11/29/2025

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


지난 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

우리는 매일 웹사이트에 접속합니다. 화려한 디자인, 편리한 메뉴 구성, 광고 배너들이 우리를 반깁니다. 하지만 이 모든 시각적 요소들은 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 검색 시대에, 당신의 콘텐츠가 가장 먼저, 가장 정확하게 읽히는 티겟이 될지 모릅니다.

11/27/2025

AI Model과 Agent



예전만 해도 우리는 AI에게 이렇게 말했습니다.

“파리 가는 비행기 표 좀 찾아줘.”

그러면 AI는 친절하게 대답했죠.

“여기 시간표 입니다. 예매는 링크를 눌러서 직접 하세요.”

하지만 위 대화는 완전히 변경되었습니다. OpenAI가 결제 기업 스트라이프(Stripe)와 “인스턴트 체크아웃” 기능을 도입했기 때문입니다. (아직은 지역적 한계가 있음) 이제 사용자가 “이 티켓 예매해줘”라고 말하면, ChatGPT는 등록된 카드로 실제 결제를 진행합니다.

이 현상은 “순수 모델(Model)”의 시대가 저물고, 행동하는 “에이전트(Agent)”의 시대가 본격적으로 열린 것입니다.

본 글에서는 단순히 기술의 변화를 언급하는 것보다, 어떤 원리로 AI가 내 지갑을 열 수 있게 된것인지, 이 변화가 우리에게 어떤 영향을 줄 것인지 살펴 보도록 하겠습니다.


모델 중심(Model-centric): “뇌(Brain)만 있는 천재의 한계”

우리가 흔히 알고 있는 초기의 ChatGPT는 Model-centric의 산물입니다. “유리병 속에 든 뇌” 였죠.

모델은 인터넷의 모든 텍스트를 읽고 학습했습니다. 그래서 아는 것이 엄청나게 많습니다. 변호사 시험도 보고, 의사 면허 시험도 봅니다. 그러나 모델에게는 치명적인 결함이 있었습니다.

  1. 손발이 없다: 인터넷 뱅킹 앱을 켤 손가락이 없습니다.
  2. 신분증이 없다: 결제를 하려면 로그인을 해야 하는데, AI 모델 자체는 “계정”이나 “카드 정보”를 가질 수 없었습니다.
  3. 책임감이 없다: 모델은 다음 단어를 확률적으로 뱉어낼 뿐, “비행기 표를 예매했다.”고 말해놓고 실제 예약을 안해도 죄책감을 느끼지 않습니다.

그래서 AI는 말만 청산 유수인 심부름은 못 시키는 답답한 천재 였습니다.


에이전트 중심(Agent-centric): “뇌(Brain)에게 손과 발을 달아주다”

올해, 빅테크 기업들은 방향을 틀었습니다. “더 똑똑한 뇌를 만드는 건 이제 가성비가 안나온다. 대신 뇌에게 손발을 달아주자” 이것이 바로 Agent-centric의 핵심 철학 입니다.

OpenAI는 “에이전틱 커머스 프로토콜”을 발표했습니다. 쉽게 말해서 AI에게 안전하게 신용카드를 쥐어주는 기술입니다. 사용자가 미리 결제 시스템에 카드를 등록해두면, AI는 카드 번호를 몰라도 “결제 토큰”이라는 암호만 던져서 결제를 승인 받습니다.

2024년 엔트로픽은 더 과격한 방식을 택했습니다. AI(Claude)에게 아예 모니터 화면을 보여주고 마우스와 키보드 권한을 줬습니다.

“이 엑셀 파일 열어서, A열에 있는 사람들한테 이메일 보내줘”라고 시키면, AI가 실제로 마우스 커서를 움직여 엑셀을 켜고, 복사/붙여넣기를 하며 이메일을 보냅니다. API가 없는 구형 소프트웨어까지 AI가 조작할 수 있게 된 사건입니다.


에이전트는 어떻게 결제 하는가?

위에서 언급한 내용을 보면 “AI가 돈을 쓴다니 무섭다.”고 생각할 수 있습니다. 그러나 그 내부를 들여다보면 마법이 아니라 매커니즘이 작동합니다.

