#프롬프트를 가득 채우지 마라 — 점진적 공개의 3층 깔때기

← 전체 목차 · 이전: 파일 하나 읽고 함락된다 — Agent 간접 프롬프트 인젝션 · 다음: Agent 아키텍처: 실행 Agent에게는 거부권이 있어야 한다

수십 페이지짜리 운영 규범을 작업 시작 시점에 시스템 프롬프트로 한꺼번에 밀어 넣는 것은 엄밀함이 아니라 시스템에 능동적으로 간섭을 만들어내는 행위다. 사용자가 "안녕하세요" 한마디를 보냈을 뿐인데 모델은 재무 규범과 코드 규범을 통째로 한 번 읽어야 하고, 연산력은 낭비되고, 컨텍스트는 과밀해지며, 무관한 규칙들 사이에서 환각이 생겨 코드 작성 로직과 항공권 조회 로직을 뒤섞는다.

답은 점진적 공개다. 시작부터 디테일을 노출하지 않고 "언제 이 스킬을 써야 하는가"만 먼저 알려주고, 작업이 실제로 구체적인 실행 단계에 도달했을 때 해당 설명을 동적으로 로딩한다. 문서 06이 점진적 공개의 원리를 다뤘다면, 이 문서는 그것을 3층 깔때기로 구현하는 방법과 세 가지 엔지니어링 경계를 다룬다.

#반면교사: 만능 업무 비서의 시스템 프롬프트

항공권 조회, 코드 작성, 재무 리포트 처리를 모두 해야 하는 Agent를 만든다고 하자. 초보 개발자는 세 스킬의 모든 규칙·파라미터 표·하위 로직을 맨 앞 시스템 프롬프트에 한 번에 다 써넣는다.

#해법: 정보 공급을 깔때기로 만든다

사용자 지시
  ↓
1층  라우팅 판정층      —— 극단적 간결. 분기 선택만 수행
  ↓ (모델이 특정 스킬을 호출하기로 명확히 결정)
2층  핵심 워크플로       —— 스킬의 핵심 골격 SOP 로딩
  ↓ (통상 작업은 여기서 종료. 특수 상황일 때만 계속)
3층  세부 리소스 온디맨드 —— 스크립트 코드 / 과거 사례 동적 인출

#1층 · 라우팅 판정층: 이름과 한 줄 설명만

키워드는 극단적 간결이다. 코드나 장문의 설명을 보여줄 필요가 전혀 없고 두 가지만 제공한다.

• 스킬 이름: 예) "재무 리포트 스킬"
• 기능 설명 한 줄: 예) "Excel 재무 데이터를 처리·집계하는 데 사용"

이 층의 유일한 목적은 모델이 빠르게 분기 선택을 하도록 돕는 것이다. 이때 컨텍스트가 매우 깨끗하므로 판단 정확도가 자연히 올라간다.

2층의 로딩은 1층의 판정 결과가 잠금 해제해 주는 것이지, 기본으로 일어나는 일이 아니다.

#2층 · 핵심 워크플로: 여기서 처음 작업 설명서를 본다

모델은 여기서 처음으로 구체적인 작업 설명서(SOP)를 본다. 예: 1단계 표에서 어느 열을 추출할지, 2단계 데이터 클렌징을 어떻게 할지.

비유: 직원이 구체적인 업무를 배정받은 뒤에야 해당 매뉴얼의 주간 부분을 펼쳐 보는 것이지, 입사 첫날 매뉴얼 전체를 외우는 것이 아니다.

통상적인 작업이라면 여기서 실행이 끝난다. 3층은 필수 경유지가 아니라 예외 분기다.

#3층 · 세부 리소스 온디맨드: 예외일 때만 인출

특수 상황을 만났을 때만 3층이 발동한다. 예: 데이터 클렌징 중 매우 드문 날짜 포맷을 발견했을 때, 그제서야 당신이 설정해둔 규칙에 따라 다음을 인출한다.

• 그 특수 포맷을 처리하는 스크립트 코드
• 또는 과거의 해결 사례

한정어 두 개에 주목할 것 — 당신의 설정에 따라(모델의 자유재량이 아님), 정말로 쓰이는 그 일부만(문서 전체가 아님).

#깔때기가 돌아갈 때의 수익

마지막 항목이 진짜 가치다 — 스킬 총량과 단일 컨텍스트 부피의 디커플링. 이것이 없으면 스킬 라이브러리의 규모 상한은 곧 컨텍스트 윈도우의 상한이 된다.

#세 가지 엔지니어링 경계 — 자칫하면 뒤집힌다

#함정 1 · 입구 설명의 "정도"가 가장 잡기 어렵다

양방향 리스크다. 왼쪽으로 치우치면 오검색, 오른쪽으로 치우치면 누락 검색이며, "자세히 쓸수록 안전하다"는 단조 방향은 존재하지 않는다.

#함정 2 · 3층의 자료 인출에는 절대 경로나 고유 식별자를 줘야 한다

3층에서 외부 자료를 인출할 때 요구사항은 강제 조건이다. 매우 명확한 절대 경로, 또는 전역 고유 문서 식별자를 반드시 제공해야 한다.

그리고 다른 길은 명시적으로 부정된다: 모델이 컨텍스트를 보고 파일명을 퍼지 매칭해 주기를 기대하지 마라.

명확한 좌표를 주지 않음
  → 모델이 높은 확률로 환각으로 존재하지 않는 경로를 지어냄
  → 시스템이 계속 "파일을 찾을 수 없음" 오류를 뱉음

#함정 3 · 극단으로 가지 말 것, 핵심 워크플로는 쪼개면 안 된다

