AI 에이전트에게 일을 시킬 때, 지시가 잘 안 먹히면 우리는 보통 프롬프트를 더 강하게 씁니다. MANDATORY, DO NOT SKIP 같은 대문자 명령을 붙이고, “이 Skill만 깔면 해결된다”는 도구에 기대를 겁니다. 그런데 비슷한 시기에 나온 두 개발자의 글은 정반대 방향에서 같은 결론에 도달했습니다. 프롬프트로 모든 걸 해결하려는 시도에는 천장이 있다는 것입니다.
한쪽은 머신러닝 엔지니어 Skylar Payne의 글입니다. 에이전트가 반드시 지켜야 할 단계를 프롬프트에 욱여넣지 말고, 시스템이 직접 검증할 수 있는 코드로 옮기라고 말합니다. 다른 한쪽은 Scott Logic의 기술 블로그로, 1주일 만에 GitHub 별 2만 개를 받은 인기 Skill ‘Ponytail’을 뜯어보고 그 실체가 7단어짜리 문구로 대체 가능했다는 검증을 내놓습니다. 둘을 나란히 놓으면 “프롬프트에 무엇을 맡기고 무엇을 맡기지 말아야 하는가”라는 하나의 질문이 보입니다.
출처:
- If It Has to Happen, Don’t Put It in the Prompt – Skylar Payne
- Ponytail? YAGNI! – Scott Logic
대문자로 소리쳐도 모델은 단계를 빠뜨린다
Payne은 코드 변경을 에이전트에게 맡길 때 원하는 작업 순서가 있습니다. 깨끗한 작업 공간을 만들고, 거기서만 코드를 고치고, 변경 내용을 요청과 대조하고, 검증을 돌리고, 화면을 캡처하고, 그 증거를 모아 보고하는 흐름입니다. 코드 수정은 그중 한 조각일 뿐입니다.
그래서 이 단계들을 프롬프트에 적습니다. 평소에는 모델이 잘 따릅니다. 문제는 예상 밖의 일이 생길 때입니다. 테스트가 실패해 조사가 필요하거나, 캡처한 화면에 시각적 문제가 있거나, 데이터베이스가 예상보다 늦게 뜨는 순간, 모델은 단계 하나를 슬쩍 빠뜨리기 쉽습니다. 검증이 마지막 수정 이전 상태에서 돌아갔을 수도 있고, 캡처가 옛날 화면을 담고 있을 수도 있습니다. 쓸모 있는 일을 다 해놓고도 정작 중요한 요구사항 하나를 놓치는 식입니다.
그러면 우리는 프롬프트를 더 세게 씁니다. DO NOT SKIP, MANDATORY, HARD RULE. NO EXCEPTIONS. Payne은 여기서 개발자 Brian Suh의 표현을 빌려옵니다. 만약 당신이 MANDATORY 같은 단어를 쓰기 시작했다면, 이미 프롬프팅의 천장에 부딪힌 것이라고요. 질문을 바꿔야 합니다. “어떻게 하면 이 프롬프트를 더 강하게 만들까”가 아니라 “왜 이게 아직도 그냥 프롬프트인가”로요.
핵심은 간단합니다. 텍스트는 요청할 수 있지만 강제할 수는 없습니다. 프롬프트는 작업 공간이 모델 편집 전에 존재하도록 만들 수 없고, 검증이 마지막 패치 이후에 실행되도록 강제할 수 없으며, 캡처 파일이 실제로 생겼는지 확인하지 못합니다. 모델이 이미 “끝났다”고 판단하면, 최종 보고에 증거를 넣으라고 텍스트로 아무리 적어도 소용이 없습니다.
반드시 지켜야 할 것은 시스템이 확인하게
그렇다고 모든 걸 코드로 못 박으라는 얘기는 아닙니다. 판단이 필요한 부분은 여전히 모델의 몫입니다. 어떤 파일을 살필지, 변경이 요청과 맞는지, 캡처 화면이 이상한지, 검증 실패의 트레이드오프가 무엇인지는 모델이 더 잘합니다. 다만 모델은 사실을 추적하는 데는 일관되게 미덥지 못합니다. 작업 공간이 만들어졌는지, 변경이 그 안에서 일어났는지, 검증이 마지막 수정 이후에 돌았는지 같은 단순한 사실 말입니다.
Payne이 제안하는 해법은 “계속 빠지는 요구사항을 프롬프트 밖으로 옮기는 것”입니다. 작업 공간에서 일해야 한다면 그 생성을 필수 단계로 만들고, 검증이 필요하면 그 출력을 붙잡아 저장하고, 사람이 출시 여부를 결정해야 한다면 리뷰 게이트를 둡니다. 이런 규칙을 모델 주변을 감싸는 코드, 즉 하네스(harness)가 검사하게 하는 것입니다. 그가 인용한 한 문장이 이 발상을 잘 압축합니다. “준수를 선택이 아니라 구조로 만들어라.”
이 패턴은 코딩 밖에서도 나타납니다. 약 200개의 마크다운 요구사항 파일을 하나씩 검토하는 QA 에이전트 사례가 좋은 예입니다. 처음엔 잘 돌아갔지만 실행이 길어지자 어떤 파일은 빠지고 어떤 파일은 두 번 검토됐으며, 한 번의 실패가 앞선 파일들을 다시 작업에 끌어들였습니다. 해결책은 프롬프트 수정이 아니었습니다. 모델에게 파일 하나만 주고 결과를 저장한 뒤 다음으로 넘기는 식으로, 목록과 순서와 완료 조건을 코드가 관리하게 바꾼 것입니다. 반복 작업에서 모든 항목을 모델이 추적하게 하는 건, 시스템에서 가장 예측 불가능한 부분에 가장 중요한 보증을 맡기는 셈이니까요.
프롬프트 한 줌에 건 환상, Ponytail의 경우
Payne이 “프롬프트로 강제하려 들지 말라”고 말한다면, Scott Logic의 글은 “프롬프트 한 줌에 과한 기대를 걸지 말라”고 말합니다. 표적은 Ponytail이라는 Skill입니다. “방 안에서 가장 게으른 시니어 개발자처럼 생각하게 만든다”는 문구를 내걸고, 코딩 에이전트가 불필요하게 많은 코드를 쏟아내는 문제를 잡아준다고 주장합니다. 약 1주일 만에 별 2만 개를 모았고, 인상적인 벤치마크 수치까지 제시했습니다.
그런데 저자가 실제로 열어보니, Ponytail의 알맹이는 약 100줄짜리 마크다운 파일 하나였습니다. 그 내용은 1990년대부터 있던 YAGNI(You Ain’t Gonna Need It, 필요해지기 전엔 만들지 마라) 원칙의 설명에 가까웠습니다. 저장소 전체는 90개 파일에 6천 줄이 넘었지만, 정작 핵심 로직은 그 짧은 파일이 전부였습니다.
저자는 직접 검증에 나섰습니다. Ponytail의 벤치마크에는 결함이 있었습니다. 이 테스트는 정답 여부와 코드 줄 수(LOC)를 측정하는데, 아무 Skill도 없는 기준선(baseline)은 종종 여러 개의 코드 예시를 한꺼번에 내놓습니다. 그래서 줄 수가 부풀려져 점수가 나쁘게 나온 것이지, 실제 코딩 에이전트는 적절한 시스템 프롬프트 아래에서 그렇게 동작하지 않습니다. 공정한 비교가 아니었던 셈입니다.
저자는 기준선 프롬프트에 짧은 문장을 하나씩 더해가며 격차를 좁혔습니다. 줄 수의 변화는 이렇게 줄어들었습니다.
- 기준선만: 평균 108줄
- “예시는 하나만, 부연 설명 없이” 추가: 16줄
- 여기에 “YAGNI 원칙을 따르라” 추가: 10.4줄
- 다시 “한 줄짜리 해법으로” 추가: 6.9줄
마지막 단계에서 Ponytail의 8.25줄을 넘어섰습니다. 단 일곱 단어로, 2만 별을 받은 Skill을 그 자신의 벤치마크에서 이긴 것입니다. 정답률은 모든 경우 100%를 유지했습니다.
두 글이 함께 가리키는 곳
두 저자의 결론은 한 지점에서 만납니다. 프롬프트는 만능이 아니라는 것입니다.
Payne의 글은 “프롬프트가 약속을 강제하지 못하는 영역”을 보여주고, Scott Logic의 글은 “프롬프트의 효과가 과장되기 쉬운 영역”을 보여줍니다. 한쪽은 반드시 지켜야 할 것을 시스템 구조로 옮기라 하고, 다른 한쪽은 누군가의 그럴듯한 프롬프트를 검증 없이 받아들이지 말라고 합니다. 방향은 달라도 둘 다 같은 분별을 요구합니다. 무엇을 느슨한 텍스트에 맡기고, 무엇을 코드와 검증에 맡길지 구분하는 감각입니다.
Scott Logic의 저자는 글 말미에서 한 가지를 덧붙입니다. 프롬프트 다루기가 어렵다면, 그 해법은 남의 프롬프트나 또 다른 Skill이 아니라 모델의 강점과 약점을 직접 부딪혀가며 익히는 데 있다고요. 모델의 능력은 들쭉날쭉해서, 어떤 작업은 놀랍도록 잘하고 겉보기에 비슷한 다른 작업은 형편없이 실패합니다. 그 경계를 스스로 감각으로 익히는 것이 새로운 실무 역량이라는 이야기입니다.
Payne의 글은 Hermes Workflows라는 본인의 도구 소개로, Scott Logic의 글은 벤치마크의 함정에 대한 더 상세한 분석으로 각각 이어집니다. 프롬프트의 한계를 코드로 넘어서는 구체적 방법이나, 검증되지 않은 Skill을 가려내는 기준이 궁금하다면 원문에서 더 깊이 살펴볼 수 있습니다.
답글 남기기