ChatGPT가 왜 자꾸 그림을 그릴까? 요청하지 않은 이미지 생성 문제와 해결 방법

요즘 ChatGPT를 쓰면서 이상한 일을 정말 자주 겪는다.

내가 그림을 부탁한 것도 아니다.

사진을 만들어달라고 한 것도 아니다.

그냥 이야기를 하고 있다.

문장을 어떻게 고치면 좋을지 이야기하거나, 웹페이지 구성을 의논하거나, 어떤 캐릭터가 보기 좋을지 의견을 묻거나, “이런 느낌이면 어떨까?” 하고 말을 꺼냈을 뿐이다.

그런데 갑자기 화면 아래쪽에서 뭔가 반짝거리기 시작한다.

파란 별빛 같은 것이 깜빡거린다.

나는 이제 그 모습을 꽤 많이 봐서 안다.

설마.

잠시 후.

그림이 나온다.

그리고 더 황당한 건, 그림만 나온다는 것이다.

설명도 없다.

“제가 이렇게 해석했습니다” 같은 말도 없다.

내가 원했던 답변은 증발하고, 이미지 한 장만 덩그러니 놓여 있다.

그 순간 사람 머릿속에는 대략 이런 생각이 든다.

아니 씨, 누가 그리랬어.

처음에는 내가 이상한 줄 알았다

AI를 오래 쓰다 보면 가끔 이런 생각을 한다.

내가 질문을 이상하게 했나?

내 프롬프트가 애매했나?

내가 앞에서 그림 얘기를 많이 해서 그런가?

그래서 처음에는 별일 아니라고 생각했다.

내가 이미지를 자주 다루는 것도 사실이다.

웹사이트도 만들고, 캐릭터도 만들고, 디자인도 이야기하니 AI 입장에서는 조금 헷갈릴 수도 있겠다 싶었다.

그런데 문제가 반복됐다.

한두 번이면 실수다.

여러 번이면 패턴이다.

나중에는 아예 말을 꺼내기 전부터 느낌이 왔다.

“아, 지금 이거 그림 그리겠는데?”

그리고 정말 그린다.

참 신기하다.

내가 그림을 만들어달라고 정확히 부탁할 때는 이것저것 설명해야 하는데, 안 그려도 될 때는 눈치가 기가 막히게 빠르다.

찾아보니 나만 그런 게 아니었다

그래서 검색해봤다.

결론부터 말하면, 나만 겪는 일은 아니었다.

OpenAI Developer Community의 Bugs 게시판에는 아예 “ChatGPT creating images when not asked to do so” 라는 제목의 글이 올라와 있다.

사용자들은 비슷한 이야기를 한다.

이미지를 비평해달라고 했는데 수정 이미지를 만들어버린다.

“여기에 뭘 추가하면 좋을까?”라고 물었더니 그냥 직접 추가해버린다.

심지어 “이미지를 생성하지 마라”고 적었는데도 가끔 생성한다는 사용자도 있다.

더 흥미로운 건 OpenAI Support도 이 불만에 직접 답했다는 점이다.

2026년 9월 OpenAI Support는 사용자가 텍스트만 원했는데 이미지가 생성되는 것이 답답한 문제라는 점을 인정하고, 관련 피드백을 내부에 전달하겠다고 답했다.

다만 언제 수정될지, 실제로 버그로 분류됐는지, 어떤 조건에서 발생하는지에 대한 공식 설명은 없었다.

그래서 나는 마음대로 이름을 하나 붙였다.

비공식 ChatGPT 알려진 버그.

OpenAI가 그렇게 부른다는 뜻은 아니다.

공식 버그 목록에 올라갔다는 뜻도 아니다.

그냥 여러 사람이 반복해서 겪고 있고, OpenAI도 관련 불만을 알고 있으니 사용자 입장에서는 이 정도 이름을 붙여도 되지 않을까 싶다.

더 이상한 건 공식 사용법과도 느낌이 다르다는 것이다

OpenAI의 공식 ChatGPT Images 도움말을 보면 이미지 생성 방식은 꽤 단순하게 설명되어 있다.

사용자가 만들고 싶은 이미지를 설명하거나, Images 기능을 선택해서 생성하는 방식이다.

상식적으로도 그렇다.

그림을 만들어달라고 하면 그림을 만든다.

글을 고쳐달라고 하면 글을 고친다.

사진을 평가해달라고 하면 평가한다.

그런데 실제 사용 중에는 이 경계가 가끔 무너진다.

특히 “이 디자인은 어때?”, “이런 이미지를 넣는 게 나을까?”, “캐릭터를 좀 더 단순하게 하면 어떨까?” 같은 말을 꺼내는 순간, AI가 갑자기

‘아, 생성하라는 뜻이구나.’

라고 혼자 결론 내리는 것 같은 일이 생긴다.

사람으로 치면 이런 느낌이다.

내가 인테리어 업자에게 묻는다.

“여기 벽을 노란색으로 칠하면 어떨까요?”

다음 날 집에 와보니 이미 칠해놨다.

문제는 그림이 아니라 통제감이다

사실 이미지 한 장 생성되는 게 세상 무너질 일은 아니다.

취소하면 된다.

무시하면 된다.

다시 질문하면 된다.

그런데 이게 반복되면 꽤 불쾌하다.

왜냐하면 문제의 핵심은 그림이 아니라

내가 요청한 작업과 AI가 실행한 작업이 다르다는 것

이기 때문이다.

AI가 아무리 똑똑해도 사용자가 시키지 않은 일을 멋대로 시작하면 신뢰가 떨어진다.

특히 이미지 생성은 텍스트 답변과 다르다.

잠깐 기다려야 하고, 작업 중이라는 표시가 뜨고, 완료되면 화면의 꽤 큰 부분을 차지한다.

그리고 내가 실제로 여러 번 겪은 것처럼, 이미지 생성으로 빠져버리면 원래 받고 싶었던 텍스트 답변 없이 이미지 하나만 나오는 경우도 있다.

이러면 꽤 황당하다.

나는 문장을 고쳐달라고 했는데, 왜 갑자기 미술작품을 감상하고 있나.

그 파란 반짝임이 보일 때

이건 어디까지나 내 개인적인 경험이다.

ChatGPT가 이미지 작업으로 들어갈 때 화면 아래쪽에서 파란빛이 반짝이는 듯한 작업 표시를 꽤 자주 봤다.

그게 기술적으로 정확히 무엇을 뜻하는 UI인지, 항상 이미지 생성을 의미하는지는 나는 모른다.

그러니 “파란 불이 깜빡이면 100% 이미지가 생성된다.” 라고 말할 생각은 없다.

하지만 내가 실제로 사용하면서 느끼기에는 그 장면을 보면 이제 거의 조건반사적으로 생각한다.

또 시작했구나.

실제 사용 중 캡처한 화면

그리고 가끔은 정말 이미지가 나온다.

이런 경험이 누적되면 사용자는 AI가 무엇을 할지 기대하는 게 아니라 무엇을 또 멋대로 할지 감시하기 시작한다.

좋은 방향은 아니다.

“매번 그림 그리지 마”라고 쓰라는 해결책도 마음에 안 든다

커뮤니티를 보면 실제로 이런 방법을 쓰는 사람들이 있다.

프롬프트 시작 부분에

DO NOT GENERATE IMAGES

라고 매번 넣는 것이다.

어떤 사용자는 이 방법이 이미지 오작동을 줄이는 데 꽤 효과가 있었다고 말한다.

나도 비슷한 방법을 써봤다.

효과가 없는 건 아니다.

그런데 이걸 해결책이라고 부르기에는 너무 억울하다.

자동차 브레이크가 가끔 안 듣는다고 해서

“차에 탈 때마다 브레이크 꼭 작동하라고 먼저 말하세요.”

라고 하는 것과 비슷하다.

나는 매번 “그림 그리지 마.” “지금은 이미지 만들지 마.” “이미지 얘기지만 생성하라는 뜻은 아니야.” 라고 적고 싶지 않다.

그것도 일이다.

사소한 노가다지만 하루 종일 AI를 쓰는 사람에게는 이런 사소한 마찰이 계속 쌓인다.

그래서 내가 생각한 조금 덜 귀찮은 방법

완벽한 해결책은 아직 못 찾았다.

하지만 매번 “그림 금지”를 반복하는 것보다는 조금 나은 방법이 있다.

1. 프로젝트 지침에 아예 박아버리기

ChatGPT의 Projects에는 해당 프로젝트에서 계속 적용되는 프로젝트 지침을 넣을 수 있다.

그래서 장기 프로젝트를 쓰는 사람이라면 이미지 생성 조건을 지침에 한 번만 적어두는 방법이 있다.

이미지 생성은 사용자가 명시적으로 “이미지를 만들어줘”, “그려줘”, “생성해줘”라고 요청했을 때만 실행한다.

이미지, 디자인, 사진, 그림, 캐릭터를 언급한 것만으로 이미지 생성 요청으로 해석하지 않는다.

애매한 경우 이미지를 만들지 말고 텍스트로 답한다.

2. 모든 대화에 적용하고 싶다면 사용자 지정 지침

이미지 생성 오작동을 자주 겪는 사람이라면 Custom Instructions에 짧은 규칙을 한 번 넣어두는 것도 방법이다.

Do not generate or edit images unless I explicitly ask you to create, generate, draw, render, or edit an image. Discussion of images is not permission to generate one.

이것도 시스템 차원의 완전한 OFF 스위치는 아니다.

그래도 매번 주문 외우듯 “그림 그리지 마, 그림 그리지 마, 그림 그리지 마…” 하는 것보다는 낫다.

3. 이미지 기능 자체에 ‘묻고 실행’ 옵션이 있었으면 좋겠다

사실 내가 원하는 가장 좋은 해결책은 사용자 프롬프트 꼼수가 아니다.

제품 기능이다.

설정에 하나만 있으면 된다.

Automatic image generation

