[GN#56] 인스타그램을 10억 사용자로 만든 `인접 사용자 이론`

2020-07-27 ~ 2020-08-02 사이의 주요 뉴스들
10억 사용자를 가진 플랫폼이 된 인스타그램은 요즘엔 인별/인별그램이라는 명칭으로 방송에서도 심심찮게 언급되는 것을 볼 수 있습니다. 2010년에 출시되어 2012년 4월까지 3천만명의 아이폰 사용자만을 대상으로 사진을 공유하던 인스타그램은, 2012년 4월 3일 안드로이드 버전을 출시하니까 바로 안드로이드 사용자 1백만명이 가입을 하고 일주일 동안 5백만의 안드로이드 사용자를 끌어들이는 기염을 토하게 됩니다. 그러고 나서 바로 4월 9일에 페이스북이 10억달러(1조2천억원)에 인수한다는 발표가 나면서 큰 화제가 되었는데요. 더 놀라운 건 그때 인스타그램의 직원이 13명이었다는 것이기도 했죠. 인수된 후에도 얼마전까지는 인스타그램은 페이스북 색을 많이 드러내지 않으면서 계속 발전하며 사용자를 꾸준히 늘려왔습니다. 이 인스타그램의 사용자 증가를 어느 정도 설명하는 글이 "인접 사용자 이론" 이라는 제목으로 공유되어서 소개해 드립니다. 나름 주요부분만 요약을 했는데도 길긴 합니다만, 사용자 수를 늘리는 건 모든 서비스회사들의 주요 목표인지라 꼭 읽어보시기 바랍니다.

회사가 주는 최고의 복지 중 하나는 훌륭한 동료를 두는 것이라는 얘기를 합니다. 그들을 통해서 배울 수 있는 것들이 많고, 그러면서 자신도 성장하기 때문일 텐데요. 동료들한테 배우는 것중 가장 재미나고 유용한 것에 개발도구를 잘 쓰는 법도 포함됩니다. 작은 팁 하나만으로 생산성을 대폭 개선할 수 있기 때문이죠. 요즘 웹 개발자들한테는 필수도구인 크롬 개발자도구를 마치 동료가 알려주듯 자세히 설명한 "시니어 프론트엔드 개발자처럼 크롬 개발자도구 사용하기" 글은 쥬니어부터 시니어까지 모두 참고할 만한 글입니다. 비슷하게 대학생들도 처음에 전산학과에 들어가더라도 정규과정에서는 잘 가르쳐 주지 않지만 배워야 할 것들이 꽤 있는데요. MIT의 전산학 조교들이 가장 기본적인 쉘, 에디터, 터미널, 버전관리등에 대해서 설명한 강의도 보시면 좋을 것 같아요.

CloudFlare는 CDN업체중에서 마켓쉐어는 아주 크지 않은 회사입니다만, 인터넷 기술 관련해서는 다양한 분야에서 많이 거론되는 회사입니다. 긱뉴스에서도 CloudFlare로 검색하면 꽤 많은 뉴스들이 공유된 걸 볼 수 있는데요. 이건 좋은 회사 기술 블로그는 어떻게 운영되는가 글에서처럼 사내에서 기술 블로그를 장려하는 문화가 기본이어서 나온 결과 일듯 합니다. CloudFlare가 자신들의 서버리스 환경이었던 Workers를 확장해서 AWS Lambda와 견줄 수 있는 서버리스 플랫폼으로 출시하겠다는 발표를 했습니다. 놀랍게도 Cold Start 시간이 0 이라는걸 강조하고 있는데요. 전 세계 각지에 Edge를 두고있는 CDN 업체가 그 인프라를 기반으로 FaaS업체로 확장해 나가는 것을 지켜보는 것도 재미날 것 같습니다.


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

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


인스타그램을 10억 사용자로 만든 "인접 사용자 이론"

사용자 4억명에서 10억명이 된 3년간 Growth팀 헤드였던 Bangaly의 경험을 공유한 글 [주요 부분 요약]
- 입사 시점엔 선형적 성장으로 성장속도가 느려지기 시작
ㅤ→ 기하급수적 성장으로 바꾸기 위한 노력

- "인접 사용자(The Adjacent User)"는 제품을 알고, 사용해 봤지만 참여하지는 못하는 사용자
ㅤ→ 제품 포지셔닝 이나 경험하는데 장벽이 있음을 의미. 제품을 받아 들이지(수용,Adoption) 못함
ㅤ→ 4억명에게는 PMF(Product-Market Fit, 제품 시장 맞춤) 했지만, 여전히 이를 이해하고 사용하지 못하는 사용자 그룹이 있음
ㅤ→ Growth 팀은 지속적으로 인접 사용자를 정의하고, 그들이 뭘 어려워 하는지를 이해하고, 공감하면서 문제를 해결해야 함
ㅤ→ 인접 사용자 이론은 인스타그램 뿐만 아니라 다른 많은 제품기반 회사들에서도 역동적인 변화를 만들어 냄

** 인접 사용자의 중요성 **

- 인접 사용자를 해결하는 것이 현재 PMF의 잠재력(Potential)을 잡는 것
PMF 하다면 건강한 리텐션 커브를 가지게 되지만, 이게 최종 목표는 아님.
현재의 리텐션은 PMF의 진정한 포텐셜을 보여주지는 못함.
리텐션과 PMF 둘 사이엔 약간의 갭이 있고, 인접사용자를 끌어들이면 그 갭을 줄일 수 있음

- 인접 사용자를 끌어들이면 점진적으로 영향을 주게 됨
매년 유권자들에게 투표하라고 독려하는데, 이러면 이 유권자들은 그 선거의 결과에 영향을 줄 뿐만 아니라 향후에 있을 선거 및 해당 세대의 정치적 참여를 바꿀수 있음.
비슷하게 인접 사용자에게 서비스의 핵심 가치를 경험하게 하면 단기적인 코호트가 변경될 뿐만 아니라 향후 모든 코호트에 영향을 미침.
이는 리텐션 뿐만 아니라 사용자 획득 및 수익 창출까지 모두 영향을 줌.

- 인접 사용자는 제품에 대한 노력을 집중하는 또 하나의 방법
대부분 제품 팀은 기존 사용자를 잘 알고 있지만, 미래 고객(Future Audience)들은 계속 바뀌어감.
이런 잠재적인 사용자들이 제품을 채택할 때 발생 하는 문제는 시간이 지나면서 계속 증가함.
차세대 고객군을 이해하고, 지원하고, 구축하는 전담팀이 없다면 고객을 늘려갈 수가 없음.
이러면 성장을 멈추고 제품이 원하는 수준에 도달하지도 못함.

** 인접 사용자 깊이 이해하기 **

제품을 여러 개의 단계별 서클(Circle)로 생각해보면, 각 서클들은 사용자가 있는 상태에 따라 나눠짐
예) Power User > Core User > Casual User > Signed Up > Visitor
각 서클에는 사용자들이 그 궤도에 머무르며, 이 사용자들은 다른 단계로 넘어가지 않고 그 안에 있을 가능성이 더 높음
보통 다음단계로 넘어가는데 이를 방해하는 것(진입장벽)들이 있음.
이들이 인접 사용자이며, 우리의 목표는 "그들을 식별하고 그들이 왜 힘들어 하는지를 이해하는 것".
그들의 문제를 해결하면 더 많은 고객을 끌어들이고 서클의 가장자리를 더 확장하게 됨.

