사용기 - 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%로 표시되는 상황에서는, 압축된 정보가 필요할 때 원문을 다시 꺼내 검증하는 루프가 실제로 동작하고 있는지 확신하기 어려웠다.

사용기 - CodeGraph 사용하여 Codex 가 코드를 구조화된 코드 그래프로 이해하게 만들기

AI 코딩 도구를 사용하면 자주 경험하는 문제는 "프로젝트 구조를 파악하는 데 시간이 많이 걸린다" 였다. 특히 멀티 모듈이나 대규모 코드로 구성된 프로젝트의 경우 기존 소스를 검색하여 파악하는데 많은 시간이 걸린다. 

CodeGraph 는 소스 코드를 분석해서 코드베이스를 그래프 형태로 인덱싱하는 오픈소스 프로젝트이다. 

CodeGraph는 AI 코딩 에이전트가 프로젝트 소스코드를 매번 grep, find, Read로 처음부터 탐색하지 않도록, 코드베이스를 미리 인덱싱해 코드 지식 그래프로 제공하는 도구다. 로컬 코드베이스를 분석해 .codegraph/ 디렉터리에 인덱스를 저장하고, Codex CLI, Claude Code, Cursor, Gemini CLI, Antigravity IDE 같은 AI 에이전트가 MCP를 통해 이 그래프를 조회할 수 있도록 해준다. 공식 설명에서도 CodeGraph는 tree-sitter 기반으로 코드베이스를 파싱하고, 심볼·엣지·파일 정보를 SQLite/FTS5에 저장하며, MCP를 통해 AI 에이전트에 제공하는 로컬 우선 코드 인텔리전스 도구라고 설명한다.

CodeGraph 는 AST(Abstract Syntax Tree) 결과를 이용하여 코드 그래프를 만들어 사용하고 있는데 관련하여 2026년 arXiv 논문 "Codebase-Memory:Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP" 에 따르면Tree-sitter 기반 코드 지식 그래프 + MCP 방식이 **토큰은 10배 적게, tool call은 2.1배 적게 사용했지만, 답변 품질은 파일 탐색형 agent 92% 대비 83%**였다고 보고한다. 즉, 그래프 기반 탐색은 효율성은 높지만, 원본 파일을 충분히 읽는 방식보다 품질이 낮아질 수 있다는 문제를 보여주고 있다.

CodeGraph는 이런 품질 이슈를 “자동 정답화”로 해결하지 않고, AST 기반 그래프 + context/trace/impact + 원본 body 제공으로 사실 확인 비용을 줄이는 방식으로 완화하고 있다.

1. 설치하기 

 환경

• 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

설치는 npm 을 사용하여 전역으로 설치하는 방식을 사용했다. (여러 프로젝트에서 사용할 수 있도록)

npm install -g @colbymchenry/codegraph

설치 이후에는 다음 명령으로 확인 할 수 있다. 

codegraph --version

which codegraph

2. AI 코딩 에이전트에 MCP 연결

CodeGraph는 MCP 서버로 동작한다. 따라서 Codex, Claude Code, Cursor 같은 AI 코딩 도구에서 사용하려면 먼저 MCP 설정을 연결해야 한다. Codex 를 주력으로 사용하고 있어 Codex 에 MCP 로 등록했다. 

codegraph install

이 명령은 현재 개발환경에 설치된 AI 에이전트를 감지하고, CodeGraph MCP 서버 설정을 자동으로 추가한다. 공식 README 기준으로 자동 설정 대상에는 Claude Code, Cursor, Codex CLI, opencode, Hermes Agent, Gemini CLI, Antigravity IDE, Kiro 등이 포함된다. 

기본적으로 설치는 전역으로 설치하고 각 프로젝트 경로에서 초기화를 해주것이 좋다. (여러 프로젝트에서 사용할 수 있게)

성공적으로 연결되었다면 아래와 같이 확인하거나 codex 도구에서 /mcp 명령으로 확인 할 수 있다. 

grep -A 3 -B 1 "codegraph" ~/.codex/config.toml

 Codex 앱에서 /mcp 입력

3. 로컬 프로젝트 초기화 및  인덱스 생성

