Codex를 활용한 자기 개선형 세무 에이전트 구축

실제 환경의 시스템은 실험실에서와 다르게 작동하며, 배포 전에는 예측하기 어려운 방식으로 고장이 발생합니다. 팀들은 종종 출시 후에 이러한 실패를 발견하며, 그 후 몇 주 동안 에지 케이스(edge cases)를 조사하고, 프롬프트(prompts)를 조정하며, 실제 환경의 피드백을 지속 가능한 제품 개선으로 전환하는 데 시간을 보냅니다. 이 피드백 루프는 수동적이고 느리며, 엔지니어가 직접 개선 작업을 수행할 때만 발전합니다. 하지만 오늘날, 사려 깊게 설계된 평가 인프라(eval infrastructure), 실무자 및 실제 환경에 대한 직접적인 접근성, 그리고 Codex의 최첨단 에이전트 역량(agentic capabilities)을 활용하면 스스로 개선하는 에이전트를 구축할 수 있습니다.

이 포스트에서는 우리가 이러한 유형의 에이전트를 구축하기 위해 Codex를 어떻게 사용했는지 자세히 살펴보겠습니다. 지난 6개월 동안, OpenAI의 현장 배치 엔지니어(forward deployed engineers) 및 연구원들은 Thrive Holdings의 엔지니어들과 협력하여, 점점 더 복잡해지는 세무 신고서 작성을 돕기 위해 30개 이상의 회계 법인 네트워크를 보유한 Crete(새 창에서 열기)와 함께 Tax AI를 구축했습니다. 엔지니어가 각 실패 사례를 찾아 수정하는 방식에 의존하는 대신, Tax AI는 Codex를 사용하여 실제 사용 사례를 자율적 개선을 촉진하는 구조화된 신호(structured signals)로 전환합니다.

Crete의 실무자들은 매 시즌 수만 건의 세무 신고서를 준비하며, 이 과정에서 수백만 개의 기초 문서를 검토해야 합니다. 중간에서 대규모 복잡도를 가진 신고의 경우, 데이터 입력에만 신고서당 8시간이 소요될 수 있으며, 여기에는 종종 지저분한 데이터 소스, 전년도 문서, 그리고 수동 추출 및 계산 작업이 포함됩니다. 그들은 세무 시즌 중 가장 바쁜 시기에 세무 준비 작업이 상당한 병목 현상(bottleneck)이라고 지적했습니다.

이 문제를 해결하기 위해, Tax AI는 이번 세무 시즌 파일럿에 참여한 Crete 법인들을 통해 7,000건의 세무 신고서를 처리했습니다. 이 시스템은 1040 및 1041 세무 신고서 준비 과정의 많은 시간 소모적인 프로세스를 자동화합니다. 하지만 효율성 향상보다 더욱 주목할 만한 점은, 시스템 자체가 3개월 전 처음 배포되었던 버전보다 측정 가능한 수준으로 더 나아졌다는 사실입니다.

Tax AI에서 실무자들은 소스 파일과 함께 고객별 특이 사항(client-specific notes)을 업로드합니다. 그러면 Tax AI가 검토 준비가 된 세무 엔진 제출물(tax engine submission)을 생성합니다. 이를 통해 실무자들은 세무 준비 시간의 약 3분의 1을 절약하고, 최대 97%의 정확도로 신고서 초안을 작성하며, 처리량(throughput)을 약 50% 증가시켜 고객과 함께 보낼 수 있는 시간을 더 많이 확보할 수 있습니다.

우리는 Tax AI가 나중에 수정할 필요 없이 얼마나 정확하게 신고서를 완료할 수 있는지를 이해함으로써 이러한 개선 사항을 정량화할 수 있습니다. 우리는 필드 완성도(field completion)가 75%, 90%, 또는 100%에 도달하는 신고서의 비율을 확인하여 정확도를 측정합니다. 출시 당시에는 신고서의 4분의 1만이 75%의 필드 완성도에 도달했으나, 6주 이내에 86%가 그 수치에 도달했습니다. 시스템은 90% 및 100% 필드 완성도 수준에서 훨씬 더 빠른 성장을 보여주었습니다. 이러한 임계값(thresholds)은 각기 다른 신고서에 대해 실무자의 후속 조치가 얼마나 더 필요한지에 대한 실질적인 관점을 제공합니다.

초기에 Tax AI는 W-2 및 1099와 같은 더 단순한 업무를 처리했습니다. 시즌이 진행됨에 따라 K-1, 스케줄(schedules), 그리고 더 까다로운 예외 사례(edge cases)가 포함된 더 복잡한 신고서로 영역을 확장했습니다. 새로운 기능이 추가될 때마다 이전보다 신고서당 더 많은 시간을 절약할 수 있었는데, 이는 시스템이 맡은 작업이 더 어렵고 수동으로 수행하기에 더 많은 시간이 소요되는 작업이었기 때문입니다. 우리는 오늘날에도 지속적인 진전을 목격하고 있습니다.

