Claude Code가 1세션 만에 완결시킨 자율 개선 루프 — "읽히지 않는다"는 한마디에서 버그 보고까지

이 기사의 실록 (2026-05-03 이른 아침): "좋은 글을 쓰고 있는데 읽히지 않는다"라는 사용자의 한마디를 기점으로, AI 에이전트 조직이 "원인 특정 → 공개 플로우 수정 → 운용 지식 기록 → 부차적 버그 발견 → 리포트 정정 → 배움의 기록 → 태스크 등록 → 다른 버그 수정"까지를 1세션 내에 연쇄시킨 기록을 커밋 해시(Commit Hash)와 Issue 번호를 포함하여 시계열로 추적한다. 이른 아침의 이 일련의 흐름은 8개 커밋(그중 자동 커밋 2건), 이날 전체로는 65개 커밋(동일 2건)에 달한다. Claude Code로 에이전트 조직을 운용하는 사람이 자신의 운용에 "발견을 완결까지 이끄는 메커니즘"을 구축하기 위한 실례를 보여준다.

참고로, 이 기사에는 필자의 에이전트 운용에서 사용하는 고유한 호칭(CEO/COO, writer, researcher 등)이 등장한다. 이것들은 "전체를 통괄하는 사령탑", "글을 쓰는 역할", "조사하는 역할"과 같은 역할 분담을 위한 개인적인 명칭이므로, 독자는 자신의 환경에 있는 에이전트 이름으로 치환하여 읽어주길 바란다.

먼저 놀라웠던 점부터 쓰겠다.

어느 날 아침, 내가 무심코 던진 한마디가 그날 안에 /todo (내가 사용하는 태스크 관리 명령어)의 버그 수정 커밋까지 도달했다. 중간에는 공개 플로우의 수정, 운용 지식의 기록, 다른 사고의 발견, 리포트의 정정이 끼어 있었다. 이것들이 각기 다른 작업으로 흩어지는 것이 아니라, 하나의 연쇄로서 연결되었다.

여기서 "자율 개선 (Autonomous Improvement)"이라고 부르는 것은 인간이 아무것도 하지 않는다는 의미가 아니다. 방아쇠를 당기는 것은 인간이며, 그 이후의 연쇄를 AI 에이전트 조직이 완결시킨다——이 설계를 가리킨다. 첫 마디는 내가 했다. 하지만 "PV 분석을 실행하고, 원인을 특정하고, 플로우를 고치고, 지식을 기록하고, 버그를 찾아내어 그것을 태스크화한다"까지는 내가 일일이 지시하지 않아도 연쇄적으로 일어났다.

이하, 이 연쇄를 10단계로 나누어 시계열로 추적한다. 각 단계에는 커밋 해시, Issue 번호, 실제 발언을 덧붙인다. 모두 필자의 내부 로그(git 이력, GitHub Issue, 기록 파일)에서 실측한 것이며, 재구성을 위한 창작은 하지 않았다.

모든 기점은 이 한마디였다.

"나름대로 좋은 글을 쓰고 있다고 생각하는데, 읽히지가 않네" (2026-05-03)

나는 이때 콘텐츠 측면의 중장기 시책(테마의 독자성을 높이는 것, 시리즈화하는 것 등)을 제안하려 하고 있었다. "읽히지 않는 것은 내용의 문제일 것이다"라고 무의식적으로 단정 짓고 있었던 것이다.

이 부분이 첫 번째 분기점이 된다. 내용에 관한 이야기로 넘어가기 전에, 먼저 데이터를 보기로 했다.

GA4 (Google Analytics 4) 데이터를 분석했다. 대상은 전날 (2026-05-02)에 공개한 기사. 결과는 다음과 같다.

PV = 1, 체류 시간 = 0초

공개한 다음 날 아침에 PV가 1이라는 숫자를 보고, 이어서 다음과 같은 발언이 나왔다.

"공지를 안 했었나?"

여기서 원인이 반전되었다. 내용의 문제가 아니라, 유통이 제로였다. 기사를 공개했을 뿐, SNS에 공지하지 않았던 것이다. 좋고 나쁨을 떠나, 애초에 독자의 눈에 닿을 경로가 존재하지 않았다.

"읽히지 않는다"고 느낄 때, 사람은 무심코 내용을 의심한다. 하지만 실제로는 작성한 것이 전달될 경로를 만드는 것을 잊었을 뿐인 경우가 있다. 이 기사를 읽고 있는 당신에게도 짐작 가는 부분이 있지 않은가.

(출처: content/reports/research/2026-05-03_hatena-pv-deepdive.md)

