패키지와 프레임워크

예전 회사에서는 프레임워크 개발을 했다. 스프링과 같은 자바 프레임워크였고, 이를 기반으로 많은 SI 프로젝트들이 진행되었다.

지금 회사에서는 패키지 솔루션 개발을 한다. 말로만 패키지지 실제로는 SI인 솔루션들도 많지만 설치 이후에 거의 수정을 하지 않는 진정한(?) 솔루션을 개발한다.


프레임워크 개발은 익명의 다수의 개발자를 대상으로 하기 때문에 제약이 많다. 학습과 경험에 의해서 이것 저것 고쳐야 할 것들이 보여도 수정하기가 어렵다. 이 문제를 해결하려고 잡다한 시도들을 했다.

컴포넌트 기반 개발을 축으로 무조건적으로 인터페이스와 구현을 분리하고, IoC 패턴으로 컴포넌트 간의 상관 관계를 쉽게 수정할 수 있도록 했다. 결과적으로 늘어나는건 적용된 디자인 패턴 숫자와 XML 파일... 그리고 이에 비례한 복잡도...

프레임워크 개발을 할 때는 중요하지 않은 문제를 중요하다고 간주하며 살던 시기였다.


솔루션을 개발하면서는 가능한 쉽게 가는 쪽을 선택했다. 골격은 MVC 패턴을 준수했지만 설정 부분을 다 하드코딩으로 처리햇다. XML 파일을 수정하나 코드를 수정하나 차이도 없고, 컴파일러가 오류를 잡아 주기 때문에  오타 가능성이 현격하게 낮아진다는 장점도 있다.

HiveMind와 같은 IoC 컨테이너도 쓰레기 통으로 던졌다. 필요한 객체를 직접 생성해서 쓰면 되지 굳이 set 메소드를 만들고, 이를 XML 파일에 설정해야 할 이유를 찾을 수 없었다.


물론 솔루션 개발에서 이런 태도로 전환할 수 있었던 것은 내가 작성한 코드를 다른 것에 영향을 주거나 받지 않고 쉽게 수정할 수 있기 때문이다. 현재의 나와 지금 함께 개발하고 있는 개발자들, 그리고 미래의 나와 미래에 나와 함께할 개발자들 혹은 내가 떠난 후 내 일을 인수 인계받을 개발자들만을 염두하면 된다.

결론적으로 어떤 코드든 쉽게 수정할 수 있다는 것이 솔루션 개발의 장점이다.

물론 패키지 솔루션에서도 데이터베이스와 파일 구조를 변경하거나 외부 개발자들에게 공개한 오픈 API를 변경하는 것은 곤란한 일이다.

 
요약하면 유연성에 대한 태도도 바뀌었다. 전에는 고도의 기법을 통한 확장 가능성을 유연성으로 이해했다면 지금은 쉽게 이해할 수 있도록 간결하게 작성하는 것을 유연성을 확보하는 통로로 받아들이고 있다. 쉽게 이해할 수 있도록 간결하다면 수정하는 건 어렵지 않다.