프롬프트 기법을 다 걷어내도 되나?

페르소나를 안 지정해도, 단계를 안 나눠도, 출력 형식을 안 정해도 결과가 같다. 그러면 프롬프트 기법은 다 걷어내도 되는 걸까.

처음 AI로 일하기 시작했을 때 제일 열심히 공부한 게 프롬프트였다. 페르소나를 지정해라, 목적을 명시해라, 단계를 나눠서 시켜라, 예시를 두세 개 붙여라, 출력 형식을 먼저 정해라. 강의든 글이든 대체로 같은 목록을 줬고 나는 그걸 틀로 만들어 썼다. 그러다 모델이 몇 번 바뀌는 동안 그 틀을 하나씩 걷어냈다. 페르소나를 빼도 결과가 같았고, 단계를 안 나눠도 알아서 나눴고, 출력 형식을 안 정해도 읽을 만하게 왔다. 지금은 대체로 한두 문장으로 묻는다. 입력이 짧아졌으니 매 턴 들어가는 토큰도 같이 줄었고, 돌아오는 결과는 나빠지지 않았다.

이번 달에 로블록스 게임 두 개를 만들면서 맵이 어이없게 작게 나온 걸 봤다. 원인을 찾다가 기획서를 열었더니 맵 크기가 한 줄도 안 적혀 있었다. 크기를 정한 문장이 딱 하나 있었는데 그게 "작게"였다. 그 자리를 보고 있다가, 이 모양을 어디서 봤다는 생각이 들었다. 이번 달 초에 초등학교 5학년인 아들이 AI랑 대화해서 게임을 만드는 걸 옆에서 봤을 때다. 아들도 한 항목을 두 글자로 답하고 넘어갔었다.

층은 세 번 올라갔다

프롬프트를 다듬는 게 전부이던 시기가 실제로 있었다. 지금은 무게중심이 옮겨간 게 문서로도 남아 있다.

Anthropic 은 2025년 9월 29일에 올린 컨텍스트 엔지니어링 글에서 이렇게 적었다. "At Anthropic, we view context engineering as the natural progression of prompt engineering." 프롬프트 엔지니어링은 지시문을 어떻게 쓰느냐의 문제이고, 컨텍스트 엔지니어링은 추론이 도는 동안 모델의 창 안에 무엇을 남기고 무엇을 뺄지 고르는 문제라는 구분이다. 같은 글에 이런 문장도 있다. "We're already seeing that smarter models require less prescriptive engineering." 모델이 좋아질수록 시시콜콜 지시할 필요가 줄어든다는 이야기고, 내가 틀을 걷어내면서 겪은 게 이거다.

그다음 층에는 하네스라는 이름이 붙었다. OpenAI가 2026년 2월 11일에 harness engineering 이라는 제목으로 글을 올렸고, 이후로 이 단어를 자주 본다. 에이전트를 감싸는 도구·검사·규칙·기록 전체를 설계 대상으로 놓는 관점이다.

두 글 사이가 5개월이다. 문장을 잘 쓰는 문제에서 무엇을 보여줄지 고르는 문제로, 다시 무엇으로 감쌀지 짜는 문제로 이 속도로 옮겨왔다. 여기에 요즘은 왕복 자체를 설계하는 층이 하나 더 붙는다. 이름은 앞으로도 몇 번 더 바뀔 것이다.

그런데 층이 세 번 올라가는 동안 안 옮겨간 지점이 하나 있다. 무엇을 물었느냐다. 컨텍스트를 잘 골라도 안 물어본 건 안 물어본 것이고, 하네스를 잘 짜도 안 물어본 건 검사 대상이 되지 않는다.

짧게 물어도 되는 만큼 안 물은 게 안 보인다

틀을 걷어낸 대가가 뭐였는지 이번에 알았다.

