마루 11층 루프탑을 처음 오픈한 7월 Open Office Hours!

디스콰이엇은 매달 말 매쉬업엔젤스와 함께 Open Office Hours를 열고 있습니다. 첫 세션이었던 6월 OOH날에는 비가 와서 아쉽게도 루프탑 폴딩도어를 개방하지 못했는데요, 이번 8월 OOH에서 (아마도)마루 360 오픈 이래 최초로 루프탑을 열고 행사를 진행했습니다!

해가 떠 있는 낮의 루프탑은 폴딩도어를 열면 이런 느낌이에요. 아직 여름이라 낮에는 루프탑을 쓰기에는 조금 덥더라고요.

이번에는 매쉬업엔젤스에서 진토닉을 준비해 주셨습니다!! 지난번과 같이 피자와 맥주는 기본이고요🍕 매쉬업 심사역님이 만들어 주시는 진토닉이 드시고 싶으시면 곧 공지될 8월 OOH에 신청해 주세요!

Open Office Hours는 매쉬업엔젤스 팀과 청중 앞에서 서비스를 소개하고, 캐주얼하게 질의응답하는 자리인데요, 이날은 전세계 500만 사용자를 가진 필기 앱 'Flexcil'과 전자책 플랫폼 'Sconn'의 메이커, @권정구 대표님께서 먼저 서비스를 소개해 주셨습니다.

Sconn 프로덕트 페이지 보러 가기

이어서 실시간 지역 소셜 플랫폼 'ROOMER'의 메이커, @Leonard Kim 대표님께서 서비스를 소개해 주셨습니다. 해가 뉘엿뉘엿 넘어가는 시점이라 한층 깊어진 분위기에서 소개를 듣고, Q&A에 참여할 수 있었어요.

ROOMER 프로덕트 페이지 보러가기

네트워킹 시간은 외부와 내부를 구분하던 폴딩 도어를 완전히 열고, 스탠딩 형식으로 피자와 맥주를 먹으며 진행했는데요, 라운지 파티를 정말 좋아하는 저에게는 가만히 있기만 해도 신나는 시간이었어요.

서비스에 대해 발표해주신 메이커분들과 맥주를 마시며 Q&A 시간에 못다한 질문과 의견을 나누시기도 하고, 미리 댓글로 작성해주신 '나누고 싶은 대화'에 기반해서 메이커분들을 찾아가 소통한 의미있는 시간이었답니다!

늘 메이커들의 프로덕트/비즈니스/투자유치에 대한 좋은 대화 모더레이팅해주시는 매쉬업엔젤스의 엔젤😊 @성윤모 , @박선영 , @도건희 심사역님 고생 많으십니다 :)

8월 Open Office Hours는 참가자 분들이 남겨주신 피드백을 바탕으로 더 좋은 이벤트로 찾아뵙도록 하겠습니다! 곧 올라올 공지를 확인해 주세요!

02. 무슨 제품을 만들까 (문제편)

URURL은 사이드프로젝트를 하고 싶은 사람들이 모여 만든 서비스입니다.

팀원들끼리 각자 느끼고 있던 문제점을 하나씩 공유하다가 다같이 고개를 끄덕인 공통적인 문제점이 있었습니다. 바로 읽고 싶은 URL은 많은데 정리하기 어렵고, 정리를 해놓더라도 다시 찾아 읽지 않는다는 것이었어요.

비단 저희만의 문제일지 궁금해져서 리서치를 시작해보았고 생각보다 많은 분들이 그런 니즈가 있고, 이 니즈를 해결해줄 서비스도 여럿 있다는 것을 알게되었습니다.

두번째 글에서는 저희팀의 문제 정의, 타겟 정의, 이용자 니즈 확인(데스크 리서치, 이용자경험조사) 단계에 대해서 담았습니다.

--------------------------------------------------------------

❈ 사이드 프로젝트(URURL)를 진행하면서 경험하는 내용들을 기록한 글입니다. ​

​

기획자들끼리 머리를 맞댔다. 사이드 프로젝트는 하고 싶은데 과연 어떤 프로덕트를 만들어야 할까? 보통 거창한 무언가를 만들어야 한다고 생각하겠지만, 우리는 우리에게 필요한 것을 만들기로 했다. 가장 확실한 니즈가 있는 프로덕트를 만드는 것이 최선이라고 판단했기 때문이다.

01. 해결하고 싶은 문제 찾기

​각자 실생활에서 필요하다고 느낀 것을 말해보고 거기에 아이디어를 덧붙여보기로 했다. 다양한 의견이 나왔는데 그중에서도 읽고 싶은 URL은 많은데 정리하기 어렵고, 정리를 해놓더라도 다시 찾아 읽지 않는다는 문제점이 공통적이었다. 덧붙여 다른 일잘러들은 무슨 콘텐츠를 읽고 어떤 인사이트를 얻는지 궁금해했다. 우리 사이트에서 기획자(PM/PO)가 모여 커뮤니티를 형성하고 그 안에서 집단지성을 뽐내면 어떨까 까지도 상상했다. 논의를 하다 보니 URL을 쉽게 저장, 관리하며 인사이트를 얻을 수 있는 사이트가 있으면 좋겠다는 의견으로 모아졌다. 

.

.

.

자세한 이야기는 아래 링크에서 확인 가능합니다 :)

https://blog.naver.com/pengddori/222837805811

Social+ 회사의 6가지 수익화 방법

개인화된 콘텐츠에 대한 VIP 멤버십 가입

• 두 가지 방법으로 수행할 수 있다.
• 플랫폼 또는 특정 작성자에 대한 구독
• 구독을 통해 사용자는 참여 수준에 따라 다른 항목을 선택할 수 있다.
• 브랜드 스폰서에 대한 의존도를 줄이고 크리에이터의 진정성을 높인다.
• 단점은 콘텐츠가 더 적은 사람들에게 도달한다는 것이다.

커머스: 크리에이터의 제품 판매를 돕는 플랫폼

• 핀터레스트는 이 분야를 개척했지만, 틱톡과 인스타그램도 이제 '공간'으로 옮겨가고 있다.
• 두 분야에 대한 인센티브는 크리에이터가 제품이 출시되는 분야의 전문가로 간주될 때 조정된다.

가상 라이브 경험

• 일반적으로 특정 라이브 이벤트와 관련된 일회성 구매
• 복싱의 PPV(Pay-per-view) 모델
• 코로나19로 가속화된 비교적 새로운 매체

인터넷 기반 유료 커뮤니티

• 이러한 회사는 사용자들이 공통의 관심사를 가진 사람들과 상호작용할 수 있도록 한다.
• 피트니스, 정신건강, 진로지도 등을 위해 할 수 있다.
• 플랫폼은 중매인 역할을 하며 사용자는 특정 분야에서 사람들이 추구하는 커뮤니티이다.

디지털 굿즈 및 앱 내 구매

• 중국 및 비디오 게임에서 인기 있음
• 인기 게임인 어뮤즈(Ambody Us)는 무료 게임임에도 불구하고 캐릭터를 개인화하는데 사용한다.
• 게임 외에도 미국에서는 거의 채택되지 않았다.

팁, 도네이션 및 소액 거래

