네 가지 핵심 전략: Write, Select, Compress, Isolate

컨텍스트 문제는 네 가지 결정으로 줄어든다

컨텍스트 엔지니어링은 복잡해 보이지만, 실제 문제는 대개 네 가지 질문으로 돌아온다.

무엇을 밖에 써둘 것인가. 무엇을 다시 가져올 것인가. 무엇을 줄일 것인가. 무엇을 분리할 것인가.

이 네 가지 질문이 각각 Write, Select, Compress, Isolate 전략이다. 이름은 단순하지만, 현대 AI 시스템의 많은 설계가 이 안에서 움직인다. 대화 기록 관리, RAG, 에이전트 메모리, 도구 호출, 멀티 에이전트 구조, 권한 제어도 결국 이 네 전략의 조합이다.

LLM의 컨텍스트 윈도우는 넓어지고 있다. 그러나 넓어진 창이 곧 좋은 답변을 보장하지는 않는다. 창이 커질수록 불필요한 정보도 함께 들어가기 쉽고, 오래된 지시와 최신 지시가 충돌하며, 관련 없는 문서가 모델의 주의를 빼앗는다. 그래서 중요한 것은 더 많이 넣는 능력이 아니라, 무엇을 어디에 둘지 결정하는 능력이다.

네 전략은 다음처럼 구분할 수 있다.

이 네 가지를 따로 외울 필요는 없다. 한 문장으로 기억하면 된다. 좋은 시스템은 기억할 것은 밖에 쓰고, 필요한 것은 골라 가져오며, 긴 것은 줄이고, 섞이면 위험한 것은 분리한다.

Write: 컨텍스트 밖에 써두기

Write 전략은 정보를 모델의 현재 입력 안에 계속 붙잡아두지 않고, 외부 저장소에 기록하는 방식이다. 여기서 저장소는 꼭 거창한 데이터베이스일 필요가 없다. 스크래치패드, 상태 객체, 임시 파일, 캐시, 이벤트 로그, 업무 데이터베이스, 사용자 프로필, 작업 큐 모두 Write의 대상이 될 수 있다.

핵심 목적은 컨텍스트 윈도우를 비우는 것이다. 모델이 모든 것을 매번 읽게 만들면 비용이 늘고 판단도 흐려진다. 반대로 중요한 중간 결과를 외부에 적어두면, 다음 단계에서는 필요한 요약이나 참조만 다시 넣으면 된다.

예를 들어 에이전트가 시장 조사 보고서를 작성한다고 하자. 검색 결과, 후보 자료, 제외한 자료, 중간 판단, 사용자 요구사항, 최종 목차가 모두 대화창에 남아 있으면 금방 복잡해진다. 이때 시스템은 다음 정보를 외부에 써둘 수 있다.

• 사용자 요구사항: 상태 객체에 저장

• 검색한 문서 목록: 데이터베이스나 파일에 저장

• 각 문서의 핵심 요약: 별도 메모리에 저장

• 이미 검토한 자료와 제외 사유: 이벤트 로그에 저장

• 최종 보고서 초안: 작업 파일에 저장

이렇게 하면 모델은 매 단계마다 전체 이력을 읽지 않아도 된다. 대신 현재 단계에 필요한 상태만 읽는다.

Write 전략에서 중요한 것은 아무거나 저장하지 않는 것이다. 저장은 미래의 Select를 전제로 해야 한다. 나중에 다시 찾을 수 없는 기록은 컨텍스트 설계상 거의 의미가 없다. 따라서 기록에는 최소한의 메타데이터가 붙어야 한다. 언제 생성됐는지, 어떤 사용자와 작업에 속하는지, 원본 출처는 무엇인지, 신뢰도는 어느 정도인지, 접근 권한은 누구에게 있는지 같은 정보다.

Write는 단순한 기억 장치가 아니라 시스템의 장기 상태를 만드는 행위다. 잘못된 정보를 저장하면 이후 단계에서 반복적으로 재사용된다. 그래서 저장 전 검증, 만료 정책, 수정 이력도 함께 설계해야 한다. 특히 사용자 선호나 업무 규칙처럼 오래 유지되는 정보는 더 신중해야 한다. 한 번의 대화에서 나온 임시 취향을 영구 프로필로 저장하면, 이후 모든 응답이 그 잘못된 기억에 끌려갈 수 있다.

Select: 필요한 순간에 골라 가져오기

