Kiro의 컴팩션에서 살아남을 정보를 결정하는 방법 (2026년 가이드)

Kiro가 설명하는 메커니즘은 간단합니다. 컴팩션은 "세션이 커짐에 따라 이전 대화 기록을 자동으로 요약하여 긴 세션의 생산성을 유지"하며, "목표, 결정 및 기술적 진행 상황은 보존되고 장황한 중간 과정만 압축된다"는 프레임을 취하고 있습니다.

이 과정은 세 단계로 나뉩니다. 먼저 "Kiro가 목표, 결정, 진행 상황 및 다음 단계를 캡처하는 구조화된 요약을 생성"한 다음, "이전 대화 기록은 요약으로 대체되는 반면 가장 최근 메시지는 그대로 유지"되고, 마지막으로 세션이 "중단 없이 중단된 지점부터" 계속됩니다.

이러한 설계는 합리적이며, 선택한 범주도 작업을 계속하는 데 적합합니다. 어떤 파일이 변경되었는지, 어떤 테스트가 통과했는지, 무엇이 남았는지, 제약 조건이 무엇인지 아는 요약본이 있다면 작업을 계속 이어나갈 수 있습니다. Kiro의 실제 예시가 이를 잘 보여줍니다. 45분간의 리팩터링 후 요약본에는 수정된 파일, 통과한 테스트, 남은 두 파일, 그리고 "모든 변경 사항은 하위 호환되어야 한다"는 제약 조건이 유지됩니다.

하지만 여기서 발생하는 공백은 버그가 아니라 범주의 차이에서 기인합니다. 요약은 결론은 효율적으로 보존하지만 논거는 제대로 보존하지 못합니다. "모든 변경 사항은 하위 호환되어야 한다"는 제약 조건으로 살아남습니다. 하지만 여기서 왜 하위 호환성이 타협 불가능했는지(아무도 업데이트할 수 없는 호출자, 이전 버전을 사용하는 클라이언트, 작년에 실패한 마이그레이션 등)를 정립하는 데 걸린 20분은 테이블에서 탐색적 논의 및 중간 추론 단계로 분류되어 압축됩니다.

압축 가능한 열에 있는 두 가지 항목을 더 주목할 필요가 있습니다. "해결된 문제의 오류 세부 정보"는 이미 해결한 실패 사례가 압축됨을 의미합니다. 하지만 해결된 실패 사례는 대개 여러분이 선택한 접근 방식의 가장 강력한 근거가 됩니다. "이전 메시지의 코드 스니펫"은 거부된 구현은 사라지고 채택된 구현만 남는다는 것을 의미하며, 이는 선택을 정당화하는 비교 대상을 제거합니다.

누락된 세부 정보에 대한 Kiro의 해결책은 솔직하면서도 시사하는 바가 큽니다. "에이전트가 세션 이전의 특정 세부 정보를 잃어버린 것 같다면 다시 설명하십시오. 에이전트가 즉시 반영할 것입니다." 이는 실제로 작동합니다. 하지만 이는 보존되는 열에 없는 정보를 유지하는 메커니즘이 결국 사용자가 기억하고 다시 말하는 것뿐임을 의미합니다. 이는 AI에게 컨텍스트를 반복해서 설명하지 않는 방법에서 설명한 루프와 같습니다.

이것은 Kiro에만 국한된 설계가 아닙니다. Amazon Q Developer도 다른 이름으로 동일한 형태를 문서화하고 있습니다. 컴팩션 이후 "Amazon Q는 응답 생성을 위해 전체 기록이 아닌 압축된 요약을 사용"하며, 세션 패널에는 전체 대화가 계속 표시되지만 "IDE를 다시 시작하면 자세한 채팅 기록이 재설정"됩니다. 두 벤더의 독립적인 두 구현이 내린 결론은 같습니다. 대화는 작업 기억(working memory)이지 저장소(storage)가 아니라는 점입니다.

컴팩션 끄기. 대부분의 환경에서 지원되지 않습니다. Kiro의 문서에 따르면 컴팩션은 "IDE에서 자동으로 수행되며 수동 트리거가 없습니다." 웹과 모바일에서도 마찬가지입니다. CLI만 /compact를 노출하지만, 이는 수동 트리거일 뿐 스위치가 아닙니다. 컴팩션을 피하는 유일한 대안은 컨텍스트 부족 오류를 마주하는 것뿐입니다.