예를 들어 “스타벅스에서 아이스 아메리카노 주문해줘”

1. 의도파악 - 뇌의 역할

  • 생각: “사용자가 커피를 원한다. 이건 대화로 해결할게 아니라 주문 행동이 필요해.”
  • 판단: Order_Coffee라는 도구를 써야겠군

2. 파라미터 추출 - 뇌의 역할

  • 생각: “메뉴는 아이스 아메리카노, 매장은 사용자의 현재 위치 근처인 강남점, 사이즈는 기존으로 설정하자.”

3. 도구 호출 - 손의 역할

  • 여기서 AI는 텍스트를 응답하는게 아니라 코드(함수)를 호출합니다.
  • run_function: Startbucks_Order(item=”Ice Americano”, store=”Gangnam”, payment_token=”.....”)

4. 인간 승인 - 안전 장치

  • 화면에 팝업이 뜹니다.
  • 시스템: “강남점에 아메리카노 5000원 결제할까요? [승인/거절]
  • 사용자: [승인] 클릭

5. 실행 및 결과 보고

  • 시스템이 실제 스타벅스 서버로 주문을 넣고 “주문 번호”를 받아옵니다.
  • AI: “주문 완료했습니다. 번호는 A-55입니다.”

즉, AI 모델 자체가 돈을 만드는게 아니라, AI가 “결제 앱”을 리모컨처럼 조종하는 것입니다. 이것이 바로 에이전트의 본질입니다.


에이전트를 천재처럼 만드는 법

앤드류 응(Andrew Ng)은 “2025년 AI 경쟁력은 모델의 IQ가 아니라, 일하는 방식(Workflow)에 있다”고 얘기했습니다. 멍청한 모델도 다음과 같은 패턴으로 일하면 천재처럼 성과를 낼 수 있다는 의미입니다.


성찰: “나 실수 안 했나?”

AI가 코드를 짰는데 에러가 발생한 상황에 대해 과거 모델은 그냥 멈추거나 틀린 코드를 주는데, 에이전트는 “어? 에러 메시지가 떴네? 3번째 줄 문법이 틀렸구나, 다시 고쳐서 실행해보자.” (스스로 수정 후 성공)


도구 사용: “모르면 찾아봐”

“오늘 삼성전자 주가 어때?”라는 질문에 에이전트는 뇌피셜로 말하지 않습니다. 실시간 주식 API를 호출해서 현재 얼마인지 팩트를 말합니다.


계획

“이번 주말 부산 여행 코스 짜고 예약해줘”라는 질문에 에이전트는 아래처럼 행동합니다.

  1. KTX 시간표 조회
  2. 호텔 검색 (사용자 취향 반영)
  3. 맛집 리스트업
  4. 사용자 컨펌 후 일괄 결제

멀티 에이전트: “팀으로 일하라”

복잡한 소프트웨어 개발을 할때, 에이전트로 팀을 구성합니다.

  • 기획자 AI: 요구사항 정리
  • 개발자 AI: 코드 작성
  • 테스터 AI: 코드 실행 및 버그 찾기 (개발자 AI를 혼냄)

이들이 서로 대화하며 밤새 프로그램을 완성해 놓습니다.


검색의 종말과 대행의 시작

이 기술의 변화는 우리 삶과 경제에 어떤 충격을 줄까요?


광고 시장의 붕괴와 재편

검색의 시대가 끝날 수 있다고 생각될 수 있습니다.

과거에는 “제주도 호첼” 검색 -> 블로그 10개 읽으면서 광고 봄 -> 비교 후 예약 (1시간 소모)

미래에는 “제주도 호텔 괜찮은 곳 예약해줘”(1-3분 소모) 라고 말해서 예약이 되면, 검색 광고 모델이 수익원인 서비스들은 큰 위기를 맞습니다. 그리고 예약 서비스를 제공하는 곳은 AI의 추천 목록 1순위에 들어가는 것이 기업의 생존 과제가 될 수 있습니다.


SaaS

지금까지는 엑셀을 돈 내고 사서, 사용법을 우리가 공부해야 했습니다. 앞으로는 “재무제표 정리해주는 AI” 자체를 구독할 수 있습니다. 소프트웨어의 기능이 아니라, 그 소프트웨어가 만들어내는 결과를 사는 시대로 바뀔 수 있습니다.