다음으로, 우리 팀이 세 가지 핵심 기둥에 의존하여 Tax AI를 어떻게 자기 개선형(self-improving)으로 공동 설계(co-engineered)했는지 살펴보겠습니다. 그 세 가지 기둥은 1) 전문가 실무자의 피드백, 2) 프로덕션 트레이스(production traces, 입력부터 최종 출력까지의 구조화된 이력), 3) 맞춤형 평가(evals)를 기반으로 지속적이고 빠른 제품 개발을 가능하게 하는 Codex 기반 반복 루프(iteration loop)입니다. 우리의 경험이 전문가의 지식이 전체 시스템의 품질과 그 안에서 흐르는 데이터를 형성하는 데 핵심적인 역할을 하는 다른 도메인의 빌더들에게 유용하기를 바랍니다.

Tax AI가 더 복잡한 신고로 확장됨에 따라, 점수가 매겨진 신고서 중 75%, 90% 및 전체 완료에 도달하는 비율은 세무 시즌 내내 계속 상승했습니다.

세무 준비의 더 어려운 부분(K-1, 임대 부동산 스케줄, 그리고 여러 소스 파일 간에 값을 대조해야 하는 세무 양식 등)으로 진입함에 따라, 진정한 과제는 제품이 복잡한 운영상의 실패(production failures)를 가시화하고, 이해 가능하며, 실행 가능한 상태로 만들 수 있는지 여부임이 분명해졌습니다.

제품 초기에는 대부분의 수정 작업이 수동으로 이루어졌습니다. 실무자(Practitioners)들이 시스템 오류를 수정할 수는 있었지만, 제품이 전체 문맥(context)을 포착하지는 못했습니다. 예를 들어, 신고 전 변경된 값은 실제 추출 실패(extraction miss), 매핑(mapping) 문제, 제품 지원 부족, 또는 예상되는 워크플로 노이즈(workflow noise)를 반영할 수 있습니다. 이러한 사례들을 분류하는 데에는 여전히 엔지니어링 팀의 후속 조치가 필요했습니다. 엔지니어들은 코딩 에이전트(coding agents)를 사용할 수 있었지만, 시스템은 아직 개선 루프(improvement loop) 내에서 AI를 의미 있게 사용하도록 설계되지 않았습니다. 우리는 정복해야 할 올바른 언덕(the right hill to climb)이 어디인지 식별할 수 있는 신호(signal)를 가지고 있지 않았습니다.

이는 우리가 세 가지 기둥을 중심으로 시스템을 설계하도록 이끌었습니다:

실무자에게 밀착하기: 업무를 수행하는 사람들이 제품이 학습하는 내용을 조종할 수 있어야 합니다. 그들의 직관과 이해도는 어떤 오류가 중요한지를 드러내며, 다음 단계로 워크플로의 어느 부분에 집중할 가치가 있는지 알려주는 데 도움을 줍니다.

운영 과정에서 증거가 생성되도록 제품 구축하기: 제품은 단순히 입력값과 출력값만을 포착하는 것을 넘어, 소스 자료에서 추출된 필드와 출처(provenance), 그리고 다운스트림 제출 및 전문가 수정에 이르는 전체 경로를 포착해야 합니다.

Codex 기반의 개선 루프 생성하기: 운영상의 이슈가 가시화되고 구조화되면, 이는 발견 사항(findings), 맞춤형 평가(evals), 그리고 범위가 지정된 엔지니어링 작업(scoped engineering tasks)이 될 수 있습니다. 그러면 Codex는 조사, 변경 제안, 타겟 및 회귀 평가(regression evals)를 통한 검증을 도와줌으로써, 순수하게 수동적인 반복 주기보다 더 빠르게 제품을 발전시킬 수 있습니다.

아래의 임대 부동산 사례는 이러한 루프가 실제로 어떻게 작동하는지 보여줍니다. 실무자의 수정 사항이 어떻게 구조화된 발견 사항이 되고, 이어 평가 대상이 되며, 최종적으로 Codex의 범위가 지정된 엔지니어링 작업으로 변하는지 과정을 안내합니다.

임대 소득 (Rental property income)은 개인 세무 신고서의 Schedule E에 보고됩니다. 엔지니어링 관점에서 이를 추출하는 작업은 설명하기는 간단하지만, 제대로 수행하기는 어렵습니다. 시스템은 지저분한 원본 자료(수기 메모, 이메일, 스프레드시트 및 기타 고객 파일)를 읽어야 하며, 세무 엔진 (tax engine)에 확신을 가지고 매핑할 수 있는 임대 부동산 필드 (rental-property fields)를 추출해야 하고, 실무자 (practitioner)가 결과를 승인하거나 수정할 수 있도록 충분한 근거를 보존해야 합니다. 아래의 단순화된 예시는 이러한 원본 파일과 추출된 출력물이 어떤 모습일 수 있는지를 보여줍니다.

