Aside는 "AI를 브라우저에 얹은 것"이 아니라 브라우저를 에이전트가 일하는 작업대로 다시 지은 것이다. API 연동을 새로 붙이는 대신, 내가 이미 로그인해 둔 그 화면을 사람처럼 직접 조작한다.

AI 브라우저는 지난 2년 동안 계속 "곧 된다"는 말만 들었습니다. 데모는 멋있는데 실제 업무를 맡기면 로그인 화면에서 멈추고, 결제 단계에서 포기하고, "죄송하지만 이 작업은 할 수 없습니다"로 끝났습니다. Aside(어사이드) 는 그 실패 지점을 정면으로 겨냥한 제품입니다. 2026년 6월에 공개됐고, 지금 macOS와 Windows에서 무료로 시작할 수 있습니다.

이 글은 공식 사이트·기술 블로그·벤치마크 저장소를 직접 확인해서, 뭐가 다른지 / 실제로 얼마나 되는지 / 어디서 조심해야 하는지를 정리한 글입니다.

1. 한 줄 정의: "통합 없이, 로그인 그대로"

Aside의 자기 소개는 이 문장으로 시작합니다.

"Today's AI browsers are broken. They never complete a task. … Aside is a browser rebuilt for people and agents."

번역하면 — 지금 AI 브라우저는 고장났다. 태스크를 끝내지 못한다. Aside는 사람과 에이전트를 위해 브라우저를 다시 지은 것이다.

핵심 차이는 접근 방식입니다. 대부분의 에이전트는 서비스마다 연동(integration) 을 붙입니다. Gmail 커넥터, 슬랙 커넥터, 노션 커넥터… 없는 서비스는 못 씁니다. Aside는 반대로 내가 이미 쓰는 웹사이트와 계정을 그대로 씁니다. 사람이 하듯이 로그인된 세션에서 클릭하고 입력합니다.

그래서 "연동이 없는 서비스"도 쓸 수 있습니다. 사내 그룹웨어, 오래된 관리자 페이지, 결제 페이지, 관공서 사이트까지요. 대신 브라우저가 내 모든 로그인을 들고 있는 곳이 되기 때문에, 뒤에서 다룰 금고(Vault)와 승인 게이트가 제품의 절반을 차지합니다.

2. 왜 지금인가: 1세대 AI 브라우저의 실패

Aside가 등장한 배경에는 1세대 제품들의 줄줄이 이어진 실패가 있습니다.

시기	사건	의미
2025	Dia, Perplexity Comet, ChatGPT Atlas 등장	"AI가 옆에서 돕는 브라우저" 컨셉 확산
2025~26	실제 업무 태스크 완주율 낮음	로그인·결제·다단계 폼에서 중단
2026-05	TechCrunch "Chrome·Safari 대안" 특집에 Aside 소개	시장이 대안을 찾기 시작
2026-07	ChatGPT Atlas 서비스 종료	1세대 AI 브라우저의 상징적 후퇴
2026-07	9to5Mac "Atlas 종료 후 실제로 쓰는 AI 브라우저"에 Aside 포함	대체재로 지목

Atlas가 사라진 뒤 시장은 두 갈래로 갈렸습니다. 하나는 브라우저에 비서를 얹는 방식(Comet, Dia), 다른 하나는 에이전트가 일하도록 브라우저를 새로 짜는 방식(Aside). Aside의 기술 블로그는 이 지점을 이렇게 표현합니다. "Dia, Comet, Atlas의 에이전트는 진짜 작업 하나를 끝내기에 너무 멍청했다."

3. 실제로 뭘 할 수 있나

Aside가 내세우는 작업 범위는 "웹에서 사람이 하는 일" 거의 전부입니다. 공식 문서와 유스케이스 페이지에 나온 것들을 묶으면 이렇습니다.

영역	예시 작업
개인 행정	카드 명세서 확인, 구독 해지, 보험·항공 예약 변경
커뮤니케이션	메일함 정리, 답장 초안, 메신저 확인
운영(ops)	SaaS 리포트 수집, 인보이스 다운로드, 갱신·승인 처리
채용(HR)	온보딩·오프보딩 서류, 채용 공고 게시, 지원자 스크리닝
개발	CI 실패 로그 확인, 스테이징 스크린샷, 대시보드 모니터링
리서치	출처 수집, 가격 페이지 캡처, PDF 필드 추출, 근거 기록

특히 눈에 띄는 건 개발자용 인터페이스입니다. Aside는 앱 안에서만 쓰는 게 아니라 aside CLI, REPL, MCP 서버로도 붙습니다. 예를 들어 이렇게 시킬 수 있습니다.

aside "Open the failed GitHub Actions run for this PR, find the first failing step,
compare it with the last passing run, and draft a PR comment with log links. Do not post it."

aside repl     # Playwright처럼 페이지·탭·로케이터·스크린샷을 직접 다룸
aside mcp      # 코딩 에이전트가 사내 대시보드 증거를 가져오게 함

CI 로그·Datadog 트레이스·피처 플래그처럼 브라우저로만 열리는 증거를 코딩 에이전트에게 먹이는 용도입니다. 요즘 개발 워크플로에서 실제로 병목이 되는 지점이라, 이건 꽤 실용적인 포지션입니다.

4. 성능: 벤치마크 3종 1위, 단 조건을 봐야 한다

Aside가 가장 크게 홍보하는 숫자입니다. 2026년 6월 기준으로 세 개의 브라우저 에이전트 벤치마크에서 1위를 주장합니다.

벤치마크	내용	Aside 결과	비교
Online-Mind2Web	실제 웹사이트 136곳, 300개 태스크	297/300 (99.0%)	GPT-5.4 CUA 92.8%, Opus 4.8 + Claude Code(Playwright MCP) 84.0%, Atlas 70.0%
Odysseys (CMU)	실제 브라우징 기록 기반 200개 장기 태스크	완주 151/200 (75.5%), 루브릭 88.8%	루브릭 기반 부분 점수
BU-Bench-V1	Browser Use의 100개 고난도 태스크	93/100 (93.0%)	Fable 5 + Claude Code 80%, Kimi K2.6로도 88%

숫자만 보면 압도적입니다. 그런데 여기서 반드시 짚어야 할 세 가지가 있습니다.

1. 자사 주도 측정이다. 결과 저장소(at-inc/aside-benchmarks)는 공개돼 있어 태스크별 판정과 실패 사유까지 볼 수 있지만, 실행·채점 파이프라인은 회사가 돌린 것입니다. 경쟁 제품은 회사가 직접 돌린 결과입니다.
2. 모델이 다르다. Aside는 GPT-5.5(고사고 모드)로, 경쟁은 다른 모델로 측정됐습니다. 회사도 이 비교가 "모델 대 해네스"라서 논쟁적이라는 점을 인정하고 "sorry for the ragebait"라고 씁니다.
3. 그래도 의미는 있다. 같은 모델 계열에서도 하네스(에이전트 실행 구조) 에 따라 성적이 20%p 가까이 벌어진다는 건 실제로 중요한 발견입니다. Aside + Kimi K2.6이 Fable 5 + Claude Code를 이겼다는 대목이 그 근거입니다.

정리하면 — "Aside가 세계 최고"라고 단정할 수는 없지만, "브라우저 조작을 잘 시키는 구조가 따로 있다" 는 주장은 데이터로 뒷받침됩니다.

5. 어떻게 만들었나: 브라우저가 아니라 코딩 에이전트다

기술 블로그에서 가장 흥미로운 부분입니다. Aside는 자기를 "코딩 에이전트" 라고 부릅니다. 코어 도구가 딱 두 개입니다. JS REPL과 bash.

• 브라우저를 CDP나 원시 DOM으로 제어하지 않고, Playwright 문법의 JS 코드를 직접 작성해서 조작합니다.
• 이유는 단순합니다. LLM이 학습 과정에서 가장 많이 본 게 코드이고, 그중 브라우저 자동화는 Playwright입니다. "모델이 이미 아는 인터페이스를 왜 새로 발명하는가."
• 시스템 프롬프트는 도구 정의까지 포함해 약 10K 토큰. Claude Code는 20K 정도라고 비교합니다.
• 화면 상태는 원시 DOM 대신 가공한 접근성 트리(a11y tree) 로 전달합니다. DOM은 div와 스타일이 90%를 차지해 컨텍스트를 낭비한다는 판단입니다.
• 기반은 pi-mono/core를 썼고, 컴팩션·스킬·훅·샌드박스·REPL·bash·브라우저 자동화는 직접 구현했습니다.

코드로 조작한다는 건 실무에서 차이가 큽니다. 복잡한 폼을 채우거나, 유튜브 영상을 프레임 단위로 확인하거나, 페이지가 막혔을 때 네트워크 요청을 뜯어 사이트 내부 API를 역으로 찾아 쓰는 우회가 가능해집니다. 요청이 사이트 자신의 요청과 똑같아서 봇으로도 잘 안 걸립니다.

6. 메모리: 브라우징 기록이 곧 업무 기억

에이전트가 실패하는 두 번째 이유는 매번 처음부터 시작한다는 점입니다. Aside는 브라우징 기록을 메모리로 바꿉니다.

• 어떤 사이트를 어떤 일에 쓰는지 학습합니다. ("어제 열어둔 지원자 찾아서 면접 노트 준비해")
• 태스크가 끝나면 "dreaming" 이라는 하위 에이전트가 인물·회사·결정 같은 핵심만 추출해 저장합니다.
• 사이트에서 막혔을 때 통했던 경로를 사이트별로 기억합니다.
• 메모리는 마크다운 파일로 기기에 저장되고, 사용자가 직접 열어보고 수정할 수 있습니다.

여기서 중요한 건 저장 위치입니다. Aside는 메모리가 로컬에만 있고 외부와 공유되지 않는다고 명시합니다. 임베딩도 로컬 모델을 씁니다. "클라우드에 내 브라우징 기록이 쌓인다"는 게 싫은 사람에게는 이게 결정적입니다.

7. 비밀번호: 에이전트에게 안 보여주고 로그인시키기

AI 브라우저의 진짜 난관은 로그인입니다. 대부분의 에이전트는 로그인 화면에서 멈추고 사람을 부릅니다. Aside는 Aside Vault라는 비밀번호 관리자를 따로 만들었습니다.

기능	내용
자동 채움	자격증명을 모델에 노출하지 않고 페이지에 주입
암호화	기기 내 전체 암호화, Secure Enclave 기반 하드웨어 보호
범위 제한	태스크에 필요한 자격증명만, 그 태스크 동안만 접근
감사 로그	무엇을 언제 왜 썼는지 기록
가져오기	1Password, Apple Passwords, Bitwarden, Dashlane, LastPass, Chrome

"AI에게 내 비밀번호를 준다"는 감각적 저항을 기술로 푸는 접근입니다. 모델은 비밀번호를 보지 못하고, 브라우저가 대신 채워 넣습니다. 사람이 쓰는 비밀번호 관리자와 같은 원리죠.

8. 안전장치: 되돌릴 수 없는 건 사람이 누른다

행동	Aside 단독	내 승인 필요
페이지 읽기, 정보 수집, 스크린샷	가능	—
폼 작성, 초안 생성, 파일 정리	가능	—
메시지 발송, 게시, 결제	—	필요
로그인·자격증명 사용	자동 채움	범위 밖이면 차단

여기에 파일시스템·네트워크 격리, 그리고 (회사 주장으로) 포스트-퀀텀 암호화가 더해집니다. 다만 이 부분은 벤더 설명이므로, 실제 도입 전에는 민감 계정을 분리한 프로필에서 먼저 검증하는 게 안전합니다.

원칙은 하나입니다. 브라우저에 로그인을 맡기는 순간, 그 브라우저는 내 권한의 사본이 된다. 승인 게이트는 편의 기능이 아니라 사고의 마지막 방어선이다.

9. 요금제: 무료로 시작, 쓰면 늘린다

플랜	가격	사용량	루틴(예약 작업)
Free	$0	월 500 크레딧	3개
Pro	$20/월	무료의 3배	무제한
Max	$200/월	무료의 40배	무제한
Enterprise	별도 문의	팀 단위	팀 공용 프로필·금고

모델은 가져오는 방식입니다. ChatGPT Plus/Pro, Claude Pro/Max, GitHub Copilot 구독을 연결하거나, Anthropic·OpenAI·Google·xAI·OpenRouter 등의 API 키를 직접 넣을 수 있습니다. 즉 Aside는 모델을 파는 게 아니라 실행 환경을 파는 구조입니다.

크레딧이 '모델 토큰'이 아니라 '작업량' 기준이라는 점은 장단점이 있습니다. 토큰 개념 글에서 정리했듯 토큰은 모델마다 단가가 다른데, 크레딧으로 추상화하면 예측은 쉬워지고 대신 비싼 모델을 쓰면 손해일 수 있습니다.

10. 경쟁 구도: 누구와 싸우는가

제품	성격	강점	약점
Chrome + Gemini	기존 브라우저에 AI 내장	설치·호환성	에이전트 완주율
Perplexity Comet	검색·리서치 중심	정보 탐색	로그인 후 업무
Dia	대화형 브라우저	UX	복잡한 다단계 작업
ChatGPT Atlas	1세대 AI 브라우저	브랜드	2026-07 종료
Aside	에이전트 우선 브라우저	완주율·로컬 메모리·금고	데스크톱 전용·자사 벤치마크

재미있는 건 Aside가 자기 경쟁자를 "다른 AI 브라우저"가 아니라 "Claude Code + Playwright MCP" 같은 개발자 도구 조합으로 본다는 점입니다. 브라우저 자동화를 이미 하던 사람들이 타깃이라는 뜻입니다. AI 코딩 툴 비교에서 다룬 도구들과 정면으로 겹칩니다.

11. 아직 약한 점 5가지

1. 데스크톱만 된다 — macOS·Windows 앱. 리눅스·모바일·웹 버전은 확인되지 않음
2. 벤치마크는 자사 측정 — 공개 저장소로 검증 가능하지만, 경쟁 제품 조건은 회사가 정한 것
3. 크레딧 소모가 큼 — 장기 태스크(수십 단계, 수 분~수 시간)는 크레딧을 빨리 먹습니다
4. 로그인 위임 리스크 — 편한 만큼, 뚫리면 피해 범위가 큽니다. 업무용/개인용 프로필 분리가 필수
5. 한국 환경 검증 부족 — 한국 사이트 호환성, 원화 결제, 국내 서비스 로그인 흐름은 직접 테스트해야 합니다

