Steve Yegge는 실리콘밸리에서 독특한 위치를 차지하는 인물이다. Google과 Amazon에서 수십 년간 일한 베테랑 엔지니어이자, 기술 블로그계의 전설적인 필자다. 2000년대 초반 Amazon 내부 SOA 전환에 대한 Jeff Bezos의 메모를 폭로(?)한 "Stevey's Google Platforms Rant"로 유명하다. 그런 그가 AI에 대해 흥미로운 전환을 했다. 한때 AI 회의론자였던 Yegge가 이제는 "AI가 소프트웨어 엔지니어링을 근본적으로 바꾼다"고 주장한다. 그의 핵심 주장들을 짚어본다.

 

50% Dial: 엔지니어 절반을 줄여라

 

Yegge의 가장 도발적인 주장이다. 그는 조직이 엔지니어의 절반을 줄이고, 남은 절반이 AI 도구를 최대한 활용하면 오히려 전체 생산성이 올라간다고 말한다.

 

이게 단순한 비용 절감 논리가 아니라는 점이 중요하다. Yegge의 논점은 이렇다:

 

  1. 큰 팀은 커뮤니케이션 오버헤드가 기하급수적으로 증가한다 (브룩스의 법칙)
  2. AI 도구는 개인의 생산성을 수 배로 증폭시킨다
  3. 적은 인원 + AI = 더 적은 회의, 더 적은 조율, 더 빠른 의사결정
  4. 결과적으로 절반의 인원이 이전 전체보다 더 많이 산출한다

 

마치 도로에 차가 절반으로 줄면 교통 체증이 사라지고 모든 차의 평균 속도가 올라가는 것과 같다. 엔지니어 수를 줄이는 것이 아니라, 소통 병목을 제거하는 것이 핵심이다.

 

NOTE 잠깐! 이 용어는?
브룩스의 법칙: "지연되는 소프트웨어 프로젝트에 인원을 추가하면 더 늦어진다." 팀 구성원 수가 n명이면 커뮤니케이션 채널은 n(n-1)/2로 증가한다. 10명이면 45개, 20명이면 190개의 채널이 생긴다.

 

AI 도입 8단계(8 Stages)

 

Yegge는 개인과 조직의 AI 도입 수준을 8단계로 분류한다.

 

단계설명특징
1-2최소 사용간헐적 자동완성, 가끔 챗봇 질문
3-4적극적 보조AI 페어 프로그래밍, 코드 리뷰 보조
5-6에이전트 위임독립적 태스크를 AI 에이전트에 위임
7-8다중 에이전트 관리10개 이상의 에이전트를 동시 오케스트레이션

 

대부분의 엔지니어가 1-3단계에 머물러 있다. Yegge는 5단계 이상에 도달해야 진정한 생산성 도약이 일어난다고 주장한다. 중요한 건, 이 전환이 갑자기 일어나는 것이 아니라 단계적으로 올라가야 한다는 점이다. AI에게 전체 기능 구현을 맡기기 전에, 먼저 테스트 작성을 맡겨보고, 리팩토링을 맡겨보고, 점진적으로 신뢰를 쌓아야 한다.

 

드라큘라 효과: 100배 생산성의 대가

 

"드라큘라 효과"는 Yegge가 명명한 현상으로, AI를 집중적으로 사용하면 짧은 시간에 엄청난 생산성 스파이크를 경험하지만, 그 직후 극심한 정신적 피로가 찾아온다는 것이다.

 

NOTE 잠깐! 이 용어는?
드라큘라 효과: 드라큘라가 낮에 힘을 쓰면 급격히 약해지는 것처럼, AI와의 고강도 협업 후 생산성이 급락하는 현상이다. Yegge가 자신의 경험을 바탕으로 명명했다.

 

이유는 명확하다. AI가 코드를 생성하는 속도는 빠르지만, 그 코드를 이해하고, 검증하고, 통합하는 것은 여전히 인간의 뇌가 담당한다. AI가 10배 빠르게 코드를 쏟아내면, 인간의 뇌는 10배 빠르게 판단을 내려야 한다. 이건 마라톤이 아니라 스프린트를 연속으로 뛰는 것과 같다.

 

Yegge는 이 현상을 겪은 후, 자신의 작업 패턴을 근본적으로 바꿨다고 한다.

 