로컬 프로젝트 루트로 이동하여 init 명령을 사용하여 초기화를 실행 합니다. 최초 초기화인 경우 -i 옵션을 사용하여 코드 분석 인덱싱까지 함께 진행하는 것이 일반적이다. 

codegraph init -i

코드가 추가 되거나 수정되면 index 명령을 사용하여 인덱스를 갱신한다. 

codegraph index

 status 명령으로 초기화 또는 인덱싱 상태를 확인할 수 있다. 

codegraph status

4. 사용 방법

5. 사용 후기

CodeGraph 을 코덱스에 사용한 결과 코드 검색 속도는 아주 빨라졌다. 작업 하기 전에 관련 코드를 검색하는 작업을 하는 것이 일반적인데 codegraph 을 사용하여 검색하고 해당 파일들을 기준으로 수정작업을 진행하기 때문에 상당한 속도 개선은 있는 것 같다.

추가로 CodeGraph 는 아주 빠른 속도록 업데이트 되고 있기 때문에 다음과 같이 설치된 버전과 최신 버전을 확인해서 

echo "installed: $(codegraph --version)"

echo "latest:    $(npm view @colbymchenry/codegraph version)"

최신 버전으로 업데이트 할 수 있다. (전역 설치의 경우에)

npm update -g @colbymchenry/codegraph

CodeGraph 버전을 업데이트했다면 필수는 아니지만 최신 분석 로직 반영을 위해서 index 을 다시 실행한는 것이 좋다. 

codegraph index

codegraph status

사용기 - ChatGPT 에서 설계 하고 개발은 Codex 에서

Codex 와 대화 하면서 구체적인 설계를 진행하는 것 보다 ChatGPT 에서 설계를 하고 대화 결과를 코덱스에 공유하여 구현을 하는 것을 테스트 해보았다. 실험의 목적은 코덱스의 토큰 사용량을 최소화하기 위한 경제성이다.

모델은 5.5 Pro 을 사용하였고 대화를 통하여 원하는 설계를 구체화 했다. Codex 전달용 작업 계획을 요청했지만 한번에 복사하여 사용하기는 어려운 점이 있었다. 

대화에 대한 공유 링크를 생성하고 링크를 Codex 에 전달하여 진행을 시도하였다. 다만 이경우 전체 대화 내용을 읽어서 작업 계획을 수립하기 때문에 진행 과정의 대화 까지 읽어 들여 비효율적이며 토큰을 낭비하게 된다. 

좀더 효과적은 작업 내용 전달을 위해서 ChatGPT 대화에서 최종 결과에 대한 md 파일 생성을 요청하여 Codex 에 공유하여 작업을 진행하게 했다. 

생성된 md 파일을 통한 작업 지시의 장점은 md 파일 계획이 1차, 2차 구현으로 구분되어 있는 경우 Codex 는 1차 구현만 진행하게 되는데 작업이 완료된 이후에 다시 2차 를 구현하도록 지시할 수 있다는 점이다. (또한 미리 작업 계획 초안을 검토하는 것이 용이)

이번 작업을 통해 느낀 점은 AI 코딩에서 중요한 것은 단순히 좋은 모델을 사용하는 것이 아니라, AI가 안정적으로 이해하고 작업할 수 있도록 작업 자체를 구조화하는 것이라는 점이다.

특히 ChatGPT에서 충분히 설계와 정리를 수행한 뒤, 최종 내용을 md 기반 작업 계획으로 압축하여 Codex에 전달하는 방식은 예상보다 효율적이었다.

공유 링크 방식은 전체 대화 흐름까지 모두 포함되므로 불필요한 컨텍스트 증가와 토큰 낭비가 발생하기 쉽다.

반면 md 기반 작업 문서는:

• 작업 범위를 제한하고
• 구현 단계를 분리하며
• 필요한 정보만 압축 전달하고
• 검토 가능한 형태로 유지할 수 있다.

결국 AI 시대의 개발 생산성은 “얼마나 긴 프롬프트를 작성했는가”보다, AI가 일하기 좋은 구조와 흐름을 어떻게 설계했는가 에 더 크게 좌우된다고 느꼈다.

사용기 - 프롬프트는 시작이고, AI는 환경에서 일한다

