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

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll translate it into Korean while preserving the original formatting, markdown, and any code blocks or URLs.

Problem: single AI agent drifts

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

GitHub에 있는 두 개의 오픈소스 프레임워크는 동일한 해결책에 도달했습니다: 작업을 여러 에이전트에 분산시키고 서로를 검증하게 하는 것. plan → implement → review → fix의 루프를 강제합니다. 두 프레임워크 중 더 큰 것은 **118,624 ★**를 기록하고 있습니다.

Source:

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

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

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

멀티‑에이전트 오케스트레이션은 각 단계를 작게 유지함으로써 이를 해결합니다:

1. 계획 에이전트 – 작업을 여러 조각으로 나눈다.
2. 구현 에이전트 – 한 번에 하나의 조각을 처리한다.
3. 리뷰 에이전트 – 코드가 계획과 일치하는지 확인한다.

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

이것은 새로운 아이디어가 아니라 CI/CD 파이프라인을 닮았습니다. 차이점은 이제 에이전트가 인간이 담당하던 역할을 수행하고, 단계 간 인계가 자동화된다는 점입니다.

Discipline or flexibility? Two frameworks, two designs

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 에이전트가 나쁜 코드를 생성하면, 모델을 바꾸기 전에 구조를 추가해 보세요.