모델이 실수하면 규칙 한 줄이 붙습니다. 도구가 바뀌면 우회법이 붙고, 새 모델이 와도 옛 지침은 그대로 남죠. 그렇게 쌓인 파일은 온보딩 문서와 스타일 매뉴얼과 트러블슈팅 일지가 뒤섞인 덩어리가 됩니다.
마이크로소프트 .NET 블로그가 이 문제를 정면으로 다뤘습니다. 지시문 위생 관리의 목표는 파일을 짧게 만드는 게 아니라는 점을 글은 먼저 못 박죠. 결과를 실제로 바꾸는 고신호 정보의 최소 집합을 남기는 것이 목표입니다.
출처: Instructions Hygiene – What Frontier Models Still Need You to Say – Microsoft .NET Blog
컨텍스트를 예산으로 다룬다
지시문 파일은 해당하는 요청마다 매번 컨텍스트에 실립니다. 개발자의 실제 작업, 관련 코드, 도구 출력, 대화 기록과 나란히 놓여 주의를 나눠 갖는다는 뜻이죠. 컨텍스트 창이 커졌다고 해서 추가되는 토큰이 공짜가 되지는 않습니다.
그래서 글은 질문을 바꾸라고 제안합니다. “이 저장소에 대해 무엇을 알려줄 수 있을까”가 아니라, “모델이 스스로 발견하거나 추론하거나 찾아올 수 없는 것은 무엇인가”로 말입니다. 이 구분이 건강한 지시문 파일의 출발점이 됩니다.
프론티어 모델이 아직 모르는 다섯 가지
최신 모델은 저장소를 탐색하고, 흔한 프레임워크를 알아보고, 평범한 오류에서 스스로 회복합니다. 반면 팀의 머릿속에만 있는 결정과 제약은 알 길이 없죠. 글이 꼽은 다섯 가지는 이렇습니다.
- 추론할 수 없는 시스템 사실 — 어떤 경계가 의도된 것인지, 낡아 보이는 디렉터리가 아직 프로덕션에서 쓰이는지
- 검증까지 가는 가장 짧은 경로 — 실제로 통하는 빌드·테스트 명령
- 코드베이스가 스스로 정하지 못하는 선택 — 합리적인 방식이 여럿일 때 팀이 고른 쪽
- 하드 제약과 비싼 실수 — 어기면 보안·호환성·운영 사고가 나는 규칙
- 진실의 출처가 있는 위치 — 전부 담는 대신 믿을 만한 문서를 가리키기
두 번째 항목을 글은 가장 값진 정보로 꼽습니다. 에이전트가 헤매는 시간을 없애고 “완료”의 기준을 구체적으로 주기 때문이죠.
다만 조건이 붙습니다. 직접 검증한 명령만 남길 것. 틀린 명령을 확신에 찬 어투로 반복해두면 아예 없는 것보다 나쁩니다.
네 번째의 강조 표현에도 제동이 걸립니다. always·never·must 같은 단어는 정말로 절대적인 규칙에만 쓰라는 것. 일반적인 경고로 파일을 채우면 강조가 강조로 기능하지 않습니다.
빼는 쪽이 더 빠르다
오래된 지시문 파일을 개선하는 가장 빠른 방법은 대개 뺄셈이라고 글은 말합니다. 첫 번째 제거 대상은 “깨끗하고 유지보수 가능한 코드를 작성하라”, “모범 사례를 따르라” 같은 일반론이죠. 모델이 이미 아는 데다, 실제 결정을 가르는 데는 너무 막연합니다.
“오류를 적절히 처리하라” 대신 글이 제안하는 문장은 이런 쪽입니다. 검증 실패는 400, 리소스 없음은 404, 동시성 충돌은 409로 매핑하고 기존 헬퍼를 쓰라고 쓰는 것. 같은 자리를 지역적 결정으로 채우라는 뜻이죠.
프롬프트 민속학이라 부를 만한 것들도 정리 대상입니다. “심호흡을 하세요”, “단계적으로 생각하세요”, “세계 최고 수준의 시니어 엔지니어처럼 행동하세요” 같은 문장이 여기 해당합니다. 프로젝트 지식이 아닌 데다, 경직된 절차 지시는 불필요한 탐색을 유발하거나 그 환경의 도구와 충돌하기도 합니다.
마지막은 옛 실패의 일지입니다. 우회법은 그게 여전히 필요한 동안만 파일에 있어야 하죠. 원인이 고쳐졌는데 경고만 남아 있으면, 에이전트는 존재하지 않는 문제를 계속 피해 다니게 됩니다.
스킬 문서도 같은 병을 앓는다
지시문만의 문제는 아닙니다. 같은 주 arXiv에 올라온 SkillZip 논문은 자기진화 에이전트가 쌓는 스킬 문서에서 똑같은 팽창을 지적하죠. 성공한 절차와 실패 수정을 계속 덧붙이다 보면 같은 요구가 여러 분기와 예시와 경고에 흩어져 되풀이되고, 흔한 액션 시퀀스는 재사용되는 대신 복사됩니다.
논문의 처방은 “한 번 설명하고 여러 번 참조하라”입니다. 반복되는 규칙은 적용 범위에서 한 번만 선언하고, 반복되는 액션 시퀀스는 공용 절차로 묶고, 나머지는 명시적 예외로 남기는 방식이죠. 압축 과정에서 평가를 아예 돌리지 않는다는 점도 특징입니다. 테스트로 확인하는 대신 희귀 규칙이 구조적으로 보존되도록 목적함수를 짜서, 압축 시점의 평가셋에 성능이 매이는 문제를 피했습니다.
두 자료를 겹쳐 보면 방향이 같습니다. 덜어내는 일이 성능을 깎는 절충이 아니라, 신호 대 잡음을 올리는 작업이라는 것.
스킬을 어떻게 쓸지 다룬 앞선 글들과 나란히 놓으면 그림이 채워집니다. 무엇을 스킬로 옮길지, 흩어진 스킬을 어떻게 관리할지에 이어, 이번은 이미 쓴 것을 어떻게 덜어낼지에 관한 이야기죠.
프롬프트 30~50번 뒤에야 문구를 정한다, 인튜이트가 콘텐츠 기준을 스킬로 옮긴 이유
스킬이 12개 에이전트에 흩어졌다, macOS 스킬 관리 앱이 나오는 이유
해보려면
환경: GitHub Copilot 기준으로 저장소 전역 지시문은 .github/copilot-instructions.md, 경로별 지시문은 .github/instructions/ 아래, 에이전트 지시문은 AGENTS.md입니다. 전역과 경로별이 함께 있으면 둘 다 적용됩니다.
출발점: 모든 항목을 keep(여전히 참이고 추론하기 어려움) / remove(모델이 이미 함, 도구가 강제함, 막연함, 낡음) / move(경로별 파일이나 링크 문서로) / verify(명령·버전·의존성이 바뀌었을 수 있음) 넷 중 하나로 판정합니다.
확인: 줄인 파일로 대표적인 작업 하나를 시켜보고, 상상한 실패가 아니라 실제로 발생하는 실패를 관찰합니다. 반복되는 실패에만 최소한의 지침을 더한 뒤 다른 작업으로 한 번 더 테스트합니다.
걸리는 지점: 검증하지 않은 명령을 남겨두면 없느니만 못합니다. 모델별 분기(“A 모델이면 파일 세 개를 먼저 보라”)도 피하는 편이 좋은데, 모델의 가용성과 동작이 저장소 구조보다 훨씬 빨리 바뀌기 때문입니다.
참고자료:
답글 남기기