AI 도구를 쓰는 팀과 AI로 설계하는 팀의 차이
Claude Code를 쓰는 팀은 많다. 그런데 대부분은 비슷한 방식으로 쓴다. 채팅창 열고, 코드 붙여넣고, 결과물 확인하고, 다음 작업으로 넘어간다. 도구를 쓰는 건 맞는데, 워크플로우를 설계하지는 않는다.
최근 dev.to에 올라온 세 편의 실전 사례를 겹쳐 읽으면 패턴이 보인다. 각기 다른 문제를 다루고 있지만, 공통적으로 가리키는 방향은 하나다. AI 도구의 진짜 ROI는 도구 하나의 성능이 아니라, 여러 도구를 어떻게 조합하고 워크플로우에 구조적으로 엮느냐에서 나온다.
패턴 1: 역할을 분리하면 병렬이 가능하다
aeoptimize라는 오픈소스 CLI 개발 사례가 흥미롭다. Claude, Gemini, Copilot 세 AI를 동시에 투입했는데, 핵심은 "편의에 따라 나눈 게 아니라 역량 적합성으로 나눴다"는 점이다.
Claude는 17개 규칙 기반 스코어링 엔진과 보안 감사를 맡았다. 장문 컨텍스트 추론이 필요한 작업이다. Gemini와 Copilot은 각각 Vite, Next.js 플러그인을 담당했다. 인터페이스가 명확하게 정의된 자기완결형 컴포넌트였고, 각 AI가 해당 생태계 관용어에 익숙하다는 판단이 깔려 있었다.
테크 리드 관점에서 이건 단순한 도구 분배가 아니다. 작업의 특성(장문 추론 vs. 속도 우선 코드 생성)과 AI의 강점을 매핑하는 설계 결정이다. 팀에서 시니어 개발자가 태스크를 분해해 주니어에게 배분하는 것과 구조적으로 같다.
보안 리뷰도 눈여겨볼 부분이다. Codex를 "협력자가 아닌 공격자"로 투입해 적대적 리뷰를 돌렸고, 리다이렉트 SSRF 취약점을 포함해 HIGH 심각도 이슈 4개를 잡아냈다. 코드를 작성한 사람이 동시에 검증하면 자신의 가정을 의심하지 못한다. 독립된 AI를 리뷰어로 투입하면 그 맹점이 드러난다. 이건 AI 코드 리뷰를 팀에 도입할 때 기억해야 할 핵심 원리다.
패턴 2: 코드베이스 분석은 "태스크 퍼스트"로 시작해야 한다
Claude Code로 낯선 코드베이스를 파악하는 사례에서 가장 실용적인 인사이트가 나온다. "이 코드 좀 봐줘"는 틀린 접근이다. Claude Code는 목표를 모르면 표면적 요약만 돌려준다.
올바른 접근은 목표를 먼저 제시하고, 읽어야 할 파일을 명시하고, 아직 코드를 작성하지 말라고 지시하는 것이다. 작동하는 기존 예제를 비교 기준으로 제공하면 효과가 배가된다. "Watcher는 이미 통합돼 있고 작동 중이다. 이걸 레퍼런스로 써라"는 한 문장이 수십 줄의 문서보다 유용하다.
실제로 5개 서비스를 허브에 통합하는 작업에서 이 방식으로 2분 만에 통합 패턴, 헬스 폴링 주기, SSO 흐름, 그리고 기존 구현 간의 불일치(Watcher의 setInterval이 실패 시 재시도를 하지 않는 버그)까지 찾아냈다는 사례는 설득력이 있다.
팀 온보딩에 직접 적용 가능한 패턴이다. 신규 팀원이 레거시 코드베이스에 투입됐을 때 "이 태스크를 수행하려면 무엇을 알아야 하는가"를 중심으로 Claude Code와 세션을 설계하면, 문서가 없거나 오래된 프로젝트에서도 온보딩 시간을 대폭 단축할 수 있다.
패턴 3: 컨텍스트는 설계해야 유지된다
7개 프로젝트를 Claude Code로 동시에 운영하는 사례는 컨텍스트 관리를 "운영 엔지니어링" 수준으로 다룬다. 핵심 구조는 단순하다. 5계층 컨텍스트 피라미드(CLAUDE.md → MEMORY.md → knowledge/ → 프로젝트별 BACKLOG → daily 로그)와 이를 자동으로 유지하는 훅 시스템이다.
주목할 설계 결정이 몇 가지 있다.
첫째, 200줄 제한. MEMORY.md를 200줄로 캡핑한다. Claude가 200줄 이후부터 항목을 무시하기 시작한다는 걸 수개월 운영하며 발견했다. 컨텍스트 윈도우 크기와 실제 주의 집중 구간은 다르다.
둘째, 50 교환 주기 자동 저장. 15번은 너무 잦고 100번은 너무 위험하다. 긴 세션이 컴팩션 없이 소멸하는 걸 경험한 뒤 튜닝한 수치다. 이 훅이 없으면 몇 시간 분량의 작업 컨텍스트가 증발한다.
셋째, 플레인 텍스트 선택. SQLite, 벡터 임베딩, 그래프 DB를 다 검토하고 마크다운을 선택했다. git, 백업, 에디터 교체, Claude Code 업데이트 중 어느 상황에서도 살아남는 유일한 포맷이기 때문이다.
Anthropic의 엔지니어들이 만든 훅 시스템(PreToolUse, PostToolUse, SessionStart, SessionEnd)을 기반으로, Cole Medin의 claude-memory-compiler와 커뮤니티의 패턴을 조합해 구성한 시스템이라는 점도 솔직하게 밝히고 있다. 이 투명성 자체가 팀에서 이 시스템을 도입할 때 커스터마이즈할 지점을 명확하게 보여준다.
테크 리드가 지금 당장 적용할 수 있는 것
세 패턴을 팀 수준으로 번역하면 실행 우선순위가 나온다.
단기(이번 주): CLAUDE.md 작성을 팀 온보딩 체크리스트에 넣어라. 코드베이스 분석 세션을 설계할 때 태스크 퍼스트 템플릿을 표준화하라. 한 번 분석한 아키텍처 결정은 CLAUDE.md에 누적하라. 이게 없으면 다음 세션마다 같은 분석을 반복한다.
중기(이번 달): AI 역할 분배를 명시적으로 설계하라. 장문 추론이 필요한 아키텍처·보안 리뷰는 Claude에게, 프레임워크별 관용어가 중요한 컴포넌트 생성은 해당 생태계에 강한 모델에게. 적대적 리뷰어를 워크플로우에 포함시켜라. 코드를 작성한 AI와 다른 AI가 보안 관점에서 검토하게 하는 것이 팀 리뷰보다 SSRF 같은 구조적 취약점을 먼저 잡는다.
장기(다음 분기): 컨텍스트 관리를 팀 인프라로 격상하라. 7개 프로젝트 동시 운영 사례의 훅 시스템은 개인 생산성 도구지만, 이 구조를 팀 단위로 확장하면 프로젝트 전환 비용과 온보딩 비용을 동시에 줄일 수 있다.
워크플로우 설계가 AI ROI를 결정한다
솔직히 말하면, 세 사례 모두 AI 도구 자체의 성능 이야기가 아니다. Claude가 얼마나 똑똑한지, Gemini가 얼마나 빠른지를 증명하는 사례가 아니다. AI를 어떻게 구조화해서 쓰느냐가 결과를 결정한다는 이야기다.
역할 분리, 태스크 퍼스트 프롬프팅, 컨텍스트 지속성—이 세 가지는 결국 같은 원칙의 다른 표현이다. AI는 도구이고, 도구의 효과는 사용 방식이 결정한다. 팀에 AI를 붙이는 것과 AI-First로 워크플로우를 설계하는 것의 차이가 여기에 있다.
학습 곡선에 대해서는 냉정하게 봐야 한다. 특히 컨텍스트 관리 시스템은 초기 설정 비용이 무시할 수준이 아니다. 200줄 제한이나 50 교환 주기 같은 수치는 수개월의 운영 경험에서 나온 것이다. 팀 전체가 이 수준으로 올라오려면 시간이 걸린다. 하지만 그 비용을 미리 계산하고 투자하는 팀과 그렇지 않은 팀의 6개월 후 생산성 격차는 상당할 것이다.