▲

CTO로서 내가 코드를 작성하는 이유

 (assembled.com)
18P by GN⁺ 2일전 | ★ favorite | 댓글 5개
  • 많은 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 역할 정의에 관한 블로그 포스트 참고
    • 여러 CTO와 대화 후 역할의 형태에 엄청난 편차 존재 인식
    • 일부 CTO는 기술 비전가, 일부는 조직 빌더, 일부는 인프라 중심
    • 공통점은 훌륭한 CTO가 자신의 특정 기술, 관심사, 회사 상황을 고려하여 가장 많은 가치를 창출할 수 있는 영역을 파악한다는 것
  • 필자의 경우 많은 코드 작성을 의미
    • 조직 설계보다 소프트웨어 구축을 더 즐김
    • 고객과 코드베이스에 대한 깊은 지식으로 특히 효과적
    • 강력한 엔지니어링 매니저 채용
  • 그러나 이것은 개인적인 경로이지 처방이 아님
  • CTO 역할은 매우 유연
    • 조직 구축, 제품 전략 개발 등 - 기술 리더십은 강점, 에너지 원천, 회사 필요에 따라 다양
  • 리더십이 기술 업무 포기를 의미한다고 걱정하는 엔지니어에게: 많은 경로 존재
    • 핵심은 자신이 독특하게 뛰어난 영역을 파악하는 것
▲
scari 3시간전  [-]

현직 CTO이고 이 글에 매우 동의하지 않습니다.
코딩을 놓으면 안 된다에는 100% 공감하는데, 회사 제품과 상관없는 오픈소스를 하면 될 일입니다. 초기 스타트업의 기술 파운더로써 올라운더로 일해야 한다는 관점에서만 유효한 얘기라고 생각합니다.

답변달기
▲
iolothebard 11시간전  [-]

본인이야 좋겠지… 하지만 회사는?
받는 월급에 맞는 일을 해야…

답변달기
▲
vk8520 2일전  [-]

실험형 프로젝트를 CTO가 직접 하는 게 의아하네요. 실무진들한테 충분한 시간을 준다면 잘 해낼탠데 말이죠. 가장 의아한 건, 장기 실험형 프로젝트를 CTO만 진행해야 한다는 게 상당히 의아합니다. 본인에게 리소스 사용 권한이 있다면, 실험형 프로젝트를 위한 리소스를 따로 구해내어서 실무진에게 충분히 시간을 주면 되는 일인텐데 말이죠.

답변달기
▲
shakespeares 2일전  [-]

개인적인 경로.. 조직 관리 할 부분이 늘어나지 않도록 관리를 잘해야 할텐데 말이죠..

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 어떤 회사에 지원할지 고민 중인데 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가 된 이유가 단지 공동창업자이기 때문일 수도 있음
    이런 접근으로 다른 회사에 들어간다면 스태프 엔지니어 수준에도 못 미칠 수 있음

  • 마지막으로, 회사 웹사이트의 가격 페이지에 실제 가격이 없다는 점은 혼란을 줄 수 있으니 수정이 필요함

답변달기