시스템이 천재를 더 빛나게 한다 이미지: AI 생성

맥도날드 직원은 미슐랭 셰프가 아니다. 그런데 서울에서 먹는 빅맥과 뉴욕에서 먹는 빅맥은 같은 맛이다. 시스템이 일관성을 만들기 때문이다.

여기서 대부분의 사람들은 이렇게 결론짓는다. “재능이 필요 없다. 시스템이면 충분하다.” 나도 한때 그렇게 생각했다. 틀렸다.

맥도날드의 시스템은 셰프를 대체하지 않는다. 셰프를 해방한다. 매장 직원이 그릴 온도를 외울 필요가 없어진 덕분에, 본사의 셰프는 신메뉴 개발에만 집중할 수 있다. 시스템이 반복을 맡았기 때문에, 인간의 창의성은 오직 창의성이 필요한 곳에만 쏠린다. 시스템은 천재를 대체하는 게 아니라, 천재가 천재일 수 있는 조건을 만든다.

같은 원리가 AI 에이전트에도 적용된다. 구조 없는 천재는 표류한다. 구조만 있으면 평범하다. 흥미로운 일은 둘을 결합할 때 일어난다.

구조가 만든 해방의 역사

1935년, 보잉 B-17이 시험비행에서 추락했다. 조종사가 무능해서가 아니다. 비행기가 너무 복잡해져서 한 사람의 기억력으로 모든 절차를 소화할 수 없었기 때문이다. 해결책은 더 뛰어난 조종사를 구하는 게 아니라 체크리스트를 만드는 것이었다. 그 이후 B-17은 180만 마일을 무사고로 비행했다.

통상적인 해석은 “체크리스트가 조종사의 기량을 대체했다"이다. 하지만 실제로 일어난 일은 다르다. 체크리스트가 절차 기억이라는 인지 부하를 떠맡았기 때문에, 조종사는 상황 판단(난기류 속에서의 결심, 비상시 우선순위 재배치)에 온전히 집중할 수 있게 됐다. 체크리스트가 기계적 반복을 맡자, 조종사의 판단력이 비로소 빛을 발한 것이다.

도요타 생산 방식(TPS)도 같은 구조를 따른다. andon 코드를 당기면 라인이 멈추고, 문제가 해결될 때까지 한 대도 출고되지 않는다. 표준 작업 절차(SOP)가 반복 가능한 품질을 만든다. 하지만 TPS의 진짜 위력은 SOP 자체에 있지 않다. SOP가 일상 운영의 변동을 흡수하기 때문에, 엔지니어들이 kaizen(근본적 개선)에 시간을 쏟을 수 있다는 데 있다. 구조가 반복을 맡으니, 사람은 개선에 집중한다.

아툴 가완디의 연구는 이걸 수술실로 가져왔다. WHO 수술 안전 체크리스트를 도입한 병원에서 수술 합병증이 36% 감소하고 사망률이 47% 감소했다. 체크리스트는 19개 항목짜리 종이 한 장이다. 외과의사의 실력을 올린 게 아니라, “거즈 빠뜨리지 않기” 같은 인지 부하를 시스템에 넘김으로써 외과의사가 진짜 어려운 판단(예상 밖 출혈에 대한 즉각 대응, 수술 방향의 실시간 재설계)에 집중하게 한 것이다.

패턴은 동일하다. 구조가 반복을 맡으면, 인간의 역량이 판단과 창의에 집중된다. 시스템의 가치는 재능을 대체하는 데 있지 않다. 재능이 낭비되지 않는 것을 보장하는 데 있다.

AI에게도 같은 원리가 적용된다

지금 AI 업계의 지배적 서사는 “더 큰 모델, 더 많은 파라미터, 더 높은 벤치마크"다. 모델이 똑똑해지면 문제가 풀린다는 믿음. 일부는 맞다. 하지만 절반만 맞다.

가장 강력한 모델에게 구조 없이 “앱 하나 만들어"라고 하면 무슨 일이 벌어지는가. 처음 100줄은 깔끔하다. 500줄 넘어가면 스스로 만든 인터페이스를 잊는다. 1000줄이면 앞에서 정한 규칙을 뒤에서 어긴다. 엔드포인트가 30개를 넘기면 DB 스키마와 API 명세가 서서히 어긋나기 시작한다.

