문돌이가 CTO(Chief Technology Officer)가 되기 까지

비즈니스

문돌이가 CTO(Chief Technology Officer)가 되기 까지

이병록 2020. 8. 5. 17:57

이 글 최종 수정일 : 2020-08-05

제목부터 상당히 자극적이다.

문돌이가 엔지니어링, 개발을 넘어 최고 기술 책임자라니..

요즘 같은 경우 조그마한 기업에 기술 담당자가 있으면 CTO라고 부르지만

개인적인 생각에서는 진짜 CTO급은

1. 최소 프로그래밍부터 프로덕트 개발까지 10년 이상의 경력을 최소한 쌓고

2. 가지고 있는 도메인 지식도 출중하며 해당 기업의 기술 로드맵을 그리며

3. 기업의 모든 기술 스택을 알고 있는 사람, 아키텍트

4. 기업의 위기가 찾아왔을 때 혁신적으로 방향을 뚫을 수 있는 사람

5. 그리고 기업의 high-technology의 정점에 있는 사람

6. 기업의 비즈니스 모델을 기술적으로 녹여낼 수 있는 사람

7. 기업의 문제에 솔루션을 제시할 수 있는 사람

그런 분이 CTO라 불리고 진정한 CTO급이 아닌가 라는 개인적인 생각이 든다.

'문돌이가 CTO가 되기 까지'라는 자극적인 제목을 달긴 했지만, 사실 나는 CTO급은 아니다.

그러나 기업의 상황과 환경이 'CTO'로 불리도록 만들었고 직무로 'CTO'의 일을 하게 되었을 뿐이다.

주어진 나의 환경

'문돌이가 개발자가 되기까지'의 글의 연장선이다.

여러 상황과 기회로 인해 총괄 개발이사 또는 스타트업의 CTO를 맡게 되었다.

(강제적 DevOps를....)

환경상 주변에 공돌이 또는 개발자의 길을 걷는 사람이 없었고 문돌이 밖에 없어서 조언을 해줄 사람이 정말로 없었다.

스타트업이다 보니 사수도 없었고 부사수도 없었다.

내가 경력이 있었던 것도 아니고 스타트업의 개발과 관련된 막중한 임무를 맡아야 하는 책임을 지게 된 것이다.

즉. 어떻게든 혼자서 발버둥 쳐야 하는 상황이었다.

실제로 기업의 서비스를 운영하고 개발한다는 것은 '동아리' 같은 세미 프로젝트를 하는 것이 아니다.

기업의 방향에 맞춰 신속하게 개발하고 문제없이 운영해야 한다는 것이다.

그 말은 '나의 실수로 인해 잘못하면 기업에 큰 타격을 입힐 수 있다'는 얘기이다.

(실제로 큰 타격은 아니지만 작은 타격들을 많이 입혔다.... 후..)

스타트업은 큰 기업과 같이 시스템화 되어있거나 체계적인 경우가 많지 않다.

기업을 정상적으로 운영하고 성장시킬 수 있도록 문화를 이제부터 만들어야 한다는 얘기이다.

그러한 막중한 임무를 맡아야 했다.

경험치가 없다. 실수도 많다. 그러나 거기에서 배운다

Dev에서만 얘기해보자면.

시니어도 아니고 실무 경험이 전무한 상황에서 '총괄 개발직'을 맡게 됨에 따라 정말 셀 수 없는 삽질을 많이 했다.

정말로 주변에 물어볼 사람이 정말로 없었으며, 누군가에게 막 도움을 청하는 스타일이 아니다 보니 더 고생을 많이 했다.

만약에 실무경험이 충분했었으면 고생을 덜 하지 않았을까 생각이 날 정도로 진짜 고생을 많이 했다.

경험치가 많이 좌우되는 부분이 서비스를 운영하기 위한 시스템 설계와 백엔드 관련 개발이 가장 영향이 크다.

골치 아픈 부분이다.

가능하다면 서비스를 운영하고 개발하는 기업의 사수(물론 좋은 사수..^^)에게 배우는 것이 가장 덜 고생하고 빠르게 잘 배울 수 있다.

사수 없이 경험 없이 삽질과 박치기를 하는 것은 장점이라고는 하나도 없고 대부분 단점밖에 없지만

그럼에도 딱 하나 장점이 있다면 수많은 삽질들과 아래에서부터 쌓아 나가는 경험을 통해 '왜 이런 아키텍처를 선택하게 되며, 왜 이런저런 기술들을 사용하게 되고 연구하고, 개발하게 되는가'에 대한 것을 알고 뼛속까지 겪게 된다.

지금 당장 머릿속에 생각나는 예시는 다음과 같다.

(이미 성장할 만큼 성장한 기업에서는, 겪는 상황이나 생각이 다르긴 하다.)

'왜 최초 설계할 때부터 가용성 높고 확장성 높게 설계해야 하는가'

