OpenAI가 공개한 Tax AI 사례는 에이전트 제품을 만드는 팀에게 꽤 실용적인 참고자료입니다. Thrive Holdings, OpenAI, Crete의 30개 이상 회계법인이 함께 만든 Tax AI는 복잡한 1040, 1041 세금 신고 준비를 자동화하는 시스템입니다. 발표에 따르면 파일럿 기간 동안 7,000건의 세금 신고를 처리했고, 세무 실무자의 준비 시간을 약 3분의 1 줄였으며, 최대 97% 정확도와 약 50% 처리량 증가를 보였습니다. 더 흥미로운 점은 첫 배포 후 6주 만에 75% correct field completion에 도달한 신고 비율이 25%에서 86%로 올라갔다는 설명입니다.
이 글의 목적은 세무 자동화를 소개하는 것이 아닙니다. 핵심은 production trace, practitioner feedback, tailored eval, Codex-driven iteration loop를 어떻게 연결했는지입니다. 이 구조는 세금, 보험, 의료 문서, 법무 검토, 고객지원 자동화처럼 전문가 피드백이 중요한 도메인에 그대로 응용할 수 있습니다.
랩 환경에서는 프롬프트가 잘 동작합니다. 샘플 문서도 깔끔합니다. 하지만 실제 고객 파일은 다릅니다. 스캔 품질이 낮고, 이전 연도 문서가 섞이고, 이메일 본문에 중요한 정보가 들어 있고, 표와 손글씨가 같이 등장합니다. 결과가 틀렸을 때도 원인이 하나가 아닙니다. 추출 실패일 수도 있고, 매핑 문제일 수도 있고, 제품이 아직 지원하지 않는 필드일 수도 있고, 실무자의 선호나 워크플로우 노이즈일 수도 있습니다.
많은 AI 제품은 여기서 막힙니다. 사용자가 수정한 값은 있지만, 왜 수정했는지 모릅니다. 엔지니어는 로그를 뒤지고 프롬프트를 고치지만, 같은 실패가 반복되는지 확인할 eval이 없습니다. 결국 개선은 수동 티켓 처리처럼 느려집니다.
Tax AI 사례가 보여주는 방향은 다릅니다. 제품이 production evidence를 만들도록 설계하고, 그 evidence를 Codex가 조사할 수 있는 eval target과 engineering task로 바꿉니다.
사용자가 값을 바꿨다고 해서 시스템이 틀렸다는 뜻은 아닙니다. 세무 실무자가 신고 전 값을 수정했다면 그것은 실제 오류일 수도 있고, 전년도 값이 carry-forward 된 것일 수도 있고, 신고 과정의 다른 단계에서 바뀐 값일 수도 있습니다. 이런 맥락을 구분하지 않으면 모델은 잘못된 방향으로 개선됩니다.
그래서 전문가 피드백은 구조화되어야 합니다. Tax AI 사례에서는 practitioner correction을 field-level review row로 만들고, expected value, predicted value, actionable 여부를 구분합니다. 비슷한 수정 패턴을 그룹화해 반복 제품 실패와 정상 워크플로우 노이즈를 분리합니다. 그 다음 반복되는 문제를 eval target으로 만듭니다.
이 흐름이 없으면 “사용자가 고쳤다”는 사실만 남습니다. 하지만 좋은 개선 루프에서는 “어떤 필드에서, 어떤 문서 유형에서, 어떤 추출 또는 매핑 단계가 반복적으로 실패했는가”까지 남아야 합니다.
자가 개선 에이전트를 만들려면 trace가 옵션이 아니라 제품 기능이어야 합니다. 단순 입력과 출력 로그만으로는 부족합니다. 문서가 어떻게 분류됐는지, 어떤 청크에서 값을 뽑았는지, 어떤 citation을 붙였는지, 어떤 schema로 normalize됐는지, downstream system에 어떻게 매핑됐는지, 사용자가 어떤 값을 수정했는지까지 이어져야 합니다.
최소 trace 구조는 다음과 같습니다.
이 구조가 있어야 Codex나 다른 코딩 에이전트가 문제를 조사할 수 있습니다. “fair rental days를 자주 놓친다”는 신호가 있다면, 에이전트는 source selection, extraction schema, mapper, grader 중 어디가 문제인지 추적할 수 있습니다.
좋은 eval은 모델 전체 점수를 보기 위한 것이 아닙니다. 제품 개선에서는 “작은 언덕”이 필요합니다. 예를 들어 rental property 문서에서 fair rental days 필드를 놓치는 문제가 반복된다면, 해당 케이스만 모은 targeted eval을 만듭니다. 그리고 Codex에게 이 eval을 통과하도록 제한된 변경을 맡깁니다.
작업 흐름은 이렇게 잡을 수 있습니다.
이 구조의 장점은 개선 단위가 작다는 것입니다. “세무 AI 정확도 올리기”는 너무 큽니다. “rental property source package에서 fair rental days 필드 누락 줄이기”는 실행 가능한 작업입니다.
Tax AI 사례에서 중요한 표현은 “stay close to practitioners”입니다. 도메인 전문가가 단순히 정답 데이터를 붙이는 사람이 아니라, 어떤 오류가 실제로 중요한지 결정하는 역할을 합니다. AI 제품팀은 전문가가 수정한 값을 그대로 정답으로 삼기보다, 수정의 의미를 함께 해석해야 합니다.
실무 적용 시에는 전문가 화면에 correction reason을 남길 수 있게 하는 것이 좋습니다. 예를 들어 “원문 누락”, “필드 매핑 오류”, “고객 메모 반영”, “전년도 값 유지”, “제품 미지원” 같은 선택지를 둡니다. 이 태그는 나중에 eval target을 만들 때 큰 차이를 만듭니다.
자가 개선 에이전트는 모델 accuracy만 보면 안 됩니다. Tax AI 발표가 field completion threshold와 throughput, practitioner time saving을 함께 말한 이유가 있습니다. 제품 성공은 정확도와 업무 시간 절감이 동시에 일어나야 합니다.
권장 지표는 다음과 같습니다.
특히 regression 실패율은 중요합니다. 한 필드를 고치다가 다른 문서 유형을 망치면 자가 개선이 아니라 자가 회귀입니다.
자가 개선 AI 에이전트의 핵심은 모델이 스스로 똑똑해지는 것이 아닙니다. 제품이 실패를 구조화된 증거로 남기고, 그 증거를 작은 eval과 안전한 코드 변경으로 바꾸는 것입니다. trace가 없으면 자가 개선은 구호에 그칩니다.
참고: OpenAI, “Building self-improving tax agents with Codex”, 2026-05-27.