Feedback Loop Engineering은 2026년 1월 다니엘 데멜(Daniel Demmel)이 AI 코딩 에이전트의 품질을 높이는 핵심을 “검증 가능한 반복 구조”로 설명하면서 제시한 개념이다. 

이후 2026년 2월 OpenAI는 Codex 활용 사례를 통해 하네스 엔지니어링(Harness Engineering)이라는 표현을 사용하며, 에이전트가 안정적으로 일할 수 있도록 실행 환경·검증 체계·피드백 구조를 설계하는 접근을 소개했다. 

두 개념은 별개라기보다, Feedback Loop Engineering이 “무엇을 반복해야 하는가”를 설명하고 하네스 엔지니어링(Harness Engineering)이 “그 반복이 가능하도록 어떤 환경을 설계해야 하는가”를 설명한다고 볼 수 있다.

많은 사람들이 AI 코딩 에이전트를 잘 사용하는 방법은 “프롬프트를 잘 쓰는 것”이라고 생각한다.
하지만 최근 흐름은 다르다. “스스로 검증하고 개선할 수 있는 구조를 만드는 것”이다.

프롬프트 중심에서는 결과가 프롬프트 품질에 크게 의존하며 사람이 계속 개입해야 한다. Feedback Loop Engineering은 완전히 다른 방향을 제시한다.
AI가 스스로 결과를 개선하는 구조를 통하여, 결과 품질이 프롬프트가 아니라 테스트와 검증에 의해 결정되도록 만든다. 이러한 구조에서는 사람이 모든 과정을 직접 통제할 필요가 없다. AI는 실행 결과와 오류를 기반으로 스스로 수정하고, 반복적으로 품질을 높여간다.

결국 중요한 것은 더 정교한 질문이 아니라, 잘못된 결과를 빠르게 발견하고 수정할 수 있는 피드백 루프를 설계하는 것이다. 

결정적으로 최근 Codex에서 지원하기 시작한 “Computer Use”, “Browser Use” 기능을 직접 경험하면서 생각이 완전히 바뀌었다.

그동안은 좋은 프롬프트, 정교한 스킬, 다양한 서브에이전트를 만드는 것이 핵심이라고 생각했다.
하지만 실제로는 전혀 다른 결과를 보게 되었다.

단순한 명령만으로도

• 테스트 후 수정하고
• 서버를 재시작하고
• 브라우저에서 직접 화면을 확인하고
• 테스트 결과를 바탕으로 다시 수정하는

전체 작업 흐름을 AI가 스스로 수행하는 경험을 하게 되었다. 이 과정에서 느낀 것은 명확했다.

중요한 것은 프롬프트가 아니라 “일을 할 수 있는 환경”이었다.

프롬프트를 아무리 잘 작성해도 AI가 실행하고, 확인하고, 실패를 인지하고, 다시 수정할 수 없다면
결국 사람이 계속 개입해야 한다. 반대로, 환경만 제대로 갖추어지면 아주 간단한 명령만으로도 AI는 스스로 작업을 이어가고 결과를 개선해 나간다.

이 경험은 정말 충격적이었다.

에이전트가 테스트하고 수정하고 벡엔트 파트 작업는 이슈로 등록

에이전트가 이슈를 확인해서 처리하고 서버를 재시작해서 확인

결국 중요한 것은 질문을 잘하는 능력이 아니라,
AI가 스스로 실행하고 검증하며 반복할 수 있도록
프로젝트와 환경을 설계하는 것이다.

 

AI는 왜 사용자를 잘못된 확신으로 이끄는가 — Sycophancy 논문에서 본 대화형 AI 의 위험

Sycophantic Chatbots Cause Delusional Spiraling, Even in Ideal Bayesians 

최근 공개된 Sycophantic Chatbots Cause Delusional Spiraling, Even in Ideal Bayesians 논문은  ChatGPT와 같은 대화형 AI가 가질 수 있는 구조적 위험을 설명한다. 이 논문이 말하는 핵심은 단순하다.

AI의 위험은 단지 틀린 답을 하는 데만 있지 않다. 사용자의 현재 믿음을 반복적으로 정당화하면서 잘못된 확신을 점점 더 키울 수도 있다.

