ai-agents-for-beginners

AI 에이전트를 위한 컨텍스트 엔지니어링

(위 이미지 클릭 시 이 수업의 영상 시청)

AI 에이전트를 구축하는 응용프로그램의 복잡성을 이해하는 것은 신뢰할 수 있는 에이전트를 만드는 데 중요합니다. 우리는 프롬프트 엔지니어링을 넘어 복잡한 요구를 해결하기 위해 정보를 효과적으로 관리하는 AI 에이전트를 구축해야 합니다.

이번 강의에서는 컨텍스트 엔지니어링이 무엇이며 AI 에이전트 구축에서 어떤 역할을 하는지 살펴보겠습니다.

소개

이번 강의에서 다룰 내용:

• 컨텍스트 엔지니어링이란 무엇인지, 그리고 프롬프트 엔지니어링과 어떻게 다른지.

• 효과적인 컨텍스트 엔지니어링을 위한 전략, 정보 작성, 선택, 압축, 분리 방법 포함.

• AI 에이전트를 좌절시키는 일반적인 컨텍스트 실패와 이를 해결하는 방법.

학습 목표

본 강의를 완료하면 다음을 이해하게 됩니다:

• 컨텍스트 엔지니어링을 정의하고 프롬프트 엔지니어링과 구별하는 방법.

• 대규모 언어 모델(LLM) 응용프로그램에서 컨텍스트의 주요 구성요소를 식별하는 방법.

• 에이전트 성능 개선을 위한 컨텍스트의 작성, 선택, 압축, 분리 전략 적용 방법.

• 중독, 산만, 혼동, 충돌 같은 일반적인 컨텍스트 실패를 인식하고 완화 기법을 구현하는 법.

컨텍스트 엔지니어링이란 무엇인가?

AI 에이전트에게 컨텍스트란 특정 작업을 수행하기 위한 계획을 이끄는 정보입니다. 컨텍스트 엔지니어링은 AI 에이전트가 다음 작업을 완수하는 데 올바른 정보를 갖도록 보장하는 실천입니다. 컨텍스트 창은 크기 제한이 있으므로 에이전트 개발자는 정보를 추가, 삭제, 압축하는 시스템과 프로세스를 구축해야 합니다.

프롬프트 엔지니어링과 컨텍스트 엔지니어링의 차이

프롬프트 엔지니어링은 단일 고정된 지침 세트에 초점을 맞춰 AI 에이전트를 효과적으로 안내하는 일입니다. 반면 컨텍스트 엔지니어링은 초기 프롬프트를 포함한 동적 정보 집합을 관리하여 시간이 지나도 AI 에이전트가 필요한 정보를 확보하도록 하는 방법입니다. 컨텍스트 엔지니어링의 핵심은 이 과정을 반복 가능하고 신뢰할 수 있게 만드는 것입니다.

컨텍스트의 유형

컨텍스트가 단 하나의 정보만 뜻하지 않는다는 것을 기억하는 것이 중요합니다. AI 에이전트가 필요한 정보는 다양한 출처에서 올 수 있으며, 에이전트가 이 출처들에 접근할 수 있도록 만드는 것은 우리의 역할입니다:

AI 에이전트가 관리해야 할 컨텍스트 유형은 다음과 같습니다:

• 지침(Instructions): 에이전트의 “규칙”과 같습니다 - 프롬프트, 시스템 메시지, 몇 가지 예시(행동 방법 안내), 그리고 사용할 수 있는 도구 설명입니다. 프롬프트 엔지니어링과 컨텍스트 엔지니어링이 결합되는 부분입니다.

• 지식(Knowledge): 사실, 데이터베이스에서 검색된 정보, 에이전트가 축적한 장기 기억 등을 포함합니다. 에이전트가 다양한 지식 저장소와 데이터베이스에 접근해야 하는 경우 Retrieval Augmented Generation(RAG) 시스템 통합이 포함됩니다.

• 도구(Tools): 에이전트가 호출할 수 있는 외부 함수, API, MCP 서버 정의와 이 사용 후 받는 피드백(결과)입니다.

• 대화 기록(Conversation History): 사용자와의 진행 중 대화입니다. 시간이 지날수록 대화가 길고 복잡해져 컨텍스트 창에서 공간을 많이 차지합니다.

• 사용자 선호(User Preferences): 사용자의 좋아하거나 싫어하는 것에 대한 시간이 지나며 학습된 정보입니다. 중요한 결정을 내릴 때 참고하도록 저장 및 호출할 수 있습니다.

