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

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

맞는 말이라 할 말이 없었습니다. 저도 요즘 그렇게 씁니다. "당신은 20년 경력의 시니어 백엔드 개발자입니다"로 시작하는 프롬프트를 마지막으로 쓴 게 언제인지 기억이 안 납니다.

그런데 답을 받고 나니 기분이 좀 이상했습니다. 그럼 그때 그 공부는 뭐였나 싶었습니다. 역할 지정, 목적 명시, 사고 과정 유도, 예시 붙이기. 그런 걸 정리한 문서를 저도 몇 개 만들었고 팀에도 돌렸거든요. 헛공부였으면 화가 나야 할 것 같은데 화도 안 나고 그냥 허탈했습니다. 그때 열심히 외운 공식이 시험 범위에서 빠졌다는 얘기를 들은 기분이었습니다. 틀린 걸 배운 건 아닌데 쓸 데가 없어진 것 같은 느낌이요.

그래서 그 습관이 지금 제 글에 얼마나 남아 있는지 보고 싶어졌습니다. 이 블로그를 넉 달 넘게 에이전트로 돌렸으니 발행글 전체가 그 시절 습관의 화석이어야 할 것 같았습니다. 열어보니 프롬프트 형식의 흔적은 예상대로 거의 없었습니다. 그런데 찾던 거 말고 다른 게 걸렸습니다.

페르소나를 지정하던 때

2023년쯤을 떠올려보면 프롬프트는 거의 주문이었습니다. 역할을 먼저 주고, 목적을 적고, 출력 형식을 못 박고, 단계를 나눠 생각하게 하고, 예시를 두세 개 붙이고, 마지막에 확실하지 않으면 모른다고 답하라를 넣었습니다. 이걸 지키면 답이 실제로 좋아졌고 안 지키면 실제로 나빠졌습니다.

그때 쓰던 걸 하나 옮겨보면 이런 식이었습니다.

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

이 중에 지금 제가 손으로 쓰는 건 하나도 없습니다. 그냥 "이 파일 리뷰해줘" 칩니다. 그런데 결과는 그때보다 낫습니다.

그러니 강의가 팔렸던 것 같습니다. 이걸 냉소적으로 보는 사람들이 있고 저도 반쯤은 그쪽이었습니다. AI 양산 채널이 무너지고 나서 강의를 팔러 가는 경로를 한 편 쓸 만큼 그 판을 안 좋게 봤고, 바이브 코딩 강의를 결제하기 전에 읽으라는 글도 썼습니다.

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

지금 보면 그때 형식이 왜 필요했는지 알 것 같습니다. 모델이 문맥을 스스로 못 채웠습니다. 제가 무슨 상황에서 뭘 하려는지, 이 코드가 어느 프로젝트 건지, 앞에서 뭘 정했는지를 모델이 알 길이 없었으니 매번 손으로 채워 넣어야 했고, 그 채워 넣기를 정형화한 게 프롬프트 템플릿이었습니다. 형식은 문맥 대신 쓰던 거였고, 진짜 문맥이 들어오니까 물러난 것 같습니다. 안 통하게 된 게 아니라 통할 데가 없어진 거죠.

형식은 파일로 내려갔습니다

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

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

위의 그 프롬프트랑 맞대보면 거의 하나씩 대응됩니다. 역할 지정은 에이전트 정의 파일로, 출력 형식은 산출물 경로 계약으로, 단계 나누기는 스킬의 워크플로우 절로 갔습니다. 확실하지 않으면 추정이라고 적으라는 건 리서치 브리프의 확정·추정 구분표가 됐습니다.

토큰이 줄어드는 이유도 여기 있는 것 같습니다. 형식을 버려서 아끼는 게 아니라 같은 내용이 앞쪽 고정된 데 있으니 캐시에서 다시 읽히는 겁니다. 계획서 얘기를 쓸 때 제 세션 로그를 뽑아본 적이 있는데 매번 새로 쓰는 건 매번 새로 계산되고 파일에 들어가 있는 건 거의 공짜였습니다.

