글 쓰는 기획자 '길'

ChatGPT와 기획/기술 리뷰 함께하기

Wed, 22 Mar 2023 23:42:37 +0900

이전에 LinkedIn에 한번 적었던 것처럼, Planetarium에서는 회사에서 전직원에게 ChatGPT 유료 버전 구독을 전액 지원해준다. 인당 월 20$로 스타트업에게는 절대로 작지 않은 비용이지만, 확실히 이를 도입하고 나서 생산성이 어마어마하게 상승했다.

데이터 분석에 필요한 SQL부터, 운영성에 업무에 필요한 SQL 작성, 그리고 UX writing까지 사용해보면 거의 무궁무진한 사용성을 보여주는 이 무시무시한 도구로, 한번 '개발자와 가상의 기획 리뷰를 해본다는 느낌으로 써볼까?' 라는 생각이 들어 이를 진행 해보았다.

어떤 일을 맡겼나?

내가 담당하는 서비스에는 Referral ID가 존재한다. 지금까지는 이를 URL에 파라메터로 넘겨주고 있었고, 해당 파라메터를 손으로 입력할 일은 없다고 생각하여 긴 자리수를 그대로 사용하고 있다.

그러나, 회사에서 준비하고 있는 '앞으로 다가올 개선 버전' 에서는 손으로 직접 Referral ID 를 입력하는 시나리오도 발생할 것으로 예상이 되어, "가능하다면 Human-readable 하고 짧은 코드를 만들 수 있었으면 좋겠다" 라는 생각이 들었다.

지금까지의 업무 방식이라고 하면, 함께 일하는 시니어 백엔드 엔지니어 중에서 이러한 업무를 해본 사람을 찾아가서 "친구 초대 코드를 최대한 짧게 만들어 보려고 하는데, 몇자까지 줄일 수 있을까요?" 라고 물어보고 자문을 구한다거나, 아니면 구글 검색 등을 통해서 Referral ID를 어떻게 만들 수 있는지 찾아보았을 것 같다. 혹은, 다른 웹서비스들은 어떻게 Referral ID를 관리하고 있는지 벤치마크 등을 해보지 않았을까?

그런데 당연히, 이 방식에는 몇가지 현실적인 단점이 있다.

그 중 대표적인 것이, "최대 몇자리 까지 줄일 수 있다" 라는 것을 '문서'로만 찾아보거나, 아니면 경험에 의존해서 알 수 있다는 것이 아닐까 싶은데, 운이 좋게 관련 경험이 풍부한 시니어 엔지니어가 있었다면 그 정답을 바로 알려줄 수도 있지만, 그런 상황이 아니라면? 아마 높은 확률로, 다른 서비스의 레퍼런스를 확인하고 그 모델을 따라가지 않았을까?

하지만 요즘 핫하다는 ChatGPT는 코딩까지 직접 해주는 도구가 아니었던가.

바로, ChatGPT와 함께 리서치를 시작해 보았다.

먼저 간단한 요구사항을 정리하면 다음과 같았다.

유저 사이에서 중복되는 Referral ID가 발생하지 않도록 UUID에서부터 코드를 생성한다.
반대로, 생성된 Referral ID를 다시 UUID로 변환할 수 있어야 한다.

과정

처음에는 대략적인 가설을 가지고 시작했다. 한 8자리~10자리 정도면 충분하지 않을까?

ChatGPT에게 요구사항으로, 다음과 같은 전제를 전달했다.

Generate a unique referral ID based on UUID, and limit it to 8 or 10 digits.
Create a referral code from a 36 character code that is unique and easy to remember.
Use a combination of letters (case-insensitive) and numbers.

그리고 아래와 같은 코드를 얻었다.

num = int(code, 36)

def generate_referral_code(code):
    base = 36
    mod = 36**10

    num = int(code, base)

    result = ''
    while len(result) < 10:
        num = num // mod
        remainder = num % 36
        char = str(remainder) if remainder < 10 else chr(remainder + 55)
        result += char

    return result

그 뒤에 가장 중요한 질문인, 32자리인 uuid를 10개의 자리수로 줄이면 '동일한 Referral ID'를 얻을 확률에 대하여 계산해달라 요청했다.1억명이 가입한 경우를 가정해서 실제로 얼마가 중복되는지도 계산해 달라 요청했다. 물론 각각이 한줄 한줄의 프롬프트였었고, 아쉽게도 지금은 ChatGPT에서 Chat history를 제공해주지 않아 캡쳐를 하진 못했다. 대신 맨 마지막에, '이 모든 것을 정리하여 문서로 만들어줘' 라는 명령어를 쳤고, 맨 아래에 아래와 같은 요약을 ChatGPT에서 제공해주었다.

Probability of Collision:

For a 10 character code using base-36 numbers, the probability of collision between two different 36 character codes mapping to the same 10 character code is around 0.00022%.
If there are 100 million users who signed up for the service and each user has a unique 10 character referral code generated using base-36 numbers, the probability of two users having the same referral code is effectively zero (less than 1 in 10^15). However, in reality, it's possible that some users may have the same referral code due to the limited number of possible codes compared to the number of users.

해치웠나?

아쉽게도 1차 시도는 실패였다. ChatGPT가 작성해준 코드를 돌려 보았을 때, 어디가 잘못된 것인지는 모르겠어도 반대로 10자리 코드에서 uuid를 얻는 과정에서 계속 다른 값이 나왔다. (해당 코드는 Jupyter notebook에 돌려 보았다.) 생성된 코드에서 원래의 UUID를 얻지 못하니, 실패였다.

2차 시도는 그래서, 자리수를 내가 먼저 임의로 정하지 않고 '최대한 줄여달라'는 요청으로 프롬프트를 다시 시작해 보았다.

그리고 아래는, GPT4가 만들어준 답변들을 바탕으로 마지막에 "문서로 요약해줘" 라 입력한 결과이다.

소개

이 문서는 32자리 UUID를 base-62 인코딩을 사용하여 짧은 참조 ID로 압축하는 Python 스크립트를 제공합니다. 이 스크립트는 무작위 UUID를 생성하고, 이를 참조 ID로 압축하며, 압축을 해제하여 프로세스가 뒤집힐 수 있는지를 확인합니다.

방법:

Base-n 인코딩 및 디코딩:
- 이 스크립트는 지정된 문자 집합을 사용하여 다른 진법으로 숫자를 변환하는 ****base_n_encode***와 base_n_decode 함수를 정의합니다.
UUID 압축 및 해제:
- compress_uuid 함수는 UUID 문자열을 입력으로 받아 하이픈을 제거하고 결과적으로 생성된 16진수 숫자를 알파벳과 숫자(0-9, a-z, A-Z)로 이루어진 base-62 숫자로 변환합니다.
- decompress_uuid 함수는 참조 ID를 입력으로 받아 base-62 문자 집합을 사용하여 이를 16진수 숫자로 변환하고 하이픈으로 구분된 UUID 문자열로 형식화합니다.
충돌 확률 계산:
- 이 스크립트에는 생일의 역설 공식을 사용하여 참조 ID 충돌 확률을 계산하는 collision_probability 함수가 포함되어 있습니다.

Python code

import uuid

def base_n_encode(number, base, charset):
    if number == 0:
        return charset[0]
    result = ""
    while number > 0:
        number, remainder = divmod(number, base)
        result = charset[remainder] + result
    return result

def base_n_decode(s, base, charset):
    number = 0
    for char in s:
        number = number * base + charset.index(char)
    return number

def compress_uuid(uuid_str):
    hex_str = uuid_str.replace('-', '')
    num = int(hex_str, 16)
    base62_charset = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
    return base_n_encode(num, 62, base62_charset)

def decompress_uuid(referral_id):
    base62_charset = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
    num = base_n_decode(referral_id, 62, base62_charset)
    hex_str = format(num, 'x').zfill(32)
    return f"{hex_str[:8]}-{hex_str[8:12]}-{hex_str[12:16]}-{hex_str[16:20]}-{hex_str[20:]}"

# Generate a random UUID
random_uuid = uuid.uuid4()
print(f"Original UUID: {random_uuid}")

# Compress the UUID into a referral ID
referral_id = compress_uuid(str(random_uuid))
print(f"Referral ID: {referral_id}")

# Decompress the referral ID back into a UUID
decompressed_uuid = decompress_uuid(referral_id)
print(f"Decompressed UUID: {decompressed_uuid}")

결과

이 스크립트는 UUID를 짧은 참조 ID로 성공적으로 압축하고 이를 다시 원래 UUID로 해제합니다. 그러나 생성된 참조 ID 수가 많아질수록 충돌 확률이 증가합니다. 많은 수의 사용자에게는 충돌 가능성을 줄이기 위해 더 긴 참조 ID를 사용하는 것이 권장됩니다.

그리고 아래는, 위 과정에서 위 코드가 맞는지 테스트를 위한 코드를 작성해 달라고 요청한 것이다.

import math

def collision_probability(n, shortened_code_length, base):
    N = base ** shortened_code_length
    prob = 1 - math.exp(-n**2 / (2 * N))
    return prob

base = 62
shortened_code_length = 22

n_values = [1_000, 10_000, 100_000, 1_000_000, 10_000_000, 300_000_000_000_000]
for n in n_values:
    prob = collision_probability(n, shortened_code_length, base)
    print(f"Collision probability for {n} generated codes: {prob:.10f}")

결과는 아래와 같았다.

Collision probability for 1000 generated codes: 0.0000000000
Collision probability for 10000 generated codes: 0.0000000000
Collision probability for 100000 generated codes: 0.0000000000
Collision probability for 1000000 generated codes: 0.0000000000
Collision probability for 10000000 generated codes: 0.0000000000
Collision probability for 300000000000000 generated codes: 0.0000000000

마지막에, 위 코드를 우리 팀에서 메인으로 사용하는 Typescript로 바꾸어 달라는 요청까지 완벽하게 해주는 것을 보면서, 이제 기획자의 입장에서 무언가 기술 리뷰를 받고자 할 때, 이런 식으로 직접 검증을 해보는 것도 가능하구나 라는 결론에 도달했다.

답을 공개하자면, UUID를 중복 걱정 없이 최대한 줄일 수 있는 것은 base62로 인코딩을 바꾸어 22자까지 줄일 수 있다는 것이다. 처음에 이야기한 것처럼 관련 경험이 있는 시니어 엔지니어가 있었다면 '그건 최대가 22자까지 줄일 수 있다.' 라고 바로 답을 해줄 수 있었겠지만, 개발을 잘 모르는 PM 입장에서 상호 변환되는 동작하는 코드 형태로 간단하게 이를 알아볼 수 있다는 부분에서 정말 놀라웠다.

그리고 무엇보다, 중간에 개인적으로 python library를 설치하는 과정에서 좀 오류가 있어 library를 사용하지 않는 버전으로 개발해달라고 요청하느라 좀 시간이 오래걸렸던 것을 제외하면 이 모든 과정이 대략 30분 남짓하게 소요되었다는 것이다.

무서운 세상이다.

유저 분석 자동화와 보상 최적화를 향한 여정

Wed, 11 Jan 2023 00:15:05 +0900

요약

새로운 회사에서 못해도 주에 최소 4시간 이상은 인사이트 담당자분의 시간을 투입해야 하는 데이터 분석 건이 있었다.
여기에 시간이 많이 드는 반면, 간소화 하지 못하는 데에는 2가지의 이유가 있었다. 하나는 필요한 데이터가 들어있는 DB가 2개 이상으로 분리되어 있어서 둘 사이에 join을 걸 수 없다는 것과, 다른 한가지는 유저 ID 기준으로 어떤 Action을 했는지 각 Action 별 Count를 세어야 하는데 그 대상이 되는 테이블이 30Gb을 넘다 보니, Groupby + Count Query로 접근하면 퍼포먼스 이슈가 있다는 점이었다.
파이썬으로 각 DB에서 필요한 데이터를 불러온 뒤, Pandas로 분석하여 Report를 만든 후, 회사의 Slack 채널에 뿌려주는 Script를 만들었다. 이를 통해 이 업무는 하루 한번 버튼을 눌러주면 되는 수준의 업무로 완전히 개선되었고, 주 1회 발행되던 리포트는 매일 최근 8일치 데이터를 보여주는 형태로 바뀌었다.
당연히 우리 팀은 오롯이 '분석'에만 초점을 맞출 수 있게 되었고, 분석된 데이터를 바탕으로 보상 정책을 수정할 수 있게 되었다는 행복한 엔딩.
그리고 그 과정에서 나는 약간의 개발 지식과, 파이썬을 활용한 환경 설정, 그리고 환경변수를 활용하여 중요 정보를 GitHub에 올리지 않는 방법을 배웠다.

