출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
해당 글을 구분을 어디에 둬야할지 참 모호했는데.. 아웃사이더 햄도 어쨌거나 본인의 의견을 담은 사담같은 부분이 있기에 [Talk] 에 두기로 했다.. 그리고 이러한 사담성의 성격을 지닌 글을 갖고 오게 된 이유는 내가 생각하지 못했던 부분에 대한 글이기도 하고 한 번쯤은 이러한 고민을 해보고 생각을 해봐도 좋겠다 싶어서이기도 하다..
누군가 그랬지.. 아는만큼 보인다고.. 그 말이 진리인듯 하다.. 본인이 경험해본만큼 그리고 아는만큼 그에 따른 불편함도 편리함도 그리고 파생되는 효과적인 부분도 다 생각하게 되는 듯 하다.. 그럼 이제 본론으로 들어가보도록 하자..
보통 이런 제목은 안쓰는 편이긴 한데 약간 낚시성(?) 제목을 작성했다.(적당한 제목이 생각 안나기도 해서...) 엄청 많은 회사를 다녀본 것은 아니지만 많은 개발 조직 혹은 회사가 자체 프레임워크나 라이브러리를 가지고 있거나 가지려고 하고 있다. 나는 이러한 시도를 그다지 안좋아하는데 그런 얘기를 해보려고 한다. 어떤 선을 딱 긋기는 어렵지만 보통 사내 프레임워크라 불리는 정도로 포커싱을 해서 얘기해보자.
흐름 자체는 자연스럽다
개발자들은 기본적으로 중복작업 혹은 반복 작업을 별로 좋아하지 않는다. 그래서 여건이 허락하는 내에서는 중복된다고 생각되는 모든 것을 공통화 혹은 자동화해서 제거하게 된다. 이러한 과정은 간단한 리팩토링부터 프로세스 자동화까지 포함되고 리팩토링에서 나아가 업무상 공통이 된다고 생각하는 부분은 별도 라이브러리로 추출하게 되고 더 나아가게 되면 프레임워크를 작성해서 서비스쪽을 개발하는 개발자들은 추상화레벨 위에서 로직개발에만 신경쓰도록 하려는 것은 아주 자연스러운 흐름이다. 실제로 이러한 흐름을 통해서 수많은 오픈소스들이 등장한다고 생각한다.
회사내 프레임워크의 문제
앞에서 자연스러운 흐름이라고 얘기했고 "사내 업무에 특화된 똑같은 작업을 회사차원에서 공통 프레임워크로 작성하면 생산성을 높일 수 있다"라는 유혹(?)은 꽤 달콤해 보이지만 실제로 기대대로 되지 않는다고 본다.(오히려 생산성을 낮추는 효과까지) 내가 본 혹은 들은 프레임워크들은 이 자연스러운 흐름과는 달리 많은 문제점을 가지고 있다.
흐름이 반대로 되어 있다
앞에서 자연스럽다고 한 것은 실제 개발을 하면서 반복되는 부분의 불편함을 느끼고 공통화를 추출해내는 것이다. 경험이 많아지면 작성해 보기 전에도 어느정도 미리 공통화할 부분을 뽑아낼 수 있기는 하다. 이러한 흐름은 자연스러운데 개발업무를 수행하면서 어느정도 공통화를 할 수 있더라도 프레임워크 수준으로 제작하려면 많은 공수가 들어간다. 회사가 해당 프로젝트를 허용해 주지 않는한 업무를 수행하면서 프레임워크 수준으로 개발하기는 좀처럼 쉽지 않다.(각 부분에서 실제 개발을 하면서 필요한걸 공통화하고 라이브러리하는 접근이 훨씬 더 좋다고 본다. 그러면서 시간을 할당해서 좀더 나은 형태로 만들고...)
실제 사내 프레임워크의 제작 과정을 본 적은 없지만 일반적으로는 윗분의 의지로 프레임워크를 만들게 되고 이를 위해서 별도의 조직을 만들어서 프레임워크만 만들게 한다. 시작이 모두 이렇게 되는지는 모르지만 결과적으로는 프레임워크를 만드는 별도의 조직이 구성되게 된다. 여기서 문제가 발생한다고 보는데 서비스 혹은 제품을 개발하는 사람과 프레임워크를 개발하는 사람이 분리되고 프레임워크를 개발하는 쪽에서 이런 부분이 필요할꺼라고 추측해서 개발을 하게 되고 당연히 서비스쪽의 니즈를 다 충족시키기는 어렵다. 실제로 개발하면서 공통화되었으면 하는 부분이 바로바로 프레임워크에 전달되고 적용되기는 무척 어렵고(분리된 조직의 비효율성도 한몫한다) 시간이 지날수록 점점 거리가 멀어지는 것 같다.
실제로 별로 좋지 않다
이런 문제를 빼고서도 경험상 보면 실제로 별로고 자체 프레임워크를 사용하는 쪽에서는 금세 오래된 기술을 사용하고 있다고 느끼게 된다. 회사 조직상 우수한 인력만 모으는 것이 쉽지 않은 탓에 프레임워크를 제작하는 개발자들이 그정도 수준이 되는지 의심스러운 경우도 많아 보인다. 많은 경우는 프레임워크를 만들 수 있기 때문에 만든다기 보다는 프레임워크를 만드는게 업무로 떨어졌기 때문에 만드는 경우도 다소 존재하게 된다. 현재 관심가지는 오픈소스들은 수많은 오픈소스 중에서 인정받은 프로젝트들이므로 당연히 커미터들의 실력도 단연 우수한다. 이런 전세계를 기반으로 한 인력 풀(pool)에 비해 한 회사에서 구성한 인력 풀(pool)의 질이 떨어지는 것은 당연하다고 본다.(개개인이 부족하다는 얘기하곤 좀 다르다.)
설사 아주 우수한 인력으로 만들었다고 하더라도 IT에서 기술의 발전과 흐름의 변화는 아주 빠르기 때문에 만들 당시에는 아주 혁신적이고 좋은 구현체라고 할지라도 금세 뒷쳐지게 마련이다. 오픈소스 프레임워크와 사내 프레임워크를 양쪽 다 아는 입장에서는 시간이 지나면서 사내 프레임워크가 추세를 제대로 따라잡지 못한다면 금세 오래되고 좋지 않은 프레임워크로 생각하게 마련이다. 추세를 따라가는게 쉬운 일이 아니지만 회사가 우수인력을 한 조직에 수년간 계속 유지하는게 쉽지 않기도 하고 기존 레거시를 사용하는 서비스들이 많으므로 쉽게 변경하기 어려운 이유도 있다.
강제 적용
최종적인 문제는 여기서 발생한다고 보는데 이렇게 만들어진 프레임워크를 사내 개발표준으로 강제화해 버린다. 강제화의 정도는 조직마다 다르겠지만 사내의 정치적인 부분이 작용해서 오랜기간 고급인력을 들여서 만든 프로젝트를 아무도 안쓴다면 입장(?)이 곤란해 지므로 모두가 사용하도록 권장(이라면서 사실은 강제)하게 된다. 좋은 프레임워크로 선택하게 하는 것이 아닌 강제화라는 방법을 선택하게 되는 것이다.
사내에서 비슷한 용도의 프로젝트를 2-3개씩 만드는 회사는 없다. 그러므로 선택권은 없어지고 억지로 사용하게 되고 이러한 강제화 프로세스가 완성된다면 제품을 아주 좋게 만들어야할 동기는 사라져버린다. 치명적 버그가 없애고 사용자들이 얘기하는 이슈들을 개선하는 정도로 충분하고 새로운 방식으로 프레임워크를 기반부터 바꾸는 시도는 사용하는 개발자들의 비명이 들릴때까지는 좀처럼 시도하기 어렵다.
그럼 대안은?
그러면 어떻게 해야하는가? 누구나 비슷한 생각을 하겠지만 그냥 오픈소스를 써라.
오픈소스 프레임워크
과거에도 좋았지만 근래에는 오픈소스의 성장세가 아주 크다. 리누스 토발즈가 말한대로 "보고 있는 눈이 충분히 많으면 찾지 못할 버그는 없다."라는 말을 오픈소스들이 제대로 증명해 주고 있다고 본다. 자바 엔터프라이즈라면 Spring, 자바스크립트라면 jQuery 등 충분히 검증받은 걸출한 프로젝트들이 많이 존재한다.
"오픈소스는 무조건 좋다"라고 얘기하고 싶은게 아니라 오픈소스는 계속해서 경쟁하게 되고 경쟁에서 앞선 프로젝트만 살아남게 된다.(경쟁이 무조건 좋은 것은 아니지만 오픈소스에서는 좋은 효과가 난다고 본다.) 많은 사람이 오픈소스 프로젝트에 공헌해서 개선을 하고 있고 더 좋은 해결책이 있는 개발자들은 새로운 프로젝트를 만든다. 새로운 시도가 더 좋은 방법이라면 기존 프로젝트의 인기는 점점 줄어들고 역사속으로 사라진다. 이러한 과정이 계속해서 반복되면서 점점 퀄리티는 좋아지게 된다. 그리고 철저히 사용자 중심이다. 어떤 방법이 좋은가는 반드시 정해진 것은 없다. 여기서의 사용자는 개발자들이지만 제품을 만들어서 내놓고 사용자들이 선택하는 방식이다. 일반적으로 사내에서 진행되는 프레임워크보다 훨씬 사용자 중심적인 구조를 가질 수 밖에 없다. 업무에 특화된 것들이 있다면 이런 오픈소스들 위에 라이브러리처럼 레이어를 올려서 사용할 수 있다. 이 레이어를 프레임워크 의존성이 없게 만든다면 업무에 특화된 공통화에 대한 니즈도 충족시키면서 서비스를 개발하는 쪽의 기술을 제약할 필요도 없고 시대에 뒤떨어졌다는 비판의 부담도 가질 필요 없다. 충분히 이렇게 만들 수 있는 시대이다.
물론 오픈소스가 가지는 제약사항도 있다. 우리가 원하는 기능이 없을 수도 있고(이건 바로 앞에서 얘기한 방법으로 해결할 수 있을 것이다.) 우리에게 중요한 어떤 이슈가 오픈소스 프로젝트에서는 다른 이슈에 우선순위가 밀려서 개선되지 않을 수도 있다. 하지만 이러한 문제는 앞에서 프레임워크 개발팀을 구성했듯이 오픈소스 대응팀같은 걸 만들어서 필요한 부분을 직접 개선해서 오픈소스에 공헌할 수 있다. 이렇게 할 수 있다면 자체적으로 개발해서 운영하는 것보다 훨씬 적은 비용으로 더 좋은 프레임워크를 얻을 수 있다. 오픈소스 생태계도 좋아지고 비용도 줄어드는 말그대로 윈윈이다.
더군다나 자체 프레임워크를 만들면 필연적으로 필요한 문서화나 인력충원에 대한 부담도 오픈소스 프레임워크를 사용하면 엄청나게 줄일 수 있다. 만약 스프링이나 jQuery를 쓴다면 사내에서 문서를 만들필요 없이 이미 시장에 많은 문서들이 나오고 수많은 이슈와 해결책에 대한 글이 구글에서 검색만 하면 찾아낼 수 있게 된다. 사내에만 특화된 부분만 따로 문서화하면 그뿐이다. 인력충원도 새로 뽑아서 새로운 프레임워크의 사용방법 가르쳐주고 하는 과정을 반복할 필요없이 해당 프레임워크의 경험자를 그냥 뽑으면 되고 어쩌면 훨씬 더 잘 아는 사람을 뽑을 수 있을지도 모른다.
수레바퀴는 재발명해도 된다
"이미 있는데 뭐하러 또 만들어!"라고 얘기하고 싶은건 아니다. "수레바퀴를 재발명하지 말라."는 프로그래밍의 오래된 격언이지만 사실 이는 어디까지 추상화하고 그 위에서 개발할 것인가의 문제일 뿐 수레바퀴를 게속 개선할 필요는 있다.(수레바퀴 비유는 여전히 유용하지만 좀 과용되는가 감도 있다.)그리고 수레바퀴를 더 좋은 수레바퀴로 만들려면 지금의 수레바퀴를 어떻게 만들었는지 알아야 하므로 수레바퀴를 재발명하는 시도자체를 말리고 싶진 않다.(오히려 권장하고 싶다.) 그러면서 점점 좋은 수레바퀴가 만들어지는 것이다.
오픈소스로 내놓아라
하지만 수레바퀴를 재발명하려면 많은 노력이 필요하고 혼자나 한 조직내에서만 이뤄내기는 쉽지 않다. 기존의 오픈소스들이 만족스럽지 않아서 사내에서 새로운걸 만들고 싶다면 오픈소스화 해서 세상에 공개해라. 수많은 개발자들의 검증을 받을 수 있고 돈을 안들이고도 소스를 수정해 주는 열정적인 개발자를 만날 수 있을지도 모른다. 그리고 당연히 여러 사람이 모이면 더 좋은 해결책을 찾을 수 있고 사내에서만 개발하는 것보다 여러모로 이점을 가질 수 있다. 오픈소스에서 실제 성능과 기능으로 다른 프레임워크와 경쟁하는 식으로 접근한다면 프레임워크의 질을 좋게 유지할 수도 있고 설사 더 좋은 프레임워크가 나오더라도 손해볼 일은 그다지 없다.(그렇다면 더 좋은 해결책이 있는데 좋지 않은 해결책을 사내에 적용하려 했다는 것이므로..)
덧) 이건 사내 프레임워크에 대한 비판글인지... 오픈소스 찬양글인지... 쓰다보니 모호해진 감이...
My Comment..
요 근래에 아웃사이더 햄의 글을 갖고오거나 혹은 나 스스로 무엇인가 포스팅을 함에 있어서 가장 많은 생각을 해본 것 같다.. 그렇다고 해서 지난 시간 동안 아무 생각없이 무조건 퍼오고 무조건 포스팅 했다는 뜻은 아니다..
나 스스로 오픈소스 오픈 프레임워크를 다양하게 많이 써보진 않았다.. 개발 자체에 관심을 갖은것 자체가 오래되지는 않았기에 말이다.. 그런데 해당 글을 읽다보니 과거에 스프링을 써봤던 경험, 전자정부프레임워크를 써본경험, 회사내 프레임워크를 써봤던 경험을 떠올리면서 볼 수 있었다..
글에 대한 내 결론은 나도 동감한다!!! 이다.. 회사에서 자체 프레임워크라고 해서 개발을 하고 SI 사업으로 발주를 해서 버전을 올리고 하지만 결국 보면, 그 버전업이라는 것 자체가 특정 개발자들이 혹은 기존 프레임워크를 개발했던 회사가 버전업을 시키는 것인데.. 그 개발인력이 개발하는 환경과 생각 자체도 결국에는 오픈소스에서 출발한다는 것이다..
그래서 과거 전자정부프레임워크를 봐도 그렇고 S 사 프레임워크도 그렇고 B 사 프레임워크도 보면 결국에는 스트럿츠나 스프링에 기반을 두고 있는 시스템이다.. 차이가 있다면..?? 기껏해야 명칭이 바뀌었다는거..?? 아니면, 쓰는 패턴을 살짝만 당사에 맞도록 변경했다는 정도이다..
그런 경험을 하면서도 본문과 같은 생각은 못해봤는데.. 그냥 쓰기만 급급했지.. -_-;;; 이번 기회에 한 번더 고민을 하고 곰곰히 생각을 해보게 되었다.. 내가봐도 아니.. 내가 겪어본 과거를 생각해봐도 어차피 비슷비슷한 A, A-1, A-2 스러운 것을 쓰는것보다는 많은 사람이 쓰고, 그로인해서 수많은 피드백을 통해서 수정하고 업데이트 되고 새로운 버전이 출시되고 하는 오픈소스에 무게를 두는것이 좋다고 본다..
물론, 아무리 그래봐야.. 저마다 생각이 틀리기에 또한, 유니크함을 갖고 싶은 무리..?? 단체가 많기에 자신들의 것을 지금 이순간에도 만들고 있겠지.. 꼭, 세상 어디에도 없는 본인들만의 것을 창조한 것처럼 말이지.. ㅎㅎㅎㅎ
댓글 없음:
댓글 쓰기