보통 이런 제목은 안쓰는 편이긴 한데 약간 낚시성(?) 제목을 작성했다.(적당한 제목이 생각 안나기도 해서...) 엄청 많은 회사를 다녀본 것은 아니지만 많은 개발 조직 혹은 회사가 자체 프레임워크나 라이브러리를 가지고 있거나 가지려고 하고 있다. 나는 이러한 시도를 그다지 안좋아하는데 그런 얘기를 해보려고 한다. 어떤 선을 딱 긋기는 어렵지만 보통 사내 프레임워크라 불리는 정도로 포커싱을 해서 얘기해보자.
흐름 자체는 자연스럽다
개발자들은 기본적으로 중복작업 혹은 반복 작업을 별로 좋아하지 않는다. 그래서 여건이 허락하는 내에서는 중복된다고 생각되는 모든 것을 공통화 혹은 자동화해서 제거하게 된다. 이러한 과정은 간단한 리팩토링부터 프로세스 자동화까지 포함되고 리팩토링에서 나아가 업무상 공통이 된다고 생각하는 부분은 별도 라이브러리로 추출하게 되고 더 나아가게 되면 프레임워크를 작성해서 서비스쪽을 개발하는 개발자들은 추상화레벨 위에서 로직개발에만 신경쓰도록 하려는 것은 아주 자연스러운 흐름이다. 실제로 이러한 흐름을 통해서 수많은 오픈소스들이 등장한다고 생각한다.
회사내 프레임워크의 문제
앞에서 자연스러운 흐름이라고 얘기했고 "사내 업무에 특화된 똑같은 작업을 회사차원에서 공통 프레임워크로 작성하면 생산성을 높일 수 있다"라는 유혹(?)은 꽤 달콤해 보이지만 실제로 기대대로 되지 않는다고 본다.(오히려 생산성을 낮추는 효과까지) 내가 본 혹은 들은 프레임워크들은 이 자연스러운 흐름과는 달리 많은 문제점을 가지고 있다.
흐름이 반대로 되어 있다
앞에서 자연스럽다고 한 것은 실제 개발을 하면서 반복되는 부분의 불편함을 느끼고 공통화를 추출해내는 것이다. 경험이 많아지면 작성해 보기 전에도 어느정도 미리 공통화할 부분을 뽑아낼 수 있기는 하다. 이러한 흐름은 자연스러운데 개발업무를 수행하면서 어느정도 공통화를 할 수 있더라도 프레임워크 수준으로 제작하려면 많은 공수가 들어간다. 회사가 해당 프로젝트를 허용해 주지 않는한 업무를 수행하면서 프레임워크 수준으로 개발하기는 좀처럼 쉽지 않다.(각 부분에서 실제 개발을 하면서 필요한걸 공통화하고 라이브러리하는 접근이 훨씬 더 좋다고 본다. 그러면서 시간을 할당해서 좀더 나은 형태로 만들고...)
실제 사내 프레임워크의 제작 과정을 본 적은 없지만 일반적으로는 윗분의 의지로 프레임워크를 만들게 되고 이를 위해서 별도의 조직을 만들어서 프레임워크만 만들게 한다. 시작이 모두 이렇게 되는지는 모르지만 결과적으로는 프레임워크를 만드는 별도의 조직이 구성되게 된다. 여기서 문제가 발생한다고 보는데 서비스 혹은 제품을 개발하는 사람과 프레임워크를 개발하는 사람이 분리되고 프레임워크를 개발하는 쪽에서 이런 부분이 필요할꺼라고 추측해서 개발을 하게 되고 당연히 서비스쪽의 니즈를 다 충족시키기는 어렵다. 실제로 개발하면서 공통화되었으면 하는 부분이 바로바로 프레임워크에 전달되고 적용되기는 무척 어렵고(분리된 조직의 비효율성도 한몫한다) 시간이 지날수록 점점 거리가 멀어지는 것 같다.
실제로 별로 좋지 않다
이런 문제를 빼고서도 경험상 보면 실제로 별로고 자체 프레임워크를 사용하는 쪽에서는 금세 오래된 기술을 사용하고 있다고 느끼게 된다. 회사 조직상 우수한 인력만 모으는 것이 쉽지 않은 탓에 프레임워크를 제작하는 개발자들이 그정도 수준이 되는지 의심스러운 경우도 많아 보인다. 많은 경우는 프레임워크를 만들 수 있기 때문에 만든다기 보다는 프레임워크를 만드는게 업무로 떨어졌기 때문에 만드는 경우도 다소 존재하게 된다. 현재 관심가지는 오픈소스들은 수많은 오픈소스 중에서 인정받은 프로젝트들이므로 당연히 커미터들의 실력도 단연 우수한다. 이런 전세계를 기반으로 한 인력 풀(pool)에 비해 한 회사에서 구성한 인력 풀(pool)의 질이 떨어지는 것은 당연하다고 본다.(개개인이 부족하다는 얘기하곤 좀 다르다.)
설사 아주 우수한 인력으로 만들었다고 하더라도 IT에서 기술의 발전과 흐름의 변화는 아주 빠르기 때문에 만들 당시에는 아주 혁신적이고 좋은 구현체라고 할지라도 금세 뒷쳐지게 마련이다. 오픈소스 프레임워크와 사내 프레임워크를 양쪽 다 아는 입장에서는 시간이 지나면서 사내 프레임워크가 추세를 제대로 따라잡지 못한다면 금세 오래되고 좋지 않은 프레임워크로 생각하게 마련이다. 추세를 따라가는게 쉬운 일이 아니지만 회사가 우수인력을 한 조직에 수년간 계속 유지하는게 쉽지 않기도 하고 기존 레거시를 사용하는 서비스들이 많으므로 쉽게 변경하기 어려운 이유도 있다.
강제 적용
최종적인 문제는 여기서 발생한다고 보는데 이렇게 만들어진 프레임워크를 사내 개발표준으로 강제화해 버린다. 강제화의 정도는 조직마다 다르겠지만 사내의 정치적인 부분이 작용해서 오랜기간 고급인력을 들여서 만든 프로젝트를 아무도 안쓴다면 입장(?)이 곤란해 지므로 모두가 사용하도록 권장(이라면서 사실은 강제)하게 된다. 좋은 프레임워크로 선택하게 하는 것이 아닌 강제화라는 방법을 선택하게 되는 것이다.
사내에서 비슷한 용도의 프로젝트를 2-3개씩 만드는 회사는 없다. 그러므로 선택권은 없어지고 억지로 사용하게 되고 이러한 강제화 프로세스가 완성된다면 제품을 아주 좋게 만들어야할 동기는 사라져버린다. 치명적 버그가 없애고 사용자들이 얘기하는 이슈들을 개선하는 정도로 충분하고 새로운 방식으로 프레임워크를 기반부터 바꾸는 시도는 사용하는 개발자들의 비명이 들릴때까지는 좀처럼 시도하기 어렵다.
그럼 대안은?
그러면 어떻게 해야하는가? 누구나 비슷한 생각을 하겠지만 그냥 오픈소스를 써라.
오픈소스 프레임워크
과거에도 좋았지만 근래에는 오픈소스의 성장세가 아주 크다. 리누스 토발즈가 말한대로 "보고 있는 눈이 충분히 많으면 찾지 못할 버그는 없다."라는 말을 오픈소스들이 제대로 증명해 주고 있다고 본다. 자바 엔터프라이즈라면 Spring, 자바스크립트라면 jQuery 등 충분히 검증받은 걸출한 프로젝트들이 많이 존재한다.
"오픈소스는 무조건 좋다"라고 얘기하고 싶은게 아니라 오픈소스는 계속해서 경쟁하게 되고 경쟁에서 앞선 프로젝트만 살아남게 된다.(경쟁이 무조건 좋은 것은 아니지만 오픈소스에서는 좋은 효과가 난다고 본다.) 많은 사람이 오픈소스 프로젝트에 공헌해서 개선을 하고 있고 더 좋은 해결책이 있는 개발자들은 새로운 프로젝트를 만든다. 새로운 시도가 더 좋은 방법이라면 기존 프로젝트의 인기는 점점 줄어들고 역사속으로 사라진다. 이러한 과정이 계속해서 반복되면서 점점 퀄리티는 좋아지게 된다. 그리고 철저히 사용자 중심이다. 어떤 방법이 좋은가는 반드시 정해진 것은 없다. 여기서의 사용자는 개발자들이지만 제품을 만들어서 내놓고 사용자들이 선택하는 방식이다. 일반적으로 사내에서 진행되는 프레임워크보다 훨씬 사용자 중심적인 구조를 가질 수 밖에 없다. 업무에 특화된 것들이 있다면 이런 오픈소스들 위에 라이브러리처럼 레이어를 올려서 사용할 수 있다. 이 레이어를 프레임워크 의존성이 없게 만든다면 업무에 특화된 공통화에 대한 니즈도 충족시키면서 서비스를 개발하는 쪽의 기술을 제약할 필요도 없고 시대에 뒤떨어졌다는 비판의 부담도 가질 필요 없다. 충분히 이렇게 만들 수 있는 시대이다.
물론 오픈소스가 가지는 제약사항도 있다. 우리가 원하는 기능이 없을 수도 있고(이건 바로 앞에서 얘기한 방법으로 해결할 수 있을 것이다.) 우리에게 중요한 어떤 이슈가 오픈소스 프로젝트에서는 다른 이슈에 우선순위가 밀려서 개선되지 않을 수도 있다. 하지만 이러한 문제는 앞에서 프레임워크 개발팀을 구성했듯이 오픈소스 대응팀같은 걸 만들어서 필요한 부분을 직접 개선해서 오픈소스에 공헌할 수 있다. 이렇게 할 수 있다면 자체적으로 개발해서 운영하는 것보다 훨씬 적은 비용으로 더 좋은 프레임워크를 얻을 수 있다. 오픈소스 생태계도 좋아지고 비용도 줄어드는 말그대로 윈윈이다.
더군다나 자체 프레임워크를 만들면 필연적으로 필요한 문서화나 인력충원에 대한 부담도 오픈소스 프레임워크를 사용하면 엄청나게 줄일 수 있다. 만약 스프링이나 jQuery를 쓴다면 사내에서 문서를 만들필요 없이 이미 시장에 많은 문서들이 나오고 수많은 이슈와 해결책에 대한 글이 구글에서 검색만 하면 찾아낼 수 있게 된다. 사내에만 특화된 부분만 따로 문서화하면 그뿐이다. 인력충원도 새로 뽑아서 새로운 프레임워크의 사용방법 가르쳐주고 하는 과정을 반복할 필요없이 해당 프레임워크의 경험자를 그냥 뽑으면 되고 어쩌면 훨씬 더 잘 아는 사람을 뽑을 수 있을지도 모른다.
수레바퀴는 재발명해도 된다
"이미 있는데 뭐하러 또 만들어!"라고 얘기하고 싶은건 아니다. "수레바퀴를 재발명하지 말라."는 프로그래밍의 오래된 격언이지만 사실 이는 어디까지 추상화하고 그 위에서 개발할 것인가의 문제일 뿐 수레바퀴를 게속 개선할 필요는 있다.(수레바퀴 비유는 여전히 유용하지만 좀 과용되는가 감도 있다.)그리고 수레바퀴를 더 좋은 수레바퀴로 만들려면 지금의 수레바퀴를 어떻게 만들었는지 알아야 하므로 수레바퀴를 재발명하는 시도자체를 말리고 싶진 않다.(오히려 권장하고 싶다.) 그러면서 점점 좋은 수레바퀴가 만들어지는 것이다.
오픈소스로 내놓아라
하지만 수레바퀴를 재발명하려면 많은 노력이 필요하고 혼자나 한 조직내에서만 이뤄내기는 쉽지 않다. 기존의 오픈소스들이 만족스럽지 않아서 사내에서 새로운걸 만들고 싶다면 오픈소스화 해서 세상에 공개해라. 수많은 개발자들의 검증을 받을 수 있고 돈을 안들이고도 소스를 수정해 주는 열정적인 개발자를 만날 수 있을지도 모른다. 그리고 당연히 여러 사람이 모이면 더 좋은 해결책을 찾을 수 있고 사내에서만 개발하는 것보다 여러모로 이점을 가질 수 있다. 오픈소스에서 실제 성능과 기능으로 다른 프레임워크와 경쟁하는 식으로 접근한다면 프레임워크의 질을 좋게 유지할 수도 있고 설사 더 좋은 프레임워크가 나오더라도 손해볼 일은 그다지 없다.(그렇다면 더 좋은 해결책이 있는데 좋지 않은 해결책을 사내에 적용하려 했다는 것이므로..)
덧) 이건 사내 프레임워크에 대한 비판글인지... 오픈소스 찬양글인지... 쓰다보니 모호해진 감이...
Outsider's Dev Story
Stay Hungry. Stay Foolish. Don't Be Satisfied.
내용에 동감하고 동의합니다.
고민많이 하다가 정리한건데 동감해 주셔서 감사합니다. ㅎ
수레 재발명도 제발좀 안했으면 좋겠습니다. 정 발명하고 싶은게 있으면 오픈소스 포크해서 필요한 기능 넣어서 들고가면되지.....
저도 그런건 답답해 하긴 하지만 새로운 접근에 대한 시도나 더 좋은 방법이 있다면 재발명해도 된다는 쪽입니다. 일반적으로는 그런 의도로 하는게 아니라 그냥 똑같은걸 하나 더 만들어내버려서 문제이긴 한데... 많은 것들이 같은 결과를 더 좋은 해결책으로 바꿔나가면서 현재까지 온거니까요.. 그런부분에 대한 얘기였습니다...
관리자만 볼 수 있는 댓글입니다.
앗... ㅠㅠ 맞춤법이.. 흑흑 고쳤습니다.
라이브러러는 있어야겠지요. 그렇다면 라이브러리와 프레임웍은 어떻게 구분할지 ㅋ
프레임워크와 라이브러리의 구분은 토비의 스프링에 나온 표현이 제일 적절하다고 생각합니다.
>라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접제어한다.
>반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다.
이 기준으로는 jQuery는 라이브러리에 분류되지만 이 글의 의도에서는 그 구분까지는 필요없다고 생각해서요... 특화된 부분은 공통화해서 만들필요가 있겠지요.
앱의 흐름을 제어하면 프레임웍이라니 의미있군요^^
완전 동감하고 있습니다.
^^
이해는 가지만 동의는 할 수 없는 글입니다.
항상 동의하는 글만 읽다가 뭔가 말 하고 싶은 대목이어서 처음으로 댓글 남겨 봅니다.
동의 할 수 없는 이유는 짧게 거론해 볼께요.
제 의견이 이런것은 사내 프레임웍 담당 개발자와 일선 프로젝트 PL을 번갈아 가며 오랜 시간을 보냈었기 때문일지도 모르겠지만,
소속과 문화와 수준이 천차 만별인 수 많은 개발자들이 서로 시간차를 두고
프로젝트 구성원으로 모였을때,
이것을 시스템적으로 제어 하는 가장 좋은 방법은 프레임웍인 경우가 많습니다.
동일한 코드의 패턴, 네이밍 룰과 파일의 위치까지 통제해 주는 오픈 소스 프레임워크는
존재하지 않으니까요. 심지어는 단순한 유틸 클래스 마저도 오픈소스를 랩핑시켜야 하는 경우도 많습니다.
마지막 문제는 오픈소스 프레임웍에 진입장벽과 러닝커브가 오히려 더 크다는 것 일 겁니다. 제대로 알고 쓰는 사람이 많지 않다는 거죠.
토비의 스프링 책 1,2권을 선물로 주고 강의를 해줄 수 도 없는 노릇이니까요.
괜한 소리를 했나 싶네요.. ㅎㅎ
동감하시는 분들을 보면 기분 좋기도 하지만 저도 뭐 다 경험한 것도 아니고 모든 상황에 다 맞는 의견도 없다고 생각하기에 태클(?)도 환영합니다.
정확히 어떤 부분을 말씀하시는지 모르겠지만 프레임워크를 사용하는 자유도에 대한 생각의 차이가 아닐까 생각해 봅니다. SI같은 경우 오픈 소스 프레임워크의 자유도에 비해서 훨씬 엄격하면서 거의 반이상 완성된 프레임워크에 빈 자리만 채워넣는 형태로 제공하는 경우도 있다고 들었지만 사실 이는 양날의 검이라고 생각하기에 프레임워크가 그렇게 엄격하게 파일의 위치까지 제어해야하는지 모르겠습니다. A사 프레임워크를 능숙히 다루지만 B사 프레임워크에서는 초보개발자 수준이라면 누굴 탓해야 하는 걸까요? 그리고 유틸리티 클래스 같은건 얼마든지 프레임워크에 의존성 없이 제공할 수 있지 않나요?
오픈소스 프레임워크의 러닝커브가 더 크다는 점에는 완전히 동의할 수 없지만 자체 프레임워크들에 비해서 훨씬 보편적인 개념이 들어갔기에 장기적으로 보면 훨씬 이익이라고 보고 있습니다.
괜한 소리 하신거 아닙니다. ^^
저도 동감입니다; 요새 너무 고생하고 있습니다; ㅠㅠ
요즘 프레임워크를 만들고 계신가 보군요.. ㅠㅠ
조아요 <3
is윤군님이 좋아합니다.
다만, 오픈소스에 변경이 필요하고 이를 패치했는데, 메인 스트림에 들어가지 않는 경우에는, 오픈소스의 버전업에 따라서 꽤 많은 시간이 필요한듯 하더군요. 역시 모든것은 케바케라는 ㅎㅎㅎ
오픈소스나 업무 특성에 따라 그런경우도 있긴 하겠죠... 오픈소스도 관리안되는 프로젝트들도 있고요. ㅎ
좋은 글 잘 보았습니다.
글 내용이 모두 깊이 공감이 됩니다.
개발자들의 생각과 경영진들과의 생각이 달라서 빚어지는 많은 일들 중
하나를 잘 짚어낸 글이군요.
단, 보안 관련된 프레임워크는 사내 전사 프로젝트로 진행하는 것이 옳다고 봅니다.
공감해주셔서 다행입니다. ㅎㅎㅎ
보안도 상황에 따라 애매하긴 하지만 특화된 부분은 사내에서 공통화하는게 맞다고 봅니다. 그런 부분까지 얘기한건 아니라는걸 이해하시리라 생각합니다. ㅎ
전적으로 동의합니다.
공통 라이브러리를 만드는것은 찬성을 하지만, Framework를 만드는것은 문제가 있다고 생각합니다.
위에 적으신것처럼, 암호화와 보안, 회사 LDAP에 대한 공통 SSO 정도의 라이브러리를 제공하는 것은 어찌보면 개발팀의 당연한 의무이겠지만, 제어의 흐름을 바꿔버리는 Framework를 사내에서 따로 만드는것은 인력 및 시간 낭비인것 같습니다.
그렇지만.. 위에 적으셨던 내용과 같이, 대부분이 정치적 이유로 이런 일들이 만들어지는 것 같은 것이 현실이군요.;
사내 정치는 사실 다른 부분에서도 많은 문제가 되지만 전사 프레임워크는 정말 아닌것 같아요.
비슷한 논조를 가진 CIO의 기사가 떠올랐었는데, 우연찮게 링크를 다시 확보하게 되서 남깁니다.
'2013년 하지 말아야 할' 9가지 애플리케이션 개발 프로젝트 - http://www.ciokorea.com/news/15198
저도 저글을 보았습니다. 결과적으로 비슷하긴 하지만 얘기하고자 하는 바는 좀 다르긴 하죠. 그리고 전 기술이 미천해서 하지 말아야 할 정도인지는 잘 모르겠습니다. 항상 레드오션이라고 생각한 곳에서 혁신이 터져나오는걸 많이 봐서요... 강제화만 하지 않는다면 학습(?)차원에서 하는건 말리진 않습니다. ㅎ
저도 꽤나 이렇게 얘기 많이 하구 댕겼는데 오랜만에 생각이 같은 글을 만나서 반가워서 댓글 답니다 ㅎㅎ 수레바퀴 얘기는 matz가 꽤나 감동적인 speech를 해서 말리면 욕먹을거 같기도 하네요.
저도 수레바퀴를 만드는 시도자체는 반대하지 않습니다. 마츠가 어떤 얘기를 했는지 궁금하군요.
https://speakerdeck.com/yukihiro_matz/reinventhing-wheels-of-future
https://www.youtube.com/watch?v=hgs_fVfsduA
제가 히어링이 좀 에바라 영어는 잘 안들리네요; ㅋ 발음이 그리 좋지는 않으신거 같기도 하구요; ㅎㅎ
못찾고 있었는데 감사합니다. ㅎ
백프로 이백프로 공감합니다.
결국 사내시스템이 흐름을 역행하는 모습을 보이고 뒤쳐지는 상황은 스스로를 가둬버리는 사내프레임워크 때문인 것을 개발하며 경험했습니다. 개발자에게도 좋지않은 생태계를 조성해버리는것 같네요
오래된 글이 오랜만에 다시 공유되면서 이슈가 되었네요 ㅎㅎ 특히 국내에서 이런 모습이 많이 보이는것 같아서 아쉽네요.
내용을 쭉 읽고나서 고민하다 저도 한마디 남겨봅니다.
우선 언급하신 부분외에도 사내프레임워크가 주는 또 하나의 단점이 하나 있는데 사내 프레임워크가 어느 정도 만들어져서 잘 사용되면 발생하는 단점입니다. 이게 오래 잘 지속되는 경우에는 조직내에서 소위 에이스급들이 프레임워크 개발조직에 몰리게 됩니다. 그리고 다른 일반 조직은 개발바보가 되가는게 보이지요. 결국 프레임워크가 난이도 있고 어려운 작업들은 다 맡아버리고 개발자에게 남는거는 거의 똑같은 업무 로직정도만 남고 더 이상 신기술 적용도 새로운 기술적 시도도 할 기회가 없는거죠.
제 자신이 회사에서 프레임워크를 만든다고 차출되어서 개발과 지원만 몇년을 하고 현재는 제품총괄을 하는 입장이다보니 적으신 내용과는 다른 의미로 단점들이 드러나는 것도 있어서 적었습니다. 그리고 사내 프레임워크들이 다 불량품만 있는건 아니랍니다. 그리고 오픈소스 프레임워크의 대표격인 Spring도 핵심 코드들 열어보면 모듈별로 퀄리티가 들쭉날쭉합니다. 즉 오픈소스라고 다 퀄리티가 높은것만도 아니지요.
아무래도 쓰신 내용 자체가 제 주업이다보니 주제넘게 한마디 적었습니다.
좋은 의견 감사합니다. 저도 여러 부분 생각해 보며 적었지만 결국 제가 경험한 환경에 대해서만 쓸 수 있다보니 약간은 편향적일 수밖에 없습니다.
저는 제대로 된 사내 프레임워크는 본 적이 없어서 특히 싫어하는 편이라 그쪽에 대해서 적은데 잘되었을때도 그런 문제가 있을 수 있겠군요. 그런 의미에서도 저는 오픈소스 프레임워크를 쓰면서 각 조직별로 에이스들이 배치되어 회사 전체의 개발자 수준을 높히는 쪽이 장기적으로 좋다고 보고 있습니다. 말씀하신대로 오픈소스라고 다 좋은 것은 아니지만 확률상 좋을 확률이 높다고 생각하는 편이고 마지막에 쓴대로 실제 오픈 소스 프로젝트가 별로라면 사내 프로젝트를 오픈소스로 공개하면 더 발전할 수 있는 여지도 있고 회사 기술력 홍보에도 좋다고 보고 있습니다.
완전공감함니다. 근데 오픈 소스를 만들 의지를 가진 조직이 얼마나 잇을까 하네요
그래도 요즘은 오픈소스로 공개해서 아파치 인큐베이터로도 많이 들어가고 많아 나아지고 있다고 생각합니다. ㅎㅎ
제 댓글을 보실지 모르겠습니다만^^;
좋은 의견 감사드리며,
작성하신 의견에 매우 공감하고 있습니다.
0.사내프레임워크가 관리가 잘 안되는 이유도 있지만...
1.경영진의 정치적인 이유로 사용되는 경우를 많이 봤습니다.
2.개발자의 창의성을 낮추고 기술역량을 키우기에 어렵습니다.
3.급변하는 기술 및 비즈니스 요구사항을 발빠르게 대응하기 어렵습니다.
사내프레임워크가 무조건 나쁘다고 생각하지는 않습니다만,
서비스 성격을 고려하지 않고 정치적인 이유로 사내프레임워크를 무조건 사용하도록 강요하고, 사용하지 않으면 불이익을 주는 현실을 경험하고 있습니다ㅠㅠ
(예전에는 이 문제로, 윗사람들과 많은 마찰이 있었습니다만, 제 생각이 무조건 정답이 아니고, 먹여살려야할 가정도 있어서 요즘에는 그냥 시키는대로 하자.라는 생각으로 일하고 있습니다만...)
현실과 이상 사이에서 균형을 잡기가 쉽지가 않네요.
간만에 공감되는 글이라서 댓글 남겨봤습니다.
네 댓글은 놓치지 않는 한은 다 보고 있습니다. ^^ 말씀하신대로 사내 프레임워크를 만들 규모에서는 정치적인 이유가 제일 크다고 생각합니다. 사내 프레임워크를 잘 만들어서 오픈소스로 공개해서 다른 사람들도 사용하게 하는 것은 꽤 좋은 일이라고 보지만 국내에서는 말씀하신대로 정치적인 이유로 잘 안되는 경우가 훨씬 많은 것 같네요. 말씀하신대로 현실과 이상의 차이를 메꾸기가 쉽지 않죠. ㅠㅠ