RAG is dead, long live RAG?! - 2024, 2025, 2026 RAG 트렌드 연대기

LLM Basic to Advanced

목록 보기

10/10

[ 글의 목적: 26년 8월 기준, 2024 → 2025 → 2026 RAG 트렌드를 연대기로 정리. 논문 발행일·제품 출시일·사례 참조. 요약 + 사견 ]

RAG is dead, long live RAG?! - 2024, 2025, 2026 RAG 트렌드 연대기

2026년 8월 지금, 3대 클라우드의 최신 발표문에서 "RAG"라는 단어가 헤드라인에서 사라지고 있습니다. Microsoft는 Foundry IQ를 "에이전트를 위한 통합 지식 레이어"라고 부르고, Google의 올해 4월 Gemini Enterprise 업데이트는 BYO-MCP와 Deep Research 에이전트 얘기가 중심이고요. OpenAI는 그냥 Company Knowledge라고 부릅니다. 벡터 DB에 청크 넣던 그 RAG는 어디로 갔을까요? 죽었다는 소문이 어디까지 사실인지 궁금해서 지난 3년을 다시 훑었습니다.

Intro to Large Language Models 번역글에서 "그렇게 24년도는 전 세계가 '야 너두 RAG 할 수 있어!' 를 외치게 되었다"고 쓴 적이 있습니다. 그리고 2년이 지났습니다. 그 사이에 "야 너두"의 정체였던 벡터 DB에 청크 넣고 top-k 뽑기는 학계에서 한 번, 클라우드 3사에서 한 번, 표준화 단체에서 한 번, 총 세 번 해체됐습니다.

이 글은 그 해체의 연대기입니다. RAG 자체를 설명하는 일은 LLM 엔지니어링 책 리뷰의 RAG 파이프라인 섹션으로 대체합니다. (청킹, 임베딩, 벡터 DB, 하이브리드 검색 같은 기본 내용이 있습니다!)

3막 구조 한눈에 보기: 논문 - 제품 - 지식 레이어와 표준

1. 2023~2024: RAG의 '질문'을 바꾸다

2023년까지 RAG의 질문은 "무엇을 검색할까"였습니다. 더 좋은 임베딩, 더 좋은 청킹, 더 좋은 벡터 DB. 그런데 2023년 말부터 나온 논문 4편이 질문 자체를 바꿔버립니다. "검색을 언제 할 것인가, 그리고 검색 결과를 얼마나 믿을 것인가!"

naive RAG의 실패 모드 4개와 그걸 겨냥한 논문 4편

*naive RAG는 기본적이고 단순한 형태의 검색 증강 생성(RAG) 방식입니다. 문서 나누기(Indexing), 관련 문서 찾기(Retrieval), 답변 만들기(Generation)의 3단계를 말합니다.

1) Self-RAG - 검색이 항상 필요한가? (2023.10)

Self-RAG는 2023년 10월 17일 arXiv에 올라왔고 이후 ICLR 2024 oral로 채택됐습니다. 핵심은 reflection token이라는 특수 토큰입니다. 모델이 생성 중에 "지금 검색이 필요한가?"(retrieval 토큰), "검색된 문서가 관련 있나? 내 답변이 근거에 붙어 있나?"(critique 토큰)를 스스로 판단하도록 학습시킵니다.

Retrieve: "검색이 필요한가?" (yes / no / continue)
ISREL: "검색 문서가 실제로 관련 있는가?" (relevant / irrelevant)
ISSUP: "출력이 해당 문서로 충분히 뒷받침되는가?" (fully / partially / no support)
ISUSE: "전체적으로 출력이 유용한가?" (1~5점 척도)

문제의식이 뼈아픕니다. 기존 RAG는 질문이 검색을 필요로 하든 말든, 고정 개수의 문서를 무조건 프롬프트에 밀어 넣습니다. 저자들 표현으로는 이게 LM의 범용성(versatility)을 해친다는 거죠. "오늘 날씨 어때?"에도 사내 위키 5개 청크를 붙여주는 파이프라인, 다들 한 번쯤 만들어보셨을 겁니다. ~~제가 만들었다는 뜻입니다.~~

2) CRAG - 검색 결과가 쓰레기면 어떡하지? (2024.01)

