7천건 세금신고가 만든 루프, Codex 자기개선의 조건

AI 요약

• 무슨 일: OpenAI가 Thrive Holdings와 만든 Tax AI의 Codex 자기개선 루프를 공개했습니다.
  • Crete의 30개 이상 회계법인 네트워크에서 7,000건의 세금 신고를 처리한 사례입니다.
• 핵심 숫자: 준비 시간 약 3분의 1 절감, 최대 97% 초안 정확도, 처리량 약 50% 증가를 주장했습니다.
• 의미: 에이전트 개선의 병목은 모델 호출이 아니라 생산 트레이스와 평가 인프라입니다.
  • 실무자 수정은 곧바로 패치가 아니라 검토, 그룹화, 평가 타깃화를 거쳐 Codex 작업이 됩니다.
• 주의점: OpenAI 사례는 특정 도메인, 특정 운영 구조, 강한 전문가 감독 안에서 나온 결과입니다.

OpenAI가 2026년 5월 27일 공개한 Tax AI 사례는 겉으로 보면 세금 업무 자동화 이야기입니다. 하지만 개발자 관점에서 더 중요한 주제는 따로 있습니다. 실제 프로덕션에서 발견되는 실패를 어떻게 에이전트가 고칠 수 있는 작은 작업으로 바꾸는가입니다.

OpenAI와 Thrive Holdings는 지난 6개월 동안 Crete의 회계법인 네트워크와 함께 Tax AI를 만들었습니다. 공식 글에 따르면 이 네트워크는 30개 이상의 회계법인을 포함하고, 파일럿 기간 Tax AI는 7,000건의 세금 신고를 처리했습니다. 대상은 미국의 1040 및 1041 신고서 준비 업무입니다. OpenAI는 Tax AI가 세금 준비 시간을 약 3분의 1 줄이고, 최대 97% 정확도로 초안을 만들며, 처리량을 약 50% 늘렸다고 설명합니다.

여기까지만 보면 흔한 엔터프라이즈 AI 성공 사례처럼 보입니다. 하지만 글의 본문은 성과보다 루프에 집중합니다. 실무자가 고친 값, 문서에서 추출된 필드, 세금 엔진으로 매핑된 경로, 최종 신고 값, 평가 세트, 회귀 테스트, Codex 작업 환경이 하나의 흐름으로 묶입니다. 이 구조가 없으면 "에이전트가 스스로 좋아졌다"는 말은 대부분 마케팅 문구에 가깝습니다. 이번 글은 그 문구를 엔지니어링 문제로 끌어내린 사례입니다.

세금 자동화보다 중요한 것은 실패의 포맷입니다

OpenAI의 설명에서 가장 먼저 눈에 띄는 숫자는 업무의 크기입니다. Crete 실무자들은 한 시즌에 수만 건의 세금 신고를 준비하고, 그 과정에서 수백만 개의 기초 문서를 다룹니다. 중간 이상 난도의 신고에서는 데이터 입력만 8시간이 걸릴 수 있다고 합니다. 문서는 깔끔한 API 응답이 아니라 과거 연도 자료, 손글씨 메모, 이메일, 스프레드시트, 고객별 예외가 섞인 작업물입니다.

이런 업무에서 AI가 초안을 만드는 것 자체는 이제 놀라운 주장이 아닙니다. 진짜 문제는 초안이 틀렸을 때입니다. 틀린 값은 단순한 추출 실패일 수도 있고, 세금 엔진에 전년도 값이 남아 생긴 차이일 수도 있습니다. 실무자가 선호하는 입력 방식일 수도 있고, 제품이 아직 지원하지 않는 필드일 수도 있습니다. 또는 모델이 문서를 잘못 읽은 명확한 오류일 수도 있습니다.

