Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

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

보통 이런 제목은 안쓰는 편이긴 한데 약간 낚시성(?) 제목을 작성했다.(적당한 제목이 생각 안나기도 해서...) 엄청 많은 회사를 다녀본 것은 아니지만 많은 개발 조직 혹은 회사가 자체 프레임워크나 라이브러리를 가지고 있거나 가지려고 하고 있다. 나는 이러한 시도를 그다지 안좋아하는데 그런 얘기를 해보려고 한다. 어떤 선을 딱 긋기는 어렵지만 보통 사내 프레임워크라 불리는 정도로 포커싱을 해서 얘기해보자.


흐름 자체는 자연스
개발자들은 기본적으로 중복작업 혹은 반복 작업을 별로 좋아하지 않는다. 그래서 여건이 허락하는 내에서는 중복된다고 생각되는 모든 것을 공통화 혹은 자동화해서 제거하게 된다. 이러한 과정은 간단한 리팩토링부터 프로세스 자동화까지 포함되고 리팩토링에서 나아가 업무상 공통이 된다고 생각하는 부분은 별도 라이브러리로 추출하게 되고 더 나아가게 되면 프레임워크를 작성해서 서비스쪽을 개발하는 개발자들은 추상화레벨 위에서 로직개발에만 신경쓰도록 하려는 것은 아주 자연스러운 흐름이다. 실제로 이러한 흐름을 통해서 수많은 오픈소스들이 등장한다고 생각한다.


회사내 프레임워크의 문제
앞에서 자연스러운 흐름이라고 얘기했고 "사내 업무에 특화된 똑같은 작업을 회사차원에서 공통 프레임워크로 작성하면 생산성을 높일 수 있다"라는 유혹(?)은 꽤 달콤해 보이지만 실제로 기대대로 되지 않는다고 본다.(오히려 생산성을 낮추는 효과까지) 내가 본 혹은 들은 프레임워크들은 이 자연스러운 흐름과는 달리 많은 문제점을 가지고 있다.


흐름이 반대로 되어 있다
앞에서 자연스럽다고 한 것은 실제 개발을 하면서 반복되는 부분의 불편함을 느끼고 공통화를 추출해내는 것이다. 경험이 많아지면 작성해 보기 전에도 어느정도 미리 공통화할 부분을 뽑아낼 수 있기는 하다. 이러한 흐름은 자연스러운데 개발업무를 수행하면서 어느정도 공통화를 할 수 있더라도 프레임워크 수준으로 제작하려면 많은 공수가 들어간다. 회사가 해당 프로젝트를 허용해 주지 않는한 업무를 수행하면서 프레임워크 수준으로 개발하기는 좀처럼 쉽지 않다.(각 부분에서 실제 개발을 하면서 필요한걸 공통화하고 라이브러리하는 접근이 훨씬 더 좋다고 본다. 그러면서 시간을 할당해서 좀더 나은 형태로 만들고...)

실제 사내 프레임워크의 제작 과정을 본 적은 없지만 일반적으로는 윗분의 의지로 프레임워크를 만들게 되고 이를 위해서 별도의 조직을 만들어서 프레임워크만 만들게 한다. 시작이 모두 이렇게 되는지는 모르지만 결과적으로는 프레임워크를 만드는 별도의 조직이 구성되게 된다. 여기서 문제가 발생한다고 보는데 서비스 혹은 제품을 개발하는 사람과 프레임워크를 개발하는 사람이 분리되고 프레임워크를 개발하는 쪽에서 이런 부분이 필요할꺼라고 추측해서 개발을 하게 되고 당연히 서비스쪽의 니즈를 다 충족시키기는 어렵다. 실제로 개발하면서 공통화되었으면 하는 부분이 바로바로 프레임워크에 전달되고 적용되기는 무척 어렵고(분리된 조직의 비효율성도 한몫한다) 시간이 지날수록 점점 거리가 멀어지는 것 같다.


실제로 별로 좋지 않다
이런 문제를 빼고서도 경험상 보면 실제로 별로고 자체 프레임워크를 사용하는 쪽에서는 금세 오래된 기술을 사용하고 있다고 느끼게 된다. 회사 조직상 우수한 인력만 모으는 것이 쉽지 않은 탓에 프레임워크를 제작하는 개발자들이 그정도 수준이 되는지 의심스러운 경우도 많아 보인다. 많은 경우는 프레임워크를 만들 수 있기 때문에 만든다기 보다는 프레임워크를 만드는게 업무로 떨어졌기 때문에 만드는 경우도 다소 존재하게 된다. 현재 관심가지는 오픈소스들은 수많은 오픈소스 중에서 인정받은 프로젝트들이므로 당연히 커미터들의 실력도 단연 우수한다. 이런 전세계를 기반으로 한 인력 풀(pool)에 비해 한 회사에서 구성한 인력 풀(pool)의 질이 떨어지는 것은 당연하다고 본다.(개개인이 부족하다는 얘기하곤 좀 다르다.)