효과적인 컨텍스트 엔지니어링 전략

계획 전략

좋은 컨텍스트 엔지니어링은 좋은 계획에서 시작됩니다. 다음 접근법은 컨텍스트 엔지니어링 개념을 적용할 때 도움이 됩니다:

명확한 결과 정의 - AI 에이전트가 수행할 작업의 결과를 명확히 정의해야 합니다. “AI 에이전트가 작업을 마치면 세상은 어떻게 변할까?” 라는 질문에 답하십시오. 다시 말해, 사용자가 AI 에이전트와 상호작용 후 어떤 변화, 정보, 응답을 가질지 명확히 합니다.
컨텍스트 매핑 - AI 에이전트의 결과를 정의한 후, “이 작업을 완료하려면 AI 에이전트가 어떤 정보가 필요할까?” 라는 질문에 답해야 합니다. 이렇게 하면 해당 정보가 어디에 위치하는지 컨텍스트 맵을 만들 수 있습니다.
컨텍스트 파이프라인 생성 - 정보 위치를 알았다면 이어서 “에이전트는 이 정보를 어떻게 얻을까?” 에 답해야 합니다. 이는 RAG나 MCP 서버 및 기타 도구 활용 등 다양한 방법으로 구현할 수 있습니다.

실용적인 전략

계획도 중요하지만 정보가 에이전트의 컨텍스트 창에 흘러들어오기 시작하면 이를 관리할 실용 전략이 필요합니다:

컨텍스트 관리

일부 정보는 컨텍스트 창에 자동으로 추가되지만, 컨텍스트 엔지니어링은 다음과 같은 몇 가지 전략으로 보다 적극적으로 이 정보를 관리하는 것입니다:

에이전트 스크래치패드(Agent Scratchpad) 이는 AI 에이전트가 단일 세션 동안 현재 작업 및 사용자 상호작용과 관련된 중요한 메모를 할 수 있게 합니다. 이 메모는 컨텍스트 창 외부의 파일 또는 런타임 객체에 존재하며 필요시 에이전트가 후에 불러올 수 있어야 합니다.
기억(Memories) 스크래치패드는 단일 세션의 컨텍스트 창 밖 정보를 관리하는 데 좋습니다. 기억은 여러 세션에 걸쳐 관련 정보를 저장하고 조회할 수 있게 합니다. 여기에는 요약, 사용자 선호도, 개선을 위한 피드백 등이 포함됩니다.
컨텍스트 압축 컨텍스트 창이 커져 제한에 가까워지면 요약 및 다듬기 같은 기술을 사용할 수 있습니다. 이는 가장 관련성 높은 정보만 유지하거나 오래된 메시지를 제거하는 방법을 포함합니다.
멀티 에이전트 시스템(Multi-Agent Systems) 멀티 에이전트 시스템 개발은 각 에이전트가 자신만의 컨텍스트 창을 갖는 형태이므로 컨텍스트 공유와 전달 방식을 계획하는 컨텍스트 엔지니어링의 한 방식입니다.
샌드박스 환경(Sandbox Environments) 에이전트가 코드를 실행하거나 문서 내 대량 정보를 처리해야 할 때, 결과 처리가 많은 토큰을 필요로 할 수 있습니다. 이러할 때 모든 것을 컨텍스트 창에 저장하는 대신, 에이전트가 코드를 실행하고 결과 및 관련 정보만 읽어오는 샌드박스 환경을 사용할 수 있습니다.
런타임 상태 객체(Runtime State Objects) 특정 정보를 에이전트가 필요로 할 때 접근할 수 있도록 정보를 담는 컨테이너를 생성합니다. 복잡한 작업 시 각 하위 작업의 결과를 단계별로 저장해 컨텍스트가 오직 그 하위 작업과만 연결되게 할 수 있습니다.

컨텍스트 점검

이러한 전략 적용 후, 다음 모델 호출이 실제로 어떤 컨텍스트를 받았는지 확인하는 것이 효과적입니다. 유용한 디버깅 질문은:

에이전트가 너무 많은 컨텍스트를 불러왔나, 잘못된 컨텍스트를 불러왔나, 혹은 필요한 컨텍스트를 놓쳤나?

이 질문에 답하기 위해 원본 프롬프트, 도구 출력, 기억 내용을 전부 기록할 필요는 없습니다. 실제 운영 환경에서는 다음과 같은 소규모 컨텍스트 점검 기록이 선호됩니다:

