Compress 길어진 맥락을 압축하기

길게 일하는 AI는 자주 비슷한 문제를 만납니다. 처음에는 똑똑하게 잘 따라오다가, 대화가 길어지고 문서가 쌓이고 로그가 불어나면 점점 핵심을 놓치기 시작합니다. 중요한 제약은 뒤로 밀리고, 이미 결정한 사항을 다시 묻고, 원인과 증상을 섞어 버립니다. 많은 사람이 이때 더 긴 컨텍스트를 먼저 떠올리지만, 실무에서는 다른 질문이 더 중요합니다. 이 많은 맥락을 어떻게 줄이되, 중요한 것은 잃지 않을까라는 질문입니다.

앞 장의 Select가 지금 필요한 정보를 고르는 기술이었다면, Compress는 골라 온 정보를 짧고 강하게 다시 정리하는 기술입니다. Select가 장바구니에 무엇을 담을지 결정하는 일이라면, Compress는 그 장바구니 안을 다시 정돈해 정말 중요한 것만 앞으로 보이게 만드는 일에 가깝습니다.

요약은 흔히 편의 기능처럼 취급됩니다. 읽기 쉽게 줄여 주는 서비스 정도로 생각하기 쉽습니다. 하지만 컨텍스트 엔지니어링에서는 전혀 다릅니다. 요약이 잘되면 긴 작업이 이어지고, 요약이 망가지면 전체 시스템이 틀어집니다. 그래서 Compress는 문장을 예쁘게 줄이는 기술이 아니라, 작업의 핵심 상태를 보존하는 설계 기술입니다.

압축이 필요한 진짜 이유

AI 시스템에서 길어지는 것은 단지 대화만이 아닙니다. 회의 기록이 쌓이고, 문서 초안이 여러 버전으로 늘어나고, 디버깅 로그가 끝없이 이어집니다. 이 모든 것을 원문 그대로 계속 넣으면 세 가지 문제가 생깁니다.

• 중요한 정보가 덜 중요한 설명 속에 묻힙니다.

• 비용과 지연 시간이 커집니다.

• 모델이 전체를 다 읽는 듯 보여도 실제로는 핵심 연결을 놓치기 쉽습니다.

사람도 마찬가지입니다. 회의록 50페이지를 그대로 다시 읽는 것보다, 결정 사항 5줄과 미해결 이슈 3개를 먼저 보는 편이 훨씬 낫습니다. 문제는 AI가 그 요약을 자동으로 믿고 다음 작업을 이어 간다는 점입니다. 그래서 사람용 요약보다 AI용 요약은 더 엄격해야 합니다. 읽기 쉬운 것만으로는 부족하고, 다음 판단에 필요한 제약을 빠뜨리지 않아야 합니다.

압축은 줄이는 일이 아니라 보존하는 일이다

많은 사람이 요약을 짧게 만드는 일로 생각합니다. 하지만 실무에서는 길이보다 더 중요한 기준이 있습니다. 바로 무엇을 반드시 남겨야 하는가입니다.

좋은 압축은 원문의 모든 문장을 살리지 못해도, 다음 작업의 품질을 바꾸는 정보는 남깁니다. 예를 들어 제품 정책 문서를 요약할 때는 배경 설명이 조금 줄어들어도 괜찮을 수 있습니다. 하지만 시행일, 예외 조건, 적용 대상, 금지 사항이 빠지면 요약은 짧아진 것이 아니라 망가진 것입니다.

이 감각이 중요합니다. 압축은 종종 정보 삭제처럼 보이지만, 실제 목적은 삭제가 아니라 핵심 구조의 보존입니다. 원문을 납작하게 줄이는 것이 아니라, 다음 단계에서 꼭 필요한 뼈대를 다시 세우는 일입니다.

손실 압축과 무손실 압축

컨텍스트 압축을 이해할 때 가장 유용한 구분은 손실 압축과 무손실 압축입니다.

