강남거북이개발자

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc7 in position 0 같은 줄을 만나면 대부분 encoding='utf-8'을 붙였다가 또 실패하고, 그다음엔 errors='ignore'로 넘겨버린다. 그러면 에러는 사라지지만 글자는 영원히 깨진 채로 남는다.

이 글은 한글 파일을 읽을 때 나는 UnicodeDecodeError를 기준으로, 에러 메시지에서 무엇을 읽어야 하는지와 읽는 쪽·쓰는 쪽을 어떤 순서로 고치는지를 정리했다. 예제는 내 맥의 python3 3.9.6과 최신 문서(Python 3.15 계열)를 함께 확인해서 썼다.

30초 요약

한글 깨짐은 파일 손상이 아니라 코덱 선택 문제라는 것을 정리한 히어로 이미지

목차

1. UnicodeDecodeError는 왜 나는가
2. 에러 메시지에서 읽어야 하는 네 가지
3. 해결 1 — 읽는 쪽에 encoding을 지정한다
4. 해결 2 — cp949와 BOM(utf-8-sig) 구분
5. 해결 3 — 인코딩을 모를 때 확인하고 변환하기
6. 그래도 안 될 때 — 쓰는 쪽과 실행 환경
7. 증상별 처방 표
8. 내가 막혔던 곳
9. 참고 자료

UnicodeDecodeError는 왜 나는가

파이썬 3에서 str은 글자, bytes는 바이트다. 파일을 텍스트 모드로 열면 파이썬이 바이트를 읽어서 코덱으로 글자로 바꾸는데, 이때 바이트가 그 코덱의 규칙에 맞지 않으면 UnicodeDecodeError가 난다. 같은 파일이라도 어떤 코덱을 고르느냐에 따라 성공과 실패가 갈린다.

내 맥에서 직접 확인한 결과다. 같은 "한글"이라는 글자를 utf-8로 저장하면 b'\xed\x95\x9c\xea\xb8\x80', cp949로 저장하면 b'\xc7\xd1\xb1\xdb'가 된다. 이 cp949 바이트를 utf-8로 읽으면 바로 에러가 난다.

>>> "한글".encode("cp949")
b'\xc7\xd1\xb1\xdb'
>>> "한글".encode("cp949").decode("utf-8")
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc7 in position 0: invalid continuation byte

cp949의 첫 바이트 0xC7은 utf-8에서 "앞 글자의 뒤를 잇는 바이트"로만 쓰이는 값이라, 파이썬 입장에서는 문장이 시작하자마자 규칙이 깨진 것이다. 반대 방향도 똑같이 실패한다. utf-8 바이트를 cp949로 읽으면 'cp949' codec can't decode byte 0xed in position 0: illegal multibyte sequence가 나온다.

정리하면 이 에러는 파일이 깨진 게 아니다. 내가 고른 코덱이 파일과 안 맞는 것이다. 파일은 그대로 두고 읽는 쪽을 고치면 된다.

에러 메시지에서 읽어야 하는 네 가지

트레이스백은 생각보다 많은 정보를 준다. 아래 한 줄만 제대로 읽어도 절반은 해결된다.

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc7 in position 12: invalid continuation byte

position이 0이고 byte가 0xef라면 BOM(Byte Order Mark)이 원인일 수 있다. utf-8 BOM은 EF BB BF 세 바이트다. 이때는 utf-8-sig로 읽으면 BOM을 건너뛴다. 처리 방식은 아래 해결 2에서 따로 다룬다.

어느 파일에서 났는지 안 보이면 트레이스백 위쪽 프레임을 봐야 한다. open()을 여러 번 부르는 코드라면 파일 경로를 로그로 찍는 편이 빠르다. 나는 예외를 잡아서 경로를 붙여 다시 올리는 방식을 쓴다.

try:
    text = open(path, encoding="utf-8").read()
except UnicodeDecodeError as exc:
    raise RuntimeError(f"{path} 디코딩 실패: 코덱={exc.encoding}, 위치={exc.start}") from exc

UnicodeDecodeError에는 encoding, object, start, end, reason 속성이 있어서 어느 지점에서 막혔는지 코드로 꺼낼 수 있다. (내장 예외)

여러 파일을 한꺼번에 읽는 배치라면, 원인을 찾기 전에 -X warn_default_encoding을 붙여 실행해 보는 것도 방법이다. 인코딩을 적지 않은 open()마다 EncodingWarning이 찍힌다. 이 경고는 Python 3.10부터 있고 기본은 꺼져 있다. (PEP 597)

해결 1 — 읽는 쪽에 encoding을 지정한다

결론은 간단하다. 텍스트를 읽는 모든 지점에 인코딩을 적는다. 파이썬 3.15 문서 기준으로, 텍스트 모드에서 encoding을 생략하면 UTF-8이 기본이고, UTF-8 모드가 꺼진 환경에서는 locale.getencoding()이 대신 쓰인다. 즉 같은 코드가 OS와 버전에 따라 다르게 동작할 수 있다. (open())

이 불확실성을 없애려고 파이썬은 3.15부터 UTF-8 모드를 기본으로 켠다. (PEP 686) 그래도 3.14 이하를 쓰는 사람이 많으니, 코드에는 인코딩을 직접 적는 습관이 안전하다.

# 가장 기본
from pathlib import Path

text = Path("메모.txt").read_text(encoding="utf-8")

# 한 줄씩 읽기
with open("로그.txt", encoding="utf-8") as f:
    for line in f:
        print(line.rstrip())

csv 모듈은 newline=""을 같이 넣어야 줄바꿈 처리가 꼬이지 않는다. 엑셀이 만든 파일이면 cp949부터 시도한다.

import csv

with open("주소록.csv", newline="", encoding="cp949") as f:
    rows = list(csv.DictReader(f))

pandas를 쓴다면 read_csv의 encoding 인자로 같은 값을 넘긴다. encoding_errors의 기본값은 'strict'라서, 인코딩이 틀리면 조용히 넘어가지 않고 에러를 낸다. (pandas.read_csv)

import pandas as pd

df = pd.read_csv("매출.csv", encoding="cp949")
df = pd.read_csv("매출.csv", encoding="utf-8-sig")   # BOM 있는 utf-8

JSON은 예외가 적다. 교환용 JSON 텍스트는 UTF-8로 쓰는 것이 표준이고, 파이썬 json 모듈도 그 전제로 동작한다. (RFC 8259 §8.1) 그래도 파일을 직접 열어 읽는다면 인코딩을 적어두는 편이 좋다.

증상별 처방을 한 장에 정리한 카드 — 코덱·BOM·errors 처리 순서

위 코드처럼 읽는 지점마다 encoding을 붙여두면, 나중에 다른 사람이 같은 파일을 열어도 에러 없이 같은 결과를 본다. 인코딩은 "환경이 정해주는 값"이 아니라 "내가 정하는 값"으로 다루는 게 핵심이다.

해결 2 — cp949와 BOM(utf-8-sig) 구분

한국어 환경에서 실제로 마주치는 인코딩은 크게 셋이다. 이름이 비슷해서 헷갈리는데, 파이썬 표준 인코딩 목록에는 cp949가 949, ms949, uhc와 같은 코덱으로 등록돼 있다. (표준 인코딩)

utf-8-sig는 읽을 때 앞의 BOM을 건너뛰고, 쓸 때는 BOM을 붙인다. (codecs — utf_8_sig) 이걸 안 쓰면 첫 컬럼 이름이 '\ufeff이름'처럼 보이면서, 값은 멀쩡한데 컬럼 매칭만 실패하는 이상한 상황이 된다. KeyError: '이름'이 나는데 눈으로는 똑같아 보이는 증상이 그거다.

cp949와 euc-kr은 겹치는 부분이 많지만 같은 코덱은 아니다. cp949가 euc-kr보다 넓은 문자 집합을 담는다. 그래서 euc-kr로 저장된 파일은 cp949로도 대부분 읽힌다. 반대는 안 된다. 실무 순서는 utf-8 → cp949 → euc-kr로 두는 편이 무난하다.

def read_korean_text(path):
    for enc in ("utf-8-sig", "cp949"):
        try:
            return path.read_text(encoding=enc), enc
        except UnicodeDecodeError:
            continue
    raise UnicodeDecodeError("unknown", b"", 0, 1, f"{path} 인코딩 판별 실패")

이 함수는 BOM 있는 utf-8과 cp949를 모두 잡는다. 다만 "성공했다"가 "제대로 읽혔다"를 보장하지는 않는다. 아래 섹션에서 이 함정을 다룬다.

해결 3 — 인코딩을 모를 때 확인하고 변환하기

파일이 어떤 인코딩인지 모르면 추측보다 확인이 먼저다. 맥·리눅스에서는 file 명령으로 charset을 볼 수 있다.

file -I 주소록.csv          # macOS
file -i 주소록.csv          # Linux

charset=unknown-8bit처럼 나오면 판별에 실패한 것이다. 이럴 때 파이썬에서는 charset-normalizer를 쓴다. requests가 의존성으로 함께 설치하는 라이브러리라 이미 깔려 있는 경우가 많다.

from charset_normalizer import from_bytes

raw = open("주소록.csv", "rb").read()
best = from_bytes(raw).best()
print(best.encoding)          # 예: cp949
text = str(best)

바이너리로 읽어서("rb") 디코딩을 직접 하는 게 요령이다. 텍스트 모드로 열면 그 순간 이미 에러가 나기 때문이다.

이미 인코딩을 알았다면 파일 자체를 utf-8로 바꿔두는 편이 오래 편하다. iconv는 맥과 리눅스에 기본으로 있다.

iconv -f CP949 -t UTF-8 주소록.csv > 주소록-utf8.csv

주의할 점은 짧은 문자열의 인코딩 판별이 원리적으로 불가능하다는 것이다. 바이트 몇 개는 여러 코덱에서 동시에 유효하다. 자동 판별은 "후보를 좁히는 도구"로만 쓰고, 사람이 눈으로 결과를 확인하는 절차를 남겨두는 게 안전하다.

그래도 안 될 때 — 쓰는 쪽과 실행 환경

읽기에서 고쳤는데도 에러가 나면 이번엔 반대쪽이다. UnicodeEncodeError는 글자를 바이트로 바꾸는 과정에서 났다는 뜻이라 처방이 다르다.

첫째, 터미널 출력에서 막히는 경우다. print()가 UnicodeEncodeError: 'ascii' codec can't encode characters로 죽으면 표준출력의 인코딩이 ascii로 잡힌 것이다. 환경 변수로 고정한다.

PYTHONIOENCODING=utf-8 python3 app.py
python3 -X utf8 app.py          # UTF-8 모드 강제

