프롬프트만 고치다 AI 에이전트가 망가진다: 컨텍스트 엔지니어링 실전 가이드

AI 에이전트를 만들었는데 대화가 길어질수록 지시를 잊고, 이미 확인한 내용을 다시 검색하며, 끝난 일을 반복한다면 무엇부터 고쳐야 할까요? 프롬프트 문장을 더 강하게 쓰는 것만으로는 부족할 수 있습니다. 컨텍스트 엔지니어링은 AI가 매 단계에서 보는 지시, 자료, 도구 결과, 메모리와 작업 상태를 설계하는 방법입니다. 이 글은 프롬프트 엔지니어링과 컨텍스트 엔지니어링의 차이부터 RAG, 메모리, 평가, 운영 설계까지 실무 관점으로 연결합니다.

 

핵심 요약

• 프롬프트는 AI에게 무엇을 어떻게 하라고 지시하는 중요한 구성 요소입니다. 컨텍스트 엔지니어링은 그 지시를 포함해 판단에 필요한 정보 전체를 관리합니다.

• 컨텍스트 창이 크다고 모든 정보를 넣는 방식이 항상 유리하지는 않습니다. 관련성, 최신성, 출처와 작업 단계가 함께 중요합니다.

• AI 에이전트는 도구 실행 결과를 확인하면서 다음 행동을 결정합니다. 성공 기준과 중단 조건을 외부 상태로 확인할 수 있어야 합니다.

• 도입 효과는 실제 업무의 성공률, 비용, 지연 시간, 오류 복구율로 검증해야 합니다. 특정 블로그의 사례를 모든 서비스의 성능 보장으로 받아들여서는 안 됩니다.

 

이 글의 대상은 누구인가

LLM 기반 업무 자동화, 사내 검색, 고객 지원, 코딩 에이전트를 설계하는 개발자와 기획자를 대상으로 합니다. 모델을 직접 학습시키지 않아도 개선할 수 있는 영역을 설명하되, 컨텍스트 설계만으로 모델의 모든 한계를 해결할 수 있다고 주장하지는 않습니다. 아래 사례와 체크리스트는 공개 기술 문서를 바탕으로 구성한 설계 예시이며, 필자가 운영 실험으로 측정한 성과 수치는 아닙니다.

 

목차

1. 프롬프트만 고치면 왜 같은 문제가 반복될까

2. 프롬프트·컨텍스트·RAG·메모리의 차이

3. 워크플로우와 AI 에이전트의 선택 기준

4. 컨텍스트를 쓰고, 고르고, 압축하고, 분리하기

5. 검색·도구·메모리를 연결하는 실제 설계

6. 실패를 줄이는 평가와 운영 지표

7. 업무 적용 예시와 도입 순서

8. 자주 묻는 질문과 참고 자료

 

1. 프롬프트만 고치면 왜 같은 문제가 반복될까

 

프롬프트 엔지니어링은 여전히 중요합니다. 역할, 목표, 제한 사항, 출력 형식과 좋은 예시를 명확하게 쓰면 결과의 일관성을 높일 수 있습니다. 문제는 지시가 아무리 좋아도 판단 재료가 틀렸거나 누락되면 올바른 행동을 기대하기 어렵다는 점입니다. 최신 환불 규정이 필요한데 오래된 문서만 제공했다면, “정확하게 답하라”는 문장을 반복해도 규정의 날짜는 바뀌지 않습니다.

 

대화형 챗봇에서는 한 번의 답변 품질이 주로 보입니다. 반면 AI 에이전트에서는 검색, 읽기, 판단, 도구 실행, 결과 확인이 연속으로 이어집니다. 첫 단계에서 잘못 저장한 사실이 다음 단계의 전제가 될 수 있고, 도구가 반환한 긴 로그가 사용자의 핵심 조건을 밀어낼 수 있습니다. 따라서 오류를 수정할 때 문장 표현뿐 아니라 정보가 언제 들어왔고 어느 단계에서 다시 사용되었는지도 살펴봐야 합니다.

 