손실 압축은 일부 정보를 버리는 대신 짧고 빠르게 만드는 방식입니다. 대화 요약, 긴 보고서의 핵심 정리, 로그 묶음의 대표 에러 추출이 여기에 가깝습니다. 모든 세부를 남기지는 않지만, 의사결정에 필요한 핵심은 남겨야 합니다.

무손실 압축은 의미상 중요한 항목을 빠뜨리지 않고 구조를 바꾸어 더 다루기 쉽게 만드는 방식입니다. 예를 들어 장문의 회의록을 읽고 결정 사항, 담당자, 기한, 미해결 이슈, 참고 링크로 구조화하는 일은 길이는 줄어들 수 있어도 핵심 필드는 보존하려는 시도입니다. 로그에서도 전체 문장을 그대로 두는 대신 에러 코드, 발생 시각, 서비스명, 재현 단계, 스택 트레이스 위치처럼 필요한 필드를 정확히 추출해 정리하면 무손실에 가까운 압축이 됩니다.

쉽게 말해 손실 압축은 풍경화를 스케치로 바꾸는 일이고, 무손실 압축은 짐을 다시 접어 넣는 일입니다. 둘 다 필요하지만, 언제 무엇을 써야 하는지는 다릅니다.

무엇을 절대 잃으면 안 될까

압축이 어려운 이유는 문장을 줄이는 기술보다, 잃어서는 안 될 정보를 구분하는 기술이 더 중요하기 때문입니다. 실무에서 특히 보존해야 하는 항목은 대체로 비슷합니다.

• 현재 목표와 성공 조건

• 이미 결정된 사항과 변경 불가 제약

• 아직 풀리지 않은 질문과 위험 요소

• 사람, 도구, 문서 사이의 역할 관계

• 다음 행동과 책임 주체

이 다섯 가지는 긴 작업에서 특히 자주 사라집니다. 대화가 길어질수록 목표는 흐려지고, 이미 정한 규칙은 뒤로 밀리며, 미해결 항목은 종종 해결된 것처럼 착각됩니다. 그래서 요약을 만들 때는 아름다운 문장보다 먼저 목표, 제약, 상태, 다음 행동이 살아 있는지 확인해야 합니다.

좋은 요약은 읽었을 때 그럴듯한 느낌을 주는 문서가 아닙니다. 다음 단계의 AI가 이것을 보고도 같은 방향으로 일할 수 있게 만드는 작업 메모입니다.

Select와 Compress는 어떻게 다를까

둘은 비슷해 보이지만 역할이 다릅니다. Select는 바깥에 있는 많은 정보 중에서 지금 필요한 것을 고르는 일입니다. Compress는 그렇게 골라 온 정보가 여전히 길거나 복잡할 때, 그 안에서 핵심 구조를 남기고 다시 줄이는 일입니다.

예를 들어 고객지원 시스템이 최신 환불 정책 문서와 최근 상담 기록을 선택해 왔다고 해 봅시다. 여기까지는 Select입니다. 그런데 그 문서가 30페이지이고 상담 기록이 200줄이라면, 그대로 다음 답변 단계에 넣기 어렵습니다. 이때 환불 가능 기간, 예외 조항, 고객 등급 조건, 이전 상담에서 이미 확인된 사실만 짧게 재구성하는 것이 Compress입니다.

한마디로 정리하면 이렇습니다. Select는 무엇을 데려올지 정하고, Compress는 데려온 것을 어떻게 들고 다닐지 정합니다.

대화를 압축하는 법

대화는 압축이 가장 자주 필요하면서도 가장 쉽게 망가지는 영역입니다. 이유는 간단합니다. 대화에는 사실, 감정, 요청, 결정, 맥락 전환이 한데 섞여 있기 때문입니다. 그래서 단순히 앞부분을 짧게 요약하면 중요한 합의가 빠지거나, 아직 논의 중인 내용을 확정된 사실처럼 기록하기 쉽습니다.

대화 요약에서는 보통 다음 순서가 안정적입니다.

먼저 사용자의 목표를 한 줄로 잡습니다. 지금 무엇을 하려는 대화인지가 첫 줄에 보여야 합니다. 그다음 이미 확정된 결정 사항을 따로 적습니다. 이후 아직 확정되지 않은 쟁점과 미해결 질문을 분리합니다. 마지막으로 다음 턴에서 필요한 행동이나 입력값을 남깁니다.