가장 간과되기 쉬운 지점이다. 온디맨드 로딩에는 적용 하한선이 있다.

• 온디맨드 로딩은 부담을 덜기 위한 것이다.
• 그러나 이것이 연속된 핵심 워크플로까지 잘게 쪼개라는 뜻은 아니다.
• 2층의 표준 실행 단계는 반드시 완전하게 유지되어야 한다.

"1단계에 뭘 하고 2단계에 뭘 하는지"까지 모델이 외부 라이브러리에서 즉석 조회하게 만들면, 반복 호출과 기본 규칙 탐색에 드는 시간만으로도 작업이 완전히 무너진다. 즉 과도한 파편화는 절약한 컨텍스트 비용을 더 비싼 호출 라운드 비용으로 바꿔치기한다.

#핵심 통찰

1. "전부 미리 알려주는 것"은 엄밀함이 아니라 간섭이다 — 직관적으로는 규범을 빠짐없이 쓰는 것이 책임감이지만, 대규모 모델에게 무관한 규칙은 불활성 배경이 아니라 추론에 참여하는 노이즈다. 결과는 환각과 로직 혼선이며, 비용은 정보가 불완전한 경우보다 오히려 크다.
2. 정보는 문서 구조가 아니라 실행 시점에 맞춰 공급해야 한다 — 사람의 문서는 주제별로 조직되지만 모델에게 필요한 것은 "지금 사슬의 어느 단계에 있는가"별 조직이다. 점진적 공개의 실질은 정적 문서를 실행 사슬에 정렬된 로딩 순서로 재배열하는 것이다.
3. 판단 정확도는 정보량이 아니라 컨텍스트의 깨끗함에서 온다 — 1층이 스킬 이름과 한 줄 설명만 주는 이유가 여기 있다. 라우팅은 분류 문제이며, 디테일은 분류에 도움이 되지 않고 오히려 방해가 된다. "많이 줄수록 정확하다"는 직관과 정반대다.
4. 스킬 총량과 단일 컨텍스트 부피는 반드시 디커플링되어야 한다 — 이것이 계층화가 주는 가장 값진 성질이다. 백엔드에 수백~수천 개 스킬을 걸어도 단일 대화의 컨텍스트는 계속 깨끗하다. 이것이 없으면 스킬 라이브러리의 규모 상한이 컨텍스트 윈도우 상한과 같아진다.
5. 입구 설명은 양방향 리스크이며 "자세할수록 안전한" 방향은 없다 — 광범위하면 오발동, 경직되면 누락이다. 단방향 튜닝으로는 해결되지 않고 두 종류의 오류 사이에서 트레이드오프하며 실제 사용자 표현으로 반복 캘리브레이션해야 한다.
6. 모델의 검색·위치 파악 능력을 가정해서는 안 되고, 좌표는 시스템이 제공해야 한다 — 위치 파악에 실패한 모델은 침묵하지 않고 경로를 지어낸다. 오류가 "찾지 못함"에서 "존재하지 않는 것을 조회함"으로 바뀐다는 점이 더 나쁘다.
7. 온디맨드 로딩에는 하한선이 있다 — 연속된 워크플로는 쪼갤 수 없다 — 분할 입도 최적화에는 비용 곡선이 있다. 너무 잘게 쪼개면 아낀 컨텍스트가 호출 라운드와 탐색 시간으로 되돌아온다. 계층화는 글자 수가 아니라 "예외 vs 주간"의 이음매를 따라 잘라야 한다.
8. 스킬 문서의 독자는 읽는 사람이 아니라 검색하는 주체다 — "편집이 절제되고 논리가 명확한 색인 목록"이라는 규정은 스킬 문서의 품질 기준을 "깊이 있게 설명했는가"에서 **"정확히 찾히는가, 적게 싣는가"**로 바꾼다.

#엔지니어링 실전 Tips

• 입구 설명은 "분기 선택"을 기준으로 쓸 것: 이 글의 독자는 라우팅 판정을 하는 모델이지 스킬을 사용하는 모델이 아니다. 판정에 필요한 것은 경계의 명확함이지 능력의 상세함이 아니다.
• "통상 경로"와 "예외 경로"를 명시적으로 분리할 것: 통상 작업은 2층에서 끝나야 한다. 3층이 대다수 작업에서 발동된다면 거기 담긴 것은 사실 주간 콘텐츠이며 층을 잘못 배치한 것이다.
• 예외 리소스에는 발동 조건을 명시할 것: 3층은 "당신의 설정에 따라" 인출된다. 리소스 자체 외에 "드문 날짜 포맷을 만나면 → 이 스크립트를 인출"이라는 규칙이 있어야 모델에게 인출 근거가 생긴다.
• "파일을 찾을 수 없음" 오류율로 좌표 품질을 역추적할 것: 이 오류가 계속 나온다면 검색 모듈이 고장 난 것이 아니라 입구에서 절대 경로나 고유 식별자를 주지 않아 모델이 환각으로 좌표를 채우고 있는 것이다.
• 분할 입도는 호출 라운드 수로 건강검진할 것: 모델이 기본 규칙을 반복 조회하며 루프를 돌고 있다면 지나치게 쪼갠 것이다. 컨텍스트에서 아낀 돈을 호출 시간이 먹고 있다.
• 스킬을 늘리기 전에 디커플링을 먼저 확인할 것: 신규 스킬 추가 시 단일 대화의 컨텍스트가 함께 커지는지 검사할 것. 커진다면 1층이 극단적 간결에 도달하지 못한 것이고, 규모화되는 즉시 무너진다.