Articles
Lesson 11분

세션이 바뀌면 기억이 사라져요 — 이슈 트래커를 AI의 공유 메모리로 만든 이야기

AI 에이전트와 일할 때 세션이 바뀔 때마다 같은 설명을 반복하고 있었어요. 이슈 트래커의 description을 '세션 간 공유 메모리'로 재설계하고, 콜드스타트 실행률 0%를 100%로 바꾼 시행착오.

중급 세션 연속성 이슈 트래커 맥락 관리 AI 에이전트 프로젝트 관리 Linear
이 글을 읽으면
  • 배경: AI 에이전트와 35일간 일하면서 세션이 바뀔 때마다 같은 맥락을 반복 설명하는 데 시간을 쓰고 있었어요
  • 핵심 인사이트: 이슈 트래커를 “할 일 목록”이 아닌 “세션 간 공유 메모리”로 재설계하면, 어떤 세션에서든 이슈 하나만 읽고 작업을 이어갈 수 있었어요
  • 이런 분에게: AI에게 작업을 맡길 때마다 “이거 왜 하는 건데?” “지난번에 어디까지 했지?”를 다시 설명하고 있는 분

세션이 바뀌면 맥락이 증발해요

AI와 일하면서 가장 많이 낭비한 건 뭘까요? 저는 “같은 설명을 반복하는 시간”이었어요.

셀포지(Selforge) 프로젝트를 35일간 운영하면서 이슈가 30개쯤 쌓였어요. 이슈 트래커에 제목은 적어뒀거든요. “위키 에이전트 개선”, “크론 스케줄 수정”, “콘텐츠 파이프라인 추가” 같은 식으로.

문제는 다음 날 새 세션을 열 때 시작됐어요. PM 에이전트 셀피한테 “HMI-18번 이슈 진행해줘”라고 하면, 셀피가 이슈를 열어보고는 이렇게 물어봐요.

“이 이슈, 왜 해야 하는 건가요? 어디서부터 시작하면 될까요?”

분명 어제 같이 논의하면서 만든 이슈인데, 오늘의 셀피는 어제의 셀피가 아니거든요. AI 세션은 바뀔 때마다 백지 상태에서 시작해요. 어제의 맥락은 증발하고, 이슈 제목만 덩그러니 남아있는 거예요.

결국 저는 매번 같은 설명을 반복하고 있었어요. “이건 이런 배경이 있고, 이 파일을 수정해야 하고, 여기서 시작하면 돼.” 매일. 같은 이슈에 대해. 세션이 바뀔 때마다.

셀포지 시스템을 35일 운영하면서 Linear 이슈가 30개 축적됐어요. 세션이 끊기고 새로 시작할 때마다 같은 패턴이 반복됐어요:

  • 이슈 title만 보고는 “왜 이걸 하는지” 알 수 없음
  • 셀피(PM 에이전트)가 추측하거나, 흐민이 다시 설명해야 함
  • 컴팩션(대화 요약)이 남긴 정보는 “결과” 중심이라 “의도”가 빠져있음

실제 데이터를 확인해보니 이슈의 60%가 description이 비어있고, 20%는 완료 후 결과만 기록된 상태였어요. 이슈가 만들어지는 지점이 5곳(주간 제안, 데일리 브리핑, ad-hoc 대화, daily wrap-up, 주간 리뷰)에 분산되어 있는데, 각 지점에 이슈 품질 기준이 없었어요.

기존 시스템이 이 문제를 잡지 못한 이유: 세션이 살아있는 동안은 대화 컨텍스트가 맥락을 대신해줬거든요. 문제는 세션 경계를 넘을 때만 드러나요.

사람은 기억하지만, AI는 기억하지 못해요

이 문제가 미묘한 이유는, 이슈를 만들 때는 절대 느끼지 못한다는 거예요.

이슈를 만드는 순간에는 세션 안에서 맥락이 살아있거든요. “아, 아까 논의한 그거지”라면서 제목만 적어요. 충분하다고 느껴요. 그 맥락이 머릿속에(정확히는 세션 컨텍스트에) 있으니까요.