'왜 시스템을 자동화해야 하는가?'

'단순히 프레임워크, 라이브러리를 사용하는 것을 떠나 왜 CS와 근본적인 원리가 중요한가?'

'서비스 개발을 하다 보면 새로운 개념과 새로운 알고리즘들을 만들어야 한다.'

'호환성 있게 개발을 해야 한다는 것은 무엇인가? 그리고 왜 그래야 하는가?'

'사이드 이팩트를 막기 위해 할 수 있는 것은 무엇일까? 왜 테스트 코드를 짜야하는가? 어디까지가 적정선인가'

'리팩터링을 할 수밖에 없는 이유와, 왜 가장 쉬운 코드가 제일 좋은 코드인가? 내가 짠 코드를 한 달 뒤에 봐도 이해할 수 있는가?'

'기술 부채, 리팩터링 그리고 오버 엔지니어링, 그 아슬아슬한 적절한 간격은 무엇일까?'

'모든 거 다 넣으면 좋다. 트래픽 대응 다 좋다. 비용을 최소화하면서 핵심적인 부분을 어떻게 챙길 것인가?'

'어떻게 기능을 빠르게 도입하면서 이후의 가용성, 수용성, 확장성, 마이그레이션에도 문제없이 만들 수 있는가?'

수많은 고민들과 문제들을 겪어나가며 하나씩 고민하고 해결하기도 하고

우선순위에 따라 미루기도 하는 과정을 통해 느끼게 된다.

겪지 않았지만 누군가 미리 알려주는 방법으로 깨우침을 얻는 방법도 있으나

실제로 겪고 짬에서 나오는 바이브로 누군가에게 설명해줄 수 있는 내공을 가질 수도 있다.

다만 시행착오가 너무 많고 개고생이라 많은 시간을 낭비한다.

그만큼 남들보다 더 많은 압도적인 연구 & 자기 계발 시간을 투자해야 한다.

필자는 코딩을 처음 한 이후부터 퇴근하고 이후에도 자기계발에 소홀한 날이 거의 없었다.
당연히 개발 서적도 읽어야 하고, 교양서적도 읽어야 하고, 
스타트업 비즈니스 관련 내용이나 서칭 이런 부분에도 많이 고민하고 연구해야 했다.
지금은 퇴사하고 아주 살짝 게을러졌지만 그래도 하루에 일하는 시간 포함 밤 10시에 퇴근해서 새벽 3시까지 공부했고
그것을 몇년간 유지했다.즉 하루에 컴퓨터를 보는시간이 약 14~16시간 이상이었다. 
그것을 꾸준히 몇년간 유지했다.
1만 시간의 법칙이라고 하던가? 이쪽을 전문성가지고 가려면
10만 시간의 법칙은 기본으로 깔고가야지 기본기를 다질 수 있는 것 같다.
1만 시간은 엄청 짧다.

추가로 개발뿐만 아니라 4학년때 복전을 시작하다보니 대학에서 공부 못했던
이산수학, 대학미적분, 선형대수, 수리통계학 이런 부분도 별도로 공부를 했다.
(공부하는데 1년넘게 걸린듯..오래걸림.. 지금은 또 안사용하니 다까묵..)

개발은 쉽지 않다. 솔루션을 제시하는 것은 더 쉽지 않다.

지금도 느끼는 거지만 '한 부분'이 아니라 '원 스톱'으로 돌아가는 서비스 전체를 개발해야 한다는 것은 쉬운 일은 아니다.

단순히 이미 만들어진 것에 살을 붙이는 것이 아니다.

전문 기획자가 존재하지 않고는 무에서 유를 만드는 기획과 개발은 정말 정말 쉽지 않다.

서비스 도메인에 대한 지식이 기본적으로 깔려야지 예측 가능한 시스템을 만들 수 있다.

(예시로 핀테크 관련 서비스 개발을 하려면 핀테크 쪽을 알아야 한다. 단순 기능 개발 말고 전체 시스템 설계..^^)

그러나 경험 없는 나는 정말로 힘들었다.

프런트를 기획하는 것은 다들 머리 싸매서 할 수 있을지라도 시스템 자체를 설계하는 것은 정말로 쉽지 않다.

전문 기획자가 존재하지 않으면 단순하게 '이런 이런 것들이 있으면 좋고 이렇게 됐으면 좋겠어요'로 끝난다.

그럼 디자이너와 함께 문제에 대한 핵심을 파악하고 해당 문제를 어떻게 해결할 수 있을지 고민하게 된다.

다만 현재의 아키텍처에서 데이터 구조상 구현하려면 상당한 시간을 들여야 하는 경우도 있다.

그런 경우는 예상 가능한 시간(예측 가능 비용)이라면 같이 다시 얘기를 해보지만 그것이 아닌 경우는 굉장히 골치 아프다.

그런 일이 빈번하다.

