심적 시뮬레이션이라는 제로 토큰 엔진

실제로 하지 않았는데, 뇌는 이미 일부를 수행한다

토큰을 쓰기 전에 이미 일이 진행되는 구간이 있다. 손은 키보드 위에 올라가지 않았고, 모델 호출도 아직 일어나지 않았다. 그러나 좋은 빌더의 머릿속에서는 이미 모듈이 나뉘고, 데이터가 흐르고, 예외 조건이 충돌하고, 어떤 함수가 너무 많은 책임을 떠안는지 드러난다.

이 장에서 말하는 제로 토큰 엔진은 신비한 직감이 아니다. 실제 실행 전에 머릿속에서 수행을 재구성하는 능력이다. 스포츠 심리학에서는 이것을 심상 훈련, 심적 재허설, 운동 심상이라고 부른다. 핵심은 간단하다. 인간은 어떤 행동을 실제로 수행할 때뿐 아니라, 그 행동을 높은 해상도로 상상할 때도 관련 뇌 회로의 일부를 활성화한다.

이를 설명하는 대표 개념이 기능적 등가성이다. 실제 행동과 상상 행동이 완전히 같다는 뜻은 아니다. 공을 던지는 상상만으로 어깨 근육이 실제 투구만큼 강화되지는 않는다. 그러나 운동 계획, 공간 예측, 순서 조정, 감각 예측과 관련된 신경 과정은 상당 부분 겹친다. 마르크 장느로는 운동 심상이 실제 운동 실행과 신경 표현을 공유한다고 보았고, 이후 심상 연구들은 운동 전 영역, 보조운동영역, 두정엽, 소뇌 등 수행과 관련된 네트워크가 상상 속 행동에서도 함께 관여한다는 방향으로 논의를 확장했다.¹

중요한 것은 이 중첩이 엘리트 수행의 경제성을 설명한다는 점이다. 초보자는 실제로 부딪쳐야만 안다. 엘리트는 부딪치기 전에 일부를 안다. 실제 행동을 완전히 대체하지는 못하지만, 실제 행동이 낭비하지 않도록 미리 지형을 만든다.

AI 빌딩에서도 같다. 초보자는 "일단 만들어줘"라고 쓰고, 결과를 받은 뒤에야 자신이 무엇을 원했는지 깨닫는다. 엘리트 빌더는 프롬프트를 쓰기 전에 이미 시스템의 압력 지점을 본다. 이 기능은 토큰을 아끼는 기술이 아니라, 토큰이 들어갈 위치를 결정하는 기술이다.

AI 생성 이미지

기능적 등가성은 '상상도 훈련'이라는 말보다 엄격하다

심적 시뮬레이션을 단순한 긍정적 이미지 트레이닝으로 오해하면 안 된다. "성공하는 장면을 떠올리자"는 식의 자기암시가 아니다. 기능적 등가성이 요구하는 상상은 훨씬 차갑고 구체적이다.

예를 들어 농구 선수가 자유투를 상상한다고 해보자. 막연히 공이 림을 통과하는 장면을 떠올리는 것은 낮은 해상도의 이미지다. 반면 정밀한 심상은 발바닥 압력, 손목 각도, 공의 회전, 관중 소음, 경기 종료 직전의 압박, 자신의 호흡 속도까지 포함한다. 그 순간 뇌는 단순한 그림을 보는 것이 아니라, 수행의 조건을 부분적으로 재현한다.

코딩 전 사고도 이와 같다. "로그인 기능을 만들어야지"는 낮은 해상도의 상상이다. "세션은 어디서 검증되는가, 토큰 갱신은 어느 계층의 책임인가, 실패한 인증과 만료된 인증을 UI가 같은 방식으로 다루면 어떤 혼선이 생기는가, 테스트 더블은 어디까지 허용할 것인가"까지 떠올릴 때 비로소 고해상도 시뮬레이션이 된다.

기능적 등가성의 가치는 여기서 나온다. 실제로 코드를 쓰지 않았지만, 이미 코드가 실패할 수 있는 경로를 일부 지나가 본다. 실제로 AI에게 물어보지 않았지만, AI가 헛소리를 할 가능성이 높은 빈틈을 미리 좁힌다. 실제 토큰은 아직 쓰지 않았지만, 토큰이 만들어낼 결과의 품질을 결정하는 전처리는 시작된 것이다.

PETTLEP: 상상을 실행에 가깝게 만드는 일곱 개의 손잡이

스포츠 심리학자 폴 홈스와 데이비드 콜린스는 심상 훈련을 실제 수행 조건에 가깝게 만들기 위한 PETTLEP 모델을 제안했다.² 이 모델은 좋은 상상이 왜 그냥 머릿속 그림이 아닌지 보여준다.