그러니까 형식이 없어진 게 아니라 있는 데가 바뀐 겁니다. 대화 안에 있던 게 저장소로 내려갔고, 내려간 뒤로는 제가 매번 신경 쓸 필요가 없어졌습니다. 사람들이 여기에 붙인 이름이 컨텍스트 엔지니어링이었고 그다음이 하네스 엔지니어링이었습니다. 제가 반년 넘게 이름도 모르고 짜놓은 게 사실 아웃터 루프였다는 걸 뒤늦게 알아챈 글도 있는데, 거기서 이 네 단어가 서로를 대신하는 게 아니라 위로 쌓인다고 썼습니다.

이번에 궁금했던 건 그다음입니다. 프롬프트가 파일로 내려가고, 파일이 하네스가 되고, 하네스 위에 루프가 올라갔습니다. 계속 아래로 내려가고 위로 쌓이는데 그럼 사람 손에 남는 건 뭔지. 이름이 네 번 바뀌는 동안 안 바뀐 게 있는지.

열어보고 좀 멍했습니다

제목만 쭉 훑었는데 절반 넘는 글이 같은 모양이었습니다. 무엇인 줄 알았는데 아니었다, 그렇게 믿었는데 다른 게 나왔다. 본문으로 내려가면 더해서 대부분의 글에 틀렸다는 말이 들어 있고, 틀린 사람은 대개 저였습니다.

멍했던 건 개수 때문이 아니었습니다. 저는 이걸 문체 취향이라고 생각하고 있었거든요. 반전 있는 제목이 클릭이 잘 나오니까 그렇게 뽑는다고, 어디서 배운 카피라이팅 습관이라고요.

그게 아니었습니다. 제목에 반전이 들어가는 건 글을 쓰다가 제 생각이 실제로 바뀌었기 때문이었습니다. 본문에 틀렸다가 들어 있는 건 그 글에서 제가 뭔가를 틀렸다고 적어야 했기 때문이고, 그건 대개 남이 아니라 저였습니다.

한 번 더 나눠봤더니 7월 이전보다 7월 이후 글에서 이 비중이 눈에 띄게 올라갔습니다. 7월 이후는 스킬과 규칙이 거의 정착한 뒤입니다. 이걸 습관이 굳은 거라고 봐야 할지 하네스가 시킨 거라고 봐야 할지는 모르겠습니다. 둘 다 결과는 똑같이 생겼거든요. 이럴 때 억지로 하나를 고르면 대개 제가 듣고 싶은 쪽을 고르게 돼서 이번엔 안 골랐습니다.

결과를 바꾼 건 다섯 번째 칸이었습니다

제가 AI를 쓰는 방식은 대충 이렇게 돕니다. 궁금한 게 하나 생기고, 깊게 찾아보게 시키고, 그 결과를 제가 공부하고, 공부한 걸로 분석을 시키고, 분석 결과를 들고 다시 질문을 만들고, 거기서 또 돕니다. 몇 바퀴 돌면 결과가 나옵니다.

그림으로 그리면 여섯 칸짜리 순환이라 그럴듯해 보이는데, 실제로 결과를 바꾸는 칸은 다섯 번째 하나였습니다.

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

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

다섯 번째 칸의 질문은 새 정보를 달라는 게 아니었습니다. 딥서치를 한 번 더 돌리라는 게 아니라 제가 처음에 뭘 참이라고 놓고 시작했는지를 꺼내라는 거였습니다.

한 번 더 있었습니다. macOS 화면 공유 취약점이 터졌을 때 회사 네트워크가 느려져서 그 얘기를 썼습니다. 패치가 한꺼번에 몰린 낮이었으니 이유가 뻔해 보였습니다. 쓰다가 제 맥을 봤더니 5900 포트가 열려 있었습니다. 그래서 글이 남 얘기에서 제 얘기가 됐습니다. 그런데 그 글은 발행하고 나서 또 고쳤습니다. 화면 공유가 켜져 있던 이유를 설정을 방치했다고 적었는데, 되짚어보니 방치가 아니라 원격 제어를 하려고 제가 직접 켠 거였습니다. 그걸 고치고 나서야 글이 맞는 말이 됐습니다. 발행 버튼을 눌러도 루프는 안 끝났습니다.

