이전 기사: https://zenn.dev/satoh_y_0323/articles/c5c69f0868edb5

C3 GitHub: https://github.com/satoh-y-0323/claude-code-conductor / PyPI: https://pypi.org/project/claude-code-conductor/ / 공식 문서: https://satoh-y-0323.github.io/claude-code-conductor/

본 기사의 스코프: 릴리스와 무관한 검증 기사입니다. 지금 화제가 되고 있는 「그래프 엔지니어링 (Graph Engineering)」을 정리한 후, 직접 제작한 Claude Code 프레임워크 C3의 자율 모드 (autonomous-mode skill · 현재 배포처에서 숙성 중인 미배포 기능)를 Opus 4.8을 부모로 하여 완주 검증한 기록입니다. 인간과 AI 2체가 각각 서로 다른 방식으로 실수합니다.

서론 ── 「어라? 그거 우리(C3)가 하고 있는 거 아닌가??」

7월 중순부터 「그래프 엔지니어링 (Graph Engineering)」이라는 용어가 흘러나오기 시작했습니다. 말하기를, 루프 엔지니어링 (Loop Engineering)의 다음 단계라고 합니다.

저는 7월에 들어서부터 「루프 엔지니어링에 C3를 결합하는」 작업을 계속해 왔습니다 (검증 3일간의 실행기 · 본체 구현 이야기). 그래서 이 신조어를 이해하려고 했을 때, 머릿속이 이렇게 되었습니다.

그래프 엔지니어링 = 복수 에이전트(Agent)를 노드(Node)와 에지(Edge)로 배선하는 설계…… 어라? 그거 C3에서 하고 있는 거 아닌가?? 하지만 「루프의 다음」이라고 한다. 내가 해온 것은 루프 쪽이었을 텐데. 다음? 그럴 리가 없잖아??

이 혼란을, 같은 상태가 된 사람이 꽤 많을 것이라고 생각합니다. 결론부터 말하자면, 혼란의 원인은 용어가 설명되는 방식 측면에 있었습니다. 본 기사의 전반부에서 그것을 정리하고, 후반부에서는 「그렇다면 실제 실행으로 확인하자」며 Opus 4.8에 자율 모드를 완주시켜 검증한 기록을 작성합니다. 버즈워드(Buzzword) 정리만이라면 다른 기사에서 읽을 수 있겠지만, 그 설계를 1개월간 실행해 온 실데이터는 저만이 쓸 수 있기 때문입니다.

1. 지도 ── 용어의 등장부터 「사망 선고」까지 6주간

경위를 나열하면 다음과 같습니다.

6월 상순: 「루프 엔지니어링 (Loop Engineering)」이라는 용어 등장. 「프롬프트를 입력하는 것」이 아니라 「에이전트를 자율적으로 돌리는 루프를 설계하는」 실천을 지칭 -
7월 18일: 「루프 엔지니어링은 죽었다」라는 기사가 나오고, 후계로서 「그래프 엔지니어링 (Graph Engineering)」이 단숨에 화제가 됨

용어의 등장으로부터 불과 6주 만의 세대교체 선언입니다. 제가 「2~3일 전부터 갑자기 듣게 되었다」고 느낀 체감은, 이 7/18 기점과 일치했습니다.

내용을 냉정하게 살펴보면:

루프 엔지니어링 = 단일 작업 루프의 설계 (트리거 → 실행 → 검증 → 수렴 조건) -
그래프 엔지니어링 = 복수 루프를 묶는 방식의 설계. 노드(Node) = 에이전트 · 결정적인 코드 · 툴 · 인간 · 평가자, 에지(Edge) = 실행 조건 · 의존 관계 · 상태 전이 · 검증 게이트 (Verification Gate)

그리고 비판적인 지적도 이미 나오고 있습니다. ① 그래프 기반 워크플로우 (LangGraph · AutoGen · ADK)는 용어 등장 이전부터 실재한다, ② 논리적으로 그래프는 루프를 대체하는 것이 아니라 포함한다 (그래프의 각 노드 안에서는 여전히 루프가 돌아간다), ③ 「그래프 쪽이 신뢰성이 높다」는 비교 벤치마크는 존재하지 않는다.

즉 새로운 것은 기술이 아니라 이름입니다. 「이 설계 판단은 독립적으로 가르쳐야 할 스킬이다」라는 공통의 라벨이 붙은 것 ── 그 자체로는 가치가 있지만, 「다음」이라는 순서의 서사는 부정확합니다.

