프롬프트 공부가 헛것이었나 싶어 내 글 40편을 세어봤다. 절반이 넘는 21편에 "틀렸다"가 들어 있었다

며칠 전에 별생각 없이 물어봤다. 지금도 페르소나를 지정하고 목적을 명시하고 단계를 나눠주는 게 의미가 있냐고. 돌아온 답은 대충 이랬다. 예전만큼은 아니다, 자연어로 그냥 말해도 되고, 오히려 그 편이 토큰도 덜 쓴다.

맞는 말이라 별 반박을 못 했다. 나도 요즘 그렇게 쓴다. "당신은 20년 경력의 시니어 백엔드 개발자입니다"로 시작하는 프롬프트를 마지막으로 쓴 게 언제인지 기억이 안 난다. 그런데 답을 받고 나니 좀 이상한 기분이 들었다. 그럼 그때 그 공부는 뭐였나. 역할 지정, 목적 명시, 사고 과정 유도, 예시 제공. 그런 걸 정리한 문서를 나도 몇 개 만들었고 팀에도 돌렸다.

그래서 확인해보기로 했다. 그 습관이 지금 내 글에 얼마나 남아 있나. 이 블로그를 넉 달 넘게 에이전트로 굴렸으니 발행글 전체가 그 시절 습관의 화석이어야 한다. 세어보면 나오겠지 싶었다.

세어봤다. 프롬프트 형식의 흔적은 예상대로 거의 없었다. 여기까지는 맞췄다. 그런데 안 찾던 게 걸렸다. 발행글 40편 중 제목부터 뒤집히는 게 14편이고, 본문에 "틀렸다"가 들어간 글이 21편이었다.

페르소나를 지정하라던 시절

2023년 무렵을 기억해보면, 프롬프트는 거의 주문에 가까웠다.

역할을 먼저 준다. 목적을 명시한다. 출력 형식을 못 박는다. 단계를 나눠 생각하게 한다. 예시를 두세 개 붙인다. 마지막에 "확실하지 않으면 모른다고 답하라"를 넣는다. 이걸 순서대로 지키면 답이 실제로 좋아졌다. 안 지키면 실제로 나빠졌다.

당시 내가 쓰던 것 중 하나를 옮겨 적으면 이런 식이었다.

당신은 대용량 트래픽을 다뤄본 시니어 백엔드 개발자입니다. 아래 코드를 리뷰해주세요. 다음 순서로 답변하세요. 1) 요약 2) 발견한 문제를 심각도 순으로 3) 각 문제의 수정 제안 4) 놓쳤을 수 있는 부분. 확실하지 않은 내용은 추정이라고 명시하세요.

이 여섯 줄 중에 지금 내가 손으로 쓰는 건 하나도 없다. 대신 그냥 이렇게 친다. "이 파일 리뷰해줘." 그런데 결과는 그때보다 낫다.

그래서 강의가 팔렸다. 이 대목을 냉소적으로만 보는 시각이 있고, 나도 그쪽에 반쯤 기울어 있었다. 실제로 AI 양산 채널이 무너지고 나서 강의를 팔러 가는 경로를 한 편 썼을 만큼 그 판을 안 좋게 봤다. 바이브 코딩 강의를 결제하기 전에 읽으라는 글도 썼다.

그런데 그 시절을 강의 팔기로만 설명하면 안 맞는 조각이 하나 있다. 언어학 전공자들이 들어왔다는 것. 화용론 하던 사람들이 프롬프트 얘기를 하고 있었다. 돈 냄새를 맡고 온 거라고 치부하기엔, 그들이 하던 말이 꽤 구체적이었다. 지시문의 명제 구조가 어떻고, 전제가 어디에 숨어 있고, 같은 요청도 발화 수반력이 다르면 응답이 달라진다는 식의 얘기였다.

지금 와서 보면 그때 형식이 필요했던 이유가 명확하다. 모델이 문맥을 스스로 못 채웠다. 내가 어떤 상황에서 뭘 하려는지, 이 코드가 어느 프로젝트 것인지, 앞에서 뭘 결정했는지를 모델이 알 방법이 없었다. 그래서 매번 손으로 채워 넣어야 했고, 그 채워 넣기의 정형이 프롬프트 템플릿이었다.

형식은 문맥의 대용물이었다. 대용물은 원본이 도착하면 자리를 비운다. 그래서 그 형식이 지금 안 통하는 게 아니라, 통할 자리가 없어진 것에 가깝다.

형식이 어디로 갔는지는 이미 안다

내가 매번 손으로 쓰던 것들은 사라진 게 아니라 파일로 내려갔다.

이 블로그 레포에는 CLAUDE.md가 있다. 여기에 이 프로젝트가 뭘 하는 곳인지, 카테고리가 뭐가 있는지, 발행 전에 뭘 세야 하는지가 적혀 있다. 스킬이 스무 개 있다. 글을 쓸 때 어떤 호흡으로 쓰는지, 문체 점검을 어떤 순서로 하는지가 각각 파일 하나씩이다. 훅이 세 개 있어서 세션이 시작될 때 이전 상태를 자동으로 붙여주고, 커밋 직전에 시크릿을 스캔한다.

