A seeker after truth

PostgreSQL Index 생성 'CONCURRENTLY' 옵션, Auto Vacuum, 기타

dr.meteor — Wed, 8 Oct 2025 20:11:55 +0900

1. CREATE INDEX CONCURRENTLY 에 대하여

PostgreSQL에서 CONCURRENTLY 옵션은 인덱스를 생성하거나 제거할 때 테이블에 대한 락(lock) 방식을 다르게 하는 옵션

1) 일반적인 인덱스 생성

CREATE INDEX idx_name ON table_name(column_name);

이 방식은 테이블에 대한 공유 락(share lock)을 걸기 때문에, 인덱스를 생성하는 동안 테이블에 쓰기(INSERT/UPDATE/DELETE)가 잠깐 멈춘다
큰 테이블에서는 시간이 오래 걸릴 수 있고, 서비스 중인 테이블이라면 문제가 될 수 있다

2) CONCURRENTLY 옵션 사용

CREATE INDEX CONCURRENTLY idx_name ON table_name(column_name);

이 방식은 테이블을 락하지 않고도 인덱스를 생성할 수 있다 (인덱스를 생성하는 동안에도 SELECT, INSERT, UPDATE, DELETE 모두 가능)
단점
- 일반 인덱스 생성보다 시간이 더 오래 걸릴 수 있음
- 만약 생성 도중 실패하면, 부분적으로 만들어진 인덱스가 남아 있는 경우가 있다. 이때는 DROP INDEX CONCURRENTLY로 제거해야 한다

3) 주의할 점

CONCURRENTLY를 쓰면 트랜잭션 안에서 사용할 수 없다.
`BEGIN; CREATE INDEX CONCURRENTLY idx_name ON table_name(column_name); -- 오류 COMMIT;`
그래서 단독으로 실행해야 한다.

2. Auto Vacuum이 동작하는 이유, 그리고 빅데이터 적재 시 이의 동작 시간이 늘어나는 이유

1) Auto Vacuum이 필요한 이유

PostgreSQL은 레코드를 지우지 않고, 버전을 관리하는 구조를 쓴다 (MVCC(Multi-Version Concurrency Control) 기반 DB니까)

UPDATE → 기존 튜플을 "dead tuple(죽은 행)"으로 표시하고 새 튜플을 생성
DELETE → 튜플은 그대로 남아 있지만 "dead" 상태로만 표시
즉, 물리적으로는 공간이 줄어들지 않음

이 dead tuple이 쌓이면:

디스크 공간 낭비 → 테이블이 실제 데이터보다 훨씬 커짐
쿼리 성능 저하 → 스캔 시 dead tuple까지 읽어야 함
통계 부정확 → 옵티마이저가 잘못된 실행 계획 선택 가능

그래서 autovacuum이 돌면서,

dead tuple 정리 (공간 회수)
ANALYZE 실행 (통계 업데이트)
transaction wraparound 방지 (옛 트랜잭션 ID가 오버플로 되지 않게)

2) 대량 데이터가 많아질수록 시간이 늘어나는 이유

autovacuum의 작업량은 단순히 "변경된 행 개수"에 비례하지 않고, 테이블 크기 전체와 dead tuple 분포에도 영향을 받는다.

스캔 범위 증가
- autovacuum은 dead tuple을 찾으려고 테이블 페이지를 훑어야 함
- 테이블이 커질수록 I/O 비용이 기하급수적으로 늘어남
인덱스 정리 비용
- dead tuple이 삭제되면 인덱스에서도 해당 엔트리를 지워야 함
- 인덱스 크기도 데이터에 비례해서 커지므로, 정리 시간이 길어짐
ANALYZE 비용
- 통계를 샘플링하려 해도 테이블이 크면 I/O 자체가 더 많이 듦
병렬성 제한
- autovacuum은 기본적으로 백그라운드에서 여러 워커(worker)가 돌아가지만, 전체 DB의 리소스를 무한히 쓰지는 않음 → 큰 테이블이면 한 워커가 오래 잡고 있음
Cache 효과 감소
- 작은 테이블은 메모리에 다 올라오지만, 대규모 테이블은 디스크 I/O를 계속 발생시킴 → 시간이 늘어남

3) 요약

autovacuum은 MVCC 구조 때문에 필수
데이터가 커질수록
- 스캔해야 하는 페이지 수가 많아지고
- dead tuple 정리 및 인덱스 재정리 비용이 커져서
- 시간이 오래 걸릴 수밖에 없음

4) 나는 insert 쿼리만 쓰던 상황인데, 왜 auto vacuum이 오래 돌았을까?

(1) autovacuum (ANALYZE)의 실행

INSERT로 새로운 행이 많이 추가되면, PostgreSQL은 통계가 낡았다고 판단하고 ANALYZE를 자동 실행함
autovacuum_analyze_scale_factor 기본값이 0.1 (10%)이라, 행 수가 1천만이라면 백만 건 추가될 때마다 ANALYZE가 돌음
대용량 테이블일수록 샘플링 비용이 커져서 시간이 오래 걸림

즉, UPDATE/DELETE가 없어도 "INSERT가 많으면" ANALYZE 때문에 autovacuum이 계속 돈다.

(2) 인덱스 팽창 (Index bloat)

INSERT가 계속되면 인덱스도 계속 커짐.
페이지 분할(splitting)이 반복되며 인덱스 구조가 비효율적으로 커질 수 있음.
autovacuum이 이 인덱스를 스캔하느라 시간이 늘어남.

특히 대량 INSERT → autovacuum (analyze) 시 인덱스 페이지도 같이 스캔하게 되므로 시간이 점점 길어지는 현상 발생 가능.

(3) TOAST 테이블 증가

큰 텍스트나 JSON 같은 컬럼을 많이 INSERT하면 TOAST 테이블도 같이 커짐.
autovacuum은 메인 테이블 외에도 TOAST 테이블도 같이 관리함 → 부하 증가.

(4) Dead tuple이 없더라도 visibility map 스캔 비용

VACUUM이 dead tuple을 정리하지 않더라도, "페이지에 dead tuple이 있는지" 확인하기 위해 visibility map을 스캔함.
테이블 크기가 커지면, 이 확인 작업 자체가 느려짐. (즉, I/O 기반 비용 증가)

5) TOAST 테이블이란?

TOAST(Table Of Attributes Stored Externally)는 테이블의 너무 큰 컬럼 데이터를 본 테이블 바깥에 따로 저장하는 내부 메커니즘

(1) 왜 TOAST가 필요한가?

PostgreSQL의 한 행(row)은 기본적으로 한 페이지(8KB) 안에 저장돼. 그런데 만약 하나의 컬럼이 너무 크면 어떻게 될까?

