펌글인데 내용이 괜찮고 또 사라지기전에 보관차원에서 작성해본다.
앞의 글에서 이어집니다.
사내 프레임워크 만들지 말자 - 2
실제 사내 프레임워크의 제작
과정을 본 적은 없지만 일반적으로는 윗분의 의지로 프레임워크를 만들게 되고 이를 위해서 별도의 조직을 만들어서 프레임워크만 만들게
한다. 시작이 모두 이렇게 되는지는 모르지만 결과적으로는 프레임워크를 만드는 별도의 조직이 구성되게 된다. 여기서 문제가
발생한다고 보는데 서비스 혹은 제품을 개발하는 사람과 프레임워크를 개발하는 사람이 분리되고 프레임워크를 개발하는 쪽에서 이런 부분이 필요할꺼라고 추측해서 개발을 하게 되고 당연히 서비스쪽의 니즈를 다 충족시키기는 어렵다. 실제로 개발하면서 공통화되었으면 하는 부분이 바로바로 프레임워크에 전달되고 적용되기는 무척 어렵고(분리된 조직의 비효율성도 한몫한다) 시간이 지날수록 점점 거리가 멀어지는 것 같다.
실제로 별로 좋지 않다
이
런 문제를 빼고서도 경험상 보면 실제로 별로고 자체 프레임워크를 사용하는 쪽에서는 금세 오래된 기술을 사용하고 있다고 느끼게
된다. 회사 조직상 우수한 인력만 모으는 것이 쉽지 않은 탓에 프레임워크를 제작하는 개발자들이 그정도 수준이 되는지 의심스러운
경우도 많아 보인다. 많은 경우는 프레임워크를 만들 수 있기 때문에 만든다기 보다는 프레임워크를 만드는게 업무로 떨어졌기 때문에
만드는 경우도 다소 존재하게 된다. 현재 관심가지는 오픈소스들은 수많은 오픈소스 중에서 인정받은 프로젝트들이므로 당연히 커미터들의
실력도 단연 우수한다. 이런 전세계를 기반으로 한 인력 풀(pool)에 비해 한 회사에서 구성한 인력 풀(pool)의 질이
떨어지는 것은 당연하다고 본다.(개개인이 부족하다는 얘기하곤 좀 다르다.)
설사 아주 우수한 인력으로 만들었다고 하더라도 IT에서 기술의 발전과 흐름의 변화는 아주 빠르기 때문에 만들 당시에는 아주 혁신적이고 좋은 구현체라고 할지라도 금세 뒷쳐지게 마련이다.
오픈소스 프레임워크와 사내 프레임워크를 양쪽 다 아는 입장에서는 시간이 지나면서 사내 프레임워크가 추세를 제대로 따라잡지
못한다면 금세 오래되고 좋지 않은 프레임워크로 생각하게 마련이다. 추세를 따라가는게 쉬운 일이 아니지만 회사가 우수인력을 한
조직에 수년간 계속 유지하는게 쉽지 않기도 하고 기존 레거시를 사용하는 서비스들이 많으므로 쉽게 변경하기 어려운 이유도 있다.
다음의 글로 이어집니다.
클릭해주세요
본 블로그의 각 자료에 관한 설명: 항상 이런글을 링크하고나면 나중에 다시보면 원본 혹은 사본이 없어진경우가 많아 일부는 본문까지 복사해둔다.
글이 도움이 되고, 마음에 드신다면 마구마구 공유 해주세요~
꼬리말 - 노른자집 Music Player 설명서 | 살아있는 추천 글 보기 | 블로그 인기글보기 | 전체글보기
'IT > IT 일반' 카테고리의 다른 글
OOP의 실제 예를 연구하자 (0) | 2017.02.10 |
---|---|
인터넷 커뮤니티 이용 팁 (0) | 2017.02.05 |
폰트: TrueType글꼴 OpenType글꼴 (0) | 2017.02.03 |
사내 프레임워크 만들지 말자 - 4* (0) | 2017.01.26 |
사내 프레임워크 만들지 말자 - 3 (0) | 2017.01.26 |
사내 프레임워크 만들지 말자 - 1 (0) | 2017.01.26 |
웹 프로그래밍 (0) | 2017.01.26 |
Social API 프로그래밍 (0) | 2017.01.21 |
[경제] 샤와 텔러스의 치열한 가격경쟁, 소비자는 즐거워 (0) | 2016.12.27 |
C# vs JAVA - 5/5* (0) | 2016.12.19 |