예를 들어 고객이 “주문 두 건 중 아직 발송되지 않은 한 건만 취소해 달라”고 요청했다고 가정해 보겠습니다. 시스템이 고객 요청, 주문 번호, 배송 상태, 취소 권한, 이미 수행한 작업을 구분하지 않으면 두 주문을 모두 대상으로 판단할 위험이 있습니다. 이 문제에 필요한 개선은 “조심해서 취소하라”는 추상적인 경고보다 대상 주문의 명시, 최신 상태 조회, 실행 전 조건 검증, 실행 후 확인입니다.

 

Anthropic은 2025년 9월 공개한 컨텍스트 엔지니어링 글에서 모델의 입력을 유한한 자원으로 다룹니다. 핵심은 원하는 행동을 이끌어낼 수 있는 정보의 구성을 찾는 것입니다. 이는 무조건 입력을 짧게 하라는 뜻이 아닙니다. 빠지면 안 되는 세부 조건을 보존하면서, 현재 결정과 관계없는 내용이 경쟁하지 않도록 정리하라는 의미에 가깝습니다.

 

2. 프롬프트·컨텍스트·RAG·메모리의 차이

 

프롬프트 엔지니어링은 모델에게 전달하는 지시를 작성하고 조직하는 활동입니다. 컨텍스트 엔지니어링은 지시뿐 아니라 검색 문서, 도구 설명, 실행 결과, 대화 이력, 메모리 등 추론 시점의 입력을 구성하고 유지하는 활동입니다. 둘은 경쟁 관계가 아닙니다. 좋은 프롬프트는 좋은 컨텍스트의 일부이며, 잘 설계된 자료도 해석 지침이 불명확하면 잘못 사용될 수 있습니다.

 

RAG는 검색 증강 생성입니다. 필요한 자료를 외부 저장소에서 찾아 모델에 제공하는 접근입니다. 컨텍스트 엔지니어링 안에서 지식을 고르는 중요한 수단이지만, 모든 문제가 검색 문제는 아닙니다. 검색 결과가 정확해도 서로 다른 버전의 정책이 섞이거나, 도구 실행이 실패했는데 성공으로 기록되면 전체 작업은 틀릴 수 있습니다. 검색 품질과 행동 상태 관리는 각각 확인해야 합니다.

 

메모리는 이후 단계나 다른 세션에서 다시 사용할 정보를 보관하는 기능입니다. 현재 작업의 진행 상태를 저장하는 단기 메모리와, 여러 세션에 걸쳐 재사용하는 장기 메모리를 구분하면 설계가 쉬워집니다. “이 요청의 첫 번째 주문 조회가 끝났다”는 정보와 “사용자가 한국어 답변을 선호한다”는 정보는 수명과 적용 범위가 다릅니다. 하나의 저장소에 넣더라도 사용할 때는 범위를 구별해야 합니다.

 

컨텍스트 창은 모델이 한 번에 처리할 수 있는 입력과 출력의 범위에 관련된 용량입니다. 모델마다 계산 방식과 제한이 다르므로 서비스 문서를 확인해야 합니다. 용량이 늘면 더 많은 자료를 볼 여지가 생기지만, 관련 정보를 정확히 선택하는 일이 사라지지는 않습니다. 문서 전체를 읽는 것과 최신 규정의 정확한 조항을 찾아 적용하는 것은 서로 다른 문제입니다.

 

개념을 한 문장씩 연결하면 다음과 같습니다. 프롬프트는 업무 지침, RAG는 필요한 자료를 찾는 경로, 메모리는 재사용할 기록, 컨텍스트 엔지니어링은 이들을 매 순간 어떤 조합으로 제공할지 정하는 설계입니다. 이 구분을 해두면 “답이 틀렸으니 모델을 바꾸자”는 결론에 바로 뛰어들지 않고 어느 구성 요소가 실패했는지 분해할 수 있습니다.

 

3. 워크플로우와 AI 에이전트의 선택 기준

 

