Codex 세무 AI 7000건 처리, 개선 루프는 eval에서 시작

OpenAI는 2026년 5월 27일 Codex로 만든 self-improving tax agents 사례를 공개했습니다. Thrive Holdings, Crete 회계 법인 네트워크와 함께 만든 Tax AI가 주인공입니다. 발표문은 새 모델 이름보다 운영 설계를 더 많이 보여줍니다. 현업 회계사가 고친 필드, source document, tax engine mapping, filed return, eval suite, Codex 작업 브랜치를 한 줄로 이어 세무 agent를 개선했다는 내용입니다.

이 사례가 AI 개발자에게 닿는 이유는 수치가 구체적이기 때문입니다. OpenAI는 Tax AI가 이번 tax season 파일럿에서 Crete에 참여한 30개 이상 accounting firm의 7000건 tax return을 처리했다고 밝혔습니다. 대상 업무는 주로 미국 1040과 1041 신고서 준비입니다. Crete practitioners는 세무 시즌마다 수만 건 신고서와 수백만 개 underlying document를 다루며, 중간 이상 복잡도의 신고서는 data entry만 최대 8시간 걸릴 수 있다고 설명했습니다.

OpenAI가 제시한 성능 숫자는 세 가지입니다. Tax AI는 tax preparation 시간을 약 3분의 1 줄이고, draft return을 최대 97% 정확도로 만들며, throughput을 약 50% 높였다고 합니다. 정확도 개선도 한 가지 기준으로 공개됐습니다. OpenAI는 75% correct field completion에 도달한 scored return 비율이 launch 시점에는 25%였지만, 6주 안에 86%까지 올라갔다고 밝혔습니다. 독자가 확인해야 할 부분은 이 수치가 독립 benchmark가 아니라 OpenAI와 Thrive가 공동 작성한 production 사례라는 점입니다.

self-improving이라는 단어는 조심해서 읽어야 합니다. 발표문이 설명한 개선은 모델이 production 중에 가중치를 직접 바꾸는 형태가 아닙니다. 현업 교정이 structured data로 저장되고, product trace가 failure 위치를 드러내며, 반복되는 오류가 tailored eval target으로 바뀌고, Codex가 그 eval을 만족하는 product change 후보를 만듭니다. 이 구조는 자가 학습 모델보다 eval-backed engineering loop에 가깝습니다.

OpenAI가 공개한 세 단계는 단순합니다. 첫째, practitioner가 무엇을 고쳤는지 product가 놓치지 않아야 합니다. 둘째, source material에서 extracted field, provenance, downstream submission, filed return까지 이어지는 trace가 남아야 합니다. 셋째, 반복된 correction이 actionable finding으로 묶이면 Codex가 repo, eval, skills, docs, read-only production evidence를 함께 보고 수정 후보를 제안합니다.

세무 도메인에서 이 설계가 필요한 이유는 오류의 원인이 하나가 아니기 때문입니다. 회계사가 값을 바꿨다고 해서 항상 extraction miss는 아닙니다. prior-year return에서 carry forward된 값일 수 있고, tax engine 안의 기존 값일 수 있고, practitioner preference일 수 있고, 아직 제품이 지원하지 않는 workflow일 수 있습니다. OpenAI는 이 구분을 practitioner가 도와야 했고, 모호한 경우는 자동화 루프에 밀어 넣지 않고 product team으로 되돌린다고 적었습니다.

OpenAI의 rental property 예시는 이 구조를 field 단위로 보여줍니다. Rental property income은 개인 신고서의 Schedule E에 들어갑니다. 시스템은 handwritten note, email, spreadsheet, client file 같은 messy source에서 rental-property field를 추출하고, tax engine에 넣을 개념으로 mapping해야 합니다. 여기서 fair rental days, other expenses, 같은 property가 여러 개 등장하는 source package처럼 작은 필드 오류가 실제 신고 검토 시간을 잡아먹습니다.

Tax AI는 correction을 세 단계로 처리합니다. 먼저 filed return과 Tax AI output을 비교해 expected value, predicted value, actionable 여부가 들어간 field-level review row를 만듭니다. 다음으로 비슷한 row를 묶어 recurring product failure와 expected workflow noise를 나눕니다. 그 뒤 반복되는 finding이 eval target이 됩니다. Codex가 받는 입력은 "답이 틀렸다"가 아니라, 대표 source package, expected output, 관련 code path, grader, regression suite가 붙은 작업 단위입니다.

Codex가 맡는 일은 code generation보다 investigation에 가깝습니다. 발표문은 Codex가 source package, extraction schema, mapper behavior, code path를 검사한다고 설명합니다. 그 뒤 unsupported field, missed extraction pattern, source selection 문제, mapper gap, grader 문제를 나눕니다. 수정 후보도 extraction schema 확장, rental-property document selection 개선, tax-engine mapper 업데이트, expected workflow noise를 잘못 센 grader 조정처럼 범위가 좁습니다.

여기서 AGENTS.md와 skills가 등장합니다. OpenAI가 예시로 든 bounded task environment에는 repo branch, AGENTS.md, task spec, plan, result file이 들어갑니다. app code, eval datasets, regression suites, graders, skills, docs도 같은 작업 환경에 놓입니다. production trace와 source artifacts, tax-engine docs는 read-only context로 분리됩니다. Codex가 고칠 수 있는 surface와 증거로만 읽어야 하는 surface를 나눈 셈입니다.