우리가 경계해야 할 것들

모든 기술에는 그림자가 있습니다. 즉, “결제하는 AI”는 새로운 위험을 만들 수 있습니다.

에이전트가 오작동을 일으켜, “생수를 주문해줘”라는 명령에 무한 루프가 걸려 물을 1000개를 주문한다면? 그래서 중요한 순간에 반드시 인간 개입(Takeover) 모드를 발동시킵니다. “결제하시겠습니까?” 라는 최종 결정은 인간에게 넘기는 것이죠.

또한, AI 내 카드로 해킹 사이트에서 결제하면 누구 책임일까요?

  • AI 개발사?
  • 결제 모듈사?
  • 행위를 한 사용자?

이제 AI는 결제도 하고, 화면도 보고, 마우스도 움직입니다. 이것은 “에이전트 혁명”입니다. 과거의 AI가 말을 잘하는 비서였다면, 지금의 AI는 일 잘하는 파트너입니다. 이제 우리는 작업자의 마인드에서 벗어나야 합니다. 에이전트에게 명확한 목표를 주고, 결과물을 검토하고 승인하는 관리자의 역량이 중요해졌다고 생각됩니다.

11/05/2025

머신 러닝을 시작하는 프로그래머가 저지르는 실수


머신러닝을 시작할 때 정해진 방법은 없습니다. 각기 다른 방식으로 배우고, 목적 그리고 목표도 다릅니다.

프로그래머가 머신러닝의 세계로 뛰어드는 것은 새로운 프로그래밍 언어를 배우는 것과는 다른 경험입니다. 논리와 명확한 규칙, 100% 예측 가능한 결과에 익숙한 경험을 규칙이 아닌 데이터에서 패턴을 학습하고, 확률과 통계에 기반한 경험으로 바꿔야 합니다.

이런 근본적인 차이 때문에, 뛰어난 프로그래머도 머신러닝을 시작할 때 함정에 빠지곤 합니다. 이 글은 프로그래머가 겪을 수 있는 실수와 머신러닝 실무자로 거듭나기 위한 사고방식의 전환에 대해 이야기합니다.


실수 1: 바퀴를 재발명하려고 한다. (알고리즘 구현에 집착)

가장 흔한 실수입니다. 프로그래머는 종종 "이 기술이 어떻게 작동하는지" 알아야 직성이 풀립니다. 그래서 선형 회귀, 서포트 벡터 머신 같은 알고리즘을 밑바닥부터 직접 구현하려고 시도할 수 있습니다.

이는 마치 웹 애플리케이션을 만들기 위해 HTTP 프로토콜과 TCP/IP 소켓을 직접 구현하는 것과 같습니다. 물론 훌륭한 경험이 되겠지만, 당장 무언가를 해결하기 위해서는 비효율적입니다.

"알고리즘과 작동 원리"와 "이 알고리즘을 문제에 적용하는 법" 두 가지를 동시에 해결해야 합니다. 이미 어느정도 최적화된 라이브러리가 있는데, 굳이 처음부터 코드를 짜는 것은 낭비일 수 있습니다.

일단 라이브러리 사용자가 되었으면 합니다. 잘 만들어진 라이브러리를 가져와 문제에 적용하는 것부터 해보는것을 추천합니다. 알고리즘의 세부 구현은 나중에 그 기술을 깊게 파고들거나, 운영 환경에 맞는 커스터마이징이 필요할 때 파고들어도 늦지 않습니다.


실수 2: 100% 정확도를 추구한다.

프로그래밍 세계에서는 버그는 "0" 또는 "1"입니다. 코드는 작동하거나, 작동하지 않거나 둘 중 하나입니다. 하지만 머신러닝의 세계는 다릅니다.

소프트웨어 버그는 "실패"이지만, 머신러닝 모델의 95% 정확도는 "엄청난 성공"일 수 있습니다.

머신러닝은 본질적으로 통계적 추론입니다. 현실 세계의 데이터는 노이즈가 많고 불완전합니다. 100% 정확한 모델은 사실상 불가능하며, 만약 100%가 나왔다면 "Overfitting"울 의심해야 합니다.

