Legora CTO: 코드가 싸진 뒤 병목은 어디인가: 20VC

Legora CTO는 2026년 엔지니어링 조직이 2024년과 완전히 다르다고 봄. Claude Code, Cursor, Pi 같은 AI tooling 때문에 각 엔지니어가 훨씬 더 많이 ship할 수 있기 때문
코드 작성은 이제 가장 큰 병목이 아님. 새 병목은 무엇을 만들지 정하는 product work와, AI가 만든 코드를 어떻게 review할지임
Legora에서는 Claude와 Cursor가 코드 기여량 최상위에 있고, AI가 만든 코드가 이미 50%를 넘는다고 언급함
하지만 token usage leaderboard를 만들면 token maxing, 즉 많이 쓰는 척하려고 토큰만 태우는 문제가 생김. Legora CTO는 사용량보다 output과 효율을 보상해야 한다고 봄
20VC 인터뷰. Harry Stebbings가 Legora CTO와 AI 시대 engineering org, code review, PM, design, hiring, token spend를 묻는 대화

코드가 싸지면 무엇이 병목이 되나?

Legora CTO는 소프트웨어 개발을 세 단계로 나눔. 첫째, 고객의 pain과 dream을 제품으로 바꾸는 product work. 둘째, 실제 코드를 쓰는 build 단계. 셋째, review하고 merge하는 단계
과거에는 두 번째 단계, 즉 코드를 얼마나 빨리 쓰느냐가 병목이었음
지금은 Claude Code, Cursor 같은 도구 때문에 코드 작성 비용이 크게 내려감
그러면 자연스럽게 양쪽 끝이 병목이 됨. “무엇을 만들지”를 더 빨리 정해야 하고, “이 코드가 시스템에 어떤 영향을 주는지”를 더 잘 검토해야 함
그래서 PM은 고객과 더 많이 이야기하고, 사용자의 요구와 회사의 전략을 더 잘 합성해야 함
엔지니어는 단순히 코드 타이핑을 많이 하는 사람이 아니라, 시스템이 어떤 방향으로 가야 하는지 판단하는 사람이 되어감

AI code review는 왜 아직 부족한가?

Legora도 AI review bot을 쓰고 있음. security reviewer, specialized reviewer처럼 여러 bot이 AI coder와 서로 주고받으며 코드를 다듬는 구조가 생김
하지만 CTO는 현재 review tool이 충분하지 않다고 봄
이유는 단순히 “이 줄이 맞나”를 보는 것이 진짜 review가 아니기 때문
중요한 review는 시스템 아키텍처, 안정성, 보안 경계, 장기적인 설계 방향에 대한 판단임
코드 diff 전체를 사람이 다 보는 방식은 점점 비효율적이지만, 전략적 trade-off가 있는 변경은 여전히 사람이 봐야 함
그래서 그는 review 문제를 푸는 스타트업을 만들라고 말할 정도로 이 영역을 큰 기회로 봄

과거 병목	AI 이후 병목
코드를 빨리 쓰기	무엇을 만들지 정하기
사람이 모든 PR 읽기	위험한 변경만 잘 골라 review하기
개발자 도구 세팅	agent가 잘 일하는 환경 만들기
기능별 디자인 회의	제품 전체 taste와 design language 유지
AI 사용량 늘리기	output과 효율을 실제로 높이기

미래 엔지니어는 무엇을 하나?

CTO는 미래 엔지니어가 코드를 타이핑하기보다 시스템 설계 한 단계 위에서 일할 것이라고 봄
어떤 module을 재사용 가능하게 만들지, 어느 지점에 투자하면 전체 시스템이 안정되는지, 어떤 guardrail을 기계적으로 강제할지를 판단해야 함
또 하나의 새 역할은 agent를 잘 일하게 만드는 meta engineering임
과거 developer experience 팀이 lint, local setup, CI를 개선해 개발자를 빠르게 만들었다면, 이제는 agent experience를 개선해야 함
Legora는 자체 background coding agent를 만들고, 엔지니어 한 명이 여러 agent를 동시에 돌릴 수 있게 함. local dev setup, browser, iteration loop, custom review agent까지 개발자 경험 팀이 담당함
CTO는 이 팀을 더 일찍 만들지 않은 것을 후회한다고 말함. 엔지니어 생산성이 10배 올라가면, 모두를 20% 더 효율적으로 만드는 팀의 가치도 훨씬 커지기 때문

token maxing은 왜 위험한가?

기업들이 “AI를 잘 쓰자”며 token usage leaderboard를 만들고, 성과 평가에서 token usage를 언급하는 경우가 있음
CTO는 이 방식이 token maxing을 만든다고 봄. 사람들이 실제 output이 아니라, 많이 쓰는 척하려고 토큰을 태우기 때문
좋은 방식은 hack day, demo, 내부 공유를 통해 누가 실제로 더 효과적으로 일하는지 보여주는 것임
보상 기준도 “AI를 얼마나 많이 썼나”가 아니라 “얼마나 더 좋은 output을 냈나”여야 함
token budget은 결국 opportunity cost 문제임. 경쟁이 치열하고 더 빨리 ship하는 가치가 크다면 많은 토큰을 쓰는 게 맞을 수 있음
다만 model routing과 limits가 중요해짐. 모든 일을 가장 비싼 모델에 맡기는 게 아니라, 작업별로 latency, performance, cost를 나눠 최적 모델을 써야 함

token maxing이 뭔가요?

AI를 실제로 잘 쓰는 게 아니라, 많이 쓰는 것처럼 보이기 위해 토큰 사용량만 늘리는 행동임. 사용량 leaderboard나 평가 지표가 잘못 잡히면 사람들이 output이 아니라 token burn을 최적화할 수 있음.

AI code review가 사람 review를 대체하나요?

일부는 대체할 수 있지만, 아직 완전하지 않음. 반복적이고 명확한 review는 AI가 맡을 수 있지만, 시스템 아키텍처, 보안 경계, 장기 설계 방향 같은 판단은 사람이 봐야 한다는 입장임.

PM도 이제 코딩해야 하나요?

PM이 prototype을 만들어 handover cost를 줄이는 건 유용함. 하지만 Legora처럼 product work가 병목인 회사에서는 PM이 코딩에 시간을 많이 쓰면 고객 이해와 요구 합성이라는 더 중요한 일을 놓칠 수 있음.

1인기업 관점

결국 code gen, content gen의 cost가 0으로 수렴하면 만드는 것 자체는 점점 덜 중요해지는 듯함. 그때 남는 건 고객관리, distribution, 그리고 무엇을 만들고 무엇을 안 만들지 판단하는 메타인지인 것 같음. 1인기업도 token을 많이 쓰는 것보다, 고객과 시장을 더 잘 읽고 쓸데없는 기능을 안 만드는 쪽이 더 큰 병목일 듯함.

Legora CTO: 코드가 싸진 뒤 병목은 어디인가: 20VC (youtube.com) ↗