예를 들어

CREATE TABLE files ( id serial primary key, filename text, content bytea );

여기서 content가 20MB짜리 바이너리 데이터라면, 이걸 한 행 안에 다 넣을 수 없겠지? 그래서 PostgreSQL은 이 큰 데이터를 자동으로 잘라서 다른 테이블에 따로 저장해버려. 이때 만들어지는 게 바로 TOAST 테이블이야.

(2) TOAST 테이블의 구조

PostgreSQL은 테이블 생성 시, 만약 “큰 컬럼이 들어올 가능성이 있다면”,
자동으로 _toast_<oid> 형태의 숨겨진 보조 테이블을 같이 만든다.

예시:

SELECT relname, reltoastrelid::regclass FROM pg_class WHERE relname = 'files';

결과:

files 테이블에는 작은 메타 정보만 남고
실제 큰 내용(content)은 pg_toast.pg_toast_12345 테이블에 저장돼 있음.

3) TOAST의 작동 방식

PostgreSQL은 큰 컬럼을 저장할 때 자동으로 3단계 압축 과정을 거쳐:

Compress → 먼저 zlib으로 압축 시도
Out-of-line storage → 그래도 크면 chunk 단위(기본 2KB)로 잘라서 TOAST 테이블에 저장
In-line fallback → 크기가 작으면 그냥 본 테이블에 저장

즉, 실제 본 테이블에는 다음처럼 저장됨

main_table.row → {toast_pointer} -- 실제 데이터는 다른 테이블(pg_toast)에 있음

(4) autovacuum과 TOAST의 관계

이게 핵심이야. PostgreSQL의 autovacuum은 메인 테이블만 관리하지 않아. 그 테이블에 딸린 TOAST 테이블도 같이 관리해. 즉,

INSERT/UPDATE/DELETE가 많으면 → main + toast 둘 다 vacuum 대상
TOAST 테이블이 커질수록 → autovacuum 시간이 늘어남

특히 큰 TEXT, JSONB, BYTEA 컬럼이 자주 바뀌거나 계속 추가되는 환경이면, TOAST 테이블에 dead tuple이 쌓이고, 이걸 정리하느라 autovacuum이 점점 오래 걸릴 수 있어.

(5) TOAST 관련 성능 관리 팁

상황 조치

큰 텍스트/바이너리 컬럼 자주 삽입	TOAST 테이블도 같이 autovacuum 관리 필요
UPDATE로 큰 데이터 교체 잦음	dead tuple 폭증 → 수동 VACUUM 주기적 실행
대용량 JSONB/TEXT 많음	ALTER TABLE ... SET STORAGE EXTERNAL or MAIN 등으로 정책 조정 가능
모니터링	pg_class.reltoastrelid 로 어떤 테이블이 TOAST 테이블을 가지는지 확인 가능

예시:

-- TOAST 테이블 이름 확인 SELECT relname AS table_name, reltoastrelid::regclass AS toast_table FROM pg_class WHERE reltoastrelid != 0; -- TOAST 테이블의 dead tuple 수 확인 SELECT relname, n_dead_tup FROM pg_stat_user_tables WHERE relname LIKE 'pg_toast%';

.... 그럼 auto vacuum을 수동 실행하는 옵션으로 삽입만 계속 하면, 삽입이 느려질 가능성은 더이상 없는 건가 정말?

3. 기타 자잘한 것

1) 2025-09-26 11:23:23 => 이런 식으로 돼있는 데이터는 타입을 timestamp without time zone(단순히 날짜와 시간만 저장. 타임존 정보 없음) 또는 timestamptz(UTC 기준으로 내부 저장 후, 세션 타임존에 맞춰 변환해서 보여줌)로 저장한다.

2) 위와 같은 값을 삽입할 땐 INSERT INTO example (created_at) VALUES ('2025-09-26 11:23:23'); 같은 식으로 작은 따옴표로 감싸서 넣으면 된다.

3) INSERT INTO my_table ("name") VALUES (hello); => 큰따옴표로 감싸는 건 테이블명, 컬럼명으로 인식한다.

네트워크, DB 업무 용어1

dr.meteor — Sun, 7 Sep 2025 23:41:24 +0900

- 공인 IP: 인터넷 이용자로서 발급받은 공유기 IP. 한국인터넷진흥원에서 관리함.

- 사설IP: 해당 공유기를 통한 네트워크를 사용하는 기기들이 가진 IP. 내 컴퓨터 IP, 엔진엑스 IP, 로컬호스트 IP 등등이 이에 해당.
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-IP-%EA%B8%B0%EC%B4%88-%EC%82%AC%EC%84%A4IP-%EA%B3%B5%EC%9D%B8IP-NAT-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A7%90-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC#%EA%B3%B5%EC%9D%B8_ip

- 터널링: 한 네트워크에서 다른 네트워크로 ... 다른 프로토콜이나 물리적 장벽을 '터널'처럼 가로지르도록 데이터를 캡슐화하여, 마치 중간에 장애물이 없는 것처럼 통과시키는 기술 및 현상. VPN, SSH, DNS 가 대표적.

- DB 클라이언트: 테이블플러스, dbeaver, 데이터그립 같은 접속 GUI 프로그램

Discord Stage 채널의 기술 아키텍처와 통신 기반 분석

dr.meteor — Mon, 16 Jun 2025 22:18:53 +0900

Discord의 Stage 채널은 기존 음성 채팅 채널을 확장한 일종의 실시간 음성 방송 플랫폼입니다. 청중과 발표자를 분리하고, 요청 기반의 발언 시스템을 도입하여 공개 토론, 세미나, 팟캐스트 등 다양한 용도에 활용되고 있습니다. 하지만 90명 이상 참여하는 대규모 채널에서는 발표자의 음성이 중간에 끊기거나, 심각한 오디오 왜곡(잡음) 현상이 발생하는 등의 문제가 종종 보고되고 있습니다. 이 글에서는 Stage 채널의 통신 방식, 트래픽 처리 구조, 소프트웨어 아키텍처 및 사용자 경험에서 관찰된 주요 기술적 문제에 대해 다루겠습니다.

통신 방식: WebRTC + SFU 기반의 일방향 최적화 모델

Stage 채널은 음성 데이터 전송을 위해 WebRTC 기술을 채택하고 있습니다. 이는 기본적으로 브라우저 간 실시간 음성/영상 전송을 위한 오픈소스 기술로, 낮은 지연을 보장하며 UDP를 기반으로 빠른 전송을 제공합니다.

