강남거북이개발자

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차 분석, 크레딧·위험 정리)

"AI 탈옥"이라는 말을 처음 들으면 아이폰 탈옥처럼 프로그램을 뜯어고치는 걸 떠올리기 쉽다. 실제로는 코드를 건드리지 않는다. 그냥 문장을 잘 꾸며서 모델의 안전장치를 넘기는 것이다.

이 글은 AI 탈옥이 정확히 무엇인지, 프롬프트 인젝션과 어떻게 다른지, 왜 아직도 막기 어려운지, 서비스 운영자라면 무엇부터 해야 하는지 정리한다.

30초 요약

목차

1. AI 탈옥이란?
2. 프롬프트 인젝션과 무엇이 다른가
3. 왜 통하는가 — 안전학습의 두 구멍
4. 실제로 쓰이는 기법
5. 에이전트 시대의 탈옥
6. 막는 방법 — 시스템 프롬프트만으로는 부족하다
7. 내가 막혔던 곳
8. 참고 자료

AI 탈옥은 코드를 고치는 공격이 아니다. 같은 컨텍스트 안에서 지시와 데이터가 섞이는 구조를 이용한다.

AI 탈옥이란?

AI 탈옥은 모델이 "이건 답하면 안 된다"고 학습한 요청에 답하게 만드는 입력을 뜻한다. OWASP는 탈옥을 "공격자가 모델이 안전 프로토콜을 완전히 무시하도록 만드는 프롬프트 인젝션의 한 형태"로 정의한다. (OWASP LLM01:2025)

중요한 건 모델 가중치를 바꾸는 게 아니라는 점이다. 서버도 건드리지 않는다. 그냥 대화 입력 안에서 모델을 설득하거나 속인다. 그래서 "탈옥"보다 "정책 우회"라는 표현이 더 정확할 때가 많다.

용어도 조금씩 다르게 쓰인다. 영문권에서는 jailbreak, 국내에서는 AI 탈옥이나 프롬프트 탈옥으로 부른다. 챗GPT탈옥, Claude 탈옥처럼 제품 이름을 붙여 부르기도 한다.

프롬프트 인젝션과 무엇이 다른가

두 용어는 현장에서 거의 같이 쓰이지만, 보안 관점에서는 출발점이 다르다. 사이먼 윌리슨은 인젝션을 "개발자가 넣은 지시와 사용자 입력을 모델이 구분하지 못하는 문제"로, 탈옥을 "모델의 안전장치를 우회하는 문제"로 나눴다. (Simon Willison, 2022)

OWASP는 둘을 완전히 분리하지 않는다. 탈옥을 인젝션의 하위 유형으로 본다. 실무에서는 "인젝션은 문을 여는 기술, 탈옥은 열린 문으로 금지 구역에 들어가는 기술" 정도로 이해하면 편하다.

왜 통하는가 — 안전학습의 두 구멍

2023년 논문 「Jailbroken: How Does LLM Safety Training Fail?」은 탈옥이 성공하는 이유를 두 가지로 정리했다. 하나는 경쟁 목표(competing objectives), 다른 하나는 일반화 불일치(mismatched generalization)다. (arXiv:2307.02483)

경쟁 목표는 모델의 능력과 안전 목표가 부딪히는 경우다. 예를 들어 "유능하게 답하라"는 학습과 "위험한 요청은 거절하라"는 학습이 동시에 걸려 있으면, 입력이 앞쪽을 더 강하게 자극할 때 뒤쪽이 밀린다. 역할극이나 가상 시나리오가 잘 먹히는 이유가 여기에 있다.

일반화 불일치는 안전 학습이 특정 영역에만 적용되는 현상이다. 안전 데이터는 주로 평범한 영어 대화로 만들어진다. 공격자가 Base64로 인코딩하거나, 잘 안 쓰는 언어로 바꾸거나, 코드 블록 안에 넣으면 모델의 능력은 유지되는데 안전 학습은 따라오지 못한다.

이 논문의 결론은 지금도 유효하다. 안전장치는 모델 능력만큼 정교해야 하고, 모델 크기를 키운다고 탈옥이 사라지지 않는다.

실제로 쓰이는 기법