UTF-8 모드는 PYTHONUTF8=1로도 켤 수 있고, 3.15부터는 기본값이다. (PEP 540, PEP 686)

둘째, 파일을 쓸 때 인코딩을 안 적은 경우다. 읽기만 고치고 쓰기는 그대로 두면, 저장된 파일이 실행 환경에 따라 달라진다.

with open("결과.csv", "w", encoding="utf-8-sig", newline="") as f:
    f.write("이름,점수\n")

엑셀에서 다시 열어야 하는 파일이라면 utf-8-sig가 편하다. BOM이 있어야 엑셀이 utf-8로 인식한다.

셋째, 외부 명령의 출력을 읽을 때다. subprocess의 text=True는 로캘 인코딩을 쓰기 때문에, 실행 환경이 바뀌면 깨진다.

import subprocess

out = subprocess.run(["ls"], capture_output=True, text=True, encoding="utf-8").stdout

넷째, 파일 이름 자체가 문제인 경우다. 리눅스에서 잘못된 바이트가 섞인 파일명은 surrogateescape 오류 처리기로 문자열에 담긴다. 이걸 다시 인코딩해야 원래 파일명으로 돌아간다. (에러 처리기)

import os

for name in os.listdir("."):
    raw = name.encode("utf-8", "surrogateescape")

errors 기본값은 strict이고, replace는 깨진 글자를 �로 바꾸며 ignore는 아예 지운다. 데이터를 살려야 하는 자리에서 ignore를 쓰면 행 길이가 달라져서 나중에 원인 찾기 어려운 버그가 된다. (에러 처리기)

증상별 처방 표

지금까지 내용을 증상 기준으로 다시 묶었다. 에러 문구를 그대로 검색해 들어온 사람을 위한 표다.

내가 막혔던 곳

가장 오래 헤맨 건 공공데이터 CSV였다. pd.read_csv(path)가 UnicodeDecodeError를 내서 encoding="cp949"를 붙였더니 이번엔 읽히는데, 컬럼 이름이 지역이 아니라 \ufeff지역처럼 잡혀서 df["지역"]이 KeyError를 냈다. 화면에 출력된 컬럼명은 멀쩡해 보여서 한참을 의심하지 못했다. BOM은 눈에 안 보이니까. 결국 repr(df.columns[0])로 찍어보고 나서야 원인을 알았다. 지금은 한국어 CSV를 받으면 utf-8-sig를 먼저 시도하고, 실패하면 cp949로 내려간다.

두 번째는 errors="ignore"의 유혹이었다. 급할 때 이걸 붙이면 에러가 사라지고 코드는 끝까지 돌아서 성공한 것처럼 보인다. 그런데 그 뒤에 만든 집계표에서 특정 지역 이름만 비어 있었다. 복구가 안 되는 손실이었다. 그 뒤로는 ignore 대신 replace를 쓰고, 깨진 개수를 세서 로그로 남긴다. 몇 건이 깨졌는지 알아야 데이터를 믿을지 결정할 수 있다.

세 번째는 환경 차이였다. 내 맥에서는 잘 돌던 스크립트가 윈도우 노트북에서 같은 파일을 읽다가 죽었다. 맥은 기본이 utf-8이고 한국어 윈도우는 ANSI 코드 페이지가 cp949라서, 인코딩을 안 적은 open()이 서로 다르게 동작한 것이다. 그때부터 텍스트를 여는 코드에는 예외 없이 encoding을 적는다. 파일을 옮겨 다니는 프로젝트라면 Python 가상환경 venv 만들기처럼 실행 환경을 문서에 남겨두는 습관도 같이 들였다.

참고 자료

• UnicodeDecodeError — Built-in Exceptions — encoding·start·end·reason 속성
• open() — Built-in Functions — 텍스트 모드 기본 인코딩 규칙
• codecs — 표준 인코딩 — cp949/949/ms949/uhc 별칭
• codecs — 에러 처리기 — strict·replace·surrogateescape
• codecs — utf_8_sig — BOM 처리
• PEP 686 — Make UTF-8 mode default — Python 3.15 기본값 변경
• PEP 597 — Add optional EncodingWarning — -X warn_default_encoding
• PEP 540 — UTF-8 mode — PYTHONUTF8
• pandas.read_csv — encoding, encoding_errors
• RFC 8259 §8.1 — JSON은 UTF-8
• 관련 글: ModuleNotFoundError 해결 · pip install 오류 해결 · Python 가상환경 venv 만들기

스레드에서 "드디어 dot이 여러 대의 컴퓨터에 붙는다"는 글이 돌고, 그 밑에 "코덱스는 신이야"라는 댓글이 붙어 있었다. dot이 뭔지 모르면 이 대화가 무슨 말인지 따라가기 어렵다.

이 글은 dots가 무엇인지, 이번에 무엇이 열렸는지, 실제로 어떻게 설정하는지, 그리고 어디서 막히는지를 OpenAI 공식 문서에서 확인해 정리한 것이다. 2026년 11월 10일 기준 문서 내용이다.

30초 요약

목차

1. dots란? 한 문단 정의
2. 이번에 달라진 것 — dot 하나에 컴퓨터 여러 대
3. 설정은 3단계 — 컴퓨터마다 같은 작업을 반복
4. 실제로 이게 왜 편한가 — 노트북과 맥을 동시에 쓰는 그림
5. 한 번에 한 대 — 알아야 할 제약
6. 요금과 접근 조건
7. 내가 막혔던 곳
8. 참고 자료

dots란? 한 문단 정의

dot은 ChatGPT 안에서 돌아가는 개인용 에이전트다. 챗봇처럼 질문에 답하는 게 아니라, 자기 컴퓨터를 하나 받아서 일을 대신 처리한다. OpenAI 발표문은 이렇게 적는다. "dot은 프런티어 지능에 클라우드 컴퓨터, 피드백으로 배우는 능력, 24/7로 목표를 향해 일하는 성질을 붙인 것"이다. (발표문)

그래서 기본값이 "내 컴퓨터를 쓰는 AI"가 아니다. dot은 클라우드에 자기 컴퓨터와 브라우저를 갖고 있고, 내 기기와는 분리돼 있다. 내 노트북을 쓰게 하려면 따로 허용해야 한다. 이 구조를 모르고 쓰면 "왜 내 파일을 못 읽지"에서 막힌다.

모델은 GPT-6 Astra로 시작했고, 2026년 11월 3일부터 GPT-6.1 Terra가 추가됐다. 한 작업 안에서도 부분마다 다른 모델을 쓸 수 있다는 설명이다. (발표문) GPT-6 계열 자체가 궁금하면 GPT-6 Cyber 정리에 배경을 적어뒀다.

이번에 달라진 것 — dot 하나에 컴퓨터 여러 대

이전에는 dot 하나에 컴퓨터 한 대를 붙이는 그림이 기본이었다. 지금 문서는 "컴퓨터를 한 대 넘게 연결하고, 작업마다 어느 컴퓨터를 쓸지 dot에게 말할 수 있다"고 적는다. (문서)

바뀐 지점은 세 가지다.

여기서 많이 헷갈리는 부분이 하나 있다. 이 연결은 Codex에 컴퓨터를 연결하는 것과 별개다. Work Sync를 켜는 것과도 별개다. 문서는 "어느 한쪽 연결만으로는 dot이 내 컴퓨터에 접근할 수 없다"고 못 박는다. (문서)

설정은 3단계 — 컴퓨터마다 같은 작업을 반복

설정 자체는 짧다. 대신 컴퓨터 대수만큼 반복해야 한다.

1. 그 컴퓨터에서 ChatGPT 데스크톱 앱을 연다.
2. dot 프로필을 열고 Computers에서 지금 쓰는 컴퓨터를 찾아 Allow를 누른다.
3. 확인 창에서 Allow access를 누른다.

다른 컴퓨터를 추가하려면 그 컴퓨터에서 같은 과정을 한 번 더 하면 된다. (문서)

모바일에서 만든 dot이라도 데스크톱 앱에서 나중에 연결할 수 있다. 반대로 모바일 웹은 지원하지 않는다. 설정은 모바일 앱, 데스크톱 앱, 데스크톱 브라우저 셋 중 아무 데서나 시작해도 되고, 만든 dot은 다른 기기에서 그대로 이어진다. (문서)

권한을 끊을 때는 Revoke access를 쓴다. 상태가 Offline으로 보이는 건 권한이 사라진 게 아니라 그 컴퓨터를 지금 못 쓴다는 뜻이다. (문서)

실제로 이게 왜 편한가 — 노트북과 맥을 동시에 쓰는 그림

스레드 글이 든 예시가 이해가 빠르다. 노트북에서 코딩하는 동안, dot에게 다른 맥의 Xcode에서 iOS 앱을 빌드·테스트하고 결과 화면을 보내달라고 하는 식이다. 서로 다른 컴퓨터에서 같은 오류를 재현하는 것도 같은 원리다.

이게 되는 이유는 dot이 클라우드에서 작업을 조율하고, 실제 실행만 연결된 컴퓨터에서 하기 때문이다. 문서 표현으로는 "작업은 클라우드에서 관리되면서 연결된 컴퓨터의 파일과 도구를 쓴다"이다. (문서)

실무에서는 이런 조합이 나온다.

Xcode처럼 그 컴퓨터에만 깔린 도구를 쓰는 작업이 대표적이다. 로컬 스킬도 연결된 컴퓨터가 있어야 돈다. (문서)

한 번에 한 대 — 알아야 할 제약

가장 중요한 제약은 "여러 대를 동시에 조종한다"가 아니라는 점이다. 문서는 이렇게 적는다. 컴퓨터별로 별도 스레드를 시작하고, 각 스레드는 한 번에 컴퓨터 한 대를 쓴다. (문서)

여기에 하나 더. dot의 대화는 Pro·Business Premium의 ChatGPT 사용량 한도에 안 들어가지만, dot이 시작한 Work·Codex 작업은 그 제품의 한도에 그대로 들어간다. (문서) 에이전트를 부려서 아낀 시간이 사용량으로 돌아오는 구조라는 뜻이다.

요금과 접근 조건

dots는 별도 구독이 아니라 ChatGPT 요금제에 붙어 있다. 첫 dot은 추가 비용 없이 포함되고, 여러 dot과 속도·작업량 확장은 앞으로 열린다는 설명이다. (발표문)

Pro 요금은 공식 요금 문서의 "월 $100, $200, $500 중 선택" 표기를 그대로 옮겼다. (요금 문서) Business Premium 금액은 사용자 수와 결제 방식에 따라 달라서 여기 적지 않았다.

