donghyeon.kang/company-haness
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
bac770dc4c5cc03e9efa62873c9c95eaed3fe9ce
company-haness/docs/superpowers/harness-efficiency-audit-2026-07-07.md
T

22 KiB
Raw Blame History

status, applies-to-version, superseded-by, exclude-from, note
status applies-to-version superseded-by exclude-from note
historical-snapshot registry 62 roles / 26 families / 11 lenses (작성 시점 스냅샷) 현재 정본 registry 73 roles / 28 families / 12 lenses — org-os/00-role-registry/*
must-read
default-search
이 문서의 62/26/11 등 수치는 2026-07-07 시점 스냅샷이다. 현재 수치·구조는 org-os 레지스트리를 정본으로 한다(finding #20).

Org OS 하네스 vs. 업계 멀티에이전트 오케스트레이션 — 설계 효율성 비교

작성: 2026-07-07 · 방법: WebSearch + WebFetch(공식 문서/논문/1차 엔지니어링 블로그) · 날조 없음, 모든 판정은 아래 출처에 접지.

BLUF (Bottom Line Up Front)

  • 판정: 사용자 하네스의 골격은 업계 정설과 정합하며, 두 개의 가장 중요한 실무 교훈을 명시적으로 코드화했다. (1) Anthropic의 "멀티에이전트는 병렬 리서치/분석엔 이기고 코딩엔 진다" → collaboration-default의 fan-out(판단·설계·분석) vs collapse(코드·실행) 분기로 반영. (2) Cognition의 "요약 말고 전체 트레이스를 공유하라" → synthesis-rehydration(하위 .report.yaml 전문 재적재)으로 반영. 대부분의 프레임워크(MetaGPT/ChatDev/CrewAI)는 이 둘을 구분하지 않는다.
  • 주된 실무 리스크는 토큰·지연 비용이다. Anthropic 관측상 멀티에이전트는 채팅 대비 ~15배 토큰을 쓰고 토큰량이 성능분산의 **80%**를 설명한다. 사용자 하네스는 fan-out + 전문 재적재(rehydration)를 기본 경로에 두므로, mode×tier 게이팅과 렌즈 상한이 규율대로 강제되지 않으면 비용이 폭증한다.
  • 다양성을 headcount(62역할)가 아니라 11 렌즈로 고정한 것은 옳은 선택이다 — Anthropic이 경고한 "단순 질의에 subagent 50개 spawn" 낭비를 구조적으로 억제한다.

조사한 하네스 (each target · approach · well / limitation · 사용자와 비교)

1. Anthropic — "How we built our multi-agent research system" (1차 엔지니어링 블로그)

  • approach: Orchestrator-worker. Lead(Opus)가 질의를 분해→subagent(Sonnet)를 병렬 spawn, 각자 독립 context window로 탐색 후 lead가 종합.
  • well: 병렬화·context 압축·다양한 툴 인터페이싱이 필요한 리서치에서 단일 Opus 대비 +90.2%. 복잡 질의 리서치 시간 최대 90% 단축. subagent 각자 context로 자연 압축.
  • limitation: 채팅 대비 ~15배 토큰(agent 단독은 4배). 토큰량만으로 성능분산 80% 설명 → 고가치 과제에만 경제성. "대부분 코딩 과제는 리서치보다 병렬화 가능 부분이 적다"며 코딩·강결합 과제엔 부적합. lead 소폭 변경이 subagent 거동을 예측불가하게 바꾸는 창발성.
  • comparison-to-user: 가장 직접적 원형. 사용자의 Orchestrator+fan-out worker+각자 clean context 구조가 동일 패턴. 사용자는 여기에 (a) 코드=collapse로 Anthropic의 코딩 경고를 명시 반영, (b) tier로 고가치 과제만 heavy fan-out 하도록 경제성 게이트를 추가 — Anthropic이 글로만 언급한 것을 정책으로 강제.

2. Cognition (Devin) — "Don't Build Multi-Agents" (1차 엔지니어링 블로그, 반론 진영)

  • approach: 단일 스레드 선형 에이전트 권장. context가 연속. 초과 시 히스토리를 핵심 결정으로 압축(하되 "제대로 하기 어렵다").
  • well: 원칙 2개가 날카롭다 — (1) "개별 메시지가 아니라 전체 agent trace를 공유하라", (2) "행동은 암묵적 결정을 내포하고, 충돌하는 결정은 나쁜 결과를 낳는다". Flappy Bird 예: 한 subagent는 마리오 배경, 다른 subagent는 안 맞는 새 → 사전 미명시 가정 충돌.
  • limitation: 병렬성·확장성을 포기. 대규모·초장기 과제의 cross-agent context 전달 문제는 미해결로 남김. 2025 현재 "협업 다중 에이전트는 취약한 시스템만 낳는다"는 강한 입장(장기적으론 낙관).
  • comparison-to-user: 사용자 하네스가 명시적으로 인용·방어한 상대. handoff-context-policy에 "요약만으로 축소하지 않는다(Cognition)", synthesis-rehydration에 "요약은 관점을 유실 → 원본 전문 재적재"로 정확히 대응. 다만 Cognition의 핵심 우려(병렬 워커가 미명시 가정에서 발산)는 단일 fan-out phase 내부에서 여전히 살아있고, 사용자는 이를 cascade(상위 Packet을 하위 입력으로 전달)로 완화한다.

3. MetaGPT (ICLR 2024 oral, arXiv 2308.00352)

  • approach: 인간 SOP(표준운영절차)를 프롬프트 시퀀스로 인코딩한 역할기반 assembly-line. 역할 접두 프롬프트 + 구조화 중간산출물.
  • well: SOP·구조화 산출물이 "LLM 단순 체이닝의 연쇄 환각"을 억제. 역할별 도메인지식 주입.
  • limitation: 워터폴형 고정 파이프라인이라 유연성 낮음. 역할이 코딩까지 fan-out → 코드 강결합엔 Anthropic/Cognition 경고 적용.
  • comparison-to-user: 역할기반·구조화 산출물 강제(=사용자의 .report.yaml+E0~E5 증거등급)는 유사. 차이: 사용자는 코드 단계를 collapse로 접어 assembly-line을 코드에까지 적용하지 않음(더 방어적).

4. ChatDev (ACL 2024, arXiv 2307.07924)

  • approach: 워터폴(설계→코딩→테스트→문서)을 chat-chain으로. 각 노드=서브태스크, instructor/assistant 2-에이전트 대화 + communicative dehallucination.
  • well: 단계·2자 대화로 구조화. 요청-확인 패턴으로 환각 완화.
  • limitation: 2자 대화 체인이라 관점 다양성·병렬성 제한. 고정 워터폴.
  • comparison-to-user: 사용자의 cascade(결정→설계→세부→구현)와 위상 유사. 그러나 사용자는 각 phase에서 N-way fan-out(다관점) 후 종합 — ChatDev의 2자 대화보다 다양성 우선. dehallucination ≈ 사용자의 evidence-grade/독립 검증.

5. AutoGen / AG2 (Microsoft, 오픈소스)

  • approach: 대화 주도(conversation-first). 에이전트들이 메시지로 자유 협상, 인간 참여·코드 실행 루프.
  • well: 유연·범용, human-in-the-loop·코드 실행에 강함.
  • limitation: 자유 대화라 워크플로 예측불가·수렴 불안정. 거버넌스/감사 배선은 별도 구축 필요.
  • comparison-to-user: 정반대 철학. 사용자는 자유 대화 대신 **파일기반·계약기반(context-package, report-return-contract)**으로 예측가능성·감사성을 택함. 유연성↓ 대신 재현·감사·거버넌스↑.

6. CrewAI (오픈소스)

  • approach: role/goal/backstory를 가진 crew, sequential/hierarchical task pipeline.
  • well: 역할 분해가 직관적, 비엔지니어도 이해. 팀형 구조화 과제에 적합.
  • limitation: 역할 정의는 있으나 렌즈 다양성·증거등급·DRAI 결정권 같은 거버넌스는 없음. 종합·dissent 보존 개념 부재.
  • comparison-to-user: 사용자 하네스는 CrewAI의 role-pipeline을 거버넌스로 감싼 상위집합 — DRAI(결정권), lens(다양성 바닥), evidence(접지), human-gate(위험 승인)가 추가.

7. LangGraph (LangChain)

  • approach: 노드=에이전트/툴, 엣지=허용 전이인 그래프/유한상태기계(FSM). 중앙 공유 state + checkpoint + guard/approval 노드.
  • well: 제어흐름을 개발자가 설계(flow engineering)해 장기거동 디버그·정렬 용이. 조직 제약을 그래프 노드로 삽입.
  • limitation: 그래프를 사람이 설계해야 함(구축비용). 공유 state 모델이라 관점 격리(발산)는 별도 설계.
  • comparison-to-user: 사용자 하네스는 LangGraph의 "명시적 제어흐름·승인노드"를 YAML 상태머신(state-transition-rules, acceptance-gates)으로 구현. 차이: LangGraph는 공유 state 중심, 사용자는 발산 시 격리 context(관점 오염 방지)로 갈라짐 — 발산/수렴을 분리한 게 더 정교.

8. OpenAI Swarm → Agents SDK

  • approach: routines(지시+툴) + handoffs(다른 에이전트를 반환하는 함수). Swarm은 stateless·경량 교육용, Agents SDK가 guardrail·tracing·handoff를 프로덕션화.
  • well: 극단적 단순함·경량. handoff로 제어 이양이 명료.
  • limitation: stateless·경량이라 거버넌스·증거·다관점 종합은 사용자가 구축. 오케스트레이션 로직이 얇음.
  • comparison-to-user: 사용자의 cross-group-edges(선언된 handoff 채널)가 Swarm handoff와 개념 유사하나, 사용자는 방향별 handoff-artifact 계약·미전달 시 Blocked까지 규정 — 훨씬 두꺼운 계약.

9. Microsoft Magentic-One (2024.11, arXiv/MSR)

  • approach: Orchestrator + 특화 에이전트 4(WebSurfer/FileSurfer/Coder/Terminal). Task Ledger(사실·계획) + Progress Ledger(진척·자기반성) 듀얼 원장.
  • well: 듀얼 원장으로 계획·진척을 분리 추적, 교착 시 재계획. 범용 웹/파일 과제.
  • limitation: 소수 특화 에이전트라 다관점 종합·거버넌스는 범위 밖. 오케스트레이터 창발성 리스크(Anthropic과 공통).
  • comparison-to-user: 직접 차용. 사용자 /plan-wave의 "Magentic 듀얼 원장(plan.md + progress.yaml)"이 바로 이 Task/Progress Ledger 패턴. 사용자는 여기에 렌즈 다양성·DRAI·증거등급을 얹어 조직 운영으로 확장.

10. AWS Bedrock 멀티에이전트 협업 (supervisor 패턴)

  • approach: Supervisor + collaborator 특화 에이전트. routing mode(단순→직접 라우팅) vs full orchestration(복잡→분해·병렬·종합). conversation-history 공유 옵션.
  • well: 관리형·관측성(AgentCore Observability). "책임 중복 최소화"를 공식 베스트프랙티스로 명시. routing/full 이원화로 경량-중량 경로 분리.
  • limitation: 벤더 종속. 관점 다양성·dissent·증거등급 개념 없음(도메인 라우팅 중심).
  • comparison-to-user: routing vs full = 사용자의 light vs heavy tier / converge vs divergent와 동형. AWS의 "책임 중복 최소화"는 사용자의 capability-families invocation-triggers/exclusions가 대응 — 다만 62→26 taxonomy가 커서 중복 리스크는 사용자 쪽이 더 크다(권고 참조).

11. 12-Factor Agents (HumanLayer)

  • approach: 프레임워크가 아닌 원칙 12개. Factor 3 "own your context window"가 핵심, 그 외 own your prompts, unify execution+business state, contact humans with tool calls, own your control flow 등.
  • well: "context window를 명시적으로 소유·구성하라", "중간 데이터는 구조화 포맷으로", 40~60% 구간의 'dumb zone'(회상력 저하) 경고. 프로덕션 신뢰성 지향.
  • limitation: 원칙만 제공, 오케스트레이션 구현체는 없음.
  • comparison-to-user: 사용자 하네스는 이 원칙들의 구현 사례에 가깝다 — .report.yaml 구조화 산출물(own context/structured), re-hydration-control(forbid raw-logs, structured-summary만 pass), DRAI human-gate(contact humans), state-machine(own control flow), evidence-grade(unify state). 정합성 높음.

사용자 하네스와 비교 (요약 매트릭스)

축 사용자 Org OS 가장 가까운 업계 사용자의 차별점
상위 구조 Orchestrator + fan-out worker Anthropic, Magentic-One, AWS supervisor 코드=collapse 분기로 코딩 경고 반영
코드 vs 판단 fan-out(판단/설계/분석) / collapse(코드/실행) Anthropic(코딩엔 멀티에이전트 비권장) 정책으로 강제(대부분 프레임워크는 미구분)
context 공유 synthesis-rehydration(전문 재적재) Cognition(full trace 공유) Cognition 우려를 명시 인용·방어
진척 추적 plan.md + progress.yaml 듀얼 원장 Magentic-One Task/Progress Ledger 직접 차용 + 거버넌스 확장
다양성 11 렌즈(불가침 바닥), headcount와 분리 (업계에 뚜렷한 대응 없음) 고유 강점 — 토큰 낭비 억제 장치
결정권/승인 DRAI + human-gate(heavy) AWS/12-factor(human-in-loop) 문서유형별 RACI로 세분화
소통 매체 파일기반 .report.yaml→MD LangGraph checkpoint/AWS observability 감사·재현성 우선(지연 감수)
경량/중량 경로 mode×tier(light/standard/heavy) AWS routing vs full 2직교축으로 더 세분
증거 접지 E0~E5 + hook 강제 자기채점 금지 MetaGPT/ChatDev(dehallucination) 아티팩트 검증까지 강제

효율성 평가 (Verdict)

강점 (근거 접지)

  1. fan-out/collapse 분기는 업계 최선의 판단과 정합. Anthropic은 "대부분 코딩 과제는 리서치보다 병렬화 가능 부분이 적다"며 코딩·강결합에 멀티에이전트를 비권장했고, Cognition은 코딩에 단일 스레드를 권장했다. 사용자 하네스는 판단·설계·분석·수익=fan-out, 코드·실행=collapse로 정확히 이 선을 그었다. MetaGPT/ChatDev/CrewAI는 코드까지 다중 역할을 굴려 이 구분이 없다 → 사용자 설계가 더 방어적이고 토큰 효율적이다.
  2. synthesis-rehydration이 Cognition의 1순위 비판을 정면으로 방어. "요약이 아니라 하위 .report.yaml 전문을 읽는다"는 규칙은 Cognition의 "individual messages가 아니라 full agent trace를 공유하라"와 동일 처방이다. 대부분 프레임워크가 종합 단계에서 요약으로 관점을 유실하는 지점을, 사용자는 명시적으로 막았다.
  3. 다양성을 렌즈(11)로 고정한 것이 토큰 폭증의 구조적 방파제. Anthropic은 "단순 질의에 subagent 50개 spawn"을 대표적 실패로 지목했다. 사용자는 다양성 바닥을 role 62가 아니라 lens 11로 두고, 같은 렌즈 중복은 collapse(family-collapse), 공유 렌즈는 primary carrier 1개만 대변(shared-lens-selection)한다 → spawn 폭발을 스펙 차원에서 억제. 이것은 조사 대상 중 가장 독창적인 효율 장치다.
  4. 경제성 게이트(mode×tier)가 Anthropic의 "고가치 과제에만 멀티에이전트"를 정책화. mode==converge && tier==light → 멤버 분리 생략, 단일 종합은 저위험 과제에서 15배 토큰 경로를 회피한다. AWS의 routing-vs-full 이원화와 동형이되 2직교축으로 더 세밀.
  5. 파일기반·계약기반 소통은 "org OS"(내구·감사) 목적에 정확히 맞는 트레이드오프. 12-factor의 own-your-context/structured-output, LangGraph의 checkpoint, AWS observability와 같은 계열. 인메모리 대화(AutoGen)보다 느리지만 재현·감사·거버넌스를 얻는다. 지연에 민감한 코드 루프는 어차피 collapse로 접히므로 손해가 상쇄된다.

약점 / 리스크 (근거 접지)

  1. 토큰·지연 비용이 최대 리스크. Anthropic: 멀티에이전트 ~15배 토큰, 토큰량이 성능분산 80% 설명. 사용자 하네스는 fan-out(DECIDE 7 C-level + DESIGN 8 family) 위에 다시 synthesis-rehydration(전문 재적재)을 쌓는다 → 종합 지점 context가 특히 무겁다. tier 게이팅과 렌즈 상한이 규율대로 강제되지 않으면(현재 일부는 정책 텍스트로만 존재) 기본 converge 경로에서 비용이 통제 불능이 될 수 있다.
  2. 단일 fan-out phase 내부의 발산 리스크는 잔존. Cognition의 Flappy Bird(미명시 가정 충돌)는 phase 간 cascade(상위 Packet→하위 입력)로 완화되지만, 한 phase 안에서 8개 family가 clean context로 병렬 시작하면 여전히 서로 모르는 가정으로 발산할 수 있다. 재조정 부담이 전적으로 종합자(synthesizer)에게 몰린다.
  3. 종합자(synthesizer)가 품질 병목이자 미검증 지점. 스펙은 "dissent 삭제 금지"를 명시하나, 종합 결과가 실제로 dissent를 보존했는지 검증하는 강제기가 fan-out 종합 단계엔 약하다. Anthropic도 종합·창발을 실패원으로 지목했다.
  4. Orchestrator 창발성·프롬프트 취약성. Anthropic: "lead의 소폭 변경이 subagent 거동을 예측불가하게 바꾼다." 사용자 하네스는 모든 fan-out을 Orchestrator가 구동하므로 그 프롬프트/스펙이 취약 레버. gen_agents.py가 워커를 스펙에서 생성해 워커 drift는 막지만, Orchestrator 자체 프롬프트는 단일 실패점.
  5. 62→26 taxonomy의 책임 중복 리스크. AWS 공식 베스트프랙티스는 "collaborator 책임 중복 최소화"를 강조한다. 26 family + 33 워커는 라우팅 중복·경계 모호 위험이 업계 사례보다 크다. invocation-triggers/exclusions가 있으나, family 수가 많을수록 유지비와 오라우팅 확률이 오른다.

종합 판정

사용자 하네스는 **"멀티에이전트를 아무데나 쓰지 말고, 병렬 이득이 있는 판단/리서치에만 쓰고, 종합 시 관점을 요약으로 죽이지 말라"**는 2025~2026 업계 합의를 스펙으로 성문화한, 이례적으로 자기인식이 높은 설계다. 골격의 효율성 근거는 탄탄하다. 실패는 구조가 아니라 운영 규율에서 온다 — 즉 tier 게이트·렌즈 상한·dissent 보존 검증을 강제기로 실제 배선했는가가 15배 토큰 비용의 통제 여부를 가른다.

개선 권고 (근거 포함)

  1. wave당 토큰·비용을 계측하고 tier별 fan-out 예산을 강제하라. (근거: Anthropic — 멀티에이전트 15배 토큰, 토큰량이 성능분산 80% 설명) agent-operating-kpi.yaml에 tokens/wave·cost-per-decision KPI를 추가하고, tier=light/standard에서 fan-out 폭(활성 워커 수)에 하드 상한을 두어 예산 초과 시 자동으로 collapse/단일 종합으로 강등. 지금의 "정책 텍스트"를 hook 강제로 승격.

  2. standard tier의 fan-out 폭을 family가 아니라 lens로 상한하라. (근거: Anthropic — 단순 질의에 50 subagent spawn 실패 사례; 사용자 자신의 shared-lens-selection) "공유 렌즈는 primary carrier 1개만 대변, heavy일 때만 sub-angle 분화"를 scorecard/Orchestrator에서 기본 강제로 만들고, heavy에서만 carrier 확장. 이미 스펙에 있는 원칙을 실행 배선으로 끌어올리는 것.

  3. fan-out phase 내부에 '공유 제약 pre-brief'를 주입해 발산을 억제하라. (근거: Cognition — 행동은 암묵적 결정을 내포, 미명시 가정 충돌이 Flappy Bird 실패를 낳음) cascade가 phase 간에는 Packet을 전달하지만, 한 phase 내 병렬 워커들에게도 승인된 ExecutiveDecisionPacket + 공통 설계 제약 헤더를 context-package에 동봉해, 워커들이 서로 모르는 가정에서 발산하지 않게 하라. (발산 다양성은 유지하되 '충돌하는 결정'만 사전 정렬.)

  4. 종합자에 dissent-보존 검증 강제기를 붙여라. (근거: 스펙의 "dissent 삭제 금지" must-not + Anthropic이 종합을 실패원으로 지목) 종합 .report.yaml에 dissent/conflicts 필드 존재와 하위 보고서 참조 링크를 validate_report hook이 검사하도록 확장. synthesis-rehydration이 실제로 관점을 보존했는지 아티팩트로 검증(자기채점 금지 원칙과 정합).

  5. 초장기 wave용 명시적 compaction 에이전트를 두되 결정 재적재 경로에서는 배제하라. (근거: 12-factor Factor 3 'own your context'·'dumb zone' 40~60%; Cognition·Anthropic 모두 context 초과를 최난제로 지목) fan-out 워커의 원시 트레이스가 context를 넘길 때만 핵심 결정으로 압축하는 compaction 단계를 형식화하고, 결정/종합 지점의 synthesis-rehydration(구조화 .report.yaml 전문)은 압축 대상에서 제외해 관점 유실을 막아라. (raw-log는 이미 forbid — 이를 '압축 후 통과' 파이프라인으로 명문화.)

출처 (URL 목록)

1차 (직접 fetch/공식):

2차 (해설/비교):

Reference in New Issue View Git Blame Copy Permalink