이건 모델이 멍청해서가 아니다. 컨텍스트 윈도우 안에서 모든 결정의 일관성을 유지하는 건 구조적으로 불가능에 가까운 일이기 때문이다. 사람도 못 한다. B-17 조종사가 못 한 것과 같은 이유다. 복잡도가 한 주체의 인지 용량을 넘으면, 그 주체가 아무리 뛰어나도 빠뜨린다.

우리는 이걸 드리프트라고 부른다. 에이전트가 반복 루프를 돌면서 초기 명세에서 조금씩 벗어나는 현상. 구조가 없으면 드리프트는 필연이다. 모델을 업그레이드해도 드리프트가 나타나는 시점이 늦춰질 뿐이다. 절대 사라지지 않는다.

핵심은 이거다. 구조 없이는 Opus조차 필드명을 기억하는 데 추론력을 낭비한다. 구조가 있으면 Opus는 “이 도메인을 어떻게 분해할 것인가"에 추론력을 집중할 수 있다. 똑똑한 모델은 구조가 단순한 작업을 맡을 때만 비로소 똑똑한 일을 한다.

43분, 32 엔드포인트, 버그 제로

증거가 있다. ZenFlow 벤치마크다.

Claude Sonnet 4.6. 최상위 모델(Opus)이 아닌 중간급 모델이 yongol의 SSOT 구조 안에서 앱 하나를 처음부터 끝까지 만들었다.

결과:

  • 32개 엔드포인트, 9개 DB 테이블, 9개 쿼리 파일, 37개 Hurl 테스트, 전부 통과
  • 소요 시간 약 43분
  • 코드 생성 버그 0건

모델이 실수를 안 한 건 아니다. 4건의 오류가 있었다(BUG-077~080). 중요한 건 4건 모두 “SSOT 작성 실수"로 분류됐다는 점이다. 코드 생성기의 버그가 아니라, 에이전트가 명세를 잘못 쓴 것이다. 그리고 시스템이 그걸 잡았다. validate가 실패를 리포트했고, 에이전트는 명세를 고쳤고, 다시 돌렸고, 통과했다.

43분 중 약 16분이 이 validate 루프에 쓰였다. 시스템이 에이전트를 가르친 시간이다.

Sonnet은 Opus보다 “덜 똑똑하다”. 전반적으로 벤치마크 점수가 낮다. 그런데 구조 안에서는 생산 품질의 코드를 만들었다. 천재가 필요 없어서가 아니라, 구조가 실행을 맡음으로써 천재가 실행에서 해방됐기 때문이다.

구조가 Sonnet으로도 충분한 품질의 실행을 처리해 주기 때문에, 천재 모델은 설계와 판단이라는 진짜 고난도 영역에만 투입될 수 있다. 맥도날드 직원이 햄버거를 일관되게 만들어 주기 때문에, 본사의 셰프가 신메뉴를 구상할 수 있는 것과 같은 메커니즘이다.

세 개의 톱니바퀴

이 구조를 분해하면 세 가지 구성요소가 나온다. 나는 이걸 Ratchet Pattern이라고 부른다. 각 톱니바퀴는 “천재가 더 이상 신경 쓰지 않아도 되는 것"을 하나씩 떠맡는다.

1. SSOT: 무엇을 만들 것인가

Single Source of Truth. yongol에서는 9개의 선언적 명세 파일이 이 역할을 한다. OpenAPI가 엔드포인트를 정의하고, DDL이 테이블을 정의하고, Rego가 권한을 정의한다. 핵심은 이 9개가 operationId라는 단일 식별자로 체이닝된다는 점이다. 하나의 엔드포인트에 대한 API 스펙, DB 쿼리, 테스트, 권한 규칙이 모두 같은 키로 묶여 있다.

SSOT가 떠맡는 것: 기억. 필드명, 관계, 제약 조건. 천재가 이것들을 기억할 필요 없다. 명세가 기억한다.