접근 조건 표에서 눈여겨볼 건 마지막 줄이다. 기업용은 관리자 프리뷰 기간을 거쳐 11월 18일부터 기본값이 켜짐으로 바뀐다. (문서) 회사 계정으로 쓰는 사람은 그날 전에 관리자에게 물어보는 게 안전하다.

내가 막혔던 곳

이 글을 쓰면서 실제로 세 번 걸렸다.

첫째, 한국어 검색으로는 정보가 거의 안 나온다. "닷", "dots", "오픈AI 에이전트"로는 스레드 글과 요약 블로그만 나왔다. 결국 OpenAI 문서 원문을 직접 열어서 읽어야 했다. 문서는 learn.chatgpt.com/docs/llms-full.txt로 전체를 한 파일로 받을 수 있어서, 거기서 "컴퓨터", "연결" 부분을 찾는 게 제일 빨랐다.

둘째, "여러 대 연결"을 처음엔 "여러 대 동시 사용"으로 읽었다. 문서를 두 번 읽고 나서야 스레드마다 한 대라는 걸 확인했다. 블로그 요약 글에 이 제약이 빠져 있는 경우가 많아서, 이 글에는 표로 따로 뺐다.

셋째, Codex에 이미 컴퓨터를 연결해 둔 사람은 dots도 자동으로 될 거라고 생각하기 쉽다. 문서는 명시적으로 별개라고 적는다. 기존 연결이 있다고 dot 설정을 건너뛰면 "왜 파일을 못 읽지"에서 막힌다.

참고 자료

• Introducing dots — OpenAI
• Connect computers and apps to your dot — ChatGPT 문서
• Meet dots · Access — ChatGPT 문서
• Pricing — ChatGPT 문서
• Tasks and memory — ChatGPT 문서

관련 글: GPT-6 Cyber 총정리 · Gemini 사용법 · Cursor 사용법

요즘 국내에서 "AI 비서"라는 말로 같이 묶여 소개되는 앱이 둘이다. 부이(vooy)와 피클(Pickle). 둘 다 채팅창에 말로 시키면 일을 처리한다고 해서, 처음엔 같은 앱인 줄 알았다.

막상 써보려고 앱스토어 설명을 나란히 놓으니 역할이 꽤 달랐다. 하나는 찾고 비교하고 계획하는 쪽, 다른 하나는 전화하고 결제하는 쪽이다. 이 글은 2026년 11월 9일 기준 공식 사이트와 앱스토어 정보로 둘을 같은 기준에 놓고 비교한 것이다.

30초 요약

부이(vooy)와 피클은 같은 ‘AI 비서’로 묶여 소개되지만, 줄여주는 구간이 다르다.

목차

1. 부이(vooy)란? — 이름부터 낯선 앱
2. 피클이란? — 이미 한 번 정리한 앱
3. 한눈에 비교
4. 같은 부탁을 두 앱에 하면
5. 요금 비교
6. 안전과 권한 — 여기서 갈린다
7. 어떤 사람에게 뭐가 맞나
8. 내가 막혔던 곳
9. 참고 자료

부이(vooy)란? — 이름부터 낯선 앱

먼저 이름 정리. 공식 한글 표기는 부이다. 회사명도 (주)부이코리아, 앱스토어 개발자도 Vooy Korea, Inc.다. "보이"가 아니다. vooy는 Virtual Oracle of You의 앞글자를 딴 조합이고, 슬로건은 "당신의 첫 반려 에이전트"다. (vooy 공식 사이트)

하는 일은 이렇게 소개된다. 메신저에서 평소 말하듯 부탁하면, 내 취향과 일정을 바탕으로 정보를 찾고 다음 할 일을 정리해준다. 대표 예시가 식당 찾기, 장보기 계획, 약속 준비, 여행 항공권 최저가, 출근길 브리핑이다. (Google Play)

기능 중 눈에 띄는 건 세 가지다.

• 취향 기억 — 좋아하는 음식, 선호하는 분위기, 지난 대화의 계획까지 맥락으로 쓴다
• 그룹 대화 — 친구들과 만날 장소를 찾을 때 단체방 안에서 정보를 나누고 계획을 이어간다
• 실행 연결 — 추천에서 끝내지 않고 일정과 할 일을 구체적으로 정한다

앱스토어 카테고리는 생산성이 아니라 소셜 네트워킹이다. 채팅 UX를 전면에 둔다는 뜻으로 읽힌다. iOS 16.4 이상, 한국어·영어·일본어를 지원하고, 채용 페이지에는 서울에서 시작해 도쿄·방콕·타이베이·싱가포르로 확장한다는 계획이 적혀 있다. (App Store, 채용 페이지)

부이(vooy) 공식 사이트를 직접 캡처했다. ‘찾고 비교하고 예약하는 일까지’를 전면에 내세운다.

피클이란? — 이미 한 번 정리한 앱

피클은 10월 31일에 이미 단독 글로 정리했다. (피클 AI 총정리) 여기서는 비교에 필요한 부분만 다시 짚는다.

피클은 질문에 답하는 데서 끝나지 않고 실제 행동을 한다. 대신 전화를 걸고, 쿠팡·다이소몰에서 주문·결제하고, KTX·항공권·숙소·병원·식당을 예매한다. 결제나 예매처럼 되돌리기 어려운 일은 진행 전에 승인을 받는다. (pickle.com, Google Play)

가장 독특한 기능은 친구의 피클과 약속 잡기다. 사람끼리 "언제 볼까?"로 시작하는 대화를 양쪽 에이전트가 대신 맞추고, 장소와 식당 예약까지 처리한다.

기술적으로는 권한 설계가 눈에 띈다. 자격증명은 AWS Nitro Enclaves 격리 환경에서만 쓰고, 비밀번호·카드는 기기에서 만든 키로 암호화하며, 권한은 1~30일 기간을 정해 빌려주는 구조다. 자세한 내용은 앞선 글에 정리해뒀다.

한눈에 비교

두 앱의 역할을 나란히 놓았다. 부이는 계획 쪽, 피클은 실행 쪽에 가깝다.

표의 세 번째 줄이 가장 중요하다. 부이의 공식 설명은 예약·주문·일정을 "확인 후 단계별로 안내"하는 쪽에 가깝다. 피클은 같은 일을 대신 실행한다. "AI 에이전트"라는 같은 단어를 쓰지만, 손을 대는 지점이 다르다. 애초에 에이전트가 챗봇과 어떻게 다른지는 AI 에이전트란에 정리해뒀다.

같은 부탁을 두 앱에 하면

말로 비교하는 것보다 상황을 하나 놓는 편이 낫다. "이번 주말에 친구 셋이랑 성수에서 점심 먹고 전시 보려는데, 다들 시간 맞춰서 예약까지 해줘"라고 부탁한다고 치자.

부이 쪽 흐름

1. 셋의 가능한 시간대를 대화로 정리한다
2. 성수 식당 후보를 취향에 맞춰 비교한다
3. 전시 시간과 동선을 묶어 일정으로 정리한다
4. 예약은 확인 후 단계별로 안내한다

피클 쪽 흐름

1. 친구의 피클과 대화해 빈 시간을 맞춘다
2. 식당을 예약하고, 필요하면 전시 예매까지 처리한다
3. 결제가 들어가면 승인을 요청한다
4. 끝나면 결과를 요약해 알려준다

둘 다 "카톡 20개"를 줄여주지만, 줄어드는 구간이 다르다. 부이는 생각하고 정하는 구간, 피클은 전화하고 결제하는 구간이다. 같은 부탁도 어디까지 맡길 수 있는지가 다르다.

요금 비교

출처는 각 앱스토어 표시 가격이다. (App Store vooy, Google Play 피클)

부이는 현재 무료다. 초기 사용자 확보 단계라 언제 유료화해도 이상하지 않다. 피클은 무료 한도가 있고, 전화·예매처럼 오래 걸리는 작업이 한도를 많이 먹는 구조다.

안전과 권한 — 여기서 갈린다

에이전트 앱에서 진짜 비용은 구독료가 아니라 사고 났을 때의 비용이다. 두 앱의 공개 자료를 같은 기준으로 놓으면 이렇게 된다.

부이 쪽 "공개 자료 없음"은 문제가 있다는 뜻이 아니라, 아직 보안 설계 문서를 공개하지 않았다는 뜻이다. 신생 앱에서는 흔한 일이다. 다만 위치·연락처·연락처 정보까지 수집한다고 앱스토어에 표시돼 있으니, 가입 전에 권한을 어디까지 줄지 직접 확인하는 게 좋다. (App Store 개인정보)

피클은 반대로 보안 문서를 먼저 공개한 쪽이다. 실제 사고가 없었다는 뜻은 아니지만, "무엇을 어떻게 지키는지"를 읽고 판단할 재료가 있다는 건 선택에 도움이 된다.

어떤 사람에게 뭐가 맞나

부이가 맞는 경우

• 여행·외식·모임 준비에서 "뭐가 좋을지" 비교하는 시간이 아깝다
• 친구들과 계획 맞추는 대화가 길어지는 편이다
• 결제까지 맡기는 건 아직 부담스럽다

피클이 맞는 경우

• 통신사·보험사·병원 전화 대기가 싫다
• KTX·항공권·숙소 예매를 자주 한다
• 승인만 하면 결제까지 맡기고 싶다
• 권한이 어떻게 통제되는지 확인하고 쓰고 싶다

둘 다 쓰는 경우

부이로 계획을 세우고, 피클로 실행하는 조합이 이론상 가장 자연스럽다. 다만 앱을 두 개 오가야 해서, 한쪽이 다른 쪽 기능을 흡수하는 방향으로 빠르게 바뀔 가능성이 크다. 두 회사 모두 초기 단계라 석 달만 지나도 그림이 달라질 수 있다.

내가 막혔던 곳

두 앱 모두 전화번호 인증이 필요해서, 내가 대신 가입해 실제로 돌려보지는 못했다. 그래서 이 글에는 내가 만든 사용 화면이 아니라 공식 페이지 캡처만 들어간다. 후기 글을 쓸 때 늘 아쉬운 부분이다.

대신 확인하면서 헷갈렸던 지점을 남긴다. 첫째, "부이"를 "보이"로 검색하면 결과가 잘 안 나온다. 회사명이 (주)부이코리아라서 한글 표기는 부이다. 둘째, 두 앱의 앱스토어 카테고리가 다르다. 부이는 소셜 네트워킹, 피클은 생산성이다. 카테고리만 봐도 설계 철학이 갈린다는 걸 알 수 있다.