따라서 "실무자가 수정했다"는 이벤트 하나만으로는 제품이 배울 수 없습니다. 수정은 신호이지만, 아직 학습 데이터가 아닙니다. OpenAI가 강조한 설계는 이 차이를 다룹니다. Tax AI는 실무자가 무엇을 고쳤는지뿐 아니라 시스템이 처음 무엇을 제안했는지, 어떤 소스 문서를 근거로 삼았는지, 어느 매핑 경로를 탔는지, 최종 신고에는 무엇이 들어갔는지를 보존합니다.

이것이 프로덕션 트레이스입니다. 로그보다 좁고, 감사 기록보다 제품 개선에 가깝습니다. 에이전트가 고칠 수 있는 작업을 만들기 위해 필요한 증거 묶음입니다.

세 단계 루프: 전문가, 트레이스, Codex

OpenAI는 Tax AI의 자기개선 구조를 세 축으로 설명합니다. 첫째, 실무자와 가까이 있어야 합니다. 세금 신고에서는 어떤 차이가 실제 오류인지, 어떤 차이가 정상적인 판단인지 도메인 전문가가 구분합니다. 둘째, 제품이 생산 환경에서 증거를 남겨야 합니다. 입력과 출력만 남기는 것이 아니라, 문서 분류부터 필드 추출, 출처, 세금 엔진 매핑, 전문가 수정까지 전체 경로를 보존해야 합니다. 셋째, 이 증거를 맞춤 평가와 Codex 작업으로 바꾸는 루프가 있어야 합니다.

이 세 축은 흔히 말하는 "AI 에이전트가 알아서 고친다"와 다릅니다. 자동 수정이 아니라 검토 가능한 수리 공정에 가깝습니다. 반복된 실무자 수정은 먼저 그룹화됩니다. 예를 들어 임대 부동산 신고에서 fair rental days 필드를 자주 놓치거나, 여러 임대 물건이 같은 문서 패키지 안에 있을 때 값을 섞거나, "기타 비용"을 잘못 매핑하는 패턴이 드러날 수 있습니다.

그 패턴이 검토되면 평가 타깃이 됩니다. 대표 소스 패키지, 기대 출력, 실패 조건, 회귀 기준이 붙습니다. 그다음에야 Codex가 실제 제품 스캐폴드 안에서 문제를 조사합니다. 추출 스키마가 빠졌는지, 소스 선택이 나빴는지, 매퍼가 누락됐는지, grader가 정상 워크플로 노이즈를 실패로 세고 있는지 확인합니다.

이 과정에서 Codex는 막연한 "버그를 고쳐줘" 프롬프트를 받지 않습니다. OpenAI 글의 예시처럼 Codex 작업 환경에는 repo, task.yaml, 평가 데이터, suites, graders, 관련 문서, 그리고 읽기 전용 production trace와 source artifacts가 분리되어 들어갑니다. 고칠 수 있는 표면과 고치면 안 되는 증거가 나뉘어 있습니다.

25%에서 86%로, 숫자가 말하는 개선의 성격

OpenAI가 제시한 핵심 성과 중 하나는 필드 완성도입니다. Tax AI는 신고서가 나중에 얼마나 적게 수정되는지를 보기 위해 75%, 90%, 100% correct field completion 기준을 사용했습니다. 출시 시점에는 75% 완성도에 도달한 신고가 전체의 25% 수준이었지만, 6주 안에 86%가 그 기준을 넘었습니다.

이 숫자는 단순 벤치마크 점수와 다릅니다. 모델이 고정된 테스트셋에서 몇 점을 받았다는 뜻이 아니라, 실제 운영에서 드러난 문제를 제품 개선 루프로 되돌린 결과입니다. 그래서 더 흥미롭습니다. AI 제품이 시간이 지나며 좋아진다는 주장은 흔하지만, 대부분은 모델 교체, 프롬프트 변경, 사용자 경험 개선이 뒤섞여 있습니다. Tax AI 사례는 적어도 한 계층에서는 무엇이 신호가 되고, 무엇이 평가가 되며, 무엇이 Codex 작업이 되는지 더 구체적으로 보여줍니다.