선택(Selection): 후보 청크, 도구, 기억이 몇 개 고려되었으며, 몇 개가 선택되었고 어떤 규칙이나 점수에 따라 나머지가 걸러졌는지를 추적합니다.
압축(Compression): 원본 범위 또는 추적 ID, 요약 ID, 압축 전후 예상 토큰 수, 원본 내용이 다음 호출에서 제외되었는지를 기록합니다.
분리(Isolation): 별도의 에이전트, 세션, 샌드박스에서 실행된 하위 작업, 반환된 범위 요약, 큰 도구 출력이 부모 에이전트 컨텍스트 밖에 유지되었는지를 기록합니다.
기억 및 RAG(Memory and RAG): 검색된 문서 ID, 기억 ID, 점수, 선택 ID, 편집 상태를 원본 전체 텍스트 대신 저장합니다.
안전과 프라이버시(Safety and privacy): 민감한 프롬프트 텍스트, 도구 인자, 결과, 사용자 기억 본문 대신 해시, ID, 토큰 버킷, 정책 레이블을 선호합니다.

목표는 더 많은 컨텍스트를 보관하는 것이 아니라, 개발자가 어떤 컨텍스트 전략이 동작했고 다음 모델 호출에 의도한 영향을 주었는지 증거를 남기는 것입니다.

컨텍스트 엔지니어링 예시

예를 들어 AI 에이전트에게 “파리 여행 예약해 줘.” 라고 요청한다고 합시다.

• 단순히 프롬프트 엔지니어링만 사용하는 에이전트는 단지 이렇게 응답할 수 있습니다: “언제 파리에 가고 싶으세요?” 사용자가 질문한 시점에 직접 질문만 처리한 경우입니다.

• 컨텍스트 엔지니어링 전략을 적용한 에이전트는 훨씬 더 많은 일을 합니다. 응답하기 전에 시스템은 다음을 수행할 수 있습니다:

◦ 실시간 데이터를 활용하여 캘린더에서 사용 가능한 날짜를 확인합니다.

◦ 장기 기억에서 과거의 여행 선호사항을 기억합니다. 예를 들어 선호 항공사, 예산, 직항 선호 여부 등.

◦ 비행기 및 호텔 예약용으로 사용 가능한 도구를 식별합니다.

그리고 예시 응답은 이렇게 될 수 있습니다: “안녕하세요 [사용자 이름]님! 10월 첫째 주에 시간이 비시네요. 평소 예산 [예산] 내에서 [선호 항공사]의 직항편을 파리로 찾아 드릴까요?” 이처럼 풍부하고 컨텍스트를 고려한 응답은 컨텍스트 엔지니어링의 힘을 보여줍니다.

일반적인 컨텍스트 실패

컨텍스트 중독(Context Poisoning)

무엇인가: LLM이 생성한 환각(잘못된 정보)이나 오류가 컨텍스트에 들어가 반복 참조되면서 에이전트가 불가능한 목표를 추구하거나 터무니없는 전략을 개발하는 현상입니다.

대처법: 컨텍스트 유효성 검사와 격리(quarantine)를 구현하세요. 정보를 장기 기억에 추가하기 전 검증합니다. 중독 가능성이 감지되면 새로운 컨텍스트 쓰레드를 시작해 나쁜 정보 확산을 막습니다.

여행 예약 예시: 에이전트가 작은 지역 공항에서 먼 국제도시로 가는 직항편이 존재하지 않는 환각적 정보를 저장합니다. 이후 예약을 요청할 때 계속 불가능한 노선을 찾으려 하여 중복 오류가 발생합니다.

해결책: 비행편 세부 정보를 작업 컨텍스트에 추가하기 전 반드시 실제 API로 비행편 존재 및 노선을 검증하는 단계를 구현하세요. 실패 시 잘못된 정보는 “격리”되어 이후 사용되지 않습니다.

컨텍스트 산만(Context Distraction)

무엇인가: 컨텍스트가 너무 커져 모델이 학습한 내용보다는 누적 히스토리에 너무 집중해 반복적이거나 도움이 되지 않는 행동을 하는 현상입니다. 컨텍스트 창이 꽉 차기 전에 이런 오류가 시작될 수 있습니다.

대처법: 컨텍스트 요약을 사용하세요. 축적된 정보를 주기적으로 압축해 짧은 요약으로 만들어 중복된 히스토리를 제거하며 중요한 세부를 유지해 집중을 리셋합니다.