- 인스타그램의 인접 사용자 예

Not Signed Up (비가입) → Signed Up (가입)
Signed Up (가입) → Activated (활성)
Casual (가끔 쓰는 일반 사용자) → Core Usage (매일 쓰는 코어 유저)

각 단계별로 더 진행하지 못하고 머무르는 사람들이 있음.

"Bangaly: 인스타그램에선 사용자가 가입후 첫 7일동안 10명 이상의 팔로워가 생기면 활성화될 확률이 65% 이상이었어요."

- Slack 의 인접 사용자 예

Not Signed Up → Signed Up (Acquisition Teams)
Signed Up → Casual (Activation Teams)
Casual → Core Free (Engagement Teams)
Core Free → Monetized (Monetization Teams)

"Fareed: 슬랙에선 사용자가 지난 7일중 3일동안만 활동(3d7)한 경우, 사용자는 서클의 가장자리에 있어서 그 다음주에 50%의 확률로 이탈또는 유지했어요"

** 팀들이 인접 사용자에게 집중하지 않는 이유 **
ㅤ→ 파워 유저에게 집중
ㅤ→ 페르소나는 잘못된 도구
ㅤ→ 모든 스윙에서 홈런을 치려함

- The Gravity Of The Power User
제품 팀들은 보통 자신들 제품의 파워 유저.
제품 팀이 사용하는 것들은 불편한 것들이 바로 눈앞에 보이니 자동으로 개선되는 경향이 있음.
그러나 이것은 자신 또는 친구들을 위해서 만드는 것들이 되어, Ego(자아)에게 도움될 수 있지만 본인 또는 파워 유저를 위해 만드는 것이라면 성장하지 못함.
항상 자신/팀/파워유저와 같은 레벨의 지식,의도,요구사항이 없는 다음 고객들을 위해 만들어야 함.

인접 사용자를 대상으로 작업하려면 "임계 값을 초과" 해야함.
그들이 누구인지 알기 위해 정의하고, 이해하려고 해야함.
이건 직원으로서 보는 것과 크게 다를 수 있으며, 그들이 누구인지 알게되면 공감하고 그들이 무엇을 어려워 하는지 알수 있게 되며, 그러면 뭘 만들어야 할지 알게 됨.

"Andrew: Uber 에서는 많은 직원들이 우버 제품의 파워 유저 였어요. 그들이 제품을 많이 사용했기 때문에 성장에 필요한 것을 알고 있다는 얘기를 많이 했습니다. 하지만 실제로 그것들이 우버에 새로운 고객들을 끌어들인 일은 거의 없었습니다."

- Personas Tend To Be The Wrong Tool
제품의 문제를 해결하고자 할 때, 누구를 대상으로 할 것인가에 대한 질문에 제품팀은 보통 페르소나를 얘기하지만, 이런 이슈들이 있음.

1. 현재 사용자 vs 다음 사용자 : 페르소나는 보통 현재 사용자를 설명하는 경향이 있고, 인접 사용자는 다음 사용자가 누군지 예측하여 성공할 수 있도록 함.
2. 변하지 않음 : 대부분 회사가 페르소나를 만든 뒤엔 몇년간 유지하며 진화시키거나 변경하지 않음. 인접 사용자는 하나의 문제를 해결하고 다음으로 넘어갈 때 마다 계속 진화하고 바뀌어야 함.
3. 너무 넓음 : 페르소나들은 보통 너무 넓어서 액션을 취하기 힘든 경향이 있음. 인접 사용자는 오늘 제품을 사용하는 사람의 가장 끝단에 있는 서브 세그먼트들을 보게 해줌.
4. 사용자 기반이 아님 : 회사는 보통 페르소나를 인구통계학 및 정서적인 요구에 따라 만듦. 이는 많은 어플리케이션에 유용하지만, 인접 사용자들의 진입 장벽을 페르소나 정의에 넣지 않는다면, 인접사용자를 끌어들이는 데에는 도움이 되지 못할 것.

- Trying To Hit A Home Run Every Time
제품 팀은 100개의 안타를 치는 것보다 홈런을 치는 것을 더 크게 평가하는 경향이 있음.
그럴수록 더 큰 마켓의 사용자를 따라서 더 큰 스윙을 하게 됨.
그러면, 새 사용자를 위한 PMF를 맞추기 위해 제품을 만들게 되고, 현재 PMF의 잠재력은 만족시키지 못하게 됨.

기억해야 할 건, 인접 사용자는 여러분의 제품을 오늘 당장 사용하기 위해 노력하는 사용자라는 것.
인접 사용자가 아닌 사람은 전세계의 모든 사람일 수 있음.
비인접 사용자가 더 크겠지만, 그들이 당신의 제품을 수용하기 위한 진입장벽 역시 훨씬 더 큼.
크게만 가려고 하는 회사는, 분명한 단계들을 건너뛰고 현재의 수용 문제를 해결하지 못함.

인접 사용자 문제를 해결하는건 종종 "최적화"로 간주하여, 일부 조직에서는 이를 단기적인 사고(Thinking)라고 무시하지만 그렇지 않음.
이것은 장기적인 로드맵과 빠른 성장을 가능하게 해주는 연속된 실행 훈련이며, 단기 경로가 아닌 장기 경로를 짧게 전환하며 가는 것.

