소프트웨어 아키텍처는 프로젝트 초기에 완성해 안정적으로 유지할 수 있는 설계가 아니다. 요구사항과 기술, 도메인에 대한 이해가 바뀌므로 아키텍처도 계속 조정해야 하며, 실제로는 그 변경에 드는 비용과 얻는 효과를 따져야 한다.
아키텍처는 소프트웨어의 구조와 품질 목표를 다루므로 프로젝트 초기에 고민할 가치가 있다. 아무것도 정해지지 않은 시점에는 기본 구조와 주요 기술 과제를 살펴보는 일이 특히 유용하다. 그러나 초기 설계를 지나치게 상세하게 만드는 ‘Big Design Up Front’는 문제가 될 수 있다. 반대로 초기에 아키텍처를 거의 정하지 않고 모든 결정을 뒤로 미루는 것도 답은 아니다.
결정을 늦추면 더 많은 정보를 바탕으로 판단할 수 있지만, 프로젝트 초기에 모든 것을 예측할 수는 없다. 새로운 요구사항이 생기거나 기존 요구사항에 대한 이해가 달라지고, 새로운 기술이 등장하면 기존 결정을 수정해야 한다. 아키텍처 결정 기록(ADR)은 결정뿐 아니라 그 이유도 남겨, 나중에 판단의 근거가 바뀌었는지 확인하고 결정을 다시 검토하도록 돕는다.
아키텍처가 문제에 맞지 않을 때 선택지는 초기에 더 많이 설계하는 것과 새로운 정보를 얻을 때마다 고치는 것이다. 초기 설계를 계속 늘리는 방식은 한계가 있으므로, 변화에 맞춰 아키텍처를 조정하는 편이 낫다. 처음의 결정이 당시에는 타당했더라도 이후에는 바꿔야 할 수 있다. 이를 인정하지 않으면 새 요구사항을 기존 구조에 억지로 맞추려 할 수 있다.
다만 아키텍처를 고치기로 했다고 해서 시스템 전체가 일관되게 바뀌는 것은 아니다. 예를 들어 단순한 데이터 저장만 필요했던 시스템에 복잡한 검증과 업무 규칙이 추가되면, 데이터를 담는 구조만으로는 부족해진다. 기존 코드를 모두 바꾸는 비용이 크면 새 기능에만 로직을 넣을 수 있고, 그 결과 로직이 있는 데이터와 없는 데이터가 공존한다. 메인프레임에서 시스템을 옮기는 과정이나 이전 설계를 통합하기 전에 새 설계를 도입하는 경우에도 구조가 뒤섞일 수 있다.
일관된 구조는 시스템을 이해하고 변경하기 쉽게 한다. 하지만 일관성을 확보하려면 비용이 든다. 따라서 구조를 정리해 이후 변경 비용을 낮추는 편이 나은지, 변경이 충분하지 않으므로 일관되지 않은 상태를 유지하는 편이 나은지는 경제적으로 판단해야 한다. 기능 개발에만 집중해 아키텍처에 필요한 투자를 고려하지 않으면, 나중에는 기능을 더하기 어려울 정도로 문제가 커질 수도 있다.
이 관점에서 실제 아키텍처의 문제는 초기 설계만으로 설명되지 않는다. 핵심은 시간이 지나며 쌓인 구조를 어떻게 정리하고 발전시킬지다. 새 기술과 요구사항, 도메인 이해의 변화에 맞춰 이상적인 아키텍처도 달라지지만, 실제 구현을 매번 그에 맞추는 일은 비용 때문에 실행하기 어려울 수 있다. 현실의 불일치한 아키텍처는 아키텍처에 충분히 투자하지 않은 결과일 수도 있고, 정리 비용과 기대 효과를 저울질한 선택일 수도 있다.
관련 자료: Martin Fowler의 아키텍처 설명, 아키텍처 조정에 관한 글, Java Magazin에 실린 독일어 원문.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요