예를 들어 문서 작성 에이전트라면 이런 식의 압축이 좋습니다.

• 목표: 컨텍스트 엔지니어링 입문서 3장 초안 작성

• 확정 사항: 독자는 실무자, 톤은 쉬운 설명 중심, 분량은 3천 자 안팎

• 미해결 사항: 사례를 국내 기업 중심으로 할지 일반 사례로 할지 결정 필요

• 다음 행동: 3장 구조 제안 후 사용자 승인 받기

이런 구조는 짧지만 강합니다. 단순 줄거리 요약보다 다음 작업에 훨씬 직접적으로 도움이 됩니다.

대화 압축에서 특히 주의할 점은 사람의 선호와 일회성 요청을 구분하는 일입니다. 이번 답변에서만 필요한 조건을 장기 규칙처럼 남기면 이후 대화가 이상해집니다. 반대로 반복되는 선호를 매번 잊으면 불필요한 마찰이 생깁니다. 그래서 대화 압축은 기억 설계와 닿아 있지만, 이번 장의 핵심은 저장 자체보다 현재 작업을 이어 가기 위한 요약의 품질에 있습니다.

문서를 압축하는 법

문서 압축은 읽기 편한 줄거리 만들기와 다릅니다. 특히 정책 문서, 계약서, 제품 명세서, 기술 가이드는 핵심 제약을 놓치지 않는 것이 가장 중요합니다.

문서 요약을 할 때 흔한 실수는 배경 설명을 예쁘게 정리하면서 실제로 중요한 조건문을 흘려보내는 것입니다. 예를 들어 제품 사용 정책 문서에서 브랜드 철학은 멋지게 남아 있는데, 정작 금지된 사용 사례와 예외 승인 절차가 빠져 있다면 실무에서는 거의 쓸모가 없습니다.

문서 압축은 문서 종류에 따라 방식이 달라져야 합니다. 설명형 문서는 핵심 주장과 근거를 남기는 편이 좋고, 규정형 문서는 적용 대상과 예외 조항이 중심이 되어야 하며, 절차형 문서는 단계와 조건 분기가 잘 보이도록 정리해야 합니다.

실전에서는 문서 요약을 자유 서술로만 두지 말고, 정해진 틀로 뽑는 편이 훨씬 안전합니다. 예를 들면 이런 틀이 유용합니다.

• 문서 목적

• 적용 대상

• 반드시 지켜야 할 규칙

• 예외 조건

• 시행일 또는 버전

• 지금 질문과 직접 관련된 조항

이 형식의 장점은 간단합니다. 요약이 조금 서툴러도 중요한 칸이 비어 있으면 바로 문제를 발견할 수 있습니다. 자유로운 요약문은 그럴듯하게 읽히지만, 정작 빠진 정보가 눈에 잘 띄지 않습니다.

로그를 압축하는 법

로그 압축은 특히 개발과 운영에서 중요합니다. 원시 로그는 길고 시끄럽습니다. 정보가 많은 것 같지만, 실제로는 같은 실패 메시지가 수백 번 반복되기도 하고, 핵심 원인보다 주변 잡음이 더 크게 보이기도 합니다.

좋은 로그 압축은 로그를 문학 작품처럼 요약하지 않습니다. 대신 문제 해결에 필요한 좌표를 남깁니다. 예를 들어 다음 같은 항목이 중요합니다.

• 언제부터 문제가 시작되었는가

• 어떤 서비스나 모듈에서 발생했는가

• 대표 에러 메시지와 코드가 무엇인가

• 재현 조건이 있는가

• 직전 변경 사항이나 배포와 연결되는가

이런 구조로 바꾸면 수천 줄 로그도 몇 줄의 작업 메모로 바뀝니다. 다만 여기서 아주 중요한 원칙이 있습니다. 로그 압축은 원본을 대체하면 안 됩니다. 요약은 원인을 찾기 위한 안내판이어야지, 증거 자체가 되어서는 안 됩니다. 필요할 때 원문으로 다시 내려갈 수 있어야 합니다.