Stage 채널의 경우, 발표자에서 청중으로 향하는 단방향 음성 스트리밍이 핵심이므로, Peer-to-Peer 연결이 아닌 SFU(Selective Forwarding Unit) 방식을 사용합니다. SFU는 각 발표자의 오디오 스트림을 받아 다수의 청중에게 중계하는 역할을 하며, 이를 통해 서버는 전송 병목을 줄이고 보다 효율적인 스트리밍을 지원합니다.

이와 같은 구조는 발표자 수보다 청중 수가 많을 때 유리하며, 각 클라이언트가 SFU로부터 스트림만 수신하므로 클라이언트 리소스 소비도 적습니다. 그러나 이 구조는 오디오 품질 저하 시 문제 원인을 정확히 추적하기 어렵다는 단점도 내포하고 있습니다.

트래픽 처리 및 분산 구조

Stage 채널은 Discord의 글로벌 인프라 내에서 동작합니다. Discord는 지역 기반으로 배치된 음성 서버(Voice Regions)와, 전 세계에 분산된 백엔드 인프라를 활용하여 사용자의 접속 위치에 따라 최적의 서버를 연결해줍니다.

이러한 구조는 일반적인 대화형 음성 채널에서는 잘 작동하지만, Stage 채널처럼 수십 명 이상의 청중이 동시에 접속할 경우 다음과 같은 트래픽 처리 이슈가 발생할 수 있습니다:

SFU의 부하 집중: 하나의 발표자의 오디오 스트림이 수십 또는 수백 명에게 중계되는 경우, 특정 SFU 노드에 부하가 집중됩니다. 부하 분산이 적절히 되지 않으면 스트림 지연이나 끊김 현상이 발생할 수 있습니다.
패킷 손실과 Jitter: UDP 기반 통신 특성상 네트워크 환경이 불안정한 사용자에게서 패킷 손실이 빈번하게 발생할 수 있으며, 이를 보정하기 위한 Jitter Buffer가 제 역할을 못하면 잡음, 끊김 등으로 이어집니다.
브라우저/앱 환경 다양성: 청중 중 일부는 브라우저로, 일부는 모바일 앱으로 접속하게 되는데, 서로 다른 환경에서 WebRTC 구현 방식이 달라져 호환성 문제로 음성 깨짐이나 싱크 밀림 현상이 일어날 수 있습니다.

소프트웨어 아키텍처: 이벤트 기반 비동기 모델

Discord는 클라이언트-서버 구조의 이벤트 기반 아키텍처를 사용합니다. 클라이언트의 모든 요청(예: 발언 요청, 발표자 전환, 음소거 처리 등)은 비동기 메시지로 서버에 전달되며, 서버는 이 이벤트를 구독 중인 참여자에게 브로드캐스트합니다.

Stage 채널은 사용자 상태를 "청중 → 발언 요청 중 → 발표자" 등의 상태로 전이시키는 상태 머신 구조를 따릅니다. 이 구조는 이벤트 전파에 의존하기 때문에 네트워크 지연이나 서버 처리 병목이 있으면 발표자 전환이 지연되거나, 청중에게 잘못된 상태가 전달될 수 있습니다.

사용자 경험 기반 주요 이슈 및 기술적 원인

Stage 채널을 실제로 운영하면서 가장 빈번히 경험되는 문제는 다음과 같습니다:

발표자 음성이 중간에 끊기거나 무음 처리됨
- SFU 노드의 부하로 인해 오디오 프레임이 유실되거나, 클라이언트의 Jitter Buffer가 정상 작동하지 않아 발생합니다.
- 발표자 디바이스에서의 CPU 과부하나 Discord 앱의 비정상적인 WebRTC 세션 재시도 로직이 원인이 되기도 합니다.
발표자 음성이 로봇 소리/기계음으로 들림
- 패킷 손실 보정을 위한 오디오 코덱(예: Opus)의 오류 복원 기능이 과도하게 작동할 경우, 음성 왜곡이 발생합니다.
- 네트워크 품질이 낮은 상태에서 SFU가 재전송을 시도하지 못하거나, 오디오 재구성이 불완전할 경우에도 유사한 증상이 발생합니다.
발언 요청/전환 지연
- 이벤트 기반 아키텍처에서 메시지 전파가 지연되거나, 발표자 상태 변경 이벤트가 일부 청중에게만 반영될 경우 발생합니다.
- 일부 클라이언트의 Discord 앱 또는 브라우저에서 WebSocket 연결이 일시적으로 끊긴 후 재연결되는 경우, 상태 불일치가 발생할 수 있습니다.
전체적인 지연 증가 (Latency Drift)
- 장시간 연결 시 클라이언트와 서버 간의 지연이 누적되며, 실시간성과 동기화 문제가 발생합니다.
- 특히 모바일 네트워크나 Wi-Fi 환경에서 네트워크 핸드오버가 발생하면 이런 문제가 심해집니다.

결론

Discord Stage 채널은 실시간 음성 방송 플랫폼으로서 WebRTC와 SFU를 활용해 다수 청중에게 고품질 음성을 전달하는 구조로 설계되었습니다. 하지만 대규모 사용자 수, 네트워크 환경의 다양성, WebRTC의 구현 복잡성 등으로 인해 실제 사용에서는 다양한 품질 저하 현상이 보고되고 있습니다.

특히 90명 이상이 참여하는 상황에서는 발표자의 음성이 끊기거나 변형되는 등 기술적 한계가 분명히 드러나며, 이는 서버 부하, 네트워크 상태, 클라이언트 환경 등 여러 복합 요소에 기인합니다. 향후 이러한 문제를 해결하기 위해서는 더욱 정교한 트래픽 분산, 클라이언트 네트워크 적응 알고리즘 개선, 상태 동기화 메커니즘의 안정화가 필요합니다.

게임 개발은 유니티 하나로 끝? 게임 개발의 기술 스택과 구조 이해하기 (feat.MMORPG, 퍼즐)

dr.meteor — Tue, 22 Apr 2025 22:20:40 +0900

저는 웹, 앱, 데이터 분야 개발에는 익숙하지만, 게임 개발은 유니티와 언리얼만 알 뿐 구조나 기술 스택은 생소하여 이 글을 쓰게 되었습니다. 간단하게 공부해본 결과, 게임은 클라이언트-서버 아키텍처는 물론 실시간 통신, 인프라, 운영 툴까지 웹/앱 이상으로 복잡한 구조를 갖추고 있었습니다. 이 글에서는 게임 개발의 전체적인 아키텍처와 사용 기술, 엔진의 역할까지 정리했습니다.

게임 개발의 전체 구조

게임 개발도 웹 서비스처럼 기획 → 개발 → 테스트 → 출시 → 운영이라는 사이클을 따릅니다. 하지만 내부 구조와 요구되는 기술은 꽤 다릅니다.
게임은 무엇보다 실시간성과 높은 사용자 경험(UX)을 요구하기 때문에, 아키텍처도 여기에 맞춰 구성됩니다.

