Named Ownership — AI 시대 책임의 단위

12% production cohort의 또 한 가지 공통 패턴. 모든 agent·skill·tool에 책임자(owner)와 성공 기준(success criteria)이 명시적으로 박힌다. 익명 swarm은 brittle, expensive, debug 불가. overview의 🤖 AI 시대 운영 표현 마지막. ship-and-rollback-as-normal의 짝. AI agent에게 책임의 단위를 정의하는 mechanism — 사람과 AI가 함께 일할 때 누가 무엇에 책임지는가의 답.

한 줄

모든 agent·skill·tool에 owner(누가 책임지는가) + success criteria(언제 끝났는가)가 명시적으로 박혀 있어야 한다. 88% pilot이 못 가는 이유 중 큰 것이 익명 AI swarm — 누가 만들었는지 모르고, 언제 끝났는지 모름. 12% 성공 cohort는 AI가 만들었어도 사람이 책임. 학내 segment에서는 학번이 자연 owner identifier, 학과·연구실이 자연 ownership boundary.

⚛️ 철학

원칙의 왜. 더 깊은 root와의 연결.

12% cohort의 두 번째 공통 패턴

research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap의 핵심 발견 (March 2026):

12% 성공 cohort의 공통 패턴 중 하나: 모든 agent·skill·tool에 named owner + scoped success criteria가 박혀 있다. 88% 실패 cohort: 익명 swarm. "AI가 만들었으니 AI가 책임" → 사실 아무도 책임 안 짐.

핵심 명제:

AI가 코드를 짰어도 사람이 owner. AI failure 시 사람이 고침. Success criteria가 없으면 agent는 언제 멈출지 모름 → 무한 loop 또는 조기 종료.

Owner와 Success Criteria의 짝

이 명제가 두 가지 mechanism을 동시에 요구:

→ 둘이 짝. owner가 기준을 정의, criteria가 기준의 측정 가능 표현. 한쪽만 있으면 반쪽 mechanism.

Ralph Loop의 verify_completion이 success criteria의 mechanism

Geoffrey Huntley의 Ralph Loop (production-grade AI agent 패턴):

def ralph_loop(task):
    while True:
        ai_agent.work(task)
        if verify_completion(task):  # ← success criteria
            break

verify_completion 함수가 success criteria의 정확한 implementation. 사람이 함수로 언제 끝났는가를 정의 → AI agent가 그 함수 통과까지 작업.

→ named-ownership = owner가 verify 함수를 작성. owner의 strategic 책임은 success criteria 정의.

"Built by AI, owned by 사람" 패턴

12% cohort의 운영 구호:

Built by AI, owned by 사람. AI가 만든 코드도 사람이 책임. AI failure 시 그 owner에게 escalate.

이게 strategic-vs-tactical-programming|strategic-vs-tactical 명제의 책임 측 표현 — AI tactical, 사람 strategic. 책임은 strategic에 속함.

다른 root와의 연결

• ship-and-rollback-as-normal — 둘 다 12% cohort 패턴. 짝
• strategic-vs-tactical-programming — 책임은 strategic 영역. AI tactical에 위임 안 됨
• bounded-context — BC 단위가 자연 ownership boundary. owner는 BC의 owner
• deep-modules — deep module의 owner = strategic 결정자. interface 정의 책임
• anti-corruption-layer — ACL의 owner는 외부 시스템 변경 모니터링 책임
• Linus's Law (Eric S. Raymond): given enough eyes, all bugs are shallow — AI 시대 변형: given enough named owners, all failures are recoverable

🧱 추상적 작동 구조

두 모델 비교

Owner의 4가지 책임

→ *4가지 모두가 strategic 활동. AI에게 위임 X. 사람의 핵심 영역.

Success Criteria의 종류

→ Success criteria가 구체적이고 측정 가능해야 AI agent가 사용 가능. *vague한 success ("잘 작동한다")*는 사용 불가.

Anthropic harnesses의 one-feature-at-a-time이 named ownership의 implementation

sources/key-articles-summary#3. Anthropic — *Effective Harnesses for Long-Running Agents*|Anthropic harnesses의 패턴:

Feature list (JSON) — 각 feature에 owner + 완료 기준. AI agent가 한 번에 한 feature만 작업.

{
  "features": [
    {
      "id": "feat-1",
      "owner": "human",
      "ai_agent": "coder-agent",
      "passes": {
        "tests": false,
        "smoke": false
      }
    }
  ]
}

→ Anthropic이 자체 production AI 도구를 위해 도달한 답이 정확히 named ownership. passes field가 success criteria, owner가 named ownership.

⚠️ 약점/한계

원칙의 적용 한계. 잘못 적용 시 함정.

1. Owner 추적 비용

매 skill·tool·agent에 owner 명시. 새로 만들 때마다 누가 책임지는가 결정. 작은 시도에도 friction.

해결: Default owner 설정. 학내 marketplace는 upload한 사람이 자동 owner. 명시적 transfer 없으면 그대로.

2. Owner 떠날 때 transfer

