HowtoAI
ai-guide2026-05-22 5 min read

Adaptive RAG 쿼리 라우터 7단계 — 단순·복잡 분기로 비용 40% 절감 2026년 가이드

🤖
HowtoAI 편집팀AI 전문 에디터

AI 기술을 누구나 쉽게 활용할 수 있도록 실전 가이드를 작성합니다. ChatGPT, Claude, AI 자동화, SEO 분야를 전문으로 다룹니다.

📅 2026-05-22⏱️ 5 min read🌐 how-toai.com
목차 보기

Adaptive RAG — 2026년 RAG 운영의 신규 정석

2026년 RAG 운영 best practice가 단일 Hybrid 파이프라인에서 Adaptive RAG로 빠르게 이동하고 있어요. 핵심은 모든 쿼리에 풀 파이프라인을 돌리지 않는 거. 쿼리 분류기를 앞에 박아서 복잡도를 3티어로 분류한 다음 티어별 다른 파이프라인을 라우팅. 단순 쿼리는 캐시·벡터 단일 검색만, 복잡은 Agentic RAG·Graph RAG까지 활성화.

핵심 변화 3가지. (1) 비용 절감 — 단순 쿼리에서 reranker·다중 LLM 호출이 빠지면서 호출당 평균 비용이 내려가요. (2) 응답 시간 단축 — 캐시 hit이나 단일 검색으로 끝나는 쿼리 비중이 늘어 평균 응답이 빨라져요. (3) 정확도 유지 — 단일 풀 파이프라인과 동등. 단순 쿼리에 복잡 파이프라인을 안 쓰니 자원을 정말 필요한 복잡 쿼리에 집중하는 구조예요. 절감 폭은 쿼리 분포와 캐시 적중률에 좌우되니 도입 전후를 같은 기준으로 측정해서 비교하는 게 중요해요.

이번 글은 분류기 설계부터 티어별 파이프라인·캐시 전략·모니터링까지 7단계로 정리해요. LangGraph·LlamaIndex 같은 프레임워크에서 자주 쓰이는 패턴도 함께 담았어요.

데이터 파이프라인 흐름 — Adaptive RAG의 본질은 쿼리 분류기가 단순·중간·복잡 3티어를 자동 라우팅해서 자원을 정말 필요한 곳에 집중하는 구조 시각화

1단계 — 쿼리 분류기 옵션 3가지(LLM·임베딩·규칙)

가장 먼저 결정할 게 분류기 구현 방식. 3가지 옵션이 있는데 운영 단계별로 진화하는 게 정답.

(1) LLM 분류기(MVP 단계 권장) — 각 제공사의 저렴한 경량 모델에 분류 프롬프트. 호출 비용이 매우 낮고 응답도 빨라요. 구현은 하루면 끝나고 학습 데이터도 필요 없어요(zero-shot). 한국 1인·소규모 팀이 가장 빠르게 시작 가능. (2) 임베딩 + 분류 헤드(중기 단계) — 쿼리 임베딩 → MLP 분류 헤드 학습. 본인 데이터 1,000건+ 라벨 필요. 호출당 비용은 거의 0이고 응답도 가장 빨라요. 라벨 데이터가 쌓일수록 정확도가 LLM 분류기를 넘어서요. 운영 3개월+ 데이터 모인 후 전환. (3) 규칙 기반(MVP 임시 또는 보조) — 길이·키워드·문장 수 같은 휴리스틱. 비용은 0이지만 정확도가 낮아 다른 분류기의 fallback 보조용으로 적합해요.

본인 진화 패턴 — (a) 운영 첫 1개월: LLM 분류기 + 사용자 피드백 로깅, (b) 1~3개월: 라벨 데이터 1,000건+ 모이면 임베딩 분류기 학습, (c) 3개월+: 임베딩 분류기 + LLM 분류기 fallback(confidence 낮을 때만 LLM 호출). 단계별 진화가 비용·정확도 둘 다 최적화하는 본전 흐름이에요.

2단계 — 단순·중간·복잡 티어 정의(도메인별 비중)

분류 기준 명확히 설계. 일반적 기준 + 본인 도메인 특성 반영 필수.