또 하나 중요한 지점은 복잡도의 방향입니다. OpenAI는 초기에 W-2와 1099 같은 단순 업무를 처리하다가, 시즌이 진행되며 K-1, 여러 schedule, 더 까다로운 edge case로 확장했다고 설명합니다. 쉬운 업무에서만 정확도가 올랐다는 이야기가 아닙니다. 더 어려운 업무로 들어갈수록 한 건당 절약되는 시간이 커졌고, 임대 부동산 영역에서는 90% 정밀도와 재현율에 도달하기까지 약 6주와 상당한 엔지니어링 감독이 필요했다고 합니다.

이 표현은 중요합니다. "자기개선"이라는 단어가 붙었지만, OpenAI는 인간 엔지니어와 실무자 감독을 지우지 않습니다. 오히려 감독이 루프의 전제라고 말합니다. 실무자는 수정과 판단으로 신호를 만들고, 엔지니어는 아키텍처와 제품 결정을 책임지며, Codex는 경계가 정해진 작업 안에서 조사, 구현, 검증 후보를 만듭니다.

왜 세금 업무였을까

세금 신고는 AI 데모에 좋은 소재처럼 보이지 않을 수 있습니다. 사용자에게 화려한 화면을 보여주기 어렵고, 결과가 틀리면 비용이 큽니다. 그런데 바로 그 점 때문에 에이전트 제품의 다음 단계를 보기 좋은 도메인입니다. 입력은 비정형이고, 규칙은 촘촘하며, 최종 책임은 전문가에게 남습니다. 제품이 "그럴듯한 답"을 내는 것보다, 왜 그 답을 냈고 어디서 틀렸는지 추적하는 능력이 더 중요합니다.

OpenAI가 든 임대 부동산 예시는 이를 잘 보여줍니다. Schedule E에 들어갈 임대 수입과 비용을 처리하려면 시스템은 여러 문서에서 부동산별 필드를 읽고, 출처를 보존하고, 세금 엔진의 개념으로 매핑해야 합니다. 하나의 숫자가 틀렸을 때 원인은 다양합니다. 모델이 값을 못 찾았을 수도 있고, 여러 부동산을 섞었을 수도 있고, 고객 메모의 의도를 잘못 해석했을 수도 있고, 세금 엔진 쪽 기존 값과 충돌했을 수도 있습니다.

코딩 에이전트도 같은 문제를 겪습니다. 테스트 실패 하나는 구현 오류일 수도 있고, 테스트가 낡았다는 신호일 수도 있고, 요구사항이 애매하다는 신호일 수도 있습니다. 프로덕션 버그 하나는 코드 한 줄의 문제가 아니라 데이터 계약, 권한, 배포 환경, 사용자 워크플로가 엮인 결과일 수 있습니다. Codex가 유용해지는 지점은 "코드를 쓴다"가 아니라 이 증거 묶음을 다룰 수 있는 작업 환경이 있을 때입니다.

Tax AI 사례의 메시지는 그래서 세무 업계 밖으로 번집니다. 에이전트가 실제 제품을 개선하려면 다음 네 가지가 필요합니다. 첫째, 실무자가 만든 고품질 피드백 신호입니다. 둘째, 제품이 그 신호의 맥락을 잃지 않도록 남기는 트레이스입니다. 셋째, 반복 패턴을 평가 타깃으로 바꾸는 운영 절차입니다. 넷째, 변경을 검증하고 되돌릴 수 있는 회귀 평가와 리뷰입니다.

자기개선이라는 말의 위험한 부분

이번 발표에서 조심해야 할 단어는 "self-improving"입니다. 이 표현은 쉽게 오해됩니다. 모델이 독립적으로 목표를 세우고, 제품을 마음대로 바꾸고, 배포까지 밀어 넣는 모습을 상상하기 쉽습니다. 그러나 OpenAI 글의 실제 구조는 훨씬 제한적입니다.