예전 프롬프트 틀은 성능 장치이기 전에 목록이었다. 목적, 대상, 제약, 형식, 예시. 칸이 있으니 채우면서 한 번은 생각하게 됐고, 못 채운 칸은 빈 채로 눈에 보였다. 틀을 걷어내니 그 목록도 같이 없어졌다. 지금 내가 쓰는 건 한두 문장이고, 그 문장에 안 들어간 게 뭔지는 문장을 아무리 들여다봐도 안 나온다. 없는 건 안 보인다.

문제는 그 빈칸이 비어 있는 채로 남지 않는다는 것이다. 모델은 빈칸을 만나면 멈추지 않고 채운다. 그리고 채운 값은 내가 말한 값과 같은 서식으로 결과에 들어간다. 글자 모양으로는 둘이 구별되지 않는다.

되묻는 턴이 왜 잘 안 생기는지도 여기 붙어 있다고 본다. 한 턴이 싸지면 다음 걸 시키는 게 쉬워진다. 답이 30초 만에 오는데 그중 한 턴을 잡고 앉아서 "내가 이번에 뭘 안 물었지" 를 따지고 있으면, 그 30초가 아까워 보인다. 그래서 앞으로 나간다. 되돌아가는 비용이 실제로 커진 게 아니라 앞으로 나가는 비용이 작아진 것뿐인데, 체감은 같은 방향으로 움직인다.

열한 살이 비워둔 축

아들이 AI와 대화해서 게임 하나를 만든 게 8월 3일이다. 열 턴짜리 짧은 대화였고, 그중 여섯 번째 턴이 이렇게 생겼다.

여섯 번째 턴이 13시 58분이다. AI 가 시점 세 개를 물었고 아들은 3d 라고 답했다. 일곱 번째도 같은 분인데, 이때는 AI 가 이미 배경으로 넘어간 상태였고 아들이 다른건 좋은데 1인 칭 시점으로 하자 라고 되돌렸다.

AI가 물어본 건 시점이었다. 1인칭이냐 3인칭이냐 쿼터뷰냐. 아들이 친 건 3d 두 글자다. 차원과 시점은 다른 축이다. 3D인지 2D인지와, 카메라가 눈에 붙는지 등 뒤에 붙는지는 따로 정해야 하는 항목이다. 아들은 앞쪽 축만 답하고 뒤쪽 축을 비워뒀다.

그다음 턴에 AI가 올린 요약에는 시점이 정해진 것으로 적혀 있었다. 아들이 말한 적 없는 값이었다. 2편에 이 장면을 쓰면서 한 줄로 정리했는데, 그 문장이 지금 이 글의 출발점이다. 아들이 비워둔 축을 AI가 자기가 채운 것이다.

여기까지는 열한 살이라 그렇다고 생각했다. 어휘가 부족하고 시점이라는 말의 뜻을 정확히 몰라서 두 글자로 답했다고. 그렇게 적어두고 넘어갔다.

제일 잘 쓴 입력이 제일 먼저 사라졌다

같은 대화에 하나가 더 있었다. 다섯 번째 턴에서 AI가 무기 종류를 목록으로 뿌렸고 아들은 4 라고 쳤다.

프롬프트 강좌 기준으로 그날 아들이 친 열 줄을 채점하면 4 가 제일 높은 점수를 받는다. 오타가 없고, 짧고, 정확하고, 모호하지 않다. 반대로 제일 낮은 점수를 받을 줄은 사람들씨리 싸우는 이나 애니메이션 같은 기술로 싸운는 개임 쪽이다. 오타가 있고 조사가 어긋나고 문장이 끝나지도 않았다.

완성된 게임에 남은 건 낮은 점수 쪽이다. 사람들씨리 싸우는 도 남았고 애니메이션 같은 기술로 도 남았다. 4 로 고른 무기 종류는 게임에 안 들어갔고, 아들은 한참 놀면서도 그걸 못 잡았다.