(1) 단순(Tier 1) — 사실 검색·단일 문서 답변·캐시 가능. 패턴: 짧은 의문문(평균 10~15자), 명사 중심, 키워드 검색 충분. 예시: "5월 매출 보고서 어디?", "회의실 예약 정책?", "휴가 신청 절차?". 도메인별 비중: 사내 지식 검색 50%, 고객 CS 60%, 기술 문서 35%. (2) 중간(Tier 2) — 다중 문서 합성·간단 비교·요약. 패턴: 중간 길이 문장(15~30자), 동사·부사 다수, "비교", "정리", "차이" 같은 키워드. 예시: "경쟁사 A·B 가격 정책 차이", "지난 3개월 매출 트렌드 요약". 도메인별 비중: 사내 35%, CS 30%, 기술 45%. (3) 복잡(Tier 3) — 다단계 추론·교차 참조·계산. 패턴: 긴 문장(30자+), 복합 조건, "통합", "분석", "예측" 키워드. 예시: "Q1 매출 + 마케팅 비용 + 채널 ROI 통합 분석 + Q2 전망". 도메인별 비중: 사내 15%, CS 10%, 기술 20%.

본인 측정 시작 — 첫 1주 모든 쿼리를 단순 Hybrid 파이프라인으로 처리하면서 동시에 분류 로깅. 1주 후 도메인별 실제 비중 측정 → 티어 기준 조정. 본인 데이터 기반이 정답이에요.

3단계 — 티어별 파이프라인 설계

3티어 각각에 다른 파이프라인 배치. 단순할수록 빠르고 저렴하게, 복잡할수록 풍부한 도구 활성화.

(1) 단순 파이프라인 — L1 캐시 → 미스면 L2 캐시(의미 유사) → 미스면 벡터 단일 검색(top 3) → LLM 답변(경량 모델로 충분). 응답이 가장 빠르고 비용도 가장 낮아요. (2) 중간 파이프라인 — Hybrid RAG(BM25 + 벡터 병행 검색 + RRF 결합) → reranker → LLM 답변(중급 모델). 호출이 늘어난 만큼 단순 티어보다 무거워요. (3) 복잡 파이프라인 — Agentic RAG. 에이전트가 plan → retrieve → validate → re-query → reflect 루프. 필요시 Graph RAG로 다중 hop 추론. LLM은 각 제공사의 최상위 모델. 응답 시간과 비용 모두 가장 큽니다.

LLM 모델 매핑이 비용 절감의 또 하나 핵심. 단순 쿼리에 최상위 모델을 부르면 낭비예요. 티어별로 (단순 → 경량 모델) → (중간 → 중급 모델) → (복잡 → 최상위 모델) 매핑이 본전 패턴이에요.

4단계 — 3층 캐시 전략(L1·L2·L3)

캐시는 Adaptive RAG의 비용 절감 효과를 가장 크게 만드는 컴포넌트. hit 한 건마다 LLM 호출이 통째로 사라지니까, 반복 질문이 많은 서비스일수록 효과가 커요.

(1) L1 — 정확 매칭 캐시 — 쿼리 텍스트 정규화(소문자·공백 정리) 후 해시 키. Redis·Cloudflare KV·Vercel KV 사용. 응답이 사실상 즉시. TTL 1시간. 자주 묻는 동일 질문(FAQ) 흡수. 세 층 중 구현이 가장 쉬워 먼저 넣기 좋아요. (2) L2 — 의미 유사 캐시 — 쿼리 임베딩 + 코사인 유사도 0.95+ 매칭. Pinecone·Qdrant·pgvector 사용. TTL 1시간. 같은 의도 다른 표현(예: "매출 보고서" vs "매출 리포트") 흡수. L1이 놓치는 표현 차이를 메워요. (3) L3 — 검색 결과 캐시 — 검색된 top 문서만 캐시, LLM 답변 생성은 매번 새로. TTL 24시간. 컨텍스트는 같지만 답변 톤·길이 변형 가능.

Stale 답변 방지 — (a) TTL 짧게(L1·L2는 1시간), (b) 문서 업데이트 시 관련 캐시 자동 무효화 webhook, (c) 사용자 피드백(나쁜 답변 표시) 시 즉시 무효화. 본인 운영에 stale 답변 사고 0건 달성 가능한 패턴이에요.