기존에 존재하지 않는 시스템(벤치마킹할 만한 것이 없는)을 만드는 것이라면 빈번하게 발생하는 상황이다.

내가 딱 그랬다.

경험치가 부족할 때 풀어야 하는 문제를 겪으면 솔루션을 제시하는 것이 쉽지 않았다.

그리고 그 솔루션은 온전히 자신이 생각해내야 하고 풀어야 하는 문제였다. (동료가 있으면 같이)

지금도 부족하지만 상대적으로 좀 더 낫다.

문제는 구체적이어야 한다. 그제야 솔루션이 나온다.

문제를 얘기할 때 대부분은 추상적이다. 구체적이지 않다.

그리고 문제를 해결할 수 있을지도 불분명하기에 그냥 넘어가는 경우도 많다.

예를 들어

'사장님들이 사용하는 Admin System을 어려워한다. 어떻게 해결할 수 있을까요?'

'A라는 업체의 대여 상품을 B라는 업체에서 대여해야 합니다. A라는 업체는 B라는 업체에게 상품을 위탁하는 것이고 B라는 업체는 수탁받아서 해당 상품을 운용해야 합니다. 다만 정산은 A라는 업체가 몇 퍼센트의 수익을 가져가고 B라는 업체는 몇 퍼센트의 수익을 가져갑니다. 그리고 우리도 몇 퍼센트의 수익을 가져가야 합니다. 어떻게 하면 좋을까요?'

'각 업체마다 이미 운용하고 있는 요금제가 상이합니다. 어떻게 해결할 수 있을까요?'

'고객이 한 번에 여러 상품을 결제할 수 있는 방법은 있을까요?'

'각 채널별 앱 인스톨 트래킹을 확인할 수 있는 방법은 없을까요?'

'동일 상품 재고 문제는 어떻게 해결할 수 있을까요?'

'해당 상품만 특정 기간에 예약이 안될 수 있도록 할 수 있을까요?'

등

실제로 상당히 많은 문제들이 운영 도중에 발생하며 해결해야 하는 문제, 미뤄야 하는 문제가 존재한다.

각각의 문제에 우선순위를 정하여 해결해야 하는 일로 체크해둔다.

단순히 효율성을 떠나 효과성도 생각해봐야 한다.

이런 부분은 경영진과 무엇을 먼저 해결해야 할지 정한다.

그리고 그 해결하는데 들어가는 리소스(시간, 비용)를 측정하도록 노력해야 한다. 그리고 효과성도 측정해야 한다.

다만 경험이 없다면 리소스에 들어가는 비용을 측정하기도 쉽지 않다.

경험이라는 것도 완벽히 똑같은 경험을 한 것이 아니라면 유사한 경험이라도 새로운 문제는 새로운 문제다.

일반적으로 매번 새로운 문제를 겪는다. 그리고 고민한다.

솔루션을 제시하기 위해서는 먼저 문제를 구체화해야 한다.

왜 그 문제가 생겼는지, 그리고 문제를 해결하려는 이유를 확실히 알아야 한다.

그렇지 않으면 더 많은 비용을 지불할 수도 있으며 생각한 것과 다른 방향으로 갈 수도 있기 때문이다.

위의 문제

'사장님들이 사용하는 Admin System을 어려워한다. 어떻게 해결할 수 있을까요?'

를 어떻게 해결해야 할지 예시로 잡아봤다.

저런 문제는 보통 사장님들이 그냥 '어렵다'라고 얘기하는 경우가 많다.

어떤 부분이 '어렵고' '복잡한지', 정확히 얘기해주지는 않는다.

보통 나이 드신 분들은 그냥 복잡하다. 힘들다 이런 얘기가 많다.

그리고 인간은 귀찮음이 깔려 있기에 '알아서 만들어주고 설정해주고 해결하기를' 바란다.

그리고 나이가 들면 뭔가를 배우는 것에 피곤해하고 힘들어하는 경우가 많다.

뇌가 늙는 것은 자연스러운 일이다.

이건 모든 인간의 비슷한 공통점이다. 시간이 지나면 누구나 겪을 수밖에 없는 문제다. 물론 나도 포함이다.

그럼 이 문제를 어떻게 해결할 수 있을까?

1. UX적으로 쉽게 사용할 수 있도록 조정한다.

2. 사용설명서(가이드라인)를 만들고 배포한다.

3. 주기적인 교육을 한다. 학습시킨다.

4. QnA를 만들어서 참조하라고 한다.

5. 그냥 전화 달라고 한다. 직접 설정하고 조정해드린다.

이미 알겠지만 다 덧가지 방법 중에 정답은 없다.

정답이 없다는 말은 다 덧가지 다 잘못됐다가 아니다.

순서가 틀렸다.

먼저 문제를 제대로 물어봐야 한다.

'무엇을 하는데 어떤 부분이 어려운가요?'

그럼 이렇게 얘기한다.