왜 하게 되었나?

사설

파이썬으로 업무를 자동화 하는 것에 본격적인 관심을 가지기 시작했던 시점은 사실 2018년이었는데, 당시에 회사에서 ML 기반의 프로젝트를 담당하게 되면서 어께너머로 본 것도 있고, 이때를 기점으로 따로 이런저런 수업을 듣기도 했었다. 사실 이것 외에도 주식 관련 통계라던가, 경매 알리미 같은 토이 프로젝트를 하며 공부를 이어가고 있었다.

이전 직장인 라이엇 게임즈에서 아쉬웠던 점 중 하나가, 생각보다 회사 업무를 하면서 이런 부분을 직접 다룰 만한 기회가 생기지 않는 다는 것이었는데, 데이터 자체는 엄청나게 많지만 내 업무의 연관성이 아무래도 이쪽에 직결되지 않다 보니, 뭔가 의미있는 프로젝트를 스스로 만들기가 좀 어려웠다. 그러다 겨우겨우 발견했던 아이템 중 하나가 결국 마케팅팀과 인플루언서를 담당하는 팀이 유튜브 조회수를 한땀한땀 손으로 조사한다는 것이었고, 그렇게 그렇게 나온 토이 프로젝트 중 하나가 이 블로그에도 올려둔 유튜브 조회수 수집기이다.

진짜 배경 및 문제 정의

22년에 새롭게 합류한 플라네타리움에서는, 내가 담당하는 Product가 아무래도 유저의 Retention과 이를 위한 보상에 직결되는 서비스이다 보니, 자연스럽게 통계 데이터를 볼 일이 많아졌다. 함께 일을 하는 사업 PM 분이 워낙에 SQL을 잘 다루셔서, 대부분의 데이터는 가공된 형태로 받아볼 수 있었는데, 문제는 가끔 DB에 없는 데이터와 join을 하고자 하는 니즈가 발생한다는 것이었다. 그래서, 소스가 다른 두 곳의 데이터를 가져와야 한다면, 파이썬 스크립트로 이를 해결할 수 있지 않을까? 하는 생각에 착수하게 되었다. 덤으로, DB Query도 수동에서 자동으로 변경할 수 있을테니,일석 이조의 효과를 기대할 수 있었다.

게다가, 스타트업이라 회사에 리소스가 워낙 귀하다 보니, 다른 개발자 분들이 더 중요한 일을 할 수 있도록 방해를 하고 싶지 않은 마음도 있었고, 또 개인적으로 사이드 프로젝트로 회사 업무 효율을 높이는 경험을 해보면 좋겠다 싶어, 좋은 기회라 생각했다. 회사에도 득이 되고, 동료에게도 득이 되고, 나에게도 득이 되는, 안할 이유가 없는 프로젝트였다. 유일한 문제는 시간이라, 다른 일이 너무 안되거나 퇴근 후에 짬짬이, 토이 프로젝트로 접근하며 한발씩 천천히 나아갔다.

문제 1: 여러 곳에 분산되어 있는 데이터

우리 서비스의 분석을 위해 필요한 데이터는 크게 두 곳에 담겨 있다. 우선 서비스 자체가 둘로 나뉘어져 있었다. 블록체인 위에 모든 데이터가 올라가 있는 우리 회사의 게임과, 그 게임을 플레이하는 유저들의 온보딩 및 리텐션을 담당하는 '포탈'의 DB였다. 다행히 블록체인 쪽 데이터는 분석을 위해 RDB로 내려주는 서비스를 내부 개발자 분이 미리 만들어 주셔서 2가지 데이터 모두 RDB를 대상으로 Query를 하면 되는 상황이엇지만, 데이터가 두 곳으로 나뉘어져 있으니, 이 둘을 join하는 것은 임시 table을 만들어 update를 하지 않는 이상 쉽진 않았다. 심지어 한쪽은 블록체인 데이터의 사본인 '읽기' 전용의 DB지만, 다른 한쪽은 라이브 서비스를 진행 중인 Production DB였다. 이 DB의 사본을 만들어 달라고 하는 것도 물론 가능했지만, 위에도 적었듯이 '그 작업을 할 시간에 다른 더 귀한 일'을 해야 하는 스타트업이다. DB를 이중화 하기 보다는, 가벼운 Query를 던져 서비스에 무리가 가지 않는 수준에서 같은 DB를 쓰는게 우선은 더 낫다고 판단했다.

문제 2: 연산이 무거워서 DB 에 직접 Query를 하기 어려움

우리는 게임 데이터를 바탕으로, 게임을 열심히 하는 열성 유저 (Heavy, 이하 H그룹) 그룹과 일일 보상 정도만 챙기는 라이트 유저 (이하 L그룹) 을 나누고자 했는데, 문제는 이 연산 자체가 매우 방대했다. 우리 게임의 특징은, 모든 Action이 다 블록체인에 기록된다는 점인데, 이렇다 보니 하루에도 수십만 줄의 Action 데이터가 남았다. 분석하기엔 좋았지만, DB에 대놓고 직접 query를 던지기엔 퍼포먼스 이슈가 컸다. 특히 그 Action 관련 Table은 우리 블록체인의 '태초(Genesis)' 블록부터 데이터가 있어서, 그 용량이 30Gb을 가볍게 웃돌았다. 여기에 대놓고 Unique, Groupby, COUNT 같은 걸 날리기엔, 아무리 최적화를 해도 살떨리는 일이었다.

자, 문제를 파악했고. Solution도 생각보다 간단했다.

무었을 했나?

문제1, 2가 워낙 직관적이고 심플해서, 구현만 하면 되었다. 그래서 간단하게 설계를 해보았다. 설계를 다 하고 나니, 구현이 그리 어려울 것도 없어 보였다. 아마 평소에 SQL이나 Pandas 에 익숙한 분이 했다면 넉넉잡아 2-3일 만에 마칠 수 있는 업무의 분량이 아니었을까 싶다.

우선 데이터가 분산되어 있으니 하나의 공간으로 모아야 했다. 어차피 데이터를 받아온 뒤의 처리는 Pandas를 이용할 예정이었으므로, 우선 local로 다 모으는 쪽으로 했다.
유저를 H그룹과 L그룹으로 나누기 위해서, 가능한 긴 기간이면서도 DB에 부하가 어느정도 감내 가능한 수준의 구간을 잡으려고 했다. 이 과정에서 일주일 정도가 적당하다고 결론을 내렸고, Action 관련 테이블에서 7일치 데이터만을 가져오기로 하였다. 그렇게 한번씩 가져오면, 약 0.4Gb 정도가 local에 쌓였다. (이 부분은 결국 추후 개선이 필요하게 된다. 한방에 0.4Gb를 긁어오는 Query라니...)
H그룹과 L그룹으로 나누는 코드 자체도, 결국 Pandas로 했다. 각 유저의 고유 ID (Web3 게임이니 Address를 기준으로) 를 기준으로, 일자별로 - 어떤 유저가 - 어떤 Action을 몇번씩 했는지, Count만 남기는 식으로 Aggregate한 테이블을 임시로 만들었다. 그 테이블을 바탕으로, 내부 정책에 따라 평균 Score를 메긴 뒤, H그룹과 L그룹으로 구분했다. 결국 각 그룹에 속한 유저의 고유 ID를 알 수있게 되었다.
결국 하고자 했던 것은, H그룹은 더 보상을 많이 가져가고, L그룹에 지출되는 보상의 총량은 합리적인 수준까지 낮추는 것이었다. 보상을 제공할 수 있는 Pool이 한정적인 만큼, 더 충성도가 높고 활동이 많은 고객이 보상을 더 가져가게 하는 것이 서비스를 위해 맞는 방향이었다. 그래서 최근 7일 동안 H그룹과 L그룹이 가져간 보상의 총량을, '보상' 테이블과 위에서 만든 그룹별 ID를 매핑하여 산출할 수 있었다.

위 까지가 분석에 해당했고, 처음에는 이를 csv 파일로 떨구게 만들었다. 이를 사업 PM 분의 PC에도 설치해드리고, 내 PC에도 설치를 했는데 뭔가 좀 아쉬웠다. 이전에 텔레그램 경매 알리미를 만들었던 경험을 살려서, 많은 사람들이 편하게 볼 수 있도록 Slack에 쏴줘야지- 라는 곳까지 생각이 나아갔다. 기존에도 tabulate를 이용하면 테이블을 이쁘게 마크다운으로 보여줄 수 있다는 것을 알고 있어서, Slack 채널에 본문으로 보여주고 CSV 파일도 함께 업로드 해주는 기능까지 구현을 해버렸다.

이 과정에서의 챌린지 + 헤딩

우선 DB 종류가 다르고, DB 관련 Python Library를 써본 적이 없었다.

DB 중 하나는 MySQL인데, 다른 하나는 postgresql 이었다. Query도 아주 약간 다르긴 했는데 무시해도 될 수준이었지만, 문제는 내가 Python으로 DB에서 직접 데이터를 가져오는 것을 해본 적이 없다는 것이었다. MySQL의 경우는 Pandas 자체에서 pd.read_sql 이라는 기능을 제공했지만, psql은 경험이 없어서 psql을 지원하는 library를 찾아보아야 했다. 이 과정에서, psycopg2가 이를 담당해준다는 것을 알게 되었고, 맥용 라이브러리는 어째서인가 살짝 다른 버전을 install 해야 한다는 것 외에는 크게 문제가 없었다.

Jupyter notebook, data type, convention...

사실 DB Connection 자체를 처음 해보기도 하고, Pycharm 등의 IDE에서 디버깅을 하는 방법을 아직 잘 모른다. 그래서 Anaconda와 Jupyter notebook을 활용해서 코드를 한줄한줄 돌려보며 작업을 진행했고, 코드가 얼추 검증되고 나면 이를 pycharm으로 옮겨서 함수형으로 코드를 정리했다. 이 과정에서 가능하면 가까운 미래에 내 산출물을 보고 내부 엔지니어 중 누군가가 이를 서버에 올려주거나 좀 개선해주지 않을까 싶은 마음에, 최대한 주석을 잘 달고 변수명도 좀 Convention을 맞추어 해보고 싶었다. 근데 역시 숙련도가 부족하여 잘 안되긴 했다. Convention도 엉망이고. 대략 아래와 같달까.

다시 한번, 서버 엔지니어 분들의 기술에 경의를 표하게 되는 계기가 되었다. 역시 프로그래밍은 어렵다.

늘 이런 일을 할 때 내가 제일 어려운 건 Data type에 따른 처리이다. 위의 주석에도 달아두었지만, 아직까지 나는 Data type에 따른 처리가 경험이 부족하다. 매번 봇 만들때마다 이전에 했던 노하우도 싹 기억에서 초기화 되는 것 같고. 그래도 일단 잘 돌아가니 다행!

결과?

그래서 그 산출물은 아래와 같이 생겼다. 아직은 하루에 한번, 내 로컬 환경에서 '실행'을 눌러주어야 동작하는 말 그대로 스크립트 이고, 내 맥이 잠자고 있는 동안에는 실행을 할 수 없어서 아직 Scheduler를 걸어두진 못했다. Slack bot으로 만들어 두었기 때문에, 내가 지정한 채널에 하루에 한번 리포트를 올려준다. 예전엔 주간 미팅에서 한번씩 지표를 보여주는 것이 전부였지만, 이제는 관심이 있는 사람은 누구든 채널에 와서 이 지표를 볼 수 있다. 심지어 슬랙에 최적화된 형태로 뿌려주는데 고민을 많이 해서, 아래 보는 것처럼 예쁜 표로 (디자이너 눈엔 어디가 이쁘냐 하겠지만) 출력이 되며 CSV 파일도 준다.