보존 설정 조정하기. CLI는 두 가지 설정을 제공합니다. 그대로 유지할 최소 최근 메시지 쌍의 수인 compaction.excludeMessages와 최근 메시지로 유지할 컨텍스트 창의 최소 비율인 compaction.excludeContextWindowPercent입니다. 둘 다 기본값은 2이며, "두 설정이 모두 평가되어 더 보수적인(더 큰) 값이 적용"됩니다.

이 값을 높이면 최근 대화의 꼬리 부분을 더 많이 그대로 유지하므로 연속성에 확실히 도움이 됩니다. 하지만 한 시간 전에 이루어진 추론에는 아무런 도움이 되지 않습니다. 꼬리는 중요도가 아니라 최신성에 의해 정의되기 때문입니다. 이는 긴 컨텍스트 창이 메모리가 될 수 없는 이유에서 설명한 일반적인 한계입니다.

세션 내보내기. Kiro는 올바른 이유로 이를 권장합니다. "전체 기록을 보존해야 하는 경우 컴팩션이 발생하기 전에 세션을 내보내십시오." 내보내기는 완전한 손실을 막는 실제적인 안전장치입니다. 하지만 이는 검색 메커니즘이 아닙니다. 기록은 시간 순서대로 정렬되어 있고 인덱싱되지 않으며, 현재 무엇이 사실인지보다는 당시에 무슨 말을 했는지를 설명하기 때문입니다. 이 차이가 바로 인덱싱된 세션 로그가 기억하는 것과 기억하지 못하는 것의 핵심 주제입니다.

각 단계마다 새 세션 시작하기. 합리적인 관리 방법이며, Kiro의 CLI 가이드에서도 "동일한 세션 내에서 새로운 단계의 작업을 시작하기 전에" /compact를 실행할 것을 권장합니다. 하지만 새 세션은 스티어링 파일만 있고 대화는 없는 상태로 시작되므로, 지난 세션에서 정립하고 기록해 두지 않은 모든 내용은 요약이 아니라 정의상 사라지게 됩니다.

모든 것을 스티어링에 넣기. 과도한 교정입니다. .kiro/steering/ 아래의 Kiro 스티어링 파일은 기본적으로 항상 켜져 있으며, 스티어링 위치의 AGENTS.md는 범위를 지정할 수 없습니다. 문서에 따르면 "AGENTS.md 파일은 포함 모드를 지원하지 않으며 항상 포함됩니다." 전체 추론 기록을 그곳으로 옮기면 컴팩션 문제를 컨텍스트 예산 문제로 전환하는 꼴이 되며, 이는 AI 에이전트에게 얼마나 많은 메모리를 주어야 하는가에서 다룬 트레이드오프입니다.

테이블 자체가 도구입니다. 사후 분석이 아니라 사실이 나타나는 순간에 이를 라우팅 규칙으로 사용하세요.

1단계: 두 열을 라우팅 명세서로 읽기

Kiro의 테이블을 문자 그대로 받아들이고 작업 중에 적용해 보세요. 세션에서 중요한 사실이 정립되면 그것이 어느 열에 해당하는지 자문해 보십시오.

작업 상태, 수정된 경로, 다음 단계 또는 명시된 요구 사항이라면 대화에 그대로 두십시오. Kiro가 이를 보존하므로 다른 곳에 중복해서 기록하면 서로 일치하지 않는 두 개의 기록이 생길 뿐입니다.

논거, 거부된 옵션, 교훈을 준 해결된 오류, 또는 비교 대상인 코드 스니펫이라면 이는 압축 가능한 목록에 해당합니다. 이는 지금 대화 내용이 그대로 남아 있을 때 다른 곳에 기록하라는 신호입니다.

경계선에 있는 사례는 보존되는 열에 있는 "주요 결정 및 제약 조건"입니다. 결정은 살아남지만, 그 정당화 과정은 살아남지 못합니다. 따라서 결정에 대한 라우팅 규칙은 다음과 같습니다. 결정은 대화에 남겨두고, 그 정당화 과정은 외부로 작성하십시오. 기록된 이유가 없는 제약 조건은 다음에 이를 불편하게 여기는 사람에 의해 삭제되기 마련입니다.

2단계: 재사용 가능한 절반을 스티어링으로 승격하고, 스티어링 범위 제한하기

작성한 내용 중 일부는 다음 세션에서도 유효하므로 Kiro 자체 설정에 속해야 합니다.

스티어링 파일은 워크스페이스 범위의 경우 .kiro/steering/에, 글로벌 범위의 경우 ~/.kiro/steering/에 위치하며, 프론트 매터에서 포함 모드를 설정할 수 있습니다. 이때 주의해야 할 문서화된 제약 조건이 있습니다. "포함 설정은 파일의 첫 번째 콘텐츠여야 하며, 그 앞에 빈 줄이나 콘텐츠가 없어야 합니다." 세 가지 모드는 always(기본값), fileMatchPattern을 사용하는 fileMatch, 그리고 manual입니다.