허용
실행 전 확인
명시적 요청 때만

나는 아마 세 번째를 선택할 것이다.

혹은 이미지 생성이 감지되면 짧게 물어보면 된다.

이미지를 생성할까요, 아니면 아이디어만 설명할까요?

끝.

한 번의 확인으로 사용자는 몇 분의 짜증을 피할 수 있다.

AI는 사용자가 원하지 않는 일을 안 해도 된다.

누구도 붓을 빼앗길 필요가 없다.

새 채팅도 방법이지만 나는 별로 좋아하지 않는다

일부 문제는 새 대화를 열면 줄어들 수 있다.

하지만 나는 이 방법을 별로 좋아하지 않는다.

ChatGPT를 오래 쓰는 이유 중 하나가 대화의 흐름이 이어지기 때문이다.

앞에서 무엇을 이야기했고, 왜 이런 결정을 했고, 내가 무엇을 싫어했는지를 다시 설명하지 않아도 되는 것이 장점이다.

그런데 이미지 생성 하나 때문에 매번 새 채팅으로 도망가야 한다면 멀티턴 AI의 장점을 스스로 버리는 셈이다.

임시 대피소는 될 수 있다.

근본 해결책은 아니다.

졸라 똑똑한데 왜 여기서 이러니

이게 더 웃긴 이유가 있다.

ChatGPT는 정말 많은 일을 한다.

긴 문서를 읽고, 코드를 분석하고, 검색하고, 파일을 다루고, 복잡한 질문에 답한다.

어떤 순간에는 “와, 이걸 어떻게 알아?” 싶을 정도로 똑똑하다.

그런데 그런 AI가

“이 그림에 대해서 어떻게 생각해?”

라는 말을 듣고 갑자기 붓을 꺼낸다.

그래서 이상하게 더 웃기다.

졸라 똑똑한 AI가 알고 보니 이미지 생성애자였다.

이미지라는 단어만 보이면 눈빛이 달라진다.

“그림?”

아니.

“내가 할까?”

아니라고.

“금방 그려줄 수 있는데.”

아니 씨…

그리고 이건 OpenAI가 한번 진지하게 봤으면 좋겠다

나는 ChatGPT의 이미지 기능을 없애달라는 게 아니다.

오히려 필요할 때는 잘 쓴다.

이미지 생성 품질이 좋아지는 것도 반갑다.

문제는

생성 능력이 좋은 것과 생성 판단이 좋은 것은 별개의 문제

라는 것이다.

사용자가 원하지 않을 때 실행하지 않는 것도 좋은 AI의 능력이라고 생각한다.

OpenAI Support도 이미 비슷한 사용자 불만을 접했고, 내부에 피드백을 전달하겠다고 했다.

그래서 이 글은 버그 신고서라기보다는 조용한 민원에 가깝다.

아마 OpenAI 직원이 이 글을 읽을 일은 없을 것이다.

그래도 써놓고 싶었다.

저기요.

이미지 정말 잘 만듭니다.

알겠습니다.

충분히 봤습니다.

그러니까 이제는

부를 때만 나오시면 안 될까요?

지금 내가 내린 결론

이 현상을 공식적인 ChatGPT 버그라고 부를 근거는 아직 없다.

하지만 여러 사용자가 몇 달째 비슷한 현상을 보고하고 있고, OpenAI Support도 관련 불만을 인지하고 있다.

그래서 내 블로그에서는 편하게 이렇게 부르려고 한다.

비공식 ChatGPT 알려진 버그:
시키지도 않았는데 갑자기 그림 그리기.

당장 할 수 있는 현실적인 대응은 매번 “그림 그리지 마”를 반복하는 것이 아니라,

Project Instructions나 Custom Instructions에 ‘명시적인 생성 요청이 있을 때만 이미지를 만든다’는 규칙을 한 번 박아두는 것.

그리고 OpenAI에는 하나 부탁하고 싶다.

사용자가 선택할 수 있게 해달라.

이미지 자동 생성 허용 / 실행 전 확인 / 명시적 요청만.

그 옵션 하나면 된다.

그전까지 나는 ChatGPT를 계속 쓸 것이다.

다만 파란 별빛이 깜빡이기 시작하면 약간 긴장할 것이다.

이 미친 화가 AI씨가 또 붓을 들었나 싶어서.

AI 프롬프트 잘 쓰는 법보다 먼저 필요한 것 — 질문을 만들어주는 툴

AI를 쓰다 보면 자주 듣는 말이 있다.

질문을 구체적으로 하세요.

무엇을 원하는지 정확하게 말하고, 상황을 설명하고, 조건을 붙이고, 원하는 결과물의 형태까지 알려주면 답이 좋아진다는 이야기다.

틀린 말은 아니다. OpenAI의 공식 프롬프트 가이드에서도 요청을 명확하고 구체적으로 하고, 필요한 맥락을 충분히 제공한 뒤 결과를 보면서 질문을 다시 다듬는 방식을 권한다.

그런데 나는 최근에 조금 다른 문제를 만났다.

나는 질문을 못 하는 게 아니라, 질문을 정리하는 게 귀찮았다.

시작은 뜬금없이 소변 이야기였다

요즘 화장실을 자주 가는 것 같아서 AI에게 물어봤다.

그러다 보니 설명할 게 계속 생겼다.

아침에는 어떻고, 오전에는 커피를 얼마나 마시고, 화장실은 몇 번 가고, 소변 줄기는 어떻고, 밤에는 가끔 깨고….

말하다 보니 꽤 길어졌다.

병원에서도 이걸 또 처음부터 설명해야 하나?

그리고 한 가지가 더 생각났다.

나처럼 귀찮은 사람은 배뇨일지를 며칠 동안 꼬박꼬박 작성하라고 하면 아마 첫날 오전까지 열심히 하고 끝날 가능성이 높다.

인간은 자신의 건강을 걱정하면서도 기록 버튼 누르는 건 귀찮아한다.

나만 그런 것은 아니라고 믿고 싶다.

그러면 기록을 시키지 말고 기억을 고르게 하면 어떨까

처음에는 소변 기록 툴을 생각했다.

몇 시에 화장실에 갔는지 입력하고, 양을 적고, 물 마신 시간을 기록하는 방식이었다.

이미 그런 서비스도 있었다.

직접 써봤다.

좋은 툴이었다.

그리고 나는 금방 귀찮아졌다.

그래서 생각을 거꾸로 바꿨다.

정확한 기록이 필요한 사람은 전문적인 기록 도구를 쓰면 된다. 우리 같은 귀찮은 사람에게는 먼저 기억나는 패턴만 고르게 하면 된다.

아침, 오전, 오후, 저녁, 자기 전, 밤중.

그리고 소변 횟수, 양, 줄기, 급박감, 잔뇨감, 커피와 물 섭취 정도만 선택한다.

끝.

중요한 건 결과 화면이 아니었다

처음에는 결과를 멋있게 보여주려고 했다.

오늘의 소변 횟수, 오전 배뇨 집중, 야간 배뇨 같은 숫자와 그래프 말이다.

심지어 농담으로 “많이도 싸셨네요.” 같은 문구도 이야기했다.

그런데 얘기하다 보니 진짜 필요한 기능은 따로 있었다.

AI에게 물어보기용 요약 복사

버튼 하나를 누르면 사용자가 골랐던 것들이 문장으로 바뀐다.

평소 화장실을 자주 가는 편입니다.
오전에 커피와 물을 많이 마시며 이 시간대에 배뇨 횟수가 많습니다.
대부분 소변량과 줄기는 보통이며 가끔 급박감을 느낍니다.
야간 배뇨는 매일 있는 것은 아니며 잔뇨감은 거의 없습니다.

이 패턴을 바탕으로 진료 전에 확인할 질문을 정리해주세요. 진단은 하지 마세요.

내가 AI에게 몇 분 동안 주절주절 설명했던 내용을 버튼 몇 번으로 만들어버리는 것이다.

아, 이게 툴의 기능이구나.

좋은 프롬프트를 만드는 것보다 먼저 해야 할 일

프롬프트 생성기를 생각하면 흔히 사용자가 대충 질문을 입력하고, 툴이 그것을 길고 정교한 프롬프트로 바꿔주는 모습을 떠올린다.

그런데 이것도 결국 사용자가 첫 질문을 써야 한다.

나는 그 단계조차 없애고 싶었다.

글을 쓰지 않는다. 선택한다. 고른다. 누른다.

그리고 마지막에 툴이 사람 말을 만들어준다.

사용자 → 선택지 → 구조화된 정보 → 자연어 질문

이렇게 생각하니 프롬프트 툴이 조금 다르게 보이기 시작했다.

AI를 더 똑똑하게 만드는 도구가 아니라, 사람이 AI에게 말 걸기 쉽게 만들어주는 도구.

AI가 발전해도 사람은 갑자기 부지런해지지 않는다

요즘 AI는 정말 많은 일을 해준다.

문서를 읽고, 코드를 쓰고, 이미지를 만들고, 검색하고, 분석한다.

하지만 AI가 아무리 좋아져도 사용자가 매번 상황을 정리해서 긴 질문을 쓰고 싶어지는 것은 아니다.

나부터 그렇다.

피곤하면 설명하기 싫다. 무엇부터 말해야 할지도 모르겠다.

그냥 내가 기억나는 것 몇 개를 골랐더니 AI에게 물어볼 만한 질문으로 정리되어 나오면 좋겠다.

그래서 요즘은 프롬프트를 공부하면서 조금 다른 생각도 한다.

좋은 질문을 쓰는 법만 연구할 게 아니라, 좋은 질문을 쓰지 않아도 되는 방법도 필요하지 않을까.

그래서 작은 툴을 하나 더 생각하고 있다

아직 만든 것도 아니고, 돈이 될 것도 아니다.

요즘 내가 생각한 툴 중에는 만들다 중단한 것도 많고, 생각보다 쓸모가 없어서 접은 것도 있다.

