1,974줄 풀 백업 — 1인 개발에서 상태 관리하는 법

💡 Tip. 바쁜 현대인들을 위한 본문 요약

• 워크트리 4개를 한 사람이 돌릴 때 통신 채널이 없으면 어제 결정이 오늘 휘발된다 — 단일 파일 session-sync.md 한 장으로 모든 역할이 같은 줄을 읽고 쓰는 운영
• 500줄 임계치 + 풀 아카이브 디렉토리 — session-archive/YYYY-MM-DD_HHmm_제목.md 로 떨어뜨리는 패턴, 임계치는 모델 컨텍스트 윈도우 보호
• 메시지 표준 한 줄 — ## [발신 → 수신] YYYY-MM-DD HH:MM - 제목 — 회고 가능한 형태로 결정이 남고, 다음 세션이 grep 으로 따라잡는다
• 변경 명세서는 별도 디렉토리 — docs/changes/YYYY-MM-DD_*.md 는 git 추적, session-sync.md 는 git 외부
• 하루치 통신이 1,974줄까지 누적된 풀 백업의 안쪽 — 모듈 등록 누락 DI 에러 회수, 배포 인프라 동시 진행, 연락처 포맷 통일 BE·FE 직렬화 같은 결정 3건이 같은 한 장 위에서 차례로 실렸다
• 권장 도입 순서 — 단일 파일 신설 → 500줄 임계치 → 아카이브 디렉토리 → 메시지 표준 → 변경 명세서 분리 → LESSONS 갱신 룰

---

🎯 동기 — 한 사람이 5개 세션을 돌리려면 상태가 어디 있어야 하나

데스크톱 런타임 배포까지 끝낸 다음 날, 같은 사람이 같은 키보드 앞에서 다섯 개 역할을 번갈아 돌리는 흐름이 본격적으로 가동됐다. PM 세션이 변경 명세서를 떨어뜨리면 BE 세션이 구현 + 빌드를 가져가고, FE 세션이 그 위에서 폼·테이블을 갈아끼우고, QA 세션이 검증 시나리오를 회수하고, 외부 단말 세션이 모바일·Unity 콘텐츠 흐름을 받아낸다.

문제는 각 세션이 서로의 결정을 모른다는 점이다. 같은 사람이라도 세션은 별개의 모델 인스턴스이고, 한 세션이 컨텍스트 윈도우를 다 쓰고 종료되면 그 안에 있던 결정·근거·다음 작업은 함께 휘발된다. 어제 PM 세션이 BE 세션에 넘긴 “Display 테이블 스키마 변경 명세서”의 채택 사유가 다음 BE 세션에는 남아 있지 않다는 의미다.

“같은 사람이 같은 키보드로 두 역할을 번갈아 박아도, 결정을 문자열로 남겨 두지 않으면 회고가 되지 않는다.”

해결은 단순했다 — 모든 세션이 같은 파일 한 장을 읽고 쓴다. 그 파일이 session-sync.md 다. PM 세션이 BE 세션에 넘기는 명세는 [PM → BE] 헤더로 시작하는 메시지가 되고, BE 세션의 완료 보고는 [BE → PM] 헤더로 같은 파일 그 아래에 누적된다. 다음 BE 세션이 깨어났을 때 첫 행동은 이 파일을 처음부터 끝까지 읽는 것이다.

📌 핵심: 1인 멀티 세션 개발의 상태 관리는 각 세션의 메모리가 아니라 세션 외부의 공유 파일에 있어야 한다. 같은 사람이 같은 결정을 두 번 내리지 않으려면, 결정이 문자열로 같은 파일 안에 남아 있어야 한다.

---

🛠️ 설계 — 단일 파일 + 임계치 + 아카이브 디렉토리

설계는 세 부분으로 나뉜다. 파일 한 장, 임계치 한 개, 디렉토리 한 개.

단일 파일 session-sync.md 의 위치

파일은 git 추적 밖이다. 위치는 워크트리 바깥의 별도 vault — ~/Documents/obsidian/jongmolee-vault/git/server/nest-prisma/session-sync.md. git 추적에 두면 머지 충돌이 통신 비용을 거꾸로 끌어올린다. 같은 머신 안에서 세션끼리만 보면 되는 워킹 메모 의 성격이라 별도 vault 가 자연스러운 위치다.