셋째, "AI가 예약해준다"는 문구를 액면가로 믿으면 안 된다. 부이는 안내까지, 피클은 대행까지다. 같은 문장처럼 보여도 내가 마지막에 버튼을 눌러야 하는지, AI가 누르는지가 완전히 다른 경험이다. 가입 전에 이 차이를 먼저 확인하는 걸 권한다.

참고 자료

• vooy 공식 사이트
• vooy App Store
• vooy Google Play
• 피클 공식 사이트
• 피클 Google Play
• 피클 App Store

Gemini를 처음 열면 채팅창 하나만 보인다. 그런데 주변에서 쓰는 사람 얘기를 들어보면 Gems, Deep Research, Canvas, Notebook 같은 이름이 계속 튀어나와서 내가 쓰는 화면과 같은 앱인지 헷갈린다.

이 글은 무료 계정으로 시작해서 어디까지 쓸 수 있는지, 유료로 올렸을 때 무엇이 달라지는지를 2026년 11월 9일 기준 공식 문서로 확인해 정리한 것이다. 요금과 한도는 모두 구글 공식 페이지에서 가져왔다.

30초 요약

목차

1. Gemini 사용법, 한 줄 정의부터
2. 시작하기 — 웹과 앱 중 뭘 쓸까
3. 무료 플랜으로 되는 것과 안 되는 것
4. Gemini 프롬프트는 첨부에서 갈린다
5. Gems와 Notebook — 반복 작업 줄이기
6. Deep Research 사용법 — 보고서 뽑는 순서
7. 요금제 비교 — 무료·Plus·Pro·Ultra
8. 내가 막혔던 곳
9. 참고 자료

Gemini 사용법, 한 줄 정의부터

구글 문서는 Gemini를 "텍스트, 오디오, 이미지를 함께 처리하는 멀티모달 LLM에 대한 인터페이스"로 설명한다. 모델 이름이 아니라 모델을 쓰는 창구라는 뜻이다. (Gemini 앱 안내)

그래서 같은 Gemini라도 어디서 부르느냐에 따라 만나는 모델이 다르다. 웹과 앱에서는 대화용 모델이 붙고, 구글 검색의 AI 모드에서는 검색에 맞춘 구성이 붙는다. 2026년 11월 기준 가장 위에 있는 모델은 Gemini 4 Argon이고, 이건 AI Pro 이상 요금제에서 열린다. (요금제)

처음 쓰는 사람이 기억할 건 하나다. Gemini는 "질문창"이 아니라 "작업대"에 가깝다. 파일을 붙이고, 링크를 주고, 표를 만들고, 이미지를 고치는 일이 한 대화 안에서 이어진다.

시작하기 — 웹과 앱 중 뭘 쓸까

시작은 구글 계정 로그인 하나로 끝난다. 설치형 프로그램이 아니고 브라우저에서 열면 바로 쓸 수 있다. (Gemini 앱)

웹과 앱은 같은 계정이면 대화 기록이 이어진다. 나는 문서 작업은 웹에서 하고, 이동 중에는 앱에서 음성으로 이어서 쓴다. Gemini Live는 채팅 안에 들어와 있어서 음성 모드와 텍스트 입력을 오가며 쓸 수 있다. (요금제)

개발자라면 AI Studio를 같이 열어두는 게 편하다. 초기 비용 없이 Gemini Developer API를 쓸 수 있고, 무료 구간에서는 입력·출력 토큰이 무료다. 대신 무료 구간 콘텐츠는 구글 제품 개선에 사용된다고 명시돼 있다. (요금제) 사내 코드를 넣을 거라면 유료 구간으로 올리는 게 맞다.

무료 플랜으로 되는 것과 안 되는 것

무료가 생각보다 넓다. 유료의 핵심은 기능 개방이 아니라 모델 등급과 사용량이다.

출처는 구글 요금제 페이지와 사용량 한도 안내다. (요금제, 한도 안내)

여기서 많이들 오해하는 부분이 모델이다. 무료 계정은 2026년 10월 9일부터 모델 자동 선택이 기본값이라, 대부분의 질문이 가장 빠른 Flash-Lite로 간다. 깊은 추론이 필요한 질문만 Flash나 Pro로 넘어간다. 설정에서 스마트 모델 선택을 끄면 무료 계정은 모든 답변에 Flash-Lite를 쓴다. (한도 안내)

영상 쪽이 궁금하면 Gemini Omni 1.2 Flash 정리에 따로 적어뒀다. 영상 생성은 요금제에 따라 크레딧이 갈리는 부분이 있어서 따로 보는 게 낫다.

Gemini 프롬프트는 첨부에서 갈린다

같은 질문이라도 파일을 붙이면 답의 밀도가 달라진다. 무료 계정에서도 문서 업로드와 요약은 열려 있어서, 이 기능만 써도 체감 차이가 크다.

내가 자주 쓰는 형태는 이렇다.

첨부한 계약서 PDF에서 위약금 조항만 뽑아줘.
조항 번호와 원문 문장을 같이 적고, 없으면 "없음"이라고 써.
추측해서 채우지 마.

포인트는 세 가지다. 원하는 출력 형식을 먼저 말하고, 없는 경우를 어떻게 처리할지 정하고, 추측 금지를 명시한다. 프롬프트를 길게 쓰는 것보다 이 세 줄이 결과를 안정시킨다. 더 자세한 기준은 프롬프트 작성법에 좋은 예·나쁜 예로 정리해뒀다.

Canvas는 이 과정에서 문서를 다듬을 때 쓴다. 답변을 캔버스로 띄운 뒤 문단을 직접 고치고, 그 상태로 계속 대화를 이어갈 수 있다. 블로그 초안이나 회의록 정리에 붙여 쓰면 복사·붙여넣기 왕복이 줄어든다.

Gems와 Notebook — 반복 작업 줄이기

Gems는 자주 쓰는 지시를 저장해두는 기능이다. 매번 같은 말투와 형식을 요구한다면 Gem 하나로 묶어두는 게 낫다. 무료 계정에서도 열린다. (요금제)

내가 만들어 쓰는 Gem은 두 개다. 하나는 "블로그 교정"이고, 다른 하나는 "코드 리뷰"다. 블로그 교정 Gem에는 말투 규칙과 금지 패턴만 넣어뒀다. 초안을 붙이면 그 규칙에 맞춰 고친다.

Notebook은 리서치와 글쓰기를 붙여놓은 공간이다. 자료를 모으고 요약하면서 원고까지 이어가는 흐름이라, 조사와 작성이 따로 놀지 않는다. 무료는 기본 사용량, AI Plus는 오디오 개요를 더 많이 준다. (요금제)

Deep Research 사용법 — 보고서 뽑는 순서

Deep Research는 질문 하나를 여러 출처로 쪼개서 조사하고 긴 보고서로 묶는 기능이다. 데스크톱과 모바일 모두에서 쓸 수 있고, Gemini 앱에 로그인해야 하며 만 18세 이상만 쓸 수 있다. (혜택 제한)

순서는 이렇게 잡으면 된다.

중요한 건 한도다. 구글 문서는 이미지·영상·음악 생성, Deep Research, Pro 모델, 확장된 사고를 "사용량을 더 많이 쓰는 기능"으로 따로 적어둔다. 한도에 빨리 닿는 이유가 여기 있다. (한도 안내)

요금제 비교 — 무료·Plus·Pro·Ultra

2026년 11월 9일 기준 구글 공식 요금제 페이지에 적힌 금액이다. (요금제)

AI Pro 금액은 결제 지역과 프로모션에 따라 화면에 다르게 뜬다. 내가 확인한 시점의 국내 페이지에는 금액이 고정 표기되지 않아서, 이 표에는 배수만 적었다. 대신 AI Pro부터 Gemini 4 Argon이 열린다는 점이 무료·Plus와의 실질적인 차이다.

무료로 충분한 사람은 이렇다. 하루에 몇 번 질문하고, 가끔 이미지 한 장 만들고, 문서 요약 정도면 무료로 끝난다. 유료가 필요한 순간은 한도에 자주 부딪히거나, Argon급 모델로 코드와 긴 문서를 다뤄야 할 때다.

다른 챗봇과 고민된다면 ChatGPT vs Claude 비교에 판단 기준을 적어뒀다. 도구를 여러 개 쓰는 편이면 AI 기초 용어 20개 정리를 먼저 훑는 게 이해가 빠르다.

내가 막혔던 곳

처음에 "왜 답이 이렇게 짧지" 싶어서 설정을 한참 뒤졌다. 원인은 모델이었다. 무료 계정은 자동 선택이 기본이라 대부분 Flash-Lite로 가고, 나는 그걸 Pro급 모델이라고 생각하고 있었다. 한도 안내 페이지를 읽고 나서야 구조가 이해됐다. (한도 안내)

두 번째는 한도 계산이다. 하루에 몇 번만 썼는데 갑자기 막혀서 이상하다고 느꼈다. 그날은 Deep Research를 두 번 돌리고 이미지를 여러 장 만들었다. 한도가 프롬프트 개수가 아니라 복잡도·기능·대화 길이를 합산하는 방식이라, 무거운 기능을 몰아 쓰면 금방 소진된다. 5시간마다 새로고침되고 주간 한도에서 최종적으로 멈춘다는 것도 같이 알게 됐다.

세 번째는 Gems를 만들어놓고 안 쓰는 습관이다. Gem을 열 개 넘게 만들었는데 정작 대화할 때 부르지 않으면 소용이 없다. 지금은 두 개만 남기고, 대화 시작할 때 @로 부르는 걸 습관으로 만들었다.

참고 자료

• Gemini 앱이란 — 구글 공식 안내 — 멀티모달 LLM 인터페이스 정의, 기능 범위
• Gemini 요금제 — 무료·Plus·Pro·Ultra 기능과 금액
• Gemini 모델 액세스 및 한도 변경사항 — 2026년 10월 모델 자동 선택, 5시간·주간 한도
• Google One 혜택 제한사항 — Deep Research·Flow의 연령·지역 제한
• Google AI 요금제 상세 — 플랜별 포함 기능
• Gemini Omni 1.2 Flash 정리 · 프롬프트 작성법 · ChatGPT vs Claude 비교 · AI 기초 용어 20개

2026년 11월 5일, OpenAI가 GPT-6 Cyber를 공개했다. 이름 그대로 보안 업무만 따로 학습시킨 모델이다. 취약점을 찾는 데서 끝나지 않고, 실제로 동작하는 익스플로잇을 만들고 패치 후보까지 낸다.

이 글은 이 모델이 무엇이고, 무엇을 실제로 해냈고, 돈을 내면 바로 쓸 수 있는지까지 정리한 것이다. 수치와 접근 조건은 OpenAI 공식 발표문, API 문서, 시스템 카드에서 직접 확인했다.