이유가 문장력이 아니다. 4 는 그 자체로 요구가 아니라 요구를 가리키는 포인터다. 내용은 AI가 보여준 목록 안에 있었고 그 목록은 다음 턴부터 화면 위로 밀려 올라간다. 아들 입력창에 남은 건 숫자 하나다. 나중에 게임과 맞춰보려고 대화를 뒤지면 4 라는 글자가 나오는데 그걸로는 뭘 골랐는지 알 수 없어서 위로 더 올라가야 한다. 반면 오타투성이 문장은 그 자체가 요구라서, 문장이 남아 있으면 대조표가 이미 손에 있는 것이다.

3d 와 4 는 층이 다르다. 3d 는 뜻이 덜 넘어간 경우라 화면을 보면 잡힌다. 2D가 나오면 눈에 보인다. 4 는 뜻이 정확히 넘어갔는데 나중에 맞춰볼 기준이 아들 쪽에 안 남은 경우다. 이건 화면을 봐도 안 잡힌다. 무기가 하나인 게임도 화면상으로는 아무 문제가 없다.

여기서 하나 갈린다. 잘 쓴 입력과 원하는 결과를 데려오는 입력이 같지 않다. 잘 쓴 입력은 그 턴에 오해 없이 전달되는 문장이고, 결과를 데려오는 입력은 열 턴 뒤에 대조할 수 있게 내 쪽에 남는 문장이다. 프롬프트 기법이 다뤄온 건 앞쪽이다.

내가 비워둔 축

3주쯤 뒤에 내가 같은 걸 했다.

8월 19일에 로블록스 게임 두 개를 같은 날 시작했다. 이번엔 순서를 바꿔서 기획서와 하네스를 코드보다 먼저 놨다. 하루 만에 12,903줄이 나왔고 테스트 354단언이 통과했고 둘 다 실행됐다. 그런데 켜보니 학교 맵이 작았다. 복도 끝에서 끝까지 걷는 데 8.6초, 대각선으로 가로질러도 15초가 안 걸린다.

좌표가 데이터 파일 하나에 모여 있어서 직접 재봤다. SchoolLayout.luau 에 방이 일곱 개 있고, 각 방의 중심과 크기를 펼쳐서 바깥 경계를 잡으면 가로 102, 세로 176 스터드다. 학교 전체가 그 안에 들어간다.

그래서 기획서를 열었다. §6 맵 구성. 이 절이 맵 크기에 대해 말하는 내용의 전부가 한 줄이다.

맵은 길을 잃지 않을 정도로 작게 만든다.

기획서 전체를 스터드·크기·면적·거리로 훑으면 걸리는 줄이 다섯 개인데 넷은 MVP 범위 목록이고, 나머지 하나가 저 "작게"다. 같이 만든 다른 게임도 같은 모양이었다. 메인섬에 주요 지역 11개가 이름으로 나열돼 있고 26개 절 어디에도 스터드 값이 없다. 코드는 그 섬을 420 × 420 스터드로 정했는데, 그 숫자가 어디서 나왔는지는 문서 어디에도 안 적혀 있다.

기획서가 대충 만들어진 게 아니다. 오히려 반대다. 기술 검토를 거쳐 확정한 결정이 12개 붙어 있고 내용이 촘촘하다. 그런데 12개가 전부 범주형이다. 이거냐 저거냐, 켜느냐 끄느냐, 코드냐 에셋이냐. 얼마나 크냐를 정한 결정은 하나도 없다. 자세한 해부는 따로 쓴 글에 있다.

두 자리를 나란히 놓으면 이렇게 된다.

아들은 13시 58분에 시점을 물어봤고 3d 라고 답했다. 비워둔 축은 카메라 위치였고 그 자리를 AI 요약이 채웠다. 나는 기획서 6절에서 맵을 물어봤고 "작게" 라고 답했다. 비워둔 축은 크기였고 그 자리를 코드가 102 × 176 으로 채웠다.

어휘 문제가 아니었다. 나는 스터드가 뭔지 알고, 102와 400의 차이도 알고, 어떻게 적어야 하는지도 안다. 그런데 안 적었다. 열한 살이 두 글자로 답한 자리와 내가 두 글자로 답한 자리가 같은 모양이다.

