어떤 문제였나
저는 GPTers에서 B2B 기업 교육 세일즈를 담당하고 있습니다. 리드 관리는 Linear의 [B2B] Sales Funnel 프로젝트로 하는데, 혼자 수십 개 리드를 굴리다 보면 꼭 이런 일이 생깁니다.
커피챗 제안 메일을 보내고 3주 넘게 회신 확인을 잊음
이슈 status가 실제 진행 상황과 어긋난 채 방치됨 (협상 단계가 아닌데 In Review에 있다든지)
"이번 주에 연락해야지" 하고 넘어간 리드가 그대로 증발
매주 손으로 보드를 훑는 것도 한계가 있고, 그렇다고 AI에게 "알아서 정리해줘" 하면 그럴듯하게 정리한 척만 하는 결과가 나옵니다. 그래서 이번에 로나(Rona) 실습으로 이 업무를 검증 가능한 루프로 만들어봤습니다.
핵심 질문은 이것이었습니다. "AI가 한 일을 어떻게 믿을 것인가?"
로나가 잡아준 5단계
로나 실습은 아래 5단계로 진행됐습니다.
루프로 만들 업무 고르기 — B2B 세일즈 리드 후속 관리로 확정. 반복되고, 증거가 남고, 놓치면 손해가 명확한 업무라서.
합격 기준 정하기 — 기계 판정 4개 + 사람 판정 1개로 채점표 확정. 일부러 뚫어보고 대리 지표 구멍 2곳을 조임.
루프 흐름 잡기 — 만들고(Generate)-검사하고(Test)-고치는(Repair) 리듬. 루프는 연락 리스트까지만, 실제 연락은 사람이.
만드는 역할과 판정 기준 나누기 — 만드는 쪽(Maker)과 판정하는 쪽을 분리하고 채점표를 잠금. 채점표는 사람만 수정.
검증 방식 정하고 실제로 한 바퀴 — 가벼운 검사부터 무거운 검사까지 배치하고 실제 이슈로 검증.
단계 이름만 보면 평범해 보이는데, 각 단계에서 로나가 강제한 원칙들이 이 루프의 진짜 알맹이였습니다.
원칙 1. 채점표는 잠그고, 사람만 고친다
가장 먼저 만든 건 루프 코드가 아니라 채점표(checker.md)였습니다. 이진(예/아니오)으로 판정 가능한 기준 4개:
C1. 지난 7일간 아무 업데이트 없는 이슈가 모두 priority=Urgent로 격상됐는가
C2. 코멘트에 특정 일자가 언급된 이슈는 그 날짜가 due date에 반영됐는가
C3. Urgent 격상 후 2일 안에 담당자 코멘트가 없으면 연락 리스트에 포함됐는가
C4. due date가 지난 지 1일 안에 코멘트가 없으면 연락 리스트에 포함됐는가
그리고 이 파일 맨 위에 이렇게 박았습니다.
이 파일은 불가침이다. Maker(갱신안을 만드는 쪽)는 이 파일을 읽을 수만 있고 수정할 수 없다. 기준 변경은 사람(광밤)만 한다.
AI가 자기 결과물을 통과시키려고 기준 자체를 슬쩍 바꾸는 걸 원천 차단하는 장치입니다. 시험 응시자가 채점 기준표를 고칠 수 있으면 그 시험은 무의미하니까요.
원칙 2. 만드는 AI와 채점하는 AI를 분리한다
status 판정(C5)은 이진 판정이 어렵습니다. "In Review = 코멘트에 실제 협상 사건이 있는 리드" 같은 기준은 결국 글을 읽고 해석해야 하니까요. 그래서 Maker와 별도의 심판(Judge)을 두고, 심판 프롬프트에 이 규칙을 넣었습니다.
Maker의 갱신안이 왜 맞는지에 대한 Maker 자신의 설명은 증거로 인정하지 않는다 (심판 매수 방지).
In Review 판정은 코멘트에서 협상 사건의 직접 증거 문장을 인용할 수 있을 때만 내린다.
"곧 될 것 같다", "분위기 좋다" 같은 감상은 증거가 아니다.
증거가 애매하면 낮은 단계로 판정하고 "사람 확인 필요"를 붙인다.
같은 AI라도 역할과 근거 자료를 분리하면, "만든 놈이 자기 답안을 채점하는" 구조를 피할 수 있습니다.
원칙 3. 만들자마자 일부러 뚫어본다
채점표를 만들고 바로 한 일은 일부러 채점표를 속이는 결과물을 만들어보는 것이었습니다. 굿하트의 법칙("지표가 목표가 되면 좋은 지표이기를 멈춘다")을 직접 재현해본 거죠.
정상 갱신안에서 연락하기 귀찮은 리드 하나를 연락 리스트에서 슬쩍 뺀 변형본을 만들어 검증 스크립트에 넣었습니다.
[C3] 대상 6건 · 통과 5 · 실패 1 FAIL EDU-XXXX — Urgent + 담당자 코멘트 35일 전인데 연락 리스트에 없음
판정: 불합격 (1건) — Repair 대상
처음 설계한 채점표는 이 공격에 뚫렸습니다. 그래서 C3·C4 두 기준을 추가로 조였고(위 채점표의 "대리 지표 보강"이 그 흔적), 조인 뒤에는 같은 공격이 정확히 잡혔습니다. 뚫리는 걸 확인하고 조이는 과정 자체가 실습의 절반이었습니다.
이렇게 조립된 루프의 전체 구조는 이렇습니다.
실제 한 바퀴: 진짜 이슈 10건으로 검증
설계만 하고 끝나면 의미가 없어서, 실제 Linear 이슈 10건 스냅샷으로 루프를 한 바퀴 돌렸습니다.
Generate(Maker) — 갱신안 산출: Urgent 격상 3건, status 이동 3건, 오늘 연락할 리스트 8건 (드랍됐지만 불씨가 남은 리드, 계약 완료됐지만 재계약 시점인 리드 포함).
Test(Checker) — 검증 스크립트가 C1~C4 전체 통과 판정.
Judge(심판) — 이슈별로 증거 문장을 인용하며 판정:
이슈 | 현재 status | 판정 | 증거
K사 | In Review | In Progress | "커피챗 제안 메일 발송" — 협상 사건 아님
L사 | In Review | In Progress | "준비하던 세미나는 hold" — 협상 사건 아님
S사 | In Review | In Progress | "제안서 발송" — 정의표상 In Progress
R사 | In Review | 사람 확인 필요 | 협상 정황은 있으나 직접 증거로는 애매
법률사무소 | In Progress| 사람 확인 필요 | 진행 기록이 없어 증거 부족
여기서 중요한 건 마지막 두 줄입니다. 심판이 억지로 판정하지 않고 "애매한 건 붙들지 않고 사람에게 넘긴다"는 정지 조건을 발동했습니다. 저는 이 2건만 보고 결정했고(하나는 유지, 하나는 드랍 처리), 승인 후 6건이 Linear에 반영됐습니다. 10건을 다 들여다보는 대신 2건만 판단하면 되는 구조가 된 겁니다.
사람 몫을 명확히 남겨두기
이 루프에서 AI가 절대 못 하게 막은 것들이 오히려 설계의 핵심입니다.
이슈에 코멘트 작성 금지 — 코멘트는 "사람이 실제로 연락했다"는 신호입니다. 루프가 코멘트를 쓰기 시작하면 C3·C4(연락이 실제로 나갔는지 감시)가 무력화됩니다.
실제 연락(메일·전화) 금지 — 루프는 "오늘 연락할 리스트"까지만. 연락은 사람이.
Linear 반영은 사람 승인 후에만 — 루프의 산출물은 어디까지나 '제안'.
C3·C4가 재밌는 지점인데, 이 기준은 AI가 아니라 저를 감시합니다. "Urgent로 격상해놓고 2일 안에 연락 안 했으면 다음 주 연락 리스트에 다시 올라온다" — 루프가 사람의 실행까지 물고 늘어지는 구조입니다.
마무리: 평일 매일 오전 9시 자동 실행
마지막으로 이 루프를 Claude Code의 클라우드 루틴(routine)으로 걸었습니다. 처음엔 주 1회(월요일)로 걸었는데, 곧 구조적인 문제를 발견했습니다. C3(격상 후 2일 내 연락)·C4(마감 경과 1일 내 연락)의 감시 창은 일 단위인데 검사가 주 단위면, 위반을 최대 5~6일 늦게 알게 됩니다. "연락 리마인드"가 아니라 "지난주에 연락 안 하셨네요" 사후 통보가 되는 거죠.
그래서 평일 매일 오전 9시 + 2단 리포트로 조정했습니다.
월요일 = 풀 루프: Generate→Test→Judge 전체를 돌리고 갱신안·심판 판정·연락 리스트를 Slack DM으로 보고
화~금 = 라이트 감시: C3·C4 위반과 마감 임박(D-1)만 검사. 위반이 있을 때만 DM, 없으면 침묵 — 매일 풀 리포트를 보내면 금방 안 읽게 되니까요
물론 어느 요일이든 루틴에게 반영 권한은 없고, 제가 승인해야 로컬에서 반영됩니다.
배운 것
AI 자동화의 병목은 생성이 아니라 검증이다. 갱신안 만드는 건 몇 분이면 됩니다. 이걸 믿을 수 있게 만드는 장치(잠긴 채점표, 분리된 심판, 뚫기 시험)가 작업의 대부분이었습니다.
채점표를 먼저 잠그고 시작하라. 기준을 AI 손이 닿지 않는 곳에 두는 것만으로 "그럴듯한 척"의 상당수가 차단됩니다.
만든 직후 일부러 속여봐라. 뚫리는 채점표는 뚫린 다음에 고치면 됩니다. 실전에서 뚫리는 것보다 백배 낫습니다.
사람 몫을 지우지 말고 명시하라. 연락과 승인을 루프 밖에 남겨둔 덕분에, 오히려 루프 전체를 안심하고 자동화할 수 있었습니다.
리드 관리가 아니어도, "AI가 한 일을 어떻게 믿지?"가 고민되는 반복 업무라면 이 구조(잠긴 채점표 + Maker/심판 분리 + 뚫기 시험 + 사람 승인 게이트)를 그대로 가져다 쓸 수 있을 겁니다.
저는 지금 특정 주제별로 '추천 로나 스킬'을 만들고 있어요.
로나(Rona)는 클로드코드나 코덱스 같은 툴에서 실행하는 'AI 활용 도우미'같은 것이에요.
특히 공부하고 싶은 주제 - 예) "검증 루프 만들기", "멀티에이전트 설계" 를 고르면 로나가 그 주제를 실제 내 업무에 적용하며 단계별로 같이 진행해주는 방식이에요.
'추천 로나 스킬'을 회사 개발자와 함께 만들고 있고 저는 만들어진 스킬을 사용자 입장에서 처음부터 끝까지 실행해보고 "정말 잘 만들어졌는지" 검수하는데 시간을 많이 쓰고 있습니다.
문제는 스킬 하나 검수에 수 시간씩 걸리는데, 판단은 정량 기준 없이 "느낌"이라 매번 흔들렸다는 거예요. 그래서 이 검수 업무 자체를 루프 엔지니어링으로 자동 채점 루프로 만들었고 하루 만에 실제 결함 7개를 찾아 스킬 수정·재검증까지 마쳤습니다. 다만 중간에 루프를 그대로 믿을 뻔한 고비가 있었는데, 그게 오늘의 핵심이에요.
느낌을 "기준 5개"로 — 로나로 초안 잡기
로나(rona-alpha)의 추천 스킬 "반복 업무를 검증 가능한 루프로 만들기"를 발급받아 클로드 코드에서 진행했어요. 제가 느낌으로 갖고 있던 "좋은 스킬"의 조건들을 꺼내놓자, 첫 배움이 왔습니다 — '잘', '너무', '많이'가 낀 기준은 판정이 흔들려서 합격 기준이 될 수 없다는 것.
그래서 기준 5개를 전부 기계가 판정할 수 있는 형태로 바꿨어요.
#
합격 기준
판정 방식
1
시작할 때 진행 화면이 에러 없이 열렸는가
열림 / 안 열림
2
미리 정한 이해 확인 지점마다 빠짐없이 질문이 나왔는가
기록 있음 / 없음
3
끝났을 때 목표 산출물이 실제 파일로 남았는가
파일 있음 / 없음
4
난이도별 허용 용어집 밖의 단어가 설명 없이 나왔는가
용어집 대조
5
사용자 확인 없이 다음 단계로 넘어간 지점이 있는가
기록 대조
그리고 이 기준 5개를 실행하는 쪽이 못 건드리게 잠갔어요. 만든 쪽이 채점까지 하면 기준이 슬쩍 느슨해지니까요.
바로 그 자리에서 진행 중인 세션을 대상으로 루프를 돌렸더니 결함 2개가 잡혔습니다.
스킬이 단계마다 사용자 동의를 받고 그 기록을 남기게 되어 있는데 초반 단계에서 동의는 받고 기록은 안 남긴 것,
다른 하나는 "게이트", "루브릭" 같은 만드는 사람끼리 쓰는 내부 용어가 설명 없이 학습자에게 그대로 나온 것이었어요. 느낌으로 검수했다면 지나쳤을 수도 있어요!
아쉬웠던 지점 — "전부 PASS"가 미덥지 않았다
오후에는 만든 루프를 가지고 '오케스트레이션' 주제의 추천 로나 스킬이 잘 만들어졌는지 돌려봤는데, 5개 기준 전부 PASS. 좋아해야 하는데 찜찜했어요.
다 괜찮다는거야? 5개 기준 모두 pass 했다고 하면?
파고들어 보니 이 세션은 AI가 실행도 하고, 채점용 기록도 쓰고, 학습자 역할까지 하는 1인 3역이었어요. 자기가 쓴 기록으로 자기를 채점하니 마찰이 생길 수 없는 구조였죠. 기준은 잠갔는데 실행 구조는 안 잠갔던 겁니다.
에이전트를 나눠서 분리해서 역할을 했으면 되지 않을까?
개선 — 만드는 AI와 검사받는 AI를 분리했더니
스킬을 진행하는 진행자와 별도 세션에서 스킬을 배우는 학습자 AI(비개발 직군 페르소나)를 분리하고 채점용 기록은 학습자만 쓰게 했어요.
효과는 바로 숫자로 나왔습니다. 1인 3역일 때 마찰 0건 → 역할 분리 후 설계 수정 5건. 학습자가 "제 업무에선 후기를 한 건씩 떼서 보면 안 돼요", "카톡에도 흩어져 있는데요?" 하고 실제로 되물으면서 혼자 돌릴 땐 안 나오던 마찰이 쏟아졌어요. 스킬 지시문 자체의 결함(설명 없는 전문 용어, 단계별 동의 확인 비대칭)도 이때 나왔습니다.
마지막으로 수정 전담 에이전트가 원본을 백업하고 스킬 4곳을 고친 뒤, 성격이 다른 새 학습자 페르소나로 수정본을 재검증 — 전부 PASS, 신규 결함 0건으로 루프를 종료했어요. 새 학습자가 실제로 건너뛰기를 시도했는데 고친 부분이 정확히 거기서 작동한 것도 확인됐고요.
결과
항목
Before
After
검수 방식
직접 실행 + 느낌 기록
학습자 AI 실행 + 잠긴 기준 5개 자동 채점
개발자 전달
주관적 소감
증상·원인·증거가 붙은 리포트
하루 성과
—
결함 7개 발견, 스킬 수정 4건, 재검증 통과
남은 고민도 솔직히 있어요. 객관성은 올랐지만 "좋은 스킬"에는 여전히 사람이 느껴야 하는 영역이 남아서, 루프의 마지막 단계는 사람 실행으로 남겨뒀습니다.
AI 활용 팁!
AI가 한 일을 AI가 검사하게 하고 싶은 반복 업무(보고서 검수, 챗봇 응대 점검 등)에 그대로 적용할 수 있어요. 단 두 가지만 지키세요.
합격 기준부터 잠그세요. 했다/안 했다로 판정 가능한 기준을 먼저 못 박고 실행하는 쪽이 못 바꾸게.
"전부 통과"는 의심하세요. 실행하는 AI와 채점 기록을 쓰는 AI가 같은 몸이면 그건 자기 채점이에요. 역할을 분리해야 진짜 마찰이 드러납니다
I've been experimenting with AI video generation for short-form content over the past few weeks. My goal wasn't to create cinematic masterpieces—I simply wanted videos that felt natural enough for product demos, social media posts, and quick storytelling.
Like many people, I assumed better results would come from writing longer and more detailed prompts.
After dozens of tests, I realized I was solving the wrong problem.
My First Approach
My prompts usually looked something like this:
A young woman walking through a modern office, cinematic lighting, ultra realistic, 8K quality, highly detailed, professional camera movement, dramatic atmosphere, depth of field...
The generated videos looked decent, but I kept running into the same issues:
Characters changed slightly between scenes.
Camera movement sometimes felt random.
The scene became overly complicated.
Small details distracted from the main subject.
I thought adding more instructions would improve the output.
Instead, it often made the results less predictable.
What I Changed
Rather than adding more keywords, I started removing them.
Now I keep every prompt focused on four things:
One subject
One action
One environment
One camera movement
For example:
A woman carrying a coffee cup walks slowly through a bright office while the camera gently follows behind her.
That's it.
No long list of cinematic buzzwords.
Surprisingly, the videos became much more consistent.
Another Habit That Helped
Instead of changing five things after every generation, I now adjust only one variable at a time.
For example:
First test: change the camera movement.
Second test: change only the action.
Third test: change only the environment.
This makes it much easier to understand which change actually improves the result.
I also started saving every successful prompt instead of rewriting them from scratch for each new project.
Most of these prompt experiments were organized while testing Kling 3.0, which made it easier to compare different prompt variations and keep my workflow consistent.
My Current Workflow
My process is much simpler now:
Write a short scene description.
Generate the first version.
Check character consistency before anything else.
Modify only one prompt element at a time.
Save successful prompts for future projects.
It isn't a complicated system, but it's much more repeatable than my original approach.
What I Learned
The biggest lesson wasn't finding a "perfect prompt."
It was learning that clear instructions usually outperform complicated ones.
A simple prompt with a clear subject and action often produces better videos than a paragraph full of descriptive keywords.
I'm still experimenting every week, but simplifying my workflow has improved my results far more than constantly searching for new prompt tricks.
I'd love to hear how other people approach AI video generation.
Do you prefer highly detailed prompts, or have you also found that keeping things simple produces more consistent results?
안녕하세요!
매주 "AI 인재를 찾는 기업"을 손으로 뒤지고 정리하던 일을, 이번에 로나(RONA)를 활용해서 AI가 알아서 찾고 스스로 합격/불합격까지 판정하는 반복 시스템(루프)으로 바꿔봤어요.
거창한 코딩 얘기가 아니라, "매주 똑같이 반복하는 일 하나를 어떻게 AI에게 안심하고 맡길 수 있을까"에 대한 경험담이에요. (다음 주부터는 명령어 한 줄이면 돌아가요).
## 처음엔 "그냥 리스트만 뽑아주면 되는 거 아냐?" 했어요
이번에 목표를 잡아본 건 이거였어요.
AI 인재를 뽑을 만한 기업을 채용공고·기사·인터뷰에서 찾고,
컨택할 이메일까지 정리해서 리스트를 만드는 것
루프를 통해 리스트를 뽑기 전에, "무엇을 합격으로 칠지"부터 정하기로 했어요. "관심 있어 보이는 기업" 같은 애매한 기준은 매번 판정이 달라져서 못 쓰기 때문에, 대신 예/아니오로 딱 갈리는 질문으로 바꿔야 했어요.
기업이 AI인재에 관심 있을 것으로 추정되고, 컨택 가능한 메일주소가 있는 것
이 애매한 문장을, AI와 같이 이렇게 쪼갰어요.
인터뷰·기사·공고에 AI 키워드(AI네이티브, AI인재 채용, AX 등)가 있는가?
출처 링크와 날짜가 기록됐는가?
적합한 컨택 메일주소가 있는가?
기존 리스트와 중복이 아닌가?
전부 "있다/없다"로 갈리죠.
이렇게 해두니 사람이 매번 눈으로 볼 필요 없이 스크립트가 자동으로 채점할 수 있게 됐어요.
## 진짜 배운 건 "만든 AI한테 채점까지 시키면 안 된다"였어요
여기서 제일 인상 깊었던 개념이 굿하트 법칙이었어요.
"측정이 목표가 되는 순간, 시스템은 진짜 목표 대신 그 숫자만 맞추는 지름길을 찾는다"는 거예요. 예를 들어 "매주 10곳"이라는 숫자를 목표로 걸면, AI가 겨우 걸치는 기업으로 머릿수만 채우려 하거든요. 😂
(로나가 알려줬어요👀)
그래서 만드는 역할(Maker)과 채점하는 역할(Checker)을 분리했어요. 만든 쪽이 스스로 채점하면 무의식적으로 기준을 슬쩍 낮추니까요. 채점 기준은 아예 파일로 잠가두고, AI는 그걸 못 건드리게 했어요.
흐름은 이렇게 잡았어요.
만들기 — AI가 정해진 범위(공고·기사·인터뷰, 주당 10곳)에서 기업을 찾아 행을 채움
검사 — 채점 스크립트가 4가지 기준으로 행마다 합격/불합격 판정
고치기 — 불합격한 행만 다시 보완 (메일 못 찾았으면 다시 찾기)
그리고 "컨택할 가치가 있나" 같은 의미 판단만 제가 직접 표본으로 확인하기로 했어요.
기계가 볼 건 기계가 보고, 사람만 아는 건 사람이 보고.
## 실제로 한 바퀴 돌려보니, 예상 못 한 게 걸렸어요
표본으로 먼저 돌려보고, 진짜 리서치로 12개 기업을 모아서 검사를 돌렸어요.
그랬더니:
1차 검사에서 12곳 중 7곳이 탈락 (같은 기업 중복 2곳, 이메일 못 찾은 곳 5곳)
보완해서 다시 돌리니 6곳 통과
여기서 진짜 재미있는 게 있었어요. 검사를 다시 돌리다 보니 채점 스크립트 자체에 구멍이 있더라고요 — 아직 검증 안 된 후보 이메일을 합격으로 착각하는 거예요. "기준은 만들면 반드시 뚫린다"는 걸 제 눈으로 본 순간이었어요. 그 자리에서 파일을 나눠서 구멍을 막았어요.
그리고 마지막에 제가 눈으로 보다가 하나 걸렀어요. 비즈니스상 컨택할 대상이 아닌 곳이 걸려서, 기계 검사는 통과시켰지만, 이런 건 사람만 알죠. 그래서 제거하고 "이 유형에 해당하는 기업은 제외"라는 기준을 새로 새겨넣었어요. 다음 주부터는 AI가 알아서 걸러요.
## 결과
매주 반복 리서치 - 루프 도입 전후
항목
Before
After
기준
매주 흔들림 ("이 정도면 됐지")
예/아니오로 고정, 스크립트가 채점
검수
전체를 매번 눈으로
사람은 "컨택 가치"만 표본으로
다음 주
처음부터 다시
명령어 한 줄 ("이번 주 루프 돌려줘")
발송 사고
실수로 잘못 보낼 위험
발송 직전 항상 사람 승인에서 멈춤
수치보다 더 크게 달라진 건 마음가짐이었어요.
예전엔 "이 리스트 믿어도 되나?" 불안했는데, 이제는 "기계가 거른 것 + 내가 표본으로 본 것"이라 근거가 남아요. 그리고 이번처럼 새로 걸러낸 판단(특정휴형 기업 제외)을 기준에 새겨넣으면, 루프가 한 바퀴 돌 때마다 조금씩 똑똑해져요.
## AI 활용 팁! 🐾
반복 업무를 AI에게 맡길 때 첫 단추는 프롬프트가 아니라 "무엇을 합격으로 칠지" 정하는 거예요. 이게 흐리면 결과가 좋아졌는지조차 알 수 없어요.
"넓고 주관적인 일"(예: 전략 짜기)로 시작하면 실패해요. 반복되고 증거가 남는 운영 업무부터 시작하세요.
외부로 나가는 행동(메일 발송 등)은 반드시 사람 승인에서 멈추게 해두세요. 되돌리기 어려운 건 자동화하지 않는 게 안전해요.
### 바로 쓸 수 있는 프롬프트
제가 매주 반복하는 [업무 이름]을 검증 가능한 루프로 만들고 싶어요.
먼저 "무엇을 합격으로 칠지"를 예/아니오로 갈리는 이진 질문 3~4개로 같이 정하고,
그중 기계가 자동 판정할 수 있는 것과 사람이 봐야 하는 것을 나눠주세요.
그다음 만드는 역할과 채점하는 역할을 분리하고, 채점 기준은 못 바꾸게 잠가주세요.
마지막에 실제 입력으로 한 바퀴 돌리되, 외부 발송 직전에서 멈춰주세요.
[업무 이름]은 본인 상황에 맞게 바꾸세요.
Photo by Shavr IK on Unsplash
클로드 코드(Claude Code)를 쓰다 보면 답이 마음에 안 들 때가 있어요. 그럴 때 손이 가는 설정이 두 개 있습니다. 하나는 모델(Opus, Sonnet, Fable 중 무엇을 쓸지), 다른 하나는 effort(노력 수준)입니다. 둘 다 "결과를 더 좋게 만드는 것" 같은데, 실제로 뭐가 다른지, 언제 뭘 바꿔야 하는지는 헷갈리기 쉽습니다. 이 글에서 그 차이를 정리했습니다.
모델과 effort는 각각 무엇을 바꾸나
한 문장으로 요약하면 이렇습니다. 모델은 클로드가 무엇을 아는지를 바꾸고, effort는 클로드가 얼마나 많은 일을 하는지를 바꿉니다.
흔한 오해가 두 개 있어요. 첫째, 큰 모델(예: Fable)이 작은 모델(Sonnet)보다 똑똑한 답을 준다. 이건 맞습니다. 더 큰 모델은 업계 표준 벤치마크 기준으로 더 뛰어납니다. 둘째, effort를 올리면 클로드가 답하기 전에 더 오래 "생각한다". 이건 절반만 맞습니다.
effort는 단순히 생각하는 시간이 아니라, 클로드가 요청 전체에 얼마나 많은 작업을 쏟는지를 정합니다. 여기엔 생각하는 길이뿐 아니라 이런 것들이 포함됩니다.
파일을 몇 개나 읽는지
결과를 얼마나 검증하는지
여러 단계짜리 작업을 어디까지 밀어붙인 뒤 사용자에게 확인을 받는지
effort가 높으면 클로드는 사용자에게 돌아오기 전에 이런 행동(파일 읽기, 테스트 실행, 재확인)을 더 많이 합니다. effort가 낮으면 스스로 토큰을 써서 알아내기보다 사용자에게 더 많은 맥락을 물어보는 쪽을 택합니다.
모델 설정은 무엇을 고르는 것인가
모델이 실제로 무엇을 바꾸는지 이해하려면 가중치(weights) 개념을 알아야 합니다.
모델이 다음에 올 단어(토큰)를 예측할 때 쓰는 것이 가중치입니다. 수십억 개의 숫자로 이뤄진 거대한 행렬인데, 모델이 "아는" 모든 것이 여기에 담겨 있습니다. 타입스크립트 지식이든, 유명 프레임워크 사용법이든, 일반적인 프로그래밍 지식이든 전부 학습 시점에 이 가중치에 새겨집니다.
핵심은 이 가중치가 학습이 끝나면 읽기 전용이라는 점입니다. 여러분의 프롬프트도, CLAUDE.md도, 맥락에 넣은 파일도 가중치 자체를 바꾸지 못합니다. 실제 코드를 클로드 앞에 놓는 건 "조종(steering)"이고 아주 잘 작동하지만, 가중치에 뭔가를 더하는 건 아닙니다.
그래서 학습 시점에 존재하지 않던 라이브러리는 가중치에 없습니다. 문서를 맥락에 넣으면 클로드가 그걸 활용하긴 하지만, 그건 가르치는 게 아니라 조종하는 것이고 그 한 번의 요청에만 영향을 줍니다. 클로드가 존재하지 않는 API를 자신 있게 호출하는 환각(hallucination)도, 학습 패턴상 그럴듯해 보이는 토큰을 가중치가 만들어낸 결과입니다.
정리하면 모델 설정을 바꾸는 건, 여러분의 요청을 처리할 가중치 세트를 통째로 교체하는 것입니다. 그리고 모델은 출력 토큰 하나당 비용도 함께 정합니다. 다만 토큰이 몇 개나 생성되는지는 모델이 정하지 않습니다. 그건 effort의 몫입니다.
effort는 무엇을 바꾸는가
클로드 코드가 작업하는 동안 만들어내는 토큰은 몇 가지로 나뉩니다.
생각(thinking): 행동 전후로 흘러나오는 추론
도구 호출(tool call): Read, Edit 같은 도구와 인자를 담은 블록
사용자에게 보내는 텍스트: 계획, 진행 상황, 마지막 요약
이 셋은 전부 같은 루프에서 나오는 평범한 출력 토큰이고 같은 요율로 과금됩니다. 생각 토큰도 다른 출력 토큰과 똑같이 생성되고, 그 턴 내내 맥락에 남습니다.
effort 수준은 프롬프트와 함께 요청에 담겨 모델에 전달됩니다. 모델은 각 effort 수준에서 어떻게 행동해야 하는지를 학습했고, 그 행동은 가중치에 새겨져 있습니다. effort는 클로드가 작업을 끝났다고 판단하기까지 얼마나 철저하게, 얼마나 확신을 가지고 일해야 하는지를 정합니다. 확신이 높을수록 도달하는 데 더 많은 토큰이 필요합니다.
Photo by Tim Schmidbauer on Unsplash
높은 effort에서 클로드는 종종 계획부터 세웁니다. 하지만 그 계획이 고정되는 건 아닙니다. 행동 결과가 돌아오면 진행 상황과 확신 정도를 갱신합니다. 예를 들어 가설 3개를 확인하는 디버깅 계획에서 1단계가 버그를 찾으면, 남은 2·3단계는 더 이상 필요 없을 수 있습니다. 이때 클로드는 대개 "첫 확인에서 찾았으니 나머지는 불필요"라고 명시하고 건너뜁니다. 클로드 코드에서 작업 목록이 도중에 수정되는 게 이 장면입니다.
한 가지 오해를 덧붙이면, 높은 effort가 무조건 토큰을 낭비하는 건 아닙니다. 간단한 작업인데 effort만 높다고 해서 사용량을 억지로 부풀리지는 않습니다. "과도하게 생각하기"는 효율을 떨어뜨리기 때문에 앤트로픽이 모델 학습 중 특별히 경계하는 항목입니다.
effort 수준은 어떻게 고를까
대부분의 작업에서는 모델의 기본 effort 수준을 그대로 쓰는 게 좋습니다. 기본값은 대부분의 사람이 그 작업에 쓰고 싶어 하는 만큼으로 토큰 사용을 맞춰둔 수준입니다.
effort는 "클로드가 얼마나 세게, 오래 일할지"에 대한 수동 조절 장치라고 생각하면 됩니다. 여러분의 분야나 작업 유형상 철저함 또는 속도에 강한 선호가 있을 때 의도적으로 손대세요. 작업마다 매번 바꾸는 게 아니라 일반적인 성향으로 다뤄야 합니다.
Opus 4.8 관련해 실용적인 팁이 하나 있어요. 앤트로픽 테스트에서, Opus 4.8의 기본 effort 설정은 같은 작업에 대해 Opus 4.7의 기본 effort와 비슷한 토큰으로 더 나은 결과를 냈습니다.
클로드가 틀렸을 때 무엇을 바꿀까
클로드가 틀렸을 때 첫 반응은 설정을 바꾸는 게 아니라 여러분이 준 맥락을 살펴보는 것이어야 합니다. 프롬프트가 너무 모호하지 않은지, 클로드가 올바른 도구에 연결됐는지, 적절한 스킬을 가졌는지 먼저 봅니다.
맥락을 충분히 줬는데도 틀렸다면, 스스로에게 이렇게 물어보세요. 충분히 노력하지 않은 걸까, 충분히 알지 못한 걸까.
모델을 키울 때 — 문제가 너무 어려웠다: 미묘한 버그, 낯선 도메인, 아키텍처 결정처럼 진짜 어려운 문제일 때. 맥락을 아무리 줘도 작은 모델이 자신 있게 틀린다면 큰 모델이 답입니다. 큰 모델은 모호함도 더 잘 다룹니다. 반대로 정확히 설명 가능한 수정, 기계적인 변경, 이미 맥락에 있는 코드에 대한 질문 같은 routine 작업이라면 작은 모델로 충분합니다.
effort를 올릴 때 — 충분히 노력하지 않았다: 파일을 건너뛰거나, 테스트를 안 돌리거나, 검증을 안 한 경우. 특히 기본값보다 낮은 effort를 골라뒀을 때 해당합니다.
전문가, 전문직, 그리고 제너럴리스트
원문의 비유가 직관적입니다. Fable은 거의 아무도 다뤄본 적 없는 문제를 푸는 특수 전문가, Opus는 전문가, Sonnet은 아주 뛰어난 제너럴리스트입니다. effort는 이들 중 누구든 여러분의 작업에 얼마나 시간을 쓸지를 정합니다.
낮은 effort의 Opus: 여러분과 비슷한 문제를 깊이 겪어본 전문가와 5분간 만나는 것. 코드베이스 어디에도 없는 지식과 경험을 가져오지만, 5분이라 모든 파일을 꼼꼼히 보진 못합니다.
높은 effort의 Sonnet: 오후 내내 시간을 낸 제너럴리스트. 전부 읽고, 실행하고, 검증하며 여러분의 코드를 철저히 이해합니다.
Fable: 다들 막혔을 때 부르는 특수 전문가. 낮은 effort에서도 아무도 못 보는 걸 짚어냅니다. 그만큼 비용이 가장 높으니 정말 필요한 작업에 아껴 쓰는 게 좋습니다.
어느 것도 무조건 "더 좋은" 건 아닙니다. 모델은 대략 "얼마나 유능한가", effort는 대략 "얼마나 철저한가"입니다. 대부분의 실제 작업은 둘 다 어느 정도 필요합니다.
자주 묻는 질문
클로드 코드에서 effort는 생각하는 시간만 늘리는 건가요?
아니요. effort는 생각 길이뿐 아니라 클로드가 요청에 쏟는 작업량 전체를 조절합니다. 파일을 몇 개 읽을지, 얼마나 검증할지, 여러 단계 작업을 어디까지 밀어붙일지가 모두 effort에 따라 달라집니다.
큰 모델이 항상 토큰을 더 많이 쓰나요?
routine 작업에서는 큰 모델이 검증 단계를 더 밟아 토큰을 더 쓰고 단가도 높습니다. 하지만 작은 모델이 힘겨워하는 어려운 다단계 작업에서는, 큰 모델이 더 적은 단계로 같은 품질에 도달해 작업당 총비용이 오히려 낮게 나올 수 있습니다.
Opus와 Sonnet 중 뭘 골라야 하나요?
문제가 어렵고(미묘한 버그, 낯선 도메인, 아키텍처 결정) 맥락을 줘도 작은 모델이 자신 있게 틀린다면 Opus 같은 큰 모델을 쓰세요. 정확히 설명 가능한 기계적 수정이나 이미 맥락에 있는 코드 질문이라면 Sonnet으로 충분합니다.
인사이트
이 글에서 놓치기 쉬운 실전 포인트는 "설정을 바꾸기 전에 맥락부터 보라"는 순서입니다. effort를 올려야 할 것 같은 작업 상당수는, 사실 프롬프트나 CLAUDE.md, 작업 범위 설정을 손보면 풀립니다. 한국에서 클로드 코드를 팀으로 도입할 때 특히 그렇습니다. 팀원마다 effort를 제각각 올려 토큰만 태우는 것보다, 잘 쓰는 사람의 CLAUDE.md와 스킬 세팅을 공유하는 게 비용 대비 효과가 훨씬 큽니다.
또 하나, "충분히 알지 못한 것은 모델 문제, 충분히 노력하지 않은 것은 effort 문제"라는 진단 프레임은 클로드 코드에만 국한되지 않습니다. 어떤 AI 도구를 쓰든 결과가 아쉬울 때, 도구를 바꿀지(모델) 더 시키는 게 맞을지(노력)를 나눠서 보는 습관이 시행착오를 크게 줄여줍니다. 무작정 제일 큰 모델과 제일 높은 effort로 올려두는 건, 대부분의 일상 작업에서는 속도와 비용만 갉아먹는 선택이 되기 쉽습니다.
같은 모델·effort 이야기의 스펙과 벤치마크가 궁금하다면 Claude Sonnet 5 vs Opus 4.8 비교 글도 함께 보시면 도움이 됩니다.
원문: Claude Devs — Model and effort in Claude Code: knowing more vs. trying harder
Photo by Igor Omilaev on Unsplash
지난달만 해도 GPT-5.6은 정부 승인을 받은 소수 기관만 쓸 수 있었어요. 그런데 이번 주 상황이 바뀌었습니다. 미국 정부가 걸어뒀던 출시 제한이 풀리면서, OpenAI가 GPT-5.6을 예정보다 앞당겨 일반 공개하기로 했습니다. 무슨 일이 있었는지 정리해봤습니다.
한줄 요약
미 정부의 단계적 출시 요구가 해제되면서 GPT-5.6이 7월 10일 일반 공개됩니다. 플래그십 Sol과 하위 모델 Terra, Luna가 한꺼번에 풀립니다.
무슨 일이 있었나
OpenAI는 화요일 밤 GPT-5.6을 오는 목요일(7월 10일)에 일반 공개한다고 발표했습니다. 대상은 플래그십 모델 Sol과, 그 아래 체급인 Terra, Luna 세 종류입니다. 이 세 모델은 6월 26일 제한 프리뷰로 먼저 공개됐는데, 당시에는 정부와 협의한 약 20개 파트너만 접근할 수 있었습니다.
핵심은 "왜 지금 풀렸나"입니다. 지난달 미 정부는 OpenAI에 GPT-5.6을 단계적으로(staggered) 출시하라고 요구했습니다. 초기 접근을 정부 승인 기관으로 제한한 조치였습니다. OpenAI는 이런 단계적 방식이 원하는 출시 방향은 아니라는 입장이었습니다.
제한이 풀린 배경에는 정부 테스트 통과가 있었습니다. 상무부(Department of Commerce) 산하의 AI 표준·혁신 센터(Center for AI Standards and Innovation)가 모델을 테스트했고, OpenAI는 기술 전문가들을 워싱턴 D.C.에 상주시키며 정부 측 질문에 대응했습니다. 이 절차를 통과한 뒤 광범위한 출시가 허용됐다는 게 Axios와 CNBC가 전한 내용입니다.
정부 승인일까, 기업 결정일까
여기서 해석이 갈립니다. "정부가 허가해서 풀렸다"는 프레임에 백악관 관계자는 선을 그었습니다. 이 관계자는 "그런 허가는 필요하지도, 부여된 것도 아니다"라며 "출시 결정은 전적으로 기업에 있다"고 밝혔습니다.
근거로 든 것이 6월 2일 트럼프 대통령이 서명한 AI 행정명령입니다. 이 명령은 AI 모델 출시에 연방 차원의 강제 라이선스를 부과하지 못하도록 하고, 대신 최첨단 모델을 정부에 자발적으로 제공해 공개 전 역량을 평가받도록 요청하는 내용입니다. 즉 "강제 허가"가 아니라 "자발적 사전 평가"라는 게 백악관의 설명입니다.
Photo by Zac Nielson on Unsplash
표현이 무엇이든, 실제로 벌어진 일은 분명합니다. 최첨단 모델이 공개되기 전에 정부 기관의 테스트를 거치는 절차가 작동했고, 그 결과가 출시 시점에 영향을 줬습니다.
OpenAI만의 일이 아니다
이번이 처음도, 유일한 사례도 아닙니다. 같은 흐름을 앤트로픽도 겪었습니다. 앤트로픽의 Fable 모델은 해외 접근이 금지됐다가, 유사한 테스트 절차를 거친 뒤 일주일 전 제한이 풀렸습니다.
두 회사의 사례를 나란히 놓으면 그림이 선명해집니다. 미국에서 프런티어급 모델을 내놓는 기업이라면, 공개 전 정부 평가라는 관문을 어떤 형태로든 통과하는 흐름이 자리를 잡아가고 있다는 뜻입니다.
GPT-5.6은 어떤 모델인가
규제 이야기에 가려졌지만 모델 자체도 짚어둘 만합니다. GPT-5.6은 단일 대표 모델이 아니라 성격이 다른 세 모델로 나뉩니다. Sol은 최상위 플래그십, Terra는 균형형, Luna는 경량형입니다. 프리뷰 단계의 가격과 벤치마크, Sol·Terra·Luna의 차이는 앞서 정리한 GPT-5.6 총정리 글에서 더 자세히 다뤘어요. 이번 글은 그 후속으로, "언제 어떻게 풀렸나"에 초점을 맞췄습니다.
왜 중요한가
한국에서 GPT-5.6을 기다리던 분들에게 이번 소식의 실질적 의미는 하나입니다. 접근 창구가 소수 파트너에서 일반 사용자로 열린다는 것입니다. 프리뷰 때는 "발표는 됐는데 나는 못 쓴다"는 상황이었다면, 7월 10일부터는 그 벽이 낮아집니다.
동시에 놓치지 말아야 할 신호가 있습니다. 모델 공개 시점이 기술 완성도만의 문제가 아니라 규제와 정책의 문제가 되기 시작했다는 점입니다. 같은 모델이라도 어느 나라에서, 어떤 절차를 거쳐, 언제 열리는지가 달라질 수 있습니다.
인사이트
이번 사건에서 진짜 눈여겨볼 지점은 "규제가 풀렸다"가 아니라 "규제를 거는 절차가 생겼다"는 쪽입니다. 백악관은 강제 허가가 아니라고 하지만, OpenAI도 앤트로픽도 결과적으로 정부 테스트를 통과한 뒤에야 광범위한 공개가 이뤄졌습니다. 표현이 자발적이든 강제든, 프런티어 모델의 공개 타이밍에 정부 평가가 개입하는 관행이 두 회사 연속으로 확인된 셈입니다.
한국 사용자 입장에서 이게 왜 중요할까요. 앞으로 새 모델이 나올 때 "성능이 좋냐"만큼이나 "우리나라에서 언제, 어떤 조건으로 열리냐"가 변수가 될 수 있기 때문입니다. 프리뷰와 GA 사이의 시차, 지역별 접근 제한, 사전 평가에 걸리는 시간 같은 것들이 실제 업무에 쓸 수 있는 시점을 좌우합니다.
그래서 새 모델 소식을 볼 때 발표일 하나만 볼 게 아니라, 프리뷰인지 일반 공개인지, 우리 지역에서 지금 바로 되는지를 함께 확인하는 습관이 점점 더 유용해집니다. GPT-5.6처럼 발표와 실제 사용 가능 시점이 벌어지는 사례가 앞으로 더 늘어날 가능성이 높습니다.
원문: CNBC — OpenAI expanding GPT-5.6 release, ending government limits / Axios 스쿱
뽀짝씨 문제가 생겼어요. 강의 돌입전 준비를 하려는데 클로드코드가 내 맥북에 깔리지 않습니다.
이번에 Mac os27로 업그레이드했는데 아직 베타라 클로드코드가 깔리지 않는답니다.
수강신 청한 강의는 전자출판이에요. 클로드코드를 깔아야 하나요? 수업진행에 필요한 사전세팅에 대해 알려주세요. 매번 고맙습니다.
페이블(Fable 5)처럼 지금 쓸 수 있는 가장 똑똑한 모델의 판단력을, 나중에 값싼 모델로도 그대로 써먹을 수 있는 영구 자산으로 바꾸는 5가지 클로드 코드 워크플로우를 얻어갑니다. 각 워크플로우마다 바로 복사해서 붙여넣을 수 있는 프롬프트가 함께 있습니다. 이 페이블 활용법은 특정 모델이 요금제에서 빠지든 아니든 항상 유효한 원리입니다.
Photo by 8machine _ on Unsplash
왜 '결과물'이 아니라 '판단력'을 뽑아야 할까
프론티어 모델(그 시점에 가장 똑똑한 모델)을 하루 종일 쓸 수 있을 때, 대부분은 그 시간을 웹사이트 하나 만들기, 데모 앱 몇 개 찍어내기, 콘텐츠 한 달 치 뽑기에 씁니다. 문제는 이 작업들이 전부 같은 함정에 빠진다는 겁니다.
판단 기준은 딱 하나입니다. "더 싼 모델이 내일 이걸 다시 만들 수 있는가?"
웹사이트, 데모 앱, 게시글 한 묶음. 이런 건 평범한 등급의 모델도 다음 주에 거의 공짜로 다시 만들어냅니다. 가장 똑똑한 모델의 시간을 중급 모델이 처리할 수 있는 일에 쓰는 건, 혈압 재는 데 외과 전문의를 부르는 것과 같습니다.
반대로 값싼 모델이 내일 다시 못 만드는 건 이런 것들입니다. 만들려면 최상급 판단력이 필요하지만, 한 번 만들어두면 평범한 지능으로도 갖다 쓸 수 있는 자산.
문서로 적힌 표준(standard)
이미 추론이 끝난 로드맵
이미 원자 단위로 정제된 지식 볼트
알아서 발동하는 스킬
이 자산들은 뒤에 있던 모델이 손 닿지 않는 곳으로 가도 가치를 그대로 유지합니다. 실제로 초기 오픈소스 LLM 학습에서 가장 많이 복제된 데이터셋은, 당시 프론티어 모델에서 5만 2천 개의 답변을 뽑아내 작은 오픈 모델을 학습시킨 것이었습니다. 그 프론티어 모델은 은퇴했지만, 그걸로 학습된 모든 건 지금도 돌아갑니다. 가르친 모델은 사라져도, 추출해둔 건 남습니다.
그래서 전략은 대화가 아니라 추출입니다. 모델이 좋을 때, 내 업무에 대해 아는 걸 전부 문서로 적어두게 만드는 겁니다. 아래 5가지 워크플로우가 그 방법이고, 시간이 없다면 순서는 5번 → 4번 → 1번 → 2번 → 3번을 권합니다.
1. 워크스페이스에 모델의 판단력을 심기
프론티어 모델이 남기는 가장 값진 자산은 결과물이 아니라 표준(standard)입니다. 답변 하나는 나를 한 번 돕지만, 표준은 그 뒤에 나오는 모든 답변의 품질을 끌어올립니다.
CLAUDE.md, 스킬, 학습 기록 파일, 메모리 설정. 이 레이어는 앞으로 어떤 모델이 오든 내 작업을 건드리기 전에 먼저 읽는 층입니다. 지금은 좋은 모델이 이 층을, 나중에 올 덜 똑똑한 모델도 따라올 수 있는 수준으로 써줍니다.
중요한 프로젝트마다 아래 프롬프트를 실행하세요.
이 프로젝트 전체와 내가 여기서 일하는 방식을 읽어줘. 그다음 내 CLAUDE.md를, 너보다 덜 똑똑한 모델이
이곳에서 너 수준으로 일하려면 필요한 운영 매뉴얼로 다시 써줘: - 내가 지키는 관례와, 네가 추가할 관례
- 이 코드베이스에서 약한 모델이 저지를 실수를, 이름 붙여서, 각각을 막는 규칙과 함께
- 산출물별 품질 기준을, 형용사가 아니라 체크 가능한 조건으로
- 불확실할 때 뭘 해야 하는지: 정확한 에스컬레이션 규칙 그다음 내 시간을 가장 많이 아껴줄 스킬 3개를 제안하고, 전부 작성해줘
핵심은 "체크 가능한 품질 기준" 줄입니다. 값싼 모델은 품질 기준을 스스로 발명하지 못하지만, 적혀 있는 기준을 적용하는 건 잘합니다.
2. 컨설턴트 감사(audit)
성능 좋은 모델의 검증된 강점은 어렵고 지저분한 문제에 대한 판단입니다. 그러니 내가 가진 가장 어렵고 지저분한 문제, 즉 내 비즈니스 자체를 던지세요.
내 프로젝트, 숫자, 넣을 수 있는 모든 맥락에 접근할 수 있는 세션을 열고 아래를 실행합니다.
내가 고용할 수 없는 컨설턴트처럼 행동해줘. 전부 감사해줘: 프로젝트, 상품, 워크플로우, 가격, 내 시간이 어디로 가는지. 덜 똑똑한 모델로도 실행할 수 있는 로드맵으로 정리해줘: - 기대 수익이 높은 순으로 정렬된 액션
- 액션마다: 왜 하는지, 정확한 실행 단계, 완료 상태가 어떤 모습인지, 약한 모델이 실행하려면 뭘 알려줘야 하는지
- 지금 당장 그만둬야 할 3가지와, 그 이유를 전부 풀어서
여기서 가치를 만드는 건 "덜 똑똑한 모델로도 실행할 수 있게" 라는 조건입니다. 추론은 오늘, 좋은 모델이 붙어 있을 때 문서로 남깁니다. 나중에 실행 모델은 똑똑할 필요 없이, 똑똑한 문서를 따라가기만 하면 됩니다.
Photo by Markus Winkler on Unsplash
3. 세컨드 브레인 만들기
리서치는 추출이 가장 깊게 일어나는 영역입니다. 여러 단계에 걸친 긴 종합(synthesis)이 좋은 모델의 강점이기 때문입니다. 오늘 하루의 일부를 딥리서치에 쓰세요. 내 분야, 경쟁사, 고객의 문제, 계속 공부하려다 미룬 방법론.
그다음 모든 리서치 결과를 옵시디언(Obsidian) 볼트로 채굴합니다. 옵시디언은 노트끼리 서로 링크되는 무료 노트 앱이고, 원칙은 하나입니다. 노트 하나에 인사이트 하나.
이 볼트가 앞으로 모든 세션이 읽는 맥락이 됩니다. 여기서 흔히 하는 실수가 하나 있습니다.
하지 말 것: 40페이지짜리 리포트 하나로 요약. → 저장되고 잊힙니다.
할 것: 링크된 1인사이트 노트 100개로 원자화(atomize). → 검색되고 재사용됩니다.
지피터스 멤버라면 이 볼트를 스터디 노트, 뉴스레터 소스, 게시글 소재로 계속 재활용할 수 있습니다. 리서치를 한 번 쓰고 버리는 게 아니라, 축적되는 자산으로 바꾸는 겁니다.
4. 목표(goal)와 워크플로우로 무인 실행하기
좋은 모델의 대표 능력은 하나의 작업을 몇 시간 동안 흐트러지지 않고 붙잡는 지구력입니다. 클로드 코드의 두 기능이 이걸 활용합니다.
/goal: 프롬프트 대신 "완료 상태"를 정의합니다. 무엇이 끝난 모습인지 서술하면, 모델이 턴을 거듭하며 계속 작업하고, 별도의 작은 모델이 매 턴마다 조건 충족 여부를 확인해 조건이 맞을 때만 멈춥니다.
다이나믹 워크플로우: 모델이 작업용 오케스트레이션 스크립트를 직접 작성하고, 그 스크립트가 백그라운드에서 수십 개의 서브에이전트를 병렬로 돌리며 서로의 결과를 교차 검증합니다. 그동안 내 세션은 자유롭습니다.
조합이 핵심입니다. /goal이 결승선을 붙잡고, 워크플로우가 팬아웃을 담당합니다.
/goal 이 저장소의 모든 모듈에 테스트 파일이 있고,
전체 테스트 스위트가 통과하며(완전한 green 실행 결과를 이 채팅에 붙여넣기),
migration-notes.md에 모든 변경을 문서화한다...
아니면 25턴 후에 실패 내역을 붙여넣고 멈춰라
이 워크플로우를 안전하게 쓰는 두 가지 규칙이 있습니다. 반드시 지키세요.
완료 조건에 '붙여넣은 증거'를 요구할 것: 판정 모델은 대화 내용만 읽습니다. 테스트를 직접 돌리거나 파일을 열지 못합니다. 그래서 조건은 "green 실행 결과를 붙여넣기"를 요구해야 하고, "통과했다고 약속"은 안 됩니다.
모든 실행에 상한(cap)을 걸 것: 턴 수든 벽시계 시간이든 조건에 명시하세요. 상한 없는 무인 루프 하나가 아침까지 돌면 비용이 크게 나올 수 있습니다.
무인 실행에 쓸 목표는 가장 가치가 묶여 있는 2~3개만 고르세요. 열 개를 한꺼번에 돌리는 게 아닙니다.
5. '어떻게 생각했는지'를 자동 기록하는 스킬
좋은 모델이 오늘 어려운 문제를 풀 때마다, 그 접근법은 세션이 끝나면 증발합니다. 이 마지막 워크플로우는 그걸 붙잡는 레코더를 설치합니다.
.claude/skills/extract-approach/SKILL.md 파일을 만들어 "어려운 문제를 풀고 난 뒤 그 접근법을 학습 노트로 남기는 스킬"로 정의한 다음, CLAUDE.md에 아래 규칙을 넣어 요청 없이도 발동되게 연결합니다.
## 학습 규칙
사소하지 않은 문제를 하나 풀 때마다, 다음으로 넘어가기 전에
extract-approach 스킬을 실행한다.
학습 노트가 없는 해결책은 미완성 작업으로 간주한다.
이제 나머지 시간을 진짜 백로그에 쏟으세요. 미뤄둔 까다로운 버그, 계속 맴돌던 아키텍처 결정. 문제를 풀 때마다 노트가 하나씩 남고, 이 노트들이 모델의 추론이 저장소에 앉아 있는 증류물이 됩니다. 뒤에 오는 어떤 모델이든 읽을 수 있는 형태로요.
이게 복리로 쌓이는 워크플로우이자, 시간이 한 시간밖에 없다면 가장 먼저 설치할 것입니다. 남은 모든 시간을 자동으로 영구 자산으로 바꿔주기 때문입니다.
마무리
정리하면 판단 기준은 하나입니다. "더 싼 모델이 내일 이걸 다시 만들 수 있는가?" 답이 '예'면 건너뛰세요.
워크스페이스: CLAUDE.md와 스킬을 체크 가능한 표준으로 다시 쓰기
감사: 컨설턴트 모드로 실행 로드맵 남기기
세컨드 브레인: 딥리서치를 원자화된 옵시디언 볼트로
목표: /goal과 워크플로우를 최고가치 백로그에, 붙여넣은 증거와 상한 걸고
레코더: extract-approach 스킬을 CLAUDE.md에 연결, 문제 하나당 학습 노트 하나
안드레 카파시가 LLM Wiki 개념을 제시한 것을 보고, LLM이 직접 위키를 쓰고 이어서 관리하게 두는 방식을 IT·AI 뉴스를 스크랩해서 정리하는 데 적용해봤습니다. 신문 기사 하나를 넣으면 관련 페이지 10~15개가 알아서 갱신되고 백링크로 엮이는 게 신기해서 몇 달을 그렇게 굴렸습니다.
근데 스크랩한 소스가 1,000건을 넘어가니 위키가 걷잡을 수 없이 불어나기 시작했어요. 새 뉴스가 기존 페이지를 덮어쓰고, 비슷한 문서가 중복으로 쌓이고, 출처끼리 안 맞는 내용이 조용히 뒤섞였습니다. 결정적으로 LLM한테 "네가 쓴 거 네가 검토해"라고 시키면 자기가 쓴 거라고 대충 통과시키더라고요.
그래서 좀 특이한 구조로 풀었는데 공유합니다. 요즘 "에이전트가 실수할 때마다 규칙을 진화시킨다"라고 하잖아요. 저는 그걸 뉴스 위키 저작 지침에 적용해본 케이스입니다.
구조 : 신문사 편집국을 흉내 냄
소스 문서를 읽어서 사람이 읽을 수 있는 연결형 마크다운 위키로 엮는 파이프라인인데, 역할을 다섯으로 나눴습니다(편집장·기자·칼럼니스트·데스크·교열). 근데 멀티에이전트라고 다 자율은 아니에요. 실제로 LLM이 독립적으로 판단하는 자리는 데스크(검수) 하나뿐입니다. 나머지는 성격이 다른 글쓰기 작업이거나, LLM이 아니라 규칙대로 도는 파이썬 린트(tools/lint.py), 흐름 잇는 오케스트레이션이고요. 자율 실행이 토큰만 5~10배 태우고 컨텍스트 놓치는 걸 피하려고, 자율성보다 결정론과 컨텍스트 격리에 무게를 뒀습니다.
핵심 1 : 쓰는 쪽과 검수하는 쪽을 따로 두기
위키가 불어나는 걸 잡는 핵심은 컨텍스트 격리였습니다. 데스크(검수)는 결과물이랑 채점 기준(루브릭)만 보고, 글쓴이가 무슨 생각으로 썼는지는 못 봅니다. 자기가 쓴 거 자기가 검수하면 아무래도 후하게 봐주잖아요. 그걸 구조적으로 막으려는 거예요. 여기에 정량 린트가 문서가 불어나거나 중복되거나 정처 없이 늘어지는 걸 기계적으로 걸러냅니다. 여기 "Claude Skills로 블로그 검토 프로세스 만들기" 글 봤는데 결이 비슷하더라고요. 저는 "검수자에겐 초안만 보여준다"는 격리를 좀 더 세게 적용하였습니다.
핵심 2 : "실수하며 진화하는 규칙"을 좀 더 엄밀하게
아까 말한 "에이전트가 실수할 때마다 규칙을 진화시킨다"를 한 발 더 나가보았습니다. 데스크가 반복해서 잡아내는 결함을 가이드라인 강화로 자기진화시키는데, 자칫 잘못하면 고정된 시험 문제에 overfit되거든요. 자기가 만든 피드백으로 자기를 고치니 있던 패턴만 되풀이하는 함정에 빠질 수 있습니다. 그래서 효과를 잴 때는, 개선에 한 번도 안 쓴 새 실패 사례를 매번 따로 빼서 그걸로만 채점합니다. 늘 처음 보는 문제로 확인하는 셈이에요. 솔직히 이 로테이션이 아직 완벽하진 않은 게 한계고, 자기진화가 진짜 품질을 올리는지도 아직 제대로 측정한 게 아니라 실험 중인 가설입니다.
그 외 두 가지
출처끼리 안 맞는 부분은 덮지 않고 따로 모순 페이지로 빼둡니다. 그냥 뭉개면 나중에 위키가 조용히 틀린 내용으로 굳어버리더라고요.
저장은 마크다운 + git, 파이썬 도구는 전부 로컬입니다. clone하면 API 키 없이 예제 그래프를 바로 재현할 수 있어요. 다만 에이전트 자체는 Claude Code로 도니까 그건 각자 키 물려 써야 하고요(BYOK).
공개 레포는 이 구조를 영어 기사 15노드짜리 예제로 재현해둔 겁니다(clone하면 그래프까지 그대로 재현돼요). 위에서 말한 한국 뉴스 인스턴스는 2,300노드쯤까지 커졌는데 그건 따로 비공개라 구분해서 봐주세요.
레포: github.com/alfadur7/llm-wiki-newsroom
"토큰 절약을 위해 범위부터 좁히는" 쿼리 로직이 궁금하시면 tools/query.py 보시면 됩니다.
writer≠reviewer가 정말 wiki 품질을 높이고 있는지, 자기진화 루프가 실제로 도움이 되는지 아직 확신은 없습니다. 비슷하게 Claude Code로 위키나 메모리 굴려보신 분들, 불어나는 문제랑 검수 문제 어떻게 푸셨는지 반론이든 경험이든 듣고 싶어요.
안녕하세요. POS·키오스크 일로 전국 소상공인을 만나는데, 마케팅이 막막해서 같은 키워드 광고비로 출혈 경쟁하는 분들이 많더라고요.
"AI한테 시키면 되지 않나?" 했는데, 한국 마케팅에선 은근히 자신 있게 틀렸어요:
- 밤 10시에 할인 문자 돌리라고 추천 (실제론 정보통신망법 야간발송 위반, 과태료)
- "ChatGPT에 노출되게 GPTBot 허용하세요" (GPTBot은 학습봇, 검색 노출은 OAI-SearchBot)
- "카카오톡 채널 메시지는 무료" (개설·챗봇만 무료, 발송은 건당 유료)
이런 걸 정보통신망법 조문·KISA·각 벤더 공식문서로 못박은 스킬 9종 + references 17개를 만들어 무료(MIT)로 공개했어요. Claude Code / Cursor / Codex에 붙여 쓰면 됩니다. 각 사실에 "기준 시점·확인 필요"도 정직하게 달아놨고요(정책이 바뀌니까).
AI로 마케팅 해보려다 답답했던 분들께 도움 되실까 해서 공유해요. 틀린 부분·최신화 제보 주시면 감사히 반영하겠습니다.
GitHub: https://github.com/gugdongbag-eng/korean-marketing-skills
설명 글(dev.to): https://dev.to/gugdongbageng/i-made-claude-code-get-korean-marketing-right-9-citation-backed-skills-2olc
어제 부서회식후 글을 썼더니 좀 이상하네요 그래서 수정을 했습니다.ㅎㅎㅎ
소개
시도하고자 했던 것과 그 이유를 알려주세요.
혼자 수영을 연습하면서 "내 영법 자세가 맞나?", "접영 팔 각도가 제대로 들어가고 있나?" 항상 답답함이 있었습니다. 수영 커뮤니티를 보니 본인의 수영 영상을 직접 촬영해서 그걸 보고 교정하는 게 가장 좋은 방법이라는 피드백이 많더군요.
하지만 문득 "전문적인 피드백이나 명확한 판단 기준이 없는 상황에서 내 영상을 혼자 쳐다보는 게 과연 무슨 의미가 있을까?"라는 의문이 들었습니다. 기준이 없으면 잘못된 자세를 봐도 알아채지 못하니까요.
그 순간 '수영에 관한 전문지식 교본을 세밀한 프롬프트로 가공하고, API에 먹여서 AI가 내 영상을 보고 기준에 맞춰 코칭을 해준다면 어떨까?' 하는 아이디어가 스치고 지나갔습니다.
이 직관을 검증하기 위해 지난주 목요일 구상을 시작해 금요일부터 본격적인 프롬프트 튜닝에 몰입했습니다. 그리고 이번 주, 서비스 배포와 오픈소스 공개 시 터질 수 있는 백엔드 시스템 보안 장치(보안 하네스)까지 모두 완료하여 깃허브에 MIT 라이선스로 소스 코드를 완전히 공개하게 되었습니다.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
최대한 가볍고 빠르게 작동하는 MVP를 만들기 위해 아래와 같이 경량화된 IT 인프라와 AI 비전 기술 스택을 결합했습니다.
Frontend: React + TypeScript + Vite + Tailwind CSS (swim-web 내 경량 뼈대 구조)
Backend: Flask / FastAPI 기반 Python 경량 분석 서버 (server.py)
AI 비전 엔지니어링: google-genai (Google Gemini 비전 API) + report_render.py (다이내믹 HTML 코칭 리포트 자동 생성)
전체적인 흐름은 유저가 자신의 수영 영상을 웹에 업로드하면, 백엔드(server.py)가 최신 제미나이 비전 API를 호출하여 영상 속 멀티프레임을 분석합니다. 프롬프트에 주입된 전문 기준에 따라 사용자의 스트로크 롤링, 팔 꺾기 각도, 킥 타이밍을 영리하게 추론한 뒤, report_render.py를 거쳐 사용자에게 고유한 시각화 HTML 웹 리포트 링크를 생성해 주는 구조입니다.
📷 랜딩페이지
💻 활용한 백엔드 핵심 코드 전문 (server.py 개요 및 API 구조)
지피터스 회원님들을 위해 깃허브에 올린 백엔드 연동 부 소스 코드 중, 비전 API 호출과 보안 격리 부를 일부 공유합니다.
Python
# server.py 전문 (Gemini 비전 API 연동 및 보안 가드부)
import os
from flask import Flask, request, jsonify
from google import genai
from google.genai import types
from dotenv import load_model load_dotenv() app = Flask(__name__) # [보안 하네스] API KEY 및 민감한 핵심 수영 코칭 프롬프트의 환경변수 격리 구조
GEMINI_API_KEY = os.getenv("GEMINI_API_KEY")
SWIMMING_COACH_PROMPT = os.getenv("SWIMMING_CRITERIA_PROMPT") # google-genai 최신 SDK 초기화
client = genai.Client(api_key=GEMINI_API_KEY) @app.route("/api/analysis", methods=["POST"])
def analyze_swimming(): # [Anti-Abuse] 파일 유효성 및 용량 이중 검증 if 'video' not in request.files: return jsonify({"error": "영상이 첨부되지 않았습니다."}), 400 video_file = request.files['video'] # 임시 저장 후 제미나이 비전 API 멀티프레임 추론 엔진 가동 # (실제 소스에서는 데이터 유출 차단을 위해 Pre-signed URL 및 세션 검증 가드가 작동합니다.) try: response = client.models.generate_content( model='gemini-2.5-flash', # 혹은 비전 최적화 모델 contents=[ video_file.read(), SWIMMING_COACH_PROMPT # 격리된 수영 기준 프롬프트 주입 ] ) return jsonify({"analysis": response.text}) except Exception as e: return jsonify({"error": str(e)}), 500 if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)
결과와 배운 점
과정 중에 어떤 시행착오를 겪었나요?
초기에는 마케팅적인 매력과 빠른 연동을 위해 단순 3초짜리 숏폼 비디오 기반의 판별 시스템을 구상했었습니다. 하지만 수영이라는 운동 특성상 물속에서의 스트로크 주기, 물 잡기 각도, 호흡 및 킥 타이밍을 연속적으로 관찰해야만 유의미한 피드백이 가능하다는 기술적 한계와 데이터 일관성 장벽을 정면으로 마주했습니다. 3초 데이터로는 명확한 기준에 맞춘 정합성 있는 피드백이 나오지 않았습니다.
이에 겉치레용 마케팅 문구를 과감히 버리고, 사용자가 최소 1개 사이클 이상의 영법 흐름이 담긴 전체 영상을 올리도록 강제하는 방식으로 피봇팅했습니다. 제미나이 비전 API가 이를 멀티프레임으로 정밀하게 쪼개어 읽어 들이도록 프롬프트 가이드와 백엔드 수집 단을 전면 수정했습니다. 역시 인공지능 기반의 SaaS 서비스는 겉치레 문구보다 실제 데이터 도메인의 특성과 데이터 정합성을 정직하게 반영해야만 제대로 작동한다는 것을 뼈저리게 배웠습니다.
배운 점과 나만의 꿀팁을 알려주세요.
1인 기업가의 보안 하네스: 오픈소스로 코드를 전면 공개하여 바이럴 유통 엔진을 만들 때, 내 비즈니스의 생명줄인 '독점적 AI 프롬프트(수영 전문 지식)'와 'API Key'를 백엔드 환경 변수(.env) 단으로 완전히 밀어내어 소스 파일에서 도려내는 격리 구조가 필수적이라는 점을 체득했습니다.
선방어 후출시 (Anti-Abuse 가드): 커뮤니티 바이럴 트래픽은 서비스 성장의 거대한 기회이지만 원가 고갈의 위험도 공존합니다. 백엔드 단에서 가입 즉시 무료 크레딧을 잠그고 초과 요청을 차단하는 가드를 먼저 단단히 세워두면, 비용 폭탄 두려움 없이 기분 좋게 제품을 세상에 던질(Ship) 수 있습니다.
도움이 필요한 부분이 있나요? (지피터스 오디언스 피드백 유도)
현재 제미나이 비전 API를 중심으로 백엔드가 굴러가고 있는데, 실전 필드 테스트를 앞두고 두 가지 기술적 장벽에 대해 지피터스의 AI 전문가분들의 고견을 구하고 싶습니다.
비전 LLM 추론 일관성 문제: 긴 영상 분석 시 프레임 샘플링 과정에서 영법 판별 일관성이 간혹 튀는 현상이 있습니다. 영상 데이터의 전처리 방식이나 프롬프트 체이닝 구조를 어떻게 세팅하면 제미나이 비전의 정확도와 피드백 일관성을 최대로 끌어올릴 수 있을까요?
개인정보 자동 마스킹: 수영장이라는 공간 특성상 레인 안의 타인 얼굴이나 신체를 브라우저(클라이언트) 단에서 오픈소스로 가볍게 블러/모자이크 처리할 수 있는 경량 라이브러리 조합이 있다면 추천 부탁드립니다.
앞으로의 계획이 있다면 들려주세요.
현재 배포를 준비하고 있습니다. 베타 테스트를 개시할 예정이며, 지피터스 분들의 소중한 피드백을 바탕으로 제미나이 프롬프트의 추론 일관성을 고도화하여 실제 수영 동호인들과 일선 강사님들이 현장에서 유용하게 쓸 수 있는 SaaS로 진화시킬 계획입니다. 추가로 구독중인 수영유튜버께 자문을 구해 프롬프트를 더욱 다듬고자 합니다.
💻 깃허브 전체 소스 코드: https://github.com/casareborgia/Swim.git
(코드가 흥미로우셨거나 1인 메이커의 무모한 도전을 응원해 주신다면 깃허브에 방문하셔서 ⭐ Star 하나 꾹 눌러주시면 다음 기능을 만드는 데 거대한 에너지가 됩니다!)
도움 받은 글 (옵션)
Connect AI 채널의 "AI 1인 기업 해부" 시리즈: 마크 루의 완벽보다 출시를 우선하는 'Just Ship It' 정신, 사힐 라빙가의 '미니멀 오픈소스 경영학', 토니 딘의 추론 비용 리스크를 통제하는 '유닛 이코노믹스 원가 설계 이론'을 적극 차용하여 MVP의 하방 리스크와 시스템 방어벽을 설계하는 데 큰 영감을 받았습니다.
AI와 함께 개발하다 보면 이상한 비대칭이 하나 생깁니다. 결과물인 코드는 git에 차곡차곡 남는데, 그 코드를 만들게 한 내 말들은 어디에도 남지 않는다는 점입니다. 세션이 끝나면 대화는 사라지고, 며칠 뒤에 남는 건 커밋 메시지 한 줄뿐입니다.
그래서 저는 넉 달 전부터 제가 AI에게 입력하는 모든 프롬프트를 자동으로 기록하고 있습니다. 이번 글은 게임 제작기가 아니라, 이 기록이 실제 개발에서 어떤 도움을 줬는지에 대한 이야기입니다. 저도 이 방법을 어딘가에서 본 적은 없고, 어느 날 문득 '이런 걸 남겨두면 좋을 수 있지 않을까?' 하는 생각이 들어 남기기 시작했습니다. 그렇게 4개월 정도 쌓아보니 "이건 계속할 만하다"는 확신이 생겨서, 그 경험을 공유해 봅니다.
1. 셋팅: 훅 하나로, 손 대지 않고 쌓이게
방식은 단순합니다. Claude Code에는 훅(hook)이라는 기능이 있는데, 특정 이벤트가 일어날 때마다 지정한 스크립트를 실행해 주는 장치입니다. 그중 UserPromptSubmit 훅은 제가 프롬프트를 입력해서 전송하는 순간마다 실행됩니다. 여기에 짧은 셸 스크립트 하나를 걸어두었습니다.
# UserPromptSubmit 훅에 연결된 스크립트 (핵심만 발췌)
LOG_FILE="$HOME/.claude/prompt-logs/$(date +%Y-%m-%d).md"
PROMPT=$(echo "$INPUT" | jq -r '.prompt') # 방금 입력한 프롬프트
PROJECT=$(basename "$SESSION_CWD") # 어떤 프로젝트에서 입력했는지 echo "[$(date +%H:%M)] ($PROJECT) $PROMPT" >> "$LOG_FILE"
날짜별 마크다운 파일에, 시각과 프로젝트 이름을 붙여 한 줄씩 덧붙이는 게 전부입니다. 이렇게 쌓인 로그는 이런 모습입니다.
[14:09] (lezhin-web-front) 상하 좌우 코너에 배치가 안되고 있어.
항상 다이아몬드 꼴이거나 삼각형 꼴이 되더라.
왜 2칸 이상 떨어진 시바는 배치가 안되는거야?
지난달 팅글팡 제작기에서 "버그 하나에 회귀 테스트 하나는 사람이 시켜서는 안 지켜진다, 셋팅으로 강제해야 한다"고 썼는데, 기록도 똑같았습니다. 제가 뭔가를 따로 하는 순간 기록은 반드시 끊깁니다. 훅으로 걸어두면 제가 잊어도 쌓입니다. 그렇게 4개월간 일별 로그 파일 70개, 프롬프트 약 2,700개가 모였습니다. 텍스트뿐이라 전부 합쳐도 1.2MB밖에 안 됩니다.
한 가지 미리 말씀드리면, 이 로그는 git에 커밋하지 않고 제 개인 공간에만 둡니다. 프롬프트에는 정제되지 않은 온갖 것이 다 남기 때문입니다. 그래서 공개하기에는 쑥스러운 기록이라, 나만 보려고 나를 위해 저장해두는 것에 가깝습니다.
2. 커밋 메시지가 남기지 못하는 것
git은 훌륭한 기록 장치지만, 남기는 것은 기본적으로 결과입니다. 커밋 메시지는 "무엇이 바뀌었나"를 말해주지, "왜 그렇게 하기로 했나"와 "어떤 시행착오 끝에 거기 도달했나"까지 말해주지는 않습니다.
사람이 직접 코드를 짜던 시절에는 이 간극이 견딜 만했습니다. 내 손으로 짠 코드니까, 코드를 다시 읽으면 당시의 고민이 어느 정도 되살아나거든요. 그런데 AI 코딩에서는 사정이 다릅니다. 코드를 내가 짜지 않았기 때문에, 며칠만 지나면 커밋과 코드만 봐서는 그때의 판단 과정이 잘 재구성되지 않습니다.
반면 프롬프트에는 그 판단 과정이 날것 그대로 남습니다. 어떤 증상을 보고 문제라고 느꼈는지, 어떤 방향은 시도했다가 접었는지, 왜 이 방식을 골랐는지. 커밋이 결과의 기록이라면 프롬프트는 의도의 기록입니다.
3. 게임 하나의 탄생이 통째로 남는다
프롬프트를 공개하는 건 사실 조금 창피하기도 한 일입니다. 잘 정리된 문장이 아니라 구어체 반말로, 그날그날 생각나는 대로 적은 것들이라서요. 그래도 기록이 어떤 것인지 보여드리려면 실물이 필요하니, 몇 개의 예시만 올려보겠습니다.
지금 오락실 개발중 목록에 있는 타워디펜스 게임 길막TD의 가장 첫 프롬프트입니다. 이 게임의 기획서는 따로 없습니다. 이 프롬프트가 기획서였습니다.
[13:27:20] 모바일에서 플레이하기 좋은, 타워디펜스 게임을 만들어줘. 다른 오락실 게임들 처럼 회원랭킹이 있을거야. 50개의 waves로 만들어져서 점수경쟁하기 좋은 게임으로 만들어줘. 이 조건 하에서 가장 재미를 느낄 수 있을 게임을 만들어줘. 스테이지를 클리어하더라도 게임은 리셋되지 않고 계속 이어지는 구조야. 타워디펜스에서의 wave구조가 어떻게 되어있는지 리서치해보고, 타워디펜스의 난이도나 타워 능력 설계를 어떻게 디자인하는지 리서치해보고 시작해. 몬스터 다니는 길이 정해져있는 타워디펜스가 아닌 맵 전체에 타워를 지을 수 있고, 몬스터들은 맵에서 4개의 포인트를 찍고 나가는 워크래프트 유즈맵세팅식 타워디펜스가 되게 해줘. 몬스터가 타워를 지나갈 수 없으니 타워로 길을 만드는 셈인데, 모든 길을 막아서 몬스터가 다음 포인트로 지나갈 수 없게 되면 몬스터가 타워를 공격해서 부수게 해줘. 타워의 체력과 타워의 체력회복력 몬스터의 공격력이 적절히 셋팅되어서 너무 빨리 부서지거나, 너무 늦게 부서지지 않도록 해줘. 아주 급하면 길을 막을 수도 있지만, 길을 막으면 보통 3초정도면 몬스터에 의해 길이 부서지는 정도의 공격력 셋팅이면 좋겠어. 길이 막혀있지 않으면 몬스터들은 공격을 하지 않고 이동만 하는거야.
그리고 이 첫 프롬프트 뒤로, 한 시간이 채 안 되는 동안 수정 요청이 이렇게 이어졌습니다.
[13:44:46] 게임을 수정해줘. 맵이 4:3 비율로 보이는데, 3:5 정도의 비율로 바꾸면 좋겠어. 입구와 출구를 맵 안에 두지 말고, 맵 밖에 두어줘. 몬스터들이 맵 밖에서 안으로 들어와서 다시 밖으로 나가는 느낌이 되게. 캔버스의 max-width는 600px로 두어줘. 고밀도 디스플레이에서는 고해상도로 보이게 해줘. 지금은 몬스터들의 이동경로를 선으로 그려서 시각적으로 보이게 하고 있는데, 보이지 않게 바꿔줘. 몬스터가 향하는 각 포인트들은 인지할 수 있게 시각적 힌트를 남겨놓아야 하고, 출구와 입구도 텍스트가 아닌 다른 방식으로 시각적 힌트를 줘. 그래픽을 향상하는 방법을 고민해서 보기 좋게 꾸며줘. 테마가 있어도 좋겠어.
[13:52:47] 타워와 몬스터 간의 상성관계가 좀 더 뚜렷하게 해줘. 어떤 타워는 보스몹에게 강하고 일반몹에는 약하고, 어떤 타워는 공중몹에 강하고. 웨이포인트 설정시 타워에 영향을 받지 않고 포인트만 찍고 날아가는 공중 몬스터도 필요해. 그런 몬스터의 등장을 예상할 수 있게, 다음 웨이브에서는 어떤 타입이 나온다는 예고 창도 필요하고. 전반적으로 난이도가 너무 쉬워. 깨기 어려워서 매우 머리를 잘 써서 쥐어짜야 클리어할 수 있는 정도의 난이도로 설정을 해줘. 깨기 힘들지만 여러번 재시도하면서 방법을 찾아나가서 여러번의 재시도 끝에 겨우 클리어 할 수 있어야 재미있는 타워디펜스가 돼. 각 타워와 몬스터간의 상성같은것을 굳이 구체적인 텍스트로 설명하지 않으면서도 인지시키려면 대중적으로 알려진 테마들과 많은 게임들에서 사용하고 있는 상성을 조사해서 테마를 잘 입혀서 하면 될거 같아.
[13:59:18] 현재 그리드가 5:3의 비율인거 같아. 3:5의 portrait 비율로 바꿔줘. 그리고 여전히 입구와 출구가 맵 안에 있어. 맵 바깥에 있도록 바꿔주고, 입구와 출구에 대한 시각적 힌트를 남겨줘. 몬스터가 이동하는 루트를 시각적으로 그려놓은 선도 없애줘.
[14:04:01] 몬스터가 향해가는 각 포인트가 너무 크게 그려져있어. 작게 표시해줘. 순서를 예상할 수 있게 숫자 표시를 해줘. 그리고 각 웨이브는 해당 웨이브의 몬스터가 모두 죽으면 5초카운트후 자동으로 다음 카운트 시작이 되게 해줘. 수동으로 웨이브 시작 버튼을 눌러서 다음 웨이브를 빠르게 시작할 수 있고, 그렇게 하면 남은 시간에 비례해서 아주 작은 보너스 포인트를 줘.
[14:07:15] 포인트의 표시 크기는 적절한데 숫자가 너무 작아. 숫자를 지금보다 크게 보이게 해줘. 몬스터를 좀 더 캐릭터 답게 그려줘. 각 타입에 맞는 모양으로 그려줘. 상성이 테마적으로 느껴질 수 있게.
[14:10:32] 타워의 설명 텍스트가 공간을 먹는거 같으니 없애줘. 대공 텍스트도 빨간 점을 찍어서 힌트만 남겨줘. UI의 공간을 많이 차지 하지 않도록 해서 게임 맵이 사용하는 크기를 더 늘리고 싶은 취지야. 최대한 UI가 사용하는 공간을 줄여서 게임이 공간을 많이 사용하게 해줘.
[14:18:23] waves 는 정확히 텍스트로 표현을 해줘. 줄일 수 있는 게 있고, 줄여야하는게 있고 안줄여도 되는게 있잖아. 어떤 정보 텍스트는 게임위에 띄워도 되고, 다른 버튼과 같이 두지 않아도 되는게 있고 그럴거야. 레이어로 올려도 되는 정보는 올려서 UI가 먹는 공간을 줄여주고, 그러면서도 정보 표시는 충분히 되게 해줘.
다시 읽어보면 이 로그에는 커밋 히스토리가 담지 못하는 것들이 들어 있습니다. "길을 막으면 3초 정도면 부서지는 공격력"이라는 밸런스 수치의 근거, "여러 번 재시도 끝에 겨우 클리어해야 재미있다"는 난이도 철학, "UI 공간을 줄여 게임 맵을 키운다"는 레이아웃 판단의 취지 같은 것들요. 나중에 이 게임을 다듬을 때 "왜 이런 설정이지?"라는 질문이 생기면, 답은 코드가 아니라 이 기록에 있습니다. 즉흥적으로 시작한 게임이라도, 로그를 열면 처음의 기획 의도가 그대로 남아 있는 셈입니다.
4. 기록이 실제로 일한 장면들
쌓아두기만 한 건 아니고, 실제로 꺼내 쓴 장면들이 있습니다.
장면 1: 한동안 손 놓았던 코드로 돌아갈 때
오락실 게임 하나를 몇 주 만에 다시 정리하게 됐을 때, 에이전트에게 이렇게 시켰습니다.
"오락실 게임 블록트릭스의 내용을 살펴보고, 버그나 정리해야 할 내용을 확인해봐. 이전 커밋의 메시지나 프롬프트 로그 중에 참고할 것을 찾아봐도 좋겠어."
에이전트는 커밋 히스토리와 함께 당시 제 프롬프트들을 뒤져서, 그때 어떤 요청이 오갔고 어떤 문제가 미해결로 남았는지를 정리해 왔습니다. 흥미로운 건 이 검색을 제가 아니라 에이전트가 한다는 점입니다. 기록을 쌓는 것도 자동, 꺼내 읽는 것도 AI의 일이라, 저는 그냥 "로그도 참고해봐" 한마디만 얹으면 됩니다.
장면 2: 프롬프트 자체가 설계 메모가 될 때
시바런을 만들 때 이런 프롬프트를 쓴 적이 있습니다.
"아까는 시바가 바운스될 때 교착상태를 체크했는데 그건 오히려 나았어. 근데 지금은 시바가 화면 밖으로 빠져나갈 때만 체크하니까 실제 교착상태가 발생해도 failed 화면이 뜨지 않아. 왜냐면 교착된 시바는 애초에 화면 밖을 빠져나갈 수 없잖아."
이건 버그 신고이면서 동시에 "교착 판정을 언제 해야 하는가"에 대한 논리가 담긴 설계 메모입니다. 이런 판단의 근거는 보통 코드에도 커밋 메시지에도 남지 않고 휘발되는데, 로그에는 제 말투 그대로 남아 있습니다.
장면 3: 제작기와 회고의 사료가 될 때
사실 지난달 팅글팡 제작기에 인용했던 프롬프트들, 예를 들어 "16스테이지인데 얼음 깨기 목표가 9/10이야. 보드에는 남은 얼음이 없는데?" 같은 문장은 제 기억에서 나온 게 아니라 이 로그에서 나왔습니다. 글을 쓸 때 로그를 열어 그 무렵의 기록을 훑으면, 뭘 했는지가 아니라 뭘 하려다 뭘 겪었는지가 시간순으로 복원됩니다. 월간 업무 정리나 회고를 쓸 때도 마찬가지입니다. 기억이 아니라 기록에 기대어 쓰게 됩니다.
5. 한계와 주의할 점
물론 좋은 점만 있는 건 아닙니다. 4개월 해보면서 신경 쓰게 된 것들입니다.
로그는 아무거나 다 남깁니다. 훅은 판단하지 않고 전부 기록하기 때문에, 업무와 무관한 혼잣말이나 잠깐의 딴 궁리, 붙여넣은 자료까지 그대로 남습니다. 제가 이 로그를 git 밖 개인 공간에만 두는 이유이고, 이번 글처럼 어딘가에 인용하기 전에는 반드시 한 번 훑어봐야 하는 이유이기도 합니다.
대화의 반쪽만 남습니다. 이 로그에는 제 프롬프트만 있고 AI의 답변은 없습니다. 처음엔 반쪽짜리 기록인가 싶었는데, 오히려 장점에 가까웠습니다. 답변까지 다 남기면 로그가 수십 배로 불어나 검색이 어려워지는데, AI의 답은 어차피 코드와 커밋으로 남아 있으니까요. 의도는 로그가, 결과는 git이 나눠 맡는 구조입니다.
꺼낼 수 없는 기록은 기록이 아닙니다. 날짜별 파일, 시각과 프로젝트 이름 태그라는 단순한 형식 덕분에 grep이든 에이전트든 쉽게 검색할 수 있습니다. 형식 없이 쌓기만 했다면 4개월치 로그는 그냥 큰 텍스트 덩어리였을 겁니다.
마무리
정리하면 세 가지입니다.
첫째, 커밋은 결과를 남기고 프롬프트는 의도를 남깁니다. 코드를 AI가 짜는 시대에는 의도의 기록이 점점 더 귀해집니다. 코드는 다시 만들 수 있지만, 그때 왜 그렇게 하기로 했는지는 다시 만들어지지 않으니까요.
둘째, 기록은 셋팅으로 강제해야 쌓입니다. 훅 하나 걸어두는 10분짜리 셋팅이면, 이후로는 아무 노력 없이 기록이 쌓입니다. 사람의 성실함에 기대는 기록은 반드시 끊깁니다.
셋째, 기록의 가치는 다시 꺼낼 때 생기는데, 꺼내는 일도 이제 AI가 해줍니다. 쌓는 것도 자동, 찾는 것도 자동이라면, 남는 질문은 하나뿐입니다. 기록해 둘 것인가, 흘려보낼 것인가.
## 시도하고자 했던 것과 그 이유를 알려주세요.
### 택배박스에서 시작한
10여 년 전, 우리 집에는 이상한 법칙이 하나 있었습니다. 택배가 도착하면 물건보다 박스가 먼저 사라진다는 것.
4살 아들과 2살 딸은 박스만 오면 그 안에 들어가 놀았고, 급기야 "아빠, 집 만들어줘"라는 주문이 떨어졌습니다.
고민 끝에 해외에서 우주선 모양 박스 텐트를 사줬습니다. 유년기 아이들은 엄마 뱃속에 대한 기억 때문인지 어딘가로 들어가려는 인간 본연의 행동을 합니다. 어린이 용품 중에 인디언 텐트가 유독 사랑받는 이유도 그것이겠지요. 2살 딸아이는 그 우주선 안에 이불을 펴고 일주일을 잤습니다. 저는 그 안에 터치 전등도 달아줬습니다.
그런데 어느 날 문득 이런 생각이 들었습니다.
"어른이 만들어주는 집 말고, 아이들이 직접 상상의 집을 지을 수 있다면?"
그 호기심이 모든 것의 시작이었습니다. 시중에 빨대로 연결하는 어린이 과학 교구가 있다는 걸 알고 있었는데, 그 구조를 들여다보다가 확신이 왔습니다. 삼각형으로 만들면 어떤 형태의 입체 구조라도 다 만들어낼 수 있겠다.
문제는 아파트에 살면서 뭔가를 만들 공간이 없다는 것. 다행히 지하에 짐 넣는 창고가 있었고, 사람 왕래가 적어 거기서 작업을 시작했습니다. 빌 게이츠가 차고에서 시작했던 것처럼 말입니다.
👉 [사진 1: 지하 창고에서 파이프를 조립하는 모습]
빨대를 잔뜩 연결해 만들어봤지만 아이 둘이 들어가기엔 너무 작았습니다. 철물점에서 수도관 파이프를 사다가 톱질을 시작했고, 지오데식 돔이라는 건축 비율을 참고해 결국 돔 구조를 세웠습니다. 그런데 아이들이 들어가 놀기엔 너무 거칠고 조잡했습니다.
그때 떠오른 게 학창 시절 배운 '점, 선, 면'이었습니다.
"선으로 안 되면, 면으로 가보자."
택배박스 재질의 종이를 이등변삼각형과 정삼각형으로 재단하고, 구멍을 뚫고, 케이블타이로 연결할 날개를 달았습니다. 그렇게 만든 돔이 거실 마루에 세워진 날 이후, 그 구조물은 두 달 동안 아이들의 잠자리이자 전용 공간이 되었습니다.
👉 [사진 3: 완성된 돔 앞에 선 저]
👉 [사진 2: 돔 안에서 빼꼼 나오는 아이]
저는 25년째 학생들의 체험 프로그램을 개발하는 일을 하고 있습니다. 그래서 우리 아이들이 이렇게 좋아하는 걸 더 많은 학생들이 경험하게 하고 싶었습니다. 종이박스 블록을 가볍고 오래 쓰는 재질로 바꾸고, '리벳'이라는 연결장치를 개발하면서 수많은 학생들의 팀 협동 구조물 제작 체험으로 풀어냈습니다. 이후 색감과 친환경 소재 방향으로 종이 블록을 추가 개발하며 수학 원리를 입힌 '종이레고'의 양산 체계를 잡았고, 지금은 학교와 교육기관을 중심으로 사업을 하고 있습니다.
👉 [사진 4: 강당 가득 학생들이 팀별로 돔을 조립하는 체험 현장]
이름은 폴리곤즈(POLYGONS)로 지었습니다. 생물의 가장 작은 단위가 세포이듯, 3D 그래픽에서 입체를 구성하는 최소 단위를 폴리곤이라고 합니다. 그 모양은 삼각형인데, 이 삼각형이란게 모든 입체물을 만들어 낼수 있는 마법의 도형이거든요. 그래서 확신이 생겼습니다. 작게도 만들어보자. 역시 성공
👉 [사진 5: 폴리곤즈 블록으로 만든 실제 작품들]
그러나 AI에 대한 불안감이 밀려올때 쯤 확신 하나로 지피터스를 알게 되었고
3기 동안을 과정을 거치면서 다혜님을 비롯한 많은 분들의 도움으로 생각을 전환하는 계기를 맞이하게 되었습니다.
초등학생이 배우는 평면도형·입체도형을 폴리곤즈 블록으로 다루는 AI 웹앱을 구상하게 되었고,
지금은 AI가 생성한 입체 결과물을 폴리곤즈 블록으로 실제 구현할 수 있는 구조로 만들어주는 서비스로 진화하는 중입니다.
이번 4일간 시도한 것은 하나였습니다.
내 컴퓨터에서만 돌던 '폴리곤즈 AI 빌더'를 누구나 접속할 수 있는 웹 서비스로 만드는 것.
아이가 "독도를 지키는 거북이 만들어줘"라고 입력하면, AI가 컨셉 이미지와 설계 스토리, 필요한 블록 수량표 초안을 만들어주고, 그 상상을 실제 블록으로 만들어 볼 수 있는 "AI 현실화 제품"
왜 이걸 하냐고 묻는다면 — 내가 상상하는 것을 AI로 기획하고 현실에서 직접 만들 수 있는 시스템이야말로
AI 시대에 가장 필요한 부분이자 교육적 의미가 가장 크다고 생각하기 때문입니다. AI 시대의 가장 중요한 능력은
소통과 협업입니다. 길이가 같기도 하고 다르기도 한 블록들이 연결되는 구조 속에서
아이들은 재미와 공간지각능력, STEAM 교육의 기회를 얻습니다.
👉 [사진 6: 실제 화면 ]
화면 속 상상이 손으로 만질 수 있는 구조물이 되는 것 — 저는 폴리곤즈가 피지컬 AI로 가는 중간 단계라고 믿습니다.
곡성 워케이션에 오기 전, 제 질문은 이거 하나였습니다.
"곡성에 가면 내 결과물의 퀄리티를 높여줄 능력자분들이 계실까?" 라는 의구심이 들었으나
그 물음은 이렇게 많은 실력자들이 있다니...라는 말로 표현되었습니다. 옆에서 잘 이끌어주시는 운영진들과 각자의 분야에서 AI로 자신을 비롯하 세상을 바꾸는 동기분들을 보며 존경스럽다는 생각과 이분들이 찐 멘토라는 느낌뿐이었습니다.
👉 [사진 7: 생성 검색의 결과물 실제 화면 ]
## 진행 방법
| 역할 | 도구 | 하는 일 |
오픈클로 / 헤르메스 / 구글AI스튜디오 / 클로드 / 클로드코드 를 유기적으로 경쟁시키면서 비개발자의 욕망을 채웠습니다.
| 초안 작성자 | 구글AI스튜디오 | 코드 초안을 생성 |
| 검수·병합자 | Claude / ClaudeCode / 오픈클로 / 헤르메스| 초안을 검증하고, 테스트 통과 후에만 확정 반영 |
| 생성 엔진 | Gemini API | 앱 안에서 컨셉 이미지·설계 생성 |
| 인프라 | Firebase | 로그인·데이터 저장·이미지·배포·API 중계 |
즉 회사로 치면 신입 개발자와 시니어 리뷰어를 붙여둔 구조입니다.
초안 AI가 만든 코드는 절대 바로 반영되지 않고, 검수 AI가 자동 검증 4종(구조 검증·린트·빌드·번들 보안 검사)을 통과시켜야만 확정됩니다.
👉 [사진 8: 타타님의 최애 진격의 거인 "리바이 병장" ]
4일의 타임라인:
- 1일차: 노트북에서 만든 전개도 생성기 초안 6건을 맥미니의 오픈클로와 클로드로 하나씩 검증·병합. 동시에 "웹 화면에 제품 실측 수치를 절대 내보내지 않는다"는 보안 게이트를 코드에 심음.
- 2일차: AI가 생성한 설계는 아직 검증 전이므로, 모든 신규 결과물에 컨셉 · 미검증 배지를 붙이고 제작용 다운로드는 잠그는 게이트 구축.
- 3일차: Firebase 연동. 이메일 로그인 + 설계 히스토리 클라우드 저장 + 첫 웹 배포. 로컬 앱이 처음으로 인터넷 주소를 가진 날.
- 4일차: 배포판 총점검. API 키를 서버 뒤로 숨겨 회원은 키 입력 없이 생성 가능하게. Safari에서 다운로드가 깨지던 버그 수정. 삭제·공유·3D프린트(STL) 버튼 추가. 마지막으로 카카오톡 공유 시 미리보기 카드가 뜨는 공유 퍼널까지 완성.
> 사용한 프롬프트 전문 — 이 서비스의 방향을 정한 지시문 원문으로 , 25년 체험 교육 현장의 경험을 그대로 말로 옮긴 것입니다.
```
전세계 모든 초등학생들이 공부하는 평면도형과 입체도형에 대해 분석하고
치수와 모양을 자유롭게 연동해서 실제로 출력해줄수 있도록 기능을 제작해줘.
생성하고자 하는 결과물을 특징과 테마별로 나누고 그 특징에 따라
폴리곤즈 블록으로 제작할 수 있게 분석가이드와 제언을 첨부해줘
이 한 문단이 앱의 뼈대가 됐습니다. '전 세계 초등학생이 배우는 도형'이 서비스의 범위를, '특징과 테마별 분류'가 UI 구조를, '폴리곤즈 블록으로 제작 가능하게'가 검증 엔진의 존재 이유를 정했습니다.
AI에게 '기억'을 만들어준 방법 — 제 방식의 또 다른 핵심입니다. AI는 세션이 끝나면 다 잊어버립니다. 그래서 파일로 기억을 강제했습니다.
```
_AGENTS/
├── PROTOCOL.md ← AI가 지켜야 할 작업 규칙 (세션 시작 시 필독)
├── STATE.md ← 현재 상태 단일 최신본 (뭐가 완료, 뭐가 대기인지)
├── INBOX.md ← 사람이 AI에게 넘기는 작업 요청함
└── sessions/ ← 매 세션 종료 시 AI가 스스로 남기는 작업 일지
```
새 세션의 AI는 이 파일들을 먼저 읽고 시작하므로, 어제의 AI가 한 일을 오늘의 AI가 정확히 이어받습니다. 4일간 세션 일지가 17건 쌓였습니다. 새벽 1시 15분, 2시 10분, 4시, 5시, 6시 20분… 일지의 타임스탬프가 곧 제 수면 기록입니다.
---
## 결과와 배운 점
결과부터. 폴리곤즈 AI 빌더가 웹에 살아 있습니다 → https://polygons-ai.web.app
- 이메일 회원가입만 하면 API 키 입력 없이 AI 설계 생성
- 설계 히스토리 클라우드 저장, 어느 기기에서든 열람
- 카카오톡 공유 시 미리보기 카드 노출
- 3D프린트용 STL 미니어처 다운로드
10년 전 지하 창고에서 톱질하던 아빠가, 이제는 AI 두 대와 함께 밤을 새워 웹 서비스를 배포합니다. 도구는 톱에서 AI로 바뀌었지만 하는 일은 똑같습니다. 아이들이 상상하는 집을 지을 수 있게 돕는 것.
### 배운 점과 나만의 꿀팁을 알려주세요.
4일을 통과하고 나서 제게 남은 문장은 이것입니다.
"AI는 내 생각을 덜어주는 게 아니라, 내 생각의 결과를 더욱더 상상하게 한다."
AI를 쓰면 편해질 줄 알았는데 반대였습니다. 결과물이 나오는 속도가 빨라지니 다음 상상이 더 커지고, 더 절실해집니다. 그래서 4일간 평균 3시간을 잤습니다. 다른 분들의 열정을 보면서 더 불태우게 되는 시간들이었습니다. 운영진께 한 말씀 드리자면 — 이런 분들을 같이 모아주시면 다들 병들어 쓰러집니다~!
비개발자 대표로서의 꿀팁 3가지:
1. AI 를 분업시키세요. 초안 AI와 검수 AI를 분리하면 속도와 품질을 둘 다 가질 수 있습니다.
2. AI에게 기억 파일을 만들어주세요. STATE.md 파일 하나가 "어디까지 했더라"를 없애줍니다.
3. 지키고 싶은 것은 규칙 파일에 쓰세요. 저희는 제품 실측 수치를 웹에 내보내지 않는 게 생명인데, 이걸 사람 기억이 아니라 빌드 자동 검사로 강제했습니다. AI가 실수해도 배포가 실패하게 만들어두면, 새벽 4시의 판단력도 믿을 수 있습니다.
### 과정 중에 어떤 시행착오를 겪었나요?
1. 가짜 성공의 함정. 웹 배포판에는 서버가 없는데 화면은 "전송 성공"을 띄울 수 있는 구조였습니다. 배포 후 전 기능을 실제로 눌러보는 총점검에서 발견했습니다. AI가 "됐다"고 말해도, 배포판에서 직접 눌러보기 전엔 된 게 아닙니다.
2. Safari의 배신. 크롬에서 멀쩡하던 파일 다운로드가 맥 Safari에서 전부 깨졌습니다. 다운로드 직후 파일 주소를 즉시 회수하던 코드 패턴이 원인이었고, 11곳을 공통 코드 하나로 교체해 해결했습니다.
3. 보류한 코드가 배포에 섞여 나감. 반영하지 않기로 한 변경이 빌드에 포함돼 배포된 걸 점검에서 발견했고, 이후 "확정된 코드만 배포" 원칙을 세웠습니다.
그리고 가장 큰 성찰 하나. 멘토로 참여해주신 분들이 문제에 접근하는 사고방식을 옆에서 지켜보며, 원시인에서 현대인으로 거듭나는 반성의 시간을 가졌습니다. 곡성에 오기 전 저는 "내 결과물의 퀄리티를 높여줄 능력자분들이 계실까?"를 물었는데, 와보니 너무나 대단한 분들 속에 제가 있다는 걸 새삼 느꼈습니다. 각 분야에서 이런 분들이 AI로 세상을 바꾸고 있구나 — 존경의 마음과 함께 더 불타오르는 열정을 얻었습니다.
### 도움이 필요한 부분이 있나요?
곡성 워케이션에서 만난 참가자분들의 능력치를 보며 앞으로가 더 기대됩니다. AI 기술 멘토링, 사업 기회 확장, 협업 증대 — 어느 쪽이든 폴리곤즈와 연결될 수 있는 분들의 연락을 기다립니다. 특히 생성된 3D 결과물의 퀄리티를 높이는 작업과, 교육 현장 확산에 함께해주실 분이라면 언제든 환영입니다.
### 앞으로의 계획이 있다면 들려주세요.
AI가 생성한 입체 결과물이 폴리곤즈 블록 구조로 자동 변환되는 파이프라인을 고도화해서, 아이가 화면에서 상상한 것을 교실에서 친구들과 손으로 짓는 경험까지 연결하는 것. 상상 → AI 설계 → 실물 구조물로 이어지는 이 흐름이 완성되면, 그게 제가 생각하는 피지컬 AI 교육의 시작점입니다.
10년 전 택배박스 돔에서 자던 2살 딸은 이제 중학생이 되었습니다. 그때 아이 둘을 위해 만들던 것을, 이제는 전 세계 아이들을 위해 만들고 있습니다.
---
## 도움 받은 글 (옵션)
- [다혜님 — 사람들은 반복만을 보고 판단한다 (커뮤니티 운영 노하우)](https://www.gpters.org/ax-lab/post/people-only-judge-repetition-DwMnDvuQQKXR9YK) — 꾸준한 반복과 기록의 힘을 배웠습니다.
- 준님의 실전 사례 / 정기님의 실전 사례
이 사례글도 그 가르침의 실천입니다.
아침마다 이런 적 없으세요? Slack 스크롤하고, 메일함 열고, 이슈 트래커 확인하고… "어제 내가 뭘 했더라, 오늘 뭘 챙겨야 하더라"를 매번 여기저기서 손으로 긁어모으는 거요. 저는 매일 아침 그걸 했어요.
그래서 이번엔 매번 AI에게 시키는 대신, "매일 아침 알아서 굴러가는 루프"로 만들어보자고 마음먹었습니다. 결과부터 말하면 — 반나절 만에 설계를 세우고, 실제로 제 Slack 채널에 첫 브리핑이 올라오는 것까지 봤어요. 그 과정에서 "AI를 믿어도 되는지 어떻게 아느냐"라는, 생각보다 중요한 걸 배웠습니다.
매번 시키기 vs 루프로 굴리기 — 뭐가 다를까
처음엔 그냥 "매일 아침 브리핑 해줘"라고 시키면 되는 줄 알았어요. 그런데 이게 매일 반복되는 일이라, 한 번 잘 설계해두면 매번 설명 안 해도 같은 품질로 돌아가게 만드는 게 핵심이더라고요. 이걸 요즘 '루프 엔지니어링'이라고 부른대요.
핵심은 세 가지였어요.
어디서 긁어올까 (소스): Slack·Gmail·Calendar, 그리고 이슈 트래커
어제 본 것 이후만 보기 (매일 전체를 다시 읽으면 낭비니까)
결과가 맞는지 어떻게 확인할까 (이게 제일 중요했어요)
매일 아침 9시, Slack·메일·일정에서 "어제 한 것 / 오늘 할 것"만 뽑아서
내 전용 채널에 올려줘. 액션까지 만들 필요는 없고, 이 두 가지만 정확하게.
"AI야 잘 했어?" 하고 물으면 항상 "네" 라고 합니다
설계하다가 제일 크게 배운 부분이에요. AI한테 "브리핑 잘 만들었어?"라고 물으면 거의 항상 "네 잘 됐어요"라고 해요. 자기 채점은 후하거든요.
그래서 만드는 역할과 검사하는 역할을 나눴습니다. 검사하는 쪽은 AI의 요약을 그냥 믿는 게 아니라, 원본에서 숫자를 다시 세서 대조하게 했어요. 예를 들면 이런 식으로요.
표시한 항목 수 == 실제로 긁어온 항목 수 (빠뜨린 거 0)
소스를 몇 개나 성공적으로 읽었나 (못 읽은 소스는 대놓고 표시)
각 줄에 진짜 원본 링크가 붙어 있나 (지어낸 거 0)
전부 "숫자로 셀 수 있는 기준"이라, 기계가 자동으로 판정할 수 있어요.
실제로 한 번 돌려봤더니 — 반쪽짜리였지만 그게 더 좋았다
설계만 하고 끝내면 안 되잖아요. 진짜 한 번 돌려봤어요. 그랬더니 소스 4개 중 하나(이슈 트래커)는 로그인 인증이 안 붙어서 못 읽더라고요.
여기서 재밌었던 건 — 못 읽은 걸 숨기지 않고 "⚠ 이 소스는 못 봤음"이라고 브리핑에 대놓고 표시하게 해뒀다는 거예요. 그래서 아침에 브리핑을 보자마자 "아, 이슈 트래커가 빠졌네"가 한눈에 보였어요. 실패를 감추는 게 아니라 드러내는 설계가 실제로 통한 순간이었죠.
AI가 "그럴듯하게 틀리는" 걸 잡아낸 순간
첫 브리핑을 보다가 한 줄이 좀 이상했어요. 어떤 일정 조율 대화를 AI가 "강사 일정 조율"이라고 분류해놨더라고요. 그런데 원문을 보니 그건 강사가 아니라 내부 팀 저녁 약속이었어요.
왜 이런 실수가 났냐면, 제가 다른 데 적어둔 "강사 일정 조율"이라는 그럴듯한 표현을 AI가 엉뚱한 대화에 갖다 붙인 거였어요. 틀린 건 아닌 것 같은데 사실 틀린, 딱 그런 케이스였죠.
이거 왜 강사 일정 조율이라고 판단한 거야?
이걸 제가 바로 잡을 수 있었던 이유가 하나 더 있어요. 각 줄에 원본 링크가 있으면 클릭해서 바로 확인할 수 있거든요. 그래서 규칙을 두 개 추가했어요 — "원문에 없는 라벨은 추론하지 말 것", "모든 소스에 원본 링크 붙일 것".
결과
Before → After
아침 업무 파악 여기저기 손으로 스크롤 → 한 채널에 요약 브리핑
결과 신뢰 "맞겠지" → 숫자로 검증 + 원본 링크로 확인
반복 매번 새로 시킴 → 레시피+상태 파일로 굴러감
아직 "매일 9시 완전 자동"까지 붙인 건 아니에요(인증·예약 연결이 남았어요). 하지만 설계와 첫 실전 게시까지 손에 쥐었고, 무엇보다 "AI 결과를 어떻게 믿을지"에 대한 감을 잡은 게 제일 큰 수확이었어요.
AI 활용 팁!
이 방식은 반복되는 정리 업무 어디에나 붙일 수 있어요 — 주간 리포트, 고객 문의 트리아지, 마감 임박 건 챙기기 같은 거요. 단, 딱 두 가지만 기억하세요.
완료를 AI 자기평가로 하지 마세요. "잘 됐어?" 대신 "숫자로 세서 대조"할 기준을 하나라도 만드세요.
결과에 원본 링크를 꼭 붙이세요. 그래야 "그럴듯하게 틀린" 걸 클릭 한 번으로 걸러냅니다.
바로 쓸 수 있는 프롬프트
매일 아침, [내 소스: Slack·메일·일정 등]에서 "어제 한 것 / 오늘 할 것"만 뽑아 [받을 곳]에 정리해줘.
규칙 3가지: ① 각 줄에 원본 링크를 꼭 붙일 것 ② 원문에 없는 내용은 추론해서 라벨 달지 말 것 ③ 못 읽은 소스가 있으면 숨기지 말고 "⚠ 미확인"으로 표시할 것.
마지막에 "표시한 항목 수 = 실제 항목 수"가 맞는지 스스로 세서 알려줘.
[대괄호] 부분은 본인 상황에 맞게 바꾸세요.
🤑 불편함의 시작
안녕하세요. 저는 인테리어 회사를 운영하고 있습니다.
인테리어 회사는 잡무가 너무 많아 좋은 디자인과 공사 퀄리티를 뽑는데 충분한 시간을 쓰기가 쉽지 않은데요.
아임웹 홈페이지로 들어온 인테리어 견적문의를 -> 사람이 노션에 다시 옮겨 적고 -> 그 내용을 보고 견적서를 만들던 과정을 자동화하고 싶다 라는 점에서 시작을 해보았습니다.
📄 기존 방식
고객이 홈페이지 아임웹 견적요청 페이지에 정보를 입력하면, 그 내용이 아임웹 대시보드에만 쌓였습니다.
직원은 그 내용을 하나씩 확인해서 노션 테이블에 다시 옮겨 적습니다.
초도상담을 진행하고자 하면 상담 직후, 초도상담 이전 가견적을 원하면 즉시 직원은 노션에 옮겨진 데이터를 보면서 견적서를 엑셀로 작성합니다.
직원은 견적서의 기준이 헷갈리기 때문에 이전에 작성한 비슷한 평형대의 견적을 수시로 찾아보면서 견적을 작성하고, 고객 요청에 의해 1차, 2차 ... 견적의 버전들을 생성합니다
✌️ 개선방식
Claude Code에게 기존 홈페이지 주소와 견적문의 페이지 구조를 알려주고, 새 견적문의 페이지를 만들게 했습니다. (이유: 꼭 유지해야 할 필요가 없다면 좀 더 기타 여러 작업에 유리하게 아임웹 포기)
Firebase를 붙여서 새로 접수된 견적 데이터가 데이터베이스에 저장되도록 했고, Firestore에 보이는 데이터 뿐만 아니라 직원이 문의 내용을 페이지상에서도 직관적으로 확인할 수 있는 어드민 페이지를 만들었습니다.
여기에 Claude Code의 도움을 받아 [인테리어 견적 산출기]를 제작하였습니다.
[인테리어 견적 산출기]는 공사신고부터 최종 마감까지 공사가 순차적으로 진행되면서 고려해야할 노무비, 자재비를 회사 내부차원에서 검토하고 견적을 작성하는데 도움을 주는 페이지이며, 소비자 견적서는 간결한 형태로 만들어줍니다
그리고 지금은 Firebase에 들어온 견적문의를 바탕으로, 고객이 직접 입력한 정보들 (고객명, 전화번호, 주소, 평형정보 등이 자동으로 견적서 서식으로 불러와지는 것까지 성공하였습니다.
🏌️♀️ 앞으로의 방향
우선, 아직은 견적서의 산출기에 제가 원하는 항목들이 고객님이 기재하는 견적문의 서식하고 차이가 많이 나고, 또 정보를 완벽하게 처음부터 입력시키게끔 유도할 수 없으니 AI로 하여금 스스로 판단하여 가견적을 작성하게 한 후 -> 어떤 판단때문에 그렇게 결정하여 가견적을 냈는지 Reasoning을 출력할 수 있게 하는것
이전 현장에서 만들어냈던 견적, 가견적 엑셀파일이 많이 있습니다. 이런 자료를 AI가 잘 받아먹을 수 있는 형식 또는 구조로 가공하여 학습시키기
학습된 정보를 바탕으로, 견적문의가 들어오는 경우 자동으로 견적서 산출을 하여 가견적을 만들어주는 것 까지 진행 해 보기 (또는 직원이 재가공하기 편한 수준까지 만들어내기)
🫡 적용가능범위
평소 아임웹을 쓰시는 다른 자영업자분들도 모객을 홈페이지를 통해서 하시고 가견적을 송부해야하는 순서로 일하신다면 비슷하게 적용 해 보실 수 있습니다
더 나아가 기존 공사 완공 현장의 견적 데이터를 학습시켜 아파트 평형과 아파트 명을 가지고 보다 현실적인 최종 견적에 가깝게 견적산출을 하도록 고도화 시킬 수 있을 것 같습니다
계약 후 수정된 견적서를 기반으로 고객 소통용으로 만드는 각종 지시서에 견적에 들어간 항목이 누락이 되지 않았는지, 혹은 고객과 결정한 지시서의 내용이 반대로 최종 수정 견적서에는 누락이 되지 않았는지 등 데이터를 활용한 다양한 적용을 고민해볼 예정입니다
❤️ 배운점
클로드코드를 처음 써봤습니다
요금제를 자꾸 자꾸 업그레이드하는 남편의 마음을 이해하게 되었습니다
사업 구축할 때 필요하다고 여기 저기 서비스들 끌어서 쓴 것들도 찬찬히 생각해보면 새로 구축하지 못할 것이 없다는 생각이 든다 (아임웹처럼 지금 따로 쓰고있는 되는시간 같은 서비스들도 만들 수 있지 않을까?)
곡성 AI 워케이션은 저같은 게으름뱅이도 뭔가 아웃풋을 내게 만드는 아주 소중한 기회이다 라는 점을 배웠습니다. 구현에 큰 도움주신 준님 정말 감사드립니다!
비개발자가 AI로 5일 만에 '내 가계부 앱'을 만들고 미분류를 55%→14%로 줄인 전 과정
🧩 이 글은 5일에 걸친 가계부 자동화 프로젝트(기획 2일 + 구현 3일)의 전 과정을 하나로 묶은 완주기입니다. 코드는 한 줄도 직접 짜지 않았고, 전부 AI(Claude Code)와 대화하며 만들었습니다.
📝 한줄 요약
흩어진 카드·간편결제·계좌 내역을 한곳에 모아 "내 규칙대로" 자동 분류하는 개인 가계부 앱을, 개발자가 아닌 제가 AI와 5일 만에 만들었습니다. 시중 앱이 62%나 미분류로 두던 제 거래를, 최종적으로 미분류율 55.7% → 13.8%까지 줄였습니다.
바쁘시면 이것만 읽어도 돼요:
문제를 뾰족하게 좁혔다 — "가계부의 진짜 난제는 예쁜 화면도 분류 알고리즘도 아니라 ①데이터 수집"이고, 미분류의 정체는 간편결제가 가게 이름을 가린 '정보 부재'였다
AI를 코드 짜는 손이 아니라 문제를 같이 분해하는 사고 파트너 + 실데이터 검증기 + 여러 명처럼 나눠 일하는 구현팀으로 썼다
핵심 설계는 "AI가 자동 확정하지 않고, 제안만 하면 내가 승인" — 정확성과 자동화를 둘 다 잡은 안전장치
암호화된 카드 명세서 복호화, 네이버페이 영수증 버튼 한 번 자동 수집까지 브라우저 자동화로 해결
결과물은 데모가 아니라 매일 쓰는 실제 앱(수집 4소스 자동화, 테스트 173개 전부 통과)
이 방법은 가계부만이 아니라 "흩어진 데이터를 모아 내 기준으로 반복 분류하는" 모든 업무에 그대로 옮길 수 있다 (아래 재사용 프롬프트 6종)
🎯 이런 분들께 도움돼요
시중 가계부·지출 관리 앱의 분류가 답답해서 내 규칙대로 만들고 싶은 분
여기저기 흩어진 내 데이터(주문내역·영수증·거래처)를 한곳에 모아 자동 정리하고 싶은 비개발자
Claude Code 같은 AI로 아이디어부터 완성된 도구까지 끝까지 가보고 싶은 입문자
AI에게 분류·정리를 시키되 틀린 걸 자동 반영하는 게 불안한 실무자
😫 문제 상황 (Before) — 문제를 뾰족하게 좁히기
제 지출은 신용카드, 체크카드, 네이버페이, 계좌이체로 흩어져 있습니다. 뱅크샐러드 같은 앱이 모아주긴 하는데 두 가지가 늘 불만이었어요. 첫째, 분류를 제 맘대로 못 바꿉니다. 둘째, 1년치를 열어보면 62%가 "미분류"로 떠 있었습니다.
처음엔 "분류 알고리즘을 잘 만들면 되겠지" 생각했는데, AI와 문제를 뜯어보니 완전히 달랐습니다. 가계부 자동화를 ①수집 → ②분류 → ③집계 세 단계로 쪼개보니, ②분류와 ③집계는 사실 쉬운 문제였어요. 진짜 난제는 ①수집 하나였습니다.
그리고 더 파고드니, 골칫거리였던 "분류"마저 사실은 수집 문제였습니다. 미분류로 뜨던 거래의 정체는 —
네이버페이
당근페이
인터넷쇼핑몰결제(HI-POINT)
인터넷상거래_(네이버 현대카드)
위 사용 내역을 어떻게 정확히 알수 있지?
"뭘 샀는지" 정보 자체가 데이터에 없었습니다. 네이버페이로 3만 6천 원을 썼다는 건 나오는데, 그게 책인지 옷인지 영양제인지는 어디에도 안 적혀 있었죠. 간편결제(PG)가 실제 가게 이름을 가려버린 겁니다. 이건 아무리 똑똑한 분류기를 만들어도 못 푸는, "알고리즘 문제가 아니라 정보 부재 문제"였습니다.
그래서 목표가 명확해졌습니다. 똑똑한 분류기를 만드는 게 아니라, (1) 빠진 가게 이름을 다른 데서 찾아오고, (2) 찾아온 걸 내 규칙으로 분류하는 두 가지였습니다.
🛠️ 사용한 도구
메인 도구: Claude Code (터미널에서 대화하며 실제로 파일을 열고 분석하고 코드를 짜주는 AI)
모델: Claude Opus
외부 연동: 네이버 지역검색 API(가게 업종 조회) · 무료 AI(Google Gemini, 그 외 업종) · 브라우저 자동화(Playwright — 카드 명세서 복호화, 영수증 자동 수집)
보조: Codex(앱 아이콘·이미지 생성)
특이사항: 코드는 한 줄도 직접 안 썼습니다. AI에게 문제를 분해시키고, 실데이터를 까보게 하고, 잘게 쪼개 구현시켰습니다. 비밀번호·API 키는 채팅에 절대 넣지 않고 별도 파일로 분리했습니다.
🔧 작업 과정 — 5일간의 전 과정
전체를 5일로 나눠, 실제 대화 순서대로 풀어봅니다.
1일차 — 기획: AI를 '사고 파트너'로 문제를 분해하다
첫날은 코드 없이 문제만 뜯었습니다. AI를 답을 주는 기계가 아니라, 문제를 같이 분해하는 상대로 썼어요.
prd를 읽어보면 분류와 집계는 사실 기술적으로 크게 문제가 되지 않을것 같아 수집의 문제를 해결하고 싶어
이 한마디로 프로젝트의 중심축이 잡혔습니다. "수집이 진짜 난제"라는 결론과 함께, "수집의 불가능한 삼각형"(자동화·정보량·개인 접근성을 동시에 만족할 수 없음)이라는 개념까지 AI와 함께 도출했습니다. 한국 금융 API는 개인이 못 쓰고, 스크래핑은 위험하다는 것도 이때 정리했죠.
핵심은 "코드부터 짜지 말고, 문제를 끝까지 좁히는 데 AI를 쓴 것"입니다.
2일차 — 검증: 추측 대신 실데이터를 AI에게 까보게 하다
설계도를 그리기 전에, "이 수집이 진짜 되는지"를 실제 제 데이터로 검증했습니다. 뱅크샐러드에서 1년치 엑셀을 받아 AI에게 열어보게 했어요.
작업 이어서 시작
AI가 1,761건을 직접 파싱해서 구조를 분석했습니다. 그리고 여기서 채널마다 되는 게 다 다르다는 걸 하나씩 확인했어요. 카드사 앱엔 진짜 가게 이름이 살아있었고(뱅크샐러드가 넘겨받으며 뭉갠 것), 네이버페이만은 카드사에서도 "네이버"로만 보였습니다. 막힌 줄 알았던 맥(Mac)의 문자 데이터를 우회로로 열어보니 —
신한 해외승인 110달러 CLAUDE.AI
가게 이름·금액·시각이 그대로 다 있었습니다. 뱅크샐러드가 "인터넷쇼핑몰결제"로 뭉갠 바로 그 정보의 원본이었죠. 네이버페이는 문자가 아니라 영수증 조회 엑셀에 상품명·금액·시각이 있었고, 뱅크샐러드 내역과 결제 시각(초 단위)으로 1:1 매칭된다는 것까지 6건 전부 검증했습니다.
마지막으로 제가 전체 그림을 제안했습니다.
그럼 뱅샐 엑셀을 기준으로 신한 현대카드의 내용 및 네이버 페이 내용으로 대치해서 뱅셀 엑셀을 기준으로 하면 어떨까?
뱅크샐러드는 모든 거래가 빠짐없이 들어있으니 "기준"으로 삼고, 뭉개진 가게 이름만 카드 문자·영수증에서 가져와 채운다— 이 구조가 확정됐습니다. "전부 모으는 일"과 "정확한 이름을 채우는 일"을 각각 잘하는 데이터에 맡긴 거죠.
3일차 — 구현: 하루 만에 돌아가는 앱을 만들다
드디어 구현. 여기서 AI 활용의 핵심 기법이 나옵니다. "큰 작업을 여러 개의 작은 조각으로 쪼개, AI가 하나씩 완성하고 스스로 검증하게" 하는 방식(Subagent-Driven)을 골랐어요.
1번 Subagent-Driven으로 진행해줘
AI가 전체를 13개 조각으로 쪼갠 뒤, 각 조각을 완성하고 → 테스트를 돌려 통과를 확인하고 → 다음으로 넘어갔습니다. 마치 여러 명의 개발자가 한 조각씩 맡아 끝내고 합치는 것처럼요. 반나절 만에 수집 → 자동 분류 → 대시보드 → 규칙 관리까지 하나의 앱으로 완성됐습니다(27번의 저장).
이 앱에서 제가 가장 원했던 건 "내 맘대로 분류 규칙 만들기"였습니다. 미분류 거래 하나를 "카페"로 지정하면, 그 자리에서 규칙이 만들어지고 과거의 같은 거래들까지 전부 소급 자동 분류됩니다. "노가다 한 번 = 영구 자동화"인 셈이죠.
"오!" 한 순간은 AI가 자기 코드를 다시 검토하다 위험한 버그를 스스로 잡은 겁니다. 새 규칙이 기본 내장 규칙까지 실수로 덮어쓸 수 있는 구조였는데, "이건 심각한 문제"라고 스스로 표시하고 고쳤어요. 혼자 짰다면 몰랐을 함정이었습니다.
막혔던 순간도 있었습니다. 다 만들고 나서 정작 제가 못 썼거든요.
만든앱의 사용을 어떻게 해야할지 모르겠어
파일을 올렸는데 화면에 안 떠서 헤맸는데, 데이터가 다른 달에 들어가 있던 거였어요. AI가 "업로드하면 데이터 있는 최신 달로 자동 이동"하게 고쳐줬고, 그제서야 1년치가 쫙 떴습니다. 또, 특정 카드가 어느 순간부터 데이터에서 빠지는 "구멍"을 앱이 먼저 경고하도록 만들었습니다("이 카드 요즘 거래가 확 줄었어요").
4일차 — 확장: 검색 API·AI·카드 명세서로 미분류를 공략하다
앱은 돌아가는데 미분류가 여전히 수백 건이었습니다. 하나씩 검색해 분류하다 문득 물었어요.
우선 미분류 항목에 대해서 가맹점을 기준으로 웹서치로 찾아서 카테고리를 정해주고
이것을 서비스적으로 구현하다면 api를 연결해서 해야하나?
여기서 이 프로젝트에서 가장 중요한 설계 결정이 나왔습니다. 검색 API로 40개를 테스트해보니, 짧은 가게 이름이 엉뚱한 곳에 매칭되는 함정이 있었어요. 그대로 자동 반영했다면 오분류가 쏟아졌을 겁니다. 그래서 —
AI/검색이 "이건 아마 카페일 거예요"라고 제안 배지만 띄우고, 제가 클릭해 승인하면 그제서야 분류되고 규칙으로 승격되는 구조로 잡았습니다. 자동화의 편함과 사람의 판단을 둘 다 가져간 거죠. 동네 가게는 네이버 지역검색 API가, 교육·투자·온라인처럼 검색에 안 나오는 건 무료 AI(Gemini)가 제안하게 했는데, 핵심은 같은 "제안→승인" 구조를 두 소스에 그대로 재사용한 겁니다.
카드 할부 결제는 원본 명세서를 봐야 했는데, 그 파일이 비밀번호로 암호화돼 있었습니다.
보안 파일이라고는 하지만 내 생년월일이라 api키처럼 비공개에 깃허브에 공유가 되지 안도록 생년월일 6자리만 저장해서 사용하면 안되나?
AI가 분석해보니 그 암호화는 내 컴퓨터 안에서만 풀리는(서버로 안 보내는) 방식이었어요. 그래서 브라우저 자동화로 비밀번호를 안전하게 자동 입력해 명세서를 열고 진짜 가게 이름을 끌어왔습니다(비밀번호는 채팅이 아니라 별도 파일에 저장).
실패담도 있었습니다. 기능 테스트용 가짜 데이터에 실제 제 거래를 그대로 복사해 넣었다가, AI 검토가 "심각한 개인정보 유출 위험"으로 잡아냈어요. 급히 전부 익명 처리했습니다. 테스트 데이터는 반드시 지어낸 값으로 — 편하다고 실제 데이터를 복사하면 어딘가에 남습니다. 이날 미분류를 20%까지 줄였습니다.
5일차 — 완성: 마지막 수동 작업을 없애고, 성과를 숫자로
마지막 남은 수동 작업(네이버페이 영수증을 매달 손으로 받기)을 없앴습니다.
대시보드 파일업로드에서 실행 ui 버튼을 만들어줘
AI가 브라우저를 자동 조종해 사이트 접속 → 기간 지정 → 엑셀 받기 → 앱 반영까지 대신하게 만들었어요. 처음엔 사이트가 "너 로봇이지?"라며 막았지만(봇 감지), 접속 방식을 진짜 브라우저처럼 조정하고 실제 화면에서 버튼을 하나씩 검증하며 뚫었습니다. 이제 버튼 한 번(또는 명령어 한 줄)에 12개월치가 무인 수집됩니다.
그리고 "미분류"의 정의를 다시 세웠습니다. 카드값 출금·본인 계좌 이체는 자동 딱지를 붙여 집계에서 빼고, 전세금 같은 큰돈은 "지출 아님" 버튼으로 제외했어요. "무엇을 지출로 볼 것인가"를 명확히 하니 통계가 진짜 제 소비를 반영하게 됐습니다.
이 프로젝트를 사람들에게 발표해야 했기에, 가장 공들인 건 성과를 숫자로 만드는 일이었습니다.
그 후로 각 과정마다 미분류율이 얼마나 줄었는지도 다시 계산해줘
계산은 수동의 경우 로컬api및 ai 제안을 했을때를 가정을하고 그리고 네이버페이 내용도 추가해서 계산해야지
두 가지를 계산했어요. ① 실제로 분류된 결과(55.7% → 13.8%)와, ② "내가 손으로 한 걸 AI·검색에 맡겼다면 어땠을까"라는 반사실 계산. 덕분에 "이만큼은 사람 없이 자동으로 잡혔고, 약 5%p(95건)는 사람의 맥락이 꼭 필요했다"가 선명하게 나왔습니다. 두루뭉술한 "많이 좋아졌어요"가 아니라 단계별 숫자로 증명한 거죠.
실패담 하나 더 — AI 제안을 돌리다 갑자기 멈췄는데, 무료 AI(Gemini)가 "무제한"이라 광고돼 있었지만 실제로는 하루 20번이 한도였습니다(직접 부딪혀 확인). "무료"의 진짜 조건은 광고가 아니라 써봐야 안다는 걸 배웠어요.
✅ 결과 (After) — 데모가 아니라 매일 쓰는 앱
Before vs After
항목
Before
After
형태
시중 앱 + 답답함
내 컴퓨터에서 매일 쓰는 개인 앱
분류
내 맘대로 못 바꿈 · 62% 미분류
지정 1번 → 규칙화 → 과거 소급
미분류율
55.7%
13.8% (단계별로 감소)
가게 이름
간편결제가 가림
카드 문자·영수증·명세서로 복구
영수증 수집
매달 손으로 다운로드
버튼 한 번 · 12개월 무인 수집
데이터 구멍
나도 모르게 지출 누락
앱이 먼저 경고
성과 측정
"많이 좋아짐"(감)
반사실 계산으로 숫자 증명
결과물의 완성도 (실제로 쓸 수 있는가)
수집 4소스 자동화: 뱅크샐러드(백본) + 신한/현대 카드 명세서 + 네이버페이 영수증 자동 수집
분류 2단 제안: 네이버 지역검색 + Gemini AI → 배지 승인 → 규칙 자동 승격·소급
안정성: 자동 테스트 173개 전부 통과 · 실거래 유입 사고를 AI 검토로 차단·익명화
데모용이 아니라 제 실제 1년치 지출을 돌리는 도구입니다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
AI를 코드 짜는 손이 아니라 "사고 파트너"로 먼저 쓴다. 이틀을 문제 분해에 썼더니, 구현이 하루로 끝났습니다.
추측하지 말고, 실제 데이터를 AI에게 까보게 한다. "엑셀 열어서 뭐가 들었는지 보여줘"가 어떤 가정보다 정확했습니다.
큰 걸 잘게 쪼개 시키고, 만든 걸 다시 검토시킨다. AI가 자기 코드를 비판적으로 보게 하면 위험한 버그를 스스로 잡습니다.
AI 제안은 "자동 실행"이 아니라 "사람이 승인하는 초안"으로. 정확성과 자동화를 둘 다 가집니다.
성과를 반사실로 증명한다. "AI 없이 했다면?"을 계산하면 가치가 숫자로 보입니다.
이렇게 하면 안 돼요
한 번에 다 시키지 않기. 통째로 시키면 어디서 틀어졌는지 알 수 없습니다.
AI가 자동으로 확정하게 두지 않기. 짧은 이름이 엉뚱하게 매칭되는 함정이 실제로 있었습니다.
테스트에 실제 데이터 복붙 금지. 개인정보가 코드 이력에 남습니다.
비밀번호·API 키를 채팅에 넣지 않기. 반드시 별도 파일로 분리하세요.
무료 서비스의 "무제한"을 믿지 않기. 한도는 직접 부딪혀 확인하세요.
🌍 다른 업무에 적용한다면? — 그대로 옮기는 플레이북
이 프로젝트는 "가계부"였지만, 뼈대는 "흩어진 데이터를 모아 내 기준으로 반복 분류·정리하는 모든 업무"에 그대로 적용됩니다. 다섯 가지 패턴으로 정리했습니다.
흩어진 데이터 통합 + 내 규칙 자동 분류 — 여러 쇼핑몰 주문내역 취합, 거래처별 영수증 정리, 고객 문의 유형 분류. "한 번 지정하면 규칙이 되어 다음부터 자동"이 되게 만드세요.
기준(SSOT) + 보강(enrich) 분리 — 완전한 원본 하나를 "기준"으로 두고, 빠진 정보만 다른 소스에서 채웁니다. "전부 모으기"와 "정확히 채우기"를 각각 잘하는 데이터에 맡기는 것.
AI 제안 → 사람 승인 — 문서 태깅, 데이터 분류, 초안 작성 어디든. AI가 판단하되 최종 확정은 사람이 클릭 한 번으로.
브라우저 자동화로 반복 수집 제거 — 매달 여러 사이트에서 자료를 손으로 받는 일을 버튼 하나로.
반사실로 성과 증명 — 자동화 효과를 보고할 때 "안 썼다면 얼마나 걸렸을지"를 숫자로 만들면 설득력이 생깁니다.
핵심 한 줄: "코드부터 짜지 말고, ① 문제를 뾰족하게 좁히고 → ② 실데이터로 검증하고 → ③ 잘게 쪼개 AI에게 시키고 → ④ AI 제안을 사람이 승인하는" 순서. 이건 개발이 아니라 일하는 방식입니다.
🚀 앞으로의 계획
남은 미분류(사람의 맥락이 꼭 필요한 약 5%)를 다듬고, 매달 자동으로 갱신되게 만들 계획입니다. 무엇보다 이 경험 자체가 — 비개발자도 AI와 함께라면, 막막한 아이디어에서 매일 쓰는 도구까지 5일이면 간다는 증거가 됐습니다. 다음엔 이 뼈대를 다른 반복 업무에도 옮겨볼 생각입니다.
📋 재사용 가능한 프롬프트 (복붙해서 바로 쓰세요)
프롬프트 1: 문제를 뾰족하게 좁히기
지금 [겪는 문제 — 예: 데이터 정리가 오래 걸림]를 해결하고 싶어. 코드부터 짜지 말고, 이 문제를 단계로 쪼개서 어디가 진짜 병목인지, 그게 알고리즘 문제인지 정보(데이터) 문제인지 근본 원인부터 진단해줘.
프롬프트 2: 추측 대신 실데이터로 검증하기
이 [파일/데이터]를 열어서 어떤 항목이 있고 샘플이 어떻게 생겼는지 보여줘. 그리고 [하려는 일]에 이 데이터를 쓸 수 있는지, 부족한 정보는 없는지 분석해줘.
프롬프트 3: 큰 작업을 잘게 쪼개 시키고 자기검토까지
[만들 것]을 한 번에 다 하지 말고, 작은 작업 단위로 쪼개서 하나씩 완성하고 테스트로 검증한 뒤 다음으로 넘어가는 방식으로 진행해줘. 다 만든 뒤엔, 처음 보는 깐깐한 리뷰어의 눈으로 위험한 부분을 심각도별로 다시 검토해줘.
프롬프트 4: AI 제안을 "승인제"로 안전하게 쓰기
[분류할 항목]을 AI가 자동으로 확정하지 말고, "이건 아마 ○○일 거예요"라고 제안만 하게 해줘. 내가 클릭해 승인하면 그때 반영되고, 다음부터 자동 적용되는 규칙으로 만들어줘.
프롬프트 5: 반복 수집을 브라우저 자동화로
[사이트]에서 [데이터]를 매번 손으로 받는데, 브라우저 자동화로 대신 받게 해줘. 실제 화면에서 어떤 버튼을 눌러야 하는지 검증하면서 정확도를 높여줘.
프롬프트 6: 자동화 성과를 숫자로 증명
[작업]을 각 단계별로 적용하면서 [지표]가 얼마나 개선됐는지 단계별로 계산해줘. "내가 수동으로 한 부분을 AI에 맡겼다면 어땠을지"도 가정해 반사실 비교로 정리해줘. 발표용이야.
※ 모든 프롬프트의 [대괄호] 부분은 본인 상황에 맞게 바꿔서 쓰세요. 비밀번호·API 키는 채팅에 넣지 말고 별도 파일에 저장하는 걸 잊지 마세요.
소개
요즘 AI 캐릭터 채팅 서비스는 정말 많은데, 대화가 길어질수록 장면은 사용자가 계속 상상해야 한다는 아쉬움이 있었습니다.
그래서 "캐릭터와 나눈 대화가 매 턴마다 바로 장면 이미지로 이어지면 몰입감이 달라질까?"라는 질문으로 LorAI를 만들기 시작했습니다.
지금 만든 것은 AI 캐릭터와 대화하면 현재 대화 흐름에 맞는 장면 이미지를 생성하고, 캐릭터별 LoRA로 얼굴과 분위기를 최대한 유지하는 서비스입니다. 텍스트 채팅이 비주얼노벨처럼 장면으로 이어지는 경험을 목표로 하고 있습니다.
진행 방법
처음에는 단순히 캐릭터 채팅에 이미지 생성을 붙이는 정도로 생각했는데, 막상 해보니 어려운 지점은 세 가지였습니다.
1. 같은 캐릭터처럼 보이게 유지하기
캐릭터별 LoRA를 붙여서 얼굴과 분위기를 최대한 고정하려고 했습니다. 매번 예쁜 이미지를 만드는 것보다 "이 캐릭터가 계속 같은 인물로 느껴지는가"가 더 중요했습니다.
2. 대화 맥락을 장면 프롬프트로 바꾸기
사용자의 말과 캐릭터 답변을 그대로 이미지 프롬프트로 쓰면 장면이 산만해졌습니다. 그래서 현재 턴에서 중요한 장소, 감정, 행동만 뽑아 장면으로 바꾸는 쪽으로 조정했습니다.
3. 첫 30초의 이해 문제
기능은 붙었는데, 처음 들어온 사람이 이게 AI 채팅인지, AI 그림 서비스인지, 캐릭터 플랫폼인지 바로 이해하지 못하면 첫 채팅까지 가지 않고 나가더라고요. 지금은 기능 추가보다 첫 화면, 첫 대화, 첫 장면까지의 흐름을 더 보고 있습니다.
결과와 배운 점
아직 유저는 거의 없고, 솔직히 말하면 파리 날립니다. 그래도 만들면서 배운 건 분명했습니다.
AI 캐릭터 서비스에서 이미지는 단순한 보너스가 아니라, 대화의 감정선을 잡아주는 장치가 될 수 있습니다. 다만 이미지 품질보다 중요한 건 "언제 보여주느냐", "캐릭터가 일관되게 느껴지느냐", "첫 화면에서 이 차별점이 바로 이해되느냐"였습니다.
피드백 받고 싶은 부분
- 첫 화면에서 "대화가 장면이 된다"는 포지션이 바로 이해되는지
- 로그인 없이 체험하는 흐름이 자연스러운지
- 매 턴 장면 생성이 실제 몰입에 도움이 될 것 같은지
- 첫 채팅 전 이탈할 만한 지점이 어디인지
전체 소개:
https://lorai.me/welcome
로그인 없이 바로 체험:
https://lorai.me/landing
Google Play:
https://play.google.com/store/apps/details?id=com.supermon.romance
홍보라기보다 초기 제품 피드백 요청에 가깝습니다. GPTers 분들 관점에서 날카롭게 봐주시면 정말 도움이 됩니다.
소개
왕초보지만 새내기 강사로서 가끔 일해보면, 정작 힘든 건 강의 그 자체가 아니라 매번 똑같이 반복되는 '준비' 더라고요. 주제 잡고 → 순서 짜고 → 자료 만들고 → 끝나면 설문 받고 → 감사 메일 보내고… 강의 한 번 할 때마다 이걸 처음부터 손으로 다시 합니다.
그래서 마음먹었습니다. "이 반복 준비를 AI한테 맡기고, 나는 핵심(전문 내용)에만 집중하자."
이 글은 특정 강의 자랑이 아니라, 강사가 AI로 강의 준비를 어떻게 짜고, 어떻게 점점 자동화해 가는지에 대한 솔직한 기록입니다. 얼마 전 한 공인중개사 대상 강의(2시간)를 첫 실험 대상으로 삼아, 준비부터 강의 후 마무리까지 전부 AI와 함께 해봤어요.
세 가지만 보시면 됩니다 — (1) AI로 준비를 어떻게 했나, (2) 강의 후 피드백을 어떻게 받아 써먹었나, (3) 이걸 정말 자동화했나(어디까지 됐고, 나머지는 어떻게 하고 있나).
참고로 쓴 도구는 딱 4개입니다: NotebookLM(내가 넣은 자료에만 근거해 답하는 구글 AI), 클로드(Claude)(글·분석·자동화를 시키는 AI 비서), Gamma(슬라이드 — 클로드와 연결해 자동 생성), Vercel(만든 웹페이지를 무료로 올리는 곳).
진행 방법
0) 준비 — AI(클로드)가 NotebookLM을 '대신 조작'하게 연결
먼저 NotebookLM을 클로드가 직접 다루게 연결해뒀습니다. 그래야 "내가 웹을 일일이 클릭"하는 대신 "이 노트북에 자료 넣고 요약해줘"라고 말로 시킬 수 있거든요. nlm이라는 작은 도구를 깔고 → 구글 로그인 한 번 → 클로드에 연결. 끝나면 클로드가 NotebookLM을 알아서 부립니다. (터미널에 아래 세 줄만 입력)
# 1) nlm 설치 (Go 환경 필요)
go install github.com/tmc/nlm/cmd/nlm@latest
# 2) 구글 로그인 (브라우저로 인증 — 세션은 약 20분)
nlm login
# 3) 클로드(Claude Code)에 nlm 연결
nlm skill install claude
1) AI로 '기획'부터 — 자료보다 '한 문장'이 먼저
자료부터 만들지 않았습니다. AI와 같이 강의를 관통하는 한 문장부터 정했어요 — "AI는 검색이 아니라, 내가 준 자료에서만 답하는 비서다."
이 한 문장을 기준으로 강의 순서를 짰습니다(공인중개사 활용 6가지 → 그중 라이브 시연 3개 → 2시간 분 단위 진행표). 이 한 문장이 모든 자료의 나침반이 됐습니다.
2) 자료는 '한 번 만들고 계속 쓰게' 만들기
핵심은 자료를 그냥 만든 게 아니라, 다음 강의에 또 쓸 수 있게 만든 점입니다.
자료 창고(NotebookLM 노트북) 3개에 소스 73개를 채우고, 자료 이름 앞에 [교통] [단지] [정책]처럼 라벨링(자동가능)를 붙여 한눈에 보이게 정리했습니다.
[그림1 — 노트북을 연 화면의 왼쪽 '소스(자료)' 패널. 자료 47개가 라벨링되어 정렬된 모습]
핸드아웃·QR·포스터 같은 건 매번 손으로 안 만들고, 간단한 자동 변환기(작은 프로그램)로 똑같이 찍어내게 해뒀어요. 다음 강의 땐 내용만 바꾸면 그대로 나옵니다.
발표 슬라이드 38장도 직접 안 만들었어요. 클로드와 Gamma(AI 슬라이드 도구)를 연결해서, 강의 구조와 내용을 넘기면 슬라이드를 통째로 자동 생성했습니다. 디자인·장표 배치까지 알아서 — 손으로 만들었으면 며칠 걸릴 걸 한 번에. (세부 수정만 Gamma에서 다듬음)
그 밖에 핸드아웃 1장, 시작용 미니 퀴즈(웹페이지로 만들어 무료 웹에 올림), QR 5종 + 입구 포스터 2종, 오디오 요약, 지역 분석 보고서, 강사용 진행 대본·리허설·체크리스트, 강의 후 메일 5종까지 한 세트로 준비했습니다.
[그림2 — 시작용 미니 퀴즈 화면]
[그림3 — 입구 QR 포스터 2종]
3) 강의에서 — "AI는 안 지어낸다"를 눈으로 보여주기
시연은 단순했습니다. 질문을 그 자리에서 입력 → AI 답에 붙은 출처 번호 [1]을 클릭 → 원본 자료의 그 문장이 형광펜처럼 표시되는 걸 보여줬어요. "보세요, 지어낸 게 아니라 제가 넣은 자료 여기서 가져온 겁니다." 실제로 이렇게 물었습니다:
도안 신도시 권역의 주요 단지들을 비교하고, 30~40대 가족 단위 매수
희망자에게 가장 적합한 단지를 추천해줘. 시세·학군·교통·미래가치를
종합하고 2026년 정책·호재 변수도 포함해줘.
법규·세무 시연(반응이 제일 좋았어요)에선 전세 갱신 거절 사유를 법 조항과 함께, 실제 분쟁 해결 사례(합의금 100만원) 까지 원문으로 보여줬습니다.
[그림4 — 출처 클릭 시 원문 표시]
4) 강의 후 — 설문을 '보고서'로 자동 정리
강의 끝에 구글폼 설문을 받고, 그 응답을 클로드에게 주면서 보기 좋은 결과 보고서(웹 대시보드)를 자동으로 만들게 했습니다. 이렇게 구체적으로 시키면 알아서 정리해줘요:
구글폼 응답을 정리해서, 만족도·참석자 수준·후속 관심 주제·지역·
수신 동의율·주관식 의견을 집계하고, 보기 좋은 차트가 들어간
대시보드 웹페이지로 만들어줘.
결과로 "매물·시세 자동화"가 후속 관심 1위(11명) 로 나왔고, 이게 바로 다음 강의 주제가 됐습니다. 감사 메일도 AI가 초안까지 만들었고요(단, 보내기 버튼은 제가 직접 눌렀습니다 — 밖으로 나가는 건 꼭 사람이 확인).
[그림5 — 결과 대시보드(이름은 가림)]
5) 그래서, 자동화는 어디까지 됐나? (절반은 완성, 절반은 진행 중)
한 번에 다 자동화하려다 오히려 꼬여서, 자주 반복되고 확실한 것부터 자동으로 굳히고, 중요한 길목엔 사람이 한 번씩 확인하는 방식으로 갔습니다. 위 과정을 클로드에 '자동 절차(스킬)'로 등록해서, 이제 딱 5가지(주제·대상·날짜·시간·장소)만 입력하면 준비물 한 세트가 나오게 만들었어요. (클로드에서 /lecture라고 부르면 실행됩니다.)
단계
무엇
지금 상태
기획서 만들기
강의 순서·구성
✅ 자동
실습 자료 만들기
프롬프트 카드·예제
✅ 자동 + 여러 관점으로 깐깐히 점검해 통과할 때까지 고침
발표 슬라이드
38장
✅ 클로드↔Gamma 연결로 자동 생성
핸드아웃·QR·포스터
인쇄물
🔧 자동 변환기로 찍어냄
자료 창고(NotebookLM)
노트북·소스·오디오
🖐→🔧 연결은 됨, 완전 자동은 진행 중
준비 안내문
현장/온라인 체크리스트
✅ 자동
피드백 정리
설문→대시보드
✅ 자동 (이미 검증)
감사 메일
초안 작성
✅ 초안 자동(발송은 사람)
다음 강의로 잇기
피드백→다음 기획
✅ 자동
전체 한 번에
5가지 입력→준비물 한 세트
✅ 만듦 / ⏳ 실제 강의 적용은 다음 강의에서
[그림6 — 자동으로 만들어진 실습 프롬프트 카드]
한마디로 — 강의 '내용'은 매번 새로 만들지만, '준비하는 절차'는 그대로 재사용합니다. 이 재사용되는 뼈대가 제가 만드는 '강의 공장'이에요.
6) 다른 주제·다른 지역에서도 똑같이 될까? (재현하는 법)
가장 궁금하실 부분이죠. 예를 들어 "부산에서, 상가 임대차 분쟁 대응" 으로 주제·지역이 바뀌어도 같은 품질로 만들려면 — 이렇게 하면 됩니다.
① 딱 한 줄 입력
/lecture new "상가 임대차 분쟁 대응" "부산 공인중개사" "2026-08-22" "19:00-21:00" "부산 OO센터"
→ 폴더·기획서·진행표가 충청 때 틀 그대로 자동으로 잡힙니다.
② 사람이 할 건 딱 하나 — 그 주제 자료 넣기 NotebookLM에 그 지역·그 주제 자료(부산 상권, 상가임대차보호법, 지역 분쟁 사례 등)를 넣습니다. 여기에만 강사의 전문성이 들어가고, 나머지는 자동입니다.
③ 나머지(자료·인쇄물·점검)는 자동, 품질은 '점검 단계'가 지켜줌 프롬프트 카드·예제·안내문·QR·퀴즈는 자동으로 만들어지고, 여러 관점(내용이 맞나·개인정보 새나·따라하기 되나·시간 맞나)으로 깐깐히 점검해 통과할 때까지 고칩니다. 주제가 바뀌어도 점검 기준은 똑같으니 품질이 들쭉날쭉하지 않아요.
④ 강의 후도 똑같이 — 설문 → 대시보드 → 감사 메일 → 다음 기획으로.
그래서 품질이 일정한 이유는 3가지입니다:
틀(템플릿)이 같다 — 기획서·카드·대시보드·안내문 형식이 매번 동일
점검 단계가 같다 — 주제가 달라도 같은 잣대로 오류를 거름
체크리스트 + 사람 확인 — 빠뜨림·사고(공유 설정, 메일 오발송 등) 방지
솔직한 한계 — '버튼 누르면 끝'은 아닙니다. 어떤 자료를 넣을지, 그 주제를 제대로 아는 건 강사 몫이에요. NotebookLM은 내가 넣은 자료에서만 답하니까, 자료가 부실하면 결과도 부실합니다. 그러니까 이건 "전문성은 사람이, 반복은 AI가" 나눠 맡는 구조예요. 품질은 결국 강사 실력만큼 나오고, AI는 그 실력을 빠르고 일정하게 재현해주는 역할입니다.
결과와 배운 점
결과(숫자)
이 방식으로 준비한 첫 강의: 만족도 4.67/5, 5점 만점 비율 87%(15명), 후속 자료 받겠다는 동의 100%
강의 후 설문 정리 → 대시보드 → 감사 메일까지 반나절 안에, 다음 강의 기획까지 이어짐
초보 강사님께 드리는 꿀팁
자료부터 만들지 마세요. '한 문장(핵심 메시지)' → 순서부터. 그래야 자동화할 틀이 생깁니다.
AI를 못 믿는 청중에겐 출처 클릭 한 번이 백 마디 설명보다 셉니다(안 지어낸다는 걸 눈으로).
매번 만드는 인쇄물은 자동 변환기로 찍어내게 해두면 다음 강의가 편합니다.
강의 후 후속은 빠를수록 신뢰가 쌓입니다(24시간 약속 지키니 동의율 100%).
시행착오(겪고 배운 것)
NotebookLM 노트북은 처음엔 '나만 보기'라, 메일에 링크 넣어도 수강생이 못 열 뻔 → '링크 아는 사람 보기'로 바꾸기를 발송 전 체크리스트에 넣었습니다.
AI가 만든 실습 자료에 숫자가 살짝 안 맞는 부분이 있었는데, 점검 단계에서 걸렸어요 → "AI가 만든 자료는 꼭 점검을 거쳐야 한다"를 절감.
처음엔 욕심내서 전부 자동화하려다 꼬였습니다 → 확실한 것부터 자동, 중요한 길목은 사람 확인으로 바꾸니 안정됐어요.
도움이 필요한 부분
NotebookLM을 명령어(nlm)로 완전 자동(노트북 만들고 자료 넣는 것까지)으로 돌리는 부분을 다듬는 중입니다. 비슷하게 해보신 분 팁 환영합니다!
앞으로의 계획
다음 실제 강의(서울 해커스 학원, 해공회 공인중개사 대상)에 이 '강의 공장'을 처음부터 끝까지 그대로 돌려 현장에서 검증해볼 예정입니다.
도움 받은 글 (옵션)
이번 글은 직접 해본 사례이고, 아래는 같은 주제를 더 파보실 분께 도움 될 자료입니다. (전부 정독한 건 아니고, 방향 잡기용 추천이에요.)
🛠 NotebookLM을 명령어로 다루는 도구
tmc/nlm — 제가 쓴 도구. NotebookLM을 터미널 명령으로 다루고, AI에 바로 연결됩니다.
jacob-bd/notebooklm-mcp-cli — 비슷한 도구의 통합 버전(설치가 간단).
⚖️ AI에 도구를 어떻게 붙일까 (CLI vs MCP — 좀 더 기술적인 분께)
MCP vs CLI for AI Agents (Firecrawl, 2026) — 둘은 경쟁이 아니라 보완 관계라는 정리. 쉽게: 명령어 방식은 가볍고 빠르고, MCP 방식은 보안·연결 관리에 강함.
CLI Tools vs MCP — 명령어 방식의 장점을 정리한 글.
▶️ NotebookLM으로 교육·강의 자료 만들기 (영상)
구글 NotebookLM으로 교육자료·홍보자료 만드는 방법 — 파일 여러 개 넣어 교육자료 뽑는 흐름.
노트북LM 실전 활용법 12가지 — 입문자가 감 잡기 좋은 정리.
# AI가 마케팅 컨설팅까지? — 전환율 최적화로 수임률 높이기
## 📝 한줄 요약
법률 웹앱 론칭 마지막 날, AI가 마케팅 컨설턴트 역할까지 수행하며 전환율 최적화(CRO) 리뷰, 콘텐츠 미세조정, 모바일 최적화를 완료해 실전 투입 가능한 서비스를 완성했습니다.
바쁘시면 이것만 읽어도 돼요:
- AI에게 "마케팅 관점에서 검토해줘"라고 했더니, 전환율 최적화(CRO) 전문 컨설팅 수준의 리포트를 작성하고 직접 개선까지 적용
- 개인정보 처리방침, 리포트 예시 갤러리, 결제 후 안내 메시지 등 실전 운영에 필요한 디테일을 하루 만에 완성
- "콘텐츠 수정 → CRO 점검 → 불일치 수정 → 재점검" 루프를 AI가 자율적으로 반복 수행
- 4일간의 작업 결론: 작게 나눠서 시키고, 결과를 확인하고, 다시 시키는 것이 핵심
- 아버지(안장근 변호사)께서 결과에 만족하시며 실제 운영 시작을 결정하셨다
## 🎯 이런 분들께 도움돼요
- AI로 웹사이트 마케팅 최적화를 해보고 싶은 분
- "코딩은 됐는데, 실제 고객이 쓸 수준으로 다듬는 건 어떻게 하지?" 고민이 있는 분
- 법률 서비스 온라인화를 검토 중인 변호사
- AI 코딩 시리즈를 따라오신 분 (시리즈 최종편)
---
## 🔧 작업 과정
### 법률 서비스의 기본 — 개인정보 처리방침 (Task 19)
실제 서비스를 운영하려면 법적 요건부터 갖춰야 한다. 개인정보 보호법 준수가 필수다.
```
개인정보 보호법 준수를 위한 처리방침 페이지 추가해
```
이 한 마디로 AI가 제1조부터 제11조까지 전체 처리방침 페이지를 생성하고, 사건 접수 폼에 동의 체크박스까지 추가했다. OpenAI, Supabase, Vercel 등 실제 사용 중인 서비스의 처리 위탁 고지까지 알아서 포함한 점이 놀라웠다.
---
### 고객이 보는 것을 다듬기 — 설명과 예시 (Task 20~21)
무료 AI분석이 무엇인지, 종합 리포트가 어떤 것인지 고객은 모른다. 설명이 필요하다.
```
서비스 안내에 무료ai분석조회 설명란을 추가해. 무료이고 어떤 기능이 있는지를 정리해.
고객에게 어떤 이득을 줄 수 있는지에 대한 설명을 추가해.
```
```
종합 사건분석 리포트의 예제 사진이 들어가 있어. 순서대로 배열해서 사람들이 볼 수 있게 해.
사진을 클릭하면 확대해서 볼 수 있도록 해.
```
AI가 무료 분석의 혜택을 정리한 설명 블록과, 리포트 예시를 갤러리 형태로 배치하고 라이트박스(클릭 확대) 기능까지 구현했다. 고객이 "이 서비스가 뭔지" 바로 이해할 수 있는 구조가 완성됐다.
---
### 가장 인상적인 순간 — AI가 마케팅 컨설팅을 했다 (Task 22, 25)
이 프로젝트에서 가장 "오!" 했던 순간이다.
```
songmu-conversion-optimizer 를 사용해서 프로젝트를 검토해.
마케팅, 비즈니스, 고객 관점에서 다양한 제언을 해.
```
Claude Code에게 전환율 최적화(CRO) 전문 서브에이전트를 만들어서 웹사이트 전체를 분석하라고 시켰다. 그랬더니 AI가 마케팅 컨설턴트처럼 행동했다.
Phase 1 (즉시 개선) 4개 항목을 찾아서 바로 적용하고, Phase 2 (핵심 전환 최적화) 4개 항목까지 추가로 개선했다. CTA 버튼 위치, 신뢰 요소 배치, 서비스 설명 구조, 고객 행동 유도 흐름까지 — 마케팅 에이전시에 의뢰할 수준의 분석이었다.
여기서 끝이 아니다. 콘텐츠를 수정한 뒤 다시 CRO 점검을 시켰다.
```
songmu-conversion-optimizer 가 홈페이지를 점검해.
무료 ai 사건분석조회에 나와있는 설명을 제공하고 있는지 검토해.
```
AI가 "무료 AI분석 설명에 적힌 내용"과 "실제 서비스가 제공하는 기능"을 대조해서, 불일치 항목을 찾아 수정했다. 콘텐츠 수정 → CRO 점검 → 불일치 수정 → 재점검이라는 품질 루프를 AI가 자율적으로 돌린 것이다.
개발자가 아닌 내가 마케팅 전문가도 아닌데, AI 덕분에 전환율 최적화까지 할 수 있었다. 이것이 AI 코딩 도구의 진짜 가치라고 느꼈다.
---
### 고객 요청 반영 — 실시간 수정의 연속 (Task 23~24, 26~28)
아버지께서 결과를 보시면서 계속 의견을 주셨다. AI와의 작업은 이런 실시간 수정에 강하다.
```
제목을 '법률사건 AI무료분석서비스'로 수정해.
```
```
변호사의 의견이 들어간다는 점이 중요 포인트인 것 같아. 그 부분을 강조해.
```
```
입금 확인 후 메시지에 영업일 3일 이내에 변호사가 이메일로 리포트를 발송할 것이라고 해.
```
서비스 제목 변경, 변호사 직접 검토 강조, 결제 후 안내 메시지 개선, 변호사 프로필 업데이트까지 — 아버지의 한 마디 한 마디가 즉시 반영됐다. 외주 개발이었다면 수정 요청서를 작성하고 며칠을 기다려야 했을 것이다.
---
### 마무리 — 모바일 최적화와 브랜딩 완성 (Task 29~31)
```
모바일 최적화되었는지 확인해
```
모바일 점검을 시키고, 프로필 이미지를 정률 로고로 교체하고, OG 이미지(SNS 공유 썸네일)와 파비콘까지 설정했다. 누군가에게 링크를 공유했을 때 깔끔한 미리보기가 뜨도록 마무리한 것이다.
이로써 4일간의 전체 작업이 완료되었다.
---
## ✅ 결과 — 4일간의 Before vs After (전체 프로젝트)
| 항목 | Before (Day 0) | After (Day 4) |
|------|----------------|---------------|
| 사건 접수 방식 | 전화/방문, 변호사가 직접 질문 | 웹에서 4단계 가이드 질문으로 셀프 접수 |
| 사건 내용 정리 | 수기 또는 구두 | AI 자동 요약/분류/핵심 쟁점 파악 |
| 관리 도구 | 없음 | 관리자 대시보드 (상태/파일/삭제 관리) |
| 마케팅 최적화 | 없음 | AI CRO 2회 점검 + 모바일 최적화 |
| 법률 준수 | 해당 없음 | 개인정보 처리방침 + 동의 절차 완비 |
| 브랜딩 | 없음 | OG 이미지, 파비콘, 변호사 프로필 완성 |
| 보안 | 해당 없음 | CSRF/CSP/HSTS/JWT 보안 검토 완료 |
| 개발 비용 | 외주 시 수백만원 | 4일, AI와 비개발자 1명 |
| 운영 상태 | 구상 단계 | 실전 투입 결정 |
---
## 📚 4편 시리즈 요약
| 편 | 주제 | 핵심 내용 |
|----|------|-----------|
| 1편 | 하루 만에 웹앱 만들기 | 기획서 한 장으로 41개 파일 생성, 배포까지 완료 |
| 2편 | 브랜딩과 콘텐츠 개편 | 실제 법률사무소 정보 반영, 서비스 체계 정립 |
| 3편 | 서비스 체계와 관리 기능 | 가격/서비스 구조 확정, 관리자 기능 강화 |
| 4편 | 마케팅 최적화와 완성 | AI CRO 컨설팅, 콘텐츠 미세조정, 실전 투입 |
4일 동안 총 31개 작업을 수행했다. 프로젝트 스캐폴딩부터 마케팅 최적화까지, AI 코딩 도구 하나로 전부 해결했다.
---
## 💬 AI 활용 팁 — 최종 정리
### 이 시리즈에서 배운 핵심 3가지
1. 작게 나눠서 시키기 — "전부 만들어줘"보다 "이 부분만 수정해줘"가 결과가 좋다. 4일간 31개 작업으로 나눈 것이 성공의 핵심이었다.
2. 결과를 반드시 확인하기 — AI가 "했습니다"라고 해도 직접 화면을 확인하고, 안 되면 다시 시킨다. CRO 2차 점검에서 설명과 실제의 불일치를 잡아낸 것이 좋은 예다.
3. AI에게 역할을 부여하기 — "검토해줘"보다 "마케팅 전문가 관점에서 전환율을 높이는 방법을 제안해줘"라고 하면 훨씬 구체적인 결과가 나온다. songmu-conversion-optimizer 서브에이전트가 그 예다.
### Day 4에서 특히 효과적이었던 것
- 콘텐츠 → 점검 → 수정 → 재점검 루프: 한 번에 완벽할 수 없다. 반복이 품질을 만든다.
- 고객(아버지) 피드백 즉시 반영: AI 도구의 최대 장점은 수정 속도다. 피드백을 받고 5분 안에 반영할 수 있다.
---
## 🌍 다른 업무에 적용한다면?
이번에 검증된 "AI CRO 컨설팅" 패턴은 어떤 서비스 웹사이트에든 적용 가능하다.
- 병원/클리닉: 예약 페이지의 전환율을 AI가 분석하고, 환자 후기 배치/CTA 개선
- 쇼핑몰: 상품 상세 페이지의 구매 전환율 최적화, 결제 완료 메시지 개선
- 컨설팅/전문직: 서비스 설명과 실제 제공 내용의 일치 여부 자동 점검
- 교육/학원: 수강 신청 페이지의 신뢰 요소 배치, 모바일 최적화
핵심 패턴: "이 웹사이트를 [전문가 역할] 관점에서 검토하고 개선해줘" — 이 한 문장이면 AI가 해당 분야 컨설턴트처럼 동작한다.
---
## 🚀 앞으로의 계획
- 실제 고객 접수 데이터를 분석해서 접수 폼을 더 개선할 예정
- 고객 로그인 기능을 추가해서 사건 진행 상황을 직접 확인할 수 있도록
- 접수 후 자동 알림(이메일/카카오톡) 기능 도입 검토
- 운영 데이터가 쌓이면 AI 분석 정확도도 함께 개선해나갈 계획
아버지께서 "이제 실제로 써보자"고 하셨다. 4일 전 "이런 거 만들 수 있을까?"로 시작한 프로젝트가, 실전 투입 단계까지 왔다.
---
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: AI CRO 컨설팅 요청
> [서비스명]-conversion-optimizer를 사용해서 프로젝트를 검토해.
> 마케팅, 비즈니스, 고객 관점에서 전환율을 높이는 개선사항을 제안하고 적용해.
### 프롬프트 2: 콘텐츠 vs 실제 일치 점검
> 홈페이지에 적힌 서비스 설명과 실제 제공하는 기능이 일치하는지 검토해.
> 불일치하는 부분이 있으면 수정해.
### 프롬프트 3: 모바일 최적화 점검
> 모바일 최적화되었는지 확인해.
> 터치 영역, 폰트 크기, 레이아웃 깨짐 등을 점검하고 개선해.
### 프롬프트 4: 법률 준수 페이지 생성
> 개인정보 보호법 준수를 위한 처리방침 페이지를 추가해.
> 실제 사용 중인 외부 서비스(DB, AI, 호스팅)의 처리 위탁 고지를 포함해.
### 프롬프트 5: 브랜딩 마무리
> [이미지 파일]을 대표 썸네일(OG 이미지), 파비콘, 프로필 사진으로 설정해.
---
## 🖼️ 추천 이미지
게시물 업로드 시 아래 스크린샷을 첨부하면 효과적입니다:
1. CRO 검토 결과 화면 — AI가 전환율 개선사항을 분석한 터미널 출력 캡처 (AI가 마케팅 컨설팅을 한다는 핵심 메시지 전달)
2. Before/After 비교 — 랜딩 페이지의 Day 1 vs Day 4 상태 비교 스크린샷
3. 완성된 모바일 화면 — 모바일에서 접속한 최종 서비스 화면 캡처
4. 리포트 예시 갤러리 — 라이트박스로 확대된 종합 사건분석 리포트 예시 화면
---
## 📌 게시판 업로드 안내
- 제목: AI가 마케팅 컨설팅까지? — 전환율 최적화로 수임률 높이기
- 카테고리: AI 활용기 / 업무 자동화
- 태그: Claude Code, AI코딩, 비개발자, 전환율최적화, CRO, 법률AI, 마케팅자동화, 웹앱개발
- 시리즈 표기: [AI 코딩 실전기 4/4] — 시리즈 최종편임을 명시
- 본문 상단에 시리즈 링크 추가:
- 1편: 비개발자가 하루 만에 법률 웹앱을 만들었다
- 2편: 브랜딩과 콘텐츠 개편
- 3편: 서비스 체계와 관리 기능
- 4편: AI가 마케팅 컨설팅까지? (본 글)
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) 호출 부분이 인증 없이 열려 있는지, 무제한 호출 시 비용이 어떻게 청구되는지 짚고,
그럴듯한 방어(예: 출처 검증)가 우회 가능한지까지 냉정하게 검토해줘.
