치킨모임
920
2022-08-03 14:11:52 작성 2022-08-05 09:21:06 수정됨
5
3522

2년 9개월의 스타트업(B2C) 여정을 마치며 [ 경험 공유 ]


안녕하세요.


일전에 

아이들랩 - 아이고고 앱의 CTO로 재직했던

배진호입니다.


B2B 기업에서

B2C 기업의 CTO로 경험했던 이야기들을 정리해보고,

회고해보는 시간을 가지려고 합니다.


모든 일에는 시작과 끝이 있고,

어쩌면 그 길이 더 길어질 수도, 짧아질 수도 있지만,

또 남는 것들은 경험들이니까요.


첫 회사는 삼성 엔지니어링의 CI 그룹에서 개발이었습니다.

회사의 그 당시 임직원은 1만 명 정도에 가까웠고,

주 고객은 최대가 만 명이었습니다.


사내에 홈페이지도 만들고, 사내 사람들을 위한 다양한 서비스들을 만들었습니다.

당시 했던 직무는 인사팀 업무, 사내 EP 서비스 운영/개발 업무,

상담 센터 관련 홈페이지 유지보수 및 개발, 사내 블로그 개발 및 유지보수,

IT 자산 관리 개발 업무, 전사 모니터링 시스템 개발에 참여 등등

메일링 및 메신저 연동, 사내 클라우드 서비스

전사적으로 필요한 업무들을 주로 수행했는데요.


그러나 보니 사내에 중요한 시스템과 관련된 업무들이 주축을 이루었고,

대부분의 시간들을 이런 시스템을 분석하고,

이해하는데 주 시간들을 보내었습니다. 


하나의 사내 서비스를 론칭하기 위해서는 3개월, 6개월 등등 그런 시간들을 배정하고 할당했었는데요.


첫 스타트업이었던, 스튜디오 봄봄, 그리고 지난 회사였던 아이들랩에서는

B2C로써 B2B와는 다르게 생각해야 할 것들이 많이 있었고,

그 결과 다양한 시도들을 해볼 수 있었습니다.


제가 오래전 

https://brunch.co.kr/@chickenmoim/9 

 

이런 문제를 화두로 던진 적이 있습니다.

당시 전 웹 개발자로서, 시장의 변화가 앱에 있다고 생각을 했고,

앱 개발자로 전직을 해야 하는지까지도 고민을 했던 부분이 있었는데요.


아이들랩에서 지난 2년간 했던 것들과

그리고 그 결과들에 대해서 이야기해보겠습니다.



앱으로의 첫 진입

처음 아이들랩의 입사는

기존 프리랜서를 하다가 대표님의 제안으로 입사를 했었습니다.

당시 40세가 되기 전, 스타트업, B2C로서의 성장을 경험해 보는 것에 대해서 무척이나 심취해 있었는데요.

연봉은 크게 중요하지 않다고 생각을 했었고, 그런 부분은 상관하지 않고, 회사에 참여하게 되었습니다.


회사에서는 당시 앱이 없었고,

모두 웹으로 돌아가고 있었고, 웹으로 결제가 이어지고 있었습니다.

참고로 아이들랩에서 개발한 서비스는 아이 고고입니다. 

아이고고는 부모와 선생님을 이어주는 서비스입니다. 특히나 보육적인 부분보다는 교육적인 부분에 강점이 있고, 튜터님들은 다양한 클래스를 만들 수 있는 선생님들입니다. 아이 키우는 입장에서, 원어민, 발레, 수학, 코딩 등등 집으로 찾아오는 서비스가 많지 않은데, 일종의 프리미엄 선생님들로, 선생님들이 집에 찾아오는 독특한 서비스를 하고 있었습니다.

제 생각에는 너무나 좋은 서비스고 미래적인 서비스인데, 알려지지 않았기 때문에 아직 성장에 대해서 가능성이 많다는 생각을 했었고, 함께 개발을 시작했는데요.


