개발자들은 최근 Codex가 다음과 같은 경로에 방대한 양의 진단 데이터를 지속적으로 기록하고 있다는 점에 대해 논의해 왔습니다:

~/.codex/logs_2.sqlite

눈에 보이는 데이터베이스 크기는 비교적 작게 유지될 수 있지만, 백그라운드에서 SQLite WAL (Write-Ahead Logging) 파일에는 빈번한 쓰기 작업이 계속 발생합니다.

일부 사용자들은 다음과 같은 현상을 보고했습니다:

• 과도한 SSD 쓰기;
• 급격히 증가하는 WAL 파일;
• 느려진 응답 속도;
• 잠금 경합 (lock contention);
• 시작 또는 세션 신뢰성 문제.

한 가지 비공식적인 해결 방법(workaround)은 로깅 테이블로의 새로운 삽입(insert)을 무시하는 SQLite 트리거(trigger)를 추가하는 것입니다.

이는 디스크 쓰기 문제를 줄여줄 수 있습니다.

하지만 이는 더 깊은 구조적 질문을 던집니다:

에이전트의 내부 로그를 비활성화한다면, 프로젝트를 계속 진행하는 데 필요한 메모리는 무엇이 보존해 주는가?

진단 로그와 프로젝트 메모리는 동일한 것이 아닙니다.

에이전트의 내부 로그는 주로 에이전트 애플리케이션 자체를 위해 설계되었습니다.

로그에는 다음과 같은 내용이 포함될 수 있습니다:

• 네트워크 이벤트 (network events);
• 트레이스 출력 (trace output);
• 런타임 상태 전이 (runtime state transitions);
• 저수준 디버깅 정보 (low-level debugging information);
• 내부 운영 세부 사항.

이러한 로그들은 Codex를 진단하는 데 유용할 수 있습니다.

하지만 내일 당신의 프로젝트를 재개할 다음 코딩 에이전트에게 반드시 필요한 것이라고 할 수는 없습니다.

다음 에이전트는 보통 훨씬 더 작고 의미 있는 정보들을 필요로 합니다:

• 현재의 기준점(ground truth)이 되는 파일은 무엇인가?
• 어떤 결정이 내려졌는가?
• 왜 그 결정이 내려졌는가?
• 어떤 접근 방식들이 이미 실패했는가?
• 어떤 증거가 검증되었는가?
• 무엇이 미완성 상태로 남아 있는가?
• 다음에 무엇이 일어나야 하는가?

이것이 바로 프로젝트 연속성 (project continuity)입니다.

이는 진단 텔레메트리 (diagnostic telemetry)가 아닙니다.

로그를 차단하면 어떤 일이 발생할까요?

트리거를 이용한 해결 방법은 Codex의 로컬 로깅 데이터베이스에 새로운 행(row)이 삽입되는 것을 중단시키려 시도합니다.

의도된 운영 효과는 명확합니다:

• 반복적인 SQLite 쓰기 감소;
• WAL 성장 지연 또는 중단;
• SSD 부하 감소;
• 잠재적인 응답성 향상.

하지만 이는 여전히 Codex의 내부 데이터베이스 동작을 수정하는 비공식적인 해결 방법일 뿐입니다.

진단 가시성 (diagnostic visibility)이 감소할 수 있습니다.

향후 Codex 스키마 마이그레이션 (schema migration) 이후에 동작이 달라질 수 있습니다.

디버깅 (debugging)을 방해할 수 있습니다.

보장되거나 영구적인 해결책으로 제시되어서는 안 됩니다.

더 중요한 것은, 이를 프로젝트 메모리 (project-memory) 전략으로 취급해서는 안 된다는 점입니다.

Codex 로깅이 완벽하게 작동하더라도, 내부 진단 데이터베이스 (internal diagnostic database)는 지속적인 프로젝트 연속성을 위해 의존하기에는 여전히 잘못된 장소입니다.

그 스키마 (schema)는 Codex의 소유입니다.

그 보존 정책 (retention policy)은 Codex의 소유입니다.

