주소는 같은데 표현은 다르다: MCP로 공간 맥락을 식별하는 방법

“해솔아파트”, “가람로 19”, “해솔공원 맞은편 아파트”. 한 사람이 같은 단지를 두고 다르게 표현한 거예요. 앞선 대화를 아는 사람에겐 셋이 한 곳이라는 게 보여요. 그런데 Agent가 이 표현을 그대로 데이터 조회에 넘기면 서로 다른 결과가 나옵니다. 지역 단서를 놓치거나 비슷한 이름의 장소를 먼저 고르는 순간, Agent는 사용자가 의도하지 않은 공간에서 답을 찾기 시작합니다.

저희가 풀려던 문제는 표현을 하나의 표준 문자열로 바꾸는 일이 아니었어요. 주소, 지번, 건물명, 단지명, 랜드마크에서 장소 단서를 보존하고, 가능한 후보를 검증한 뒤, 다음 조회에 사용할 BigValue 공간 키를 확정하거나 보류하는 일이었습니다.

도로, 건물, 랜드마크는 서로 다른 종류의 단서지만 하나의 공간으로 모입니다. 이 글의 주소와 장소 이름은 실제 입력이 아니라 공개용으로 만든 예시예요.

전체 흐름은 다음과 같습니다.

주소 표현
  → 장소 토큰
  → 공간 후보
  → 후보 검증
  → BigValue 공간 키 확정 또는 보류
  → Agent 데이터 조회

여기서 공간 키는 BigValue 데이터에서 조회 대상을 안정적으로 연결하기 위한 식별 기준을 뜻하는 일반 표현이에요. 실제 키의 명칭·값·형식이나 내부 식별 체계는 이 글에서 다루지 않습니다. 마지막 단계의 Agent 데이터 조회는 사용자가 말한 이름이 아니라 확정된 공간 키를 기준으로 먼저 데이터를 찾는다는 뜻이고요.

게이트를 지나야 조회가 시작됩니다. 왼쪽에서 오른쪽으로 가는 동안 확정되는 건 장소가 아니라 확정해도 되는지에 대한 판단이에요.

같은 장소도 표현이 다르면 조회가 흔들립니다

사용자는 처음에 “해솔아파트를 찾아줘”라고 말해요. 원하던 곳이 나오지 않자 “가람로 19에 있는 곳”이라며 주소를 덧붙이고, 그래도 아니면 “해솔공원 맞은편 단지”라고 다시 설명하고요. 상대가 못 알아들을 때 말을 바꿔가며 좁히는 건 자연스러운 일이죠.

조회 시스템에 남는 건 문자열 세 개뿐입니다. 앞의 말과 뒤의 말이 한 장소를 가리킨다는 사실은 어디에도 적혀 있지 않아요.

문제는 표기 방식이 제각각이라는 데서 끝나지 않습니다. 단지명만 검색하면 같은 이름을 가진 다른 지역의 후보가 나오고, 도로명 숫자를 잘못 해석하면 인접 장소가 선택돼요. 어떤 조각을 지우고 어떤 조각을 남기느냐에 따라 결과가 갈립니다.

이 상태에서 첫 검색 결과를 바로 데이터 조회에 넘기면 이후 절차가 정상적으로 작동해도 답의 공간적 출발점이 달라져요. 시작이 어긋나면 그다음은 다 어긋납니다. 그래서 입력 표현을 곧바로 조회 조건으로 쓰지 않고, “이 표현들이 어느 공간을 가리키는가”를 먼저 확인하는 단계를 두었어요.

세 갈래 모두 결과가 나옵니다. 그래서 어느 쪽으로 갔는지는 답만 봐서는 알 수 없어요.

주소 문자열과 조회할 공간은 다릅니다

사용자가 말한 주소는 장소를 찾기 위한 출발점이에요. 반면 BigValue 데이터 조회에는 여러 표현이 들어와도 같은 대상을 가리킬 수 있는 안정적인 공간 기준이 필요하고요.

두 작업은 닮아 보이지만 목적이 다릅니다. 주소 문자열을 정리하는 작업은 표기의 차이를 줄여요. 조회할 공간을 확정하는 작업은 남아 있는 단서가 어떤 후보를 지지하는지, 그 근거가 다음 조회로 넘길 만큼 충분한지를 판단하고요.

정규화만으로는 부족합니다. “해솔아파트”라는 이름을 깨끗하게 다듬어도 동명 후보를 가를 수 없다면 공간은 아직 확정되지 않은 거예요. 반대로 도로명, 숫자, 랜드마크처럼 서로 다른 표현이 같은 후보를 가리킨다면 확정 근거는 강해집니다. 저희는 이 차이를 다루려고 주소 표현을 공간 키로 연결하는 과정을 네 단계로 나눴어요.

