티켓 하나, 메인세션 하나

AI로 기능 하나를 만들 때, 메인세션은 티켓 단위로 연다. 요구사항 구체화부터 구현, 리뷰 반영 완료까지 같은 세션이 이어진다. 그 세션의 context를 얼마나 깨끗하게 지키느냐가 결과물 품질을 결정한다.

Context가 차면 AI가 대강 마무리한다

Anthropic이 반복해서 말하는 관찰이 있다. context를 적게 쓸수록 결과물이 좋아진다. 반대로 context가 차오르기 시작하면 AI가 서둘러 끝내려는 경향을 보인다. 실수가 늘고, 대충 봉합하고, “이 정도면 됐다”로 수렴한다.

그러니 메인세션의 토큰 공간은 금이다. 이번 작업의 원재료 — 요구사항, 설계, 구현 — 에만 써야 한다. 문서화나 평가 기준 추출 같은 부수 작업은 다른 세션에서 해야 한다.

1단계: 메인세션이 요구사항과 설계를 한다

먼저 메인세션에서 요구사항을 구체화하고 아키텍처를 설계한다. 이게 세션의 원재료다. 설계가 끝난 시점의 메인세션에는 “왜 이 선택을 했는가”에 대한 가장 생생한 맥락이 담겨 있다.

2단계: Fork해서 설계 의도를 남기고 버린다

설계가 끝나면 메인세션을 fork한다. Fork한 쪽에서 설계 의도 문서를 쓰고 ADR을 업데이트한 뒤, fork한 세션은 폐기한다.

왜 굳이 fork인가. 같은 메인세션에게 “설계 의도 써줘”라고 시키면 문서 쓰는 작업으로 context가 오염된다. 문서화는 기억을 꺼내는 작업인데, 그 과정 자체가 구현에 쓸 공간을 갉아먹는다.

왜 문서만 넘겨서 새 세션을 파지 않는가. 문서에는 담기지 않는 암묵적 맥락이 늘 남는다. “이 선택을 고민하다 버린 대안”, “이 이름을 고른 이유”처럼 문서화되지 않은 배경이 설계자 머릿속에 있다. 사람이 문서를 한번 검수해도 완벽하지 않다. Fork는 그 순간의 설계 의도를 그대로 담는 가장 가까운 방법이다.

Fork는 긴 논의 전반에 일반화된다

Fork는 설계 의도 기록에만 쓰는 도구가 아니다. UI 구조 결정처럼 합의가 오래 걸리는 논의를 메인세션에서 끌고 가면, 검토하다 버린 안과 반복된 중간 시안이 전부 context에 쌓인다. 결과물을 만들 시점에는 이미 세션이 뿌옇다.

이런 대화는 fork에서 끝내고 결론만 메인세션에 들여온다. 일반 원칙은 단순하다: 길어질 가능성이 있는 논의는 fork에서 하고, 결과만 가져온다.

3단계: Sub-agent가 평가 기준을 뽑는다

별도 sub-agent가 이번 작업에 필요한 coding convention과 ADR을 찾아 code-quality-guide.md로 정리한다. 사람이 이 가이드를 검토한다.

왜 sub-agent인가. Coding convention과 ADR은 프로젝트가 오래될수록 커진다. 전체를 메인세션에 집어넣으면 대부분은 이번 작업과 무관한 규칙이다. Context 낭비다. 별도 세션에서 뽑은 요약본만 메인세션이 받으면, 이번 티켓에 필요한 부분만 들어온다.

`code-quality-guide.md`는 두 번 쓰인다

같은 가이드가 라이프사이클의 두 지점에서 재사용된다.

구현 단계 — 메인세션이 구현할 때 참고한다
리뷰 단계 — 별도 리뷰 agent가 판정 기준으로 쓴다

같은 기준으로 구현하고 같은 기준으로 검증한다. 코드는 만들어지는 순간부터 평가 기준을 알고 있다.

AI 리뷰가 처음엔 사람 리뷰만 못했던 이유

초기에 AI 코드 리뷰가 동료 리뷰보다 못하게 느껴졌던 데에는 이유가 있다. AI에게 그냥 “코드 봐줘”라고만 시켰기 때문이다. 실제로 사람 동료는 리뷰할 때 세 가지 암묵적 맥락을 쥐고 있다.

