AI는 세션이 바뀌면 다 잊는다 — 그래서 문서 우선
어제 세 시간 동안 AI와 함께 설계를 다듬었습니다. 다음 날 새 세션을 열었더니, 그 AI는 어제 일을 하나도 기억하지 못했습니다. 처음 만나는 사람처럼요. 이 망각을 “결함”으로 여겨 싸우려는 동안엔 계속 같은 자리를 맴돌았습니다. 망각을 전제로 인정하고 나서야, 개발 방식이 근본적으로 바뀌었습니다. 이 글은 “AI에게 어제가 없다는 게 무슨 뜻인지”, “왜 머릿속·대화창은 믿으면 안 되는지”, 그리고 “문서를 AI의 장기기억으로 삼는다는 게 구체적으로 무엇인지”를 풀어 쓴 기록입니다.
AI에겐 어제가 없다
섹션 제목: “AI에겐 어제가 없다”사람 동료라면 “어제 그거 어떻게 됐죠?”가 통합니다. AI 세션은 다릅니다. 대화창을 닫는 순간, 그 안의 모든 결정·맥락·시행착오가 사라집니다. 새 세션은 완전한 백지에서 시작합니다 — 어제의 토론도, 우리가 고민 끝에 내린 결론도, 막다른 길에서 돌아 나온 경험도 전부 없던 일이 됩니다.
더 나쁜 건, 긴 작업 도중 컨텍스트(작업 기억)가 가득 차 압축되면 — 한 세션 안에서도 — 앞부분을 잊는다는 점입니다. 한 시간 전에 정한 방향을, 같은 세션의 AI가 두 시간째에는 기억하지 못할 수 있습니다. 망각은 예외가 아니라 작동 원리입니다.
초기엔 이걸 인정하지 않았습니다. 중요한 결정을 머릿속과 대화 맥락에만 담아둔 채 작업했습니다. 그 결과 새 세션마다 같은 설명을 반복했고, AI는 지난 세션이 이미 내린 결정을 모른 채 다른 방향으로 코드를 짰습니다. “분명 어제 이렇게 하기로 정했는데” 싶은 일이 거듭됐습니다.
처방 — 문서를 AI의 장기기억으로
섹션 제목: “처방 — 문서를 AI의 장기기억으로”해법은 의외로 단순합니다. 중요한 것은 전부 파일에 적습니다. AI의 휘발성 메모리 대신, 저장소(git)에 박힌 문서를 장기기억으로 삼습니다. 그러면 어떤 세션이 열려도 같은 출발점에 섭니다 — 문서가 “어제의 나”를 대신 기억해주니까요.
구체적으로 네 종류의 문서를 AI의 기억으로 삼았습니다.
| 문서 종류 | 담는 것 | 언제 읽나 / 쓰나 |
|---|---|---|
| 상태 파일 | 지금 무슨 작업 중인지 · 남은 것 · 다음 할 일 · 제약조건 | 세션 시작 시 가장 먼저 읽음 |
| 핸드오프 문서 | 이 세션의 진행 상황 · 내린 결정 · 막힌 지점(블로커) | 세션 끝낼 때 다음 세션을 위해 남김 |
| 결정 기록(ADR류) | “왜 이렇게 정했나”의 근거 | 같은 논쟁을 반복하지 않도록 참조 |
| 프로젝트 규칙·지식 | 우리 컨벤션 · 도메인 불변식 · 금지 사항 | 매 세션 자동 로드 |
흐름으로 펼치면 이렇게 작동합니다.
- 세션 시작 — 상태 파일과 규칙 문서를 가장 먼저 읽어, “어디까지 했고 무엇을 지켜야 하는지”를 복구합니다.
- 작업 중 결정 — 중요한 판단을 내리면 그 근거를 결정 기록에 적습니다 (“왜 A가 아니라 B를 골랐나”).
- 컨텍스트가 차오르면 — 압축이 일어나기 전에 핵심 맥락을 상태 파일로 떨궈두고 커밋합니다.
- 세션 종료 — 핸드오프 문서에 진행 상황·블로커를 남겨, 다음 세션이 곧장 이어받게 합니다.
특히 세 번째 — 압축 전에 미리 떨궈두기 — 가 핵심입니다. 망각 자체는 막을 수 없으니, 망각해도 복구되게 설계한 것입니다. 컨텍스트가 일정 수준 차오르면 상태 파일을 갱신하고 커밋한 뒤 압축하도록 절차를 뒀습니다. 압축으로 작업 기억이 흐려져도, 방금 떨군 파일을 다시 읽으면 자리를 되찾습니다.
”문서 우선”은 느린 게 아니다
섹션 제목: “”문서 우선”은 느린 게 아니다”처음엔 문서를 먼저 쓰는 게 손해처럼 느껴졌습니다. “코드를 짜야 진도가 나가는데, 문서나 쓰고 있다니.” 실제론 정반대였습니다.
여기엔 더 큰 의미도 있습니다. 회사의 노하우가 사람의 머릿속이 아니라 문서와 에이전트에 축적되면, “그 사람만 아는 것” 같은 인수인계 리스크가 구조적으로 줄어듭니다. AI의 망각을 메우려고 시작한 문서화가, 조직의 기억을 사람에서 시스템으로 옮기는 일과 같은 방향을 향합니다.
핸드오프가 실제로 작동하는 모습
섹션 제목: “핸드오프가 실제로 작동하는 모습”문서 우선이 추상적으로 들릴 수 있으니, 두 세션이 하루를 사이에 두고 한 작업을 이어받는 과정을 단계로 펼쳐 봅니다.
- 월요일 세션 — 어떤 모듈의 결재선 검증을 손보다가 “이 예외 케이스는 내일 처리”라는 미완 지점에 도달합니다.
- 종료 직전 — 상태 파일에 “지금까지 한 것 / 남은 예외 케이스 / 막힌 이유”를 적고, 핸드오프 문서에 “다음 세션은 여기부터”를 남기고 커밋합니다.
- 화요일 새 세션 — 완전한 백지로 열립니다. 하지만 가장 먼저 상태 파일과 규칙 문서를 자동으로 읽습니다.
- 즉시 복구 — “아, 어제 결재선 검증을 하다 예외 케이스에서 멈췄구나”를 문서로 파악하고, 같은 설명을 다시 들을 필요 없이 곧장 그 지점부터 이어갑니다.
여기서 월요일의 AI와 화요일의 AI는 서로 다른 세션 — 사실상 다른 기억의 존재입니다. 그런데도 작업이 매끄럽게 이어지는 건, 오직 그 사이에 놓인 문서 덕분입니다. 문서가 없었다면 화요일의 AI는 “결재선 검증을 처음부터 다시 설명해 주세요”라고 했을 것이고, 운이 나쁘면 어제 폐기한 방향을 모르고 되살렸을 것입니다.
망각은 결함이 아니라 전제다
섹션 제목: “망각은 결함이 아니라 전제다”처음에 저는 AI의 망각과 싸우려 했습니다. “왜 어제 일을 기억 못 하지?” 그건 잘못된 질문이었습니다. AI는 원래 그렇게 작동합니다. 사람 동료를 대하는 방식(구두로 인수인계, 머릿속 맥락 공유)을 AI에 그대로 쓰려 한 게 문제였습니다.
전제를 바꾸자 해법이 명확해졌습니다. “AI는 잊는다”를 받아들이고, 잊어도 복구되는 구조를 만든다. 그게 문서 우선 개발입니다. 망각을 없애려는 대신, 망각에 대비합니다.
이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에, 멀티세션을 굴릴 때 각 세션이 같은 출발점에 서게 하는 토대는 〈멀티세션과 worktree 격리〉에 있습니다.