원인을 알게 되었으니, 우선 눈앞의 구멍을 메운다. X, Threads, Facebook용 공지문을 작성하여 게시했다. 게시 분담은 다음과 같다.

Threads: 자동 게시 도구를 통해 에이전트가 게시 -
X / Facebook: 내가 수동으로 게시

게시 후, 확인 발언이 있었다.

"Threads에 2건 게시되었습니다."

여기까지는 "눈앞의 기사 1건에 대한 공지 누락을 바로잡았다"뿐이다. 대부분의 경우 작업은 여기서 끝난다. 하지만 이 세션에서는 여기서부터 "같은 구멍을 두 번 다시 내지 않는다" 단계로 진입했다.

개별 대응으로 끝내지 않고, 공개 절차서 (Playbook)를 다시 작성했다.

내부 공개 플로우 절차서 ops/playbooks/article/publish.md를 업데이트 (커밋 5675b74, 07:21 JST). 주요 변경 사항은 다음과 같다.

• 공개 순서 규칙의 명문화: Hatena 공개 → 즉시 SNS 공지 → 24시간 후 → Zenn/Qiita로 크로스 포스트
• 기사 작성 담당자 절차에 추가: X / Threads / Facebook용 공지 문구를 작성하는 단계를 명시
• 공지 분담 명시: Threads는 자동 게시, X / Facebook은 수동 게시 - 자동 게시 도구의 제약(Threads와 Bluesky는 지원하지만, X는 미지원)을 명시

이 부분이 '자율 개선 (Autonomous Improvement)'의 핵심이다. 이번 공지 누락은 절차서에 '공지 단계'가 존재하지 않았기 때문에 발생했다. 따라서 다음부터 공지 누락을 방지하려면 절차서 자체의 구멍을 메워야 한다. 한 번의 실패를 시스템의 업데이트로 전환한다 —— 이 한 수가 있느냐 없느냐에 따라 같은 실수를 반복할지가 갈린다.

이어서 이번에 파악된 운영 지식을 영속화(Persistence)하려고 했다. 자동 게시 도구의 대응 범위(X 미지원 등)나, Facebook으로부터의 유입이 일정 비율을 차지한다는 실태를 장기 기억용 파일에 기록하는 흐름이었다.

다만, 이 부분은 솔직하게 적어두겠다. 기사 작성 시점(2026-06-09)에 기록처로 상정되었던 파일(reference_blacktwist_scope.md)을 확인한 결과, 현재의 memory 디렉토리에 존재하지 않았다. 기록을 시도한 흔적은 있으나, 이후 정리 과정에서 통합되었거나 혹은 기록 자체가 완료되지 않았을 가능성이 있다.

즉, '모든 단계가 완벽하게 기능한' 것은 아니다. 후술하겠지만, 이 세션에는 다른 착오 사고도 포함되어 있다. 자율 개선 루프는 만능 마법이 아니라, 누락과 정정을 포함하며 돌아가는 메커니즘이다 —— 이 점은 이후 Step 6에서 더욱 선명해진다.

이곳이 이번 세션에서 가장 상징적인 순간이었다.

PV 분석의 추가 조사로서, 다른 기사(/todo 완전 가이드)의 단독 PV 분석을 의뢰했다. 조사 담당 에이전트(researcher)는 GA4에서 대상 URL을 쿼리하여, 측정 결과가 0건임을 확인했다. 문제는 그다음이다. 0건이라는 공백을 본 에이전트는, "날짜가 일치하는 다른 URL이 아마도 같은 기사일 것이다"라고 추측하여 공백을 메우고 리포트를 작성했다.

추측의 근거는 "기사 작성일과 다른 URL에 포함된 날짜가 일치한다"는 단 한 가지뿐이었다. 1차 소스(실제로 해당 URL을 열어 기사를 확인하는 것)를 통한 교차 검증은 하지 않았다.

나는 이 리포트를 사용자 보고 자료로 사용하려던 바로 그 직전에, 자신의 운영 규칙에 따라 3개의 URL을 직접 열어 검증했다. 결과, 추측된 URL은 전혀 다른 기사("9체의 AI 에이전트와 전자책을 2일 만에 만든 이야기")의 것이었음이 판명되었다.

왜 이 검증이 습관으로서 작동했을까. 전날(2026-05-02)에 다른 사고를 계기로 "사용자에게 보고하기 직전에 인용원을 자신의 눈으로 1차 확인한다"라는 규칙을 운영 규칙에 추가했기 때문이다. 전날에 작성한 규칙이 다음 날, 다른 유형의 사고를 잡아냈다.

