같은 명령을 다시 줘도, 같은 작업이 되지는 않습니다

들어가며 — 같은 명령, 다른 숫자

있을 법한 장면 하나로 시작하겠습니다.

매달 하는 거래 점검이 있습니다. 담당자는 이 일을 AI에게 맡기고 있고, 잘 됐던 명령을 따로 저장해 뒀습니다. 이런 문장입니다.

첨부한 원본에서 정상 거래만 집계해서 부서별로 정리해 주세요.

세 달 동안 이 문장을 한 글자도 바꾸지 않았습니다. 그런데 8월 보고서를 지난 달과 나란히 놓고 보다가 이상한 걸 발견합니다. 6월에는 취소된 건이 빠져 있고, 7월에는 들어가 있습니다. 8월에는 취소 건도 빠지고 보류 건도 빠졌습니다.

누가 실수했나 찾아봅니다. 아무도 실수하지 않았습니다. 명령은 같았고, 데이터도 정상이었고, 계산도 맞았습니다. 매달 나온 숫자는 그 달에 적용된 기준에서 보면 전부 정확합니다.

달라진 건 하나뿐입니다. “정상 거래”의 경계를 매달 다시 판정했다는 것.

그리고 이 상황에서 제일 곤란한 질문이 옵니다. “그럼 우리 정상 거래 기준이 뭐예요, 어디 적혀 있죠?” 명령 문서를 열어 보여줄 수는 있습니다. 거기 “정상 거래만”이라고 적혀 있습니다. 그게 전부입니다.

1. 명령은 재사용되지만, 실행은 재현되지 않습니다

전에 잘 됐던 명령을 흘려보내지 말고 쌓아 두라고 쓴 적이 있습니다. 그 글은 지금도 그대로 유효합니다. 저장해 둔 명령은 다음 작업의 출발점을 한 칸 높여 줍니다.

오늘 이야기는 그 글의 옆 칸입니다. 명령을 쌓으면 출발점이 같아집니다. 그런데 출발점이 같다고 도착점이 같지는 않습니다.

이 둘은 다른 말입니다.

재사용 — 같은 문장을 다시 쓸 수 있다
재현 — 다시 썼을 때 같은 일이 벌어진다

우리는 앞의 것을 해 두고 뒤의 것까지 확보했다고 생각합니다. 저장된 프롬프트를 붙여 넣는 순간 “지난번과 같은 작업”을 시켰다고 느끼기 때문입니다. 그런데 실제로 같은 것은 문장이고, 그 문장이 하는 일은 매번 새로 정해집니다.

말로 준 지시에는 단계가 하나 더 끼어 있습니다. 문장이 실행되기 전에 해석됩니다. 그리고 그 해석은 화면에 남지 않습니다.

2. 편차는 오류가 아니라서, 아무 데도 안 걸립니다

왜 같은 문장이 매번 다르게 실행되는지 짚어 보면 세 가지가 겹칩니다.

첫째, 문장에는 경계가 안 적혀 있습니다. “정상 거래”라고 쓴 사람 머릿속에는 취소·보류·환불·부분취소가 어디에 들어가는지 정리돼 있습니다. 문장에는 안 들어갔습니다.

전에 말하지 않은 기준은 AI가 대신 정한다고 했던 그 자리입니다. 다만 그 글은 한 번의 작업에서 벌어지는 일을 봤고, 오늘은 그 일이 매달 반복되면서 서로 다르게 채워지는 쪽을 봅니다.

둘째, AI는 지난달에 어떻게 판정했는지 모릅니다. AI는 기억하지 않습니다. 6월에 취소 건을 뺐다는 사실은 6월 대화 안에만 있고, 8월 요청은 백지에서 다시 시작합니다. 사람이라면 “지난번엔 어떻게 했었죠”가 나오지만, 그 질문을 하는 주체가 없습니다.