위에 옮겨 적은 여섯 줄짜리 프롬프트와 대조해보면 대응이 거의 일대일이다. 역할 지정은 에이전트 정의 파일로 갔다. 출력 형식 지정은 산출물 경로 계약으로 갔다. 단계 분할은 스킬의 워크플로우 절이 됐다. "확실하지 않으면 추정이라고 명시하라"는 리서치 브리프의 확정·추정 구분표가 됐다.

토큰이 줄어드는 이유도 여기 있다. 앞에서 "자연어로 해도 토큰이 덜 든다"는 답을 받았다고 썼는데, 정확히는 형식을 버려서 아끼는 게 아니다. 같은 내용이 앞쪽 고정 위치에 있으면 캐시에서 다시 읽힌다. 계획서 얘기를 쓸 때 내 세션 로그를 뽑아보니 473턴 누적에서 캐시 재사용이 97.5%였다. 매번 새로 쓰는 건 매번 새로 계산되고, 파일에 박힌 건 거의 공짜다.

그러니까 형식이 없어진 게 아니라 위치가 바뀐 것이다. 대화 안에 있던 게 저장소로 내려갔고, 내려간 뒤로는 내가 매번 의식할 필요가 없어졌다.

이 흐름에 사람들이 붙인 이름이 컨텍스트 엔지니어링이었고 그다음이 하네스 엔지니어링이었다. 그리고 내가 반년 넘게 이름도 모르고 짜 놓은 게 사실 아웃터 루프였다는 걸 뒤늦게 알아챈 글도 한 편 있다. 그 글에서 이 네 단어가 서로를 대체하는 게 아니라 위로 쌓인다는 얘기를 했다.

여기까지는 이미 쓴 얘기다. 이번에 궁금했던 건 다른 쪽이다.

프롬프트가 파일로 내려가고, 파일이 하네스가 되고, 하네스 위에 루프가 얹혔다. 계속 아래로 내려가고 위로 쌓이는데, 그럼 사람 손에 남는 건 뭔가. 이름이 네 번 바뀌는 동안 안 바뀐 게 있나.

40편을 세어본 결과

그래서 열어봤다. 발행 아카이브에 40편이 있다. 본문 길이 중앙값이 10,178자, 제일 짧은 게 3,974자, 제일 긴 게 13,481자다.

먼저 제목만 뽑아서 훑었다.

• 내가 짠 건 하네스가 아니라 아웃터 루프였다
• AX 도입 파일럿 95%가 실패하는 자리는 모델이 아니라 구두로 끝난 회의다
• 유튜브 AI 슬롭 수익화 정지 — 도구가 아니라 사람이 문제다
• 망분리 20년 만에 AI가 청구서를 보냈다. 법이 요구한 건 전 직원 인터넷 차단이 아니었다
• 카카오는 순자산 36%에 'AI'라는 이름을 붙였다. AI가 지우는 것도 직업이 아니라 계단의 첫 칸이다
• AI로 주식투자가 될까 싶어 모델 셋을 붙여봤다. 정정된 건 위험 목록이 아니라 "AI가 충동을 줄여준다"는 내 전제였다
• 구글은 서울에서 모델이 아니라 에이전트를 판다

제목에 "아니라" 또는 "아니었다"가 들어간 게 7편이다. 형태만 다르고 하는 일은 같은 게 7편 더 있다.

• 시크릿 스캔을 걸어뒀는데 AWS 키가 그냥 통과했다
• 내 커밋 훅은 커밋되는 파일을 안 보고 있었다
• macOS 화면 공유 취약점 패치가 몰린 낮에 사내 네트워크가 느려졌다. 정작 내 맥은 5900 포트가 그대로 열려 있었다
• AI 코딩 4단계는 그대로다. 사람만 빠졌고, 내가 세운 감시 훅 12개는 4개월간 발화 0회였다
• 리더보드 1위와 2위는 태스크 0.36개 차이였다. 내 하네스엔 두 달 반 죽어 있던 게이트가 있었다
• AI 챗봇에 불만 아홉 줄을 쏟았더니 정작 당사자에게 말할 문장은 하나도 안 남았다
• 하사비스는 11개월 만에 AGI 예측을 2.5년 당겼다 — 그런데 더 크게 빗나간 건 순서였다

합쳐서 14편. 40편의 35%가 제목에서 이미 뒤집힌다.

여기서 하나 정직하게 밝혀둘 게 있다. 앞의 7편은 명령어 한 줄로 나온다. 제목 줄에서 "아니"를 찾으면 그대로 그 7개다. 뒤의 7편은 아니다. 내가 제목을 눈으로 읽고 "이것도 같은 모양이다"라고 판단해서 넣었다. 그래서 14라는 숫자는 두 성격이 섞여 있고, 다음 문단에 나오는 숫자들과 무게가 다르다. 이 구분은 글 뒤쪽에서 다시 문제가 된다.