수명 주기에 따라 사용하세요. 전체 리포지토리에 적용되는 규칙은 always 파일에 넣습니다. 특정 영역에만 적용되는 규칙은 inclusion: fileMatch와 패턴을 지정하여 다른 곳에서 작업할 때 비용이 들지 않도록 합니다. 가끔 호출하는 긴 절차는 manual로 설정합니다.

스티어링에 어울리지 않는 것은 프로젝트 결정의 누적 기록입니다. 스티어링은 모든 작업의 매 세션마다 로드되므로 결정 로그가 무한히 커지게 됩니다. 또한 Kiro는 글로벌 스티어링이 장비별 디렉터리라고 명시하고 있습니다. 웹에서 "글로벌 스티어링"은 로컬 ~/.kiro/steering/ 디렉터리를 가리키며, "클라우드 샌드박스는 이를 읽을 수 없습니다." 따라서 클라우드 세션에서 이를 재사용하려면 Configuration Sync를 통해 업로드해야 합니다. 한 노트북에만 존재하는 파일은 팀의 기록이 될 수 없습니다.

3단계: 요약이 실행되지 않는 곳에 이유를 위한 공간 마련하기

나머지 정보(거부된 접근 방식, 제약 조건 뒤에 숨겨진 이유, 에이전트가 막혔을 때 사람이 제공한 사실 등)는 이전의 두 목적지 모두에서 제외되는 세 가지 특성을 가집니다. 지속적으로 늘어나므로 항상 켜둘 수 없고, 드물고 구체적으로 쿼리되므로 모든 프롬프트에 포함되어서는 안 되며, 다음 세션, 다음 사람, 다음 도구에서도 읽을 수 있어야 하므로 한 장비의 기록에만 머물러서는 안 됩니다.

이것은 파일도 대화도 아닌 저장소(store)입니다. 결정이 내려질 때 추가되고 결정에 의문이 제기될 때 읽히며, 그 안의 어떤 것도 요약 과정을 거치지 않습니다.

MemoryLake가 바로 그 저장소입니다. 세션이 압축하는 추론과 스티어링 파일이 담지 말아야 할 내용을 보관하는 공유 레이어입니다. Kiro는 상태를 유지하고, 스티어링은 상시 규칙을 유지하며, 이 레이어는 논거를 유지합니다. 여기서 시작하세요.

1단계: API 키 생성

프로젝트를 위한 워크스페이스를 생성하고 API 키를 발급받습니다. 세션당 하나가 아니라 프로젝트당 하나의 워크스페이스를 사용해야 컴팩션이 재설정하는 세션들을 아우를 수 있습니다.

2단계: 첫 번째 메모리 업로드

처음부터 시작할 필요는 없습니다. 이미 컴팩션이 진행된 세션을 내보내어 압축 가능한 열에 해당하는 정보(시도했다가 포기한 접근 방식, 설계를 바꾼 오류, 누군가 구두로 언급한 제약 조건 등)를 추출해 보세요. 이미 가지고 있는 각 스티어링 파일의 이면을 설명하는 이유를 추가하십시오. 해당 파일들은 왜 그런지 설명하지 않고 규칙만 명시하고 있기 때문입니다.

3단계: AI 및 에이전트 연결

실제로 사용하는 환경 전반에 Kiro를 연결하세요. IDE와 CLI는 컴팩션 시 다르게 동작하므로 두 환경 모두 동일한 데이터 세트를 읽어야 합니다. 팀 워크플로우를 위해 Kiro Crew를 실행하는 경우 해당 에이전트도 연결하여, 예약된 에이전트가 이를 설정한 사람보다 더 좁은 기록을 바탕으로 작동하지 않도록 하십시오.

긴 세션에서 보이지 않게 정보가 손실되는 일이 사라집니다. 컴팩션은 여전히 자체 일정에 따라 실행되고 요약본은 여전히 상태를 유지합니다. 하지만 각 제약 조건 뒤에 숨겨진 논거는 요약되지 않는 곳에 보관되므로, 컴팩션된 세션은 메모리가 짧아진 것이 아니라 컨텍스트가 작아진 것뿐입니다.

