2.2. 프롬프트로는 불확정성을 해결할 수 없다 — 코드와 토큰

앞 챕터 끝에 한 가지 질문이 남았습니다.

"그럼 프롬프트를 더 잘 쓰면 되지 않을까?"

실제로 대부분 이 길로 갑니다. 출력이 흔들리면 프롬프트가 부족했다고 결론 내리고, 다시 프롬프트 창으로 돌아갑니다. "이번에는 표 색을 명시하자", "헤더는 굵게 하라고 한 줄 더 넣자". 그렇게 프롬프트는 점점 길어지는데, 출력은 여전히 흔들립니다.

프롬프트가 부족해서가 아닙니다. 방향이 틀렸기 때문입니다. 이번 챕터에서는 프롬프트가 할 수 있는 일과 할 수 없는 일을 원리부터 가르고, 일관성의 진짜 열쇠인 코드, 그리고 지갑과 직결되는 토큰 이야기까지 내려가 보겠습니다.

1. 프롬프트를 다듬으면 되지 않을까 — 분포를 좁힐 뿐, 한 점을 만들지 못한다

앞 챕터에서 본 대로 LLM은 다음에 올 말을 확률표에서 하나씩 뽑아 문장을 만듭니다. 그렇다면 프롬프트는 이 뽑기에서 무슨 일을 할까요.

프롬프트는 확률분포의 모양을 바꿉니다. 잘 쓴 프롬프트는 엉뚱한 단어들의 확률을 낮추고, 원하는 방향의 단어들에 확률을 몰아줍니다. 분포가 좁아지고, 그만큼 출력 품질이 올라갑니다. 프롬프트를 다듬을수록 결과가 좋아지는 이유가 이것입니다.

하지만 분포를 좁히는 것과 분포를 한 점으로 만드는 것은 전혀 다른 일입니다.

아무리 좁혀도 그것은 여전히 분포입니다. 봉우리가 날카로워질 뿐, 폭이 0이 되지는 않습니다. 폭이 남아 있는 한 출력은 그 폭 안에서 계속 흔들립니다.

프롬프트는 분포를 좁힐 뿐 폭이 남는다 — 한 점을 만드는 것은 코드다

온도(temperature)라는 설정을 0으로 낮추면 매번 가장 확률 높은 단어만 뽑게 만들 수 있습니다. 하지만 이것도 완전한 보장은 아닙니다. 모델 바깥의 인프라 변수¹ 때문에 똑같은 입력에도 결과가 갈릴 수 있습니다.

물론 프롬프트가 무의미하다는 뜻은 아닙니다. "무엇을 할지"를 정하는 것은 프롬프트의 일이고, 그 일을 대신할 것은 없습니다. 다만 프롬프트는 "매번 똑같이"를 보장하지 못할 뿐입니다.

주문서가 아무리 자세해도 매번 다른 셰프가 요리하면 접시는 조금씩 달라집니다. 주문서를 탓할 문제가 아닙니다.

2. 지침을 파일로 정리하면 되지 않을까 — 스킬도 결국 프롬프트다

요즘은 자주 쓰는 지시를 파일로 정리해 두는 방식이 널리 쓰입니다. 특정 작업의 절차와 규칙을 문서로 묶어 AI가 그때그때 꺼내 읽게 하는 스킬(Skills), 프로젝트 전체 규칙을 담는 CLAUDE.md 같은 지침 파일이 대표적입니다. 이렇게 정리해 두면 일관성이 잡히리라 기대하게 됩니다.

하지만 이 파일들은 전부 프롬프트입니다.

형식이 마크다운 문서일 뿐, AI에게 건네는 말이라는 점에서는 채팅창에 치는 한 줄과 다르지 않습니다. 전부 확률의 영역이라는 뜻입니다. 지침 파일은 분포를 더 정교하게, 더 재사용하기 좋게 좁혀줄 뿐 분포 자체를 없애지 못합니다. 여기에 일관성의 열쇠가 있다고 믿는 한, 앞 절의 벽에 계속 부딪힙니다.

3. 그럼 무엇이 흔들린 걸까 — 매번 새로 태어나는 코드

진짜 열쇠는 그 밑에 있습니다. 제 경험을 하나 보여드리겠습니다.

챗봇에게 같은 프롬프트를 다섯 번 연속으로 넣어본 적이 있습니다. 표 하나를 엑셀 파일로 만들어 달라는, 한 글자도 다르지 않은 요청이었습니다. 다섯 번 받은 파일의 헤더 색이 다섯 번 다 미묘하게 달랐습니다. 테두리 굵기도, 폰트 크기도 조금씩 어긋났습니다. 프롬프트를 더 길게, 더 구체적으로 다시 써도 여전히 달랐습니다.