회사 Slack 채널에 내가 만든 봇이 매일 리포트를 쏴준다. 아직은 하루 한번 발사 버튼을 눌러줘야 한다.

기존에는 한번 데이터 보려면 못해도 한 3-4시간은 금방 날아가는 작업이었는데, 이를 버튼 한번만 누르고 한 10분 기다리면 되는 수준으로 (물론 10분동안 딴짓하면 알아서 채널에 올라가 있다) 획기적으로 단축을 해냈다.

위에 요약에도 적었지만, 당연히 우리 팀은 이제 '분석'에만 초점을 맞출 수 있게 되었고, 분석된 데이터를 바탕으로 보상 정책을 수정할 수 있게 되었다는 행복한 엔딩이다. 실제로 작년 말 기준, 보상 관련 최적화로 지표가 많이 개선되기도 하였고, 현재 기준으로는 ~~내가 없는 날엔 리포트가 안나가니 회사 내에서 존재감을 어필하기에 나쁘지 않은 접근인 것 같기도 하다.~~

그리고 그 과정에서, 나는 개발적으로 크게 2가지를 더 배웠는데, 하나는 requirements.txt로 python library들을 빼서 다른 PC나 환경에 쉽게 프로젝트를 세팅할 수 있도록 하는 것과..

지금까지 이론으로만 알고 있던, 중요한 credential 같은 정보를 .env로 빼는 방법을 우리 회사 다른 시니어 엔지니어분에게 배울 수 있었다! 이론만 알고 있어서 어떻게 하는지가 매우 궁금했는데, 이제 어떻게 하는지 배웠으니 이후에 개인 프로젝트에서도 유용히 써먹을 수 있겠다.

남은 과제

원래 내부 엔지니어 분의 도움을 받아, 위 스크립트를 하루에 한번 동작하도록 t1 micro 같은 인스턴스에 올려두려고 했었는데...
최초에 Script 자체를 1주일에 한번 weekly report를 만든다고 가정하고 작성을 하다 보니, 데이터가 7일치가 필요하여 0.3~0.4gb 짜리 데이터를 DB connection을 열고 받아온다. 결국 내가 만든 스크립트가 인스턴스를 죽였고 ㅋㅋㅋ 최적화를 해야 올릴 수 있을 것 같다고 피드백을 받았다.
이왕 스케쥴러를 설정할 수 있는 환경에 두기로 하였으니, 로컬 캐시를 두고 저 7일치 데이터를 최대한 작게 슬라이싱해서 가져와서, 그 결과값만 남기는 식으로 코드를 개선할 예정이다.

스케쥴러로 동작한다고 가정을 하면, 지금 통으로 짜둔 함수들을 좀 기능별로 나누어서 refactoring을 하고, 데이터 수집과 데이터 후가공, 리포트 가공 등으로 코드를 나누긴 해야 할 것 같다. 이 부분은 짬이 되면 더 하거나, 팀에 새로 오시는 엔지니어 분에게 토이 프로젝트로 넘겨드리려고 한다.

이상, 이직 후 개인적으로 가장 마음에 드는 성과 중 하나에 대한 회고를 마쳐본다.

유튜브 조회수 수집기 (YouTube View count Scraper)

Mon, 24 May 2021 23:56:34 +0900

요약

이 조회수 수집기는 내가 원하는 채널 안에 있는 모든 비디오의 현재 조회수를 긁어 줍니다.
사용하려면 Python이 필요합니다.
YouTube API 사용 신청이 필요합니다.

왜 만들게 되었나?

개인적으로 Python을 통한 데이터 분석이나, 파이썬 업무 자동화와 관련된 부분에 관심이 많습니다. 이 과정에서, 회사에서 몇몇 동료 분들이 YouTube 조회수를 손으로 확인하시는 모습을 보고 한번 토이 프로젝트로 진행을 해보았습니다.

비디오 개수가 많지 않다면, 물론 손으로 확인하는 것도 충분히 편리합니다. 그리고 내가 소유하고 있는 채널의 경우는, 관리자 페이지를 통해서 좀 더 편하게 조회수를 확인할 수 있습니다.

하지만, 다음과 같은 경우에는 이 수집기를 사용해 보시는 것도 좋을 것 같습니다.

유명하다는 그 인플루언서, 채널 누적 조회수는 알겠는데 평균 조회수는 얼마가 나오지? 가장 인기 있는 동영상은 뭐고, 일 평균 조회수 가장 낮은 동영상은 뭐지?
내 소유 채널이 아닌데, 하루에 한 번씩 동향 보고를 만들어야 한다.
우리 회사 채널인데, 관리자 권한이 나는 없다. 그런데 조회수 동향을 매일 살펴봐야 한다.

어떻게 쓰나요?

설치방법

이 코드를 실행하는데 필요한 것은 다음과 같습니다.

프로그램 실행을 위한 코드: https://github.com/Gilhwan/youtube_scraper
Python 3.6 이상
Google Client API Python 라이브러리

googleapis/google-api-python-client

The official Python client library for Google's discovery based APIs. - googleapis/google-api-python-client

github.com

Pandas

pandas - Python Data Analysis Library

pandas pandas is a fast, powerful, flexible and easy to use open source data analysis and manipulation tool, built on top of the Python programming language. Install pandas now!

pandas.pydata.org

그럼 하나하나 어떻게 설치하면 좋은지 따라 해 봅시다.

1. 우선 코드를 내려받아야 합니다.

https://github.com/Gilhwan/youtube_scraper에 접속하면, 파일을 다운로드할 수 있습니다. 아래에서 code > Download Zip을 하시면 됩니다.

Download Zip으로 한번에 다운받을 수 있습니다.

압축파일로 다운로드가 되니, 적절한 곳에 압축을 풉시다.

Run.bat 파일로 실행을 하면 되고, gil_youtube.scraper.py는 파이썬 코드입니다.

사실 실제로 필요한 것은 .py 파일 뿐이지만, .py만 다운로드하여서 실행 가능하신 분이라면 굳이 '어떻게 쓰나요?' 부분을 읽으실 필요가 없겠죠.

아직은 python도 없고 라이브러리도 없어서, 동작하지 않습니다.

유튜브 조회수 수집기를 실행하려면, python 과 2개의 라이브러리를 설치할 필요가 있습니다.

2. Python을 설치합니다. Anaconda를 이용하여 설치하면 더욱 쉽습니다.

Anaconda는 Python을 이용하여 데이터 분석이나 머신러닝 관련 개발이 필요한 경우, Python을 포함한 여러 라이브러리를 편하게 설치/관리할 수 있도록 도와주는 도구입니다. 설치 방법을 자세하게 다루기보다는, 좋은 블로그 링크를 하나 첨부합니다.

3. Anaconda를 설치한 뒤에는 Anaconda prompt를 실행합니다.

윈도우를 기준으로, (키보드의) 시작 버튼 > Anaconda Prompt 라고 입력하시면, 실행하실 수 있습니다.
요렇게 '검색' 해서 실행하시면 됩니다.

4. pip install로 아래 2가지를 설치합니다.

anaconda prompt 화면

위와 같이 pip install 이후에 라이브러리 이름을 입력하고 엔터를 치면 됩니다.

아래 2가지를 순서대로 입력합니다.

pip install google-api-python-client
pip install pandas

중간에 설치 여부를 묻는 창 (y/n)이 나온다면, y를 입력합니다.

5. YouTube API Key를 등록해야 합니다.

이 프로그램은 YouTube Data API v3를 사용합니다. 해당 API는 개인의 경우 테스트 용도로 무료로 발급받을 수 있습니다.

일 최대 10,000번 호출하여 사용할 수 있고, 비디오 1개의 조회수를 확인할 때마다 1번의 호출이 발생합니다.

또한, 최초에 채널명과 전체 비디오 목록을 가져오기 위해서 2번을 추가로 호출합니다.

위의 이유로, API Key를 넣어서 배포하는 것이 불가능합니다.

YouTube API Key를 발급받는 방법 또한 더욱 자세히 설명이 되어 있는 블로그가 있어, 링크로 대체합니다.

6. 마지막으로, API key를 프로그램 내에 삽입해주어야 합니다.

gil_youtube_scraper.py 파일 안에는 다음과 같이, api_key를 입력해야 하는 부분이 있습니다.

<-- change here--> 에 입력해주면 됩니다.

메모장으로 gil_youtube_scraper.py를 열어도 좋고, .py 파일을 편집하기에 편리한 편집기(IDE)를 사용하셔도 좋습니다.

개인적으로는 pycharm(무료)을 선호하며, pycharm을 설치하여 해당 파일을 열면 위와 같은 화면을 보실 수 있습니다.

<--change here--> 에 본인의 api key를 넣어주면 설치는 모두 끝납니다.

사용방법

1. Run.bat를 더블 클릭하여 실행합니다. 아래와 같은 화면이 나오면 정상적으로 python과 라이브러리 2가지가 설치된 것입니다.

여기까지 나오면 제대로 설치가 된 것입니다.

2. 채널 아이디를 복사/붙여 넣습니다. 채널 아이디 확인 방법은 다음과 같습니다.

유튜브 채널 주소의 빨간 부분 (yt.com/channel/~~~~) 이 채널 아이디 입니다.

3. 채널 아이디를 붙여 넣고 엔터를 치면 끝입니다.

이렇게 설명이 나오면서 동작을 시작합니다.

동작이 완료되면, 채널명_날짜.csv 가 생성됩니다.

끝으로

사실 코드 자체만 열어놓고 본다면, 매우 간단한 수준의 코드입니다.

YouTube 채널 아이디에서, uploads라는 플레이리스트를 가져옵니다. Uploads는 YouTube에서 모든 채널에 기본적으로 생성하는 비디오 리스트입니다. ('동영상'에 해당)
해당 플레이리스트 내에 있는 모든 비디오 ID를 가져옵니다.
각 비디오 ID 별로 한 번씩, YouTube Data API v3를 호출하여 조회수, 좋아요, 싫어요, 댓글 수, 등록된 날짜를 가져옵니다. 여기서, 등록된 날짜(시간)가 UTC여서, 이를 KST로 변환합니다.
오늘 날짜를 기록합니다.

또, 이 코드 자체가 엄청 독창적이거나 하진 않습니다. 인터넷에 유튜브 조회수 수집이라고 검색을 해보면, 여러 코드가 나오는데 이를 참고하여 만들었습니다. 셀레니움이라는 라이브러리를 활용한 방식도 있지만, 이왕이면 구글, 유튜브가 정식으로 제공하는 API를 사용하여 만드는 쪽이 더 공부가 될 것 같아, 이 방식을 택했습니다.

다만, 인터넷에 이미 코드가 올라와 있어도 이걸 막상 기획자나 마케터가 따라서 만들기에는 배경지식이 많이 필요하고, 또 직접 시도해보려면 시행착오가 많을 수 있는 부분이어서 직접 따라 해 본 것을 사용법과 함께 블로그 글 형태로 정리해보았습니다.

휴대전화번호가 최악의 회원가입 수단인 이유: 클럽하우스 사례

Mon, 22 Feb 2021 23:28:29 +0900

최근에 iOS에서 붐인 클럽하우스 App을 보면, 회원가입 절차가 휴대전화 번호 기반으로 되어 있다. 일견 간편한 가입 수단이라고 생각할 수 있지만, 사실 휴대전화 번호는 계정으로 사용하기에는 매우 많은 단점들을 가지고 있다.

그럼에도 불구하고 클럽하우스가 휴대전화번호로 회원가입을 시키는 이유와 함께 한국 서비스에 휴대전화 번호로 회원가입을 넣게 될 경우 만나게 될 지옥들에 대해서 한번 이야기해보려고 한다.

우선, 클럽하우스는 왜?

클럽하우스가 계정을 휴대전화번호로 설정한 다양한 이유가 있겠지만, 이렇게 만든 이유를 간단하게 역기획 해보자면 무엇보다 큰 이유는 ‘주소록’이다.

