[GN#44] 온라인 서비스의 가격 결정 하는 법

2020-05-04 ~ 2020-05-10 사이의 주요 뉴스들
온라인 서비스의 가격을 결정하는 것은 정말 어려운 일중에 하나입니다. 아마존에서 Pricing으로 책을 검색해보면 1만 권이 넘는 결과가 나옵니다. 책이 이렇게 많은 이유는 아마도 다양한 이론과 의견이 있기 때문이겠죠. 게다가 디지털 제품의 경우는 실물 상품과 달리 반영구적이고, 원가에 대한 걱정 없이 거의 무한정으로 재생산 가능하기 때문에 "내 SaaS는 얼마나 받아야 할까?"라는 질문에 선뜻 답하기가 곤란합니다.

"Sequoia의 제품 가격 결정 가이드"는 기존 경제학 관점으로는 설명할 수 없는 디지털 제품의 가격 정하는 법을 정리한 글입니다. ( 참고로, 세콰이어 캐피털은 1972년에 설립되어서 애플, 구글, 오라클, 깃헙, 페이팔, 유튜브, 인스타그램, 쿠팡 등에 투자한 세계 최대 규모의 VC입니다. ) 이 글은 "비용에 기반한 가격 설정" 이 아닌 "가치에 기반한 가격 설정" 을 해야 한다고 제시하며, 이 가치를 높아 보이게 만드는 다양한 사례들을 예로 들고 있습니다. 글 마지막에는 적정 가격을 찾기 위한 워크시트도 제공하고 있으니 온라인 서비스를 만들고 계시다면 꼭 참고하시기 바랍니다.

1851년 창간한 뉴욕타임스는 2008년 경제 위기때 본사 건물을 일부 매각할 정도로 어려웠으나, 10년간 디지털로 성공적으로 전환하여 올해 2월 현재 525만명의 유료 구독자를 가지고 있습니다. 그중 디지털 유료 구독자만 440만명으로 종이신문을 보는 독자는 3분의 1도 되지 않습니다. "뉴욕타임즈 CTO의 4년 회고"는 4년간 CTO로 재직했던 Nick Rockwell이 그 동안의 여정을 잘 정리한 글입니다. 스타트업이나 기술 기반 기업에서는 일반적인 Growth 개념을 NYT에 도입한 게 가장 큰일이었다고 합니다.

"Director of Engineering 은 무슨 일을 하나요 ?"는 개발 조직의 책임자 중 하나인 DoE의 업무에 대해서 정리한 글입니다. 일반적으로 스타트업의 개발 책임자는 CTO 정도만 알고 있긴 합니다만, 조직이 커지면 CTO/VPE/DoE 가 하는 일이 조금씩 달라지기 때문에 비교하면서 보시면 좋을 것 같습니다.

스타트업 창업자분들께 종종 듣는 질문 중 하나는 "앱은 뭘로 개발하면 좋은가요?"입니다. 상황에 따라 다르긴 하겠지만, 제가 보통 드리는 답변은
#1 앱이 꼭 필요 없는 서비스라면, 모바일 웹만 먼저 잘 만들어도 됩니다.
#2 앱이 꼭 필요하다면 초기엔 React Native 나 Flutter로 iOS/Android 플랫폼을 동시 지원하세요.
#3 사용자 많아지고 개발자도 늘고 자금도 생기면, 각 OS에 최적화된 네이티브 앱으로 바꿔도 좋습니다. (Swift & Kotlin)
인데요. "iOS와 Android 앱의 디자인 차이점 32가지" 글은 이중 #2와 #3 단계에서 꼭 보셔야할 글 입니다.

최근에 변경된 페이스북 디자인은 호불호가 있긴 합니다만, 속도 개선을 위해 노력한 점들은 높이 사야 할 것 같습니다. 각 단계별로 필요 자원만 빨리 받고, 고객 경험을 훌륭하게 만들기 위해 CSS/JS/Data 모든 측면에서 고민하고 실제로 적용한 경험을 "Facebook의 테크스택 재구축 이야기" 글에서 상세히 공유합니다.

✓ 사내에서 슬랙을 쓰신다면 뉴스채널에 GeekNews SlackBot 을 추가하여 편하게 새 글을 받아보시고, 멤버들에게도 공유해주세요.
✓ 주위분들께 https://news.hada.io/weekly 를 추천해 주세요.
✓ 스팸함에 들어가지 않게 news@hada.io 를 주소록에 추가해주세요.
Twitter , Facebook 에서도 긱뉴스를 받아 보실 수 있습니다.

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


Sequoia의 제품 가격 결정 가이드

"가격은 수학 문제가 아니라 판단의 문제"

- 인식 가치 올리기 : 가격과 (고객이 생각하는) 가치의 갭을 고려
ㅤ→ 에버노트는 국가별로 프리미엄 가격을 다르게 설정 ( 소득 수준이 다르므로, 가치의 기준이 다름 )
ㅤ→ Ebay는 판매자들이 상품 리스트에 사진을 추가하는 기능을 처음부터 25센트에 제공했지만, 사람들이 많이 사용하지 않음. ( 그 가치를 모르니까 ) 하지만 이 기능을 사용한 판매자가 더 높은 클릭률과 더 높은 가격을 받는 경향이 있는 것으로 나타났고, 이걸 "데이터로 기능과 함께 제공"함으로써 기능의 인식 가치를 높임. 실제로 이베이가 이 사진 호스팅 비용에 25센트가 드는 것은 아니어서, 다른 옵션들과 함께 수억 달러의 순이익을 창출.

- Let your price tell a story : 가격이 얘기하게 만들기
ㅤ→ 제품에 설정한 가격은 인식 가치에 영향을 주게 됨. 사람들은 50달러짜리 와인이 10달러짜리 와인보다 좋은 거라고 가정. 즉, 가격은 품질에 대한 프록시(대리인)
ㅤ→ 고객 기반을 확장하는 방법의 하나는, 같은 가격대에 여러 입맛에 맞는 제품을 구비하는 것 ( 5 색상 iPhone 같은 )
ㅤ→ 또 다른 방법은 여러 가지 가격대에서 다양한 버전을 제공하는 것
ㅤ→ 아무리 많은 조사를 하더라도, 고객이 무엇을 원하는지는 확신할 수 없음.
ㅤ→ 고객이 자신만의 패키지를 구성할 수 있게 하면, 가격 및 제품군에 대한 실시간 피드백을 받을 수 있음.

- Know your pinch points : 핀치 포인트를 알자
ㅤ→ 두 명의 고객이 있을 때 그들은 서로 다른 가치로 상품을 인식.
ㅤ→ 이 다른 그룹들을 이해하면, 이런 것은 비용을 지불하고 써야지 하고 생각하는 "핀치 포인트"가 뭔지 알 수 있음.
ㅤ→ Linkedin은 유료화 시작하던 2005년에 고객의 90%가 사용하지 않는 기능들을 리스트하고, 그것들이 헤비유저들에게 좀 더 가치가 있다고 판단한 뒤 별도로 분리. 이중 "파워 검색"과 "다른 멤버에게 연락하기" 기능은 링크드인 프리미엄 계정의 기초가 되었음.

- Design for snap judgments : 빠른 판단이 가능하도록 만들기
ㅤ→ 전통적인 경제방식으로는 가격을 책정할 수 없음. "사람들은 합리적으로 행동하지 않음"
ㅤ→ 구매할 때 논리와 이성이 끼어들기도 전에 "아주 짧은 시간" 동안에 먼저 결정을 하게 됨. 새로운 것의 가치를 평가하는 노력을 기울이기보다는, 자신이 내린 판단이 올바르다고 생각하는 방식으로 쉬운 길을 택함.
ㅤ→ 온라인에서 로퍼(Loafer, 구두의 일종) 같은 신발을 볼 때, 후드와 찢어진 청바지를 입은 모델이 신은 것이 서류 가방을 든 회사원이 신은 것보다 싸다고 생각하게 됨. 신발을 만들 때 들어가는 재료나 박음질 등에 대한 고민 없이 쉬운 질문을 선택. "학생 & 회사원은 로퍼에 돈을 얼마나 쓸까?" 그 값이 이 로퍼의 가격이 비싼지 아니면 할인하는지를 판단하는 기준이 됨.
ㅤ→ 웹사이트를 만들어주는 Weebly 도구는 처음에 "무료이고 쉬워요."라는 걸 강조했지만, 사람들은 이걸 "기능 없는 싼 티 나는 제품"으로 인식함. "당신처럼 독특한 사이트를 만들어 보세요."라는 문구로 바꾸고, 수백만 달러가 들어간 것처럼 보이는 웹사이트를 데모로 보여주기 시작.
ㅤ→ 에버노트는 SWAG(막 나눠주는 기념품 같은 물품들)을 금지. 싸구려 민트사탕이나 스트레스 볼(꾹꾹 눌러보는 고무공) 같은 것과 에버노트를 연관 짓지 못하도록. 나이키와 애플은 자신들의 제품이 아닌 것에는 로고를 넣지 않음. MacHeist 같은 소프트웨어 번들 딜 프로모션도 금지하는 대신, Moleskine 같은 노트북 (실제로 서비스보다 더 비싼 금액인)과의 연계 상품을 만듦.

- Decoy Pricing : 미끼 상품 만들기
ㅤ→ Economist 잡지가 온라인 $59, 인쇄본 $125, 인쇄본+온라인을 $125에 팔았을 때,
ㅤㅤ100명의 학생 중 84명이 $125콤보를 선택하고, 16명은 온라인 버전을 선택
ㅤㅤ하지만, 인쇄본 전용 옵션을 제거했을 때는 68명이 더 싼 버전인 $59를 선택.
ㅤㅤ즉 인쇄본은 패키지로서는 가치가 없지만, 소비자가 Snap Judgement 할 때 영향을 줌.
ㅤ→ 미끼 상품은 다른 상품을 더 좋게 보이는 효과가 있음.
ㅤ→ B2B 제품에서도 마찬가지. 10 사용자당 월 $500, 25 사용자당 월 $1000 일 때, 무제한 사용자 대상 월 $1200로 설정. 그러면 대부분 $1000 대신 $1200을 선택.

- 가격에 대한 가설 세우기
ㅤ→ Pricing Worksheet 를 파일로 제공. 4개의 필드 채우기
ㅤ(1) 고객이 당신의 제품을 처음 볼 때 생각나야 할 것들 : 왼쪽에는 당신 제품의 대체제가 될 만한것, 오른쪽에는 같이 사용할만한 보완제.
ㅤ(2) 순간 판단 요소와 상세 분석에 따른 결과로 알 수 있는 요소들
ㅤ(3) 인식 가치를 시각화. 다른 대체제 및 보완제들의 가격에 기반.
ㅤ(4) 누구를 대상으로 마케팅 할 것인가

세콰이어 캐피탈에서 만든지 꽤 오래된 가이드지만 기초중의 기초라서 살짝 요약해 봤습니다.
Pricing Worksheet 파일 : https://www.dropbox.com/s/c943j7h3hkgdi68/Pricing-Worksheet.pdf

 
뉴욕타임즈 CTO의 4년 회고

- 재직기간중 온라인 구독자 1백만->5백만
- 기술조직은 회사의 비즈니스 지표에 따라 평가되어야 한다
- Growth 기반 사고와 실천을 NYT에 도입한게 가장 큰 일이라고 생각
ㅤ→ Growth 관련 똑똑한 사람들을 모셔서 배움(사내 강의) : 앤드류첸(a16z),브라이언 발포(Reforge) 등
ㅤ→ 마케팅 기술 플랫폼에 투자 : ActionIQ를 이용한 CDP(고객 데이터 플랫폼) 구축
ㅤ→ Paywall 용 Meter 서비스 재개발하여 전환율을 높임
ㅤ→ 가격변동 시험을 쉽게 할 수 있도록 개선
- 데이터 인프라 스트럭처 개선: 하둡 및 자체 솔루션에서 순수 GCP 데이터 스택으로 (BigQuery)
- 클라우드 도입: 4개 데이터센터에서 GKE기반으로. Kafka,GraphQL,React,Swift 등으로 대부분을 재개발
- 문화:
ㅤ→ 성과중심 문화를 만든게 전체 문화에 도움이 되었음.
ㅤ→ 조인했을때 나보다 팀이 더 많이 알고 있었고, 그들에게 많이 배우고 협업해서, 팀이 잘하는 것을 하도록 도와준 것이 중요했음.
- R&D 와 신규 서비스
ㅤ→ R&D팀을 리빌딩 하고, 연구개발이 실제 비즈니스에 기여할수 있는 기반을 조성. 조직내 어디서나 혁신이 가능하도록.

"기술조직은 회사의 비즈니스 지표에 따라 평가되어야 한다" 이 부분 원문내용을 조금 더 적어서 보충하면

1. 생산성/퍼포먼스 지표들도 중간에는 쓰이겠지만, 끝내는 비즈니스 결과로 평가되는 수 밖에 없음 (예: 구독자 증가율 )
2. 목표와 얼라인이 중요.

회사의 목표와 상관 없이 기술적 성취를 위해서만 나가는 경우를 종종 봐서.. 많이 공감 됩니다.

 
Director of Engineering 은 무슨 일을 하나요 ?

보통 CTO에게 직보하는 DoE(기술이사)의 업무 범위 이야기
- 피플 리더십
ㅤ→ 1대1 미팅 진행
ㅤ→ 리크루팅
ㅤ→ 기술 성장 로드맵 정의
ㅤ→ 핵심 가치 추구
ㅤ→ 미션 수행
- 프로세스 관리
ㅤ→ Software Development Lifecycle
ㅤ→ 팀 스케일링
ㅤ→ 기술 전략 수립
ㅤ→ EOS(Entrepreneurial Operating System)
- 제품의 방향
ㅤ→ 로드맵을 위한 자원관리
ㅤ→ 배포 관리
ㅤ→ 전체적인 감독
ㅤ→ 접근 권한 관리
ㅤ→ 특정 기능을 개발할 것인지, 구매할 것인지 결정

일반적으로 작은 규모의 스타트업이라면 CTO가 해야할 일들이겠지만, 회사 규모가 좀 커지기 시작하면
CTO는 리더십,비즈니스 연계 등 더 윗선에서 봐야할 것들을 보게 되니까
DoE가 CTO를 도와서 할 일들을 잘 정리한 문서인듯 합니다.

CTO/VPE 가 첫 90일동안 해야할 일 https://news.hada.io/topic?id=1686 글과 비교하면서 보세요.

글에 설명 안 된 몇개 단어들
What is EOS? https://www.eosworldwide.com/what-is-eos
L10 Meeting https://www.eosworldwide.com/blog/what-the-heck-is-a-level-10-meeting

 
iOS 와 Android 앱의 디자인 차이점 32가지

단순 비교만이 아니라, 각 OS UI의 특장점을 이해하는데 좋은 글

기본 차이점
1. HIG vs. Material Design
2. 단위: pt vs. dp
3. 스크린: 320pt x 568pt vs. 360dp x 640dp
4. 폰트 : San Francisco vs. Roboto
5. 안드로이드 네비게이션 바
6. 매터리얼 디자인의 Shadow와 Elevation
7. Naming:
ㅤ→ Tab bar vs. Bottom Navigation Bar
ㅤ→ Navigation Bar vs. Top App Bar,
ㅤ→ Segmented Controls vs. Tabs
ㅤ→ Alerts vs. Dialogs
ㅤ→ Touch ID vs. Android Fingerprint
8. 탑 레벨 내비게이션 방법
9. 탭바와 하단 네비게이션 바의 차이
10. 안드로이드 탭의 특별한 기능
11. 하위 페이지 보이는 방법의 차이
12. 네비게이션 서랍(Drawer) 호출 패턴
13. 스크롤시의 동작 차이
14. 검색 동작의 차이

컴포넌트(UI) 차이점
15. iOS에 없는 것들
ㅤ→ Navigation Drawer, Backdrops, Banner, Snackbar, Chips, Bottom App Bar, FABs(Floating Action Button), Bottom Navigation Drawer, Side Sheet, Expanding Bottom Sheet, Standard Bottom Sheet,
16. Android에 없는 것들
ㅤ→ Page Control, Toolbars, Steppers, Popovers
17. 같지만 다른 Status Bar
18. Refresh Content Control vs. Swipe to refresh
19. 컨트롤들의 비주얼 차이점
20. 뒤로 가기 화살표의 모양과 헤더포지션 차이
21. "점 세개" 아이콘의 차이점
22. Pickers : iOS 날짜선택은 드럼타입, 안드로이드는 일반 달력 모양
23. 텍스트 필드의 차이
ㅤ→ iOS 는 레이블을 필드위에 보여주고 입력시 사라짐, 안드로이드는 입력시 위로 이동
ㅤ→ 내용 Clear 버튼은 비슷
ㅤ→ 매터리얼 디자인은 입력시 밑줄을 Primary색상으로 강조
24. Context Menus vs. Menus
25. Action View/Activity View vs. Modal Bottom Sheet
26. Edit Menus vs. Text Selection Toolbar
27. 디바이더 사이즈 크기 : iOS 0.5pt vs. Android 1dp

다른 차이점
28. 탭 존 크기 : iOS 44x44pt , Android 48x48dp
29. App Store vs. Google Play
30. iOS의 특이한 Undo/Redo : 사용자가 폰을 흔들면 Undo 기능 동작
31. 런치 화면의 차이 : 매터리얼은 런치화면에 앱로고를 허용하지만, HIG는 런치화면에을 마케팅용도로 사용하는것은 추천하지 않음. 플레이스 홀더로만 사용
32. 매터리얼 디자인의 추가 요소 : Data Format, Data Visualization, Empty States, Offline States 등

스타트업인데 앱은 뭘로 개발해야 하나요? 라는 질문에 저의 기본 대답은

#1 앱이 꼭 필요없는 서비스라면, 모바일 웹만 먼저 잘 만들어도 됩니다.
#2 앱이 꼭 필요하다면 초기엔 React Native 나 Flutter 로 iOS/Android 플랫폼을 동시 지원하세요.
#3 사용자 많아지고 개발자도 늘고 자금도 생기면, 각 OS에 최적화된 네이티브앱으로 바꿔도 좋습니다. (Swift & Kotlin)

근데, 이거 10년 전과 대답이 똑같습니다.
그때는 HTML5, Hybrid(Phonegap) , Objective C++ & Java 였을 뿐..
지금은 웹을 React로 만들면 React Native 때문에 조금 편하긴 하겠네요.
#1은 무조건, #2를 추천하고, #3은 선택

이 UI 비교 글은 #3번일 때는 잘 이해해야 하고, #2일때도 봐두면 좋은 글입니다.

 
Facebook의 테크스택 재구축 이야기

간단한 PHP로 시작한 페이스북이 이번 새 디자인에 맞게 React + Relay(GraphQL) 로 바꿔온 과정과 교훈

CSS,JS,Data,Navigation 각각에 빠른 앱을 위한 기본원칙 적용
1. 필요한 자원만 최대한 빨리 전송
2. 사용자 경험을 위한 엔지니어링 경험

CSS
- Atomic CSS로 CSS를 80%줄이고, 필요없는 CSS는 다운받지 않게 변경
- 접근성을 위해 rems 사용, px → rems 수동 변환할때의 버그를 줄이기 위해 빌드도구에서 이를 자동 변환
- Theming(다크모드)를 위해 CSS 변수 사용
- 깜박임 방지를 위해 Inline SVG 사용(img 에 SVG파일 넣는 대신). 이를통해 색상 변경도 런타임에서 가능해짐

JS
- 3단계 Code-splitting 한 JS를 단계별로 전송
ㅤTier 1. 로딩시 UI Skeleton을 빠르게 보이기 위한 베이직 레이아웃
ㅤTier 2. 화면에 보이는 모든 콘텐츠를 완전히 렌더링 하기 위한 JS. 완전히 동작가능하고, Tier 2 이후에 코드가 로딩되더라도 화면 구성이 바뀌면 안됨
ㅤTier 3. 화면 출력후 필요한 모든 것. 로깅코드, 실시간 업데이트 구독 등.
- 500KB의 JS가 50KB Tier 1, 150KB Tier 2, 300KB Tier 3 로 분할 → 로딩 및 화면 표시가 매우 빨리 끝나는 효과
- 분할 덕분에 A/B 테스트 시에도 양쪽에서 필요한 코드만 받게 설정이 가능해짐
- Data-Driven React 앱을 만들도록 도와주는 Relay 의 기능을 이용, 어떤 데이터를 가져올 지에 따라 필요한 컴포넌트만 로딩하게 변경
- Product별 JS Budget(예산) 제도를 도입. 성능 목표, 기술적 제약 및 제품 고려사항을 기반으로 예산을 설정. 시간이 흐른뒤에도 코드가 늘어나는 것을 방지.

Data
- Relay 를 이용, 모든 데이터 페칭을 GraphQL 로을 이용하도록 표준화
- Realy 덕분에 페이지 요청단계부터 먼저 필요한 데이터를 병렬로 다운로드. 화면에 빠르게 보여주도록 가능
- GraphQL 내부 확장인 @stream을 이용해서 뉴스피드 같은 걸 여러번의 라운드트립없이 한번의 쿼리로 데이터를 차례차례 보내게 함
- @defer + React Suspense 로 당장 필요하지 않은 데이터는 나중에 로딩하도록

Navigation
- SPA 네비게이션시 새 페이지 로딩할때 자원 로딩 시간및 라운드트립을 줄이기 위해 Route Map을 구성
- 필요할 때마다 최대한 빨리 Route Map에 Route 정보를 분할하여 로딩
- 자원은 가능한 빨리 먼저 프리페칭 (호버시 프리페치, 마우스 다운시 코드와 데이터 가져오고, 클릭이 일어나면 React 상태 변경)
- 네비게이션 간에 빈화면을 보여주는 것 대신, React Suspense 트랜지션을 활용하여 새 Route 가져오기 전에 기존 Route 를 지속해서 보여주기
- EntryPoints ( 코드 분기 포인트 와 데이터 쿼리를 Wrapping 한 작은 파일) 를 이용해서 코드 및 데이터 다운로드를 병렬화

Relay - The production-ready GraphQL client for React https://relay.dev/

페이스북 새 디자인의 CSS에서 알게된 것들 https://news.hada.io/topic?id=1819
글도 같이 참고하시면 좋습니다.

 
delta - git/diff Syntax-Highlighter

- git diff 의 출력을 구문강조 해주는 유틸
- 설치후 .gitconfig 에서 pager로 delta를 지정하면
ㅤgit diff/show/log/stash/reflog/add 등 대부분의 명령이 구문강조 됨
- Line내에서 추가/삭제 부분을 여러개까지 인식해서 표시
- diff 와 pipe 해서 보여주는 용도로도 사용

bat 에서 지원하는 구문강조 테마를 그대로 지원합니다. 세트로 쓰면 깔끔.
bat - Syntax Highlighting 되는 cat https://news.hada.io/topic?id=1985

 
Rich - 터미널을 화려하게 포매팅하는 파이썬 라이브러리

- CLI 만들때 다채로운 색상, 스타일(두껍게,이탤릭,밑줄 등) 적용
- 테이블, 프로그레스 바, 마크다운, 코드 구문강조, traceback 출력 지원
- 기본 print 대신 rich print() 메소드 적용만으로 아름다운 출력 가능
- console 객체에서 bbcode 와 비슷한 형식으로 스타일 적용
- console.log 는 현재시간,호출한 파일을 자동 출력하고, 파이썬 구조체나 repr 문자열을 구문강조 처리. 로컬변수 출력기능 지원
- emoji 는 :smiley 형태로 지원
- 깜빡이지 않는 Progress Bar 지원
- pygments 라이브러리로 Syntax Highlighting

 
Tara - 무료 JIRA 대체도구

- 스프린트 단위 개발에 적합한 이슈관리 툴
- 요구사항과 Task를 한눈에 보고 빠른 Task 입력 가능
- 주간,격주간,월간 반복 스프린트 관리
- GitHub 연동 : 이슈,커밋,릴리즈,PR
- 에픽,스토리,멀티스프린트,훌륭한 개인별 대시보드

Slack 과 Y컴비네이터에서 투자를 받은 회사네요.
작은 회사에서는 써보니 괜찮다는 평이 있는거 같은데, 과연 아틀라시안과 경쟁이 될수 있을지 기대해 봅니다.
나중에 유료화를 어찌 할지는 모르겠지만 현재는 아예 Freemium 모델도 아니고 그냥 무료네요.


그외에 Jira/Trello 를 제외하고 종종 얘기되는 프로젝트/이슈 관리 도구들

* ClubHouse https://clubhouse.io/ - 프로젝트관리+다양한 연동으로 현재 시장에서 가장 좋은 평을 받는 서비스. Write라는 Knowledge Base 도구를 베타시작 (위키 엔진과 비슷)

* Phabricator https://phacility.com/ - 코드리뷰,이슈트래커,위키 등을 포함하는 협업도구. PHP로 작성되고 10년이나 되었다보니 여러 부분에서 다소 올드한 PHP스러움이 묻어납니다.

* Basecamp https://basecamp.com/ - ToDo,위키,마일스톤 관리,파일 공유,메시징 기능등을 가진 프로젝트관리+내부 커뮤니케이션 툴. 원격근무회사들에 잘 어울리죠.

* Treenga https://treenga.com/ - Task관리에만 집중한 도구

 
Caddy 2 릴리즈 - 성능 좋고 간편한 HTTPS 자동 지원 웹서버

- Let's Encrypt 인증서 관련 기능을 내장. 자동으로 인증서 발급 및 갱신. HTTPS가 기본
- 읽기 쉬운 Caddyfile 로 빠르고 편한 설정. JSON 포맷으로 상세 설정
- Go로 작성된 의존성 없는 싱글 바이너리
- 리버스 프록시, 사이드카 프록시, 로드밸런서, API Gateway 등으로 사용 가능
- 웹 서버 설정용 REST API 제공 -> 테스팅 등 자동화에 편리
- nginx.conf 를 직접 읽어서 설정값으로 사용 가능

v1 때는 라이센스가 조금 독특해서, 코드는 Apache 2.0 이었지만
바이너리는 유료 서비스에 사용 하려면 서브스크립션을 구매해야 하는 구조라 직접 빌드하거나 했어야 했는데,
작년 10월에 Go 관련 교육을 제공하는 Ardan Labs와 파트너 계약을 하면서 그런 제약이 사라졌습니다.
https://github.com/caddyserver/caddy/issues/2786

v1 과는 완전히 다른 코드베이스로 재개발되어 하위호환 되지는 않지만 세팅은 거의 비슷
https://caddyserver.com/docs/v2-upgrade

 
바닐라 아이스크림에 알레르기가 있는 자동차

GM에 접수된 고객 클레임
"새 폰티악을 몰고 아이스크림을 사러가서, 다른 아이스크림은 상관없지만 바닐라 아이스크림을 고르면 시동이 걸리지 않아요"
그래서 엔지니어가 모든 데이터를 분석하여 찾은 문제는 "Vapor Lock"
"아무리 미친 것 같은 문제라도 가끔은 진짜다."

500마일 이메일 문제 https://edykim.com/ko/post/500-mile-email-problem/
“500 마일 (역주. 800km 가량) 이상 되는 거리엔 메일을 보낼 수가 없어요.”

최신 고성능 안드로이드폰일수록 메모리가 부족하다
https://twitter.com/0x1a21b01/status/1258053111857311744

 
GitHub Codespaces 공개

- 깃헙내에서 VS Codespaces 사용 (예전 Visual Studio Online)
- 컨테이너 & 클라우드 기반 IDE
- 코드,빌드,테스트,디버그,배포를 브라우저에서
- VS Code 로컬에서도 연결해서 개발 가능
- 얼리억세스 통해서 베타 신청 받는중

특별한 환경을 필요로 하는 오픈소스들의 경우엔 개발환경을 로컬에 구축하지 않고도 쉽고 빠르게 컨트리뷰트 하기 좋은 환경이 될듯
또한 iPad에서 잘 실행되는 개발환경이기도 해서 어디서나 개발가능!

Github Codespaces는 VS Codespaces 와 같은 기술을 사용하지만 GitHub 관련 기능을 포함하고 있는 거라고 보심 됩니다.
GitHub Actions 가 하단에서는 Azure Pipelines 를 활용하듯, MS의 클라우드 제품들이 차곡차곡 GitHub에 적용중.

아직은 가격이 공개 안 됐는데, GA전에 가격도 공개 예정.
지난 달에 MS가 Visual Studio Online 을 VS Codespaces로 이름 변경하면서, 가격을 50% 정도 내린바 있습니다.

VS Codespaces 의 변경된 가격이 시간당
- 베이직 $0.085 ( 2코어, 4G, 64GB SSD )
- 스탠다드 $0.169 ( 4코어, 8G, 64GB SSD )
- 프리미엄 $0.339 ( 8코어, 16G, 64GB SSD )

인데.. GitHub Codespaces가 이거보다 더 싸지는 않을듯 ?

 
데이터 분석가 인터뷰를 위한 SQL질문 모음

여러 회사 인터뷰를 진행했던 지원자의 스터디 노트
- Self-join
ㅤ→ MAU MoM
ㅤ→ Tree 구조 레이블링
ㅤ→ 사용자 리텐션
ㅤ→ 누적 캐쉬플로우
ㅤ→ 이동 평균
ㅤ→ 멀티조인
- Window Function
ㅤ→ 최대 연봉자 찾기
ㅤ→ 부서별 평균 연봉
- 그외
ㅤ→ 히스토그램
ㅤ→ 크로스 조인
ㅤ→ 고급 카운팅

문제의 정의가 스타트업에서 많이 쓰일법한 것들이라 재미나게 봤습니다.

SQL 입문가이드 용으로 추천한 Select Star SQL https://selectstarsql.com/ 사이트도 훌륭하네요.
브라우저에서 SQLite를 올려서 인터랙티브한 SQL 쿼리가 가능하게 만들어뒀습니다.
https://github.com/zichongkao/selectstarsql

 
Axiom - 코딩없이 브라우저 봇 만들기

- 클릭만으로 웹에서 반복작업/자동화 만들기 지원
- 웹페이지 데이터 추출(멀티페이지), 데이터 자동 입력, 버튼/링크 클릭
ㅤ데이터 필터링 및 변환, 파일 다운로드/업로드, 구글 쉬트 읽고 쓰기
- 데스크탑 (크롬확장+별도 실행파일), 클라우드 (지원예정)
- 일반인을 위한 No-Code RPA(Robotic Process Automation) 도구

개발자들은 Puppeteer 같은 걸로 비슷한 작업을 할 수는 있겠지만, 코딩 모르는 사람도 반복 작업들을 쉽게 해주는 도구

No-Code 관련 챙겨볼 기사들

No Code is New Programming https://news.hada.io/topic?id=1099
Low-Code / No-Code 개발 플랫폼들 리뷰 https://news.hada.io/topic?id=1799
"No Code" 소프트웨어 리스트 https://news.hada.io/topic?id=374
Y컴비네이터 W20 참가 197개 스타트업들 https://news.hada.io/topic?id=1751

 
NeutralinoJs - JS/HTML/CSS로 크로스플랫폼 앱 만들기

- Electron / NW.js 와 비슷하지만 초경량 & 빠름
ㅤ→ 메모리 7MB 내외. 앱 크기 1MB 이하(압축)
- Node와 크로미움을 내장하지 않고, 플랫폼 브라우저 이용 & C++서버를 XHR로 호출하여 사용
- 개발환경 구축이 빠르고 쉬움. 별도 의존성 없음
- 윈/맥/리눅스
- OS 레벨 API 제공 : FileSystem, runCommand 등

물론 아직 일렉트론 보다는 덜 성숙한 상태.
다만 예전 같았으면 윈도우에서 IE에 의존하는 상황때문에 약간 호환성 문제가 있었겠지만,
이제 Edge가 크로미움 기반으로 완전히 이전하면 Neutralino 가 일렉트론보다 가볍게 쓰기 좋을듯.

 
Modern PHP 살펴보기

올해로 25주년. 전세계 웹사이트 78%가 사용중. 7.4.5 출시
- PHP OOP의 진화
- 의존성 관리와 써드파티 확장들 : PEAR,PECL에서 Composer로
- FFI(외부 함수 인터페이스) : 타 언어와의 연계가 쉬워져서 TensorFlow Bindings for PHP 같은 것들이 가능해짐
- 보안을 덜 모호하게
- 지속적인 성능 개선 : 7.4 는 5.6대비 3배의 Req처리 성능. 프리로딩 지원. JIT 추가(8에서 공식 릴리즈 예정)

PHP글이 올라오면 HN댓글창은 전쟁터. 500개가 넘는 댓글이..
https://news.ycombinator.com/item?id=23077367

PHP in 2019 https://news.hada.io/topic?id=92
PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 벤치마크 https://news.hada.io/topic?id=1278
PHP 8 의 새 기능들 https://news.hada.io/topic?id=1438

 
Prototypr - 디자이너를 위한 큐레이션 플랫폼

- 계속 추가되는 약 1000+개의 디자인 도구
- 매일 매일 손으로 큐레이션 해서 올리는 디자인 관련 글들
- 주간 뉴스레터 발행

디자이너를 위한 긱뉴스 라고 보면 되겠군요 ^^

 
(마케터 머리 꼭대기에 있는) Z세대가 광고 보는 법

1. Z세대는 인스타 피드에 뜨는 맞춤형 광고를 이용하고,
2. 유튜버 돈 벌라고 영상 앞에 달린 광고를 Skip 없이 끝까지 시청하며,
3. 광고주 보라고 유료 광고 영상에 폭풍 칭찬 댓글을 달고
4. 사고 싶은 게 생기면 광고(리뷰)를 제 손으로 찾아본다.

재작년 자료긴하지만, '밀레니얼, 그리고 Z세대가 말하는 유튜브의 모든 것'이라는 인포그래픽도 한 번 보시면 좋을 것 같아 링크 남깁니다
https://www.20slab.org/Archives/29165

CEO,마케터,개발자 누구든 한 번 읽어보시면 좋을듯 합니다. 소비자 트렌드의 파악은 중요하니까요.
확실히 요즘 세대의 광고 소비는 다르긴 한 듯

 
Liftbridge - 가볍고 Fault-Tolerant한 메시지 서버

- Kafka/Pulsar 와 비슷하지만 훨씬 간단하고 클라우드에 적합한 구현체
- Zookeeper/JVM등 복잡한 의존성 및 설정 필요없는 16MB짜리 싱글 Go 바이너리
- 클라이언트는 gRPC사용
- NATS를 확장해서 기존 NATS환경의 코드변경 없이 안정적인 스트리밍,Pub/Sub Log API 추가 가능
- Wildcard Subscription 지원
- Key-value & 헤더 지원 → WAL, Write Ahead Logging 에 적합
- 로그 보관 및 키 기반 압축

NATS - 심플하고 안전한 고성능 오픈소스 메시징 시스템 : https://nats.io/
NATS의 한글 소개글 https://medium.com/@goinhacker/nats-a63fba865d6f

기존에 로그기반 메시징 솔루션으로 NATS Streaming이 있지만 그건 NATS와는 별도의 프로토콜 구현방식,
Liftbridge 는 NATS를 보완해서 그 기반위에서 간단하지만 안전한 전송을 보장하도록 구현하는 "Bridge"
그래서 기존 코드의 변경없이 추가하여 사용 가능.

Liftbridge vs NATS Streaming vs Apache Kafka vs Apache Pulsar
https://liftbridge.io/docs/feature-comparison.html

Liftbridge 개발자인 Tyler Treat 가 2017~2018년에 분산 로그시스템 구현에 대해 적은 시리즈 글을 참고하세요.
Building a Distributed Log from Scratch
- Part 1: Storage Mechanics https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-…
- Part 2: Data Replication https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-…
- Part 3: Scaling Message Delivery https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-…
- Part 4: Trade-Offs and Lessons Learned https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-…
- Part 5: Sketching a New System https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-…

* Write Ahead Logging 이란 ? : https://postgresql.kr/docs/9.6/wal-intro.html

 
Fast or Slow - 웹사이트 속도 측정 도구

- 전셰계 10개 위치에서 웹사이트의 FCP,FMP,TBT,TTI,RTT 등을 측정
ㅤ→ US SE/NE/NW/Central,영국,독일,네덜란드,일본,호주,브라질
- 측정 결과에 이메일 주소 입력하면 정기 모니터링 가능
- 결과는 약 90일간 저장되고, 예전 결과도 볼 수 있음

구글 PageSpeed Insights랑 결과는 비슷한데, 다양한 장소에서 테스트한 결과를 보여주는게 좋네요.
https://developers.google.com/speed/pagespeed/insights/

First Contentful Paint (FCP)
First Meaningful Paint (FMP)
Total Blocking Time (TBT)
Time To Interactive (TTI)
Round-trip time (RTT)

 
ink - React로 CLI만들기

- create-ink-app 으로 Scaffold 생성
- 최종 렌더링 결과가 DOM이 아니라 터미널 출력용 문자열
- 페이스북 Yoga엔진으로 터미널에서 Flexbox 레이아웃을 지원
- Box, Color, Text, Transform, AppContext, StdinContext, StdoutContext 등의 기본 컴포넌트
- Link, Spinner, Gradient, Image, Tab, Multiselect, ProgressBar, Table, Markdown 등의 확장 컴포넌트
- useInput, useApp, useStdin, useStdout, useStdoutDimensions 등의 Hook 지원
- Gatsby, Parcel 등에서 사용중

 
blessed - node.js용 터미널 UI 라이브러리

- terminfo/termcap을 파싱하여 ncurses를 재구현. 어떤 터미널에서든 출력가능
- 터미널용 최적화된 Widget API 제공
ㅤ→ Box,List,Form,Prompt,Image 등의 컴포넌트
ㅤ→ 쉬운 UI 제어를 위한 다양한 이벤트/메소드 지원
- CSR (change-scroll-region, 특정 부분만 스크롤), BCE (back-color-erase, 현재 배경색으로 지우기) 지원하여 효율적인 화면 출력

 
Selecto.js - 마우스/터치로 드래그해서 선택하기

- 드래그 동작으로 아이템 선택기능을 지원하는 라이브러리
- 실시간으로 아이템 선택 및 토글 가능
- 스크롤 하면서도 가능
- react,vue,svelte,angular,preact 용 패키지 제공

Moveable - 개체 사이즈 모든 방향으로 조정하는 JS 라이브러리 https://news.hada.io/topic?id=689
개발하신 최연규(Daybrush) 님의 프로젝트

https://github.com/daybrush/scena 에서 Scene.js, Moveable , Selecto, Guides, Ruler 등 다양한 컴포넌트랑 같이 보세요.

 
Async-GraphQL - Rust로 구현된 GraphQL 서버 라이브러리

- async/await, Type-Safe, Subscription, Custom Scalar, Cursor Connections, Multipart Request
ㅤ→ GraphQL의 최신 스펙들을 대부분 지원
- Apollo Tracing/Federation 확장 지원
- Actix-Web, Warp, Tide 웹 프페임워크들과 연동

기존 Rust 기반 GraphQL 서버라이브러리 인 Juniper 랑 비교해서 더 많은 기능을 내장
https://github.com/graphql-rust/juniper

몇년된 Juniper와 달리 이 프로젝트는 2020.03.01에 첫 커밋해서 두달 조금 넘었는데..
엄청난 속도로 개발중. 커밋 로그 보면 하루에 몇개씩 올리고 있네요.