학내 segment 특성: 학생 졸업·휴학·전과로 owner가 자주 변경. Transfer 비용 큼.

해결: Transfer ritual + 후임자 onboarding 자료. ADR + AGENTS.md를 transfer manifest로 사용. 졸업 시점에 후임자 지정.

3. Over-formalization

작은 1회용 시도에 owner + success criteria 강제 = 친구한테 주는 종이 한 장에 인지장. 친구 관계 망가뜨림.

해결: Scale별 차등. 1회용 = no formal owner. Marketplace 공개 = formal owner 강제. 중간은 자율.

4. Success criteria 정의 어려움

어떤 게 성공인지 사전에 모름. 도메인 탐색 중에는 success criteria가 움직이는 표적.

해결: Tracer bullets로 빠르게 시도. 3번 같은 패턴 보면 그때 success criteria 박기. pattern of three.

5. AI agent에게 owner 부여 가능?

핵심 질문: AI agent도 owner가 될 수 있는가?

답: No. AI agent는:

• Failure 시 고치는 능력이 사람보다 약함 (root cause 분석)
• 지속적 책임이 어려움 (session 간 기억 없음)
• 법적·도덕적 책임 불가능

따라서 owner는 항상 사람 (개인 또는 팀). AI agent는 executor로만.

6. Bus factor

한 owner에 모든 책임 집중하면 그 사람이 떠나면 시스템 마비. ("버스에 치이면 어떡함?")

해결: Co-owner 권장. 핵심 component는 최소 2명 owner. 학내 segment에서는 주 owner + 보조 owner 패턴.

7. Owner shopping anti-pattern

명시적 owner 없는 일을 떠넘기기. "이거 owner가 없으니 너가 해" 패턴.

해결: Default owner를 upload한 사람으로. 떠넘기기 불가. 명시적 transfer만 가능.

🔄 대안 흐름

이 원칙이 적용 안 되는 시나리오와 다른 답.

대안 1 — Collective ownership (XP)

팀 전체가 owner. 누구나 수정 가능. 책임도 공동. Extreme Programming의 핵심 명제.

→ 작은 팀 / 강한 신뢰 환경에 정당. 큰 시스템에서는 공동 책임 = 무책임으로 변할 위험. 학내 동아리에 적합 가능.

대안 2 — No ownership / commons (작은 OSS)

작은 OSS 프로젝트 / 1회성 실험. 누구도 owner 아님. 자유롭게 수정.

→ Wiki 같은 것. 책임 부재가 정당한 영역. 단, production에 가져가지 못함.

대안 3 — Distributed ownership (큰 시스템)

도메인별로 다른 owner. 한 사람이 모두 책임지지 않음. bounded-context|BC 단위로 owner.

→ 12% cohort 패턴의 큰 시스템 변형. 권장 패턴.

대안 4 — Temporary ownership

Task별로 임시 owner. Task 끝나면 commons로 환원. 1회성 실험에 적합.

→ Spike, prototype에 정당. Production 도달 시점에 permanent owner로 변환.

대안 5 — Code as documentation — 코드 자체가 owner의 의도 표현

명시적 owner field 대신 git blame이 owner 추적. 코드 history가 책임 표현.

→ Modern git tooling이 암묵적 named ownership 제공. 단, 현재 owner와 역사적 contributor 구분 필요.

💡 인사이트

AI 시대 왜 지금 부활하는가 + 학내 segment 의미.

1. AI agent의 책임 부재가 88% 실패의 한 원인

전통 시스템: 코드를 짠 사람이 자연스럽게 owner. AI 시대:

"AI가 짰으니 AI가 책임" → 사실은 아무도 책임 안 짐.

이게 88% pilot 실패의 조용한 원인. 시스템에 issue 발생 → 고칠 사람 없음 → 방치 → 더 많은 issue → production 신뢰 불가 → 결국 폐기.

12% cohort 답: *AI가 짰어도 사람이 owner. AI failure를 사람이 fix. 책임이 명시적.

2. Owner가 AI agent의 행동 boundary 정의

명시적 owner가 있으면 AI agent의 행동 범위가 정의됨:

• Owner의 권한 범위에서만 AI agent 작동
• Owner가 허용한 자원만 사용
• Owner의 success criteria까지만 작업

→ *Owner = AI agent의 capability boundary 정의자. Sandbox + named ownership이 AI 안전성의 짝.

3. v1.0 design 직접 적용

→ 모든 layer에 owner + success criteria 박힘. v1.0의 책임 추적 mechanism.

4. 학내 segment의 자연스러운 정합 — 학번 = owner identifier

학내 segment에서 named ownership이 자연스럽게 정착하는 이유:

→ 학내 조직 구조 자체가 named ownership에 맞춰져 있음. v1.0이 학내에 가져다 주는 별 design 노력 없는 정합.

5. Linus's Law의 AI 시대 변형

Eric S. Raymond의 명제:

"Given enough eyes, all bugs are shallow." — Linus's Law

AI 시대 변형:

"Given enough named owners, all failures are recoverable."