재설명 루프가 줄어듭니다. 유실된 세부 정보를 다시 설명하라는 Kiro의 조언은 한두 번은 괜찮습니다. 하지만 한 달 동안 매 세션마다 동일한 세 가지 사실을 다시 설명해야 한다면 비용이 많이 들고, 설명하는 사람이 그 사실이 정립되었었다는 것 자체를 기억해야 하므로 신뢰할 수 없습니다.

거부된 접근 방식이 다시 제안되지 않습니다. "해결된 문제의 오류 세부 정보"는 압축 가능한 목록에 있으므로 작동하지 않았던 기록이 가장 먼저 사라집니다. 이를 기록해 두면 에이전트가 화요일에 배제했던 방안을 다시 제안하는 일을 막을 수 있습니다.

스티어링 파일이 효과적인 수준으로 작게 유지됩니다. 결정 로그가 자체적인 공간을 가지면, 스티어링은 매 요청마다 컨텍스트를 소모하는 끊임없이 늘어나는 문서 대신 짧은 상시 규칙 세트가 될 수 있습니다. 항상 켜져 있는 레이어를 가볍게 유지해야 하는 일반적인 논거는 더 적게 보관함으로써 에이전트 메모리가 더 정확해진 방법에서 확인할 수 있습니다.

이유는 세션이 끝날 때가 아니라 언급되는 순간에 기록하십시오. 세션이 끝날 때쯤에는 대화가 이미 컴팩션되었을 수 있으며, 컴팩션 시점 이전의 기록은 "세션 내에서 복구할 수 없다"는 Kiro의 경고가 적용됩니다.

장시간 자율 실행을 하기 전에 내보내기를 수행하십시오. 비용이 들지 않고 Kiro가 권장하는 방법이며, 감사할 수 없는 요약본만 남는 상황을 방지하는 유일한 방법입니다.

보존이 아니라 연속성을 위해 CLI 보존 설정을 높이십시오. compaction.excludeMessages를 늘리면 에이전트가 경계를 넘어서도 일관성을 유지하는 데 도움이 됩니다. 하지만 보호되는 창은 최신성에 의해 정의되므로 이는 저장소가 아닙니다.

always 스티어링보다 fileMatch 스티어링을 더 많이 사용하십시오. 모든 always 파일은 매 요청마다 동일한 컨텍스트를 두고 경쟁하므로, 범위를 지정할 수 있었던 파일들은 순수한 오버헤드가 됩니다. 또한 스티어링 위치의 AGENTS.md에는 사용할 수 있는 포함 모드가 없다는 점에 유의하십시오.

작성할 때 결정과 제약 조건을 구분하십시오. "결제에서 공유 재시도 헬퍼를 사용하지 마십시오"는 제약 조건이며 컴팩션에서 살아남습니다. "이중 청구가 발생하는 실패 경로에서 재시도하기 때문입니다"는 이유이며, 살아남지 못합니다. 그리고 이 이유만이 6개월 후에 제약 조건이 삭제되는 것을 막을 수 있는 유일한 장치입니다.

참고용 세션 로그를 유지하는 경우, 이를 저장소와 분리하여 보관하십시오. 로그는 시간 순서대로 기록되며 당시에 무슨 말을 했는지 설명합니다. 저장소는 현재 무엇이 사실인지 설명합니다. 이 둘을 섞으면 가장 최근의 모순된 내용이 가장 오래된 주장 옆에 놓이게 되어 구분할 수 없게 됩니다. 그리고 나중에 도구를 이동할 때 깔끔하게 이식되는 것은 저장소입니다. 이는 Kiro에서 Codex로 마이그레이션하기에서 확인한 바와 같습니다.

Kiro의 컴팩션 테이블은 무엇을 대비해야 하는지 정확히 알려주기 때문에 대부분의 벤더 문서보다 더 유용합니다. 상태, 경로, 결정, 다음 단계, 의도는 살아남습니다. 도구 호출 세부 정보, 탐색적 논의, 중간 추론 단계, 해결된 오류 세부 정보, 이전 코드 스니펫은 살아남지 못할 수 있으며, 이 작업은 단방향입니다.

실질적인 대응은 컴팩션과 싸우는 것이 아닙니다. 두 번째 열의 정보를 저장하는 공간으로 대화를 사용하는 것을 중단하는 것입니다. 사실이 나타나는 순간 어느 열에 속하는지 결정하고, 상시 규칙을 범위가 지정된 스티어링 파일로 승격하며, 추론 과정에는 요약 단계가 닿지 않는 공간을 마련해 주는 것입니다. 그렇게 하면 컴팩션된 세션은 Kiro가 말한 그대로 유실되는 정보 없이 컨텍스트만 작아진 상태가 됩니다.