HTML 시뮬레이터로 의사결정하기

치과의사신문 + 덴탈위키 공동기획 「노션 기반 치과 경영관리 시스템 구축」 ⑥

1. 같은 질문에 매번 다른 답을 하고 있지 않나

“직원 급여를 300만 원으로 올리면 병원이 얼마를 더 부담하나요.”

컨설팅 현장에서 가장 자주 받는 질문 중 하나다. 경험과 직관에 기댄 답은 대개 “한 30만원쯤 더 들어갑니다” 같은 형태로 나온다. 틀린 답은 아니다. 문제는 재현성이다. 같은 질문을 다음 달에 다시 받으면 답이 조금 달라지고, 다른 사람이 답하면 또 달라진다. 근거를 물으면 설명이 길어지고, 요율이 바뀐 해에는 갱신 자체를 잊는다. 직관은 빠르지만 검증할 수 없고, 전달할 수 없고, 갱신되지 않는다.

시뮬레이터 기반 의사결정은 이 세 가지를 뒤집는다. 입력 값이 화면에 남으니 검증할 수 있고, 파일 하나를 넘기면 전달되며, 참조테이블만 교체하면 갱신된다. 무엇보다 답을 하나만 주지 않는다. 숫자를 바꿔가며 스무 번 물어볼 수 있다. 의사결정의 질은 정답을 아는 데서 오지 않고, 대안을 몇 개나 비교해 봤는가에서 온다.

2. 입력부와 출력부 : 시뮬레이터의 뼈대

모든 시뮬레이터는 입력부와 출력부로 갈린다.

예시로 든 급여 계산기는 왼쪽 한 열이 입력부, 오른쪽 전체가 출력부다. 입력부에는 과세급여·식대·자가운전보조금·출산보육수당·기타 과세수당 다섯 칸과, 접어둔 원천징수 설정(공제대상 가족 수, 8~20세 자녀 수, 간이세액 비율, 국민연금 상한액), 그리고 사업장별 보험 요율 조정이 들어간다. 출력부에는 상단 요약 카드 세 장, 근로자·사용자 명세 두 장, 항목별 비교표 한 장이 놓인다.

이 분리가 중요한 이유는 만져도 되는 것과 만지면 안 되는 것을 화면이 스스로 구분해 주기 때문이다. 출력부의 숫자는 손으로 고칠 수 없고, 값을 바꾸려면 반드시 입력부로 돌아가야 한다. 엑셀에서 흔히 벌어지는 사고, 즉 수식 칸에 숫자를 덮어써서 표 전체가 조용히 망가지는 일이 구조적으로 불가능해진다.

3. 근로자 명세와 사용자 명세 : 하나의 급여, 두 개의 숫자

같은 급여를 두 개의 눈으로 본다. 근로자에게 급여는 세전급여에서 원천징수를 뺀 실수령액이고, 사용자에게 급여는 지급 총액에 4대보험 사용자 부담분을 더한 실부담액이다. 첫 화면의 예시에서 세전 320만원은 근로자에게 282만 6,700원(88.3%)으로, 사용자에게 352만 620원(110.0%)으로 나타난다.

이 간극이 급여 협상에서 벌어지는 거의 모든 오해의 출발점이다. 직원은 실수령액으로 말하고 병원은 실부담액으로 말한다. 두 번째 화면은 그래서 질문을 거꾸로 돌린 결과다. 세후 300만원을 맞추려면 세전은 341만 2,770원이어야 하고, 그때 사용자 실부담은 375만 6,100원이 된다. 계산기가 없으면 이 대화는 결론이 나지 않는다.

4. 세전·세후와 과세·비과세 : 성격이 다른 두 개의 축

가장 자주 섞이는 두 쌍이다. 세전과 세후는 시간의 축이다. 지급이 결정된 금액에서 원천징수를 거쳐 통장에 들어가기까지의 전후 관계다. 과세와 비과세는 성격의 축이다. 같은 세전급여를 세금과 보험료의 기준이 되는 부분과 되지 않는 부분으로 가른 것이다.

두 축은 직교한다. 세전급여는 과세급여와 비과세급여의 합이고, 세후급여는 세전급여에서 원천징수를 뺀 값이다. 비교표 오른쪽 상단에 ‘기준급여’가 따로 표시되는 이유가 여기에 있다. 국민연금·건강보험·고용보험·소득세가 모두 세전급여가 아니라 과세급여를 기준으로 계산되기 때문이다. 식대 20만원을 어느 쪽에 놓느냐에 따라 보험료와 소득세가 동시에 움직인다는 사실은 이 한 줄을 보고 나서야 실감된다.

5. 비과세급여 : 항목, 조건, 한도의 3단 확인

비과세는 이름만 알면 되는 것이 아니라 세 겹으로 확인해야 한다.

첫째는 항목이다. 법이 정한 목록에 있어야 한다. 치과에서 실무적으로 가장 자주 쓰이는 것은 식대, 자가운전보조금, 출산·보육수당 세 가지다.

둘째는 조건이다. 식대는 현물 식사를 따로 제공받지 않아야 하고, 자가운전보조금은 본인 명의 차량을 업무에 사용하면서 별도 실비를 받지 않아야 하며, 출산·보육수당은 자녀 연령 요건을 충족해야 한다.

셋째는 한도다. 예시 화면은 세 항목 모두 월 20만 원 한도로 설정되어 있다.

