테스트 결과와 서버 로그를 오래 읽힌 뒤, 코딩 도우미가 방금 정한 수정 범위를 다시 묻는 일이 있다. 대화에 쌓인 출력이 작업 지시와 같은 공간을 차지하기 때문이다. Context Mode는 큰 파일을 별도 프로세스에서 처리하고 필요한 결과만 대화에 돌려주는 도구다. 대화가 압축될 때 작업 상태를 이어 주는 기능도 묶었다. 두 기능이 어떻게 다른지 알면, 로그를 줄이는 도구에 기억 전체를 맡기는 착각을 피할 수 있다.
Context Mode 설치 방법: Claude Code 플러그인부터
Claude Code를 쓰고 있다면 플러그인 마켓플레이스 경로가 가장 짧다. 먼저 터미널에서 node --version과 claude --version을 확인한다. 현재 패키지는 Node.js 22.5.0 이상을 요구하고, README의 Claude Code 최소 버전은 1.0.33이다. 아래 두 줄은 터미널 명령이 아니라 Claude Code의 대화 입력창에 차례로 넣는다.
/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode설치 뒤 Claude Code를 다시 시작하거나 /reload-plugins를 실행한다. 이어 같은 입력창에서 진단을 요청한다.
/context-mode:ctx-doctor진단은 실행 환경, 훅, SQLite 전문 검색 기능인 FTS5, 플러그인 등록 상태를 살핀다. 실패한 항목이 있으면 그 항목부터 해결한다. 설치 목록에서 enabled로 보이는 것과 MCP 서버가 실제 요청에 응답하는 것은 다르다. Bun이 없어 패키지 설치를 건너뛰었다는 메시지가 표시될 수도 있으므로, 목록만 보고 끝내지 않는다. 이후 /context-mode:ctx-stats로 도구 호출과 사용량 집계가 생기는지 확인한다.
격리한 설정 폴더에서 Claude Code 2.1.291로 설치했을 때 Context Mode 1.0.169가 enabled 상태로 등록됐다. 별도로 같은 버전의 MCP 서버에 연결해 조회한 도구 목록에는 파일 처리, 문서 색인, 검색 도구가 들어 있었다.
로그 1만 행을 읽히는 대신 오류 행을 고른다
서버 로그에서 결제 시간 초과를 찾는다고 해 보자. 로그 전체를 대화에 붙이면 정상 응답도 모두 작업 공간을 차지한다. Context Mode의 ctx_execute_file은 파일을 FILE_CONTENT 변수로 읽어 코드를 실행한다. 모델은 로그 내용을 한 줄씩 읽는 대신, 어떤 조건으로 고를지 코드를 작성한다. 대화에 들어오는 것은 그 코드가 출력한 결과다.
동작 확인에는 정상 상태 줄과 오류 줄을 섞은 가상 로그 1만 행을 썼다. 실제 장애 기록이 아니라 재현을 위해 만든 입력이다. ERROR가 들어간 줄만 골라 출력하자 전체 행 수와 오류 개수, 오류 3행이 돌아왔다. 사용한 JavaScript는 다음과 같다.
const rows = FILE_CONTENT.split('\n');
const errors = rows.filter(line => line.includes('ERROR'));
console.log(JSON.stringify({lines: rows.length, errors: errors.length}));
console.log(errors.join('\n'));입력 파일은 260,008바이트였고, 도구가 돌려준 텍스트는 실행 코드와 경로를 포함해 386바이트였다. 이 숫자는 같은 파일에서 지정한 오류만 고른 결과다. 전체 로그 분석의 정확도나 다른 업무의 절감률을 뜻하지 않는다. 필요한 사건을 빠뜨리지 않으려면 먼저 넓게 집계한 뒤, 시간대·요청 식별자·오류 유형을 좁혀 읽는 편이 낫다.
Claude Code에 요청할 때는 도구 이름과 찾을 조건을 함께 적으면 된다. 예를 들어 “Context Mode로 access.log의 ERROR 행 수를 세고 마지막 5행만 보여 줘. 아직 코드는 수정하지 마”처럼 분석 대상과 반환 범위를 구분한다. 출력이 다시 커지면 그만큼 대화도 커진다. 도구를 거쳤다는 사실보다 무엇을 출력했는지가 더 중요하다.
다시 찾을 문서는 색인하고, 작업 상태는 훅으로 남긴다
일회성 로그 집계와 반복해서 찾을 문서는 처리 방식이 다르다. 운영 매뉴얼이나 API 설명서는 ctx_index로 저장하고 ctx_search로 필요한 구간을 찾는다. SQLite FTS5를 사용하며, 검색어에 맞는 원문 조각을 돌려준다. 검색 결과를 모델이 새로 요약한 문서와 혼동하지 않는 것이 좋다.
별도 테스트에서는 결제 시간 초과 대응과 상태 점검 설명을 두 제목으로 나눈 가상 매뉴얼을 색인했다. checkout timeout을 검색하자 결제 연동 서버와 연결 풀을 점검하라는 구간이 나왔다. 로그에서 찾은 증상과 운영 문서의 대응 절차를 연결할 수 있는 셈이다. 실제 업무에서는 문서 이름을 source로 지정해 다른 프로젝트 자료가 섞이지 않게 검색 범위를 좁힐 수 있다.
대화 압축 뒤 작업을 잇는 기능은 별도 경로다. 훅이 파일 수정, Git 작업, 오류, 사용자 결정 같은 사건을 기록하고 압축·재개 시점에 작업 상태를 복원한다. MCP 서버만 추가하면 파일 처리와 검색은 쓸 수 있지만, 플랫폼에 맞는 훅이 없으면 같은 수준의 세션 연속성이 생기지 않는다.
Claude Code용 플러그인은 훅과 도구를 함께 등록한다. Codex CLI도 지원하지만 README는 현재 훅 기반 세션 추적을 부분 지원으로 분류한다. Cursor는 도구 사건을 수집해도 압축 후 복원이 제공되지 않는다고 안내한다. 다른 클라이언트로 옮길 때는 “MCP가 연결됐다”와 “이전 작업 상태가 복원된다”를 따로 확인해야 한다.
권한과 라이선스는 줄어들지 않는다
README에서 말하는 샌드박스는 실행별 프로세스를 나누고 원시 출력을 대화 밖에 두는 구조다. 네트워크를 끊거나 시스템 전체를 격리하는 가상 머신으로 생각하면 안 된다. 인증된 CLI를 실행할 수 있도록 환경과 설정 경로를 전달하는 기능도 있다. 운영 자격증명이 있는 환경에서는 실행 코드와 파일 접근 범위를 기존 도구와 마찬가지로 검토해야 한다. 대화에 데이터를 덜 보낸다는 것과 코드 실행 권한을 줄인다는 것은 다른 문제다.
저장소의 라이선스는 Elastic License 2.0이다. 사용·복사·수정·배포를 허용하지만, 상당한 기능을 제삼자에게 제공하는 호스팅·관리형 서비스에는 제한이 있다. 내부 개발 도구로 쓰는 경우와 제품에 얹어 서비스하는 경우를 나누어 판단해야 한다.
처음에는 긴 로그 하나를 골라 원래 파일을 남긴 채 오류 집계부터 해 보면 된다. 반환값이 필요한 줄을 포함하는지 대조한 뒤, 자주 찾는 매뉴얼을 색인한다. 세션 복원은 그다음에 압축 전후의 수정 파일과 사용자 지시가 이어지는지 확인한다. 작은 출력 하나가 제대로 돌아오는 것부터 확인하면, 설치 성공과 업무에 쓸 수 있는 상태를 구분하기 쉽다.