Text to SQL이 왜 잘 안될까?

LLM(Large Language Model)의 등장으로 데이터 접근 방식도 변해야 한다고 생각한다. 데이터베이스 분야외에 다른 분야는 LLM을 위한 변화가 이미 시작되었다.

프론트엔드 관점에서는 Perplexity, GPT 검색과 같은 AI 에이전트 및 스크래퍼를 지원하기 위해 명확한 제목, 구조화된 섹션, 풍부한 스니펫을 통해 "LLM 검색"이 가능하도록 설계되어가고 있다.

AI가 콘텐츠를 더 효과적으로 요약, 추출을 할 수 있게 하기 위함이다.

백엔드 관점에서는 백엔드에서 만들어지는 API 디자인은 AI 에이전트가 분석하고 사용할 수 있도록 명확한 주소와 메타데이터를 갖춘 MCP과 같은 프로토콜로 전환되고 있다.

프론트엔드, 백엔드를 지나 이제 데이터베이스의 차례이다.

레거시 데이터베이스에서 작업한 경험이 있으신 분들은 아마 알고 있을 것이다. 데이터베이스는 자가 설명적이지 않다. 데이터베이스의 스키마를 보고 무엇을 의미하는지 알기가 어렵다.

Fullname이라면 유추할 수 있지만, 축약어를 사용한다면 더더욱 판단하기가 어렵다.

예를 들어, order라는 테이블이 있다고 하면 이 테이블이 고객의 주문서를 담고 있는 것인지, 구매 주문서인지 이름만 봐서는 판단하기 어렵다. 이는 데이터베이스가 안고 있는 오래된 문제이다.

이제는 LLM이 데이터베이스에서 제공하는 맥락만으로 데이터에 대한 이해를 해야 한다. 사람도 헷갈리는데 혼란스럽지 않을까?

여기서 "Text to SQL"의 허점이 발생한다. 지금은 사용자가 자연어를 사용하여 데이터를 뽑는 시대가 열리고 있다.

"지난 분기 각 매장의 총 수익을 보여주세요." 라고 질문을 하면,

위에 맞는 적절한 SQL 쿼리를 실행하고 그 결과를 차트에 표시해야 한다. 이런 상황을 고려하지 않은 LLM 태생 이전에 디자인한 데이터베이스로 이 질문에 대한 정확한 SQL을 만들 수 있을까?

생각보다 이 문제는 어려운 문제이다.

누군가는 이렇게 얘기할 수 있다. LLM에 데이터베이스의 전체 스키마를 전달하고, SQL 쿼리를 생성하도록 요청하면 되지 않느냐고...

테이블 이름, 컬럼명 그리고 관계에 대한 정보가 있어도 LLM은 사용자의 질문에 정확하게 답변하는 SQL쿼리를 생성하지 못할 수 있다. 

대부분의 데이터베이스 스키마에서 테이블과 컬럼명은 그 자체로 설명적이지 않기 때문이다. 때로는 개발자 조차도 스키마 이해에 어려움을 겪기 때문에 AI가 이해할 수 있을 것이라고 기대할 순 없다.

위에서 언급한 대로 고객 주문과 구매 주문이 각각 어떤 테이블에 있는지 이해하지 못하면 파악할 수 없다. 이 상황은 데이터베이스가 클수록 상황은 더 나빠진다.

일반적인 코드 생성 문제와는 달리 이 문제는 단순하게 텍스트 설명에서 코드를 생성하는 것 이상이다. 모델은 데이터베이스 구조, 데이터 유형, 테이블 간의 관계 등을 알고 있어야 하기 때문이다.

비즈니스의 전문화된 용어를 데이터베이스의 구조로 번역하는 방법에 대해 모델을 훈련시켜야 할 수 도 있다. 모델이 전반적인 비즈니스를 이해하고, 데이터 구조를 이해한 상태에서 사용자의 질문에 답할 수 있어야 하는 경우가 대부분이기 때문이다.

