CUPIST Story

데이팅 앱이 솔로를 응원하는 굿즈를 만든 이유

크리스마스가 껴있는 연말은 아마, 모든 사람들의 마음을 설레게 만들 거예요. 하지만 그중에서도 가장 설레는 사람은 아마 솔로이지 않을까요? 새로운 사랑이 크리스마스 전에 나타나리라 간절히 믿으며, 출근길 나를 지켜보던 사람이 짠하고 나타나서 고백하진 않을까? 지난 소개팅에서 잘 된 사람이 다시 연락 올 수도 있을 거야! 생각하며 연애 가능성을 점쳐보기도 하죠.

이렇게 솔로가 사랑을 찾으러 활발하게 움직이는 시기를 글램이 놓칠 수는 없겠죠. 그래서 팀원 모두가 입을 모아 말했습니다. 진부한 그 대사 "우리 재밌는 아이디어 없을까요?"

그래서 재밌는 아이디어, 뭐요?

한창 회의를 하던 중, A가 가볍게 던진 말에 모두 고개를 끄덕였습니다

사람들은 데이팅 앱을 사용하는 걸 부끄럽게 생각할 때가 있는 것 같아요 가끔 지하철에서 글램 하는 걸 들킬까 봐 몰래 한다는 분들도 있더라고요 (웃음) 아마 '글램을 사용한다' = '솔로' + '외로워서 열심히 사랑을 찾는 중' 것이고 이런 상태를 별로 들키고 싶지 않은 것 같아요"

그날 오전에도 SNS에 "요즘 즐겁다"를 올린 저는 내심 뜨끔하지 않을 수 없었습니다. 사실 혼자 보내는 일상이 텅 빈 냉장고처럼 외롭지만 절대 들키고 싶지 않은 내 모습을 그대로 말하는 것 같아서 말이죠.

코로나 19가 확산되면서 구성원의 건강을 위해 큐피스트도 재택근무를 시행하고 있습니다. (어느덧 3주 차..)

갑자기 찾아온 재택근무! 처음 도입해보는 제도이기 때문에, 정상적으로 운영이 될 수 있을까 걱정이 많았어요.

하지만 걱정과는 달리 큐피스트 구성원들은 평소처럼 책임감 있게 업무를 해주고 있어요. 빠른 의사결정이 필요하다면 화상으로 미팅을 하고, 슬랙과 노션을 이용하여 모든 업무를 공유하고 있어요.

성공적으로 재택근무를 운영할 수 있도록 빨리 적응해준 구성원들에게 감사해요!

매달 시행하는 큐피스트의 컨퍼런스. 재택근무라고 그냥 넘어갈 수는 없죠!

이번에는 화상 미팅으로 대체하여 진행했어요. 저희가 컨퍼런스를 진행하는 모습을 영상으로 담아봤는데요!

큐피스트의 투명한 정보 공유와 의사 결정이 이루어지는 컨퍼런스의 모습이 궁금하시다면 아래 동영상을 클릭해주세요 :)

큐피스트는 이른 시일 내에 코로나 19사태가 안정화 되길 바라며 모두의 건강과 회복을 기원합니다!

우리는 사랑을 위해 이곳에 왔고, 사랑은 혁명이 필요하다.

사랑은 혁명이 필요해

사랑은 너무나 힘들고 험난하다. 누가 우리와 맞는지 모르고, 알아도 찾을 수 없으며, 찾아도 사랑에 도달하기 힘들다. 혼자 있고 싶으나 외롭긴 싫고, 사랑받고 싶으나 상처받기 싫다. 외로움에 익숙해지고 자존감을 상실하기도 한다. 부의 격차는 사랑의 격차에 비할 바가 되지 않는다.

공간의 시작은 하나의 질문에서

지금보다 진보된 사랑을 꿈꾸는 우리는, 우리의 공간을 하나의 질문에서 출발하기로 했다. '좋은 조직이란 무엇이며, 어떤 조직이 좋은 조직인가?'

흔히 좋은 조직이라 하면 어떤 요청사항도 들어줄 것 같은 CEO와 친절한 동료들, 야근이 없는 정시퇴근과 다양한 복지를 제공하는 회사를 떠올린다. 이런 부분들은 좋은 조직을 만드는 개별적 요소로 작용 될 수도 있지만, 최우선이 되지는 않는다. 사명은 조직의 존재 이유이며 나가고자 하는 목적을 담고 있기 때문에 좋은 조직을 찾고 있다면 가장 먼저 사명이 분명하고 명확한 조직인가를 확인할 필요가 있다.