• 라이브스트림 팁은 중국에서 100억 달러 규모의 산업이 되었다.
• Twitch는 미국에서 비디오 게임 스트리머에 이것을 사용한다.
• 이에 대한 단점은 팁을 주는 것이 일관성 없는 수익의 흐름이 될 수 있다는 것이다.

진짜 동작하는 한글 웹폰트 최적화하기

돌아보면 한글 웹폰트 최적화는 시작해서는 안되는 작업이였습니다.

서비스에 큰 도움이 되지도 않는데, 그 깜박거림과 짧은 순간의 폰트 변경을 없애보겠다는 오기 때문에 거의 일주일을 썻네요.

이렇게라도 남겨야 덜 억울할것 같아서 기록해봅니다.

한달전쯤 운영중인 사이트의 웹폰트 최적화가 전혀 동작하지 않는다는 것을 깨달았습니다. 가끔 실패하겠지 뭐 생각했었는데, 첫번째 방문, 첫번째 로딩에서는 거의 100% 폰트가 바로 적용되지 않았습니다.

'한글 폰트 최적화' 검색해서 font-display:optional 도 적용했는데, 왜그러지? 내가 뭘 잘못했나?

그래서, 한글 웹폰트가 잘 적용된 모범사례를 찾기 시작했습니다.

한글웹폰트 모법사례찾기 에 보시면 자세한 내용을 볼 수 있습니다.

결론적으로, 꿀꿀한 충격을 받았습니다. 제가 본 큰 회사들은 font-display:optional를 쓰고 있지 않았습니다. 이 최적화는 한글에 맞지 않다는 것을 알았습니다. 영어 subset 폰트정도로 작은 크기나 나 되야 쓸수 있는거지, 한글웹폰트에는 어림도 없었던거죠. 그리고, 한글사이트에서 유독 많이 보이는 첫화면 애니메이션이 혹시 웹폰트 최적화 포기를 숨기기 위한 꼼수가 아닌가 의심이 생겼습니다. 하여간, 제가 찾아본 어떤 한글 사이트에서도 첫로딩에 웹폰트를 제대로 표시하는 곳을 찾지 못했습니다. 괜히 애니메이션이 있거나, 깜박이거나, 홈페이지와 폰트가 따로 따로 등장하는 꼬진 모습을 보여주고 있었습니다.

다른곳에서 한 것을 따라하려는 것을 포기하고, 그냥 제가 해보기로 했습니다.

검색해서 찾은 것은 subset 폰트를 극단적으로 줄일 수도 있다는 가능성이였습니다. 한페이지에 등장하는 글자들로만 이루어진 폰트를 만드는 방식인데, 희망을 가지고 했지만, 실패했습니다. 여전히 font-display:optional을 적용하기에는 더 줄여야 했습니다.

그래서, 첫화면에 보이는 부분만 뽑아서 subset폰트를 만들었고, (10kb수준) font-display:optional 이 적용될 수 있는 수준으로 빠르게 로딩되었습니다. 이렇게 되면, 최신 웹폰트 최적화 기술을 사용할 수 있습니다. preload link 와 display:optional 두개만 있으면 됩니다.

핵심만 설명드린거고, 실제 제품에 적용하려면 몇가지 고민이 더 되어야 합니다.

전체 작업과정과 고려사항은 여기서 (꼼수로 완성한 한글 웹폰트 최적화) 보실 수 있습니다.

작업 결과는 file.kiwi 에서 보실수 있습니다. 예전에는 대부분 첫로딩에서 이상했지만, 이제는 3g 모바일 이 아니라면 대부분 첫로딩에서도 웹폰트를 잘 표시합니다.

한글 폰트최적화는 국내업계에서 할 수 있는 게 별로 없는 분야입니다. 구글이 뭐해줄지 바라만 보고 있는 상황이죠. 구글은 영어중심으로 계속 서비스를 만들테니.. 한 몇년은 이런 꼼수를 쓰면서 버터야 할것입니다. 첫화면 애니메이션이 많은 국내사이트를 보면, ie시절 폰트가독성이 떨어져서 12pt만 사용했었다는 전설이 떠오르네요.

팔로우 기능 개발 노트 - Feed

여러분들도 알다시피 디스콰이엇에서 최근에 팔로우 기능을 배포하였어요!

이번 기회에 팔로우 기능을 같이 개발하면서 고민해 보았던 부분들, 그리고 이번에 사용 되었던 Redis 의 향후 활용 계획등을 정리해 보려고 합니다. 이 글의 경우 "피드"에 대해서 더 중점적으로 얘기해 보려고 해요.

Motivation

저희는 팔로우 기능에 앞서 좀 더 개인화 된 피드에 대해 고민해 보았어요. 유저별로 더 관심이 갈 만한 포스트들을 피드 상단에 정렬해 놓는다 던지, 우선적으로 보고싶은 메이커의 포스트를 위에 놓는다 던지, 혹은 보고 싶지 않은 유형의 글들을 필터링 할수 있게끔 한다 던지. 정말 많은 기능들이 있었습니다. 하지만 논의 끝에 팔로우 기능을 구현 한다면 활발하게 활동하는 메이커들에 대한 보상체계를 만듦과 동시에 관심있는 메이커의 포스트들만 정리해서 볼수 있는 피드를 일차적으로 구성할수 있다고 판단했어요.

저희가 얘기해 보면서 나온 피드의 종류는 크게 2가지가 있었던것 같아요:

1. 팔로잉 피드
2. 추천 피드

추천 피드의 경우 흔히 LinkedIn 이나 Facebook 과 같은 플랫폼에서 활용하는 특정 score 에 기반한 포스트 정렬을 생각했어요. 이러한 추천 피드의 경우 먼저 노출되어야 할 포스트가 유저의 활동에 따라 실시간으로 변할 뿐만 아니라 동시 다발적으로 일어나는 유저간의 interaction 에 따라서 정말 많은 포스트들의 respective score 가 바뀌는게 특징이죠.

근데 다양한 피드를 조회 하려고 할때 마다 DB 에 있는 포스트들을 동적으로 정렬한다는 것은 너무나도 비효율적이였어요. 특히 아직 배포하지 않은 추천 피드의 경우 유저의 활동에 따라서 포스트의 relevance score 가 자주 바뀌게 되는데 그런 연산을 쿼리 시점에서 하는게 더더욱 비효율적이였죠.

Redis & ZSET

그래서 저희는 유저 별로 사전에 정렬된 피드를 가지고 있는게 좋을거 같다고 생각했고, 큰 소셜 플랫폼들에서 활용 하는 push 모델의 피드 (Fan-out-on-write) 와 pull 모델의 피드 (Fan-out-on-load) 를 둘다 수용할수 있는 Redis 기반의 피드 구현을 생각해 보았어요.

기존의 PostgreSQL 만으로도 충분히 피드 구현이 가능하지만, 추후에 실시간으로 업데이트가 되는 피드의 경우 Redis 에서 제공하는 ZSET 이 너무나도 적합하다는 생각이 들었어요. ZSET 의 경우 KEY , VALUE , 그리고 SCORE 라는 필드를 활용하는데 각 KEY 에 해당하는 SET 마다 SCORE 에 따라서 알아서 정렬이 되게끔 설계되어 있어요 (흔히 게임 플랫폼들에서 플레이어들의 랭킹을 관리할때 Redis 의 ZSET 을 많이 활용 한다고 해요!).

