Codex로 자기개선 세무 에이전트 구축하기

Thrive Holdings와 OpenAI가 실무자 전문성과 Codex 기반 루프를 결합해 Crete 회계사를 위한 Tax AI를 공동 개발한 방법

현실 세계의 시스템은 실험실과 달리 프로덕션에서 다르게 동작하며, 배포 전에 예상하기 어려운 방식으로 문제가 발생합니다. 팀은 종종 출시 후에야 이런 실패를 발견하고, 몇 주 동안 엣지 케이스를 점검하고, 프롬프트를 조정하고, 프로덕션 피드백을 지속 가능한 제품 개선으로 바꾸는 데 시간을 씁니다. 이 피드백 루프는 수작업이고 느리며, 엔지니어가 진전시킬 때만 개선됩니다. 하지만 오늘날에는 신중하게 설계된 eval 인프라, 실무자와 현실 환경에 대한 직접 접근, 그리고 Codex의 최전선 에이전트형 역량을 통해 자기개선하는 에이전트를 구축할 수 있습니다.

이 글에서는 우리가 Codex를 사용해 이런 유형의 에이전트를 어떻게 구축했는지 살펴봅니다. 지난 6개월 동안 OpenAI의 현장 파견 엔지니어와 연구원들은 Thrive Holdings의 엔지니어들과 협력해 Crete⁠(새 창에서 열기)의 30개 이상 회계 법인 네트워크와 함께, 그리고 그들을 위해 점점 더 복잡해지는 세금 신고 준비를 돕는 Tax AI를 구축했습니다. Tax AI는 엔지니어가 각 실패를 찾아 고치는 데 의존하는 대신, Codex를 사용해 프로덕션 사용을 자율적 개선을 촉진하는 구조화된 신호로 전환합니다.

Crete의 실무자들은 매 시즌 수만 건의 세금 신고서를 준비하며, 이를 위해 수백만 개의 기초 문서를 처리해야 합니다. 중간에서 높은 복잡도의 신고에서는 데이터 입력만으로도 신고서당 8시간이 걸릴 수 있으며, 지저분한 데이터 소스, 전년도 문서, 수작업 추출과 계산이 자주 수반됩니다. 그들은 세금 시즌의 가장 바쁜 기간 동안 세무 준비가 중요한 병목이라고 우리에게 알려주었습니다.

이 문제를 해결하기 위해 Tax AI는 이번 세금 시즌 파일럿에 참여한 Crete 소속 법인 전반에서 7,000건의 세금 신고서를 처리했습니다. 이 시스템은 1040 및 1041 세금 신고서 준비의 많은 시간 집약적 과정을 자동화하지만, 효율성 향상보다 더 주목할 점은 시스템 자체가 3개월 전 처음 배포된 버전보다 측정 가능하게 더 좋아졌다는 것입니다.

Tax AI에서 실무자들은 소스 파일과 고객별 메모를 함께 업로드합니다. 그러면 Tax AI는 검토 준비가 된 세금 엔진 제출물을 생성합니다. 이 시스템은 실무자의 세무 준비 시간을 약 3분의 1 절약하고, 최대 97% 정확도로 신고서 초안을 작성하며, 처리량을 약 50% 높여 고객과 보낼 시간을 더 확보해 줍니다. 

우리는 Tax AI가 나중에 수정 없이 얼마나 정확하게 신고서를 완성할 수 있는지 이해함으로써 이 개선을 정량화할 수 있습니다. 우리는 신고서 중 75%, 90%, 또는 100%의 정확한 필드 완료에 도달한 비율을 확인해 정확도를 측정합니다. 출시 시점에는 신고서의 4분의 1만이 75% 정확한 필드 완료 수준에 있었지만, 6주 안에 86%가 그 수준에 도달했습니다. 시스템은 90%와 100% 정확한 필드 완료 수준에서 더 빠른 성장세를 보였습니다. 이 임계값은 서로 다른 신고서에 여전히 얼마나 많은 실무자 후속 조치가 필요한지 실용적으로 보여줍니다. 

초기에는 Tax AI가 W-2와 1099 같은 더 단순한 업무를 처리했습니다. 시즌이 진행되면서 K-1, 스케줄, 더 어려운 엣지 케이스가 포함된 더 복잡한 신고로 확장되었습니다. 새로운 역량이 추가될 때마다 이전보다 신고서당 더 많은 시간을 절약했는데, 맡게 된 작업이 더 어렵고 수작업으로 처리하기에 더 많은 시간이 들었기 때문입니다. 우리는 오늘도 계속되는 진전을 보고 있습니다.

