개념 해설 · 2026-09-02
답하기 전에 무엇을 물어야 하는가
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 번외편
세법 AI를 만들 때 처음에는 계산기를 조금 더 똑똑하게 만들면 될 줄 알았다. 사용자의 자산과 가족관계를 구조화하고, 관련 규칙을 찾고, 세율과 공제를 적용하면 된다. 질문이 들어오고 답이 나간다. 겉으로는 자연스러운 흐름이다.
하지만 이 흐름은 너무 빨리 결론으로 간다. 가업상속공제라는 규칙을 찾았다는 사실과, 그 규칙을 이 사람에게 적용할 수 있다는 사실은 전혀 다르다. 법률 AI에서 더 어려운 일은 답을 만드는 것보다 지금 가진 사실로 답해도 되는지를 판정하는 일이었다.
규칙을 찾은 뒤부터 질문이 시작된다
사용자가 “아버지가 보유한 비상장회사 주식을 상속받으면 세금이 얼마인가요?”라고 묻는다고 해보자. 시스템은 피상속인과 상속인의 관계, 비상장주식이라는 자산 종류, 대략의 평가액, 상속이라는 사건을 우선 구조화할 수 있다. 이 정도 정보면 가업상속공제는 충분히 후보 규칙이 된다.
그렇다고 곧바로 공제를 계산할 수는 없다. 이 프로젝트에서 모델링한 규칙에는 경영기간, 기업의 적격성, 지분 보유 요건, 상속인의 가업 종사처럼 따로 확인해야 할 사실들이 있다. 어떤 조건은 충족되어 있을 수 있고, 어떤 조건은 분명히 충족하지 않을 수 있다. 더 문제적인 경우는 아직 아무것도 모르는 조건이다.
보통 프로그램은 조건을 True와 False로 나누는 데 익숙하다. 법률 추론에서는 한 상태가 더 필요했다.
APPLICABLE
필요한 사실을 확인했고, 조건을 충족함
NOT_APPLICABLE
필요한 사실을 확인했고, 조건을 충족하지 않음
INSUFFICIENT_FACTS
판단에 필요한 사실이 아직 없음
가령 경영기간이 10년 이상인지 확인해야 하는데 기간 데이터가 없다면, 조건은 False가 아니다. 조건을 평가할 입력값 자체가 없다. 이를 False로 바꾸면 받을 수 있는 공제를 너무 일찍 제외하고, 반대로 추측으로 True로 바꾸면 받을 수 없는 공제를 적용할 수 있다. 둘 다 계산의 오류처럼 보이지만, 더 앞단의 질문 오류다.
법률 AI가 “모른다”를 표현할 수 있어야 하는 이유가 여기 있다.
모른다는 상태는 정지가 아니라 다음 질문의 입력값이다
처음에는 INSUFFICIENT_FACTS를 실패 메시지처럼 다뤘다. “정보가 부족합니다”라고 알리고 끝내는 식이다. 실제로 필요한 것은 부족하다는 선언이 아니라, 부족한 사실을 사용자가 답할 수 있는 질문으로 바꾸는 일이었다.
예를 들어 시스템이 모르는 것이 경영기간과 상속인의 가업 종사 여부라면, 물어야 할 것도 그 두 가지다. 기업 적격성과 지분 요건을 이미 알고 있다면 다시 묻지 않는다. 좋은 clarification은 친절한 말투보다, 어떤 빈칸이 결론을 바꾸는지 아는 문제다.
그래서 질문도 막연하면 안 된다. “정보를 더 알려 주세요”는 시스템의 부족함을 사용자의 숙제로 넘긴다. 반면 “피상속인이 해당 회사를 몇 년 동안 계속 경영했나요?”는 필요한 사실을 특정한다. 가능하다면 선택지도 그 사실의 단위와 맞아야 한다. 사용자는 법률의 내부 조건을 외울 필요가 없고, 자신의 경험을 답하면 된다.
여기서 대화는 추론 앞에 놓인 사용자 경험 레이어가 아니다. 추론이 스스로 발견한 결측을 메우는 연산의 일부다.
같은 질문도 관계를 모르고는 답할 수 없다
해외주식을 예로 들면 이 차이가 더 선명해진다. 자산의 평가액만 보고 해외금융계좌 신고 여부를 판단하려 하면, 주식이 어디에 보관되어 있는지라는 관계를 놓치게 된다. 국내 증권사 계좌인지 해외 금융기관 계좌인지가 먼저 구분되어야 하고, 그다음에야 필요한 잔액 사실을 확인할 수 있다.
중요한 것은 자산이라는 엔터티 하나가 아니다. 그 자산이 어떤 계좌와 연결되어 있는지, 그 계좌가 어느 관할에 놓여 있는지, 특정 시점에 잔액이 얼마였는지다. 온톨로지가 유용한 이유도 관계를 많이 저장할 수 있어서만은 아니다. 어떤 결론에 어떤 관계가 필요한지를 규칙과 함께 드러내기 때문이다.
혼인 전후의 증여를 묻는 경우도 비슷하다. 증여액만으로 답을 만들 수 없다. 이전 공제 사용 이력, 공제의 적용 가능 여부, 증여자와 수증자의 관계처럼 결과를 바꾸는 사실이 남는다. 결론을 서두르면 계산기는 가장 그럴듯한 숫자를 낼 수 있다. 질문을 먼저 설계하면 시스템은 그 숫자가 아직 나와도 되는지를 판정한다.
질문은 규칙의 바깥에서 하드코딩되면 곧 낡는다
여기까지 만들고 나면 질문 목록을 코드에 넣고 싶어진다. 가업상속공제 규칙이면 경영기간, 기업요건, 지분요건, 상속인요건을 묻는 템플릿을 if / elif로 연결하는 방식이다. 작동은 한다. 처음에는 가장 빠르기도 하다.
하지만 이 방식에는 작지만 중요한 거짓말이 들어 있다. 시스템이 무엇을 물어야 하는지 아는 것처럼 보이지만, 실제로는 규칙이 아니라 코드가 알고 있다. 규칙이 바뀌거나 새 규칙이 늘어날수록 질문 생성기는 법률 모델의 바깥에서 뒤따라가야 한다.
더 나은 구조는 규칙 평가 결과가 자신이 부족한 조건을 반환하게 하는 것이다.
RuleEvaluation
verdict: INSUFFICIENT_FACTS
satisfied_conditions:
- QualifiedEnterpriseCondition
- OwnershipCondition
missing_conditions:
- ManagementPeriodCondition
- HeirEngagementCondition
failed_conditions: []
이 결과를 받으면 질문 생성기는 ‘가업상속공제’라는 이름을 몰라도 된다. missing_conditions에 연결된 사실만 읽어, 사람에게 이해되는 문장으로 바꾸면 된다. 규칙은 판단에 필요한 사실을 선언하고, resolver는 어떤 사실이 비었는지 평가하며, 대화 레이어는 그 빈칸을 메우는 질문을 만든다. 질문이 규칙에서 파생되기 시작하는 지점이다.
계산기보다 먼저 필요한 것은 판단 과정이다
이 구조를 만들며 처음 생각했던 목표도 달라졌다. 세금을 계산해 주는 AI를 만들고 싶었지만, 계산은 생각보다 마지막에 있었다. 그 전에 사건을 분류하고, 사람과 자산의 관계를 묶고, 후보 규칙을 찾고, 조건을 평가하고, 모르는 사실을 구분해야 했다. 그리고 사용자가 답한 사실을 상태에 반영한 뒤, 같은 규칙을 다시 평가해야 했다.
질문
→ 현재 사실 구조화
→ 후보 규칙 탐색
→ 조건 평가
→ 결측 사실 발견
→ 추가 질문
→ 상태 갱신
→ 재평가
→ 계산과 설명
이 순서를 보면 대화의 위치가 달라진다. 대화는 규칙 엔진의 앞에 붙은 인터페이스도, 답변을 부드럽게 보이게 하는 장식도 아니다. 판정을 계속 가능하게 만드는 데이터 수집의 루프다.
그래서 좋은 법률 AI는 모든 질문에 바로 답하는 AI가 아닐 수 있다. 지금 가진 정보로 답할 수 있는지를 먼저 판정하고, 답할 수 없다면 무엇을 물어야 하는지를 아는 AI에 더 가깝다.
그 질문을 잘한다는 것은 말을 잘한다는 뜻이 아니다. 결론이 어떤 사실 위에 서 있는지 알고, 비어 있는 사실을 끝까지 False로 둔갑시키지 않는다는 뜻이다.
참고와 범위
이 글은 「가족 자산운용을 위한 세법 온톨로지 제작 프로젝트」에서 Rule Resolver, RuleEvaluation, missing_conditions, ClarificationSlot을 설계하며 얻은 구현 관찰을 바탕으로 한다. 여기서 쓴 상속·증여·해외계좌 사례는 시스템의 질문 구조를 설명하기 위해 가상화한 예시다.
이 글은 개별 거래의 세무 판단이나 절세 방안을 제공하지 않는다. 실제 판단에는 거래 시점에 유효한 법령, 당사자 관계, 자산 평가, 계약과 대금 지급 자료, 공제 사용 이력 등 구체적 사실관계와 전문가 검토가 필요하다.