ZSET 으로 피드를 관리 하기 위한 커맨드는 아래 3개만으로 충분합니다:

클라이언트에서 특정 feedType 을 요청 하게 될 경우 ZRANGE 혹은 ZREVRANGE 로 해당 피드를

O(log(n) + n) 의 시간으로 불러올수 있게 됩니다! 필요의 경우 ZRANGEBYSCORE 같은 커맨드로 특정 SCORE 범위에 있는 포스트들만 불러올수도 있죠.

ElastiCache 환경

Redis 가 in-memory 데이터베이스이다 보니까 정말 빠르다는 장점이 있지만, 그만큼 관리 포인트들도 적지 않아요. Redis의 한 “클러스터” 안에는 master node 들과 이들의 복제본인 replica node 들이 존재해요. 마스터 노드들 은 key들을 분산해서 저장하기 위해 서로 소통을 해야되고, master node 에 문제가 생겼을때 replica node 가 데이터 베이스 복원을 도와줘야하기에 master 와 replica 간의 통신도 필요하죠.

하지만, 클러스터가 운영되는 네트워크에 문제가 생기게 되었을때 network partition 으로 인해 클러스터 안의 노드들이 서로 소통을 하지 못하는 문제가 생기게 되는데, 이때 redis 는 처음 설정해 놓은 master node 만큼을 유지하려고 replica node 를 master node 로 “승진” 시키는 작업을 거치게 되요. 이때 나올수 있는 문제가 split-brain problem 이라는 문제에요!

Elasticache 를 통해 Redis 를 운영하게 되면 위에서 일어나는 네트워크 문제나, key re-distribution에 더 잘 대응할수 있고, 저희의 경우 이미 대부분의 인프라가 AWS 클라우드를 통해서 운영되고 있어서 Elasticache 를 통해 feed 를 위한 Redis를 호스팅 하게 되었어요.

Elasticache를 통해 개발 환경을 만들 경우 주의 해야될 점이 있어요! 바로 Elasticache가 돌아가는 VPC 안의 리소스들만 Redis 의 configuration endpoint 에 접속할수 있다는 점이죠. 저희의 경우 아직은 로컬 환경에서의 개발이 필요했어서 “bastion server” 를 통해서 위 문제를 해결했어요:

직접적으로 Redis cluster 와 통신을 할수 없기에, internet gateway 와 연결된 EC2 를 활용한 port forwarding 을 통해 개발 환경을 구축 할수 있었어요. Production의 경우 저희 서버가 Elasticache 와 같은 VPC 에 해당하는 subnet 에서 운영되고 있기에 별다른 configuration이 필요하진 않았어요.

대략적으로 저희 피드 구현에 대한 생각과 개발 내용들을 얕게나마 정리해 보았는데, Build-In-Public 을 지향하는 팀으로써 앞으로도 개발적인 내용을 더 많이 공유해 볼까 해요. 지금 현재는 팔로잉 하는 메이커들의 포스트만 볼수 있지만 앞으로는 더 다양한 피드들을 제공함에 있어서도 Redis를 적극 활용할거 같습니다!

다른 메이커 분들도 프로덕트를 만들면서 고민하셨던 개발적인 요소들을 많이많이 공유해 주시길 기대할게요!

5개의 사업 중 성공한 사업과 실패한 사업의 차이 [박재욱] 1편

> 제일 중요하게 생각는게 문제를 어떻게 정의하느냐

실패했던 제품들 = 문제정의에 실패했던 제품들

이 제품이 시장에서 어떤 가치를 지니는지

사용자들이 왜 써야되는지에 대해서 명확하고 뾰족하게 제시하지 못했음

문제 정의만 잘 되고 나면 그 솔루션은 다양한 방식으로 정답을 찾아야 됨

시장에 내놓아봐야 아는 거긴 하지만

잘 정의된 문제는 솔루션을 만나게 되었을 때 폭발력이 굉장히 크고

이를 통해 성장할 가능성이 많이 열림

진짜 이 문제점은 나 이외에도 굉장히 많은 다수가 고통받고 힘들어하는 문제다..

여기서부터 좋은 제품이 나옴

> 뉴스 큐레이션 서비스가 실패한 이유

실제로 모바일로 가속화되는 시점

언론사들이 자신들의 헤게모니를 가져오려는 노력

→ 실제로 콘텐츠를 수급받는 게 굉장히 어려웠음

시장에 대한 문제정의를 함에 있어서 소비자 입장에서 문제정의를 잘 하는 게 중요하기도 한데요

그걸 결국 제공해줘야 하는 공급자가 있어야 한다고 하면 콘텐츠 공급자들이 헤게모니 상에서 어떤 생각들을 갖고 있는지 이것에 대한 부분을 잘 보는 것이 참 중요하다고 생각합니다.

> 제품이 잘 될 때 심정

항상 어떤 제품이 잘 되기 시작하면

내가 생각했던 것보다 훨씬 잘 됨

성장 속도만큼 충분한 내공이 있었으면

더 잘했을텐데.. 그런 생각을 했었음

가장 큰 차이점은, 과거에 실패했던 제품들은 이용자들이 시장에서 뭘 원하는지에 대한 것들을 상상을 갖고서만 생각했고 그 페인포인트가 실제로 크지 않았어요.

반면, 사람들이 직접적으로 어떤 문제를 해결해주는 서비스가 없기 때문에 간접적인 방법으로 그 문제를 해결하는 서비스를 우회적으로 쓰고 있는 경우들이 있단말이죠.

그걸 캐치해내게 되면 그로부터 파괴적인 성장을 할 수 있게끔 사람들의 니즈에 딱 맞는 제품이 탄생하게 되는 것 같아요.

> 돌아간다고 하면 더 나은 의사결정을 할 수 있었던 것들

과거 비트윈이 일본에서 잘 되고 있을 때

자금력을 갖고 있던 경쟁사가 공격적인 마케팅을 하여

비트윈을 2위로 밀어낸 적이 있음 (경쟁에서 밀려나 버림)

→ 지금 돌아간다면 공격적으로 맞불을 놔서 시장을 키우면서

1등 자리를 지켰을 거라는 생각 (오히려 시장을 키울 수 있는 기회)

• 어떻게 하면 공격적으로 이 시장을 키울 수 있는지
• 어떤 방식으로 시장에서 승자가 될 수 있는지

이런 부분에 대해서 미숙했던 것 같다.

너무 오가닉하게 잘 성장했던 제품이었기 때문에

마케팅이라는 분야가 갖고 있는 힘을 잘 모르고 무지하고 무시했던 것 같음

> 스타트업에게 시장이 얼마나 중요해요?

시장은 굉장히 중요하다고 생각

옆에만 돌아보면 하고 싶은, 할 수 있는 사업 영역이 계속 보임

큰 시장에 도전하고 있는 것에 대한 즐거움

비트윈 서비스를 하면서 답답했던 부분들이

성장을 하는 과정에서 확장하면서 한계가 보일 때…

다음번에 창업을 하면 정말..

한계가 없을 것 같은 무궁무진한 시장에 도전하겠다 다짐