임대 부동산 원본 패키지는 하위 세무 엔진 개념으로 매핑되기 전에 인용된 필드 (cited fields)로 정규화됩니다.

에이전트가 예측한 값과 실제 제출된 세무 신고서의 값 사이의 차이는 실제 추출 오류를 반영할 수도 있지만, 실무자의 선호도, 세무 엔진 내 이전 연도 신고서에서 이월된 값, 또는 신고 워크플로우 (filing workflow)의 다른 곳에서 도입되거나 변경된 값일 수도 있습니다. 실무자들은 우리가 이러한 사례들을 식별하여, 어떤 조치가 실무자의 수정이 필요한지 또는 제출을 차단하는지를 파악할 수 있도록 도와주었습니다.

우리는 이러한 수정 사항들을 상세히 볼 수 있었기 때문에, 검토 프로세스를 실패 후 수행하는 최종 단계에서 지속적인 학습 사이클 (continuous learning cycle)로 전환했습니다. 우리는 전문가의 조치를 구조화된 데이터 (structured data)로 캡처하도록 워크플로우를 설계했습니다. 이제 모든 개입은 Tax AI가 무엇을 제안했는지, 실무자가 무엇을 수정했는지, 그리고 최종적으로 제출된 신고서에 무엇이 반영되었는지를 정확히 기록함으로써 제품의 개선 루프 (improvement loop)에 기여합니다.

임대 부동산 (rental properties)과 같이 복잡한 워크플로우의 경우, 시스템은 소스 파일 (source files)과 제출된 신고서 (filed return) 사이에서 발생하는 과정을 보존해야 합니다. 그 과정 속에서 문서는 정리, 분할 및 분류되며, 임대 부동산 필드 (rental-property fields)는 소스 자료에 대한 인용 (citations)과 함께 추출됩니다. 추출된 값들은 세무 엔진 (tax engine)으로 매핑되며, 실무자 (practitioners)들은 신고 전 이를 수정할 수도 있습니다. 이러한 제품 수준의 추적 (product-level traces)을 통해 실패가 어디에서 발생했는지 조사하는 것이 가능해집니다. 실무자의 수정을 유용한 평가 대상 (evaluation targets)으로 전환하기 위해, 시스템은 다음 세 단계를 거쳐 이를 처리합니다:

차이점 포착 (Capture the difference): Tax AI의 출력값을 제출된 신고서와 비교하여, 예상 값 (expected value), 예측 값 (predicted value), 그리고 해당 차이점이 조치 가능한지 (actionable) 여부를 담은 필드 수준의 검토 행 (field-level review rows)을 생성합니다.

관련 실패 그룹화 (Group related failures): 유사한 검토 행들을 그룹화하여 반복되는 제품의 실패를 예상 가능한 워크플로우 노이즈 (workflow noise)와 분리합니다. 예를 들어, 반복적인 실무자 수정 사항은 Tax AI가 공정 임대 일수 (fair-rental-day) 필드를 자주 놓치거나, "기타 비용 (other expenses)"를 잘못 처리하거나, 동일한 소스 패키지 내의 여러 임대 부동산을 혼동한다는 것을 보여줄 수 있습니다.

반복되는 패턴을 평가 대상으로 전환 (Turn repeated patterns into eval targets): 검토 및 측정이 완료되면, 반복되는 발견 사항들은 Codex가 개선할 수 있는 명확한 평가 대상 (eval targets)이 됩니다.

임대 부동산 검토 행은 반복되는 제품의 실패를 예상 가능한 노이즈와 분리한 다음, 조치 가능한 사례들을 Codex가 극복해야 할 과제 (a hill to climb)인 평가 대상으로 전환합니다.

세 번째 기둥은 이러한 새로운 평가 (evals)에 대응할 수 있는 엔지니어링 루프 (engineering loop)를 구축하는 것입니다. 바로 이 지점에서 Codex가 핵심적인 역할을 수행하게 됩니다.

우리의 평가 파이프라인 (eval pipeline)이 실무자들은 안정적으로 채우고 있는 반면, Tax AI는 "공정 임대 일수 (fair rental days)" 필드를 지속적으로 놓치고 있다고 표시한다고 가정해 봅시다. 이 발견 사항은 이미 대표적인 소스 패키지와 예상 출력값을 포함한 타겟팅된 평가 세트 (targeted eval set)로 패키징되어 있기 때문에, Codex는 제품 스캐폴드 (product scaffold) 내에서 직접 근본 원인 (root cause)을 조사할 수 있습니다.