다음으로, 우리 팀이 세 가지 핵심 축에 기대어 Tax AI를 어떻게 자기개선형으로 공동 설계했는지 살펴보겠습니다. 1) 전문가 실무자 피드백, 2) 프로덕션 트레이스(입력부터 최종 출력까지의 구조화된 이력), 3) 지속적이고 더 빠른 제품 개발을 가능하게 하는 맞춤형 eval 기반 Codex 주도 반복 루프입니다. 우리의 경험이 실무자 전문성이 전체 시스템과 그 안을 흐르는 데이터를 형성하는 데 핵심인 다른 도메인의 빌더들에게도 도움이 되기를 바랍니다.

우리가 세무 준비의 더 어려운 부분(K-1, 임대 부동산 스케줄, 여러 소스 파일 간 값 대사가 필요한 세금 양식)으로 나아가면서, 진짜 과제는 제품이 복잡한 프로덕션 실패를 보이게 하고, 이해 가능하게 하고, 조치 가능하게 만들 수 있는지라는 점이 분명해졌습니다.

제품 초기에는 대부분의 수정이 수작업이었습니다. 실무자들은 시스템 오류를 수정할 수 있었지만, 제품은 전체 맥락을 포착하지 못했습니다. 제출 전 변경된 값은 실제 추출 누락, 매핑 문제, 누락된 제품 지원, 또는 예상된 워크플로 노이즈를 반영할 수 있었습니다. 이런 사례를 가려내는 데는 여전히 엔지니어링 팀의 후속 조치가 필요했습니다. 엔지니어는 코딩 에이전트를 사용할 수 있었지만, 시스템은 아직 개선 루프 안에서 AI를 의미 있게 활용하도록 설계되어 있지 않았습니다. 우리는 어떤 언덕을 올라야 하는지 식별할 신호가 없었습니다.

그래서 우리는 시스템을 세 가지 축 중심으로 설계하게 되었습니다:

1. 실무자와 가깝게 유지: 실제로 일을 하는 사람들이 제품이 무엇을 학습할지 이끌어야 합니다. 그들의 직관과 이해는 어떤 오류가 중요한지 드러내고, 워크플로의 어느 부분에 다음으로 집중할 가치가 있는지 판단하는 데 도움을 줍니다.
2. 프로덕션이 근거를 만들도록 제품 구축: 제품은 단순한 입력과 출력 이상을 포착해야 합니다. 소스 자료에서 추출된 필드와 출처, 다운스트림 제출, 전문가 수정에 이르는 전체 경로를 포착해야 합니다.
3. Codex 주도 개선 루프 만들기: 프로덕션 이슈가 보이고 구조화되면, 그것들은 발견 사항, 맞춤형 eval, 범위가 정해진 엔지니어링 작업이 될 수 있습니다. 그다음 Codex는 조사, 변경 제안, 목표형 및 회귀 eval에 대한 검증을 도와 순수 수작업 반복 사이클보다 더 빠르게 제품을 전진시킬 수 있습니다. 

아래의 임대 부동산 예시는 그 루프가 실제로 어떻게 작동하는지 보여주며, 실무자 수정이 구조화된 발견 사항이 되고, 이어 eval 목표가 되며, 마지막으로 Codex 범위의 엔지니어링 작업이 되는 과정을 안내합니다.

임대 부동산 소득은 개인 세금 신고서의 Schedule E에 보고됩니다. 엔지니어링 관점에서 이 추출 작업은 설명하기는 쉽지만 잘 수행하기는 어렵습니다. 시스템은 지저분한 소스 자료(손글씨 메모, 이메일, 스프레드시트, 기타 고객 파일)를 읽고, 시스템이 세금 엔진에 자신 있게 매핑할 수 있는 임대 부동산 필드를 추출하며, 실무자가 결과를 승인하거나 수정할 수 있을 만큼 충분한 근거를 보존해야 합니다. 아래의 단순화된 예시는 그러한 소스 파일과 추출된 출력이 어떤 모습일 수 있는지 보여줍니다.

에이전트가 예측한 값과 제출된 세금 신고서의 실제 값 사이의 차이는 실제 추출 누락을 반영할 수 있지만, 실무자 선호, 세금 엔진에서 전년도 신고서로부터 이월된 값, 또는 신고 워크플로의 다른 곳에서 추가되거나 변경된 값일 수도 있습니다. 실무자들은 이런 사례를 구분하도록 도와주었고, 그 덕분에 어떤 조치가 실무자 수정을 필요로 하거나 제출을 막는지 식별할 수 있었습니다.