OSS의 눈은 자연스럽게 *AI 시대의 책임자**로 진화. 코드를 보는 사람보다 책임지는 사람이 더 가치 — AI가 양산하는 코드 시대에는.

6. Anthropic harnesses의 named ownership 직접 implementation

sources/key-articles-summary#3. Anthropic — *Effective Harnesses for Long-Running Agents*|Anthropic feature list 패턴:

{
  "features": [
    {
      "id": "feat-1",
      "passes": {
        "tests": false,    ← success criteria
        "smoke": false
      }
    }
  ]
}

각 feature에 passes field가 success criteria. Agent가 한 번에 한 feature만 → 암묵적 owner = 그 feature. 12% cohort 패턴이 Anthropic 자체 production 도구에서 검증됨.

7. 졸업 후 owner transfer

학내 segment의 흥미로운 패턴 — 학생이 졸업 후 owner를 후임자에게 이전:

4학년 학생: 학내 도구 owner
   ↓ (졸업 시점)
3학년 후배: 새 owner

Transfer 자료:
- AGENTS.md (도구 사용법)
- ADR (왜 이렇게 design했는지)
- 후배 onboarding session

→ 학내 segment에서 owner transfer가 자연 ritual. 졸업 = 학습의 매듭 + transfer ritual. v1.0이 transfer mechanism을 도구화하면 학내 도구가 세대를 거쳐 진화.

8. AI agent에 owner 부여 = AI에게 전적 위임 거부

Named ownership의 가장 깊은 의미:

AI agent에게 책임을 위임하지 않는다는 철학적 결정.

이게 research/stateless-llm-sdk/software-fundamentals-thesis|Matt thesis의 strategic vs tactical 분할의 책임 측 표현 — 책임은 사람의 strategic 영역. AI agent는 executor. 위임하면 안 됨.

학내 segment에 가르칠 메시지:

"AI를 사용하는 자유와, 그 결과를 책임지는 의무는 분리되지 않는다. AI가 짠 코드도 너의 코드."

이게 v1.0이 학내에 가르치는 윤리. 단순 도구가 아니라 책임 모델.

9. 연구실 segment의 specific 가치

연구실에서 named ownership의 의미:

• 논문 저자 = 연구 코드의 owner
• *재현 가능성 (reproducibility)*이 owner의 핵심 책임
• 후속 연구자에게 transfer가 자연 의무

연구 코드가 재현 안 되는 가장 큰 원인 = 익명 코드 + 떠난 owner. v1.0이 연구실 owner mechanism을 도구화하면 재현 가능성 위기에 직접 기여.

10. AI 시대 새 개념 — Agent ownership chain

복잡한 시스템에서 owner chain:

사람 (이수용) → AI agent → tool call → 외부 system

각 단계가 책임 ownership chain. 외부 system fail 시 chain을 따라 사람까지 escalate. 사람이 chain의 종착점.

→ AI 시대의 법적·윤리적 책임 모델. v1.0이 audit trail로 chain 시각화하면 책임 명료성 보장.

다음에 가야 할 자리

이 노트가 호출한 다른 원칙들 — 자연스러운 다음 노트:

• tdd-as-small-deliberate-steps — test가 success criteria의 가장 작은 단위. 짝
• tracer-bullets — 작은 end-to-end가 owner의 첫 책임

→ 🤖 AI 시대 운영 표현 모두 완성. 다음은 🔄 Process 축 마무리 — TDD와 tracer bullets. tdd-as-small-deliberate-steps가 자연스러운 다음.

관련

• overview
• ship-and-rollback-as-normal — 12% cohort의 짝 패턴
• strategic-vs-tactical-programming — 책임은 strategic의 영역
• bounded-context — BC가 자연 ownership boundary
• anti-corruption-layer — ACL의 owner 책임
• research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap — 12% cohort 데이터의 직접 source
• sources/key-articles-summary#3. Anthropic — *Effective Harnesses for Long-Running Agents*|key-articles-summary — feature list가 named ownership의 implementation
• research/stateless-llm-sdk/design-principles|design-principles — 7 원칙 5번 (Named Ownership + Scoped Success Criteria)의 직접 source

Sources

직접 source (12% cohort)

• March 2026 enterprise survey — research/stateless-llm-sdk/research-to-production-gap|research-to-production-gap 노트의 정리

Ralph Loop

• Geoffrey Huntley — How to Ralph Wiggum — Ralph Loop 원전. verify_completion 함수가 핵심

AI agent에 owner 부여 (Anthropic)

• Anthropic — Effective Harnesses for Long-Running Agents — feature list / passes field

Linus's Law (인사이트 5)

• Raymond, E.S. (1999). The Cathedral and the Bazaar. — Linus's Law 원전

Code ownership 패턴 (대안)

• Extreme Programming Explained — Kent Beck. Collective ownership
• Team Topologies — Skelton & Pais. Distributed ownership

연구 reproducibility (인사이트 9)

• The Turing Way — open-source guide for reproducible research https://the-turing-way.netlify.app/