사장 - '상품을 등록하는데 어렵다'

나 - '음 설명이 어려운 건가요 아니면 뭔가 기입할 것이 많아서 복잡한가요?'

사장 - '기입할 것도 많고 선택할 수 있는 요금제도 많은데 뭘 어떻게 선택하고 어떻게 등록해야 할지 모르겠다.'

나 - '어떤 상품을 등록하시려고 하시는 거예요? 가격정책은 어떤가요?'

사장 - '대여형 전기 자전거를 등록하려고 하는데, 1시간에 4,000원 2시간에 8,000원 받으려고 한다'

나 - '그렇군요. 그럼 3시간에는 얼마 받으실 생각이시고 그 이상 빌려가게 된다면 얼마를 받으실 건가요?'

사장 - '음 그건 생각 안 해봤는데, 시간마다 4,000원씩 추가하는 건 어떨까 생각이 든다.'

나 - '그렇군요. 그럼 만약에 고객이 1시간 30분 또는 1시간 20분 이렇게 빌리면 요금을 얼마로 측정하면 될까요?'

사장 - '음.. 1시간 30분도 2시간 요금처럼 받으면 될 것 같다.'

나 - '알겠습니다. 만약에 고객이 1박 2일 정도로 빌리면 8만 원 이상의 요금이 계산되는데 굉장히 비싸지 않을까요?'

사장 - '그럼 5시간 이후부터는 20,000원 받고 혹시나 그럴 일은 없겠지만 1박 2일이면 40,000원을 받는 것이 나을 것 같다'

나 - '알겠습니다. 사장님께서 말씀하신 관련 요금제는 A1 요금제로 해결할 수 있습니다. 이번엔 제가 등록해드리지만 나중에 새로운 상품을 등록하실 때 A1요금제로 자동으로 등록하실 수 있도록 설정해놓겠습니다. 또 다른 어렵거나 복잡한 것이 있으신가요?'

사장 - '일단은 없는 것 같다. 생기면 말해주겠다'

나 - '알겠습니다. 문제가 있으시면 연락을 부탁드립니다.'

위의 핵심적인 문제는 '상품을 등록할 때 어떤 요금제를 등록해야 하는가'이다. 그 안에 어려움과 복잡성이 묻어있는 것이다.

문제 정리

1. 문제

사장님들이 사용하는 Admin System을 어려워한다.

2. 구체적인 핵심 문제

상품을 등록할 때 어떤 요금제를 등록해야 하는가'

3. 해결 방법

1) 요금제에 대한 선택권을 줄인다.

2) 최초 요금제 설정을 도와준다.

3) 복잡하면 전화 달라고 한다.

4. 이렇게 해결할 수 있는 이유

전제로

'사장님들은 가격을 바꿀지언정 한 번 요금제를 정하면 다시는 바꾸지 않는다'

'이런 문제는 한 번 해결하면 다음에는 겪지 않는다.(빈도수가 극히 낮다)'

이 문제를 해결함에 있어서 UX로 해결할 문제도 아니었고, 가이드라인에 쉽게 설명해야 하는 문제도 아니다.

또한 큰 학습이 필요 없다. 개발은 더 필요 없다. (이미 기능이 존재한다면)

다만 해당 문제가 빈도수가 상당히 높으며, 그로 인해 비효율적인 방향으로 진행된다면 해결 방법을 다른 방법으로 선택할 필요가 있다.

여기서 말하고자 하는 핵심은 해결하기에 앞서 문제를 '구체적'으로 알아야 한다는 점이다.

그때부터 해결 방법론을 논할 수 있다.

문제를 구체적으로 알지 않으면 개발은 산으로 간다.

그건 어느 직무든 분야든 동일하다. 그것을 빨리 깨달아야 한다.

기업의 방향을 아는 것이 개발과 무슨 연관이 있으며 왜 중요한가?

당연히 CTO라면 알고 있어야 하는 부분이고, 일반 팀원들도 알아야 하는 부분이다.

서비스를 운영하고 개발하다 보니 스스로 한 가지 개념을 만들게 되었는데 능동적 예측 개발(Active Prediction Develop)이라는 것이다.

이미 많은 사람들이 무의식적으로 하고 있을 것이다.

'능동적 예측 개발'이란

기업의 방향을 깊숙이 알고 예측하여 개발하는 것으로, A라는 문제가 주어졌을 때 A에 의존되는 유사한 문제들을 예측하여 같이 해결하는 개발 방법으로써 이후에 들어갈 개발비용을 줄이고 신속하게 서비스에 도입할 수 있도록 하는 기법이다.

말로만 해서는 어려우니 예시를 들어보자

예시 문제

한정된 물건을 여러 사람이 대여 예약할 수 있도록 중개하는 서비스가 존재한다고 생각해보자.

1. 물건을 대여할 수 있는 대여 예약 시스템을 만들어야 한다.

