🤔 AI 시스템, 왜 엉뚱한 답을 내놓을까? "질문이 곧 설계도"인 이유

 

"분명히 물어봤는데, 왜 이런 답이 나온 거지?"

AI 챗봇을 쓰다 보면 한 번쯤은 이런 경험을 하게 되더라구요. 분명 뭔가를 물어봤는데, 답은 관련이 있어 보이긴 하는데 내가 진짜로 알고 싶었던 건 아닌 그 묘한 어긋남.

대부분의 사람들은 이걸 "AI 성능 문제"라고 생각해요. 모델이 부족한 거겠지, 데이터가 부족한 거겠지 하고요. 근데 실제로 파고들면 전혀 다른 원인이 나와요.

문제의 핵심은 시스템을 만들 때 "이 시스템이 어떤 질문에 답해야 하는가"를 처음부터 정의하지 않았다는 데 있어요. 들으면 당연한 것 같은데, 현실에서는 놀라울 정도로 자주 무시되는 원칙이에요.

오늘은 정보 아키텍트 제시카 탈리스만이 제안한 개념을 바탕으로, 왜 "질문이 설계도"인지, 그리고 이게 우리가 요즘 가장 많이 쓰는 RAG 시스템이나 AI 챗봇에 어떤 의미인지를 풀어볼게요.

기능이 있는 시스템 vs 질문에 답하는 시스템, 이 둘은 다르다

소프트웨어를 개발할 때 일반적인 요구사항은 이런 식으로 써요. "이 기능이 있어야 한다", "이 버튼을 누르면 이게 되어야 한다". 그리고 검증도 "이 기능이 존재하는가"로 끝나요.

거래 처리 시스템 같은 건 이게 맞아요. 결제가 되거나 안 되거나, 딱 두 가지 결과니까요.

근데 AI 응답 시스템이나 검색 시스템은 완전히 달라요. 결과가 관련이 있는지 없는지, 완전한지 부분적인지, 정확한지 아니면 그냥 그럴듯하게 만들어낸 건지가 훨씬 더 중요하거든요. 이걸 능력 기반 요구사항으로는 절대 잡을 수 없어요. 기능이 "있냐 없냐"의 문제가 아니니까요.

정보 검색 시스템을 일반 소프트웨어처럼 설계하면, 처음부터 잘못된 틀로 만들기 시작하는 거예요. 이 원칙은 RAG 파이프라인, 지식 그래프, AI 에이전트 워크플로우 모두에 똑같이 적용돼요.

사서들은 100년 전부터 알고 있었다

흥미롭게도 이 문제를 가장 먼저 체계적으로 연구한 건 IT 업계가 아니에요. 도서관 정보학이에요.

사서들은 오래전부터 이용자가 처음에 하는 질문과 실제로 알고 싶은 질문이 다르다는 걸 알고 있었어요. 그래서 레퍼런스 인터뷰라는 실천이 생겼어요. 이용자가 던진 표면적 질문을 그대로 받아들이지 않고, 진짜 정보 필요가 무엇인지를 함께 찾아가는 과정이에요.

연구 결과가 충격적이에요. 전체 레퍼런스 거래의 절반 가까이가 아무런 인터뷰 없이 처음 질문 그대로 검색을 시작하는 것으로 나타났고, 그 경우 실패율이 훨씬 높았어요. 워크숍 별명이 "왜 처음부터 그렇게 말하지 않으셨나요?"였던 게 괜히 나온 게 아니에요.

1985년에 나온 연구도 있는데요, 잘 작동한다고 여겨지던 대형 전문 검색 시스템을 분석했더니 특정 검색어에 대해 관련 문서의 20% 미만만 반환하고 있었어요. 문제는 알고리즘이 아니라, 사람이 정보를 표현하는 방식과 문서가 색인되는 방식 사이의 간극이었어요. 더 좋은 알고리즘을 얹어도 그 간극 위에서는 해결이 안 되는 거죠.

현재 기업에서 도입되는 RAG 시스템도 같은 문제를 안고 있어요. 2024년 해외 연구에서 RAG 실패 원인 1순위로 지식 베이스에 필요한 콘텐츠가 없는 것이 지목됐는데, 이것도 결국 어떤 질문에 답해야 하는지를 먼저 정의하지 않아서 발생하는 문제예요.

역량 질문(Competency Questions)이라는 방법론

온톨로지 공학 분야에서는 1995년부터 이 문제에 대한 공식적인 답을 내놓고 있어요. 역량 질문(Competency Questions, CQ)이라고 해요.

간단히 말하면, 시스템이 반드시 답할 수 있어야 하는 자연어 질문 목록을 설계 시작 전에 먼저 써두는 거예요. 스키마도 짜기 전에, 코드 한 줄도 쓰기 전에요.

예를 들어 이런 질문이 하나 있다고 해봐요.

"배포 파이프라인에서 48시간 이상 사람의 승인을 기다리고 있는 단계는 어디이며, 그 단계를 촉발한 업스트림 단계의 담당 팀은 어디인가?"

이 질문 하나만 있어도 시스템 스키마에 뭐가 필요한지가 바로 보여요. 파이프라인 단계와 승인 상태, 타임스탬프, 촉발 관계, 담당 팀 정보가 모두 연결돼야 하고, 한 번의 쿼리로 탐색 가능해야 해요.

반면 그냥 "배포 파이프라인 데이터"라는 주제 설명만 있으면, 이 연결이 필요하다는 걸 아무도 알 수 없어요. 설계하는 사람마다 다르게 만들게 돼요.

