OpenAI가 코덱스로 사내 법무·재무·채용 업무의 99%를 자동화했다고 밝혔습니다.

같은 시기, Stripe의 Staff Engineer가 커뮤니티에 이렇게 썼습니다. “에이전트 병렬 조율이 이제 직급 기대치가 됐다.”

두 문장은 반대처럼 보입니다. 하나는 99% 자동화, 다른 하나는 새 역량 기대치. 하지만 실제로는 같은 방향을 가리킵니다.

자동화가 많아질수록, 그 자동화를 판단하고 통제할 사람의 가치가 올라갑니다.

자동화가 없애는 것과 새로 만드는 것

자동화가 업무를 없앤다는 설명은 절반만 맞습니다.

OpenAI 코덱스가 내부 법무 검토의 99%를 처리한다면, 남은 1%는 무엇입니까? 코덱스가 틀렸을 때 그것이 틀렸다고 판단하는 사람입니다. 재무 분석의 99%가 에이전트로 넘어갔다면, 남은 1%는 에이전트가 어떤 기준으로 무엇을 빠뜨렸는지를 읽는 사람입니다.

이것이 Verification Tax(검증 과세)입니다. 자동화 비율이 높아질수록 자동화 결과물을 검증하는 역할의 난이도와 책임이 함께 올라가는 현상입니다.

자동차 운전을 자동화하면 안전 엔지니어가 더 중요해집니다. 코드 생성을 자동화하면 코드 검토 설계자가 더 중요해집니다. 에이전트가 업무의 99%를 처리하면, 나머지 1%를 책임지는 역할은 더 희귀해지고 더 높은 가치를 갖습니다.

MIT emollick 연구팀의 조직설계 분석과 KT·삼성의 AI 도입 데이터 준비도 평가가 같은 결론을 냈습니다. 도입 성패를 가르는 첫 번째 변수는 모델의 성능이 아니라 조직이 검증을 얼마나 체계적으로 설계했는가입니다.

빅테크가 만들고 있는 새 직무

이 변화는 이미 직무 정의로 나타나고 있습니다.

AI FDE(현장 임베드 담당자)는 에이전트를 배포한 뒤 조직 안에 실제로 흡수되도록 돕는 역할입니다. 기술적 배포가 끝난 시점에 투입됩니다. 현장 팀이 에이전트를 어떻게 쓰고 있는지, 어디서 예외가 발생하는지, 어떤 판단을 에이전트에 위임하면 안 되는지를 추적합니다.

자주 받는 질문이 있습니다. “에이전트를 도입했는데 왜 현장 팀이 계속 이전 방식으로 일하느냐.”

기술 문제가 아닙니다. 에이전트가 언제 틀릴 수 있는지, 어떤 결과를 믿어도 되는지, 예외 상황에서 어떻게 개입해야 하는지가 현장 팀에게 전달되지 않은 것입니다. AI FDE가 없으면 배포는 끝났어도 운영은 시작되지 않습니다.

Stripe Staff Engineer의 문장으로 다시 돌아옵니다. “에이전트 병렬 조율이 이제 직급 기대치가 됐다.”

에이전트가 10개 있을 때, 관리자는 10개 에이전트 각각이 어떤 조건에서 실행되고, 어떤 경우에 멈춰야 하며, 서로의 결과를 어떻게 검증하는지를 설계해야 합니다. 단일 에이전트를 쓸 때는 프롬프트를 잘 쓰면 됐습니다. 병렬 에이전트 10개를 운영하면, 실행 조건과 결과 검증을 조율하는 능력이 필요합니다.

이것이 단순한 기술 역량이 아닌 이유가 있습니다. 어떤 에이전트를 믿을 수 있는지, 어떤 결과물에 사람의 검토가 필요한지, 어디서 에스컬레이션이 일어나야 하는지는 도메인 맥락 없이는 설계할 수 없습니다. Stripe에서 이것이 직급 기대치가 됐다는 말은, 수석 엔지니어는 이제 에이전트를 만드는 것보다 에이전트가 서로를 확인하는 구조를 설계하는 것이 더 중요한 역량이 됐다는 뜻입니다.

PM이 새로 짊어야 할 것

SVPG(Silicon Valley Product Group)는 PM 역할의 새로운 정의를 이렇게 썼습니다. “PM의 역할은 무엇이 존재해야 하는지를 결정하는 것이다.”

에이전트 시대에 이 정의는 더 구체화됩니다. 어떤 에이전트가 존재해야 하는지뿐 아니라, 에이전트가 틀렸을 때 누가 어떻게 판단하는지까지 설계하는 것이 PM의 역할입니다.

실제로 어떻게 보이는지 예를 들겠습니다.

고객 문의 에이전트를 설계한다고 가정합니다. 에이전트가 95%의 문의를 처리합니다. 남은 5%는 에이전트가 자신 없다고 표시하거나, 감지된 위험이 임계값을 넘은 경우입니다. PM이 결정해야 하는 것은 이 5%를 누가 받고, 어떤 기준으로 다시 판단하며, 그 판단이 다음 에이전트 학습에 어떻게 반영되는지입니다.

에이전트를 만드는 것보다 이 검증 루프를 설계하는 것이 더 어렵습니다. 그리고 이것이 자동화 99%가 남기는 1%입니다.

희귀해지는 역할

2026년 하반기, 채용 시장에서 AI Engineer와 AI FDE 직무가 늘고 있습니다. 에이전트를 만드는 역할이 아니라 에이전트를 판단하는 역할입니다.

이 역할이 희귀한 이유는 두 가지입니다.

첫째, 에이전트의 한계를 경험적으로 알아야 합니다. 특정 도메인에서 에이전트가 어떤 조건에서 틀리는지, 어떤 판단은 절대 위임하면 안 되는지를 알아야 검증 기준을 만들 수 있습니다. 에이전트를 직접 운영해 본 경험이 없으면 이 기준을 설계할 수 없습니다.

둘째, 조직과 기술을 모두 읽어야 합니다. 에이전트의 기술적 한계를 알면서, 동시에 현장 팀이 그 결과를 어떻게 받아들이는지를 이해하는 사람이 필요합니다. 엔지니어와 운영팀 사이, 지금은 공식 직무가 없는 자리입니다.

자동화가 많아질수록 이 경계를 판단하는 사람이 더 필요합니다. 그런데 이 역할은 아직 직무 정의가 명확하지 않아서, 많은 조직에서 PM이 비공식적으로 맡고 있습니다.

지금 준비해야 할 것

에이전트가 늘어나는 속도만큼, 검증 설계를 아는 PM의 값이 올라갑니다.

구체적으로는 세 가지입니다.

에이전트가 틀리는 조건을 문서화하는 능력. 어떤 입력에서, 어떤 맥락에서 에이전트가 틀리는지를 체계적으로 기록하는 것이 검증 기준의 출발점입니다.

예외 처리 흐름을 설계하는 능력. 에이전트가 모르는 상황을 만났을 때 어디로 가야 하는지, 누가 판단하고 그 판단이 어떻게 피드백되는지를 설계합니다.

자동화 결과물에서 신호를 읽는 능력. 에이전트가 출력한 결과에서 무엇이 정상이고 무엇이 이상인지를 판단하는 것입니다. 이것은 도메인 지식 없이는 만들 수 없습니다.

OpenAI의 99%는 그들이 이 세 가지를 잘 설계했다는 뜻입니다. 그리고 그것을 설계한 사람들은 자동화가 늘어날수록 더 가치 있어집니다.

여러분 팀에서 자동화가 99%까지 갔을 때, 남은 1%를 설계하는 사람은 누구입니까?