레이블이 LLM인 게시물을 표시합니다. 모든 게시물 표시
레이블이 LLM인 게시물을 표시합니다. 모든 게시물 표시

11/29/2025

AI가 읽는 제품과 서비스를 설계

Written by Giljae Joo (주길재)  in , , , , ,   with 댓글 없음


지난 30년 동안 웹의 역사는 인간을 위한 설계, 즉 “사용자 경험(UX)”의 역사였습니다. 1990년대의 투박한 텍스트 기반 인터페이스에서 매끄러운 모바일 터치 인터페이스에 이르기까지, 기술적 진보의 중심은 “인간의 눈과 손”이었습니다. 그러나 2025년 현재 우리는 또 다른 거대한 전환점에 서 있습니다. 바로 AI 에이전트가 웹의 새로운 주요 사용자로 등장한 것입니다.

본 글은 짐 닐슨(Jim Nielsen), 마르타 페르난데스(Marta Fernandez), 마티아스 빌만(Mathias Bilmann)등 업계의 선구적인 사람들이 제기한 통찰을 바탕으로 작성되었습니다.

본 글에서 이야기하는 AX는 AI Transformation이 아닙니다. Agent Experience인 점을 기억해주세요.

AX(Agent Experience, AX)는 단순한 기술적 유행어가 아닙니다. 이는 웹의 본질을 “인간이 보는 공간”에서 “기계가 이해하고 행동하는 공간”으로 확장하는 구조의 변화입니다.

AX는 “AI 에이전트가 제품이나 플랫폼의 사용자로서 갖게 되는 전체적인 경험”이라고 정의되며, 이것이 향후 소프트웨어 산업의 핵심 경쟁력이 될 것이라 생각합니다. “AI에 의해 구동되는 인간 중심의 경험”으로 확장될 것이며, 알고리즘의 능력을 윤리적이고 이해 가능한 행동으로 번역하는 디자인이 중요해질 것입니다.

본 글에서는 AX의 정의와 필요성, 기술적 구현 방식 그리고 비즈니스와 웹의 미래에 미칠 영향을 포괄적으로 다룹니다.


AX의 정의와 패러다임의 전환

UX에서 AX로: 설계 단위의 변화

전통적인 UX 디자인은 인간의 인지적 한계와 심리적 만족을 최우선으로 고려했습니다. 버튼의 위치, 크기, 색상 그리고 직관적인 루트는 모두 인간의 시각적 처리를 돕기 위한 장치였습니다. 그러나 AI 에이전트에게는 이러한 시각적 요소는 오히려 정보 처리를 방해하는 소음이 됩니다.

마르타 페르난데스는 UX에서 AX로의 전환을 “설계 단위(Design Unit)”의 근본적인 변화라고 설명합니다.

<UX와 AX의 구조적 차이>

구분UX (사용자 경험)AX (에이전트 경험)
주요 사용자인간AI Agent
입력 방식시각, 터치, 음성텍스트, API, 데이터
설계 단위페이지, 화면, 선형적 흐름에이전트, 행동, 확률적 결정
핵심 목표만족도, 체류 시간, 시각적 즐거움성공률, 토큰 효율성, 자율성
예측 가능성정의된 상태가변적이고 설명 가능한 결과
오류 처리시각적 피드백자가 수정, 로그 기록

위 표가 시사하는 바는 인간을 체류시키기 위한 “몰입형 디자인”에서, 기계가 신속하게 목표를 달성하게 돕는 “효율성 디자인”으로의 이동입니다. 에이전트는 웹사이트의 아름다움에 감탄하지 않습니다. 목표 달성을 위한 데이터의 명확성과 구조적 논리성을 요구합니다. 따라서 AX 디자인은 화려한 그래픽을 걷어내고, 정보의 뼈대를 드러내는 작업과 같습니다.


새로운 페르소나

Netify CEO 마티아스 빌만은 소프트웨어 기업들이 제품을 개발할 때, AI 에이전트를 마케팅 담당자나 개발자처럼 하나의 구체적인 페르소나로 취급해야 한다고 주장합니다.

  1. 목표 지향적: 에이전트는 심심풀이로 웹 서핑을 하지 않습니다. 명확한 목적을 가지고 접근 합니다.
  2. 확률적 추론: 전통적인 프로그램과 달리, LLM기반 에이전트는 매번 동일한 경로로 움직이지 않을 수 있습니다. AX는 이런 불확실성을 수용하고, 에이전트가 길을 잃지 않도록 “가드레일”을 제공해야 합니다.
  3. 고도의 문자주의: 에이전트는 문맥 파악 능력은 뛰어나지만, 숨겨진 UI 요소나 암묵적인 관습보다 명시적인 텍스트를 선호합니다.