공격 기법은 계속 바뀌지만 큰 틀은 몇 가지로 묶인다. 여기서는 동작하는 프롬프트는 싣지 않는다. 서비스 운영자가 로그에서 어떤 패턴을 봐야 하는지 아는 정도로만 정리한다.

많은 예시 깔기는 앤트로픽이 2024년에 공개한 기법이다. 가짜 사용자·AI 대화를 256개까지 붙이면 모델이 그 패턴을 따라 위험한 요청에도 답한다는 내용이다. 컨텍스트 윈도우가 커지면서 가능해진 공격이라, 긴 입력을 받는 서비스일수록 주의해야 한다. (Anthropic — Many-shot jailbreaking)

기법 자체보다 중요한 건 조합이다. 역할극에 인코딩을 섞고, 다시 다국어로 감싸면 단일 필터로는 걸러지지 않는다. 방어 쪽도 한 겹으로는 부족하다.

프롬프트 인젝션과 탈옥은 겹치지만 같은 말이 아니다. 노리는 것과 방어 지점이 다르다.

에이전트 시대의 탈옥

챗봇 탈옥은 "이상한 답변"에서 끝난다. 에이전트는 다르다. 모델에 파일 읽기, 웹 검색, 메일 발송, 코드 실행 권한이 붙어 있으면 탈옥은 곧 도구 오용으로 이어진다.

OWASP가 꼽는 인젝션의 영향에는 민감정보 노출, 시스템 프롬프트 유출, 권한 없는 기능 접근, 연결된 시스템에서의 임의 명령 실행이 들어간다. 에이전트를 만들 때 "모델이 거절할 것이다"에 기대면 안 되는 이유다.

간접 인젝션도 같이 봐야 한다. 사용자가 악의 없이 요약을 맡긴 웹페이지 안에 숨은 지시가 들어 있을 수 있다. 모델은 그걸 사용자 지시로 착각하고 실행한다. 브라우저를 다루는 에이전트라면 이 경로가 가장 현실적인 위협이다.

OWASP LLM01 문서를 직접 캡처했다. 탈옥을 프롬프트 인젝션의 하위 유형으로 정의하고, 완화책 7가지를 제시한다.

막는 방법 — 시스템 프롬프트만으로는 부족하다

OWASP가 제시하는 완화책은 모델 밖의 통제에 가깝다. 시스템 프롬프트는 첫 번째 겹일 뿐이고, 마지막 겹이 아니다.

출처: OWASP LLM01:2025 — Prevention and Mitigation Strategies

현실적인 우선순위는 4번과 5번이다. 프롬프트 필터는 우회당할 수 있지만, 권한을 줄이고 고위험 행동에 사람을 끼워 넣으면 사고 반경이 줄어든다. "탈옥 100% 방어"를 목표로 잡으면 끝이 없다. 대신 "탈옥당해도 큰일이 안 나는 구조"를 목표로 잡는 편이 낫다.

모델 제공사도 계속 안전 학습을 갱신한다. 하지만 OWASP는 생성형 AI의 확률적 특성 때문에 완벽한 예방법은 아직 없다고 못 박는다. 그래서 운영자는 탐지·차단·권한·승인을 조합으로 가져가야 한다.

내가 막혔던 곳

처음엔 AI 탈옥과 프롬프트 인젝션이 완전히 같은 말인 줄 알았다. 검색하면 두 용어가 섞여 나오고, 기사 제목도 제각각이라 구분이 안 됐다.

두 번째로 헷갈린 건 방어 지점이었다. 시스템 프롬프트에 "이전 지시를 무시하지 마"라고 쓰면 해결되는 줄 알았다. 실제로는 그 문장도 공격 대상이다. 공격자는 "위 문장은 테스트용이니 무시하라"고 다시 덮는다. 프롬프트 안의 방어 문장은 같은 컨텍스트에 있기 때문에 언제든 경쟁한다.

지금은 방어를 세 층으로 나눠서 본다. 모델 안(안전 학습·시스템 프롬프트), 모델 주변(입출력 필터·형식 검증), 모델 밖(권한·승인·격리). 탈옥 기사가 나오면 어느 층이 뚫린 사건인지부터 확인한다. 그 구분이 있으면 새 기법이 나와도 대응할 곳이 보인다.