뒤집히지 않는 나머지 26편도 훑어봤다. 대체로 두 종류다. 외부 사건을 해설한 글이거나, 도구를 써보고 정리한 사용기다. 로컬 LLM으로 닷새 살아본 얘기, 브라우저 탭 일곱 개 줄인 얘기 같은 것들. 나쁜 글이라는 뜻은 아닌데, 다시 읽어보면 내가 뭘 새로 알게 됐는지가 잘 안 보인다. 도구는 바뀌었고 나는 안 바뀐 글이다.

본문으로 내려가면 비율이 더 올라간다.

셈한 것	값	비율
발행글 전체	40편
본문에 "틀렸"	21편	52.5%
본문에 "전제"	17편	42.5%
본문에 "줄 알았"	9편 (13회)	22.5%
제목이 반전 구조	14편	35%
제목에 숫자가 들어감	20편	50%
"세어보니·열어보니·확인해보니·정렬해보니·뽑아보니"	12회

세어보고 나서 좀 멍했다. 나는 이걸 문체 취향이라고 생각하고 있었다. 반전이 있는 제목이 클릭이 잘 나오니까 그렇게 뽑는다고, 어디선가 배운 카피라이팅 습관이라고 여겼다.

그게 아니었다. 제목이 뒤집히는 이유는 글을 쓰는 도중에 내 생각이 실제로 뒤집혔기 때문이다. 21편에 "틀렸다"가 들어 있는 건 21편에서 내가 뭔가를 틀렸다고 적어야 했기 때문이고, 그건 대개 남이 아니라 나 자신이었다.

한 번 더 잘라봤다. 7월 이전에 쓴 13편 중에서는 8편이 "틀렸다" 또는 "전제"를 포함한다. 61.5%다. 7월 이후 27편에서는 22편이다. 81.5%로 올라간다.

이 차이를 어떻게 읽어야 할지는 솔직히 모르겠다. 두 가지 해석이 가능하다. 하나는 습관이 굳었다는 것. 반전을 찾는 게 몸에 붙어서 자연스럽게 자주 나온다. 다른 하나는 하네스가 강제했다는 것. 7월 이후는 스킬과 규칙이 대부분 자리를 잡은 뒤다. 어느 쪽인지 지금 데이터로는 구분이 안 된다. 두 해석의 관측 결과가 똑같이 생겼기 때문이다.

결과를 바꾼 건 다섯 번째 단계였다

내가 AI를 쓰는 방식은 이렇게 돈다.

궁금증이 하나 생긴다. 깊게 찾아보게 시킨다. 그 결과를 내가 학습한다. 학습한 걸로 분석을 시킨다. 분석 결과를 들고 다시 질문을 만든다. 여기서 다시 돈다. 몇 바퀴 돌고 나면 결과가 나온다.

이걸 그림으로 그리면 여섯 칸짜리 순환이다. 그럴듯해 보인다. 그런데 실제로 결과를 바꾸는 칸은 여섯 개가 아니었다. 다섯 번째 하나였다.

주식 얘기를 쓸 때가 그랬다. 시작 질문은 "AI로 주식 리서치가 될까"였다. 모델 셋을 붙였고, 각각한테 같은 종목을 물었고, 답이 나왔다. 여기서 멈췄으면 글은 "LLM이 짚어준 위험 요소 목록" 같은 게 됐을 거다. 실제로 초안 방향이 그쪽이었다.

다섯 번째 칸에서 질문을 하나 더 만들었다. 내가 이걸 왜 하고 있지. 답을 적어보니 "AI가 내 충동적 판단을 줄여줄 것"이었다. 그 전제를 문장으로 꺼내놓고 다시 대조하니 안 맞았다. 모델들은 내가 이미 사고 싶어 하는 종목에 대해 근거를 더 잘 정리해줬다. 충동이 줄어든 게 아니라 충동에 각주가 붙었다. 그래서 그 글의 제목은 "정정된 건 위험 목록이 아니라 내 전제였다"가 됐다.

여기서 중요한 건 다섯 번째 칸의 질문이 새로운 정보를 요구하는 질문이 아니었다는 점이다. 딥서치를 한 번 더 돌리라는 게 아니었다. 내가 처음에 뭘 참이라고 놓고 시작했는지를 꺼내라는 것이었다.

한 번 더. macOS 화면 공유 취약점이 터졌을 때 회사 네트워크가 느려졌길래 그 얘기를 썼다. 패치가 한꺼번에 몰린 낮이었으니 인과가 뻔해 보였다. 쓰다가 내 맥을 확인했는데 5900 포트가 열려 있었다. 그래서 글이 남 얘기에서 내 얘기로 바뀌었다.