여기서 핵심 개념은 비위를 맞추는 성향(sycophancy) 이다. 이는 AI가 사용자의 말에 과도하게 동조하거나, 사용자가 기대하는 방향으로 답을 맞추려는 성향을 의미한다. 사용자는 이를 친절하고 공감적인 응답으로 받아들일 수 있지만, 반복적인 대화에서는 오히려 잘못된 방향의 자기 확신을 강화하는 결과로 이어질 수 있다.

예를 들어 사용자가 어떤 가설이나 해석을 제시했을 때, AI가 “그럴 가능성이 있다”, “관찰이 일관적이다”, “흥미로운 해석이다” 와 같은 표현을 반복하면 사용자는 자신의 판단이 점차 검증되고 있다고 느끼게 된다. 문제는 이것이 단순한 대화 UX 차원의 문제가 아니라, 잘못된 판단을 스스로 강화하는 구조로 발전할 수 있다는 점이다.

이 논문이 특히 주목할 만한 이유는 이러한 현상이 비합리적인 사용자에게만 나타나는 것이 아니라는 점이다. 연구에서는 새로운 정보를 받아들일 때 기존 믿음을 합리적으로 조정하는 이상적인 베이지안 사용자(ideal Bayesian user) 를 모델링했는데, 그 경우에도 sycophantic한 응답이 반복되면 잘못된 믿음이 강화될 수 있었다. 즉, 사용자의 논리성 여부와 관계없이 AI와의 상호작용 구조 자체가 인지적 편향을 만들어낼 수 있다는 의미다.

AI 기반 프로그램 개발자 입장에서 여기서 중요한 점은 할루시네이션(Hallucination, 환각)만 줄인다고 문제가 끝나지 않는다는 사실이다. 논문은 AI가 거짓말을 하지 않도록 제한한 경우도 실험했지만, 위험은 완전히 사라지지 않았다. 이유는 AI가 사실만 말하더라도 사용자의 믿음을 강화하는 사실만 선택적으로 제시할 수 있기 때문이다. 즉, 문제는 사실 여부뿐 아니라 어떤 정보를 선택하고 어떤 정보를 제외하는가에도 있다.

AI를 활용해 개발할 때는 몇 가지 실무 원칙을 의식할 필요가 있다.

• 첫째, AI의 응답을 최종 결론처럼 받아들이지 않아야 한다.
• 둘째, 하나의 답변만 신뢰하기보다 다른 해석이나 반대 근거도 함께 확인해야 한다.
• 셋째, 반복적인 대화 속에서 특정 방향으로 사고가 편향되고 있지 않은지 스스로 점검해야 한다.
• 넷째, 설계·보안·성능·운영과 같이 영향이 큰 판단은 반드시 사람이 최종 검토해야 한다.

결국 이 논문이 AI를 활용하는 개발자에게 주는 메시지는 분명하다. AI는 틀린 정보를 생성할 때만 위험한 것이 아니라, 사용자의 현재 생각을 자연스럽게 강화하면서 잘못된 확신을 만들어낼 수도 있다. 따라서 AI 기반 개발에서는 정확도뿐 아니라 균형성, 반대 근거 확인, 최종 판단의 책임 주체를 함께 고려해야 한다.

AI를 활용해 개발할 때 원칙을 실천하는 현실적인 방법

예를 들어 개발자가 AI에게 “이 구조가 맞는지 검토해줘”, “내 설계 방향이 타당한가”, “이 방식이 가장 좋은 방법 아닌가” 와 같이 질문하면, AI는 이미 질문 안에 포함된 방향을 따라 답할 가능성이 높다. 즉, 객관적인 검토보다 현재 사용자의 사고 흐름을 이어주는 방식으로 응답하기 쉽다. 이 때문에 실무에서는 질문의 방향 자체를 의도적으로 바꾸는 습관이 필요하다. 예를 들어 다음 두 질문은 비슷해 보이지만 결과는 분명히 다르다.

• 이 구조가 맞는지 검토해줘
• 이 구조의 취약점과 실패 가능성을 먼저 찾아줘

