저는 한동안 이 Agentic Framework를 작업해 왔으며, 현재 Claude Agentic Framework가 어느 단계에 와 있는지 공유하고자 합니다. 이것은 Claude Code CLI 상단에 위치하는 설정 레이어(configuration layer)로, 단일 채팅 세션을 21개의 전문화된 에이전트(agents)로 구성된 규율 있는 팀으로 변환합니다. 에이전트들이 업무를 수행합니다. 훅(Hooks)이 품질을 강제합니다. 일관성 시스템(consistency system)이 모든 것을 정직하게 유지합니다. 최근의 변경 사항을 통해 리뷰 기능이 훨씬 강력해졌으며, 마침내 코드 이외의 작업에 대해서도 적절한 셀프 스코어링 루프(self-scoring loop)를 갖추게 되었습니다.
이것은 단순한 프롬프트 모음이 아닙니다. 실제적인 강제(enforcement)입니다.

챗봇에서 에이전트로

대부분의 사람들은 여전히 Claude를 챗봇처럼 취급합니다. 질문을 던지면 답변을 받고, 코드를 복사하고, 실행하고, 오류를 직접 수정하고, 다시 질문합니다. 모델은 자신의 작업 결과물을 결코 보지 못합니다.
에이전트(agent)는 다르게 작동합니다. 목표를 부여하면, 에이전트는 계획을 세우고, 파일을 편집하고, 명령어를 실행하고, 출력을 읽으며, 결과가 완료되거나 실제 결정 지점에 도달할 때까지 계속 진행합니다. 컨텍스트(Context)는 에이전트 스스로 수집합니다. 메모리(Memory)는 CLAUDE.md와 메모리 파일에 존재합니다. 도구(Tools)는 파일 시스템(filesystem), 셸(shell), git, MCP 서버까지 완벽하게 갖추고 있습니다. 피드백 루프(Feedback loops)가 존재하며, 가드레일(Guardrails)은 엄격합니다.
그 차이는 컨텍스트 경제성(context economics)에서 가장 명확하게 드러납니다. 단일 롱 세션(long session)은 모든 파일과 로그로 윈도우를 채워버려 초기 결정 사항들이 메모리에서 밀려나게 됩니다. 에이전트 방식의 설정에서는 오케스트레이터(orchestrator)가 가볍게 유지됩니다. 방대한 읽기 작업은 짧은 요약만을 반환하는 일회성 자식 윈도우(disposable child windows)에서 수행됩니다. 이 저장소 자체를 마지막으로 개편하는 동안, 두 개의 리뷰 에이전트만으로도 자체 윈도우 내에서 약 357k 토큰을 소모했습니다. 조정 세션(coordinating session)은 각각 약 1,500 토큰 정도의 보고서 두 개를 전달받았습니다.

실전 아키텍처 (Architecture in Practice)

모든 것은 하나의 목표에서 시작됩니다. 라우팅 (Routing) (CLAUDE.md 규칙, /delegate 명령, 그리고 에이전트 설명에 의해 구동됨)은 작업을 적절한 전문가에게 전달합니다. 기술 (Skills)과 MCP 서버가 해당 전문가를 지원합니다. 전문가가 작업을 마치면, 코드 리뷰 게이트키퍼 (code-review-gatekeeper)가 품질을 검토합니다. 발견된 문제점들은 수정됩니다. 그 후, 피어 리뷰 크리틱 (peer-review-critic)이 의도적으로 읽기 전용 툴셋 (read-only toolset)을 사용하여 독립적인 최종 검토를 수행합니다. 스톱 게이트 (stop gate)는 실제 검토가 기록되었는지 확인합니다. 오직 그 단계가 완료되어야만 세션이 종료될 수 있습니다.

이 프레임워크는 최근 자체적인 파이프라인을 거쳤습니다. 멀티 에이전트 감사 (multi-agent audit)를 통해 격차를 발견했고, 10개의 커밋 (commits)으로 이를 수정했으며, 두 개의 리뷰 에이전트가 승인(sign off)했고, 3개의 CI 작업이 통과되었으며, 스톱 게이트가 최종 검토를 실시간으로 강제했습니다.

실제로 차단 기능을 수행하는 더 강력한 리뷰

최근 가장 큰 변화는 판결 인식 피어 리뷰 스톱 게이트 (verdict-aware peer-review stop gate)입니다. 이전에는 시스템이 단순히 리뷰가 수행되었는지만 확인했습니다. 이제 피어 리뷰 크리틱 (peer-review-critic)은 반드시 VERDICT: APPROVED 또는 VERDICT: CHANGES_REQUIRED라는 명확한 판결 (VERDICT) 라인을 출력해야 합니다. 레코더 훅 (Recorder hooks)이 이 결정을 로그로 기록합니다. 스톱 게이트는 판결이 APPROVED가 아니라면 세션 종료를 거부합니다. 조용히 우회하는 방법은 없습니다.
새롭고 개선된 명령어가 이를 지원합니다:

• /build: 명세서 (spec)가 말하는 그대로를 빌드하고, APPROVED를 받을 때까지 명세 준수 리뷰어 (spec-compliance-reviewer)와 반복 (최대 3회 반복)하는 자율 루프 (autonomous loop)를 실행합니다.
• /review-spec: 수동 적합성 검사 (manual conformance check)를 수행합니다.
• /delegate: 이제 명세서를 더 깔끔하게 소비하며, 이전의 할 일(per-todo) 단위의 데드락 (deadlocks)을 방지합니다.

이 강제 기능은 마침내 성숙해진 느낌을 줍니다. 이제는 "리뷰가 있었는가?"가 아니라, "실제 판결은 무엇이었으며 시스템이 이를 준수했는가?"를 묻습니다.