내가 생각하는 훌륭한 리더

현재 같이 팀을 하려고 이야기를 나누고 있는 친구는 내가 봤을 때 정말 훌륭한 리더이다.

그는 리더의 두 가지 역할을 매우 훌륭하게 해낼 수 있는 친구라는 확신이 들었다.

더 크게 볼 수 있게 해준다

그가 처음에 자기소개할 때 했던 이야기가 생각난다.

저는 우주 최강의 회사를 만들 것이기 때문에 우주 최강의 팀을 원합니다. 최고들과 함께 하고 싶습니다.

목표를 세계 1등도 아니고 우주 1등이라고 했다 ㅋㅋㅋ 이렇게 큰 꿈을 가진, 그리고 그것에 진심인 사람은 정말 드물다. 그 때부터 뭔가 다르다라는 생각이 들었다.

그리고 예비 코파운더끼리 핏을 맞춰보기 위해 작성하는 설문조사가 있는데, 거기에 일주일에 몇 시간 정도 일하고 싶은지 적는 칸이 있었다. 거기에 딱 이렇게 적어놨다.

? 그게 무슨 의미가 있는지 모르겠다. 어짜피 잘 때도 사업 생각만 하고 있을 건데. 그냥 눈 뜨고 있는 시간 전부 할 거다.

그리고 월급 얼마를 받아야 성공했다고 말할 수 있냐는 질문에는

적어도 머스크 만큼은 벌어야 그런 말 할 수 있을 거 같다. 그 전에 성공했다고 말하기 가오 상한다.

라고 적어놨다 ㅋㅋㅋ 진짜로 미친놈이다.

그런 답변들을 보자 왠지 월급 1,000만원 받으면 성공했다고 느낄 거 같다고 적어놓은 나의 답변이 너무 작게 느껴졌다.

불안하지 않게 확신을 준다

계속해서 반복해서 말하는 것이 ‘나는 절대 포기하지 않을 자신있다. 그리고 해낼 거 같다.'고 말한다. 그리고 함께 하자고 한 멤버들에게도 정말 큰 확신을 주는 말을 한다.

나는 내가 판단력을 믿기 때문에 너가 굉장히 뛰어난 사람일 거라는 확신이 있다.

이 말이 정말 고맙고 멋지게 느껴진다. 이런 말을 할 수 있는 사람이 얼마나 있을지 싶다.

먼저 희생하여 팀 플레이를 조장한다.

나는 경제적 안정감을 위해 캐시를 먼저 좀 얻고 싶다고 하니, 그럼 너가 초반에 월급을 더 가져가라. 더 필요한 사람이 더 많이 가져가는 게 맞지 않겠냐고 한다.

그리고 나는 제대로 달리기 전에 좀 쉬고 싶다고 하니, 그럼 우리 투자받으면 1,000만원 지원해줄테니 3주 푹 쉬다 와라. 라고 까지 했다.

이렇게까지 팀을 위해 무한 신뢰, 무한 희생의 태도를 보이는 리더와 함께 한다면 정말 좋은 팀을 만들 수 있겠다 라는 생각이 들었다.

이 친구는 여지껏 리더의 포지션에 있어본 적이 없다. 하지만 내가 보기엔 이미 훌륭한 리더이다. 앞으로 얼마나 더 성장할지, 얼마나 더 큰 리더가 될지 정말 기대되는 친구이다.

여러분이 본 훌륭한 리더는 어떤 사람이었나요?

100일챌린지#060

Growth의 다섯 가지 법칙

#1일1메이커로그 #Inbox정리

예전에 @Kain 님 페이스북 글의 댓글을 보고 저장했던 글입니다.

1️⃣ PMF(Product Market Fit), 데이터, Growth.

1.1 PMF 이전의 Growth = 아직 준비되지 않은 제품의 유통에 초점을 맞추며, 종종 잘못된 내부 우선 순위와 PMF 실패를 초래한다.

1.2 데이터 이전의 Growth = 우연히 Growth 모델을 발견한다고 해도, 데이터로써 발견하지는 못할 것이다. 그 결과 예측 가능한 비즈니스 결과를 도출할 수 있는 능력이 부족하게 된다.

2️⃣ 해킹이 아닌 프레임워크로 확장한다.

프레임워크로 문제를 해결하면 학습과 성공을 위한 복제 가능한 프로세스가 만들어진다. 해킹은 괜찮지만, 확장 가능한 노력은 아닐 것이다.

3️⃣ Funnel이 아닌 Loop를 만든다.

Loop는 출력이 입력으로 재투자되어 스스로 지속 가능한 Growth를 만드는 플라이휠이다. Funnel은 선형이고, Funnel 꼭대기에 일정한 압력을 가하며, 어떤 새로운 채널, 돈 또는 전술로도 규모에 맞게 충분히 채울 수 없을 것이다. 성공적인 성장은 Funnel을 사용하여 Loop를 강화시키는 것이지만, Loop를 만드는 것을 우선시한다.

4️⃣ Growth는 혁명이 아니라 진화다.

Growth 진화 = 예측 가능하고 지속 가능하며 경쟁적으로 방어 가능한 성장 시스템을 구축하여 지속적인 성공을 거두었다. 혁명은 혼란, 예측 불가능성 및 거부 가능성(내부 또는 시장별)을 초래한다. 내부 Growth에 투자하는 것에서부터 외부 리더를 영입하는 것, 인접 사용자로 확장하는 것, 새로운 인물을 선택하는 것에 이르기까지 진화는 항상 더 나은 길이다.

5️⃣ 실패를 포용하면 배움이 된다.

Growth팀의 목표는 기존 제품<>고객 상호 작용에서 가장 큰 인식과 현실 격차를 발견하는 것이다. 실험과 같은 과학적 방법을 적용하는 것이 이 발견의 속도를 높일 수 있는 가장 예측 가능한 방법이다. 이 프로세스는 실패를 활용하여 가설을 구체화하고 성공을 제공한다. 성장 팀의 목표는 정기적으로 학습해야 한다(그리고 실패하도록 허용되어야 한다).

저희 프로덕트에서 흥미로운 투표가 진행되고 있습니다!

안녕하세요!

커뮤니티형 리서치 플랫폼, 픽플리를 만들고 운영하고 있는 R2C 컴퍼니입니다.

현재 픽플리는 9월 정식 론칭에 앞서 커뮤니티 빌딩을 위한 다양한 가설 검증을 진행하고 있는데요.

현재 운영 중인 베타 커뮤니티에서 저희가 검증하려고 하는 가설 중 하나에 부합하고, 개인적으로도 궁금했던 흥미로운 질문이 올라와서 디스콰이엇 메이커분들께도 한 번 공유드려봅니다! ㅎㅎ

'비염인 사람들은 코로나 면역?'

한창 코로나가 기승일 때 제가 활동했던 어느 커뮤니티에서 어떤 분이 이러한 의혹을 제기했었고,

그 당시 많은 분들이 맞는 것 같다는 응답을 해주셨던 기억이 있네요!

메이커 여러분들은 어떠셨나요?

Cf. 저는 심한 만성 비염이고, 지금까지 코로나에 걸린 적이 없어요!

