Claude Code를 팀에 도입했다고 해서 워크플로우가 바뀌는 건 아니다. 도구를 켜는 것과 팀 프로세스에 실제로 뿌리내리는 것은 완전히 다른 문제다. 요즘 현장에서 수렴되는 세 가지 실전 패턴—레거시 코드 테스트 자동화, 에이전트 반복 실수 구조 해결, Ultraplan 멀티에이전트 계획 분리—을 엮으면, Claude Code를 팀이 신뢰할 수 있는 수준으로 운영하기 위한 설계 원칙이 드러난다.
아무도 건드리지 않는 그 모듈, 이제 테스트를 붙일 수 있다
레거시 코드베이스에는 반드시 그런 모듈이 있다. 프로덕션에서 돌아가고, 핵심 비즈니스 로직을 건드리며, 테스트가 단 한 줄도 없는 것. dev.to에 공유된 실전 워크플로우에 따르면, Claude Code로 이 문제를 풀 때 가장 흔한 실수는 "코드를 이해했다고 가정하고 테스트를 짜는 것"이다. 그 가정이 틀리면 테스트는 통과하지만 프로덕션은 터진다.
올바른 접근은 Characterization Test 우선 전략이다. 코드가 '해야 하는 것'이 아니라 '실제로 하고 있는 것'을 먼저 기록한다. Claude Code에 invoice.py의 모든 함수, 입출력, 사이드 이펙트를 분석하게 하고, 각 엣지 케이스에 대해 실제 출력값을 그대로 단언(assert)하는 테스트를 생성한다. 결과가 틀려 보여도 일단 현재 동작을 캡처하는 것이 목적이다. 그 다음 갭 분석 단계에서 Claude Code가 "DB 접근 불가 시 에러 핸들링 없음", "이메일 실패 시 조용한 실패" 같은 고위험 미커버 경로를 우선순위별로 뽑아준다. 여기서 비로소 '원하는 동작'을 정의하는 Behavior Test를 작성한다. 이 테스트는 처음엔 실패한다. 그게 맞다. 코드를 고치는 방향을 정의하는 것이니까.
팀 운영 관점에서 이 워크플로우의 핵심은 Characterization Test를 리팩토링 후에도 삭제하지 않는 것이다. 이것이 곧 회귀 방지 스위트가 된다. 2,000줄짜리 레거시 모듈도 이 흐름을 따르면 "아무도 건드리지 않던 모듈"에서 "안전하게 배포할 수 있는 모듈"로 전환된다.
에이전트가 같은 실수를 반복하는 건 AI 문제가 아니라 인프라 문제다
dev.to의 Authora 팀이 진단한 패턴은 날카롭다. AI 코딩 에이전트가 동일한 버그를 세 파일에 각각 다른 방식으로 "수정"하거나, 다른 에이전트가 앞선 변경을 모르고 롤백하는 사태—이건 에이전트가 코딩을 못해서가 아니다. 지속적 정체성, 공유 메모리, 안전한 툴 경계 세 가지가 없는 환경에 에이전트를 던져놓은 시스템 설계 실패다.
대부분의 에이전트 워크플로우는 아직 이 구조다: Human 프롬프트 → 에이전트 세션 → 툴/파일/API → 코드 변경. 여기엔 에이전트가 "어제 자신이 뭘 바꿨는지", "다른 에이전트가 지금 같은 파일을 건드리는지", "어떤 툴 호출이 승인된 것인지" 알 방법이 없다. 세션이 끝나면 모든 컨텍스트가 사라지고, 다음 세션은 백지에서 같은 판단을 반복한다. MCP가 툴 호출을 표준화하면서 이 반복 비용은 오히려 더 저렴해졌고, 잘못된 액션의 재시도도 쉬워졌다.
해결책은 "더 나은 프롬프트"가 아니다. 지루하지만 정확한 답은 에이전트를 프로덕션 서비스처럼 설계하는 것이다: 세션마다 검증 가능한 에이전트 정체성 부여, MCP 엔드포인트의 스코프 제한과 인증 강제, 파일·태스크 단위 락(lock)과 소유권 할당, 민감한 액션(배포·삭제·시크릿 접근)에 대한 명시적 승인 게이트, 그리고 에이전트별 툴 호출 감사 로그. 이 인프라가 갖춰지면 "왜 AI가 또 이러는 거야?"가 "이 에이전트 롤은 그 액션 권한이 없고, 무슨 일이 있었는지 정확히 안다"로 바뀐다. 실패 모드가 추적 가능해지는 것이 신뢰의 시작이다.
Ultraplan: 계획을 클라우드로 분리해 병목을 제거하다
Anthopic이 Claude Code에 추가한 Ultraplan은 위의 두 문제—실행 전 검토 부재, 단일 에이전트의 논리 오류—를 아키텍처 수준에서 건드린다. 기존에는 복잡한 리팩토링을 요청하면 터미널 세션이 AI의 파일 탐색과 계획 수립에 통째로 묶였다. Ultraplan은 이 계획 단계를 클라우드 원격 세션으로 분리한다. /ultraplan 명령 하나로 작업이 백그라운드로 넘어가고, 개발자는 그 사이에 다른 브랜치 작업이나 테스트 실행을 계속할 수 있다.
내부 구조는 멀티에이전트다. 코드베이스를 독립적으로 탐색하며 서로 다른 접근법을 제안하는 탐색 에이전트 3개가 병렬로 돌고, 비평 에이전트 1개가 보안 결함·아키텍처 일관성·잠재적 회귀 오류를 검토한다. 단일 에이전트가 처음부터 끝까지 혼자 판단할 때 발생하는 논리적 오류를 구조적으로 줄이는 설계다. 대형 저장소에서 한 서비스 변경이 연쇄 영향을 미칠 때 특히 유효하다.
팀 운영에서 주목할 점은 계획의 투명성이다. 생성된 계획은 claude.ai 브라우저 인터페이스에서 섹션별로 검토하고, 특정 줄에 인라인 코멘트로 수정을 요청하거나 우려를 표시할 수 있다. 계획이 확정되면 클라우드에서 바로 실행해 PR을 자동 생성하거나, 로컬로 가져와 직접 실행하는 두 경로 중 선택한다. AI가 실행하기 전에 팀이 계획을 보고 개입할 수 있는 구조—이게 기존 AI 코딩 도구에서 가장 부족했던 신뢰 레이어다. 단, 코드베이스 분석이 외부 서버에서 이뤄지므로 보안 정책이 엄격한 환경이나 네트워크 격리 시스템에서는 도입 전 별도 검토가 필요하다.
세 패턴이 수렴하는 하나의 원칙
레거시 테스트 자동화, 에이전트 지속성 설계, Ultraplan 계획 분리—세 흐름이 가리키는 방향은 같다. Claude Code를 팀 워크플로우에 실제로 뿌리내리려면 실행 전 검토 가능성, 에이전트 행동의 추적 가능성, 점진적 신뢰 구축 이 세 축이 설계 단계부터 갖춰져야 한다. 도구를 켜는 건 하루면 되지만, 팀이 그 결과물을 신뢰하게 만드는 인프라를 갖추는 데는 훨씬 더 의도적인 설계가 필요하다. AI 코딩 도구의 ROI는 도구 자체가 아니라 그 주변의 운영 설계에서 결정된다.