블로그로 돌아가기
DevOps

ClaudeThink — 에이전트 오케스트레이션을 제품처럼 다듬기

2026.04.29·4분 소요·1회 조회
S시리즈 · 1 / 1

ClaudeThink

1ClaudeThink — 에이전트 오케스트레이션을 제품처럼 다듬기

4월 중순에는 최애의 관리자와 별개로 ClaudeThink 작업도 많이 했다. 이쪽은 사용자가 보는 웹 서비스는 아니고, 내가 에이전트로 개발할 때 쓰려고 만든 작업 보조 시스템에 가깝다.

처음에는 프롬프트와 규칙을 잘 정리하면 충분할 줄 알았다. 그런데 실제로 긴 작업을 해보면 문제가 다르다. 에이전트가 어디까지 했는지, 어떤 근거로 다음 작업을 하는지, 컨텍스트가 줄어들기 전에 뭘 남겨야 하는지, 실패한 도구 호출을 어떻게 회수할지 같은 문제가 계속 생긴다.

ClaudeThink는 그 문제를 제품처럼 다뤄보려는 시도였다.

시작은 프롬프트 묶음이 아니라 상태 기록이었다

초기 커밋에서는 config, logger, type, store, plugin manifest 같은 기본 구조를 만들었다. 재미있는 기능은 아니지만, 없으면 뒤가 안 된다.

에이전트 작업에서 제일 답답한 순간은 “아까 뭘 하다 말았지?”가 사라지는 때다. 사람은 대충 기억으로 이어가지만, 에이전트는 컨텍스트가 잘리면 그 기억이 사라진다. 그래서 세션 상태, handoff, lore, checkpoint 같은 것들을 남기는 구조가 필요했다.

이때 만든 hook runtime과 MCP server도 같은 맥락이다. 대화 밖에서 작업 상태를 기록하고, 다시 읽고, 필요하면 회수할 수 있어야 한다.

4월 19일쯤에는 breadcrumb와 headroom 관련 기능을 계속 붙였다.

긴 작업을 하다 보면 컨텍스트가 부족해질 때가 있다. 그때 그냥 요약 한 번 하고 넘어가면 중요한 결정이 빠진다. 그래서 작업 중간의 작은 흔적을 breadcrumb로 남기고, 컨텍스트 여유를 headroom으로 보고, 세션이 끝날 때 pending-lore를 자동으로 잡는 식으로 구조를 만들었다.

말은 거창하지만 목적은 단순했다.

에이전트가 오래 일하다가 갑자기 바보가 되는 순간을 줄이고 싶었다.

Memory Lore v2에서 배운 것

Memory Lore v2 작업을 하면서 제일 신경 쓴 건 “자동 저장”이 아니었다. 오히려 자동 저장은 위험하다.

에이전트가 잘못 이해한 내용을 그대로 기억에 넣으면, 다음 세션에서 더 자신 있게 틀린다. 그래서 lore review, pending state, accept transaction 같은 흐름을 넣었다. 기억은 바로 확정되는 게 아니라 검토되고 받아들여져야 한다.

이 과정에서 PreCompact summariser도 붙였다. 컨텍스트가 압축되기 전에 핵심 내용을 구조화해서 남기고, 나중에 사람이 보거나 에이전트가 다시 읽을 수 있게 하는 기능이다.

개발하면서 느낀 건, 에이전트 메모리는 “많이 저장하기”보다 “나중에 믿어도 되는 형태로 저장하기”가 훨씬 중요하다는 점이다.

출시 전 감사가 꽤 빡셌다

4월 22~23일에는 audit fix 커밋이 계속 이어졌다.

동시성 문제, atomic accept, BEGIN IMMEDIATE, path traversal, typed handoff envelope, stage checkpointer 같은 것들이 나왔다. 로컬 개발 보조 도구라고 해도 파일을 읽고 쓰는 순간 보안 경계가 생긴다.

특히 path traversal은 그냥 넘길 수 없었다. 에이전트 도구는 편의를 위해 파일 경로를 자주 다루는데, 여기서 경계가 약하면 도구 자체가 위험해진다. 그래서 1.0.0을 찍기 전에 이런 차단 이슈를 꽤 많이 닫았다.

이때부터 “에이전트 도구도 제품처럼 감사해야 한다”는 생각이 강해졌다.

CodexThink로 이어진 부분

4월 말에는 New project 쪽에서 CodexThink 2.0.0 작업도 했다.

Design Companion, Agentation MCP, manual design sandbox, route fidelity, visual scale guardrails 같은 것들이 이때 들어갔다. ClaudeThink가 Claude workflow와 memory/lore에 가까웠다면, CodexThink는 Codex 세션에서 디자인 QA와 작업 라우팅을 더 강하게 묶는 쪽이었다.

이 둘은 이름은 다르지만 같은 문제를 보고 있다.

에이전트에게 일을 맡길 때, 단순히 “잘해줘”라고 말하는 것으로는 부족하다. 어떤 문서를 믿어야 하는지, 어떤 파일을 만져도 되는지, 언제 멈춰야 하는지, 결과를 어떻게 검증해야 하는지 시스템이 계속 알려줘야 한다.

지금 돌아보면

ClaudeThink 작업은 블로그에 쓰기 애매한 종류의 개발이다. 화면이 화려하지도 않고, 사용자가 바로 체감하는 서비스도 아니다.

그래도 나한테는 꽤 중요한 프로젝트였다. 에이전트 기반 개발을 계속 하려면 프롬프트만 잘 쓰는 것으로는 부족하다는 걸 확인했기 때문이다. 기록, 검토, 권한 경계, 회수, 압축 전 요약, release gate 같은 것들이 있어야 긴 작업을 믿고 맡길 수 있다.

커밋으로 보면 4월 17일부터 24일까지의 ClaudeThink 작업, 그리고 4월 29일 CodexThink 2.0.0 초기화 작업이 이 글의 범위다.

이전 글

최애의 관리자 — LCP, ISR 비용, 보안까지 다시 본 최적화 기록

다음 글

최애의 관리자 — 티어표, 덱, 거던 플래너를 다시 다듬은 5월 작업