셋째, 이번 달 데이터가 조금 다릅니다. 지난달엔 없던 상태값이 이번 달에 몇 건 생기면, 같은 문장이 그 건을 처음 만납니다. 문장은 그대로인데 문장이 상대하는 세계가 바뀐 겁니다.

그래서 결과가 매달 조금씩 다릅니다. 여기서 중요한 건 이 편차의 성격입니다.

편차는 오류가 아닙니다. 틀린 숫자가 나온 게 아니라, 다른 기준으로 계산된 맞는 숫자가 나옵니다. 검사기를 돌려도 안 걸리고, 수식 오류도 없고, 눈으로 봐도 이상하지 않습니다. 세 달치를 나란히 놓고 대조하기 전까지는 존재 자체를 모릅니다.

그리고 대부분의 조직은 세 달치를 나란히 놓지 않습니다. 매달 그 달의 보고서만 봅니다.

명령은 세 달 동안 한 글자도 바뀌지 않았습니다. 매번 다시 해석된 것뿐입니다.

3. 문서에 적은 규칙은 설명이고, 실행되는 규칙은 집행입니다

여기가 이 글에서 가장 하고 싶은 말입니다.

우리는 규칙을 지키게 만들려고 규칙을 적습니다. 업무 지침, 산출물 기준, AI에게 주는 프롬프트 문서 — 형태는 달라도 하는 일은 같습니다. 문장으로 적어서 다음 사람이 읽게 하는 것.

그런데 문장으로 적힌 규칙에는 결정적인 성질이 하나 있습니다.

어겨도 아무 일이 일어나지 않습니다.

그래서 지켜졌는지 아무도 모릅니다. 지침에 “취소 건은 제외한다”라고 적어 놓고 취소 건을 포함해서 집계해도, 문서는 조용합니다. 문서는 무엇이 옳은지를 설명할 뿐이고, 그 설명이 실제로 적용됐는지는 다른 문제입니다.

같은 규칙을 실행되는 형태로 내려놓으면 성질이 바뀝니다. 상태가 ‘정상’인 건만 세고, 취소·보류는 빼고, 기간은 말일까지 포함한다 — 이 판정이 매번 돌아가는 파일 안에 들어가 있으면, 어긴 결과는 그냥 안 나옵니다. 규칙이 집행됩니다.

이게 발상의 전환입니다. 같은 작업을 매번 똑같이 하게 만드는 방법은 더 정확하게 부탁하는 것이 아닙니다. 부탁을 그만두는 것입니다.

그리고 부수 효과가 하나 붙는데, 저는 이게 본질에 더 가깝다고 봅니다.

그 파일이 명세서가 됩니다. “우리 정상 거래 기준이 뭐예요”라는 질문에 내놓을 수 있는 물건, 그리고 내놓았을 때 “그런데 실제로 그렇게 하고 있나요”를 다시 물을 필요가 없는 물건. 문장으로 된 명세서는 읽어야 알 수 있고 읽어도 지켜졌는지는 모릅니다. 실행되는 명세서는 돌려 보면 압니다.

4. 제가 겪은 자리 — 판정을 문장에서 파일로 옮겼을 때

교육 자료를 만들다 겪은 일로 이 차이를 확인한 적이 있습니다.

인쇄용 워크북에서 페이지 아래쪽이 잘리는 문제가 있었습니다. 제가 갖고 있던 판정 규칙은 문장이었습니다. “아래 테두리와 쪽 번호가 다 보이는지 눈으로 확인한다.” 이 규칙으로 열여섯 장을 봤습니다.

이 문장은 볼 때마다 다르게 적용됐습니다. 크게 잘린 한 장은 잡혔고, 표기 한 줄이 절반쯤 깎인 장은 그냥 넘어갔습니다. 미세한 건 안 보이니까요.

