주간 뉴스

내 맘대로 월간(月刊) 뉴스 - 2016년 10월

Sangkon Han

• 18 min read

  • library version check

    • 프로젝트에서 사용중인 라이브러리를 편하게 최신버전으로 업그레이드 해주는 방법을 소개하고 있음

  • LINE LIVE 채팅 기능의 기반이 되는 아키텍처

    • WebSocket, Actor Model(Akka), Redis를 사용해서 구성된 아키텍처를 소개하고는 기사
    • 대용량 처리를 위해서 '병렬(Akka)'처리와 'Pub/Sub' 구조는 기본이라 할 수 있는 듯

    서드 파티 라이브러리의 경계 조건(edge case)이라고도 할 수 있는 이슈에 봉착하게 되는 경우가 있습니다. 그럴 경우에는 해당 커뮤니티나 GitHub issue 등을 통해 개발자와 커뮤니케이션하여 수정하거나, workaround 사용이 필요하기도 합니다. 최근의 예로는, Redis Cluster에 node를 추가할 때 여러 서버에서 lettuce의 동작이 불안정해지는 현상이 발견되어 GitHub issue를 등록하여 조치된 사례가 있습니다.

  • 김헌기님의 단상 중(페이스북이라 링크 생략)

    • 측정 불가능한 제품은 애초에 만드는게 아니라고 생각하고 있었기 때문에 많은 공감이 되었음

    1.품질을 측정할 때 정탐,과탐,오탐,미탐이라는 말이 있습니다. 단어만 보면 무슨 말인지는 다들 아실 겁니다. 그중에 제일 나쁜 것이 미탐이라고 들었습니다. 측정하지 못하면 얘기도 꺼내지 못해본다는 의미라고는 하는데 저는 이제 체감해 봅니다.

  • [북 인터뷰] 시간 생산성 종말 선언한 크리스 베일리 "야근은 최악이다. 스스로 최적화된 스케줄을 만들라"

    • 개인의 생산성은 시간, 집중력, 에너지(체력)이라는 세 가지 요소로 결정된다.
    • 오늘날 시간은 더 이상 돈이 아니다. 이제 생산성이 돈이다. 회사가 더 많은 이윤을 남기고 싶다면 직원의 시간보다는 에너지와 주의력을 관리해야 한다”고 말했다.
    • “누구나 일을 미룹니다. ‘결심의 재발견’의 저자 피어스 스틸의 연구에 따르면 약 95%의 사람들이 일을 미룬다는 사실을 인정했습니다. 5%는 거짓말을 한 것으로 보입니다(웃음).
    • 새로운 환경에 적응하는 데는 한 달 이상이 걸립니다. 하지만 흥분제를 끊고 일단 적응하면, 인터넷 외에 수많은 재밌는 일을 찾게 됩니다.”

  • Overview of JavaScript ES6 features (a.k.a ECMAScript 6 and ES2015+)

    • Block scope variables(let) 말고는 뭔 소리인지 잘 모르겠지만, 정적 언어의 장점을 흡수하려고 하는 듯

  • 이커머스의 미래

    • 중간 단계를 축소하면 결론적으로 더 많은 이득을 얻을 수 있다. 너무 당연한 이치 아닌가? 싶은데 V-Commerce이란 새로운 용어로 정의될 정도라면 지금까지 그렇게 하지 못했던 이유가 뭘까?
    • 본인의 브랜드를 온라인에서 고객에게 직접 파는 Direct to Consumer 모델이다. 이런 브랜드는 온라인에서 태어나고 모든 것이 온라인에서 이루어진다. 실리콘벨리에선 DNVB(Digitally Native Vertical Brand)라고 불린다.최근 유니레버에 1조원 exit을 한 Dollar Shave도 같은 분류이다.
    • V-Commerce성공사례로는 Warby Parker, Bonobos, Casper 등이 있다

  • git add -p 와 git commit -v 의 사용]

    • diff와 add를 동시에 할 수 있는 방법을 소개하고 있음
    • 결론적으로 히스토리를 잘 관리해야 한다는 점!

  • 마크다운 문서화 도입기

    • Markdown으로 문서화를 진행할 때 발생하는 몇가지 고민을 엿볼 수 있음

    그리고 개인적으로 마크다운을 쓰는 가장 큰 이유는 자료(data)와 표현(presentation) 부분을 분리 할 수가 있기 때문이다. 예를 들어 마크다운 문서는 하나의 데이터지만, html, pdf, docx 등으로 변환해서 보여줄 수 있고(오픈소스등에 의해서) 그 안에서 css 등과 같은 역할을 하는 것들을 통해서 하나의 데이터 여러가지 표현을 만들어 낼 수 있다.

  • 2017년에 버려질 빅데이터 도구 7가지

    • 결론적으로 말해서 스파크, 파이썬/스칼라, 카프카를 중심으로 고민해두자!

    빅데이터의 상당 부분이 스칼라(Scala)와 파이썬(Python)으로 이동했다. 후자는 성능 저하를 감당할 수 있지만 파이썬 라이브러리가 필요하거나, 파이썬 개발자가 많을 때 적합한다. 물론 통계에 R을 이용할 수도 있다. 그러나 R의 스케일 기능이 미흡하기 때문에 파이썬으로 옮겨야 한다.

  • [번역] 최신 기술 – Event Sourcing 처음 적용하기

    • 보험, 금융과 같이 큰 규모의 프로젝트는 모든 이력을 정확히 추적하고 기록해야하지만, 그렇지 않은 대부분의 어플리케이션과 웹사이트는 현재 상태만 저장해도 충분합니다.
    • 이벤트소싱은 데이터를 어떤 구조로 설계하고 저장하는지에 대한 내용으로 봐야 합니다.
    • 이벤트소싱은 이벤트를 데이터 소스로 간주합니다. 수 십년간 개발자들은 이벤트에 대해서 그다지 중요하게 생각하지 않았습니다. 어쩌면 그런 이유로 이벤트소싱이 주목받지 못했는지도 모릅니다. 이벤트소싱이 딱히 쓸모있지 않다고 생각해도 괜찮습니다. 아직 필요하지 않을 뿐입니다.

  • Sql server 2012 / Event ID 36888 Schannel Error

    • 패치는 조심히 해야 하고, 일단 문제가 생기면 일이 커진다는 점을 여실히 느낄 수 있게 해주는 기사
    • 패치는 항상 스테이징 서버에 먼저 적용한 후에 진행하자!

    sql server 에서 access violation 에러가 발생하여 정기점검때 os/db patch 를 적용하는 것으로 정했으나 (급박하게) 미리 테스트해볼 생각을 하지 못했습니다. 서비스 DB 의 OS, DB engine 패치 작업은 Beta 환경에서 먼저 적용/테스트 한 후 수행하는게 실제 장애 상황을 방지하는 좋은 방법입니다.

  • 견고한 서비스를 만들기 위한 팁

    • 견고한 서비를 만들기 위한 7가지 방법을 소개하고 있음
    • 모니터링과 배포에 관련된 내용은 적극적으로 추천함!

  • Kubernetes을 활용한 분산 부하 테스팅

    • 분산 부한 테스트를 진행했던 과정을 소개하는 기사
    • Try and Error 과정을 잘 소개하고 있기 때문에 분산 테스트를 진행하는 팀은 참고해 볼 것

  • [아재글] 업무, 조직 세분화로 인해 발생하는 문제점은?

    • 조직 세분화시 발생하는 비용에 대해서 자세히 소개하고 있음
    • PM, PL의 경우 해당 조직을 세분화하는 것에 대해서 조금 더 자세히 알아볼 필요가 있음
    • 소프트웨어 개발에 있어서 작업을 세분화하고 분업화할 때 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는 데에 더 많은 시간이 걸린다. 생산라인 접근 방식은 수작업 노동에는 잘 맞을 수 있다. 그러나 지적인 작업에는 형편없이 실패한다.
    • 이 같은 문제점은 사람을 꾸준히 늘리더라도 생산성이 높아지는 것이 아니라 떨어트린다. 소프트웨어 개발회사에서 이 같은 문제점은 일정 수준 규모에서 급격하게 사람을 늘릴 경우 발생할 가능성이 높은 현상으로 판단된다.

  • Why kernel development still uses email

    • 커널 개발자들이 여전히 이메일로 소통하는 이유에 대해서 소개한 기사
    • 도구가 아니라 절차를 중요하게 여기는 그들의 개발방식에 박수를 보내면서 이메일에 대해서 다시금 생각해 보게 됨

    When new developers come in, the first thing they have to do is to learn how the project works. That includes reading the reviews that developers are doing; that is how one learns what developers care about and how to avoid mistakes. With the kernel, those reviews are right there on the mailing list for all to see; with a system like Gerrit, one has to work to seek them out.

  • Elastic Stack 5.0.0 RC1 설치 방법

    • 무작정 따라하면 설치 됩니다!

  • [서우석의 O2O 비즈니스] O2O 스타트업의 성공조건

    • 읽어보면 참 좋은데,이렇게 만드는게 하늘의 별따가라는 걸 충분히 알 수 있는 기사

    스타트업의 진정한 미학은 바로 이런 상황에서 기존의 문화를 유지하면서 동시에 전문성도 보강하는 그 과정에 있다고 보는데, 누구나 생각하지만 쉽게 되지는 않는것 같다. 그래서 초기 멤버들이 회사와 계속해서 성장하고 커미트먼트를 유지할 수 있는 방법에 대해서 고민해 봤다.

  • 간단하게 해주세요

    • 단순하게 쵝오라고 하는데, 그 쵝오를 만들려먼 누군가를 갈아넣어야 된다는 점을 다시금 상기해 볼 수 있는 기회

  • Gradle Dependency 분리하기

    • Gradle 에서 라이브러리들를 분리하는 작업을 소개하고 있음

  • [번역] Go에서 애플리케이션 설계하기

    • 여전히 가깝고 멀기만한 당신인 'Go' 애플리케이션 설계에 대한 기사
    • 라이브러리 주도 개발 (Library driven development)이란 신세계를 알려줌

    “설정보다는 컨벤션”이라는게 그들의 모토였다. 그러나 Go는 그 어떤 프로젝트 구조나 애플리케이션 설계방식을 규정짓고 있지 않으며 Go의 컨벤션은 대개 제각각이다.

  • 박상혁님 글 중에서(페이스북이라 링크 생략)

    • 일단 잘못을 자신의 방향으로 돌리는 습관은 성공의 필수적이고, 자신이 왜 그런 잘못된 판단을 했는지 알아보는게 우선인건 확실한 것 같다.
    • 그런데 사람을 채용하는 문제는 너무 많은 자잘한 뭔가가 있어서 딱히 말하기 쉽지 않다. 그 '자잘함'이 채용과정에서 작용하기 시작하면 답이 없다.
    • 인재를 키우면서 성장해야 한다는 점이 스타트업의 큰 부담감이 되기도 하지만 동시에 큰 '재미'가 되지 않겠는가?

    회사의 대표는 일을 하는데 있어 역량이 떨어진다고 생각되는 사람은 뽑지 말아야하고, 뽑았으면 직원의 역량을 키울 수 있도록 방법을 마련해야 한다.
    일 못한다고 타박하는 건 결국 대표의 역량 부족이다.

  • 김영재님 글 중에서(페이스북이라 링크 생략)

    • CQRS에 관련된 글인데, 영재님의 글을 통해서 CQRS에 대해서 조금은 추상적인 개념을 머리속에 그려볼 수 있게 되었음

    CQRS 단점 또는 주의사항. 1. ReadModel을 한 번 잘못 만들면 수정도 못하고 레코드 처음부터 완전히 다시 실행해야 한다., 2. 만들다보면 ReadModel에 CRUD를 구현하고 싶은 욕망이 든다. 데이터베이스에 확실히 "Read"라고 박아줘야겠다., 3. ReadModel을 이용해서 2차 ReadModel을 만들면 1의 문제가 발생시 더 큰 와장창이다. 그러니 ReadModel은 수평적/독립적으로 만들어야겠다., 4. 하지만 3의 문제 때문에 이미 이용할 수 있는 ReadModel이 있더라도 ReadModel을 모두 별개로 구성, 별개의 job으로 실행하면 읽히는 쪽에서 난데없는 부하가 걸릴 수 있다.

  • JavaScript는 잘못이 없다. 정말로.

    • JS의 잘못이 아니라 Front-End가 '미칠 것'같이 난해 한 것 뿐

    태초에 디자인이 잘못되어 모호한 this, 난해한 scope, private의 미지원 등 언어 자체가 엉성한 부분들이 많다는 것이다. 하지만 JavaScript가 세상에 나온지 벌써 20년이 훌쩍 지났다. 무기징역급 중죄의 공소 시효도 15년인 마당에, 범죄도 아니고, 심지어 태어날 때 부터 가지고 있었던 결함 때문에 20년동안 같은 비난을 받는 것은 너무하지 않은가? 누구나 공공연히 알고 있는 문제는 보통 잘못이라기 보단 특징이라고 여겨지기 마련이다. 게다가 ES6부터는 그런 결함들을 고치기 위한 기능들이 많이 추가되고 있다.

  • atom editor packages

    • ATOM에서 추천하는 패키지라면 다른 곳에서도 충분히 '필수'적 일 수 있음

  • 츠타야 서점이 말하는 '진짜 기획'

    • 기획에 대해서 조금 다른 시각을 가질 수 있음
    • 최소한 우리(?)가 알고 있는 그 기획은 아님

    빠르게 변화하는 소비자들의 니즈에 맞춰 기존의 생산자 관점과 구조를 바꿀 수 있는 것. 그게 바로 마스다가 생각하는 '기획'

  • Vim 사용자 정의 파일 타입 꾸미기

    • Vim 에디터 관련인데, Emacs는 이런 글 없나?!

  • 3초 만에 눈길 잡고 全 세계인 신발 벗기는 마케팅

    • 창의적인 마켓팅 방법을 소개하는 기사

  • Maven Wrapper 소개와 사용

    • Maven 설치 없이 빌드를 할 수 있는 방법을 소개하는 기사

  • [번역] 비동기 파이썬

    • 비동기 관련해서 아주 훌륭한 가이드를 제공
    • 파이썬이 아니더라도 다른 언어에서 충분히 사용할 수 있기 때문에 시간이 된다면 꼭 읽어보세욤!

  • CSS TOP 10

    • CSS 관련해서 어마어마한 작품을 볼 수 있음

  • 양파님의 글 중에서(페이스북이라 링크 생략)

    프로젝트 매니저는 여자 아홉명이 한 달만에 아이를 낳을 수 있다는 사람이다. 