이에 대해서 왜 비염인 사람이 코로나에 걸리지 않는가에 대한 나름의 가설도 있는데, 궁금하신 분은 댓글 달아주시면 같이 토론(?)해봐도 재밌을 것 같네요 ㅋㅋ

(모집 완료) 디스콰이엇 메이커 챌린지 IV 모집

안녕하세요! 디스콰이엇 오퍼레이터 박종한입니다. 메이커 챌린지 IV 모집을 시작합니다❗️

메이커 챌린지 IV는 메이커로그를 일주일에 1회 이상 4주간 작성하는 챌린지 프로그램입니다. 프로덕트 길드 또는 인사이트 길드에 배정되어 카카오톡 채팅방에서 소통하고 글을 작성합니다. 메이커 챌린지 IV는 4주간 진행되며, 8월 20일까지 지원을 받습니다.

꾸준히 메이커로그를 작성하고, 댓글, Upvote로 챌린지 참여자와 열심히 소통하면 4주 완주 보상, 길드 승리 보상, 주간 메이커 어워드를 얻으실 수 있습니다.

메이커로그에는 본인의 프로덕트 제작 여정을 기록하는 것, 다른 사람이 만든 좋은 프로덕트를 분석하고 소개하는 것, 개인적인 회고와 인사이트를 적는 것 등 모든 것을 마구마구 남겨주시면 됩니다.

이번에는 새롭게 게이미피케이션 요소를 넣었습니다. 참가자 본인이 작성한 메이커로그에 달린 Upvote 수 및 댓글 개수와 타인의 메이커로그에 단 Upvote와 댓글 개수를 종합하여(집계 방식은 투명하게 공개됩니다) 길드와 메이커의 활동점수와 순위를 매깁니다. 리더보드는 매일 카카오톡 채팅방을 통해 업데이트될 예정입니다.

4주 완주 시 메이커 핸드북, 길드 승리 시 YC Startup School 강의 번역본, 주간 메이커 어워드 수상 시 메이커 티셔츠를 드립니다!

• 모집 기간: 08.09(화) ~ 08.20(토)
• 인터뷰: 08.21(일) ~ 08.25(목)
• 선발 결과 안내: 08.27(토)
• 챌린지 기간: 08.29(월) ~ 09.25(일) 4주간

자세한 내용은 아래 신청 링크에서 확인해 주세요!

https://club.disquiet.io/mch4

3년간 경험과 인풋을 공유합니다.

창업가로서 너무 많은 경험과 인풋이 들어오고 있지만 정리할 시간을 가지지 못하여 그것들을 효율적으로 활용하거나 제대로 전달하지 못하고 있다는 것을 깨닫게 되었습니다. 그래서 글을 통해 저의 경험과 다양한 인풋들을 정리하고 그것들을 공유함으로써 저와 같이 예비 창업가들에게 도움이 되는 글을 작성해보려고 합니다.

현재 어떤 주제로 작성해야 할지 고민 중이어서 관심 있는 주제를 선정하거나 이야기해주시면 순차적으로 저의 경험과 인풋을 글로 전달해드리겠습니다.

주제

• 3년간 창업하며 실패 했던 경험
• 쉽게 팀빌딩 하는 방법
• 개발자 팀원 구하기
• 디자이너 팀원 구하기
• 사이드프로젝트 진행하는 방법
• 스타트업관련 책 추천
• 스타트업관련 책 소개
• 고객인터뷰 방법
• 15분만에 랜딩페이지 만들기 (노션+우피)
• GA를 통한 데이터 분석하기
• 5분만에 로고 만들기 (wix로고)
• 멋사 3기 스타트업 스쿨 후기 (진행중)
• 혁신창업스쿨 후기
• 멘토링(강남언니_김윤혁 CPO님)
• 멘토링(위잇딜라이트_배상기 CEO님)
• 멘토링(왓챠_원지현 COO님)
• 초기 멤버에 대한 생각
• 창업에 대한 생각
• 스타트업이란?
• 협업하는 방법
• 노션을 통해 효율적으로 협업하는 방법
• 팀원끼리 효율적인 소통방법
• 기타

저에게 궁금한 주제가 있으면 언제든 편하게 댓글 메세지 주시면 감사하겠습니다.

[마지막 기회] 창업가 대상 멘탈케어 프로젝트

이제 신청기간이 얼마 남지 않았습니다.

1기 프로젝트에만 드리는 혜택이니 놓치지 마세요!

▶멘탈케어 프로그램 무료!

▶심리 및 해석상담 무료!

▶멘탈케어 앱 프리미엄 1년 구독 무료!

📢 더 많은 혜택 및 자세한 내용은 소개페이지에서 확인 가능합니다.

무료 신청하기 ▶ https://forms.gle/5s9qEtfogopjiL4V7

프로그램 소개 ▶ https://bit.ly/3AmWTLm

어제 오늘 비가 정말 많이 오네요.

스타트업들이 많이 모여있는 지역이

침수 피해가 가장 큰 장소와 묘하게 겹쳐 있다는 것이 신기하면서 안타깝습니다.

모두 안전하고 행복한 한 주 되시기를 진심으로 기원합니다 :)

정현의 슬리드 노트 모아보기

[그동안 제가 공유한 슬리드 노트들을 한번에 보고 싶다면?]

제가 공유한 노트들이 도움이 된다는 분들이 많으셔서, 그동안 작성한 노트를 모아볼 수 있는 슬리드 프로필 페이지를 만들었습니다. :)

• 🏆 스타트업을 한다면 꼭 봐야하는 노트 TOP 3 🏆
• ✔️ 누적 방문자 1만 명! 스타트업에서 가장 핫한 토스 PO세션 🔥
• ✔️ 스타트업의 바이블, YC Startup School 요약노트 🚀
• ✔️ 인사가 만사, 구글 출신 황성현 대표님의 조직문화 핵심요약 👪
• ✔️ 크리에이터 이코노미 추천 영상 ✨

다양한 주제로 묶어서 정리해놓았으니, 지금 나에게 맞는 필요한 영상 요약 노트를 꺼내 보시면 됩니다!

+ 앞으로 모든 신규 노트들도 여기에 업로드 할 예정입니다. :)

https://slid.cc/share/docs/정현의-슬리드-노트-모아보기-f5a0d3ee2ceb40a68b4b64071f8902f6

문제를 정의하고 경쟁 서비스를 분석했다.

내가 디자인하려는 것은 'IT 업계 디자이너를 위한 지식 관리 서비스'이었지만 지금은 'IT 업계 실무자의 지식 활용과 인사이트 창출을 돕는 아티클 큐레이션 서비스'로 방향을 조금 다르게 설정했다. 그 이유는 다음과 같다.

