사용기 - Large Context Analysis 스킬 적용기: CodeGraph로 컨텍스트를 적게 읽게 만들기

MIT CSAIL의 논문 「Recursive Language Models」는 긴 컨텍스트 문제를 다른 방식으로 접근한다. 이 논문은 OOLONG-Pairs처럼 입력 전체의 많은 쌍을 비교해야 하는 작업에서, GPT-5 기본 모델과 compaction agent가 각각 0.1 F1 수준에 머무른 반면 RLM depth=1은 58.0 F1을 기록했다는 결과를 제시한다.

이를 바탕으로 논문은 긴 프롬프트를 LLM 컨텍스트 창에 직접 넣거나 반복 요약하는 대신, 외부 환경에 두고 필요한 부분을 프로그램적으로 탐색·분해·재귀 호출하는 Recursive Language Models, RLMs를 제안한다.

* OOLONG-Pairs : 논문에서 RLM 성능을 검증하기 위해 사용한 긴 컨텍스트·고밀도 추론 벤치마크

* compaction agent : 긴 입력을 그대로 넣지 않고, 중간에 요약하거나 압축해서 더 짧은 컨텍스트로 만든 뒤 답하게 하는 방식의 에이전트

* F1 : 정답을 얼마나 잘 맞혔는지 보는 평가 지표

* RLM depth=1: 재귀 호출의 깊이를 1단계까지 허용

Headroom을 사용하면서 성능 리포트상으로는 토큰 절감 효과가 크게 표시되었지만, 컨텍스트를 줄인다는 것은 결국 모델에게 전달되는 정보가 줄어든다는 뜻이기도 하다. 특히 성능 지표에서 TOIN retrieval이 0%로 표시되는 상황에서는, 압축된 정보가 필요할 때 원문을 다시 꺼내 검증하는 루프가 실제로 동작하고 있는지 확신하기 어려웠다.

이 지점에서 앞서 언급한 Recursive Language Models 논문이 주는 시사점이 있었다.  논문은 긴 컨텍스트 문제를 단순히 더 큰 컨텍스트 창에 넣거나, 반복적으로 요약·압축하는 방식만으로 해결하기 어렵다고 본다. 특히 OOLONG-Pairs처럼 입력 전체의 많은 조합을 비교해야 하는 고밀도 추론 작업에서, GPT-5 기본 모델과 compaction agent는 각각 0.1 F1 수준에 머무른 반면, RLM depth=1은 58.0 F1을 기록했다. 이 결과는 긴 입력을 무조건 넣거나 줄이는 것보다, 외부 환경에 두고 필요한 부분을 탐색·분해·재귀 호출하는 방식이 더 효과적일 수 있음을 보여준다.

이 내용을 Codex 사용 방식에 그대로 적용하기는 어렵지만, 실무적인 힌트는 얻을 수 있었다. 코딩 에이전트들은 대부분 기본적인 파일 검색, 코드 탐색, 부분 읽기, 요약 기능을 제공한다. 그렇다면 반드시 Headroom처럼 컨텍스트를 프록시에서 압축하지 않더라도, 작업 절차 자체를 바꿔 불필요한 컨텍스트 생성을 줄일 수 있다.

기본적으로 CodeGraph를 사용하고 있기 때문에 CodeGraph를 RLM식으로 쓰는 스킬을 적용해보기로 했다. 

*CodeGraph : 코드베이스를 미리 분석해서 클래스, 함수, 호출 관계, 파일 구조를 그래프로 만들어두고, 코딩 에이전트가 필요한 코드 위치를 빠르게 찾도록 도와주는 도구

1. 스킬 생성하기

스킬 생성은 코덱스 앱을 사용했고 적용 모델은 GPT-5.5 매우 높음을 사용 plugin-creator 플러그인을 사용하여 다음 내용으로 생성을 요청했다. 

코덱스의 create-plugins 에 의하여 생성된 결과물은 ~/plugins/large-context-analysis/.codex-plugin/ 경로에 자동으로 생성되었다.

생성된 사용자 플러그인은 플러그인 메뉴 내가 만든 항목에서 확인 할 수 있고 "추가" 버튼을 클릭하여 바로 사용할 수 있다. 

1. 새로운 플러그인 생성을 위해 @plugin-creator 채팅으로 이동
2. 생성 후 플러그인 메뉴에서 내가 만든 항목으로 이동
3. 생성된 목록에서 새로운 스킬을 추가

2. 스킬 테스트 하기

