OpenAI가 공개한 Tax AI 사례에서 중요한 지점은 ‘세무 업무를 AI가 했다’가 아닙니다. 실무 개발자 입장에서 봐야 할 핵심은 운영 중 나온 수정 기록을 다시 평가 데이터와 개선 작업으로 바꾸는 루프입니다.
OpenAI와 Thrive Holdings는 Crete의 30개 이상 회계 법인 네트워크와 함께 1040, 1041 세금 신고 준비를 돕는 Tax AI를 만들었다고 설명했습니다. 파일 업로드, 문서 분류, 필드 추출, 세무 엔진 제출, 전문가 리뷰까지 이어지는 실제 업무 흐름 안에서 Codex를 개선 루프에 넣은 사례입니다. 파일 몇 개를 읽고 답하는 데모가 아니라, 수천 건의 실무 케이스에서 어떤 값이 틀렸는지, 왜 틀렸는지, 다음 버전에서 어떻게 줄일지를 구조화한 사례라서 볼 가치가 있습니다.
특히 공개된 수치가 흥미롭습니다. 파일럿 기간 동안 7,000건의 세금 신고를 처리했고, 데이터 입력만 8시간 걸릴 수 있는 복잡한 업무에서 준비 시간을 약 3분의 1 줄였다고 합니다. 신고서 초안 정확도는 최대 97%, 처리량은 약 50% 증가했다고 설명했습니다. 출시 초기에 75% 이상 필드가 맞는 신고서는 약 25%였지만, 6주 뒤에는 86%까지 올라갔다는 점도 공개했습니다.
많은 AI 자동화 프로젝트는 프롬프트를 잘 쓰는 단계에서 멈춥니다. 문제가 생기면 운영자가 로그를 보고, 엔지니어가 원인을 추측하고, 프롬프트를 바꾸고, 다시 배포합니다. 이 방식은 초반에는 빠르지만 운영 규모가 커지면 바로 느려집니다. 실패 유형이 늘어나고, 사용자 수정이 진짜 모델 오류인지 업무 선호인지 구분하기 어려워지기 때문입니다.
Tax AI 사례는 이 병목을 다르게 풀었습니다. 전문가가 수정한 값을 단순 피드백으로 남기지 않고, 제품 내부의 trace와 연결했습니다. 어떤 원본 문서에서 어떤 필드를 추출했고, 어떤 값으로 매핑했고, 전문가가 무엇을 바꿨고, 최종 신고서에는 무엇이 들어갔는지를 남겼습니다. 이렇게 해야 ‘틀렸다’가 아니라 ‘어느 단계에서 어떤 종류의 오류가 반복된다’로 바뀝니다.
개발팀이 배워야 할 포인트는 명확합니다. AI 에이전트의 품질 개선은 대화 로그를 많이 모은다고 자동으로 생기지 않습니다. 입력, 중간 판단, 도구 호출, 최종 출력, 사용자 수정이 같은 단위로 묶여야 합니다. 그래야 평가 데이터로 바꿀 수 있고, Codex 같은 코딩 에이전트가 실제로 고칠 수 있는 작업 단위가 됩니다.
AI 제품에서 eval을 만든다고 하면 보통 정답 데이터셋부터 떠올립니다. 하지만 복잡한 업무 자동화에서는 정답만으로 부족합니다. 정답과 예측값의 차이가 있어도 그것이 모델 추출 오류인지, 제품이 아직 지원하지 않는 필드인지, 사용자가 선호상 바꾼 값인지, 이전 연도 데이터에서 이월된 값인지 구분해야 합니다.
OpenAI 사례의 rental property 예시는 이 문제를 잘 보여줍니다. 임대 부동산 소득은 Schedule E에 들어가지만, 실제 원천 자료는 이메일, 스프레드시트, 손글씨 메모, 작년 자료처럼 제각각입니다. 모델이 숫자를 못 읽은 것인지, 여러 부동산을 섞은 것인지, ‘other expenses’ 분류를 잘못한 것인지, 세무 엔진 매핑에서 빠진 것인지가 다를 수 있습니다.
따라서 eval은 단순히 입력과 정답을 나란히 두는 형태가 아니라, 실패 지점을 추적할 수 있어야 합니다. 문서 분류 eval, 필드 추출 eval, citation eval, 매핑 eval, 최종 제출 eval을 나눠야 합니다. 그래야 한 번의 실패가 ‘모델이 별로다’로 끝나지 않고, 구체적인 개선 backlog가 됩니다.
Codex가 한 일은 마법처럼 세무 지식을 알아낸 것이 아닙니다. 더 실용적으로 보면 반복되는 실패 패턴을 조사하고, 재현 가능한 eval을 만들고, 코드 변경 후보를 제안하고, 회귀 테스트까지 확인하는 루프에 들어간 것입니다.
예를 들어 특정 필드가 반복적으로 누락된다면 먼저 관련 trace를 묶습니다. 그다음 실패가 extraction 문제인지 mapping 문제인지 분류합니다. 실패 유형이 확인되면 작은 eval 케이스를 만듭니다. Codex는 그 eval을 통과하기 위한 코드 변경을 제안할 수 있고, 기존 케이스가 깨지지 않는지도 확인할 수 있습니다.
이 접근은 개발 조직에 꽤 현실적입니다. 모든 것을 자동 merge할 필요는 없습니다. 오히려 초반에는 Codex가 issue 초안, 재현 스크립트, eval fixture, 변경 diff 후보를 만들고 사람이 승인하는 방식이 안전합니다. 중요한 것은 실패를 사람이 매번 읽고 해석하는 구조에서 벗어나는 것입니다.
세무가 아니어도 같은 패턴을 적용할 수 있습니다. 고객지원 요약, 견적서 추출, 계약서 검토, 주문 처리, 리포트 생성처럼 전문가가 검토하는 AI 업무라면 모두 해당됩니다.
최소한 아래 데이터는 남겨야 합니다. 첫째, 원본 입력의 버전입니다. 파일이나 메시지가 나중에 바뀌면 분석이 꼬입니다. 둘째, 모델 출력과 도구 호출 결과입니다. 셋째, 사람이 수정한 전후 값입니다. 넷째, 최종 승인된 값입니다. 다섯째, 수정 사유를 선택형으로라도 남길 UI입니다. 자유 텍스트만 있으면 나중에 묶기가 어렵습니다.
여기서 욕심내면 안 됩니다. 처음부터 완전한 관측 시스템을 만들기보다, 가장 돈이 많이 드는 오류 3개를 정하고 그 오류에 필요한 trace만 남기는 게 낫습니다. 예를 들어 ‘금액 추출 오류’, ‘문서 종류 분류 오류’, ‘필수 필드 누락’처럼 운영자가 매일 보는 문제부터 시작하면 됩니다.
간단한 구조는 이렇게 잡을 수 있습니다. 작업 하나마다 run_id를 만들고, 입력 파일, 중간 추출 결과, 모델 응답, 사용자 수정, 최종 승인 데이터를 같은 run_id로 묶습니다. 사용자 수정 UI에서는 필드 단위로 predicted_value, corrected_value, reason_code, reviewer_id, timestamp를 남깁니다.
이후 배치 작업이 수정 로그를 읽어 반복 패턴을 그룹화합니다. 같은 필드, 같은 문서 유형, 비슷한 원인 코드가 일정 횟수 이상 반복되면 eval 후보로 올립니다. eval 후보는 사람이 확인한 뒤 fixture가 됩니다. Codex나 다른 코딩 에이전트는 이 fixture를 기준으로 실패를 재현하고 수정안을 만듭니다.
중요한 운영 규칙도 있습니다. eval은 통과율만 보면 안 됩니다. false positive 비용도 같이 봐야 합니다. 세무처럼 틀린 값 하나가 큰 리스크가 되는 업무에서는 모델이 모르는 것을 모른다고 표시하는 능력이 더 중요할 수 있습니다. 따라서 정확도, 수정 필요율, citation 존재율, 사람이 검토하는 데 걸린 시간, 회귀 실패율을 함께 봐야 합니다.
run_id를 만들고 입력, 중간 결과, 최종 결과를 연결합니다.이번 사례의 결론은 단순합니다. AI 에이전트를 오래 운영할수록 중요한 것은 모델 이름보다 피드백 루프입니다. 운영 trace를 eval로 바꾸는 구조가 있으면 에이전트는 시간이 지날수록 좋아질 수 있습니다. 그 구조가 없으면 모델을 바꿔도 같은 종류의 장애를 계속 사람이 해석해야 합니다.