그 형식 (format)은 Codex와 함께 변경될 수 있습니다.

그 목적은 Codex가 스스로를 운영하고 진단하는 것을 돕는 것이지, 다음 에이전트 (agent)에게 필요한 가장 작은 검증된 컨텍스트 (context)를 보존하는 것이 아닙니다.

진정한 성능 격차는 연속성 성능 (continuity performance)입니다.

개발자들이 "에이전트 성능"이라는 말을 들을 때, 보통 다음과 같은 것들을 생각합니다:

• 모델 품질 (model quality);
• 응답 속도 (response speed);
• 토큰 사용량 (token usage);
• 도구 실행 (tool execution);
• 지연 시간 (latency).

그만큼 중요한 또 다른 종류의 성능이 있습니다:

새로운 세션이 얼마나 빨리 정확한 컨텍스트를 복구하고 작업을 계속할 수 있는가?

저는 이를 연속성 성능 (continuity performance)이라고 부릅니다.

결정을 다시 내리는 데 20분을 소비하거나, 잘못된 파일을 다시 열거나, 실패한 실험을 반복하거나, 프로젝트의 현재 상태를 오해하는 빠른 모델은 프로젝트 수준에서 잘 작동하고 있는 것이 아닙니다.

이는 다음과 같은 상황에서 특히 두드러집니다:

• 원래 세션이 사라졌을 때;
• 컨텍스트가 압축되었을 때;
• 트랜스크립트 (transcript)가 너무 클 때;
• 에이전트가 변경되었을 때;
• 로컬 로그가 삭제되었을 때;
• 내부 데이터베이스가 비활성화되었을 때;
• 도구가 저장 형식을 변경했을 때.

문제는 모든 추적 이벤트 (trace event)가 사라졌다는 것이 아닙니다.

문제는 다음 에이전트가 무엇이 중요한지 더 이상 알지 못한다는 것입니다.

QiJu의 역할

QiJu는 현재 PyPI에서 공개적으로 사용할 수 있습니다:

uv tool install qiju

이는 AI 코딩 에이전트를 위한 로컬 우선 (local-first), 무손실 기록 레이어 (lossless record layer)입니다.

다음과 함께 작동합니다:

• Claude Code;
• Codex;
• Kiro;
• Cursor.

QiJu는 모든 대화 줄이나 모든 도구 이벤트를 보존하려고 시도하지 않습니다.

QiJu는 작업이 계속될 수 있도록 허용하는 더 작은 사실 집합을 의도적으로 기록합니다:

• 실제 정답(ground-truth) 파일 또는 아티팩트 (artifact);
• 내려진 결정;
• 이를 뒷받침하는 근거;
• 검증된 결과;
• 해결되지 않은 리스크;
• 다음 행동.

이후의 Codex 세션—또는 Claude Code, Kiro, 또는 Cursor—은 해당 기록을 검색하여 올바른 상태에서 작업을 계속할 수 있습니다.

목표는 이전 세션 전체를 재구성하는 것이 아닙니다.

목표는 다음 에이전트가 올바르게 작업을 이어갈 수 있도록 돕는 것입니다.

QiJu는 "메모리"가 아닙니다.

이 구분은 중요합니다.

QiJu는 모델이 더 많은 것을 기억하게 만들지 않습니다.

그것은 명시적인 기록 계층 (explicit record layer)을 생성합니다.

일반적인 에이전트 메모리 (agent memory)는 다음을 답하려고 시도합니다:

모델이 무엇을 기억하는가?

QiJu는 다음을 답하려고 시도합니다:

• 우리는 이것을 왜 알고 있는가?
• 증거는 어디에 있는가?
• 누가 결과를 생성했는가?
• 그것이 검증되었는가?
• 다음에 무엇이 일어나야 하는가?
• 어떤 에이전트가 계속해야 하는가?

이는 작업이 한 도구의 내부 회상 (internal recall) 속에 갇히는 대신, 감사 가능하고 (auditable) 인계 가능하게 (handoffable) 만듭니다.