역량 질문이 특히 강력한 이유가 또 있어요. 바로 이게 검수 테스트가 된다는 거예요. 시스템이 역량 질문 전체에 정확히 답할 수 있으면 해당 범위에서는 완성된 시스템이에요. 스키마가 바뀌었을 때 어떤 역량 질문의 답이 달라지면, 무엇이 깨진지 바로 알 수 있어요. 설계 방법론과 인수 테스트가 같은 산출물이 되는 거예요.

RAG에 적용하면 어떻게 달라질까

요즘 기업 AI 도입의 핵심 프레임워크로 자리잡은 RAG에 역량 질문을 적용하면 뭐가 달라질까요.

RAG는 수집 파이프라인, 색인 전략, 검색 레이어, 추론 설정, 스키마가 전부 이어져 있어요. 그런데 이 각각의 설계 결정이 명시적이지 않은 암묵적 가정 위에서 이루어지면, 가정들이 서로 일치하지 않아요.

역량 질문이 있으면 달라져요. 검색 레이어가 불완전한 맥락을 반환하면 답변이 부분적이 돼요. 모델이 검색된 맥락에 없는 관계를 만들어내면 답변이 특정한 방식으로 잘못 돼요. 역량 질문이 없으면 이 두 가지 실패가 탐지 자체가 안 돼요. 부분적인 답변은 그럴듯해 보이고, 만들어진 관계도 맞아 보이거든요.

저장 비용도 명확해지는 효과가 있어요. 역량 질문이 "독일에서 이 제품을 출시하기 전에 필요한 규제 승인은 무엇인가?"라면, 시스템에는 규제 프레임워크, 제품 분류, 관할권 매핑이 있어야 해요. 과거 가격 데이터나 공급업체 연락처는 불필요해요. 이해관계자가 나중에 "왜 가격 질문에 답 못 해?"라고 물으면, 처음부터 역량 질문에 없었기 때문이라고 명확하게 답할 수 있어요.

사람들이 가장 많이 놓치는 것: 초기 질문과 진짜 질문은 다르다

AI 에이전트 시스템에서도 같은 원리가 적용돼요.

사용자가 AI 에이전트에게 보내는 첫 번째 쿼리는 대부분 진짜 정보 필요의 압축된 버전이에요. 자신이 뭘 불확실해하는지, 시스템에 어떤 데이터가 있는지를 완전히 모르는 상태에서 던지는 질문이거든요.

초기 쿼리를 그대로 받아서 표면적인 문구에 맞춰 검색하는 시스템은 사용자가 말한 것을 처리하는 거예요. 진짜로 알고 싶었던 것을 처리하는 게 아니에요.

반면 역량 질문 중심으로 설계된 시스템은 사용자가 발견하고 싶었던 것을 검색해요. 이 두 결과 사이의 차이가 바로 도서관 사서의 레퍼런스 인터뷰를 소프트웨어로 재현한 거예요.

어렵지 않아요, 대화 하나면 시작할 수 있어요

이 방법론이 거창하게 들릴 수 있는데, 시작 자체는 의외로 단순해요.

최근에는 LLM을 활용해 기존 지식 구조에서 역량 질문을 자동 생성하거나 역공학하는 연구들도 나오고 있어요. 질문 세트 없이 만들어진 시스템에도 소급 적용하는 방법이 생기고 있는 거예요.

실질적인 비용은 하나의 대화에 있어요. 도메인 전문가, 데이터 엔지니어, 기획자, 최종 사용자가 모여서 "이 시스템이 어떤 질문에 답해야 하는가"를 첫 번째 스키마 요소를 선언하기 전에 써 내려가는 것.

그 대화는 언제나 가능했어요. 우리가 질문을 먼저 정의하는 방식으로 시스템을 만들지 않았을 뿐이에요.

앞으로 AI 시스템 설계는 어떻게 바뀔까

2025년 이후 AI 내재화가 본격화되면서, 기업들은 기술 스택보다 설계 원칙의 중요성을 점점 더 실감하고 있어요. RAG를 도입한다, 에이전트를 붙인다는 이야기보다 이걸로 어떤 질문을 해결할 것인가를 먼저 정의하는 조직이 훨씬 좋은 결과를 내고 있어요.

"질문을 먼저 정의하라"는 원칙은 기술이 아니에요. 사고방식의 전환이에요. AI 시스템이 엉뚱한 답을 내놓는 이유의 대부분은 기술적 한계가 아니라, 설계 단계에서 "어떤 질문에 답해야 하는가"를 정의하지 않은 데 있어요.

좋은 AI 시스템은 좋은 질문에서 시작해요.

마무리

AI 챗봇이나 RAG 시스템이 원하는 답을 못 내놓는다면, 모델 탓을 하기 전에 한 가지를 먼저 확인해보세요. 이 시스템이 어떤 질문에 답해야 하는지를 설계 단계에서 정의했는가. 역량 질문(Competency Questions) 방법론은 이 물음에 대한 가장 체계적인 답이에요. 설계 방법론과 인수 테스트가 같은 산출물이 되고, 팀 전체가 같은 목표를 보게 돼요. 지금 만들거나 도입하려는 AI 시스템이 있다면, 오늘 딱 한 가지만 해보세요. "이 시스템이 반드시 답해야 하는 질문 10개를 써보는 것." 그게 가장 강력한 설계 첫걸음이에요.