[GN#6] 아마존은 어떻게 소프트웨어를 개발하는가

2019-08-12 ~ 2019-08-18 사이의 주요 뉴스들
개발조직을 운영하는 것은 여전히 매우 어렵고, 회사마다 달라서 어떤것이 정답이라고 할 수가 없습니다. 종종 얘기되는 아마존의 개발방식을 알아보는 글을 추천합니다.

또한 안 좋다고만 얘기하는 기술부채에 대한 다른 관점을 정리한 "좋은 기술 부채 3가지" 글도 추천합니다.

매주 월요일 아침, 지난 일주일간의 GeekNews 중 엄선한 뉴스들을 이메일로 보내드립니다.


아마존은 어떻게 소프트웨어를 개발하는가

분해,자동화,고객중심 구성.
"팀은 서비스를 완전히 소유하는 작은 팀으로 나눠집니다. EC2도 2피자 팀으로 시작했습니다"

 
"좋은" 기술 부채 3가지

기술 부채는 대부분 안좋다고 얘기됨
돈빌려서 집을 사면 축하해주는데, 왜 기술은 안그럴까 ?
중요한 차이점은 "빚을 진 의도가 무엇인가?" 임

글에서 얘기한 세가지 좋은 기술 부채들
- Scaffolding
- Hardcoding Things
- Not Fixing All the Edge Cases

중요한건 "Good Tech Debt is Intentional"

빠르게 성장하고, 비용과 시간을 절약하기 위해 의도를 가지고 부채를 지는것은 괜찮다.
그 기술부채의 한계를 잘 알고 잘 정리해서 나중에 개선할수 있게 하자.

왜 기술 "부채" 냐면, 어차피 빚을 진 거고, 빚은 이자가 붙어 늘어나기 마련
그 빚으로 얻게 되는 이득보다 빚이 많아지기 전에 잘 알고 빚을 갚아야 한다는 것

하지만 이자가 붙어서 통보가 날아오는 은행 대출과 달리,
기술 부채는 그게 눈에 보이지 않기 때문에 다들 까먹게 되는 것

빚이 불어나기 전에 갚읍시다.

 
좋은 git commit 메시지를 위한 영어 사전

"실제로 프로젝트에서 사용되는 커밋 메시지는 간단하기 그지 없습니다. 문법도 중학 영어 수준이고, 어려운 단어 역시 사용되지 않습니다. 결국 커밋 로그 메시지의 작성은 작문이 아니라 패턴으로 접근해야 합니다. 자신의 커밋이 가진 특징을 패턴에 대입시켜 단어들을 뽑아내는 것이죠. 작문의 결과로 보면 너무 단순해서 부족해 보일지 몰라도, 여러 사람들에게 쉽게 읽히고 쉽게 이해되도록 하기에는 패턴화된 단순한 문장이 훨씬 낫습니다.

그럼에도 불구하고 커밋 메시지를 쉽게 쓰는 것은 어렵습니다. 첫째, 한 문장으로 설명이 가능하도록 작업을 쪼개어 커밋하는 것 자체가 쉽지 않습니다. 둘째, 작성한 당사자가 아닌 처음 보는 제3자가 이해할 수 있는 문장을 만들어야 합니다. commit -m을 입력한 후, 메시지 입력창이 나타나면 눈을 감고 크게 한숨을 내쉬면서 작업한 내용을 돌아보세요. 그리고 최선의 한 단어를 선택해보세요."

 
판교사투리에 대해 알아보자

스타트업에 취업하고픈 사람들을 위한 지역사투리 정리.
아는 사람들에겐 유머, 모르는 사람들에겐 정보.

 
Atlassian 이 사내 PaaS를 이용하여 직원들의 AWS 억세스를 관리하는 이유

Micros 라는 PaaS를 통해 1000개가 넘는 서비스들이 호스팅중.
해커톤에서 만든 코드부터, 실제 플래그십 제품까지 모두 포함.

굉장히 중요한 서비스지만, 실제로는 간단히 구성됨.
- Docker 이미지 : 서비스 로직
- 서비스 설명을 담은 YAML
== DB,큐,캐쉬 등 필요로 하는 리소스 정의
== 오토스케일링 특성 같은 다양한 설정들

나머지 모든 일들은 Micros 에서 처리
= Log Aggregation , Monitoring , Alert
= 멀티 AZ, 백업/리스토어/리텐션 설정 등

개발한 부분이 많지는 않고 대부분 AWS 의 기능을 이용함.

** 이렇게 PaaS 를 구성하는 이유

- 사내 표준 도구 및 프로세스와의 통합하는게 개발을 쉽게함
- 서비스들에 폭넓게 적용되어야할 변경들이 단순화 되고 예측할수 있게 됨
- 소수 엔지니어의 전문기술들이 몇배로 증대됨(multiplied)
( 사내에 PostgreSQL 전문가는 얼마 없지만, Micros 에만 적용하면 회사 전체가 이득 )
- 플랫폼을 개선하는 작은 시도들도 회사 전체에 영향을 미치게 됨
- AWS의 새로운 피쳐들도 점진적으로 기존의 보안이나 규정을 지켜가며 추가됨.

물론 이 방식이 다 좋은것은 아니고, 새로운 AWS 기능을 실험하기 힘들기도 하고, 다른 3rd 파티 도구들이 Micros 와 연계가 안될경우도 있음. 그래서 내부적으로 PaaS 의 기능 추가하는 프로세스를 만들어놨음.

이 PaaS 는 내부 엔지니어와 AWS 사이를 가로막는 장벽이 아니라, AWS 의 인프라를 더 많이 보여주도록 하고 있음. 계속 발전 시켜 나갈것임

글이 굉장히 길어서 몇 부분만 발췌해서 적었습니다.
조금 큰 조직에서 AWS 를 운영하고 있다면 천천히 읽어보시길 권해드립니다.

예전에 KTH , Daum 도 이와 비슷하게 내부클라우드(오픈스택이었던걸로 기억)를 구성해서 썼던것으로 아는데
이렇게 얇게 AWS 위에 덧씌우는 방법도 좋은 것 같네요.

 
Webkit Tracking Prevention Policy (추적 방지 정책) 발표

트래킹이 뭔지에 대한 정의부터 어떤 트래킹을 방지하는지, 기능제한이나 사전 사용자 동의가 이뤄졌을때의 내용, 이렇게 차단됨으로써 발생하는 일들을 웹킷이 어떻게 대응하는지 등을 정의.

기본적으로 숨겨진 모든 트래킹과 크로스 사이트 트래킹을 방지.

Mozilla 의 Anti tracking policy 에서 영감을 얻었다고
https://wiki.mozilla.org/Security/Anti_tracking_policy

 
Programmer's Music - 코딩중에 집중력/생산성을 높이기 위한 논보컬 음악 큐레이션

20개 이상의 장르, 장르당 46시간 이상의 음악들.
뽀모도로 기법을 적용해서 스트레치 & 휴식시간 알림 기능.
장르 선택해서 감상가능. 광고 및 기타 방해가 되는것 없음.

 
Data : 과거, 현재, 그리고 미래

데이터에 대한 역사부터 요즘의 데이터 활용 사례까지를 얘기하는 수업자료.

Syllabus 에 수업자료 PDF를 포함해서 관련해서 읽을 수많은 링크들이 있음.

https://github.com/data-ppf/data-ppf.github.io/wiki/Syllabus

 
GitHub 별이 돈을 벌어주지 않는다

계속하려면 돈이 중요하다.

결론
1-자신의 문제를 풀어라
2-빨리 남에게 보여줘라
3-빨리 배포해라
4-돈받는걸 두려워하거나,챙피해하지마라
5-니 작업의 가격을 매기는데 남의 의견을 듣지마라

글 마지막에 유명한 문구 라고 적힌.. (테일러 스위프트의 노래죠.)

'Cause the players gonna play, play, play, play, play
And the haters gonna hate, hate, hate, hate, hate
Baby, I'm just gonna shake, shake, shake, shake, shake
I shake it off, I shake it off'

뭔가를 만들면 욕하는 사람은 나오기 마련이고, 신경쓰지 말고 가는게 중요.

 
iOS와 Android 간에 코드를 공유하는데 드는 비용

Dropbox 는 2013년 시작할때 양플랫폼간에 공유하기 위해 C++을 사용.
그때는 팀이 작았고, 빠르게 성장하는 모바일 로드맵을 지원하기 위해서 였음.
현재는 Swift 와 Kotlin 을 이용하는것으로 바꿨고, 이것은 코드 공유를 위해 드는 아래와 같은 숨겨진 비용 때문임 ( 사실 별로 숨겨지지도 않음 )

- 커스텀 프레임워크와 라이브러리에 따른 오버헤드
- 커스텀 개발 환경의 오버헤드
- 플랫폼간의 차이점을 처리하는데 따른 오버헤드
- 개발자를 교육하고 채용하고 유지하는데 드는 오버헤드

결론적으로 한개의 코드로 쓰는건 좋아보이지만, 오버헤드가 크다는거
이 글의 마지막 패러그래프는 "Android / iOS 개발자 뽑아요!" 인게 중요

글이 긴데, 사실 Dropbox 는 특이하게 C++ 을 써서 그런거고
작은 조직에서는 한개의 코드로 멀티 플랫폼을 지원하는거가 솔직히 초반에 땡기는게 사실.

10년전에는 HTML5과 Phonegap 을 이용한 Hybrid 개발이 그랬고,
요즘은 React Native 와 Flutter 같은 것이 나와서 한번에 여러 플랫폼 지원이 가능하다는걸로 모두를 유혹하고 있음

내 생각은, 작은 조직에서는 위와 같은 방식으로 코드쉐어 하는게 장점이 분명히 있음.
다만 프로덕트가 성장함에 따라 이건 다시 기술부채가 되어감.
사용자가 늘고, 조직이 크고, 개발자가 더 늘어나면 Web/iOS/Android 모두 그에 맞는 기술로 발전하는게 최종 모습이 되는 것이라고 생각함.

https://news.hada.io/topic?id=309 에 있는 좋은 기술 부채에 대한 글에서 처럼
의도를 가지고 기술 부채를 만드는게 중요. 이자가 불어나기 전에 빚을 갚읍시다.

조직에서 감당할 수 있는 오버헤드냐 아닐까요
뭘 선택도 감당할 수 있다면 가장 잘 할수 있는것에 집중하는 게 맞을 것 같아요
어차피 플랫폼마다 다른건 어쩔수 없는거 같아요. 하이브리드로 만들어도 차이점이 사라지지는 않더군요

 
점점 더 선명해지는 쿠팡의 시대

핵심은 쿠팡이 얼마나 사람들의 일상과 습관을 길들이고 있는가가 아닐까 싶다. 쿠팡은 그걸 해내고 있는 것으로 보인다. 그런 부분에서 10대와 50대 이상에서 폭발적으로 사용자가 증가한 쿠팡의 모습은 의미가 있는 것 같다.

 
‘넵’병은 실재했다.

우리는 왜 ‘넵’을 쓰는가. 아직 뚜렷한 치료법이 발견되지 않은 ‘넵’병에 대해 알아보자.

참고사항 2가 킬링포인트 인듯.

넵넵!

 
구글의 "웹사이트 빠르게 만들기" 가이드

이미지/자바스크립트/CSS/써드파티 JS코드/웹폰트/네트웍 최적화 방법과 성능측정하기.

기존에 공개된 가이드에 써드파티 JS 관련 글이 3개 추가됨
- Third-party JavaScript performance
- Identify slow third-party JavaScript
- Efficiently load third-party JavaScript

 
빠르고 최적화된 Javascript 를 작성하는 13가지 팁

필요없는 코드와 단계 제거하고, 루핑횟수와 계산을 줄이고, 빌트인 메소드를 잘 이용하고, 하고자 하는 작업에 알맞는 객체를 사용하고, Async 와 코드분할하기.

아마존은 100ms의 지연이 1%매출을 감소시킨다고 했고, 구글은 검색페이지 보여주는데 500ms 시간이 늘면 20% 트래픽이 감소한다고 했음.