Physical은 신체적 감각이다. 실제 수행 자세, 호흡, 근육 긴장, 손의 감각을 포함한다. AI 빌딩으로 옮기면 개발 환경, 사용하는 프레임워크, 파일 구조, 명령어, 배포 방식까지 떠올리는 것이다. 추상적 아이디어가 아니라 손에 잡히는 실행 조건이다.

Environment는 환경이다. 선수에게는 경기장, 조명, 관중, 바닥 감각이다. 빌더에게는 팀의 코드베이스, 레거시 제약, 배포 파이프라인, 고객 데이터, 보안 정책이다. 좋은 설계는 빈 우주에서 태어나지 않는다. 항상 특정 환경의 마찰 속에서 작동한다.

Task는 과제의 정확성이다. 훈련 장면은 실제 경기 과제와 닮아야 한다. 빌더가 "대시보드 만들어줘"라고 생각하는 것은 과제가 아니다. "관리자가 결제 실패 고객을 필터링하고, 상태 변경 이력을 확인하며, 환불 플로우로 이동하는 화면"처럼 업무 단위가 정확해야 한다.

Timing은 시간이다. 심상은 실제 수행 시간과 비슷하게 진행될수록 효과가 커진다. 코드 설계에서도 시간 감각은 중요하다. 요청이 들어오고, 인증이 수행되고, 데이터가 조회되고, 캐시가 만료되고, 실패 응답이 돌아오는 순서를 시간축 위에 올려야 한다. 많은 버그는 구조보다 순서에서 터진다.

Learning은 숙련도에 따른 조정이다. 초보자는 거칠게 상상하고, 숙련자는 더 많은 변수를 넣는다. 처음부터 모든 예외를 보려 하면 분석 마비에 빠진다. 반대로 숙련자가 초보 수준의 상상에 머물면 토큰을 아무리 써도 구조가 얕다.

Emotion은 감정과 압박이다. 실제 경기에는 긴장과 두려움이 있다. AI 빌딩에도 감정이 있다. 마감 압박, 투자자 데모, 사용자 장애, 팀원의 반박, 이미 작성된 코드에 대한 애착이 판단을 흐린다. 좋은 시뮬레이션은 기술 조건뿐 아니라 압박 속에서 자신이 어떤 나쁜 결정을 내릴지도 미리 본다.

Perspective는 관점이다. 1인칭으로 직접 수행하듯 볼 수도 있고, 3인칭으로 전체 움직임을 관찰할 수도 있다. 빌더에게도 두 관점이 필요하다. 함수 내부를 구현하는 1인칭 시점과, 시스템 전체 결합도를 내려다보는 3인칭 시점이다. 한쪽만 있으면 편향된다. 구현자 시점만 있으면 국소 최적화에 빠지고, 설계자 시점만 있으면 손에 잡히지 않는 추상화에 머문다.

PETTLEP의 교훈은 명확하다. 상상은 선명할수록 실행에 가까워진다. 실행에 가까운 상상일수록 실제 시행착오를 줄인다.

반복은 필요하지만, 무작정 반복은 부채가 된다

스포츠에서 실제 훈련은 사라질 수 없다. 슛은 던져야 하고, 스프린트는 뛰어야 하며, 경기 감각은 몸으로 배워야 한다. 그러나 무작정 반복은 다른 문제를 만든다. 피로가 쌓이고, 부상 위험이 커지고, 잘못된 자세가 자동화된다. 나쁜 폼으로 만 번 반복하면 만 번만큼 나쁜 신경 회로가 단단해진다.

AI 빌딩의 고토큰 반복도 같은 위험을 가진다. "에러가 나니 다시 고쳐줘"를 반복하면 당장은 움직이는 코드가 나올 수 있다. 그러나 그 과정에서 중복 로직, 불명확한 책임 경계, 임시 예외 처리, 알 수 없는 의존성이 누적된다. 이것이 이 책에서 계속 경계하는 기술 부채다. 문제는 코드가 많아지는 것이 아니다. 인간이 이해하지 못하는 결정이 많아지는 것이다.

정밀한 심적 재허설은 반복의 반대가 아니다. 반복을 더 안전하게 만드는 장치다. 실제 훈련 전에 몸이 망가질 경로를 줄이고, 실제 코딩 전에 구조가 망가질 경로를 줄인다. 그러므로 엘리트 빌더는 적게 시도하는 사람이 아니다. 실패 비용이 큰 시도를 머릿속에서 먼저 태워보고, 실제 토큰은 남은 후보에 집중하는 사람이다.

여기서 중요한 균형이 있다. 심적 시뮬레이션이 완벽주의의 핑계가 되면 안 된다. 머릿속에서 영원히 설계만 하는 사람은 엘리트가 아니라 지연자다. 스포츠 심상도 실제 훈련과 결합될 때 강해진다. AI 빌딩에서도 제로 토큰 사고는 실제 구현을 대체하지 않는다. 다만 첫 호출의 품질을 바꾸고, 이후 반복의 방향을 바꾼다.

