설계 판단
세금 표는 재구현하지 말고 데이터로 넣는다
근로소득 간이세액표를 산식으로 다시 구현할지, 표 자체를 담을지 갈렸다. 매년 바뀌는 값에서 갈림길이 된다.
매달 떼는 소득세는 계산이 아니라 조회다
연봉 실수령액 계산기를 만들 때 4대보험은 간단했습니다. 요율을 곱하면 됩니다. 문제는 소득세였습니다.
매달 월급에서 떼는 소득세는 세율을 곱해 구하는 값이 아닙니다. 국세청이 미리 만들어 둔 근로소득 간이세액표에서 찾는 값입니다. 이 표는 근로소득공제, 기본공제, 특별소득공제와 특별세액공제 일부, 연금보험료공제, 근로소득세액공제를 전부 미리 반영해 만든 결과물입니다.
두 갈래
구현 방법이 갈렸습니다.
| 표를 데이터로 내장 | 산식을 코드로 재구현 | |
|---|---|---|
| 내는 값 | 매달 실제로 떼는 금액 | 연간 확정 세액 ÷ 12 |
| 사용자 기대 | 통장 입금액과 일치 | 월 공제액과 어긋남 |
| 데이터 | 약 646개 구간 × 11열 | 없음 |
| 매년 갱신 | 새 파일로 교체 (기계적) | 공제·세율 확인 (판단 필요) |
| 틀렸을 때 | 표가 통째로 어긋나 바로 보임 | 조용히 조금씩 틀림 |
데이터를 내장하는 쪽을 골랐습니다. 이유는 두 가지입니다.
첫째, "실수령액"을 검색하는 사람이 알고 싶은 건 통장에 꽂히는 숫자입니다. 연간 확정 세액은 연말정산 뒤의 이야기라 매달의 질문에 답하지 못합니다.
둘째, 갱신의 성격이 다릅니다. 표를 쓰면 매년 새 파일을 받아 변환 스크립트를 돌리면 끝입니다. 산식을 쓰면 매년 세법 개정 내용을 읽고 어디를 어떻게 고칠지 판단해야 합니다. 판단이 필요한 갱신은 미뤄지고, 미뤄지면 틀린 채로 남습니다.
파일 하나가 조사를 끝냈다
설계 단계에서 한동안 막혀 있었습니다. 간이세액표의 계산 방법 원문이 필요했는데 2차 자료들이 서로 다른 값을 적고 있었습니다. 자녀세액공제 금액만 해도 어떤 곳은 12,500원, 어떤 곳은 20,830원이었습니다.
확인되지 않은 숫자로 정답표를 채우면 그게 그대로 테스트 기준이 됩니다. 그래서 소득세 열을 비워 둔 채로 스펙을 냈습니다.
운영자가 공식 표 파일을 넣어 주자 한 번에 풀렸습니다.파일 첫 장의 비고에 계산 방법과 자녀세액공제 금액이 원문 그대로 있었습니다.찾아 헤매던 것이 데이터 옆에 붙어 있었던 셈입니다.
변환 스크립트는 조용히 실패하면 안 된다
표를 데이터로 바꾸는 스크립트를 쓸 때 검증을 같이 넣었습니다. 구간 수가 0인지, 하한이 상한보다 큰지, 구간 사이에 빈틈이 있는지, 표의 끝과 초과 구간 공식의 시작점이 맞는지.하나라도 어긋나면 파일을 쓰지 않고 즉시 중단합니다.
원본 형식이 조금 바뀌었을 때 절반만 읽고 조용히 성공하는 게 최악입니다. 그러면 잘못된 데이터가 배포되고, 숫자가 조금 이상한데 원인은 안 보이는 상태가 됩니다.
구간 폭이 균일하지 않았다
표를 파싱하고 나서 알게 된 것도 있습니다. 월급여 구간의 폭이 5천원·10천원·20천원으로 섞여 있습니다.낮은 구간은 촘촘하고 높은 구간은 성깁니다.
나눗셈으로 색인을 계산하려던 첫 구상은 그대로 버렸습니다. 이분 탐색으로 구간을 찾도록 바꿨고, 경계에서 어긋나지 않는지 테스트로 잠갔습니다.데이터를 실제로 열어 보기 전에는 구조를 가정하면 안 된다는 평범한 교훈입니다.