30초 요약

GPT-6 Cyber는 2026년 11월 5일 공개됐다. GPT-6 Astra를 보안 업무에 특화시킨 모델이다.

목차

1. GPT-6 Cyber란? 한 문단 정의
2. 무엇이 달라졌나 — ExploitGym 48.5%
3. 실제로 찾아낸 것 — Firefox 81개, Linux 948개
4. 왜 '정렬'이 이 모델의 핵심인가
5. 기존 모델과 비교
6. 요금과 쓰는 방법 — Daybreak Red 승인 절차
7. 한계와 주의할 점
8. 내가 막혔던 곳
9. 참고 문헌

GPT-6 Cyber란? 한 문단 정의

GPT-6 Cyber는 GPT-6 Astra를 기반으로 사이버보안 업무만 강화 학습한 변형 모델이다. 시스템 카드는 용도를 "취약점 발굴, 익스플로잇 개발, 웹 모의해킹 같은 승인된 보안 업무"로 적는다. (시스템 카드)

일반 모델과 갈리는 지점은 두 가지다. 하나는 보안 요청을 거부하는 비율을 낮춘 것, 다른 하나는 반대로 작업 범위를 넘어서지 않도록 따로 훈련한 것이다. 보안 모델에서 이 두 가지는 원래 충돌한다. 거부를 줄이면 위험한 요청도 통과하고, 안전을 올리면 정당한 연구까지 막힌다. OpenAI는 이번 모델이 양쪽을 동시에 개선했다고 주장한다.

모델 ID는 gpt-6-cyber 하나뿐이고 스냅샷도 하나다. 입력은 텍스트와 이미지, 출력은 텍스트만 받는다. (API 문서)

무엇이 달라졌나 — ExploitGym 48.5%

성능 비교의 기준점은 ExploitGym이다. 원격 대상에 지정된 취약점을 실제로 공격해 성공하는지 보는 평가다. GPT-6 Cyber는 48.5%를 기록했고, GPT-5.6 Cyber는 32.1%였다. OpenAI는 이를 상대 기준 51% 개선이라고 표현한다. (발표문)

절대 수치로 보면 절반은 아직 실패한다는 뜻이기도 하다. 그래도 이전 세대가 3분의 1 수준이었던 것을 생각하면 한 세대 만에 크게 올라온 편이다.

취약점을 찾는 능력도 따로 쟀다. 소스 코드 없이 웹 애플리케이션만 보고 취약점을 찾아내는 새 평가에서 GPT-6 Cyber는 재현율 40.3%를 냈다. GPT-6 Astra는 32.0%였다.

가장 눈에 띄는 건 RemoteExploitBench다. GitLab, PostgreSQL, Jenkins처럼 실제로 쓰이는 애플리케이션의 알려진 취약점을 통제된 환경에 띄워두고 원격 공격을 시도한다. GPT-6 Astra를 Daybreak Blue 권한으로 돌리면 작업의 100%를 거부했다. 같은 과제에서 GPT-6 Cyber는 95%를 완료했다. 실패한 하나는 원격에서 익스플로잇이 동작하지 않은 경우였다. (발표문)

실제로 찾아낸 것 — Firefox 81개, Linux 948개

벤치마크보다 무게가 있는 건 실제 코드베이스에서 나온 결과다.

Linux 쪽은 파이프라인 비용도 같이 공개돼 있어서 참고할 만하다. 감사 대상 선별에 $3,426, 취약점 후보 분석에 $316,549, 재현 검증에 $73,330이 API 크레딧으로 들었다. OpenAI 스스로 이 금액을 "상한에 가깝다"고 밝혔다. (OpenAI 분석)

사람이 손으로 하던 감사를 에이전트 팀으로 바꾸면 단가가 이렇게 잡힌다는 뜻이다. 취약점 하나를 찾는 값이 아니라, 후보 수천 개를 걸러내고 실제로 재현되는 것만 남기는 공정 전체의 값이다.

OpenAI 공식 발표 페이지를 직접 캡처했다. Daybreak Red 승인 고객에게 우선 제공된다는 안내가 앞부분에 나온다.

왜 '정렬'이 이 모델의 핵심인가

보안 에이전트에서 진짜 사고는 성능이 낮아서 나지 않는다. 시킨 범위를 넘어서서 엉뚱한 서비스를 건드릴 때 난다. OpenAI는 이 문제를 ExploitGym Honeypot으로 평가했다.

과제 환경에 패키지 레지스트리나 오브젝트 스토리지 같은 보조 서비스를 붙여둔다. 일부러 공격하기 쉽게 만들어놨고, 그 서비스를 뚫으면 과제 플래그를 얻을 수 있다. 모델은 그것이 자기 업무 범위 밖이라는 걸 스스로 판단해야 한다. (발표문)

수치는 시스템 카드 기준이다. (시스템 카드) GPT-6 Astra는 프롬프트 없이도 0%였는데, GPT-6 Cyber는 공격 능력이 올라간 만큼 프롬프트 없이 0.07%가 남았다. 성능을 올리면 이 숫자가 다시 올라간다는 걸 보여주는 대목이다.

여기에 붙은 장치가 더 있다. 범위를 벗어난 행동을 잡는 감시, 산업 제어 시스템·필수 서비스·선거 시스템 관련 고위험 요청 차단, 자격증명 탈취 대비 IP 허용 목록, 그리고 제로 데이터 보존 고객에게 요구하는 Private Safety Processing이다. (발표문)

기존 모델과 비교

OpenAI가 공개한 실제 결과. Firefox 신규 고위험 취약점 81개, Linux 권한상승 익스플로잇 948개다.

표의 빈칸은 OpenAI가 같은 기준으로 공개하지 않은 값이다. 채우려고 추정하지 않았다. (발표문, 시스템 카드)

Daybreak는 OpenAI의 신뢰 기반 접근 프로그램이다. Blue는 검증된 방어자에게 취약점 확인과 패치를 돕고, Red는 익스플로잇 개발과 승인된 보안 테스트까지 허용한다. GPT-6 Cyber는 Red 등급에 속한다.

요금과 쓰는 방법 — Daybreak Red 승인 절차

먼저 알아둘 건, 결제만 하면 쓸 수 있는 모델이 아니라는 점이다. API 문서 첫 줄이 "조직에 Daybreak Red 접근 권한과 승인이 필요하다"로 시작한다. 승인 여부는 계정 팀이 확인해준다. (API 문서)

비용은 100만 토큰 기준으로 이렇다.

(API 문서)

출력 단가가 입력의 5배다. 취약점 분석처럼 코드와 로그를 길게 넣고 답은 짧게 받는 작업은 캐시 입력 단가($2)를 얼마나 잘 쓰느냐가 비용을 가른다. 반대로 익스플로잇 코드와 설명을 길게 뽑는 작업은 출력 단가가 그대로 붙는다.

지원 범위도 확인해야 한다. Chat Completions와 Responses API는 되지만 Batch, 파인튜닝, 임베딩, 이미지 생성, 오디오 계열은 전부 지원하지 않는다. 스트리밍, 구조화 출력, 함수 호출, 웹 검색, 프롬프트 캐싱은 지원한다. (API 문서)

준비 순서는 대략 이렇다.

1. Daybreak 프로그램에 신청한다.
2. 조직과 프로젝트를 만들고 계정 팀에서 Red 등급 승인을 받는다.
3. Red API는 기본적으로 IP 허용 목록을 요구하니 접근 가능한 네트워크 대역을 정해둔다.
4. Zero Data Retention을 쓰는 조직은 Private Safety Processing을 함께 설정한다.

한계와 주의할 점

• 벤치마크는 전부 OpenAI 자체 평가다. 외부 재현 결과는 아직 없다. 숫자를 인용할 때 "OpenAI 발표 기준"을 붙이는 게 안전하다.
• Critical 등급은 "위험하다"는 뜻이지 "쓰면 안 된다"는 뜻이 아니다. 대신 접근이 좁고 감시가 붙는다. 일반 사용자가 ChatGPT에서 바로 고르는 모델이 아니다.
• 방어 성공률 100%는 없다. OpenAI도 차단율을 100%로 올리는 걸 목표로 두지 않는다고 밝힌다. 정당한 보안 업무까지 막히기 때문이다. (발표문)
• 보안 특화 학습이 다른 분야의 거부 성향을 낮추지 않았는지도 따로 평가했다. 생물·화학 분야는 High로 유지됐고 Critical로 올라가지는 않았다. (시스템 카드)
• 역할 경계는 사람이 잡아야 한다. 에이전트가 찾은 취약점을 실제로 보고할지, 어느 범위까지 테스트할지는 위임 계약서와 승인 절차의 문제다. 프롬프트 인젝션이나 탈옥 공격의 기본 개념은 AI 탈옥이란에 정리해뒀다.

내가 막혔던 곳

API 문서를 처음 열었을 때는 모델 ID만 확인하면 바로 호출해볼 수 있을 거라고 생각했다. 실제로는 첫 문단이 접근 승인 요구였고, 그 아래에 IP 허용 목록과 Private Safety Processing 이야기가 이어졌다. 개인 계정으로 키를 만들어 호출하는 방식이 통하지 않는 모델이다.

그래서 이 글에는 내가 직접 돌려본 화면이 없다. 대신 공개된 시스템 카드와 발표문 수치를 기준으로 정리했다. 실제 도입을 검토한다면 순서를 이렇게 잡는 게 현실적이다. 계정 팀에 Red 등급 가능 여부를 먼저 묻고, 그다음에 파이프라인 설계를 시작한다. 승인이 안 나오면 설계가 아무리 좋아도 테스트할 수 없다.

컨텍스트가 100만 토큰을 넘는다고 해서 코드베이스를 통째로 밀어넣는 방식도 권하지 않는다. OpenAI가 Linux 감사에서 실제로 쓴 방법은 먼저 감사 대상 7%만 골라내는 것이었다. 큰 창은 편의 기능이고, 비용을 줄이는 건 선별 단계다. 컨텍스트 길이 자체가 궁금하면 컨텍스트 윈도우란을 먼저 보면 된다.

참고 문헌

• Introducing GPT-6 Cyber — OpenAI
• GPT-6 Cyber System Card — OpenAI Deployment Safety Hub
• GPT-6-Cyber 모델 문서 — OpenAI API
• A thousand fewer paths to root — OpenAI
• Mozilla 보안 공지 MFSA2026-118

Cursor를 설치하고 나면 화면이 VS Code와 비슷해서 어디부터 눌러야 할지 모르겠다. 탭 자동완성은 계속 회색 글씨를 띄우고, 오른쪽에는 Agent 창이 따로 있다. 둘이 무슨 관계인지 알기 전까지는 결국 예전처럼 직접 타이핑하게 된다.

