Hacker News 2026.04.05 32

성당, 시장, 그리고 윈체스터 미스터리 하우스 — 소프트웨어 개발 방법론의 세 번째 모델

에릭 레이먼드의 비유를 넘어서

소프트웨어 개발 방법론 이야기를 할 때 빠지지 않는 고전이 있어요. 에릭 레이먼드(Eric Raymond)의 1997년 에세이 《성당과 시장(The Cathedral and the Bazaar)》이에요. 이 에세이는 소프트웨어 개발을 두 가지 모델로 나눴는데요, 성당(Cathedral) 모델은 소수의 설계자가 정교한 청사진을 그려놓고 그대로 짓는 방식이에요. 전통적인 기업 소프트웨어 개발이 이런 식이죠. 반대로 시장(Bazaar) 모델은 누구나 참여할 수 있고, 시끄럽고 혼란스러워 보이지만 그 속에서 자연스럽게 좋은 결과물이 나오는 방식인데, 리눅스 같은 오픈소스 프로젝트가 대표적이에요.

그런데 최근 한 블로그 글이 이 유명한 이분법에 세 번째 모델을 제안했어요. 바로 윈체스터 미스터리 하우스(Winchester Mystery House)예요.

윈체스터 미스터리 하우스가 뭐예요?

윈체스터 미스터리 하우스는 미국 캘리포니아 산호세에 실제로 있는 건물이에요. 윈체스터 라이플로 유명한 윈체스터 가문의 상속녀 사라 윈체스터가 1886년부터 1922년 자신이 세상을 떠날 때까지 38년간 쉬지 않고 증축을 계속한 저택이에요. 결과물이 어떻게 됐냐면, 방이 161개, 계단이 40개, 문이 2,000개인데, 그중 상당수는 아무 데로도 이어지지 않아요. 벽을 향해 열리는 문, 바닥으로 떨어지는 계단, 천장이 너무 낮아서 들어갈 수 없는 방 같은 것들이 가득하죠.

전체적인 설계도는 없었어요. 그냥 매일매일 "여기에 방을 하나 더 붙이자", "저기에 계단을 올리자" 하면서 끊임없이 덧붙인 결과예요. 개별 방 하나하나는 나름 잘 지어져 있는데, 전체적으로 보면 도무지 이해할 수 없는 구조가 된 거예요.

소프트웨어에서의 윈체스터 미스터리 하우스

이 비유가 소프트웨어 개발에 적용되면 굉장히 날카로워져요. 성당 모델도 시장 모델도 아닌 세 번째 유형의 프로젝트가 분명히 있거든요. 끊임없이 기능을 추가하고 확장하지만, 전체적인 비전이나 아키텍처 없이 그냥 계속 덧붙이기만 하는 프로젝트. 겉보기에는 활발하게 개발되고 있는 것 같고, 커밋도 열심히 찍히고, 릴리스도 꾸준히 나오는데, 막상 전체 구조를 보면 "이게 왜 이렇게 돼 있지?"라는 의문만 남는 코드베이스요.

글쓴이는 이런 특징들을 짚어요. 첫째, 건축이 멈추지 않아요. 리팩토링이나 삭제는 거의 일어나지 않고, 새 기능만 계속 추가돼요. 레거시 코드를 정리하는 것보다 새 코드를 옆에 붙이는 게 항상 우선이에요. 둘째, 개별 부분은 괜찮아 보여요. 각각의 PR이나 기능 단위로 보면 나름 잘 짜여 있는데, 이것들이 모여서 만들어내는 전체 시스템은 일관성이 없어요. 셋째, 아무도 전체 그림을 모르는 경우가 많아요. 팀원 각자는 자기가 담당하는 영역만 알고, 시스템 전체를 이해하는 사람이 없어요.

이건 성당 모델(계획이 너무 많아서 실행이 느린 것)의 반대 문제이면서, 시장 모델(다양한 참여자가 자연스럽게 합의에 이르는 것)과도 달라요. 시장에서는 경쟁과 선택을 통해 좋은 것이 살아남지만, 윈체스터 미스터리 하우스에서는 한번 붙인 것은 절대 떼어내지 않아요. 그냥 계속 쌓이기만 해요.

왜 이런 일이 벌어질까요?

이 패턴이 생기는 원인은 여러 가지인데요, 가장 큰 건 "기능 추가 = 진보"라는 착각이에요. 제품 로드맵이 항상 새 기능 중심으로 짜여 있고, 기술 부채를 갚거나 기존 코드를 리팩토링하는 건 "비생산적"이라고 여기는 조직 문화가 있으면 자연스럽게 이렇게 되거든요.

또 하나는 삭제에 대한 두려움이에요. "이거 지워도 되나?"라는 질문에 확신을 갖기 어려우니까, 안전하게 그냥 놔두고 새 코드를 옆에 쓰는 거예요. 테스트 커버리지가 낮거나, 시스템의 의존 관계를 파악하기 어려운 프로젝트일수록 이런 경향이 강해요.

프로젝트 매니저나 경영진 입장에서도, 기존 기능을 리팩토링하는 것보다 새 기능을 추가하는 게 더 "보이는 성과"이기 때문에 이런 방향으로 압력이 가해지기 쉬워요.

업계 맥락: 이 비유가 닿는 곳

소프트웨어 아키텍처 논의에서 이런 문제를 다루는 개념들이 이미 꽤 있어요. 마틴 파울러(Martin Fowler)의 기술 부채(Technical Debt) 개념이 대표적이고, 최근에는 "소프트웨어 엔트로피"라는 표현도 자주 쓰여요. 시스템에 변경을 가할수록 무질서도가 높아진다는 거죠.

마이크로서비스 아키텍처의 유행도 이 맥락에서 볼 수 있어요. 모놀리스가 윈체스터 미스터리 하우스처럼 되는 걸 막으려고 서비스를 쪼개는 건데, 아이러니하게도 마이크로서비스 전체가 하나의 거대한 윈체스터 미스터리 하우스가 되어버리는 경우도 있거든요. 각 서비스는 잘 설계되어 있는데, 서비스 간의 관계가 누구도 파악할 수 없는 미로가 되는 거예요.

한국 개발자에게 주는 시사점

이 비유는 자기가 속한 프로젝트를 진단하는 도구로 쓸 수 있어요. "우리 프로젝트가 성당인가, 시장인가, 윈체스터 미스터리 하우스인가?" 한 번 생각해 보세요.

만약 윈체스터 미스터리 하우스에 가깝다면, 실천할 수 있는 것들이 있어요. "지금 우리 시스템의 전체 아키텍처를 화이트보드에 그릴 수 있는 사람이 있는가?" 이 질문에 "아니오"가 나오면 위험 신호예요. 정기적인 아키텍처 리뷰, 의도적인 삭제(코드 정리 스프린트), 기술 부채 백로그 관리 같은 관행이 필요한 시점이에요.

스타트업 초기에는 빠르게 기능을 쌓아올리는 것이 당연히 우선이지만, 어느 시점이 되면 "멈추고 정리하는 시간"을 의도적으로 확보하지 않으면 시스템이 감당할 수 없는 복잡성에 도달해요. 윈체스터 미스터리 하우스는 38년간 지었지만, 소프트웨어에서는 훨씬 빨리 그 지점에 도달하거든요.