의 글을 요약 정리한 내용임
오늘날의 ‘똑똑한 AI’에는 불편한 진실이 있다. 구문(syntax) 처리에는 강하지만, 의미(semantics) 이해는 미흡하고, 비즈니스 맥락에는 취약하다. 특히 마지막 약점이 중요하다. 기업 가치 대부분이 이런 맥락적 틈새 속에 숨어 있기 때문이다.
예를 들어, 조직마다 ‘활성 고객(active customer)’의 정의가 다를 수 있다. 화요일에만 적용되는 특정 할인 코드, 인수합병 이후 바뀐 SKU 명칭, 그리고 재무팀과 영업팀이 서로 다르게 해석하는 매출 지표 등이 대표적인 사례다.
AI 모델은 학술적 테스트에서는 뛰어난 성과를 내고, 심지어 합리적인 SQL 쿼리를 생성하기도 한다. 그러나 기업 방화벽 뒤에서 운영 환경과 실제로 맞닥뜨리는 순간, 성능은 급격히 흔들린다.
투자자이자 분석가인 톰 텅구즈는 이런 점을 잘 보여주는 스파이더 2.0(Spider 2.0) 벤치마크 결과를 공개했다. 스파이더 2.0은 모델이 자연어를 SQL로 변환하는 능력을 현실적인 기업 데이터베이스 환경에서 평가한다. 결과는 냉정하다. 모델의 정확 일치율은 약 59%에 머물고, 변환·코드 생성 복잡성이 추가되면 약 40%까지 떨어진다.
여기서 중요한 점은, 이 데이터 세트가 단순한 실험용 장난감이 아니라 실제 기업이 운영하는 복잡하고 방대한 스키마를 반영한다는 사실이다. 다시 말해, 현실의 비즈니스 맥락에 가까워질수록 AI는 더 큰 어려움에 직면한다.
기업용 소프트웨어를 개발하는 사람이라면 이는 놀라운 일이 아니다. 개발자가 AI와 관련해 겪는 가장 큰 문제는 단순히 코드를 뱉어낼 수 있는지가 아니다. 데이터와 규칙을 기반으로 이 시스템을 일관되게 신뢰할 수 있는지다. 이는 ‘거의 맞는 코드’에 대한 세금과 직결된다. 즉, 모델이 생성한 결과물이 조직의 구체적인 맥락을 정확히 이해하지 못하기 때문에 이를 디버깅하고 사실 확인하는 데 시간을 허비하게 되는 것이다.
대형 모델은 기본적으로 공개 텍스트를 학습한 패턴 엔진이다. 그러나 기업 고유의 비즈니스 로직, 예를 들어 이탈률을 계산하는 방식, 영업 구역을 운영하는 방법, 거의 동일한 두 제품 라인의 미묘한 차이 같은 것들은 공개 웹에 존재하지 않는다. 이 정보는 지라 티켓, 파워포인트 문서, 제도적 지식, 그리고 과거 의사결정의 산물인 데이터베이스 스키마에 숨어 있다. 이는 곧 엔터프라이즈 AI의 기억을 구성하는 핵심 요소이기도 하다. 데이터 모델도 예외가 아니다. 1,000개가 넘는 컬럼을 가진 테이블, 이름이 바뀐 필드, 불안정하게 설계된 차원, 그리고 조직 개편 때마다 바뀌는 용어가 발목을 잡는다.
스파이더 2.0 벤치마크 결과가 이런 현실을 보여준다. 실제 업무 흐름에 가까운 과제를 다룰수록 점수가 떨어지는 이유도 여기에 있다. 다단계 쿼리, 익숙하지 않은 스키마 간의 조인, 방언(dialect) 차이, DBT 내 변환 작업 같은 요소 때문이다. 한편 기업은 점점 에이전틱 AI로 나아가고 있다. 이들 모델은 웹을 탐색하거나, 코드를 실행하거나, 데이터베이스를 직접 조회할 수 있다. 그러나 모델의 이해가 조금이라도 빗나가면 에이전틱 기능의 위험성이 커진다.
비즈니스 맥락은 단순한 데이터가 아니다. 정책과 프로세스, 그리고 기업의 역사가 결합된 것이다. AI는 문제의 형태를 파악할 수는 있지만, 실제 기업이 살아온 현실까지 이해하지는 못한다.
희소식은 이 문제를 해결하기 위해 철학적 돌파구가 필요한 것은 아니라는 점이다. 필요한 것은 모델의 메모리, 그라운딩, 거버넌스, 피드백을 더 정교하게 설계하는 엔지니어링 측면의 접근이다. 필자는 AI에 더 많은 파라미터를 추가하는 것보다, 더 많은 메모리를 확보하는 것이 중요하다고 주장해 왔다. 즉, 과거에 어떤 일이 있었는지를 구조적으로 기록하고, 해당 도메인의 데이터와 정의를 정확히 불러올 수 있는 체계를 마련해야 한다. 이를 제대로 구현하면 신뢰 격차가 줄어들 수 있다.
문제를 완전히 해결할 수 있을까? 특정 영역에서는 가능하다. 기업의 재무 지표, 고객 테이블, DBT 모델, 보안 정책에 대해서는 신뢰할 수 있는 AI 어시스턴트를 만들 수 있다. 그러나 비즈니스 맥락은 끊임없이 변하는 목표물이며, 인간은 계속해서 규칙을 바꾼다. 따라서 기업은 언제나 인간(물론 개발자도 포함된다)을 루프 안에 두어 의도를 명확히 하고 엣지 케이스를 판별하며, 비즈니스 변화에 맞춰 시스템을 발전시켜야 한다. 이 작업의 목표는 인간을 배제하는 것이 아니다. 인간을 컨텍스트 엔지니어(context engineer)로 전환해 AI 시스템이 비즈니스가 실제로 어떻게 작동하는지 학습하도록 하는 것이다.
기업과 관련한 질문에 신뢰할 수 있는 답변을 얻고 싶다면, 모델이 기업의 실제 데이터와 구조를 볼 수 있어야 한다. 이는 검색 증강 생성(Retrieval-Augmented Generation, RAG)으로 시작된다. 즉, 모델이 답변하기 전에 적절한 데이터와 메타데이터 조각(DDL, 스키마 다이어그램, DBT 모델, 행 샘플)을 제공해야 한다.
특히 텍스트-투-SQL(Text-to-SQL)의 경우에는 테이블·컬럼 설명, 데이터 계보 주석, 이미 알려진 조인 키(join key)를 포함해야 한다. 또한 검색은 단순히 PDF 벡터 집합에 의존해서는 안 된다. 카탈로그, 메트릭 저장소, 데이터 계보 그래프와 같은 관리된 소스를 반드시 포함해야 한다. 스파이더 2.0 결과를 보면 모델은 익숙하지 않은 스키마를 마주할 때 정답을 찾지 못하고 추측한다는 사실을 알 수 있다. 따라서 모델이 마주하는 ‘낯섦’을 줄여야 한다.
대부분 AI 애플리케이션은 기억상실증 환자와 같다. 매 요청마다 처음부터 다시 시작하며, 이전에 무슨 일이 있었는지 알지 못한다. 따라서 작업 메모리, 장기 메모리, 에피소드 메모리(episodic memory)로 구성된 계층적 메모리를 추가해야 한다. 이 메모리의 핵심은 데이터베이스다. 특히 임베딩, 메타데이터, 이벤트 로그를 저장할 수 있는 데이터베이스는 AI의 ‘마음’을 구성하는 핵심 요소로 자리 잡고 있다. 메모리는 모델을 단순한 패턴 매칭 수준에서, 실제로 맥락을 담아내는 시스템으로 끌어올린다.
텍스트-투-SQL 모델에서는 추상 구문 트리(Abstract Syntax Tree, AST)를 생성하거나 실행 계층에서 검증·확장할 수 있는 제한된 SQL 방언을 사용하는 방식이 효과적이다. 쿼리는 시맨틱 레이어에서 이미 정의된 차원과 측정값에 고정해야 한다. 자연어로 처리해 모델이 테이블 이름을 추측하도록 하는 것보다 함수·도구 호출을 사용해 get_metric('active_users', date_range='Q2')와 같은 방식으로 요청하게 만들어야 한다. 모델을 신뢰할 수 있는 구성 요소를 활용하는 계획자처럼 다룰수록 잘못된 추론(환각)이 줄어든다.
모호성이 가장 큰 부분에 집중할 수 있도록 승인 프로세스를 마련해야 한다. 예를 들어, 위험한 조인을 강조 표시하고, 신뢰할 수 있는 쿼리와 비교해 행 단위 차이를 미리 보여주며 “status_code in (3,5)는 활성 고객에서 제외해야 한다”와 같은 구조화된 피드백을 수집해 이를 메모리와 검색 프로세스에 반영해야 한다. 사람이 업무를 수행하는 과정에서 자연스럽게 시스템을 훈련시키게 되고, 그 결과 시스템은 더 나은 맥락 학습자로 발전한다.
벤치마크는 물론 유용하지만, KPI는 “재무팀이 분기를 정확히 마감하도록 도왔다”여야 한다. “스파이더 2.0에서 70%를 달성했다”가 되어서는 안 된다. 따라서 과제별 맞춤 평가가 필요하다. 시스템이 3가지 표준 매출 쿼리를 생성할 수 있는가? 접근 제어를 100% 준수하는가? 이런 평가를 매일 실행해야 한다.
또한 스파이더 2.0은 워크플로우가 현실적일수록 실패할 가능성이 더 크다는 점을 보여준다. 다단계 쿼리와 GUI 전반에 걸친 실제적 과제를 포함한 확장판인 스파이더2-V(Spider2-V)가 등장한 이유도 여기에 있다. 평가 역시 현실성을 충실히 반영해야 한다.
아무리 AI가 정교해진다고 해도 여전히 사람이 개입해야 제대로 작동한다는 점은 분명하다. 이는 결함이 아니라 특징이다.
비즈니스 맥락 문제는 일정 범위 안에서는 엔지니어링으로 해결할 수 있다. 올바른 그라운딩, 메모리, 제약, 평가, 보안을 적용하면 기업의 질문에 대부분 신뢰할 만한 답변을 내놓는 시스템을 구축할 수 있다. 그 과정에서 ‘거의 맞는 코드에 대한 세금’은 크게 줄어들 것이다.
그러나 맥락은 결국 사회적이다. 분기별 비즈니스 리뷰와 복도에서 오가는 대화 속에서 새롭게 정의된다. 신제품이 출시되고, 법적 정책이 바뀌고, 누군가는 정의를 수정하고, 인수합병이 일어나면 모든 것이 다시 재편된다. 이런 지속적인 재협상이 보장하는 사실은 단 하나다. 인간의 판단이 언제나 루프 안에 있어야 한다는 것이다.
이에 따라 개발자의 역할도 달라진다. 단순히 코드를 생성하는 사람이 아니라, 컨텍스트 엔지니어로서 시맨틱 레이어를 관리하고, 정책을 코드로 작성하며, 검색과 메모리를 설계하고, AI가 현실과 정렬되도록 유지하는 피드백 루프의 관리자가 되는 것이다. 이것이 바로 AI가 고도화되더라도 개발자가 여전히 필요한 이유다. 자동화가 확대될수록 기계와 비즈니스를 동시에 이해하는 사람의 가치는 더 커진다.
AI를 유용하게 활용하고 싶다면 기억(remember)하고 검색(retrieve)하며 존중(respect)하는 시스템을 목표로 삼아야 한다.
기억 : 과거에 무엇이 일어났고 어떤 결정이 내려졌는지를 저장하는 계층적 메모리
검색 : 필요한 순간에 올바른 내부 정보를 불러오는 관리되는 그라운딩
존중 : 기업의 정책, 사람, 프로세스를 따르는 과제와 함께 이동하는 권한 관리
이렇게 하면 AI는 단순히 똑똑한 자동완성처럼 보이지 않고, 실제 상황을 이해하는 동료에 더 가까워질 것이다. 이는 모델이 마법처럼 상식을 갖게 되었기 때문이 아니다. 그 상식을 공급하도록 주변 시스템을 설계했기 때문이다.
스파이더 2.0의 냉정한 점수는 AI를 비난하기 위한 근거가 아니라 어디에 투자해야 할지를 알려주는 청사진이다. 모델이 비즈니스 맥락에서 성과를 내지 못한하는가? 해법은 다른 모델이 아니라 다른 아키텍처에 있다. 즉, 인간 지능과 인공지능의 장점을 결합한 구조가 필요하다. 경험에 비춰보면 이런 파트너십은 피할 수 없는 미래다.
