[NEWS] 기술 뉴스 #14 : 14-09-01..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

웹개발 관련

• Chrome Enchanted: 2014년 주목할만한 HTML5 규격 4종 : 도창욱님이 정리한 글로 Web Components, Web Animations, WebRTC, Service Worker 기술의 개념을 잡기에 잘 정리된 글이다. 개인적으로는 Web Components와 Service Worker에 관심이 있는 편이다.(한글)
• JavaScript Memory Management Masterclass : JavaScript의 메모리 관련 성능개선과 관련해서 아주 깊은 내용까지 잘 정리된 발표자료(영문)
• 온라인 장애 체험관 : 네이버 NULI에서 접근성 확대를 위해 온라인 장애 체험관 사이트를 열었다(한글)
• 반응형 웹 디자인의 현재 : Smashing Magazine의 The State Of Responsive Web Design를 번역한 글로 반응형 웹과 관련된 기술들을 잘 설명한 글이다. 현재 반응형 웹을 구현하는 방법이라기보다는 현재의 문제점과 새로운 기술들이 어떻게 해결하려고 하고 있는지를 설명하고 있어서 반응형 웹 디자인에 관심이 있다면 알아둘 필요가 있는 내용이다.(한글)
  

그 밖의 프로그래밍 관련

• Beautiful Open : 오픈 소스 프로젝트 사이트 중에서 디자인이 좋은 사이트만 모아놓은 곳(영문)
• Common App Rejections : 애플이 앱스토어에서 앱 리뷰를 거절하는 이유를 정리해 놓은 페이지를 공개했다.(영문)
• Java 9 Features Announced : 오라클에서 Java 9의 기능을 처음으로 공개했다. Java 8도 먼 얘기로 들리는 상황에 벌써 자바 9을 얘기하는 게 맞는지 모르겠지만, 경량 JSON API, HTTP 2 클라이언트 등이 포함되었다.(영문)
• VisuAlgo : 정렬, 큐, 트리 등의 데이터 구조나 알고리즘을 동작 방식을 애니메이션으로 코드와 함께 보여주는 사이트. 알고리즘을 애니메이션으로 보여주는 사이트가 다수 있지만 깔끔한 디자인과 코드와 함께 보여주고 있어서 알고리즘을 이해하기에 좋다.(영문)
• Open Sourcing the f8 Conference Apps : 페이스북이 인수한 DBaaS 업체인 Parse에서 페이스북 콘퍼런스인 f8용으로 만든 앱을 오픈 소스로 공개했다. 이 앱은 Parse를 기반으로 만들어졌다.(영문)
• PYCON Korea 2014 : 국내 첫 파이썬 콘퍼런스가 지난 8월 30일에 숙명여대에서 열렸다. 나는 안타깝게도 참석을 못 했지만 콘퍼런스 사이트에 가면 발표자료를 볼 수 있다.(한글)
  

IT 업계 뉴스

• Amazon’s Twitch Acquisition Is Official : 아마존이 게임 스트리밍 서비스인 Twitch를 1조원에 인수했다.(영문)
• 구글의 스타트업 전용공간, ‘캠퍼스 서울’이 문을 엽니다! : 구글이 아시아 최초로 캠퍼스 서울을 설립하고 국내 스타트업 을 지원할 예정이다.(한글)
  

볼만한 링크

• 뉴욕타임스 혁신보고서(번역본) : 170페이지 정도의 PDF로 뉴욕타임스의 혁신보고서의 번역본이다. 내용이 길어서 다 읽어보진 못했고 IT 기술 내용이 위주는 아닌 것 같지만 관심 가는 주제라서 링크를...(한글)
• GitHub – Cracking the Code to GitHub’s Growth : Github의 성장과 관련해서 분석한 글이다. 긴 글이지만 Github이 어떠한 전략을 사용하면서 성장했고 어떤 부분을 중요시하는지 잘 정리되어 있다.(영문)

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

출처 : 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 스러운 것을 쓰는것보다는 많은 사람이 쓰고, 그로인해서 수많은 피드백을 통해서 수정하고 업데이트 되고 새로운 버전이 출시되고 하는 오픈소스에 무게를 두는것이 좋다고 본다..

물론, 아무리 그래봐야.. 저마다 생각이 틀리기에 또한, 유니크함을 갖고 싶은 무리..?? 단체가 많기에 자신들의 것을 지금 이순간에도 만들고 있겠지.. 꼭, 세상 어디에도 없는 본인들만의 것을 창조한 것처럼 말이지.. ㅎㅎㅎㅎ

[Talk] antirez의 오픈소스 소프트웨어에 대한 몇 가지 생각..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

요즘 가장 활발하다고 생각하는[해당 글은 2013년 과거 글이기 때문에 해당 글귀는 취소선 표시를 하였다..] 오픈소스 개발자 중 하나인 antirez가 블로그에 A few thoughts about Open Source Software라는 글을 올렸는데 개인적으로 많이 공감을 가서 번역을 해봤다. 오역이 있을 수 있으므로 원문 참고하세요.(antirez의 문장은 약간 어렵;;;) 참고로 anntirez(본명 Salvatore Sanfilippo)는 Redis를 만든 사람입니다.