우리는 고민했다. 좋은 조직 기준은 무엇이며, 어떤 요소들이 좋은 조직을 만들 수 있을지. 경영학에 아버지라 불리는 피터 드러커는 5가지 질문을 던졌다.

우리의 미션은 무엇인가? 왜, 무엇을 위해 존재하는가?

우리의 고객은 누구인가? 반드시 만족시켜야 할 대상은 누구인가?

우리의 고객의 가치는 무엇인가? 그들은 무엇을 가치 있게 생각하는가?

우리의 결과는 무엇인가? 어떤 결과가 필요하며, 그것은 무엇을 의미하는가?

시작하기 전에

몇 달 전에 Facebook으로부터 끔찍한 메일을 한 통 받았습니다. 아마 이 글을 읽는 몇몇 분들 또한 Facebook Account Kit이 서비스 종료한다는 메일을 받으면서 "일이 늘어났다!!!"라는 저와 같은 생각을 하지 않으셨을까 예상합니다. 물론 우리가 시간이 없지 기술이 없는 건 아니기 때문에 Facebook에서 예고한 기간에 맞춰 대체 모듈을 작성하였고 한 가지 사소한 문제를 만나게 되었을 뿐이었습니다. 저의 소중한 저 사향 테스트폰(사실 내 폰)에서 문자 확인을 하러 앱을 이탈하기만 해도 메모리가 싹싹 증발하는 몹시 난감한 상황을 쉽게 제공해 주었습니다. 물론 안드로이드의 고질적인 문제이며 전통적인 방법으로 처리 할 수 있지만 현재의 아키텍처에서 해당 방법은 그다지 아름다운 결론으로 끝나지 않는 것을 이미 확인한 바 있었습니다. 그러다 번득 SavedState 관련 모듈이 추가되었던 것을 기억해 냈고 바로 구현에 착수하기 시작하였습니다.

우선 본 문서에서 설명되지 않는 코드들이 있으나 SavedState와 관련된 사항만 언급하고자 하는 점 양해 부탁드립니다.

ViewMode에 Saved State 끼얹기

Saved State module for ViewModel | Android Developers

본 문서는 개념 설명을 위한 문서가 아닌 실제 구현을 위함으로 자세한 설명은 위 문서를 확인하시길 바랍니다.

시간이 없습니다! 앱 모듈에 아래 의존성을 추가하도록 합시다.

ViewModel에 SavedStateHandle을 생성자로 넣어줍니다. 이제 ViewModel과 관련된 데이터는 별도의 외부 도움 없이 내부에서 끝나게 될 예정입니다. 그런데 SavedStateHandle는 누가 만들어 주는 걸까요?

PhoneVerificationViewModelFactory가 AbstractSavedStateViewModelFactory를 상속해서 구현되도록 수정해야 합니다. 기존에 사용하던 ViewModelProvider.Factory에서 추가된 점으로 create의 Parameter로 SavedStateHandle를 받아 낼 수 있고 이를 이용하여 ViewModel을 생성 할 수 있습니다.

"분석 툴은 어떤거 쓰세요?", "CEO에 대해 평가하자면?" 큐피스트 데이터 팀이 자주 받는 질문에 직접 답했어요.

일단 자기소개 먼저!

오~ 드라마 <이번 생은 처음이라>는 어떻게 하게 된 거예요?

1. 마케팅 트렌드 2020

2020년, 권력 이동의 해, 새로운 문법이 업계를 주도할 것

Mass → Niche

: 미디어 파편의 시대, 소비자는 각자 다른 세상에서 콘텐츠를 접한다

미디어를 모두 이해할 수 없는 시대, 모든 미디어가 버티컬 화 되면서 유저 접근은 한층 더 어려워진다.

니치는 소비자와 미디어의 아이덴티티와 신념, 그리고 자기 인식이자 가치관이다.

니치 시대의 마케팅은 신념과 정체성을 기반으로 한 브랜딩이여야 한다

Growth → Branding

: 이제 마케팅은 세그먼트 위주의 그로스에서 벗어나 상품이 아닌 가치판매에 집중해야 한다

가치와 신념을 중심으로 마케팅을 종교화 하고, 이를 통해 유저 로열티와 리텐션을 보장받아야 한다.

광고에 대한 피로도는 이미 Max, 단순한 프로덕트 설명이 아닌 비주얼 가치 브랜드 세계관으로 접근하라