** 인접 사용자가 있다는 건 어떻게 알까

당신이 인접 사용자를 알아내고 도와주기 전까지는 계속 인접으로 남아있음.
"그들은 스스로는 상위 단계로 가지 않습니다"
그들에 대해 열정을 가지고 그들의 눈으로 제품을 보는 법을 배워야 하며,
그들에게 집중하지 않으면 성장이 느려지고, 코호트(동질 집단)가 쇠퇴.

- 코호트 쇠퇴(Cohort Decay) 가 시그널

충분한 사용자가 있다면, 인접 사용자의 영향이 코호트에 나타나기 시작.
각 사용자 단계간의 이동을 나타내는 정량적 지표가 보이는데,
예를 들어, 무료에서 유료사용자로 전환, 가입 사용자에서 활성 사용자로 전환 등.

코호트 기반으로 이런 값들을 보면 각 코호트들 간에 점점 감소하는 걸 볼수 있음.
각 세그먼트에 들어가려는 인접 사용자가 있고, 또한 그 안에서 다음 단계로 넘어가려는 사람들이 있기 때문

** 인접 사용자를 찾고 정의하기

인접 사용자의 눈으로 제품을 보는 첫 단계는
그들이 누구이며, 왜 어려움을 겪고 있는지에 대한 가설을 세우는 것

- 목표는 가시성을 얻는 것. 완벽하진 않아도 됨.

선택 가능한 모든 옵션을 펼쳐 놓고(Landscape), 그중에서 집중할 인접 사용자를 파악해야함.
그중에서 종종 여러개의 군을 선택할 경우가 있기 때문에, 단 한 그룹의 인접사용자만을 아는 것은 충분치 않음
그리고 그게 완벽할 수는 없음. 완벽을 찾다가는 시작도 하지 못할 것.

절차는 다음과 같음.
ㅤ→ 인접 사용자에 대한 가설을 세우고,
ㅤ→ 집중할 대상을 선택하고,
ㅤ→ 팀이 그들의 눈으로 제품을 보게 한 뒤,
ㅤ→ 실험하고 고객과 대화를 통해서 검증 및 학습한 다음,
ㅤ→ 선택할 수 있는 옵션들(Landscape)을 업데이트 한뒤에
ㅤ→ 그 옵션들 중에서 선택.
그리고 이것을 눈덩이 굴리듯 계속 반복.

- 누가 지금 성공적이고 왜 그런지 알기

인접 사용자를 이해하려면, 현재 성공적인 사람들이 누군지, 그들이 왜 성공했는지를 알면 도움이 됨.
왜냐하면 인접 사용자는 그들과 하나 또는 그 이상의 속성이 다를 뿐이기 때문. (전체는 아님)
그 속성들은 확장 벡터(Expansion Vector)를 만들어 냄.

Instacart 를 예로 들어 보면, 75%를 차지하는 건강한 사용자들은

ㅤ→ 여성
ㅤ→ 도시에 사는(Urban)
ㅤ→ 특정 도시에 위치
ㅤ→ 세대주
ㅤ→ 한명 이상의 아이
ㅤ→ 더 풍요롭고 가격에 덜 민감
ㅤ→ 인스타카트 주문 작성에 1시간 정도는 소비할 생각이 있음

이중 일부는 데이터로 부터 알고, 일부는 고객과의 대화를 통해 알게 된 것이고, 일부는 추론한 것.
각각은 다음과 같은 확장 벡터를 만듬.

ㅤ→ 여성 ⇨ 남성
ㅤ→ 도시 ⇨ 교외 ( Suburban )
ㅤ→ 특정 도시 ⇨ 다른 도시들
ㅤ→ 세대주 ⇨ 세대원
ㅤ→ 아이 한명 ⇨ 작은 가정, 커플, 싱글
ㅤ→ 풍요롭고 가격에 덜 민감 ⇨ 가격에 민감
ㅤ→ 주문에 노력 들임 ⇨ 주문에 시간 소비하기 싫음

더 세분화 할수록 일반적으로 더 좋지만, 속성에는 공통적인 카테고리가 있음.
어떤 카테고리가 관련 있고 영향을 주는지는 제품에 따라 다름.

ㅤ→ 성별
ㅤ→ 나이
ㅤ→ 수입
ㅤ→ 위치
ㅤ→ 언어
ㅤ→ 가격 민감도
ㅤ→ 기술 이용도 (Tech Enablement)
ㅤ→ 고객 성숙도
ㅤ→ 기기의 능력
ㅤ→ 제품의 유스케이스
ㅤ→ 역할(Role)
ㅤ→ 회사

- 인접 사용자는 누구인가 ?

제품에 성공적으로 안착한 사람과 그 이유에 대한 가설을 세우면 가능한 인접 사용자 세그먼트를 가정할 수 있음.
위에서 찾은 벡터중 하나 이상을 변경하는 것이 필요.

이런 데이터 분석은 상향식으로 하는게 좋음
사용자와 오래 대화하는 것 보다, 데이터를 통해 각 서클의 가장자리에서 발생하는 일들을 지켜 볼 것

Instacart 에서 데이터를 봤을 때, 현재 성공한 사용자들도 처음엔 주문 작성하는데 시간이 오래걸렸다는 것을 알 수 있었음.
우리의 가설은 현재 우리의 사용자들은 매장에 직접 가는것 대신 장바구니에 제품을 채우는데 몇시간 씩 소비할 의도가 있는 사용자라고 판단.
이를 통해 이런 (시간을 소비할)의도가 없는 첫번째 사용자들에게 제품을 쉽게 찾도록 하는데 집중할 수 있도록 해주었음.

Instagram 에서 처음 데이터를 봤을 때, 엄청난 양의 Organic 웹 트래픽이 쏟아졌지만 그들은 가입하거나 건강한 사용자로 전환되지는 않았음.
처음엔 이유를 몰랐는데, 많은 데이타 탐색을 통해서 그들이 어디서 오는지 왜 웹을 통해서 접근했는지 등과 다른 이유들을 통해서 인접 사용자를 정의하는데 도움이 되었음

- 왜 그들은 인접 사용자 인가 ?

