부동산 AI Agent는 숫자를 말해도 되는지 어떻게 판단할까

“이 동네에서 제일 좋은 아파트가 어디예요?”

실거래 중간값을 내림차순으로 세우면 1위가 나옵니다. 그런데 그 단지는 최근 1년 거래가 열 건이 안 됐고, 재건축을 앞두고 값이 올라 있었어요. 실제로 그 동네에 살려는 사람이 먼저 보는 단지는 따로 있었습니다.

숫자는 맞습니다. 정렬도 맞고요. 답만 틀렸습니다.

복덕방 가재는 부동산 질문에 필요한 근거를 확인해 답하는 상담 Agent입니다. 지역과 단지, 거래와 가격, 기간처럼 상담에 필요한 데이터를 보고 고객의 질문에 답해요.

값을 꺼내는 일과 그 값을 답변에 쓰는 일 사이에는 확인해야 할 것이 하나 더 있습니다.

이 글은 데이터에서 꺼낸 값이 고객이 읽는 한 줄이 되기까지의 과정을 다룹니다. 이 숫자를 말해도 되는지를 어디에서 판단하게 했는지가 주제예요.

프롬프트로 지시해도 답변마다 달라집니다

처음에는 프롬프트를 고쳤어요. 원 단위의 긴 숫자를 그대로 내보내지 말 것, 단위를 확인할 것, 사람이 읽기 쉬운 표현으로 바꿀 것 같은 지시를 붙였습니다.

효과가 없지는 않았어요. 다만 같은 문제가 계속 다시 나왔습니다. Agent가 답변을 만들 때마다 숫자를 다시 해석하고 있었기 때문이에요.

원 단위를 억 원 단위로 바꾸는 규칙은 같은 입력에 같은 결과가 나와야 하는 일입니다. 예시를 충분히 붙이면 어느 정도는 맞아요. 다만 맞았는지를 매번 확인해야 한다면 그건 계약이 아니라 기대예요.

답변 한 줄이 나가기까지 숫자가 흔들립니다

고객이 이 단지 얼마냐고 묻습니다. 답변 한 줄이 나가기까지 Agent는 이런 일을 해요.

층마다 답하는 질문이 다릅니다. 앞 층이 답하지 못한 것이 다음 층으로 넘어가요.

그렇게 나가는 답이 “최근 1년 실거래 기준으로 38.75억 원입니다. 다만 거래가 2건이라 시세로 보기는 어려워요” 같은 한 줄이에요. 이 경로 어디에서든 숫자는 흔들릴 수 있었습니다. 단계마다 무엇을 고정했는지 차례로 보겠습니다.

1. 무엇을 묻는지부터 가릅니다

고객이 한 말이 그대로 조회 조건이 되지는 않아요. 같은 매물 이야기도 의도가 갈립니다. 조건에 맞는 매물을 찾아 달라는 요청과, 이미 봐 둔 매물이 괜찮은지 봐 달라는 요청과, 요즘 이 동네 매물이 어떤지 묻는 요청은 서로 다른 답을 받아야 해요.

이 판정을 상담 행동별 Skill이 맡습니다. 여기서 Agent Skill은 상담에서 자주 나오는 행동 하나를 어떻게 처리할지 적어 둔 문서예요. 어떤 값을 쓰고, 무엇을 확인하고, 무엇을 말하지 않을지가 여기에 들어갑니다.

전부 한꺼번에 읽히지는 않아요. 상담 전체에 걸리는 원칙은 항상 함께 주입되고, 매물 조회나 대출 상담처럼 행동이 갈리는 규칙은 그 의도로 판정됐을 때만 읽힙니다. 규칙이 늘 때마다 프롬프트 한 덩어리를 키우지 않으려는 이유이기도 해요.

단위 환산도 여기서 처리해요. 고객이 “50평 이상”이라고 하면 약 165㎡ 이상으로 바꿔 조회하고, 조건에 못 미치는 결과가 섞여 나오면 후보가 아니라 참고 사례로 낮춰 안내해요. 하드 조건을 만족하지 못한 결과를 후보처럼 늘어놓는 것이 실제로 자주 나던 오답이었습니다.