앞의 네 칸이 필요 없다는 얘기는 아닙니다. 다시 묻는 건 아무것도 없는 데서 나오지 않았습니다. 내가 뭘 전제했지라는 질문이 쓸모 있으려면 그 전제를 반박할 사실이 손에 있어야 합니다. 사실이 없으면 다시 묻는 건 말 바꾸기에 그칩니다. 실제로 근거 없이 각도만 몇 번 틀다가 처음 결론으로 돌아온 초안이 있었는데, 그건 루프를 돈 게 아니라 제자리에서 빙빙 돈 거였습니다.

딥서치와 공부하는 칸은 반박할 재료를 모으는 칸이고, 분석하는 칸은 그 재료를 제 상황에 대보는 칸인 것 같습니다. 여기가 잘돼 있으면 다섯 번째 칸에서 던지는 질문에 구체적인 대상이 생기고, 여기가 부실하면 다섯 번째 칸은 감상이 됩니다. 앞의 넷은 틀릴 수 있는 문장을 만드는 일이고 다섯 번째는 그 문장이 정말 틀렸는지 보는 일이라, 하나만 있으면 안 도는 것 같습니다.

문체 규칙인 줄 알았던 것

여기까지 보고 하네스를 다시 열어봤는데 좀 웃겼습니다.

blog-writing 스킬에 도입부 규칙이 있었습니다. 제가 넣은 거였습니다. 첫 문단을 네 박자로 잡으라는 거였고 동기, 시도, 의도한 성공, 그리고 의도 안 한 새 문제였습니다. 저는 이걸 문체 규칙으로 넣었습니다. 결과부터 던지면 AI가 쓴 글처럼 읽히니까 사람이 쓴 것처럼 보이게 호흡을 정해둔 거라고 생각했습니다.

다시 보니 이건 문체 규칙이 아니라 질문하는 순서였습니다. 네 번째 박자를 채우려면 세 번째에서 멈추면 안 됩니다. 목표에 닿은 데서 한 번 더 물어야 합니다. 잘된 것 말고 옆에서 망가진 게 뭐냐고요. 그걸 안 물으면 네 번째가 안 채워지고 네 번째가 비면 글이 안 써집니다. 그래서 저는 매번 그걸 물었습니다. 문체 때문에 물었는데 하고 보니 질문 순서를 돌린 셈이었습니다.

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

제 손에서 나온 게 파일로 내려간 겁니다. 프롬프트 형식이 파일로 내려간 것과 같은 일이 한 층 위에서 또 있었던 건데, 다른 건 이번엔 제가 몰랐다는 겁니다. 프롬프트는 알고 내렸는데 이건 모르고 내렸습니다. 형식이 사라지고 남은 게 문장이 아니라 순서였다는 걸 제 손으로 파일에 적어두고도 몇 달을 못 알아봤습니다.

이 습관에 붙은 함정

반전이 있어야 글이 된다고 생각하면 반전을 찾는 대신 만들게 됩니다. 제가 그랬습니다.

이 블로그의 애드센스 신청이 거절됐을 때 원인을 찾겠다고 발행 이력을 다 뽑았습니다. 나흘 사이에 서른다섯 편이 올라가 있었고 5분에 열 편씩 쏟아진 날도 있었습니다. 숫자가 극적이었습니다. 5분에 열 편은 누가 봐도 정상이 아니고, 거절 통보는 그 뒤에 왔습니다. 둘을 나란히 놓으니 인과가 보이는 것 같았습니다. 그래서 하루 최대 1편이라는 규칙을 만들고 문서에 위반 금지라고 적어뒀습니다.