누가 인접 사용자를 아는 것 만으로는 충분하지 않고, 왜 그들이 어려움을 겪는지 알아야 함.
그러기 위해선 "인접 사용자와 공감하는 것"이 정말 중요.

기본적으로 제품팀/개발팀은 고급사용자 이기 때문에 그들이 인접 사용자와 공감을 하기는 매우 어려움.
그들이 왜 어려움을 겪고 있는지에 대해 가설을 세우려면 4가지 기술을 권장.

1. 인접 사용자가 되기
ㅤ개밥먹기. 그들의 조건/환경에서 제품을 경험해보기. 지속적으로 팀이 신규사용자의 흐름을 경험할 수 있도록 하는 것부터 시작.
ㅤ결국엔, 인접 사용자의 경험을 시뮬레이션 할 수 있는 도구를 구축.
ㅤㅤ→ Instagrams 은 인접 사용자가 국제화 되면서 다양한 기기,네트웍속도,언어 등을 경험해보는 방법을 찾아야 했음
ㅤㅤ→ Facebook 은 Air Traffic Control 이라고 부르는 도구를 통해서 네트웍 속도를 제어하여 경험하게 함
ㅤㅤ→ Instacart 는 샌프란시스코와 전혀 다른 캔자스주의 환경을 경험할 수 있는 방법을 찾아야 했음
ㅤ인접사용자 처럼 매일 살아보는 건 눈에 잘 띄지않는 것들을 알게 해 줌.

2. 인접 사용자를 보기
ㅤ사용성 테스트를 통해서 인접 사용자들이 어떻게 제품을 사용하는지 보기
ㅤ가입하고, 활성화하는 동안 뭐를 어려워 하는지 살펴 보고 이야기 하게 만들기

3. 인접 사용자와 대화하기
ㅤ설문조사 또는 직접 대화를 통해서, 인접사용자들이 왜 제품을 이용하고, 어떤 문제를 해결하고, 혹시 그들이 생각중인 다른 대체제 들은 무엇인지 물어보기
ㅤ인스타그램에서 사용자들이 로그아웃 한뒤 다시 로그인 하지 못하는 사람들이 늘어 나는 것을 발견
ㅤㅤ→ 로그아웃을 어렵게 만들 것인가, 재 로그인을 쉽게 만들것인가를 결정해야 할 상황이 옴.
ㅤㅤ→ 의도적으로 로그아웃 하는 사용자와 대화를 통해 알게된 사실
ㅤㅤㅤㅤ1. 선불폰을 쓰고 있어서 데이터 사용량 걱정이 되거나, 가족과 폰을 공유하는 경우가 있음
ㅤㅤㅤㅤ2. 가짜 이메일 주소를 많이 사용. 서양은 이메일 주소가 많지만, 국제적으로는 그렇지 않음. 그냥 문자를 사용
ㅤㅤ→ 이 두가지를 알게 되니 각 유스케이스를 해결할 창의적인 대안들을 찾을 수 있었음.

4. 인접 사용자를 방문하기
ㅤ인접 사용자의 환경에 직접 방문해서, 그들이 어떤 환경에서 제품을 사용하고 그들의 업무흐름, 제약 조건, 요구사항등을 파악

** 인접 사용자 순서 정하기
흔히 하는 가장 큰 실패중 하나는 집중해야 할 인접 사용자의 순서를 잘 못 정하는 것.

1. 인접 사용자는 한개 또는 두개의 속성만 달라야 함
5개의 벡터가 있다고 할때, 5개가 모두 다르다면 잘못된 선택.
그건 모든 스윙마다 홈런을 치려는 것과 같음.

인접 사용자는 하나의 큰 집단을 잡는게 아니라, 미세하게 정의하고, 그 단계를 늘려 가는 것

2. 모든 인접 사용자가 기회는 아님
많은 세그먼트가 있지만, 존재한다고 반드시 그들에게 서비스 해야할 필요는 없음.
핵심은 해당 세그먼트가 제품의 전략적 방향과 일치해야 한다는 것

3. 내부의 문제를 먼저 해결할 것
내부 퍼널에서 보이는 인접 사용자 군을 먼저 선택해야 함.
그들은 이미 의도를 가지고 우리 제품을 사용했지만, 성공하지 못했기 때문에 그들의 문제를 해결하는 것은 단기적인 영향을 미치게 됨.

ㅤElena : B2B 제품의 인접 사용자 우선 순위
ㅤㅤ1. 추가적으로 매출을 낼수 있는 기존 사용자군
ㅤㅤ2. 간접적으로 추가 가치를 만들어 낼수 있는 기존 사용자 군 ( 매출은 안되지만 바이럴효과가 있는 사용자 군처럼)
ㅤㅤ3. 완전히 새로운 인접 사용자

인접 사용자 고려시 장기적으로 그 집단이 성장하는 집단인지도 고려해야함

** 진화하는 인접 사용자 환경

내가 인스타그램에서 일을 시작했을땐, 인접 사용자군은 미국의 35-45세 여성들중에서 페이스북 계정은 있지만, 인스타그램의 가치는 보지 못하는 사람들 이었음.
인스타그램을 떠날때 쯤엔, 자카르타에 있는 3G 안드로이드폰을 선불제로 사용하는 여성이었음.
그 둘사이에 우리가 해결한 인접사용자는 약 8가지 정도의 다른 군들이 있었음.

여러가지 이유로 인접 사용자는 변함

ㅤ1. 새로운 정보들을 얻게 됨 : 인접 사용자에 대한 실험을 했더니 예상 못한 결과가 나왔다던가, 새로운 데이터를 보게 된다던가, 사용자 리서치를 통해서 새로운 가설들이 나온다 던가
ㅤ2. 계속 새로운 사용자들이 늘어남
ㅤ3. 제품에 새로운 가치가 추가됨

이런 환경의 변화에 따라 주목할 점들

ㅤ1. "왜 그런가" 이해하기 위해서는 시간이 필요 : 실험 결과가 나오면 왜 잘되었는지/안되었는지 항상 고민해봐야 함
ㅤ2. 기본적인 사용자 등록, 활성화, 참여, 수익창출에 지속적으로 노력해야 함
ㅤ3. 인접 사용자의 임계값을 지속적으로 넘어가서 확장해야함