이를 생각하는 유용한 방법은 다음과 같습니다:

Codex 로그는 Codex에게 내부적으로 무슨 일이 일어났는지 알려줍니다.
QiJu는 다음 에이전트에게 작업을 계속하는 데 무엇이 중요한지 알려줍니다.

실제 사례

Codex 세션이 패키징 마이그레이션 (packaging migration)을 막 마쳤다고 가정해 봅시다.

작업 중에 에이전트는 다음 사항들을 발견했습니다:

• 공개 패키지는 src/qiju/로 이동해야 함;
• pyproject.toml은 버전 권위 (version authority)로 유지되어야 함;
• 런타임 JSON은 패키지 리소스 (package resources)를 통해 로드되어야 함;
• CLI를 삭제하더라도 사용자 기록은 보존되어야 함;
• 지원되는 모든 코딩 에이전트 호스트는 설치된 휠 (installed-wheel) 테스트를 통과해야 함.

전체 대화 기록 (transcript)에는 이러한 결론을 둘러싼 수만 개의 단어가 포함될 수 있습니다.

지속 가능한 프로젝트 기록은 이보다 훨씬 작을 수 있습니다:

Ground truth (실제 값):
design/pypi-packaging-execution-plan.md
Decision (결정):
소스 및 PyPI 설치를 위해 하나의 정전적 (canonical) src/qiju 패키지를 사용함.
Verified (검증됨):
Wheel 및 sdist가 아티팩트 검사 (artifact inspection) 및 설치된 wheel 스모크 테스트 (installed-wheel smoke tests)를 통과함.
Rejected (기각됨):
스테이징 빌드 (staging build) 중에만 스크립트를 qiju로 이름을 변경하는 방안.
Next (다음 단계):
TestPyPI에 게시하고 클린 설치 라이프사이클 테스트 (clean-install lifecycle test)를 반복함.

이것만으로도 다음 에이전트가 적절한 파일을 찾고, 결정을 이해하며, 올바른 지점에서 작업을 계속하기에 충분합니다.

모든 추적 메시지 (trace message)가 필요한 것은 아닙니다.

필요한 것은 올바른 기록입니다.

새로운 업데이트 문제

PyPI를 통해 QiJu가 설치되면, 사용자는 다음 명령어로 CLI를 업그레이드할 수 있습니다:

uv tool upgrade qiju

하지만 이는 또 다른 미묘한 문제를 발생시킵니다.

기존 프로젝트 내부에 복사된 SKILL.md 파일들은 그대로 오래된 상태(stale)로 남아 있는 동안 CLI만 업데이트될 수 있기 때문입니다.

이러한 스킬 (skills)들은 Claude Code, Codex, Kiro, 그리고 Cursor에게 QiJu를 호출하는 방법을 알려줍니다.

따라서 실행 파일만 업그레이드하는 것으로는 충분하지 않습니다.

QiJu 0.5.3에는 다음이 추가되었습니다:

qiju update

이 명령은 등록된 프로젝트 전반에 걸쳐 설치된 QiJu 스킬들을 새로고침합니다.

전형적인 사용법:

uv tool upgrade qiju
qiju update

변경 사항을 미리 볼 수도 있습니다:

qiju update --dry-run

하나의 호스트만 새로고침하려면:

qiju update --host codex

또는 레지스트리 (registry)가 존재하기 전에 생성된 오래된 프로젝트들을 스캔하고 백필 (backfill)하려면:

qiju update --scan-projects

이것이 중요한 이유는 연속성 (continuity)이 기록을 보존하는 것뿐만 아니라, 에이전트 통합 (agent integration) 자체를 최신 상태로 유지하는 것에도 달려 있기 때문입니다.

프로젝트 등록 방식

프로젝트에서 QiJu를 초기화할 때:

cd /path/to/project
qiju init --host codex

QiJu는 프로젝트 위치를 등록합니다.

각 프로젝트 고유의:

.qiju/config.json

은 어떤 호스트가 활성화되어 있는지에 대한 신뢰할 수 있는 정보원 (source of truth)으로 남습니다.