파일 상단은 세션 진행 상황 보드 다. 아래는 실제 풀 백업 시점의 상단 일부를 발췌한 형태다.

# Session Sync - 세션 간 공유 파일

> PM/Backend/Frontend/QA/Unity 세션 간 실시간 소통용.
> Git 외부, 커밋 없이 즉시 공유.

## 운영 규칙
- **500줄 이하** 유지
- 아카이브: `session-archive/YYYY-MM-DD_HHmm_제목.md`

## 현재 진행 상황 (YYYY-MM-DD HH:MM)
| 작업 | 내용 | 담당 | 상태 |
|------|------|------|------|
| ...  | ...  | ...  | ...  |

## 워크트리 현황
nest-prisma/            ← PM (dev)
nest-prisma-backend/    ← BE (feature/backend-work)
nest-prisma-frontend/   ← FE (feature/frontend-work)
nest-prisma-unity/      ← 외부 단말 (feature/unity-work)

상단 보드 아래로 시간순 메시지 스트림 이 누적된다. 각 메시지는 한 형식만 따른다.

## [PM → BE] 2026-02-03 00:30 - 지표 운영테이블 스키마 변경

### 배경
기존 구현이 RAW 테이블 기반이었으나, Display 테이블 히스토리 방식으로 변경 필요.

### 변경 명세서
docs/changes/2026-02-03_지표_운영테이블_히스토리.md (v2 업데이트됨)

### 작업 체크리스트
- [ ] schema.prisma: @unique 제거, 인덱스 추가
- [ ] prisma db push
- [ ] metric-display.service.ts: upsert → create
- [ ] member-metrics API 로직 수정 (Display 기반)

🔍 단서: 메시지 표준 한 줄 ## [발신 → 수신] YYYY-MM-DD HH:MM - 제목 이 다음 세션의 grep 진입점이 된다. 다음 BE 세션이 깨어났을 때 grep '\\[PM → BE\\]' 한 번으로 자신 앞으로 떨어진 모든 명세를 시간순으로 회수한다.

임계치 500줄 — 모델 컨텍스트 윈도우 보호

500줄은 자의적인 숫자가 아니다. 세션 모델의 컨텍스트 윈도우 가 임계치를 결정한다. 한 세션이 깨어나서 첫 행동으로 session-sync.md 를 전부 읽어야 하는데, 파일이 2,000줄로 부풀어 있으면 그 한 번의 읽기로 컨텍스트의 큰 덩어리가 지나간 통신 으로 채워진다. 정작 본 작업에 쓸 토큰이 줄어든다.

500줄 임계치는 작업 가능한 컨텍스트 비율 을 60% 이상으로 유지하려는 보호 장치다. 임계치를 넘으면 완료된 메시지를 아카이브로 떨어뜨려 본문을 다시 가볍게 만든다. 임계치는 머신 메모리·모델 컨텍스트 윈도우에 따라 조정 가능하지만, 500줄은 16K 토큰 안쪽에서 시간순 보드 + 워크트리 현황 + 다음 작업 보드 까지 모두 보존할 수 있는 경험적 임계치다.

아카이브 디렉토리 — 시간 기준 풀 백업

session-archive/ 디렉토리는 시간 기준의 풀 백업 저장소 다. 파일명 규칙은 YYYY-MM-DD_HHmm_제목.md. 풀 백업이 떨어지는 순간 본문은 상단 보드 + 다음 작업 보드 만 남기고 비워진다.

세 디렉토리는 갱신 빈도와 영속성이 다르다. 분 단위로 바뀌는 통신은 git 외부, 머지 단위로 고정되는 명세는 git 안. 둘 사이의 다리가 시간 기준 아카이브 다.

---

📝 실전 사례 — 1,974줄 풀 백업 안에 담긴 결정 3건

2026-02-03_1740_full_backup.md 는 하루치 통신이 1,974줄까지 누적된 시점에 떨어진 풀 백업이다. 그날 하루 안에 같은 한 장 위에서 일어난 결정 3건을 짧게 짚는다.

결정 1 — 모듈 등록 누락 DI 에러 회수 → LESSONS 항목 추가