공간 키 연결을 네 단계로 나눕니다

1. 표현을 장소 토큰으로 나눕니다

세 표현에는 서로 다른 단서가 들어 있어요. “해솔아파트”에는 단지명이, “가람로 19”에는 도로명과 숫자가, “해솔공원 맞은편 아파트”에는 랜드마크와 일반 주거 표현이 담겨 있죠. 이 조각들을 한 줄의 문자열로만 다루면 어느 부분이 장소를 특정하는지 구분하기 어렵습니다.

여기서 저희가 겪은 문제가 하나 있어요. “해솔공원 맞은편 아파트”를 물었는데 전혀 다른 지역의 결과가 돌아왔습니다.

원인은 단지명을 잡는 규칙이었어요. 단지 이름은 대개 “○○아파트”처럼 고유한 앞부분과 일반 주거 표현이 붙어 있잖아요. 그래서 뒤쪽 일반 표현을 기준으로 이름의 범위를 잡고 있었는데, “해솔공원 맞은편 아파트”는 형태만 같고 의미가 반대였어요. 여기서 앞부분은 버려도 되는 수식어가 아니라 지역을 좁힐 유일한 단서였거든요. 규칙이 앞을 버리자 남은 건 “아파트”뿐이었고, 검색은 도시 전체로 퍼졌습니다.

그래서 랜드마크는 지우지 않고 독립된 장소 단서로 남기게 했어요. 이번에는 반대 방향에서 문제가 생겼습니다. 일반 표현을 함부로 지우면 안 된다는 판단을 확대 적용하자, 이름 대부분이 일반 표현인 단지에서 두세 글자만 남아 검색어로 쓰기엔 너무 짧다는 이유로 거절되기 시작했어요. 지역명을 붙여 다시 물으면 이번에는 랜드마크 좌표가 정상 결과처럼 돌아왔고요.

두 번의 실패가 가리키는 방향은 같았습니다. 문제는 무엇을 지우느냐가 아니라 어느 범위를 먼저 보호하느냐였습니다. 그래서 순서를 바꿨어요. 먼저 어떤 조각이 지역·도로명·지번인지, 어떤 조각이 건물·단지명이나 랜드마크인지, 어떤 조각이 동·호·층 같은 상세 단서인지를 구분합니다. 건물이나 단지명으로 판단한 범위는 먼저 보호하고, 그 밖의 조각만 행정구역 단서로 해석해요. “동”처럼 행정구역과 건물 동을 모두 나타낼 수 있는 표현도 이 순서 안에서 갈립니다.

이 단계의 목적은 입력을 짧게 만드는 게 아니에요. 다음 단계에서 후보를 만들고 비교할 때 쓸 근거를 잃지 않는 겁니다. 다만 하나의 토큰 규칙이 모든 주소 유형에 통한다고 볼 수는 없어요. 모호한 표현을 지나치게 확장하면 새로운 후보가 불필요하게 늘 수 있어서, 원문 단서와 허용 범위를 함께 살폈습니다.

토큰을 나눈 뒤에는 아직 정답을 고르지 않아요. 보존한 단서를 바탕으로 가능한 공간 후보를 확보하는 단계로 넘어갑니다.

같은 입력이라도 조각마다 대우가 다릅니다. 어떤 단서는 범위를 보호받고, 어떤 단서는 단독으로 해석하지 않고 보류해요.

2. 토큰에서 가능한 공간 후보를 넓게 모읍니다

“해솔아파트”를 검색해 가장 먼저 나온 결과, 그곳이 사용자가 말한 장소일까요? 보장은 없습니다. 같은 이름의 단지가 여러 지역에 있을 수 있으니까요.

더 성가신 경우도 있었어요. 단지명을 검색했더니 1순위가 그 단지의 테니스장이었습니다. 검색이 틀린 건 아니에요. 부속시설의 이름이 단지 본체보다 입력과 더 정확히 맞아떨어졌을 뿐이거든요. 이름이 가장 잘 맞는 후보와 사용자가 찾던 장소는 다를 수 있습니다. 점수만으로는 이 둘을 가를 수 없어서, 후보가 주거 본체인지 부속시설인지도 함께 보게 됐어요.

첫 결과를 그대로 정답으로 쓰면 후보를 찾는 일과 확정하는 일이 한 번에 섞입니다.

그래서 후보 생성과 공간 키 확정을 분리했어요. 단지명에서는 가능한 동명·유사 후보를 찾고, 도로명과 숫자에서는 해당 표현과 연결될 수 있는 후보를 모읍니다. 랜드마크는 주변 장소라는 별도의 관계 단서로 쓰고요.