실무에서 가장 위험한 패턴은 에러 로그를 감정적인 이야기로 요약하는 것입니다. 예를 들어 서버가 이상해졌고 인증이 꼬인 것 같다는 식의 표현은 읽기에는 편하지만, 실제로는 아무 정보도 남기지 않습니다. 로그 압축은 느낌이 아니라 관측 가능한 사실을 남겨야 합니다.

좋은 압축은 형식이 있다

요약이 자주 망가는 이유 중 하나는 매번 다른 방식으로 쓰기 때문입니다. 어떤 때는 줄거리처럼 쓰고, 어떤 때는 의견까지 섞고, 어떤 때는 중요한 숫자를 빼먹습니다. 그래서 압축은 자유로운 문장 실력에 맡기기보다, 가능한 한 고정된 형식을 두는 편이 좋습니다.

예를 들어 긴 작업을 위한 작업 요약이라면 다음 네 칸만 있어도 품질이 크게 좋아집니다.

• 목표: 지금 무엇을 만들거나 해결하려는가

• 제약: 반드시 지켜야 할 조건은 무엇인가

• 현재 상태: 무엇이 끝났고 무엇이 남았는가

• 다음 행동: 바로 이어서 해야 할 일은 무엇인가

회의 요약이라면 결정 사항과 미결 사항을 분리하고, 로그 요약이라면 증상과 추정 원인을 분리하는 식으로 설계할 수 있습니다. 형식이 있으면 요약 자체가 검토 가능해집니다. 압축의 품질은 종종 문장 미감보다 누락을 발견하기 쉬운 구조에서 나옵니다.

단계별 압축이 필요하다

긴 작업에서는 한 번의 거대한 요약보다, 여러 번의 작은 압축이 더 안전합니다. 처음부터 모든 것을 한 장짜리 요약으로 만들면 중요한 연결이 쉽게 사라집니다. 반면 중간중간 압축하면 정보가 완전히 부패하기 전에 핵심을 붙잡을 수 있습니다.

예를 들어 긴 대화가 있다면 매 턴마다 요약하지 말고, 의미 있는 단위가 끝날 때마다 작은 요약을 만드는 편이 좋습니다. 문서 작업이라면 초안 단계, 피드백 단계, 수정 단계마다 상태 요약을 남길 수 있습니다. 로그 분석도 마찬가지입니다. 전체 로그를 한 번에 줄이기보다 시간대별, 서비스별, 에러 유형별로 먼저 압축한 다음 최종 요약으로 합치는 편이 더 정확합니다.

이 방식을 쓰면 장점이 큽니다. 앞단의 작은 요약이 뒤 단계의 재료가 되므로, 나중에 문제가 생겼을 때 어느 단계에서 정보가 사라졌는지 추적하기 쉬워집니다.

압축이 망가지는 전형적인 패턴

요약 실패는 늘 비슷한 얼굴로 나타납니다.

첫째, 중요한 결정을 배경 설명 속에 묻어 버리는 경우입니다. 읽으면 자연스럽지만, 다음 단계에서 결정을 찾기 어렵습니다.

둘째, 미해결 사항을 해결된 것처럼 적는 경우입니다. 대화에서는 특히 자주 생깁니다. 논의 중이던 아이디어가 마치 합의된 정책처럼 요약되면 이후 작업이 엉뚱한 방향으로 달립니다.

셋째, 숫자와 조건문을 떨어뜨리는 경우입니다. 기한, 버전, 금액, 예외 조건은 짧은 문장 안에서도 쉽게 사라집니다. 하지만 실무에서는 바로 이런 정보가 정답을 갈라놓습니다.

넷째, 요약 속에 추측을 끼워 넣는 경우입니다. 로그 압축에서 특히 위험합니다. 관측된 사실과 모델의 해석을 섞어 쓰면, 나중에 그 해석이 사실처럼 재사용됩니다.