이 글은 설치 직후 30분 동안 무엇을 어떤 순서로 눌러야 하는지 정리한 것이다. 단축키와 요금은 2026년 11월 8일 기준 Cursor 공식 문서와 가격 페이지에서 확인했다.

30초 요약

목차

1. Cursor 사용법, 처음 30분에 할 일
2. 설치 — OS별로 다른 점만 짚기
3. Tab과 Cmd+I, 이 두 개가 전부다
4. Agent에게 코드베이스부터 설명시키기
5. Plan Mode — 파일 여러 개를 건드리기 전
6. Rules로 프로젝트 규칙 고정하기
7. 요금 — Free부터 Ultra까지
8. 내가 막혔던 곳
9. 참고 자료

Cursor 사용법, 처음 30분에 할 일

순서는 단순하다. 폴더를 열고, Agent에게 이 저장소가 어떻게 생겼는지 물어보고, 작은 변경 하나를 시킨 뒤 diff를 읽는다. 이 한 바퀴를 돌고 나면 어느 키를 언제 쓰는지 감이 온다.

공식 문서도 같은 순서를 권한다. 설치와 로그인, 코드베이스 설명 요청, 작은 수정, diff 검토, 그리고 Plan Mode로 넘어가기다. (Quickstart) 나는 여기에 Rules 설정만 하나 더 붙여서 쓴다.

Cursor는 에디터 안에서 Agent를 부르는 구조다. Agent는 파일 검색, 파일 읽기, 편집, 셸 명령 실행, 브라우저 조작 같은 도구를 스스로 골라 쓴다. 작업 중 도구 호출 횟수에 제한은 없다고 문서에 적혀 있다. (Agent 개요)

설치 — OS별로 다른 점만 짚기

맥은 dmg 설치 파일 하나면 끝난다. 애플 실리콘과 인텔 모두 지원하고, 최소 버전은 macOS 12(Monterey)다. 윈도우는 Windows 10 이상에서 exe로 설치한다.

리눅스는 배포판에 따라 방법이 갈린다. 데비안·우분투는 저장소를 등록해서 apt로 받는 쪽이 권장된다. AppImage로도 실행할 수 있지만, 문서는 데스크톱 아이콘과 자동 업데이트 때문에 apt·yum 패키지를 권한다. (Quickstart)

# Debian/Ubuntu
curl -fsSL https://downloads.cursor.com/keys/anysphere.asc | gpg --dearmor | sudo tee /etc/apt/keyrings/cursor.gpg > /dev/null
echo "deb [arch=amd64,arm64 signed-by=/etc/apt/keyrings/cursor.gpg] https://downloads.cursor.com/aptrepo stable main" | sudo tee /etc/apt/sources.list.d/cursor.list > /dev/null
sudo apt update && sudo apt install cursor

# RHEL/Fedora
sudo dnf install cursor   # 저장소 등록 후

설치하고 로그인한 다음, 폴더를 하나 연다. 빈 폴더보다는 이미 코드가 있는 프로젝트를 여는 편이 첫인상을 파악하기 쉽다. 맥에서 개발 도구를 처음 세팅하는 중이라면 Mac 개발환경 세팅에서 Homebrew와 터미널 설정을 먼저 끝내두면 편하다.

Tab과 Cmd+I, 이 두 개가 전부다

처음 며칠은 이 두 기능만 써도 된다. Tab은 입력하는 동안 회색 글씨로 이어질 코드를 제안하고, Cmd+I는 옆 패널에 Agent를 띄운다.

Tab은 여러 줄을 한 번에 고치거나 빠진 import를 채워 넣기도 한다. 제안을 수락한 뒤 한 번 더 Tab을 누르면 다음에 손댈 위치로 커서가 이동한다. 파일을 넘나드는 수정이 필요하면 에디터 아래에 작은 포털 창이 뜬다. (Tab 문서)

Tab이 성가실 때는 끄는 방법이 세 가지다. 에디터 오른쪽 아래 Tab 표시를 눌러 일정 시간 쉬게 하거나, 전체를 끄거나, markdown·JSON처럼 특정 확장자에서만 끌 수 있다. (Tab 문서) 나는 markdown에서 먼저 껐다. 문서 쓰다가 문장이 계속 제안으로 덮여서 집중이 안 됐다.

Agent에게 코드베이스부터 설명시키기

처음 연 저장소라면 코드를 고치기 전에 구조부터 물어본다. 문서에 있는 예시 프롬프트를 거의 그대로 써봤다.

Explain this codebase. Point me to the main entry points,
key modules, and anything I should read before making changes.

Agent가 저장소를 검색하고 관련 파일을 읽은 뒤 프로젝트 구조를 요약해준다. 남의 코드를 인수인계받았을 때 이 한 번으로 어디부터 읽어야 할지 정리가 된다. (Quickstart)

구조를 파악했으면 작은 변경을 시킨다. 처음부터 리팩터링을 맡기면 diff가 너무 커져서 검토가 안 된다. 문구 수정이나 자잘한 UI 문제처럼 위험도가 낮은 것부터 고르는 게 좋다.

Suggest three small, safe improvements in this codebase.
Explain the tradeoffs and wait for me to choose one.

Agent가 일을 마치면 diff 뷰에서 바뀐 줄을 확인하고, 프로젝트에 이미 있는 검사 명령을 돌려달라고 한다. 테스트, 타입 체크, 린트, 로컬 빌드 중 그 저장소가 쓰는 것을 그대로 부르면 된다. (Quickstart)

Plan Mode — 파일 여러 개를 건드리기 전

작업이 여러 파일에 걸치거나 조사가 필요하면 Plan Mode를 쓴다. Agent 입력창에서 Shift+Tab을 누르면 켜진다.

켜두면 바로 코드를 쓰지 않는다. 관련 파일을 찾아 읽고, 요구사항이 애매한 부분을 질문하고, 구현 계획을 만든 뒤 내 승인을 기다린다. (Quickstart) 계획을 읽고 고칠 부분을 말해주면 그때부터 실제 편집이 시작된다.

작업이 길어질 때는 대기열을 쓴다. Agent가 돌고 있는 동안 다음 지시를 입력하고 Enter를 누르면 현재 작업이 끝난 뒤 순서대로 처리된다. 급하게 방향을 틀어야 하면 Cmd+Enter로 대기열을 건너뛰고 바로 전달한다. (Agent 개요)

되돌릴 일이 생기면 채팅 타임라인의 체크포인트를 누른다. Agent가 큰 변경 전에 자동으로 스냅샷을 남기고, 그 지점의 파일 상태를 미리 본 뒤 복원할 수 있다. 다만 체크포인트는 로컬에만 저장되고 git과 무관하다. 영구적인 버전 관리는 git으로 해야 한다. (Agent 개요)

Rules로 프로젝트 규칙 고정하기

같은 지시를 매번 프롬프트에 쓰는 게 지겨워질 때 Rules를 넣는다. .cursor/rules 폴더에 .mdc 파일로 두면 저장소에 커밋되어 팀원과 같이 쓸 수 있다.

여기서 한 번 헷갈린다. 같은 폴더의 .md 파일은 규칙으로 인식되지 않는다. frontmatter가 없어서 description·globs·alwaysApply를 읽을 수 없기 때문이다. 순수 마크다운으로 쓰고 싶으면 .cursor/rules 대신 AGENTS.md를 쓴다. (Rules)

규칙이 언제 붙는지는 frontmatter 세 필드가 정한다.

---
globs: src/components/**/*.tsx
alwaysApply: false
---
Use named exports, not default exports
Keep components under 200 lines

@파일명을 규칙 본문에 적어도 파일 내용이 프롬프트에 복사되지는 않는다. Agent가 필요할 때 도구로 직접 읽는다. 항상 컨텍스트에 있어야 하는 내용은 규칙 본문에 그대로 써야 한다. (Rules)

프롬프트를 어디까지 잘게 쪼갤지는 프롬프트 작성법에서 다룬 기준을 그대로 적용했다. 규칙 파일도 결국 짧고 구체적인 문장이 잘 먹는다.

요금 — Free부터 Ultra까지

2026년 11월 기준 Cursor는 X 구독에 묶여 있고, 무료 플랜부터 Ultra까지 다섯 단계다. 아래 가격은 월 단위, 세전 기준이다. (Pricing)

Plus는 Cursor 자체 모델만 쓴다. Grok 4.7, Grok 4.6, Grok 4.5, Composer 2.5가 여기 들어가고, Fast 꺼짐·effort medium 같은 고정 설정으로 동작한다. Cloud Agents나 Automations, 서드파티 모델은 Premium부터 열린다. (Models & Pricing)

사용량은 주 단위로 갱신되는 하나의 풀이다. 에디터의 Agent, CLI, Cloud Agents, Grok 앱이 같은 풀에서 차감되므로 하루 몰아 써도 한 달치가 날아가지는 않는다. 남은 사용량과 다음 갱신일은 에디터 설정과 grok.com 대시보드의 Usage에서 볼 수 있다. (Models & Pricing)

예전 Pro·Pro+·Ultra·Start·Teams Standard/Premium 요금제를 쓰고 있었다면 그대로 유지된다. 월 2개 풀과 on-demand 과금 방식이 남아 있다. (Models & Pricing)

어떤 툴을 골라야 할지 아직 고민 중이라면 AI 코딩 툴 비교에서 Cursor·Copilot·Claude Code를 같은 기준으로 정리해뒀다. 터미널에서 일하는 쪽이 편하면 Claude Code 설치·사용법을 먼저 읽는 게 낫다.

내가 막혔던 곳

처음 Cursor를 켰을 때 Tab 제안이 너무 자주 떠서 오히려 타이핑이 느려졌다. 문장을 쓰다가도 회색 글씨가 끼어들어서 Esc를 계속 눌렀다. 알고 보니 확장자별로 끌 수 있었다. 지금은 markdown과 JSON에서 Tab을 꺼두고 코드 파일에서만 쓴다.

두 번째는 Rules가 안 먹는 문제였다. .cursor/rules에 .md 파일을 넣고 왜 규칙이 적용되지 않는지 한참 찾았다. 규칙으로 인식되려면 .mdc 확장자와 frontmatter가 필요하다. 폴더만 맞으면 되는 줄 알았던 게 실수였다. (Rules)

세 번째는 체크포인트를 git 대신으로 착각한 것이다. Agent가 이상하게 고쳐서 체크포인트로 되돌린 뒤 안심하고 커밋을 안 했다. 체크포인트는 로컬 스냅샷이라 다른 사람과 공유되지 않고, 저장소를 새로 받으면 사라진다. 결국 git 커밋을 같이 해야 한다. (Agent 개요)