2. 물건을 대여한다는 것은 대여일과 반납일이 존재해야 하며, 물건은 유형자산이므로 무한한 것이 아니라 유한하기 때문에 한 사람에게 대여를 했을 때 재고가 존재하지 않는다면 다른 사람에게 대여할 수 없도록 제약을 걸 수 있어야 한다.

3. 누군가가 물건을 대여했으면 다른 사람은 먼저 대여한 사람이 물건을 반납할 때까지 대여할 수 있는 상황이 아니다.

4. 중복 대여를 제한하기 위해서는 항상 대여일과 반납일이 존재해야 한다는 점이다.

그래서 시스템적으로 대여일과 반납일이 존재하고 그 조건을 기준으로 중복 대여를 막는 시스템을 만들었다고 생각해보자.

서비스를 이용하는 고객은 대여일과 반납일을 '선택'하여, 예약을 한다.

여기서 '능동적 예측 개발'을 도입해보자.

'앞으로 기업의 방향이 단순히 물건을 단기적으로 대여하고 반납받는 중개 플랫폼을 떠나 장기 대여뿐만 아니라 정기구독이 가능한 상품을 늘릴 것이다.'라고 예측이 된다고 생각해보자.

장기 대여나 정기 구독은 단기 대여와 다르게 예약 기간이 한정되고 고정되어있고 연장하는 방식으로 운영된다.

즉, 단기 대여는 고객이 반납일을 '선택' 하지만 장기 대여나 정기 구독은 예약 기간이 한정되고 고정되어 있으므로

굳이 고객이 반납일을 선택할 필요가 없다. 대여일만 '선택'하면 된다.

그래서 고객이 대여일과 반납일을 '선택'하는 기능뿐만 아니라 연관된 대여일만 '선택'하면 자동적으로 반납일이 계산되는 기능을 만들어본다.

추후 필요할 때 만들 수도 있지만, 예약 시스템을 만들려고 하는 상황에서 해당 문제'만' 해결하는 것이 아니라 이후에 발생될 문제를 해결하기 위해, 기능을 만들 때 요구사항을 예측하여 일괄적으로 개발을 해버린다.

당장에 쓰이지는 않지만 단기간 내에 사용될 가능성이 높은 기능을 미리 만들어두는 것이다.

[전제조건, 제약]

1. 예측하여 만드는 기능은 개발 시간이 짧아야 한다. 개발 시간이 많이 들어가는 것은 오버 엔지니어링이다.

2. 단기간 내에 사용하고, 필요할 것 같다고 예측 가능한 기능이어야 한다.

3. 복잡한 기능이 아니어야 한다. 복잡한 기능은 생각하는 시간 비용이 들어간다.

4. 오버 엔지니어링과 적정선을 찾는다.

[효과]

1. 예측했던 문제가 실제로 발생했을 때 큰 개발 없이 바로 도입할 수 있다. (신속성)

2. 기능을 만들 때, 이전에 만들어졌던 기능을 다시 살펴보는 시간과 이해하는 과정(시간 비용)이 필요하나, 미리 몰입하여 개발했으므로 시간 비용이 줄어든다.

3. 개발할 때도 미리 가능성을 예측하여 개발했기 때문에 설계 및 코드 유연성이 높아진다.(소프트웨어 수명이 길어짐)

4. 다른 할 것이 많은 상황에서, 기능 추가에 대한 귀찮음이 줄어든다.

나는 실제로 이 방법론을 통해 덕을 꽤 많이 봤으며 서비스에 신속하게 도입하고 적용할 수 있었다.

그뿐만 아니라 다른 부분에 시간을 더 많이 투자할 수 있었다.

여기서 중요한 부분은 '오버 엔지니어링'과 '예측 엔지니어링'에 대해 그 사이에 아슬아슬하게 있어야 한다는 점이다.

기업을 위한 어떤 데이터를 수집해야 하는가?

대부분 개발과 관련된 얘기를 했으나, 기업의 운영이 잘 되고 있는지 판단하기 위한 데이터를 수집해야 했다.

데이터의 가장 큰 단점은 수집하는 시점부터 쌓인다는 점이다.

여기서 얘기하는 것은 개발자들이 수집하는 운영을 위한 또는 시스템 로그를 얘기하는 것이 아니다.

기업을 운영하거나 서비스를 운영할 때 미리 수집해야 하는 데이터를 선정하고 고려해야 했다.

수집하지 않았던 데이터는 알 수가 없으며, 수집 후 알 수 있다.

즉 데이터를 쌓아 나아가야 하는 것에 있어서 필수 불가결한 시간이 걸린다는 점이다.

데이터를 수집하는 큰 이유는, 측정과 평가 그리고 인사이트를 얻기 위함이다.

'우리가 잘 해내고 있는가, 앞으로 어떻게 더 성장을 해야 하는가'를 판단하는 기준에 도움이 된다.