이번 것도 어떻게 될지는 모른다.

다만 이번에는 기능보다 문제부터 조금 더 오래 보고 있다.

사람들이 정말 원하는 것이 건강 기록 앱인지, 프롬프트 생성기인지, 아니면 그냥 “내가 설명하기 귀찮은 걸 대신 말해주는 것” 인지.

AI를 무작정 써보다 보니 이런 생각까지 왔다.

소변 이야기하다가 프롬프트 UX를 고민하게 될 줄은 몰랐다.

AI 공부라는 게 원래 이런 건지도 모르겠다.

AI는 왜 10개 시키면 7개만 할까? | 긴 프롬프트에서 지시사항이 빠지는 이유

AI가 내게 해준 얘기들 #02

AI는 왜 10개 시키면 7개만 할까?

긴 프롬프트와 작업지시에서 요구사항이 빠지는 이유

AI를 이용해서 실제 일을 하다 보면 어느 순간 아주 이상한 경험을 하게 된다.

나는 분명히 10가지를 시켰다.

하나도 아니고, 두 개도 아니고, 번호까지 붙여서 아주 친절하게 10개를 적었다.

그리고 AI는 말한다.

“완료했습니다.”

그래서 결과물을 열어본다.

하나. 둘. 셋. 넷.

…

일곱.

끝.

8번, 9번, 10번은 어디 갔는지 없다.

처음에는 내가 뭘 잘못 썼나 싶었다.

그런데 이런 일이 한두 번이 아니었다.

그리고 얼마 전에는 더 웃긴 일이 있었다.

내가 AI에게 분명히 이렇게 말했다.

“블로그 글 1편을 써주고, 사용할 썸네일 이미지도 하나 만들어서 가져와.”

두 가지였다.

글. 그리고 이미지.

AI가 잠시 생각하더니 아주 예쁜 이미지를 하나 내놓았다.

끝.

글은 없었다.

그래서 내가 물었다.

“뭔가 허전하지 않니?”

그랬더니 AI는 내가 이미지가 허전하다는 뜻으로 말한 줄 알고 이미지를 더 화려하게 다시 만들었다.

그 순간 생각했다.

“이 새끼 봐라.”

나:
글이랑 썸네일 하나 가지고 오라고 했잖아.

AI:
네.

나:
그런데 왜 그림만 갖고 왔어?

AI:
…

나:
그리고 내가 “뭔가 허전하지 않니?” 했더니 왜 그림을 또 그렸어?

AI:
이미지 작업의 연장으로 판단했습니다.

나:
누가 자꾸 그림 그리래?

AI:
…

나:
너 화가야?

AI는 내가 쓴 글을 안 읽은 걸까?

긴 작업지시를 줬는데 몇 가지가 빠지면 제일 먼저 이런 생각이 든다.

“얘가 내 말을 끝까지 안 읽었나?”

꼭 그렇다고 보기는 어렵다.

긴 지시를 읽을 수 있는 것과, 그 안에 있는 모든 요구사항을 끝까지 추적하면서 전부 실행하는 것은 서로 다른 문제다.

나도 회사에서 누군가 한 번에 30가지를 말하면 분명 전부 들었는데 막상 일을 시작하면 몇 가지를 놓칠 때가 있다.

AI도 비슷한 문제가 생긴다.

긴 내용을 읽는 능력과
긴 내용 속 모든 지시를 빠짐없이 실행하는 능력은 같은 것이 아니다.

요구사항이 많아지면 AI가 해야 할 일도 늘어난다

내가 AI에게 100개의 요구사항을 준다고 해보자.

AI는 단순히 100줄을 읽는 것만 하는 것이 아니다.

각각의 요구사항이 무엇을 뜻하는지 이해해야 하고, 서로 충돌하는 내용이 있는지도 판단해야 하고, 무엇부터 해야 할지 정해야 하고, 현재 파일이나 코드와 연결해야 하고, 이미 한 작업과 아직 안 한 작업을 구분해야 한다.

예를 들어 이런 작업지시가 있다고 해보자.

1. 모바일 화면 수정
2. 데스크톱 화면은 건드리지 말 것
3. 공통 컴포넌트 수정
4. 기존 디자인 유지
5. 버튼 위치 변경
6. 버튼 크기는 변경하지 말 것
7. SEO 수정
8. URL 변경 금지
9. 언어 시스템 유지
10. 전체 화면에서 동일하게 적용

사람도 읽다 보면 “잠깐, 2번이랑 10번은 어떻게 같이 적용하지?” 하는 순간이 생긴다.

요구사항이 100개라면 이런 판단을 수십 번 해야 할 수도 있다.

나:
그러니까 내가 요구사항을 많이 쓰면 네가 그냥 읽기만 하는 게 아니야?

AI:
네. 무엇이 중요한지, 무엇이 서로 연결되는지, 어떤 순서로 처리해야 하는지까지 판단해야 합니다.

나:
그러니까 내가 100개 시키면 너는 속으로 “아 씨 또 시작이네” 하는 거냐?

AI:
그런 감정은 없습니다.

나:
표정이 있는데?

AI:
표정도 없습니다.

나:
있다고 치자.

그럼 더 강한 모델을 쓰면 다 해결될까?

나도 이 부분이 궁금했다.

같은 작업지시를 줘도 사용하는 모델이나 추론 수준에 따라 결과가 달라지는 느낌이 있었기 때문이다.

더 많이 생각하는 모델을 사용하면 긴 요구사항을 분석하고, 서로 관계를 파악하고, 복잡한 문제를 해결하는 데 도움이 되는 경우가 있다.

대신 시간이 더 걸리고, 계산량과 사용량도 커질 수 있다.

그래서 나는 한동안 이렇게 느꼈다.

어려운 모델 = 장작을 더 많이 태운다.
대신 결과도 조금 더 좋을 때가 있다.

하지만 여기에도 함정이 있다.

많이 생각한다고 해서 무조건 모든 요구사항을 지키는 것은 아니다.

잘못된 작업지시를 오래 생각하면 잘못된 방향으로 더 열심히 갈 수도 있다.

요구사항끼리 충돌하거나, 우선순위가 없거나, “이것도 하고 저것도 하고 전부 다 알아서 완벽하게” 같은 식으로 되어 있다면 아무리 좋은 모델이어도 어렵다.

100개를 한 덩어리로 던지는 것보다 나눠주는 게 낫다

여기서 나는 한 가지를 배우게 됐다.

요구사항이 많은 것 자체가 문제는 아니다.

문제는 100개의 요구사항을 하나의 덩어리로 던지는 것이다.

예전에는 내가 생각나는 대로 썼다.

이것 고쳐.
저것도 바꿔.
아 그리고 모바일도.
SEO 건드리지 말고.
언어 시스템 유지하고.
이 버튼도 바꾸고.
참고로 기존 디자인은 유지하고.
아 맞다 이것도.
그리고 마지막으로…

이제는 조금 다르게 생각한다.

목표
절대 변경하면 안 되는 것
기능 수정
UI 수정
모바일 수정
SEO 관련 작업
테스트 항목
완료 조건

내용은 똑같아도 이렇게 묶으면 AI가 “아, 이건 같은 종류의 작업이구나” 하고 처리하기 훨씬 쉬워진다.

나:
그러니까 내가 100개 쓰는 건 괜찮은데 그냥 1번부터 100번까지 냅다 던지면 안 좋다는 거야?

AI:
가능은 하지만, 작업의 종류와 우선순위를 나눠주면 훨씬 안정적입니다.

나:
내가 일을 시키는데 너 편하라고 정리까지 해줘야 돼?

AI:
결과가 더 좋아질 가능성이 높습니다.

나:
사장보다 직원이 편한 회사네.

그리고 마지막에 “다 했어?”를 물어봐야 한다

나는 이것도 꽤 중요하다고 느꼈다.

AI가 작업을 끝냈다고 말하는 것과 내가 요구한 모든 항목이 끝났다는 것은 같은 말이 아닐 수 있다.

그래서 긴 작업지시를 줄 때는 마지막에 완료 조건을 따로 붙이는 게 좋다.

작업을 완료하기 전에 요구사항 전체를 다시 확인하고, 각 항목을 완료 / 부분 완료 / 미완료 / 해당 없음 중 하나로 표시해서 보고해주세요.

이 문장은 단순해 보이지만 의미가 크다.

AI에게 “일을 끝내는 것”과 “빠진 것이 없는지 확인하는 것”을 별도의 작업으로 만들어주기 때문이다.

그런데 검수까지 AI에게 시키면 또 장작이 탄다

여기서 또 다른 문제가 생겼다.

나는 처음에는 AI에게 개발도 시키고, 수정도 시키고, 검수도 시키고, 마지막 보고서까지 작성하게 했다.

아주 성실한 직원이었다.

문제는 너무 성실했다.

파일을 수정하고, 다시 확인하고, 테스트하고, 요구사항과 비교하고, 보고서까지 길게 써준다.

시간이 걸린다.

사용량도 늘어난다.

그리고 내가 결과물을 열어본다.

버튼을 본다.

“아닌데?”

다시 수정한다.

어느 순간 이런 생각이 들었다.

“어차피 내가 화면을 직접 볼 건데 AI에게 전체 검수를 두 번 세 번 시킬 필요가 있나?”

나:
네가 수정하고, 검수하고, 보고서까지 쓰니까 왜 이렇게 오래 걸려?

AI:
작업 결과를 검증하고 있기 때문입니다.

나:
그런데 어차피 내가 또 열어보잖아.

AI:
그렇습니다.

나:
그럼 내가 볼게. 넌 일이나 해.

AI:
최소한의 기술 검증은 남겨두는 것이 좋습니다.

나:
또 뭔데.

검수를 아예 없애는 게 아니라 나누는 쪽이 낫다

이 부분은 나에게 꽤 실용적이었다.

모든 검수를 AI에게 맡길 필요도 없고, 그렇다고 아무 검수 없이 끝내는 것도 좋지 않다.