반대 방향도 정해 뒀어요. 고객이 “34평”이라고 말하면 그 조건은 그대로 유지하되, 근거 없이 “84㎡”라고 바꿔 단정하지는 않아요. 고객이 말한 숫자는 같은 단위의 조건 문맥 안에서만 다시 씁니다. 환산은 조회에 쓰는 값이고, 답변에 못 박는 값이 아니었습니다.

Skill이 담는 것은 말하지 않을 것만이 아니에요. 무엇을 조회하지 않을지도 적혀 있습니다. 스키마를 뒤지거나 전체 컬럼을 긁거나 없는 컬럼 이름을 추측하는 대신 안전한 필드 목록과 조회 템플릿을 먼저 쓰게 해 뒀어요. 이걸 열어 두면 Agent가 조회를 반복하다 상담이 느려집니다.

2. 값 옆에 읽는 법을 붙입니다

무엇을 묻는지 가렸으면 값을 꺼내옵니다. 그런데 처음엔 숫자만 잘 전달하면 되는 줄 알았어요.

부동산에서 가격은 한 종류가 아니에요. 실제로 체결된 실거래가가 있고, 파는 쪽이 부른 호가가 있고, 은행이 담보평가에 사용하는 BigValue 시세가 있어요. 셋은 값의 크기가 비슷해 보여도 만들어진 방식이 다르고, 서로 다른 질문에 쓰입니다.

그래서 숫자 자체는 관측값으로 두고, 그 숫자를 어떻게 읽어야 하는지는 별도 정보로 붙였어요. 무엇을 뜻하는 값인지, 권할 만한 표현은 무엇인지, 쓰면 안 되는 표현은 무엇인지가 값 옆에 함께 옵니다. 이를테면 시세에는 범위로 말하라는 표현과 호별 단정은 쓰지 말라는 표현이 함께 붙습니다.

BigValue 시세는 한 걸음 더 갔어요. 호별 단일 값이 아니라 하한과 상한을 가진 범위로 유지해요. 추정한 값이라는 성격을 문장으로 설명하는 대신 값의 형태로 드러낸 거예요. 범위로 내려온 값은 애초에 “이 집은 39억입니다”라고 말하기 어렵습니다.

숫자를 옮겨 적는 일과 그 숫자가 무엇인지 함께 옮기는 일은 다릅니다. 범위로 적힌 값은 그 형태만으로 단정을 막습니다.

이름도 문제였어요. 내부에서 쓰던 기간 지표 이름에는 365d가 붙어 있었어요. 관측 기간이 1년이라는 뜻이었는데, 한국어 이름은 어디에도 없었습니다. 지역이나 거래 유형 같은 축에는 한국어 라벨이 있었는데 기간 축에만 비어 있었고요.

이름이 없으면 모델이 지어냅니다. 답변에 “365일 실거래가”라고 나갈 수 있었던 거예요. 그건 데이터를 다루는 사람의 말이지 상담을 받는 사람의 말이 아니에요. 그래서 기간 축에 “최근 1년” 같은 한국어 라벨을 심고, 응답 규칙에 365일이라는 표기를 쓰지 않는다는 항목을 넣었습니다.

프롬프트로 이 문제를 풀 수는 없었습니다. 데이터에 없는 이름을 확인하라고 지시해도 모델에게는 확인할 대상이 없기 때문이에요. 지시문은 있는 정보를 잘 쓰게 만들지만, 없는 기준을 채워 주지는 못합니다.

3. 값을 말해도 되는지 판정합니다

값이 무엇인지 알아도, 지금 이 질문에 그 값을 써도 되는지는 또 다른 문제였어요.

저희가 데이터를 사용하는 규칙을 정하면서 함께 적어 둔 조건이 있어요.

표본 수가 적으면 단정하지 않는다

이 규칙을 그대로 구현했어요. 표본이 기준에 못 미치면 가격 값을 아예 내보내지 않게 했습니다.

돌려보니 반대쪽으로 넘어가 있었어요. 실거래가 한두 건뿐인 소형 단지에서는 Agent가 가격을 아무것도 말하지 못했어요. 고객은 그 단지 가격을 물었고, 데이터에는 실제로 체결된 거래가 있었는데, 화면에는 답할 수 없다는 말만 남았습니다.

