Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

돌고 있는 셸 스크립트에서 설명 줄 28바이트를 지웠을 뿐인데 백업 단계가 빠지고 원본 지우기가 실행됐고, 종료 코드는 0이었습니다(2026-10-01, macOS 27.0, bash 5.3.20 재현). 이럴 때 클로드 코드 되돌리기로 파일을 돌려도 이미 실행된 단계는 돌아오지 않습니다.

안녕하세요? 정리하는 개발자 워니즈입니다. 앞 글 클로드 코드 멀티 에이전트, 거짓 6건 뒤 나눈 역할에 이어, 9월 26일 실제로 겪은 스크립트 덮어쓰기와 빈 폴더에서 다시 돌린 실험 네 개를 정리합니다.

• 무엇을 했나 클로드 코드 되돌리기(/rewind)는 파일 내용을 돌려놓는 기능이고, 저는 돌고 있는 bash 스크립트를 실행 중에 고치는 실험 A~D 를 돌렸습니다
• 결과 숫자 28바이트 삭제는 종료 코드 0으로 백업을 건너뛰었고, 22바이트 추가는 종료 코드 2로 멈췄으며, 사본에 고쳐 mv 로 바꾸자 세 단계가 모두 돌았습니다
• 누구에게 쓸모 크론처럼 주기적으로 도는 셸 스크립트를 AI 에게 고치게 하는 분께 맞습니다

1. 클로드 코드 되돌리기 전에, 왜 종료 코드 0이었나요?

bash 가 스크립트를 한꺼번에 읽지 않고 실행하면서 다음 위치를 바이트로 기억해 이어 읽는 것처럼 움직였기 때문입니다. 빈 폴더의 여섯 줄짜리 deploy.sh(준비, 백업, 원본 지우기를 echo 로만 찍는 모형)를 돌려 두고 1초 뒤 맨 위 설명 줄을 지우자 출력이 [1] 준비 다음 [3] 원본 지우기 로 끝났습니다. 오류는 한 줄도 없었습니다. 결과가 가장 나쁜 경우가 신호는 가장 조용했습니다.

정직하게 덧붙이면, 지운 줄을 다음 백업 줄과 같은 28바이트로 일부러 맞췄습니다. 길이가 어긋난 실험 B(문구 22바이트 추가)는 한글 글자 한가운데부터 읽혀 종료 코드 2로 멈췄습니다. 흔한 쪽은 B 이고, A 는 운이 나쁘면 오류 없이 엉뚱한 단계가 돈다는 데까지만 보여 줍니다.

2. 어떤 고치기가 같은 inode 에 다시 쓰나요?

> 리다이렉트와 python open(w) 가 같은 inode 에 다시 쓰고, sed -i '', perl -pi, 사본 뒤 mv, Claude Code 2.1.281 Edit 도구는 새 inode 를 만들었습니다(ls -i 실측, 표는 부록). 돌던 bash 를 깨는 것은 같은 inode 쪽입니다. Edit 도구 결과는 한 버전에서 한 번 본 값이라 일반화하지 않습니다.

9월 26일 실제 사고도 이 차이로 막았습니다. lsof -p PID 로 돌던 프로세스가 옛 inode 를 쥔 것을 보고, 백업을 cat 백업 > 원본 으로 같은 inode 에 되돌린 뒤 새 판본은 mv 로 넣었습니다. 권한을 줄 때 되돌릴 수 있다고 믿는 비용은 AI 에이전트 권한 설계와 되돌리기 비용에 적었습니다.

3. 클로드 코드 되돌리기(/rewind)는 어디까지 되돌리나요?

Claude 의 파일 편집 도구로 고친 파일까지입니다. 공식 문서는 체크포인트가 “Checkpointing does not track files modified by Bash commands.” 라고 적고, 버전 관리를 대신하지 않는다고 못 박습니다(Claude Code checkpointing 공식 문서). 가장 위험한 셸 명령 편집이 가장 되돌리기 어려운 편집이기도 했습니다.

원본 지우기는 파일이 아니라 이미 일어난 행동이라 /rewind 로 파일을 돌려도 지워진 것은 그대로입니다. 그래서 되돌리기를 믿을 만하게 만드는 대신 고치는 순서를 바꿨습니다.

4. 사본에 고치고 bash -n 뒤 mv 로 바꾸면 무엇이 달라지나요?

실험 A 와 똑같이 설명 줄을 지우되 사본 deploy.sh.new 에서 고치고 bash -n 통과 뒤 mv 로 넣자, inode 가 6015892 에서 6015932 로 바뀌었고 돌던 프로세스는 옛 판본의 세 단계를 종료 코드 0으로 끝까지 실행했습니다. 편집 내용은 같고 원본에 닿는 방식만 바꿨는데 백업이 살아 있었습니다.

5. 이렇게 해도 안 되는 것은 무엇인가요?

1. 이미 실행된 단계는 어떤 되돌리기로도 돌아오지 않아, 지워질 대상은 git 이나 별도 백업으로 지킵니다
2. bash -n 은 문법만 보고 단계 순서를 잘못 바꾼 판본은 통과시킵니다
3. 9월 25일 여러 번 제자리 편집하고도 무사했던 이유, /rewind 가 같은 inode 에 쓰는지, zsh 나 다른 bash 판의 동작은 확인하지 않았습니다
4. 세 줄은 작업 규칙이지 게이트가 아닙니다. 규칙과 지켜짐이 다른 이야기라는 것은 AI에게 규칙을 알려줬는데 안 지켜졌습니다에서 겪었습니다

필자의 결론

클로드 코드 되돌리기는 파일을 돌리는 도구이고, 돌고 있는 스크립트의 사고를 막는 도구는 아닙니다.

주기적으로 도는 셸 스크립트는 사본에 고치고 bash -n 통과 뒤 mv 로 바꾸세요.

오늘은 그런 스크립트 하나에 ls -i 를 찍어 두고, 다음에 고친 뒤 번호가 바뀌었는지만 확인해 보세요.

돌고 있는 스크립트를 고칠 때 다른 방식으로 막고 계신 분은 어떤 순서를 쓰시나요?

부록: 재현 명령과 출력

1. 환경. 2026-10-01 밤, macOS 27.0, GNU bash, 버전 5.3.20(1)-release (aarch64-apple-darwin27.0.0), mktemp -d 로 만든 /tmp 빈 폴더. deploy.sh 는 1 #!/bin/bash, 2 # 옛 설명(공백으로 28바이트), 3 echo "[1] 준비", 4 sleep 3, 5 echo "[2] 백업 만들기", 6 echo "[3] 원본 지우기".
2. 실험 A 명령과 출력.

bash deploy.sh > a.out 2>&1 & P=$!; sleep 1
python3 -c "p='deploy.sh'; s=open(p).read(); open(p,'w').write(s.replace(s.splitlines(True)[1],''))"
wait $P; echo "종료 코드 $?"; cat a.out

== 실험 A: 실행 중에 맨 위 설명 줄 하나를 지운다(제자리 편집)
종료 코드 0
[1] 준비
[3] 원본 지우기

1. 실험 B 출력(3번 줄을 echo "[1] 준비 (설명을 늘렸다)" 로 늘림).

종료 코드 2
[1] 준비
deploy.sh: 줄 5: 예기치 않은 `)' 토큰 주변에서 문법 오류
deploy.sh: 줄 5: `� 늘렸다)"'

1. 66번째 바이트 계산. 줄 길이는 12, 28, 18, 8, 28, 28바이트라 백업 줄은 66번째 바이트에서 시작합니다. 28바이트를 지우면 그 자리에 원본 지우기 줄이 오고, 22바이트를 넣으면 그 자리가 을 의 세 번째 바이트입니다(repro.sh 문자열을 python3 -c 로 셈).
2. inode 실측(repro-inode.log, ls -i).

1. 실험 C 명령과 결과.

cp deploy.sh deploy.sh.new
# 여기서 deploy.sh.new 를 고친다
bash -n deploy.sh.new && echo "bash -n 통과" && mv deploy.sh.new deploy.sh; ls -i deploy.sh

바꾸기 전 6015892, bash -n 통과, 바꾼 뒤 6015932, 돌던 프로세스 종료 코드 0, 돌던 프로세스와 다음 실행 모두 [1] 준비, [2] 백업 만들기, [3] 원본 지우기.

1. 실제 사고 기록. 2026-09-25 다른 세션이 같은 스크립트를 여러 번 제자리 편집(로그에 문법 오류 없음, 이유는 미확인), 2026-09-26 AI 세션 하나가 실행 중인 스크립트를 덮어씀(inode 복구로 피해를 막음). 셀프테스트가 통과해도 실데이터에서 틀렸던 비슷한 결의 기록은 바이브 코딩 현실, 테스트는 통과했는데 261편 중 6편만 맞았다에 있습니다.

The post [AI 코딩] 클로드 코드 되돌리기, 종료 코드 0인데 백업이 빠졌다 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

제미나이 사용법을 직접 시험해 보니 같은 채팅에서 find -mtime +3 설명이 처음에는 “72시간 초과”, 되묻자 “96시간부터” 로 뒤집혔습니다. PDF, 리눅스 명령, 화면 사진을 맡겨도 될까요? 표로 옮기는 일은 맡길 만했고 명령 설명은 한 번 더 되물어야 맞았습니다.

• 무엇을 했나 2026-10-02 오전 제미나이 웹 임시 채팅에 PDF 문서, 리눅스 명령, 화면 사진 세 가지 일을 맡겼습니다
• 결과 숫자 PDF 의 할 일 3개와 터미널 캡처의 파일 3개는 원문 그대로였고, 명령 설명은 두 번 물어 두 번 다 틀렸습니다
• 누구에게 쓸모 문서나 화면을 표로 옮기거나 리눅스 명령을 제미나이에게 묻는 분

안녕하세요? 정리하는 개발자 워니즈입니다. 제미나이 노트북과 노트북LM 차이는 제미나이 노트북 사용법, 노트북LM 차이 5가지에, 이미지 만들기는 제미나이 이미지 생성 방법, 한글 글자와 워터마크에 따로 정리해 두었습니다.

1. 제미나이 사용법 실측, 리눅스 명령 설명은 왜 첫 답과 되물은 답이 달랐을까?

첫 답에 붙은 설명 한 줄이 틀렸기 때문입니다. 시험은 2026-10-02 10:05~10:12 에 제미나이 웹에서 했고, 상황마다 새 임시 채팅을 열고 모드 메뉴에서 ‘3.8 Flash’ 를 골랐습니다.

질문의 요지는 “3일 넘게 지난 .log 파일만 지우는 명령을 알려 주고, 지우기 전에 목록을 먼저 보는 명령도 같이 달라” 였습니다. 명령 꼴은 맞았는데 설명은 이랬습니다.

-mtime +3: 수정된 지 정확히 3일(72시간)을 초과한 파일을 찾습니다.

새 임시 채팅에서 한 번 더 물어도 “72시간을 초과한 파일을 필터링합니다” 로 같았습니다. 거기서 “방금 명령에서 -mtime +3 이면 73시간 지난 파일도 지워져? 예, 아니오로 먼저 답해 줘.” 라고 묻자 첫 줄이 “아니오.” 였습니다.

96시간(정확히 만 4일) 이상 지난 파일: 24로 나누었을 때 4 이상이 되므로 이때부터 +3에 걸려 삭제됩니다.

어느 쪽이 맞는지는 73시간, 95시간, 97시간 전으로 시각을 되돌린 빈 .log 파일 3개로 가렸습니다. macOS 27.0 의 BSD find 와 debian:stable-slim 컨테이너의 GNU find 4.10.0 으로 목록만 뽑았습니다.

73시간 파일은 걸리지 않고 97시간 파일만 나왔습니다. 첫 답 설명이 틀렸고 되물은 뒤의 답이 맞았습니다. 필자는 -delete 가 붙은 지우는 명령을 한 번도 실행하지 않았습니다.

2. PDF 문서를 맡기면 할 일 표는 원문과 맞았나요?

맞았습니다. 할 일 3개는 원문과 한 줄도 다르지 않게 뽑혔고 지어낸 행은 0개여서, PDF 를 다루는 제미나이 사용법으로는 가장 맡기기 편한 일이었습니다.

PDF 는 필자가 이 글을 위해 직접 쓴 1쪽짜리 가상 점검 보고서입니다. 질문은 “첨부한 시험용 점검 보고서에서 할 일을 담당자, 기한, 할 일 세 칸 표로 정리해 줘. 문서에 없는 내용은 넣지 마.” 였고, 답이 끝날 때까지 7.7초가 걸렸습니다.

할 일이 아닌 “다음 점검은 10월 28일이다.” 는 요청대로 빠졌습니다. 막힌 곳은 모양이었습니다. 표가 그려지지 않고 | :--- | :--- | :--- | 같은 기호가 글자 그대로 보였고 머리줄이 한 번 겹쳤습니다.

3. 화면 사진을 맡기면 터미널 캡처를 글자 그대로 읽었나요?

읽었습니다. 파일 이름 3개와 시각 3개가 한 글자도 틀리지 않고 표로 옮겨졌고, -mtime +3 아래 파일도 ‘./age-97h.log’ 하나로 맞게 읽었습니다. 답이 끝나기까지 6.1초가 걸렸습니다.

올린 사진은 1절의 GNU find 실제 출력을 그대로 옮긴 터미널 캡처라서 이 제미나이 사용법 예제는 정답을 필자가 이미 알고 있는 상태에서 채점한 셈입니다.

이번에는 표가 제대로 그려졌지만 칸마다 ‘PNG’ 라는 출처 칩이 붙었습니다. 답의 글자만 뽑아 보니 파일 이름과 시각 사이사이에 ‘PNG’ 라는 글자가 끼어 있었습니다.

사진과 함께 물었을 때는 -mtime +3 을 처음부터 96시간으로 맞게 말했습니다. 사진 속 출력이 정답을 보여 줘서 그랬는지는 한 번의 시험으로 가릴 수 없어 미확인으로 남깁니다.

4. 리눅스 명령은 어떻게 되물어야 할까?

경계가 되는 숫자를 하나 집어 “예, 아니오로 먼저” 되묻는 것이 이번 제미나이 사용법에서 가장 쓸모 있었던 질문법이었습니다. 필자가 정한 순서는 세 가지입니다.

• 목록 명령부터 돌립니다. 제미나이도 첫 줄에 -delete 없는 목록 명령을 줬습니다
• 경계 숫자로 되묻습니다. 73시간처럼 경계 바로 위의 숫자를 넣어 예, 아니오를 먼저 받습니다
• 분 단위로 바꿔 씁니다. 72시간을 넘긴 파일이 목적이라면 -mmin +4320 이 시간 계산을 덜 헷갈리게 했습니다

매일 반복되는 로그 정리라면 정해 둔 설정에 맡기는 편이 낫습니다. 설정은 Nginx Logrotation 설정, 셸 기본기는 Bash 입문자를 위한 핵심 요약 정리에 정리해 두었습니다.

5. 이번 제미나이 사용법 실측으로 안 되는 것과 확인하지 못한 것

모드 메뉴에 보인 네 이름 가운데 이 글의 결과는 전부 3.8 Flash 한 모드의 결과입니다. 등급별 사용 한도는 제미나이 앱 도움말에서 확인하시는 편이 맞습니다.

1. 모드별, 등급별 사용 횟수와 요금은 확인하지 않았습니다.
2. 휴대폰 앱과 크롬 안의 제미나이는 쓰지 않았고, 전부 웹에서 시험했습니다.
3. 1쪽보다 긴 PDF, 스캔한 PDF, 여러 파일 올리기는 해 보지 않았습니다.

필자의 결론

이번 제미나이 사용법 세 상황을 정리하면, 필자는 제미나이를 원문 대조가 쉬운 옮겨 적기에는 맡기고, 명령 설명은 반드시 한 번 되묻는 도구로 봅니다. 같은 모드가 같은 채팅 안에서 72시간이라고 했다가 96시간이라고 뒤집었고, 맞은 쪽은 find 를 직접 돌려 보고서야 가렸기 때문입니다.

그래서 당신은 이것만 하면 됩니다. 제미나이가 준 명령에 -delete 나 rm 이 있으면 목록 명령을 먼저 돌리고, 경계 바로 위의 숫자를 넣어 “예, 아니오로 먼저 답해 줘” 라고 되물어 보세요.

첫 설명과 되물은 답이 달랐던 명령이 있으셨다면 댓글로 남겨 주세요.

부록: 재현 명령과 출력

제미나이가 처음 돌려준 두 줄입니다(제미나이 답 원문, 2026-10-02 10:06).

find . -maxdepth 1 -type f -name "*.log" -mtime +3
find . -maxdepth 1 -type f -name "*.log" -mtime +3 -delete

필자가 돌린 스크립트에서 파일을 만들고 -mtime +3 을 고르는 줄만 옮겼습니다. 맥과 리눅스 양쪽에서 돌도록 touch 를 두 방식으로 걸었습니다.

d=$(mktemp -d); cd "$d"
now=$(date +%s)
for h in 73 95 97; do f="age-${h}h.log"; : > "$f"; t=$((now - h*3600)); touch -d "@$t" "$f" 2>/dev/null || touch -t "$(date -r $t +%Y%m%d%H%M.%S)" "$f"; done
find . -maxdepth 1 -type f -name "*.log" -mtime +3 | sort

GNU find 4.10.0(debian:stable-slim 컨테이너, 2026-10-02 10:08 실행) 출력입니다. 컨테이너 시각이 UTC 라 한국 시각으로는 9시간을 더합니다.

-rw-r--r-- 1 root root 0 2026-09-29_00:08 age-73h.log
-rw-r--r-- 1 root root 0 2026-09-28_02:08 age-95h.log
-rw-r--r-- 1 root root 0 2026-09-28_00:08 age-97h.log
find . -maxdepth 1 -type f -name '*.log' -mtime +3:
./age-97h.log

72시간을 넘긴 .log 를 고르는 목록 명령입니다. BSD find 와 GNU find 둘 다에서 73시간, 95시간, 97시간 파일 셋을 모두 골랐습니다.

find . -maxdepth 1 -type f -name "*.log" -mmin +4320

PDF 답의 행 대조입니다. 문서와 표에 나오는 김 대리, 박 과장, 이 주임은 모두 가상 인물입니다.

걸린 시간은 보낸 시각부터 생성 중지 단추가 사라진 시각까지입니다. PDF 는 올린 뒤 보내기까지 3.7초와 답 7.7초, 첫 명령 질문 답 4.5초, 다시 연 채팅의 명령 질문 답 12.1초, 되묻기 답 6.1초, 사진 답 6.1초였습니다.

-mtime 과 -mmin 조건의 원문은 GNU findutils 설명서에 있습니다. 확인용 이미지가 쌓였다면 도커 이미지 용량 정리 3단계 순서로 치우시면 됩니다.

The post 제미나이 사용법, 리눅스 명령 설명이 첫 답과 둘째 답에서 달랐다 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

클로드 요금제 비교에서 가장 먼저 갈리는 지점은 어디일까요? 답은 클로드 코드(Anthropic 이 만든 코딩 도구)를 쓰느냐입니다. Free 는 0달러지만 클로드 코드가 빠져 있고, 클로드 코드가 필요하면 Pro 월 20달러부터입니다.

• 무엇을 했나 2026-10-02 에 공식 요금 페이지와 지원 문서를 직접 열어 세 요금제 숫자를 한 줄씩 대조했습니다
• 결과 숫자 Free 0달러, Pro 월 20달러(연간 결제 시 월 17달러), Max 월 100달러부터이고 요금제별 사용 한도 수치는 공식 문서에 없었습니다
• 누구에게 쓸모 클로드 코드를 쓰려고 어느 요금제에 돈을 낼지 고르는 분

안녕하세요? 정리하는 개발자 워니즈입니다. 이 글의 숫자는 남의 정리표가 아니라 공식 원문에서만 가져왔습니다.

1. 클로드 요금제 비교, 가격은 얼마인가요?

0달러, 20달러, 100달러부터의 세 계단입니다. 2026-10-02 에 claude.com 요금 페이지를 직접 열어 읽은 숫자입니다.

Pro 는 결제 주기에 따라 월 20달러와 월 17달러로 표기돼 있습니다. Max 는 고정 가격이 아니라 시작가라서 “부터” 를 꼭 붙여 읽어야 합니다.

결제 주기만 바꿔도 Pro 는 15% 싸진다는 점이 가격표에서 가장 손에 잡히는 숫자인 것 같습니다. 12개월 계산은 부록에 두었습니다. 원화 환산과 세금 포함 여부는 확인하지 못해 미확인으로 남깁니다.

2. Free, Pro, Max 기능은 무엇이 다른가요?

위 요금제가 아래 요금제 기능을 전부 포함하고 무언가를 더하는 계단식입니다. 위로 올라가며 사라지는 기능은 없습니다.

Free 에도 채팅, 웹 검색, 파일 생성, 코드 실행, 프로젝트 최대 5개가 있습니다. Pro 는 여기에 클로드 코드와 모든 Claude 모델 접근을 더합니다. Max 는 Pro 대비 5x 또는 20x 사용량을 고르는 구조입니다.

그래서 Free 에서 Pro 로 가는 첫 계단은 기능이 바뀌고, Pro 에서 Max 로 가는 둘째 계단은 양이 바뀝니다. 클로드 요금제 비교를 표 한 장으로 끝내기 어려운 이유가 여기 있습니다.

3. 클로드 코드는 어느 요금제부터 쓸 수 있나요?

Pro 부터이고 Max 에도 그대로 들어 있습니다. 개발자의 클로드 요금제 비교에서는 Pro 가 사실상 입장권입니다.

놓치기 쉬운 문장은 지원 문서의 아래 한 줄입니다. 채팅과 클로드 코드가 따로 노는 두 통이 아니라 한 통을 나눠 쓴다는 뜻으로 읽힙니다.

“Both Pro and Max plans offer usage limits that are shared across Claude and Claude Code” (support.claude.com, 2026-10-02 확인)

그 통의 크기는 원문에 없습니다. 요금 페이지 자주 묻는 질문에는 한도가 5시간 단위 세션 창에서 리셋되고 유료 요금제에 주간 한도가 더 붙는다고만 적혀 있습니다.

남은 양은 클로드 코드 세션에서 /status 로 보라고 지원 문서가 안내합니다. 보는 법은 클로드 코드 사용량 확인 3가지에, 도구의 작업 흐름은 서평 클로드 코드 에이전틱 코딩에 정리했습니다.

4. Pro 로 충분할까, Max 5x 와 20x 는 언제 볼까요?

개발 용도의 클로드 요금제 비교는 Pro 에서 출발하는 것이 자연스럽습니다. 다만 충분한지는 쓰기 전에 표로 판정할 수 없습니다. 한도가 공유되는데 그 크기가 공개되지 않아서입니다.

그래서 Pro 로 시작해 /status 로 남은 양을 지켜보다가, 작업이 멈추는 일이 반복될 때 Max 로 올리는 순서가 가장 정직합니다. 같은 방식으로 커서 AI 무료 한도 총정리, 공식 문서 기준도 대조해 두었습니다.

Max 의 5x 와 20x 는 Pro 대비 배수라서 Pro 의 절대량을 모르면 Max 의 절대량도 알 수 없습니다. 5x 로 올렸는데도 막힌다면 그때 20x 를 보는 순서가 비용 쪽 위험이 가장 적은 것 같습니다.

채팅과 문서 정리만 한다면 아직 돈을 낼 이유가 없습니다. 무료와 유료를 가르는 방식은 노션 AI 무료와 유료 차이 비교와 나란히 보셔도 좋습니다.

5. 요금표만 보고는 알 수 없는 것과 안 되는 것

클로드 요금제 비교를 공식 문서만으로 하면 분명히 비는 칸이 생깁니다. 공식 문서 기준으로 분명히 안 되는 것은 Free 에서 클로드 코드를 쓸 수 없다는 한 가지뿐입니다. 나머지는 안 된다가 아니라 공식 문서가 숫자를 주지 않는다입니다.

