지난 주말 Andrej Karpathy가 올린 데모 하나가 계속 머리에 남았습니다. Opus 5에 100만 토큰 컨텍스트와 반지의 제왕 첫 문단을 주고, Three.js로 그 장면을 3D로 렌더링하게 한 실험입니다. 모델은 약 2시간 동안 혼자 5,500줄을 쓰며 폴리곤 배치, 카메라 동선, 애니메이션을 조율했고, 비용은 약 10달러였습니다. 결과물은 설명보다 직접 보는 편이 빠릅니다.
“펠리컨 SVG를 그려봐” 같은 벤치마크의 다음 단계라는 해석이 많았는데, 저는 다른 게 더 크게 보였습니다. 바뀐 건 모델의 그림 실력이 아니라 위임의 단위입니다.
위임의 단위가 바뀌었다
지금까지 에이전트에게 주던 일은 프롬프트 크기였습니다. 함수 하나, 버그 하나, 파일 하나. 크면 우리가 쪼갰습니다. 쪼개는 이유는 단순합니다. 컨텍스트가 작으면 긴 작업 중에 앞부분이 시야에서 밀려나고, 밀려나면 일관성이 깨지니까요.
100만 토큰은 그 전제를 지웁니다. 2시간짜리 세션 동안 모델이 쓴 코드 전부, 시도한 것 전부가 시야 안에 남습니다. 책상이 충분히 크면 작업을 나눠서 줄 이유가 없습니다. 위임의 단위가 태스크에서 세션으로 넘어가는 겁니다.
이건 함수 호출과 작업 세션의 차이입니다. 전자는 우리가 분해하고 감독합니다. 후자는 재료와 의도를 주고 결과를 받습니다. 카파시가 한 일은 첫 문단을 골라준 것과, 2시간 뒤에 결과를 본 것뿐입니다.
빌더의 일이 이동하는 곳
실행이 10달러에 2시간이 되면, 실행은 더 이상 병목이 아닙니다. 남는 건 두 가지입니다.
들어가는 쪽: 브리핑. 무엇을 컨텍스트에 넣을 것인가. 카파시의 입력은 첫 문단 하나였지만, 그 선택 자체가 설계 행위입니다. 우리 일로 옮기면 스펙, 브랜드 가이드, 레퍼런스, 기존 코드 중 무엇을 통째로 넣고 무엇을 뺄지 고르는 일이 됩니다.
나오는 쪽: 판정. 나온 것을 어떤 기준으로 받아들일 것인가. 5,500줄을 줄 단위로 리뷰하는 건 세션 단위 위임과 맞지 않습니다. 이제는 완성 기준을 먼저 정의해두고, 결과를 그 기준으로 판정해야 합니다.
일을 잘게 쪼개고 과정을 감독하는 건 오랫동안 시니어의 기술이었습니다. 그 값은 내려가고, 재료를 고르는 일과 완성 기준을 세우는 일의 값이 오릅니다. 불편한 변화지만 방향은 분명해 보입니다.
어디까지 옮겨지는가
선을 그어야 공정합니다. 이 데모가 증명하지 않은 것이 세 가지 있습니다. 유지보수가 없고, 정답 제약이 없고, 사용자가 없습니다. 렌더링이 어색해도 감상이 조금 떨어질 뿐, 아무도 다치지 않습니다.
그래서 리트머스는 한 줄입니다. 결과물이 감상 대상인가, 운영 대상인가. 시안, 프로토타입, 탐색, 데모는 틀려도 됩니다. 스펙에서 데모까지 한 번에 가는 일은 이미 이 방식이 더 빠를 수 있습니다. 반면 운영 대상, 그러니까 틀리면 사용자가 다치고 내일도 고쳐야 하는 소프트웨어는 아직 다른 게임입니다. 2시간 자율 실행의 산출물을 프로덕션에 그대로 넣어도 된다는 증거는 이 데모에 없습니다.
이번 주에 해볼 것
감상 대신 실험 하나를 설계해보세요. 자기 도메인에서 “재료 통째로 + 반나절 자율"에 맞는 일을 고르는 겁니다.
- 제품 스펙 전체와 브랜드 가이드를 넣고 데모 한 방 만들기
- 코드베이스를 통째로 넣고 마이그레이션 초안 받기
- 문서 전체를 넣고 온보딩 가이드 뽑기
조건은 두 가지면 충분합니다. 결과물이 틀려도 되는 영역일 것, 비용 상한을 미리 정할 것. 10~20달러면 위임의 단위가 바뀌었는지 각자의 일에서 확인해보기에 충분합니다.