예시로

KPI가 빈번하게 바뀔 상황은 많지 않겠지만, 만약에 이런 상황이 발생한다고 생각해보자.

마케팅 팀의 KPI가 '회원가입 전환율'이라고 해보자.

그리고 그 '회원가입 전환율'은 매출과 직접적으로 연관된다고 가정한다.

그래서 돈을 태운만큼 얼마나 효과가 있는지 측정하기 위한 기준을 '회원가입 전환율'로 정했다고 가정한다.

문제 정리

1. 해당 KPI 적용 팀

마케팅 팀

2. 문제

회원가입 전환율을 어떻게 계산하고 그 기준은 어떠한가?

3. 구체적인 핵심 문제

'회원가입 전환율'이란 정확히 무엇인가? (사내 정의)

'회원가입 전환율'에 포함되는 데이터의 기준 문제

'회원가입 전환율' 기간별 측정 방법에 대한 기준 문제

'회원가입 전환율'을 알려고 하는 이유는 무엇인가? 마케팅에 의해서 퍼포먼스를 확인하기 위함인가? 그렇다면 그 기준 측정은 어떻게 해야 하는가?

Dirty 데이터를 어떻게 필터링해야지 '회원가입 전환율'을 최대한 오차 없이 측정할 수 있는가?

4. 다양한 시나리오 체크

1) 최초 앱 다운로드 또는 웹으로 접속 이후 긴 기간 동안 회원가입을 하지 않다가 회원가입을 하는 상황도 '회원가입 전환율'에 포함이 되는 것이 맞는가?

(1) 예시 상황 1

A 프로모션 기간은 2020-03-01 ~ 2020-03-20일이다.

고객의 최초 앱 다운로드 또는 웹 접속이 2020-01-01이고,

2020-03-01에 회원 가입을 했을 때 과연 마케팅의 효과로 인해 전환되었다고 할 수 있는가?

2) 어느 기간의 회원 가입자만 '회원가입 전환율'에 포함시킬 것인가?

(1) 예시 상황 1

B 프로모션 1주일 정도 진행하며 기간은 2020-07-06 ~ 2020-07-12이다. B 프로모션이 '회원가입 전환율'을 증가시켰다는 것을 판단하기 위해 2020-07-06 ~ 2020-07-19까지 회원 가입자에 대해서만 '회원가입 전환율'에 포함된다.

3) 동시 다발적으로 프로모션이 진행될 수 있다. 여러 프로모션 중 '회원가입 전환율'에 가장 효과가 좋은 프로모션은 무엇인가?

(1) 예시 상황 1

A 프로모션, B 프로모션이 동시에 진행 중이다. 하나는 페이스북에서, 하나는 제휴 마케팅을 통해서 진행된다. 그리고 각각 프로모션에 대한 효과를 파악하려고 한다.

4) 중복가입자도 포함시키는가? (회원 탈퇴 후 재가입 또는 여러 계정을 통한 회원가입)

5. 설계 준비

1) 정의

회원가입 전환율은 프로모션 기간을 포함하여 종료기간에서 7일을 더한 기간의 회원 가입자 수 / 최초 앱 다운로드 또는 웹 접속자 수를 뜻한다.

2) 공식

회원가입 전환율 = (프로모션 시작 기간 ~ 프로모션 종료기간 + 7 day의 최초 회원 가입자 수) / (최초 앱 다운로드 또는 웹 접속자 수)

6. 주의 사항

1) 중복가입자 문제 최대한 방지

2) 최대한 오차 없이 최초 앱 다운로드 또는 웹 접속자 수를 측정하는 방법

(1) finger printing 방식

(2) referer 방식

(3) 그 외

3) 프로모션 당 각 다운로드 또는 접근 링크 제공 필요. 리다이렉트 또는 프락시 방식으로 원본에 접근 가능해야 함.(앱 다운로드 링크 또는 웹 페이지 접근 링크)

7. 수집해야 하는 데이터

1) 최초 회원가입 날짜

2) IP

3) User-Agent

4) 디바이스 정보 또는 해상도

5) 브라우저 정보 또는 그 외 Finger Printing 할 수 있는 데이터

6) 회원을 식별할 수 있는 익명의 토큰

7) 링크 정보

8) 회원가입 시 CI 또는 DI (회원가입 방식에 따라 제공 비 제공 여부 달라짐)

9) 기타

이렇게 간략하게 예시를 정리해볼 수 있다.

다시 한번 얘기하지만 먼저 문제를 정확히 파악하고 해당 시나리오를 최대한 검토하면서 필요한 데이터를 수집해야 한다.

CTO는 최고 엔지니어이나 엔지니어적 마인드를 가지면 안 된다.

각 유수한 기업의 CTO들의 각 가치관들이 있고, CTO의 가치관과 CEO의 가치관이 합쳐져 문화를 만든다.