15년 정도 정기적으로 오픈소스에 공원해왔음에도 여전히 오픈소스에 공헌하는 것이 나에게 어떤 의미가 있는지 계속 생각해 보고 있다. 아마도 오픈소스에 공헌하는 것은 단순히 내가 코드를 작성하는 것을 좋아하기 때문일 것이다. 그리고 이것이 보통 내가 내 시간을 보내는 방법이다. 오픈소스에 공헌하는 의미를 생각하기 보다는 주로 코드를 작성하면서... 하지만 오픈소스와 IT산업과의 관계와 나는 OSS를 무엇이라고 생각하는지에 대해서 계속 생각하기 시작했다.

일단 오픈소스는 나에게 자유소프트웨어 운동에 공헌하는 방법이 아니라 인류에 공헌하는 방법이다. 이는 많은 것을 의미하는데 예를 들어 나는 사람들이 내 코드로 무엇을 하는지 신경쓰지 않고 사람들이 수정사항을 적용해서 다시 배포하는 것도 신경쓰지 않는다. 나는 그냥 사람들이 내 코드를 여러가지로 사용하기를 원할 뿐이다.

특히 사람들이 내 코드로 재미를 느끼고 새로운 것을 배우고 돈을 벌었으면 좋겠다. 내가 작성한 것으로 사람들이 돈을 벌어들이면 내기 무언가를 잃어버리는 것이 아니라 오히려 나에게 이득이 되는 것이다.

1. 누군가 내 코드를 사용해서 비용을 지불할 수 있다면 나는 세계에 더 큰 영향력을 가진다.
2. 내 코드로 돈을 버는 다양한 사람들이 있다면 아마도 그들은 이 돈을 나와 공유하거나 나를 고용하고 싶어할 것이다.
3. 내 스스로가 내 코드(다른 오픈소스 소프트웨어 코드와)로 돈을 버는 사람이 될 수 있다.

이러한 이유로 내가 선택한 라이센스는 BSD 라이센스이고 이는 "원하는 것은 무엇이든지 하라"는 완벽한 구현체이다.

하지만 당연히 모두가 이렇게 생각하는 것은 아니고 오픈소스에 공헌하는 많은 프로그래머들은 다른 사람이 소스코드를 가져가서 동일한 라이센스를 따르지 않고 상업제품을 배포하는 것 같은 사업을 하는 것을 좋아하지 않는다.

나한테는 GPL 라이센스를 사용하기 위해 따라야 하는 많은 규칙들이 오히려 사람들이 소스코드로 할 수 있는 것에 대한 진짜 자유를 줄이는 실제적인 장애물이다. 게다가 나는 라이센스와 많이 관련되지 않은 공헌을 다시 받는다고 느낀다. 유용하다면 포크(fork)를 관리하는 것이 큰 일이 아니므로 사람들은 어떤 방법으로든 다시 공헌하려고 할 것이다. 개발이 이뤄지는 곳이 정말 가치있는 곳이다. 고치지 않고 발전하지 않는 코드는 가치가 전혀 없다. 오픈소스 개발자로써 당신이 가치를 제공할 수 있다면 다른 사람들이 자신들의 변경사항을 더 적용하고 싶어할 것이다.

어쨌든 더 적은 패치를 합치고 사용자관점에서 더 자유로울 때 그 반대인 경우보다 훨씬 더 행복하다. 그러므로 나는 논쟁할게 그리 많지 않다.

내 생각에는 오픈소스가 공정한 양으로 돌려받아야 하는 것은 패치가 아니라 오히려 돈이다. 새로운 스타트업 운동(그리고 저비용으로 운영되는 많은 대형 IT 회사들)은 잘 동작하는 많은 오픈소스 코드에 기반하고 있다. 회사들은 성공의 핵심요소인 오픈소스 소프트웨어를 작성한 사람들과 그들이 번 돈의 일부를 공유하려고 노력해야 하고 돈을 재분재하는 건전한 방법은 이러한 사람들이 오픈소스 소프트웨어를 작성하도록 고용하거나(VMware가 나에게 했듯이) 기부를 하는 것이다.

많은 개발자들은 열정을 가지고 여가시간에 많은 작업을 하고 오픈소스에 대한 이들의 공헌을 적은 부분만 지불된다. 재분배는 사람들이 열정을 가지고 코드를 작성하는데 집중할 수 있게 하고 매달 월급을 받기위해 회사에서 하는 것과 비교해서 경제에 훨씬 더 중요한 영향을 끼칠 수 있게 할 것이다. 그리고 불행히도 pull request에 비용을 지불할 수 없으므로 소스 공헌으로 프로젝트를 돕는 이유는 좋고 건전한 것이기 때문인데 내 생각이 이는 충분치 않다.

이 모든 것을 다른 관점으로 볼 수도 있지만 나는 현재 IT 산업의 많은 가치를 오픈소스 소프트웨어(대부분은 여가시간에 작성하거나 경영자가 허락한다면 업무시간에 하는 여러 일가운데 시간틈을 채울려는 중요한 노력으로 작성한)가 준다고 본다.

