[Spring Framework] 개발 효율성과 애플리케이션 아키텍처의 필요성

 

 

우선 개발 효율성을 살펴보자.

이 목표가 왜 필요한지는 직관적으로 이해할 수 있을 것이다.
애플리케이션의 아키텍처를 이해하기 위해 5,000쪽이나 되는 문서를 읽어야 한다거나 애플리케이션의 아키텍처를 동작하게 하려고 의미를 알 수 없는 주문 같은 코드를 삽입해야 한다면 말이 되지 않을 것이다.
애플리케이션 아키텍처는 이해하기 쉽고 간단히 사용할 수 있어야 한다.

테스트도 마찬가지이다. 어떤 오브젝트를 테스트하기 위해 웹 컨테이너를 꼭 준비해야 하거나 라이브러리에 클래스 경로를 이것저것 설정해야 하거나 테스트를 위해 구현을 변경하는 것은 귀찮은 작업이다.

테스트는 간단하게 실행할 수 있는 것이 가장 좋다.

웹 애플리케이션의 생명 주기와 애플리케이션 아키텍처의 필요성에 대해 알아보자.

애플리케이션 아키텍처의 목표에 왜 변경이나 기능 추가의 용이성, 미래의 환경 변화에 대응할 수 있는 유연성이 필요할까? 바로 웹 애플리케이션에대한 사용자의 요구가 쉽게 변하기 때문이다. 요구의 변경은 웹 애플리케이션 개발 중에도, 릴리스 후에도 발생한다. 웹 애플리케이션이 릴리스되거나 개발 중이라는 것과 관계없이 웹 애플리케이션의 생명 주기는 웹 애플리케이션 릴리스, 요구 변화 ,변경 및 기능 추가라는 상태를 웹 애플리케이션이 폐기될 때까지 반복한다. 이처럼 폐기될 때까지 계속 변경되는 상태를 가리켜 웹 애플리케이션의 완성은 웹 애플리케이션이 폐기될 때라고 말하기도 한다.

 

이 상태에서 변경이나 기능 추가에 유연하지 않은 애플리케이션 아키텍처를 채용한 웹 애플리케이션은 사용자의 변경 요구에 애플리케이션 아키텍처가 대응하지 못해 웹 애플리케이션을 유지하기 어려워질 것이다. 개발 중이라면 이해할 수 없는 누더기 웹 애플리케이션을 만들거나 최악의 경우에는 납품할 수 없는 상태의 웹 애플리케이션이 될 수도 았다.

또한, 웹 애플리케이션을 릴리스한 다음이라면 현재의 웹 애플리케이션을 버리고 새로운 웹 애플리케이션을 도입해야 하는 상황이 발생할 것이다.

웹 애플리케이션이 그렇게 오래 사용되지 않는다고 생각할 수도 있지만 일단 도입된 웹 애플리케이션은 예상 이상으로 오랜 기간에 걸쳐 이러한 생명 주기를 반복하면서 계속 사용된다. 이를 실감하게 된 계기는 밀레니엄 버그(2000년 문제)였다. 1980년대 후반에 만든 시스템에서는 메모리 절약을 위해 연도의 두 자리만 이용하는 것이 설계의 정석이었고, 그 무렵 제작진들은 입버릇처럼 '이런 시스템은 5년도 안 쓸 걸'이라고 했으나, 참 안이한 생각이었다. 한번 가동한 시스템이 그렇게 오랜 기간동안 이용될 것이라고는 당시 거의 생각하지 않았던 것이다. 가능하면 이 교훈을 살려서 우리는 연말에 출근하는 일이 없길 바라자.

이야기가 잠깐 옆으로 샜지만
시스템 개발 중이든 릴리스 후이든 사용자의 요구에 유연하게 대응할 수 있는 애플리케이션 아키텍처가 필요하다는 것은 이해했을 것이다.