research

Orthogonality — 변경의 전파 차단, AI agent에게 reasoning 공간 주기

Orthogonality — 변경의 전파 차단, AI agent에게 reasoning 공간 주기

Hunt & Thomas The Pragmatic Programmer (1999) 핵심 원칙. 서로 무관한 변경이 서로 무관해야 한다. 한 곳 수정이 다른 곳에 cascading 안 되게 design. overview의 🔄 Process 축 시작. Ian Bull의 Sinks vs Pipes metaphor가 AI 시대 표현. AI agent에게 isolation에서 reasoning할 공간을 주는 mechanism.

한 줄

한 component의 변경이 다른 component에 영향을 주지 않는 design. 어원은 수학의 직교 — 두 벡터가 90도면 한 벡터 변화가 다른 벡터에 사영되지 않음. AI 시대에는 pipes (cascading side effect) → sinks (contained effect) 흐름의 직접 표현. AI agent는 blast radius가 contained된 module에서만 안전하게 reasoning할 수 있음.

⚛️ 철학

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

Pragmatic Programmer의 정의

"In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others."

— Hunt & Thomas, The Pragmatic Programmer (1999)

핵심 명제:

한 component의 변경이 다른 component에 영향을 주지 않으면 두 component는 orthogonal하다.

수학적 직관:

소프트웨어 단위에서:

  • 변경 (한 곳 수정 → 다른 곳 영향 0)
  • 의존 (한 곳 의존이 다른 곳 의존을 강제 X)
  • 책임 (한 책임이 한 module에만)

AI 시대 표현 — Sinks vs Pipes

sources/key-articles-summary#5. Ian Bull — *Sinks, Not Pipes*|Ian Bull 명제가 정확히 orthogonality의 AI 시대 metaphor:

"A pipe is a component that does its work and then triggers something else... To understand what a pipe does, you have to follow the entire chain."

"A sink is a component that receives input, does its work, and stops. Its effects are contained."

Pipe (비-orthogonal)Sink (orthogonal)
한 동작이 cascade trigger한 동작이 contained
변경 시 체인 전체 영향변경 시 자기만 영향
AI가 전체 체인을 알아야 함AI가 하나만 알면 됨
Blast radius 큼Blast radius 작음

→ Orthogonality = sink-only architecture. AI 시대의 가장 직접적 implementation.

다른 root와의 연결

  • information-hiding — secret이 잘 격리되면 자연스럽게 orthogonal. Hiding이 orthogonality의 mechanism
  • information-leak-vs-abstraction — leak이 orthogonality 위반의 직접 신호. Leak ↔ cross-component 영향
  • anti-corruption-layer — 외부 변화에 대한 orthogonality 보장. ACL이 외부와 내부를 직교로
  • bounded-context — BC 사이 orthogonality. 한 BC 변경이 다른 BC 영향 X
  • simple-not-easy — Hickey의 *complect (얽힘)*가 정확히 orthogonality 위반. 같은 명제의 다른 표현
  • reversibility — orthogonal 시스템이 결정 되돌리기 쉬움. 직교가 reversibility의 mechanism

🧱 추상적 작동 구조

변경 전파의 두 시나리오:

직교 측정 — 변경 전파 그래프

Orthogonality를 측정 가능하게 만드는 도구:

1. Git history에서 함께 변경된 파일 추적
   (git log --name-only로 commit별 파일 묶기)

2. *함께 변경되는 빈도가 높은* 파일 쌍 식별
   → 그 쌍이 *비-orthogonal* 신호

3. 그 쌍을 *같은 module로 모음* 또는 *interface로 격리*

Modern 도구:

  • CodeScene — git history로 temporal coupling 시각화
  • NDepend (.NET) — 의존 그래프
  • Bazel build graph — explicit dependency

Pragmatic Programmer의 Helicopter test

직교 측정의 직관 도구:

이 component를 헬기로 들어 올려서 옆 시스템에 떨어뜨릴 수 있는가? 다른 변화 없이 작동하는가?

답이 Yes → orthogonal. No → 다른 component에 묶임.

직교의 의존 그래프 — 단방향 vs 양방향

→ Orthogonality는 단방향 의존이 mechanism. 순환 의존은 비-orthogonal의 가장 명료한 신호.

⚠️ 약점/한계

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

1. 완벽한 직교는 불가능