열한 살은 되돌아갔고 나는 안 갔다

같은 실수를 했는데 결과가 갈렸다. 갈린 지점은 그다음 턴이다.

아들은 일곱 번째 턴에 이렇게 쳤다.

다른건 좋은데 1인 칭 시점으로 하자

이 문장이 나온 시점을 보면 AI는 이미 시점 이야기를 끝내고 배경을 묻고 있었다. 넘어간 결정으로 되돌아간 것이다. 문장을 두 조각으로 나눠보면 다른건 좋은데 가 나머지를 명시적으로 살려두고 1인 칭 시점으로 하자 가 한 축만 갈아낀다. 완성된 게임에 1인칭이 그대로 남았고 나머지 셋도 안 흔들렸다.

나는 안 되돌아갔다. 맵이 작다는 걸 게임을 켜고 나서야 알았고, 이 글을 쓰는 지금도 안 고쳤다. 고치려면 기획서에 숫자부터 적어야 하는데 그 숫자를 아직 못 정했다. 열한 살은 같은 자리에서 한 턴 만에 되돌아갔다.

왜 아들은 되돌아갔고 나는 못 갔나. 답은 하나라고 본다. 아들 쪽에는 대조할 기준이 있었고 내 쪽에는 없었다. 아들은 1인칭이 뭔지 안다. 자기가 해본 게임이 그렇게 생겼으니까. 머릿속에 그림이 있으니 요약에 적힌 글자와 대볼 수 있었고, 어긋난 걸 봤으니 짚을 수 있었다.

내 기획서에는 그 그림에 해당하는 게 없었다. "작게" 는 대조가 안 되는 문장이다. 102 × 176이 작은지 아닌지 판정하려면 비교할 숫자가 있어야 하는데, 그 숫자를 적기로 한 문서에 "작게" 가 적혀 있다. 그래서 코드가 채운 값을 볼 방법이 화면을 직접 켜보는 것뿐이었다.

테스트가 354개 통과했다는 것도 여기서 다시 읽힌다. 그 단언들은 존재하는가, 겹치지 않는가, 닿는가, 개수가 맞는가를 검사한다. 전부 예/아니오로 답할 수 있는 항목이고, 그래서 검사로 옮기기 쉬웠다. 크기는 그 목록에 없다. 354개 중에 맵이 적절한 크기인지 물어본 단언은 0개다. 문서에 숫자가 없으면 검사도 만들 수 없다.

그리고 순서가 이렇게 굳는다. 기획서에 숫자가 없다 → 코드가 임의로 채운다 → 회귀 테스트가 그 값을 고정한다 → 그 값이 계약이 된다. 어느 단계에서도 규칙을 어기지 않았는데, 결과적으로 아무도 결정한 적 없는 숫자가 저장소에서 제일 단단한 게 됐다.

기준이 하나 있던 자리

기획서 두 개를 통틀어 크기에 관한 정량 기준이 딱 하나 있었다. 군도 §21 Vertical Slice 통과 기준 1번이다.

플레이어가 15분 안에 직업 스승을 발견할 수 있다.

왜 이 줄이 있는지도 적혀 있다. §23 주요 위험 1번이 "직업 스승을 못 찾고 이탈" 이다. 시작 화면에서 직업을 안 고르는 게 이 게임의 차별점인데, 그 대가로 스승을 못 찾으면 플레이어가 무기 없이 헤매다 나간다. 그래서 상한을 걸었다. 물어야 할 걸 알고 물은 자리다.

좌표가 데이터 파일에 있으니 재볼 수 있다. 스폰은 (0, 24), 수호자 스승 발트는 폭포 뒤 동굴 (-140, -150) 이다. 직선거리 223스터드, baseWalkSpeed 가 16이니 걸어서 14초. 기획서가 의도한 대로 소문 NPC 셋을 다 들르는 경로로 계산해도 합계 393스터드, 25초다. 대화 시간은 뺀 순수 이동 시간이다.