지표 운영테이블 스키마 변경 머지 직후, dev 머지를 받은 직후 서버 기동에서 NestJS DI 에러가 발견됐다.

Nest can't resolve dependencies of the MemberReportApplicationService (PrismaService, ?).
Please make sure that the argument MetricDisplayService at index [1] is available
in the ParentModule context.

근본 원인은 단순했다 — MemberReportApplicationService 에 MetricDisplayService 의존성을 추가했으나, 해당 모듈의 providers 배열에 등록을 누락 했다. tsc --noEmit 과 pnpm build 는 통과한다. NestJS 런타임에서 의존성 그래프를 구성할 때만 실패한다.

PM 세션이 직접 수정한 후 같은 파일에 한 줄을 남겼다.

## [PM → BE] 2026-02-03 02:00 - ⚠️ DI 에러 발생 (모듈 등록 누락)

### 필수 조치 — LESSONS.md 에 새 항목 추가됨, 반드시 숙지

`.claude/skills/role-backend/LESSONS.md`
→ "13. 서버 기동 테스트 필수 - DI 에러 검증 (Critical)"

### 앞으로의 작업 완료 보고 전 체크리스트
1. TypeScript 빌드 — `pnpm build`
2. 서버 기동 테스트 (PORT=3001) — "Nest application successfully started" 확인
3. 관련 API curl 테스트
4. 3001 포트 회수 (Ctrl+C)

같은 한 장의 마법은 이 지점에서 나온다. 결정 (pnpm build 만으론 부족) 이 문자열 로 남고, 근거 (실제 에러 메시지) 가 바로 위 메시지 에 보존되어 있고, 전파 채널 (LESSONS.md 13번 항목) 이 다음 BE 세션의 시작 시 자동 읽기 대상으로 묶인다.

⚠️ 주의: DI 에러는 pnpm build 만으론 잡히지 않는다. NestJS 의 의존성 주입은 런타임 에서 모듈 그래프를 구성한다 — 컴파일 통과와 무관하다. 서버 기동 테스트가 마지막 검증 단계 다.

결정 2 — Cloud Run 배포 + Firebase Hosting 멀티사이트 동시 진행

같은 날 오전·오후 안에 Cloud Run 컨테이너 배포 와 Firebase Hosting 멀티사이트 3건 분리 배포 가 차례로 들어갔다. 같은 세션이 두 가지를 동시에 박지 않았다. PM 세션이 [PM → BE] 메시지로 Dockerfile 트러블슈팅을 넘기고, BE 세션이 응답으로 [BE → PM] 머지 보고를 떨어뜨리는 사이에, PM 세션은 Firebase 콘솔에서 사이트 4건을 생성하고 같은 파일에 다른 메시지 헤더 로 보고를 남겼다.

## [PM] 2026-02-03 09:10 - 인프라 NestJS Dockerfile 완료 (Final)
... 트러블슈팅 5건 표 ...
## [PM] 2026-02-03 10:20 - ✅ Cloud Run 배포 완료
... Service URL + 트러블슈팅 3건 ...
## [PM] 2026-02-03 03:00 - Firebase Hosting 설정 완료
... 사이트 4건 ...
## [PM] 2026-02-03 10:40 - ✅ Firebase Hosting 배포 완료
... 배포 URL 3건 + 남은 작업 ...

같은 PM 세션이 같은 한 장 위에서 시간순으로 자기 작업 흔적을 남기면, 다음 날 다른 세션 이 깨어났을 때 인프라 흐름 전체가 한 화면에 정렬된다. 이 인프라 결정의 자세한 분리 흐름은 직전 편의 외부 단말 분리 결정 과 직접 연결된다.

결정 3 — 연락처 포맷 통일 BE·FE 직렬화

가장 길었던 단일 결정은 연락처 포맷 통일 이다. DB·DTO·UI 모두 하이픈 포함/미포함이 섞여 있어, 숫자만 저장 으로 통일하는 결정을 같은 파일 안에서 다음 순서로 직렬화했다.