CRAG(Corrective RAG)는 2024년 1월 29일 공개됐습니다. 경량 retrieval evaluator를 하나 두고 검색 결과의 품질을 Correct / Incorrect / Ambiguous 세 갈래로 판정합니다. 판정에 따라 교정 액션이 달라집니다. Incorrect나 Ambiguous면 웹 검색으로 확장하고, decompose-then-recompose 알고리즘으로 문서에서 핵심만 다시 추립니다.

여기서 중요한 디테일 하나. 웹 검색은 evaluator 판정에 따른 조건부 트리거입니다. 매번 도는 게 아니고요.

PS. Meta가 나중에 낸 동명의 벤치마크 논문(CRAG: Comprehensive RAG Benchmark, arXiv:2406.04744)과는 완전히 별개의 논문임 주의.

3) RAPTOR - 긴 문서는 어떡하지? (2024.01)

RAPTOR는 2024년 1월 31일 공개된 ICLR 2024 논문으로, 청크를 재귀적으로 임베딩·클러스터링·요약해서 상향식 요약 트리를 만듭니다. SBERT로 임베딩하고 UMAP으로 차원을 줄인 다음 GMM soft clustering으로 묶습니다. 그렇게 묶인 걸 gpt-3.5-turbo로 요약하고(경량 모델을 사용한다 쯤으로 받아들이면 됩니다.), 그 요약을 다시 임베딩해서 위층을 쌓는 구조입니다.

# RAPTOR의 아이디어를 아주 거칠게 요약하면:

# 0층: 원본 청크들
"[청크1] [청크2] [청크3] [청크4] [청크5] [청크6]"

# 1층: 비슷한 청크끼리 묶어서 요약
"[요약A(1,2)] [요약B(3,4,5)] [요약C(6)]"

# 2층: 요약을 또 요약
"[최상위 요약(A,B,C)]"

# 검색할 때는 모든 층을 대상으로 -> "디테일 질문은 아래층, 전체 맥락 질문은 위층"이 걸린다

RAPTOR의 상향식 요약 트리 구조

저자들은 GPT-4와 결합했을 때 QuALITY 벤치마크에서 기존 최고 성능 대비 절대 정확도 20%p 향상을 보고합니다. 짧은 연속 청크만 뽑아서는 "이 책 전체의 주제가 뭐야?" 같은 질문에 답할 수 없다는 문제를 정면으로 겨냥했습니다.

4) GraphRAG - 코퍼스 전체를 묻는 질문은? (2024.04)

Microsoft Research의 GraphRAG 논문은 2024년 4월 24일 공개됐습니다. "이 데이터셋의 주요 테마는?" 같은 전역 질문에 벡터 RAG가 구조적으로 실패한다는 관찰에서 출발해서 이 문제를 아예 쿼리 중심 요약(Query-Focused Summarization) 문제로 재정의합니다. 인덱스는 2단계입니다. LLM으로 엔티티 지식 그래프를 뽑고, 밀접하게 연결된 엔티티 그룹(커뮤니티)마다 요약을 미리 생성해둡니다.

개괄적인 흐름은 위 이미지와 같습니다. 사실 위는 다른 RAG랑 차이가 없습니다. 사견으로 GraphRAG의 코어는 결국 "그래프"인데 핵심은 아래 사진처럼 "그 계층과 깊이"라고 봅니다. ~~할말이 너무 많지만, 글의 본래 목적과 상이하기에 이만..~~

다만 GraphRAG의 성능 입증은 LLM-as-judge 기반의 comprehensiveness/diversity 지표에 한정됩니다. 후속 연구에서 평가 편향과 표준 벤치마크에서의 혼재된 결과를 지적하기도 했습니다. "전역 질문을 해결했다"보다는 "해결을 제안하고 입증을 시도했다"가 정확한 서술입니다.

5) 그래서 1막의 결론

4개 논문을 한 줄씩으로 압축하면 이렇게 됩니다.

Self-RAG: 검색이 항상 필요한 건 아니다.
CRAG: 검색 결과를 믿으면 안 된다.
RAPTOR: 청크 여러 개 붙인다고 문서가 되진 않는다.
GraphRAG: top-k로는 전체를 볼 수 없다.

전부 naive RAG의 실패 모드 하나씩을 겨냥한 논문들입니다. 2024년에 이미 "벡터 DB에 청크 넣기"의 부고(?)를 나눠 쓰고 있었던 거죠.