이 구성은 최근 코딩 에이전트 논의와 정확히 맞물립니다. 많은 제품이 "PR을 만든다", "테스트를 실행한다", "issue를 처리한다"는 실행 표면을 앞세웠습니다. Tax AI 사례에서 더 선명한 부분은 PR 이전의 작업 포장입니다. Codex가 들어갈 task folder에는 success condition이 eval로 들어 있고, representative failure가 production trace로 들어 있으며, human review가 ambiguity를 걸러낸 뒤에야 변경 후보가 생깁니다.

정확도 수치는 읽는 방법이 중요합니다. "최대 97% accuracy"는 어떤 field 집합, 어떤 신고 유형, 어떤 표본 기준인지 원문만으로 모두 확인할 수 없습니다. 75% correct field completion은 launch 대비 개선을 보여주지만, 90%와 100% completion의 구체 수치 그래프는 기사 텍스트보다 원문 이미지에 더 많이 의존합니다. 따라서 이 사례를 그대로 구매 기준으로 삼기보다, 팀 내부 agent 운영의 measurement checklist로 가져오는 편이 정확합니다.

시간 절감 수치도 같은 방식으로 봐야 합니다. 한 senior accountant가 지난해 tax prep에 180시간을 썼고 올해는 15시간만 썼다는 사례가 원문에 등장합니다. 이 숫자는 강하지만, 개인 사례입니다. 전체 파일럿의 평균을 대체하지 않습니다. 다만 180시간에서 15시간으로 줄어든 업무가 client call과 신규 서비스 확장으로 옮겨갔다는 설명은 vertical agent의 비용 절감이 어디에서 제품 가치로 바뀌는지 보여줍니다.

OpenAI가 Thrive Holdings와 함께 이 사례를 공개한 점도 배경입니다. 발표문은 Thrive가 owner이자 operator인 구조라 Crete 같은 실제 사업 안에서 practitioner와 production data에 직접 접근할 수 있었다고 설명합니다. 일반 SaaS vendor가 고객 데이터를 멀리서 보는 관계보다 더 깊은 운영 접근입니다. 이 조건이 없으면 field-level correction을 안정적으로 수집하고, 애매한 case를 practitioner와 분류하고, scoped eval로 바꾸는 시간이 길어질 수 있습니다.

세무 신고는 agent 제품에 쉬운 도메인이 아닙니다. 입력 문서는 messy하고, 규칙은 form과 schedule마다 다르며, 틀린 값은 고객 신고 리스크로 이어집니다. OpenAI 사례는 그래서 더 좁은 주장을 합니다. agent가 전체 세무 판단을 대체했다는 말이 아니라, extraction과 mapping layer에 자동화를 적용했고, architecture와 product decision과 shipping은 engineer가 책임진다고 적었습니다. 이 문장이 빠지면 "AI가 회계사를 대체한다"는 과장으로 읽히기 쉽습니다.

개발팀이 이 사례에서 바로 가져갈 수 있는 설계는 네 가지입니다. 첫째, production feedback을 free-text complaint가 아니라 expected value와 predicted value가 있는 review row로 저장합니다. 둘째, trace에는 model input/output만 남기지 말고 source provenance와 downstream system mapping을 남깁니다. 셋째, recurring finding을 eval target으로 바꾸기 전 expected workflow noise를 사람과 분리합니다. 넷째, coding agent에게는 수정 권한보다 먼저 읽기 전용 evidence와 regression command를 줍니다.

보안과 거버넌스 질문도 남습니다. Tax AI가 다루는 문서는 세무 정보, client note, prior-year return, supporting document를 포함할 수 있습니다. Codex task가 read-only production context를 참조한다면, 어떤 데이터가 sandbox로 들어가고, 어떤 식별자가 masking되며, 실패한 run의 artifact가 어디에 보존되는지 정해야 합니다. 원문은 bounded task environment를 보여주지만, 고객별 data residency, audit log, reviewer policy까지 모두 공개하지는 않았습니다.

커뮤니티 반응은 아직 넓게 형성되지 않았습니다. HN과 GeekNews에서 같은 제목의 활발한 토론은 확인하지 못했습니다. 보조 보도들은 대체로 OpenAI 수치를 요약했고, 일부는 self-improving이라는 표현이 model self-training보다 structured correction loop에 가깝다고 해석했습니다. 이 지적은 타당합니다. 이번 사례의 기술적 가치는 모델이 스스로 똑똑해졌다는 주장보다, 사람의 교정 행위를 Codex가 처리할 수 있는 engineering task로 바꾼 데 있습니다.

AI 인프라 관점에서는 observability, eval, coding agent가 한 제품 루프로 합쳐지는 장면입니다. W&B Weave, LangSmith, Braintrust, Datadog 같은 도구가 agent trace와 eval을 운영하려는 시장과 겹칩니다. OpenAI 사례는 별도 observability 제품 발표가 아니지만, 경쟁 기준을 분명히 합니다. "agent가 답을 잘한다"가 아니라 "agent failure가 evidence, eval, patch, regression, review로 닫히는가"가 enterprise vertical에서 더 중요한 비교 항목이 됩니다.

이 글의 결론은 보수적입니다. OpenAI와 Thrive의 Tax AI는 7000건 파일럿, 30개 이상 회계 법인, 최대 97% draft accuracy, 6주 뒤 75% field completion 86%라는 숫자를 공개했습니다. 하지만 그 숫자는 제품 내부 사례입니다. 독자가 가져갈 부분은 숫자를 복제한다는 약속이 아니라, production correction을 eval과 Codex task로 바꾸는 절차입니다. Agent를 배포한 팀에게 다음 병목은 모델 선택보다 trace 설계, field-level review, regression suite, human gate일 수 있습니다.