정답은 없다. 여러 CTO의 인터뷰를 보거나 얘기를 해보면 각 생각하는 방향이 조금씩은 다른 점을 느낄 수 있다.

'CTO는 최고 엔지니어이나 엔지니어적 마인드를 가지면 안 된다'라는 것은 개인적 가치관일 뿐이다.

일단 기본적으로 팀원으로 일하는 엔지니어와 CTO의 차이를 이해해야 한다.

•일의 범위

•책임의 범위

•능력의 범위

일의 범위

일의 범위는 당연히 넓을 수밖에 없다. 기업 서비스의 규모와 크기 따라 팀원의 수도 다르며, 구성도 다르다.

그리고 구성에 따라 일의 범위도 달라진다. 구성이라 함은 직무로 나뉘어있는 카테고리라고 볼 수도 있을 것 같다.

확실하게 얘기할 수 있는 건 기업의 규모와 팀 규모에 따라 하는 일이 조금씩 달라진다.

예시로 이전의 X사는 CTO팀이 별도로 있어서 CTO는 개발에 참여할 시간보다, 내/외부 미팅 및 기술 연구들을 직접 챙기는 경우가 많았다.

그리고 국내의 CTO 포지션과 해외의 CTO 포지션은 조금 다른 것으로 알고 있다.

팀 개발 문화 설계 - 팀원들이 자유하되 방종하지 않고, 지속적으로 의욕을 갖도록 고민하고 성찰한다. 팀원이 최고의 퍼포먼스를 낼 수 있도록 성찰하고 고찰한다. 어떻게 하면 팀원들의 불만을 최소화하고 기업의 비전과 생각이 맞아떨어지도록 도와주고 성장시킨다. 최소한 '000 출신은 뭔가 다르다'라는 인정을 받게끔 만든다. (규모가 작은 팀인 경우는 가능하다)

기술 로드맵 구성 - 기업의 현재 방향과 미래의 방향에 여러 발짝이 아니라 한 발짝만 앞서, 앞으로 해야 개발팀이 나아가야 할 방향에 대해 고민하고 성찰한다.

설계 - 기업의 도메인을 가장 빠삭하게 알아야 하며, 그에 따라 비즈니스 로직을 설계한다. 또한 기업의 기술 설계에 대해 당연히 알고 있어야 한다.

개발 - 인원이 적으면 당연히 직접 개발해야 하며, 인원이 넘쳐나서 이미 팀 자체가 시스템화가 잘되어있다면 그 시스템이 잘 돌아가도록 유지한다. (여기서 개발은 프로그래밍을 뜻한다. 프로덕트 개발을 얘기하는 것은 아니다.)

기술 연구 - 기업의 미래의 먹거리가 될 수 있으며, 경쟁력이 될 수 있기 때문에 직접 챙긴다. 대부분의 CTO의 시선은 여기에 머물러있다. 챙긴다 함은 직접 개발이 될 수도 있지만, 유능한 인력을 직접 데려오고 선출하여 지속적으로 경쟁력을 확보하도록 한다.

문서작업 - 비서가 있을 정도가 아닌 경우가 대부분이기에, 정책, 계약서, 법적 관련 내용과 관련하여 문서 작업한다. 소프트웨어 품질의 기준을 작성하기도 하고 확인하기도 하고, 그 외의 잡다한 것을 하게 된다. 예시로 위치기반 서비스 사업자, 또는 개인정보보호법 체크, 보안인증받는 것 등이 있다.

책임의 범위

책임의 범위는 임원이 가지는 책임과 기업이 정상적으로 굴러갈 수 있도록 의사결정자로서 책임을 진다.

기업 방향 의사결정 - 기업의 방향이 진행함에 따라 C Level 임원들과 함께 매 실시간 의사 결정을 하며 책임져야 한다.

개발 - 기업의 서비스 기술 개발 운영 문제에 대해 모든 책임을 진다. 기업의 서비스가 정상적으로 운영될 수 있도록 책임을 진다. 또한 미래 먹거리를 발굴하고 찾아내야 한다. 말 그대로 최고 기술 책임자이다.

팀원 - 팀원이 지속적으로 성장할 수 있도록 코칭하며, CEO와의 다리로써 기업의 비전을 지속적으로 주입시켜 주어야 한다. 항상 왜?라는 질문에 답을 할 준비가 되어있어야 한다. 해외에서는 별도로 개발 팀원들을 코칭하고 부스팅 시키는 직무가 별도로 있다.

능력의 범위

개발 - 뛰어난 동료들과 일을 나눠 가지거나, 최소한 인력이 넘쳐나서 개발할 시간이 없을 정도가 되지 않는 한, 엔지니어링과 연구는 무조건 잘해야 한다. 당연하다. 그 기준은 각 CTO의 가치관에 따라 갈린다. (사고력, 눈, 손목이 비정상이 되기 전까지)

