“OpenAI Codex가 사내 업무의 99%를 자동화했다.”

이 문장 뒤에 이어지는 이야기를 끝까지 읽은 사람은 많지 않습니다.

같은 시기 OpenAI는 “검증·예외 처리·배포 책임”을 전담하는 새 직무군을 조직 내에 만들었습니다. AI Field Deployment Engineer(AI FDE)라고 부릅니다. 코드를 짜는 역할이 아닙니다. 에이전트가 실패하는 지점을 찾고, 실패 패턴을 기록하고, 그 책임 소재를 정의합니다.

자동화가 깊어질수록 검증 직무도 함께 생겨납니다. 이 패턴은 예외가 아닙니다.

왜 자동화와 검증은 함께 늘어나는가

자동화가 특정 임계를 넘으면 조직은 반드시 두 방향으로 분기합니다.

자동화 범위 확대. 처음에는 단순 반복 업무를 에이전트에게 넘깁니다. 성과가 나오면 복잡한 업무로 확장합니다. 에이전트가 판단하는 영역이 점점 넓어집니다.

예외 복잡도 증가. 자동화 범위가 넓어질수록 에이전트가 처리하지 못하는 케이스도 다양해집니다. 단순한 오류가 아닙니다. “모델이 틀렸는지, 입력 데이터가 오염됐는지, 프롬프트 설계가 잘못됐는지”를 구분해야 하는 복합 예외입니다. 이걸 기록하고 분류하는 역할이 필요해집니다.

삼성SDS는 2026년 초 에이전트 도입 현황을 발표하며 이 구조를 수치로 보여줬습니다. 에이전트 도입을 시도한 기업 중 실제 프로덕션으로 확장한 비율은 5%였습니다. 95%는 PoC 단계에 머물렀습니다. 기술 문제가 아니었습니다. 에이전트가 실패했을 때 책임 소재가 불분명하고, 예외를 기록하는 체계가 없고, 검증 프로세스가 설계되지 않았기 때문이었습니다.

emollick(와튼 스쿨)이 146개 경제학 팀에게 같은 데이터셋을 주고 Claude Code·Codex로 재현한 실험에서도 비슷한 패턴이 나왔습니다. 에이전트 AI는 인간 중간값에 가까운 결과를 냈지만 편차가 좁고 극단값이 없었습니다. “최고”를 만드는 시스템이 아니라 “일관된 양질”을 보장하는 시스템이었습니다. 그리고 그 일관성은 모델이 보장하지 않았습니다. 검증 설계가 보장했습니다.

AI FDE는 무슨 일을 하는가

AI FDE가 실제로 하는 일을 보면 이해가 빨라집니다.

AI FDE 업무 예시 (하루)
- 에이전트가 처리한 1,200건 중 이상값 17건 분류
- 원인 태깅: 프롬프트 설계 오류 / 입력 데이터 품질 / 모델 한계
- 오류 유형별 대응 프로세스 문서화
- 다음 스프린트 evals 개선 티켓 작성

QA 엔지니어가 하던 일과 다릅니다. QA는 “버그를 찾는다”입니다. AI FDE는 “에이전트가 왜 이 결정을 내렸는지, 그것이 잘못된 이유가 무엇인지, 같은 패턴이 반복되는지”를 분석합니다. 이것은 시스템 이해를 요구하는 판단 업무입니다.

이 직무가 등장한 이유는 하나입니다. 에이전트가 실수했을 때 그것이 “버그”인지 “설계 의도”인지 구분할 수 있는 역할이 필요해졌기 때문입니다. 그 역할은 코드를 짜는 사람이 아니라, 시스템이 어떻게 설계됐는지를 아는 사람이 맡습니다.

PM이 자동화 전에 설계해야 하는 것

에이전트 도입 성패를 결정하는 변수는 생각보다 단순합니다. KT와 삼성이 반복적으로 마주치는 병목은 “어느 모델을 쓸까”가 아닙니다. “이 시스템을 누가 감독하고, 실패하면 어떻게 되는가”입니다.

모델 선택이 성패의 20%를 결정한다면, 검증 구조 설계는 나머지 50%를 결정합니다. 나머지 30%는 데이터 준비도입니다.

PM이 에이전트 로드맵을 짤 때 자동화 범위만 그리면 절반을 놓친 겁니다. 나머지 절반은 이 질문들입니다.

검증 구조 설계 체크리스트

  1. 에이전트가 처리하는 케이스 중 사람이 반드시 검토해야 하는 케이스의 기준은 무엇인가
  2. 에이전트 오류 발생 시 1차 책임자는 누구인가
  3. 오류 패턴을 어떻게 기록하고, 어떻게 evals 개선으로 연결하는가
  4. 검증 담당 역할(AI FDE급)이 팀 내에 있는가

없다면 지금 당장 신설할 필요는 없습니다. 그러나 언제 필요해지는지는 알고 있어야 합니다. 도입 5%에 머문 기업들은 대부분 필요해진 시점에 이미 늦었습니다.

자동화 로드맵과 검증 로드맵은 같은 문서에 있어야 한다

“자동화 많이 = 사람 적게”라는 공식은 에이전트 시대에 맞지 않습니다.

더 정확한 공식은 이것입니다.

자동화가 늘면, 단순 실행자는 줄고 판단 책임자는 늘어난다.

OpenAI가 99%를 자동화했을 때 AI FDE를 신설한 것은 우연이 아닙니다. 자동화 깊이가 깊어질수록 어디선가 반드시 이 직무가 생겨납니다. 빠른 조직은 먼저 설계하고, 느린 조직은 사고가 터진 뒤에야 만듭니다.

PM이 해야 할 일은 그 직무가 생기는 시점을 미리 예측하고, 책임 구조와 evals 파이프라인을 함께 설계해두는 것입니다. 자동화 타임라인과 검증 구조 타임라인은 같은 문서 안에 있어야 합니다.

지금 팀에서 에이전트 자동화 범위를 늘리고 있다면, 검증 구조는 어디에 있나요?