문제는 판정 하나에 두 가지 질문이 겹쳐 있었다는 것이었어요. “이 숫자가 실제로 관측된 값인가”와 “이 숫자를 그 동네 시세로 대표해도 되는가”는 다른 질문이에요. 전자는 거래가 한 건만 있어도 참이고, 후자는 한 건으로는 성립하지 않습니다.

그래서 판정을 두 개로 나눴어요. 값을 말해도 되는지와 대표로 삼아도 되는지를 각각 따로 내려요. 표본만 부족한 경우에는 관측값을 단서와 함께 말하고, 대표 시세라는 단정만 막습니다. 근거 자체가 없거나 데이터가 오래된 경우는 여전히 값 진술까지 막고요.

기존 판정 필드는 지우지 않고 대표값 기준으로 남겨 뒀어요. 이미 그 필드를 보고 동작하는 쪽이 있었으니까요. 판단을 쪼개는 일과 계약을 깨는 일은 같이 갈 이유가 없었습니다.

4. 계산할 값과 말할 값을 나눕니다

이제 문장을 만들 차례예요. 그런데 이 자리에서 Agent가 숫자를 다시 손보면 앞의 판정이 소용없어집니다.

가격이 원 단위 정수로 저장되어 있다고 해볼게요. 이 값은 정렬하거나 일정 금액 이하만 걸러 내거나 차이를 계산하기에 좋습니다. 반면 고객에게는 자릿수가 긴 정수보다 “몇 억 원”처럼 바로 읽히는 표현이 낫고요.

그런데 숫자가 나가는 화면은 한 곳이 아니에요. 검색 결과 표에도 나오고, 매물 카드에도 나오고, 대화 답변에도 나옵니다. 각 화면이 원 단위 값을 받아 저마다 읽기 좋게 바꾸면 같은 값이 서로 다른 모양으로 갈라져요. 38.75억 원과 38억 7,500만 원과 약 39억 원이 같은 거래를 가리키게 됩니다.

그래서 저희는 두 값을 계약 수준에서 갈랐습니다. 저장된 원 단위 값은 관측값 그대로 두고, 표시값과 그 단위를 별도 필드로 함께 실어 보내요. 이를테면 한 건의 거래가가 관측값 3,875,000,000원과 표시값 38.75, 표시 단위 억 원으로 함께 실립니다.

값을 나눠 두면 Agent가 긴 숫자를 보고 매번 단위를 추정할 필요가 없어요. 이미 정해진 표시값 가운데 질문에 맞는 것을 고르고, 그 값이 무엇을 뜻하는지 설명하는 데 집중할 수 있어요. 검색 결과 표와 매물 카드와 대화 답변이 같은 표시값을 쓰면 숫자 표현을 결정하는 곳도 함께 줄어듭니다.

값과 단위는 따로 실려 와서 화면에 닿을 때 하나로 붙습니다. 이 글의 도식은 실제 구조를 공개용으로 다시 그린 것입니다.

5. 실행 직전에 한 번 더 막습니다

여기까지가 문서와 계약으로 정한 것들입니다. 그런데 문서는 지시일 뿐이에요. Agent가 그대로 따를 확률을 높일 뿐 실행을 막지는 못합니다.

그래서 두 지점에 실제로 걸리는 장치를 뒀습니다.

하나는 도구를 부르기 직전이에요. 부르려는 함수가 공개된 목록에 있는지, 인자 조합이 그 함수가 받기로 한 형태인지, 미리 막아 둔 조합에 걸리지는 않는지를 실행 전에 봅니다. 어긋나면 호출을 취소하고 무엇이 어긋났는지를 이유로 돌려줘요. 이유 없이 막기만 하면 Agent는 같은 호출을 다시 시도합니다.

다른 하나는 도구 결과가 나온 뒤입니다. 그 결과를 고객에게 보내기 전에 수치와 날짜가 맞는지, 빠진 정보는 없는지, 단정하면 안 되는 것을 단정하지 않았는지 확인해요.

전자는 잘못된 질문이 나가는 걸 막고, 후자는 잘못된 답이 나가는 걸 막습니다.

