두 가지 결과, 같은 도구

두 팀이 동일한 AI 모델을 사용하는 모습을 지켜보면, 완전히 다른 두 가지 결과를 목격하게 된다.

첫 번째 팀은 모델에게 화면을 만들라고 지시한다. 출력 결과는 비슷하지만 어딘가 어긋난다. 스타일링은 Figma 파일에서 벗어나 있다. 상태 관리는 건드려서는 안 될 파일까지 건드린다. 로컬에서는 빌드가 통과하지만 CI에서는 아무도 이유를 알 수 없는 실패가 발생한다. 정합성 확인도 실패한다. 엔지니어는 모델이 3분 만에 생성한 코드를 수정하는 데 3시간을 쏟는다. 다시 시도한다. 결과는 같다. AI 코딩은 아직 프로덕션에 쓸 수준이 아니라고 결론 내리고, 실험은 거기서 끝난다.

두 번째 팀은 모델에게 화면을 만들라고 지시한다. 출력 결과 역시 완벽하지 않다. 하지만 그들은 모델이 어떤 파일을 건드렸어야 하고 어떤 파일은 놔뒀어야 하는지 정확히 알고 있다. 어긋난 부분을 즉시 발견하고, 수정을 지시한 뒤 배포한다. 프로덕션에서 버그가 발생해도 당황하지 않는다. 모델에게 실패 원인을 추적하고 패치를 생성하게 한 다음 배포한다. 전체 사이클은 몇 분이면 끝난다. Reddit에 불만이 올라온다. 그것들도 똑같은 속도로, 공개적으로 수정한다.

같은 모델. 같은 프롬프트. 완전히 다른 결과.

격차는 모델이 아니다

첫 번째 팀은 도구를 탓한다. 출력이 불안정하다. 모델이 환각을 일으킨다. 생성된 코드가 취약하다. 이런 불만은 틀리지 않았다. 모델은 실제로 환각을 일으킨다. 생성된 코드는 실제로 취약하다. 하지만 두 번째 팀도 똑같은 환각과 똑같은 취약성을 마주한다. 그저 더 빨리 복구할 뿐이다.

격차는 자신감이다. 두 번째 팀은 단순히 코드베이스를 충분히 잘 알고 있어서, 모델이 낭떠러지로 향하는 순간을 감지할 수 있다. 어떤 경계가 중요하고 어떤 경계가 그렇지 않은지 안다. 그들은 충분히 큰 규모에서 충분히 많은 망가진 것들을 배포해 봤기 때문에, 프로덕션 버그를 수정하는 일이 실존적 위기가 아니라 루틴하게 느껴진다. 그들에게 AI는 타이핑과 보일러플레이트를 없애 주었다. 판단력을 없애 주지는 않았다. 판단력은 이미 그들에게 있었기 때문이다.

첫 번째 팀에게 AI는 타이핑을 없애 주었지만 불확실성은 증폭시켰다. 모델이 올바른 파일을 건드렸는지 알 수 없다. 생성된 상태 관리가 다른 화면을 망가뜨릴지 알 수 없다. CI 실패가 실제 문제인지 불안정한 테스트인지 알 수 없다. AI가 생성한 모든 변경 사항은 주사위 던지기다. 대부분의 사람은 프로덕션에 주사위를 던지는 데 익숙하지 않다.

두 번째 팀은 실제로 누구인가

이것은 이론적 원형이 아니다. 두 번째 팀은 Claude Code를 만든 사람들과 많이 닮았다.

Anthropic의 엔지니어들은 세계 최고 수준이다. 그들은 분산 시스템, ML 인프라, 사용자 대상 제품을 대규모로 배포해 왔다. 모든 실패 모드를 목격했다. 그들의 AI가 버그 투성이의 refactor를 생성하면, 과거에 똑같은 실수를 저질러 본 경험이 있기 때문에 몇 초 만에 문제를 찾아낸다. 프로덕션이 깨져도, 어디를 봐야 하는지 알려줄 guardrail이 필요 없다. 그들의 직관 자체가 guardrail이다.