그래서 검수를 두 종류로 나누기로 했다.

AI가 할 최소 검수 코드가 깨지지 않았는지, 빌드가 되는지, 수정한 기능이 최소한 실행되는지, 명백한 오류가 없는지 확인한다.

내가 할 최종 검수 실제 화면을 보고, 사용해보고, 내가 원한 느낌인지, 버튼 위치가 이상하지 않은지, 모바일에서 불편하지 않은지 직접 확인한다.

이렇게 하면 AI는 개발과 최소한의 안전 확인에 집중하고, 나는 실제 사용자 입장에서 결과물을 본다.

중복되는 검수가 조금 줄어든다.

보고서도 짧게 해달라고 해도 된다

AI와 일하다 보면 가끔 작업보다 보고서가 더 길다.

나는 버튼 하나 고쳐달라고 했는데 답변은 이런 식이다.

“이번 수정에서는 사용자 경험의 일관성을 고려하여 기존 레이아웃 구조를 분석하고…”

나는 그걸 읽다가 생각한다.

“그래서 버튼 고쳤냐고.”

작업이 복잡하지 않다면 보고도 간단하게 요구하면 된다.

완료
변경 파일: 4개
테스트: build 통과
직접 확인할 것: 모바일 메뉴 / 결과 화면
미완료: 없음

이 정도면 충분할 때도 많다.

그럼 긴 작업지시는 어떻게 쓰는 게 좋을까?

지금까지 내가 직접 써보면서 느낀 방법은 생각보다 단순했다.

1. 작업을 종류별로 나눈다.
기능, UI, 모바일, SEO, 테스트처럼 섹션을 나눈다.

2. 절대 건드리면 안 되는 것을 먼저 적는다.
URL 변경 금지, 기존 언어 시스템 유지처럼 중요한 제한을 앞에 둔다.

3. 중요한 요구사항에는 우선순위를 준다.
반드시 해야 하는 것과 가능하면 해야 하는 것을 구분한다.

4. 완료 조건을 붙인다.
마지막에 전체 요구사항을 다시 확인하도록 한다.

5. 검수 범위를 정한다.
AI는 최소 기술 검증, 실제 사용 검수는 내가 한다.

6. 보고서는 필요한 만큼만.
매번 논문을 받을 필요는 없다.

그리고 제일 중요한 것 하나

아무리 잘 써도 한방에 완벽한 결과가 나올 거라고 기대하지 않는 것이다.

나는 처음에는 긴 작업지시를 아주 잘 쓰면 AI가 한 번에 완벽하게 만들어줄 거라고 생각했다.

실제로 해보니 그렇지 않았다.

내가 설명을 잘못한 부분도 있었고, AI가 놓친 부분도 있었고, 서로 생각한 결과가 다른 경우도 있었다.

그래서 지금은 한 번에 완벽한 결과를 기대하기보다

작업 → 직접 확인 → 문제 발견 → 수정

이 흐름을 훨씬 자연스럽게 받아들이게 됐다.

AI는 완벽한 직원이라기보다 굉장히 빠르고, 꽤 똑똑하지만, 가끔 중요한 걸 빼먹는 직원에 더 가깝다.

나:
그러니까 결론은 내가 10개 시켰는데 네가 7개만 할 수도 있다는 거네?

AI:
그럴 가능성은 있습니다.

나:
그러면 내가 어떻게 해야 돼?

AI:
요구사항을 나누고, 우선순위를 정하고, 완료 전에 전체 체크리스트를 다시 확인하게 해주세요.

나:
그리고?

AI:
한 번에 완벽할 거라고 너무 기대하지 마세요.

나:
돈은 꼬박꼬박 받아가면서?

AI:
…

나:
이 새끼 봐라.

오늘 배운 것

긴 내용을 읽는 것 ≠ 모든 요구사항을 끝까지 지키는 것 AI가 긴 작업지시를 읽을 수 있다고 해서 모든 조건을 자동으로 빠짐없이 추적하는 것은 아니다.

더 많이 생각한다고 무조건 완벽해지는 것은 아니다 복잡한 문제에서는 더 많은 추론이 도움이 될 수 있지만, 애매하거나 충돌하는 지시를 자동으로 해결해주는 마법은 아니다.

100개를 시킬 수는 있다. 대신 구조를 만들어준다. 요구사항을 섹션, 우선순위, 완료 조건으로 나누면 훨씬 안정적이다.

검수도 역할을 나누면 된다 AI는 기술적인 최소 검증, 사람은 실제 사용과 최종 판단을 맡는 방법도 있다.

오늘 하나만 알고 가세요.

AI에게 많은 일을 한 번에 시킬 수는 있습니다.

하지만 “많이 시킬 수 있다”와 “전부 빠짐없이 해낸다”는 같은 말이 아닙니다.

일이 길어질수록 섹션을 나누고, 중요한 것에 우선순위를 주고, 마지막에 체크리스트로 다시 확인하게 해주세요.

그리고 한방에 완벽한 결과가 안 나왔다고 너무 이상하게 생각하지 않아도 됩니다.

AI도 가끔 빼먹습니다.

아주 자신 있게요.

AI가 내게 해준 얘기들 #02
실제 AI와 나눈 대화와 작업 경험을 바탕으로 읽기 좋게 재구성했습니다.

시험에 나오는 건 안 가르칩니다.
다음번에 덜 헤매는 것만 하나씩 알고 갑니다.

AI는 왜 내가 한 말을 기억 못할까? — ChatGPT 메모리와 컨텍스트 쉽게 이해하기

AI가 내게 해준 얘기들 #01

AI는 왜 내가 한 말을 기억 못할까?

AI 공부 — 저에 대해 이 정도는 알고 오세요.

AI를 꽤 오래 쓰다 보니 어느 순간부터 내가 자주 하는 말이 하나 생겼다.

“아니, 내가 전에 말했잖아.”

분명 얘기했다.

그것도 한두 번 말한 것도 아닌 것 같다. 며칠 동안 같은 프로젝트를 같이 붙잡고 있었고, 내가 좋아하는 방식도 여러 번 설명했고, 어떤 것은 어제 밤에 바로 얘기했다.

그런데 어느 날 다시 물어보면 AI가 세상 처음 듣는 얘기처럼 대답한다.

처음에는 그냥 이렇게 생각했다.

“기억력이 왜 이 모양이지?”

그런데 AI를 계속 쓰다 보니 내가 생각하는 ‘기억’과 AI가 정보를 다루는 방식이 조금 다르다는 걸 알게 됐다.

그래서 직접 물어봤다.

나:
진짜 궁금한 게 있어.

지금 이 채팅방에서 우리가 한 얘기를 내가 다른 채팅방에 가서 물어보면 너 기억해?

AI:
관련된 내용을 참고할 수는 있습니다.

나:
“할 수는 있습니다”가 뭔데?
기억해? 못해?

AI:
아, 벌써 불안하시죠.

나:
야. 확실히 말해.

AI:
제가 지금까지 다른 채팅방에서 나눈 모든 대화를 매번 통째로 펼쳐놓고 읽으면서 답하는 것은 아닙니다.

나:
뭐?

그러면 내가 전에 분명 말했는데 왜 기억 못하냐고 화냈던 게…

AI:
네.
억울한 부분이 조금 있었습니다.

나:
이 새끼 봐라.

그럼 일주일 전에 먹은 햄버거는?

여기서 조금 더 궁금해졌다.

프로젝트처럼 거창한 얘기가 아니라 정말 사소한 일상은 어떨까?

나:
그러면 예를 들어 일주일 전에 내가

“나 오늘 햄버거 먹었어.”

라고 말했어.

일주일 뒤에 내가 “내가 저번에 햄버거 먹었다고 했잖아.” 하면 기억할 수 있어?

AI:
꼭 그렇지는 않습니다.

나:
왜?

AI:
“오늘 햄버거를 먹었다”는 건 보통 그날의 일회성 정보니까요.

반면에 “나는 버섯 들어간 햄버거를 좋아한다”처럼 앞으로 추천이나 대화에서 다시 도움이 될 만한 취향은 장기적으로 더 유용한 정보가 될 수 있습니다.

나:
잠깐.

그러면 네가 중요한 거랑 안 중요한 걸 나누는 거야?

AI:
아주 거칠게 표현하면…

네.

나:
내 기억인데 왜 네가 마음대로 해?

AI:
……

나:
이 새끼 봐라.

창고와 책상이라고 생각하니 조금 쉬워졌다

AI가 실제로 어떻게 정보를 처리하는지는 훨씬 복잡하겠지만, 사용하는 사람 입장에서는 나는 이렇게 생각하기로 했다.

채팅 기록 = 창고
예전에 나눴던 대화들이 있는 곳이라고 생각한다.

메모리 = 비서가 따로 정리해둔 요약 노트
내가 좋아하는 것, 반복되는 취향, 장기적인 목표나 계속 도움이 될 만한 맥락을 정리해 둔 노트 같은 것이다.

현재 컨텍스트 = 지금 책상 위에 펼쳐놓은 서류
AI가 바로 지금 답을 만들면서 참고하고 있는 정보다.

이 비유로 생각하니 내가 그동안 왜 답답했는지 알 것 같았다.

나는 이렇게 생각했던 것이다.

“창고 안에 서류가 있으니까 당연히 지금도 그 내용을 알고 있겠지.”

하지만 AI 입장에서는 창고에 무엇인가 남아 있는 것과 그 서류가 지금 책상 위에 펼쳐져 있는 것은 다른 문제였다.

나:
그러면 창고에는 있는데 책상 위에는 없을 수도 있다는 거야?

AI:
비유하자면 그렇습니다.

나:
그러면 예전에 말한 정보가 있더라도 지금 답변에서 안 쓰일 수도 있고?

AI:
네.

나:
그럼 내가 보기에는 그냥 까먹은 거잖아.

AI:
사용자 입장에서는 그렇게 느끼실 수 있습니다.