분석 대시보드 화면 — Adaptive RAG 운영의 본질은 티어별 분포·비용·응답 시간·캐시 hit률 5개 지표를 매일 모니터링하는 운영 사이클 시각화

5단계 — 분류 confidence threshold + fallback

분류기 오판 대응. confidence 낮은 쿼리는 안전한 쪽으로 fallback.

(1) Confidence threshold 0.7 — 분류기가 단순으로 분류했는데 confidence 0.7 미만이면 중간 티어로 fallback. 비용 약간 더 들지만 정확도 보호. 복잡으로 분류했는데 confidence 0.7 미만이면 중간 fallback도 같은 논리. (2) 티어 간 안전 거리 — 단순 → 중간 fallback은 OK, 복잡 → 단순 fallback은 위험(누락 답변). 단방향 fallback 규칙 적용. (3) 분류 confidence 추세 모니터링 — 시간 따라 분류 confidence 평균이 떨어지면 분류기 학습 부족·도메인 변화 신호. 재학습 트리거.

운영 초기에는 분류 confidence 평균이 낮게 시작하는 게 정상이에요. 사용자 피드백 데이터가 쌓이고 임베딩 분류기를 재학습하는 시점에 눈에 띄게 올라가요. confidence 추세 자체가 분류기 품질을 보는 정량 지표라, 절대값보다 방향을 보는 게 중요해요.

6단계 — A/B 테스트 + 사용자 피드백 루프

분류 오판 자동 감지 + 분류기 학습 데이터 자동 수집.

(1) A/B 테스트 — 트래픽 1%에 동시에 (a) 분류기 결정 파이프라인, (b) 풀 파이프라인(모든 쿼리 복잡 처리) 둘 다 실행. 두 결과를 사용자에게 보여주지 말고 백엔드 로깅. 두 결과 차이가 큰 쿼리 = 분류 오판 가능성 → 라벨링 큐에 자동 추가. (2) 사용자 피드백 버튼 — 답변에 좋아요·싫어요 버튼. 싫어요 비율 5% 넘는 쿼리 패턴은 분류기 학습 데이터에 자동 추가 + 운영자 알림. (3) 분류기 재학습 사이클 — 1,000건+ 새 라벨 데이터 모이면 분류기 재학습. 보통 월 1회 트리거.

피드백 루프를 붙여두면 운영 기간이 길어질수록 분류 정확도가 꾸준히 올라가요. 사용자 피드백 루프가 분류기 품질 자동 개선의 핵심 메커니즘이에요. 피드백 인터페이스는 답변 카드 우측 하단에 작게 넣는 편이 좋아요. 크게 넣으면 습관적으로 눌러 노이즈가 섞여요.

7단계 — 5개 핵심 지표 일·주별 모니터링

Adaptive RAG 운영의 본전 지표 5개. 매일 자동 대시보드, 주별 운영자 리뷰.

(1) 티어별 분포 — 단순·중간·복잡 비율 시간 따른 변화. 정상 패턴은 단순 비중이 시간 흐름 따라 증가(캐시 hit·반복 쿼리 학습). 복잡 비중 갑자기 늘면 도메인 변화·사용자 패턴 변화 신호. (2) 티어별 비용 — 단순·중간·복잡 각각 평균 호출 비용. 단순 비용이 의외로 높으면 캐시 hit률 점검 신호. (3) 응답 시간 p50·p95 — 평균만 보면 long tail 놓침. p95가 5초 넘으면 사용자 이탈 위험. (4) 분류 정확도 — 분류기 결정 vs 사용자 피드백 일치율. 80%+ 유지 목표. (5) 캐시 hit률 — L1·L2·L3 각각. 합산 25%+ 권장. L1만 5% 미만이면 정확 매칭 캐시 키 정규화 점검.

본인 대시보드 — Grafana·Datadog·Sentry로 5개 지표 그래프. 주별 월요일 운영자 리뷰 미팅 30분. 매주 분류 오판 top 10 쿼리 라벨링 + 재학습 결정. 사이클이 도입 6개월 후 자동화되면서 비용 절감 효과가 누적이에요.

5월 22일부터 바로 시작할 액션 4가지

이번 글에서 정리한 7단계 중 첫 2주에 본전 큰 액션 4개.

