Lehman 법칙으로 읽는 소프트웨어 진화와 유지보수

변화하지 않는 시스템은 환경에서 멀어진다

소프트웨어는 배포 시점의 모습으로 고정되지 않는다. 특히 실제 업무와 사회의 절차를 지원하는 시스템은 환경, 사용자 요구, 시장의 변화에 맞춰 계속 수정된다. Lehman이 제시한 소프트웨어 진화 법칙은 이런 대규모 시스템의 변화 패턴을 설명하는 관찰 원리다.

Meir M. Lehman 교수는 1969년부터 1984년까지 IBM과 임페리얼 칼리지 런던에서 연구를 수행했다. IBM OS/360 같은 대형 시스템을 관찰하며 초기 법칙을 도출했고, 이후 내용을 다듬고 확장해 8가지 법칙으로 정립했다. 이 연구는 소프트웨어 개발과 유지보수의 성격을 이해하는 소프트웨어 공학의 이론적 기반으로 평가된다.

법칙이 겨냥한 시스템의 범위

Lehman은 프로그램을 변화의 성격에 따라 S-타입, P-타입, E-타입으로 구분했다.

S-타입(Specified) 프로그램은 명확한 사양에 따라 만들어진다. 수학 함수 계산이나 정렬 알고리즘처럼 형식적으로 정의할 수 있는 문제 영역이 여기에 속한다.

P-타입(Problem) 프로그램은 실세계 문제를 풀기 위한 프로그램이다. 문제 자체는 정확히 명세할 수 있지만, 해법의 판단에는 주관성이 개입될 수 있다. 체스 게임과 AI 시스템이 예시다.

E-타입(Evolutionary) 프로그램은 현실의 절차나 활동을 뒷받침한다. 환경과 계속 상호작용하므로 지속적인 진화가 필요하다. 운영체제, ERP 시스템, 모바일 앱이 대표적이며, Lehman의 법칙은 주로 이 E-타입 시스템에 적용된다.

진화 과정에서 반복되는 경향

환경 적응은 계속된다

E-타입 프로그램은 변화하는 환경에 맞추기 위해 지속적으로 변해야 한다. 변화를 멈춘 소프트웨어는 시간이 갈수록 쓸모를 잃는다. Windows OS가 터치스크린 환경에 맞춰 UI를 바꾼 사례가 이에 해당한다.

기능 추가는 복잡성 관리 없이는 누적된다

시간이 흐를수록 소프트웨어의 구조는 저하되고 복잡도는 커지는 경향을 보인다. 이는 엔트로피가 증가하는 자연 법칙에 비유되며, 별도의 관리 작업이 없다면 새로운 기능을 넣는 일도 점점 어려워진다. 레거시 코드베이스에서 기능 추가의 난도가 높아지는 현상이 대표적이다.

⤢✕

진화 속도에는 조직의 리듬이 있다

소프트웨어 진화 과정은 자기조절적 특성을 가진다. 크기, 시간, 결함 수 같은 제품 속성은 정규 분포를 따르는 경향이 있으며, 릴리스 주기가 일정한 패턴을 형성하는 모습으로 나타날 수 있다.

개발 조직의 평균 작업률도 시간이 지나도 일정한 경향을 보인다. 자원, 제약조건, 조직문화가 여기에 영향을 주며, 팀 규모가 같을 때 매월 해결되는 이슈 수가 일정한 패턴을 보이는 현장이 한 사례다.

릴리스마다 시스템에 반영되는 평균 변화량 역시 상대적으로 일정하게 유지된다. 개발자는 시스템을 이해하고 익숙해질 시간이 필요하다. 한 번에 너무 큰 변화를 주면 익숙함이 깨지고 품질 저하로 이어질 수 있으며, 주요 릴리스와 마이너 릴리스가 주기적으로 나뉘는 이유도 이 관점에서 볼 수 있다.

만족도를 지키려면 기능은 확장된다

사용자 만족도를 유지하려면 기능적 내용은 계속 늘어나야 한다. 사용자의 기대도 지속적으로 증가하는 경향이 있기 때문이다. 초기 버전 이후 기능이 계속 확장되는 모바일 앱은 이 법칙을 보여 준다.

