UrbanDS가 말하는 데이터 발견 설계

UrbanDS가 주는 실무적 결론은 “LLM 에이전트가 분석 코드를 더 잘 쓰게 하는 것”보다 “어떤 데이터를 찾아 써야 하는지”를 시스템 설계의 핵심 문제로 다뤄야 한다는 데 있다. 도시, 공공, 금융, 의료처럼 데이터가 여러 저장소에 흩어져 있고 형식도 다른 조직에서는 단일 에이전트에 파일 몇 개를 주고 분석을 맡기는 방식이 병목이 될 수 있다. UrbanDS는 이 병목을 그래프와 역할 분리로 다루는 연구다.

문제는 모델 능력이 아니라 데이터 접근 방식이다

기존 LLM 데이터 과학 에이전트의 흔한 전제는 “분석할 데이터셋이 이미 주어져 있다”는 것이다. 이 전제에서는 에이전트가 코드를 생성하고, 오류를 고치고, 차트를 만들고, 모델을 학습하는 능력이 핵심이 된다. 하지만 실제 도시 과제는 다르다. 관련 데이터가 하나의 테이블에 들어 있지 않고, 여러 기관·형식·공간 단위·시간 단위에 걸쳐 존재한다.

UrbanDS 논문 초록이 지적하는 한계도 여기에 있다. 기존 방법은 제한된 제공 데이터셋에 의존하는 경향이 있다. 또 대규모·이기종 데이터 저장소에서 관련 정보를 발견하고 활용해야 하는 데이터 집약적 상황에서 어려움을 겪는다고 설명한다. 도시 과제는 그런 상황의 대표 사례로 제시된다.

이 차이는 제품 설계에 직접적인 의미가 있다. 데이터가 이미 정리된 내부 분석 환경에서는 코드 실행형 에이전트가 효율을 낼 수 있다. 반대로 데이터 카탈로그가 크고, 데이터셋 간 관계가 불명확하며, 과제마다 필요한 출처가 달라지는 환경에서는 “분석 에이전트”보다 “데이터 발견·선택·관계 파악 계층”이 먼저 필요할 수 있다.

UrbanDS의 핵심 장치: 데이터셋 그래프

UrbanDS의 그래프 가이드는 데이터셋별 재사용 가능한 스킬과 데이터셋 간 관계를 통합 데이터셋 그래프로 조직한다. 여기서 중요한 점은 그래프가 단순 색인이나 검색 목록이 아니라는 것이다. 논문 설명에 따르면, 그래프는 에이전트가 과제 관련 데이터를 찾고 계획을 세우는 구조적 힌트로 쓰인다.

실행 시 Planner Agent는 이 그래프에서 관련 데이터셋을 검색·선택하고 실행 계획을 만든다. Relation Agent는 데이터셋 간 관계를 식별해 그래프에 통합한다. 즉 UrbanDS는 “질문 → LLM이 알아서 데이터 선택 → 분석”이라는 일괄 호출 방식이 아니다. 데이터 저장소를 탐색 가능한 지식 구조로 바꾸고, 그 위에서 계획을 세우는 방식에 가깝다.

이 설계의 장점은 재사용성이다. 어떤 데이터셋을 어떻게 다룰 수 있는지, 어떤 데이터셋들이 관계를 갖는지 한 번 구조화하면 다음 과제에서 다시 쓸 수 있다. 대규모 저장소에서는 이 차이가 중요하다. 매번 프롬프트에 데이터 설명을 길게 넣거나, 담당자가 수동으로 관련 테이블을 골라주는 방식은 과제 수가 늘수록 비용이 커진다.

반대로 한계도 있다. 제공된 근거만으로는 검색된 데이터셋을 실제로 어떻게 물리적으로 조인·병합·변환하는지 구체적 연산 방식을 확인하기 어렵다. 따라서 UrbanDS를 읽고 바로 “이제 이기종 데이터를 자동 병합할 수 있다”고 판단해서는 안 된다. 그래프가 데이터 발견과 계획에는 도움을 줄 수 있지만, 실제 결합의 정확성·키 매칭·단위 변환·품질 검증은 별도 검증 대상이다.