개발자는 애 낳는데 18개월이 걸린다는 사람이다.
온사이트 코디네이터는 여자 한 명이 한 달만에 애를 아홉명 낳을 수 있다는 사람이다. 
고객은 자기가 왜 애를 원하는지 모르는 사람이다. 
마케팅 매니저는 인간 여자 남자가 없어도 자기가 애를 생산할 수 있다는 사람이다. 
리소스 최적화 팀은 인간 여자 남자 그 외 아무 재료 없이 애를 생산할 수 있다는 팀이다. 
문서화 팀은 애가 나오던지 말던지 9개월동안의 과정을 문서화 하면 된다는 팀이다. 
품질 감사자는 애 낳는 프로세스가 맘에 드는 게 하나도 없는 사람이다. 
테스터는 내가 원한 애는 얘가 아니라고 부인에게 늘 말하는 사람이다. 
인사과장은 당나귀라도 어쨌든 9개월 시간만 주면 인간 아이를 낳을 수 있다고 믿는 사람이다.

Project Manager is a person who thinks nine women can deliver a baby in one month.
Developer is a person who thinks it will take 18 months to deliver a baby.
Onsite Coordinator is one who thinks single woman can deliver nine babies in one month.
Client is the one who doesn’t know why he wants a baby.
Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.
Resource Optimization Team thinks they don’t need a man or woman; they’ll produce a child with zero resources.
Documentation Team thinks they don’t care whether the child is delivered, they’ll just document nine months.
Quality Auditor is the person who is never happy with the process to produce a baby.
Tester is a person who always tells his wife that this is not the right baby.
HR Manager is a person who believes a donkey can deliver a human baby if given nine months.