첫 고민은,

앱을 만들 것인지, 말 것인지였습니다.

제 입장에서, 기존에 없던 것을 만들어야 하는 부담감이 있었는데요.

조금 더 편한 생각으로는 기존의 웹을 유지 보수하고 하던 데로 그냥 하는 부분이었지만,


회사가 성장하고, 매출을 만들고, 지표를 만들기 위해서는

이 시장에서 앱을 론칭하고, 사용자를 모아야겠다는 생각이었습니다.


그 결과

https://brunch.co.kr/@chickenmoim/21  


이렇게 앱이 탄생합니다.

총 6~9개월이 걸렸고, 지금은 안드로이드, 아이폰 합쳐 기존 고객 대비 400% 이상 성장을 하고 있습니다.


여기서 중요한 부분은

기존에 웹으로 사용하던 고객이 앱으로 모두 전환을 하지 않으면 어떡할 것인가?

그리고 앱이 생각보다 반응이 없으면 어떡할 것인가?

웹은 광고가 앱보단 쉬운 편인데, 앱으로 어떻게 계속 lock-in을 시킬 것인가?


등등 기존 결제 플로우와 앱으로의 결제 플로우가 다른 부분도 고민해야 하는 부분이었습니다.

그리고 가장 큰 맥락이었던 채팅 시스템을 만들기.

웹으로 서비스를 할 때는 채팅 시스템이 없었습니다.


신규로 앱 서비스를 론칭할 때 부모님과 선생님을 이어주는 중요한 브리지로 채팅 시스템이 가장 중요하다고 판단을 했는데요. 그만큼 채팅에 대한 설계는 복잡하고, 공수도 많이 들어갔던 부분이기도 합니다.


특히나 리엑트 네이티브로 개발하면서, 아이폰과, 안드로이드, 그리고 웹 상에서 모든 소켓들이 자연스럽게 이어지는 부분을 테스트하고 개발하는 과정이 쉽지 않았고, 많은 테스트를 거쳤습니다.


하지만, 그 결과 채팅을 통해서, 기존에 생겨났던 업무들이 많이 줄어들게 되었고, 더 많은 사용자들이 이 앱을 통해서, 유입되고, 검색하고, 결제할 수 있게 되었죠.


B2C에서 뭔가를 개발해야 한다는 건, 시장의 반응을 살피고,

고객의 니즈를 반영해야 한다는 점이었습니다.


그 당시 함께 중간에 함께 합류해주셨던 기획자 분께서 이 많은 일들을 견인해주셨습니다.

가장 크게 감동받고 느꼈던 것 중에 하나는,

실제 고객과의 만남을 자처하셨는데!

실제로 미팅도 하기도 하고, 전화하기도 하면서, 최대한 고객의 눈높이를 맞추기 위해 적극적으로 

고객 안으로 들어가셨다는 점입니다.

때로는 상담도 하시고 전화도 하면서 생기는 고객의 정확한 니즈들을 파악하고,

그게 기획이 되고, 운영이 되고, 앱으로 구현되었을 때!


그 결과들의 꽃들은 아주 천천히 서서히, 그리고 다양하게 반영됩니다. 고객의 리뷰로써, 앱의 사용성으로,

앱의 디자인으로..


b2c를 하면서 겪었던 가장 좋았던 것은 고객과 소통하고, 그 발전을 눈으로 함께 볼 수 있었다는 점이었습니다. 



함께한 개발자들

작은 회사이지만,

CTO의 직무로 경험하고 생각한 것들 중 하나는 누군가와 함께 개발할 것인가입니다.


이직 후에 개발자는 대학생 개발자 1명이었습니다.

그리고 인턴으로 한 명의 개발자가 더 있었죠. 3명의 개발자가 이런 것들을 다 처리해야 한다.

당연한 스타트업 입장에서, 스타트업스럽게, 다해야 하는 상황이었죠.


개발을 어디까지 해야 하는가?