1. 내가 어떤 서비스를 만들려고 하는지를 남에게 설명할 때 '지식 관리'라는 넓은 개념 때문에 두루뭉술하게 이해되는 경향이 있었다. 무엇보다도 내 스스로가 '지식 관리 서비스'라는 말로 인해 혼란스러울 때가 조금 있었다. 서비스를 어떤 식으로 풀어나갈지를 고민할 때마다 갈피를 제대로 잡지 못했다는 말이다. 미리 결과(솔루션)을 정해버리고 나중의 스텝을 그것에 끼워맞추는 것은 잘못된 행위이지만, 적어도 내가 뭘 하고 있는지는 분명하게 전달할 수 있어야 한다고 생각했다. 그를 위해 수많은 형태의 자료 중 글로 이루어진 자료에 초점을 두기로 결정했다.
2. 두 번째 이유는 꽤 단순한데... 문득 디자이너가 보는 자료라고 반드시 디자이너만 본다는 법은 없다는 것을 깨달았다. 분야에 상관 없이 자신에게 좋은 글이라고 판단되면 너나 할 것 없이 기획자든, 개발자든, 마케터든, 디자이너든 누구든 간에 찾아서 읽을 것이다. 가짓수를 조금 줄일 여지는 나중에라도 생길지도 모르지만 어느 한 직군을 위한 아티클 큐레이션이 그렇게 큰 의미가 있을까? 싶었다.

그 후에는 데스크 리서치를 통해 사용자들이 겪는 문제에 어떠한 패턴이 존재하는지를 구체적으로 알아봤다. 그 결과는 다음과 같았다.

1. 읽을만한 좋은 글들이 너무 많지만 그것을 다 읽기에는 시간이 부족하다. 어떤 글을 읽어야 할지, 내게 필요한(도움을 주는) 글은 어떤 것인지 잘 모르겠다.
2. 온라인 아티클은 클릭 한 번으로 북마크하기 참 쉬운데 반해 그것을 읽는 과정은 훨씬 더 오래 걸린다. “나중에 읽어봐야지~” 하는 가벼운 마음으로 아티클을 저장하다보면 모아둔 글은 어느새 산더미처럼 쌓이게 된다.
3. 시간 관리를 정말 잘 해서 글을 다 읽더라도, 글을 읽고 얻은 지식을 ‘자기화’하는 과정이 부재하여 내가 어떤 글을 읽어서 어떤 점을 깨달았었는지를 기억하지 못한다. 즉 머리에 남는 것이 별로 없다. 때문에 접한 글은 많은데 정작 내가 만들어 낸 인사이트나 유무형의 성과/결과물은 많지 않다.
4. 글을 소화해서 깨달은 점, 얻은 지식들을 잘 정리하는 것 까지는 잘 했지만, 나중에 이를 되돌아보거나 연결하는 과정이 결여되어 있다. 특히 창의적인 생각이나 인사이트를 떠올리기 위해서는 새로운 지식을 이전의 지식과 결합해보는(연관지어 생각해보는) 시도가 이뤄져야 하는데, 그것을 제대로 실천하기는 쉽지 않다.

여기에서 나는 곧바로 문제를 해결하기 위해 솔루션을 생각했다. 그러다가 문득 예전에 봤던 글 중에 "우리는 문제가 보이면 무작정 해결하려고만 한다"라는 다소 뼈때리는 말이 기억이 나서 그제서야 정신을 차렸다.

솔루션은 일단 흐릿하게만 구상해두고, 경쟁 서비스 분석과 사용자 조사 결과를 토대로 검증/디벨롭하는 방식으로 접근하기로 했다. 경쟁 서비스 분석은 다음과 같이 간단하게 했다.

1. 국내외 북마크 서비스, 자료 관리 툴, 뉴스레터 서비스 등 내가 디자인하려는 서비스와 결이 비슷한 것들을 찾았다. 총 37개의 서비스를 발견했다.
2. 테이블을 하나 만든 뒤 발견한 서비스들을 리스트업했다.
3. 테이블에 7가지 항목(카테고리, 위협적인지 여부, 서비스 이름, 관련 링크, 서비스 정의, 구동 플랫폼, 핵심 피처/기능)을 만들어서 각 서비스별로 내용을 채웠다.
4. 채운 내용을 바탕으로 경쟁 서비스들이 내놓은 강점과 그것들이 여전히 해결하지 못한 문제점을 파악했다.
5. 4를 토대로 내 서비스가 갖는 기회 요인을 발견했다.

경쟁 서비스들이 여전히 해결하지 못하는 문제점과 그에 따른 기회 요인은 다음과 같이 파악되었다.

1. '필요성'을 되짚어보는 과정의 부재 - 지금 당장 시간을 투자에서 읽을 가치가 있는 글인가? 정말 필요한 글인가? => '필요성'이라는 잣대를 적용해보자. 가능할진 모르겠지만...
2. 글을 모으는것에 비해 소비하는 행위 자체는 여전히 많은 시간과 노력을 필요로 한다. => 글을 보다 쉽고 빠르게 소비할 수 있도록 글을 가공하거나 관련 프로세스를 뒷받침 또는 단순화한다.
3. '지식의 자기화'에 필요한 도구/기능을 제공하기는 하지만 그것을 적극적으로 장려하지는 않는다. => '지식의 자기화'를 적극적으로 장려한다.
4. 글, 지식, 깨달음을 되돌아보거나 연결하는 과정은 여전히 빠져있다. => 제텔카스텐 기법, 네트워크 방식의 지식 연결 등을 모색해본다. 가능할진 모르겠지만...

이제는 사용자 조사를 해야 하는데 주변에 마땅히 부탁드릴만한 분이 안계셔서 조금 걱정이 된다. 일단 인터뷰 질문부터 만들어야겠다.

군대에서 디자인 공부하기 - Daily UI 챌린지

지난 3월부터 시작한 Daily UI 챌린지가 오늘부로 끝났다. Daily UI (Daily UI 챌린지)는 주말을 제외한 100일 동안 매일 이메일로 보내주는 주제를 디자인해 SNS에 올리는 챌린지다. 군대에서 자기계발을 위한 나만의 루틴을 만들고 싶기도 했고, 근본적으로는 내 디자인 경험의 폭을 넓히고 싶단 생각에서 시작했다.

일과, 근무와 병행하다 보니 규칙적으로 하루에 디자인 하나를 만들기 힘들었다. 보통 격일로 하는 근무가 끝나면 오후 9시 정도 되었기 때문이다. 그래서 디자인을 올리지 못하는 날이 생기거나, 시간이 많은 날에는 미리 하루에 2개가 넘는 디자인을 하기도 했다. 챌린지 룰을 완벽히 지킨 건 아니지만 끝까지 완주했다는 사실에 의의를 두고 싶다.

환경의 문제와 의지의 문제가 섞여 보여주기 부끄러운 구린 디자인도 많이 있었다. 그래도 꾸준히 올리는 것이 더 좋다고 생각해 만족스럽지 않아도 그냥 SNS에 올렸다. 그랬더니 댓글로 피드백을 달아주는 분들도 생기고, 인스타그램 메시지로 마음에 들어 내 디자인을 코딩 연습에 사용하고 싶다는 요청을 받기도 했다. 이런 순간엔 챌린지를 끝까지 완주해야겠다는 동기부여와 함께 뿌듯함을 느꼈다.