⤢✕

유지보수가 멈추면 품질은 떨어진다

E-타입 시스템은 적극적인 유지보수가 없으면 품질이 저하된다. 환경 변화에 계속 적응해야 하며, 보안 패치를 적용하지 않아 취약점이 증가하는 시스템이 그 예다.

소프트웨어 진화는 하나의 선형 과정이 아니라 다중 피드백 루프를 가진 시스템으로 이해해야 한다. 사용자, 개발자, 시장 등 여러 이해관계자의 상호작용이 개발 방향을 바꾼다. 사용자 피드백에 따라 제품의 방향이 달라지는 과정이 피드백 시스템 법칙에 해당한다.

제품에서 확인할 수 있는 진화의 모습

웹 브라우저는 초기 모자이크와 넷스케이프에서 현대적 브라우저로 발전했다. HTML5와 CSS3 같은 새로운 웹 표준을 지원하는 변화는 지속적인 변화 법칙과 연결된다. 렌더링 엔진과 자바스크립트 엔진이 복잡해진 모습에서는 복잡성 증가를, 개발자 도구와 확장 프로그램의 확대에서는 지속적 성장을 확인할 수 있다.

Android와 iOS 같은 모바일 운영체제는 환경 변화에 맞춰 계속 적응한다. 버전별 기능 증가는 복잡성 관리와 함께 다뤄지며, 일정한 릴리스 주기에는 자기조절과 조직적 안정성의 특성이 반영된다. 사용자 피드백도 다음 변화의 입력으로 작동한다.

⤢✕

ERP 시스템에서는 비즈니스 환경 변화에 대한 지속적 적응이 요구된다. 모듈이 늘어나면 복잡성 관리가 필요해지고, 대규모 업그레이드와 소규모 패치는 변화량을 조절하는 리듬을 만든다. 사용자 요구가 축적되면서 기능 확장도 계속된다.

애자일과 아키텍처에 주는 관점

지속적인 변화의 법칙은 애자일의 핵심 가치와 맞닿아 있다. 피드백 시스템 법칙은 DevOps의 지속적 통합과 배포가 다루는 흐름과 연결되며, 복잡성 증가 법칙은 리팩토링이 왜 계속 필요한지를 설명한다.

아키텍처를 선택할 때도 변화 가능성을 전제해야 한다. 마이크로서비스 같은 변화를 고려한 설계, 기술적 부채 관리, 확장성과 유지보수성을 함께 보는 판단이 필요하다.

오픈소스 소프트웨어에서는 커뮤니티가 피드백 시스템의 역할을 한다. 분산된 개발 조직은 조직적 안정성의 문제를 안고 있으며, 모듈성은 복잡성 관리의 한 방법이 된다.

법칙으로 단정할 수 없는 범위

Lehman의 법칙은 엄밀한 자연 법칙이라기보다 관찰된 경향성에 가깝다. 모든 유형의 소프트웨어에 적용되는 것도 아니며, E-타입 시스템을 중심으로 한다.

애자일과 지속적 배포 같은 현대 개발 방법론에서는 일부 경향이 덜 뚜렷하게 나타날 수 있다. 소규모 소프트웨어나 모바일 앱에도 적용 범위가 제한될 수 있으므로, 개별 시스템의 맥락을 벗어난 일반화에는 주의가 필요하다.

장기 운영을 위한 변화 관리

Lehman의 관점은 소프트웨어가 지속적인 변화와 적응을 필요로 한다는 사실을 전제한다. 복잡성 증가와 품질 저하는 진화 과정에서 나타날 수 있지만, 이를 인식하면 리팩토링, 피드백 수집, 유지보수 계획을 개발 프로세스 안에 둘 수 있다.

장기적인 유지보수성과 가치 창출은 변화 자체를 피하는 데 있지 않다. 변화가 불가피하다는 조건 아래에서 그 속도와 복잡성, 품질 영향을 관리하는 데 있다.