후보를 넓게 모으는 이유는 결과를 많이 보여주려는 게 아니에요. 다음 검증 단계에서 서로 비교할 선택지를 남기려는 겁니다. 우선 후보 하나만 보관하면 다른 단서와 충돌하는지 확인하기 어렵지만, 보조 후보를 함께 두면 어떤 근거로 한 후보를 선택하거나 보류했는지 판단할 수 있어요.

물론 후보 범위를 무작정 넓히면 검증 비용과 모호성이 함께 커집니다. 그래서 입력에서 실제로 보존한 장소 단서와 연결되는 범위 안에서만 후보를 확보해요. 후보가 여러 개 남았을 때 Agent는 하나를 먼저 고르는 대신, 현재 대화에서 확인한 지역·건물 조건이나 이전 대화에서 이미 확인된 장소 단서처럼 문맥상 신뢰할 수 있는 정보를 다시 살피고, 이런 문맥으로도 근거가 충분하지 않다면 확정을 뒤로 미룹니다.

이제 단지명에서 나온 후보, 도로명·숫자에서 나온 후보, 랜드마크 관계가 가리키는 후보가 남아요. 다음 질문은 후보가 몇 개인지가 아니라, 입력 단서와 대화 문맥이 같은 공간으로 수렴하는지입니다.

3. 후보가 같은 공간을 가리키는지 검증합니다

후보 검증에서는 서로 독립적인 단서가 같은 공간을 지지하는지 살폈어요. 단지명 후보와 “가람로 19”의 후보가 같은 공간을 가리키고, “해솔공원 맞은편”이라는 랜드마크 관계도 모순되지 않는다면 확정 근거가 강해집니다.

반대로 도로명 텍스트는 같지만 숫자가 다르다면 이름의 유사성만으로 확정하지 않아요. 예를 들어 “가람로 19”를 찾을 때 인접한 “가람로 20”이 검색 결과로 나오더라도 핵심 숫자가 충돌하잖아요. 결과가 존재한다는 이유로 이 후보를 공간 키로 바꾸면, 다른 장소를 정상 결과처럼 다음 조회에 넘기게 됩니다. 잘못된 장소를 확정하는 거짓 양성(false positive)입니다.

이런 응답은 실패 목록에 남지 않아요. 상태가 성공이니까요. 앞선 랜드마크 사고는 결과가 눈에 띄게 이상해서 금방 드러났지만, 바로 옆 주소는 그럴듯해서 조용히 쌓입니다. 저희가 이 유형을 늦게 발견한 이유이기도 하고요.

여러 표현이 함께 들어온 경우에는 각 단서에서 얻은 후보가 공통 공간으로 수렴하는지도 봐요. 단지명은 후보 A를, 도로명은 후보 B를 가리킨다면 가장 높은 점수를 받은 하나를 곧바로 고르지 않습니다. 후보 사이의 충돌 자체를 확정할 수 없다는 근거로 남기고요.

여기서 중요한 건 후보 수보다 확정 근거의 강도예요. 강한 일치 근거를 가진 우선 후보 옆에 유사한 보조 후보가 있을 수 있는데, 보조 후보가 있다는 이유만으로 항상 멈출 필요는 없습니다. 반대로 후보가 하나만 남았어도 입력의 숫자나 지역 단서와 충돌한다면 확정해서는 안 됩니다.

이런 실패 유형은 실제 주소나 내부 식별자를 빼고 회귀 사례로 남겨, 설계를 바꾼 뒤 다시 확인했어요.

네 단서가 모두 게이트를 거칩니다. 확정과 보류는 다른 결과가 아니라 같은 판정의 두 출구예요.

4. 확정할 수 없으면 공간 키를 만들지 않습니다

검증 결과가 항상 하나의 공간 키로 끝나지는 않아요. 단지명·도로명·랜드마크가 같은 후보로 수렴하고 충돌하는 단서가 없다면 공간 키를 확정할 수 있습니다. 하지만 동명 후보가 남거나 표현끼리 다른 공간을 가리키고, 앞선 대화 문맥으로도 이를 가를 근거가 부족하다면 공간 키가 필요한 다음 조회를 진행하지 않고 추가 확인이 필요한 상태로 남겨요.

상세 단서에도 같은 경계를 적용했어요. 동·호·층 정보가 입력에 있어도 이를 뒷받침하는 기준 데이터가 없다면, 더 넓은 상위 장소를 같은 답인 것처럼 대신 반환하지 않습니다. 확인된 범위와 확인하지 못한 범위를 구분하고, 다음 조회를 보류하고요.

찾지 못했다는 응답이 정상 결과일 때도 있어요. 기준 데이터에 아직 들어오지 않은 장소라면, 근처의 다른 곳을 대신 내놓는 것보다 없다고 답하는 편이 맞습니다.

이 단계의 판단은 세 방향으로 나뉩니다.

