부동산 AI Agent는 왜 데이터 마트만으로 충분하지 않았나

처음에는 데이터 마트를 연결하면 될 줄 알았습니다.

이 글은 부동산 AI Agent를 만들 때 데이터 마트, LLM tool 설계, 답변 근거 검증을 어떻게 연결해야 하는지에 대한 기록입니다. 특히 “좋은 데이터가 있는데도 왜 Agent 답변은 불안정해질까?”라는 질문에서 출발합니다.

BigValue에서는 부동산 데이터를 분석과 서비스에 활용하기 위해 여러 데이터 단위를 다뤄 왔습니다. 지역, 단지, 거래, 가격, 기간처럼 부동산 서비스를 만들 때 필요한 데이터는 이미 여러 형태로 정리되어 있었습니다.

그래서 부동산 AI Agent를 만들 때도 처음에는 생각이 단순했습니다.

이미 정리된 데이터가 있고, Agent는 자연어 질문을 이해할 수 있으니, 둘을 연결하면 부동산 질문에도 꽤 잘 답할 수 있지 않을까?

하지만 실제로 연결해보니 문제는 조금 달랐습니다.

좋은 데이터 마트를 갖고 있는 것과, 좋은 AI Agent를 만드는 것은 같은 일이 아니었습니다. 부동산 Agent에게 필요했던 것은 더 많은 데이터가 아니라, 데이터를 어떤 조건에서 사용해도 되는지에 대한 규칙이었습니다.

데이터 마트를 Agent에 연결하는 것보다 어려웠던 것은, 데이터를 어떤 조건에서 써도 되는지 알려주는 일이었습니다.

부동산 AI Agent에 데이터 마트를 바로 연결했을 때 생긴 문제

초기 구조는 단순했습니다.

사용자가 질문하면 Agent가 질문을 해석하고, 필요한 데이터를 찾아 SQL 또는 tool 호출로 데이터 마트에서 값을 가져온 뒤 답변을 생성하는 방식이었습니다.

사용자 질문
  → 부동산 AI Agent
  → 데이터 마트
  → 조회 결과
  → 답변

데모 수준에서는 이 방식도 꽤 그럴듯하게 동작했습니다. 예를 들어 “최근 A지역 아파트 가격은 어때?” 같은 질문에는 Agent가 관련 데이터를 찾고, 최근 거래나 평균 가격을 바탕으로 답변할 수 있었습니다.

문제는 질문이 조금만 실제 상담에 가까워질 때 드러났습니다.

부동산 질문은 겉으로는 짧지만, 안에는 여러 기준이 숨어 있습니다.

• “A지역”이 행정동인지, 법정동인지, 역세권인지, 생활권인지
• “최근”이 1개월인지, 3개월인지, 6개월인지
• “가격”이 실거래가인지, 매물가인지, 전세가인지, 평당가인지
• 매매와 전세를 같은 흐름으로 봐도 되는지
• 단지 기준 질문에 지역 평균을 써도 되는지
• 표본 수가 적을 때도 추세라고 말해도 되는지
• 데이터가 오래됐을 때 “요즘”이라고 답해도 되는지

Agent는 데이터를 가져올 수는 있었습니다. 하지만 값을 가져왔다는 것이 곧 답해도 된다는 뜻은 아니었습니다.

부동산 상담에서 가장 위험한 답변은 틀린 티가 나는 답변이 아니라, 기준이 빠졌는데도 자연스럽게 읽히는 답변이었습니다.

Agent가 데이터를 가져왔다는 사실만으로 답변이 맞아지는 것은 아니었습니다. 기준이 빠진 답변은 문장만 보면 자연스럽게 보일 수 있습니다.

예를 들어 사용자가 “이 동네 전세 괜찮아?”라고 물었는데, Agent가 매매 가격 흐름을 섞어 설명할 수 있습니다. 특정 단지에 대해 물었는데 지역 평균을 기준으로 답할 수도 있습니다. 최근 흐름을 묻는 질문에 표본 몇 건만 보고 상승세라고 말할 수도 있습니다.