사견으로, 이 시기 논문들의 진짜 기여는 개별 기법보다 "검색을 판단의 대상으로 만들었다"는 관점 전환이라고 생각합니다. 검색이 파이프라인의 고정 단계가 아니라 매번 품질을 평가받고 스킵될 수도 있는 "의사결정"이 된 순간, 뒤에 나올 agentic retrieval은 사실 예고된 수순이었습니다.

2. 2024 말~2025: 클라우드 3사가 RAG를 "제품"으로 흡수하다

논문이 질문을 바꾸는 동안, 클라우드 3사는 RAG를 관리형 서비스로 흡수했습니다. 이 시기의 키워드는 "재랭킹과 평가가 옵션이 아니라 기본값이 됐다" 입니다.

1) 타임라인부터

2막 타임라인: 2024.11 MCP 공개부터 2025.05 LlamaIndex 부고까지

날짜	사건
2024-11-25	Anthropic이 MCP(Model Context Protocol)를 최초 공개
2024-12-20	Vertex AI RAG Engine 실제 GA (공식 릴리스 노트 기준)
2025-01-10	Google 블로그의 RAG Engine GA "발표"
2025-03-11	OpenAI Responses API 출시, file search 빌트인 편입
2025-05-29	LlamaIndex "RAG is dead, long live agentic retrieval"

PS. Vertex AI RAG Engine의 GA를 검색하면 대부분 "2025년 1월"이 나옵니다. 실제 GA는 2024년 12월 20일이고 릴리스 노트에 그렇게 적혀 있습니다. (2025-01-10은 이미 GA된 제품의 홍보 블로그가 올라온 날)

2) OpenAI - file search의 재포장

2025년 3월 11일 OpenAI는 Responses API를 출시하면서 web search, file search, computer use를 빌트인 도구로 넣었습니다. file search에는 메타데이터 필터링과 재랭킹(ranking_options)이 기본 내장입니다. 따로따로 붙이던 도구들이 API 하나로 묶인 셈이고요.

PS. 두 가지는 짚고 넘어가야 합니다!
첫째, file_search 자체는 2024년 Assistants API v2에 이미 있었습니다. 2025-03에 일어난 일은 Responses API 편입입니다. 둘째, 공식 문서의 "custom reranking"이라는 표현은 ranker 선택과 score threshold 튜닝 수준입니다. 임의의 재랭커 모델을 꽂는 기능까지는 아니고요. ~~벤더 표현은 원래 좀 넉넉하게 부풀려져 있으니 걸러 읽는 습관이..~~

3) 실전 배포는 어떻게 생겼나 - 보험사와 투자은행 예시

이 시기 실무 레퍼런스로 자주 인용되는 사례 둘을 원문 기준으로 보겠습니다. 두 사례 모두 벤더(Google, OpenAI)가 게시한 케이스 스터디라 독립 감사 수치는 아니라는 점을 먼저 깔아두고요.

독일 보험사 SIGNAL IDUNA는 Gemini 1.5 Pro + Cloud SQL pgvector + Vertex AI Ranking API + Gen AI Evaluation Service 조합으로 고객지원 어시스턴트를 만들었습니다. 보험 요율 600개 이상을 다룬 내부 문서 2,000개 이상을 근거로 물렸습니다. 평균 응답 시간은 약 6초. 결과는 핵심 처리시간 약 30% 단축, 케이스 종결률 73% → "almost 98%"입니다.

스택 구성을 다시 보자면, 벡터 저장소 + 재랭킹 API + 평가 서비스. 2025년의 "제품화된 RAG"가 어떤 모양인지 이 한 줄이 다 보여줍니다.

Morgan Stanley는 wealth management 부문 어드바이저 팀의 98% 이상이 내부 지식검색 어시스턴트를 쓰고, 문서 접근률이 20%에서 80%로 뛰었다고 밝혔습니다. 답변 가능 질문 7,000개 수준에서 시작해 10만 개 문서 코퍼스로 확장됐다는데 제가 이 케이스에서 제일 좋아하는 건 따로 있습니다.

배포 전 모든 유스케이스를 eval 프레임워크로 검증하고 샘플 질문 회귀 테스트를 매일 돌렸다는 것. 98%라는 채택률을 만든 건 모델이 잘나서가 아니라 평가 체계가 쌓은 신뢰입니다.

숫자로 보는 2025년의 배포 현장: Morgan Stanley와 SIGNAL IDUNA 수치 카드