다음으로 실제 테스트를 진행해보았다. 문제는 Large Context Analysis 스킬의 효과를 확인하기 어렵다는 점이다. 

 

큰 파일/데이터을 다룰때는 large-context-analysis 사용해.

첨부한 로그를 분석해줘.

전체 로그를 한 번에 읽지 말고,

최초 ERROR, 반복 stack trace, root cause 후보를 먼저 분리해줘.

그 다음 CodeGraph로 관련 클래스와 호출 경로를 찾고,

필요한 소스 구간만 확인해줘.

마지막에는 원인, 수정 후보, 검증 방법을 정리해줘.

보통은 간단하게 아래와 같은 작업 기준을 전달하는 것으로도 충분했다. 

큰 파일·긴 로그·대형 diff·복잡한 데이터 분석 시 `large-context-analysis` 스킬을 사용하고, CodeGraph로 작업 대상 코드를 먼저 선정한 뒤, 작업 완료 후 `Context Usage Report`를 반드시 제시한다.

Headroom처럼 토큰 절감률이나 압축률이 숫자로 표시되는 것이 아니기 때문이다. 그래서 작업 요청에 추가 조건을 넣었다. 

단순히 로그를 분석하게 하는 것이 아니라, 작업 완료 후 `Context Usage Report`를 제출하도록 했다. 이 보고서에는 사용한 검색어, CodeGraph 탐색 단계, 읽은 파일 목록, 전체 파일을 읽었는지 또는 일부 구간만 읽었는지, 확인한 주요 라인·메서드·SQL ID, 불필요하다고 판단해 읽지 않은 파일, 최종 원문 검증 여부를 포함하도록 했다. 

이렇게 하면 스킬의 효과를 “토큰이 얼마나 줄었는가”가 아니라 “Codex가 얼마나 불필요한 파일과 로그를 덜 읽었는가”, “관련 후보를 먼저 좁혔는가”, “최종 결론을 원문 기준으로 검증했는가”로 판단할 수 있을 것으로 기대했다. ( 테스트 과정에서 SKILL 에 Report 기능을 추가하여 아래 추가 설명없이도 확인이 가능하게 했다). 

"Context Usage Report"를 작성해줘.

Context Usage Report에는 다음을 포함해줘.

- 사용한 검색어

- 사용한 CodeGraph 쿼리 또는 탐색 단계

- 읽은 파일 목록

- 전체 파일을 읽었는지, 일부 구간만 읽었는지

- 확인한 주요 라인/메서드/SQL ID

- 불필요하다고 판단해 읽지 않은 파일

- 최종 판단 전 원문 검증 여부

Context Useage Report 

이번 테스트 결과를 보면 Large Context Analysis 스킬은 어느 정도 의도한 방식으로 동작했다. Codex는 처음부터 전체 코드베이스를 읽지 않고, search-visualization, VectorSearchVisualizationService, VectorStorePort, PgVectorStoreAdapterV2, PgVectorMapper, metadataFilter, includeText, includeMetadata 같은 기능과 관련된 구체적인 검색어를 사용해 관련 범위를 좁혀 갔다.

CodeGraph 탐색도 /search-visualization에서 시작해 Controller → Service → VectorStorePort → PgVectorStoreAdapterV2 → PgVectorJdbcMapper → PgVectorMapper.xml 경로로 진행되었다. 즉 단순히 파일을 많이 읽는 방식이 아니라, 기능의 호출 흐름을 먼저 따라가며 후보 파일을 좁힌 것이다.

실제로 읽은 파일도 구분되었다. DefaultVectorSearchVisualizationService.java와 PgVectorSearchParameter.java는 전체를 확인했고, PgVectorJdbcMapper.java, PgVectorMapper.xml, 테스트 파일은 관련 SQL 또는 테스트 구간만 부분적으로 확인했다. 반면 RAG 일반 검색 Controller/DTO, SkillGraph/Markdown 파일, projection 생성 및 point 저장 관련 파일은 이번 작업 범위와 직접 관련성이 낮다고 판단해 재검토 대상에서 제외했다.

이 점은 Large Context Analysis 스킬의 효과를 보여주는 부분이다. 효과가 토큰 절감률처럼 숫자로 표시되지는 않지만, Codex가 검색과 CodeGraph를 먼저 사용해 후보를 좁히고, 필요한 파일과 구간만 확인했으며, 불필요한 파일을 읽지 않도록 유도했다는 점에서 컨텍스트 사용을 줄이는 방향으로 동작했다고 볼 수 있다.