도메인 자체가 본질적으로 얽힌 경우 있음:

  • 결제 ↔ 주문 (성공/실패가 강하게 묶임)
  • 인증 ↔ 권한 (한 변경이 다른 변경 강제)

해결: Essential coupling은 인정하고 한 module 안에 모음. accidental coupling만 직교화.

2. 직교 강제가 over-engineering

작은 시스템에 직교 강제하면 indirection 폭발. 매 component마다 interface, 매 호출마다 dependency injection. 학습 곡선 + 코드량 증가.

해결: *Rule of three + 변화 압력 측정. 직교의 가치는 변화에 강함. 안 변하면 직교 가치 0.

3. Performance overhead

직교 위해 추가 indirection layer가 들어가면:

  • 함수 호출 overhead
  • Allocation 증가
  • Cache miss 가능

→ Hot path에서는 의도적 coupling이 정당.

4. 직교 측정의 사전 어려움

변경 전파를 사전에 알기 어려움. 지나봐야 어디가 함께 변하는지 알 수 있음. 직교 design은 예측 의존.

해결: Git history가 가장 좋은 측정. 6개월 후 함께 변경된 파일을 확인하고 그때 refactor.

5. AI 시대 specific — AI agent의 implicit coupling 양산

AI agent가 코드 짤 때 implicit coupling을 의식 못함:

  • "이 함수가 저 모듈의 state를 암묵적으로 가정"
  • "이 변경이 저쪽 logic을 깨는데 AI는 모름"

해결: Test가 직교의 강제 mechanism. AI가 변경하면 모든 test 실행 + fail이 직교 위반 신호. tdd-as-small-deliberate-steps|TDD가 AI 시대 직교의 동반 도구.

6. Premature orthogonality

도메인 이해 전에 직교 강제 → 잘못된 경계. 6개월 후 발견하고 다시 refactor. 비용 폭발.

해결: Tracer bullets (tracer-bullets)로 빠르게 탐색. 도메인이 3번 같은 패턴을 보이면 그때 직교화.

🔄 대안 흐름

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

대안 1 — Pragmatic coupling

의도적 coupling이 정당한 경우:

  • 성능 (zero-copy, shared buffer)
  • 도메인 본질적 (결제 ↔ 주문)
  • 작은 시스템 (over-engineering 회피)

→ 직교 반대가 아니라 맥락별 선택. 직교를 기본값으로 두되, 명시적으로 coupling 선택.

대안 2 — Microservices가 직교 강제

서비스 경계가 자연스러운 orthogonality. 한 서비스 변경 → 다른 서비스 무관 (API 호환만).

→ Architecture 단위 직교. 강력하지만 운영 비용 큼.

대안 3 — Functional core, imperative shell (Bernhardt)

순수 함수형 core + 외부 effect는 shell에서. core가 자연스럽게 orthogonal.

→ paradigm 단위 직교. Functional 영향 강한 modern 언어 (Rust, Swift, Kotlin)와 정합.

대안 4 — Event-driven

직접 의존 대신 event로 통신. component A가 event 발행, B가 subscribe. 컴파일 타임 의존 없음.

→ 직교 강함. 단, eventual consistency, 디버깅 어려움.

대안 5 — Direct integration (작은 시스템)

직교 무시. 모든 component가 서로 직접 호출. 작은 시스템에 정당.

→ Premature orthogonality 회피. 시스템 크기 증가하면 점진 직교화.

💡 인사이트

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

1. AI agent의 cascading side effect 양산 위험

AI agent의 자연 경향:

  • 매 prompt마다 새 import 추가
  • 매 task마다 새 의존 만들기
  • Implicit coupling을 의식 못함

→ 누적되면 비-orthogonal 시스템이 양산됨. deep-modules#인사이트의 shallow 양산 약점이 cross-module 단위에서 다시 나타남.

2. 직교가 AI agent에게 reasoning 공간 제공

sources/key-articles-summary#5. Ian Bull — *Sinks, Not Pipes*|Bull 명제 다시:

"If your components are sinks, the AI can reason about them in isolation. It can read the interface, understand the contract, write or modify the implementation, run the tests, and move on. The blast radius of any change is contained."

비-orthogonal 시스템에서 AI는 전체 체인을 한 context window에 담아야 함 → 불가능. Orthogonal 시스템에서 AI는 하나의 module만 담으면 됨 → reasoning 가능.

→ Orthogonality는 AI agent에게 작업 단위를 제공하는 mechanism. Bounded context와 같은 정신, 다른 단위.