"이 정도면 괜찮은데?"를 받아들이는 것이 중요합니다. 90% 정확도의 모델이라도 비즈니스 문제를 해결하고 가치를 창출할 수 있다면 성공입니다.

"완벽한 정답"이 아닌 "최선의 추정치"를 찾는 것을 목표로 해야 합니다. 모델의 성능을 높이는 것도 중요하지만, 그 모델이 실제 문제를 해결하는데 얼마나 유용한지를 기준으로 판단해야 합니다.


실수 3: 코드만 보고 프로세스를 놓친다.

프로그래머는 종종 "어떤 알고리즘을 사용할까?"라는 "모델링(코딩)" 단계에 집중합니다. 머신러닝에서는 모델링 코드가 차지하는 비중은 20%도 되지 않을 수 있습니다.

머신러닝의 성공은 알고리즘이 아니라 데이터와 프로세스에 있습니다. 따라서 전체 워크플로우에 익숙해져야 합니다.

  1. 문제 정의: 무엇을 하려고 하는가?
  2. 데이터 수집 및 정제
  3. 모델이 잘 학습할 수 있도록 데이터를 가공
  4. 모델 선택 및 훈련: 다양한 모델을 빠르게 테스트
  5. 평가 및 튜닝: 모델의 성능을 검증하고 개선
  6. 배포 및 모니터링: 실제 서비스 적용

GUI기반 도구로 이 전체 흐름을 먼저 경험해보는 것도 좋은 방법입니다. 코딩 없이 데이터가 어떻게 흘러가는지 한눈에 볼 수 있습니다.

나중에 Weka에 대해서 다뤄보도록 할께요.


실수 4: 수학에 압도당하거나 무시하거나

"머신러닝을 하려면 수학 학위가 필요한가요?" 많은 이들이 겁부터 먹습니다. 혹은 반대로 "라이브러리가 다 해주는데 수학이 필요한가요?" 라며 수학을 무시합니다. 둘 다 문제입니다.

자동차 운전을 위해 엔진의 연소 원리를 알 필욘 없지만, 차가 꿀렁거리거나 이상한 소리가 나면 최소한의 지식(엔진오일, 냉각수)이 있어야 문제를 진단할 수 있습니다.

모델이 왜 이런 예측을 했는지, 왜 성능이 안나오는지 이유를 모른 채 그저 파라미터만 바꿔가며 "감"에 의존하는 수학 무시형은 디버깅이 불가능해집니다.

이론에만 매몰되어 실제 코드를 한 줄도 짜보지 못하는 수학에 압도형은 지쳐서 포기하게 됩니다.

그래서 필요할 때 학습하는 전략을 취하시면 됩니다.

  1. 일단 라이브러리로 모델을 돌려봅니다.
  2. 모델 성능이 기대에 미치지 못하면, 해당 알고리즘의 작동 원리와 관련된 수학을 찾아보며 이해도를 높입니다.
  3. 수학은 머신러닝을 시작하기 위한 필수 조건이 아니라, 더 잘하기 위한 핵심 도구입니다.


실수 5: 자동화

마지막으로, 프로그래머분들이 가진 강력한 무기를 잊지 않았으면 합니다. 바로 자동화와 시스템 구축 능력입니다. 많은 데이터 사이언티스트가 Colab or Jupyter에서 훌륭한 모델을 만들지만, 이를 실제 운영 환경에 배포하고 유지보수하는데 어려움을 겪습니다.

프로그래머는 이미 익숙한 CI/CD, 테스트 자동화, 빌드 및 배포에 대한 파이프라인 개념은 머신러닝 세계에서는 MLOps라고 불립니다. 이 영역은 프로그래머가 가장 빛을 발휘할 수 있는 기회입니다. 모델을 "만드는 것"을 넘어, 모델을 "안정적으로 서비스하는 것"에서 가치를 증명하시면 됩니다.

머신러닝은 코딩 스킬에 "실험"과 "통계"라는 새로운 스킬을 더하는 과정입니다. 알고리즘 구현이라는 숲에 갇히지 말고, 라이브러리를 활용해 문제를 해결하는 더 큰 그림을 보세요.