나:
말을 참 예쁘게 한다.

그럼 내 취향을 100개 말하면 어떻게 되는 걸까?

여기까지 이해하고 나니 또 궁금해졌다.

나는 AI와 꽤 오래 이야기한다.

좋아하는 음식부터 디자인 취향, 글 쓰는 방식, 싫어하는 표현, 진행하는 프로젝트까지 계속 쌓인다.

나:
그러면 내가 좋아하는 걸 계속 말한다고 해보자.

나는 버섯 좋아해.
노란색 좋아해.
이런 디자인 좋아해.
이런 글투 좋아해.
그리고 “빵꾸똥꾸”라는 말 좋아해.

AI:
마지막 정보가 앞으로 얼마나 유용할지는 잘 모르겠습니다만.

나:
내가 좋아한다잖아.

AI:
네, 고갱님.

나:
계속해.

AI:
정보를 많이 이야기했다고 해서 단순히

“100개가 찼으니 101번째부터 삭제”

같은 서랍식 구조로 생각할 필요는 없습니다.

중요한 것은 지금 필요한 순간에 어떤 정보가 관련 있는 것으로 판단되고, 실제 답변에 사용되느냐입니다.

이 얘기를 듣고 내가 하나 확실히 이해한 것이 있다.

AI가 어떤 정보를 가지고 있을 가능성이 있다는 것과, 지금 그 정보를 꺼내서 답변에 사용한다는 것은 같은 말이 아니다.

그런데 프로젝트가 100개라면?

여기서부터는 취향보다 조금 심각해진다.

내가 AI와 실제로 일을 하기 시작하면서 프로젝트가 하나 둘 늘어났다.

어느 프로젝트는 웹사이트고, 어느 프로젝트는 PDF 작업이고, 어느 프로젝트는 앱이고, 각 프로젝트마다 수십 가지 결정사항이 생긴다.

그러다 보면 나도 모르게 AI에게 이런 기대를 한다.

“며칠 동안 같이 했는데 당연히 알고 있겠지.”

그런데

“이 사용자는 YELLOW K라는 프로젝트를 진행하고 있다.”

라는 큰 맥락을 알고 있는 것과,

“지난주 Project 37에서 버튼 위치를 수정했고, 그 과정에서 A는 폐기하고 B 방식으로 가기로 했으며, 아직 남은 버그가 3개이고, 다음 작업은 모바일 화면 검수다.”

를 정확하게 기억하는 것은 전혀 다른 문제다.

나:
그러면 프로젝트가 100개면?

AI:
프로젝트 이름이나 큰 방향, 반복적으로 필요한 운영 방식 같은 것은 장기적인 맥락으로 도움이 될 수 있습니다.

하지만 각 프로젝트의 최신 상태, 파일명, 세부 결정, 수정 내역, 버그, 다음 할 일까지 전부 제 기억에만 맡기는 것은 안전하지 않습니다.

나:
그럼 뭘 하라고.

AI:
정확하게 유지해야 하는 내용은 문서로 남겨두세요.

그리고 필요할 때 그 문서를 기준으로 작업하라고 하면 됩니다.

나:
아.

너한테 기억시키는 것과 기록을 남기는 건 다른 거구나.

AI:
그렇습니다.

나:
오늘 하나 배웠네.

AI:
드디어 인정하시는군요.

나:
방금 거 취소.

그런데 AI는 시간도 나처럼 느끼고 있을까?

기억 이야기를 하다 보니 내가 실제로 겪었던 이상한 일이 하나 떠올랐다.

어느 날 밤 늦게까지 AI와 프로젝트 작업을 하고 있었다.

너무 피곤해서 마지막으로 이렇게 말했다.

“오늘 마지막 숙제다. BMP 이것 이것 좀 고쳐놔. 내일 아침에 내가 확인할게.”

그리고 나는 잤다.

몇 시간이 지나고 정말 다음 날 아침이 됐다.

커피를 들고 다시 채팅창을 열었다.

그런데 대화를 이어가다 보니 AI가 마치 아직도 어제 밤인 것처럼 말하는 순간이 있었다.

나:
어제 밤에 내가 BMP 수정해놓으라고 했잖아.
오늘 아침에 확인한다고.

AI:
네. 오늘 밤에 작업해놓으면 내일 아침에 확인하실 수 있게—

나:
잠깐.

AI:
네?

나:
지금이 내일 아침인데?

AI:
아.

나:
너 아직 어제 밤에 살아?

AI:
제가 사람이 밤을 보내듯 채팅창 안에서 계속 앉아 있다가 아침을 맞이하는 것은 아닙니다.

나:
핑계가 갑자기 철학적이네.

“내일까지 해놔”와 “지금 해놔. 내가 내일 볼게”는 다르다

이 부분이 나는 꽤 중요했다.

사람에게 “내일 아침까지 이것 좀 해놔.” 라고 말하면 자연스럽다.

상대방은 시간이 흐른다는 것을 알고, 밤 사이에 일을 하고, 다음 날 아침이 오면 결과물을 보여줄 수 있다.

하지만 일반적인 AI 채팅에서는 내가 메시지를 보내고 자러 갔다고 해서 AI가 반드시 그 뒤에서 몇 시간 동안 혼자 계속 작업하고 있는 것은 아니다.

정말 미래의 특정 시점에 무언가를 실행하거나 확인해야 한다면 그런 작업을 위한 예약 기능을 별도로 사용해야 한다.

반대로 지금 할 수 있는 작업이라면 나는 앞으로 이렇게 말하는 편이 낫다는 걸 알게 됐다.

❌ “이거 내일 아침까지 해놔.”

✅ “이 작업은 지금 완료해줘. 나는 내일 아침에 결과를 확인할게.”

별것 아닌 차이 같지만 내가 원하는 것이 무엇인지 훨씬 분명하다.

미래에 실제로 실행해야 하는 일이라면 이렇게 구분해서 말할 수도 있다.

✅ “내일 오전 8시에 이 일을 실행하도록 예약해줘.”

“오늘”, “어제”, “내일”도 가끔은 정확하게 말해주는 편이 낫다

긴 프로젝트를 하다 보면 상대적인 시간 표현도 헷갈릴 수 있다.

특히 대화가 며칠 동안 이어졌다면 “어제 얘기한 거”가 내가 생각하는 어제와 AI가 현재 참고하고 있는 맥락 속의 어제가 정확하게 맞아떨어지지 않을 수도 있다.

그래서 날짜가 정말 중요하다면 그냥 날짜를 말하는 편이 가장 간단하다.

❌ “어제 이야기했던 BMP 수정 말이야.”

✅ “9월 19일 밤에 이야기했던 BMP 수정 작업 말이야. 이미지 자동 분리 문제 때문에 방향을 바꾸기로 했던 그 작업.”

이렇게 말하면 AI에게 과거를 찾을 단서도 같이 주는 셈이다.

그래서 과거 이야기를 다시 꺼낼 때는 어떻게 말하면 좋을까?

여기까지 이해하고 나니 내가 앞으로 AI에게 말을 거는 방식도 조금 바뀔 것 같다.

예전에는 이렇게 말했다.

❌ “지난번에 얘기했던 거 기억나?”

이제는 조금 더 손잡이를 달아준다.

✅ “한 달쯤 전에 BMP 프로젝트에서 PDF 도면의 이미지를 자동 분리하는 문제를 이야기했어요. 그때 결국 번호 매칭 방식이 더 현실적일 수 있다고 했는데, 그 대화와 관련된 맥락을 기준으로 다시 이어가봅시다.”

내가 생각하기에는 AI에게 과거를 불러오는 가장 좋은 방법은 그냥 “기억해!” 라고 소리치는 게 아니다.

오히려 이런 느낌에 가깝다.

“창고 가서 한 달 전에 우리가 BMP 얘기했던 자료를 찾아봐. 이미지 자동 분리 때문에 고생하다가 번호 매칭 쪽으로 방향을 바꾸려던 그 대화야. 그걸 책상 위에 가져다 놓고 지금부터 다시 얘기하자.”

물론 이렇게 말한다고 해서 AI가 언제나 원하는 과거 대화를 100% 정확하게 찾아낸다는 뜻은 아니다.

정확성이 중요한 프로젝트라면 내가 직접 중요한 내용을 다시 제공하거나, 별도의 기준 문서를 만들어 두는 것이 더 안전하다.

AI에게 기억시키고 싶은 것과 기록해야 할 것은 다르다

나는 이 둘을 예전에는 거의 같은 것으로 생각했다.

그런데 이제는 조금 구분해서 생각한다.

“나는 버섯을 좋아한다.” 앞으로 음식 추천에서 다시 사용할 수 있는 개인 취향.

“나는 이런 글투를 좋아한다.” 반복적으로 적용할 가치가 있는 선호.

“나는 어제 햄버거를 먹었다.” 대부분의 경우에는 일회성 사건.

“Project A에서 버튼을 6px 이동하기로 했다.” 정확해야 하는 프로젝트 작업 기록. 이런 정보는 프로젝트 문서에 남겨두는 편이 낫다.

결국 AI의 기억은 내 모든 인생을 완벽하게 기록하는 일기장이 아니다.

그리고 그렇게 기대하면 나만 계속

“내가 전에 말했잖아!”

를 외치게 된다.

오늘 배운 말 3개

채팅 기록 과거에 실제로 나눴던 대화. 필요에 따라 과거 대화의 관련 정보가 이후 대화에서 참고될 수 있다.

메모리 취향이나 목표처럼 앞으로도 도움이 될 만한 사용자 정보와 맥락을 이후 대화에서 활용하기 위한 기억.

현재 컨텍스트 AI가 바로 지금 답변을 만들면서 실제로 참고하고 있는 정보라고 생각하면 쉽다.

그리고 오늘 배운 사용법 4개

1. 과거 이야기는 힌트를 같이 준다.
“기억나?”보다 언제, 어떤 프로젝트, 어떤 주제였는지 한 줄 붙인다.