레지스트리는 QiJu에게 프로젝트가 어디에 있는지 알려줍니다.

프로젝트 설정 (config)은 QiJu에게 각 프로젝트가 어떻게 연결되어 있는지 알려줍니다.

이러한 분리 덕분에 qiju update는 휴리스틱 파일 시스템 스캔 (heuristic filesystem scans)에만 의존하지 않고도 프로젝트를 새로고침할 수 있습니다.

또한 이는 초기화(initialization) 중에 등록되었다면, 표준 검색 루트(standard search roots) 외부에 있는 프로젝트들도 여전히 업데이트될 수 있음을 의미합니다.

이전 설치 버전의 경우, 하나의 마이그레이션(migration) 명령이면 충분합니다:

qiju update --scan-projects

그 이후에는 일반적인 업데이트를 빠르고 결정론적(deterministic)인 상태로 유지할 수 있습니다.

QiJu가 수행하지 않는 것

QiJu는 다음을 수행하지 않습니다:

• Codex의 SQLite 로깅(logging) 동작 수정
• 자체적인 SSD 쓰기 중단
• Codex 진단(diagnostics) 대체
• 비공식 데이터베이스 트리거(database trigger)의 안전성 보장
• Codex 대화 인터페이스(conversation interface) 보존
• 이전 세션의 모든 내부 이벤트(internal event) 재현
• 모든 트랜스크립트(transcripts) 또는 프롬프트(prompts)를 조용히 수집
• 임베딩(embeddings) 또는 벡터 메모리(vector memory) 사용

캡처(Capture)는 의도적인 것입니다.

사용자—또는 사용자의 지시를 받는 에이전트(agent)—가 무엇을 기록할 가치가 있는지 결정합니다.

그 경계는 중요합니다.

QiJu는 또 다른 백그라운드 로거(background logger)가 아닙니다.

그것은 정반대입니다: 중요한 것에 대한 의도적이고 검사 가능한 기록입니다.

실제 워크플로 (A real workflow)

QiJu 설치:

uv tool install qiju

프로젝트에 연결:

cd /path/to/project
qiju init --host codex

세션 중에 에이전트에게 중요한 것을 기록하도록 요청하십시오:

$qiju-log

나중에, 다른 세션이나 다른 에이전트에서:

$qiju-search the last packaging decision

QiJu 업그레이드 후:

uv tool upgrade qiju
qiju update

이렇게 하면 CLI와 설치된 에이전트의 기술(skills)을 모두 최신 상태로 유지할 수 있습니다.

로그를 비활성화한 후 이것이 중요한 이유

SQLite 트리거 우회책(workaround)을 적용하여 Codex가 대부분의 로컬 진단 이벤트(diagnostic events)를 쓰는 것을 중단한다고 가정해 봅시다.

운영 측면에서 이는 디스크 압박(disk pressure)을 줄일 수 있습니다.

하지만 이제 분리가 명확해집니다:

Codex 진단 (Codex diagnostics)
→ 감소하거나 사용 불가
QiJu 프로젝트 기록 (QiJu project records)
→ 여전히 사용 가능
실제 데이터 파일 (Ground-truth files)
→ 여전히 참조됨
결정 사항 (Decisions)
→ 여전히 검색 가능
다음 단계 (Next steps)
→ 여전히 복구 가능

다음 에이전트는 이전 Codex 실행의 모든 내부 이벤트를 알지 못할 수도 있습니다.

그럴 필요도 없습니다.

에이전트에게 필요한 것은 다음과 같습니다:

• 무엇이 결정되었는가;
• 왜 결정되었는가;
• 증거가 어디에 있는가;
• 무엇이 검증되었는가;
• 다음에 무엇을 해야 하는가.

이것이 바로 QiJu가 Codex의 내부 로깅 (logging)이 제한되거나 삭제된 상황에서도 연속적인 성능 (continuity performance)을 유지하도록 돕는 방식입니다.

더 넓은 관점에서의 설계 교훈

