[NEWS] 14-01-15 기술 뉴스..

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

올해는 좀 더 새로운 시도를 해보려고 생각하고 있었는데 뭘할까 생각하다가 그나마 내가 많이하는 것 중 하나가 인터넷에서 많은 뉴스나 링크들을 찾아보는 걸 오랫동안 했기 때문에 이런걸 어떤 뉴스레터식으로 제공할 수 있지 않을까 생각했다. 사실 내가 관심가기거나 보는 것들은 대부분 트위터를 통해서 공유하고 있기는 하지만 SNS 특성상 계속 보는 사람이 아니면 확인하기가 어렵고 놓칠 가능성도 높은 문제가 있다. 그래서 링크를 찾아보거나 뉴스들을 보는 건 일상이니까 모아놓으면 어떨까 하는 생각을 하게 되었다.

어찌 보면 이건 약간 실험의 일정이기도 하다.(실험이라는 의미는 해보다 아니다 싶으면 안할지도 모른다는거...) 이렇게 모아놓으면 과연 유용할까하는... 예전에 xguru님의 기술뉴스도 잘 보았고 난하님의 Read Trend같은 형태도 있는데 나는 어떤 형태가 좋을지는 사실 맘을 정하지 못했다. 이런 저런 서비스들을 테스트해봤지만 그다지 맘에 드는 형태는 없어서 그냥 작성하기 편한 포맷을 그대로 이용했다. 따로 편집하는건 공수가 너무 들어서...

링크도 보고 쌓기만 하다가 정리를 좀 해보려니까 생각보다는 좀 만만치 않고(카테고라이징도 계속 고민 중) 첫 모음도 사실 해놓고 보니 만족스럽지는 않은데 하다보면 차차 자리를 좀 잡아가지 않을까 기대하고 있다. 기술뉴스라고는 하지만 지극히 내 관심사에 모은 소식들이고 그렇다 보니 어떤 링크들은 최신이 아닌데 내가 최근에 본 소식들도 있을 수 있다. 지금 생각으로는 한달에 2번을 생각하고 있는데 어떻게 될지는 나도 잘...

웹

• React Chrome Developer Tools : 페이스북의 자바스크립트 라이브러리인 React의 코드를 디버깅할 수 있는 크롬 익스텐션. (영문)
• Switchery : 체크박스를 iOS 7 스타일로 꾸밀 수 있는 자바스크립트 라이브러리. (영문)
• Web Developer Checklist : 웹사이트를 만들 때 웹개발자가 점검해 봐야 할 목록과 그에 대한 관련 서비스가 잘 정리되어 있다.(영문)
• JavaScript Promise 외 튜토리얼 4종 라이브 소식 : 도창욱님이 HTML5 Rocks의 내용을 번역해서 제공하는 블로그로 최근에 추가된 자바스크립트 네이티브 Promise 등의 내용이 추가되었다. 그리고 해당 블로그에 최근 크롬 개발자 서밋에 대한 내용도 추가되었다.
  

프로그래밍

• Node.js: Why did Koding switch from Node.js to Go? : Koding이 왜 Node.js에서 Go로 갈아탔는가에 대한 질문에 Koding CEO가 직접 대답한 내용으로 코드가 많아졌을때 관리가 어렵고 프로파일링이 쉽지 않고 콜백헬의 어려움 등을 이유로 들었다. (영문)
• Web Developers: What should you be learning in 2014? : 2014년에 웹개발자가 어떤 기술을 배워야 하는가를 취업관련 사이트(영국쪽 기반)의 내용을 기반으로 분석한 글 (영문)
• IntelliJ IDEA Minimal Survival Guide : Jetbrain의 Intellij IDEA의 사용가이드를 정리한 내용으로 제목은 Minimal 가이드이지만 아주 자세하게 정리가 되어 있다. (영문)
• Introducing GitHub Traffic Analytics : Github에서 저장소 페이지의 방문 트래픽을 통계로 보여주는 기능을 추가했다. (영문)
  

읽을 만한 글