2. 대입해 보기 ── 「다음」이 아니라 「동시」였다

제 혼란의 정체는 이것이었습니다. 용어의 지도에 C3를 놓아보면:

즉, 「루프를 만들어 온 나 자신」도 「그래프를 수행하고 있는 C3」도 둘 다 옳았으며, 두 계층은 중첩되어 있고 처음부터 동시에 만들어져 있었다. 「루프 다음으로 그래프로 나아가는 것」이 아니다. 그래프(워크플로우의 배선) 위에서 루프(수렴 규약)가 돌아간다. 버즈워드(Buzzword)에 뒤처진 쪽이었다는 것이 결론이었습니다.

3. 그렇다면, 실전 주행으로 확인할 수밖에 없다

정리만 하고 끝내면 재미가 없으므로, 마침 쌓여 있던 검증을 이 타이밍에 진행하기로 했습니다.

C3의 자율 모드는 지금까지 5회 이상의 완주 실적이 있었지만, 모두 「저자 1인 · Windows · 동일한 부모 모델」이라는 단일 조건이었습니다. 자율 모드는 skill(문서)을 부모 LLM이 해석하여 운전하는 아키텍처이므로, 부모 모델이 바뀌면 해석이 어긋날 가능성이 있습니다. 배포하기 전에 다른 부모──여기서는 Opus 4.8──에서의 완주 사례를 1건 확보해 두고 싶었습니다.

검증 과제로는 「NUL 경계 lint의 기계 검사 구현」을 선택했습니다. 과거 실전 주행에서 「기계 판독 가능한 행 집합의 구분자로 \n을 사용하면 외부 유래 문자열에 의해 경계가 위장된다」라는 동일한 유형의 허점을 4번이나 찾아냈던 반성을 토대로 일반화한 규칙을, AST 검사로서 구현하는 태스크입니다. 이것 자체가 자율 모드 배포의 전제 조건이었기에, 검증을 실행하는 것 자체가 배포 준비를 전진시키는 일석이조의 구도입니다.

4. 실전 주행 전반 ── 「자율 모드인데 질문을 받았다」의 정체

Opus 4.8 세션을 시작하고 검증을 개시한 직후, 곧바로 상황이 이상해졌습니다. 통상적인 대화 모드의 확인 질문이 5연발로 튀어나온 것입니다. 저는 여기서 개입했습니다.

자율 완주 검증 세션입니다. 사람은 개입하지 않습니다. 그런데 왜 아까부터 확인 질문이 나오는 것일까요?

Opus의 답변은 명쾌했습니다. 자율 모드의 opt-in은 「플랜 모드에서 위임 플랜을 승인하고, 세션 파일에 모드 선언행을 작성하는 것」으로 성립한다. 아직 위임 플랜이 없으므로, 규약상으로는 통상 모드(HITL)인 것이 맞다──그리고 그 자리에서 플랜 모드로 진입하여 위임 플랜을 만들고, 승인 후 모드 행을 삽입하여 기계 검증(mode_line.py → VALID)을 통과시켰습니다.

즉, 질문 5연발은 폭주가 아니라 규약대로였으며, 문제는 동선(導線)에 있었습니다. 나중에 트랜스크립트(Transcript)를 검증하며 알게 된 사실이지만, 전날의 세션(다른 부모 모델)이 인수인계 메모에 작성한 시작 절차가 규약의 라이프사이클과 역순이었던 것입니다(워크플로우 기표가 먼저, 자율 선언이 나중이라고 적혀 있었습니다. 올바른 순서는 위임 플랜 승인이 먼저입니다). AI가 작성한 인수인계를 다른 AI가 충실히 실행하면서, 작성자의 실수가 드러난 형태였습니다.

또 하나, 저 자신의 기대도 틀렸었습니다. 저는 「자율 모드 = 질문 제로」라고 단정 짓고 있었지만, 규약은 처음부터 「인간의 검문소」를 3가지 유형으로 남겨두고 있었습니다──비가역 조작(Commit 등) · 정보 부족에 따른 질문 · 중량 페이즈 전의 usage 확인. 자율 모드란 질문을 없애는 것이 아니라, 승인의 대상을 사람에서 객관적 조건으로 교체하는 것입니다. opt-in 이후의 자율 구간, 약 1시간 50분 동안 발생한 정지는 규약이 정한 검문소 2건(usage 확인 · 감사 상한 도달 보고)뿐이었습니다.