사실 CTO의 직무보다는 개발 업무가 훨씬 많았습니다. 다만, 관점을 그렇게 가져야 했죠.

대표가 바라보는 관점의 시각을 비슷하게 유지하면서도, 

가능한 부분을 조언해야 했고, 동시에 개발자의 관점으로 생각을 해서 일정도 조절해야 했습니다.


자바 개발자인 동시에 리엑트 개발자가 되어야 했고

나중에는 리엑트 네이티브 개발자가 되어야 했죠.


프론트 개발도 하면서, 서버 세팅부터, 배포까지, API 개발도 해야 했고요.

나중에 서버 측 REST API를 만든 개수를 세어보았습니다. 130개 정도 되던데...

아마 이런 부분에 대해서 고통과 고민에 대해서는 아마도 아는 사람만 아는 그런 류일 것입니다.


https://brunch.co.kr/@chickenmoim/17 


이런 직종의 전환과 관련된 글도 쓰고 고민도 했었죠.


아직 초기의 스타트업 대표님들, 그리고, 개발자가 부족하고 적어서, 힘들어하시는 분들,

그래도 할 수 있긴 합니다. 인원이 적다고 너무 낙담하지 않기를, 가능하긴 하다! 응원을 드려봅니다.


몇 가지 프로젝트를 진행하고서

첫 개발자는 이름 있는 좋은 기업으로 떠났습니다.

연봉도 대우도 잘 받고! 너무나 축하할 일이었죠.


하지만, 당장 앱을 개발해야 하는데, 인력이 없다는 건, 매우 힘든 일입니다.

모임을 하면서 좋은 점이라면, 좋은 사람들을 많이 알고 있다는 점이죠. 


그래서 안드로이드도 개발할 줄 알고, 아이폰도 개발할 줄 아는 친구를 회사로 섭외했습니다.

이런 부분이 CTO의 직무겠죠..


다행스럽게도(?) 그 친구는 기존에 실력에 비해서 너무 좋지 않은 처우를 받고 있었고,

전 그보다는 훨씬 좋은 대우를 줄 수 있었죠. (일종의 WIN-WIN)


그 친구는 리엑트 네이티브도 할 줄 몰랐고, 리엑트도 할 줄 몰랐습니다.

따라서 리엑트 문법은 배워야 하는 상황이었죠.


뭐 저도 배워서 하는 마당이었는데, 그 친구도 충분히 가능할 것이라고 생각했죠.

그래서, 같이 배우면서 하기로 했습니다. 제가 구조는 잡아두고! 살을 같이 붙이도록 말이죠.


다행스럽게도, 안드로이드와 아이폰의 구조를 알고 있다는 건, 생각보다 리엑트 네이티브의 앱 개발의 속도를 더해주었습니다. 그래서 실제로 앱을 론칭하는데 아주 중요한 역할을 했죠.


결과적으로 런칭 완료!

다시 한번 더 짚고 갑니다.


https://play.google.com/store/apps/details?id=com.igogo&hl=en_US&gl=US 

https://apps.apple.com/us/app/%EC%95%84%EC%9D%B4%EA%B3%A0%EA%B3%A0-%EB%A7%9E%EC%B6%A4-%ED%82%A4%EC%A6%88%ED%81%B4%EB%9E%98%EC%8A%A4-%ED%94%8C%EB%9E%AB%ED%8F%BC/id1524244020


팀원 한 명은 그 뒤로 아쉽게 

다른 회사로 가게 되었습니다.


결과적으로 다시 혼자서 개발/운영

CTO?? 팀원?? 팀장?? 인격체가 다양하게 나누어지기 시작했죠.


그 뒤로, 회사는 그래도 꾸역꾸역 계속 성장합니다.

다시 개발자를 뽑아야 하는 시점!


면접들을 다시 보기 시작했습니다. 그 결과 개발자 분들을 더 채용하게 되었는데요.

