Legacy-First Design (LFD): 시간이 지나도 여전히 의미가 통하는 소프트웨어 설계
Source: Dev.to
Introduction
대부분의 소프트웨어 아키텍처 논의는 더 빠르게 변화하는 방법에 초점을 맞춥니다.
반면에, 다른 그리고 불편한 질문에 대해서는 거의 다루지 않습니다:
변화가 느려지거나… 완전히 멈추면 어떻게 될까?
실제로, 많은 장수 소프트웨어 시스템은 성능이나 확장성 문제 때문에 실패하지 않습니다. 시간이 흐르면서 개념적 일관성을 잃기 때문에 실패합니다. 비즈니스 규칙이 인프라에 스며들고, 아키텍처 결정이 되돌릴 수 없게 되며, 결국 시스템은 이해되기보다는 다시 작성됩니다.
이 글에서는 Legacy‑First Design (LFD) 를 소개합니다. 이는 시간을 암묵적인 가정이 아니라 첫 번째 제약조건으로 다루는 개념적 아키텍처 방법론입니다.
What is Legacy‑First Design?
Legacy‑First Design은 프레임워크, 언어, 혹은 아키텍처 패턴이 아닙니다.
아키텍처 결정 수준에서 작동하며, 설계자와 엔지니어에게 시간이 지나도 유지되어야 할 것과 시간에 따라 변할 수 있는 것을 명시적으로 구분하도록 요구합니다.
단기적인 전달 속도나 기술적 편의성에 최적화하는 대신, LFD는 다음을 우선시합니다:
- 시스템 정체성 보존
- 기술적 노후화에 대한 저항성
- 장기적인 개념적 명료성
- 활발한 유지보수가 없어도 살아남을 수 있는 능력
핵심은 아키텍처 질문을 다음과 같이 재구성하는 것입니다:
“소프트웨어를 어떻게 구조화하면 더 빠르게 진화할 수 있을까?”
→
“진화가 멈추어도 여전히 유효해야 하는 것은 무엇인가?”
Survival in an Abandoned State
대부분의 아키텍처 접근법은 지속적인 유지보수를 전제합니다. LFD는 그렇지 않습니다.
유지보수가 장기간 부재하는 상황을 예외적인 실패가 아니라 소프트웨어 수명 주기의 예측 가능한 단계로 간주합니다. 이 관점에서, 방치될 때 개념적으로 붕괴되는 시스템은 설계적으로 실패한 것이며, 한때 정상적으로 동작했더라도 마찬가지입니다.
방치된 상태에서도 살아남도록 설계한다는 것은 다음을 의미합니다:
- 원래 제작자가 없어도 이해할 수 있도록 유지
- 핵심 비즈니스 의미를 보존
- 오랜 기간 비활동 후에도 여전히 의미가 통하는 시스템 구축
Relationship to Existing Approaches
Legacy‑First Design은 Clean Architecture, Domain‑Driven Design, Hexagonal Architecture와 같은 기존 접근법을 대체하려는 것이 아닙니다.
오히려 이들 접근법이 종종 암묵적으로 남겨두는 시간적 거버넌스 레이어를 명시적으로 추가합니다.
LFD는 시스템이 어떻게 구조화되는가 보다 시간에 따라 무엇이 변할 수 있고 무엇이 변하지 않아야 하는가에 더 큰 관심을 둡니다.
Canonical Definition
Legacy‑First Design (LFD)의 완전하고 정식 정의는 짧은 기술 논문에 제시되어 있습니다:
📄 Legacy‑First Design (LFD): A Temporal Approach to Software Sustainability – Zenodo
이 논문은 LFD를 개념적이고 규범적인 방법론으로 명시하고, 기존 아키텍처 접근법과의 관계를 논의하며, 그 한계점을 인정합니다. 의도적으로 간결하게 작성되어 구현 세부사항을 제시하기보다는 논의를 촉발하는 데 목적을 둡니다.
Limitations and Outlook
소프트웨어 시스템은 보통 하나의 나쁜 결정 때문에 실패하지 않습니다.
Legacy‑First Design은 복잡성이나 갈등을 없애겠다고 약속하지 않습니다. 대신 시간이 흐를 때도 일관성을 유지하는 시스템을 설계하라는 보다 높은 요구를 제시합니다.
장수 시스템, 레거시 코드베이스, 혹은 아키텍처 지속 가능성을 고민하고 있다면, 이 관점을 탐구해 볼 가치가 있습니다.