큐피스트의 각 조직은 이렇게 일해요

소개팅앱은 이제 약간 흘러간 말이죠. 지금 저희는 '소셜 엔터테인먼트'를 추구합니다.

(왼쪽부터) 큐피스트 라이언(Ryan) CTO와 키쓰(Keith) 프로덕트 디자이너, 브라이트(Bright) 앱 개발자 / 사진=오승혁 기자

자기소개 부탁드립니다.

3인 3색 인터뷰 CTO x 디자이너 x 개발자

Design

Engineering

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

일단 자기소개 먼저!

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

현직자가 말하는 글램 데이터 분석 TMI

Data

Marc 큐피스트 데이터 클래스원

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

큐피스트 데이터 분석가 Marc

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

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

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

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

큐피스트 데이터 클래스

신입 데이터 분석가로서의 성장기

Data

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

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

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

•

디자이너의 상상

•

개발자 A, B의 구현 모습

Fit한 프로토타이핑 툴 찾기

Design

이전편 링크

API Gateway Part 1 - 개요

시스템 요구사항 및 설정

시스템 요구사항

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

Open-Source API Management and Microservice Management

Careful! You are browsing documentation for an outdated version of Kong. Go here to browse the documentation for the latest version. Kong can run on instances of any size with any resources. While the system requirements vary significantly depending on the use-case, generally speaking, we recommend to start big and then gradually reduce the instances to the appropriate number and size.

https://docs.konghq.com/enterprise/0.32-x/kong-implementation-checklist/

설정

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

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

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

Declarative Config and DB-less Mode

API Gateway Part 2 - Kong 도입(1)

Engineering

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

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

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

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

상황에 맞는 분석 기법을 활용하여 통계적 판단을 내릴 수 있는가?

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

데이터 분석 실무에서 필요한 5가지 역량

Data

이전편 링크

API Gateway Part 1 - 개요

API Gateway Part 2 - Kong 도입(1)

Plugin 개발

Lua 개발환경 설정

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

Before going further, it is necessary to briefly explain how Kong is built, especially how it integrates with Nginx and what Lua has to do with it. lua-nginx-module enables Lua scripting capabilities in Nginx. Instead of compiling Nginx with this module, Kong is distributed along with OpenResty, which already includes lua-nginx-module.

https://docs.konghq.com/1.3.x/plugin-development/

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

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

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

Plugin 구조

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

API Gateway Part 3 - Kong 도입(2)

Engineering

주제 : 문제를 해결하는 디자인을 할 때의 기쁨을 공유하는 자리 -시각화에서 기획, 데이터, 비즈니스까지, 더 넓어진 디자이너의 역할에 관한 이야기

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

요약

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

Speaker

[라인]

이정영, UX&Interaction Lead

•

라인의 디자인 프로세스 역사 

•

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

Spectrum Con 2019 후기

Design

시작하기 전에

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

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

ViewMode에 Saved State 끼얹기

Saved State module for ViewModel | Android Developers

As mentioned in the Saving UI States article, objects can handle configuration changes so you don't need to worry about state in rotations or other cases. However, if you need to handle system-initiated process death, you may want to useonSaveInstanceState() as backup.

https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate

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

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

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

토막 글 - ViewMode에 Saved State 끼얹기

Android

안녕하세요, 글램 데이터 팀의 Data Scientist 다운입니다

이번 글에서는 글램 데이터 팀이 어떻게 글램 백엔드 서버와 독립적인 내부 머신러닝 서비스를 구축하고 운영했는지 소개하려고 합니다.

이 글을 통해 다음과 같은 내용을 파악할 수 있습니다.

도입 배경

기술에 대한 제한을 두지 않고 사용하고 싶은 기술을 자유롭게 제안할 수 있어요

•

컨텍스트 스위칭을 최소화하기 위해 업무 집중을 위한 환경 조성을 위해 노력해요

•

매 주 수요일 11:00 ~ 13:00 개인의 직무 성장을 위한 Level-up Study를 진행해요

•

구성원 간 서로 다른 technical stack을 자유롭게 공유하는 I  DEV  U 클럽을 진행해요 

•

매달 사내 컨퍼런스에서 업무에 관한 자유로운 토론을 해요

I DEV U가 진행되는 모습

"큐피스트 개발팀은 무슨 일을 하나요?"

•

글램 서비스에 들어갈 신기능 개발을 해요

큐피스트 엔지니어가 일하는 방법

Engineering

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

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

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 게이트웨이의 주요 기능은 다음과 같다.

•