한편 반대 증거도 있습니다. 법률 AI 스타트업 Harvey는 fine-tuning과 RAG를 먼저 시도했다가 판례법 리서치에는 불충분하다는 결론을 내리고 OpenAI와 함께 미국 판례법 100억 토큰 상당을 추가한 커스텀 모델을 만들었습니다. 대형 로펌 10곳의 변호사 대상 블라인드 비교에서 97%가 커스텀 모델 출력을 GPT-4보다 선호했습니다.

이 97%는 선호도 지표입니다. 사용률도 정확도도 아니에요. 이 사례가 말해주는 건 "RAG면 다 된다"가 아니라 도메인이 깊으면 검색 증강만으로는 안 되는 지점이 있다는 겁니다.

4) "long context가 RAG를 죽인다"?

이 시기 내내 "컨텍스트 윈도우가 100만 토큰이 되면 RAG는 필요 없어진다"는 얘기가 많았습니다. 2025년 2월에 나온 LaRA 벤치마크의 부제가 이 논쟁의 결론을 스포일러합니다: "No Silver Bullet for LC or RAG Routing". *(LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs)

2,326개 테스트 케이스로 11개 LLM을 평가해 보니 RAG와 long context 중 어느 쪽이 나은지는 모델 크기, 장문 처리 능력, 컨텍스트 길이, 태스크 유형, 청크 특성의 복합 함수였습니다.

결론은 "대체"가 아니라 "라우팅"입니다. 필요한 건 언제 어느 쪽을 태울지 판단하는 계층이고요. 어디서 많이 듣던 결론 아닌가요? 네, 사실 1막에서 Self-RAG가 하던 바로 그 얘기입니다.

RAG vs Long Context: 대체가 아니라 라우팅

5) 2막의 커튼콜 - 벤더가 직접 쓴 부고

그리고 이 시기의 마지막 장면은 LlamaIndex가 2025년 5월 공식 블로그에 올린 글의 제목이 "RAG is dead, long live agentic retrieval"입니다. 프레임워크 벤더가 자기 밥줄이었던 단어의 부고를 직접 쓴 셈인데 재밌는 건 부고의 결론이 "그래서 검색은 더 중요해졌다"라는 점입니다.

naive chunk 검색을 넘어선 agentic retrieval이 이제 table stakes(기본값)라는 선언 — 물론 벤더의 선언이니 감안해서 들어야겠지만 바로 다음에 벌어진 일을 보면 틀린 말은 아니었고요.

3. 2025 말~2026: 지식 레이어와 표준의 시대

그리고 2025년 하반기부터, RAG라는 단어가 제품 발표문에서 슬슬 사라지기 시작합니다. 대신 등장한 단어가 knowledge layer입니다. *(저는 이걸 아직까지 지식도서관이라고 부르고 있습니다.)

"RAG는 파이프라인의 이름에서, 권한을 아는 지식 계층의 구현 디테일로 강등되는 중입니다 (하나의 기술 이름 처럼)"

1) 타임라인

3막 타임라인: 2025.10 Company Knowledge부터 2026.04 Gemini Enterprise까지

날짜	사건
2025-10-23	OpenAI Company Knowledge 발표 - 권한 인식 + 출처 인용 강제
2025-11-18	Azure Foundry IQ 공개 프리뷰 - "unified knowledge layer"
2025-11-19	Company Knowledge에 커스텀 MCP 커넥터(search/fetch) 지원
2025-12-09	Anthropic, MCP를 Linux Foundation 산하 AAIF에 기부
2026-04-23	Gemini Enterprise 업데이트 - BYO-MCP, Deep Research 에이전트

2) 세 벤더의 공통분모

OpenAI의 Company Knowledge는 Slack, SharePoint, Google Drive, GitHub, Notion 등 연결된 사내 도구를 통합하고 답변에 출처 인용과 원본 링크를 붙입니다. 그리고 기존 사내 권한 체계를 그대로 존중합니다. 사용자가 원래 볼 수 있는 문서만 검색되고 커넥터별 RBAC(Role-Based Access Control)를 따릅니다.

