article · 2026-08-13
같은 문장인데, 왜 다른 AI가 필요할까
Semantic Atlas가 모델 비교에서 사용자 목적과 조직구조까지 가게 된 이유
“GPU 가격이 올랐다.”
이 문장의 토픽은 무엇일까.
단어만 보면 GPU라는 객체와 가격이 올랐다는 상태 변화가 보인다. 하지만 고객 상담을 분석하는 사람은 가격 불만을 찾을 수 있다. 시장을 조사하는 사람은 수요 증가나 공급 제약의 신호를 찾을 수 있다. 조직의 인프라를 책임지는 사람은 예산과 구매 시점을 다시 판단해야 할 문제로 받아들일 수 있다.
문장은 하나인데 필요한 해석은 셋이다. 차이를 만드는 것은 모델보다 그 문장을 보는 사람이 무엇을 알고 싶어 하는지, 그 정보로 어떤 결정을 내리려는지에 있다.
Semantic Atlas를 만들며 가장 늦게 깨달았지만, 시스템을 설계할 때는 가장 먼저 물어야 하는 질문이었다.
사용자는 이 시스템을 왜 사용하는가?
Semantic Atlas는 무엇이었나
Semantic Atlas는 AI Model Benchmark Platform으로 시작했다. 흩어진 AI 모델 정보를 모아 순위를 매기는 리더보드가 아니라, 목적에 따라 모델을 비교할 수 있도록 지식의 구조를 만드는 Universal Benchmark를 구상했다.
논문, Git 저장소의 문서, 기술 보고서처럼 형식이 다른 출처에서 정보를 가져온다. 그 안의 내용을 entity–relation–entity 형태의 triple과 근거가 있는 claim으로 구조화한다. 모델이 어떤 task를 수행하는지, 어떤 데이터셋에서 어떤 metric을 기록했는지, 입력과 출력은 무엇인지 연결한다. 그런 다음 사용자의 purpose를 여러 task로 나누고 각 task에 적합한 모델이나 시스템 후보를 찾는다.
Semantic Atlas는 이 흐름을 연결하는 의미 지도였다. 모델 이름과 점수만 저장하는 것이 아니라, 어떤 목적에서 어떤 비교가 유효한지를 표현하려 했다. 나는 evidence를 entity, relation, claim으로 구조화하고 ontology graph와 semantic overlay를 만드는 upstream structuring system으로 설계했다.
문제는 이 구조를 설계할수록 모델보다 먼저 정해야 할 것이 계속 나타났다는 점이다.
목적이 정해져야 데이터의 의미가 정해진다
‘토픽 분석’은 하나의 기능처럼 들리지만 목적에 따라 전혀 다른 분석이 된다.
VOC 분석에서는 고객이 직접 말하지 않은 의도와 불만이 중요하다. “가격이 올랐다”는 발화가 단순한 정보 전달인지, 구매 포기인지, 경쟁사 이탈의 전조인지 구분해야 한다.
논문 분석에서는 주요 객체와 그 사이의 인과·비교 관계가 중요하다. 두 논문이 비슷한 단어를 썼는지가 아니라 비슷한 논리 구조를 가졌는지가 핵심일 수 있다.
둘 다 ‘토픽 분석’이라고 부를 수 있지만 정답의 단위부터 다르다. 하나는 잠재 의도와 행동 가능성을 찾고, 다른 하나는 객체와 주장 사이의 논리적 유사성을 찾는다. 이 차이를 정하지 않고 데이터를 모으면 데이터셋은 커져도 기준은 선명해지지 않는다.
데이터가 커질수록 분류 기준이 중요해진다
내가 실제로 겪은 문제는 데이터 규모가 커질수록 데이터 확보보다 분류 기준의 엄밀성이 더 중요해진다는 점이었다.
몇십 개의 사례는 사람이 맥락을 보충할 수 있다. 수만 건으로 커지면 ‘불만’과 ‘정보 문의’의 경계, ‘시장 신호’와 ‘단순 사실’의 경계, 하나의 발화가 여러 범주에 걸릴 때의 처리 규칙을 먼저 고정해야 한다. 그렇지 않으면 라벨의 수는 늘어나지만 같은 라벨이 같은 의미를 보장하지 못한다.
Teacher Model을 이용한 데이터 증류는 정해진 기준으로 데이터를 빠르게 확장하는 데 유용하다. 그러나 기준 자체가 비어 있거나 흔들리면 모델이 만드는 라벨도 그 모호함을 반복한다. 내가 다뤘던 생성·분류 모델은 주어진 맥락과 학습 분포 안에서 가능성이 높은 출력을 고르는 방식이었다. 아직 조직이 정의하지 않은 정답의 경계를 모델이 먼저 확정해 줄 것이라고 기대하기는 어려웠다.
데이터셋은 모델을 적용하기 전에 이미 존재하는 원재료라기보다, 목적과 분류 기준을 통해 만들어지는 설계 결과물에 가깝다.
사용 목적 → 해석 단위 → 분류 기준 → 데이터셋 → 모델 적용
목적을 task로 옮기면 조합이 폭발한다
사용 목적이 정해져도 바로 모델을 고를 수 있는 것은 아니다. “반복되는 고객 문제를 빨리 찾고 싶다”는 목적에는 텍스트 정리, 의도 추출, 의미 기반 군집화, 시간 변화 탐지, 문제 유형 분류, 담당 부서 라우팅 같은 여러 작업이 들어간다.
각 단계에는 규칙 기반 처리, 전통적인 분류기, 임베딩, 검색, LLM, 에이전트, 사람 검수 등 여러 선택지가 있다. 앞 단계의 출력은 다음 단계의 입력이 되고, 어느 단계에서 사람을 개입시킬지에 따라 비용과 정확도도 달라진다.
실제 목적을 task로 분해하면 가능한 조합은 사실상 무한대에 가까워진다. Universal Benchmark가 모든 조합을 미리 평가해 정답 하나를 주는 체계가 될 수 없었던 이유다.
필요한 것은 완전한 순위표가 아니라 탐색 공간을 줄이는 의미 구조였다. 사용자가 무엇을 알고 싶은지, 그 답을 만들기 위해 어떤 판단이 필요한지, 각 판단의 실패 비용은 얼마인지에 따라 후보 task와 metric을 먼저 좁혀야 했다.
모델의 점수에서 시스템의 실효성으로
이 지점에서 Semantic Atlas의 관심은 AI Model에서 AI System으로 옮겨갔다.
분류 정확도가 2%p 높은 모델이 실제 업무에서도 더 좋은 선택이라는 보장은 없다. 더 느리거나 비쌀 수 있고, 특정 입력에서만 잘 작동할 수도 있다. 잘못된 분류를 사람이 모두 다시 확인해야 한다면 높은 모델 점수가 시간 절감으로 이어지지 않는다. 결과가 검색, 승인, 라우팅, 실행으로 연결되지 않으면 좋은 출력도 업무 성과가 되지 못한다.
모델은 시스템의 한 부품이었다. 데이터, 규칙, 검색, 인터페이스, 사람의 검수, 업무 행동, 피드백 루프가 함께 있어야 실효성을 말할 수 있었다.
이 질문을 따라가다 Palantir Ontology와 SAP의 업무 구조까지 보게 됐다. Palantir는 Ontology를 객체와 관계의 표현에 그치지 않고, 데이터·로직·행동·보안을 연결해 조직의 의사결정을 모델링하는 시스템으로 설명한다. Palantir, The Ontology system Semantic Atlas가 같은 운영 플랫폼을 만들려던 것은 아니었다. 다만 모델을 현실의 의사결정과 연결하려면 업무 객체와 행동까지 봐야 한다는 문제의식은 이어져 있었다.
조직이 곧 시스템이다
목적과 데이터, Task가 같아도 모든 조직에 같은 시스템이 적합하지는 않다. 조직은 시스템을 운영하는 바깥 조건이 아니라, 그 시스템이 실제로 어떤 형태를 취할지를 결정하는 시스템 자체다.
NLP 엔지니어가 있는 조직은 자체 데이터로 분류기나 리랭커를 학습하고, 오류 유형을 분석하며, 주기적으로 모델을 개선할 수 있다. Agent 엔지니어 중심의 조직은 기존 모델과 도구를 조합하고 검색, 프롬프트, 규칙, 검수 흐름을 설계하는 방식이 더 현실적일 수 있다.
하지만 직무 이름만으로도 부족하다. 누가 분류 기준을 정의하는가. 모호한 사례의 최종 판단은 누가 하는가. 기준 변경이 기존 데이터와 리포트에 미치는 영향을 누가 관리하는가. 발견한 실패를 다시 학습 데이터나 규칙으로 돌려보내는 책임은 누구에게 있는가.
이 역할이 조직구조 안에 없으면 시스템은 처음에는 작동해도 시간이 갈수록 의미가 흐려진다. 반대로 도메인 담당자와 엔지니어, 운영자가 기준과 피드백을 함께 관리할 수 있다면 최고 성능 모델이 아니어도 더 안정적인 결과를 만들 수 있다.
그래서 Organization은 System과 분리된 마지막 고려사항이 아니다. 구성원, 역할, 책임, 피드백 경로가 모여 System의 작동 방식을 이룬다. Task 다음에 조직을 설계해야 하는 이유다.
결국 UX로 돌아온다
Semantic Atlas가 어려웠던 이유는 모델의 수가 많아서만이 아니었다. 비교의 기준을 끝까지 따라가면 모델 밖으로 나갈 수밖에 없었기 때문이다.
사용 목적이 문장의 의미와 분류 기준을 정한다. 그 기준이 데이터셋을 만들고 task를 나눈다. Task는 그것을 만들고 고치고 운영할 구성원과 역할을 요구한다. 그렇게 구성된 조직이 곧 System의 작동 방식이 된다.
여기서 말하는 UX는 화면을 편리하게 만드는 일보다 넓다. 사용자가 무엇을 알고 싶어 하는지, 그 앎으로 무엇을 결정하려는지, 시스템의 답을 어떻게 신뢰하고 행동으로 옮기는지를 이해하는 일이다.
Semantic Atlas는 AI 모델을 비교하기 위한 Ontology로 출발했다. 그러나 비교가 유효하려면 가장 먼저 사용 목적이 도출되어야 했다. 그 목적을 Task로 옮긴 뒤에는 구성원과 조직구조를 설계해야 했다. 그 조직구조가 곧 현실의 System이기 때문이다.
AI의 실효성은 가장 높은 점수를 받은 모델에서 결정되지 않는다. 사용자의 질문을 정확히 정의하는 일에서 시작해, 그 질문을 계속 책임질 수 있는 조직에서 완성된다.
결국 AI Model의 성능은 출발점이 아니었다. 사용 목적과 분류 기준, 데이터, Task, Organization이라는 조건을 먼저 정한 뒤, 그 Organization이 곧 System이 되는 과정 안에서야 의미를 갖는 마지막 변수였다.