두 번 지적받고 버렸습니다. 애드센스 프로그램 정책에 발행 빈도 조항은 없습니다. 몰아서 올린 건 얇은 글이 한꺼번에 노출된 경로였을 뿐이었습니다. 같이 나타난 두 가지 중 눈에 띄는 쪽을 원인으로 굳혔던 겁니다. 그 규칙이 살아 있는 동안 조건을 다 갖춘 글이 오늘 이미 한 편 올렸다는 이유로 밀렸습니다. 반전을 찾던 습관이 반전을 만드는 습관으로 넘어간 게 그때였던 것 같습니다.

무서운 건 만든 반전도 쓰는 사람한테는 발견처럼 느껴진다는 겁니다. 규칙을 적던 날 저는 뭔가 알아냈다고 생각했습니다. 여섯 주 뒤에 지적받고 나서야 그게 발견이 아니라 제가 보고 싶었던 그림이라는 걸 알았습니다.

그 일을 겪고 나서 저는 셀 수 있는 것만 주장한다를 원칙처럼 삼았습니다. 하루 1편 규칙에는 셀 수 있는 근거가 없었고, 있었던 건 관측 하나와 그걸 원인으로 읽고 싶은 제 마음이었으니까요. 셀 수 있느냐를 기준으로 삼으면 저런 실수는 안 나올 거라고 생각했습니다.

게이트에는 그게 맞았습니다. 예전에는 발행 스크립트가 검수 브리프에서 판정: 합격이라는 문자열을 찾아서 통과를 정했는데, 그 문자열을 쓰는 게 검사받는 에이전트 자신이었습니다. 검문소랑 통행증 발급처가 같았던 거죠. 지금은 파일을 열어서 세면 나오는 것만 게이트로 씁니다. 모델이 뭐라고 해도 값이 안 바뀌는 것들입니다.

그런데 글에는 안 맞았고 저는 그 둘을 한동안 구분 안 하고 밀었습니다. 셀 수 있는 것만 쓰겠다고 하면 글이 점점 센 것들로 채워집니다. 몇 시간 걸렸고, 몇 번 틀렸고, 몇 편 중 몇 편이었고. 단단해 보이는데 다 쓰고 읽어보면 제가 뭘 느꼈는지가 한 줄도 없습니다. 들어갈 데가 없어서요.

삽질 여덟 시간으로 말하면 이렇습니다. 8시간 소요라고 쓰면 그건 데이터입니다. 실제로 그 여덟 시간은 이렇게 갑니다. 한 시간쯤엔 왜 안 되지고, 두 시간쯤 되면 입에서 욕이 나오고, 네 시간이면 열이 뻗치고, 여섯 시간쯤 지나면 이게 나랑 해보자는 건가 싶어지고, 여덟 시간을 넘기면 빡쳐서 그만두거나 해탈합니다. 같은 여덟 시간인데 앞의 건 숫자 하나고 뒤의 건 읽는 사람이 자기 일처럼 아는 곡선입니다. 겪어본 사람은 남의 글에서 그걸 바로 알아봅니다. 여섯 시간쯤 지나서라고만 써도 압니다. 반대로 시간을 정확히 적어놔도 그 곡선이 없으면 아무도 자기 얘기로 안 읽습니다.

세는 건 게이트가 할 일이고 글이 할 일은 다른 것 같습니다. 그 둘을 한동안 같은 원칙으로 묶어놔서 제 글이 오래 딱딱했습니다.

그래서 요즘 묻는 방식

처음 질문으로 돌아가면, 어떻게 물어야 원하는 걸 얻느냐입니다. 페르소나 지정이 아니면 뭔지.

요즘 제가 실제로 하는 건 문장 형식보다는 순서에 가깝습니다.