로열티 유저가 신규 유저가 브랜드와 만나는 최접점이다

이전편 링크

Kong Plugin 개발의 시작점은 아래 공식문서이다. Nginx 는 lua-nginx-module 을 통해 Lua 스크립트를 이용해 확장 기능을 추가할 수 있다. Nginx 에 해당 모듈을 포함하여 컴파일 하는 대신에, Kong 은 OpenResty 라는, 이미 lua-nginx-module 이 포함된 버전과 함께 배포된다. Kong 의 Plugin 을 개발하는 것은 OpenResty 확장을 개발하는 것과 매우 비슷한 작업이다. 이 작업은 Kong 의 Plugin Developement Kit: PDK 를 이용하는 개발 작업이다.

Open-Source API Management and Microservice Management

아래의 명령으로 homebrew 를 이용해 OSX 환경에 Lua 컴파일러를 설치하고, REPL을 실행해볼 수 있다.

하지만, Kong Plugin 을 개발하기 위해서는 Nginx 의 lua-nginx-module 을 이용하여 Nginx 의 다양한 기능 (특히 logging과 request/response)을 사용하는 것이 필수적이다. 그러므로 아래 명령을 이용해 OpenResty 를 설치라면 수월하게 개발을 진행할 수 있다.

Nginx 를 이용해 웹사이트의 데이터를 가져오는 간단한 코드를 작성하고, resty를 이용해 실행해보자.

가장 간단한 방식의 Kong Plugin 은 아래 두 개의 모듈로 구성된다.

이전편 링크

공식문서에 따르면, 최소 4 CPU cores, 16GB 램, 24GB의 디스크 저장공간을 필요로 한다. AWS 환경에서는 c4.2xlarge 인스턴스(8 CPU cores with 16GB RAM)을 추천한다.

Open-Source API Management and Microservice Management

공식 패키지로 설치를 진행할 경우 /etc/kong/kong.conf.default 기본 설정 파일이 함께 제공된다. 실행시 /etc/kong/kong.conf, /etc/kong.conf 파일을 찾지만, -c / --conf 옵션으로 설정 파일을 지정할 수 있다.

kong.conf 파일의 설정 값은 KONG_ 으로 시작하는 환경변수를 지정해서 덮어쓸 수 있다. (Docker 구성등에 유용하다) 예를 들어

위의 kong.conf 항목은, 다음과 같은 환경변수로 덮어쓸 수 있다.

Kong 은 기본적으로 PostgreSQL 또는 Cassandra 와 함께 사용하도록 되어 있으나, DB-less mode 로 실행할 수 있다.

서비스는 항상 진화한다. 요구사항이 추가되며 복잡도가 증가하고 여러개의 서비스로 분리되기도 한다. 의존관계가 생겨 유지보수가 어려워지만, 모든 것을 새로 작성하기에는 시간과 인력, 많은 리소스들이 부족하다. 이때 필요한 것이 최소의 비용으로 서비스를 분해하고 다시 조립하는 것이다. 새로운 서비스를 추가할 수 있도록 확장성을 가질 수 있으면 더욱 좋을 것이다. 이런 이유로 모놀리스 서비스가 마이크로서비스로 분해된다. 그리고 복잡해진다. 이것을 통합하고 단순화하기 위해 필요한 것이 API Gateway다.

GLAM 서비스에 API Gateway 를 도입하고 마이크로서비스를 통합한 과정을 소개한다.

Wikipedia 의 API Management 페이지의 Gateway 항목은 아래와 같이 작성되어 있다.

Gateway: a server that acts as an API front-end, receives API requests, enforces throttling and security policies, passes requests to the back-end service and then passes the response back to the requester. A gateway often includes a transformation engine to orchestrate and modify the requests and responses on the fly. A gateway can also provide functionality such as collecting analytics data and providing caching. The gateway can provide functionality to support authentication, authorization, security, audit and regulatory compliance.API Management fro Wikipedia

게이트웨이: API 의 프론트엔드로서 동작하는 서비스로, API 요청을 받아 요청을 조정하고 보안정책을 적용한 후 요청을 백엔드 서비스로 전달하고 발생한 응답을 요청자에게 전달해주는 역할을 한다. 게이트웨이는 요청과 응답을 실시간으로 변형할 수 있는 기능을 제공하기도 한다. 또한 통계 자료에 대한 수집기능이나 응답에 대한 캐시 기능을 제공 한다. 게이트웨이는 기능적으로 인증, 인가, 보안, 감사 및 내부 규제 준수등의 기능을 제공한다.

