어떤 회사에 지원할지 고민 중인데 CTO가 주말마다 코드를 커밋한다고 자랑하는 블로그 글을 본다면, 나는 도망칠 준비를 할 것임
리더의 역할은 건강한 조직 문화를 만드는 것인데, 주말 근무를 자랑하는 건 그 반대임
게다가 법무나 엔지니어링 검토를 생략하고 고객 문제를 하루 만에 해결했다고 공개적으로 말하는 건 위험한 신호임
인용된 부분 중 “사람 관리나 조직 설계는 내 강점이 아니다”라는 문장이 특히 인상적이었음
스타트업의 기술 창업자형 CTO와 대기업의 전문 CTO를 혼동한 것 같음
초기 스타트업에서는 문화가 완전히 다르고, 이런 글은 오히려 적합한 인재를 걸러내는 필터 역할을 함
오히려 CTO가 직접 나서서 비효율적인 프로세스를 깨고 중간관리자의 핑계 구조를 없애는 게 맞다고 생각함
다만 “하루 만에 만들었다”는 표현은 팀의 역량을 깎아내리는 뉘앙스라서, 블로그에 공개할 일은 아닌 듯함
나도 창업자/CTO로서 주말에 코딩하지만, 팀원에게 강요하지 않음
내가 짜는 코드는 대부분 내부 DevEx 개선이나 기술 부채 정리용임
법적 검토를 생략하는 일은 없고, 프로덕션 코드보다는 PoC 수준으로만 다룸
창업자 CTO는 코드에 가까이 있는 게 중요하지만, 균형을 잃지 않는 게 핵심임
CTO 역할은 회사마다 다름
Greg Brockman의 Stripe 사례처럼 어떤 CTO는 기술 비전가, 어떤 CTO는 조직 설계자, 또 어떤 CTO는 인프라 중심임
나의 경우엔 코딩을 즐기고 고객과 코드베이스에 깊이 관여해 있어서, 그게 가장 큰 가치 창출 방식임
“CTO”라는 직함은 정의가 모호함
어떤 CTO는 창업자 출신으로 자유롭게 코딩하고, 또 어떤 CTO는 고객 중심으로 일하다가 코드 접근권을 잃음
반면 독단적인 CTO도 존재함
결국 어떤 유형의 CTO인지 명확히 해야 ‘왜 코딩하는가’라는 질문이 의미를 가짐
창업자라면 CTO라는 타이틀보다 공동창업자라는 지위가 더 중요함
이 경우 CTO라는 이름은 단지 역할 구분일 뿐임
많은 회사에는 VP of Engineering과 CTO가 따로 있음
CTO는 전략과 방향성, VP는 일상적인 엔지니어링 관리에 집중함
예전에 C레벨이 일반 직원과 함께 일하던 회사를 다녔는데, 그들이 진짜 똑똑했고 자신의 한계를 아는 겸손함이 있었음
CTO의 본질은 회사를 기술적으로 경쟁력 있게 유지하는 것임
그 방법이 조직 구축이든 직접 코딩이든 상관없음
하지만 “CTO”라는 말을 꺼내는 순간 허세가 따라오는 경우도 많음
관리직이 직접 코드를 짜면 코드 리뷰가 왜곡되고, 팀이 혼란스러워질 수 있음
결국 그 사람은 CTO가 아니라 마음은 여전히 개발자일 가능성이 큼
나도 팀에서 가장 시니어라 리뷰어들이 내 코드를 거절하기 어려워하는 게 고민임
CTO가 코딩하는 걸 완전히 반대하진 않지만, 이 경우엔 CTO 역할 수행이 부족해 보임
실질적인 기술 리더십은 창업 엔지니어가 담당하는데, 보상은 훨씬 적은 구조가 문제임
보고 체계가 없고 코딩만 하는 CTO는 전략보다는 시니어 개발자 역할에 가깝다고 생각함
나도 그런 제안을 받아봤지만 결국 형식적인 타이틀에 불과했음
나도 코딩하는 CTO지만, 아직 직원이 없고 매출도 적음
조직이 커지면 역할이 달라질 것 같음
CTO의 핵심은 책임과 자율성임
작은 스타트업에서는 팀과 함께 스프린트를 진행하며, 일정이 밀리면 원인을 해결하고, 번아웃된 사람을 챙기는 게 내 일임
“전략에 집중한다”는 말이 구체적으로 뭘 의미하는지 의문임
“직속 보고자가 없다”는 건 단순히 관리 라인이 없다는 뜻일 수도 있음
하지만 글을 보면 팀이 핫한 AI 프로젝트조차 시도할 여유가 없는 구조라면, 그건 조직 문제임
CTO가 직접 코딩하는 게 아니라 이런 시스템적 병목을 해결해야 함
결국 이 글은 채용 홍보용이지만, 내부적으로는 비정상적인 구조를 드러내는 듯함
기술 직함은 맥락 없이는 의미가 없음
회사마다 “시니어”나 “헤드”의 역할이 완전히 다름
CTO가 코딩에 너무 몰입하면 생기는 문제는 명확함
PR 리뷰 왜곡, 본업 소홀, 역할 혼란, 팀의 자율성 침해 등임
“CTO는 코딩하지 말고 전략만 해야 한다”는 생각은 기계적 사고임
기술 회사의 본질은 가치 전달이고, 때로는 CTO가 직접 큰 기능을 하루 만에 구현하는 게 가장 가치 있는 일일 수 있음
KPI 회의보다 훨씬 생산적인 하루일 수도 있음
가끔은 C레벨이 직접 현장 감각을 되찾는 게 필요함
어떤 사람은 CTO가 된 이유가 단지 공동창업자이기 때문일 수도 있음
이런 접근으로 다른 회사에 들어간다면 스태프 엔지니어 수준에도 못 미칠 수 있음
마지막으로, 회사 웹사이트의 가격 페이지에 실제 가격이 없다는 점은 혼란을 줄 수 있으니 수정이 필요함
Hacker News 의견
어떤 회사에 지원할지 고민 중인데 CTO가 주말마다 코드를 커밋한다고 자랑하는 블로그 글을 본다면, 나는 도망칠 준비를 할 것임
리더의 역할은 건강한 조직 문화를 만드는 것인데, 주말 근무를 자랑하는 건 그 반대임
게다가 법무나 엔지니어링 검토를 생략하고 고객 문제를 하루 만에 해결했다고 공개적으로 말하는 건 위험한 신호임
초기 스타트업에서는 문화가 완전히 다르고, 이런 글은 오히려 적합한 인재를 걸러내는 필터 역할을 함
내가 짜는 코드는 대부분 내부 DevEx 개선이나 기술 부채 정리용임
법적 검토를 생략하는 일은 없고, 프로덕션 코드보다는 PoC 수준으로만 다룸
창업자 CTO는 코드에 가까이 있는 게 중요하지만, 균형을 잃지 않는 게 핵심임
CTO 역할은 회사마다 다름
Greg Brockman의 Stripe 사례처럼 어떤 CTO는 기술 비전가, 어떤 CTO는 조직 설계자, 또 어떤 CTO는 인프라 중심임
나의 경우엔 코딩을 즐기고 고객과 코드베이스에 깊이 관여해 있어서, 그게 가장 큰 가치 창출 방식임
“CTO”라는 직함은 정의가 모호함
어떤 CTO는 창업자 출신으로 자유롭게 코딩하고, 또 어떤 CTO는 고객 중심으로 일하다가 코드 접근권을 잃음
반면 독단적인 CTO도 존재함
결국 어떤 유형의 CTO인지 명확히 해야 ‘왜 코딩하는가’라는 질문이 의미를 가짐
이 경우 CTO라는 이름은 단지 역할 구분일 뿐임
CTO는 전략과 방향성, VP는 일상적인 엔지니어링 관리에 집중함
그 방법이 조직 구축이든 직접 코딩이든 상관없음
관리직이 직접 코드를 짜면 코드 리뷰가 왜곡되고, 팀이 혼란스러워질 수 있음
결국 그 사람은 CTO가 아니라 마음은 여전히 개발자일 가능성이 큼
CTO가 코딩하는 걸 완전히 반대하진 않지만, 이 경우엔 CTO 역할 수행이 부족해 보임
실질적인 기술 리더십은 창업 엔지니어가 담당하는데, 보상은 훨씬 적은 구조가 문제임
보고 체계가 없고 코딩만 하는 CTO는 전략보다는 시니어 개발자 역할에 가깝다고 생각함
나도 그런 제안을 받아봤지만 결국 형식적인 타이틀에 불과했음
조직이 커지면 역할이 달라질 것 같음
작은 스타트업에서는 팀과 함께 스프린트를 진행하며, 일정이 밀리면 원인을 해결하고, 번아웃된 사람을 챙기는 게 내 일임
하지만 글을 보면 팀이 핫한 AI 프로젝트조차 시도할 여유가 없는 구조라면, 그건 조직 문제임
CTO가 직접 코딩하는 게 아니라 이런 시스템적 병목을 해결해야 함
회사마다 “시니어”나 “헤드”의 역할이 완전히 다름
CTO가 코딩에 너무 몰입하면 생기는 문제는 명확함
PR 리뷰 왜곡, 본업 소홀, 역할 혼란, 팀의 자율성 침해 등임
“CTO는 코딩하지 말고 전략만 해야 한다”는 생각은 기계적 사고임
기술 회사의 본질은 가치 전달이고, 때로는 CTO가 직접 큰 기능을 하루 만에 구현하는 게 가장 가치 있는 일일 수 있음
KPI 회의보다 훨씬 생산적인 하루일 수도 있음
가끔은 C레벨이 직접 현장 감각을 되찾는 게 필요함
어떤 사람은 CTO가 된 이유가 단지 공동창업자이기 때문일 수도 있음
이런 접근으로 다른 회사에 들어간다면 스태프 엔지니어 수준에도 못 미칠 수 있음
마지막으로, 회사 웹사이트의 가격 페이지에 실제 가격이 없다는 점은 혼란을 줄 수 있으니 수정이 필요함