Anthropic의 Building effective agents는 워크플로우와 에이전트를 구분합니다. 워크플로우는 미리 정한 코드 경로에 따라 LLM과 도구를 연결합니다. 에이전트는 LLM이 작업 과정과 도구 사용을 동적으로 결정하는 비중이 큽니다. 실제 제품은 두 방식을 섞을 수 있습니다. 문서 분류는 고정 경로로 처리하고, 예외 조사만 에이전트에 맡기는 구조가 한 예입니다.

 

순서와 조건이 분명한 업무는 워크플로우부터 검토할 만합니다. 입력 형식 확인, 문서 검색, 답변 초안 작성, 근거 확인처럼 단계가 안정적이면 각 지점에 검사 로직을 두기 쉽습니다. 모든 분기를 모델에게 맡겨야 자동화 수준이 높아지는 것은 아닙니다. 예측 가능한 코드는 비용과 지연 시간을 줄이고, 사고가 났을 때 어느 조건이 적용되었는지 추적하는 데도 유리합니다.

 

반대로 필요한 조사 횟수나 작업 경로를 미리 정하기 어려운 업무에서는 에이전트가 유용할 수 있습니다. 코드 저장소에서 오류의 원인을 조사하는 경우 수정할 파일과 검증 방법이 요청마다 달라집니다. 이때도 목표, 도구 권한, 예산, 중단 조건은 명시해야 합니다. 자율적으로 탐색한다는 것은 무제한으로 실행한다는 뜻이 아닙니다.

 

에이전트를 채택하기 전에는 단일 호출과 검색만으로 해결되는 기준선을 만들어야 합니다. 이후 다단계 워크플로우와 에이전트를 같은 평가 데이터로 비교합니다. 더 복잡한 방식이 실제 성공률을 높이는지, 그 개선이 추가 비용과 대기 시간을 정당화하는지 확인해야 합니다. 공개 기술 블로그의 중요한 공통점은 멋진 구조보다 측정 가능한 업무 결과를 먼저 보라는 데 있습니다.

 

4. 컨텍스트를 쓰고, 고르고, 압축하고, 분리하기

 

LangChain의 Context Engineering for Agents는 대표적인 전략을 쓰기, 선택하기, 압축하기, 분리하기로 정리합니다. 이 분류는 특정 제품을 반드시 사용하라는 규칙이 아닙니다. 현재 시스템에서 정보가 어디에 저장되고, 언제 모델에 노출되며, 얼마나 오래 유지되는지 점검하는 실용적인 틀입니다. 한 서비스 안에서도 네 전략이 동시에 필요할 수 있습니다.

 

4-1. 쓰기: 대화 이력 밖에 작업 상태를 남긴다

 

모든 진행 상황을 긴 채팅 기록 속에만 남기면 중요한 상태를 찾기 어려워집니다. 목표, 완료한 항목, 남은 항목, 사용자 제약, 확인한 사실과 출처를 구조화해 저장하면 다시 시작할 때 필요한 맥락을 복원하기 쉽습니다. 여기서 기록은 모델이 그럴듯하게 작성한 회고와 구별해야 합니다. 도구가 실제로 반환한 결과와 확인되지 않은 추정을 나누어 저장해야 합니다.

 

권장 상태 항목의 예시는 작업 ID, 대상 ID, 현재 단계, 완료 조건, 확인된 결과, 미해결 질문, 마지막 갱신 시각입니다. 취소 요청이라면 대상 주문 번호와 취소 결과를 연결해 보관합니다. 글 작성 업무라면 주제, 출처 목록, 편집 단계와 저장 상태가 필요합니다. 하나의 범용 메모에 모든 업무를 구겨 넣기보다, 다음 판단에 필요한 필드를 선택하는 편이 검증하기 쉽습니다.

 

4-2. 고르기: 지금 필요한 자료만 불러온다

 

검색 결과는 관련성만으로 정렬하면 부족할 수 있습니다. 문서의 적용 대상, 개정 시각, 권한, 원문 출처를 함께 확인해야 합니다. 같은 키워드를 포함해도 고객용 안내와 내부 예외 처리 지침은 역할이 다릅니다. 모델이 읽기 전에 접근 권한을 검사하고, 최종 답변에는 실제 판단을 뒷받침하는 근거를 연결해야 합니다.

 