"모든 성공적인 제품은 성장률을 유지하기 위해서는 궁극적으로는 핵심 사용자에서 인접 사용자로 초점을 옮겨야 합니다.

인접 사용자 이론은 '사용자 중심'에 대해서 완전히 다른 접근법을 요구합니다.
정적인 페르소나는 제거하고, 제품에 대한 Adoption행동을 가지면서 동적으로 진화하는 페르소나를 기본으로 해야합니다.
성장하는 3-6개월 마다 다음 인접 사용자를 대상으로 그들이 뭘 관심있어 하는지, 어떤 문제를 해결하는지등에 대해서 고민하도록 팀의 방향을 바꿔야 합니다.

이에 성공하면 타겟하는 인접 사용자 군들의 코호트 리텐션, 참여율, 수익 창출등이 개선되게 되며,
점점 더 큰 사용자 기반에서도 계속 성장률을 유지할수 있게 됩니다.
그리고 작은 노력만으로도 다음 인접 사용자를 지속적으로 발견할 수 있게 될 것입니다."

 
시니어 프론트엔드 개발자처럼 크롬 개발자도구 사용하기

크롬 개발자도구에서 유용하지만 흔히 사용되지 않는 팁들입니다.

 
당신이 컴퓨터 학부에서 놓친 학기를 찾아서

대학교 컴퓨터 과학/공학 정규 과정에서 다루지 않지만, 배우고 익숙해야 하는 여러 도구들이 있습니다. 셸(Shell), 에디터, 터미널, 버전 관리, 데이터 다루기, 디버깅 등 자주 사용하지만 어떻게 능숙하게 다룰 수 있는지 배우지 않았던 도구들을 위한 수업이 있습니다.

MIT 컴퓨터 학부 조교들이 (아마도) 신입생을 위해 마련한 수업입니다. MIT에 등록금을 내지 않아도 올해 1월 녹화한 강의는 수업 노트와 함께 영상도 모두 유튜브에서 볼 수 있습니다. 조교가 직접 도구를 쓰는 방법을 보여주면서 진행하는데 자막과 수업 노트를 참조하면 어렵지 않게 따라갈 수 있습니다.

 
CloudFlare, Workers Unbound 서버리스 베타 시작

JavaScript만 지원하던 기존 Workers를 대폭 확장하여 AWS Lambda등과 견줄수 있는 Serverless 플랫폼으로
- 동일 워크로드 기준. 람다 보다 75%, Azure 24%, GCP 52% 정도 저렴
- 콜드스타트 시간 0
- Unthrottled CPU
- 전세계 100+개국 200개 도시에 15초 만에 Deploy
- JavaScript, C, C++, Python, Go, Rust, Scala, Kotlin, COBOL

* 기존 Workers 는 Cloudflare Workers Bundled 로 이름을 바꾸고 게속 지원

시장 점유율은 Akamai > Fastly > Amazon Cloud Front > Cloudflare 정도로 알고 있는데,
기술력도 그렇고, 그걸 외부에 보이는 기술 마케팅 부분은 확실히 뛰어난듯 합니다.
긱뉴스에도 다른 CDN 업체들은 거의 이슈가 안되는데, Cloudflare는 계속 뭔가 올리게 되네요.

Workers가 빠른 것 중에 하나는 Node가 아닌 V8 자체를 그대로 올렸다는 것도 이유중 하나 였는데
그러다 보니 확장성이 많이 떨어져서 일부 기능에만 사용 가능했었는데요.
이렇게 제대로된 서버리스 플랫폼으로 가면 람다와도 경쟁이 가능할 듯 하네요.

 
CloudFlare가 Workers의 콜드 스타트 시간을 0으로 만든 방법

- TLS 첫 네고시에이션 패킷인 ClientHello를 받을때 WarmUp 시작
- Worker 로딩시간이 5ms 밖에 되지 않아서, 클라이언트와 클라우드플레어간 레이턴시 보다도 작으므로 Cold Start Zero를 달성
- 현재는 도메인 Root에 디플로이된 Worker에만 가능. 차후에 하부경로에 대해서도 최적화 예정

CloudFlare, Workers Unbound 서버리스 베타 시작 https://news.hada.io/topic?id=2543
이 기사 소개하면서 콜드 스타트 0 라고 하길래 정말 저게 가능한가 싶었는데 딱 궁금증을 해결해주네요.

아니 콜드 스타트가 20초씩 걸리는 환경들이 엄청많은데 tls 를 이용한 것은 둘째치고 기본적으로 워커 로딩이 5밀리초라는게 더 놀라운데요...

 
Notable - 마크다운 기반 노트 작성 도구

- 오픈소스 마크다운 기반 노트 편집 및 관리 도구
ㅤ→ VS Code가 사용하는 것과 같은 편집기 사용(멀티커서, 미니맵, 구문강조등 내장)
- Txt 파일단위로 저장되어 Lock-In 되지 않음 (Dropbox,Git등에 싱크)
- 다크테마 및 Zen 모드(다른 UI없이 노트화면만 보이는)
- 맥/윈/리눅스 지원. 모바일은 지원예정

깃헙에는 다른 노트 도구들과 비교해놓은 표를 볼 수 있습니다.
https://github.com/notable/notable

가장 비슷한 느낌의 오픈소스는 Joplin 인듯

Joplin - 윈/맥/리눅스/iOS/안드로이드를 지원하는 오픈소스 노트 & ToDo 앱
https://news.hada.io/topic?id=922

https://standardnotes.org/
저는 여러 개 사용하다가 결국 여기 정착했습니다. 마크다운을 지원하진 않아요. 다만 윈/맥/리눅스/iOS/안드로이드 지원하고 동기화가 잘 되고, 데이터가 암호화돼 보관됩니다.
익스포트 임포트는 json기반으로 돼 있어 일반 사용자에게는 조금 불편할 수 있는데 개발자들에게는 괜찮습니다.

Typora

이거는 기능 많이 없고 간단 합니다. 미리 보기 창이 따로 있지 않고 위지윅 방식으로 입력 됩니다. 소스 입력으로 토글 단축키도 있구요.

 
디자인 가이드라인 / 디자인 시스템은 왜 필요한가