세 겹 중 하나라도 어긋나면 그 금액은 비과세가 아니다. 그래서 이 시뮬레이터는 한도 초과분을 지우지 않고 과세 기준급여로 자동 이월시킨다. 식대에 30만원을 입력하면 20만원만 비과세로 인정되고 나머지 10만원은 과세급여에 합산되어 보험료와 소득세를 함께 끌어올린다. 이 동작 하나가 “식대를 올려 실수령액을 늘리자”는 흔한 제안의 한계를 그대로 보여준다.

6. 4대보험 원천징수와 소득세 등 원천징수

통장에서 빠지는 돈은 한 덩어리로 보이지만 성격이 전혀 다른 두 갈래다.

4대보험 원천징수는 사회보험료다. 국민연금·건강보험·장기요양보험은 노사가 같은 금액을 나눠 부담하고, 고용보험은 근로자가 실업급여분만, 사용자는 여기에 고용안정·직업능력개발분을 더해 낸다. 산재보험은 사용자 전액 부담이라 근로자 칸이 0원이다. 비교표에서 근로자 열과 사용자 열이 나란히 채워지는 구간이 여기다.

소득세 등 원천징수는 조세다. 근로소득 간이세액표에서 과세급여·공제대상 가족 수·자녀 수로 찾은 금액이 소득세가 되고, 지방소득세는 그 10%다. 사용자 부담은 없다. 병원은 대신 징수해 납부하는 역할만 한다. 비교표의 소득세·지방소득세 행에서 사용자 열이 0원인 이유다. 결정적인 차이가 하나 더 있다. 매월 떼는 소득세는 확정액이 아니라 예납액이며, 연말정산에서 다시 계산된다.

7. 월급여 원천징수와 퇴직급여 원천징수

같은 원천징수라도 월급여와 퇴직급여는 다른 세계다.

월급여는 종합과세 대상 근로소득이라 매월 간이세액표로 떼고 연말정산으로 정산하며, 4대보험료가 함께 공제된다. 퇴직급여는 분류과세다. 다른 소득과 합산하지 않고 지급 시점에 세액이 종결되며 연말정산에 합산되지 않는다. 계산 구조도 다르다. 퇴직소득에서 근속연수공제를 빼고, 근속연수로 나눈 뒤 12를 곱해 환산급여를 만들고, 환산급여공제를 거쳐 세율을 적용한 다음 다시 근속연수 비율로 되돌린다. 오래 근무할수록 세부담이 낮아지도록 설계된 구조이며, 퇴직급여에서는 4대보험료를 공제하지 않는다.

그래서 급여 시뮬레이터와 퇴직급여 시뮬레이터는 하나로 합칠 수 없다. 입력값이 다르고(월 단위 대 근속연수), 참조테이블이 다르며(간이세액표 대 근속연수공제표), 정산 시점이 다르다. 예시 화면에 퇴직급여가 없는 이유이자, 다음 모듈이 별도 파일이어야 하는 이유다.

8. 왜 프론트엔드 도구만으로 충분한가

치과병의원의 의사결정지원 시스템을 만들 때 서버와 데이터베이스부터 떠올리면 대개 그 프로젝트는 끝나지 않는다. 급여·상담·수납처럼 반복 판단이 필요한 영역은 HTML·CSS·JS 파일 하나로 끝내는 편이 옳다. 이유는 다섯 가지다.

• 배포 마찰이 없다 : 파일 하나를 메신저로 보내거나 노션에 임베드하면 끝이다. 설치도 로그인도 없다. 직원이 열지 않는 도구는 존재하지 않는 도구다.
• 데이터가 기기를 떠나지 않는다 : 급여는 병원에서 가장 민감한 정보다. 서버가 없으면 유출 경로도 없다. 브라우저에 남는 것은 요율 설정뿐이고 직원의 급여액은 어디에도 기록되지 않는다.
• 참조테이블을 코드에서 분리할 수 있다 : 간이세액표는 엑셀 업로드로, 4대보험 요율과 비과세 한도는 JSON으로 교체된다. 연초 개정 때 개발자를 부르는 대신 표만 갈아끼운다.
• 반응이 즉시다 : 숫자를 고치는 순간 다시 계산된다. 왕복 지연이 있으면 사람은 두세 번 만져보고 그만둔다. 만져보게 만드는 것이 교육 도구의 거의 전부다.
• 수명이 길다 : 프레임워크도 런타임도 없는 단일 파일은 몇 년 뒤 브라우저에서도 그대로 열린다. 그리고 통째로 AI에게 건네 고쳐 쓸 수 있을 만큼 작다.

9. 계산은 기계가, 확정은 사람이

시뮬레이터는 급여대장이 아니다. 4대보험 신고 기준, 비과세 인정 여부, 국민연금 기준소득월액의 결정 시점, 산재보험 업종요율에 따라 실제 금액은 달라진다. 화면 하단에 주석이 붙어 있는 이유이며, 그 문장은 장식이 아니라 사용 조건이다. 급여·보험청구·재무처럼 되돌리기 어려운 영역일수록 최종 검토는 담당자의 몫으로 남겨두어야 한다.

직관은 답을 하나 내놓지만, 시뮬레이터는 질문을 스무 번 하게 만든다. 경영이 나아지는 지점은 정답을 맞힌 순간이 아니라 물어볼 수 있는 질문의 수가 늘어난 순간이다.