성능 숫자는 신호지만, 구매 결정 근거는 아니다

이 숫자는 데이터 집약적 과제에서 범용 에이전트만으로 충분하지 않을 수 있다는 해석을 가능하게 한다. 데이터셋 그래프와 역할 분리된 에이전트 구조가 과제 수행 정확도를 높일 가능성도 있다.

하지만 숫자의 해석은 보수적이어야 한다. 이 결과는 arXiv 사전공개본의 저자 보고다. 독립 재현과 통계적 유의성 검정 결과는 확인되지 않았다. 따라서 현재 근거가 지지하는 결론은 “UrbanDS가 항상 더 좋다”가 아니다. “대규모·이기종 데이터 저장소에서는 그래프 기반 데이터 발견 계층을 붙인 에이전트가 비교 우위를 가질 수 있다”에 가깝다.

의사결정 규칙: 데이터셋 수보다 ‘관계 불확실성’을 보라

UrbanDS를 실무에 적용할지 판단할 때 데이터셋의 절대 개수만 보면 부족하다. 핵심 기준은 과제 수행에 필요한 데이터 관계가 사전에 안정적으로 정의돼 있는가다.

이미 분석용 마트가 잘 정리돼 있고, 과제마다 사용할 테이블이 거의 정해져 있으며, 조인 규칙도 명확하다면 UrbanDS식 그래프 멀티에이전트 구조는 과할 수 있다. 이 경우에는 기존 데이터 카탈로그, 파이프라인, 코드 실행 에이전트의 품질을 높이는 편이 더 직접적이다.

반대로 다음 조건이 겹치면 UrbanDS식 접근을 검토할 만하다. 과제마다 필요한 데이터셋이 달라진다. 데이터 설명과 사용법이 사람의 암묵지로 남아 있다. 데이터셋 간 관계가 문서화돼 있지 않거나 자주 바뀐다. 분석 실패의 주된 원인이 모델링보다 잘못된 데이터 선택이다. 이런 환경에서는 LLM 에이전트의 코딩 능력보다 데이터 발견·선택·관계 추론을 관리하는 계층이 병목을 줄일 수 있다.

금융, 의료, 공공 데이터로의 확장은 원리상 가능하다. UrbanDS의 핵심이 도시라는 도메인 자체가 아니라 대규모·이기종 저장소에서 데이터셋 프로파일과 관계 그래프를 만들고, 계획·실행 에이전트가 이를 활용하는 구조이기 때문이다. 의료 영역에서도 여러 데이터 소스와 멀티에이전트 접근을 결합한 사례가 보고돼 있다. 그러나 UrbanDS가 금융·의료·공공 데이터에서 직접 성능을 검증했다는 근거는 확인되지 않았다. 도메인을 옮길 때는 스키마, 접근통제, 규제, 평가 체계를 새로 설계해야 한다.

지금 만들 수 있는 최소 실험

UrbanDS 전체를 복제하려 하기보다, 조직 내부에서 먼저 검증할 질문은 하나다. “그래프 기반 데이터 발견이 사람이 고른 데이터셋 또는 단순 검색보다 과제 정확도를 높이는가.”

이를 보려면 대표 과제 몇 개를 고르고, 관련 데이터셋 후보가 많은 저장소를 대상으로 세 방식을 비교하면 된다. 첫째, 사람이 관련 데이터를 지정한다. 둘째, 텍스트 검색이나 기존 카탈로그 검색만 쓴다. 셋째, 데이터셋 설명과 관계를 그래프로 구성해 에이전트가 선택하게 한다. 평가 기준은 최종 답의 정확도만이 아니다. 선택된 데이터셋의 적절성, 불필요한 데이터 사용, 잘못된 관계 추정, 재실행 가능성까지 포함해야 한다.

이 실험에서 그래프 방식이 이기지 못한다면 멀티에이전트 구조를 키울 이유가 약하다. 반대로 데이터 선택 오류가 줄고 재사용 가능한 관계 지식이 쌓인다면, 그때 Planner Agent나 Relation Agent 같은 역할 분리를 확장할 근거가 생긴다.

Aionda