이 지점에서 앞서 언급한 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/ 경로에 자동으로 생성되었다.
생성된 사용자 플러그인은 플러그인 메뉴 내가 만든 항목에서 확인 할 수 있고 "추가" 버튼을 클릭하여 바로 사용할 수 있다.
- 새로운 플러그인 생성을 위해 @plugin-creator 채팅으로 이동
- 생성 후 플러그인 메뉴에서 내가 만든 항목으로 이동
- 생성된 목록에서 새로운 스킬을 추가
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
- 불필요하다고 판단해 읽지 않은 파일
- 최종 판단 전 원문 검증 여부
이번 테스트 결과를 보면 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 스킬의 효과를 “느낌”이 아니라, 실제 탐색 범위 축소 결과로 비교할 수 있을 것 같다.
* 앞에서 언급되는 이름들은 테스트에 적용된 프로젝트 소스 이름이다.
댓글 없음:
댓글 쓰기