
솔직히 고백하자면, 저는 제가 '스티브 잡스'가 된 줄 알았습니다. 창업 초기, 팀원이 5명을 넘어가고 엔젤 투자를 받았을 때 제 머릿속을 지배한 건 '프로덕트'가 아니라 '조직 문화'였습니다. LG CNS 시절 겪었던 딱딱한 위계질서가 싫었고, 토스에서 경험한 자율적인 문화가 정답이라 믿었거든요. 그래서 저는 코드를 짜는 대신 '관리'를 시작했습니다. 1:1 면담을 잡고, 동기 부여 세션을 열고, 거창한 성과 관리 시스템을 도입하려 했죠.
결과는 처참했습니다. 프로덕트의 핵심 지표는 바닥을 기는데, 저는 회의실에서 "우리의 미션은 무엇인가"를 떠들고 있었으니까요. 그때 날려버린 시간과 인건비를 따져보니 대략 런웨이(Runway) 6개월 치에 해당하더군요. 오늘은 저처럼 '멋진 CEO 놀이'에 취해 골든타임을 놓치지 않길 바라는 마음으로, 초기 스타트업이 범하는 치명적인 관리의 안티패턴에 대해 이야기해 보려 합니다.
동기 부여는 '주입'하는 게 아니라 '채용'하는 것입니다
당시 저는 개발자들이 야근을 하지 않거나 주말에 슬랙 알림을 끄면 불안했습니다. "열정이 식었나?"라는 생각에 토요일 아침 스탠드업 미팅을 제안하기도 했죠. 소위 '996' 같은 문화를 은근히 강요하며, 그것이 스타트업의 야성이라 포장했습니다. 하지만 이건 제 불안함을 팀원들에게 전가하는 행위일 뿐이었습니다.
진짜 A급 엔지니어들은 제가 "열심히 하라"고 닥달해서 움직이지 않았습니다. 그들은 본능적으로 문제 해결에 집착하는 사람들이었습니다. 제가 억지로 동기를 주입하려 들자, 오히려 실력 있는 시니어 개발자가 면담 요청을 해오더군요. "대표님, 저는 코드를 짜고 문제를 해결하러 왔지, 군대식 점호를 받으러 온 게 아닙니다." 그가 떠나고 나서야 깨달았습니다. 동기 부여는 관리자가 만들어내는 산출물이 아니라, 채용 단계에서 이미 결정된 '변수'라는 것을요.
여러분이 지금 팀원들의 근태를 감시하느라 에너지를 쓰고 있다면, 그건 관리의 문제가 아니라 채용의 실패일 확률이 높습니다. 훌륭한 초기 멤버는 억지로 시키지 않아도, 새벽 2시에 유럽 고객과 미팅을 잡고, 스스로 레거시 코드를 뜯어고칩니다.
관리자를 너무 일찍 뽑는 건 '자살골'입니다
팀원이 10명이 되었을 때, 저는 덜컥 '엔지니어링 매니저(EM)'를 채용했습니다. 제가 실무에서 손을 떼고 싶었기 때문입니다. 하지만 아직 PMF(Product-Market Fit)도 찾지 못한 단계에서 전문 관리자를 뽑은 건 최악의 수였습니다.
우리는 아직 '무엇을 만들지'도 모르는 상태였습니다. 그런데 새로 온 매니저는 '어떻게 만들지'를 최적화하려 들더군요. JIRA 티켓을 예쁘게 정리하고, 스프린트 프로세스를 정립하는 데 일주일을 썼습니다. 하지만 정작 고객이 원하는 기능은 배포되지 않았습니다. 관리자는 자신의 직무인 '관리'를 열심히 했을 뿐입니다. 문제는 관리할 '대상(성공한 제품)'이 없었다는 점이죠.
초기 단계, 적어도 엔지니어가 15명 미만인 단계에서는 전문 관리자가 필요 없습니다. 창업자나 CTO가 직접 모든 엔지니어와 소통해야 합니다. "체계가 없다"고 불평할 수도 있습니다. 하지만 초기 스타트업에서 체계보다 중요한 건 '속도'와 '생존'입니다. 중간 관리자 한 명을 거칠 때마다 의사결정 속도는 반으로 줄고, 정보의 왜곡은 두 배로 늘어납니다. 관리자가 아니라, 당장 고객의 불만을 코드로 해결해 줄 '메이커'가 필요합니다.
구글을 따라 하지 마십시오, 제발
많은 창업자가 구글이나 넷플릭스의 화려한 인사 제도를 흉내 냅니다. 저 또한 그랬습니다. OKR을 도입하고, 동료 평가 시스템을 설계하느라 밤을 샜습니다. 그런데 곰곰이 생각해 보십시오. 구글이 그런 시스템을 만든 건 직원이 수만 명이라서입니다. 우리는 고작 작은 보트에 탄 10명 남짓한 선원일 뿐입니다.
기술 스택을 고를 때, 우리는 보통 가장 지루하고 검증된 'Node & Postgres' 조합을 선택합니다. 그게 가장 안전하고 효율적이기 때문이죠. 관리도 마찬가지여야 합니다. 혁신적인 관리 기법을 도입하려 하지 마십시오. 그냥 가장 지루하고 뻔한 방식을 택하세요. 매주 한 번 전체 미팅하고, 솔직하게 대화하고, 투명하게 공유하는 것. 그거면 충분합니다.

지금도 가끔 후배 창업자들을 만나면 묻습니다. "지금 하시는 그 고민이, 이번 달 매출에 1원이라도 기여합니까?"
만약 당신이 지금 모니터 뒤에 숨어 조직도를 그리고 있거나, JIRA 티켓의 상태 값을 고민하고 있다면, 당장 멈추고 고객을 만나러 가십시오. 아니면 IDE를 켜고 버그라도 하나 더 잡으십시오. 초기 스타트업에서 '관리'란, 일을 되게 만드는 최소한의 기름칠일 뿐, 그 자체가 목적이 되어서는 안 됩니다.
우리는 회사를 '운영'하러 모인 게 아니라, 제품을 '만들어' 생존하기 위해 모인 사람들이니까요. 당신의 시간은 어디에 쓰이고 있습니까?