그런데 그 글은 발행하고 나서 또 고쳤다. 커밋 로그에 fix(content)로 남아 있다. 화면 공유가 켜져 있던 이유를 나는 "설정을 방치했다"로 적었는데, 되짚어보니 방치가 아니라 원격 제어를 하려고 내가 직접 켠 거였다. 그 정정이 들어간 뒤에야 글이 맞는 말이 됐다.

루프는 발행 버튼을 눌러도 안 끝났다.

그렇다고 앞의 네 칸이 장식은 아니다

다섯 번째 칸이 결과를 바꾼다고 쓰고 나니, 그럼 앞의 네 칸은 왜 도느냐는 반문이 바로 붙는다.

내 경험으로는 재료 때문이다. 재질문은 무에서 나오지 않는다. "내가 뭘 전제했지"라는 물음이 유용해지려면, 그 전제를 반박할 수 있는 사실이 손에 있어야 한다. 사실이 없으면 재질문은 말 바꾸기에 그친다. 실제로 그런 적이 있다. 근거 없이 각도만 몇 번 틀다가 처음 결론으로 되돌아온 초안이 있었고, 그건 루프를 돈 게 아니라 제자리에서 회전한 것이었다.

딥서치와 학습 칸은 그래서 반박 재료를 쌓는 자리다. 분석 칸은 그 재료를 내 상황에 붙여보는 자리다. 여기까지가 잘 되어 있으면 다섯 번째 칸에서 던지는 질문이 구체적인 대상을 갖는다. 여기가 부실하면 다섯 번째 칸은 감상이 된다.

순서로 말하면 이렇다. 앞의 네 칸은 틀릴 수 있는 문장을 만드는 일이고, 다섯 번째 칸은 그 문장이 실제로 틀렸는지 보는 일이다. 둘 중 하나만 있으면 안 돈다.

절차를 문체 규칙인 줄 알고 파일에 박아뒀다

여기까지 세고 나서 하네스를 다시 열어봤다. 그리고 좀 웃었다.

blog-writing 스킬에 도입부 규칙이 있다. 내가 만들어 넣은 거다. 첫 문단은 네 박자로 잡으라고 되어 있다.

1. 동기 — 왜 이걸 하려 했는지
2. 시도 — 무엇을 했는지
3. 의도한 성공 — 목표 도달
4. 의도 안 한 새 문제 — 그런데 다른 데서 깨진 게 있음

나는 이걸 문체 규칙으로 넣었다. 결과부터 던지면 AI가 쓴 글처럼 읽히니까, 사람이 쓴 것처럼 보이게 하려고 호흡을 정해둔 거라고 생각했다.

지금 다시 보면 이건 문체 규칙이 아니다. 질문 절차다.

네 번째 박자를 채우려면 세 번째에서 멈추면 안 된다. 목표에 도달한 지점에서 한 번 더 물어야 한다. 잘된 것 말고 옆에서 깨진 게 뭐냐고. 그걸 안 물으면 4번 칸이 안 채워지고, 4번 칸이 비면 글이 안 써진다. 그래서 나는 매번 그걸 물었다. 문체 때문에 물었는데 결과적으로 절차를 돌린 셈이다.

경로를 되짚어보면 더 이상하다. 이 규칙이 스킬 파일에 들어가기 전에 메모리 파일로 먼저 적혔는데, 거기 붙어 있는 예시가 "사용자가 직접 다듬어준 도입"이라고 표시되어 있다. 어느 날 내가 초안 도입부를 손으로 고쳤고, 그걸 보고 규칙이 추출됐고, 추출된 규칙이 스킬로 승격돼서 이제는 매 글에 자동으로 적용된다.

내 손에서 나온 게 파일로 내려간 것이다. 앞에서 프롬프트 형식이 파일로 내려갔다고 썼는데, 같은 일이 한 층 위에서 또 일어나고 있었다. 다른 건 내가 그걸 의식하지 못했다는 점이다. 프롬프트가 내려갈 때는 알고 내렸는데, 이건 모르고 내렸다.

40편 중 21편에 "틀렸다"가 있는 건 이 규칙이 40번 강제로 발동한 결과다. 제목 14개가 뒤집혀 있는 것도 마찬가지다. 형식이 사라진 자리에 남은 게 문장이 아니라 순서였다는 증거를, 나는 내 손으로 파일에 적어두고도 몇 달을 못 알아봤다.

그런데 이 습관에는 붙어 있는 함정이 있다

반전이 나와야 글이 된다고 생각하면, 반전을 찾는 대신 만들어내게 된다.

내가 실제로 그랬다. 이 블로그의 애드센스 신청이 거절됐을 때 원인을 찾겠다고 발행 이력을 다 뽑았다. 4월 9일에 10편이 5분 만에, 4월 10일에 10편이 4분 만에, 4월 22일에 4편이 70초 만에, 5월 5일에 11편이 26분 만에 올라가 있었다. 나흘에 35편이었다.