• 근거 충분하면 BigValue 공간 키 확정
• 복수 후보 남으면 추가 확인 상태로 보류
• 근거 약하거나 핵심 단서 충돌하면 공간 키 없이 조회 중단

보류는 사용자에게 한 번 더 질문해야 하는 부담을 만들고 바로 결과를 제공할 수 있는 범위를 줄여요. 그래도 근거 없는 공간 키를 채워 넣으면 이후 데이터 조회와 답변이 모두 다른 장소에서 진행됩니다. 그래서 오답을 막은 비율과 바로 답한 비율을 하나의 성공률로 합치지 않고 따로 봤어요.

네 단계를 거치면 “해솔아파트”, “가람로 19”, “해솔공원 맞은편 아파트”는 문자열 세 개가 아니라 같은 공간을 지지하는 단서 묶음이 됩니다. 충분히 검증된 경우에만 하나의 BigValue 공간 키가 다음 조회의 출발점이 되고요.

여기서 끊기면 앞의 판단이 사라집니다

공간 키를 확정하는 절차가 있어도 Agent가 다음 단계에서 다시 사용자가 말한 이름으로 조회를 시작하면 앞서 만든 판단이 이어지지 않아요. 그래서 Agent가 표현을 해석하고 신뢰 수준을 확인한 뒤, 방금 확인한 장소 맥락과 공간 키를 다음 도구 호출에 이어 받아 같은 공간을 기준으로 데이터를 조회하도록 연결했습니다.

이 지점에서 MCP는 장소를 잘 찾게 만드는 알고리즘 자체가 아니에요. 표현을 해석하고, 후보를 검증하고, 공간 키를 확정하거나 보류한 뒤, 그 키로 조회하는 순서를 Agent의 실제 도구 호출에 연결하는 실행 계약이죠. 앞에서 만든 공간 판단이 다음 도구 호출에서도 이어지게 하는 경계가 여기입니다.

어디서 틀렸는지부터 구분합니다

같은 장소에 대한 답이 어긋났다고 해서 원인이 모두 주소 해석에 있는 건 아니에요. 해결 과정을 단계로 나누면 어느 경계에서 문제가 생겼는지 구분할 수 있습니다.

앞의 랜드마크 사고처럼 주소 표현에서 지역 단서를 잃어 후보가 애초에 빠졌다면 단서 해석의 문제예요. 필요한 후보는 있었지만 숫자 충돌을 놓치거나 동명 후보 중 하나를 근거 없이 골랐다면 후보 검증의 문제고요. 올바른 공간 키를 확정했는데 이후 조회 결과가 기대와 다르다면, 공간 키 이후의 데이터 조회나 답변 구성 경로를 따로 살펴야 합니다.

이 구분은 공간 키의 책임 범위도 분명하게 해요. 검증된 공간 키는 Agent가 같은 공간에서 조회를 시작하도록 돕지만, 데이터의 최신성이나 특정 질문에 대한 답변 적합성까지 보장하지는 않습니다. 주소 해석의 성공과 후속 데이터·답변의 성공은 서로 다른 검증 대상입니다.

검증 비용도 모든 입력에 똑같이 더하지는 않았어요. 빠르게 확정할 수 있는 단일 단서 경로는 그대로 두고, 여러 단서가 섞이거나 오답 위험이 큰 경로에서만 교차검증을 했습니다. 변경 뒤에는 대표 실패 유형이 다시 나타나지 않는지 회귀 검증하고, 기존 경로에 불필요한 호출 비용이 더해지지 않는지도 나눠서 살폈고요.

Agent는 같은 장소에서 조회를 시작합니다

처음의 세 표현으로 돌아가 볼게요. 사용자는 “해솔아파트”, “가람로 19”, “해솔공원 맞은편 아파트”처럼 편한 방식으로 장소를 말합니다. 시스템은 이 문장을 하나의 형식으로 억지로 맞추기보다, 단지명·도로명·숫자·랜드마크라는 장소 단서를 보존해요.

각 단서에서 후보를 모은 뒤 같은 공간으로 수렴하는지 검증합니다. 수렴하면 공간 키를 확정해 MCP가 Agent의 데이터 조회로 넘기고, 충돌하거나 상세 단서를 확인할 수 없으면 추측해 만들지 않아요.

이 흐름이 모든 장소 질의나 후속 데이터 문제를 해결하는 건 아닙니다. 다만 이 업무 범위에서는 사용자의 자연스러운 표현을 그대로 허용하면서도, Agent가 다음 조회를 어느 공간에서 시작할지 정하는 기준을 분리할 수 있었어요.

사람은 같은 장소를 여러 방식으로 말합니다. Agent의 조회까지 그 표현마다 흔들릴 필요는 없습니다. 표현은 자연어로 받되 조회는 검증된 공간 키에서 시작하는 것, 저희가 만든 경계는 여기까지입니다.