21. 효과적인 프롬프팅과 컨텍스트 관리

비유로 시작하기: 좋은 지시서가 좋은 결과를 만든다

유능한 직원에게도 모호한 지시를 주면 엉뚱한 결과가 나옵니다. "보고서 좀 써줘"보다 "경쟁사 3곳의 가격을 표로 정리하고, 우리 제품의 강점 2가지를 결론에 넣어줘"가 훨씬 나은 결과를 냅니다. 에이전트도 똑같습니다. 프롬프트는 에이전트에게 주는 지시서이고, 그 품질이 결과 품질의 상한을 정합니다.

이 장의 원칙은 특정 프레임워크 전용이 아닙니다. OpenAI SDK의 instructions, CrewAI의 role/goal/backstory, LangGraph 노드의 시스템 메시지, n8n의 System Message — 표현은 달라도 모두 같은 원칙이 적용됩니다.

프롬프팅 5원칙

이 강좌 전체에서 반복된 원칙을 한자리에 모읍니다.

📌 핵심: 8장에서 매니저 에이전트가 부하를 안 쓰던 문제, 10장에서 트리아지가 엉뚱하게 라우팅하던 문제, 둘 다 프롬프트 구체화로 해결했습니다. 에이전트가 기대대로 안 움직일 때 첫 번째 점검 대상은 거의 항상 프롬프트입니다.

도구 설명: 가장 자주 놓치는 레버

5장부터 반복했듯, 도구의 description(또는 독스트링)은 모델이 "언제 이 도구를 쓸지" 판단하는 유일한 근거입니다. 도구가 있어도 안 쓰이거나 엉뚱하게 쓰인다면, 십중팔구 설명이 모호한 탓입니다.

# 나쁨 — 언제 쓸지 알 수 없음
@function_tool
def search(q: str) -> str:
    """검색한다."""
    ...

# 좋음 — 용도·입력·반환이 명확
@function_tool
def search_product_catalog(query: str) -> str:
    """제품 카탈로그에서 이름·설명으로 제품을 검색해
    최대 5개의 제품명과 가격을 반환한다.
    재고나 배송 정보가 필요할 때는 사용하지 않는다."""
    ...

💡 팁: "이 도구를 쓰지 말아야 할 때"를 함께 적으면 오용이 크게 줄어듭니다. 모델은 경계가 분명할 때 더 정확히 판단합니다.

큰 컨텍스트 다루기

3장에서 봤듯, 토큰은 비용이자 한계입니다. 큰 코드베이스·긴 문서·장기 대화를 다룰 때는 "모든 것을 한 번에 넣기"가 불가능합니다. 세 가지 전략을 조합합니다.

flowchart TB
    classDef strat fill:#80DEEA,stroke:#00838F,color:#000

    A[큰 컨텍스트 문제]
    A --> S1[요약<br/>오래된 내용 압축]:::strat
    A --> S2[RAG<br/>필요한 조각만 검색해 주입]:::strat
    A --> S3[청킹·선택<br/>관련 부분만 골라 전달]:::strat

요약(Summarization)은 4장에서 본 메모리 전략입니다. 오래된 대화나 긴 문서를 요약문으로 압축합니다. RAG(Retrieval-Augmented Generation)는 전체를 벡터로 저장해 두고, 질문과 관련된 조각만 검색해 그때그때 컨텍스트에 주입합니다(n8n의 벡터 스토어 도구, LangGraph의 검색 노드 등). 청킹·선택은 큰 입력을 조각내고 관련된 부분만 골라 전달합니다. (청킹은 큰 문서를 검색·처리하기 좋게 일정 크기로 잘게 나누는 것을 말합니다.)

📌 핵심: RAG의 멘탈 모델은 "컨텍스트는 채팅 기록이 답하는 '방금 무슨 얘기 했지?'와 다르다"는 것입니다. 채팅 메모리는 대화 맥락을, RAG는 "이 주제에 대해 내가 아는 지식"을 답합니다. 프로덕션 에이전트는 보통 둘을 함께 씁니다.

💡 팁: RAG에서 청크 크기는 512~1024 토큰, 겹침은 64~128 토큰이 지원·정책 문서에 잘 맞는다고 알려져 있습니다. 청크가 너무 크면 검색 정확도가 떨어지고 컨텍스트 비용이 늘며, 너무 작으면 맥락이 끊깁니다.

평가와 개선의 반복 루프

좋은 에이전트는 한 번에 나오지 않습니다. 만들고 → 관찰하고 → 고치는 반복으로 다듬어집니다. 6장에서 본 트레이싱, n8n의 실행 이력, LangGraph의 상태 시각화가 모두 이 "관찰" 단계를 돕습니다.

flowchart LR
    classDef step fill:#80DEEA,stroke:#00838F,color:#000
    classDef obs fill:#FFE082,stroke:#F9A825,color:#000

    B[프롬프트·도구 구성] --> R[실행]:::step
    R --> O[트레이스·로그 관찰]:::obs
    O --> F[실패 지점 파악]:::step
    F --> B

⚠️ 흔한 실수: 에이전트가 틀리면 곧장 "더 센 모델"로 바꾸는 것. 많은 경우 모델이 아니라 프롬프트·도구 설명·컨텍스트 구성이 문제입니다. 트레이스로 어느 단계에서 어긋났는지 먼저 확인하세요. 모델 교체는 그다음입니다.

💡 팁: 평가를 위해 대표 입력 10~20개를 "테스트 세트"로 모아두면, 프롬프트를 바꿀 때마다 회귀(이전엔 되던 게 깨짐)를 빠르게 잡을 수 있습니다.

이 장에서 배운 것

• 프롬프팅 원칙(구체성·역할·출력 형식·단계 안내·예시)은 모든 프레임워크에 공통으로 통한다.
• 도구 설명은 모델의 도구 선택을 좌우하는 핵심 레버다. "쓰지 말아야 할 때"도 함께 적는다.
• 큰 컨텍스트는 요약·RAG·청킹을 조합해 다룬다. 채팅 메모리와 RAG는 답하는 질문이 다르며 보통 함께 쓴다.
• 에이전트는 만들고-관찰하고-고치는 반복으로 개선한다. 틀리면 모델 교체보다 프롬프트·트레이스를 먼저 본다.

✍️ 확인 문제

1. 도구 설명에 "쓰지 말아야 할 때"를 적으면 어떤 이점이 있는가?
2. 채팅 메모리와 RAG는 각각 어떤 질문에 답하며, 왜 프로덕션에서 함께 쓰는가?
3. 에이전트가 자꾸 틀릴 때 "더 센 모델로 교체"가 첫 대응으로 부적절한 이유는?

이전 부: 20. 실전 n8n
다음 장: 22. 비용·토큰 관리와 보안