다른 직무들을 하시다가 개발일을 하려고 오신 분들이었습니다.


가장 먼저 보았던 것은,

가능성, 해보았던 것들도 중요했지만, 성장할 수 있는지, 

배우고자 하는지, 그리고, 열의는 어떠한지.. 등등이었습니다.


결과적으로, 일반적인 신입을 뽑기보다는 

다른 일을 하다가 직무를 전환하신 분들을 더 뽑게 되었는데요.


기존 직무에 비해서 일을 어려워하지 않을지 걱정하실 텐데,

그보다도, 이미 기존의 직무가 적성이 아니라고 판단하시고, 새로운 일을 접하시고, 열정이 있으셨기 때문에

훨씬 더 일에 대한 적응력이 빠르셨고,


다른 직무에 대해서도 이미 이해도가 있으셔서,

업무적으로도 훨씬 더 자유로운 의사소통이 가능했습니다. 


개발자가, 개발만 하는 것보다, 커뮤니케이션이 가능한 상태로 개발에 임하게 되면,

업무적인 효율이 훨씬 더 증대된다고 생각을 하는데요.


그게 잘 되었다는 점이 매우 좋았죠.


업무에 관해서는

새로 오신 분들 입장에서, 프론트 직무, 서버 직무, 이렇게 정해져 있지 않았습니다.

어찌 보면 업무가 너무 많은 거 아니냐 이렇게 생각할 수도 있는데요.


결국 일의 총량이 중요한 것이지, 업무를 바꾸어서 해보는 것 자체는 중요하다고 생각을 합니다.


따라서, 저희는 리엑트쪽 프런트 개발 업무도 있었고,

리엑트 네이티브 앱 쪽 관련 프론트 업무, 그리고 서버 업무도 있었는데...


관련해서 업무들을 쪼개어서, 먼저 하고 싶은 업무들을 정하고, 거기에 서포터를 해주는 방식으로,

업무가 진행되었습니다. 한쪽에서는 서버 업무 & 서버 서포트, 리엑트 네이티브 앱 업무 & 관련 서포트..


결과적으로는 한 번씩 내부적인 교육도 진행을 했었는데요.

서버&인프라에 대해서 교육

리엑트에 대해서 교육

디비 구조에 대해서 교육


https://brunch.co.kr/@chickenmoim/11 


첫 강의 이후에, 몇몇 강의들을 진행하고 있는 터라!


어찌 보면, 이런 교육들이 그분들 입장에서는 조금 더 적응하기 좋았던 게 아닌가 생각이 되네요.


나중에는

앱 내에 론칭하는 한정 판매&커머스 부분을 진행하는 데 있어서

두 분이 거의 진행했다고 봐도 무방할 정도로, 잘해주셨다고 생각해요!


제가 생각하는 CTO는 매니징이 필요하면 매니징, 교육이 필요하면 교육, 개발이 필요하면 개발

회사에 기술적으로 부족한 부분이나 성장에 장애가 되는 요인들을 걷어내고,

때로는 의사 결정으로, 때로는 실제 개발로, 때로는 인원 충원 등으로 나아갈 수 있도록 방향을 만들어주고,

동기 부여하고, 또 실행하는 게 아닌가 싶습니다.



업무 효율화에 대하여


관점이라는 건 참 중요하다고 생각합니다.

보는 시각에 따라서, 아 이 회사 망하겠네? 아 이 회사 성공하겠네?

인원이 적으면, 아 인원이 적으니까, 업무로드가 적겠다, 빨리 의사 결정하고, 빨리 실행할 수 있겠다.

반면 인원이 많으면 많을수록, 개선이 어렵겠다. 산으로 갈 확률이 높겠다.


기본적으로 가지고 있는 생각들을에 대하여, 

틀을 깨고 관점을 전환하는 것이 중요하다고 생각합니다.


사람들은 하는 업무가 있을 때, 그 업무가 업무로써 자연스러워서, 계속 그 경향을 가지고 그 일을 하려고 하기도 합니다.