2. Codegen: 어떻게 만들 것인가

SSOT에서 코드를 생성한다. 에이전트가 자유롭게 코드를 쓰는 게 아니라, 명세에서 파생된 코드를 쓴다. 드리프트가 구조적으로 억제된다. 명세에 없는 건 만들 수 없고, 명세에 있는 건 빠뜨릴 수 없다.

Codegen이 떠맡는 것: 반복. 32개 엔드포인트의 보일러플레이트를 일일이 작성하는 건 천재가 할 일이 아니다. 구조가 한다.

3. Gate: 제대로 만들었는가

결정론적 검증이다. validate는 9개 명세 사이의 정합성을 검사한다. operationId가 OpenAPI에는 있는데 Hurl 테스트에 없으면 실패. DDL에 컬럼이 있는데 sqlc 쿼리에서 참조하지 않으면 경고. 통과하지 않으면 다음 단계로 넘어가지 않는다.

Gate가 떠맡는 것: 검수. 32개 엔드포인트 사이의 정합성을 사람이 눈으로 확인하는 건 B-17 조종사가 절차를 머리로 기억하려는 것과 같다. 측정값이 합격을 결정한다.

이 세 톱니바퀴가 맞물리면 래칫이 된다. 한 번 통과한 것은 되돌아가지 않는다. 에이전트가 실수하면 게이트가 잡고, 에이전트가 고치고, 다시 검증한다. 이 루프에서 빠져나가는 길은 “통과"뿐이다. 그리고 이 전체 루프가 돌아가는 동안, 천재는 다음 문제의 설계를 구상하고 있을 수 있다.

천재가 빛나는 순간

그렇다면 천재는 어디에 쓰이는가. 구조 바깥의 모든 곳이다. 거기서 진짜 가치가 만들어진다.

맥도날드 매뉴얼을 쓴 사람은 매장 직원이 아니다. 레시피를 설계하고, 공정을 분해하고, 어느 단계에서 검수를 넣을지 결정한 사람은 전문가다. 도요타의 andon 코드도 마찬가지다. 라인을 세울 조건을 정의한 것은 오노 다이이치의 통찰이었다. 시스템은 실행을 맡지, 설계를 맡지 않는다. 설계는 천재의 영역이다. 구조가 실행의 짐을 덜어줬기 때문에, 천재는 설계에만 몰입할 수 있다.

AI에서도 같다. yongol의 SSOT를 작성하는 것(어떤 엔드포인트가 필요한지 판단하고, 테이블 관계를 설계하고, 권한 모델을 결정하는 것)은 깊은 추론이 필요한 일이다. 구조가 잡히기 전의 탐색, 전례 없는 아키텍처 판단, “이 문제를 어떻게 분해할 것인가"라는 질문. 이런 것들은 구조 안에 집어넣을 수 없다. 여기에 강한 모델이 비용만큼의 값어치를 한다.

그래서 나는 실제 작업에서 모델을 나눠 쓴다. 설계와 판단은 Opus에게, 구조 안의 실행은 Sonnet에게. 이 이중 모델 패턴이야말로 “시스템이 천재를 빛나게 한다"의 가장 직접적인 실현이다. Opus가 필드명이나 보일러플레이트에 추론력을 낭비하지 않는다. 구조가 그걸 맡기 때문이다. Opus는 오직 아키텍처 결정, 도메인 분해, 엣지 케이스 판단(진짜 Opus여야만 할 수 있는 일)에만 집중한다.

건축가가 벽돌을 나르지 않는 건 벽돌 작업을 무시해서가 아니다. 직원이 그걸 맡기 때문에 건축가가 도면에 집중할 수 있는 것이다. 모든 공정에 최고급 인력을 투입하는 건 철저함이 아니라 낭비다.

비싼 모델을 아끼는 게 아니라, 제대로 쓰는 것이다

가격을 보자.

Claude Sonnet의 출력 토큰 가격은 $15/M-token이다. Opus는 $75/M-token이다. 5배 차이. 구조 없이 전 공정을 Opus에게 맡기면, Opus의 추론력 대부분이 보일러플레이트 생성과 필드명 일관성 유지에 소모된다. 시간당 $75를 받는 건축가에게 벽돌을 나르게 하는 셈이다.