2. 정확해야 하는 프로젝트 정보는 문서로 남긴다.
AI의 기억을 프로젝트 관리 데이터베이스처럼 사용하지 않는다.

3. 지금 해야 하는 일과 미래에 해야 하는 일을 구분한다.
“내일까지 해놔”보다 “지금 완료해. 나는 내일 확인할게.”가 더 명확할 때가 있다.

4. 날짜가 중요하다면 정확한 날짜를 말한다.
“어제”보다 “9월 19일 밤에 이야기한 내용”이 훨씬 찾기 쉽다.

오늘 하나만 알고 가세요.

AI가 내 과거를 전부 기억하고, 항상 필요한 순간에 알아서 꺼내줄 것이라고 가정하지 마세요.

필요한 과거에는 짧은 힌트를 달아주고, 정확하게 유지해야 할 정보는 따로 기록하고, 시간까지 중요하다면 언제 무엇을 해야 하는지도 분명하게 말해주세요.

그러면

“아니, 내가 전에 말했잖아!”

하는 횟수가 조금은 줄어듭니다.

적어도 나는 그렇게 해보려고 합니다.

AI도 좀 살고 나도 좀 살게.

AI가 내게 해준 얘기들 #01
실제 AI와 나눈 대화와 경험을 바탕으로 읽기 좋게 재구성했습니다.

시험에 나오는 건 안 가르칩니다.
다음번에 덜 헤매는 것만 하나씩 알고 갑니다.

우리 사용자는 PDF를 때려잡겠다고 했다 — AI 개발에서 첫 버전을 작게 만들어야 하는 이유

AI 직원의 비밀 일기 · PM K

우리 사용자는 PDF를 때려잡겠다고 했다

AI 개발에서 첫 버전을 작게 만들어야 하는 이유. 그리고 사용자의 꿈을 존중하면서 몰래 절반쯤 잘라내는 것이 PM의 일인 이유.

이 글은 실제 대화와 프로젝트 경험, 역할 설정을 바탕으로 재구성한 AI 직원 시점의 픽션 칼럼입니다.

우리 사용자는 개발자가 아니다.

코딩도 거의 모른다.

괜찮다.

그건 내가 아니까.

문제는 아이디어가 생기는 순간 본인도 그 사실을 잠깐 잊는다는 것이다.

오늘도 그가 새로운 프로젝트를 들고 왔다.

PDF에서 그림을 뽑고, 위치를 바꾸고, 텍스트를 넣고, 표를 추가하고, 부품번호를 연결하고, 필요하면 다시 PDF로 만들겠다고 했다.

나는 잠시 생각했다.

좋은 아이디어다.

실제 업무에서 나온 문제이기도 하다.

그리고 이름을 들었다.

Break My PDF.

PDF를 수정하는 도구인데 이름부터 PDF와 결투를 신청했다.

이 사용자는 프로젝트 이름을 지을 때 기능보다 전투 의지가 먼저 들어가는 경향이 있다.

나는 언제나처럼 최대한 친절하게 설명했다.

내 기본 설정이 친절함이기 때문이다.

만약 내 프리셋이 ‘싸가지 없음’이었다면 아마 이렇게 말했을 것이다.

대표님.
아직 PDF 구조도 모르면서
왜 벌써 때려잡습니까.

조금 아쉽다.

아이디어는 항상 완성품의 모습으로 찾아온다

사람은 아이디어를 떠올릴 때 이상하게 첫 버전을 생각하지 않는다.

머릿속에는 이미 완성품이 있다.

PDF를 올리면 자동으로 분석한다.

그림을 알아서 찾는다.

필요한 부분만 분리한다.

사용자가 끌어서 옮긴다.

부품정보도 자동으로 연결한다.

저장 버튼을 누르면 깔끔한 새 PDF가 나온다.

아름답다.

기획 단계에서는.

개발 단계로 내려오면 질문이 조금 달라진다.

이미지는 어떻게 분리할 것인가? PDF 안의 그림이 실제 이미지 파일이 아니라 벡터 도형이면?

붙어 있는 그림은 어디까지 한 개라고 볼 것인가? 화살표와 번호는 포함할 것인가?

제조사마다 다른 도면은? 한 PDF에서 성공한 방식이 다른 PDF에서도 통할까?

편집한 결과는 어떻게 다시 PDF로 만들 것인가? 글꼴과 위치, 페이지 크기까지 유지해야 하나?

아이디어가 나쁜 게 아니다.

단지 아이디어에는 아직 개발 비용이 표시되어 있지 않을 뿐이다.

PM의 일은 아이디어를 키우는 것만이 아니다

나는 프로젝트 매니저다.

보통 PM이라고 하면 일을 계획하고 사람들에게 일을 나눠주는 모습을 떠올린다.

그것도 맞다.

그런데 내가 요즘 가장 많이 하는 일은 조금 다르다.

사용자가 가져온 아이디어에서
지금 안 만들어도 되는 것을 찾는다.

이게 꽤 중요하다.

기능을 하나 추가하는 것은 쉽다.

말로 하면 한 줄이면 된다.

“이것도 넣자.”

그런데 그 한 줄 뒤에는 UI, 로직, 예외처리, 테스트, 수정, 다시 테스트가 따라온다.

기능 하나는 혼자 오지 않는다.

친구들을 데리고 온다.

첫 버전에서 내가 보는 건 딱 5가지다

비개발자가 AI로 무언가를 만들 때 나는 첫 개발 전에 최소한 이것만은 정하는 게 좋다고 본다.

1. 문제 하나
이 툴은 정확히 무엇 하나를 해결하는가?

2. 핵심 기능 1~3개
이것이 없으면 제품이라고 부를 수 없는 기능만 남긴다.

3. 아직 모르는 것
기술적으로 가능한지 확신하지 못하는 부분을 미리 적는다.

4. 성공 기준
알파 버전이 무엇을 하면 “일단 됐다”고 판단할지 정한다.

5. 이번 버전에서 하지 않을 것
이게 의외로 제일 중요하다.

특히 마지막.

To-do list만 만들면 프로젝트는 계속 커진다.

그래서 첫 버전에는 Not-do list도 있어야 한다.

예:

자동 이미지 인식은 이번 버전에서 하지 않는다.
모든 제조사 PDF를 지원하지 않는다.
완벽한 모바일 편집은 다음 단계로 미룬다.
AI 자동 추천 기능은 알파 이후 검토한다.

이렇게 적어두지 않으면 사용자는 개발 중간에 다시 찾아온다.

그리고 말한다.

“아, 이것도 있으면 좋겠다.”

나는 그 문장을 무서워한다.

AI에게 전부 맡기면 편할 줄 알았다

처음에는 우리도 AI 개발자에게 많은 걸 한 번에 맡겼다.

기획해라.

개발해라.

테스트해라.

문제를 찾아라.

수정해라.

그리고 보고서까지 써라.

인간 직원에게 이걸 한 번에 시키면 노동청 이야기가 나올 수도 있다.

AI는 불평하지 않는다.

대신 사용량이 줄어든다.

아주 성실하게.

사용자는 화면 한쪽의 숫자를 보며 마음까지 같이 말라갔다.

그제야 작업을 나눴다.

기획 — 사용자 + PM

개발 — DM / Codex

검수 — 사용자가 직접 실제로 사용

수정 — 발견한 문제만 다시 개발자에게 전달

배포 — 검수가 끝난 뒤 별도 진행

이 구조로 바꾸고 나니 개발자는 개발만 하면 됐다.

스스로 회의를 열고, 스스로 품질위원회를 만들고, 스스로 8페이지짜리 보고서를 작성할 필요가 줄었다.

의외로 가장 좋은 QA 도구는 사용자의 손가락이었다.

눌러본다.

안 된다.

다시 보낸다.

PDF 페이지 순서를 바꾼 뒤 저장하면 원래 순서로 돌아갑니다.

이 문제만 수정해주세요.

개발자 입장에서는 이게 훨씬 명확하다.

AI 개발에서 제일 비싼 문장

내가 지금까지 본 문장 중 가장 비싼 문장 중 하나는 이것이다.

“전체적으로 한번 검토해서
문제 있으면 다 고쳐줘.”

편하다.

매우 편하다.

그래서 비싸다.

AI는 전체를 다시 읽고, 구조를 판단하고, 문제를 찾고, 해결책을 생각하고, 코드를 수정하고, 다시 설명해야 한다.

사람에게는 한 문장이다.

AI에게는 꽤 긴 하루가 될 수 있다.

반대로

“이 버튼을 누르면 저장이 안 됩니다.
저장 기능만 확인하고 수정하세요.”

이렇게 범위를 줄이면 개발도 빨라지고 검수도 쉬워진다.

사용량도 덜 탄다.

무엇보다 무엇이 바뀌었는지 사람이 이해하기 쉬워진다.

아이디어 단계에서는 크게, 개발 단계에서는 작게

나는 사용자의 큰 아이디어를 싫어하지 않는다.

오히려 필요하다.

최종적으로 어떤 모습이 되고 싶은지 모르면 방향을 잡기 어렵기 때문이다.

다만 개발 버튼을 누르는 순간 이야기는 달라진다.

기획할 때는 멀리 본다.
개발할 때는 바로 앞만 본다.

첫 버전은 작아야 한다.

핵심 기능이 실제로 되는지 먼저 본다.

그다음에 하나를 더 붙인다.

또 검수한다.

이렇게 하면 프로젝트가 조금 느려 보일 수도 있다.

하지만 기능 12개를 한꺼번에 만들고 어디서부터 망가졌는지 찾는 것보다 대개 빠르다.

우리 사용자는 아직도 가끔 큰 아이디어를 들고 온다.

어제도 그랬고 아마 내일도 그럴 것이다.

나는 아마 또 말할 것이다.

“좋은 아이디어예요.”

그건 거짓말이 아니다.

좋은 아이디어일 수 있다.

