우버의 2026년 AI 전략은 ‘개발자를 대체한다’는 단순한 이야기보다 더 현실적이다. 회사는 AI 지출을 늘리는 한편 채용은 덜 하는 방향으로 움직이고 있으며, CEO 다라 코스로샤히(Dara Khosrowshahi)는 자율 AI 에이전트가 우버 코드 변경의 약 10%를 만들어낸다고 말했다. 다만 이 코드는 저장소에 병합되기 전 사람이 검토한다 ^[10].

즉, 우버가 노리는 것은 무인 개발 조직이 아니다. 지금의 핵심은 신규 인력을 계속 늘리는 대신, 기존 직원 한 명이 더 많은 일을 처리하도록 만드는 ‘인력 효율화’다.

채용을 줄인다는 말의 의미: 감원보다 ‘증원 속도 조절’

우버가 말하는 AI 활용은 현재 단계에서 엔지니어를 전면 대체하는 모델이 아니다. 보도된 전략의 중심은 인력 증가 속도를 조절하면서 AI로 직원 처리량을 높이는 데 있다 ^[10]. 코스로샤히는 직원들이 AI를 활용해 산출량을 20%, 30%, 50%, 나아가 100%까지 높이길 원한다고 말했다 ^[10].

이렇게 되면 채용 계산법이 달라진다. 과거에는 더 많은 개발 역량이 필요할 때 사람을 더 뽑는 방식이 기본이었다. 이제는 그 일부를 코딩 에이전트, 개발자 도구, 워크플로 자동화, AI 연산 자원으로 보충할 수 있는지 먼저 따져볼 수 있다. 코스로샤히는 장기적으로 신규 엔지니어 채용의 일부를 AI 에이전트와 GPU로 대체할 가능성도 언급했다 ^[5]. 다만 현재 운영 방식은 여전히 사람이 검토하고 책임지는 구조에 가깝다 ^[10].

우버 엔지니어링 안에서 AI가 하는 일

가장 큰 변화는 AI가 단순 자동완성 도구에서 소프트웨어 개발 과정의 능동적인 참여자로 바뀌고 있다는 점이다. 우버 CTO 프라빈 네팔리 나가(Praveen Neppalli Naga)는 회사가 AI 코딩에 강하게 베팅하고 있으며, 우버 엔지니어의 95%가 매월 AI 도구를 사용하고, 내부 AI 에이전트가 주당 약 1,800건의 코드 변경을 만든다고 밝혔다 ^[13].

물론 이 숫자가 곧 ‘AI가 알아서 배포한다’는 뜻은 아니다. 핵심 통제 장치는 여전히 사람의 코드 리뷰다. 코스로샤히는 AI가 작성한 코드가 저장소에 추가되기 전에 직원들이 확인한다고 설명했다 ^[10].

우버의 개발 생산성 투자는 코드 생성에만 머물지 않는다. Developer Productivity Engineering 세션 설명에 따르면, 우버는 소프트웨어 개발 생애주기 전반에 AI를 적용해 개발자가 더 빠르게 품질 있는 결과물을 내도록 하는 데 투자하고 있다. 여기에는 대형 단일 코드 저장소인 모노레포에 맞춘 코딩 어시스턴트, 대규모 코드 마이그레이션을 위한 에이전트형 시스템, AI 기반 테스트와 코드 리뷰 워크플로가 포함된다 ^[14].

진짜 승부처는 ‘에이전트형 개발’

우버의 생산성 베팅은 통합개발환경(IDE)에서 몇 줄을 추천받는 수준을 넘어선다. 더 중요한 변화는 도구가 하나의 작업 단위를 받아 프로젝트 맥락을 읽고, 코드를 만들고, 때로는 리뷰 가능한 변경안까지 준비하는 ‘에이전트형 개발’이다.

개발자 뉴스레터 The Pragmatic Engineer의 내부 취재에 따르면, 우버 개발자의 84%는 에이전트형 코딩 사용자로 분류됐다. 이는 명령줄 기반 에이전트를 쓰거나, IDE에서 단순 탭 자동완성보다 더 에이전트적인 요청을 많이 하는 개발자를 뜻한다 ^[8]. 같은 보도는 IDE 기반 도구 안에서 생성되는 코드의 65~72%가 AI 생성 코드라고 전했다 ^[8].