커뮤니케이션 - 혼자 일하는 것이 아닌 다수의 사람들과 일하므로, 설명과 설득을 잘해야 한다. 협상도 잘해야 한다. 그러나 대부분의 엔지니어 출신 CTO는 조금 어려워하는 부분이다. 실제로 비 개발자 출신들에게 설명이나, 설득은 쉽지 않은 부분이다.

인력 - 인력은 곧 힘이다. 유능한 인력을 끌어오거나 도움을 받을 수 있다면, 기업의 문제를 좀 더 쉽게 해결할 수 있다. 이 부분은.. 음.. 가장 어려운 부분이 아닌가 싶다. 용병술은 기업이 커질수록 CTO의 가장 큰 무기 중 하나이다.

정신력, 체력 - 체력은 말할 필요가 없다. 정신력, 체력관리는 자기 계발 중에서도 가장 중요하므로 프로페셔널한 생각을 가지고 있다면 잘 관리해야 한다. 하나 정말로 쉽지는 않다.

적응력 - 적응력이라 함은 새로운 기술을 받아들이는 것에 있어서 거부감이 적어야 한다. 빠른 학습능력을 가져야 한다.

학습력 - 항상, 고찰하고 고민하고 지속적으로 발전해야 한다. 발전하지 않는 CTO가 위에 있으면 팀원 전체가 매너리즘에 빠질 수 있다.

여태까지 원론적인 이야기였고.

현실은 다르다.

규모가 압도적으로 큰 기업의 CTO가 아니라면 대부분 이와 같은 비슷한 고민과 문제를 가진다.

어떤 가치관을 가진 CTO가 되어야 하는가?

어느 정도까지 개발 능력을 키워야 하나?

다른 일을 하느라 개발을 잘 못하고 있다. 그러다가 도태되지 않을까?

내가 알지 못하는 코드들이 많아지고 있다. 어디까지 알고 컨트롤해야 하는가?

팀원들에게 나는 어떤 CTO이어야 하는가?

이게 소규모 기업의 CTO가 가지는 생각이 아닌가 싶다.

개인적인 생각으로 인간은 완벽하지 않고 완벽할 수도 없고, 모든 일을 혼자서 할 수 없다. 절대로.

결국은 협업이고 사람에 대한 오케스트레이션이다.

C Level의 임원이 돈을 많이 받는 이유는 책임과 의사결정에도 있지만 사람에 대한 오케스트레이션을 하기 때문이다.

사람을 오케스트레이션 하는 것이 가장 어렵다.

'열 길 물속은 알아도 한 길 사람 속은 모른다.'

결론적으로 'CTO는 최고 엔지니어이나 엔지니어적 마인드를 가지면 안 된다'라는 얘기를 정리하면

일반적으로 '월급 받고 엔지니어링하고 팀원들 관리하고 있으니 내 할 일 끝났으니 끝이다'라는 마인드로는 경력 쌓아서 개발 팀장 정도는 될지 몰라도 CTO가 되려면 생각이 많이 바뀌어야 한다.

본문 맨 위에서 얘기했지만

'기업의 비즈니스 모델을 기술적으로 녹여낼 수 있는 사람'

'기업의 위기가 찾아왔을 때 혁신적으로 방향을 뚫을 수 있는 사람'

'기업의 기술 로드맵을 그리는 사람'

이 부분이 CTO와 엔지니어의 큰 차이점이라고 볼 수 있다.

마지막으로

조그마한 스타트업의 CTO직을 내려놓고 나오면서 잘했던 점은 무엇인지 또는 부족한 점은 무엇인지 성찰과 정리를 했었다.

짧다면 짧고 길다면 길 수 있는 4년 넘게 CTO로 있었던 그 시간은 힘든 점도 많았고 굉장히 많은 것을 느끼게 하고 배울 것이 많았다.

어찌 보면 문돌이로서 좋았다면 좋은 기회, 그저 그랬다면 그저 그런 기회로서 어떤 기회이든 배울 것이 많고 생각을 강제적으로 많이 할 수밖에 없는 직급과 직무였다. 큰 기업의 CTO도 아니고 작은 기업의 CTO 직무를 맡았지만 생각해보면 항상 부족하고 연구하고 알아가고 배워야 할 것들이 넘쳐났었다.

환경이 사람을 만든다고 하던가.

그런 기회가 주어진 것에 감사하고, 이제는 새로운 도전을 위해 쉬어가는 중이다.

지금도 누군가는 CTO로서 또는 엔지니어로서 또는 개발을 입문하거나 문돌이로서 새로운 시작을 도전하는 분들을 위해 응원한다.

앞으로 더 힘들 수도 즐거울 수도, 재미날 수도, 버거울 수도 있지만 그럼에도 잘 이겨내리라 믿는다.

'저 같은 빡대가리도 CTO 직무를 맡았는데요..'

저작자표시 변경금지