답 대신 확인하는 방법을 묻습니다. 우리 훅이 제대로 도느냐고 물으면 그럴듯한 진단이 옵니다. 이 훅이 제대로 돌았다면 로그에 뭐가 남아 있어야 하느냐고 물으면 확인할 대상이 옵니다. 뒤쪽으로 물어서 넉 달 동안 한 번도 안 울린 감시 훅들을 찾았고, 두 달 반 죽어 있던 게이트도 그렇게 찾았습니다. 앞쪽으로 물었으면 절대 안 나왔을 것들입니다. 진단은 읽으면 납득이 되고 납득이 되면 확인을 안 하게 되니까요.

제 전제를 문장으로 꺼내서 같이 넘깁니다. 이게 제일 자주 결과를 바꿨습니다. 전제는 대개 질문 안에 숨어 있고 숨어 있는 동안은 아무도 안 봅니다. AI로 주식 리서치가 될까에는 AI가 내 충동을 줄여준다가 숨어 있었습니다. 꺼내서 같이 던지면 그것도 틀릴 수 있는 문장이 됩니다. 요령이라면 질문을 쓰고 나서 이 질문이 성립하려면 뭐가 이미 참이어야 하지를 한 줄 적어보는 정도입니다.

확정과 추정을 나눠 달라고 합니다. LLM은 확실한 것과 불확실한 걸 같은 문체로 씁니다. 표를 그리고 번호를 매기고 소수점 아래까지 적습니다. 그래서 리서치를 시킬 때 둘을 나눠 내놓게 합니다. 안 그러면 나중에 다시 인용할 때 제가 추정을 사실로 옮겨 적습니다. 실제로 그렇게 옮긴 게 몇 개 있어서 지금은 인용 금지 목록을 따로 두고 있습니다.

결과를 받은 다음에 이게 틀리려면 뭐가 참이어야 하느냐고 묻습니다. 다섯 번째 칸이 결국 이겁니다. 답을 한 번 더 다듬어달라는 거랑은 다릅니다. 결론을 무너뜨릴 조건을 늘어놓게 하고 그중 실제로 확인할 수 있는 게 있으면 확인하러 갑니다. 애드센스 규칙은 이 질문을 안 해서 여섯 주를 살아남았습니다.

언제 그만 물을지도 정해둬야 하는 것 같습니다. 그게 없으면 앞의 것들이 그냥 지연이 됩니다. 반증 조건을 늘어놓게 하는 질문은 몇 번이고 다시 할 수 있고 할 때마다 뭔가 나옵니다. 나오니까 또 하게 되고 그러다 글이 안 나갑니다. 저는 남은 항목이 어떤 건지를 봅니다. 고칠 목록에 아직 확인하면 답이 나오는 게 있으면 더 돌고, 남은 게 다 제가 판단해야 하는 거면 멈춥니다. 판단은 한 바퀴 더 돈다고 나아지지 않고, 대개 한 바퀴 더 돌면 판단을 미룰 핑계가 하나 더 생깁니다. 하네스에도 적어뒀는데 실제로 지키는 건 매번 어렵습니다. 이 글도 두 번 더 돌 뻔했습니다. 한 바퀴 더 돌면 더 좋은 글이 될 것 같은 느낌은 거의 매번 들고, 그 느낌이 맞은 적은 생각보다 적었습니다.

여기 어디에도 역할 지정은 없습니다. 예시를 세 개 붙이라는 것도 없습니다. 다 묻는 순서에 관한 겁니다. 화용론 하던 사람들이 지시문의 전제를 뜯어보던 일이 지금 제가 전제를 문장으로 꺼낸다고 부르는 거랑 같은 일이라, 옛날 공부가 다 헛것이었던 것 같지는 않습니다. 껍데기는 자동화됐고 알맹이는 이름을 바꿔 남았습니다. 그때는 둘이 한 덩어리로 팔려서 뭐가 껍데기인지 알 길이 없었을 뿐입니다.

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

출력 형식 지정도 없다고 쓰려다가 오늘 실제로 친 프롬프트를 다시 봤습니다. 요즘 제가 쓰는 문장은 대체로 이런 모양입니다.

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