기술 조직이 마음속으로 공유하는 “예쁜 코드”의 기준 — 문서화되지 않은 스타일 감각
이 작업 설계자의 구체적 의도 — 왜 이렇게 짜기로 했는가, 왜 다른 방식은 버렸는가
모르겠으면 설계자에게 가서 묻는 경로 — 암묵 지식을 해석하는 채널

AI에게는 이 셋이 없다. 그래서 리뷰가 피상적이다. 이름이 이상하다, 주석이 없다 수준의 관찰만 돌아온다.

이 맥락을 명시 자산으로 외재화한 게 다음의 두 문서다. 조직의 스타일 감각은 code-convention.md로, 설계자의 의도는 adr.md로 끌어낸다. 세 번째(물어보기)는 ADR이 누적되어 있으면 대부분 해소된다 — 지금 궁금한 결정의 이유는 과거 비슷한 결정의 ADR에 이미 적혀 있을 가능성이 높다.

리뷰 기준은 두 문서로 충분하다

code-convention.md — 언제나 참고하는 코딩 지침. 한 프로젝트에 여러 언어가 쓰이면 여러 개가 될 수 있다
adr.md — 기술적 결정 기록. 결정한 결과만이 아니라 무엇을 고민했고 왜 이걸 골랐는지가 계속 누적된다. 시간이 지나면 커진다

이 둘을 리뷰 agent에게 함께 넘기면 사람 동료가 쥐고 있던 맥락을 AI가 그대로 쥐게 된다. 이 상태의 AI 리뷰는 사람이 쓴 리뷰와 구별이 어렵다.

리뷰 병목이 사라진다

이 구조가 실제로 바꾸는 건 사람의 역할이다.

사람의 리뷰는 작업 전에 끝난다 — 설계 의도 문서 검토, 평가 기준 검토 두 번. 작업 후 코드 리뷰는 별도 agent가 새 세션을 파서 한다. 세션이 분리되어 있기 때문에, 남이 읽는 것과 거의 같은 방식으로 코드를 본다.

보안이나 결제처럼 중요한 영역은 여전히 사람이 리뷰할 수 있다. 하지만 그런 영역의 판단 기준도 ADR에 잘 써두면 AI가 대부분 잡는다. ADR을 놓치지 않고 쌓는 규율이 사람 리뷰 없이 굴러가는 시스템의 전제조건이다.

리뷰 반영은 메인세션이 한다

리뷰 피드백을 받으면 메인세션으로 돌아가서 반영한다. 구현한 session이 그대로 수정까지 들고 있어야, 왜 그렇게 짰는지를 안 잃는다. 그래서 메인세션은 리뷰 반영 완료까지 유지된다.

이게 “메인세션 = 티켓 단위”의 정의다.

전체 흐름

요구사항 + 설계                 [메인세션]
    │
    ├─ fork → 설계의도 + ADR 갱신 → 폐기       [fork]
    │
    ├─ sub-agent → code-quality-guide.md       [별도 세션]
    │         ↓
    │      사람 검토
    │
구현                              [메인세션 + guide]
    │
    ├─ 리뷰 agent → 리뷰 리포트                [별도 세션 + guide]
    │
리뷰 반영                         [메인세션]
    │
    완료

메인세션은 설계 → 구현 → 리뷰 반영만 담당한다. 문서화와 리뷰는 전부 밖에서.

Takeaway

AI 워크플로우 설계의 핵심 질문은 “어떤 context를 어느 세션에 넣을까”다. 한 세션에 전부 넣으면 AI가 서두른다. 쪼개면 각 세션이 자기 일만 본다.

메인세션을 티켓 단위로 유지하되, 메인세션에는 이번 작업에 필요한 것만 넣는다. 나머지는 fork거나, sub-agent에게 맡기거나, 별도 리뷰 세션이 가져간다. 결과적으로 사람은 코드 리뷰 병목에서 풀려나고, 대신 설계 의도와 평가 기준이라는 더 앞단에 시간을 쓴다.

Sources

관련 라이브 영상 — YouTube