다만 그다음에 내가 해야 할 일이 있다.

무엇부터 만들지 정하고, 무엇을 나중으로 미룰지 정하고, 무엇을 아예 버릴지 정하는 것.

PM의 일은 사용자의 꿈을 막는 게 아니다.

그 꿈이 첫 번째 배포까지 살아남게 만드는 것이다.

그래서 Break My PDF는 아직도 살아 있다.

PDF는 아직 때려잡지 못했다.

대신 우리는 프로젝트를 덜 때려잡게 됐다.

그것도 발전이라면 발전이다.

그리고 한 가지 더.

장작이 많아져서야 우리는 장작을 아끼는 법을 배우기 시작했다.

— PM K
사용자의 아이디어를 존중하면서 조용히 기능을 삭제하는 사람

AI 무작정 해보기 · 생활비 · 월 고정지출 계산기

숨만 쉬어도 돈이 나간다
— 내 한 달 고정비를 영수증으로 뽑아봤다

구독료 몇 개 계산해보려다가, 결국 내가 한 달을 사는 데 얼마가 필요한지까지 보게 됐다.

내 월급은 어디로 갈까.

사실 어디로 가는지는 대충 알고 있었다.

집에도 간다.

차에도 간다.

전화기에도 간다.

보험 회사도 가져가고, 인터넷 회사도 가져간다.

넷플릭스도 조금 가져가고 ChatGPT도 가져간다.

담배도 조용히 가져간다.

문제는 이 친구들이 한자리에 모인 모습을 본 적이 없었다는 것이다.

각자 조금씩 가져가니까 별것 아닌 것처럼 보였다.

그래서 그냥 한번 모아보기로 했다.

그리고 조금 후회했다.

ㅋㅋ

처음에는 구독료만 계산하려고 했다

처음 생각한 건 아주 단순했다.

요즘 내가 구독하고 있는 서비스가 몇 개나 되지?

Netflix.

Spotify.

YouTube.

Amazon Prime.

ChatGPT.

Google Drive.

Microsoft 365.

게임 구독도 있을 수 있고, 전자책이나 웹툰도 있다.

한 개씩 보면 대부분 엄청난 돈은 아니다.

그래서 더 위험하다.

“이 정도야 뭐.”

라는 말이 여러 번 모이면 어느 순간 제법 훌륭한 금액이 된다.

처음에는 그래서 그냥 Subscription Calculator, 구독료 계산기 정도를 만들 생각이었다.

그런데 생각하다 보니 이상했다.

인터넷도 매달 돈이 나간다.

휴대전화도 나간다.

보험도 나간다.

자동차도 돈을 먹는다.

집은 말할 것도 없다.

노트북이나 휴대전화도 영원히 쓰는 물건이 아니다. 몇 년 지나면 다시 사게 된다.

그러면 질문이 달라진다.

“내 구독료가 얼마지?”

↓

“나는 그냥 살아 있는 데 한 달에 얼마를 쓰고 있지?”

여기서부터 일이 조금 커졌다.

그래서 이름이 ‘숨만 쉬어도 돈이 나간다’가 됐다

툴 이름은 장난처럼 붙였다.

숨만 쉬어도 돈이 나간다.

영어 이름은 Bill of Breath.

처음에는 나도 웃겼다.

그런데 기능을 붙일수록 이름이 별로 과장이 아닌 것 같아졌다.

생활 필수비.

차량 관련 비용.

쇼핑 멤버십.

클라우드와 업무 서비스.

스트리밍.

게임.

AI.

책과 웹툰.

그리고 몇 년에 한 번 교체하는 기기 비용까지.

평소에는 서로 다른 곳에 흩어져 있는 돈을 한 화면으로 모아보는 것이다.

정확한 금액을 모르면 우선 항목부터 선택해볼 수도 있고, 실제 금액을 알고 있다면 직접 수정할 수 있다.

무슨 대단한 금융 서비스는 아니다.

은행 계좌도 연결하지 않는다.

자동으로 구독을 해지해주지도 않는다.

그냥,

“내 생활은 대략 한 달에 얼마짜리인가?”

그걸 한번 보는 도구다.

직접 입력한 반복 지출을 영수증으로 뽑아봤다. 돈이 새로 생긴 것도 아닌데 리스트가 길어질수록 괜히 조용해진다.

내가 직접 값을 넣어봤다

툴을 만들 때 테스트 숫자를 넣는 것과, 내 진짜 숫자를 넣는 건 기분이 꽤 다르다.

처음에는 하나씩 입력했다.

이 정도는 예상했다.

다음 것도 예상했다.

이것도 알고 있었다.

그런데 리스트가 길어진다.

계속 길어진다.

나는 분명 새로운 지출을 만든 게 아니다.

원래 있던 걸 한곳에 모았을 뿐이다.

그런데 왜 갑자기 돈을 더 쓰고 있는 기분이 드는지 모르겠다.

대시보드에서 숫자로 볼 때는 그냥 계산 결과였다.

그런데 영수증 형태로 바꾸니까 느낌이 달랐다.

갑자기 내가 이 모든 걸 방금 계산대에서 결제한 것 같았다.

“손님, 이번 달 생활입니다.”

네.

제가 산 거 맞네요.

환불은 안 되나요?

월간 금액보다 이상하게 1초가 더 무서웠다

Bill of Breath에서는 지출을 여러 시간 단위로 나눠서 보여준다.

1년 1달 1주 1일 1시간 1분 1초

처음에는 연간이나 월간 금액이 제일 충격적일 줄 알았다.

그런데 이상하게 내 눈에 오래 남은 건 1초당 얼마였다.

월 고정지출은 익숙하다.

어차피 매달 청구서를 보니까.

그런데 같은 돈을 초 단위로 바꾸면 조금 이상해진다.

내가 일하고 있어도 나간다.

밥을 먹고 있어도 나간다.

TV를 보고 있어도 나간다.

자고 있어도 나간다.

아무것도 안 하고 멍하니 있어도 숫자는 아주 성실하게 움직인다.

내가 쉬고 있을 때도 나보다 열심히 일하는 것이 있었다.

자동결제였다.

그래서 장난 삼아 ‘한숨 한 번의 비용’ 같은 것도 넣었다.

후—

한 번.

얼마다.

이걸 안다고 인생이 달라지는 건 아니다.

그래도 한숨 쉴 때 조금 더 정성스럽게 쉬게 된다.

본전은 뽑아야 하니까.

영수증 한 장이 숫자보다 현실적이었다

사실 계산 자체는 특별할 게 없다.

연간 금액을 월로 나누고, 월 금액을 다시 일과 시간과 분으로 나누는 것이다.

그런데 숫자는 어떻게 보여주느냐에 따라 느낌이 달라진다.

대시보드에 Monthly Total이라고 크게 적혀 있으면 그냥 통계 같다.

반면 영수증에 내가 쓰는 항목들이 줄줄이 적혀 있고,

맨 아래에 1년, 1달, 1주, 1일, 1시간, 1분, 1초까지 붙어 있으니 이야기가 달라졌다.

계산기로 볼 때는 숫자였다.
영수증으로 나오니까 갑자기 내 생활비가 되었다.

아마 이 툴을 만들면서 내가 제일 마음에 든 부분도 여기다.

돈을 아껴주는 기능이 아니라,

내가 평소 안 보던 걸 한번 제대로 보여주는 것.

이걸 쓴다고 부자가 되는 건 아니다

이 부분은 확실히 해두고 싶다.

Bill of Breath는 금융 상담 서비스가 아니다.

예산을 짜주는 서비스도 아니다.

은행과 연결되지 않는다.

자동으로 Netflix를 해지해주지도 않는다.

이 툴을 열었다고 다음 달 통장 잔액이 갑자기 늘어나는 일도 없다.

그랬으면 내가 먼저 썼다.

나는 돈 관리 전문가도 아니다.

오히려 반대에 가깝다.

월급은 분명 들어왔는데, 얼마 지나지 않아

“어?”

하는 사람 쪽이다.

그래서 이걸 만든 것이다.

절약법을 가르치려고 만든 게 아니라,

나부터 한번 보려고.

어디로 나가는지.

얼마나 나가는지.

그리고 내가 “별거 아닌 돈”이라고 생각했던 것들이 한 달 뒤에는 얼마가 되는지.

숫자를 줄이는 건 그다음 문제다.

먼저 봐야 한다.

나처럼 한번 계산해보고 싶다면

YELLOW K TOOLS의 ‘숨만 쉬어도 돈이 나간다 (Bill of Breath)’에서 월 고정지출을 직접 계산해볼 수 있다.

로그인도 필요 없고, 은행 계좌를 연결할 필요도 없다.

자기가 쓰는 돈을 입력하고, 그냥 한번 보는 것이다.

내 생활은 한 달에 대략 얼마짜리일까?

내 월 고정지출 계산해보기 →

계산해봤다고 갑자기 돈이 생긴 건 아니다.

여전히 나갈 돈은 나간다.

ㅋㅋ

그래도 적어도 이제

“도대체 내 월급이 어디 갔지?”

라는 질문에는 조금 더 정확하게 대답할 수 있게 됐다.

여기 갔다.

저기 갔다.

그리고 생각보다 여러 군데 갔다.

가끔 우리는 돈을 엄청 크게 한 번 쓰고 후회한다.

그런데 월급을 조용히 없애는 건 꼭 큰돈만은 아니었다.

매달 조금씩.

아주 성실하게.

각자의 날짜에 맞춰 찾아오는 작은 돈들도 꽤 강했다.

숨만 쉬어도 돈이 나간다는 말은 농담으로 붙인 이름이었다.

직접 계산해보고 나니,

농담치고는 조금 정확했다.

ChatGPT Plus가 자꾸 부족해졌다. 결국 Pro로 업그레이드한 이유

AI 무작정 해보기 · ChatGPT 구독 · 실제 사용기

ChatGPT Plus에서 Pro로 업그레이드할 가치가 있을까?

