종합 계산기 허브
운영 중결과 금액이 아니라 법령 조문까지 보여주는 무료 모의계산 78종
- 기간
- 2026-08 ~ 현재
- 커밋
- 198
- 계산기
- 78종
- 엔진 테스트
- 46개
- 채널
- 웹·MCP
기술 스택
- Cloudflare Workers
- Next.js
- OpenNext
- Playwright
- React
- Sentry
- Tailwind CSS
- TypeScript
- Zod
실제 화면 운영 중인 서비스를 그대로 캡처했습니다
2026-10-06 기준

개요
무엇이고 누구를 위한 것인가연말정산·증여세·양도세·실업급여 같은 세금 계산부터 확률·금융 시뮬레이션, 정부 지원정책 자격 판정까지 78종의 계산기를 한 곳에 모은 무료 서비스다. 대상은 세무 전문가가 아니라 "내 경우엔 얼마인지" 빠르게 확인하고 싶은 일반 사용자다.
다른 계산기와의 차이는 하나로 요약된다 — 숫자만 던지지 않는다. 모든 결과에 항목별 계산 과정과 근거 법령 조문(예: 소득세법 §55)이 함께 나온다. 같은 계산 엔진이 웹 포털과 MCP 서버 두 채널로 서빙돼, AI 어시스턴트가 이 계산기를 도구로 직접 호출할 수 있다.
문제
무엇이 문제였나세금 계산기는 검색하면 수십 개가 나오지만 대부분 세 가지 한계를 공유한다.
근거가 없다. 총액 하나만 보여주면 사용자는 그 숫자가 맞는지 검증할 방법이 없다. 자기 상황에서 어떤 공제가 적용됐는지, 어디서 한도에 걸렸는지도 알 수 없다.
시간이 지나면 조용히 틀린다. 세율과 공제 한도는 매년 개정된다. 계산 로직에 숫자가 박혀 있으면 어느 계산기가 몇 년도 기준인지 아무도 모르고, 작년 기준 결과가 화면에 아무 표시 없이 올해도 서빙된다.
법적 경계가 있다. 2026년 6월 개정 세무사법은 세무대리를 암시하는 표현을 제한한다. "대신 신청", "환급 보장" 같은 문구는 물론, 세무사만 쓸 수 있는 명칭을 서비스 자격처럼 표기하는 것도 문제가 된다. 계산을 잘하는 것과 별개로 무엇을 말하지 않을지가 설계 요건이다.
접근
어떻게 풀었나세 문제를 각각 구조로 풀었다 — 사람의 주의력에 기대지 않고, 틀릴 수 없는 형태를 만드는 쪽으로.
- 근거를 반환 타입에 강제했다. 모든 계산기는
calculate(input): CalcResult형태의 순수 함수이고, 결과에 항목별 계산 과정(steps)이 반드시 들어간다. 각 단계에 법률명과 조문이 붙는다. "총액만 던지는 계산기"는 타입 수준에서 만들 수 없다. - 법정 파라미터를 코드에서 분리했다(rules-as-code). 세율·공제 한도 같은 값은
engine/params/<연도>/에 연도별로 둔다. 개정이 나오면 코드를 고치는 게 아니라 새 연도 파일을 추가한다. 파라미터 파일마다 국세청·국가법령정보센터 등 1차 출처 URL과 검증일을 단다. - 엔진을 프레임워크에서 떼어냈다. 계산 엔진은 Next.js에 의존하지 않는 순수 TypeScript 모듈이라, 포털과 MCP 서버가 같은 코드를 쓴다. 계산 로직이 두 벌로 갈라지지 않는다.
- 법적 표현을 전역 규약으로 고정했다. "참고용 모의계산" 고지를 전역 footer에 두고, 세무대리를 암시하는 표현은 UI·메타데이터·문서 어디에도 쓰지 않는다.
주요 기능
사용자가 실제로 쓰는 것- 세금·노동 — 연봉 실수령액, 4대보험료, 연말정산, 증여세, 양도소득세, 종합소득세, 퇴직소득세, 실업급여 등
- 복지·지원정책 자격 — 기초생활수급, 근로·자녀장려금, 청년일자리도약장려금, 한부모가족 지원 등 판정형 계산기. 결과를 금액이 아닌 "자격 진단"으로 보여준다
- 보조금 카탈로그 — 보조금24 공공서비스를 코드표 역산으로 구조화하고, 지역별 페이지 243개를 프리렌더로 생성
- 확률·금융 — 베이즈 정리, 몬테카를로, 로또 확률(Powerball 프리셋 포함 영문판), 대출 이자, 복리
- 계산기 도우미(베타) — 자연어로 물으면 맞는 계산기를 찾아 실행한다. "실수령액 400만 원 받으려면 연봉은?" 같은 역산도 답한다
- 계산 히스토리 — 최근 계산을 기기에 저장하고 입력값을 그대로 복원
- 영문판 —
/en경로로 언어 무관 계산기(확률·금융)부터 해외 사용자에게 연다 - MCP 서버 — stdio(로컬)와 HTTP remote 두 transport. Claude 커넥터로 등록돼 claude.ai에서 계산기를 도구로 직접 호출할 수 있다
아키텍처
어떻게 구성돼 있나 engine/ ── 순수 TypeScript, 프레임워크 비의존
calculators/<id>.ts calculate(input) → { total, steps }
params/2025, 2026 세율·한도 + 1차 출처 URL·검증일
core/ 반올림·포맷 공용
│
├──▶ web/ (Next.js + OpenNext) ── Cloudflare Workers ── calculator.azclab.com
│ /calc/<id> 페이지 78개, 보조금 카탈로그, 지역 페이지 243개
│ 계산기 도우미: 찾기 → 실행 (숫자는 엔진만 만든다)
│
└──▶ mcp/ (MCP 서버) ── stdio · HTTP remote ── Claude 커넥터 등
list_calculators, calc_<id> 도구계산기 1종을 추가하는 일은 엔진 모듈 1개 + 테스트 1개 + 페이지 1개 + 레지스트리 등록으로 정형화돼 있다. 입력은 Zod 스키마를 거치므로 계산기마다 제각각인 방어 코드가 생기지 않는다.
기술적 의사결정
무엇을 고르고 무엇을 버렸나- 테스트 통과를 정확성의 근거로 쓰지 않기로 했다. 64종 전수 계산식 감사에서 오류 16건이 나왔는데, 그 전부가 기존 테스트를 통과하고 있었다. 테스트 기댓값이 잘못된 구현에서 역산돼 있었기 때문이다. 그래서 파라미터 검증과 별개로 "산식 감사"를 독립된 축으로 세우고, 결과를 소득대체율·실효세율 같은 상식 기준으로 역검산한다.
- 오류 유형 6가지를 체크리스트로 만들었다. 한도(cap) 누락, 산식 오독(연/월·곱/나누기), 별표 구간 임의 축약, 단서·예외 누락, 근거 조문 오기, 그리고 법에 없는 요건 날조. 마지막 유형은 다른 수치를 잘못 뒤집어 만든 것이었다 — 연 900만 원 한도를 12로 나눠 "월 75만 원 초과분만"이라는 존재하지 않는 요건이 생겼다.
- 챗봇에게 숫자를 만들 권한을 주지 않았다. 언어 모델은 그럴듯한 세액을 지어낼 수 있다. 그래서 모델이 쓸 수 있는 도구를 "계산기 찾기"와 "계산기 실행" 두 개로 좁혔다. 모든 금액은 실제 엔진이 내고 근거 조문도 엔진의
steps를 그대로 넘긴다. 화면에는 계산 결과 카드를 답변과 별도로 그려서, 답변 문장이 틀려도 카드의 숫자는 엔진 값이 되게 했다. - 도구를 계산기마다 만들지 않았다. MCP처럼 계산기 하나당 도구 하나로 넘기면 설명만 8.8만 자가 된다. 무료 모델(Groq)의 분당 토큰 한도가 8천이라 한 번에 넘친다. 찾기 → 실행 두 단계로 나눠 필요한 계산기의 입력 스키마만 넘긴다.
- 개별 상담은 거절하도록 설계했다. "제 경우 어떻게 신고해야 하나요" 같은 개별 사안 판단·절세 전략은 세무사법 영역이라 공식 창구로 안내한다. 주민번호·전화번호·계좌번호 형태의 입력은 AI로 보내기 전에 막는다.
- 파라미터를 DB로 옮기지 않았다. 운영 중 수정이 편해지지만 코드 리뷰·테스트·git 히스토리의 통제 밖으로 나간다. 법령 수치는 바뀌는 순간이 곧 감사가 필요한 순간이다.
- 무인 자동 갱신을 하지 않는다. 주간 감사가 정책 변동을 감지만 하고, 반영은 사람 승인 세션에서 한다. 소스별 크롤러를 상시 돌리는 것도 버렸다 — 사이트 구조가 바뀔 때마다 부서진다.
- 정책 변경 주기를 3계층으로 나눴다. 정기 고시(기준중위소득·최저임금, 연 1회), 세법 연례(12월 국회 → 2월 시행), 수시 정책(사업 공고). 계층마다 점검 시점이 달라 한 번의 연례 작업으로 몰리지 않는다.
- 전수 E2E는 한 브라우저로만 돌린다. 디바이스 매트릭스(chromium·webkit·firefox × 데스크톱 + iPhone·Pixel·iPad)는 스모크·반응형에만 쓰고, 78종 전수와 SEO 계약 검사는 chromium 하나로 돌린다. 6개 브라우저로 곱하면 시간만 늘고 얻는 게 없다.
결과
무엇이 달라졌나78종을 운영 중이며, 모든 결과 화면에 계산 과정과 근거 조문이 나온다.
- 검증 체계가 자리잡기 전 만든 계산기 24종에서 오류 13건이 나온 반면, 체계 이후 추가된 복지 15종은 오류 0건이었다. 차이는 파라미터 파일 헤더 — 항목마다 조문·고시번호·출처 URL이 달려 있으면 검증이 가능해진다.
- 통합 QA 첫 실행에서 실제 결함을 잡았다. Safari·iOS에서 모든
<select>가 23px로 찌그러지는 문제(다른 브라우저는 44px), 홈의 canonical 누락, 폼 최대값이 스키마 최대값을 넘던 필드 12개. - 프리렌더된 페이지가 실제로는 Worker에서 매 요청 다시 렌더되고 있던 문제를 찾아 정적 자산 캐시로 해소했다(
x-nextjs-cache: HIT확인). 빌드 로그의 "Static" 표시를 믿지 않고 응답 헤더로 확인해서 잡았다. - 같은 엔진이 웹과 MCP 두 채널을 서빙한다. 세율 개정은 코드 변경 없이 연도 파라미터 파일 추가로 반영된다.
배운 점
다시 한다면"전수 감사 완료"는 끝이 아니었다. 감사를 완료한 바로 그날 기준중위소득 7인 가구 값의 오류가 추가로 발견됐고, 이어서 시효가 지난 전제(이미 개편된 제도를 전제로 한 산식)라는 새로운 유형까지 나왔다. 정확성은 한 번 달성하는 상태가 아니라 계속 유지해야 하는 체계라는 것 — 그래서 파라미터 검증, 산식 감사, 정책 동기화를 각각 독립된 축으로 두고 주기를 따로 돌린다.