당신의 AI 에이전트는 혼자 작동합니다. 계획도, 테스트도, 리뷰도 없습니다. 118,000명의 개발자가 해결책을 찾았습니다.

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have that, I’ll provide a Korean translation while keeping the source link and all formatting unchanged.

문제: 단일 AI 에이전트의 흐트러짐

단일 AI 코딩 에이전트는 코드를 작성할 수 있습니다. 하지만 큰 작업을 주면 흐트러집니다. 테스트를 건너뛰고, 계획을 잊어버리며, 실제로는 완료되지 않았는데 “완료” 라고 말합니다. 이것은 모델 문제가 아니라 워크플로우 문제입니다.

GitHub에 있는 두 개의 오픈소스 프레임워크는 같은 결론에 도달했습니다: 작업을 여러 에이전트에 나누어 주고 서로를 검증하게 하라는 것입니다. 계획 → 구현 → 검토 → 수정의 루프를 강제합니다. 두 프레임워크 중 더 큰 것은 **118,624 ★**를 기록하고 있습니다.

작업을 나누면 왜 드리프트가 멈추는가

하나의 에이전트가 모든 일을 수행하면, 그 컨텍스트는 단계마다 커집니다. 30 분이 지나면 원래 계획을 놓치고, 한 시간이 지나면 아무도 요구하지 않은 새로운 요구사항을 만들어냅니다. 실패 패턴은 예측 가능합니다:

• 에이전트가 한 번에 모든 것을 구축하려고 하면 구조가 무너집니다.
• 작업 중간에 “done” 라고 선언합니다.
• 테스트를 작성하지 않고 기능을 완료된 것으로 표시합니다.
• 세션이 끝날 때 환경을 깨진 상태로 남겨둡니다.

Multi‑agent orchestration 은 각 단계를 작게 유지함으로써 이를 해결합니다:

1. Planning agent – 작업을 여러 조각으로 나눕니다.
2. Implementation agent – 한 번에 하나의 조각을 처리합니다.
3. Review agent – 코드가 계획과 일치하는지 확인합니다.

리뷰가 실패하면 작업이 다시 구현 단계로 돌아갑니다. 각 에이전트는 깨끗하고 집중된 컨텍스트에서 시작하므로 드리프트가 멈춥니다. Superpowers 는 이를 명시적으로 표현합니다: 계획은 “열정은 있지만 감각도, 판단도, 프로젝트 컨텍스트도 없고 테스트를 꺼리는 주니어 엔지니어에게도 충분히 명확해야 합니다.”

이는 CI/CD 파이프라인을 닮았지만, 이제 에이전트가 인간이 담당하던 역할을 수행하고 단계 간 인계가 자동으로 이루어집니다.

규율 vs 유연성? 두 프레임워크, 두 디자인

Superpowers

Superpowers (118 k ★) 를 설치합니다. 에이전트가 무언가를 만들고 싶어한다는 것을 감지하면 즉시 코드를 작성하는 대신 멈춥니다. 에이전트는 다음을 수행합니다.

1. 실제로 원하는 것이 무엇인지 묻습니다.
2. 대화에서 사양을 추출합니다.
3. 설계를 짧고 읽기 쉬운 조각으로 보여주어 승인을 받습니다.

승인을 하면 에이전트가 계획을 작성합니다. “execute” 라고 말하면 서브‑에이전트 기반 개발이 시작됩니다.

• 계획에 있는 각 작업은 2–5 분 동안 진행되며, 정확한 파일 경로, 전체 코드, 검증 단계가 포함됩니다.
• 각 서브‑에이전트가 작업을 마치면 두 단계 리뷰가 실행됩니다:
  • 1단계 – 코드가 사양과 일치하는가?
  • 2단계 – 코드 품질 검사.

TDD는 RED‑GREEN‑REFACTOR 사이클을 따르며, 테스트가 존재하기 전에 작성된 코드는 삭제됩니다. 14개의 내장 스킬이 이 7단계 워크플로우를 선택이 아닌 필수로 강제합니다. Claude Code, Cursor, Codex, OpenCode, Gemini CLI와 모두 호환됩니다.

oh‑my‑claudecode

oh‑my‑claudecode (14 k ★) 은 팀 방식을 채택합니다. Team mode 는 다음과 같은 단계 파이프라인을 실행합니다:

team‑plan → team‑prd → team‑exec → team‑verify → team‑fix

v4.4.0 이후로는 tmux 워커를 이용해 Claude, Codex, Gemini 를 동시에 실행할 수 있습니다. 예시 명령:

omc team 2:codex   "Review auth module for security issues"
omc team 2:gemini  "Redesign UI components for accessibility"
omc team 1:claude  "Implement payment flow"

• 32개의 특화된 에이전트가 포함되어 있으며, 난이도에 따라 작업을 Haiku 또는 Opus 로 라우팅합니다.
• 한 줄 명령으로 교차 모델 PR 리뷰를 수행할 수 있습니다:

/ccg Review this PR — architecture (Codex) and UI components (Gemini)

자동 스킬 학습 – 문제를 디버깅하면 OMC 가 수정을 스킬 파일로 추출합니다. 예시:

# .omc/skills/fix-proxy-crash.md
---
name: Fix Proxy Crash
triggers: ["proxy", "aiohttp", "disconnected"]
source: extracted
---
Wrap the handler at server.py:42 with try/except ClientDisconnectedError...

다음에 동일한 오류가 발생하면 스킬이 자동으로 삽입됩니다 – 별도의 호출이 필요 없습니다.

요구사항이 명확하지 않을 때는 다음 명령을 사용합니다:

/deep-interview "I want to build a task management app"

이 명령은 소크라테스식 질문을 시작해 숨겨진 가정을 밝혀내고, 코드를 작성하기 전 가중치가 부여된 차원들에 대한 명확성을 측정합니다.

요점

• Superpowers는 품질을 보장하기 위해 규율을 강제합니다.
• oh‑my‑claudecode는 옵션을 넓히기 위해 다중 제공자 유연성을 제공합니다.

두 프레임워크 모두 동일한 핵심 루프를 사용합니다: plan → implement → review → fix.

모델이 병목이 아닙니다. 워크플로우가 병목입니다.

엔지니어링을 활용한 결과, 단일 에이전트는 장기간에 걸쳐 잘 작동하려면 좋은 환경이 필요함을 보여주었습니다. 다중 에이전트 오케스트레이션은 더 나아가 작업을 에이전트들 간에 분할하고 서로를 검사하게 합니다. 결과적인 품질은 프로세스에서 나오며, 원시 모델 파워에서 나오지 않습니다.

구조가, 단일 모델이 아닙니다.

두 프레임워크는 동일한 핵심 루프에 도달했습니다:

1. 계획
2. 구현
3. 검토
4. 수정

다음에 AI 에이전트가 나쁜 코드를 생성하면, 모델을 교체하기 전에 구조를 추가해 보세요.