reopt-responsibility-partitioning

---
name: reopt-responsibility-partitioning
description: 여러 에이전트가 공동 작업하거나 역할 경계가 불명확할 때. 새 에이전트 추가, 기능 분리 리팩토링, 장애 원인 분석 상황에서 트리거.
---

# 책임 분할 (Responsibility Partitioning)

OCLS 단계: **OWN** · 결과를 소유할 주체와 책임 경계를 명확히 정의한다.

## 핵심 규칙

- 시스템의 최종 목표를 하위 책임으로 분해하고, 각 책임을 하나의 에이전트에 배정한다.
- 분할 기준은 "이 에이전트가 무엇을 설명할 수 있는가"이다.
- 각 에이전트는 책임 범위 내에서 독립적으로 판단·실행하고, 범위 밖은 명시적 핸드오프로 위임한다.
- 분할 후 각 경계에 Module Contract를 부여한다.

## 판단 질문

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

## 적용 체크

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 에이전트가 추출·변환·검증·적재를 모두 수행하면 스키마 변경 시 전체 파이프라인이 무너진다. 추출·변환·적재 에이전트로 분리하면 각각 독립적으로 테스트·교체 가능하다.

## 호출 예시

```
"CustomerAgent가 분류·응답·검토·에스컬레이션을 전부 하고 있어.
reopt-responsibility-partitioning으로 3-4개 에이전트로 분할하고,
각 에이전트의 목표·권한·종료 조건을 한 문장씩 명시해줘."
```

## 관련 패턴

- Module Contract — 분리된 책임마다 계약 부여
- Context Routing — 책임 간 정보 전달 규칙