이런 답변은 문장만 보면 자연스럽습니다. 하지만 실제로는 질문의 기준과 데이터의 기준이 어긋나 있습니다.

SQL을 만든다는 것과 부동산 질문에 답한다는 것은 달랐다

처음에는 테이블과 컬럼 설명을 더 자세히 주면 해결될 것이라고 생각했습니다.

예를 들어 Agent에게 이런 정보를 주는 방식입니다.

- 지역 코드: 지역을 식별하는 코드
- 단지 ID: 단지를 식별하는 값
- 거래 가격: 거래 금액
- 거래 일자: 거래가 발생한 날짜
- 거래 유형: 매매, 전세, 월세 등 거래 구분

이런 설명은 필요합니다. 하지만 충분하지는 않았습니다.

테이블 설명은 “어떤 데이터가 있는지”를 알려줍니다. 반면 부동산 질문에 답하려면 “그 데이터를 어떤 조건에서 해석해야 하는지”가 필요합니다.

예를 들어 “이 단지 가격이 오른 편인가요?”라는 질문에 답하려면 단순히 최근 가격과 과거 가격을 비교하는 것만으로는 부족합니다.

함께 봐야 할 기준이 있습니다.

• 같은 거래유형끼리 비교하고 있는가
• 같은 면적대끼리 비교하고 있는가
• 비교 기간은 적절한가
• 표본 수는 충분한가
• 최근 거래가 특이 거래일 가능성은 없는가
• 매물가와 실거래가를 섞어 말하고 있지는 않은가
• 지역 평균과 단지 평균을 혼동하고 있지는 않은가

SQL 생성은 이 중 일부만 해결합니다. 올바른 테이블을 찾고 조건을 걸어 값을 가져올 수는 있습니다. 하지만 그 값이 사용자 질문에 대한 답으로 충분한지 판단하는 일은 별도의 문제였습니다.

저희가 바꾼 것은 모델이 아니라, 모델이 데이터를 만나는 방식이었습니다.

Agent tool을 쿼리가 아니라 상담 행동 단위로 설계한 이유

가장 먼저 바꾼 것은 Agent에게 데이터 마트의 raw schema를 그대로 노출하지 않는 것이었습니다.

초기 방식에서는 Agent가 질문을 보고 직접 어떤 테이블을 볼지, 어떤 조건을 걸지, 어떤 값을 비교할지 결정해야 했습니다. 유연하다는 장점은 있었지만, 잘못된 grain의 데이터를 섞거나 질문의 기준을 임의로 채울 위험도 컸습니다.

그래서 데이터 마트와 Agent 사이에 한 단계의 인터페이스를 두었습니다.

사용자 질문
  → 부동산 AI Agent
  → Agent Skill
  → 상담 행동 단위 tool
  → 데이터 마트
  → 답변 근거 묶음
  → 답변 가능 여부 확인
  → 답변

Agent가 직접 “어떤 테이블을 조인할지”를 고르는 대신, “어떤 상담 행동이 필요한지”를 고르게 한 것입니다.

예를 들면 다음과 같은 단위입니다.

지역 가격 흐름 확인하기
단지 최근 거래 확인하기
주변 지역과 비교하기
매물가와 실거래가 차이 확인하기
표본 수 부족 여부 확인하기
기간별 변동성 확인하기

이렇게 하면 Agent의 자유도는 줄어듭니다. 대신 안정성은 올라갑니다.

모든 질문을 하나의 만능 SQL 생성기로 처리하면 빠르게 시작할 수 있습니다. 하지만 부동산 상담에서는 질문의 의도, 거래유형, 가격 기준, 기간, 표본 수, 최신성을 함께 다뤄야 했습니다. 그래서 구현 비용이 조금 더 들더라도, 자주 등장하는 상담 패턴을 tool 단위로 나누는 쪽을 선택했습니다.

