아직도 1년 전 프롬프트를 그대로 쓰고 있나요?

저장해 두고 매번 그대로 다시 쓰는 프롬프트가 있나요? 저는 몇 가지 있습니다. 프롬프트 엔지니어링이 한참 유행할 때, 만든 프롬프트인데요. 성능이 꽤 훌륭해 즐겨 쓰고 있었습니다. 이런 프롬프트는 몇 가지 비슷한 구조를 가집니다. “단계별로 생각하세요”, 같은 규칙을 여러 차례 강조한 문단, 도구 쓰는 법을 예시로 늘어놓은 블록, “오늘은 2026년 8월입니다” 같은 기준 문구.

그런데 어느 순간, 이런 프롬프트가 영 제 성능을 내지 못했습니다. 그래서 이유를 찾다 보니 더는 이런 규칙이 큰 효과를 내지 못한다는 걸 알게 되었습니다.

앤트로픽은 최근 블로그 글 「클로드 5세대 모델을 위한 컨텍스트 엔지니어링의 새 규칙」에서 클로드 오퍼스 5·페이블 5용 클로드 코드 시스템 프롬프트의 80% 이상을 지웠다고 밝혔습니다. 코딩 평가에서 측정 가능한 손실은 없었다고 했고요. 심지어 그동안 모범 사례로 통했던 컨텍스트 엔지니어링 요령 여러 개를 두고 “미신(myth)”이라고 부르기까지 합니다.

그래서 궁금해졌습니다. 그렇다면 지금의 AI는 어떻게 써야 하지? 무슨 프롬프트와 컨텍스트를 줘야 하지?

AI 모델을 만드는 회사, 앤트로픽과 오픈AI, 구글과 xAI, 문샷이 발표한 공식 문서를 훑었습니다. 그랬더니 몇 가지 공통점이 보이더라고요. 프롬프트와 컨텍스트, 하네스의 오래된 미신들을 찾고, 바로 점검할 만한 규칙들을 정리했습니다. 새 술은 새 부대에 담아야 하는 겁니다.

낡은 규칙과 미신들

우선 자주 쓰던 프롬프트에서 지워도 괜찮은 것들부터 볼까 합니다. 아래는 널리 퍼진 프롬프트와 컨텍스트 방법론 가운데, 최신 문서들이 직접 낡았다고 표시한 항목입니다.

1. “단계별로 생각해”, “네 추론을 설명해”

오픈AI의 추론 모델 베스트 프랙티스는 모델이 내부에서 추론하니 이 두 문구가 불필요하다고 적어 뒀습니다. 구글 제미나이 프롬프트 전략 문서도 내부 사고 텍스트가 자동 생성되니 응답 안에서 추론 단계를 서술하게 할 필요는 일반적으로 없다고 합니다.

2. 도구 쓰는 법을 예시로 알려주기

이 방식은 도구 사용의 1순위 규칙이었는데요. 앤트로픽은 최신 모델에서 그 예시가 오히려 모델을 특정 탐색 공간에 가둔다는 걸 발견했다고 합니다. 예시는 만들기 힘들뿐 언제든 옳다고 생각했는데, 그렇지 않다는 거죠.

3. 같은 규칙을 두 군데에 반복해 쓰기

예전 클로드 모델은 컨텍스트 창 끝의 지시를 앞의 지시보다 더 잘 듣는 경향이 있었어요. 그래서 도구 얘기를 시스템 프롬프트에도 쓰고 도구 설명에도 쓰는 관습이 생겼습니다. 하지만 이제는 토큰 낭비에 가깝습니다. 알아서 잘 이해하니까요.

4. 상세한 단계별 절차 안내, 그리고 프롬프트에 적어 둔 출력 스키마

오픈AI GPT-5.5 모델 가이드의 레거시 프롬프트 정리 체크리스트가 두 가지 문제를 나란히 지목합니다. 제품이 그 경로를 요구하는 게 아니라면 경로는 모델이 고르게 두고, 스키마는 Structured Outputs로 옮기는 편이 좋습니다.

5. “오늘은 2026년 8월입니다” 같은 현재 날짜 문구

요즘 모델은 현재 날짜(UTC)를 이미 안다고 문서에 적혀 있습니다.

6. 역할 부여와 단계 명시