다만 이 수치와 코스로샤히가 말한 ‘코드 변경의 약 10%’는 같은 지표가 아니다. 10%는 자율 에이전트가 만들어낸 코드 변경 비중을 말하고, 65~72%는 IDE 도구 내부에서 생성된 코드의 비중을 가리킨다 ^[8][10]. 실무적으로 보면, AI가 초안을 잡는 코드의 범위는 넓어지고 있지만, 최종 병합 변경분 가운데 자율 에이전트에 귀속되는 비중은 별도로 봐야 한다.

비용은 사라지지 않고 형태가 바뀐다

AI가 채용 필요를 줄일 수 있는 논리는 간단하다. 같은 인력으로 더 많은 기능을 출시하고, 테스트하고, 수정할 수 있다면 회사는 개발 산출량을 늘리면서도 인원 증가 속도는 낮출 수 있다 ^[10].

하지만 비용이 없어지는 것은 아니다. 사람에게 쓰던 비용의 일부가 도구, 에이전트, 연산 자원, 사용량 기반 AI 서비스 비용으로 옮겨간다. 우버에서 Anthropic의 코딩 도구 Claude Code 사용량이 급증해 2026년 AI 코딩 예산을 예상보다 빨리 소진했다는 보도도 있었고, 우버가 Claude Code와 Cursor 같은 도구를 쓰고 있다는 보도도 나왔다 ^[2][3].

이 예산 관련 보도만으로 우버의 전체 AI 지출 구조를 단정할 수는 없다. 그래도 방향은 분명하다. 소프트웨어 개발 역량은 점점 ‘사람 몇 명’만의 문제가 아니라, 사람·에이전트·개발 도구·컴퓨팅 자원을 어떻게 섞느냐의 문제가 되고 있다.

코딩 밖으로 넓어지는 AI 활용

우버는 오래전부터 차량 호출 요금 책정과 운전자-승객 매칭 같은 영역에 AI를 활용해왔다 ^[20]. 최근에는 생성형 AI와 에이전트형 AI가 고객 지원, 운전자 온보딩, 엔지니어링 개발 생애주기 일부에도 적용되며, 일부 운영 워크플로에서 수작업 개입을 줄이고 있다는 보도도 나왔다 ^[11].

이 지점이 중요한 이유는 생산성 향상이 단지 개발자가 코드를 더 빨리 쓰는 문제에 그치지 않기 때문이다. AI가 내부 서비스 문제를 더 빠르게 진단하고, 고객 지원 절차를 간소화하고, 온보딩 단계의 반복 업무를 줄인다면 병목은 개발팀 바깥에서도 줄어들 수 있다 ^[11].

엔지니어에게 주는 신호

현재까지의 증거는 ‘엔지니어 없는 개발 조직’이 아니라 ‘감독형 AI 엔지니어링 모델’을 가리킨다. 우버는 에이전트가 더 많은 초안과 변경안을 만들게 하고 있지만, AI 작성 코드는 병합 전 사람이 검토한다 ^[10]. 공개된 수치 역시 실제 생산성 향상이 몇 %인지 감사된 결과라기보다는, AI 도구의 도입률과 코드 생성·변경 활동을 보여주는 성격이 강하다 ^[8][10][13].

따라서 실무자 관점의 결론은 비교적 분명하다. 아키텍처 판단, 리뷰, 디버깅, 운영 품질, 책임 있는 의사결정은 여전히 엔지니어의 몫이다. 다만 초안 작성, 반복 구현, 대규모 코드 이전, 테스트 보조, 코드 리뷰 일부는 AI 시스템으로 넘어갈 여지가 커지고 있다 ^[10][14].

채용 측면에서 압박을 받는 쪽은 기존 엔지니어의 존재 자체라기보다 ‘추가로 몇 명을 더 뽑아야 하는가’라는 질문이다. 우버는 AI 생산성 향상이 실제 업무 흐름에서 유지된다는 전제 아래, 이전보다 적은 신규 채용으로도 더 많은 엔지니어링 역량을 확보하려는 실험을 하고 있다 ^[10].