제 첫 강의는 devOps 였습니다.

업무의 툴의 요소도 중요하지만, 가장 중요한 것은 업무에 대한 효율을 높이는 것이라고 생각했죠.


개발자로서 기존의 회사들은 

배포 담당자가 따로 있었고, 문서를 쓰느라 실제로 개발에 대한 시간들이 2~3배 들어가고 있었죠.

레퍼런스 차원에서 문서가 매우 중요하다고는 하지만, 가끔은 함수에 오타 하나 수정했는데, 이걸 위한 문서를 작성할 때면, 아.. 이거 매우 비효율적이라고 생각하는 부분이 많았는데요.


따라서, 

첫 번째는 배포 효율화 - 기존에 로컬에서 작업하고, 배포하던 방식을 깃의 repo를 통해서 개발 배포와 운영 배포를 나누어서, 깃에 있는 것을 내려받고 빌드하고 배포하는 방식으로 전환합니다.


두 번째는 깃과 관련된 내부 원칙 확립 - 브랜치 전략상, 너무 많은 브랜치가 주는 비효율성 때문에, 스타트업으로써 각각 내부에 개발 브랜치 르 및에 하나씩의 브랜치를 두는 방식으로, 심플한 브랙치 전략을 가져갔습니다.


세 번째는 업무 효율화

처음 회사에 와서, 알람 톡을 세팅했는데요. 상호 교차 고객이 어떤 지점에서든 알람을 받을 수 있도록 만든다. 그리고 실제 스케줄이 잡혀있을 때 알람 톡을 활용해서 진행한다.

나중에 알람 톡의 타입 개수만 20개 이상으로 늘어났는데요. 그만큼 고객 간의 브리지를 잡아서, 알람 톡을 효율화하는 작업만으로도 고객 입장에서는 편하다고 느낄 수 있는 포인트를 많이 만들었습니다.


네 번째는 슬랙 알람 활용 

고객의 여러 가지 반응에 대해서,

슬랙으로 올 수 있도록 훅을 이용해서, 고객의 리뷰부터 다양한 것들을 알 수 있도록 효율화를 했습니다.

그 결과, 다양한 이슈들을 미리 발견해서 처리할 수 있었죠.



다양한 효율적인 부분들이 결과적으로 업무적인 부분의 부하를 많이 줄였다고 생각합니다.

아쉬웠던 건, 리엑트 네이티브의 빌드 배포 자동화를 하고 싶었는데,

그 부분을 못 해본 부분이 아쉬웠던 부분이었죠.


B2C 경험의 결과 - 새로운 회사 

사실

아직도 아이들랩은 성장 중입니다.


날아가는 로켓에 뛰어내려서, 아쉬운 부분도 많이 있습니다.

좋은 기획자분들도 만났고, 좋은 마케터분들, 그리고 좋은 MD와 편집자, 

함께 회의하고 의견을 반영하고 개진하는 대표님을 만나서 너무 좋은 시간들이었습니다.


그 결과 고객을 상대하는 다양한 방법과 개발 방식과 원칙들을 배웠고

마케팅에 대해서도 많이 배우고 성장했습니다.


회사를 이직하면서,

롤링페이퍼를 받아보기는 처음이었지만!

비밀스러운 롤링을 공개합니다.



기존 회사에서

이직하게 된 이유와 배경은


새로운 도전, 그리고 다음 회사의 이야기에서 잘 전달해 드리도록 하겠습니다!


B2C 회사의 CTO 로서 많은 제안들이 있었고,

매력적인 회사에서의 매력적인 제안이 이직 사유라고 할 수 있겠네요.


제가 해야 할 남아있던 숙제가 많이 남아있지만, 남은 분들도 너무 잘해주고 계시고,

더 잘할 수 있을 것이라고 기대합니다.


이상으로 마칩니다.


https://brunch.co.kr/@chickenmoim/23 

23
8