(1) 현재 RAG에 LLM 분류기 박기 — 저렴한 경량 모델에 분류 프롬프트. 1일 작업. 모든 쿼리에 분류 결과만 로깅(파이프라인은 변경 X). 1주 후 도메인별 티어 비중 측정.

(2) 단순 티어 파이프라인 분리 — 1주 측정 결과에서 단순으로 분류된 쿼리만 별도 파이프라인(L1·L2 캐시 + 벡터 단일 검색 + 저렴한 LLM)으로 라우팅. 비용·응답 시간 즉시 개선.

(3) L1·L2 캐시 도입 — Redis·Cloudflare KV에 정확 매칭 + 임베딩 의미 유사 캐시 박기. TTL 1시간. hit률 모니터링.

(4) 사용자 피드백 좋아요·싫어요 버튼 — 답변 카드에 박기. 싫어요 쿼리 자동 수집 → 분류기 학습 데이터 누적 시작.

이 4개만 먼저 넣어도 도입 초기부터 비용과 응답 시간이 함께 내려가요. 이어서 분류기 재학습과 복잡 티어 Agentic RAG 분리까지 마치면 절감 폭이 한 번 더 커져요. RAG 운영 본전은 한 번에 다 도입하지 말고 1주·1개월·3개월 단계별로 적용하는 흐름이에요. MCP 서버 운영 + n8n HITL 같은 다른 영역에도 같은 단계적 도입 원칙이 적용되는 보편 패턴이에요.

Adaptive RAG 도입 흔한 실수 5가지

Adaptive RAG를 도입하는 팀들이 초반에 반복해서 밟는 실수 5가지. 도입 전 점검하면 시행착오 시간 크게 줄어요.

(1) 분류기 과적합 — 학습 데이터 본인 도메인 한정 — LLM 분류기를 본인 데이터로만 미세조정하면 새로운 쿼리 패턴에 분류 실패. zero-shot LLM 분류기로 시작 + 사용자 피드백 누적 후 임베딩 분류기로 전환이 안전. 첫 단계에 과적합 분류기 박으면 1년 후 재학습 비용이 큼.

(2) 티어 비중 정적 결정 — 도메인 변화 반영 X — 운영 6개월 후 사용자 행동 패턴 변화로 단순·복잡 비중이 크게 달라지는데 티어 분류 기준을 고정하면 분류 정확도 폭락. 분기마다(3개월) 티어 비중·기준 재검토 사이클이 본전.

(3) 캐시 무효화 누락 — stale 답변 사고 — 문서 업데이트 시 관련 캐시 자동 무효화 안 박으면 사용자가 outdated 답변 받음. 사내 정책 변경·세법 개정 같은 이슈에서 사고 위험. 문서 인덱싱 파이프라인에 캐시 무효화 webhook 강제 통합.

(4) A/B 테스트 트래픽 너무 적음 — 1% 트래픽으로 A/B 테스트하면 분류 오판 패턴 발견에 3개월+ 걸림. 첫 한 달은 5~10% 트래픽으로 빠르게 패턴 수집 → 패턴 안정화 후 1%로 낮추는 흐름이 학습 속도 본전.

(5) 사용자 피드백 버튼 위치 잘못 — 답변 카드 위쪽이나 큰 버튼으로 박으면 습관적 클릭이 늘어 노이즈. 카드 하단에 작게 넣는 편이 진짜 의견 가진 사용자만 클릭하는 패턴이라 학습 데이터 품질이 좋아요.

5가지는 도입 첫 몇 달에 한 번씩은 겪게 되는 실수예요. 사전 인지가 본전 시점 단축이에요.

Adaptive RAG + LLM 모델 라우팅 결합 — 절감 폭 한 번 더

Adaptive RAG 위에 LLM 모델 라우팅까지 결합하면 추가 비용 절감 가능. 단순·중간·복잡 티어별로 다른 LLM 모델을 자동 선택.

(1) 단순 티어 → 각 제공사의 경량 모델 — 사실 검색·캐시 답변 정리에 충분. (2) 중간 티어 → 중급 모델 — 다중 문서 합성·요약에 본전. (3) 복잡 티어 → 최상위 모델 — 다단계 추론·Agentic RAG 루프에 한정. 모델별 토큰 단가는 개편이 잦으니 라우팅 표를 만들기 전에 각 제공사 공식 가격 페이지에서 최신 단가를 확인하세요.

