Claude Code를 팀에 도입했는데 매번 새 세션을 열 때마다 같은 결정을 반복해서 설명하고 있다면, 그건 모델 문제가 아니다. 메모리 설계 문제다. 에이전트를 '돌리는 것'과 '팀 워크플로우에 통합하는 것' 사이의 간극은 생각보다 구체적인 곳에 있다.
세 가지 메모리 레이어, 경쟁이 아니라 역할 분리다
dev.to의 Vibsync 팀 아티클은 Claude Code의 컨텍스트 관리 도구 세 가지—CLAUDE.md, Git, MCP 메모리 서버—를 흔히 경쟁 관계로 오해하지만, 실제로는 각각 다른 레이어를 담당한다고 정리한다. 이 구분이 명확하지 않으면 팀은 이 셋을 뒤섞어 쓰다가 오히려 혼선만 늘어난다.
CLAUDE.md는 '규칙집'이다. 코딩 스타일, 아키텍처 컨벤션, 테스트 실행 명령어처럼 거의 바뀌지 않는 repo-scoped 규칙을 담는다. 자동으로 읽히고, 코드와 함께 버전 관리된다. 그러나 정적이다. "오늘 아침에 뭘 결정했는가"를 담을 수 없고, 다른 repo를 넘나들 수도 없다.
Git은 '코드의 진실 공급원'으로만 써야 한다. 일부 팀이 Git에 Markdown 볼트나 공유 결정 로그를 커밋해서 에이전트 메모리처럼 쓰려 하는데, 이건 머지 컨플릭트를 자초하는 설계다. "이 모듈 아직 건드리지 마" "결제 담당은 Carol" 같은 실시간 협업 컨텍스트는 diff가 없다. Git은 poll-based라서 에이전트는 fetch 이후에야 업데이트를 본다—결정이 내려진 그 순간이 아니라.
MCP 메모리 서버가 '라이브 컨텍스트' 레이어다. 에이전트가 내린 결정을 즉시 기록하고, 다른 머신의 다른 에이전트가 접속하자마자 그 결정을 받아볼 수 있다. Claude Code, Cursor, Codex 어디서든 읽고 쓸 수 있는 벤더 중립 표준(MCP, Model Context Protocol)이다. 코드 저장소를 대체하려 해서는 안 되고, 좋은 MCP 서버라면 그러지 않는다.
한 줄 요약: Git은 코드, CLAUDE.md는 규칙, MCP는 실시간 팀 컨텍스트. 이 세 레이어는 조합해서 쓰는 것이지 선택의 문제가 아니다. 새 Claude Code 세션을 열 때마다 같은 결정을 다시 설명해야 한다면, MCP 레이어가 없는 것이다.
LLM 파이프라인 CI, '더 많은 재시도'가 답이 아니다
메모리 설계만큼 중요한 두 번째 문제가 있다. Claude Code가 생성한 코드를 포함한 LLM 파이프라인을 CI에서 어떻게 테스트할 것인가. dev.to의 또 다른 아티클(by Mukesh)이 이 문제를 3계층 전략으로 정리한다.
기존 CI는 "같은 입력 → 같은 출력"을 전제로 설계되어 있다. LLM이 들어오는 순간 이 전제가 깨진다. 팀이 흔히 택하는 두 가지 잘못된 대응이 있다: LLM 관련 코드 경로는 테스트를 거의 안 쓰거나, 정확한 문자열로 assert했다가 첫 flake에 테스트를 비활성화하거나. 둘 다 프로덕션에서 프롬프트 변경이나 모델 업그레이드가 조용히 동작을 망가뜨릴 때까지 아무것도 모르는 상태를 만든다.
Tier 1: Contract 테스트 (결정론적, PR마다 실행). 실제 모델을 절대 호출하지 않는다. 파이프라인 출력의 '형태'만 검증한다. 고정 JSON fixture를 파싱·검증 레이어에 통과시켜 필수 필드 존재 여부, 타입 일치, 스키마 준수를 확인한다. 밀리초 단위로 실행되고 API 키도 필요 없다. 실제 장애를 일으키는 버그 유형—모델이 필드를 빠뜨렸을 때 파서가 터지는 것—을 잡는 데 가장 효과적이다. 머지 블로킹 기준이 되어야 한다.
Tier 2: Replay 테스트 (결정론적, PR마다 실행). 실제 모델 응답을 한 번 녹화해 cassette 파일로 저장하고, 이후 CI에서는 네트워크 없이 재생한다. HTTP 테스트의 VCR과 동일한 개념이다. 프롬프트를 의도적으로 변경할 때는 로컬에서 재녹화 후 cassette diff를 PR에 포함시킨다—이 diff 리뷰 단계에서 리그레션을 가장 자주 잡는다. 실제 모델 출력을 기준으로 파싱·비즈니스 로직을 검증하면서도 CI 속도와 비용을 지킨다.
Tier 3: Live Smoke 테스트 (비결정론적, 야간 스케줄). 실제 API를 실제 비용으로 호출한다. 목적은 하나: replay cassette가 포착하지 못한 모델 드리프트 감지. 출력 동일성이 아니라 속성으로 assert한다—응답이 유효한 JSON인가, 스키마를 만족하는가, 임베딩 기반 시맨틱 유사도가 임계값 이상인가, 토큰 사용량이 비용 예산 안에 있는가. PR 게이트에 절대 넣지 않는다. CircleCI의 scheduled workflow로 매일 밤 한 번, 결과는 사람이 트리아지한다.
한 가지 실용적인 디테일: 비용 상한 체크 스크립트를 pytest 호출 이전에 실행해 프롬프트 변경이 컨텍스트 윈도우를 10배 넓혔을 때 야간 청구서가 날아오기 전에 잡는다. --reruns 1 옵션으로 단일 API 타임아웃은 알람 없이 재시도하되, 두 번 연속 실패는 실제 신호로 처리한다.
설계 원칙이 먼저, 도구가 나중이다
두 전략의 공통 구조가 보인다. 메모리 설계든 CI 테스팅이든, 핵심은 레이어 분리와 각 레이어의 적합한 도구 매핑이다. MCP를 Git처럼 쓰려 하면 머지 컨플릭트가 생기고, LLM 파이프라인을 일반 함수처럼 테스트하려 하면 flaky 테스트가 쌓인다. 에이전트를 팀 워크플로우에 통합하는 것은 "AI를 켜는 것"이 아니라 컨텍스트 관리와 품질 검증을 위한 설계 결정이다.
AI-First 팀 리빌딩을 진행 중이라면 이 두 설계를 온보딩 체크리스트에 넣는 것을 권한다. Claude Code 세션을 처음 여는 팀원이 CLAUDE.md가 어디 있는지, MCP 엔드포인트가 무엇인지, CI의 어느 테스트가 PR을 블로킹하는지 알고 시작하는 것—이것이 에이전트를 '동료'로 통합하는 실질적인 첫 단계다.