… 고 간략히 번역할 수 있겠다.

API 게이트웨이의 주요 기능은 다음과 같다.

라우팅:

인증, 인가 및 보안 기능:

공통 로직 처리:

요청 및 응답을 변환:

GLAM에서 처리해야하는 요구사항이 복잡해지면서, 글램의 백엔드 엔지니어링 팀은 기존의 모놀리틱 서비스를 서비스 도메인에 맞는 마이크로서비스로 분리하는 작업을 진행중이다.

큐피스트에서 데이터 분석가로 근무한 지 어느새 4개월 차에 접어들었다. 3개월 간 정신없는 수습 기간을 보냈는데, 본인은 직무를 전환했기 때문에 회사에 대한 적응 뿐 아니라 업무 자체에 대한 적응도 도전 과제였다. 데이터 분석가로서 실무를 겪어보니 전직을 마음 먹었을 때 예상했던 것과 유사한 점도 있고 전혀 알지 못했던 것들도 있었다. 또, 같은 데이터 분석이라도 회사가 일하는 방식에 따라 업무의 범위나 깊이가 많이 달라질 수 있겠다고 느꼈다. 이번 포스팅에서는 큐피스트 데이터 클래스의 일하는 방식과 클래스원으로 업무를 수행하면서 배운 점들을 정리해보았다.

큐피스트 데이터 클래스가 일하는 방식

어떤 직무든 그 직무를 수행하는 팀의 성격이 매일의 업무에 큰 영향을 미치는 만큼 먼저 큐피스트 데이터 클래스의 형태와 일하는 방식을 소개하고자 한다. 조직에서 데이터팀을 구성하는 방식은 크게 두 가지 형태가 있는 것 같다. 하나는 영업, 마케팅 등 특정 기능팀에 분석가가 소속되어 해당 팀의 데이터 수요에 대응하는 형태이고, 다른 하나는 별도의 데이터팀을 꾸려 전사적으로 데이터 관련 사항에 대응하는 방식이다.

큐피스트 데이터 클래스는 후자의 형태로, 조직 내 허브(Hub)로서 프로덕트팀, 마케팅팀 등 현업에서 필요한 데이터를 전달하는 방식을 취하고 있다. 독특한 점은 허브 형태의 데이터팀이라면 흔히 지원 조직이라고 생각할 수 있는데, 큐피스트에서는 여러 팀을 지원함과 동시에 주요 지표를 살펴보면서 필요하다고 판단되는 프로젝트를 자체적으로 수행하는 독자적인 팀의 성격 역시 갖고 있다. 이 같은 능동적인 성격의 특성은 업무에 많은 영향을 주는데, 예를 들어 일정 기간 동안의 특정 지표 추이를 현업 팀에게 전달할 때 단순히 요청 받은 수치만 전달하는 게 아니라, 관련된 다른 지표에 특이 사항은 없는지 살펴보고, 눈에 띄는 변화가 있다면 그 원인은 무엇일지에 대한 의견까지 제시하기도 한다.

조직 문화 측면에서 지금까지 경험한 데이터 클래스의 문화는 '매우 높은 수준의 권한 위임'과 '클래스 리더의 헌신적인 지원'으로 요약할 수 있을 것 같다. 3개월 간 대부분의 업무에서 완전한 권한 위임이 이루어졌었고 덕분에 주어진 문제에 대해 충분히 고민해 볼 수 있었다. 때때로 잘못된 접근법으로 처음부터 다시 분석해야 하는 상황이 발생하기도 했는데, 그 때마다 클래스 리더가 가까이서 의견과 제안, 가이드를 주면서 문제를 풀어나갈 수 있게 많은 도움을 주었다. 무엇보다 그런 시행착오가 발생해도 여전히 권한을 충분히 위임받을 수 있었고, 덕분에 계속해서 분석 주제에 대해 깊게 생각해 볼 수 있었다. 이렇게 스스로 끊임없이 고민하고 판단할 수 있었던 기회와 시행 착오를 허락해 준 환경 덕분에 빠른 시간 내에 업에 대한 이해를 높이고 부족한 부분을 인지할 수 있었다.

by Kaya, 큐피스트 데이터 클래스 리더 | 큐피스트 기술 블로그