프로그래머들의 강력한 엔지니어링 능력은 머신러닝 프로젝트를 "연구"에서 "제품"으로 만드는 핵심 열쇠가 될 것입니다.

11/03/2025

누군가 내게 말해줬더라면 좋았을 것들

본 글은 샘 알트먼의 블로그의 "What I Wish Someone Had Told Me"의 글을 번역했습니다.


1. 낙관주의, 집착, 자기 믿음, 순수한 추진력 그리고 인맥은 일이 시작되는 방식이다.

2. 응집력 있는 팀, 침착함과 긴급함의 적절한 조화, 비이성적인 헌신은 일이 마무리되는 방식이다. 장기적인 안목은 부족하기 쉽다. 단기적으로 사람들이 어떻게 생각하는지에 대해 걱정하지 않으려 노력해야 한다. 이는 시간이 지남에 따라 더 쉬워질 것이다.

3. 팀이 별로 중요하지 않은 쉬운 일을 하는 것보다 정말로 중요한 어려운 일을 하는 것이 더 쉽다. 대담한 아이디어는 사람들에게 동기를 부여한다.

4. 인센티브는 초능력이다. 신중하게 설정해야 한다.

5. 당신의 자원을 확신이 강한 소수에게 베팅하도록 집중해야 한다. 말하기는 쉽지만 이행하기는 어렵다. 당신이 생각하는 것보다 더 많은 것을 삭제할 수 있다.

6. 명확하고 간결하게 소통해라.

7. 불필요한 겉치레와 관료주의를 볼 때무다 맞서 싸우고 다른 사람들도 그렇게 하도록 해라. 조직도가 사람들이 생산적으로 함께 일하는 데 방해가 되지 않도록 해라.

8. 중요한 것은 결과이다. 좋은 과정이 나쁜 결과를 변명하게 두지 말아라.

9. 채용에 더 많은 시간을 써야 한다. 빠른 개선 속도를 보이는 잠재력이 높은 사람들에게 위험을 감수해라. 지능 외에도 일을 완수해낸 증거를 찾아라.

10. 슈퍼스타들은 보기보다 훨씬 가치가 있지만, 당신은 사람들이 조직의 성과에 미치는 순수한 영향을 기준으로 평가해야 한다.

11. 빠른 반복은 많은 것을 만회할 수 있다. 빨리 반복한다면 틀리는 것은 괜찮다. 계획은 수십 년 단위로, 실행은 주 단위로 측정되어야 한다.

12. 비즈니스 세계의 물리 법칙과 맞서 싸우지 말아라.

13. 영감은 사라지기 쉽고 삶은 빠르게 지나간다. 아무것도 하지 않는 것은 교활한 위험이다.

14. 규모는 종종 놀라운 창발적 특성을 가진다. 규모가 커지면 예상치 못한 새로운 특성들이 나타난다.

15. 복리 지수는 마법과 같다. 특히, 당신은 규모와 함께 복리 이점을 얻는 비즈니스를 만들고 싶을 것이다.

16. 다시 일어서서 계속 나아가라.

17. 훌륭한 사람들과 함게 일하는 것은 인생에서 가장 멋진 것 중 하나다.

10/23/2025

제로샷 학습 (Zero-Shot Learning)

본 글은 제로샷 학습(Zero-Shot Learning)의 개념을 이해하고, 실제 예제 코드를 통해 이를 구현하는 방법을 설명합니다. 제로샷 학습이 무엇이고, 왜 중요한지를 Hugging Face를 이용해 얼마나 쉽게 활용할 수 있는지 다루도록 하겠습니다.


제로샷 학습이란 무엇인가?

전통적인 머신러닝 모델을 훈련시키는 방식으로 "암기 과목" 공부와 비슷합니다. 예를 들어 모델에게 "고양이"와 "개" 사진 1000장을 보여주며 "이건 고양이야, 이건 강아지야"라고 정답(Label)을 알려줍니다. 학습이 끝난 모델은 "고양이"와 "강아지"는 잘 구분하지만, 한 번도 본 적 없는 "코끼리" 사진을 주면 혼란에 빠집니다.