두 장치 모두 처음부터 차단으로 켜지 않았어요. 먼저 기록만 하는 모드로 운영 트래픽에 붙였습니다. 실제 상담에서 이 규칙이 몇 번 걸리는지, 걸린 것 중 정말 막아야 했던 게 몇 개인지를 보려는 거였고요. 규칙을 만든 사람은 오탐을 잘 못 봅니다. 자기가 짠 조건이라 걸릴 만한 것만 걸린다고 믿게 되거든요.

임계값은 사례 묶음 두 벌로 잡았습니다. 실제로 막았어야 하는 호출을 모은 쪽과 그대로 나갔어야 하는 호출을 모은 쪽을 따로 두고, 앞쪽이 전부 걸리면서 뒤쪽은 하나도 걸리지 않을 때까지 조건을 좁혔어요. 한쪽만 보면 규칙은 언제든 더 조이거나 더 풀 수 있습니다.

다만 관찰 모드에 오래 두면 안 됩니다. 기록은 임계값을 잡아 주지만 그 자체로 오류를 줄이지는 않아요. 쌓인 기록을 규칙으로 되돌려야 결과가 달라지고, 실제로 도구 호출 오류가 줄기 시작한 것도 차단으로 바꾼 다음이었습니다. 관찰은 도착지가 아니라 임계값을 정하는 구간이었어요.

마지막으로 표기가 새는 것도 막았습니다. 데이터베이스와 내부 함수가 쓰는 타입 표기와 밖으로 나가는 공개 표기를 다르게 두고, 변환은 서비스 경계 한 곳에서만 일어나게 했어요. 그리고 실제 응답에 내부 표기가 섞여 있지 않은지 확인하는 검사를 배포 절차에 넣어 뒀어요. 경로마다 변환을 따로 하면 어딘가는 반드시 빠집니다.

층마다 맡는 판단이 다릅니다

앞 도식에서 단계마다 붙어 있던 이름이 이 구분이에요. 어느 판단을 어디에 두는지가 기준이었습니다. 상담 맥락이 있어야 내릴 수 있는 판단은 Skill에 두고, 값 자체의 성격에서 나오는 판단은 값 옆에 붙여 보내고, 그 둘이 지켜지지 않은 채로 호출이나 답변이 나가려 할 때 마지막으로 막는 일은 실행 직전에 뒀어요.

프롬프트에 전부 적으면 매번 다시 해석되고, 데이터에 전부 맡기면 상담 맥락을 모르는 채로 판정이 내려져요. 층을 나누자 각 층이 답할 수 있는 질문도 분명해졌습니다.

남은 것도 있습니다. 표시 규칙은 계열이 늘 때마다 예외가 생기고, 관찰 모드에서 차단 모드로 넘기는 임계값은 데이터가 쌓이는 만큼 다시 잡아야 합니다. 상담 의도는 저희가 나눠 둔 것보다 늘 더 잘게 갈라지고요.

문장은 모델이 쓰고 나머지는 고정합니다

부동산 상담에서 숫자가 흔들리면 답변 전체를 믿기 어려워집니다. 고객은 그 숫자로 집을 비교하고 예산을 가늠하고 다음 행동을 정하니까요.

그렇다고 답변 문장을 통째로 정해 두면 상담이 되지 않습니다. 무엇을 먼저 설명할지, 어떤 비교가 이 고객에게 필요한지, 어디서 조심하라고 말할지는 모델이 훨씬 잘해요.

저희가 찾은 지점은 그 사이였어요. 문장은 모델이 씁니다. 대신 틀리면 안 되는 것만 층마다 고정합니다. 지표가 무엇인지, 언제 기준인지, 어디까지가 범위인지, 이 값을 대표로 삼아도 되는지 같은 것들입니다.

이제 그 동네에서 제일 좋은 아파트가 어디냐고 물으면 복덕방 가재는 한 단지를 짚어 주지 않아요. 거래가 가장 비쌌던 단지와 재건축 기대가 붙은 단지, 그리고 실제로 그 동네에 살려는 사람이 먼저 보는 단지를 갈라서 보여줍니다.

숫자는 처음과 같습니다. 달라진 것은 그 숫자를 어디까지 말해도 되는지 아는 것입니다.