단순 연결 구조에서는 Agent가 기준을 스스로 채워야 했습니다. 바꾼 구조에서는 Skill, tool, 근거 묶음, 답변 가능 여부 확인을 거치게 했습니다.

숫자 하나가 아니라 답변 근거 묶음이 필요했다

두 번째로 중요했던 것은 tool의 반환값이었습니다.

Agent에게 평균 가격 하나, 최근 거래 하나만 넘기면 Agent는 그 숫자를 중심으로 답변을 만듭니다. 하지만 부동산 데이터에서는 숫자 자체보다 그 숫자가 어떤 조건에서 나온 것인지가 더 중요할 때가 많습니다.

그래서 tool은 단순한 조회 결과가 아니라, 답변에 필요한 근거 묶음을 반환하도록 설계했습니다.

공개용 예시로 표현하면 다음과 같습니다.

{
  "question_basis": {
    "target": "지역 또는 단지",
    "transaction_type": "매매 또는 전세",
    "price_basis": "실거래가 또는 매물가",
    "period": "분석 기간"
  },
  "query_result": {
    "summary_value": "대표값",
    "comparison_value": "비교 기준값",
    "change_direction": "상승 또는 하락 또는 판단 보류"
  },
  "data_state": {
    "sample_size": "충분 또는 부족",
    "freshness": "최신 또는 확인 필요",
    "coverage": "제한 조건"
  },
  "answer_limitations": [
    "표본 수가 적으면 단정하지 않는다",
    "매물가와 실거래가를 섞어 말하지 않는다",
    "단지 질문에 지역 평균만으로 답하지 않는다"
  ]
}

여기서 중요한 것은 query_result만이 아닙니다.

question_basis, data_state, answer_limitations가 함께 있어야 Agent가 답변의 강도를 조절할 수 있습니다. 표본 수가 부족하면 “올랐다”고 단정하지 않아야 하고, 최신성이 낮으면 “최근 흐름”이라고 말하지 않아야 합니다. 질문 기준과 조회 기준이 다르면 답변을 보류하거나 다시 물어봐야 합니다.

값 하나만으로는 상담 답변이 되기 어렵습니다. 답변에는 값뿐 아니라 그 값을 써도 되는 조건이 함께 필요했습니다.

값 하나만으로는 상담 답변이 되기 어렵습니다. 가격 기준, 거래유형, 표본 수, 최신성, 답변 제한 조건이 함께 있어야 했습니다.

부동산 상담 Agent에서 중요한 것은 답변보다 답변 가능 여부였다

세 번째로 둔 장치는 답변 가능 여부 확인이었습니다.

Agent가 답변을 만들기 전에, 현재 근거만으로 사용자 질문에 답해도 되는지 확인하는 단계입니다.

확인하는 항목은 단순합니다.

• 질문 의도와 조회 결과의 유형이 맞는가
• 지역, 단지, 거래유형, 기간의 grain이 일치하는가
• 표본 수가 충분한가
• 데이터 최신성이 질문 의도에 맞는가
• 매물가와 실거래가를 혼동하지 않았는가
• 평균, 중위값, 대표값 표현이 적절한가
• 답변 제한 조건이 본문에 반영되었는가
• 추가 질문을 해야 하는 상황은 아닌가

공개용 pseudo flow로 표현하면 다음과 같습니다.

if 질문이 불명확하면:
    바로 조회하지 않고 추가 질문을 한다

if 표본 수가 부족하면:
    추세를 단정하지 않는다

if 데이터 최신성이 낮으면:
    최근 흐름이라고 표현하지 않는다

if 질문 기준과 조회 기준이 다르면:
    정밀한 답변처럼 말하지 않는다

otherwise:
    근거와 제한 조건을 함께 답변한다

이 단계는 Agent의 답변을 더 보수적으로 만듭니다. 대신 답변은 더 안전해집니다.