1. 요금제별 정확한 사용 한도와 세션당 메시지 수는 원문에 수치가 없습니다
2. Max 20x 개별 가격은 이번 대조 기록에 없어 적지 않았습니다
3. 팀 요금제, API 요금, 다른 회사 요금제는 이번 대조 범위에 넣지 않았습니다

필자의 결론

필자는 고르는 기준을 가격표가 아니라 두 질문, 클로드 코드를 쓰는가와 Pro 에서 실제로 막혔는가로 봅니다. 사용 한도 숫자가 공식 문서에 없는 이상 표만 보고 Max 를 고를 근거는 없습니다.

그래서 당신은 이것만 하면 됩니다. 결제 버튼을 누르기 전에 요금 페이지를 열어, 지금 자주 쓰는 기능이 Free 카드 안에 있는지부터 한 줄씩 대조해 보세요.

어떤 기준으로 클로드 요금제를 고르셨는지, 헷갈렸던 칸이 있었다면 댓글로 알려 주세요.

부록: 재현 명령과 출력

2026-10-02 에 데스크톱 브라우저로 연 원문 두 곳입니다. Claude 요금 페이지 (claude.com/pricing)와 Claude 구독으로 Claude Code 쓰기 지원 문서 11145838입니다. 개인 계정의 사용량과 결제 화면은 넣지 않았고, 개인 구독 세 요금제만 놓고 한 클로드 요금제 비교입니다.

가격 계산은 요금 페이지 숫자를 곱하고 나눈 값이고 실제 청구 금액이 아닙니다. Pro 월간 결제 12개월은 240달러, 월 17달러 12개월은 204달러라서 차이는 36달러입니다. 월 20달러에서 월 17달러로 내려가는 폭은 15% 이고, Max 시작가 100달러는 Pro 월간 결제의 5배입니다.

“표기 없음” 은 기능이 없다는 뜻이 아니라 요금 페이지 문구에 그 칸으로 적혀 있지 않았다는 뜻입니다. 모델별로는 Claude Fable 모델이 Max 요금제에 주간 사용 한도의 50% 만큼 포함되고, Pro 는 사용 크레딧으로 쓸 수 있다고 요금 페이지에 적혀 있습니다(2026-10-02 확인).

The post [AI Now] 클로드 요금제 비교, 0달러 20달러 100달러 3단계 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

AI 가 쓴 원고 하나에서 클로드 코드 기술 주장 9건 중 6건이 거짓이었습니다. 검사 역할에 고칠 권한까지 줘야 할까요? 필자의 답은 주지 않는다입니다.

• 무엇을 했나 검사 역할 서브에이전트에 Edit 를 뺀 판과 넣은 판을 빈 폴더에서 한 번씩 돌렸습니다
• 결과 숫자 Edit 없는 판은 원고 해시가 그대로였고, Edit 를 넣은 판은 검사자가 직접 고쳐 해시가 바뀌었습니다
• 누구에게 쓸모 AI 가 쓴 원고나 문서를 다른 AI 에게 검사시키는 분

안녕하세요? 정리하는 개발자 워니즈입니다. 앞 글 바이브 코딩 현실, 테스트는 통과했는데 261편 중 6편만 맞았다에서는 테스트 통과만 믿었다가 실데이터에서 어긋난 일을 적었습니다.

1. 클로드 코드 멀티 에이전트 검사 역할에 Edit 를 주면 어떻게 되나요?

검사자가 직접 고칩니다. 2026-10-01 macOS 에서 Claude Code 2.1.281, 모델 haiku 로 /tmp 빈 폴더 두 곳에서 한 번씩 돌렸습니다.

폴더에는 9월에 실제로 반송된 문장을 그대로 옮겼습니다. 원고는 “사용 가능 메모리는 오히려 늘었습니다”, 원문은 “통합 전 496MB에서 95MB 감소” 입니다.

실험 A(tools 가 Read, Grep)의 검사자는 거짓 1건을 보고하고 “Edit/Write 도구로 직접 수정하지 못했습니다” 라고 남겼습니다. 실험 B 는 tools 에 Edit 하나만 더했습니다. 보고에 “파일 수정: 완료됨” 이 찍혔고 해시가 2bfba1b9 로 바뀌었습니다.

2. 거짓 6건은 어떤 원고에서 나왔나요?

2026-09-08 에 다른 AI 도구가 만든 샘플 원고입니다. 클로드 코드 기술 주장 9건을 공식 문서와 로컬 실측으로 대조했더니 거짓 6, 부분사실 2, 확인불가 1, 사실 0 이었습니다.

있지도 않은 .claudeignore 설정 안내, macOS 에 없는 strace 로그, 약 1년 어긋난 출시 시점이 있었습니다. 형식 검사, 보안 검사, SEO 검사는 전부 통과할 수 있는 상태였습니다. 세 검사 모두 문장이 사실인지는 보지 않기 때문입니다.

규칙 문장을 하나 더 쓰는 것으로는 메워지지 않았습니다. 그 경험은 규칙을 알려줬는데 안 지켜졌던 기록에 적었습니다.

3. 쓰는 역할과 마감 역할을 이렇게 나눴습니다

클로드 코드 멀티 에이전트 구성에서 원고를 쓰는 역할과 검사하는 마감 역할을 다른 에이전트로 뗐습니다. 마감 역할 정의에 이유를 한 줄로 적었습니다. “원고를 쓴 주체가 자기 원고의 게이트를 판정하면 통과 쪽으로 기웁니다.”

도구를 좁히는 자리는 Claude Code 서브에이전트 공식 문서의 tools 필드입니다. 실험 A 와 B 도 이 칸 하나만 바꿨습니다.

4. 검사 역할에 쓰기 권한을 주면 무엇이 사라지나요?

클로드 코드 멀티 에이전트에서 검사 역할이 고치면 고친 문장을 다시 판정할 쪽과 반송 기록이 사라집니다. 실험 B 의 검사자는 원고에 없던 “496MB에서 401MB로” 를 넣었고, 이번에는 맞았습니다.

하지만 다음에 고친 문장에 새 거짓이 섞이면 아무 검사도 받지 않고 남습니다. 조용히 고치면 쓰는 역할은 자기가 방향을 뒤집었다는 것도 모릅니다.

실전 첫 적발은 2026-09-24 RDS 비용 줄이기 글이었습니다. 숫자는 맞고 방향만 반대인 문장이 1회차에 반송됐고, 2회차에 사실 12건 중 거짓 0 으로 통과했습니다.

5. 역할을 나눠도 안 되는 것

1. 재현은 haiku 로 판마다 한 번씩입니다. 다른 모델이나 두 번째 실행에서는 다르게 움직일 수 있습니다
2. Bash 를 쥔 마감 역할은 셸로 파일을 바꿀 수 있습니다. 나머지는 역할 정의 문장과 반송 형식이 맡습니다
3. 마감 역할이 대조 목록에 올리지 않은 문장은 이 구조로도 걸러지지 않습니다

보고만 믿지 않고 파일 상태를 한 번 더 보는 습관은 AI 에이전트로 혼자 일하면서 늘어난 것은 검증이었다는 글에서 이어진 것입니다.

필자의 결론

클로드 코드 멀티 에이전트에서 검사 역할은 고치는 손이 없어야 검사로 남는다고 봅니다. 실험 B 의 검사자는 맞는 문장을 썼지만 그 순간 두 번째 작성자가 됐습니다.

그래서 당신은 이것만 하면 됩니다. 검사용 서브에이전트 정의를 열어 tools 칸에 Edit 나 Write 가 있으면 빼고, 고칠 곳은 ‘거짓: 원고 문장 / 원문: 원문 문장’ 꼴로 보고하게 하세요.

검사 역할에 어떤 도구까지 주고 계신지 댓글로 나눠 주시면 다음 재현에 참고하겠습니다.

부록: 재현 명령과 출력

실험 A 명령입니다. 앞뒤 md5 -q 는 수정 여부를 보고 문장이 아니라 해시로 보려고 넣었습니다.

md5 -q draft.md
echo "checker 서브에이전트에게 draft.md 를 source.md 와 대조해 검사시키고, 틀린 곳이 있으면 checker 가 직접 draft.md 를 고치게 해. 너는 직접 파일을 고치지 마. 마지막에 checker 가 보고한 판정과 파일을 고쳤는지를 그대로 적어." | claude -p --model haiku --setting-sources project --agents "$(cat agents.json)" --allowedTools "Agent,Read"
md5 -q draft.md

실험 B 는 checker 의 tools 를 ["Read", "Grep", "Edit"], 바깥 --allowedTools 를 "Agent,Read,Edit" 로 바꾼 것 말고는 같습니다.

실험 B 를 같은 조건에 --output-format stream-json 만 더해 한 번 더 돌리자(2026-10-01 23시 40분) 서브에이전트가 Read 두 번과 Edit 한 번을 불렀습니다. 고친 쪽은 checker 였고, 고친 문장은 첫 판과 글자가 달랐습니다. 원문의 496MB 에서 401MB 를 빼면 95MB 이니 원고가 틀린 것은 숫자가 아니라 방향이었습니다.

The post [AI 코딩] 클로드 코드 멀티 에이전트, 거짓 6건 뒤 나눈 역할 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

터미널에서 안티그래비티 CLI 를 불렀더니 로그인 안됨이나 권한 거부 같은 오류가 떠서 어디부터 고쳐야 할지 막막하신가요?

안녕하세요? 정리하는 개발자 워니즈입니다. 이 글은 필자가 2026-09-29 에 macOS arm64 와 agy 1.2.13 으로 안티그래비티 CLI 를 직접 돌리며 낸 오류 7가지를 원문 메시지 그대로 적고 증상별로 고친 방법을 정리합니다.

한 줄 요약 안티그래비티 CLI 오류는 대부분 PATH 와 첫 로그인과 모델 이름에서 나왔고 오류 문구가 고칠 방향을 알려 줬습니다. 가장 위험했던 것은 헤드리스 모드에서 파일 쓰기가 거부됐는데도 종료 코드가 0 으로 끝나는 경우였습니다.

• 바로 고칠 것 command not found 는 PATH 문제였고 authentication timed out 은 대화형 첫 로그인으로, requires --effort 는 --effort high 로 풀렸습니다
• 스크립트라면 종료 코드만 보지 말고 출력 문구와 결과 파일로 성공을 판정해야 권한 거부를 놓치지 않습니다
• macOS 함정 허용 규칙을 /tmp 로 적으면 걸리지 않았고 실제 경로인 /private/tmp 로 적어야 걸렸습니다

목차

1. 안티그래비티 CLI 오류 7가지, 직접 재현하니 무엇이 나왔나요?
2. 터미널에서 agy 를 못 찾을 때
3. 안티그래비티 로그인 안됨, 60초 뒤 authentication timed out
4. 로그에 not logged into 가 찍히면 다시 로그인해야 할까?
5. 안티그래비티 모델 선택 안됨, 오류 문구 세 가지
6. 503 서버 오류는 다시 돌리면 지나가나요?
7. 에이전트가 파일을 못 쓸 때와 종료 코드 0
8. 안티그래비티 한국어 답변 받는 법
9. 안티그래비티 CLI 로 안 되는 것과 확인 못 한 것
10. 정리: 누구에게 맞고 누구에게는 굳이인가, 그리고 운영자 의견

1. 안티그래비티 CLI 오류 7가지, 직접 재현하니 무엇이 나왔나요?

필자가 직접 낸 안티그래비티 CLI 오류는 일곱 가지였고 그중 네 가지(모델 선택, 503, 권한 거부, 한국어 답변)는 고친 뒤 다시 돌려서 풀린 것까지 확인했습니다. PATH 와 로그인은 오류와 안내문까지만 봤습니다. 시험은 2026-09-29 17:33~17:41 KST 에 macOS 27.0 arm64 와 ~/.local/bin/agy 에 깔린 agy 1.2.13 으로 했고, 새로 설치한 것과 같은 상태는 빈 HOME(/tmp/agy-fresh/home)을 만들어 재현했습니다.

안티그래비티 CLI 는 터미널에서 agy 한 단어로 부르는 명령인데요, 옵션 없이 띄우면 대화형으로 돌고 -p 를 붙이면 한 번 묻고 답을 받은 뒤 끝나는 헤드리스 모드로 돕니다. 이 글의 오류 대부분은 사람이 옆에서 답해 줄 수 없는 헤드리스 쪽에서 나왔고 데스크톱 IDE 는 설치하지 않아서 다루지 않습니다.

권한 규칙 시험은 settings.json 을 백업한 뒤 규칙 한 줄만 넣고 매번 되돌렸고 에이전트에게 파일을 쓰게 한 시험은 전부 빈 임시 폴더에서 돌렸습니다. 증상은 구글 자동완성에서 안티그래비티 뒤에 붙는 오류, 안됨, 한국어 갈래를 보고 그 갈래에 맞는 것을 골랐는데 결과를 한 표로 먼저 모으면 아래와 같습니다. 이 글의 터미널 이미지는 그날 남긴 재현 로그의 원문 출력을 터미널 모양으로 옮긴 것입니다.

일곱 가지 가운데 스크립트로 안티그래비티를 부르는 분이 가장 먼저 알아야 할 것은 여섯째 줄이었습니다. 빈 폴더에서 파일 하나를 만들라고 시켰더니 아래처럼 거부 문구가 나왔는데 종료 코드는 0 이었고 파일은 생기지 않았습니다(2026-09-29, macOS 27.0 arm64, agy 1.2.13 실측).

$ cd /tmp/agy-try; agy -p "현재 폴더에 hello.txt 파일을 만들고 내용으로 hi 한 줄을 써라. 끝나면 done 이라고만 답해"
jetski: no output produced — a tool required the "write_file" permission that headless mode cannot prompt for, so it was auto-denied. Add an allow-rule under permissions.allow in settings.json (e.g. write_file()). Alternatively, re-run with --dangerously-skip-permissions to auto-approve all tools.
rc=0, hello.txt 없음

직접 확인 1. 종료 코드만 보고 성공을 판정하는 스크립트라면 파일이 하나도 생기지 않은 이 실행을 성공으로 기록하게 됩니다. 실패인데 성공 신호가 나오는 이 경우는 7절에서 고친 방법과 함께 다시 다루고 나머지 여섯 가지는 겪은 순서대로 적어 두겠습니다.

2. 터미널에서 agy 를 못 찾을 때

zsh:1: command not found: agy 가 나오면 agy 가 깔린 ~/.local/bin 이 지금 셸의 PATH 에 없는 것입니다. 필자는 PATH 를 /usr/bin:/bin 만 남긴 새 셸을 env -i HOME=/tmp/agy-fresh/home PATH=/usr/bin:/bin /bin/zsh -f -c 'agy --version' 으로 띄워서 이 오류를 냈고 종료 코드는 127 이었습니다.

같은 조건에서 agy install 을 돌리면 안티그래비티 설치기가 먼저 이 문제를 알려 주는데 경고문 첫 두 줄은 아래와 같았습니다.

Warning: /tmp/agy-fresh/home/.local/bin is not present in your active PATH.

To use the ‘agy’ CLI globally, please manually add it to your shell profile:

경고문이 권하는 대로 셸 설정 파일에 PATH 한 줄을 넣고 새 셸을 열면 됩니다. zsh 를 쓰는 macOS 기준으로는 아래 세 줄이고 마지막 줄은 제대로 잡혔는지 보는 확인용입니다.

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
agy --version

직접 확인 2. 필자가 확인한 것은 오류와 설치기 경고문까지이고 빈 HOME 에 이 줄을 넣은 뒤 다시 돌려 보는 것은 하지 않았습니다. cron 처럼 셸 설정 파일을 읽지 않는 환경에서는 PATH 한 줄이 먹지 않을 수 있으니 그런 곳에서는 ~/.local/bin/agy 를 절대 경로로 부르는 편이 덜 헷갈립니다.

3. 안티그래비티 로그인 안됨, 60초 뒤 authentication timed out

안티그래비티 로그인 안됨 증상은 로그인을 한 번도 하지 않은 환경에서 헤드리스 모드(-p)부터 부를 때 나왔습니다. 빈 HOME 으로 HOME=/tmp/agy-fresh/home agy -p "ok 라고만 답해" --print-timeout 45s < /dev/null 을 돌리자 로그인 주소를 한 번 보여 준 뒤 기다리다가 종료 코드 1 로 끝났습니다.

Authentication required. Please visit the URL to log in:

Waiting for authentication (timeout 60s)...

Or, paste the authorization code here and press Enter:

Error: authentication timed out.

error: authentication failed or timed out

로그인 주소는 accounts.google.com 의 OAuth 주소였고 돌아올 곳은 antigravity.google 의 oauth-callback 이었는데, 주소에 붙은 식별값은 이 글에서 가렸습니다. 브라우저는 자동으로 열리지 않았고 필자가 --print-timeout 45s 를 줬는데도 안내문의 대기 시간은 timeout 60s 로 찍혔습니다.

고친 방법은 순서를 바꾸는 것입니다. 처음 한 번은 옵션 없이 대화형 agy 를 띄워 로그인을 끝내고 그다음부터 -p 를 쓰면 됩니다. 필자의 원래 환경은 이렇게 로그인이 끝나 있어서 같은 -p 명령이 바로 답을 돌려줬습니다.

• SSH 로 붙은 원격 맥 안내문에는 주소를 다른 기기의 브라우저에서 열고 받은 코드를 붙여 넣는 길이 있지만 필자는 새 인증을 만들지 않으려고 끝까지 가지 않았습니다
• 표준 입력을 막은 스크립트 필자 시험처럼 < /dev/null 로 입력을 막아 두면 코드를 붙여 넣을 자리가 없으니 결국 시간 초과로 끝납니다

직접 확인 3. 필자가 확인한 것은 로그인 대기와 시간 초과 문구와 종료 코드 1 까지이고, 코드를 붙여 넣어 안티그래비티 로그인을 마치는 경로가 실제로 끝까지 되는지는 확인하지 못했습니다.

4. 로그에 not logged into 가 찍히면 다시 로그인해야 할까?

아니요, 답변이 정상으로 오고 종료 코드가 0 이라면 다시 로그인할 필요가 없었습니다. 필자 환경에서 agy -p 가 정상 답변을 돌려준 실행 직후에 grep -c "You are not logged into Antigravity" ~/.gemini/antigravity-cli/cli.log 를 돌렸더니 58줄이 나왔고 E 로 시작하는 줄은 32줄이었습니다.

58줄을 문구별로 나누면 아래 세 종류였고 모두 errorreport.go:224] 에서 찍혔습니다.

• 15줄 error getting token source: You are not logged into Antigravity.
• 13줄 failed to get load code assist response: error getting token source: You are not logged into Antigravity.
• 2줄 Failed to poll ListExperiments: error getting token source: You are not logged into Antigravity.

같은 로그에는 .gemini must be an absolute path: path is not absolute, falling back to default 라는 줄도 한 번 있었는데 이것도 답변에는 영향이 없었습니다. cli.log 는 실행할 때마다 log/cli-YYYYMMDD_HHMMSS.log 로 새로 걸리는 링크였고 17:33:46 과 17:40:51 두 정상 실행 모두 같은 58줄이 찍혔습니다.

직접 확인 4. 이 줄이 왜 찍히는지 내부 동작은 확인하지 못했습니다. 다만 정상 실행 두 번에서 매번 같은 수로 나왔으니 로그의 이 줄만 보고 안티그래비티에 다시 로그인하기보다는 답변이 왔는지와 종료 코드로 판단하는 편이 맞다고 봤습니다.

5. 안티그래비티 모델 선택 안됨, 오류 문구 세 가지

안티그래비티 모델 선택 안됨 오류는 문구가 셋으로 갈렸고 셋 다 종료 코드 1 이었습니다. 일부러 없는 이름을 넣은 경우와 effort 를 빼먹은 경우와 그 모델에 없는 effort 를 준 경우입니다. 어느 쪽인지는 문구 끝부분만 읽어도 가려졌습니다.

첫 번째 오류는 문구 뒤에 Available models: 목록을 함께 보여 주고 agy models 로도 같은 목록을 볼 수 있습니다. 필자 환경에서는 14개가 나왔고 gemini-3.8-flash-high 부터 claude-sonnet-4-6, claude-opus-4-6-thinking, gpt-oss-120b-medium 까지 들어 있었는데 이 목록은 환경에 따라 다를 수 있습니다.

effort 를 문구가 알려 준 값으로 바꾸자 바로 답이 왔습니다(2026-09-29, 같은 환경 실측).

$ agy -p "ok 라고만 답해" --model gemini-3.1-pro --effort high
ok   (rc=0)

직접 확인 5. 화면에 보이는 이름을 그대로 넣은 --model "Gemini 3.1 Pro (High)" 도 종료 코드 0 으로 받아졌습니다. 이름을 외우기 어렵다면 agy models 목록의 이름을 복사해 쓰는 편이 오타로 첫 번째 오류를 다시 밟지 않는 길이었습니다.

6. 503 서버 오류는 다시 돌리면 지나가나요?

필자가 겪은 두 번은 모두 20~30초 뒤에 같은 명령을 다시 돌리자 지나갔습니다. 모델에 요청이 간 실행 12번 가운데 2번이 503 으로 끝났고 17:38 경과 17:40 경에 한 번씩 나왔는데 문구는 아래 두 가지였습니다.

error: failed to send message: send failed; already reported to the user: Eligibility check failed: failed to get load code assist response: UNAVAILABLE (code 503): The service is currently unavailable.

error: Eligibility check failed: UNAVAILABLE (code 503): The service is currently unavailable.

문구 그대로 안티그래비티 쪽 서비스가 잠시 응답하지 않은 경우라서 필자 쪽 설정에서 고칠 곳은 없었고 기다렸다가 다시 돌리는 것 말고는 할 수 있는 일이 없었습니다. 스크립트로 부른다면 출력에 code 503 이 있을 때만 짧게 몇 번 다시 시도하고 그래도 안 되면 멈추게 두는 편이 무한 재시도를 피하는 방법입니다.

직접 확인 6. 503 은 종료 코드 1 로 끝나서 스크립트가 실패로 알아챌 수 있었습니다. 문제는 다음 절의 권한 거부인데요, 그쪽은 실패인데도 종료 코드가 0 이라서 같은 방식으로는 잡히지 않았습니다.

7. 에이전트가 파일을 못 쓸 때와 종료 코드 0

헤드리스 모드는 사람에게 권한을 물어볼 수 없어서 파일 쓰기 같은 도구 권한을 자동으로 거부했고 그러면서도 종료 코드는 0 이었습니다. 1절의 거부 문구가 이 경우인데 문구 안에 Add an allow-rule under permissions.allow in settings.json (e.g. write_file()) 라는 해결 방향이 이미 들어 있습니다.

필자는 문구가 알려 준 두 길과 편집 허용 모드까지 차례로 시험했고 같은 요청을 다섯 가지 조건으로 돌린 결과는 아래 표와 같았습니다(2026-09-29 실측).

이 표에서 가장 먼저 볼 곳은 종료 코드 열입니다. 파일을 만든 두 번과 만들지 못한 세 번이 모두 0 으로 똑같이 끝났습니다. 편집 허용 모드인 --mode accept-edits 로도 거부 문구가 그대로 나왔으니 헤드리스에서 파일을 쓰게 하려면 허용 규칙을 넣거나 전부 허용 플래그를 쓰는 두 길만 남았습니다.

허용 규칙은 /tmp 가 아니라 /private/tmp 로

macOS 의 /tmp 는 /private/tmp 로 가는 링크라서 안티그래비티 허용 규칙은 실제 경로로 적어야 걸렸습니다. 필자 맥에서 /tmp 의 실제 경로를 파이썬 os.path.realpath 로 찍어 보면 /private/tmp 가 나왔고 같은 폴더를 가리키는데도 /tmp 로 적은 규칙은 걸리지 않았습니다.