먼저, 증거는 생산 환경에서 오지만 Codex가 원본 증거를 마음대로 바꾸지는 않습니다. 대표 작업 환경은 쓰기 가능한 repo와 읽기 전용 production trace를 분리합니다. 둘째, 모든 수정이 작업이 되지 않습니다. 실무자 수정은 검토와 그룹화를 거쳐 반복되는 제품 실패로 판단될 때만 평가 타깃이 됩니다. 셋째, Codex의 결과는 targeted eval과 broader regression suite를 통과해야 하며, 엔지니어 리뷰가 남습니다.

이 제한이 있어야 "자기개선"이라는 말이 안전해집니다. 제한이 없으면 자기개선은 책임 회피가 됩니다. 제품이 틀렸을 때 누가 판단했는지, 어떤 증거로 바꿨는지, 무엇을 검증했는지 설명할 수 없기 때문입니다.

개발팀이 이 사례에서 가져갈 실무적 교훈은 에이전트를 더 많이 붙이는 것이 아닙니다. 오히려 에이전트가 건드릴 수 있는 표면을 작게 만들고, 실패를 설명하는 데이터 구조를 촘촘하게 만드는 것입니다. "Codex가 repo를 볼 수 있다"는 것은 출발점일 뿐입니다. 어떤 task를 받는지, 어떤 평가가 성공을 정의하는지, 어떤 문서는 읽기 전용인지, 어떤 변경은 인간에게 돌려보내야 하는지가 더 중요합니다.

엔터프라이즈 AI의 경쟁축도 바뀝니다

최근 AI 회사들은 엔터프라이즈 업무 안으로 더 깊이 들어가고 있습니다. Anthropic은 PwC와 KPMG 같은 전문 서비스 조직에 Claude를 배치하고, OpenAI는 Codex와 workspace agent를 업무 흐름에 넣고, Microsoft는 Agent 365 같은 관리 계층을 밀고 있습니다. 표면적으로는 "어느 모델이 더 똑똑한가"의 경쟁처럼 보이지만, 실제 고객 조직에서는 다른 질문이 더 중요해집니다.

어느 회사가 도메인 피드백을 제품 개선 데이터로 바꿀 수 있는가. 어느 플랫폼이 감사를 견딜 수 있는 트레이스를 남기는가. 어느 에이전트가 검증 가능한 작은 작업으로 실패를 분해하는가. 어느 조직이 자동화할 것과 전문가에게 되돌릴 것을 구분하는가.

Tax AI는 OpenAI가 이 경쟁을 어떻게 보고 있는지 보여줍니다. Codex는 단순히 IDE 안의 코딩 도우미가 아니라, 운영 증거와 평가 인프라를 가진 도메인 제품의 개선 엔진으로 배치됩니다. 이는 AI 코딩 도구 시장에도 중요한 신호입니다. 에이전트의 경쟁력은 채팅창의 답변 품질만으로 결정되지 않습니다. 실제로는 평가 세트, 제품 트레이스, 샌드박스, 권한 경계, 회귀 테스트, 리뷰 흐름을 얼마나 잘 묶는지가 차이를 만듭니다.

다만 이 사례를 그대로 일반화하기는 어렵습니다. Thrive Holdings는 소유와 운영을 함께 하는 구조라 OpenAI와 직접 제품과 서비스를 묶어 실험할 수 있었습니다. Crete 실무자들은 반복 업무를 수행하면서 고품질 피드백을 남길 수 있었습니다. 모든 회사가 이런 도메인 전문가 접근성, 데이터 권한, 평가 인프라, 엔지니어링 시간을 갖고 있지는 않습니다.

그래서 이번 뉴스의 결론은 "이제 모든 업무가 스스로 개선된다"가 아닙니다. 더 정확한 결론은 "스스로 개선되는 것처럼 보이는 에이전트 제품은, 보이지 않는 곳에 매우 인간적인 운영 시스템을 갖고 있다"입니다.

개발팀이 볼 체크리스트

AI 팀이나 개발자 조직이 이번 사례를 읽을 때 확인해야 할 질문은 비교적 분명합니다.