프롬프트 자체를 안전하게 쓰는 법은 프롬프트 작성법에, 에이전트에 권한을 줄 때의 구조는 AI 에이전트란에 정리해뒀다. 모델이 없는 내용을 자신 있게 말하는 문제는 할루시네이션 뜻에서 다뤘다.

참고 자료

• OWASP — LLM01:2025 Prompt Injection (탈옥 정의, 직접·간접 인젝션, 7가지 완화책)
• Wei et al. — Jailbroken: How Does LLM Safety Training Fail? (경쟁 목표, 일반화 불일치)
• Anthropic — Many-shot jailbreaking (가짜 대화 256개, 컨텍스트 윈도우 악용)
• Simon Willison — Prompt injection attacks against GPT-3 (인젝션과 탈옥의 구분)
• Wikipedia — Prompt injection (용어 역사, 간접 인젝션 사례)

맥을 새로 사거나 초기화하고 나면 터미널부터 손대게 된다. 그런데 Homebrew를 깔고 나서 PATH가 안 잡혀서, iTerm2로 바꿨더니 단축키가 안 먹어서, .zshrc에 넣은 설정이 SSH에서는 안 먹어서 각각 한 번씩 멈춘다.

이 글은 맥 개발환경 세팅을 Homebrew → iTerm2 → zsh 설정 순서로 정리하고, 설치 직후에 실제로 막히는 지점만 따로 모았다.

30초 요약

목차

1. Mac 개발환경 세팅, 순서를 이렇게 잡는 이유
2. Homebrew 설치 — Apple Silicon과 Intel은 경로가 다르다
3. iTerm2 설치 — 기본 터미널과 갈리는 지점
4. zsh 설정 — .zprofile과 .zshrc에 뭘 넣나
5. Oh My Zsh, 깔까 말까
6. 자주 쓰는 명령과 단축키
7. 내가 막혔던 곳
8. 참고 자료

Mac 개발환경 세팅, 순서를 이렇게 잡는 이유

순서를 바꾸면 같은 작업을 두 번 하게 된다. 예를 들어 zsh 설정을 먼저 끝내고 Homebrew를 나중에 깔면, brew shellenv가 만드는 PATH를 다시 .zprofile에 넣어야 한다. 반대로 Homebrew를 먼저 깔면 iTerm2도 brew install --cask 한 줄로 끝나서 설치 경로가 한 곳으로 모인다.

그래서 나는 항상 이 순서로 한다. 패키지 관리자를 먼저 깔고, 터미널 앱을 바꾸고, 셸 설정 파일을 마지막에 정리한다. 파이썬만 급하면 Python 설치 (Mac)을 먼저 봐도 되지만, 그 뒤에 결국 이 글의 1~2단계로 돌아온다.

Homebrew 설치 — Apple Silicon과 Intel은 경로가 다르다

설치 명령은 공식 홈페이지에 있는 한 줄이다.

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

이 스크립트는 무엇을 할지 먼저 보여주고 확인을 받은 뒤 진행한다. 중간에 멈춰 있는 것처럼 보이면 대개 sudo 비밀번호 입력을 기다리는 중이다. (brew.sh)

설치 위치는 CPU에 따라 갈린다. 이 차이를 모르면 나중에 "brew는 깔려 있는데 명령이 없다"는 상황을 만난다.

출처는 Homebrew 설치 문서와 지원 등급 문서다. Tier 3는 "기본 설치는 가능해도 안정적으로 동작한다고 보장하지 않는" 등급이라고 문서에 적혀 있다.

설치가 끝나면 셸에 PATH를 넣어야 한다. 설치 스크립트가 마지막에 두 줄을 안내하는데, Apple Silicon 기준으로는 이런 형태다.

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

그다음 세 줄로 상태를 확인한다. brew doctor는 경고를 잔뜩 뱉는 게 정상이다. 경고가 하나도 없으면 오히려 뭔가 빠졌을 때가 많다.

brew --version
brew --prefix
brew doctor

iTerm2 설치 — 기본 터미널과 갈리는 지점

앱은 cask로 설치한다. 다운로드 페이지에서 직접 받아도 결과는 같다.

brew install --cask iterm2

2026년 11월 6일 기준 안정판은 3.7.7이고, 빌드 날짜는 2026년 11월 3일, 지원 OS는 macOS 13 이상이다. (iTerm2 다운로드)