클럽하우스는 휴대전화 번호를 기반으로 초대를 받거나, 혹은 기존의 회원의 확인 (Let them in!)이 있어야 가입이 가능한 일종의 Closed network이다. 이렇게 이유하는 이유에는 여러 가지가 있겠지만, 그중 한 가지는 서비스 초기에 운영 Cost를 줄이는데 큰 역할을 하기 때문이다.

클하 쓰고 있는 친구 없으면 가입 못함

안 그래도 최근, Clubhouse 내에서도 다양한 트롤링 사례들이 언급되고 있는데, 이를 모니터링하고 차단할 방법이 현재로는 사용자의 신고 외에는 없다. 클럽하우스는 아직 운영인력도 ‘채용중’인 상태고, 음성을 녹음하여 리뷰하지 않는다. 이 2가지 사례만 보아도, 클럽하우스는 ‘지인 기반 Closed network이니 함부로 트롤링을 하지 못할 것이다.’라는 가설을 깔고 있다는 것을 알 수 있다.

주소록을 수집해서 단순히 ‘홍보’를 하려고 하는 것이 아니라, 서비스에 가입하는 사람들과 & 서비스에 가입된 사람들의 품질 관리를 사용자에게 시키는 구조인 셈이다.

그 외에 장점은 없을까?

무엇보다 휴대전화번호는 신뢰할 수 있고, 도달률이 높은 연락처다. 이메일도 verification을 거치면 신뢰할 수 있는 연락처가 되기는 한다. 하지만 이메일의 치명적인 단점은 도달률이다. ‘필수로 읽어보셔야 하는 정보입니다.’라는 메일을 보내도 1 자릿수의 Open rate을 기록하는 경우가 많은데, 휴대폰은 상대적으로 메시지를 확인할 확률이 높다. 더불어, 정 급한 경우 전화를 해버릴 수도 있다. 그래서 오프라인 서비스와 연계되는 배달이나 중고거래 (예: 번개장터) 서비스에서는 휴대전화 번호를 그 자체로 계정으로 사용하는 경우도 종종 있다.

더불어 국내기업 한정 일지 모르지만, 사용자들에게 이메일보다 선호된다. 아무래도 앞서 이야기 한 이메일의 오픈율과도 관계가 있지만, 국내 사용자들이 가장 선호하는 이메일 ‘네이버’의 경우 그 계정으로 가입한 카페, 구독 중인 블로그, 그 외 다양한 이유로 수집된 경우 등을 바탕으로 메일함을 도무지 사용할 수 없을 정도로 스팸이 넘쳐난다. 본래도 이메일이라는 채널 자체가, 스팸의 온상이 되기 쉬운 환경인데, 외국은 ‘봇’이라면, 국내 사용자들은 여기에 카페/블로그가 크게 한몫 기여한다.

이러다 보니, 사용자들도 이메일로 알림을 받는 것 보다, 휴대전화 번호로 알림을 받기를 더 좋아한다. 회원가입 단계에서 이메일을 인증하는 것보다 휴대전화 번호로 인증하는 것이 더 편하다고 느끼는 경우가 많다. (그리고 자연스레 국내 서비스들은 유독, 휴대전화 번호를 많이 수집한다. 마케터들도 도달률이 더 높은 휴대폰을 선호하기도 하고.)

다만, 이 부분은 현재의 10대처럼 ‘태어나서 처음 사용해본 인터넷 환경이 스마트폰’인 세대에게는 더 이상 선호되지 않는 수단이기도 하다. (버튼만 누르면 로그인이 되는 Social 계정을 두고 굳이 다른 정보를 입력하는 수고를 들여야 하는 걸 이해하기 어려울거다.)

여기까지 보면, 휴대전화 번호는 매우 좋은 회원가입 수단이다.

그럼 이렇게 좋은 장점을 가진 ‘휴대전화 번호’ 기반 회원가입이 왜 최악인지, 특히 ‘한국기업’에게 있어서 얼마나 끔찍한 의사결정이 될 가능성이 있는지에 대해서 한번 이야기해보겠다.

우선 돈이 많이 든다.

먼저, 배경지식이 없는 분들을 위해 간단히 설명하자면 휴대전화 번호를 기반으로 인증을 하는 데는 크게 2가지 방식이 있다. 한 가지는 점유 인증 (휴대폰을 현재 소유하고 있는지)이고, 다른 하나는 본인 확인 (휴대폰을 소유하고 있는 사람의 실명과 생년월일을 함께 확인하는) 방식이다.

여러 가지 규제로 인해서 실명으로 반드시 이용해야 하는 서비스의 경우, 회원가입 시 울며 겨자 먹기로 본인 확인을 포함해야 하는 경우가 많다. 이때의 인증비용은 회사마다 사정이 다르겠지만, 절대 저렴하지 않은 비용이 ‘건당’ 발생한다. (규모나 계약에 따라 다르지만, 약 30~60원 내외.)

법률적인 이유로 반드시 생년월일과 실명을 인증 후에 수집해야 하는 경우가 아니라면, 상대적으로 저렴한 ‘점유 인증’을 선택할 수 있다. 이 경우는 제공사마다 다르지만, 약 6~10원 정도의 비용이 발생한다. 무엇보다 이는 ‘건당’이고, 인증 시도를 여러 번 하게 되는 경우 xN 만큼의 비용이 발생한다.

하루에 10만 명이 가입하는 대박이 났다고 가정하면, 하루 100만 원 인증비용이 발생하는 거다. 결코 ‘저렴’ 하지는 않다. (그리고, Clubhouse는 1월 200만 명이 추가로 가입했다. 아마도 Amazon SNS를 썼을 텐데, SMS만 최소 1400만 원 썼다는 소리다.)

휴대전화 번호는 생각보다 신뢰할 수 없다.

대부분 2년에 한번 휴대폰을 바꾼다.

한국 통신사업자 협회의 발표 자료에 따르면, 2020년 한 해 동안 ‘번호이동’을 한 가입자의 수가 540만 명이다. 번호이동이란, 사용하던 휴대전화 번호를 들고 휴대폰 회사(통신사)를 바꾸는 행위이다. 과거 011 시절의 번호이동과는 다르게, 통신사가 바뀐다고 하여 반드시 번호가 바뀐다고 장담하긴 어렵지만, 010 국번 내에서도 여전히 통신사 별로 사용 불가능한 번호대가 있다.

대한민국의 휴대폰 가입 현황은 이미 100%를 넘었고, 대한민국의 인구는 5천만이다. 540만 명이면, 못해도 이중 10%는 ‘매년’ 휴대전화 번호가 바뀔 가능성을 지니고 있다는 의미이다.

혹시 데이터 함께 쓰기로 회선을 개통한 뒤에, 혹은 휴대전화 번호를 새로 개통한 뒤에, 나는 처음 쓰는 번호인데 엄청난 스팸이 오는 경험을 해본 적이 없는가? 혹은 카카오톡으로 갑자기, 나는 신청한 적 없는 택배 알림이나, 보험금 지급 관련 안내가 나에게 날아오는 경험을 해본 적이 있지 않나? 그 모든 게, ‘이전에 이 번호를 사용하던 사람’ 때문일지도 모른다. (혹은 단순히 오타를 냈거나.)

개발비용 (혹은 Engineering cost)이 많이 든다.

국내외를 막론하고, 휴대전화 번호는 개인정보다. 국내법에서도 개인정보의 취급과 처리에 다양한 법률적인 요구사항들이 존재한다. (예를들어, 개인정보는 다른 데이터와 분리보관 되어야 하며, 사용자의 요청에 따라 언제든지 삭제될 수 있어야 한다. 또한 사용목적이 달성된 경우, 그 즉시 파기 되어야 한다.)

다른 개인정보들도 마찬가지지만, 휴대전화번호는 특히 주의를 기울어야 하는 정보 중 하나다. 앞서 이야기한 것처럼 ‘간단히’ 수집할 수 있는 정보인 데다, 번호는 그대로인데 소유자가 바뀌기도 하는 개인정보다. 누군가 “본인이 가입하지 않았는데 내 휴대전화 번호가 사용되고 있다.”라는 민원이라도 들어오는 경우, 이를 적시에 파기해줄 수 있는 운영 도구가 필요하다.

더욱이 이렇게 ‘가변적인’ 데이터를 회원을 구분하는 main key 값으로 쓰겠다는 접근은 정말 위험하다.

대표적인 최악의 경우, 아래와 같은 시나리오가 발생할 수도 있다.

A라는 사용자가 휴대폰 번호 010-####-5678 이라는 번호로 회원가입을 했다.
우리 서비스에 약 10만원 정도, 콘텐츠 이용을 위한 포인트를 충전했다.
A라는 사용자가 휴대폰번호를 010-####-1234로 변경했다.
위의 5678이라는 휴대전화 번호로 더 이상 로그인을 할 수 없어, 서비스를 이용할 수 없다.
어찌어찌 고객센터를 통해 환불을 요청할 수 있지만, 우리는 5678의 주인이 A인지 알 길이 없다.
A가 신분증 사본을 보낸다 하더라도, 번호 1234의 현 주인이 A라는 사실만 확인할 수 있다.
우리가 다행히 A의 정보를 ‘본인 확인’을 받아 가입 시에 보관했다고 가정해도, A와 생일이 같고 동명이인인 가능성을 배제할 수는 없다.

위와 같은 상황에서, 콘텐츠분쟁조정위원회라던가, 소비자보호원 등을 통해 민원이라도 접수되는 날에는, 사용자 A에게 10만원을 최대한 빠르게 환불해주어야 하는 사태가 발생한다. 환불이 끝나고, 알고 보니 A의 동생 B와 서로 번호를 바꾸었고, 우리는 A에게 10만 원을 환불해 주었는데, B가 “내 계정의 10만 원이 사라졌다.”라며 민원을 넣는 가능성도 절대 0은 아니다.

해결방법이자 많은 서비스가 채택하는 대안

사실 이 글은, 회원 서비스를 기획해본 경험이 없는 기획자 또는 회원 서비스를 개발해본 적이 없는 개발자에게 조금이라도 도움이 되었으면 하는 마음에 작성을 하게 되었다. (구글링을 해도, 회원 서비스 기획과 관련된 자료는 잘 없는 것 같아서.)

정리하자면, 휴대전화 번호를 계정 시스템의 Key로 두는 것은 매우 위험한 행위이다. 휴대전화 번호로 회원가입을 하도록 하자는 의견을 PM, 기획자가 제시하는 경우, 이러한 경험이 없는 엔지니어는 자연스럽게 ‘휴대전화 번호’를 고유 Key 값으로 설계를 해버리기도 한다.

여러 가지 대안이 있지만, 가장 추천하고자 하는 대안은 휴대전화 번호를 계정으로 사용하지 않는 거다. 휴대전화 번호는 보조적인 수단으로 사용되어야 하는, 이메일 주소보다도 더 쉽게 바뀔 수 있는 정보다.

그리고 설령, 모종의 이유 (임원이 꼭 휴대폰 번호로 회원가입을 시켜야 한다고 우긴다거나)로 휴대전화 번호를 계정으로 사용해야 한다면, 개발팀과 위 내용을 상의하여 반드시 ‘대체수단’을 함께 등록하고 관리할 수 있도록 하자.

게임 회사가 IE에 대응하는 조금 색다른 방법

Fri, 12 Feb 2021 07:20:14 +0900

배경

IE, Internet Explorer는 많은 경우, 웹 환경으로 서비스를 제공하는 Product 조직에게 매우 골치아픈 브라우저다. 어째서 IE가 골치아픈 브라우저인지에 대해서는 굳이 자세히 설명하지 않아도 많은 레퍼런스가 있으니 간단히 넘어가도록 해보자.

"바퀴를 두번 만들 필요는 없다." 라는 말이 있다.

Product 조직에 위 이야기를 적용하자면, 같은 기능을 하는 어플리케이션을 각 부서에서 만드는 것은 낭비란 말이다. 즉, 회원가입이나 계정 관리와 같은 기능은 매우 당연하게도, 전사에서 한 부서가 만드는 것이 좋다고 느껴지기 마련이다.

