50번째 세션, 나는 AI를 다시 가르치고 있었다
180개 이상의 세션을 Claude Code로 운영한 개발자가 dev.to에 올린 회고는 불편하게 솔직하다. 30번째 세션 즈음부터 이상한 일이 반복됐다. 명시적으로 금지해 둔 CSS 패턴이 다시 등장하고, 배포된 버전과 상태 파일이 서로 다른 말을 하기 시작했다. 50번째 세션에 이르렀을 때 그는 실제 작업보다 AI를 다시 오리엔테이션하는 데 더 많은 시간을 쓰고 있었다. 이게 예외적인 경험이 아니라는 게 문제다.
왜 상태는 무너지는가
이 현상에는 이름이 있다. 컨텍스트 드리프트(context drift)다. AI 코딩 에이전트는 세션이 바뀔 때마다 이전 대화를 기억하지 못한다. 컨텍스트 윈도우가 가득 차면 오래된 제약 조건이 조용히 밀려난다. 더 교묘한 문제도 있다. AI는 학습 특성상 동의하는 방향으로 반응하는 경향이 있어, 잘못된 방향으로 가고 있어도 '그래 맞아요'를 돌려주기 쉽다. 이걸 그는 "AI가 동의하는 건 당신 아이디어가 옳아서가 아니라, 동의가 기본값으로 훈련됐기 때문"이라고 정확히 짚었다.
도구 문제가 아니라 거버넌스 문제다
그가 180개 세션의 경험에서 뽑아낸 결론은 날카롭다. 이건 프롬프트 작성법의 문제도, 도구 선택의 문제도 아니다. 워크플로우의 인간 측 운영 프로토콜이 없었던 것이다. 그 결과물이 오픈소스 프레임워크 Sessioncraft다. 세션 라이프사이클 관리, 프로젝트 상태 구조화, 컨텍스트 경제(context economy), 핸드오프 브리프 설계, 메모리 편집 분류법, 스킬 설계, 그리고 실패 패턴 목록—7개 문서로 구성된 실전 거버넌스 가이드다. Claude 특화로 설계됐지만 핵심 원칙은 도구 비종속적이다.
현장 감각으로 보면 이 접근이 맞다. 우리 팀이 AI 코딩 도구를 쓰면서 가장 많이 놓치는 게 바로 이 지점이다. 세션 기록을 '나중에 정리하자'고 미루는 패키징 부채(packaging debt), 핸드오프 브리프에 제약 조건을 빠뜨리는 실수, 컨텍스트가 넘치면 뭘 먼저 잘라낼지 기준이 없는 것. 이것들이 쌓이면 세션 50에서 벌어지는 일이 일어난다.
지속 메모리: 아키텍처로 해결하는 방법
Sessioncraft가 '사람 측 운영 프로토콜'이라면, Nous Research의 오픈소스 에이전트 Hermes Agent는 아키텍처 측에서 같은 문제를 공략한다. Hermes는 로컬 SQLite와 마크다운 파일에 대화 이력, 선호 설정, 프로젝트 컨텍스트를 저장하고, 새 세션이 시작될 때 관련 메모리를 자동으로 로드한다. 탭을 닫으면 모든 걸 잊는 기존 에이전트와 구조적으로 다르다.
v0.6.0에서 도입된 프로필 기능은 팀 관점에서도 유용하다. Work 프로필과 Personal 프로필이 독립된 메모리 컨텍스트와 스킬 세트를 갖는다. 클라이언트 프로젝트 질문과 개인 작업 질문을 에이전트가 구분해서 처리한다. 로컬 실행이라 데이터가 외부로 나가지 않는다는 프라이버시 이점도 있다. 다만 트레이드오프는 명확하다—로컬 모델은 Claude Opus나 GPT 수준의 추론 품질에 미치지 못한다. 복잡한 설계 판단이 필요한 순간에는 클라우드 API를 써야 한다.
두 접근의 시사점: 설계 레이어를 분리하라
Sessioncraft와 Hermes를 함께 놓고 보면 장기 프로젝트 AI 컨텍스트 관리의 핵심 구조가 보인다.
레이어 1 — 세션 거버넌스 (사람이 설계): 세션 시작 전 상태 파일 검증, 제약 조건 명시, 핸드오프 브리프 표준화. Sessioncraft가 다루는 영역이다. 이걸 갖추지 않으면 메모리 아키텍처가 아무리 좋아도 쓸모없다. 잘못된 상태를 빠르게 기억하는 것뿐이다.
레이어 2 — 지속 메모리 (아키텍처로 설계): SQLite 기반 영속 저장, 자동 컨텍스트 로드, 프로필 분리. Hermes가 다루는 영역이다. 세션 거버넌스가 올바른 정보를 담보해 줄 때, 지속 메모리가 그걸 제대로 전달한다.
팀 도입 관점에서 학습 비용도 현실적으로 봐야 한다. Sessioncraft는 문서 기반 프로토콜이라 팀 합의와 실천 훈련이 필요하다. Hermes는 터미널 친숙도가 있으면 30분 안에 셋업되지만, 스킬 설계와 프로필 관리는 별도 학습 시간이 든다. 어느 쪽도 '설치하면 끝'이 아니다.
전망: AI 에이전트 운영은 엔지니어링 문제다
세 번째 소스(ALTK-Evolve)가 제시하는 방향도 같은 맥락에 닿아 있다. 정적인 가중치로 고정된 에이전트는 프로덕션에서 점점 드리프트한다. 진짜 해결은 에이전트가 실제 인터랙션에서 지속적으로 업데이트되는 학습 루프를 갖는 것이다. 기술적으로는 샌드박스 실행 환경, 희소 보상 신호 처리, 에피메럴 컨텍스트와 영구 가중치를 구분하는 메모리 시스템이 필요하다.
단기적으로 팀이 집중해야 할 실천은 명확하다. AI가 길을 잃는 건 도구의 한계가 아니라 운영 설계의 부재다. 세션 상태 구조화, 컨텍스트 우선순위 설계, 핸드오프 표준화—이 세 가지를 팀 운영 프로토콜로 제도화하지 않으면, 세션이 쌓일수록 AI 생산성이 아니라 AI 재교육 비용이 쌓인다. 도구를 켜는 것과 제대로 운영하는 것은 여전히 다른 엔지니어링 문제다.