reopt-responsibility-partitioning

---
name: reopt-responsibility-partitioning
description: When several agents share work or role boundaries are unclear. Triggers on adding a new agent, refactoring to split capabilities, or attributing the cause of an incident.
---

# 책임 분할 (Responsibility Partitioning)

OCLS 단계: **OWN** · 각 결과의 소유자를 정하고 그 경계를 분명히 그린다.

## 핵심 규칙

- 시스템의 최종 목표를 하위 책임으로 분해하고, 각 책임을 정확히 하나의 에이전트에 할당한다.
- 분할의 기준은 "이 에이전트가 자신의 일에 대해 무엇을 설명할 수 있는가"이다.
- 각 에이전트는 자신의 범위 안에서 판단하고 실행한다. 범위 밖의 일은 명시적 핸드오프로 위임한다.
- 분할이 끝나면 각 경계에 모듈 계약을 부여한다.

## 판단 질문

**이 책임은 별도 에이전트로 분리될 만큼 독립적인가?**

## 적용 체크

1. 이 에이전트의 책임 범위를 한 문장으로 진술할 수 있는가?
2. 목표, 권한 범위, 종료 조건이 선언되어 있는가?
3. 이 에이전트가 실패할 때, 에스컬레이션 대상은 누구인가?
4. 다른 에이전트의 책임 경계와 겹치지 않는가?

## 코드 예시

```typescript
// ❌ 모든 책임을 하나의 에이전트에 몰아넣음 — 사고 원인 추적 불가
class CustomerAgent {
  async handle(msg: string) {
    const cat = await this.classify(msg);
    const reply = await this.generate(cat);
    const approved = await this.review(reply);
    return approved ? reply : await this.escalate(msg);
  }
}

// ✅ 책임 분할 + 명시적 핸드오프 — 각 에이전트를 독립적으로 평가·교체 가능
interface IntakeAgent { classify(msg: string): Promise<IntakeResult> }
interface ResponseAgent { generate(ctx: IntakeResult): Promise<Response> }
interface QAAgent { review(r: Response): Promise<QAVerdict> }
interface EscalationAgent { route(v: QAVerdict): Promise<Action> }
```

## 안티패턴

**고객 응대**: 모든 기능을 하나의 에이전트에 몰아넣고 "프롬프트로 역할을 분리"하면 역할 간 간섭이 발생한다. 분류 프롬프트를 조정하면 응답 톤이 바뀐다.

**데이터 파이프라인**: 추출 + 변환 + 검증 + 적재를 한 ETL 에이전트가 처리하면, 스키마가 한 번 바뀔 때마다 전체 파이프라인이 무너진다. extract / transform / load 에이전트로 분리하면 각각을 독립적으로 테스트하고 교체할 수 있다.

## 호출 예시

```
"CustomerAgent가 분류, 응답, 검토, 에스컬레이션을 한곳에서 모두 처리하고
있다. reopt-responsibility-partitioning을 적용해 3~4개 에이전트로 분리하고,
각 에이전트의 목표·권한·종료 조건을 한 문장으로 선언해줘."
```

## 관련 패턴

- 모듈 계약 — 분리된 각 책임에 계약을 부여한다
- 컨텍스트 라우팅 — 책임 사이로 정보를 전달하는 규칙