그래서 눈 대신 숫자를 쓰기로 하고, 브라우저 화면에서 페이지 높이를 재 봤습니다. 네 장이 잘렸다고 나왔습니다. 실제로 잘린 건 두 장이었습니다. 나머지 두 장은 인쇄될 때 내부 칸이 알아서 줄어들어 넘침을 흡수하는 구조였고, 화면에서 잰 값은 줄어들기 전의 크기였습니다.

그래서 판정을 문장에서 파일로 옮겼습니다. 완성된 PDF에서 잉크가 찍힌 좌표를 읽어, 297mm보다 아래에 그려진 요소가 있으면 잘림으로 판정하게 했습니다. 짧은 스크립트 하나입니다.

이때 얻은 것은 정확도만이 아니었습니다.

같은 자료를 몇 번 돌려도 같은 판정이 나옵니다. 눈의 컨디션이 개입하지 않습니다.
다음 인쇄물에도 같은 판정이 강제됩니다. 제가 그 기준을 기억하고 있든 잊었든 상관없이.
그리고 지금 “우리 인쇄물의 잘림 기준”이 어디 있냐고 물으면, 그 파일이 답입니다. 그 전에 문서에 적어 뒀던 “여백을 충분히 둔다”는 문장은 아무것도 강제하지 않았습니다.

비슷한 자리가 하나 더 있었습니다. “뒷자리에서도 보이게 글자를 키워 달라”는 요청이 왔을 때, 이걸 말로 시키면 전체를 일정 비율로 곱해 버립니다. 그러면 이미 큰 표지 제목이 지면을 넘칩니다. 무엇을 키우고 무엇은 손대지 않으며 상한이 어디인지를 규칙으로 내려놓아야, 다음에 같은 요청이 와도 같은 결과가 나옵니다.

여기서 한 번 데인 결함은 주의가 아니라 장치로 막는다고 쓴 글과 헷갈릴 수 있어 선을 그어 두겠습니다.

그 글은 사고가 난 다음의 이야기입니다. 같은 결함이 재발하지 않게 사람 대신 기계가 막게 하는 것이었죠. 오늘 이야기는 사고가 하나도 안 났을 때의 이야기입니다. 아무도 틀리지 않았는데 매달 조금씩 다른 것, 그 편차를 고정하는 것.

쓰는 물건은 같습니다. 그 물건이 하는 일이 다릅니다. 하나는 막고, 하나는 고정합니다.

5. 그럼 전부 코드로 내리면 되나요 — 아닙니다

여기서 한 걸음 더 가면 반대쪽 함정이 있습니다.

바로 얼마 전에 6개월 전에 쓴 지시가 오늘 AI를 방해한다고 썼습니다. 지시문에는 낡는 줄이 섞여 있고, 낡은 줄은 조용히 남아서 계속 일한다고요. 규칙을 실행되는 형태로 내려놓는 일에도 같은 위험이 있습니다. 아니, 더 셉니다. 강제되는 규칙은 낡아도 강제됩니다.

그래서 내릴 것과 말로 남길 것을 갈라야 합니다. 기준은 하나로 충분합니다.

답이 이미 정해져 있는가.

정해져 있으면 내립니다. 집계에서 무엇을 빼는지, 기간 경계를 어디로 두는지, 반올림을 어디서 하는지, 파일 이름을 어떻게 붙이는지, 산출물에 무엇이 반드시 들어가야 하는지. 이런 것들은 매번 다시 판단할 이유가 없고, 매번 다시 판단하면 그게 편차가 됩니다.

정해져 있지 않으면 말로 남깁니다. 이번 보고서에서 무엇이 중요한지, 어떤 톤으로 쓸지, 이 예외를 봐줄지. 이건 판단이고, 판단을 파일에 굳히면 지난달의 판단이 이번 달을 지배합니다.