다른 한편으로, 계정과 같이 전사가 사용하는 기능의 경우, 각 지역의 환경도 고려해야 하지만 동시에 통일된 기술 스택을 가져가야 효율적이다. 특히, 우리 회사처럼 20개국이 넘는 곳에 오피스가 있고, 이중 개발 조직을 가진 오피스도 (내가 아는 한) 4개 지역이 되는 곳에서는 가능한 통일된 개발 환경을 가져가는 것이 협업을 위해 중요하다.

-라는 것이, 사실 교과서적인 접근이고, 전사 차원에서 정해진 웹 환경을 기준으로 개발하는 것이, 지역 오피스에 있는 PM인 나에게 있어서는 변경 불가능한 변수 중에 하나이기도 했다.

그럼에도 불구하고, 이상론과는 다르게 여러 지역에 서비스를 제공하다 보면 자연스럽게 각 지역에 맞춘 Customize가 필요하다. 특히, 개인정보와 관련된 기능인 '계정'과 관련된 부분에서는 각 국가에서 요구하는 가이드라인, 즉 Compliance 측면의 요구사항이 다르다.

내가 현재 몸담고 있는 회사는 145개국에 서비스를 제공하고 있다. 그 중에서도 크게 아래의 지역들은 동일한 배경을 가진 요구사항 (미성년자의 보호, 개인정보의 보호) 에 대해서도 구체적인 가이드라인이 엄청나게 다르다. 사실 나머지 지역들도, 내가 요구사항을 정확하게 알지 못할 뿐, 다른 부분이 많이 존재할지도 모른다.

북미
유럽
한국
동남아시아
러시아
일본

이처럼 '요구사항'이 다른 것 외에도, 지역에 따라 다른 것들이 몇가지 더 있는데, 대표적으로 사람들의 습관이 다르고, 이용 환경이 다르다. 특히 한국의 경우, 다른 지역과는 다르게 매우 높은 IE 선호도와 함께 PC방 환경이라는 특이성을 가지고 있다.

IE를 지원해야 했던 이유

앞서 이야기 한 것과 같이 Global 공통으로 사용하는 기능에 관해서, 각 지역별로 Customize가 들어간 기능이 필요한 경우가 있다. 다행히도 한국 오피스는 이를 자체적으로 소화할 수 있는 개발 조직을 갖추고 있고, 이러한 부분을 직접 개발, 관리해 왔다.

2020년 이전까지는 우리 오피스도 당연히 한국 지역의 특성을 가장 중요하게 고려했다. 즉, 모든 기능을 릴리즈 할때 IE 호환성을 염두에 두었다. 또한 한국에서 직접 개발하지 않는 사이트에 대해서도, Central (본사) 측의 개발팀에 IE를 사용하는 한국의 특징에 대해 매우 열심히 커뮤니케이션했다. 대표적인 사이트가 링크의 페이지로, 한국 팀에서 직접 개발하지 않았지만 한국 오피스의 요청으로 IE 호환성을 지킨 케이스이다.

특히, 우리가 IE 호환성을 매우 중요하게 생각했던 이유 중 또 다른 한가지는 바로 PC방 환경이다.

요즘 아무리 크롬에 대한 선호도가 올라갔다 하더라도, 우리 회사의 게임은 필연적으로 PC방에서의 접속이 많다. PC방에서는 다들, 윈도우에 기본으로 설정되어 있는 브라우저를 사용한다. 자기 PC가 아닌 만큼, 별도로 브라우저를 설치하여 인터넷을 이용하는 경우는 매우 드물다. 문제는 우리나라 PC방 환경은 99.9%가 윈도우를 사용하고 있다는 것이고, 그 윈도우의 기본 브라우저는 바로 Edge (그 중에서도, IE 기반의 구형 Edge) 또는 IE 11이라는 것이다.

자연스럽게, 회사에서는 매우 오랫동안 IE 호환성을 신경 써왔다. 올해 우리 개발팀이 과감한 실험을 도입하기 전까지는 말이다. 우리는 사내에서, 이 의사결정을 "님폰없"이라고 부르기로 했다.

It turns out, you guys actually have phones.

회원가입은 여전히 우리 서비스, 즉 게임을 이용하기 위해서 반드시 필요한 기능 중 하나이다. 물론 LoL은 오래된 게임이고, 많은 경우 이미 계정을 가지고 있지만 2020년은 새로운 신작이 많이 출시되는 기점인 만큼, 신규 회원가입의 양도 엄청나게 늘어났다. 즉, '회원가입'은 우리 회사의 신규 고객의 첫 동선인 것이다.

그 첫 동선의 많은 비중은 여전히 PC방이다. 협동을 중요시 하는 게임을 좋아하는 회사의 특성 상, '친구'와 PC방에서 게임을 시작하는 경우가 여전히 많고, 이 PC방이라는 환경은 도무지 예측을 할 수 없는, 하지만 동시에 무시할 수 없는 환경이다.

하지만 앞선 포스팅에서 몇번 이야기했던 바와 같이, 우리팀은 개발자 2.5명과, 전사의 서비스 디자인을 담당하는 디자이너 1명, 그리고 PM인 내가 함께 일하는 작은 조직이다. 늘 리소스는 부족하고, 할일은 많다. (그리고 회원 관련 기능은 외주를 맡기기도 매우 어렵다.)

작은 조직에서의 Product Roadmap 관리 이야기

이직 2년차 회고: Global 게임 회사의 Product manager - (2) Previously on Gi's retro "회사에 필요한 일이면서, 내가 잘할 수 있는 일, 그리고 회사도 나도 내가 하면 좋을 것 같다는 일을 맡아볼 수 있는 기회.

gilhwan.com

그리고 2020년, 마침 PC에 최적화 되어 있던 회원 관련 기능들의 모바일 대응이 거의 끝나가고 있었고, 나는 카카오 페이나 각종 결제 서비스 덕분에 익숙한 QR을 회원에 적용해보자고 제안을 한다.

우리가 타겟으로 하고 있는 사용자의 시나리오는 대략 이러하다.

비밀번호가 기억나지 않는 사용자가 게임 클라이언트에서 '비밀번호 찾기'를 누른다.
계정 복구 페이지는 웹으로 구현되어 있어, 윈도우의 기본 브라우저인 IE가 열린다. (윈10의 경우, 크롬 기반이 아닌 Edge가 열린다.)
호환이 되지 않는 브라우저라는 안내와 함께, 최신 브라우저를 설치하여 계속하거나, 사용자의 휴대폰에서 지금 Action을 계속할 수 있다는 안내를 제공한다.
- 이를 부드럽게 이어주기 위해, 사용자가 본래 접속하려고 했던 서비스 (이 경우 '비밀번호 찾기')의 URL을 QR코드와 함께 보여준다.

최신 브라우저를 설치하여 서비스를 이용해 달라는 문구와 함께, QR코드를 보여준다. (현재는 화면에 QR코드가 없다.)

기대효과

우선 무엇보다, 리소스를 대폭 아낄 수 있다. 특히, 위의 기능을 모듈로 만들어 개발팀 전체가 공용으로 사용하기로 했기 때문에 계정 관련 기능을 담당하는 우리파트 뿐만 아니라 전체 개발팀의 리소스를 아끼게 되었다. (그리고 위 기능은, 회원 관련이 아닌 다른 파트의 개발자분이 만들어 주셨다.)

개발을 효율적으로 만든 것 외에, 이 의사결정이 '사용자 친화적인가?' 라는 Challenge도 당연히 존재한다. 이 부분은 실제로 통계의 변화를 살펴보긴 해야 하겠지만, 나는 "시점의 문제일 뿐, 결국 사용자는 PC 밖에서 Action이 필요하다."는 점에 착안했다.

회원가입, 아이디/비밀번호 찾기, 휴면계정 활성화의 공통점은 무엇일까? 이는 바로, (많은 경우) 휴대폰, 이메일 등으로 인증을 거쳐야 한다는 점이다. 특히 한국은 휴대폰 인증에 대한 선호도가 매우 높다. (약 9:1 정도) 즉, 어차피 사용자는 휴대폰으로 눈과 손이 가야 한다. 또한 PC방과 같은 환경에서, 자신의 개인정보를 공용 PC에 입력하는 경험보다는 더 안심이 될 것으로 보인다. PC에서 하던 절차를 자신의 휴대폰에서 이어서 한다는 행태가 요즘같은 시대에 크게 불편할것 같지 않다.

마지막으로, 사용자가 반드시 휴대폰으로 이동해야 하는 것이 아니라 크롬을 설치하여 계속할 수 있는 Option도 여전히 제공한다. 강제하지 않고, 선택지를 주는 것이다.

마무리

'요즘같은 시대에 누가 IE를 지원하나요?' 라는 생각을 갖는 회사도 점차 많아지고 있다. 특히 Global 서비스 일수록, 국내 환경과 같이 작은 갈라파고스에 신경을 쓰지 않는 경우도 많다. 하지만 우리 회사에게 한국은 매우 중요한 곳이고, 우리 개발팀 또한 한국의 사용자 경험을 매우 중시하는 만큼, 적은 리소스로 최적의 효과를 낼 수 있는 접근을 시도해 보기로 하였다.

참고로, 이 기능을 탑재한 계정 관련 페이지는 아직 정식 릴리즈는 되지 않았다. 이전 포스팅에서 언급한 '올해의 대규모 개편'에 해당하는 이 사이트가 릴리즈 되는 대로, 기획의도 및 회고와 함께 글을 써보려고 한다.

작은 조직에서의 Product Roadmap 관리 이야기

Tue, 9 Feb 2021 23:41:47 +0900

이직 2년차 회고: Global 게임 회사의 Product manager - (2)

Previously on Gi's retro

"회사에 필요한 일이면서, 내가 잘할 수 있는 일, 그리고 회사도 나도 내가 하면 좋을 것 같다는 일을 맡아볼 수 있는 기회가 인생에 몇번이나 있을까? 그런 의미에서, 지난 2년은 행복했고 지금도 행복합니다."

요약

예전에는 우선순위 조정이라는 것이 Agile 교과서에나 나오는 환상속의 동물이 아닐까 생각했다. 이 회사로 옮겨 보니, 우선순위 조정은 이견이 따로 없을 정도로 쉬웠다. (늘 P0급 업무가 줄을 서있었으니.) 그럼에도 불구하고, 바쁘게 업무들을 쳐낸 만큼, 올해는 백로그에 쌓아두었던 대규모 개편을 준비할 수 있어 기쁘다.

말 뿐인 우선순위 조정

이전 회사에 속해 있을 때의 이야기를 다시 잠깐 가져오자면, 대부분의 요구사항은 Top-down으로 이루어지는 경우가 많았다. 물론, Top-down의 장점도 분명 있고, 때로는 올바른 방향으로 이끄는 리더의 Top-down은 그 결과물과 속도가 매우 아름다운 경우도 있다. (누구나 선망하는 테슬라의 자동차라던가, Apple의 iPhone 4라던가.)

대기업 8년차, 대부분의 요구사항은 보통 일정과 함께 하늘에서 떨어지는 경우가 많았다. 그러다 보니 자연스럽게,

기존에 세워두었던 Roadmap은 쉽게 흔들리기 마련이고,
그나마 이번 Iteration에서 예정해 두었던 아이템을 하늘에서 떨어진 친구가 다음 Sprint로 넘어가 주면 다행이었다.
하늘에서 떨어진 친구를 우선 Iteration 안에 배치하고, 다음 Iteration으로 도저히 넘길 수 없는 친구들을 이번 일정에 킵하는 경우가 많았다.

그리고 따라오는 결과는 제법 자주, 이랬다.

개발자는 야근을 하고,
기획자는 미안하고,
QA는 일정이 모자라니 OK 도장을 찍을 수 없다며 울부짖지만,
전략팀 또는 홍보팀은 예정된 일정이 있으니, (제대로) 나올지 안나올지 모르는 기능을 가지고 Biz dev도 하고, 기사도 준비하고, 때로는 상품(요금제라던가, 번들링이라던가)도 출시한다.

대기업 8년차, 위와 같은 경험을 자주 겪다 보니, 다른 회사 App을 사용하면서 어딘가 모르는 불편함이 느껴질 때 "여기는 왜 이정도 밖에 하지 못할까?" 에서, "여기도 뭔가 사정이 있었겠지." 라는 생각을 먼저 하게 되었다고 할까.