----

예전에 번역해서 올렸던게 눈에 띄어서.
댓글 중에:
"기획자는 임신 중에 아이 성별을 바꾸고 싶다는 사람입니다" 가 있었음.


* [CJ대한통운 브랜드경험디자인 프로젝트 / CJ 대한통운 Brand eXperience Design Renewal / 플러스엑스 / plusx](http://blog.naver.com/PostView.nhn?blogId=shindesign77&logNo=220827664977&redirect=Dlog&widgetTypeCall=true)
  * 브랜드 디자인이 어떤 건지 한 눈에 알 수 있는 기사

* [모바일 UI 디자인시 고려해야 할 가이드라인 모음 1](https://brunch.co.kr/@chulhochoiucj0/8)
  * 프린트해서 책상 앞에 붙여두자!
  
* [“개발 커뮤니티에서 느낀 스타트업과 개발자의 거리”](https://medium.com/@baejinho/%EA%B0%9C%EB%B0%9C-%EC%BB%A4%EB%AE%A4%EB%8B%88%ED%8B%B0%EC%97%90%EC%84%9C-%EB%8A%90%EB%82%80-%EC%8A%A4%ED%83%80%ED%8A%B8%EC%97%85%EA%B3%BC-%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%9D%98-%EA%B1%B0%EB%A6%AC-5fd8fed4c482#.ih8bvolf6)
  * 스트타업의 개발자라의 필수덕목은 성장력이다. 그러기 위해선 일단 '코딩'은 되야 한다. 이것도 저것도 안되면 성장은 고사하고 전체가 몰살(한명 살리자고 팀 전체가)하는 경우를 보게 될 것이기 때문
  > * 1가지를 아주 잘하는 사람이라고 해도, 평소 즐겨하지 않는 언어 때문에 한가지를 잘하는 사람마저 잃을 수 있습니다.
  > * 그러면, css나 html 그리고 js, node 까지는 잘 다룰 수 있을지도 모릅니다. 또한,엥귤러와 같은 프레임워크를 쓰기도 할 것입니다. 하지만 그렇다고 해서, 그것이 어떤 트래픽의 과부하를 견뎌낼 정도로 서버단 서비스를 잘 운영해본 것을 의미하는 것은 아닙니다. (서버 프로그래머로 보기에는 단정 짓기 모호한 부분이 생깁니다.) 즉, 어떤 개발자를 바라 볼 때, 그 개발자의 입장을 고려한다면 모든걸 다 잘하기 위해서는 많은 시간이 필요하다는걸 염두하셔야 합니다.
  > * 개발자들의 위치란 천차 만별이고, 초보 개발자의 경우에는 여타 다른 시스템을 경험해 보지못했기 때문에 배워야 할 것이 많습니다. 그런상황에서 요구사항이 늘어나고, 그것을 감당할수 없게 되면, 결국 떠나게 될 것입니다.