시니어 개발자가 실제로 쓰는 소프트웨어 공학 56가지 법칙 정리 (lawsofsoftwareengineering.com)

한줄 요약

팀, 아키텍처, 품질, 의사결정 4개 축으로 나눈 소프트웨어 공학 핵심 법칙 56가지 실전 해설.

어떤 상황에서 필요한가?

소프트웨어 공학에는 수십 년간 반복 검증된 원칙들이 존재한다. 문제는 대부분의 개발자가 이 법칙들을 이름은 알지만 언제, 어떤 맥락에서 적용해야 하는지 잘 모른다는 점이다. 주니어 때는 "DRY를 지켜라"는 말을 들어도 코드 중복을 없애는 수준으로만 이해한다. 시니어가 되면 그 법칙이 설계 결정, 팀 구조, 일정 산정까지 관통하는 원리임을 체감한다.

Dr. Milan Milanović가 정리한 Laws of Software Engineering은 이런 원칙 56가지를 Architecture, Teams, Planning, Quality, Scale, Design, Decisions 7개 카테고리로 분류한다. 이 글에서는 그 중 실무 임팩트가 큰 법칙들을 중심으로 내가 직접 겪은 맥락과 함께 풀어본다.

핵심 구현 방법

팀 구조에 관한 법칙: 조직도가 곧 아키텍처다

Conway's Law는 "조직의 커뮤니케이션 구조가 시스템 설계에 그대로 반영된다"는 원칙이다. 이걸 무시하면 마이크로서비스를 도입해도 팀 경계와 서비스 경계가 어긋나서 결국 모든 배포가 다른 팀을 기다려야 하는 상황이 생긴다. 아키텍처를 바꾸고 싶다면 팀 구조부터 바꿔야 한다.

Brooks's Law는 "지연된 프로젝트에 인력을 추가하면 더 늦어진다"고 말한다. 신규 투입자에게 컨텍스트를 전달하는 비용, 기존 팀원의 집중력 분산이 단기적으로 생산성을 오히려 떨어뜨린다. 마감이 촉박할수록 팀 확대보다 범위 축소를 먼저 검토해야 한다.

Price's Law도 직시해야 한다. 전체 기여자 수의 제곱근에 해당하는 인원이 전체 성과의 50%를 만들어낸다. 팀이 커질수록 핵심 기여자가 상대적으로 희석된다. 100명 조직이면 약 10명이 절반의 결과물을 만드는 셈이다.

아키텍처에 관한 법칙: 복잡성은 없애는 게 아니라 이동시키는 것

Gall's Law는 "동작하는 복잡한 시스템은 반드시 동작하는 단순한 시스템에서 진화한 것"이라고 말한다. 처음부터 완벽한 MSA를 설계하려다 실패하는 팀을 너무 많이 봤다. 먼저 동작하게 만들고, 그 다음에 분리하라.

Hyrum's Law는 실전에서 가장 체감이 큰 법칙 중 하나다. API 사용자가 충분히 많아지면 문서에 없는 모든 동작 방식이 누군가에게 의존된다. 응답 속도, 에러 메시지 포맷, 심지어 버그까지. 이게 레거시 시스템 교체가 그렇게 어려운 이유다.

Tesler's Law는 "애플리케이션에는 절대 줄일 수 없는 복잡성이 존재하며, 그것은 제거되는 게 아니라 이동될 뿐"이라고 한다. 사용자에게 감추면 개발자가 짊어지고, 개발자가 감추면 인프라가 짊어진다. 복잡성의 총량은 보존된다.

품질에 관한 법칙: 나쁜 코드는 복리로 이자가 붙는다

Technical Debt는 단순히 "지저분한 코드"가 아니다. 개발 속도를 늦추는 모든 것이 기술 부채다. 부채 자체보다 이자가 문제다. 처음엔 티가 안 나지만 누적되면 새 기능 하나 추가하는 데 예상의 몇 배 시간이 걸린다.

Kernighan's Law는 "코드를 작성하는 것보다 디버깅이 두 배 어렵다"고 말한다. 여기서 따라오는 함의가 중요하다. 자신이 작성할 수 있는 가장 영리한 코드를 짜면, 그 코드를 디버깅할 능력이 부족해진다는 뜻이다. 영리함보다 명료함을 선택해야 하는 이유다.

Broken Windows Theory는 방치된 나쁜 코드 하나가 팀 전체의 코드 품질 기준을 끌어내린다는 원칙이다. "어차피 이 파일은 레거시니까"라는 말이 팀에서 나오기 시작하면 이미 신호가 켜진 것이다.

의사결정에 관한 법칙: 틀린 판단의 패턴을 먼저 알아야 한다

Sunk Cost Fallacy는 이미 투자한 시간과 돈 때문에 잘못된 방향을 계속 유지하는 심리다. "여기까지 왔는데 포기할 수 없다"는 말이 나올 때마다 이 법칙을 떠올려야 한다. 과거 비용은 미래 결정에 영향을 줘서는 안 된다.

Goodhart's Law는 특히 엔지니어링 관리자에게 중요하다. "측정값이 목표가 되는 순간, 그것은 좋은 측정값이 아니게 된다." 코드 커버리지 80% 목표를 설정하면 의미 없는 테스트가 늘어난다. PR 수를 KPI로 잡으면 잘게 쪼갠 불필요한 PR이 늘어난다.

Hype Cycle & Amara's Law는 신기술의 단기 영향은 과대평가되고 장기 영향은 과소평가된다고 말한다. 지금 유행하는 기술을 즉시 도입하는 것도, 완전히 무시하는 것도 둘 다 리스크다.

실전에서 주의할 점

이 법칙들은 절대 규칙이 아니라 사고의 도구다. YAGNI("지금 당장 필요하지 않은 것은 만들지 마라")와 Gall's Law가 단순함을 강조한다고 해서 설계를 아예 하지 말라는 뜻이 아니다. 문맥 없이 법칙만 꺼내드는 것은 오히려 판단을 흐린다.

Dunning-Kruger Effect를 가장 경계해야 할 대상은 사실 이 법칙들을 방금 알게 된 사람이다. 법칙을 처음 배운 직후 모든 상황에 적용하려는 충동이 생긴다. 경험이 쌓이면 어떤 상황에 어떤 법칙이 적합한지 구분하는 감각이 생긴다. 그 감각이 시니어와 주니어의 차이다.

Pareto Principle도 현실 점검용으로 자주 사용한다. 버그의 80%는 코드베이스의 20%에서 나온다. 성능 문제의 80%는 특정 경로 20%에서 나온다. 모든 것을 동시에 개선하려 하지 말고, 레버리지가 높은 20%를 먼저 찾아라.