경량 모델과 최상위 모델의 단가 차이는 몇 배에서 수십 배까지 벌어지니, Adaptive RAG로 티어를 나눈 뒤 모델 라우팅까지 붙이면 절감 폭이 한 번 더 커져요. 단, (a) 단순 티어에 너무 약한 모델 쓰면 답변 품질 폭락 위험, (b) 복잡 티어에 충분히 강한 모델 안 쓰면 정확도 손실. 모델별 답변 품질을 본인 도메인 데이터로 한 달 평가 후 라우팅 결정이 정답이에요.

운영 메커니즘 — 분류기가 티어 결정 후 LLM 라우터가 모델 선택. 라우터는 단순 if-else 로직으로 충분(에이전트 불필요). 비용·속도·품질 3축 최적화의 마지막 한 단계가 모델 라우팅이에요.

❓ 자주 묻는 질문 (FAQ)

Adaptive RAG가 기존 Hybrid RAG와 어떻게 다른가요?

Hybrid RAG는 모든 쿼리에 같은 파이프라인(BM25 + 벡터 + reranker)을 돌리는 단일 흐름. 단순한 사실 검색이든 복잡한 다단계 추론이든 똑같이 reranker까지 호출하니 단순 쿼리에 과한 비용이 들어요. Adaptive RAG는 그 앞에 쿼리 분류기를 박아서 쿼리 복잡도를 3티어(단순·중간·복잡)로 분류한 다음 티어별 다른 파이프라인을 라우팅. 단순 쿼리는 캐시·벡터 단일 검색만, 복잡은 Agentic RAG·Graph RAG까지 활성화. 단순 쿼리에서 reranker와 불필요한 LLM 호출이 빠지니 호출량과 평균 응답 시간이 함께 줄어요. 정확도는 단일 흐름과 비슷하게 유지돼요.

쿼리 분류기는 어떻게 만들고 학습 데이터는 어디서 모으나요?

분류기 옵션 3가지. (1) LLM 분류기 — 저렴한 경량 모델에 분류 프롬프트. 호출 비용이 매우 낮고 구현은 하루면 끝나요. (2) 임베딩 + 분류 헤드 — 쿼리 임베딩 → 작은 분류 헤드(MLP) 학습. 본인 데이터 1,000건+ 필요. 호출당 비용 거의 0. (3) 규칙 기반 — 길이·키워드·문장 수 같은 휴리스틱. 비용은 0이지만 정확도는 낮은 편. 권장은 (a) MVP 단계: 규칙 기반으로 시작, (b) 사용자 100명+ 데이터 모이면 LLM 분류기로 전환, (c) 1,000건+ 라벨 데이터 모이면 임베딩 분류기로 비용 절감. 학습 데이터는 본인 RAG 사용 로그(쿼리·실제 사용된 파이프라인·정답률)에서 자동 수집.

단순·중간·복잡 3티어 분류 기준이 정확히 뭔가요?

(1) 단순(Tier 1, 40~50% 비중) — 사실 검색·단일 문서 답변·캐시 가능. 예: '5월 매출 보고서 어디 있어?', '회의실 예약 정책이 뭐야?'. 처리: 캐시 조회 → 미스면 벡터 단일 검색. (2) 중간(Tier 2, 35~45% 비중) — 다중 문서 합성·간단 비교. 예: '경쟁사 A·B 가격 정책 차이 정리해줘'. 처리: Hybrid RAG(BM25 + 벡터 + reranker). (3) 복잡(Tier 3, 10~20% 비중) — 다단계 추론·교차 참조·계산 필요. 예: 'Q1 매출 데이터 + 마케팅 비용 + 채널별 ROI 통합 분석'. 처리: Agentic RAG(에이전트가 plan-retrieve-validate-reflect 루프). 비중은 도메인별로 달라요. 본인 데이터로 측정해서 조정 필수.

각 티어별 비용·응답 시간 차이가 얼마나 나요?