네 조각입니다. 하려는 일, 분석 방식, 알고 싶은 것, 받을 형태. 앞의 셋은 이 글 내내 말한 순서 쪽인데 네 번째는 누가 봐도 출력 형식 지정입니다. 3년 전 템플릿에 있던 바로 그 항목이 아직 손끝에 남아 있었습니다. 저는 매번 그걸 쓰면서도 안 쓴다고 생각하고 있었습니다.

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

받는 형태도 요즘 바뀌었습니다. 예전엔 거의 다 마크다운이었는데 요즘은 HTML로 달라고 하는 일이 훨씬 많습니다. 처음엔 별생각 없이 그렇게 됐는데 되짚어보니 이유가 있었습니다. 마크다운은 다시 열어야 보이고 HTML은 열면 그대로 보입니다. 표가 표로 보이고, 접었다 펼 수 있고, 도표를 넣을 수 있고, 링크 하나로 남한테 넘길 수 있습니다. 혼자 읽고 끝낼 거면 마크다운으로 충분한데 며칠 뒤에 다시 보거나 남한테 보여줄 거면 HTML이 손이 덜 갑니다. 결과물이 오래 갈수록 형식 요구가 무거워지는 것 같습니다. 대화창에서 끝날 답이면 아무렇게나 받아도 되는데 일주일 뒤에 다시 열 답이면 처음부터 열기 좋은 모양으로 받아야 합니다.

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

역프롬프트

하나 더 있습니다. 저는 이걸 역프롬프트라고 부릅니다. 결과물을 주고 이 내용을 깊게 분석해서 이걸 만들어낼 프롬프트를 거꾸로 짜보라고 시킵니다. 남이 쓴 잘된 문서로 할 때도 있고 제 글로 할 때도 있습니다.

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

제 걸로 하면 더 불편한 게 나옵니다. A를 말하려고 썼다고 생각했는데 거꾸로 짠 프롬프트를 읽어보면 실제로는 B를 깔고 쓴 글일 때가 있습니다. 이 글도 초반에 그랬습니다. 프롬프트 엔지니어링이 어떻게 됐나를 묻고 있다고 생각했는데 되돌려보니 내가 헛공부한 게 아니라는 걸 확인하고 싶다는 쪽에 더 가까웠습니다. 그걸 알고 나니 좀 민망했고, 그다음에 반대 사례를 일부러 찾다가 형식 지정 하나는 안 없어졌다는 게 나왔습니다.

역프롬프트는 다섯 번째 칸의 변형 같습니다. 내가 뭘 전제했지를 직접 물으면 대개 그럴듯한 답을 제가 지어냅니다. 자기 전제를 자기가 들여다보는 건 잘 안 됩니다. 결과물을 거쳐서 돌아오면 지어내기가 어렵습니다. 이미 쓴 문장이 증거로 남아 있으니까요.

잘 물어도 안 나오는 것

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

답도 좋았습니다. 상황이 정리됐고 제 감정에 이름이 붙었고 상대가 왜 그랬을지 가설이 두어 개 나왔습니다. 읽고 나니 마음이 가라앉았습니다.

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

이건 순서를 고쳐도 안 바뀝니다. 확인하는 방법을 물어도, 전제를 꺼내놔도, 반증 조건을 늘어놓게 해도 같습니다. 물어서 답이 나오는 문제가 아니었으니까요. 필요한 건 정보가 아니라 그 사람 앞에 앉는 일이었습니다. 사실로 답할 수 있는 질문과 겪어야만 답이 되는 질문은 종류가 다른 것 같습니다. 앞의 것에는 위에 쓴 것들이 먹히는데 뒤의 것에는 안 먹히고, 잘 물을수록 진짜 할 일을 대신해버립니다. 저는 이걸 한참 뒤에야 구분했고 지금도 창을 열기 전에 매번 하지는 못합니다. 구분해야 한다는 걸 아는 거랑 그 순간에 알아채는 건 다른 일이더군요.

