10인 규모의 스타트업 CTO로 지낸다는 것

By on May 30, 2019

[10인 규모의 스타트업 CTO로 지낸다는 것]

2015년 11월, 현수와 처음 코드윙즈를 창업한 이후, 벌써 햇수로는 만 5년 차가 되었다. 그동안 코드윙즈라는 이름을 달고 함께 사무실에서 일했던 팀원들이 21명이 넘어간다. 이 글을 쓰면서 같이 일했던 친구들 이름을 하나하나 적어보면서 함께 일했던 기억을 떠올려보면, 누구 한명 빠짐없이 좋은 사람들과 일을 할 수 있었던 것 같고, 회식하면 예전에 함께 일했던 팀원들도 꼭 함께 만나 간간이 근황을 보면 다들 각자의 분야에서 멋지게 일하고 있는 것 같다.

다만 한가지 아쉽고 미안한 점은 회사 초창기에 조직 관리 시스템이 체계화되어있지 않았다는 점이다. 창업 멤버들끼리는 다 같이 출근하여 일하였고, 테스크도 다양화되기보다는 다 같이 한 테스크에 대해서 하나씩 헤쳐나가는 식이었기에 별도의 협업 도구 없이도 테스크 관리에 대한 문제는 발생하지 않았다. 2017년에는 두 명이서 회사를 운영하고 필요한 디자인 등의 자원은 외주로 돌리던 시기기에 각자의 역할만 잘 지키면 큰 문제 없이 회사가 운영되었다.

그러나 다시 팀원은 늘어가면서 함께 일하는 개발팀만 6명이 되고, 외부 미팅도 많아지게 되면서 모든 테스크에 대해 추적하는 것이 불가능해졌다. 특히 작년에는 EBS SW 교육 사이트 이솦 개발에 참여하게 되어 일산으로 출퇴근하게 되었다. 팀원들과 면대 면으로 소통하는 시간도 줄어들게 되면서 막 새로 시작한 성인 대상 온라인 코딩 Q&A 사이트였던 코드메이트의 서비스 개발에 신경을 쓰지 못하게 되었다. 다행히 당시에 함께 일했던 팀원들이 너무나도 좋은 사람들이었기에 CTO의 부재에도 책임감 있게 개발을 진행하여 서비스 개발은 성공적으로 완료되었지만 결국 올해 초 서비스를 중단하게 되었다. 코드메이트의 서비스 중단에는 마케팅 역량 부족 등의 여러 이유가 있었지만 코드메이트 서비스의 실패 경험은 PM 역할의 중요성을 다시 한 번 재고 하는 계기가 되었다.

