관점 에세이 · 2026-08-29
거래 다음에는 자산을 봐야 했다
관계와 거래의 그래프를 자산의 시간으로 이어, 보유와 처분에 따라 달라지는 세금 지도로 확장하기

앞선 세 편에서 만든 Resolver는 거래를 잘 본다. 누가 누구에게 자산을 이전했는지, 두 당사자가 어떤 관계인지, 사건이 직접 매매인지 증여 뒤 재양도인지, 빠진 사실은 무엇인지. 거래가 입력되면 어떤 규칙을 검토해야 하는지 찾는 길이 생겼다.
사람, 자산, 거래, 채무를 연결하고 거래에 양도인·양수인 역할을 두는 그래프는 자연스럽다. Property Graph라면 간선의 속성에 역할이나 금액을 넣고, 자산을 따라 거래 경로를 탐색할 수도 있다.
하지만 거래 하나를 잘 담았다고 자산의 시간을 담은 것은 아니다.
가족 자산운용에서 거래는 매일 일어나지 않는다. 자산은 오래 보유되고, 이자를 낳거나, 언젠가 팔 때 축적된 시간이 세금 계산으로 돌아온다.
질문이 바뀌었다.
이 거래에 어떤 규칙이 적용되는가?에서 이 자산은 보유하고 처분하는 동안 어떤 세금의 경로를 지나게 되는가?로.
거래 Resolver가 답하지 못하는 질문
가족 간 자산 이전은 사건 중심 질문이다. A가 B에게 넘긴 것인가. 대가가 있었는가. 직계존비속인가. 증여 뒤 다시 팔렸는가. 이런 질문은 거래 한 건과 그 앞뒤 사건을 중심으로 정리된다.
하지만 한 채의 주택을 가진 사람의 질문은 대개 여기서 멈추지 않는다. 언제 취득했는가. 지금 보유하고 있을 때 어떤 세금이 붙는가. 나중에 처분하면 무엇을 계산해야 하는가. 가족에게 이전하면 처분과 증여의 경계는 어떻게 나뉘는가.
같은 주택이지만 질문의 중심이 달라진다. 거래 Resolver가 보는 것은 화살표다.
Person A ──Transfer──> Person B
자산 관점이 보는 것은 시간 위의 물건이다.
Acquire ───── Hold ───── Dispose
└──────── Asset ────────┘
이 둘은 경쟁하는 모델이 아니다. 거래는 자산의 생애에서 일어나는 사건이고, 자산은 여러 거래와 보유 상태를 이어 주는 기준점이다. 다만 한쪽만 있으면 다른 쪽의 질문이 비어 있다.
한 자산의 최종 소유자만 보면 다음 두 경우는 비슷해 보일 수 있다.
A ──매매──> B
A ──증여──> B ──양도──> C
그러나 법은 같은 “자산 이동”으로 읽지 않는다. 사건의 종류, 같은 자산인지, 사건의 순서, 두 날짜의 간격, 그 사이의 세액 비교가 달라진다. 그래프는 사건을 끊기지 않은 경로로 저장하고, 온톨로지는 그 경로가 DirectSale인지 GiftThenSale인지처럼 법적 자격을 부여한다.
여기서 그래프와 온톨로지는 경쟁하지 않는다. 그래프는 사건을 잃지 않게 한다. 온톨로지는 사건을 같은 이름으로 뭉개지 않게 한다.
기존 구조에는 예금 자산에서 이자소득이 생기고 원천징수라는 과세방식이 붙는 연결이 있다. 반면 양도차익, 특히 실제 가족의 의사결정과 가까운 부동산 양도소득세는 이 자산 지도의 빈칸이었다.
자산의 시간은 세 개의 질문으로 나뉜다
자산을 보면 모든 세금을 한 덩어리로 부를 수 없다. 이번 로드맵에서는 취득, 보유, 처분이라는 세 축으로 나눠 현재의 커버리지를 표시하기로 했다. 이는 지금 당장 온톨로지의 새 클래스가 아니라, 무엇을 등록했고 무엇을 아직 모르는지 보여 주는 작업용 지도다.
| 자산의 국면 | 시스템이 묻는 질문 | 지금의 상태 |
|---|---|---|
| 취득 | 어떤 원인과 조건으로 이 자산을 취득했는가 | 거래·취득세 규칙 일부 존재 |
| 보유 | 계속 가지고 있는 동안 어떤 과세가 이어지는가 | 재산세·종합부동산세는 아직 미등록 |
| 처분 | 팔거나 유상 이전할 때 어떤 소득과 계산이 생기는가 | 부동산 양도소득세부터 등록 예정 |
이미 있는 TransactionPattern은 별도의 네 번째 축처럼 작동한다. 직접 매매인지, 직접 증여인지, 증여 뒤 재양도인지 같은 사건의 모양은 취득·보유·처분 중 어느 한 칸에만 갇히지 않는다.
그래서 로드맵은 다음처럼 읽는 편이 낫다. 취득·보유·처분은 자산이 시간 속에서 놓이는 자리다. TransactionPattern은 그 자리에서 실제로 일어난 사건의 모양이다.
Asset
├── 취득: 어떤 원인으로 들어왔는가
├── 보유: 어떤 상태로 지속되는가
└── 처분: 어떤 대가와 결과로 나가는가
TransactionPattern
└── 그 경로를 만든 사건은 어떤 형태였는가
이렇게 보면 "보유세를 아직 다루지 않는다"는 말도 더 정확해진다. 보유세가 중요하지 않다는 뜻이 아니다. 오히려 모든 자산군에서 보유 축의 커버리지가 아직 0이라는 사실을 드러내는 표식이다. 이번 슬라이스에 다 넣겠다고 약속하면, 부동산 양도소득세라는 첫 문제조차 흐려질 수 있다.
첫 번째 자산은 부동산이어야 했다
자산별 확장에는 순서가 필요하다. 예금 이자와 배당은 이미 자산-소득-과세방식의 연결로 일부 등록돼 있다. 다음 후보로는 국내 상장주식, 해외주식, 펀드와 ETF도 있다.
그런데 첫 번째는 부동산으로 정했다. 이유는 세율표가 단순해서가 아니다. 오히려 반대다. 취득 시점과 취득가액, 보유 기간, 처분 시점, 가족 간 이전, 채무, 예외가 한 자산에 길게 쌓인다. 사용자의 실제 자산 이전과 세대 분리 문제에도 직접 닿아 있다.
부동산은 이 프로젝트가 이미 배운 모든 것을 한꺼번에 요구한다.
관계. 사건. 시간. 가격. 증빙. 그리고 자산 자체의 이력.
그래서 부동산 양도소득세를 먼저 등록하는 일은 "부동산 세금 계산기"를 만드는 일이 아니다. RESIDENTIAL_REAL_ESTATE라는 자산이 어떤 취득 기록을 갖고 있고, 어떤 처분 사건과 연결되는지, 양도차익과 관련한 규칙을 어디에서 찾아야 하는지부터 다시 정하는 일이다.
순서는 부동산, 국내 상장주식, 해외주식, 펀드·ETF로 잡았다. 이것은 난이도 순서도, 시장 전망 순서도 아니다. 한 자산군씩 사실 모델과 규칙 모델의 연결을 검증하고 다음 자산으로 넘어가기 위한 순서다. 자산마다 소득의 성격과 과세 예외가 다르기 때문이다.
한 번에 자산 포트폴리오를 모델링하지 않는 이유
모든 자산의 취득·보유·처분 규칙을 한 화면에 올리고 싶어진다. 하지만 그런 목록은 완성도보다 빈칸을 감추기 쉽다. 예금 이자의 원천징수와 부동산 양도차익, 해외주식의 과세, 펀드와 ETF의 특례는 모두 "자산 세금"이라고 묶이지만 같은 입력과 계산 경로를 쓰지 않는다.
가령 부동산의 처분은 과거 취득 기록이 중요하다. 해외주식도 양도차익이라는 이름을 공유할 수 있지만, 자산 분류와 거래 시장, 계산과 공제의 조건이 다를 수 있다. 펀드와 ETF는 상품 구조에 따라 소득의 성격부터 분리해야 할 수 있다.
한 번에 다 넣으면 객체의 이름은 많아지지만 질문은 더 흐려진다. 어떤 사실이 특정 자산군에만 필요한지, 어디까지가 공통이고 어디부터가 예외인지 분간하기 어려워진다.
첫 자산군에서 실제 규칙 하나를 조회하고, 그 규칙이 요구하는 사실을 Customer 모델과 KB 사이에 연결한다. 그 연결이 다른 자산에도 재사용되는지 확인한 뒤에만 공통 구조로 올린다.
자산을 보는 것은 거래를 버리는 일이 아니다
자산 관점으로 옮겨도 1~3편에서 만든 구조는 남는다. 부동산을 처분하는 순간에도 양도자와 양수자가 있고, 거래 유형과 이전 취득의 방법·날짜가 있다. 가족 안에서 이전한다면 관계 기반 규칙도 다시 만난다.
다만 흐름의 시작점이 달라진다.
거래 관점
거래 입력 → 관계·패턴 → 후보 규칙 → 적용성 평가
자산 관점
자산 이력 → 취득·보유·처분의 질문 → 관련 규칙 → 필요한 거래 사실 확인
첫 경로는 이미 일어난 일이나 예정 거래를 평가하기 좋다. 두 번째 경로는 아직 팔지 않은 자산을 앞에 두고, 무엇을 기록해 두어야 나중에 판단할 수 있는지 찾기 좋다. 가족 자산운용에서는 후자의 시간이 더 길다. 거래는 짧고, 보유는 길다.
자산 관점은 “그래프 DB에 자산 노드를 하나 더 넣자”는 제안이 아니다. 이미 연결된 사건들을 어떤 기준점으로 다시 질문할지 바꾸는 일이다. 같은 자산을 따라가며 취득 기록, 보유 상태, 처분 사건, 가족 내 이전을 함께 봐야 시간 조건도 누락되지 않는다.
그래서 이번 확장은 Resolver에 기능 하나를 더하는 일보다, 시스템이 무엇을 기준으로 질문을 시작할 수 있는지 넓히는 일에 가깝다.
다음에는 스키마를 키우지 않는 이유를 쓴다
취득·보유·처분이라는 지도를 만들었다고, 그 이름을 곧바로 온톨로지의 클래스 이름으로 만들지는 않기로 했다. 지금은 TBox를 더 크게 만드는 것보다 부동산 양도소득세라는 실제 규칙이 어디에서 모델을 막는지 보는 편이 먼저다.
이미 TransactionPattern에는 직접 매매, 직접 증여, 증여 후 재양도 같은 형태가 있다. 그리고 부담부증여처럼 하나의 증여가 채무 인수분과 무상 이전분으로 갈라지는 사건은 이 패턴을 더 정밀하게 만들 구체적 이유가 된다.
다음 편에서는 왜 어떤 개념은 지금 구조화하고, 어떤 개념은 빈 자리로 남겨 두는지 쓴다. 온톨로지의 크기는 지식의 양이 아니라, 실제 질문을 놓치지 않는 경계에서 결정돼야 한다.
참고와 범위
이 글은 자산별 세금 커버리지를 확장하기 위한 설계 로드맵이다. 부동산 양도소득세, 보유세, 금융자산 과세의 실제 적용은 자산 종류, 취득과 처분의 시점·방법·금액, 보유 현황, 적용 법령과 예외에 따라 달라진다. 개별 거래의 세무 판단은 관련 자료와 당시 법령을 바탕으로 별도 검토가 필요하다.