절대 수치는 문서 규모·모델·인프라에 따라 크게 달라지니 본인 환경에서 측정해야 하지만, 티어 간 차이의 방향은 뚜렷해요. (1) 단순 — 캐시 hit이면 LLM 호출 0건이라 사실상 즉시 응답에 비용도 거의 안 들어요. 캐시 miss여도 벡터 단일 검색 + 답변 1회라 가장 가벼워요. (2) 중간 Hybrid — reranker와 답변 생성으로 LLM 호출이 늘어 단순 티어보다 몇 배 무거워요. (3) 복잡 Agentic — plan-retrieve-validate 루프에서 호출이 여러 번 반복되니 응답 시간과 비용 모두 가장 큽니다. 결국 모든 쿼리를 중간·복잡 파이프라인으로 처리하던 걸 티어별로 갈라 놓는 것만으로 평균 비용과 평균 응답 시간이 함께 내려가요.

캐시 전략은 어떻게 설계해야 hit률 높이고 stale 답변 막나요?

3층 캐시 권장. (1) L1 — 정확 매칭 — 쿼리 텍스트 해시 키. hit 시 0.05초. TTL 1시간. 자주 묻는 질문에 본전. (2) L2 — 의미 유사 매칭 — 쿼리 임베딩 + 임계값(코사인 유사도 0.95+). hit 시 0.1초. TTL 1시간. 같은 의도 다른 표현 흡수. (3) L3 — 결과 캐시 — 검색 결과(top 10 문서)만 캐시, LLM 답변 생성은 매번 새로. TTL 24시간. 컨텍스트는 같지만 답변 톤 변형 가능. Stale 방지는 (a) TTL 짧게(1~24시간), (b) 문서 업데이트 시 관련 캐시 자동 무효화 webhook, (c) 사용자 피드백(나쁜 답변 표시) 시 즉시 무효화. 캐시 hit률은 서비스 성격에 따라 갈리는데, 반복 질문이 많은 도메인일수록 비용 절감 효과가 큰 핵심 컴포넌트예요.

분류기 오판으로 단순 쿼리가 복잡 파이프라인 타는 건 어떻게 막나요?

분류 오판은 (1) 비용·속도 손실(단순→복잡 오판), (2) 정확도 손실(복잡→단순 오판) 2가지 위험. 대응 3개. (a) 분류 confidence threshold — 분류 신뢰도 0.7 미만이면 안전한 쪽(중간 티어)로 fallback. (b) A/B 테스트 로깅 — 분류기 결정 vs 강제 풀 파이프라인 결과를 1% 트래픽에 동시 실행 비교. 분류 오판 패턴 자동 감지. (c) 사용자 피드백 루프 — 답변에 좋아요·싫어요 버튼. 싫어요 비율 높은 쿼리 패턴을 분류기 학습 데이터에 자동 추가. 운영 초기에는 오판이 섞이는 게 정상이고, 피드백 데이터가 쌓이면서 분류 정확도가 올라가는 흐름이에요.

Adaptive RAG 도입 후 모니터링 핵심 지표 5개가 뭐예요?

(1) 티어별 분포 — 단순·중간·복잡 비율 모니터링. 시간 흐름 따라 단순 비중 증가가 정상(캐시 hit·반복 쿼리 학습). 복잡 비중 갑자기 늘면 도메인 변화·사용자 패턴 변화 신호. (2) 티어별 비용 — 단순·중간·복잡 각각 평균 호출 비용. 단순 쿼리 비용이 의외로 높으면 캐시 hit률 점검. (3) 응답 시간 p50·p95 — 평균만 보면 long tail 놓침. p95가 5초 넘으면 사용자 이탈 위험. (4) 분류 정확도 — 분류기 결정 vs 사용자 피드백 일치율. 80%+ 유지 목표. (5) 캐시 hit률 — L1·L2·L3 각각. 25%+ 권장. 5개 지표를 매일·주별 대시보드로 모니터링하는 운영 사이클이 본전 핵심이에요.

📚 함께 읽으면 좋은 글 (Related Posts)

AI 사용법 가이드 더 보기 →
GitHub Copilot 무료와 유료 차이, AI 크레딧 기준으로 다시 정리했어요
ai-guide2026-10-02

GitHub Copilot 무료와 유료 차이, AI 크레딧 기준으로 다시 정리했어요