️ 기본 아키텍처: 클라이언트 - 서버 - DB

게임도 기본적으로는 클라이언트와 서버, 그리고 데이터 저장소로 구성됩니다.

[클라이언트(Unity/Unreal)]  <-->  [게임 서버]  <-->  [DB, 캐시 등]
                                        │
                                        └── [운영툴 서버, API 게이트웨이 등]

클라이언트

Unity (C#), Unreal Engine (C++) 등 게임 엔진을 사용
그래픽, 물리 엔진, UI, 애니메이션, 사운드, 입력 처리 등 포함
WebSocket이나 TCP/UDP 통신 기능 내장 또는 확장 가능

게임 서버

실시간 멀티플레이, 전투 로직, 유저 세션, 매치메이킹 등 처리
Java, Node.js, Go, C#, C++ 등 다양한 언어로 커스텀 구현
Redis, MySQL, MongoDB, Cassandra 등 다양한 DB 사용

게임 서버 구조는 어떻게 생겼을까?

게임의 장르에 따라 서버 구조도 달라집니다.

예를 들어 MMORPG처럼 대규모 유저가 동시에 접속하는 게임은 다음과 같은 마이크로서비스 아키텍처 형태를 가질 수 있습니다.

Zone 서버 (맵/지역 단위로 분리)
매치메이킹 서버
채팅 서버
AI 서버
인증 및 과금 서버
운영툴 서버

실시간 처리를 위해 TCP/UDP 기반 통신을 주로 사용하고, 일부 시스템은 REST API나 gRPC로도 구성합니다.

그렇다면 퍼즐 게임은 어떨까요? 경우에 따라 다르지만, 여기선 MMORPG에 비하면 비교적 단순한 클라이언트-서버 구조를 갖는 예시로 캐주얼 퍼즐 게임을 들어보겠습니다.

캔디크러쉬사가, 애니팡 같은 캐주얼 퍼즐 게임의 특징은 다음과 같습니다.

싱글 플레이 중심
실시간성 거의 없음
서버는 주로 유저 정보 동기화, 랭킹, 광고, 과금 처리 담당
대부분은 비동기 구조 + 클라이언트 중심 설계

따라서 클라이언트가 대부분의 게임 로직을 처리하고, 서버는 기록과 검증만 맡는 구조가 일반적입니다. 이 경우 서버는 주로 다음과 같은 기능을 수행합니다.

유저 계정 관리 (게스트, 소셜 로그인 등)
스테이지 클리어 기록 저장
하트, 아이템 보유량 동기화
과금/광고 보상 처리
랭킹 (주로 비동기: 일일/주간 등)

이 경우 DB에는 유저 상태, 인벤토리 등이 저장될 것이고, 광고, 결제, 랭킹, 푸시 등의 기능은 내외부 API가 수행할 것입니다.

유니티/언리얼의 주요 역할

유니티와 언리얼은 주로 클라이언트 개발에 집중된 엔진입니다.

주요 역할:

3D/2D 렌더링
물리 엔진 처리
UI 구성
애니메이션 시스템
오디오 처리
일부 네트워크 기능

그렇기 때문에 유니티, 언리얼이 기획자에게 프로토타이핑 툴로도 쓰일 수 있는 것입니다. 반면, 주 역할이 아닌 것은 다음과 같습니다.

게임 서버 로직 개발 (멀티플레이 동기화, 매치메이킹 등)
데이터베이스 저장/조회
인증, 과금, 이벤트 운영
대시보드/운영툴 개발
로그 수집, 분석

그렇지만 앞서 나왔던 캐주얼 퍼즐 장르처럼 비교적 단순한 게임의 경우, 클라이언트가 게임의 주요 로직을 처리하기도 합니다.

주요 기술 스택

게임 클라이언트, 서버, 인프라/DevOps 분야의 주요 기술 스택을 정리하면 다음과 같습니다.

클라이언트

기능	기술 스택
그래픽/물리/애니메이션	Unity, Unreal Engine
UI	엔진 내 UI 시스템, TextMeshPro 등
오디오	FMOD, Wwise 등
네트워크	WebSocket, TCP/UDP, Photon, Mirror 등

서버

기능	기술 스택
게임 로직	Java, Node.js, C#, C++ 등
데이터 저장	MySQL, MongoDB, Redis, Cassandra 등
세션/매치메이킹	자체 구현 또는 BaaS (PlayFab, Nakama 등)
인증/결제	OAuth, Firebase Auth, AWS Cognito 등

인프라 및 DevOps

인프라: Docker, Kubernetes, AWS/GCP
배포/CI: GitHub Actions, Jenkins, ArgoCD
모니터링/로깅: Prometheus, Grafana, ELK, Sentry
콘텐츠 배포: CDN 기반 패치 시스템

✅ 마무리

게임 개발은 처음 접하면 유니티, 언리얼로 모든 걸 다 할 수 있을 것 같지만, 실제로는 복잡한 분산 시스템과 다양한 기술 스택이 함께 움직이는 종합 개발입니다.

웹이나 앱 개발에 익숙한 사람이라면, 서버 아키텍처, 통신 구조, DevOps 등 익숙한 개념들이 게임에서도 적용되지만, 실시간성과 사용자 경험에 훨씬 민감한 환경이라는 점이 차이점입니다.

처음 게임 개발을 알아보시는 다른 분들에게도 이 글이 도움되었길 바라며 마치겠습니다.

OS에서 프로그램과 패키지가 설치 및 삭제되는 과정을 설명해보자.

dr.meteor — Sun, 20 Apr 2025 17:30:38 +0900

안녕하세요! 이번 글에서는 일상적으로 경험하는 프로그램 설치와 삭제 과정 속에 숨겨진 내부 동작에 대해 자세히 알아보려고 합니다. 설치 버튼을 클릭하거나 패키지 매니저 명령어 몇 줄이면 완료되는 이 과정 뒤에는 운영체제 내부에서 어떤 복잡한 일들이 일어날까요?

1. 설치 파일 실행 - 첫 단계

Windows에서 .exe 파일을, Mac에서 .dmg 파일을 더블 클릭하면 어떤 일이 벌어질까요?

User: 크롬 설치 파일 더블클릭
OS: "오, 실행 가능한 프로그램이네! 이걸 메모리에 올려서 실행해야겠다."

이 순간 운영체제는 해당 파일이 실행 가능한 형식인지 확인하고, 설치 프로그램을 메모리에 로드합니다. 이것은 하드 디스크에서 RAM으로 데이터를 복사하는 과정입니다. 설치 프로그램이 메모리에 로드되면, CPU는 해당 프로그램의 명령어를 실행하기 시작합니다.

2. 사용자 권한 확인 - 보안의 첫 관문

OS: "이 프로그램이 시스템을 변경하려고 하는데, 허용할까요?"
User: "예" 버튼 클릭

이 단계에서 운영체제는 사용자 계정 제어(UAC)를 통해 관리자 권한이 필요한 작업을 허용할지 확인합니다. 이는 권한 상승(privilege escalation)이라는 보안 메커니즘의 일부로, 모든 프로그램이 기본적으로 제한된 권한으로 실행되다가 필요할 때만 더 높은 권한을 요청하게 됩니다.

3. 시스템 환경 확인 - 호환성 체크

설치 프로그램: "이 컴퓨터가 내가 필요로 하는 조건을 갖추고 있는지 확인해야겠다."

설치 프로그램은 다음과 같은 항목을 확인합니다:

OS 버전과 호환성
필요한 최소 하드웨어 사양
필수 종속성(dependencies) 존재 여부
디스크 공간 확인

이 과정은 운영체제의 시스템 레지스트리나 환경 변수에 접근하여 정보를 수집합니다.

4. 파일 추출 및 복사 - 짐 풀기

설치 프로그램: "모든 필요한 파일을 지정된 위치에 풀어놓자."

대부분의 설치 파일은 실제로는 압축 파일입니다. 이 단계에서는:

압축 해제 알고리즘이 작동하여 파일을 풉니다.
파일 시스템 API를 사용하여 파일을 지정된 디렉토리에 복사합니다.
파일 시스템 트리가 업데이트됩니다.

Windows에서는 주로 C:\Program Files\ 디렉토리에, Mac에서는 /Applications/ 폴더에 파일이 복사됩니다. 이 과정에서 파일 시스템의 디렉토리 구조에 새로운 노드(폴더와 파일)가 추가됩니다.

5. 시스템 레지스트리 업데이트 - 주소록 갱신

설치 프로그램: "OS에게 내가 여기 있다고 알려주자."

특히 Windows 시스템에서 중요한 단계입니다:

레지스트리는 키-값 쌍으로 구성된 계층적 데이터베이스입니다.
설치 프로그램은 HKEY_LOCAL_MACHINE\SOFTWARE\ 또는 HKEY_CURRENT_USER\SOFTWARE\ 아래에 프로그램 정보를 기록합니다.
이 정보에는 설치 경로, 버전, 구성 설정 등이 포함됩니다.

Mac과 Linux에서는 레지스트리 대신 구성 파일(.plist, .conf 등)을 사용하여 비슷한 정보를 저장합니다.

6. 환경 변수 설정 - 길 표시하기

설치 프로그램: "다른 프로그램들이 나를 쉽게 찾을 수 있도록 지도에 표시해놓자."

많은 프로그램이 시스템 환경 변수를 수정합니다:

PATH 변수에 실행 파일 경로 추가 (명령줄에서 프로그램을 쉽게 실행할 수 있게 함)
특정 프로그램용 환경 변수 설정 (예: JAVA_HOME)
이 변경사항은 메모리와 구성 파일 모두에 반영됩니다.

이런 환경 변수는 일종의 전역 해시맵(hashmap)으로 생각할 수 있습니다.

7. 바로가기 생성 - 접근성 향상

설치 프로그램: "사용자가 나를 쉽게 찾을 수 있게 바로가기를 만들자."

이 단계에서는:

바탕화면, 시작 메뉴 또는 독(Dock)에 바로가기 파일이 생성됩니다.
이 바로가기는 실제로 작은 포인터 파일로, 실제 프로그램 경로를 가리킵니다.
파일 연결(file associations)이 설정되어 특정 확장자를 가진 파일을 이 프로그램으로 열 수 있게 합니다.

8. 서비스 등록 - 백그라운드 작업자 배치

설치 프로그램: "부팅할 때마다 자동으로 실행되도록 설정하자."

일부 프로그램은 시스템 서비스나 데몬으로 등록됩니다:

Windows의 서비스 관리자 또는 Linux/Mac의 systemd/launchd에 서비스가 등록됩니다.
부팅 시퀀스에 이 서비스를 시작하는 단계가 추가됩니다.
이는 프로세스 관리 시스템의 작업 대기열에 새로운 항목을 추가하는 것과 같습니다.

9. 종속성 설치 - 필요한 재료 모으기

설치 프로그램: "내가 제대로 작동하려면 이것들도 필요해."

많은 프로그램이 다른 소프트웨어 구성 요소에 의존합니다:

공유 라이브러리 (.dll, .so, .dylib 파일)
런타임 환경 (예: .NET, Java Runtime)
이런 종속성이 없으면 설치 프로그램이 자동으로 다운로드하고 설치합니다.

이것은 일종의 의존성 그래프(dependency graph)를 따라 필요한 모든 노드를 확보하는 과정입니다.

10. 설치 완료 및 정리 - 마무리 작업

설치 프로그램: "모든 작업이 완료되었으니 임시 파일을 정리하고 마무리하자."

마지막으로

임시 파일이 삭제됩니다.
설치 로그가 생성됩니다.
필요하다면 시스템 재시작을 요청합니다.
설치 프로그램 자신이 종료됩니다.

CLI 패키지 관리자로 설치하게 되면?

CLI 패키지 관리자(apt, yum, brew, npm 등) 역시 명령어 한 줄로 위의 모든 단계를 자동화합니다.

User: apt install firefox
패키지 관리자: "알겠습니다. 필요한 모든 것을 알아서 처리할게요."

이 간단한 명령어 뒤에서 패키지 관리자는

중앙 저장소에서 패키지 정보를 검색합니다.
종속성을 해결합니다 (의존성 그래프 생성).
필요한 모든 파일을 다운로드합니다.
파일을 적절한 위치에 설치합니다.
시스템 구성을 업데이트합니다.

이는 그래프 이론, 해시 테이블, 트리 구조 같은 자료구조를 활용하여 이루어집니다.

프로그램 삭제 시

프로그램을 삭제할 때는 설치의 역순으로 진행됩니다.

User: "프로그램 삭제" 클릭
OS: "이 프로그램과 관련된 모든 것을 찾아서 제거할게요."

자료 구조로 본 삭제 프로세스

그래프 순회(Graph Traversal): 설치 중 생성된 파일 및 레지스트리 항목의 그래프를 역방향으로 순회합니다.
해시맵 조회(HashMap Lookup): 빠른 파일 및 레지스트리 항목 조회를 위해 해시맵을 사용합니다.
큐(Queue): 삭제할 항목을 순서대로 처리하기 위한 작업 대기열이 생성됩니다.

삭제 중 진행되는 일들

언인스톨러(제거 프로그램) 실행: 대부분의 프로그램은 자체 제거 프로그램을 포함합니다.
파일 시스템 정리: 프로그램 파일이 삭제됩니다 (파일 시스템 트리에서 노드 제거).
레지스트리 정리: 프로그램 관련 레지스트리 키가 삭제됩니다.
환경 변수 롤백: 변경된 환경 변수가 원래 상태로 복원됩니다.
바로가기 및 파일 연결 제거: 생성된 바로가기와 파일 연결이 제거됩니다.
서비스 등록 해제: 등록된 서비스가 중지되고 시스템에서 제거됩니다.

이 과정에 사용된 아키텍처와 기술은?

이 모든 과정이 원활하게 작동하는 데는 몇 가지 핵심 아키텍처와 기술이 있습니다.

1. 계층적 파일 시스템

파일 시스템은 트리 구조로 설계되어 있어 프로그램 파일을 체계적으로 저장하고 찾을 수 있게 해줍니다:

/ (루트)
└── Program Files/
    └── Chrome/
        ├── chrome.exe
        ├── resources/
        └── libs/

이 트리 구조는 깊이 우선 탐색(DFS)이나 너비 우선 탐색(BFS) 알고리즘으로 효율적으로 탐색할 수 있습니다.

2. 계층적인 키-값 저장소 형태의 레지스트리/설정 데이터베이스

HKEY_LOCAL_MACHINE/
└── SOFTWARE/
    └── Google/
        └── Chrome/
            ├── Version = "123.0.0"
            └── InstallPath = "C:\Program Files\Chrome"

이 구조는 B-트리나 그 변형을 사용하여 빠른 검색, 삽입, 삭제를 지원합니다.

3. 패키지 관리 시스템

패키지 관리자는 다음과 같은 핵심 구성 요소를 가집니다:

의존성 해결기(Dependency Resolver): 방향성 비순환 그래프(DAG)를 사용하여 패키지 간 관계를 모델링합니다.
중앙 저장소(Repository): 패키지 메타데이터의 분산 데이터베이스입니다.
트랜잭션 엔진: ACID(원자성, 일관성, 고립성, 지속성) 속성을 보장하여 설치 과정이 중단되어도 시스템이 일관된 상태를 유지하게 합니다.

4. 디지털 서명과 해시 함수를 활용한 무결성 검증

패키지 파일의 해시값 계산 (SHA-256 등)
공개 키 암호화를 사용한 서명 검증
인증서 체인 검증

OS는 암호화 기술을 통해 설치 과정의 안전성을 보장합니다.

마치며

단순해 보이는 설치/삭제 작업 뒤에는 이처럼 복잡한 과정과 정교한 알고리즘이 작동하고 있습니다. 이같은 복잡성은 사용자에게는 보이지 않지만, 시스템의 안정성과 효율성을 보장하는 필수적인 요소입니다.

현대 패키지 관리자들은 다음과 같은 문제를 해결하기 위해 계속 발전하고 있습니다.

의존성 지옥 방지: 정교한 버전 관리와 충돌 해결 메커니즘
안전한 롤백: 설치 실패 시 시스템을 이전 상태로 복원
성능 최적화: 병렬 다운로드, 증분 업데이트 등으로 속도 향상
보안 강화: 서명 검증, 체크섬, 샌드박싱 기술 적용

다음에 프로그램을 설치하거나 삭제할 때, 단순한 클릭 또는 명령어 하나로 이루어지는 것처럼 보이지만, 그 이면에는 수십 년간 발전해온 컴퓨터 과학의 정수가 응축되어 있다는 점을 기억하시면 좋겠습니다.

그럼 이 글이 독자분의 CS 이해도와 응용력을 높이는 데 도움이 되었기를 바라며 글을 마치겠습니다.

개념, 논리 모델링

dr.meteor — Mon, 22 Apr 2024 17:37:02 +0900

모델링의 정의

모델링의 정의는 영속성을 갖는 데이터에 대한 시스템 구조를 사람이 이해할 수 있도록 형상화하는 과정임
개념적 모델링을 거쳐 식별한 것을 기호 등을 통해 추상화하여 표현, 논리적 모델링을 하고 정보 시스템의 데이터베이스로 구축하기 위해 추상화된 모델을 구체화된 형태로 변환하는 것을 물리적 모델링이라고 함

식별자 상속

집합 간의 베타 관계를 해소하고 두 집합을 통합 테이블 형태로 설계한 경우 개인 개발 생산성이 증대되고 성능 향상 효과도 기대할 수 있음
개인 고객 속성과 법인 고객 속성이 같은 테이블에 혼합되어 존재함으로 속성의 의미가 불분명해지고, not null 제약 조건을 반영할 수 없어 데이터 무결성 문제가 발생할 수 있음
데이터 정합성 문제가 발생하지 않도록 응용 프로그램에서 업무 규칙을 추가로 설계하고 반영해야 함
식별자 상속은 식별 관계와 비식별 관계로 구분할 수 있음
식별 관계는 참조되는 상위 엔티티, 식별자가 참조하는 하위엔티티 비식별자로 상속되는 경우를 말하고, 비식별 관계는 식별자가 아닌 일반 속성으로 상속되는 관계를 말함

데이터 모델링의 정규형

유형을 만족하지 못하는 모델은 개념이 명확하지 않거나 다수의 개념을 하나의 엔티티에 포함한 것이므로 개념을 분리하여 모델링을 하면 대부분 정규형을 만족하는 결과를 얻게 됨
별도 정규화 과정을 거치지 않았다 해도 데이터 모델링 완전성을 확인해 본다는 측면에서 정규형을 만족하고 있는지 검토할 수 있음
정규화를 너무 심하게 할 경우 응용 프로그램에서 조인이 빈번하게 발생해 성능이 저하되지 않을까 걱정할 수 있음

정규화의 개념

정교화는 물리모델링이 아닌 논리모델링 과정에서 ER 모델과 함께 적용하는 것이 일반적임
부채꼴 함정은 제3정규형에서 발생하는 문제임
부채꼴 함정은 엔티티 사이의 관계가 정의되어 있지만 관계가 모호한 경우 m:n 관계를 해결하기 위해 교차 엔티티를 도입하면서 1대 1 관계를 만들 때 일어날 수 있음
엔티티 간 관계를 잘못 설계하여 연계된 정보를 추적하지 못해 발생함으로 이들 간 관계를 명확히 하여 해결할 수 있음

데이터 모델링의 개념

데이터 모델링은 데이터 아키텍처의 핵심 구성 요소임
데이터 모델링은 프로젝트 상황에 따라 하향식 접근 방식과 상향식 접근 방식 두 가지가 있음

리버스 모델링의 개념

직무 면접을 갔을 때 소통 성향이라든지 외향적인 성향이라든지 이런 것들이 중요하게 여겨질 수 있음
리버스 모델 활용이라는 개념이 새로워서 알면 좋을 것 같음
리버스 모델링은 데이터 모델을 현행화하는 과정을 말함
보충 설명: DB 메타 정보로 기초 데이터 모델을 생성, 즉 엔티티를 생성하고 컬럼에 대한 코멘트 정보를 이용하거나 시스템 운영자의 지원을 받아 한글명으로 속성을 수정하는데 FK 제약 조건이 없는 경우가 대부분이므로 현행 시스템 산출물을 최대한 활용하고 업무나 시스템을 잘 아는 시스템 운영자에게 도움을 요청할 수 있다

데이터 분산 전략

할당된 it 자원을 파악할 수 있어 정보 시스템 구축에 따른 중복 투자를 방지할 수 있고 이미 투입된 자원을 효율적으로 재분배할 수 있음
데이터 관리 차원에서는 데이터에 대한 통합, 연계, 중복 등에 대한 방안을 수립하는 데 기초 자료로 활용할 수 있음
데이터 분산 전략 수립 시 데이터 주제 영역별로 분산 아키텍, 주제 영역 단위로 담당자를 지정하여 데이터 모델링 작업을 수행하고 각각의 데이터 모델을 통합할 수 있는 근간을 제공하여 시스템 개발 및 유지보수 활동을 효율적으로 수행할 수 있음

개념 모델의 속성 정의

데이터를 바라보는 관점에 따라 완전히 다른 주제 영역으로 분류될 수 있으므로 데이터 관점으로 접근할지, 업무나 기능 중심으로 분류할지 고객을 포함한 이해관계자와 충분히 협의하여 진행하는 것이 좋음
식별자 및 속성 정의에 대한 이야기
개념 모델링을 하다 보면 모델러에 따라 속성 전체를 노출해야 한다는 사람도 있고, 식별자와 일부 속성 정도로 극히 일부만 노출하면 된다는 사람도 있음
개념 모델을 누가 어떤 용도로 사용할지를 생각한다면 답은 대충 나오는 것 같음

논리 데이터 모델링

논리 데이터 모델링은 모든 업무 영역에 필요한 데이터 모델을 설계하고 시스템 관점에서 필요한 데이터 항목은 반영하지 않음
데이터에 대한 이력 관리 대상은 업무 측면에서 꼭 관리할 필요가 있는 부분은 반영해야 함
논리모델링은 개념 데이터 모델과 지속해서 구조적 일관성을 유지하면서 진행함

엔티티 통합의 개념

데이터를 수집할 수 있는 대상이 고객이 될 수도 있고, 동의 절차를 통과해야 비로소 고객 집합에 포함될 수도 있어서 까다로움
엔티티는 업무 행위에 대한 상세 배역 및 업무 결과에 대한 상태를 나타내는 엔티티이며, 중요 엔티티에 종속되거나 다른 행위 엔티티에 종속됨
엔티티 통합은 엔티티 일반화를 통해 구조적인 측면에서 하나의 엔티티로 설계하는 경우도 있고, 여러 시스템이나 업무에서 개별적으로 관리하던 데이터를 모아 관리하는 데이터 통합도 있음
투비 데이터 모델의 설계 방향을 수립할 때 데이터 및 엔티티 통합이 핵심 개선 요소로 많이 언급됨

식별자 상속 관계와 비식별자 상속 관계

식별자 상속 관계와 비식별자 상속 관계의 차이는 FK가 어디에 위치하느냐임
식별자 상속 관계는 FK가 곧 PK키를 갖는 엔티티를 구별하는 역할까지 동시에 수행하는 것임
비식별적 상속 관계인 경우에는 관계를 통해서 FK를 받긴 하지만 그게 곧 FK이 갖고 있는 엔티티의 PK까진 아닌 거임

M:N 관계

고객과 상품, 주문과 배송처럼 핵심 엔티티나 중요한 엔티티 간 관계를 개념적으로 표현할 때 나타난다.
논리 모델에서는 엔티티를 상세화하거나 교차하는 엔티티를 설계하여 m:n 관계를 1대 1 관계로 표현한다.
M:N 관계가 완전히 해소될 때까지 1대 m 관계를 분해해야 한다.

속성

데이터 표준 도메인과 매우 깊은 관계가 있으며, 번호, 코드, 명칭, 설명, 금액, 날짜, 비율 등 도메인을 중심으로 데이터 성격을 식별할 수도 있다.
데이터 발생 규칙을 기술하기도 한다.

식별자 지정

유일하게 식별 가능하고 최소 속성으로 구성하고 변하지 않으면서 반드시 존재하는 값
자세한 얘기는 SQLD 요약본에. 모든 엔티티는 식별자가 있어야 되는데 없는 경우는 로그 성격 데이터거나 데이터로서 가치를 갖지 않는 임시 저장 성격의 데이터 가능성이 높다.
그래서 데이터 간 특성의 구분이 식별자로 이루어질 수도 있다는 걸 배우게 됐고, 엔티티 개체가 처음부터 유일하게 존재하는 것이 아니라 업무 처리나 이벤트 성격의 데이터인 경우 회원 아이디, 계좌번호처럼 아이디나 일련번호 등을 부여하여 식별하는 경우도 흔하다. 이 경우라 하더라도 일련번호 등을 부여하는 기준이 뭔지 반드시 식별해야 한다.
인조 식별자는 결제 번호처럼 결제를 상실할 때 본질 식별자인 사원번호 등을 대신하여 인위적으로 부여한 일련번호 형식의 식별자를 말한다.
본질 식별자를 주 식별자로 하는 경우 주민등록번호보다는 사원번호처럼 엔티티를 대표하거나 변하지 않는 혹은 식별자 특성에 더 적합한 속성을 우선하는 것이 좋다. 사원번호가 주식별자가 되는 경우 주민등록번호는 자연스럽게 대체 식별자가 된다.
인조 식별자를 주 식별자로 사용하면서 본질 식별자를 식별하지 않은 경우를 종종 볼 수 있다.
결제에 상실할 때 상신자가 상신했을 때 본질 식별자는 데이터를 발생하는 규칙을 제공하며 유일하게 데이터를 식별할 수 있는 기준을 제공한다.
본질 식별자를 정확하게 정의하지 않았다면 핵심적인 정의가 누락되었다고 볼 수 있으며, 개발자가 데이터 집합을 자의적으로 해석하여 중복 데이터를 발생시킬 수 있는 여지를 주게 된다.
결제번호처럼 인조 식별자를 주 식별자로 정의한 경우 문제 식별자인 상신자, 사원번호, 플러스 결제 일시를 대체 식별자로 지정할 수 있다.
본질 식별자 또는 인조 식별자가 주식별자 역할이라든지 대체 식별자 역할이라든지 데이터 발생 규칙을 정의하고 실체의 무결성, 제약 조건을 설계해야 한다.
논리 데이터 모델은 업무 변경에 유연하게 대응할 수 있어야 하고 확장성을 가져야 한다.
향후 식별자를 변경하게 된다면 해당 엔티티와 관계를 갖는 다른 엔티티도 영향을 받게 된다.
본질 식별자를 사용하는 것보다 인조 식별자를 사용한다면 식별자를 변경할 가능성이 낮아지고 이로 인한 설계 변경을 최소화할 수 있다.
이처럼 본질 식별자 대신 인조 식별자를 사용하여 유연하고 확장 가능한 논리 모델을 설계할 수 있는 경우가 있다.
업무적으로 중요성은 덜하지만 본질 식별자에 (발주 번호 + 입찰 마감일자) 대신 인조 식별자인 입찰 번호를 부여하여 관리할 수도 있다.
하위 엔티티에 대한 하위 엔티티가 존재할 때 식별자를 계속 상속받게 되므로 하위 엔티티로 내려갈수록 식별자 속성 개수가 많아지게 되며 모델이 복잡해진다.
데이터 모델을 단순화하고 물리 모델로 변환했을 때 개발 편의성 및 성능적인 이점을 제공하기 위해 인조 식별자를 추가하여 주 식별자로 사용한다.
또 개인정보 암호화 대상에 해당하여 본질 식별자를 주식별자로 사용하지 못하는 경우도 있고, 본질 식별자에 대한 데이터가 들어오지 않은 상태에서 업무 처리를 위해 인조 식별자를 추가하는 경우도 있다.
도메인을 지정하거나 데이터 타입을 지정할 때 가장 중요한 원칙은 속성이 관리할 때 데이터에 맞는 데이터 타입을 지정하는 것이다.

데이터 타입

데이터 유형을 고려하여 문자형, 숫자, 날짜형 데이터 타입을 지정해야 한다. 식별자 속성은 좀 애매하다. 업무적으로 부어 코드, 연도, 일련번호와 같은 식별 체제 체계를 갖는다면 문자형을 지정해야 하고, 의미없이 시스템에서 순차적으로 부여한다면 숫자형으로 지정한다.
자식 엔티티에서 식별자로 상속받으려면 무조건 not null로 지정되고, 비식별자, 즉 일반 속성으로 상속받으면 옵셔널리티 지정에 따라 not null 여부가 결정된다.

CI, github actions에 대해 알게 된 것 총정리 ing

dr.meteor — Sun, 31 Mar 2024 08:41:33 +0900

CI는 리눅스 등 로컬 OS 환경에서 뭘 할 수 없을 때, 검사하고 싶은 타 OS 에서 뭘 하고 싶은지 CLI 명령어 기반으로 정의 내리고 시키는 일이라고 생각한다.

대표적 툴인 github actions 의 문법이 공식 문서에 정리돼있다: https://docs.github.com/en/actions/using-workflows

검사 속도를 빠르게 하는 캐싱에 관한 건 여기 정리돼있고 https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

최종 프로젝트 환경 구성에선 이 레포에 나오는 내용을 참고해 설정했다: https://github.com/actions/cache

또 feature/** 브랜치에 push가 생길 때마다, develop 브랜치에 PR 생길 때마다 CI 트리거를 하고 싶어 문법을 찾아봤는데, 아래와 같이 하면 끝난다... 출처는 https://github.com/actions/cache

또 주의사항으로, 처음 workflow 구동 시 루트 폴더에 대해 동일한 하위폴더 명으로 들어가 실행 경로를 잡아 버린다. 보통 장고에서 레포 네이밍을 이런 식으로 많이 하기 때문이겠지

그래서 이름을 서로 다르게 잡아놨다면, python manage.py test 명령 전에 폴더를옮기는 작업 먼저 해주어야 한다. yml 파일에 반영한 모습은 아래와 같다.

그리고 깃헙액션도 컨텍스트 변수가 있고, 다음과 같은 값들을 지니고 있다. 어떤 정보에 접근하고 활용할 수 있는지 알 수 있다: https://velog.io/@excellent/Github-Action-Context

21년도에 스파크 실시간 처리 영상 남겨둔 것

dr.meteor — Sat, 9 Mar 2024 20:46:06 +0900

데이터 재전처리 과정에서 발견한 것들

dr.meteor — Sun, 3 Mar 2024 14:18:42 +0900

- 면수는 그냥 물이랑 마찬가진데 미리 전처리할걸 후회됨...

- 한 컵을 1C 로 표현한 것도 발견. 국자'란 단위도 있음. 또 밥 한 '공기' 도. tb란 단위도. ea/EA 도 있음

- 파프리카 "각각 1/2개씩" 이런거 표현 어케하나 싶음

- "야채 절임물" 이것도 판매하는 재료 아닌데 어쩌냐

- 당근 단위로 '덩이'도 있다.. 심지어 3/1 덩이라고 분수 잘못씀ㅎㅎ;;;

- 아래와 같은 '혼합장' 재료로 인식하면.. 없는 재료라서...ㅠㅠㅠㅠ

콩나물 300g 끓는물에 3분데쳐 냉장고에서 차게 식힌다.

혼합장 1/2T, 소금 1/2t, 깨소금 1T, 참기름 1T, 다진대파 2T넣고 무친다.

시금치나물

시금치 300g 데쳐 물기 꼭짜주고,

*혼합장 1/2T, 소금 1/2t, 깨소금 1T, 참기름 1T넣고 무쳐준다.

*혼합장= 국간장:멸치액젓:참치액 1:1:1로 섞어서 써요.

<Apache Airflow 기반의 데이터 파이프라인> 6,8,14단원 메모

dr.meteor — Fri, 26 Jan 2024 20:38:33 +0900

8단원

코드 자체가 좋음 이를테면 yield, 에러 및 예외처리 파트 등. 그리고 파이썬 패키지 만드는 방법 다루고 있는.. 챕터다.

https://github.com/K9Ns/data-pipelines-with-apache-airflow/blob/main/chapter08/dags/custom/ranking.py

이를테면 위 코드에서 pd.NamedAgg란 클래스는 처음봄!

logger = logging.getLogger(__name__)

그동안 이걸 안했구낳; 당황스럽