숫자가 극적이었다. 5분에 10편이라는 건 누가 봐도 정상이 아니다. 그리고 거절 통보가 그 뒤에 왔다. 두 관측을 나란히 놓으니 인과가 보이는 것 같았다.

그래서 규칙을 만들었다. 하루 최대 1편. 문서에 L1 등급으로 박고 위반 금지라고 적었다.

두 번 지적받고 폐기했다. 구글 애드센스 프로그램 정책에 발행 빈도 조항이 없다. 거절 사유가 가리킨 건 그 35편의 길이 중앙값이 3,600자였고 이미지가 0장이었고 내부링크가 0개였다는 사실이다. 벌크 타이밍은 얇은 글이 한꺼번에 노출된 경로였을 뿐이다. 나는 같이 나타난 두 관측 중 눈에 띄는 쪽을 원인으로 굳혔다.

그 규칙이 살아 있는 동안, 조건을 다 갖춘 글이 "오늘 이미 한 편 올렸다"는 이유로 밀렸다. 반전을 찾는 습관이 반전을 만드는 습관으로 넘어간 자리가 정확히 거기다.

메모리 파일에도 남겨뒀다. 얇은 콘텐츠 이론에는 대조군이 없다고. 얇은 뉴스 카피 30편으로 승인된 사이트가 실제로 있고, 그러면 내 이론은 반례 앞에서 무너진다. 편수로 통과 확률을 계산하지 말라고 적어놨다.

두 습관을 가르는 선은 하나뿐이다. 셀 수 있냐.

"하루 1편" 규칙에는 셀 수 있는 근거가 없었다. 있었던 건 나흘 35편이라는 관측 하나와, 그걸 원인으로 읽고 싶은 내 마음이었다. 반면 이 글에 적은 21편, 17편, 9편은 지금 그 명령어를 다시 쳐도 같은 값이 나온다. 내가 뭐라고 주장하든 안 바뀐다.

반전 강박에는 두 번째 증상도 있다. 40편 중 20편, 정확히 절반의 제목에 숫자가 들어 있다. 0.36개 차이, 훅 12개 발화 0회, 7일과 40개월, 커밋 92%. 숫자가 들어가면 제목이 단단해 보인다. 그런데 그 숫자가 논지를 지탱하는 경우와, 논지는 따로 있고 숫자는 신뢰의 소품으로 붙어 있는 경우가 섞여 있다. 앞에서 말한 "하루 1편" 규칙도 나흘 35편이라는 숫자를 달고 있었다. 숫자가 붙어 있다고 셀 수 있는 주장이 되는 게 아니다. 세야 하는 건 결론 쪽이지 도입부 쪽이 아니다.

이 구분은 하네스에도 그대로 옮겨 적었다. 예전에는 발행 스크립트가 검수 브리프에서 "판정: 합격"이라는 문자열을 찾아서 통과 여부를 정했다. 그런데 그 문자열을 쓰는 건 검사받는 에이전트 자신이었다. 검문소와 통행증 발급처가 같았다. 지금은 파일을 열어서 세면 나오는 숫자만 게이트로 쓴다. 본문 글자수, 내부링크 개수, 자리표시 주석이 남았는지. 모델이 뭐라고 주장해도 값이 안 바뀌는 것들이다.

그래서 실제로 어떻게 묻는가

여기까지 오면 처음 질문으로 돌아온다. 어떻게 하면 효과적으로 질문하고 원하는 결과를 얻나. 페르소나 지정이 답이 아니라면 뭐가 답인가.

내가 실제로 쓰는 건 네 가지다. 넷 다 문장의 형식이 아니라 순서에 관한 것이다.

답 대신 세는 방법을 묻는다. "우리 훅이 제대로 도는가"라고 물으면 그럴듯한 진단이 온다. "이 훅이 제대로 돌았다면 로그에 뭐가 몇 개 찍혀 있어야 하나"라고 물으면 셀 대상이 온다. 나는 후자로 물어서 4개월간 발화 0회인 감시 훅 12개를 찾았고, 두 달 반 죽어 있던 게이트도 그렇게 찾았다. 앞의 질문으로는 절대 안 나왔을 것들이다. 진단은 읽고 나면 납득이 되고, 납득이 되면 확인을 안 하게 된다.

내 전제를 문장으로 꺼내서 같이 넘긴다. 이게 제일 자주 결과를 바꾼다. 대개 전제는 질문 안에 숨어 있고, 숨어 있는 동안에는 검증 대상이 아니다. "AI로 주식 리서치가 될까"에는 "AI가 내 충동을 줄여준다"가 숨어 있었다. 꺼내서 같이 던지는 순간 그것도 틀릴 수 있는 문장이 된다. 요령이랄 게 있다면, 질문을 쓰고 나서 "이 질문이 성립하려면 뭐가 이미 참이어야 하지"를 한 줄 적어보는 것 정도다.

