Prototyping as Leadership: How a CTO Ships with AI Agents — Hursh Agrawal, The Browser Company

한 줄 핵심

AI 코딩 에이전트 덕분에 CTO 같은 리더도 바쁜 일정 속에서 매일 빌드하고, 밤새 실행·검증·개선까지 돌리며 제품과 전략을 함께 바꿀 수 있게 됐다.

시간별 요약

1. 0:00
   관리자의 일정, 그리고 왜 빌드가 일이 되었는가 리더의 일정은 회의와 보고로 가득하지만, AI 에이전트 덕분에 그 사이사이가 실제 빌드 시간으로 바뀌었다. 이제 리더십은 문서와 회의로만 영향력을 행사하는 것이 아니라, 직접 제품을 만들며 모델 변화와 사업 방향을 동시에 읽어내는 일까지 포함한다.
2. 2:44
   새 모델을 판단하는 법, 그리고 논쟁보다 시연 새 모델의 유용성은 오래 토론해서가 아니라 직접 써봐야 판단할 수 있다. 프로토타입을 만들어 팀에 보여주면, 매번 설득하는 비용을 줄이면서 제품과 전략에 미칠 영향을 더 빠르게 공유할 수 있다.
3. 4:25
   실행은 해결됐고, 판단은 아직 남아 있다 모델은 실행에는 강하지만 무엇을 시도해야 하는지 판단하는 능력은 여전히 부족하다. 리더는 가진 맥락을 바탕으로 모델이 막히는 지점을 넘겨주고, 내부 툴·팀 보상용 산출물·비전 실험 같은 영역에 시간을 써야 한다.
4. 5:16
   리더가 만들어야 할 네 가지와 피해야 할 한 가지 리더가 만들기 좋은 것은 내부 효율 도구, 팀을 기리는 산출물, 그리고 새 모델의 가능성을 보여주는 비전형 제품이다. 반대로 핵심 경로의 업무는 맡지 않아야 하며, 일정이 흔들릴 때 바로 영향받는 일을 리더가 쥐는 것은 피해야 한다.
5. 6:05
   하루의 형태, 그리고 왜 5pm이 가장 중요한가 아침에는 전날 밤 에이전트가 만든 코드를 검토하고, 낮에는 짧은 steering 시간으로 방향을 잡고, 5:00 p.m.에는 밤새 돌릴 작업을 세팅하는 흐름이 가장 효율적이다. 핵심은 밤에 에이전트가 일하게 하고 아침에 완성된 보고서를 받는 단일 루프를 만드는 것이다.
6. 6:56
   기능을 밤새 만들고, 프롬프트를 조립하는 법 기능 개발은 작업을 잘게 쪼개기보다, 모델이 리더처럼 판단할 수 있도록 사업 맥락과 트레이드오프를 최대한 많이 넣는 방향이 효과적이다. Slack, Notion, Jira, 코드베이스에서 배경을 모아 큰 프롬프트로 만들고, 테스트 선작성과 end-to-end 확인까지 포함시켜야 밤새 실행이 안정적으로 돌아간다.
7. 9:28
   검증, PR 정리, 그리고 아침 보고서 밤새 작업에는 리뷰 친화적 PR 분리, CI 통과, AI 코드 리뷰, 봇 코멘트 정리까지 포함되어야 아침에 바로 합칠 수 있다. 작업이 끝나면 trade-off와 수행 결과를 담은 보고서를 남기게 해, 사람이 잠든 동안에도 전체 스택이 준비되도록 해야 한다.
8. 11:16
   몇 개의 피드백 덤프로 기능을 상향식으로 개선하기 간단한 피드백 버튼과 JSON 덤프만 모아도 작은 데이터셋을 eval set으로 바꾸고, scoring function을 설계해 hill climbing을 돌릴 수 있다. 데이터가 적어도 과적합을 조심하라고 지시하면 꽤 괜찮게 최적화되며, 이 흐름은 내부 도구와 제품 품질 개선에 모두 재사용된다.
9. 13:47
   분류기를 밤새 학습시키기 모델 선택, 데이터 정리, 합성 데이터 추가, 여러 frontier model 조합, AWS sandbox에서의 학습·평가·폐기까지 한밤에 처리할 수 있다. 중요한 것은 생산 환경을 건드리지 않는 격리된 학습 경로를 주고, 아침에는 학습된 모델과 배포 방향까지 함께 받는 것이다.
10. 15:27
    작업 범위를 넓히기와 그것을 떠받치는 발판 이 방식이 가능한 이유는 코드 리뷰, agents.md hygiene, 신뢰할 수 있는 CI, feature flags, prototype branch 같은 조직적 발판이 이미 있기 때문이다. 동시에 PR은 테스트 전에 올리고 작고 읽기 쉬워야 하며, 리더가 이런 기준을 지켜야 팀 전체의 코드 품질 기준도 함께 올라간다.
11. 17:06
    읽지 않은 코드에 리뷰어를 추가하지 말 것 코드를 읽지 않은 상태에서 다른 리뷰어를 붙이는 일은 가장 위험한 습관이며, 결국 명백한 결함을 놓친 책임이 돌아온다. 직접 읽고 검토한 뒤에만 추가 리뷰를 붙여야 하며, 이것이 바쁜 일정 속에서도 신뢰를 유지하는 최소한의 원칙이다.

실무 인사이트

• 리더는 회의 사이의 자투리 시간을 빌드 시간으로 바꾸되, 핵심 경로보다 학습 가치가 큰 내부 도구·프로토타입·비전형 실험에 집중하는 것이 효율적이다.
• 밤새 에이전트를 돌릴 때는 프롬프트보다 검증 체계가 더 중요하므로, 테스트·CI·AI code review·아침 보고서를 한 묶음으로 설계해야 한다.
• 작은 피드백 덤프라도 반복적으로 모아 eval set으로 바꾸면 기능 개선과 모델 최적화를 같은 루프로 운영할 수 있다.