Microsoft의 Foundry IQ는 Azure AI Search 위에 올라간 "에이전트를 위한 통합 지식 레이어"로, 2025년 11월 18일 공개 프리뷰로 나왔습니다. (일부분 GA, 일부분 프리뷰) 재사용 가능한 knowledge base 하나를 단일 API로 여러 에이전트에 물릴 수 있습니다. 내부에는 agentic retrieval 엔진이 있어서 쿼리 계획·분해·반복 검색·자기평가를 수행하고, "retrieval reasoning effort"라는 다이얼로 검색에 쓸 추론 강도를 조절합니다. Entra ID 권한을 존중하고, SharePoint 소스에서는 Purview 민감도 레이블이 인덱싱·검색 파이프라인 전체에서 유지됩니다.

Google의 Gemini Enterprise는 2026년 4월 업데이트에서 BYO-MCP(Bring Your Own MCP)를 도입하고 Google Workspace든 Microsoft 365든 데이터 소스의 네이티브 권한을 그대로 존중한다고 명시했습니다. Deep Research 에이전트도 같이 나왔고요. 오픈 웹과 사내 데이터를 몇 시간씩 자율적으로 종합해서 인용 달린 보고서를 만들어 주는 에이전트입니다.

이 전환이 얼마나 빠른지는 2막에 나왔던 SIGNAL IDUNA만 따라가 봐도 알 수 있어요. 이 회사는 3월에 RAG 어시스턴트 케이스 스터디의 주인공이었습니다. 같은 해 10월 Gemini Enterprise를 10,000명 이상의 직원·영업 파트너에게 전사 롤아웃합니다. 반년 만입니다. 도입 동기가 흥미로운데, 향후 10년간 직원의 약 30%가 주로 은퇴로 회사를 떠날 예정이라 그들의 지식을 보존해야 한다는 것. 엔터프라이즈가 RAG를 도입하는 이유가 여기 있는 거죠.

세 벤더 발표문을 나란히 놓으면 공통분모가 정확히 세 개 나옵니다.

3사 지식 레이어의 공통분모: 권한 인식, 출처 인용 강제, MCP 연결

# 2026년형 "지식 레이어"의 3대 공통 요소

knowledge_layer = {
    "permission_aware": "사용자가 원래 볼 수 있는 것만 검색된다",   # 전원 공통
    "citation_enforced": "모든 답변에 출처가 강제된다",           # 전원 공통
    "mcp_connected": "데이터 소스 연결은 MCP를 기본 제공한다",      # 전원 공통
}
# "벡터 검색"은? -> 구현 디테일로 내려감. 발표문 헤드라인에서 사라짐.

PS. 다만 모든 벤더가 아직 자사 platform에 어떻게든 귀속시키려는 움직임이 좀 더 강합니다. 사실 탈중앙화는 내가 중앙화할래의 다른 말일지도... 개인적으로 가장 아쉬운 게 이 부분...

3) MCP - 검색이 "표준 인터페이스"가 되다!

MCP 얘기를 안 할 수가 없습니다. 2024년 11월 25일 Anthropic이 공개한 MCP는, 1년여 뒤인 2025년 12월 9일 Linux Foundation 산하 Agentic AI Foundation에 기부됐습니다. AAIF는 Anthropic, Block, OpenAI가 공동 설립했고 Google, Microsoft, AWS, Cloudflare, Bloomberg가 지원합니다. 발표 시점 기준 활성 공개 MCP 서버 1만 개 이상, SDK 월 9,700만 다운로드(Python+TypeScript 합산)라고 하니 경쟁사 전원이 한 표준 아래 모인 드문 그림입니다.

이에 대한 좀 더 depth 있는 얘기는 AI 에이전트는 왜 서로 통신해야 할까? A2A의 모든 것로 대체하겠습니다. (요즘IT에도 기고하고 있어요!)

RAG 관점에서 MCP가 중요한 이유는 이겁니다. 지금까지 RAG는 "중앙 인덱스를 만들고 그 위에 파이프라인을 쌓는 것"이었습니다. MCP에서는 검색 가능한 지식 소스를 표준 인터페이스로 노출하면 됩니다. 상징적인 장면은 OpenAI가 Company Knowledge에 커스텀 MCP 커넥터를 받기 시작한 겁니다(2025-11-19). search/fetch 기능을 갖춘 커넥터고요. (OpenAI, MCP 지원하는 ChatGPT 개발자 모드 공개 참조)

PS. MCP는 연결 표준이지 검색 품질 표준이 아닙니다. 검색이 구리면 MCP로 연결해도 구립니다. ~~케이블 좋다고 화질이 좋아지진 않죠.~~