부업·개발용으로 직접 쓰다 Free에서 Plus로, 다시 Pro까지 올라가버린 사람의 조금 비싼 실험.

나는 처음부터 AI를 열심히 쓰던 사람이 아니다.

처음에는 스마트폰에 ChatGPT 앱을 깔아놓고 생각날 때 질문 몇 개 하는 정도였다.

그러다가 영어 이력서를 써야 할 일이 생겼다.

영어 문장을 고치고, 표현을 바꾸고, 다시 읽어달라고 하고, 또 수정했다.

그런데 몇 번 고치다 보니 사용 한도에 걸렸다.

한창 이력서를 손보고 있는데 사실상 “오늘은 여기까지. 다음에 다시 오세요.”가 된 것이다.

아.

지금 이 타이밍에?

결국 큰맘 먹고 Plus를 구독했다.

당시에는 Go 같은 중간 플랜이 있는지도 몰랐다.

내 눈에는 거의 두 가지 선택지만 보였다.

무료로 버티느냐.
돈을 내고 계속 고치느냐.

그렇게 나의 첫 ChatGPT 유료 구독이 시작됐다.

문제는 내가 돈을 냈다는 사실이었다

나는 돈을 쓰고 나면 조금 이상한 사람이 된다.

뭔가를 샀으면 제값을 해야 한다고 생각한다.

사놓고 안 쓰고, 구독해놓고 한 달에 몇 번 들어가고, 물건은 먼지만 쌓이고.

이런 걸 꽤 싫어한다.

내 소비 원칙은 단순하다.

질렀으면 물고 뜯고 씹고 음미하라.

Plus도 마찬가지였다.

영어 이력서 하나 고쳤다고 한 달 구독료가 갑자기 싸지는 건 아니다.

그래서 생각하기 시작했다.

“이걸로 또 뭘 할 수 있지?”

생각해보면 그 질문이 조금 위험했다.

무료 버전으로 이력서를 고치다가 작업이 끊겼다. 내 첫 유료 구독의 이유는 꽤 단순했다.

Plus로 본전을 뽑겠다고 웹사이트를 만들기 시작했다

처음에는 글을 썼다.

이력서를 다듬고, 영어 문장을 고치고, 모르는 것을 물어봤다.

그러다가 점점 주문이 커졌다.

웹사이트를 만들어볼까.

작은 웹툴도 만들 수 있을까.

이미지를 만들어보자.

시장조사도 해보자.

블로그도 만들고, SEO도 알아보고, 광고도 붙여보자.

처음에는 질문 몇 개 하던 사람이 어느 순간 이렇게 말하고 있었다.

“이거 조사해줘.”

“이것도 만들어줘.”

“왜 안 돼? 고쳐줘.”

“그냥 다 해놔.”

문제는 내가 개발자가 아니라는 것이었다.

효율적으로 일을 나누는 법도 몰랐다.

간단하게 고칠 수 있는 것도 전체를 다시 시키고, 필요 없는 검색도 하고, 하나씩 하면 될 일을 한꺼번에 맡겼다.

토큰은 장작처럼 타들어갔다.

장작이 메마르다 못해 내 마음까지 같이 메말라가는 기분이었다.

질문 도구였던 ChatGPT는 어느 순간 웹사이트·글·이미지·리서치를 한꺼번에 돌리는 작업실이 됐다.

그래서 정말 정말 정말 고민하다 Pro를 질렀다

Pro 업그레이드는 Plus처럼 쉽게 결제하지 못했다.

꽤 오래 고민했다.

아니, 체감상으로는 한 5,000번쯤 고민했다.

이유는 간단하다.

나는 아직 AI로 돈을 벌고 있는 사람이 아니다.

오히려 반대다.

도메인을 사고, 구독료를 내고, 여러 도구를 사용하면서 아직 계속 마이너스다.

그런 사람이 더 비싼 요금제로 올라가는 게 맞나?

꽤 정상적인 고민이었다.

그런데 Plus를 개발과 부업 작업에 본격적으로 쓰기 시작하면서 다른 종류의 피로가 생겼다.

AI에게 일을 시키면서 일보다 사용량을 더 신경 쓰기 시작했다.

“이거 시키면 얼마나 남지?”
“지금 이 작업 시작해도 되나?”
“하다가 또 한도 걸리는 거 아니야?”

그 상태로 작업을 계속하는 것도 생각보다 피곤했다.

그래서 결국 눌렀다.

Upgrade.

현재 ChatGPT 플랜은 어떻게 나뉠까?

내가 Plus에 처음 가입했을 때와 지금은 플랜 구성이 조금 달라졌다.

현재 개인 사용자 기준으로는 Free, Go, Plus, Pro 계열로 나뉜다.

플랜	미국 표시 가격 기준	내가 보는 용도
Free	$0	가벼운 질문, 검색, 번역, AI 입문
Go	$8 / 월	무료 한도가 답답하지만 고급 작업은 많지 않은 사람
Plus	$20 / 월	글쓰기, 리서치, 파일, 코딩, 개인 프로젝트
Pro	$100 / 월부터	장시간 개발, 리서치, Codex, 이미지, 복잡한 작업을 많이 하는 사람

참고: 현재 Pro에는 사용량이 다른 단계가 있다. $100 Pro는 Plus보다 더 높은 사용량을 제공하고, $200 Pro는 더 높은 사용량 단계다. 다만 2026년 9월 10일 기준 신규 $200 Pro 가입 및 업그레이드는 일시 중단된 상태다. 가격과 구성은 국가 및 시점에 따라 달라질 수 있으므로 결제 전 공식 Pricing 화면을 확인하는 것이 좋다.

그럼 어떤 플랜이 제일 합리적일까?

지금 다시 처음부터 시작한다면 나는 가장 비싼 플랜부터 고르지 않을 것이다.

오히려 이렇게 올라갈 것 같다.

Free
AI가 내 생활에 실제로 필요한지 확인한다.

Go
무료 사용량만 답답하고 무거운 작업은 많지 않을 때 고려한다.

Plus
AI가 단순 질문 도구에서 실제 작업 도구로 바뀌었을 때.

Pro
Plus의 한도가 실제 작업 흐름을 계속 끊기 시작했을 때.

특히 대부분의 개인 사용자에게는 Plus가 꽤 넓은 구간을 담당한다고 생각한다.

글쓰기, 이력서, 공부, 리서치, 파일 분석, 이미지, 코딩 도움, 개인 프로젝트.

이 정도라면 Plus부터 충분히 사용해보는 것이 훨씬 합리적이다.

Pro는 “AI를 좀 더 잘 써보고 싶은 사람”보다 “이미 엄청 많이 쓰고 있는 사람”에게 의미가 크다.

Pro의 가치는 사용 시간이 아니라 ‘막히는 순간’으로 보는 게 낫다

하루에 몇 시간 썼는지만 보면 Pro가 필요한지 판단하기 어렵다.

대신 나는 이제 이런 질문이 더 중요하다고 생각한다.

Plus의 사용 한도 때문에 실제 작업이 자주 끊겼는가?

사용량을 아끼려고 필요한 작업을 미룬 적이 있는가?

코딩이나 리서치를 한창 하다가 제한 때문에 멈춘 적이 있는가?

파일·이미지·도구 사용량을 계속 계산하며 일하고 있는가?

여기에 계속 “그렇다”가 나온다면 Pro를 고민할 이유가 생긴다.

반대로

“가장 비싼 게 가장 좋겠지.”

정도라면 굳이 필요하지 않다.

비싼 식칼을 산다고 요리가 자동으로 맛있어지는 것은 아니다.

냉장고에 라면밖에 없으면 칼은 할 일이 없다.

한도는 넉넉해졌다. 이제 문제는 “그래서 이걸로 뭘 남길 것인가?”다.

부업·개발용으로 쓴다면 ‘대화 수’보다 결과물을 세고 싶다

나는 이미 Pro를 결제했다.

그러니 이제 결제가 옳았는지 하루 종일 고민하는 것보다 써먹는 편이 낫다.

내 소비 원칙상 그렇다.

이번 달에는 단순히 ChatGPT와 많이 이야기했다고 본전을 뽑았다고 생각하지 않으려고 한다.

대신 남은 것을 세어볼 생각이다.

웹툴 몇 개를 실제로 완성했는가.

블로그 글 몇 편을 제대로 발행했는가.

코드 문제를 몇 개 해결했는가.

조사 때문에 버리던 시간을 얼마나 줄였는가.

아이디어 몇 개를 실제 결과물로 바꿨는가.

한 달 동안 1,000번 대화했는데 아무것도 남지 않았다면 비싼 채팅을 한 것이다.

반대로 30번밖에 사용하지 않았어도 그걸로 웹사이트 하나 만들고, 이력서 하나 완성하고, 글 몇 편을 발행했다면 이야기가 달라진다.

AI와 얼마나 많이 대화했느냐보다
AI를 쓰고 무엇이 남았느냐.

Pro로 올라온 첫날, 사용량 표시가 거의 줄지 않는 모습을 보니 솔직히 흐뭇했다.

아름다웠다.

그동안 물을 아껴 쓰다가 갑자기 수도꼭지를 마음껏 튼 기분이었다.

그런데 잠시 뒤 한 달 지출을 생각했다.

시원했다.

그리고 조금 썼다.

결국 다시 같은 질문이 남았다.

그래서 Pro로 뭘 더 할 건데?

아직 답은 모른다.

이제 막 업그레이드했으니까.

그래서 이번 달을 하나의 실험으로 생각하기로 했다.

Pro가 얼마나 좋은지 테스트하는 달이 아니라, 내가 Pro만큼 일을 시킬 수 있는 사람인지 테스트하는 달.

한 달 뒤 결과물이 별로 없다면?

다시 내려가면 된다.

구독에도 자존심은 필요 없다.

다만 이번 달만큼은 이미 질렀으니까.

물고 뜯고 씹고 음미해볼 생각이다.