특히 5번은 국내 사용자에게 실질적입니다. 공공·금융 사이트처럼 보안 플러그인과 인증서가 끼는 흐름은 아직 검증 사례가 없습니다.

12. 도입한다면 이 순서로

1. 개인 계정이 아닌 전용 프로필로 설치 — 업무용 브라우저 프로필을 따로 만들고 시작
2. 읽기 전용 태스크부터 — "명세서 확인", "가격 페이지 캡처"처럼 쓰기 없는 일로 품질 확인
3. 초안까지만 — 메일·게시글은 항상 초안에서 멈추게 하고 내가 전송
4. 승인 게이트 유지 — 결제·발송·삭제는 절대 자동 승인하지 않기
5. Vault 범위 최소화 — 태스크별로 필요한 자격증명만, 끝나면 정리
6. 감사 로그 주간 확인 — 어떤 자격증명이 언제 쓰였는지 습관적으로 점검

에이전트 사고의 대부분은 성능 부족이 아니라 권한 과다에서 나옵니다. Aside처럼 브라우저 전체를 쥔 제품은 그 원칙이 더 중요합니다.

13. 정리

• Aside는 통합 없이 로그인된 웹을 직접 조작하는 데스크톱 AI 브라우저다. 2026년 6월 공개, macOS·Windows, 무료 500크레딧부터.
• 기술적 핵심은 브라우저를 코딩 에이전트로 다루는 하네스다. Playwright JS + a11y 트리 + 10K 프롬프트 + 로컬 메모리 + 자격증명 금고.
• 성능 주장은 인상적이지만 자사 측정이다. 지금 바로 믿을 건 "완주율이 실제로 다르다"는 부분이고, 계정 보안은 내가 설계해야 한다.

3줄 요약하면 — 통합 대신 로그인, 코딩 에이전트로 만든 브라우저, 권한은 좁게·승인은 유지.

---

출처

• Aside 공식 사이트 · 가격 · 헬프센터
• How we built a browser agent that outperforms Fable (Aside Blog, 2026-06-25)
• 벤치마크 결과 저장소 (GitHub, at-inc/aside-benchmarks)
• Y Combinator 기업 페이지
• 9to5Mac: With ChatGPT Atlas shutting down (2026-07-10)

관련 글

• AI 기초 용어 20개
• 토큰이란 무엇인가
• AI 코딩 툴 비교

토큰(token)이란 - AI가 글자를 세는 방식과 요금 계산 (2026)

AI API를 처음 붙이면 반드시 이런 에러를 만난다. This model's maximum context length is 8192 tokens. 분명히 짧은 질문을 보냈는데 토큰이 넘친다고 한다. 이유는 하나다. 모델은 글자를 읽지 않고 토큰을 읽는다.

이 글은 토큰이 정확히 무엇이고, 왜 "글자 수 ÷ 4"가 한국어에서는 틀리는지, 그리고 그 숫자가 어떻게 청구서가 되는지를 순서대로 정리한다. 예시 숫자는 실제 토크나이저로 센 값이라 그대로 재현할 수 있다.

핵심 원칙 한 줄: 토큰은 "글자"가 아니라 "모델이 아는 최소 조각"이다. 그래서 언어가 바뀌면 같은 내용도 값이 달라진다.

---

0) 30초 요약

궁금한 것	답
토큰이 뭔가	모델이 텍스트를 자르는 최소 단위. 단어보다 작을 때도 있다
1토큰은 몇 글자	영어 약 4자, 한국어는 약 1.5~2자 (인코딩마다 다름)
왜 중요한가	요금·속도·컨텍스트 한도가 전부 토큰으로 계산된다
어떻게 세나	tiktoken 또는 각 회사의 token counting API
줄이는 법	출력 길이 제한, 프롬프트 캐싱, 불필요한 예시 삭제

이 다섯 줄이 이 글의 전부다. 아래는 그 이유와 실습이다.

---

1) 증상 - "토큰이 부족합니다"는 무슨 뜻인가

처음 보는 에러 세 가지를 먼저 정리한다.

# 1. 입력이 너무 길다
This model's maximum context length is 8192 tokens.
However, your messages resulted in 9000 tokens.

# 2. 출력이 잘렸다
finish_reason: "length"

# 3. 요금이 예상보다 크다
usage: { input_tokens: 12000, output_tokens: 3000 }

세 개 모두 원인이 같다. 내가 보낸 "글"이 모델 기준으로는 예상보다 많은 "토큰"이었다는 것. 한국어로 프롬프트를 쓰면 특히 이 일이 자주 생긴다. 1번에서 다룰 토크나이저 구조 때문이다.

---

2) 원인 - 토큰은 BPE로 잘린 조각이다

LLM은 텍스트를 숫자 배열로 바꿔서 계산한다. 이 변환을 토큰화(tokenization)라고 하고, 대표적인 방식이 BPE(Byte Pair Encoding) 다.

BPE는 간단하다. 자주 붙어 나오는 글자 조합을 하나의 기호로 합치는 것을 반복한다.

low, lower, lowest 를 아주 많이 학습했다면

"lowest"  →  ["low", "est"]      (2토큰)
"newest"  →  ["new", "est"]      (2토큰)
"unque"   →  ["un", "que"]       (2토큰)

그래서 토큰은 이런 모양이 된다.

• 한 글자일 수도 있고 (a)
• 단어 일부일 수도 있고 (ing)
• 단어 하나일 수도 있고 (token)
• 구두점·공백·줄바꿈도 각각 토큰이 될 수 있다

OpenAI 공식 문서도 "토큰은 문자, 단어의 일부, 단어 전체, 또는 구두점일 수 있다"고 설명한다. 즉 토큰 ≠ 단어 ≠ 글자다. 이 셋을 섞으면 계산이 전부 틀어진다.

BPE의 장점은 임의의 텍스트를 손실 없이 처리한다는 점이다. 학습 때 못 본 단어나 이모지도 바이트 단위로 쪼개서 어떻게든 표현한다. 대신 그런 텍스트는 토큰을 더 많이 먹는다.

---

3) 그래서 "글자 수 ÷ 4"는 영어에서만 맞다

OpenAI 문서의 경험 법칙은 이렇다.

기준	값
1 토큰	약 4글자 (영어)
1 토큰	약 0.75 단어 (영어)
100 토큰	약 75 단어 (영어)

문제는 이 숫자가 영어 기준이라는 것이다. 문서에도 "다른 언어는 문자·단어·토큰의 관계가 다를 수 있다"고 못 박혀 있다.

실제로 세어 봤다. o200k_base 인코딩 기준이다.

import tiktoken
enc = tiktoken.get_encoding("o200k_base")

for s in ["Hello, how are you today?",
          "안녕하세요 오늘 기분은 어떠세요?",
          "토큰이란 무엇인가",
          "안녕하세요"]:
    print(len(enc.encode(s)), len(s), s)

7   25  Hello, how are you today?      → 3.6자/토큰
10  18  안녕하세요 오늘 기분은 어떠세요?   → 1.8자/토큰
6    9  토큰이란 무엇인가                → 1.5자/토큰
2    5  안녕하세요                       → 2.5자/토큰

같은 인사말인데 영어는 7토큰, 한국어는 10토큰이다. 내용은 한국어가 더 짧은데 토큰은 더 많다. 한국어는 학습 데이터에서 상대적으로 적게 등장하고, 조사·어미가 붙어 형태가 계속 바뀌기 때문에 어절이 잘게 쪼개진다.

여기서 실무 규칙 하나가 나온다.

한국어 문서는 대략 "글자 수 ÷ 1.6" 정도로 잡고, 실제 값은 반드시 토크나이저로 확인한다.

주의할 점도 있다. 위 숫자는 특정 인코딩의 결과일 뿐이다. 모델이 다르면 인코딩이 다르고, 같은 문장도 토큰 수가 달라진다. OpenAI 문서가 "토큰 ID가 모든 모델에 적용된다고 가정하지 말라"고 하는 이유다.

---

4) 토큰은 하나가 아니다 - 입력·출력·캐시·추론

요금 계산이 어긋나는 가장 흔한 이유가 이걸 하나로 뭉뚱그리기 때문이다.

종류	설명	요금
입력 토큰	내가 보낸 프롬프트 (prompt tokens)	입력 단가
출력 토큰	모델이 생성한 답 (completion tokens)	출력 단가, 보통 더 비쌈
캐시된 입력 토큰	프롬프트 캐싱으로 재사용된 부분	할인 단가
추론 토큰	추론 모델이 답 전에 내부에서 쓴 토큰	출력과 동일하게 과금

마지막 줄이 특히 함정이다. 추론 토큰은 화면에 보이지 않지만 출력 토큰으로 청구된다. 그래서 짧게 답한 것 같은데 output 사용량이 수천으로 찍히는 일이 생긴다.

계산은 초등학교 산수다.

비용 = (입력 토큰 ÷ 1,000,000 × 입력 단가)
     + (출력 토큰 ÷ 1,000,000 × 출력 단가)

예) 입력 20,000 · 출력 2,000 · 입력 $3/M · 출력 $15/M
   = 0.06 + 0.03 = $0.09

여기서 감각적으로 알아야 할 것은 출력이 입력보다 3~5배 비싼 경우가 많다는 점이다. "답을 길게 써 달라"는 요청은 입력을 늘리는 것보다 비용에 크게 작용한다.

---

5) 컨텍스트 윈도우도 토큰이다

"컨텍스트 윈도우 200K"는 20만 글자가 아니라 20만 토큰이다. 한국어 기준으로 환산하면 체감 용량이 절반 이하로 줄어든다.

표기	영어 체감	한국어 체감
8K 토큰	약 6,000 단어	약 1만 2천 자
128K 토큰	약 96,000 단어	약 20만 자
200K 토큰	약 150,000 단어	약 32만 자

또 하나. 컨텍스트 윈도우는 입력 + 출력의 합이다. 8K 모델에 8K짜리 문서를 넣으면 답변할 공간이 0이 된다. 실제로는 답변 길이만큼 미리 비워 둬야 한다.

[ 입력 6,000 ][ 출력 여유 2,000 ]  ← 8K 모델의 안전한 배분

---

6) 토큰 세는 방법 - 3가지

방법 1. tiktoken (로컬, 무료, 빠름)

pip install tiktoken

import tiktoken

enc = tiktoken.encoding_for_model("gpt-4o")   # 모델에 맞는 인코딩 자동 선택
n = len(enc.encode("여기에 확인할 텍스트"))
print(n)

BPE 기반이라 손실 없이 되돌릴 수 있고, 임의 텍스트에 동작한다. 대량 배치 전에 대략적인 크기를 잡을 때 가장 편하다.

단, 텍스트만 센 값이다. 실제 요청에는 메시지 역할, 도구 정의, 스키마, 이미지가 붙으면서 토큰이 더 늘어난다. 정확한 값이 필요하면 2번을 쓴다.

방법 2. API의 토큰 카운팅 엔드포인트

OpenAI는 Responses 입력 전체를 세는 input-token counting API를 제공하고, Anthropic은 count_tokens 엔드포인트를 제공한다. 둘 다 메시지 구조·도구·이미지까지 포함한 값을 돌려준다.

# Anthropic 예시
import anthropic
client = anthropic.Anthropic()

r = client.messages.count_tokens(
    model="claude-sonnet-4-5",
    messages=[{"role": "user", "content": "토큰 계산 예시입니다."}],
)
print(r.input_tokens)

Anthropic 문서 기준으로 이 엔드포인트는 system 프롬프트, 도구, 이미지, PDF까지 입력으로 받는다. 이미지·PDF는 base64로 넣어야 세어 준다. 반면 웹 검색 같은 서버 도구나 MCP 커넥터를 쓰는 요청은 에러가 나므로, 그때는 실제 응답의 usage를 봐야 한다.

방법 3. 응답의 usage 필드 (가장 정확)

"usage": {
  "input_tokens": 812,
  "output_tokens": 240,
  "cache_read_input_tokens": 0
}

실제로 과금된 값이다. 로그에 이걸 남겨 두면 "예상 vs 실제"가 얼마나 벌어지는지 바로 보인다. 나는 새 모델을 붙일 때 첫 20건은 무조건 usage를 수집한다. 추정 공식이 안 맞는 경우를 대부분 여기서 잡는다.

---

7) 실전 - 토큰을 줄이는 7가지

1. 출력 길이를 명시한다. "3문장으로", "JSON만"처럼 상한을 준다. 출력 단가가 비싸므로 효과가 가장 크다.
2. 프롬프트 캐싱을 쓴다. 시스템 프롬프트·긴 참고자료처럼 매번 같은 앞부분은 캐시하면 입력 단가가 크게 떨어진다.
3. 예시(few-shot)를 줄인다. 예시 3개가 실제 질문보다 토큰을 더 먹는 경우가 흔하다. 2개로도 되면 2개만.
4. 표·JSON으로 압축한다. 같은 정보를 산문으로 반복하면 토큰이 두 배가 된다.
5. 대화 이력을 잘라낸다. 최근 N턴만 남기거나, 오래된 대화는 요약본으로 치환한다.
6. 긴 문서는 검색해서 넣는다. 문서 전체를 붙이지 말고 관련 부분만 뽑아 넣는다. 이 구조가 RAG다.
7. 한국어는 여유 있게 잡는다. 영어 기준 ÷4로 계산하면 한도에 걸린다. ÷1.5~÷2로 보수적으로.

특히 6번은 효과가 크다. 100페이지 문서를 매번 통째로 넣는 대신, 질문과 관련된 3페이지를 찾아 넣으면 입력 토큰이 90% 이상 줄어든다. 검색 증강생성(RAG)이 비용 이야기에서 자주 등장하는 이유다.

---

8) 자주 하는 오해 5개

