https://notebooklm.google.com/notebook/ae3ee7ae-8eb8-46f9-a208-ec52e740450f
노트북 LM을 통해 딥 리서치 했던 사운드 제작 프로세스 직업에 대한 것을 여러가지로 정리하게 되었습니다.
마인드 맵 만들어주고 이런거 신기하더라구요
소개
바이브코딩으로 앱을 만들어 본 분이라면 아실 거예요. "되는 것 같은데... 진짜 되나?" 하는 찜찜함. 출시 전에 뭘 확인해야 할지 몰라서 그냥 올렸다가 사용자가 먼저 버그를 발견하는 일이요.
저는 코드를 직접 보지 않고 전부 AI한테 맡기는 쪽인데, 그래도 "내 앱이 해야 할 일을 하는가"는 확인할 수 있더라고요. 검증은 코드 실력이 아니라 "생각하는 방식"에 가깝거든요. 식당 위생 점검관이 요리할 줄 몰라도 점검하듯요. 제가 출시 전에 쓰는 체크리스트를 공유합니다.
진행 방법 — 3단계
1단계 · "꼭 돼야 하는 일"을 평범한 말로 적는다
기술 명세 말고, 사용자가 하는 행동을 적습니다. 초기 앱은 의외로 짧아요.
- 가입하고 로그인할 수 있다
- 우리 앱의 핵심 기능 한 가지를 할 수 있다
- 로그인 후 내 데이터를 볼 수 있다
- (결제가 있으면) 결제를 끝낼 수 있다
이게 끝입니다. 이게 당신의 테스트 계획이에요.
2단계 · 각 단계에 "성공한 모습"을 붙인다
"가입 버튼을 누른다"는 테스트가 아닙니다. "가입 버튼을 누르면 → 대시보드로 넘어가고 → 오른쪽 위에 내 이름이 보인다" 가 테스트예요. 성공한 모습을 정의해야 클릭이 점검이 됩니다.
3단계 · "조용한 실패"를 노린다
가장 위험한 건 화면은 멀쩡한데 속으로는 안 된 경우입니다.
폼은 제출됐는데 데이터가 저장 안 됨 / 결제는 됐는데 구독이 활성화 안 됨 / 메일은 발송됐는데 도착 안 함. 이건 화면만 봐서는 안 보입니다. 각 단계의 "성공한 모습"을 미리 정해놨을 때만 잡혀요.
손이 벅차지면
위를 매번 직접 하기 벅차지면 E2E 자동 검증 도구들이 사람처럼 클릭해서 대신 확인해줍니다(오픈소스 Autonoma 같은). 다만 이런 도구는 대체로 코드·터미널 흐름 위에서 돌아가서, 설치는 AI한테 맡기더라도 결과를 받아보는 자리가 개발 쪽에 가깝더라고요. 코드 안 보는 1인 운영자라면, 일단 위 3단계를 매번 빠짐없이 돌리는 습관부터가 큰 차이를 만듭니다.
결과와 배운 점
- 검증은 "모든 걸 다 확인"이 아니라 "제일 중요한 몇 개를 빠짐없이"입니다.
- "성공한 모습"을 정의하는 한 줄이 거의 전부를 결정해요.
- 완벽한 품질보다 "최소한 이건 된다"는 안심이 출시에는 더 중요하더라고요.
이 체크리스트가 도움 되면 좋겠어요 🙂
아침마다 이런 적 없으세요? 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가지: ① 각 줄에 원본 링크를 꼭 붙일 것 ② 원문에 없는 내용은 추론해서 라벨 달지 말 것 ③ 못 읽은 소스가 있으면 숨기지 말고 "⚠ 미확인"으로 표시할 것.
마지막에 "표시한 항목 수 = 실제 항목 수"가 맞는지 스스로 세서 알려줘.
[대괄호] 부분은 본인 상황에 맞게 바꾸세요.
한줄 요약
GPT-5.6은 OpenAI가 2026년 6월 26일 공식 프리뷰를 시작한 차세대 모델 시리즈로, 플래그십 Sol, 균형형 Terra, 경량 Luna 세 모델로 나뉩니다. 지금은 약 20개 파트너 기관만 쓸 수 있고, 일반 공개는 수주 내로 예고됐어요.
무슨 일이 있었나?
OpenAI가 6월 26일 GPT-5.6 시리즈의 제한 프리뷰를 발표했습니다. 이번 세대의 가장 큰 변화는 하나의 대표 모델이 아니라 용도별 3개 모델로 출발한다는 점입니다.
모델 포지셔닝 가격 (1M 토큰, 입력/출력)
Sol
플래그십, 최고 난도 추론·에이전트
$5 / $30
Terra
균형형, 일상 업무
$2.50 / $15
Luna
경량·고속, 대량 처리
$1 / $6
성능 지표로는 터미널 기반 에이전트 벤치마크인 Terminal-Bench 2.1이 먼저 공개됐습니다. Sol의 최상위 설정(Ultra)이 91.9%로 신기록을 세웠고, 중간급인 Terra도 80%를 넘겼습니다. 외신 정리에 따르면 Terra는 GPT-5.5급 성능을 절반 수준 비용으로 제공하는 포지션이고, Sol은 일부 코딩 에이전트 작업에서 Claude Mythos 5를 앞선 것으로 알려졌습니다.
접근 방식이 이례적입니다. OpenAI는 6월 2일 발표된 미국 행정명령에 따라 출시 계획을 미국 정부와 먼저 공유했고, 현재는 약 20개 신뢰 파트너 기관에만 모델을 열어둔 상태입니다. 안전성 검증에는 자동화 테스트로만 A100 GPU 70만 시간 이상을 투입했고, 자율적인 완전 익스플로잇 생성에는 도달하지 못해 사이버 위험 임계값 미달 판정을 받았다고 밝혔습니다.
속도 쪽 소식도 있습니다. OpenAI는 Cerebras 하드웨어에서 Sol을 최대 초당 750토큰으로 제공하는 파트너십을 7월에 시작합니다.
Photo by Taylor Vick on Unsplash
왜 중요한가?
첫째, 모델 라인업의 3단 분화가 업계 표준이 됐습니다. Anthropic의 Haiku·Sonnet·Opus, Google의 Flash·Pro 구도처럼 OpenAI도 가격과 성능의 3단 사다리를 명시적으로 채택했습니다. 이제 모델 선택의 질문은 "어느 회사가 최고인가"에서 "이 작업에 어느 단이 맞는가"로 바뀝니다.
둘째, 가격 경쟁이 중간 체급에서 붙습니다. Terra의 입력 $2.50는 이번 달 나온 Claude Sonnet 5의 한시 가격 $2와 정면으로 겹치는 구간입니다. 프론티어급 성능의 가격 하한이 빠르게 내려오고 있다는 뜻이고, 이 혜택은 API로 서비스를 만드는 팀에게 바로 돌아갑니다.
셋째, 정부 협의를 거친 단계적 공개라는 새 출시 문법입니다. 프론티어 모델을 곧바로 전체 공개하지 않고 정부 공유, 소수 파트너, 일반 공개 순서로 여는 방식은 앞으로 다른 프론티어 랩에도 반복될 가능성이 높습니다.
실전에서 어떻게 쓸 수 있을까?
지금 당장은 쓸 수 없습니다. 약 20개 파트너 기관 한정 프리뷰라서, ChatGPT나 API에서 GPT-5.6을 선택하는 방법은 아직 없습니다. 지금 할 수 있는 준비는 두 가지입니다.
하나, 작업별 모델 단수를 미리 설계해두세요. GA가 되면 Sol·Terra·Luna 중 무엇을 쓸지 바로 결정해야 합니다. 대량 분류·요약처럼 볼륨이 큰 작업은 Luna($1/$6), 일상 업무 자동화는 Terra, 복잡한 에이전트 워크플로만 Sol로 나누는 식입니다. 지금 쓰는 프롬프트와 파이프라인을 작업 난이도별로 분류해두면 전환이 빠릅니다.
둘, 비용 재계산 시점을 잡아두세요. GPT-5.5나 Claude로 돌리고 있는 API 워크로드가 있다면, GPT-5.6 GA 시점에 Terra·Luna 단가로 다시 계산해볼 가치가 있습니다. 중간 체급 기준으로 기존 대비 절반 수준의 비용 구조가 예고된 상태입니다.
자주 묻는 질문
GPT-5.6은 언제부터 쓸 수 있나요?
OpenAI는 수주 내 일반 공개를 예고했습니다. 현재(2026년 7월 초)는 약 20개 파트너 기관 한정 프리뷰 상태라 ChatGPT와 API 모두에서 일반 사용자는 접근할 수 없습니다.
Sol, Terra, Luna의 차이는 뭔가요?
Sol은 최고 난도 추론과 에이전트 작업용 플래그십($5/$30), Terra는 GPT-5.5급 성능을 더 낮은 비용으로 제공하는 균형형($2.50/$15), Luna는 대량 처리용 경량 고속 모델($1/$6)입니다. 가격은 1M 토큰당 입력/출력 기준입니다.
GPT-5.6 성능은 어느 정도인가요?
공개된 지표 기준으로 Sol의 최상위 설정이 Terminal-Bench 2.1에서 91.9%로 신기록을 세웠습니다. 다만 제한 프리뷰 단계라 독립적인 외부 검증은 아직 제한적이며, 일반 공개 후 실사용 평가를 확인할 필요가 있습니다.
인사이트
이번 발표에서 가장 눈여겨볼 부분은 이름의 승격이라고 봐요. 지금까지 OpenAI의 경량 모델은 mini, nano 같은 접미사였는데, 이번에는 Sol·Terra·Luna라는 독립된 이름을 받았습니다. 접미사는 "본 모델의 축소판"이라는 인상을 주지만, 고유명은 각 체급이 독자적인 제품이라는 선언입니다. 실제로 매출 볼륨은 플래그십이 아니라 중간·경량 체급에서 나오는 구조로 가고 있고, Terminal-Bench 80%를 넘긴 Terra가 그 증거입니다. 다음 분기 AI 비용 최적화의 싸움터는 최고 성능이 아니라 "충분한 성능의 최저가" 구간이 될 거예요.
한국 사용자 관점에서는 시차를 기회로 쓸 수 있습니다. 수주 간의 프리뷰 기간은 뒤집어 보면 준비 기간입니다. GA 당일에 "우리 워크로드 중 뭘 옮기지"를 처음 고민하는 팀과, 작업별 모델 단수와 예상 비용표를 만들어둔 팀의 격차는 꽤 클 겁니다. 저희는 이 글의 비교 카드 기준으로 GA 시점에 실측 후속 글을 이어갈 예정이에요.
원문: OpenAI — Previewing GPT-5.6 Sol
이 글을 읽으면
AI 시대 커리어를 어떻게 설계해야 할지, Scale AI·Google DeepMind·OpenAI를 모두 거친 사람의 기준으로 정리할 수 있어요. 지난주 X에서 조회 289만, 북마크 1만 7천을 기록한 Phil Chen의 아티클 "Career advice in the age of AI"를 6가지 조언으로 풀었습니다.
글 전체를 관통하는 프레임은 한 문장입니다. "AI 모델은 손실함수(loss function)를 정의할 수 있는 모든 것에서 좋아진다." 정답과 채점 기준이 명확한 일은 AI가 계속 잘하게 되고, 학교 교육은 대부분 그런 문제로 이루어져 있죠. 그래서 남는 질문은 하나예요. AI가 채점할 수 없는 일을 나는 얼마나 갖고 있는가.
1. 진짜 희소한 자원에 집중하기, 자본이 아니라 시간·관계·평판
저자가 첫 번째로 꼽는 것은 자원의 우선순위 재조정입니다. 자본에 대한 접근은 어느 때보다 쉬워졌지만, 시간과 관계와 평판은 여전히 희소합니다.
본인의 선택이 근거입니다. 그는 퀀트 펀드의 제안을 거절하고 당시 규모가 훨씬 작던 Scale AI에 입사했습니다. 단기 보상은 적었지만 LLM 인프라 전문가들과의 네트워크가 생겼고, 그 평판이 이후 DeepMind와 OpenAI 기회로 이어졌습니다. 연봉 숫자보다 "누구와 어떤 문제를 풀었는가"가 다음 기회의 입장권이 된다는 이야기입니다.
2. 문제 해결이 아니라 문제 발견 능력 키우기
에이전트가 코드를 대신 쓰는 시대에는 문제를 푸는 능력보다 풀 가치가 있는 문제를 고르는 능력이 결정적입니다.
저자의 회사는 채용에서 리트코드(LeetCode)식 코딩 테스트와 시스템 설계 면접을 폐기했습니다. 대신 후보자가 낯선 환경을 얼마나 빠르게 파악하고, 가치 있는 문제를 식별하고, 제약 안에서 해결하는지를 봅니다. 흥미로운 관찰이 하나 나오는데, 같은 문제를 풀더라도 후보자마다 소비하는 토큰과 시간이 크게 달랐다고 합니다. 잘하는 사람은 에이전트에게 코드 생성을 시키기 전에 문제를 어떻게 분해할지에 대한 직관과 외부 맥락을 먼저 가져온다는 것이죠.
3. 가장 야심 찬 형태의 문제를 고르기
세 번째 조언은 강화학습의 "Bitter Lesson" 원칙을 커리어에 적용한 것입니다. 작업별 잔기술보다 범용적이고 스케일이 큰 방법이 결국 이긴다는 원칙처럼, 커리어도 야심 찬 문제에 붙어야 가치가 축적됩니다.
AI 덕분에 소프트웨어를 만드는 일 자체는 쉬워졌습니다. 누구나 간단한 시스템을 만들 수 있으니, 간단한 시스템에는 가치가 쌓이지 않습니다. 회사를 고를 때는 그 회사가 자기 문제의 가장 야심 찬 형태에 도전하는지, 직무를 고를 때는 그 역할이 문제의 최전선에 서게 해주는지를 물어야 합니다.
Photo by Jens Lelie on Unsplash
4. 마지막 10%에서 전력 질주하기
에이전트가 만든 평균적인 결과물은 초안 수준입니다. 실제 가치는 마지막 10%, 즉 고유한 관점, 디테일에 대한 집착, 다듬기(polish), 깔끔한 아키텍처에서 나옵니다. 저자는 이 마지막 10%가 작업량의 90%이면서 동시에 보상의 90%라고 말합니다.
실행 방법도 구체적입니다. 개인 프로젝트에서 "조금 더 시간을 들여 다듬는" 연습을 의도적으로 하고, 새로운 세대의 에이전트가 나올 때마다 배운 것을 반영해 처음부터 다시 만들어보라는 것입니다.
5. 기회의 양과 전환율을 동시에 키우기, 축구의 xG처럼
축구에서 기대 득점을 뜻하는 xG(expected goals)처럼, 커리어도 "좋은 기회에 노출되는 확률"과 "그 기회를 성과로 바꾸는 효율" 두 변수로 볼 수 있습니다.
이 대목에서 꽤 놀라운 실화가 나옵니다. 저자는 2023년에 약 50명 규모이던 Anthropic과 창업자 외 2명뿐이던 Cursor의 제안을 거절하고 DeepMind의 모델 추론·훈련 팀을 선택했습니다. 2024년에 두 회사가 다시 제안했지만 이번에는 OpenAI를 골랐습니다. 지금 기준으로 보면 아까운 선택 같지만, 저자의 해석은 다릅니다. 좋은 평판을 유지하면 기회는 계속 돌아오고, 커리어는 길다는 것. 그리고 초기 회사를 고를 때는 지금의 제품보다 팀과 시장을 봐야 한다는 것입니다.
6. 연구는 더 이상 소수의 특권이 아니다
마지막 조언은 의외로 문이 열려 있다는 소식입니다. 공개 최적화 리더보드에서 아이디어를 체계적으로 실험할 수 있고, Modal 같은 컴퓨팅 제공자들이 학생에게 크레딧을 줍니다. 모델을 직접 쓰면서 평가 기준을 만들어보는 것만으로도 연구 직관을 검증할 수 있습니다.
저자가 강조하는 것은 연구자라는 직함이 아니라 마인드셋입니다. 호기심, 인프라와 싸우는 끈기, 시스템을 깊이 이해해서 디버깅하는 능력, 그리고 결과의 가치를 설득해 더 많은 자원을 확보하는 능력. 이 조합은 연구실 밖에서도 그대로 통합니다.
마무리
여섯 가지를 한 줄로 압축하면 이렇게 돼요. AI가 채점할 수 있는 일(정답이 있는 문제 풀이)에서 경쟁하지 말고, AI가 채점할 수 없는 일(문제 정의, 마지막 10%, 관계와 평판)에 자원을 몰아라. 시험 잘 보는 능력으로 쌓아온 커리어일수록 이 전환이 불편하겠지만, 방향 자체는 부정하기 어렵습니다.
자주 묻는 질문
AI 시대 커리어에서 가장 먼저 길러야 할 능력은 뭔가요?
Phil Chen은 문제 발견 능력을 꼽습니다. 코드는 에이전트가 대신 쓸 수 있지만, 어떤 문제가 풀 가치가 있는지 고르고 자원을 배분하는 판단은 여전히 사람의 몫이기 때문입니다.
비개발자에게도 이 조언이 적용되나요?
적용됩니다. 6가지 중 코딩이 전제인 항목은 없습니다. 문제 발견, 마지막 10% 다듬기, 관계와 평판 구축은 마케팅·기획·운영 직군에서도 동일하게 작동하는 원칙입니다.
AI가 채점할 수 없는 일이란 정확히 무슨 뜻인가요?
손실함수, 즉 명확한 정답과 평가 기준을 정의할 수 있는 일은 AI가 계속 좋아집니다. 반대로 문제 자체를 정의하거나 가치를 판단하거나 방향을 정하는 일은 채점 기준이 없어서 AI가 대체하기 어렵다는 뜻입니다.
인사이트
이 글에서 가장 실용적인 대목은 채용 방식의 변화라고 봐요. 리트코드를 버리고 "에이전트와 함께 낯선 문제를 푸는 과정"을 보는 회사가 이미 존재한다는 건, 채용 시장의 평가 축이 지식 보유량에서 문제 접근 방식으로 넘어가고 있다는 신호입니다. 며칠 전 다룬 메타 사례와 겹쳐 보면 대비가 선명한데요. 메타는 "에이전트가 사람을 대체한다"에 베팅했다가 속도 조절에 들어갔고, Phil Chen은 "에이전트를 지렛대로 쓰는 사람의 기준"을 다시 쓰고 있습니다. 같은 기술을 보고 한쪽은 뺄셈을, 한쪽은 곱셈을 설계한 셈이죠.
하나 더, "마지막 10%" 조언은 저희가 콘텐츠를 만들 때도 그대로 검증돼요. 에이전트가 뽑아준 초안은 누구나 가질 수 있으니, 차별화는 결국 고유한 관점과 다듬기에서 갈립니다. AI 시대 커리어의 역설은 여기에 있습니다. 도구가 상향 평준화될수록, 도구가 채점할 수 없는 부분의 값이 올라간다는 것. 이번 주에 뭔가를 만들고 있다면, 끝냈다고 느낀 지점에서 10%만 더 다듬어보세요. 그 구간이 AI와 나의 가격 차이가 만들어지는 곳이에요.
원문: Phil Chen — Career advice in the age of AI (X)
한줄 요약
메타가 AI 에이전트로 인력을 대체하겠다며 8,000명을 해고한 지 반년, 저커버그가 내부 타운홀에서 "AI 에이전트 발전 속도가 기대만큼 가속되지 않았다"고 인정했습니다. AI 에이전트 한계가 빅테크 최고경영자의 입에서 공식 확인된 첫 사례입니다.
무슨 일이 있었나?
로이터에 따르면 저커버그는 7월 2일(현지시간) 열린 내부 타운홀에서 AI 에이전트 개발 속도가 경영진이 예상했던 방식으로 "가속되지 않았다"고 직원들에게 말했습니다.
이 발언이 무거운 이유는 앞선 결정 때문입니다. 메타는 올해 초 사무직의 약 10%에 해당하는 8,000명을 해고했고, 별도로 7,000명을 'Agent Transformation'을 포함한 AI 조직으로 재배치했습니다. AI 에이전트가 사람의 업무를 대신할 것이라는 전제 위에 조직 전체를 다시 설계한 셈입니다.
저커버그는 이번 타운홀에서 해고 과정이 "깔끔하지 못했다"고도 인정했습니다. 해고를 단행한 이유에 대해서는 "변화하는 산업 지형에 충분히 빠르게 적응하지 못할 것을 경영진이 우려했기 때문"이라고 설명했습니다.
AI 중심 조직 개편의 효과에 대해서도 솔직했습니다. 기대했던 이점이 "아직 실현되지 않았다"면서, 향후 3~6개월 안에 AI 투자의 개선 효과가 나타나기 시작할 것이라고 전망했습니다. 메타는 올해에만 AI 인프라에 최대 1,450억 달러(약 200조 원)를 투자할 것으로 예상됩니다.
내부 분위기는 수치보다 심각합니다. TechCrunch는 지난 6월, 신설 AI 조직에 배치된 엔지니어들이 자기 조직을 "영혼을 갈아넣는 수용소"라고 표현했다고 보도했습니다. AI타임스 등 국내 보도에 따르면 저커버그는 6월 내부 메모에서 "전환 과정에서 실수를 저질렀다"고 인정하고 연내 추가 전사 해고는 없다고 밝힌 바 있습니다.
왜 중요한가?
이 발언은 "AI가 사람을 대체한다"는 명제의 현재 위치를 보여주는 실측 데이터입니다.
메타의 베팅 구조는 단순했습니다. 사람을 먼저 내보내고, 그 공백을 AI 에이전트가 메우는 순서였습니다. 그런데 공백을 메워야 할 에이전트의 발전 속도가 계획을 따라가지 못하면, 그 격차의 비용은 남은 조직이 치르게 됩니다. 8,000명 해고, 7,000명 강제 재배치, 그리고 "영혼을 갈아넣는" 내부 증언이 그 비용의 실체입니다.
주목할 부분은 저커버그가 AI 에이전트 자체를 부정하지 않았다는 점입니다. 문제는 방향이 아니라 속도였습니다. 3~6개월 내 개선을 언급한 것도 베팅을 접는 게 아니라 시간표를 다시 쓰겠다는 신호로 읽힙니다. 200조 원 규모의 투자는 그대로 유지됩니다.
Photo by Alex Kotliarskyi on Unsplash
실전에서 어떻게 쓸 수 있을까?
메타의 시행착오는 AI 도입을 준비하는 조직에게 순서에 관한 교훈을 남깁니다.
첫째, 대체가 아니라 위임 단위로 시작하는 편이 안전합니다. 사람을 줄이고 에이전트로 메우는 방식이 아니라, 지금 있는 사람이 에이전트에게 업무를 위임하며 검증하는 방식입니다. Karpathy가 코드 작성의 80%를 에이전트에 위임하면서도 감독자 역할을 유지하는 것이 대표적입니다.
둘째, 조직 단위 전환보다 워크플로 단위 전환이 실패 비용이 낮습니다. 메타처럼 수천 명을 한 번에 AI 조직으로 옮기면 에이전트 성숙도가 계획에 못 미칠 때 되돌릴 방법이 없습니다. 반복 업무 하나, 리포트 하나부터 에이전트화하면 실패해도 그 업무만 되돌리면 됩니다.
셋째, AI 투자 성과의 시간표를 보수적으로 잡아야 합니다. 세계에서 가장 공격적으로 투자한 메타조차 "3~6개월 뒤 개선 기대"로 물러섰습니다. 도입 첫 분기에 인건비 절감을 기대하는 계획이라면 다시 검토할 필요가 있습니다.
자주 묻는 질문
AI 에이전트 한계는 구체적으로 무엇인가요?
현재 AI 에이전트는 잘 정의된 반복 업무에는 강하지만, 맥락이 자주 바뀌는 업무를 사람 없이 끝까지 수행하는 데는 한계가 있습니다. 메타 사례는 이 한계를 조직 구조가 앞질러 갔을 때의 비용을 보여줍니다.
메타는 AI 에이전트 투자를 줄이나요?
아닙니다. 메타는 올해 AI 인프라에 최대 1,450억 달러를 투자할 예정이며, 저커버그는 3~6개월 내 개선 효과를 기대한다고 밝혔습니다. 속도 조정이지 방향 전환이 아닙니다.
AI 때문에 해고가 계속 이어질까요?
저커버그는 6월 내부 메모에서 연내 추가 전사 해고는 없다고 밝혔습니다. 다만 이는 메타의 약속일 뿐, 업계 전반의 AI발 구조조정 흐름이 멈췄다는 뜻은 아닙니다.
인사이트
메타의 진짜 실수는 AI 에이전트를 믿은 게 아니라, 도입 단위를 잘못 고른 것이라고 봅니다. 같은 시기에 에이전트로 성과를 내는 조직들은 공통적으로 반대 순서를 씁니다. Anthropic Claude Code 팀의 Boris Cherny는 직무를 없애는 대신 프로토타이퍼, 빌더, 스위퍼 같은 역할(아키타입) 단위로 재편하는 그림을 제시했고, 이를 해설한 Lucas는 "의도적 소수 인력 + 풍부한 토큰"으로 자동화를 강제하되 해고가 아닌 조직 설계로 푸는 방식을 소개했습니다. 사람을 빼고 에이전트를 넣는 뺄셈이 아니라, 사람당 에이전트 지렛대를 키우는 곱셈입니다.
한국 조직에 시사하는 바는 더 직접적입니다. 국내에서는 "AI 전담팀 신설 후 전사 확산" 방식이 유행하는데, 이는 메타의 축소판이 되기 쉽습니다. 전담팀이 성과를 내기 전에 조직 기대치가 먼저 올라가고, 그 격차가 전담팀의 번아웃으로 전가되는 구조가 똑같기 때문입니다. AI 에이전트 한계가 어디까지 물러나는지는 분기 단위로 다시 재야 하고, 조직 개편은 그 실측치를 따라가는 편이 안전합니다. 기술 시간표보다 조직 시간표가 앞서가는 순간, 그 격차를 메우는 것은 결국 사람입니다.
원문: TechCrunch — Mark Zuckerberg tells staff that AI agents haven't progressed as quickly as he'd hoped
비개발자가 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 키는 채팅에 넣지 말고 별도 파일에 저장하는 걸 잊지 마세요.
## 시도하고자 했던 것과 그 이유를 알려주세요.
### 택배박스에서 시작한
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) — 꾸준한 반복과 기록의 힘을 배웠습니다.
- 준님의 실전 사례 / 정기님의 실전 사례
이 사례글도 그 가르침의 실천입니다.
📝 한줄 요약
"이 상품 재고 지금 어디까지 왔어요?"
MD가 마케팅 일정을 잡기 전에 자주 확인해야 했던 질문입니다. 곡성 AI 워케이션 동안 이 질문을 줄이기 위해, 여러 사이트와 메신저를 오가며 확인하던 물류/재고 상태를 한 화면에서 볼 수 있는 운영 Flow 대시보드로 정리했습니다.
핵심은 "자동화가 데이터를 가져온다"에서 끝내지 않고, MD와 물류 담당자가 실제로 믿고 쓸 수 있도록 수집 기준, 최신성, 재고 기준일, 업무 단계까지 함께 보여주는 것이었습니다.
바쁘시면 이것만 읽어도 돼요:
MD와 대표가 물류 담당자에게 반복해서 묻던 "재고가 어디까지 왔는지" 문제를 한 화면의 Flow로 좁혔습니다.
중국 창고, 중국 운송장, 국내 배송, 업무 메신저 신호, 판매채널 포털, 재고관리 포털 데이터를 읽기 전용으로 모았습니다.
AI는 단순 코딩뿐 아니라 문제 쪼개기, 화면 구조 설계, API 응답 대조, 검증 루프 설계에 계속 사용했습니다.
공개용 스크린샷은 업체명, 상품명, 주문번호, 수량을 모두 샘플화했습니다.
캠프 후에는 MD가 입고/재고 상황을 직접 보고 마케팅 일정을 잡고, 물류 담당자는 반복 답변보다 예외 처리와 메모에 집중하는 흐름을 목표로 합니다.
🎯 이런 분들께 도움돼요
물류, 재고, 입고 상태를 여러 사이트에서 따로 확인하는 분
MD, 마케팅 담당자, 운영 담당자가 같은 재고 정보를 보고 움직여야 하는 팀
AI로 내부 운영 도구를 만들고 싶은데 "어디까지 자동화하고 어디서 사람이 판단해야 하는지" 고민하는 분
😫 문제 상황 (Before)
기존에는 재고가 어디 있는지, 언제 들어오는지, 판매 가능한 상태인지 확인하려면 물류 담당자에게 계속 물어봐야 했습니다. 대표나 MD 입장에서는 마케팅 일정을 잡아야 하는데, 재고 들어오는 날짜와 현재 위치가 확실하지 않으면 광고나 프로모션 타이밍을 잡기 어렵습니다.
물류 담당자 입장에서도 답을 하려면 한 화면만 보면 되는 것이 아니었습니다. 중국 창고, 중국 운송장, 국내 배송, 판매채널 포털, 재고관리 포털, 업무 메신저를 각각 확인해야 했습니다. 같은 질문이 반복되면 담당자는 매번 여러 곳을 다시 확인하고, MD는 답을 기다리는 구조가 됩니다.
그래서 문제를 이렇게 좁혔습니다.
"MD와 대표가 물류 담당자에게 반복해서 묻던 재고 위치와 입고 상태를,
처음 로그인 이후 한 화면에서 직접 확인할 수 있게 만들자."
이번 글의 초점은 "여러 자동화를 많이 만들었다"가 아니라, 반복 질문이 생기는 물류/재고 확인 병목을 한 화면의 운영 Flow로 바꾼 과정입니다.
🛠️ 사용한 도구
AI 코딩 도구: 요구사항 정리, 구현 방향 제안, 화면 구조 수정, 테스트 보강
운영허브 화면: 내부 직원이 보는 물류 Flow와 재고 현황 화면
브라우저 자동화/크롤링: 외부 포털에서 읽기 전용 상태 확인
API 조회: 재고 수량과 상품/옵션 정보를 보강
업무 메신저 신호 수집: 사람이 남긴 확인 메시지를 보조 신호로 사용
검증 루프: UI smoke 테스트, 시간 표시 점검, 브라우저 캡처로 화면 상태 확인
공개 글에서는 실제 업체명, 상품명, 주문번호, 입고번호, 옵션 ID, 내부 경로, 계정 정보는 사용하지 않습니다. 아래 스크린샷도 모두 공개용 샘플 데이터로 바꾼 화면입니다.
💡 해결 방향
처음부터 모든 업무를 완전 자동화하려고 하지 않았습니다. 우선 "반복 확인"을 줄이는 데 집중했습니다.
업무 흐름을 단순화하면 이렇습니다.
구분
기존 흐름
바꾼 흐름
질문
MD/대표가 물류 담당자에게 재고 위치와 입고 상태를 물어봄
MD가 운영 Flow 화면에서 직접 확인
확인
담당자가 여러 포털과 메신저를 돌아다님
크롤링, API, 브라우저 자동화가 읽기 전용으로 모음
판단
담당자 답변을 기다린 뒤 마케팅 일정 판단
입고 단계와 재고 기준일을 보고 일정 판단
담당자 역할
반복 질문에 답변
예외 상황, 메모, 최종 판단에 집중
여기서 중요한 기준은 "데이터를 가져왔다"가 아니라 "직원이 이 데이터를 믿고 써도 되는지"였습니다. 그래서 화면에는 수집 방식, 주기, 최신 시각, 기준일을 같이 넣었습니다.
🧭 도식화
아래 흐름을 기준으로 공개용 도식 이미지를 만들었습니다. 핵심은 "질문을 받은 사람이 여러 곳을 확인해 답하는 흐름"을 "필요한 사람이 먼저 화면에서 확인하는 흐름"으로 바꾸는 것이었습니다.
Before
After
MD/대표 질문 → 물류 담당자 확인 →
여러 사이트 접속 → 수동 취합 → 답변 반복
최초 로그인/세션 확인 → 크롤링/API/브라우저 자동화 → 물류 Flow/재고 현황/수집 기준 표시 → MD 직접 확인
🧪 작업 과정 1: 물류 Flow를 "업무 단계"로 다시 쪼개기
처음 물류 화면은 주문번호 중심으로 보는 구조였습니다. 그런데 실제 업무에서는 모든 단계가 같은 기준으로 움직이지 않았습니다. 공장 주문과 공장 출고 단계에서는 상품 라인 기준으로 봐야 하고, 창고 입고 이후에는 주문 묶음이나 입고 묶음 기준으로 봐야 했습니다.
AI에게 한 번에 "물류 대시보드 만들어줘"라고만 하면 화면은 나올 수 있지만, 실무 흐름과 어긋날 가능성이 큽니다. 그래서 먼저 업무 기준을 문장으로 쪼갰습니다.
공장 주문/출고 단계에서는 상품 라인으로 보고,
창고 입고 이후에는 주문 또는 입고 묶음으로 본다.
카드에는 빠른 판단에 필요한 값만 남기고,
식별자와 상세 메모는 팝업에서 확인한다.
이 기준을 AI와 함께 화면 규칙으로 바꿨습니다. 카드에 어떤 정보를 남길지, 팝업에는 어떤 정보를 보낼지, 메모가 실수로 닫히지 않게 하려면 어떤 UX가 필요한지 계속 조정했습니다.
이 화면에서 보여주고 싶었던 것은 예쁜 대시보드가 아니라, "지금 물류 흐름이 어느 단계에 있는지"를 물어보지 않고도 볼 수 있는 구조였습니다.
🧪 작업 과정 2: 재고 API를 그대로 믿지 않고 사람이 읽을 수 있게 보강하기
재고 화면에서 한 번 막혔던 지점은 상품명이었습니다. 처음에는 재고 API가 상품명을 충분히 주지 않는 것처럼 보였습니다. 그냥 "API가 안 준다"라고 끝내면 화면에는 숫자 ID만 남고, 직원은 다시 사람이 해석해야 합니다.
여기서 AI와 다시 점검했습니다.
재고 API가 수량 기준 데이터라면,
상품명과 옵션명은 다른 상품 목록 API나 주문 API와 조합해서 보강할 수 있지 않을까?
실제 응답과 문서를 대조해 보니, 한 API만으로는 부족하지만 다른 API와 연결하면 사람이 읽을 수 있는 재고표에 가까워질 수 있었습니다. 그래서 재고 수량은 재고 API를 기준으로 삼고, 상품명/옵션명은 상품 목록과 주문 이력 쪽 데이터를 조합하는 방향으로 바꿨습니다.
여기서 얻은 교훈은 컸습니다.
"API가 안 준다"는 말은 절반만 맞을 수 있다.
실무 자동화에서는 한 API의 응답만 보지 말고,
같은 도메인의 다른 데이터와 연결해서 사람이 읽을 수 있는 표로 만들어야 한다.
🧪 작업 과정 3: 자동화 기준과 최신성을 화면 안에 넣기
여러 데이터가 한 화면에 모이면 또 다른 문제가 생깁니다. "이 값이 언제 수집된 거지?", "이건 서버 자동이야, 사람이 확장 프로그램을 실행해야 하는 거야?", "이 기준일은 오늘이야 어제야?" 같은 질문이 남습니다.
그래서 물류 화면 상단에 수집 자동화 기준을 따로 넣었습니다. 예를 들면 이런 식입니다.
중국 창고 주문: 브라우저 크롤러 기준
중국 운송장: 확장 프로그램 기준
국내 배송: 배송 상태 확인 기준
업무 메신저 신호: 일정 주기 서버 자동 수집
판매채널 포털: 브라우저 자동화 기준
재고관리 포털: 매일 정해진 기준일로 수집
자동화가 많아질수록 "어디서 온 데이터인지"와 "얼마나 최신인지"를 숨기면 오히려 신뢰도가 떨어집니다. 이번 작업에서는 이 정보까지 화면에 넣어야 실제 업무자가 안심하고 쓸 수 있다고 봤습니다.
✅ 결과 (After)
가장 큰 변화는 같은 질문을 반복하지 않아도 되는 구조가 생겼다는 점입니다.
항목
Before
After
재고 위치 확인
물류 담당자에게 질문
운영 Flow 화면에서 단계 확인
입고/배송 상태 확인
여러 사이트를 따로 열어 확인
한 화면에서 단계별 카드로 확인
재고표 확인
판매채널/재고관리 화면을 따로 확인
재고 현황 탭에서 기준일별로 확인
마케팅 일정 판단
담당자 답변을 기다린 뒤 판단
입고 예정과 재고 상태를 보고 바로 판단
담당자 업무
반복 질문 대응
예외, 메모, 최종 판단에 집중
캠프 후 실제 사용 흐름은 이렇게 잡았습니다. MD는 광고나 프로모션 일정을 잡기 전에 먼저 재고 화면과 물류 Flow를 확인합니다. 물류 담당자는 같은 질문에 반복해서 답하기보다, 화면에서 설명되지 않는 예외 상황과 메모를 보강합니다.
정량적으로는 외부 포털을 모두 사람이 직접 확인하는 시간을 아직 공개 수치로 측정하지는 못했습니다. 대신 이번 캠프에서 확인한 작동 증거는 세 가지입니다.
물류 Flow 화면에서 단계별 카드와 수집 기준이 표시됨
재고 현황 화면에서 재고 종류별 탭, 필터, 기준일, 샘플 수량 구조가 표시됨
UI smoke 테스트와 브라우저 캡처로 화면이 깨지지 않는지 확인함
🔍 정확성은 어떻게 확인했나
AI가 만들어준 결과를 그대로 믿지는 않았습니다. 특히 내부 운영 도구는 한 번 잘못 표시되면 사람이 잘못 판단할 수 있기 때문에, 아래 기준으로 확인했습니다.
실제 화면에서 카드가 업무 단계 순서대로 보이는지 확인
수집 기준 박스에 최신 시각, 수집 방식, 기준일이 표시되는지 확인
재고 화면에서 탭, 필터, 컬럼 설정, 정렬이 작동하는지 확인
상품명이 비어 보이는 원인을 API 응답과 저장된 스냅샷으로 다시 확인
화면 캡처를 공개용으로 만들 때 업체명, 상품명, 주문번호, 수량을 샘플화했는지 확인
아직 남은 제한도 있습니다. 일부 상품명은 외부 포털이나 추가 크롤러 매핑이 있어야 더 정확히 채워질 수 있습니다. 그래서 이 화면은 외부 시스템을 수정하는 자동화가 아니라, 읽기 전용으로 모아 보고 사람이 최종 판단하는 운영 화면으로 두었습니다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
"대시보드 만들어줘"보다 "누가 어떤 질문을 반복하는지"부터 정리하기
업무 단계를 데이터 기준이 아니라 사람이 판단하는 기준으로 다시 나누기
API 하나만 보고 포기하지 말고, 같은 도메인의 다른 API와 연결해 보기
자동화 결과만 보여주지 말고 수집 방식, 주기, 최신성을 함께 보여주기
화면 피드백을 작은 UI 규칙과 테스트 항목으로 바꾸기
이렇게 하면 안 돼요
내부 데이터를 그대로 공개 스크린샷에 넣지 않기
"자동화됐다"는 말만 믿고 최신성/기준일 표시를 빼지 않기
처음부터 외부 시스템을 수정하는 자동화로 만들지 않기
API 응답에 상품명이 없다고 해서 바로 한계로 단정하지 않기
🌍 다른 업무에 적용한다면?
이 방식은 물류뿐 아니라 여러 부서가 같은 상태를 반복해서 물어보는 업무에 적용할 수 있습니다.
CS: 고객 문의 상태, 택배 상태, 환불 상태를 한 화면에 모으기
마케팅: 캠페인 진행 상태, 소재 승인 상태, 재고 가능 여부를 함께 보기
구매/발주: 발주 요청, 입고 예정, 결제 상태, 담당자 메모를 단계별로 보기
매장 운영: 재고 부족, 발주 필요, 입고 예정, 판매 중단 상품을 한 화면에 보기
핵심은 "AI로 데이터를 모은다"가 아니라, 반복 질문이 생기는 지점을 찾아 그 질문에 답하는 화면을 만드는 것입니다.
🚀 앞으로의 계획
캠프 이후에는 실제 운영자가 더 자주 보는 항목을 기준으로 화면을 다듬을 예정입니다.
MD가 마케팅 일정을 잡을 때 필요한 입고 예정/재고 기준을 더 또렷하게 표시
상품명이 비는 항목은 추가 포털 매핑이나 크롤러로 보강
물류 담당자가 남긴 메모를 단계별로 더 찾기 쉽게 정리
자동 수집 실패나 로그인 필요 상태를 더 분명하게 표시
최종 목표는 "물류 담당자에게 물어보지 않아도 된다"가 아니라, 담당자가 반복 답변보다 판단이 필요한 일에 시간을 쓰게 만드는 것입니다.
📋 재사용 가능한 체크리스트
내 업무에서 반복 질문 찾기
아래 질문에 답하면 비슷한 자동화 주제를 찾기 쉽습니다.
누가 누구에게 같은 질문을 반복해서 하나요?
그 질문에 답하려면 어떤 사이트, 파일, 메신저를 열어야 하나요?
답변을 기다리는 동안 어떤 업무가 멈추나요?
완전 자동화가 아니라도 한 화면에 모으면 바로 줄어드는 질문은 무엇인가요?
사람이 최종 판단해야 하는 지점은 어디인가요?
📋 재사용 가능한 프롬프트
프롬프트 1: 반복 확인 업무를 자동화 주제로 좁히기
내 업무에서 반복 확인이 많은 프로세스를 정리하고 싶어.
업무 배경: [업무 배경] 반복 질문: [누가 누구에게 무엇을 묻는지] 확인해야 하는 곳: [사이트/파일/메신저/담당자] 최종 판단자: [사람이 결정해야 하는 것]
이걸 기준으로 AI 자동화 사례 글에 쓸 수 있게
가장 뾰족한 문제 한 문장
Before/After 표
자동화가 맡을 일과 사람이 판단할 일
공개하면 안 되는 민감 정보 목록 으로 정리해줘.
프롬프트 2: 자동화 결과물의 신뢰도 점검하기
아래 자동화 화면을 실제 업무자가 믿고 쓸 수 있는지 점검해줘.
화면 목적: [예: 재고/입고 상태 확인] 데이터 출처: [API/크롤링/브라우저 자동화/수기 메모] 갱신 주기: [주기] 사용자가 해야 하는 판단: [판단]
다음 기준으로 빠진 항목을 찾아줘.
최신 수집 시각이 보이는가
기준일이 명확한가
자동 수집과 수동 확인이 구분되는가
데이터가 비었을 때 사용자가 오해하지 않는가
외부 시스템을 수정하지 않는 읽기 전용 안전장치가 있는가
공개 스크린샷에서 업체명, 상품명, 주문번호, 수량이 가려졌는가
📝 한줄 요약
브런치카페 3개 매장을 운영하면서 노션·구글드라이브·엑셀·카톡에 흩어져 있던 매뉴얼·레시피·급여·재고를, 클로드 코드(Claude Code)와 "말로 대화"하며 우리 회사 전용 위키와 자동화로 옮겼습니다. 3년 전 지피티 3.5와 함께하던 파이썬 코딩은 3일 만에 포기했던 비개발자인데, 이번엔 됐어요. 그것도 지피터스가 전남 곡성에서 연 'AI 워케이션 1기' 고작 3박 4일 동안, 함께 간 멤버들과 으쌰으쌰하면서요.
바쁘시면 이것만 읽어도 돼요
사용한 도구·목표: 헤르메스 에이전트 + 클로드 코드(AI 코딩 도구)Fable 5 모델로, 흩어진 매장 지식을 한 곳(위키)으로 모으고 반복 수작업을 자동화, 에이전트를 통해 매장관리. 코드는 한 줄도 안 쓰고 전부 한국어로 말로 시켰어요.
핵심 결과: 자료 4곳 → 위키 1곳(문서 78개), 급여 근무시간 집계 8년 손계산 → 대화 1시간, 재고 부족·서류 만료를 봇이 먼저 감지(실제로 제 발주 실수를 잡아 사고를 막았어요).
핵심 깨달음: AI를 잘 쓰는 비결은 프롬프트 기술이 아니라 "이미 쌓아둔 데이터·매뉴얼" 이었어요. 8년치가 있었기에 AI가 폭발적으로 일해줬어요.
AI를 맹신하진 않았어요: 실제 잘 작동하는지 확인을 위해 급여는 실제 지급액과 한줄씩 대조, 위키는 배포 후 직접 열어 검수하고 썼습니다.
막혔던 순간: Supabase·SQL이 뭔지 아직도 몰라요. 모르면 그냥 "이게 뭔지 모르겠는데 뭘 하면 돼?"라고 물어보면 됐어요.
가장 큰 변화: 모든 업무자료 일원화, 반복업무 자동화 및 에이전트를 통한 완벽 소통으로 인해 동업자와의 마찰을 없앴음
🎯 이런 분들께 도움돼요
카페·음식점·미용실·학원처럼 매뉴얼과 반복 업무가 많은 자영업을 하는데, 모든 게 사장 머릿속에만 있는 분
노션·구글드라이브·엑셀·카톡에 자료가 흩어져서 매번 "그거 어디 있더라" 하는 분
코딩은 전혀 모르는 비개발자지만, 매달 반복하는 수작업(급여·정산·재고)을 자동화하고 싶은 분
예전에 자동화나 코딩을 시도했다가 어려워서 포기했던 분
기억력 이슈로 인해 개인 비서가 필요하신분
😫 문제 상황 (Before)
저는 남양주에서 브런치카페 매장 3곳을 운영합니다. 가족 사업이라 아버지가 한 곳, 저와 동생이 더 바쁜 두 곳을 맡고 있어요. 한 매장에만 아르바이트가 15명, 다른 매장에 5~6명씩 있습니다.
문제는, 모든 게 저한테 몰려 있었다는 것이었어요.
직원들이 저를 "엄마 바라보듯" 봤어요. 궁금한 게 생기면 신입도 알바도 매번 저한테 전화·카톡. 8년을 그렇게 매장에 매여, 아파서 못 나간 날 빼고 거의 매일 일했습니다.
레시피와 매뉴얼은 노션, 구글드라이브, 엑셀, 카톡 네 군데에 흩어져 있었어요. 한 곳에서 고치면 다른 곳도 다 고쳐야 하고, 정작 필요할 땐 못 찾았어요.
재고 조사는 주 2회. 거래처가 빵·면·식자재 등 아주 많은데, 엑셀엔 정렬 버튼이 없으니 100개 가까운 품목을 손으로 다 확인했어요. 한번은 목요일에 발주 넣는 걸 깜빡했고, 금요일 마감을 놓쳤습니다.
급여는 8년 내내, 직원별로 "며칠에 몇 시부터 몇 시까지 일했다"를 손으로 하나하나 계산해서 명세서에 넣었어요.
직원 보건증 만료일처럼 매달 챙겨야 하는 것도 전부 제 기억에 의존했어요. 누군가에게 일을 시키면 "했는지 안 했는지"를 제 머릿속으로 계속 체크해야 했고, 이게 엄청난 압박이었습니다.
결국 근본 원인은 하나였어요. 우리 매장의 모든 지식이 '정리된 문서'가 아니라 '제 머리와 흩어진 파일'에만 있었다는 것. 그래서 뭐든 저를 거쳐야 했죠. 그리고 이런 일들 — 매뉴얼 정리, 급여 계산, 재고 점검 — 은 전부 반복되고, 규칙이 있고, 글·숫자로 된 일이라, 사람이 매번 손으로 할 게 아니라 AI가 제일 잘할 수 있는 종류의 일이었어요.
그동안 다른 방법을 안 써본 게 아니에요.
노션: 입력은 편했지만, 필요한 값 정리(레시피 종류별 정렬 등)가 잘 안 됐고 알림이 안 왔어요. (그래서 재고를 깜빡한 거예요.)
구글드라이브: 자료는 있는데 뒤죽박죽. 수정할 때마다 압축·업로드·재배포가 번거롭고 지원 안 되는 글꼴도 많았어요.
3년 전 파이썬 직접 코딩: 챗GPT(당시 GPT-3.5) 채팅창에 물어가며 급여 자동화 코드를 짜봤는데, 오타 하나만 있어도 프로그램이 안 돌아갔어요. 3일을 내내 붙잡다 포기했고, 국비 지원 파이썬 강의도 들을까 했지만
너무 바빠서 이어가지 못했어요.
▲ 노션에도 만들어봤지만, 정작 필요할 땐 이렇게 비어 있거나 흩어져 있었어요.
▲ 구글드라이브는 자료는 많은데 정리가 안 돼, 필요할 때 못 찾았어요.
결정적 계기는 두 가지. 친구가 자기 회사 전용 위키를 AI로 만든 걸 한 달쯤 전에 봤고 "나도 해야겠다" 싶었어요. 그리고 지피터스가 전남 곡성에서 연 'AI 워케이션 1기'(3박 4일)을 보고 참여신청하며 "이번엔 제대로 옮기자" 마음먹었습니다.
이번 목표는 딱 여기까지로 정했어요. "흩어진 지식을 한 곳에 모으고, 매달 반복하는 수작업만 자동화하자." 매출 예측이나 완전 무인 운영 같은 건 처음부터 욕심내지 않고 범위 밖에 뒀습니다. 할 수 있는 것부터, 확실히요.
🛠️ 사용한 도구
도구: 클로드 코드(Claude Code) , 헤르메스 — AI에게 한국어로 대화하듯 시키면, 직접 파일을 만들고 고치고 인터넷에 올려주는 AI 코딩 도구예요.
모델: Fable 5 — 3년 전 챗GPT도, 얼마 전 버전까지도 제 기준엔 못 미더웠는데, 이 정도 되니 확실히 믿고 맡길 수 있었어요.
왜 이걸 골랐냐면: 3년 전 챗GPT 채팅창은 코드를 "글로만" 알려줬어요. 그 코드를 제가 복사해서 돌려야 했는데, 비개발자한테 그게 제일 큰 벽이었죠. 띄어쓰기 하나만 틀려도 작동을 안하니깐요.
클로드 코드는 제가 말로 시키면 자기가 알아서 파일까지 만들고 고쳐줍니다. 그 차이가 저를 살렸어요.
걸린 시간: 자료 모으기는 몇 주간 짬날 때마다 조금씩 해뒀지만, 이 글의 핵심 — 위키 구축, 급여 자동화(딱 1시간), 비서 봇(반나절) — 은 곡성 워케이션 3박 4일 안에 다 일어났어요.
특이사항: 코드는 한 줄도 안 썼어요. 전부 "이건 이래야 하고, 결과물은 이래야 하고, 예전엔 이런 문제가 있었어" 식으로 상황을 통째로 설명하는 방식으로 진행했습니다.
🔧 작업 과정
흩어진 매뉴얼을 '우리 회사 위키' 한 곳으로
가장 먼저, 네 군데에 흩어진 자료를 한 곳에 모으고 싶었어요. 처음엔 그냥 이렇게 말했어요.
우리 매장 매뉴얼이랑 레시피를 한 곳에서 볼 수 있는 위키로 만들어줘.
그랬더니 모든 문서가 다 보이는 위키가 나왔어요. 그런데 이러면 알바가 관리자용 정보(발주 단가·매출 같은 것)까지 다 보게 되잖아요. 그래서 한 번 더 구체적으로 말했습니다.
알바는 기본 문서만 보이게 하고, 관리자만 볼 수 있는 잠금 문서를 따로 만들어줘.
그리고 직원이 로그인하면 자기 매장 문서만 보이게 해줘.
이렇게 '누가 뭘 볼 수 있는지'까지 콕 집어 말하니 딱 원하는 게 나왔어요. 지금은 레시피·오픈/마감 체크리스트·응대 멘트·컴플레인 매뉴얼까지 78개 문서가 들어 있습니다.
▲ 실제로 만든 우리 매장 위키. 직원이 로그인하면 자기 매장 문서만 보여요.
배운 점: 두루뭉술하게 → 구체적으로 한 끗 바꾸는 게 전부였어요. "위키 만들어줘"가 아니라 "알바는 이것만, 관리자는 잠금"까지 말해주는 것.
사장인 저도 틀렸어요 — 응대 멘트까지 '퀴즈'로
위키에 문서만 쌓아두면 직원들이 잘 안 읽잖아요. 그래서 실제 응대 멘트를 퀴즈로 풀며 익히게 만들었어요. 정답은 우리 매장 매뉴얼에 있는 멘트 토씨 그대로고, 누르는 순간 초록(정답)·빨강(오답)으로 바로 채점돼요.
웃긴 건 — 제가 임신 휴가로 오래(6개월) 쉬다가 오랜만에 이 퀴즈를 풀어봤는데, 사장인 제가 틀렸어요 😂 ('전화 첫마디'를 '안녕하세요'로 골랐는데, 정답은 '감사합니다'로 시작하는 우리 매장 멘트였죠.)
▲ 사장인 제가 우리 매장 응대 멘트 퀴즈를 틀렸어요 😂 6개월 쉬니 사장도 디테일을 잊더라고요.
배운 점: 6개월이면 사장도 디테일을 잊어요. 근데 시스템은 안 잊더라고요. 사람 머리에 기대던 걸 이렇게 정리해두니, 이제 직원들이 저한테 안 물어봐도 스스로 익힐 수 있어요. 제가 제일 원하던 '나한테 묻지 마'가 이렇게 시작됐어요.
8년간 손으로 하던 급여 집계를, 1시간 "대화"로 자동화
3년 전 파이썬으로 실패했던 바로 그 작업이에요. 이번엔 코드 대신 말로 설명했어요. 제가 원래 "이건 이래야 하고, 이 과정에선 이런 문제가 있었고"를 다 설명하는 성격인데, 그게 오히려 통했어요.
직원별로 며칠에 몇 시부터 몇 시까지 일했는지 정리한 데이터가 있어.
이걸로 이번 달 급여명세서를 자동으로 만들어줘.
8년간 손으로 계산했는데 이제 그만하고 싶어.
먼저 어떤 정보가 필요한지 물어보고, 결과가 맞는지 내가 실제 지급액이랑 대조할 수 있게 보여줘.
AI가 먼저 뭘 알려줘야 하는지 되물어봤고, 제가 답해주니 5분 돌리고, 결과 보고, 다시 5분 돌리고… 1시간 만에 매달 반복하던 작업이 자동화됐습니다. 3년 전엔 3일을 붙잡고도 못 한 일이었어요.
▲ 실제 6월 급여대장 결과. 근무시간은 자동 집계, 이름·급여액만 가렸어요.
배운 점: 3년 전에 안 됐던 건 제 능력 문제가 아니라 도구가 아직 무르익지 않았기 때문이었어요. "말로 설명하는 능력"만 있으면 되는 시대가 온 거예요.
시키지도 않았는데, 봇이 내 실수를 먼저 잡았다
재고를 깜빡해 발주를 놓쳤던 그 사고. 다시는 그러기 싫어서, 데이터를 스스로 들여다보는 봇을 헤르메스로 만들어 텔레그램으로 연결해뒀어요.
우리 재고 조사 데이터를 보고,
발주를 깜빡했거나 안전재고보다 부족한 품목이 있으면
먼저 알려주는 봇을 만들어줘.
그리고 바로 어제, 이 봇이 진짜 일을 냈어요.
제가 뭘 물어본 것도 아니에요. 봇이 먼저 "A지점 재고에서 발주가 필요해 보이는 항목들이 있어"라며 목록을 보내줬어요. 피자도우(현재 11 / 안전 20), 냅킨, 치아바타… 안전재고 아래로 떨어진 품목들이었죠. 보는 순간 "아차" 했어요. 제가 발주를 깜빡한 거였거든요.
▲ 제가 묻지도 않았는데 봇이 먼저 "발주 필요 품목"을 찾아 보냈어요. 안전재고 아래로 떨어진 재료들이 목록으로 떴죠. (재료·업체명은 가렸어요.)
문제는 토요일이라서 재료를 구하려면 화요일까지 기다렸어야하는것. 그래서 바로 움직였어요. A지점 동업자에게 "내가 발주를 못 넣어서 물건이 모자랄 거야, 미안해"라고 먼저 사과하고, B지점 직원들에게 "모자란 품목 좀 챙겨서 보내줘"라고 부탁했어요. 두 매장이 서로 물건을 나눠 어제 하루를 간신히, 하지만 무사히 넘겼습니다.
(이날 매출이 평소의 130퍼센트 이상이였어서 정말 큰일날뻔 했어요 ㅠㅠ)
▲ A지점에 사과하고, B지점에 부족한 품목 공수를 부탁해 하루를 넘겼어요.
대박인건 이거예요. 제가 문제를 지적하기 전에, 봇이 먼저 찾았다는 것. 사람은 아무리 똑똑해도 — 게다가 매장에 나가지도 못하는 상황이면 — 다 챙길 수 없어요. 그 구멍을 봇이 메워줬어요. 예전에 노션을 쓰다 알림이 안 와서 발주를 놓쳤던 바로 그 사고가, 이번엔 봇 덕분에 '사고'가 되기 전에 수습된 거예요. (봇은 그 사이 직원 보건증 만료 임박도 따로 찾아줬고요.)
▲ 보건증 만료 임박(⚠️)을 자동으로 띄워줘요. 직원 연락처만 가렸어요.
배운 점: 자동화의 진짜 힘은 "시킨 걸 잘하는 것"이 아니라 "내가 놓친 걸 먼저 알려주는 것" 이더라고요. "내가 기억해야 하는 일"을 "시스템이 먼저 알려주는 일"로 바꾸니, 매장에 없어도 마음이 놓였어요.
AI가 만든 걸, 그대로 믿지는 않았어요
이게 제일 중요한 부분이에요. AI가 똑똑해도 100% 맡기면 안 되잖아요. 그래서 결과가 나올 때마다 사람이 검산할 수 있는 형태로 받았어요.
급여: AI가 만든 명세서를 제가 실제 지급액이랑 한 줄씩 대조했어요. 숫자가 맞아떨어지는 걸 확인하고서야 실제로 썼습니다.
위키: 배포하고 나서 문서를 하나씩 직접 열어보며 레시피 수치나 매장별 차이가 맞는지 검수했어요.
봇 알림: 봇이 "재고 없어요"라고 하면 실제 재고랑 대조해서 진짜 없는지 봤어요. (실제로 맞았고요.)
배운 점: AI한테 "알아서 다 해줘"가 아니라, "내가 확인할 수 있게 보여줘"라고 시키는 것이 핵심이었어요. 그래야 믿고 쓸 수 있어요.
그래서, 내가 없어도 매장이 돌아가는 매장을 완성했습니다.
이 모든 걸 자동화 할 수 있도록 미리 자료들을 전부 아카이빙 하고 만들어둔 게 정말 다행이었어요. 제가 임신이 심해서 6개월간 외출 자체가 불가능했거든요. 매장에 나갈 수가 없었어요.
그런데 그동안 만들어둔 매뉴얼이, 저 없이도 매장이 돌아가게 해줬어요. 그런데 여기서 불편했던 점들을 이제 AI 자동화로서 "흩어져있던 것들이 전부 한눈에"정리해둔 위키가 직원들을 간편하고 덜 힘들게 도와주는 역할을 하게 된거죠. 솔직히 이번 워케이션에 참여하면서 "광명을 찾은 느낌" 이었습니다.
✅ 결과 (After)
Before → After
항목
Before
After
매뉴얼·레시피 위치
노션·드라이브·엑셀·카톡 4곳에 흩어짐
전용 위키 1곳(문서 78개)
신입·알바가 궁금할 때
매번 사장(나)에게 전화·카톡
위키에서 직접 검색
월 급여 근무시간 집계
8년간 직원별 손 계산·입력
스케줄표 기반 자동 생성
급여 자동화 구축
3년 전 파이썬 3일 시도 후 포기
클로드 코드로 완벽하게 완성
재고 발주 관리
엑셀 수기, 깜빡해 발주 누락
봇이 부족 품목 먼저 감지 → 사고 예방
서류(보건증) 만료
내 기억에 의존(놓친 적 있음)
봇이 만료 임박 발견·알림
내가 자리를 비우면
매장 운영이 나에게 의존
임신 6개월 부재에도 운영 지속
지금 실제로 이렇게 쓰고 있어요
급여 자동화 — 이번 달부터 매달 이걸로 돌리고 있어요.
위키 — 지금 라이브로 떠 있고, 관리자에게는 배포 완료했어요. 곧 직원들에게 정식으로 열 예정이에요.
알림 봇 — 이미 제 실수를 실제로 잡아줬어요. 바로 어제, 봇이 먼저 발주 누락을 찾아내 두 매장이 물건을 나눠 사고를 막았고, 직원 보건증 만료 임박도 따로 잡아줬어요.
정직한 한계: 카카오톡 연결은 아직 세팅 중(오픈 전), 재고 자동 예측(POS 연동)은 아직 시작 전입니다. 그래서 "직원이 써보니 좋더라" 같은 제3자 후기는 아직 없어요. 이건 솔직히 배포하면 바로 박수 나올 예정이라고 확신합니다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
AI를 "오늘 새로 온 직원"이라고 생각하고, 아는 걸 다 말해주기. "이건 이래야 하고, 결과물은 이래야 하고, 예전엔 이런 문제가 있었어"까지 상황을 통째로 설명했더니 찰떡같이 알아들었어요.
두루뭉술 → 구체적으로, 한 끗만 바꾸기. "위키 만들어줘"는 실패, "알바는 이것만·관리자는 잠금"은 성공. 원하는 걸 콕 집는 게 전부였어요.
이미 쌓아둔 데이터·매뉴얼이 제일 큰 무기. AI를 가장 잘 쓰는 사람은 프롬프트 고수가 아니라 이미 자기 문제와 데이터가 쌓여 있는 사람이더라고요.
"알아서 해줘" 대신 "내가 확인할 수 있게 보여줘". 그래야 AI 결과를 믿고 쓸 수 있어요.
이렇게 하면 안 돼요 (제가 겪은 함정)
도구가 무르익기 전에 무리하지 마세요. 3년 전 파이썬 직접 코딩은 오타 하나에 다 멈춰서 3일 만에 포기했어요. 지금은 훨씬 쉬워졌습니다.
모르는 걸 부끄러워하지 마세요. 저는 아직도 Supabase·SQL이 뭔지 몰라요. 막히면 그냥 AI에게 "이게 뭔지 모르겠는데 뭘 하면 돼?" 라고 물어보면 돼요.
민감정보는 공개되는 곳에 절대 올리지 마세요. 비밀번호·계좌·주민번호는 위키에 넣지 않고, 관리자만 열 수 있는 잠금 문서로 분리했어요.
🌍 다른 업무에 적용한다면?
제 경험상 이 세 가지에 해당하는 일이면 거의 다 됩니다: ① 매달·매주 반복되고 ② 규칙이 있고 ③ 글이나 표로 된 업무. 급여·재고·매뉴얼이 딱 그랬어요.
다른 자영업(병원·미용실·학원·공방): 매뉴얼·예약·재고 구조가 비슷해서 "흩어진 자료 → 전용 위키" 그대로 이식됩니다. 신입 교육 시간을 크게 줄일 수 있어요.
사무직의 반복 엑셀 업무: 주간 보고서, 월 정산처럼 매달 손으로 하는 집계를, 급여 자동화와 똑같이 "데이터 줄게, 이 결과물로 만들어줘"로 처리할 수 있어요.
개인·팀 리마인드: "누가 뭘 했는지 / 언제까지 뭘 해야 하는지" 챙겨주는 봇은 어떤 직군이든 응용됩니다. 저는 이걸로 재고·서류 만료를 챙겨요.
시작하기 전 알아둘 것: 유료 구독이 필요하고, 회사 데이터를 AI에 넣는 게 걱정되면 저처럼 민감정보(비번·계좌·개인정보)만 빼고 시작하면 됩니다. 조직에서 쓸 땐 보안 규정·승인부터 확인하세요. 따라 하면 첫 결과물은 한 시간 안에 볼 수 있어요.
반대로, 이건 AI한테 안 맡겨요. 직원들의 특성을 파악해 동기부여를 하거나, 많이 화가 난 손님을 대면으로 달래는 것처럼 사람의 공감·태도가 필요한 일은 여전히 제 몫이에요. AI는 반복되고 규칙 있는 일을 덜어주는 거지, 사장의 판단을 대신하진 않더라고요.
🚀 앞으로의 계획
재고 자동 예측: 우리 POS(토스포스)의 매출·재고 데이터를 연동해, 부족할 재고를 미리 예측·발주하게 만들기.
카카오톡 연결: 실무가 대부분 카톡에서 이뤄지니, 알림 봇을 카톡으로 연결하기.
알바까지 확대: 위키와 봇을 파트타이머까지 열어서 "셀프교육" 이 되는 교육 시스템 완성하기.
직접 교육: 돌아가서 직원들에게 AI 활용 법을 직접 가르치기. 직원들도 다양한 아이디어로 AI를 활용하면서 더 편하게 일할 수 있을 거예요.
📋 재사용 가능한 프롬프트
프롬프트 1: 흩어진 자료를 '우리 회사 위키'로 모으기
우리 [매장/회사]의 [매뉴얼·레시피·업무 지식]이 [노션·구글드라이브·엑셀·카톡] 여러 곳에 흩어져 있어. 직원들이 한 곳에서 검색해서 볼 수 있는 웹사이트(위키)로 만들어줘. [일반 직원]은 기본 문서만 보이게 하고, [관리자]만 볼 수 있는 잠금 문서도 따로 필요해. 내가 자료를 하나씩 줄 테니 순서대로 정리해서 넣어줘.
[대괄호] 안은 본인 상황에 맞게 바꿔 쓰세요.
프롬프트 2: 매달 반복하는 수작업 자동화하기
내가 매달 [직원별 근무시간]을 손으로 [급여명세서]에 입력하고 있어. [며칠에 몇 시부터 몇 시까지 일했다]는 데이터를 줄 테니, 이걸로 [이번 달 결과물]을 자동으로 만들어줘. 먼저 어떤 정보가 필요한지 나한테 물어보고, 결과가 맞는지 내가 [실제 값]이랑 대조할 수 있게 표로 보여줘.
[대괄호] 안을 본인 반복 업무(정산·리포트·집계 등)로 바꾸면 그대로 쓸 수 있어요.
🤫 마지막 고백 — 사실 이 글도 제가 '쓴' 게 아니에요
솔직히 말하면, 저 글쓰기를 진짜 너무너무 싫어해요. 이런 후기 글은 제 인생에서 제일 안 어울리는 일이에요. 그래서 이 글도, 실은 제가 겪은 일을 AI한테 말로 쭉 들려주고 같이 완성한 거예요. 저는 "이땐 이랬고, 저땐 저랬고" 수다 떨듯 말했을 뿐이고요.
근데 진짜 포인트는 이거예요. 저는 얼마 전까지 '스킬(skill)'이라는 말만 들어도 무서웠던 사람이에요. (스킬은 AI한테 "이런 종류의 일은 이런 순서로 만들어줘"라고 미리 짜두는 자동 틀 같은 건데, 그 단어 자체가 저 같은 AI 바보한텐 '개발자들이나 쓰는 어려운 것' 같았거든요.) 솔직히 "나는 절대 저런 거 못 써" 싶었어요.
그런 제가, 그 무섭던 '스킬'을 써서 지금 이 후기를 썼어요.
그러니까 이 글은 — 글쓰기라면 질색하는 AI 바보가 → 이름만 들어도 겁나던 '스킬'까지 꺼내 써서 → 끝내 완성한 후기예요. 저처럼 겁내던 사람도 됐으니, 이거 읽는 분은 진짜 누구나 할 수 있어요. 무서워하던 그 단어, 그냥 한번 눌러보세요.
🤝 무에서 유까지 3박 4일 — 곡성의 '찐 기버'들
이걸 꼭 말하고 싶어요. 이 글의 핵심 장면들 — 위키가 살아나고, 급여가 자동으로 돌고, 봇이 제 실수를 잡아준 것 — 은 전부 지피터스가 전남 곡성에서 연 'AI 워케이션 1기', 딱 3박 4일 안에 일어난 일이에요. 그런데 그 3박 4일 동안, 저는 단 한 번도 혼자인 적이 없었어요.
운영진분들만 도와주신 게 아니에요. 함께 참가한 멤버 한 분 한 분이 전부 '찐 기버'였어요. 제가 막힐 때마다 누군가 다가와 알려주셨고, 비개발자 왕초보인 제가 완전히 초보적인걸 물어봐도 아무도 이상하게 보지 않았어요. 다들 각자 자기 프로젝트가 있는데도, 서로 봐주고 알려주고 같이 기뻐하면서 으쌰으쌰했어요. 그 분위기 속에서 — 코딩도 모르고, 스킬이란 말만 들어도 무섭던 제가 — 무에서 유를 창조해냈습니다.
혼자 집에서 했다면 아마 3년 전 파이썬 때처럼 3일, 아니 하루만에 포기했을 거예요. 같이 하는 사람들이 있어서, 3일이 '포기'가 아니라 '완성'이 됐어요.
▲ 무에서 유를 함께 만든 곡성 'AI 워케이션 1기' 멤버들. (얼굴은 가렸지만, 이 안에 제 은인들이 다 있어요.)
🙏 마지막으로, 지피터스에게
저는 지푸라기라도 잡는 심정으로 이번 AI워케이션 1기 곡성에 참여했어요. 전엔 입덧이 심해서 외출도 못 하던 때였고, 매장 셋을 8년째 제 머리와 몸으로만 붙들고 있던 사람이었습니다.
솔직히 저는 아직도 Supabase가 뭔지, SQL이 뭔지 몰라요. 대단한 개발자가 된 것도 아니에요. 그런데 이 커뮤니티에서 보고 배운 것들이, 그리고 곡성에서 만난 운영진분들과 멤버분들 한 분 한 분이, "매장에 갇힌 삶"에서 저를 꺼내줬습니다. 이제 제가 자리를 비워도 매장이 돌아가고, 8년간 손으로 하던 일이 말 몇 마디로 끝나요.
돌아가면 이걸 직원들, 가족들, 친구들, 주변사람들에게 하나씩 가르칠 거예요. 곡성에서 제가 받은 것처럼요. 저처럼, 일에 짓눌리지 않고 일하는 사람이 한 명이라도 더 늘었으면 좋겠어요. 지피터스 스터디 23기도 오늘 돌아가자마자 등록할거에요 :)!
자영업자 하나 살려주셔서, 진심으로 감사합니다. 이 은혜, 저도 누군가에게 갚을게요. 🙇♀️
📝 한줄 요약
개인정보 동의서는 겉으로 보면 간단한 서식처럼 보이지만, 실제로는 수집·이용, 제3자 제공, 업무위탁, 민감정보, 고유식별정보(주민등록번호·여권번호·운전면허번호 등), 주민등록번호 처리처럼 여러 법적 판단이 겹쳐 있는 문서였습니다. 그래서 AI에게 단순히 "동의서 만들어줘"라고 시키는 대신, 법령과 공식 자료를 근거로 삼고, 확인되지 않은 사실은 문서에 넣지 못하게 막는 작성기를 만들었습니다.
바쁘시면 이것만 읽어도 돼요:
Claude Code와 Codex CLI를 함께 써서 개인정보 동의서 작성기를 만들었습니다.
목표는 "그럴듯한 샘플 생성"이 아니라, 법적으로 위험하면 멈추는 작성기였습니다.
공식 자료 14종 이상, 실무 샘플 31종, 골든 케이스(정답을 정해두고 결과를 비교하는 대표 시나리오) 19종을 기준으로 검증했습니다.
수집·이용인지, 제3자 제공인지, 업무위탁인지도 사용자의 선택만 믿지 않고 사실관계로 다시 판단하게 했습니다.
가장 중요한 전환점은 AI가 모르는 값을 채워 넣지 못하게 한 "실전 작성 모드"였습니다.
최종 법적 판단은 사람의 검토가 필요하지만, 빠뜨리기 쉬운 위험을 먼저 걸러내는 도구로 만들었습니다.
🎯 이런 분들께 도움돼요
개인정보 동의서를 직접 만들어야 하는 소상공인, 스타트업 총무·운영 담당자
법정 필수기재사항이 있는 문서를 다루지만 개발자나 법률가는 아닌 실무자
고위험 업무에 AI를 쓰고 싶지만, AI가 그럴듯하게 지어내는 것이 걱정되는 사람
"AI가 문서를 대신 써준다"보다 "AI가 틀리면 막아준다"는 방식에 관심 있는 사람
😫 문제 상황 (Before)
개인정보 동의서는 생각보다 위험한 문서입니다.
이름과 휴대전화번호를 받는 것처럼 단순해 보이는 상황에서도, 실제로는 다음 질문이 따라붙습니다.
이 정보는 우리가 직접 수집해서 쓰는 것인가?
외부 회사에 넘기는 것인가?
외부 회사가 우리 업무만 대신하는 것인가?
그 외부 회사가 자기 목적에도 쓰는가?
마케팅 안내는 필수 동의에 묶어도 되는가?
주민등록번호를 받아도 되는 법적 근거가 있는가?
보유기간은 내부 기준으로 정하면 되는가, 법에서 따로 정한 기간이 있는가?
이 작업의 출발점은 간단했습니다. 겉으로는 서식 작성처럼 보이는 일이 실제로는 수집·제공·위탁을 가르는 법적 판단이고, 비법률가가 잘못 쓰면 과징금이나 형사책임으로 이어질 수 있다는 점을 분명히 인식한 것입니다.
실무자는 대개 "개인정보 동의서 하나 필요하다"고 생각합니다. 그런데 법적으로는 그 안이 여러 블록으로 갈라집니다. 수집·이용 동의, 제3자 제공 동의, 업무위탁 안내, 민감정보 동의, 고유식별정보 동의, 동의 없이 처리하는 개인정보 안내가 서로 다릅니다.
게다가 개인정보를 받는 일은 한 번으로 끝나지 않습니다. 회원가입, 이벤트, 채용, 배송, 예약처럼 사업을 운영하는 내내 반복되는 업무라서, 매번 사람의 기억과 복붙에 맡기기에는 위험이 누적됩니다.
특히 어려운 지점은 "수집이냐, 제3자 제공이냐, 위탁이냐"를 가르는 일입니다. 예를 들어 배송업체에 고객 정보를 넘긴다고 해서 항상 제3자 제공인 것은 아닙니다. 그 업체가 우리 업무만 대신하는지, 아니면 자기 사업 목적에도 쓰는지에 따라 결론이 달라질 수 있습니다.
기존 대안도 충분하지 않았습니다.
첫째, 서식 복붙은 케이스별 차이를 잡아내지 못합니다. 어느 서식에는 주민등록번호가 있고, 어느 서식에는 제3자 제공 표가 있고, 어느 서식에는 위탁 안내가 있습니다. 그런데 내 업무에 어느 것이 필요한지는 별도 판단이 필요합니다.
둘째, 인터넷 예시나 오래된 해설서는 최신 법령과 맞지 않을 수 있습니다. 개인정보보호법은 여러 차례 크게 바뀌었고, 예전 자료에는 지금 기준과 맞지 않는 설명이 섞여 있을 수 있습니다.
셋째, AI에게 그냥 물어보는 것도 위험합니다. AI는 빈칸을 싫어합니다. 목적, 항목, 보유기간, 제공받는 자가 부족하면 그럴듯한 값을 만들어 채울 수 있습니다. 일반 글쓰기라면 편리한 기능이지만, 법률 문서에서는 치명적인 문제가 될 수 있습니다.
그래서 목표를 이렇게 잡았습니다.
"개인정보 동의서를 자동으로 만들어주는 도구"가 아니라, "법적 근거와 사용자 확인이 없으면 문서 생성을 막는 도구"를 만들자.
규칙이 분명하고 반복되는 문서 판단이라는 점에서 AI와 자동화가 잘 맞는 일이었지만, 그만큼 근거 없는 자동완성은 강하게 막아야 했습니다.
🛠️ 사용한 도구
Claude Code: 전체 설계, 법률 판단 구조화, 룰 설계, 검증 기준 정리, 작업 지휘
Codex CLI: 병렬 구현, 웹 작성기 개선, 테스트 보강, 생성 결과 정리
/show-me-the-prd: 막연한 아이디어를 기획서와 단계별 구현 계획으로 바꾸는 데 사용
품앗이: 여러 구현 작업을 나누어 동시에 진행하는 데 사용
Ralph: 논리 구조와 하네스가 맞는지 검토하는 데 사용
insane-search: 실무 샘플과 참고 자료를 찾고 정리하는 데 사용
모델: Claude Opus·Haiku 계열과 Codex 기반 코딩 에이전트
도구를 나눈 이유는 단순합니다. 법률 판단과 제품 방향은 한 곳에서 강하게 통제하고, 반복 구현과 테스트는 병렬로 밀어붙이기 위해서였습니다.
일반 챗봇 하나에 물어보는 대신 Claude Code를 쓴 이유는, 로컬에 모아둔 공식 자료를 직접 대조하고, 같은 절차를 반복 가능한 형태로 만들며, 근거 없는 답을 구조적으로 막아야 했기 때문입니다.
🔧 작업 과정
한 문장을 기획서로 바꾸기
처음에는 아이디어가 컸습니다. "개인정보 동의서를 자동으로 만들고 싶다"는 말만으로는 무엇부터 만들어야 할지 알기 어려웠습니다.
그래서 먼저 AI에게 제품 기획자 역할을 맡겼습니다.
이 자료들을 근거로 개인정보 수집 동의서·제3자 제공 동의서·위수탁 동의서·민감정보·고유식별정보 동의서 작성 자동화 파이프라인을 만들고 싶다. 일률적 서식은 금지, 법령 요구사항을 빠짐없이 반영하고, '수집/제3자제공/위탁'을 판별하는 로직이 필요하다. 사용자는 비법률가다.
AI는 바로 코딩을 시작하지 않았습니다. 어떤 문서를 만들 것인지, 어떤 법적 판단이 필요한지, 어떤 데이터를 받아야 하는지, 어떤 경우에는 생성을 막아야 하는지부터 쪼갰습니다.
이 과정에서 제품 개요, 데이터 구조, 단계별 구현 계획, 검증 기준이 생겼습니다. 막연한 문장 하나가 실제 개발 가능한 기획서로 바뀐 것입니다.
여기서 배운 점은 분명했습니다. AI에게 "바로 만들어줘"라고 하기 전에, 먼저 "나를 인터뷰해서 설계로 바꿔줘"라고 시키면 훨씬 안전합니다.
진짜 실무 서식으로 검증하기
기획서만으로는 부족했습니다. 법적으로 맞는 것처럼 보이는 설계가 실제 서식 관행과 어긋날 수 있기 때문입니다.
그래서 실제로 사용된 개인정보 동의서 샘플을 모아 분석했습니다.
각종 사이트에서 개인정보 동의서 샘플을 수집해야 함. 주택청약 관련은 한국부동산원, 나머지는 대표 서비스 사이트에서 개인정보 제공 동의서 샘플을 받아 분석할 것.
분석 대상에는 주택청약, 금융, 병원, 공공기관, 법정서식 등 여러 분야가 들어갔습니다. 총 31종의 실무 샘플을 보면서 중요한 사실이 드러났습니다.
실제 서식은 "한 장짜리 동의서"처럼 보여도 내부적으로는 여러 동의 블록으로 나뉘어 있었습니다. 필수 수집·이용, 선택 수집·이용, 제3자 제공, 민감정보, 고유식별정보, 위탁 안내가 한 문서 안에 섞여 있었습니다.
또 하나의 발견은 위탁과 제3자 제공의 경계가 실무에서 자주 흐려진다는 점이었습니다. 사용자는 그냥 "외부 업체에 준다"고 말하지만, 법적으로는 그 외부 업체가 어떤 지위인지 다시 확인해야 했습니다.
이 단계에서 설계가 많이 바뀌었습니다. 단순히 항목을 입력받아 표를 만드는 방식이 아니라, 사용자의 업무 흐름을 먼저 묻고 필요한 문서 블록을 자동 산정하는 방식으로 방향을 잡았습니다.
AI 설계도 실제 사례로 검증해야 탁상공론을 피할 수 있다는 점을 크게 느꼈습니다.
혼자 짜지 않고, 판단과 구현을 나누기
전체 구조가 잡히자 구현량이 커졌습니다. 법령 근거를 연결해야 하고, 위험 항목을 검증해야 하고, 문서를 만들어야 하고, 테스트도 필요했습니다.
이때 사용한 방식이 병렬 작업이었습니다.
품앗이로 Phase 1 만들어줘
핵심 법률 판단, 룰, 조문 연결, 문서 구조는 Claude가 직접 통제했습니다. 반면 반복 구현, 문서 생성기, 검증기, 테스트, 웹 작성기 같은 작업은 Codex 여러 개에 나누어 맡겼습니다.
이 방식의 장점은 속도만이 아니었습니다. "법적 판단은 한 곳에서 일관되게 하고, 손이 많이 가는 구현은 여러 AI에게 나눈다"는 구조가 생겼습니다.
한 AI로 처음부터 끝까지 순차로 만들 수도 있었지만, 구현량이 많아 느리고 법률 판단까지 흩어질 위험이 있어 판단은 한 곳에 모으고 구현만 병렬로 나누는 방식을 골랐습니다.
AI를 여러 개 쓴다고 해서 모든 판단을 흩어놓으면 오히려 위험합니다. 이 프로젝트에서는 판단의 중심은 좁게, 작업의 손은 넓게 가져갔습니다.
공식 자료를 물려서 지어내지 못하게 하기
개인정보 문서에서 가장 위험한 것은 "그럴듯한 법률 설명"입니다. 그래서 공식 자료를 조각내어 검색하고 인용할 수 있도록 연결했습니다.
개인정보 보호법, 시행령, 표준지침, 통합 안내서, 사례집, 질의응답, 동의서 작성 가이드 등을 법령 다음 우선순위의 참고자료로 반영해줘. 주민등록번호와 보유기간도 실제 근거를 찾아 검증에 활용하고 싶어.
여기에는 개인정보보호법, 시행령, 표준 개인정보 보호지침, 개인정보 처리 통합 안내서, 분야별 안내서, 질의응답, 공공기관 안내, 실무교재, 상담사례, 주민등록번호 사례집, 지방자치단체 사례집, 동의서 작성 가이드 등이 들어갔습니다.
총 14종 이상의 자료를 연결하면서 원칙을 하나 세웠습니다.
근거가 없으면 말하지 않는다.
예를 들어 주민등록번호는 단순히 사용자가 원한다고 받을 수 없습니다. 법률이나 대통령령 등에서 구체적으로 요구하거나 허용하는 경우가 아니면 처리할 수 없기 때문입니다. 그래서 작성기는 주민등록번호가 등장하면 근거 후보를 찾고, 없으면 문서 생성을 막도록 했습니다.
보유기간도 마찬가지였습니다. 사용자가 "잘 모르겠다"고 해도 작성기가 아무 기간이나 제안하면 안 됩니다. 법령상 보존기간이 있는지 먼저 찾고, 없으면 목적 달성에 필요한 최소 기간을 내부 기준으로 정하도록 안내해야 했습니다.
이 과정에서 AI의 역할이 바뀌었습니다. "문장을 만들어주는 도구"가 아니라 "자료를 대조하고 근거를 요구하는 도구"가 된 것입니다.
AI가 모르는 값을 지어내 채우는 문제를 막기
가장 중요한 전환점은 테스트 중에 나왔습니다.
음식점 사례로 개인정보 수집·이용 동의서와 제3자 제공 동의서를 만들어 보자고 했을 때, AI가 너무 잘했습니다. 목적, 항목, 제공받는 자, 보유기간까지 꽤 그럴듯하게 채워 넣었습니다.
문제는 바로 그 점이었습니다. 사용자가 말하지 않은 사실까지 AI가 샘플처럼 채워 넣은 것입니다. 샘플 문서로는 좋아 보이지만, 실제 업무에서는 위험합니다. 제공받는 자가 누구인지, 어떤 목적으로 제공되는지, 어떤 항목이 제공되는지는 실무자가 직접 확인해야 하는 사실입니다.
AI가 너무 잘 채워줘서 오히려 겁이 났습니다. 처음 요청은 "동의서를 만들어보자"에 가까웠지만, 이 순간부터 요청의 중심이 "확인 안 한 값은 넣지 마"로 바뀌었습니다.
이 문제를 보고 방향을 바꿨습니다.
진짜 실전처럼 해보자. 샘플만 이런식으로 찍어내는 것은 아무런 의미가 없어. 정말 자세하고 세밀하게 작성해야 해. 단계마다 강한 하네스 엔지니어링을 통해 해당 단계가 위법하지 않은지를 먼저 판단해야 하고, 다음 단계에서 필요한 사항이 무엇인지를 추천할 수 있어야 해.
그래서 "실전 작성 모드"를 넣었습니다.
추천값과 사용자 확정값을 분리했습니다. AI가 추천할 수는 있지만, 사용자가 직접 확인하지 않은 값은 최종 문서에 들어가지 못하게 했습니다. 목적, 항목, 보유기간, 제공받는 자, 제3자 제공 세부사항처럼 법적으로 중요한 값은 빈칸이면 생성이 보류되도록 했습니다.
이 프로젝트의 핵심은 여기였습니다.
AI를 더 자유롭게 만드는 것이 아니라, AI가 모를 때 멈추게 만드는 것.
고위험 업무에서는 이 차이가 매우 큽니다.
터미널 숫자 입력에서 체크박스 웹 작성기로
초기 테스트는 터미널에서 숫자를 입력하는 방식이었습니다. 개발자에게는 괜찮지만, 비법률가 실무자가 쓰기에는 불편했습니다. 무엇을 선택하면 어떤 법적 효과가 생기는지 한눈에 보기 어려웠기 때문입니다.
그래서 웹 작성기로 바꿨습니다.
이것을 체크박스로 해서 여러 개를 체크할 수 있도록 하면 어떨까? 만약 여기 터미널 창에서 구현하는 것이 어렵다면 웹앱으로 만들거나 다른 방식으로 구현하면 어때?
웹 작성기는 10단계 흐름으로 구성했습니다. 사용자는 먼저 업무 상황을 고르고, 개인정보처리자 성격을 확인하고, 정보주체와 처리 목적을 정하고, 필요한 항목과 보유기간, 동의 방법, 동의 블록을 차례로 확정합니다.
각 단계에는 추천 선택지가 붙었습니다. 예를 들어 음식점, 카페, PC방, 노래연습장처럼 개인정보 처리 방식이 비슷한 업종은 처리 유사 프로파일로 묶었습니다. 업종 이름만 전통적으로 비슷한 것이 아니라, 개인정보 서류를 유사하게 쓰는지 기준으로 묶은 것입니다.
또한 위험한 선택지는 바로 표시했습니다. 마케팅 목적 항목을 필수 동의에 묶으려 하면 경고가 뜨고, 주민등록번호처럼 법적 근거가 필요한 항목은 별도 검토가 필요하다고 안내합니다.
이 과정에서 여러 번 UI를 고쳤습니다. 추천 버튼이 눌리지 않는 문제, 글자가 잘리는 문제, 개발자 같은 "단계 검토" 화면, 마지막 단계에서 생성 보류가 뜨는 문제도 하나씩 잡았습니다.
좋은 안내는 한꺼번에 많은 설명을 주는 것이 아니라, 사용자가 선택하는 순간 그 선택의 의미와 위험을 보여주는 것이라는 점을 배웠습니다.
AI가 만든 계획을 다시 AI로 검증하기
작업이 커질수록 "이 구조가 정말 맞나?"라는 문제가 생겼습니다. 4단계와 6단계가 중복되는지, 5단계와 6단계 순서가 맞는지, 동의 방법 질문과 접수 방식 질문이 중복되는지 같은 논리 문제가 계속 나왔습니다.
ralph로 지금까지 했던 작업을 검증해서 개인정보 서류 작성 하네스를 논리적 정합성에 맞게 구성해줘.
이때는 별도 검증 루프를 돌렸습니다. AI가 세운 구조를 다시 AI에게 검토시키고, 사용자가 지적한 모순을 기준으로 하네스를 고쳤습니다.
특히 중요한 결론은 이것이었습니다.
사용자에게 모든 법률 판단을 맡기면 안 됩니다. 하지만 AI가 사용자의 의사를 무시하고 결론을 확정해서도 안 됩니다.
그래서 구조를 이렇게 잡았습니다.
사용자는 사실관계를 입력합니다. AI는 그 사실관계를 바탕으로 처리유형과 필요한 문서 블록을 자동 산정합니다. 사용자가 생각한 판단과 AI 판단이 다르면, AI가 조용히 덮어쓰는 것이 아니라 충돌을 표시하고 다시 확인하게 합니다.
이것이 이 작성기의 중요한 설계 원칙이 되었습니다.
✅ 결과 (After)
결과물은 단순한 동의서 생성기가 아니라, 단계별로 사실관계를 확인하고, 법적 위험을 표시하며, 확인되지 않은 값이 있으면 생성을 보류하는 개인정보 문서 작성기입니다.
Before vs After
항목
Before
After
필수 항목 누락 확인
사람이 조문을 일일이 대조해야 했고, 빠뜨려도 알아차리기 어려움
자동 검증 배터리 15/15 통과 기준으로 누락과 위험을 표시
법적 근거
예시 서식이나 AI 답변을 그대로 믿으면 환각 위험
판단마다 조문과 출처를 연결하고 인용 무결성을 검사
주민등록번호 같은 위험 항목
사용자가 원하면 무심코 수집 항목에 넣을 수 있음
법적 근거가 없으면 자동 차단
실무 사례 반영
서식 하나를 복사해 쓰는 방식
실무 샘플 31종을 분석해 문서 블록 구조에 반영
법령·근거 대조
사람이 개인정보보호법 조문과 공식 자료를 일일이 대조해야 해 빠뜨린 부분을 확인하기 어려움
공식 자료 14종 이상을 자동 대조·인용하고, 골든 케이스 19종으로 누락과 위험을 회귀 검증
문서 구조 인식
실무자 인식은 "동의서 1장"에 머물기 쉬움
케이스별로 필요한 동의 블록을 최대 7종까지 자동 산정
구축 규모
해당 없음
3일 동안 공식 자료 14종 이상, 골든 케이스 19종, 자동 검증 배터리 15/15 기준으로 구축
결과물
완성된 작성기는 다음을 수행합니다.
개인정보 수집·이용 동의서 초안 생성
제3자 제공 동의서 초안 생성
업무위탁 안내와 위탁계약 검토 항목 안내
마케팅 선택 동의 분리
민감정보·고유식별정보·주민등록번호 위험 검토
법령상 보존기간 후보 확인
사용자가 확인하지 않은 사실이 있으면 생성 보류
생성된 문서를 화면에서 미리 보고, 문서 파일로도 저장
검증 방식도 함께 만들었습니다.
골든 케이스 19종으로 대표 시나리오의 기대 결과와 비교
일부러 위험 케이스를 넣어 반드시 차단되는지 확인
문서에 들어간 조문과 출처가 실제 자료와 연결되는지 검사
생성 문서의 중요 표시와 동의 블록 분리 여부 확인
웹 작성기에서 단계별 완료 상태가 실제 입력 완료와 맞는지 확인
다만 이것을 법률 전문가의 최종 검토를 대체하는 도구라고 보지는 않습니다. 자동 검증은 위험을 줄여주지만, 최종 법적 판단은 개인정보 보호책임자나 법률 전문가의 검토가 필요합니다. 이 점은 생성 문서에도 명시했습니다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
먼저 AI에게 질문하게 하기
처음부터 "만들어줘"라고 하지 않고, AI가 나를 인터뷰하게 했습니다. 덕분에 사용자가 제공해야 할 사실과 AI가 판단해야 할 부분을 분리할 수 있었습니다.
근거 자료를 먼저 먹이고, 출처 없으면 말하지 못하게 하기
법률 문서에서는 유창한 설명보다 출처가 중요합니다. 공식 자료를 조각내 연결하고, 판단마다 근거를 요구하니 환각 위험을 줄일 수 있었습니다.
판단과 구현을 나누기
법률 판단은 일관되게 관리하고, 구현은 여러 AI에게 병렬로 맡겼습니다. 덕분에 속도와 통제력을 함께 가져갈 수 있었습니다.
사용자 확정값과 AI 추천값을 분리하기
AI가 추천한 값은 편리하지만, 사용자가 확인하지 않은 사실은 문서에 들어가면 안 됩니다. 이 분리가 실전 도구와 샘플 생성기의 차이를 만들었습니다.
테스트를 결과물이 아니라 안전장치로 보기
테스트는 개발자를 위한 형식적 절차가 아니라, "이 문서가 위험한 상황에서 멈추는가"를 확인하는 안전장치였습니다.
이렇게 하면 안 돼요
예시 서식 하나를 만능처럼 쓰기
업종과 목적이 다르면 필수 항목, 제공받는 자, 보유기간, 동의 블록이 달라집니다.
오래된 자료를 최신 확인 없이 신뢰하기
법령과 지침은 바뀝니다. 특히 개인정보보호법은 개정 이력이 많기 때문에 최신 공식 자료를 우선해야 합니다.
AI가 채운 값을 그대로 믿기
AI가 그럴듯한 제공받는 자, 목적, 보유기간을 써도 실제 사실과 다르면 문서 전체가 위험해질 수 있습니다.
사용자에게 법률용어를 그대로 던지기
"제3자 제공인지 위탁인지 선택하세요"라고 묻는 것만으로는 부족합니다. 사용자는 사실관계를 말하고, 도구가 법적 분류를 도와야 합니다.
🌍 다른 업무에 적용한다면?
이 방식은 개인정보 동의서에만 쓰이는 방식이 아닙니다.
핵심은 세 가지입니다.
첫째, 공식 근거 자료를 먼저 정리한다.
둘째, 사용자가 확인해야 할 사실과 AI가 판단할 수 있는 부분을 나눈다.
셋째, 확인되지 않은 값은 AI가 채우지 못하게 막는다.
정리하면, 반복적으로 작성하고, 법령·기준 같은 규칙이 정해져 있으며, 텍스트 중심으로 결과물이 나오는 문서 업무라면 이 방식을 그대로 옮길 수 있습니다.
예를 들어 표준 근로계약서, 취업규칙, 하도급 계약서처럼 법정 필수기재사항이 많은 문서에도 비슷한 방식이 가능합니다. 관련 법령과 공식 지침을 근거 자료로 연결하고, 사용자가 사실관계를 입력하면, AI가 필요한 조항과 누락 위험을 검토하게 할 수 있습니다.
세무 신고, 의료 안내문, 보조금 신청서처럼 틀리면 손해가 큰 업무에도 적용할 수 있습니다. 이런 업무에서 중요한 것은 AI가 얼마나 많이 쓰느냐가 아니라, 모르는 것을 얼마나 잘 멈추느냐입니다.
즉, 고위험 AI 업무의 기준은 "자동 완성"이 아니라 "자동 제동"이어야 합니다.
다만 도입 장벽도 있습니다. 대화형 AI와 복붙만으로 작게 시작할 수는 있지만, 실무에 쓰려면 근거 자료를 준비하고 조직의 보안 규정과 전문가 검수 절차를 함께 세워야 합니다.
🚀 앞으로의 계획
다음 단계는 전문가 검수입니다.
자동 검증 배터리를 통과했다고 해서 바로 실무 배포가 끝나는 것은 아닙니다. 개인정보 보호책임자나 변호사가 실제 생성 문서와 판단 기준을 검토하고, 어떤 문구는 더 보수적으로 바꿔야 하는지 확인해야 합니다.
그다음에는 분야 확장이 가능합니다.
현재는 개인정보 동의서와 위탁, 제3자 제공, 주민등록번호, 보유기간 검토에 집중했습니다. 앞으로는 채용, 의료, 공공기관, 학원, 온라인 이벤트처럼 분야별로 더 세밀한 질문과 추천값을 붙일 수 있습니다.
마지막으로, 이 방식을 다른 법정 문서 작성기로 확장해보고 싶습니다. 개인정보 동의서에서 만든 원칙, 즉 "근거를 먼저 연결하고, 확인 안 된 값은 막고, 위험하면 멈추는 구조"는 다른 법률 문서에도 그대로 적용할 수 있기 때문입니다.
📋 재사용 가능한 프롬프트
프롬프트 1: 한 문장을 기획서로 바꾸기
[만들고 싶은 것]을 [근거 자료]를 바탕으로 만들고 싶어. 반드시 지킬 것: [핵심 제약 3가지]. 사용자는 [대상]이야. 바로 만들지 말고, 먼저 인터뷰식 질문으로 필요한 정보를 끌어낸 뒤 기획서부터 만들어줘. 특히 사용자가 입력해야 할 사실과 AI가 판단해도 되는 부분을 나눠줘.
프롬프트 2: AI가 지어내지 못하게 막기
[문서]를 작성하되, 내가 직접 확인하지 않은 값은 본문에 넣지 마. 네가 추천한 값과 내가 확정한 값을 분리하고, 확인 안 된 항목은 임의로 채우지 말고 "확인 필요"로 멈춰. 모든 판단에는 [근거 자료 또는 조문]을 붙이고, 근거가 불명확하면 문서 생성을 보류해줘.
프롬프트 3: 고위험 업무 검증 루프 만들기
[업무명]에 AI를 쓰려고 해. 틀리면 문제가 되는 지점을 먼저 찾아줘. 각 위험 지점마다 "사용자가 직접 확인해야 할 사실", "AI가 추천할 수 있는 값", "확인 없이는 멈춰야 하는 조건", "검증 방법"으로 나눠서 하네스를 설계해줘.
📝 한줄 요약
AI 활용 강사로 일하며 쌓이고 있는 강의 자료 및 콘텐츠를 "LLM Wiki"로 엮고, Hermes Desktop + 텔레그램으로 노트북이 꺼져 있어도 이어지는 AI 비서를 하루 만에 구축한 이야기.
바쁘시면 이것만 읽어도 돼요:
AI워케이션의 목적인 강의안 자동화를 위해 주제 한 줄만 던지면 Claude Code가 인터뷰 → HTML 강의안 저작 → 검증 → 미리보기까지 자동화를 만들었어요. 브라우저에서 직접 확인하고 "배포"를 승인한 순간에만 Netlify에 실제 라이브로 올라가도록 했어요. Hermes Desktop을 텔레그램 봇에 연동해, 노트북을 꺼도 맥락을 기억하는 AI 비서를 갖게 됐다.
추가로 하나더 진행했어요. 강의자료가 여기저기 흩어지던 문제를, Obsidian 기반 LLM Wiki로 정리하고 Hermes Desktop을 텔레그램 봇에 연동해 노트북을 꺼도 맥락을 기억하는 AI 비서를 갖게 됐다. 이동 중에도 언제든 AI 비서를 호출할 수 있다.
곡성 AI 워케이션 에서 조별 네트워크 모임에서 이야기를 나누다가 LLM Wiki 구축 이야기를 듣고 AI에게 "LLM Wiki 구축하고 헤르메스 에이전트를 이용해서 자동화하고 싶다"라고 물었더니, 핵심 문제를 진단하고 해결책을 3단계로 제시했다
강의자료 자동 다운로드가 보안 장벽(Cloudflare)에 막히자, 사람이 직접 옮기고 AI가 나머지 정리를 이어받는 방식으로 유연하게 전환했다
결과: 강의자료 2개 과정(4주차씩)이 검색 가능한 위키 29페이지로 정리되어 서로 연결됨
반복 개설되는 강의 패턴을 발견하고, "커리큘럼 vs 운영 회차"를 분리하는 구조까지 AI와 함께 설계했다
배운 교훈: 토큰처럼 민감한 정보는 채팅창이 아니라 안전한 파일로, 자동화가 막히면 사람이 손으로 하는 게 더 빠를 때도 있다
🎯 이런 분들께 도움돼요
AI를 업무에 쓰지만 매번 같은 맥락을 반복 설명하는 게 지친 1인 창업자·직장인
강의안, 자료, 콘텐츠가 여기저기(다운로드 폴더, 노트북, 클라우드)에 흩어져 있는 프리랜서
ChatGPT/Claude는 쓰는데 "기억이 이어지는 나만의 비서"를 만들어보고 싶은 분
😫 문제 상황 (Before)
AI 강사로 일하며 여러 기관에서 AI 활용 강의 등 같은 과정을 진행하고 있다. 문제는 강의 자료가 계속 쌓인다는 것이다 — 센터마다, 기수마다 강의안이 새로 생기고, 노트북 폴더에 자료가 쌓일수록 찾는 데 시간이 들고, AI에게 물어봐도 세션이 끝나면 맥락이 사라져 매번 처음부터 설명해야 했다.
그래서 노트북을 꺼도 기억이 남고, 강의 및 콘텐츠 자료가 쌓일수록 오히려 더 잘 정리되는 시스템을 만들어보기로 했다.
🛠️ 사용한 도구
Hermes Desktop: Nous Research의 오픈소스 AI 에이전트 데스크탑 앱
모델: ChatGPT, Claude Code, GLM-5.2 (z.ai 프로바이더)
지식 베이스: Obsidian 볼트 + LLM Wiki 패턴(Karpathy 방식)
메신저: 텔레그램 봇(BotFather)
🔧 작업 과정
1. 텔레그램 토큰, 채팅창에 그냥 붙여넣으려다 제지당하다
헤르메스 데스크탑과 텔레그램 연동할려고 해
Hermes는 곧바로 hermes-agent 스킬을 불러오더니 게이트웨이 상태부터 점검했다. 아직 꺼져있고, 텔레그램도 미설정 상태. 공식 문서까지 브라우저로 열어 확인하고는 "BotFather에서 토큰 받으셨나요?"라고 되물었다.
토큰을 받고 나서 별 생각 없이 물었다.
텔레그램 토큰 여기에 알려주면 돼?
여기서 예상 못한 답이 왔다. "가능은 하지만 보안상 권장하지 않습니다. 채팅에 남으면 누군가 대화 기록에 접근할 때 봇을 통째로 뺏길 수 있어요." 대신 .env 파일에 직접 넣거나 설정 마법사를 쓰라고 안내했다. 토큰을 안전하게 넣은 뒤 "넣었어"라고만 알려주니, Hermes가 설정을 재확인하고 게이트웨이 시작 방식(자동시작/테스트용/둘 다)을 물어왔다. "둘 다"를 골랐더니 게이트웨이가 곧바로 실행되고, Windows 시작 폴더에 자동실행까지 등록됐다. 텔레그램 앱을 열어 봇에게 말을 걸어보니 바로 응답이 왔다.
2. 위키의 진짜 문제를 AI가 먼저 짚어주다
텔레그램 연동을 끝내고, 다음 방향을 물었다.
그 다음에 뭘 진행하면 좋을까? 추천해줘. LLM Wiki를 발전시키고 싶어.
여기가 가장 인상 깊었던 순간이다. Hermes는 곧바로 위키 폴더 전체를 훑더니 이렇게 진단했다. "노트는 20개 있지만 구조 규칙·인덱스·변경 이력을 관리하는 파일이 없어서, 지금 당장은 괜찮아 보여도 노트가 100개 넘어가면 통제 불가능해집니다." 뼈대는 있는데 정작 "지식이 쌓이는 시스템"이 없다는 걸, 묻지도 않은 문제까지 먼저 찾아낸 것이다.
해결책도 3단계로 명확했다. ① 구조 정비(구조 규칙·인덱스·변경 이력 파일 만들기 + 기존 노트 20개 메타데이터 보강) ② 실제 인제스트 데모 ③ 린트로 깨진 링크·고아 노드 점검. 전체를 한 번에 진행해달라고 하자, Hermes는 노트를 하나하나 읽어가며 태그를 정리하고, 인제스트 데모(아이디어 메모 하나를 위키 개념 페이지로 변환)까지 실행한 뒤, 위키링크 50건을 스캔해 고아 노드 2개를 찾아 바로 연결까지 마쳤다.
3. 강의자료 다운로드가 보안벽에 막히다
다음날, 실제 강의자료로 위키를 채워보기로 했다.
00센터 에서 진행한 <AI실무강의> 5월 11일 개강
1주차~4주차 네이버 단축링크 4개
링크에 있는 강의교안 html를 다운받아서 저장하고 명명규칙에 맞게 정리해서 wiki에 정리해줘.
Hermes가 링크를 따라가 보니 실제로는 외부 아티팩트 페이지였고, 자동 다운로드도 헤드리스 브라우저도 보안 봇 차단에 걸려 빈 껍데기만 받아졌다. 여기서 막혔다. Hermes는 깔끔하게 인정했다 — "자동화로는 이 이상 못 뚫습니다. 브라우저에서 직접 저장해서 이 경로에 넣어주세요." 다운로드 폴더에 파일을 옮겨두고 한마디만 남겼다.
C:\Users\user\Downloads\AI실무강의\ 아래에 다 옮겨 놓았어.
그러자 Hermes가 나머지를 이어받았다. 명명규칙에 맞춰 파일을 볼트로 복사하고, HTML에서 실제 텍스트를 추출하고, 과정 개요·원본 소스·주차별 위키 페이지까지 한 번에 만들어줬다. 자동화가 막히는 지점은 깔끔하게 사람에게 넘기고, 넘겨받은 다음부터는 반복 작업을 전부 대신해준 셈이다.
4. "이거 반복되는 패턴인데?" — 구조를 먼저 고친 순간
같은 방식으로 AI실무강의 과정까지 정리한 뒤, 다음 자료도 이어가려다 잠시 멈췄다. 그 자리에서 문득 든 생각을 그대로 물었다.
그것보다 각 센터별로 동일한 과정명이 월 또는 분기별로 계속 개설되고 진행되는거라 뭔가 분류기준이 있어야 할거 같은데
Hermes는 이 지적을 곧바로 구조 문제로 인식했다. "같은 과정이 반복 개설되면 파일명이 충돌하고, 커리큘럼과 특정 회차 운영 정보가 한 파일에 섞입니다." 그러고는 커리큘럼(과정 정의)과 기수(특정 회차) 운영 기록을 분리하는 구조를 제안했고, "기수를 뭘로 구분할지" 되물었다. 개강일 기준으로 정하자, 기존 파일들을 새 구조로 옮기고 명명규칙 문서까지 새로 써서 확정했다.
✅ 결과 (After)
LLM Wiki 옵시디언 그래프 뷰 캡쳐화면
Before vs After
항목
Before
After
AI 기억
세션마다 리셋, 매번 맥락 재설명
노트북을 꺼도 장기 기억 파일이 기억을 이어감
접근성
노트북 켰을 때만 AI 호출 가능
이동 중에도 텔레그램으로 언제든 호출
강의자료
다운로드 폴더·여러 센터에 흩어짐
위키 29페이지로 정리, 과정↔주차↔프로젝트가 서로 링크
반복 개설 강의
파일명 충돌 위험
커리큘럼/기수 분리 구조로 안전하게 누적
결과물
LLM Wiki 구축 : AI 활용 강사로 일하며 쌓이고 있는 자료 및 콘텐츠를 LLM Wiki로 구조화
텔레그램 연동 : 게이트웨이 실행 + Windows 로그인 시 자동 시작 으로 AI 비서 호출
기수 체계 도입 : 커리큘럼과 기수(회차)를 분리해 반복 개설 강의도 충돌 없이 관리
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
"다음에 뭘 하면 좋을까?"라고 물으면, AI가 먼저 구조적 문제를 진단해준다 — 단순히 시키는 일만 하는 게 아니라, "이대로 가면 나중에 문제가 됩니다"처럼 앞을 내다본 진단을 먼저 받을 수 있었다.
자동화가 막히면 사람이 짧게 개입하고, 나머지는 다시 AI에게 넘긴다 — 보안 차단처럼 AI가 못 뚫는 구간은 깔끔하게 인정받고, 파일 하나 옮겨주는 것만으로 나머지 반복 작업(명명규칙 정리, 위키 컴파일)은 그대로 AI가 이어받았다.
이렇게 하면 안 돼요
비밀번호·토큰은 채팅창에 바로 붙여넣지 않기 — Hermes가 먼저 막아줬지만, 원래는 별도 설정 파일이나 마법사처럼 안전한 경로로 넣는 게 기본이어야 한다.
모든 실행 기록을 장기 기억에 자동 누적하지 않기 — "이것도 기억해두면 편하지 않을까" 싶어도, 실행 로그와 "계속 유효한 사실"은 성격이 다르다. 다 섞으면 정작 중요한 정보가 묻힌다.
🌍 다른 업무에 적용한다면?
지금은 강의 자료 정리에 썼지만, 같은 구조(구조 규칙+인덱스+변경 이력)는 고객 응대 기록, 프로젝트 회의록, 개인 독서 노트처럼 "꾸준히 쌓이는데 매번 흩어지는" 어떤 자료에도 그대로 적용할 수 있다. 핵심은 폴더를 잘 나누는 게 아니라, 새 정보가 들어올 때마다 인덱스와 로그가 함께 갱신되는 습관을 만드는 것이다.
🚀 앞으로의 계획
위키에 쌓인 강의자료를 바탕으로 블로그·콘텐츠 자동 생산까지 확장할 계획이다. 이미 콘텐츠 플라이휠(독서→블로그→출판→브랜딩→강의) 구조를 잡아뒀으니, 다음 단계는 위키 노트 하나를 고르면 AI가 블로그 초안까지 이어서 뽑아주는 흐름을 만드는 것이다.
❤️ 고마운분들에게
곡성 AI 워케이션을 함께 한 1조 정옥선님, 아루나님, 함께 참여하신 1기 분들, 지피터스 운영진 분들, 헤르메스 셋업에 도움주신 박정기님에게 정말 감사드립니다!
📋 재사용 가능한 프롬프트
프롬프트 1: 지식 정리 시스템 진단 요청
지금 내 [노트/자료] 구조를 살펴보고, 앞으로 계속 쌓일 걸 감안했을 때 뭐가 부족한지 진단해줘. 그리고 어디서부터 시작하면 좋을지 단계별로 제안해줘.
[노트/자료]는 본인이 쓰는 앱이나 폴더명으로 바꾸세요 (예: Notion 페이지, 옵시디언 볼트, 구글 드라이브 폴더)
프롬프트 2: 반복되는 자료 구조 개선 요청
[반복되는 대상]이 [주기]마다 계속 새로 생기는데, 지금 구조로는 파일명이 충돌하거나 정보가 섞일 것 같아. 어떻게 분류하면 좋을지 기준을 몇 가지 제안해주고, 내가 고르면 그 구조로 바꿔줘.
[반복되는 대상]/[주기]는 예: "강의 자료" / "분기", "고객 미팅 노트" / "매주" 등으로 바꾸세요
최학곤 · 챗GPT강사/AI강사
📝 한줄 요약
구글 타임라인·카카오톡·문자에 흩어져 있던 11.5년치(4,073일) 내 흔적을, AI 코딩 도구로 파싱·통합하고 하루 단위 실록체 기록 3,296편으로 자동 리라이트했습니다. 손으로는 평생 못 쓸 기록이 원클릭 캘린더 앱 안으로 들어왔고, 서로 다른 포맷에 갇혀 있던 조각들이 한 날짜로 엮이는 순간 잃어버린 지난 11년이 되살아났습니다.
바쁘시면 이것만 읽어도 돼요:
뭘 했나: 스마트폰 구글 지도 내보내기(80MB, 290만 줄, 2014~2026)를 파싱해 날짜별 활동일지를 만들고, 여기에 카톡·문자를 엮어 사실/해석을 분리한 '황제실록'체 서술로 자동 변환.
정량 성과: 하루 단위 기록 0건 → 4,073일 자동 생성 + 3,296편 실록 리라이트, 최종 재확인 미처리 0건.
핵심 난관 1 — 데이터: 공식 Takeout은 단 1일치만 줬다. 스마트폰 앱 직접 내보내기로 우회해 11.5년치를 확보.
핵심 난관 2 — 품질: "이동·지출·만난 사람 나열 + 상투적 논평"에 머물던 초기 결과를, 본기(사실)와 사관 논평(해석)을 분리하는 설계로 갈아엎음.
가장 신경 쓴 것 — AI 검증: 날짜·시각·기간·건수·거리·인용을 근거 데이터와 자동 대조하는 검증 로직을 심고, false positive를 여러 차례 잡아냄. AI가 지어낸 숫자를 그냥 믿지 않았다는 게 이 프로젝트의 핵심.
민감정보: 위치·대화·문자·금융성 알림이 원본이라, 처음부터 마스킹·추상화를 파이프라인 기본값으로 박아넣음.
배운 교훈: 개인 데이터 자동화의 승부처는 "생성"이 아니라 "검증과 마스킹"이었다.
🎯 이런 분들께 도움돼요
이 글은 특히 이 두 분을 위해 썼습니다:
흩어진 개인 기록(위치·메신저·문자)을 한데 모아 잃어버린 지난 시간을 되살리고 싶은 분 — 일기를 못 쓰는 사람일수록 효과가 큽니다. 스마트폰은 이미 당신을 몇 년째 기록하고 있으니까요.
AI에게 문서 정리를 맡기고 싶지만 "AI가 지어낸 내용"이 무서워 못 맡기던 분 — 이 글의 절반은 "AI가 뱉은 걸 어떻게 안 믿고 검증했나"에 대한 이야기입니다.
그리고 아래 실무자분들께도 그대로 이식됩니다(→ 🌍 섹션 참고): 개인정보·기밀이 섞인 데이터를 다루거나, "사실"과 "해석"을 분리해 기록해야 하는 분(법률·공공·상담·HR, 경위서·회의록·상담일지 등).
😫 문제 상황 (Before)
저는 일기를 거의 못 씁니다. 그런데 스마트폰은 저 대신 11년 넘게 성실히 기록하고 있었습니다. 문제는 그 기록이 사람이 읽을 수 없는 형태였다는 것.
구글 타임라인 위치 기록은 위경도 숫자 덩어리였고,
카카오톡·문자는 각각 다른 파일 포맷에 갇혀 있었고,
이 모든 게 날짜라는 공통 축으로 엮여 있지 않았습니다.
"11.5년을 하루 단위로 정리한다"는 건 손으로는 사실상 불가능한 작업이었습니다. 4,073일을 하루 10분씩만 정리해도 680시간, 꼬박 넉 달 걸립니다. 그래서 지금까지 아무도(=저도) 손대지 못했고, 그 결과 제 과거는 검색도 회상도 안 되는 죽은 데이터로 남아 있었습니다.
결정적 계기는 어느 날 특정 과거를 되짚어 볼 일이 생겼을 때였습니다. "그게 언제였지, 그날 뭘 했더라"를 확인하려는데, 기록이 없어 아무것도 재구성할 수 없었습니다. 분명 스마트폰 어딘가엔 흔적이 있는데 꺼내 읽을 수가 없다는 그 막막함이, 미루던 일을 시작하게 만든 방아쇠였습니다.
게다가 시간이 제 편이 아니었습니다. 구글이 타임라인 정책을 바꾸면서 서버에 있던 기록은 이미 1일치로 쪼그라들었고(뒤에서 설명), 폰에 남은 11.5년치도 기기를 바꾸거나 잃어버리면 그대로 증발합니다. "지금 안 꺼내면 영영 못 꺼낸다" — 이게 이 일을 더는 미룰 수 없었던 진짜 이유였습니다.
왜 기존 방법으로는 안 됐나 (기존 대안 검토)
구글 공식 Takeout(테이크아웃)을 먼저 받아봤습니다. 그런데 구글이 타임라인을 서버 저장에서 기기 로컬 저장으로 정책을 바꾸면서, 서버 기반 Takeout에는 딱 1일치(2025-07-11~12) 데이터만 들어 있었습니다. 11.5년을 원한 사람에게 하루치는 무의미했죠.
엑셀·수작업 정리는 위에서 계산한 대로 규모 자체가 감당 불가였습니다.
예전에 비슷한 자동 요약을 시도했을 때는 결과물이 "어디 갔고, 얼마 썼고, 누굴 만났다"를 건조하게 나열하고 끝에 상투적 코멘트를 붙이는 수준이라, 다시 읽고 싶은 기록이 아니었습니다.
그리고 이 문제는 자동화·AI에 딱 맞는 성격이었습니다 — 4,073일이 똑같은 패턴의 반복이고, 위경도·시각·상호명 같은 규칙적 데이터이며, 결국 텍스트로 서술하는 일이니까요. 양이 많아 사람이 못 하고, 규칙은 코드가, 서술은 LLM이 잘하는 전형적인 영역이라 "굳이 AI?"가 아니라 "AI가 아니면 불가능"에 가까웠습니다.
즉 문제는 두 겹이었습니다 — ① 데이터를 못 모은다, ② 모아도 읽을 만하게 안 나온다. 이 프로젝트는 이 두 벽을 차례로 넘은 기록입니다.
🛠️ 사용한 도구
도구: Claude Code(파싱·일지 생성 파이프라인 설계), Codex CLI(황제실록 리라이트 백엔드 실행)
왜 나눴나: 한 도구로 다 하지 않았습니다. 정확한 파싱·파이프라인 설계는 Claude Code가, 수천 편의 문체 생성(대량 배치)은 Codex가 각각 더 잘하는 영역이라 판단해 강점을 분담했습니다.
핵심 모델: 리라이트 백엔드는 상위 추론 모델을 reasoning effort를 최고로, 응답은 빠른 티어로 설정해 대량 배치에 맞춤
데이터 소스: 구글 타임라인(스마트폰 내보내기 80.7MB), 카카오톡 대화 JSON, 문자(SMS/MMS) XML
특이사항: 원본이 전부 민감정보라, 마스킹·추상화를 옵션이 아니라 기본값으로 두고 작업
🔧 작업 과정
1막. "하루치가 전부라고?" — 데이터 소스를 갈아탄 순간
처음엔 정석대로 갔습니다. 구글 테이크아웃에서 위치 기록을 받아, 원시 신호(위치 좌표·활동·와이파이 스캔)를 파싱하는 파서를 만들고 SQLite 데이터베이스에 넣었습니다. 파서는 잘 돌았습니다 — 위치 373건, 활동 3,001건이 깔끔하게 적재됐죠.
문제는 결과를 보고 나서였습니다.
날짜 범위를 확인해줘. 데이터가 며칠치나 들어온 거야?
돌아온 답은 "2025-07-11 ~ 07-12, 약 1일치". 구글 정책 변경 때문에 서버 Takeout이 껍데기만 준 것이었습니다. 여기서 포기했다면 이 프로젝트는 없었습니다.
대신 스마트폰 구글 지도 앱에서 직접 내보내기를 시도했더니, 완전히 다른 파일이 나왔습니다.
스마트폰에서 직접 내보낸 타임라인 파일을 확인해줘. 크기랑 기간, 며칠치인지 알려줘.
파일 크기: 80.7MB, 무려 292만 줄
기간: 2014-11-29 ~ 2026-06-28, 약 11.5년
고유 날짜: 4,073일, 총 세그먼트 73,820개(장소 방문 23,518 / 이동 경로 22,468 / 활동 27,679)
요청 → 작업 → 결과 → 배운 점
같은 "구글 타임라인"인데 Takeout판과 스마트폰판은 최상위 키도, 좌표 표기법도 완전히 달랐습니다. Takeout은 정수형 좌표(원시 신호), 스마트폰판은 문자열 좌표(의미 세그먼트: 방문·경로·활동). 그래서 기존 파서를 버리지 않고, 스마트폰 포맷 전용 파서를 새로 만들어 방문·경로·활동을 각각의 테이블로 나눠 담았습니다.
→ 배운 점: 같은 서비스라도 "어느 문으로 데이터를 꺼내느냐"에 따라 양과 형식이 하늘과 땅 차이다. 공식 경로가 막히면 대체 출구를 먼저 의심하라.
2막. 위치·카톡·문자를 '같은 날짜 서랍'에 모으다 — 세 기록의 삼각측량
타임라인만으로는 반쪽짜리였습니다. 구글 타임라인은 "어디에 있었고 얼마나 움직였나"(장소·거리)는 복원했지만, 정작 "거기서 무엇을 했나"는 비어 있었죠. 좌표는 남았는데 이야기가 없었습니다.
그래서 나머지 두 조각을 마저 데려왔습니다.
카톡 대화 내보낸 거랑 문자 내보낸 것도 날짜별로 잘라서 타임라인이랑 같은 날짜에 합쳐줘.
카카오톡 대화기록: 앱에서 대화를 내보내 파일로 저장한 뒤, 날짜별로 잘라(청킹) 정리했습니다.
문자(SMS/MMS): 휴대폰에서 내보내, 역시 날짜별로 분류·청킹했습니다.
핵심은 세 소스를 전부 "같은 날짜 서랍"에 나눠 담았다는 것입니다. 위치도, 대화도, 문자도 하루 단위로 정렬되니, 특정 날짜를 열면 그날의 세 기록이 한자리에 모였습니다.
그러자 서로의 결점이 메워졌습니다.
타임라인은 동선(어디→어디, 몇 km)을 알려주고,
카톡·문자는 그 자리에서 무슨 일이 있었는지(약속·대화·맥락)를 채워주고,
특히 카드결제 알림 문자에는 방문한 상호(가게 이름)가 찍혀 있었습니다.
여기서 결정적인 장면이 나왔습니다. 카드내역의 상호명과 타임라인의 그 시각 동선을 대조하니 "이 시각, 이 좌표에 있었다 = 이 가게였다"가 딱 맞아떨어졌습니다. 서로 다른 출처가 같은 사실을 가리키자, 기록의 신뢰도가 급격히 올라갔습니다. — 이건 곧 소스끼리 서로를 자동 교차검증해준 셈입니다.
요청 → 작업 → 결과 → 배운 점
세 소스를 날짜 축으로 합치자, 좌표 덩어리였던 과거가 "언제·어디서·누구와·무엇을"이 채워진 하루로 복원됐습니다. 옛날에 갔던 장소, 자주 가던 식당, 심지어 해외여행까지 — 잊고 있던 일상이 통째로 실록의 재료가 됐습니다.
→ 배운 점: 한 소스의 빈칸은 다른 소스가 메운다. 위치의 "어디"와 대화·결제의 "무엇"이 만나는 순간 로그는 기억이 되고, 서로 다른 출처가 겹치는 지점(카드 상호 ↔ 타임라인 동선)은 공짜 교차검증이 된다.
3막. AI가 만든 첫 실록을 보고, 설계를 갈아엎다
데이터가 모이자 진짜 목표로 갔습니다 — 이 숫자 덩어리를 읽을 만한 하루 기록으로 바꾸는 것. 컨셉은 '황제실록'이었습니다. 내 하루를 임금의 하루처럼 사서(史書) 문체로 서술하는 것.
그런데 초기 결과물이 딱 "그저 그런 자동 요약"이었습니다. 어디 갔고, 얼마 쓰고, 누굴 만났는지 단순 열거한 뒤 끝에 상투적 논평을 붙이는 식. 여기서 방향을 크게 틀었습니다.
실록을 사실과 해석으로 분리해줘. '본기'에는 근거가 있는 사실만 쓰고, 상상·풍자·통찰·비유는 맨 끝 '사관은 논한다' 논평 문단에만 넣어.
이 한 줄이 결과물의 격을 바꿨습니다.
본기(本紀): 그날의 장소·이동·지출·대화·알림을 근거 기반 사실만으로 서술.
사관은 논한다: 해석·비유·통찰은 오직 여기에만. (기존의 사신은 논한다 표현도 사관은 논한다로 통일)
페르소나: 생존 인물의 실제 문체를 모방하지 않고, 기능적 페르소나만 적용 — 냉정한 앵커형, 문명비평가형, 사마천형, 소설가형.
기록 주체: 나를 항상 상(上)으로만 지칭. 실명, "사용자", 대명사 "그"는 검증으로 차단.
실제로 이렇게 나옵니다 (2024년 어느 하루, 마스킹본):
총 이동 77.6km · 14곳 방문(17시간)
상은 오전 10시 10분 자전거로 나아가 개포로에 이르고, 지하철을 이어 타 종로를 거쳐 11시 36분 서울역사박물관에 들어갔다. 앞서 인물3이 그곳에 있겠다고 알렸고, 상은 짧게 응답하였다.
상은 낮에 스타벅스에 머문 뒤 대성집(미쉐린가이드 도가니탕)에 들렀고, 사직로 골목을 지난 다음 2시간 39분 동안 9.3km를 걸었다. 저녁에는 커피스트와 Wooh Ahh Craft Beer Bar에 들렀으며, 밤에는 지하철과 자전거를 이어 타고 트레이더스 위례점에 갔다가 22시 18분 집에 들었다. 이날 총 이동 거리는 77.6km였다.
금전 기록에는 00시 44분 2,500원 결제 알림이 있고, 인물3과의 사이에 송금·수취 알림이 여러 차례 이어졌다.
통신에는 국군의 날 교통통제 예고, 방문 일정 변경 알림, 등록 사건 알림, 공연 예매 완료 알림이 섞여 있었다. 인물2가 건강·의료에 관한 개인적 사정을 청하였고, 상은 세부를 옮기지 않은 채 문서와 절차의 관점에서 답하였다.
사관은 논한다. 이동은 길고, 알림은 촘촘하며, 돈의 오감도 여러 번 맞추었다. 누가 무엇을 맡고 어디서 확인할 것인가. 절차가 일의 뼈대다.
한 편 안에 설계가 전부 담깁니다 — 본기(사실)는 시각·장소·거리·금액 같은 근거만 서술하고, 해석은 오직 마지막 "사관은 논한다" 한 문단에만. 실명은 인물2·인물3으로, 나는 상으로, 민감한 건강 얘기는 "세부를 옮기지 않은 채"로 추상화됩니다. 그리고 이 하루 안에 타임라인 동선 + 카드결제 알림 + 카톡 송금이 자연스럽게 한 흐름으로 엮여 있죠.
요청 → 작업 → 결과 → 배운 점
"사실과 해석을 섞지 말라"는 원칙 하나로, AI의 창의성은 논평 문단이라는 우리(cage) 안에서만 풀어놓게 됐습니다. 덕분에 본문은 신뢰할 수 있고, 읽는 재미는 마지막 문단이 책임지는 구조가 됐습니다.
→ 배운 점: AI에게 "잘 써줘"가 아니라 "사실은 여기, 상상은 저기"라고 자리를 지정해주면, 환각이 갈 곳을 미리 가둘 수 있다.
4막. 진짜 승부처는 '생성'이 아니라 '검증'이었다 ⭐
이 프로젝트에서 시간을 가장 많이 쏟은 곳은 글을 뽑는 부분이 아니라, AI가 뽑은 글이 사실인지 확인하는 부분이었습니다. 개인 기록은 숫자 하나만 틀려도 "가짜 기억"이 되니까요.
AI가 만든 실록이 근거 데이터랑 실제로 맞는지 자동으로 검증하게 해줘. 틀리면 걸러내.
그래서 리라이트 결과를 원본 근거와 대조하는 검증 장치를 여러 겹 심었습니다.
시각 표현: '오전/오후', '12:09', '0시 9분' 같은 서로 다른 표기를 근거 시각과 대조.
기간 표현: 시각의 '분' 성분과 실제 체류 시간(duration)을 혼동하지 않도록 구분.
건수 표현: 본문에 나온 개수를 근거 데이터의 카운트 값과 대조.
거리 표현: '총 이동거리'와 '구간별 이동거리'를 구분해 검증.
인용 검증: 대화 원문을 길게 직접 인용하지 못하도록 제한.
여기서 흥미로운 반전이 있었습니다. 검증기가 너무 깐깐해서 멀쩡한 문장을 오탐(false positive) 하는 일이 반복됐고, 그걸 여러 차례 잡아 완화했습니다. 마지막 버그는 특히 기억에 남습니다 — Urban's Court라는 표현의 아포스트로피(')를 긴 인용부호로 오인해 정상 문장을 계속 막던 문제였죠. 이걸 고치고 나서야 마지막 한 편이 통과됐습니다.
요청 → 작업 → 결과 → 배운 점
검증을 켜자 처음엔 통과율이 나빴지만, 오탐을 하나씩 교정하면서 "믿을 수 있는 자동 기록"에 가까워졌습니다. 그리고 문법 검사와 자체 테스트를 통과시킨 뒤, 논평 표지(사신은 논한다 등)가 남아 있는지 전수 검색해 0건을 확인했습니다.
→ 배운 점: AI 자동화의 신뢰도는 생성 프롬프트가 아니라 검증 규칙의 촘촘함에서 나온다. 그리고 검증기도 코드라서, 검증기 자신의 버그까지 잡아야 완성된다.
5막. "매번 서버 켜기 귀찮아" — 원클릭 캘린더 앱으로
기록이 쌓여도 매번 개발 서버를 띄우고 브라우저 주소를 입력해야 본다면, 결국 안 보게 됩니다. 그래서 열람 경험까지 손봤습니다.
매번 서버 띄우고 [localhost](http://localhost) 접속하는 게 번거로워. 클릭 한 번으로 켜지는 앱처럼 만들어줘. 다크/라이트 모드도.
월간·주간 캘린더 뷰를 만들고, 클릭 한 번으로 실행되는 앱 래퍼로 감쌌습니다. 처음 만든 라이트/다크 모드가 육안으로 차이가 거의 없길래, 라이트 모드의 배경·카드·헤더·요일 영역 색상 대비를 다시 분명하게 조정했습니다.
→ 배운 점: 자동화의 마지막 1cm는 "얼마나 쉽게 다시 열어보게 만드느냐"다. 여기서 막히면 그동안의 작업이 전부 서랍 속으로 들어간다.
6막. 3,296편을 한 번에 — 그리고 멈춰도 이어달리게
마지막은 전체 적용이었습니다. 카톡 개인/소수 지인방은 근거로 통합하되 오픈채팅·서비스성 알림은 우선순위를 낮추거나 제외하고, 민감 주제는 원문을 복원하지 않고 추상 요약 수준으로만 쓰도록 못 박은 뒤 전량 리라이트를 돌렸습니다.
전체 대상 3,296편
1차 완료 3,293편, 실패 3편
재시도로 2편 해결, 마지막 1편은 위의 아포스트로피 버그를 고친 뒤 정상 저장
최종 재확인: 미처리 0건
대량 실행이라 중간에 멈출 위험이 있어서, 2건씩 배치 처리 + 타임아웃 시 단건으로 후퇴 + 실패분 재시도 + 이미 성공한 건 건너뛰고 재개하는 안전장치를 넣었습니다. 실제로 한도(rate limit)에 걸리면 5분 뒤 재개, 그래도 안 되면 다시 5분 뒤 재개하는 운영 규칙까지 정해뒀습니다. 다행히 최종 실행은 한도 없이 완주했고, 타임아웃은 단건 후퇴로 회복됐습니다.
→ 배운 점: 수천 건 배치의 핵심은 속도가 아니라 "중단돼도 처음부터 다시 안 하게" 만드는 재개 설계다.
그리고 — 잃어버린 11년이 되살아난 순간
기술적으로 가장 뿌듯했던 건 검증기를 다듬은 순간이었지만, 개인적으로 가장 뭉클했던 건 따로 있었습니다.
앞서 2막에서 세 기록을 같은 날짜 서랍에 모았을 때, 결과물로 그 진가가 드러났습니다. "2019년 그날, 나는 여기 있었고(타임라인) / 이 사람과 이런 얘길 나눴고(카톡) / 이 가게에서 카드를 긁었다(문자)"가 한 페이지에 나란히 서자, 기억에서 지워졌던 특정 하루가 통째로 되살아났습니다. 옛날에 갔던 장소, 자주 가던 식당, 해외여행까지 — 단순한 데이터 통합이 아니라 잃어버린 줄도 몰랐던 지난 11년을 실록으로 되찾은 경험이었습니다.
→ 배운 점: 개인 데이터의 가치는 각 소스에 있는 게 아니라 "엮이는 축(날짜)"에 있다. 흩어져 있으면 로그, 엮이면 기억이다.
✅ 결과 (After)
Before vs After
항목
Before
After
하루 단위 기록
0건 (11.5년간, 사실상 불가능)
4,073일 자동 활동일지 + 3,296편 실록체 서술
데이터 확보
공식 Takeout 1일치만 제공
스마트폰 내보내기로 11.5년(80.7MB) 확보
데이터 통합
위치·카톡·문자가 각각 다른 앱·포맷에 흩어짐
3개 소스를 날짜별 청킹 후 통합(삼각측량)
기록의 깊이
타임라인만 있어 "어디"는 알아도 "무엇을"은 공백
카톡·문자·카드내역으로 "무엇을"까지 복원
서술 품질
이동·지출·사람 단순 나열 + 상투적 논평
본기(사실)/사관 논평(해석) 분리된 읽을 만한 기록
열람 방식
없음 / 80MB JSON 직접 뒤지기
원클릭 캘린더 앱(월간·주간, 다크/라이트)
미처리
—
0건 (3,293 1차 + 3건 재시도로 전부 해결)
결과물 (동작 증거)
말이 아니라 실행 로그로 남은 증거들입니다.
파싱 로그: Positions 373 / Activities 3001 / Place Visits 9 정상 적재 확인
스마트폰 데이터: 4,073 고유 날짜 / 73,820 세그먼트 집계 확인
리라이트 로그: 3293 rewritten, 3 invalid → 재시도 후 최종 summary targets=0(미처리 0)
검증: 문법 검사 통과, 자체 테스트 통과, 논평 표지 전수 검색 0건
교차검증: 카드결제 문자의 상호명 ↔ 타임라인 동선이 같은 시각·좌표에서 일치 — 서로 다른 출처가 같은 사실을 가리킴
지금도 쓰고 있습니다. 완성 후 서랍에 넣어둔 게 아니라, 주기적으로 캘린더 앱을 열어 옛날 특정 날짜를 되짚어 봅니다. 원클릭 앱으로 만든 게 결정적이었습니다 — 매번 서버를 켜야 했다면 진작 안 봤을 겁니다.
주변 반응도 있었습니다. 여자친구는 결과물을 보더니 "이거 나한테도 알려줘"라고 했고, 어느 모임에서 만난 분은 이 작업물을 보고 깜짝 놀라며 방법을 꼭 알려달라고 카카오톡으로 따로 부탁해 왔습니다. 제 데이터라 남이 직접 써본 건 아니지만, "나도 만들고 싶다"는 반응은 이 방식이 개인적 취미를 넘어 남에게도 통한다는 신호였습니다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
한 소스의 빈칸은 다른 소스로 메워라(삼각측량). 타임라인의 "어디"에 카톡·문자의 "무엇"을 날짜 축으로 합치니 반쪽짜리 기록이 온전해졌습니다. 게다가 카드내역 상호명과 동선이 겹치면 공짜 교차검증까지 됩니다.
"사실은 여기, 상상은 저기"로 자리를 지정하라. 본기와 논평을 물리적으로 분리하니 환각이 갈 곳이 논평 문단으로 제한됐습니다. AI의 창의성을 죽이지 않으면서 본문 신뢰도를 지키는 방법.
검증을 프롬프트가 아니라 규칙으로 심어라. 날짜·시각·기간·건수·거리·인용을 근거와 자동 대조하게 하니, "그럴듯한 거짓말"이 걸러졌습니다.
대량 작업엔 재개 설계를 먼저. 실패분만 건너뛰고 이어달리는 구조 덕에 수천 건을 안전하게 완주했습니다.
공식 경로가 막히면 대체 출구를 의심하라. Takeout 1일치 → 스마트폰 내보내기 11.5년치. 데이터의 문은 하나가 아니었습니다.
이렇게 하면 안 돼요 (실제로 겪은 함정)
AI가 뱉은 숫자를 그냥 믿기. 시각·건수·거리는 서로 다른 값을 헷갈리기 쉽습니다(분 성분 vs 체류시간, 총거리 vs 구간거리). 반드시 근거와 대조하세요.
검증기를 만들고 방심하기. 검증기도 코드라 오탐을 냅니다. Urban's Court의 아포스트로피를 인용부호로 오인해 멀쩡한 문장을 계속 막았습니다. 검증기 자신의 버그까지 잡아야 끝납니다.
마스킹을 나중에 하기. 위치·대화·문자는 태생이 민감정보라, 마스킹·추상화를 처음부터 기본값으로 두지 않으면 나중에 통째로 다시 돌려야 합니다.
열람 편의를 무시하기. 매번 서버 켜야 보는 결과물은 결국 안 보게 됩니다. "다시 여는 마찰"을 0에 가깝게 만드세요.
🌍 다른 업무에 적용한다면?
이 프로젝트의 진짜 자산은 '실록'이 아니라 "흩어진 데이터를 → 날짜 축으로 통합 + 사실·해석 분리 서술 + 자동 검증 + 마스킹으로 정리하는 파이프라인" 자체입니다. 저는 두 방향 모두로 실제 확장을 고려하고 있습니다.
① 개인 영역으로 더 넓히기 (실제 다음 계획)
사진·가계부·건강기록까지 같은 날짜 축에 합류: 위치·카톡·문자에 사진(어디서 뭘 봤나), 가계부(그날 뭘 샀나), 건강 앱(수면·걸음)을 얹으면, 하루의 복원도가 로그에서 장면으로 올라갑니다. 검증·마스킹 부품은 그대로 두고 "근거 소스"만 추가하면 됩니다.
② 업무 문서로 옮기기 (직무 이식)
법률·공공기관 문서 정리: 사건 경위서·회의록·상담일지를 ① 사실 요약(근거 인용 대조) 과 ② 의견·해석으로 분리 서술하고, 실명·연락처·기관명을 자동 마스킹하며, 날짜·금액·인용의 정확도를 근거 문서와 대조 검증. "AI가 지어낸 사실"이 치명적인 분야일수록 이 구조가 강력합니다.
고객 상담/CS 로그 아카이브: 메신저·통화·티켓을 날짜·고객 축으로 통합하고, 개인정보는 추상 요약으로만 남긴 뒤 "무슨 일이 있었나(사실) / 무엇을 개선할까(해석)"를 분리 기록.
왜 이식이 되나: 이 사례에서 실제로 작동한 네 부품 — 날짜 축 통합, 사실/해석 분리, 근거 대조 검증, 마스킹 기본화 — 은 데이터 종류(위치든 대화든 사진이든 법률 문서든)와 무관하게 재사용됩니다. 바꿔야 할 건 "근거 데이터의 필드 이름"뿐입니다. 실제로 위치→카톡→문자로 소스를 늘릴 때 이 부품들을 그대로 재사용했습니다.
솔직한 재현 난이도 & 전제조건
과장 없이 말씀드리면, 이건 "복붙 한 번으로 끝"은 아닙니다. 층을 나눠 보면:
🟢 대화형 AI(ChatGPT·Claude)만으로 오늘 당장 되는 것: 위 재사용 프롬프트 2개(사실/해석 분리 서술 + AI 자가검증). 내 데이터 한 조각을 붙여넣기만 하면 됩니다. 비개발자도 즉시 가능.
🟡 AI 코딩 도구가 필요한 것: 11.5년치 대량 파싱·날짜별 청킹·자동 검증 파이프라인은 Claude Code·Codex 같은 도구(+약간의 스크립트)가 필요합니다. 순수 비개발자라면 이 부분을 AI 코딩 도구에 통째로 맡기거나, 규모를 "최근 몇 달"로 줄여 시작하길 권합니다.
필요 준비물: 스마트폰 타임라인 내보내기, 카톡·문자 내보내기, AI 코딩 도구 접근(유료 구독 포함 가능).
안 맞는 경우(비적용): 실시간 대응이 필요한 업무, 근거 데이터가 아예 없는 순수 창작, 소스가 한 종류뿐이라 교차검증이 불가능한 경우엔 이 방식의 강점(삼각측량·검증)이 약해집니다.
조직으로 키우려면: 개인은 이대로 충분하지만, 팀·조직 규모로 올리면 데이터 접근 권한·보안 규정·마스킹 수준 합의가 기술보다 먼저 필요합니다.
🚀 앞으로의 계획
사진 EXIF 결합(여행일지): 위치 기록에 사진 촬영 시각·좌표를 얹어, 인터랙티브 지도가 있는 여행일지로 확장.
검색·질의 연동: 4,073일 기록을 자연어로 "2019년 여름에 자주 가던 곳은?"처럼 물어볼 수 있게 Wiki/검색과 연결.
마스킹 정책 고도화: 외부 공유를 전제로, 민감 주제 추상화 수준을 사용자가 선택할 수 있게.
방법 전파: 지금 이 글이 첫 공유입니다. 나아가 "나도 알려달라"던 여자친구·모임 지인에게 따라 할 수 있는 방법(이 글의 재사용 프롬프트 + 데이터 내보내기 순서)을 정리해 전수할 계획입니다.
📋 재사용 가능한 프롬프트
아래 프롬프트는 대화형 AI(Claude, ChatGPT 등)에 복붙해서 바로 쓸 수 있습니다. [대괄호] 부분만 본인 상황에 맞게 바꾸세요.
프롬프트 1: 개인/업무 데이터를 '사실 ↔ 해석' 분리해 서술시키기
아래 [데이터 종류: 예) 하루치 위치·대화 기록 / 회의록 / 상담 로그]를 읽고 하나의 기록으로 정리해줘.
규칙:
[사실 섹션 이름: 예) 본기] 에는 근거가 있는 사실만 써라. 원본에 없는 내용은 추측해서 쓰지 마라.
상상·해석·비유·평가는 오직 맨 끝 [논평 섹션 이름: 예) 총평] 문단에만 써라.
인물은 [지칭 방식: 예) 실명 대신 이니셜]로만 부르고, [마스킹 대상: 예) 전화번호·기관명·금액]은 가리거나 추상화해라.
대화 원문을 길게 직접 인용하지 말고, 요지만 요약해라.
문체는 [원하는 톤: 예) 담담한 앵커 / 냉정한 비평가] 하나로 일관되게.
프롬프트 2: AI가 만든 요약의 '사실 정확도'를 스스로 검증시키기
방금 네가 작성한 [결과물: 예) 하루 기록]을 아래 [근거 데이터]와 대조해서 사실 오류가 있는지 자가 점검해줘.
다음 항목을 각각 O/X로 판정하고, X면 근거의 실제 값을 함께 제시해라:
시각: 본문에 쓴 시간이 근거의 시각과 일치하는가 (오전/오후, 표기법 혼동 주의)
기간: '몇 시 몇 분'과 '얼마나 머물렀는지(체류 시간)'를 혼동하지 않았는가
건수: 본문의 개수가 근거 데이터의 실제 카운트와 같은가
금액/수치: [핵심 수치: 예) 지출액·거리]가 근거와 일치하는가 (합계 vs 구간 구분)
인용: 원문에 없는 말을 지어내 인용하지 않았는가
판정이 모두 O가 될 때까지 본문을 고쳐 다시 제시해라. 근거가 없으면 지어내지 말고 "확인 불가"로 표기해라.
추천 이미지:
"결과 (After)" 섹션: 완성된 원클릭 캘린더 앱의 월간 뷰(다크/라이트 모드 나란히) 스크린샷 — 4,073일이 캘린더에 채워진 전경.
"2막 — 삼각측량" 섹션: 같은 날짜에 타임라인 동선 + 카톡 + 카드결제 문자가 나란히 놓인 화면, 또는 카드 상호명↔타임라인 좌표가 일치하는 대조 장면. ※ 마스킹 필수.
"4막 — 검증" 섹션: 리라이트 로그 3293 rewritten, 3 invalid 또는 최종 summary targets=0 터미널 화면.
"3막" 섹션: 실제 생성된 '황제실록' 하루 기록 예시(본기 + 사관은 논한다 문단이 분리된 화면). ※ 게시 전 반드시 실명·지명·대화 내용 마스킹.
## 시도하고자 했던 것과 그 이유를 알려주세요.
### 택배박스에서 시작한
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) — 꾸준한 반복과 기록의 힘을 배웠습니다.
- 준님의 실전 사례 / 정기님의 실전 사례
이 사례글도 그 가르침의 실천입니다.
비개발자가 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로 30일 챌린지 커리큘럼을 만들며
📝 한줄 요약
포트폴리오·블로그, 따로 업데이트하기 귀찮아서 늘 밀리잖아요. 저는 아예 "작업하면 사이트가 저절로 채워지는" 구조를 만들어 뒀습니다. 이번에 AI로 30일짜리 강의 챌린지 커리큘럼을 만들었더니, 손 하나 더 안 대고 포트폴리오 사이트에 강의 자료로 올라갔어요.
바쁘시면 이것만 읽어도 돼요:
진실(원본)은 한 곳에만 두고, 사이트는 그걸 거울처럼 비추게 설계했다.
그래서 "커리큘럼을 만든 작업" 자체가 "포트폴리오를 업데이트한 것"이 된다. 정리 노동이 사라진다.
발행 여부는 파일에 스위치 하나(공개 켜기/끄기)로 정한다. 코드는 안 건드린다.
이번 30일 커리큘럼은 그 구조가 실제로 도는 걸 보여준 사례. Day 파일을 만들고 스위치를 켜자 사이트 강의 탭에 저절로 등장했다.
온보딩 강의는 매 기수 반복되니까, 한 번 쌓은 커리큘럼이 계속 누적된다. 일할수록 포트폴리오가 저절로 두꺼워지는 구조.
🎯 이런 분들께 도움돼요
포트폴리오·블로그 업데이트가 늘 밀려서 방치 중인 분
강의·스터디 커리큘럼을 만드는 강사·스터디장
여기저기 흩어진 작업물을 한 사이트로 모으고 싶은 분
😫 문제 상황 (Before)
저는 강의를 하고, 스터디를 운영하고, 이런저런 프로젝트를 벌입니다. 그런데 그렇게 만든 결과물이 자꾸 여기저기 흩어져요. 폴더 어딘가, 노트 어딘가에 쌓이기만 하고.
그리고 그걸 "포트폴리오"로 보여주려면 또 따로 정리를 해야 합니다. 사이트에 옮겨 붙이고, 소개 글 쓰고, 목록 업데이트하고. 이게 너무 귀찮아서 대부분 안 하게 돼요. 그래서 정작 열심히 일해도 밖에서 보면 아무것도 없는 상태가 됩니다.
이번에도 딱 그 상황이 겹쳐서 터졌습니다.
외부 계기: 제가 운영하는 온보딩 스터디의 방향이 바뀌면서, 기존에 쓰던 "바이브 코딩(AI로 코딩하기) 입문" 강의를 따로 챌린지로 분리해야 했어요.
진짜 문제: 그런데 기존 강의를 오랜만에 열어 보니, 쉽게 쓴다고 썼는데도 초보자가 보기엔 정신이 없더라고요. git이니 오픈소스니 하는 도구를 욕심내서 첫 주에 몰아넣은 탓에, "빠르게 뭔가 만드는 재미"라는 목적과 오히려 정반대로 가 있었습니다.
기회: 이왕 손대는 김에 ① 챌린지 ② 강의 포트폴리오 ③ 다른 곳에서도 쓸 4주 커리큘럼, 이 세 개를 한 번에 정리하고 싶었어요.
정리하자면 "그냥 자료 옮기기"가 아니라 아예 다시 설계해야 하는 일이었습니다. 그리고 다 만든 다음, 그걸 또 포트폴리오 사이트에 올리는 노동이 기다리고 있었죠. 그 노동을 없애는 게 이 이야기의 핵심입니다.
🛠️ 사용한 도구
도구: Claude Code (터미널에서 AI와 대화하며 파일을 만들고 고치는 도구). 강의를 실제로 따라 할 사람들을 위해서는, 코딩이 필요 없는 Claude Cowork를 기준으로 잡았습니다.
모델: Claude Opus
특이사항: 이미 "작업 폴더를 거울처럼 비추는 사이트"를 만들어 둔 상태였고, 이번 작업은 그 구조 위에서 진행했습니다.
🔧 작업 과정
흩어진 강의의 "진짜 원본"부터 찾기 — AI가 기록을 뒤져 줬다
시작부터 막혔습니다. 예전에 강의할 때 쓴 사이트를 다시 열었는데, 내용이 뭔가 달랐어요. 나중에 제가 메뉴를 추가하면서 어느샌가 바뀐 것 같은데, 정작 "그때 실제로 강의에 쓴 버전"이 어디 있는지 못 찾겠더라고요.
얼마전에 사이트를 확인했는데 실제 내가 강의할때 사용했던 사이트랑 좀 내용이 다른거 같더라고;;
대체 강의때 사용했던 버전이 어디있는지 못찾겠더라고 그걸 기준으로 정리해야하는데 말이야
여기서 처음 "오!" 했습니다. AI한테 강의 영상 내용을 기준으로 알려주고 "혹시 이전 버전이나 기록을 뒤져 볼래?"라고 했더니, 저장된 히스토리를 뒤져서 "이게 실제 강의 때 쓴 원본이고, 이건 나중에 메뉴를 추가하며 바뀐 버전"이라고 짚어 줬어요.
비개발자 입장에선 이게 꽤 신기했습니다. 저 혼자였으면 "어디 갔지…" 하고 한참 헤맸을 텐데, AI가 과거 기록을 대신 뒤져서 원본을 찾아 준 거죠. 여기서부터 정리를 시작할 수 있었습니다.
"도구 먼저"를 "만드는 재미 먼저"로 뒤집다
원본을 찾아 놓고 보니, 구조 자체가 문제였습니다. AI와 대화하며 커리큘럼을 하나씩 짚다가 이런 자각이 왔어요.
기존에 작성한건 오픈소스와 깃을 사용하게 하고 싶은 욕심에 이 내용을 첫주에 넣어서
어쩌면 첫주에 가장 빠르게 바이브 코딩을 할수 있게 만드는 목적과도 맞지 않은거 같아.
초보자용 강의의 황금률은 "빠른 첫 성취"인데, 제 커리큘럼은 그 성취가 한참 뒤에나 나오게 짜여 있었던 거예요. AI와 주거니 받거니 하다 보니 제 생각의 모순이 눈에 보였습니다.
그래서 순서를 통째로 뒤집었습니다. "만드는 재미 먼저, 어려운 도구는 필요해지는 순간에 하나씩." git·오픈소스를 빼는 게 아니라, "그게 정말 필요해지는 시점"으로 자리를 옮긴 거죠.
매일 뭔가가 쌓이는 "누적형" 프로젝트로
이번 설계에서 가장 공들인 부분입니다. 챌린지의 매 미션이 버려지는 연습이 아니라, 하나의 최종물로 쌓이게 만들고 싶었어요.
과정마다 실용적인 결과물을 하나씩 만들고 그 결과물들을 합쳐서 최종적으로
스터디원에게 도움이 되는 걸로 만들고 싶어. 예를 들어 이런식이지
1.내 학습메이트만들기 2.개념 배우기 페이지·용어사전 3.나만의 학습사이트 만들기 4.깃으로 버전관리
흐름은 이렇게 잡혔습니다. 내 학습 메이트(나를 도와줄 AI 도우미) 만들기 → 첫 페이지 만들기 → 개념·용어 조각 쌓기 → 그것들을 하나의 학습 사이트로 통합. 30일이 끝나면 흩어진 연습물이 아니라 "내 학습 본진" 하나가 손에 남습니다.
첫 주의 딜레마 — 몰아서 vs 매일 조금씩
여기서 한 번 크게 막혔습니다. 제가 운영하는 커뮤니티는 스케줄이 특이해요. 첫 주에 한 달 치를 몰아서 보여주고, 이후에 하나씩 구현하는 방식이거든요. 그런데 챌린지는 원래 "매일 조금씩 꾸준히"가 본질이잖아요. 둘이 정면으로 부딪혔습니다.
첫 주에 몰아넣자니 다른 스터디까지 들으며 너무 빡세고, 안 몰자니 다른 스터디를 따라갈 기본기가 안 잡히고.
해결책은 이랬습니다. 첫 주에는 "최소한의 바이브 코딩 기반"만 다지되, 그 과정에서도 눈에 보이는 간단한 결과물이 나오게 구성했어요. 첫 주부터 다른 스터디를 따라갈 최소 역량은 갖추면서, 동시에 작은 성취감도 얻게. 무거운 도구는 뒤로 미루고요. 아까 "만드는 재미 먼저"로 순서를 뒤집은 게, 이 딜레마까지 같이 풀어 준 셈입니다.
그리고 — 아무것도 안 옮겼는데 사이트에 올라갔다
여기가 이 글의 진짜 핵심입니다.
보통은 커리큘럼을 다 만든 다음, 그걸 포트폴리오 사이트에 또 옮겨 붙이는 작업이 남습니다. 저는 그 노동이 싫어서, 미리 사이트를 이렇게 만들어 뒀어요.
진실(원본)은 제 작업 폴더 한 곳에만 둡니다. 사이트는 그 폴더를 거울처럼 비추기만 합니다.
그래서 이번에도 커리큘럼을 만든 곳은 그냥 제 평소 작업 폴더였는데, 거기에 Day 파일들을 만들고 "공개" 스위치 하나를 켜자 — 사이트의 강의 탭에 강의 카드가 저절로 생겨났습니다. 옮겨 붙이기도, 목록 수정도, 코드 손대는 것도 없었어요.
원리는 단순합니다.
폴더 하나 = 강의 하나. 폴더를 만들면 강의가 하나 생긴 것.
각 파일에 "공개: 켜기/끄기" 스위치가 있어서, 켜야만 세상에 보입니다. 아직 다듬는 중이면 꺼 두면 되고요.
개발용 메모는 특정 표시 뒤에 적어 두면 방문자에겐 안 보입니다. "나만 볼 메모"와 "남에게 보일 소개"가 한 파일 안에서 자동으로 갈립니다.
결국 "커리큘럼을 만드는 작업"이 곧 "포트폴리오를 업데이트하는 작업"이 됩니다. 두 개가 하나로 합쳐지는 거예요.
✅ 결과 (After)
Before vs After
항목
Before
After
강의 자료 만든 뒤
사이트에 따로 옮겨 붙이는 노동이 남음
스위치 하나 켜면 사이트에 저절로 등장
포트폴리오 상태
귀찮아서 방치, 밖에서 보면 비어 있음
작업할수록 저절로 채워짐
강의 구조
도구를 첫 주에 몰아넣어 정신없음
"만드는 재미 먼저", 차근차근 따라감
매 기수 반복
매번 새로 정리
커리큘럼이 계속 누적 → 자동 마스터클래스
결과물
30일 바이브 코딩 챌린지 커리큘럼 — 하루 하나씩, 결과물이 누적되는 6주 구성
같은 내용의 4주 강의 커리큘럼 — 강사 포트폴리오·타 강의용
둘 다 별도 정리 노동 없이 사이트에 자동 반영
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
"결과물이 곧 콘텐츠가 되게" 구조를 먼저 짜라. 이게 제일 큰 교훈입니다. 만든 걸 나중에 정리하는 게 아니라, 작업하는 곳과 보여지는 곳을 처음부터 연결해 두면 "정리"라는 노동 자체가 사라집니다. 폴더 구조를 곧 사이트 구조로 설계해 두는 거죠.
AI와 대화하며 내 생각의 모순을 비춰 보라. "도구를 첫 주에 몰아넣은 게 목적과 정반대였다"는 걸, 혼자선 몰랐는데 AI와 주고받다가 깨달았습니다. AI는 답을 주기도 하지만, 내 생각을 되비추는 거울로도 좋습니다.
버전이 꼬이면 AI에게 기록을 뒤지게 하라. "그때 쓴 버전이 어디 갔지?" 싶을 때, 비개발자도 AI를 시켜 과거 기록을 되짚을 수 있습니다.
이렇게 하면 안 돼요
욕심내서 어려운 걸 앞에 몰지 마세요. 초보자용이라면 "빠른 첫 성취"가 먼저입니다. 좋은 도구라도 필요해지는 순간에 하나씩 꺼내야 따라옵니다.
"만든 다음에 정리하자"고 미루지 마세요. 그 정리는 대부분 영원히 안 합니다. 구조로 미리 해결해 두는 편이 낫습니다.
🌍 다른 업무에 적용한다면?
이 "거울 구조"는 강의에만 쓰이는 게 아닙니다. 블로그 글, 프로젝트 소개, 작업 일지 — 뭐든 "원본은 한 곳, 사이트는 그걸 비추기만" 하게 만들면, 일하는 것만으로 자기 브랜딩이 쌓입니다. 마케터라면 캠페인 회고가, 디자이너라면 작업물이, 기획자라면 문서가 저절로 포트폴리오가 되는 식이죠.
🚀 앞으로의 계획
게임처럼 즐기는 챌린지로: 이 30일 커리큘럼을 게이미피케이션(게임 요소를 입혀 재미있게 만드는 것) 방식과 붙여서, 매일 체크하며 성취감을 느끼는 형태로 발전시킬 계획입니다.
"자동 반영" 구조를 전방위로 확장: 지금은 강의·사례글 위주지만, 앞으로 제가 벌이는 모든 프로젝트를 같은 거울 구조에 태워서, 무엇을 하든 자동으로 한 사이트에 쌓이게 만들 생각입니다.
📋 재사용 가능한 프롬프트
프롬프트 1: 초보자용 커리큘럼을 "빠른 첫 성취" 순서로 재설계하기
지금 이 [강의/커리큘럼]을 초보자 관점에서 검토해줘. 특히 "빠른 첫 성취"가 언제 나오는지 봐줘 — 어려운 도구나 개념을 앞쪽에 몰아넣어서, 정작 초보자가 부담 없이 뭔가 만드는 재미를 늦게 느끼게 되어 있진 않은지. 그렇다면 "만드는 재미 먼저, 어려운 도구는 필요해지는 순간으로" 순서를 뒤집는 안을 제안해줘. [강의 주제]는 본인 상황에 맞게 바꾸세요.
프롬프트 2: 매 미션이 최종물로 쌓이는 "누적형" 흐름 설계하기
[기간, 예: 30일] 동안 하루 하나씩 진행하는 챌린지를 설계해줘. 조건: 매 미션이 버려지는 연습이 아니라, 결과물이 하나씩 누적돼서 마지막엔 [최종 결과물, 예: 나만의 학습 사이트] 하나로 합쳐지게 만들어줘. 각 미션이 앞 미션의 결과물 위에 쌓이는 순서로 배치해줘. [ ] 안은 본인 상황에 맞게 바꾸세요.
아침마다 이런 적 없으세요? 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도 모름)가 Claude Code와 대화만으로 문자 업무를 대신해주는 안드로이드 앱 '나리'를 이틀 만에 만들었습니다. 매일 저녁 1~2시간 걸리던 문자 릴레이가 알림 확인 몇 번으로 줄어들 예정입니다.
바쁘시면 이것만 읽어도 돼요:
Claude Code로 인력 배치 문자 업무 자동화 앱 제작 — 이틀간 버전 15번 업데이트
문자 대화 캡쳐 14장을 통째로 줬더니 AI가 5개월치를 읽고 우리 회사 업무 규칙을 스스로 정리
테스트 간 불편한 걸 말하면 몇 분 뒤 새 버전이 도착하는 사이클
"이럴 때 나는 뭘 해야 하지?"라는 업무 질문이 그대로 기능이 됨
막혔던 곳: 문자가 앱에 안 들어와서 헤맴 → 알고 보니 '채팅+' 때문 (해결법 본문에)
핵심 교훈: 실제 자료를 통째로 주고, 작게 만들어서 바로 써보기
🎯 이런 분들께 도움돼요
문자·전화 반복 업무에 매일 시간을 뺏기는 자영업자·소상공인 사장님 (강추!!)
AI 코딩 도구로 내 업무 자동화를 시도해보고 싶은 직장인
"개발을 하나도 모르는데 앱을 만들 수 있을까?" 궁금하신 분
😫 문제 상황 (Before)
우리 회사 저녁 풍경은 매일 똑같았습니다.
거래처 과장님 문자가 옵니다 — "내일 주간 5명 야간 2명 입니다~". 그럼 여사님들께 한 분 한 분 확인 문자를 보냅니다. "내일 주간 들어가세요. 출근 가능 여부 답주세요~". 회신을 기다립니다. "네"가 오면 명단에 적고, 안 오면 재촉 문자를 보내고, 그래도 없으면 전화를 겁니다. 못 온다는 분이 있으면 다른 분을 찾습니다. 그렇게 모은 명단을 저녁 8시 전까지 거래처에 회신해야 하루가 끝납니다.
중간에 "인원 정정합니다~"가 오면 처음부터 다시. 여기에 월초마다 여사님들께 출근일수를 문자로 걷어서 수작업 정산까지. 매일 저녁이 이 문자 릴레이에 묶여 있었습니다.
매일 반복되는 이 대수롭지 않지만 중요한 일을 자동화 해보기로 마음먹었습니다.
어플 개발전 고민의 흔적들..
🛠️ 사용한 도구
도구: Claude Code (Windows 데스크톱 앱) + 클로드 폰 앱 (원격 제어)
모델: Claude Fable 5
특이사항: 개발 프로그램이 하나도 없는 일반 PC에서 시작 — 개발 환경 설치부터 앱 완성까지 전부 AI가 진행. 저는 코드를 한 줄도 쓰지 않았고, 볼 일도 없었습니다.
🔧 작업 과정
업무를 말로 설명하는 것에서 시작
거창한 기획서 없이, 제 업무를 그대로 적어서 던졌습니다.
나는 현재 공장에 인력을 투입하는 아웃소싱 업체 대표야.
1. 거래처로부터 문자를 통해 주문을 받고,
2. 어떤 인원(특정)을 몇명 요청하는지를 파악 후
3. 해당 인원(인력)들에게 요청일자에 작업 투입이 가능한지 확인하는 문자를 보내고
4. 거래처 요청 인력을 충족하는 문자 회신 완료 갯수를 확인 후
5. 재차 거래처에게 요청일자 예정 투입인력에 대한 문자를 회신. 위 일을 대신하는 인력 관리 어플리케이션, '나리'를 만들고 싶어.
어떤 식으로 진행해야 할지, 더 필요한 자료들은 뭐가 있을지를 알려줘.
'나리'는 우리 집 강아지 이름입니다 🐶 이름을 이렇게 지은 데는 이유가 있습니다. 반려동물을 키우는 건 사실 굉장히 귀찮고 정성이 들어가는 일인데, 정성을 쏟는 만큼 애착도 커지더라고요. 처음엔 그렇게 귀찮던 강아지가 어느새 우리 집 귀염둥이 막내가 된 것처럼 — 지피터스의 '뽀짝이'가 그런 존재가 된 걸 보고 벤치마킹했습니다. 이 앱도 처음엔 손이 많이 가겠지만, 정성을 쏟다 보면 결국 우리 회사의 막내 직원이 되어주길 바라는 마음이었습니다.
작업 개시전 고민이 많았습니다. 업무 자동화를 핸드폰으로도 가능할지 의문이었고, 여러가지 다양한 상황이 생길수 있기에 불안함도 어느정도 있었습니다. 그러나 클코(클로드코드, 첫날 못알아 듣는다고 혼났어요.)는 우선적이지만 쉬운, 당장 해야할 과제를 주었습니다. 문자를 주고받는 방식 세 가지를 보고 비교적 정형화 되있어 자동화하기 좋은 작업이라 용기를 주더군요. 그리고 이어서 "문자 캡쳐본을 최대한 많이, 특히 취소·정정 같은 예외 사례를 모아달라", "머릿속에만 있는 업무 규칙을 알려달라"고 숙제를 줬습니다. 일 잘하는 신입사원 같다는 느낌을 처음 받은 순간이었습니다.
캡쳐 14장을 던졌더니, 우리 회사 규칙이 정리되어 나왔다
거래처·여사님들과 주고받은 문자 캡쳐 14장(5개월치, 스크롤이 아주 긴 것들)과 연락처 엑셀을 폴더에 넣고 알려줬습니다.
자료를 "…\D산업" 폴더에 입력해뒀어.
진행하기 이전에 자료들을 모두 살펴보고 더 필요한 자료가 있다면 지금 말해줘.
잠시 후 돌아온 분석 결과에 놀랐습니다. 주문 문자의 패턴("내일 ○요일 주간 N명 야간 N명 입니다~"), 여사님들 회신의 90%가 "네" 한 글자라는 것, 제가 거래처에 보내는 명단 문자의 양식까지 — 제가 설명한 적 없는 우리 회사의 일하는 방식을 문자에서 스스로 뽑아냈습니다.
압권은 이거였습니다: "대화에는 나오는데 연락처 명단에 없는 분이 세 분 있습니다. 지금도 일하시는 분들인가요?" — 캡쳐 속에서 사람 이름을 대조해 빠진 사람을 찾아 되물은 겁니다.
개발 첫날, v0.1이 폰에 깔렸다
디자인 시안 3개 중 하나를 고르고, 업무 규칙 네 가지(최근 많이 나간 분 우선, 30분 무응답이면
재촉, 미달이면 거래처와 통화, 명단은 전날 저녁 8시까지)를 확정해주자 개발이 시작됐습니다.
개발 프로그램이 하나도 없는 PC였는데, AI가 필요한 도구들을 알아서 내려받아 설치하고, 앱을 만들고, 설치 파일을 클라우드 폴더에 넣어줬습니다. 폰에서 그 파일을 눌러 설치하니 — 아이콘에 우리 강아지 얼굴이 박힌 앱이 진짜로 폰에 떴습니다.
폰으로 써보고, 말하면, 몇 분 뒤 새 버전 (이틀간 15번)
여기서부터가 진짜였습니다. 테스트폰으로 실제처럼 문자를 보내보면서 불편한 점을 그대로 말했습니다.
설치해서 테스트 해봤는데, 아래와 같은 문제를 발견했어.
1. 주간 오타나니까 인식 못함
2. 주간 야간 구분해서 최근 많이 나간 인원을 선별해서 추천해줘야 함
모레라는 말을 못알아 듣니? 모레는 2일 후를 말하는거야. 글피는 3일 후.
이정도는 알아들어줬으면 좋겠어.
이런 피드백을 보내면 몇 분 뒤에 고쳐진 새 버전이 도착했습니다. 오타가 나도 알아듣고, "주간 3"처럼 '명'을 빼먹어도 알아듣고, 글피까지 이해하는 앱이 되어갔습니다. 이틀 동안 이 사이클을 15번 돌렸습니다.
말로 설명하기 어려울 땐 화면 캡쳐를 보냈습니다. "버튼이 찌그러졌다", "세 번째 사람이 안 보인다" 같은 건 캡쳐 한 장이 백 마디 말보다 빨랐습니다.
물론 잔소리도 필요했습니다. 개선하겠다고 말만 하고 다음 버전에 안 들어가 있길래 한마디 했더니, 그 다음부터는 말한 것을 그 버전에 바로 반영하더군요. 강아지 사진을 옆으로 누운 채로 넣어놔서 "미적 감각 좀 발휘해봐"라고 다시 시켰습니다. AI도 직원처럼, 피드백을 정확하게 해줘야 잘합니다.
내 질문이 기능이 되다
가장 신기했던 경험은 이겁니다. 데모 화면을 보다가 업무 질문을 그냥 던졌습니다.
김○분 씨가 내일 병원가서 못한다고 문자를 보냈어. 그럼 다음에 내가 어떤 행동을 할까?
1. 다른 대체 인력에게 문자를 보낸다
2. 다른 대체 인력에게 전화를 한다.
3. 인원이 불가하다고 거래처에 전화를 한다.
AI의 답: "1번이 첫 행동입니다. 그런데 이 질문 덕분에 앱에 그 '1번 버튼'이 없다는 걸 발견했습니다. 바로 만들겠습니다." — 30분 뒤, 불가 회신이 오면 대체 인력 후보를 추천순으로 보여주는 버튼과, 자동 모드에서는 불가 문자가 오는 순간 다음 후보에게 알아서 확인 문자를 보내는 기능이 새 버전에 들어 있었습니다.
기능 요청 이전에 업무 프로세스 순서가 저렇다는 것을 알려주려고 했는데, 스스로 기능을 추가하고 버전업 시키더군요.
"네가 알아서 고칠 부분을 찾아봐"
이틀째에는 아예 이렇게 시켜봤습니다.
내가 얘기 하지 않았지만 너가 판단해서 필요한 부분이나 수정할 부분들을 찾아서 얘기해주는게 너무 맘에 든다.
나와 나눈 대화를 토대로 더 알려주거나 수정하거나 더해졌으면 하는 기능들을 알려주고 다시 만들어줘.
AI는 우리가 나눈 대화에서 제가 헷갈렸던 순간들을 복기해서 네 가지를 스스로 찾아 반영했습니다 — 버전 헷갈리지 않게 화면에 표시, 같은 날짜 주문이 겹치면 경고, 지나간 주문 자동 정리, 테스트 기록 한 번에 지우기. 시킨 것만 하는 도구가 아니라 같이 일하는 느낌을 받은 지점입니다.
막혔던 이야기 — 문자가 안 들어온다?
순탄하지만은 않았습니다. 어느 순간부터 테스트 문자에 앱이 전혀 반응하지 않았습니다. 앱이 고장난 줄 알았는데, 원인은 뜻밖에도 '채팅+'(RCS) — 요즘 폰 문자앱은 서로 지원하면 문자가 아니라 메신저(채팅) 방식으로 보내는데, 이건 문자가 아니라서 어떤 앱도 읽을 수 없는 구조였습니다. 해결은 간단했습니다: 앱이 설치된 폰에서 채팅+ 기능만 끄면, 상대가 뭘로 보내든 문자로 도착합니다.
이 사건 이후 AI에게 "문자마다 네가 어떻게 판단했는지 기록을 남겨라"라고 시켜서 앱 안에 진단 로그 화면이 생겼고, 그다음부터는 "왜 반응이 없지?"를 캡쳐 한 장으로 원인 파악할 수 있게 됐습니다. 문제가 생기면 포기하는 게 아니라, 문제를 진단하는 도구를 만들어달라고 하면 됩니다.
✅ 결과 (After)
Before vs After
항목
Before
After
저녁 문자 릴레이
매일 1~2시간 (주문 파악→개별 문자→집계→명단 회신)
알림 확인 + 버튼 몇 번, 자동 모드는 예외 상황만 개입
재촉·독촉
시계 보며 수동
30분 무응답 시 자동 재촉, 이후 전화 권장 알림
명단 실수
날짜 오타·오발송 가능
날짜는 주문 카드에서 자동 생성 — 손으로 쓸 일 없음
월초 정산
출근일수 문자로 걷어 수작업
앱이 월별 자동 집계
앱 수정
(외주라면 건당 비용+대기)
대화로 요청 → 몇 분 뒤 새 버전, 이틀간 15회
현재는 기존 방식과 병행하며 검증 중이며, 안정되면 자동 발송 모드로 완전 전환할 예정입니다.
결과물
안드로이드 앱 '나리' v1.4 — 문자 주문 자동 해석, 실시간 현황판, 자동 발송 모드, 회신 자동 판정(번복까지 처리), 인원 편집, 정산 자동 집계, 진단 로그
그리고 무엇보다: "내 업무 도구를 내가 만들 수 있다"는 자신감. 다음 자동화 아이디어가 벌써 여러 개입니다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
실제 자료를 통째로 주기 — 말로 설명하려 애쓰지 말고 문자 캡쳐·엑셀을 그대로 던지세요. AI가 알아서 규칙을 뽑고, 빠진 것까지 되물어봅니다.
작게 만들어 바로 써보기 — 완벽한 기획 대신 반나절 만에 v0.1을 폰에 깔고, 쓰면서 고치는 게 훨씬 빠릅니다. 15번의 작은 업데이트가 한 번의 큰 기획을 이깁니다.
화면 캡쳐로 피드백 — "설명하기 어려운 불편함"은 스크린샷 한 장이 가장 정확한 언어입니다.
업무 질문을 그대로 던지기 — "이럴 때 나는 뭘 하지?"라는 질문이 빠진 기능을 찾아줍니다.
이렇게 하면 안 돼요
말한 것이 반영됐는지 확인 없이 넘어가기 — AI도 직원처럼 "말만 하고 안 했네?"를 잡아줘야 합니다.
디자인 감각을 전적으로 믿기 — 사진이 옆으로 눕는 일도 생깁니다. 결과물은 꼭 눈으로 확인하세요.
안 되면 바로 포기하기 — "통신망 법 때문에 안 된다더라" 같은 소문에 흔들리지 말고, 기록(로그)을 근거로 원인을 찾으면 대부분 답이 나옵니다.
🌍 다른 업무에 적용한다면?
문자로 굴러가는 반복 업무라면 구조가 거의 같습니다 — 미용실·식당의 예약 확인과 리마인드, 학원의 출결 안내, 소규모 도매의 발주 접수와 확정 회신, 기사님 배차 확인 같은 것들요. "받은 연락을 해석하고 → 여러 명에게 확인을 돌리고 → 집계해서 회신"하는 일이라면 이 글의 방식이 그대로 통합니다.
🚀 앞으로의 계획
실전 투입 — 1~2주 병행 운영으로 검증 후 자동 발송 모드로 전환 (병목의 순기능)
나리 에이전트화 — 나리를 텔레그램 대화 상대로 만들어서, 규칙 변경("재촉은 40분으로 바꿔")을 앱 재설치 없이 대화로 끝내는 구조로 발전
정산·급여 자동화 완성 — 출근일수 집계를 넘어 급여 계산까지
다른 업무도 AI로 — 이번에 익힌 방식으로 다음 반복 업무 자동화
📋 재사용 가능한 프롬프트
프롬프트 1: 업무 자동화 시작
나는 [업종]의 [역할]이야. 내 업무는 이래: 1) … 2) … 3) … 위 일을 대신하는 [앱/도구]를 만들고 싶어. 어떤 식으로 진행해야 할지, 더 필요한 자료들은 뭐가 있을지를 알려줘.
[업종/역할/업무 단계]를 본인 상황에 맞게 바꾸세요. 업무를 번호 매겨 순서대로 쓰는 게 포인트입니다.
프롬프트 2: 실제 자료 분석시키기
자료를 [폴더 위치]에 넣어뒀어. 진행하기 이전에 자료들을 모두 살펴보고, 더 필요한 자료가 있다면 지금 말해줘.
캡쳐·엑셀·문서를 폴더에 몰아넣고 위치만 알려주면 됩니다.
프롬프트 3: 테스트 피드백
설치해서 테스트 해봤는데, 아래와 같은 문제를 발견했어.
[문제 1] 2. [문제 2] 위 오류를 범하지 않도록 수정해줘.
화면 캡쳐를 함께 첨부하면 효과가 배가 됩니다.
프롬프트 4: 알아서 개선시키기
내가 얘기하지 않았지만 네가 판단해서 필요한 부분이나 수정할 부분들을 찾아서 얘기해주고, 반영해줘.
작업이 어느 정도 쌓인 뒤에 쓰면 AI가 대화를 복기해서 빠진 것을 찾아옵니다.
🙏 감사한 분들
도착하자마자 클로드 코드 설치부터 도와주신 SOPA님
갈피도 못 잡고 방황하고 있을 때 첫 발걸음을 뗄 수 있게 해주신 타타님
데이터 구조화에 대한 개념과 사업적인 방향까지 제시해주신 쭌님
볼 때마다 잘 되고 있냐며 수시로 여쭤보고 작업 방향을 제시해주신 정기님
사내 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) 호출 부분이 인증 없이 열려 있는지, 무제한 호출 시 비용이 어떻게 청구되는지 짚고,
그럴듯한 방어(예: 출처 검증)가 우회 가능한지까지 냉정하게 검토해줘.
소개
개인 투자자가 넘쳐나는 시황·매크로·뉴스 속에서 "내 포트폴리오에 의미 있는 신호"를 스스로 찾기 어려운 문제를 해결하고자 함.
야간 미장·매크로·KRX 시세를 여러 앱과 텔레그램으로 직접 취합하는 번거로움을, 내 계좌 기준 한 화면으로 압축하고자 함.
단발성 리포트가 아니라 AI가 지식을 쌓고(위키) → 인과로 잇고(그래프) → 에이전트가 자율로 진단·점검하는(LangGraph) 3층 자동화로 만들고자 함.
클라우드 의존과 구독 비용을 최소화하고, 내 컴퓨터(맥)에서 로컬로 돌아가는 자기 소유 시스템을 지향함.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
Tip: 코드 전문은 코드블록에 감싸서 작성해주세요. ( / 을 눌러 '코드 블록'을 선택)
LLM 위키 (Obsidian + 위키 사서 AI): 종목·매크로·뉴스·투자 결정을 위키 문서로 축적하고 자동 분류·링크·정합에 사용함.
GraphRAG (PostgreSQL + pgvector): ETF·종목·매크로·뉴스·공시를 11종 관계로 묶은 인과 지식그래프 구축에 사용함.
로컬 LLM (gemma 31B, ollama) + embeddinggemma 768d: 뉴스에서 관계 추출과 의미 임베딩을 전부 로컬에서 처리하는 데 사용함.
통계 인과 (statsmodels): Granger + 다변량 VAR/IRF로 충격 전파를 수치화하는 데 사용함.
에이전트 오케스트레이션 (LangGraph · LangChain): 역할별 전문 AI(팀장·분석가·집행관·사서)를 작업 흐름으로 묶어 자율 운영하는 데 사용함.
데이터 소스: KRX·KIS·yfinance·FRED/ECOS·네이버 데이터랩·DART·YouTube·Tavily를 한 그래프로 통합하는 데 사용함.
결과
1️⃣ 3층 아키텍처 = 하나의 자동화 흐름
LLM 위키(지식 축적) → 그래프래그(인과 연결) → 에이전틱 AI(자율 실행)로, 위로 갈수록 "스스로 판단·실행"에 가까워지도록 동선을 설계함.
2️⃣ 1층 — LLM 위키
Obsidian 기반 위키에 종목·매크로·개념·뉴스를 문서로 축적하고, 위키 사서 AI가 새 자료를 자동으로 분류·링크·정합하도록 함.
실제 위키 그래프뷰에서 수백 개 문서가 이미 거대한 연결망을 이루고 있음(이번 발표의 출발점).
3️⃣ 2층 — 그래프래그 (이번 작업의 핵심)
종목→ETF 편입(비중), 매크로→가격 전파, 뉴스→영향 등 11종 관계·8만+ 엣지로 그래프를 구성함.
규칙 기반·LLM 추출·통계 인과 3가지 방식으로 엣지를 생성하고, 엔티티 해상도로 "엔비디아=NVIDIA"를 한 노드로 통합함.
다차원 인과 망과 SVAR/IRF로 "충격이 어느 종목까지 며칠 시차로 전파되는지"를 추적함.
4️⃣ 3층 — 에이전틱 AI (LangGraph)
팀장·분석가·집행관·사서 역할의 AI가 그래프를 활용해 자율로 분석·점검·핸드오프하도록 함. LangChain=도구 배관, LangGraph=작업 흐름 지휘.
중요한 결정은 사람 승인 게이트(텔레그램 확인)를 거치도록 함.
5️⃣ 데이터 파이프라인 & 정합
9종 소스를 PostgreSQL로 수집하며, KRX 당일 시세의 T+1 지연은 KIS 당일가로 채워 괴리 0%로 정합함.
6️⃣ 산출물 채널
프리마켓 퀵샷·클로징벨·주간·헤지펀드 PM 톤 리포트를 텔레그램으로 내 계좌 기준 자동 발송하고, 동적배분·RS/CANSLIM·세제 계산 등을 제공함.
배운 점
지식을 점이 아니라 인과의 선으로 이으면(그래프래그) "왜?"라는 질문에 경로로 답할 수 있음을 확인함.
로컬 LLM에서 thinking 모드를 끄는 작은 튜닝만으로 추출 속도가 6.5배 빨라짐을 확인함.
출처·기준일을 분리하고 LIVE로 재검증하는 절제가 시스템 신뢰의 핵심임을 배움.
3층(위키→그래프→에이전트)으로 나누면 각 층을 독립적으로 키우고 검증할 수 있음을 깨달음.
과정 중에 어떤 시행착오를 겪었나요?
종목 단위 리포트의 한계를 깨닫고 "관점" 단위로 전환하는 과정에서, 계좌·ETF·뉴스·매크로를 그래프로 묶어야 진짜 진단이 됨을 GraphRAG로 돌파함.
인과 그래프가 종목 그래프와 다리 3개뿐인 외딴 섬이었던 문제를, 브리지 엣지로 222개까지 이어 전파 경로를 복원함.
시뮬레이션(픽션) 데이터와 실세계 데이터의 시계열 괴리로 매크로 인과 분석이 깨지는 한계를, 이력이 긴 ETF 패널로 대체하고 그 한계를 정직하게 명시함.
통계 모델이 노이즈에서 엉뚱한 시차를 골라 결과가 깨지는 문제를 고정 시차로 교정했으며, 도구의 "성공" 메시지를 믿지 않고 LIVE로 재검증하는 습관을 들임.
데이터의 출처와 기준일을 항상 분리 표기(예: 비중=운용사 공식, 기준가=시스템 종가)하여 추정·픽션을 사실로 단정하지 않도록 함.
도움이 필요한 부분이 있나요?
앞으로의 계획이 있다면 들려주세요.
맨 위층 에이전트 자동화(LangGraph)를 본격 가동하여, 여러 에이전트가 그래프 위에서 자율로 일하는 단계로 확장할 계획임.
그래프래그 3계층(GNN 링크 예측으로 빠진 관계 추론·그래프 신호 재랭킹·전용 그래프DB·실전 백테스트 검증)을 추진할 계획임.
내 계좌 기준 정량 분석 풀스택(RS/MDD/Granger/CANSLIM/백테스트)을 자동 매핑할 계획임.
도움 받은 글 (옵션)
참고한 지피터스 글이나 외부 사례를 알려주세요.
(내용 입력)
상담센터 바우처 행정 웹앱 구축기 — 실무진과 실시간으로 핑퐁하면서, 가짜 데이터 프로토타입 5단계 → 진짜 DB 전환 → 배포까지
🎯 바쁘시면 이것만 읽어도 돼요
코딩 못 하는 자동화 담당 직원이 Claude Code로 상담센터 바우처 행정 웹앱을 만들었어요 — 첫날은 규칙 세팅, 둘째 날에 프로토타입 5단계 + 진짜 DB 전환 + 배포까지 갔어요
비결은 "한 번에 다 만들어줘"가 아니라, 가짜 데이터로 화면을 먼저 완성하고 DB는 나중에 갈아끼우는 순서였어요
제일 큰 고비는 코딩이 아니었어요 — 실무진의 업무를 제가 요약해서 AI한테 전달하는데, 그 요약이 현장과 달라서 화면 다 만든 뒤에 데이터 구조를 갈아엎었어요
👀 이런 분들께 도움돼요
동료·팀이 쓸 업무 도구를 대신 만들어주는 역할을 맡은 비개발자
"AI한테 뭐라고 시켜야 할지"보다 "실무자한테 뭘 물어봐야 할지"가 막막한 분
프로토타입은 만들어봤는데 진짜 DB·로그인·권한으로 넘어가는 게 무서운 분
만들다가 구조가 틀렸다는 걸 알았을 때 갈아엎어야 하나 고민해본 분
😮 Before: 우리 센터 바우처 업무엔 '한눈에 보는 화면'이 없었어요
최근 클코를 배우다보니 상담센터에서 자동화를 맡게 되었어요. 상담이나 행정을 직접 보는 실무자는 아니지만 옆에서 본 바우처 업무는 손이 많이 갔어요 — 내담자마다 바우처를 등록하고, 상담사가 자필 제공기록지를 내고, 소장님이 확인해야 정산이 되고, 본인부담금 입금도 챙겨야 해요. 역할도 상담사·행정·회계·소장 넷으로 갈리고요. 이게 한 화면에 모이는 도구가 없어서, 누가 뭘 냈고 뭐가 빠졌는지는 결국 실무진이 기억해야 했어요. 그러다보니 누락도 많이 생겼고요.
✨ After: 4역할이 같이 쓰는 웹앱이 이틀 만에 URL로 나왔어요
로그인하면 역할별로 다른 메뉴가 보이고, 기록지 제출 → 소장 확인 → 정산 반영이 화면 안에서 흘러가는 웹앱이 됐어요. 첫날 워크스페이스 세팅, 둘째 날 프로토타입 5단계 → Supabase(진짜 DB) 전환 → Vercel 배포까지. 코드는 한 줄도 직접 안 썼어요. 대신 말을 정말 많이 했어요 — AI한테도, 실무진한테도요.
🛠️ 이 앱이 하는 것 (배경 30초)
내담자×바우처 단위로 등록을 관리해요 (기간·등급·담당 상담사)
상담사는 회기별 기록지 사진을 올리고, 소장은 확인 버튼으로 정산에 반영해요
본인부담금 입금은 회계·소장만 수정할 수 있고, 상담사는 본인 내담자만 보여요
미제출·미확인이 화면에서 바로 표시돼요 — "실무진이 기억하던 것"이 앱의 일이 됐어요
🔨 과정: 규칙 → 가짜 데이터 → 번역 오류 발각 → 진짜 DB
1️⃣ 첫날은 코딩 대신 규칙만 세웠어요
바로 "만들어줘" 하고 싶은 걸 참고, 첫날은 워크스페이스에 규칙 문서(CLAUDE.md)부터 만들게 했어요. 핵심 규칙은 세 개였어요 — 자격·금액·일자는 추정 금지, 불확실하면 나한테 질문할 것 / 개인정보는 로컬에만, git에 못 올라가게 차단 / 등록·제출의 최종 확정은 사람이 할 것. 내담자 정보를 다루는 앱이라 이 세 줄이 없으면 시작을 못 했어요. 하루를 썼는데, 이후 작업 내내 AI가 애매하면 멈추고 물어봤으니 본전은 충분히 뽑았어요.
2️⃣ 가짜 데이터로 화면을 먼저 다 만들었어요
둘째 날, 프로토타입을 5단계로 쪼개서 진행했어요 — 뼈대 → 데이터 모델·4역할 전환 → 배정 화면 → 일정·기록지 업로드 → 소장 확인·본인부담금. 이 단계에선 DB도 로그인도 없이 전부 가짜 데이터예요. 덕분에 "화면이 실제 업무랑 맞나"만 보면 됐고, 단계마다 제 눈으로 확인하고, 애매한 건 실무진한테 바로 물어보고, code-review를 시키고 저장(커밋)하고 넘어갔어요. 리뷰가 제가 못 봤을 타입 버그를 실제로 하나 잡아내기도 했고요.
3️⃣ 😲 하이라이트: "내담자 한 명 = 상담사 한 명" — 제 번역이 틀렸어요
본인부담금 화면까지 다 만들고 나서야 알았어요. 결과적으로 바우처를 두 개 받는 내담자 같은 상황이 생길 수 있다고 들었고 바우처마다 담당 상담사가 달라요. 그런데 앱은 제가 AI한테 처음 설명한 대로 "내담자에게 상담사 한 명"으로 짜여 있었어요. AI가 틀린 게 아니에요. 실무진의 업무를 AI한테 전달하는 중간에서, 제가 잘못 요약한 거예요.
화면을 다 만든 뒤라 고민했는데, 결국 데이터 구조를 통째로 갈아엎었어요 — 모든 관리 단위를 '내담자'에서 '내담자×바우처(등록)'로요. 사람 개발자한테 이걸 부탁했으면 며칠짜리 부탁이었을 텐데, AI는 갈아엎는 걸 무서워하지 않더라고요. 반나절 안에 화면들이 새 구조로 다시 맞춰졌어요.
비슷한 일이 한 번 더 있었어요. 등록여부(O/X) 관리 기능을 만들었는데, 소장님이 한마디 하셨어요 — "상담사 배정이 안 되면 일정 등록도 안 해요." 그 말 한마디에 기능을 통째로 뺐어요. 실무진의 한 문장이 제 기획 열 줄보다 정확했어요. 실시간으로 물어볼 수 있는 거리에 실무진이 있다는 게 이 프로젝트 최대의 자원이었어요.
4️⃣ 진짜 DB로 갈아끼우기 — 읽기부터, 권한은 맨 끝에
화면이 업무와 맞다는 확신이 생긴 뒤에야 Supabase(진짜 DB)로 넘어갔어요. 순서를 잘게 쪼갰어요 — ① 테이블 설계 ② 읽기만 DB로 전환(쓰기는 아직 가짜) ③ 진짜 로그인 ④ 쓰기 전환 ⑤ 역할별 권한을 서버에서 강제(RLS). 권한은 화면에서 숨기는 걸로 끝내지 않고, 검증 스크립트를 돌려서 "상담사 계정으론 진짜 본인 것만 보이는지"를 확인하고 통과시켰어요. 끝나고 Vercel로 배포해서 URL을 받았어요.
📊 결과
단계
한 것
확인 방식
1일차
워크스페이스 + 규칙 3종 (추정 금지·개인정보 로컬·확정은 사람)
규칙 문서 리뷰
2일차 오전~
프로토타입 5단계 (가짜 데이터)
단계마다 눈 검증 + 실무진 확인 + code-review + 커밋
2일차 ~밤
DB 전환 5단계 (읽기→로그인→쓰기→권한)
권한 검증 스크립트 통과
직후
Vercel 배포
팀이 URL로 접속
역할 4종(상담사·행정·회계·소장)별 메뉴·권한 분리, 권한은 서버 강제
중간에 데이터 모델 1회 전면 교체, 만든 기능 1개 드롭 — 둘 다 "실무진이 더 정확해서"
💡 효과적이었던 것
가짜 데이터로 먼저 완성한 것 — 화면과 업무가 맞는지부터 검증하고, DB는 나중에 갈아끼웠어요. 모델을 갈아엎는 대사건이 있었는데도 이 순서 덕에 피해가 화면 수정으로 끝났어요
단계마다 멈춰서 확인한 것 — 제 눈 검증 + 실무진 확인 + code-review + 커밋 세트. 어디서 틀어졌는지 항상 한 단계 안에서 찾을 수 있었어요
실무진 말을 스펙으로 쓴 것 — 소장님 한마디로 기능을 빼고, 실제 내담자 사례로 모델을 바꿨어요. 제가 정리한 요구사항보다 현장 문장이 셌어요
⚠️ 이런 건 아쉬웠어요
남의 업무를 받아 적는 건 생각보다 어려웠어요. 실무진은 당연해서 말하지 않는 게 많고, 저는 몰라서 묻지 못하는 게 많았어요. "바우처 2개 내담자" 같은 예외는 묻기 전엔 안 나와요
실제 데이터 몇 줄을 너무 늦게 봤어요. 처음부터 진짜 내담자 명단 몇 줄(가명으로라도)을 실무진한테 받아서 같이 봤으면, 그 예외를 화면 만들기 전에 발견했을 거예요
📋 따라하려면
실무자를 인터뷰해서 업무를 역할별로 적어요 — "누가, 뭘 내고, 누가 확인하고, 뭐가 돈이 되나". 실무자가 당연해서 말 안 한 것이 진짜 스펙이에요
시작 전에 규칙 3줄부터 만들어요 — 추정 금지 / 민감정보 로컬만 / 최종 확정은 사람
가짜 데이터로 화면 먼저 — DB·로그인은 화면이 업무와 맞다는 확신이 든 다음에
단계마다 직접 확인 + 실무진 확인 + code-review + 커밋, 세트로 묶어서 진행해요
실제 데이터 샘플(가명) 몇 줄을 초반에 받아서 AI한테 보여줘요 — 예외 케이스가 모델을 결정해요
DB 전환은 읽기 → 로그인 → 쓰기 → 권한 순서로 쪼개요
내 다음 목표
진짜 데이터(내담자 200명, 2년치 기록)를 부어서 실운영에 들어가기 — 그리고 여기서 사건이 하나 터지는데, 그 이야기는 따로 한 편으로 할 예정.
현황 화면을 요약 패널에서 제대로 된 대시보드로 키우기
실무진이 보고 따라할 역할별 사용 가이드 만들기
