모델이 좋아질수록 지침은 왜 얇아지는가

Thariq Shihipar는 X에 이상적인 프롬프팅 방식을 세 줄로 정리했습니다.
얇은 프롬프트, 두꺼운 산출물과 맥락, 얇은 스킬.
이 문장을 “프롬프트를 짧게 쓰라”는 요령으로 읽으면 핵심을 놓칩니다. 모델이 좋아질수록 사람과 모델 사이에서 정보가 놓이는 자리가 달라진다는 뜻에 가깝습니다.
예전에는 사람이 작업 순서를 자세히 적었습니다. 이제 모델은 일반적인 작업 순서를 더 많이 스스로 구성합니다. 사람은 그 대신 무엇을 이루려는지, 현실에 어떤 제약이 있는지, 무엇을 좋은 결과로 볼지를 더 분명하게 알려줘야 합니다.
상세한 지침은 부족한 판단력을 보완했다
예전 모델은 한 단계씩 떼어 놓은 일은 곧잘 처리했지만, 여러 단계를 이어서 판단하는 데 약했습니다. 목표를 오래 붙들지 못했고, 조사해야 할 때 바로 수정하거나, 검증해야 할 때 일찍 끝냈습니다.
그래서 사람은 모델이 놓칠 만한 절차를 지침으로 밖에 꺼내 놓았습니다.
| 사람이 적어 준 절차 | 보완하려던 실패 |
|---|---|
| 먼저 관련 파일을 찾아라 | 충분히 조사하지 않고 시작함 |
| 수정 전에 원인을 확인하라 | 첫 가설을 곧바로 정답으로 여김 |
| 작업이 끝나면 테스트하라 | 결과를 확인하지 않고 완료를 선언함 |
| 실패하면 원인을 고쳐 다시 실행하라 | 한 번 실패한 뒤 멈춤 |
이런 지침은 틀린 방법이 아니었습니다. 당시 모델의 판단력을 보완하는 발판이었습니다. 문제는 발판이 필요 없어진 뒤에도 그대로 남을 수 있다는 점입니다.
판단이 이어지기 시작했다
발판이 왜 필요 없어졌는지 보려면, 모델이 좋아질 때 정확히 무엇이 좋아지는지를 봐야 합니다.
버그를 고치는 일을 생각해 보겠습니다. 일을 받으면 갈림길이 계속 나타납니다. 증상부터 재현할까, 코드를 더 읽을까, 로그를 볼까. 고친 뒤에는 어떤 테스트면 충분할까. 결과가 예상과 다르면 첫 가설을 버리고 어디까지 되돌아갈까. 여기에 필요한 것은 파일을 고치는 능력이 아니라, 갈림길마다 다음 행동을 고르고 결과를 보고 계획을 고치는 능력입니다.
앞의 표를 다시 보면, 네 가지 실패는 사실 하나입니다. 조사 없이 시작하는 것은 첫 판단을 건너뛴 것이고, 첫 가설을 고집하는 것은 결과를 보고도 판단을 고치지 않은 것입니다. 확인 없이 끝내는 것은 마지막 판단을 생략한 것이고, 실패한 뒤 멈추는 것은 끊어진 판단을 다시 잇지 못한 것입니다. 전부 판단이 다음 판단으로 이어지지 못하고 끊긴 자리입니다.
새 모델은 이 연결이 눈에 띄게 길고 안정적입니다. 사람으로 치면 신입과 경력자의 차이입니다. 신입에게는 일의 순서를 적어 주지만, 경력자에게는 목표와 사정만 말합니다. 차이는 각 단계를 할 줄 아느냐가 아니라, 다음 단계를 스스로 고를 수 있느냐에 있습니다.
물론 더 똑똑해져서 무조건 알아서 잘한다는 뜻은 아닙니다. 일반적인 절차를 스스로 구성할 수 있는 범위가 넓어졌다는 뜻입니다. 그래도 이 차이가 중요합니다. 모델이 이미 안정적으로 해내는 절차를 지침으로 계속 강제하면 도움이 되지 않습니다. 상황에 맞는 더 나은 길을 고를 여지를 오히려 막습니다. 발판이 걸림돌로 바뀌는 자리입니다.
얇은 지침, 두꺼운 맥락, 얇은 스킬
지침이 얇아진다는 것은 정보가 줄어든다는 뜻이 아닙니다. 정보의 중심이 방법에서 현실로 이동한다는 뜻입니다.
얇은 지침에는 목표와 이유, 바꾸면 안 되는 제약, 완료 기준을 담습니다. “어떻게”를 낱낱이 지정하기보다 “무엇을 왜 이루어야 하는지”를 선명하게 만듭니다. 얇다는 말은 막연하다는 뜻이 아니라, 판단에 꼭 필요한 정보만 압축해서 준다는 뜻입니다.
두꺼운 맥락에는 실제 코드, 데이터, 화면, 프로토타입, 좋은 사례, 이전 결정, 사용자 반응 같은 산출물을 담습니다. 모델은 우리가 말하지 않은 현실을 알 수 없습니다. 현실을 충분히 보여줄수록 모델이 추측으로 메워야 하는 빈칸이 줄어듭니다.
얇은 스킬에는 모델이 원래 아는 일반 지식이 아니라 이 조직과 작업에서만 알 수 있는 내용을 담습니다. 내부 도구를 쓰는 법, 자주 빠지는 함정, 안전 규칙, 검증 방법이 여기에 속합니다.
이 셋은 한 번 채우고 끝나지 않습니다. 실행 결과와 반복된 실패가 다시 다음 작업의 맥락이 됩니다.
하네스는 더하기보다 걷어내며 좋아진다
이 재배치는 지침 한 장에서 끝나지 않습니다. 그때그때 건네는 프롬프트가 한 번의 지시라면 스킬은 늘 실어 두는 지침이고, 하네스는 이 모두를 담는 작업 환경입니다. 지침뿐 아니라 도구, 파일, 상태, 반복 방식, 검증 절차까지 포함합니다. 그리고 같은 원리가 이 구조 전체에 적용됩니다.
약한 모델을 위해 만든 하네스에는 작업 순서를 고정하는 장치가 많습니다. 새 모델이 그 순서를 스스로 구성하게 되면 예전 장치는 중복되거나 방해가 됩니다. 반대로 긴 작업의 상태를 보존하고, 실제 시스템에서 결과를 검증하고, 위험한 행동을 막는 장치는 모델이 좋아져도 남습니다.
그래서 하네스는 새 모델이 나올 때마다 시험대에 오릅니다. 일반 절차를 강제하는 지침을 하나씩 덜어내고, 실제 작업으로 결과를 비교하고, 반복해서 나타나는 실패를 막는 지식과 도구와 검증만 남기는 것입니다.
| 덜어낼 가능성이 큰 것 | 계속 남겨야 할 것 |
|---|---|
| 모델이 안정적으로 수행하는 일반 절차 | 조직과 제품에만 있는 사실 |
| 모든 상황에 같은 순서를 강제하는 규칙 | 실제로 반복된 함정과 실패 사례 |
| 이미 아는 내용을 되풀이하는 설명 | 안전과 권한에 관한 단단한 경계 |
| 과거 모델의 약점에 맞춘 임시 장치 | 결과를 확인하는 테스트와 증거 |
좋은 하네스는 규칙이 많은 하네스가 아닙니다. 모델이 스스로 판단해도 되는 부분과 시스템이 반드시 보장해야 하는 부분을 정확히 나눈 하네스입니다.
사람은 지시에서 미지수 찾기로 옮겨 간다
그 경계를 긋는 일은 사람의 몫입니다. 모델이 방법을 잘 고르게 될수록 사람의 일은 사라지는 게 아니라 자리를 옮깁니다. 작업 순서를 적는 데서, 어떤 문제를 풀지와 무엇이 아직 정해지지 않았는지를 찾는 데로 갑니다.
모델은 주어진 목표 안에서 좋은 방법을 고릅니다. 하지만 어떤 결과가 사업에 중요한지, 어떤 위험을 감수할 수 있는지, 사용자가 무엇을 불편해하는지는 저절로 알지 못합니다. 이것은 모델의 일반 지식이 아니라, 지금 이 일을 맡긴 사람만 가진 현실입니다.
Thariq는 미지수를 찾는 법을 다룬 글에서 프롬프트, 스킬, 맥락을 지도에 비유합니다. 실제 코드와 현실은 영토입니다. 지도에 없는 부분을 만나면 모델은 멈추지 않고 가장 그럴듯한 답을 추측합니다. 여기에 함정이 있습니다. 강한 모델일수록 추측이 자연스러워 보여서 빈칸이 눈에 잘 띄지 않습니다. 지침이 얇아질수록 사람이 빈칸을 알아차리는 일은 더 중요해집니다.
그렇다고 모든 중간 단계를 승인할 필요는 없습니다. 붙들어야 할 것은 결과를 크게 바꾸는 결정과 실패 비용이 큰 지점입니다. 취향, 우선순위, 비용, 위험은 정답이 하나로 정해진 문제가 아니기 때문입니다.
일반적인 작업 절차는 점점 모델 안으로 들어갑니다. 그러나 목표와 맥락, 취향과 책임은 저절로 생기지 않습니다. 하네스도 사라지지 않습니다. 모델을 끌고 가는 고정된 레일에서, 모델이 현실을 보고 스스로 판단하도록 돕는 환경으로 바뀔 뿐입니다.
이 흐름을 한 문장으로 줄이면 이렇습니다.
모델이 좋아질수록 방법을 덜 지시하고, 현실을 더 많이 보여주며, 좋은 결과의 기준을 더 분명히 정해야 합니다.