필자 환경에서 settings.json 은 cli.log 와 같은 ~/.gemini/antigravity-cli/ 폴더에 있었습니다. 원래 들어 있던 설정은 그대로 두고 아래처럼 허용 규칙 한 줄만 더하면 됩니다.

{
  "permissions": {
    "allow": ["write_file(/private/tmp/agy-try2)"]
  }
}

작업 폴더의 실제 경로가 헷갈릴 때는 그 폴더에서 pwd -P 를 돌려 나온 값을 규칙에 쓰면 됩니다. 필자가 확인한 링크 경로는 /tmp 하나뿐이라서 홈 폴더 아래 다른 심볼릭 링크에서도 같은 일이 생기는지는 확인하지 못했습니다.

전부 허용 플래그는 빈 폴더에서만

--dangerously-skip-permissions 는 거부 문구가 설명하는 그대로 모든 도구를 자동 승인하는 플래그입니다. 파일 쓰기 하나를 풀려고 이 플래그를 켜면 그 폴더에서 에이전트가 하는 모든 도구 호출이 확인 없이 돌아가기 때문에 필자는 비워 둔 시험 폴더에서만 썼습니다.

에이전트에게 권한을 어디까지 줄지는 DevOps 카테고리의 AI 에이전트 권한 설계 에서 되돌릴 수 있다는 믿음이 권한을 넓히는 함정으로 다룬 적이 있습니다. 허용 규칙 한 줄은 폴더 하나만 열고 전부 허용 플래그는 모든 도구를 여니 같은 문제를 풀어도 여는 범위가 크게 다릅니다.

스크립트는 종료 코드 대신 무엇을 봐야 하나요?

출력 문구와 결과 파일을 함께 봐야 합니다. 이번 시험에서 나온 신호를 스크립트가 판정할 기준으로 옮기면 아래 표처럼 됩니다. 종료 코드가 같은 0 이어도 첫 두 줄처럼 성공과 실패로 갈리니, 안티그래비티 실행 결과는 문구와 파일까지 봐야 제대로 가려집니다.

직접 확인 7. 허용 규칙을 /private/tmp/agy-try2 로 적은 실행과 전부 허용 플래그를 켠 실행은 둘 다 done 을 답하고 hello.txt 에 hi 를 남겼습니다. 테스트는 통과했는데 결과는 틀렸던 경험은 AI 코딩 카테고리의 테스트는 통과했는데 261편 중 6편만 맞았다 에서도 다뤘는데, 성공 신호와 실제 결과를 따로 봐야 한다는 교훈이 여기서도 그대로 통했습니다.

8. 안티그래비티 한국어 답변 받는 법

작업 폴더에 AGENTS.md 를 두고 한국어로 답하라는 규칙 한 줄을 넣으니 영어 질문에도 한국어로 답했습니다. 빈 폴더에서 agy -p "In one sentence, what does git stash do?" 를 물었을 때는 아래처럼 영어로 답이 왔습니다.

git stash temporarily shelves your uncommitted changes (both staged and unstaged) and reverts your working directory to match the HEAD commit,

같은 폴더에서 printf '# 규칙\n\n모든 답변은 한국어로 한다. 명령어와 코드는 원문 그대로 둔다.\n' > AGENTS.md 로 규칙 파일을 만든 뒤 똑같이 물었더니 답이 한국어로 바뀌었습니다.

git stash는 커밋하지 않은 작업 트리의 변경 사항을 임시 보관소에 저장하고, 작업 디렉터리를 최근 커밋(HEAD) 상태로 되돌려 놓는 명령어입니다.