이유는 AI가 엑셀을 만드는 방식에 있습니다. "엑셀 만들어줘"라고 치면 AI가 어딘가에서 엑셀 창을 띄우고 마우스로 셀을 클릭하는 그림이 떠오르지만, 실제로는 전혀 다릅니다.

클로드 엑셀처럼 파일을 직접 다루는 전용 도구도 있지만(4부에서 다룹니다), 채팅창의 일반적인 경로에서 AI가 하는 일은 여기서도 글쓰기입니다. 다만 한국어 대신 파이썬 코드를 씁니다.

openpyxl 같은, 엑셀 파일을 다루는 공구 상자(라이브러리)를 불러와 셀에 값을 넣고 색을 칠하는 코드를 한 벌 작성합니다. 그 코드를 컴퓨터가 실행하는 순간 비로소 xlsx 파일이 생겨납니다. PPT도, 워드도, 데이터 분석 차트도 같은 구조입니다.

파일을 만드는 손은 AI가 아니라 코드입니다. 그리고 그 코드를 매 요청마다 새로 짭니다. 표를 만들 때마다 헤더 색을 칠하는 코드가 새로 작성되고, 새로 작성되니 매번 미묘하게 다릅니다.

흔들린 것은 프롬프트가 아니라, 매번 새로 태어난 코드였습니다.

그렇다면 해법도 여기서 나옵니다. 말은 미리 고정해 둘 수 없지만 코드는 파일로 저장해 둘 수 있고, 저장된 코드는 결정론의 영역이라 100번을 돌려도 같은 결과를 냅니다. 그래서 서식처럼 매번 똑같아야 하는 규칙은 AI가 새로 짜게 두지 않고, 미리 만들어 둔 코드에 박아 둡니다. AI는 그 코드를 호출만 합니다.

복사# 매 요청마다 새로 짜지 않고, 미리 정의해 둔 테마 함수를 호출만 한다
apply_header_style(ws, row=1, theme="audit_charcoal")  # 색·테두리·굵기 = 코드에 고정

이렇게 하면 AI가 판단할 거리가 확 줄어듭니다. 서식까지 매번 정하게 두면 AI가 결정할 변수가 10개쯤 되고, 그 10개가 매번 조금씩 흔들립니다. 서식을 코드로 고정하면 남는 판단은 한두 개입니다. 무엇을 표로 볼 것인가, 어디까지가 헤더인가. 딱 그것만 AI가 판단하고, 나머지는 코드가 똑같이 처리합니다.

두 도구의 일은 이렇게 갈립니다.

구분	프롬프트	코드
정하는 것	무엇을 할지	어떻게 할지
성질	확률 — 분포를 좁힌다	결정론 — 결과를 고정한다
같은 입력을 주면	매번 조금씩 다른 결과	항상 같은 결과

이 원리를 실제 업무 서식에 구현해 쓰고 있는 사례는 5부에서 자세히 뜯어봅니다.

4. 토큰은 언제 드나 — AI가 쓸 때 들고, 코드가 돌 때는 들지 않습니다

코드로 고정하는 설계에는 품질 말고도 이득이 하나 더 있습니다. 지갑과 직결되는 이야기입니다.

앞 챕터에서 본 토큰은 말의 조각이면서, 동시에 AI 요금과 사용량 한도가 매겨지는 단위입니다.

AI 서비스는 전기요금 같은 종량제로 움직입니다. AI가 내 요청과 자료를 읽을 때(입력 토큰), 그리고 생각을 거쳐 답과 코드를 써 내려갈 때(출력 토큰) 계량기가 올라갑니다.

챗지피티·클로드의 구독 요금제도 겉모습만 정액제일 뿐, 안에서는 사용량을 재서 한도를 겁니다. "사용량 한도에 도달했습니다" 안내가 바로 계량기가 가득 찼다는 신호입니다.

특히 기억할 것은 토큰이 들지 않는 순간입니다. AI가 써 준 코드를 컴퓨터가 실행하는 동안에는 토큰이 전혀 들지 않습니다. 그 일은 AI가 아니라 컴퓨터의 몫이라 계량기가 돌지 않습니다. 코드가 1초를 돌든 10분을 돌든 마찬가지입니다.

활동	하는 주체	토큰 소모
요청과 자료를 읽는다	AI	○ (입력 토큰)
생각하고, 답과 코드를 쓴다	AI	○ (출력 토큰)
작성된 코드를 실행한다	컴퓨터	×

