소프트웨어 엔지니어링의 법칙들: 우리가 매일 부딪히는 개발 세계의 물리 법칙

코드를 짜다 보면 반복해서 만나는 현상들

개발을 몇 년 하다 보면 이런 경험 있지 않으세요? "분명히 간단한 기능인데 왜 이렇게 오래 걸리지?", "팀에 사람을 더 뽑았는데 오히려 일정이 늦어지네?", "회의에서 나누는 얘기가 코드 구조랑 신기하게 닮아있네?" 이런 현상들을 관찰해서 정리한 것이 바로 '소프트웨어 엔지니어링의 법칙들'이에요. lawsofsoftwareengineering.com 이라는 사이트에서는 이런 법칙들을 한곳에 모아서 누구나 쉽게 찾아볼 수 있게 정리해 두었거든요.

이게 왜 중요하냐면, 경험 많은 시니어가 직감으로 알고 있는 것들을 이름 붙여서 정리하면 주니어 개발자도 훨씬 빠르게 배울 수 있어요. "왜 안 되는지 모르겠지만 하지 마세요"가 아니라, "이건 브룩스의 법칙 때문이에요"라고 설명할 수 있으면 소통이 훨씬 매끄러워지죠.

꼭 알아둘 만한 대표 법칙들

브룩스의 법칙(Brooks's Law) 은 가장 유명한 법칙인데요, "늦어진 프로젝트에 인력을 더 투입하면 더 늦어진다"는 내용이에요. 왜 그런가 하면, 새로 합류한 사람을 가르치느라 기존 팀원의 시간이 빠지고, 사람이 많아질수록 서로 커뮤니케이션하는 비용이 기하급수적으로 늘어나기 때문이에요. 10명이 모이면 의사소통 경로가 45개나 생기거든요.

콘웨이의 법칙(Conway's Law) 은 더 흥미로워요. "시스템 구조는 그 조직의 커뮤니케이션 구조를 닮는다"는 건데요, 예를 들어 백엔드 팀, 프론트엔드 팀, DBA 팀이 따로 있으면 자연스럽게 3계층 아키텍처가 나오게 돼요. 마이크로서비스가 유행한 이유도 작은 팀 여러 개가 각자 서비스를 소유하는 조직 구조와 맞물렸기 때문이고요. 그래서 요즘은 이걸 거꾸로 이용해서 원하는 아키텍처에 맞춰 조직을 먼저 설계하는 '역 콘웨이 전략'을 쓰기도 해요.

호프스태터의 법칙(Hofstadter's Law) 도 빼놓을 수 없죠. "항상 예상보다 오래 걸린다. 호프스태터의 법칙을 감안해서 계산해도 그렇다." 이 재귀적인 문장이 핵심이에요. 우리가 "2주 걸리겠지" 하고 버퍼를 3주로 잡아도 결국 4주가 걸리는 그 현상을 완벽하게 포착한 표현이거든요.

구달의 법칙(Goodhart's Law) 은 성과 지표를 만들 때 꼭 기억해야 해요. "지표가 목표가 되는 순간, 그것은 더 이상 좋은 지표가 아니다." 코드 커버리지를 80%로 강제하면 의미 없는 테스트가 양산되고, PR 개수로 평가하면 작은 PR을 쪼개서 올리게 되는 그런 현상이죠.

법칙을 아는 것과 쓰는 것은 다르다

이런 법칙들을 그냥 외우기만 하면 별 소용이 없어요. 실무에서 마주하는 상황에 연결해서 쓸 때 진짜 힘이 생기거든요. 예를 들어 PM이 "일정이 급해서 개발자를 두 명 더 붙일게요"라고 할 때, 그냥 "네..."하고 받아들이지 말고 브룩스의 법칙을 설명하면서 "지금 합류하면 다음 스프린트부터나 기여할 수 있을 것 같고, 당분간은 온보딩 비용이 더 클 거예요"라고 현실적인 대안을 제시할 수 있잖아요.

또 흔히 인용되는 파킨슨의 법칙("일은 주어진 시간을 다 채우도록 늘어난다"), 피터의 법칙("사람은 무능해지는 직급까지 승진한다"), 린디 효과("오래 살아남은 기술일수록 앞으로도 오래 살아남을 가능성이 크다") 같은 것들은 기술 선택이나 커리어 결정에도 도움이 돼요. 새로 나온 멋져 보이는 프레임워크보다 15년 된 PostgreSQL이 더 안전한 선택인 경우가 많은 이유가 바로 린디 효과거든요.

업계 맥락에서 보면

이런 '법칙 모음' 형식의 콘텐츠는 예전부터 있었어요. 마틴 파울러 블로그, 프래그머틱 프로그래머 책, 그리고 "A Philosophy of Software Design" 같은 책들이 비슷한 지혜를 전달해왔죠. 하지만 한 페이지에 모아 놓은 레퍼런스 사이트는 생각보다 드물어요. Awesome Software Architecture 같은 GitHub 리포지토리도 있지만, 거긴 도구 모음에 가깝고요.

이 사이트의 가치는 "검색 가능한 공통 어휘"를 만들어준다는 거예요. 코드 리뷰할 때 "이건 YAGNI 원칙에 어긋나요"라고 링크를 걸 수 있으면 설명이 훨씬 짧아지잖아요.

한국 개발자에게

당장 실무에 어떻게 써먹을지 고민이라면, 팀 위키나 온보딩 문서에 이런 법칙 몇 개를 소개하는 섹션을 만들어 보는 걸 추천해요. 주니어가 입사했을 때 "왜 우리가 이런 방식으로 일하는지" 설명하는 좋은 도구가 되거든요. 또 본인이 시니어로 성장하는 과정이라면, 이런 개념을 익혀두면 회의에서 의사결정을 논리적으로 뒷받침할 때 유용해요. 영어 표현이지만 업계 공용어라서 글로벌 팀과 일할 때도 바로 통해요.

한 줄로 정리하면, 소프트웨어 개발의 '상식'을 이름 붙여서 정리해 둔 참고서예요. 여러분이 현업에서 가장 자주 인용하는 법칙은 뭔가요? 반대로 "이건 법칙이라기보다 미신 같아" 싶은 것도 있으신가요?