리먼의 소프트웨어 변화 원리와 유지보수 전략

변경은 배포 이후부터 시작된다

소프트웨어는 개발을 마쳤다고 해서 고정된 결과물이 되지 않는다. 사용자의 요구, 새 기술, 법적 규제처럼 운영 환경을 둘러싼 조건이 바뀌는 동안 시스템도 계속 수정된다. 이 변화에 대응하지 못하면 소프트웨어는 실용성을 잃고 도태될 수 있다.

메이어 리먼(Meir M. Lehman)은 장기간의 관찰과 데이터를 토대로 소프트웨어 진화에서 반복되는 8가지 법칙을 제시했다. 이 원리는 시스템이 시간이 지날수록 왜 복잡해지고 품질이 흔들리는지, 이를 다루기 위해 조직과 유지보수 체계가 무엇을 해야 하는지를 설명한다.

진화 과정에서 반복되는 리먼의 원리

계속적 변경

실제 환경에서 사용되는 소프트웨어는 끊임없이 변경되어야 한다. 시간에 따른 사용자 요구의 변화, 새로운 기술의 등장, 법적 규제 변화가 모두 변경 요구를 만든다.

복잡도 증가

변경이 이어지고 기능이 추가되면 내부 구조의 복잡도는 증가한다. 초기 설계에 없던 요소가 덧붙으면서 모듈 간 결합도는 높아지고 응집도는 낮아지는 경향을 보인다. 이 흐름을 억제하려면 주기적인 리팩토링이나 재설계 같은 복잡도 관리가 함께 이뤄져야 한다.

프로그램 진화의 규칙성

시스템의 변경은 무작위로만 일어나지 않으며 고유한 패턴과 추세를 보인다. 시스템 크기, 오류 발생 빈도, 변경 횟수를 시간에 따라 추적하면 일정한 통계적 규칙성을 발견할 수 있다. 소프트웨어 진화가 관리자의 의지만이 아니라 시스템 자체의 특성에도 영향을 받는다는 뜻이다.

조직적 안정

개발 조직의 생산성은 장기적으로 일정하거나 안정적인 수준을 유지하는 경향이 있다. 개발 인력을 대폭 투입해도 의사소통 비용과 학습 곡선 때문에 즉각적인 생산성 향상을 기대하기 어렵다. 이는 브룩스의 법칙(Brooks' Law)과도 맥을 같이한다.

친근성 유지

버전이 바뀌더라도 한 번의 변화량은 일정한 수준에서 예측 가능해야 한다. 한 버전에 너무 많은 기능을 급격히 바꾸면 시스템 안정성이 흔들리고, 사용자와 관리자의 이해도도 낮아져 운영 리스크가 커진다.

기능의 지속적 성장

사용자 만족과 시장 경쟁력을 유지하려면 소프트웨어 기능은 계속 성장해야 한다. 시스템은 사용자가 마주한 문제를 해결하는 과정에서 더 많은 기능을 포함하는 방향으로 진화하고, 이는 규모 확대로 이어진다.

관리되지 않은 변화가 만드는 품질 저하

지속적인 변경과 기능 추가는 철저한 관리가 없을 때 품질 저하를 초래한다. 시스템이 환경 변화에 완전히 적응하지 못하거나 변경의 부작용(Side Effect)이 누적되면 신뢰성과 성능이 떨어질 수 있다.

피드백 시스템

개발과 유지보수는 다중 루프 피드백 시스템으로 볼 수 있다. 개발자, 사용자, 관리자 사이에서 정보와 피드백이 원활히 오가야 의미 있는 개선과 품질 확보가 가능하다.

요구사항, 변경, 품질 관리가 연결되는 흐름

⤢✕

외부 환경과 사용자 요구사항은 변경을 일으키고, 그 변경은 기능 성장을 가져온다. 동시에 구조적 복잡도와 품질 저하도 함께 발생한다. 리팩토링으로 구조를 개선하고, 품질 저하에서 얻은 피드백을 다음 변경에 반영하는 순환이 유지보수의 핵심이다.

유지보수 체계에 반영할 관점

복잡도 증가와 품질 저하는 소프트웨어 진화에서 자연스럽게 나타날 수 있다. 따라서 문제가 발생한 뒤에만 대응하기보다 예방적 유지보수(Preventive Maintenance)로 코드를 정리하고 구조를 개선할 필요가 있다.

형상 관리(Configuration Management)도 이 과정의 기반이다. 프로그램 진화의 패턴을 파악하고 버전 간 친근성을 지키려면 변경 이력을 정밀하게 추적할 도구와 프로세스가 필요하다.

기능 확대와 품질 유지는 트레이드오프(Trade-off)에 놓인다. 기능이 늘어날수록 테스트 자동화와 정적 분석을 강화해 품질 하락을 방어해야 한다. 데브옵스(DevOps) 환경에서의 모니터링과 사용자 피드백 반영 역시 피드백 시스템을 구현하는 방식으로 볼 수 있다.

변화 대상에 따라 달라지는 소프트웨어 성격

리먼은 변화 원리를 도출하는 과정에서 소프트웨어를 성격에 따라 S-Type, P-Type, E-Type으로 구분했다.

S-Type (Static-type): 명확하게 정의된 수학적 사양에 따라 작성된 프로그램이다. 환경 영향을 거의 받지 않으며, 사양이 바뀌지 않는 한 변경할 필요가 없다.
P-Type (Practical-type): 실질적 문제를 해결하는 프로그램이다. 문제 정의는 명확하지만 해결 방법은 환경에 의존하므로 환경이 변하면 프로그램도 변해야 한다.
E-Type (Embedded-type): 인간 활동이나 사회적 시스템 안에 내장된 프로그램이다. 실행 결과가 환경을 변화시키고, 그 변화가 다시 요구사항으로 돌아오는 강한 피드백 루프를 가진다. 리먼의 8가지 법칙은 주로 E-Type 소프트웨어에 적용된다.

시스템을 성장시키는 일과 안정성을 유지하는 일은 분리할 수 없다. 리먼의 변화 원리는 변경을 예외가 아닌 정상 상태로 보고, 그 과정에서 복잡도·품질·조직·피드백을 함께 관리해야 한다는 기준을 제시한다.

Sources

Lehman, M. M., "Programs, Life Cycles, and Laws of Software Evolution", Proceedings of the IEEE, Vol. 68, No. 9, 1980.
Lehman, M. M., and Belady, L. A., "Program Evolution: Processes of Software Change", Academic Press, 1985.
정보관리기술사 학습 가이드, 소프트웨어 공학 유지보수 단원.