AI 코딩 에이전트가 '동료'가 된 주간
이번 주 AI 개발 도구 생태계에 세 가지 움직임이 동시에 터졌습니다. Anthropic이 Claude Sonnet 4.6을 출시하면서 100만 토큰 컨텍스트 윈도우와 강화된 코딩·에이전트 능력을 내놓았고, 구글은 Gemini 3.1 Pro를 공개하며 ARC-AGI-2 추론 벤치마크를 31.1%에서 77.1%로 끌어올렸습니다. 같은 타이밍에 Andrej Karpathy가 X에서 지적한 AI 코딩 에이전트의 공통 실수 패턴이 forrestchang이라는 개발자의 손을 거쳐 CLAUDE.md라는 65줄짜리 가이드라인 파일로 정리됐고, GitHub 스타 6,500개를 돌파하며 개발자 커뮤니티를 뒤흔들었습니다. 이 세 흐름은 따로 보면 릴리즈 노트, 벤치마크 경쟁, 오픈소스 팁에 불과하지만, AI-First 팀을 운영하는 입장에서 보면 하나의 메시지로 수렴합니다. "모델 성능이 올라갈수록, 팀이 AI를 다루는 '규칙'과 '구조'가 생산성의 병목이 된다."
모델은 똑똑해졌는데, 왜 코드 품질은 안 따라오나
Claude Sonnet 4.6은 Claude Code 초기 테스트에서 이전 Sonnet 4.5 대비 70% 비율로 선호됐고, 심지어 Opus 4.5보다도 59% 비율로 더 나은 평가를 받았습니다(요즘IT 보도). 문맥을 먼저 읽고, 중복 로직을 통합하고, 성공을 잘못 주장하는 빈도가 줄었다는 피드백이 핵심입니다. Gemini 3.1 Pro 역시 코드 기반 애니메이션, 인터랙티브 3D 시뮬레이션 등 프론트엔드 코딩에서 눈에 띄는 도약을 보여줬습니다(테크튜브 보도).
그런데 Karpathy는 정확히 이 시점에 "AI 코딩 에이전트를 80% 비율로 쓰면서 발견한 공통 실수"를 공유했습니다. 모델이 아무리 좋아져도, 프로젝트 컨벤션을 모르면 게으른 코드를 생산하고, 컨텍스트가 길어지면 앞에서 합의한 설계를 잊어버리고, 한 번에 너무 많은 파일을 건드리다 사이드 이펙트를 만듭니다. 이건 모델의 지능 문제가 아니라 '일하는 방식의 정의'가 빠져 있는 문제입니다. 우리 팀에서도 Claude Code를 본격 도입한 뒤 비슷한 패턴을 겪었는데, CLAUDE.md 같은 규칙 파일 하나를 프로젝트 루트에 넣자 체감 품질이 확 달라졌습니다.
AI-First 팀이 지금 세팅해야 할 세 가지 레이어
저는 이 세 흐름을 엮어 AI-First 개발 워크플로우를 세 겹의 레이어로 정리하고 있습니다.
첫째, 모델 선택 레이어. Claude Sonnet 4.6과 Gemini 3.1 Pro가 동시에 나오면서, 작업 성격에 따라 모델을 분기하는 전략이 현실적으로 가능해졌습니다. 깊은 추론이 필요한 아키텍처 설계에는 Opus 4.6이나 Gemini 3.1 Pro의 확장 사고를 쓰고, 반복적인 코드 생성·리팩터링에는 Sonnet 4.6의 가성비를 활용하는 식입니다. Sonnet 4.6의 가격이 백만 토큰당 3/15달러로 Opus 대비 훨씬 저렴하면서도 선호도에서 앞서는 상황이니, 팀 예산 내에서 '어디에 비싼 모델을 쓸 것인가'를 정하는 것이 첫 번째 설계 포인트입니다.
둘째, 가이드라인 레이어. CLAUDE.md가 증명한 것은 간단합니다. AI 에이전트에게 매번 좋은 프롬프트를 쓰려고 에너지를 쏟는 것보다, 일하는 규칙을 한 번 정의해서 매 세션에 자동 적용하는 것이 근본적인 해법이라는 점입니다. 저희 팀은 프로젝트별로 커스텀 규칙 파일을 운영하면서, 여기에 CLAUDE.md의 범용 원칙을 베이스 레이어로 깔고 있습니다. npx skills add 한 줄이면 Claude Code에 바로 적용되고, Cursor에서는 .cursorrules로 변환해서 쓸 수도 있습니다. 이 레이어가 없으면 100만 토큰 컨텍스트 윈도우도 '긴 대화에서 방황하는 AI'를 만들 뿐입니다.
셋째, 검증 레이어. 구글의 Addy Osmani가 14년 경력에서 뽑은 교훈 중 "AI는 초안을 싸게 만들고, 취향이 비싸진다"는 문장이 이 레이어의 본질을 정확히 찌릅니다(요즘IT 보도). AI가 생성한 코드의 품질을 검증하고, 무엇을 머지하고 무엇을 버릴지 판단하는 능력 — 이것이 AI-First 시대에 개발자의 진짜 역할입니다. Sonnet 4.6이 환각과 잘못된 성공 주장을 줄였다고는 하지만, 여전히 LLM은 비결정적 시스템입니다. AI 코드 리뷰를 자동화하되, 최종 판단은 사람이 내리는 구조를 팀 프로세스로 정착시켜야 합니다.
팀 리빌딩의 진짜 과제는 '도구'가 아니라 '문화'
전자신문이 보도한 알파센스 리포트의 핵심 메시지는 직장에서 AI가 생존 조건이 되었다는 것이고, GitHub CEO가 인용한 "AI를 받아들이든지, 커리어를 떠나든지"라는 문장은 냉혹하지만 현실입니다. 그런데 제가 팀 리빌딩을 하면서 느끼는 건, 도구 도입보다 "AI한테 물어보는 걸 부끄러워하지 않는 문화"를 만드는 게 열 배는 어렵다는 겁니다.
Karpathy가 AI 에이전트의 실수를 X에 공개적으로 공유하고, 그걸 65줄짜리 파일로 정리한 커뮤니티의 속도감 — 이게 AI-First 문화의 실제 모습입니다. AI가 실수하면 숨기는 게 아니라 패턴을 찾아 규칙으로 만들고, 그 규칙을 팀 전체가 공유하는 것. Osmani가 말한 "영웅이 필요 없는 시스템"도 결국 같은 얘기입니다. AI 프롬프트를 잘 쓰는 '영웅' 한 명에 의존하지 말고, 규칙 파일과 검증 프로세스로 팀 전체의 바닥을 올리는 것이 지속 가능한 구조입니다.
전망: 모델은 분기마다, 규칙은 매주, 문화는 매일
Claude Sonnet 4.6과 Gemini 3.1 Pro는 앞으로도 분기마다 더 강력한 후속 모델에 자리를 내줄 겁니다. 하지만 팀이 한 번 잘 설계한 가이드라인 레이어와 검증 레이어는 모델이 바뀌어도 그대로 작동합니다. AI-First 팀의 경쟁력은 최신 모델을 얼마나 빨리 쓰느냐가 아니라, 모델 위에 올리는 팀의 규칙과 판단 체계가 얼마나 견고한가에서 갈립니다.
이번 주에 팀에서 당장 해볼 수 있는 건 세 가지입니다. CLAUDE.md를 프로젝트에 추가하고, Claude Sonnet 4.6과 Gemini 3.1 Pro를 작업 유형별로 분기 테스트하고, AI가 생성한 PR에 대한 리뷰 체크리스트를 한 장 만드는 것. 도구는 이미 준비돼 있습니다. 이제 우리가 일하는 방식을 업데이트할 차례입니다.