오해	사실
"1토큰 = 1글자"	아니다. 영어 평균 4자, 한국어 1.5~2자
"공백은 안 세진다"	센다. 앞 공백이 붙은 토큰이 따로 있다
"같은 문장이면 어느 모델이든 토큰 수가 같다"	아니다. 인코딩이 모델마다 다르다
"토큰을 세면 요금이 정확히 나온다"	도구 정의·이미지·캐시 여부까지 반영해야 맞는다
"컨텍스트가 크면 많이 넣어도 된다"	길어질수록 비용·지연이 늘고, 중간 정보를 놓치기도 한다

세 번째가 은근히 중요하다. 모델을 바꿨더니 같은 프롬프트가 한도에 걸리는 일은 인코딩이 바뀌었기 때문인 경우가 많다. 모델 교체 시에는 토큰 수도 다시 재야 한다.

---

9) 정리 - 3줄 요약

1. 토큰은 BPE로 잘린 최소 조각이다. 글자도 단어도 아니므로 "글자 수 ÷ 4"는 영어에서만 통한다.
2. 요금·속도·컨텍스트 한도가 모두 토큰으로 계산되고, 입력·출력·캐시·추론 토큰은 단가가 각각 다르다.
3. tiktoken으로 대략 재고, 정확한 값은 토큰 카운팅 API나 응답의 usage로 확인한다. 한국어는 여유 있게 잡는다.

토큰 다음에 자연스럽게 이어지는 개념이 컨텍스트 윈도우와 LLM의 동작 원리다. 아래 글에서 이어서 보면 좋다.

• LLM이란 무엇인가
• AI 기초 용어 20개 정리
• Claude 요금제 비교

공식 문서 출처

• OpenAI - Understanding and counting tokens
• Anthropic - Token counting
• openai/tiktoken (GitHub)

클로드 듀엣은 "물어보면 답하는 AI"가 아니라 먼저 말을 걸어오는 AI다. 아침에 브리핑을 보내고, 하루 종일 연결된 앱을 살피다가, 네가 결정해야 할 것만 골라 알려준다.

2026년 10월 21일, Anthropic이 Claude Duet(클로드 듀엣) 리서치 프리뷰를 열었습니다. 새 모델이 아니라 새 앱입니다. 모델은 Claude Opus 5.5를 쓰고, 형태는 "채팅창"이 아니라 "비서"에 가깝습니다.

솔직히 저는 이게 지금까지 나온 AI 제품 중에서 가장 방향이 다른 물건이라고 봅니다. 성능이 얼마나 오르냐의 문제가 아니라, 누가 먼저 말을 거느냐가 바뀌었거든요. 이 글은 공식 발표문과 릴리스 노트를 기준으로, 뭐가 달라졌고 어디까지 쓸 수 있고 어디서 조심해야 하는지를 정리한 글입니다.

1. 한 줄 정의: "먼저 오는 에이전트"

Anthropic의 표현은 이렇습니다.

"Claude Duet, a new app where Claude works as a proactive agent. It comes to you with what needs your attention, completes tasks you ask of it, keeps working even when you step away, and checks with you before it acts on your behalf."

번역하면 — 네가 신경 써야 할 것을 먼저 가져오고, 시킨 일은 끝까지 해두고, 네가 자리를 비운 사이에도 계속 일하고, 대신 행동하기 전에는 반드시 확인한다.

기존 Claude 앱과 결정적으로 다른 지점은 첫 문장입니다. 지금까지 AI는 내가 창을 열고 질문을 던져야 움직였습니다. 듀엣은 반대로 아침에 먼저 브리핑을 보내고, 하루 중 필요한 순간에만 메시지를 보냅니다.

2. 하루가 어떻게 흘러가는가

공식 설명을 시간 순서로 풀면 이렇게 됩니다.

시점	듀엣이 하는 일	내가 하는 일
아침	연결된 앱들을 훑어 짧은 브리핑 발송	읽고 우선순위 조정
낮	몇 시간마다 연결 계정 점검, 필요할 때만 알림	알림에 짧게 답하거나 지시
작업 중	가상 머신의 브라우저로 백그라운드 실행	다른 일 하기
완료/판단 필요	결과 또는 승인 요청 알림	승인·수정·거절
저녁	밀린 일·결과 요약(활용 예시)	확인하고 마무리

핵심은 "몇 시간마다" 입니다. 24시간 감시가 아니라 주기적 점검이에요. Anthropic이 그렇게 설계한 이유도 명확합니다. 실시간 감시는 플랜 사용량을 훨씬 빨리 태우기 때문입니다. 이건 뒤에서 다시 다룹니다.

그리고 듀엣은 자기 브라우저가 달린 가상 머신에서 돌아갑니다. 내 노트북이 꺼져 있어도, 폰을 안 보고 있어도 작업이 계속된다는 뜻입니다. 예전 글에서 정리한 AI 에이전트의 동작 방식과 비교하면 "내 컴퓨터 안의 도구"에서 "내 밖의 일꾼"으로 넘어간 셈입니다.

3. 실제로 뭘 시킬 수 있나

발표문에 나온 예시는 꽤 구체적입니다. 업무용으로 설계됐다는 게 첫 줄부터 드러납니다.

• 놓친 Gmail·Slack 메시지를 찾아 답장 초안까지
• QuickBooks·Stripe에서 미납 인보이스 확인 후 독촉 메일 초안
• Gusto에서 근무시간·보너스·경비 채워 급여 실행 준비
• 채용 공고 초안 작성 → 내가 수정·승인 → LinkedIn 게시
• Docusign으로 계약서 검토·서명 요청 준비
• HubSpot의 거래 이력으로 팔로업 메일 작성
• 제품 출시를 Canva 소셜 캠페인으로 전환
• Shopify 스토어 세팅·디자인·관리
• 대시보드 제작, 재무·영업 예측, 프로토타이핑, 웹앱 제작

커넥터는 Claude Marketplace의 6,000개 이상을 쓴다고 합니다. 결제는 Stripe의 디지털 지갑 Link로 하고, 실제 카드번호 대신 가상 카드를 쓰는 구조입니다. Shopify의 Shop Pay도 지원하고, 1Password에 저장한 로그인으로 사이트 로그인까지 확장할 예정이라고 예고했습니다.

한마디로 "회사 업무의 잔손질" 을 정확히 겨냥했습니다. 개인 심부름(항공권 예약 같은 것)은 아직 약하다고 공식적으로 인정했습니다.

4. 안에서 일하는 사람들은 어떻게 쓰나

발표문에 실린 Anthropic 내부 사례가 오히려 제일 현실적입니다.

• Boris Cherny (Claude Code 리드): 산책하면서 머릿속 할 일 목록을 듀엣에게 말한다. 책상에 돌아와서 저장해두지 않아도 된다고.
• Chelsea Larsson (모델·제품 행동 설계 리드): 아이들 보러 가기 전에 할 일 목록을 넘기고, 저녁 리포트로 결과를 받는다.
• Karan Ahuja (Duet 팀 리드): 사용자 인터뷰 일정 잡기, 프로토타입 공동 작업, 코드 배포까지 시킨다.

재미있는 건 이 사람들이 "더 많이 일하려고" 쓰는 게 아니라는 점입니다. 일을 넘기고 비우는 용도로 쓰고 있어요. 이게 이 제품의 성격을 잘 보여줍니다.

5. 안전장치는 어디까지인가

에이전트 제품에서 제일 중요한 부분입니다. 듀엣은 "읽고·초안 쓰고·준비하는 것"은 혼자 하지만, 되돌릴 수 없는 행동은 승인 없이 못 합니다.

행동	듀엣 단독	내 승인 필요	아예 불가
메일·메시지 읽기, 초안 작성	가능	—	—
대시보드·예측·프로토타입 제작	가능	—	—
메시지 발송, 결제, 서명, 삭제	—	필요	—
증권 거래, 계좌 간 자금 이동	—	—	불가
카드번호·신분증 정보 전송	—	—	불가 (전용 분류기가 차단)
건강·개인 재무 정보 전송	—	명시적으로 지시한 경우만	—

기술적 근거도 공개했습니다. 자격증명은 Claude Managed Agents 설계를 따라 듀엣이 비밀번호·로그인 토큰을 직접 보지 않고, 행동 승인은 auto mode classifier가 판단하며, 숨은 지시·프롬프트 인젝션 방어는 브라우저 사용 연구에서 가져왔습니다.

여기에 전용 민감정보 분류기 + 안전 시스템 프롬프트를 새로 붙였습니다. 메일을 읽고 대신 메시지를 보내는 에이전트는 항상 "이 정보를 어디로 보내도 되는가"를 판단해야 하니까요. 레드팀과 외부 업체 모의해킹, 버그바운티까지 돌렸다고 밝혔습니다.

그래도 원칙은 하나입니다. 권한을 줬다고 책임이 넘어가지는 않는다. 결제·서명·삭제는 사람이 마지막에 본다.

6. 지금 당장 쓸 수 있나

• 형태: iOS·Android 독립 앱 + claude.ai
• 대상: Pro·Max 플랜 (리서치 프리뷰)
• 지역: 미국부터 시작, 대기자 명단(waitlist) 신청 후 초대
• 비용: 별도 요금 없음. 기존 플랜 사용량 한도를 Claude와 공유
• 모델: Claude Opus 5.5 기반

한도 공유가 은근히 중요한 포인트입니다. 듀엣의 백그라운드 점검도 내 사용량에서 빠져나갑니다. 큰 작업(재무 모델, 덱 제작)은 모델 턴을 많이 쓰니, 요금제 비교 글에서 정리한 것처럼 Max 쪽이 체감이 다를 겁니다.

한국은 아직 시작 지역이 아닙니다. Pro·Max를 쓰고 있다면 대기자 명단에 올려두고, 풀리면 Claude 사용법 글의 계정 구조 그대로 이어서 쓰면 됩니다.

7. Claude 앱·Cowork·Code와 뭐가 다른가

이름이 비슷해서 헷갈리는데, 역할이 다릅니다.

제품	시작점	강한 일	내 자리
Claude 앱(채팅)	내가 질문	대화·문서·리서치	내가 창을 연다
Claude Cowork	내가 작업 위임	보고서·스프레드시트·발표자료	채팅 안에서 모드 없이
Claude Code	터미널·IDE	코드베이스 수정·배포	개발자 책상
Claude Duet	Claude가 먼저	업무 감시·알림·백그라운드 실행	비서석

2026년 9월에 Cowork가 "모든 대화"로 통합되면서 채팅과 작업의 경계가 사라졌는데, 듀엣은 그 위에 "누가 먼저 말을 거는가" 라는 축을 하나 더 얹은 셈입니다. 모델 라인업 자체가 궁금하면 GPT·Gemini·Claude 비교 글을, 용어가 낯설면 AI 기초 용어 20개를 먼저 보시면 됩니다.

8. 아직 약한 점 5가지

공식 발표문이 스스로 인정한 한계입니다. 이걸 알고 쓰는 것과 모르고 쓰는 것의 차이가 큽니다.

1. 스레드를 잘못 읽을 수 있다 — 초기 버전이라 대화 맥락을 오해할 여지가 있음
2. 긴급도 판단이 어긋날 수 있다 — 뭐가 급한지 조율 중이라고 명시
3. 개인 심부름은 약하다 — 업무 중심 설계라 항공권 예약 같은 건 약함
4. 자기 브라우저 화면을 보여주지 못한다 — 지금 뭘 클릭하는지 볼 수 없음
5. 별도 앱이다 — 메인 Claude 앱과 아직 분리돼 있음 (앞으로 통합 방향은 실험 중)

특히 4번은 실무에서 체감이 큽니다. 뭔가 잘못됐을 때 어디서 틀어졌는지 볼 수 없다는 뜻이니까요. 그래서 초기에는 "결과물 검토가 쉬운 일"부터 맡기는 게 합리적입니다.

9. 도입한다면 이 순서로

권한 설계가 전부입니다. 한 번에 다 연결하지 마세요.

1. 읽기 전용부터 — 메일·캘린더·슬랙 읽기만 연결해서 브리핑 품질을 2주 관찰
2. 초안까지 — 답장·독촉·공고 초안을 만들게 하고, 내가 항상 검토 후 전송
3. 승인 게이트 유지 — 결제·서명·삭제는 계속 사람이 확인 (기본값이지만 습관이 중요)
4. 감사 로그 확인 — 어떤 앱에 어떤 권한을 줬는지 주기적으로 정리
5. 민감 정보 차단 확인 — 카드·신분증·건강 정보가 나가지 않는지 테스트

이 순서가 중요한 이유는, 에이전트 사고의 대부분이 "권한을 넓게 준 뒤 되돌릴 수 없는 행동" 에서 나오기 때문입니다. Anthropic이 아예 불가로 막아둔 항목(증권 거래, 계좌 이체)이 있는 것도 같은 맥락입니다.

10. 정리

• 클로드 듀엣은 새 모델이 아니라 새 앱이다. Opus 5.5 기반, Pro·Max 리서치 프리뷰, 미국 우선.
• 바뀐 건 기능 목록이 아니라 시작점이다. 내가 묻는 AI에서, 먼저 알려주는 AI로.
• 아직 초기다. 맥락 오판·브라우저 미표시·개인 심부름 약함은 감수하고, 읽기 → 초안 → 승인 순서로 권한을 좁게 열어야 한다.

3줄 요약하면 — 먼저 오는 비서, 업무 잔손질에 강함, 권한은 좁게 시작.

---

출처

• Introducing Claude Duet (Anthropic, 2026-10-21)
• Claude Release notes (2026-10-21)
• Our framework for trustworthy agents

AI 기초 용어 20개 정리 - 뉴스에 나오는 단어, 이제 다 알아듣기 (2026)

"토큰이 부족해서", "컨텍스트 윈도우가 커졌다", "RAG로 붙였다". AI 기사와 강의에는 같은 단어가 계속 나오는데, 한 번도 제대로 설명해 주는 사람이 없다. 그래서 처음부터 20개를 한 번에 정리한다.

이 글 하나만 읽으면 AI 관련 글을 읽을 때 모르는 단어 때문에 멈추는 일이 없어지도록 구성했다. 용어는 실제로 쓰는 순서(모델 → 토큰 → 학습 → 활용 → 한계)대로 묶었고, 헷갈리는 쌍은 따로 비교했다.

핵심 원칙 한 줄: 용어는 외우지 말고 "무엇이 부족할 때 나오는 말인지"로 기억한다.
토큰은 요금과 한도, 컨텍스트는 기억력, RAG는 자료실, 파인튜닝은 재교육이다. 이 네 가지 틀에 넣으면 20개가 한 번에 정리된다.

---

0) 30초 요약 - 가장 많이 헷갈리는 4개만 먼저

용어	한 줄 정의	없으면 생기는 일
토큰	모델이 글자를 세는 단위	요금 계산이 안 되고 길이 제한을 못 지킨다
컨텍스트 윈도우	한 번에 볼 수 있는 작업 기억	대화가 길어지면 앞부분을 잊는다
RAG	외부 자료를 검색해 프롬프트에 넣기	최신 정보·사내 문서를 답하지 못한다
파인튜닝	추가 데이터로 모델을 더 학습시키기	말투·형식을 프롬프트로만 맞춰야 한다

이 네 개가 AI 뉴스의 절반이다. 나머지 16개는 이 넷의 주변에 붙어 있다.

---

1) 모델 그 자체 - LLM, 파라미터, 오픈웨이트

1. LLM (거대언어모델)

Large Language Model. 다음에 올 토큰을 확률로 예측하는 신경망을, 인터넷 규모의 텍스트로 아주 크게 학습시킨 것이다. "생각한다"기보다 엄청나게 잘 이어 쓰는 모델이라고 이해하는 편이 정확하다. 자세한 동작 원리는 LLM이란 무엇인가에서 따로 정리했다.

2. 파라미터 (가중치)

모델 내부의 숫자 덩어리. 학습이 끝나면 이 숫자들이 고정되고, 그 숫자 조합이 곧 "모델"이다. 보통 7B, 70B처럼 개수로 표기한다.

• 파라미터 수 ↑ → 대체로 표현력·추론력 ↑, 하지만 메모리·비용 ↑
• 파라미터 수만으로 성능이 결정되지는 않는다. 학습 데이터 품질과 후처리 학습이 더 크게 작용한다.

3. 오픈웨이트 모델

가중치 파일을 내려받을 수 있는 모델. 로컬에서 돌릴 수 있어 비용·보안 면에서 유리하다. 반대로 가중치를 공개하지 않고 API로만 쓰게 하는 쪽은 클로즈드 모델이라 부른다.

오픈웨이트 → 내 노트북·서버에서 실행 가능 (메모리 필요)
클로즈드   → API 호출만 가능 (관리 편함, 데이터는 외부로)

4. 지식 컷오프

모델이 학습한 데이터의 마지막 시점. 그 이후 뉴스는 모델이 "모른다". 그래서 최신 정보가 필요한 질문에는 검색(RAG)이나 웹 도구가 붙는다.

---

2) 토큰과 비용 - 토큰, 토크나이저, 컨텍스트 윈도우, 프롬프트

5. 토큰

모델이 텍스트를 처리하는 단위. 공식 문서의 표현을 그대로 옮기면, 모델은 "자주 등장하는 문자 시퀀스" 덩어리인 토큰으로 텍스트를 처리한다.

" tokenization" → " token" + "ization"

즉 글자수도 단어수도 아닌 제3의 단위다. 요금, 속도, 길이 제한이 전부 토큰 기준이다.

6. 토크나이저

텍스트를 토큰으로 쪼개는 프로그램. 모델마다 쪼개는 방식이 달라서, 같은 문장도 모델마다 토큰 수가 다르다. 한국어는 영어보다 토큰 효율이 낮은 경우가 많아, 같은 내용이라도 토큰이 더 많이 나올 수 있다.

7. 컨텍스트 윈도우

모델이 한 번에 "볼 수 있는" 텍스트의 양. 공식 문서는 이를 모델의 작업 기억(working memory) 이라고 설명한다. 학습 데이터 전체와는 다른 개념이다.

상황	무슨 일이 생기나
대화가 윈도우를 넘음	앞부분이 잘리거나 요약된다
문서를 통째로 넣음	윈도우가 크면 가능, 대신 비용·지연 ↑
윈도우가 작음	긴 코드·긴 로그 분석이 어렵다

8. 프롬프트

모델에 주는 입력 전체. 질문 한 줄일 수도 있고, 지시문+예시+자료+출력형식이 붙은 긴 문서일 수도 있다. 프롬프트 설계는 사실상 모델을 프로그래밍하는 일에 가깝다.

9. 시스템 프롬프트

대화 시작 전에 고정으로 들어가는 지시문. "너는 한국어로 답하는 조수다" 같은 역할·규칙·금지사항을 담는다. 사용자가 매번 말하지 않아도 되는 기본값이라고 보면 된다.

[시스템] 역할·말투·금지사항·출력형식
[사용자] 실제 질문 + 참고자료
[모델]   응답

---

3) 학습과 튜닝 - 파인튜닝, 임베딩, 추론

10. 파인튜닝

이미 학습된 모델을 추가 데이터로 더 학습시키는 과정. 공식 문서의 정의대로 "사전학습된 모델을 추가 데이터로 더 훈련해, 그 데이터의 패턴을 모방하게 만드는 것" 이다.

• 잘 맞는 일: 말투·형식·분류 기준을 고정할 때
• 안 맞는 일: 최신 사실을 가르칠 때 (→ RAG가 낫다)
• 주의: 데이터 품질이 나쁘면 성능과 편향이 같이 나빠진다

11. 임베딩

텍스트를 숫자 벡터로 바꾼 것. 의미가 비슷한 문장은 벡터 공간에서 가까이 놓인다. 검색, 추천, 분류, 중복 탐지에 쓰이고, RAG의 검색 단계가 이걸로 돌아간다.

# 개념 예시: 문장 → 벡터 → 코사인 유사도
sim = cosine(embed("환불 규정"), embed("돈 돌려받는 방법"))
# sim이 높으면 의미가 비슷하다고 판단

12. 추론 (Reasoning)

답을 내기 전에 중간 단계를 거쳐 생각하는 능력, 또는 그런 동작에 특화된 모델 계열. 계산·논리·코드 디버깅처럼 단계가 필요한 문제에서 차이가 난다. 대신 토큰을 더 쓰고 느리다.

13. 벤치마크

모델 성능을 비교하는 시험 세트. 수학, 코딩, 상식 등 영역별로 있다. 숫자가 높다고 내 업무에 바로 좋은 것은 아니다. 벤치마크는 평균, 내 업무는 특수 케이스라서 직접 테스트가 최종 판단이다.

---

4) 활용 기술 - RAG, 툴 콜링, MCP, 에이전트

14. RAG (검색증강생성)

Retrieval-Augmented Generation. 질문이 오면 외부 자료에서 관련 부분을 먼저 검색해 프롬프트에 붙이고, 그걸 근거로 답하게 하는 방식.

질문 → 검색(임베딩) → 관련 청크 top-k → 프롬프트에 삽입 → 모델 응답

파인튜닝과의 차이는 명확하다.

항목	RAG	파인튜닝
목적	최신·사내 지식 주입	말투·형식·판단 기준 학습
자료 갱신	문서만 바꾸면 즉시 반영	재학습 필요
출처 표시	가능(인용)	어려움
비용	검색 인프라	학습 비용

15. 툴 콜링 (함수 호출)

모델이 "이건 내가 계산할 게 아니라 도구를 불러야겠다"고 판단해, 정해진 형식으로 함수 이름과 인자를 출력하는 기능. 실제 실행은 내 코드가 한다. 계산기, DB 조회, 날씨 API가 여기 붙는다.

16. MCP (Model Context Protocol)

AI 앱과 외부 도구·데이터를 연결하는 표준 규약. 도구마다 커넥터를 따로 만드는 대신, 같은 규약으로 붙이는 방식이다. 정확한 스펙은 공식 문서를 확인하는 게 안전하다.

17. AI 에이전트

목표를 주면 스스로 계획을 세우고, 도구를 호출하고, 결과를 보고 다음 행동을 정하는 시스템. 챗봇과의 차이는 한 번 답하고 끝나는가, 여러 단계를 스스로 반복하는가다.

목표 → 계획 → 도구 호출 → 결과 확인 → (실패면 수정) → 반복 → 종료

---

5) 한계와 조절 - 할루시네이션, 멀티모달, temperature

18. 할루시네이션 (환각)

모델이 사실이 아닌 내용을 그럴듯하게 만들어내는 현상. 원인은 "거짓말"이 아니라 다음 토큰을 확률로 이어 붙이는 구조에 있다. 대응은 세 가지다.

1. 근거 자료를 프롬프트에 넣는다(RAG)
2. "모르면 모른다고 답하라"를 시스템 프롬프트에 명시한다
3. 숫자·인용·링크는 원문에서 직접 확인한다

19. 멀티모달

텍스트 외에 이미지·음성·영상도 입력 또는 출력으로 다루는 능력. "이 스크린샷의 에러 원인"처럼 텍스트만으로는 불가능한 질문이 가능해진다.

20. temperature (온도)

출력의 무작위성을 조절하는 값. 낮으면 같은 질문에 비슷한 답(정확·일관), 높으면 다양한 답(창의·변동). 정리·추출·코드에는 낮게, 아이디어 발산에는 높게.

작업	권장	이유
정보 추출·요약·코드	낮게	형식과 정확성 유지
번역·교정	낮게	표현 흔들림 최소화
브레인스토밍·카피	높게	후보 다양성 확보

---

6) 20개 한 번에 보기

#	용어	영어	한 줄
1	거대언어모델	LLM	다음 토큰을 예측하는 큰 신경망
2	파라미터	parameters	모델 내부의 학습된 숫자
3	오픈웨이트	open weights	가중치를 내려받아 직접 실행
4	지식 컷오프	knowledge cutoff	학습 데이터의 마지막 시점
5	토큰	token	모델이 쓰는 텍스트 단위
6	토크나이저	tokenizer	텍스트를 토큰으로 쪼개는 도구
7	컨텍스트 윈도우	context window	한 번에 볼 수 있는 작업 기억
8	프롬프트	prompt	모델에 주는 입력 전체
9	시스템 프롬프트	system prompt	고정된 역할·규칙 지시문
10	파인튜닝	fine-tuning	추가 데이터로 더 학습
11	임베딩	embedding	의미를 담은 숫자 벡터
12	추론	reasoning	답 전에 단계적으로 생각
13	벤치마크	benchmark	성능 비교용 시험 세트
14	검색증강생성	RAG	검색 결과를 붙여 답하게 함
15	툴 콜링	tool calling	모델이 함수 호출을 지정
16	모델 컨텍스트 프로토콜	MCP	AI와 도구 연결 표준
17	AI 에이전트	agent	계획·도구·반복으로 목표 수행
18	환각	hallucination	사실 아닌 내용을 그럴듯하게 생성
19	멀티모달	multimodal	텍스트+이미지+음성 처리
20	온도	temperature	출력의 무작위성 조절

---

7) 헷갈리는 쌍 5개만 확실히

A	B	구분 한 줄
파인튜닝	RAG	능력을 바꾸는가 / 참고자료를 붙이는가
프롬프트	시스템 프롬프트	매번 주는 입력 / 고정된 규칙
컨텍스트 윈도우	학습 데이터	지금 보는 작업 기억 / 과거에 학습한 전체
토큰	단어	모델이 쓰는 조각 / 사람이 쓰는 단위
에이전트	챗봇	여러 단계를 스스로 반복 / 한 번 답하고 종료

이 표에서 두 개 이상 막히면, 해당 용어의 항목만 다시 읽으면 된다.

---

8) 다음에 읽을 글

• LLM이란 무엇인가 — 1번 용어의 확장판
• ChatGPT vs Claude 비교 — 모델 선택 기준
• AI 코딩 툴 비교 — 툴 콜링·에이전트의 실전 사례
• 클로드 사용법 — 프롬프트·시스템 프롬프트 실습
• 공식 문서: OpenAI Key concepts, Claude Glossary

---

정리 (3줄)

1. 토큰·컨텍스트·RAG·파인튜닝 네 개만 잡으면 AI 기사 대부분이 읽힌다.
2. 최신 지식은 RAG, 말투·형식은 파인튜닝, 태도·규칙은 시스템 프롬프트.
3. 숫자와 인용은 모델 말이 아니라 원문으로 확인한다. 그게 환각을 막는 유일한 습관이다.

ModuleNotFoundError 해결 - 원인 6가지와 상황별 해결법 (2026)

ModuleNotFoundError: No module named 'requests'

이 에러는 "모듈이 없다"고 말한다. 하지만 실제로 없는 경우는 생각보다 드물다. 대부분은 설치는 했는데 다른 파이썬에 설치했다, 패키지 이름과 import 이름이 다르다, 내 파일이 그 이름을 가로챘다 중 하나다.

이 글은 2026년 10월 기준으로, 이 에러를 만났을 때 에러 문구를 읽고 원인을 분류하는 순서로 정리했다. 위에서부터 따라가면 5분 안에 원인을 찾을 수 있다.

핵심 원칙 한 줄: pip install 대신 python3 -m pip install을 쓴다.
그리고 확인은 항상 python3 -c "import sys; print(sys.executable)"로 한다. 이 두 습관이면 이 에러의 90%는 다시 안 만난다.

---

0) 1분 진단 - 4줄이면 끝난다

에러가 났을 때 패키지부터 뒤지지 말고, 내 파이썬과 pip가 같은 곳을 보고 있는지부터 확인한다.

which -a python3
python3 -V
python3 -m pip -V
python3 -c "import sys; print(sys.executable)"

정상이라면 2번째 줄의 버전과 3번째 줄 끝의 (python 3.x)가 같고, 4번째 줄 경로가 1번째 줄의 첫 경로와 같아야 한다.

/opt/homebrew/bin/python3
Python 3.14.8
pip 26.1 from /opt/homebrew/lib/python3.14/site-packages/pip (python 3.14)
/opt/homebrew/bin/python3

이 네 줄이 서로 다른 파이썬을 가리키면, 원인은 거의 확정이다. 아래 2번 항목으로 바로 가면 된다.

에러 문구별로 어디를 보면 되는지는 이렇게 갈린다.

에러 문구	실제 원인	볼 항목
No module named 'requests' (설치는 했음)	다른 파이썬에 설치	2번
No module named 'cv2' (opencv 설치는 했음)	패키지명 ≠ import명	4번
No module named 'requests.sessions'	내 파일이 패키지를 가림	5번
No module named 'src' / 'app'	실행 경로·패키지 구조 문제	6번
터미널은 되는데 주피터·IDE만 실패	커널·인터프리터 불일치	7번
내 PC는 되는데 서버·도커만 실패	의존성 파일 누락	8번

---

1) 정말로 설치가 안 된 경우

가장 단순한 경우다. 먼저 설치 여부를 확인한다.

python3 -m pip show requests

WARNING: Package(s) not found가 나오면 진짜 없다. 설치한다.

python3 -m pip install requests

pip 명령 자체가 없어서 command not found가 나오는 경우는 pip를 복구한다.

python3 -m ensurepip --upgrade

여기서 error: externally-managed-environment가 뜨면, 그건 다른 문제다. Homebrew 파이썬처럼 시스템이 보호하는 환경(PEP 668)이라 전역 설치를 막는 것이다. 이때는 venv를 만드는 게 정답이다.

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install requests

전역 설치는 언젠가 반드시 충돌한다. 실습용이 아니라면 처음부터 venv 안에서 설치하는 습관이 좋다.

---

2) pip과 python이 다른 파이썬을 가리킬 때 (가장 흔함)

이게 이 에러의 진짜 주범이다. 증상은 명확하다.

• pip install requests는 성공했다
• 그런데 python3 main.py를 실행하면 No module named 'requests'
• pip list에도 requests가 보인다

이유는 간단하다. 설치한 pip와 실행한 python이 서로 다른 프로그램이다. macOS에는 파이썬이 여러 개 깔려 있기 일쑤다. 시스템 파이썬(/usr/bin/python3), Homebrew 파이썬(/opt/homebrew/bin/python3), pyenv, conda, Xcode 번들까지.

확인은 이렇게 한다.

python3 -m pip -V
python3 -c "import sys; print(sys.executable)"

두 경로의 파이썬 버전이 다르면 끝난다. 예를 들어 pip는 python 3.9인데 실행은 python 3.14라면, requests는 3.9 쪽에만 깔려 있다.

해결은 두 가지다.

첫째, 설치를 실행할 파이썬으로 한다. 이게 정석이다.

python3 -m pip install requests

python3 -m pip는 "지금 이 python3에 딸린 pip"를 뜻한다. PATH 순서가 어떻든 어긋날 수 없다.

둘째, PATH 순서를 정리한다. which -a python3 pip pip3로 전부 확인하고, 쓰지 않는 파이썬의 bin 경로를 PATH에서 빼거나, ~/.zshrc에서 Homebrew 경로를 앞에 둔다.

export PATH="/opt/homebrew/bin:$PATH"

윈도우는 py 런처로 버전을 지정하면 확실하다.

py -0p
py -3.12 -m pip install requests
py -3.12 main.py

pip와 pip3는 서로 다른 파이썬을 가리킬 수 있다. 이름만 보고 믿지 말고 -m pip를 쓴다.

---

3) 가상환경 밖에서 설치했거나, 활성화를 잊은 경우

venv를 만들어 놓고 활성화하지 않은 채 pip install을 하면, 설치는 전역 파이썬에 되고 실행은 venv에서 된다. 반대도 마찬가지다.

프롬프트 앞에 (.venv)가 붙어 있는지부터 본다.

which python
python -c "import sys; print(sys.prefix)"

sys.prefix가 프로젝트 폴더의 .venv를 가리켜야 한다. 아니라면 활성화한다.

source .venv/bin/activate      # macOS · Linux
.venv\Scripts\activate         # Windows

IDE의 내장 터미널은 자동으로 venv를 활성화하지 않는 경우가 많다. 터미널 탭을 새로 열면 풀리는 일도 흔하다. 의심되면 deactivate 후 다시 활성화한다.

venv 안에서는 python -m pip도 안전하다. python이 곧 venv의 파이썬이기 때문이다.

---

4) 패키지 이름과 import 이름이 다를 때

설치도 제대로 됐고 파이썬도 하나인데 안 된다면, 이름이 다른 경우다. 이건 에러가 아니라 규칙이다.

대표적인 것만 모으면 이렇다.

설치 명령	실제 import
pip install Pillow	import PIL
pip install opencv-python	import cv2
pip install beautifulsoup4	import bs4
pip install scikit-learn	import sklearn
pip install PyYAML	import yaml
pip install python-dateutil	import dateutil
pip install python-dotenv	import dotenv
pip install mysqlclient	import MySQLdb
pip install PyMuPDF	import fitz
pip install psycopg2-binary	import psycopg2
pip install python-telegram-bot	import telegram
pip install PyJWT	import jwt
pip install protobuf	import google.protobuf

이름이 기억나지 않을 때는 추측하지 말고 패키지에게 직접 물어본다. Python 3.10 이상이면 표준 라이브러리로 바로 확인할 수 있다.

from importlib.metadata import packages_distributions

d = packages_distributions()
print(d["cv2"])        # ['opencv-python']
print(d["sklearn"])    # ['scikit-learn']

반대 방향, 즉 "이 패키지가 어떤 모듈을 제공하는지"는 pip show -f로 본다.

python3 -m pip show -f opencv-python | head -20

출력의 top_level.txt 항목에 import 가능한 최상위 이름이 나온다.

---

5) 내 파일 이름이 모듈 이름을 가로챌 때

이건 정말 찾기 어려운 케이스다. 프로젝트 폴더에 requests.py라는 파일이 있으면, import requests는 설치된 패키지가 아니라 내 파일을 먼저 불러온다. 파이썬은 현재 디렉터리를 sys.path 맨 앞에 넣기 때문이다.

증상이 독특하다. 최상위 import는 통과하는데, 그 안의 하위 모듈에서 터진다.

ModuleNotFoundError: No module named 'requests.sessions'

내 requests.py에는 sessions라는 하위 모듈이 없으니 당연한 결과다. 확인은 이렇게 한다.

python3 -c "import requests; print(requests.__file__)"

출력이 site-packages가 아니라 내 프로젝트 폴더를 가리키면 범인이다.

절대 쓰면 안 되는 파일 이름은 표준 라이브러리와 겹치는 것들이다. random.py, json.py, email.py, token.py, types.py, queue.py, secrets.py, copy.py, platform.py, logging.py, uuid.py, test.py, select.py.

해결은 파일 이름을 바꾸는 것뿐이다. requests.py → my_requests.py처럼. 그리고 남은 캐시를 지운다.

find . -name "__pycache__" -type d -exec rm -rf {} +

이름을 바꿨는데도 계속 에러가 나면, .pyc 캐시가 남아 있는 경우가 많다. __pycache__ 삭제는 이 에러의 기본 청소 루틴이다.

---

6) 실행 방식 문제 - 스크립트 vs 모듈, 상대 import

프로젝트 구조가 잡혀 있을 때 자주 나온다.

myapp/
├── src/
│   ├── __init__.py
│   └── utils.py
└── main.py

main.py 안에서 from src import utils를 쓰고 python3 src/main.py로 실행하면 실패할 수 있다. 파이썬이 스크립트가 있는 src/를 기준으로 경로를 잡기 때문에, src라는 패키지 자체를 못 찾는다.

이때 나오는 에러는 두 가지다.

ModuleNotFoundError: No module named 'src'
ImportError: attempted relative import with no known parent package

해결은 실행 위치와 방식을 바꾸는 것이다. 프로젝트 루트에서 모듈로 실행한다.

python3 -m src.utils

패키지 구조라면 __init__.py가 있어야 하고, 배포까지 생각한다면 pyproject.toml을 만들고 편집 가능 모드로 설치하는 게 깔끔하다.

python3 -m pip install -e .

임시방편으로 PYTHONPATH를 쓰는 방법도 있다. 다만 이건 실행할 때마다 붙여야 하고, 나중에 배포에서 똑같은 문제가 재발한다.

PYTHONPATH=. python3 src/main.py

"내 컴퓨터에서만 되는 코드"의 대표 원인이 이 실행 방식이다. 처음부터 루트 기준 -m 실행으로 통일하는 편이 낫다.

---

7) IDE·주피터 커널이 다른 파이썬을 쓸 때

터미널에서는 잘 되는데 VS Code 실행 버튼이나 주피터 노트북에서만 실패한다면, 그 도구가 다른 인터프리터를 잡고 있는 것이다.

VS Code는 Cmd+Shift+P → Python: Select Interpreter에서 venv의 파이썬을 고른다. 고른 뒤에도 안 되면 VS Code를 재시작한다. 터미널 설정이 예전 경로를 캐시하는 경우가 있다.

PyCharm은 Settings → Project → Python Interpreter에서 확인한다.

주피터는 셀에서 직접 확인하는 게 가장 빠르다.

import sys
print(sys.executable)

여기에 venv 경로가 아니라 시스템 파이썬이 찍히면, 커널을 잘못 잡은 것이다. venv를 커널로 등록한다.

source .venv/bin/activate
python3 -m pip install ipykernel
python3 -m ipykernel install --user --name myenv --display-name "Python (myenv)"

그 다음 노트북에서 Kernel → Change Kernel로 Python (myenv)를 고른다.

---

8) 내 PC는 되는데 서버·도커에서만 실패할 때

로컬에는 우연히 깔려 있던 패키지가 서버에는 없는 경우다. 대표적으로 requirements.txt에 빠졌거나, 설치 단계가 이미지 빌드에서 누락된 경우다.

확인은 간단하다. 실제로 쓰는 패키지만 뽑아서 고정한다.

python3 -m pip freeze > requirements.txt

도커라면 설치 단계가 최종 이미지에 남아 있는지 본다. 멀티 스테이지 빌드에서 pip install을 빌더 단계에만 하고 복사하지 않으면, 실행 단계에는 패키지가 없다.

한 가지 더. 리눅스는 파일 이름의 대소문자를 구분한다. macOS에서 import MyModule로 잘 되던 코드가 서버에서 No module named 'MyModule'로 죽는다면, 실제 파일명이 mymodule.py인지 확인한다.

의존성 충돌까지 의심된다면 pip의 자체 검사를 돌린다.

python3 -m pip check

---

9) 그래도 안 될 때 - 5분 체크리스트

순서대로 실행하면 대부분 여기서 끝난다.

# 1. 지금 실행 중인 파이썬
python3 -c "import sys; print(sys.executable)"

# 2. 그 파이썬의 pip
python3 -m pip -V

# 3. 설치 여부
python3 -m pip show requests

# 4. 실제로 불러온 파일 위치
python3 -c "import requests; print(requests.__file__)"

# 5. 이름 충돌 파일 검색
ls | grep -i requests

# 6. 탐색 경로 확인
python3 -c "import sys; print('\n'.join(sys.path))"

# 7. venv 활성화 여부
python3 -c "import sys; print(sys.prefix)"

4번에서 site-packages가 아닌 경로가 나오면 5번(이름 충돌), 3번에서 못 찾으면 2번(다른 파이썬), 7번이 .venv가 아니면 3번(venv)이다.

마지막 수단은 캐시를 버리고 깨끗하게 재설치하는 것이다.

python3 -m pip install --force-reinstall --no-cache-dir requests

---

10) 자주 하는 오해

"pip install은 성공했는데 왜 없다고 하지?"

거의 항상 다른 파이썬이다. 2번 항목의 두 줄만 확인하면 판정된다.

"ModuleNotFoundError랑 ImportError는 뭐가 달라?"

ModuleNotFoundError는 ImportError의 하위 클래스다(Python 3.6+). 모듈 자체를 못 찾으면 전자, 모듈은 찾았는데 그 안의 이름이 없으면 후자다. from requests import gett 같은 오타는 ImportError로 나온다. 즉 처리 코드에서는 ImportError 하나만 잡아도 둘 다 커버된다.

"--user로 설치했는데 sudo로 실행하면 왜 안 보이지?"

--user는 사용자별 site-packages에 설치한다. sudo로 실행하면 root 사용자가 되어 다른 경로를 본다. 애초에 sudo로 파이썬을 실행하지 않는 게 좋다.

"site-packages 폴더를 복사하면 안 되나?"

안 된다. 바이너리 확장은 파이썬 버전과 플랫폼에 묶여 있어서, 복사하면 import 단계에서 깨진다. 반드시 그 환경의 pip로 설치한다.

"conda 환경인데 pip로 설치해도 되나?"

된다. 다만 conda로 설치한 패키지와 pip로 설치한 패키지가 같은 이름으로 겹치면 조용히 깨질 수 있다. 한 환경 안에서는 가급적 한쪽으로 통일한다.

---

정리

ModuleNotFoundError는 "설치해라"라는 뜻이 아니다. "네가 생각하는 그 파이썬에, 네가 생각하는 그 이름으로, 없더라"라는 뜻이다. 그래서 순서가 중요하다.

1. python3 -m pip -V와 sys.executable이 같은지 확인한다
2. 다르면 python3 -m pip install로 설치한다
3. 같으면 패키지명과 import명이 다른지 확인한다
4. 그래도 안 되면 같은 이름의 내 파일이 있는지 찾는다

이 네 단계면 이 에러로 한 시간을 태우는 일은 없을 것이다. 파이썬 자체를 처음 세팅하는 중이라면 Python 설치 (Mac) 2026 - Homebrew로 5분 만에 끝내기를 먼저 보는 게 빠르고, 설치 단계에서 나는 다른 에러들은 pip install 오류 해결 - 자주 나는 에러 10개와 원인별 해결법에 정리해 두었다. 파이썬이 실제로 무엇을 하는 프로그램인지 궁금하다면 LLM이란 무엇인가처럼 개념부터 잡는 글도 도움이 된다.

참고

• Python 공식 문서 - import 시스템
• importlib.metadata - packages_distributions
• pip 문서 - 외부 관리 환경(PEP 668)

Python 설치 (Mac) 2026 - Homebrew로 5분 만에 끝내기

맥에서 파이썬을 처음 설치하면 대부분 같은 지점에서 막힌다. python을 쳤는데 command not found가 뜨거나, 설치를 했는데 pip가 없다고 하고, 어떤 글은 Homebrew를 쓰라 하고 어떤 글은 공식 인스톨러를 쓰라고 한다.

결론부터 정리하면 이렇다.

초보·입문자는 Homebrew로 설치하고, 프로젝트는 venv로 격리한다. 실무에서 여러 프로젝트를 오가면 uv를 쓴다.

이 글은 2026년 10월 기준 macOS에서 파이썬을 설치하는 가장 덜 험한 경로와, 설치 후 반드시 만나는 오류 5가지를 한 번에 정리한다.

---

1) 맥에는 파이썬이 이미 있다. 그런데 왜 또 설치하나

터미널을 열고 확인해보자.

python3 --version

대부분 Python 3.9.6 같은 값이 나온다. 이건 애플이 Xcode Command Line Tools에 넣어둔 시스템 파이썬이다.

문제는 세 가지다.

1. 버전이 낡았다. 2026년 10월 현재 최신은 Python 3.15.0(2026-10-09 출시)이고, 3.13·3.14가 실무 주력이다. 3.9는 2025년 10월에 보안 지원이 끝났다.
2. 건드리면 안 된다. 시스템 도구가 이 파이썬을 쓴다. 여기에 패키지를 막 깔면 macOS 업데이트나 개발 도구가 꼬인다.
3. pip 설치가 막혀 있다. 최근 파이썬은 시스템 영역에 패키지를 설치하지 못하도록 잠가둔다(externally-managed-environment).

그래서 내가 쓰는 파이썬을 따로 설치한다. 시스템 파이썬은 그대로 두고, 그 위에 새로 까는 것이다.

---

2) 설치 방법 3가지, 뭘 고르면 되나

방법	명령	장점	단점	추천
공식 인스톨러	python.org에서 .pkg 다운로드	클릭 몇 번, 초보자 친화적	업데이트·버전 관리가 번거롭다	입문 첫날만
Homebrew	brew install python	업데이트·삭제가 쉽고 다른 도구와 일관적	Homebrew 자체를 먼저 설치해야 한다	기본 추천
uv	brew install uv	압도적으로 빠르고 버전·가상환경을 한 도구로 관리	명령이 조금 다르다	실무·다중 프로젝트

정리하면 Homebrew로 파이썬을 설치하고, 가상환경은 venv(또는 uv) 조합이 가장 무난하다.

---

3) Homebrew로 설치하기 (5분)

3-1. Homebrew 먼저 설치

터미널에 아래 한 줄을 붙여넣는다.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

설치가 끝나면 안내 문구에 따라 PATH를 잡아준다. 요즘 버전은 안내에 나오는 두 줄을 그대로 복사하면 된다.

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

칩에 따라 경로가 다르다. Apple Silicon(M1~M4)은 /opt/homebrew, Intel 맥은 /usr/local이다. 설치 마지막에 출력되는 안내가 정답이니 그걸 따르면 된다.

확인:

brew --version

3-2. 파이썬 설치

brew install python

이 명령은 Homebrew가 관리하는 최신 안정 버전을 설치한다. 2026년 10월 기준 3.14 계열이 잡히는 경우가 많다. 특정 버전이 필요하면 버전을 지정한다.

brew install python@3.14
brew install python@3.15

3-3. 설치 확인

python3 --version
which python3

/opt/homebrew/bin/python3 또는 /usr/local/bin/python3가 나오면 성공이다. 시스템 파이썬(/usr/bin/python3)이 나온다면 PATH 순서가 잘못된 것이니 3-1의 shellenv 설정을 다시 확인한다.

---

4) python이 아니라 python3인 이유

맥에서 python을 치면 이렇게 나온다.

zsh: command not found: python

파이썬 2와 3이 공존하던 시절의 유산이다. 지금은 python이라는 이름을 아무도 보장해주지 않는다. 해결은 두 가지다.

방법 1 — 그냥 python3를 쓴다 (가장 안전)

python3 --version
python3 -m pip --version

방법 2 — python으로도 부르고 싶다면 별칭을 만든다

echo 'alias python=python3' >> ~/.zshrc
echo 'alias pip=pip3' >> ~/.zshrc
source ~/.zshrc

강의·블로그 예제가 python으로 적혀 있어도, 실제로는 python3로 실행하면 거의 그대로 동작한다. 습관은 python3가 낫다.

---

5) pip는 python3 -m pip로 쓰는 습관

pip install requests는 위험할 수 있다. 내가 쓰는 파이썬이 아니라 다른 파이썬에 설치되는 사고가 흔하다. 아래 형태를 권한다.

python3 -m pip install --upgrade pip
python3 -m pip install requests

python3 -m pip는 "이 파이썬의 pip" 를 정확히 지정한다. 어느 파이썬에 깔렸는지 헷갈리는 일이 사라진다.

---

6) 가상환경(venv): 프로젝트마다 방을 따로

파이썬을 하나만 설치해도, 프로젝트마다 필요한 패키지 버전은 다르다. A 프로젝트는 pandas 2.x, B 프로젝트는 1.x를 쓸 수 있다. 이걸 한 곳에 다 깔면 반드시 충돌한다.

그래서 프로젝트 폴더마다 가상환경을 만든다.

mkdir myproject && cd myproject
python3 -m venv .venv
source .venv/bin/activate

프롬프트 앞에 (.venv)가 붙으면 활성화된 상태다. 이 상태에서 설치하면 그 폴더 안에만 깔린다.

python -m pip install requests
python -m pip freeze > requirements.txt

나갈 때는:

deactivate

다음에 다시 들어올 때는 source .venv/bin/activate만 실행하면 된다.

.venv 폴더는 Git에 올리지 않는다. .gitignore에 .venv/를 추가하면 된다. 남에게는 requirements.txt로 환경을 전달한다.

---

7) uv: 2026년 실무의 기본값이 되고 있는 도구

uv는 파이썬 패키지·가상환경·버전 관리까지 한 번에 처리하는 도구다. 체감 속도가 pip보다 훨씬 빠르고, 프로젝트마다 파이썬 버전까지 고정할 수 있다.

설치:

brew install uv

프로젝트 시작:

uv init myproject
cd myproject
uv add requests
uv run python main.py

uv add는 패키지를 설치하면서 pyproject.toml과 uv.lock에 기록한다. uv run은 가상환경을 알아서 맞춰 실행한다. activate를 깜빡해서 생기는 사고가 줄어든다.

특정 파이썬 버전을 쓰고 싶다면:

uv python install 3.14
uv venv --python 3.14

입문 단계에서 uv까지 한 번에 배우면 혼란스러울 수 있다. 처음엔 Homebrew + venv, 익숙해지면 uv 순서를 권한다.

---

8) 설치 후 반드시 만나는 오류 5개

① command not found: python

python3를 쓰거나 별칭을 만든다. (4번 항목)

② xcode-select: error: unable to get active developer directory

Command Line Tools가 없거나 경로가 깨진 경우다.

xcode-select --install

그래도 안 되면:

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

③ error: externally-managed-environment

Homebrew 파이썬은 시스템 영역 설치를 막아둔다. 정상 동작이다.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install 패키지명

가상환경 안에서 설치하면 해결된다. --break-system-packages는 최후의 수단이고 권하지 않는다.

④ pip: command not found

python3 -m ensurepip --upgrade
python3 -m pip --version

그래도 없으면 brew install python으로 다시 설치하는 편이 빠르다.

⑤ SSL 인증서 오류 (CERTIFICATE_VERIFY_FAILED)

python.org 인스톨러로 설치한 경우에 자주 나온다. 파인더에서 아래 파일을 실행하면 인증서가 설치된다.

/Applications/Python\ 3.15/Install\ Certificates.command

버전에 맞는 폴더명으로 바꿔 실행하면 된다. Homebrew 설치에서는 거의 발생하지 않는다.

---

9) VS Code와 연결하기

1. VS Code에서 확장 Python(Microsoft)을 설치한다.
2. 프로젝트 폴더를 연다.
3. Cmd + Shift + P → Python: Select Interpreter → .venv 안의 파이썬을 고른다.
4. 터미널에서 source .venv/bin/activate 후 python main.py로 실행한다.

인터프리터를 잘못 고르면 "패키지를 설치했는데 import가 안 된다"는 상황이 생긴다. VS Code 오른쪽 아래에 표시되는 파이썬 경로가 .venv인지 항상 확인하자.

---

10) 어떤 버전을 설치할까 (2026년 10월 기준)

버전	상태	추천
3.15	2026-10-09 출시, 최신	새 프로젝트·학습용
3.14	2025-10 출시, 안정	실무 기본 추천
3.13	2024-10 출시, 안정	라이브러리 호환 최우선
3.12 이하	구버전	기존 프로젝트 유지보수

라이브러리 생태계는 최신 버전을 바로 따라오지 않는다. 특별한 이유가 없다면 한 단계 뒤의 안정 버전(3.14) 이 사고가 적다.

---

11) 자주 묻는 질문

Q. Homebrew랑 python.org 인스톨러를 둘 다 설치해도 되나?

권하지 않는다. 같은 이름의 파이썬이 두 개 생겨 PATH가 꼬인다. 하나만 쓰자.

Q. sudo pip install은 왜 안 되나?

시스템 파이썬을 오염시킨다. 꼭 필요하면 가상환경을 만들자.

Q. 회사 맥에서 Homebrew 설치가 막혀 있다.

python.org 인스톨러로 설치하고, 프로젝트마다 venv를 쓰면 된다. 원리는 같다.

Q. 파이썬을 지우고 싶다.

Homebrew라면 brew uninstall python, 가상환경은 폴더 삭제로 끝난다. 시스템 파이썬은 지우지 말자.

---

정리: 오늘 할 일 체크리스트

• ☐ Homebrew 설치 (brew --version 확인)
• ☐ brew install python 실행
• ☐ python3 --version으로 버전 확인
• ☐ 프로젝트 폴더에서 python3 -m venv .venv
• ☐ source .venv/bin/activate 후 python -m pip install
• ☐ VS Code 인터프리터를 .venv로 선택

설치 자체는 5분이면 끝난다. 시간이 걸리는 건 그다음이다. 파이썬으로 무엇을 할지 정하는 게 진짜 시작이다. AI를 업무에 붙이는 쪽이라면 LLM이란 무엇인가부터 읽고, 코딩 도구를 고민 중이라면 AI 코딩 툴 비교를 함께 보면 좋다.

pip install 오류 해결 - 자주 나는 에러 10개와 원인별 해결법 (2026)

pip install requests 한 줄이 안 될 때, 대부분은 패키지가 없어서가 아니다. 어느 파이썬에 설치하려는지, 어디에 설치하려는지, 무엇을 설치하려는지 이 세 가지 중 하나가 어긋난 것이다.

이 글은 2026년 10월 기준으로 실제로 가장 자주 만나는 pip 오류 10개를 증상별로 정리한다. 각 항목은 에러 문구 → 원인 → 해결 명령 순서다. 급하면 아래 진단 3줄부터 실행하면 된다.

핵심 원칙 한 줄: pip install 대신 python3 -m pip install을 쓴다.
이 한 가지만 지켜도 절반의 오류가 사라진다.

---

0) 먼저 3줄로 진단하기

오류가 났을 때 가장 먼저 확인할 것은 패키지가 아니라 내 파이썬과 pip의 정체다.

which -a python3 pip pip3
python3 -V
python3 -m pip -V

python3 -m pip -V의 출력에는 그 pip가 어느 파이썬에 속해 있는지 경로가 나온다.

pip 26.x from /opt/homebrew/lib/python3.14/site-packages/pip (python 3.14)

여기서 python 3.14와 python3 -V의 버전이 다르면, 지금까지 엉뚱한 곳에 설치하고 있었던 것이다. 이 경우 아래 1번과 8번이 원인이다.

---

1) pip: command not found / 'pip'은(는) 내부 또는 외부 명령이 아닙니다

증상

zsh: command not found: pip

원인

• pip가 PATH에 없다.
• pip는 설치됐지만 pip3라는 이름만 있다.
• (윈도우) Python 설치 시 Add Python to PATH를 체크하지 않았다.

해결

가장 확실한 방법은 이름 대신 모듈로 실행하는 것이다. PATH 문제를 우회한다.

python3 -m pip --version

윈도우는 py 런처를 쓴다.

py -m pip --version

python3 -m pip도 없다면 pip 자체가 없는 것이므로 복구한다.

python3 -m ensurepip --upgrade

pip3는 python3의 pip라는 뜻일 뿐, 별개 프로그램이 아니다. pip와 pip3가 서로 다른 파이썬을 가리키는 경우도 흔하다. 그래서 항상 python3 -m pip가 안전하다.

---

2) error: externally-managed-environment (PEP 668)

증상

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try brew install
    xyz, where xyz is the package you are trying to install.

원인

Homebrew나 배포판이 관리하는 파이썬은 시스템 영역에 패키지를 설치하지 못하도록 잠겨 있다(PEP 668). macOS Homebrew 파이썬은 3.12부터 이 보호가 기본 적용된다. 버그가 아니라 의도된 안전장치다. 시스템 파이썬을 오염시켜 다른 도구가 깨지는 사고를 막는다.

해결 — 상황에 따라 3가지

① 프로젝트용 패키지 → 가상환경 (가장 정석)

cd myproject
python3 -m venv .venv
source .venv/bin/activate
python -m pip install requests

프롬프트 앞에 (.venv)가 붙으면 성공이다. 이 안에서는 자유롭게 설치된다.

② CLI 도구 → pipx

black, yt-dlp, poetry처럼 명령어로 쓰는 프로그램은 pipx가 맞다. 각 도구를 독립된 환경에 설치하고 실행 파일만 PATH에 노출한다.

brew install pipx
pipx ensurepath
pipx install black

③ 정말 시스템 전역에 필요할 때 (최후의 수단)

python3 -m pip install --break-system-packages 패키지명

--break-system-packages는 이름 그대로 보호장치를 끄는 옵션이다. Homebrew 업데이트와 충돌할 수 있으니, ①이나 ②로 해결되지 않는 특수한 경우에만 쓴다.

sudo pip install은 어떤 경우에도 답이 아니다. 권한 문제를 덮을 뿐, 원인은 그대로 남는다.

---

3) PermissionError: [Errno 13] Permission denied

증상

ERROR: Could not install packages due to an OSError:
[Errno 13] Permission denied: '/usr/local/lib/python3.11/site-packages/...'

원인

시스템이 소유한 디렉터리에 쓰려고 했다. 앞 항목과 뿌리가 같다.

해결

# 1순위: 가상환경
python3 -m venv .venv && source .venv/bin/activate
python -m pip install 패키지명

# 2순위: 사용자 디렉터리에만 설치 (시스템 파이썬을 써야 하는 경우)
python3 -m pip install --user 패키지명

sudo를 붙이면 당장은 되지만, 이후 그 패키지를 일반 사용자로 업데이트할 때 다시 권한 오류가 나고 삭제도 어려워진다. sudo pip는 빚을 만드는 일이다.

---

4) SSL: CERTIFICATE_VERIFY_FAILED

증상

Could not fetch URL https://pypi.org/simple/requests/:
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: unable to get local issuer certificate'))

원인

• python.org 인스톨러로 설치한 macOS 파이썬에 루트 인증서가 연결되지 않았다. (가장 흔함)
• 회사 프록시가 HTTPS를 가로채는데 그 인증서를 파이썬이 모른다.
• 시스템 날짜/시간이 크게 틀어졌다.

해결 ① — macOS 공식 인스톨러 사용자

파인더에서 해당 버전 폴더의 인증서 스크립트를 실행한다. 터미널에서는 아래처럼 버전만 맞춰 실행하면 된다.

/Applications/Python\ 3.15/Install\ Certificates.command

해결 ② — 회사 프록시 환경

사내 루트 인증서 파일(.pem)을 지정한다.

export SSL_CERT_FILE=/path/to/company-root.pem
export REQUESTS_CA_BUNDLE=/path/to/company-root.pem

pip 전용으로 고정하려면 설정 파일에 넣는다.

python3 -m pip config set global.cert /path/to/company-root.pem

해결 ③ — 임시 우회 (권장하지 않음)

python3 -m pip install --trusted-host pypi.org --trusted-host files.pythonhosted.org 패키지명

--trusted-host는 검증을 끄는 것이므로, 원인을 고친 뒤에는 반드시 제거한다.

Homebrew 파이썬은 인증서가 함께 관리되어 이 오류가 거의 없다. SSL 오류가 반복된다면 설치 경로 자체를 Homebrew로 바꾸는 것도 방법이다. (설치법은 Python 설치 (Mac) 참고)

---

5) Could not find a version that satisfies the requirement / No matching distribution found

증상

ERROR: Could not find a version that satisfies the requirement pandas==9.9.9
ERROR: No matching distribution found for pandas==9.9.9

원인은 4가지 중 하나다.

1. 패키지명 오타 — reqeusts, beautifulSoup 같은 실수. pip는 대소문자를 구분하지 않지만 철자는 구분한다.
2. 존재하지 않는 버전 — ==9.9.9처럼 없는 버전을 지정.
3. 내 파이썬 버전과 호환되지 않음 — 최신 파이썬(3.15)에 아직 wheel이 없는 패키지가 대표적이다. Requires-Python 조건에 걸린다.
4. 내 OS/칩에 맞는 배포본이 없음 — Apple Silicon(arm64)용 wheel이 없어 소스 빌드로 넘어가다 실패하는 경우.

해결

# 1. 정확한 이름과 사용 가능한 버전 확인
python3 -m pip index versions 패키지명

# 2. 버전 제약을 풀고 설치
python3 -m pip install 패키지명

# 3. 최신 파이썬이 원인이면 한 단계 낮은 버전 사용
brew install python@3.14
python3.14 -m venv .venv

패키지의 지원 파이썬 범위는 PyPI 페이지의 Requires: Python 항목에서 확인할 수 있다. "최신 파이썬 = 최고"가 아니다. 라이브러리 생태계는 보통 한 단계 뒤처져 있다.

내 플랫폼 정보를 직접 확인하려면:

python3 -c "import platform,sys; print(sys.version); print(platform.machine(), platform.system())"
python3 -m pip debug --verbose | head -20

pip debug는 이 환경에서 허용되는 wheel 태그 목록을 보여준다. "왜 내 환경엔 없다고 하지?"를 판단할 때 유용하다.

---

6) error: subprocess-exited-with-error / Failed building wheel

증상

error: subprocess-exited-with-error
× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> [ ... gcc: error ... ]
ERROR: Failed building wheel for 패키지명

원인

순수 파이썬 패키지는 wheel 파일을 그대로 받아 설치한다. 하지만 C/C++ 확장이 있는 패키지는 내 컴퓨터에서 컴파일해야 하고, 이때 컴파일러나 헤더 파일이 없으면 실패한다. macOS에서 Xcode Command Line Tools가 없는 경우가 대표적이다.

해결

# 1. 컴파일 도구 설치 (macOS)
xcode-select --install

# 2. 빌드 도구 최신화 — 의외로 자주 이걸로 해결된다
python3 -m pip install --upgrade pip setuptools wheel

# 3. 네이티브 라이브러리가 필요한 패키지는 Homebrew로 먼저 설치
brew install openssl readline sqlite3 xz zlib

그래도 안 되면 wheel이 제공되는 버전으로 낮추는 것이 빠르다. 최신 버전이 소스 배포만 제공하는 경우가 있다.

python3 -m pip install "패키지명==사용가능한버전"

윈도우라면 Visual Studio Build Tools가 필요하다. 다만 윈도우는 대부분 wheel이 제공되므로, 빌드까지 가는 경우는 드물다.

---

7) ReadTimeoutError / ConnectionResetError / 설치가 중간에 멈춤

증상

pip._vendor.urllib3.exceptions.ReadTimeoutError:
HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out.

원인

네트워크가 느리거나, 사내 방화벽·프록시가 연결을 끊거나, PyPI가 일시적으로 느린 경우다. 패키지가 크면(예: torch, tensorflow) 기본 타임아웃으로는 부족하다.

해결

python3 -m pip install --timeout 60 --retries 5 패키지명

프록시 환경이면 지정한다.

export HTTPS_PROXY=http://proxy.company.com:8080
export HTTP_PROXY=http://proxy.company.com:8080

이미 받은 파일을 재사용하면 재시도가 빨라진다. pip는 기본적으로 캐시를 쓰지만, 강제로 캐시를 활용하려면:

python3 -m pip install --cache-dir ~/.cache/pip 패키지명

사내 미러가 있다면 인덱스를 바꾸는 편이 근본적이다.

python3 -m pip config set global.index-url https://pypi.org/simple
python3 -m pip config list

pip config list로 기존 설정을 먼저 확인하자. 예전에 잘못 넣은 인덱스나 프록시 설정이 남아 있어서 오류가 나는 경우도 많다.

---

8) 설치했는데 ModuleNotFoundError: No module named '...'

증상

>>> import requests
ModuleNotFoundError: No module named 'requests'

pip install requests는 분명히 성공했다고 나왔다.

원인 ① — 다른 파이썬에 설치됐다 (가장 흔함)

pip와 실행 중인 파이썬이 서로 다른 경우다.

python3 -m pip -V          # pip가 속한 파이썬 경로 확인
python3 -c "import sys; print(sys.executable)"   # 실행 중인 파이썬 경로

두 경로의 파이썬 버전이 다르면 원인이 확정이다. 해결은 간단하다. 설치도 실행도 같은 파이썬으로 하면 된다.

python3 -m pip install requests
python3 -c "import requests; print(requests.__version__)"

원인 ② — 패키지명과 import명이 다르다

이건 오류가 아니라 규칙이다. 설치 이름과 코드에서 부르는 이름이 다른 패키지가 많다.

설치 명령	코드에서 import
pip install Pillow	import PIL
pip install opencv-python	import cv2
pip install scikit-learn	import sklearn
pip install beautifulsoup4	import bs4
pip install PyYAML	import yaml
pip install python-dateutil	import dateutil
pip install python-docx	import docx
pip install psycopg2-binary	import psycopg2

원인 ③ — VS Code가 다른 인터프리터를 쓰고 있다

터미널에서는 되는데 VS Code 실행만 안 된다면 십중팔구 이것이다. Cmd + Shift + P → Python: Select Interpreter에서 .venv 안의 파이썬을 고른다. 오른쪽 아래 상태바에 표시된 경로가 .venv인지 확인하면 끝난다.

---

9) ResolutionImpossible / 의존성 충돌

증상

ERROR: Cannot install A and B because these package versions have conflicting dependencies.
The conflict is caused by:
    The user requested numpy==2.1.0
    pandas 2.2.0 depends on numpy>=1.26.0
ERROR: ResolutionImpossible

원인

한 패키지가 요구하는 라이브러리 버전과 다른 패키지가 요구하는 버전이 서로 맞지 않는다. 오래된 프로젝트에 새 패키지를 얹을 때 자주 난다.

해결

# 1. 현재 상태 진단
python3 -m pip check

# 2. 충돌하는 패키지만 범위로 묶어서 설치
python3 -m pip install "numpy>=1.26,<2.2" "pandas==2.2.0"

# 3. 기존 패키지까지 함께 갱신
python3 -m pip install --upgrade --upgrade-strategy eager 패키지명

그래도 안 되면 가상환경을 새로 만드는 것이 가장 빠르다. 오염된 환경을 고치는 데 드는 시간이 더 비싼 경우가 많다.

deactivate
rm -rf .venv
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

requirements.txt 없이 pip install을 반복하다 보면 이 상황이 반드시 온다. 프로젝트를 시작할 때 python -m pip freeze > requirements.txt를 습관으로 만들자.

---

10) No space left on device / [Errno 28]

증상

OSError: [Errno 28] No space left on device

원인

pip 캐시와 임시 파일이 디스크를 채웠다. 큰 패키지(torch 등)를 여러 번 재설치하면 캐시가 수 GB까지 쌓인다.

해결

# pip 캐시 크기와 위치 확인
python3 -m pip cache dir
python3 -m pip cache info

# 캐시 비우기
python3 -m pip cache purge

# 디스크 확인
df -h

임시 디렉터리를 다른 곳으로 돌리는 방법도 있다.

export TMPDIR=~/tmp
mkdir -p ~/tmp

sudo로 캐시를 지우면 소유권이 꼬일 수 있다. 캐시는 항상 현재 사용자로 지운다.

---

예방 체크리스트 5가지

• ☐ 설치 전에 python3 -m pip -V로 pip의 주인을 확인한다
• ☐ 프로젝트마다 .venv를 만들고 활성화한 뒤 설치한다
• ☐ pip install 대신 python3 -m pip install을 쓴다
• ☐ 설치 후 python3 -m pip freeze > requirements.txt로 기록한다
• ☐ sudo pip는 쓰지 않는다

이 다섯 줄이면 이 글의 오류 10개 중 7개는 애초에 발생하지 않는다.

---

자주 묻는 질문

Q. pip 자체는 어떻게 업데이트하나?

python3 -m pip install --upgrade pip

pip install --upgrade pip도 되지만, 위 형태가 어느 파이썬인지 명확하다.

Q. pip와 pip3 중 뭘 써야 하나?

둘 다 python3 -m pip의 별칭일 뿐이다. 다만 환경에 따라 서로 다른 파이썬을 가리킬 수 있으므로 python3 -m pip를 권한다.

Q. 요즘은 uv를 쓴다고 하던데, pip를 몰라도 되나?

uv는 빠르고 편하지만, 오류 메시지를 읽고 원인을 찾는 능력은 pip 경험이 더 잘 길러준다. 입문은 pip + venv, 익숙해지면 uv 순서를 권한다. uv도 내부적으로 같은 PyPI를 쓰기 때문에 여기서 배운 원인 분류는 그대로 통한다.

Q. 회사 보안 정책상 PyPI가 막혀 있다.

사내 미러를 쓰거나, 오프라인 환경이라면 wheel 파일을 직접 받아 pip install 파일.whl로 설치한다. 이 경우에도 파이썬 버전과 플랫폼 태그가 맞아야 한다.

Q. --break-system-packages를 써도 되나?

가능하면 쓰지 않는다. 꼭 필요하면 무엇이 왜 필요한지 기록해두고, 나중에 가상환경으로 옮기는 계획을 세우자.

---

정리: 오류를 만났을 때 순서

1. 에러 문구의 마지막 3줄을 읽는다. pip는 원인을 마지막에 알려준다.
2. python3 -m pip -V로 pip의 주인을 확인한다.
3. 분류한다 — 못 찾음 / 권한·환경 / 인증서 / 네트워크 / 버전·빌드 / import / 의존성.
4. 분류에 맞는 항목으로 돌아간다.
5. 해결 후 python3 -m pip check와 실제 import로 검증한다.

pip 오류는 대부분 "패키지가 없어서"가 아니라 "내 환경을 잘못 알고 있어서" 생긴다. 환경을 먼저 확인하는 습관 하나로 디버깅 시간이 크게 줄어든다.

파이썬을 아직 제대로 설치하지 않았다면 Python 설치 (Mac)부터, AI 개발을 시작하는 단계라면 LLM이란 무엇인가를 함께 읽으면 좋다.

LLM이란 무엇인가 - 토큰부터 컨텍스트까지, 한 번에 정리

요즘 뉴스마다 LLM이라는 말이 나온다. 그런데 막상 "LLM이 뭐예요?"라고 물으면 설명이 이상하게 어려워진다. "대규모 언어 모델"이라고 풀어도 여전히 모르겠고, "트랜스포머 어텐션..."부터 시작하면 대화가 끝난다.

한 문장으로 줄이면 이렇다.

LLM은 "다음에 올 말을 확률로 고르는" 기계다. 그걸 인터넷 규모의 글로 아주 많이 훈련시킨 것이다.

ChatGPT도 Claude도 Gemini도 이 원리 위에 서 있다. 차이는 얼마나 많이·어떻게 훈련시켰는지, 그리고 그 위에 어떤 장치를 얹었는지다.

이 글은 LLM이 무엇인지, 토큰·컨텍스트 같은 필수 용어가 무슨 뜻인지, 그리고 LLM이 잘하는 것과 못하는 것을 한 번에 정리한다. AI를 업무에 쓰기 시작한 사람이 알아야 할 최소한만 담았다.

---

1) 이름부터 뜯어보기: Large, Language, Model

단어	뜻	실제로 의미하는 것
Language	언어	텍스트(그리고 요즘은 이미지·음성·코드)를 다룬다
Model	모델	통계적으로 다음에 올 것을 예측하는 함수
Large	대규모	훈련 데이터와 파라미터(내부 숫자)가 매우 많다

여기서 중요한 건 Model이다. LLM은 데이터베이스가 아니다. 어딘가에서 답을 꺼내오는 게 아니라, 입력받은 문맥 다음에 올 가장 그럴듯한 말을 계산해서 만들어낸다.

이 차이가 LLM의 장점과 단점을 동시에 만든다. 문장을 자연스럽게 이어 붙이는 능력은 인간을 넘지만, "이 말이 사실인가"를 확인하는 장치는 기본적으로 없다. 뒤에서 다시 다룬다.

---

2) LLM의 유일한 일: 다음 토큰 맞히기

LLM이 하는 일은 놀랄 만큼 단순하다. 문장을 앞에서부터 읽다가, 바로 다음 조각 하나를 고른다. 그리고 그걸 붙여서 다시 다음 조각을 고른다. 이걸 반복해서 긴 답이 나온다.

"오늘 점심은" 다음에 올 말을 고른다고 해보자.

후보	확률
무엇을	18%
뭐	12%
김치찌개	9%
먹을까	7%
...	나머지

LLM 내부에는 이런 확률표가 수십만 개의 후보에 대해 있다. 거기서 하나를 뽑아 붙이고, 다시 표를 계산하고, 또 뽑는다. 답변이 스트리밍으로 한 글자씩 찍히는 이유가 여기 있다. 실제로 그렇게 만들고 있는 중이다.

재밌는 점은 이 단순한 반복이 규모를 키우면 번역·요약·코딩·추론처럼 보이는 행동으로 나타난다는 것이다. "다음 단어 맞히기"를 아주 잘하려면 세상의 문법과 맥락과 상식을 흉내 낼 수밖에 없기 때문이다.

---

3) 토큰(token): LLM이 보는 글자의 단위

LLM은 글자를 그대로 보지 않는다. 토큰이라는 조각으로 잘라서 본다. 단어보다 작고, 글자보다 크다.

• 영어는 대략 4글자 ≈ 1토큰 (unbelievable → un + believ + able 같은 식)
• 한국어는 대략 한 글자 ≈ 1토큰 안팎 (조사·어미가 붙으면 조금 늘어난다)
• 숫자·특수문자·이모지는 생각보다 토큰을 많이 먹는다

토큰이 중요한 이유는 세 가지다.

1. 요금의 단위다. API 가격표는 "100만 토큰당 얼마"로 적혀 있다. 2026년 기준 가장 싼 모델은 입력 100만 토큰에 $0.10 수준, 최상위 모델은 $10 수준이다. 같은 100배 차이다.
2. 한 번에 넣을 수 있는 양의 단위다. 이게 다음에 나오는 컨텍스트 윈도우다.
3. 토크나이저가 바뀌면 같은 글도 토큰 수가 달라진다. 모델이 세대 교체되면 같은 문서의 비용이 갑자기 늘거나 줄 수 있다.

실무 감각으로는 이렇게 기억하면 된다. A4 한 장 분량의 한국어 ≈ 1,000~1,500토큰. 보고서 10장을 통째로 넣으면 1만~1.5만 토큰이다.

---

4) 컨텍스트 윈도우: 모델의 '작업 기억'

컨텍스트 윈도우(context window)는 한 번에 볼 수 있는 토큰의 최대량이다. 질문 + 대화 기록 + 첨부 문서 + 모델이 쓴 답변까지 전부 여기에 포함된다.

2026년 현재 주요 모델은 20만에서 100만 토큰 수준이다. 100만 토큰이면 한국어로 대략 100만 자, 책 열 권 분량이다.

여기서 자주 하는 오해 세 가지를 짚고 가자.

• "많이 넣으면 다 기억한다"는 아니다. 창이 커도 가운데 부분을 놓치는 경향(이른바 lost in the middle)이 있다. 중요한 자료는 앞이나 뒤에 두고, 질문을 구체적으로 쓰는 게 낫다.
• "대화가 길어져도 무한히 기억한다"는 아니다. 창을 넘으면 오래된 대화부터 잘리거나 요약된다. 오래 쓰는 작업은 문서에 적어두고 다시 넣는 편이 안전하다.
• "많이 넣으면 좋은 답이 나온다"도 아니다. 관련 없는 자료를 잔뜩 넣으면 오히려 답이 흐려지고 비용만 늘어난다. 필요한 부분만 잘라 넣는 게 실력이다.

---

5) 어떻게 훈련되는가: 세 단계

LLM은 한 번에 만들어지지 않는다. 크게 세 단계를 거친다.

1. 사전학습(pretraining) - 인터넷 규모의 텍스트로 "다음 토큰 맞히기"를 무한 반복한다. 여기서 언어·상식·코딩 패턴이 몸에 밴다. 비용이 가장 크고, 몇 달씩 걸린다.
2. 지시 학습(SFT) - 사람이 쓴 모범 답안(질문-답 쌍)으로 "질문에 답하는 형식"을 가르친다. 사전학습만 한 모델은 말을 이어갈 줄 알지만 시키는 대로 하지는 못한다.
3. 선호 학습(RLHF 등) - 사람이 좋은 답과 나쁜 답을 비교한 데이터로, 더 유용하고 덜 해로운 쪽으로 성향을 조정한다. "친절하게, 간결하게, 거절할 건 거절하게"가 여기서 만들어진다.

2026년의 프런티어 모델은 여기에 한 단계가 더 붙는다. 추론(reasoning) 학습이다. 답을 내기 전에 스스로 생각하는 과정을 강화학습으로 훈련시켜, 수학·코딩·계획 같은 문제에서 정확도를 끌어올린다. 그래서 요즘 모델은 "생각하는 시간"이 곧 성능이고, 그만큼 토큰을 더 쓴다.

---

6) '크다'는 말의 의미가 바뀌었다

원래 LLM 경쟁은 파라미터 수 싸움이었다. 100억, 1000억, 1조 개. 크면 똑똑해진다는 경험칙(스케일링 법칙)이 있었기 때문이다.

지금은 계산이 조금 달라졌다.

• 작은 모델이 빠르게 좋아졌다. 2026년의 소형 모델은 2년 전 최상위 모델급 성능을 훨씬 싼값에 낸다. "무조건 큰 모델"은 더 이상 정답이 아니다.
• 같은 모델도 얼마나 생각하게 하느냐로 성능이 갈린다. 어려운 문제는 오래 생각시키고, 단순한 일은 바로 답하게 하는 식이다.
• 크기보다 붙이는 것이 중요해졌다. 검색, 사내 문서, 도구 호출, 메모리 같은 외부 장치를 붙이는 쪽이 실무 성과를 더 많이 바꾼다.

그래서 실무에서는 "가장 좋은 모델"보다 "이 일에 충분한 모델"을 고르는 게 맞다. 요약·분류·번역은 저렴한 모델, 복잡한 설계·디버깅은 상위 모델. 이 감각이 비용을 열 배 아껴준다.

---

7) LLM이 못하는 것 (여기가 제일 중요하다)

LLM의 한계는 대부분 "확률로 다음 말을 고르는 기계"라는 사실에서 나온다.

• 할루시네이션(환각) - 모르는 것을 모른다고 하기보다, 그럴듯한 문장을 만들어낸다. 확률 기계에게 "그럴듯함"은 "사실임"이 아니다. 출처·수치·인용은 반드시 원문과 대조해야 한다.
• 최신성 - 학습이 끝난 시점 이후의 일은 모른다. 웹 검색이나 사내 문서 연결(RAG)이 필요한 이유다.
• 정확한 계산·집계 - 본질적으로 계산기가 아니다. 숫자 계산·정산·통계는 도구를 쓰게 하거나 직접 검산해야 한다.
• 자기 지식에 대한 과신 - "내 컨텍스트에는 없지만"이라고 말해야 할 상황에서도 자신 있게 답하는 경향이 있다.
• 긴 문맥의 가운데 - 위에서 말한 lost in the middle. 문서를 통째로 넣었다고 다 읽었다고 가정하면 안 된다.

반대로 LLM이 압도적으로 강한 영역은 분명하다. 초안 만들기, 요약, 형식 변환, 번역, 코드 작성과 설명, 아이디어 발산. 이 여섯 가지는 "정답이 하나로 정해지지 않은 언어 작업"이라 확률 기계에 딱 맞는다.

---

8) 검색·RAG·에이전트와의 관계

LLM이라는 말과 함께 튀어나오는 단어들이 있다. 관계만 알면 정리가 된다.

개념	한 줄 정의	비유
LLM	다음 토큰을 예측하는 두뇌	시험 보는 사람
검색(Search)	외부에서 최신·정확한 자료를 찾아옴	도서관
RAG	검색한 자료를 프롬프트에 붙여 답하게 함	오픈북 시험
에이전트(Agent)	LLM이 도구를 스스로 골라 여러 단계를 실행	손발이 달린 사람
파인튜닝	특정 일에 맞게 모델 가중치를 추가 학습	직무 교육

핵심은 LLM은 두뇌 하나이고, 나머지는 그 두뇌를 더 쓸 만하게 만드는 장치라는 것이다. 최신 정보가 필요하면 검색을 붙이고(RAG), 실제로 파일을 만들거나 예약을 해야 하면 도구를 붙인다(에이전트). 요즘 제품 대부분은 이 조합으로 동작한다.

---

9) 2026년 지형, 아주 짧게

• GPT(OpenAI), Gemini(Google), Claude(Anthropic) 세 진영이 프런티어를 나눠 갖고 있고, 메타가 2026년에 다시 뛰어들었다.
• 각 진영은 최상위 모델 + 저렴한 소형 모델의 2~4단 구성으로 나왔다. 성능 차이보다 가격·속도·컨텍스트·도구 생태계 차이로 고르는 시대다.
• 모델 이름과 가격은 석 달만 지나도 바뀐다. 그래서 최신 라인업은 GPT·Gemini·Claude 모델 라인업 비교에 따로 정리해뒀다.

처음 쓰는 입장이라면 모델 비교부터 하지 말고, 하나를 골라 일주일 써보는 게 먼저다. 써보면 그다음 질문이 달라진다. "어떤 모델이 좋아?"에서 "이 작업을 어떻게 시켜야 하지?"로 넘어가는 게 성장이다.

---

10) 처음 배울 때 순서

1. 용어 6개만 외운다. 토큰, 컨텍스트, 프롬프트, 환각, RAG, 에이전트. 이 글에 다 나온다.
2. 하나를 매일 쓴다. 뉴스 요약, 메일 초안, 회의록 정리처럼 매일 하는 일에 붙인다.
3. 프롬프트를 고쳐본다. 같은 요청을 세 번 다른 방식으로 써보고 결과 차이를 관찰한다. 이게 가장 빠른 학습이다.
4. 문서를 넣어본다. 내 자료를 넣고 질문하는 경험(Projects·파일 첨부)이 채팅과 차원이 다르다.
5. 자동화로 넘어간다. 반복되는 일을 예약·도구 호출로 넘기는 순간부터 시간이 실제로 줄어든다.

Claude를 처음 쓴다면 Claude 사용법 정리, ChatGPT와 고민 중이라면 ChatGPT vs Claude 비교, 개발자라면 AI 코딩 툴 비교를 이어서 보면 된다. 비용이 궁금하면 Claude 요금제 비교에 숫자로 정리해뒀다.

---

11) 자주 묻는 질문

Q. LLM과 AI는 같은 말인가요?

아니다. AI가 큰 범주고, LLM은 그 안에서 언어를 다루는 모델의 한 종류다. 이미지 생성 모델, 음성 인식 모델, 추천 모델도 AI다.

Q. 챗봇과 뭐가 다른가요?

챗봇은 제품 형태, LLM은 부품이다. 예전 규칙 기반 챗봇은 정해진 답만 했고, LLM 기반 챗봇은 답을 그때그때 만든다.

Q. 파인튜닝과 프롬프트 중 뭘 먼저 해야 하나요?

거의 항상 프롬프트가 먼저다. 프롬프트와 참고자료로 해결되는 일이 대부분이고, 파인튜닝은 형식·말투·도메인 습관을 굳힐 때 쓴다. 비용도 데이터 준비도 훨씬 크다.

Q. LLM은 이해하고 있는 건가요?

이건 지금도 논쟁이다. 확실한 건, LLM은 문맥 안의 패턴을 매우 정교하게 다루고, 그 결과가 실용적으로 쓸 만하다는 점이다. "이해"라는 단어를 붙일지는 철학의 영역이고, 업무에서는 어디까지 믿을지를 정하는 게 더 실용적이다.

---

12) 정리

• LLM은 다음 토큰을 확률로 고르는 기계다. 그 단순한 규칙이 규모를 만나 번역·요약·코딩처럼 보이는 일을 해낸다.
• 토큰은 요금과 한도의 단위, 컨텍스트 윈도우는 작업 기억이다. 이 두 개만 알면 대부분의 AI 뉴스가 읽힌다.
• 훈련은 사전학습 → 지시 학습 → 선호 학습(+추론 학습) 순서다. 성격과 말투는 뒤쪽 단계에서 만들어진다.
• 한계는 환각·최신성·계산·과신이다. 이 네 개를 알고 쓰면 사고의 90%는 막을 수 있다.
• 잘하는 일에 쓰고, 확인이 필요한 일은 확인한다. 그게 LLM을 잘 쓰는 방법의 전부다.

용어가 잡혔으면 이제 도구를 고를 차례다. 모델과 가격은 계속 바뀌니, 결정을 미루지 말고 오늘 하나 골라서 일주일 써보는 게 낫다.