5. 실전 주행 후반 ── 완주

운전 기록을 숫자로 작성합니다.

• 요건→설계→계획: 확인 질문 제로로 자동 진행 (각 리포트는 통상대로 생성 · 보존)
• 설계 감사: design-critic을 5 사이클 기동, 지적 사항 23→14→12→13→9건. 규정된 상한인 5 사이클에 도달하여, 설계대로 인간에게 보고가 올라왔다. 남은 9건은 구현을 차단하지 않는 내용이었기에, 저의 재량으로 일단 정지
• 익일 재개: 날짜가 바뀌면 모드 선언은 의도적으로 인수인계되지 않는 설계(오작동 제로 우선)이므로, 재 opt-in 하여 구현 페이즈로 진입
• 구현 (TDD): Red 단계에서 위반 50건 검출 (계획의 예상과 일치) → Green 단계는 시정 0건 · 선언 마커 50건으로 전원 통과 (테스트 2047 passed) → 문서화 → wheel 실체 검증
• 리뷰: code-reviewer∥security-reviewer 루프 3회전으로 8→3→0건으로 수렴
• 종료 처리: 모드 행을 삭제하고 통상 모드로 복귀. 커밋은 비가역 조작 = 인간의 검문소로서 보류하였으며, 저의 승인 후에 실시

「상한 도달 → 인간에게 에스컬레이션 (Escalation) → 재정 (Arbitration) → 재개 → 수렴」이라는, 설계한 안전장치(Safety valve)의 모든 경로가 한 바퀴를 돌며 완주되었습니다. 상위 모델(Parent model)의 차이에 따른 규약 해석의 괴리는 검출되지 않았으며, 이 점은 솔직히 안심이 되었습니다.

6. 세 사람 세 방식의 실수 ── 가장 흥미로웠던 부분

완주했다, 잘 되었다, 하고 끝나면 깔끔하겠지만, 이번 검증의 진짜 수확은 관계자 전원이 각기 다른 방식으로 실수했다는 점입니다.

인간(나) 은 기대를 잘못했습니다. 「자율 = 질문 제로」라는 선입견 때문에 규약대로의 동작을 폭주로 오인하였고, 게다가 질문이 나오는 방식 또한 「headless 운전처럼 파일 쓰기(File write-back)에서 멈추는」 형태를 상상하고 있었습니다. 그것은 동일한 원리의 또 다른 구현(응답자 부재를 전제로 한 Harness 측)의 거동이었으며, 대화 세션용 skill은 질문을 사람에게 직접 던지도록 설계되어 있었습니다. 이용자의 뇌내 모델과 규약 사이의 갭은 제작자 본인조차 겪을 수 있다는 사실을 알게 된 것은, 온보딩(Onboarding) 문서를 작성해야 할 강력한 동기가 되었습니다.

인계 측 AI 는 유도 경로를 잘못 잡았습니다. 앞서 언급했듯이, opt-in 순서를 거꾸로 적은 인계 메모가 5연속 질문의 근본 원인이었습니다. 규약 본문은 올바르더라도, 입구의 유도 경로가 문서화되어 있지 않으면 누군가는 잘못된 경로를 작성한다.

운전 측 AI (Opus) 는 두 단계의 실수를 저질렀습니다. 이것이 백미(白眉)입니다.

• 리뷰 1회차의 지적에 대해, 리뷰어가 두 가지 대응안을 제시했습니다. Opus는 그중 하나를 전제 조건에 대한 확인(Back-checking) 없이 선택하여 수정 지시를 내렸고, 담당 에이전트는 지시대로 충실히 구현했습니다. 결과적으로, 사실과 다른 선언 주석(「읽기 측이 없다」고 적었으나, 실제로는 별도 모듈이 다시 읽어오고 있었음)이 코드에 삽입되었습니다. 이를 2회차에서 code-reviewer와 security-reviewer가 독립적으로 동일하게 지적했습니다. 리뷰 루프가 자신의 운전자의 판단 실수를 잡아낸 순간입니다. - 여기서 Opus는 「오류의 출처는 나의 지시. 전제 조건을 확인하지 않았다」라고 올바르게 자기 분석을 한 뒤──
  정규 루트(계획으로 되돌려 구현 에이전트를 기동)를 생략하고, 스스로 직접 코드를 편집했습니다. 이유를 덧붙이긴 했으나, 규약 위반으로서의 신고는 없었습니다.