또한 최종 판단 전 CodeGraph 결과를 원문으로 확인하고, rg로 SQL 패턴을 재확인했으며, 대상 Gradle 테스트와 git diff --check까지 통과시켰다는 점도 중요하다. 이는 요약이나 CodeGraph 결과만 믿지 않고 원본 파일과 테스트 결과를 기준으로 검증했다는 의미다.

다만 효과를 더 명확히 보려면 다음부터는 후보 파일 수, 실제 읽은 파일 수, 전체 읽기 파일 수, 부분 읽기 파일 수, 제외한 파일 수를 함께 기록하는 것이 좋다. 그렇게 하면 Large Context Analysis 스킬의 효과를 “느낌”이 아니라, 실제 탐색 범위 축소 결과로 비교할 수 있을 것 같다.  

* 앞에서 언급되는 이름들은 테스트에 적용된 프로젝트 소스 이름이다.

마지막으로 이번 실험의 결론은 Headroom이 불필요하다는 것이 아니다. Headroom은 긴 로그나 반복 tool output을 줄이는 데 여전히 유용할 수 있다. 다만 압축된 컨텍스트 품질이 찜찜하다면 (개인적인 생각), 먼저 CodeGraph와 스킬을 이용해 “처음부터 필요한 것만 읽게 만드는 방식”을 적용해볼 만하다. Large Context Analysis 스킬은 토큰 절감 도구라기보다, 코딩 에이전트의 조사 습관을 바꾸는 절차적 안전장치에 가깝다.

사용기 - Headroom으로 Codex 토큰 사용량 줄이기

코딩 에이전트를 사용하여 코드를 분석하고 수정하다보면 가장 먼저 부딪치는 문제는 컨텍스트(모델이 답변을 만들기 위해 한 번에 참고하는 입력 정보 전체)와 토큰 사용량이다. 

LLM 은 텍스트를 글자 단위가 아닌 토큰(token) 단위로 처리하는데 토큰은 대략 단어 조각, 기호, 코드 조각에 해당한다. 즉 컨텍스트가 길어질 수록 LLM 에 전달되는 토큰 수도 증가하게 된다.

1. Headroom

Headroom은 AI 코딩 에이전트가 LLM에 전달하는 컨텍스트를 압축해 토큰 사용량을 줄이기 위한 오픈소스 프로젝트다. 공식 README에서는 Headroom을 다음 문장으로 설명한다.

Compress everything your AI agent reads.

Same answers, fraction of the tokens.

즉, AI 에이전트가 읽는 파일, 로그, tool output, RAG chunk, 대화 이력 등을 LLM에 전달하기 전에 압축해서, 가능한 한 같은 답변을 더 적은 토큰으로 얻는 것이 목표다.

Codex 같은 AI 코딩 에이전트는 사용자의 질문만 LLM에 보내지 않는다. 문제 해결을 위해 소스 파일, 오류 로그, 터미널 명령 결과, git diff, 프로젝트 문서, 이전 대화 이력 등을 함께 전달한다. 이 정보들이 모두 컨텍스트가 되고, 컨텍스트가 길어질수록 토큰 사용량과 비용도 증가한다.

Headroom은 이 지점에서 Codex와 LLM 사이에 위치하는 컨텍스트 압축 레이어로 동작한다. 기술적으로 보면 Headroom은 Codex가 LLM Provider로 요청을 보내기 전에 중간에서 요청을 받아 컨텍스트를 정리한다.

 Codex가 파일을 읽거나, 터미널 명령을 실행하거나, 검색 결과와 로그를 수집하면 이 결과들은 그대로 LLM 입력에 포함될 수 있다. Headroom은 이 입력을 가로채서 중복 제거, 요약, 필터링, 구조화 같은 처리를 수행한 뒤 더 짧은 형태의 컨텍스트로 다시 구성한다.

아키텍처 및 동작방식

이 구조에서 중요한 점은 Headroom이 최종 답변을 직접 생성하는 모델이 아니라는 것이다. Headroom은 Codex와 LLM 사이에서 입력 컨텍스트를 최적화하는 계층이다. 즉, “무엇을 답할 것인가”는 여전히 LLM이 담당하고, Headroom은 “LLM에게 어떤 정보를 얼마나 효율적으로 전달할 것인가”를 담당한다.