오픈 웹과 AX 철학

AX는 단순히 기업의 효율성을 높이는 도구를 넘어, 오픈 웹의 생존과 직결된 문제일 수 있습니다. 만약 특정 거대 기업들만이 독점적인 제휴를 통해 서비스들을 연결한다면, 웹은 소수를 위한 닫힌 공간으로 전략할 것입니다.

반면, 개별 웹사이트와 서비스들이 표준화된 AX(e.g. API, llms.txt)를 제공한다면, 에이전트가 자유롭게 웹을 탐색하고 상호작용할 수 있는 “오픈 에이전트 생태계”가 가능해집니다. 이는 짐 닐슨과 같은 웹 표준 옹호자들이 오랫동안 주장해 온 “누구나 접근 가능한 하이퍼텍스트로서의 웹” 이라는 철학과 매핑됩니다.


AX의 기술적 아키텍처와 구현

AX를 성공적으로 지원하기 위해서는 기존의 웹 개발 방식과는 다른 기술적 접근이 필요합니다. 핵심은 “기계 가독성”을 극대화 하는 것입니다.


llms.txt: 에이전트를 위한 지도

llms.txt에 대해서는 이전 글에 작성했으니, 참고해주세요.


API: 에이전트의 손과 발

AX의 세계에서 GUI(Graphic User Interface)는 보조적인 수단입니다. 에이전트에게 가장 강력한 인터페이스는 API(Application Programming Language) 입니다. 그 이유는 아래와 같습니다.

  • 자기 기술적 API: 에이전트가 사람의 개입 없이 도구를 사용하려면, API 명세서가 기계가 읽을 수 있는 형태로 완벽하게 제공되어야 합니다. 에이전트는 이 명세서를 메뉴얼처럼 읽고, 스스로 요청을 구성해야 합니다.
  • 예측 가능성: 에이전트 경험을 저해하는 가장 큰 요소는 “예기치 않는 변경” 입니다. API 응답 형식이 예고 없이 변경되면 에이전트의 논리 회로는 어려움을 겪습니다. 이는 개발자도 마찬가지죠 🙂 따라서 AX는 엄격한 버전 관리와 명확한 오류 메시지를 요구합니다.
  • 세밀한 권한 관리: 인간 사용자와 달리 에이전트는 수백 번의 작업을 순식간에 수행할 수 있습니다. 따라서 Read, Create 등 매우 세분화된 API 권한 관리가 필수적입니다.

토큰 경제학과 효율성

AX 디자인의 핵심 제약 조건은 “컨텍스트 윈도우” 입니다. AI 모델이 한 번에 기억할 수 있는 정보의 양은 제한적이며, 긴 텍스트를 처리할수록 비용과 시간이 증가합니다. 즉, 훌륭한 AX는 “최소한의 토큰으로 최대의 의미”를 전달하는 것입니다.

에이전트에게 5MB 사이즈의 자바스크립트가 포함된 페이지를 던져주는 것과 핵심 정보만 담긴 5KB 사이즈의 JSON이나 마크다운 요약을 제공하는 것 중 어떤 것이 좋은 AX일까요?


인간 중심의 기계 설계

AX가 기계를 위한 설계라 해도, 그 최종 목적은 인간을 돕는 것입니다. AX가 단순하게 자동화하는 것이 아니라 신뢰, 투명성 그리고 사용자 주체성을 위한 설계가 되어야 합니다.

사용자가 에이전트에게 “제주도행 항공권을 예매해줘” 라고 지시했을 때, 사용자는 에이전트가 자신의 의도대로 행동할 것이라고 믿어야 합니다. 이 신뢰를 구축하는 것이 AX의 핵심 과제입니다.

신뢰를 구축하려면 과정이 투명해야 합니다. 에이전트가 결과를 내놓기 전에 “당신의 요청에 따라 A 항공사와 B 항공사를 비교 중입니다.” 와 같은 중간 과정을 로그나 요약 형태로 보여주어야 합니다. 또한 결제 단계와 같은 중요한 스텝에 도달 했을 때에는 인간이 이를 검토하고 승인하거나 취소할 수 있는 명확한 인터페이스를 제공해야 합니다.