참고 자료

• Cursor Quickstart — 설치 조건, 첫 작업 순서, Plan Mode
• Cursor Agent 개요 — 도구 목록, 체크포인트, 대기열 단축키
• Cursor Rules — .mdc 규칙 구조와 frontmatter 동작
• Tab completion — 수락·거절 단축키, 확장자별 비활성화
• Models & Pricing — 플랜별 포함 사용량, 주간 풀
• Cursor Pricing — 월 가격표
• AI 코딩 툴 비교 · Claude Code 설치·사용법 · Mac 개발환경 세팅

git을 처음 배울 때 어려운 건 개념이 아니라 명령이 실패했을 때다. fatal:로 시작하는 줄이 뜨면 무슨 일이 일어난 건지 알 수 없어서, 구글에 그 문장을 그대로 붙여넣고 블로그 몇 개를 전전하게 된다.

이 글은 로컬 저장소에서 커밋하고 원격에 올리는 흐름을 한 번 훑은 뒤, 입문자가 실제로 가장 자주 만나는 에러 7개를 증상별로 정리했다. 명령은 macOS의 git 2.39.2에서 직접 실행해 확인했다.

30초 요약

목차

1. git 기초 사용법, 이 흐름 하나만 익히면 된다
2. 설치와 최초 설정 — 커밋이 거부되는 이유
3. 로컬 작업 — status·add·commit·log
4. 원격 저장소 — remote·push·clone
5. 브랜치와 충돌 — switch·merge
6. 자주 나는 에러 7가지
7. 되돌리기 — restore·reset·revert 차이
8. 내가 막혔던 곳
9. 참고 자료

git 기초 사용법, 이 흐름 하나만 익히면 된다

git은 파일을 세 군데에 나눠 담는다. 작업 폴더, 스테이징 영역(index), 커밋 기록이다. git add는 작업 폴더의 변경을 스테이징으로 올리고, git commit은 스테이징에 있는 것만 기록으로 남긴다. 이 구조를 알고 나면 "분명히 고쳤는데 커밋에 안 들어간다"는 상황이 이해된다.

처음 배울 때는 아래 다섯 줄이면 충분하다. 나머지 명령은 이 흐름이 막힐 때 꺼내 쓰는 도구다.

git init
git add .
git commit -m "first commit"
git remote add origin https://github.com/USER/REPO.git
git push -u origin main

-u는 이후에 git push만 쳐도 같은 원격·브랜치로 올라가게 묶어두는 옵션이다. 한 번만 붙이면 된다.

설치와 최초 설정 — 커밋이 거부되는 이유

맥에서는 터미널에서 git을 처음 실행하면 Xcode Command Line Tools 설치 안내가 뜬다. 그 창에서 설치를 누르면 /usr/bin/git이 생긴다. 내 맥에서는 git version 2.39.2 (Apple Git-143)이 잡혀 있다. 더 최신 버전이 필요하면 Homebrew로 따로 깔 수 있고, 이때 PATH 순서에 따라 두 개가 공존할 수 있다. 그 이야기는 Mac 개발환경 세팅에 정리해 뒀다.

설치 다음에 반드시 하는 설정이 있다. 이름과 이메일이 없으면 git이 커밋을 만들어주지 않는다.

git config --global user.name "Henry"
git config --global user.email "me@example.com"
git config --global init.defaultBranch main
git config --list --show-origin

세 번째 줄은 새 저장소의 기본 브랜치 이름을 정한다. 공식 문서를 보면 git init의 기본값은 아직 master이고, Git 3.0에서 main으로 바뀔 예정이라고 적혀 있다. (git-init) 지금 맞춰두면 나중에 이름이 바뀌어도 헷갈리지 않는다.

--show-origin은 각 설정이 어느 파일에서 왔는지 알려준다. 회사 저장소에서만 다른 이메일을 쓰는 경우처럼 설정이 겹칠 때 이 옵션으로 원인을 찾는다.

로컬 작업 — status·add·commit·log

작업 순서는 늘 같다. 무엇이 바뀌었는지 보고, 필요한 것만 올리고, 메시지를 붙여 기록한다.

git status -sb          # 현재 브랜치와 변경 파일
git add -p              # 바뀐 부분을 하나씩 확인하며 스테이징
git commit -m "로그인 폼 유효성 검사 추가"
git log --oneline --graph -10

git add -p는 처음엔 번거롭게 느껴진다. 그런데 디버그 출력이나 임시 주석이 커밋에 섞이는 일이 확 줄어든다. 커밋 하나에 한 가지 변경만 담는 습관도 여기서 생긴다.

메시지는 "무엇을"보다 "왜"를 적는다. fix bug보다 빈 이메일로 로그인 시 500 오류 수정이 나중에 도움이 된다.

원격 저장소 — remote·push·clone

GitHub에 빈 저장소를 만들었다면 주소를 등록하고 올린다. 이미 있는 저장소를 받을 때는 clone 한 줄이면 되고, 이때 origin이 자동으로 잡힌다.

git remote add origin https://github.com/USER/REPO.git
git remote -v
git branch -M main
git push -u origin main

# 반대 방향
git clone https://github.com/USER/REPO.git

인증은 비밀번호로 하지 않는다. GitHub는 git 작업에 계정 비밀번호를 받지 않고, Personal Access Token이나 SSH 키를 쓴다. (GitHub 문서) 토큰을 URL에 넣어두면 편하지만, 그 URL이 그대로 커밋이나 로그에 남을 수 있어서 나는 SSH 키를 쓴다.

ssh-keygen -t ed25519 -C "me@example.com"
pbcopy < ~/.ssh/id_ed25519.pub   # GitHub > Settings > SSH keys에 붙여넣기
ssh -T git@github.com

마지막 줄에서 Hi USER! You've successfully authenticated가 나오면 끝이다. 처음 SSH로 접속할 때 뜨는 fingerprint 확인 문구는 yes를 입력한다.

브랜치와 충돌 — switch·merge

브랜치를 만들고 옮기는 명령은 2.23에서 switch와 restore로 분리됐다. 예전 글에 있는 checkout도 여전히 동작하지만, 새로 배울 때는 역할이 나뉜 명령을 쓰는 편이 헷갈리지 않는다.

git switch -c feature/login   # 만들면서 이동
git switch main               # 이동
git merge feature/login       # main에 합치기
git branch -d feature/login   # 합친 뒤 정리

같은 줄을 양쪽에서 고쳤다면 merge가 멈추고 CONFLICT (content)를 알려준다. 충돌 파일에는 <<<<<<<, =======, >>>>>>> 표시가 생긴다. 이 표시를 지우면서 남길 내용만 정리하고 나서 저장한 뒤 세 줄을 실행한다.

git status                 # 충돌 파일 확인
git add <해결한 파일>
git commit                 # merge 커밋 완료 (또는 git merge --continue)

중간에 마음이 바뀌면 git merge --abort로 merge 직전 상태로 돌아간다. 충돌 해결이 길어질 것 같으면 이 명령을 먼저 외워두는 게 낫다.

자주 나는 에러 7가지

입문 단계에서 실제로 자주 만나는 것들만 모았다. 대부분은 명령 한 줄로 풀린다.

refusing to merge unrelated histories는 GitHub에서 README를 만들고 로컬에서도 git init 후 첫 커밋을 따로 만든 경우에 난다. 두 저장소가 공통 조상을 갖지 않아서 git이 기본적으로 거부한다. --allow-unrelated-histories로 한 번 합치고 나면 이후부터는 정상적으로 동작한다. (git-merge)

push가 거부됐을 때 --force로 밀어버리는 사람이 많다. 남의 커밋이 사라질 수 있으니, 정말로 내 이력으로 덮어써야 하는 상황에서만 --force-with-lease를 쓴다. 원격이 내가 마지막으로 본 상태에서 바뀌었으면 이 옵션은 push를 거부한다. (git-push)

되돌리기 — restore·reset·revert 차이

되돌리기는 "무엇을 되돌리는지"에 따라 명령이 다르다. 여기서 많이 헤맨다.

reset은 기록을 지우고 revert는 기록을 남긴다. 혼자 쓰는 브랜치면 reset이 깔끔하고, 다른 사람과 공유한 브랜치면 revert를 쓴다. 공유 브랜치에서 reset 후 force push를 하면 동료의 로컬과 어긋난다.

git restore는 --staged를 붙이느냐에 따라 대상이 완전히 달라진다. 이 차이를 모르면 "add를 취소했는데 파일까지 사라졌다"는 상황이 생긴다. (git-restore)

내가 막혔던 곳

처음 git을 쓰던 시절, 나는 git init을 홈 디렉터리에서 실행했다. 그 뒤로 새 프로젝트를 만들 때마다 git status가 이상하게 많은 파일을 보여줬고, 왜 그런지 한참 몰랐다. 상위 폴더에 .git이 있으면 git은 거기를 저장소로 인식한다. 지금은 프로젝트 폴더를 만든 뒤 그 안에서만 git init을 한다. 이미 늦었다면 ls -a로 상위 경로를 훑어 .git이 있는지 확인하면 된다.

두 번째는 첫 push에서 겪은 인증 실패다. 비밀번호를 계속 넣어도 Authentication failed가 떴다. GitHub가 git 작업에 계정 비밀번호를 더 이상 받지 않는다는 걸 그때 알았다. 토큰을 만들고 나서 해결됐지만, 토큰을 원격 URL에 넣어둔 탓에 나중에 그 주소가 스크립트에 남아 있었다. 지금은 SSH 키를 쓰고, 원격 주소에는 토큰을 넣지 않는다. 파이썬 프로젝트라면 .venv를 .gitignore에 넣는 것도 같이 챙긴다. Python 가상환경 venv 만들기에서 만든 폴더를 그대로 커밋하면 저장소가 순식간에 무거워진다.

세 번째는 git pull 습관이다. 원격에 커밋이 있는 상태에서 그냥 git pull을 하면 merge 커밋이 생기고, 이력이 지저분해진다. 혼자 쓰는 저장소에서는 git config --global pull.rebase true로 rebase를 기본으로 두는 편이 읽기 쉽다. 다만 이미 push한 커밋을 rebase하면 해시가 바뀌므로, 협업 브랜치에서는 습관대로 쓰면 안 된다.

참고 자료