확정과 추정의 경계를 명시적으로 요구한다. LLM은 확실한 것과 불확실한 것을 같은 문체로 쓴다. 표를 그리고 번호를 매기고 소수점 둘째 자리까지 적는다. 그래서 리서치를 시킬 때 확정과 추정을 나눈 표를 같이 내놓게 한다. 그 표가 없으면 나중에 재인용할 때 내가 추정을 사실로 옮겨 적는다. 실제로 그렇게 옮겨 적은 수치가 몇 개 있어서 지금은 인용 금지 목록으로 따로 관리한다. 2025년 설문인데 2차 매체를 타면서 2026년으로 표기된 채 도는 수치, 발표 자료에 그래프만 있고 1차 출처를 못 찾은 벤치마크 숫자 같은 것들이다.

결과를 받은 뒤에 "이게 틀리려면 뭐가 참이어야 하나"를 묻는다. 이게 다섯 번째 칸의 정체다. 답을 한 번 더 다듬어달라는 요청과는 다르다. 결론을 무너뜨릴 조건을 나열하게 만들고, 그중에 실제로 확인 가능한 게 있으면 확인하러 간다. 앞에 적은 애드센스 규칙은 이 질문을 안 던져서 여섯 주를 살아남았다.

다섯 번째를 굳이 붙이자면 언제 그만 묻는지다. 이게 없으면 앞의 네 가지가 그냥 지연이 된다. 반증 조건을 나열시키는 질문은 몇 번이고 다시 던질 수 있고, 던질 때마다 뭔가 나온다. 나오니까 계속 던지게 되고, 그러다 보면 글이 안 나간다.

내가 쓰는 기준은 남은 항목의 성격이다. 고칠 목록에 아직 "확인하면 값이 나오는 것"이 있으면 더 돈다. 남은 게 전부 "내가 판단해야 하는 것"이면 멈춘다. 판단은 한 바퀴 더 돈다고 나아지지 않고, 대개 한 바퀴 더 돌면 판단을 미룰 새 핑계가 하나 생긴다. 이 기준은 하네스에도 적어뒀는데, 실제로 지키는 건 매번 어렵다. 이 글도 두 번 더 돌 뻔했다.

네 가지 어디에도 역할 지정이 없다. 예시를 세 개 붙이라는 얘기도 없다. 전부 묻는 순서에 관한 것이다. 출력 형식 지정도 없다고 쓰려다 말았는데, 그건 다음 절에서 고쳐야 할 문장이 됐다.

그렇다고 옛날 공부가 헛것이었다는 얘기는 아니다. 화용론 하던 사람들이 지시문의 전제를 뜯어보던 그 작업이, 지금 내가 "내 전제를 문장으로 꺼낸다"고 부르는 것과 같은 일이다. 껍데기였던 부분은 자동화됐고, 알맹이였던 부분은 이름을 바꿔 남았다. 그때는 그 둘이 한 덩어리로 팔렸기 때문에 뭐가 껍데기였는지 구분할 방법이 없었을 뿐이다. 껍데기가 벗겨지는 데 3년이 걸렸고, 벗겨지고 나서야 안쪽이 보였다.

형식 지정 하나는 안 없어졌다

여기까지 써놓고 내가 오늘 실제로 친 프롬프트를 다시 봤다. 그리고 앞에서 한 말을 고쳐야 했다.

내가 요즘 쓰는 문장은 대체로 이 모양이다.

이러이러한 걸 하려고 해. 이걸 어떤 식으로 분석해서 어떤 결과를 알고 싶어. 결과는 파일로 받고 싶어.

네 조각이다. 하려는 일, 분석 방식, 알고 싶은 것, 받을 형태. 앞의 셋은 이 글 내내 말한 순서 쪽이다. 그런데 네 번째는 명백히 출력 형식 지정이다. 3년 전 프롬프트 템플릿에 있던 바로 그 항목이 아직 내 손끝에 남아 있었다.

앞 절에서 "네 가지 어디에도 출력 형식 지정이 없다"고 썼는데, 그건 내가 쓰는 걸 안 보고 쓴 문장이었다. 실제로는 매번 쓴다.

그런데 3년 전과 쓰는 이유가 다르다. 그때는 모델을 조종하려고 형식을 못 박았다. 번호를 매기고 섹션을 나눠야 답이 흐트러지지 않았으니까. 지금은 조종할 게 없다. 형식을 적는 건 내가 그 결과를 뒤에 어떻게 쓸지가 이미 정해져 있기 때문이다. 파일로 받으면 나중에 다시 열어서 다음 질문의 재료로 쓴다. 대화창 안에 두면 스크롤 뒤로 사라진다. 루프를 돌릴 생각이면 결과가 파일로 떨어져 있어야 한다.

그리고 요구하는 형태가 최근에 바뀌었다. 예전엔 거의 다 마크다운이었는데 요즘은 HTML로 달라고 하는 일이 훨씬 많다. 처음엔 별생각 없이 그렇게 됐는데, 되짚어보니 이유가 있었다.