사람끼리 일할 때도 비슷한 패턴이 있지 않나요? 회의에서 열심히 논의하고 “그럼 이거 진행하자”라고 했는데, 담당자가 나중에 “그래서 뭘 어떻게 하라는 거죠?”라고 물어보는 상황. 회의록에 결론만 적고 배경과 맥락을 빠뜨렸던 거예요.

AI와 일할 때 이게 극단적으로 드러나요. 사람은 어제 회의 내용을 어렴풋이라도 기억하지만, AI는 세션이 바뀌면 진짜로 아무것도 모르는 상태가 되거든요. “어렴풋이 기억하는” 것조차 없어요.

원인 체인을 정리하면 이렇게 돼요:

이슈가 생성/수정되는 지점이 5곳에 분산
  → 각 지점에 이슈 품질 기준 없음
    → 주간 제안에서 "무엇을/왜/공수"를 분석하지만
      → 이 분석이 Linear description으로 흘러가지 않음
        → 이슈 생성 시점에는 맥락이 세션 컨텍스트에 있어서
          → description의 필요성을 못 느낌

핵심은 마지막 줄이에요. 맥락이 컨텍스트에 있을 때는 기록의 필요성을 느끼지 못해요. 문제가 드러나는 건 항상 세션 경계를 넘을 때예요.

이슈 = 세션 간 공유 메모리

이 문제를 해결하려고 이슈 description의 구조를 설계했어요. 기준은 하나였어요.

“새 세션이 이 이슈의 description만 읽고 작업을 시작할 수 있는가?”

이 질문에 “예”라고 답할 수 있으면 좋은 description, 아니면 부족한 description이에요. 이슈 트래커를 “할 일 목록”이 아니라 “세션 간 공유 메모리”로 바라보기 시작한 거예요.

사람 사이에서도 마찬가지잖아요. 좋은 이슈 티켓이 “X 기능 개선”이 아니라 “X 기능에서 이런 문제가 있고, 이런 방향으로 접근하고, 이 파일에서 시작하면 된다”를 담고 있는 것처럼요.

5개 블록으로 정리했어요. 배경(왜 필요한가), 방향(어떻게 접근하는가), 진입점(어디서 시작하는가), 목표 연결(왜 지금 하는가), 완료 기준(뭐가 되면 끝인가). 이 다섯 가지가 있으면 어떤 세션에서든 이슈 하나만 읽고 바로 작업을 시작할 수 있어요.

5-Block Description 구조를 설계했어요:

  1. 배경 — 왜 필요한가. 증상 + 원인 가설. Bug면 원인 가설 필수.
  2. 방향 — 어떻게 접근하는가. 실행 동사 기반. “확인한다/검토한다”는 방향이 아니라 TODO예요. 조사가 필요한 경우 “원인이 X면 A를, Y면 B를” 형태의 분기 경로.
  3. 진입점 — 어디서 시작하는가. 구체적 파일 경로 + grep 명령어.
  4. 커밋먼트 연결 — 왜 지금 하는가. 상위 목표와의 연결 한 줄.
  5. 완료 기준 — 뭐가 되면 끝인가. 구현 시점에 바로 검증 가능한 기준. “N일 관찰” 같은 후행 지표 대신 코드/설정에서 확인 가능한 상태.
5-Block Description 구조 — 배경, 방향, 진입점, 커밋먼트 연결, 완료 기준으로 구성된 세션 간 공유 메모리

이 구조의 핵심은 WHY/HOW/WHERE/DONE 네 차원을 빠짐없이 담는다는 거예요. 이슈 트래커에 관계없이 — Linear든 Jira든 GitHub Issues든 — 이 네 차원이 있으면 새 세션이 콜드스타트로 작업을 시작할 수 있어요.

”잘 만들었다”고 생각했는데 0점이었어요

5-Block 구조를 만들고 나서, 처음에는 꽤 만족스러웠어요. 체계적으로 정리했으니까 잘 되겠지 했죠.

