25%→86%는 무엇을 뜻하나: 세무 에이전트의 교정 피드백을 평가로 바꾸는 법

“6주 만에 25%에서 86%”라는 수치만 보면 세무 신고서의 모든 필드가 86% 정확해졌다고 읽기 쉽습니다. 그러나 OpenAI와 Thrive Holdings가 설명한 Tax AI 사례의 지표는 다릅니다. 평가 대상 신고서 가운데 정답 필드 완성률이 최소 75%에 도달한 신고서의 비중이 출시 무렵 약 4분의 1에서 6주 뒤 86%로 올라갔다는 뜻입니다. 신고서 86%가 완벽했다는 말도, 전체 필드의 정확도가 86%라는 말도 아닙니다. 이 구분부터 해야 에이전트의 개선 루프를 설계할 때 목표를 잘못 잡지 않습니다.

OpenAI 글은 Crete의 참여 회계법인에서 이번 세금 시즌 7,000건의 신고서를 처리했다고 합니다. Crete 네트워크가 30개 이상의 회계법인을 포함한다는 설명은 참여 법인 수와 같지 않습니다. 1040·1041 신고서 준비에서 자료 추출과 세무 엔진 입력을 보조하지만, 회계사가 검토하고 최종 제출을 승인합니다. 이 사례는 전문 업무의 모든 판단과 신고가 자율화됐다는 발표가 아닙니다.

먼저 성과 지표를 분리해서 읽자

원문은 준비 시간 약 3분의 1 절감, 초안 정확도 최대 97%, 처리량 약 50% 증가도 보고합니다. 각각의 정의·분모·기준선이 충분히 제시되지 않았으므로 서로 곱하거나 “Codex 덕분에 생산성이 몇 배”라고 계산할 수 없습니다. 특히 최대 97%는 매 신고서에 보장되는 정확도가 아닙니다. 시즌 초에는 W-2·1099 중심이었고 뒤로 갈수록 K-1과 복잡한 스케줄을 다뤘다는 점도 고정 난이도의 전후 실험으로 읽지 말아야 할 이유입니다. 75% 문턱 지표의 평가 건수, 불확실성 구간, 통제군과 난이도별 구성은 원문에 없습니다.

75% 정답 필드 완성률 문턱을 넘은 평가 대상 신고서 비중이 출시 무렵 25%, 6주 뒤 86%인 출처 보고값 비교

75%는 신고서별 필드 완성 문턱, 25%와 86%는 그 문턱을 넘은 신고서의 비중. 분모와 구성은 공개되지 않았다. 출처: openai.com/index/building-self-improving-tax-agents-with-codex.

여기서 유용한 질문은 “몇 퍼센트 좋아졌나”보다 무엇을 고쳤을 때 어느 검증 문턱을 넘었는가입니다. 원문은 75%뿐 아니라 90%와 100% 필드 완성 문턱도 추적했다고 하지만, 이 두 문턱의 구체적인 시작·종료 수치를 본문에서 제공하지 않습니다. 따라서 그림에 임의의 막대를 채워 넣지 않았습니다. 별도로 언급된 임대 부동산 업무의 약 6주 후 정밀도·재현율 90%도 다른 과제의 다른 지표입니다.

수정된 값은 곧바로 ‘모델 오류’가 아니다

Tax AI는 고객 자료와 메모를 받아 원본 문서에서 필드를 추출하고 출처를 남긴 뒤, 세무 엔진 개념에 매핑합니다. 회계사는 제출 전 초안을 고칩니다. 초기에는 그 수정이 추출 실패인지, 필드 매핑 오류인지, 전년도 값의 승계인지, 담당자의 선호인지, 또는 업무 흐름 중 다른 곳에서 바뀐 값인지 구별하기 어려웠다고 원문은 설명합니다. 최종 신고서와 예측의 차이만 로그로 모으면 개선 대상을 오인할 수 있습니다.

따라서 원문에서 핵심 자산은 막연한 사용자 피드백이 아니라 원본 자료→인용된 추출 필드→매핑→제안 값→실무자 수정→최종 신고서를 잇는 제품 흔적입니다. 어느 단계에서 값이 달라졌는지 따라갈 수 있어야 전문가가 그 차이를 실제 결함인지 분류합니다. 민감한 세무 자료를 평가용으로 복제하라는 뜻은 아닙니다. 원문이 묘사한 Codex 작업 환경에서는 수정 가능한 작업 트리와 읽기 전용 생산 증거를 나눕니다. 실무 적용 시에는 권한·비식별화·보존 정책을 별도로 정해야 합니다.

원본 자료, 출처 딸린 추출, 세무 엔진 매핑, 전문가 교정, 최종 신고서의 연결 경로

어디서 값이 달라졌는지 추적해야 차이를 실패로 분류할 수 있다. 원문 설명을 재구성한 자체 도식이며 제품 화면이 아니다. 출처: openai.com/index/building-self-improving-tax-agents-with-codex.

독자용 결정표: 어떤 교정을 평가셋으로 만들까

먼저 최종값이 예측값과 다른 이유를 분류합니다. 차이 자체는 실패의 증거가 아니라 조사할 후보입니다. 아래 표는 OpenAI의 임대 부동산 사례를 바탕으로 편집자가 만든 판단 도구입니다. 원문의 자동 분류 규칙이나 실제 세무 데이터로 검증한 성능표는 아닙니다.