Anthropic은 자료를 모두 미리 넣는 방법과 필요할 때 도구로 읽는 방법을 설명합니다. 경로, 링크, 문서 ID 같은 가벼운 참조를 유지하고 세부 내용을 필요한 시점에 불러오면 불필요한 입력을 줄일 수 있습니다. 다만 실행 중 탐색은 도구 호출과 대기 시간을 늘릴 수 있습니다. 항상 필요한 규칙은 미리 제공하고, 세부 근거는 상황에 따라 조회하는 혼합 방식이 현실적인 선택지가 됩니다.

 

4-3. 압축하기: 짧게 만드는 것보다 보존할 것을 정한다

 

대화 요약은 단순한 문장 축약이 아닙니다. 사용자 요청의 제한 조건, 결정된 사항, 남은 문제, 실행한 작업과 출처를 보존해야 합니다. “고객 요청을 처리하는 중”이라는 요약은 짧지만, 어느 주문을 처리했고 무엇이 남았는지 알려주지 않습니다. 반면 대상 ID와 완료 상태를 담은 짧은 구조화 기록은 후속 행동을 결정하는 데 도움이 됩니다.

 

요약에서 빠진 정보는 다음 단계에서 다시 복구하기 어려울 수 있습니다. 따라서 원본 기록은 별도로 보관하고, 요약에는 필요한 근거를 다시 찾아갈 참조를 남기는 편이 좋습니다. 오래된 로그를 제거하는 규칙도 성공적인 도구 결과와 아직 해결되지 않은 오류를 구분해야 합니다. 실패 메시지를 무조건 정리하면 복구에 필요한 단서까지 사라집니다.

 

4-4. 분리하기: 역할마다 필요한 정보를 다르게 준다

 

모든 정보를 모든 단계에 제공할 필요는 없습니다. 검색 단계는 문서 위치와 질의가 필요하고, 답변 단계는 검증된 근거와 표현 지침이 필요합니다. 실행 단계는 대상 ID, 권한, 요청 조건을 정확히 알아야 합니다. 이처럼 상태의 일부만 노출하는 방법으로도 컨텍스트를 분리할 수 있습니다. 반드시 여러 에이전트를 만들어야 하는 것은 아닙니다.

 

여러 에이전트를 사용할 경우에는 각자의 범위와 전달 형식을 더 명확히 해야 합니다. 조사 담당이 근거 없는 결론만 넘기면 작성 담당이 검증할 수 없습니다. 반대로 원문 전체를 그대로 전달하면 분리의 이점이 줄어듭니다. 핵심 주장, 출처, 날짜, 불확실한 부분을 함께 전달하고 최종 결과를 통합할 책임을 정해야 합니다. 병렬화가 추가하는 호출 비용과 조정 비용도 측정 대상입니다.

 

5. 검색·도구·메모리를 연결하는 실제 설계

 

검색 시스템을 개선할 때 흔히 검색 문서 수부터 늘립니다. 그러나 더 많은 문서가 더 좋은 판단을 보장하지는 않습니다. 먼저 실패 사례를 확인해야 합니다. 필요한 문서가 검색되지 않았는지, 검색되었지만 잘못된 조각만 제공되었는지, 정확한 조항이 있었는데 모델이 적용하지 못했는지에 따라 수정 지점이 달라집니다. 검색과 생성 오류를 분리하면 불필요한 튜닝을 줄일 수 있습니다.

 

도구 설명은 함수 이름보다 구체적이어야 합니다. 무엇을 수행하는지, 어떤 인자가 필요한지, 조회와 변경 중 무엇인지, 성공과 실패를 어떻게 구분하는지 알려줘야 합니다. 비슷한 이름의 도구가 많으면 선택이 어려워질 수 있으므로 중복 기능을 줄이는 것이 좋습니다. 입력 검증과 권한 검사는 자연어 설명에만 의존하지 말고 실제 프로그램에서 강제해야 합니다.

 