제로샷 학습은 이와는 정반대입니다. 이름 그대로, 0(Zero)개의 예시(Shot)만 보고도 문제를 푸는 방식입니다. 예를 들어 모델에게 "고양이"나 "강아지"라는 정답(Label) 자체를 가르친 적이 없습니다. 대신, 모델은 "언어"와 "이미지" 사이의 "관계"와 "개념"을 미리 학습합니다.


마치 우리가 "얼룩말"을 한 번도 본적이 없어도, "말이랑 비슷한데 몸에 검은 줄무늬가 있어"라는 설명만 듣고도 얼룩말을 알아볼 수 있는 것과 같습니다.


위에서 언급한 개념을 더 쉽게 이해하기 위해 "도서관 사서"로 비유해보겠습니다.


전통적인 사서 (훈련 필요)

  • 이 사서는 "역사", "과학" 코너만 압니다.

  • 새롭게 "경제" 책이 들어오면, 이 사서는 이 책을 어디에 둬야 할지 모릅니다. "경제" 코너를 새로 만들고, 어떤 책이 경제 책인지 수백 권의 예시를 보여주며 "다시 훈련(Fine-tuning)" 해야 합니다.


제로샷 사서 (훈련 불필요)

  • 이 사서는 "역사", "과학" 코너를 암기한 것이 아니라, "책의 내용"과 "코너 이름(Label)"의  의미를 모두 이해하고 있습니다.

  • 새로운 "경제" 책이 들어오면, 사서는 이 책을 읽어봅니다.

  • 그리고 우리가 제시한 새로운 코너 이름(Lable)인 "경제"의 의미도 생각해봅니다.

  • 사서는 이 책의 내용은 "경제"라는 단어의 의미와 매우 가깝다고 추론하고 책을 분류합니다.


이제 제로샷 학습에 대해서 이해가 되셨나요?


왜 이 학습법이 혁신적일까?

전통적인 AI 모델 구축의 가장 큰 병목은 "데이터 라벨링" 입니다. 수만, 수십만 개의 데이터에 일일이 정답을 매핑하는 작업은 시간과 비용이 엄청나게 듭니다.


제로샷은 이 문제를 해결합니다.

  • 비용 절감: 데이터 라벨링 비용이 절감됩니다.

  • 유연성: "정치", "사회"로 분류하던 모델을 "IT", "예술"로 분류하고 싶을 때, 모델을 재훈련할 필요 없이 Label 이름만 바꿔주면 됩니다.

  • 신속성: 아이디어가 떠오른 즉시 프로토타입을 만들 수 있습니다.


제로샷 구현 예시

텍스트 분류

가장 기본적인 제로샷 텍스트 분류 예제를 살펴보겠습니다.

먼저 Hugging Face의 transformers 라이브러리를 설치합니다.


!pip install transformers


다음은 텍스트(sequence)와 후보 라벨(candidate_labels)만으로 분류를 수행하는 코드입니다.


from transformers import pipeline


classifier = pipeline("zero-shot-classification", model="MoritzLaurer/mDeBERTa-v3-base-mnli-xnli")

sequence_to_classify = "내일 중요한 축구 경기가 열린다고 한다."

candidate_labels = ["정치", "경제", "스포츠", "IT/기술"]

output = classifier(sequence_to_classify, candidate_labels, multi_label=False)

print(output)


위 코드를 실행하면 아래와 같은 결과가 나오게됩니다.


{'sequence': '내일 중요한 축구 경기가 열린다고 한다.', 

'labels': ['스포츠', 'IT/기술', '정치', '경제'], 

'scores': [0.9846686720848083, 0.008273092098534107,0.0036497144028544426, 0.003408558899536729]}


  • sequence: 원본 텍스트

  • labels: 점수가 높은 순서대로 정렬된 라벨 리스트

  • scores: 각 라벨 대한 신뢰도 점수(0~1)


"축구 경기"라는 텍스트가 "스포츠" 라벨과 가장 관련성(0.98)이 높다고 나옵니다. 위 모델은 정확하게 추론해냈습니다.