내 생각에 이는 경제적으로 차선책인데 수많은 똑똑한 코더들이 자신들이 좋아하고 많은 사람들이 이미 돈을 버는데 사용하고 있을 것을 작성하는데 더 자유로울 수 있다면 이 사람들은 경제적인 상승을 제공할 수 있다.

[DEV]강력한 웹브라우져 프로파일링 :: Browserscope..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

금년도 1월에 Steve Souders의 UA Profiler에 대해서 포스팅을 했었습니다. 이 UA Profiler보다 훨씬 기능이 뛰어난 새 오픈소스 프로젝트인 Browserscope를 공개되었습니다. 현재 UA Profiler에는 해당 프로젝트가 Browserscope로 대체되었음을 표시하고 있습니다. Steve Souders도 팀에 포함되어 있는 것 같이만 Browserscope 프로젝트는 Lindsey Simon가 이끌고 있으며 그의 블로그에서 Browserscope를 발표했습니다.

Browserscope는 UA Profiler를 기반으로 시작되었으며 현재 4가지 카테고리로 브라우져 테스트를 제공하고 있는데 UA Profiler는 Network탭 부분에 포함되었으며 추가로 Acid3, Selectors API, Rich Text부분을 제공하고 있습니다. UA Profiler와 마찬가지로 Browserscope는 브라우저 프로파일링을 위한 커뮤니티 주도 프로젝트로 웹개발자들의 참고자료와 브라우저의 기능추적을 통한 혁신을 촉진시키는 것을 목적으로 하고 있습니다.

페이지 상단에는 Browserscope의 간단한 소개와 상당히 개발자감성의 콘솔창에 최근에 참여된 브라우저 테스트의 로그가 보여지고 있습니다. 상단 메뉴를 누르면 각 카테고리별로 자신의 브라우져를 테스트해 볼 수 있으며 선택적으로 결과를 공유할지는 정할 수 있습니다. "How Does Your Browser Compare?"를 클릭해서 들어가면 전체 테스트를 모두 한꺼번에 실행하고(약 4분이 걸린다고 합니다.) 결과를 공유할 수 있습니다. 개인정보가 빠져나가는 것도 아니고 이런 데이터는 많은 결과가 있을수록 좋기 때문에 왠만하면 참여하는게 좋다고 생각하고 있습니다.

그 아래에는 4개의 카테고리가 탭으로 구분되어 결과를 볼 수 있습니다. 기본적으로 익숙한 브라우저들의 결과가 비교되어서 나타나고 있습니다. 역시 개발자들이 많이 참여하는 이런 사이트에서는 Firefox가 압도적으로 많은 양을 차지하고 있습니다.(개인적으로 개발용 브라우져에 가깝다고도 생각합니다.) 아직 3.5로는 많이 업데이트를 하지 않았는지 3.0이 가장 많은 테스트케이스를 가지고 있습니다.

왼쪽의 셀렉트박스로 All Browser를 선택하면 각 브라우져의 세부버전부터 Blackberry같은 모바일까지 400여종의 브라우저의 테스트 결과를 보여줍니다. 각 브라우져의 기능은 차이도 많고 세세한 부분은 일일이 테스트하기도 쉽지 않은데 테스트가 많이 싸이면 정말 유용하게 도움이 될듯 하고 여러상황에서 근거자료로 사용할 수 있을 듯 합니다.

테스트 결과 표 하단에서는 각 탭의 테스트에 대한 자세한 정보를 볼 수 있는 링크가 제공되고 있고 해당 데이터를 CSV로도 다운로드를 제공하고 있습니다.

현재 Browserscope 프로젝트는 구글코드에서 오픈소스로 진행되고 있습니다. 각 테스트 및 소스에 대해 관심이 있으시면 가보시면 될듯 합니다.

위 버튼을 누르시면 현재 브라우저의 테스트를 실행하고 결과를 공유할 수 있습니다.

My Comment..
2009년 햄의 포스팅이어서.. 지금도 과연 할까..?? 했는데 들어가보니 여전히 진행중이더란.. 그래서 햄의 글을 다시 보고서 해봤는데.. 솔직히 크게 먼가를 느끼고 있지는 않다.. ㅋㅋ.. 아직은 수양이 부족하거나 관심사에서 좀 떨어진 부분이라 그런가 싶기도 하고 말이지.. 머.. 이러면서 쫒아가는거고 따라가는거지.. 괜찮아 괜찮아.. 아! 글구 원래 코멘트는 노랑색으로 썼는데 주황색 계열로 바꿨다.. 모바일에서는 블로그를 잘 안보는데 우연하게 오늘 봐보니 노랑색이 잘 안보이더란.. 링크해서 보면 또 보이고 애매하다.. 그래서 오늘부터 색을 바꿨당.. 이제 강조 또는 색을 입힐 때는 모바일에서도 잘 보이는지 확인하고서 결정해야 될 듯 하다..