OpenAI와 Thrive Holdings가 Crete 회계 네트워크에서 만든 Tax AI 사례는 “AI 에이전트가 스스로 좋아진다”는 말을 제품 구조로 풀어낸 사례다. 핵심은 Codex가 단독으로 세무 판단을 대신하는 것이 아니라, 현업 수정 기록·프로덕션 트레이스·평가 세트를 묶어 제한된 개선 작업을 반복하게 만든 점이다.
핵심 요약
- OpenAI와 Thrive Holdings는 Crete의 30개 이상 회계법인 네트워크와 함께 1040·1041 세금 신고서 준비를 돕는 Tax AI를 구축했다.
- 파일럿 기간에 Tax AI는 7,000건의 세금 신고서를 처리했고, 원문은 세무 준비 시간 약 3분의 1 절감, 최대 97% 정확도, 처리량 약 50% 증가를 언급한다.
- 개선 방식은 세 가지다. 현업 회계사의 수정 피드백, 입력부터 최종 신고까지 이어지는 프로덕션 트레이스, 그리고 Codex가 평가·코드·스킬을 보고 제한된 수정을 제안하는 반복 루프다.
- 다른 팀이 참고할 지점은 “자동 패치” 자체가 아니라, 어떤 오류를 자동화할 수 있고 어떤 문제는 사람에게 되돌려야 하는지 나누는 게이트 설계다.
무엇이 바뀌었나
OpenAI의 글은 Tax AI를 단순한 세무 자동화 사례로 소개하지 않는다. 초점은 출시 후 실제 사용에서 생기는 실패를 제품 개선 신호로 바꾸는 방법에 있다. 세무 업무는 문서 형식이 불규칙하고, 전년도 자료와 고객 메모가 섞이며, 같은 숫자라도 추출 오류·매핑 오류·세무 판단·업무상 예외가 섞여 나타난다. 이런 문제를 엔지니어가 매번 수동으로 분류하면 개선 속도가 느려진다.
Tax AI는 회계사가 원천 파일과 고객별 메모를 올리면 세무 엔진에 넣을 수 있는 제출물을 만든다. 초기에는 W-2, 1099 같은 비교적 단순한 작업에서 시작했지만, 시즌이 진행되며 K-1, 스케줄, 여러 출처를 대조해야 하는 복잡한 신고로 범위를 넓혔다. 원문에 따르면 75% 필드 완성 기준에 도달한 신고 비율은 출시 시점의 약 25%에서 6주 뒤 86%로 올라갔다.
자가 개선 루프의 구조
| 구성 요소 | 역할 | 실무자가 봐야 할 점 |
|---|---|---|
| 현업 피드백 | 회계사가 수정한 값과 최종 제출 값을 제품 학습 신호로 남긴다. | 수정 기록이 단순 로그가 아니라 오류 유형을 판별할 수 있는 구조인지 확인해야 한다. |
| 프로덕션 트레이스 | 원천 문서, 추출 필드, 출처 인용, 세무 엔진 매핑, 최종 수정까지의 경로를 보존한다. | 민감 데이터 접근 권한, 보존 기간, 익명화·마스킹 정책이 함께 설계돼야 한다. |
| Codex 반복 루프 | 반복되는 실패를 평가 세트로 만들고, Codex가 원인 조사·수정·검증·PR 제안을 돕는다. | 쓰기 가능한 작업 영역과 읽기 전용 운영 컨텍스트가 분리돼야 하며, 사람의 리뷰 없이 배포되면 안 된다. |
원문은 임대 부동산 신고 예시를 통해 이 구조를 설명한다. Schedule E의 임대 수입은 손글씨 메모, 이메일, 스프레드시트, 고객 파일을 함께 봐야 할 수 있다. Tax AI가 예측한 값과 최종 신고 값이 다르면 그것이 실제 추출 누락인지, 전년도 값의 이월인지, 회계사의 선호인지, 아직 제품이 지원하지 않는 케이스인지 구분해야 한다. 이 구분이 끝난 반복 패턴만 평가 목표가 된다.
Codex가 하는 일과 하지 않는 일
Codex가 직접 “세무 판단”을 내리는 구조로 읽으면 위험하다. OpenAI가 설명한 루프에서 Codex의 역할은 반복되는 현업 수정 패턴을 제한된 엔지니어링 과제로 바꾸는 것이다. 예를 들어 공정 임대일수(fair rental days) 필드를 자주 놓친다는 신호가 확인되면, Codex는 소스 패키지, 추출 스키마, 매퍼, 평가, 관련 코드 경로를 함께 보고 원인을 찾는다. 이후 스키마 확장, 문서 선택 개선, 세무 엔진 매퍼 수정, 평가기 보정 같은 후보 수정을 제안하고 타깃 평가와 회귀 평가를 다시 돌린다.
이 차이는 중요하다. 좋은 에이전트 운영은 “문제가 생기면 알아서 고친다”가 아니라 “반복 가능한 실패만, 충분한 증거와 성공 기준이 있을 때, 제한된 범위에서 수정 후보를 만든다”에 가깝다. 증거가 애매하거나 자동화가 안전하지 않은 경우에는 제품팀과 엔지니어에게 되돌리는 경로가 필요하다.
실사용 전에 확인할 운영 기준
- 권한 분리: Codex가 볼 수 있는 운영 트레이스와 실제로 수정할 수 있는 저장소·파일 범위를 분리해야 한다. 민감한 고객 문서는 읽기 전용·최소 권한·감사 로그가 기본값이어야 한다.
- 평가 세트 품질: 하나의 실패 사례를 바로 패치 대상으로 삼지 말고, 반복되는 패턴인지, 기대 출력이 명확한지, 회귀 평가가 준비돼 있는지 확인해야 한다.
- 사람의 승인: 세무·의료·금융처럼 책임이 큰 도메인에서는 에이전트가 만든 변경을 사람이 검토하고 배포 여부를 결정해야 한다.
- 롤백과 재현성: 어떤 트레이스와 어떤 평가가 어떤 코드 변경으로 이어졌는지 남겨야 한다. 결과가 나빠질 때 이전 버전으로 되돌릴 수 있어야 한다.
- 비용과 지연: 트레이스 저장, 평가 실행, Codex 작업, 회귀 테스트가 모두 비용을 만든다. 단순 반복 업무 절감액보다 운영비가 커지면 확장 가치가 떨어진다.
제한된 파일럿으로 검증하기
- 먼저 고위험 전체 업무가 아니라 오류 유형이 분명한 한 구간을 고른다. 예를 들면 문서에서 필드를 추출해 내부 양식에 넣는 단계처럼 성공 기준을 숫자로 표현할 수 있는 작업이 적합하다.
- 현업 수정 기록을 구조화한다. “무엇을 바꿨는가”뿐 아니라 원래 예측값, 최종 값, 근거 문서, 수정 사유, 실제로 배포를 막은 문제인지까지 남겨야 한다.
- 반복되는 실패만 평가 세트로 만든다. 한 번 나온 예외나 판단이 필요한 케이스는 자동 패치 대상에서 제외하고, 사람이 검토할 큐로 보낸다.
- Codex 작업 환경을 제한한다. 운영 데이터는 읽기 전용 샘플로 제공하고, 수정 가능한 코드는 좁은 모듈과 테스트에 한정한다.
- 변경 후보는 타깃 평가와 회귀 평가를 모두 통과한 뒤 리뷰한다. 통과율만 보지 말고, 새로 생긴 오탐·누락·비용 증가도 같이 기록한다.
ActualStack 관점의 결론
이번 사례는 Codex를 “코딩 속도를 높이는 도구”로만 보는 관점에서 한 걸음 더 나간다. 제품이 운영 중 남기는 흔적을 잘 설계하면, 현업 피드백이 평가로 바뀌고, 평가는 제한된 코드 변경 후보로 이어질 수 있다. 다만 이 구조는 데이터가 민감할수록 더 엄격한 권한·감사·검토 체계가 필요하다.
따라서 개발팀이 바로 가져갈 교훈은 Tax AI의 세무 기능 자체가 아니라 루프의 설계다. 현업 수정이 어떤 데이터로 남는지, 그 데이터가 어떤 평가로 바뀌는지, Codex가 어느 범위까지 수정할 수 있는지, 마지막 배포 책임자가 누구인지가 분명해야 한다. 이 네 가지가 없으면 “자가 개선”은 품질 시스템이 아니라 위험한 자동화가 될 수 있다.
출처와 검증
- 원문: OpenAI, “Building self-improving tax agents with Codex”
- 확인한 주요 수치: Crete 30개 이상 회계법인 네트워크, 파일럿 7,000건 처리, 세무 준비 시간 약 3분의 1 절감, 최대 97% 정확도, 처리량 약 50% 증가, 75% 필드 완성 기준 6주 뒤 86% 도달.
- 해석상 주의: 해당 수치는 OpenAI와 Thrive Holdings가 공개한 특정 파일럿 사례다. 다른 도메인에 적용하려면 데이터 권한, 평가 품질, 사람의 검토, 롤백 절차를 별도로 검증해야 한다.