설사 아주 우수한 인력으로 만들었다고 하더라도 IT에서 기술의 발전과 흐름의 변화는 아주 빠르기 때문에 만들 당시에는 아주 혁신적이고 좋은 구현체라고 할지라도 금세 뒷쳐지게 마련이다. 오픈소스 프레임워크와 사내 프레임워크를 양쪽 다 아는 입장에서는 시간이 지나면서 사내 프레임워크가 추세를 제대로 따라잡지 못한다면 금세 오래되고 좋지 않은 프레임워크로 생각하게 마련이다. 추세를 따라가는게 쉬운 일이 아니지만 회사가 우수인력을 한 조직에 수년간 계속 유지하는게 쉽지 않기도 하고 기존 레거시를 사용하는 서비스들이 많으므로 쉽게 변경하기 어려운 이유도 있다.


강제 적용
최종적인 문제는 여기서 발생한다고 보는데 이렇게 만들어진 프레임워크를 사내 개발표준으로 강제화해 버린다. 강제화의 정도는 조직마다 다르겠지만 사내의 정치적인 부분이 작용해서 오랜기간 고급인력을 들여서 만든 프로젝트를 아무도 안쓴다면 입장(?)이 곤란해 지므로 모두가 사용하도록 권장(이라면서 사실은 강제)하게 된다. 좋은 프레임워크로 선택하게 하는 것이 아닌 강제화라는 방법을 선택하게 되는 것이다.

사내에서 비슷한 용도의 프로젝트를 2-3개씩 만드는 회사는 없다. 그러므로 선택권은 없어지고 억지로 사용하게 되고 이러한 강제화 프로세스가 완성된다면 제품을 아주 좋게 만들어야할 동기는 사라져버린다. 치명적 버그가 없애고 사용자들이 얘기하는 이슈들을 개선하는 정도로 충분하고 새로운 방식으로 프레임워크를 기반부터 바꾸는 시도는 사용하는 개발자들의 비명이 들릴때까지는 좀처럼 시도하기 어렵다.



그럼 대안은?
그러면 어떻게 해야하는가? 누구나 비슷한 생각을 하겠지만 그냥 오픈소스를 써라.


오픈소스 프레임워크
과거에도 좋았지만 근래에는 오픈소스의 성장세가 아주 크다. 리누스 토발즈가 말한대로 "보고 있는 눈이 충분히 많으면 찾지 못할 버그는 없다."라는 말을 오픈소스들이 제대로 증명해 주고 있다고 본다. 자바 엔터프라이즈라면 Spring, 자바스크립트라면 jQuery 등 충분히 검증받은 걸출한 프로젝트들이 많이 존재한다.

"오픈소스는 무조건 좋다"라고 얘기하고 싶은게 아니라 오픈소스는 계속해서 경쟁하게 되고 경쟁에서 앞선 프로젝트만 살아남게 된다.(경쟁이 무조건 좋은 것은 아니지만 오픈소스에서는 좋은 효과가 난다고 본다.) 많은 사람이 오픈소스 프로젝트에 공헌해서 개선을 하고 있고 더 좋은 해결책이 있는 개발자들은 새로운 프로젝트를 만든다. 새로운 시도가 더 좋은 방법이라면 기존 프로젝트의 인기는 점점 줄어들고 역사속으로 사라진다. 이러한 과정이 계속해서 반복되면서 점점 퀄리티는 좋아지게 된다. 그리고 철저히 사용자 중심이다. 어떤 방법이 좋은가는 반드시 정해진 것은 없다. 여기서의 사용자는 개발자들이지만 제품을 만들어서 내놓고 사용자들이 선택하는 방식이다. 일반적으로 사내에서 진행되는 프레임워크보다 훨씬 사용자 중심적인 구조를 가질 수 밖에 없다. 업무에 특화된 것들이 있다면 이런 오픈소스들 위에 라이브러리처럼 레이어를 올려서 사용할 수 있다. 이 레이어를 프레임워크 의존성이 없게 만든다면 업무에 특화된 공통화에 대한 니즈도 충족시키면서 서비스를 개발하는 쪽의 기술을 제약할 필요도 없고 시대에 뒤떨어졌다는 비판의 부담도 가질 필요 없다. 충분히 이렇게 만들 수 있는 시대이다.

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

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


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


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



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