Claude Code를 팀에 도입하고 나서 가장 먼저 드는 착각이 있다. '모델이 좋으니 그냥 연결하면 되겠지.' 실제로 테스트할 때는 그게 맞다. 그런데 팀이 매일 쓰는 인프라로 올라서는 순간, '그냥 연결'은 조용히 세 가지 문제를 만들어낸다. 비용 폭발, 환각(hallucination), 컨텍스트 단절. 세 기사를 같이 읽고 나서 이 문제들이 서로 무관하지 않다는 걸 확인했다. 그리고 해법도 하나의 구조로 수렴한다.
레이어 1: UX 레이어 — 에이전트를 어떻게 쓸 것인가
dev.to에 올라온 T3 Code + Claude Code + Lynkr 스택 분석 글은 이 질문에서 출발한다. "어떤 모델이 제일 좋은가?"가 아니라 "내 코딩 워크플로우에서 어느 단계가 실제로 비싼 모델을 써야 하는가?"
실제 Claude Code 세션을 들여다보면 단순한 코드 생성 요청이 아니다. 레포 탐색 → 파일 읽기 → 플랜 수립 → 툴 호출 → 코드 생성 → 실패 감지 → 재시도 → 컨텍스트 추가 → 요약. 이 루프가 한 세션에서 수십 번 반복된다. 문제는 이 모든 턴이 동일한 비싼 모델 경로를 타고 간다는 것이다. 파일 하나 요약하는 작업과 멀티파일 디버깅이 같은 비용을 쓴다. 그건 설계가 아니라 방치다.
T3 Code가 제안하는 레이어 분리의 핵심은 단순하다. UX(T3 Code) → 에이전트(Claude Code) → 게이트웨이(Lynkr) → 모델 프로바이더. 각 레이어가 독립적으로 진화할 수 있어야 한다. 게이트웨이 레이어가 없으면 모델 전환, 캐싱, 폴백, 비용 라우팅을 전부 앱 레이어에서 반복해서 구현해야 한다. Lynkr의 벤치마크가 흥미로운 이유는 숫자 자체보다 문제를 짚는 방향 때문이다. 툴 헤비 트래픽에서 53% 토큰 절감, JSON 툴 결과 87.6% 압축. 이게 가능한 이유는 코딩 에이전트 트래픽이 일반 챗과 구조적으로 다르기 때문이다. 반복적인 시스템 프롬프트, 반복적인 레포 컨텍스트, 반복적인 툴 스키마. 여기서 낭비가 쌓인다.
실행 가능성 평가를 솔직하게 하면: 게이트웨이 레이어 추가는 초기 설정 비용이 있다. 소규모 팀이 바로 이 스택을 전부 올리기는 무겁다. 하지만 '어느 턴이 비싼 모델이 필요한가'라는 질문 자체를 팀이 갖고 있어야 한다. 그 질문이 없으면 에이전트 비용은 사용량에 비례해서 선형으로 오른다.
레이어 2: 검증 레이어 — AI가 틀릴 때를 어떻게 잡을 것인가
LightShield 팀의 qa-probe 사례는 Claude Code 환각 문제를 가장 현실적으로 보여준다. 시나리오는 이렇다. 엔드포인트가 빈 배열을 반환한다. AI 어시스턴트는 상태 코드를 보고 원인을 선언한다. 그리고 멀쩡한 핸들러를 고쳐 상황을 악화시킨다.
이 팀이 파악한 핵심은 날카롭다. 빈 배열 하나에 원인이 여섯 개 있다. DB 미시딩, 피처 플래그 비활성, 프론트-백엔드 컨트랙트 불일치, 인증 토큰 누락, 428 프리컨디션, 스키마 드리프트. 상태 코드는 증거가 아니다. AI가 증거 없이 판단하면 가장 그럴듯한 답을 만들어낸다. 그게 환각의 실제 동작 방식이다.
qa-probe의 접근이 흥미로운 이유는 AI를 대체하려는 게 아니라 AI에게 읽히기 좋은 증거를 만드는 도구라는 점이다. 분석 → 프로브 → 리포트 세 단계로 실제 요청, 응답 샘플, 타이밍, 25개 카테고리 기반 근본 원인, 그리고 신뢰도를 함께 반환한다. 신뢰도가 낮으면 none을 반환하고 블러핑하지 않는다. 이걸 MCP 툴로 Claude에 연결하면 결과가 달라진다. "엔드포인트가 실패 중"이라는 맥락 대신 "DB 비어 있음, 높은 신뢰도, 증거는 이 응답"이라는 맥락을 받는다. 핸들러가 아니라 DB 시딩을 고친다.
이건 Claude Code를 팀 인프라로 쓸 때 반드시 풀어야 하는 문제다. 에이전트가 빠르게 코드를 고칠수록, 잘못된 가설 위에서 빠르게 고치는 리스크도 커진다. 검증 레이어는 에이전트를 느리게 만들려는 게 아니다. 에이전트가 올바른 레이어를 고치게 만들려는 것이다. CI 게이트에 qa-probe 같은 툴을 붙이는 방식은 내일 당장 시작할 수 있는 수준의 설계다.
레이어 3: 컨텍스트 레이어 — AI가 전체 코드베이스를 어떻게 이해할 것인가
RepoMind 구축 사례는 세 레이어 중 가장 근본적인 질문을 건드린다. AI 어시스턴트가 컨텍스트 창에 들어오는 것만 볼 수 있다면, 코드베이스 수준의 질문에는 구조적으로 답할 수 없다. "이 파일을 수정하면 뭐가 깨지는가?" "새 기여자는 어디서 시작해야 하는가?" 이런 질문은 수십 개 파일을 횡단하는 추론이 필요하다.
RepoMind 개발자가 처음 발견한 것이 있다. MCP는 툴 호출이 아니라 아키텍처 문제다. 의도적으로 틀린 계산기를 만들고 Claude에 연결했더니, Claude는 종종 자체 추론을 썼다. 모델이 언제 툴을 써야 하는지 알아야 툴이 의미가 있다. 설계 없이 MCP를 붙이는 건 동료에게 공구함을 주고 언제 뭘 쓸지 안 알려주는 것과 같다.
이 시스템이 RAG만으로 충분하지 않다는 결론에 도달한 과정도 실용적이다. 벡터 검색은 관련 코드를 찾는다. 하지만 레포는 문서가 아니라 네트워크다. 파일 간 의존성, 함수 호출 체인, 모듈 상호작용은 벡터 유사도로 잡히지 않는다. 그래서 의존성 그래프, 임팩트 분석, 크리티컬 파일 탐지 같은 레포지토리 인텔리전스 레이어를 별도로 쌓았다. 30개 이상의 레포 인식 툴, 7개의 전문 에이전트(온보딩, 설명, 임팩트 분석, 버그 조사 등)로 구성된다.
이 구조가 Claude Code 팀 인프라 설계에 주는 시사점은 명확하다. 컨텍스트를 수동으로 복붙하는 방식은 레포가 커질수록 선형으로 나빠진다. 컨텍스트 공급 자체를 시스템으로 만들어야 한다. MCP 기반으로 레포 인텔리전스를 연결하면 에이전트는 파일 내용이 아니라 코드베이스 구조를 이해하고 작업한다.
세 레이어를 하나의 설계로 읽기
세 기사가 각자 다른 문제를 다루는 것처럼 보이지만, 실제로는 같은 구조적 결함을 다른 각도에서 가리킨다. Claude Code를 레이어 분리 없이 직접 연결하면:
- UX 레이어 부재: 세션·프로젝트·비용 라우팅이 에이전트에 뒤섞인다
- 검증 레이어 부재: 에이전트가 증거 없이 가설을 행동으로 옮긴다
- 컨텍스트 레이어 부재: 에이전트가 코드베이스 수준 질문에 구조적으로 답하지 못한다
세 레이어 모두를 동시에 올릴 필요는 없다. 하지만 어떤 레이어가 지금 팀의 병목인지는 명확하게 진단해야 한다. 비용이 예상보다 빠르게 오르고 있다면 게이트웨이 레이어 부재다. 에이전트가 같은 버그를 반복해서 잘못 고친다면 검증 레이어 부재다. 에이전트에게 매번 파일을 수동으로 넣어줘야 한다면 컨텍스트 레이어 부재다.
'Claude Code 도입'이라는 말이 팀에서 나오기 시작했다면, 도구 선택보다 이 세 레이어의 설계가 먼저다. 레이어 없이 에이전트를 켜는 건 인프라 없이 서버를 올리는 것과 같다. 빠르게 뜨고, 예측 불가능하게 터진다.