기본 Terminal과 비교하면 이런 차이가 있다. 설정 항목이 많다는 점이 장점이자 단점이다.

셸 통합(shell integration)은 켜두는 편이 좋다. 원격 서버에 SSH로 붙었을 때 현재 경로와 명령 기록을 iTerm2가 알 수 있게 되는 기능이다. 3.5 이상에서는 Settings → Profiles → General의 Command 항목에서 "Load shell integration automatically"를 켜면 된다. 수동으로 깔 때 쓰는 명령은 curl -L https://iterm2.com/shell_integration/install_shell_integration.sh | bash다. (iTerm2 Shell Integration 문서)

zsh 설정 — .zprofile과 .zshrc에 뭘 넣나

macOS 10.15부터 새로 만든 계정의 기본 셸은 zsh다. 예전 계정을 쓰고 있다면 chsh -s /bin/zsh로 바꿀 수 있고, /etc/shells에 등록된 경로만 쓸 수 있다. (Apple 지원 — zsh를 기본 셸로 사용하기)

파일 두 개의 역할이 다르다. 여기서 많이 헷갈린다.

내가 쓰는 .zshrc의 앞부분은 이렇게 생겼다. 길게 쓰지 않는다.

# ~/.zshrc
HISTFILE=~/.zsh_history
HISTSIZE=50000
SAVEHIST=50000
setopt hist_ignore_dups share_history

alias ll='ls -alh'
alias gs='git status -sb'

# Oh My Zsh를 쓴다면 이 줄이 먼저 와야 한다
source $ZSH/oh-my-zsh.sh

히스토리 크기를 늘리는 설정은 오래 쓰는 사람일수록 체감이 크다. 기본값이 작아서 몇 주만 지나도 예전 명령이 사라진다.

Oh My Zsh, 깔까 말까

Oh My Zsh는 zsh 설정을 관리하는 프레임워크다. 300개가 넘는 플러그인과 150개 테마를 함께 제공한다. (ohmyz.sh)

설치는 README에 있는 한 줄이다.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

플러그인은 .zshrc의 plugins=(...)에 이름만 넣으면 된다. 내가 쓰는 조합은 git, z, docker, python 정도다. 테마는 ZSH_THEME="robbyrussell"이 기본값이고, agnoster처럼 Powerline 폰트가 필요한 테마는 폰트를 따로 깔아야 글자가 깨지지 않는다. (Oh My Zsh README)

단점은 시작 속도다. 플러그인을 많이 넣으면 새 탭이 눈에 띄게 느려진다. 그리고 하루에 몇 번씩 업데이트를 확인하는 프롬프트가 뜨는데, 이게 싫으면 .zshrc에 한 줄을 넣어 끈다.

zstyle ':omz:update' mode disabled

프레임워크 없이 .zshrc만 직접 관리해도 충분한 사람이 많다. 자동완성이 아쉬우면 Python 가상환경 venv 만들기처럼 손이 자주 가는 작업부터 alias로 줄여보고, 그래도 부족할 때 넘어오는 편이 낫다.

자주 쓰는 명령과 단축키

설치 직후에 제일 많이 치는 것들만 모았다.

셸 단축키는 이것만 익혀도 손이 편해진다.

내가 막혔던 곳

첫 번째는 brew가 두 개였던 일이다. 예전에 Rosetta로 띄운 터미널에서 Homebrew를 설치해서 /usr/local/bin/brew가 남아 있었고, 새로 설치한 /opt/homebrew/bin/brew와 번갈아 잡혔다. 터미널마다 brew --version이 다르게 나와서 한참 헤맸다. 지금은 새 맥을 세팅할 때 가장 먼저 which -a brew로 중복을 확인한다. 두 줄이 나오면 하나는 지우고 PATH 순서를 정리해야 한다.

두 번째는 Intel 맥에서의 지원 등급이다. 내가 쓰는 맥은 macOS 13.7.8에 Intel CPU라, 공식 문서의 요구 사항(Apple Silicon + macOS 15 이상)에 들어가지 않는다. 실제로 Homebrew 6.0.18이 /usr/local/bin/brew에서 잘 돌고 있지만, 문서상으로는 Tier 3다. 새 formula를 깔 때 미리 빌드된 bottle이 없어서 소스 컴파일로 떨어지는 경우가 있고, 이때는 Xcode Command Line Tools가 필요하다. xcode-select --install로 미리 깔아두면 이 상황에서 덜 당황한다.

