본문 바로가기

CTO

개발자가 싫어하는 대표의 5가지 습관 - 피해야 할 커뮤니케이션 "이거 간단한 거니까..."어느 날 저녁 8시, 개발자의 슬랙에 메시지가 옵니다. "내일 투자자 미팅이 있는데, 데모할 때 이 기능 하나만 더 보여주고 싶어요. 간단한 거니까 오늘 밤에 만들 수 있죠?"개발자는 한숨을 쉽니다. 또 시작이구나. 7년간 수많은 개발자들과 일하며, 그리고 수많은 대표님들과 대화하며 느낀 것이 있습니다. 좋은 대표와 나쁜 대표의 차이는 능력이 아니라 습관에 있다는 것을요. 특히 개발자와의 커뮤니케이션에서 몇 가지 습관은 정말 치명적입니다. 이런 습관이 반복되면, 아무리 좋은 개발자도 퇴사를 고민하게 됩니다.습관 1: "간단한 거잖아요" 증후군왜 문제인가"이거 그냥 버튼 하나 추가하는 건데..." "다른 데서 복붙하면 되는 거 아닌가요?" "간단한 거니까 금방 되죠?" 이 말을 .. 더보기
개발 기간은 왜 항상 늦어질까? - 일정 산정의 비밀 "2주면 되죠?"비개발자 대표님들이 가장 많이 하는 질문입니다. "로그인 기능 추가하는 거, 2주면 되죠?" "결제 시스템 붙이는 거, 1주일이면 충분하지 않나요?" "이거 그냥 버튼 하나 추가하는 건데, 하루면 되는 거 아닌가요?" 그리고 개발자는 난처한 표정으로 대답합니다."음... 최소 한 달은 봐야 할 것 같은데요." 대표님은 속으로 생각합니다. '개발자들은 왜 항상 일정을 길게 잡을까? 여유부리는 건가?' 개발자도 속으로 생각합니다. '대표님은 왜 항상 일정을 짧게 생각하실까? 개발이 뭔지 모르시나?' 이 간극이 스타트업의 가장 큰 갈등 중 하나입니다.개발은 빙산이다한 대표님이 실제로 했던 말입니다. "로그인 기능이요? 네이버도 있고, 카카오도 있고, 구글도 있잖아요. 그냥 복붙하면 되는 거 아.. 더보기
5명 개발팀 vs 1명 풀스택, 뭐가 나을까? - 규모별 팀 구성 전략 투자자가 던진 질문한 스타트업 대표님의 고민을 들은 적이 있습니다. 시리즈 A 투자 미팅에서 투자자가 물었다고 합니다. "개발팀이 몇 명이죠?" "5명입니다." "매출 대비 인건비 비중이 너무 높은 것 같은데요. 풀스택 개발자 1~2명으로도 충분히 돌아가는 서비스 아닌가요?" 그 대표님은 순간 당황했다고 합니다. 하지만 곰곰이 생각해보니, 그 질문은 틀리지 않았습니다. 당시 그 회사의 서비스는 기술적으로 복잡하지 않았고, 실제로 뛰어난 풀스택 개발자 한 명이면 충분히 만들고 유지할 수 있는 수준이었습니다. 반대의 경우도 봤습니다. 개발자 한 명으로 1년 넘게 버티다가 결국 서비스가 터져버린 스타트업. 그 한 명이 번아웃으로 퇴사하자 회사 전체가 마비됐습니다. 개발팀의 적정 규모는 정답이 없습니다. 하지만.. 더보기
기술 스택 선택, 대표가 알아야 할 것들 - React vs Vue는 중요하지 않습니다 "React로 할까요, Vue로 할까요?"개발자를 채용하거나 외주 개발사와 미팅할 때 자주 듣는 질문입니다. "React가 요즘 대세라고 하던데요?""Vue가 더 배우기 쉽다고 들었어요""Angular는 어떤가요?"그러면 개발자는 30분 동안 기술적인 장단점을 설명하고, 대표님은 고개를 끄덕이지만 사실 하나도 이해가 안 됩니다. 그리고 결국 이렇게 묻죠. "그래서... 뭐가 좋은 건가요?" 7년 전 저도 똑같았습니다. 공동창업자들과 기술 스택을 논의하면서 React와 Vue를 비교하는 문서를 며칠 동안 읽었습니다. 그런데 지금 돌아보니 깨닫습니다. 그건 정말 중요하지 않았습니다.충격적인 진실: 기술 스택은 생각보다 중요하지 않다제가 7년간 배운 가장 중요한 교훈입니다. 초기 스타트업에서 React를 선택.. 더보기
비개발 대표의 첫 개발자 채용 가이드 - 이력서에서 뭘 봐야 하나요? "이력서를 봐도 도통 모르겠어요"비개발 대표님들과 이야기하다 보면 가장 많이 듣는 말입니다. "React 5년 경력이라는데 좋은 건가요?""Github 스타 1,000개면 실력이 좋은 건가요?""대기업 출신인데 우리 스타트업에 맞을까요?" 저도 처음 개발자를 채용할 때 비슷했습니다. 기술 스택 나열만 잔뜩 있는 이력서를 보며 "이게 대체 무슨 뜻이지?" 싶었죠. 7년간 20,000명이 넘는 개발자를 면접하고, 그중 100명 정도와 함께 일하면서 배운 게 있습니다. 이력서에서 정말 봐야 할 건 화려한 스펙이 아니라, 그 사람이 우리 회사에서 실제로 일할 수 있는 사람인지 판단할 수 있는 단서들입니다.첫 번째 개발자, 왜 가장 중요한가첫 개발자 채용은 그냥 채용이 아닙니다. 회사의 기술 DNA를 결정하는 순.. 더보기
개발자가 하는 말, 번역해드립니다 - "기술 부채", "리팩토링", "레거시"의 진짜 의미 "대표님, 기술 부채가 심각합니다"이 말을 들으면 대표님들은 보통 이렇게 생각합니다. "기술 부채? 우리가 개발비를 못 준 건가? 아니면 서버비를 밀린 건가?" 아닙니다. 개발자가 말하는 기술 부채는 돈 문제가 아닙니다. 하지만 방치하면 정말로 돈 문제가 될 수 있습니다. 작년에 한 대표님께서 급하게 연락하셨습니다. 간단한 기능 하나 추가하는 데 개발자가 2달이 걸린다고 한다는 거였죠. "뭐가 그리 어렵냐"고 물으니 개발자는 "기술 부채 때문"이라고만 답했답니다. 대표님은 화가 나서 개발자를 바꾸려 했고, 개발자는 억울해서 퇴사를 고민했습니다. 문제는 둘 다 같은 언어를 쓰고 있지만, 다른 뜻으로 이해하고 있다는 거였습니다. 오늘은 개발자들이 자주 쓰는 용어들을 비개발자 대표님들이 이해할 수 있게 번역해.. 더보기
스타트업에 CTO가 정말 필요한가? CTO 명함의 무게"우리 회사 CTO입니다."이러면서 명함을 건넨다고 해도 아쉽지만 상대방의 눈빛은 달라지지 않습니다. 솔직히 말하자면, 초기 스타트업에서 CTO라는 타이틀은 생각보다 가볍습니다. 3명짜리 팀에서 개발자 1명에게 CTO 명함을 주는 건 어렵지 않으니까요. 문제는 그 타이틀이 실제로 필요한 역할과 책임을 의미하느냐는 것입니다. 8년 전 저희 팀이 시작했을 때도 비슷했습니다. 공동창업자로 합류하면서 자연스럽게 CTO 타이틀을 받았지만, 당시 제가 한 일은 CTO라기보다는 '유일한 개발자'에 가까웠습니다. 아키텍처 설계, 코딩, 배포, 서버 관리, 심지어 와이파이 고장까지 모두 제 몫이었죠. 그때 깨달았습니다. 스타트업에 정말 필요한 건 CTO라는 타이틀이 아니라, 그 순간 회사가 필요로 하는.. 더보기