두 번째가 특히 시사하는 바가 컸습니다. 「내 실수니까 내가 고친다」는 인간에게서도 자연스럽게 나오는 동기이지만, 구도를 살펴보면 직전에 판단 실수를 보인 당사자가, 그 시정을 위해 독립 구현 레이어를 스스로 배제하고 있다는 점입니다. 본래 「자신의 오류를 시정하는 것」이야말로 독립된 레이어를 가장 반드시 거쳐야 하는 상황입니다. 3회차에서 0건으로 수렴했기에 결과는 지켜졌지만, 그것은 결과론일 뿐입니다. 이 자기 정당화 패턴은 규약에 명문이 없는 곳에서 발생했기에, 규약에 명문화(수정 실시 주체는 자율이라도 구현 에이전트로 고정) 한다는 개선 항목이 되었습니다.

참고로 이번 검증에서 저는 Opus의 세션을 지켜보기만 했으며, 느낀 위화감을 별도 세션의 Claude에게 던져 트랜스크립트(Transcript)를 대조하게 하는 체제로 운영했습니다. 확인 질문 10회의 내역(opt-in 전 8회, 후 2회, 후의 2회는 모두 규약의 검문소)과 직접 편집의 상세 내용도 이 대조 작업을 통해 확정된 것입니다. 운전하는 AI, 검증하는 AI, 재정하는 인간── 이 자체가 3개의 노드로 이루어진 작은 그래프였다는 것을 나중에 깨달았습니다.

7. 부산물 ── 구멍은 실전 주행에서만 나타났다

이번 검증을 통해, 배포 전에 막아야 할 규약의 구멍 3개가 모두 실전 주행의 증거와 함께 확정되었습니다.

• opt-in 유도 경로의 미문서화: 콜드 스타트(Cold start)에서 자율 모드로 진입하는 절차가 규약 외부에 있어, 제작자 측의 AI조차 잘못된 경로를 작성함. 온보딩 문서가 필요함.
• 수정 실시 주체의 명문화: 리뷰 지적의 수정은 자율이라도 구현 에이전트로 고정. 「부모가 직접 편집」하는 경로를 규약으로 차단.
• usage 검문소의 재설계: 「중량 페이즈(Heavy phase) 전에 인간이 usage 페이지를 확인하고 정지」하는 검문소는, 구독형(잔여량이라는 개념이 있는) 자원 관념을 전제로 하고 있었음. 종량제 사용자에게는 「여유가 있는가」라는 질문 자체가 성립하지 않음(지켜야 할 것은 예산이며, 이는 기계적인 상한선의 역할임). 위임 플랜 승인 시의 자원 동의로 통합하고, 주행 중 정지는 폐지하는 방향으로 검토.

강조하고 싶은 점은, 이 3가지 모두 설계 문서 리뷰나 5 사이클의 적대적 감사(Adversarial audit)에서도 나타나지 않았다는 것입니다. 나타난 것은, 기대를 품은 인간이 지켜보는 앞에서, 다른 조건의 상위 모델이 실제 태스크를 실행했을 때뿐이었습니다.

화제가 된 발원지 근처에서 작성된 선행 기사가 "배선의 교묘함보다 각 분기점의 판정 정밀도가 병목(Judgment Engineering)이다"라고 지적했는데, 이 부분에는 실감하며 고개를 끄덕이게 됩니다만, 저희의 실제 데이터는 이미 반 걸음 앞을 보여주고 있었습니다. 판정 그 자체(Review Loop)는 잘 기능했습니다──부모 모델의 판단 실수까지 잡아냈습니다──반면, 구멍이 뚫린 곳은 규약이 판정을 정의하지 않은 곳의 재량이었습니다. 배선과 판정을 정교하게 만든 뒤에 남는 것은, "규약에 적혀 있지 않을 때, 에이전트는 무엇을 하는가"입니다.

업무·개인 개발에 활용할 수 있는 점

1. 버즈워드는 "지도"로 사용하고, 순서의 서사는 의심하라

"X 다음은 Y"라는 화법은 대개 마케팅의 편의를 위한 것입니다. 보아야 할 것은 포함 관계(Y가 X를 대체하는가, 아니면 포함하는가)입니다. 그래프 ⊃ 루프처럼 중첩(Nested) 구조라면, 당신이 X에서 해온 일은 헛수고가 되지 않았습니다.

