사내 프레임워크 만들지 말자 - 4*

펌글인데 내용이 괜찮고 또 사라지기전에 보관차원에서 작성해본다.

사내 프레임워크 만들지 말자 - 4

업 무에 특화된 것들이 있다면 이런 오픈소스들 위에 라이브러리처럼 레이어를 올려서 사용할 수 있다. 이 레이어를 프레임워크 의존성이 없게 만든다면 업무에 특화된 공통화에 대한 니즈도 충족시키면서 서비스를 개발하는 쪽의 기술을 제약할 필요도 없고 시대에 뒤떨어졌다는 비판의 부담도 가질 필요 없다.

충분히 이렇게 만들 수 있는 시대이다.

물론 오픈소스가 가지는 제약사항도 있다. 우리가 원하는 기능이 없을 수도 있고(이건 바로 앞에서 얘기한 방법으로 해결할 수 있을 것이다.) 우리에게 중요한 어떤 이슈가 오픈소스 프로젝트에서는 다른 이슈에 우선순위가 밀려서 개선되지 않을 수도 있다. 하지만 이러한 문제는 앞에서 프레임워크 개발팀을 구성했듯이 오픈소스 대응팀같은 걸 만들어서 필요한 부분을 직접 개선해서 오픈소스에 공헌할 수 있다. 이렇게 할 수 있다면 자체적으로 개발해서 운영하는 것보다 훨씬 적은 비용으로 더 좋은 프레임워크를 얻을 수 있다. 오픈소스 생태계도 좋아지고 비용도 줄어드는 말그대로 윈윈이다.

더군다나 자체 프레임워크를 만들면 필연적으로 필요한 문서화나 인력충원에 대한 부담도 오픈소스 프레임워크를 사용하면 엄청나게 줄일 수 있다. 만약 스프링이나 jQuery를 쓴다면 사내에서 문서를 만들필요 없이 이미 시장에 많은 문서들이 나오고 수많은 이슈와 해결책에 대한 글이 구글에서 검색만 하면 찾아낼 수 있게 된다. 사내에만 특화된 부분만 따로 문서화하면 그뿐이다. 인력충원도 새로 뽑아서 새로운 프레임워크의 사용방법 가르쳐주고 하는 과정을 반복할 필요없이 해당 프레임워크의 경험자를 그냥 뽑으면 되고 어쩌면 훨씬 더 잘 아는 사람을 뽑을 수 있을지도 모른다.

수레바퀴는 재발명해도 된다
"이미 있는데 뭐하러 또 만들어!"라고 얘기하고 싶은건 아니다. "수레바퀴를 재발명하지 말라."는 프로그래밍의 오래된 격언이지만 사실 이는 어디까지 추상화하고 그 위에서 개발할 것인가의 문제일 뿐 수레바퀴를 게속 개선할 필요는 있다.(수 레바퀴 비유는 여전히 유용하지만 좀 과용되는가 감도 있다.)그리고 수레바퀴를 더 좋은 수레바퀴로 만들려면 지금의 수레바퀴를 어떻게 만들었는지 알아야 하므로 수레바퀴를 재발명하는 시도자체를 말리고 싶진 않다.(오히려 권장하고 싶다.) 그러면서 점점 좋은 수레바퀴가 만들어지는 것이다.


오픈소스로 내놓아라
하지만 수레바퀴를 재발명하려면 많은 노력이 필요하고 혼자나 한 조직내에서만 이뤄내기는 쉽지 않다. 기존의 오픈소스들이 만족스럽지 않아서 사내에서 새로운걸 만들고 싶다면 오픈소스화 해서 세상에 공개해라. 수 많은 개발자들의 검증을 받을 수 있고 돈을 안들이고도 소스를 수정해 주는 열정적인 개발자를 만날 수 있을지도 모른다. 그리고 당연히 여러 사람이 모이면 더 좋은 해결책을 찾을 수 있고 사내에서만 개발하는 것보다 여러모로 이점을 가질 수 있다. 오픈소스에서 실제 성능과 기능으로 다른 프레임워크와 경쟁하는 식으로 접근한다면 프레임워크의 질을 좋게 유지할 수도 있고 설사 더 좋은 프레임워크가 나오더라도 손해볼 일은 그다지 없다.(그렇다면 더 좋은 해결책이 있는데 좋지 않은 해결책을 사내에 적용하려 했다는 것이므로..)



덧) 이건 사내 프레임워크에 대한 비판글인지... 오픈소스 찬양글인지... 쓰다보니 모호해진 감이...