단, 토큰이 들지 않는 것은 정확히 실행 구간까지입니다. 실행이 끝난 결과나 오류 메시지를 AI가 다시 읽어 확인할 때는 입력 토큰이 듭니다.

토큰 계량기는 AI가 코드를 쓰는 동안만 돈다 — 컴퓨터가 코드를 실행하는 구간은 토큰 0

이 구분이 코드 고정 설계에 마지막 논거를 보탭니다. 서식·검증 코드를 미리 고정해 두면, AI가 매번 수백 줄씩 새로 쓰던 코드가 저장된 코드를 부르는 호출 한 줄로 줄어듭니다. 쓰는 토큰이 줄어 비용이 내려가고, 써 내려갈 분량이 줄어 답이 빨라지고, 실행되는 코드가 같으니 결과가 똑같아집니다.

비용, 속도, 일관성 — 같은 설계에서 삼중 이득이 나옵니다.

제 경우 자주 쓰는 엑셀·워드 서식을 코드로 고정해 두고 AI에게는 호출만 시키는데, 고정하기 전에는 보고서 몇 건을 연달아 맡기면 오후에 사용량 한도 안내를 만나는 날이 잦았습니다. 고정한 뒤로는 같은 분량에서 한도에 걸리는 일이 눈에 띄게 줄었고, 답이 돌아오는 속도도 체감이 다릅니다.

5. 그럼 전부 코드로 고정하면 되지 않을까 — 판단의 표면은 열어 둔다

주의할 것이 있습니다. 이 해법은 불확정성을 없애는 것이 아닙니다.

AI는 본질적으로 확률모델이고, 이 성질을 0으로 만들 수는 없습니다. 할 수 있는 것은 불확정성이 작동하는 표면적을 줄이는 일입니다.

AI가 매번 새로 결정하는 변수 하나하나가 흔들림이 새어 나오는 구멍이고, 그 구멍의 총합이 표면적입니다. 서식을 코드로 고정하면 그만큼 구멍이 닫히고, 닫힌 만큼 결과가 안정됩니다. 불확정성이 사라진 것이 아니라, 작동할 자리를 잃은 것입니다.

다만 반대쪽 극단도 경계해야 합니다. 표면을 전부 닫아버리면 그것은 AI가 아니라 그냥 매크로입니다.

모든 판단을 코드로 고정하면 AI를 쓸 이유가 없습니다. AI의 값어치는 "무엇을 할지" 판단하는 데 있습니다. 무엇이 표이고 어디까지가 헤더인지 알아보는 판단은 코드로 대체하기 어렵고, 대체할 이유도 없습니다.

그래서 판단의 표면은 열어 두고, 실행의 표면만 닫습니다.

이번 챕터의 결론은 석 줄로 정리됩니다. 프롬프트는 "무엇을 할지"를 정하며 분포를 좁히는 도구이고, "매번 똑같이"는 그 밑의 코드가 만듭니다. 고정해 둔 코드는 토큰 없이 돌기 때문에 비용·속도·일관성의 삼중 이득이 따라옵니다. 그리고 불확정성은 없애는 것이 아니라, 실행의 표면을 코드로 닫아 작동할 자리를 줄이는 것입니다.

그래서 다음에 AI 출력이 흔들리면, 프롬프트 창으로 돌아가기 전에 먼저 이렇게 가르시기 바랍니다. 흔들린 것이 판단(무엇을 할지)이면 프롬프트를 다듬을 일이고, 실행(어떻게 할지)이면 손댈 곳은 코드입니다. 내 업무에서 매달 똑같이 반복되는 산출물들을 떠올려 같은 잣대를 대 보시기 바랍니다. 매번 똑같아야 하는 부분이 곧 코드로 닫을 자리입니다.

그러면 다음 질문이 자연스럽게 이어집니다. 어디까지 코드로 닫고, 어디부터 AI의 판단에 맡길 것인가. 이 경계선을 긋는 일이 업무 시스템 설계의 전부입니다. 다음 챕터에서는 제가 실무에서 찾은 그 경계선의 비율, **결정론 90% + AI 10%**가 왜 그 비율이어야 하는지 근거와 반론까지 함께 살펴보겠습니다.

Footnotes

1. 컴퓨터가 소수점 계산을 처리하는 순서(부동소수점 연산), 여러 사용자의 요청을 서버가 묶어 처리하는 방식(배치) 등입니다. 같은 입력이라도 이런 처리 환경의 차이가 결과에 미세한 차이를 만들 수 있습니다. ↩