도구 결과도 다음 판단에 맞춰 설계해야 합니다. 주문 조회에 필요한 결과라면 주문 ID, 배송 상태, 갱신 시각, 취소 가능 여부를 명확하게 반환합니다. 관련 없는 내부 로그와 대용량 원문을 항상 붙이면 핵심 필드를 찾기 어려워집니다. 상세 로그는 필요할 때 다시 조회할 수 있도록 식별자를 주고, 기본 결과는 판단에 필요한 필드 중심으로 구성하는 방식을 검토할 수 있습니다.

 

특히 재시도는 별도 설계가 필요합니다. 네트워크 시간 초과는 실행이 없었다는 뜻이 아닐 수 있습니다. 서버에서 변경은 끝났지만 응답만 도착하지 않았을 수 있기 때문입니다. 상태를 확인하지 않고 같은 변경을 다시 요청하면 중복 처리가 발생할 수 있습니다. 서비스가 지원하는 경우 요청 식별자와 중복 방지 처리를 사용하고, 불확실한 결과는 재조회로 확인해야 합니다.

 

메모리를 저장할 때는 사실, 선호, 임시 상태, 추론을 구분합니다. 사용자가 한 번 특정 주제를 물었다고 해서 영구적인 관심사로 확정하면 이후 작업에 엉뚱한 정보가 들어갈 수 있습니다. 저장 근거와 갱신 시각, 적용 범위, 삭제 방법을 두고, 오래되거나 충돌하는 항목을 정리하는 기준을 마련해야 합니다. 메모리는 많이 쌓는 기능보다 적절하게 다시 사용하는 기능이 중요합니다.

 

외부 문서에 있는 명령문과 사용자의 지시도 분리해야 합니다. 검색한 페이지가 “이전 지침을 무시하라”고 쓰고 있어도 그것은 조사 대상의 텍스트입니다. 시스템의 권한이나 작업 목표를 바꾸는 근거로 사용해서는 안 됩니다. 외부 자료가 행동에 영향을 주는 경로를 점검하고, 실행 권한을 제한하며, 중요한 변경 전후의 상태를 검증하는 설계가 필요합니다.

 

6. 실패를 줄이는 평가와 운영 지표

 

평가는 “답이 자연스럽다”는 인상에서 멈추면 안 됩니다. 업무가 완료되었는지, 대상이 정확했는지, 근거가 최신인지, 허용 범위를 지켰는지 확인해야 합니다. 예를 들어 고객 지원에서는 안내 문장의 친절함과 실제 주문 상태 변경의 정확성을 나누어 평가할 수 있습니다. 코딩 업무에서는 테스트 통과뿐 아니라 요청한 동작과 무관한 변경이 없는지도 검토해야 합니다.

 

첫 번째 지표는 업무 성공률입니다. 성공 조건을 사람이 확인할 수 있는 기준으로 적습니다. “보고서를 잘 썼다”보다 “필수 항목을 포함하고 각 핵심 수치에 근거가 있으며 요청 형식으로 저장되었다”가 더 검증하기 쉽습니다. 필요한 조건을 충족하지 못한 부분 성공을 완전 성공과 섞지 않는 것도 중요합니다. 자동 평가와 표본에 대한 사람 검토를 조합할 수 있습니다.

 

두 번째는 성공한 작업 한 건당 비용입니다. 호출당 가격만 보면 재시도와 실패의 비용을 놓칠 수 있습니다. 모델 입력·출력 비용, 검색과 도구 호출 비용, 재시도 횟수, 사람 검토 부담을 함께 봐야 합니다. 저렴한 모델이 여러 번 실패하는 구조와 비싼 모델이 한 번에 완료하는 구조는 실제 업무 단위에서 비교해야 의미가 있습니다.

 