명세서, 계획 및 문서를 위한 셀프 스코어링 루프 (Self-Scoring Loop)

Code는 이미 리뷰 게이트 (review gates)를 갖추고 있습니다. 그 외의 모든 것들 — 명세서 (specifications), 아키텍처 노트 (architecture notes), 프로젝트 계획 (project plans), 제안서 (proposals) — 은 과거에 "이것을 더 개선해 주세요"와 같은 모호한 지침에 의존하곤 했습니다. 새로운 셀프 스코어링 루프 (self-scoring-loop) 기술은 이를 변화시킵니다.
루프는 단순하고 엄격합니다:

1. 먼저 루브릭 (rubric, 평가 기준)을 작성합니다 (합계가 100이 되는 5~7개의 가중치가 부여된 기준). 루브릭은 루프 전체 동안 고정됩니다.
2. 각 기준에 대해 현재 버전을 0~100점으로 점수를 매기고 짧은 근거를 작성합니다.
3. 가장 취약한 한두 개의 기준을 지목하고 왜 점수가 깎였는지 정확히 설명합니다.
4. 취약한 부분만 다시 작성합니다. 이미 높은 점수를 받은 부분은 유지합니다.
5. 다시 점수를 매깁니다. 점수 향상이 3점 미만이거나, 90점 이상에 도달하거나, 3회 반복에 도달하면 중단합니다.
6. 다듬어진 버전과 함께 최종 점수 및 궤적 (예: 68 → 81 → 87)을 반환합니다.

가드레일 (Guardrails)은 의도적입니다. 루프 중간에 루브릭을 변경해서는 안 됩니다. 눈에 보이는 루브릭 없이 점수를 매기는 것은 무효입니다. 이 기술은 권고 사항이며, 코드에 대한 피어 리뷰 게이트 (peer-review gates)를 절대 대체하지 않습니다.
저는 비코드 산출물 (non-code deliverable)을 제시하기 전에 이 방법을 직접 사용합니다. 개선 사항은 측정 가능하며, 중단 규칙은 끝없는 반복 작업을 방지합니다.

vouchfx에서의 관련 규율 (Related Discipline in vouchfx)

동일한 사고방식은 저의 다른 프로젝트인 vouchfx에서도 나타납니다. 그곳에서는 "위임된 실행 (delegate runs)" 개념이 다른 형태로 등장합니다. 선언적인 .e2e.yaml 명세(specs)가 Roslyn을 통해 메모리 안전(memory-safe)한 C# 델리게이트(delegates)로 한 번 컴파일됩니다. 그런 다음 이 델리게이트들은 .NET Aspire와 Testcontainers에 의해 오케스트레이션되는 전체 컨테이너 토폴로지(topology)를 대상으로 실행됩니다. 판결(Verdicts)은 명시적이며 (Pass, Fail, EnvironmentError, Inconclusive), CI 종료 코드(exit codes) 및 보고서로 깔끔하게 매핑됩니다. 에이전틱 프레임워크(agentic framework)의 셀프 스코어링(self-scoring) 아이디어와 vouchfx의 엄격한 델리게이트 기반 실행은 동일한 지점에서 기인합니다. 즉, 품질은 단순히 바라는 것이 아니라, 측정 가능해야 하며 강제되어야 한다는 점입니다.

수치 및 시작하기 (Numbers and Getting Started)

현재 이 프레임워크는 다음과 함께 제공됩니다:

1. 7개 카테고리와 3개 모델 티어(tiers)에 걸친 21개의 특화된 에이전트 (specialized agents)
2. 4개의 등록된 훅 (hooks) (하나의 강력한 차단 게이트 포함)
3. 셀프 스코어링 루프 (self-scoring-loop)를 포함한 여러 운영 기술 (operational skills)
4. 5개의 MCP 서버
5. 런타임에 진실을 도출하고 어떠한 드리프트(drift) 발생 시 빌드를 실패시키는 일관성 검증기 (consistency validator), Windows 단계를 포함한 3개의 CI 작업

설치는 간단합니다:

git clone https://github.com/tomas-rampas/claude-agentic-framework ~/.claude
pwsh -NoProfile -File ~/.claude/scripts/install.ps1
bash ~/.claude/scripts/validate-consistency.sh   # RESULT: PASS 예상

Claude Code CLI, PowerShell 7+, bash, jq, 그리고 MCP 서버를 위한 일반적인 Node/uv 구성 요소들이 필요합니다.

맺음말 (Closing)

저는 자신감 있게 말하면서 정작 어려운 부분은 조용히 건너뛰는 에이전트들에 지쳐서 이것을 만들었습니다. 실제 중단 게이트 (stop gates), 판결 기록 (verdict recording), 그리고 테스트 스위트 (test suite)가 없는 모든 작업에 대한 구조화된 자기 채점 루프 (self-scoring loop)의 결합은 이 시스템을 실제 엔지니어링 팀에 훨씬 더 가깝게 느껴지도록 만듭니다.

이 프레임워크는 공개되어 있습니다. 이 글을 시작하게 된 프레젠테이션은 리포지토리의 docs/team-presentation.md에 있습니다. 리뷰 및 채점 변경 사항을 다룬 Medium 포스트는 이미 공개된 상태입니다. 피드백, 이슈, 그리고 더 나은 루브릭 (rubrics)을 환영합니다.

에이전트가 코드를 작성합니다. 훅 (Hooks)은 품질을 타협할 수 없는 요소로 만듭니다. 일관성 시스템 (consistency system)은 전체 과정이 정직하게 유지되도록 합니다. 이것이 현재의 상태이며, 저는 이를 계속해서 더 정교하게 다듬을 계획입니다.