## 들어가며 21년 4월부터 25년 4월까지, CTO로 입사하여 개발자 3명이 있는 개발팀을 이끌고 30명이 넘는 R&D본부를 만들고 이끌어왔는데 드디어 대장정(?)의 마침표를 찍게 되었다. 4년간의 여정을 하나의 글에 담아내는게 나의 부족한 필력으로 가능할지 모르겠지만 너무 시간이 지나기 전에 적어보려고 한다. ## Timeline ### 21년 4월, 5월 - 파트타임으로 시작 처음에 회사에 합류하게 된건 사실 단기 프로젝트의 파트타임 계약이었다. 당시만 해도 내 서비스를 개발하고 있었고 당장의 캐시 플로우를 확보하기 위해서 처음 두달은 내 일을 하고 퇴근하고 회사에서 일하는 식이었다. 당시 개발팀의 개발자는 총 3명이었고 그 중 2명과 함께 매일 밤 7시부터 저녁 11시, 어떨때는 자정이 넘는 시간까지 같이 프로젝트를 진행하였다. 몇가지를 했었는데 첫번째는 7000줄이 넘는 단일 컨트롤러 코드를 layered architecture 라도 적용하여 반복되는 코드를 줄이고 raw query 를 repository 패턴으로 분리하거나 재귀함수 제거, functional 패러다임 적용으로 코드를 깔끔하게 정리하려고 노력했다. Node.js와 Express.js를 이용하여 구성된, 프레임워크 없이 만들어진 노드 서버였고 인스턴스 하나에 PM2 를 띄워서 서비스를 운영중이었고, 컨트롤러 코드 내에서 다른 함수를 호출하는 것이 아닌 같은 서버의 API 콜을 하면서 피크 타임에 반복해서 네트워크 오버헤드, 응답 시간 지연이 반복되어서 해당 문제를 해결하는데 대부분 시간을 쏟았다. 또한 푸시나 오버헤드가 큰 작업들을 백그라운드 잡으로 빼지 않고 있어 마찬가지로 서버에 큰 부하를 주고 있었고 해당 작업을 Kafka 를 이용하여 이벤트 처리에 적용하는 것도 하나의 큰 작업 중 하나였다. 이때의 작업은 대부분 레거시 서비스의 특히 백엔드 서버의 여러 문제 해결, 코드 리팩토링, 성능 문제 해소, 서버 안정화 등이 메인이었고 그걸 하면서 Kafka 스터디 및 이벤트 적용, k8s 스터디 등을 진행했다. ### 21년 6월~12월 - 6개월 계약직 CTO 이런 저런 작업을 하다보니 어느새 개발팀의 메인 과제들이 나랑 직접적으로 연결되어 버렸고, 5월에 CTO 직을 제안을 받았다. 기존에 CTO 를 담당했던 전임자 분은 서비스 경험 혁신 부서라는 운영부서를 희망하셨고 안그래도 현금이 필요했던 나는 6개월만 더 해보자 라는 생각에 CTO직 제안을 큰 고민없이 받아들였다. 6월부터는 기존에 계속 가지고 있던 레거시 서비스를 추가 개발하면서 대표님의 제안으로 당시 서비스 중이던 운영 서비스를 레거시를 버리고 완전히 새로운 서비스를 개발해서 대체하는 것을 목표로 하였다. 팀 내에서 프로젝트 명은 SA 서비스 개발이라는 과제명이었고, 이미 100명이 넘는 회사의 시리즈 C까지 받은 서비스를 완전히 새로운 서비스로 개발하는 건 내 입장에서도 꽤 부담스러운 입장이었고 처음에는 기존 레거시를 최대한 개선하는 방향으로 제안했으나 대표님의 완고한 설득(?)으로 완전히 새로운 서비스, 즉 SA 서비스를 개발하기로 했다. 당시 기술 스택은 당시 모든 인원이 Node.js 만 다루고 있었고 그래서 TypeScript 와 NestJS, MySQL 그리고 k8s 에 배포하는 방향으로 기본 밑그림을 가지고 초기 3개월이 넘는 시간동안은 거의 기존 레거시 서비스의 문제점으로부터 출발하여 앞으로 어떤 콘텐츠도 담을 수 있는 확장성 있는 시스템으로 개발할 것인가를 고려하여 설계하고 빠르게 프로토타이핑을 해보았다. 이때 동시에 진행하던게 바로 CMS, 즉 콘텐츠 에디터 시스템이었는데 기존 레거시 서비스는 완전히 기본적인 에디터만 제공하고 있었고 거기에 들어가는 보기 문항 번호나 특수문자 등은 콘텐츠 작업자들이 매크로나 메모장에 별도로 저장해서 사용하고 오류로 동작하는 부분도 마치 하나의 기능으로 승화(?)시켜 콘텐츠 작업을 하던 중이었는데, 이러한 사람들을 나는 콘텐츠 닌자라고 부르기도 했다. 콘텐츠 제작의 문제를 해결하기 위해 CMS 도 새로 기획하고 만들기 시작했는데, 어쩌면 이때가 IHFB 에서는 처음으로 사용자의 의견을 듣고 실제로 콘텐츠 제작도 해보고 그들의 문제점도 공감하면서 고객 중심의 개발을 했던 경험이었다. 단축키 하나하나 까지도 테스트를 해보려고 했던 것이나 중간중간에 개발된 버전을 가지고 간략하게나마 사용자 테스트를 하면서 진행했던 기억이 있다. 사실 콘텐츠라는 것이 교육 비지니스에 핵심과도 같은 것인데 단순히 사람을 더 쓰면 된다는 인식에 가로막혀 어떠한 기술적 지원을 못받고 있었던 조직이었다보니 그들의 문제를 해소해주고 싶은 욕심이 앞섰다. 여튼 이 기간 동안 제대로된 개발팀을 구축하기 위해 대대적으로 채용도 진행하였고 당시에 회사는 시리즈 C 투자를 성공적으로 받았고 역대급 TV 광고 마케팅, 대규모 채용 등 투자금을 이용하여 스케일업에 필요한 다양한 액션들을 취하고 있을때였다. 개발팀도 21년 12월 기준 어느새 4월 기준 3명이었던 팀이 13명까지 증가하였고 내 계약도 어느새 끝을 향해 가고 있었다. ### 22년 - 신규 SA 서비스 런칭을 향하여 시작을 했으니 끝내고 싶었고 여기까지 왔으니 끝은 보고 마무리하고 싶었다. 22년에 두번의 계약을 더 진행하면서 SA 서비스의 마무리를 위해 달리기 시작했다. 회사도 마포에서 여의도 파크원으로 이사를 하였고 우리 팀 뿐만 아니라 회사 전체적으로 공격적으로 채용을 했고, TV에는 이병헌이 나와서 우리 서비스를 홍보하며 대대적으로 마케팅이 진행되던 시기이다. 레거시 서비스에서 돌아가던 모든 것이 그대로 돌아갔어야하고 레거시 서비스의 그것보다 구조적으로 더 뛰어났어야했다. 다만, 생각보다 레거시 서비스는 몇년에 걸친 유구한 전통을 가진 피쳐들이 산재해 있었고 어떻게든 이러한 기능들이 서비스 운영에 여기저기 활용되고 있었다. 아주 조그마한 것이라도 놓치면 서비스 운영이 안되는 상황이었기에 생각보다 길어지는 서비스 개발 기간에 레거시에서 놓친 것은 없는지 체크 또 체크하면서 계속 개발을 해왔다. 서비스가 1차적으로 일단락되어 완성된건 8월 이었고, 영향도나 민감도나 낮은 일부 고객군 (내신 시험을 치지 않는 중1, 고3)을 대상으로 프리 런칭을 진행했다. 그렇게 9월, 10월, 11월 계속해서 프리 런칭 상태에서 12월 마지막 주에 모든 사용자가 새로운 서비스로 마이그레이션 되었다. 1월부터 7월까지 장장 7개월간 개발을 했고 8월부터 12월까지는 실제 운영 서비스에 적용하기 위해 운영팀 교육부터 콘텐츠 마이그레이션 등 개발 외에 다양한 업무들을 소화해냈다. 채용은 계속되어 팀은 20명이 넘어가고 있었고 여름즈음해서 소위 네카쿠라배 팀장급 인사들도 팀에 합류하면서 한결 더 팀다운 팀으로 발전하며 서비스 개발과 런칭에 만전을 기했다. 마지막 컨텐츠 마이그레이션을 위해 새벽 4시까지 회사에서 팀원들과 작업을 했었는데 아직도 그때 직전의 강렬했던 기억들이 남아있다. 정식 릴리즈까지 꼬박 1년이 넘게 걸리다보니 사실 이게 끝나긴 끝나는 건가 의심하기도 했다. 어느새 단순 개발팀이 아니라 R&D 본부라는 명칭으로 하나의 본부에 자리잡아 독자적인 조직 문화를 형성하며 어느새 하나의 조직이 되어 움직이고 있었고 팀장급 인원들도 들어오고 우여곡절 끝에 서비스도 런칭하면서 이제 드디어 마무리하는 시점이 다가왔다. ### 23년 1월~8월 - 정규직 전환 그리고 고도화 22년 말 아이러니하게도 드디어 런칭을 했을때, 회사에서는 정규직을 제안했고 고민할 수 있는 짧은 시간이 주어졌다. 솔직히 런칭을 했지만.. 아직 서비스 안정화부터 서비스 운영에서 벌어지는 다양한 이슈 등 해결해야할 문제가 산더미였다. 그래도 1년을 넘게 서비스에 쏟아서 그런가 이 서비스가 다시 자리 잡고 고도화되는 방향을 보고 나가고 싶다는 욕심이 생겼다. 결국 이 시기에 적지만 회사 주식을 매입하여 회사 주주가 되었고 회사에서는 처음으로 정규직으로 일하기 시작하였다. 마음가짐도 고쳐먹었다. 이때까지는 항상 나는 회사에서 외부인이었고 그런 마음으로 일을 계속 하고 있었는데, 이제는 조금 더 진심으로 임해보자. 핑계대지말고 내가 할 수 있는 일은 최선을 다해보자. 그게 내 결심이었다. 새로 만든 건 좋은데 기존에 비해 구조도, 인프라도 복잡해져 있었고 장애 대응이나 여러 해결책들도 난이도가 꽤 있는 상황이었다. 그래도 이즈음 구성된 백엔드, 프론트엔드, PM 세 명의 팀장 체제가 기능팀을 잘 컨트롤 해내면서 여러 문제가 있었지만 굉장히 이상적으로 업무 프로세스를 갖추어나가고 있었다. QA도 이즈음 신설이 되었고, 아마 이 시점에 이미 약 25명 넘게 인원이 있었다. 실제 서비스에서도 기존 상품보다 훨씬 프리미엄 상품을 출시함에 따라 추가적인 많은 기능 요구사항이 있었고 제품 자체도 훨씬 더 다양한 콘텐츠 타입을 다루면서 더 많은 기능들이 탑재되었던 시기였다. ### 23년 9월~12월 - B2G? B2B? 일이 어려워지기 시작한 즈음, 아마 이 시기가 내가 완전히 새로운 국면을 맞이하는 시기였다. 일단 합이 정말 좋았던 PM 팀장님이 개인 사업으로 떠나게 되고 내가 팀장직을 대행하게되면서 이 즈음부터는 CTO 보다는 PM의 역할을 더 많이 하게되었다. 그리고 회사에서도 기존에 집중하던 B2C 외에 만들어진 플랫폼을 가지고 B2B, B2G 까지 확장하기 위해 여러 일을 벌이던 시기였는데 나도 비지니스 요구사항을 쫓아가기만 해도 정신이 없었다. 9월, 그리고 24년 1월 해서 회사에서는 전에 하지 않았던 외부 행사 (박람회) 등을 크게 기획하여 나가게 되었고 그때 보여줄 데모와 기능 개발을 하기 위해 이 시기부터는 기존 B2C 보다는 대부분 B2B, B2G 제품 개발에 시간을 쏟았다. 사실 B2C 에 비해서 난이도가 굉장히 높았는데 도대체 무엇을 기준으로 어떤 기능을 만들어야하는지 판단이 잘 서지 않았고 고객 목소리보다는 자칭 전문가라고 생각하는 회사 내부 경영진, 외부 전문가 집단, 개발팀 외 집단 들에게 계속 기능 우선순위가 휘둘리기 바빴다. 이 시기부터가 정말 어려워지는 시점이었지만 난이도의 문제라기 보다는 이러한 B2B, B2G 제품 만들기는 내가 10년 넘게 쌓아온 분야가 아니라서 사실 재미도 흥미도 느끼지 못했던게 가장 큰 문제였고 항상 모든 기능 구현이 숙제처럼 느껴졌다. 그래도 23년 정규직 전환을 하면서 진심을 다해 쏟아보자고 한 이상 묵묵히 앞으로 나아갔다. ### 24년 1월~8월 - B2G 살면서 교과서라는 것을 만들 줄 몰랐지만 정책 심사 가이드라인이 주어졌고 1월 박람회부터 8월 심사 제출까지 정말 모든걸 불태웠던 시기였다. 막바지에는 거의 집에도 가지 않았고 주말, 휴일에도 계속 일을 했다. 단순히 개발만 하고 끝낸게 아니라 중간에 연수 사업이니 시연이니 여러 사업적 요구사항이 주어져서 매번 계획했던 것보다 훨씬 빠듯한 일정으로 주어졌고 그 과정에서 어떻게든 우선순위를 조정하고 리소스를 확보해서 일을 끝내려고 했다. CTO 보다는 PMO 또는 PM에 가까운 역할에 집중했고 이 시기 같이 일하던 PM들도 나를 PM으로 인식하고 있었다. 결론적으로 PM은 정말 나랑은 안맞는 포지션이라는걸 뼈저리게 알게되었지만, 그래도 개발자라는 에고보다는 이 일을 완수해내는데 최선을 다했다. 기존 서비스를 기반으로 하였지만 뼈대만 남긴채 단기간에 새로운 플랫폼을 만들었고 그렇게 해서 더운지 느끼지도 못하고 여름이 지나가 버렸다. ### 그리고 지금까지 24년 9월부터 지금까지 이야기는 이전 기록에서 충분히 설명하였다. 관심있으면 참고. - [[지난 7개월의 기록 - 생각의 나열 (2024년 9월~2025년 3월 기록)]] ### 정리하면 - **초창기**: 레거시 플랫폼 리팩토링 및 안정화 (3명~13명) - **1기**: 신규 SA 플랫폼 런칭 (13명~20명) - **2기**: 플랫폼 고도화 (~25명) - **3기**: B2G 플랫폼 개발 (~35명) 아마 제일 재밌었던 시절을 꼽으라면 세명의 팀장 체제가 정리되고 23년 2월부터 이 체제가 변경되기 전까지 서비스 고도화에만 집중했던 23년 6월까지였다. 참 써놓고보니 그렇게 많은 일을 못한 것 같기도 하고 또 지난 시간을 곰곰히 곱씹어보면 무엇하나 쉬웠던 시기는 없었다. 코드를 작성하던 시기가 사실 더 즐거웠던 것도 맞고 사람들끼리 더 끈끈했다. 다만, 다른 분이 얘기했던 그랬던 기억은 나만 행복한 기억이고 이미 다들 잊으시고 최근의 기억만 주로 남으니 긴 시간동안 우리가 그래도 때로는 즐겁고 때로는 서로에게 끈끈했던 그 시기가 있었는데 이제는 더 이상 그때의 흔적을 서로 찾아보기는 힘들다는게 참 슬프다. 과거에 매여있자는 건 아니고, 마무리하고 떠나는 입장에서는 그래도 좋은 기억으로 남고 싶은 욕심 때문이겠지. 어쩌겠나, 지금까지 오기로 결정한 것도 나이고 순간순간 멈출수 있었음에도 계속 왔던 건 결국 내 선택이었으니. 어차피 박수받고 나가고자 했으면 이 자리에 왔었으면 안되었다. 여튼, 시간 순대로 두서없이 그냥 생각나는데로 했던 일들을 나열해보았다. 이제 하나하나 톺아보자. ## Outcome (조직과 제품) ### 데이터팀 데이터 팀이 제대로 구축이 된건 22년 8월에 현재 계신 두분이 합류하면서 부터다. Airflow 를 통한 기본적인 데이터 엔지니어링 부터 시작하여 통계학 스터디(특히, 앤디필드 책을 파이썬으로 다 재작성하였다.)부터 데이터 웨어하우스 구축, 분석 파이프라인 구축 등 실제 서비스 운영에 핵심으로 들어가는 데이터 프로덕트 개발을 주로 같이 진행을 했다. 처음 합류때 두분다 주니어였기에 매주 같이 스터디도 하고 개발 설계도 같이 하면서 진행을 했고 처음 1년간은 각자 개인 시간까지 투자했던 덕분인지 두 분다 굉장히 빠르게 성장하셨다. 특히, 한분은 최근 2년간 바쁜 회사생활 와중에도 대학원 생활까지 끝냈는데 로봇 같은 분이라고 다들 놀리시지만 여튼 학업과 업무를 병행해본 경험이 있는 나로썬 정말 존경을 표할 수 밖에 없다. 사실 데이터 팀에 집중해서 더 많은 것들을 할 수 있었는데 아쉽게도 23년 하반기부터 내가 디자인 팀 대행을 맡게 되면서부터 팀 매니지먼트에 상대적으로 많이 소홀하게 되었고 여러모로 나도 직전 회사에서 데이터 엔지니어링을 하다가 왔다보니 조금 더 계획했던 로드맵을 더 많이 실행하지 못한 아쉬움이 남는다. 그래도 다행인건 두분다 스스로들 잘 하시는 분들이라 현재 업무를 마무리하는 이 시점에 가장 믿음직스러운 팀원들이고 가장 감사한 팀원들이다. 그리고 두분은 어떻게 생각하실지 모르겠지만, 내 입장에서 가장 편한 분들이고 여전히 조금 더 챙겼으면 좋았을걸 이라는 아쉬움이 많이 남는 팀이다. 현재 회사의 주요 과제인 AI Agent 프로젝트를 진행하고 있는데 그토록 염원하던 something AI 엔지니어링을 드디어 하게 되었으니 두분 다 꼭 성과를 보셨으면 좋겠다. ### 디자인팀 디자인 팀을 맡게된건 당시에만 해도 전화위복이라고 생각했다. 기존 팀장님이 나갔고 새로운 PM 채용을 하는 중에 내가 팀장 대행을 맡았는데, 다시 기획 세부로 들어가서 디테일들을 볼 수 밖에 없었던 시기였다. 다만, 한가지 후회하는건 기회를 충분히 살리지 못했는데, 그 이유가 얼마있지 않아 또 새로운 PM을 채용했기 때문이다. 주니어 PM이었기에 내가 여전히 팀장 대행을 맡았는데, 이전 PM 팀장님의 역할의 상당수를 신규 PM 에게 요구했던 것이 가장 큰 실수였다. (PM 얘기는 PM 파트에서 하고..) 디자인팀에서 개발자 출신 팀장이 유효타가 날 수 있었던 건 다행히도 내 사업을 하면서 체득한 기획 역량이 뒷밤침 되어주었던 부분이 있었고 단순 UX/UI 디자인이 아니라 세부 정책까지 맡아서 설계하는 프로덕트 디자인을 추구하고 있었기에 특히 그런 영역에서 여러가지 역할을 가져갈 수 있었다. 물론 심미적이나 조형적인 부분에서 내가 줄 수 있는 피드백은 0에 가까웠고 그냥 무지성으로 색깔이 좀 마음에 안든다 라는 피드백이 최선이었다. 할줄은 몰라도 못나고 예쁜건 판단할 수 있으니. 디자인 팀을 맡으면서 좋았던 건 한명 한명과 프로덕트 기획 방향성과 피드백을 주고 받는 시간이었다. 개발자나 디자이너나 메이커는 무조건 자기 솔루션에 과도하게 몰입할 수 밖에 없고 누군가 한 명이 계속 바깥에서 끄집어내는 역할을 해줬어야하는데 프로젝트를 이끌어갈때는 그런 부분에서 제 역할을 잘 했다. 특히 다양한 과제를 동시에 진행해도 제품은 하나고 그 제품을 쓰는 고객도 정해져있는 상황에서는 피드백을 유효하게 주기가 어렵지 않았고 디자이너 분들도 수용을 잘해주었고 이해가 안되는 것들은 그래도 계속 서로 설득을 하려고 노력을 했었다. 너만 그렇게 생각하는거 아니냐고 할 수 있겠지만 워낙 요구사항이 탑다운으로 꽂히다보니까 중간 관리자인 내 입장에서 우선순위를 결정하기 위해서는 무조건 계속 why 를 고민하고 동기를 만들어야 했다. 누군가에게 그 설득이 충분치 않을 수 있으나 절대 설득의 과정을 무시하지 않았다고 장담한다. 다만, 최근, 즉 마지막에 와서는 제품도 다양하고 스쿼드도 다양하고 고객도 너무 다양하다보니 실제로 구현 범위에서의 피드백 말고는 내 피드백의 유효타가 점점 줄어드는 경험을 했었고 만약 올해 퇴사를 하지 않고 계속했다면 연초부터 생각했던 방향은 디자인 팀장 역할을 위임하고 다시 CTO 역할로 돌아가는 것이긴 했다. ### QA팀 QA팀은 처음 계셨던 PM 팀장님과 함께 초기 인력을 세팅했고 같이 QA 프로세스도 잡아나갔다. 사실 QA 팀은 처음 구축된 이후로 크게 성장을 만들지 못하였다. 아쉬움이 가장 크게 남는 팀인데, 데이터팀 디자인팀까지 팀장을 맡는 상황에서 QA 조직에 대한 방향성과 전문성을 가져가면서 팀을 이끌기엔 경험도 역량도 역부족이었다고 생각한다. 최후반부에는 QA팀에 계속 권한을 쥐어주고 더 잘할 수 있는 방향으로 의무감을 부여하는 방법으로 고민했었는데 아쉽게도 일하는 기간동안 제대로된 TC리뷰나 QA 자동화 프로세스 구축 등에는 거의 시간을 쏟지 못했다. 나는 경험이 부족하지만 팀에는 좋은 QA 팀과 일했던 사람들이 다수 있다. 팀 자체가 고민해서 앞으로 조금 더 조직에 기여하는 전문성 있는 팀으로 나아갔으면 하는 바램이다. ### 개발팀 (FE/BE) 처음 1년은 거의 개발팀과 같이 코드도 보고 직접 코드도 쓰고 대부분을 코드 리뷰하는데 시간을 썼는데, FE 팀은 처음부터 계셨던 FE 팀장님에게 위임을 하고 대부분 백엔드에 집중을 했다. 레거시, layered, functional, DDD, clean 등 내가 계속 초기에 셋업하려고 아젠다를 가져왔었는데 이 시기에 한가지 아쉬운 건 어떠한 설계 방법론도 100%라는 건 없기에 그레이 영역에 대한 판단 기준을 너무 모호하게 세우고 개발이 진행되었다는 점이다. 그게 아직도 프로덕션 코드에 많이 남아있는데, 내가 가져온 방법론이 지금 기준에서 또다시 레거시가 되더라도 당시에 조금 더 strict 하게 기준을 세우고 모호한 영역에 대해서 조금 더 밀도있게 코드 리뷰를 했어야했는데 나도 당시에는 많이 부족했었다. 당시 BE 팀장님이 오면서 코드 책임은 자연스럽게 위임을 했고 오히려 FE 주니어 개발자와 매주 시간을 내서 복잡하게 커플링된 컴포넌트를 풀어내는 프로젝트를 한다던가 반년 정도의 시간은 코드 작업은 대부분 데이터 엔지니어링 쪽이었다. 그래도 회사의 핵심 개발팀이기 때문에 주요 설계 사항이나 결정 사항들을 항상 팔로업하고, 또 신규 프로젝트 설계에도 적극 참여해서 설계 리뷰를 했었다. 코드 리뷰보다는 그 시점부터는 대부분 설계 리뷰와 기술 문서 리뷰를 주로 했었는데, 지금 돌이켜 생각해보면 코드 리뷰도 같이 계속 더 많이 챙겼어야했는데 하는 아쉬움이 있다. 물론 아예 코드를 안본건 아니었지만 많이 부족했다. 실제 설계대로 구현이 되는지는 코드의 결과로 검증해야하는데 프로젝트 초반 설계 리뷰에 치중된 탓인지 여하튼 내가 처음에 가져왔던 아젠다나 코드 구현의 본질이 많이 어긋나있었다는 것을 뒤늦게 많이 발견했었다. 항상 기술 스택부터 설계 방향까지 어느 시점에 언제로 돌아가서 다시 선택하면 어떻게 할까를 마무리하는 지금 이 시점에도 계속 고민했는데, 특히 B2G 를 하면서 플랫폼을 일부 재구축을 할 수 있는 시점에 조금 더 과감하게 기존 구조를 깨부수지 못한 부분이 아쉬움으로 많이 다가온다. 촉박한 개발 일정을 맞추려고 타협을 보았던 건데, 일종의 온고지신(?) 전략으로 접근했으나 결론적으로 지금 시점에는 후회하는 선택이 되었다. 후임자와 남은 개발자들 그리고 뒤에 들어오는 훌륭한 인재들이 꼭 현재 구조의 본질적인 문제를 해소하고 변경에 강한 소프트웨어, 핵심 로직에만 집중할 수 있는 효율적인 서비스로 개선했으면 한다. ### PM 그냥 아쉬움만 남는다. 나는 24년 한해동안은 CTO가 아니라 PM 이었는데, PM으로서 대실패를 했다. 채용한 PM들의 장단점을 살려서 운용하지도 못했고 제대로 일을 위임하지고 그리고 제대로 서로 커뮤니케이션이나 공유도 되지 않았다. 가장 많은 시간을 보낸 팀이고 사람들인데.. 결론적으로 잘하지 못하였다. 같이 해준 PM들에게도 죄송하고 이 실패로 한동안 마음이 심란하기도 하였다. 몇가지 원인이 있는데, 가장 큰 원인은 내가 PM 리드 였고 내가 PM 롤모델이었다는 것이다. 그런데 내가 아무리 개발을 내려놓고 PM을 한다한들, 기술 베이스와 설계를 기반으로 제품을 리뷰하고 기획하는 역량은 오로지 나만의 것이다. 이건 내가 잘할 수 있는 영역인데, 처음에는 이 역할을 강요했던게 큰 패착이라고 생각한다. 그런데 PM은 일의 요구사항을 듣는 순간 내가 판단할 수 있나 없나를 메타인지 한 후에 내가 판단할 수 있는 것이면 빠르게 내가 판단하고 내가 판단할 수 없다면 빠르게 이해관계자들을 적시에 회의실에 앉혀서 일의 진행에 막힘이 없게 해야한다. 여기서 PM이 할 수 없는 것을 할 수 있다고 생각하고 시간을 지체하는 순간, 타이밍이 어긋나고 모든 실무자들이 불행해지는 방향으로 흘러가는 것이다. 그리고 인하우스 프로덕트에서 PM은 조금 더 빠르게 고객의 목소리를 딜리버리하는 역할, 문제의 본질을 판단하는 능력 그리고 그걸 메이커들과 협의하여 어떻게 고객만족을 하느냐에 그 역할이 있다. 타이밍도 나빴던 건 1년간 진행했던 B2G 프로덕트는 사실 그러한 경험을 전혀 할 수 없었던 프로젝트였고 해야하는 과제가 주어지면 그 과제의 범위를 최대한 최소화해서 최소 조건에 만족하게 만드는게 대부분 요구되는 역할이었다. 또는 사업지원서 같은 문서 작업을 하던가. 그래도 더 잘할 수 있었을 거라 생각한다. 그럼에도 불구하고 더 좋은 프로덕트 환경에서 일했어야 한다. 최소한 PM에 있어서만큼은 난 A급이 아니기 때문에 B2C 또는 B2B 인하우스 프로덕트에서 이 분들과 만나서 일했다면 조금 더 잘할 수 있지 않았을까, 조금 더 위임할 수 있지 않았을까 생각한다. 정말 이런 환경에서는 PM은 그냥 이리저리 치이면서 피만 빨리는 포지션인 것도 같다. 단 한번의 제대로된 칭찬도 없이 매번 잔소리만 했던 팀이다. 죄송스럽고 각자가 선택한 다음 환경에서는 두분다 조금 더 본인답게 일하는 환경에서 일하시길. ### 조직 구조의 변화 기능팀으로 시작해서 마지막에는 어설프지만 목적 조직, 스쿼드 체제로 가져온건 다행이라고 생각한다. 사실 주도적으로 조직을 변화시켰다기 보다는 변화하는 외부사업에 휘둘리면서 하나의 큰 본부가 기능팀 단위로 매 스프린트마다 맥락이 전혀 다른 일들을 하고 있는게 반복되었기 때문에 그 연속성을 가지고자 사람들을 조금 더 집중시키고자 생존형(?) 스쿼드 체제가 되었다. 그런데 PM 수도 부족하고 사업의 사이즈도 불균형이 심하고 맥락이 다른데(사업도 다르고 고객도 다른데) 같은 플랫폼 전략(같은 코드베이스, 같은 브랜치)을 가져가다보니 배포 때마다 항상 사고가 났다. 개선을 하려면 사업을 버리던가, 그게 안된다면 사업 단위로 코드베이스를 나누고 모든 것에 독립적으로 가져가야 스쿼드들도 속도를 더 잘낼 수 있을 것 같은데 이 부분에 대해서는 경영진과 내 생각이 달라 더 코멘트할 내용은 없다. 스쿼드마다 코드베이스를 분리하고, 스쿼드마다 수석 개발자를 두고, 스쿼드마다 담당 PM이 존재하고 (특히 B2G 같은 사업은 워낙 이해관계자가 얽혀있기 때문에 PM이 둘 이상은 필요하다고 생각한다.) 아예 조직구조도 스쿼드를 기준으로 확 분리시켰다면 인원이 몇명이든 조금 더 기민한 체제를 운영할 수 있었을까? 리소스가 없는데 리소스가 더 있었으면 잘했을 거라는 건 사실 회고에 적기엔 좀 치사한 내용인 것 같고, 사실 스쿼드 체제로 가면서 가장 바랬던 건 Back to the Basic 이었다. 내가 처음 합류해서 3명과 같이 조직 문화를 만들어가고 기민하게 팀을 이끌어갔듯, 다시 소규모 스쿼드가 되면서 그러한 문화를 만들어가는게 목표였는데.. 생각보다 그런 부분에서 현재를 비추어봤을때 잘되었다고 보기는 어렵다. 다년간 기능팀에 익숙해져서 그런걸까. 그저 작년에 B2G 프로젝트 때문에 사람들이 지쳐서 그런걸까. 그럼에도 불구하고 내가 했어야하는 정말 중요한 한가지는 사람들이랑 더 자주 1 on 1 하고 더 자주 얘기하는 것이었다. 1월에 부랴부랴 사람들이랑 얘기를 나눴을때는 너무 그 타이밍이 늦었다는 생각이 컸다. 누군가 나에게 내가 관리자인데 뭘 해야할지 모르겠다고 질문하면 부지런하게 사람들이랑 1 on 1 하는 것이 최선이라고 조언해줄 것이다. 또한 명확한 보고 체계의 부재가 가장 큰 문제 중 하나다. (위든, 아래든) 스쿼드 구조를 떠나서 팀장들이나 PM들이나 또는 시니어들에게도 직접적으로 정리하여 보고받는 체계를 더 빨리 만들었어야 했다. "스타트업" 그리고 각자 모두가 움직이는 조직에서 일했던 경험으로 "보고"라는 건 사실 금기시되는 용어로 여기며 살았는데 결국 큰 회사에는 보고 체계도 직급 체계도 중요하고 위임할 수 있는 사람에게 잘 위임하는 정말 필수적인 일이다. 이걸 너무 늦게 깨달은 것도 문제 중 하나라고 생각한다. 리더십은 아래로도 향하지만 위로도 향한다. 단순히 조직 구조를 바꾼다고 일이 되는게 아니다. 상위 사업구조와 하위 조직문화가 모두 뒷밤침 되어줄때 조직 구조도 제 기능을 다하는 것이다. ### 조직 문화 조직이 초기 20명으로 향하던 시점까지가 아마 내 영향력이 가장 컸던 시점이었고 체크인 미팅이나 랜덤밥메이트나 스프린트 회고 등 여러 장치들이 유효했었다. 온보딩 문서도 직접 작성하였고 내가 조직 문화에서 가장 중요시하는 유머와 서로에 대한 호기심을 잃지 않는 그런 장치들이 잘 동작했었다. 그렇게 동작하던 것들이 작년 B2G 프로젝트를 하면서 사람들의 동기 상실, 회사의 소통 부재 등이 겹치면서 무너져 내렸고, 나도 이러한 디테일들을 하나둘씩 놓기 시작하니 그나마도 동작하던 장치들이 마지막에 와서는 그냥 와르르 무너졌다. 더이상 이렇게 유지되는건 힘들다는 판단에 회사 EX팀에 의뢰를 하였고 이제 회사가 다시 앞으로 나아가야할 때 어쩌면 팀이 가진 정체성이나 문화는 다시 세팅되어야하는 시점인지도 모르겠다. 내가 만들어온 문화가 이제 더이상 동작하지 않는다면 이제 과감하게 벗겨내고 새로운 문화를 다시 셋업해나갔으면 한다. ### 제품 제품을 만들면서 항상 구조 중심, 설계 중심, 솔루션 중심으로 제품을 기획했었는데 때론 확장성을 고려하고 구조 중심의 사고가 많은 도움이 되었으나 결론적으로 후회하는 건 고객 유즈 케이스를 놓쳤던 건들이다. 단적인 예로 현재 콘텐츠 시스템의 커리큘럼은 그 커리큘럼이 완성된 이후 쓰여진다는 것을 전제로 구조가 설계되었는데, 실제 서비스에서는 완성된 커리큘럼보다는 매번 새로 만들고 쓰면서 업데이트되는 커리큘럼이 대부분이고 심지어 고객들도 그러한 케이스에서 돈을 지불한다는 것이다. 초기 1년동안 기존 레거시를 따라잡아야 한다는 생각과 뇌피셜로 생각한 구조적 완결성에만 집중한 결과, 당시에 아무리 확장성을 고려했다 한들 너무나 변경에 취약한 구조를 가지게 되었고 제품 설계 자체가 선천적으로 변경에 취약하다보니 다양한 유즈케이스와 엣지케이스가 드러날수록 계속해서 개발 비용이 기하급수적으로 늘어났다. 마치 객체지향 class에서 getter 와 setter 를 만들면 여기저기서 다 일반화해서 쓸 수 있다는 생각으로 만들어서 썼다가 기능 요구사항이 계속 늘어나면서 getter, setter 에 if 문이 덕지덕지 붙게되고 잘못 건드려서 다른 모든 영역에 사이드 이펙트를 일으키는 것처럼 DDD 나 최근 설계 트렌드와는 다르게 근본적인 모델 설계를 너무 strict 하게 가져갔고 그렇게 정해진 구조는 일종의 불변의 법칙이 되어서 추후 모든 변경사항은 이걸 건드리지 않고 변경을 하거나 이걸 활용해서 변경을 해야했기에 필연적으로 개발 비용이 늘어날 수 밖에 없는 구조가 되었다. 니가 CTO 였는데 니가 더 잘했으면 되는거 아니냐고? 하하, 맞다. 그래서 후회한다고 썼다. 초기에 실무 부서들이 정확히 무얼하는지 어떻게 서비스를 운영하는지를 더 많이 인터뷰하고 실제 업무도 해보고 이해를 했어야했는데 레거시를 대신할 신규 플랫폼에 집중해야 했기에, 무조건 새로운 플랫폼이 기능도 디자인도 좋다는 뇌피셜에 빠져있었기에 실제 고객 사이드에서 일어나는 유즈케이스를 깊게 들여다보지 못한채, 고립된 상태로 개발을 했다. 사실 22년 런칭 이후에 퇴사를 하지 않은 것도 이것을 만회 또는 고객 유즈케이스에서 개발하고자 하는 니즈가 강했었다. 사실 개발 스택을 뭘 쓸까 보다 이 부분이 마지막까지도 크게 아쉬운 부분이다. 개발자가 좋은 코드를 짜려면 고객을 알아야한다. 단순히 PM이나 디자이너가 알려주는 내용, 남이 알려주는 내용만으로 코드를 짠다면 결국 빠른 시일 내에 내가 짠 코드를 보고 탓하고 있을 것이다. 단순히 코드 이슈라면 리팩토링이라도 하겠지만, 디비 스키마부터 이미 쌓여버린 프로덕션 데이터들, 관계 테이블의 구조들을 다시 뒤집고 마이그레이션하고 개발하는건 사실 서비스가 궤도에 올라서 또다른 비지니스 요구사항으로 달려가는 시점에는 불가능에 가깝다. 계속 거대한 혹을 달고 가는 것과 다름없다. 기술기술기술 하면서 에고를 가지는 개발자들이 착각하지 말아야할 것은 우리의 가치는 결국 고객의 가치 실현으로 연결될때 그 의미가 빛을 발한다는 것이다. 내가 돈을 받는데, 그게 고객 가치랑 연결이 되지 않는다면 사실 그건 시한부 개발자나 다름없다고 생각한다. 어쩌고저쩌고 돌고돌아 고객 중심. 결국은 누군가 쓰는 제품을 만드는 것을 명심 또 명심하자. ## 마무리하며 내가 결국 만든 건 조직과 제품인데, 조직 관점에서 가져가야하는 단 한가지 액션 아이템을 뽑자면 무조건 더 자주 1 on 1 하자. 제일 많이 아쉬우면서 그때 했었으면 조금 다를 수 있었는데 하는 것들이 마지막에는 훨씬 더 뼈저리게 다가왔다. 제품 관점에서는 바로 직전에 말했듯이 고객 중심. 구조고 설계고 뭣이 중헌디. 고객 중심이 최우선이어야 한다. 착각하지 말자. 절대 고객 얘기를 있는 그대로 듣기만 하라는게 절대 아니다. 오히려 거기서 숨겨져있는 요구사항과 니즈, 기회를 포착하는게 진짜 실력이라고 생각한다. (그리고 그걸 코드로 가져올 수 있는 개발자가 되자.) 앞서 나의 다른 글들이 그렇듯 4년간 무슨 일을 했는지 간략히(?) 돌아보았다. 생각나는데로 써재낀(?) 글이라 횡설수설 말그대로 사고의 흐름을 그대로 옮겨담았다. 글을 쓰면서 새로운 시작을 위해 다 털어버리자는 마음도 있었고 과거에 연연하지 말고 여기에 묻어버리자는 마음도 동시에 들었다. 기억은 희미해질 것이고 여기에 있는 글을 읽으면서 아 그때 그랬지 라고 생각할 것이다. 사실 회사나 다른 아쉬움들도 현재 많은 상태다. 하지만 공개된 공간이다보니 그런 것보다는 내 기록과 내가 행동으로 이끌어 낼 수 있는 일들에 집중하여 글을 썼다. 그러한 아쉬움도 어느새 다 희미해지리라. 다른 버전의 솔직한 생각들은 현재가 한참 지난 어느 시점에 내가 여전히 그럴 의지와 기억을 가지고 있다면, 다시 글로 옮겨보겠다. 사실 난 20대 대부분을 내 사업을 하면서 커리어를 채웠으니 경력이 13년이 된 것 치곤 직장인으로는 처음으로 이렇게 오래 회사에 있어보았다. 그것도 그냥 말단 직원이 아니고 CTO라는 직함의 중간 관리자로. 20대부터 30대가 넘어서까지 계속 대표님으로 불리다가 이제야 이사라고 불리는게 좀 적응이 된 것 같은데 시간이 참 무섭다. 회사가 급격하게 성장하는 모습도 어려운 모습도 모두 보면서 때로는 내가 경영자라면 이 상황에서 어떤 판단을 내렸을까 항상 멘탈 시뮬레이션을 했다. 내가 누구보다 더 잘났다가 아니라 나는 나만의 스타일이 있으니까 내 방식에서의 최선을 항상 고민했고 그러면서 경영자의 입장도 항상 같이 이해하려고 노력했다. R&D본부가 3명에서 30명이 될때, 회사는 100명에서 500명이 되었으니 난이도가 당연히 높은 일이다. 상사를 뒤에서 씹어대거나 법인카드로 맛난 것도 먹었고 월급의 소중함도 깨달았다. 경영자로만 있었을때는 몰랐던 많은 것들을 알게 되었다. 조금 더 현실주의자가 되었고 중간 관리자로서 항상 책임을 다하려고 했으나 생각보다 그것도 쉽지 않았다. 팀원들에게는 "나도 너네들이랑 같은 입장이야", "내가 책임지고 결정할게" 이 상반된 문장들을 항상 가슴속에 품고 있었고 어떨때는 위든 아래든 모두가 미울때도, 때론 모두에게 한없이 감사할때도 있었다. 마지막의 마지막이 되어서야 아쉬운 마음이 제일 크지만 참 이 시간동안 많은 걸 느끼고 배우고 얻어가는 시간이었다. 어느 시점엔가 회사 일이 너무 힘들고 스트레스가 심해져서 (무슨 일 때문인지는 기억이 안나고) 아내 품(결혼 전이다.)에 안겨서 엉엉 울었던 적도 있다. 그리고 어느 시점에는 불면증(나는 진짜 어디든 누우면 바로 자는 사람이다.)과 잠꼬대로 욕을 하지를 않나 새벽에 회사 일 때문에 잠에 깨서 하룻밤을 지샌적도 종종 있었다. 내가 내 사업했을때보다 더 스트레스를 받았다. 마지막에서야 사람들에게 힘든 기색을 보이기는 했지만 그래도 드러내기 좋아하는 나 치고는 포커 페이스하면서 여기까지 잘 왔다. 생각을 깊게 하면 모든 것이 다 아쉽고 후회될 것이다. 이제, 4년간의 치열했던 기억은 여기 묻어두고 좋은 기억과 배움만 손에 쥐고 새로운 출발을 해보자. >What we call the beginning is often the end. >우리가 시작이라 부르는 것은 종종 끝이다. >And to make an end is to make a beginning. >그리고 끝을 만드는 것은 시작을 만드는 것이다. >The end is where we start from. >끝은 우리가 출발하는 곳이다. ― T.S. 엘리엇 --- 정리도 되지 않고 뒤죽박죽인 제 4년간의 발자취를 마지막까지 읽어주신 모든 분들께 감사의 말씀을 드립니다. 당분간 쉼을 가지고 새로운 소식으로 돌아오겠습니다.