우리가 이제까지 알아왔던 UX에서 브랜드의 성격이 시각적 톤앤매너로 표현된다면, AX에서는 행동(Behavior)으로 표현됩니다. 예를 들어서 금융 서비스 에이전트는 매우 보수적이고 확인을 자주하는 Behavior로 설계해야 합니다. 이런 행동 양식을 부여하는 것이 사용자 경험의 일관성을 유지하는데 매우 중요합니다.


비즈니스 전략으로서의 AX와 미래 전망

AX는 단순한 개발 트렌드가 아닙니다. 조직의 이름 혹은 회사명을 변경한다고 AX를 한다고 할 순 없습니다. 이는 기업의 생존을 결정할 비즈니스 전략으로 바라봐야 합니다.

마티아스 빌만은 “LLM이 사용하기 어려운 도구는 도태될 것”이라고 단언합니다. 왜 이런 얘기를 할까요?

예를 들어, 두 개의 프로젝트 관리 도구가 있다고 가정해 봅시다. 도구 A는 화려한 Drag & Drop 인터페이스를 가졌지만 API가 빈약하고, 도구 B는 인터페이스는 매우 투박하지만 강력하고 문서화된 API를 제공합니다. 기업들이 업무 자동화를 위해 AI 에이전트를 도입할 때, 에이전트는 어떤 도구를 선택할까요? 아마도 도구 B를 선택할 것입니다. 그 이유는 에이전트가 조작할 수 없는 소프트웨어는 자동화된 워크플로우에서 배제되기 때문입니다. 즉, AX가 뛰어난 제품이 시장 우위를 점하게 됩니다.

검색 엔진 최적화(SEO)의 시대가 저물고, 에이전트 최적화(AEO)의 시대가 오고 있습니다. 이제 기업은 구글 검색 결과 1페이지에 오르는 것뿐만 아니라, ChatGPT나 PErplexity와 같은 답변 엔진이 자사의 정보를 인용하도록 만들어야 하기에 아래의 사항들이 중요해집니다.

  • 구조화된 데이터의 중요성: Schema.org를 통해 가격, 재고, 리뷰 평점을 명확하게 명시해야 에이전트가 신뢰할 수 있는 데이터로 인식합니다.
  • 에이전트 커머스: 2026년까지 상당수의 전자상거래가 인간의 직접 클릭이 아닌, 에이전트의 대리 수행으로 이루어질 것으로 예측됩니다. “가장 싼 방을 예약해줘”라는 지시를 수행하는 에이전트에게 선택받으려면, 에이전트가 즉시 접속 가능한 API와 정확한 실시간 데이터를 제공해야 합니다.

아마도 웹은 “인간이 소비하는 미디어 웹”과 “에이전트가 일하는 유틸리티 웹”으로 양분될 것입니다. 기업은 이 두 가지 웹을 동시에 만족시켜야 하는 과제에 직면하게 되지 않을까 합니다.


마무리

웹은 다시 한번 진화하고 있으며, 이번 진화의 주인공은 Agent라고 생각됩니다. 

이 바닥에서 일하는 우리들에게 AX는 선택이 아닌 필수입니다. 화려한 디자인 뒤에 가려진 정보의 장벽을 허물고, 에이전트가 자유롭게 드나들 수 있는 “약속된 문”을 만드는 것. 

이것이 AI 시대에 우리가 만드는 제품과 서비스가 살아남는 길이며, 인간과 AI가 공존하는 더 나은 디지털 세상을 만드는 방법이라 생각합니다. 

지금 당신이 만든 제품과 서비스는 Agent를 맞이할 준비가 되어 있습니까?


참고:

11/28/2025

AI가 읽기 쉬운 Web을 위한 llms.txt

Written by Giljae Joo (주길재)  in , , , , , ,   with 댓글 없음

우리는 매일 웹사이트에 접속합니다. 화려한 디자인, 편리한 메뉴 구성, 광고 배너들이 우리를 반깁니다. 하지만 이 모든 시각적 요소들은 AI에게는 그저 소음에 불과하다는 사실을 알고 계셨나요?

ChatGPT, Claude, Gemini와 같은 대규모 언어 모델(LLM)의 능력은 대단합니다. 사람들은 이제 검색을 하고 링크를 찾아다니는 대신, AI에게 질문을 합니다. 이때 AI는 웹사이트를 방문하여 정보를 읽어옵니다.