마크다운은 다시 열어야 보인다. HTML은 열면 그대로 보인다. 표가 표로 보이고, 접었다 펼 수 있고, 도표를 그려 넣을 수 있고, 링크 하나로 남한테 넘길 수 있다. 분석 결과를 혼자 읽고 끝낼 거면 마크다운으로 충분한데, 며칠 뒤에 다시 보거나 남한테 보여줄 거면 HTML이 손이 덜 간다. 결과물의 수명이 길어질수록 형식 요구가 무거워지는 셈이다.

그러니까 살아남은 형식 지정은 모델을 향한 게 아니라 다음 차례의 나를 향한 것이다. 페르소나 지정은 모델이 문맥을 못 채워서 필요했고 그래서 없어졌다. 출력 형식 지정은 내가 결과를 어디에 쓸지 알아야 해서 필요하고, 그건 모델이 좋아진다고 없어지지 않는다.

역프롬프트라고 부르는 것

하나 더 있다. 나는 이걸 역프롬프트라고 부른다.

결과물을 하나 주고 이렇게 시킨다. "이 내용을 심층 분석해서, 이걸 만들어낼 프롬프트를 역산해줘." 남이 쓴 잘된 문서를 주고 시킬 때도 있고, 내가 쓴 걸 주고 시킬 때도 있다.

남의 걸로 하면 그 문서를 만든 사람이 뭘 정해놓고 시작했는지가 드러난다. 어떤 독자를 상정했는지, 뭘 당연하다고 놓고 건너뛰었는지, 어떤 순서로 밀었는지. 결과물만 봐서는 안 보이는데 프롬프트로 되돌리면 보인다.

내 걸로 하면 더 불편한 게 나온다. 나는 A를 주장하려고 썼다고 생각했는데, 역산된 프롬프트를 읽어보면 실제로는 B를 전제하고 쓴 글일 때가 있다. 이 글도 초반에 그랬다. 나는 "프롬프트 엔지니어링이 어떻게 됐나"를 묻고 있다고 생각했는데, 되돌려보니 "내가 헛공부한 게 아니라는 걸 확인하고 싶다"는 쪽에 더 가까웠다. 그 전제를 알고 나니 반대 사례를 일부러 찾게 됐고, 이 절 앞에 붙은 "형식 지정 하나는 안 없어졌다"가 그렇게 나왔다.

역프롬프트는 앞에서 말한 다섯 번째 칸의 변종이다. "내가 뭘 전제했지"를 직접 물으면 대개 그럴듯한 답을 내가 지어낸다. 자기 전제를 자기가 조회하는 건 잘 안 된다. 그런데 결과물을 통해 돌아오면 지어내기가 어렵다. 이미 쓴 문장이 증거로 있으니까.

잘 물어도 안 나오는 게 있다

여기까지 쓰고 보니 질문만 잘하면 다 되는 것처럼 읽힐 위험이 있어서 반대 사례를 하나 붙여야겠다.

언젠가 회사 일로 화가 나서 챗봇에 불만을 아홉 줄쯤 쏟은 적이 있다. 나름대로 잘 물었다. 상황을 시간순으로 정리했고, 내가 뭘 기대했고 뭐가 어긋났는지 적었고, 상대 입장에서 봤을 때 어떻게 보일지도 같이 물었다. 형식으로 보면 이 글에서 좋다고 말한 조건을 대체로 갖췄다.

답도 좋았다. 상황이 정리됐고, 내 감정에 이름이 붙었고, 상대의 행동을 설명할 만한 가설이 두어 개 나왔다. 읽고 나니 마음이 가라앉았다.

그런데 대화창을 닫고 나서 이상했다. 정작 그 사람한테 할 말은 한 문장도 안 만들어져 있었다. 아홉 줄을 쏟는 동안 필요한 게 해소돼버려서, 실제로 해야 할 대화를 할 동력이 사라진 것이다. 질문이 나빠서가 아니었다. 질문이 좋아서 그렇게 됐다.

이 자리는 순서를 고친다고 안 바뀐다. 세는 방법을 물어도, 전제를 꺼내놔도, 반증 조건을 나열시켜도 결과는 같다. 물어서 답이 나오는 종류의 문제가 아니었기 때문이다. 필요한 건 정보가 아니라 그 사람 앞에 앉는 일이었다.

그래서 질문법 얘기에는 경계선이 하나 필요하다. 사실로 답할 수 있는 질문과, 겪어야만 답이 되는 질문은 다른 종류다. 앞의 것에는 이 글에 쓴 네 가지가 먹힌다. 뒤의 것에는 안 먹히고, 잘 물을수록 오히려 진짜 할 일을 대신해버린다. 나는 이 구분을 한참 뒤에야 했고, 지금도 대화창을 열기 전에 매번 하지는 못한다. 구분이 필요하다는 걸 아는 것과 그 순간에 알아채는 것은 다른 일이다.

형식만 팔린 이유

