개발 프레임워크 만들기 대장정 02- 재사용성 vs. 확장성

개발 프레임워크를 가진 업체가 프로젝트에서 실제로 투입되었을때 고객과의 사이에서 있을 수 있는 갈등중의 하나가 바로 개발 프레임워크의 코드 수정에 대한 것이다.  고객은 프레임워크 코드를 수정해서 자신들이 원하는 기능을 구현해 주길 바란다. 프레임워크 제공 업체에서는 최대한으로 그런 수정을 막아보려 한다. 이 부분은 프레임워크이기 때문에 수정할 수 없다는 것이다. 그러나 프레임워크의 네임스페이스까지도 철저히 수정해주길 원하는 고객을 만나면 끝에 가서는 프레임워크 제공 업체는 어쩔 수 없는 일이다. 물론 이 부분은 두 업체간의 영업적 계약이 어떻게 되었는가에 따라서 이야기가 다분이 달라질 수 있는 측면이 있다. 프로젝트의 재사용성이라는 것을 그런 영업적인 쇼부(쇼부라... 이쯤 되면 이 포스트가 개인적인 것이라는 것을 이해했을 것이라 본다. 기술적으로나 이곳에서 표현된 내용이 검증된 것은 아니라는 말이다. 휙~) 이를 통해서 프로젝트 코드를 수정하지 않고 재사용해야 한다는 것을 말하려는 것은 물론 아니다.우선 예를 하나 들어보자. 어떤 프로젝트에서 로그를 데이터베이스로 남겨야 한다고 했다. 그리고 그 로그를 저장하는 코드는 프레임워크에서 제공하기로 했다. 그래서 그런식으로 구현해서 프로젝트가 종료되었다. 그리고 나서 동일한 프레임워크를 가지고서 다른 프로젝트로 갔다. 그런데 그 프로젝트에서는 로그를 파일 시스템에 남겨야 한다고 한다.

 

 

로깅하는 코드가 개발 프레임워크 내부에 코드되어 있는 상황에서라면 이렇게 고객의 요구사항이 바뀔때마다 로깅 부분의 코드를 수정해야 한다. 물론 로깅하는 부분의 코드를 별도로 메모장에 저장해뒀다면 필요한 코드를 복사&붙여넣기 하는 방식으로 간단히 수정할 수 있다. 그래서 다시 빌드해서 개발자에게 프레임워크 어셈블리를 개발자에게 배포하면 된다. 또는 이렇게 해도 된다. DB로깅 코드와 파일 시스템 로깅 코드를 모두 프레임워크내에 구현해 놓고 어디에 로깅할지를 환경 변수로 설정하는 것이다.

 

 

 

이렇게 config 파일에 DB에 로깅할지 파일 시스템에 로깅할지를 설정한다음 프레임워크에서는 설정 값을 읽어서 원하는 코드를 실행하도록 할 수 있다. 그럼 프레임워크 코드를 수정하지 않고 갈 수 있을 것이다. 그러나 DB, 파일 시스템이외에 예상치 못했던 저장소가 출현하면? 예를 들어서 이벤트 로그로 남겨달라면 ? 이 포스트에서 말하고 싶은 것은 재사용성과 밀접한 관계가 있는 확장성에 대한 것이다. 변경 가능성이 있는 부분을 확인하고 추후 현장에서의 요구에 따라서 실제 구현은 그곳에서 이뤄져야 한다는 것이다. 즉 프레임워크라 하면 이런 변경 가능한 부분을 자신의 수정없이 받아들일 수 있어야 한다는 것이다.

 

프레임워크의 코드가 재사용되기 위해서는 확장이 될 수 있는 아키텍쳐가 필요한 것이다. 사이트에서 필요한대로 로깅 로직을 구현해서 개발 프레임워크에 끼워 넣고 사용하면 되는 것이다. 다만 개발 프레임워크가 이해하고 있는 API를 구현해주기만 하면 된다. 예를 들어 로깅 객체의 Write() 메소드만 노출시켜 주면 된다. 이 부분에서 조금 이해가 어려울 수도 있을 것이다. 뒤에 interface라는 것을 생각해보려 한다. 그때 한번 더 생각해보도록 하자. 지금은 개발 프레임워크라는 것은 그림처럼 레고 블럭처럼 상황에 따라 필요한 블럭을 끼워서 사용할 수 있도록 하는 구조를 가지고 있어야 한다고만 생각하자.

Unity Application Block라는 것은 이런 구조를 제공할 수 있는 프레임워크이다.

 

 

Unity Application Block 부분이 개발 프레임워크이라면 사이트별로 필요한 대로 익스텐션을 구현해서 사용할 수 있도록 지원해주고 있다. 데이터베이스 로깅 코드나 파일 시스템 로깅 코드 부분이 사이트별 익스텐션 구현 부분이 되는 것이다.

Unity Applicaton Block을 사용하기 위해서는 그보다 먼저 프로젝트마다 어느 부분이 변경가능성이 있는지를 밝혀내는 것이 더 중요하다. 이것은 프레임워크에 대한 현장 개발 경험이 중요한 부분이다. 그러나 일반적으로 인증, 권한부여, 캐싱, 일반 로깅 및 예외 로깅 또 없나...음...보안 관련등이 변경 가능성이 있을 수 있는 부분들이다.  이런 문제에 대해서 알면 좋겠지만 몰라도 지금의 대장정에서 문제가 될 것은 아니다. 우선은 Unity Application Block을 이해하고 사용할 수 있는 것이 대장정의 목표이다. 사실 이런 확장성을 얼마나 쉽게 잘 지원해줄 수 있는가가 잘 만들어진 프레임워크에 대한 기준중의 하나라고 볼 수 있을 것이다. 이제 다음 포스트에서는 Unity Applicaion Block에서 확장성을 어떻게 구현하고 있는지, 어떤 기술을 사용하고 있는지를 알아볼 것이다.