Select 전략은 외부에 있는 많은 정보 중 지금 필요한 것만 컨텍스트로 가져오는 방식이다. Write가 정보를 밖으로 내보내는 전략이라면, Select는 그중 무엇을 다시 안으로 들일지 결정하는 전략이다.

가장 익숙한 형태는 검색이다. 벡터 검색은 문장의 의미가 비슷한 자료를 찾는 데 강하다. 키워드 검색은 정확한 용어, 제품명, 법 조항, 오류 코드처럼 문자 일치가 중요한 경우에 유용하다. 메타데이터 필터는 검색 범위를 줄인다. 예를 들어 특정 고객사, 특정 날짜 이후, 승인된 문서, 사용자가 접근 가능한 문서만 대상으로 삼을 수 있다. 재순위화는 1차 검색 결과를 다시 평가해 더 적절한 순서로 정렬하는 과정이다.

좋은 Select는 검색 알고리즘 하나로 끝나지 않는다. 보통 여러 단계를 거친다.

1. 사용자의 요청에서 의도와 제약을 파악한다.

2. 검색 범위를 메타데이터로 먼저 좁힌다.

3. 키워드 검색과 벡터 검색을 함께 사용한다.

4. 후보 문서를 재순위화한다.

5. 최종 컨텍스트에 넣을 조각을 선택한다.

6. 출처, 날짜, 권한 정보를 함께 전달한다.

여기서 중요한 점은 관련성이 항상 충분조건은 아니라는 것이다. 어떤 문서가 질문과 의미상 비슷하더라도 오래되었거나, 권한이 없거나, 초안 상태이거나, 다른 부서의 정책일 수 있다. 이런 자료가 들어오면 모델은 그럴듯하지만 틀린 답을 만들 수 있다. 따라서 Select는 관련성뿐 아니라 최신성, 신뢰도, 권한, 업무 범위를 함께 판단해야 한다.

Select의 실패는 두 방향으로 나타난다. 하나는 필요한 정보를 못 가져오는 것이다. 이 경우 모델은 일반 지식으로 빈칸을 채우려 하고, 환각 가능성이 높아진다. 다른 하나는 너무 많이 가져오는 것이다. 이 경우 정답 근처의 자료가 있어도 잡음에 묻힌다. 실무에서는 후자가 더 자주 문제가 된다. 검색 결과를 넉넉히 넣으면 안전할 것 같지만, 실제로는 모델에게 불필요한 판단 부담을 준다.

따라서 Select는 항상 평가되어야 한다. 좋은 검색 시스템은 최종 답변만 보는 것이 아니라, 어떤 문서가 후보로 뽑혔는지, 어떤 문서가 탈락했는지, 왜 특정 문서가 위에 왔는지를 추적할 수 있어야 한다. 컨텍스트 엔지니어링에서 검색 로그는 디버깅의 핵심 자료다.

Compress: 의미는 남기고 토큰은 줄이기

Compress 전략은 긴 정보를 짧게 만드는 방식이다. 오래된 대화, 긴 문서, 도구 출력, 코드 실행 결과, 중간 추론, 검색 결과 묶음은 그대로 넣기 어렵다. 그렇다고 모두 버리면 중요한 맥락이 사라진다. 이때 필요한 것이 압축이다.

압축은 단순 요약과 다르다. 요약은 읽기 쉽게 줄이는 데 초점이 있지만, 컨텍스트 압축은 다음 작업에 필요한 정보를 보존하는 데 초점이 있다. 예를 들어 회의록을 요약할 때 일반 요약은 논의 흐름을 정리한다. 하지만 다음 단계가 계약서 작성이라면 결정된 조건, 책임 주체, 날짜, 예외 조항, 미해결 쟁점이 더 중요하다. 다음 단계가 개발 작업이라면 API 변경점, 담당자, 마감일, 의존성이 더 중요하다.

즉, 좋은 압축은 목적 의존적이다. 무엇을 하려는지에 따라 남겨야 할 정보가 달라진다.

Compress에는 몇 가지 방식이 있다.

• 요약: 긴 내용을 짧은 문단으로 줄인다.

• 추출: 날짜, 숫자, 이름, 결정사항처럼 필요한 항목만 뽑는다.

• 구조화: 자유로운 텍스트를 표, JSON, 체크리스트 같은 형식으로 바꾼다.

• 병합: 여러 문서의 중복 내용을 합치고 충돌 지점을 표시한다.

• 계층화: 전체 요약, 섹션 요약, 원문 링크를 단계적으로 둔다.

