# CTO로서 내가 코드를 작성하는 이유 > Clean Markdown view of GeekNews topic #23930. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23930](https://news.hada.io/topic?id=23930) - GeekNews Markdown: [https://news.hada.io/topic/23930.md](https://news.hada.io/topic/23930.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-27T00:38:42+09:00 - Updated: 2025-10-27T00:38:42+09:00 - Original source: [assembled.com](https://www.assembled.com/blog/why-i-code-as-a-cto) - Points: 21 - Comments: 5 ## Summary 많은 CTO가 관리 중심으로 이동하지만, 여전히 **직접 코드를 작성하며 제품을 구축**하는 리더십 방식을 강조하는 글입니다. 글쓴이는 실험적 프로젝트, 긴급 고객 요청, 버그 수정 같은 **세 가지 개발 활동**을 통해 조직 내에서 가장 높은 **레버리지**를 창출한다고 말하는데요. **AI 개발 도구의 실제 효용과 한계**를 몸소 체감하며 기술적 판단력을 유지하는 점은 꽤 인상적입니다. 결국 CTO의 역할은 정형화된 틀보다 **자신의 강점과 회사의 맥락에 맞는 리더십 설계**에 달려 있다는 메시지가, 기술 리더로서 방향을 고민하는 이들에게는 참고할 만 합니다. ## Topic Body - 많은 CTO들이 관리 중심으로 전환하지만, 여전히 **직접 코드를 작성하며 제품을 개발**하는 방식을 유지하고 있음 - 실험적 프로젝트, 긴급 고객 요청, 버그 수정 등 **세 가지 유형의 개발 작업**을 통해 조직 내에서 높은 레버리지를 창출 - 코딩을 지속함으로써 **AI 도구의 실제 효용과 한계**를 직접 체감하고, 기술적 의사결정의 현실성을 확보 - 관리보다는 **문제 해결과 제품 구축에 강점과 열정**을 두며, 이를 가능하게 하는 조직 구조를 설계 - CTO 역할에는 정형화된 틀이 없으며, **각자의 강점과 회사 상황에 맞는 리더십 방식**을 찾는 것이 핵심 --- ### CTO로서 코드를 계속 작성하는 이유 - 많은 CTO들이 시간이 지나며 코딩을 멈추지만, 여전히 **직접 기능을 개발하고 배포**하는 방식을 유지하고 있음 - 지난 12개월 동안 직접 보고하는 팀원 없이 여러 주요 기능을 출시 - 단순한 취미 수준이 아닌, 실제 제품에 반영되는 **핵심 기능 개발자 역할** 수행 - 이를 “기술 리더로서 가장 **레버리지가 높은 활동** 중 하나”로 정의함 ### 실제로 구축하는 세 가지 유형의 프로젝트 #### 1. 장기 실험형 프로젝트 (Long-horizon experimental projects) - 조직 내에서 **새로운 제품을 실질적으로 구축할 수 있는 인력은 매우 제한적**임 - 대부분의 조직은 기존 제품 유지와 확장에 초점을 맞추기 때문 - 창업자, 일부 임원, 고성과 개인 기여자(IC)만이 새로운 제품을 시도할 여유를 가짐 - 조직 구조, 로드맵 인센티브, 제한된 리스크 예산으로 인해 대부분의 엔지니어는 몇 달간 불확실한 프로젝트 추진 불가 - CTO는 **고객 pain point와 아키텍처에 대한 깊은 이해**를 바탕으로 **불확실한 실험 프로젝트를 빠르게 추진할 수 있는 독특한 위치** - 실패 사례도 있었지만 큰 성공도 달성 - AI 채팅 제품 사례: 팀이 가치를 인정했지만 시간과 여유가 없어 미뤄졌던 프로젝트를 추수감사절 휴가 기간에 프로토타입 개발 - 이후 팀과 협력하여 **수백만 달러 ARR 제품으로 상용화** 성공 #### 2. 긴급 고객 요청 처리 (Critical customer asks) - 주요 고객이 긴급하게 필요로 하는 기능이 **대규모 계약이나 갱신의 블로커**가 되는 상황 발생 - 현재 스프린트 진행 중인 엔지니어를 투입하는 대신, CTO가 **빠른 의사결정과 시스템 전체 이해**를 바탕으로 직접 처리 - 실제 사례: 연간 백만 달러 고객의 컴플라이언스를 위한 **데이터 리덕션 기능 요청** - 팀의 초기 검토에서는 고객이 직접 API 통합을 구축하거나, 제품·법무·엔지니어링 간 여러 회의 필요로 예상 - CTO가 하루 만에 작동하는 버전 구축 및 배포로 **고객 관계 유지** #### 3. 버그 수정 (Bugfixes) - 많은 사람이 놀라지만, **버그 수정은 코드베이스의 멘탈 맵을 유지**하는 가장 좋아하는 방법 중 하나 - 검색 결과 3페이지에서 페이지네이션이 깨지거나, WebSocket 연결이 정확히 60초 후 끊기는 이유를 추적할 때 시스템 전체를 순회 - 코드 리뷰나 아키텍처 논의로는 얻기 어려운 **기술 부채에 대한 직관적 이해** 획득 - 이러한 경험을 통해 **기술 투자 방향과 우선순위 결정**에 필요한 직관을 유지 ### 코딩을 지속하는 이유 #### 1. 실제로 작동하는 기술을 파악하기 위해 - Claude Code, Codex, Cursor 등 **AI 도구를 매일 사용**하는 경험을 통해 도구 및 채용 전략적 결정 시 현실과 과대광고 구분 가능 - 최근 사례: 복잡한 통합을 건드리는 기능을 vibe-coding으로 시도했으나 진전 없다가, 직접 손으로 작성하니 훨씬 빠르게 진행 - 코드량은 많지 않았지만 정확한 로직 필요 (LLM에 취약한 영역) - 반면 다른 대형 기능은 Claude Code로 거의 전체 개발 - **AI가 뛰어난 영역(CRUD, 테스트, 보일러플레이트)과 실패하는 영역(정밀성, 시스템 뉘앙스)** 파악이 트위터 과대광고 기반 의사결정보다 우월 - 코드 내부에 있으면 **언제 압박하고 언제 완화할지 감지** 가능 - 아키텍처가 지나치게 복잡하거나 기술 부채가 실제 문제가 되는 시점 감지 - 보고에만 의존하는 관리자는 많은 것을 놓칠 수 있음 #### 2. 자신이 잘하고 즐기는 일에 집중하기 위해 - **조직 구축과 인사 관리는 특별히 즐기지 않음** - 엔지니어링 관리는 대인 관계 역학, 성과 평가, 조직 설계 필요 - 중요한 기능이지만 강점이 있는 영역은 아님 - 그래서 **우수한 엔지니어링 매니저와 리더를 채용** - 그들이 더 잘하고 즐김 - CTO는 **제품 개발, 기술 문제 해결, 코딩**에 집중 가능 - 스타트업은 “**스프린트형 마라톤**”과 같아서, **흥미를 유지하고 오래 빠르게 달릴 수 있는 업무** 중심으로 역할 설계 - 이것이 수년간 지속 가능한 방식이며, 회사에 매우 중요 #### 3. AI 도구가 레버리지를 확장시켰기 때문 - 몇 년 전에는 **전략적 업무를 처리하면서 코딩 시간 확보에 어려움**이 있었음 - 회사가 성장하면서 하루 종일 회의에 갇혀 있고, 강점 영역 밖에서 작업 - 전문적으로 가장 힘든 시기 중 하나 - **현대 AI 도구가 이 방정식을 근본적으로 변화**시킴 (특히 최근 몇 개월) - **생산성이 이전보다 2~3배 향상** - 이 도구들은 판단력이나 기술 지식을 대체하지 않고, 오히려 그 기술을 더 가치 있게 만듦 - AI 도구에게 "기존 CSV 내보내기 형식과 일치하되 사용자 프로필 테이블에서 세 가지 추가 필드를 포함하는 데이터 내보내기 구축"이라고 지시하면 대부분의 코드를 정확하게 생성 - 정확히 무엇이 필요하고 어디서 찾을지 아는 **깊은 컨텍스트 보유** - 해당 코드베이스 부분에 익숙하지 않은 엔지니어는 세부 사항 파악에 상당한 시간 소요 - 업무가 "모든 코드 라인 작성"에서 **"컨텍스트 제공, 의사결정, 솔루션 평가"로 전환** - 다행히 많은 컨텍스트 보유 ### 자신에게 맞는 방식 찾기 - CTO 역할을 정의할 때 [Greg Brockman의 Stripe CTO 역할 정의에 관한 블로그 포스트](https://blog.gregbrockman.com/figuring-out-the-cto-role-at-stripe) 참고 - 여러 CTO와 대화 후 **역할의 형태에 엄청난 편차** 존재 인식 - 일부 CTO는 기술 비전가, 일부는 조직 빌더, 일부는 인프라 중심 - 공통점은 훌륭한 CTO가 **자신의 특정 기술, 관심사, 회사 상황**을 고려하여 가장 많은 가치를 창출할 수 있는 영역을 파악한다는 것 - 필자의 경우 많은 코드 작성을 의미 - 조직 설계보다 **소프트웨어 구축을 더 즐김** - **고객과 코드베이스에 대한 깊은 지식**으로 특히 효과적 - 강력한 엔지니어링 매니저 채용 - 그러나 이것은 **개인적인 경로이지 처방이 아님** - CTO 역할은 매우 유연 - 조직 구축, 제품 전략 개발 등 - 기술 리더십은 **강점, 에너지 원천, 회사 필요에 따라 다양** - 리더십이 기술 업무 포기를 의미한다고 걱정하는 엔지니어에게: **많은 경로 존재** - 핵심은 **자신이 독특하게 뛰어난 영역**을 파악하는 것 ## Comments ### Comment 45568 - Author: scari - Created: 2025-10-29T07:52:35+09:00 - Points: 1 현직 CTO이고 이 글에 매우 동의하지 않습니다. 코딩을 놓으면 안 된다에는 100% 공감하는데, 회사 제품과 상관없는 오픈소스를 하면 될 일입니다. 초기 스타트업의 기술 파운더로써 올라운더로 일해야 한다는 관점에서만 유효한 얘기라고 생각합니다. ### Comment 45566 - Author: iolothebard - Created: 2025-10-29T00:19:38+09:00 - Points: 1 본인이야 좋겠지… 하지만 회사는? 받는 월급에 맞는 일을 해야… ### Comment 45515 - Author: vk8520 - Created: 2025-10-27T19:35:29+09:00 - Points: 1 실험형 프로젝트를 CTO가 직접 하는 게 의아하네요. 실무진들한테 충분한 시간을 준다면 잘 해낼탠데 말이죠. 가장 의아한 건, 장기 실험형 프로젝트를 CTO만 진행해야 한다는 게 상당히 의아합니다. 본인에게 리소스 사용 권한이 있다면, 실험형 프로젝트를 위한 리소스를 따로 구해내어서 실무진에게 충분히 시간을 주면 되는 일인텐데 말이죠. ### Comment 45505 - Author: shakespeares - Created: 2025-10-27T10:40:33+09:00 - Points: 1 개인적인 경로.. 조직 관리 할 부분이 늘어나지 않도록 관리를 잘해야 할텐데 말이죠.. ### Comment 45488 - Author: neo - Created: 2025-10-27T00:38:43+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45695979) - 어떤 회사에 지원할지 고민 중인데 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가 된 이유가 단지 **공동창업자**이기 때문일 수도 있음 이런 접근으로 다른 회사에 들어간다면 **스태프 엔지니어** 수준에도 못 미칠 수 있음 - 마지막으로, 회사 웹사이트의 **가격 페이지에 실제 가격이 없다는 점**은 혼란을 줄 수 있으니 수정이 필요함