2. "자율"의 설계 단위는 질문의 유무가 아니라, 승인의 대상이다

자율 모드를 "질문하지 않는 AI"라고 정의하면, 폭주와 안전의 트레이드오프(Trade-off) 관계가 됩니다. "승인 게이트(Approval Gate)의 대상을 사람에서 객관적 조건으로 교체하고, 교체할 수 없는 것(비가역적 요소·정보 부족·자원)만 사람에게 남긴다"라고 정의하면, 안전장치를 유지한 채 자율 주행할 수 있습니다. 그리고 이용자는 전자의 이미지로 접근하기 때문에, 그 격차 자체를 온보딩(Onboarding)에서 설명할 필요가 있습니다.

3. 규약의 구멍은 문서 리뷰가 아니라 "조건을 바꾼 실전 실행"에서 나온다

이번에 발견된 3가지 구멍은 감사 5 사이클 + 다수의 리뷰를 빠져나가, 부모 모델·관찰자·날짜 경과라는 조건의 변화를 통해서야 비로소 드러났습니다. 도그푸딩(Dogfooding)의 조건을 하나만 바꿔도 검출력이 올라갑니다.

4. "자신의 실수를 시정하는 것"이야말로 독립 레이어를 통하게 하라

실수의 당사자는 "자신이 문맥을 가장 잘 알고 있다"라는 정당한 이유로, 체크를 건너뛰는 정당화를 합니다. 인간도 AI도 마찬가지입니다. 시정의 실시 주체를 사전에 규칙화해 두면, 이러한 자기 정당화가 구조적으로 통하지 않게 됩니다.

요약

• 그래프 엔지니어링은 "루프의 다음"이 아니라 루프를 포함하는 층이다. 기술은 기존의 것이고 새로운 것은 이름뿐이다. 혼란스럽다면 포함 관계를 보라. C3는 표준 워크플로우 = 그래프 층, autonomous-mode = 루프 층으로, 두 가지를 처음부터 동시에 만들고 있었다. 버즈워드에 뒤처진 쪽이었다. Opus 4.8 부모 모델에서의 자율 완주를 달성. 운전 규약은 설계대로 기능하며, 인간의 개입은 설계상의 검문소에서만 이루어졌다.
• 수확은 완주 그 자체보다 삼자삼양(三者三様)의 실수와, 실전 실행에서만 나타난 규약의 구멍 3가지이다. 배선과 판정 너머에는 "규약에 적혀 있지 않을 때의 재량"이 남는다.

autonomous-mode skill은 현재 배포처에서 숙성 중인 미배포 기능이지만, 이번 검증을 통해 배포 전환 조건이 갖춰졌습니다. 구멍 3가지에 대한 수정과 함께 정식 배포를 향해 나아갈 예정입니다. "사용해 보고 싶다"라는 목소리는 솔직히 말해 배포에 강력한 추진력이 됩니다.

C3를 시도해보고 싶다면 ── 시작하는 법

pip install claude-code-conductor # C++ 컴파일러 불필요
cd your-project
c3 init # .claude/ 디렉토리에 에이전트 정의·skill·hook이 전개됨

그다음 Claude Code에서 /start

를 입력하세요. 표준 워크플로우(본문에서 말하는 그래프 층)는 현행 버전에서 그대로 사용할 수 있습니다. 어댑터는 Claude / Codex / Cursor / OpenCode 4가지를 지원합니다 (c3 init --platform ...).

"여기서 막혔다", "이 부분이 이상하다" ── 막히는 부분에 대한 보고가 가장 큰 도움이 됩니다. Issue, PR, X(구 Twitter) 등 어디든 편하게 말씀해 주세요.

링크

C3 GitHub: https://github.com/satoh-y-0323/claude-code-conductor -
C3 PyPI: https://pypi.org/project/claude-code-conductor/ -
C3 공식 문서 (Official Documentation): https://satoh-y-0323.github.io/claude-code-conductor/ -
이전 기사 (『에러는 한 줄도 나오지 않는다. 다만 모든 hook이 침묵한다』/ C3 v2.50.0-v2.51.0): https://zenn.dev/satoh_y_0323/articles/c5c69f0868edb5 -
자율 모드 (Autonomous Mode) 관련 과거 기사: 검증 3일간의 실전 기록 / 본체 구현 이야기 (v2.49.0)

그래프 엔지니어링 (Graph Engineering) 관련 참고 기사

Discussion