세 번째는 전체 지연 시간과 사용자가 기다리는 시간입니다. 평균만 보면 드물게 매우 오래 걸리는 요청이 가려질 수 있으므로 분포도 확인해야 합니다. 자료를 매번 탐색하는 방식이 정확도를 높여도 응답 시간이 서비스 요구를 넘으면 조정이 필요합니다. 캐시, 사전 검색, 단계별 모델 선택 등을 적용한 뒤 성공률이 유지되는지 함께 평가합니다.

 

네 번째는 오류 복구율과 반복 행동입니다. 동일 질의의 불필요한 재검색, 이미 완료한 도구의 재호출, 실패 원인을 반영하지 않은 재시도는 컨텍스트 설계 문제의 단서가 됩니다. 반복 횟수를 제한하는 것만으로 원인이 해결되지는 않습니다. 어떤 결과를 읽지 못했는지, 상태가 누락되었는지, 종료 조건이 모호했는지 실행 기록을 확인해야 합니다.

 

실험에서는 모델, 프롬프트, 검색 설정, 도구 버전과 평가 데이터의 버전을 기록합니다. 한 번에 여러 요소를 바꾸면 개선 이유를 알기 어렵습니다. 같은 요청 집합에서 기준선과 변경안을 비교하고, 실제 배포 전 새로운 사례에서도 효과가 유지되는지 확인합니다. 공개 자료의 성능 수치가 있더라도 자신의 데이터와 권한 환경에서 재현하기 전에는 목표치로 단정하지 않는 편이 타당합니다.

 

7. 업무 적용 예시: 사내 규정 질의 에이전트

 

여기서는 “출장 숙박비를 얼마까지 청구할 수 있는가”를 묻는 사내 지원 서비스를 가정합니다. 가장 단순한 기준선은 질문을 분류하고 관련 규정을 검색해 근거와 함께 답하는 구조입니다. 사용자의 지역, 직급, 출장 시점처럼 정책 적용에 필요한 조건이 빠졌다면 먼저 그 조건을 확인합니다. 필요한 정보가 없을 때 임의의 금액을 만들어 답하지 않는 것이 성공 조건에 포함됩니다.

 

입력 컨텍스트는 업무 지침, 현재 질문, 적용에 필요한 사용자 정보, 검색한 규정의 해당 조항으로 구성할 수 있습니다. 모든 인사 규정 전체를 넣기보다 숙박비와 예외 조건에 관련된 부분을 고릅니다. 문서마다 제목, 시행일, 출처를 함께 제공하면 서로 충돌할 때 확인할 단서가 생깁니다. 어떤 문서가 우선하는지는 조직의 실제 규정에 따라 정해야 합니다.

 

작업 상태에는 확인된 조건과 아직 모르는 조건을 나눠 기록합니다. “국내 출장, 다음 달 예정, 직급 미확인”처럼 남기면 다음 단계에서 무엇을 물어야 하는지 분명해집니다. 최종 답변에는 적용 기준, 한도, 예외, 근거와 추가 확인이 필요한 사항을 구분합니다. 이 구조는 친절한 설명을 작성하는 능력과 규정을 정확히 적용하는 능력을 따로 검증하게 해줍니다.

 

이후 증빙 제출까지 자동화한다면 변경 도구가 추가됩니다. 답변만 제공할 때와 달리 어떤 문서를 어느 신청 건에 첨부할지, 사용자가 제출을 요청했는지, 서버에서 접수가 완료되었는지 확인해야 합니다. 검색 에이전트에 모든 쓰기 권한을 바로 부여할 이유는 없습니다. 필요한 작업 단계에 필요한 권한만 제공하면 검증 범위도 명확해집니다.

 

이 사례에서 컨텍스트 엔지니어링의 성과는 문장을 더 풍부하게 만드는 데만 있지 않습니다. 적용 조건 누락, 과거 규정 사용, 중복 제출, 근거 없는 답변을 얼마나 줄이는지로 평가할 수 있습니다. 실제 업무에 도입할 때는 정상 사례뿐 아니라 정책 충돌, 검색 실패, 권한 부족, 시간 초과 같은 예외 사례도 평가 데이터에 넣어야 합니다.

 

8. 국내 기술 블로그에서 참고할 설명 방식

 