근데 한 가지 결정을 잘못 내렸어요. 이슈의 긴급도에 따라 description 상세도를 다르게 적용한 거예요. 급한 이슈(Must Ship)는 5-Block 전부, 급하지 않은 이슈(Nice to Have)는 배경 한 줄만.

합리적으로 들리죠? 급한 건 상세하게, 급하지 않은 건 간단하게. 시간도 아끼고.

그러고 나서 블라인드 테스트를 돌렸어요. 아무 맥락 없는 새 세션에서 이슈 description만 읽고 작업을 시작할 수 있는지 확인한 거예요. 결과는 충격이었어요.

5개 이슈 중 0개가 콜드스타트 실행 가능. 0%.

급하지 않지만 복잡한 이슈들이 문제였어요. 긴급도가 낮으니까 description이 한 줄이었는데, 실제로는 설계 판단이 필요한 이슈들이었거든요. 새 세션은 “뭘 해야 하는지는 알겠는데, 왜 해야 하는지 모르겠고, 어디서 시작하는지 모르겠어요”라는 상태가 됐어요.

v1 구현에서 긴급도 기반 차등을 적용했어요. Must Ship → 5-Block 전부, Nice to Have → 배경 한 줄.

블라인드 콜드스타트 리뷰를 진행했어요. Architect 에이전트에게 아무 맥락 없이 description만 주고 “작업을 시작할 수 있는가?”를 평가하도록 한 거예요.

v1 결과: 5개 이슈 중 0개가 콜드스타트 실행 가능 (0%)

핵심 결함 3가지:

  • WHERE 차원 부재: 파일 경로가 없어서 새 세션이 어디서 시작할지 모름
  • HOW 차원 빈약: “확인한다/검토한다” 같은 탐색 동사가 실행 동사 대신 사용됨
  • 원인 가설 부재: 증상만 기술하고 왜 그런지 가설이 없음

긴급도 기반 차등의 근본 문제를 Architect 블라인드 리뷰로 파악했어요: 긴급도는 “언제 할 것인가”의 기준이지 “얼마나 맥락이 필요한가”의 기준이 아닌 거예요. P4(낮은 긴급도)라도 설계 판단이 필요하면 풍부한 맥락이 필요해요.

전환점 — 급한 것과 복잡한 건 다른 축이에요

0%라는 숫자 앞에서 문제가 선명해졌어요.

“급한 것”과 “맥락이 필요한 것”은 다른 축이라는 거예요. 급하지 않아도 복잡한 이슈가 있고, 급하지만 간단한 이슈가 있어요. 이 둘을 한 축으로 묶으면 “급하지 않지만 복잡한” 이슈의 맥락이 증발해요.

차등의 기준을 긴급도에서 복잡도로 바꿨어요.

  • Trivial (제목만으로 범위가 명확한 이슈): 배경 한 줄이면 충분해요
  • Non-trivial (설계 판단이 필요한 이슈): 배경 + 방향 + 진입점 + 목표 연결
  • Complex (여러 파일 수정, 원인 분석이 필요한 이슈): 5-Block 전부

이렇게 바꾸고 다시 블라인드 테스트를 돌렸어요.

5개 중 5개 콜드스타트 실행 가능. 100%. 평균 점수 6.6/8.

작은 전환이었지만, 0%가 100%가 되는 결과를 가져왔어요.

복잡도 기반 차등으로 전환했어요:

  • Trivial (제목만으로 scope 명확, 한 줄 수정): 배경 한 줄
  • Non-trivial (설계 판단 필요): 배경 + 방향 + 진입점 + 커밋먼트
  • Complex (다수 파일 수정, 원인 분석 필요): 5-Block 전부
v1 긴급도 기반에서 v2 복잡도 기반으로의 전환 — 콜드스타트 실행률 0%에서 100%로

v2 블라인드 콜드스타트 리뷰 결과:

이슈WHYHOWWHEREDONE합계판정
HMI-822217/8PASS
HMI-921216/8PASS
HMI-1022228/8PASS
HMI-1821216/8PASS
HMI-1921216/8PASS

Before: 0/5 콜드스타트 실행 가능 (0%) After: 5/5 콜드스타트 실행 가능 (100%), 평균 6.6/8