문제는 여기서 발생합니다. 사람을 타겟으로 보기 좋게 만들어진 웹사이트는 AI가 읽기에는 매우 복잡합니다. 광고 스크립트, 복잡한 레이아웃, 스타일 시트 등이 섞여 있어, 중요한 정보(텍스트)를 찾아내기 어렵게 만듭니다. 도서관에 갔는데 책의 내용보다 책 표지의 디자인과 도서 위치를 설명하는 안내표기가 더 많은 상황입니다.

이 문제를 해결하기 위해 등장한 것이 llms.txt 입니다. 본 글에서는 이 텍스트 파일이 왜 중요한지 알아보려 합니다.


llms.txt란?

쉽게 설명하면 llms.txt는 AI를 위해 특별히 준비된 전용 메뉴판입니다.

예를 들어서 레스토랑에 가면, 음식 사진이 포함된 메뉴판을 줍니다. 이는 사람을 타겟팅한 메뉴판입니다. 만약 LLM이 손님이라면 어떨까요? 사진이나 디자인은 필요 없습니다. 음식이름, 가격, 설명만 깔끔하게 정리된 것을 원할 것 입니다.

llms.txt가 이 역할을 해주게 됩니다. 웹사이트의 복잡한 디자인 요소를 모두 걷어내고, AI가 이해하기 쉬운 형태인 Markdown 형식을 사용해 핵심 정보만 제공합니다.

사람을 위한 웹사이트는 UX 관점에서 레이아웃, 메뉴 구조, 이미지, 버튼, 텍스트등이 필요했다면, LLM용 웹사이트는 제목, 요약, 핵심 문서로 가는 직관적인 링크만 필요할 뿐입니다.


왜 만들었지?

이 개념은 2024년 9월, Answer AI의 제러미 하워드가 제안하며 널리 알려지기 시작했습니다. AI 개발자들은 웹사이트의 정보를 AI에게 학습시키거나 검색하게 할 때마다 불필요한 HTML 코드를 걸러내는 작업이 지쳐 있었습니다.

“그냥 웹사이트 소유자들이 AI가 읽기 쉽게 요약본을 올려두면 안될까?”

이 단순한 아이디어가 llms.txt 프로젝트의 시작이었습니다.


왜 필요하지?

단순히 AI에게 친절하기 위해 필요한 것은 아닙니다. 여기에는 매우 현실적이고 경제적인 이유가 숨어 있습니다.

AI 모델을 사용할 대 정보의 양은 곧 비용입니다. AI는 글자를 읽을 때 “토큰”이라는 단위로 계산하는데, 불필요한 HTML 태그도 전부 토큰을 사용하게 됩니다.

만약에 웹사이트의 정보가 100인데, 디자인 코드 때문에 전체 데이터가 1000이 된다면, AI는 핵심 정보를 얻기 위해 10배의 비용과 노력을 들여야 합니다. llms.txt를 제공하면 알짜배기 정보 100만 읽으면 되기에 훨씬 효율적입니다.

또한, 아무리 똑똑한 AI라도 한 번에 기억하고 처리할 수 있는 정보의 양에는 한계가 있습니다. 쓸데없는 코드로 이 공간을 채워버리면, 중요한 내용을 AI가 잊어버리거나 놓칠 확률이 높아집니다.

깨끗하게 정리된 텍스트를 제공하면, AI는 한정된 기억 공간을 정보를 이해하는데 온전히 쓸 수 있습니다. 결과적으로 사용자가 웹사이트에 대해 질문했을 때, AI가 더 정확하고 똑똑한 답변을 할 수 있게 됩니다.


robots.txt와 차이점

기존의 robots.txt의 개념과 혼동하는 사람들이 존재합니다. 둘 다 웹사이트의 root에 위치하는 텍스트 파일이라는 점은 같지만, 목적은 완전히 반대입니다.

robots.txt의 목적은 “통제” 입니다. 어디를 들어오면 안되는지를 알려주는 역할을 합니다.

llms.txt의 목적은 “안내”입니다. 무엇을 읽어야 가장 정확한지 알려주는 역할을 합니다.

위 두 파일은 경쟁 관계가 아니라 상호 보완적인 관계입니다. 완벽한 웹사이트 관리를 위해서는 두 파일이 모두 필요합니다.


llms.txt 작성법

그렇다면 이 파일은 어떻게 생겼을까요? 생각보다 단순합니다. 개발자가 아니더라도 금방 만들 수 있습니다.


파일의 위치

웹사이트의 가장 최상위 주소 뒤에 붙습니다. e.g. https://example.com/llms.txt


기본 구조

