AI-First 팀의 가장 큰 고통: 세션이 끝나면 기억도 끝난다
Claude Code를 팀에 도입하면 초반엔 다들 놀랍니다. 코드 생성 속도, 디버깅 보조, 리팩터링 제안—체감 효율이 확실하거든요. 그런데 며칠 지나면 반드시 이 불만이 터져 나옵니다. "어제 설명한 아키텍처 결정, 오늘 또 설명해야 해요?"
이건 개인의 습관 문제가 아닙니다. Claude Code의 구조적 설계 문제입니다. 각 세션은 완전한 백지에서 시작합니다. 어제 팀이 합의한 '왜 optimistic locking을 선택했는가', 지난주에 삽질하며 찾아낸 Docker 볼륨 마운트 함정—전부 증발합니다. dev.to에 올라온 실험 리포트에 따르면, 한 개발자는 4시간짜리 DB 마이그레이션 디버깅 세션을 통째로 날린 뒤 이 문제를 본격적으로 파고들었습니다.
팀 단위로 Claude Code를 쓴다면, 이 문제는 개인 생산성 손실을 넘어 팀 전체의 컨텍스트 동기화 실패로 번집니다. 테크 리드 입장에서 이걸 그냥 놔두면 안 됩니다.
문제를 정확히 나눠야 해결책도 보인다
세션 메모리 문제는 사실 두 가지가 섞여 있습니다.
- 세션 내 컴팩션 문제: 대화가 길어지면 Claude가 앞쪽 내용을 압축해버립니다. 불편하지만 어느 정도 감수할 수 있어요.
- 세션 간 단절 문제: 터미널을 닫으면 끝입니다. 다음 날 새 세션은 전혀 다른 Claude입니다. 이게 진짜 킬러입니다.
대부분의 팀이 직면하는 건 후자입니다. 그래서 해결책도 이 두 문제를 구분해서 접근해야 합니다.
지금 쓸 수 있는 세 가지 접근법과 그 한계
같은 dev.to 리포트에서 세 가지 방식을 실험한 결과를 정리하면 이렇습니다.
① CLAUDE.md + 노트 시스템: 프로젝트 루트에 CLAUDE.md를 두고 notes/YYYY-MM-DD.md로 세션 요약을 기록하는 방식입니다. 잘 쓰면 효과가 있지만, 피곤할 때—정작 컨텍스트가 가장 중요한 순간—기록을 건너뛰게 됩니다. 팀에서 이걸 규율로 강제하는 건 현실적으로 어렵습니다.
② SQLite MCP 메모리 레이어: remember()/recall() 도구를 통해 명시적 지식을 세션 간 저장합니다. 내구성은 좋지만 Claude가 알아서 저장하지 않습니다—프롬프트로 유도해야 합니다. 더 큰 문제는 '우리가 이 결정을 내릴 때 코드가 어떤 상태였는가'를 연결하지 못한다는 점입니다.
③ Git 상태 연동 세션 리플레이(Mantra): AI 코딩 세션을 녹화하고 각 메시지를 해당 git 커밋 상태에 연결합니다. 컨텍스트를 사후에 복구하는 데는 가장 강력하지만, Claude에 자동으로 주입하지는 않습니다—리뷰 후 수동으로 프롬프트를 구성해야 합니다.
현실적인 조합은 이 세 가지를 레이어로 쌓는 겁니다. SQLite MCP로 명시적 결정을 저장하고, Mantra로 전체 세션 이력을 보존하고, CLAUDE.md엔 비자명한 핵심만 짧게 남깁니다. 완벽하진 않지만 컨텍스트 회복 속도를 크게 높일 수 있어요.
flat file의 한계: CLAUDE.md가 200줄을 넘는 순간
dev.to에 공개된 OMEGA 프로젝트 분석은 CLAUDE.md 방식의 구조적 한계를 더 명확하게 짚습니다. 파일이 커지면 다섯 가지 문제가 겹칩니다: 검색 불가, 자동 캡처 없음, 무한 성장(중복/충돌 미감지), 프로젝트 간 학습 단절, 체크포인트 없음.
"REST 사용"과 "WebSocket으로 마이그레이션"이 같은 파일 안에 공존하고, Claude는 어느 쪽을 읽느냐에 따라 다른 결정을 내립니다. 팀이 공유하는 CLAUDE.md라면 이 충돌은 더 자주, 더 크게 발생합니다.
OMEGA는 이를 MCP 서버로 해결하려는 시도입니다. 입력된 메모리를 SHA256 해시→임베딩 코사인 유사도 3단계 중복 검사로 거르고, 벡터 검색+FTS5+시간 감쇠를 조합해 검색합니다. LongMemEval 벤치마크에서 95.4%라는 수치를 냈고, 전부 로컬에서 동작합니다(API 키 불필요). 팀 표준 메모리 레이어를 고민한다면 참고할 만한 설계입니다.
게임 체인저: Anthropic의 Auto-Memory 공식 출시
그리고 Anthropic이 직접 움직였습니다. GeekNews를 통해 알려진 Claude Code의 Auto-Memory 기능 추가가 이 판을 바꿉니다.
핵심은 역할 분리입니다: - CLAUDE.md: 사용자가 작성하는 지침 파일. Claude가 따라야 할 규칙과 선호 설정. - MEMORY.md: Claude가 스스로 업데이트하는 메모 공간. 세션 중 학습한 내용을 자동 기록.
사용자가 "remember..."라고 요청하면 MEMORY.md에 저장하고, 이후 세션에서 별도 입력 없이 재활용합니다. /memory 명령으로 비활성화도 가능합니다.
이전까지는 서드파티 MCP 서버나 수동 노트에 의존해야 했던 기능을 Anthropic이 공식으로 내장한 겁니다. 팀 표준 세팅 입장에서 보면, 이제 기본 레이어는 MEMORY.md로 확보하고, 그 위에 프로젝트별 규칙(CLAUDE.md)과 고급 메모리 레이어(필요시 OMEGA나 SQLite MCP)를 얹는 구조가 현실적입니다.
팀 표준 세팅: 지금 바로 적용할 수 있는 레이어 구조
AI-First 팀 기준으로 제가 권장하는 Claude Code 표준 세팅은 이렇습니다.
Layer 0 — Auto-Memory (기본 활성화): Anthropic이 내장한 MEMORY.md 자동 저장. 별도 설정 없이 켜두세요. 팀원 개인 레벨에서 컨텍스트 지속성의 기본을 담당합니다.
Layer 1 — CLAUDE.md (팀 규칙 레지스트리): 코딩 스타일, 아키텍처 원칙, 금지 패턴 등 변하지 않는 팀 규약을 짧고 명확하게 유지합니다. 200줄 넘기면 구조를 다시 검토하세요.
Layer 2 — Git 연동 세션 이력 (Mantra 등): 중요한 결정이 있었던 세션을 복구할 때 쓰는 레이어입니다. 수동이지만 "왜 그렇게 결정했는가"를 재구성하는 데 가장 강력합니다.
Layer 3 — 구조화 메모리 서버 (선택): 프로젝트 복잡도가 높거나 팀 규모가 커질 때 OMEGA 같은 MCP 기반 메모리 레이어를 추가합니다. 크로스 프로젝트 학습과 자동 캡처가 필요한 팀에 적합합니다.
도구 선택: Claude Code는 여전히 옳은 베팅인가
dev.to의 4개 CLI 비교 리뷰도 참고할 만합니다. Gemini CLI는 랜덤 HTTP 에러와 느린 응답으로 신뢰도 미달, Copilot CLI는 월 한도가 병목, OpenCode는 속도와 단순함으로 좋은 인상을 줬지만 통합 생태계는 아직 Claude Code에 못 미칩니다. Claude Code는 5시간 리셋 한도, PLAN 모드, GitHub/Slack 등 서드파티 통합에서 팀 협업 도구로서의 강점이 뚜렷합니다. 메모리와 CPU를 많이 먹는다는 단점은 실제이고, 긴 세션에서 프리징이 발생한다는 리포트도 있습니다—팀 도입 시 하드웨어 스펙을 함께 고려하세요.
전망: 메모리 문제는 해결되는 중이다
Auto-Memory 공식 추가는 Anthropic이 세션 단절 문제를 직접 인식하고 제품 레벨에서 대응하기 시작했다는 신호입니다. 아직 완전한 네이티브 세션 지속성—지난 세션 관련 이력을 자동으로 끌어오는—은 아니지만, 방향은 맞습니다.
팀 리빌딩 관점에서 지금 이 시점이 오히려 좋은 타이밍입니다. 메모리 레이어를 직접 설계해보면서 팀원들이 'Claude Code가 어떻게 컨텍스트를 다루는가'를 이해하게 됩니다. 도구를 그냥 쓰는 팀과 도구의 한계를 알고 설계하는 팀은 6개월 후 AI 활용 역량에서 큰 차이가 납니다.
AI는 동료입니다. 동료가 기억을 잃지 않도록 환경을 설계하는 게 테크 리드의 역할입니다.