15 개발자들이 반복적으로 경험하는 소프트웨어 공학의 불가피한 법칙
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
소프트웨어 아키텍처, 프로젝트 관리
대상자
소프트웨어 개발자, 프로젝트 매니저, 팀 리더 (중급~고급 개발자 대상)
핵심 요약
- 모어의 기대 법칙: 기술 발전에 따라 사용자 기대는 지수적으로 증가하므로, 1.5초 이내의 로딩 시간을 목표로 해야 한다.
- 자위스키의 법칙: 기능 범위 확장은 불가피하며, "한 줄 더 추가"라는 요청은 시스템 복잡도를 두 배로 증가시킨다.
- 갈의 법칙: 간단한 시스템부터 시작하고, 이후에 복잡성을 추가해야 하며, MVP(최소 기능 제품)는 단일 기능으로 출시해야 한다.
- 브로크스의 법칙: 팀 확대는 프로젝트 지연을 유발하므로, 기능 축소보다 작은 팀에 집중하는 것이 효과적이다.
섹션별 세부 요약
1. 모어의 기대 법칙 (Moore’s Law of Expectations)
- 사용자 기대는 기술 발전 속도보다 빠르게 증가하며, 3초 이상의 로딩 시간은 53%의 이탈률을 유발한다.
- 스켈레톤 스크린보다 로딩 스핀너보다 사용자 경험에 유리한 디자인을 선택해야 한다.
- 모바일 사용자를 대상으로 하면, 하이엔드 기기보다 저사양 기기에서의 성능을 우선 고려해야 한다.
2. 자위스키의 법칙 (Zawinski’s Law)
- 기능 범위 확장은 자연스럽게 발생하며, "기능 추가" 요청은 100% 확률로 복잡도 증가를 유발한다.
- "기본 기능"에서 벗어나는 순간 시스템은 구글 웨이브처럼 복잡해지며, 리그레션 테스트를 통해 유지보수가 어려워진다.
- "필수 기능"과 "쿨 아이디어"를 구분하는 것이 팀의 생산성과 유지보수 가능성에 직접적으로 영향을 미친다.
3. 호프스타터의 법칙 (Hofstadter’s Law)
- 프로젝트 예상 시간은 항상 실제 소요 시간의 1/3 이하로 추정되며, 버퍼 시간은 예상보다 2배 이상 추가해야 한다.
- "단순 리팩토링"은 의도치 않은 종속성 문제로 인해 2주 이상 소요될 수 있다.
- 비선형 프로젝트 관리는 예상치 못한 차질이 빈번하게 발생하며, 이를 대비하기 위해 미니 프로젝트 단위로 분할해야 한다.
4. 갈의 법칙 (Gall’s Law)
- 복잡한 시스템은 간단한 시스템에서 유래하며, MVP는 단일 기능으로 출시해야 한다.
- REST API 기반의 단일 서버가 18개 마이크로서비스보다 장기적으로 유지보수가 쉬우며, CI/CD 파이프라인의 복잡성은 시스템 안정성에 악영향을 미친다.
- 초기 단계의 복잡성 추가는 장기적 유지비용을 3배 증가시킬 수 있으므로, "현재 문제"에 초점을 맞추는 설계가 필요하다.
5. 컨웨이의 법칙 (Conway’s Law)
- 팀의 커뮤니케이션 구조는 시스템 아키텍처에 직접적으로 반영되며, 다른 팀의 기술 스택 차이는 API 불일치를 유발한다.
- 프론트엔드와 백엔드 팀의 분리는 Figma 디자인과 실제 구현 간 차이를 증폭시킨다.
- 시스템 설계 시 팀 구조를 고려해야 하며, "사용자 경험" 중심의 팀 구성이 필요하다.
6. 브로크스의 법칙 (Brooks’s Law)
- 프로젝트 지연 시 추가 인력은 오히려 생산성 저하를 유발하며, 6명의 개발자보다 2명이 팀을 유지하는 것이 효과적이다.
- 신규 개발자 온보딩은 기존 팀의 생산성에 10% 이상의 감소를 초래할 수 있다.
- "기능 축소"가 아닌 "작은 팀에 집중"하는 것이 프로젝트 지연 방지에 효과적이다.
결론
- 모든 프로젝트에 버퍼 시간 추가하고, 기능 범위 축소를 통해 복잡도를 줄이는 것이 핵심이다.
- 사용자 경험 중심의 팀 구성과 간단한 시스템 설계를 통해 장기적인 유지보수 가능성을 높여야 한다.
- "현재 문제"에 집중하고, 예상치 못한 차질을 대비하기 위해 작은 단위로 프로젝트 분할하는 것이 실무에서 효과적이다.