부동산 상담에서는 빠르고 자신감 있는 답변보다, 어떤 조건에서 나온 답변인지 분명히 말하는 것이 더 중요했습니다. 답변을 잘하는 Agent보다 먼저 필요했던 것은, 답해도 되는 상황을 구분하는 Agent였습니다.

좋은 데이터 마트가 좋은 AI Agent를 보장하지 않는 이유

이번 작업에서 가장 크게 배운 점은 “데이터를 많이 주면 Agent가 똑똑해진다”는 접근이 충분하지 않다는 것이었습니다.

부동산 데이터는 조건에 따라 의미가 달라집니다.

• 지역 단위인가, 단지 단위인가
• 매매인가, 전세인가, 월세인가
• 실거래가인가, 매물가인가
• 최근 1개월인가, 6개월인가, 1년인가
• 평균인가, 중위값인가
• 표본 수가 충분한가
• 최신 데이터인가
• 특정 면적대나 특정 거래에 치우쳐 있지는 않은가

Agent가 이런 조건을 고려하지 못하면, 데이터는 오히려 그럴듯한 오답의 재료가 됩니다.

그래서 저희는 부동산 Agent를 “데이터 마트에 연결된 챗봇”으로 보기보다, 데이터 마트 위에 Agent가 사용할 수 있는 상담 행동, 근거 묶음, 답변 가능 여부 규칙을 얹은 시스템으로 보고 있습니다.

데이터 마트
  → Agent Skill / 상담 행동 단위 tool
  → 답변 근거 묶음
  → 답변 가능 여부 확인
  → 사용자 답변

이 구조는 단순한 직접 연결보다 복잡합니다. tool을 설계해야 하고, 반환값의 계약을 관리해야 하며, 답변 제한 조건도 계속 보강해야 합니다.

하지만 그만큼 Agent가 데이터를 더 조심스럽게 사용하게 됩니다. 무엇을 알고 있는지뿐 아니라, 무엇을 모르는지도 표현할 수 있게 됩니다.

남은 과제

물론 이 구조가 모든 문제를 해결한 것은 아닙니다.

아직 개선해야 할 과제가 남아 있습니다.

첫째, evaluator와 guardrail을 더 정교하게 만들어야 합니다. Agent가 답변에서 거래유형, 기간, 표본 수, 최신성 같은 조건을 제대로 반영했는지 자동으로 평가하는 체계가 필요합니다.

둘째, trace를 더 잘 남겨야 합니다. 사용자 질문이 어떤 기준으로 해석되었고, 어떤 tool이 호출되었으며, 어떤 근거 묶음을 바탕으로 답변이 만들어졌는지 추적할 수 있어야 합니다. 그래야 실패한 답변을 재현하고 개선할 수 있습니다.

셋째, 응답 속도와 안정성도 계속 조정해야 합니다. 질문 해석, tool 호출, 근거 확인, 답변 가능 여부 확인 단계를 추가하면 품질은 좋아지지만 지연이 생길 수 있습니다. 어떤 단계는 캐싱하고, 어떤 단계는 비동기로 처리할지 운영 관점에서 계속 다듬어야 합니다.

마치며

좋은 데이터 마트는 부동산 AI Agent를 만들기 위한 중요한 출발점입니다. 하지만 데이터 마트만으로 Agent가 도메인 질문에 안전하게 답할 수 있는 것은 아니었습니다.

Agent에게 필요한 것은 더 많은 데이터라기보다, 데이터를 해석하고 사용할 수 있는 조건이었습니다.

저희가 배운 것은 단순했습니다.

• 질문을 데이터가 읽을 수 있는 단위로 정리하고
• raw query 대신 상담 행동 단위의 tool을 제공하고
• 결과값 하나가 아니라 답변 근거 묶음을 전달하고
• 답변 전에 답변 가능 여부를 확인해야 한다는 것

좋은 데이터 마트와 좋은 AI Agent는 다릅니다.

부동산 Agent를 만들며 저희가 가장 많이 바꾼 것은 데이터 자체가 아니라, Agent가 데이터를 만나는 방식이었습니다.