실무에서는 구조화 압축이 특히 중요하다. 자연어 요약은 읽기 편하지만, 시스템이 다시 사용하기에는 모호할 수 있다. 반면 상태 객체나 체크리스트 형태로 압축하면 이후 단계에서 선택하고 검증하기 쉽다. 예를 들어 고객 지원 대화가 길어졌다면 다음처럼 압축할 수 있다.

• 고객: A사 관리자

• 문제: 결제 후 영수증 PDF가 생성되지 않음

• 환경: 크롬, 기업 계정, 2026년 5월 18일 발생

• 이미 시도한 조치: 로그아웃, 브라우저 캐시 삭제

• 남은 작업: 결제 로그 확인, PDF 생성 큐 상태 확인

이 압축은 짧지만 다음 응답에 필요한 맥락을 충분히 담고 있다.

압축에서 가장 조심해야 할 문제는 손실이다. 줄이는 과정에서 예외 조건, 숫자, 부정 표현이 사라지면 큰 오류가 생긴다. 특히 아니다, 제외한다, 이전 버전만 해당한다 같은 표현은 반드시 보존해야 한다. 압축 결과만 믿지 말고 원문으로 돌아갈 수 있는 링크나 식별자를 남겨야 하는 이유도 여기에 있다.

또 하나의 원칙은 중간 추론을 무조건 보존하지 않는 것이다. 모델이 작업 중 만든 생각의 흔적을 모두 저장하면 컨텍스트가 빠르게 오염된다. 필요한 것은 최종 판단, 근거, 미해결 쟁점, 다음 행동이다. 과도한 내부 추론 기록은 비용을 늘리고, 나중에 잘못된 가정을 사실처럼 재사용하게 만들 수 있다.

Isolate: 섞이면 위험한 것을 분리하기

Isolate 전략은 서로 다른 작업, 사용자, 권한, 도구, 추론 공간을 분리하는 방식이다. 컨텍스트 문제는 부족해서만 생기지 않는다. 섞여서 생기기도 한다.

예를 들어 한 에이전트가 고객 A의 민감한 데이터를 처리한 뒤, 같은 세션에서 고객 B의 요청을 처리한다고 하자. 격리가 제대로 되어 있지 않으면 고객 A의 정보가 고객 B의 답변에 섞일 위험이 있다. 또는 개발 도구를 사용할 수 있는 에이전트와 외부 이메일을 보낼 수 있는 에이전트가 같은 맥락을 공유하면, 검증되지 않은 내용이 곧바로 외부로 전송될 수 있다.

Isolate는 이런 위험을 줄이기 위해 경계를 만든다. 대표적인 방법은 다음과 같다.

• 작업별 네임스페이스를 분리한다.

• 사용자별 메모리와 조직별 메모리를 나눈다.

• 읽기 권한과 쓰기 권한을 다르게 둔다.

• 도구 실행을 샌드박스에서 수행한다.

• 서브에이전트별로 필요한 컨텍스트만 제공한다.

• 민감 정보는 별도 저장소에 두고 필요할 때만 제한적으로 주입한다.

여기서 네임스페이스란 정보가 속한 공간을 뜻한다. 같은 단어의 메모리라도 어느 사용자, 어느 프로젝트, 어느 조직, 어느 작업에 속하는지 분리해 관리하는 것이다. 샌드박스는 실행 환경을 격리해, 실험이나 도구 실행이 실제 시스템에 영향을 주지 않도록 만든 공간이다.

멀티 에이전트 구조에서는 Isolate가 더욱 중요하다. 여러 에이전트가 같은 목표를 향해 협업할 때 모든 정보를 공유하면 효율적일 것 같지만, 실제로는 역할이 흐려진다. 리서치 에이전트는 자료를 찾고, 분석 에이전트는 근거를 비교하고, 작성 에이전트는 결과물을 만들고, 검토 에이전트는 오류를 찾는 식으로 역할을 나누면 각 에이전트에 필요한 컨텍스트도 달라진다.

격리는 보안을 위해서만 필요한 것이 아니다. 품질을 위해서도 필요하다. 작성 에이전트에게 모든 원문과 모든 반론을 한꺼번에 넣으면 문장이 흔들릴 수 있다. 반대로 검토 에이전트에게는 초안과 기준표, 원문 근거가 필요하다. 같은 작업이라도 역할에 따라 컨텍스트는 달라져야 한다.

Isolate의 핵심은 최소 공유다. 모두가 모든 것을 보는 구조보다, 필요한 주체가 필요한 정보만 보는 구조가 안전하고 안정적이다.