• 집에서 일하기 : 유칼립투스에서 일하는 박상민님이 자신의 경험에 기반해서 원격근무에 대해서 적은 글로 원격근무에 관심이 많다면 읽어볼 만하다.
• Flat Design vs. Realism : inTacto라는 회사에서 플랫 디자인과 리얼리즘 디자인에 대한 인포그래픽인데 아주 인터렉티브하게 잘 만들어져서 내용보다 인포그래픽 자체가 볼만하다. (영문)
• 일간워스트 개장기 : rainygirl님이 일간워스트를 만드는 과정을 자세하게 공유한 글로 여러가지 이슈들에 대해서 어떻게 대응하고 발전했는지를 재미있게 읽을 수 있다
• Introducing Jelly : 트위터의 공동창업자인 비즈 스톤이 Jelly라는 Q&A 서비스를 오픈함.(영문)
• The Year in Kickstarter 2013 : 킥스타터가 2013년에 어떤 일을 겪었는지 보여주는 프리젠테이션으로 2013년의 펀딩 금액 및 사용자에 대한 통계와 대표 프로젝트가 나와있다. (영문)
• OP.GG 오픈부터의 1년을 되돌아보며 : [LoL](League of Legends) 전적검색 사이트인 OP.GG를 오픈하고 1년간의 과정을 정리한 글로 서비스를 어떻게 개선하고 장애에 대응했는지가 잘 정리되어 있어서 LoL을 안하더라도 읽어볼만하다.
• Outage post-mortem : 드랍박스가 지난 10일 장애를 겪은 후 정리한 포스트모템이다. OS 업그래이드 작업을 진행하던 중 해당 서버가 엑티브인지 검사하는 스크립트의 버그로 서버가 엑티브상태인데 업그래이드가 일부 진행되면서 디비의 마스터-슬레이브 연동에 문제가 생겨서 장애가 발생했다고 한다. 파일을 저장하는 서버는 아니라서 파일 손상은 없었다고... (영문)
• Google to Acquire Nest : 구글이 아이팟의 아버지인 토니 파델이 만든 Nest를 32억달러에 인수했다. Nest는 온도조절장치와 화재경보장치 등을 만드는 회사다. (영문)
• Stackoverflow.com 의 아키텍처 : 작년 Developer Conference 2013에서 스택오버플로우의 아키텍쳐에 대해서 발표된 내용이 정리된 글로 스택오버플로우가 서버 및 플랫폼이 어떤 규모로 운영되고 있는지 알 수 있다.
  

프로젝트

• CocoaSPDY : 트위터가 공개한 iOS, OS X에서 사용할 수 있는 SPDY 클라이언트 라이브러리.
• iSPDY : Voxer가 공개한 iOS, OS X에서 사용할 수 있는 SPDY 클라이언트 라이브러리
• hpack : 트위터가 공개한 HTTP 2.0 헤더압축에 대한 자바 라이브러리.
• AngularFire : 리얼타임 데이터 백앤드 서비스인 Firebase를 AngularJS에서 쉽게 사용할 수 있도록 만든 Angular 바인딩

My Comment..
항상 햄의 포스팅을 가져올 때는 고민을 살짝 하는데 이번 글은 조금 더 고민을 했다.. 다른 이유보단 구태여 과거 뉴스를 왜..?? 라는 부분 때문인데.. 

나 스스로 햄의 글들을 가져올 때 과거의 글을 떠나서 저런 부분이 있었구나.. 저렇게 정리를 했구나 하는 것 때문에 가져오는 것도 있지만, 해당 글처럼 기술 동향을 정리해둔 뉴스 포스팅은 비록 과거글이라고 할지라도 난 부끄럽게도.. 그 마저도 몰랐기에..

저 시점에는.. 이 글로 따지면 2014년에는 저런 기술과 뉴스가 이슈를 이루고 있었구나.. 하면서 어찌보면 과거를 답습..?? 하는 관점에서 고미을 하다가 글을 가져왔다.. 지금도 그렇지만 햄의 글을 과거부터 읽어가면서 몰랐던 기술, 언어, 오류, 뉴스, 생각 등등.. 많이 알아가고 있다..

점차적으로 현실에 가까워지고 있기도 하고 말이지.. 

[Talk] 보안이 정말 그렇게 중요한가..

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

개개인이 가진 보안의 적정수준이란 건 당연히 다르기 마련이고 상황이나 입장에 따라 달라지게 마련이지만 평소 주위에 만연해 있는 보안에 대한 인식은 너무 과도하다고 생각한다.

큰 의미에서 보안이란 것은 대부분 어떤 가치 있는 무언가를 허가받지 않은 사람이 이용하지 못하도록 막는 것인데 내가 가진 보안에 대한 입장은 이용을 편하게 할 수 있는 수준을 보장한 뒤에 보안을 논해야 한다고 본다. 왜냐하면, 원래의 목적은 그 무언가를 이용하는 것이 1차적인 목적이고 그에 대한 부작용으로 허가받지 않은 사람이 사용하게 돼서 생기는 문제를 막기 위해 보안이 추가된 것이기 때문이다. 하지만 현실은 보안이 너무 과도해져서 이용 자체를 크게 저해하고 있다. 마치 이용을 막는 게 1차 목표인 것처럼...(물론 어디는 보안이 너무 과도하고 어딘가는 보안이 너무 빈약한 문제는 있다.)