원칙은 어디에 심을까

5-Block 구조를 만들었는데, 이걸 실제로 지키게 만드는 게 다음 과제였어요. 이슈가 만들어지는 지점이 5곳이나 되거든요. 주간 제안할 때, 매일 브리핑할 때, 대화 중에 갑자기 생길 때, 하루를 마무리할 때, 주간 리뷰할 때.

세 가지 방법을 검토했어요.

A) 5곳 각각에 규칙을 심는다 — 같은 규칙을 5번 복사해야 해요. 하나를 고치면 나머지 4곳도 고쳐야 하고요.

B) 별도 가이드 파일을 만들고 5곳에서 참조한다 — 중복은 없지만, “이 파일을 참조해”라는 연결 고리를 5곳에 다 심어야 해요.

C) 셀피의 핵심 규칙 파일에 원칙을 추가한다 — 한 곳만 수정하면 끝이에요.

C를 선택했어요. 셀피의 역할을 정의하는 파일(pm-channel.md)은 셀피가 행동하는 모든 순간에 이미 읽히고 있었거든요. 여기에 원칙을 심으면 별도로 참조하라고 하지 않아도, 크론이든 대화든 모든 지점에서 자연스럽게 적용돼요.

웹 프레임워크의 미들웨어 패턴과 비슷해요. 모든 요청이 지나가는 곳에 규칙을 하나 심으면, 개별 라우트마다 따로 적용하지 않아도 되잖아요.

이슈가 생성·수정되는 지점 5곳에 대한 아키텍처 결정:

A) 5개 스킬 각각에 작성 로직 삽입 — 중복 5배, 유지보수 비용 높음 B) 별도 linear-issue-guide.md 레퍼런스 파일 — DRY하지만 참조 체인 복잡 C) pm-channel.md에 원칙 섹션 추가 (채택) — 1곳 수정으로 전체 적용

C를 선택한 이유: pm-channel.md는 셀피의 오케스트레이터 파일이에요. 크론이든 ad-hoc이든 모든 행동에서 이미 로드돼요. 프레임워크의 미들웨어 패턴이에요.

그리고 원칙만 심으면 점점 안 지키게 되니까, 피드백 루프를 이중으로 만들었어요:

  • 데일리 브리핑: “description이 빈 활성 이슈”를 감지하면 브리핑에 플래그
  • 주간 리뷰: description 충실도 자체 점검 항목

원칙이 살아있으려면 위반을 감지하는 장치가 필요해요.

분석했으면 기록하라

5-Block을 도입한 뒤에 재미있는 낭비를 하나 더 발견했어요.

매주 월요일에 셀피가 이번 주 태스크를 제안하거든요. 이때 각 태스크에 대해 “무엇을 / 왜 / 공수”를 분석해요. 꽤 꼼꼼하게. 그런데 이 분석 결과가 이슈 description으로 흘러가지 않고 있었어요. 세션 안에서 분석하고, 제안을 보내고, 그 분석은 그냥 사라지는 거예요.

이미 만들어진 분석을 description에 옮겨 적는 건 추가 비용이 거의 0이에요. 이미 머릿속에(세션 컨텍스트에) 있는 정보니까요. 반면에 나중에 새 세션이 맥락을 다시 구축하는 비용은 이슈 하나당 꽤 커요.

“분석했으면 기록하라.” 단순한 원칙인데, 의식하지 않으면 놓치기 쉬워요. 맥락이 머릿속에 있는 동안에는 기록의 필요성을 느끼지 못하거든요. 문제는 항상 세션 경계를 넘을 때 드러나요.

이건 AI와 일할 때만의 이야기가 아니에요. 사람끼리 일할 때도, 회의에서 열심히 논의한 내용이 회의록에 안 남으면 다음 회의에서 같은 논의를 반복하잖아요. 같은 구조예요.

핵심 발견: selfy-weekly-suggest(주간 태스크 제안 크론)의 Step 4에서 이미 배경/방향/커밋먼트를 분석하는데, Step 5(Linear 동기화)에서 description 필드를 아예 안 쓰고 있었어요.