기준은 900초였고 실제는 25초다. 36배 여유로 통과한다.

통과한 게 좋은 소식이 아니다. 15분 기준은 "스승이 너무 멀지 않은가" 를 물으려고 만든 것이고 돌아온 답은 25초였다. 이 정도로 빗나가면 그 기준은 아무것도 못 거른다. 25초와 300초를 구별하지 못하니까, 통과했다는 사실 자체가 정보가 아니게 된다.

그래서 기준을 만들어두는 것만으로는 부족하다. 기준의 자릿수가 결과의 자릿수와 비슷한 데 있어야 대조가 성립한다. 아들의 1인칭이 대조된 건 그림이 있어서이기도 하지만, 그 그림이 화면과 같은 자릿수였기 때문이기도 하다. 카메라가 눈에 붙었는지 등 뒤에 붙었는지는 켜자마자 갈린다.

되물어야 뒤집힌다

되묻는 게 실제로 뭘 바꾸는지 확인한 자리가 하나 더 있다.

며칠 전에 Orca 라는 도구를 붙여봤다. 에이전트 여러 개를 폴더별로 갈라 돌리는 물건이다. worktree 를 세 개 만들어 각 폴더에 다른 에이전트를 띄우는 구조다. 파일은 정말 안 섞였다. 여기서 멈췄으면 "격리된다" 로 끝났을 것이다.

한 번 더 물어봤다. 폴더가 갈렸다는 게 정확히 어디까지 갈렸다는 뜻인가. 그래서 git 2.50.1 로 직접 재현했다.

$ git rev-parse --git-path refs/stash
.git/refs/stash

stash 위치가 각 폴더 밑이 아니라 공통 디렉터리에 있었다. A 폴더에서 치워둔 변경이 B 폴더에서 그대로 보인다. 거기서 꺼내면 어떻게 되나. 나는 브랜치가 다르니까 충돌이 나면서 지저분해질 거라고 예상했다. 깨끗하게 적용됐다. 다른 브랜치의 변경이 아무 경고 없이 얹혔다. 충돌이 났으면 오히려 눈에 띄었을 텐데 그게 없어서 더 안 좋다. 전체 재현 기록은 이 글에 있다.

같은 글을 쓰면서 숫자 하나도 뒤집혔다. 내가 참고한 소개 자료에는 Orca 저장소 스타가 2만이라고 적혀 있었다. 저장소를 직접 열어보니 49,472였다. 자료가 거짓말을 한 게 아니라 낡은 값이었고, 그건 열어보기 전에는 구별이 안 된다.

두 번 다 첫 답이 틀린 게 아니었다. 첫 답은 내가 물어본 범위 안에서 맞았다. 뒤집힌 건 범위를 넓혀서 다시 물었을 때다.

그래서 질문 순서가 이렇게 굳었다

앞에서 지금은 한두 문장으로 묻는다고 썼는데, 그게 정확하지 않다. 이 글을 쓰다가 내가 실제로 뭘 치고 있는지 들여다봤더니 틀이 하나 남아 있었다. 이 모양이다.

{하려는 것}을 하려고 해. 이걸 {어떤 식}으로 분석해서 {어떤 결과}가 알고 싶어.
이걸 파일로 받고 싶어.
---
이 내용을 심층분석해서 역프롬프트로 생성해줘

프롬프트 강좌가 가르친 틀은 다 걷어냈는데 이건 안 걷혔다. 그리고 걷힌 것들과 남은 것이 성격이 다르다.

걷힌 쪽은 전부 이번 턴의 전달 정확도를 올리는 장치였다. 페르소나, 톤, 단계 분해, 예시. 모델이 좋아지면서 사줄 필요가 없어진 게 이쪽이다.