코딩 전 구조 시뮬레이션은 무엇을 걸러내는가

AI에게 코드를 요청하기 전, 엘리트 빌더의 머릿속에서 먼저 돌아가야 하는 것은 세 가지다.

첫째, 버그의 경로다. 정상 흐름만 떠올리면 누구나 설계자가 된 것처럼 느낀다. 그러나 시스템은 정상 흐름보다 경계 조건에서 무너진다. 값이 없을 때, 권한이 애매할 때, 네트워크가 끊겼을 때, 같은 요청이 두 번 들어왔을 때, 사용자가 뒤로 가기를 눌렀을 때. 좋은 빌더는 프롬프트 전에 이 장면들을 먼저 통과한다.

둘째, 예외 조건의 위치다. 예외는 어디선가 처리되어야 한다. 문제는 아무 곳에서나 처리되기 시작할 때다. UI가 도메인 규칙을 알고, API 라우터가 데이터 정합성을 임시로 고치고, 데이터베이스 쿼리가 사용자 경험을 결정하기 시작하면 시스템은 서서히 뒤틀린다. 코딩 전 시뮬레이션은 "이 책임은 어느 층에 있어야 하는가"를 묻는 과정이다.

셋째, 결합도의 압력이다. 결합도는 한 부분을 바꿀 때 다른 부분이 함께 흔들리는 정도다. AI는 국소적으로 그럴싸한 코드를 잘 만든다. 하지만 국소적 정합성이 전체 안정성을 보장하지는 않는다. 엘리트 빌더는 AI에게 맡기기 전에 어떤 모듈이 서로 알면 안 되는지, 어떤 데이터 구조가 외부로 새어 나가면 안 되는지, 어떤 규칙이 한 곳에서만 선언되어야 하는지 정한다.

이 세 가지가 프롬프트 이전에 정리되면 AI의 역할은 달라진다. AI는 더 이상 방향을 정하는 존재가 아니다. 이미 좁혀진 경계 안에서 빠르게 구현하고, 누락된 세부를 제안하고, 테스트 케이스를 보강하는 실행 장치가 된다. 이것이 인지 증폭기의 올바른 위치다.

제로 토큰 사고는 절약이 아니라 사전 컴파일이다

제로 토큰 사고를 단순히 돈 아끼는 기술로 이해하면 핵심을 놓친다. 물론 비용은 줄어든다. 불필요한 대화, 장황한 재질문, 무의미한 코드 재생성을 줄이기 때문이다. 그러나 더 큰 효과는 품질이다.

프로그래밍에서 컴파일은 사람이 쓴 코드를 기계가 실행 가능한 형태로 바꾸는 과정이다. 이때 오류가 드러난다. 타입이 맞지 않고, 참조가 끊기고, 문법이 어긋난다. 제로 토큰 사고는 프롬프트의 사전 컴파일이다. 아직 AI에게 보내지 않았지만, 머릿속에서 요구사항의 타입을 맞추고, 책임의 참조를 정리하고, 실행 순서의 문법 오류를 잡는다.

그래서 좋은 프롬프트는 긴 문장이 아니다. 이미 컴파일된 사고의 얇은 출력물이다. 겉으로는 짧아 보여도 그 안에는 많은 제거가 들어 있다. 하지 않을 것, 묻지 않을 것, 허용하지 않을 것, 검증할 것이 정리되어 있다.

토큰 만능주의는 이 과정을 건너뛴다. 생각이 흐린 상태에서 모델을 호출하고, 모델이 낸 흐린 결과를 다시 모델에게 고치게 한다. 그 결과 토큰은 늘어나지만 판단은 깊어지지 않는다. 반대로 엘리트 빌더는 토큰을 쓰기 전에 자기 머릿속에서 작은 경기장을 만든다. 실제 환경을 넣고, 수행 과제를 좁히고, 시간 순서를 돌리고, 압박 상황을 추가하고, 1인칭과 3인칭 시점을 오간다.

그다음에야 프롬프트를 쓴다.

이 순서가 바뀌면 AI는 사고의 증폭기가 아니라 혼란의 증폭기가 된다. 순서가 맞으면 AI는 강력하다. 인간의 머릿속 시뮬레이터가 먼저 방향을 잡고, 모델의 토큰이 그 방향으로 압축된 힘을 밀어낼 때, 적은 연산으로도 높은 밀도의 결과가 나온다.

엘리트 빌더의 무기는 프롬프트 문장력이 아니다. 프롬프트 이전에 이미 실패한 설계를 폐기하고, 살아남은 구조만 AI 앞에 올려놓는 능력이다. 이것이 심적 시뮬레이션이라는 제로 토큰 엔진이다.

참고

¹Marc Jeannerod, Mental imagery in the motor context

²Paul S. Holmes and David J. Collins, The PETTLEP Approach to Motor Imagery