한 가지 위안이 있는데, 71편에서 짚은 문제가 여기서는 좀 덜합니다. 문장으로 된 지시는 낡아도 겉으로 티가 안 납니다. 반면 실행되는 규칙은 낡으면 돌려봤을 때 걸립니다. 규칙이 현실과 어긋나면 결과가 이상하게 나오거나 멈추기 때문입니다. 낡은 문장은 조용히 살아남고, 낡은 규칙은 스스로 신고합니다.

그리고 한 가지 더. 이 일에 코드를 짤 줄 알아야 하는 건 아닙니다. 전에 코드는 외우는 게 아니라 받아내는 것이라고 썼습니다. 규칙을 말로 정확히 쓸 수 있으면, 그 규칙대로 판정하는 파일은 AI에게 한 번 받으면 됩니다. 어려운 쪽은 코드가 아니라 규칙을 정하는 일입니다. 취소 건을 넣을지 뺄지는 아무도 대신 정해 주지 않습니다.

6. 오늘의 한 걸음 — 두 달치를 나란히 놓는 것부터

거창하게 시작할 것 없습니다. 순서는 이렇습니다.

같은 작업의 산출물 두 개를 나란히 놓습니다. 지난달과 이번 달, 또는 지난 분기와 이번 분기. AI에게 시킨 반복 작업이면 더 좋습니다. 그리고 다른 칸을 찾습니다. 그 목록이 편차의 목록입니다. 대개 두세 개는 나옵니다.
그중 판단이 안 들어간 칸을 하나만 고릅니다. 여러 개 고르지 마세요. 하나로 시작해서 남는 걸 확인하는 편이 낫습니다.
그 칸의 규칙을 문장으로 정확히 씁니다. 이게 실제 일입니다. “정상 거래만”이 아니라 “상태가 정상인 건만, 취소·보류·부분취소는 제외, 기간은 말일 포함”까지.
그 규칙대로 판정하거나 집계하는 파일을 한 번 받습니다. AI에게 시키면 됩니다. 다음 달부터는 그 파일을 돌립니다. 명령을 다시 주는 대신에요.
규칙 문서에는 ‘왜’를, 파일에는 ‘무엇을’ 남깁니다. 문서에는 취소 건을 왜 빼기로 했는지가 들어갑니다. 그건 사람만 읽을 수 있고, 나중에 기준을 고칠 때 필요합니다. 파일에는 그래서 무엇을 하는지가 들어갑니다. 둘이 같이 있어야 명세서입니다. 문서만 있으면 설명이고, 파일만 있으면 이유를 잃어버린 규칙입니다.

마무리 — 무엇을 강제할 수 있느냐가 실력입니다

AI로 일하는 사람이 늘면서, 잘 쓰는 기준도 한 칸씩 옮겨 왔습니다. 처음에는 얼마나 그럴듯한 답을 받아내느냐였고, 다음에는 그 답을 검증할 수 있느냐였습니다.

오늘 짚은 건 그다음 칸입니다. 같은 일을 두 번 시켰을 때 같은 결과가 나오게 만들 수 있느냐.

이건 AI의 성능 문제가 아닙니다. 모델이 열 배 좋아져도 말로 준 규칙은 여전히 말로 준 규칙입니다. 해석 단계는 그대로 남고, 편차도 그대로 남습니다. 달라지는 건 편차가 더 그럴듯해진다는 것뿐입니다.

그래서 규칙을 남기는 일은 문장을 잘 쓰는 일이 아니라, 어긴 것이 통과하지 못하게 만드는 일입니다.

매달 하는 그 일의 기준이 지금 어디 있는지 떠올려 보면, 대개 두 곳 중 하나입니다. 문서 안에 문장으로 있거나, 아무 데도 없이 머릿속에만 있거나. 두 곳 다 매달 다시 해석됩니다.

세 번째 자리를 하나 만들어 두자는 것이 이 글의 전부입니다. 돌려 보면 지켜졌는지 알 수 있는 자리, 그리고 기준을 묻는 사람에게 그냥 건네줄 수 있는 자리요.