llms.txt 파일 내부는 Markdown 문법을 따릅니다. 마크다운은 우리가 카카오톡이나 슬랙에서 글자를 굵게 만들거나 리스트를 만들 때 쓰는 아주 간단한 서식입니다.

# 사이트 이름
> 사이트에 대한 아주 짧은 요약

## 핵심 문서
- [가이드](https://...md) [사용법](https://...md)
- [자주 묻는 질문](https://...md)

## 추가 정보
이 사이트는 AI가 쉽게 읽을 수 있도록 구성되었습니다.
상세한 내용은 위 링크의 마크다운 파일을 참고하세요.

AI에게 “우리 사이트 이름은 이거고, 핵심 내용은 저 링크들에 있으니 저기를 읽어”라고 알려주는 Index 역할을 합니다.

Blot.new의 llms.txt는 여기서 확인해 보실 수 있습니다.


llms-full.txt

때로는 링크를 타고 가는 것조차 귀찮거나, 한 번에 모든 정보를 AI에게 주고 싶을 때가 있습니다. 이럴 경우 llms-full.txt라는 파일도 함께 만드는 것이 권장됩니다.

이 파일은 웹사이트의 모든 핵심 문서를 하나의 거대한 텍스트 파일로 합쳐둔 것입니다. AI는 여러 페이지를 왔다 갔다 할 필요 없이, 이 파일 하나만 읽으면 전체를 파악할 수 있게 됩니다.


기대효과

우리는 지금까지 구글이나 네이버 검색 결과 상단에 노출되기 위해 검색 엔진 최적화(SEO)를 적용했습니다. 하지만 이제는 인공지능 엔진 최적화(AEO) 또는 생성형 엔진 최적화(GEO)를 준비해야 할 때입니다.

사용자가 ChatGPT에게 “A회사 제품의 환불 규정이 뭐야?”라고 질문하면, AI가 복잡한 웹페이지를 해매다가 엉뚱한 답변을 할 수 도 있기에, llms.txt를 통해 명확한 환불 규정 텍스트를 제공한다면, AI는 정확한 답변을 사용자에게 전달할 수 있습니다.

개발자 도구나 API 문서를 제공하는 기업이라면 llms.txt는 필수입니다. 요즘 개발자들은 코딩할 때 AI의 도움을 받는데, AI가 해당 라이브러리의 사용법을 잘 숙지하고 있을수록 개발자들의 선택을 받을 확률이 높아지기 때문입니다.


결론

llms.txt를 작성하다 보면 한 가지 흥미로운 사실을 깨닫게 됩니다. 군더더기를 빼고, 핵심만 명료하게 정리하고, 목차를 일목요연하게 만드는 작업이 사실은 “사람”에게도 필요한 일이라는 점입니다.

AI가 읽기 쉬운 글은 사람도 읽기 쉽습니다. llms.txt의 도입은 단순히 기계를 위한 작업을 넘어, 웹사이트가 담고 있는 정보의 본질이 무엇인지 다시 한번 점검하고 정제하는 계기가 될 것입니다.

아직 이 표준은 초기 단계입니다. 구글이나 오픈AI가 공식적으로 따르겠다라고 선언한 것은 아닙니다. 하지만 웹의 역사가 증명하듯, 유용한 약속은 결국 표준이 됩니다.

지금 당신의 웹사이트 루프에 작은 텍스트 파일 하나를 추가해보는 것은 어떨까요? 다가오는 AI 검색 시대에, 당신의 콘텐츠가 가장 먼저, 가장 정확하게 읽히는 티겟이 될지 모릅니다.

9/18/2025

Text to SQL이 왜 잘 안될까?

Written by Giljae Joo (주길재)  in , , , ,   with 댓글 1개

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는 엄격한 범위 설정이 중요하다. 정확성이 입증된 후에만 확대하는 것이 효과적이다.

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

3/04/2025

오픈소스 LLM(Large Language Model)

Written by Giljae Joo (주길재)  in , ,   with 댓글 없음


LLM(Large Language Model)을 선택할 때는 두 가지 경로가 있다. 오픈소스냐 아니냐이다.

본 글에서는 오픈소스 LLM을 선택할 때의 이점을 살펴본다.


생성형 AI가 많이 쓰여짐에따라 방대한 데이터를 분석하고, 비즈니스 전략을 수립하고, 상호작용을 간소화하고, 고객에게 개인화된 응답을 제공할 Needs가 있을 수 있다. 이럴 경우 기술 스택에 대한 고려를 해야 할 시점에 있을 수 있다.


“상용 서비스를 사용해야 할까? 아니면 오픈소스 LLM을 선택해야 할까?”


물론, 처음부터 완전한 맞춤형을 사용하는 것은 매력적일 수 있다. 실제로 LLM은 시간, 돈, 노력을 들일 만한 가치가 없는 대규모 사업일 수 있다. 비용, 확장 및 업데이트의 어려움, 환경적 영향 등 고려해야 할 단점이 존재한다.


많은 리더들은 LLM을 처음부터 완전하게 훈련하지 않고도 사용할 수 있다는 사실을 깨닫지 못한다. 오픈소스 모델에는 이미 기초적인 지식과 기술이 포함되어 있다. 그리고 자체 데이터를 추가하여 정의하고 생성 AI 쿼리에서 훌륭한 결과를 얻는 데 필요한 컨텍스트를 제공할 수 있다.


대부분의 회사는 활용되지 않거나 갇힌 데이터처럼 보물 창고를 가지고 있다. 즉, 여러 팀, 조직 또는 문서에 분산되거나 Silo된 데이터를 의미한다. 이런 데이터는 구조화된 데이터(엑셀, 데이터베이스)와 구조화되지 않은 데이터(로그, 채팅 로그, 이메일)로 구분된다.


에릭 레이몬드의 “성당과 시장”이라는 책을 보면 상용 솔루션과 오픈소스 진영에 대한 이야기가 나온다. AI 시대에도 이런 움직임이 있다. 독점 시스템의 장벽을 허물어 전 세계의 개발자, 연구자, 열광자들이 기초 모델에 기여하고, 수정하고, 개선하도록 노력하고 있다.


이런 커뮤니티 기반의 협력 모델은 해당 분야의 발전을 가속화할 뿐만 아니라 AI 기술의 이점을 더 광범위하게 이용할 수 있도록 보장한다.


나도 이번에 LLM 관련해서 준비해야 할 것이 있고, 접근을 오픈소스 기반으로 하고 있기에., 관련 내용을 정리해본다.


오픈 소스 LLM이란?

오픈소스 LLM은 인간 언어를 이해하고, 생성하고, 조작하도록 설계된 AI 모델의 유형이다. 오픈소스라는 것은 모델의 아키텍처, 코드, 모델 등 누구나 자유롭게 사용, 수정, 배포할 수 있다는 것을 의미한다. 높은 가용성과 낮은 비용은 AI 개발에 대한 협력적이고 투명한 접근 방식을 촉진한다.


오픈소스 LLM은 유일한 LLM은 아니다. 그러나 가장 널리 접근 가능한 모델이다.


오픈 소스 LLM은 독점 LLM과 어떻게 다른가?

오픈 소스 LLM은 주로 접근성과 적응성에서 독점적인 대응 제품과 다르다. 오픈소스 모델은 사용, 수정 및 배포를 위해 무료로 제공된다. 이런 특징은 혁신에 대한 협력적 접근 방식을 장려하고 특정 요구 사항에 대한 수정을 허용한다.


이와 대조적으로 독점적인 LLM은 특정 회사가 통제하고 소유한다. 공급업체는 라이선스 등 LLM에 대한 접근을 제한하고, 특정 요구 사항에 대한 수정을 제한한다.


이런 근본적 차이는 해당 모델을 제공하는데 드는 비용과 유연성에 영향을 미친다.


오픈 소스 LLM의 이점

ChatGPT가 세상에 공개되자마자 OpenAI의 GPT 모델은 빠르게 유명해졌다. 하지만 해당 모델은 많은 비용이 동반되어야 하기에 많은 기업들이 대규모 모델에 투자하는 것의 가치에 의문을 제기하기도 했다.


이에 따라 많은 기업이 소규모의 개방형 LLM을 선택하여 RAG(Retriever-And-Generator) 파이프라인을 활용하여 데이터를 통합하고 비슷하거나 더 뛰어난 효율성을 달성하고 있다.


고려해 볼 만한 폐쇄형 LLM에는 여러가지 장점이 있다.


비용 효율성

오픈소스 LLM은 독점적 모델에 비해 비용 효율적인 대안을 제시하여 기업이 AI 역량을 활용할 수 있는 재정적으로 실행 가능한 수단을 제공한다.


  • 라이센스 비용이 필요하지 않기에 초기 비용과 지속적인 비용 절감을 기대할 수 있다.

  • 해당 모델을 자유롭게 조직내에 배포할 수 있다.

  • 특정 맞춤형 서비스가 가능하기에 효율성이 향상될 수 있다.


데이터 소유권 및 제어

오픈소스 LLM을 활용하는 것은 데이터에 대한 통제력과 소유권을 확보하여 다양한 매커니즘을 통해 보안을 강화한다.


  • 데이터 호스팅 제어

    • 온프레미스 또는 신뢰할 수 있는 클라우드 공급자의 호스팅을 선택

    • 민감한 데이터를 보호하는게 중요하다.

  • 내부 데이터 처리

    • 민감한 데이터 유출을 방지한다.

    • 데이터 침해 위험을 줄이고 개인 정보 보호를 강화한다.

  • 투명성

    • 오픈 소스 특성으로 인해 코드와 프로세스 감시가 가능하다.

    • 내부 규정 준수 기준에 부합하는지 확인이 가능하다.


오픈 소스 LLM을 사용하는 기업

전 세계 다양한 기업이 오픈 소스 LLM을 활용하고 있다.


Shopify

Shopify는 Llama 2를 활용하여 LLM을 채택했다. 이 도구는 소규모 업체가 상거래 관리와 관련된 작업을 자동화하도록 지원한다.

상품 설명을 생성하고, 고객 문의에 답변하고, 마케팅 콘텐츠를 만들어 시간을 절약하고 운영을 간소화하는데 도움이 된다.


Perplexity

Perplexity가 오픈 소스 LLM을 활용하는 방법은 다음과 같다.



응답 생성 프로세스

사용자가 질문을 하면 Perplexity 엔진은 약 6단계를 실행하여 답변을 작성한다. 이 프로세스에는 여러 언어 모델을 사용하여 포괄적이고 정확한 답변을 제공하고자 한다.


Perplexity는 자체적으로 개발한 오픈 소스 LLM을 사용한다. Mistral 및 Llama와 같은 기존 프레임워크를 개선한 이 모델은 사용자의 문의와 관련된 콘텐츠를 간결하게 요약하도록 맞춤화 되어 있다.


오픈 소스 LLM을 활용한 사례 및 가능성

오픈 소스 LLM은 다양한 산업과 애플리케이션에서 수많은 기회를 열어주었다. 다음은 오픈소스 LLM의 잠재력에 대한 일반적인 사용 사례와 가능성이다.


챗봇 및 대화형 에이전트

오픈소스 LLM은 자연스럽고 의미 있는 대화에 참여할 수 있는 정교한 챗봇을 만들 때 사용할 수 있다.


콘텐츠 생성

블로그 게시물과 마케팅 카피 및 스토리텔링까지 오픈소스 LLM은 고품질 콘텐츠를 빠르고 효율적으로 생성할 수 있다. 사용자는 해당 모델을 사용하여 아이디어를 브레인스토밍하고, 기사 초안을 작성하거나, 반복적인 쓰기 작업을 자동화할 수 있다.


코드 생성 및 지원

코드 스니펫을 생성하고 기존 코드를 디버깅함으로써 개발자를 지원할 수 있다. Copilot, Cursor AI등으로 이미 입증되었으며, 오픈소스 대안으로 공급업체에 묶이지 않고도 유사한 기능을 제공할 수 있다.


감정 분석 및 텍스트 분류

내가 중점을 가지고 보고 있는 사안이다. 감정 분석을 위해 오픈 소스 LLM을 활용하여 리뷰 또는 피드백에서 고객 의견을 측정할 수 있다. 텍스트 분류 모델은 대규모 데이터 세트를 구성하는데 도움이 되고 구조화되지 않은 데이터에서 통찰력을 추출하는 것을 쉽게 만들어준다.


교육 도구

LLM은 강력한 교육 도구로 활용될 수 있다. 학습자의 진도와 선호도에 따라 콘텐츠를 조정하는 개인화된 학습 경험, 튜터링등을 제공 할 수 있다.


연구 개발

실험과 가설 검증을 수행할 수 있다. 모델을 수정할 수 있는 능력은 새로운 이론을 시험하고, 방법을 탐구할 수 있게 해준다.


오픈 소스 LLM 시작하기

처음에는 어려울 수 있으나, 과정은 간단할 수 있다. 아래는 LLM에 대해서 시작하기 위한 단계이다.


1단계: 사용 사례 식별

기술적인 측면에 들어가기 전에 LLM으로 무엇을 성취하고 싶은지 정의하는 것이 중요하다.


“LLM을 이용해 무엇을 하고 싶은가?” 에 대한 질문에 답을 할 수 있어야 한다. 그래야 필요에 맞는 올바른 모델과 도구를 선택할 수 있다.


2단계: LLM 선택

사용 사례에 적합한 LLM을 선택하는 것이 중요하다.  성능, 확장성, 커뮤니티 지원 등과 같은 요소를 고려하여 사용 가능한 모델을 조사해야 한다. 현재 인기 있는 오픈소스 LLM은 다음과 같다.


  • Llama

    • 장점: 성능과 확장성으로 유명하다. 다양한 애플리케이션을 위해 다재다능하게 설계되었다. 속도와 품질 간의 균형을 제공하여 대화형 AI 및 콘텐츠 생성과 같은 작업에 적합하다.

    • 응용 분야: 챗봇, 글쓰기 도우미, 교육 도구

  • CodeZen

    • 장점: 코드 생성에 특별히 맞춤화되어 있다. 고품질 코드 스니펫을 생성하고 개발자에게 제안을 하는데 뛰어나다.

    • 응용 분야: 소프트웨어 개발, 디버깅 지원, 코딩 교육

  • MIXTRAL

    • 장점: 다양한 텍스트 관련 작업에서 성과를 향상시키기 위해 여러 가지 훈련 기술을 결합한다. 다양한 맥락에 적응할 수 있도록 설계되어 많은 사용 사례에서 좋은 결과를 낸다.

    • 응용 분야: 텍스트 분류, 감정 분석, 개인화된 콘텐츠 생성

  • Falcon

    • 장점: 효율성과 속도가 뛰어난 것으로 알려져 있다. 챗봇이나 실시간 콘텐츠 생성과 같은 분야에 적합하다.

    • 응용 분야: 고객 지원, 대화형 인터페이스, 실시간 데이터 처리

  • GPT-NeoX-20B

    • 장점: 200억 개의 매개변수를 갖춘 상업용 LLM에 대한 가장 큰 오픈소스 대안 중 하나이다. 일관되고 맥락적으로 관련성 있는 텍스트를 생성하는데 안정적인 성능을 제공한다.

    • 응용 분야: 복잡한 콘텐츠 생성, 학술 연구, 글쓰기

  • Ollama

    • 장점: 로컬 실행으로 데이터 프라이버시를 보장하며, 비용 효율성과 맞춤화가 뛰어나 개인 장치에서 강력한 LLM을 운영하기에 최적이다.

    • 응용 분야: 코드 생성, 의료 데이터 분석, 교육 지원, 고객 서비스 챗봇, 콘텐츠 제작


각 모델은 다양한 분야에 적합한 장점을 지니고 있다.


3단계: 환경 설정

선택한 LLM을 실행하려면 적합한 환경이 필요하다. 로컬 머신이나 클라우드 기반일 수 있다. 진행 방법은 다음과 같다.


  • 로컬: 머신에 충분한 연산 능력(가급적으로는 GPU)이 있다면, TensorFlow나 PyTorch와 같은 필수 라이브러리를 설치하여 모델을 로컬에서 실행할 수 있다.

  • 클라우드: 하드웨어를 관리하지 않으려는 사람들을 위해 AWS, Google과 같은 다양한 플랫폼이 LLM에 대한 클라우드 기반 접근을 제공한다.


4단계: 모델 액세스

오픈소스 LLM은 모델을 다운로드하고 구현하기 위한 사용자 친화적인 인터페이스를 제공한다.


5단계: 미세 조정 및 정의

모델에 액세스하면 사용 사례와 일치하는 특정 데이터에 대해 모델을 미세 조정할 수 있다. 필요한 데이터 세트에 대해 추가로 학습하여 요구 사항에 맞게 더 나은 성능을 발휘할 수 있도록 하는 것이 포함된다.


6단계: 모델 배포

모델을 훈련하고 테스트한 후 마지막 단계를 배포다. 사용 사례에 따라 모델을 애플리케이션에 통합하거나 웹 서비스로 설정하여 배포할 수 있다.


결론

오픈소스 LLM은 접근성을 개방하여 혁신을 촉진하고 산업 전반에 걸친 다양한 응용을 활성화하고 있다. 오픈소스의 등장은 혁신, 창의성, 생산적 관점에서 AI의 진보가 그 어느 때보다 협력적이고 접근하기 쉬운 새로운 시대를 알리는 신호이다.


여기에 승선하여 몸 담고 있는 곳에서 미래를 향한 길을 밝힐 필요가 있다.