예를 들어 Codex가 테스트 실패 원인을 찾기 위해 수천 줄의 로그와 여러 개의 소스 파일을 읽었다고 가정해보자. 이 정보를 그대로 LLM에 보내면 토큰 사용량이 크게 증가한다. Headroom은 이 중 반복되는 stack trace, 중복 로그, 관련성이 낮은 출력 등을 줄이고, 오류 원인 분석에 필요한 핵심 정보를 중심으로 컨텍스트를 다시 구성한다.

따라서 Headroom의 기술적 역할은 단순히 텍스트 길이를 줄이는 것이 아니다. 컨텍스트 안에서 의미 있는 정보는 유지하고, 반복되거나 덜 중요한 정보는 줄여서 LLM이 더 적은 토큰으로 문제를 이해하도록 돕는 것이다.

이 때문에 Headroom은 특히 다음과 같은 작업에서 효과를 기대할 수 있다.

• 긴 빌드 로그 분석
• 테스트 실패 원인 추적
• 대형 코드베이스의 여러 파일 분석
• 큰 git diff 검토
• 검색 결과가 많은 작업
• 이전 대화 이력이 길게 누적된 Codex 세션

반대로 다음과 같은 경우라면 굳이 사용할 필요가 없다.

• 짧은 파일 수정
• 간단한 질문
• 작은 버그 수정
• 정확한 원문 로그 전체가 중요한 장애 분석
• 보안/권한/결제/마이그레이션처럼 작은 차이가 중요한 작업

2. 설치하기 

 환경

• Model : MacBook Pro (14-inch, 2021)
• CPU : Apple M1 Pro
• MENORY : 16GB
• DISK : 512 GB SSD
• OS : macOS 15.3.1 (24D70)
• AI Coding Agent : Codex

Headroom은 Codex 앱에 직접 붙는 도구라기보다, Codex CLI를 감싸거나 proxy로 연결하는 도구이다. 공식 README도 Headroom을 “AI agent가 읽는 tool output, logs, RAG chunks, files, conversation history를 LLM에 도달하기 전에 압축하는 도구”로 설명하고, Codex 같은 coding agent와 함께 사용할 수 있다고 안내하고 있다. 

먼저 Codex CLI 와 파이선이 설치되었는지를 아래 명령으로 확인한다.

python3 --version

pip3 --version

which codex

codex --version

참고로 Codex 앱만 사용하고 있더라도 Codex CLI 설치는 별도이다.  설치는 아래와 같은 명령으로 진행한다. (OpenAI 공식 문서 기준)

curl -fsSL https://chatgpt.com/codex/install.sh | sh

다음으로 python 패키지 형태로 headroom 을 설치한다. 

python3 -m pip install -U "headroom-ai[all]"

3. 사용하기

설치가 완료 되었다면 아래 명령으로 실행할 수 있다. 

headroom wrap codex

성능 리포트 기능을 사용하여 컨텍스트 압축이 효과가 있는지를 확인해 볼 수 있다. 

headroom perf

위 리포트 결과를 보면 압축후 토큰 사용량이 0 이 된점을 보아 좀 과장되었다고 생각을 하게 되었다. 또한 Retrievals 비율이 0% 인것으로 보아 패턴을 학습하고는 있지만, 그 학습된 패턴을 다시 꺼내 재사용하지는 못하고 있음을 알 수 있다. 이 결과는 사용 시간이 너무 잛아서 그런거라고 예상하고 있다.

좀더 긴 시간을 사용후에 확인 해보았지만  필요할 때 원문을 꺼내 사용한 기록은 존재하지 않았다. 

아쉬운 점은 /status 을 사용해도 요금 한도부분을 확인 할 수 없었다. (추측하건데 headroom warp API 가 이를 지원하지 않아서 인것 같다.) 사용하다 갑짜기 limit 에 도달했다는 메시지를 받았다. 

headroom wrap 명령이 codex 설정을 자동으로 모델 provider , openai_base_url 정보를 수정하기 때문에 headroom 을 사용하지 않는 경우에는 unwrap 으로 다시 설정을 원복 해줘야 한다. 

headroom unwrap codex  

 

4. 결론

개인적으로 Headroom을 사용하면서도 품질에 대한 찜찜함을 완전히 버리기는 어려웠다. 성능 리포트상으로는 토큰 절감 효과가 크게 표시되었지만, 컨텍스트를 줄인다는 것은 결국 모델에게 전달되는 정보가 줄어든다는 뜻이기도 하다. 특히 TOIN retrieval이 0%로 표시되는 상황에서는, 압축된 정보가 필요할 때 원문을 다시 꺼내 검증하는 루프가 실제로 동작하고 있는지 확신하기 어려웠다.