4. 마치며

1) 위에서 다룬 연대기를 요약해보면

첫째, 시작은 여전히 hybrid + rerank + citation + evals입니다. SIGNAL IDUNA의 스택이 정확히 이 구성이고 Morgan Stanley의 채택률을 만든 것도 eval 체계였습니다. 처음부터 GraphRAG나 agentic 루프로 시작할 이유가 없습니다. 실패 사례가 쌓이면 그때 원인별로 — 검색 누락인지, 조합/추론 실패인지, 권한/정책 문제인지 — 분리해서 레버를 추가하면 됩니다.

둘째, 검색 실패의 절반은 검색기 밖에 있습니다. Self-RAG/CRAG/LaRA가 공통으로 말하는 건 "언제 검색할지, 검색을 믿을지, 어느 경로를 태울지"의 판단 계층입니다. 2026년의 지식 레이어 제품들은 그 판단 계층에 권한과 인용을 얹었습니다.

작년 할루시네이션 논문 리뷰에서 이렇게 썼습니다.

사견으로, 이론상 RAG가 할루시네이션을 더 줄이려면 Vector 보다는 "유사한게 아니라 명확하고 확실하게 검색되는 것" 이 더 도움을 줄 수 있다.

1년이 지났습니다. 하이브리드 검색은 관리형 제품의 기본값이 됐고, 날짜·권한·출처는 임베딩 대신 메타데이터 필터로 처리하는 게 상식이 됐습니다. 모든 걸 벡터에 담아 "어떻게든 증강하겠지~"라는 기도메타는 이제 공식적으로 안 통하는 시대입니다. ~~1년 전엔 사견이었는데 지금은 벤더 공식 문서가 대신 말해줍니다.~~

죽은 건 RAG가 아니라 단순하게 "벡터 DB에 청크 넣고 top-k"라는 공식이었습니다. 검색으로 근거를 대는 일은 오히려 판이 커졌고요.

2) 벤더들의 Agentic retrieval

벤더들은 전부 agentic retrieval을 서버 안에 넣고 있습니다. Foundry IQ의 "retrieval reasoning effort" 다이얼이 대표적이죠. 서버가 쿼리를 계획합니다. 분해하고 반복 검색하고, 자기평가까지 서버 몫이에요.

그런데 MCP 생태계를 보면 정반대 방향도 보입니다. 서버는 search/fetch 두 개만 잘 노출하고 계획·분해·반복은 클라이언트 쪽 에이전트(Claude Code, Cursor 같은)가 하는 구조. agentic의 위치가 서버냐 클라이언트냐 — 사견으로, 2026년 RAG 아키텍처에서 제일 재밌는 갈림길이 여기라고 생각합니다.

서버형 agentic vs 클라이언트형 agentic 구조 비교

사실 이 갈림길에서 후자를 택한 물건을 하나 만들고 있습니다.

사내에 흩어진 Notion·Slack·Discord 등 지식을 출처 인용이 강제된 위키로 정제하고, Slack/Discord에서 딸깍 한 번으로 물어볼 수 있는 지식 도서관 에이전트입니다.

만들다 보니 트렌드 글에는 안 나오는 밑바닥 얘기가 꽤 쌓였습니다. 한국어 조사 때문에 FTS 검색이 통째로 빗나가는 장애("XXX가"로 검색하면 색인 토큰 "XXX"를 못 찾습니다), 임베딩이 "2026-01"과 "2026-07"을 구분 못 해서 날짜를 메타데이터로 빼야 했던 결정 같은 것들이요.

저는 Agent들의 Ecosystem에 특이점은 꼭 온다고 생각합니다. 각 빅테크, 벤더들은 탈중앙화를 얘기하지만 결국 본인이 대신해서 중앙화가 되려고 하구요. 25년말 26년초 곧 모두가 개개인의 Agent를 최소한 하나는 가지게 된다고 얘기가 나왔죠. 지금 IT쪽에서 claude(code)나 gpt(codex)를 아예 안 쓰는 사람이 있을까요? 나아가 이미 휴대폰에도 내장되고, 사내 On-premise LLM 역시 매우 많이 퍼졌습니다. 사실 이미 모두 최소 1개 Agent를 웹이든 앱이든 하드웨어를 통해서든 사용하고 있습니다.