2019년 2월, 헬로알고라는 새로운 오프라인 학원을 잠실에 오픈하면서, 학원 학생들이 학습에 사용할 온라인 코딩 학습 플랫폼을 개발하게 되었다. 신규 서비스의 개발 시작과 동시에 코드메이트 서비스에서의 실패 경험이 떠올랐다. 이번에는 같은 실수를 반복하지 않기 위해 첫 2주를 서비스 설계가 아닌 조직 문화를 정립하는 데 사용하였다. img/upload/IMG_6646 EBS에서 16억 규모의 프로젝트 진행 경험을 바탕으로 나름대로 테스크 진행 및 개발 프로세스에 대한 룰을 세웠고, 사무실은 서울대학교 내부에, 학원은 잠실에 있기에 리모트 작업을 하더라도 커뮤니케이션에 문제가 안 생기도록 슬랙을 도입한 후, 여러 채널로 나누어 목적에 맞는 구분 및 의사소통에 대한 룰을 정하였다. 또한, 실제 학생들이 수업에 사용하는 서비스이기에 QA를 중요하게 생각하여 각 테스크 개발 시에 단위 테스트 및 통합 테스트에 대한 룰을 만들어 운영 서비스에서의 오류 발생 횟수를 현저하게 감소시켰다. 테스크 관리에 대해서는 코드윙즈 초창기에는 트렐로를 쓰다가, 아사나를 쓰다가 다시 트렐로 + 슬랙 조합으로 돌아왔다. 아사나는 다양한 기능을 제공한 다는 점에서 훨씬 강점이 있었지만, 이런 협업 도구에 익숙하지 않은 팀원들이 많았기에 트렐로의 칸반 (Ideation -Design - Doing - Pull Request - Merged - Released), 우선 순위에 따른 라벨링, due date 기능만 사용하였다. 테스크 관리에 대해서는 위와 같은 룰을 정하였고, 그 외에 여러 가지 변화를 실험적으로 해보았다.

  1. 가능하면 매일 30분씩 팀원들과 산책을 한다. 사무실이 학교 안에 위치한 덕에, 그리고 학교가 관악산에 있는 덕에 사무실에서 조금만 걸으면 금방 자하연이나 버들골 등 산책할 수 있는 곳이 나온다. 날씨가 좋았던 봄날에는 팀원들과 버들골에 가서 신문지를 깔고 짜장면과 탕수육을 시켜먹기도 하였다. 개발자들이 밖에 나가는 것을 싫어하지는 않을까 걱정하였으나 아직은 모두가 만족하는 괜찮은 도전인 것 같다.

  2. 새로운 협업 도구를 도입할 때는 항상 팀원들에게 그 당위성을 설명하는 것이 중요하게 생각한다. 특히 작은 조직에서, 이전에 조직 경험이 없는 사람이라면 갑자기 무슨 무슨 툴을 사용한다고 사용법을 익히라 하거나, 설치하라고 한다면 반발감이 들기 쉽다. 이런 부분에 대해서 “무조건 써야 해.” 라고 이야기하는 것보다는 그 당위성과 편리함을 이해시켜주는 것이 중요하다. 처음부터 너무 복잡한 툴을 사용하는 것은 좋지 않은 것 같다. 시작하는 초기 단계의 스타트업이라면 무조건 슬랙을 도입하기보다는 익숙한 채널을 사용하고, 서서히 협업툴을 사용하는 것이 좋다고 생각한다.

  3. 서비스 개발뿐만 아니라 다양한 것들을 해볼 수 있도록 한다. 우리 팀원들이 언젠가 다른 조직에서 일하는 날이 왔을 때, “코드윙즈에서는 뭐했어?” 라는 질문을 받게 된다면 “Django로 웹 개발하다가 왔습니다”. 라고 이야기하는 게 아니라 “학원 학생들의 학습 데이터를 가지고 클러스터링을 하여 유의미한 군집을 찾아보았습니다.” “학생의 학습 수준과 푸는 문제의 유형 간의 상관관계를 분석해봤습니다.” “AWS의 ec2에서 배포하던 서비스를 ECS fargate로 이전하고 codepipeline을 설정하여 깃헙에 푸쉬하면 자동으로 빌드 - 배포까지 되는 자동화를 해보았습니다.” “기존 웹 소켓을 사용하던 채점 시스템을 queue - celery 형태로 변경하여 각 솔루션별 채점 시에 같은 자원을 사용하도록 보장하였습니다.” ”Django에서 mysql 검색 성능이 나오지 않는 것 같아 elastic search를 설치 후 벤치마킹 해보았습니다.” 등의 답변을 할 수 있도록, 단순하게 웹 프론트/백앤드 개발이 아닌 최대한 다양한 경험을 해볼 수 있도록 하고자 한다. 물론 이런 테스크를 분배할 때는 항상 테스크를 실제로 수행하는 사람에게 “왜 이것을 해보면 좋을까?” 에 대해서 내가 기대하는 바를 설명하여 주고, 이 부분에 대한 실제 수행하는 팀원의 이해를 구하는 것이 중요하다. 만약에 그 사람이 생각하기에 이런 것들을 하는 것이 불필요하다고 느껴지면 오히려 짐처럼 느껴질 수 있기에 과감하게 변경한다.

  4. 시간이 조금 걸리더라도 분배한 테스크에 대해서는 코드에 직접 손을 대지 않고, 검색 키워드를 알려줘서라도 직접 해결책을 찾아 테스크를 완료하도록 한다. 이전에는 의욕이 앞서서 직접 키보드에 손을 올리는 일이 많았지만, 지금은 테스크를 수행하는 사람이 끝까지 개발하도록 하고, 대신에 풀 리퀘를 날렸을 때 코드 리뷰를 꼼꼼하게 하는 것으로 대신한다.

물론 위의 것들을 계속해서 지속하는 것이 마음처럼 쉽지 않다. 처음에 열정적으로 코드 리뷰를 하던 마음이나, 테스크 분배 때 열심히 설명하던 열정도 일이 많아지고 시간이 지날수록 사그라지고 “이 정도는 알아서 해줬으면” 하는 마음이 들기 쉬운 것 같다. 이런 생각이 들때 마다 아직까지는 많이 부족한 초보 PM인 것 같다. 그래도 여전히 스타트업 문화를 사랑하는 건 이런 하나하나의 작은 변화 속에서 발전을 기대할 수 있기 때문인 것 같다.

Back to blog