Write-through 최적화를 적용했어요:

  • Step 4의 “왜:” → 배경 블록으로 확장
  • Step 4의 “무엇을:” → 방향 블록으로 정제
  • 진입점: grep/find로 파일 경로 조회하여 추가
  • 커밋먼트: Step 4에서 이미 매핑 완료

토큰 경제성: pm-channel.md(5-Block 원칙 포함)는 세션 prefix로 캐싱돼요(Anthropic 프롬프트 캐시, 5분 TTL, 90% 저렴). Step 4 분석은 컨텍스트 윈도우에 이미 존재해요. Step 5에서 description을 생성할 때 추가 INPUT 비용 = 0. 추가 OUTPUT만 이슈당 약 270 토큰.

항목BeforeAfter증분
이슈당 description평균 371자평균 1,081자2.9x
주간 이슈 읽기 비용~6.7K tokens~19.4K tokens+12.7K
세션 전환 맥락 재구축 절약—~45K tokens/주-45K
순 절감—~32K tokens/주+ 사람 시간 15-30분/주

여기서 배운 것들

이 시행착오에서 얻은 인사이트를 정리해볼게요. AI 에이전트와 일하는 상황에 한정되지 않는, 범용적인 교훈이라고 느꼈어요.

”급한 것”과 “맥락이 필요한 것”은 다른 축이에요

긴급도와 복잡도를 혼동하면, “급하지 않지만 복잡한” 것의 맥락이 증발해요. 이건 이슈 관리뿐 아니라, 문서화 전반에 적용되는 원칙이에요. “중요하지 않은 것 같으니까 간단하게만 적자”는 판단이 나중에 큰 비용이 될 수 있어요.

맥락이 있을 때는 기록의 필요성을 못 느껴요

문제가 드러나는 건 항상 맥락이 사라진 후예요. 이슈를 만들 때, 회의록을 쓸 때, 코드 커밋 메시지를 쓸 때 — “나중에 이 맥락을 모르는 사람(또는 AI)이 이걸 읽으면 이해할 수 있는가?”를 기준으로 삼으면 좋겠어요.

원칙은 피드백 루프 없이 죽어요

규칙을 만들어놓고 끝이면, 점점 안 지키게 돼요. “빈 description 감지”와 “충실도 점검”이라는 이중 피드백 루프가 원칙을 살아있게 했어요. 사람 팀에서도 마찬가지예요. 코드 리뷰가 컨벤션을 살려두는 것처럼, 정기적으로 “잘 지키고 있나?” 점검하는 장치가 필요해요.

블라인드 테스트가 착각을 깨줘요

스스로 “잘 만들었다”고 생각했던 v1이 0점이었어요. 자기가 만든 것은 맥락이 머릿속에 있으니까 잘 보여요. 맥락이 없는 제3자에게 테스트하면 진짜 품질이 드러나요. 이건 프롬프트, 문서, 설계 어디에나 적용되는 방법이에요.

마무리

빌드 로그 #5에서 셀피가 NCT와 Linear 5단 구조를 만든 이야기를 했는데, 이 글은 거기서 한 레이어 더 들어간 이야기예요. 구조를 만드는 것과, 구조 안의 정보를 세션 경계 너머로 전달하는 것은 다른 문제였거든요. 영속성 체인이 “시스템의 몸이 살아남는 법”이었다면, 이 글은 “시스템의 기억이 살아남는 법”이에요.

돌이켜보면, 해결책 자체는 별로 복잡하지 않았어요. description을 잘 쓰자. 다만 “잘”의 기준이 “나 자신이 보기에 충분한가”가 아니라 “맥락이 없는 누군가가 읽었을 때 바로 행동할 수 있는가”로 바뀌었을 뿐이에요.

혹시 AI에게 작업을 맡기면서 “이거 왜 하는 건데?”를 반복 설명하고 있다면 — 이슈 description에 WHY, HOW, WHERE가 있는지 한번 확인해보세요. 아마 셋 중 하나는 빠져있을 거예요.