구글이 머티리얼 디자인 시스템을 공개한 후, 많은 회사들이 고유 "Design System"을 구축하고 공유
이는 애플,IBM,Shopify,Audi,Uber 등 도메인과 회사 규모를 가리지 않는 트렌드
디자인 시스템이 무엇이고, 왜 필요한지에 대해서 상세히 설명한 시리즈 글(총 8편)

1편 - 디자인 가이드라인/디자인 시스템은 왜 필요한가(현재글)
2편 - 디자인 가이드라인/디자인 시스템의 종류
3편 - 디자인 가이드라인/디자인 시스템의 운영
4편 - 디자인 가이드라인/시스템 작업 프로세스 및 유의할 점
5편 - GUI 디자인 리서치
6편 - 기본 시각 요소 설계 시 알아 두어야 할 것들
7편 - 컴포넌트를 디자인할 때 고려해야 할 것들
8편 - 특수한 목적을 고려한 컴포넌트 디자인하기

 
GPT-3는 어떻게 동작하는가

OpenAI GPT-3의 동작 방식을 시각화와 애니메이션으로 설명
작성자 Jay Alammar는 주로 BERT, Transformer, GPT-2 등의 머신러닝 컨셉들을 알기 쉽게 설명하는 글을 많이 작성합니다. 몇개는 한글로도 번역되어 있습니다.

GPT-3는 아직 작성이 완료되지 않아서 내용이 조금 부족합니다.
The Illustrated GPT-2 를 먼저 보시면 좋을거 같아요.
https://jalammar.github.io/illustrated-gpt2/

BERT와 Transformer 등의 3개 글은 한국어 번역본도 있습니다

The Illustrated BERT,ELMO https://nlpinkorean.github.io/illustrated-bert/
The Illustrated Transformer https://nlpinkorean.github.io/illustrated-transformer/
Visualizing A Neural Machine Translation Model https://nlpinkorean.github.io/visualizing-neural-machine-translation-m…

 
해커뉴스에 올라오는 책 추천만 모아서 메일로 보내주는 뉴스레터

Hacker News 에 올라오는 추천 책들만 모아 이메일로 보내주는 뉴스레터 서비스가 있네요.
- Weekly 업데이트
- 프로그래밍 언어별 구분
- 댓글 1100만개를 분석해서 나온 Top 목록
- 창업가/투자가들이 추천하는 목록

개발자를 위한 책뿐만 아니라 인지과학과 심리학을 다룬 서적도 목록에 있네요. 정보 고맙습니다.

 
Can I Use 새로운 베타 웹사이트 공개