이것이 그들이 밀어붙일 수 있는 이유다. 버그가 있는 코드를 배포하고, 기록적인 속도로 공개적으로 수정하며 계속 나아간다. 그들의 제품에 대한 불만은 인터넷 곳곳에 널려 있다. 그들은 속도를 늦추지 않고, 그들의 엔지니어는 잠을 설치는 일이 없다. 안정성은 중요하지만, 버그를 배포한 바로 그 AI로 몇 분 안에 수정할 수 있다면 버그의 대가는 낮다.

그들에게는 Autotomy가 필요 없다. 그들의 엔지니어는 이미 Autotomy가 규칙으로 인코딩하는 판단력을 스스로 갖추고 있기 때문이다.

99%의 문제

업계의 나머지는 Anthropic이 아니다.

대부분의 엔지니어링 팀에는 대규모 배포를 수십 번 경험한 엔지니어가 없다. AI가 생성한 잘못된 refactor를 몇 초 만에 찾아낼 직관도 없다. 알려진 버그를 배포하고 실시간으로 수정할 자신감도 없다. 코드가 프로덕션에서 깨지면 상사가 질문을 던진다. QA가 무언가를 반려하면 데드라인이 밀린다. 데모에서 회귀 버그가 발생하면 신뢰가 증발한다.

이런 팀에게 프로덕션 버그는 5분짜리 수정이 아니다. 하루 치 스트레스다. 이해관계자와의 대화 자리다. 신뢰도에 남는 흠집이다.

그들에게는 엘리트 팀에게 필요 없는 무언가가 필요하다. 엘리트 수준의 판단력 없이도 AI 출력을 신뢰할 수 있게 만드는 체계다. 병합 전에 경계 위반을 잡아내는 guardrail이 필요하다. 동작을 독립적으로 검증하는 contract가 필요하다. AI가 생성한 모든 변경 사항에 대해 엔지니어가 일일이 재검토하지 않아도 되도록 규칙을 강제하는 CI가 필요하다.

그들에게 Autotomy가 필요한 이유는 그들이 나쁜 엔지니어라서가 아니다. 안정성이 중요하고 실수에 대가가 따르는 평범한 조직에서 일하는 평범한 엔지니어이기 때문에 Autotomy가 필요한 것이다.

엘리트 팀도 Autotomy가 필요할까

아마도 그럴 수 있다.

엘리트 팀이 밀어붙일 수 있는 것은 그들의 엔지니어가 어떤 상황에서도 복구할 수 있기 때문이다. 하지만 복구에도 여전히 시간이 든다. Anthropic의 엔지니어들조차 견고한 경계가 막아줬을 버그를 수정하는 데 몇 시간을 쓴다. 최고의 직관조차 코드베이스가 충분히 커지면 엣지 케이스를 놓친다.

핵심 질문은 예방 비용이 복구 비용보다 낮은가이다. 어떤 버그든 몇 분 안에 고칠 수 있는 팀에게 예방은 오버헤드처럼 느껴질 수 있다. 위반을 그냥 고칠 수 있는데 왜 경계를 강제하는가? 통합을 그냥 눈으로 확인할 수 있는데 왜 contract 테스트를 작성하는가?

하지만 팀은 영원히 엘리트로 남지 않는다. 엔지니어는 떠난다. 코드베이스는 커진다. 1년차에 모든 나쁜 refactor를 찾아냈던 직관은 3년차가 되면 얇아진다. 모든 암묵적 의존성을 알고 있던 엔지니어는 다른 팀으로 이동한다. 1만 라인에서 통했던 밀어붙이기 전략은 10만 라인에서 부채가 된다.

Autotomy는 엘리트 팀의 속도를 늦추지 않는다. 그들의 속도를 지속 가능하게 만든다. 그들의 판단력을 이직과 규모 속에서도 살아남는 규칙으로 인코딩한다. 개인의 전문 지식을 팀 인프라로 전환한다.

