개발 프레임워크 만들기 대장정 01 - 개발 프레임워크란

SI 프로젝트에 참여하는 개발자들은 대부분 개발 프레임웤에 대한 경험이 있을 것이다. 큰 규모의 프로젝트에서는 나름대로의 개발 프레임워크를 만들어 진행한다. 업무 개발자들이 업무 프로세스를 구현하는데 집중할 수 있도록 잡다한 내용은 모두 블랙 박스로 만들어 놓는 것이다. 개발자들은 블랙박스에서 노출시켜놓은 공개적인 API만을 잘 사용하면 된다는 그런 생각이다.

 

그러나 프로젝트마다 프레임워크를 설계한 사상이 다르고 구현 또한 달라지기 때문에 업무 개발자들은 프로젝트마다 새로운 프레임워크의 설계와 새로운 API에 익숙해져야만 한다. 업무 개발자들은 피곤한 일이다. 그러다 보니 업무 개발자들은 프레임워크의 내부를 늘 궁금해하는 듯 하다. 어떻게 만들어졌을까. 이런 것을 어떻게 구현했을까. 그러나 프로젝트가 한참 진행중인 사이트에서 개발자가 프레임워크(이하 특별한 언급이 없는한 "프레임워크"이라 하면 개발 프레임워크를 말하기로 한다. .NET 프레임워크를 떠올리지는 않도록 하자) 내부를 살펴보기는 시간상 쉽지 않은 일이다. 그래서 프레임워크를 만들수 있으려면 무엇을 공부해야 하나요. 어떤 기술을 알아야 하나요 하는 질문을 자주 듣는 것도 당연한 듯 싶다.

개발 프레임워크 장사를 하는 업체도 있다.  프레임워크에 나름대로의 브랜드명을 붙여서 프로젝트에 납품을 한다. 그러나 이미 그 훌륭함이 증명된 오픈 프레임워크도 많이 있다. 유명한 오픈 소스 프레임워크로는 Spring.NET이라는 것이 있다. 내가 알기로는 모 SDS 업체에서도 이 프레임워크를 자주 사용한다고 한다. 얼마나 자주 사용하는지는 모르겠지만. 마이크로소프트에서도 Application Block이라는 이름으로 여러 블록을 내놓고 있다. 여기에 얼마전에 Unity Application Block이라는 프레임워크를 추가로 내놓았다.  이전 버전의 Application Block을 사용해본 적은 있지만 Unity 라는 이름을 달고 나온 이 녀석은 사실 필자도 잘 모른다.

 

이번 포스트부터는 개발 프레임워크 만들기 대장정이라는 큰 제목하에서 기나긴 대장정에 오르려고 한다. 이 대장정의 목표는 이미 나와 있다. 바로 Unity Application Block을 이해하는 것이다. 이것을 이해하기 위해서는 많은 얘기들을 해야 할 것이다. 너무 많은 얘기를. 하다 보면 나도 모르는 것이 많을 것이다. 기본적으로 인터페이스, 상속, 오버라이딩같은 객체 지향 이야기도 해야 할 것이고  패턴 얘기 그리고 새로운 버전의 C#과 .NET 프레임워크에 대한 이야기도 해야 할 것이고. 모두다 큰 주제들이다.

 

언제 끝날지 모르는 장정이다. 어디를 경유해서 가야하는 지도 모른다. 다만 목적지만을 알고 있다는 것 뿐이다. 최단 거리로 가야할지, 일반 도로로 가야 할지 고속도로로 가야할지 아무것도 결정된 것은 없다. 고속도로로 가다가 잘못해서 산길로 접어들어 숲을 보지 못하고 헤멜지도 모른다. 가고 싶은 만큼 가다 쉬고 싶을때 쉬고 그러다 쉬고 나면 또 갈 것이다. 블로깅이 의무감으로 짓눌리는 일은 없어야 한다고 늘 혼자 다짐한다. 즐겁게 하고 싶다. 

 

그럼 개발 프레임워크가 뭔지부터 생각해보자. 이것을 정의하기 위해서 다른 참조 문서를 보지는 않았다. 다만 지금까지의 경험을 바탕으로 해서 정리해보려 한다. 어떤 사람들은 메세지 관리 또는 메뉴 관리같은 공통 모듈을 개발 프레임웤과 같은 의미로 사용하기도 한다. 그렇지만 개발 프레임웤은 공통 모듈을 포함하기는 해도 그것이 전부는 아니다. 개발 프레임워크가 하는 역할에는 몇 가지가 있는 듯 하다.

