"Best practice" 가 아니라 트레이드오프

"best practice" 라는 말은 종종 의문 없이 적용되지만, 모든 환경에 똑같이 들어맞는 단일한 답은 드뭅니다. 이 글은 맥락 의존성을 보여 주는 세 고전 (CAP · PACELC · Conway's Law) 의 사실.

1. 트레이드오프의 자리

소프트웨어 결정 대부분은 트레이드오프. 더 빠른 응답을 얻으면 일관성이 약해지고, 더 강한 일관성을 얻으면 가용성이 떨어짐. 더 작은 PR 은 리뷰가 빠른 반면 큰 변경의 의도를 한 호흡에 전달하기 어려움.

"best practice" 는 어떤 맥락에서 자주 잘 동작했다는 사후 관찰일 뿐, 다른 맥락에 그대로 옮겨질 보장은 없습니다. 맥락에는 팀 크기 · 팀 분산도 · 도메인 · 운영 인력 · 규제 · 예산 · 코드 수명이 포함.

2. CAP

Eric Brewer 가 1998 년 처음 발표하고 2000 년 PODC 키노트에서 정리한 정리. 2002 년 Seth Gilbert 와 Nancy Lynch 가 형식적 증명을 발표.

명제 — 네트워크 분산 데이터 저장소는 다음 셋을 동시에 모두 보장할 수 없음:

• Consistency — 모든 읽기가 가장 최근 쓰기를 보거나 에러를 반환.
• Availability — 모든 정상 노드가 요청에 응답 (데이터 최신성 보장은 별개).
• Partition tolerance — 네트워크 메시지가 지연 · 유실돼도 시스템이 계속 동작.

분할이 발생할 가능성이 있는 실제 분산 시스템은 P 를 포기할 수 없으므로, 분할 시점에 C 와 A 중 하나를 선택하게 된다는 의미로 자주 인용.

Brewer 본인이 2012 년 글 "CAP Twelve Years Later" 에서 "둘 중 둘 선택" 이라는 단순화가 오해를 부른다고 정정. 실제 시스템은 분할이 없는 평소에 두 속성을 모두 가깝게 만족시키고, 분할 시점의 행동만 선택할 뿐입니다.

대표 분류:

• CP — MongoDB (기본 설정) · HBase · ZooKeeper.
• AP — Cassandra · CouchDB · DynamoDB (설정에 따라).

3. PACELC

Daniel Abadi 가 2010 년 글 "Problems with CAP" 와 2012 년 IEEE Computer 논문 "Consistency Tradeoffs in Modern Distributed Database System Design" 에서 제안:

If Partition: choose A or C
Else (정상 동작 시): choose Latency or Consistency

CAP 가 다루지 않는 평시의 트레이드오프 (지연 vs 일관성) 까지 포괄. 강한 일관성 복제는 평시에도 추가 라운드트립을 요구해 지연이 늘어나는 경향.

PACELC 의 시각은 "best practice" 가 환경에 따라 달라진다는 점을 보여 줍니다. 같은 DB 라도 어떤 일관성 수준 · 어떤 복제 토폴로지로 운영하느냐에 따라 분류가 달라짐.

4. Conway's Law

Melvin Conway 의 1968 년 논문 "How Do Committees Invent?" 의 한 줄:

"Any organization that designs a system... will inevitably produce a design whose structure is a copy of the organization's communication structure."

조직의 의사소통 구조가 결국 시스템 구조를 닮는다는 관찰. 시스템 설계 결정의 다수가 사실 조직 결정이라는 함의.

Inverse Conway Maneuver (Lewis & Fowler 등이 정리) 는 원하는 시스템 구조가 있다면 그에 맞춰 팀 구조를 먼저 바꾼다는 의도적 적용. Team Topologies (Skelton & Pais, 2019) 가 이 시각을 팀 운영 패턴으로 정리.

5. 트레이드오프를 의식한 결정

다음 자문이 도움:

1. 이 결정이 무엇을 포기하는가? — 모든 결정은 무엇 하나를 얻고 다른 것을 비킴.
2. 현재 환경에서 그 비용을 감당할 만한가? — 같은 결정도 팀 규모 · 운영 인력에 따라 비용이 다름.
3. 되돌릴 수 있는가? — 일방통행 결정은 신중히, 양방향 결정은 빠르게 (Bezos "one-way vs two-way doors" 비유).
4. 누구의 best practice 인가? — Google 의 best practice 가 5 인 팀에 그대로 통하지 않는 일이 흔함.

6. 다른 표현

"best practice" 라는 말 대신 자주 사용되는 표현:

• good default — 다른 정보가 없을 때 시작점.
• fit for purpose — 목적에 적합한.
• context-dependent — 맥락에 의존하는.

이 표현들이 더 정직한 이유는 결정의 책임을 맥락 평가에 돌려 두기 때문.

7. 자주 걸리는 자리

"X 는 best practice 라서" 만으로 결정을 정당화하면, 그 X 가 등장한 환경과 현재 환경의 차이를 보지 않게 됨.

큰 회사의 사례 (Google · Netflix · Spotify) 는 그 회사의 규모 · 문화에서 자란 해법. "Spotify 모델" 이 정작 Spotify 내에서도 변형된 채로 운영된다는 보고가 여러 차례.

CAP / PACELC 는 분산 시스템에 대한 기술적 트레이드오프이며, 모든 시스템이 분산은 아님. 단일 노드 시스템에서 CAP 를 인용하는 것은 오해.

트레이드오프 의식이 결정을 지연시키는 분석 마비로 가는 경우 — 자문은 명확한 결정을 위한 도구이지 끝없는 비교의 도구가 아님.

하고픈 말

"best practice" 라는 말 자체가 책임을 회피하는 단어가 될 수 있습니다. 모든 결정에는 트레이드오프가 있고, 같은 결정도 환경에 따라 비용이 다름. CAP · PACELC · Conway's Law 셋은 이 사실을 가장 자주 보여 주는 고전. "왜 이 자리인가" 를 적어 두면 미래의 자신과 동료가 결정을 다시 평가할 수 있는 자리.

Next

• progressive-refactor
• docs-for-agent-and-human

Wikipedia CAP theorem · Eric Brewer CAP Twelve Years Later · Daniel Abadi Consistency Tradeoffs (PDF) · Melvin Conway How Do Committees Invent? · Team Topologies 공식 사이트 · Martin Fowler Inverse Conway Maneuver · Will Larson Engineer's Guide to Best Practices 를 참고합니다.