첫째, 사용자 수정이 구조화되어 있습니까. 단순히 "사용자가 결과를 편집했다"를 저장하는 것과, 예상값, 실제값, 최종값, 근거 문서, 워크플로 단계, 수정 이유 후보를 함께 남기는 것은 다릅니다. 후자가 있어야 개선 루프가 시작됩니다.

둘째, 실패를 제품 노이즈와 분리할 수 있습니까. 모든 차이를 오류로 보면 에이전트는 잘못된 목표를 최적화합니다. 세금 신고에서는 전년도 값, 실무자 판단, 미지원 필드가 섞입니다. 소프트웨어 제품에서는 플래키 테스트, 임시 운영 우회, 문서화되지 않은 고객 예외가 비슷한 역할을 합니다.

셋째, 반복 패턴을 평가로 바꾸는 사람이 있습니까. 좋은 eval은 자동으로 생기지 않습니다. 누군가가 실패를 묶고, 대표 사례를 고르고, 기대 출력을 정의하고, 성공 기준을 정해야 합니다. Codex가 가장 잘하는 것은 이 경계가 있는 작업 안에서 코드와 테스트를 움직이는 일입니다.

넷째, 에이전트 작업 환경에 읽기 전용 증거와 쓰기 가능한 코드가 분리되어 있습니까. 이 구분이 없으면 디버깅이 쉬워지는 대신 감사와 재현성이 무너집니다.

다섯째, 개선 후 새 문제가 생겼는지 확인하는 회귀 평가가 있습니까. Tax AI 사례에서 targeted eval만큼 중요한 것은 broader regression suite입니다. 특정 필드 하나를 고치며 다른 schedule을 망가뜨리면 자기개선이 아니라 국소 최적화입니다.

이번 발표가 남긴 신호

OpenAI 글의 마지막에는 한 시니어 회계사가 지난해 세금 준비에 180시간을 썼지만 올해는 15시간만 썼다는 사례가 나옵니다. 이 숫자는 강력합니다. 하지만 더 오래 남을 신호는 다른 곳에 있습니다. 180시간을 15시간으로 줄인 주인공이 단순한 모델 호출이 아니라, 실무자 피드백을 평가 가능한 작업으로 바꾸는 시스템이라는 점입니다.

AI 에이전트 시장은 "무엇을 할 수 있나"에서 "어떻게 고쳐지는가"로 이동하고 있습니다. 첫 번째 질문은 데모에서 답할 수 있습니다. 두 번째 질문은 운영 시스템에서만 답할 수 있습니다. Tax AI는 그 운영 시스템의 한 사례입니다. 프로덕션 트레이스가 있고, 도메인 전문가가 있으며, 평가 세트가 있고, Codex가 경계 안에서 고치고, 인간이 검증합니다.

이 흐름은 앞으로 코딩 에이전트 제품의 평가 기준도 바꿀 가능성이 큽니다. 더 긴 컨텍스트, 더 빠른 모델, 더 많은 도구 호출도 중요하지만, 기업이 실제로 물어볼 질문은 조금 더 건조합니다. 우리 제품의 실패를 이 에이전트가 이해할 수 있는 포맷으로 줄 수 있는가. 수정이 반복되는지 측정할 수 있는가. 실패를 eval로 바꾸는 비용이 줄어드는가. Codex가 낸 변경을 믿을 수 있는 검증 루프가 있는가.

이번 OpenAI 사례는 낙관적인 이야기이면서 동시에 까다로운 이야기입니다. 에이전트가 스스로 좋아질 수 있다는 가능성을 보여주지만, 그 가능성은 자동으로 오지 않습니다. 사람이 남긴 수정, 제품이 남긴 증거, 평가가 정의한 목표, 엔지니어가 유지하는 경계가 있어야 합니다. 결국 자기개선 에이전트의 핵심은 에이전트가 아니라, 에이전트가 배울 수 있도록 실패를 정리하는 조직의 능력입니다.