• 개발 생산성 보장
• 개발 코드의 통일성 보장
• 품질( stability, performance, security 등)의 평균 보장

음...뭐 또 없나...맞다. 중요한 게 빠졌다.

• 재사용성

이중에서 필자가 가장 중요하게 생각하는 것은 "개발 생산성"이다. 개발자가 쉽게 익숙해지고 사용하기 쉬워야 한다는 것이 내게 가장 중요하다. 필자가 경험한 프레임워크 중에서 그 내부까지 완전하게 살펴본 것은 한 5 제품정도이다. 이 중에서 어떤 제품은 개발자에게 할테면 하고 말라면 말라는 식의 제품도 있었다. 물론 개발을 하기 위해서는 개발자는 힘들어도 그 프레임워크가 제시하는 방식대로 개발을 해야 했다. 자칫 정신을 놓으면 실수할 수도 있다. 그것때문에 몇 시간을 보내버릴 수 있다. 물론 많은 개발자들은 그 개발 프레임워크가 사용하기 힘든지 어려운지도 몰랐다. 당연하게 생각했다. 에러가 발생하면 자기가 잘못한줄 알고 미안해했다. 프레임워크 담당자는 실수한 개발자에게 짜증을 부렸다. 이전에 알려주지 않았느냐는 것이다. 그러나 내가 보기에는 프레임워크를 잘못 설계해서 개발 절차가 복잡해진것이다. 개발자가 실수할 수 있는 부분이라면 최대한 프레임웤에서 대신해줘야 한다. 그렇게 못해줄 실력이라면 개발자에게 미안해해야 한다. 그러나 현실은 개발자가 프레임워크 담당자의 실수와 그들의 부족한 실력을 모두 떠 안고 가야 한다. 불쌍한 개발자들만 이리 치이고 저리 치인다. 쓰으..."넌 프레임워크 개발자 아니냐?"하는 소리도 들리는 듯 하지만, 필자는 asp로 하는 업무 개발부터 시작했고 지금도 프레임워크 개발보다는 업무 개발로 프로젝트에 참여하는 경우가 많다. 현재 참여하고 있는 이 프로젝트도 일반 개발자로 참여하고 있다.

 

업무 개발자로 참여하면서도 필자는 운이 좋게도 개발 프레임워크를 다루는 프로젝트에도 많이 참여할 수 있었다. 그래서 이제는 좀 덜 떨어진듯한 개발 프레임워크를 만나더라도 이해할 수 있는 연륜은 된듯하다. 인생 뭐 있어 하고 만다.

 

또 하나 중요하게 생각하는 것중의 하나가 바로 재 사용성이다. 앞에서 말한것처럼 공통 모듈을 프레임워크라고 생각한 사람들은 바로 프레임워크의 재사용성만을 생각했기때문일 것이다. 여기서 말하는 재사용성이라는 것은 특정 프로젝트에서만의 재사용성을 말하는 것은 아니다. 다른 프로젝트에서도 소스 수정없이 그대로 적용할 수 있어야 한다. 이 재사용성은 프레임워크 장사를 하는 업체에게는 수익과 직결되는 중요한 항목이다. 업체에서 보유한 프레임워크는 최소한의 수정으로 여러 프로젝트에서 그대로 적용할 수 있어야 하고 하기 때문이다. 설계가 잘못되어서 프로젝트마다 현장에 맞게 손을 봐야 하는 부분이 많아지면 많아질 수록 인력과 시간에서 손해나는 장사이다.

 

프레임워크를 사용하게 되면 코드의 통일성에도 어느 정도 기여할 것이고 애플리케이션의 안정성, 퍼포먼스, 보안등에서 최선의 보장은 안되겠지만 단시간내에 평균적인 보장은 이룰 수 있다는 것도 개발 프레임워크의 장점일 것이다. 개발 프레워크의 위치를 보면 다음 그림처럼 간단히 표현할 수 있을 것이다.

 

 

 

개발자가 .NET 프레임워크나 OS에 대한 내부 사정을 모르더라도, 특정 프로젝트 사정에 맞도록 만들어서 최대한의 생산성을 내도록 하는 것이 바로 개발 프레임워크라고 필자는 생각한다.

 

특정 프로젝트 상황에 맞도록 만들어져야 한다고 해서 그 프로젝트에만을 고려해서 만든다는 것은 아니다. 앞에서 말한대로 재사용성을 고려해서 다른 프로젝트에서도 코드 수정없이 만들도록 해야 한다. 이 재사용성에 대해서 다음 포스트에서 좀 깊게 생각해보자.