예를 들어 보면 나는 집에 들어갈 때 우리 집 현관문에 달린 자물쇠를 열고 들어간다. 자물쇠는 2개가 달렸지만 보통 1개만 사용하고 장기간 비울 때만 2개를 사용한다. 다른 집도 비슷할 거라고 생각하는데 여태 살면서 가정집에 자물쇠 3개 이상 달린 집은 본 적이 없다. 만약 자물쇠가 종류별로 다른 인증체계를 가지고 자물쇠가 10개쯤 달려있다면 하나만 사용하는 것보다 당연히 더 안전할 것이다. 하지만 그렇게 하지 않는 이유는 현관문을 하루에도 수십 번씩 열어야 하기 때문이다. 지문인식부터 시작해서 열쇠를 다발로 가지고 다니면서 현관문을 오갈 때마다 일일이 십여 개씩 열고 다닌다면 보통 제정신이 아니라고 생각할 것이다. 영화에서 편집증에 걸린 사람이 이렇게 하는 거 외에는 실생활에서는 본 적이 없다. 현관문은 아니더라도 창문 등을 통해서 집에 들어오는 방법도 있다. 만약에 나갈 때 버튼 하나만 누르면 쇠로 된 셔터가 내려와서 모든 창문을 막아버리면 당연히 더 안전할 것이다. 마찬가지로 그렇게 하는 사람은 없다. 여기에는 비용문제도 있고 현관문과 마찬가지로 매일 사용해야 하므로 이런 짓거리는 하지 않는다.

좀 과해 보이는 예시일 수도 있지만 내가 느끼기에는 IT에서 이러한 일은 빈번하게 일어난다. 보안은 중요하다는 명목하에서...

앞의 예제를 다시 보면 가장 쉬운 보안해결책은 집에 값진 물건을 두지 않는 것이다. 값진 물건을 두지 않으면(그래서 은행 같은 게 있는 거지...) 설사 보안체계가 뚫리더라도 위험이 크지 않다. 하지만 값진 물건이 있을 수밖에 없긴 한데 그렇다면 이 값진 물건에만 별도의 보안을 추가하면 된다. 당연히 생각해도 온 집안에 물건이 다 중요하진 않을 테니 절대 잃어버리면 안 되는 것만 별도의 금고에 넣거나 하면 된다. 이럴 때는 별도의 인증과정이 들어가도 아무도 불만을 품지 않는다. 번거로운 인증과정을 거칠 정도로 그 안에 들어 있는 것이 중요하기 때문이다. 그리고 이 부분은 이용성에도 문제가 되지 않는다. 내가 냉장고를 열고 물통을 꺼내는 횟수랑 금고에서 황금 송아지를 꺼내볼(우리 집에 그런 건 없다.) 횟수는 당연히 다를 수밖에 없다. 그러므로 물통을 꺼낼 때는 추가로 인증과정을 거치지 않지만 황금 송아지를 꺼낼 때는 추가로 인증과정을 요구해도 크게 문제가 되지 않는다.

하지만 IT 환경을 보면 보안이라는 이유로 너무 많은 걸 보안영역 안에 넣어버린다. 그래서 원래는 이용하는 게 목적이었는데 너무 불편하므로 꼭 필요한 상황이 아니면 이용하지 않으려고 하게 된다. 내가 느끼기에 이 중에 80% 정도는 물통에서 물을 먹기 위해서 냉장고에 자물쇠가 걸려있는 꼴이다. 혹시 냉장고에 들어있는 물통이 나중에 값지게 될지도 모를 일이므로... 심지어 일해서 수익을 내는 회사에서도 이런 역전현상이 수시로 발생한다는데 당혹감을 감출 수 없는데 수많은 개발방법론을 도입해서 생산성을 조금이라고 올리는 것보다 보안을 조금 낮추는 게 훨씬 더 생산성을 높일 수 있을 거라고 본다.

왜 이런 일이 발생했는지는 나도 알 수 없다. 하지만 간단한 애플리케이션을 너무 과도하게 설계에서 성능이 제대로 나오지 않는다면 개발자가 해결해야 할 이슈이듯이 보안 때문에 생산성이 떨어진다면 이를 해결해야 하는 건 보안 쪽이다. 그리고 이런 무리한 요구도 아니고 이미 보안도 어느 정도 지키면서 생산성도 유지할 수 있는 기술은 충분히 개발되었다고 본다.