Codex 로깅 문제는 개발자들이 종종 여러 가지 서로 다른 종류의 메모리 (memory)를 혼용한다는 점을 상기시켜 줍니다:

1. 진단 (Diagnostics) — 애플리케이션 내부에서 무엇이 일어났는가.
2. 대화 기록 (Conversation history) — 사용자와 에이전트가 무엇을 말했는가.
3. 저장소 상태 (Repository state) — 코드베이스에 현재 무엇이 존재하는가.
4. 결정 이력 (Decision history) — 프로젝트가 왜 현재 상태에 도달했는가.
5. 연속 문맥 (Continuation context) — 다음 에이전트가 다음에 무엇을 해야 하는가.

단일 SQLite 로그, 트랜스크립트 (transcript), 또는 Git 저장소만으로는 이 다섯 가지를 모두 온전히 나타낼 수 없습니다.

Git은 무엇이 변했는지는 보여줄 수 있지만, 항상 왜 변했는지를 보여주지는 못합니다.

트랜스크립트는 이유를 보여줄 수 있지만, 규모가 너무 크거나 특정 도구에 종속될 수 있습니다.

진단 로그 (Diagnostic logs)는 런타임 동작 (runtime behavior)을 보여주지만, 프로젝트 관점에서는 대부분 노이즈 (noise)를 포함하고 있습니다.

지속 가능한 에이전트 워크플로우 (agent workflow)에는 명시적인 프로젝트 기록 계층 (project record layer)이 필요합니다.

현재의 한계

QiJu는 아직 개발자 프리뷰 (developer preview) 단계입니다.

이 글을 작성하는 시점을 기준으로:

• macOS 및 Linux를 지원합니다.
• Windows는 아직 지원되거나 테스트되지 않았습니다.
• 캡처 (capture)는 자동이 아닌 의도적인 방식입니다.
• 검색 (retrieval)은 결정론적인 키워드, 태그 및 정규 표현식 (regex) 검색입니다.
• 임베딩 (embeddings)이나 의미론적 순위 지정 (semantic ranking)은 없습니다.
• CLI 및 호스트 와이어링 (host wiring)은 여전히 진화 중일 수 있습니다.

이러한 한계는 의도된 것입니다.

현재의 우선순위는 신뢰성 (reliability), 검사 가능성 (inspectability), 그리고 소유권 (ownership)입니다.

나의 결론

노이즈가 많은 Codex 로그를 차단하는 것은 과도한 디스크 쓰기 (disk writes)에 대한 합리적인 임시 대응이 될 수 있습니다. 단, 사용자가 이것이 비공식적이며 진단 (diagnostics)에 영향을 미칠 수 있음을 이해한다는 전제하에 말입니다.

하지만 더 깊은 결론이 더 중요합니다:

에이전트의 내부 로그가 비활성화되거나, 삭제되거나, 손상되거나, 혹은 재설계되더라도 당신의 프로젝트 메모리는 사라져서는 안 됩니다.

Codex 로그는 Codex에게 내부적으로 무슨 일이 일어났는지를 알려줍니다.

QiJu는 다른 에이전트가 작업을 계속하는 데 필요한 실체적 진실 (ground truth), 결정, 증거, 그리고 다음 단계를 기록합니다.

이러한 분리 (separation)를 통해 프로젝트의 연속성을 희생하지 않으면서도 내부 진단 로그에 대한 의존도를 줄일 수 있습니다.

QiJu를 지금 바로 사용해 보세요:

uv tool install qiju

프로젝트 페이지:

https://pypi.org/project/qiju/

소스 코드:

https://github.com/jasonshrepo/qiju

QiJu(起居)가 마음에 드신다면 Star를 눌러주세요.

제가 가장 관심을 두고 있는 질문은 이것입니다:

만약 내일 당장 당신의 코딩 에이전트 (coding agent)의 내부 기록을 더 이상 신뢰할 수 없게 된다면, 다른 에이전트가 올바르게 작업을 이어갈 수 있도록 무엇을 보존하시겠습니까?