AI agent(목표를 받아 여러 단계의 작업을 수행하는 AI)가 늘어나면 엔지니어의 일은 코드를 직접 작성하는 데서 작업을 설계하고 결과를 검토하는 쪽으로 옮겨갈 수 있습니다. NVIDIA 최고경영자 Jensen Huang은 미래의 엔지니어 한 명이 수백 개의 agent를 관리할 것으로 내다봅니다. 이는 현재의 일반적인 업무 모습을 설명하는 수치가 아니라 전망입니다. 지금 살펴볼 수 있는 것은 agent가 기존 도구와 연결되는 방식, 그리고 그 작업을 맡기고 확인할 때 필요한 조건입니다.
수백 개의 agent보다 먼저 정할 것
Jensen Huang이 제시한 엔지니어의 역할은 아이디어를 소프트웨어 구조와 명세로 바꾸고, 작업을 agent에게 나누어 맡긴 뒤, 산출물이 품질 기준에 맞는지 판단하는 것입니다. 그의 전망에서는 연산 자원을 늘릴수록 너무 어렵거나 오래 걸리거나 많은 인력이 필요했던 작업의 제약이 줄어듭니다. 그렇더라도 무엇을 만들지 정하고 결과를 승인하는 일은 사람에게 남습니다.
그는 AI 활용 규모를 설명하며 다음과 같은 가상 예산을 들었습니다.
| 가정한 항목 | 금액 |
|---|---|
| 엔지니어의 연봉 | $50만 |
| 활용이 지나치게 적다고 본 연간 token 비용 | $5천 |
| 적극적인 활용에 필요한 최소 연간 token 비용으로 제시한 금액 | $25만 |
여기서 token은 AI 모델이 처리하는 텍스트의 단위로, 모델 이용 비용도 이 단위로 매겨집니다. 이 금액은 모든 조직이 따라야 할 예산 기준이 아니라, 엔지니어의 생산성을 논할 때 AI 연산을 핵심 자원으로 봐야 한다는 Jensen Huang의 주장을 설명하는 가정입니다. 비용을 늘리는 일만으로 좋은 결과가 보장되는지는 별개의 문제입니다. 어떤 업무를 위임하고 무엇으로 합격 여부를 판단할지 정해야 한다는 뜻으로 읽는 편이 적절해 보입니다.
▲ 작업 위임과 검토
현재의 도구 연결은 어디까지 왔나
미래의 agent 관리 업무를 이해하려면 이미 제공되는 연결 방식부터 볼 필요가 있습니다. OpenClaw는 컴퓨터에서 실행하는 오픈소스 개인용 AI 비서로, 대화가 끝난 뒤에도 기억을 유지하고 메시지 앱과 연결됩니다. 운영체제에 접근해 파일을 편집하거나 여러 단계의 작업을 수행할 수도 있습니다. 이는 agent가 답변만 작성하는 것이 아니라 기존 작업 환경에서 실제 동작을 맡는 사례입니다.
연결 대상은 개인용 앱에 그치지 않습니다. MCP(Model Context Protocol, AI 모델과 외부 소프트웨어를 연결하는 규약)를 활용하면 모델이 도구의 기능을 작업 과정에 끌어올 수 있습니다. Blender 같은 3D 소프트웨어와 Unreal Engine, Godot, Unity 같은 게임 엔진에서도 이러한 연결이 확산되고 있습니다. 다만 도구에 연결할 수 있다는 사실과 완성된 결과를 검토 없이 사용할 수 있다는 뜻은 다릅니다. 특히 운영체제나 파일에 접근하는 agent라면 맡길 작업과 접근 범위를 함께 정해야 합니다.
빠른 실행 사례와 전체 작업 기간은 다릅니다
한 기업가는 Claude와 agent 시스템을 이용해 기업용 소프트웨어 묶음을 90분 만에 교체했다고 설명했습니다. 짧은 실행 시간은 주목할 만하지만, 이를 아무 준비 없이 같은 작업을 끝낼 수 있다는 뜻으로 받아들이기는 어렵습니다. 데이터 정리, 외부 서비스 설정, 작업 흐름과 기반 환경 구축에 앞서 수주 또는 수개월이 필요할 수 있기 때문입니다. 실행에 걸린 시간과 실행이 가능하도록 준비한 시간은 구분해야 합니다.
agent에게 작업을 맡기는 과정에도 반복이 들어갑니다. prompt(모델에 주는 작업 지시)에 소프트웨어 구조, 작업 범위, 성공 기준을 구체적으로 적고, 나온 결과를 살펴 지시를 조정해야 합니다. 복잡한 작업에서는 연산 비용과 대기 시간이 발생하며, 예상 밖의 문제가 생기면 개발자가 코드를 확인하고 고쳐야 합니다. 따라서 ‘90분 만에 교체’ 같은 실행 시간보다는 사전 준비와 반복 검토까지 포함한 작업 방식이 실무에 더 중요한 기준으로 보입니다.
▲ 개발 도구 연결
기존 소프트웨어는 검토의 자리로 남습니다
agent가 널리 쓰이면 기존 개발·설계 도구의 쓰임이 줄어들 것이라는 예상도 가능합니다. Jensen Huang의 전망은 반대 방향입니다. 사람만 사용하던 도구를 여러 agent가 계속 호출하면 소프트웨어 이용이 늘어날 수 있다는 것입니다. Synopsys와 Cadence의 설계 도구, Blender 같은 작업 환경은 agent가 산출물을 만들 때 활용할 뿐 아니라 엔지니어가 결과를 확인하는 자리이기도 합니다.
이 관점에서 중요한 변화는 새 모델을 하나 더 도입하는 일이 아니라, agent의 작업이 기존 도구 안에서 이어지고 사람이 그 결과를 검증할 수 있도록 연결하는 일입니다. 엔지니어가 agent를 ‘관리한다’는 말도 작업을 많이 배분하는 것만이 아니라, 아이디어부터 검토까지 이어지는 흐름을 책임진다는 의미에 가깝습니다.
먼저 작업과 검토 기준을 설계합니다
수백 개의 agent를 운영하는 미래를 당장 목표로 삼을 필요는 없습니다. 현재의 도구를 활용한다면 먼저 다음 순서로 업무를 정리할 수 있습니다.
- 만들려는 결과를 명세로 쓰고, agent에게 맡길 작업을 구분합니다.
- 작업에 필요한 데이터와 소프트웨어 연결을 준비하고, 접근 범위를 정합니다.
- 기존 도구에서 확인할 품질 기준을 정한 뒤, 결과에 맞춰 지시를 수정합니다.
핵심은 agent의 수나 token 지출액 자체가 아닙니다. 현재의 연결 도구는 업무를 위임할 수 있는 범위를 넓혀 주고, 수백 개의 agent를 관리한다는 전망은 그에 따라 엔지니어의 설계·조율·검토 책임이 커질 가능성을 보여 줍니다.