저장해 두고 몇 달째 그대로 쓰는 프롬프트가 몇 개 있습니다. 만들었을 때는 효과가 분명했습니다. 답변이 두서없으면 “단계별로 생각해”를 붙였고, 결과 형식이 흔들리면 긴 예시와 절차를 덧댔습니다. 모델이 바뀌어도 그 문장은 일종의 안전장치처럼 남았습니다.
그런데 어느 순간부터 이상해졌습니다. 답은 틀리지 않는데 지나치게 길었고, 간단한 수정에도 계획부터 늘어놓았습니다. 이미 도구로 확인할 수 있는 내용까지 되풀이하니, 정작 판단에 필요한 근거가 긴 설명 속에 묻혔습니다. 처음에는 모델 성능 문제라고 생각했습니다. 같은 일을 새 대화에서 짧게 부탁해 보니 오히려 결과가 나았습니다.
그때 알았습니다. 프롬프트는 보관한 기간보다 맡고 있는 역할이 더 중요합니다. 예전에는 프롬프트 한 장이 계획, 자료, 도구 사용법, 검수 절차까지 떠맡았습니다. 지금은 일부 역할을 모델과 코딩 에이전트, 테스트 도구가 이미 가져갔습니다. 오래된 지시문이 틀렸다기보다, 모델과 도구가 이미 맡은 일을 프롬프트가 계속 떠안고 있었습니다.
처음에는 모델 문제라고 생각했다
제가 다시 확인한 건 장애 기록을 읽고 재발 원인을 좁히는 작업이었습니다. 기존 프롬프트는 역할 부여, 사고 절차, 출력 순서, 도구 사용 예시까지 40줄이 넘었습니다. 새 모델에서도 안심이 된다는 이유로 그대로 붙였습니다.
결과는 그럴듯했지만 검토가 불편했습니다. 로그에서 확인한 사실과 모델의 추측이 긴 설명 사이에 섞였고, 사용하지 않은 도구까지 “다음 단계”로 제안했습니다. 같은 기록에 목적, 증거 범위, 완료 기준만 남겨 다시 요청했더니 원인 후보 수는 줄고 확인 명령은 더 구체적이었습니다. 중요한 건 어느 쪽 문장이 더 세련됐느냐가 아니었습니다. 운영자가 다음 행동을 정하는 데 걸린 시간이 짧아졌습니다.
이 한 번으로 “짧은 프롬프트가 무조건 낫다”고 결론 내리지는 않았습니다. 문서 정리, 오류 원인 조사, 표 데이터 검수처럼 성격이 다른 대표 업무에도 같은 비교를 해봤습니다. 반복해서 차이가 난 부분만 지웠습니다.
오래됐다는 건 날짜보다 역할이 겹친다는 뜻이다
제가 프롬프트를 다시 볼 때는 문장보다 역할부터 나눕니다.
Prompt는 목적과 경계를, Context는 지금 필요한 자료를, Harness는 반복 실행과 검증을 맡습니다. 한 문서에 세 역할을 모두 넣으면 길어질 뿐 아니라 실패 원인도 찾기 어려워집니다.
Prompt에는 이번 요청의 목적, 지켜야 할 제약, 근거 수준, 완료 기준을 둡니다. Context에는 실제 작업 파일, 프로젝트 규칙, 최신 증거를 넣습니다. Harness는 계획 수립, 도구 호출, 테스트, 재시도, 사람에게 넘기는 조건을 다룹니다.
예전 프롬프트 상당수는 이 세 층을 한꺼번에 품고 있습니다. 그래서 결과가 나쁠 때 무엇을 고쳐야 할지 알기 어렵습니다. 지시가 모호한지, 자료가 낡았는지, 도구 연결이 실패했는지가 한 덩어리로 보이기 때문입니다.
내가 먼저 지운 문장들
첫 번째는 행동을 바꾸지 않는 역할극입니다. “10년 차 전문가처럼 생각해”는 분야와 판단 기준이 뒤따르지 않으면 대체로 분위기만 만듭니다. 저는 대신 어떤 위험을 우선하고, 무엇을 근거로 삼으며, 어느 수준에서 사람에게 넘길지를 씁니다.
두 번째는 사고 과정을 길게 설명하라는 요구입니다. 실무자에게 필요한 것은 모델의 생각을 길게 풀어쓴 설명이 아니라, 결론을 확인할 수 있는 로그와 원문 근거입니다. “단계별 추론을 모두 보여줘” 대신 “결론마다 로그나 원문 근거를 붙이고, 확인할 수 없는 부분은 추측이라고 표시해”라고 바꿨습니다.
세 번째는 도구 사용법을 예시로 반복하는 블록입니다. 도구 정의와 스키마가 이미 시스템에 있다면 같은 설명을 프롬프트에 다시 넣을 이유가 적습니다. 예시가 실제 행동을 고정하는지, 단지 토큰을 차지하는지만 봅니다.
네 번째는 날짜를 고정한 문장입니다. “오늘은 2025년 8월이다” 같은 문장은 복사되는 순간부터 부채가 됩니다. 날짜가 중요한 조사라면 실행 시점의 날짜를 넣거나, 출처의 발행일과 확인일을 함께 기록하는 편이 낫습니다.
다섯 번째는 지나치게 자세한 작업 절차와 출력 스키마입니다. 꼭 그 경로를 따라야 하는 업무가 아니라면 모델이 고를 여지를 남깁니다. 출력 형식이 시스템 입력과 연결될 때만 Structured Output이나 고정 스키마를 사용합니다.
그래도 지우면 안 되는 문장이 있다
반대로 모델이 아무리 좋아져도 제가 직접 적어야 하는 것이 있습니다.
- 고객에게 잘못된 결과가 나갔을 때의 비용
- 자동 실행이 허용되는 범위와 승인받아야 하는 범위
- 성공으로 볼 수 있는 수치와 중단 조건
- 사내 규정이나 계약처럼 모델이 추측하면 안 되는 제약
- 결과가 다음 시스템으로 넘어갈 때 필요한 형식
이것들은 “프롬프트 기술”이 아니라 업무 지식입니다. 최신 모델도 우리 회사의 손실 기준이나 고객과 맺은 약속을 저절로 알 수 없습니다. 오래된 문장을 줄이는 작업은 설명을 덜 하는 일이 아니라, 사람만 아는 내용을 더 선명하게 남기는 일에 가깝습니다.
프롬프트가 하던 일을 도구가 가져갔다
OpenAI가 공개한 Harness Engineering 글은 거대한 AGENTS.md를 “천 쪽짜리 매뉴얼”처럼 만들지 말고, 짧은 안내 문서에서 필요한 자료로 이동하게 하라고 설명합니다. 규칙을 산문으로 여러 번 강조하기보다 린터, 테스트, CI처럼 실제로 검증 가능한 장치에 두라는 방향도 분명합니다.
출처: OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026년 2월 11일. 이 글은 짧은 안내 문서, 점진적 정보 공개, 도구로 강제되는 제약을 다룹니다.
이 변화는 단순히 문서를 쪼개자는 이야기가 아닙니다. “테스트를 실행해”, “실패하면 고쳐”, “허용되지 않은 의존성을 쓰지 마”를 매번 프롬프트로 부탁하는 대신 환경 자체가 그렇게 움직이게 만드는 것입니다. 프롬프트가 설득문이라면 Harness는 업무 규칙을 실제로 집행하는 운영 장치입니다.
제가 쓰는 기준도 비슷합니다. 사람이 매번 확인해야 하는 문장이 세 번 이상 반복되면 질문합니다. 이 규칙을 테스트, 스크립트, 권한 설정, 체크리스트로 옮길 수 있는가. 옮길 수 있다면 프롬프트에서 빼는 쪽으로 기웁니다.
Context는 많을수록 좋다는 믿음도 버렸다
긴 문서와 과거 대화를 모두 넣으면 모델이 더 정확해질 것 같지만 실제로는 초점이 흐려질 수 있습니다. Anthropic은 Context를 유한한 자원으로 보고, 정보가 쌓일수록 활용 가치가 떨어지는 context rot를 경고합니다. Prompt 한 장을 잘 쓰는 문제를 넘어 시스템 지시, 도구, 외부 자료, 작업 이력 전체를 큐레이션해야 한다는 설명입니다.
출처: Anthropic, Effective context engineering for AI agents, 2025년 9월 29일. Context를 중요하지만 유한한 자원으로 설명합니다.
그래서 저는 상주 Context와 필요할 때 불러오는 자료를 나눕니다. 상주 문서에는 프로젝트 목적, 절대 어기면 안 되는 규칙, 자료 위치만 둡니다. 상세 정책, 과거 회고, 도구별 설명은 링크나 별도 파일로 두고 해당 작업에서만 읽게 합니다. 자료를 없애는 것이 아니라 찾아올 수 있게 정리하고, 필요한 순간에만 올리는 것입니다.
프롬프트 하나를 실제로 다시 고쳐봤다
예전에 쓴 문장은 이랬습니다.
당신은 10년 차 전문가입니다. 단계별로 생각하고 각 단계의 추론을 설명하세요. 먼저 계획을 작성하고 승인을 기다린 뒤 작업을 시작하세요.
문제는 멋있지만 업무가 보이지 않는다는 점입니다. 어떤 자료를 볼지, 무엇을 조심할지, 언제 끝난 것인지가 없습니다. 저는 다음처럼 바꿨습니다.
첨부한 장애 기록에서 재발 원인 후보를 찾고, 가능성이 높은 순서대로 근거를 붙여 제시해 주세요. 로그로 확인할 수 없는 원인은 단정하지 마세요. 완료 기준은 운영자가 다음 점검 명령을 바로 실행할 수 있는 상태입니다.
새 문장은 사고법을 지시하지 않습니다. 대신 입력 자료, 근거의 경계, 완료 상태를 분명히 합니다. 복잡한 작업의 계획은 에이전트가 세우게 하되, 승인이 필요한 지점에서는 실행 환경이 자동으로 멈추도록 설정합니다.
나는 새 모델이 나올 때 이렇게 점검한다
새 모델이 발표될 때마다 프롬프트 전체를 갈아엎지는 않습니다. 대표 업무 세 개 정도를 골라 기존 버전과 축약 버전을 같은 조건에서 돌립니다.
- 사용자가 실제로 받는 결과가 달라졌는가
- 근거 없는 단정이 줄었는가
- 사람이 검토하는 시간이 줄었는가
- 다시 고쳐 달라고 요청한 횟수가 줄었는가
- 실패했을 때 원인을 Prompt, Context, Harness 중 어디에서 찾을 수 있는가
한 번의 멋진 답변으로 판단하지 않습니다. 문서 검토라면 길이와 난도가 다른 문서를 섞고, 데이터 작업이라면 누락값과 형식 오류를 넣습니다. 잘못된 규칙을 지운 뒤 특정 작업만 나빠졌다면 그 규칙을 더 좁은 조건으로 되돌립니다. 삭제도 버전 관리가 필요합니다.
오래된 프롬프트를 버린다는 말의 뜻
1년 전 프롬프트가 모두 나쁘다는 뜻은 아닙니다. 당시 적어 둔 고객 기준과 실패 조건은 지금도 가장 중요한 문장일 수 있습니다. 다만 모델이 이미 하는 일, 도구가 더 확실하게 할 수 있는 일, 필요할 때 찾아오면 되는 자료까지 한 문서에 붙들어 둘 필요는 없습니다.
제가 남기는 것은 네 가지입니다. 무엇을 원하는지, 무엇을 어기면 안 되는지, 무엇을 근거로 삼을지, 어디까지 가면 끝인지. 나머지는 필요한 Context로 불러오거나 Harness가 실행하게 합니다.
오래된 프롬프트를 정리한 뒤 가장 크게 달라진 건 답변의 말투가 아니었습니다. 실패했을 때 어디를 고쳐야 하는지 보이기 시작했습니다. Prompt를 손볼지, 자료를 바꿀지, 테스트를 추가할지 구분할 수 있게 된 것. 저는 그 차이가 새 문구 하나를 더 배우는 것보다 훨씬 컸습니다.