“전문가처럼 생각해” 계열이죠. 이걸 이제 지우라고 못 박은 문서는 아직 없긴 합니다. 다만, 최근 가이드에서는 이런 안내가 자취를 감췄습니다. 특히, 7월 들어서는 이런 역할 부여가 있던 최상단 자리에 어떤 판단을 해야 하는지 두라는 서술들이 보입니다.

7. 문서를 상주 컨텍스트에 다 올리기

구글 Genkit 블로그(7월 31일)는 표준 운영 절차와 참조 가이드, 문서를 모두 올려 두는 건 지속 가능하지 않다고 적습니다. 도구 정의를 전부 요청에 넣는 방식도 문샷 키미 K3 도구 호출 문서가 하지 말라고 하죠.

정리하고 보니 꽤 충격적이네요. “10년 차 개발자처럼 생각해”라든가 “단계별로 생각해” 같은 건 이제 숨 쉬듯 그대로 넣는 문구 중 하나였거든요. 오픈AI는 이러한 예전 프롬프트가 구형 모델이 궤도를 유지하도록 절차를 과하게 규정해 둔 것뿐이라고 합니다. 지금 모델에 이를 그대로 옮기면 노이즈가 되고 탐색 범위만 좁아진다고 하죠.

그럼 왜 이러한 변화가 생긴 걸까요?

모델을 움직이는 도구의 변화

요즘 모델은 클로드 코드나 코덱스처럼 최적화된 껍데기를 함께 달고 나옵니다. 또 지금의 챗GPT와 클로드, 제미나이 웹 버전은 초기 형태와 비교하면 무척 다양한 기능을 달고 있죠. 예전엔 “테스트 돌려서 확인까지 해”라고 적어 주는 게 당연했잖아요. 그렇게 사람이 프롬프트로 채워 넣던 절차가 이미 그 껍데기들, 그러니까 하네스 안에 들어가 있습니다.

저 프롬프트들이 맡고 있던 것, 그러니까 계획과 검증도 그 안에 들어갔습니다.

앤트로픽은 「모든 작업에 맞는 하네스」라는 글에서 기본 클로드 코드 하네스가 한 컨텍스트 창 안에서 계획과 실행을 같이 해야 한다고 설명합니다. 그 방식이 무너지는 작업을 위해 클로드가 직접 하네스를 만들어 쓰는 동적 워크플로를 공개했고요. 뒤에 나온 글 「스킬로 검증 루프 만들기」에서는 에이전트가 테스트, 린터, 자체 점검까지 돌려 실패한 걸 고치고 나서야 다음으로 넘어간다고 정의합니다. 물론, 알아서 다 봐준다는 얘기는 아니지만요. 사람이 손으로 하던 점검을 스킬로 옮겨 두면 클로드가 자기 피드백 루프를 닫는다는 뜻입니다.

그러니 프롬프트로 주던 절차 지시가 하네스와 겹치기 시작합니다. 앤트로픽이 자기들 시스템 프롬프트를 지우며 찾아낸 것도 그 부분이었죠. 시스템 프롬프트와 CLAUDE.md, 스킬들이 클로드 코드를 과도하게 제약하고 있었고, 한 요청 안에 “적절히 문서를 남겨라”와 “주석을 달지 마라”가 같이 들어가 있기도 했다는 겁니다.

모델도, 이를 둘러싼 하네스도 알아서 발전하고 있으니 사용자가 직접 채울 일이 줄었다는 뜻입니다.

모델 만든 회사가 직접 알려주는 지금 기준

다행히 모델을 만든 회사에서 직접 새로운 모델을 잘 쓰는 방법을 알려 줬습니다. 비슷합니다. 덜어내는 게 먼저, 남길 건 결과와 중단 조건이라는 겁니다. 나머지는 필요할 때 불러오게 만드는 것이 좋습니다.

이 규칙들을 모델에 명령을 내리는 세 층, 프롬프트와 컨텍스트, 그리고 하네스로 나눠 정리했습니다.

프롬프트: 목적지만 적고 경로는 맡기기

오픈AI GPT-5.6 프롬프트 가이드는 첫 단락부터 이렇게 적습니다. 프롬프트에서는 결과와 중요한 제약, 쓸 수 있는 근거, 완료 기준만 정의하고, 모델이 어떤 경로를 고를지 여지를 남길 때 가장 잘 작동한다는 거예요. “항상”·“절대”는 안전 규칙처럼 진짜 예외가 없는 곳에만 쓰고, 판단이 필요한 사안에는 결정 규칙을 적으라고 덧붙입니다.