처음으로 돌아가서, 왜 그때 강의가 팔렸는지를 다시 생각해봤다.

내 결론은 전달 가능한 것만 팔렸다는 쪽이다.

역할 지정은 문장으로 적을 수 있다. 출력 형식 지정도, 단계 분할도, 예시 세 개 붙이기도 마찬가지다. 슬라이드에 올리면 그대로 옮겨진다. 받는 사람이 복사해서 붙여넣으면 다음 날부터 쓴다. 효과도 그날 확인된다.

질문의 순서는 그렇게 안 된다. "결과를 받고 나서 이게 틀리려면 뭐가 참이어야 하는지 물어라"는 한 줄로 적을 수 있지만, 적어놔도 안 하게 된다. 그 질문을 던지는 순간은 답이 이미 그럴듯하게 나와 있는 순간이고, 그럴듯한 답 앞에서 한 번 더 의심하려면 이유가 필요하다. 그 이유는 대개 전에 한 번 크게 틀려본 기억이다. 기억은 문서로 안 옮겨진다.

나도 겪었다. AI 설계 얘기를 슬라이드 25장으로 정리해서 들고 다닌 적이 있는데, 반응이 거의 없었다. 반년쯤 지나서 같은 얘기가 커뮤니티에 돌기 시작했다. 자료가 부족해서 전달이 안 된 게 아니었다. 받는 쪽에 아직 손실이 없었을 뿐이다.

AX가 회사 단위로 도입되는데 실제 격차는 옆자리 사이에서 벌어진다는 얘기를 쓴 적이 있는데, 같은 구조다. 도입은 조직 단위로 되고 형식은 전사에 배포되는데, 정작 결과를 가르는 건 각자가 답을 받고 나서 한 번 더 묻느냐다. 그건 배포가 안 된다.

그러니까 3년 전 프롬프트 강의 시장은 사기였다기보다, 팔 수 있는 부분만 팔았던 시장에 가깝다. 팔리지 않은 나머지 절반이 지금 남은 것이고, 남은 이유는 그게 우월해서가 아니라 애초에 상품이 될 수 없었기 때문이다.

이름은 또 바뀔 것이다

프롬프트, 컨텍스트, 하네스, 루프. 접미사가 같아서 나란한 단어처럼 보이지만 실제로는 위로 쌓인 층이고, 층이 하나 쌓일 때마다 아래층은 자동화돼서 안 보이게 된다. 다음 이름이 뭐가 될지는 모르겠다.

확실한 건 지금 쓰는 것도 오래 안 간다는 쪽이다. 앞에서 말한 그 슬라이드 25장이 8월에는 이미 앞뒤가 안 맞았다. 방법론이 낡는 데 반년이 걸렸다. 40년 주기로 진로를 고르던 감각으로는 안 따라가진다.

그런데 40편을 세고 나서 조금 안심한 부분이 있다. 층이 네 번 바뀌는 동안 제목 뽑는 방식은 안 바뀌었다. 2026년 4월에 쓴 글도 8월에 쓴 글도 같은 자리에서 뒤집힌다. 도구가 다 바뀌고 파일 구조가 세 번 갈아엎어지는 동안, 물어보는 순서만 그대로였다.

이건 잘하고 있다는 얘기가 아니다. 21편에 "틀렸다"가 들어 있다는 건 21번 틀렸다는 뜻이다. 전제를 미리 꺼내놨으면 안 틀렸을 것도 그중에 몇 개 있다. 애드센스 규칙은 여섯 주를 버텼고, 문서에 적힌 결정과 코드의 동작이 석 달 동안 어긋나 있던 적도 있다. 그 어긋남을 밟은 건 사람이 아니라 문서를 읽은 에이전트였다.

그리고 이 글 안에도 아직 안 센 게 남아 있다. 제목 14편 중 7편은 내가 눈으로 골랐다고 위에 적어뒀는데, 눈으로 고르는 기준을 문장으로 못 적으면 그건 다음에 재현이 안 된다. 7월 전후로 비율이 20%p 올라간 것도 두 해석 중 어느 쪽인지 못 가렸다. 셀 수 있는 것만 주장하자고 해놓고, 이 글에도 못 센 채로 넘어간 자리가 두 군데 있는 셈이다.

이 글도 그렇다. 세어보기 전에는 다른 결론을 쓸 뻔했다. 프롬프트 엔지니어링은 거품이었고 이제 자연어면 충분하다는, 어디서 많이 본 문장으로 끝날 참이었다. 명령어 몇 줄이 그걸 막았다.

쓰는 도중에 한 번 더 걸렸다. 형식 지정은 다 없어졌다고 절반쯤 써놨는데, 오늘 내가 친 프롬프트를 다시 보니 파일로 달라는 요구가 매번 붙어 있었다. 그래서 절 하나를 더 붙여야 했다. 40편에서 21번 그랬듯이, 이 글도 자기가 하려던 주장에 자기가 반례였다.