네 전략은 함께 작동한다

현실의 시스템에서 Write, Select, Compress, Isolate는 따로 움직이지 않는다. 하나의 요청을 처리하는 동안 계속 연결된다.

예를 들어 기업 내부 문서 기반 질의응답 시스템을 생각해보자. 먼저 문서를 수집해 저장한다. 이것이 Write다. 문서에는 작성일, 부서, 권한, 문서 유형 같은 메타데이터가 붙는다. 사용자가 질문하면 접근 가능한 문서 중 관련 있는 것만 검색한다. 이것이 Select다. 검색된 문서가 길면 필요한 단락만 뽑거나 요약한다. 이것이 Compress다. 마지막으로 사용자 권한 밖의 문서, 다른 부서의 비공개 자료, 다른 고객의 데이터는 컨텍스트에 들어오지 못하게 막는다. 이것이 Isolate다.

에이전트 시스템도 마찬가지다. 에이전트는 작업 중간 결과를 파일이나 상태 객체에 쓴다. 다음 행동을 결정할 때 필요한 상태만 선택한다. 오래된 대화와 도구 출력은 압축한다. 위험한 도구 실행은 샌드박스로 분리하고, 서브에이전트마다 다른 컨텍스트를 준다.

이 네 전략을 기준으로 보면 컨텍스트 설계가 훨씬 명확해진다. 문제가 생겼을 때도 진단하기 쉽다.

• 답변이 이전 맥락을 잊는다면 Write가 부족한가?

• 필요한 근거를 못 찾는다면 Select가 약한가?

• 토큰은 많은데 핵심이 흐리다면 Compress가 필요한가?

• 다른 작업의 정보가 섞인다면 Isolate가 깨졌는가?

이 질문들은 컨텍스트 디버깅의 출발점이 된다.

실무에서의 설계 순서

처음부터 복잡한 컨텍스트 플랫폼을 만들 필요는 없다. 실무에서는 다음 순서로 접근하는 편이 안전하다.

첫째, 컨텍스트에 계속 반복해서 들어가는 정보를 찾는다. 반복되는 정보는 Write 후보이다. 사용자 프로필, 프로젝트 설정, 정책 문서, 중간 산출물처럼 자주 재사용되는 정보는 외부화하는 것이 좋다.

둘째, 외부화한 정보에 메타데이터를 붙인다. 메타데이터가 없으면 나중에 Select가 어려워진다. 특히 시간, 소유자, 권한, 출처, 상태는 기본값으로 생각해야 한다.

셋째, 검색과 필터링 규칙을 만든다. 의미 검색만 믿지 말고 키워드, 날짜, 권한, 문서 상태를 함께 고려한다. 중요한 업무일수록 재순위화와 검증 단계를 둔다.

넷째, 긴 입력과 긴 출력의 압축 정책을 정한다. 모든 대화를 같은 방식으로 요약하지 말고, 다음 작업에 필요한 형태로 줄인다. 원문으로 돌아갈 수 있는 식별자도 남긴다.

다섯째, 섞이면 안 되는 경계를 정의한다. 사용자, 조직, 프로젝트, 도구, 에이전트 역할별로 네임스페이스와 권한을 분리한다.

마지막으로, 이 모든 과정을 로그로 남긴다. 어떤 정보가 저장됐고, 어떤 정보가 선택됐으며, 어떤 내용이 압축됐고, 어떤 정보가 격리됐는지 추적할 수 있어야 한다. 추적할 수 없는 컨텍스트 파이프라인은 개선하기 어렵다.

좋은 컨텍스트는 잘 배치된 정보다

컨텍스트 엔지니어링의 목표는 모든 정보를 모델에게 보여주는 것이 아니다. 정보가 있어야 할 자리를 정하는 것이다.

지금 필요한 정보는 컨텍스트 안에 있어야 한다. 나중에 필요할 정보는 외부에 써두어야 한다. 너무 긴 정보는 목적에 맞게 줄여야 한다. 섞이면 위험한 정보는 분리해야 한다.

Write, Select, Compress, Isolate는 이 판단을 돕는 기본 언어다. 앞으로 검색, 메모리, 대화 압축, 도구 사용, 멀티 에이전트, 프로덕션 파이프라인을 다룰 때도 이 네 가지 질문은 계속 반복된다.

저장할 것인가. 가져올 것인가. 줄일 것인가. 분리할 것인가.

이 질문에 명확히 답할수록 AI 시스템은 더 싸고, 더 빠르고, 더 안전하며, 더 정확해진다.