만약, 하나의 텍스트가 여러 개의 라벨에 속할 수 있다면, multi_label=True 옵션을 사용합니다.


from transformers import pipeline


classifier = pipeline("zero-shot-classification", model="MoritzLaurer/mDeBERTa-v3-base-mnli-xnli")

sequence_to_classify = "이 레스토랑은 음악은 훌륭하지만, 음식 맛은 평범했다."

candidate_labels = ["음식", "서비스", "음악", "가격"]

output = classifier(sequence_to_classify, candidate_labels, multi_label=True)

print(output)


위 코드를 실행하면 아래의 결과가 나오게됩니다.


{'sequence': '이 레스토랑은 음악은 훌륭하지만, 음식 맛은 평범했다.', 'labels': ['음악', '음식', '서비스', '가격'], 'scores': [0.9990034103393555, 0.9980430006980896, 0.9746165871620178, 0.48950350284576416]}


multi_label=True로 설정하면, 점수(scores)의 총합이 1이 되지 않습니다. 따라서 각 라벨이 독립적으로 "참일 확률"을 계산할 수 있습니다. 위 결과는 "음악"과 "음식" 모두에 관한 내용임을 추론한 것입니다.


이미지 분류

제로샷 개념은 텍스트에만 국한되지 않습니다. "개념"을 이해하는 모델이라면 이미지 분류나 객체 탐지에도 적용할 수 있습니다.

텍스트 분류가 NLI 모델을 기반으로 한다면, 이미지 분류는 CLIP(Contrastive Language Image Pre-training) 모델을 기반으로 합니다.


CLIP 모델은

  • 인터넷에서 수집한(이미지, 이미지 설명 텍스트) 쌍 정보를 엄청나게 많이 학습한 모델입니다.

  • CLIP은 "고양이 사진"과 "고양이라는 텍스트"가 서로 "가까운" 개념임을 압니다.


from transformers import pipeline

from PIL import Image

import requests # URL에서 이미지를 불러오기 위해


# 1. 제로샷 '이미지' 분류 파이프라인 로드

#    CLIP 모델을 명시적으로 지정해줍니다.

image_classifier = pipeline(

    "zero-shot-image-classification", 

    model="openai/clip-vit-large-patch14"

)


# 2. 분류할 이미지 준비 (인터넷에서 고양이 사진 불러오기)

url = "https://images.unsplash.com/photo-1514888286974-6c03e2ca1dba"

image = Image.open(requests.get(url, stream=True).raw)


# 3. 후보 레이블 (텍스트로)

#    모델은 이 텍스트와 이미지의 '유사도'를 계산합니다.

labels = ["a photo of a cat", "a photo of a dog", "a photo of a car"]


# 4. 분류 실행

result = image_classifier(image, candidate_labels=labels)

pprint.pprint(result)


위 코드를 실행하면 아래의 결과가 나옵니다.

[{'score': 0.9979252815246582, 'label': 'a photo of a cat'}, {'score': 0.0012550547253340483, 'label': 'a photo of a dog'}, {'score': 0.0008196595590561628, 'label': 'a photo of a car'}]


모델은 이미지를 보고, 우리가 제시한 라벨 중 "a photo of a cat"이라는 설명과 이미지의 개념이 99.7% 일치한다고 판단했습니다.


객체 분류

이미지 전체를 분류하는 것을 넘어, 이미지 안의 특정 객체들을 텍스트로 찾아내는 것도 가능합니다.

from transformers import pipeline

from PIL import Image

import requests # URL에서 이미지를 불러오기 위해


# 1. 제로샷 '객체 탐지' 파이프라인 로드

object_detector = pipeline(

"zero-shot-object-detection",

model="google/owlvit-large-patch14"

)


# 2. (위와 동일한 고양이 이미지 사용)

url = "https://images.unsplash.com/photo-1514888286974-6c03e2ca1dba"

image = Image.open(requests.get(url, stream=True).raw)


# 3. 찾아내고 싶은 객체들의 이름 (텍스트)

labels_to_find = ["cat nose", "cat eyes", "remote control"]


# 4. 탐지 실행

result = object_detector(image, candidate_labels=labels_to_find)

print(result)


위 코드를 실행하면 아래의 결과나 나옵니다.