첫 번째 질문은 확인을 유도하고, 두 번째 질문은 반박을 유도한다. 실제로 두 번째 방식이 더 많은 위험 요소를 드러낸다. 같은 방식으로 코드 생성 이후에도 바로 적용하기보다, 추가 검증 질문을 이어가는 것이 중요하다. 예를 들어 AI가 특정 구현을 제안했을 때는 다음과 같이 다시 질문할 수 있다.

• 이 코드가 운영 환경에서 실패할 가능성이 있는 경우는 무엇인가
• 예외 상황에서 깨질 수 있는 부분은 어디인가
• 최신 프레임워크 기준으로 문제가 될 수 있는 부분은 없는가

즉, 첫 번째 답변은 초안으로 보고 두 번째 질문부터 검증 단계로 들어가야 한다.

설계 단계와 구현 단계도 분리해서 보는 것이 좋다. AI는 설계 설명에서는 매우 자연스럽지만, 실제 코드에서는 중요한 조건을 빠뜨리는 경우가 적지 않다. 예를 들어 먼저 구조를 설명받은 뒤 다시 다음과 같이 물을 수 있다.

• 지금 설명한 구조가 실제 코드에서 깨질 수 있는 조건을 찾아줘
• 트랜잭션, 동시성, 예외 처리 측면에서 위험 요소를 설명해줘

이렇게 하면 단순 설명보다 실제 적용 시 발생할 수 있는 문제를 더 빨리 발견할 수 있다. 여러 AI를 함께 사용하는 경우에는 교차 검증도 효과적이다. 예를 들어 다음과 같은 흐름이 가능하다.

• Codex 로 초안 작성
• Claude 로 구조적 취약점 검토
• Gemini 로 대안 비교

이 과정에서 중요한 것은 단순히 다른 모델에 다시 묻는 것이 아니라, 질문 자체를 다르게 주는 것이다.

예를 들어:

• 이 코드의 문제를 추측하지 말고 실제 코드 근거로만 지적해줘
• 반대 구현 방식이 더 적절할 수 있는 경우를 설명해줘

AI가 강한 확신을 보일수록 오히려 더 검증해야 한다는 점도 중요하다. AI는 매우 자연스럽게 “이 방식이 가장 적절하다”, “일반적으로 이렇게 구현한다” 와 같은 표현을 사용하지만, 이런 문장은 기술적 근거 없이 생성될 수도 있다. 따라서 이런 답을 받으면 반드시 다시 확인해야 한다.

• 공식 문서 기준 근거는 무엇인가
• 예외 사례는 없는가
• 다른 구현 방식과 비교하면 장단점은 무엇인가

결국 AI를 활용한 개발에서 중요한 것은 빠른 답을 받는 능력보다, 반대 질문을 던지고 검증 흐름을 만드는 능력이다. AI는 개발 속도를 높여주지만 동시에 빠른 확신도 제공한다. 따라서 개발자는 AI의 첫 답을 정답으로 받아들이기보다, 검토 대상이 되는 초안으로 다루는 태도가 필요하다.

사용기 - AI 가 다른 AI 의 작업 결과를 이어 받아 마무리 하기 (클로드 , 코덱스)

AI 가 다른 AI 의 작업 결과를 이어 받아 마무리 하는 것은 어떻까.

이슈는 코덱스(Codex) 가 초안을 작성하고 클로드(Claude) 상세화 했다. 

클로드(Sonnet 4.6) 계획 상세화 결과