구조가 있으면 이야기가 달라진다. 실행(코드 생성, 정합성 유지, 테스트 통과)은 Sonnet이 구조 안에서 처리한다. ZenFlow에서 증명됐듯이, 게이트를 100% 통과하는 품질로. Opus는 설계와 판단에만 투입된다. 같은 예산으로 Opus의 추론력이 5배 밀도로 집중되는 셈이다.

비용 절감이 아니라 예산 배분이다. 천재가 필요한 곳에 천재를 쓰고, 구조로 충분한 곳에 구조를 쓴다. 총비용이 줄어드는 건 부수 효과이고, 진짜 효과는 결과물의 질이 올라간다는 것이다. 천재가 천재의 일을 할 때 나오는 산출물은, 천재가 잡일에 묻혀 있을 때와 차원이 다르다.

남은 질문들

공정하게 말하면, 아직 증명되지 않은 것들이 있다.

ZenFlow는 하나의 벤치마크다. 32개 엔드포인트는 실무에서는 중간 규모다. 200개 엔드포인트에서도 같은 패턴이 유지되는지는 아직 검증 중이다. yongol의 컨텍스트 압축이 약 10배라는 측정은 있지만, 이게 수백 엔드포인트에서도 선형적으로 스케일하는지는 추가 데이터가 필요하다.

또 하나. SSOT를 작성하는 것 자체가 전문성을 요구한다. 맥도날드 비유로 돌아가면, 매뉴얼을 쓸 수 있는 사람이 먼저 있어야 한다. 구조가 천재를 빛나게 하려면, 먼저 구조를 설계할 수 있는 천재가 필요하다. 이건 순환이 아니라 순서다. 한 번의 설계가 무한 번의 실행을 지탱한다.

하지만 핵심 패턴은 흔들리지 않는다.

곱셈

“AI가 얼마나 똑똑한가?“는 절반짜리 질문이다.

나머지 절반은 이거다: “당신의 구조는 그 지능을 어디에 집중시키는가?”

B-17에 체크리스트가 없었을 때, 최고의 조종사도 추락했다. 체크리스트가 생긴 뒤에는 평범한 조종사도 180만 마일을 무사고로 비행했고, 뛰어난 조종사는 전에 없던 난제에 대응할 여유를 얻었다. 도요타가 andon 코드 없이 “뛰어난 기술자를 더 뽑자"고 했다면 린 생산은 존재하지 않았을 것이다. andon이 있었기 때문에 기술자들은 kaizen에 집중할 수 있었다.

AI도 같다. 모델은 매년 새로 나온다. 작년의 최강 모델은 올해의 중간급이다. 하지만 구조에 투자하면 모델이 바뀌어도 남는다. SSOT 명세는 Sonnet에서도 작동하고, Opus에서도 작동하고, 내년에 나올 모델에서도 작동한다. 그리고 모델이 강해질수록, 구조가 해방해 주는 것들도 함께 커진다. 구조의 가치는 모델과 함께 증가한다.

천재 혼자는 표류한다. 구조 혼자는 평범하다. 천재와 구조가 곱해질 때, 비로소 어느 쪽 단독으로는 도달할 수 없는 곳에 닿는다.

시스템이 천재를 이기는 게 아니다. 시스템이 천재를 더 빛나게 한다. 이건 새로운 발견이 아니다. 1935년부터 증명되어 온 것이다. 우리가 AI에 적용하지 않았을 뿐이다.

관련 글

더 읽을거리 (외부)

출처

  • Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
  • Gawande, A. (2009). The Checklist Manifesto: How to Get Things Right. Metropolitan Books.
  • Haynes, A. B., et al. (2009). “A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population.” New England Journal of Medicine, 360(5), 491-499.
  • World Health Organization. (2009). WHO Surgical Safety Checklist. WHO Patient Safety.
  • B-17 체크리스트 사례: Schamel, J. (2012). “How the Pilot’s Checklist Came About.” Flight Safety Australia Magazine.

변경이력

  • 2026-06-25: 초판 발행