모델은 커졌지만 조직은 일을 맡길 준비가 안 됐다
《The Scaling Era》(Dwarkesh Patel·Gavin Leech, Stripe Press, 2025)의 목차를 처음 봤을 때는 기대가 컸다.
Scaling, Evals, Internals, Safety, Inputs, Impact, Explosion, Timelines.
AI가 왜 커졌고, 무엇을 할 수 있으며, 그 안에서는 무슨 일이 벌어지는지 차례로 설명하는 책처럼 보였다. 마지막 장에 도착하면 앞으로 무엇을 해야 할지도 알 수 있을 것 같았다.
막상 읽기 시작하니 생각과 달랐다.
사람마다 다른 말을 했다. 앞사람의 주장과 뒷사람의 반론이 맞물리지 않았다. 흥미로운 질문이 나오다가도 대화가 다른 방향으로 흘렀다. 영어 인터뷰를 옮긴 문장도 편하게 읽히지 않았다.
책을 다 읽었는데도 무엇을 읽었는지 잘 잡히지 않았다.
처음에는 번역과 편집의 문제라고 생각했다. 어느 정도는 맞다.
부제에 이미 적혀 있었다. An Oral History of AI.
이 책은 논증서가 아니다. 구술사다.
저자가 같은 질문을 들고 스무 명을 차례로 찾아간 책이 아니다. 서로 다른 시점에 진행한 인터뷰에서 관련 발언을 골라 주제별로 다시 배열했다. 그래서 목차에는 저자의 논리가 있지만 대화에는 하나의 논쟁이 없다.
그럼에도 이 책을 읽은 시간이 아깝지는 않았다.
평소에는 만나기 어려운 사람들의 이야기를 한자리에서 들을 수 있었기 때문이다. 프런티어 AI 랩의 리더와 연구자, 안전·예측 진영의 분석가, 경제학자가 무엇을 믿고 무엇을 모르는지 직접 말한다. 2024년 말까지의 대화다.
놀라운 것은 이들이 생각보다 많은 것을 모른다고 인정한다는 점이다.
Dario Amodei는 스케일링이 왜 작동하는지를 묻는 질문에 이렇게 답한다.
“The truth is that we still don’t know.”
모델에 더 많은 데이터와 연산을 투입하면 loss가 얼마나 줄어들지는 상당히 정확하게 예측할 수 있다. 하지만 어떤 능력이 언제 나타날지는 예측하기 어렵다.
우리가 예측할 수 있는 것과 실제로 원하는 것이 다르다는 뜻이다.
기업은 loss가 낮은 모델을 사고 싶은 것이 아니다. 일을 제대로 해내는 모델을 원한다.
90%와 99% 사이
Sholto Douglas의 이야기는 이 문제를 조금 더 현실적으로 보여준다.
어떤 모델이 한 단계짜리 문제를 90% 확률로 해결한다고 하자. 한두 번 사용하는 데는 그럴듯해 보인다. 하지만 직접 곱해보면 열 단계가 이어진 업무를 모두 성공할 확률은 약 35%로 떨어진다.
단계별 성공률이 99%라면 결과가 달라진다. 같은 열 단계를 약 90% 확률로 완수한다.
작은 차이처럼 보이는 90%와 99% 사이에 에이전트의 실용성이 놓여 있다.
그래서 Sholto는 MMLU 같은 단일 시험보다 분·시간·일 단위로 이어지는 장기 과업을 평가해야 한다고 말한다. 그래야 어떤 직무를 얼마나 자동화할 수 있는지 알 수 있다는 것이다.
이 대목에서 나는 책과 조금 다른 질문을 하게 됐다.
모델이 얼마나 더 똑똑해질 것인가.
물론 중요한 질문이다. 하지만 조직에서 AI를 도입할 때는 그보다 먼저 답해야 하는 질문이 있다.
이 일을 AI에게 맡겨도 되는가.
어떤 결과를 성공이라고 할 것인가.
어디까지 틀려도 괜찮은가.
언제 사람에게 되돌려야 하는가.
사람의 머릿속에만 있는 기준
회사에서는 이 질문에 답하기가 의외로 어렵다.
현업은 AI가 무언가를 대신해주길 바란다. 하지만 좋은 결과가 무엇인지 물으면 명확하게 설명하지 못하는 경우가 있다. AI가 결과를 내놓은 뒤에야 “이건 아닌데요”라는 답이 돌아온다.
무엇이 왜 아닌지 다시 물으면 그제야 기준이 하나씩 나온다.
전문가의 머릿속에만 있는 것은 스펙이 아니다. 전에도 한 번 쓴 이야기다. 이번에 새로 보인 것은 그다음이다. 모든 기업이 같은 방식으로 그 기준을 꺼내야 하는 것은 아니다.
전통적인 이커머스에는 두 종류의 일이 함께 존재한다.
주문, 결제, 재고, 정산처럼 규칙과 상태가 비교적 명확한 일이 있다. 정상적인 입력과 출력, 오류 조건도 기록으로 남는다. 이런 업무는 규칙을 정리하고 예외 사례를 충분히 테스트하면 자동화할 수 있다.
반면 쉽게 설명하기 어려운 일도 있다.
어떤 상품을 전면에 보여줄지, 어떤 고객 경험이 어색한지, 프로모션에서 무엇을 우선할지, 정책에 없는 예외를 어떻게 처리할지는 숙련자의 경험과 맥락에 좌우된다.
결과를 보면 이상하다는 것은 안다. 하지만 왜 이상한지를 미리 규칙으로 쓰기는 어렵다.
이런 업무에서는 Cognitive Task Analysis, 즉 CTA가 도움이 될 수 있다. 숙련자가 실제 상황에서 어떤 단서를 보고, 무엇을 예상하며, 어느 순간 판단을 바꾸었는지 구체적인 사건을 통해 꺼내는 방법이다. Crandall, Klein, Hoffman의 《Working Minds》가 이 방법을 정리한 책이다.
모든 회사에 CTA가 필요한 것은 아니다
작은 회사는 지식이 창업자나 소수 핵심 인력에게 집중돼 있다. 그 사람이 에이전트의 결과를 바로 보고 교정할 수 있다면 문서화보다 빠른 왕복이 효율적일 수 있다.
규칙 중심 업무라면 이미 성공 기준이 충분히 드러나 있을 수 있다. 이때 필요한 것은 CTA보다 rule coverage와 예외 테스트다.
Digital Native 기업은 또 다르다. 업무 과정이 코드와 로그, 리뷰 기록으로 남는다. 사람이 암묵지를 완전히 설명하지 않아도 실제 작업 궤적에서 모델이 배울 여지가 있다.
《The Scaling Era》에 등장하는 사람들은 전통 기업의 운영 현장보다 프런티어 랩, 빅테크, 예측·투자 네트워크에 더 가깝다. 그래서 책 안에서 자연스럽게 떠오르는 해법도 “더 많은 작업 데이터와 RL” 쪽으로 기운다.
전통 기업의 상황은 다르다. 업무 기준이 여러 시스템과 부서, 사람 사이에 흩어져 있다. 중요한 예외를 처리하는 방법이 특정 숙련자의 기억에만 남아 있기도 하다. 학습할 작업 궤적도, 성공 여부를 자동 판정할 verifier도 충분하지 않다.
그래서 암묵지를 AI Native의 보편적 병목이라고 말하면 과하다.
암묵지는 업무 기준이 말로 잘 나오지 않고, 작업 흔적도 남지 않으며, 지식 보유자와 에이전트 설계자가 멀리 떨어져 있을 때 특히 큰 전환 비용이 된다.
먼저 진단해야 한다
CTA부터 시작할 필요는 없다. 먼저 다섯 가지를 확인하면 된다.
- 좋은 결과의 기준이 명시돼 있는가.
- 실제 작업 과정이 기록되는가.
- 결과를 자동으로 검증할 수 있는가.
- 예외는 얼마나 자주 발생하는가.
- 지식 보유자가 평가 과정에 얼마나 가까이 있는가.
기준과 기록이 충분하면 규칙과 작업 로그를 활용하면 된다. 판단과 예외가 중요하지만 기록이 없다면 그때 CTA가 필요하다. CTA는 모든 조직이 거쳐야 할 의식이 아니라, 위임 준비도의 빈칸을 메우는 방법 중 하나다.
물론 이것도 영구적인 해답은 아닐 수 있다.
Richard Sutton이 2019년에 쓴 「The Bitter Lesson」의 논지가 그렇다. 사람이 넣어준 도메인 지식보다 범용 학습과 연산이 길게 보면 이긴다는 것이다.
모델의 신뢰도가 충분히 높아지고 실제 작업 기록으로 스스로 배우기 시작하면, 지금 우리가 애써 정리하는 스캐폴딩은 임시 목발이 될 수 있다. 그러나 목발이 사라져도 그 안에 담긴 도메인 지식과 조직이 허용할 실패의 경계까지 사라지는 것은 아니다.
Scaling 다음에 필요한 것
《The Scaling Era》는 AI Native의 실행 방법을 알려주는 책이 아니다.
프런티어 모델이 빠르게 커진 시대와 그 중심에 있던 사람들이 느낀 기대와 불확실성을 기록한 책이다. 서로 다른 사람들의 말을 억지로 하나의 결론으로 만들지 않은 저자의 절제도 이해할 수 있다.
다만 책을 덮고 나면 빈칸 하나가 남는다.
모델은 커졌다.
그 모델에게 조직의 일을 어떻게 맡길 것인가.
나는 이 질문에 답하려면 모델의 능력만 평가해서는 부족하다고 생각한다. 조직이 맡기려는 일도 함께 평가해야 한다. 앞에서 적은 다섯 가지가 그 평가 항목이다.
이것은 모델 Eval이라기보다 Delegation Eval에 가깝다.
AI에게 맡기고 싶은 그 일은 무엇인가.
그리고 그 일이 잘 끝났다는 것을 한 문장으로 적을 수 있으신가요?
Member discussion