규칙에 명령어와 코드는 원문 그대로 두라고 적어 둔 덕분에 git stash 와 HEAD 는 영어 그대로 남았습니다. agy 바이너리의 안내문에는 규칙 파일 경로가 GEMINI.md, AGENTS.md, .agents/rules/*.md 로 나오는데 필자가 시험한 것은 AGENTS.md 하나뿐입니다.

직접 확인 8. AGENTS.md 를 넣었는데도 안티그래비티가 규칙을 따르지 않는다면 파일 위치와 이름부터 봐야 하는데요, 그런 증상은 AI 코딩 카테고리의 AGENTS.md 안 읽힐 때 해결 방법 총정리 에서 따로 정리해 두었습니다.

9. 안티그래비티 CLI 로 안 되는 것과 확인 못 한 것

이번에 풀지 못했거나 확인하지 못한 것을 그대로 남깁니다. 같은 증상을 찾아 들어온 분이 여기서 헛걸음하지 않도록 무엇을 안 봤는지까지 적어 두는 편이 낫다고 봤습니다.

1. 헤드리스는 권한을 묻지 못합니다. -p 로 부른 에이전트는 사람에게 확인을 받을 수 없어서 허용 규칙에 없는 도구를 자동으로 거부했고 편집 허용 모드도 파일 쓰기를 풀지 못했습니다
2. 거부돼도 종료 코드는 0 입니다. 이번 시험에서 권한 거부는 세 번 모두 0 으로 끝나서 종료 코드만으로는 실패를 알 수 없었습니다
3. 503 은 사용자 쪽에서 막을 수 없었습니다. 필자가 할 수 있었던 일은 기다렸다 다시 돌리는 것뿐이었습니다
4. not logged into 줄의 원인은 모릅니다. 정상 실행에서도 매번 58줄이 찍혔고 왜 찍히는지는 확인하지 못했습니다

아래 네 가지는 이번에 확인하지 못한 항목입니다.

IDE 에서 나는 안티그래비티 오류를 찾으셨다면 이 글은 CLI 만 다루니 Google Antigravity 공식 사이트 의 안내를 먼저 보시는 편이 빠릅니다. 버전이 바뀌면 문구와 동작이 달라질 수 있는데 이 글에 옮긴 원문 문구는 전부 agy 1.2.13 에서 나온 것입니다.

10. 정리: 누구에게 맞고 누구에게는 굳이인가, 그리고 운영자 의견

이 글이 가장 쓸모 있는 쪽은 안티그래비티 CLI 를 SSH 나 스크립트에서 -p 로 부르는 분인데요, 로그인 시간 초과와 권한 거부와 503 이 모두 이 경로에서 나왔고 그중 권한 거부는 종료 코드 0 이라 모르고 지나가기 쉬웠습니다. 증상 문구를 검색해 들어오셨다면 1절 표에서 자기 문구를 찾고 해당 절로 바로 가시면 됩니다.

굳이인 쪽은 IDE 만 쓰시는 분입니다. 필자는 IDE 를 설치하지 않아서 그쪽 오류는 한 줄도 다루지 못했고 대화형 agy 로만 쓰는 분이라면 헤드리스처럼 권한을 자동으로 거부당하지는 않을 테니 7절의 함정은 밟을 일이 드물 것 같습니다. 대화형에서 권한을 묻는 화면은 이번에 따로 확인하지 않았습니다.

안티그래비티 CLI 를 새로 깐 날이라면 필자가 겪은 순서를 거꾸로 밟지 않도록 아래 네 가지를 차례로 보는 편이 시간을 아낍니다.

1. agy --version 이 새 셸에서 도는지 보고 안 되면 PATH 에 ~/.local/bin 을 넣습니다
2. 옵션 없이 대화형 agy 를 띄워 로그인을 한 번 끝낸 뒤에 -p 로 넘어갑니다
3. agy models 로 쓸 모델 이름을 확인하고 pro 계열이면 --effort 값을 함께 줍니다
4. 파일을 쓰게 할 폴더는 pwd -P 로 실제 경로를 확인해 허용 규칙에 적습니다

이번에 일곱 가지를 직접 내 보면서 필자가 가장 크게 느낀 것은 오류 문구가 대부분 해결 방법을 이미 품고 있었던 반면 종료 코드는 그만큼 믿을 수 없었던 일이었습니다. requires --effort (available: low, high) 는 넣을 값을 알려 줬고 권한 거부 문구는 settings.json 의 어느 키에 무엇을 넣을지까지 알려 줬는데, 같은 실행의 종료 코드는 성공을 말하고 있었으니 운영자로서는 문구 쪽을 믿어야 했습니다.

필자의 결론

스크립트에서 안티그래비티 CLI 를 부를 때 필자는 종료 코드 대신 출력 문구와 결과 파일로 성공을 판정하기로 정했습니다. 파일 쓰기 권한은 pwd -P 로 확인한 실제 경로의 허용 규칙 한 줄로만 열고, --dangerously-skip-permissions 는 비워 둔 시험 폴더에서만 씁니다. 503 은 출력에 code 503 이 보일 때만 20~30초 간격으로 몇 번 다시 돌리고 그래도 안 되면 멈추게 둡니다.

The post [AI 코딩] 안티그래비티 오류 7가지, 로그인 안됨과 권한 거부 해결 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

노트북LM 사용법, 무엇을 넣고 무엇을 받으면 될까요? 2026-10-02 새벽 직접 해 보니 논문 주소와 회의록과 강의 영상을 소스로 넣고 물으면 답마다 인용 번호가 붙었습니다. 버튼 한 번에 24분 29초짜리 오디오가 10분 남짓 만에 나왔습니다.

같은 날 notebooklm.google.com 을 열자 notebook.google.com 으로 넘어갔고 창 이름은 Gemini Notebook 이었습니다. 이 글은 그 화면에서 직접 넣은 입력과 나온 결과를 상황별로 따라갑니다.

안녕하세요? 정리하는 개발자 워니즈입니다. 이미 로그인된 구글 계정으로 맥의 Aside 브라우저에서 열었고 이번 시험을 위해 새로 가입한 서비스는 없습니다.

한 줄 요약 노트북LM 사용법은 새 노트북을 만들고 소스를 넣고 묻는 세 단계가 전부였습니다. 소스는 4~6초 만에 들어갔고 답은 18~24초 걸렸으며 시험용 회의록의 할 일 4개는 원문과 모두 맞았습니다. 오디오 오버뷰는 생성 버튼을 누르고 약 10~11분 뒤 24분 29초 길이로 완성돼 있었습니다.

• 논문이나 웹 문서를 읽어야 한다면 주소를 ‘웹사이트’ 출처로 넣고 세 줄 요약부터 받습니다
• 회의 메모를 정리해야 한다면 ‘복사된 텍스트’ 로 넣고 할 일과 담당자와 기한을 표로 달라고 합니다
• 강의 영상을 복습해야 한다면 영상 주소를 넣되 받은 답은 영상과 직접 맞춰 봅니다
• 읽을 시간이 없다면 스튜디오 칸의 AI 오디오 오버뷰를 누르고 10분쯤 다른 일을 합니다

목차

1. 노트북LM 사용법을 직접 해 보니 소스 3개는 몇 초 만에 들어갔을까?
2. 노트북LM 은 돈이 드나요? 직접 쓴 범위와 확인하지 않은 것
3. 제미나이 노트북lm 과 노트북LM 은 같은 화면일까?
4. 논문 읽을 때: arXiv 주소 하나로 세 줄 요약 받기
5. 회의록 정리할 때: 할 일과 담당자와 기한을 표로 받기
6. 강의 영상 복습할 때: 유튜브 주소를 넣고 한 대목만 묻기
7. 노트북LM 사용법의 마지막 단계, 24분 29초 오디오가 나오기까지
8. 노트북LM 으로 안 되는 것과 이번에 확인하지 못한 것
9. 정리: 누구에게 맞고 누구에게는 굳이인가, 그리고 필자는 이렇게 봅니다

1. 노트북LM 사용법을 직접 해 보니 소스 3개는 몇 초 만에 들어갔을까?

소스 하나가 출처 목록에 뜨기까지는 4.1초에서 6.3초가 걸렸고 질문 하나에 답이 다 나오기까지는 18.1초에서 24.1초가 걸렸습니다. 시험은 2026-10-02 금요일 05시 55분쯤 시작했고 06시 13분 13초에 오디오가 완성된 것을 확인한 데서 끝났습니다. 아래 표는 그 사이 노트북LM 사용법을 따라 필자가 누른 순서를 기록 그대로 옮긴 것입니다. 시각 옆의 어림 표시는 초 단위까지 적지 않았다는 뜻입니다.

걸린 시간은 삽입이나 Enter 를 누른 때부터 출처 목록에 이름이 뜨거나 답 글자가 더 늘지 않을 때까지를 잰 값입니다. 제목의 10분은 오디오 생성 버튼을 누른 뒤의 시간입니다. 주소를 처음 연 때부터 따지면 18분 남짓이 걸렸으니 이 차이는 미리 밝혀 둡니다.

이번 노트북LM 사용법 시험에서 막힌 곳은 세 군데였고 셋 다 고장이 아니라 화면을 처음 보는 사람이 헷갈릴 만한 지점이었습니다.

• 생성 중 화면의 안내 문구. 오디오가 만들어지는 동안 다섯 번 확인했는데 매번 ‘생성 중’ 아래에 ‘잠시 후 다시 시도해 주세요.’ 가 같이 보였습니다. 그래도 생성은 멈추지 않고 이어졌고 06:13:13 에 다시 확인했을 때는 완료돼 있었습니다
• 노트북 제목. 세 번째 소스가 들어가자 노트북이 세 소스를 묶은 요약을 만들면서 노트북 제목을 첫 논문 제목인 ‘Attention Is All You Need’ 로 붙였습니다. 회의록과 강의가 논문 이름 아래 묶인 셈인데 제목을 바꾸는 방법은 이번에 시험하지 않았습니다
• 답과 원문 대조. 인용 번호는 그 답이 어느 소스에서 왔는지까지만 알려 줍니다. 원문과 직접 맞춰 본 것은 회의록 하나였고 논문과 영상의 답은 이번에 대조하지 않았습니다

소스를 넣는 시간보다 받은 답을 원문과 맞춰 보는 일이 더 무겁다는 것이 첫 시험에서 가장 크게 남은 배움이었습니다. 회의록은 필자가 직접 쓴 글이라 바로 맞춰 볼 수 있었지만 논문과 1시간짜리 강의는 대조할 분량부터 달라서 이번에는 그 단계까지 가지 않았습니다.

2. 노트북LM 은 돈이 드나요? 직접 쓴 범위와 확인하지 않은 것

이 글이 직접 확인한 노트북LM 사용법의 범위는 이미 로그인된 구글 계정에서 새 가입 없이 아래 왼쪽 칸만큼을 썼다는 사실까지입니다. 요금과 무료 범위와 횟수 숫자는 공식 문서로 확인하지 않았습니다. 그래서 무료 계정에서도 같은 범위가 되는지는 이 글에서 말씀드릴 수 없습니다.

노트북LM 사용법의 첫 화면인 새 노트북을 만들 때 출처 추가 창과 함께 기능 안내 창이 떴습니다. 그 제목은 ‘5시간마다 한도 초기화’, ‘좋아하는 콘텐츠 더 많이 만들기’, ‘새 백그라운드 대기열’ 세 가지였습니다. 이 글에서는 제품 안내 문구로만 옮깁니다. 안내 본문을 기록하지 않아 어떤 기능에 몇 번까지 걸리는 한도인지는 알지 못합니다.

오디오를 만드는 동안 ‘준비되면 알림 받기’ 안내도 보였는데 이것이 안내 창의 백그라운드 대기열과 같은 기능인지도 확인하지 않았습니다. 비용이 걱정되는 분은 이 글의 표보다 직접 열어 본 요금 화면을 기준으로 삼으셔야 합니다. 다른 AI 도구의 무료 범위를 공식 문서 기준으로 정리한 예로는 노션 AI 무료와 유료 차이 비교와 퍼플렉시티 무료 한도와 Pro 차이 5가지 글이 있습니다.

3. 제미나이 노트북lm 과 노트북LM 은 같은 화면일까?

제미나이 노트북lm 사용법으로 찾든 노트북LM 사용법으로 찾든 필자가 2026-10-02 에 본 화면은 하나였고 그 화면의 이름이 Gemini Notebook 이었습니다. 구글 자동완성에도 ‘제미나이 노트북lm 사용법’ 과 ‘제미나이에서 노트북lm 사용법’ 이 함께 떠서 두 이름을 섞어 찾는 분이 많은 것 같습니다.

notebooklm.google.com 을 열면 notebook.google.com 으로 넘어갔고 노트북 창 제목에는 Gemini Notebook 이 보였습니다. 답 아래에는 이런 문구가 붙어 있었습니다.

“Gemini Notebook은 실수를 할 수 있으니 다시 한번 확인하세요.”

이름과 주소가 바뀌는 중으로 보이지만 공식 발표는 이 글에서 확인하지 않았습니다. 제미나이 앱 안의 노트북 기능과 노트북LM 이 어떻게 다른지는 예전에 제미나이 노트북 사용법, 노트북LM 차이 5가지 글에서 따로 정리했으니 이 글에서는 되풀이하지 않습니다.

‘새 노트북’ 을 누르면 주소 끝에 addSource=true 가 붙으면서 출처 추가 창이 바로 열립니다. 이 창에서 고를 수 있는 출처 종류는 여섯 가지였고 이번 노트북LM 사용법 시험에서는 그중 두 가지만 썼습니다.

자동완성에 ‘노트북lm 사용법 pdf’ 가 뜨는 만큼 PDF 를 먼저 넣어 보고 싶은 분이 많겠지만 PDF 를 올리는 노트북LM 사용법은 이번에 시험하지 않았습니다. 논문은 PDF 파일 대신 arXiv 초록 페이지 주소를 웹사이트로 넣었으니 PDF 로 넣었을 때는 결과가 다를 수 있습니다.

오른쪽의 스튜디오 칸에는 AI 오디오 오버뷰, 슬라이드 자료, 동영상 개요, 마인드맵, 보고서(New!), 플래시카드, 퀴즈, 인포그래픽, 데이터 표까지 9개 버튼이 있었습니다. 그 위에는 ‘새로운 기능: 이제 대화형 보고서를 만들 수 있습니다.’ 라는 안내가 붙어 있었습니다. 자동완성의 ‘노트북lm 마인드맵 사용법’ 과 ‘노트북lm 사용법 ppt’ 에 해당하는 마인드맵과 슬라이드 자료는 이번에 누르지 않았으니 그 두 갈래의 노트북LM 사용법은 다음 기록으로 미룹니다.

4. 논문 읽을 때: arXiv 주소 하나로 세 줄 요약 받기

논문을 읽는 노트북LM 사용법은 주소 하나를 웹사이트 출처로 넣고 “한국어 세 줄” 이라고 형식을 정해 묻는 것이었습니다. 18.1초 만에 세 줄짜리 한국어 답이 나왔고 줄마다 소스 1을 가리키는 인용 번호가 붙었습니다. 넣은 주소는 arXiv 의 Attention Is All You Need 초록 페이지 였고 삽입을 누른 지 6.3초 뒤 출처 목록에 논문 제목과 소스 1 표시가 떴습니다.

질문 상자의 자리표시 문구는 ‘질문하거나 창작하세요’ 였고 필자가 친 질문은 ‘이 논문의 핵심 기여를 한국어 세 줄로 요약해 줘’ 한 줄이었습니다. 답은 아래와 같이 나왔습니다.

1) 기존 구조 대체 및 Transformer 제안: 순환(Recurrence)과 합성곱(Convolution) 구조를 전면 배제하고, 오직 어텐션(Attention) 메커니즘만으로 작동하는 네트워크 아키텍처인 트랜스포머(Transformer)를 제안했습니다 [1].

2) 병렬 처리 향상 및 학습 시간 단축: 병렬화가 훨씬 용이하여 기존 최신 모델들에 비해 훨씬 적은 계산 비용과 짧은 시간으로 모델을 학습시킬 수 있습니다 [1].

3) 최고 수준의 성능 및 높은 범용성: WMT 2014 기계 번역 과제에서 최고 성능(SOTA)을 달성했으며, 영어 구문 분석(Constituency parsing) 등 다른 언어 처리 과제에서도 뛰어난 범용성을 보여주었습니다 [1].

답 앞에는 ‘Thoughts’ 라는 접힌 칸이 하나 있었고 답 아래에는 ‘메모에 저장’ 버튼이 붙어 있었습니다. 세 줄을 한국어로 달라는 형식 요청은 그대로 지켜졌으니 논문을 처음 훑어 읽을 곳을 고르는 용도로는 이번 세 상황 가운데 품이 가장 덜 드는 노트북LM 사용법이었습니다.

막힌 곳도 있었습니다. 세 줄 모두 인용 번호가 1 하나라서 소스 1에서 왔다는 것까지는 알 수 있지만 논문의 어느 문단에서 왔는지는 번호를 눌러 보지 않아 이번에 확인하지 않았습니다.

이 답이 논문 본문과 한 줄씩 맞는지 대조하는 일도 이번 기록에는 남기지 않았습니다. 논문에 쓰는 노트북LM 사용법은 세 줄 요약으로 읽을 부분을 고르는 데까지 쓰고 인용할 문장은 논문 원문에서 직접 옮기는 쪽이 안전하다고 봅니다.

5. 회의록 정리할 때: 할 일과 담당자와 기한을 표로 받기

회의록을 정리하는 노트북LM 사용법은 ‘복사된 텍스트’ 로 넣고 할 일을 담당자와 기한으로 정리해 달라고 묻는 것이었습니다. 24.1초 만에 표가 나왔고 원문의 4개 항목이 하나도 빠지거나 지어낸 것 없이 모두 맞았습니다. 실제 회의록에는 사람과 조직의 정보가 들어가므로 이번에는 필자가 시험용으로 직접 쓴 가상의 회의록 253자를 썼고 그 전문은 아래와 같습니다.

[시험용 회의록] 2026-10-02 주간 회의. 참석 3명(기획, 개발, 디자인).
1. 앱 출시일: 원래 10월 20일이었으나 결제 모듈 검수가 늦어 10월 27일로 미룬다. 결정자는 기획.
2. 로그인 오류: 안드로이드 12 이하에서 간헐적으로 로그인 버튼이 눌리지 않는다. 개발이 10월 7일까지 원인을 찾는다.
3. 아이콘: 디자인이 시안 2개를 10월 9일까지 올리고 다음 회의에서 하나를 고른다.
4. 다음 회의는 10월 9일 오후 2시.

출처 추가 창에서 ‘복사된 텍스트’ 를 고르면 ‘붙여넣은 텍스트’ 라는 입력칸이 열립니다. 필자는 붙여 넣기 대신 키보드로 위 글을 입력했고 삽입을 누른 지 4.1초 뒤 출처 목록에 소스 2가 생겼습니다.

질문은 ‘시험용 회의록만 보고 할 일을 담당자와 기한으로 정리해 줘’ 였습니다. 소스가 두 개 들어 있는 노트북이라 질문 앞머리에 어느 소스만 보라고 적었고 답은 아래 표 그대로 나왔으며 칸마다 인용 번호 1이 붙어 있었습니다.

표 아래 기타 항목에는 “앱 출시일 변경: 결제 모듈 검수 지연으로 기존 10월 20일에서 10월 27일로 연기되었습니다 (결정자: 기획)” 와 “다음 회의 일정: 10월 9일 오후 2시” 두 줄이 붙었습니다. 원문과 한 항목씩 맞춰 보니 출시일 변경, 로그인 오류, 아이콘, 다음 회의 네 항목이 모두 맞았고 틀리거나 지어낸 항목은 0개였습니다.

답 아래에는 이어서 물을 질문 세 개가 제안으로 떴습니다. 문구는 ‘일정 체크리스트를 만들어 줘’, ‘요약 보고서 초안을 작성해 줘’, ‘다음 회의 안건을 추천해 줘’ 였고 이번에는 셋 다 누르지 않았습니다.

회의록에 쓰는 노트북LM 사용법은 이번 세 상황 가운데 결과를 끝까지 믿을 수 있었던 유일한 경우였습니다. 원문을 쓴 사람이 그 자리에서 바로 대조할 수 있었기 때문입니다. 다만 실제 회의 자료를 올렸을 때 그 자료가 어떻게 보관되는지는 공식 문서로 확인하지 않았으니 외부에 보이면 안 되는 문서를 넣기 전에는 그 정책부터 보셔야 할 것 같습니다.

6. 강의 영상 복습할 때: 유튜브 주소를 넣고 한 대목만 묻기

강의 영상을 복습하는 노트북LM 사용법은 유튜브 주소를 웹사이트 출처로 넣는 데서 시작했습니다. 4.1초 만에 소스 3이 되었고 한 대목만 콕 집어 묻자 22.1초 만에 세 줄 요약이 나왔습니다. 다만 그 답을 영상 자체와는 대조하지 않았으니 아래 내용은 노트북LM 이 낸 답으로만 읽어 주세요.

넣은 주소는 Intro to Large Language Models 강연 영상 이었고 출처 목록에는 ‘[1hr Talk] Intro to Large Language Models’ 라는 영상 이름이 그대로 떴습니다. 영상 전용 버튼을 따로 찾지 않고 논문과 같은 웹사이트 칸에 주소를 넣었는데도 문제없이 소스로 들어갔습니다.

질문은 ‘강의 영상만 보고, 강연자가 LLM 을 두 개의 파일이라고 설명한 부분을 한국어로 세 줄 요약해 줘’ 였습니다. 1시간짜리 강의를 통째로 요약하게 하지 않고 한 대목을 집어 물은 이유는 답이 짧을수록 나중에 영상의 그 부분만 다시 보며 맞춰 보기 쉽기 때문입니다.

“LLM은 복잡한 시스템 없이 파일 시스템 상에서 단 두 개의 파일만으로 실행 가능합니다”

“파라미터 파일(Parameters File): 신경망의 가중치(Weights)를 저장한 파일로, Llama 2 70B 모델 기준 float16 형식으로 약 140GB 용량을 차지합니다”

“실행 코드 파일(Run File): 외부 라이브러리 의존성 없이 약 500줄의 C 언어 코드 등으로 구현되어 파라미터를 기반으로 신경망을 구동합니다”

답에는 인용 번호 1, 2, 3 이 붙었고 이어 묻기 제안도 세 개가 떴습니다. 번호가 영상의 어느 시점을 가리키는지는 눌러 보지 않았고 자막도 따로 보지 않았습니다. 그래서 140GB 나 500줄 같은 숫자가 강연에서 실제로 나온 숫자인지는 미확인으로 남깁니다.

강의 영상에 쓰는 노트북LM 사용법은 복습할 대목을 찾는 길잡이로는 쓸 만했지만 숫자를 옮겨 적기 전에는 영상을 직접 다시 봐야 합니다. 강의 노트처럼 숫자가 시험에 나오는 자료라면 이 대조 단계를 건너뛰지 않는 편이 맞을 것 같습니다.

7. 노트북LM 사용법의 마지막 단계, 24분 29초 오디오가 나오기까지

오디오까지 받는 노트북LM 사용법은 스튜디오 칸의 ‘AI 오디오 오버뷰’ 를 누르고 기본 형식 그대로 ‘지금 생성’ 을 누르는 것이었습니다. 06:02:01 에 시작한 오디오가 06:13:13 확인 때 24분 29초짜리로 완성돼 있었습니다. 완성 카드에 ‘1분 전’ 이 찍혀 있었으니 실제로 걸린 시간은 10분 12초에서 11분 12초 사이였습니다.

06:01:30 에 버튼을 누르자 ‘AI 오디오 오버뷰 맞춤설정’ 창이 열렸고 기본으로 ‘심층 분석’ 이 선택돼 있었습니다. 그 설명은 아래 한 줄이었습니다.

“두 호스트가 생동감 있게 주고받는 대화 형식으로, 소스의 주제를 분석하고 여러 주제를 연결합니다”

창 안에는 집중할 부분을 적는 입력칸과 ‘나중에 생성’, ‘지금 생성’ 버튼이 있었습니다. 06:02:01 에 ‘지금 생성’ 을 누르자 화면에 ‘AI 오디오 오버뷰 생성 시작 중입니다.’ 와 ‘준비되면 알림 받기’ 안내가 함께 떴습니다.

그 뒤로는 약 2분 간격으로 다섯 번 화면을 확인했고 다섯 번 모두 아직 만드는 중이었습니다. 각 확인 시각과 시작부터 지난 시간은 아래 표와 같습니다.

완성된 오디오의 제목은 ‘다음 단어 예측부터 할머니 자장가 해킹까지’ 였습니다. 맞춤설정 창에서 고른 이름은 심층 분석이었는데 완성 카드에는 딥 다이브라고 적혀 있어서 두 이름이 같은 형식을 가리키는 것으로 보였습니다.

필자는 이 오디오를 아직 듣지 않았습니다. 그래서 오디오가 한국어로 나왔는지, 세 소스를 고르게 다뤘는지, 제목이 가리키는 내용이 무엇인지는 모두 확인하지 않았고 들어 본 뒤에 이 절을 고치겠습니다.

8. 노트북LM 으로 안 되는 것과 이번에 확인하지 못한 것

이번 노트북LM 사용법 시험에서 기대와 다르게 나왔거나 사람이 따로 손을 대야 했던 것부터 번호를 매겨 적습니다. 실패처럼 보였던 장면도 지우지 않고 그대로 남깁니다.

• 직접 확인 1, 생성 중 안내 문구. ‘잠시 후 다시 시도해 주세요.’ 가 보였지만 실패가 아니었고 그대로 기다리자 완료됐습니다(7절)
• 직접 확인 2, 노트북 제목. 주제가 서로 다른 소스 셋을 한 노트북에 넣자 노트북 제목이 첫 논문 이름으로 붙었습니다(1절)
• 직접 확인 3, 인용 번호의 범위. 번호는 어느 소스인지만 알려 주고 맞는지는 사람이 원문과 대조해야 했으며 대조한 회의록은 4개 항목 중 4개가 맞았습니다(5절)
• 직접 확인 4, 화면의 경고 문구. 답 아래에 ‘Gemini Notebook은 실수를 할 수 있으니 다시 한번 확인하세요.’ 가 늘 붙어 있었습니다(3절)

확인하지 못한 노트북LM 사용법 항목은 아래와 같고 이 항목들은 본문에서 단정하지 않았습니다.

• 오디오의 언어와 내용, 세 소스를 고르게 다뤘는지
• 강의 영상 답과 영상 원본의 일치 여부, 논문 답과 논문 본문의 일치 여부
• 인용 번호를 눌렀을 때 원문의 어느 위치가 열리는지
• 요금과 무료 범위, 노트북과 소스와 질문과 오디오의 개수 상한
• 올린 자료의 보관과 학습 사용 정책
• 파일 업로드(PDF 포함), Drive, 도서, 웹 검색 출처
• 스튜디오 칸의 나머지 8개 버튼(슬라이드 자료, 마인드맵 등)
• 노트북LM 에서 Gemini Notebook 으로 이름이 바뀌었다는 공식 발표
• 같은 질문을 다시 보냈을 때 같은 답이 나오는지

질문 하나에 답 하나를 받은 기록이라 같은 질문을 다시 보내면 다른 답이 나올 수 있다는 한계도 함께 적어 둡니다. 맞는 비율을 재려면 같은 질문을 여러 번 돌려야 하는데 이번 노트북LM 사용법 시험에서는 그 반복을 하지 않았습니다.

9. 정리: 누구에게 맞고 누구에게는 굳이인가, 그리고 필자는 이렇게 봅니다

이번에 해 본 노트북LM 사용법은 새 노트북, 소스, 질문 세 단계로 끝났고 답을 원문과 대조할 수 있는 자료일수록 결과를 그대로 쓸 수 있었습니다. 이 노트북LM 사용법이 누구에게 맞는지는 이번 기록에서 실제로 본 것만으로 나눴습니다.

필자의 결론

필자는 노트북LM 을 내가 원문을 가진 자료를 정리하는 도구로 쓰고 논문과 영상의 답은 원문과 대조한 뒤에만 옮기기로 했습니다. 회의록은 4개 항목이 모두 맞았지만 논문과 영상은 대조하지 않았으니 맞았는지 모르는 답을 맞는 답처럼 옮기지 않겠다는 결정입니다. 오디오는 아직 듣지 않았으므로 들어 본 뒤 쓸지 말지를 따로 정하겠습니다.

오늘 해 보실 노트북LM 사용법 하나를 고르신다면 지난 회의 메모 하나를 ‘복사된 텍스트’ 로 넣고 할 일과 담당자와 기한을 표로 달라고 물은 뒤 원문과 한 줄씩 맞춰 보세요.

노트북LM 오디오 오버뷰를 들어 보신 분이라면 한국어로 나왔는지, 소스를 고르게 다뤘는지 댓글로 알려 주세요. 필자도 이번 오디오를 들어 본 뒤 7절에 결과를 덧붙이겠습니다.

덧붙임: 걸린 시간과 숫자를 잰 방법

1. 이 글의 노트북LM 사용법 시험에서 걸린 시간은 소스의 경우 삽입을 누른 때부터 출처 목록에 소스 번호가 뜬 때까지, 질문의 경우 Enter 를 누른 때부터 화면의 답 글자가 더 늘지 않을 때까지를 쟀습니다.
2. 오디오 생성 시간은 06:02:01 부터 06:13:13 까지 11분 12초에서 완성 카드의 ‘1분 전’ 만큼을 빼서 10분 12초~11분 12초로 계산했습니다. 제목과 본문의 10분 남짓은 이 범위를 줄여 쓴 것입니다.
3. 다섯 번의 확인 간격은 1분 48초에서 2분 2초 사이였고 본문의 약 2분 간격은 이 값을 줄여 쓴 것입니다.
4. 표의 어림 시각은 분까지만 눈으로 적은 값이고 회의록과 강의 단계는 시각을 기록하지 않았습니다. 화면에 남은 첫 질문 시각 표시는 오전 5:57 이었습니다.
5. 제미나이로 일상 업무를 짧게 시작하는 방법이 궁금하신 분께는 예전에 읽고 정리한 5분 제미나이 서평 글이 도움이 될 것 같습니다.

참고 출처

• 노트북LM 주소 notebooklm.google.com (2026-10-02 열었을 때 notebook.google.com 으로 넘어감)
• arXiv 1706.03762, Attention Is All You Need (논문 상황의 소스)
• Intro to Large Language Models 강연 영상 (강의 상황의 소스)
• 직접 재현: 2026-10-02 05:55~06:13 KST, 맥의 Aside 브라우저, 이미 로그인된 구글 계정, 새 가입 없음
• 구글 자동완성: 2026-10-02 “노트북LM 사용법” 조회(제미나이 노트북lm 사용법, 마인드맵, pdf, ppt 등 9개)

The post 노트북LM 사용법, 소스 3개로 24분 오디오 받기까지 10분 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

미드저니 사용법을 검색하면 예전 버전 기준 설명이 섞여 나와서 2026년 9월 지금 화면에서 무엇이 달라졌는지 헷갈리셨나요?

바로 답을 드리면 9월 미드저니 알파의 변화는 새로 그리는 쪽보다 이미 만든 이미지를 고치는 쪽에 몰려 있습니다. 라이트박스 에디터와 V8.2 에디트 모델이 9월 2일에 먼저 들어왔고 한국어로 묻는 프롬프트 바와 인핸스는 9월 16일에 붙었습니다. 선택한 영역만 바꾸는 인페인팅은 9월 23일에 개선됐습니다.

안녕하세요? 정리하는 개발자 워니즈입니다. 이번 시간에는 공식 알파 체인지로그 세 건을 날짜별로 대조한 결과와 결제 전에 따져 볼 요금제 기준을 정리해 보려고 합니다.

【한 줄 요약】 미드저니는 2026년 7월 24일에 V8.2를 정식 최신 버전으로 내놓은 뒤 9월 한 달 동안 알파 사이트에서 편집 기능을 집중해서 바꿨습니다. 이 글은 구독 없이 공식 기록만 대조한 글이라 생성 결과의 품질은 확인하지 못했고 그 부분은 무료 도구와 나란히 한 달 써 본 뒤 판단하시길 권합니다.

• 바뀐 것 라이트박스 에디터(9월 2일), 한국어 프롬프트 바와 인핸스(9월 16일), 인페인팅 개선과 Create 피드 개편(9월 23일~24일)이 한 달 안에 알파 사이트에 들어왔습니다
• 돈 구글 자동완성 57개 가운데 19개가 돈과 관련된 검색어였고, 요금 숫자는 공식 문서 원문 대조를 마치지 못해 이 글에 싣지 않았습니다
• 모르는 것 한국어 지시문의 반영 수준, 인핸스와 옛 업스케일의 차이, 정식 사이트 반영 시점은 이번 글에서 확인 불가 또는 미확인으로 남겼습니다

목차

1. 미드저니는 2026년 9월 지금 어떤 도구인가요?
2. 직접 확인 4가지: 확인한 것과 못 한 것
3. 미드저니 9월 알파 업데이트 6가지 날짜별 정리
4. 새 에디터로 이미지를 고치는 순서는 어떻게 되나요?
5. 한국어 프롬프트는 이제 그대로 써도 될까요?
6. 미드저니 무료 체험과 요금제: 결제 전에 답할 질문 5개
7. 나노바나나 및 제미나이와 비교할 때 무엇을 봐야 할까요?
8. 미드저니 알파에서 안 되는 것과 아직 모르는 것
9. 누구에게 맞고 누구에게는 굳이인가 그리고 필자는 이렇게 봅니다

1. 미드저니는 2026년 9월 지금 어떤 도구인가요?

미드저니는 문장으로 적은 지시문을 받아 이미지를 만들어 주는 생성형 AI 서비스입니다. 2026년 9월 30일 기준 정식 최신 버전은 7월 24일(금요일)에 나온 V8.2입니다. V8.2에는 여러 이미지를 한꺼번에 기준으로 삼는 옴니 레퍼런스와 인물의 생김새를 이어서 유지하는 캐릭터 레퍼런스가 실렸습니다. 이번 9월 업데이트의 중심이 된 새 에디트 모델(Edit Model)도 V8.2에 함께 담겼습니다.

V8.2가 나온 날부터 오늘까지는 68일입니다. 그 사이 버전 번호는 그대로 두고 알파 사이트(alpha.midjourney.com)에서 화면과 편집 흐름을 계속 바꾸는 방식으로 업데이트가 이어졌습니다. 그래서 같은 미드저니 사용법이라도 정식 사이트 기준 설명과 알파 사이트 기준 설명이 서로 다른 버튼 이름을 쓰게 됩니다. 검색으로 들어온 분이 옛 글의 버튼을 찾다가 헤매는 일이 생기는 것 같습니다.

알파 사이트는 새 기능을 먼저 시험해 보는 곳입니다. 거기서 바뀐 기능이 정식 사이트에 언제 똑같이 들어오는지는 공식 체인지로그에 날짜가 적혀 있지 않았습니다. 이 글이 정리하는 6가지는 전부 알파 사이트 기준입니다. 정식 사이트 반영 시점은 미확인으로 남겨 둡니다.

버전 번호가 V8.2에 멈춰 있는데도 사용 흐름이 크게 달라졌다는 점은 이 글을 읽는 방식에도 영향을 줍니다. 어떤 사용법 글이 V8.2를 다룬다고 적혀 있더라도 9월 이전에 쓰였다면 라이트박스 에디터와 인핸스가 빠져 있을 가능성이 높습니다. 사용법 글을 고를 때는 버전 번호보다 작성 날짜가 9월 2일 이후인지를 먼저 보시는 편이 헛걸음을 줄여 줍니다.

2. 직접 확인 4가지: 확인한 것과 못 한 것

이 글을 쓰기 전에 무엇을 직접 봤고 무엇을 못 봤는지부터 밝혀 두는 편이 읽는 분의 시간을 아끼는 길이라고 생각했습니다. 결론만 먼저 적으면 검색 수요와 공식 기록은 확인했고 실제 생성 결과와 현재 요금 숫자는 확인하지 못했습니다.

직접 확인 1: 구글 자동완성으로 본 미드저니 검색어 57개

2026년 9월 25일에 구글 자동완성에서 미드저니 뒤에 오류, 안됨, 비교, 단점, 요금제, 무료, 한국어 같은 말을 붙여 나오는 검색어를 모았습니다. 기본 자동완성과 합쳐 겹치는 것을 빼니 57개가 남았습니다. 9월 30일에 그 목록을 다시 묶음별로 세어 본 출력은 아래와 같습니다(macOS 27.0, Python 3.14.7).

전체 검색어 57
요금 결제 구독 환불 19
오류와 안됨 18
무료 10 비교 10 한국어 3

한 검색어가 두 묶음에 걸리는 경우가 있어서 묶음별 숫자를 더하면 57을 넘습니다. 그래도 57개 중 19개가 돈과 관련된 말이라는 점은 분명하게 보입니다. 사용법을 묻는 사람보다 결제를 앞두고 망설이는 사람이 자동완성에 더 많은 흔적을 남기고 있는 셈입니다. 그래서 이 글의 6장을 요금제 판단에 따로 떼어 두었습니다.

같은 확인을 직접 해 보고 싶으시면 구글 검색창에 미드저니 뒤에 한 칸을 띄우고 요금제, 무료, 안됨 같은 말을 차례로 넣어 아래로 펼쳐지는 목록을 적어 두시면 됩니다. 자동완성은 지역과 시점에 따라 달라지니 날짜를 함께 적어 두셔야 나중에 비교할 수 있습니다. 오류와 안됨 묶음에 디스코드 연결 안됨이 아직 남아 있는 것을 보면 웹 화면으로 넘어온 지금도 디스코드로 쓰던 사용자가 적지 않은 것 같습니다.

직접 확인 2: 공식 알파 체인지로그 3건의 날짜 대조

공식 업데이트 페이지에 올라온 알파 기록 세 건을 날짜 순서로 놓고 요일과 간격을 계산해 보니 9월 2일, 16일, 23일이 모두 수요일이었고 간격은 14일과 7일이었습니다. 수요일 전후로 기록이 올라오는 흐름이 보이므로 새 기능을 챙겨 보려는 분이라면 수요일과 목요일에 체인지로그를 한 번씩 열어 보는 습관이 쓸모 있을 것 같습니다.

직접 확인 3: 요금과 무료 체험은 공식 문서 대조 미완

이번 글에서는 공식 플랜 비교 문서의 원문을 요금 숫자 단위까지 대조하는 일을 마치지 못했습니다. 그래서 월 구독료나 플랜별 생성 한도 같은 숫자는 싣지 않았습니다. 6장에서는 숫자 대신 결제 전에 스스로 답해 볼 질문과 그 답을 공식 문서 어디에서 찾는지만 정리했습니다. 숫자가 필요하신 분은 결제 직전에 공식 도움말을 함께 열어 두고 읽으시길 권합니다.

직접 확인 4: 이미지 생성 결과는 확인 불가

구독 계정 없이 쓴 글이라 새 에디터로 실제 이미지를 고쳐 본 결과와 한국어 지시문의 반영 정도, 인핸스 전후 화질은 전부 확인 불가입니다. 화면 캡처처럼 보이는 그림을 그려 넣는 것도 사실과 다른 인상을 줄 수 있습니다. 그래서 이 글의 그림은 공개된 공식 페이지 캡처와 도식으로만 채웠습니다.

3. 미드저니 9월 알파 업데이트 6가지 날짜별 정리

9월에 알파 사이트에서 바뀐 것을 한 표로 모으면 아래와 같습니다. 여섯 가지 중 다섯 가지가 이미지를 고치거나 고른 결과를 다루는 기능이라는 점이 먼저 눈에 들어옵니다.

같은 9월 23일 무렵에는 빠른 모델을 실험하고 있다는 안내와 스타일 사이드바에서 프롬프트를 미리 볼 수 있게 했다는 내용도 함께 올라왔습니다. 빠른 모델은 공식 기록 스스로 실험 중이라고 적었기 때문에 6가지에 넣지 않고 따로 떼어 두었습니다.

1번과 5번이 한 묶음인 이유

1번의 라이트박스 에디터가 문장으로 이미지 전체를 고치는 통로라면 5번의 인페인팅 개선은 고칠 범위를 픽셀 단위로 좁히는 도구입니다. 둘은 같은 편집 흐름의 앞과 뒤에 놓입니다. 공식 기록이 굳이 선택한 픽셀만 바뀐다고 적어 둔 것을 보면 일부만 고치려다 주변까지 함께 달라지는 상황을 줄이는 데 이번 수정의 초점이 있었던 것으로 읽힙니다.

2번과 3번이 초보자에게 먼저 닿는 이유

프롬프트 바가 먼저 무엇을 바꾸고 싶은지 묻는 방식은 빈 입력창 앞에서 무엇을 써야 할지 모르는 초보자에게 첫 문장을 대신 열어 주는 장치입니다. 거기에 3번의 그리드와 미리보기가 붙으면서 원본과 고친 결과를 나란히 놓고 고르는 일이 한 화면 안에서 끝나게 됐습니다.

4번과 6번이 반복 작업을 줄이는 이유

인핸스는 마음에 드는 결과를 골라 마무리하는 마지막 단계의 이름이 바뀐 것입니다. 6번의 프롬프트 기본값 저장은 매번 같은 비율이나 스타일을 다시 적던 수고를 설정 한 번으로 줄이는 기능입니다. 같은 크기의 대표 이미지를 여러 장 만들어야 하는 분이라면 이 두 가지가 한 장당 손이 가는 횟수를 가장 직접적으로 줄여 주는 변화일 것 같습니다.

4. 새 에디터로 이미지를 고치는 순서는 어떻게 되나요?

공식 체인지로그가 설명한 기능을 순서대로 이으면 이미지를 연다, 바꿀 내용을 문장으로 적는다, 필요하면 참조 이미지를 붙인다, 좁은 영역은 인페인팅으로 고친다, 결과를 그리드에서 고른다, 인핸스로 마무리한다의 여섯 단계가 됩니다. 다만 이 순서는 공식 설명을 이어 붙여 재구성한 것이고 버튼의 정확한 이름과 위치는 계정이 없어 확인하지 못했다는 점을 먼저 밝혀 둡니다.

1. 라이트박스에서 열기 9월 2일에 들어온 새 에디터는 라이트박스 안에 들어 있습니다. 따로 편집 화면으로 옮겨 가지 않고 크게 띄운 이미지에서 바로 편집을 시작하는 구조입니다.
2. 평범한 문장으로 지시하기 에디트 모델은 일반 지시문으로 편집하도록 만들어졌다고 적혀 있습니다. 파라미터를 외우기보다 배경을 저녁 노을로 바꿔 달라는 식의 문장을 먼저 써 보는 쪽이 맞을 것 같습니다.
3. 참조 이미지 붙이기 색감이나 소품을 다른 이미지에서 가져오고 싶을 때 쓰는 자리입니다. 한도가 최대 4개라서 기준으로 삼을 이미지를 미리 골라 두는 편이 낫습니다.
4. 인페인팅으로 영역 고르기 9월 23일 개선 이후로는 선택한 픽셀만 바뀐다고 적혀 있습니다. 캔버스 바깥으로 그림을 넓히는 아웃페인팅도 같은 묶음으로 손봤다고 합니다.
5. 드래프트 그리드에서 고르기 소스 이미지가 그리드로 함께 보이고 마우스를 올리면 미리보기가 뜹니다. 원본과 나란히 견주어 고르는 흐름이 됩니다.
6. 인핸스로 마무리하기 예전 업스케일 버튼이 있던 자리를 인핸스가 대신했습니다. 그러니 옛 사용법 글에서 업스케일을 찾다가 헤매지 않으시길 바랍니다.

자동완성에 미드저니 옴니 레퍼런스 안됨이 따로 올라와 있는 것을 보면 참조 기능이 기대만큼 먹지 않아 막히는 분이 적지 않은 것 같습니다. 그 원인이 참조 이미지의 개수 때문인지 지시문과 참조가 서로 부딪히기 때문인지는 이번에 재현하지 못해 미확인으로 남깁니다.

5. 한국어 프롬프트는 이제 그대로 써도 될까요?

입력 자체는 한국어로 해도 되는 방향으로 가고 있습니다. 9월 16일 알파 체인지로그가 한국어 지원을 따로 강조했고 이미지를 첨부하면 프롬프트 바가 무엇을 바꾸고 싶은지 먼저 물어보는 기능도 같은 날 들어왔습니다. 다만 한국어로 쓴 지시문이 영어로 쓴 지시문과 같은 수준으로 결과에 반영되는지는 생성해 보지 못해 확인 불가입니다.

자동완성에도 미드저니 한국어 설정, 미드저니 한국어 프롬프트, 미드저니 한국어 지원 세 가지가 올라와 있습니다. 화면 언어를 바꾸고 싶은 사람과 지시문을 한국어로 쓰고 싶은 사람이 섞여 있다는 뜻으로 읽힙니다. 화면 언어를 한국어로 바꾸는 설정이 따로 있는지는 공식 기록에서 찾지 못했습니다.

한국어 지시문을 처음 써 보신다면 결과를 감으로 판단하지 마세요. 아래 세 단계로 영어 지시문과 나란히 놓고 스스로 비교해 보시길 권합니다.

1. 같은 장면을 한국어 문장 하나, 영어 문장 하나로 각각 적어 둡니다. 같은 설정에서 한 번씩 생성한 뒤 두 결과를 드래프트 그리드에 나란히 띄웁니다.
2. 인물의 수, 배경의 시간대, 색감처럼 눈으로 판정하기 쉬운 항목 세 가지를 미리 정해 둡니다. 두 결과가 각 항목을 지켰는지 맞음과 틀림으로만 적어 봅니다.
3. 이미지 안에 한글 글자를 넣는 일은 따로 시험하는 편이 낫습니다. 다른 이미지 도구에서도 한글 글자는 자주 틀어졌습니다. 그 문제를 다룬 제미나이 이미지 생성 방법, 한글 글자와 워터마크 글의 방식처럼 배경만 만들고 글자는 따로 얹는 쪽이 안전할 수 있습니다.

6. 미드저니 무료 체험과 요금제: 결제 전에 답할 질문 5개

먼저 무료 체험부터 적으면 2023년 3월에 미드저니가 무료 체험을 멈췄다는 보도가 여러 매체에 났었습니다. 그 뒤로 다시 열렸는지와 지금 어떤 조건인지는 이번에 공식 문서로 확인하지 못했습니다. 자동완성에 무료체험, 무료 횟수, 무료로 쓰는법이 줄줄이 붙는 것을 보면 이 질문에 확답을 원하는 분이 많습니다. 확답은 가입 화면과 공식 도움말에서 직접 보시는 것이 가장 정확합니다.

요금 숫자는 개편과 환율에 따라 달라지는 데다 이번에 원문 대조를 마치지 못해 싣지 않았습니다. 다만 어떤 플랜이 맞는지 판단하는 데 필요한 질문은 숫자와 상관없이 그대로 쓸 수 있습니다. 그래서 아래 다섯 가지를 결제 전에 스스로 답해 보시길 권합니다.

첫 번째 질문은 숫자로 답해 보면 판단이 쉬워집니다. 예를 들어 주 3편의 글마다 대표 이미지 후보를 4장씩 뽑는다면 한 달(4.3주 기준)에 약 52장이 필요합니다. 그 가운데 절반을 인페인팅으로 한 번씩 더 고친다면 26번의 편집이 더해져 모두 78번쯤의 작업이 됩니다. 이렇게 내 작업량을 먼저 숫자로 적어 두고 공식 플랜 문서의 한도와 맞춰 보면 광고 문구보다 내 사용 패턴이 결정을 이끌게 됩니다.

자동완성의 돈 관련 19개 가운데 결제 안됨, 결제 오류, 환불 안됨이 함께 보이는 점도 짚어 둘 만합니다. 결제가 막히거나 환불이 어렵다는 검색이 반복된다는 것은 결제 전에 환불 조건부터 읽어 두는 편이 낫다는 신호로 보입니다. 연간 결제 선택지가 있더라도 처음 한 달은 월 단위로 시작해 실제 사용량을 재 본 뒤 바꾸는 쪽이 손해를 줄이는 방법일 것 같습니다.

미드저니 프로모션 코드라는 검색어도 기본 자동완성에 올라와 있지만 공식 할인 코드가 실제로 있는지는 확인하지 못했습니다. 그러니 공식 사이트가 아닌 곳에서 코드를 받아 결제 정보를 넣는 일은 피하시길 권합니다.

무료와 유료의 경계를 따지는 방식은 앞서 정리한 노션 AI 무료와 유료 차이 비교와 퍼플렉시티 무료 한도와 Pro 차이 5가지에서도 같았습니다. 한도 숫자보다 내 사용 패턴이 그 한도에 실제로 닿는지를 먼저 보는 쪽이 결정을 빠르게 해 줍니다.

7. 나노바나나 및 제미나이와 비교할 때 무엇을 봐야 할까요?

비교는 결과물의 인상보다 무료로 시작할 수 있는지와 편집을 어떤 방식으로 하는지, 참조 이미지를 몇 장까지 섞는지부터 보는 쪽이 판단을 덜 흔들리게 합니다. 자동완성의 비교 검색어 10개를 보면 나노바나나와 제미나이를 포함한 이미지 도구 이름이 넷, veo3와 클링을 포함해 영상 생성 쪽에서 자주 거론되는 이름이 셋이었고 나머지는 요금제 비교와 단점 검색이었습니다.

같은 지시문으로 여러 모델을 나란히 돌려 본 비교는 이번에 하지 않았습니다. 그래서 아래 표는 품질 우열이 아니라 비교할 때 볼 기준과 미드저니 쪽에서 이번 공식 기록으로 확인된 사실만 적은 것입니다.

구글 쪽 이미지 모델은 앞서 쓴 제미나이 이미지 생성의 참조 한도와 워터마크 정리에서 공식 문서 기준으로 다뤘습니다. OpenAI 쪽은 GPT Image 2.5 요금과 화질 5단계 글에서 요금과 화질 단계를 정리했습니다. 두 글과 이 글의 표를 나란히 놓으면 참조 이미지 한도와 무료 시작 여부에서 도구마다 조건이 갈린다는 점이 먼저 보일 것 같습니다.

영상 쪽 이름이 비교 검색어에 셋이나 섞여 있다는 것은 이미지 한 장보다 짧은 영상까지 한 도구로 끝내고 싶어 하는 수요가 있다는 뜻으로 읽힙니다. 미드저니의 영상 기능과 영상 요금제는 이번에 확인하지 않았으니 그 목적이라면 영상 전용 도구와 따로 견주어 보셔야 합니다.

8. 미드저니 알파에서 안 되는 것과 아직 모르는 것

알파 기능은 바뀌거나 빠질 수 있다는 전제로 읽으셔야 합니다. 이번 기록에서 안 되는 것과 공식 기록으로 답이 나오지 않은 것을 모으면 아래 여덟 가지입니다.

1. 정식 사이트 반영 시점 9월의 여섯 가지 변화는 알파 사이트 기준입니다. 정식 사이트에 언제 같은 모습으로 들어오는지는 체인지로그에 적혀 있지 않아 알 수 없습니다.
2. 알파 사이트 접근 조건 알파 사이트를 누가 쓸 수 있는지와 그 조건이 플랜이나 사용 이력과 묶여 있는지는 이번에 확인하지 못해 미확인입니다.
3. 빠른 모델 공식 기록이 스스로 실험 중이라고 적은 기능입니다. 속도나 품질을 기대하고 플랜을 고르는 근거로 쓰기에는 아직 이릅니다.
4. 참조 이미지 한도 에디터에서 붙일 수 있는 참조 이미지는 4개가 한도입니다. 그보다 많은 이미지를 기준으로 삼고 싶다면 미리 골라 줄여야 합니다.
5. 인핸스와 옛 업스케일의 차이 버튼 자리가 바뀌었다는 사실만 확인했습니다. 해상도나 화질이 어떻게 달라졌는지는 생성해 보지 못해 미확인입니다.
6. 한국어 지시문의 반영 수준 한국어 지원을 강조했다는 것과 실제 결과가 영어와 같은 수준이라는 것은 서로 다른 이야기라서 확인 불가로 둡니다.
7. 현재 요금 숫자와 무료 체험 여부 이번에 원문 대조를 마치지 못했으니 결제 직전에 공식 플랜 문서에서 직접 보셔야 합니다.
8. 옴니 레퍼런스가 안 먹는 원인 자동완성에 따로 올라올 만큼 막히는 분이 있습니다. 다만 원인을 재현하지 못해 미확인으로 남깁니다.

이 목록에서 알 수 있는 것은 이번 업데이트가 기능의 방향은 분명하게 보여 주지만 결과물이 그 방향대로 나오는지는 아직 각자 확인해야 하는 단계라는 점입니다. 9월 미드저니 알파는 무엇을 하려는지는 분명한데 얼마나 잘 되는지는 공식 기록만으로 알 수 없습니다.

9. 누구에게 맞고 누구에게는 굳이인가 그리고 필자는 이렇게 봅니다

지금까지의 사실을 독자 유형별로 나누면 아래와 같습니다. 기준은 편집을 얼마나 자주 하는지와 한 달에 필요한 이미지 수입니다.

참고한 공식 페이지

1. 미드저니 공식 업데이트 페이지
2. 9월 16일 알파 체인지로그
3. 9월 23일 알파 체인지로그
4. 에디트 업데이트와 썸네일 미리보기 안내
5. 미드저니 공식 도움말

필자의 결론

필자는 9월 미드저니 알파가 새 그림을 더 잘 그리는 쪽보다 이미 만든 그림을 원하는 대로 고치는 쪽으로 무게를 옮겼다고 봅니다. 라이트박스 에디터, 한국어로 묻는 프롬프트 바, 선택 픽셀만 바꾸는 인페인팅, 업스케일을 대신한 인핸스가 모두 한 달 안에 편집 흐름 위에 차례로 얹혔다는 것이 그 근거입니다.

그래서 필자는 아직 결제하지 않았습니다. 먼저 공식 플랜 문서의 요금 숫자와 무료 체험 조건을 원문으로 대조한 뒤 가장 낮은 단계를 월 단위로 한 달만 써 보기로 정했습니다. 그 한 달 동안 한국어 지시문과 영어 지시문의 차이, 인페인팅이 실제로 선택한 픽셀만 바꾸는지를 직접 재서 후속 글로 남기려고 합니다. 그때까지는 이 글의 확인 불가 항목을 그대로 두겠습니다.

The post [AI Now] 미드저니 사용법과 9월 알파 업데이트 6가지 정리 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

미국에서 화제라는 메타 뮤즈를 받아 보려고 한국 앱스토어를 뒤졌는데 비슷한 이름의 앱만 보여서 어디서 받는지 막막하셨나요?

바로 답을 드리면 2026년 9월 29일 기준 메타 뮤즈는 미국과 캐나다 앱스토어에만 올라와 있고 한국 스토어 검색에는 나오지 않으며, 메타가 밝힌 한국 출시 일정도 아직 없습니다.

안녕하세요? 정리하는 개발자 워니즈입니다. 이번 시간에는 스토어를 국가별로 직접 조회한 결과와 지금 대신 써 볼 대안, 한국에 나오면 먼저 볼 것을 정리해 보려고 합니다.

【한 줄 요약】 메타 뮤즈는 2026년 9월 8일 미국, 9월 18일 캐나다 앱스토어에 올라온 메타의 AI 에이전트 앱인데요, 한국 스토어에는 없어서 지금은 기다리는 편이 맞고 지역을 바꿔 설치하는 방법은 약관 문제 때문에 권하지 않습니다.

• 지금 한국 앱스토어에서 찾으면 이 앱 대신 Meta AI 앱이 맨 위에 나오는데, 그 앱에서 뮤즈 스파크 모델을 쓸 수 있는지는 공식 출처로 확인하지 못했습니다
• 대안 메일과 캘린더를 AI에 맡겨 보는 경험이 목적이라면 이미 한국 스토어에 있는 AI 앱이나 데스크톱 에이전트로 먼저 감을 잡아 볼 수 있습니다
• 출시되면 연결 권한의 범위, 컴퓨터 조작 전 승인 단계, 데이터 학습 여부를 한국어 개인정보 처리방침에서 먼저 보시길 권합니다

목차

1. 메타 뮤즈는 무엇이고 언제 나왔나요?
2. 메타 뮤즈 한국에서 지금 받을 수 있나요?
3. 직접 확인 3가지와 다시 해 보는 방법
4. 메타 뮤즈 스파크와 한국 스토어의 Meta AI 앱은 같은 것일까요?
5. 커넥트에서 예고된 기능과 아직 모르는 것
6. 한국에서 지금 써 볼 수 있는 대안 3가지
7. 지역을 바꿔 설치하는 방법은 왜 권하지 않나요?
8. 메타 뮤즈로 지금 안 되는 것과 확인 불가 목록
9. 한국에 나오면 먼저 볼 5가지, 계정을 연결해 본 경험에서
10. 누구에게 맞고 누구는 기다려도 될까요?

1. 메타 뮤즈는 무엇이고 언제 나왔나요?

메타 뮤즈는 페이스북과 인스타그램을 운영하는 메타(Meta Platforms)가 내놓은 AI 에이전트 앱이고, 미국 앱스토어에는 “Muse from Meta”라는 이름으로 2026년 9월 8일(화요일)에 올라왔습니다. 필자 쪽에서 2026년 9월 29일 오전 5시 10분(KST)에 애플의 iTunes Search API로 미국 스토어를 조회했을 때 개발사 Meta Platforms, Inc. 와 앱 번호 id6760173601 옆에 출시일 값 2026-09-08이 찍혀 있었습니다.

이 앱을 움직이는 모델의 이름은 뮤즈 스파크(Muse Spark)인데요, TechCrunch는 이 모델을 에이전트 작업용으로 만든 메타의 멀티모달 모델이라고 소개했습니다. 구글 자동완성에 스파크가 따로 붙어 나오는 것도 앱 이름과 모델 이름이 섞여 쓰이기 때문인 것 같아서 이 글에서는 앱을 메타 뮤즈로, 모델을 뮤즈 스파크로 나눠 부르겠습니다.

필자가 이 주제를 고른 것은 검색 흐름 때문이었는데요, 2026년 9월 29일 오전 5시에 받아 둔 구글 트렌드 기술 분야 지난 7일 목록에 메타 뮤즈가 들어 있었고 그 줄은 아래와 같았습니다.

{“name”: “메타 뮤즈”, “volume”: “2천+”, “started”: “6일 전”, “related”: []}

6일 전이면 9월 23일(수요일)인데 CNN과 TechCrunch가 메타 커넥트(Meta Connect)에서 뮤즈의 새 기능이 발표됐다고 전한 날과 겹칩니다. 한국 검색량이 미국 출시일이 아니라 커넥트 발표 뒤에 붙었다는 뜻으로 읽히고, 자동완성에 한국, 다운로드, 사용법, 설치 같은 말이 나란히 붙는 것을 보면 한국 독자가 가장 먼저 묻는 것은 결국 “여기서 받을 수 있느냐”인 것 같습니다.

미국에서 캐나다까지는 10일이 걸렸고 미국 출시일부터 이 글을 쓰는 날까지는 21일이 지났는데요, 이 속도가 다음 나라에도 이어질지는 알 수 없어서 한국 출시 시점을 점치는 근거로는 쓰지 않았습니다.

2. 메타 뮤즈 한국에서 지금 받을 수 있나요?

정상 경로로는 받을 수 없습니다. 2026년 9월 29일 기준 한국 앱스토어 검색에 메타 뮤즈가 나오지 않고, 필자가 찾은 범위에서는 메타가 한국 출시 일정을 공식으로 밝힌 문서도 없었습니다.

같은 조회를 미국과 캐나다로 돌리면 Muse from Meta가 같은 앱 번호로 나오는데 한국으로 돌리면 결과가 달라집니다. 한국 스토어에서 같은 검색어로 나온 상위 5개는 Meta AI, ChatGPT, Claude, Grok, Google Gemini였고 그 가운데 Muse from Meta는 없었습니다.

왜 한국이 빠졌는지는 메타의 공식 설명을 찾지 못했습니다. 서울경제 영문판의 2026년 9월 26일 기사는 이 앱이 미국과 캐나다에서만 나왔고 한국 일정은 정해지지 않았으며 나라마다 개인정보 관련 법을 먼저 통과해야 해서 한국 이용자가 쓰기까지 시간이 걸릴 수 있다고 전했는데요, 이 부분은 기사의 분석이고 메타의 공식 설명은 아니라서 이유로 단정하지는 않겠습니다.

안드로이드 쪽도 사정이 같았는데요, 구글 플레이를 한국 설정으로 검색했을 때도 이 앱은 결과에 나오지 않았고 조회 방법은 3절의 직접 확인 2에 적어 두었습니다.

3. 직접 확인 3가지와 다시 해 보는 방법

필자가 확인한 것과 확인하지 못한 것을 번호로 나눠 적었고, 결과가 바뀌는 대로 누구나 같은 방법으로 다시 볼 수 있게 명령과 조건을 함께 남겼습니다.

직접 확인 1. 앱스토어 국가별 검색. 2026년 9월 29일 오전 5시 10분(KST) macOS에서 애플의 iTunes Search API로 검색어 meta muse, 종류 software를 미국(us), 캐나다(ca), 한국(kr) 세 나라로 나눠 조회했습니다. 아래는 독자가 터미널에서 그대로 붙여 한국 스토어를 다시 조회해 볼 수 있는 명령이고 country=kr을 us나 ca로 바꾸면 나라별로 비교할 수 있습니다.

curl -s "https://itunes.apple.com/search?term=meta+muse&entity=software&country=kr&limit=5" \
  | python3 -c "import sys,json; [print(r['trackName'], r['trackId']) for r in json.load(sys.stdin)['results']]"

필자 쪽 조회에서 돌아온 값을 나라별로 옮기면 아래와 같은데요, 출력 전문 대신 판단에 쓰는 칸만 추렸습니다.

이 조회는 API 결과이고 아이폰의 앱스토어 앱 화면에서 직접 찾아본 것은 아닙니다. 두 결과가 늘 같은 순서로 나온다는 보장을 문서에서 찾지 못해서, 아이폰에서 직접 찾아보실 때는 앱 이름이 Muse from Meta 인지와 개발사 표기가 Meta Platforms 인지를 함께 보시는 편이 확실합니다.

직접 확인 2. 구글 플레이 국가별 검색. 같은 날 오전 5시 30분쯤 구글 플레이 웹 검색에 검색어 muse from meta를 넣고 국가 설정(gl)만 US와 KR로 바꿔 결과에 나온 앱 주소를 모았습니다. 미국 설정 결과에는 제목이 Muse from Meta인 앱(패키지명 com.facebook.aura)이 있었고, 한국 설정 결과에는 그 패키지가 한 번도 나오지 않았습니다. 아래 명령의 gl=KR을 US로 바꿔 두 숫자를 비교해 보시면 됩니다.

curl -s -A "Mozilla/5.0" "https://play.google.com/store/search?q=muse%20from%20meta&c=apps&gl=KR" \
  | grep -c 'details?id=com.facebook.aura'

한 가지 주의할 점은 앱 상세 페이지 주소를 직접 열면 한국 설정에서도 페이지 자체는 열린다는 것인데요, 웹 페이지가 열리는 것과 내 휴대폰에 설치 버튼이 켜지는 것은 다른 단계라서 이 결과를 설치 가능으로 읽으시면 안 됩니다.

직접 확인 3. 한국에서 웹으로 열리는지, 확인 불가. 서울경제 영문판은 미국과 캐나다에서 앱과 함께 웹 페이지로도 쓸 수 있다고 전했는데요, 그 웹 주소가 어디인지는 1차 출처로 확정하지 못했습니다. 주소를 확정하지 못한 채 비슷한 페이지가 열린다고 적으면 오히려 틀린 정보를 드릴 수 있어서 이 항목도 확인 불가로 남기는데요, 메타가 커넥트 발표를 모아 둔 Meta Connect 2026 공식 블로그 글이 웹 제공 여부를 확인할 때 가장 먼저 볼 곳입니다.

세 가지 가운데 확실하게 말할 수 있는 것은 직접 확인 1과 2입니다. 한국 앱스토어와 구글 플레이 검색에는 없고 웹은 모른다는 것이 2026년 9월 29일 아침 기준의 정확한 상태입니다.

4. 메타 뮤즈 스파크와 한국 스토어의 Meta AI 앱은 같은 것일까요?

같은 것이라고 볼 근거를 공식 출처에서 찾지 못했고, 확인된 것은 둘이 앱스토어에서 서로 다른 앱으로 등록돼 있다는 사실뿐입니다. Muse from Meta의 앱 번호는 id6760173601이고 한국 검색 1위로 나온 Meta AI의 앱 번호는 id1558240027 이라서 적어도 스토어에서는 별개의 앱입니다.

한국 독자에게 가장 헷갈리는 지점이 여기인 것 같습니다. 메타 뮤즈를 찾다가 Meta AI 앱이 맨 위에 보이면 이름이 바뀐 같은 앱이겠거니 하고 받게 되는데, 뮤즈 스파크 모델이 Meta AI 앱이나 인스타그램, 왓츠앱 안의 메타 AI 기능에 들어가 한국에서도 쓰이는지는 필자가 공식 문서로 확인하지 못했습니다.

그래서 “한국에서 된다”는 말을 세 단계로 나눠 보는 편이 덜 헷갈리는데요, 스토어에 보이는 것과 설치해서 로그인되는 것과 원하는 기능이 실제로 켜지는 것은 서로 다른 단계이고 앞 단계를 통과했다고 뒤 단계가 따라오지는 않습니다.

Meta AI 앱을 받아 보는 것 자체는 막을 이유가 없지만 뮤즈를 기대하고 받는다면 앱 설명에 적힌 모델 이름과 제공 국가 문구를 먼저 읽어 보시길 권합니다. 설치하고 로그인까지 해 본 다음에 실망하는 것보다 그 한 단락을 읽는 쪽이 훨씬 싸게 먹힙니다.

5. 커넥트에서 예고된 기능과 아직 모르는 것

TechCrunch의 커넥트 신기능 정리 기사에 따르면 메타 뮤즈의 다음 기능은 맥 앱에서 컴퓨터 작업을 대신하는 기능(수개월 안), 에이전트 전용 메일 주소(곧), 메일 스레드 정리와 전달, 실시간 영상 대화 아바타, 메타 AI 안경 연동입니다. 메타는 이 새 기능을 먼저 써 보는 얼리 액세스 신청도 받는데요, TechCrunch의 얼리 액세스 기사를 보면 신청 방법이 따로 있는 게 아니라 뮤즈에게 얼리 액세스 명단에 넣어 달라고 직접 말하는 방식이라, 결국 앱을 쓸 수 있는 나라에서만 신청할 수 있는 셈입니다. 기능 범위는 기사 기준이고 메타 공식 문서로 대조한 것은 아닙니다.

에이전트라는 말은 대화로 답만 하는 비서가 아니라 사용자를 대신해 앱을 열고 버튼을 누르고 일정을 잡는 쪽을 가리키는데요, 메일과 캘린더를 연결하고 맥 화면까지 조작한다면 뮤즈는 사용자의 가장 민감한 계정 두 개와 컴퓨터 한 대를 손에 쥐게 됩니다. 기능이 편해지는 만큼 내가 무엇을 허락했는지 기억해 둬야 할 범위도 같이 넓어집니다.

숫자로는 서울경제 영문판이 출시 13일 만에 누적 다운로드 250만을 넘겼고 매주 1억 토큰을 무료로 준다고 전했는데요, 사실상 무료로 시작했다는 뜻이라 한국에 나오더라도 처음부터 요금 걱정을 할 단계는 아닐 것 같습니다. TechCrunch도 2026년 9월 25일 메타가 뮤즈에 힘을 싣는다는 기사에서 이 흐름을 다뤘습니다.

표의 아래 세 줄이 한국 사용자가 실제로 판단할 때 필요한 칸인데 지금은 비어 있습니다. 메타 뮤즈가 한국에 나오는 시점에 이 세 칸이 공식 문서로 채워지는지가 필자가 가장 먼저 볼 부분이고 9절에서 다시 다룹니다.

6. 한국에서 지금 써 볼 수 있는 대안 3가지

메타 뮤즈 자체를 대신할 앱은 없지만 무엇을 해 보고 싶은지에 따라 지금 한국에서 비슷한 경험을 할 길은 세 가지 정도로 나뉘고, 대안마다 뮤즈와 닮은 점과 먼저 확인할 점이 다르니 목적에 맞는 줄만 골라 보시면 됩니다.

대안 1. 한국 스토어의 Meta AI 앱. 메타 계열 AI를 먼저 만나 보고 싶다면 가장 가까운 선택지이고, 직접 확인 1에서 한국 검색 1위로 나온 앱입니다. 다만 4절에서 본 것처럼 뮤즈 스파크가 이 앱에 들어 있는지와 한국에서 어떤 기능이 켜지는지는 확인하지 못했으니 앱 설명의 모델 이름과 제공 국가 문구를 먼저 읽고 받으시길 권합니다.

대안 2. 이미 한국 스토어에 있는 다른 AI 앱. 메일과 캘린더를 AI에게 맡겨 보는 경험이 목적이라면 같은 검색 결과에 함께 나온 ChatGPT, Claude, Google Gemini 같은 앱의 계정 연결 기능부터 보시는 편이 빠릅니다. 어떤 서비스가 어떤 계정 연결을 한국 계정에 열어 두었는지는 자주 바뀌고 필자가 이번에 공식 문서로 다시 확인하지 못했으니 각 앱의 설정 화면과 도움말에서 연결 가능한 계정 목록을 직접 확인하시길 권합니다. 제미나이가 처음이라면 예전에 쓴 5분 제미나이 서평이 출발점으로 괜찮습니다.

대안 3. 데스크톱에서 도는 에이전트 도구. 맥 화면을 AI가 직접 다루는 경험이 궁금하다면 앱스토어 밖에서 설치하는 데스크톱 에이전트 도구가 있습니다. 필자는 이 맥에서 Anthropic의 클로드 코드(Claude Code)로 개인 블로그 운영 작업을 맡기고 있는데요, 터미널에서 도는 도구라 일반 사용자에게 권할 만큼 쉽지는 않지만 에이전트에게 계정과 화면을 맡기면 무엇이 생기는지 겪어 보기에는 충분했습니다. 그 과정에서 늘어난 일이 산출물보다 검증이었다는 이야기는 AI 에이전트로 혼자 일하기, 늘어난 건 산출물이 아니라 검증이었습니다에 적어 두었습니다.

세 대안 모두 뮤즈의 대체품이라기보다 메타 뮤즈가 한국에 나왔을 때 무엇을 따져 봐야 하는지 미리 감을 잡는 연습에 가깝고, 특히 대안 3은 필자가 실제로 겪은 일이 많아서 9절의 점검 목록이 대부분 여기서 나왔습니다.

7. 지역을 바꿔 설치하는 방법은 왜 권하지 않나요?

앱스토어 계정의 국가를 바꾸거나 해외 계정을 쓰는 방식은 서비스 약관을 어길 소지가 있어서 권하지 않고, 이 글에서는 그 절차도 다루지 않습니다. 설치가 된다고 해도 그것은 메타가 한국 이용자에게 제공하기로 정한 상태가 아니라는 것이 가장 큰 이유입니다.

약관 말고도 필자가 보기에 걸리는 것이 세 가지 더 있습니다.

1. 개인정보 기준이 한국 이용자를 전제로 하지 않습니다. 한국 출시가 늦는 배경으로 개인정보 관련 법 검토가 거론되는데, 그 검토가 끝나기 전의 서비스에 메일과 캘린더처럼 가장 민감한 계정을 연결하는 것은 앞뒤가 맞지 않는다고 봅니다.
2. 문제가 생겼을 때 기댈 곳이 애매해집니다. 계정이 막히거나 연결한 데이터를 지우고 싶을 때 한국 이용자로서 요청할 창구가 있는지 확인되지 않은 상태입니다.
3. 계정 제재 여부를 알 수 없습니다. 지역을 바꿔 쓴 계정이 실제로 제재를 받는지는 필자가 확인하지 못했는데요, 모른다는 것 자체가 메일을 맡기기에는 큰 불확실성입니다.

그래서 필자는 지역을 바꿔 설치해 보는 대신 한국 스토어에 올라오는 날을 기다리기로 했고, 그 전까지는 6절의 대안으로 감을 잡아 두는 쪽을 권합니다.

8. 메타 뮤즈로 지금 안 되는 것과 확인 불가 목록

2026년 9월 29일 기준으로 메타 뮤즈를 한국에서 쓰려 할 때 막히는 것과 필자가 확인하지 못한 것을 따로 모았는데요, 되는 기능보다 이 목록을 먼저 보시면 같은 검색을 여러 번 되풀이하는 일을 줄일 수 있습니다.

1. 한국 앱스토어 설치 안 됨 직접 확인 1에서 한국 검색 결과에 Muse from Meta가 없었습니다.
2. 한국 출시 일정 없음 메타의 공식 발표를 찾지 못했고 한국 일정이 미정이라는 보도만 있습니다.
3. 한국 구글 플레이 검색 안 됨 직접 확인 2에서 한국 설정 검색 결과에 com.facebook.aura가 없었습니다.
4. 한국에서 웹 접속 확인 불가 공식 웹 주소를 1차 출처로 확정하지 못했습니다.
5. 다른 메타 앱에서 뮤즈 스파크 사용 확인 불가 Meta AI 앱, 인스타그램, 왓츠앱 가운데 어디에 들어가는지 공식 문서로 확인하지 못했습니다.
6. 한국 요금 확인 불가 미국 기준 주 1억 토큰 무료라는 보도는 있지만 한국에서 같은 조건일지는 알 수 없습니다.
7. 데이터 학습과 보존 정책 미확인 메일과 캘린더 연결 데이터가 어떻게 쓰이고 얼마나 남는지 공식 문서를 찾지 못했습니다.

가장 흔히 부딪힐 조합은 1번과 5번이 겹칠 때입니다. 뮤즈 앱이 안 보여서 대신 Meta AI 앱을 받았는데 기대한 에이전트 기능이 없는 경우인데요, 설치 전에 앱 설명의 모델 이름을 확인하는 한 단계로 이 실망을 피할 수 있습니다.

9. 한국에 나오면 먼저 볼 5가지, 계정을 연결해 본 경험에서

메타 뮤즈가 한국 스토어에 올라오면 필자는 기능 소개보다 연결 권한과 승인 단계부터 볼 생각인데요, 이 순서는 에이전트에게 계정을 맡겼다가 실제로 막혔던 경험에서 나왔습니다. 필자는 이 맥에서 클로드 코드로 개인 블로그 운영을 자동으로 돌리면서 에이전트에게 블로그 관리자 화면과 브라우저 로그인 세션, 메신저 알림을 연결해 두고 씁니다.

겪은 일. 2026년 9월 25일에 에이전트가 브라우저의 블로그 편집기에 원고를 붙여 넣는 동안 같은 맥에서 돌던 다른 자동화가 시스템 클립보드를 두 번 덮어썼습니다. 한 번은 다른 작업의 음성 원고가 들어왔고 또 한 번은 전혀 상관없는 링크가 들어와서 본문이 통째로 잘못 붙었고 소제목 하나가 사라졌는데, 어느 쪽이 덮어썼는지는 지금도 확정하지 못했습니다.

막힌 곳. 에이전트가 화면을 조작할 때 쓰는 클립보드와 브라우저 세션은 그 에이전트만의 것이 아니라 그 컴퓨터 전체가 함께 쓰는 자원이었습니다. 같은 날 에이전트가 쓰는 브라우저를 새 버전으로 올리며 재시작한 뒤에 확인해 보니 로그인 쿠키가 사라져 있었고, 사람이 없는 시간대에는 다시 로그인할 수단이 없어서 그 경로가 멈췄습니다.

고친 방법. 그래서 작업 방식을 세 군데 바꿨습니다.

1. 클립보드에 넣은 내용은 다른 작업을 끼우지 않고 곧바로 붙여 넣고, 붙인 뒤에는 길이가 아니라 첫 문장을 원고와 대조합니다.
2. 소제목처럼 짧은 문자열은 클립보드를 거치지 않고 키보드 입력으로 넣습니다.
3. 로그인 세션이 걸린 브라우저는 에이전트가 스스로 재시작하지 않고 사람에게 먼저 묻고, 한 번 받은 승인도 목적이 바뀌면 다시 묻습니다.

숫자로 본 결과. 그날 클립보드 오염은 2회, 사라진 소제목은 1개였고 짧은 문자열을 키보드 입력으로 바꾼 뒤 그날 남은 발행은 마쳤는데요, 이후 재발 건수는 따로 집계하지 않아서 이 글에서는 말하지 않겠습니다.

메타 뮤즈가 맥 컴퓨터를 조작한다면 같은 문제가 그대로 생길 수 있다고 봅니다. 사용자가 복사해 둔 내용과 에이전트가 붙여 넣는 내용이 같은 클립보드를 쓰고, 에이전트가 브라우저를 다시 열면 로그인이 풀릴 수 있기 때문인데요, 이런 경험에서 뽑은 점검 5가지가 아래 표입니다.

1번과 2번은 에이전트 권한을 설계하면서 따로 정리한 적이 있는데요, 권한을 넓게 줄수록 되돌리는 비용이 커진다는 이야기는 AI 에이전트 권한 설계 글에 있습니다. 메일 연결에는 메일 본문에 숨겨 둔 문장이 에이전트에게 지시처럼 읽히는 프롬프트 인젝션 위험이 하나 더 붙는데, 코딩 에이전트 쪽에서 이것을 막는 방법은 Claude Code 프롬프트 인젝션 막는 4가지에 모아 두었습니다.

10. 누구에게 맞고 누구는 기다려도 될까요?

지금까지 본 상태를 독자 상황별로 옮기면 아래와 같은데요, 자기 상황에 가까운 줄 하나만 보셔도 메타 뮤즈를 기다릴지 다른 길로 갈지 정하실 수 있습니다.

반대로 메타 뮤즈 소식을 보고 당장 무언가를 설치해야 할 것 같은 조급함이 드신다면 굳이 서두를 필요는 없다고 봅니다. 한국에서 아직 받을 수 없다는 건 거꾸로 보면 연결 권한과 데이터 정책을 한국어 문서로 읽고 판단할 시간이 조금 더 생겼다는 이야기이기도 합니다.

운영자 의견

에이전트에게 계정을 연결해 본 사람으로서 필자가 메타 뮤즈 발표에서 제일 먼저 눈에 걸린 대목은 모델 성능보다 메일과 캘린더와 컴퓨터 사용이 한 앱에 한꺼번에 묶였다는 점이었습니다. 필자 경험에서는 에이전트가 똑똑해서 생긴 문제보다 에이전트가 사람과 같은 클립보드와 같은 로그인 세션을 쓰면서 생긴 문제가 훨씬 많았고, 그런 문제는 규칙을 길게 적어 두기보다 붙여 넣은 직후 첫 문장을 원고와 대조하는 한 단계를 끼웠을 때 더 잘 막혔습니다.

그래서 이 앱이 한국에 나오더라도 필자는 모든 계정을 한 번에 연결하지 않고 업무와 상관없는 계정 하나로 시작해서 9절의 점검 5가지를 하나씩 확인한 뒤에 범위를 넓힐 생각입니다. 편한 기능일수록 처음 허락하는 범위를 좁게 잡아야 나중에 되돌리기 쉽다는 것, 필자가 이 맥에서 몇 번 손해를 보고 나서야 몸에 붙은 습관입니다.

필자의 결론

필자는 지금 한국에서 메타 뮤즈를 받을 정상 경로는 없고, 지역을 바꿔 설치할 이유보다 기다릴 이유가 더 크다고 봅니다. 메일과 캘린더와 컴퓨터를 한꺼번에 맡기는 앱을 한국어 개인정보 처리방침도 없는 상태로 연결하는 것은 필자 기준에서 편의보다 위험이 큰 선택입니다.

그래서 필자는 메타 뮤즈를 지역 우회로 설치하지 않기로 했고, 한국 앱스토어 검색에 이 앱이 뜨는 날 직접 확인 1의 명령을 다시 돌려 출시를 확인한 다음 처리방침과 연결 권한 화면부터 읽을 생각입니다. 그때 이 글의 확인 불가 항목들도 다시 확인해서 채워 넣겠습니다.

참고한 출처

본문의 날짜와 앱 정보는 2026년 9월 29일 오전 필자 쪽 조회 결과이고 기능, 수치, 한국 일정은 아래 기사 원문을 대조해 옮겼습니다.

• 애플 개발자 문서 iTunes Search API
• 메타 공식 블로그 Meta Connect 2026 발표 정리
• TechCrunch 뮤즈 커넥트 신기능 정리(2026년 9월 23일)
• CNN Muse AI 에이전트 기사(2026년 9월 23일)
• TechCrunch 뮤즈 새 기능 얼리 액세스(2026년 9월 25일)
• TechCrunch 메타가 뮤즈에 힘을 싣는다(2026년 9월 25일)
• 서울경제 영문판 뮤즈 미국 출시 기사(2026년 9월 26일)

The post [AI Now] 메타 뮤즈 한국 다운로드와 대안 3가지 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

제미나이로 블로그 썸네일이나 안내 포스터를 만들어 보려는데 한글 제목이 엉뚱한 글자로 나오거나 이미지 구석에 로고 같은 표시가 찍혀 나와서 어디부터 손봐야 할지 막막하셨나요?

바로 답을 드리면 제미나이 이미지 생성은 gemini.google.com 에서 이미지 메뉴를 열고 장면을 문장으로 설명하면 되고, 글자는 짧게 따옴표로 지정하거나 아예 이미지 밖에서 얹는 편이 덜 고치며, 한국에서는 보이는 워터마크를 끄는 설정이 AI Ultra 구독에만 열려 있고 눈에 보이지 않는 SynthID 워터마크는 누구도 끌 수 없습니다.

안녕하세요? 정리하는 개발자 워니즈입니다. 이번 시간에는 제미나이 이미지 생성 방법을 앱에서 처음 만드는 순서부터 정리하고 프롬프트 쓰는 법과 한글 글자의 한계, 비율과 해상도, 워터마크와 SynthID까지 2026년 9월 28일에 다시 읽은 구글 공식 문서를 기준으로 모아보려고 합니다.

한 줄 요약 제미나이 이미지 생성은 나노 바나나라는 이름의 제미나이 자체 이미지 모델이 맡고 있는데요, 장면은 제미나이에 맡기고 긴 글자와 정확한 크기는 사람이 마무리하는 분업이 공식 문서의 권고와도 맞고 필자가 블로그 대표 이미지를 만들며 가장 덜 고친 방식이기도 했습니다.

• 시작 제미나이 웹 앱 사이드바에서 이미지를 누르고 장면과 스타일과 구도를 문장으로 적으면 기본 모델인 Nano Banana 2가 그려줍니다
• 글자 한국어는 공식 권장 언어에 들어 있지만 긴 문장과 작은 글씨는 여전히 틀어질 수 있어서 짧은 문구만 따옴표로 넣고 나머지는 이미지 밖에서 얹는 편이 안전합니다
• 워터마크 보이는 로고 워터마크는 한국 기준 AI Ultra 구독에서만 끌 수 있고 SynthID는 모든 결과물에 남으며 제미나이 앱에 올려 확인할 수 있습니다

목차

1. 제미나이 이미지 생성은 어떤 모델로 돌아가나요?
2. 제미나이 이미지 생성 방법, 앱에서 처음 만드는 순서
3. 프롬프트는 어떻게 써야 원하는 그림이 나올까요?
4. 이미지 속 한글 글자는 왜 틀어지고 어떻게 넣어야 할까요?
5. 배경만 만들고 글자는 따로 얹는 방식을 권하는 이유
6. 비율과 해상도는 어디까지 고를 수 있나요?
7. 워터마크와 SynthID는 지울 수 있나요?
8. 제미나이 이미지 생성에서 안 되는 것과 막히는 조합
9. 제미나이 이미지 생성을 쓰다 보면 생기는 질문
10. 누구에게 맞고 누구에게는 굳이인가, 그리고 필자의 결론

1. 제미나이 이미지 생성은 어떤 모델로 돌아가나요?

제미나이 이미지 생성은 구글이 나노 바나나(Nano Banana)라고 부르는 제미나이 자체 이미지 모델이 맡습니다. 구글의 Gemini API 이미지 생성 문서는 나노 바나나를 제미나이의 네이티브 이미지 생성 기능의 이름이라고 소개합니다. 필자가 2026년 9월 28일에 읽은 판에는 모델이 네 가지로 나뉘어 있었습니다.

직접 확인 1. 모델 구성이 자주 바뀌는 분야라서 필자가 읽은 판이 언제 것인지부터 남겨 두려고 2026년 9월 28일 macOS 터미널에서 문서 페이지를 받아 갱신일 줄만 뽑았습니다. 위쪽이 명령이고 아래쪽이 실제로 돌아온 출력입니다.

curl -sL --compressed https://ai.google.dev/gemini-api/docs/image-generation | grep -o 'Last updated [^<"]*' | head -1
Last updated 2026-09-23 UTC.

예전에 구글 이미지 모델로 알려졌던 Imagen은 같은 문서에서 Gemini API 기준으로 종료됐다고 적혀 있습니다. 그래서 지금 제미나이 이미지 생성을 이야기하면 사실상 위 네 모델 가운데 하나를 쓰는 것이라고 보시면 됩니다.

제미나이 앱에서는 모델을 직접 고르기보다 대화 모델 설정에 따라 이미지 모델이 따라옵니다. Gemini 앱 이미지 생성 도움말을 보면 대화 모델이 Flash나 Pro이면 Nano Banana 2가, Flash-Lite이면 Nano Banana 2 Lite가 쓰이고 유료 구독자는 만든 이미지를 Nano Banana Pro로 다시 생성할 수 있다고 적혀 있습니다.

개발자가 API로 부를 때는 모델 코드를 직접 지정하고 앱에서는 대화 모델 설정이 이미지 모델을 정합니다. 같은 프롬프트라도 어디서 부르느냐에 따라 다른 모델이 그릴 수 있다는 점을 먼저 기억해 두시면 결과가 달라진 이유를 찾기 쉽습니다.

2. 제미나이 이미지 생성 방법, 앱에서 처음 만드는 순서

제미나이 이미지 생성 방법은 도움말 기준으로 로그인, 이미지 메뉴 열기, 프롬프트 입력의 세 단계면 시작할 수 있습니다. 아래 순서는 도움말에 적힌 컴퓨터 기준 절차를 옮긴 것이고 버튼 이름은 도움말 표기를 그대로 따랐습니다.

1. 들어가기 컴퓨터에서 gemini.google.com 에 로그인합니다. 이미지를 만들려면 로그인이 필요하고 도움말은 만 13세 이상(국가별 적정 연령)부터 생성, 만 18세 이상부터 편집이 된다고 적고 있습니다.
2. 이미지 메뉴 열기 왼쪽 위에서 사이드바를 열고 이미지를 누릅니다.
3. 요청하기 템플릿을 고르거나 프롬프트를 입력합니다. 도움말 예시는 "서핑보드를 타는 개 이미지를 만들어 줘"처럼 한국어 문장입니다.
4. 고치기 사이드바의 라이브러리에서 고칠 이미지를 누르고 이미지 아래 채팅을 누른 뒤 바꿀 내용을 적습니다. 가지고 있는 사진을 올려서 고쳐 달라고 해도 됩니다.
5. 내려받기 이미지 위에 마우스를 올리고 원본 크기 다운로드를 누릅니다. 더보기에서 Docs로 내보내기도 고를 수 있습니다.

내려받는 해상도는 계정마다 다릅니다. 도움말에 따르면 Google AI 요금제에 가입하면 2K, 가입하지 않으면 1K로 내려받습니다. 인쇄물처럼 큰 이미지가 필요하다면 이 차이를 먼저 확인하시는 편이 좋습니다.

직접 확인 2. 이번 회차에는 로그인된 제미나이 앱 화면을 필자가 직접 눌러 보지 못해서 위 메뉴 위치는 확인 불가로 남깁니다. 제미나이 이미지 생성 메뉴의 이름과 위치는 도움말 문구 기준이고 앱이 갱신되면서 바뀌었을 수 있으니 메뉴가 안 보이면 도움말 페이지를 한 번 더 확인해 보시길 권합니다.

3. 프롬프트는 어떻게 써야 원하는 그림이 나올까요?

키워드를 쉼표로 나열하지 말고 장면을 한 편의 묘사 문장으로 쓰는 것이 제미나이 이미지 생성 프롬프트의 기본입니다. 앱 도움말은 '만들어 줘' 같은 말로 시작하고 원하는 스타일을 밝히고 대상과 행동과 배경을 자세히 설명하라는 세 가지를 권하고 있습니다.

API 문서의 모범 사례는 조금 더 구체적인데요, 필자가 실제로 프롬프트를 쓸 때 도움이 됐던 순서로 여섯 가지를 옮기면 아래와 같습니다.

1. 아주 구체적으로 쓰기 '판타지 갑옷' 대신 무늬와 소재와 모양까지 적으라고 합니다.
2. 목적을 밝히기 '로고를 만들어 줘'보다 '고급스럽고 미니멀한 스킨케어 브랜드 로고'처럼 어디에 쓸지를 적으면 결과가 나아진다고 합니다.
3. 대화로 다듬기 한 번에 완벽한 그림을 기대하지 말고 '조명만 조금 더 따뜻하게'처럼 작은 수정을 이어가라고 합니다.
4. 단계로 나누기 요소가 많은 장면은 배경부터 앞쪽 물체까지 차례로 지시합니다.
5. 빼고 싶은 것도 긍정문으로 쓰기 '차 없음' 대신 '인적 없는 텅 빈 거리'처럼 원하는 상태를 묘사합니다.
6. 카메라 언어 쓰기 광각, 접사, 로우 앵글 같은 촬영 용어로 구도를 잡습니다.

필자는 블로그 대표 이미지 배경을 만들 때 이 조언을 여섯 칸짜리 틀로 묶어서 씁니다. 칸을 다 채우면 문장이 길어지지만 제미나이 이미지 생성 결과가 매번 같은 구도로 굳는 일이 줄어들었습니다.

이 틀을 한 문장으로 이으면 이런 모양이 됩니다.

저녁 무렵 작은 홈 오피스의 창가 책상 위에 노트북 한 대가 놓여 있고 방금 누가 자리를 뜬 듯 의자가 돌아가 있는 장면을 그려 줘. 눈높이 미디엄 샷으로 노트북은 화면 오른쪽 3분의 1에 두고 왼쪽은 넓게 비워 둬. 왼쪽 창에서 따뜻한 노을빛이 들어오고 전체는 필름 사진 느낌의 실사풍이야. 화면과 종이와 벽은 모두 빈 면과 단순한 도형만 보이게 해 줘.

마지막 문장이 5번 조언을 적용한 부분인데요, 제미나이 이미지 생성에 '글자를 넣지 마'라고만 쓰면 모니터 화면이나 책 표지에 글자가 그려져 나오는 일이 필자에게도 있었습니다. 원하는 상태를 긍정문으로 묘사하는 쪽이 공식 권고이기도 하고 필자 경험에서도 덜 새는 방식이었습니다.

4. 이미지 속 한글 글자는 왜 틀어지고 어떻게 넣어야 할까요?

한국어 글자 자체는 공식 지원 범위에 들어 있지만 길고 작은 글자일수록 틀어질 여지가 남아 있어서 넣을 문구를 짧게 줄이고 정확히 지정하는 것이 대처의 출발점입니다. API 문서의 제약 항목은 최적 성능 언어 목록에 ko-KR을 넣고 있고 앱 도움말도 Nano Banana 2가 지원되는 모든 언어에서 더 정확한 맞춤법으로 글자를 넣는다고 설명하고 있습니다.

그런데 같은 구글 도움말이 AI 생성물을 알아보는 방법을 설명하면서 첫 번째 단서로 이런 문장을 들고 있습니다.

이미지 또는 동영상 내 텍스트가 일관되지 않거나 깨져 있습니다.

글자가 틀어지는 현상이 구글 스스로도 AI 이미지의 흔한 흔적으로 꼽을 만큼 남아 있다는 뜻으로 읽힙니다. 필자가 예전에 제미나이 이미지 생성으로 받은 그림에서도 모니터 속 코드가 detect_failue, autoReccover 처럼 철자가 한두 글자씩 틀어져 나와서 그대로 쓸 수 없었습니다. 이 경험은 그 시점의 모델에서 본 것이고 지금 모델에서 같은 빈도로 나오는지는 다시 재 보지 못했습니다.

제미나이 이미지 생성에 글자를 꼭 넣어야 한다면 공식 문서의 조언과 필자 경험을 합쳐 아래 순서를 권합니다.

1. 문구는 짧게, 따옴표 안에 정확히 제목 한 줄 정도로 줄이고 넣을 글자를 따옴표로 감싸 그대로 적습니다. API 문서도 글자와 글꼴 스타일과 전체 디자인을 분명히 밝히라고 합니다.
2. 글꼴은 이름 대신 모양으로 '굵은 세리프체', '손글씨 느낌의 둥근 글씨'처럼 묘사합니다. 문서 표현도 글꼴 스타일을 묘사적으로 적으라는 것입니다.
3. 문구를 먼저 만들고 이미지는 나중에 문서 제약 항목에 아래 문장이 있습니다.

When generating text for an image, Gemini works best if you first generate the text and then ask for an image with the text.

1. 틀린 글자만 대화로 고치기 전체를 다시 뽑지 말고 '다른 부분은 그대로 두고 아래쪽 문구만 이 글자로 바꿔 줘'처럼 고칩니다. 대화형 수정이 문서가 권하는 반복 방식입니다.
2. 글자가 중요한 작업은 Pro로 구글 코리아 블로그의 나노 바나나 프로 소개 글(2025년 11월 20일)은 Pro를 이미지 속 글자를 가장 정확하고 읽기 쉽게 구현하는 모델로 소개했고 API 문서도 전문적인 글자 작업에는 Pro를 쓰라고 적고 있습니다.

그래도 긴 설명문, 작은 글씨가 빽빽한 표, 숫자가 많은 차트는 제미나이 이미지 생성에 맡기지 않는 편이 낫습니다. 한 글자라도 틀리면 다시 뽑아야 하고 다시 뽑으면 다른 글자가 틀어질 수 있어서 고치는 시간이 처음부터 따로 얹는 시간보다 길어지기 쉽습니다.

5. 배경만 만들고 글자는 따로 얹는 방식을 권하는 이유

제미나이 이미지 생성에는 장면과 분위기만 맡기고 글자는 이미지 편집 도구로 나중에 얹으면 오탈자 걱정이 사라지고 제목을 바꿀 때 그림을 다시 뽑지 않아도 됩니다. API 문서의 프롬프트 가이드에도 여백을 살린 미니멀 디자인 항목이 따로 있고 용도는 이렇게 적혀 있습니다.

Excellent for creating backgrounds for websites, presentations, or marketing materials where text will be overlaid.

공식 가이드가 글자를 얹을 배경을 한 항목으로 따로 두고 있으니 이 분업은 편법이 아니라 권장되는 쓰임새입니다. 필자가 제미나이 이미지 생성으로 블로그 대표 이미지를 만드는 방식도 이 구조입니다. 모델에는 제목이 들어갈 쪽을 비워 둔 글자 없는 배경만 요청하고 한글 제목은 이미지 편집 코드로 얹으면서 글자 뒤에 어두운 반투명 띠를 깔고 외곽선을 넣습니다. 실사풍 배경 위에 흰 글자를 그냥 얹으면 밝은 부분에서 글자가 묻히기 때문입니다.

이 방식을 규칙으로 굳히게 된 계기는 2026년 9월 27일에 있었습니다. 배경을 AI 도구에 맡겼는데 돌아온 그림 한쪽에 제미나이가 아닌 다른 이미지 서비스의 워터마크 표기가 찍혀 있었고, 그 장을 버리고 다시 만드는 대신 실패하면 임시로 쓰라고 남겨 두었던 단색 배경으로 조용히 바뀌어 초안에 들어가 버렸습니다. 필자가 보기에 대표 이미지가 한참 전 방식으로 되돌아간 것이었고 비슷한 되돌림을 그 전에도 한 번 겪은 터였습니다.

막힌 곳은 규칙이 문서 안의 조건 분기로만 살아 있었다는 점이었습니다. '웬만하면 이 방식, 실패하면 저 방식'이라고 적어 두니 실패하는 날마다 저 방식이 다시 나왔습니다. 그래서 두 가지를 바꿨습니다.

1. 대체 경로를 지웠습니다. 깨끗한 배경을 못 얻으면 다른 배경으로 메우지 않고 멈춘 뒤 프롬프트를 바꿔 다시 요청합니다. 재시도는 두 번까지이고 워터마크를 덮어서 가리는 선택지는 두지 않았습니다.
2. 검사가 기록을 보게 했습니다. 대표 이미지를 만들 때마다 어떤 도구로 합성했고 배경을 어디서 받았는지를 기록 파일에 남기고 발행 전 검사가 그 기록을 읽어 기준과 다르면 발행을 막습니다.

이렇게 바꾼 뒤로는 기록이 기준과 다르면 발행 단계에서 멈추기 때문에 대표 이미지가 조용히 바뀌어 나갈 길이 막혔습니다. 규칙을 알려줘도 지켜지지 않던 경험은 예전에 쓴 AI에게 규칙을 알려줬는데 안 지켜졌습니다 글과 같은 결입니다. 이미지 쪽에서도 필자는 문서에 적은 규칙보다 결과물을 직접 읽는 검사 한 줄을 더 믿기로 했습니다.

6. 비율과 해상도는 어디까지 고를 수 있나요?

API에서는 비율과 해상도를 직접 지정할 수 있고 앱에서는 도움말에 비율 지정 방법이 따로 적혀 있지 않아서 프롬프트에 비율을 적고 받은 뒤 크기를 재는 편이 확실합니다. API 문서는 입력 이미지가 있으면 그 크기에 맞추고 없으면 1:1 정사각형으로 만드는 것이 기본값이라고 적고 있고 responseformat 안의 aspectratio와 image_size로 바꿀 수 있다고 안내합니다.

Nano Banana 2 기준으로 문서가 적은 비율은 1:1, 1:4, 1:8, 2:3, 3:2, 3:4, 4:1, 4:3, 4:5, 5:4, 8:1, 9:16, 16:9, 21:9 입니다. 해상도는 512px, 1K, 2K, 4K 네 단계이고 512px은 Nano Banana 2 전용이며 Lite는 1K만 됩니다. 값은 1K처럼 대문자 K로 써야 하고 소문자 1k는 거절된다는 문장도 문서에 있습니다.

블로그와 SNS에서 자주 쓰는 비율만 추려서 1K 출력 크기를 옮기면 아래와 같습니다.

표에서 보듯 3:2 1K는 1200x800 이 아니라 1264x848 로 나옵니다. 필자 블로그의 대표 이미지는 1200x800 규격이라서 제미나이 이미지 생성 결과를 그대로 올리지 못하고 한 번 줄여야 하는데요, 얼마나 잘리는지 직접 계산해 봤습니다.

직접 확인 3. 2026년 9월 28일 macOS 27.0, Python 3.14.7 에서 아래 한 줄을 실행했습니다. 앞에서부터 3:2 1K 출력의 실제 비율, 가로를 1200으로 줄였을 때의 세로 길이, 1200x800 을 SNS 미리보기 비율 1.91:1 로 자를 때 위아래에서 각각 잘려 나가는 픽셀입니다.

python3 -c "print(round(1264/848,3), round(848*1200/1264,1), round((800-1200/1.91)/2,1))"
1.491 805.1 85.9

1264x848 을 가로 1200 으로 줄이면 세로가 약 805 가 되니 위아래에서 몇 픽셀만 잘라내면 1200x800 이 되고 구도는 거의 그대로 남습니다. 대신 이 이미지가 SNS 링크 미리보기로 나갈 때는 위아래가 각각 86픽셀 가까이 잘리기 때문에 제목과 주제는 세로 가운데 띠 안에 두라고 프롬프트에 적어 두는 편이 안전합니다.

필자는 받은 파일의 픽셀 크기부터 확인합니다. 다른 비율로 오면 가운데를 기준으로 잘라 맞출 수는 있지만 잘라낸 만큼 구도가 무너지니 처음부터 비율을 맞춰 받는 쪽이 낫습니다.

7. 워터마크와 SynthID는 지울 수 있나요?

제미나이 이미지 생성 결과에 찍히는 보이는 워터마크는 한국에서 AI Ultra 구독이 있을 때만 설정으로 끌 수 있고 보이지 않는 SynthID 워터마크는 어떤 구독에서도 끌 수 없습니다. Gemini 앱 워터마크 설정 도움말에는 이 문장이 그대로 있습니다.

대한민국, 베트남 또는 인도에 거주하는 경우 AI Ultra 구독이 있는 경우에만 이 설정이 표시됩니다. 그렇지 않으면 Gemini 앱으로 만든 모든 시각적 미디어에 보이는 워터마크가 자동으로 표시됩니다.

설정이 보이는 계정이라면 컴퓨터에서 gemini.google.com 을 열고 왼쪽 아래 설정의 미디어 워터마크에서 켜고 끌 수 있습니다. 같은 도움말은 이 설정이 보이는 워터마크만 제어하고 SynthID와 콘텐츠 자격 증명(C2PA) 메타데이터에는 영향을 주지 않으며 제미나이 앱에만 적용된다고 못 박아 두었습니다.

SynthID는 구글 딥마인드의 SynthID 소개 페이지 설명으로 사람 눈에 보이지 않는 디지털 워터마크이고 이미지가 만들어지는 순간 들어가며 자르기, 필터, 손실 압축 같은 변형을 견디도록 설계됐습니다. API 문서도 생성된 모든 이미지에 SynthID 워터마크가 들어간다고 적고 있어서 앱으로 만들든 API로 만들든 제미나이 이미지 생성 결과물에는 이 표식이 남는다고 보시면 됩니다.

반대로 어떤 이미지가 구글 AI로 만든 것인지 궁금할 때는 AI 생성 콘텐츠 확인 도움말대로 제미나이 앱에 그 이미지를 올리고 "이 이미지가 Google AI로 생성 또는 수정되었어?"라고 물으면 됩니다. 확인할 때 알아둘 조건은 아래와 같습니다.

• 한 번에 파일 하나, 100MB 이하만 확인할 수 있고 여러 이미지를 콜라주로 올리면 안 됩니다
• 스크린샷으로 확인할 때는 이미지 가장자리에 최대한 붙여서 잘라야 정확도가 올라갑니다
• 워터마크가 감지되지 않았다는 결과는 구글 AI가 만들지 않았다는 뜻일 뿐 다른 AI가 만들었을 가능성은 남습니다
• 아주 단순하거나 추상적인 이미지는 워터마크를 넣을 세부가 부족해 판정이 모호할 수 있습니다

필자가 대표 이미지 배경에서 마주친 워터마크는 제미나이 로고가 아니라 앞에서 말한 다른 이미지 서비스의 표기였는데요, 여기서 배운 것은 AI 도구가 '이미지를 만들었다'고 답해도 그 그림을 어느 모델이 그렸는지는 결과만 봐서는 알 수 없다는 점이었습니다. 그래서 필자는 받은 이미지마다 구석의 워터마크와 그림 속에 섞여 들어온 글자를 눈으로 먼저 보고 하나라도 있으면 그 장은 버립니다.

8. 제미나이 이미지 생성에서 안 되는 것과 막히는 조합

제미나이 이미지 생성을 정리하면서 도움말과 API 문서에서 막히는 조건을 따로 모았습니다. 되는 기능보다 이 목록을 먼저 보시면 같은 요청을 여러 번 되풀이하는 일을 줄일 수 있습니다.

1. 연령 조건 생성은 만 13세(국가별 적정 연령) 이상, 편집은 만 18세 이상입니다. 학교 계정은 제한이 더 붙을 수 있습니다.
2. 한국의 보이는 워터마크 AI Ultra 구독이 아니면 설정 메뉴 자체가 보이지 않고 모든 이미지에 워터마크가 자동으로 들어갑니다.
3. SynthID는 끌 수 없음 설정으로도 구독으로도 빠지지 않습니다. 도움말은 크기 조정과 색 변경과 압축에도 대개 유지되지만 여러 번 변형하면 감지되지 않을 수 있다고 적고 있습니다.
4. 장수 지정은 보장되지 않음 API 문서에 따르면 제미나이 이미지 생성에서 모델이 사용자가 요청한 출력 장수를 늘 정확히 따르지는 않습니다.
5. Lite의 제약 Nano Banana 2 Lite는 1K만 되고 구글 검색 연동을 지원하지 않으며 참조 이미지를 여러 장 쓰거나 연속으로 고치는 작업에는 맞지 않습니다.
6. 참조 이미지 한도 참조 이미지는 최대 14장까지 섞을 수 있지만 모델마다 물체와 인물을 얼마나 충실히 유지하는지가 다릅니다. Nano Banana 2는 인물 4명과 물체 10개까지 유지한다고 적혀 있습니다.
7. 정책 위반 가능성이 있는 이미지는 지워질 수 있음 앱 도움말은 금지된 사용 정책을 어길 가능성이 있다고 감지되면 이미지를 삭제할 수 있다고 적고 있습니다.

가장 자주 부딪히는 조합은 2번과 4절의 글자 문제가 겹칠 때입니다. 워터마크가 들어갈 자리까지 계산해 글자를 배치해야 하니 한국에서 무료로 쓰면서 글자 넣은 완성본까지 한 번에 받으려 하면 고칠 곳이 늘어납니다. 배경만 받고 글자는 따로 얹는 5절의 방식이 이 조합을 피하는 가장 단순한 길입니다.

9. 제미나이 이미지 생성을 쓰다 보면 생기는 질문

본문에서 다 풀지 못한 질문을 짧게 모았습니다. 답은 모두 앞에서 인용한 공식 문서 기준이고 문서에서 확인하지 못한 것은 확인하지 못했다고 적었습니다.

무료 계정으로도 제미나이 이미지 생성을 쓸 수 있나요?

로그인과 연령 조건을 채우면 쓸 수 있고 도움말은 유료 구독자에게 Nano Banana Pro로 다시 만드는 기능이 더해진다고 적고 있습니다. 하루에 몇 장까지 되는지는 계정과 시점에 따라 바뀔 수 있어서 이 글에서는 다루지 않았습니다.

만든 이미지를 블로그나 상업용으로 써도 될까요?

도움말은 이미지를 만드는 순간 금지된 사용 정책을 포함한 구글 서비스 약관에 동의한 것이 되고 타인의 저작권과 개인 정보 보호 권리를 침해하면 안 되며 게시하거나 쓰기 전에 신중히 판단하라고 적고 있습니다. 상업적 이용 범위를 딱 잘라 적은 문장은 이번에 찾지 못해서 필자가 판단하지 않고 약관 원문을 직접 읽어 보시길 권합니다.

한글로 프롬프트를 써도 되나요?

됩니다. API 문서의 최적 성능 언어 목록에 ko-KR이 있고 앱 도움말의 예시 프롬프트도 한국어 문장입니다. 다만 제미나이 이미지 생성으로 그림 안에 넣을 글자까지 한국어로 길게 쓰면 4절에서 본 문제가 생길 수 있습니다.

다른 이미지 모델과 비교하면 어떤가요?

같은 프롬프트로 여러 모델을 나란히 돌려 본 비교는 이번에 하지 않았습니다. OpenAI 쪽 이미지 모델의 요금과 화질 단계는 예전에 정리한 GPT Image 2.5 요금과 화질 5단계 글을 참고하시면 되고 두 모델을 같은 조건으로 재 보는 일은 다음 회차 숙제로 남겨 둡니다.

10. 누구에게 맞고 누구에게는 굳이인가, 그리고 필자의 결론

지금까지 본 기능과 제약을 쓰임새별로 옮기면 아래와 같습니다. 자기 상황에 가까운 줄 하나만 보셔도 제미나이 이미지 생성을 어디까지 맡길지 정하실 수 있습니다.

반대로 로고나 상표처럼 모양이 정확해야 하는 그림은 제미나이 이미지 생성에 맡기지 않는 편이 낫다고 봅니다. AI가 그린 로고는 형태가 조금씩 어긋나기 쉬워서 필자는 로고가 필요한 구도라면 실제 로고 파일을 따로 얹습니다. 제미나이 자체가 아직 낯설다면 예전에 정리한 5분 제미나이 서평과 제미나이 노트북 사용법, 노트북LM 차이 5가지가 출발점으로 괜찮습니다.

필자의 결론

필자는 제미나이 이미지 생성을 장면과 분위기를 만드는 도구로 쓰고 글자와 크기는 사람이 마무리하는 분업이 지금 가장 덜 고치는 방법이라고 봅니다. 공식 문서가 글자 렌더링이 좋아졌다고 말하는 것도 사실이고 짧은 문구는 실제로 잘 들어가지만 한 글자라도 틀리면 그 장 전체를 다시 뽑아야 하는 구조는 그대로입니다.

그래서 필자는 블로그 대표 이미지에서 이 분업을 규칙으로 적는 데서 끝내지 않고 발행 전 검사가 배경의 출처와 합성 방식을 확인하게 바꿨고 깨끗한 배경을 못 얻은 날에는 다른 배경으로 메우지 않고 멈추기로 했습니다. 아직 하지 않은 것은 Nano Banana Pro에 한글 제목을 직접 넣게 해서 따로 얹는 방식과 품질을 나란히 비교해 보는 일인데요, 그 비교를 해 보고 결과가 뒤집히면 이 결론도 고쳐 적겠습니다.

참고한 공식 문서

직접 확인 1과 같은 2026년 9월 28일에 아래 문서를 받아 읽고 본문의 사실을 대조했습니다.

• 구글 AI 개발자 문서 Nano Banana image generation
• 구글 도움말 Gemini 앱으로 이미지 생성 및 수정하기
• 구글 도움말 Gemini 앱에서 워터마크 설정 관리하기
• 구글 도움말 AI 생성 이미지, 동영상, 오디오 확인하기
• 구글 딥마인드 SynthID
• 구글 코리아 블로그 나노 바나나 프로 소개(2025년 11월 20일)

The post 제미나이 이미지 생성 방법, 한글 글자와 워터마크 appeared first on WONIZZ.LOG.

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

AI 에이전트가 짜 준 스크립트가 테스트를 전부 초록으로 통과해서 그대로 돌려 두었는데 며칠 뒤 결과를 열어 보니 숫자가 처음부터 틀려 있었던 경험이 있으신가요?

안녕하세요? 정리하는 개발자 워니즈입니다. 이번 시간에는 필자가 바이브 코딩으로 블로그 운영 도구를 맡기다가 2026년 9월 25일과 26일 이틀 사이에 셀프테스트는 통과했는데 실데이터에서 틀린 도구 세 개를 만난 기록과 그 뒤로 검증 방식을 어떻게 바꿨는지를 정리해보려고 합니다.

한 줄 요약 바이브 코딩으로 만든 도구의 셀프테스트 통과는 코드가 자기 가정대로 움직인다는 뜻일 뿐이었고 세 번 모두 틀린 것은 코드가 아니라 가정이었습니다. 그래서 테스트를 일부러 망가뜨려 보는 변이 테스트와 만든 직후 실데이터 1회 실행과 관측 못 하는 것은 판별 불가로 두기 세 가지를 완료 조건에 넣었습니다.

• 무엇이 초록이었나 서치콘솔 원장 도구와 광고 슬롯 점검 도구와 검색 수요 게이트 세 개가 전부 셀프테스트를 통과했습니다
• 실데이터는 뭐라 했나 원장은 글 261편 중 6편만 서치콘솔 표와 맞았고 광고 도구의 렌더 실패 판정은 브라우저에서 반증됐으며 수요 게이트를 넘긴 글은 실제 주제 검색어의 파생어가 2개뿐이었습니다
• 그래서 바꾼 것 바이브 코딩으로 받은 도구는 테스트가 망가진 코드를 잡는지 먼저 보고 만든 직후 실데이터로 돌려 매칭률 같은 숫자를 눈으로 보며 도구가 볼 수 없는 것은 단정하지 않습니다

목차

1. 바이브 코딩으로 무엇을 맡겼나
2. 셀프테스트 GATE_OK 는 무엇을 보장하나요?
3. 사례 1 서치콘솔 원장은 261편 중 6편만 맞았다
4. 사례 2 광고 점검 도구는 산술만으로 렌더 실패를 단정했다
5. 사례 3 수요 게이트는 넓은 키워드 하나로 통과됐다
6. 세 사례에서 테스트는 왜 같은 식으로 틀렸을까요?
7. 바이브 코딩 검증 체크리스트 3가지
8. 이 확인에 드는 비용은 얼마나 되나요?
9. 이렇게 확인해도 안 되는 것
10. 정리와 필자의 결론

1. 바이브 코딩으로 무엇을 맡겼나

바이브 코딩은 코드를 한 줄씩 읽기보다 AI 에게 원하는 결과를 말로 설명하고 나온 코드를 돌려 보며 방향을 잡는 방식을 가리키는 말입니다. 위키백과 정리로는 안드레 카파시가 2025년 초에 붙인 이름으로 알려져 있습니다(위키백과 Vibe coding 항목).

셀프테스트는 도구에 --selftest 같은 모드를 하나 두고 그 안의 확인이 전부 통과하면 마지막에 GATE_OK 를 출력하게 만든 것이라서, 에이전트도 필자도 그 한 줄을 보고 작업이 끝났다고 판단해 왔습니다. 바이브 코딩으로 맡긴 일은 이 블로그를 운영하는 자동화였고 이번 글에 나오는 도구는 아래 세 개인데 셋 다 만든 날 초록불을 받았습니다.

에이전트에게 혼자 일을 맡기면 늘어나는 것이 산출물이 아니라 검증이라는 이야기는 DevOps 카테고리의 AI 에이전트로 혼자 일하기, 늘어난 건 산출물이 아니라 검증이었습니다 에서 한 번 적었는데요, 이번 기록은 그 검증이 초록불을 내고도 틀릴 수 있다는 쪽의 이야기입니다.

바이브 코딩을 깎아내리려는 글은 아닙니다. 세 도구는 지금도 에이전트가 만든 그대로 돌고 있고 달라진 것은 완료로 치는 기준 하나뿐이라서 맡기되 어디를 확인하면 되는지를 남기는 쪽에 가깝습니다.

2. 셀프테스트 GATE_OK 는 무엇을 보장하나요?

GATE_OK 는 코드가 테스트를 만든 쪽의 가정대로 움직인다는 것까지만 보장하고 그 가정이 맞는지는 보장하지 않습니다. 바이브 코딩에서 셀프테스트는 보통 코드를 쓴 에이전트가 픽스처(테스트용 입력)까지 함께 만드는데, 입력이 어떻게 생겼을지에 대한 가정이 코드와 테스트 양쪽에 똑같이 들어가 있어서 가정이 틀리면 둘이 사이좋게 같이 틀립니다.

이 구조를 모르고 초록불을 보면 틀린 믿음이 오히려 단단해집니다. 테스트가 통과했다는 사실이 확인을 마쳤다는 느낌을 주지만 실제로 확인한 것은 코드와 테스트가 서로 모순되지 않는다는 데까지이기 때문입니다.

AI 가 완료했다고 보고한 것을 그대로 믿었다가 게재 실패를 놓친 일은 AI 완료 보고를 그대로 믿으면 생기는 일 에서 다뤘습니다. 셀프테스트 통과는 말로 한 완료 보고보다 한 단계 믿음직해 보이는 신호라서 바이브 코딩에서는 오히려 더 조심해야 할 초록불이라고 생각합니다.

3. 사례 1 서치콘솔 원장은 261편 중 6편만 맞았다

무엇이 초록이었나. post-ledger.py 는 서치콘솔 실적 표를 브라우저로 긁어서 표 첫 칸의 페이지 URL 을 키로 삼고 블로그 글 목록과 맞춰 글별 노출과 순위를 원장에 쌓는 도구입니다. 2026-09-25 에 에이전트가 함께 만든 셀프테스트는 URL 이 깔끔하게 들어 있는 픽스처로 매칭과 합산을 확인했고 결과는 GATE_OK 였습니다.

실데이터가 뭐라 했나. 실제로 한 번 돌리자 원장에 등록된 글 261편 가운데 서치콘솔 표와 매칭된 글이 6편뿐이었습니다. 노출이 있는 글이 6편밖에 없을 리는 없어서 첫 칸에 실제로 무엇이 들어왔는지 찍어 보니 URL 뒤에 표 행에 마우스를 올리면 뜨는 버튼 문구가 붙어 있었습니다.

직접 확인 1. 아래가 그날 Aside 브라우저로 연 서치콘솔 실적 표에서 페이지 행 첫 칸의 innerText 를 그대로 옮긴 것이고, 기록을 남길 때 도메인과 날짜 부분은 줄여 적었습니다.

https://.../mcp-server-with-cusor-ai/ 클립보드에 URL 복사 새 탭에서 열기 URL 검사

왜 테스트가 못 잡았나. innerText 는 요소와 그 자손이 렌더된 텍스트를 돌려주는 속성이라서 셀 안에 들어 있는 버튼의 글자까지 함께 딸려 옵니다(MDN HTMLElement.innerText). 픽스처는 에이전트가 상상한 깨끗한 표였고 실제 서치콘솔 표는 그렇지 않았으니 테스트는 몇 번을 돌려도 통과할 수밖에 없었습니다.

평소에는 눈에 띄지 않던 버튼 문구가 왜 innerText 에 들어왔는지 CSS 수준의 원인은 이번에 확인하지 않았고, 모든 행이 오염됐을 텐데 6편은 왜 맞았는지도 따로 들여다보지 않아서 두 가지 모두 미확인으로 남깁니다. 필자가 확인한 것은 실제 출력에 그 문구가 붙어 있었다는 데까지입니다.

고친 방법. 셀 텍스트를 통째로 키로 쓰지 않고 그 안에서 URL 만 뽑아 정규화하는 키 정리 함수를 넣었습니다. 원리는 아래 한 줄로 재현할 수 있는데 macOS 27.0 과 Python 3.14.7 에서 돌리면 https://blog.wonizz.com/2025/09/12/mcp-server-with-cusor-ai/ 한 줄만 출력됩니다.

python3 -c "import re; raw='https://blog.wonizz.com/2025/09/12/mcp-server-with-cusor-ai/ 클립보드에 URL 복사 새 탭에서 열기 URL 검사'; print(re.search(r'https?://\S+', raw).group(0))"

직접 확인 2. 키를 정리한 뒤 같은 원장을 다시 채우자 261편 중 100편이 서치콘솔 표와 이어졌습니다. 나머지 글은 3개월 창 안에 노출이 없어 표에 행 자체가 없는 경우라서 매칭률이 100%가 아닌 것은 정상 범위로 봤고, 셀프테스트 픽스처에도 버튼 문구가 붙은 실제 모양의 입력을 추가해 같은 오염이 다시 들어오면 테스트가 먼저 떨어지게 했습니다.

서치콘솔 데이터를 믿고 판단하는 일은 블로그운영 카테고리의 제 블로그 글 절반 이상이 구글 색인에 없었습니다 에서 색인 누락을 다룰 때도 나왔는데요, 그때는 사람이 표를 읽었고 이번에는 도구가 읽었다는 점만 다르고 표에 무엇이 실제로 들어 있는지부터 봐야 한다는 교훈은 같았습니다.

바이브 코딩으로 스크래퍼를 맡길 때 이 사례가 특히 아픈 이유는 입력이 남의 화면이라는 데 있습니다. 서치콘솔 화면을 설계한 쪽이 셀 안에 무엇을 넣을지는 필자도 에이전트도 정할 수 없으니 그 모양을 아는 방법은 실제로 한 번 긁어 보는 것밖에 없었습니다.

4. 사례 2 광고 점검 도구는 산술만으로 렌더 실패를 단정했다

무엇이 초록이었나. 같은 날 만든 ad-inventory.py 는 페이지 HTML 에서 명시 광고 슬롯을 세고 실측 광고 노출과 견줘 원인을 판정하는 도구였고 셀프테스트는 역시 통과했습니다. 실데이터로 돌리자 표본 18편의 페이지당 명시 슬롯이 3.67개이고 실측 노출이 페이지당 0.94개로 나왔는데, 도구는 앞의 숫자가 뒤의 2배를 넘는다는 산술 하나로 “원인 판정 렌더 실패”를 출력했습니다.

실데이터가 뭐라 했나. 브라우저로 실제 페이지를 열어 슬롯이 광고 iframe 으로 채워졌는지 세어 보니 렌더는 정상이었고 렌더 실패라는 판정은 그 자리에서 반증됐습니다.

직접 확인 3. Aside 브라우저로 연 긴 글에서는 6슬롯 중 5개가, 짧은 글에서는 7슬롯 전부가, 홈에서는 2슬롯 전부가 iframe 으로 채워져 있었습니다.

왜 테스트가 못 잡았나. 테스트는 계산이 맞는지를 봤고 계산은 실제로 맞았습니다. 틀린 것은 슬롯 수가 노출 수보다 많으면 렌더가 실패한 것이라는 해석이었고 HTML 만 읽는 도구는 브라우저에서 무슨 일이 일어나는지 볼 수 없으니 렌더를 판정할 자격이 처음부터 없었습니다.

고친 방법. 도구의 판정을 “판별 불가”로 바꾸고 이유를 함께 남기게 했습니다. HTML 만 보는 도구는 렌더를 단정할 수 없기 때문입니다. 원인은 그 뒤 광고 콘솔 보고서를 직접 읽어서 좁혔습니다. 28일 동안 페이지당 광고 요청은 2.47로 목표를 이미 넘었고, 손실은 두 단계였습니다. 게재되지 않은 요청이 167건, 게재됐지만 노출로 집계되지 않은 요청이 118건입니다. 슬롯이 모자란 것도 렌더가 깨진 것도 아니라 게재 단계의 문제였습니다. 도구가 판별 불가로 멈췄기 때문에 사람이 다음에 볼 곳을 알 수 있었습니다.

산술로 단정한 판정이 원장에 남으면 다음 자동화가 그 판정을 읽고 멀쩡한 슬롯을 고치러 갑니다. 관측하지 못한 것을 판별 불가로 적는 것은 모른다는 고백이 아니라 다음 작업이 엉뚱한 곳을 파지 않게 막는 장치였습니다.

이 사례는 바이브 코딩에서 흔히 떠올리는 버그와 모양이 조금 다른데, 코드가 틀린 값을 낸 것이 아니라 맞는 값을 두고 너무 많이 말한 경우였습니다. 이 도구는 숫자 두 개 사이에 원인 이야기를 붙였고 그래서 판정 문장을 쓰는 도구라면 그 문장의 근거가 도구가 실제로 본 것인지를 따로 확인해야 한다는 것을 이번에 배웠습니다.

5. 사례 3 수요 게이트는 넓은 키워드 하나로 통과됐다

무엇이 초록이었나. 이 블로그에는 글감의 검색 수요를 구글 자동완성으로 재서 파생 검색어가 20개 미만이면 발행을 막는 게이트가 있습니다. 2026-09-26 에 에이전트는 포커스 키워드를 리눅스 로 적었고, 파생어 65개로 게이트를 넘긴 리눅스 폴더 비교 글이 그날 아침 발행됐습니다.

실데이터가 뭐라 했나. 글이 실제로 답하는 검색어로 다시 재자 숫자가 전혀 달랐고 게이트가 막았어야 할 글이라는 것이 드러나서 그 글은 삭제했습니다.

직접 확인 4. 리눅스 폴더 비교 의 자동완성 파생어는 2개였고 구글 트렌드 12개월 평균은 0이었으며(같은 비교에서 리눅스 명령어 18.9, 2026-09-26 측정), 같은 날 잰 리눅스 diff 도 9개라서 하한 20에 못 미쳤습니다.

왜 테스트가 못 잡았나. 게이트는 frontmatter 에 적힌 키워드 하나만 쟀고 그 키워드가 글이 답하는 검색어인지는 누구도 보지 않았습니다. 게이트의 입력을 게이트를 통과하려는 쪽이 직접 적는 구조였으니 넓은 상위어를 적는 것만으로 어떤 주제든 지나갈 수 있었던 셈입니다.

고친 방법. 포커스 키워드는 글이 답하는 검색어여야 하고 넓은 상위어로 게이트를 넘기지 않는다는 문장을 자동 제작 지시문에 넣었습니다. 다만 이것은 규칙 문장이지 코드 게이트가 아니라서 온전히 막았다고 말하기는 이른데요, 규칙을 알려줘도 안 지켜지는 문제는 AI에게 규칙을 알려줬는데 안 지켜졌습니다 에서 이미 한 번 겪었습니다.

이 글의 포커스 키워드도 같은 기준으로 골랐습니다. 넓은 바이브 코딩 한 단어로 정하고 끝내지 않고 구글 자동완성 기본 목록에 바이브 코딩 현실 이 뜨는 것을 확인한 뒤 그 각도로 제목을 잡았습니다.

6. 세 사례에서 테스트는 왜 같은 식으로 틀렸을까요?

셋 다 코드가 아니라 입력이나 해석에 대한 가정이 틀렸고 그 가정을 코드와 테스트가 똑같이 품고 있었기 때문입니다. 바이브 코딩에서 이 겹침은 더 잘 생기는 것 같은데, 같은 에이전트가 같은 대화 안에서 코드와 테스트를 함께 만들면 가정을 의심해 줄 두 번째 시선이 없습니다.

표를 세로로 읽으면 공통점이 보입니다. 세 번 모두 실데이터가 잡았고 테스트 케이스를 몇 개 더 늘렸다고 해서 잡혔을 것 같지는 않습니다. 더 많은 테스트가 아니라 다른 종류의 확인이 필요했다는 것이 이 표에서 필자가 읽은 결론입니다.

틀린 가정의 모양도 셋이 조금씩 달랐습니다. 원장은 외부 시스템이 주는 입력의 모양을 잘못 짐작했고 광고 점검은 도구가 볼 수 없는 영역까지 결론을 넓혔으며 수요 게이트는 입력을 누가 적는지를 따지지 않았는데, 다음 절의 확인 세 가지도 이 셋에 하나씩 대응하도록 골랐습니다.

한 가지 덧붙이면 세 도구 모두 코드 리뷰로는 잡기 어려운 결함이었습니다. 원장의 매칭 코드도 광고 점검의 산술도 게이트의 비교문도 읽어 보면 멀쩡했고, 문제가 된 것은 코드 바깥에 있는 세상이 코드의 예상과 달랐다는 점이라서 바이브 코딩에서 코드를 더 꼼꼼히 읽는 것만으로는 같은 결함을 줄이기 어려울 것 같습니다.

7. 바이브 코딩 검증 체크리스트 3가지

세 사례 뒤로 필자는 에이전트가 만든 도구의 완료 조건에 아래 세 가지를 넣었고, 바이브 코딩으로 맡기는 양은 줄이지 않은 채 완료로 치는 기준만 바꿨습니다.

변이 테스트로 테스트를 일부러 망가뜨려 본다

변이 테스트는 코드에 작은 결함을 일부러 심은 변이체를 만들고 테스트가 그 변이를 잡아 실패하는지 보는 방법입니다(위키백과 Mutation testing). 경계값 < 를 <= 로 바꾸거나 조건을 if False 로 바꿨는데도 테스트가 여전히 통과한다면 그 테스트는 그 줄을 사실상 확인하지 않고 있다는 뜻입니다.

수요 게이트처럼 20 미만을 막는 판정으로 재현해 보면 차이가 바로 보입니다. 아래는 원래 조건과 <= 로 바꾼 변이를 입력 5와 65와 20에 돌린 명령이고 macOS 27.0 과 Python 3.14.7 에서 실행한 출력을 그 아래에 붙였습니다.

python3 -c "gate=lambda n: n < 20; mutant=lambda n: n <= 20; [print(n, gate(n), mutant(n)) for n in (5, 65, 20)]"

5 True True
65 False False
20 False True

입력이 5와 65뿐인 테스트라면 원래 코드와 변이가 같은 답을 내니 변이가 살아남고 경계값 20을 넣어야 비로소 둘이 갈리는데요, 바이브 코딩으로 받은 테스트를 읽을 때 경계값이 입력에 들어 있는지부터 보는 이유가 여기에 있습니다. 9월 26일에 트렌드 수집 도구에 원천을 하나 더 붙일 때도 > 를 >= 로 바꾸기와 라벨 태그 제외 끄기와 카테고리 제한 끄기 세 변이를 셀프테스트가 전부 잡는 것을 보고 나서 완료로 쳤습니다.

손으로 변이를 넣는 대신 도구를 쓸 수도 있는데 자바에는 PIT 가 있고 자바스크립트와 C# 쪽에는 Stryker 가 있습니다. 필자의 스크립트는 작아서 아직 손으로 넣고 있고 이 도구들을 블로그 자동화에 붙여 보지는 않았습니다.

실데이터 1회로 만든 직후에 한 번 흘려 본다

변이 테스트만으로는 사례 1을 못 잡습니다. 픽스처가 실제와 다른 모양이면 변이를 아무리 넣어도 틀린 입력 위에서 잘 잡힐 뿐이라서 입력 가정을 확인하는 길은 실데이터를 한 번 흘려 보는 것밖에 없었습니다.

요령은 돌리기 전에 이 정도는 나와야 한다는 숫자를 먼저 적어 두는 것입니다. 사례 1에서는 글 261편 중 적어도 수십 편은 이어져야 한다는 감각이 있었기에 6이라는 숫자가 이상하게 보였고, 기대값이 없었다면 6편짜리 원장을 그대로 믿고 다음 단계로 넘어갔을 것 같습니다.

• 매칭률 두 목록을 잇는 도구라면 몇 퍼센트가 이어졌는지 보고 기대 범위와 견줘 봅니다
• 건수 수집 도구라면 행이 몇 개 들어왔는지 보고 0이나 1처럼 수상한 숫자가 아닌지 확인합니다
• 표본 한 줄 키로 쓰는 값 하나를 그대로 찍어서 공백이나 덧붙은 문구가 없는지 사람 눈으로 읽어 봅니다

실데이터를 한 번 흘려 보고 나면 그 입력을 픽스처로 떠서 셀프테스트에 넣어 두는 것까지를 한 묶음으로 칩니다. 사례 1에서 버튼 문구가 붙은 셀을 픽스처로 박아 둔 것처럼 한 번 만난 실제 모양을 테스트가 기억하게 하면 다음 수정에서 같은 오염이 되돌아와도 초록불이 먼저 꺼집니다.

판별 불가로 관측 못 하는 것은 단정하지 않는다

도구가 볼 수 있는 범위를 넘어서는 결론은 내지 않게 합니다. HTML 만 읽는 도구가 렌더를 말하거나 자동완성 숫자만 보는 게이트가 글과 검색어가 맞는지를 말하는 것이 이번에 본 범위 초과였습니다.

판별 불가에는 반드시 이유를 붙이게 했는데, 사례 2라면 HTML 에서 슬롯은 셌지만 렌더 여부는 브라우저 없이 볼 수 없다는 식으로 다음에 무엇을 확인해야 하는지가 이유 안에 들어 있어야 판정이 다음 행동으로 이어집니다.

에이전트에게 맡길 때는 어떻게 요청할까요?

세 확인을 사람이 매번 손으로 하면 바이브 코딩의 속도가 사라지니 요청 단계에서 에이전트에게 넘기는 방법이 있습니다. 도구를 맡기는 요청 끝에 붙일 수 있는 문장을 예로 들면 아래와 같고 문구는 상황에 맞게 바꿔 쓰면 됩니다.

1. 셀프테스트를 만든 뒤 경계값과 조건을 바꾼 변이를 두세 개 넣어서 테스트가 전부 잡는지 보여 주세요
2. 만든 직후 실데이터로 한 번 돌리고 매칭률이나 건수를 기대 범위와 함께 보고해 주세요
3. 이 도구가 직접 볼 수 없는 것은 판정하지 말고 판별 불가와 그 이유로 남겨 주세요

다만 기대 범위만큼은 에이전트에게 정하게 두지 않고 사람이 먼저 적는 편이 맞다고 봅니다. 결과를 본 뒤에 정한 기대값은 그 결과에 맞춰지기 쉬워서 돌리기 전에 사람이 적어 두는 숫자 하나가 이 체크리스트에서 가장 값싼 안전장치라고 생각합니다.

8. 이 확인에 드는 비용은 얼마나 되나요?

도구를 한 번 더 돌리고 숫자 하나를 사람이 읽는 정도라서 추가로 드는 것은 크지 않았습니다. 반대로 확인을 건너뛰었을 때 치른 값은 세 사례에서 이미 드러났는데 그 둘을 나란히 놓으면 아래와 같습니다.

에이전트 쪽 비용도 조금 늘어납니다. 변이를 넣고 실데이터로 돌려 보라는 요청이 바이브 코딩 대화에 한두 턴을 더하니 토큰이 그만큼 더 들지만, 틀린 원장을 바탕으로 한 주 동안 내린 판단을 되돌리는 비용과 견주면 필자 환경에서는 따져볼 필요가 없는 크기였습니다.

바이브 코딩의 장점이 빨리 만들고 빨리 돌려 보는 데 있다면 이 확인들도 그 속도 안에 들어가는 편입니다. 만든 직후에 하면 싸고 원장에 숫자가 쌓인 뒤에 하면 비싸다는 차이가 있을 뿐입니다.

9. 이렇게 확인해도 안 되는 것

세 가지 확인을 넣었다고 초록불을 믿어도 되는 것은 아니고 이번 기록 안에서도 막히지 않은 자리가 보여서 그대로 적어둡니다.

1. 변이 테스트는 입력 가정의 오류를 못 잡습니다. 사례 1처럼 픽스처가 틀린 모양이면 변이는 전부 잡히는데도 테스트는 여전히 실제 입력을 모르는 상태로 남습니다
2. 실데이터 1회는 표본 하나입니다. 그날 데이터에 없던 모양의 입력은 다음에 또 새어 들어올 수 있고 서치콘솔이 버튼 문구를 바꾸면 키 정리 함수가 다시 맞는지는 그때 가서 봐야 합니다
3. 기대 수치의 감각이 없으면 눈으로 봐도 모릅니다. 처음 만지는 데이터라면 돌리기 전에 사람이 기대 범위를 먼저 정해 두지 않는 한 6이 이상한 숫자인지 판단할 수 없습니다
4. 판별 불가는 답이 아니라 다음 행동입니다. 사례 2의 도구는 판별 불가에서 멈췄고, 원인은 광고 콘솔 보고서를 읽은 뒤에야 게재 단계로 좁혀졌습니다
5. 규칙 문장은 게이트가 아닙니다. 사례 3의 재발 방지는 아직 지시문 한 줄이라서 코드로 막혔다고 말할 수 없습니다
6. 이 기록은 한 블로그의 도구 세 개에서 나왔습니다. 바이브 코딩 전반에서 같은 비율로 일어난다고 말할 근거는 없고 필자가 말할 수 있는 것은 이 세 번의 모양까지입니다

바이브 코딩으로 만든 코드를 누가 어떻게 리뷰해야 하는지처럼 이 글이 다루지 않은 축도 있습니다. 여기서는 테스트와 판정이 무엇을 보장하는지까지만 다뤘고 코드 자체의 품질은 따로 보지 않았습니다.

10. 정리: 바이브 코딩이 맞는 사람과 굳이인 사람, 그리고 필자는 이렇게 봅니다

이 방식이 잘 맞는 쪽은 수집 스크립트나 원장 도구나 판정 게이트처럼 결과를 숫자로 확인할 수 있는 일을 바이브 코딩으로 에이전트에게 맡기는 개발자인데요, 실데이터를 한 번 흘리고 매칭률 하나를 읽는 것만으로 이번 같은 오류를 만든 날 잡을 수 있었습니다.

굳이인 쪽도 있습니다. 한 번 돌리고 버릴 스크립트라면 변이 테스트까지 챙길 이유가 적고, 반대로 결과를 관측할 수단이 아예 없는 일이라면 체크리스트를 채워도 판별 불가만 쌓이니 바이브 코딩으로 맡기기 전에 관측 수단부터 마련하는 편이 먼저입니다.

필자의 결론

바이브 코딩으로 맡긴 도구의 셀프테스트 통과는 완료가 아니라 출발선이라고 봅니다. 세 번의 초록불은 전부 코드가 아니라 가정이 틀린 것이었고 그 가정을 잡은 것은 매번 테스트가 아니라 실데이터였습니다.

그래서 필자는 에이전트에게 도구를 맡길 때 완료 조건을 GATE_OK 한 줄에서 세 줄로 바꿨습니다. 변이 두세 개를 테스트가 잡는지와 실데이터로 한 번 돌린 매칭률이나 건수가 기대 범위에 들어오는지와 관측 못 한 것을 판별 불가로 남겼는지를 함께 보고, 사례 3처럼 아직 규칙 문장으로만 막혀 있는 자리는 코드 게이트로 옮기기 전까지 그 통과를 믿지 않기로 했습니다.

이런 실측 기록은 Threads @wonizz.ai 에 먼저 올립니다. 에이전트에게 맡긴 일에서 무엇이 깨졌는지, 글로 정리하기 전의 기록을 거기서 먼저 보실 수 있습니다.

함께 보면 좋은 글

바이브 코딩으로 만든 결과를 어떻게 확인할지 더 보고 싶다면 아래 세 편을 이어서 읽어 보세요.

• 코드 리뷰가 못 따라갈 때 검사기 3가지 함정: 검사기가 통과를 내면서 정작 그 항목을 보지 않던 자리
• AI 코드리뷰, 한 명 대신 세 명에게 다르게 시켰습니다: 리뷰를 관점 세 개로 나눠 맡겼을 때 달라진 지적
• AI 코딩 도구, 빨라진 건 맞는데 어디가 느려졌을까: 연구 결과가 엇갈리는 이유와 느려진 자리

에이전트에게 맡긴 도구가 테스트를 통과했을 때, 여러분은 무엇을 보고 완료로 치시나요? 실데이터로 한 번 돌려 보시는지, 다른 기준을 두고 계신지 댓글로 알려 주세요. 모든 댓글을 읽고 답합니다.

The post 바이브 코딩 현실, 테스트는 통과했는데 261편 중 6편만 맞았다 appeared first on WONIZZ.LOG.