작은 조직은 Nice-to-Have만 진행해도 바쁘다.

반면, 이 회사에 와서 진행했던 대부분의 프로젝트는 사실 대부분이 P0 였다. Priority 0, 혹은 Blocker. 용어가 익숙하지 않은 분들을 위해 한마디로 설명하자면 이거다.

모든 다른 업무를 내려놓고 지금 당장 해야 할 일

실제 사례로 보자면 다음과 같다. (날짜는 많이 과장했지만, 실제로 19년에 월급을 받을 수 있었던 이유들이다.)

내일 모레 게임이 출시되어야 한다. 그런데 갑자기 회원가입이 안된다.
다음주에 신작 게임이 출시되어야 한다. 그런데 '기존 우리 고객'이 로그인을 시도하면 무조건 새 아이디를 만들어야 한다고 한다.

여러가지 규제로 인해, 저 버튼 3가지(페이스북, 구글, 애플)를 다는 일이 한국 회사에는 생각보다 녹록치 않다.

우리 조직은 개발자 3명 (백엔드 2, 프론트엔드 1명)과 디자이너 1명, 그리고 정책/운영을 담당하는 기획자 1명, PM 1명으로 구성된 조촐한 팀이다. 그나마, 백엔드 2명 중 한명은 개발팀장 (Tech Lead)이시기 때문에, 1.0을 우리 팀에 할애하고 있다고 보기도 어렵다. 이 작은 조직으로, 2019년에 신작 출시를 위한 회원 시스템 개편 (모바일 대응, Social 계정 연동, 게임 규제 준수를 위한 실명인증)을 단 한번의 큰 펑크 없이 이뤄냈다는 것이 정말 지금 생각해도 놀랍다.

날짜는 의외로 늘 박혀있다.

사실 생각해 보면 날짜가 하늘에서 내려오는 건 동일하다. 회사의 사활이 걸린 프로젝트가 출시일이 정해져서 내려오는데, 메인 Product인 '게임'도 아니고 '회원' 때문에 출시를 미루자고 할 수는 없다. (사이버펑크 2077에 CDPR 계정 로그인이 안붙었다고 출시를 미루자고 하면, 그날 바로 짐싸서 회사를 나가야 하지 않을까.)

이 부분은 내가 작은 조직으로 옮기기 전에는 느끼지 못햇는데 결국 제품을 개발한다는 건, 큰 조직이던 작은 조직이던 날짜를 Product Owner, Product manager 마음대로 정하기는 거의 불가능에 가까운 것 같다. 내 돈 100%를 태워서 만드는 나만을 위한 제품이 아닌 이상, 늘 Stakeholder가 있고 Product team은 주로 일정에 맞춰야 하는 쪽인 경우가 많다. Biz dev에서 100억원 규모의 공동 마케팅을 따왔다고 하는데 Product가 준비가 안된다고 말할 수 있는 경우가 얼마나 있을까. (그러니까 사이버펑크 2077이 그렇게 출시된 거 아니겠는가.)

그렇기 때문에 작은 조직, 즉 '리소스가 부족한 조직'에서 우선순위 조정은 어찌보면 그다지 어려운 일은 아니다.

늘 P0의 업무로 캘린더가 가득가득 하기 때문에, P0 중에서도 도저히 이번 Iteration에 못할 것들을 고민하는 경우가 오히려 많다. 모든 부서에서 P0라고 생각하고 들고 온 일들을, 갖은 꼼수나 운영 땜빵으로 P1 (반드시 있어야 함. 없어도 죽지는 않음.) 수준으로 낮춰서 다음 출시일로 미루고, P0 인 업무들도 최대한 규모를 줄여 아래와 같은 상태라도 '출시' 도장을 찍자고 이야기를 해야한다. 그래도 다행인 것은 이러한 의사결정이 매우 신속하고 빠르게 일어날 수 있다는 것이다.

(그리고 그 의사결정을 못하는 조직은 결국 망하는게 아닐까.)

돌아는 갑니다. 출시하죠. (출처는 이미지에 링크로)

PO, 그리고 Product team이 우선순위를 조정할 수 있는 조직이라 가능했다.

우리 회사는 다행히, Product Owner이면서 Project manager인 나에게 의사결정에 대한 많은 부분의 위임이 이뤄져 있다. 우리 Product team이 최종적으로 결정한 우선순위 조정과 관련하여, 회사 내에서 의사결정이 매우 빠르다.

'어차피 날짜가 박혀서 내려오는데 무슨 Roadmap인가?' 라고 생각할 수도 있겠지만, P0와 P1을 나누고, 'MVP는 여기까지고, 나머지는 출시 후에 고칩니다.' 라는 것을 설득하는데도 그리 큰 비용이 들지 않는다.

이 회사로 옮긴 뒤에, 그 이유에 대해서 많이 생각을 해보았는데, 내가 생각하는 이유는 크게 다음과 같다.

구성원부터 리더십까지, 조직이 모두 같은 방향을 바라보고 있다. 100명 남짓한 직원이 있는 회사가 이렇게 한 방향으로 Align 되기도 매우 쉽지 않은데, 다들 하나의 명확한 목표와 가치관을 공유한다. 그렇기 때문에 의사결정 과정에서 우리의 '안'이 저 가치와 목표에 부합하는지만 서로 점검하면 된다.

또 한가지, 어차피 사람이 없다. 사람이 많다면 조금이라도 더 기능을 많이 우겨넣어 보겠지만, 어차피 개발자 2.5명이 전부다. (아무리 Agile이라 해도, 사실 기획/디자인은 먼저 일하고 빠진다. 늘 일정에 가장 큰 영향은 개발자다.) 애초에 리소스가 적으면, 그다지 고민할 여유는 없다. (물론, 경우에 따라 "그럼 외주 2명을 더 투입하면 어때요??" 라는 질문을 받을 가능성은 있지만, 다음 기회에 다뤄보기로 하자.)

마지막으로, 대신 사람 하나하나가 모두 뛰어나다. 앞서 '수퍼 개발자' 라는 말을 했는데, 사실 코드 리뷰를 PM인 내가 직접 하는 것이 아닌 만큼, 코드의 퀄리티는 나는 모른다고 하는 것이 맞다. 하지만 나는 Ownership을 가지고, 일정에 맞추어 꾸준한 Quality를 담보하는 디자이너/개발자가 가장 뛰어난 사람들이라고 생각한다. 결국 구성원 하나 하나에 대한 신뢰가 깔려있으니, 굳이 이 사람들의 일정에 Challenge를 하거나 의문을 가질 필요가 없다.

결론적으로, 위의 이유들 덕분에 하늘에서 '당장 모든 일을 멈추고 이것부터 해야한다'는 과제가 내려와도, 우리 조직이 잘 버틸 수 있었던 것이 아닐까.

그리고 팀과 사용자 모두를 기쁘게 할 프로젝트 준비하기

사실 작년에 신작 출시를 위해 많은 프로젝트를 수행했고, 엄청 바쁜 시간을 보내면서도 우리 팀의 가슴을 뛰게 하는 일이 한가지 더 있었다. 바로, 계정 관리 페이지의 대대적인 개편이다.

PC 게임만 10년 넘게 서비스 해온 회사이고, 19년 갑작스럽게 신작을 4개나 출시하시는 바람에 이 일정들을 맞추느라 우리 시스템엔 아직도 많은 헬리콥터 비둘기들이 존재한다.

올해의 첫 농사는, 비둘기들이 제대로 양날개로 날게 하면서도, 사실은 비둘기가 아니라 독수리였습니다! 하는 수준의 개편을 준비하고 있다. 개인적으로 PM에게 반드시 여유가 필요한 이유가 여기에 있다고 생각하는데, 현장 최전선에서 열심히 일을 쳐내는 디자이너/개발자와 한발짝 떨어져서, 우리 팀에도 의미가 있고, 고객에게도 좋은 아이템을 발굴해 내는 것이 꼭 필요하다. 아무리 돈받고 일하는 거라고 하지만, 개발자도 디자이너도 (그리고 나도) 공장의 기계부품이 아닌 만큼, 우리에게도 보람이 매우 중요하니까.

사실, 이게 Roadmap 관리의 중요성 중 하나라고도 생각한다.

우리가 지금 하고 있는, '당장 치워야 할 과제'는 언제 끝나는 것인지,
그리고 왜 지금은 헬리콥터 비둘기가 출시되어야 하는지,
우리의 비둘기는 언제 날개를 펴게 되는지,
그리고 언제쯤이면 이 비둘기들이 독수리처럼 날아오르는지.

나에게도, 나와 일하는 동료들에게도, 그리고 우리 제품을 기다리는 사내 Stakeholder 들에게도 머리속에 최대한 같은 그림이 그려지도록 하는 일. 그게 Roadmap 관리인 것 같고, (참으로 다행이도) 우리 회사는 그러한 Roadmap 관리가 가능한 조직인 것 같다.

그럼에도 불구하고, 늘 이렇게 되긴 하겠지만. (출처는 이미지 내에)

이직 2년차 회고: Global 게임 회사의 Product manager - (1)

Mon, 1 Feb 2021 23:30:01 +0900

Previosuly on Gil's retro:
"회사를 옮긴 지 2년이 되었고, 대기업과 무엇이 다른지, 그래서 뭐가 좋은지 정리할 필요를 느꼈다."

2021/01/13 - [Retro] - 이직 2년차 회고 -1 : 대기업 Product manager 생활

나는 참 걱정이 많은 사람이다.

생애 처음으로 인턴을 했을 때, 당시의 내 팀장님은 나에게 이런 질문을 던졌다.

"너는 목표가 뭐니?"

나는 사실 한치도 주저하지 않고, 이렇게 대답했다.

"살아남는거요."

저 말의 배경에는 사실, 월급 체납이 있었다. 대학교 1학년 때부터 주에 절반은 회사를 다니거나, 프리랜서로 일했던 경험이 있던 나는 적지 않은 횟수로 월급이 안 나오거나, 페이가 줄어드는 경험을 했었다. 저 질문을 들은 지가, 만 11년이 넘어간다. 그리고 외국계로 이직하기로 마음먹었을 때, 나를 8년이나 품어준 따듯하고 안락한 친정(첫 회사)의 품을 떠나기로 마음먹었을 때, 나의 목표는 한번 더, '살아남는 것'이었다.

월급 받는 이유를 스스로 증명하기

직장생활을 처음 시작하던 시기에도 내 머릿속에 가장 굵직한 키워드는 '살아남기'였던 만큼, 나는 회사생활을 어떻게 해야 하는지에 대한 정보를 여기저기서 얻었던 기억이 난다. 그중 나에게 가장 큰 영향을 끼쳤던 책은 아래의 [입사 후 3년]이라는 책이다.

입사 후 3년

신현만 저

저자가 헤드헌터 회사 대표로서 수많은 경력 직장인들과 기업의 인사채용 담당자들과의 컨설팅, 인터뷰를 통해서 얻은 성공적인 직장생활을 위한 일종의 데이터베이스. 이 책은 직장생활에서 몸살을 앓고 있는 직장인들의 고민에 따른 대안과 사례들을 풍부하게 열거하고 ‘인재 전쟁’이라는 전투 속에서 치열하게 싸우고 있...

www.yes24.com/Product/Goods/1479866

다른 내용은 잘 기억나지 않는데, 아래의 내용은 확실하게 기억이 난다. 대략, 나의 목소리로 옮기자면 이렇다.

당신의 연봉의 3배를 회사에 벌어다 주어야 한다. 회사는 당신에게 제공하는 월급 외에도, 사무실을 유지하는 비용이나 당신에게 제공되는 장비, 집기 등에도 비용을 쓰고 있다. 당신에게 제공되는 월급이 1이라면, 이러한 비용이 1이고, 나머지 1은 회사 몫의 이익이다. 그래서 3배를 벌어야 하는 것이다.