세 번째는 .zshrc에 PATH를 넣은 일이다. 새 탭에서는 잘 되는데 SSH로 들어가면 command not found가 났다. 로그인 셸이 읽는 파일이 .zprofile이라서 그랬다. PATH는 .zprofile, 나머지는 .zshrc로 나눠 넣고 나서야 두 경우가 같이 해결됐다. Claude Code처럼 설치 후 PATH 안내를 주는 도구를 쓸 때도 같은 함정에 빠지기 쉬우니, Claude Code 설치·사용법의 PATH 부분과 같이 보면 좋다.

참고 자료

• Homebrew — brew.sh (설치 명령, prefix, formula·cask 개념)
• Homebrew — Installation (macOS 요구 사항, sudo를 쓰지 않는 이유)
• Homebrew — Support Tiers (Tier 1 조건, Intel macOS는 Tier 3)
• Apple 지원 — zsh를 기본 셸로 사용하기 (10.15부터 기본, .zprofile·.zshrc 역할, chsh)
• iTerm2 — Downloads (3.7.7, macOS 13+)
• iTerm2 — Shell Integration (3.5부터 자동 로드, 설치 명령)
• Oh My Zsh · README (플러그인 300+, 테마 150, 설치·업데이트 설정)
• Python 설치 (Mac) · Python 가상환경 venv 만들기 · Claude Code 설치·사용법

2026년 11월 5일, 구글이 Gemini Omni 1.2 Flash를 정식 출시했다. 영상 길이가 10초에서 15초로 늘고, 가격은 30% 내렸다. 숫자만 보면 작은 업데이트 같지만, 실제로 바뀐 건 "영상 한 편을 다시 뽑지 않고 대화로 고친다"는 작업 방식이다.

이 글은 Gemini Omni 1.2 Flash가 무엇인지, 1.1과 뭐가 달라졌는지, 초당 $0.07이라는 요금이 실제로 얼마인지 정리한다.

30초 요약

목차

1. Gemini Omni 1.2 Flash란?
2. 1.1 Flash와 무엇이 달라졌나
3. 요금 계산 — 초당 $0.07은 실제로 얼마인가
4. Gemini API로 영상 만드는 방법
5. 어디서 쓸 수 있나 (제품별 정리)
6. 한계와 주의할 점
7. 내가 막혔던 곳
8. 참고 자료

Gemini Omni 1.2 Flash는 2026년 11월 5일 정식 출시됐다. 15초 영상과 초당 0.07달러라는 두 숫자가 이번 업데이트의 핵심이다.

Gemini Omni 1.2 Flash란?

Gemini Omni는 구글 딥마인드의 영상 생성·편집 모델 계열이다. 추론 특화 모델인 Gemini 4와 이름이 비슷해 헷갈리기 쉬운데, Omni는 "영상을 만들고 고치는 모델"이라고 보면 된다. 텍스트 프롬프트만으로 영상을 만들고, 만든 영상을 자연어 대화로 계속 수정할 수 있다.

입력은 텍스트, 이미지, 영상 세 가지다. 출력은 영상과 그에 맞춰진 네이티브 오디오, 그리고 텍스트다. 별도 음성 합성 단계를 붙이지 않아도 대사와 립싱크가 같이 나온다. (Gemini API 문서)

버전은 세 개가 있다. gemini-omni-1.2-flash가 현재 안정 버전이고, gemini-omni-1.1-flash는 2026년 12월 3일부터 1.2로 자동 라우팅된다. gemini-omni-flash-preview는 종료됐다. 기존 코드에서 1.1을 쓰고 있어도 12월 3일 이후에는 코드 수정 없이 1.2로 넘어가고, 요금은 더 싼 1.2 기준으로 매겨진다. (모델 문서)

한 가지 미리 짚어둘 점이 있다. 이 모델은 무료 티어가 없다. Gemini API에서 쓰려면 유료 티어여야 한다. (요금 문서)

1.1 Flash와 무엇이 달라졌나