남은 네 칸은 성격이 다르다. 하려는 것, 볼 각도, 알고 싶은 결과, 받을 형식. 이건 문장을 좋게 만드는 칸이 아니라 내가 뭘 모르는지 나한테 물어보게 만드는 칸이다. 특히 세 번째 칸이 그렇다. 어떤 결과가 나오면 됐다고 볼 것인지를 결과가 나오기 전에 적어야 한다. 이 칸이 비면 남는 판단은 마음에 드나 안 드나뿐이다. 기획서에 "작게" 만 적혀 있던 자리가 정확히 이 칸이 빈 자리였다.

마지막 줄은 더 이상하다. 시킨 걸 하라는 게 아니라 이걸로 프롬프트를 다시 써오라는 지시다. 첫 턴의 산출물이 결과가 아니라 프롬프트다. 프롬프트 엔지니어링을 그만둔 게 아니라 그 일을 상대에게 넘긴 것이다. 나보다 상대가 자기한테 뭐가 필요한지 잘 알고, 그 한 턴이 제일 싸다.

받는 형식은 md 로 시작했다가 요즘은 html 로 많이 받는다. 같은 파일인데 대조하는 방식이 달라진다. md 는 읽어야 알고 html 은 켜면 보인다. 표가 비었는지, 항목이 셋이어야 하는데 둘인지, 근거 칸이 빈 채로 넘어갔는지가 화면에서 한 번에 갈린다. 아들의 1인칭이 켜자마자 갈린 것과 같은 자리다.

대신 반대쪽으로 새는 게 있다. 보기 좋게 나온 문서는 다 확인된 것처럼 읽힌다. 그래서 형식을 요구할 때 "확인 안 된 항목은 미확인으로 표시하고 근거 없는 칸은 비워둬라" 를 같이 건다. 형식이 좋아질수록 빈칸이 안 보이기 때문이다.

그 틀에도 빈칸이 있었다

이 글을 쓰면서 내 틀을 나란히 놓고 봤더니 안 적힌 칸이 셋 있었다.

하지 말 것을 안 적는다. 근거를 어디서 가져올지 안 적는다. 모를 때 어떻게 하라고 안 적는다. 셋 다 같은 종류다. 모델이 빈칸을 자기가 채우는 걸 막는 칸이고, 셋 다 비어 있었다. Orca 스타 수가 낡은 값으로 들어올 뻔한 것도 근거 출처 칸이 비어서다. 기억으로 답하지 말고 저장소를 열라고 안 적었으니까.

그래서 마지막 줄을 이렇게 고쳤다.

바로 실행하지 마라.
1) 내가 안 적었는데 결과를 가를 만한 항목 세 개를 먼저 질문으로 뽑아라.
2) 그다음 이 작업에 맞는 프롬프트를 다시 써라.
3) 내가 확인한 뒤에 실행한다.

1번이 새로 붙은 것이다. 역프롬프트를 받기 전에 내가 비워둔 축을 먼저 뽑게 한다. 안 물어본 건 나한테 안 보이니까 그걸 찾는 일을 상대에게 시키는 것이다. 열한 살이 요약을 읽고 "다른건 좋은데" 하고 되돌아간 자리를, 나는 이 세 줄로 만들어놓고 쓴다.

지금 쓰는 세 가지

틀을 안 쓰고 그냥 대화할 때는 세 가지를 붙여놓고 쓴다. 전부 이번에 확인한 자리에서 나온 것이다.

번호나 단어로 답한 다음 한 줄을 내 말로 붙인다. 4 만 남으면 열 턴 뒤에 대조가 안 된다. 4번, 검하고 창하고 대검을 싸우는 중에 바꿔 쓰는 거 처럼 한 줄이 붙어 있으면 그 줄이 그대로 대조표가 된다. 오타가 있어도 상관없다. 이번 대화에서 코드까지 간 문장들은 전부 오타가 있었다.

크기·개수·시간은 칸을 만들어놓고 강제로 채운다. "작게" 는 대조가 안 되는 문장이다. 못 정하겠으면 못 정했다고 적어두는 편이 낫다. 빈칸으로 두면 코드가 채우고, 코드가 채운 값은 회귀 테스트가 고정하고, 고정되고 나면 그게 결정된 적 없는 값이라는 걸 아무도 모른다. 그리고 칸을 만들 때 자릿수를 결과 쪽에 맞춘다. 15분짜리 칸은 25초를 못 거른다.