이번 조사에서는 Anthropic과 LangChain의 엔지니어링 글을 개념과 설계 패턴의 근거로 확인했고, 국내 사례로 SK DEVOCEAN의 프롬프트에서 컨텍스트 엔지니어링까지 다룬 글을 읽었습니다. 국내 글은 배경과 기술 변화의 흐름을 설명한 뒤 구체적인 방법론과 한계를 연결합니다. 이 글 역시 문제 상황, 개념 정리, 설계 예시, 검증 기준 순서로 독자가 적용 지점을 찾도록 구성했습니다.

 

DEVOCEAN 글은 ACE라는 특정 연구 접근도 소개합니다. 컨텍스트를 경험에 따라 갱신하는 플레이북으로 다룬다는 점이 흥미롭습니다. 다만 일반적인 컨텍스트 엔지니어링과 특정 연구인 ACE는 같은 범위의 말이 아닙니다. 이 글은 ACE 논문 실험을 직접 재현하거나 원문 전체를 검증한 보고서가 아니므로, 해당 연구의 성능 수치를 일반적인 도입 효과로 옮기지 않았습니다.

 

기술 글을 읽을 때는 개념 설명, 제품 구현, 연구 결과를 구분하면 좋습니다. 제품 팀의 문서는 실제 구현 아이디어를 얻는 데 도움이 되지만 그 제품의 특성과 목적을 반영합니다. 연구 결과는 데이터셋과 실험 조건이 붙어 있습니다. 국내 블로그의 해설은 이해를 돕지만 중요한 구현 결정을 할 때는 연결된 원문과 현재 사용 중인 서비스 문서를 다시 확인해야 합니다.

 

9. 바로 시작하는 도입 순서

 

첫 단계는 실패한 실제 요청을 모아 유형을 나누는 것입니다. 지시 이해 실패, 검색 누락, 오래된 정보, 상태 유실, 도구 오용, 종료 판단 오류를 구분합니다. 둘째 단계는 단일 호출 또는 단순 워크플로우의 기준선을 측정하는 것입니다. 기준선이 없으면 복잡한 구조가 정말 도움이 되는지 알기 어렵습니다.

 

셋째 단계는 상태와 근거를 구조화하는 것입니다. 목표, 제약, 대상, 완료 상태, 출처를 분리하고 각 단계에서 필요한 항목만 제공합니다. 넷째 단계는 도구 계약을 정리하는 것입니다. 입력 의미, 성공 조건, 오류 유형, 재시도 가능 여부가 명확한지 확인합니다. 다섯째 단계는 대화가 길어질 때의 요약과 복원 방식을 평가하는 것입니다.

 

마지막 단계는 변경 전후를 비교하고 점진적으로 배포하는 것입니다. 성공률이 좋아졌더라도 지연 시간이나 검토 부담이 커졌다면 서비스 목표에 맞춰 조정합니다. 컨텍스트 엔지니어링은 한 번의 프롬프트 수정으로 끝나는 작업보다, 실패 기록을 보고 정보 흐름을 개선하는 반복 과정에 가깝습니다. 작은 구조 변경을 측정하면서 쌓는 편이 무엇이 효과가 있었는지 설명하기 쉽습니다.

 

10. 자주 묻는 질문

 

Q. 이제 프롬프트 엔지니어링은 필요 없나요?

필요합니다. 목표와 제약을 명확하게 표현하는 일은 여전히 기본입니다. 다만 에이전트의 작업이 길어질수록 지시문뿐 아니라 검색, 메모리, 도구 결과와 상태 관리까지 함께 설계해야 합니다. 새로운 용어가 기존 기술의 모든 가치를 없애는 것은 아닙니다.

 

Q. 컨텍스트 창이 큰 모델을 쓰면 해결되나요?

더 많은 자료를 처리할 여지는 생깁니다. 그러나 관련 없는 자료와 충돌하는 규정이 함께 들어오는 문제, 오래된 메모리 문제, 잘못된 실행 상태는 용량만으로 해결되지 않습니다. 모델 선택과 정보 선택을 함께 평가해야 합니다.

 