다섯째, 요약만 남기고 원문과의 연결을 끊는 경우입니다. 좋은 압축은 원문으로 돌아갈 길을 남깁니다. 문서 출처, 메시지 범위, 로그 시간대 같은 연결 고리가 없으면 나중에 검증이 어려워집니다.

압축 품질을 높이는 실전 원칙

압축은 감각의 영역처럼 보이지만, 몇 가지 원칙을 지키면 훨씬 안정됩니다.

• 요약은 이야기보다 상태를 남겨야 합니다.

• 결정 사항과 미결 사항을 반드시 분리합니다.

• 숫자, 날짜, 버전, 금지 조건은 별도 항목으로 뽑습니다.

• 해석과 사실을 섞지 않습니다.

• 필요하면 언제든 원문으로 돌아갈 수 있게 연결점을 남깁니다.

여기에 한 가지를 더 붙이면 좋습니다. 요약의 독자를 먼저 정하라는 원칙입니다. 사람에게 보여 줄 요약과 다음 단계 AI에게 넘길 요약은 다를 수 있습니다. 사람용 요약은 읽기 쉬움이 중요하지만, AI용 요약은 누락 없는 구조가 더 중요합니다. 둘을 같은 형식으로 만들면 종종 둘 다 애매해집니다.

작은 예제로 보는 Compress

사용자가 한 시간 동안 고객지원 챗봇 개선 회의를 했다고 가정해 봅시다. 원문 대화에는 아이디어, 농담, 우려, 정책 확인 요청, 일정 논의가 뒤섞여 있습니다. 이걸 단순히 회의 내용 요약으로 줄이면 읽기는 쉬울 수 있습니다. 하지만 다음 작업을 맡은 AI에게는 부족할 가능성이 큽니다.

더 좋은 압축은 이렇게 생겼습니다.

• 목표: 환불 관련 문의에 대해 더 정확한 고객지원 챗봇 설계

• 확정 사항: 최신 정책 문서만 사용, 답변 불가 시 사람 상담으로 이관, 환불 가능 기간은 답변에 항상 명시

• 미해결 사항: 기업 고객과 일반 고객 정책을 하나의 플로우로 합칠지 결정 필요

• 위험 요소: 오래된 FAQ가 최신 정책과 충돌 가능

• 다음 행동: 정책 문서 버전 체계 정리 후 챗봇 답변 템플릿 수정

이 요약은 원문보다 훨씬 짧지만, 다음 단계에서 해야 할 일을 선명하게 보여 줍니다. 바로 이것이 좋은 압축입니다. 짧아서 좋은 것이 아니라, 짧아졌는데도 다음 판단이 더 정확해지는 것이 중요합니다.

요약은 편의 기능이 아니라 시스템 품질이다

압축을 잘못 설계하면 AI는 점점 자기가 만든 나쁜 요약 위에서 다시 추론하게 됩니다. 그러면 처음의 작은 누락이 나중에는 큰 오류가 됩니다. 반대로 압축을 잘 설계하면 긴 프로젝트도 중심을 잃지 않고 이어 갈 수 있습니다.

그래서 Compress는 단순한 후처리 단계가 아닙니다. 대화 메모, 문서 요약, 로그 정리, 중간 상태 기록을 어떻게 만들지 정하는 핵심 설계입니다. 이 장의 핵심은 하나입니다. 요약은 내용을 덜어 내는 작업이 아니라, 다음 작업이 망가지지 않게 핵심 제약을 보존하는 작업이라는 점입니다.

Write가 흔적을 남기는 기술이었다면, Select는 필요한 것을 데려오는 기술이었고, Compress는 그 흔적과 정보들을 다시 쓸 수 있는 형태로 정제하는 기술입니다. 긴 맥락을 다루는 시스템일수록 이 기술의 차이가 결과를 갈라놓습니다.

잘 압축된 컨텍스트는 AI를 더 많이 아는 존재로 만들지는 않습니다. 대신 덜 헷갈리게 만들고, 더 오래 일하게 만들고, 같은 실수를 반복하지 않게 만듭니다. 그리고 실무에서는 그 차이가 생각보다 아주 큽니다.