AI가 주는 요약을 대조표로 쓰되 요약 자체를 대조 대상으로 본다. 요약은 유용하다. 아들이 대화를 계속한 이유 중 하나도 목록이 길어지는 걸 보는 감각이었다. 그 목록에는 내가 말한 항목과 AI가 알아서 채운 항목이 같은 서식으로 나란히 적힌다. 그래서 그 목록은 대조표이면서 동시에 대조가 필요한 대상이다. 아들이 일곱 번째 턴에 한 게 뒤쪽이었다. 목록을 읽고 목록이 틀렸다고 한 것이다.

프롬프트 기법이 무의미해졌다는 얘기는 아니다. 지금도 값을 하는 게 있다. 출력을 다른 프로그램이 받아야 하면 형식을 먼저 못 박는 편이 낫고, 판정 기준이 애매한 일은 예시를 두어 개 붙이는 게 설명보다 빠르다. 군도의 이동 거리를 구간별로 재볼 때도 표의 열을 먼저 못 박고 시켰다. 구간과 거리 두 열로 오게 해두면 합계가 맞는지 내가 바로 볼 수 있다.

그것들이 사주는 건 이번 턴의 정확도다. 열 턴 뒤에 결과와 대볼 기준까지 만들어주지는 않는다. 두 개가 다른 물건인데 한동안 같은 이름으로 불렸다.

세 개 다 문장을 잘 쓰는 기술이 아니다. 잘 쓴 문장은 이미 모델이 알아서 받아준다. 남은 일은 내가 뭘 안 적었는지 나중에 알아볼 수 있게 만들어두는 쪽이다. 틀을 쓰든 안 쓰든 하는 일이 같다.

다음 이름이 뭐가 되든

프롬프트, 컨텍스트, 하네스, 루프. 이름이 붙는 속도가 5개월 간격이다. 붙을 때마다 층이 하나씩 위로 올라가고, 아래층은 없어지는 게 아니라 손이 덜 가게 된다. 모델이 좋아지면 시시콜콜 지시할 필요가 줄어든다는 문장은 앞으로도 계속 맞을 것이다.

줄어드는 건 지시의 양이지 결정의 개수가 아니다. 게임 하나를 만들려면 시점을 정해야 하고 맵 크기를 정해야 한다. 내가 안 정하면 그 항목이 사라지는 게 아니라 상대가 정한다. 상대가 정한 값은 내가 정한 값과 같은 서식으로 돌아오고, 회귀 테스트까지 통과하면 그때부터는 아무도 그게 결정된 적 없는 값이라는 걸 모른다.

그래서 어떻게 물어야 원하는 게 오느냐고 하면, 나는 이제 문장 쪽을 안 본다. 내가 이번에 안 물어본 축이 뭔지와 돌아온 걸 무엇에 대볼 것인지, 이 두 개만 본다. 앞엣것은 대개 안 보이니까 뒤엣것을 먼저 만들어서 앞엣것을 찾는다.

아들에게 붙이려고 했던 것도 이거였다. AI에게 뭘 시키는 법이 아니라 돌아온 걸 자기가 처음 원한 것과 대보는 순서다. 첫 편에 네 단계로 적어놨는데 마지막 단계인 대조를 그날 아들은 안 돌렸다. 그러면서 시점 하나는 되돌아가서 고쳤다. 그림이 있던 항목만 대조가 됐다.

아들이 사회에 나갈 때쯤이면 지금 쓰는 도구 이름은 하나도 안 남아 있을 것이다. 남는 건 자기가 뭘 안 말했는지 돌아보는 습관이고, 그건 열한 살한테나 나한테나 같은 크기의 일이다. 이번에 확인한 게 그거다. 나도 두 글자로 답하고 넘어갔다.