충돌 지시 얘기도 같은 강도로 합니다. GPT-5 계열은 프롬프트 계약을 밀착해 따르니 상충하는 규칙이 디테일 부족보다 더 큰 불안정을 만든다는 겁니다. 지시를 줄이라는 말과는 다릅니다. 서로 부딪히는 지시를 없애라는 쪽이에요.

한편 앤트로픽은 도구 사용법을 예시로 남기면 탐색 공간이 좁아진다는 이야기도 합니다. 프롬프트의 기본 방법론이었던 퓨샷(few-shot) 규칙과 정면으로 부딪치죠. 그 자리는 도구·스크립트·파일의 설계가 대신 채웁니다. Todo 도구의 상태 값(pending·in_progress·completed)이 그 자체로 사용법의 힌트가 되는 식이죠.

그럼 어떤 예시를 남겨야 할까요? 오픈AI에 따르면, 행동을 바꾸지 않는 예시는 빼는 것이 좋습니다.

사고를 어떤 단계로 해나갈지도 같은 방식으로 정리하는 것을 추천합니다. 응답 안에 추론 단계를 서술하게 만드는 지시는 오픈AI와 앤트로픽 모두 불필요하다고 적었어요. 꼭 쓰고 싶다면 무거운 문제를 풀 때만 노력(effort) 정도를 조건부로 지목하라고 합니다.

컨텍스트: 지나치게 많은 것은 덜어내기

일단 과도한 컨텍스트를 덜어내라는 제안은 어느 문서나 같습니다.

구글 Genkit 블로그는 문서를 있는 대로 다 올려 두면 토큰은 토큰대로 쓰면서 모델의 초점까지 흐린다고 적습니다. xAI는 파일이 전부 로드되니 긴 지시보다 짧고 구체적인 지시가 더 안정적으로 지켜진다고 쓰고요. 문샷은 도구 정의를 다 넣으면 잘못된 도구를 고를 확률이 높아진다고 하죠.

오픈AI는 여기에 숫자 기반 관측까지 더합니다. 내부 코딩 에이전트 평가 실행 표본에서 시스템 프롬프트를 가볍게 한 구성이 평가 점수를 약 10~15% 올리고 비용은 33~67% 줄였다고 공개했어요. 다만 워크로드마다 결과가 달라지니 이 범위는 방향 지시로만 보고 각자 애플리케이션의 대표 태스크에서 검증하라는 단서를 달았고요.

하네스: 분리한 컨텍스트를 잘 찾는 구조

그렇다고 덜어낸 컨텍스트를 아예 참조하지 말라는 건 아닙니다. 이를 잘 정리해 두고, 필요한 것만 적절하게 찾아오는 구성을 짜야 합니다.

구글은 Genkit Go에 에이전트 스킬을 넣으면서 그 원리를 프로그레시브 디스클로저(progressive disclosure), 곧 필요할 때만 정보를 드러내는 방식이라고 설명해요. 이를테면 SKILL.md에서 처음에는 프론트매터(frontmatter)만 노출하고 조건이 맞으면 본문을 불러오는 것이 좋습니다. 남의 랩에서 나온 파일 규격을 자사 프레임워크에 넣은 셈이죠.

다른 곳도 방식만 다릅니다. 앤트로픽은 일부 도구를 지연 로딩으로 두고 에이전트가 ToolSearch로 정의를 찾은 뒤 쓰게 만들었고, 문샷과 오픈AI는 검색 도구 하나로 같은 일을 합니다.

층별 역할도 다시 배치하라고 합니다. 앤트로픽은 CLAUDE.md를 가볍게 두고 저장소 용도로만 짧게 적되, 토큰 대부분은 코드베이스 안의 함정을 피하는 데 쓰라고 권합니다. 파일 시스템이나 저장소를 보면 알 수 있는 뻔한 내용은 적지 말라고 하고요.