관찰된 차이 우선 확인할 증거 다음 처리
원본에 값이 있고 추출 결과에는 없음 문서 위치·추출 인용·필드 스키마 반복되는 누락인지 묶어 표적 평가 후보로 삼기
추출은 맞는데 세무 엔진의 다른 칸에 입력 추출 필드·매퍼 규칙·최종 필드 매핑 결함으로 분리하고 회귀 평가 추가
최종 신고서 값만 다른데 전년도 이월·다른 단계 변경 가능 변경 이력·실무자 설명·최종 기록 제품 오류로 단정하지 않고 보류
원본이 모호하거나 세무 판단이 필요 상충 자료·담당자 판단·권한 경계 자동 수정 작업 대신 전문가/제품팀에 회부

한 건의 차이를 발견했다는 사실만으로 Codex에 “해결하라”고 맡기지 않습니다. 같은 유형이 반복되는지 묶고, 예상 출력과 대표 자료가 검토됐는지 확인한 뒤, 수정 가능한 표면과 합격 조건이 정해진 평가 과제로 만듭니다. 문서 출처가 누락됐는지, 추출 스키마가 필드를 지원하지 않는지, 매퍼가 틀렸는지, 채점기가 정상적인 업무 변경을 오류로 계산하는지 가려야 합니다. 예를 들어 원문에 등장하는 임대일수(fair rental days) 누락은 루프를 설명하는 가정적 예시이지, 독립적으로 측정된 자동 수정 성공 사례가 아닙니다.

추출 누락, 매핑 결함, 정상 변경 또는 이월, 모호한 판단을 분리해 반복 검토된 결함만 평가 대상으로 삼는 결정 흐름

수정값의 원인을 먼저 판별한다. 원문 사례에서 도출한 편집자용 분류 예시이며 검증된 자동 분류기가 아니다. 출처: openai.com/index/building-self-improving-tax-agents-with-codex.

이 분류표는 OpenAI 사례를 바탕으로 편집자가 구성한 운영 판단 도구이며, 실제 세무 자료로 실행·검증한 자동 판정기나 세무 자문이 아닙니다.

‘자가 개선’의 실제 작업 범위

실무자가 검토한 반복 패턴을 평가셋으로 만든 다음에는 Codex가 흔적, 평가, 저장소와 작업 지침을 함께 살펴보며 제한된 수정을 제안할 수 있습니다. 원문이 예로 드는 수정 대상은 추출 스키마, 문서 선택, 세무 엔진 매퍼, 채점기입니다. 후보 변경에는 표적 평가와 넓은 회귀 평가가 따라붙고, 엔지니어가 검토할 풀 리퀘스트를 제안합니다. 모호한 차이는 제품팀으로 돌립니다. Codex가 납세자의 최종 신고를 스스로 승인하거나 변경을 자동 배포하는 구조로 설명하지 않았습니다.

운영 체크포인트를 하나의 문장으로 정리하면 이렇습니다. “전문가가 수정한 이유를 추적할 수 있고, 반복 결함에 대한 예상 출력이 합의됐으며, 제한된 코드 변경을 표적·회귀 평가와 사람 검토로 확인할 수 있을 때만 개선 작업으로 승격한다.” 이 조건 중 하나라도 빠지면 자동 루프의 속도보다 잘못된 레이블을 대량 생산할 위험이 더 큽니다. 이는 원문의 세 기둥—전문가 피드백, 생산 흔적, 평가 기반 Codex 반복—에서 도출한 편집상 절차입니다.

실무자 교정, 반복 패턴 검토, 표적 평가, Codex 후보 수정, 회귀 평가와 사람 검토의 제한된 개선 루프

후보 변경은 평가와 사람 검토를 통과해야 한다. 자동 신고나 자동 배포를 의미하지 않는 원문 기반 개념도. 출처: openai.com/index/building-self-improving-tax-agents-with-codex.

적용 경계와 확인할 것

OpenAI는 임대 부동산 지원에 약 6주와 상당한 엔지니어 감독이 필요했고 정밀도·재현율 90%에 이르렀다고 적습니다. 앞의 “6주 뒤 신고서 86%가 75% 문턱 통과”와 같은 실험이나 분모가 아닙니다. 두 수치를 결합해 전체 세무 업무의 성능을 계산하지 마세요. 또한 이 글은 공급자와 파트너의 자체 사례 설명이지 독립 무작위 평가가 아닙니다. 개선이 Codex 하나의 효과인지, 전문가·제품 흔적·평가·업무 난이도 변화 중 무엇의 기여인지 분리할 근거도 제공하지 않습니다.

자신의 전문 업무 에이전트에 가져갈 것은 86%라는 목표 숫자보다 수정 이유를 남기는 검토 단계, 재현 가능한 표적 평가, 넓은 회귀 검사, 사람의 최종 책임이라는 설계 경계입니다. 원문 자료의 출처, 적용 날짜, 평가 분모, 예외 처리, 민감 자료 접근 권한을 먼저 명시하세요. 이 패키지는 공개 사례를 분석한 글이며 Tax AI를 재실행하거나 실제 신고서를 시험하지 않았습니다. 관련 내부 글의 정확한 공개 URL과 본문 연관성을 이번 단계에서 독립 확인하지 못했으므로 내부 링크를 억지로 추가하지 않았습니다.

원문

댓글

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다