같은 결정의 BE 와 FE 측면 이 같은 한 장 위에서 시간 라벨로 순서 가 매겨지면, 다음 세션이 깨어났을 때 “지금 어디까지 직렬화됐는지” 가 한 번의 grep 으로 회수된다. 17:30 시점에서 BE 게이트가 닫혔고 FE 게이트가 열려 있다는 사실이 시간순 보드 의 메시지 두 줄로 남는다.

📊 데이터: 풀 백업 1,974줄 중 결정 3건이 점유한 비중은 약 41% (812줄). 나머지 1,162줄은 작은 결정 17건 — DTO 필드 추가·캐시 모듈 도입·로깅 인터셉터 추가·UX 버그 회수 같은 단발 통신이다.

---

💡 교훈 — 운영하며 알게 된 패턴·안티패턴

90개 풀 백업이 누적된 4개월간 운영하며 채택·기각한 패턴을 짧게 정리한다.

채택한 패턴

기각한 패턴

📌 핵심: session-sync.md 운영의 핵심은 시간 단위에 따른 위치 분리 다. 분 단위 통신, 머지 단위 명세, 시간 단위 풀 백업, 세션 단위 LESSONS — 네 가지가 서로 다른 위치 에 놓이고, 위치 간의 다리만 명확하면 1인 멀티 세션은 작동한다.

---

🚀 권장 — 같은 상황이라면 어떻게 도입하나

같은 1인 멀티 세션 흐름을 처음 도입한다면 권장 순서는 다음과 같다.

1단계 — 단일 파일 신설 (10분)

워크트리 바깥의 별도 디렉토리에 session-sync.md 한 장 신설. 위치는 git 외부. 상단에 세션 진행 보드 + 워크트리 현황 + 운영 규칙 세 섹션만 두고 시작.

mkdir -p ~/notes/<project>/session-archive
touch ~/notes/<project>/session-sync.md

2단계 — 메시지 표준 한 줄 (5분)

모든 메시지는 ## [발신 → 수신] YYYY-MM-DD HH:MM - 제목 으로 시작. 표준 한 줄이 다음 세션의 grep 진입점 이다.

세션 신설 시 .claude/CLAUDE.md (또는 동등 위치)에 다음 룰 한 줄을 박아 둔다.

## 세션 시작 시 필수 행동
1. `~/notes/<project>/session-sync.md` 처음부터 끝까지 정독
2. 자신 역할에 해당하는 가장 최근 `[X → 본인]` 메시지 회수
3. 작업 완료 시 `[본인 → 발신자]` 헤더로 같은 파일에 보고 누적

3단계 — 임계치 + 풀 백업 룰 (15분)

session-sync.md 가 500줄을 넘으면 다음 세션이 깨어났을 때 첫 작업으로 풀 백업 떨어뜨리기 를 수행. 파일명은 session-archive/YYYY-MM-DD_HHmm_제목.md. 본문은 상단 보드 + 다음 작업 보드만 남기고 비움.

4단계 — 변경 명세서 분리 (30분)

git 추적이 필요한 명세는 별도 디렉토리. docs/changes/YYYY-MM-DD_제목.md. 머지 단위로 고정하고, session-sync.md 안에서는 명세 파일 경로 만 인용한다.

### 변경 명세서
docs/changes/2026-02-03_연락처_포맷_통일.md

5단계 — LESSONS 갱신 룰 (선택)

세션 종료 직전, 운영 중 발견한 재발 가능 패턴 은 .claude/skills/role-<역할>/LESSONS.md 에 번호 매긴 항목으로 추가. 다음 세션 깨어남 시 자동 읽기 대상으로 묶이도록 CLAUDE.md 에 인용 한 줄.

💡 인사이트: 5단계 도입의 비용은 1 시간 안쪽 이고, 회수는 세션 한 번 만에 시작된다. 두 번째 세션이 깨어났을 때 첫 행동이 어제 결정 회수 로 자동 정렬되면, 같은 결정을 두 번 내리는 비용이 사라진다.

---

📋 정리 — 1인 멀티 세션 운영 체크리스트

본 회고의 결정을 체크리스트로 정리한다.

본 운영 회고의 더 깊은 패턴 정리는 다음 편에서 세션 단위 LESSONS.md 의 7가지 역할 분기 와 now.md 단일 파일 ToDo 보드 를 같은 C 톤 메타 회고로 이어간다.