노트

집단 코드 소유

Collective Code Ownership

개발 문화#agile · 연결된 개념 11개

쉽게 말하면

집단 코드 소유는 공동 텃밭을 모두가 함께 가꾸는 거예요. 내 구역 네 구역 없이 시든 데를 본 사람이 바로 물을 줘서, 한 사람이 빠져도 밭이 멈추지 않아요.

비유가 깨지는 곳 아무나 아무렇게나 파헤쳐도 된다는 뜻은 아니에요. 자동화 테스트, 통일된 코딩 규칙, CI와 코드 리뷰, 페어 프로그래밍이 같이 있어야 누구나 고치고 누구나 품질에 책임져요.

익스트림 프로그래밍(Extreme Programming, XP)의 실천법으로, "이 모듈은 A 담당"처럼 개인에게 소유권을 두지 않고 팀 전체가 코드 전체를 소유하는 방식이다. 주문 기능을 만들다 쿠폰 코드를 고쳐야 하면 담당자에게 요청하지 않고 직접 고친다.

소유권의 세 가지 형태 (마틴 파울러의 분류)

형태의미
강한 소유 (strong)담당자만 그 코드를 수정할 수 있다
약한 소유 (weak)담당자는 있지만 다른 사람도 수정할 수 있다
집단 소유 (collective)담당자 없이 팀 전체가 공동 소유한다

얻는 것

  • 지식 사일로(Knowledge Silo)와 버스 팩터(Bus Factor) 해소: "결제는 B님만 알아요" 상태에서 B가 자리를 비우면 아무도 못 고친다. 여러 사람이 만지며 이해가 퍼진다
  • 병목 감소: 다른 모듈 수정 때문에 담당자를 기다리지 않는다
  • 리팩터링이 쉬워진다: 여러 모듈에 흩어진 중복을 경계를 넘어 한 번에 정리할 수 있다 → 리팩터링, 산탄총 수술과 뒤엉킨 변경

함께 있어야 하는 안전장치

누구나 아무렇게나 고친다는 뜻이 아니다. XP에서는 다른 실천법과 맞물려야 작동한다.

  • 자동화 테스트 → 자가 테스트 코드
  • 통일된 코딩 규칙
  • 지속적 통합(Continuous Integration, CI)과 코드 리뷰
  • 짝을 바꿔 가며 하는 페어 프로그래밍

그래서 "누구나 고칠 수 있다"와 "누구나 품질에 책임진다"가 한 묶음이다.

현실적인 절충

결제, 보안, 정산처럼 전문성이 필요한 영역은 수정 권한은 팀 전체에 두되 리뷰는 경험자가 참여하게 할 수 있다. 파울러의 분류로는 약한 소유에 가까워지지만, 수정 권한과 리뷰 책임을 나눠 생각하는 것이 핵심이다. 파울러는 셋 중 강한 소유를 가장 꺼리고, 약한 소유와 집단 소유는 둘 다 잘 돌아갈 수 있지만 개인적으로는 집단 소유를 선호한다고 말한다.

본질은 수정 권한의 문제가 아니라 팀 안에서 지식과 책임을 나누는 것이다. 『함께 자라기』의 표현으로는 좋은 통찰은 한 명만 있어도 퍼지고, 실수는 여러 사람이 모두 놓쳐야만 새어 나가는 구조다 → 함께 자라기 (책 개요). 팀 구조가 코드 구조를 닮는다는 콘웨이의 법칙와도 연결된다.

출처: CodeOwnership Martin Fowler

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 코드 냄새

    당장 버그는 아니지만 이해나 변경 비용을 높이는 구조적 신호. 리팩터링을 언제 시작하고 멈출지에 정확한 공식은 없어서, 냄새라는 어휘로 직관을 공유한다.

  • 의존성 역전 원칙

    고수준 모듈(업무 규칙)이 저수준 모듈(데이터베이스(DB), HTTP(Hypertext Transfer Protocol) 클라이언트 같은 세부 구현)에 직접 의존하지 않고, 둘 다 추상화에 의존해야 한다는 원칙. 의존 방향이 "업무 → 세부"에서 "세부 → 추상화 ← 업무"로 뒤집힌다.

  • 변경하기 쉬운 프런트엔드 코드

    Frontend Fundamentals는 "좋은 프런트엔드 코드 = 변경하기 쉬운 코드"라는 관점에서 가독성(Readability)·예측 가능성(Predictability)·응집도(Cohesion)·결합도(Coupling) 네 기준과 구체적인 기법을 정리한 공개 가이드다. 네 기준은 서로 부딪치기도 해서 상황에 맞게 무엇을 우선할지 고르는 것이 핵심이다.

  • 결합도

    한 요소를 바꿀 때 다른 요소도 바꿔야 하는 관계. 결합도는 언제나 "어떤 변경에 대해" 결합되어 있는지를 함께 말해야 의미가 있다. 같은 두 모듈도 어떤 변경에는 묶여 있고 어떤 변경에는 독립적일 수 있다.

  • 구성요소 줄이기

    셀 수 있는 모든 구성요소(파일, 폴더 깊이, 클래스, 함수, 분기, 변수, 테이블, 필드, 테스트 케이스…)는 비용이라는 관점. 심플 디자인의 네 번째 규칙을 실무 기준으로 풀어낸 것이다.

보기 옵션