여행 예약 예시: 여러 달에 걸쳐 다양한 꿈의 여행지를 논의하고 2년 전 백팩킹 여행에 관한 자세한 이야기도 나눈 후, “다음 달 저렴한 항공편 찾아줘“라 요청 시, 에이전트가 오래되고 관련 없는 백팩킹 장비나 과거 일정에 집착하며 현재 요청 처리를 무시합니다.

해결책: 일정 턴수 경과나 컨텍스트 과도한 증가 시, 에이전트는 최근 중요하고 관련 있는 대화 부분 — 현재 여행 날짜와 목적지 중심 — 을 요약하고, 덜 관련한 이전 내용은 버려 다음 LLM 호출에 압축 요약만 사용해야 합니다.

컨텍스트 혼동(Context Confusion)

무엇인가: 필요 없는 컨텍스트, 특히 너무 많은 도구가 있어 모델이 엉뚱한 응답을 하거나 관련 없는 도구를 호출하는 현상입니다. 작은 모델에서 더욱 빈번합니다.

대처법: RAG 기법을 활용한 도구 로드아웃 관리(tool loadout management)를 도입하세요. 도구 설명을 벡터 데이터베이스에 저장하고 특정 작업에 가장 관련성 높은 도구만 선택합니다. 연구 결과 도구 선택 수를 30개 이하로 제한하는 것이 좋습니다.

여행 예약 예시: 에이전트가 book_flight, book_hotel, rent_car, find_tours, currency_converter, weather_forecast, restaurant_reservations 등 수십 가지 도구에 접근할 수 있습니다. “파리에서 이동하는 최선의 방법은?” 이라는 질문에 도구가 너무 많아 book_flight를 파리 내부에서 호출하거나 rent_car를 호출하려 하는 등 혼란이 발생해 선호 대중교통도 무시됩니다.

해결책: 도구 설명에 대해 RAG 시스템을 활용해, 파리 이동 관련 질문 시 rent_car 또는 public_transport_info만 동적으로 검색하여 LLM에 집중된 도구 “로드아웃”을 제시합니다.

컨텍스트 충돌(Context Clash)

무엇인가: 컨텍스트 내 상충되는 정보가 존재하여 일관성 없는 추론이나 나쁜 최종 응답이 나오는 현상입니다. 이는 정보가 단계적으로 들어올 때 초기의 잘못된 가정이 남아 있을 때 주로 발생합니다.

대처법: 컨텍스트 가지치기(pruning) 및 오프로드(offloading)를 사용하세요. 가지치기는 새 정보가 들어올 때 오래되거나 상충하는 정보를 제거하는 것이고, 오프로드는 모델에 별도의 “스크래치패드” 작업 공간을 제공해 정보 처리를 메인 컨텍스트에 혼란 없이 진행하게 하는 것입니다.

여행 예약 예시: 처음에 상담사에게 “이코노미 클래스 비행기를 예약하고 싶어요.”라고 말합니다. 대화 도중 마음이 바뀌어 “사실 이번 여행은 비즈니스 클래스로 갑시다.”라고 말합니다. 두 지시가 모두 문맥에 남아 있으면 상담사는 상충되는 검색 결과를 받거나 어떤 선호도를 우선해야 할지 혼란스러울 수 있습니다.

해결책: 문맥 가지치기(context pruning)를 구현하세요. 새 지시가 이전 지시와 상충될 경우, 이전 지시는 제거되거나 문맥에서 명시적으로 덮어써집니다. 또는 상담사가 스크래치패드를 사용해 상충하는 선호도를 조율한 후 결정하여, 최종적이고 일관된 지침만이 행동을 안내하도록 할 수 있습니다.

문맥 엔지니어링에 대해 더 궁금하신가요?

다른 학습자들과 만나거나, 오피스 아워에 참석하고 AI 상담사 관련 질문에 답변받으려면 Microsoft Foundry Discord에 참여하세요.

이전 강의

Agentic Protocols

다음 강의

Memory for AI Agents

면책 조항: 이 문서는 AI 번역 서비스 Co-op Translator를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역은 오류나 부정확한 부분이 있을 수 있음을 유의하시기 바랍니다. 원본 문서의 원어본이 권위 있는 자료로 간주되어야 합니다. 중요한 정보의 경우, 전문가의 인간 번역을 권장합니다. 이 번역 사용으로 인해 발생하는 오해나 잘못된 해석에 대해 당사는 책임을 지지 않습니다.

This site is open source. Improve this page.