결국 이 이야기를 하는 이유는, 대기업 생활에서 나는 냉정하게 말하면 회사에 얼마를 가져다주는지 정확히 몰랐다. 회사가 나에게 월급을 주어야 하는 이유를, 명확하게 설명할 수 없었다. 내가 소속되어 있었던 회사만의 특징일 수도 있고, 대기업 중에서도 칼같이 한 사람 한 사람의 성과를 측정하는 곳도 분명 있을 것이다. (예를 들면, 삼성? 안 다녀봐서 모르겠다.)

하지만 확실한 건, 내가 다니던 회사의 평가 시스템은 결국 큰 맥락에서 저걸 원치 않았다는 거다. 애초에 사람을 잘 내보내지 못하기 때문에 (해고도 어렵고, 퇴사도 적고), 수많은 프리라이더가 있었고, 자연스럽게도 회사도 한 사람 한 사람에게 투명하게 Break-down 된 목표 할당과 평가를 원치 않았다.

사실 그렇게 세분화하여 성과를 평가하려면, 결국 그에 합당하게 보상에도 차등이 주어져야 한다. 하지만 그 회사의 평가 시스템은 그러한 제도를 포용하기엔 어려워 보였다. 어찌 되었던 '공채'를 기반으로 만들어진 회사이고, 연차가 평가를 담보해주는 방식이, 모두에게 평화로운 방식이기 때문이 아니었을까?

어쩌다 보니, 배경 설명 2부를 진행해 버렸다. 이제 진짜, 옮긴 회사 이야기를 해보자.

그래서, 그 회사에서 Product manager는 무얼 하나요?

IT Industry 짬밥 8년, 사실 회사를 다니며 게임사 출신을 본 적이 없지 않다. 특히, 내가 만나는 사람들은 대부분 게임사에서 '비게임' Product를 맡았던 기획자 혹은 개발자였다. 그래서 이 회사에 대한 Offer가 왔을 때, 면접에서 가장 궁금했던 부분도 이 질문이었다. 대체, 이 회사가 왜 뜬금없이, 그것도 한국에서 PM을 뽑는가.

다행히, 당장 입사하면 맡을 Product가 있었다. 그래서 사실, 그 Product를 성공적으로 론칭하고, 1-2년 정도 운영하고, 그 뒤에는?이라는 불안감을 가지고 이직을 하긴 했다. 그래서 당시, 인터뷰를 보았던 대표님이 "회사 옮기는걸 무슨 부서 이동하듯이 생각하는 것 같다."라고 피드백했었는데, 그분이 정확히 보신 것 같다.

저 질문을 가장 먼저 던진 이유는 당연히, 저 질문이 "그래서 내가 회사에 뭘로 돈을 벌어다 주면 되나요?"라는 의미이기 때문이다. 그리고, 내가 본 수많은 게임회사의 '비게임' 담당자들은 저 Challenge를 가장 많이 받았다. 당연히 나도, 이직을 마음먹은 순간부터 내가 가장 많이 받게 될 Challenge는 저것이 될 거라고, 각오를 하고 이직을 했다.

그리고, 매우 ㄴㅇㄱ!!! 스럽게도, 입사 후 3개월 만에 내가 맡기로 한 Product는 접혔다. 수습기간 6개월 중, 3개월이 지나던 시점이었다. 어쩐지, PM이 입사도 안 했는데, 내년 1월에 그 App이 서비스해야 하는 e스포츠 리그가 시작하는데, 입사 천천히 해도 된다고 할 때부터 알아봤어야 하는데.

입사 3개월 차, 나는 백수가 될 위기에 놓였다. 운이 좋게도, 수습 6개월 기간 동안에는 "내가 생각하기에는 우선순위가 높지는 않지만" 회사가 생각하기에 우선순위가 높은 (사실은 당시 대표님이 정말 하고 싶었던 숙원 사업인) 웹사이트 개편이 있었다. 개인적으로 저 웹사이트 개편이, '잘할 수' 있지만 재미있고 (스스로 생각하기에) 의미 있는 업무는 아니었던지라, 사이드 프로젝트로 외부에 공급하는 데이터 사업의 구색을 갖추는 작업도 병행했다. 덕분에 좀 회사에서 수명(?)이 늘었고, 나는 저 '나 아니면 안 되면서도 회사에 아주 중요한 업무'를 찾는데 주력했다. 기회가 닿는 대로, 저 '데이터 사업의 구색을 갖추는 작업'의 Retro도 한번 적어보기로 하고, 다시 오늘의 주제로 돌아가면...

그래서, 그 회사에서 Product manager는 무얼 하냐구요?

다행히, 2년이나 회사를 다닐 수 있었던 이유는 저 답을 찾았기 때문이다. 사실, 우리 회사의 Product manager들 중에 대다수는 Producer라는 타이틀을 달고, 게임 관련 업무를 한다. 게임 개발, 게임 론칭, 업데이트 등등. 사실 비게임 PM이라 그 친구들 뭐 하는지 잘 모르겠다. (한국엔 없기도 하고.)

나는 비 게임 Product manager다. 그래서, 이 회사에 들어와서 가장 열심히 고민했던 영역 중 하나가 바로 이건대, 내가 이 회사에서 월급 받으면서 다니려면, 회사에 꼭 필요한, 즉 '없어서는 안 될' 업무를 맡아야 한다는 생각이었다. 그 중에서도 '나 아니면 안될' 업무라면 금상 첨화였고.

그리고 다행히, 입사 후 만 1년 정도가 채 되기 전에, 나는 '비게임' 영역 중에서도, 개인적으로 생각하기에 사업을 위해서 '없어서는' 안 되는 서비스 2가지 서비스를 찾았다. 그리고 그중 하나의 Product Owner를 맡았고, 지금은 두 번째 서비스까지 PO를 맡았다.

아니 그래서, 대체 그 회사에서 Product manager로서 무얼 하냐구요!

네, 저는 저희 회사 게임들을 위한 한국용 회원 시스템을 담당합니다.

저 말을 할 수 있기까지, 사실 속으로는 엄청 불안 했다. 경력직 이직을 했으니, 정말 회사에 내가 월급 받는 이유를 가져다 주어야 하는데, 결국 수습이 끝날때까지 그 답을 못찾았으니 정말 백수 되는 줄 알았다. (회사에서 아무도 그거 가지고 뭐라고 안했다. 그냥 내가 불안한 거지.)

2가지 서비스 중 하나는 회원이다. 회원은 사실 전 직장에서 가장 하기 싫었던 업무이면서, 동시에 내가 생각해도 내 커리어에서 가장 잘하던 업무 중 하나였다. 그래도 벌써 회원 업무 짬밥 7년, 0부터 만드는 경험부터 정말 끔찍한 Legacy를 가진 시스템 개편까지 회원만 7년을 해본 경험을 바탕으로 정리해보면, 회원 업무의 특성은 이렇다.

Front-end 기획도 중요하지만, Back-end 관련 이해도가 필수인 포지션.
(처음부터 만드는 축복을 누리는 경우를 제외하고) Legacy 시스템에 대한 파악을 할 줄 알아야 한다.
인터넷 서비스 사업자가 지켜야 할 법률적 준수사항에 대해 잘 알면 유리하다. 즉, 회원을 오래 해봤을수록 회원 담당자로서 유리하다.
우리 서비스도 잘 알아야 하는데, 남의 서비스 (본인 확인 서비스, 휴대폰 점유 인증 등)도 잘 알아야 한다. 그래서 회원을 오래 해봤을수록 회원 담당자로서 유리하다.

한마디로, 고인물용 포지션이다. 대부분 회사에서 회원 담당은 아무한테나 잘 안 맡긴다. 심지어, 본사가 따로 있고 그래서 Global standard 하게 만들어 놓은 시스템이 있는데, 이를 한국에 맞춰서 현지화를 해야 하는 업무라니, 말만 들어도 의존성 (dependency) 천국이다. Dependency가 올라가면, 당연히 복잡성도 올라가고, 얘기 나눠야 할 Stakeholder들도 그만큼 많아진다. 한마디로, 업무 난이도가 비례해서 오른다.

사실 그래서, 회원은 다시 하기 싫은 업무 중 하나였지만, 이제는 내 커리어의 꿀 같은 경력 중 하나가 되어버렸다. 이 회사에 와서, 회원 업무를 맡는 순간, 회사에 이야기할 수 있게 된 거다.

"저는 한국 서비스를 제공하기 위해 반드시 필요한, 한국용 회원 시스템의 PO입니다."

네, 그리고 두 번째 서비스는 결제입니다. 결제도 회원 못지않게 업무의 성격이 비슷- 하다. 한 번도 맡아본 적이 없고, (사실 다른 회사에 있을 땐 별로 맡고 싶지 않아서 피해 다녔지만) 이제는 그냥 인정해야겠다. 나는 저런 업무를 잘한다. 좋아하는 것과 잘하는 것은 다른데, 이제는 하다 보니 좋아지기까지 한다.

그리고, 이제는 '왜' 회원과 결제 업무가 다른 회사에서 재미가 없었는지도 조금 알 것 같다. 이 부분은 다음 글에서 2부로 다뤄봐야겠다. (결국, 대기업과 지금 회사가 다른 점이 그 원인이다.) 글이 너무 길어졌다.

사설이 생각보다 길어졌다. 옛날이야기가 재미있어지는 것을 보니, 아저씨가 다 되었다.

그래서 오늘의 회고, 이 글에서 하고자 했던 이야기는 사실 이거 한 줄이다.

이미 눈치채셨겠지만,

"내가 회사에 기여하는 바를 확실하게 알 수 있는지 없는지가, 내가 느낀 대기업과 (특히 경력직으로 이직해온) 작은 회사(?)의 가장 큰 차이다."

좀 더 짧게, 이 회사로 옮기고 나서야 명확하게, 나는 "내가 월급 받는 이유"를 회사와 나, 모두에게 설명할 수 있게 되었다.

최근에 동료 중 한 분이, 나에게 이런 질문을 했다.

"그래서, 길님은 요즘 행복한가요?"

별로 주저 없이, 고민 없이 답할 수 있었다. 나는 지금 전반적으로 행복하다. (굳이 전반적인 이유는, 코로나 & 재택 & 육아로 많이 행복하면 오히려 그쪽이 도라이이기 때문이다.) 결국 Retro를 적기 시작한 이유도 여기에 있다. 지금 이 순간, 일을 하며 행복한 기분을 오래오래 남겨두기 위해서.

회사에 필요한 일이면서, 내가 잘할 수 있는 일, 그리고 회사도 나도 '길님이 (내가) 하면 좋을 것 같다.'는 일을, 인생을 살면서 맡아볼 수 있는 기회가 몇 번이나 있을까? 올해로 11년이 된 회사 생활을 돌아보면, 그리 흔한 기회는 아니었던 것 같다. 앞서 '대기업 Product manager 생활'의 회고에서, 길게 적었던 것처럼, 주로 내가 공감가지 않는 일을, 남이 우선순위가 높다고 하여 해 오는 경우가 더 많았다.

심지어, 그 일이 IT에 관련된 일이고, (내 인생에서 의외로 중요한 요수 중 하나인) 남들이 알만한 회사의 Product다.

네, 이직해서 행복합니다. 10년 전에도, 15년 전에도 저는 컴퓨터로 사부작 거리는 일을 하며 먹고살고 싶었고, 10년 전의 저는 윈도 켤 때 나오는 회사 로고가 나와서 행복했던 저는 지금 게임 켜면 저희 회사 로고가 나오네요.

(사실, 아들이 아빠 무슨 회사 다니는지 알 수 있는 때까지만 다닐 수 있으면 좋겠는데, 지금 맡고 있는 일 다 하고 나면 또 회사에 월급 받는 이유를 설명할 수 있는 일을 찾아야 할 텐데, 그게 좀 걱정이 됩니다. 어떻게 되겠죠 뭐...)

이루다 (스캐터랩 챗봇)의 논란과, 회사에 없는 데이터를 극복한 방법

Thu, 14 Jan 2021 20:11:26 +0900

개인적으로, 여긴 정말 천재적이다- 라고 생각했던 회사가 논란에 휘말렸다.

Google이 자연스러운 대화형 봇을 만들 수 있었던 것은 hangout과 gmail. 사람들이 대화를 주고받는 것을 수집할 수 있었으니, 당연히 A에 는 B라는 대답이 올 것이다부터, 다양한 Context를 파악할 수 있는 AI도 만들 수 있었겠지.