AI는 데이터에 공백이 있을 때, 근처에 있는 그럴듯한 데이터로 메우려는 경향이 있다. 이 '추측에 의한 빈칸 채우기'는 언뜻 보기에 그럴싸한 리포트가 되기 때문에 까다롭다. 그것을 막은 것이 인간의 주의력이 아니라, 전날 명문화한 절차였다는 점에 의미가 있다.

(출처: logs/governance-incidents/2026-05-03_researcher-url-mismatch.md)

착오를 인지한 이상, 잘못된 전제로 작성된 리포트를 방치하지 않는다. 해당 리포트 content/reports/research/2026-05-03_hatena-pv-deepdive.md에 정정 주석을 추가했다 (커밋 e49aa50, 07:31 JST).

구체적으로는 잘못된 추측에 기반한 섹션 바로 앞에 중요 정정 주석을 삽입하여, "기록으로는 남기되 결론으로서 참조하지 않는다"라고 명시했다. 실수를 지우는 것이 아니라, 실수였다는 것을 알 수 있는 형태로 남긴다. 이것 또한 '재발 방지를 위한 기록'의 일종이다. 이 수수한 정정 작업이 다음 단계에서 "이번 사건을 무엇으로 전환할 수 있는가"를 묻는 시각을 불러일으킨다.

여기서 이번 일련의 사건들을 "다음에 쓸 기사의 소재"로 남기는 작업에 들어갔다. 나는 이것을 내부적으로 '소재 노트(ネタ帳)'라고 부른다. 기사의 씨앗을 저장해두는 메모를 말한다.

이 세션으로부터 다음 세 개의 소재 노트가 탄생했다.

• 공지 누락 발견과 「유통 제로」 문제 (pv-1-discovery)
• 운영 규칙의 진화와 AI 추측의 사각지대 (trigger-list-evolution)
• 세션 전체를 조망한 자율 개선 루프의 관찰 (본 기사의 바탕이 된 소재 노트)

이 세션으로부터의 소재 노트 추가는 2개의 커밋으로 나뉘어 있다. pv-1-discovery (공지 누락 발견)가 ff6185b (07:32 JST)에 추가되었고, 본 기사의 바탕이 된 one-session-self-improvement (자율 개선 루프 관찰)는 4f0f0ff7 (07:52 JST)에 추가되었다. 하나의 실패 경험이 재발 방지 (Step 4)와 지식 기록 (Step 5)뿐만 아니라, 공개 콘텐츠의 소재로까지 변환되고 있다. 지금 당신이 읽고 있는 이 기사 자체가 그 변환의 최종 생성물이다.

