AI가 정리한 지출,
중복·환불까지 맞았을까?
“지출을 합쳐 줘”만으로는 무엇을 빼야 하는지 정해지지 않습니다. 같은 커피 두 잔은 실제 구매일 수 있고, 계좌이체는 소비가 아닐 수 있습니다. 이번에는 그 경계를 코드로 명시하고 직접 실행했습니다.
중복 1행과 본인 계좌 간 이체 1행을 제외했습니다. 근거가 부족한 4행은 보류했습니다. 따라서 49,500원은 전체 지출의 최종 확정액이 아닙니다.
“얼마 썼어?”에는 여러 답이 있습니다
계좌에서 나간 돈과 소비에 쓴 돈은 같지 않을 수 있습니다. 저축 계좌로 옮긴 돈까지 더하면 출금 규모는 알 수 있지만, 식비나 생활용품에 얼마를 썼는지는 알 수 없습니다. 환불이 들어왔다면 무엇을 돌려받았는지도 확인해야 합니다.
그래서 이번에는 질문을 좁혔습니다. “이 자료 안에서 확인되는 구매와 수수료를 더하고, 원거래에 연결된 환불을 차감한 금액은 얼마인가?”입니다. 이체를 제외하고 미확정 행을 따로 남기는 이유가 여기에서 나옵니다.
이 기준을 정하지 않은 채 AI에 합계만 요구하면, 계산이 정확해도 내가 원한 숫자가 아닐 수 있습니다. 이번 작업에서 먼저 만든 것은 보기 좋은 표가 아니라, 어떤 거래를 포함할지에 대한 규칙이었습니다.
이번에 AI가 실제로 한 일
AI 코딩 도우미가 거래 규칙과 실행 코드를 작성했고, 해당 코드를 실제로 실행해 별도로 계산한 정답과 비교했습니다. 방문할 때마다 AI를 호출하는 서비스는 아닙니다. 아래 실행은 브라우저 안에서 같은 규칙을 재현합니다.
개인의 실제 계좌 내역이 아닌 제작용 가상 자료입니다. 금융기관 연동·영수증 인식·자동 의미 추론을 검증한 사례가 아닙니다. 거래 유형과 본인 계좌 이체 여부는 입력에서 이미 확인됐다고 가정했습니다.
분류를 먼저 정했습니다
- 거래 ID와 주요 필드가 모두 같은 재수록만 중복으로 제외합니다. 금액과 상호가 같다는 이유로 지우지 않습니다.
- 명시된 본인 계좌 이체는 제외하되, 수수료는 별도 지출로 계산합니다.
- 환불은 구매 원거래와 연결되고 환불 합계가 원금 이하일 때 차감합니다.
- 같은 ID의 금액이 다르거나, 환불 원거래가 없거나, 유형이 불명확하면 보류합니다.
같아 보이는 거래, 왜 다르게 처리했을까?
① 4,500원짜리 커피 두 건은 남겼습니다
예제의 P2와 P3는 금액이 같지만 서로 다른 거래 ID입니다. 같은 날 커피를 두 번 살 수 있으므로, 금액이 같다는 이유만으로 하나를 지우면 실제 구매를 누락하게 됩니다. 두 건을 모두 포함해 9,000원으로 계산했습니다.
반대로 생활용품 P4는 ID·유형·금액·설명이 모두 같은 행이 두 번 들어 있습니다. 예제에서 이는 같은 거래의 재수록으로 정의했으므로 한 번만 반영했습니다. 이 판단은 거래 ID가 같은 원장 안에서 고유하다는 전제에 의존합니다. 서로 다른 은행 파일을 섞으면 ID가 우연히 같을 수 있어 그대로 적용하면 안 됩니다.
② 10만원 이체는 빼고 500원 수수료는 넣었습니다
T1은 ‘본인 계좌 간 이체’로 확인된 거래입니다. 이 기준에서는 소비로 보지 않아 제외했습니다. 하지만 F1의 수수료 500원은 다른 계좌에 그대로 남아 있는 돈이 아니므로 지출에 포함했습니다.
중요한 한계도 있습니다. 코드가 상대방 이름을 보고 본인 계좌인지 알아낸 것은 아닙니다. 예제에 이미 transfer라고 표시돼 있어 그 규칙을 적용한 것입니다. 실제 자료에 단순히 ‘이체’라고 적혀 있다면 상품 대금인지, 자기 계좌 이동인지 추가 확인이 필요합니다.
③ 같은 환불이어도 한 건은 빼고 한 건은 보류했습니다
R1의 20,000원은 생활용품 구매 P4에 연결돼 있습니다. 구매 50,000원보다 적은 일부 환불이므로 차감했습니다. 반면 R2의 3,000원은 원거래를 찾지 못했습니다. 전월 구매의 환불일 수도 있고 연결 정보가 빠졌을 수도 있습니다. 이번 자료만으로 판단할 수 없어 보류했습니다.
원거래를 찾지 못했다고 환불이 가짜라는 뜻은 아닙니다. 이번 집계의 근거가 부족하다는 뜻입니다. 원거래를 확보하거나 ‘이번 달 현금 유출입’처럼 다른 기준으로 질문을 바꾸면 처리도 달라질 수 있습니다.
④ 8,000원과 9,000원 중 하나를 임의로 고르지 않았습니다
P5는 같은 ID인데 금액이 다른 두 행입니다. 먼저 나온 행이나 더 작은 금액을 선택하면 깔끔한 결과는 만들 수 있지만, 어느 것이 맞는지 근거가 없습니다. 두 행 모두 보류하고 합계에 반영하지 않았습니다.
이 사례에서 보류 4행은 모두 별개의 거래 4건이라는 뜻도 아닙니다. P5의 두 행은 같은 ID의 충돌 자료입니다. 보류 ‘행 수’와 실제 미확인 ‘거래 수’를 구분해야 합니다.
직접 실행하고 확인하기
먼저 예제로 실행해 보세요. 파일을 사용하려면 아래 입력 형식에 맞춘 JSON이 필요합니다. 은행 CSV나 엑셀을 직접 읽는 기능은 아직 없습니다.
| 행 | ID | 원금액 | 반영액 | 판단 근거 |
|---|
결과를 별도로 검산했습니다
구매: 10,000 + 4,500 + 4,500 + 50,000 = 69,000원
수수료: +500원
연결된 일부 환불: −20,000원
확정 순지출: 49,500원
보류: 유형 미확인 1행 + 원거래 없는 환불 1행
+ 동일 ID의 금액 충돌 2행 = 4행행 순서를 뒤집어도 합계가 같은지, 금액이 같아도 ID가 다르면 둘 다 남는지, 원금보다 큰 환불을 보류하는지, 음수·소수 금액을 거부하는지도 실행 검사했습니다. 작은 가상 자료에서 통과한 결과이며 은행별 파일이나 실제 모든 거래 유형의 정확도를 뜻하지는 않습니다.
합계가 맞아도 원본 행이 사라졌다면 실패입니다
금액 검산과 함께 행 수도 대조했습니다. 원본 12행은 반영 6행, 중복 제외 1행, 이체 제외 1행, 판단 보류 4행으로 나뉩니다. 6 + 1 + 1 + 4 = 12이므로 처리 결과에서 빠진 행이 없습니다. 반영 6행에는 차감하는 환불 1행도 들어 있습니다.
금액과 행 수는 서로 다른 문제를 확인합니다. 합계가 우연히 맞더라도 두 거래가 서로 상쇄되며 빠졌을 수 있고, 행을 모두 남겼더라도 잘못 분류해 합계가 달라질 수 있습니다. 따라서 둘 다 확인했습니다.
금액 열을 그대로 더했다면 268,500원이 나옵니다
예제는 거래 금액을 모두 양수로 저장하고, 환불 여부는 type으로 구분합니다. 유형을 무시하고 amount만 더하면 268,500원입니다. 이는 환불·이체·중복·충돌까지 모두 더한 값으로, 이번 질문의 답인 확정 순지출과 다릅니다.
268,500원은 AI가 실제로 틀리게 답한 기록이 아닙니다. 같은 입력을 단순 합산하는 별도 방식으로 계산한 비교값입니다. 잘못된 AI 응답을 만들어 놓고 수정한 것처럼 보여주지 않았습니다. 우리가 검증한 것은 명시한 규칙에 따른 코드 실행 결과입니다.
어떤 변경에 견디는지도 확인했습니다
| 검사 | 확인할 실패 | 실행 결과 |
|---|---|---|
| 입력 행 순서 뒤집기 | 먼저 읽은 충돌행을 임의 채택 | 49,500원 유지 |
| 같은 금액·다른 ID | 정상 구매를 중복으로 삭제 | 두 건 모두 반영 |
| 동일 ID·다른 금액 | 하나를 정답으로 추정 | 두 행 보류 |
| 원금보다 큰 환불 | 검증 없이 과다 차감 | 환불 보류 |
| 음수·소수 입력 | 약속한 금액 형식 위반 | 처리 거부 |
여기서 통과했다는 것은 위 조건을 확인했다는 뜻입니다. 여러 금융기관의 원본 파일, 외화, 할부, 정산 시점 차이까지 검증했다는 뜻은 아닙니다.
내 자료에 적용하려면 이 순서로 진행하세요
- 목적을 한 문장으로 적습니다. 출금 총액을 알고 싶은지, 구매 순지출을 알고 싶은지부터 정합니다.
- 원본을 보존하고 사본을 만듭니다. 분석에 필요 없는 이름·계좌번호 등은 빼고, 행을 다시 찾을 수 있는 식별자는 남깁니다.
- AI에 열의 의미부터 확인시킵니다. 출금과 입금의 부호, 취소와 환불 표기, 통화와 기간이 불명확하면 합계부터 만들지 않도록 합니다.
- 처리 규칙과 보류 목록을 먼저 받습니다. 어디까지 자동으로 판단했는지 원본과 대조합니다. 미확정 내용을 사람이 알려주기 전까지 추정하지 않도록 합니다.
- 코드를 실행하고 금액·행 수를 대조합니다. 최종 합계뿐 아니라 포함·제외·보류 이유를 확인합니다.
- 다음 달에도 같은 형식인지 확인합니다. 열 이름이나 거래 ID의 의미가 바뀌면 이전 코드를 그대로 재사용하지 않습니다.
아래 요청문은 이런 순서를 전달하기 위한 예시입니다. 특정 AI 제품의 파일 처리 기능이나 답변 정확도를 보장하는 명령은 아닙니다.
같은 작업을 AI에 맡길 때 사용할 요청문
다음 자료를 단일 계좌의 원화 거래 원장으로 정리해 줘. 원본 행과 ID를 보존하고 거래 유형이 불명확하면 추측하지 마. ID와 주요 값이 같은 재수록만 중복 후보로 처리하고, 같은 ID의 값이 다르면 해당 ID의 모든 행을 보류해. 본인 계좌 간 이체로 확인된 행은 제외하고 수수료는 포함해. 환불은 원거래 연결과 누적 환불액을 검증한 뒤 반영해. 포함·제외·보류 이유를 행마다 표시하고 확정 지출과 미확정을 구분해. 사용한 코드를 제공하고 합계를 다른 계산으로 검산해. 은행 파일의 열 의미나 금액 부호가 불명확하면 먼저 부족한 근거를 알려줘.
결론: 계산보다 보류 기준이 중요했습니다
규칙이 정해진 정리·계산·검산 코드는 AI로 만들 수 있습니다. 하지만 자료에 없는 “이 돈이 소비인지 이체인지”는 계산만으로 알 수 없습니다. 이번 결과의 쓸모는 숫자 하나를 단정하는 대신, 자동으로 처리할 부분과 추가 확인할 부분을 나누었다는 데 있습니다.
실제 자료에 적용할 때는 거래 유형·부호·통화·기간을 먼저 맞춰야 합니다. 서로 다른 계좌의 ID를 그대로 섞거나, 전월 구매에 대한 환불을 이번 자료만으로 확정하면 잘못된 결과가 나올 수 있습니다.
직접 실행 파일은 이렇게 생겼습니다
아래는 구매 한 건과 그에 연결된 일부 환불입니다. amount는 음수를 붙이지 않은 원화 정수이고, 환불의 related가 구매 id를 가리킵니다. 예제 파일을 내려받으면 전체 12행을 볼 수 있습니다.
[
{"id":"P1","type":"purchase","amount":10000,"label":"구매"},
{"id":"R1","type":"refund","amount":2000,"related":"P1","label":"일부 환불"}
]지원하는 type은 purchase(구매), fee(수수료), refund(환불), transfer(확인된 본인 계좌 간 이체), unknown(유형 미확인)입니다. 금액은 원화 정수만 사용하고, 같은 파일 안에서 ID를 일관되게 유지해야 합니다. AI가 데이터를 이 형식으로 변환했다면 변환 결과 자체도 원본과 대조해야 합니다.
은행 내역을 그대로 붙여 넣어 알아서 변환하는 도구는 아닙니다. 이번 페이지의 직접 실행 기능은 공개한 처리 규칙을 재현하고, 형식이 맞는 작은 자료에서 판단 근거를 확인하는 용도입니다.
이 방식이 유용한 경우와 아직 맡기기 어려운 경우
매번 같은 형식의 자료가 들어오고 거래 유형의 의미가 분명하다면, AI가 작성한 코드를 반복 실행하는 방식이 유용할 수 있습니다. 매번 모든 행을 모델에 보내지 않아도 같은 기준으로 처리하고 이유를 남길 수 있기 때문입니다. 다만 이번 작업에서는 사람의 수작업 시간과 비용 절감률을 측정하지 않았습니다.
반대로 설명이 없는 출금이 많거나, 여러 계좌와 통화를 섞거나, 전월과 이번 달의 거래를 연결해야 한다면 추가 규칙이 필요합니다. 이 경우 합계를 빨리 내는 것보다 확인할 항목을 정확히 추리는 것이 먼저입니다. 현실의 모든 거래를 자동 분류했다고 말할 단계는 아닙니다.