국내에서 카카오나 네이버를 제외한 회사에서 챗봇을 만들기 위해서는 반드시 필요한 데이터가 결국 대화 내역이다.

대기업이라면 "우리 회사의 약점 (a.k.a. 대화형 AI 못 만드는 이유): 대화 데이터가 없음" 이렇게 적어 놓고 넘어가거나, '그래서 어딜 사와야 하나~' 라고 생각할 만한 부분을, 이 회사는 무려 사용자가 직접 제출할 수 있도록 동기부여를 했다. 어떻게?

사람들이 가장 궁금해 할 만한 관심사 중 하나인 '연애'를 콕 찝어서, 대화 내역을 제출하면 두 사람 중 누가 더 자주 이야기 하고, 누가 더 호감도가 높다고 판단된다~ 같은 형태로 '데이터를 읽어' 준다. (심지어 일부 기능은 유료로도 팜....)

그 회사에 대해서 자세히 아는 것은 아니지만, 밖에서 바라보는 내가 대단하다 생각했던 부분들은 다음과 같다.

1) 우리 회사에는 없지만, 우리 회사의 Core 역량을 위해 반드시 필요한 데이터를 끌어오는 그 아이디어.

2) AI 챗봇 만드는 회사에서 연애 분석 어플을 만들자고 제안할 수 있는 PM, 그리고 그걸 만들어주는 개발자들.

회사에서 대화내역을 수집한 것이 적법 했는지, 특히 A-B 사이의 대화에서 A만 동의를 받아도 관계 없는 것인지, 개인정보가 담긴 대화내역은 어떻게 처리했을지 (왠지 이 부분이 매우 취약할 것 같긴 한데) 등 현재 문제가 된 것들 외에도 여러가지로 논란의 거리들이 많다. 거기에 안타까운 일로 구설수에 올라서 개인적으로는 마음이 아프다.

당연히, 그 회사의 잘못된 부분까지 옹호하려는 마음은 없다. 고지를 하고 수집했고, 약속된 범위 내에서 적절히 가공을 하고 사용을 했어야 하는 부분이다. 이 부분에 대해 문제가 있었다면, 해당 부분은 사법기관의 영역이다. 개인인 나는 확실한 무언가가 발표되기 전까지는 말을 아끼려고 한다.

나름의 비전을 가지고 '우리 기술이 이제 여기까지 왔다.' 라는 쇼케이스 목적의 Product을 내놓았는데, 그게 회사에 치명적인 악재로 돌아오게 되었을 때, 그 Product을 담당하는 Team의 마음은 정말 참담할 것 같다.

오랜만에, 담당 Product가 런칭과 함께 안 좋은 일로 Twitter trends에 올라갔던 생각이 떠오른다. 잘못된 건 바로잡고, 잘 해결되었으면 좋겠다.

---

그리고, 위 글을 Facebook에 올렸었는데, 이루다는 다음과 같이 흘러갔다.

JTBC에서 언급이 되었고, 스캐터랩은 이루다의 서비스를 잠정 중단했다. 어찌 되었던, 이번 발표로 세상에 널리 알려지긴 했으니 결론적으로는 그 목표를 어느정도 달성하지 않았나 싶다.

다시 한번,

동종업계에서 동일한 업무를 하는 사람의 입장에서는 대단한 부분만큼은 인정하고 가야겠다.

이직 2년차 회고 -1 : 대기업 Product manager 생활

Wed, 13 Jan 2021 22:49:43 +0900

들어가며,

본격적인 회고에 앞서, 간단히 배경설명을 좀 해보려고 한다.

회사를 옮긴지 2년이 지났다. 엄밀히는 회사를 바꿔본 경험이 적은 편은 아니지만, 큰 맥락에서는 어찌보면 첫 이직이었다.

이력서 상으로는 여러번의 이직이지만, 실제로는 한 회사의 신입 공채로 입사하여, 그 회사에서 나를 안고 '사업'이 네번이나 회사를 옮겼다. 덕분에, 해당 사업에 적을 두고 있는 나도 회사를 네번이나 옮겼지만, 늘 같은 그룹사 안에서 이동하다 보니, 크게 이직을 했다는 생각이 들어본 적은 없었다. 특히, 같은 사업부 사람들이 주로 같이 이동했던지라, 본부나 팀을 옮긴 것 정도의 생소함이 있을 뿐,회사가 바뀐다는 느낌 보다는 그저 사무실이 바뀌고 복지나 분위기가 좀 바뀐다는 느낌 정도였다.

8년의 대기업 생활 후에 내가 합류한 회사는, 전체 직원은 100명 남짓이지만(입사 당시)Product manager는 나 하나, 개발자를 포함한 엔지니어를 모두 합쳐도 30명 남짓한 '작은' 회사였다. 물론, 한국 지사가 작을 뿐 Global하게는 완전 대기업인데다, 또 기업의 외연적인 측면을 생각하면 작은이란 단어가 글을 쓰는 지금도 매우 어색하게 느껴지지만, 여기서 작다는 의미는 우리 오피스의 직원 수에 그 방점을 둔다.

특히, 실제로 내가 함께 일하는 개발자는 3명~5명 정도를 오갔다. 여기에 함께 일하는 디자이너 1명, 정책과 실무, 운영을 함께 논의하는 동료 1명 정도의 소규모 그룹이, 내가 몸담은 Product 조직이다.

이직 2년차, 대기업 vs. 스타트업까지의 큰 차이는 아니지만, 아래의 비교 정도라 할 수 있겠다.

큰 조직 vs. 작은 조직 (엄밀히는 이 회사도 인원은 많지만, 한국지사는 약 100명)
국내 대기업 vs. 외국계 대기업(?)

쓰다 보니 글이 길어져서, '대기업 시절'의 회고를 먼저 간단히 적어보려고 한다. 결국 PM의 입장에서 큰 조직, 작은 조직의 비교를 소회로 풀어보고자 글을 쓰기 시작한 것이니 말이다.

"하면 좋은 일"이 많았던 대기업 기획자 생활

서비스를 만들다 보면, 되게 자주 쓰는 단어가 있다. 영어로는 Nice-to have. 직역하면 "있으면 좋을만한 (기능)".

주로 다음 버전에 들어갈 기능이나, 이번 분기 할일 등을 정리하다 보면 나오는 이야기. 그리고 문자 그대로의 의미와는 정 반대로, 주로는 "일단은 안 만들" 기능이다. 당장 필요는 없으니, 언젠가 다시 생각해보겠다는 의미. 하지만 Project manage를 해보면, 이렇게 한번 backlog로 들어간 일은 좀처럼 Icebox를 나오지 못한다.

하지만, 지금에 와서 생각해보면 대기업에서 업무의 많은 부분은 '하면 좋은 일'로 채워져 있었던 것 같다.

대기업에서의 '일'은 하늘에서 떨어진다.

함께 일하는 사람들에게 일의 배경을 설명할 때, 개인적으로 좋아하는 표현이 있다.

"하늘에서 떨어진 일."

그러니까, 실무자나 Product Owner가 보기에 필요한 일이 아니라, 어디선가 위에서 내려온 바로 그 일. 그 요구사항. 그 기능 같은 것들.

특히, 그런 하늘에서 떨어진 일 중에는 아래와 같은 특징을 가진 일들이 많았다.

도무지 우리 서비스의 주요 고객들은 사용하지 않을 것 같은 기능
하지만 옆 회사 '경쟁(이라고 매번 보고서에 올라가는)' 서비스에서 출시하거나, 업데이트 한 그 기능
혹은 그 회사에서 그런 걸 할 거라고 '언론'에 보도했지만 실제로는 있는지 잘 모르겠거나, 임팩트 전혀 없는 기능
하지만 안타깝게도, 우리도 곧 넣어야 하는 바로 그 기능.

개인적으로 대기업에 오래 근무하면서 늘 염두에 두고 있는 점 중 하나는, 회사에서 요구하는 일을 최대한 좋은 품질로 수행하는 것 또한 직장인에게 중요한 덕목 중 하나라는 것이다.

특징에 적은 것처럼, 이러한 일들은 무엇보다 동기부여가 어렵다. Product manager의 입장에서 보아도 우선순위가 그렇게 높지 못하며, 이 프로젝트를 통해 달성하고자 하는 바도 명확하지 않은 경우가 많았다. 무엇보다, 그 일을 시작하게 된 계기가 말 그대로 '위에서부터 내려온 지시'인 만큼, PM인 나부터도, 명확하게 이를 동료들에게 설명하기 어려운 경우가 많았다. 나야 어떻게든 "월급을 받았으니까" 라며 스스로 동기부여를 해볼 수 있겠지만, 아무리 회사원이라 해도 기계는 아니다. 모두가 그러긴 어렵다.

그렇게, PM도 설득이 되지 않고, 개발자도 디자이너도 공감이 가지 않는, '하늘에서 떨어진 일'은 많이 양보해 봐야 Nice to Have다. 있으면 좋겠지만, 지금 급하진 않은 그런 일들.

물론, Top-down이 반드시 나쁘기만 한 것은 아니다. 때로는 Top-down이 아니면 추진할 수 없는 일도 분명히 있다. 하지만 적지 않은 빈도로, 사업적으로 공감이 가지 않거나, 왜 해야하는지 잘 와닿지 않는 기능이 우선 순위가 올라오는 일들이 많았던 것 같다.

대기업의 장점

그럼 대기업에 장점은 없냐? 오직 복지만 보고 다녔던 거냐? 절대 아니다. 작은 조직에 오니, 절대로 해볼 수 없는 일도 분명히 많다. 예를 들면, 이 회사로 옮긴 뒤에는 예산이 크게 소요되는 프로젝트는 상대적으로 맡기 어려워졌다.

특히 내가 8년간 몸담았던 스트리밍 서비스가 아주 대표적이다. 일단 서비스를 굴리는데만도 돈이 엄청나게 많이 든다.

아주 러프하게, 계산해보면 다음과 같다.

YouTube 권장 화질 (8Mbps)로 1명이 10분간 비디오 시청: 4800Mbps = 8Mbps x 60s x 10min
4800 Mbps는 Gigabytes로 전환 시 0.6 Gbytess
위 비디오를 1000번 시청하면, 600 G
Amazon 비디오 스트리밍 서비스를 기준으로, 1000번 시청에 5.1 USD
참고로 YouTube의 공식 발표 '일' 조회수는 하루 40억 건이다.

당연히 YouTube는 직접 스트리밍 서버를 구축하니, 저것 보다는 저렴한 스트리밍 비용을 부담하긴 하지만, 함부로 스타트업이 들어갈 수는 없는 영역이 비디오 스트리밍라는 이야기가 하고 싶었다. (하지만 그 힘든 것을 왓챠가 해냅니다. 그것도, 무려 5년을 넘게 살아남고 계신다.)

그리고 다시 한발짝 나와서, 저런 엄청난 돈이 드는 서비스를 작은 조직에선 당연히 상상조차 못한다. (물론 현재 회사도 엄밀히는 대기업이고, 절대 돈이 없는 회사는 아니지만, 지사이다 보니 어느정도 한계가 있긴 하다.)

종합해보면,

결국은 대기업에서의 프로젝트는, 작은 조직에서 맡기 어려운 규모의 프로젝트이긴 했지만, 동시에 Product Manager 입장에서 '당장 이걸 하지 않으면 우리가 망합니다!' 같은 우선 순위가 높은 프로젝트는 아니었던 느낌이다.

나는 결국 그 점이 아쉬워서 큰 조직을 떠났다.

위에서 정한 우선 순위나, 사업 방향 등에 공감이 가지 않는데, 일을 꾸역꾸역 해내야 하는 점에 지쳐서.

일종의 자기 결정권이랄까? 대기업은 당연히 그런 부분이 좀 부족하다.

결론적으로 만족하냐고? 현재는 만족한다. 그러니 2년이나 작은 조직으로 옮기고도 살아남을 수 있었다고 생각한다. 그런 의미에서, 다음 글에서는 작은 조직(?)에 와서 좋았던 점들을 한번 정리해볼까 한다.