AI가 소프트웨어 엔지니어링을 어떻게 바꾸고 있는가 - Gergely Orosz와의 대담
📺 원본 영상: How AI is changing Software Engineering: A Conversation with Gergely Orosz, @pragmaticengineer 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-04-22 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연은 AI Engineer 컨퍼런스의 클로징 키노트 세션으로, Pragmatic Engineer 뉴스레터의 창립자이자 전 Uber 엔지니어링 매니저인 Gergely Orosz와의 심층 대담이다. 대형 테크 기업들 사이에서 빠르게 확산되고 있는 ‘토큰 맥싱(Token Maxing)’ 현상의 실태를 생생한 내부 증언으로 풀어내는 것으로 시작하여, AI 도구의 실질적인 생산성 효과에 대한 냉정한 평가, 소프트웨어 엔지니어 역할의 구조적 변화, 그리고 Uber·Shopify·Meta 같은 기업들이 내부적으로 추진 중인 AI 인프라 혁신까지 폭넓게 다룬다. 빠르게 변화하는 AI 도구 생태계 속에서 엔지니어 개인과 조직이 어떤 전략적 선택을 해야 하는지에 대한 현장 증언을 담고 있다.
1. 토큰 맥싱(Token Maxing) - 빅테크에서 벌어지는 기이한 새 문화
‘토큰 맥싱’이라는 표현은 Gergely에게도 불과 일주일 반 전에 처음 들렸을 정도로 새로운 현상이다. 그런데 그가 SNS에 이 내용을 올리자마자 Meta, Microsoft를 포함한 대형 테크 기업의 엔지니어들로부터 DM이 쏟아졌다. 각 회사마다 이유와 양상이 조금씩 다르지만, 공통된 패턴이 존재한다.
핵심은 AI 토큰 사용량이 측정·비교되기 시작했다는 것이다. Salesforce에서는 직원 개개인이 AI 관련 도구에 지출한 금액을 내부 툴에서 누구나 검색해볼 수 있도록 공개하고 있다. Meta에서는 토큰 사용량 리더보드가 운영되었고, 이 수치가 성과 평가의 데이터 포인트 중 하나로 활용되었다. 리더보드에서 토큰 사용량이 적은 저성과자는 “아예 시도조차 하지 않는다”는 신호로 읽히고, 반대로 토큰 사용량이 많은 고성과자는 “혁신하고 있다”는 증거로 인식된다는 것이다.
01:22 - 대형 기업에서의 AI 토큰 사용량 리더보드 및 성과 평가 연동 방식 설명
이러한 구조가 만들어낸 결과는 예상대로 우스꽝스럽다. 일부 엔지니어들은 문서를 직접 읽는 대신 에이전트에게 요약해달라고 요청한다. 에이전트가 제대로 된 답을 주지 못하더라도 토큰 수는 올라가기 때문이다. Microsoft 내부에서는 아무 의미 없는 코드를 자율 에이전트로 계속 생성해 토큰 수를 부풀리는 사례도 보고되었다. Salesforce는 한 달에 최소 $175 상당의 AI 도구 사용이라는 목표치를 설정하고 있어, 월초가 되면 엔지니어들이 할당량 채우기에 나선다.
03:53 - Salesforce의 월 최소 $175 AI 사용 목표치 및 토큰 맥싱 실태 설명
Gergely는 이 현상이 과거 ‘코드 라인 수(Lines of Code)‘로 엔지니어를 평가하던 시대와 본질적으로 같은 실수라고 비판한다. Velocity나 Pluralsight Flow 같은 초기 개발자 생산성 도구들이 코드 라인 수와 PR 수를 측정했을 때와 마찬가지로, 지표가 생기면 사람들은 반드시 그 지표를 최적화하기 시작한다. 차이가 있다면, 과거의 실수는 소규모 도구 업체들이 저질렀지만 지금의 실수는 Meta·Microsoft 같은 최상위 테크 기업들이 저지르고 있다는 점이다.
Coinbase의 경우는 더 극단적이다. CEO Brian Armstrong이 전사 이메일을 통해 AI 도구 사용을 일주일 안에 시작하지 않으면 직접 면담하겠다고 공지했고, 실제로 다음 주 토요일에 엔지니어 한 명을 해고했다. 기본 연봉만 400,000에 달하고 주식 보상까지 얹히는 고임금 직업에서 이러한 압박이 가해지니, 엔지니어들이 어떻게든 토큰 수를 맞추려 하는 것은 어쩌면 합리적인 반응이다. 이는 Gergely가 제시하는 흥미로운 비유인 LeetCode(리트코드) 방식과도 연결된다. 대형 테크 기업들은 수십 년간 실제 업무와 무관한 알고리즘 인터뷰를 고집해왔는데, 그 본질적인 이유는 “말도 안 되는 것을 묵묵히 해내는 사람”을 선발하기 위해서였다는 것이다. 토큰 맥싱도 같은 문화의 연장선으로 볼 수 있다.
Meta는 리더보드 관련 기사가 나오면서 여론이 나빠지자 결국 리더보드를 없앴다. 그러나 그 문화는 사라지지 않았다. 엔지니어들은 “리더보드는 없어졌지만 수치는 여전히 어딘가에 남아있을 것”이라는 불안감으로 계속 토큰 맥싱을 이어가고 있다.
2. AI는 실제로 생산성을 높이는가 - 엇갈리는 증거들
Gergely는 토큰 맥싱 열풍이 생겨난 배경에는 리더십의 압박이 있다고 설명한다. 약 6개월 전 암스테르담에서 열린 CTO급 만찬에서, ‘네덜란드의 Amazon’이라 불리는 어느 이커머스 기업의 CTO가 고민을 털어놓았다. 자기 회사 엔지니어들이 AI 도구에 회의적이어서 잘 사용하지 않는다는 것이었다. 당시는 최신 Claude 모델들이 출시되기 전이었고, 기존 코드베이스에 Cursor 같은 도구를 적용해도 효용이 미미했던 시기였다. 경험 많은 엔지니어들이 “이게 리팩토링도 못 해주고 버그도 못 찾는데 왜 써야 하냐”고 저항했던 시절이다.
반면 리더십은 Anthropic 같은 기업들이 자사 코드의 상당 부분을 Claude Code로 작성하고 있으며 매출도 급성장하고 있다는 소식을 접하며 “우리도 더 많이 써야 한다”는 압박을 느꼈다. 인과관계가 있는지 상관관계에 불과한지 불분명한 상황에서도, “AI를 많이 쓰면 좋은 일이 생기고, 쓰지 않으면 나쁜 일이 생긴다”는 논리가 조직 내에 자리잡게 된 것이다.
생산성 효과와 관련하여 진행자가 언급한 Meter 연구는 중요한 시사점을 준다. 이 연구에서 참여자들은 AI 도구를 사용하면서 자신이 20% 더 생산적이라고 느꼈지만, 실제 결과물을 측정해보니 오히려 평균 20% 생산성이 저하된 것으로 나타났다. 단, 이 연구는 표본이 30명으로 매우 작고, 실제로 AI를 통해 탁월한 성과를 낸 아웃라이어 한 명이 포함되어 있었다는 점에서 해석에 주의가 필요하다.
09:40 - Meter 연구 결과 - 체감 20% 생산성 향상 vs 실제 20% 생산성 저하
Gergely는 이 연구 결과를 참고하되, 단편적 결론을 내리기보다는 더 복잡한 진실이 있다고 본다.
진행자는 또 다른 관점을 제시한다. AI 도구가 개별 엔지니어의 생산성을 극적으로 높이지 못하더라도, 비개발자인 팀원들이 코드를 직접 작성할 수 있게 해준다면 조직 전체의 생산성은 향상될 수 있다. ‘서버리스 개발자(Serverless Developer)‘라는 표현을 빌려, 비기술 협업자들이 엔지니어를 기다리지 않고 스스로 코드로 작업을 완수할 수 있게 되는 것이 진정한 조직적 생산성 향상이라는 논리다. 이 관점에서 보면, Pull Request 단위의 개인 생산성 측정은 AI 시대의 진짜 가치를 포착하지 못하는 프레임일 수 있다.
3. AI를 잘 사용하기 위한 조건 - 직관과 반복의 역설
Gergely는 Simon Willison과의 대화를 소개하며 AI 도구 활용의 어려움을 설명한다. Simon Willison은 Hacker News에서 가장 많이 공유된 블로그 글을 꾸준히 써온 필자이자 프롬프트 인젝션(Prompt Injection) 연구로 유명한 Django의 핵심 기여자다. ChatGPT 출시 후 2년이 지난 시점에서도 그는 “이 도구를 잘 사용하는 데 아직도 감을 잡는 중”이라고 말했다. 워크플로를 계속 바꾸며 무엇이 효과적인지 탐색하고 있다는 것이다.
이 이야기가 중요한 이유는, AI 도구에는 일반적인 소프트웨어 학습과 근본적으로 다른 특성이 있기 때문이다. 프로그래머들은 보통 컴파일러가 어떻게 동작하는지, 어셈블리가 어떻게 작동하는지 이해하면 더 효율적인 코드를 작성할 수 있다고 생각한다. 그러나 AI의 경우, 어텐션 메커니즘(Attention Mechanism)이나 확률 분포 같은 이론적 기반을 깊이 이해해도 실제 도구를 더 잘 활용하는 데는 생각만큼 도움이 되지 않는다. 이해와 숙련이 분리된다는 점에서 소프트웨어 엔지니어들에게는 낯선 경험이다.
게다가 개인 수준에서 AI 활용에 능숙해지더라도, 팀 수준으로 확장하면 또다시 새로운 학습 곡선이 시작된다. AI와의 협업 패턴을 팀 전체로 전파하는 것은 별개의 도전이다. 그럼에도 Gergely는 “노력을 투자할수록 효과가 분명히 나타난다”는 사실은 변하지 않는다고 강조한다. 그리고 AI에서 가장 큰 가치를 뽑아내는 팀들의 공통점으로 두 가지를 꼽는다. 낮은 에고(Low Ego)와 기존 선입견(Prior)을 내려놓는 개방성이다. “선입견을 버려라(Leave your priors behind)“는 표현은 이 대담 전반에서 반복되는 핵심 메시지다.
4. 소프트웨어 엔지니어의 역할 변화 - 더 넓어지고, 더 작아지는 팀
AI가 소프트웨어 엔지니어의 역할을 바꾸고 있다는 것은 분명하지만, Gergely는 이 변화가 AI 때문에 갑자기 시작된 것이 아니라 이전부터 진행되어온 추세가 가속화된 것이라고 본다. 벤처 투자를 받는 스타트업들은 항상 소규모 팀으로 더 빠르게 움직여야 했기 때문에, 2010년대 중반부터 이미 엔지니어 한 명이 더 넓은 범위를 책임지는 구조를 채택해왔다.
이미 몇 년 전부터 테스터(Tester) 역할은 소프트웨어 엔지니어에 흡수되었고, DevOps 역할도 마찬가지다. 이제 제품(Product) 역할까지 엔지니어가 담당하는 ‘제품 엔지니어(Product Engineer)’ 트렌드가 빠르게 확산되고 있다. AI의 등장은 여기에 더해, 주니어 엔지니어에게도 시니어 수준의 사고와 비즈니스 이해를 요구하는 방향으로 기대치를 끌어올리고 있다. 결과적으로 엔지니어에게 요구되는 역량의 폭은 계속 넓어지고 있다.
13:40 - 소프트웨어 엔지니어 역할 변화 - 테스터·DevOps·제품 역할의 통합 과정
팀 규모 측면에서는 John Deere의 사례가 흥미롭다. 200년 역사를 가진 트랙터 제조업체인 John Deere에서도 엔지니어링 VP가 “Two-Pizza Team(아마존식 소규모 팀)이 이제 One-Pizza Team으로 줄어들고 있다”고 말했다고 한다. AI 도구를 통해, 예전에 소규모 팀이 하던 일을 더 작은 팀이 해내게 된 것이다. Gergely는 이미 자신이 “원 피자 팀”이라는 농담을 던지기도 했다. 이 변화는 전통적인 대기업에서도 현실로 나타나고 있다는 점에서 주목할 만하다.
5. “에이전트 관리 = 엔지니어링 매니저” - 과장된 비유의 문제점
청중에서 “이제 모두가 엔지니어링 매니저가 된다”는 주장이 언급되었다. 에이전트들을 지휘하는 역할이 엔지니어링 매니저의 역할과 유사하다는 논리다. Gergely는 엔지니어링 매니저를 직접 경험한 입장에서 이 비유를 단호하게 반박한다.
엔지니어링 매니저 자리가 어려운 이유는 기술적 판단 대신 ‘사람 문제(People Problem)‘를 다뤄야 하기 때문이다. 팀원들 사이의 갈등, 개인의 커리어 고민, 저성과자 관리 등이 매니저의 실제 일상이다. 그런데 AI 에이전트에게는 그런 문제가 없다. 에이전트들이 서로 갈등을 빚거나, 개인적인 고민으로 생산성이 떨어지거나, 퇴사를 고민하는 일은 없다. 따라서 에이전트 오케스트레이션(Agent Orchestration)은 매니저보다는 테크 리드(Tech Lead)나 숙련 엔지니어(Senior Engineer)의 역할에 가깝다는 것이 그의 주장이다.
DHH(David Heinemeier Hansson, Ruby on Rails 창시자)는 이 감각을 “메크 수트(Mech Suit)“라는 비유로 표현했다. 한 번에 일곱 가지를 동시에 처리할 수 있고, 훨씬 빠르게 움직이되 여전히 자신이 통제권을 쥐고 있다는 느낌이다. 반대편 극단에는 Mitchell Hashimoto(HashiCorp 창립자)가 있다. 그는 백그라운드 에이전트를 최대 하나만 유지하는 미니멀리스트 접근법을 택한다. 각자가 자신만의 에이전트 운용 패턴을 찾아가고 있는 초기 단계라는 것이 Gergely의 관찰이다.
매니저십과 다른 또 하나의 결정적 차이는 피드백 루프(Feedback Loop)의 속도다. 팀을 이끄는 매니저로서 전략적 결정의 결과를 확인하려면 수개월이 걸리지만, 에이전트와 작업하면 결정의 결과를 훨씬 빠르게 확인할 수 있다. 이는 학습과 개선의 사이클을 근본적으로 단축시키는 요인으로, 에이전트 기반 작업이 단순한 업무 위임이 아닌 새로운 종류의 엔지니어링 역량임을 시사한다.
6. 대기업들의 AI 인프라 혁신 - 눈에 보이지 않는 거대한 투자
외부에서 바라보면 Uber 같은 대형 테크 기업들이 AI에 막대한 투자를 한다고 하면서도 새로운 기능이나 제품이 별로 나오지 않는 것처럼 보인다. Gergely는 이유가 있다고 설명한다. 이 기업들은 지금 외부에 보이는 제품보다 내부 AI 인프라를 전면 재건하는 데 집중하고 있기 때문이다.
Uber의 경우, Cursor나 Claude Code 같은 상용 도구를 도입하는 것을 넘어서, 자사 모노레포(Monorepo)에 완전히 통합된 커스텀 백그라운드 코딩 에이전트를 자체 구축하고 있다. 자체 MCP(Model Context Protocol) 게이트웨이를 만들어 서비스 디스커버리(Service Discovery)와 연동하고, 온콜(On-call) 툴링과 내부 코드 리뷰 시스템도 AI 기반으로 리스크 분류까지 수행하도록 재편하고 있다.
18:09 - Uber의 내부 AI 인프라 구축 현황 - MCP 게이트웨이, 커스텀 코딩 에이전트
Airbnb, Intercom, Meta, Microsoft, 그리고 중견 기업들도 마찬가지 방향으로 나아가고 있다.
Gergely는 이 현상의 배경에 세 가지 이유가 있다고 분석한다. 첫째, 내부 AI 도구 구축은 상대적으로 위험이 낮은 방식으로 AI를 깊이 이해하고 실전 경험을 쌓을 수 있는 방법이다. 아직 완성도가 불확실한 AI 기능을 고객에게 출시하는 것보다 내부 인프라에서 먼저 검증하는 것이 훨씬 안전하다. 둘째, 수십 년의 코드가 쌓인 대형 코드베이스는 어떤 서드파티 AI 도구의 컨텍스트 윈도우(Context Window)에도 다 들어가지 않는다. 자체 RAG(Retrieval-Augmented Generation) 구현을 통해 서드파티 도구보다 더 나은 결과를 내는 것이 충분히 가능하다. 셋째, “AI”가 붙으면 예산을 받기 쉬운 시대라는 현실도 있다. 개발자 플랫폼 팀이 일반 인력 증원 요청을 하면 어렵지만, “에이전트 경험 팀”이라고 이름 붙이면 추가 인원을 쉽게 확보할 수 있다.
결론적으로, 지금 대형 테크 기업에 재직 중이라면 경쟁사를 포함한 다른 대형 기업들도 같은 종류의 인프라를 동시에 구축하고 있을 가능성이 높다. “MCP 게이트웨이를 아직 구축하지 않고 있다면 이미 뒤처지고 있는 것”이라는 Gergely의 말은 반은 농담이지만, 반은 진지한 현실 진단이다.
7. Shopify의 선제적 AI 전략 - 6개월의 차이가 만드는 것
대기업 AI 인프라 투자의 가장 설득력 있는 사례로 Shopify가 등장한다. Shopify는 2021년, GitHub Copilot이 아직 내부 테스트 단계일 때 전사 도입에 성공한 첫 번째 기업이다. 당시 엔지니어링 VP Farhan Thawar는 GitHub CEO Thomas Dohmke가 Copilot을 내부 개발 중이라는 소식을 접하고 직접 연락을 취했다. 그의 제안은 “구매하고 싶다”가 아니라 “3,000명의 솔직한 피드백을 제공하겠다”는 것이었다. 상업적 거래가 아닌 상호 이익의 파트너십 제안이었고, 이것이 받아들여져 Shopify는 시장 출시 1년 전부터 Copilot을 전사에 배포하게 되었다.
21:09 - Shopify의 GitHub Copilot 선제 도입 전략 - 경쟁사 대비 6개월 선도 확보
초기에는 순탄치 않았다. 도구가 아직 미숙했고, 적응 과정에서 상당한 혼란도 겪었으며, 비용 부담도 만만치 않았다. 그럼에도 Farhan의 전략적 판단은 단호했다. 이 혼란과 비용은 경쟁사보다 6개월 앞서는 것에 대한 대가이며, 그 6개월의 선도(Lead Time)가 충분히 그 모든 비용을 정당화한다는 것이다. 물론 이 전략이 모든 기업에게 합리적인 것은 아니다. 물리적 사업을 영위하는 기업이나 AI 속도전이 핵심이 아닌 업종이라면, 도구가 성숙해질 때까지 기다리는 것이 더 현명한 선택이다.
Farhan이 덧붙인 또 다른 이유도 주목할 만하다. AI 최신 도구를 자유롭게 사용할 수 없는 회사는 최고의 인재를 채용하기 어렵다는 것이다. “저 좋은 도구들을 쓸 수 없다면 어떻게 최고의 사람들을 채용할 수 있겠느냐”는 그의 말은, AI 도구 활용이 단순한 생산성 문제를 넘어 채용 경쟁력의 요소가 된 시대를 보여준다. 비용과 혼란을 감수하는 선제적 투자가 혁신성 및 채용 브랜딩 측면에서 복합적인 이익으로 돌아온다는 논리다.
8. Pragmatic Engineer의 탄생 - 위기에서 발견한 프로덕트-마켓 핏
Gergely는 뉴스레터의 탄생 과정도 간략하게 나눴다. Covid-19 팬데믹 시기 Uber의 대규모 구조조정으로 그의 팀이 해체되면서 사기가 바닥을 쳤다. 원래 계획은 책을 쓰고 Uber 내부에서 쌓은 노하우를 바탕으로 플랫폼 엔지니어링 스타트업을 창업하는 것이었다. 실제로 그 아이디어가 살아있었다면, AI Engineer 컨퍼런스 대신 “Platform Engineer” 컨퍼런스가 탄생했을 수도 있었다고 그는 농담처럼 말했다.
그 대신 그는 Uber를 떠난 지 1년 후, 실험적으로 뉴스레터를 시작했다. 소프트웨어 엔지니어링을 깊이 있게 다루는 글이 없다는 공백을 발견했고, 아무것도 발행하기 전에 자신 있게 Twitter에 올린 글 하나만으로 100명이 미리 연간 구독료를 납부했다.
24:29 - Pragmatic Engineer 프로덕트-마켓 핏 발견 - 발행 전 100명 유료 구독자 선납
6주 후에는 1,000명의 유료 구독자가 생겼는데, 그 구독료 수입이 마침 암스테르담에서의 Uber 기본 연봉과 맞아떨어졌다. Gergely는 이것을 프로덕트-마켓 핏(Product-Market Fit)의 신호로 받아들이고, 이후 2년간 오직 두 개의 아티클 작성에만 집중했다. 모든 인터뷰 요청, 협업 제안, 팟캐스트 출연을 거절하고 핵심에만 집중한 결과, Pragmatic Engineer는 수개월 만에 기술 분야 유료 뉴스레터 1위에 올랐고 이후 3년간 그 자리를 유지했다. 현재는 연구원 한 명을 더 합류시켜 두 명이 함께 운영 중이며, 1년 반 전부터는 팟캐스트도 시작했다.
마무리 / 핵심 정리
이 대담에서 Gergely Orosz가 전달하는 메시지는 하나의 방향으로 수렴한다. AI 도구는 분명히 작동하고 있지만, 그 효과를 제대로 끌어내기 위해서는 지표 게임(Token Maxing처럼)이 아니라 진정한 실전 사용이 필요하며, 여기에는 긴 시간과 반복적인 학습이 수반된다는 것이다.
대기업들이 내부에서 AI 인프라에 막대한 투자를 하는 것은 외부에서 보면 낭비처럼 보일 수 있지만, 코드베이스 규모, 선도 기간 확보, 실전 역량 내재화라는 세 가지 이유를 갖춘 합리적 선택이다. 소프트웨어 엔지니어의 역할은 더 넓어지고 팀은 더 작아지며, 에이전트와의 협업은 매니지먼트가 아닌 숙련된 기술 리더십에 가깝다. 그리고 이 모든 변화를 헤쳐나가는 데 가장 중요한 태도는, 기존의 선입견(Priors)을 내려놓고 열린 자세로 계속 배우는 것이다. 기술적 역량만큼이나 사고방식의 유연성이 중요한 시대를 요약하는 말이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | How AI is changing Software Engineering: A Conversation with Gergely Orosz |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-04-22 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.