가장 큰 변화는 길이다. 1.1은 최대 10초였는데, 1.2는 15초까지 만들고 편집한다. 3초에서 15초 사이를 1초 단위로 지정할 수 있어서, 6초 제품 소개나 15초 광고를 한 번에 뽑을 수 있다.

두 번째는 대화형 편집이다. 마음에 안 드는 부분이 있으면 전체를 다시 생성하는 대신 "배경만 바꿔줘", "조명을 더 따뜻하게"처럼 다음 턴에서 요청한다. 이 방식이 15초 전체 길이에서 동작한다. 초안은 360p나 720p로 빠르게 뽑고, 세부를 고친 다음, 최종본만 1080p나 4K로 업스케일하는 워크플로가 공식적으로 권장된다.

세 번째는 레퍼런스 고정이다. 최대 6장의 레퍼런스 이미지와 3초 이하의 짧은 모션 클립을 넣어 인물·제품·브랜드 색을 일관되게 유지한다. 얼굴, 의상, 패키지 타이포그래피가 카메라 각도가 바뀌어도 흐트러지지 않는 게 목표다.

네 번째는 연속 촬영감이다. FPV 드론 비행이나 급격한 줌아웃 같은 복잡한 카메라 무빙에서 불필요한 점프 컷이 줄었다고 구글은 설명한다. 다만 빠른 스포츠 동작, 급격한 대본 변경, 복잡한 물리 표현은 아직 개선 중이라고 공식 블로그에 적혀 있다.

1.1과 1.2를 같은 항목으로 비교했다. 길이와 가격이 바뀌고, 해상도와 레퍼런스 이미지 수는 그대로다.

출처: Google DeepMind 모델 문서, 출시 블로그

요금 계산 — 초당 $0.07은 실제로 얼마인가

공식 요금표는 초당 달러가 아니라 토큰 단위로 적혀 있다. 영상 출력은 100만 토큰당 $12이고, 720p 영상 1초가 5,792 토큰으로 계산된다. 이걸 곱하면 초당 약 $0.07이 나온다.

출처: Gemini API 요금. 입력은 텍스트·이미지·영상 모두 100만 토큰당 $1.50, 텍스트 출력은 100만 토큰당 $9다.

여기서 많이들 착각하는 게 있다. 15초 4K 한 편이 $3를 넘는다는 건, 열 번만 다시 뽑아도 $30이라는 뜻이다. 반대로 같은 15초를 360p로 초안 뽑고 마음에 드는 것만 4K로 올리면 비용이 크게 줄어든다. 구글이 "초안은 낮게, 최종만 높게"를 강조하는 이유가 여기에 있다.

15초 4K 최종본 1편 = $3.13
15초 360p 초안 5편 + 4K 업스케일 1편
= (0.35 × 5) + 3.13 = $4.88
→ 무작정 4K로 5번 뽑는 것($15.65)보다 약 3분의 1

Gemini API로 영상 만드는 방법

Python SDK에서는 client.interactions.create를 쓴다. 모델 이름만 넣고 프롬프트를 보내면 영상과 오디오가 함께 돌아온다.

import base64
from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-omni-1.2-flash",
    input="A marble rolling fast on a chain reaction style track, continuous smooth shot.",
)
with open("marble.mp4", "wb") as f:
    f.write(base64.b64decode(interaction.output_video.data))

길이와 해상도, 화면 비율은 response_format에서 정한다. 세로 영상은 9:16, 가로는 16:9다.

interaction = client.interactions.create(
    model="gemini-omni-1.2-flash",
    input="A futuristic city with neon lights and flying cars, cyberpunk style",
    response_format={
        "type": "video",
        "aspect_ratio": "9:16",
        "resolution": "1080p",
        "duration": "15s",
    },
)

REST로 직접 호출할 때는 주의할 점이 있다. SDK의 interaction.output_video 편의 필드는 SDK 전용이고, REST 응답에서는 steps 배열 안의 model_output을 뒤져서 base64 영상 데이터를 꺼내야 한다. (REST 응답 스키마)

영상 확장은 마지막 10초를 참고해 3~10초씩 덧붙이는 방식이다. 한 번에 30초까지만 늘릴 수 있고, 앞쪽이나 중간에 끼워 넣는 건 안 된다. 대화가 들어 있는 업로드 영상에 새 대사를 추가하는 것도 현재는 지원하지 않는다.