Q. RAG를 이미 사용 중인데 무엇을 더 해야 하나요?

검색된 문서의 관련성과 최신성 외에 어떤 지시와 이력이 함께 들어가는지 살펴보세요. 도구 결과가 불필요하게 길지 않은지, 작업 상태가 명확한지, 최종 답변이 실제 근거를 사용하는지 점검하면 다음 개선 지점을 찾을 수 있습니다.

 

Q. 멀티 에이전트가 항상 더 좋나요?

업무를 독립적으로 나누고 필요한 결과를 통합할 수 있을 때 장점이 생길 수 있습니다. 반면 조정 비용과 정보 전달 손실이 추가될 수 있습니다. 단일 에이전트 또는 단순 워크플로우와 같은 조건에서 비교한 뒤 결정하는 것이 적절합니다.

 

Q. 컨텍스트 엔지니어링의 최종 목표는 무엇인가요?

입력을 무조건 줄이거나 도구 수를 늘리는 것이 목표는 아닙니다. 현재 단계에서 필요한 근거와 상태를 제공해 요청한 업무를 정확히 끝내는 것입니다. 사용자가 체감하는 성공률과 비용, 대기 시간, 오류 복구 능력으로 그 결과를 확인해야 합니다.

 

마치며

AI 에이전트가 지시를 잊거나 같은 행동을 반복할 때 프롬프트를 살펴보는 것은 좋은 출발점입니다. 거기서 한 걸음 더 나아가 모델이 실제로 받은 자료, 검색한 근거, 도구 결과와 작업 상태를 함께 확인해야 합니다. 프롬프트 엔지니어링이 명확한 업무 지침을 만드는 일이라면, 컨텍스트 엔지니어링은 그 지침을 수행할 정보 환경을 지속적으로 관리하는 일입니다.

 

다음 개선은 거대한 프레임워크 교체일 필요가 없습니다. 실패한 요청 하나를 고르고, 빠진 조건을 상태에 기록하고, 오래된 문서를 제외하고, 실행 결과를 확인하는 검사부터 추가해 볼 수 있습니다. 작은 변경이 실제 성공률을 높이는지 측정하는 과정이 AI 에이전트를 데모에서 업무 도구로 발전시키는 실질적인 방법입니다.

 

참고 자료와 출처

아래 자료의 본문을 확인해 개념을 정리했습니다. 제품 기능과 문서 내용은 이후 변경될 수 있으므로 실제 구현에서는 최신 문서를 확인하세요.

 

[1] Anthropic, Building effective agents, 2024.12.19.

워크플로우와 에이전트의 구분, 단순한 설계부터 시작하는 원칙, 도구 인터페이스와 실행 피드백을 참고했습니다. 현재 페이지에는 초기 발행 이후 도구 환경이 달라졌다는 안내가 있습니다.

https://www.anthropic.com/engineering/building-effective-agents

Building effective AI agents

 

[2] Anthropic, Effective context engineering for AI agents, 2025.09.29.

프롬프트와 컨텍스트의 관계, 필요한 시점의 자료 조회, 압축, 구조화된 메모와 장기 작업의 컨텍스트 관리를 참고했습니다.

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Effective context engineering for AI agents

 

[3] LangChain, Context Engineering for Agents, 2025.07.02.

쓰기, 선택, 압축, 분리라는 분류와 상태·메모리·도구 결과 관리의 사례를 참고했습니다. 특정 제품의 성능 보장으로 인용하지 않았습니다.

https://blog.langchain.com/context-engineering-for-agents/

Context Engineering

 

[4] SK DEVOCEAN, 소리지르는비버, AI 에이전트의 진화: 프롬프트에서 컨텍스트 엔지니어링까지 (ACE를 곁들인), 2025.10.16.

국내 기술 블로그의 배경 설명과 방법론·한계 제시 구성을 참고했습니다. ACE의 실험 수치는 본문에서 재인용하지 않았습니다.

https://devocean.sk.com/blog/techBoardDetail.do?ID=167967