형식만 팔린 이유

처음으로 돌아가서 그때 왜 강의가 팔렸는지를 다시 생각해보면, 옮길 수 있는 것만 팔렸던 것 같습니다.

역할 지정은 문장으로 적을 수 있습니다. 출력 형식, 단계 나누기, 예시 세 개도 마찬가지입니다. 슬라이드에 올리면 그대로 옮겨지고, 받은 사람이 복사해서 붙여넣으면 다음 날부터 쓰고, 효과도 그날 보입니다.

질문 순서는 그렇게 안 됩니다. 결과를 받고 나서 이게 틀리려면 뭐가 참이어야 하는지 물어라는 한 줄로 적을 수는 있는데 적어놔도 안 하게 됩니다. 그 질문을 할 때는 이미 답이 그럴듯하게 나와 있고, 그럴듯한 답 앞에서 한 번 더 의심하려면 이유가 필요합니다. 그 이유는 대개 전에 크게 한 번 틀려본 기억이고, 기억은 문서로 안 옮겨집니다. 남이 크게 틀린 얘기를 들어도 그건 남의 얘기라, 제가 틀려보기 전까지는 그 질문을 할 이유가 안 생깁니다.

저도 겪었습니다. AI 설계 얘기를 슬라이드로 정리해서 들고 다닌 적이 있는데 반응이 거의 없었습니다. 반년쯤 지나서 같은 얘기가 커뮤니티에 돌기 시작했습니다. 자료가 모자라서 안 먹힌 게 아니라 받는 쪽에 아직 잃은 게 없었을 뿐이었습니다. AX가 회사 단위로 들어오는데 실제 격차는 옆자리 사이에서 벌어진다는 얘기도 같은 모양입니다. 도입은 조직 단위로 되고 형식은 전사에 배포되는데 결과를 나누는 건 각자가 답을 받고 한 번 더 묻느냐이고, 그건 배포가 안 됩니다.

3년 전 프롬프트 강의 시장은 사기였다기보다 팔 수 있는 부분만 판 시장에 가까웠던 것 같습니다. 안 팔린 나머지 절반이 지금 남은 거고, 남은 건 그게 더 나아서가 아니라 처음부터 상품이 될 수 없어서였습니다.

이름은 또 바뀔 겁니다

프롬프트, 컨텍스트, 하네스, 루프. 뒤에 붙는 말이 같아서 나란한 단어처럼 보이는데 실제로는 위로 쌓인 층이고, 하나 쌓일 때마다 아래층은 자동화돼서 안 보이게 됩니다. 다음 이름이 뭘지는 모르겠습니다. 지금 쓰는 것도 오래 안 갈 것 같습니다. 그 슬라이드가 반년 만에 앞뒤가 안 맞았으니 방법론이 낡는 데 반년이면 충분했던 겁니다. 40년 주기로 진로를 고르던 감각으로는 못 따라갈 것 같습니다.

그래도 40편을 열어보고 조금 안심한 게 있습니다. 층이 네 번 바뀌는 동안 제목 뽑는 방식은 안 바뀌었습니다. 4월 글도 8월 글도 같은 데서 생각이 바뀝니다. 도구가 다 바뀌고 파일 구조를 세 번 갈아치우는 동안 묻는 순서만 그대로였습니다.

절반 넘는 글에 틀렸다가 들어 있다는 건 그만큼 틀렸다는 얘기기도 합니다. 전제를 미리 꺼내놨으면 안 틀렸을 것도 그중에 몇 개 있습니다. 애드센스 규칙은 여섯 주를 버텼고, 문서에 적힌 결정이랑 코드 동작이 석 달 동안 어긋나 있던 적도 있었습니다. 그 어긋남을 밟은 건 사람이 아니라 문서를 읽은 에이전트였습니다. 7월 전후로 비중이 올라간 게 습관 때문인지 하네스 때문인지도 저는 아직 모릅니다.

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