코드를 짜는 비용은 0에 수렴했다. 그런데 팀은 왜 더 바빠졌을까?
솔직히, 요즘 코드 생성 자체는 거의 공짜입니다. Claude Code든 Copilot이든, "이거 만들어줘"라고 던지면 몇 초 안에 수백 줄이 나옵니다. 그런데 이상하죠? 생산성이 올라갔다는데, 팀원들은 되려 더 바빠졌다고 합니다. Berkeley 연구가 정확히 이 지점을 찌릅니다 — AI가 비개발자의 코딩을 가능하게 했지만, 결국 엔지니어가 동료의 AI 코드를 리뷰·수정하는 데 더 많은 시간을 쓰게 됐다는 거예요. 코드 생성이 싸졌다는 건, '조용한 파손(silent breakage)'도 싸졌다는 말과 동의어입니다.
여기서 AI-First 팀이 풀어야 할 진짜 문제가 드러납니다. 생성 속도를 높이는 게 아니라, 검증과 구조의 배선을 다시 짜는 것. 최근 등장한 세 가지 실천법이 이 배선을 구체적으로 보여주고 있어서, 팀 리빌딩 관점에서 정리해 봤습니다.
1. 커밋 '전'에 AI 리뷰를 강제한다: git-lrc의 접근
dev.to에 소개된 git-lrc는 발상이 단순하지만 임팩트가 큽니다. git hook으로 걸어서, staged diff가 커밋되기 전에 Gemini API가 리뷰를 강제합니다. PR 리뷰 때 발견되던 — 혹은 더 나쁘게는 프로덕션에서 터지던 — 미묘한 로직 삭제, 느슨해진 유효성 검사, 로그에 슬쩍 끼어든 시크릿 같은 것들을 커밋 시점에서 잡겠다는 거죠.
인상적인 건 커밋 메시지에 [reviewed], [vouched], [skipped] 태그가 남는다는 점입니다. 몇 주 뒤에 팀원 누구든 git log만 보면, 어떤 변경이 리뷰를 거쳤고 어떤 게 의식적으로 건너뛴 건지 추적할 수 있습니다. AI가 코드를 쓰는 시대에, "이 코드 누가 검증했어?"라는 질문에 답할 수 있는 구조를 커밋 레벨에서 만드는 거예요. 저는 이걸 팀에 도입하면서 "AI는 가속 페달이고, git-lrc는 브레이크 시스템이다"라고 설명했는데, 꽤 직관적으로 먹혔습니다.
2. 에이전트 하나가 아니라 셋을 동시에 돌린다: 병렬 작업의 인지 비용 문제
AI 에이전트가 팀원처럼 느껴지기 시작하면, 자연스럽게 "하나 더 돌리면 안 돼?"라는 생각이 듭니다. 하나는 리팩터링, 하나는 테스트 작성, 하나는 프로토타입. 개별로는 강력한데, 병렬로 돌리면 터미널 세 개, 브랜치 세 개, 그리고 "이 터미널이 뭘 하고 있었더라?" — 인지 부하가 급격히 올라갑니다.
Parallel Code를 만든 Johannes의 핵심 통찰은 간결합니다: "각 AI 세션이 자동으로 격리된 피처 브랜치처럼 동작해야 한다." git worktree를 자동 생성하고, 세션별 시각적 경계를 두고, 생성과 폐기를 쉽게 만드는 것. tmux로 레이아웃은 잡을 수 있지만, 워크플로우 구조는 잡아주지 못한다는 지적이 정확합니다. 레이아웃은 워크플로우가 아니거든요.
이걸 팀 운영 관점에서 보면, 우리는 지금 '단일 에이전트 IDE' 시대에서 '멀티 에이전트 오케스트레이션' 시대로 넘어가는 전환점에 있습니다. Steve Yegge가 말한 AI 채택 8단계 중 Level 8 — 에이전트 오케스트레이터를 직접 구축하는 단계가 바로 이겁니다.
3. 코드가 아니라 '컨텍스트 레이어'를 읽는다
flowkater.io의 분석 글이 정리한 핵심 전환이 있습니다. Ben Shoemaker는 "더 이상 코드를 한 줄씩 읽지 않는다. 스펙, 테스트, 아키텍처를 읽는다"고 했고, Evan Armstrong은 코드 생성은 상품화됐지만 "프로덕션에서 코드를 거버닝하는 컨텍스트 레이어는 상품화되지 않았다"고 짚었습니다. AWS Serverless Plugin 사례가 이를 증명합니다 — Claude Code에 Kinesis 스트림 프로세서를 시키면 기본 설정의 코드는 나오지만, 처리량에 맞는 배치 사이즈, 부분 실패 처리, IAM 스코핑 같은 "판단"은 컨텍스트 레이어에 인코딩해야 합니다.
Kent Beck의 '복리 게임' 프레임워크가 여기서 결정적입니다. "더 나은 AGENTS.md로는 복리 게임을 이길 수 없다"는 말은, AGENTS.md나 CLAUDE.md가 쓸모없다는 게 아닙니다. 오늘의 아키텍처 결정이 6개월 뒤의 가능성을 열거나 닫는다는 사실을 AI에게 '왜'를 설명하는 방식으로 담아야 한다는 거예요. 문서가 아니라 판단을, 파라미터가 아니라 맥락을 인코딩하는 것. 이게 AI-First 팀에서 시니어 엔지니어의 핵심 역할이 됩니다.
"AI는 거울이다" — 팀 리빌딩의 출발점
스탠포드의 Jeremy Utley가 한 말이 계속 맴돕니다: "게으르고 싶은 사람에게는 게으름을, 예리해지고 싶은 사람에게는 날카로움을 도와준다." Anthropic 연구에서도 같은 AI를 쓰면서 사용 방식에 따라 학습 결과가 극명하게 갈렸습니다. 통째로 맡긴 사람은 가장 빠르게 끝냈지만 가장 적게 배웠고, 개념만 물어보고 직접 짠 사람은 퀴즈 점수가 월등히 높았죠.
그래서 AI-First 팀 워크플로우의 재배선은 결국 세 가지로 수렴합니다:
- 검증 시점을 당긴다 — PR 리뷰가 아니라 커밋 전에 AI 리뷰를 강제하고, 그 이력을 추적 가능하게 만든다.
- 에이전트를 구조적으로 병렬화한다 — 터미널을 늘리는 게 아니라, 격리된 워크스페이스 단위로 에이전트를 오케스트레이션한다.
- 코드 대신 컨텍스트를 엔지니어링한다 — AGENTS.md에 아키텍처 결정의 '이유', 도메인 컨벤션, 판단 기준을 명시해서 AI가 일관된 코드를 만들게 한다.
"코드를 읽을 줄 아는데 안 읽는 것과, 못 읽는 것은 완전히 다른 이야기"라는 원문의 마무리가 핵심을 찌릅니다. AI-First는 코드를 안 짜는 게 아니라, 거울에 비출 게 있는 팀을 만드는 것입니다. 도구가 아무리 좋아져도, 비출 게 없으면 거울은 빈 화면만 돌려보낼 테니까요.