어떤 상황에서 LLM이 힘들어하는지 살펴보자.

LLM은 필드 이름의 의미가 중요하다. 이름이 모호하면 추측하게 되고, 잘못된 이해를 할 수 있다. 예를 들어 "가치"라는 필드가 있으면, 이 필드는 "원화"라는 의미도 담고 있어야 한다. "가치_원" 으로 표현되어야 LLM이 이해할 수 있을 것이다.

일관된 데이터 형식도 중요하다.
"구매날짜 = 2025-09-18"
"주문날짜 = 2025/09/18"

위 처럼 데이터 형식이 서로 다르면, 일관된 형태로 답을 하기가 어렵다.

그리고 회사내부에서 사용하는 용어, 지표, 명명 규칙을 LLM은 알지 못한다.

1. 재구매 고객: 최소 3개월 이상 구매한 고객
2. 이탈 고객: 3개월 이상 로그인을 안한 고객

회사내에서는 위 용어에 대해 정의를 내렸지만, 데이터베이스에서는 해당 데이터가 존재하지 않는다. 여러 데이터를 기반으로 애플리케이션 계층에서 계산을 해야 하기 때문이다.

이럴 경우 LLM은 추론할 수 없다. 이런 용어의 논리를 명확하게 정리하지 않으면, LLM은 올바른 의견을 낼 수 없다.

반면, LLM의 등장 이전에 우리가 해왔던 것들을 생각해보자.

이전 글에도 작성했지만, SQL과 코드에서 필드 이름을 축약어를 선호했기에 짧은 이름을 주로 사용한다. 가독성보다 최적화를 선택했다.

여러가지 이유, 제약이 있을테고, 이는 타당한 엔지니어링 결정일 수 있지만 스키마를 의미적으로 추론하기 어렵게 만든 것은 사실이다.

그럼 우리는 앞으로 어떻게 해야 할까?

MCP 스타일 표준 관점에서 접근을 해야 할 것이다. 기계가 이해할 수 있는 친화적인 스키마 설계가 필요하다.

즉, 데이터베이스를 설계하는 방식에 변화가 필요하다. 아래처럼 우선 시작해봐야하지 않을까?

• 설명이 드러나는 명확한 이름과 일관된 형식 사용
• 의미론적 관계를 반영
• 기계가 이해할 수 있는 메타데이터 추가
• 컨텍스트가 저장된 벡터DB를 이용한 추론

끝으로, Text to SQL에서 질의에 대한 답이 이상하다면, LLM의 문제로 바라볼 것이 아니라. 스키마 설계를 의심해야 한다. 우리는 LLM을 염두해서 설계하지 않았기 때문이다.

Text to SQL에서 정확도를 높이려면 시스템이 접근할 수 있는 정보의 범위를 좁히는 것도 중요하다. 성공적인 Agent는 엄격한 범위 설정이 중요하다. 정확성이 입증된 후에만 확대하는 것이 효과적이다.

다음 글에서는 스키마 설계에 대한 부분을 다룰 생각이다.

Read More

사람들은 AI로 분류된 제품을 싫어한다.

포스팅 제목이 자극적이라고 생각할 수 있지만, 내가 한 말은 아니기에 오해 마시라.

흥미로운 연구 논문이 있다. 워싱턴 주립대와 템플 대학교의 연구원들은 제품에 AI 기능을 추가했을 때의 효과에 대한 연구를 발표했다. 

100명의 참여자로 구성된 두 개의 그룹을 만들고, 가상 광고를 이용하여 "AI" 가 붙은 제품이나 "AI 기반" 제품을 구매할 의향이 더 높은지, 아니면 "첨단 기술"이나 "신기술"이 붙은 제품을 구매할 의향이 더 높은지를 측정했다.