외부 검증 결과도 있습니다. 취리히연방공대 SRI 랩의 「AGENTS.md 평가」는 여러 코딩 에이전트와 모델을 대상으로 컨텍스트 파일이 작업 성공률을 올리지 못하면서 추론 비용만 20% 넘게 올렸다고 보고했습니다. 논문 결론 자체는 사람이 쓴 컨텍스트 파일이 최소 요구사항만 적어야 한다는 쪽이라, 개발사들이 내놓은 최신 권고와 비슷한 방향입니다. 컨텍스트 파일이 무의미하다는 게 아니라 무엇을 적는지에 따라 갈린다는 뜻이겠죠.

오늘 바로 지울 프롬프트/남길 프롬프트

다만, 이미 내 작업에 깊이 관여하는 항목들을 갑자기 지우면 어떤 문제가 생길지 모릅니다. 그러니 낡은 목록을 실제 프롬프트에서 걷어낼 때 역시 순서가 중요합니다.

한꺼번에 다시 쓰지 말고 이미 작동하는 프롬프트와 도구 세트에서 지시나 예시, 도구를 한 그룹씩만 빼고 같은 평가를 다시 돌리는 것이 좋습니다. 그래야 무엇이 실제로 행동을 바꾸던 지시였는지 알 수 있으니까요. 특히, 모델 업데이트와 함께 잘 쓰던 규칙이 이상해졌을 때 해볼 만합니다.

안 쓰는 도구와 반복되는 승인 규칙이 특히 그 대상입니다. 오픈AI는 태스크와 관련된 도구만 노출하고, 안전한 행동(파일 읽기, 로그 확인, 범위 안 코드 수정, 테스트 실행)은 허용 목록으로 묶고, 정책은 한 곳에 한 번만 적으라고 합니다. “먼저 물어라”나 “승인을 기다려라”를 여기저기 반복하면 예상할 수 있는 안전한 행동에까지 승인 요청이 쏟아집니다.

물론 반드시 남겨야 하는 것도 있습니다. 사용자에게 보이는 결과, 성공 기준과 중단 조건, 안전·비즈니스·권한에 기반한 제약, 맥락에 따라 도구를 고르는 라우팅 규칙, 필요한 출력 형태와 검증 요구입니다.

마지막으로, 어떤 프롬프트를 써야 하나 싶을 때면 앤트로픽 페이블 5 실무 가이드(7월 6일)에 그대로 복사해 써볼 만한 예시가 실려 있습니다.

Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture.

애매한 게 있으면 한 번에 한 질문씩 나를 인터뷰해 줘. 내 답이 아키텍처를 바꿀 만한 질문을 먼저.

Can you do a blind spot pass to help me figure out my relevant unknown unknowns and help me prompt you better.

내가 모른다는 것조차 모르는 부분을 찾도록 블라인드 스팟 패스를 해 줘. 그래서 내가 더 잘 시킬 수 있게.

마치며

이 모든 건 모델과 하네스가 똑똑해졌으니 명령을 덜어내라는 얘기지, 직접 만든 하네스를 버리라는 뜻은 아닙니다.

앤트로픽은 클로드가 한 컨텍스트 창에서 오래 일할 때 나타나는 실패 유형을 「모든 작업에 맞는 하네스」에 적어 뒀어요. 복잡한 다단계 작업을 끝내지 않고 중간에 완료를 선언하는 것(보안 검토 50개 항목 중 35개만 처리하고 끝내는 식), 검증이나 판정을 시키면 자기 결과를 편애하는 것, 요약이 반복되면서 “X를 하지 마라” 같은 제약이 사라지는 것. 그러니 실제로 실무 환경처럼, 컨텍스트를 길게 소비하며 작업을 돌릴 때는 사람이 만든 하네스를 쌓아가는 것이 좋습니다.

그렇다면 사람이 명령해야 하는 것은 뭘까요? 모델이 스스로 알아낼 수 없는 것만 적는 겁니다. 그리고 그 ‘알아낼 수 없는 것’이 무엇인지는 이 작업을 가장 잘 아는 나만이 답할 수 있습니다.

무엇보다 이 모든 건 내가 풀어야 할 문제로 돌아옵니다. 어느 문서나 대부분 같은 단서가 달려 있습니다. 내가 자주 쓰는 대표 태스크에서 직접 검증하라는 거죠. 낡은 목록에서 무엇을 지우고 무엇을 남길지 가르는 기준은 결국 내 작업에서만 나옵니다. 그러니 직접 써보면서 스스로 맞는 방법을 찾아가길 권합니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.