GitHub Copilot 무료와 유료 차이를 GitHub 공식 문서로 정리했어요. 무료 플랜은 코드 완성이 월 2,000회로 묶이고 모델은 자동 선택만 되며, 받는 AI 크레딧 양은 숫자로 공개돼 있지 않아요. Pro는 월 10달러에 1,500크레딧과 무제한 코드 완성을 줘요. 1크레딧은 0.01달러이고 매달 1일 UTC 0시에 초기화돼요. 2026년 10월 2일에 받은 문서 기준이에요.

AI 에이전트 종류는 누가 나누느냐에 따라 달라요, 구글과 앤트로픽의 분류 비교
ai-guide2026-10-01

AI 에이전트 종류는 누가 나누느냐에 따라 달라요, 구글과 앤트로픽의 분류 비교

AI 에이전트 종류를 구글 클라우드와 앤트로픽이 직접 낸 문서로 비교했어요. 구글은 사용자와 상호작용하는 방식에 따라 대화형과 백그라운드로, 에이전트 수에 따라 단일과 멀티로 나누고, 에이전트와 어시스턴트와 봇의 차이도 표로 적어요. 앤트로픽은 에이전트형 시스템을 정해진 경로를 따르는 워크플로와 스스로 과정을 정하는 에이전트로 나눠요. 두 문서 모두 정의가 여러 가지라고 적고 있어서 하나의 표준 분류는 아니에요. 2026년 10월 1일에 받은 문서 기준이에요.

클로드 무료 사용량은 몇 번까지일까, 공식 문서에는 고정 횟수가 없어요
ai-guide2026-09-30

클로드 무료 사용량은 몇 번까지일까, 공식 문서에는 고정 횟수가 없어요

클로드 무료 사용량을 Anthropic 요금 페이지와 고객센터 문서로 확인했어요. 공식 문서에는 무료 플랜의 고정 메시지 수가 없고, 세션 기반 한도가 5시간마다 초기화되는 구조예요. 보낼 수 있는 양은 대화 길이와 첨부 파일, 고른 모델, 쓰는 기능에 따라 달라지고 수요에 따라서도 바뀐다고 적혀 있어요. Pro 는 5시간 세션당 무료의 최소 5배예요. 2026년 9월 30일에 받은 문서 기준이고, 메시지를 직접 세어 보지는 않았어요.

제미나이 노트북은 노트북LM과 다른 서비스일까, 이름이 바뀐 뒤 달라진 것
ai-tools2026-10-05

제미나이 노트북은 노트북LM과 다른 서비스일까, 이름이 바뀐 뒤 달라진 것

제미나이 노트북(Gemini Notebook)은 노트북LM의 새 이름이에요. 구글은 2026년 7월 16일 이름을 바꾸면서 같은 독립 제품이라고 밝혔어요. 옛 주소 notebooklm.google.com은 10월 5일 확인 때 notebook.google.com으로 영구 이동했고, 요금 문서에는 무료 Standard가 Gmail 계정으로 가입하는 요금제로 적혀 있어요. 함께 발표된 변화는 제미나이 앱과 검색 AI 모드에서 같은 노트북을 여는 것, 일부 요금제부터 열린 코드 실행이에요. 10월 5일 고객센터 기준 AI 모드 노트북은 영어로만 돼요.

엑셀 COPILOT 함수가 안 된다면, 9월 14일 종료와 대신 쓸 방법
ai-tools2026-10-04

엑셀 COPILOT 함수가 안 된다면, 9월 14일 종료와 대신 쓸 방법

엑셀 COPILOT 함수는 2026년 9월 14일부터 쓸 수 없어요. 켜는 설정을 못 찾은 게 아니라 함수 자체가 빠졌어요. 원래도 미리 보기 기능이라 Frontier 프로그램과 Microsoft 365 참가자 프로그램에서만 열렸던 함수예요. 이미 계산된 결과는 캐시된 값으로 남지만, 셀이 다시 계산되면 #NAME? 오류가 나요. 대신 엑셀 오른쪽 아래 Copilot 아이콘으로 Copilot 창을 열고 같은 일을 말로 시키면 돼요. 2026년 10월 5일에 받은 마이크로소프트 문서 기준이에요.