[{'score': 0.5476904511451721, 'label': 'cat nose', 'box': {'xmin': 2350, 'ymin': 1570, 'xmax': 2640, 'ymax': 1818}}, 

{'score': 0.3316132128238678, 'label': 'cat eyes', 'box': {'xmin': 2021, 'ymin': 1199, 'xmax': 2931, 'ymax': 1442}}, {'score': 0.31051504611968994, 'label': 'cat eyes', 'box': {'xmin': 2027, 'ymin': 1200, 'xmax': 2940, 'ymax': 1449}}, 

{'score': 0.29117435216903687, 'label': 'cat eyes', 'box': {'xmin': 2680, 'ymin': 1215, 'xmax': 2952, 'ymax': 1438}}, {'score': 0.24599002301692963, 'label': 'cat eyes', 'box': {'xmin': 2046, 'ymin': 1199, 'xmax': 2328, 'ymax': 1417}}, 

{'score': 0.17471081018447876, 'label': 'cat nose', 'box': {'xmin': 2336, 'ymin': 1601, 'xmax': 2644, 'ymax': 1821}}, {'score': 0.14712969958782196, 'label': 'cat eyes', 'box': {'xmin': 2679, 'ymin': 1215, 'xmax': 2953, 'ymax': 1450}}, 

{'score': 0.14246635138988495, 'label': 'cat eyes', 'box': {'xmin': 2018, 'ymin': 1200, 'xmax': 2332, 'ymax': 1435}}, {'score': 0.14067652821540833, 'label': 'cat eyes', 'box': {'xmin': 1985, 'ymin': 1186, 'xmax': 2983, 'ymax': 1478}}, 

{'score': 0.13866569101810455, 'label': 'cat eyes', 'box': {'xmin': 1765, 'ymin': 1098, 'xmax': 3168, 'ymax': 1572}}]

 

결론

이제까지 제로샷에 대해서 알아보았고, 장점과 한계에 대해서 다시 한번 살펴보겠습니다.


제로샷의 장점

  • 데이터가 필요 없음

  • 유연성: 비즈니스 요구사항이 변경되어 분류 카테고리를 늘려야 할 때, 재훈련없이 candidate_labels만 수정하면 됩니다.

  • 프로토타이핑: "이런 분류가 어떨까?" 라는 아이디어를 검증하기 위해 간단히 테스트할 수 있습니다.


제로샷의 한계

  • 정확도: 모든 것을 적당히 알지만, 한 분야의 "전문가" 보다는 못합니다. 만약 "고객 리뷰"에 대해 "긍정/부정"으로 분류하는 단 하나의 작업만 수행해야 한다면, 해당 작업에 특화된 데이터로 "파인 튜닝"한 모델이 제로샷 모델보다 좋습니다.

  • 모호성: NLI 기반 모델은 라벨의 "단어 의미"에 크게 의존합니다. "IT, 기술" 처럼 의미가 비슷한 라벨이 함께 있으면 모델이 혼동합니다. 따라서 복잡한 분류는 어려울 수 있습니다.

  • 속도 및 크기: 제로샷을 수행하는 NLI 모델이나 CLIP 모델은 크기가 매우 큽니다. 특화 모델보다 추론 속도가 느릴 수 있습니다.


제로샷 학습은 "모든 것을 대체하는" 만병 통치약은 아닙니다. 하지만 AI 개발의 패러다임을 바꾸는 강력한 도구이기에 아래의 상황에서 사용 하시기를 추천 드립니다.

  • 초기 탐색 및 프로토타이핑: 어떤 종류의 데이터가 유입되는지, 어떤 분류가 의미 있을지 빠르게 탐색할 때 활용

  • 데이터가 절대적으로 부족할 때: 라벨링된 데이터가 아예 없을 때 유일한 선택지

  • 동적인 분류가 필요할 때: 분류 카테고리가 매일같이 바뀌는 환경일 때 (e.g. 실시간 뉴스 토픽 분류)


여기서 사용된 코드는
https://github.com/monocleface/huggingface-tutorials/blob/main/natural-language-processing/sample_zeroshot_classification.ipynb 에서 보시면 됩니다.