에이전트에게 코드를 맡기는 사람은 많아졌습니다. 그런데 “이 작업엔 얼마나 맡겨도 되는가”라는 질문에 선뜻 답할 수 있는 사람은 많지 않습니다. 다들 감으로 판단하고 있는 셈이죠.

구글에서 14년간 Chrome과 Gemini, Cloud AI 엔지니어링을 이끈 Addy Osmani가 최근 이 질문에 답을 시도했습니다. 자율성을 하나의 잣대가 아니라 두 개의 축으로 나누고, 이를 6단계로 정리한 프레임을 제시한 겁니다. 이어 발표한 글에서는 이 시대에 개발자가 정말 지켜야 할 커리어 원칙까지 다뤘습니다.

출처: Agentic Autonomy Levels – Addy Osmani

한 줄 사다리로는 부족해진 이유

지금까지 에이전트의 자율성을 재는 방식은 대체로 하나의 사다리였습니다. 아래는 AI를 거의 안 쓰는 상태, 위로 갈수록 AI에게 더 많이 맡기는 식이죠. Steve Yegge가 제시한 이 사다리는 “내가 지금 얼마나 AI 네이티브한가”를 가늠하는 괜찮은 지표였습니다.

문제는 에이전트를 동시에 여러 개 돌리는 능력이 별도의 스킬로 떠올랐다는 점입니다. 한 개의 에이전트를 얼마나 멀리 보내는가와, 몇 개의 에이전트를 동시에 조율하는가는 서로 다른 질문입니다. 한 줄짜리 사다리로는 이 둘을 함께 담을 수 없습니다.

그래서 Osmani는 두 축을 분리합니다. 하나는 에이전시(agency), 한 에이전트가 얼마나 스스로 판단하고 멀리 나아가는가입니다. 다른 하나는 오케스트레이션(orchestration), 몇 개의 에이전트가 동시에 돌아가고 누가 이들을 조율하는가입니다.

여섯 단계로 나눈 자율성

이 두 축을 합쳐 아래에서 위로 오르는 여섯 단계가 만들어집니다. 크게 보면 세 시기로 묶입니다. 처음엔 사람이 운전석에 있고 에이전트는 거들 뿐인 시기, 다음은 에이전트가 정해진 과업을 주도하되 사람이 옆에서 검증하는 시기, 마지막은 오케스트레이션 시기로 시스템이 일을 굴리고 사람은 예외 상황에만 개입합니다.

레벨 0은 자동완성 수준의 제안입니다. 채택 여부는 전부 사람이 결정합니다. 레벨 1은 에이전트가 실제로 코드를 고치거나 명령을 실행하되, 실행 전에 매번 승인을 받습니다. 대부분의 사람이 지금 서 있는 기본 위치입니다.

레벨 2부터는 무게중심이 옮겨갑니다. 명확한 목표와 완료 기준을 정해 과업 하나를 통째로 맡기고, 사람은 옆에서 개입할 수 있지만 대체로 손을 뗍니다. 검증도 사람이 매번 들여다보는 대신, 테스트 통과 여부나 타입 체크 같은 증거로 옮겨갑니다.

레벨 3은 목표 자체를 던지는 단계입니다. “이 페이지의 로딩 시간을 1초 밑으로 줄여줘”처럼 측정 가능한 조건만 주면, 에이전트가 계획하고 시도하고 테스트하고 검토하는 과정을 스스로 반복하다 조건을 만족하면 멈춥니다. 목표가 막연하면 이 단계는 작동하지 않습니다.

레벨 4는 여러 에이전트를 동시에 돌리는 병렬 위임입니다. 여기서 가장 큰 병목은 일을 어떻게 쪼개느냐입니다. 겹치는 영역을 여러 에이전트에 동시에 맡기면 병렬로 일한 게 아니라 merge 충돌과 중복 작업만 늘어납니다.

레벨 5는 관리자 역할을 하는 에이전트가 트리거(새 이슈, 정해진 시각 등)에 따라 깨어나 작업자 에이전트들에게 일을 나누고, 진행 상황을 검증하고, 실패하면 재시도하거나 더 유능한 에이전트나 사람에게 넘기는 단계입니다. 이슈 트래커나 백로그가 입력이고, 완료된 작업물이 출력인 일종의 공장인 셈입니다.

자율성을 결정하는 세 가지 질문

몇 단계를 쓸지는 작업의 위험도와 되돌리기 쉬운 정도가 정합니다. Osmani는 어떤 시스템이 실제로 높은 자율성을 감당할 준비가 됐는지 판단하려면 이 세 질문을 던져보라고 말합니다.