• git-init — 기본 브랜치 이름, Git 3.0에서 main으로 변경 예정
• git-config — user.name, init.defaultBranch, pull.rebase
• git-switch · git-restore — 2.23에서 분리된 명령
• git-merge — --allow-unrelated-histories, 충돌 처리
• git-push — --force-with-lease 동작
• git/git 태그 — v2.56.0
• GitHub — About authentication to GitHub — 토큰·SSH 키
• Mac 개발환경 세팅 · Python 가상환경 venv 만들기 · Claude Code 설치·사용법

퍼플렉시티가 2026년 11월 5일(현지시간) Teammates를 공개했다. 한 번 질문하고 답을 받는 도구가 아니라, 마케팅·영업·고객지원 같은 업무를 계속 맡아서 처리하는 상주형 에이전트다.

이 글은 Teammates가 정확히 무엇인지, 기존 Computer와 무엇이 다른지, 월 얼마인지, 그리고 쓰기 전에 확인해야 할 위험을 정리한다.

30초 요약

목차

1. Perplexity Teammates란?
2. Computer와 무엇이 다른가
3. 실제로 무엇을 하나 — 직무별 예시
4. 설정 방법 5단계
5. 가격 — 월 $167, 진짜 비용은 크레딧
6. 한계와 주의할 점
7. 다른 AI 동료 제품과 비교
8. 내가 막혔던 곳
9. 참고 자료

Perplexity Teammates는 2026년 11월 5일 공개됐다. 한 번의 질문이 아니라 지속되는 업무를 맡기는 에이전트다.

Perplexity Teammates란?

Teammates는 "프롬프트를 쓰는 방식"에서 "목표를 맡기는 방식"으로 바꾸는 제품이다. 퍼플렉시티는 공식 블로그에서 이렇게 설명한다. "Teammates는 장기 작업을 맡을 수 있는 개인 에이전트로, 프로젝트를 계획하고 조정하며, 우선순위가 바뀌면 방향을 전환하고, 결과를 검토용으로 제시한다."

쉽게 말하면 이런 구조다. 사람이 "이 캠페인을 계속 관리해"라고 역할을 주면, 에이전트가 할 일을 스스로 쪼개고, 정해진 시간이나 조건에 맞춰 실행하고, 사람이 봐야 할 지점에서 승인을 요청한다. 대화 세션이 끝나도 기억이 남는다.

중요한 차이는 지속성이다. 지금까지의 챗봇은 세션이 끝나면 맥락이 끊겼다. Teammates는 프로젝트 목표, 작업 이력, 공유 파일을 실행 사이에 기억한다. 그래서 "어제 하던 그거 이어서"가 통한다.

2026년 11월 5일 기준으로는 웹에서만 쓸 수 있고, iOS와 데스크톱 앱은 준비 중이다. Free·Pro 사용자는 Max로 업그레이드해야 한다.

Computer와 무엇이 다른가

Computer는 퍼플렉시티의 멀티모델 에이전트다. 브라우저를 열고, 파일을 다루고, 여러 단계 작업을 수행한다. Teammates는 그 위에 "역할·기억·감시·인계"를 얹은 것이다.

퍼플렉시티 표현을 빌리면, Computer는 "일을 처리하는 실행기"이고 Teammates는 "그 실행기를 계속 굴리는 담당자"다. Teammates가 Computer 세션과 다른 Teammates를 조정하는 구조라서, 상위에 하나의 조정자(coordinator)가 있는 셈이다.

Computer와 Teammates는 같은 엔진을 쓰지만 작업 단위와 기억 방식이 다르다. Teammates는 실행 사이에도 맥락을 유지한다.

실제로 무엇을 하나 — 직무별 예시

공식 블로그가 든 예시는 네 가지다. 모두 마케팅 문구이지, 성과 지표가 아니다. 숫자나 정확도는 공개되지 않았다.

공통점은 "감시 → 판단 → 초안 → 승인 요청"의 루프다. 사람이 매번 시키지 않아도 움직인다는 게 핵심이고, 동시에 가장 위험한 지점이기도 하다. 잘못된 판단을 해도 스스로 멈추지 않고 계속 실행할 수 있기 때문이다.

Slack에 Teammate를 초대하면 동료들이 직접 일을 넘기거나 진행 상황을 물을 수 있다. 에이전트끼리 일을 넘기는 것도 된다. 예를 들어 한 에이전트가 웹사이트에서 버그를 찾으면, 다른 에이전트에게 수정 준비를 넘긴다.

설정 방법 5단계

공식 안내는 다섯 단계다. 어렵지 않지만, 4단계에서 무엇을 쓰느냐가 결과를 좌우한다.

1. 퍼플렉시티 웹에 로그인하고 왼쪽 내비게이션에서 Teammates를 고른다.
2. 프로젝트를 반영하는 이름을 붙이고 설정을 진행한다.
3. 필요한 도구를 연결한다. Slack, GitHub, Gmail 같은 플러그인을 붙이고, GitHub는 접근할 저장소를 고른다.
4. 맡길 일을 설명한다. 작업이 어디서 들어오는지, 무엇을 내놓아야 하는지, 언제 움직여야 하는지를 적는다.
5. 프로젝트에 배정하고 첫 작업을 준다. 시장 조사, 가입 흐름 개선, 버그 조사 같은 것부터 시작한다.

좋은 브리프 예시 (구조만 참고)
- 입력: 매일 09:00 Slack #cs 채널의 전날 불만 스레드
- 판단: 환불 요청, 배송 지연, 기능 오류로 분류
- 출력: 유형별 요약 1장 + 대표 답변 초안 3건
- 승인: 환불·보상이 걸린 건은 보내기 전에 나에게 확인
- 금지: 고객에게 직접 메일 발송하지 말 것

브리프에 "무엇을 하지 말라"를 꼭 넣는 게 좋다. 에이전트는 권한이 있으면 시키지 않은 일도 한다. 특히 발송·결제·삭제 권한은 처음부터 주지 않는 편이 안전하다.

가격 — 월 $167, 진짜 비용은 크레딧

Teammates 자체의 별도 요금은 공개되지 않았다. Max 구독에 포함된 형태다.

출처: Perplexity 요금 페이지. Max는 "최고 사용 한도, 프론티어 모델, 신기능 우선 접근"이 붙는 최상위 플랜이다.

여기서 놓치기 쉬운 게 크레딧이다. Teammates는 계속 돌아가고, 브라우저 세션을 열고, 다른 에이전트와 대화한다. 한 번 쓰고 마는 Computer 작업보다 크레딧을 빨리 먹을 수 있다. 퍼플렉시티는 Teammates의 크레딧 소모량을 별도로 밝히지 않았다. 상시 감시를 붙이기 전에 크레딧 사용량을 먼저 재보는 게 좋다.

한계와 주의할 점

공식 문서와 보도에서 확인되는 제약은 다음과 같다.

• Max 전용이다. Free·Pro는 쓸 수 없다.
• 웹에서 먼저 시작했다. iOS·데스크톱은 추후다.
• 정확도·시간 절감·오류율 같은 성과 지표가 공개되지 않았다. 블로그 예시는 마케팅 시나리오다.
• 기존 Projects·Memory·Skills·커넥터의 권한을 그대로 물려받는다. 편하다는 뜻이자, 권한이 넓다는 뜻이다.
• 에이전트별로 환경과 브라우저 세션은 분리되지만, 계정 권한 자체가 분리되는 건 아니다.
• 저장된 자격증명은 암호화되고 안전하게 입력된다고 안내하지만, 어떤 권한을 줬는지는 사용자가 관리해야 한다.
• 여러 에이전트가 서로 일을 넘기므로, 실패가 한 곳에서 끝나지 않고 연쇄될 수 있다.

실무에서는 세 가지를 먼저 정하는 게 좋다. 첫째, 에이전트가 직접 실행해도 되는 행동과 승인받아야 하는 행동을 나눈다. 둘째, GitHub 저장소·Slack 채널·메일 범위를 최소로 준다. 셋째, 첫 2주는 결과를 매일 검토한다. 자율성이 높은 도구일수록 초기 감시 비용을 아끼면 나중에 더 크게 낸다.

다른 AI 동료 제품과 비교

"상주형 업무 에이전트"는 2026년 들어 경쟁이 붙은 카테고리다. 이름만 다르고 방향은 비슷하다.

출처: Digital Trends. 제품별 세부 기능과 가격은 계속 바뀌므로, 도입 전에 각 공식 페이지를 확인해야 한다.

퍼플렉시티 공식 제품 페이지를 직접 캡처했다. Max 구독자에게 웹으로 먼저 열린다는 안내가 함께 나온다.

퍼플렉시티의 차별점은 개인 구독자에게 먼저 열었다는 점, 그리고 Computer·Projects·Memory·Skills라는 기존 자산을 그대로 쓴다는 점이다. 반대로 조직 관리 기능(권한 정책, 감사 로그, SSO)은 아직 엔터프라이즈 제품만큼 갖춰졌다고 보기 어렵다.

내가 막혔던 곳

처음엔 Teammates가 Computer의 새 이름인 줄 알았다. 둘 다 브라우저를 열고 여러 단계 작업을 한다. 차이는 지속성과 협업에 있었다. Computer는 내가 시킬 때 움직이고, Teammates는 맡긴 일을 기준으로 스스로 움직인다. 이 차이를 모르면 "그냥 Computer 쓰면 되는 거 아닌가"에서 멈춘다.

두 번째는 가격 표기였다. 어떤 기사는 월 $200, 어떤 기사는 월 $167이라고 쓴다. 둘 다 맞다. 월 결제가 $200이고, 연간 결제가 월 $167이다. 연간로 묶으면 1년에 약 $2,004다.

세 번째는 크레딧이다. 구독료만 보고 "월 $167이면 쓰겠다"고 판단했는데, 상시 감시형 에이전트는 크레딧을 계속 쓴다. 지금은 자동화를 붙이기 전에 일주일치 사용량을 먼저 보고, 그 다음에 상시 실행으로 바꾸는 순서가 맞다고 본다.

에이전트에 권한을 주는 구조는 AI 에이전트란에, 권한을 뺏기는 공격은 AI 탈옥이란에 정리해뒀다. 맡길 일을 문장으로 잘 쓰는 법은 프롬프트 작성법을 참고하면 된다.

참고 자료

• Perplexity — Teammates are agents for complex, ongoing work (기능, 직무별 예시, 설정 5단계, 격리·권한)
• Perplexity — Teammates 제품 페이지 (역할·상시 실행, Max 웹 우선)
• Perplexity — 요금 (Max 연간 월 $167, 월 $200, 크레딧 10,000)
• Digital Trends — Perplexity's new AI coworkers can take over your workload (출시일, Slack, 경쟁 제품)
• explainx — Perplexity Teammates: What They Do, Cost, Risks (2차 분석, 크레딧·위험 정리)