"AI 관련 문구를 본 그룹은 다른 그룹에 비해 광고 된 제품이나 서비스를 사용/구매하거나 적극적으로 찾고 싶은 가능성이 낮았다."

특히, 자동차나 의료 관련 서비스와 같은 고위험 제품의 경우에 더욱 높았다고 한다. 연구를 시작하기 전에 연구원들은 AI 라벨이 사람들의 제품 구매 가능성을 낮추는 것이 아니라 오히려 높일 것이라고 생각했지만, 정 반대의 결과가 나온 것이다.

연구자들이 저위험군으로 분류한 품목, TV나 일반적인 상품의 경우에는 차이가 적었다고 한다.

연구진들은 의사결정이 머리보다는 가슴으로 하는 것으로 보인다고 밝혔다. 즉, 대부분 감정에 기반을 둔 의사결정을 한다는 이야기이다. 부정적인 시각을 가진 사람들은 AI기반 제품과 서비스를 신뢰하지 않았으며, 특히 AI가 어떤 기능을 하는지 이해하지 못하거나 안전에 위험을 초래할 수 있는 제품이나 서비스는 신뢰하지 않았다.

AI 도구를 한 번 이상 사용해 본 사람들은 그 도구들이 얼마나 신뢰할 수 없는지 잘 알고 있다. 어떤 일을 할 때 인간보다 뛰어나지만, 실패할 때는 비인간적인 방식으로 실패하곤 한다. 이런 부분이 무섭게 느껴질 수 있다.

현 시점에 "AI"는 마법의 키워드가 되었기에., 거의 모든 앱/서비스에는 AI 기능이 탑재되어 있다. 때로는 정말 유용하지만, 어쩔때는 귀찮을 수도 있고, 제품의 성능을 저하시키기도 한다.

AI에 대한 부정적인 태도의 원인을 파악하기 위해 추가적인 프로젝트를 진행한다고 했지만, 개인정보에 대한 우려도 있을것이라 추측한다고 했다.

예를 들어, 스마트 냉장고의 경우는 고가이고, 소프트웨어 업데이트가 필요하고, 식습관을 추적할 경우 개인정보 보호에 문제가 발생할 수 있다. 대부분의 사람들은 냉장고에 AI가 탑재되는 의미를 이해하지 못할 수 도 있다.

기업들은 자사 제품에 AI를 적용하는데 앞으로 더 적극적으로 나설것이다. AI기반 서비스/기기는 이론적으로는 매력적이지만, AI를 이용한 구체적인 장점이 명확하고 가치가 있어야 할 것이다.

오늘은 회사 앞 편의점을 가기위해 횡단보도를 건너는데., 횡단보도 전봇대 앞에 AI 피트니스라는 광고판이 보였다. 처음에는 무슨 세미나를 하는지 알았는데., 알고 보니 피트니스 홍보였다. 이 광고판을 제작할 때, AI가 피트니스 모객을 위해서 큰 도움이 될 것이라고 생각했을까? 이미 내 주변에는 "AI"라는 용어를 많이 쓰고 있다.

Read More

프로그래머가 비즈니스 문제를 해결해야 할까?

대부분의 조직은 R&R로 나눠져있다. 그리고 업계에 만연하는 것중 프로그래머는 비즈니스 문제 해결에 관여해서는 안된다는 얘기가 있다. 비즈니스 니즈에 집중하는 것이 프로그래밍의 순수한 기술적 본질을 훼손한다는 이야기이다.

나는 이런 관점에 반대한다.

일반적으로 개발자는 크게 3개의 레벨(주니어, 미들, 시니어)로 구분한다. 각 레벨에 대한 정의를 해보자.

• 주니어: 논란의 여지가 없는 레벨이다. 이론을 배웠고, 이제 업무를 시작하려는 레벨이다.
• 미들: 기술 스택에 대해 이해하는 숙련된 레벨이다.
• 시니어: 다양한 경험을 갖추고 있고, 기술 스택에 대한 경험도 많으며, 업계 전반의 폭넓은 이해를 갖추고 있어야 한다.