- 웹 브라우저별 호환성 체크 사이트
- 다크모드 지원 및 비주얼 접근성 강화
- URL이 보기 좋게 변경 ( /#feat=flexbox → /flexbox)
- 확인할 브라우저들만 통합 설정 지원
- 각 피쳐를 Saved List에 저장 가능

 
TinyPilot: $100 보다 저렴한 KVM Over IP

TinyPilot은 라즈베리파이 4와 USB HDMI 캡쳐 동글로 만든 간단한 KVM Over IP 장치입니다.

제작자는 자신의 홈 서버에 가끔 쓸 용도로 KVM Over IP 장비를 찾아봤는데,
iDRAC과 같은 기존 서버용 KVM Over IP 장치가 너무 비싸서 직접 만들었다고 합니다.

지연시간도 약 200ms 정도라고 하니, 간단한 홈 서버에서 사용한 장비로는 충분해 보입니다.

프로젝트 사이트에서 이미 완성된 장비를 구매하여 개발자에게 후원할 수 있고,
사용한 하드웨어 스펙과 소프트웨어를 모두 공개하고 있으므로 직접 제작도 가능합니다.

소스 코드: https://github.com/mtlynch/tinypilot
프로젝트 페이지: https://tinypilotkvm.com/

SSH나 RDP로는 OS 부팅 전에 사용할 수 없으니, BIOS 설정 변경 등을 할 수 없습니다.
KVM Over IP로는 BIOS 설정 변경, 전원 버튼 조작이 가능합니다.

 
Blip - 간단한 Geolocation 서버

- Google App Engine 을 이용해서 접속한 사용자의 위치 정보를 가져오는 API 서버
- CORS 세팅으로 클라이언트에서 간단히 이용 가능
- 접속 사용자의 도시/지역/국가/위도/경도 정보를 JSON으로 리턴
- Go 로 작성된 오픈소스

보통 회사에서 접속자의 Geolocation 정보를 알기 위해 MaxMind 를 사거나 하는데,
그걸 대신하거나 MixMind 가 무료로 제공하는 GeoLite2 를 사용하는 방식들도 있는데요.

위 Blip은 오픈소스고, GAE의 값을 이용하기 때문에 거의 무료티어 만으로 사용 가능합니다.

CDN인 CloudFlare 가 제공 하는 위치 데이터를 이용하는 법도 있습니다.
- http://ifconfig.io/ 좀 더 다양한 값을 리턴해 줍니다. 소스는 https://github.com/georgyo/ifconfig.io 에 Go 코드
- https://github.com/jlxw/geoip CloudFlare + Heroku. JavaScript 코드
- CloudFlare Worker 로 직접 만들기 https://maxkostinevich.com/blog/serverless-geolocation/

 
개발자 그들이 사는 세상 - GitHub

What YouTube is to content creators or Instagram is to influencers, GitHub is to developers around the world.

유튜브와 인스타그램이 콘텐츠 크리에이터들과 인싸들이 사는 세상이듯, 깃헙은 개발자가 사는 세상입니다.

코드 저장소에서 시작해서 점점 개발자의 소셜 플랫폼으로 옮겨가고 있는 깃헙의 모습을 소개한 인도 매체 기사입니다.

주목할만한 깃헙 소셜 플랫폼 애드온
- 이모지를 활용한 프로필 상태 표시
- 개인 경력을 소개할 수 있는 README 파일
- 대화와 토론을 위한 인터페이스 추가 (경쟁업체 깃랩이 서비스하는 Gitter와 유사한 기능)

인도 개발자들이 겪은 소소한 일화도 소개
- "깃헙에서는 젠더 이슈 때문에 어려움을 겪은 적이 없어요."
- "몇 개월 동안 다른 소셜 플랫폼에서 소식이 끊긴 친구가 깃헙에 커밋을 남긴 것을 보고 안심했어요."

 
Awesome GPT-3

OpenAI의 GPT-3 관련 기사 및 데모들 모음
실제 코드 보다는 동작 영상을 올린 트위터 링크들이 많지만 굉장히 다양한 예제들을 보실 수 있습니다.
어찌보면 단순한 Text In, Text Out 인 GPT-3 API로 이런 것도 할수 있구나 라고 생각하고 보시면 될 듯
- App and layout tools
- Search and data analysis
- Program generation and analysis
- Text generation
- Content creation
- General reasoning
- Articles
- Products

 
Evernote 대체제 75종 리뷰

에버노트의 역사부터 강점/약점들을 정리한 뒤 다양한 에버노트 대용품들을 총망라
제품별 화면캡쳐,설명,주요 기능 들로 정리되어 있어서 자신에 맞는 것들을 찾으면 될 듯

Bear, OneNote, CodeGiant, DEVONthink, Notion, Trello, Workflowy, Joplin,
Noteshelf, Nebo, Roam, Obsidian, Remnote, WizNote, Standard Notes, ClickUp,
Google Keep, DropBox Paper, ProofHub, Simplenote, Apple Notes, Boostnote,
Tettra, CintaNotes, Notejoy, Quip, Box Notes, Todoist, Turtl, GoodNotes,
Squid Notes, Zotero, Day One, Zoho Notebook, WhizFolders, NoteLedge, Zim,
Nimbus Note, CherryTree, Paperwork, Notezilla, TagSpaces, Dynalist, Leanote,
Polar, QOwnNotes, Zenkit, SynapBook, Org-Mode, WeDo, TiddlyWiki, Supernotes,
Checkvist, Nuclino, Omni-Notes, Taskade, Notability, Cryptee, Slite, Notable,
ColorNote, Cronycle, Laverna, Falcon, Scrivener, Airstory, Lumhaa, Zettlr, Hugo,
FSNotes App, SilentNotes, Amplenote, GigaNotes, Typora

이렇게나 많은줄은 몰랐네요. (ToDo 관련 기능들까지 들어가서 그런것 같긴 합니다만)
박성서님이 만드신 ColorNote https://www.colornote.com/ 가 있는게 반가웠구요.

어제 올린 "Notable - 마크다운 기반 노트 작성 도구" https://news.hada.io/topic?id=2534
링크에 많은 분들이 댓글 달아주셨는데, 거기서 얘기된 것들이 모두 들어 있네요

위 리스트중 긱뉴스에서도 소개드렸던 것들

Joplin - 윈/맥/리눅스/iOS/안드로이드를 지원하는 오픈소스 노트 & ToDo 앱 https://news.hada.io/topic?id=922
내가 노트툴 Roam 을 사랑하는 이유와 사용법 - https://news.hada.io/topic?id=1349
Zettlr - 제텔카스텐을 위한 마크다운 편집기 - https://news.hada.io/topic?id=2393
Obsidian - MarkDown 기반 데스크탑 지식정리 도구(Knowledge Base) https://news.hada.io/topic?id=2169

 
MS Azure Well-Architected 프레임워크

기업들이 클라우드 애플리케이션을 구축하기 위한 올바른 방향을 알려주고, 그 과정을 안내하는 프레임 워크
비용 관리, 운영 효율성, 성능 효율성, 안정성, 보안 : 5가지 아키텍처 모범 사례로 구성

- Azure Architecture Center : 프레임웤, 레퍼런스 자료 및 예제
- MS Assessments(평가) : Azure Well-Architected Review 를 통한 셀프 평가
- MS Learn : "Microsoft Azure 잘 설계된 프레임워크를 사용하여 우수한 솔루션 구축" 강의(6시간 분량)
- Azure Advisor 를 통해 5가지 분야별 가이드 및 추천

근데 이 제목 어디서 본거 같죠?
AWS Well-Architected 프레임워크 https://news.hada.io/topic?id=2435

MS가 아마존 꺼를 똑같이 가져다 썼네요. 근데 이왕 따라하려면 아마존처럼 보기좋게 백서같은 거로 내주지..
(저도 첫줄 설명은 아마존꺼를 가져왔습니다. 내 시간을 아껴줘서 고마워 MS )

 
GraphQL 기반 풀 스택 스타터킷

새 Node.JS 프로젝트 시작시 편하게 사용할 수 있는 전체 스택을 만들어둔 키트
- 전체 TypeScript 기반
- GraphQL : Apollo
- CI : GitHub Actions
- Test : Jest
- DB : PostgreSQL + Prisma ORM
- Web : React with react-app-rewired, Material UI

 
Rainbowhunt - 비내리는 창문 시뮬레이션과 빗소리 듣기

- WebGL을 이용하여 창문에 떨어지는 빗방울을 표현
- 자연의 빗소리를 종류 별로 상세 설정 가능
ㅤ→ 가랑비, 창문을 때리는 빗방울, 비바람, 땅에 빗방울 튀는 소리, 천둥소리
- 비오는 날 / 개인 날, 낮 / 밤 선택 가능
- 빗방울 양 조정 가능
- UI 안보이기 버튼

UI 다 끄는 옵션 선택하고 모니터에 크게 띄우니 느낌 좋네요

넷플릭스의 벽난로 4K 급인듯
https://www.netflix.com/title/80092839

 
Python을 Rust로 변환하며 Rust배우기

LeetCode*의 Unique Paths 문제를 해결한 Python 코드를
Rust코드로 하나 하나 바꿔가며 Rust 언어를 배워보는 글

- 기본 자료형, 함수, 구문, 표현식, 변수, 매크로, if문, 함수호출, Range, 배열/튜플/벡터, as, Struct 와 Impl, Trait

* LeetCode는 기술면접에 나온 문제들이 많이 등록된 사이트로,
알고리즘 학습 및 개발언어 스킬을 향상 하고픈 사람들이 많이 이용합니다.

본문과는 큰 연관은 없지만, 기술면접을 위해서 LeetCode 가봐야지! 하는 분들을 한번 읽어 보실만한 글
Leetcode의 Moore의 법칙 https://brunch.co.kr/@ee-er/4

 
AWS와 PHP가 협업하여 Arm64용 PHP-7.4의 속도 개선

EC2 M6g 인스턴스는 아마존의 ARM기반 CPU Graviton2를 사용 중
ㅤ→ 비슷한 M5 인스턴스에 비해 약 40% 저렴
기존에 Zend Optimizer가 ARM에서는 동작 안했는데, AWS가 ARM64용 구현체에 함수를 추가하여 M6g상에서 PHP-7.4가 7.3에 비해 37%의 속도 향상
워드프레스를 테스트 했을때 M6g vs. M5 에서 약 34% 정도 성능/가격이 좋게 나옴

내년에 나올 PHP-8 에서는 Arm64용 개선이 더 들어갈 예정. (JIT컴파일러 등도 동작하게)

AWS가 이렇게 ARM기반 서버에 신경을 써준다면, 똑같이 ARM기반인 애플 실리콘쪽에도 좋게 작용하지 않을까 생각이 됩니다.

Intel: 이러면 서버도 나가린데..

 
Stripe의 개발자 Cult 만들기

개발자들이 좋아하는 API 회사들 중 항상 선두에 얘기되는 Stripe
온라인 결제 업체인 그들의 미션은 "인터넷의 GDP 늘리기"
ㅤ→ 미국 성인 96%가 사용하고, 하루에 2.5억회의 API 처리

* Stripe의 성공 비결
1. 고객 집착
ㅤ→ 초기부터 사용자 경험에 대한 집착이 회사의 핵심
ㅤ→ 대쉬보드 모든 페이지 우상단에는 "Feedback about this page?" 버튼 : 끊임없는 사용자 UX 개선
2. 개발자 최우선
ㅤ→ 개발자가 Stripe를 사용할때 특별하고, 마치 마법처럼 느껴지게 하는게 성공의 주요 열쇠
3. 개발자와 공감
ㅤ→ 결제 경험을 개선하고 누구나 쉽게 쓸수 있게 개발자들과 교감하고 공감함
4. 디자인
ㅤ→ 기능을 중요하게 생각하면서도 아름다움을 소중히 여기고 강조

개발자 대상의 제품을 만드는 회사라면, 내 제품을 사용하는 개발자들에 대해 집착해야 함
- 개발자들이 여유시간에 당신의 제품을 가지고 뭔가를 만들어 보고 싶게 만들고
- 당신 제품에 대한 Cult를 시작하고 싶게 만들고
- 당신의 가장 큰 팬으로 만들어라

* 여기서 Cult 는 한국식으로 "골수팬층" 정도로 생각하면 되지 않을까 싶네요

Stripe는 아직 상장전이고 현재 회사 가치는 올 4월 투자 기준 $36B (44조원) 정도 됩니다.

온라인 결제 업체중 상장된 회사중에서는 Adyen 이라는 네덜란드 회사가 꽤 유명합니다 ( 한국에선 물론 아니겠지만요.. )
시총이 $40B(47조원)이구요. 2018년에 이베이가 주 결제 파트너를 Paypal에서 아디옌으로 바꾸겠다고 발표를 했고, 2021년에 교체가 완료될 예정입니다.(2023년까지는 페이팔도 사용은 가능합니다)

재미난건
- Stripe 는 Developer First
- Adyen 은 Merchants First
로 약간은 다른 노선을 취하고 있다는 것.

스타트업이나 소형 거래에서는 Stripe가 우위를 차지하고 있지만, 큰 규모의 판매자에서는 Adyen이 더 우위를 보이는 것 같은데 어떤식으로 경쟁하며 발전해 나갈지 지켜보는 것도 흥미로울듯 합니다.

 
GitHub Public Roadmap

깃헙이 자신들의 제품 개발 로드맵을 Repo에 프로젝트로 정리해서 공개
- 앞으로 3분기와 그 이후의 Future 프로젝트로 분리
- Alpha, Beta, GA + in design / exploring 단계로 구분
- 기능별, 제품별 태그를 통해서 각 기능이 어떻게 개발되고 어떤 상태인지를 볼 수 있게

깃헙이 이젠 규모가 굉장히 커져서 이렇게 전체 로드맵을 외부에 공개하는게 쉽지 않을텐데
그들만이 할 수 있는 재미난 시도라고 보여집니다.

 
deno 첫 외주 후기

swc 개발자 강동윤님이 deno팀에서 연락받아서 외주를 진행한 후기
100% 재택으로 진행되는 시급제 외주 방식으로 계약 했다고

* swc는 rust로 개발된 TypeScript/JavaScript 컴파일러

deno에서 swc 의 crate 중 swc_ecma_transforms 를 쓰고 싶은데 stable rustc 에서 컴파일 돼야 쓸 수 있으니 그렇게 바꾸는 작업을 요청

 
Release - 커맨드 하나로 Changelogs 생성하기

- 지난 릴리즈 이후의 모든 변경(커밋)들을 묶어서 GitHub Release를 생성하여 기록해주는 도구
- release [type] 명령 으로 SemVer 기준의 인자 전달
ㅤ→ major : 호환되지 않는 API 변경
ㅤ→ minor : 하위 호환되는 새 기능 추가
ㅤ→ patch : 하위 호환되는 버그 픽스
ㅤ→ pre : 프리 릴리즈 (beta,canary 등 추가 suffix 가능)
- commit 메시지에 (patch) 등을 넣으면 자동 처리. (ignore) 는 무시
- Custom Hook을 지원해서 프로젝트 루트에 release.js 가 있으면 기록전에 모든 릴리즈노트와 커밋들을 인자로 넘겨주는 함수 호출해줌. 받아서 마음대로 수정가능

 
React 와 Vue 로 똑같은 To Do 앱을 만들어 보았다 [2020]

2018년에 React 와 Vue 를 이용해서 To Do앱을 만든 걸 비교한 첫 글을 올린 뒤,
2019년엔 React Hooks가 들어간 버전으로 업데이트
2020년엔 Vue 3와 Composition API 를 적용해서 업데이트한 세번째 글

React/Vue 한 쪽에 익숙한 사람이 다른쪽을 볼 때 보기 좋음
각각의 코드는 깃헙에 공개

 
High Output Founders' Library

창업자를 위한 실용적/전술적인 조언 및 가이드들 75+개 모음
(주로 얼리스테이지/프리시딩~시리즈B 대상)
8가지 카테고리로 분류 : 채용 / IR / 펀드레이징 / 자기관리 / 사람관리 / 내부 미팅 / 회사와 문화, 핵심가치 / 제품