하루 생산적 시간: 3시간 제한

 

드라큘라 효과의 대응책으로, Yegge는 하루 진정한 생산적 시간을 3시간으로 제한할 것을 권고한다. 얼핏 적어 보이지만, AI와 함께하는 3시간은 이전의 8시간보다 더 많은 아웃풋을 낸다는 것이 그의 주장이다.

 

이 3시간 동안:

  • AI 에이전트에게 명확한 태스크를 할당한다
  • 생성된 결과물을 빠르게 검토하고 피드백한다
  • 아키텍처 결정과 방향 설정에 집중한다
  • 나머지 시간은 학습, 문서화, 비동기 소통에 할당한다

 

핵심은 양이 아니라 질이다. AI 시대에 엔지니어의 가치는 "얼마나 많은 코드를 치느냐"가 아니라 "얼마나 좋은 판단을 내리느냐"에 있다.

 

대기업은 "좀비 기업"

 

Yegge의 가장 신랄한 주장이다. 그는 대기업이 구조적으로 AI 혁신을 받아들일 수 없다고 본다.

 

이유를 정리하면:

  • 관료주의: 새로운 AI 도구 도입에 6개월의 보안 심사와 승인 프로세스가 필요하다
  • 레거시 시스템: 수십 년 된 코드베이스와 프로세스가 새로운 방식의 도입을 방해한다
  • 인센티브 구조: 관리자는 팀 규모가 줄어드는 것을 원하지 않는다 (50% Dial의 조직적 저항)
  • 위험 회피 문화: "AI가 생성한 코드를 프로덕션에?"이라는 근본적 거부감

 

반면 스타트업은:

  • 의사결정이 빠르다
  • 레거시가 없다
  • 생존을 위해 효율을 극대화해야 한다
  • AI 네이티브 워크플로우를 처음부터 구축할 수 있다

 

Yegge는 이런 구조적 차이 때문에 앞으로 모든 의미 있는 혁신은 스타트업에서 나올 것이라고 단언한다. 대기업은 이미 만들어진 혁신을 인수하는 역할로 전락한다는 것이다.

 

물론 이건 극단적인 시각이다. 실제로는 대기업 내에서도 AI를 적극 도입하는 팀과 그렇지 않은 팀이 공존한다. 다만 Yegge가 지적하는 구조적 병목은 실재한다. Google에서 새로운 내부 도구를 도입하려면 얼마나 많은 LGTM이 필요한지 아는 사람은 고개를 끄덕일 것이다.

 

엔지니어가 지금 해야 할 것

 

Yegge의 전망을 종합하면, 엔지니어에게 주는 시사점은 분명하다.

 

1. AI 도구를 지금 당장, 깊이 사용하라. 자동완성 수준에 머물지 말고, 에이전트 레벨까지 올라가야 한다. Claude Code, GitHub Copilot Workspace, Cursor — 도구는 이미 충분하다.

 

2. "코드 작성자"에서 "판단자"로 역할을 전환하라. AI가 코드를 쓰는 시대에 엔지니어의 가치는 아키텍처 설계, 트레이드오프 판단, 코드 리뷰 능력에 있다.

 

3. 에너지 관리를 배워라. 드라큘라 효과는 실재한다. 고강도 AI 협업 세션과 저강도 학습 시간을 의도적으로 배분해야 한다.

 

4. 작은 팀의 파괴력을 믿어라. 2-3명이 AI와 함께 만든 프로덕트가 20명 팀의 산출물을 넘어서는 사례가 이미 나오고 있다.

 

마무리

 

Yegge의 주장이 전부 맞을지는 알 수 없다. "50% Dial"은 현실적으로 수많은 법적, 윤리적, 조직적 문제를 동반한다. 하지만 그가 짚는 방향은 부정하기 어렵다. AI 도구의 능력은 매달 눈에 띄게 향상되고 있고, 이를 깊이 활용하는 소수와 그렇지 않은 다수 사이의 생산성 격차는 점점 벌어지고 있다.

 

Yegge 자신이 AI 회의론자에서 옹호론자로 전환한 것처럼, 변화는 실제로 도구를 써보는 사람에게 먼저 보인다. 관망하는 대신 직접 부딪혀보는 것이 가장 확실한 전략이다.