이것이 당신의 팀에 의미하는 것

당신이 첫 번째 그룹 — AI를 시도했다가 화상을 입고 자신감을 잃은 그룹 — 에 속한다면, 당신은 혼자가 아니다. 당신이 대다수다. AI 코딩 담론은 엘리트 작업자들의 작업을 관찰하며 그들의 워크플로우가 당신의 맥락에 그대로 적용될 것이라고 가정함으로써 왜곡되어 있다. 그렇지 않다.

당신의 팀은 Anthropic이 될 필요가 없다. AI 출력을 신뢰할 수 있을 만큼 안전하게 만드는 시스템이 필요하다. 즉, 견고한 경계가 필요하다. 결정적 강제가 필요하다. 위반 사항이 QA에 도달하기 전에 빌드를 실패시키는 체계가 필요하다. 이는 프로덕션에서의 AI 코딩: 대부분의 팀이 포기하는 이유에서 설명한 바와 같다.

진실은 이것이다: 프로덕션에서의 AI 코딩은 모델이 충분히 좋은가의 문제가 아니다. 모델이 값비싼 실수를 저지를 수 없을 정도로 시스템이 충분히 구조화되어 있는가의 문제다. 엘리트 팀은 판단력을 통해 이를 달성한다. 그 외 모든 사람은 guardrail이 필요하다.

목표는 단순하다. AI로 기능을 배포한다. 밤새 편히 잔다. 상사에게서 분노의 메시지 없이 아침을 맞이한다.

AI 코딩 격차에 관한 자주 묻는 질문

AI 코딩이 어떤 팀에는 통하고 어떤 팀에는 통하지 않는 이유는 무엇인가?

엘리트 팀은 AI가 생성한 실수를 즉시 발견하고 복구할 수 있는 깊은 시스템 직관을 갖추고 있다. 대부분의 팀은 그런 직관이 없다. guardrail 없이는 AI가 생성한 모든 변경 사항이 도박처럼 느껴진다. 도박이 실패하면 팀은 자신감을 잃고 AI 사용을 중단한다.

엘리트 팀이 실제로 버그 있는 코드를 생산하는가?

그렇다. 최고의 엔지니어링 조직조차 버그를 배포한다. 차이는 복구 속도다. 일반 팀이 진단하고 수정하는 데 하루가 걸리는 버그를 엘리트 팀은 몇 분 안에 처리한다. 그들은 버그를 실존적 위협이 아닌 운영상의 노이즈로 본다.

견고한 guardrail이 엘리트 팀의 속도를 늦추지는 않는가?

처음에는 그렇다. 경계와 contract 테스트를 설정하는 데는 시간이 든다. 하지만 일단 구축되면 강제는 자동으로 이루어지며 몇 초 만에 실행된다. 장기적인 이점은 코드베이스가 커지고 엔지니어가 교체되어도 팀의 속도가 지속 가능해진다는 점이다.

일반 팀이 가장 먼저 해야 할 일은 무엇인가?

코드를 생성하기 전에 모듈 interface를 정의한다. 빌드를 실패시키는 규칙으로 CI에서 그 interface를 강제한다. 전체 시스템과 독립적으로 동작을 검증하는 contract 테스트를 추가한다. 이 세 단계만으로도 AI 출력이 충분히 예측 가능해져서 QA가 모든 것을 반려하는 일이 사라진다. 더 자세한 안내는 AI 코드베이스를 위한 결정적 guardrail을 참조하라.

목표는 제로 버그인가?

아니다. 목표는 신뢰할 수 있는 AI 코딩이다. 버그가 국소적으로 남고, 진단 가능하며, 버그를 도입한 바로 그 모델로 수정 가능하다는 의미다. 팀이 3주 차에 AI 사용을 포기하지 않고 6개월 차에도 계속 사용한다는 의미다.