이러한 수정 사항을 자세히 볼 수 있었기 때문에, 우리는 검토 프로세스를 실패 후 끝나는 단계에서 지속적인 학습 사이클로 바꿀 수 있었습니다. 우리는 전문가의 행동을 구조화된 데이터로 포착하도록 워크플로를 설계했습니다. 이제 모든 개입은 Tax AI가 정확히 무엇을 제안했는지, 실무자가 무엇을 수정했는지, 그리고 최종적으로 제출된 신고서에 무엇이 들어갔는지를 기록함으로써 제품의 개선 루프에 투입됩니다.

임대 부동산처럼 복잡한 워크플로에서는 시스템이 소스 파일과 제출된 신고서 사이에서 일어나는 일을 보존해야 합니다. 그 경로를 따라 문서는 정리, 분할, 분류되고, 임대 부동산 필드는 소스 자료로의 인용과 함께 추출되며, 그 값들은 세금 엔진에 매핑되고, 제출 전 실무자가 여전히 이를 수정할 수 있습니다. 이러한 제품 수준 트레이스 덕분에 실패가 어디서 발생했는지 조사할 수 있습니다. 실무자 수정을 유용한 평가 목표로 바꾸기 위해 시스템은 이를 세 단계로 처리합니다:

• 차이 포착: Tax AI의 출력은 제출된 신고서와 비교되어, 기대값, 예측값, 그리고 그 차이가 조치 가능한 것으로 보이는지를 담은 필드 수준 검토 행을 생성합니다.
• 관련 실패 그룹화: 유사한 검토 행을 묶어 반복되는 제품 실패를 예상된 워크플로 노이즈와 구분합니다. 예를 들어 반복되는 실무자 수정은 Tax AI가 종종 “적정 임대 일수” 필드를 놓치거나, “기타 비용”을 잘못 처리하거나, 같은 소스 패키지 안의 여러 임대 부동산을 혼동한다는 점을 보여줄 수 있습니다.
• 반복 패턴을 평가 목표로 전환: 검토와 측정이 끝나면, 반복되는 발견 사항은 Codex가 개선할 명확한 eval 목표가 됩니다.

세 번째 축은 이러한 새로운 eval에 대응할 수 있는 엔지니어링 루프를 만드는 것입니다. 바로 여기서 Codex가 중심이 됩니다.

예를 들어 eval 파이프라인이 Tax AI가 “적정 임대 일수” 필드를 일관되게 놓치고, 실무자들은 이를 꾸준히 채워 넣는다고 표시한다고 가정해 봅시다. 이 발견 사항은 이미 대표적인 소스 패키지와 기대 출력이 포함된 목표형 eval 세트로 패키징되어 있으므로, Codex는 제품 스캐폴드 안에서 근본 원인을 직접 조사할 수 있습니다.

Codex는 단지 수준 이하의 최종 출력만 가지고 작업하는 것이 아닙니다. Codex는 트레이스, eval, 리포지터리, 스킬을 함께 살펴봅니다:

• 파이프라인 조사: 소스 패키지, 추출 스키마, 매퍼 동작, 코드 경로를 점검해 문제가 미지원 필드인지, 놓친 추출 패턴인지, 소스 선택 문제인지, 매퍼 공백인지, 또는 채점기 문제인지 판단합니다.
• 목표형 수정 구현: 추출 스키마를 확장하고, 임대 부동산 문서의 소스 선택을 개선하고, 세금 엔진 매퍼를 업데이트하거나, 예상된 워크플로 노이즈가 실패로 집계되고 있다면 채점기를 정교화합니다.
• 검증 및 제안: 목표형 eval을 다시 실행하고, 더 넓은 회귀 테스트 모음을 돌린 뒤, 엔지니어링 검토를 위한 후보 풀 리퀘스트를 제시합니다.
• 루프 닫기: 반복되는 실무자 수정을 측정 가능한 엔지니어링 작업으로 전환합니다. 근거가 모호하거나 안전하게 자동화할 수 없다면, 그 사례는 루프에 억지로 넣지 않고 제품 팀으로 다시 전달됩니다.