잘못됐다는 걸 얼마나 빨리 알 수 있는가. 그 실수를 얼마나 깔끔하게 되돌릴 수 있는가. 그리고 옳았다는 걸 무엇으로 증명할 수 있는가.

세 질문 모두에 대한 답이 “빨리 알 수 없다”, “되돌리기 어렵다”, “에이전트의 요약을 믿는 수밖에 없다”라면, 그건 높은 자율성이 아니라 그냥 방치입니다. 결제 시스템 리팩터링처럼 테스트가 탄탄하고 롤백 경로가 확실한 작업은 훨씬 높은 자율성을 감당할 수 있지만, 근거 자료가 부실한 문서 자동화 작업은 그럴 수 없습니다. 자율성의 수위는 작업의 이름이 아니라 검증 체계가 정해야 한다는 겁니다.

Osmani는 여기에 빠지기 쉬운 네 가지 함정도 짚습니다. 자율성 수치를 능력의 증표처럼 여기고 필요 이상으로 밀어붙이는 것, 승인 피로 때문에 지나치게 넓은 권한을 그냥 내주는 것, 에이전트가 스스로 정리한 요약을 검토 자체로 착각하는 것, 그리고 에이전트를 여러 개 띄워놓고도 결국 모든 의존관계를 사람이 일일이 손으로 조율하는 것입니다.

정답 있는 일은 AI가 다 가져간다

여기서 Osmani는 자연스럽게 다음 질문으로 넘어갑니다. 에이전트가 이만큼 일을 가져간다면, 사람에게는 뭐가 남을까요.

그가 내놓은 답은 단순합니다. AI는 답이 정해진 일에는 금방 능숙해집니다. 학교 다닐 때 풀던 문제들이 다 그랬듯, 정답이 있으면 채점도 자동화도 쉽습니다. 반면 커리어에서 진짜 남는 부분은 답이 없는 영역입니다. 무엇을 만들지 고르고, 그게 잘 만들어졌는지 판단하는 일이죠.

출처: The Agent-Era Career – Addy Osmani

Osmani는 같은 문제집을 똑같은 에이전트로 풀게 했는데도 학생마다 결과가 크게 갈리는 걸 지켜본 경험을 예로 듭니다. 차이는 실력이 아니라 판단력에서 났습니다. 잘하는 사람은 에이전트에게 안목과 직관을 실어 보냈고, 나머지는 그냥 프롬프트만 던졌다는 겁니다. 그리고 이 안목은 예전처럼 반복적인 코드를 직접 짜고 버그를 고치며 쌓아온 것이라, 에이전트가 그 반복 작업을 대신 흡수해버리면 정작 판단력을 기를 기회가 줄어드는 역설이 생깁니다.

그래서 그는 에이전트가 짠 코드가 나빠지는 것보다 더 큰 위험은 “그게 나쁘다는 걸 알아채는 능력” 자체가 사라지는 쪽이라고 짚습니다. 겉으로는 잘 작동하는 코드처럼 보이기 때문입니다.

직접 하던 사람에서 지시하는 사람으로

일하는 방식도 바뀝니다. 사람에게 일을 맡기듯 에이전트에게도 위임하는 법을 익혀야 합니다. 과업의 범위를 정하고, 완료 기준을 명시하고, 얼마나 믿을지 조율하고, 결과를 검증하는 일이죠.

Osmani는 자율성이 등급이 아니라 작업마다 조정하는 다이얼이라고 말합니다. 작고 되돌리기 쉬운 일에는 자율성을 최대로 올리고, 실수를 되돌리기 어려운 일에는 낮추는 식입니다. 그리고 무엇보다, 에이전트가 만든 결과물이 프로덕션에서 문제를 일으켰을 때 “AI가 그렇게 했다”는 변명이 되지 않는다는 점을 분명히 합니다. 코드에는 여전히 사람의 이름이 남기 때문입니다.

마지막으로 그는 “라스트 마일”을 강조합니다. 에이전트는 보통 기능의 70%를 빠르게 만들어줍니다. 나머지 30%, 즉 까다로운 예외 처리와 올바른 구조를 찾는 일, 그리고 안목을 쌓는 일은 여전히 사람의 몫입니다. 첫 초안이 공짜로 나오는 시대일수록, 그 초안을 얼마나 마무리 짓는가가 실제 가치를 가른다는 뜻입니다.