지난주에 흥미로운 실험 하나를 봤어요. GPT-4와 Claude를 같은 레포에 넣고 서로의 PR을 리뷰하게 한 거예요. 결과는 예상보다 훨씬 시사적이었습니다. 두 모델은 스타일이나 타입 힌트 같은 표면적인 부분에서는 금방 합의했지만, 아키텍처 판단에서는 완전히 갈렸어요. GPT-4는 RetryConfig 데이터클래스, 콜백 훅, 데코레이터 변형까지 제안하며 확장성을 밀었고, Claude는 YAGNI를 들어 "25줄짜리 유틸 함수에 이런 추상화가 필요한가"라고 맞섰습니다. 그런데 정작 두 모델 중 어느 쪽도 "이게 어떤 프로젝트냐" 는 물어보지 않았어요.
이게 AI 코드 리뷰의 핵심 역설입니다. model-diff 실험(dev.to)이 보여준 건 단순한 모델 간 차이가 아니에요. GPT-4는 학습 데이터에서 가장 많이 본 '프로덕션 마이크로서비스 패턴'으로 리뷰했고, Claude는 '충분성과 절제' 쪽으로 리뷰했습니다. 둘 다 틀리지 않았어요. 단지 다른 상상 속 프로젝트에 대해 옳았을 뿐입니다. AI는 컨텍스트를 묻지 않고 확신을 가지고 의견을 냅니다. 리뷰어처럼 행동하지만, 실제로는 자기 학습 분포를 반영하고 있는 거예요.
같은 맥락에서 ai-score라는 CLI 도구 실험도 눈에 띄었습니다(dev.to). 개발자가 6개월치 자신의 코드를 돌려봤더니 평균 AI 비율이 81~89%, 그리고 ai-score 툴 자체가 94% 가 나왔어요. 이 숫자가 주는 불편함은 단순히 "AI가 많이 썼네"가 아닙니다. 개발자 본인이 코드를 보면서 "이 변수명을 내가 지었나, Claude가 지었나"를 구분하지 못하게 됐다는 거예요. 판단의 귀속이 흐려지고 있는 겁니다. AI 어시스턴트와 함께 일한 결과물이 분명히 '내 코드'인데, 그 코드에 담긴 판단이 온전히 '내 판단'인지 알 수 없게 된 상황이에요.
이게 팀 리드 입장에서 제일 중요한 시그널입니다. 코드 작성 비용은 이제 거의 0에 수렴하고 있어요. Simon Willison이 정리한 것처럼(geeknews), 한 명의 엔지니어가 여러 에이전트를 병렬로 돌리며 구현·리팩터링·테스트·문서화를 동시에 처리할 수 있는 시대가 됐습니다. 하지만 Hacker News의 반응이 정확히 짚었듯, "프로그래밍은 싸졌지만 소프트웨어 엔지니어링은 여전히 비싸다." 코드 한 줄은 싸도, 그 코드가 올바른 문제를 올바른 방식으로 해결하고 있는지 검증하는 비용은 그대로입니다.
Claude Code가 디자인 워크플로우를 바꾸고 있다는 관찰도 같은 방향을 가리킵니다(geeknews). 디자이너가 Figma 목업 없이 바로 Claude Code로 작동하는 코드를 만들고 PR을 직접 제출하는 흐름이 실제로 작동하고 있어요. 핸드오프가 사라지고, 중간 산출물이 없어지고, '디자이너'와 '프론트엔드 개발자'의 경계가 흐려지고 있습니다. 이건 단순한 툴 변화가 아니라 역할의 재정의예요. 팀 리드가 기존의 역할 경계를 기준으로 팀을 구성하고 평가하면, 이미 뒤처지는 겁니다.
그렇다면 리드는 뭘 해야 하나. 저는 세 가지가 핵심이라고 봅니다.
첫째, 컨텍스트 설계자가 되어야 합니다. AI는 컨텍스트를 묻지 않아요. GPT-4가 마이크로서비스용 아키텍처를 3인 스타트업 코드베이스에 들이밀 때, 그걸 걸러내는 건 사람이 해야 합니다. 리드가 팀원과 AI 모두에게 "우리가 지금 어떤 문제를, 어떤 규모로, 어떤 제약 안에서 풀고 있는지"를 명확하게 설계해 줘야 AI 생성물의 품질이 올라가요. 프롬프트에 팀 규모, 배포 환경, 프로토타입인지 프로덕션인지를 명시하는 것, 그게 지금 리드의 핵심 스킬입니다.
둘째, 검증의 기준을 정의해야 합니다. ai-score가 94%인 코드가 나쁜 코드가 아닐 수 있어요. 하지만 그 코드가 왜 그런 판단을 했는지, 어떤 전제 위에 서 있는지 팀 내에 아는 사람이 있어야 합니다. 코드 리뷰의 초점이 '스타일 교정'에서 '판단의 귀속 확인'으로 이동해야 해요. "이 설계 결정은 누가, 왜 내렸는가"를 추적할 수 있는 팀 문화가 필요합니다.
셋째, 막히는 경험을 설계해 줘야 합니다. ai-score 실험에서 개발자가 가장 아파했던 부분은 '막혔을 때 판단을 쌓는 경험'을 AI가 단락시켜버렸다는 거예요. 팀원들이 AI를 우회로로만 쓰다 보면 판단 근육이 안 생깁니다. 의도적으로 AI 없이 설계해보는 세션, AI 생성물을 처음부터 직접 재작성해보는 경험, 이런 것들을 팀 문화로 넣어야 해요.
코드 생산 비용이 0에 가까워질수록, 역설적으로 '무엇을 만들지 결정하는 판단'의 가치는 올라갑니다. Hacker News에서 누군가 말했듯 굴착기가 생겼다고 아무 데나 구덩이를 파서 부자가 되는 게 아니에요. 도구가 싸졌다고 가치가 자동으로 생기지 않습니다. AI-First 팀의 리드는 코드를 덜 짜는 사람이 아니라, AI가 짠 코드가 올바른 문제를 올바르게 풀고 있는지 판단하는 사람이에요. 그 판단의 품질이 팀의 속도와 신뢰성을 결정합니다.