임대 부동산 예시는 더 넓게 재사용 가능한 패턴을 잘 보여줍니다. 즉, 프로덕션 산출물과 트레이스를 사용해 에이전트의 역량을 개선하는 것입니다. 프로덕션 데이터에서 검토된 발견 사항, 소스 트레이스, 기대되는 세금 엔진 출력, 관련 코드 예시, eval 명령을 입력 세트로 주면, Codex는 수주에서 수개월에 걸쳐 성능과 정확도를 실질적으로 개선할 수 있습니다. 이는 하니스 엔지니어링과 Symphony에 관한 우리의 작업에서 설명한 원칙을 바탕으로 합니다. 이 글들은 작업을 Codex가 이해하기 쉽게 만들고, 범위가 정해진 컨텍스트와 도구를 제공하며, 검증과 사람의 검토를 환경의 일부로 유지하는 방법을 안내합니다. 

그 근거가 자동으로 Codex 작업이 되는 것은 아닙니다. 실무자 수정은 추출 누락, 매핑 문제, 미지원 제품 동작, 세무 판단, 또는 예상된 워크플로 노이즈를 반영할 수 있습니다. 반복되는 차이가 검토되고 실행 가능한 발견 사항으로 그룹화된 뒤에야 시스템은 이를 명확한 성공 조건이 있는 범위 제한 작업으로 전환합니다.

우리는 이 자동화를 제품의 범위가 정해진 계층에 적용합니다. 이 계층은 추출을 수행하고 소스 문서를 세금 워크플로에 매핑합니다. 엔지니어는 아키텍처, 제품 결정, 배포에 계속 책임을 집니다. 실무자들은 이미 하고 있는 일, 즉 추출된 값을 수정하고, 신고서를 검토하고, 최종 신고를 승인하는 일을 통해 개선 루프를 이끕니다.

Codex에게 그 결과는 막연한 경고가 아니라, 근거와 수정 가능한 제품 표면, 명시적 검증 게이트를 갖춘 범위가 정해진 엔지니어링 작업입니다. 대표적인 임대 부동산 작업의 컨텍스트는 다음과 같이 요약할 수 있습니다:

같은 루프는 임대 부동산을 넘어 다른 영역에도 적용됩니다. 임대 부동산은 정밀도와 재현율 90%에 도달하는 데 약 6주와 상당한 엔지니어링 감독이 필요했지만, 그 작업은 재사용 가능한 추상화, 검토 산출물, eval 관례, 구현 패턴을 만들어 Schedule C와 Schedule A 같은 비슷하게 복잡한 스케줄을 더 쉽게 지원하게 했습니다.

Tax AI는 자기개선 에이전트를 구축하는 경로를 보여줍니다. 실무자들은 서비스를 제공하면서 높은 가치의 피드백 신호를 생성합니다. 제품 워크플로는 이러한 신호를 구조화된 근거로 보존합니다. eval로 뒷받침되는 엔지니어링 시스템은 개선 사항이 프로덕션에 도달하기 전에 이를 검증하고, 에이전트 기반 루프는 시스템을 지속적인 자기개선 흐름 속에 유지합니다. 

Thrive Holdings의 구조는 우리가 이 환경을 특정 산업에서 복제할 수 있게 해줍니다. Holdings는 소유자이자 Operator이므로, 우리의 통합 엔지니어링 팀은 벤더가 아니라 파트너로서 Crete 같은 기업 내부의 실무자 및 프로덕션 데이터와 직접 협업할 수 있습니다. 이는 기술, 제품, 서비스가 모두 한 지붕 아래에 있어 우리가 더 빠르게 움직이고 뛰어난 제품을 만들 수 있음을 뜻합니다.

작년에 세무 준비에 180시간을 쓴 한 선임 회계사는 올해는 단 15시간만 썼습니다. 그녀는 그 시간의 일부를 모든 고객에게 전화를 걸어 신고 내용을 함께 검토하는 데 썼는데, 이는 1년 전에는 불가능했던 수준의 밀착 서비스였습니다. 남은 시간은 신규 고객을 맡고 새로운 서비스 제공으로 확장하는 데 사용했습니다.

이제 우리 팀은 모두 Tax AI의 동일한 3단계 설계를 청사진으로 삼아 Thrive Holdings⁠(새 창에서 열기) 전반의 다른 도메인에서 워크플로를 구축하고 있습니다. 예를 들어 부기와 감사 같은 회계 워크플로, 그리고 IT 헬프데스크 자동화 같은 운영 워크플로가 있습니다. 도메인과 산업 전반에서 자기개선 에이전트의 더 큰 가능성은 유효합니다. 최고의 에이전트는 사람의 조정을 받아 시간이 지날수록 더 유능하고, 더 신뢰받으며, 더 가치 있게 학습합니다.

이 프로젝트에 참여한 OpenAI 팀에 대해 더 알아보려면 문의해 주세요.