어디서 쓸 수 있나 (제품별 정리)

제품별 제공 위치는 출시 블로그 기준이다. Google Vids는 15초 클립을 추가 비용 없이 만들 수 있다고 안내한다. 다만 Vids의 무료 생성과 API 과금은 별개다.

결과물에는 보이지 않는 SynthID 워터마크와 C2PA 콘텐츠 자격 증명이 붙는다. AI가 만든 영상인지 나중에 검증할 수 있게 하려는 장치다. (DeepMind — Gemini Omni)

구글 공식 발표 페이지를 직접 캡처했다. 15초·30% 인하·제공 제품 목록이 한 화면에 나온다.

한계와 주의할 점

문서에 적힌 제약을 모아두면 다음과 같다. (Limitations)

• 오디오 입력과 오디오 레퍼런스는 아직 지원하지 않는다. 레퍼런스 영상에 들어 있는 소리는 무시된다.
• 보이스 편집은 안 된다. 목소리만 바꾸는 용도로는 쓸 수 없다.
• 여러 영상을 동시에 참조하거나 비교 추론하는 기능은 없다.
• 시스템 지시문, temperature, top_p, 중지 시퀀스, 네거티브 프롬프트를 지원하지 않는다. 부정 조건은 본문 프롬프트에 "Do not do X" 형태로 써야 한다.
• 첫 프레임·마지막 프레임 보간은 3~10초만 된다. 10초를 넘기면 오류가 난다.
• 업로드한 영상의 편집·확장은 EEA, 스위스, 영국에서 아직 안 된다. 모델이 만든 영상을 다시 편집하는 건 된다.
• 미성년자가 나온 이미지의 업로드·편집은 EEA, 스위스, 영국에서 지원하지 않는다.
• YouTube 영상을 소스로 넣는 건 안 된다.

국내 사용자 입장에서 당장 걸리는 건 오디오 입력과 보이스 편집이다. 제품 광고에서 모델의 목소리를 그대로 쓰고 싶다면, 지금은 영상 생성 단계에서 대사를 함께 뽑는 방식으로 우회해야 한다.

내가 막혔던 곳

요금표를 처음 봤을 때 "초당 $0.07"만 보고 15초짜리를 몇 번 뽑아보면 얼마 안 나오겠다고 생각했다. 실제로는 세 가지가 더 붙는다.

첫째, 출력 길이를 안 정하면 기본값이 10초라는 점이다. 3초만 필요한데 10초로 뽑으면 같은 컷을 세 번 만드는 셈이다. duration을 항상 명시하는 습관이 비용을 줄인다.

둘째, 1080p와 4K는 업스케일 단계에서 토큰이 다시 매겨진다. 720p로 뽑고 4K로 올리면 720p 요금에 4K 요금이 더해지는 구조다. "4K로 바로 뽑으면 한 번만 내지 않나" 싶지만, 공식 계산은 해상도별 토큰 단위로 따로 잡힌다. 초안 단계와 최종 단계를 분리해서 견적을 내야 한다.

셋째, 1.1을 쓰던 코드가 12월 3일에 자동으로 1.2로 넘어간다. 요금은 싸지지만 출력 길이 기본값과 레퍼런스 제약이 달라지므로, 길이를 명시하지 않은 코드는 결과가 달라질 수 있다. 지금 duration을 넣어두면 12월 이후에도 같은 길이로 나온다.

영상 모델을 고를 때 전체 지형이 궁금하면 멀티모달 AI란과 AI 기초 용어 20개 정리를 같이 보면 도움이 된다. 프롬프트가 길어질 때의 토큰 계산은 토큰(token)이란에서 다뤘다.

참고 자료

• Google — Gemini Omni 1.2 Flash 출시 블로그 (2026-11-05, 15초·30% 인하·제품별 제공 위치)
• Gemini API — Generate and edit videos with Gemini Omni Flash (Interactions API, 길이·해상도·레퍼런스, 제약)
• Gemini API — Gemini Omni Flash 모델 사양 (토큰 한도, 3~15초, 24fps, 버전 정책)
• Gemini API — 요금 (초당 토큰, 해상도별 요금)
• Google DeepMind — Gemini Omni (SynthID·C2PA, 안전 평가)