Claude Code 프레임워크 전쟁
(shmck.substack.com)- 개발자들은 이제 AI와 협업하는 방식을 학습하는 단계에 있으며, Claude는 단순한 챗봇이 아니라 프레임워크로 활용될 때 가치가 극대화됨
- 커뮤니티에서는 Claude를 어떻게 구성하고 활용할지에 대한 다양한 시도가 이어지며, 이를 Claude Code Framework Wars라 부를 정도로 실험이 활발함
- 이를 통해 Claude를 프로젝트 매니저, 아키텍트, 개발자, 리뷰어 등 여러 역할로 활용하는 흐름이 형성되고 있음
- 프레임워크 설계에는 작업 관리, 지침 제공, 에이전트 협업, 세션 운영, 툴 접근, 코드 개발, 전달, 맥락 보존 등 8가지 주요 결정이 필요함
- 핵심 교훈은 AI가 개발자를 대체하는 것이 아니라 구조화된 규칙과 역할을 통해 생산성을 배가시키는 동료로 자리잡는다는 점임
서론
-
핵심 아이디어: 클로드를 단순 대화 도구가 아닌 프레임워크로 간주, 명확한 규칙과 작업 흐름을 통해 예측 가능하고 가치 있는 결과 생성
- 개발자는 코딩 대신 고부가가치 역할(프로젝트 관리, 설계, 아키텍처)로 전환
- 클로드 코드 프레임워크는 코드 작성 없이 구조화된 프롬프트로 동작
-
클로드 코드 프레임워크 전쟁: 개발자 커뮤니티가 생산적 AI 활용을 위해 다양한 접근법 실험중
- 수십 개의 오픈소스 프로젝트가 작업 흐름과 역할 구조를 정의하며 경쟁
- 예: Agent OS, Claude-Flow
프레임워크 설계시 고려해야 할 주요 선택지
1. 작업 관리 위치
- 클로드가 참조할 수 있는 작업 소스 정의 필요
-
마크다운 백로그: 작업을 마크다운 형식의 투두 리스트로 관리
- 예: Backlog.md, ReqText
-
구조화된 텍스트: 제품 사양을 작업으로 변환
- 예: Agent OS
-
이슈/티켓: GitHub Issues 또는 Jira 티켓으로 사양 저장, 코드 리뷰와 연결
- 예: ccpm
-
마크다운 백로그: 작업을 마크다운 형식의 투두 리스트로 관리
- 핵심: 작업이 클로드가 접근 가능하고 추적 가능한 위치에 태스크가 저장되어야 함
2. Claude에 가이드 제공 방법
- 모호한 프롬프트 대신 명확한 구조로 클로드 지침 제공
- 명령어 라이브러리: /create-tasks, /review 같은 사전 정의된 슬래시 명령어
- 코딩 표준: 기술 스택과 코딩 가이드라인 명시
- 완료 정의: 작업 완료 기준을 코드화
- 트리거 검증 훅: 모든 변경에 린팅과 테스트 강제
- 클로드 리뷰어: 클로드가 개발과 리뷰를 동시에 수행
- 핵심: 명확하고 반복 가능한 규칙으로 클로드의 작업 품질 향상
3. 에이전트 협업 구조
- 여러 클로드 에이전트 사용 시 역할과 계획으로 조정
-
역할 시뮬레이션: AI가 PM, 아키텍트, 개발자, 테스터 역할 수행
- 예: Agent OS
-
스웜 병렬 처리: 사양 → 의사 코드 → 코드 → 테스트로 이어지는 구조적 흐름에서 다수 에이전트 동시 실행
- 예: Claude-Flow
- 리포지토리 네이티브 아티팩트: 작업, 로그, 의사 결정 기록(ADR)을 코드베이스에 저장해 메모리 지속
-
역할 시뮬레이션: AI가 PM, 아키텍트, 개발자, 테스터 역할 수행
- 핵심: 조정을 통해 다수 AI 작업자의 충돌 방지
4. 세션 운영 방식
- AI 출력의 혼란 방지를 위해 세션을 작업 환경으로 설정
-
터미널 오케스트레이션: 클로드가 명령어, 창, 로그 제어
- 예: Symphony, Claude-Squad
-
병렬 워크트리: Git Worktrees로 여러 브랜치를 병렬 실행
- 예: Crystal
-
병렬 컨테이너: 클로드를 독립 컨테이너에서 실행해 충돌 방지
- 예: ClaudeBox
-
터미널 오케스트레이션: 클로드가 명령어, 창, 로그 제어
- 핵심: 병렬 작업으로 충돌 없이 생산성 극대화
4. 세션 실행 방식
- AI 출력의 혼란 방지를 위해 세션을 작업 환경으로 설정
-
터미널 오케스트레이션: 클로드가 명령어, 창, 로그 제어
- 예: Symphony, Claude-Squad
-
병렬 워크트리: Git Worktrees로 여러 브랜치를 병렬 실행
- 예: Crystal
-
병렬 컨테이너: 클로드를 독립 컨테이너에서 실행해 충돌 방지
- 예: ClaudeBox
-
터미널 오케스트레이션: 클로드가 명령어, 창, 로그 제어
- 핵심: 병렬 작업으로 충돌 없이 생산성 극대화
5. 클로드의 도구 접근
- 클로드가 기술 스택 전반에 대한 지식을 활용하도록 설정
- 핵심: 도구 통합으로 클로드를 단순 자동완성에서 활성 팀원으로 전환
6. 코드 개발 방식
- 클로드가 필요에 따라 다양한 역할 수행
- 핵심: 소프트웨어 생애 주기 전반에서 AI 활용
7. 코드 전달 방식
- 코드가 리포지토리에 도달하는 방법 정의
- 핵심: 생산용 안전 반복 또는 프로토타입용 스캐폴드 선택
8. 맥락 보존 방식
- 클로드의 망각 문제를 프레임워크 메모리로 해결
- 문서와 저널: CLAUDE.md, 아키텍처 노트, 프로젝트 저널 최신화
-
지속적 메모리 및 점검: 최근 작업 요약, 프로젝트 건강 점검, 의사 결정 저장
- 예: Claude-Flow
- 핵심: 메모리 없이는 AI가 오류 반복, 메모리로 진행 복합화
통합 방안
- 선택지를 메뉴로 간주, 한 번에 모든 설정 불필요
- 초보 설정: 마크다운 백로그 + 티켓 차이점
- 구조화된 팀: 제품 사양 + 표준 + 역할 시뮬레이션
- 실험 중심: 리포지토리 아티팩트 + 병렬 세션
- 프로토타입 모드: 앱 빌더 + 문서 스캐폴드
결론 및 시사점
-
핵심 교훈: 클로드는 구조화된 환경에서 최상의 성과 발휘
- 개발자 역할 대체가 아닌, 보일러플레이트 작업 감소로 사양 정의, 설계 검토, 아키텍처 정의에 집중
- 작업이 잘못되면 빠르게 탈선 가능, 구조적 관리 필수
- 현재 초기 단계이나 프레임워크는 AI를 마법 상자가 아닌 관리 가능한 팀원 집합으로 수렴
- 구조를 제공할수록 더 큰 가치를 반환
- 오픈소스 프로젝트를 통해 커뮤니티가 다양한 프레임워크 실험, 생산적 AI 활용법 모색
- 개발자는 클로드를 체계적으로 활용하여 고부가가치 작업에 집중하고, AI를 팀원으로 통합해 생산성 극대화 가능
Hacker News 의견
-
Claude Code용 "프레임워크"를 여러 개 시도해 보았으나, 객관적으로 성능이 좋아진 건 잘 모르겠음
공식처럼 복잡한 과정을 둘러싼 의식만 가득하고, 실제로 무엇 때문인지 의문임
이런 프레임워크 방식이 모델 훈련 목적과 맞지 않는 느낌임
실제로는 모델에 불필요한 정보들을 던져주면서, "내가 정해놓은 과정"에 맞추려 억지로 맥락을 오염시키는 셈임
맥락 오염을 없애고, 실제 작업에 꼭 필요한 정보만 제공하면서 점진적으로 개선해 나가는 게 중요하다고 봄
이런 전통적 협업 방식은 맥락 제한된 에이전트 맥락 밖에서 진행되어야 더 맞는 구조임-
이 글에서는 subagents에 대해 전혀 언급하지 않아서 언제 작성된 건지 궁금함
나는 "메모리 뱅크에서 현재 작업에 관련 있는 정보만 찾아오기", "테스트 돌려보고 실패 및 커버리지만 피드백하기" 같은 작업들을 subagent에 위임함
이렇게 하면 메인 에이전트의 컨텍스트가 금세 꽉 차는 걸 막을 수 있었음
https://docs.anthropic.com/en/docs/claude-code/sub-agents -
dev containers와 worktrees 같은 몇 가지 실용 관행을 도입하면서 삶이 더욱 편해졌음
프로젝트 파일 관리와 worktree 생성을 위한 나만의 shell script "프레임워크"도 직접 만들었는데, 이 작업은 이틀 정도만에 끝냈음
특정 툴에 종속되지 않아 자유로움
컨텍스트 오염이 실제로 신경써야 할 현실이라는 점에 동의함
특히 MCP endpoint 정의가 내 컨텍스트 중 상당 부분(약 2만 토큰)을 차지하는 걸 경험하면서, MCP 선택 시 반드시 컨텍스트 이슈도 고려함 -
실제 프로젝트 매니저와 비슷한 상황이라 느꼈음
-
-
내가 원하는 점은, Claude를 활용해서 명확하지 않은 부분을 먼저 묻는 단계가 제안서 작성에 포함되는 것임
실제 엔지니어에게 요구사항과 기대 결과만 주면, 실행 전에 당연히 추가 질문을 던져 확실히 맞춰볼 것임
Claude도 이런 확인 과정을 자동화해줄 수 있기를 기대함- OpenAI의 deep research tool과 비슷한 느낌임
명확히 하지 않은 질문을 전혀 고려하지 않아 여러 실수가 생기는 경우가 많음을 종종 경험함
- OpenAI의 deep research tool과 비슷한 느낌임
-
이런 프레임워크 적용 시, 실제 어느 정도 자율성을 두고, 어떤 환경(greenfield/brownfield)에서 사용하는지 궁금함
엔터프라이즈 소프트웨어에 Claude Code를 붙여서 자신 있게 결과를 내본 경험이 있는 분도 있는지 묻고 싶음
나는 회사에서는 Claude Code에 비교적 자유롭게 접근 가능하지만, 내 코드베이스에서는 프론트엔드 UI나 Playwright를 포함하면 결과가 들쭉날쭉함
코드 찌꺼기는 얼마나 남는지, 동료와의 협업 피로도는 어떤지, pull request 규모, 추론 비용, 병렬화 시 관리 방식 등 실제 사용 노하우가 궁금함
README 문서는 시스템 특화 용어, 이모지, 지나치게 개인화된 툴박스 정리법 등으로 가득 차서 판매용 홍보 문서처럼 느껴질 때가 있음
결국 Anthropic 등에서 이런 기능들을 자체 CLI에 편입하지 않을까 싶음
개인적으로는 reasoning 모델로 10페이지짜리 스펙, 엄격한 lint/type check/formatter/hook, 작업 체크리스트, red/green TDD까지 모두 처리하게 하며, GPT-5에게 “go” 한 번이면 필요한 결과물이 자동으로 만들어짐
같은 도구만 있다면 누구나 자기만의 시스템을 쉽게 만들 수 있음- 나도 Claude Code를 사용한 지 3주 정도밖에 안 됐지만, 최근 50만 SLOC 이상 대형 Elixir/Phoenix 코드베이스에서 역할 기반 구조(예: persona)에 따라 인상적인 결과를 경험함
$200 Max 플랜을 써서 추론 비용도 고정임
특히 신규 기능 추가 등 greenfield 상황일 땐 성과가 뚜렷했음
복잡한 리팩터링이나 시스템 심층 변경에는 (좋은 설계 문서가 있다면) 진도가 꽤 나가지만, 문서화가 부족한 곳은 효과가 잘 안 나옴
초기엔 "좋지 않은 코드"—스타일이나 재사용성/유지보수성이 떨어지는 구현물이 많았는데, CLAUDE.md 파일을 강화하고, "elixir-code-reviewer" subagent를 개발자 persona가 무조건 활용하도록 한 뒤부터 코드 품질이 눈에 띄게 향상됨
우리 플랫폼은 오픈소스라, 현재 Claude command 및 subagent 구성을 여기에 공유함
https://github.com/Simon-Initiative/oli-torus/tree/master/.claude
- 나도 Claude Code를 사용한 지 3주 정도밖에 안 됐지만, 최근 50만 SLOC 이상 대형 Elixir/Phoenix 코드베이스에서 역할 기반 구조(예: persona)에 따라 인상적인 결과를 경험함
-
블로그에서 LLM 특유의 스타일이 진하게 느껴졌음
유용한 정보이지만, AI에게서 AI에 대해 배우고 있다는 점이 재미있음-
요새 AI 관련 글 중 많은 부분이 이렇게 느껴짐
실제로는 비전문적인 작업이 아니면 Claude Code를 직접 모니터링하고, 잘못된 방향으로 갈 땐 즉각 개입해야 함
보안상 너무 많은 권한을 주거나, 실제 어떤 명령을 실행하는지 확인하지 않으면 안 됨
지금의 "프레임워크"는 아직 갈 길이 멀고, 현재로선 “엄청난 속도로 코드를 뿜어내는 주니어 인턴” 정도로 생각하는 게 현실적임 -
글쓴이가 repo를 제대로 확인하지 않았거나, 실제로 제한된 리서치 결과일 수 있음
예를 들어 superClaude는 MCP 서버가 아니고, metaGPT는 Claude Code와 호환되지 않는 듯 보임
-
-
agent도 인간처럼 자기 컨텍스트를 직접 관리하게 두지 않는 이유가 늘 궁금함
이전 작업 전체 히스토리를 왜 매번 전부 포함시키는지 모르겠음
agent가 어느 컨텍스트를 남겨야 효과적인지 판단하게 두고, 맥락 관리의 장단점을 스스로 학습하게 하면 각 작업 수행 능력이 더 좋아질 것 같음 -
결국 여기서도 textbook "bitter lesson"이 반복되는 듯함
사람들이 온갖 "프레임워크"를 만들지만, 다음 세대 모델이 모두 쓸모없게 만들어버림
http://www.incompleteideas.net/IncIdeas/BitterLesson.html -
BMAD-method가 언급되지 않아 꽤 놀라웠음
내 경험상 BMAD-method가 Claude Code에 가장 좋은 보완책임-
BMAD-method가 뭔지 궁금함
단순히 시스템 프롬프트 수준인지, 무엇 때문에 그렇게 유용하게 느꼈는지 알고 싶음
https://github.com/bmad-code-org/BMAD-METHOD -
BMAD 시스템은 포스트에서 소개한 AgentOS와 비슷해 보임
이런 컨텍스트 엔지니어링 방식이 내게는 효과적이었고, 직접 Claude에게 커맨드와 agent를 생성하게 해서 필요에 맞게 수정함
최근엔 context 공유에 json과 markdown도 적극적으로 활용함 -
taskmaster도 마찬가지지만 리스트에 없음
-
-
context 관리가 마치 저수준 프로그래밍처럼 느껴짐
올바른 연산을 위해 CPU 레지스터에 정확한 값들을 넣어야 하는 것과 비슷하다고 생각함
다른 점은 각 작업별로 추가/제거할 context 권한이 우리에게 훨씬 적다는 점임 -
B-MAD Framework를 써보고 효과가 너무 달라서 이제는 이 툴 없인 작업이 불가능해졌음
앞으로도 이런 프레임워크가 더 많아지길 바람 -
이런 프레임워크를 실제 사용해 본 분 있는지 궁금함
실질적으로 성과를 주는지, 단순히 유행을 타는 하이프인지 궁금함- 때때로 프레임워크 쪽을 들여다보면 대부분 자기 자신으로만 구축되어 있음
결과는 예상대로이며, 검증도 없이 온갖 기능이 쏟아지고, 제대로 된 문서도 없이 Claude-isms로 가득함
실제로는 만든 사람이 관심 있는 소수 프로젝트에만 쓸 수 있는 수준임
- 때때로 프레임워크 쪽을 들여다보면 대부분 자기 자신으로만 구축되어 있음