Codex는 단순히 수준 미달의 최종 출력물(sub-par final output)만 가지고 작업하는 것이 아닙니다. Codex는 트레이스 (trace), 평가 (eval), 리포지토리 (repo), 그리고 스킬 (skills)을 함께 조사합니다:

파이프라인 조사 (Investigate the pipeline): 소스 패키지, 추출 스키마 (extraction schemas), 매퍼 (mapper) 동작, 그리고 코드 경로를 조사하여 문제가 지원되지 않는 필드인지, 누락된 추출 패턴인지, 소스 선택 문제인지, 매퍼의 공백인지, 아니면 평가자 (grader)의 문제인지를 결정합니다.

타겟팅된 수정 구현 (Implement targeted fixes): 추출 스키마를 확장하거나, 임대 부동산 문서에 대한 소스 선택을 개선하거나, 세무 엔진 (tax-engine) 매퍼를 업데이트하거나, 예상되는 워크플로우 노이즈가 실패로 집계되는 경우 평가자 (grader)를 정교화합니다.

검증 및 제안 (Validate and propose): 타겟팅된 평가 (eval)를 재실행하고, 더 광범위한 회귀 테스트 (regression suites)를 실행하며, 엔지니어링 검토를 위한 후보 풀 리퀘스트 (pull request)를 생성합니다.

루프 폐쇄 (Close the loop): 반복되는 실무자의 수정을 측정 가능한 엔지니어링 작업으로 전환합니다. 만약 증거가 모호하거나 안전하게 자동화할 수 없는 경우, 해당 케이스는 루프를 통해 강제로 처리되는 대신 제품 팀으로 다시 라우팅됩니다.

엔드 투 엔드 (end-to-end) 자기 개선 루프: 프로덕션 트레이스 (production traces)는 반복되는 필드 수준의 수정을 드러내며, 이는 Codex가 트레이스, 평가 (evals), 리포지토리 (repo), 스킬 (skills)과 함께 조사할 수 있는 실패 신호가 됩니다. 실행 가능한 패턴은 제한된 평가 (bounded evals)와 후보 제품 변경 사항이 되며, 모호한 케이스는 검토를 위해 엔지니어에게 다시 라우팅됩니다. 배포된 각 개선 사항은 다음 사이클을 위한 새로운 프로덕션 증거를 생성합니다.

임대 부동산 예시는 더 넓은 재사용 가능한 패턴, 즉 에이전트의 능력을 향상시키기 위해 프로덕션 아티팩트 (production artifacts)와 트레이스를 사용하는 방식의 전형적인 사례입니다. 프로덕션 데이터에서 검토된 결과, 소스 트레이스, 예상되는 세무 엔진 출력, 관련 코드 예시, 그리고 평가 (eval) 명령어를 입력 세트로 제공하면, Codex는 몇 주 또는 몇 달에 걸쳐 성능과 정확도를 실질적으로 향상시킬 수 있습니다. 이는 작업을 Codex가 읽기 쉽게 만들고, 범위가 지정된 컨텍스트와 도구를 제공하며, 검증과 인간의 검토를 환경의 일부로 유지하는 방법을 설명하는 하네스 엔지니어링 (harness engineering) 및 __Symphony__에 관한 연구에서 기술된 원칙을 기반으로 합니다.

그러한 증거가 자동으로 Codex 작업(task)이 되는 것은 아닙니다. 실무자의 수정 사항은 추출 누락(extraction miss), 매핑 문제(mapping issue), 지원되지 않는 제품 동작, 세무 판단, 또는 예상되는 워크플로우 노이즈(workflow noise)를 반영할 수 있습니다. 반복되는 차이점들이 검토되고 실행 가능한 발견 사항(actionable finding)으로 그룹화된 후에야, 시스템은 이를 명확한 성공 조건이 있는 제한된 작업(bounded task)으로 전환합니다.

우리는 이러한 자동화를 제품의 제한된 계층(bounded layer)에 적용합니다. 이 계층은 추출을 수행하고 소스 문서를 세무 워크플로우(tax workflows)로 매핑합니다. 엔지니어는 아키텍처, 제품 결정 및 배포(shipping)에 대한 책임을 유지합니다. 실무자는 추출된 값을 수정하고, 신고서(returns)를 검토하며, 최종 신고(filings)를 승인하는 등 이미 수행하고 있는 업무를 통해 개선 루프(improvement loop)를 조종합니다.

Codex의 결과물은 모호한 경고가 아니라, 증거와 편집 가능한 제품 인터페이스(product surfaces), 그리고 명시적인 검증 게이트(validation gates)를 갖춘 범위가 정해진 엔지니어링 작업입니다. 대표적인 임대 부동산 작업에 대한 컨텍스트는 다음과 같이 요약될 수 있습니다: