반응형
Python 설치 (Mac)

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 다운로드클릭 몇 번, 초보자 친화적업데이트·버전 관리가 번거롭다입문 첫날만
Homebrewbrew install python업데이트·삭제가 쉽고 다른 도구와 일관적Homebrew 자체를 먼저 설치해야 한다기본 추천
uvbrew 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.152026-10-09 출시, 최신새 프로젝트·학습용
3.142025-10 출시, 안정실무 기본 추천
3.132024-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 오류 해결

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 Pillowimport PIL
pip install opencv-pythonimport cv2
pip install scikit-learnimport sklearn
pip install beautifulsoup4import bs4
pip install PyYAMLimport yaml
pip install python-dateutilimport dateutil
pip install python-docximport docx
pip install psycopg2-binaryimport 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이 뭐예요?"라고 물으면 설명이 이상하게 어려워진다. "대규모 언어 모델"이라고 풀어도 여전히 모르겠고, "트랜스포머 어텐션..."부터 시작하면 대화가 끝난다.

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

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을 잘 쓰는 방법의 전부다.

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

반응형
반응형
Claude 요금제 비교 2026

Claude 요금제 비교 2026 - Free·Pro·Max·Team, 나는 뭘 사야 할까

"Claude 얼마예요?"라고 물으면 대답이 길어진다. $0부터 시작해서, 쓰는 양에 따라 월 $20, $100, $200까지 올라가고, 팀 단위로 가면 좌석당 과금이 붙는다. 게다가 요금제 페이지는 영어로 뜨고, 세금이 붙으면 숫자가 또 달라진다.

그래서 2026년 10월 17일 기준으로 claude.com/pricing을 직접 열어 확인한 숫자로 한 번 정리했다. 결론부터 말하면 이렇다.

  • 일단 무료(Free)로 시작한다. 요즘 무료도 충분히 쓸 만하다.
  • 매일 쓰기 시작하면 Pro. Claude Code까지 여기서 열린다.
  • 하루 종일 돌리거나 Claude Code를 본업으로 쓰면 Max.
  • 2명 이상이 같이 쓰면 Team, 보안·감사 요건이 있으면 Enterprise.

1) 2026년 10월 라인업 한눈에

지금 Claude 요금제는 다섯 갈래다.

플랜대상가격(한국 결제, 부가세 포함)
Free구경·가벼운 사용$0
Pro개인 실사용월 $22 (연간 결제 시 월 $18)
Max헤비 유저·개발자5x 월 $110 / 20x 월 $220
Team2~150명 팀스탠다드 시트 월 $27.50 (연간 시 $22)
Enterprise대기업시트당 $20(연간, 최소 20석) + 사용량 과금

미국 기준 표시가는 Pro $20, Max $100/$200, Team 스탠다드 $25다. 한국에서 결제하면 부가세 10%가 붙어서 위 숫자로 보인다는 점만 기억하면 헷갈리지 않는다.


2) Free - 생각보다 많이 준다

$0인데도 꽤 준다.

  • 웹·데스크톱·모바일 채팅
  • 웹 검색, 파일 생성, 코드 실행
  • 대화 간 메모리
  • 앱·도구 연결(커넥터), Skills
  • Artifacts, Claude Design·Slides·Docs
  • Projects 최대 5개

작년만 해도 유료 기능이던 것들이 내려왔다. "AI를 처음 써본다" 단계라면 무료로 2주는 충분히 버틸 수 있다.

다만 Free에는 두 가지 벽이 있다.

  1. Claude Code가 없다. 개발자에게는 이게 가장 큰 차이다.
  2. Research(심층 리서치)와 긴 작업이 막힌다. 자료를 여러 개 엮어서 보고서를 뽑는 식의 작업은 Pro부터다.

3) Pro - 개인 사용자의 사실상 표준

월 $22(연간 결제 시 월 $18, 1년치 $220 선불). 한 달 커피 세 잔 값이다.

Free에 더해지는 것:

  • 사용량 증가 (구체적 한도는 Anthropic이 공개하지 않고, 시기에 따라 조정된다)
  • Claude Code - 터미널에서 돌리는 코딩 에이전트
  • Research - 웹을 여러 번 오가며 근거를 모아 답하는 모드
  • Projects 제한 해제, 프로젝트 안에 자료 묶어두기
  • Claude in Chrome, Microsoft 365, Outlook 연동
  • 작업 위임·예약(schedule) - "매주 월요일 9시에 이거 해줘" 같은 예약 실행
  • Claude Science, Dashboards(베타), 더 많은 모델 선택

내 기준으로 Pro의 값은 Claude Code와 Projects에서 뽑는다. 채팅만 쓴다면 무료와 체감 차이가 크지 않을 수 있다. 반대로 코드를 만지거나, 자료를 계속 넣고 돌리는 작업이 있다면 $22는 바로 회수된다.


4) Max - "하루 종일" 쓰는 사람의 플랜

월 $110(5x) 또는 $220(20x). Pro 대비 사용량이 5배 또는 20배다.

Pro에 더해지는 것:

  • 출력 길이 한도 상향 (긴 글·긴 코드를 한 번에)
  • 신기능 얼리 액세스
  • 트래픽 몰릴 때 우선 접근
  • 매달 $100(5x) / $200(20x) 상당의 API 크레딧 - Claude Platform에서 개발할 때 쓸 수 있다

여기서 많이 하는 오해가 있다. Max는 "더 좋은 모델"이 아니라 "더 많은 양"이다. 모델은 Pro와 같다. 그러니 "Claude가 똑똑해지나?" 싶어서 올리는 건 돈 낭비고, "자주 막힌다" 싶을 때 올리는 게 맞다.

판단 기준은 단순하다. 최근 일주일 동안 사용량 제한에 걸린 날이 3일 이상이면 Max 5x, 매일 걸리고 Claude Code까지 돌린다면 Max 20x다.


5) Team - 2명부터, 좌석을 섞을 수 있다

2~150명 규모 팀용. 여기가 구조가 조금 다르다. 시트(좌석)를 두 종류로 나눠 섞을 수 있다.

시트 종류월 요금(연간)월 요금(월간)특징
스탠다드$22$27.50Pro보다 많은 사용량
프리미엄$110$137.50스탠다드의 5배 사용량, Claude Code·Cowork 포함

예를 들어 10명 팀에서 개발자 2명만 프리미엄, 나머지 8명은 스탠다드로 두는 식이다. 전원을 똑같이 맞출 필요가 없어서, 실제로는 이 조합이 가장 많이 쓰인다.

Team에 포함되는 것:

  • 중앙 청구·관리 콘솔
  • SSO(싱글 사인온), 도메인 인증
  • 커넥터 관리자 제어, 데스크톱 앱 기업 배포
  • 기본적으로 사용자 데이터를 모델 학습에 쓰지 않음
  • 월 최대 $500의 공유 API 크레딧

개인 Pro 여러 개를 사는 것과의 결정적 차이는 관리 콘솔과 데이터 정책이다. 결제·권한·감사가 한 곳에서 돌아가야 하는 순간 Team으로 가야 한다.


6) Enterprise - 규제 산업이면 여기

셀프서비스 Enterprise는 시트당 월 $20(연간 결제, 최소 20석)에 사용량을 API 요율로 별도 과금한다. 영업 지원형은 별도 협의다.

Team에 더해지는 것:

  • SCIM(계정 자동 동기화), 감사 로그, 컴플라이언스 API
  • 역할 기반 세밀 권한, 조직 단위 지출 한도
  • 맞춤 데이터 보존, IP 허용 목록, 네트워크 수준 접근 제어
  • HIPAA 준수 옵션
  • Claude Security(베타)

금융·의료·공공처럼 "감사 로그와 접근 통제를 증명해야 하는" 조직은 Team이 아니라 Enterprise다. 최소 20석이라 소규모 팀에는 문턱이 있다.


7) API는 구독과 별개다

개발자라면 여기서 많이 갈린다. Pro/Max 구독과 API 과금은 완전히 별도다. 구독은 앱(claude.ai, Claude Code)을 쓰는 요금이고, API는 토큰 단위 종량제다.

모델입력 (100만 토큰)출력 (100만 토큰)
Fable 5.1$10$50
Opus 5.5$4$20
Sonnet 5.5$2$10
Haiku 5.5$0.10$0.50

감각적으로 말하면, Opus 5.5로 100만 토큰을 넣고 100만 토큰을 받으면 $24다. 책 한 권 분량을 넣고 비슷한 분량을 받는 작업이 3만 원 안쪽이라는 뜻이다.

그래서 판단은 이렇게 나뉜다.

  • 앱에서 대화·코딩을 한다 → 구독(Pro/Max)
  • 내 서비스에 붙인다 → API
  • 둘 다 한다 → 구독 + API (Max에는 매달 API 크레딧이 붙는다)

8) 그래서 나는 뭘 사야 하나

케이스별로 정리하면 이렇다.

이런 사람추천이유
AI가 처음, 가끔 씀Free무료로도 검색·파일·Artifacts 다 된다
매일 쓰는 직장인ProResearch·Projects·예약 작업이 열린다
개발자(코딩 중심)Pro → Max 5xClaude Code를 쓰다 막히면 올린다
Claude Code로 하루 종일 작업Max 20x5x도 하루 종일이면 부족하다
2~10명 스타트업Team(시트 혼합)관리 콘솔·SSO·데이터 정책
규제 산업·20인 이상Enterprise감사 로그·SCIM·HIPAA

내가 주변에 가장 많이 하는 조언은 "Pro로 시작하고, 일주일 뒤 사용량 제한에 걸린 날을 세어보라"는 것이다. 그 숫자가 3일을 넘으면 Max, 아니면 Pro에서 만족한다. 대부분은 Pro에서 멈춘다.


9) 돈 새는 실수 몇 가지

  • 연간 결제를 월간으로 착각하기. Pro 연간은 1년치 $220을 한 번에 낸다. 중간 해지하면 남은 기간이 환불되지 않는다.
  • Max를 "성능 업그레이드"로 오해하기. 모델은 같다. 양이 늘 뿐이다.
  • Team을 개인 Pro 여러 개로 대체하기. 당장은 싸 보이지만 청구·권한·감사가 안 된다.
  • API 크레딧을 구독 사용량으로 착각하기. Max에 붙는 API 크레딧은 개발 플랫폼에서만 쓴다.
  • 부가세 빼고 예산 잡기. 한국 결제는 표시가에 10%가 붙는다.

해지·환불 정책은 결제 수단마다 다르다. 웹 결제는 Settings > Billing에서 직접, 앱스토어 결제는 애플·구글 쪽에서 처리해야 한다.


10) 정리

  • Free → Pro → Max는 "성능 계단"이 아니라 "양 계단"이다. 모델은 대체로 같고, 얼마나 쓸 수 있는지가 달라진다.
  • Pro의 진짜 값은 Claude Code·Projects·Research에 있다. 채팅만 한다면 무료와 차이가 작다.
  • 팀은 시트를 섞는 순간 Team이 답이다. 개발자만 프리미엄, 나머지는 스탠다드.
  • 20인 이상 규제 산업은 Enterprise. 감사 로그와 SCIM이 필요해지는 지점에서 갈린다.

Claude를 처음 쓴다면 Claude 사용법 정리부터, ChatGPT와 고민 중이라면 ChatGPT vs Claude 비교를 먼저 보면 선택이 쉬워진다. 모델 라인업 전체는 GPT·Gemini·Claude 라인업 비교에 정리해뒀다.

가격은 Anthropic이 예고 없이 바꾼다. 이 글은 2026년 10월 17일 확인 기준이니, 몇 달 뒤에 읽는다면 숫자보다 구조(양 계단·시트 혼합·구독과 API 분리)를 가져가면 된다.


참고: claude.com/pricing (2026-10-17 확인), platform.claude.com 모델 가격표, Anthropic 고객센터(사용 한도·환불 정책).

반응형
반응형

AI 코딩 툴 비교 2026 - Cursor vs Claude Code vs GitHub Copilot, 뭘 써야 할까

요즘 "AI로 코딩한다"는 말 안에 서로 다른 세 가지 도구가 뒤섞여 있다. 에디터에 붙는 자동완성(Copilot), AI가 몸통인 에디터(Cursor), 터미널에서 일을 맡기는 에이전트(Claude Code) — 이름만 AI 코딩 툴이지 쓰는 방식이 완전히 다르다.

그래서 이 글은 "뭐가 제일 좋아요"가 아니라 "내 작업 방식엔 뭐가 맞는가"로 정리했다. 2026년 10월 기준이고, 이 분야는 몇 달마다 요금과 기능이 바뀌니 지금 시점의 지형으로 읽으면 된다.


1) 한 줄 결론

  • GitHub Copilot = 자동완성 + 보조. 익숙한 에디터(VS Code·JetBrains)를 그대로 두고 "옆에서 도와주는" 타입.
  • Cursor = AI가 몸통인 에디터. 에디터 자체를 AI 중심으로 새로 만든 것. 코드베이스를 통째로 이해하고 고친다.
  • Claude Code = 터미널 에이전트. 터미널에서 "이거 고쳐줘"라고 일을 맡기면 파일을 읽고, 고치고, 테스트까지 스스로 도는 타입.

비유하면 Copilot은 조수, Cursor는 AI가 깔린 작업대, Claude Code는 시키면 알아서 하는 계약직 개발자에 가깝다. 겹치는 부분도 많지만 "손이 어디에 있느냐"가 다르다.


2) 종류가 다르다는 걸 먼저 이해하자

세 도구는 경쟁 관계라기보다 층이 다른 도구다.

  • 플러그인형 (Copilot): 이미 쓰는 IDE 위에 얹는다. 타이핑하는 순간 다음 줄을 제안하고, 채팅으로 물어보고, 요즘은 "에이전트 모드"로 여러 파일도 고친다. 도입이 제일 쉽다.
  • 에디터형 (Cursor): VS Code를 포크해 만든 별도 에디터. 탭(Tab) 자동완성, 여러 파일을 한 번에 고치는 에이전트, 코드베이스 전체를 읽는 검색·질의가 강하다. 에디터를 갈아타야 한다는 게 유일한 진입장벽.
  • 터미널 에이전트형 (Claude Code): 에디터 안이 아니라 터미널에서 돈다. "이 버그 잡고 테스트 통과시켜" 같은 목표를 주면 파일을 찾아 읽고, 수정하고, 명령을 돌려 검증까지 한다. 위임형에 가장 가깝다.

즉 어디까지 맡길 것이냐가 선택의 축이다. 한 줄 보조 → Copilot, 에디터 안에서 파일 여러 개 → Cursor, "알아서 끝내라" → Claude Code.


3) 요금제 (개략, 2026년 10월)

가격은 자주 바뀌니 대략의 위치만 보자. 대부분 무료 티어가 있어 써보고 결정하면 된다.

구분GitHub CopilotCursorClaude Code
무료Free (제한적)Hobby (제한적)없음(구독/API)
개인 유료Pro (월 $10 수준)Pro (월 $20 수준)Claude Pro에 포함 (월 $17~20)
상위Pro+ / BusinessUltra / TeamsClaude Max (월 $100~200)
과금 방식정액정액(+사용량)구독 + 사용량(API)

읽는 포인트:

  • 가성비 1위는 Copilot. 월 $10 안팎으로 자동완성·채팅·에이전트 모드를 다 준다.
  • Cursor는 월 $20 기준. 에디터를 통째로 AI화한 값이라고 보면 된다. 헤비 유저는 사용량 초과분이 붙을 수 있다.
  • Claude Code는 "따로 결제"가 아니라 Claude 구독에 포함된다. 이미 Claude Pro/Max를 쓴다면 추가 비용 없이 시작할 수 있다. 대신 많이 돌리면 API 사용량이 붙는다.

4) 강점 비교

실제 선택에 가장 도움이 되는 부분이다.

항목CopilotCursorClaude Code
진입 난이도매우 쉬움보통(에디터 이동)보통(터미널)
자동완성 품질좋음매우 좋음없음(해당 없음)
여러 파일 수정보통(에이전트 모드)좋음매우 좋음
코드베이스 이해보통매우 좋음좋음
"알아서 끝내라" 위임제한적좋음매우 좋음
터미널·테스트 실행제한적제한적매우 좋음
기존 환경 유지매우 좋음보통좋음(에디터 무관)

한 줄로: "가볍게 시작 = Copilot, 에디터 안에서 강하게 = Cursor, 통째로 위임 = Claude Code."


5) 상황별 추천

  • AI 코딩을 처음 켜본다 / 기존 IDE를 바꾸기 싫다 → Copilot. 오늘 바로 켤 수 있다.
  • 혼자 큰 프로젝트를 굴리고 에디터도 AI로 바꾸고 싶다 → Cursor. 탭 자동완성과 코드베이스 질의가 강력하다.
  • "이 기능 만들고 테스트까지 통과시켜"처럼 일을 던지고 싶다 → Claude Code. 터미널에서 목표 단위로 위임할 때 진가가 나온다.
  • 회사/팀 표준이 GitHub에 묶여 있다 → Copilot. 권한·리뷰·정책 연동이 이미 되어 있다.
  • 이미 Claude를 구독 중이다 → Claude Code를 추가 비용 없이 켜보자. 가장 빠른 체험 경로.

6) 사실 제일 좋은 답은 "섞어 쓰기"다

세 도구는 서로를 완전히 대체하지 않는다. 실전에서 많이 쓰이는 조합은 이렇다.

  1. Copilot(또는 Cursor 탭) + Claude Code: 평소엔 에디터에서 자동완성으로 속도를 올리고, 손이 많이 가는 작업(리팩터링·버그 수정·테스트)은 터미널 에이전트에게 통째로 던진다. 가장 무난한 조합.
  2. Cursor 단독: 에디터를 AI로 갈아타는 게 부담 없고, 한 도구에서 다 하고 싶을 때.
  3. Copilot 단독: 예산이 빠듯하고 환경을 안 바꾸고 싶을 때. 여기서 부족하면 Claude Code를 얹는다.

핵심은 "자동완성은 에디터에서, 위임은 터미널에서" 로 역할을 나누는 것이다. 둘을 한 도구로 억지로 다 하려 하면 어느 쪽도 아쉬워진다.


마무리

AI 코딩 툴은 "성능 순위"로 고르는 게 아니라 "내 손이 어디에 있느냐" 로 고르는 것이다.

  • 옆에서 도와주면 충분하다 → Copilot
  • 에디터를 AI로 바꾸고 싶다 → Cursor
  • 일을 통째로 맡기고 싶다 → Claude Code

처음이라면 Copilot(또는 Cursor)으로 감을 잡고, 위임이 필요해지는 순간 Claude Code를 얹는 순서를 권한다. 다만 셋 다 두세 달이면 또 바뀌니, "지금 1등"을 외우기보다 "이 작업은 누구에게 맡기면 편한가"라는 감각을 들고 가는 게 오래 간다.

AI 모델 자체의 지형이 궁금하면 GPT·Gemini·Claude 라인업 비교와 ChatGPT vs Claude 비교를, Claude 입문은 클로드(Claude) 사용법을 참고하면 된다.

참고 출처

반응형
반응형

ChatGPT vs Claude, 2026년엔 뭘 써야 할까 (실사용 기준 정리)

"ChatGPT랑 Claude 중에 뭐가 나아요?" 이 질문을 요즘 정말 자주 받는다. 결론부터 말하면 "더 좋은 것"이 따로 있는 게 아니라, 잘하는 게 다르다. 그래서 이 글은 "어느 쪽이 이긴다"가 아니라 내 작업이 어느 쪽에 맞는지를 고르는 기준으로 정리했다.

2026년 10월 기준이고, 두 서비스 모두 몇 달마다 요금제와 모델이 바뀌니 "지금 이 시점의 지형"으로 읽으면 된다.


1) 한 줄 결론

  • ChatGPT = 만능형. 멀티모달(이미지·음성)·생태계·도구 연동이 넓고, "일단 뭐든 다 된다".
  • Claude = 작업형. 긴 문서 이해, 자연스러운 글쓰기, 코딩·에이전트(여러 단계 일을 알아서 처리) 쪽이 강하다.

비유하면 ChatGPT는 종합 플랫폼, Claude는 일 잘하는 비서에 가깝다. 둘 다 잘하는 영역이 겹치지만, "오래 앉아서 일을 맡기는" 쪽은 지금 Claude가, "이것저것 폭넓게 실험하는" 쪽은 ChatGPT가 편하다.


2) 성격 차이부터 이해하면 쉽다

  • ChatGPT (OpenAI): GPT-6 Astra / 6.1 Sol / 6 Luna 라인업. 이미지 생성, 음성 대화, 앱·플러그인 생태계, 커스텀 봇(GPTs), 검색 연동까지 한 곳에 묶여 있다. "한 앱에서 다 하고 싶다"에 강하다.
  • Claude (Anthropic): Fable / Opus / Sonnet / Haiku 라인업. 문서·코드·긴 글을 다루는 정확성과 톤에 무게를 둔다. Projects·Artifacts·Claude Code로 "작업 공간에 자료 넣고 굴리는" 흐름이 잘 짜여 있다.

즉 기능 개수로는 ChatGPT, 한 우물 깊이로는 Claude라는 구도가 지금까지 이어져 왔다. 물론 서로 따라잡으며 격차는 계속 줄고 있다.


3) 요금제 비교 (2026년 10월)

개인 사용자 기준으로 대응시키면 이렇게 된다. 가격은 바뀔 수 있고, 부가세 별도다.

구분ChatGPTClaude
무료FreeFree
개인 유료Plus (월 $20 수준)Pro (연 $17 / 월 $20)
상위Pro (월 $200 수준)Max (월 $100~200)
팀/기업Team·EnterpriseTeam·Enterprise

읽는 포인트:

  • 무료로도 둘 다 "진짜 쓸 만"하다. 먼저 무료로 며칠씩 써보고 올려도 늦지 않다.
  • 개인 유료는 사실상 같은 가격대($20)라 가격만으로는 못 가른다. "무엇을 더 쓰는가"로 골라야 한다.
  • Claude Pro의 값은 Projects·Claude Code에 있다. 자료를 묶어두고 굴리는 작업이 많으면 여기서 체감이 크다.
  • ChatGPT 상위(Pro)는 이미지·영상·에이전트 등 무거운 기능을 하루 종일 돌리는 사람용이다.

4) 모델 라인업 한눈에

이름 규칙이 달라서 헷갈리는데, 위에서 아래로 갈수록 싸고 빠르다만 기억하면 된다.

  • ChatGPT: GPT-6 Astra(최상위) → GPT-6.1 Sol(주력) → GPT-6 Luna(경량)
  • Claude: Fable 5.1(최상위) → Opus 5.5(주력) → Sonnet 5.5(균형) → Haiku 5.5(경량)

가격은 100만 토큰당 이렇다 (입력/출력). 참고로 세 진영 전체를 같은 잣대로 비교한 글은 GPT·Gemini·Claude 라인업 비교에서 따로 다뤘다.

티어ChatGPTClaude
주력GPT-6.1 Sol $2 / $10Opus 5.5 $4 / $20
경량GPT-6 Luna $0.10 / $0.50Haiku 5.5 $0.10 / $0.50

앱에서는 보통 모델을 알아서 골라주니, 일반 사용자는 신경 쓸 게 별로 없다. 개발자라면 API 단가와 컨텍스트 길이를 보고 고르면 된다.


5) 기능별로 붙여보면

여기가 실제 선택에 가장 도움이 되는 부분이다. 항목별로 어느 쪽이 편한지 정리했다.

  • 긴 글쓰기·문서 요약: Claude 우세. 톤이 자연스럽고, 긴 문서를 넣었을 때 맥락을 놓치는 일이 적다는 평이 많다.
  • 이미지 생성·편집: ChatGPT 우세. 아예 이미지 생성이 붙어 있다. Claude는 이 영역이 상대적으로 약하다.
  • 음성 대화: ChatGPT 우세. 실시간 음성 대화 품질이 앞선다.
  • 코딩·개발: Claude 우세(에이전트·터미널 쪽). Claude Code로 코드베이스를 통째로 다루는 흐름이 강하다. 다만 단순 코드 질문은 둘 다 무난하다.
  • 자료 넣고 분석(Projects/파일): Claude 우세. 프로젝트별로 자료·지시를 묶어두는 구조가 잘 되어 있다.
  • 검색·최신 정보: 비슷. 둘 다 웹 검색을 붙였다.
  • 생태계·연동(지메일·엑셀·앱): ChatGPT 우세. 연결되는 앱이 넓다.
  • 업무 자동화·에이전트: Claude 우세. "여러 단계 일을 맡기는" 툴 호출·스킬 흐름이 안정적이라는 평.

한 줄로: "보고 듣고 만드는 것 = ChatGPT, 읽고 쓰고 시키는 것 = Claude."


6) 그래서 나는 이렇게 고른다

상황별로 정리해봤다.

  • AI를 처음 써본다 / 이것저것 다 해보고 싶다 → ChatGPT. 폭이 넓어서 실험이 편하다.
  • 매일 문서·보고서·블로그를 쓴다 → Claude. 톤과 긴 글 처리가 편하다.
  • 코딩·개발 작업을 위임하고 싶다 → Claude (Claude Code).
  • 이미지·영상·음성이 필요하다 → ChatGPT.
  • 자료를 넣어두고 계속 돌린다(업무 자동화) → Claude (Projects).
  • 가격이 최우선인 대량 작업 → 두 회사 경량 모델 단가가 거의 같다. 정확도로 붙여보면 된다.

한 가지만 골라야 한다면? 글·문서·코딩 중심의 지식 작업자라면 Claude, 이미지·음성까지 두루 쓰는 범용 사용자라면 ChatGPT를 권한다.


7) 사실 제일 좋은 답은 "둘 다"다

두 서비스 모두 월 $20 안팎이라, 진짜로 파고드는 사람은 둘 다 구독한다. 이유는 간단하다.

  1. 강점이 다르다. 한쪽이 못 하는 걸 다른 쪽이 메운다.
  2. 한쪽이 장애·가격변경·모델 하향을 해도 안 흔들린다. 의존을 분산하는 효과가 있다.
  3. 같은 질문을 양쪽에 던져 비교하면 답 품질이 확 올라간다. 특히 중요한 글·코드에 유용하다.

돈이 아깝다면 이렇게 하자. 무료 플랜 두 개를 나란히 켜두고, 자주 쓰는 쪽만 유료로 올린다. 이 "무료 A + 유료 B" 조합이 가성비가 가장 좋다.


마무리

ChatGPT vs Claude는 "누가 더 똑똑한가"의 싸움이 아니라 "내 작업이 어디에 맞는가"의 문제다. 성격(만능 vs 작업형), 요금제(사실상 동일 가격대), 강점(멀티모달 vs 문서·코딩) 세 가지만 보면 답이 나온다. 처음이면 양쪽 무료로 며칠씩 써보고, 자주 쓰는 쪽에 돈을 내자.

두 도구 모두 두세 달이면 또 바뀐다. 그러니 "지금 1등"을 외우기보다 "내 일을 어느 쪽에 맡기면 편한가"라는 감각을 들고 가는 게 오래 간다.

처음부터 하나만 깊게 파보고 싶다면, 클로드 입문 정리는 클로드(Claude) 사용법 - 처음 쓰는 사람을 위한 정리에 따로 정리해뒀다.

참고 출처

반응형
반응형

클로드(Claude) 사용법 - 처음 쓰는 사람을 위한 정리 (무료부터 Pro·Max까지)

요즘 "클로드 쓰세요?"라는 말을 정말 자주 듣는다. 그런데 막상 시작하려면 "무료로 어디까지 되지?", "Pro는 꼭 사야 하나?", "ChatGPT랑 뭐가 달라?" 같은 질문이 먼저 막힌다.

그래서 이 글은 클로드를 처음 쓰는 사람 기준으로 정리했다. 설치부터 요금제, 모델, 그리고 알면 판이 바뀌는 기능까지 한 번에 훑는다. 이 글 하나 저장해두면 두고두고 꺼내 쓸 수 있게 쓰는 게 목표다.


1) 클로드가 뭔가 (한 줄로)

클로드는 앤트로픽(Anthropic)이 만든 AI 다. 챗GPT·제미나이와 같은 대형 언어모델(LLM) 계열이고, 강점은 문서 이해·요약, 긴 글쓰기, 코딩, 그리고 "에이전트"(알아서 여러 단계 일을 처리하는 것) 쪽에 있다. 웹·앱으로 대화하듯 쓸 수도 있고, 개발자는 API로 붙일 수도 있다.

일반 사용자 입장에서 핵심은 이거다. "그냥 질문하는 챗봇"보다 "일을 맡기는 비서"에 가깝다. 그래서 기능을 몇 개만 알면 체감이 확 달라진다.


2) 무료로도 이만큼 된다

돈 안 내고도 꽤 쓸 만하다. 무료(Free) 플랜에서 되는 것:

  • 웹·데스크톱·모바일 앱에서 대화
  • 웹 검색, 파일 만들기, 코드 실행
  • 메모리(Memory) — 대화를 넘어 나를 기억
  • 앱·툴 연결(Connectors)
  • 아티팩트(Artifacts) 로 결과물 만들기
  • Claude Design·Slides·Docs

"일단 무료로 써보고, 부족하면 올린다"가 정석이다. 무료로 며칠 써보면 내가 Pro가 필요한 타입인지 금방 감이 온다.


3) 요금제 3단계 - Free / Pro / Max

가격은 2026년 10월 기준이다(부가세 별도, 바뀔 수 있음).

플랜가격핵심
Free$0대화·웹검색·아티팩트·메모리, 사용량 제한
Pro월 $17(연 결제) / $20(월 결제)사용량↑, Claude Code·Projects, 더 많은 모델, Chrome·M365 연동
Max월 $100부터 (5x)Pro의 5배~20배 사용량, 높은 출력 한도, 우선 접속, 월 $100~200 API 크레딧

읽는 포인트:

  • Pro의 진짜 값은 "Projects"와 "Claude Code" 다. 문서·자료를 넣어두고 전용 워크스페이스로 굴리려면 Pro가 사실상 필수.
  • Max는 "하루 종일 클로드로 작업하는 사람"용이다. API 크레딧이 붙어서 개발자·파워유저에게 유리.
  • 가끔 쓰는 정도면 Free로 충분하다. 무작정 Pro부터 결제할 필요 없다.

4) 모델이 여러 개다 - 뭘 고르나

같은 클로드라도 쓰는 모델에 따라 똑똑함·속도·가격이 다르다. 2026년 10월 라인업은 이렇다(100만 토큰당 입/출력).

모델성격가격언제
Fable 5.1최고 난도 추론·장기 에이전트$10 / $50정말 어려운 문제
Opus 5.5실전 주력(기본값)$4 / $20대부분의 작업은 이걸로 시작
Sonnet 5.5속도·지능 균형$2 / $10빠른 일상 작업
Haiku 5.5초경량·초저렴$0.10 / $0.50부터대량 처리·분류

일반 사용자는 이렇게 기억하면 된다. "기본은 Opus, 가볍게는 Sonnet·Haiku, 진짜 어려우면 Fable." 앱에서는 보통 모델을 알아서 골라주니, 특별히 무거운 작업이 아니면 신경 안 써도 된다.


5) 알면 판이 바뀌는 기능 5개

여기가 이 글의 핵심이다. 클로드가 "그냥 챗봇"에서 "일하는 도구"로 바뀌는 지점이 여기다.

  • Projects — 주제·업무별 전용 워크스페이스. 프로젝트 지시(Project Instructions)와 올려둔 자료를 매번 자동으로 참조한다. "매번 배경 설명 붙여넣기"에서 해방된다. 업무·공부·글쓰기별로 하나씩 만들어두면 효율이 확 오른다.
  • Artifacts — 답변을 문서·코드·시각 자료로 바로 만들어준다. 코드 미리보기, 표, 간단한 앱까지. 복사-붙여넣기 반복이 줄어든다.
  • 메모리(Memory) — 대화를 넘어 내 선호와 맥락을 기억한다. 쓸수록 나에게 맞춰진다.
  • 웹 검색 + 파일 — 최신 정보 검색, PDF·문서 올려서 분석. "자료 넣고 물어보기"가 기본이 된다.
  • Skills·Connectors — 자주 쓰는 작업 방식을 스킬로, 외부 앱을 커넥터로 연결. 반복 작업을 자동화하는 출발점.

이 다섯 개만 써도 클로드 활용도가 두세 배는 올라간다.


6) 개발자라면 - Claude Code와 API

개발자에게 클로드의 진짜 무기는 Claude Code 다. 터미널·에디터에서 코드베이스를 직접 다루며, 여러 파일에 걸친 수정, 툴 호출, 테스트까지 맡길 수 있다(Pro 이상). "AI에게 코드를 물어보는" 수준을 넘어 작업을 위임하는 단계다.

API로 붙이려면 각 모델 ID(claude-opus-5-5 등)로 호출하면 된다. 모델별 문서와 가격은 platform.claude.com에서 확인할 수 있다.


7) 처음 쓰는 순서 (실전 4단계)

  1. 가입 — 구글 계정 등으로 웹(claude.com)이나 앱에서 시작. 무료로.
  2. 일단 질문 몇 개 — 내가 자주 하는 작업(요약·번역·코드·글쓰기)을 던져보고 감을 잡는다.
  3. Projects 하나 만들기 — 가장 자주 하는 업무 하나를 프로젝트로 묶고, 자료와 지시를 넣는다.
  4. 부족하면 Pro — 사용량이 모자라거나 Projects·Claude Code가 필요해지면 그때 결제.

자주 하는 실수는 "한 번에 다 시키기"다. 클로드는 대화로 다듬어가는 게 강점이니, 작게 시작 → 결과 보고 → 다시 요청이 훨씬 잘 나온다.


마무리

클로드는 "무료로 충분히 맛보고, Projects·Claude Code가 필요해지는 순간 Pro로 올리는" 도구다. 요금제 3단계, 모델 4종, 핵심 기능 5개 — 이 세 가지만 기억하면 처음 쓸 때 헤매지 않는다.

AI 툴은 두세 달이면 또 바뀐다. 그래서 "지금 기능"을 외우기보다 "어떻게 일을 맡기는가"라는 감각을 들고 가는 게 오래 간다. 클로드는 그 감각을 익히기에 좋은 출발점이다.


참고 출처

  • [Claude 요금제 (claude.com/pricing)](https://claude.com/pricing)
  • [Anthropic 모델 개요 (platform.claude.com)](https://platform.claude.com/docs/en/about-claude/models/overview)
  • [Anthropic 지원 문서 (기능·사용량)](https://support.anthropic.com/)
반응형
반응형

메타 '뮤즈 원더' 나왔다 - 14개월 만의 프런티어 모델, 이제 '3강'은 '4강'이 되는가

지난 글에서 GPT·Gemini·Claude, 이른바 '세 진영'의 모델 라인업을 한 표로 정리했다. 그 글이 올라간 지 이틀 만에, 판이 하나 더 벌어졌다. 메타가 자기 모델을 두고 처음으로 "프런티어(frontier)" 라는 단어를 꺼내 들었기 때문이다.

결론을 바로 말하면 이렇다. 메타가 성능 경쟁의 최상위 무대에 처음으로 이름을 올렸다. 다만 그 등장 방식은 앞의 세 진영과 결이 다르다. 이 글은 메타의 새 모델 '뮤즈 원더'가 뭔지 정리하고, 이게 기존 3강 구도를 어떻게 흔드는지에 대한 내 관점까지 같이 적어보려 한다.


1) 무슨 일이 있었나

메타의 초지능연구소(MSL)는 2026년 10월 12일(현지시간), 최상위 모델 시리즈 '뮤즈 원더(Muse Wonder)' 와 '뮤즈 원더 풀(Muse Wonder Full)' 을 공개했다. 메타가 자사 모델을 "프런티어 수준"이라고 공식 명명한 건 이번이 처음이다.

마크 저커버그 CEO는 "뮤즈 스파크가 우리의 첫 모델 제품군이었다면, 훨씬 더 규모가 크고 보다 진보된 뮤즈 원더는 우리를 최첨단으로 이끌었다"고 말했다. 파이낸셜타임스(FT) 인터뷰에서는 한 발 더 나가 "오픈AI를 따라잡았다"는 취지로 밝혔다. AI 사업을 총괄하는 알렉산더 왕 CAIO도 블룸버그에 "현재 시중에서 가장 우수한 모델과도 충분히 경쟁력이 있다"고 했다.

시장 반응도 즉각적이었다. 발표 당일 메타 주가는 전일 대비 3.38% 오른 742.96달러로 정규장을 마감했다(장중 한때 4.5%까지 올랐다). 지난달 개인 AI 에이전트 '뮤즈' 공개 이후로는 주가가 10% 가까이 올랐다는 계산이다.

이번 발표는 저커버그가 AI 경쟁에서 뒤처졌다는 위기감을 공개적으로 인정하고 초지능 팀을 대규모로 재편한 지 약 14개월 만의 결과물이다. 블룸버그는 "재건된 팀의 역량을 처음으로 대외 검증받는 자리"라고 짚었다.


2) 이름이 다 '뮤즈'라서 헷갈린다

먼저 정리하고 가자. 메타는 올해 '뮤즈'라는 이름을 서로 다른 제품에 계속 붙여왔다. 이름은 같아도 성격이 완전히 다르다.

  • 뮤즈(Muse) — 개인 AI 에이전트. 2026년 9월 8일 정식 출시. 이메일 전송, 여행 예약, 구매 대행, 공과금 절감 협상처럼 실제 작업을 대신 처리한다. 현재 미국에서만 이용 가능. 무료(사용량 제한) / 파워 월 20달러 / 맥시멈 월 100달러.
  • 뮤즈 스파크(Muse Spark) — 개발자용 모델. 2026년 4월 첫 공개 후 7월 1.1로 업그레이드, 지금은 1.3까지 나왔다. 처음 보는 도구에 바로 적응하는 제로샷, 서브에이전트 병렬 활용, 코딩 작업에 특화된 에이전트용 모델.
  • 뮤즈 이미지(Muse Image) — 사흘 만에 중단된 기능. 7월, 인스타그램 공개 계정 사진을 사전 동의 없이 활용하는 논란으로 공개 사흘 만에 철회됐다.
  • 뮤즈 원더 / 뮤즈 원더 풀 — 이번 프런티어 모델. 오늘의 주인공. 이름에 '뮤즈'가 들어가지만 위의 에이전트 '앱'이 아니라, 그 에이전트를 굴리는 '모델'이다.

한 줄로 묶으면 이렇다. '뮤즈'는 앱(에이전트)이고, '뮤즈 스파크·원더'는 그 앱을 움직이는 모델이다. 같은 브랜드를 두 축에 나눠 쓰는 셈이라, 검색할 때 이걸 먼저 구분해야 헛짚지 않는다.


3) 뮤즈 원더, 무엇이 다른가

뮤즈 원더의 포지션은 명확하다. "복잡한 소프트웨어 엔지니어링과 장기(long-horizon) 에이전트 작업" 용이다. 여러 파일에 걸친 코드 변경을 만들고 검증하며, 작업을 계획해 서브에이전트에 위임하고, 툴을 병렬로 호출하고, 오류가 나도 다른 방법으로 다시 시도한다.

공식 문서 기준 스펙은 이렇다.

항목내용
입력텍스트 · 이미지 · 영상 · 오디오 · PDF
출력텍스트
컨텍스트1,048,576 토큰 (약 105만)
추론 강도reasoning effort minimal ~ max
두 버전뮤즈 원더(API·Muse Code) / 뮤즈 원더 풀(Muse Code 구독 전용, API 미제공)
학습 인프라오하이오 '프로메테우스' 데이터센터 (기가와트급)

여기서 눈에 띄는 건 두 가지 축의 새 기능이다.

  • 액티브 메모리(Active Memory). 대화 이력과 사용자의 선호·습관을 기억한다. 메타는 "며칠, 몇 주, 몇 달, 그 이상으로 중요한 걸 기억하게 하는 데 엄청난 노력을 쏟았다"고 강조했다.
  • 액티브 포커스(Active Focus). 복잡하고 모호한 과제를 수행하다 오류가 나면, 스스로 다른 접근을 시도하며 끝까지 목표를 완수한다.

그리고 이 모델은 곧 개인 에이전트 '뮤즈'에 탑재된다. 순서는 구독자부터다. 메타는 "뮤즈를 쓰는 모두에게 가져갈 수 있는 특화 모델"도 따로 개발 중이라고 밝혔지만, 구체적인 일정은 아직 없다.


4) 성능 - 메타의 주장과 독립 지표는 갈린다

먼저 메타 쪽 주장부터. 메타는 자체 테스트(모델 카드)에서 뮤즈 원더와 원더 풀이 Claude Fable 5.1, GPT-6 Astra와 비슷한 벤치 점수를 낸다고 밝혔다. 국내 일부 보도는 한 발 더 나가 "뮤즈 원더가 클로드 오푸스 5.5·페이블 5.1, 오픈AI 챗GPT6 아스트라보다 뛰어난 평가를 받았다"고 전했다.

하지만 그대로 받아들이기 전에, 독립 평가기관 수치를 같이 봐야 한다. AI 모델 평가업체 아티피셜 애널리시스(Artificial Analysis) 의 지능지수(AAII)를 보면 이렇다.

모델AAII위치
Claude Opus 5.558선두(1위)
뮤즈 원더 풀56공동 2위
Claude Fable 5.1 / GPT-6 Astra / Gemini 4 Argon53 (각)공동 상위권
뮤즈 원더52공동 7위

정리하면 이렇다. 메타의 최상위 '원더 풀'은 독립 지표에서도 2위권에 올랐다. 반면 API로 풀린 '원더'는 7위권으로, 아직 최상위 한 칸(Fable·Astra·Argon·Opus)을 넘진 못했다. 메타의 "최첨단" 주장은 '원더 풀' 기준으로는 설득력이 있고, '원더'만 놓고 보면 과장이 섞여 있다는 뜻이다.

메모리 쪽은 좀 더 분명하다. 메타는 연속 학습·기억 구축을 겨루는 MemoryBench에서 뮤즈 원더가 Fable·Opus·Astra보다 높은 점수를 냈다고 밝혔다. '기억'은 메타가 전면에 내세우는 차별점이라, 여기서 앞선다는 주장은 다른 경쟁사 벤치와 결이 다르다.

한 가지 더. 구글 Gemini 4 Argon과의 비교는 아직 공백이다. 더버지는 "아르곤은 아직 역량이 드러나는 중이라 비교가 불명확하다"고 짚었다.


5) 가격 - 오푸스 5.5와 '정확히' 같은 값

Meta Model API 기준 가격이다(100만 토큰당).

모델입력출력캐시 입력
뮤즈 원더 (muse-wonder-1.0)$4.00$20.00$0.20
뮤즈 스파크 (1.1~1.3)$1.25$4.25$0.15
뮤즈 스파크 (Contributor)$0.10$0.20$0.002

여기서 제일 눈에 들어오는 건 뮤즈 원더의 $4/$20이 Claude Opus 5.5와 정확히 같은 값이라는 점이다. 테크크런치는 "GPT-6 Sol이나 Opus 5.5와 비슷한 비용대"라고 표현했다. 즉 메타는 최상위에 도전하면서 가격을 '깎아서'가 아니라 '정면으로' 맞세웠다.

몇 가지 단서도 있다.

  • 뮤즈 원더 풀은 API로 안 풀린다. Muse Code 구독자에게만 제공된다. 성능은 사고, 유통은 구독으로 잠근 전략이다.
  • 원더에는 Contributor 모드가 없다. 메타는 스파크에서 "내 데이터를 학습에 쓰게 해주는 대신 가격을 크게 깎아주는" Contributor 모드를 운영하는데, 원더(API)에는 이 할인이 없다. 스파크 Contributor는 입력 $0.10 / 출력 $0.20으로, 정가의 10분의 1 수준이다.
  • 장문맥 프리미엄이 없다. 컨텍스트가 거의 꽉 차든 비어 있든 같은 요율이다.
  • 부가 요금: 뮤즈 이미지 $0.01/장, 음성 전사 $0.18/시간, 웹 검색 그라운딩 $2.50/1,000쿼리.

요약하면, "같은 값이면 벤치로 붙자" 는 가격 정책이다. 그리고 '학습 데이터 제공 ↔ 할인'이라는 Contributor 모드는, 성능·가격과는 또 다른 축의 새 거래 조건이다.


6) 그래서 '3강' 구도는 어떻게 되나

여기가 이번 발표의 진짜 볼거리다. 내 관점을 세 갈래로 나눠 적어본다.

먼저, 무엇이 바뀌었나. 지금까지 이 구도는 GPT(오픈AI)·Gemini(구글)·Claude(앤트로픽)의 '세 진영'이었다. 세 회사가 대형·중형·경량으로 티어를 수렴시킨 상태였다는 게 지난 글의 결론이었다. 메타는 오랫동안 라마(Llama)를 오픈 웨이트로 뿌리는 '다른 트랙'에 있었고, 소비자용 프런티어 모델에서는 후발 주자였다. 그 메타가 이번에 '프런티어'를 달고 정면 무대에 올라온 것이다.

(1) '4강'이 됐나? — 반은 맞다. 독립 지표에서 '원더 풀'이 AAII 공동 2위에 올랐으니, 최상위권에 네 번째 이름이 들어온 건 사실이다. 다만 API로 누구나 쓸 수 있는 '원더'는 7위권이다. 즉 "최상위 한 칸"은 여전히 Opus 5.5·Argon·Fable·Astra가 지키고, 메타는 그 바로 아래에서 치고 올라오는 위치다. '4강 체제'라기보다 '3강 + 도전자' 에 가깝다.

(2) 그런데 진짜 차별점은 '수직 결합'이다. 이게 내가 보는 핵심이다. 앞의 세 진영은 모델과 API가 중심이다. 메타는 다르다. 모델을 자기 에이전트(뮤즈)와 유통(왓츠앱·인스타그램·AI 글래스)에 곧바로 꽂는다. 그러니 경쟁 축이 "누가 더 똑똑한가"에서 "누구의 에이전트가 더 많은 사람을 더 오래 붙잡는가"로 옮겨간다. 모델 성능이 조금 뒤져도 유통이 압도적이면 게임이 달라지는 구조다.

(3) '기억'이라는 새 좌표가 생겼다. 액티브 메모리와 MemoryBench가 그 신호다. 오픈AI·앤트로픽이 '한 번의 작업'을 잘하는 데 집중하는 동안, 메타는 '며칠~몇 달을 기억하는 것'을 전면에 세웠다. 벤치마크의 축 자체가 하나 늘어난 셈이고, 이건 다른 진영이 즉시 따라잡기 어려운 종류의 차별점이다.

그래서 구도를 한 문장으로 정리하면: 3강 구도가 무너진 게 아니라, '성능 3강' 위에 '에이전트·유통의 제4축(메타)'이 얹혔다. 모델이 하나 더 생긴 게 아니라, 경쟁의 축이 하나 더 생긴 것이다.

개발자 입장에서는 실무적인 변화가 더 와닿는다.

  • 가격이 Opus 5.5와 같으니, 같은 값이면 벤치와 지연시간으로 붙는다.
  • Meta Model API는 오픈AI 호환·앤트로픽 호환 요청 형식을 지원한다. 기존 코드를 거의 그대로 옮길 수 있어 전환 비용이 낮다.
  • Contributor 모드라는 새 선택지가 생겼다. 데이터를 학습에 내주는 대신 값싸게 쓰는 거래다.

남은 변수도 분명하다.

  • 월스트리트저널(WSJ)은 글로벌 뮤즈 에이전트 다운로드 증가세가 이미 둔화됐다고 전했다. 원더가 이 흐름을 되돌릴 수 있을지가 관건이다.
  • CNBC는 "구독으로 잠근 모델"이라는 점을 들어 유료 전환율을 최대 변수로 봤다. 실제 구독 지표는 4분기 실적에서 처음 확인된다.
  • 메타의 설비투자(캐펙스) 규모도 이 출시와 맞물려 있다. 프런티어 모델을 자체 개발·운용하려면 데이터센터와 자체 AI 가속기(MTIA) 투자가 함께 늘어야 한다.

7) 그래서 지금 뭘 쓰면 되나

  • API에서 최신 프런티어를 써보고 싶다면: 뮤즈 원더가 바로 후보다. 가격은 Opus 5.5와 같은 $4/$20이니, 같은 값이면 벤치로 비교해 고르면 된다.
  • 최고 성능이 필요하면: 여전히 Claude Opus 5.5(AAII 58)가 선두고, 뮤즈 원더 풀(56)이 그 뒤를 바짝 쫓는다. 다만 원더 풀은 API가 아니라 Muse Code 구독으로만 열린다.
  • 소비자 에이전트·기억이 중요하면: 메타의 액티브 메모리 쪽을 눈여겨볼 만하다. 단, 개인 에이전트 뮤즈는 아직 한국에 정식 출시되지 않았다(미국만).
  • 티어 감각은 그대로 유지하자. 최상위(Opus 5.5·Argon·Fable 5.1·Astra) / 중상(Sol·3.1 Pro·Sonnet 5.5) / 경량(Luna·Haiku 5.5)의 골격은 안 바뀌었다. 메타의 '원더 풀'이 이 골격의 최상위 칸에 새로 끼어든 셈이다.

마무리

2026년 10월의 지형은 이렇게 갱신된다. 성능 경쟁의 최상위에 네 번째 진영(메타)이 들어왔지만, 그 무게중심은 '모델 성능'이 아니라 '에이전트·유통·기억'에 있다. 3강이 4강으로 바뀐 뉴스라기보다, 3강 옆에 성격이 다른 경쟁 축이 하나 더 생긴 뉴스로 읽는 게 정확하다.

모델은 두세 달이면 또 바뀐다. 그래서 "지금 누가 1등"보다 "이 변화가 어떤 축을 새로 만드는가" 를 기억하는 게 오래 간다. 메타가 이번에 던진 카드는 성능표가 아니라 '기억'과 '유통'이었다. 그게 앞의 세 진영을 실제로 흔들지, 아니면 반짝 이벤트로 끝날지는 지금부터 몇 분기의 구독 지표가 말해줄 것이다.


참고 출처

  • [Meta Model API — Pricing and rate limits](https://dev.meta.ai/docs/pricing-rate-limits)
  • [Meta Model API — Models](https://dev.meta.ai/docs/models)
  • [Meta research — Muse Wonder (블로그·모델카드)](https://research.meta.ai/blog/muse-wonder)
  • [TechCrunch — Meta releases its first frontier model, Muse Wonder](https://techcrunch.com/2026/10/12/meta-releases-its-first-frontier-model-muse-wonder/)
  • [The Verge — Meta has some Wonder Full new AI models](https://www.theverge.com/ai-artificial-intelligence/1009479/meta-muse-wonder-full-ai-model)
  • [연합뉴스 — 오픈AI·앤트로픽 따라잡는 메타…새 AI모델 '뮤즈 원더' 공개](https://www.yna.co.kr/view/AKR20261013009200091)
  • [머니투데이 — 저커버그 "오픈AI 따라잡았다"](https://www.mt.co.kr/world/2026/10/13/2026101306063562112)
반응형

+ Recent posts