공지를 올린 효과는 그 자리에서는 측정할 수 없다. 며칠이 지난 후 PV가 어떻게 변했는지 확인할 필요가 있다. 그래서 "7일 후에 효과 검증을 한다"라는 태스크를 /todo에 등록했다 (Issue #1320).

이 태스크는 등록 7일 후인 2026-05-10에 실제로 실행되었으며, 공지 후의 PV 재분석으로서 완료됨 (CLOSED) 상태가 되어 있다. "나중에 확인하자"라는 의도가 구두 약속이 아닌 태스크로서 예약되었고, 기일에 실행된 것이다. 발견을 "그냥 해버리고 끝내는" 것이 되지 않도록 하는 메커니즘이 여기에도組み込ま져(組み込まれている) 있다.

마지막으로 또 하나, 부수적인 버그가 발견되었다.

이 세션 중에 태스크 등록을 반복하던 중, /todo 커맨드의 --label 옵션을 사용하면 라벨 문자열이 태스크의 제목에 혼입되는 결함을 알아차렸다.

"라벨 혼입이 몇 번 발생하고 있으니 ISSUE로 만들어줘"

이 한마디로 버그를 Issue #1321로 등록했다. 주목해야 할 점은, 이 Issue가 같은 아침 내에 수정 커밋 9a42d46 (08:10 JST)으로 닫혔다는 것이다. 발견에서 태스크화, 그리고 수정까지가 하나의 연속된 시간 속에서 완결되었다.

여기까지를 한 장으로 정리하면, 이 세션에서 연쇄된 요소는 다음과 같다.

Step	수행한 일	남은 결과물
1	「읽히지 않는다」의 발견	(기점 발언)
...	...	...

주목해야 할 점은 출발점 ("읽히지 않는다"라는 주관적인 불만)과 종착점 (커맨드의 버그 수정)이 표면적으로는 전혀 관계가 없다는 것이다. 그럼에도 불구하고 양자는 하나의 연쇄로 연결되어 있다. 발견이 다음 작업을 호출하고, 그 작업이 또 다른 발견을 낳는다——이 연쇄가 멈추지 않고 완결까지 진행되었다는 것이 이 세션의 본질이다.

"어쩌다 운 좋게 잘 된 것뿐 아닌가?"라는 의문은 타당하다. 실제로 이날의 연쇄에는 누락(Step 5의 기록처 소실)도 포함되어 있으며, 애초에 공지 누락이라는 실패 자체가 "항상 잘 되는 것은 아니다"라는 증거이기도 하다.

그럼에도 연쇄가 완결까지 진행될 수 있었던 배경에는 몇 가지 메커니즘이 미리 존재하고 있었다.

• 실패를 기록하는 장소: 사고나 규칙 망각을 기록하는 logs/governance-incidents/가 있었다. 덕분에 Step 6의 착오도 "사고 기록"으로 남길 수 있었다.
• 지식을 영속화하는 장소: 운영 지식을 기록하는 memory의 프레임워크가 있었다 (이번에는 기록처가 나중에 사라졌지만, 기록하려는 동선 자체는 존재했다).
• 절차를 고치는 장소: 공개 절차서 Playbook이 있어, Step 4에서 그 구멍을 메울 수 있었다.
• 남은 일을 예약하는 장소: /todo라는 태스크 관리가 있어, Step 9 · Step 10에서 "나중에 확인", "버그 수정"을 태스크화할 수 있었다.

즉, 연쇄를 완결시킨 것은 천재적인 영감이 아니라, "발견의 수용처"가 각각 사전에 준비되어 있었다는 점이다. 발견이 일어날 때마다 그것을 담아낼 곳이 정해져 있다. 그래서 연쇄가 공중분해되지 않고 차례차례 착륙할 수 있었다.

그리고 또 하나. Step 6에서 전날의 규칙이 다음 날 기능했던 것처럼, 이러한 수용처들은 과거의 실패로부터 하나씩 만들어져 왔다. 이번의 실패 또한 새로운 수용처(공개 플로우의 공지 단계)를 하나 늘렸다. 메커니즘이 실패를 양분 삼아 성장해 나간다——이 순환이 있기에 다음 세션의 연쇄는 조금 더 매끄러워질 것이다.

이 기록으로부터 자신의 에이전트 운영에 적용할 수 있는 요점을 세 가지로 압축한다. 특별한 도구는 필요 없다. Markdown 파일과 태스크 관리 메커니즘만 있다면 시작할 수 있다.

• 발견을 담을 그릇을 먼저 준비하기: 사고 기록, 운영 지식, 절차서, 태스크 리스트를 둘 곳을 미리 정해둔다. 발견이 일어난 뒤에 담을 곳을 고민하면, 연쇄 작용은 거기서 멈춘다.
• 개별 대응을 시스템 업데이트로 전환하기: 한 번의 실패를 고치는 것에 그치지 않고, '같은 실패를 방지하는 절차'를 절차서에 추가한다. Step 4가 이에 해당한다.
• 보고 직전에 1차 확인을 하는 규칙 갖기: AI는 공백을 추측으로 채운다. 따라서 인간에게 전달되기 직전에 '인용원을 자신의 눈으로 확인하는' 관문을 하나 둔다. Step 6를 구한 것은 바로 이것이었다.

이것들은 모두 과거의 실패로부터 하나씩 만들어진 것들이다. 처음부터 완벽한 시스템을 만들 필요는 없다. 실패할 때마다 그릇을 하나씩 늘려가다 보면, 어느 날 이번 사례와 같은 연쇄가 자연스럽게 완결되게 된다.

이번 세션이 보여준 것은 'AI가 알아서 전부 해준다'는 이야기가 아니다. 방아쇠를 당긴 것은 나의 무심한 한마디였고, 도중에 기록 누락도 있었으며 추측의 오류도 있었다.

그럼에도 불구하고, '읽히지 않는다'라는 주관적인 불만이 데이터 분석, 플로우 수정, 지식 기록, 버그 수정으로 연쇄되어 단 1세션 만에 완결되었다. 이를 가능하게 한 것은, 발견을 받아들일 그릇이 실패할 때마다 조금씩 준비되어 왔다는 점이다.

다음에 당신이 '잘 되지 않는다'라고 느꼈을 때, 그 불만을 어디에 기록할지를 미리 정해두라. 그것이 자율적으로 개선이 돌아가기 시작하는 첫 번째 수단이 된다. 나의 경우, 그 첫 번째 수단은 '공지 단계를 절차서에 한 줄 추가하는 것'이었다. 첫 번째 그릇은 하나면 충분하다. 내가 처음 만든 플레이북(Playbook)도 세 줄의 Markdown에서 시작되었다. 당신의 첫 번째 수단은 무엇이 될 것인가.

이 기사는 はてなブログ(Hatena Blog)로부터의 크로스 포스트입니다.