3. v1.0 design 직접 적용 — Crate 단방향 의존

my-cli (binary)
   ↓
llm-loop (high level)
   ↓
llm-providers (mid level)
   ↓
llm-core (foundation)

원칙:

  • 위 → 아래만 의존
  • 역방향 의존 금지 (cargo가 강제)
  • 한 crate 변경 → 위 crate만 영향. 아래는 무관

→ Crate 단방향 의존이 가장 명료한 orthogonality 강제. Rust의 cargo 시스템이 언어 차원에서 orthogonality 강제. Java/Python 같은 언어에서는 명시적 노력이 필요한 게 Rust에서는 기본.

4. Hooks layer가 orthogonality의 mechanism

research/stateless-llm-sdk/design-principles|7 원칙의 hooks layer는 직교의 운영 표현:

event publish (모듈 A) → hook execution → event subscribe (모듈 B)

A는 B를 모름. B는 A를 모름. 둘 다 event spec만 알면 됨.

→ Hooks가 orthogonality를 운영 차원에서 보장. v1.0의 lifecycle event가 그 implementation.

5. Skill 사이 orthogonality

각 SKILL.md가 self-contained. 한 skill 변경 → 다른 skill 무관:

  • skill A의 변경이 skill B를 깨지 않음
  • 신규 skill 추가가 기존 skill 영향 X
  • Marketplace에서 각 skill이 독립 install·uninstall

→ Marketplace의 경제적 가치가 직교에 직접 비례. 비-orthogonal한 skill ecosystem은 변경마다 모든 skill 영향 → 사용자가 업데이트를 두려워. 직교가 trust의 mechanism.

6. 학내 segment 가치 — 도구 사이 trust

학생이 학내 도구 여러 개를 사용:

  • 수강신청 도구
  • 시간표 짜기 도구
  • 졸업요건 검증 도구
  • 성적 분석 도구

비-orthogonal: 한 도구 업데이트 → 다른 도구가 깨질 수 있음 → 학생이 업데이트를 두려워함 → 도구 채택 저하.

Orthogonal: 한 도구 업데이트 → 그 도구만 영향 → 학생이 안심하고 업데이트 → 채택 가속.

→ 학내 segment의 도구 채택 자체가 orthogonality에 직접 의존. 사용자 trust = 직교의 함수.

7. 변경 전파 그래프가 직교 self-test

매 sprint 끝에:

  • git log --name-only 분석
  • 함께 변경된 파일 빈도 측정
  • 빈도 높은 쌍 = 비-orthogonal 신호
  • 그 쌍을 refactor 후보로

→ 직교는 지속적 측정 + refactor가 mechanism. 한 번 design하고 끝나는 게 아니라 진화의 도구.

8. Hickey 명제의 직교 표현

simple-not-easy 핵심: complect (얽힘) 제거. 직교의 정확한 표현:

Complect = orthogonality 위반. 두 component가 얽혀 있으면 orthogonal하지 않음.

Hickey의 simple = 완전 직교 시스템. 매 component가 one role, one task, one dimension. 14 원칙의 통합성이 또 확인됨.

9. AI 시대 새 직교 단위 — Session-level orthogonality

기존 직교: 영구 architectural 단위. AI 시대 추가: AI session level.

각 AI session이 서로 직교해야:

→ AI 시대의 새 orthogonality 단위. v1.0이 session 단위 직교를 기본값으로 두면 long-running agent 안정성 확보.

다음에 가야 할 자리

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

→ 🔄 Process 축 두 번째로 reversibility가 자연스러움. orthogonality와 짝.

관련

Sources

직접 source

  • The Pragmatic Programmer: 20th Anniversary Edition — Hunt & Thomas (2019). Tip 13 Eliminate Effects Between Unrelated Things. 한국어판 《실용주의 프로그래머: 20주년 기념판》 (인사이트)
  • The Pragmatic Programmer 1st edition (1999) — orthogonality 원전 챕터

AI 시대 표현

측정 도구 (인사이트 7)

  • Your Code as a Crime Scene — Adam Tornhill. Temporal coupling 측정 방법론
  • CodeScene tool — Tornhill의 회사

대안 패러다임

  • Functional Core, Imperative Shell — Gary Bernhardt. talk
  • Building Microservices — Sam Newman
  • Hexagonal Architecture — Alistair Cockburn (대안 4의 architectural 표현)
← research 목록으로홈으로