스타트업에 테크리도로 합류한지 1년이 조금 지났습니다. 그곳에서 정말 멋진 사람들을 만났고 저에게 처음으로 대용량 트래픽에 대한 경험과 AI 프로젝트에 대한 경험을 할 수 있게 해주었습니다. 하지만 그것과는 별개로 처음으로 8명으로 이루어진 팀의 '리더' 역할을 소화하는 것과 그중 6명의 개발자들에게 '테크' 가이드 라인을 주는것은 정말 많은 고민과 땀으로 점철된 시간들이었습니다.
저의 지난 1년동안 기억에 남는 주요 이벤트 위주로 저의 고민과 행동을 작성해보았습니다. 테크리더라는 직무에 도전하시는 분, 그리고 새로운 테크리더를 맞이하시는 분들에게 조금이라도 도움이 되었으면 하는 마음으로 글을 적습니다.
어떻게 테크리더라는 직무를 하게 되었나?
제 경력은 조금 특이합니다.
경제학과 4학년 1학기에 나름 데이터를 많이 다뤄봤다는 생각에 앱 서비스 회사에서 DA로 1년 9개월을 일했습니다.
다시 학교로 돌아와 공부를 마무리하고 같이 일했던 프로덕트팀의 열정에 감화되어 개발자의 길을 걷기로 마음 먹었습니다.
42Seoul 프로그램을 1년간 진행하면서 전 직장 사람들과 한 사이드 프로젝트가 잘 풀려서 프롭 테크 회사에 개발자로 들어갑니다. 그곳에서 3년이 조금 넘는 시간동안 개발자로 일하면서 팀을 새롭게 꾸리고, Java, Python 등을 이용해 서비스들을 만들었습니다.
이런 경력을 리멤버에 올렸는데 "테크리더" 직무에 잘 어울릴것 같고 커피챗을 해보자는 연락이 왔습니다.
커피챗을 해보니 그곳에서는 내가 더 주도적으로 일할 수 있을것 같다는 확신이 들었고, 추가 채용 과정을 진행하고 합격이 되었습니다.
물 흐르듯이 일이 진행됐는데 제가 맡게될 팀 규모가 8명이고 그중에 개발자가 6명이라는 이야기를 들으니 덜컥 겁이 났습니다.
'내가 빌딩한 팀도 아니고 이미 만들어진 팀, 그것도 8명 팀의 리더 역할을 하면서 6명 개발자의 선임 개발자 노릇도 해야하다니...'
그래서 템플스테이를 가기로 결정했습니다(지금 와서 생각하면 쌩뚱맞지만). 도봉산에 위치한 한 절이 역사가 깊고 스님과의 대담 시간도 있다고 하니 나의 고민을 스님에게 상담하면 뾰족한 해법이 나올것만 같았습니다. 지금 생각해보면 어떤 대화를 했는지 기억이 안날 정도로 스님과의 대담은 실망스러웠습니다. 단지 실망스러웠다는 기억만 남아있습니다. 역시 세상은 혼자 살아가야 하는 걸까요, 그래서 저 스스로 준비를 시작했습니다.
테크리더란 무엇인가?
우선 테크리더란 무엇인지 찾아야 했습니다. 테크리더의 정의를 찾는 중에 아래의 2개 책과 하나의 리포트의 도움을 받았습니다.
두 권의 책은 어떻게 기술임원(테크리더, 스태프 엔지니어)가 되는지, 그리고 그 과정에서 겪게될 일들과 대응전략, 마지막으로 퇴사계획까지 알려주는 세세한 가이드라인 같은 책이었습니다. 모든 가이드라인이 그렇듯 획일적으로 적용할 수 없겠지만 '내가 이런일을 하게 되게쑥나' 하는 시뮬레이션을 할때 도움이 되는 책입니다.
그리고 마지막 리포트는 IT가 비즈니스로 태동하던 2002년에 작성된 리포트인데 짧은 리포트인데, 20여년의 세월이 지나고 나온 두 권의 책과는 다르게 날것 그대로의 개념을 다룬다는 점에서 더 직관적으로 다가왔습니다.
이상의 자료를 찾아보고 제가 내린 결론은 다음과 같습니다. "테크리더는 작은 CTO 다"
무한 참조를 만들고자하는게 아닙니다. 2025년 당시에는 "CTO란 무엇인가?" 라는 질문이 "테크리더란 무엇인가?"에 대한 질문보다 오래되었고 더 많은 연구가 진행되었으며 제가 나름대로 찾아본 결과 둘은 권한과 책임 다루는 조직의 크기만 다르지 기본적인 속성은 일치했기 때문에 CTO 의 역할에 빗어대 테크리더를 설명하고자 합니다.
아래는 처음 개념을 잡을때 도움이 되었던 도식과 표입니다.
X축 (제품/서비스 내 정보 자산의 비중)
조직이 제공하는 제품과 서비스에서 실물 자산 대비 '정보(소프트웨어, 데이터, 디지털 서비스 등 비실물 요소)'가 차지하는 비중을 의미합니다. 오른쪽으로 갈수록 정보 자체가 핵심 상품인 조직(예: IT/SaaS/플랫폼)에 가깝고, 왼쪽으로 갈수록 실물 기반의 전통 제조업/원자재 기업에 가깝습니다.
Y축 (비즈니스 환경의 변화 속도 및 강도)
대내외적 압력(시장 경쟁, 규제, M&A, 기술 패러다임 전환 등)으로 인해 조직이 겪는 비즈니스 변화의 크기와 속도를 의미합니다. 위쪽으로 갈수록 급격한 변화와 혁신을 요구받는 환경에 노출되어 있음을 의미합니다.
아래는 비즈니스가 위치한 사분면에 따라 요구되는 CTO 의 역할(모델)과 그 역할이 갖춰야하는 강점을 나타냅니다.
그리고 저는 깨달았습니다. 새롭게 합류할 곳은 SaaS 비즈니스를 하는 곳이었고, 역할 사분면에서 보면 저에게 "Visionary and Operations Manager" 가 요구될 것이라고요. 정말 많은 강점을 HIGH로 요구하고 있으며 저는 충분하지 않다는 생각을 했습니다. 하지만 어쩌겠습니까 이미 입사일자는 정해졌는데, 우선 제가 어떤 역할을 해야할지 대략적인 윤곽이라도 얻었다는게 성과라고 생각했습니다.
입사 후 첫 CEO와 미팅을 하다.
입사하고 일주일 뒤에 CEO와의 면담 시간이 잡혔습니다. 저는 즉시 그 메시지를 파악할 수 있었죠.
"CEO에게 내가 가진 비전을 보여줄 수 있는 시간이 일주일 주어진거구나"
그리고 책에서 읽은 엔지니어링 전략 문서가 떠올랐습니다.
"Visionary Operations Manager로서 기깔나는 엔진어링 전략 문서를 가져가야겠다"
일주일이라는 시간동안 우리 프로덕트의 비즈니스 환경과 코드베이스 그리고 기술인력들의 특성을 파악하기 위한 시간을 보내고자 했습니다. 이를 통해 기술적으로 나아갈 방향 그리고 인력운영 방안을 만들어보고자 했지요. 하지만 끝대로 되지 않았습니다.
제가 맡은 프로덕트는 회사에서 처음으로 만든 SaaS 였습니다. 회사 매출의 80%를 담당하는 프로덕트이지만 역사가 오래됐고 그만큼 담당자가 변경된 이력도 많은 프로덕트였죠. 그래서 그런지 많은 문제를 안고 있는 코드였습니다. "이 문제를 어떻게 해결하지?" 이 고민으로 시스템 다이어그램을 그리고 지우고, 리팩터링 계획을 세웠다가 지웠다가 매일 새벽까지 고민하는 시간이 반복되었습니다.
경보가 울립니다. 애석하게도 Observability 를 잘 구축해둬서 문제가 생기면 전사 모든 인원이 알 수 있었습니다. 제가 맡은 프로덕트의 버그입니다. CEO가 저를 태그합니다. "버그 원인 파악해서 대응방안 공유 부탁드립니다." 지금와서 생각하면 CEO는 이런 상황이 너무 익숙해서 담담하게 말한거였는데 저는 식은땀이 났었습니다. CEO가 직접 태그하지 않더라도 하루에도 몇건이나 CS팀을 통해 버그리포트가 들어오고 있었습니다. 어떤 맥락에서 발생하는 버그인지 파악하기 위해 매일매일 데이터독을 뒤져보았습니다.
팀원 모두와 커피챗을 하고 한명 한명 따로 만나서 심층 면담을 하면서 기술인력이 겪는 고충을 파악했습니다. 장기간 리더십이 부재한 상황을 겪었던 팀원들은 불만이 많이 쌓여있었습니다. 그 와중에 팀원 한명한명이 오너십을 발휘해서 어떻게든 프로덕트를 끌어오고 있었지만 스트레스가 심한 상황이라는게 명확했죠. 웃음끼 하나없는 팀 분위기에 농담하나 던지기도 쉽지 않았습니다.
화끈한 일주일을 겪은 후 저는 깨달았습니다. "아 내가 당장 집중해야할 역할이 Visionary 뭐시기, 엔지니어링 전략 문서 그딴게 아니라 급한 불을 끄는거구나" 스스로 겪은 문제를 분류하고 사례를 정리하고 해결 우선순위를 나눠서 시각화했습니다.
선배와 지인들에게 회사의 문제를 이야기하니 '그걸 굳이 왜 너가 해결하려고 하냐', '아직 개발 실무를 더 해도 좋다. 이직도 좋은 옵션이다.' 등의 반응이 많았습니다. 그런데 저는 제가 선택한 일의 책임을 지지 않고서는 성장할 수 없다고 믿기에 오히려 이 문제를 더 해결하고 싶어졌습니다.
드디어 CEO와의 미팅 시간이 다가왔습니다. 이런저런 이야기할 것도 없이 저는 처음부터 본론을 꺼냈습니다.
"지금 우리팀은 심각한 문제가 있습니다. 이 상황에서 고객가치를 고민하는건 사치입니다."
문제 사례와 이 문제의 심각도, 그리고 개별 사건으로 드러나는 문제들이 어떻게 연관되어 있는지 시각화한 자료를 꺼냈습니다. 그리고 제 나름대로 고민한 해결책도 제시했죠.
CEO도 진솔하게 이야기했습니다.
"이런 문제가 있다는건 알고 있었습니다. 그래서 테크리더가 필요하다고 생각했고 기대한대로 문제를 잘 파악해주신것 같습니다.. 하지만 우리 비즈니스가 위치한 시장은 극도로 경쟁이 치열한 시장이고 우리는 이미 리팩터링으로 반년의 시간을 보냈습니다. 더 이상 고객가치 향상을 미루는건 비즈니스 자체가 위험해질 수 있습니다. 저는 파트를 나눠서 Feature 개발과 '안정성'과 '효율성' 프로젝트를 동시에 진행하는 것을 제안드립니다."
CEO의 의지는 단호했습니다.
경쟁이 치열한 시장에서 이미 6개월을 리팩터링에 베팅했다는 것 자체가 CEO이 문제를 심각하게 받아들이고 해결하고 싶어했다는 좋은 시그널이었습니다. 하지만 동시에 실패한 리팩터링 프로젝트로 부정적인 경험을 겪은 CEO에게 다시 리팩터링에 전력투구하자고 설득하기란 쉽지 않다는 것을 깨달았고, 저도 아직 그정도로 자신이 없었습니다. 아직 문제를 다 파악한게 아니었거든요.
"그럼 제가 '안정성', '효율성' 차원에서 문제를 다시 정의하고 해결하기 위한 로드맵을 가져오겠습니다."
이렇게 첫번째 CEO 미팅이 마무리 되었습니다. 좋은 성과가 많이 있었습니다. CEO가 인지하는 문제가 제가 인지하는 문제가 같다는 것, 그리고 이 문제를 해결하기 하고자하는 의지가 정말 충만하다는 것이었습니다. 그리고 '안정성' 과 '효율성' 이라는 키워드를 얻은것이 큰 성과였습니다.
첫 회사의 CEO에게 추천받아서 읽었던 로지컬 씽킹이라는 책을 통해 배운 MECE 개념을 활용해 문제와 액션아이템을 다시 정의했습니다.
안정성,효율성을 프로덕트와 조직의 문제로 나누고 그 이하로 해결과제와 해결 방법을 나열했습니다.
그리고 기술적으로 풀어낼 수 있는 문제는 문제 해결 임팩트를 우선순위로 삼아 타임라인에 나열했습니다.
조직적인 문제는 현재 실무 Workflow 를 시각화하고 문제가 발생하는 구간을 시각화하고 해결법을 제시했습니다. 현재 상황이 비정상적이라는 것을 인정하고, 그렇기에 제가 제시하는 해결책도 비정상적이었죠.
일주일 뒤 다시 CEO미팅을 진행했고, 모든 계획을 컨펌받을 수 있었습니다.
평범하게는 안된다, 헌신과 결단이 필요하다.
"빨리 가려면 혼자 가고, 멀리 가려면 함께 가라", "리더는 혼자 일하는 사람이 아니라 다른 사람과 함께 성과를 만들어내는 사람" 익히 알고 있는 말이고, 테크리더 직무를 시작하기에 앞서 팀원들이 일을 잘할 수 있는 환경을 만드는게 가장 효율이 좋은 일이라는것을 알고 있습니다. 하지만 리더는 필요하다면 이러한 상식적인 원칙을 깨트리는 결정을 할 수 있어야합니다.
팀원 모두가 함께 가는 그림이 아름답지만 지금 당장 프로덕트가 겪는 문제를 해결하기 정석적인 프로세스를 진행하는 것은 적절하지 않다고 생각했습니다. 그 이유는 단순합니다. 다음의 프로세스를 보세요. 문제 원인을 파악하고, 최적의 옵션을 찾고, 요구사항 문서를 작성하고,이해시키기 위해 모든 제반사항과 최적화 및 해결 방법을 설명하고, 실행결과를 기다리고, 리뷰 및 QA 하고, 배포한다.
그냥 단순히 너무 느립니다.
팀원들에게는 고객가치 향상이라는 임무가 있다는것, 그리고 현재 프로덕트가 겪는 비정상적인 버그와 CS는 시급한 사항입니다. 그래서 이 문제해결 프로젝트의 상당 부분을 저 혼자 진행하기로 결정했습니다. 그래서 9~6 업무시간에는 팀원들에게 업무 가이드라인을 주고 코드 리뷰, 회의를 하면서 시간을 보내고 문제 해결을 위한 리서치와 실행은 오후나 새벽 그리고 주말에 이뤄졌습니다.
입사 3주차에 모놀리식으로 단일 서버로 운영되던 서버를 3개의 서비스로 분리했고, 5주차에는 실제 가장 많은 문제를 일으키던 성능 문제를 해결할 수 있었습니다. 8주차에는 클라우드 비용의 40%를 절감하는 쾌거를 이루기도 했습니다. 실제 문제를 해결하면서 이 과정을 문서화해서 팀 뿐만 아니라 개발조직 전체에 공유해서 조직 전체에 성능 최적화를 이루어냈습니다.
대신 휴식이 없는 일정으로 인해 극도의 스트레스에 시달리고 건강도 악화되었습니다. 그리고 팀원들의 불만도 높아졌습니다. 비동기적으로 문제, 이론, 해결방법에 대한 내용을 문서와 발표로 공유하지만 "왜 혼자 일하냐", "우리가 모르는 배포사항이 주말이나 새벽에 왜 반영되냐" 등 당연히 나올 수 있는 이야기였습니다.
스트레스, 건강악화, 팀원들의 불만 모두 예상된 결과였고 제가 감수하기로한 것들이었습니다. 급한 불을 끈 후에는 CEO에게 상황을 솔직히 공유하고 쉼표를 찍었습니다. 그리고 저혼자 내달리느라 놓쳤던 팀원들과의 소통과 신뢰 회복에 온전히 시간을 쏟았습니다. 조직을 다시 정상 궤도로 올려 놓으려고 노력했습니다. 하지만 첫 인상부터 잘못 박혀서 그런걸까요? 신뢰를 회복하지 못한 팀원도 존재했습니다. 아쉽게도 그 팀원과는 관계가 계속 틀어졌고 결국 다른 길을 갈 수 밖에 없었습니다.
비정상적인 문제는 정상적인 방법으로 해결할 수 없습니다. 진정 해결할 가치가 있는 문제라면 다른 요소들을 잠시 희생해서라도 반드시 풀어내야만 합니다. 경영 전략 중에는 '비치헤드 전략(Beachhead Strategy)'이 있습니다. 적진에 상륙할 때 해안 교두보를 먼저 확보하듯, 가장 뚫기 어렵지만 확실한 거점 하나에 모든 자원을 쏟아부어 우위를 선점하고, 이를 발판 삼아 점차 영역을 확장하는 진입 전략입니다. 무너져가는 서버 아키텍처와 성능 문제는 제가 모든 개인 시간과 체력을 쏟아부어서라도 반드시 확보해야 했던 우리의 '비치헤드'였습니다. 비록 그 과정에서 일부 희생이 따랏지만, 이 단단한 교두보가 확보되었기에 이제 우리는 정상적인 프로세스 위에서 더 쾌적하게, 그리고 함께 멀리 갈 수 있게 되었습니다.
F45에서 긍정적 피드백의 힘을 배우다.
팀의 업무를 챙기며 하루 종일 아키텍처를 고민하고 코드 리뷰를 하는 일상이 반복되었습니다. 캘린더에 30분이라도 빈 시간이 생기면 전화 부스 같은 곳에 숨어 겨우 숨을 돌렸죠. 이런 강행군 속에서 악화된 건강을 회복하기 위해, 예전부터 추천받았던 F45(그룹 트레이닝)에 과감히 등록했습니다.
새로운 방식의 운동 자체도 효과적이었지만, 제 시선을 사로잡은 것은 F45 코치들이 사람들의 사기를 북돋는 방식이었습니다. 그들은 사람들이 포기하려 할 때 다가가 파이팅을 외쳤고, 끝내 세션을 마치게 만들었습니다. 체력이 바닥나 있던 저에게는 무리하지 않도록 조금 낮은 강도의 동작을 알려주며 어떻게든 끝까지 함께 갈 수 있게 이끌어 주었습니다.
그 모습을 보며 저의 리더십을 되돌아보게 되었습니다. 저는 팀원들에게 높은 기준을 제시하고, 부족한 부분이 보이면 끝까지 옆에 붙어서 싱크를 맞추려 했습니다. 오랫동안 사수 없는 환경에서 구르며 성장했기에, 리더가 기준을 잡아주고 함께 문제를 파고드는 것이 최고의 도움이라 믿었기 때문입니다.
그리고 저를 되돌아보게 되었습니다. 팀원들에게 높은 수준의 기준을 제시하고 제 생각에 부족한 부분이 있으면 끝까지 옆에 붙잡고 이야기하면서 싱크를 맞추려고 했습니다. 저는 한동안 사수가 없는 환경에서 일을 했었는데, 그래서 그런지 이렇게 기준을 제시해주고 옆에서 계속 같이 문제를 파고드는게 팀원들에게 도움이 되는 일이라고 생각하고 있었습니다.
물론 그 방식이 틀린 것만은 아니었을 겁니다. 하지만 F45 코치들이 제게 남들과 똑같은 표준 강도와 횟수만을 요구했다면, 과연 제가 그 세션을 끝까지 마칠 수 있었을까요? 저는 코치들에게 받았던 긍정적인 에너지를 우리 팀에도 전해주기로 결심했고, 행동 양식을 완전히 바꾸는 5가지 규칙을 세웠습니다.
- 규칙 1. 회의 중에는 무조건 웃는 얼굴로 마주하기 누군가 의견을 이야기할 때면 무조건 웃는 얼굴로 쳐다보며 경청했습니다. 회의실에 웃음소리가 자연스럽게 스며들도록 노력했습니다.
- 규칙 2. 다름을 대할 땐 '호기심'과 '선의'로 접근하기 서로 생각이 다를 때는, 제가 이해한 상대의 의견을 먼저 정리해서 말하며 오해가 없는지 점검했습니다. 그리고 제 생각을 더했죠. 만약 제게 실수가 있었다면 핑계 없이 깔끔하게 인정했습니다.
- 규칙 3. 스크럼의 시작은 가벼운 아이스브레이킹으로 매일 출근길의 날씨나 전날 밤의 뉴스 등을 참고해 첫 멘트를 준비했습니다. 마땅한 소재가 없으면 팀원의 눈에 띄는 긍정적인 변화라도 찾아내어 어떻게든 아침 분위기를 띄웠습니다.
- 규칙 4. 구체적인 사례로, 공정하게 칭찬하기 아쉬운 점을 꾸짖기보다는 아주 작은 것이라도 좋은 태도를 보였다면 즉각적이고 구체적으로 칭찬했습니다. 심지어 당사자가 없는 리더들 간의 회의에서도 칭찬을 아끼지 않았습니다.
- 규칙 5. 배포 기여도 상세히 기록하고 공유하기 무사히 배포가 끝날 때마다, 누가 어떤 기여를 했는지 상세하게 적어 조직 전체에 공유하며 모두가 성취감을 느끼게 했습니다.
저는 믿었습니다. 긍정적인 에너지를 바탕으로 신뢰가 쌓이면, 조금씩 서로의 업무 스타일과 기대치가 일치하게 되고, 결국 제가 원했던 기준 그 이상을 달성할 수 있을 거라고요. 이렇게 몇 주를 보내자 객관적인 숫자로 증명할 순 없어도 팀의 공기는 확실히 달라졌습니다. 타 부서에서 먼저 "그 팀 분위기가 많이 바뀌었네요"라고 말해줄 정도였고, 다들 눈치 보지 않고 자신의 의견을 가감 없이 이야기하기 시작했습니다. 비록 그 의견이 틀렸을지라도, 아무도 비난하지 않을 것이라는 단단한 심리적 안전감이 생겼으니까요.
F45 코치님들 덕분에 사람과 사람이 일할 때 '분위기와 관계'가 얼마나 중요한지 깊이 깨달았습니다. 당장 내일 아침 모두의 성과가 기준치를 훌쩍 넘기진 못하더라도, 방향이 맞다면 결국 시간이 해결해 줄 것이라 굳게 믿게 되었습니다.
PO 의 공석, T 와 L 의 균형을 고민하다.
두 개 분기 동안 팀에 PO(Product Owner)가 공석이었습니다. 불행히도 첫 분기에는 굵직한 프로젝트 여러 개가 한꺼번에 몰려버렸죠. 저는 기술적으로 풀어야 하는 문제들뿐만 아니라 팀의 일정, 타 부서와의 소통까지 모두 떠안아야 했습니다. 체감상 이전 업무량의 두 배를 훌쩍 넘겼습니다. 그 와중에 제가 놓치고 있는 수많은 조직적, 매니징 차원의 문제들이 눈에 밟혔지만, 스스로 무언가 조치를 취할 여력이 없어 깊은 무력감에 휩싸였습니다. 사실상 첫 분기가 끝날 즈음에는 반쯤 포기 상태였죠.
어떻게든 첫 분기를 넘겼습니다. 큰 프로젝트들은 어영부영 마무리되었고 성과는 미미했습니다. 다음 분기를 준비할 시기가 되어 비로소 팀을 돌아보았습니다. 하루하루 저를 짓누르는 무력감도 컸지만, 팀의 상태는 훨씬 심각했습니다. 동시다발적인 프로젝트를 쳐내느라 그동안 애써 잡아놓았던 일하는 방식과 팀워크가 모래성처럼 무너져 있었죠.
팀원들과 면담을 진행하며 가슴이 아팠습니다. 제가 느끼던 무기력과 좌절감을 그들도 고스란히 느끼고 있었으니까요. 슬픔은 곧 분노로 바뀌었고, 그 화살은 회사를 향했습니다. "PO가 없는 걸 뻔히 알면서 어떻게 이런 짐을 지울 수 있지? 이것 때문에 팀이 다 망가졌잖아.", "어떻게든 시키는 대로 다 했는데 성과는 왜 이래? 시장조사나 전략이 맞긴 했던 건가?"
무언가 변화가 절실했습니다. 다가오는 분기도 이렇게 흘려보낼 순 없었죠. 휴가를 내고 저보다 먼저 팀장 역할을 겪고 있는 친구와 드라이브를 하며 속마음을 털어놓았습니다. 그 친구의 답변은 심플했습니다.
"네 역할이 너무 빠르게 확장돼서 힘든 거야. 지금 당장은 '과락만 피한다'는 마인드를 기본으로 깔고, 진짜 중요한 문제 하나에만 집중해 봐." 그 짧은 조언이 제게 망치로 맞은 듯한 깨달음을 주었습니다. 저는 PO가 공석인 기간 동안, PO의 역할과 테크 리더의 역할을 모두 완벽하게 수행하려다 결과적으로 모든 것을 놓치고 있었던 겁니다. 상황을 객관화하니 제가 그동안 잘 써먹던 문제 해결 프레임워크(상황 파악 -> 문제 정의 -> 문제 해결)가 떠올랐습니다.
진짜 문제는, PO가 부재한 상황에서도 제가 여전히 '테크(Tech)' 역할만을 고집하고 있었다는 것이었습니다. 지금 우리 팀에 당장 필요한 것은 T(Tech)가 아니라 L(Lead), 즉 '리더'의 역할이었습니다. 리더는 무엇을 해야 할까요? 비전을 제시하고 성과를 내는 것도 중요하지만, 지금 당장 필요한 건 매니지 업(Manage-Up)이었습니다. 상사(CEO)의 기대를 현실적인 수준으로 조정하고, 당당히 근거를 요구하며, 때로는 무리한 업무를 거부하는 방패가 되어야 했죠. 리더로서 그 역할을 제대로 하지도 못했으면서 되려 회사 탓만 하고 있었던 제 자신을 발견했습니다.
저는 즉각 CEO와 미팅을 잡았습니다. 지난 분기에 우리가 '고객 가치'를 제대로 실현하지 못했음을 짚고, 앞으로 일하는 방식을 완전히 바꾸겠다고 선언했습니다. 다음 분기 업무 로드맵을 직접 짜서 현실적인 수준으로 조정했죠. CEO 앞에서 큰소리는 쳤지만, 속으로는 '이걸 나 혼자 해낼 수 있을까?' 두려웠습니다. 그래서 사내에 애자일(Agile) 코치 경험이 있는 분을 찾아가 조언을 구했습니다.
코치님의 솔루션은 명쾌했습니다. "의사결정 과정의 병목을 최대한 제거하고, 팀원 모두가 믿고 따를 수 있는 원칙을 만들라"는 것이었습니다. 너무나 감사하게도 그분은 직접 우리 팀 회의에 참여해 업무 진행과 코칭을 도와주셨습니다.
여기서 '의사결정의 병목'이란 곧 CEO와의 정렬(Alignment)을 의미했습니다. 큰소리는 쳤지만, 여전히 CEO는 1대1로 마주하기 부담스럽고 두려운 존재였습니다. 하지만 리더로서 이 두려움을 반드시 극복해야 했기에, 저는 난생처음 심리상담을 받으러 갔습니다.
나이가 지긋하신 선생님께 제가 지난 분기 동안 어떤 고통을 받았고, 지금 무엇을 극복해야 하는지 전부 털어놓았습니다. 제 이야기를 묵묵히 끝까지 들으신 선생님은 이렇게 정리해 주셨습니다. "내가 대표라면 당신을 너무 좋아할 것 같은데? 골치 아픈 문제도 다 해결해 줬고, 어떻게든 팀을 여기까지 끌고 온 거잖아. 무서워하지 말아요. 당당하게 부딪혀도 충분히 괜찮을 것 같은데." 그 한마디가 제게 엄청난 용기를 주었습니다.
팀이 일하는 원칙을 세우는 건 생각보다 쉬웠습니다. 모두가 고통의 시간을 지났기에 가슴속에 품고 있던 이야기들이 많았거든요. 쏟아지는 불만과 의견들을 정제해 3가지의 단단한 원칙을 세웠습니다.
- 기능을 많이 찍어내는 것이 중요한 게 아니다. 단 하나를 배포하더라도 고객이 진정 가치를 느끼는 기능을 배포한다.
- 계획은 언제든 변경될 수 있다. 우리는 합당한 사유가 있다면 일정은 유연하게 조정한다.
- 정기적인 회고는 무조건 진행한다. 회고를 통해 우리 팀이 일하는 방식을 끊임없이 발전시킨다.
이후 이슈가 생길 것 같으면 망설이지 않고 당당하게 CEO에게 이야기했습니다. 팀의 모든 아쉬운 점은 '리더 역할을 제대로 못한 제 탓'으로 돌렸고, 모든 구성원이 볼 수 있는 공개 채널에서 투명하게 소통했습니다. CEO가 팀에 기대하는 바가 있다면 다음 날 새벽까지 파고들어서라도 결과물이나 중간 보고를 가져갔습니다. 이 팀의 모든 책임과 결정은 내가 온전히 짊어진다는 확실한 시그널을 CEO와 팀원 모두에게 보여주었습니다. 덕분에 팀원들도 제가 매니징을 제대로 한다고 느꼈고, CEO도 더욱더 신뢰를 주었습니다.
팀원들과 함께 만든 원칙은 무슨 일이 있어도 사수했습니다. F45에서 얻었던 '긍정적 피드백'의 교훈을 매일의 업무에 녹여냈고, 최대한 팀원들을 외부의 압박으로부터 보호하며 그들이 '진짜 중요한 가치'에만 몰입할 수 있는 안전한 환경을 만드는 데 온 힘을 쏟았습니다.
회고를 마치며
처음에 생각했던 글의 구조는 조금더 구조화되어 있는 경험을 통해 학습했던 업무 원칙들 위주로 전달하고자 했습니다. 하지만 글을 쓰다보니 그래봤자 윌라신의 엔지니어링 리더십, 스태프 엔지니어 책보다 더 나을게 없다는 생각이 들었습니다. 그래서 그냥 솔직하게 경험들 위주로 수필처럼 적어보는걸로 방향을 바꿨습니다.
지금 와서 되돌아보면 지난 1년간 처음으로 병원에 입원도 해보고, 심리상담도 가보고 진짜 고생했구나 진짜 사람이 할짓이 못되는구나 하고 비춰질것도 같습니다. 하지만 저는 이러한 과정을 통해 제가 일하는 의미를 발견할 수 있었습니다. 수많은 어려움이 있음에도 내가 계속 나아가야 하는 이유 그거 하나는 제대로 찾았다고 자부합니다.
1년 뒤, 10년 뒤의 저는 이 회고록을 어떤 마음으로 돌아볼까요? 확실한 건, 지난 1년은 제 삶에서 가장 뜨거웠고 치열했던 순간으로 남을 거란 사실입니다. 그 누구도 알아주지 않는 압박 속에서도 저는 제 모든 것을 걸어 문제를 해결했고, 제 안의 탁월함을 깎아내기 위해 묵묵히 버텼습니다.
비정상적인 위기 속에서 비정상적인 방법으로 살아남은 이 1년의 기록이, 저와 비슷한 무게를 견디고 있을 누군가에게 작은 위로와 용기가 되기를 바라며 글을 마칩니다.
'탐구 생활' 카테고리의 다른 글
| ORM의 편리함 속 함정 - SELECT *와 수직 분할의 중요성 (0) | 2025.11.08 |
|---|