이 글의 제목은 "(큐피스트) 데이터 분석 실무에서 필요한 5가지 역량"입니다. 회사의 조직 구조나 업무 환경, 의사 결정 방식에 따라 중요한 가치는 상이할 수 있습니다. 이 내용은 30명 규모의 스타트업이자 빠른 속도와 린(lean)함을 추구하는 큐피스트가 "좋은 데이터 분석가"에 대해 고민하는 과정의 일부입니다.

오늘은 큐피스트의 데이터 클래스가 생각하는 "데이터 분석가의 5대 역량"에 대해 이야기하려 합니다. 이 다섯 가지는 현재 큐피스트 데이터 클래스원의 직무 역량 평가 혹은 채용 기준으로 활용할 만큼 의미 있게 여기는 역량입니다. 그럼 밴 다이어그램에서 강조하는 세 분야가 큐피스트에서는 어떻게 활용되고 있는지 살펴보겠습니다

첫째, 통계 지식에 기반한 분석력

먼저 가장 중요하게 여기는 역량은 통계 지식입니다. 데이터 분석가는 통계적으로 의미 있고 명확한 분석을 실시하며 그에 따른 분석 결과에 책임을 져야 합니다. 통계 지식에 기반한 분석이 결코 '아묻따' 머신러닝을 돌리는 행위를 말하는 것은 아닙니다. "95% 신뢰수준에서 귀무가설이 기각되었다"라는 남들이 이해하지 못할 용어로 리포트를 작성하는 것을 말하는 것은 더더욱 아닙니다. 문제를 풀기 위해 적절한 방법을 선택하고, 불분명한 수치를 보고 유의미한 기준을 바탕으로 판단을 내릴 수 있는 것을 의미합니다.

기존에는 디자인의 개념이 제품을 시각적으로 잘 표현하는 것에 한정되어 있었다면, 이제는 서비스 기획과 데이터, 개발을 이해하고 프로젝트를 이끌어가는 중요한 역할까지 확대됨. 이에 따른 커뮤니케이션 능력 및 비즈니스 임팩트를 함께 주는 것까지 고려해야 한다.

1,000여 명이 참석한 대규모 디자인 컨퍼런스(이번 연도에 진행된 컨퍼런스 중 최대 규모 예상). 참여 기업의 라인업 수준이 높았다. 내가 생각하는 디자이너의 역할과 일치하는 부분과 현재 맡은 업무에 도움되는 내용이 많았다. 기업의 규모에 따라 어떻게 디자인 프로세스를 정립하고, 발전시키고, 지속 운영해가고 있는지 알짜배기로 들을 수 있었다.

[라인]

이정영, UX&Interaction Lead

라인의 Product Design 영역 전략 설정 → 'UX/UI 설계 → Interaction 설계' → 개발

서비스 초기부터 UX/UI 디자이너로 글램 서비스의 기획과 visual 디자인을 해 나가며 디자이너 - 개발자 간의커뮤니케이션 장벽을 낮춰 생산성를 높이기 위한 방안을 찾고 하나의 프로세스로 정착시킨 과정을 전하고자 한다.

2017년 말 글램은 생존을 위해 열심히 달리고 있었고, 디테일한 애니메이션 보다 오늘 접속한 유저 수, 기능 이용률, D+1 잔존율이 더 중요했다. 이에 맞춰 빠르게 기능을 기획, 디자인해 개발자에게 전달해 배포하는 것이 먼저였다. 꼭 필요한 기능만 담아 빠르게 유저에게 제품을 제공해야 하면서도, 사용성이 불편하거나 버그 등으로 기능 이용 자체를 불편하게 만들어서는 안 되기에 배포 전 의도한 디자인이 제대로 구현됐는지 꼼꼼히 리뷰하는 과정은 필수였다.

처음 디자인 문서를 전달할 때는 속도가 빠르다고 느꼈다. 하지만 개발 시작 후 디자인 단에서 수치상으로는 동일하지만 생각했던 것과 다른 모습, 의도대로 구현되지 않은 애니메이션, 예상하지 못했던 부가적인 상황들로 디자인을 수정하고, 다시 개발하는 수정의 루프가 무한 반복되었다. 이는 실제 프로덕트를 경험하며 디자인하지 않는 디자이너의 머릿속 상상에는 한계가 존재하고, 이 상황에서 최대한 문서로 구체화해 개발자에게 전달하는 과정에서 의도가 완벽히 전달되기 어려우며, 또 이를 구현하는 개발자 마다의 해석이 다르기 때문이다.

디자이너의 상상

개발자 A, B의 구현 모습