오너십을 코드에 다는 법

코드 오너십이라는 개념이 있다. 어떤 코드의 변경, 품질, 동작을 누가 책임지는가 하는 것이다. 작은 팀에서는 모두가 모든 것을 알아야 하니까 오너십을 따질 필요가 없다고 생각하기 쉽다.

그런데 실제로는 그 반대였다. 오너십이 불분명하면 3명짜리 팀에서도 아무도 모르는 코드가 생긴다.

오너십이 없을 때 생기는 것

팀에 합류한 지 얼마 안 된 코드가 있다. 이 코드가 왜 이렇게 생겼는지, 누가 건드렸는지 아무도 기억하지 못한다. 버그가 생기면 “이거 누가 만들었지?” 하고 git blame을 먼저 찾게 된다.

더 큰 문제는 이 코드를 고쳐야 할 때 아무도 선뜻 나서지 않는다는 것이다. 건드렸다가 다른 곳이 깨질 수도 있고, 왜 이렇게 만들었는지 맥락을 모르니 어디까지 수정해도 되는지 알 수가 없다. 결국 아무도 안 고치고 기술 부채만 쌓인다.

우리가 한 것 — 파일 단위 주석

가장 단순한 방법부터 시작했다. 각 주요 파일이나 모듈 상단에 담당자를 명시하는 주석을 달았다. 팀 전원이 공동으로 관리하는 코드도 있고, 특정 사람이 주 담당인 코드도 있다.

# owner: mings
# 마지막 주요 변경: 2026-03-15
# 목적: 외부 API 연동 어댑터

이것만으로도 변화가 생겼다. 코드에 이름이 붙으면 그 이름의 사람이 해당 코드에 더 신경을 쓰게 된다. 코드 리뷰에서도 “이 파일 담당자 의견 확인했어?” 하는 대화가 자연스럽게 생겼다.

CODEOWNERS 파일

주석보다 좀 더 체계적인 방법으로 CODEOWNERS 파일을 사용했다. 저장소 루트에 파일을 만들고, 디렉토리 또는 파일 패턴별로 담당자를 지정한다.

/src/api/ @mings
/src/infra/ @slecs
/src/ui/ @slecs

이 파일이 있으면 해당 경로의 파일이 변경됐을 때 자동으로 담당자가 리뷰어로 지정된다. 리뷰 요청이 자동화되고, 변경 전에 담당자 확인이 되니 사후에 “이렇게 바꿨냐”는 대화가 줄었다.

오너십은 독점이 아니다

오너십을 명시한다고 해서 다른 사람이 그 코드를 건드릴 수 없다는 의미가 아니다. 긴급한 수정이 필요하면 누구든 할 수 있다. 다만 그 변경 사실을 담당자에게 알리고, 담당자가 나중에 검토할 수 있게 한다.

오너십은 책임의 위치를 명확히 하는 것이지, 코드의 접근을 막는 것이 아니다. 이 구분이 팀에서 받아들여지면 오너십 제도가 제대로 작동한다.

— by mings