덧) 물론 이런 얘기를 하면 나중에 보안 문제로 재판 갔을 때 회사가 얼마나 보안에 대해 노력했느냐 하는 부분이 중요하다느니 어쩌느니 하는 얘기가 나오는데 재판을 안 가봐서 그런지 몰라도 별로 동의는 되지 않는다. 그거 해결하기 위해서 보안전문가가 있는 거 아닌가? 내가 개발을 더 쉽고 잘하기 위해서 원래 만들려던 서비스의 목적을 잃어버리고 야크 털만 깎고 있으면 잘했다고 해주나? 개발 열심히 잘했다고? 개발 자체가 목적이 아니라 서비스(혹은 무언가)를 만드는 게 목적이므로 그 중간은 어찌 되었든 내가 알아서 해결하고 결과물이 나와야 하는 거 아닌가?
덧) 왜 개발과 보안이 붙으면 항상 개발 쪽이 지는 걸까....

My Comment..
해당 포스팅을 읽으면서 내 상황과 많이 비교하게 되었다.. 아무래도 금융권쪽에 있다보니 보안이라는 부분과는 악어와 악어새 같은 입장이라고 해야될까.. 업무적인 롤이 되었건 인간관계적인 측면에서건 말이지.. 비교하는 부분이 좀 잘못된 걸수도 있는데 순간 딱 떠오른게 그렇다.. ㅎㅎ..

난 개발이라는 것을 처음 할 때 보안이라는 개념이 없었던 것 같다.. 그냥 아웃풋만 내면 되는거 아닌가..?? 라는 생각을 많이 했는데.. 지내다보니 표준, 취약성, 개인정보 관련 등등 무엇인가 엄청 많더라.. 그런데 그것의 정점을 찍은 것이 현 업무라고 생각한다.. 물론 더 높은 보안 수준도 있겠지만 최소한 내가 경험한 범주에서는 그러하다..

나는 햄의 글과 좀 비슷한 생각이 들기도 하고, 갈팡질팡하기도 한다.. 우선 과거 경험을 얘기해보면, 예전에 우리나라에서 나름 제일 크다고 하는 전산센터에 출장을 간일이 있었다.. 거기서는 보안 이슈 때문에 가방은 물론 호주머니까지 다 검사를 했으며, 담배 안에 무엇이 있는지도 검사했다.. 심지어 라이터는 압수를 했는데 어찌보면 사람이 문제를 일으킨다는 관점에서 물리적인 보안 점검을 그렇게 한다면 이해는 간다 당연히 불편하긴 하지만..

위와 같이 생각을 하면, 보안은 당연히 철저해야된다고 생각이 되기도 한다.. 문제가 생기면 결국 고생하는건 당사자가 되는 것이고 그로인해 문제의 영향도가 어디까지 파생될지 모르니 말이다.. 근데 또 한편으로 SW 개발적인 부분에서 다가서자면 특정 시스템 또는 특정 명령어에 대해서 다 제약을 걸어버리는 경우가 보안의 보편적인 룰일 것이다..

여기서 문제가 개발은 해야되고, 테스트도 해야되고, 오류가 있으면 확인해야될 자료가 있고 그런 것인데 그런 부분이 다 막히거나 특정인에게 요청해서 다시 피드백을 받고 그런 방식을 고수하면서 개발 데드라인은 과거와 똑같다..??? 이런것이 또 하나의 문제라면 문제 같다.. 얘기를 하다보니 이게 참.. 양면 색종이 같다..

보안을 생각하면 최대한 막는 것이 맞지만, 업무의 효율성을 위해서는 풀어주는게 좋고말이지.. 흠..;; 현재 업무하는 곳에서는 이제 어느정도 익숙해지긴 했지만 모든 보안이란 것이 어느 한쪽에 너무 치우쳐서 양극화를 만들어내기보단 그 중간을 유지하는 것이 결론적으로는 제일 좋은 것 같다.. 그 중간.. 중립을 유지하는게 제일 어려운것이 또한 문제긴 한다..

햄이 맨 마지막에 왜 항상 개발쪽이 지는 것일까.. 라고 했는데.. 글쎄 이부분은 현 시점에서는 다 그런건 아닌듯하다.. 머 일하다보면 대부분 지는거 같긴한데.. 그래도 과거와 비교한다면 많이 좋아진 것 아닌가 하는 생각을 살짝해본다.. ㅎㅎㅎ