원하던 원치 않든, 프로그래머는 비즈니스 문제를 해결한다. 사업은 수익을 창출해야 하고, 여기에는 급여 지급도 포함된다. 수익을 창출하려면 문제(비즈니스 과제)를 해결해야 한다. 간접적이던 직접적이던 비즈니스에 "가치"를 부여하여 문제를 해결해야 한다.

몇 가지 예를 들어보자. 새로운 웹사이트를 만들어야 한다고 가정해보자. 업무 흐름은 아래와 같을 것이다.

현업 요구사항 -> 프로젝트 관리자 -> IT 실무자로 이어지는 업무 흐름에서 두 가지 접근 방식이 존재한다.

• 사례 #1: 요구사항 대로 그냥 코딩 - 모든 사람이 책임 범위내에서 일한다. 프로젝트 관리자는 현업과 논의하고 티겟을 만들고, 시니어는 아키텍처를 설계하고, 주니어는 미들과 개발을 한다.
• 사례 #2: 업무 시작 전에 프로젝트 관리자, 시니어, 현업등이 비즈니스 문제를 심도 있게 논의하는 회의를 여러 차례 진행한다. 단순히 문제 해결 방법 뿐만 아니라, 비즈니스, 개발자, 디자이너 등 모든 사람이 참여해서 효과적으로 문제를 해결하는 방법을 논의한다. 모두에게 효과적인 방안을 찾은 후에야 개발이 시작된다.

사례#1 에서는 모두가 "그냥 코딩"만 한다. 비즈니스 문제는 비효율적으로 해결된다. 마감일이 정해져 있으면, 허술한 해결책을 찾고, 책임을 전가하고, 장황하게 수정 작업을 하고, "새로운 요구사항"을 추가하는 상황이 발생한다. 이는 사람들이 요구대로만 했기 때문이다. 모두가 자신의 범위내에서 "톱니바퀴"처럼 일했고, 비즈니스 문제 해결에는 참여하지 않았다.

사례#2에서는 항상 발생하는 대부분의 잠재적 문제가 상호작용을 통해 해결된다. 필요한 것을 오해할 수 있기 때문에 개발자가 프로젝트 구현 방식을 근본적으로 변경할 수도 있다는 점은 당연한 것이다. 물론 역량에 따라 크게 달라지겠지만, 문제는 훨씬 줄어들 것이다. 이 시나리오에서 비즈니스 문제는 효과적으로 해결된다.

사례#1과 사례#2의 주요 차이점은 무엇일까?

구현 방식이 아니라 팀워크이다. 여기서 팀이란 단순히 프로젝트내에서 무언가를 구현하는 코더 몇 명이 아니라 참여하는 구성원 전체를 의미한다. 사례#2에서는 모두가 좋은 결과를 얻기 위해 함께 노력한다는 점이 존재한다. 물론 세상은 완벽하지 않지만., 가정적으로 그렇다.

이유는 모르겠지만, 사람들은 종종 문제 해결을 영업과 연관 짓는다. 프로그래머는 "어떻게" 판매될지 생각하는 것이 아니라, "무엇"이 판매될지를 생각해야 한다. 최종 제품의 품질은 아키텍처, 속도, 로직, 디자인 등에 따라 달라진다. 여러가지 것들이 제품의 품질에 담긴다.

본 글의 서두에서 프로그래머는 원하든 원치 않든 비즈니스 문제를 해결한다고 언급했다. 다시 한번 생각해본다. 프로그래머가 비즈니스 문제를 해결해야 할까?

그래야 한다고 생각한다. 역량, 직책 그리고 경험 측면에서 해결해야 한다.

프로그래머가 영업을 해야 할까? 물론 아니다. 그러나 영업이 안고 있는 비즈니스 문제를 해결해주어야 한다.

Read More