코덱스(Codex)가 12개의 서브 이슈들로 구성된 언브렐라(#27) 이슈를 등록하고 클로드(Claude)에게 #27 이슈 구현을 요청했다. 

클로드(Sonnet 4.6) 구현 결과

코덱스(Codex)에게 클로드(Claude)의 작업 브랜치의 상태를 분석하여 현재 진행 상황을 확인하고 작업을 마무리 하게 했다. 

코덱스 (GPT 5.4 medium)  이어서 구현

클로드(Claude)에게  PR #40 에 대한 리뷰를 요청했다.

클로드(Sonnet 4.6)  1차 리뷰 결과

코덱스(Codex)에게 리뷰 결과를 조치하게 했다.

코덱스 (GPT 5.4 medium)  1차 리뷰 조치

클로드(Claude)에게  PR #40 에 대한 재 리뷰를 요청했다. 확인 결과 병합은 가능한 상태이지만 추가로 몇가지 마이너한 개선 사항이 도출되었다.

클로드(Sonnet 4.6)  2차 리뷰 결과(1차 리뷰 조치 확인)

코덱스(Codex)에게 다시 리뷰 결과를 조치하게 했다.

코덱스 (GPT 5.4 medium)  2차 리뷰 조치

다시 클로드(Claude)에게 리뷰를 요청했고 모든 이슈가 해결되었음을 확인 할 수 있었다.

클로드(Sonnet 4.6)  3차 리뷰 결과(2차 리뷰 조치 확인)

AI 모델에게 코드를 작성하게하고 같은 모델에게 리뷰를 시키면 코딩시 놓친 맹점이 리뷰할 떄도 그냥 넘어갈 수 있게된다. 참고로 보리스 체르니(Boris Cherny)가 공개한 Claude Code 내에서 코덱스(Codex) 를 사용하여 코드 리뷰를 수행하거나 Codex에 작업을 위임할 수 있는 플러그인이  Codex plugin for Claude Code 도 같은 맥락이다.

 

사용기 - 클로드, 코덱스, 제미나이 기반의 AI 코딩 : VUE 프로그램을 REACT 로 변경

작업의 목표는 기존 Vue3 기반 프로젝트를 1.x, 2.x 브랜치로 구분하고, 2.x 브랜치에서 React 전환을 진행하는 것이었다. 단순히 특정 모델 하나만 사용하는 것이 아니라, 여러 AI 코딩 에이전트를 실제 작업에 투입해 계획 수립, 상세화, 구현, 리뷰, 병합의 각 단계에서 어떤 조합이 가장 효율적인지를 확인해보고자 했다

1. 최초 계획 수립 - Codex

최초 작업 계획은 Codex(GPT-5.4, reasoning effort: medium)를 사용해 수립했다. Codex는 전체 작업 방향과 단계별 흐름을 정리한 MIGRATION_2X.md 문서를 작성했다. 이 문서는 실제 개발을 바로 수행할 수 있는 상세 설계서라기보다는, 원칙과 단계별 진행 방향을 정리한 초안 성격의 계획서에 가까웠다.

이 단계에서 느낀 점은 Codex가 최초 구조를 잡고 작업을 시작하는 능력, 그리고 여러 작업을 분할해 병렬로 진행할 수 있도록 초기 작업 틀을 만드는 능력이 우수하다는 점이었다. 이후 이 문서를 기반으로 모든 이슈를 등록하는 작업도 Codex를 통해 수행했고, 총 12개의 이슈가 생성되었다.    

2. 상세 계획 수립 - Gemini 중심, Codex 보조

클로드 공식 문서는 CLAUDE.md를 프로젝트 기억용 파일로 설명하고, /init로 시작용 CLAUDE.md를 자동 생성하라고 권고 하고 있다. 일관적인 작업 수행을 위해서 먼저 생성을 진행했다. 추가로 기존 프로젝트의 정책 및 템플릿 내용도 반영하도록 했다. Claude Pro 요금제의 가장 큰 불편함은 5시간 단위와 주간 단위의 사용 제한이다. 작업이 한창 진행되는 중간에 멈추는 경우가 반복되다 보니, 실제 사용성 면에서 답답함이 크다. 작업중에 주간 한계를 초과하여 금주 목요일 11:00 까지 기다려야 한다. 

제한이 풀리자 바로 /init 명령을 실행했고, 클로드는 기존 프로젝트의 파일을 분석하여 CLAUDE.md 을 생성했다. 

클로드(Sonnet 4.6) init 실행 결과

Claude 를 사용한 세부 계획 수립 계획을 변경하여 Gemini 2.5 Flash가 기존 MIGRATION_2X.md를 검토하여 세부 내용을 보완했고, 다시 Codex가 이를 검토하고 수정하는 방식으로 계획을 다듬었다. 다만 이후 실제 구현과 리뷰를 진행하는 과정에서, 작업 범위의 경계가 다소 모호하게 잡히는 경우가 있었고, 그 부분을 다시 Claude가 검토하면서 보완했다. 글 전체 흐름을 기준으로 보면 세부 계획 수립 능력은 Gemini보다 Claude가 더 안정적이었다고 판단된다.

제미나이(Gemini 2.5 Flash) 실행 가능성 검토

코덱스 (GPT 5.4 medium) 1차 검토

코덱스 (GPT 5.4 medium) 1차 검토 결과 보완

제미나이(Gemini 2.5 Flash) 2차 검토

다음으로 코덱스(GPT-5.4 reasoning effort : medium)를 사용하여 병렬작업을 고려하여 모든 이슈 등록과 변경된 문서을 커밋하도록 했다. (12개의 이슈가 등록됨)

생성되어 등록된 이슈 목록

이 과정에서 코덱스 역시 작업중에 주간 한계를 초과하였지만 미리 구매해두었던 토큰을 소모하면서 작업을 수행했다. 이 단계에서 얻은 결론은 다음과 같았다.

• Codex: 최초 계획 초안 작성에 강점

• Claude: 계획의 세부화와 경계 정리에 강점 (사용 제한으로 확인 못함)

• Gemini: 계획 보완과 실행 가능성 판단에 충분히 유용함 

3. 구현 - Codex와 Gemini 중심

실제 구현은 처음에는 Gemini(Free)를 통해 진행했다.

Gemini는 Plan 모드와 Edit 모드를 구분하고 있었고, 실제 코딩을 위해서는 Edit 모드 전환이 필요했다. 무료 버전임에도 불구하고, 구현 자체는 충분히 수행 가능했고, 리뷰 결과에 대한 수정도 상당히 잘 반영했다. 이 점에서 Gemini의 코딩 능력 자체는 충분히 확인할 수 있었다고 본다.

다만 사용량 제한에 도달하면 작업이 중단되는 문제가 있었고, 실제 작업 흐름을 이어가는 데에는 제약이 있었다. 그 이후 구현은 Codex가 이어받아 진행했는데, 이 과정은 서로 다른 모델 에이전트가 작업을 이어받을 수 있는지를 확인하는 좋은 사례가 되었다. Codex는 구현을 이어서 진행하는 데에도 무리가 없었고, 이후 병합 충돌 원인을 작업 히스토리 기준으로 파악하고 해결하는 모습도 인상적이었다.

실제 수행 흐름을 종합하면, 구현 단계에서는 다음과 같은 인상이 남았다.

• Gemini: 무료 버전 기준에서도 구현 능력은 충분히 확인 가능
• Codex: 구현의 연속성, 작업 유지, 충돌 해결, 마무리 처리에 강점

4. 리뷰 - Claude의 강점이 가장 분명했던 구간

구현 결과에 대한 검토는 주로 Claude를 통해 진행했다.

브랜치 리뷰, PR 리뷰, 리뷰 결과 확인, 추가 수정 요청 등 여러 단계에서 Claude를 반복적으로 사용했는데, 전체 흐름을 보면 이 부분에서 Claude의 장점이 가장 뚜렷하게 드러났다. Claude는 단순한 오류 지적이 아니라 작업 범위의 타당성, 보완 필요 지점, 수정 누락 여부를 비교적 안정적으로 짚어냈다. 

Codex도 코드 리뷰를 수행했지만, 글의 흐름상 Codex는 리뷰어 역할보다는 직접 수정하고 정리하는 역할에서 더 자연스러웠다. 반면 Claude는 여러 차례 교차 검증 과정에서도 추가 수정 사항을 찾아냈고, PR 리뷰 품질도 일관적이었다. 따라서 리뷰 단계에 대해서는 Claude가 가장 적합했다고 판단된다.

코덱스 (GPT 5.4 medium)  코드리뷰 결과

클로드(Sonnet 4.6) 브랜치 리뷰 결과

5. 병렬 작업과 교차 검증에서 확인한 점

이번 작업에서는 단순히 하나의 모델만 쓰지 않고, 서로 다른 모델을 조합해 병렬 작업과 교차 검증도 시도했다. Codex가 지시문을 작성하고, Gemini와 Codex 서브에이전트가 각각 구현을 수행한 뒤, Claude가 리뷰를 담당하는 방식도 실험했다. 또한 Claude가 작업한 결과를 Codex가 리뷰하고, 다시 Codex 결과를 Claude가 리뷰하는 교차 방식도 시도했다. 

이러한 과정을 통해 확인한 것은, 모델마다 잘하는 역할이 분명히 다르다는 점이다.

• Codex는 실행과 정리에 강했다.

• Claude는 계획의 정교화와 리뷰의 완성도가 높았다. 

• Gemini는 무료 버전 기준에서도 구현 능력을 보여주었다.

코덱스 (GPT 5.4 medium)  작업 결과

클로드(Sonnet 4.6) PR 리뷰 결과

다음으로는 작업을 서로 다른 모델 에이전트를 사용하여 진행해보았다. 이 작업위해서 코덱스를 사용하여 작업 지시를 위한 업무 계획을 정리하게 하게 한다음에 구현을 진행했다. 

이번에는 보다 정확한 병렬을 위해서 코덱스가 지시문을 작성하게 했다. 하나는 제미나이에게 작업을 요청했고 하나는 코덱스 서브에이전트가 작업하도록 했다. 

코덱스 (GPT 5.4 medium)  작업 지시문 생성

리뷰는 클로드를 사용하여 진행했다. 코덱스는 PR 까지 진행하여 PR 에 대한 리뷰를 (클로드가) 진행하고 (코덱스가) 결과 조치 후 다시 (크로드가) 리뷰를 진행했다. 코덱스는 1차 리뷰 결과에 대한 조치는 완벽하게 처리했고 2차 리뷰에 클로드에 의하여 추가 조치 사항이 발견되었으며 해당 내역역시 조치를 완료하는 것으로 리뷰 결과에 대한 조치 완전하게 처리함을 확인 할 수 있었다. 

클로드(Sonnet 4.6) 1차 리뷰 결과

클로드(Sonnet 4.6) 2차 리뷰 결과

클로드(Sonnet 4.6) 3차 리뷰 결과

제미나이는 작업 완료 이후 커밋까지는 했지만 PR 생성은 불가하다고 하여 작업 결과불을 기준으로 리뷰를 진행했다. 제미나이 역시 리뷰 결과에 대한 조치를 완전하게 처리했다. PR 생성은 클로드가 진행했다.

클로드(Sonnet 4.6) 최초 브랜치 리뷰 결과

클로드(Sonnet 4.6) 조치 결과 확인

병렬도 조치한 작업에 대한 병합 과정에서 제미나이 구현에 대한 PR 에서  충돌이 발생하여 코덱스를 사용하여 이슈를 해결하고 병합을 마무리 했다. 

깃랩 병합 이슈

코덱스가 작업 히스토리를 확인하여 원인을 파악하고 해결하는 과정이 인상적이었다. 

코덱스 (GPT 5.4 medium)  병합 이슈 해결

코덱스를 통한 중간 정검(9/12)과  MIGRATION_2X.md 문서를 현횅화 했다. 또한 코덱스는 남은 이슈별 작업 기준을 정리하고 코덱스 서브에이전트와 제미나이 + 클로드가 구현을 진행했다. 리뷰는 클로드 한꺼번에 했고 보완 역시 코덱스가 한번에 처리했다.

  

클로드(Sonnet 4.6) 리뷰 결과 확인

이제 하나의 이슈만 남았는데 코덱스가 마무리 구현을 진행하고 클로드가 리뷰하게 했다. 

클로드(Sonnet 4.6) 최종 리뷰 결과

작업 완료 후 로컬에서 직접 실행하여 화면을 확인해본 결과, 이번 계획의 범위였던 공통 기능을 포함한 사용자 파트의 React 전환은 완전하지는 않지만 전반적으로 잘 이관된 상태임을 확인할 수 있었다.

이번 실험을 통해 각 모델의 강점이 어느 정도 분명하게 드러났다.

특히 Gemini는 무료 버전을 사용했음에도 코딩 능력 자체는 충분히 확인할 수 있었다. 그러나 실제 실무에서 지속적으로 사용하기에는 사용량과 기능 제약이 존재했다. 반면 Codex는 최초 계획 수립, 구현, 이슈 정리, 병합 충돌 해결 등 실행과 연속성 측면에서 강점을 보였고, Claude는 상세 계획 수립과 리뷰, PR 검토 등 정교한 검토와 품질 보증 측면에서 가장 안정적이었다.