챌린지에 평균적으로 하루에 한 시간 이상은 투자한 것 같다. 개인정비 시간을 쪼개 디자인하는 게 쉽지는 않았지만 꾸준히 하다 보니 삶의 일부가 된 듯 익숙해져 오히려 좋았다. 습관의 무서움과 중요성을 덤으로 깨달았던 순간이었다. 돌이켜보면 내가 투자한 시간 대비 많은 걸 얻었단 생각이 든다. 폭넓은 디자인 경험과 함께 디자인 기본기를 돌아보고 다질 수 있었던 시간을 얻었고, 무엇보다 군 생활 156일을 이걸로 녹였다는 생각이 들어 기분이 매우 좋았다. 조만간 입대 1년이 깨지는데 앞으로 남은 군 생활 동안 어떻게 성장해야 할지 고민을 좀 해봐야겠다.

인스타그램: https://www.instagram.com/ui_stuff/

Dribbble: https://dribbble.com/Beomsoo

Disquiet에 처음 하고 싶은 말은요

창업을 준비하면서,

주변에 대학 졸업하기 전/후 혹은 사회생활 주니어 친구들이 많이 생겼어요.

전 너무 좋아요! 그들과 이야기하면 넘치는 열정을 충전 받는 기분이 들거든요 :D

그런데 그들에게 제가 가장 많이 받는 질문이 이거예요.

"창업을 계속 시도하는 게 맞을까요? 아니면 취업해서 경력을 조금 쌓고 시작하는 게 맞을까요?"

저는 그들의 젊음이 너무 부러운데 그들은 저의 경험을 부러워하더라고요.

회사에 들어가 더 많은 경험을 하고, 조직을 이해하고, 다양한 사람들과 협업하며 네트워크를 만들어가는 것이 창업을 시작할 때 필요하다고 생각해서 하는 말인 것 같아요.

저는 이렇게 대답했어요.

“둘 중 어느 것이 좋고 나쁜 건 없다”

회사에 들어가 경력을 쌓고 창업을 하는 것도 분명 도움이 될 것이고, 당장 MVP를 만들 아이디어와 팀이 있다면 지금이 좋다.

기회는 우리가 생각하지 못한 범주에서 찾아 오기 때문에 늘 '선택'이라는 문제를 수반해요. 어느 것이 나에게 기회인지 잘 생각해 보세요.

우린 야수의 심장을 가졌으니 창업은 하면 됩니다.

😎

서버 접속이 느려요! K8S 스케쥴러를 만들기까지

(원본은 노션으로 작성되어 있습니다.)

안녕하세요 팀모노리스 CTO 이창환입니다.

수업 시간은 1분 1초가 소중하기 때문에, 저희는 접속시간을 최소한으로 줄이는 것을 신경쓰고 있습니다. 현재 목표는 10~20초 사이인데요. 이 시간 동안 주로 포드(Pod)가 생성됩니다.

1학기 중에 간헐적으로 서버 접속이 느리다는 것을 알게 되었고, 이 문제를 해결하기까지 많은 노력을 기울였습니다. 이 글에서는 우리가 어떤 과정으로 문제를 해결했고, 어떤 결론을 도출했는지 이야기하려고 합니다.

쿠버네티스에 대한 내용이 많고 문제는 결국 스케쥴러를 직접 만들어서 해결했기에 이런 주제에 관심이 있으시다면 재밌을거에요.

문제 파악

한 선생님께서 서버가 늦게 켜진다고 보고를 주셨습니다. 당연히 제가 들어갈때는 빠르게 잘 들어가졌습니다. 그 당시에는 서버 실행 시간을 볼 수 있는 환경이 없어서 문제 파악을 위해서 프로메테우스(Prometheus)와 그라파나(Grafana)를 설치했습니다.

그런 후 결과를 보니, 실제로 30초까지 서버 실행이 늘어지는 현상이 관측되었습니다. 

이 문제를 해결하기 위해서 추가적인 지표를 확인했는데요. 주피터 허브에 남은 접근 기록(Access Log)과 프로메테우스의 로그를 종합적으로 고려했습니다. 예시를 함께 살펴볼까요?

비정상 실행

59:06.506 - 서버 스폰 시작

59:06.595 - GET /hub/spawn-pending/{user}

59:06.??? - kube_pod_created

59.49.??? - kube_pod_container_state_started

00:00.831 - took 54.339 seconds to start

스폰시작 ↔ container start : 43s

container start ↔ 스폰완료 : 11s

정상 실행

59:46.474 - 서버 스폰 시작

59:46.575 - GET /hub/spawn-pending/{user}

59:46.??? - kube_pod_created

59.52.??? - kube_pod_container_state_started

00:01.535 - took 54.339 seconds to start

스폰시작 ↔ container start : 6s

container start ↔ 스폰완료 : 9s

파드가 실행되기 전 pending 상태에 오래 머무르는 것같네요. 하지만 이것만으로는 원인을 단정할 수가 없어서, 수업이 진행중일 때 이벤트를 확인해보았습니다.

이미지를 다운로드하기 위해서 20초 가량이 소모되었네요! 그러니 간헐적으로 1분까지도 실행시간이 걸리는 것이었어요. 🤔 어떻게 해결할 수 있을까요?

문제의 배경

일반적인 쿠버네티스 사용자는 파드 실행이 1분정도 걸리는 것은 이해해줄 수 있는 편이에요. 하지만 팀모노리스에서는 사용자가 접속하는 순간 파드를 띄우기 때문에 파드 실행시간이 곧 유저의 기다림으로 이어집니다.

이런 구조는 주피터 허브에서 사용되는 구조인데요. 커뮤니티의 사용자들도 파드가 실행되는 시간을 줄이기 위해 많은 노력을 해왔습니다. 그 중 하나는 이미지 풀러(Puller)입니다. 이미지 풀러는 노드(Node)가 생성될 때 함께 실행되어 미리 이미지를 다운받습니다. 그러면 파드가 생성될 때, 이미지를 다운로드 받는 시간을 줄일 수 있습니다.

문제

아하, 이미지 풀러에 문제가 있었나봐요. 그래서 파드가 이미지를 다운로드 받아야만 했고, 그만큼 서버 실행이 늦춰진것 같습니다.

하지만 여기서 구체적으로 문제를 설명하자면 굉장히 복잡해집니다. 노드 한 대에 사용자 3명이 할당될 수 있다고 해봅시다. 사용자가 이미 3명이 있을 때, 새 사용자가 오면 다음 그림처럼 새로운 노드를 할당받겠죠.

그런데 이 과정도 상당히 시간이 오래걸립니다. 이미지 다운로드 받는 것은 비교도 안됩니다. 그래서 이 상황도 다른 방식으로 대응하고 있는데요. 바로 더미 사용자를 미리 할당해놓는 것입니다.

다음 그림처럼 녹색 더미 사용자를 미리 할당해두면, 새 사용자가 올 때 더미를 제거하고 사용자를 할당합니다. 그리고 사라진 더미도 잠시 후에 추가해 놓는데요. 이러면 실제 사용자보다 많은 자원을 미리 확보하고 있어서, 사용자가 노드 생성을 기다리는 경우가 많이 줄어듭니다.

이제 이 더미와 앞에서 말한 이미지 풀러가 섞여서 문제를 일으키는데요. 각 노드에 이미지의 여부를 파랑 동그라미로 함께 표현했습니다. 다음 그림처럼 오른쪽 노드가 생성될 때, 이미지 풀러가 이미지를 미리 받아놓습니다. 오른쪽 노드에는 더미만 있는데도요!

