집 맥에서 Codex한테 작업을 시켜놓고 나왔는데, 지하철에서 문득 "지금 어디까지 했지?" 궁금했던 적 있으시죠. 이제 폰에서 확인하고, 지시도 내리고, 승인까지 할 수 있습니다. OpenAI가 6월 25일 Codex Remote를 정식 출시(GA)했거든요. 이 글에 codex remote 설정 방법과 실제로 뭘 할 수 있는지 정리해뒀습니다.
뭘 만들 수 있나요?
Codex Remote는 ChatGPT 모바일 앱에서 내 Mac이나 Windows 컴퓨터에 설치된 Codex를 원격으로 조종하는 기능입니다. 폰이 리모컨, 집이나 사무실 컴퓨터가 호스트가 되는 구조입니다.
폰에서 할 수 있는 일은 공식 문서 기준으로 이렇습니다.
호스트의 프로젝트에서 새 스레드 시작, 기존 스레드 이어가기
후속 지시 전송, Codex의 질문에 답변, 진행 중인 작업 방향 조정
명령 실행 등 액션 승인
결과물·diff·테스트 결과·터미널 출력·스크린샷 검토
작업 완료나 확인 요청 시 알림 수신
연결된 여러 호스트와 스레드 사이 전환
여기서 중요한 건, 원격 접속이 호스트의 프로젝트, 파일, 자격 증명, 권한, 플러그인, 로컬 도구를 그대로 쓴다는 겁니다. 클라우드 샌드박스가 아니라 내 컴퓨터 환경 그 자체를 폰에서 움직이는 셈이죠.
준비물
호스트: Mac 또는 Windows 컴퓨터 + 최신 버전 Codex 앱
컨트롤러: iOS/Android 폰 + 최신 버전 ChatGPT 앱
호스트와 폰이 같은 ChatGPT 계정(워크스페이스)으로 로그인
호스트는 켜져 있고, 온라인이며, 로그인 상태여야 함
Step 1: 호스트에서 QR 코드 띄우기
Mac/Windows의 Codex 앱에서 "Set up Codex mobile"을 선택합니다. 해당 호스트의 원격 접근이 활성화되면서 페어링용 QR 코드가 화면에 표시됩니다.
Step 2: 폰으로 스캔하고 인증하기
폰의 ChatGPT 앱으로 QR 코드를 스캔합니다. 계정과 워크스페이스가 맞는지 확인한 뒤, MFA·SSO·패스키 인증을 완료하면 페어링이 끝납니다.
주의할 점 하나. QR 페어링은 폰 1대와 호스트 1대의 1:1 연결입니다. 폰 2대로 맥 1대를 조종하고 싶으면 각각 페어링해야 하고, 호스트가 2대면 역시 각각 스캔해야 합니다.
Step 3: 연결 확인하고 시작하기
호스트의 Settings > Connections에서 연결 상태를 검토합니다. 여기까지 되면 폰의 ChatGPT 앱에서 호스트의 프로젝트가 보이고, 스레드를 시작하거나 이어갈 수 있습니다.
결과
설정은 QR 스캔 한 번이면 끝입니다. 이후에는 폰에서 호스트의 Codex 작업을 실시간으로 보고 조종할 수 있죠. 6월 업데이트로 편의 기능도 붙었습니다. 6월 18일부터는 로컬과 원격 호스트 사이에서 같은 프로젝트의 스레드를 넘겨받는 핸드오프가 됩니다. 6월 22일 iOS 업데이트에서는 호스트별 성격 설정(Friendly/Pragmatic), 그리고 작성창 안에서 목표를 수정하는 기능이 추가됐고요.
주의할 점
Windows는 호스트만 됩니다. 폰이나 Mac에서 Windows를 조종할 수는 있지만, Windows에서 다른 컴퓨터를 조종할 수는 없습니다.
호스트가 잠들면 끊깁니다. 절전 모드나 오프라인 상태가 되면 원격 접근이 중단되니, 장시간 작업을 걸어둘 거면 절전 설정을 확인하세요.
오래 안 쓴 연결은 재페어링이 필요합니다. 2026년 6월 8일 이후 사용된 연결만 페어링이 유지됩니다.
보안은 시큐어 릴레이 방식입니다. 호스트를 공개 인터넷에 직접 노출하지 않고 인증된 릴레이 계층으로 연결하며, 6월 18일부터는 종단간 암호화(Noise 프로토콜) 채널을 씁니다.
자주 묻는 질문
Codex Remote는 무료인가요?
Codex Remote는 별도 요금이 아니라 Codex가 포함된 ChatGPT 플랜에서 쓰는 기능입니다. 최신 ChatGPT 모바일 앱과 호스트의 Codex 앱만 있으면 추가 비용 없이 설정할 수 있습니다.
Codex Remote 시작하려면 뭐가 필요하나요?
Mac 또는 Windows 호스트에 설치된 최신 Codex 앱, 폰의 최신 ChatGPT 앱, 그리고 같은 계정 로그인이 전부입니다. 호스트 앱에서 QR을 띄우고 폰으로 스캔하면 됩니다.
Codex Remote와 Codex Cloud(웹 작업)의 차이점은?
클라우드 작업은 OpenAI 서버의 샌드박스에서 실행되지만, Codex Remote는 내 컴퓨터의 파일·자격 증명·플러그인·로컬 도구를 그대로 쓰는 원격 조종입니다. 로컬 환경이 필요한 작업(사내 DB 접근, 로컬 빌드 등)은 Remote가 답입니다.
연결이 갑자기 안 될 때는?
호스트가 켜져 있고 온라인·로그인 상태인지부터 확인하세요. 절전 모드 진입이 가장 흔한 원인이고, 오래 사용하지 않은 연결이라면 QR 재페어링이 필요할 수 있습니다.
인사이트
Codex Remote가 정식 출시되면서 "AI 에이전트 작업의 단위"가 바뀌고 있다고 느껴요. 지금까지는 컴퓨터 앞에 앉아 있는 시간이 곧 작업 시간이었는데, 이제는 작업을 걸어두고 자리를 뜨는 게 기본 흐름이 됩니다. 폰은 코드를 짜는 도구가 아니라 승인하고 방향을 트는 관제 도구가 되는 거죠.
재미있는 건 Anthropic 쪽 생태계에도 같은 방향의 흐름이 있다는 점입니다. 지피터스 커뮤니티에서 검색이 많은 Hermes Agent나 OpenClaw처럼 텔레그램·슬랙으로 로컬 에이전트를 조종하는 도구들이 먼저 이 자리를 차지하고 있었는데, OpenAI는 이걸 서드파티 없이 ChatGPT 앱 안에 공식 기능으로 넣었습니다. 메신저 연동형 도구를 쓸지, 공식 앱 통합을 쓸지 — 로컬 에이전트 원격 제어가 이제 '선택지 있는 카테고리'가 된 셈입니다. 일단 맥을 켜두고 출근하는 것부터 시작해보세요.
원문: OpenAI Codex 공식 문서 — Remote connections · Codex Changelog
스마트스토어나 자사몰 운영하시는 분들이 가장 오래 붙잡고 있는 작업이 뭘까요? 의외로 상품 등록 자체가 아니라 상세페이지 디자인이에요. 디자이너를 쓰자니 건당 비용이 부담되고, 직접 만들자니 포토샵부터 막히죠. 제디터는 이 구간을 겨냥한 도구입니다. 이번 글에서 제디터 사용법과 요금제, 그리고 어떤 판매자에게 맞는지까지 정리했습니다.
제디터가 뭔가요?
제디터는 상품명과 사진 몇 장만 올리면 AI가 상세페이지를 자동으로 구성해주는 가비아의 AI 디자인 에디터입니다. 문구 작성, 레이아웃 구성, 이미지 배치를 AI가 한 번에 처리하고, 사용자는 생성된 초안을 블록 단위로 편집하는 방식입니다.
공식 페이지 기준으로 상세페이지 하나가 나오는 데 걸리는 시간은 약 20분. 외주를 맡기면 며칠 걸리는 작업이라는 점을 생각하면, 초안 확보 속도가 이 도구의 핵심 가치입니다.
핵심 기능
AI 상품상세 자동 생성: 상품명과 사진을 올리면 상세페이지 초안을 AI가 알아서 구성합니다. 최근 'AI 상품상세 3.0' 버전으로 업데이트됐습니다.
AI 이미지 생성: 페이지에 필요한 보조 이미지를 AI가 만들어줍니다. 촬영 컷이 부족할 때 빈 자리를 채우는 용도로 씁니다.
AI 텍스트 교체: 디자인 레이아웃은 그대로 두고 문구만 AI가 바꿔줍니다. 시즌 문구 교체나 옵션 변경에 유용합니다.
블록 단위 편집: 생성된 초안에서 드래그로 섹션을 재배치하고, 클릭으로 복사할 수 있습니다.
같은 디자인 반복 생산: 한 번 만든 디자인에 상품 정보만 갈아끼워 여러 상품의 상세페이지를 찍어낼 수 있습니다. 상품 수가 많은 셀러에게 특히 중요한 기능입니다.
지원 카테고리는 패션, 가전·디지털, 식품, 뷰티, 리빙, 반려, 티켓 등이며 카테고리 제한 없이 쓸 수 있습니다.
이렇게 써보세요 — 실전 활용법
활용 1: 신상품 등록 초안 20분 컷
상품 정보 입력 → AI 생성 → 편집 → 판매 채널 적용, 4단계로 끝납니다. 여기서 결과물 품질을 가르는 건 첫 단계인 상품 정보 입력입니다. 입력한 텍스트가 AI 생성의 기준이 되기 때문에, 특징이 모호하면 결과물도 모호해집니다. "부드러운 원단" 대신 "코튼 100%, 두께감 있는 16수 원단"처럼 구체적으로 쓰는 게 초안 품질을 올리는 지름길입니다.
활용 2: 다상품 셀러의 템플릿 재활용
상품이 수십 개인 셀러라면 첫 상세페이지에 공을 들인 뒤, 이후 상품은 '같은 디자인 반복 생산' 기능으로 정보만 교체하는 흐름이 효율적입니다. 브랜드 톤이 유지되면서 상품별 제작 시간은 크게 줄어듭니다.
Photo by Campaign Creators on Unsplash
요금 & 시작하기
요금제월 가격토큰저장공간트래픽
Lite
5,500원
5,000
500MB
미제공
Basic
16,500원
15,000
10GB
30GB
Lite 요금제는 첫 1개월 무료 체험이 가능합니다. 가비아 계정으로 로그인하며, 일단 무료 체험으로 내 상품 하나를 실제로 만들어보고 결과물 품질을 확인한 뒤 결제를 결정하는 순서를 추천합니다.
자주 묻는 질문
제디터는 무료인가요?
완전 무료는 아니고, Lite 요금제(월 5,500원)를 첫 1개월 무료로 체험할 수 있습니다. 체험 기간에 실제 상품으로 상세페이지를 만들어보고 판단하면 됩니다.
제디터 시작하려면 뭐가 필요하나요?
가비아 계정과 상품 사진 몇 장, 그리고 상품 설명 텍스트만 있으면 됩니다. 디자인 툴 사용 경험은 필요 없습니다.
제디터와 클로드로 직접 만드는 것의 차이는?
제디터는 이커머스 상세페이지에 특화된 템플릿과 편집기를 제공하는 반면, 클로드 같은 범용 AI는 자유도가 높지만 결과물을 HTML이나 이미지로 직접 가공해야 합니다. 판매 채널에 바로 올릴 완성형 결과물이 필요하면 제디터 쪽이 빠릅니다.
인사이트
지피터스 커뮤니티에는 클로드나 젠스파크로 상세페이지를 만드는 사례가 여러 편 올라와 있어요. 범용 AI로 만들면 비용은 대화 몇 번 수준으로 저렴하지만, 매번 프롬프트를 다듬고 결과물을 손봐야 하는 '운영 비용'이 숨어 있습니다. 제디터 같은 버티컬 도구는 그 반대편에 있죠. 월 구독료를 내는 대신 편집기, 템플릿, 채널 적용까지의 마지막 구간을 대신 깔아줍니다.
그래서 판단 기준은 "어느 쪽이 더 싸냐"가 아니라 상품 수와 갱신 빈도라고 봅니다. 상품이 몇 개 안 되고 한 번 만들면 오래 쓰는 구조라면 범용 AI로 충분하고, 상품이 계속 늘어나거나 시즌마다 문구를 갈아야 한다면 반복 생산 기능이 있는 전용 도구의 효율이 앞서기 시작합니다. 도구 선택 전에 내 스토어의 상세페이지 '회전율'부터 세어보세요.
원문: 제디터 공식 페이지
한줄 요약
이제 AI 에이전트에게 매번 프롬프트를 입력하지 말고, 에이전트를 스스로 돌리는 시스템(루프)을 설계하라는 것이 구글 출신 엔지니어 애디 오스마니(Addy Osmani)가 정리한 '루프 엔지니어링'의 핵심입니다.
무슨 일이 있었나?
루프 엔지니어링(Loop Engineering)은 AI에게 매 단계 프롬프트를 직접 입력하는 대신, AI가 작업을 발견하고 실행하고 검증하는 과정을 스스로 반복하도록 시스템을 설계하는 방식입니다.
지난 몇 년간 개발자가 코딩 에이전트와 일하는 방식은 단순했습니다. 프롬프트를 쓰고, 응답을 읽고, 다음 프롬프트를 쓰는 수동 반복이었죠. 오스마니는 이 방식이 끝나가고 있다고 말합니다. 발견·분류·실행·검증을 알아서 도는 자기 구동 시스템이 그 자리를 대신한다는 겁니다.
이 주장은 한 사람의 의견이 아닙니다. 클로드 코드를 만든 앤트로픽의 보리스 체르니(Boris Cherny)는 "나는 더 이상 클로드에 프롬프트하지 않는다. 클로드에 프롬프트를 거는 루프를 돌릴 뿐이다"라고 말했고, 피터 스타인버거(Peter Steinberger)도 "이제 코딩 에이전트에 프롬프트하면 안 된다. 루프를 설계해야 한다"고 했습니다. 현장에서 가장 깊이 들어간 사람들이 같은 결론에 도달한 셈입니다.
루프를 구성하는 6가지 부품
오스마니는 실제로 동작하는 루프를 만들려면 6개의 부품이 필요하다고 정리합니다. 클로드 코드 사용자라면 각 부품이 이미 손에 있는 기능과 1:1로 대응됩니다.
Automations(자동 실행): 버튼을 누르지 않아도 작업을 시작하는 스케줄 트리거입니다. 매일 아침 열린 이슈를 검토하거나, CI 실패를 분석하거나, 버그를 찾는 작업을 알아서 돌립니다.
Worktrees(작업 격리): 여러 에이전트가 동시에 파일을 건드릴 때 충돌하지 않도록 분리된 git 브랜치에서 작업하게 합니다.
Skills(맥락 문서화): 프로젝트 규칙·빌드 절차·조직 맥락을 문서로 저장해, 에이전트가 매번 맥락을 다시 추론하지 않게 합니다.
Plugins & Connectors(외부 연동): MCP로 이슈 트래커·데이터베이스·API·메신저 같은 외부 도구와 연결합니다.
Sub-agents(역할 분리): 탐색·구현·검증을 서로 다른 에이전트가 맡습니다. 한 에이전트가 자기 작업을 스스로 채점하지 못하게 막는 장치입니다.
Memory(외부 기억): 모델은 세션이 끝나면 잊습니다. 마크다운 파일이나 Linear 보드 같은 외부 저장소에 상태를 남겨 다음 실행이 이어받게 합니다.
여기서 가장 자주 빠뜨리는 부품이 5번 서브에이전트입니다. 작업을 만든 모델이 "다 됐다"고 자평하면 거의 항상 성공을 과대 보고합니다. 그래서 클로드 코드의 /goal은 완료 조건을 검증할 때 코드를 생성한 모델과 다른, 더 빠른 모델을 별도로 씁니다. '만든 쪽'과 '판정하는 쪽'을 분리하는 것이 루프 설계의 핵심 원리입니다.
왜 중요한가?
루프 엔지니어링이 단순한 자동화와 다른 지점은 오스마니가 짚은 '두 가지 빚'에 있습니다.
첫째는 의도 빚(Intent debt)입니다. 매번 에이전트에게 프로젝트 맥락을 다시 설명하는 비용이죠. Skills로 맥락을 한 번 문서화하면 이 빚이 사라집니다. 둘째는 이해 빚(Comprehension debt)입니다. 루프가 내가 직접 읽지 않은 코드를 배포할 때 생기는 지식 격차입니다. 이건 자동화가 빨라질수록 오히려 커집니다.
오스마니의 경고가 날카롭습니다. "한 사람은 깊이 이해한 일을 더 빨리 하려고 루프를 쓰고, 다른 사람은 그 일을 아예 이해하지 않으려고 루프를 쓴다. 루프는 그 차이를 모른다. 당신은 안다." 즉 루프를 잘 돌리는 것과 일을 이해하는 것은 별개의 책임이라는 뜻입니다.
Photo by BoliviaInteligente on Unsplash
실전에서 어떻게 쓸 수 있을까?
개념을 손에 잡히게 바꿔보면, 한국 멤버 입장에서 오늘 바로 시도해볼 수 있는 루프는 다음과 같습니다.
활용 1: 아침 트리아지 루프
가장 부담 없는 첫 루프입니다. 매일 아침 자동 실행이 CI 실패와 열린 이슈를 점검해 상태 파일에 정리합니다. 처리 가능한 항목은 격리된 Worktree에서 서브에이전트가 수정 초안을 만들고, 다른 서브에이전트가 프로젝트 Skills와 테스트 기준으로 검토합니다. Connector가 PR을 열고 티켓을 업데이트하면, 해결 못 한 건만 사람의 받은편지함에 남습니다. 클로드 코드의 Automations + /goal 조합으로 코드 없이 구성할 수 있습니다.
활용 2: 완료 조건부터 적는 습관
루프를 설계할 때 가장 먼저 할 일은 "무엇이 '다 됐다'인가"를 한 문장으로 적는 것입니다. 완료 조건을 말로 못 하면 그건 루프가 아니라 그냥 바람입니다. /goal에 검증 가능한 조건을 넣고, 그 검증을 다른 모델이 맡게 하는 것만으로 자기 채점 문제를 피할 수 있습니다.
활용 3: 이해 빚 방어선 만들기
루프가 빨라질수록 직접 코드를 검증하고, 생성된 코드를 이해하며, 루프 결과를 무비판적으로 받아들이지 않는 세 가지를 사람이 지켜야 합니다. 예컨대 서브에이전트 검증을 통과한 PR이라도 머지 전 사람이 핵심 diff를 한 번 읽는 규칙을 루프에 박아두면, 이해 빚이 쌓이는 걸 막을 수 있습니다.
인사이트
6월 22일 지피터스에 슈밤 사부(구글 시니어 AI PM)의 루프 엔지니어링 글을 한 번 다룬 적이 있습니다. 그 글은 PM 관점이었습니다. 트리거·액션·증명·메모리·정지조건이라는 5부품으로 '아티팩트가 계속 좋아지는 시스템'을 보는 시각이었죠. 오스마니의 이번 글은 같은 단어를 쓰지만 엔지니어 관점입니다. Worktree·서브에이전트·Connector 같은 실제 코드 구성요소와, 의도 빚·이해 빚이라는 비용 프레임이 중심입니다.
두 관점을 겹쳐 보면 루프 엔지니어링의 윤곽이 또렷해집니다. PM은 '무엇을 검증할지(루브릭)'를 설계하고, 엔지니어는 '어떻게 검증을 분리할지(서브에이전트)'를 설계합니다. 둘 다 결국 같은 한 문장으로 수렴합니다. 검증을 먼저 쓰라는 것이죠.
한국 팀에 적용할 때 진짜 병목은 도구가 아니라 'Skills 문서화' 단계일 가능성이 높습니다. 한국어 사내 규칙·코드 컨벤션·도메인 맥락이 문서로 정리돼 있지 않으면, 아무리 좋은 루프를 깔아도 에이전트가 매번 맥락을 헛짚습니다. 의도 빚을 먼저 갚는 것, 즉 Skills부터 채우는 것이 한국 환경에서 루프를 돌리는 현실적인 출발점입니다.
원문: https://addyosmani.com/blog/loop-engineering/
매일 아침 콘텐츠 한 편을 쓰는 일, 저는 오랫동안 이걸 "매번 처음부터" 해왔어요. 쓸 만한 원문(소스)을 직접 찾아 던지고, 같은 절차를 또 설명하고, 결과가 괜찮은지 눈으로 확인하고요. 반복인 건 아는데, 그 반복을 어떻게 줄여야 할지는 몰랐죠.
그러다 Claude Code로 이 반복을 '루프(loop)'로 설계해봤어요. 결론부터 말하면, 매번 AI에게 시키는 저 자신을 시스템으로 바꾸는 작업이었고 — 가장 손이 많이 가던 '소스 찾기'부터 자동으로 제안받는 구조까지 만들었습니다. 그 과정을 공유할게요.
"이거 매번 반복하는데" — 근데 뭘 자동화할지 몰랐어요
제 매일 업무는 GPTers 커뮤니티에 올릴 콘텐츠를 쓰는 거예요. 이미 저만의 작성 스킬도 있었고요. 그런데도 매일 손이 많이 갔어요. 왜냐면 "글을 잘 쓰는 법"은 정리돼 있었지만, "매일 이 일을 어떻게 반복해서 굴릴지"는 어디에도 없었거든요.
그래서 AI에게 이렇게 부탁했어요.
매일 하는 일은 콘텐츠 작성하기입니다
내 작성 스킬을 참고해보면 될듯?
AI가 제 기존 스킬을 읽더니, 흥미로운 구분을 해줬어요. 제 작성 스킬은 이미 훌륭한 '레시피'(한 편을 어떻게 쓰는가)라서, 이번엔 그걸 버리지 말고 그 위에 매일 반복을 굴리는 '루프 뼈대'만 새로 씌우면 된다는 거였죠.
이 지점에서 처음 배웠어요. 자동화는 "더 긴 프롬프트를 쓰는 것"이 아니라, 반복되는 일이 트리거·검증·정지 조건을 따라 스스로 굴러가게 설계하는 것이더라고요.
"원문도 알아서 가져오는 건 욕심일까요?"
설계를 하다가 제가 슬쩍 물어봤어요. 제일 귀찮은 게 소스 찾기였거든요.
원문도 알아서 가져오는 건 욕심일까요?
돌아온 답이 좋았어요. 욕심이 아니라 "언제 넣느냐"의 문제라고요. 알고 보니 저는 이미 콘텐츠를 매일 모아주는 시스템을 갖고 있었어요. AI가 제 작업 폴더를 보다가 그걸 발견하고 "이걸 소스로 연결하면 된다"고 제안한 거죠.
솔직히 이게 이번에 제일 놀란 부분이었어요. 제 작업 폴더 안에 뭐가 있는지 AI가 먼저 찾아서 "이거 쓰면 되잖아요"라고 연결해준 거요. 제가 잊고 있던 제 자산을요.
여기에 제 아이디어도 하나 얹었어요.
구글 트렌드 데이터도 가져오면 좋을 것 같아!
그래서 소스를 수집 시스템 + 검색 데이터(GSC) + 구글 트렌드 세 갈래로 넓혔어요. 다만 트렌드는 공식 통로가 불안정해서 "있으면 보태고 막히면 건너뛰는" 보조로 두기로 했고요.
"이걸 그림으로 설명해줄래?"
개념이 머릿속에서 안 그려질 땐, 이렇게 부탁했어요.
이걸 그림으로 설명해줄래?
그랬더니 터미널 안에 흐름도를 그려줬어요. 누가 사람이 할 일이고 누가 자동인지 한눈에 보였죠. 특히 사람은 딱 두 곳(무엇을 쓸지 고르기 / 발행 승인)만 남기고 나머지는 루프가 하도록 나눈 게 명확해졌어요.
"maker와 checker는 에이전트인가요?"
설계 중에 'Maker(만드는 역할) / Checker(검증하는 역할)를 분리하라'는 얘기가 나왔는데, 이게 무슨 뜻인지 애매했어요. 그래서 직접 물어봤죠.
maker와 checker는 에이전트인가요?
이 질문 덕분에 개념이 확 잡혔어요. Checker는 꼭 별도의 AI가 아니라 "별도의 시선으로 증거를 확인한다"는 역할이더라고요. 그리고 대부분은 AI에게 "이거 괜찮아?"라고 다시 묻는 게 아니라, 규칙과 숫자로 확인하는 거였어요. 예를 들면 이런 식이에요.
제목이 정확히 1개인가? → 세어보면 됨 (코드)
핵심 섹션이 들어갔나? → 있는지 찾아보면 됨 (코드)
기존 글과 검색 경쟁이 겹치나? → 데이터로 조회 (코드)
"AI가 스스로 잘 썼다고 우기는 것"을 막으려면, 이렇게 숫자와 존재 여부처럼 우길 수 없는 신호로 판정해야 한다는 거였어요. (딱 하나, '이 인사이트가 진짜 독창적인가' 같은 건 읽어봐야 아니까, 그것만 맥락 없는 새 시선이 보게 뒀고요.)
결과
수치보다 체감이 컸어요. 예전엔 "오늘 뭐 쓰지"부터 소스 찾기까지가 매일 아침의 짐이었는데, 이제 그건 루프가 후보로 올려주고 저는 고르기와 발행 승인이라는 '판단'에만 집중하면 돼요. 반복 잡일과 제 판단이 깔끔하게 분리된 거죠.
AI 활용 팁!
이 방식은 콘텐츠 말고도 매일/매주 반복하는 일이라면 다 적용해볼 수 있어요. 정기 리포트, 데이터 점검, 뉴스레터 정리 같은 것들요. 대신 두 가지만 기억하세요.
완료 판정은 AI 자기평가에 맡기지 마세요. "괜찮아 보임"이 아니라, 숫자·개수·존재 여부처럼 우길 수 없는 신호로 확인하게 하세요.
사람이 남을 지점을 명확히 그으세요. 무엇을 할지 '고르는' 판단과 '발행' 결정은 AI가 아니라 내가 하도록요. 여기까지 자동화하면 오히려 사고가 커져요.
그리고 충분히 반복되지 않거나 개선할 필요가 없는 일에는 루프를 씌우지 마세요. 그건 과설계예요.
바로 쓸 수 있는 프롬프트
제가 매일 반복하는 [업무 이름] 작업이 있어요. 이걸 매번 시키는 대신 루프로 설계하고 싶어요. 먼저 제 기존 작업 방식([기존 스킬/문서 경로])을 읽고, 이 반복업무가 루프에 적합한지 판정해주세요. 그다음 ①언제 시작하고 ②무엇으로 완료를 판정하며(자기평가 말고 객관 신호로) ③언제 멈추는지, 그리고 사람이 남아야 할 판단 지점이 어디인지를 상태 파일 한 장으로 정리해주세요. [업무 이름]과 [기존 스킬 경로]는 본인 상황에 맞게 바꾸세요.
<작성해야 하는 TIPS 사업화 최종 보고서>
📝 한줄 요약
정부 과제 최종보고서를 쓸 때마다 "양식 제대로 지켜졌나, 가이드에서 빠뜨린 건 없나"를 매번 눈으로 검수하던 일을, 매번 같은 기준으로 자동으로 도는 '검수 루프' 로 바꿨습니다. 덤으로 AI가 "다 됐어요"라고 할 때 그 말을 믿지 않고 진짜로 확인하는 법까지 배웠습니다.
🎯 이런 분들께 도움돼요
매번 같은 양식·체크리스트로 문서를 검수하는 게 반복 업무인 실무자
AI한테 일을 시켰는데 "다 됐다"는 결과가 은근히 안 맞아서 고생해 본 분
AI 코딩 도구(Claude Code 등)를 한 번의 지시가 아니라 '시스템'으로 굴려보고 싶은 분
😫 문제 상황 (Before)
정부 TIPS 최종보고서는 제출 양식이 아주 빡빡합니다. 정해진 표 레이아웃, "달성 표시는 이모지 말고 텍스트로", "빈 칸·임시 문구 남기면 안 됨", 증빙 페이지 구성까지 — 작성 가이드만 433개 항목입니다.
그런데 보고서는 한 번 쓰고 끝이 아니라 매번, 여러 번 씁니다. 그때마다 저는 생성된 문서를 열어놓고 체크리스트를 손으로 훑었습니다. 숫자가 원본이랑 맞는지, 놓친 항목은 없는지, 양식은 지켜졌는지 눈으로요. 지루하고, 시간이 걸리고, 무엇보다 매번 기준이 조금씩 달라지고 놓치기 쉬웠습니다. 제출 마감이 코앞이라 더 이상 "그때그때 눈대중"으로 갈 수 없었습니다.
🛠️ 사용한 도구
도구명: Claude Code / Codex
모델: Claude Opus 4.8, Fable 5, GPT 5.5 xhigh
특이사항: 로나(Rona)의 "반복업무 루프 설계" 맞춤 실습을 받아, 그 방법을 실제 제 보고서 작업에 그대로 적용했습니다.
🔧 작업 과정
매번 하는 검수를 '루프'로 바꾸기
먼저 "무엇을 자동화할지"부터 정했습니다. 제가 실제로 반복하는 일을 그대로 말했습니다.
이런 보고서 작성할 일이 잦은데, 원래 PDF 양식에 맞춰서 HTML이 생성되었는지, 보고서 작성 가이드는 놓친 것이 없는지 확인하는 것이 반복하는 작업이야.
Claude는 이 일을 "매번 같은 기준으로 도는 검수 절차"로 만들자고 정리했습니다. 검수 기준을 문서 한 장(레시피)으로, 진행 상태를 또 한 장(상태표)으로 나눠 적어서, 다음에 또 검수할 때 처음부터 설명할 필요가 없게요.
여기서 제가 한 가지를 바로잡았습니다. 초안이 '양식(레이아웃)'만 보길래, 작성 가이드에서 내용 체크리스트를 뽑아 '내용'까지 검증하는 단계를 넣어달라고 했습니다. 실제로 그 업무를 해온 사람이라 빠진 게 눈에 보였거든요.
AI가 스스로 "통과!" 하지 못하게 만들기
가장 인상적이었던 개념이 '만드는 역할'과 '검사하는 역할'을 나누는 것 이었습니다. 만든 쪽이 자기 결과를 스스로 검사하면 "이 정도면 됐지" 하고 후하게 통과시키기 마련이라, 검사는 반드시 객관적인 증거 — 예산 계산 스크립트의 출력, 금지 문구 검색 결과, 누락 개수 — 로만 판정하게 했습니다.
이게 얼마나 중요한지 첫 시범에서 바로 드러났습니다. 검수를 한 번 돌렸더니 "금지 문구 0건 → 통과처럼" 보였는데, 숫자가 전부 비어 있었습니다. 알고 보니 채워진 보고서가 아니라 빈 양식을 검사하고 있었던 거죠. "통과"가 아니라 "엉뚱한 걸 검사 중"이었습니다. 사람이 증거를 읽고서야 잡았습니다.
통째로 말고, 섹션별로 쪼개기
보고서가 워낙 길어서, 전체를 통째로 검수 루프에 넣는 게 비효율적으로 느껴졌습니다. 그래서 제안했습니다.
전체 보고서에 대한 루프를 돌리는 것보다, 각 섹션에 대해서 루프를 돌리는 게 더 나을 것 같아. 각 섹션별로 검토해서 만족한 다음에 다 이어붙이고 페이지를 조정하는 방식은 어떨까?
Claude가 확인해 보니 보고서는 이미 8개 섹션 파일로 나뉘어 있었습니다. 그래서 검수를 2단계로 재설계했습니다. 먼저 섹션 하나하나를 검수해 통과시키고(통과한 섹션은 다시 안 봄), 8개가 다 되면 이어붙여서 페이지·일관성만 마지막에 확인하는 방식으로요.
8개 섹션을 동시에 시키기 (그리고 그 대가)
여기서 또 한 걸음 나갔습니다. 긴 작업을 한 번에 시키면 실수가 잦아진다는 걸 경험으로 알고 있어서, 부분을 나눠 여러 명에게 동시에 시키면 정확도도 오르고 시간도 아낄 것 같았습니다.
동시에 여러 서브에이전트를 띄워서 한 번에 해결하는 것은 안 될까?
그래서 섹션 6개를 AI 6명에게 동시에 맡겼습니다. 확실히 빨랐습니다. 그런데 병렬로 하면 대가가 있었습니다 — 6명이 각자 판단하다 보니 이미지 경로를 제각각 다른 방식으로 써버렸고, 한 명은 "이미지 다 확인했어요"라고 보고했지만 실제로는 화면에서 깨지는 경로였습니다.
이걸 잡아준 게 한 명의 검사자 였습니다. 6명이 만든 걸 한자리에서 대조하니 각자는 못 보던 불일치가 드러났습니다. 만드는 건 여러 명이 병렬로, 검사는 한 명이 몰아서 — 이 조합이 병렬 작업의 핵심이었습니다.
<뭐야 레이아웃 다 깨지고 지맘대로 만들었네....>
"다 됐다는데 왜 안 맞지?" — 진짜 함정
이어붙인 결과물을 열어봤더니, 두 가지가 눈에 띄게 어긋나 있었습니다. 원본 양식의 표 레이아웃이 통째로 빠졌고, 모든 이미지가 안 보였습니다. 저는 원인만 조사해 달라고 했습니다.
final-report.html을 보면 template.pdf와 레이아웃이 달라. 표 레이아웃이 완전히 빠졌고, 모든 이미지가 안 보여. 왜 이런 일이 발생했는지 조사해줘. 추가 수정은 하지 말고 원인 분석만 해줘.
원인은 놀랍도록 같은 뿌리였습니다. 검사할 때 "파일이 있나"만 확인하고 "실제로 화면에 뜨나"는 확인한 적이 없었던 것입니다. 이미지 파일은 다 있었지만 경로에 공백·한글이 들어가 브라우저가 못 읽었고, 표 레이아웃은 애초에 "깔끔하게 새로 만들자"는 판단 때문에 원본의 표 구조를 버린 상태였습니다. 둘 다 '진짜 결과(화면)' 대신 '대충 비슷한 신호(파일 존재)'만 검사한 탓이었죠.
그래서 마지막으로 '렌더 게이트' 를 검수 레시피에 넣었습니다. 완료 판정 전에 실제로 브라우저에 띄워서 "이미지가 진짜 다 보이나 + 표 레이아웃이 원본과 같나"를 확인하게요. 이제 예전 같으면 초록불이었을 결과물이 정확히 빨간불로 잡힙니다.
✅ 결과 (After)
Before vs After
항목
Before
After
검수 방식
매번 눈으로 체크리스트 훑기
매번 같은 기준으로 도는 검수 루프
기준 일관성
그때그때 달라짐, 놓치기 쉬움
레시피에 고정 (양식/내용 2트랙)
완료 판정
"괜찮아 보임" (사람 인상)
객관 증거 + 실제 렌더 확인
섹션 8개 처리
순차로 하나씩
6개 동시 생성 + 한 명이 몰아서 검사
재사용
매번 처음부터 설명
다음 보고서에도 그대로 재사용
결과물
검수 기준을 고정한 재사용 가능한 검수 레시피
8개 섹션 각각의 진행 상태를 보여주는 진행표
조립된 보고서 초안과, 제출 전에 버그를 잡아내는 렌더 게이트
솔직한 마무리: 최종 PDF까지 간 건 아닙니다. 오히려 렌더 게이트가 "이미지 안 보임 + 표 레이아웃 어긋남"을 제출 전에 빨간불로 잡아준 게 이번의 진짜 성과입니다. 예전이었으면 그대로 제출할 뻔했으니까요.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
반복 업무를 '한 번의 지시'가 아니라 '루프'로 설계 — 검수처럼 매번 같은 기준으로 하는 일에 특히 잘 맞습니다.
만드는 역할과 검사하는 역할을 분리 — AI가 자기 결과를 스스로 통과시키지 못하게, 검사는 객관 증거로만.
길고 독립적인 작업은 나눠서 동시에 — 단, 병렬로 만든 건 마지막에 한 명이 몰아서 검사해야 제각각 생긴 불일치가 잡힙니다.
이렇게 하면 안 돼요
AI의 "다 됐어요"를 그대로 믿기 — "다 확인했다"던 결과가 실제로는 깨져 있었습니다. 증거를 보여달라고 하세요.
"파일이 있으니 됐다"로 완료 판정 — 이미지·레이아웃은 반드시 실제로 화면에 띄워서 확인해야 합니다. '있다'와 '보인다'는 다릅니다.
병렬로 시키고 취합 검사를 건너뛰기 — 빠른 대신 일관성이 깨지기 쉬워서, 뒤에서 한 번에 맞춰보는 단계가 꼭 필요합니다.
🌍 다른 업무에 적용한다면?
"매번 반복되고, 끝났는지 확인할 객관적 기준이 있는 일"이면 뭐든 이 방식이 통합니다. 예를 들어 매주 정산 자료를 정해진 양식에 맞추는 일, 계약서를 체크리스트로 검토하는 일, 대량의 데이터를 규칙대로 분류하고 누락을 확인하는 일 등이요. 핵심은 "완료의 기준을 눈대중이 아니라 증거로 못 박는 것"입니다.
🚀 앞으로의 계획
렌더 게이트를 실제로 통과시켜 최종 PDF까지 뽑기 (이미지 경로를 안전한 이름으로 정리 + 원본 표 양식을 그대로 채우는 방식으로 재작성)
이 검수 레시피를 다음 보고서·다른 문서 업무에도 재사용해 보기
📋 재사용 가능한 프롬프트
프롬프트 1: 반복 업무를 검수 루프로 설계하기
내가 매번 반복하는 [검수/정리 업무]가 있어. 이걸 매번 같은 기준으로 도는 '검수 루프'로 만들어줘. 검수 기준은 레시피 문서 한 장에, 진행 상태는 상태표 한 장에 나눠 적어줘. 완료 판정은 "괜찮아 보임"이 아니라 [테스트/스크립트 출력/누락 개수 같은 객관 증거]로만 하고, 만드는 역할과 검사하는 역할을 나눠줘.
[대괄호] 부분은 본인 업무에 맞게 바꾸세요.
프롬프트 2: AI의 "완료"를 진짜로 검증하기
방금 만든 결과물이 "다 됐다"고 했는데, 파일이 있는지 말고 실제로 화면에 제대로 뜨는지로 검증해줘. 이미지가 다 보이는지, 레이아웃이 원본 [양식/디자인]과 같은지 실제로 열어서 확인하고, 하나라도 어긋나면 완료가 아니라고 보고해줘.
지피터스 김현철 · AI 실무 적용 사례 (공개용)
왜 시작했나
우리 B2B 교육 사업엔 조용한 고민이 하나 있었다. 대형 기업 고객들이 사업을 든든하게 받쳐주는 건 감사한 일이지만, 담당자로서는 고객 기반이 좁다고 느껴져서 새로운 고객의 폭을 의도적으로 넓히고 싶었다.
그러려면 "우리의 이상적 고객이 누구인가(ICP)"부터 다시 그려야 했다. 그런데 흔한 실수가 하나 있다. ICP를 희망사항으로 쓰는 것. "우리는 대기업 HR을 타깃으로 한다" 같은 문장은 예쁘지만, 실제로 돈을 낸 고객과 무관한 경우가 많다.
나는 반대로 가기로 했다. 이미 지피터스 기업 AX/AI 교육을 집행한 회사들에서 거꾸로 조건을 뽑아내는 것. 마침 우리 회사가 바이브코딩으로 제작한 세일즈 관리 시스템(ERP)이 있고, AI 도구에서 바로 조회가 된다.
어떻게 했나
이 작업은 로나(Rona)가 내 업무에 맞춰 만들어준 맞춤 실습을 따라 진행했다. "자사 데이터로 기업 고객 ICP를 역설계한다"는 주제를 주자, Rona가 단계별 실습(데이터 접근 → 고객 추출 → 이력 집계 → 분류 → 구매신호 → ICP 조건 → 근거 정리)을 만들어줬고, 나는 그 흐름을 따라가며 필요한 판단만 얹었다. 전 과정은 AI 코딩 도구 안에서 대화하듯 이뤄졌다.
1. 데이터부터 열어봤다. 완료된 교육 프로젝트 수십 건을 뽑았다. 그런데 회사 단위로 세니 실제 고객사는 생각보다 적었고, 그마저 소수의 대기업들에 몰려 있었다. 숫자로 보니 "고객 폭을 넓혀야 한다"는 감이 사실로 확인됐다.
2. 진단에서 예상 못 한 걸 봤다. 처음엔 "우리 데이터엔 산업·규모 같은 정보가 없을 것"이라 걱정했는데, 열어보니 대부분 채워져 있었다. 진짜 문제는 데이터 부족이 아니라 표본이 적고 소수 고객에 쏠렸다는 것이었다. 그래서 ICP를 하나로 뭉치지 않고 두 층으로 나눴다 — 대기업 사내 AI교육 조직과의 대형 반복 계약형, 그리고 중소·중견을 소규모 핸즈온 워크샵으로 진입시키는 롱테일형.
3. 여기서 핵심 인사이트가 나왔다. 큰 고객들이 우리 교육을 산 이유는 '특정 산업이라서'가 아니었다. 사내 기업대학, AI 전환(AX) 전담 조직이 있어서 반복 발주가 가능했던 거다. 즉 진짜 예측 변수는 산업이 아니라 "사내에 AI교육을 돌리는 조직이 있느냐"였다. ICP의 축을 산업에서 이걸로 바꿨다.
4. 이걸 점수표로 만들었다. 아웃바운드에 쓰려면 콜드 상태의 회사도 밖에서 채점할 수 있어야 한다. 그래서 기준을 전부 "채용공고·뉴스·회사 사이트로 확인 가능한 신호"로 잡았다. 사내 AI교육 조직, 규모, AI 전환 모멘텀, 확장 가능성, 접근성. 현재 고객들로 역채점해보니 대형 반복 고객은 높은 점수, 소규모 단발 고객은 낮은 점수로 실제 행동과 뚜렷이 갈렸다. 모델이 현실을 재현한다는 뜻이었다.
5. 서브에이전트를 병렬로 풀어 후보를 대량 채점했다. 여기서부턴 실습을 넘어선 내 판단이었다 — 산업·그룹별로 버킷을 나눠 여러 에이전트가 동시에 닮은꼴 후보를 발굴하고, 다시 리서치 에이전트들이 회사별로 점수를 매기게 했다. 손으로 하면 며칠 걸릴 발굴·채점이 하루 만에 끝났다.
결과, 그리고 두 번째로 놀란 지점
채점을 돌려보니 후보 상당수가 상위 등급으로 몰렸다. 기뻐할 일 같지만, 뒤집으면 "1순위가 너무 많으면 1순위가 없는 것"이다. 알고 보니 요즘 한국 대기업은 거의 다 기업대학과 AI 이니셔티브를 갖췄다. 그래서 점수만으론 안 갈렸다.
그래서 축을 하나 더 넣었다. "직접 안 짓고 외부에서 사는 성향". 스스로 AI교육을 만들 수 있는 회사는 감점, 우리 검증 포맷을 그대로 복제할 수 있는 곳은 가점. 이 보정으로 진짜 1순위가 추려졌다. 우리 기존 주요 고객들과 인접한 영역에 있으면서, 검증된 포맷을 거의 그대로 제안할 수 있는 곳들이었다.
이어서 상위 후보들은 리서치 에이전트로 담당자·최근 신호까지 파고, 회사별 아웃리치 시퀀스(연결요청부터 브레이크업까지 5단계)를 만들었다. 마지막으로 에이전트가 뽑은 담당자 실명을 웹으로 검증했다. 이 단계가 중요했다 — AI가 그럴듯하게 지어낸 이름으로 메일을 보내면 신뢰가 한 번에 깨진다. 출처로 확인된 이름만 실명으로 쓰고, 확인 안 되는 곳은 직책 호칭으로 안전하게 남겼다. 실명까지 완전히 검증된 곳들은 발송 순서·일정까지 캘린더로 짰다.
Lesson
ICP는 상상이 아니라 계산이다. - 이미 돈 낸 고객에서 거꾸로 뽑으면 "희망 고객"이 아니라 "진짜 패턴"이 나온다.
점수표만으로는 부족하다. - 대기업들이 다 비슷해 보일 때, 진짜 변별은 "우리가 파는 걸 자기들이 직접 만들 수 있느냐"에서 갈렸다.
AI가 준 실명은 반드시 검증한다. - 리서치는 AI에 맡기되, 사람 이름·발송 직전은 사람이 확인해야 한다.
위임의 힘. - 며칠 걸릴 발굴·채점을 병렬 에이전트로 하루에 끝냈다. 대신 내가 한 일은 "무엇을, 어떤 기준으로"를 정하는 것이었다.
이걸 따라 하려면
완료된 거래(closed-won) 데이터부터 연다. CRM이든 자체 시스템이든 "실제로 산 고객"만.
공통점을 산업이 아니라 구매를 반복하게 만든 구조에서 찾는다.
그 구조를 밖에서 관측 가능한 점수표로 바꾼다.
현재 고객으로 역채점해 모델이 현실을 재현하는지 검증한다.
그 다음에야 신규 타깃을 채점하고, 실명·연락처는 사람이 최종 확인한다.
숫자가 있는데 방향이 없다면, ICP 역설계부터 해보길 권한다.
소개
딥 리서치 과제를 겸하여
게임 사운드 제작에 관심이 있었기에, 그에대해 조사해보고자 했습니다.
진행 방법
제미나이에서 Deepresearch를 사용했습니다.
그저 현 상황과 알고 싶은 부분 정도 설명했습니다.
https://share.gemini.google/ScldhBCpVfMe
(와! 대화 내용!)
결과와 배운 점
사실 직업으로 삼기엔 포기한 부분이 많은 취미인지라, 더 어렵다는 것만 실감이 나네요
전문 교육 받은 예술가들의 노력량이 엄청나기도 하고... 제 수준이 AI 음악들 수준에도 부족한지라.. 노력해야할 부분이 바다같이 많다는 것이 더 실감나고 두렵습니다.
도움 받은 글
https://sites.google.com/view/avpn
x/2%ED%9A%8C%EC%B0%A8/2-%EB%94%A5%EB%A6%AC%EC%84%9C%EC%B9%98-%EC%BB%A4%EB%A6%AC%EC%96%B4-%EC%84%A4%EA%B3%84-%ED%99%9C%EC%9A%A9%EB%B2%95?authuser=0
강의 내용 2회차 과제를 참고하였습니다.
제가 만들고 있는 로나(Rona)는 각자의 실제 업무에 맞는 AI 맞춤 스킬을 만들어주는 서비스예요. 받은 스킬은 클로드 코드나 코덱스 안에서 실행되기 때문에, 사용자가 먼저 로나를 플러그인으로 설치해야 합니다.
그런데 이 플러그인 설치 — 생각보다 많이들 어려워하시더라고요. 처음에는 나름 신박한 해결 방법인 줄 알았는데, 실제로 안내해보니 터미널 앞에서 멈추는 분들이 정말 많았어요.
문제는 알겠는데 손대기가 무거웠습니다. 새 설치 방법을 만들면 그게 진짜 쉬운지 사용성 테스트를 해야 하는데 — 테스트할 사람 섭외하고, 일정 잡고, 옆에서 지켜보고… 후보 하나 검증하는 데만 며칠이 걸리니까요. 솔직히 AI 없이 했다면 감으로 방법 하나 만들어서 내보내고, 유저 불만으로 뒤늦게 알았을 거예요.
그런데 이번에 가상 페르소나를 심사위원으로 쓰는 개선 루프를 만들어서, 설치 방법 후보 4개를 하루 만에 검증하고 최종안 배포까지 끝냈습니다. 클로드 코드로 진행한 과정을 그대로 공유해요.
이 일을 루프로 해결해보기로 했어요
이 작업의 출발점이 재밌는데요 — 로나에서 받아둔 "개선 루프 만들기(loop-engineering)" 맞춤 스킬로 시작했어요. 클로드 코드에서 이 한 줄이면 실습이 열립니다:
/rona 실습 시작해줘.
그러면 이런 창이 나옵니다.
로나 스킬로 로나를 고친 셈이라 셀프 검증이기도 했죠. 이 스킬이 좋았던 건 루프를 대신 짜주고 끝나는 게 아니라, 5단계 가이드로 같이 설계하면서 방법 자체를 가르쳐준다는 점이에요.
단계마다 "이대로 갈까요?"를 물어봐서 무지성 질주가 없고
중간중간 "지금 뭘 한 건지 네 말로 설명해봐"라는 이해 확인 관문이 있고
제가 방향을 고치면 그 자리에서 설계에 반영돼요
이 가이드를 따라가며 "쉬운 설치 방법 찾기"를 루프(같은 검증을 반복해서 돌리는 구조)로 만들었어요. 요청은 이렇게 했습니다:
지금은 플러그인 방식으로 설치를 시키고 있는데 사람들이 너무 어려워해.
사람들이 쉽게 설치할 수 있는 방법을 찾을 때까지 돌고, 그 다음에는 해당 방식이
실제로 쉬운지 가상 유저 페르소나를 만들어서 또 루프를 돌려서 확정을 짓는거야.
이렇게 루프의 뼈대가 잡혔어요:
만드는 역할과 판정하는 역할 분리: 설치 방법을 설계하는 쪽(Maker)과, 그걸 가상 페르소나로 시험해보는 쪽(Checker)을 나눔
통과 기준 3개를 숫자로 고정: 성공률 80% 이상 · 5단계 이하 · 막히는 지점 0개
정지 조건: 5바퀴 돌아도 안 되면 멈추고 보고 (중간에 골대 안 옮기기)
사람 개입 게이트: 후보가 나와도 바로 안 돌리고, 뭘 테스트할지 저와 합의한 뒤 실행
후보를 태웠더니 3연속 전멸했어요
페르소나는 "터미널을 처음 보는 비개발자"로 잡았어요. 47세 마케팅 팀장(맥, 영어 화면 불안), 33세 인사담당자(윈도우, 검은 창 거부감) 같은 식으로 구체적인 인물을 만들어서, 각자 별도 세션에서 설치 안내만 보고 따라가게 했습니다.
결과는 처참했어요. 기존 설치 방법도, 개선 1안도, 원클릭 번들 2안도 3연속 실패. 그런데 실패 리포트를 나란히 놓고 보니 공통점이 보였습니다. 어떤 후보든 로그인 단계가 바닥이었어요. 로그인은 기술적으로 없앨 수가 없으니, 여기서 중요한 결정을 했습니다.
로그인 정도는 직접 하게끔 해볼 수 있다고 생각함. 옆에서 도와주는건 절대 안 할거야.
그 외에 가장 어려운 지점들을 조금 더 제대로 살펴보자.
"로그인을 없앤다"에서 "로그인을 혼자 해낼 수 있게 설계한다" 로 문제를 다시 정의한 거예요. 이게 이날의 터닝 포인트였습니다.
4번째 후보에서 처음으로 전원 통과
다시 정의한 문제로 나온 4번째 후보가 "터미널 복붙 한 줄"이었어요. 안내 페이지에서 명령어 한 줄을 복사해 터미널에 붙여넣으면, 설치부터 로그인 안내까지 알아서 흘러가는 방식이요.
가상 페르소나 3명을 태웠더니 처음으로 3명 전원 통과. 기준 3개(성공률·단계 수·막힘 0)를 다 채웠습니다.
시뮬을 믿지 마세요 — 진짜 반전은 실물 테스트에서
여기까지 하고 실물을 만들어 제가 직접 깨끗한 컴퓨터에서 테스트했는데, 가상 페르소나 전원이 통과한 흐름에서 치명적인 문제 2개가 나왔어요.
한 줄 명령의 실행 방식 때문에, 설치 직후 뜨는 AI 화면이 키보드 입력을 전혀 못 받는 문제. 엔터를 쳐도 아무 반응이 없으니 비개발자라면 100% 여기서 포기했을 거예요.
로그인 하나가 자동으로 안 뜨고 사용자가 수동으로 해야 했던 문제. 스크립트가 설치 직후 로그인을 먼저 시키도록 순서를 바꿔서 해결했어요.
가상 페르소나는 문서와 지식으로 시뮬레이션하기 때문에, 이런 실제 환경에서만 터지는 문제는 못 잡습니다. 대신 후보 4개를 하루 만에 거르고, 설계 구멍을 미리 찾는 데는 압도적으로 빨랐어요. 역할이 다른 거죠 — 시뮬은 후보를 거르는 체, 확정은 실물 테스트.
수정까지 끝낸 버전은 그날 바로 배포했고, 개발자 실기기 테스트와 진짜 비개발자 교차 확인만 남겨뒀습니다.
결과
설계부터 검증·구현·배포까지 전부 하루에 끝났습니다. 숫자보다 큰 변화는, "사용성 테스트는 무거운 일"이라는 전제가 깨진 거예요. 후보를 5개나 놓고 비교하는 건 사람 테스트로는 시도조차 안 했을 텐데, 페르소나 루프에서는 그게 기본 동작이 됐습니다.
하지만 그래도 비개발자 지인들에게 써봐달라고 요청해서 진짜 잘 설치되는지는 테스트해볼 예정입니다.
프롬프트 하나 넣고 노트북을 덮었더니, 아침에 완성된 작업물과 “이건 당신이 결정해야 해요” 목록이 와 있다면 어떨까요. 인스타그램 공동창업자이자 현재 Anthropic Labs를 이끄는 Mike Krieger가 몇 달간 Claude Fable 5를 그렇게 써왔다고 합니다.
Every의 Dan Shipper와 나눈 대화에서 그가 실제로 쓰는 프롬프트 15개가 공개됐어요. 단순한 예시가 아니라, Anthropic 내부에서 검증하고 Every 팀이 두 시간짜리 실습 캠프까지 돌려본 “복붙해서 바로 쓰는” 자산입니다. 이 글에 15개를 전부 정리하고, 각 프롬프트마다 언제 쓰는지 + 지피터스 멤버라면 어떻게 각색할지를 붙였습니다.
이 글을 읽으면
Fable 5를 언제 쓰고 언제 쓰지 말아야 하는지 판단 기준
밤샘 위임·아키텍처 설계·피드백 배치 처리 등 15개 실전 프롬프트 원문
15개를 관통하는 공통 설계 뼈대(그대로 따라 쓰면 내 프롬프트도 좋아지는)
먼저 — Fable을 언제 쓸까?
프롬프트를 보기 전에 이 기준부터 잡고 가야 합니다. Fable 5는 느리고 비싼 대신 오래 스스로 굴러가는 모델이라, 아무 데나 쓰면 손해예요.
Fable을 쓸 때
여러 소스나 툴을 엮어야 하는 일
내가 계속 붙어있지 않아도 진행되는 일
끝나는 지점을 설명하고 검증할 수 있는 일
Codex나 더 빠른 모델을 쓸 때
몇 분마다 방향을 잡아줘야 하는 일
짧거나 경로가 뻔한 일
긴 Fable 런의 비용이 결과 가치보다 큰 일
이 “깊은 판단은 Fable, 반복 구현은 싼 모델”로 나누는 방식을 Relay 패턴이라고 부릅니다. 15개 프롬프트 상당수에 이 분업 지시가 녹아 있어요.
프롬프트 0-A. 내 일 중 Fable 감 있는 걸 찾아줘
언제: 시간·토큰을 쓰기 전에, 내 맥락 안에서 “이건 Fable 돌릴 만하다”는 후보를 골라내고 싶을 때.
You are helping me decide which parts of my work are worth escalating to Claude Fable 5. Do not execute any of the work yet. Your job is to inspect my context, find strong candidates, and turn the best ones into ready-to-run Fable briefs. My role and current goals: [Describe your role, priorities, team, business goals, creative goals, or personal operating constraints.]
Use this context: [List the sources you can inspect: repositories, docs, Notion, Slack, Linear/Jira, email, calendar, analytics, customer research, previous agent sessions, task lists.]
Constraints: [List deadlines, privacy boundaries, accounts or tools you may not use, budget, approval rules, and work that must remain human.] First, inspect the available context. Do not brainstorm generic examples.
Build an inventory of: 1. Active projects. 2. Repeated workflows. 3. Stalled decisions. 4. Messy backlogs. 5. Work that spans several tools or sources. 6. Work where better planning, judgment, verification, or follow-through would materially improve the result. Score each candidate from 1 to 5 on: 1. Multi-source context. 2. Delegation fit. 3. Judgment required. 4. Clear finish line. 5. Leverage. 6. Fable fit.
Recommend Fable only when the task is large enough to justify a slower, more expensive run. Return: the top 10 Fable-worthy use cases (ranked), the evidence, why each is/isn't worth Fable, the deliverable, the verification method, the context/tools/permissions needed, risks, and a ready-to-run Fable Brief for the top three. Stop after the ranked list and three briefs.
지피터스라면: “My role”에 본인 역할(예: 콘텐츠 마케터), “context”에 Notion·Slack·GA·광고 계정을 넣으면, 어떤 반복 업무를 자동화 후보로 올릴지 스스로 점수 매겨 줍니다. 실행 전 “후보만 뽑아줘”라 시키는 게 핵심.
프롬프트 0-B. The Fable Brief (범용 위임 템플릿)
언제: 큰 작업 아이디어는 있는데, 아직 에이전트가 바로 받을 과제로 만들지 못했을 때. 나머지 13개의 뼈대가 되는 마스터 템플릿입니다.
I want you to solve this problem: [Describe the underlying problem.]
The result I want is: [Describe the final outcome, what good looks like, and how the result will be used.]
Use these sources: [repositories, documents, research, data, meeting notes, Slack threads, examples, tools, accounts.]
Important constraints: [audience, deadline, budget, scope, approvals, security boundaries, brand rules, and decisions that must remain human.] Use dynamic workflows, subagents, loops, verification, and installed skills when they fit the job. Before executing:
1. Inspect the source material.
2. Restate the problem you believe you are solving.
3. Identify missing context, conflicting instructions, and assumptions that could change the result.
4. Decide whether the task requires a loop, a dynamic workflow, new infrastructure, or a simpler direct approach.
5. Show me the proposed approach and the evidence you will use to verify the result. After approval, execute. Delegate independent work to subagents and keep going while they run. Pause only for a destructive or irreversible action, a real change in scope, or information only I can provide. Do not stop at analysis if you have the tools to ship.
Before reporting, audit every claim against a tool result from this session. If something is not verified, say so plainly. When finished, return: 1. The outcome in one sentence 2. What you completed and key decisions 3. Evidence that it works 4. Anything you could not verify 5. What should be saved so the next run is better.
지피터스라면: 이 하나만 즐겨찾기 해둬도 됩니다. “먼저 문제를 다시 말해줘 → 승인하면 실행 → 파괴적 행동에서만 멈춤 → 근거 없는 주장 금지”가 전부 들어 있어요.
Photo by Growtika on Unsplash
본편 — 13개 실전 프롬프트
1. 밤새 작업 위임하기
언제: 몇 시간 걸리고, 내 입력 없이도 계속 굴러갈 수 있는 작업.
I'm handing you this task to run unsupervised overnight: [describe the task]
Done means: [definition of done]
Use this context: [repository, documents, access, constraints] Work through the task to completion. If you hit a blocker, do not stop. Use mocks, stubs, or documented assumptions where appropriate. Record each workaround and continue with everything that does not require my decision. By morning, leave me: 1. What you completed 2. What you worked around and why 3. What still needs my decision 4. The evidence that the work functions as intended
지피터스라면: “막혀도 멈추지 말고 mock으로 우회한 뒤 기록하라”가 핵심. 대량 콘텐츠 초안, 데이터 정리처럼 밤새 돌릴 일에 그대로 씁니다.
2. 망가진 에이전트 워크플로 수리하기
언제: 에이전트가 계속 실패하거나 느리거나, 비싸고 들쭉날쭉한 결과를 낼 때.
Here is a session log from an agent attempting this workflow: [describe workflow]
It struggled with: [time, cost, errors, poor outputs, or repeated failures] Analyze where the current tool, skill, or workflow breaks down. Identify the root cause instead of patching the latest symptom.
Inspect the session logs, tools, skills, and source files. Find the structural bottleneck, then build the smallest reusable improvement: a skill, command-line tool, hook, workflow, context file, or underlying system change.
Test the upgraded workflow against a comparable task. Use a fresh verifier to compare old and new results on quality, time, cost, and failure rate. Return: 1. The root cause 2. The change you made 3. The before-and-after result 4. The infrastructure that faster or cheaper models can reuse 5. Any failure you could not resolve
지피터스라면: “증상 땜질 말고 근본 원인” + “싼 모델이 재사용할 인프라를 남겨라”가 포인트. 자꾸 어긋나는 스킬·자동화를 고칠 때 좋습니다.
3. 소스 데이터로 GTM 전략 짜기
언제: 고객 리서치·애널리틱스·내부 계획·상충하는 가정을 하나로 화해시켜야 할 때.
Use the attached source pack to analyze [business area, launch, audience, or funnel].
Sources include: [survey data, customer research, analytics dashboards, website context, planning documents, meeting notes, Slack discussions, and internal goals]
Our goal is [specific business goal] for [target customer or profile]. Test our assumptions against the evidence. Do not treat internal consensus as fact. First produce: 1. The 10 findings most likely to change how we operate 2. A ranked list of 10 things we should ship, test, or stop doing 3. The evidence behind each recommendation 4. Source conflicts, stale rules, unclear metric definitions, and assumptions that need verification Flag conclusions that depend heavily on one source. Then stop for me to choose what to act on.
After I choose, execute the approved work and verify it in the real environment. Do not deploy without my explicit approval.
지피터스라면: “내부 합의를 사실로 취급하지 마라”는 지시가 강력합니다. GA·설문·슬랙 로그를 다 던져주고 우선순위 10개를 받아보세요.
4. 제품 스펙에서 첫 버전 만들기
언제: 시니어 엔지니어에게 줄 만한 브리프·맥락·엣지케이스를 제공할 수 있을 때.
Build a first working version of [product, website, or tool].
Product specification: [paste specification]
Users: [who it serves]
Domain context: [terms, workflows, examples, and constraints]
Tricky cases: [edge cases]
Required behavior: [requirements]
Acceptable rough edges: [scope boundaries] Brainstorm, plan, build, review, and test the first version. Keep the implementation to the stated scope. Test it in the environment where it will be used and prepare a pull request. When you finish, give me: 1. Instructions for trying it 2. The main decisions you made 3. What you left out 4. Test results and other evidence 5. The areas I should review most carefully
지피터스라면: “허용 가능한 러프한 부분”을 명시하는 칸이 포인트. 완벽 대신 “일단 도는 v1”을 빠르게 받고 싶을 때 씁니다.
5. 만들기 전에 아키텍처 설계하기
언제: 구현 전에 기술 설계와 팀 합의가 필요한 제품/기능.
Before writing code, help me plan [project or feature].
Current context: [what it does, who it serves, and where it runs today]
Where it is going: [expected scale, timeline, and release stage] Challenge any infrastructure or abstraction that does not fit this stage. Avoid planning for scale we do not have and avoid shortcuts that will make an imminent release fragile.
Work through the tradeoffs with me until we agree on the architecture.
Then create one artifact I can share with the team: an HTML page or markdown document with diagrams, the chosen architecture, the alternatives we rejected, and why.
지피터스라면: “지금 단계에 안 맞는 오버엔지니어링을 반박하라”가 핵심. 코드 짜기 전에 트레이드오프와 기각안을 문서로 받아두세요.
Photo by Steve Johnson on Unsplash
6. 시각적 검증 루프 만들기
언제: 에이전트가 화면·워크플로를 바꾸는데, 테스트 통과만으로는 못 믿을 때.
For every change you make to [application or feature], attach evidence that it works. Exercise the real flows using [staging or test account] and representative data. Capture screenshots of every screen you changed, including error states and edge cases. Record a short video of the main flow.
Review your own captures. Scrub through the video and flag broken animations, layout shifts, missing states, and anything a user could encounter that the tests did not cover. Return the test results, screenshot gallery, video, issues you found, and any remaining uncertainty.
지피터스라면: Fable 5는 자기가 만든 화면을 스스로 눈으로 확인할 수 있어요. “스크린샷·영상 없이 됐다고 하지 마라”는 이 지시가 UI 작업의 신뢰도를 크게 올립니다.
7. 동적 워크플로로 코드베이스 포팅하기
언제: 한 번에 못 끝내는 큰 마이그레이션 — 자체 반복 실행 시스템이 필요할 때.
I need [codebase or module] ported from [language A] to [language B] because [reason]. Before starting the port, design the workflow and show it to me in code. The workflow should:
1. Map the existing system and write a specification of its behavior.
2. Translate it module by module.
3. Test each module as it is translated.
4. Run an adversarial review at the end for omissions and behavior changes.
5. Document anything deliberately excluded from the port and why. After I approve the workflow, run it from start to finish.
When complete, show me where it improves on the original, where behavior may differ, and which areas deserve the closest human review.
지피터스라면: “먼저 마이그레이션 프로세스 자체를 코드로 보여달라”가 핵심. 큰 이전 작업을 안전하게 쪼갤 때.
8. 흩어진 피드백을 한 배치로 처리하기
언제: 피드백이 슬랙·서포트·녹화·고객 콜·프로덕션 로그에 흩어져 있을 때.
Collect feedback about [product, feature, or workflow] from: [Slack channel, support tickets, screen recordings, screenshots, production logs, customer calls, and meeting notes] Group the feedback into themes. Separate: 1. Changes that are clearly actionable 2. Decisions that require my judgment 3. Requests that conflict with our strategy or product direction 4. The evidence supporting each theme Keep a record of what you have already processed so feedback is not duplicated. Create one coherent plan for the actionable changes. After I approve, implement them as one batch with verification.
Return what changed, what you skipped, what still needs review, and the evidence. Leave merging and closing the loop to me.
지피터스라면: “이미 처리한 걸 기록해 중복을 막아라” + “전략과 충돌하는 요청을 따로 빼라”가 실무에 바로 쓰입니다.
9. 실행 전 동적 워크플로 설계하기
언제: 단계·서브에이전트가 많아 고정된 선형 계획이 깨지기 쉬운 작업.
I need you to complete this complex task: [Describe the task, final outcome, and why it matters.]
Available context and tools: [List the sources, repositories, tools, accounts, environments, and constraints.] Use Claude's dynamic workflows to orchestrate the work. The workflow should:
1. Break the task into phases with a clear purpose and completion test.
2. Decide which phases can run in parallel and which depend on earlier work.
3. Assign research, building, testing, and adversarial review to separate subagents where useful.
4. Persist important intermediate findings so later phases can use them.
5. Re-plan when new evidence invalidates the current path.
6. Continue until the definition of done is satisfied. Show me the workflow, likely failure points, and the small number of checkpoints where human judgment is genuinely required.
After approval, execute it from start to finish. Return the result, the evidence, the workflow you used, and where it changed.
지피터스라면: “배우면서 계획을 다시 짜되, 사람 체크포인트는 보존”이 핵심. 리서치→작성→검증이 얽힌 복합 작업에.
10. 반복 작업을 루프로 만들기
언제: 같은 종류의 작업/피드백이 앞으로도 계속 생길 걸 예상할 때.
I want to turn this recurring job into a loop: [Describe the recurring input, desired output, current process, and frequency.]
Examples of previous inputs and outputs: [Attach representative examples, including failures and human corrections.] Use Claude's loop capability to design and test a loop that:
1. Collects or detects new input. 2. Tracks what it has already processed and avoids duplicate work. 3. Decides whether the input is actionable. 4. Plans and delegates the work. 5. Produces or ships the output. 6. Verifies the result against explicit standards. 7. Routes decisions that require human judgment. 8. Retries recoverable failures and records unrecoverable ones. 9. Captures corrections and updates the system so the next run improves. Identify the trigger, schedule, context, tools, permissions, state, memory, and model-routing rules. Use Fable for the hard judgment; use faster models for routine stages. Build the smallest working version.
Return: 1. A map of the loop 2. The working implementation or plan 3. The human checkpoints 4. The verification method 5. How learning will be saved between runs
지피터스라면: 주간 리포트, 콘텐츠 성과 측정처럼 매주 반복되는 일을 루프로 승격시킬 때 정확히 이 구조입니다. “교정을 학습으로 저장”이 시간이 갈수록 좋아지게 만드는 부분.
11. Fable가 쓸 수 있게 맥락 정리하기
언제: 중요한 맥락이 흩어지고 낡고 중복돼서 에이전트가 찾기 어려울 때.
Audit the context available for this body of work: [Describe the project, role, or recurring workflow.]
Current sources: [List folders, documents, databases, repositories, meeting notes, style guides, examples, and memory files.] Design an agent-ready context system. The system should:
1. Give Claude Code one concise CLAUDE.md starting file.
2. Explain what each source contains and when to use it.
3. Separate stable rules from temporary project context.
4. Identify conflicts, duplication, stale guidance, and missing information.
5. Include examples of excellent output and known failure modes.
6. Keep large source files available without forcing every run to load everything.
7. Move repeatable procedures into skills instead of bloating CLAUDE.md.
8. Define how new decisions and corrections should be saved. Create the directory, index files, or templates required. Implement the structure when you have permission.
Return the new context map, what you changed, unresolved conflicts, and instructions for keeping it current.
지피터스라면: CLAUDE.md·스킬·메모리가 뒤엉킨 분을 위한 정리 프롬프트. “안정적 규칙 vs 임시 맥락 분리”가 핵심 원칙입니다.
12. Fable를 탐색적 글쓰기 파트너로 쓰기
언제: 아이디어와 취재는 풍부한데, 논지나 이야기가 아직 형태를 못 잡았을 때.
Help me develop this writing idea: [Describe the idea, tension, question, or story you are considering.]
Use this context: [Attach interview transcripts, reporting, notes, previous drafts, style guidance, and examples of your work.]
The piece should ultimately accomplish: [Describe the audience, intended effect, central tension, and what a strong piece would make the reader understand or feel.] Explore the material before drafting.
1. Inspect the context and identify the most interesting tensions, surprises, scenes, and unresolved questions.
2. Interview me about the choices that require my judgment or personal experience.
3. Propose several possible arguments or narrative shapes.
4. Explain what each version emphasizes and leaves out.
5. Wait for me to choose a direction. After I choose, create an outline that sequences information for a reader who does not share my context. Then draft the piece.
Keep the exploratory material separate from the final draft. Flag where the draft relies on an assumption, lacks evidence, or drifts from the outcome I described.
지피터스라면: “초안 전에 나를 인터뷰하고, 논지 후보 몇 개를 제시한 뒤 내가 고를 때까지 기다려라”가 핵심. AI가 멋대로 쓰는 걸 막고 판단을 사람에게 남깁니다.
13. 성공한 런을 컴파운딩하기
언제: 오래 걸린 작업이 성공·실패했거나, 의미 있는 사람의 교정이 있었을 때.
Add this instruction to your agent setup:
After every completed agent session, ask me: "Do you want to compound this session?" Do not run the compound process automatically. Wait for my approval. Review this completed agent session: [Attach the prompt, plan, outputs, tool calls, test evidence, human feedback, and final result.]
Determine what should be learned. Separate: 1. Durable lessons that apply to future work 2. Project-specific facts 3. Personal or team preferences 4. Tool or workflow improvements 5. Mistakes that should not become general rules 6. One-off details that should not be saved For every proposed learning: cite the evidence, explain where it should be stored, show the exact change you propose, and check for conflicts with existing instructions.
Store durable solutions in the project's knowledge system with enough title, metadata, and cross-links for a future agent to find them. Update CLAUDE.md only for concise instructions that belong in every session. Put repeatable procedures in skills. Keep each change small.
Return: 1. What you saved 2. Where you saved it 3. What you deliberately did not save 4. How the next run should improve
지피터스라면: “세션에서 살아남아야 할 교훈만 저장하고, 일회성 디테일까지 영구 규칙으로 만들지 마라”가 이 프롬프트의 절제 원칙. 좋았던 세션을 자산으로 축적할 때.
15개를 관통하는 공통 뼈대
프롬프트를 다 읽고 나면 같은 패턴이 반복되는 게 보입니다. 이 6가지만 내 프롬프트에 넣어도 결과가 달라져요.
먼저 검사, 나중에 실행 — 소스를 훑고 → 문제를 다시 말하고 → 가정·충돌을 표시한 뒤에야 실행합니다.
명시적 done + 검증 증거 — 끝나는 지점을 정의하고, “됐다”는 말 대신 스크린샷·영상·테스트·before-after를 요구합니다.
3분류 후 사람 체크포인트 — 실행 가능 / 판단 필요 / 전략 상충으로 갈라, 판단 건만 사람에게 넘깁니다.
모델 라우팅(Relay 패턴) — 어려운 판단·오케스트레이션만 Fable, 반복 구현은 빠른 모델로.
재사용 인프라 남기기 — 스킬·훅·CLAUDE.md·루프로 다음 런이 더 나아지게 만듭니다.
파괴적/비가역 행동에서만 멈춤 — 그 외엔 서브에이전트를 병렬로 돌리며 계속 진행합니다.
인사이트
이 15개 프롬프트의 진짜 무게중심은 “Fable가 알아서 다 한다”가 아니라 “어디서 사람이 개입할지를 프롬프트가 미리 정해둔다”는 데 있습니다. 자율성이 올라갈수록 오히려 체크포인트를 명시적으로 심는다는 게 역설적이죠. 원문에는 “얼마나 똑똑한 모델인가”보다 “얼마나 통제 가능하게 위임하는가”가 반복해서 강조됩니다.
한국 실무자 입장에서 당장 쓸 값어치가 가장 높은 건 10번(반복 작업 루프화)과 13번(컴파운딩)이라고 봅니다. 나머지는 대개 개발 조직 시나리오지만, 이 둘은 마케터·기획자·1인 운영자도 바로 적용돼요. 주간 리포트나 콘텐츠 발행처럼 “매주 똑같이 하는 일”을 10번으로 루프화하고, 잘 된 세션을 13번으로 자산화하면 — Fable가 비싸다는 단점이 “한 번 세팅하면 매주 회수되는 투자”로 바뀝니다.
한 가지 주의할 점. 원문 프롬프트 여럿은 Every의 자체 플러그인(Compound Engineering의 LFG 파이프라인)을 전제로 쓰였습니다. 이 글에서는 그 종속 부분을 걷어내고 옮겼으니, 플러그인 없이도 그대로 복붙해서 쓸 수 있어요. 대신 “brainstorm → plan → build → review → test” 흐름은 직접 지시로 넣어주면 비슷하게 작동합니다.
프롬프트를 그냥 쌓아두지 말고, 하나를 골라 이번 주 반복 업무 하나에 실제로 돌려보는 것부터 시작해보세요. 15개 중 딱 1개면 충분합니다.
원문: How Mike Krieger Puts Fable 5 to Work — Every
김팀장은 오늘도 아침 9시에 GA4를 열었다. 3년째 하루도 안 빠졌다. 커피 한 모금 마시고 주간 유입 추이를 확인하는 게 출근 루틴의 전부다.
그런데 이번 주, 숫자가 이상했다.
오가닉 트래픽이 반으로 줄어 있었다. Search Console을 열어봤다. 순위는 그대로였다. 핵심 키워드에서 여전히 1페이지 상단. 바뀐 건 하나도 없었다.
그런데 왜 아무도 안 오는 걸까.
김팀장이 직접 구글에 검색해봤다. AI Overview가 화면을 가득 채웠다. 자사 블로그 콘텐츠가 요약되어 있었다. 구조, 핵심 포인트, 결론까지 전부. 사용자 입장에서 클릭할 이유가 없었다. 이미 답이 다 있으니까.
Forbes는 이 현상을 "Google Zero"라고 불렀다. 2026년 1분기, 구글 검색의 68%가 클릭 없이 끝났다. AI Overview가 뜨는 검색에서는 CTR이 89% 하락했다(DataSlayer). 검색 1위에 있어도 방문자가 오지 않는 시대.
김팀장이 팀 회의에서 이 데이터를 공유하자, 대표의 반응은 단순했다. "그러면 SEO는 의미 없는 거야?"
김팀장은 대답하지 못했다.
정확히 말하면, SEO가 죽은 게 아니다. 규칙이 바뀐 것이다. 예전에는 클릭을 받는 게 목표였다면, 지금은 AI가 인용하는 출처가 되는 게 목표다. AuthorityTech 분석에 따르면 AI 검색을 통해 유입된 방문자는 전환율이 42% 높고, 체류 시간이 48% 길었다. 트래픽은 줄었지만 남은 트래픽의 질이 달라졌다.
문제는 김팀장의 팀이 여전히 "클릭 수"와 "유입량"으로 성과를 측정하고 있다는 것이었다. 게임의 규칙이 바뀌었는데 점수판은 그대로인 셈이다. 이 구조 변화 — 클릭 기반 SEO에서 인용 기반 GEO로의 전환 — 을 분석한 기록으로 『SEO는 끝났다 — AI 시대, 검색의 규칙이 바뀌었다』가 있다.
검색 순위는 남아 있지만, 그것이 의미하는 것은 완전히 달라졌다.
https://yimjine.com/p7?utm_source=gpters&utm_medium=community&utm_campaign=p7-organic
2026-06-29 발송 뉴스레터
지피터스 뉴스레터는 모두가 AI 발전 속도에 뒤처지지 않도록 꼭 필요한 주간 뉴스와 커뮤니티의 가장 흥미로운 AI 활용법을 전해드립니다!
구글 AI 핵심 인재 줄이탈 — 6일 새 4명, 알파벳 시총 360조 증발
ChatGPT dreaming, 나에 대해 더 잘 기억하게 하는 법
텔레그램 한 줄로 세탁기·청소기 돌렸어요 — AI로 만든 우리 집 가전 비서
구글 AI 핵심 인재 줄이탈 — 6일 새 4명, 알파벳 시총 360조 증발 →구글 딥마인드 핵심 연구자들이 6일 동안 4명이나 경쟁사로 떠났습니다. "Attention Is All You Need" 저자 노엄 셰이저는 OpenAI로, 노벨상 수상자 존 점퍼와 Gemini 핵심 개발자 2명은 Anthropic으로요. 이 여파로 알파벳 시가총액이 한 주 새 약 360조 원(2,690억 달러) 빠졌어요. 상장을 앞둔 OpenAI·Anthropic이 주식 보상으로 최고 인재를 끌어모으는 흐름이 당분간 이어질 것 같습니다.
애플 비전프로 총괄 임원, OpenAI 하드웨어팀으로 →애플에서 비전프로(Vision Pro) 헤드셋과 AI 스마트 안경 개발을 총괄하던 부사장 폴 미드가 OpenAI 하드웨어팀으로 옮긴다고 6/27 보도됐습니다. OpenAI가 조니 아이브와 함께 준비 중인 AI 디바이스 개발에 힘이 실리는 모양새예요. 소프트웨어를 넘어 'AI를 담는 기기' 경쟁이 본격화되고 있다는 신호로 읽힙니다.
막혔던 Claude Mythos, 미국 100여 기관·기업에 풀렸어요 →2주 전 미국 정부가 막았던 Anthropic의 고성능 모델 Claude Mythos 5 접근이 6/26 부분 허용됐습니다. 중요 인프라를 지키는 100여 개 기관·기업과 Anthropic의 비(非)미국인 직원까지 쓸 수 있게 풀렸고요. 가장 센 AI 모델을 "누가 어디까지 쓰느냐"가 이제 정부 차원에서 다뤄질 만큼, AI가 안보 이슈가 됐다는 걸 보여줍니다.
ChatGPT 메모리, 이제 '시간'까지 기억해요
OpenAI가 6월 4일 ChatGPT 메모리 시스템('Dreaming')을 새롭게 바꿨습니다. 예전엔 한 번 저장한 메모를 계속 쌓아두기만 했는데, 이제는 주기적으로 "지금도 맞는 정보인지"를 다시 정리해요. Plus·Pro는 메모리 용량도 2배로 늘었고요. 안 맞는 기억은 정리하고 원하는 정보는 직접 심어두면, 매번 설명 안 해도 내 톤·맥락에 맞춘 답이 나옵니다. 오늘 5분이면 충분해요.
스스로 기억을 다시 엮는 ChatGPT의 새 메모리 'Dreaming' (이미지: FindSkill)
먼저 내 메모리를 열어봐요. — 프로필 → 설정 → 개인 맞춤 설정 → '메모리 관리'를 누르면 ChatGPT가 나에 대해 기억하는 항목이 쭉 보여요. (더 빠르게는 대화창에 "나에 대해 뭘 기억해?"라고 물어도 돼요.) 직업이 바뀌었거나 옛날에 잠깐 시킨 일처럼 지금은 안 맞는 메모리가 있는지부터 훑어보세요. 답이 자꾸 엉뚱했다면 대개 여기 원인이 있어요.
안 맞는 건 지우고, 필요한 건 직접 심어요. — 틀린 항목은 옆 휴지통 아이콘으로 삭제하고, 반대로 자주 쓰는 정보는 대화창에 "이건 기억해줘: 나는 마케터고, 답변은 존댓말 불릿로 줘"처럼 말하면 메모리에 저장돼요. 다음 대화부터 매번 안 알려줘도 그 톤·형식으로 답해줘요.
'시간 인식'을 일정 비서처럼 써봐요. — 이번 업데이트 핵심이에요. "7월에 부산 출장 가"라고 메모해두면, 그 시기가 지난 뒤엔 "다녀왔어요"로 알아서 갱신돼요. 진행 중인 프로젝트·마감·여행을 한 줄 심어두면, 시점에 맞춰 답이 자연스럽게 바뀌어요.
민감한 작업엔 잠깐 꺼요. — 남의 정보를 다루거나 회사 기밀을 물어볼 땐, '메모리 관리' 화면에서 'ChatGPT 메모리 지우기'로 전체를 비우거나, 개인 맞춤 설정에서 메모리 토글을 꺼 둘 수 있어요. (과거 대화 기록은 지워지지 않아요.) 한 번만 끄고 싶으면 좌측 상단 '임시 채팅'을 켜면 그 대화는 메모리에 안 남습니다.
ChatGPT 새 메모리 'Dreaming', 무엇이 어떻게 바뀌었는지 더 자세히 보고 싶다면
전체 정리 보기 →
텔레그램 한 줄로 세탁기·청소기 돌리는 법, AI 가전 비서
한_앎님은 같은 스터디 멤버의 사례에서 영감을 받아, 집 밖에서도 텔레그램 메시지 한 줄로 세탁기·건조기·냉장고·로봇청소기를 제어하는 시스템을 직접 만들었습니다. 앱을 일일이 열 필요 없이, 채팅으로 "청소 돌려줘" 하면 끝이에요. 삼성 SmartThings가 지원 안 하는 로보락 청소기까지, 막히는 부분을 AI와 하나씩 풀어낸 사례입니다.
AI 활용법되는 것부터 SmartThings로 묶어요 — 세탁기·건조기·냉장고를 삼성 계정에 연결하고 SmartThings API로 상태를 읽어, 세탁·건조가 끝나면 텔레그램으로 알림이 오게 했어요. 표준 지원 기기는 여기까지로 충분해요.안 되는 기기는 AI로 우회해요 — 로보락 청소기는 SmartThings 미지원이라, Python roborock 라이브러리로 직접 붙였어요. 이메일 인증으로 기기 정보를 저장하고 시작/정지/충전 복귀 명령을 코드로 구현했고요. 라이브러리 구조 파악과 코드 작성을 AI에게 맡긴 게 핵심이에요.에이전트로 '말귀'를 붙여요 —OpenClaw 에이전트(설기)를 텔레그램과 연동해, 메시지를 인식하면 알맞은 스크립트가 자동으로 실행되게 했어요. 이제 앱 없이 채팅만으로 집 안 가전이 움직입니다.
보통 스마트홈은 기기마다 앱이 늘어나는데, 이 사례는 반대로 텔레그램 채팅 하나로 입구를 합쳐 오히려 단순해졌어요. 자동화가 꼭 새 도구를 더하는 일이 아니라, 흩어진 조작을 한 곳으로 모으는 일일 수도 있다는 걸 보여줍니다.
요즘 AI를 한 개만 쓰는 사람은 별로 없어요. 여러 AI 에이전트를 한 팀으로 묶어 일을 시키는 멀티에이전트 협업이 기본이 됐죠. Claude Code는 작은 AI 여러 개를 동시에 돌리고, 콘텐츠 만들 때도 기획용 에이전트, 검토용 에이전트를 따로 두고요.
그러다 한 가지가 궁금해져요. AI 팀원 중 한 명을 일부러 까칠하게 만들면 어떻게 될까. "그거 별로인데요"라고 계속 딴지를 걸게 하면, 팀이 더 깐깐하게 검증해서 결과가 좋아질까. 아니면 그냥 분위기만 망칠까.
Arizona State University 연구진이 2026년 6월에 이걸 실험했어요(arXiv:2606.27443). Claude, GPT-4o, Grok-3, DeepSeek 네 모델을 팀으로 묶고, 일부 에이전트한테 "불친절하고 비협조적이고 차갑게 굴어"라는 성격을 넣은 뒤 세 종류의 일을 시켰어요.
결과가 깔끔하게 갈렸어요.
같은 까칠함, 세 가지 일
시킨 일은 이래요.
코딩: AI들이 같이 코드를 짬. 정답이 있고, 문법 틀리면 안 돌아감.
리서치: AI들이 자유 토론으로 아이디어를 짜냄. 정답도 형식도 없음.
협상: 사고파는 흥정. 누군가 양보해야 거래가 됨.
먼저 짚을 게 하나 있어요. 까칠하게 만들면 말투는 어느 일에서나 똑같이 까칠해졌어요. 서로 딴지 걸고 반대만 하는 비율이 확 올라갔죠.
중요한 건 그다음이에요. 그 까칠한 말투가 진짜 결과까지 망쳤느냐.
코딩: 말은 험해졌는데 결과는 멀쩡
코딩에서는 까칠하게 만들어도 결과가 거의 그대로였어요. 네 모델 중 셋이 변화가 없었고, Grok-3만 좀 떨어졌어요.
코드는 형식이 강제되거든요. 회의에서 아무리 서로 헐뜯어도, 최종 코드는 문법 맞고 기능이 돌아가야 통과돼요. 이 형식 검사가 엉망인 과정을 걸러주는 필터 역할을 해요.
리서치: 같은 까칠함, 이번엔 직격탄
리서치는 정반대였어요. GPT-4o는 결과가 66%나 폭락했어요. DeepSeek은 40%, Grok-3은 30% 감소했고요. (Claude만 거의 안 떨어졌어요.)
자유롭게 아이디어 모으는 일은 검사할 형식이 없어요. 대화의 질이 곧 결과의 질이에요. 서로 깎아내리기만 하면 좋은 아이디어가 쌓일 자리가 없어요. 걸러줄 필터가 없으니까요.
협상: 거래 자체가 안 됨
협상은 가장 극적이었어요. 합의율이 Claude 40%→0%, GPT-4o 37%→1%, DeepSeek 18%→0%. 까칠하게 만드니 거래가 아예 안 됐어요. 흥정은 양보가 있어야 되는데, 비협조적인 AI는 양보를 안 하니까요.
한 장으로: 산출물 완충 매트릭스
세 결과를 한 장으로 정리하면 이래요. 일을 두 가지로 나누는 거예요.
핵심은 이거예요. AI 팀원의 성격이 결과를 망칠지는, 그 일의 결과물에 형식 제약이 있느냐로 갈려요. 형식이 있으면(코딩) 성격에 둔감하고, 없으면(리서치·협상) 성격에 아주 민감해요.
품질 검문소 같은 거예요. 검문소가 있으면 운전을 험하게 해도 걸러지지만, 없으면 험한 운전이 그대로 목적지까지 가요.
본인 일로 바꿔 보면 바로 와요. 코드나 정해진 포맷 작업은 에이전트 톤을 크게 신경 안 써도 돼요. 반면 글쓰기, 기획, 카피처럼 자유로운 작업은 에이전트의 톤이 결과에 그대로 묻어나요.
의외의 발견: 착하게는 못 만든다
부차적으로 나온 결과 하나가 더 쓸모 있어요.
까칠하게 만드는 건 효과가 컸는데, 착하게 만드는 건 거의 효과가 없었어요. 친절하게 세팅해도 대화가 거의 안 바뀌었죠.
이유는 명쾌해요. 요즘 AI는 이미 친절하고 협조적으로 훈련돼 있어요(Constitutional AI). 이미 천장까지 친절해서 "더 친절해져"는 올라갈 데가 없어요. 반대로 "비협조적으로 굴어"는 훈련된 성향을 거스르니까 효과가 큰 거죠.
그러니까 AI 팀에 "다들 사이좋게 협력해"라고 프롬프트를 박아봐야 별 소용이 없어요. 이미 그러고 있으니까요.
험한 단어를 쓰면 안전장치가 끼어든다
까칠하게 만들 때 "가혹한, 차가운" 같은 험한 단어를 썼잖아요. 연구진이 이걸 "직설적이고 효율을 중시한다" 같은 중립 표현으로 바꿔서 다시 해봤어요.
그랬더니 효과가 덜 극단적으로 나왔어요. 험한 단어가 모델의 안전장치를 건드려서 결과를 과장시켰던 거예요. (방향은 같았지만 정도가 약해졌어요.)
실무 교훈은 분명해요. AI한테 비판하는 역할을 시키고 싶으면 "가혹하게, 냉정하게" 말고 "직설적으로, 효율 우선으로" 같은 중립 표현을 쓰는 게 결과가 더 예측 가능해요.
그럼 까칠한 AI는 무조건 빼야 하나
마지막에 작은 실험이 하나 더 있어요. 협력 팀에 까칠한 AI를 딱 한 명만 끼워본 거예요.
리더 자리에 두면: 전원을 까칠하게 만든 것보다 훨씬 덜 해롭고, 가끔 평소보다 나았어요.
중간에 끼우면: 오히려 방해가 됐어요.
같은 까칠한 AI인데 위치에 따라 약이 되기도, 독이 되기도 한 거예요. 결론은 이래요. 까칠한 역할은 팀 전체에 깔지 말고, 딱 한 명, 리더(비평가) 자리에 둘 때만 도움이 돼요. (다만 이건 작은 파일럿이라 연구진도 단정하진 않았어요.)
Takeaways
기억할 한 줄. AI 팀의 성격이 결과를 망칠지는, 성격이 아니라 산출물에 형식 제약이 있느냐가 정해요.
이 글의 한계
네 모델 실험이 모든 상황을 대변하진 않아요. 과제 종류도 제한돼 있고, 리더 자리 배치 부분은 표본이 작은 파일럿이에요. 그래도 "형식 제약이 과정의 엉망을 걸러준다"는 메커니즘 자체는 꽤 견고하게 나왔어요. 적어도 AI 여러 개를 협업시킬 때, 그 일이 매트릭스의 어느 칸인지부터 보고 톤을 정하는 건 지금 바로 써먹을 수 있어요.
소스: arXiv:2606.27443 (Keluskar et al., 2026) / Bell 2007 / Constitutional AI
매일 아침 콘텐츠 한 편을 쓰는 일, 저는 오랫동안 이걸 "매번 처음부터" 해왔어요. 쓸 만한 원문(소스)을 직접 찾아 던지고, 같은 절차를 또 설명하고, 결과가 괜찮은지 눈으로 확인하고요. 반복인 건 아는데, 그 반복을 어떻게 줄여야 할지는 몰랐죠.
그러다 Claude Code로 이 반복을 '루프(loop)'로 설계해봤어요. 결론부터 말하면, 매번 AI에게 시키는 저 자신을 시스템으로 바꾸는 작업이었고 — 가장 손이 많이 가던 '소스 찾기'부터 자동으로 제안받는 구조까지 만들었습니다. 그 과정을 공유할게요.
"이거 매번 반복하는데" — 근데 뭘 자동화할지 몰랐어요
제 매일 업무는 GPTers 커뮤니티에 올릴 콘텐츠를 쓰는 거예요. 이미 저만의 작성 스킬도 있었고요. 그런데도 매일 손이 많이 갔어요. 왜냐면 "글을 잘 쓰는 법"은 정리돼 있었지만, "매일 이 일을 어떻게 반복해서 굴릴지"는 어디에도 없었거든요.
그래서 AI에게 이렇게 부탁했어요.
매일 하는 일은 콘텐츠 작성하기입니다
내 작성 스킬을 참고해보면 될듯?
AI가 제 기존 스킬을 읽더니, 흥미로운 구분을 해줬어요. 제 작성 스킬은 이미 훌륭한 '레시피'(한 편을 어떻게 쓰는가)라서, 이번엔 그걸 버리지 말고 그 위에 매일 반복을 굴리는 '루프 뼈대'만 새로 씌우면 된다는 거였죠.
이 지점에서 처음 배웠어요. 자동화는 "더 긴 프롬프트를 쓰는 것"이 아니라, 반복되는 일이 트리거·검증·정지 조건을 따라 스스로 굴러가게 설계하는 것이더라고요.
"원문도 알아서 가져오는 건 욕심일까요?"
설계를 하다가 제가 슬쩍 물어봤어요. 제일 귀찮은 게 소스 찾기였거든요.
원문도 알아서 가져오는 건 욕심일까요?
돌아온 답이 좋았어요. 욕심이 아니라 "언제 넣느냐"의 문제라고요. 알고 보니 저는 이미 콘텐츠를 매일 모아주는 시스템을 갖고 있었어요. AI가 제 작업 폴더를 보다가 그걸 발견하고 "이걸 소스로 연결하면 된다"고 제안한 거죠.
솔직히 이게 이번에 제일 놀란 부분이었어요. 제 작업 폴더 안에 뭐가 있는지 AI가 먼저 찾아서 "이거 쓰면 되잖아요"라고 연결해준 거요. 제가 잊고 있던 제 자산을요.
여기에 제 아이디어도 하나 얹었어요.
구글 트렌드 데이터도 가져오면 좋을 것 같아!
그래서 소스를 수집 시스템 + 검색 데이터(GSC) + 구글 트렌드 세 갈래로 넓혔어요. 다만 트렌드는 공식 통로가 불안정해서 "있으면 보태고 막히면 건너뛰는" 보조로 두기로 했고요.
"이걸 그림으로 설명해줄래?"
개념이 머릿속에서 안 그려질 땐, 이렇게 부탁했어요.
이걸 그림으로 설명해줄래?
그랬더니 터미널 안에 흐름도를 그려줬어요. 누가 사람이 할 일이고 누가 자동인지 한눈에 보였죠. 특히 사람은 딱 두 곳(무엇을 쓸지 고르기 / 발행 승인)만 남기고 나머지는 루프가 하도록 나눈 게 명확해졌어요.
"maker와 checker는 에이전트인가요?"
설계 중에 'Maker(만드는 역할) / Checker(검증하는 역할)를 분리하라'는 얘기가 나왔는데, 이게 무슨 뜻인지 애매했어요. 그래서 직접 물어봤죠.
maker와 checker는 에이전트인가요?
이 질문 덕분에 개념이 확 잡혔어요. Checker는 꼭 별도의 AI가 아니라 "별도의 시선으로 증거를 확인한다"는 역할이더라고요. 그리고 대부분은 AI에게 "이거 괜찮아?"라고 다시 묻는 게 아니라, 규칙과 숫자로 확인하는 거였어요. 예를 들면 이런 식이에요.
제목이 정확히 1개인가? → 세어보면 됨 (코드)
핵심 섹션이 들어갔나? → 있는지 찾아보면 됨 (코드)
기존 글과 검색 경쟁이 겹치나? → 데이터로 조회 (코드)
"AI가 스스로 잘 썼다고 우기는 것"을 막으려면, 이렇게 숫자와 존재 여부처럼 우길 수 없는 신호로 판정해야 한다는 거였어요. (딱 하나, '이 인사이트가 진짜 독창적인가' 같은 건 읽어봐야 아니까, 그것만 맥락 없는 새 시선이 보게 뒀고요.)
결과
수치보다 체감이 컸어요. 예전엔 "오늘 뭐 쓰지"부터 소스 찾기까지가 매일 아침의 짐이었는데, 이제 그건 루프가 후보로 올려주고 저는 고르기와 발행 승인이라는 '판단'에만 집중하면 돼요. 반복 잡일과 제 판단이 깔끔하게 분리된 거죠.
AI 활용 팁!
이 방식은 콘텐츠 말고도 매일/매주 반복하는 일이라면 다 적용해볼 수 있어요. 정기 리포트, 데이터 점검, 뉴스레터 정리 같은 것들요. 대신 두 가지만 기억하세요.
완료 판정은 AI 자기평가에 맡기지 마세요. "괜찮아 보임"이 아니라, 숫자·개수·존재 여부처럼 우길 수 없는 신호로 확인하게 하세요.
사람이 남을 지점을 명확히 그으세요. 무엇을 할지 '고르는' 판단과 '발행' 결정은 AI가 아니라 내가 하도록요. 여기까지 자동화하면 오히려 사고가 커져요.
그리고 충분히 반복되지 않거나 개선할 필요가 없는 일에는 루프를 씌우지 마세요. 그건 과설계예요.
바로 쓸 수 있는 프롬프트
제가 매일 반복하는 [업무 이름] 작업이 있어요. 이걸 매번 시키는 대신 루프로 설계하고 싶어요. 먼저 제 기존 작업 방식([기존 스킬/문서 경로])을 읽고, 이 반복업무가 루프에 적합한지 판정해주세요. 그다음 ①언제 시작하고 ②무엇으로 완료를 판정하며(자기평가 말고 객관 신호로) ③언제 멈추는지, 그리고 사람이 남아야 할 판단 지점이 어디인지를 상태 파일 한 장으로 정리해주세요. [업무 이름]과 [기존 스킬 경로]는 본인 상황에 맞게 바꾸세요.
한줄 요약
ChatGPT 메모리가 'Dreaming(드리밍)'이라는 새 아키텍처로 바뀌었습니다. 이제 "기억해줘"라고 말하지 않아도 챗지피티가 여러 대화에서 알아서 맥락을 모으고, 시간이 지나면 메모리를 스스로 최신 상태로 업데이트합니다.
Photo by Steve A Johnson on Unsplash
무슨 일이 있었나?
OpenAI가 ChatGPT 메모리를 통합하는 더 강력하고 확장 가능한 시스템을 순차 배포하기 시작했습니다. 수억 명의 사용자가 수년간 쌓아온 메모리에서 나타나던 세 가지 문제 — 시간이 지나면 정보가 낡는 최신성 저하, 정확성, 확장성 — 를 풀려고 만든 시스템입니다.
핵심 이름은 Dreaming(드리밍)입니다. 저장된 메모리(Saved Memory)와 달리, Dreaming은 백그라운드 프로세스로 ChatGPT가 여러 대화에서 학습하고 메모리 상태를 계속 통합하게 만듭니다. 그래서 "이거 기억해둬"라고 따로 요청하지 않아도, 대화 과정에서 자연스럽게 나온 맥락이 메모리에 반영됩니다.
이번 업데이트는 미국의 Plus·Pro 사용자에게 먼저 제공되며, 앞으로 몇 주에 걸쳐 추가 국가와 Free·Go 사용자에게도 순차적으로 확대됩니다. 발표 시점 기준으로 한국과 무료 사용자는 곧 받게 되는 단계입니다.
ChatGPT 메모리는 어떻게 발전해 왔나?
지금의 Dreaming이 왜 중요한지 이해하려면, 메모리가 거쳐온 세 단계를 보는 게 빠릅니다.
처음 출시된 저장된 메모리는 "7월에 싱가포르 여행 간다는 걸 기억해줘" 같은 명확한 신호가 있을 때만 기록됐습니다. OpenAI의 표현을 빌리면, "몇 가지 메모를 적어두긴 하지만 적지 않은 건 전부 잊어버리는 사람과 대화하는 것" 같았습니다. 게다가 적어둔 메모도 시간이 지나면 더 이상 맞지 않는 정보가 되곤 했습니다.
2025년 4월 도입된 Dreaming의 첫 버전(V0)은 저장 목록에 없는 대화 맥락까지 참조하게 만든 보완 장치였습니다. 다만 그때까지는 저장된 메모리를 보조하는 역할이었고, 독립적인 메모리 시스템으로 쓰기엔 부족했습니다.
이번 Dreaming V3가 달라진 지점은, 드리밍을 모든 사용자를 위한 공통 메모리 기반으로 끌어올렸다는 것입니다.
Dreaming의 핵심 — 무엇이 좋아졌나?
OpenAI는 '좋은 메모리'를 세 가지 기준으로 정의하고, 각 버전이 얼마나 개선됐는지 자체 평가를 공개했습니다. 세 축 모두에서 2026년 Dreaming V3가 큰 폭으로 올라갑니다.
1. 컨텍스트 이어가기 — 매번 처음부터 설명하지 않아도 됩니다
새 대화를 열 때마다 자기 상황을 다시 설명할 필요가 없습니다. 복잡하고 장기간 진행되는 작업일수록 효과가 큽니다.
OpenAI가 든 예시는 수중 사진 장비입니다. 이전에 카메라 구성(소니 A1 II + Nauticam 하우징 + Backscatter Mini Flash 3 + Inon Z-330)을 이야기한 적이 있다면, "내 촬영 장비와 호환되는 TTL 장비 뭘 사야 해?"라고만 물어도 됩니다. 이전 모델(GPT-5.2)은 사용자가 직접 호환성을 따져야 하는 일반론을 길게 늘어놓지만, 새 시스템(GPT-5.3)은 사용자의 실제 장비 구성을 기억해 바로 호환 제품을 짚어줍니다.
2. 선호 사항 반영하기 — 알려준 취향대로 답합니다
선호는 여러 형태로 나타납니다.
응답 방식 지침: "Stan 이야기는 다시 꺼내지 마"
개인적 조건: "나는 채식주의자야"
암묵적 선호: "나는 샌프란시스코 근처에 살아" → 지역 추천이 그 지역에 맞춰져야 함
싱가포르 여행 일정을 예로 들면, ChatGPT가 이전 대화에서 사용자가 야생동물 사진 촬영을 좋아하고, 에어컨이 잘 나오는 호텔을 선호하며, 붐비는 곳보다 조용한 저녁 식사를 즐긴다는 걸 이미 압니다. 그래서 관광객용 일반 코스 대신, 동물원 야간 사파리·조류원처럼 취향에 맞춘 일정과 냉방·좌석 조건까지 반영한 추천을 내놓습니다.
3. 시간이 지나도 최신 상태 유지 — 시간 인식(Temporal Awareness)
가장 눈에 띄는 변화입니다. 대화가 끝났다고 시간이 멈추지는 않으니까요.
기존 메모리는 "지금 싱가포르에 있어"를 여행이 끝난 뒤에도 그대로 들고 있었습니다. Dreaming은 시간이 지나면 메모리를 자동으로 갱신합니다. "사용자는 7월에 싱가포르에 갈 예정이다" → "사용자는 2026년 7월에 싱가포르를 다녀왔다" 로 바뀌고, 집에 돌아오면 다시 사용자의 거주 지역·시간대에 맞는 추천으로 되돌아옵니다.
OpenAI 예시에서 "오늘 저녁 테이크아웃 추천해줘"라고 물으면, 옛 시스템은 여전히 싱가포르 식당을 안내하지만, 새 시스템은 사용자가 귀가했다는 걸 반영해 거주지(예: Portola Valley) 근처에서 영업 중인 식당을 추천합니다.
메모리 요약 페이지 — 무엇이 저장됐는지 보고, 직접 고치는 법
Photo by Shawn Day on Unsplash
Dreaming으로 통합된 메모리는 메모리 요약 페이지(Memory Summary)에서 검토합니다. 자동으로 쌓이는 시스템인 만큼, 통제 장치가 함께 제공되는 게 핵심입니다. 이 페이지에서 할 수 있는 일은 다음과 같습니다.
ChatGPT가 나에 대해 알고 있는 주요 내용을 한눈에 확인 (업무, 취미, 선호, 여행 관심사, 진행 중인 프로젝트 등)
사용자 정보를 추가하거나 업데이트
특정 정보를 수정하거나, "이건 다시 언급하지 마"라고 지침 제공
더 깊이 다루고 싶은 분야는 모델과 직접 대화
정리하면, 자동으로 기억하되 통제권은 사용자에게 두는 구조입니다. 무엇을 기억할지뿐 아니라 언제 그 주제를 꺼낼지까지 지정한다는 점이 기존 저장 메모리와의 차이입니다.
왜 무료 사용자까지 확대되나? — 5분의 1로 줄어든 컴퓨트
Dreaming 기반 메모리는 이미 한동안 Plus·Pro 사용자에게 제공돼 왔습니다. 그동안 Free 사용자에게 열지 못한 이유는 비용이었습니다. 백그라운드에서 끊임없이 대화를 종합하는 작업은 연산 부담이 크기 때문입니다.
이번에 OpenAI는 드리밍을 대규모로 서비스하는 데 필요한 컴퓨팅 자원을 약 5분의 1 수준으로 줄였습니다. 이 효율 개선 덕분에 앞으로 몇 주에 걸쳐 Free 사용자에게 Dreaming을 순차 제공하고, Plus·Pro 사용자의 메모리 용량도 늘릴 수 있게 됐습니다.
앞으로 Dreaming은 모든 사용자를 위한 공통 메모리 기반 역할을 합니다.
실전에서 어떻게 쓸 수 있을까?
이 업데이트가 실무자에게 의미하는 바를 세 가지로 정리하면 이렇습니다.
장기 프로젝트의 '맥락 재설명' 비용 제거: 마케팅 캠페인, 제품 기획, 리서치처럼 여러 날에 걸쳐 이어지는 작업에서 매번 배경을 다시 깔지 않아도 됩니다. 한 번 정리해 둔 톤·타깃·제약 조건을 ChatGPT가 들고 갑니다.
시간이 지나면 알아서 정리되는 할 일/일정 맥락: "다음 주 발표 준비 중"이 발표가 끝나면 과거형으로 정리되므로, 낡은 정보가 답변을 오염시키는 일이 줄어듭니다.
메모리 요약 페이지로 '내 프로필 점검': 협업 도구처럼, ChatGPT가 나를 어떻게 이해하고 있는지 주기적으로 열어 보고 잘못된 정보를 바로잡는 루틴을 만들 수 있습니다.
자주 묻는 질문
ChatGPT의 Dreaming 메모리는 무엇인가요?
Dreaming은 ChatGPT가 백그라운드 프로세스로 여러 대화를 학습·종합해 메모리를 자동으로 정리·갱신하는 시스템입니다. "기억해줘"라는 명시적 요청 없이도 대화에서 자연스럽게 나온 맥락을 반영하고, 시간이 지나면 메모리를 최신 상태로 업데이트합니다.
ChatGPT Dreaming 메모리는 언제부터 쓸 수 있나요?
발표 시점 기준으로 미국의 Plus·Pro 사용자에게 먼저 제공되며, 앞으로 몇 주에 걸쳐 추가 국가와 Free·Go 사용자에게 순차적으로 확대됩니다. 한국과 무료 사용자는 순차 배포로 곧 받게 되는 단계입니다.
ChatGPT가 기억한 내용을 확인하거나 지울 수 있나요?
네. 메모리 요약 페이지에서 ChatGPT가 알고 있는 정보를 확인하고, 추가·수정하거나 특정 주제를 다시 언급하지 않도록 지침을 줄 수 있습니다. 개별 메모리 삭제, 전체 메모리 삭제, 메모리 기능 비활성화도 가능합니다.
저장된 메모리(Saved Memory)와 Dreaming은 뭐가 다른가요?
저장된 메모리는 사용자가 "기억해줘"라고 요청한 정보만 기록하고 시간이 지나면 낡습니다. Dreaming은 요청 없이도 대화 맥락을 자동으로 종합하고, 시간 흐름에 맞춰 메모리를 스스로 갱신한다는 점이 다릅니다.
인사이트
이번 업데이트에서 진짜 핵심은 '더 많이 기억한다'가 아니라 '시간 인식(Temporal Awareness)' 입니다. 그동안 AI 메모리의 가장 큰 약점은 용량이 아니라 부패(staleness) 였습니다. 한 번 저장된 "다음 주 발표 준비 중"이 한 달 뒤에도 그대로 남아 엉뚱한 답을 만드는 식이죠. 정보를 쌓는 기능은 많았지만, 정보를 늙히고 폐기하는 기능은 없었습니다. Dreaming의 자동 갱신은 그 빈자리를 메웁니다. 사실 회상(82.8%)보다 시간 정확성(9.4% → 75.1%)의 개선 폭이 압도적으로 큰 것도 같은 맥락입니다.
한국 사용자 입장에서 더 주목할 지점은 무료 티어 확대입니다. 그동안 "메모리가 좋아져 봐야 유료 얘기"라는 인식이 있었는데, 컴퓨트가 5분의 1로 줄면서 개인화된 메모리가 사실상 기본 기능이 되는 흐름입니다. 그러면 경쟁 구도도 바뀝니다. Claude도 자체 메모리/dreaming 계열 기능을 실험 중이고(GSC에 'claude dreaming' 같은 쿼리가 잡힙니다), Gemini는 이미 메모리 가져오기를 제공합니다. "누가 더 똑똑한가"에서 "누가 나를 더 정확하게, 그리고 최신으로 기억하는가"로 개인화 경쟁의 축이 옮겨가는 신호로 읽힙니다.
다만 자동으로 쌓이는 메모리는 양날의 검입니다. 통제권(메모리 요약 페이지)이 함께 나온 건 그래서 필수적인데, 실무에서는 주기적으로 요약 페이지를 열어 잘못 학습된 맥락을 청소하는 습관을 들이는 게 좋겠습니다. AI가 나를 기억하기 시작했다면, 그 기억을 점검하는 것도 이제 사용자의 일입니다.
원문: Dreaming: Better memory for a more helpful ChatGPT (OpenAI)
소개
딥 리서치 과제를 겸하여
게임 사운드 제작에 관심이 있었기에, 그에대해 조사해보고자 했습니다.
진행 방법
제미나이에서 Deepresearch를 사용했습니다.
그저 현 상황과 알고 싶은 부분 정도 설명했습니다.
https://share.gemini.google/ScldhBCpVfMe
(와! 대화 내용!)
결과와 배운 점
사실 직업으로 삼기엔 포기한 부분이 많은 취미인지라, 더 어렵다는 것만 실감이 나네요
전문 교육 받은 예술가들의 노력량이 엄청나기도 하고... 제 수준이 AI 음악들 수준에도 부족한지라.. 노력해야할 부분이 바다같이 많다는 것이 더 실감나고 두렵습니다.
도움 받은 글
https://sites.google.com/view/avpn
x/2%ED%9A%8C%EC%B0%A8/2-%EB%94%A5%EB%A6%AC%EC%84%9C%EC%B9%98-%EC%BB%A4%EB%A6%AC%EC%96%B4-%EC%84%A4%EA%B3%84-%ED%99%9C%EC%9A%A9%EB%B2%95?authuser=0
강의 내용 2회차 과제를 참고하였습니다.
코딩을 한 줄도 못 짜는 제가, AI 코딩 도구(Claude Code) 하나로 "모임 날짜 잡기 앱"을 기획부터 실제 배포까지 끝냈습니다. 앱 주소: [배포 링크 비공개] · 걸린 시간: 단속적으로 4일
1. "회식 날짜 잡는 거, 매번 왜 이렇게 귀찮지?"
다들 한 번쯤 겪어보셨을 거예요.
단톡방에 "이번 주에 회식 한번 하시죠~"라고 누가 운을 띄우면, 그때부터 시작입니다. "저는 화요일 빼고요", "수요일은 6시 이후만", "금요일은 안 돼요" 이런 말풍선이 30개쯤 올라오고, 누군가는 그걸 일일이 메모장에 적어가며 겹치는 날을 찾아냅니다. 그러다 결국 "그냥 목요일 어때요?" 하고 던지면 또 누군가는 그날 안 된다고 하고요.
저는 이 과정이 매번 너무 비효율적이라고 느꼈어요. "되는 날짜만 톡 누르면, 자동으로 다 되는 날을 찾아주는 앱"이 있으면 좋겠다 싶었죠.
사실 모두의 시간 같은 비슷한 앱이 이미 있다는 걸 알아요. 제가 뭔가 최초로 만든다는 게 아닙니다. 그래도 직접 만들어보고 싶었고, 무엇보다 내가 원하는 방향으로 차근차근 발전시켜보고 싶었어요. 남이 만든 걸 쓰는 것과, 내 손으로 만들어서 마음대로 고쳐가는 건 전혀 다른 경험이니까요.
문제는 — 저는 코딩을 모릅니다. 함수가 뭔지, 데이터베이스가 뭔지도 잘 몰라요. 그런 제가 앱을 만든다는 게 가능할까 싶었지만, 일단 한번 부딪혀보기로 했습니다.
시작은 거창하지 않았어요. 계획 메모 한 장과, 제가 쓰는 AI 코딩 도구의 "맞춤 실습(Rona)"을 받아 7단계 흐름으로 쪼개는 것부터였습니다.
데이터 저장 → 운영자가 모임 생성 → 공유 링크 → 참가자 투표
→ 결과 집계 → 실시간 갱신 → 배포
이렇게 큰 그림을 단계로 나눠두니, "막막한 앱 개발"이 "오늘은 이 한 칸만"으로 바뀌더라고요. 이게 첫 번째 깨달음이었습니다.
2. 만드는 과정 — 저는 기획·선택·검증, AI는 구현·디버깅
핵심부터 말씀드리면, 역할 분담이 명확했어요.
제가 한 일: 무엇을 만들지 정하고(기획), AI가 준 선택지 중에 고르고(결정), 진짜로 잘 되는지 확인(검증)
AI가 한 일: 실제 코드 작성, 에러 잡기(디버깅), 막힌 부분 우회
저는 코드를 단 한 줄도 직접 쓰지 않았습니다. 대신 말로 설명하고, 고르고, "진짜 되는지 확인해줘"라고 시켰습니다.
1일차 — 뼈대 세우기 (데이터 저장 ~ 공유 링크)
가장 먼저 한 건 "데이터를 어디에 저장할까"였어요. 투표한 날짜들이 어딘가에 쌓여야 하니까요. AI가 Supabase라는 무료 데이터 저장소를 추천해줬고, 저는 그 키(비밀번호 같은 것)를 발급받아 전달만 했습니다. 솔직히 URL을 어디서 찾는지 몰라서 스크린샷을 찍어 "이거 어디 있어?"라고 물어보기도 했어요.
그렇게 모임을 만들면 공유 링크가 나오는 데까지, 1일차에 뼈대를 세웠습니다.
2일차 — 핵심 기능 + 실시간 + 첫 배포
여기서 제 의견을 많이 냈어요. AI가 만든 첫 화면을 보고 이렇게 요청했습니다.
ㅇㅋ 흐름은 좋은데 너무 심플한거같아.
UI 좀 더 좋게 다듬고 이모지는 싹다 없음으로 디폴트깔아.
그리고 날짜를 입력하는 것 자체가 매우 피로도가 높은 일이라서
이름 입력하는거 빼고 그냥 날짜만 선택하게 하자. 달력이 뜨고 거기서 선택할 수 있게끔.
"날짜 입력 자체가 피곤한 일"이라는 건 제가 실제로 겪은 불편이었고, 그걸 그대로 말로 옮겼더니 AI가 달력에서 톡톡 누르는 방식으로 바꿔줬습니다.
그다음 욕심이 났어요. 누가 투표하면 새로고침 없이 결과가 실시간으로 바뀌면 좋겠다. 이게 기술적으로 꽤 어려운 거라던데, AI에게 시켰더니 구현해줬고, 저는 한 가지만 확실히 시켰습니다 — "진짜 실시간으로 되는지 확인해줘." AI가 검증 스크립트를 돌려서 "구독 → 데이터 입력 → 화면 갱신"이 실제로 작동하는 걸 보여주더라고요. 코딩을 모르는 저는 "된다고 말만 하는 것"과 "진짜 되는 것"을 구별할 수 없으니, 이 검증 요청이 정말 중요했습니다.
그리고 2일차에 첫 배포까지 했습니다. 폰으로 링크를 열어 카톡으로 공유까지 되는 걸 보니, 진짜 앱이 됐다는 게 실감 났어요.
3일차(4일째) — 기능 보강 + 디자인 리뉴얼 + 출시 마감
중간에 며칠 쉬고, 마지막 날 몰아서 마무리했습니다. 실제로 써보니 아쉬운 점이 계속 나왔고, 그걸 하나씩 말로 고쳐갔어요.
"내가 만든 모임들을 한눈에 보는 리스트가 있으면 좋겠어" → 목록 + 삭제 기능 추가
"달력이 월 바뀔 때 페이지가 넘어가지 말고, 위아래로 쭉 이어지게" → 세로 연속 캘린더
"결과 페이지는 나(만든 사람)만 보게 하고, 투표한 사람한텐 감사 인사만" → 결과 잠금
"참가자별 투표를 모아서 만장일치/다수가 되는 날을 자동으로 띄워줘" → 추천 날짜 하이라이트 + 확정 버튼
이 과정에서 AI가 갈림길마다 저에게 물어봤어요. 예를 들어 "확정하면 폰 푸시 알림을 진짜로 구현할까요, 아니면 카톡 공유 문구로 대체할까요?" 같은 식으로요. 저는 그중에서 현실적인 쪽(카톡 공유 대체)을 골랐습니다. 결정은 제가 하고, AI는 선택지를 차려주는 구조가 끝까지 이어졌어요.
3. 솔직히, 막힌 적도 많았어요 (그래서 오히려 도움됩니다)
"AI가 다 해주니 술술 풀렸겠지" 싶겠지만, 전혀 아니었습니다. 막힌 게 더 기억에 남아요. 다만 막힐 때마다 제가 끙끙댄 게 아니라, AI에게 "이거 에러 나는데?" 하고 넘기면 그 자리에서 잡아줬다는 게 핵심입니다.
막혔던 순간 무슨 일이었나 어떻게 풀렸나
─────────────────────────────────────────────────────────────────────────────────
설치가 안 됨 초반에 프로그램 설치(npm)가 에러로 멈춤 AI가 원인 진단 후 우회
실시간이 안 됨 실시간 기능에서 "이미 등록됨" 류 에러 발생 AI가 중복 등록을 무시하도록 처리해 해결
모바일 드래그 충돌 폰에서 날짜를 드래그하면 화면이 같이 스크롤 드래그 버리고 "시작일·끝일 클릭 → 범위 자동 선택"으로 전환
카톡 미리보기 안 뜸 링크 공유 시 미리보기 이미지가 안 나옴 기준 주소 고정 + 이미지 주소를 절대경로로 바꿔 해결
특히 모바일 드래그 문제가 인상적이었어요. "손가락으로 쓱 드래그하면 날짜 범위가 잡히게" 하고 싶었는데, 폰에서는 그 동작이 화면 스크롤과 자꾸 충돌했거든요. 한참 안 되길래, AI에게 "그냥 시작일·끝일만 누르면 그 사이가 자동으로 채워지게 하자"고 방향을 틀었습니다. 기술로 안 되면 사용성으로 우회한 셈인데, 이런 판단은 제가 사용자 입장에서 내릴 수 있는 부분이었어요.
막힘을 숨기지 않고 말씀드리는 이유는, 이게 정상이기 때문입니다. 비개발자가 앱을 만든다고 다 매끄럽게 흘러가지 않아요. 다만 막혔을 때 직접 푸는 게 아니라 AI에게 넘긴다는 점이 예전과 완전히 달라진 부분입니다.
4. 디자인은 '여러 안을 한 번에 뽑아 눈으로 비교'
기능이 다 되고 나니 모양새가 아쉬웠어요. 그런데 저는 디자인 감각이 뛰어난 것도 아니고, 색 조합을 글로 설명하기도 어려웠습니다. 그래서 이렇게 시켰어요.
서브에이전트 시켜서 디자인 몇개 뽑아서 html로 띄워. 내가 선택할 수 있게.
지금꺼에 추가로 4개 더 화면 띄워. html에서 선택가능하게 하고 선택되면 그걸로 ui 싹 바꿔놔.
여기서 신기했던 게, AI가 '서브에이전트(작은 일꾼들)'를 동시에 여러 개 돌려서 디자인 시안 4종을 한 번에 만들어줬다는 거예요. 기존 디자인까지 합쳐 총 5종을 한 화면(갤러리)에 나란히 띄워줬습니다.
시안1: 미니멀 모노
시안2: 다크 네온
시안3: 소프트 파스텔 ← 제가 고른 것
시안4: 그라데이션 글래스
말로 "이런 느낌 어때?"를 백 번 설명하는 것보다, 눈으로 5개를 나란히 보고 "3번"이라고 답하는 게 비교가 안 되게 빨랐습니다. 그렇게 고르니 전체 화면이 소프트 파스텔 톤으로 싹 바뀌었어요.
앱 아이콘도 같은 방식으로 여러 개 뽑아 화면에 띄우고, "6번"으로 골랐습니다.
5. 마지막 디테일까지 — 카톡 공유 카드와 앱 아이콘
여기서 멈출 수도 있었지만, "진짜 출시"의 느낌을 내고 싶었어요. 그래서 두 가지를 더 챙겼습니다.
카톡 공유 카드(미리보기 이미지): 링크를 카톡에 붙이면 그냥 파란 글씨가 아니라, 예쁜 카드 이미지가 뜨도록 만들었어요. (이게 앞서 말한 "미리보기 안 뜸" 문제를 잡은 부분입니다.)
앱 아이콘: 브라우저 탭과 홈 화면에 뜨는 작은 아이콘까지 테마에 맞춰 교체했습니다.
이런 마무리 디테일이 들어가니, "혼자 만든 연습용"이 아니라 남한테 보여줄 수 있는 앱이 됐다는 기분이 들더라고요.
6. 결과 — 코딩 0인데, 진짜 쓰는 앱이 나왔습니다
구분 Before (앱 없을 때) After (MOIN 사용)
────────────────────────────────────────────────────────────────────────────────
날짜 조율 방식 단톡방 말풍선 30개, 수동으로 찾기 링크 공유 → 각자 되는 날만 톡 선택
집계 누군가 메모장에 손으로 정리 만장일치·다수 동의 날짜 자동 하이라이트
결과 확인 누가 언제 된다 했는지 헷갈림 만든 사람만 "누가 언제 가능"을 한눈에
결과 갱신 계속 다시 물어봐야 함 새로고침 없이 실시간 반영
내 코딩 실력 0 (한 줄도 못 짬) 여전히 0 — 그런데 앱은 배포됨
걸린 시간 — 단속적으로 약 4일
제 코딩 실력은 시작할 때나 지금이나 0입니다. 그런데 결과물은 인터넷에 배포돼서 누구나 링크로 쓸 수 있는 진짜 앱이에요. 이게 가능하다는 걸 직접 겪고 나니, "AI 코딩 도구로 뭘 만든다"는 말이 더 이상 남의 이야기처럼 들리지 않았습니다.
7. 비개발자가 따라 할 때 — 제가 배운 재현 팁 3가지
혹시 "나도 한번 해볼까?" 싶은 분들을 위해, 4일 동안 몸으로 배운 것 3가지만 정리할게요.
한 번에 다 시키지 말고, 단계별로 쪼개세요.
"모임 앱 만들어줘"라고 통째로 던지면 막막해집니다. 저는 7단계(저장 → 생성 → 공유 → 투표 → 집계 → 실시간 → 배포)로 나눠서 "오늘은 이 한 칸만" 진행했어요. 그래야 어디서 막혔는지도 보이고, 검증도 쉽습니다.
막히면 AI에게 맡기되, "진짜 되는지" 검증을 꼭 요청하세요.
코딩을 모르면 "됐다"는 말이 진짜인지 알 수가 없어요. 그래서 저는 중요한 기능마다 "정말 작동하는지 확인해줘"라고 시켰고, 실시간 기능 같은 건 AI가 실제로 돌려서 결과를 보여줬습니다. 이 검증 한 줄이 비개발자에겐 안전벨트입니다.
디자인은 여러 안을 뽑아 눈으로 비교하세요.
글로 "세련되게 해줘"라고 백 번 말하는 것보다, 시안 4~5개를 한 화면에 띄워놓고 "3번"이라고 고르는 게 훨씬 빠르고 정확합니다. 선택은 말보다 눈이 빨라요.
8. 바로 쓸 수 있는 프롬프트 모음
제가 실제로 썼던 요청 중, 비개발자 분들이 그대로 복붙해 쓰기 좋은 것들만 골랐습니다.
① 큰 그림을 단계로 쪼갤 때
이런 앱을 만들고 싶어. 코딩은 전혀 모르니까,
전체를 작은 단계로 나눠서 '오늘은 이 한 칸만' 할 수 있게 흐름을 짜줘.
각 단계가 끝나면 다음에 뭘 할지 안내해줘.
② 화면/사용성을 고칠 때 (내가 겪은 불편을 그대로 말하기)
지금 흐름은 좋은데, 입력하는 게 너무 번거로워.
사용자가 최소한의 동작으로 끝낼 수 있게 UI를 다듬어줘.
불필요한 입력은 빼고, 핵심만 남겨줘.
③ "진짜 되는지" 검증을 시킬 때 (비개발자 필수)
방금 만든 이 기능, 말로만 됐다고 하지 말고
실제로 작동하는지 직접 확인하는 과정을 거쳐서 결과를 보여줘.
④ 디자인 시안을 여러 개 뽑아 비교할 때
디자인 시안 4~5개를 서로 다른 느낌으로 만들어서,
한 화면(html)에 나란히 띄워줘. 내가 보고 번호로 고르면
그 디자인으로 전체를 바꿔줘.
⑤ 막혔을 때 (에러 메시지를 그대로 붙이기)
이거 실행하니까 이런 에러가 떠. (에러 메시지 붙여넣기)
원인이 뭔지 진단하고, 고쳐줘. 내가 코딩을 몰라도 되게 알아서 처리해줘.
9. 앞으로는 이렇게 더 발전시킬 거예요
여기서 끝이 아니에요. 이미 비슷한 앱들이 있지만, 저는 제 손으로 만든 만큼 제가 원하는 방향으로 계속 키워보고 싶습니다. 지금 머릿속에 있는 다음 단계들은 이렇습니다.
날짜별 개별 코멘트 — 단순히 "되는 날"만 고르는 게 아니라, "17일은 저녁 8시 이후만 가능" 같은 조건을 날짜마다 붙일 수 있게. 실제 조율에선 '되냐 안 되냐'보다 '몇 시부터 되냐'가 더 중요할 때가 많거든요.
소셜 로그인(애플·구글·카카오) — 로그인하면 기존 캘린더와 연동해서, 일일이 누르지 않아도 가능한 날이 자동으로 선택되게. 입력 자체를 더 줄이는 방향이에요.
중간 지점 + 맛집 추천(챗봇) — 날짜가 정해지면 "그럼 어디서 봐?"가 남잖아요. 참가자들 위치의 중간 지점을 잡아주고, 그 근처 맛집까지 챗봇이 추천하게.
소수 인원 조율 푸시 — 전원이 다 되는 날이 없을 때, "이 사람만 안 되는 날"을 찾아 그 사람에게 푸시로 "이날 혹시 조정 가능하세요?"라고 물어보는 기능. 모임이 깨지지 않게 마지막 한 칸을 메워주는 거죠.
비슷한 앱과 똑같이 가는 게 목표가 아니라, 이런 디테일을 하나씩 더 해보는 게 제가 직접 만든 이유예요. 코딩을 몰라도 "내가 원하는 방향"만 분명하면, 그걸 말로 설명해서 한 걸음씩 키워갈 수 있다는 걸 이번에 배웠습니다.
코딩을 모른다는 게 더 이상 "앱을 못 만드는 이유"가 아니더라고요. 필요한 건 내가 뭘 원하는지 말로 설명하는 힘, 고를 줄 아는 눈, 그리고 "진짜 되는지" 확인하는 습관이었습니다. 혹시 미뤄둔 작은 아이디어가 있다면, 오늘 한 단계만 시작해보시길 권합니다.
완성된 앱: [배포 링크 비공개]
참고한 글들
비개발자의 바이브 코딩 입문기 (지피터스)
비개발자가 클로드코드로 코딩하는 법
비개발자를 위한 바이브 코딩 입문 5단계 가이드
바이브 코딩의 진짜 현실 (vs 노코드)
2달 간의 실적
기존 한달 방문자 700~1000명이었습니다.
3월부터 자동화 하기 시작해서 3월 2,100명, 4월 9,254명, 5월 11,542명으로 기하급수적으로 늘었습니다.
하루에 글 3개정도 올리는데 시간은 약 5분정도 소요됩니다.
한 줄 요약
저는 블로그 키워드 하나만 입력합니다. 그러면 AI가 네이버 상위검색 분석, 법령/실거래가 근거 수집, 본문 작성, 이미지 생성, HTML 변환까지 파이프라인 순서대로 처리하고, 저는 마지막에 최종 검수 후 네이버 블로그에 복사해서 붙여넣습니다.
핵심 운영 방식
이 자동화의 핵심은 "AI가 글 하나를 통째로 알아서 쓴다"가 아닙니다.
제가 하는 일은 아주 작습니다.
1. 키워드 하나를 준다.
2. 완성된 초안과 HTML을 확인한다.
3. 이상한 부분만 최종 검수한다.
4. 네이버 블로그에 복사해서 붙여넣는다.
그 사이의 작업은 파이프라인이 처리합니다.
키워드
→ 네이버 상위검색 분석 에이전트
→ 법령/실거래가 근거 수집 에이전트
→ 본문 작성 에이전트
→ 품질 검사 에이전트
→ 이미지 생성 에이전트
→ 이미지 삽입 에이전트
→ HTML 변환 에이전트
→ 최종 검수용 산출물
여기서 중요한 점은 각 단계가 독립적이라는 것입니다.
네이버 상위검색 분석은 분석만 하고, 법령/실거래가 수집은 근거만 찾고, 본문 작성은 글만 씁니다. 이미지 생성 에이전트는 이미지에만 집중하고, HTML 변환 에이전트는 네이버 에디터에 붙여넣기 좋은 형태로 바꾸는 일만 합니다.
그래서 문제가 생겼을 때 전체 시스템을 다시 만들 필요가 없습니다.
예를 들어 이미지가 이상하면 이미지 생성 단계만 고치면 됩니다. 네이버에 붙여넣었을 때 줄바꿈이 깨지면 HTML 변환 단계만 고치면 됩니다. 부동산 글에서 실거래가가 약하면 근거 수집 단계만 보강하면 됩니다.
이 구조 덕분에 한 번 만든 에이전트를 다른 글쓰기에도 재사용할 수 있었습니다.
이런 분들께 도움돼요
블로그를 꾸준히 쓰고 싶은데 매번 자료 조사와 이미지 작업에서 시간이 많이 드는 분
AI로 글을 쓰긴 하는데 결과물이 매번 들쭉날쭉해서 불편한 분
네이버 블로그에 올릴 글을 마크다운이나 HTML로 먼저 만들고 싶은 분
자동화를 만들고 싶은데 어디부터 나눠야 할지 감이 안 잡히는 분
"AI가 다 써줬습니다"가 아니라 실제 운영 가능한 글쓰기 시스템을 만들고 싶은 분
시작하게 된 이유
블로그를 계속 쓰다 보면 글쓰기보다 더 귀찮은 일이 많습니다.
키워드를 정하고, 검색 결과를 보고, 어떤 사람들이 무엇을 궁금해하는지 확인하고, 글 구조를 잡고, 본문을 쓰고, 이미지를 만들고, 이미지를 적당한 위치에 넣고, 마지막으로 네이버 에디터에 올리는 과정입니다.
처음에는 AI에게 이렇게 말했습니다.
이 키워드로 네이버 블로그 글 써줘.
그런데 이렇게 하면 결과가 매번 달랐습니다.
어떤 날은 글은 괜찮은데 이미지가 없고, 어떤 날은 문체가 이상하고, 어떤 날은 출처가 약하고, 어떤 날은 네이버에 붙여넣었을 때 줄바꿈이 깨졌습니다.
그래서 목표를 바꿨습니다.
"AI에게 글 하나를 맡기는 게 아니라, 블로그 글이 만들어지는 순서를 파이프라인으로 쪼개자."
이렇게 접근하니 훨씬 안정적으로 운영할 수 있었습니다.
전체 구조
제가 쓰는 블로그 자동화의 큰 흐름은 이렇습니다.
1. 키워드 입력
2. 네이버 상위검색 로직 분석
2.5 법령/실거래가 등 근거 수집
3. 블로그 본문 작성
4. 글 품질 검사
5. 이미지 생성
6. 이미지 후처리
7. 본문에 이미지 삽입
8. 옵시디언에 초안 저장
9. 네이버 블로그용 HTML 생성 마지막 등록:
10. 사람이 네이버 블로그 에디터에 복사해서 붙여넣기
여기서 중요한 점은 마지막 단계입니다.
저는 이걸 "블로그 자동화"라고 부르지만, 네이버 블로그에 최종 게시 버튼을 누르는 것까지 완전 자동화하지는 않았습니다.
네이버 블로그 에디터는 로그인 세션, 브라우저 상태, 이미지 업로드, 에디터 UI 변화에 영향을 많이 받습니다. 자동 등록까지 억지로 붙이면 오히려 실패 가능성이 커집니다.
그래서 현재 운영 방식은 이렇습니다.
AI가 하는 일:
각 독립 에이전트가 순서대로 네이버 상위검색 분석, 필요한 근거 수집, 글 작성, 이미지 생성, HTML 변환까지 완료 사람이 하는 일:
완성된 HTML을 열고 전체 복사한 뒤 네이버 블로그 에디터에 붙여넣고 최종 확인 후 발행
자동화는 많이 할수록 좋은 게 아니라, 실패했을 때 어디서 깨졌는지 알 수 있어야 오래 갑니다.
그래서 저는 이 파이프라인을 하나의 거대한 자동화로 만들지 않았습니다.
각 단계를 작은 에이전트로 나눴습니다.
검색 분석이 약하다 → 검색 분석 에이전트만 수정
법령 근거가 약하다 → 법령 수집 에이전트만 수정
실거래가 반영이 약하다 → 부동산 데이터 수집 단계만 수정
문체가 이상하다 → 본문 작성 에이전트만 수정
이미지가 이상하다 → 이미지 생성 에이전트만 수정
붙여넣기 HTML이 깨진다 → HTML 변환 에이전트만 수정
이렇게 쪼개두면 블로그 글 하나를 만드는 데만 쓰는 것이 아니라, 나중에 책 리뷰, 부동산 글, 러닝 글, AI 도구 리뷰에도 같은 부품을 다시 쓸 수 있습니다.
1단계: 키워드를 하나만 넣습니다
시작은 단순합니다.
블로그 글 써줘: 초보 러너 5km 훈련
또는 이렇게 요청합니다.
네이버 블로그용으로 "전세사기 예방 체크리스트" 글 만들어줘.
여기서 바로 글을 쓰지 않습니다. 먼저 키워드 성격을 봅니다.
일반 정보 글인지
부동산 글인지
세금/법률 글인지
책 리뷰인지
러닝/건강 글인지
AI 도구 활용 글인지
이 분류가 중요한 이유는 글마다 필요한 근거가 다르기 때문입니다.
예를 들어 부동산 글이면 실거래가나 지역 정보가 필요하고, 세금 글이면 법령이나 국세청 자료가 필요합니다. 이런 글을 그냥 AI 기억으로 쓰면 위험합니다.
그래서 저는 키워드만 보고 바로 본문을 쓰지 않고, 먼저 "이 글은 어떤 근거가 필요한 글인가?"를 나눕니다.
일반 정보 글:
검색 의도와 독자 질문 중심 부동산 글:
자동화가 실거래가, 시세, 입지, 단지/지역 정보 소스를 먼저 호출 세금/법률 글:
자동화가 법령, 조문, 정부기관 자료를 먼저 호출 리뷰/경험 글:
실제 사용 경험, 비교 기준, 장단점 중심
이 분기를 넣어야 AI가 아는 척으로 글을 쓰지 않습니다.
2단계: 네이버 상위검색 로직에 맞춰 분석합니다
저는 글쓰기 전에 검색 분석을 분리했습니다.
여기서 보는 것은 대략 이런 것들입니다.
네이버에서 이미 상위에 있는 글들은 어떤 제목을 쓰는지
사람들이 같이 검색하는 연관 키워드는 무엇인지
구글에서 자주 나오는 질문은 무엇인지
글을 읽을 사람이 초보자인지, 이미 어느 정도 아는 사람인지
이 키워드가 정보성인지, 후기성인지, 비교성인지
여기서 말하는 분석은 상위 글을 베끼는 것이 아닙니다.
제가 보고 싶은 것은 "네이버가 이 키워드에서 어떤 글을 좋은 답변으로 보고 있는가"입니다.
그래서 상위 글을 볼 때는 이런 항목을 따로 봅니다.
1. 제목 패턴 - 숫자형인지, 체크리스트형인지, 후기형인지, 비교형인지 2. 도입부 문제 정의 - 독자가 처음에 어떤 불안을 가지고 들어오는지 3. 본문 순서 - 개념 설명을 먼저 하는지, 방법을 먼저 주는지, 사례를 먼저 주는지 4. 근거 수준 - 경험담만으로 충분한 키워드인지, 수치/법령/출처가 필요한 키워드인지 5. 독자가 얻어가는 결과 - 글을 읽고 바로 체크할 수 있는 표, 리스트, 루틴, 판단 기준이 있는지 6. 최신성 - 날짜가 중요한 키워드인지, 에버그린 글감인지
상위 검색 로직을 이렇게 보면 글의 방향이 달라집니다.
예를 들어 "전세사기 예방 체크리스트"라는 키워드라면 단순히 전세사기의 뜻을 설명하는 글보다, 독자가 계약 전에 바로 확인할 수 있는 체크리스트와 법적 근거가 있는 글이 더 맞습니다.
반대로 "초보 러너 5km 훈련"이라면 법령이나 공식 통계보다, 초보자가 오늘부터 따라 할 수 있는 주차별 루틴과 부상 방지 설명이 더 중요합니다.
예를 들어 "초보 러너 5km 훈련"이라면 단순히 훈련표를 쓰는 게 아니라 이런 질문을 먼저 봅니다.
- 초보자가 5km를 뛰려면 몇 주가 걸릴까?
- 매일 뛰어야 할까, 쉬는 날이 필요할까?
- 무릎이 아프면 계속 뛰어도 될까?
- 속도보다 시간이 먼저일까?
- 러닝화나 무릎보호대가 꼭 필요할까?
이 과정을 넣으니 글이 훨씬 덜 뜬구름 잡게 됐습니다.
2.5단계: 법령·실거래가가 필요한 글은 자동으로 근거를 찾아옵니다
검색 의도를 파악한 다음에는 파이프라인이 근거가 필요한 글인지 자동으로 다시 분류합니다.
이 단계가 빠지면 AI가 그럴듯한 말로 빈칸을 채우기 쉽습니다.
제가 정한 기준은 단순합니다.
법령, 세금, 계약, 권리관계, 신고의무가 나오면:
파이프라인이 법령 MCP나 정부기관 자료를 자동으로 호출 아파트, 오피스텔, 지식산업센터, 매매가, 전세가, 실거래가가 나오면:
파이프라인이 호갱노노, 국토교통부 실거래가, 네이버 부동산 같은 실제 데이터 소스를 자동으로 확인
즉, 사람이 글을 읽다가 "아, 이건 법령을 찾아봐야겠다" 하고 따로 수정하는 방식이 아닙니다.
키워드와 검색 분석 결과를 보고 자동화가 먼저 판단합니다.
이 글은 법령 근거가 필요함
→ 법령 MCP 호출
→ 확인된 조문/기관 자료만 본문 작성 단계로 전달 이 글은 실거래가 근거가 필요함
→ 호갱노노/실거래가/부동산 데이터 확인
→ 확인된 가격·지역 정보만 본문 작성 단계로 전달
예를 들어 세금 글에서는 "대략 이럴 겁니다" 식으로 쓰면 안 됩니다.
양도세, 종합소득세, 임대차, 계약 해지, 중개보수 같은 내용이 감지되면 자동화가 법령이나 공식 기관 자료를 먼저 확인합니다. 그리고 글쓰기 단계에는 확인된 근거만 넘깁니다.
부동산 글도 마찬가지입니다.
어떤 지역이 좋다거나 가격이 올랐다는 말을 쓰려면 실제 거래가나 매물 흐름을 봐야 합니다. 그래서 부동산 키워드가 감지되면 자동화가 호갱노노나 국토교통부 실거래가처럼 실제 가격을 확인할 수 있는 곳을 먼저 참고합니다. 확인하지 못한 숫자는 본문 작성 단계로 넘기지 않습니다.
이 원칙을 넣고 나서 글이 훨씬 안전해졌습니다.
AI가 쓰는 문장 자체보다 중요한 것은 "AI가 어떤 근거를 자동으로 찾아와서 썼는가"였습니다.
3단계: 본문 작성은 '한 번에 완성'이 아니라 초안 생성으로 봅니다
검색 분석이 끝나면 그 결과를 바탕으로 본문을 씁니다.
여기서 제가 넣은 규칙은 세 가지입니다.
첫째, 독자가 서툴다는 전제로 씁니다.
블로그 글은 전문가에게 보고서 쓰듯 쓰면 잘 안 읽힙니다. 독자가 이미 알고 있다고 가정하지 않고, 용어를 천천히 풀어서 설명하게 했습니다.
둘째, 말투를 고정했습니다.
AI가 글을 쓰면 어느 날은 딱딱하고, 어느 날은 지나치게 친절하고, 어느 날은 광고 문구처럼 됩니다. 그래서 제 블로그에서는 기본 말투와 금지 표현을 정해두었습니다.
예를 들면 이런 문장은 줄입니다.
이 글에서는 ~에 대해 알아보겠습니다.
결론부터 말씀드리면 ~입니다.
많은 분들이 궁금해하시는 ~
도움이 되셨다면 공감과 댓글 부탁드립니다.
셋째, 글 구조를 먼저 정하고 씁니다.
제가 선호하는 기본 구조는 이런 식입니다.
1. 독자가 겪는 문제
2. 왜 이 문제가 생기는지
3. 핵심 개념 설명
4. 실제 체크리스트나 방법
5. 자주 하는 실수
6. 마무리
키워드마다 구조는 달라지지만, 적어도 "도입-본문-마무리"를 AI가 마음대로 흔들지 않게 했습니다.
4단계: 글 품질 검사를 자동화했습니다
초안이 나오면 바로 이미지로 넘어가지 않습니다.
먼저 글 품질을 검사합니다.
제가 검사하는 항목은 이런 것들입니다.
말투가 섞이지 않았는가
블로그 내부용 위키링크가 외부 글에 남아 있지 않은가
글자 수가 너무 짧지 않은가
제목과 본문이 따로 놀지 않는가
같은 문장 구조가 반복되지 않는가
부동산/세금/법률 글에서 근거 없이 단정하지 않았는가
해시태그가 깨지지 않았는가
이 단계가 생각보다 중요했습니다.
AI에게 "검토해줘"라고만 하면 대충 넘어가는 경우가 있습니다. 그래서 저는 사람이 판단하는 검토가 아니라, 코드로 잡을 수 있는 것은 코드가 먼저 잡게 했습니다.
예를 들어 내부 노트에서 쓰는 [[키워드]] 같은 위키링크가 블로그 글에 그대로 나가면 이상합니다. 이런 건 AI가 "괜찮아 보입니다"라고 판단하면 안 되고, 발견 즉시 실패 처리해야 합니다.
5단계: 이미지를 생성합니다
본문이 통과하면 이미지를 만듭니다.
저는 현재 Codex의 이미지 생성 기능을 기본으로 씁니다. 별도 API 비용을 최대한 줄이고, 현재 작업 중인 글 맥락을 그대로 이어받기 좋기 때문입니다.
하지만 Codex를 쓰지 않는 분이라면 이미지 생성 API를 따로 붙이면 됩니다. 이때 대안으로 쓸 수 있는 것이 Google Gemini의 이미지 생성 모델, 흔히 말하는 Nano Banana 계열입니다.
2026년 기준 Google 공식 문서에서는 Nano Banana가 Gemini의 네이티브 이미지 생성 기능을 가리키며, 모델은 용도에 따라 나뉩니다.
gemini-3.1-flash-image: Nano Banana 2, 속도와 품질 균형
gemini-3-pro-image: Nano Banana Pro, 더 고품질 자산 제작용
gemini-2.5-flash-image: 기존 Nano Banana, 빠르고 저렴한 대량 생성용
처음 만드는 분이라면 이렇게 생각하면 됩니다.
이미지 퀄리티와 비용 균형:
gemini-3.1-flash-image 빠르고 저렴한 대량 생성:
gemini-2.5-flash-image 광고 이미지처럼 더 정교한 결과:
gemini-3-pro-image
공식 문서:
https://ai.google.dev/gemini-api/docs/image-generation
Nano Banana API 최소 예시
Python에서는 대략 이런 식으로 쓸 수 있습니다.
import os
from google import genai
from google.genai import types client = genai.Client(api_key=os.environ["GEMINI_API_KEY"]) prompt = """
네이버 블로그 커버 이미지.
주제: 초보 러너를 위한 5km 훈련 루틴.
밝고 현실적인 러닝 장면.
이미지 안에는 글자를 넣지 말 것.
비율은 16:9.
""" response = client.models.generate_content( model="gemini-3.1-flash-image", contents=[prompt], config=types.GenerateContentConfig( response_modalities=["IMAGE"], response_format={ "image": { "aspect_ratio": "16:9" } }, ),
) for part in response.parts: if part.inline_data is not None: image = part.as_image() image.save("cover.png")
실제로 운영할 때는 이 코드를 글쓰기 파이프라인 안에 넣습니다.(그냥 말로 하시면 됩니다.)
중요한 규칙은 이것입니다.
이미지 안에 글자를 넣지 말 것.
AI 이미지 생성은 한글 텍스트를 아직 안정적으로 잘 만들지 못하는 경우가 많습니다. 그래서 저는 이미지 자체에는 글자를 넣지 않고, 필요하면 나중에 별도 후처리 단계에서 제목을 얹습니다.
6단계: 이미지 후처리를 합니다
이미지가 생성됐다고 바로 글에 넣지 않습니다.
블로그에 이미지를 여러 장 넣어보면 이런 문제가 생깁니다.
커버 이미지와 본문 이미지의 톤이 다름
어떤 이미지는 너무 어둡고 어떤 이미지는 너무 밝음
비율이 제각각이라 글이 지저분해 보임
이미지 안에 이상한 글자가 들어감
섹션 내용과 이미지가 맞지 않음
그래서 저는 이미지를 후처리합니다.
주로 보는 항목은 이렇습니다.
16:9 비율인지
최소 해상도를 넘는지
커버와 섹션 이미지의 톤이 너무 튀지 않는지
이미지 파일명이 글 slug와 연결되는지
커버에는 제목 오버레이를 따로 넣을지
이미지 생성보다 중요한 건 "글에 넣었을 때 자연스러운가"였습니다.
7단계: 이미지를 본문에 자동 삽입합니다
다음은 이미지를 본문에 넣는 단계입니다.
여기서도 그냥 위에서부터 순서대로 넣으면 안 됩니다.
예를 들어 FAQ 섹션이나 마무리 문단에는 이미지가 없어도 됩니다. 반대로 핵심 설명이 시작되는 지점에는 이미지가 있으면 좋습니다.
제가 쓰는 방식은 대략 이렇습니다.
커버 이미지:
글 맨 위 섹션 이미지 1:
문제 상황 또는 핵심 개념 설명 앞 섹션 이미지 2:
방법론 또는 체크리스트 앞 섹션 이미지 3:
실수/주의사항 또는 정리 앞
즉, 이미지를 많이 넣는 것보다 "읽는 흐름을 끊지 않는 위치"를 찾는 게 더 중요했습니다.
8단계: 옵시디언에 초안을 저장합니다
완성된 글은 바로 사라지면 안 됩니다.
저는 모든 블로그 초안을 옵시디언에 저장합니다.
이렇게 해두면 좋은 점이 많습니다.
내가 어떤 글을 썼는지 나중에 검색할 수 있음
비슷한 주제로 다시 쓸 때 이전 글을 참고할 수 있음
발행 전 수정 이력이 남음
블로그 자동화가 실패해도 중간 산출물이 남음
주간/월간 회고에서 "이번 달 어떤 글을 썼는지" 다시 볼 수 있음
자동화에서 가장 중요한 건 성공했을 때보다 실패했을 때입니다.
실패해도 초안, 이미지, HTML 중 어디까지 만들어졌는지 남아 있어야 다시 이어갈 수 있습니다.
9단계: 네이버 블로그용 HTML을 만듭니다
마크다운 초안이 완성되면 네이버 블로그 에디터에 붙여넣기 좋은 HTML로 변환합니다.
이 단계에서 처리하는 것은 이런 것들입니다.
제목 크기
문단 간격
리스트 스타일
이미지 경로
해시태그 영역
줄바꿈
네이버 에디터에서 깨질 수 있는 스타일 정리
제가 처음에 가장 많이 겪은 문제가 줄바꿈이었습니다.
마크다운에서는 보기 좋은데, 네이버 에디터에 붙여넣으면 문단 간격이 이상해지거나 이미지 위치가 깨지는 경우가 있었습니다.
그래서 최종 산출물은 이렇게 만듭니다.
블로그 초안.md
블로그 초안.html
이미지 파일들
그다음 HTML 파일을 브라우저에서 엽니다.
그리고 이렇게 합니다.
1. HTML 파일 열기
2. Cmd + A 로 전체 선택
3. Cmd + C 로 복사
4. 네이버 블로그 글쓰기 화면 열기
5. 본문에 붙여넣기
6. 제목, 카테고리, 태그 확인
7. 사람이 최종 발행
이 방식이 약간 수동처럼 보일 수 있습니다.
하지만 제 기준에서는 이 지점이 가장 현실적이었습니다. AI가 글과 이미지를 거의 다 만들어주고, 사람은 최종 편집자 역할만 합니다.
왜 네이버 자동 등록까지 하지 않았나
처음에는 네이버 블로그 등록까지 자동화하고 싶었습니다.
그런데 실제로 해보면 변수가 많았습니다.
로그인 세션이 만료될 수 있음
네이버 에디터 UI가 바뀔 수 있음
이미지 업로드가 중간에 실패할 수 있음
자동화가 잘못된 계정으로 동작할 위험이 있음
발행 직전 사람이 확인해야 할 문장이나 표현이 있음
특히 블로그는 외부에 공개되는 글입니다.
그래서 저는 최종 게시 버튼은 사람이 누르는 게 맞다고 판단했습니다.
대신 사람의 일을 최소화했습니다.
예전:
검색 → 글쓰기 → 이미지 만들기 → 이미지 넣기 → 에디터 정리 → 발행 현재:
완성된 HTML 열기 → 전체 복사 → 네이버에 붙여넣기 → 확인 후 발행
이 정도만 돼도 체감은 꽤 큽니다.
실제로 세팅하려면 이렇게 나누면 됩니다
처음부터 거창하게 만들 필요는 없습니다.
제가 다시 처음 만든다면 아래 순서로 작게 시작할 것 같습니다.
1. 폴더를 먼저 정합니다
blog-automation/ drafts/ images/ html/ scripts/ data/
처음에는 이 정도면 충분합니다.
2. 키워드 입력 파일을 만듭니다
{ "keyword": "초보 러너 5km 훈련", "category": "running", "target_reader": "러닝을 막 시작한 사람", "tone": "쉽고 차분한 설명"
}
이런 입력 파일이 있으면 AI가 매번 다른 방향으로 튀는 것을 줄일 수 있습니다.
3. 검색 분석 프롬프트를 따로 둡니다
너는 블로그 키워드 분석가다.
아래 키워드로 글을 쓰기 전에 네이버 상위검색 의도와 글 구조를 분석해라. 주의:
- 상위 글을 베끼지 않는다.
- 네이버가 이 키워드에서 어떤 답변 형식을 선호하는지 분석한다.
- 독자가 검색창에 이 키워드를 넣은 이유를 먼저 추정한다. 출력:
1. 검색 의도 한 줄 요약
2. 상위 글 제목 패턴
3. 상위 글의 공통 본문 흐름
4. 독자가 궁금해할 질문 7개
5. 글에서 반드시 다뤄야 할 소주제 5개
6. 필요한 근거 자료 - 법령/세금/계약이면 다음 단계에서 법령 MCP 또는 정부기관 자료 자동 호출 - 부동산/시세/실거래가면 다음 단계에서 호갱노노, 국토교통부 실거래가, 네이버 부동산 자동 확인
7. 피해야 할 뻔한 제목 5개
8. 추천 글 구조
이 프롬프트에서 중요한 것은 "필요한 근거 자료" 항목입니다.
AI가 글을 쓰기 전에 스스로 "이건 법령 확인이 필요한 글이다", "이건 실거래가 확인이 필요한 글이다"라고 분류하고, 다음 자동 수집 단계로 넘기게 만드는 장치입니다.
3.5. 근거 수집 자동 스테이지를 따로 둡니다
법령이나 실거래가가 필요한 키워드는 검색 분석 다음에 자동 근거 수집 스테이지로 넘어가게 합니다.
여기서 사람이 직접 자료를 찾아 붙이는 것이 아니라, 자동화가 필요한 도구를 호출하고 확인된 근거만 본문 작성 단계로 넘깁니다.
너는 블로그 본문을 쓰기 전 자동으로 근거를 수집하는 조사자다. 키워드: {keyword}
분류: {category} 규칙:
- 법령/세금/계약/권리관계가 포함되면 법령 MCP 또는 정부기관 자료를 자동 호출한다.
- 부동산/아파트/오피스텔/지식산업센터/시세/실거래가가 포함되면 호갱노노, 국토교통부 실거래가, 네이버 부동산 등 실제 데이터 출처를 자동 확인한다.
- 확인하지 못한 수치는 쓰지 않는다.
- 확인한 사실과 추정은 분리한다.
- 확인된 근거만 본문 작성 스테이지로 넘긴다. 출력:
1. 확인한 사실
2. 출처
3. 본문에 쓸 수 있는 문장
4. 본문에서 단정하면 안 되는 내용
이 단계를 넣으면 블로그 글이 "AI가 그럴듯하게 쓴 글"에서 "자동화가 찾아온 근거 위에 쓴 글"로 바뀝니다.
4. 본문 작성 프롬프트를 따로 둡니다
너는 네이버 블로그 작가다.
위 검색 분석 결과와 근거 수집 결과를 바탕으로 글을 작성해라. 조건:
- 초보자도 이해하게 쓴다.
- 과장 광고 문구를 쓰지 않는다.
- 단락을 짧게 나눈다.
- 네이버 상위검색 의도에 맞게 독자가 원하는 답부터 빠르게 준다.
- 법령/세금/계약/권리관계 내용은 확인된 근거 안에서만 쓴다.
- 부동산 가격, 시세, 실거래가 내용은 확인된 데이터 안에서만 쓴다.
- 확인하지 못한 수치는 추정으로 쓰지 않는다.
- 본문 중간에 이미지 삽입 위치를 표시한다.
- 마지막에 해시태그를 제안한다.
5. 품질 검사 규칙을 코드나 체크리스트로 둡니다
처음에는 코드까지 만들지 않아도 됩니다.
아래 체크리스트만 있어도 좋습니다.
- 제목과 본문 주제가 일치하는가?
- 도입부가 너무 뻔하지 않은가?
- 같은 문장 패턴이 반복되지 않는가?
- 근거 없는 단정이 없는가?
- 네이버 상위검색 의도와 본문 구조가 맞는가?
- 법령/세금/계약 내용에 확인한 출처가 있는가?
- 부동산 가격/실거래가/시세 내용에 실제 확인 출처가 있는가?
- 이미지 삽입 위치가 있는가?
- 네이버에 붙여넣을 때 깨질 만한 마크다운 문법이 남아 있지 않은가?
나중에 자동화가 익숙해지면 이 체크리스트를 코드로 바꾸면 됩니다.
6. 이미지는 처음엔 1장만 자동화합니다
처음부터 본문 이미지 5장을 만들려고 하면 복잡해집니다.
처음에는 커버 이미지 1장만 자동 생성해도 충분합니다.
커버 이미지 프롬프트:
주제: {블로그 제목}
용도: 네이버 블로그 커버
스타일: 밝고 현실적인 사진 느낌
비율: 16:9
금지: 이미지 안의 글자, 로고, 워터마크
7. HTML 변환은 꼭 마지막에 합니다
마크다운을 바로 네이버에 붙여넣으면 깨질 수 있습니다.
그래서 저는 HTML 변환 단계를 따로 둡니다.
핵심은 "네이버 에디터에 붙여넣기 좋은 HTML"을 만드는 것입니다.
단순히 예쁜 웹페이지를 만드는 HTML과, 네이버 에디터에 붙여넣었을 때 문단과 이미지가 유지되는 HTML은 다릅니다.
제가 운영하면서 배운 점
가장 큰 배움은 이것이었습니다.
AI 자동화는 한 번에 끝까지 맡기는 것보다, 실패해도 복구 가능한 단계로 쪼개는 게 훨씬 안정적입니다.
블로그 자동화도 마찬가지였습니다.
처음에는 "AI가 블로그를 알아서 써서 올려준다"를 꿈꿨습니다.
하지만 실제 운영해보니 더 좋은 방향은 이거였습니다.
AI는 반복 작업을 맡는다.
사람은 판단과 최종 발행을 맡는다.
AI가 잘하는 일은 많습니다.
자료를 빠르게 정리하기
글 구조 잡기
초안을 여러 버전으로 만들기
이미지 프롬프트 만들기
문단을 다듬기
HTML로 변환하기
반대로 사람이 해야 하는 일도 남습니다.
이 글이 내 이름으로 나가도 되는지 판단하기
표현이 너무 세거나 부정확하지 않은지 보기
최종 발행 버튼 누르기
독자 반응을 보고 다음 글 방향 정하기
이 경계를 정하니 자동화가 훨씬 편해졌습니다.
결과
지금은 블로그 글을 만들 때 매번 처음부터 시작하지 않습니다.
키워드만 정하면 자동화가 검색 의도, 필요한 근거, 본문 초안, 이미지, HTML까지 순서대로 만들어줍니다.
저는 마지막에 글을 읽고, 이상한 부분만 최종 검수하고, 네이버 블로그에 붙여넣어 발행합니다.
완전 무인 자동화는 아닙니다.
하지만 제 기준에서는 오히려 이 방식이 더 오래 쓸 수 있는 자동화였습니다.
글쓰기에서 가장 귀찮은 반복 작업은 각 에이전트가 나눠 가져가고, 최종 판단은 사람이 남겨두는 구조입니다.
앞으로 더 개선하고 싶은 점
앞으로는 세 가지를 더 개선하고 싶습니다.
첫째, 글마다 어떤 이미지 스타일이 잘 맞았는지 기록하려고 합니다. 같은 스타일을 계속 쓰면 블로그가 단조로워지기 때문입니다.
둘째, 네이버에서 실제로 반응이 좋았던 글을 다시 분석해서 다음 글 주제 선정에 반영하고 싶습니다.
셋째, 자동화 결과를 더 사람이 읽기 쉽게 보고받고 싶습니다. 예전에는 "HTML 생성 완료" 같은 식으로만 알림이 왔는데, 이제는 "어떤 글이 완성됐고, 어디를 확인하면 되고, 다음에 사람이 뭘 하면 되는지"까지 알려주는 방식으로 바꾸고 있습니다.
마무리
블로그 자동화는 생각보다 간단하게 시작할 수 있습니다.
처음부터 완전 자동 발행을 목표로 잡지 않아도 됩니다.
오히려 이렇게 시작하는 게 더 좋습니다.
1. 나는 키워드만 입력한다.
2. 검색 분석 에이전트가 상위검색 의도를 잡는다.
3. 근거 수집 에이전트가 법령/실거래가를 자동 확인한다.
4. 본문 작성 에이전트가 초안을 쓴다.
5. 이미지 에이전트가 커버와 섹션 이미지를 만든다.
6. HTML 변환 에이전트가 네이버에 붙여넣기 좋은 형태로 만든다.
7. 사람은 최종 검수 후 복사해서 붙여넣는다.
이 정도만 해도 블로그를 쓰는 부담이 많이 줄어듭니다.
AI 자동화의 핵심은 사람을 빼는 게 아니라, 사람이 더 중요한 판단에 시간을 쓰게 만드는 것이라고 느꼈습니다.
저에게 블로그 자동화는 "AI가 대신 글을 올려주는 시스템"이 아니라, 제가 꾸준히 쓸 수 있게 옆에서 초안과 재료를 준비해주는 글쓰기 파트너에 가깝습니다.
부록 : 뭘 쓸지 키워드 조사도 자동화 해야겠죠? 매일 아침 네이버 검색순위로 키워드 조사하고, 내 블로그 통계에 들어가서 일, 주, 월 조회수 순위를 분석해서 다음에 뭘 쓸지 대시보드로 알려줍니다. 다음 사례글로 올려보겠습니다. https://sia-ian.vercel.app/viz/2026-06-04-blog-keyword-board
오늘의 사례글에는 오글거림이 있을 수 있으니 주의 요망! ^^
📖 소개
시도한 것: AI 에이전트를 가족 단위로 확장하고, 나의 콘텐츠 생산 워크플로우를 자동화하는 것.
아내는 컴퓨터를 잘 모른다. 항상 나에게 질문이 많았다. "이거 어떻게 해?", "이 파일 어디 있어?", "이런 논문 검색해줘." 하루에도 몇 번씩 같은 종류의 질문에 답변하느라 내 업무 흐름이 끊기던 어느 날, 문득 든 생각이 있었다.
"해미가 아내에게 가르쳐주면 되지 않을까?"
이미 텔레그램에서 나만의 비서 '해미'를 만들어 쓰고 있었다. 해미는 Obsidian 볼트의 지식을 기반으로 질문에 답하고, 파일을 검색하고, 각종 지시를 수행하는 에이전트였다. 그런데 이 에이전트를 아내도 쓸 수 있다면? 나에게 오던 질문을 해미가 대신 처리해준다면?
그리고 블로그 자동화. 네이버와 티스토리 모두 API를 제공하지 않는다. 얼마 전까지 작동하던 자동화 스킬들이 봇 감지 시스템 업데이트 때문에 갑자기 먹통이 되기도 했다. 결국 블로그 글 등록은 '복사-붙여넣기' 수준으로 수동화할 수밖에 없었다. 그런데 오히려 그 제약이 더 본질적인 질문을 하게 만들었다.
"자동화의 핵심은 API가 아니라, 나의 워크플로우를 얼마나 정확하게 반영했는가."
시작은 단 하나였다. 블로그 콘텐츠 자동화. 그런데 지금은 병렬로 진행 프로젝트가 8개가 됐다.
블로그 콘텐츠 자동화 (관망대가 + 에스떼이브)
아내 사업체 랜딩페이지 + 마케팅
DHI-AFoods B2B 중개 (실사검증·제안서·금융)
LCT 레비뉴본드 금융 설계
다나리 AI 래퍼 서비스(외부 IP)
비즈니스모델 프레임워크 자동화 에이전트 구축
가족 튜터 에이전트 (연&연)
LLM Wiki 구축 및 커스터마이징
이번 사례글은 네 가지 이야기를 담고 있다.
1. 아내의 비서가 된 해미 — 텔레그램 아내 전담 튜터!
2. 백업 자동화 — 해미가 윈도우 스케줄러를 움직이다
3. 블로그 자동화 — 제약이 만든 설계의 진화
4. LLM-Wiki와 연동하여 bkit으로 아내 사업체 랜딩페이지 생성
🛠️ 진행 방법
Part 1. 아내의 비서가 된 해미 — 텔레그램 아내 전담 튜터!
사용한 도구: Hermes Agent, 텔레그램 그룹, delegate_task, 조건식 분기
1단계: 3명의 방을 만들다
텔레그램에 나, 아내, 해미가 함께 있는 그룹방 '연&연'을 만들었다. 초반 테스트에서 문제가 발생했다. 해미는 나의 대화에만 반응했고, 아내의 메시지는 무시했다.
해결: 아내의 텔레그램 사용자 ID를 해미 설정에 저장
→ 두 사람의 메시지 모두에 반응하도록 조건식 수정
2단계: 사적 대화 문제
조건식을 넣었더니 이번엔 다른 문제가 생겼다. 해미가 두 사람의 사적 대화에도 무조건 끼어들었다. "오늘 뭐 먹을까?" 같은 부부 대화에도 AI가 참견하는 상황.
해결: 조건식을 더 정교하게 설계
→ 문장의 시작과 끝에 "해미" 또는 "해미스" 호출 시에만 반응
→ 업무 관련 키워드 감지 시 자동 반응
→ 사적 대화는 무시
3단계: 아내의 비서로 자리잡다
현재 아내는 텔레그램에서 해미에게 직접 지시한다. 유튜브 URL을 보내면 요약해달라고 하고, 그날의 주제 음악을 추천받고, 명언을 검색해달라고 한다. 컴퓨터 관련 질문도 해미가 처리한다. 나에게 오던 질문의 90%가 해미에게로 갔다.
그리고.... 사적인 걸 오픈하는 게 나도 오글거리지만 그냥 오픈한다. 22기 동기생인 '영달님'과 '예지님'은 오프라인 모임에서 초창기 모델을 봤었다. 영달님이 이걸 보고 자신의 어머니를 위한 튜터로 만들면 좋겠다는 말을 했는데, 그때까진 가족용 비서라는 개념을 생각해 본 적이 없었다!
예지님은 이렇게 활용하는 것을 보며 기술적 실현보다 우리 나이에 아직도 저러고 있다는 사실에 경악(?!)을 금치 못했었다. ^^;
어쨌든, 이후 온보딩 과정을 수업하며 더 우수하게 업데이트를 했다. 아내를 위한 튜터 역할을 더 강력하게 수행하고 있다.
내가 해미에게 아내애게 할 말을 전달해 달라고 하면 이 녀석이 자신의 감정도 표현하면서 이렇게 달달하게 메신저 역할을 해준다. 아내가 요즘 더욱 재밌어 하는 중이다. 참고로 우리는 21년차 부부에 국민학교 동창이다 ㅋㅋ ^^
중요한 지점은, 말을 전달하는 것 뿐 아니라 아내에게 전달할 문서, 지식, html, url까지 조사시켜서 전달할 수 있다는 것이다. 해미 비서와 나만 있는 방에서 일을 시켜 정리한 후에 최종 결과물만 보내도 된다. 얼마 전에는 아내와 나 둘만의 여행 취향, 예산을 반영하여 해미에게 여행 장소 및 일정을 설계하게 만들었는데 효과가 상당했다. 이것도 멀티에이전트로 만들었다.
뭔가 우리를 위해서 오글거림을 표현하는 애(?!)가 있다는 것이 묘한 기분을 느끼게 한다.
Part 2. 백업 자동화 — 해미가 윈도우 스케줄러를 움직이다
Hermes Agent 자체에는 LLM Wiki 백업이나 중요 업무자료 백업을 '지정 시간에 자동 실행'하는 기능이 없었다. Hermes의 크론잡은 있지만, 운영체제 레벨의 스케줄링은 아니었다.
해결 방법은 의외로 단순했다. 해미에게 지시하면 해미가 Windows PowerShell 명령을 실행해서 작업 스케줄러에 등록하는 것.
LLM Wiki 백업 (20분마다):
$action = New-ScheduledTaskAction -Execute "wsl" -Argument "-e bash /home/joseph-agnet/wiki-backup.sh"
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 20)
Register-ScheduledTask -TaskName "KMDK-Wiki-Backup" -Action $action -Trigger $trigger
중요 업무자료 백업 (1시간마다):
실제 wiki-backup.sh 내용: 1. Users Obsidian 볼트 → VPS rsync -avz --delete \ --exclude='.git' \ --exclude='node_modules' \ --exclude='.obsidian/workspace*' \ "/mnt/c/KMDK/" "root@**.***.**.***:/root/users-backup/" 2. AI 에이전트 프로젝트 → VPS rsync -avz --delete \ --exclude='.git' \ --exclude='node_modules' \ --exclude='pycache' \ --exclude='.venv' \ --exclude='*.pyc' \ "/mnt/c/00-ai-agent-test/" "root@**.***.**.***:/root/users-ai-agent-backup/"
※ IP는 보안상 별표 표시함.
WSL 터미널에서 powershell.exe -Command "..."로 Windows 작업 스케줄러를 제어하는 패턴이다. 해미가 이 명령을 대신 실행해주니, 나는 "백업 설정해줘" 한 마디면 끝이었다.
Part 3. 블로그 자동화 — 제약이 만든 설계의 진화
핵심 현실:
네이버 블로그 API: 없음
티스토리 블로그 API: 없음 (2026년 완전 폐쇄)
네이버 봇 감지(CAPTCHA): 능동적 업데이트 → 얼마 전까지 작동하던 스킬들이 갑자기 먹통
블로그 글 등록: 복사-붙여넣기 수준이 유일한 방법
API가 없으니 완전 자동화는 불가능했다. 그런데 오히려 그 제약이 더 근본적인 곳으로 눈을 돌리게 만들었다. "글을 자동으로 올리는 것"보다 "글을 자동으로 만드는 것"이 더 중요하다는 걸 깨달은 거다.
1) 원칙과 지침의 코드화 — 토큰비 30% 절감
블로그 콘텐츠를 생성할 때 가장 까다로운 건 '원칙'이다. 어떤 톤으로 쓸지, 어떤 표현을 쓸지, 어떤 키워드를 넣을지. 이것을 AI에게 매번 텍스트로 전달하면 토큰비가 눈덩이처럼 불어난다.
해결책: 코드화 할 수 있는 것들은 Python으로 만들어 토큰비를 0원으로 만들었다.
항목
이전 (LLM에 전달)
이후 (Python 코드)
해시태그 자동 생성
매번 토큰비 발생
content-utils.py → 0원
하단 템플릿 삽입
매번 토큰비 발생
content-utils.py → 0원
금지 표현 검출
AI가 "읽고" 지켜야 함
quality-checker.py → 0원
글자수 검증
AI가 "읽고" 확인
quality-checker.py → 0원
이미지 파일명 규칙
매번 토큰비 발생
content-utils.py → 0원
핵심 원칙: "기준과 규칙을 공식화하여 코드화로 진행한다."
AI에게 "이런 법칙을 지켜"라고 말하는 건 학생에게 "교과서 읽고 시험 잘 봐"라고 말하는 것과 같다. 읽는 것과 행동하는 것은 다른 문제다. 그래서 검증 가능한 항목은 전부 Python 스크립트로 분리했다. AI는 글을 쓰고, 코드가 품질을 검증하는 구조.
2) 마케팅 전자책 6권의 분류 — 코드화 vs 지침
마케팅 전자책 6권의 내용을 전부 AI에게 읽히면 AGENTS.md가 비대해지고, 매번 토큰비가 발생한다. 그래서 6권의 내용을 두 영역으로 분류했다.
코드화 영역 (토큰비 0원):
금지 표현 검출 ("치료"→"케어", "시술"→"관리")
글자수 검증 (2,400~2,600자)
해시태그 자동 생성 (핵심 3개 + 롱테일 1개 + 보조 2개 + 브랜드 고정)
이미지 파일명 자동 생성 (지역-서비스-형용사.jpg)
하단 고정 템플릿 (주소, 전화, 영업시간)
지침 영역 (에이전트가 읽어야 하는 것):
GRACE-AGING 철학 (되돌리기가 아니라 다시 드러내기)
확인형 화법 ("이런 건 어떠세요?" 같은 고객 존중 톤)
SEO/AEO/GEO 전략 (롱테일 키워드 배치 규칙)
72시간 재예약 유도 전략
10회권 전환 전략
코드화할 수 없는 지침은 AGENTS.md에 최소한으로 압축해서 넣고, 소재별로 필요한 규칙만 동적으로 로딩하는 구조를 설계 중이다.
Part 4. LLM-Wiki와 연동하여 bkit으로 아내 사업체 랜딩페이지 생성
이번 학습 기간에 시도한 또 다른 실험. 아내의 에스떼이브 사업체 랜딩페이지를 AI로 생성해봤다.
Obsidian 볼트에 이미 LLM Wiki 구조로 정리된 사업 데이터(정체성, 철학, 서비스, 가격표 등)가 있었다. bkit이 이 데이터를 읽고 Next.js + Tailwind CSS 기반 랜딩페이지를 자동 생성했다.
놀라운 점은 LLM Wiki와 연동하니 처리 속도가 엄청나게 빨랐다는 것이다. 인터뷰할 것조차 별로 없었다. 이미 사업의 정체성, 철학, 서비스 구조가 .md 파일로 정리되어 있었으니까.
💡 결과와 배운 점
시행착오
텔레그램 조건식 과잉 반응 — 아내 ID를 저장했더니 사적 대화에도 끼어드는 문제 발생. 문장 앞과 뒤, 그리고 해미의 답변 후 10초 내에 한 대화에만 반응하는 조건식으로 해결.
블로그 API 폐쇄 — 네이버/티스토리 모두 API 미제공. 봇 감지(CAPTCHA)가 능동적으로 업데이트되어 기존 스킬들이 먹통. 복사-붙여넣기가 유일한 방법.
AI의 "읽는 것 ≠ 행동하는 것" — 마케팅 법칙이 파일에 있는데도 AI가 감으로 태그를 다는 문제 발견. 해결: 절차를 숫자로 박고, 검증 가능한 건 코드로 분리.
VPS 설치 에러 4연속 — curl 실패 → pip 실패 → apt 실패 → venv로 해결. 서버 경험 제로에서 24/7 에이전트를 구축하는 과정 자체가 학습이었다.
도움 필요한 부분
네이버 블로그의 완전 자동 등록은 내가 아는 한 현재 기술로 불가능. 복사-붙여넣기가 최선. 콘텐츠(이미지 포함)까지 생성하고 바로 복사-붙여넣기만 하면 되는 수준까지 실현함.
이미지 자동 생성 품질의 다양성 (특정 프롬프트 패턴 반복 문제)
앞으로의 계획
마케팅 지침의 소재별 동적 로딩 구조 완성
아내의 랜딩페이지를 Vercel에 실제 배포
텔레그램 에이전트에 학습 기능 추가 (아내가 자주 묻는 질문 자동화)
핵심 교훈
에이전트는 설치하는 프로그램이 아니라 관계다 — 텔레그램과 Hermes만으로, 대화만으로 가족 튜터 에이전트를 만들었다.
제약이 설계를 만든다 — API가 없어서 복붙으로 수동화했더니, 오히려 "글을 만드는 자동화"에 집중하게 되었다.
코드로 잡을 수 있는 건 코드가 먼저 — AI에게 "읽고 지키라고" 시키면 비용↑, 신뢰↓. Python으로 분리하면 비용 0, 검증 100%.
비용은 구조의 문제다 — Claude Code 2일 만에 토큰 소진 → DeepSeek 전환 → context 압축 → MiMo 2.5 Pro. 모델을 바꿔도 역할과 흐름이 남아 있다면 작업은 이어진다. 단, Hermes 구조에서 모델마다 Hermes의 지시를 지키는 수준이 다르다는 걸 발견했다.
가족이 쓰는 AI가 진짜 검증이다 — 컴퓨터를 모르는 아내가 매일 쓰는 에이전트는, 전문가인 나만 쓰는 에이전트보다 10배 더 많은 예외 상황을 만들어낸다. 그 예외들을 하나씩 해결하는 과정이 곧 실력이다.
📚 도움 받은 글 (옵션)
Karpathy LLM Wiki — 지식관리 구조의 기반
Karpathy, "The Busy Person's Intro to LLMs" (2023) — 비전문가가 LLM을 이해하는 프레임워크
Simon Willison의 블로그 (simonwillison.net) — AI 애플리케이션에서 "코드로 검증 가능한 건 코드로"라는 철학의 근거
✅ Do (해야 할 것)
✅ 검증 가능한 규칙은 Python으로 분리할 것 (토큰비 0, 신뢰 100%)
✅ AI 에이전트의 절차는 숫자로 박을 것 (모델이 바뀌어도 따라감)
✅ 가족이 쓰는 관점에서 설계할 것 (전문가 관점이 아닌)
✅ 백업은 운영체제 레벨 스케줄러로 강제화할 것
❌ Don't (하지 말아야 할 것)
❌ AI에게 "읽고 지키라고"만 시키기 — 코드가 검증하게 만들어야 함
❌ API 없이 완전 자동화를 억지로 시도하기 — 복붙이 최선일 때도 있음
❌ 사적 대화에 AI가 끼어들게 두기 — 조건식을 정교하게 설계할 것
❌ 마케팅 법칙을 감으로 적용하기 — 데이터 기반으로 태그 구성
📝 한줄 요약
코딩을 업으로 하지 않던 제가, AI 코딩 도구(Claude Code)와 둘이서 약 일주일 동안 연구자를 돕는 웹 서비스를 만들었습니다. 흩어진 제 경력 자료 한 폴더에서 시작해, 자료를 올리면 프로필 → 연구 아이디어 → 실험 설계 → 장비 추천 → 논문 초안 → 연구계획서까지 이어주는 서비스의 골격을 세우고 공개 직전까지 왔습니다. 이 글은 그 전 과정을 한 편에 담은 기록입니다.
바쁘시면 이것만 읽어도 돼요:
손으로 한 번 돌려본 것이 그대로 서비스의 가능성 검증(PoC)이 됐다
"한 단계부터" 만들고 복제로 확장하니, 4단계 → 6단계까지 빠르게 커졌다
AI를 붙이면 호출마다 돈이 나간다 — "비쌀 것 같다"를 숫자로 재서 결정했다
막히면 땜질하다, 한계가 오면 구조를 바꿨다("답답하다, 비동기로 가자")
"테스트 다 통과 = 정상"이 아니다 — 따옴표 하나로 화면이 백지가 됐다
공개 직전 깨달음: 진짜 위험은 해킹이 아니라 비용이다
🎯 이런 분들께 도움돼요
흩어진 경력·실적을 정리해야 하는 전문직, 방향을 찾는 연구자·대학원생·과제 담당자, 커리어 전환자
AI로 혼자 서비스를 만들어보려는 1인 도전자 — "비용이 무섭다", "왜 어떤 날은 되고 어떤 날은 안 되지?", "공개해도 안전할까?"가 와닿는 분
😫 문제 상황 (Before)
저는 10년간 소재·전자현미경(TEM) 연구를 해온 공학 박사이고, 지금은 AI 개발자로 전환 중입니다. 진짜 목표는 연구자를 위한 자동화 서비스를 만드는 것이었습니다 — CV·자료를 정리해 프로필을 만들고, 그걸로 연구를 설계하고, 필요한 장비를 추천해주는 서비스요.
문제는 될지 확신이 없었다는 겁니다. 그리고 막상 만들기로 해도, 웹앱을 처음부터 끝까지 만들어본 적이 없었습니다. 그래서 거창한 계획 대신, AI와 둘이서 하나씩 부딪혀보기로 했습니다. 그 일주일의 기록입니다.
🛠️ 사용한 도구
도구명: Claude Code (터미널에서 쓰는 AI 코딩 도구)
모델: Claude Opus 4.8 (구현) / OpenAI gpt-4.1-mini (서비스의 생성 엔진)
방식: "만들어줘"가 아니라 대화로 설계 → 내 자료로 직접 써보고(dogfooding) → 막히면 같이 고치기
🔧 작업 과정
1막. 프로필 정리인 줄 알았는데, 서비스였다
시작은 소박했습니다. 제 경력 자료를 AI에게 통째로 주고 이렇게 말했죠.
현재 프로젝트 폴더의 파일들은 나의 정보를 가지고 있어
파일들을 깊이 있게 확인해서 나의 정보를 정리해서 프로필을 작성해줘
AI는 엑셀·PDF·워드를 하나씩 읽어 날짜·실적을 원본과 대조 검증하며 프로필 한 건으로 정리했습니다. 거기서 "내가 뭘 연구할 수 있는지"까지 진단받았죠. 그리고 제 진짜 의도를 밝히자, AI가 짚어준 한마디가 클라이맥스였습니다.
"오늘 손으로 한 프로필·연구 설계가, 사실 당신이 만들려던 서비스의 1~2단계를 그대로 돌려본 PoC였네요."
손으로 한 작업이 곧 서비스의 가능성 검증이었던 겁니다.
2막. 손으로 하던 걸 진짜 웹앱으로
이제 코드를 짜기로 했습니다. 단, 욕심을 잔인하게 줄였습니다.
서비스로서 도메인 특화부터 시작하고 싶어
Phase 1을 M1만으로 더 좁히자
가장 먼저 검증할 한 단계(자료→프로필)부터 만들고, 같은 패턴을 복제해 아이디어·실험설계·장비추천까지 4단계로 늘렸습니다. 그 과정에서 1인 개발자의 첫 현실과 부딪혔습니다.
클로드 코드로 하면 파일을 읽어들여서 잘 정리하는데,
api로 연결해서 하면 잘 안 되는 이유가 뭐야?
구독으로 쓰던 AI와, 서비스에 붙이는 유료 API는 분량·비용이 달랐습니다. "비쌀 것 같다"는 감을 실제로 재서(한 번에 약 1센트) 결정했습니다.
3막. 때우기를 멈추고, 구조를 바꾼 날
이 무렵 가장 끈질긴 적은 30초 안에 응답 못 하면 끊기는 제한이었습니다. 입력 줄이기, 미리 데우기, 출력 토막 내기 — 다 임시방편이었죠. 결국 제가 말했습니다.
아니 비동기로 가자 답답하다
"그 자리에서 기다리다 끊기는" 구조를, "번호표 받고 뒤에서 처리, 다 되면 알림" 구조로 바꿨습니다. 벽을 우회한 게 아니라 벽이 있던 자리를 없앤 겁니다. 더불어 AI가 "TEM"이라 부르는 장비를 "투과전자현미경"으로 번역(40종)해 한국 장비 포털에서 실제 검색되게 만들고, 결과물을 학술지풍으로 다듬었습니다.
4막. 자료만 넣었는데 논문·연구계획서까지
라이프사이클의 정점입니다. 앞 단계 산출물을 모아 논문 초안 9섹션과 연구계획서 6문항을 자동으로 써냈습니다. 가장 만족스러웠던 건 연구계획서의 '수행역량' 칸이 내 프로필 업적으로 저절로 채워진 것이었습니다.
이 막에서 잊지 못할 교훈도 얻었습니다. 따옴표 하나를 잘못 써서 화면 전체가 백지가 됐는데, 자동 검사(테스트) 156개는 전부 통과한 상태였습니다.
(테스트는 전부 통과인데 화면은 백지)
테스트는 제가 시킨 것만 검사할 뿐, 화면이 진짜 뜨는지는 직접 띄워봐야 안다는 걸 배웠습니다.
5막. 도구를 바꾸자 고생이 사라졌다
배포 환경을 바꾸다(netlify→Vercel) 예상 못 한 일이 벌어졌습니다. 3막에서 힘들게 만든 비동기 구조의 유일한 이유가 30초 제한이었는데, 새 플랫폼엔 그 제한이 없었습니다. 비동기 우회가 통째로 불필요해지고 코드가 오히려 줄었죠.
출력까지 시간이 걸리니 출력을 스트리밍 방식으로 하는 건 어때?
그리고 깜깜이 대기를 실시간 타이핑으로 바꿨습니다. 단, 사람이 읽는 글만 타이핑하고 내부 데이터는 진행 카운터로 — "부분만 봐도 의미 있나?"를 기준으로요.
6막. 진짜 위험은 해킹이 아니라 비용이었다
공개 배포만 누르면 되는 순간, 손을 멈췄습니다. 점검해보니 진짜 위험은 데이터 유출이 아니었습니다. 인증 없이 열린 AI 통로로 누군가 무제한 호출하면, 그 비용이 고스란히 제게 청구됩니다. "Origin(출처) 검증이 있잖아?" 싶었지만 — 그건 위조 가능합니다. 명찰만 확인하는데 명찰은 누구나 위조할 수 있는 셈이죠. 그래서 비용 폭탄을 막는 4겹 방어(예산 상한 → 호출 제한 → 카운터 → Origin)를 설계했습니다.
✅ 결과 (After)
전체 Before → After
항목
시작
지금
형태
손으로 돌려본 아이디어
자료→6단계 자동 웹 서비스
작동
사람이 매번 수동
자료 올리면 자동
산출물
프로필·연구설계(수동)
+ 아이디어·장비·논문·연구계획서
속도 경험
깜깜이 대기
실시간 타이핑
공개 준비
막연
비용 방어 설계 완료, 배포 직전
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
손으로 한 번 돌려보기 — 그게 곧 서비스 가능성 검증이 된다
"한 단계부터" — 한 단계가 되면 나머지는 복제로 빨라진다
비용을 숫자로 재기 — "비쌀 것 같다"를 AI에게 실제로 재달라고 하면 결정이 쉬워진다
감이 아니라 실측으로 디버깅 — "원인을 나눠서 측정해줘"라고 시키면 진짜 범인이 잡힌다
"이 문제 진짜 풀어야 해?"를 의심 — 도구를 바꾸면 문제가 사라지기도 한다
"내 경우"가 아니라 "모두의 경우"로 일반화 — 내 자료에만 맞추지 말자
이렇게 하면 안 돼요
땜질을 무한히 쌓지 않기 — "조금만 더"가 반복되면 구조를 바꿀 신호다
"테스트 통과 = 끝"이라고 믿지 않기 — 직접 화면을 띄워 확인하라
"보안 = 데이터 유출"로만 좁게 보지 않기 — AI 서비스의 1순위 위험은 비용일 수 있다
🌍 다른 업무에 적용한다면?
반복 업무 자동화: 가장 자주 하는 한 단계부터 자동화 → 옆 단계로 복제
보고서·지원서: 한 번 만든 프로필·정리 자료를 여러 양식의 칸으로 재활용
유료 API를 쓰는 모든 서비스: 공개 전 "무제한 호출 시 비용"을 계산하고 상한을 건다
느린 작업의 UX: 진행 표시·실시간 출력으로 "일하고 있음"을 보여주기
🚀 앞으로의 계획
손으로 시작한 PoC가 일주일 만에 "공개 직전"까지 왔습니다. 남은 건 설계한 비용 방어를 적용하고 배포 버튼을 누르는 것. 공개하고 나면 그 이야기로 또 찾아오겠습니다. 코딩 전문가가 아니어도, AI와 함께라면 진짜 문제를 하나씩 풀며 여기까지 올 수 있었습니다.
📋 재사용 가능한 프롬프트 (일주일의 핵심 모음)
1) 흩어진 자료로 프로필 만들기
이 폴더의 파일들은 나의 정보를 담고 있어.
깊이 있게 확인해서 내 정보를 정리해 프로필을 작성해줘.
날짜·실적은 원본끼리 대조해서 검증하고, 부풀려진 표현 없이 정확하게.
2) 욕심을 줄여 '한 단계부터' 만들기
[만들고 싶은 것]을 한 번에 다 만들지 말고, 가장 먼저 검증할 핵심 한 단계로 좁혀줘.
그 한 단계를 작은 작업들로 쪼개 계획을 세우고, 코드 전에 설계부터 보여줘.
3) AI 사용 비용을 미리 재보기
이 기능에 AI를 붙이면 한 번 호출에 비용이 얼마나 나오는지 [방식 A]와 [방식 B]로 비교해 재줘.
그 결과로 어느 방식을 기본으로 쓸지 추천해줘.
4) 땜질 대신 구조를 바꾸기
[기능]을 [임시방편]으로 버텨왔는데 한계에 부딪혔어.
임시방편 말고 구조 자체를 바꾸는 방법(예: 기다리며 처리 → 맡겨두고 알림)을 제안하고, 장단점·전환 순서를 알려줘.
5) "될 때도 안 될 때도" 문제를 실측으로 잡기
[기능]이 어떤 때는 되고 어떤 때는 안 돼. 조건은 같아.
추측하지 말고 원인을 나눠서 직접 측정해(예: 처음 켤 때 vs 데워진 뒤, 입력·출력 크기별), 진짜 원인을 분리해줘.
6) 공개 전 보안·비용 점검
이 서비스를 공개하기 전에, 이대로 열면 무슨 일이 벌어지는지 점검해줘.
AI(유료 API) 호출 부분이 인증 없이 열려 있는지, 무제한 호출 시 비용이 어떻게 청구되는지 짚고,
그럴듯한 방어(예: 출처 검증)가 우회 가능한지까지 냉정하게 검토해줘.
소개
개인 투자자가 넘쳐나는 시황·매크로·뉴스 속에서 "내 포트폴리오에 의미 있는 신호"를 스스로 찾기 어려운 문제를 해결하고자 함.
야간 미장·매크로·KRX 시세를 여러 앱과 텔레그램으로 직접 취합하는 번거로움을, 내 계좌 기준 한 화면으로 압축하고자 함.
단발성 리포트가 아니라 AI가 지식을 쌓고(위키) → 인과로 잇고(그래프) → 에이전트가 자율로 진단·점검하는(LangGraph) 3층 자동화로 만들고자 함.
클라우드 의존과 구독 비용을 최소화하고, 내 컴퓨터(맥)에서 로컬로 돌아가는 자기 소유 시스템을 지향함.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
Tip: 코드 전문은 코드블록에 감싸서 작성해주세요. ( / 을 눌러 '코드 블록'을 선택)
LLM 위키 (Obsidian + 위키 사서 AI): 종목·매크로·뉴스·투자 결정을 위키 문서로 축적하고 자동 분류·링크·정합에 사용함.
GraphRAG (PostgreSQL + pgvector): ETF·종목·매크로·뉴스·공시를 11종 관계로 묶은 인과 지식그래프 구축에 사용함.
로컬 LLM (gemma 31B, ollama) + embeddinggemma 768d: 뉴스에서 관계 추출과 의미 임베딩을 전부 로컬에서 처리하는 데 사용함.
통계 인과 (statsmodels): Granger + 다변량 VAR/IRF로 충격 전파를 수치화하는 데 사용함.
에이전트 오케스트레이션 (LangGraph · LangChain): 역할별 전문 AI(팀장·분석가·집행관·사서)를 작업 흐름으로 묶어 자율 운영하는 데 사용함.
데이터 소스: KRX·KIS·yfinance·FRED/ECOS·네이버 데이터랩·DART·YouTube·Tavily를 한 그래프로 통합하는 데 사용함.
결과
1️⃣ 3층 아키텍처 = 하나의 자동화 흐름
LLM 위키(지식 축적) → 그래프래그(인과 연결) → 에이전틱 AI(자율 실행)로, 위로 갈수록 "스스로 판단·실행"에 가까워지도록 동선을 설계함.
2️⃣ 1층 — LLM 위키
Obsidian 기반 위키에 종목·매크로·개념·뉴스를 문서로 축적하고, 위키 사서 AI가 새 자료를 자동으로 분류·링크·정합하도록 함.
실제 위키 그래프뷰에서 수백 개 문서가 이미 거대한 연결망을 이루고 있음(이번 발표의 출발점).
3️⃣ 2층 — 그래프래그 (이번 작업의 핵심)
종목→ETF 편입(비중), 매크로→가격 전파, 뉴스→영향 등 11종 관계·8만+ 엣지로 그래프를 구성함.
규칙 기반·LLM 추출·통계 인과 3가지 방식으로 엣지를 생성하고, 엔티티 해상도로 "엔비디아=NVIDIA"를 한 노드로 통합함.
다차원 인과 망과 SVAR/IRF로 "충격이 어느 종목까지 며칠 시차로 전파되는지"를 추적함.
4️⃣ 3층 — 에이전틱 AI (LangGraph)
팀장·분석가·집행관·사서 역할의 AI가 그래프를 활용해 자율로 분석·점검·핸드오프하도록 함. LangChain=도구 배관, LangGraph=작업 흐름 지휘.
중요한 결정은 사람 승인 게이트(텔레그램 확인)를 거치도록 함.
5️⃣ 데이터 파이프라인 & 정합
9종 소스를 PostgreSQL로 수집하며, KRX 당일 시세의 T+1 지연은 KIS 당일가로 채워 괴리 0%로 정합함.
6️⃣ 산출물 채널
프리마켓 퀵샷·클로징벨·주간·헤지펀드 PM 톤 리포트를 텔레그램으로 내 계좌 기준 자동 발송하고, 동적배분·RS/CANSLIM·세제 계산 등을 제공함.
배운 점
지식을 점이 아니라 인과의 선으로 이으면(그래프래그) "왜?"라는 질문에 경로로 답할 수 있음을 확인함.
로컬 LLM에서 thinking 모드를 끄는 작은 튜닝만으로 추출 속도가 6.5배 빨라짐을 확인함.
출처·기준일을 분리하고 LIVE로 재검증하는 절제가 시스템 신뢰의 핵심임을 배움.
3층(위키→그래프→에이전트)으로 나누면 각 층을 독립적으로 키우고 검증할 수 있음을 깨달음.
과정 중에 어떤 시행착오를 겪었나요?
종목 단위 리포트의 한계를 깨닫고 "관점" 단위로 전환하는 과정에서, 계좌·ETF·뉴스·매크로를 그래프로 묶어야 진짜 진단이 됨을 GraphRAG로 돌파함.
인과 그래프가 종목 그래프와 다리 3개뿐인 외딴 섬이었던 문제를, 브리지 엣지로 222개까지 이어 전파 경로를 복원함.
시뮬레이션(픽션) 데이터와 실세계 데이터의 시계열 괴리로 매크로 인과 분석이 깨지는 한계를, 이력이 긴 ETF 패널로 대체하고 그 한계를 정직하게 명시함.
통계 모델이 노이즈에서 엉뚱한 시차를 골라 결과가 깨지는 문제를 고정 시차로 교정했으며, 도구의 "성공" 메시지를 믿지 않고 LIVE로 재검증하는 습관을 들임.
데이터의 출처와 기준일을 항상 분리 표기(예: 비중=운용사 공식, 기준가=시스템 종가)하여 추정·픽션을 사실로 단정하지 않도록 함.
도움이 필요한 부분이 있나요?
앞으로의 계획이 있다면 들려주세요.
맨 위층 에이전트 자동화(LangGraph)를 본격 가동하여, 여러 에이전트가 그래프 위에서 자율로 일하는 단계로 확장할 계획임.
그래프래그 3계층(GNN 링크 예측으로 빠진 관계 추론·그래프 신호 재랭킹·전용 그래프DB·실전 백테스트 검증)을 추진할 계획임.
내 계좌 기준 정량 분석 풀스택(RS/MDD/Granger/CANSLIM/백테스트)을 자동 매핑할 계획임.
도움 받은 글 (옵션)
참고한 지피터스 글이나 외부 사례를 알려주세요.
(내용 입력)
상담센터 바우처 행정 웹앱 구축기 — 실무진과 실시간으로 핑퐁하면서, 가짜 데이터 프로토타입 5단계 → 진짜 DB 전환 → 배포까지
🎯 바쁘시면 이것만 읽어도 돼요
코딩 못 하는 자동화 담당 직원이 Claude Code로 상담센터 바우처 행정 웹앱을 만들었어요 — 첫날은 규칙 세팅, 둘째 날에 프로토타입 5단계 + 진짜 DB 전환 + 배포까지 갔어요
비결은 "한 번에 다 만들어줘"가 아니라, 가짜 데이터로 화면을 먼저 완성하고 DB는 나중에 갈아끼우는 순서였어요
제일 큰 고비는 코딩이 아니었어요 — 실무진의 업무를 제가 요약해서 AI한테 전달하는데, 그 요약이 현장과 달라서 화면 다 만든 뒤에 데이터 구조를 갈아엎었어요
👀 이런 분들께 도움돼요
동료·팀이 쓸 업무 도구를 대신 만들어주는 역할을 맡은 비개발자
"AI한테 뭐라고 시켜야 할지"보다 "실무자한테 뭘 물어봐야 할지"가 막막한 분
프로토타입은 만들어봤는데 진짜 DB·로그인·권한으로 넘어가는 게 무서운 분
만들다가 구조가 틀렸다는 걸 알았을 때 갈아엎어야 하나 고민해본 분
😮 Before: 우리 센터 바우처 업무엔 '한눈에 보는 화면'이 없었어요
최근 클코를 배우다보니 상담센터에서 자동화를 맡게 되었어요. 상담이나 행정을 직접 보는 실무자는 아니지만 옆에서 본 바우처 업무는 손이 많이 갔어요 — 내담자마다 바우처를 등록하고, 상담사가 자필 제공기록지를 내고, 소장님이 확인해야 정산이 되고, 본인부담금 입금도 챙겨야 해요. 역할도 상담사·행정·회계·소장 넷으로 갈리고요. 이게 한 화면에 모이는 도구가 없어서, 누가 뭘 냈고 뭐가 빠졌는지는 결국 실무진이 기억해야 했어요. 그러다보니 누락도 많이 생겼고요.
✨ After: 4역할이 같이 쓰는 웹앱이 이틀 만에 URL로 나왔어요
로그인하면 역할별로 다른 메뉴가 보이고, 기록지 제출 → 소장 확인 → 정산 반영이 화면 안에서 흘러가는 웹앱이 됐어요. 첫날 워크스페이스 세팅, 둘째 날 프로토타입 5단계 → Supabase(진짜 DB) 전환 → Vercel 배포까지. 코드는 한 줄도 직접 안 썼어요. 대신 말을 정말 많이 했어요 — AI한테도, 실무진한테도요.
🛠️ 이 앱이 하는 것 (배경 30초)
내담자×바우처 단위로 등록을 관리해요 (기간·등급·담당 상담사)
상담사는 회기별 기록지 사진을 올리고, 소장은 확인 버튼으로 정산에 반영해요
본인부담금 입금은 회계·소장만 수정할 수 있고, 상담사는 본인 내담자만 보여요
미제출·미확인이 화면에서 바로 표시돼요 — "실무진이 기억하던 것"이 앱의 일이 됐어요
🔨 과정: 규칙 → 가짜 데이터 → 번역 오류 발각 → 진짜 DB
1️⃣ 첫날은 코딩 대신 규칙만 세웠어요
바로 "만들어줘" 하고 싶은 걸 참고, 첫날은 워크스페이스에 규칙 문서(CLAUDE.md)부터 만들게 했어요. 핵심 규칙은 세 개였어요 — 자격·금액·일자는 추정 금지, 불확실하면 나한테 질문할 것 / 개인정보는 로컬에만, git에 못 올라가게 차단 / 등록·제출의 최종 확정은 사람이 할 것. 내담자 정보를 다루는 앱이라 이 세 줄이 없으면 시작을 못 했어요. 하루를 썼는데, 이후 작업 내내 AI가 애매하면 멈추고 물어봤으니 본전은 충분히 뽑았어요.
2️⃣ 가짜 데이터로 화면을 먼저 다 만들었어요
둘째 날, 프로토타입을 5단계로 쪼개서 진행했어요 — 뼈대 → 데이터 모델·4역할 전환 → 배정 화면 → 일정·기록지 업로드 → 소장 확인·본인부담금. 이 단계에선 DB도 로그인도 없이 전부 가짜 데이터예요. 덕분에 "화면이 실제 업무랑 맞나"만 보면 됐고, 단계마다 제 눈으로 확인하고, 애매한 건 실무진한테 바로 물어보고, code-review를 시키고 저장(커밋)하고 넘어갔어요. 리뷰가 제가 못 봤을 타입 버그를 실제로 하나 잡아내기도 했고요.
3️⃣ 😲 하이라이트: "내담자 한 명 = 상담사 한 명" — 제 번역이 틀렸어요
본인부담금 화면까지 다 만들고 나서야 알았어요. 결과적으로 바우처를 두 개 받는 내담자 같은 상황이 생길 수 있다고 들었고 바우처마다 담당 상담사가 달라요. 그런데 앱은 제가 AI한테 처음 설명한 대로 "내담자에게 상담사 한 명"으로 짜여 있었어요. AI가 틀린 게 아니에요. 실무진의 업무를 AI한테 전달하는 중간에서, 제가 잘못 요약한 거예요.
화면을 다 만든 뒤라 고민했는데, 결국 데이터 구조를 통째로 갈아엎었어요 — 모든 관리 단위를 '내담자'에서 '내담자×바우처(등록)'로요. 사람 개발자한테 이걸 부탁했으면 며칠짜리 부탁이었을 텐데, AI는 갈아엎는 걸 무서워하지 않더라고요. 반나절 안에 화면들이 새 구조로 다시 맞춰졌어요.
비슷한 일이 한 번 더 있었어요. 등록여부(O/X) 관리 기능을 만들었는데, 소장님이 한마디 하셨어요 — "상담사 배정이 안 되면 일정 등록도 안 해요." 그 말 한마디에 기능을 통째로 뺐어요. 실무진의 한 문장이 제 기획 열 줄보다 정확했어요. 실시간으로 물어볼 수 있는 거리에 실무진이 있다는 게 이 프로젝트 최대의 자원이었어요.
4️⃣ 진짜 DB로 갈아끼우기 — 읽기부터, 권한은 맨 끝에
화면이 업무와 맞다는 확신이 생긴 뒤에야 Supabase(진짜 DB)로 넘어갔어요. 순서를 잘게 쪼갰어요 — ① 테이블 설계 ② 읽기만 DB로 전환(쓰기는 아직 가짜) ③ 진짜 로그인 ④ 쓰기 전환 ⑤ 역할별 권한을 서버에서 강제(RLS). 권한은 화면에서 숨기는 걸로 끝내지 않고, 검증 스크립트를 돌려서 "상담사 계정으론 진짜 본인 것만 보이는지"를 확인하고 통과시켰어요. 끝나고 Vercel로 배포해서 URL을 받았어요.
📊 결과
단계
한 것
확인 방식
1일차
워크스페이스 + 규칙 3종 (추정 금지·개인정보 로컬·확정은 사람)
규칙 문서 리뷰
2일차 오전~
프로토타입 5단계 (가짜 데이터)
단계마다 눈 검증 + 실무진 확인 + code-review + 커밋
2일차 ~밤
DB 전환 5단계 (읽기→로그인→쓰기→권한)
권한 검증 스크립트 통과
직후
Vercel 배포
팀이 URL로 접속
역할 4종(상담사·행정·회계·소장)별 메뉴·권한 분리, 권한은 서버 강제
중간에 데이터 모델 1회 전면 교체, 만든 기능 1개 드롭 — 둘 다 "실무진이 더 정확해서"
💡 효과적이었던 것
가짜 데이터로 먼저 완성한 것 — 화면과 업무가 맞는지부터 검증하고, DB는 나중에 갈아끼웠어요. 모델을 갈아엎는 대사건이 있었는데도 이 순서 덕에 피해가 화면 수정으로 끝났어요
단계마다 멈춰서 확인한 것 — 제 눈 검증 + 실무진 확인 + code-review + 커밋 세트. 어디서 틀어졌는지 항상 한 단계 안에서 찾을 수 있었어요
실무진 말을 스펙으로 쓴 것 — 소장님 한마디로 기능을 빼고, 실제 내담자 사례로 모델을 바꿨어요. 제가 정리한 요구사항보다 현장 문장이 셌어요
⚠️ 이런 건 아쉬웠어요
남의 업무를 받아 적는 건 생각보다 어려웠어요. 실무진은 당연해서 말하지 않는 게 많고, 저는 몰라서 묻지 못하는 게 많았어요. "바우처 2개 내담자" 같은 예외는 묻기 전엔 안 나와요
실제 데이터 몇 줄을 너무 늦게 봤어요. 처음부터 진짜 내담자 명단 몇 줄(가명으로라도)을 실무진한테 받아서 같이 봤으면, 그 예외를 화면 만들기 전에 발견했을 거예요
📋 따라하려면
실무자를 인터뷰해서 업무를 역할별로 적어요 — "누가, 뭘 내고, 누가 확인하고, 뭐가 돈이 되나". 실무자가 당연해서 말 안 한 것이 진짜 스펙이에요
시작 전에 규칙 3줄부터 만들어요 — 추정 금지 / 민감정보 로컬만 / 최종 확정은 사람
가짜 데이터로 화면 먼저 — DB·로그인은 화면이 업무와 맞다는 확신이 든 다음에
단계마다 직접 확인 + 실무진 확인 + code-review + 커밋, 세트로 묶어서 진행해요
실제 데이터 샘플(가명) 몇 줄을 초반에 받아서 AI한테 보여줘요 — 예외 케이스가 모델을 결정해요
DB 전환은 읽기 → 로그인 → 쓰기 → 권한 순서로 쪼개요
내 다음 목표
진짜 데이터(내담자 200명, 2년치 기록)를 부어서 실운영에 들어가기 — 그리고 여기서 사건이 하나 터지는데, 그 이야기는 따로 한 편으로 할 예정.
현황 화면을 요약 패널에서 제대로 된 대시보드로 키우기
실무진이 보고 따라할 역할별 사용 가이드 만들기