자 학생들이 등교할 무렵 실제 사용자는 아무도 접속하지 않은 상태에서 더미가 미리 노드를 할당해놓고 있습니다. 여기에 두 명의 학생이 시간을 두고 들어오면 어떻게 될까요?

먼저 한 명이 도착합니다. 더미 사용자 하나를 제거하고 노드에 자리를 잡습니다. 그리고 더미가 하나 죽었으니, 이어서 더미도 하나 더 생성됩니다. 그러나 노드에 자리가 없기 때문에 새 노드가 할당되고, 더미가 새 노드로 갑니다. 그리고 새 노드에서는 이미지 풀러가 이미지를 받기 시작합니다.

이제 여기서 두 번째 사용자가 도착하면, 의도치 않은 현상이 일어납니다. 우리는 당연히 이미지가 이미 받아져 있는 노드에 가길 바라지만, 쿠버네티스의 스케쥴러는 그렇게 동작하지 않습니다. 왼쪽 노드에는 더미로 인해 진짜 빈 공간은 없기 때문에, 진짜 빈 공간이 있는 오른쪽에 할당해버립니다. 더미는 빈 공간이 없을 때만 삭제하게 되어 있거든요.

그러면 새 사용자는 오른쪽 노드로 할당되고, 이미지가 다운로드되는 것을 기다려야합니다. 이게 바로 우리를 괴롭힌 그 현상이었습니다.

해결

심상치 않아 딱 봐도 어려운 문제네요. 이걸 해결하기 위해서 수 많은 방법을 떠올렸는데요. 사실 이 문제는 팀모노리스만의 문제가 아니고 주피터 허브를 쿠버네티스에서 구동할 때 발생하는 문제라, 이미 오랜기간 알려진 문제였습니다. 하지만… 풀리지 않은 난제이기도 했어요.

결국 이미지가 설치된 노드에만 파드가 할당되도록 하는 쿠버네티스 스케쥴러를 직접 작성하기로 했는데요. 관련된 자료나 예시를 찾는 것은 굉장히 어려웠지만, 생각보다 코드양은 많지 않아 작성된 내용은 꽤나 깔끔했습니다.

https://github.com/team-monolith-product/image-locality-filter

간략한 Go 코드인데요. 핵심은 다음입니다. 저도 이거하면서 Go를 처음 써봤는데, 읽기 어렵지는 않습니다. for 문 안에 있는 if 문에서 이미지의 여부를 검사하고, 이미지가 없다면 image not found 를 전달하며 “스케쥴 불가” 상태를 반환하면 됩니다.

func (pl *ImageLocalityFilter) Filter(ctx context.Context, _ *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status {

node := nodeInfo.Node()

if node == nil {

return framework.NewStatus(framework.Error, "node not found")

}

for _, container := range pod.Spec.Containers {

if _, ok := nodeInfo.ImageStates[normalizedImageName(container.Image)]; !ok {

return framework.NewStatus(framework.Unschedulable, "image not found")

}

}

return nil

}

이제 이 스케쥴러를 적용하면 되는데요. 저희는 현재 오픈 소스를 활용하고 있어서 이 과정에서 이슈가 발생했습니다. 바로 AWS EKS 환경에서 원하는대로 스케쥴러를 적용할 수가 없던 문제인데요. 이 문제는 PR를 올려서 빠르게 해결했습니다.

https://github.com/jupyterhub/zero-to-jupyterhub-k8s/pull/2807

https://github.com/jupyterhub/zero-to-jupyterhub-k8s/pull/2809

그리고 마침내 적용을 했고, 원하는대로 스케쥴이 안되는 것까지 확인할 수 있었습니다! 1 image not found를 보세요! 놀랍지 않나요!

이제 예전처럼 서버가 늦게 켜지는 현상이 없어졌을까요? 이 작업이 마무리 됐을 때는 방학이라 사용자가 없어서 확인하지 못했는데요. 8월 초에 교사 연수 과정 중에 확인해볼 수 있었고...

모든 서버가 20초 이내에 안정적으로 켜졌습니다. (🎉)

마무리

글로 적으면서 많은 내용을 생략했는데요. 실제로는 많은 시행착오를 거치며 오랜 시간 골머리를 앓던 문제였습니다. 마침내 해결을 하게 되어 기쁜 마음에 글을 쓰게 되었습니다.

쿠버네티스 스케쥴러는 물론, Go 조차 처음 써보는 와중에 한 경험이라 상당히 재밌었고, 큰 성취감을 느낄 수 있는 작업이었습니다. 또한 커뮤니티에서 함께 공유하고 있던 어려운 문제라서 커뮤니티에 기여하는 뿌듯함도 있었어요. 이 스케쥴러가 모두에게 쓸만한 물건은 아니라고 생각하지만… 누군가에게는 도움이 될 수 있으니 내용을 정리해서 진행할 예정입니다!

긴 글 읽어주셔서 감사합니다 🙂

평생 지식을 누적하며 성장하는 북클럽을 소개합니다!

지식 습득의 양은 늘어나지만 아웃풋을 만드는 것은 어렵습니다.

어떻게 학습한 지식을 이용해 아웃풋을 늘릴 수 있을까요?

30년 이상 메모를 하며

70여권의 도서, 400여건의 논문을 발표한 니콜라스 루만의 메모법을 다룬 도서

제텔카스텐을 알아보고 토론하는 북클럽을 소개합니다!

토론은 주로 제텔카스텐 방법을 삶에 적용하기 위한 주제로 진행될 예정이며 

카톡방에 실천 위주의 대화를 진행할 예정입니다.

가지고 있는 지식을 재활용해서 효과적인 아웃풋을 만들고 싶은분, 

함께 공부하고 싶은 분께 추천드립니다.

많은 관심 부탁드립니다!

(진행 중) Smart Note Taking 북클럽 - 4기

컨텐츠 생성의 4가지 타입과 컨텐츠 생성의 미래

#1일1메이커로그

컨텐츠 생성의 네 가지 타입

1. 전문적으로 만든 콘텐츠
2. 사용자 생성 콘텐츠
3. AI를 이용한 사용자 생성 콘텐츠
4. AI가 직접 만든 콘텐츠

현재

• 현재 1&2번이 대부분이다.
• 해당 타입에서, Socializing 하려면 특정 활동(예: 게임에서 퀘스트를 완료하는 것, 이후 자연스럽게 다른 플레이어와 연결되는 것)에 집중했을 때 자연스럽게 연결되어야 한다.

미래

• 전문적으로 제작되는 컨텐츠는 제작 비용이 많이 들기 때문에 양이 제한된다.
• 사용자 생성 콘텐츠는 여러 가능성과 잠재력이 있지만, 낮은 컨텐츠 품질이 생길 수 있다.
• 대신, AI를 공동 제작자로 사용하면 일반인들이 양질의 컨텐츠를 만들 수 있는 도구를 갖추게 되므로 더 많은 양의 좋은 컨텐츠가 나올 수 있다.

이런 점에서 @유영준 님의 뤼튼 팀에서 만들고 있는 뤼튼 카피라이팅은 컨텐츠 제작자 입장에서 매력적인 도구다.

메이커 여러분은 디스콰이엇에 글을 작성할 때, 어떤 도움을 받고 싶으신가요?