내 학습허브 — 학습 전자책
학습위키를 책으로 묶었어요. 로드맵이 서문, 주차가 챕터예요. 지금 25꼭지.
내 학습허브
AI와 함께한 한 달의 학습 기록
4주 로드맵 — B2B 잠재고객 발굴 에이전트 만들기 (대상 솔루션 비공개)
4주 뒤 내 손에 남는 것
- 나만의 AI 학습메이트, 콩콩 — 나를 알고, 다정하게 옆에서 도와주는 AI. (완료)
- 확정된 내 주제 + 이 로드맵 — 회사의 특정 솔루션(○○회사 · ○○ 솔루션, 사명 비공개)에 맞는 B2B 잠재고객을 찾아주는 에이전트.
- 실제로 작동하는 미니 에이전트 1개 — ○○ 솔루션에 맞는 잠재고객 프로필을 세우고, 그 프로필에 맞는 한국 회사를 에이전트가 직접 찾아내 공공데이터·홈페이지·뉴스로 검증·보강해 구글시트에 채워주는 것. (자세한 실행 계획은 → PRD·세부계획 페이지)
- 혼자서도 다음 자동화를 만드는 근육 — API 연결, 구글시트 연동, 클로드 코드로 스크립트/에이전트 만들기 경험.
지금 나 → 4주 뒤 나
| 지금 | 4주 뒤 | |
|---|---|---|
| 할 수 있는 것 | 완전 초보 — API·에이전트·구글시트 자동화 다 처음 | 공공데이터 API를 연결해 회사 정보를 자동으로 구글시트에 채우는 미니 에이전트를 직접 다룸 |
| 지금 방식 | 마케팅 에이전시에 아웃소싱 — 회사 1곳당 약 1,500원(콜 1,000개면 1천5백만원). 또는 기업DB를 수십만원에 사고 + 사람이 회사 홈페이지 일일이 방문해 정보 보완 | 무료 공공데이터 API로 회사 기본정보를 자동 조회 (담당자 개인 연락처는 다음 단계 과제로 분리) |
| 왜 | 잠재고객 DB 구축 비용이 크고, 정보가 금방 낡고(outdated), 결국 사람이 판단·보완해야 하는 부분이 많아서 | 반복되는 조회·필터링·입력 작업을 AI가 대신하게 하고 싶어서 |
이번 프로젝트 조건 (범위를 명확히)
- 한정 솔루션: 특정 회사의 특정 제품 하나로 한정 (사명·제품명 비공개 — 아래 ○○로 표기).
- 쓰는 사람: 체이스 혼자 쓰는 개인 도구.
- 데이터 출처: 1차로 한국 공공데이터포털(data.go.kr)의 기업기본정보·재무정보 API, 국세청 사업자상태 API, OpenDART로 후보를 찾고, 회사 홈페이지·뉴스 검색으로 정보를 검증·보강한다. (사설 유료 DB는 안 씀)
- 제일 어려운 부분: 정확한 잠재고객을 찾아내고 정보를 검증·보강하는 것. (공개된 정보만으로는 한계가 있어서 — 자세한 내용은 PRD 참고)
- 이번 4주엔 안 하는 것: 담당자 개인 성명·연락처 자동 수집. (공공데이터엔 없는 개인정보라 4주 밖 과제로 남김) 콜드 이메일 관련 기능도 범위에서 제외 — 리드 발굴·검증이 핵심이라 여기 집중.
주차별 계획
| 주차 | 기간 | 주제 |
|---|---|---|
| 1주차 | 7월 23일 ~ 7월 29일 (7일) | 기획 |
| 2주차 | 7월 30일 ~ 8월 5일 (7일) | 제작 |
| 3주차 | 8월 6일 ~ 8월 12일 (7일) | 완성 |
| 4주차 | 8월 13일 ~ 8월 17일 (5일) | 회고·발표 |
1주차 (7/23~7/29) — 기획 + PRD + 세부계획 + MVP 착수
할 일
- “에이전트”·“API”·“구글시트 연동”이 뭔지 쉬운 말로 이해하기 (2개씩 천천히) ✅
- 공공데이터포털 회원가입 + API 인증키 발급 실습 (무료) ✅
- 구글 계정으로 구글시트 만들어보기, 클로드와 연결해보기 (커넥터 개념 첫 체험) ✅
- ○○ 솔루션에 맞는 잠재고객 조건 구체화 (어떤 업종·직원수·매출 규모가 유력한지 목록화) ✅
- 채울 항목별로 “어느 API에서 가져오는지” 표로 정리 (회사명·직원수·매출·주소 → 공공데이터 / 담당자 연락처 → 보류) ✅
src/content/projects/에 이 프로젝트 PRD·세부계획 작성 ✅- 이 로드맵 완성 ✅
- 클로드 코드로 스크립트/에이전트 만들기 시작 (터미널과 친해지기부터) → 공공데이터로 프로필에 맞는 회사 1개를 찾아 → 구글시트 한 줄 채우기, MVP 첫 성공까지 ✅
이 주 결과물: 로드맵·PRD·데이터 출처 표 완성 + 회사 1개 정보가 자동으로 구글시트 한 줄에 채워지는 MVP 첫 성공 사례글 예시: “Day1 — 처음으로 API 키를 발급받았다”, “Day3 — 클로드가 내 구글시트에 처음 글자를 써줬다”, “Day5 — 어떤 회사가 우리 솔루션의 잠재고객인지 기준을 정했다”, “Day7 — 내 에이전트가 처음으로 회사 정보를 시트에 채웠다”
2주차 (7/30~8/5) — MVP 본격 제작
할 일
- 공공데이터 1차 리스트업을, 여러 회사(5~10개)로 확장해 반복 자동화 (실행할 때마다 “몇 개 더 찾을까요?” 물어보고, 중복 방지) ✅
- 후보 회사의 홈페이지·뉴스를 검색해 정보를 검증·보강하는 단계 추가 (제일 어려운 핵심 부분) ✅
- 필요한 API 필드 보완 (직원수·매출·업종·주소 등) ✅
- 배운 개념은 위키에 쌓기 (
개념정리스킬)
이 주 결과물: 여러 회사를 자동으로 찾아 정보를 채우는 MVP(공공데이터+홈페이지+뉴스) 사례글 예시: “Day10 — 5개 회사를 한 번에 처리해봤다”, “Day12 — 홈페이지·뉴스로 정보를 검증·보강했다”
3주차 (8/6~8/12) — ICP 판별 로직 강화 + 대량 스케일 자동화 (2026-08-04 개정)
2주차까지 만든 MVP로 실제 15개 회사를 채워보니, (1) 업종만 느슨하게 매칭해서 안 맞는 회사가 섞이고 (2) 채팅으로 회사 하나씩 부르는 구조라 수백~수만 개로 확장이 안 된다는 두 가지 근본 문제를 발견했다. 이번 주는 이 두 가지를 정면으로 고치는 데 집중한다. (자세한 Day별 계획은 → PRD·세부계획 페이지)
할 일
- 제품(○○ 솔루션)에 대한 이해를 체이스·콩콩 둘 다 더 깊이 쌓기 — 특히 “직접 쓰는 고객”과 “이 제품으로 뭔가 만들어 파는 인티그레이터/파트너”를 구분
- 업종코드(KSIC) 기반으로 프로필별 “포함/제외” 판별 규칙 명확히 세우기
- 업종코드만으론 못 거르는 애매한 케이스를 거르는 2차 체크리스트(자체 설계·R&D·생산라인 보유 여부) 만들기
- 채팅 개입 없이 수백~수천 개 후보를 자동으로 걸러내는 배치 스크립트 만들기
- 대량 필터(저비용) → 상위 후보만 정밀검증(고비용)으로 이어지는 2단계 파이프라인 연결
- 100개 규모로 실제 돌려보고, 사람 개입이 얼마나 줄었는지 확인
이 주 결과물: 더 정확해진 ICP 판별 로직 + 수백 개 규모까지 사람 개입 없이 돌아가는 리드 스크리닝 파이프라인 사례글 예시: “Day10 — 제품을 다시 공부하다가 큰 오해를 발견했다”, “Day13 — 회사 500개를 한 번에 걸러내는 스크립트를 만들었다”, “Day15 — 100개 회사를 사람 개입 없이 돌려봤다”
4주차 (8/13~8/17) — 회고·발표 (완성하고 보여주기)
할 일
- 완성된 에이전트로 실제 후보 회사 목록 데모 시연
- 발표 자료는 클로드 디자인으로 제작 (책 8장 참고 가능)
- 한 달 회고 + 전자책 마무리
이 주 결과물: 데모 시연 + 발표 자료 + 한 달 회고 사례글 예시: “Day28 — 발표 자료를 준비했다”, “Day30 — 내 첫 B2B 에이전트를 발표했다”
다음 목표 (이번 챌린지 이후)
- 담당자 개인 연락처까지 채우려면 회사 홈페이지 자동 탐색이나 세일즈 데이터 도구(Apollo·ZoomInfo·Clay 등) 연동이 필요함.
이건 이번 4주 이후 고도화 과제로.
발표 완성 기준 — 여기까지 되면 끝
완성 기준 (한 문장)
발표에서 “시트에 회사 30곳이 이렇게 채워졌고, 이 2곳은 이런 이유로 걸러냈다”를 화면으로 보여주며 5분 안에 설명할 수 있으면 완성.
이 한 문장 안에 세 가지가 다 들어간다 — 결과물(회사 30곳), 판별력(걸러낸 근거), 증거(화면). 이걸 넘어서는 건 전부 보너스다.
왜 기준을 못 박았나
로드맵 4주차에 적어둔 할 일은 “데모 시연 + 발표 자료 + 한 달 회고 + 전자책 마무리”였다. 그런데 남은 시간이 24시간, 실제 작업 가능한 건 반나절 정도다. 전부 하려다 전부 얕아지는 것보다, 뭘 안 할지 먼저 정하는 게 낫다고 판단했다.
꼭 필요한 것 — 이것만 되면 완성
| # | 할 일 | 왜 꼭 필요한가 |
|---|---|---|
| 1 | 발표 자료 본체 | 줄거리는 이미 다 나와 있다. 왜 만들었나(회사 1곳당 1,500원) → 뭘 만들었나(시트 30곳) → 어떻게 정확해졌나(딜러사 2곳·화학회사 4곳 제거) → 뭘 배웠나. 새로 만드는 게 아니라 있는 걸 골라 담는 일이다 |
| 2 | 데모 증거 — 미리 찍어둔 것으로 | 시트 현황 스크립트 실행 화면 + 시트 실물 캡처. 발표장에서 API를 실시간으로 부르지 않는다 |
| 3 | 실패 슬라이드 1장 | 덮어쓰기 사고 · 도메인 탈취 · 세션 사망. 이 발표에서 제일 강한 부분이라 빼면 안 된다 |
라이브 시연을 안 하는 이유
8월 6일에 공공데이터 API가 실제로 막혀본 적이 있다. 원인(순간 속도)은 찾아서 고쳤지만, 그 리스크를 발표 당일에 질 이유가 없다. 미리 찍은 화면은 라이브만큼 설득력이 있으면서 실패하지 않는다.
있으면 좋지만 없어도 되는 것
- 주간 회고(3주차 회고) — 발표 자료를 만들면 재료가 저절로 나온다. 발표 뒤 30분이면 쓴다 (→ 발표 전날에 먼저 씀)
- 4주차 학습일지·사례글 — 기록의 연속성 차원. 발표 뒤로
- PRD 세부계획의 Day 12 완료 표시 — 30초짜리. 발표 자료 만들면서 겸사겸사
이번엔 빼는 게 나은 것
| 뺀 것 | 이유 |
|---|---|
| 전자책 마무리 | 반나절짜리 일이 아니다. 발표를 얕게 만들면서까지 손댈 건 아니다 |
| 한 달 회고를 별도 문서로 | 발표 자료의 마지막 챕터가 곧 회고다. 같은 걸 두 번 쓰지 않는다 |
| 회사 추가 조사·프로필 보강 | 30곳이면 발표에 충분하다. 지금 새 회사를 넣으면 검증 안 된 데이터가 발표장에 올라간다 |
| 라이브 API 시연 | 위 참고 |
이 판단에서 배운 것
마감이 가까울수록 “다 하고 싶은 마음”이 생기는데, 그때 필요한 건 더 열심히 하는 게 아니라 완성의 선을 한 문장으로 그어두는 것이었다. 선을 그으니 남은 반나절에 뭘 해야 할지가 바로 정해졌다.
그리고 자를 때 기준이 하나 있었다 — “이걸 빼면 완성 기준 문장이 무너지나?” 무너지면 필수, 안 무너지면 보너스. 전자책도, 추가 조사도 저 문장을 무너뜨리지 않았다.
1주차
Day 1 — "파일에 저장했어요"라는데 못 찾아서 헤맸던 이야기
누구에게 도움: “AI가 파일을 만들어줬다는데 어디 있는지 못 찾겠다” 하는 비개발자 초보.
Before
AI(콩콩)가 “로드맵을 00-roadmap.md에 저장했어요”라고 하면서 채팅 안에 파란 글씨 링크까지 줬다. 당연히 클릭하면 열릴 줄 알았는데, 눌러도 아무 일도 안 일어났다. 컴퓨터 어디에도 그런 파일이 안 보이는 것 같아서 “진짜 만들어지긴 한 건가?” 싶었다.
막힘 → 해결
콩콩한테 그대로 이야기했더니, 바로 이렇게 정리해줬다.
“채팅에서 제가 준 링크는 대화 안에서의 표시일 뿐, 체이스 컴퓨터에서 더블클릭해서 열리는 진짜 링크가 아니에요.”
그러면서 두 가지 방법을 알려줬다.
- 제일 쉬운 방법: 로컬 미리보기 화면(웹사이트)에서 “학습위키” 메뉴 → 원하는 글 카드 클릭. 예쁘게 정리된 글로 바로 보인다.
- 파일 자체를 보고 싶을 때: Finder에서
문서(Documents) → my-learning-hub → src → content → wiki순서로 들어가면 실제로 파일이 있다.
새로 안 개념 (2개까지만)
- 마크다운(.md): 텍스트 편집기로 열면
#,**같은 기호가 그대로 보이는 파일 형식. 이 기호들을 사이트가 알아서 제목·굵은 글씨 등 예쁜 모양으로 바꿔서 보여주는 것. - 채팅 속 링크 ≠ 내 컴퓨터 링크: AI 채팅창에 뜨는 파일 경로 표시는 대화 내용 설명일 뿐, 실제로 그 파일을 여는 버튼이 아닐 수 있다.
After
이제는 “파일 만들었어요”라는 말을 들으면, 파일을 직접 찾으려 하지 않고 웹사이트 화면에서 먼저 확인한다. 훨씬 마음이 편해졌다.
배운 것 / 재사용 자산
- 뭔가 저장됐다는데 안 보이면 당황하지 말고, “그거 어디서 보는 거예요?”라고 바로 물어보면 됨.
- 앞으로 파일 위치를 물을 땐 “웹사이트 어디 메뉴” 기준으로 먼저 물어보기 (Finder 경로는 그다음).
Day 1 — 학습메이트 콩콩을 만들고, 책 목차로 4주 로드맵을 짰다
누구에게 도움: 코딩을 모르고, “무엇부터 해야 할지” 막막한 챌린지 1일차 사람.
Before
챌린지를 시작하긴 했는데, 4주 동안 뭘 어떤 순서로 할지 하나도 안 잡혀 있었다. 이미 사둔 책(「바로바로 클로드」)은 있는데, 그걸 챌린지 일정에 어떻게 끼워 맞출지 감이 안 왔다.
어떻게 했나
1) 학습메이트부터 만들기
AI한테 성격·말투·규칙을 미리 정해두면 매번 설명 안 해도 된다길래, 인터뷰 형식으로 3개만 답했다.
- 이름 후보를 받아서 **“콩콩”**으로 정함 (마음에 드는 후보가 없어서 직접 이름을 지어줌)
- 나를 부를 호칭: “체이스”
- 나에 대한 소개: “한량. AI를 챗봇 이상으로 다양하게 쓰고 싶고, 클로드 대부분 기능을 이해하는 사람이 되고 싶다”
이 답들이 SOUL.md(성격) · USER.md(나에 대해) 파일로 저장됐다.
2) 로드맵은 “만들어줘” 한 줄로 끝내지 않음
처음엔 그냥 “로드맵 만들어줘” 하려다가, AI가 먼저 하나씩 물어봤다.
“뭘 배우거나 만들고 싶어?” → “왜 하고 싶어?” → “4주 뒤 최종 결과물은?” → “지금 나는 뭘 할 수 있고 뭐가 막막해?”
이렇게 답하다 보니, 막연했던 “AI 잘 쓰고 싶다”가 **“학습허브 사이트를 완성해서 배포한다”**는 구체적인 목표로 좁혀졌다.
3) 책 목차를 짐작하지 않고 실제로 찾아봄
내가 산 책 링크(yes24)를 주니, AI가 “짐작으로 목차를 지어내지 않겠다”며 실제로 웹에서 책 목차를 찾아 확인했다. 8개 장(처음 만나는 클로드 → 문서작업 → 아티팩트 → 커넥터 → 스킬 → 코워크 → 클로드 코드 → 클로드 디자인)을 챌린지의 4주 틀(기획→상세계획→제작→회고)에 맞춰 배치해줬다.
막힘 → 해결
로드맵을 “파일에 저장했다”는 말을 들었는데, 정작 그 파일을 내 컴퓨터에서 찾을 수가 없었다. 채팅에 있던 링크가 실제로 열리는 링크가 아니라, 그냥 대화 속 표시였다는 걸 나중에야 알았다. → 해결법은 뒤에 따로 사례글로 남긴다.
After
- 나만의 AI 학습메이트(콩콩)가 생김
- 책 8개 장이 실제로 반영된, 내 것 같은 4주 로드맵 완성
- 그 로드맵 내용 그대로 랜딩페이지 소개글도 채움
- 로컬 미리보기까지 띄워서 실제 화면으로 확인함
배운 것 / 재사용 자산
- 로드맵 인터뷰 순서 (그대로 써도 됨): 뭘 배우고 싶은지 → 왜 → 누구를 위해 → 4주 뒤 결과물 → 지금 나 vs 되고 싶은 나
- “만들어줘” 한 줄보다, AI가 되물어보게 하는 게 더 “내 것” 같은 결과물이 나온다는 것.
- 정확도가 중요한 정보(책 목차 같은 것)는 AI가 짐작하지 않고 실제로 찾아보게 하는 게 낫다는 것.
Day 3 — 내 사이트를 처음 실제로 배포했다 (GitHub + Vercel)
누구에게 도움: 코딩을 모르고, “배포”가 뭔지 막막한 사람.
Before
사이트는 내 컴퓨터 안(로컬 미리보기)에서만 보였다. 나만 볼 수 있는 상태. “배포”라는 말이 막연하게 어렵게 느껴졌다.
어떻게 했나 (그대로 따라 할 수 있는 순서)
1) 계정부터 만들기
AI가 계정을 대신 만들어줄 순 없어서(이메일·비밀번호는 본인이 입력해야 함), 순서만 안내받아 직접 만들었다.
- GitHub 가입 (github.com → Sign up → 이메일·비밀번호·아이디 → 이메일 인증)
- Vercel 가입 (vercel.com → Sign Up → “Continue with GitHub” 선택 → 그대로 로그인)
2) 필요한 도구가 있는지 먼저 확인
설치가 필요한 줄 알았는데, 확인해보니 Git·GitHub CLI·Node.js가 이미 다 깔려 있었다. (다행히 설치 단계는 건너뜀)
3) 코드를 GitHub에 올리기
아래 명령어로 진행했다 (전부 콩콩이 실행).
git init
git add -A
git commit -m "학습허브 사이트 첫 커밋"
gh repo create my-learning-hub --public --source=. --remote=origin --push
4) Vercel에서 연결하고 배포
Vercel 대시보드에서 “Add New → Project” → GitHub 저장소 목록에서 my-learning-hub 선택 → “Import” → 그대로 “Deploy” 클릭. 1~2분 기다리니 실제 주소가 생겼다.
결과 주소: https://my-learning-hub-mu.vercel.app/
막힘 → 해결
프로젝트 링크를 나중에 한 번 더 업데이트해서 GitHub에 다시 올리려는데, git push가 이런 오류를 냈다.
fatal: could not read Username for 'https://github.com': Device not configured
콩콩이 gh auth setup-git 명령어로 깃 인증을 다시 연결해주니 바로 해결됐다.
After
컴퓨터 안에서만 보이던 사이트가, 이제 누구나 접속할 수 있는 진짜 주소를 갖게 됐다. 로드맵상 원래 4주차에나 할 목표였는데, 1주차에 먼저 해낸 셈이다.
배운 것 / 재사용 자산
- GitHub = 코드 저장하는 곳, Vercel = 그 코드를 웹사이트로 띄워주는 곳. 이 둘을 “Continue with GitHub”으로 연결하면 계정 두 개를 따로 관리 안 해도 됨.
- 재현 체크리스트: ① GitHub·Vercel 가입 ② Git/GitHub CLI 설치 확인 ③
git init→add→commit④gh repo create ... --push⑤ Vercel에서 Import → Deploy. - 이후에 코드를 고칠 때마다
git add -A && git commit -m "..." && git push만 하면, Vercel이 알아서 재배포해준다.
Day 3 — 로드맵을 통째로 갈아엎었다: 책 대신 진짜 하고 싶은 일로
누구에게 도움: 로드맵을 이미 짰는데 뭔가 내 것 같지 않다고 느끼는 사람.
Before
책 목차를 따라가는 로드맵이 이미 있었다. 나름 꼼꼼하게 짰지만, 계속 보다 보니 “이게 진짜 내가 하고 싶은 일인가?” 싶었다. 평소 회사에서 진짜 아쉬웠던 문제(잠재고객 조사에 매번 큰돈과 시간이 든다는 것)는 로드맵 어디에도 없었다.
어떻게 했나
1) 그냥 지워달라고 했다
“4주 로드맵을 새로 만들고 싶어. 기존에 만든 것은 삭제해 줘.”
콩콩이 바로 삭제하기 전에 “지난번 로드맵에서 아쉬웠던 부분이 있어서인지, 완전히 다른 방향으로 새로 하고 싶은 건지” 물어봤다. 완전히 다른 방향이라고 답했다.
2) 이번엔 진짜 문제를 그대로 던졌다
막연하게 말하지 않고, 지금 회사에서 겪는 문제를 구체적으로 풀어서 이야기했다.
“영업 기회 발굴을 하기 위해서 한국에 있는 잠재 고객(회사) 정보를 얻기 위해… 마케팅 에이전시에게 프로젝트 당 수천만원을 지급하며 outsourcing을 주었습니다.”
이 한 문단이 로드맵 전체의 뼈대가 됐다.
3) 짐작 대신 실제로 찾아보게 했다
콩콩이 “한국 공공데이터로 가능한지 짐작하지 않고 실제로 확인하겠다”며 검색을 했고, 실제로 존재하는 API 3~4개(공공데이터포털 기업기본정보·재무정보, 국세청 사업자상태, OpenDART)를 찾아서 로드맵에 반영했다.
막힘 → 해결
로드맵은 스터디원과 공유되는데, 실제 회사·솔루션 이름이 그대로 들어가 있었다. **“어느 회사 어느 제품인지는 hidden 처리해달라”**고 하니, 콩콩이 문서에는 “○○회사·○○ 솔루션”으로만 남기고, 진짜 이름은 파일이 아니라 AI의 별도 기억 저장소에만 남겨서 나(체이스)와 콩콩만 알 수 있게 처리했다. 나중에 GitHub에 올려도 새어나갈 걱정이 없어졌다.
After
- “책을 다 읽어야 하는” 로드맵 → “내 진짜 문제를 푸는” 로드맵으로 바뀜
- 4주 뒤 결과물이 “이해했다”가 아니라 **“회사 정보를 자동으로 채워주는 에이전트를 만들었다”**로 훨씬 구체적이 됨
- 나중엔 리스트에서 회사 하나를 고르면 콜드 이메일 초안까지 써주는 기능도 자연스럽게 추가함
배운 것 / 재사용 자산
- 로드맵이 뭔가 어색하면, “왜 어색한지” 고민하지 말고 그냥 **“완전히 다른 방향으로 다시 만들고 싶다”**고 솔직히 말하면 됨.
- 막연한 목표보다 **“지금 진짜 겪고 있는 구체적인 문제”**를 그대로 이야기하는 게 훨씬 좋은 재료가 됨.
- 민감한 정보(회사명 등)가 있는 프로젝트는, 문서엔 마스킹 처리하고 AI 기억에만 남기는 방법이 있다는 것.
Day 4 — 실명 유출을 막는 문지기를 직접 만들었다
누구에게 도움: 스터디·회사 등 남과 공유되는 문서에 민감한 이름을 마스킹 처리해야 하는 사람.
Before
로드맵에 실제 회사·제품명이 들어가 있어서, 문서엔 “○○회사”로 마스킹 처리해뒀다. 그런데 매번 커밋하기 전에 “혹시 실명이 어딘가 남아있진 않을까” 하고 손으로 grep을 돌려 확인해야 했다. 사람이 깜빡하면 그대로 새어나갈 수 있는 구조였다.
어떻게 했나
콩콩한테 반복 작업 자동화를 추천받고, 그중 “실명 유출 자동 검사”를 골랐다.
“1. 민감정보(마스킹) 유출 자동 검사를 미리 해 보자.”
콩콩이 만든 건 .git/hooks/pre-commit이라는 파일이었다. 커밋하기 직전에 자동으로 실행돼서, 실명이 껴 있으면 커밋 자체를 막아버리는 스크립트였다.
if git diff --cached | grep -qiE "(마스킹 대상 실명)"; then
echo "🚫 커밋 중단: 실명이 포함되어 있어요!"
exit 1
fi
(실제로는 진짜 회사·제품명이 들어갔지만, 이 글에서는 가려서 옮겼다.)
막힘 → 해결(아하 포인트)
“이 파일에 실명을 적어도 되나?” 싶었는데, .git/hooks/ 폴더는 GitHub에 절대 올라가지 않는 로컬 전용 폴더라는 걸 알게 됐다. 그래서 이 안에는 실명을 그대로 적어놔도 안전했다 — 오히려 이 파일이 실명을 지키는 “금고” 역할을 하는 셈이었다.
테스트로 확인
- 일부러 실명이 든 가짜 파일을 만들어 커밋 시도 → 🚫 차단됨
- 정상적인(마스킹된) 파일을 커밋 → ✅ 통과되고 GitHub까지 반영됨
두 가지 경우를 다 눈으로 확인하고 나서야 안심이 됐다.
After
이제는 커밋할 때마다 손으로 확인 안 해도 된다. 콩콩이 실수해도, 심지어 터미널에서 내가 직접 커밋해도 무조건 걸러진다. “사람이 기억해서 지키는 규칙”보다 “도구가 기계적으로 막는 장치”가 훨씬 안전하다는 걸 몸으로 느꼈다.
배운 것 / 재사용 자산
- 민감정보처럼 절대 어기면 안 되는 것은 AI 규칙보다 Git hook 같은 기계적 장치로 만드는 게 안전하다.
.git/hooks/폴더는 로컬 전용이라 GitHub에 안 올라간다 — 여기엔 민감한 값을 적어도 괜찮다.- 자동화 만들고 나면, “막히는 경우”와 “통과하는 경우” 둘 다 테스트해봐야 진짜 확인이 된다.
Day 4 — 반복되는 저장 작업을 나만의 스킬로 자동화했다
누구에게 도움: Claude Code의 스킬·규칙·서브에이전트 차이가 헷갈리는 사람.
Before
작업이 끝날 때마다 “커밋해줘”라고 말하면, 콩콩이 상태 확인 → 커밋 메시지 짓기 → 푸시 → 화면 확인까지 매번 손으로 해줬다. 편하긴 했지만, 매번 순서를 새로 설명하는 느낌이었다.
어떻게 했나
1) 뭘 자동화할지부터 추천받기
“지금까지 나랑 작업하면서, 내가 자주 반복한 작업이 뭐가 있었어? 자동화하면 편해질 만한 걸 추천해줘. 스킬로 만들 만한 것으로만.”
콩콩이 반복 패턴 3개를 뽑아줬고, 그중 “저장 마무리” 하나를 골랐다.
2) 스킬이 맞는지부터 확인
바로 만들지 않고 먼저 물었다.
“이건 스킬로 만드는 게 맞아, 아니면 CLAUDE.md 규칙이나 서브에이전트가 나아?”
콩콩의 설명을 정리하면 이랬다.
| 특징 | |
|---|---|
| CLAUDE.md/AGENTS.md 규칙 | 항상 지키려는 원칙. 여러 단계 절차엔 안 맞음 |
| 스킬 | 정해진 말로 실행되는 여러 단계 절차. 판단이 필요한 반복 작업에 맞음 |
| 서브에이전트 | 독립적이고 무거운 일을 따로 맡기는 것. 지금 대화 맥락이 필요한 가벼운 일엔 안 맞음 |
“저장 마무리”는 여러 단계 + 판단(커밋 메시지 짓기)이 필요하고 가벼워서 스킬이 맞다는 결론이 나왔다.
3) 실제로 스킬 파일 만들기
.claude/skills/마무리저장/SKILL.md에 5단계(상태 확인 → 메시지 짓기 → 커밋+푸시 → 화면 확인 → 보고)를 정리해서 저장했다.
테스트로 확인
- 바뀐 내용이 있을 때 실행 → 알아서 메시지 짓고 커밋·푸시까지 성공
- 바뀐 내용이 없을 때 실행 → 억지로 만들지 않고 “저장할 게 없다”고 솔직히 알림
두 상황 다 의도대로 작동했다.
After
이제 “오늘 작업 마무리해줘” 한마디면 끝난다. 매번 순서를 설명 안 해도 되고, 콩콩이 뭘 확인해야 하는지도 스스로 판단한다.
배운 것 / 재사용 자산
- 자동화하고 싶은 게 생기면, 바로 만들지 말고 “이게 규칙에 맞는지 스킬에 맞는지 서브에이전트에 맞는지”부터 물어보면 훨씬 적절하게 만들어진다.
- 판단 기준 요약: 절대 어기면 안 되는 것 → 기계적 장치(Git hook 등), 여러 단계+판단이 필요한 반복 작업 → 스킬, 크고 독립적인 일 → 서브에이전트, 항상 지킬 원칙 → CLAUDE.md/AGENTS.md 규칙.
- 스킬을 만들고 나면, “바뀐 게 있을 때”와 “없을 때” 둘 다 실행해봐야 제대로 확인된다.
오늘의 일탈 — Hermes AI Agent로 구글 슬라이드 자동 생성 성공기
누구에게 도움: 정해진 커리큘럼 말고, 다른 AI 도구도 궁금해서 잠깐 곁길로 새보고 싶은 사람.
Before
원래 오늘은 정해진 학습 계획(공공데이터 API·구글시트 연동)에 없던 날이었다. 그런데 문득 “Hermes AI Agent”라는 도구로 Google Workspace 연동을 해보고 싶어졌다.
어떻게 했나
Hermes AI Agent에서 Google Workspace 연동을 시도했다. 생각보다 단계가 많고 중간에 여러 번 막혔다 — 정확히 뭐가 문제였는지는 기록해두지 않았지만, 시행착오를 여러 번 거쳤다.
우여곡절 끝에 연동이 성공했고, 테스트 삼아 이렇게 시켜봤다.
“구글 슬라이드 한 장 만들어줘.”
결과: 실제로 슬라이드 한 장이 자동으로 만들어졌다.
막힘 → 해결
연동 과정 자체가 막힘의 연속이었다. 구체적인 에러나 해결 과정을 그때그때 기록해두지 못한 게 아쉬운 점 — 다음에 비슷한 걸 시도할 땐, 막히는 순간마다 스크린샷이나 메모를 남겨두면 나중에 훨씬 더 진하게 사례글을 쓸 수 있을 것 같다.
After
여러 단계와 시행착오 끝에 테스트 슬라이드 한 장이 완성된 걸 보고, 앞으로 슬라이드 작성 방식 자체에 큰 변화가 올 거라는 확신이 들었다. 파워업 된 기분!
배운 것 / 재사용 자산
- 정해진 커리큘럼 밖으로 잠깐 곁길로 새는 것도, 그 자체로 좋은 기록거리가 된다.
- 새 도구를 처음 연동할 땐 시행착오가 당연하다 — 막힐 때마다 바로바로 메모해두면 나중에 더 좋은 사례글이 된다.
- “AI가 슬라이드 초안을 대신 만들어주는” 경험은, 앞으로 발표 자료 준비 방식에 참고할 만한 힌트가 됐다.
1주차 회고 — 방향 없이 시작해서, B2B 리드젠 에이전트까지
한 줄 요약
목표 없이 “클로드 익히기”로 시작했다가, 토요일 오프모임에서 B2B 리드젠 에이전트라는 구체적 결과물로 방향을 튼 뒤, 배포 → 자동화 → PRD까지 8일 만에 이어졌다.
누구에게 도움될까: AI 툴을 손에 쥐긴 했는데 “그래서 뭘 만들지” 막막한 사람, 그리고 개념부터 다 이해하고 시작해야 할 것 같아 망설이는 사람.
Day 1 — 방향 없이, 일단 만들어보기
시작은 막연했다. “클로드 코드를 익히자”는 목표로 학습메이트 “콩콩”을 만들고(SOUL·USER·AGENTS·CLAUDE 4개 파일), 「바로바로 클로드」 책 목차를 따라 4주 로드맵부터 짰다.
첫 시행착오도 이날 나왔다. 콩콩이 “파일에 저장했어요”라며 채팅에 링크를 줬는데, 내 컴퓨터에서 그 링크가 열리지 않았다. 채팅 속 링크는 대화 안에서만 보이는 표시일 뿐, 실제 파일은 Documents → my-learning-hub → src → content → wiki 안에 따로 있다는 걸 그제서야 알았다. 마크다운(.md)이 뭔지도 이때 처음 배웠다.
(여기에 처음 만든 4주 로드맵 화면 스크린샷을 넣으면 좋아요)
Day 3 — 오프모임 한 번이 로드맵을 통째로 바꿨다
토요일 오프모임에서, “책 목차를 따라가기”보다 “실제로 쓸 결과물을 만들자”는 쪽으로 생각이 바뀌었다. 그렇게 로드맵을 B2B 잠재고객 발굴(리드젠) 에이전트로 전면 재작성했다.
같은 날 GitHub·Vercel 계정을 만들고(이 부분은 AI가 대신 못 해줘서 직접 진행), 사이트를 처음으로 실제 배포했다. Before는 로컬 미리보기(npm run dev)로만 보던 사이트, After는 진짜 인터넷 주소(my-learning-hub-mu.vercel.app)가 생긴 것.
(여기에 배포 성공 후 Vercel 화면 스크린샷을 넣으면 좋아요)
Day 4 — 자동화를 두 개 만든 날
이날은 “반복”에 대해 배웠다. 먼저 커밋과 되돌리기(git restore)를 직접 망가뜨렸다 되돌리며 몸으로 익혔다. 그다음 두 가지를 자동화했다:
- 실명 유출 방지 “문지기” — Git pre-commit hook으로, 실명이 들어간 커밋은 자동으로 막히게 만듦. 일부러 실명을 넣은 테스트 커밋이 막히는 것과 정상 커밋이 통과되는 것 둘 다 확인.
- “마무리저장” 스킬 — 매번 반복하던 “오늘 작업 저장 마무리” 루틴을 스킬로 만들어, 이후엔 “오늘 작업 마무리해줘” 한마디로 끝나게 만듦.
재사용 자산:
.git/hooks/pre-commit에 실명 패턴 검사 넣기 + 반복 루틴은 스킬로 뽑아두기. 매일 쓰는 명령을 “규칙(기억)“이 아니라 “장치(기계적 검사)“로 만들면 절대 안 지켜지면 안 되는 것에 더 안전하다는 걸 배웠다.
Day 5 — 계획에 없던 일탈, Hermes AI
원래 로드맵엔 없었지만, Hermes AI Agent에 Google Workspace를 연동해서 구글 슬라이드 자동 생성을 테스트해봤다. 연동 과정에 시행착오가 좀 있었지만, 결국 슬라이드 한 장이 자동으로 완성되는 걸 보고 “슬라이드 작성 방식에 혁신이 온다”는 확신이 들었다.
Day 8 — 로드맵을 진짜로 만들 수 있는 PRD로
로드맵만으론 “그래서 정확히 뭘 만들지”가 여전히 막연했다. 그래서 콩콩에게 예시를 보여주며 하나씩 물어봐달라고 요청해, 인터뷰 방식으로 PRD를 완성했다. 콩콩이 웹서치로 최신 구현 방법을 조사해준 걸 참고해 기술 선택도 같이 결정했다.
인터뷰 중간에 방향이 한 번 더 바뀌었다 — “회사명을 입력받는 게 아니라 에이전트가 스스로 잠재고객을 찾아야 한다”는 걸 깨달은 것. 콜드 이메일 작성이 화려해 보이지만, 진짜 어려운 핵심은 잠재고객 프로필을 세우고 회사 정보를 검증·보강하는 쪽이라는 것도 이때 명확해졌다.
이 PRD 인터뷰 과정 자체도 “PRD” 스킬로 남겨서, 다음에도 같은 방식으로 재사용할 수 있게 만들었다.
그 여세로 PRD의 2주 세부계획 중 Day 1(구글시트 MCP 연결)을 바로 실행해봤다. 리드젠 테스트 시트 A1에 ‘연결 성공’을 써보려 했는데, 읽기·쓰기 모두 권한 에러가 나서 막혔다. 예전에 Hermes AI로는 비슷한 구글 연동이 잘 됐던 경험이 있어서, “같은 작업인데 도구마다 연결 방식이 다르구나”를 체감한 채로 다음 주 과제로 넘겼다.
(여기에 완성된 PRD 페이지 화면 스크린샷을 넣으면 좋아요)
이번 주를 돌아보며
처음엔 공부 방향성도 못 잡고 클로드를 익히는 것 자체를 목표로 잡았다가, 오프모임에서 특정 결과물(B2B 리드젠)로 구체적으로 수정한 게 잘한 선택이었다고 생각한다. 목표를 가지고 클로드에게 물어가며 그 목표를 구체화해나가는 과정을 직접 해보니, **“AI를 몰라도, AI에게 질문하면서 만들다 보면 툴과 저절로 익숙해진다”**는 게 놀랍고 흥미로웠다. 개념 이해가 아직 부족해도, 부족한 채로 일단 실행하며 나아가는 쪽을 우선하는 게 맞다는 걸 몸으로 알게 됐다.
막힌 것도 솔직히: 구글시트 연결은 아직 미해결이다. 원인도 모르고, 오늘 안에 풀지도 못했다. 그런데 이번 주를 지나며 알게 된 건, 막힌 채로 넘기는 것도 괜찮다는 것 — 계속 질문하며 풀어가면 된다.
다음 주엔
구체화된 PRD의 2주 세부계획을 따라, 하나씩 진도를 이어간다.
2주차
개념 — 구글시트에 클로드를 연결할 때 나오는 인증 용어들
세부계획 Day 1(구글시트에 클로드 연결하기) 튜토리얼을 만들다 보니, 처음 보는 인증 관련 용어가 많이 나왔다. 하나씩 정리해둔다.
구글 클라우드 쪽 용어
구글 클라우드 콘솔은 구글의 여러 개발자 도구를 관리하는 “뒷단 관리 화면”이다. 평소 쓰는 구글시트·지메일 같은 일반 서비스 화면과는 다르다 — “이 앱이 내 구글 계정에서 이런 걸 할 수 있게 허락한다”를 설정하는 곳이라고 생각하면 된다.
그 안에서 프로젝트를 하나 만드는데, 이건 “이 앱을 위한 설정들을 담는 바구니 하나”라고 보면 된다. 앱(또는 용도)마다 바구니를 새로 하나씩 만든다.
API 활성화는 구글의 특정 기능(예: 시트를 읽고 쓰는 기능)을 “이 프로젝트에서 쓸 수 있게 스위치 켜기”다. 기본적으로 꺼져 있어서, 쓰려는 기능마다 하나씩 켜야 한다.
인증(내 계정 접근을 허락하는) 용어
여기서부터가 낯선 용어의 대부분이다. 비유를 하나 들면 이해가 쉽다 — 발렛파킹을 생각해보자. 주차 요원한테 내 차 전체 열쇠(=구글 계정 비밀번호)를 통째로 주는 게 아니라, **주차만 할 수 있는 제한된 열쇠(발렛 키)**를 만들어서 준다. OAuth 관련 용어들은 전부 이 “제한된 열쇠 만들기” 과정에 나오는 것들이다.
- OAuth: 내 비밀번호를 직접 넘기지 않고도, 앱한테 “내 계정의 일부분만” 접근을 허락해주는 표준 방식. 발렛 키를 만드는 방법 그 자체.
- 동의 화면: “이 앱이 당신 계정에서 이런 걸 할 수 있어요. 허락하시겠어요?”라고 보여주고, 내가 “허용”을 눌러야 하는 화면. 앱 설치할 때 “카메라 접근을 허용하시겠습니까?” 뜨는 것과 같은 개념이다.
- 스코프(접근 범위): 발렛 키로 정확히 어디까지 되는지 정하는 것. “주차는 되지만 트렁크는 못 연다”처럼, “시트는 되지만 지메일은 안 된다”는 식으로 범위를 딱 정해둔다.
- 클라이언트 ID / 클라이언트 보안 비밀: 이 앱이 진짜 등록된 그 앱이 맞는지 구글한테 증명하는 신분증(ID)과 비밀번호(보안 비밀) 세트. ID는 남한테 보여도 되지만, 보안 비밀은 비밀번호처럼 아무 데도 붙여넣으면 안 된다.
- 리디렉션 URI: 구글에서 로그인·허용을 끝낸 뒤 “이 주소로 다시 돌아가라”고 미리 등록해두는 주소. 아무 주소로나 돌아가게 하면 위험해서, 미리 정해진 곳으로만 돌아가게 하는 안전장치다.
앱 공개 범위 관련 용어
구글 클라우드에 앱을 등록할 때, “이 앱을 누가 쓸 수 있게 할지”도 정해야 한다.
- Internal / External: 내부(Internal)는 회사(구글 워크스페이스) 안에서만, 외부(External)는 아무나 쓸 수 있게 하는 설정. 개인이 혼자 쓰는 프로젝트는 보통 외부로 만든다.
- 테스트 사용자: 앱이 아직 구글 심사를 안 받은 상태라면, “이 이메일들만 미리 써볼 수 있다”고 등록해두는 명단. 개인 프로젝트는 내 이메일 하나만 등록해두면 된다.
개념 요약 표
| 용어 | 쉬운 뜻 |
|---|---|
| 구글 클라우드 콘솔 | 구글 개발자 도구를 관리하는 뒷단 관리 화면 |
| 프로젝트(구글 클라우드) | 앱 설정들을 담는 바구니 하나 |
| API 활성화 | 구글의 특정 기능을 이 프로젝트에서 쓸 수 있게 스위치 켜기 |
| OAuth | 비밀번호를 직접 안 넘기고, 앱한테 계정 일부만 접근을 허락하는 방식 |
| 동의 화면 | ”이 앱이 이런 걸 할 수 있어요, 허락할까요?” 확인창 |
| 스코프(접근 범위) | 앱이 정확히 어디까지 할 수 있는지 정하는 범위 |
| 클라이언트 ID / 보안 비밀 | 이 앱이 진짜 그 앱인지 증명하는 신분증 + 비밀번호 |
| 리디렉션 URI | 인증이 끝난 뒤 돌아갈 주소를 미리 등록해두는 안전장치 |
| Internal / External | 이 앱을 회사 안에서만 쓸지, 아무나 쓸 수 있게 할지 |
| 테스트 사용자 | 심사 전 단계에서 미리 써볼 수 있게 등록해두는 이메일 명단 |
Day 8 — 로드맵을 PRD로: 예시 보여주며 하나씩 물어봐달라고 했다
한 줄 요약
로드맵엔 “뭘·왜”만 있고 “그래서 화면에 뭐가 보여야 하는지”는 없었다. AI한테 “빠진 것만 예시 보여주면서 하나씩 물어봐줘”라고 시켰더니, 진짜로 만들 수 있는 크기의 PRD가 나왔다.
이 글은 누구에게 도움될까: 로드맵은 만들었는데 “그래서 다음에 뭘 해야 하지”가 막막한 사람.
Before — 로드맵은 있는데 손이 안 감
로드맵엔 ”○○ 솔루션에 맞는 잠재고객을 찾아서 구글시트에 채운다”까지만 정해져 있었다. 근데 막상 만들려니 막막했다. 회사명은 어떻게 넣지? 시트엔 정확히 뭐가 채워져야 하지? 구현은 뭘로 하지? 하나도 안 정해져 있었다.
어떻게 — 실제 쓴 프롬프트
그냥 “PRD 만들어줘”라고 하면 뻔한 문서가 나올 것 같아서, 이렇게 구체적으로 시켰다.
내 로드맵에서 만들기로 한 걸 이제 실제로 만들 수 있게 구체화하고 싶어. 이걸 PRD라고 하지.
로드맵에서 이미 정한 "뭘·왜·누구를 위해"는 그대로 가져오고,
거기서 빠진 구체적인 것만 나한테 하나씩 물어봐줘.
예를 들어 화면에 뭐가 보여야 하는지, 뭐가 꼭 되어야 하는지 같은 것.
그리고 이걸 실제로 만든다면 지금 제일 쉽고 많이 쓰는 방법이 뭔지도
최신 기준으로 조사해서 짚어줘. (옛날 방식 말고, 지금 초보가 제일 적은 노력으로
만들 수 있는 방법으로. 더 쉬운 길이 있으면 알려줘.)
나는 잘 모르니, 막히면 예시를 몇 개 보여주면서 물어봐줘.
다 정리되면 PRD로 만들어서 내 사이트 위키에 저장해줘.
포인트는 세 가지였다.
- 로드맵에서 정한 건 다시 안 물어봐도 된다고 명시 — 안 그러면 뻔한 질문부터 다시 시작함
- “예시를 보여주면서” 물어봐달라고 요청 — 열린 질문(“화면에 뭐가 보여야 해?”)은 코딩 몰라서 막힘. 선택지가 있으면 고르기만 하면 됨
- 최신 기준으로 구현방법도 조사해달라고 요청 — “어떻게 만들지”까지 통째로 떠넘기지 않고, 조사해서 근거와 함께 추천하게 시킴
막힘 → 해결 — 예상 못 한 게 튀어나왔다
질문에 답하다가 “회사 명단을 어떻게 넣을지” 물었는데, 답하다 보니 원래 계획(“회사명을 입력하면 조회”)이랑 완전히 다른 게 튀어나왔다.
“네가 나에게 물을 것은 ‘몇 개 회사를 추가로 찾아드릴까요?’ 야. 이 때 이미 찾은 회사를 중복해서 찾지 않도록 해줘.”
즉 회사명을 내가 넣는 게 아니라, 에이전트가 직접 후보를 찾아야 한다는 거였다. 로드맵 쓸 때는 생각도 못 한 부분. AI가 이걸 그냥 넘기지 않고 “이렇게 이해했다”고 요약해서 확인받은 다음 넘어가서, 빠뜨리지 않고 PRD에 반영됐다.
After — 실제로 만들 수 있는 PRD가 나왔다
구현 방법도 그 자리에서 웹서치로 조사해서 “구글시트 MCP 서버 연결”과 “노코드 커넥터” 두 가지를 근거와 함께 보여줬고, 그중 하나를 골랐다. 결과물은 PRD 페이지에 저장됐고, 로컬 미리보기로 실제로 잘 뜨는지까지 확인했다.
배운 것 / 재사용 자산
- “빠진 것만 물어봐줘” 프롬프트 패턴: 이미 정한 건 다시 안 묻게 하고, 빠진 것만 예시와 함께 채우게 시키면 인터뷰가 훨씬 가벼워진다.
- “최신 기준으로 조사해줘”를 꼭 넣기: 안 그러면 AI가 오래된 기억으로 방법을 추천할 수 있다.
- 나중에 이 대화 자체를 “PRD” 스킬로 만들어서, 다음부턴 “PRD 만들어줘” 한 마디면 오늘 한 걸 그대로 재현하게 해뒀다.
클로드 커넥터가 안 될 때, 이미 설치해둔 CLI로 우회한 이야기
누구에게 도움: 클로드(또는 AI 도구)의 특정 연동이 계속 권한 오류로 막혀서, 원인은 못 찾았지만 일단 진도를 나가고 싶은 사람.
Before
PRD 세부계획 Day 1은 “구글시트에 클로드가 직접 읽고 쓸 수 있게 연결하기”였다. 클로드 코드가 가이드해준 방식대로 커스텀 커넥터(구글시트 연동)를 설정하고 진행했는데, 계속 오류가 났다. 지난주(7/30) 일지에도 “권한 없음(permission) 에러가 계속 남”이라고 적어뒀을 정도로, 며칠째 안 풀리고 있었다.
어떻게 했나
1) 다시 시도했는데 또 막혔다
기존 시트 셀에 값을 쓰는 건 됐지만(“테스트”를 A4 셀에 성공적으로 씀), 새 구글시트를 만드는 건 여전히 안 됐다.
Error: Permission denied
Please ensure the service account has access to the spreadsheet.
새 파일을 만드는 요청 자체를 거부하는 걸 보고, “이 커넥터는 이미 공유받은 파일만 다룰 수 있고, 새로 만드는 권한 자체가 없는 구조인가 보다”라는 심증까지는 갔다. 하지만 커넥터 설정 화면에서 이 연동 자체를 찾을 수가 없어서, 권한을 직접 고칠 방법도 없었다.
2) 원인 찾기를 포기하고, 이미 있는 다른 길을 확인했다
근본 원인을 계속 파기보다, “혹시 이걸 우회할 다른 방법이 이미 있나?”로 방향을 틀었다. 마침 예전에 지피터스 설치 클래스를 따라 gws라는 구글 워크스페이스 CLI를 설치해서 로그인까지 해뒀던 게 있었다.
gws auth status
확인해보니 이미 내 구글 계정으로 OAuth 인증이 돼 있었고, drive·spreadsheets 권한까지 다 갖고 있었다.
3) CLI로 직접 새 시트를 만들고 값을 썼다
gws sheets spreadsheets create --json '{"properties": {"title": "lead gen test 2"}}'
gws sheets spreadsheets values update \
--params '{"spreadsheetId": "생성된ID", "range": "B1", "valueInputOption": "USER_ENTERED"}' \
--json '{"values": [["테스트"]]}'
새 시트가 바로 만들어지고, B1 셀에 값도 정상적으로 들어갔다.
여기에 실제로 만들어진 구글시트에 “테스트” 값이 채워진 화면 스크린샷을 넣으면 좋다.
막힘 → 해결
- 막힘: 커넥터가 왜 새 파일 생성 권한만 없는지, 근본 원인(root cause)은 끝내 못 찾았다.
- 해결(우회): 원인 파악과 별개로, 이미 설치·인증돼 있던 다른 도구(gws CLI)로 같은 작업을 완전히 다른 경로로 성공시켰다.
- 커넥터 오류의 진짜 원인은 다음 과제로 남겨뒀다.
After
- 며칠째 막혀 있던 PRD 세부계획 Day 1(구글시트 연결)의 완료 기준 — “빈 구글시트에 테스트로 아무 값이나 써넣는 데 성공” — 을 오늘 달성했다.
- 다음 단계(공공데이터 API 키 발급, ICP 설정 등)로 넘어갈 수 있게 됐다.
- 다만 마음은 100% 개운하지 않다. 문제를 “해결”한 게 아니라 “우회”한 거라서, 근본 원인은 여전히 찜찜하게 남아 있다.
배운 것 / 재사용 자산
막힌 연동이 있을 때 시도해볼 체크리스트
- 정확히 어느 단계에서, 어떤 메시지로 막히는지부터 기록한다 (오늘처럼 “Permission denied” 원문을 남겨두면 나중에 검색하기도 쉽다).
- 근본 원인을 못 찾겠으면, 오래 붙잡고 있지 말고 “이미 설치·인증해둔 다른 도구가 있나?”부터 확인한다. (
which <도구명>,<도구명> auth status같은 명령으로 빠르게 확인 가능) - 우회로 일단 진도를 나가되, 원인 파악은 완전히 잊지 말고 다음 과제로 명시적으로 남겨둔다.
같은 목표(구글시트에 값 쓰기)라도 접근 경로가 여러 개일 수 있다는 것, 그리고 “원인을 몰라도 일단 우회해서 앞으로 나가도 된다”는 걸 배웠다.
반복 작업을 스킬로 저장하고, 승인 프롬프트까지 줄인 이야기
누구에게 도움: 클로드 코드로 반복 작업을 시키는데 매번 같은 설명을 다시 해야 해서 지치는 사람, 또는 “허용” 버튼을 계속 눌러야 해서 번거로운 사람.
Before
리드젠 에이전트가 회사 하나를 조사하는 과정(공공데이터로 기본정보 조회 → 홈페이지 방문 → 뉴스 검색 → 시트에 기록)이 꽤 여러 단계였다. 다음에 회사를 더 찾으려면 이 순서를 매번 처음부터 다시 설명해야 할 판이었다. 게다가 이 과정을 실제로 돌려보니, 몇 단계마다 “허용” 승인창이 떠서 계속 지켜보고 있어야 했다.
어떻게 했나
1) 반복될 작업을, 하고 나서 바로 스킬로 저장했다
콜드 이메일(다음 단계)은 성격이 달라서 빼고, 딱 여기까지만 스킬로 만들어달라고 했다.
“콜드 이메일은 좀 다른 단계여서, 일단 지금까지를 스킬로 저장해줘”
콩콩이 오늘 실제로 한 순서(몇 개 찾을지 묻기 → ICP 우선순위대로 후보 정하기 → 공공데이터 조회 → 홈페이지·뉴스 검증 → 시트 기록)를 그대로 .claude/skills/리드조사/SKILL.md로 저장했고, AGENTS.md에도 “회사 N개 더 찾아줘”라고 말하면 이 스킬이 실행되도록 등록해줬다.
2) 바로 테스트해서 실제로 되는지 확인했다
“스킬이 잘 작동하는지 보기 위해 회사 2개 더 찾아줘”
바로 실행해보니 잘 됐다. 심지어 스킬 문서에 적어둔 “동명이인 계열사 조심” 경고가 실전에서 그대로 맞아떨어졌다 — “현대위아”를 검색했더니 진짜 회사가 아니라 관계없는 자회사 “현대위아터보”가 먼저 잡혔는데, 스킬에 적힌 방법대로 정확한 회사 코드를 다시 지정해서 바로잡았다.
3) 그런데 승인 프롬프트가 계속 떴다
스킬 자체는 잘 됐지만, 회사를 조사하는 동안 “허용”을 2~3번 눌러야 했다.
“스킬이 잘 작동하는 것은 좋은데, 스킬을 이용해 회사 조사하는 과정에서 내가 허용을 2-3번 했었어. 이 허용없이 진행될 수 있도록 설정해 주고 스킬도 업데이트 해줘”
콩콩이 fewer-permission-prompts라는 스킬로 최근 대화 기록을 스캔해서, 읽기 전용이라 안전한 작업만 골라 .claude/settings.json에 자동 허용으로 추가했다. 반면 진짜 시트에 값을 쓰는 것(수정 작업)은 일부러 그대로 뒀다 — 되돌리기 어려운 작업은 계속 확인받는 게 맞다고 판단해서다.
4) 승인 프롬프트에 두 종류가 있다는 걸 알게 됐다
한 번 더 요청했더니, 콩콩이 재밌는 구분을 짚어줬다.
- 일반 도구 권한 (Bash 명령어·MCP 도구 호출) —
.claude/settings.json으로 제어 가능 - 브라우저가 새 사이트를 처음 열 때 뜨는 확인창 — 이건 별도 보안장치라 설정 파일로 못 끔
전부 다 없애는 방법(claude --dangerously-skip-permissions)이 있다는 것도 알려줬지만, 이건 승인 전체를 통째로 끄는 옵션이라 아직 위험도를 다 이해 못 했다는 이유로 그대로 남겨두기로 했다.
“이슈를 이해했으며, 이 부분은 그대로 둘께”
After
- 회사 조사 과정에서 뜨던 승인창이 대부분 사라졌다. 진짜 확인이 필요한 것(새 사이트 첫 방문, 시트에 실제로 값 쓰기)만 남았다.
- “회사 N개 더 찾아줘”라는 한마디로, 오늘 정리한 전체 순서가 그대로 반복된다.
- 무작정 다 꺼버리지 않고, “이게 왜 위험한지 아직 잘 모른다”는 이유로 한 가지 옵션은 일부러 안 켰다.
배운 것 / 재사용 자산
반복 작업을 스킬로 만들 때 체크리스트
- 오늘 실제로 한 순서를 그대로 스킬 문서에 옮긴다 (기억으로 재구성하지 않기).
- 만들고 바로 다시 실행해서 “진짜 되는지” 테스트한다.
- 테스트하다 나온 버그·예외 상황(동명이인 계열사 등)은 스킬 문서에 바로 반영한다.
승인 프롬프트를 줄일 때 기억할 것
- 모든 승인이 같은 종류가 아니다. **“읽기만 하는 것”**과 **“뭔가를 바꾸는 것”**을 구분해서, 읽기만 하는 것만 자동 허용하면 안전하면서도 편해진다.
- “전부 다 꺼버리는” 옵션은 존재하지만, 그 위험을 다 이해하기 전엔 안 켜는 게 맞다. 편리함보다 이해가 먼저다.
2주차 회고 — 하루 만에 끝낸 로드맵, 그리고 스케일업의 벽
한 줄 요약: 며칠째 막혀 있던 로드맵을 하루 만에 다 뚫었지만, “더 크게” 만들려는 순간 완전히 새로운 벽 3개를 마주한 한 주.
누구에게 도움: 프로토타입은 잘 되는데 스케일을 키우려니 막막해진 사람, “일단 되는 것”과 “제대로 되는 것”의 차이를 겪고 있는 사람.
Before — 며칠째 막혀 있던 시작점
지난주(1주차)엔 로드맵과 PRD를 짰지만, 실행 단계로 넘어가려던 순간 구글시트 연결부터 막혀 있었다. 클로드 커넥터가 원인 모를 오류를 계속 냈고, 그 상태로 며칠이 지났다.
어떻게 했나 — 하루 만에 9일 치를 끝내다 (8/3)
막혔던 걸 억지로 뚫으려 하지 않고, 이미 컴퓨터에 있던 다른 도구(gws CLI)로 우회하기로 했다.
gws sheets spreadsheets create --json '{"properties": {"title": "..."}}'
이게 뚫리자 나머지가 도미노처럼 풀렸다. 공공데이터 API 키 발급, 제품 이해 심화(체이스가 갖고 있던 2026 트렌드리포트까지 같이 읽음), 정부 3대 메가프로젝트를 반영한 잠재고객 프로필 6개 확정, 실제 회사 15개를 공공데이터·홈페이지·뉴스로 검증해서 시트에 채우기까지 — 원래 2주(근무일 기준) 잡았던 계획을 하루 만에 끝냈다.
여기서 멈추지 않고, 이 전체 조사 과정을 “리드조사”라는 스킬로 저장해서 “회사 N개 더 찾아줘” 한마디로 반복되게 만들었고, 스킬을 쓰다 보니 매번 뜨는 승인 프롬프트가 거슬려서 그것도 안전한 것들만 골라 자동화했다.
막힘 → 해결, 그리고 새로운 막힘 (8/6)
3주차로 넘어가 “찾은 회사가 정확한지” 다시 들여다봤다. 자동차 딜러사를 잠재고객으로 넣었었는데, 알고 보니 트렌드리포트의 고객 사례(NXRT)를 잘못 일반화한 것이었다 — NXRT는 딜러사가 아니라 “이 솔루션으로 자기 제품을 만들어 파는 회사(ISV)“였다. “직접고객 / ISV파트너 / 서비스파트너” 3가지 구매자 유형을 새로 정의하고, 업종코드 필터와 정성 체크리스트로 판별 로직을 강화했다.
그 다음 “정말 스케일이 되는지” 시험해보려고 상장기업 4,000개를 스크립트로 스크리닝했다. 여기서 두 가지 사고를 연달아 겪었다.
- API를 동시 8개로 몰아쳤다가 접속이 통째로 차단됨. 가짜 키로 테스트해서 “내 키 문제가 아니라 접속 자체가 막혔다”는 걸 진단하고, 순차 실행+딜레이+하루 호출 상한으로 재발 방지책을 만들었다.
- 회로차단기를 테스트하다가, 애써 모은 577개 결과 파일이 0개로 덮어써짐. “이전 결과보다 나쁘면 저장하지 않는다”는 안전장치를 추가했다.
After — 풀린 것과 안 풀린 것
| 풀린 것 | 안 풀린 것 |
|---|---|
| 시트 연결, ICP 프로필 확정, 15개 회사 조사 | 적합한 잠재고객을 찾는 방법론 자체가 아직 부족함 |
| 반복 조사 과정의 스킬화 | 홈페이지를 열 때마다 사람이 “허용”을 눌러야 하는 개입 |
| API 차단 원인 진단 + 재발방지 | 공공데이터 차단 기준을 정확히 몰라, 완전한 방지책은 아직 없음 |
| 결과 파일 덮어쓰기 버그 수정 |
배운 것 / 재사용 자산
- 막힌 걸 억지로 뚫으려 하지 말고, 이미 있는 다른 길을 먼저 찾아본다. (클로드 커넥터 대신
gwsCLI) - API가 갑자기 막히면: 가짜 키로 테스트해서 “내 문제인지 접속 자체 문제인지” 구분한다.
- 자동화 스크립트는 저장 전에 “이전보다 나쁘면 안 덮어쓰기” 안전장치를 기본으로 넣는다.
- 사례집 하나에 나온 회사를 그대로 잠재고객으로 일반화하기 전에, “이 회사가 진짜 직접고객인지, 아니면 그 위에 또 다른 벤더가 있는지”부터 확인한다.
다음 주로
이번 주는 “일단 되게 만드는 것”에서 “제대로, 크게 되게 만드는 것”으로 넘어가는 전환점이었다. 완벽히 풀고 넘어가진 못했지만, 안 풀린 문제의 정체는 명확해졌다 — 판별 방법론, 사람 개입 없는 자동화, 안정적인 데이터 접근 세 가지. 다음 주는 이 세 가지를 순서대로 푸는 데 집중한다.
3주차
API를 몰아쳤다가 IP 차단당하고, 원인을 진단한 이야기
누구에게 도움: 공공데이터 API나 무료 API로 대량 작업을 자동화하다가, 갑자기 요청이 다 실패하기 시작한 사람.
Before
상장기업 4,000개의 업종코드를 자동으로 훑는 스크립트를 만들었다. “빨리 끝내고 싶어서” 동시에 8개씩 요청을 보내도록 짰다. 처음엔 잘 됐다 — 200개, 400개, 600개… 순조롭게 진행되다가, 1,000개쯤 지난 시점부터 갑자기 요청이 죄다 실패하기 시작했다.
어떻게 했나
1) 증상부터 정확히 봤다
에러 메시지를 그냥 넘기지 않고 자세히 봤다.
Recv failure: Connection reset by peer
이건 “느려서 시간초과”가 아니라, 서버가 연결 자체를 강제로 끊어버리는 증상이었다.
2) “내 키 문제인지” vs “접속 자체가 막힌 건지” 구분했다
가장 먼저 확인해야 할 건 “무엇이 막혔나”였다. 그래서 일부러 가짜 API 키로 똑같이 요청해봤다.
curl -sv "https://opendart.fss.or.kr/api/company.json?crtfc_key=test&corp_code=00126380"
결과: 진짜 키로 시도했을 때와 **완전히 똑같은 “Connection reset”**이 났다. 키가 틀렸다는 응답(보통은 별도 에러 메시지)이 아니라 그냥 연결이 끊겼다는 건, 키의 문제가 아니라 접속 자체(아마 IP 단위)가 막혔다는 뜻이었다.
3) 범위를 넓혀서 한 번 더 확인했다
혹시 인터넷 자체가 문제인 건 아닌지도 확인했다.
curl -s -o /dev/null -w "%{http_code}\n" https://www.google.com # 200 (정상)
curl -s -o /dev/null -w "%{http_code}\n" https://opendart.fss.or.kr/ # 000 (API 아닌 메인 홈페이지조차 안 열림)
구글은 멀쩡한데 OpenDART 메인 홈페이지조차 안 열리는 걸 보고, “이 사이트로 가는 접속 자체가 막혔다”는 결론을 내렸다.
막힘 → 해결
- 막힘: 정확히 몇 분/몇 시간 차단되는지, 공식적으로 어떤 기준으로 차단하는지는 끝내 못 찾았다 (사이트 자체가 안 열려서 이용약관도 확인 못 함).
- 해결(재발 방지): 원인을 정확히 몰라도, 다시 안 걸리게 스크립트를 훨씬 보수적으로 고쳤다.
- 동시 요청 8개 → 1개(순차 실행)
- 요청 간 딜레이 250ms → 700ms
- **하루 호출 총량 상한(800회)**을 코드로 강제 — 넘으면 자동 중단
- User-Agent에 연락처를 명시해서 익명 트래픽처럼 안 보이게 함
After
재발 방지 설정을 적용한 뒤로, 같은 스크립트를 다시 돌려도 안전하게 진행되는 걸 확인했다. (참고: 한 번 차단된 뒤엔 즉시 풀리지 않아서, 이 글을 쓰는 시점에도 완전히 복구되진 않았다 — 이건 진행형 이슈다.)
배운 것 / 재사용 자산
API가 갑자기 다 막힐 때 진단 체크리스트
- 에러 메시지를 정확히 읽는다 (“타임아웃”과 “연결 강제 종료”는 원인이 다르다).
- 일부러 가짜 키로 같은 요청을 해본다 — 키 문제인지 접속 자체 문제인지 바로 구분됨.
- 그 API가 아닌 **다른 사이트(구글 등)**로도 확인해서, 내 인터넷 문제가 아닌지 배제한다.
- 그 서비스의 메인 홈페이지도 열어봐서, API만 막힌 건지 전체가 막힌 건지 확인한다.
원인을 100% 못 찾아도 괜찮다. “왜 막혔는지”보다 “다시 안 막히게 어떻게 할지”에 먼저 집중하는 게 실전에서는 더 빠른 길이었다.
자동화 스크립트가 내 데이터 577개를 통째로 지울 뻔한 사고
누구에게 도움: 결과를 파일로 저장하는 배치 스크립트를 만들어서 반복 실행하는 사람. “같은 스크립트를 두 번 돌렸을 뿐인데 데이터가 사라지는” 사고를 예방하고 싶은 사람.
Before
전날(Day 13) 후보 회사 스크리닝 스크립트를 돌려서 577개짜리 결과 파일을 힘들게 모아뒀다. 다음날(Day 15), 이 스크립트에 “연속 실패하면 알아서 멈추는 안전장치(회로차단기)“를 추가하고서, 그게 진짜 작동하는지 테스트하려고 스크립트를 다시 실행했다.
어떻게 했나
1) 일부러 “고장난 상황”에서 테스트했다
그날은 마침 API 접속이 막혀있는 상태였다. “이런 상황에서 스크립트가 무한정 매달리지 않고 잘 멈추는지” 확인하려고 일부러 그 상태 그대로 실행했다.
node agent/bulk-screen.mjs
2) 회로차단기는 완벽하게 작동했다
연속 8번 실패하자 스크립트가 알아서 멈췄다. 목표했던 대로였다.
⚠️ 연속 8회 실패 — API가 막힌 것으로 판단해 회로차단기를 작동합니다.
3) 그런데 결과 파일을 열어보니 문제가 있었다
python3 -c "
import json
d = json.load(open('agent/data/bulk-screen-results.json'))
print('total_candidates:', d.get('total_candidates'))
"
total_candidates: 0
577개였던 결과가 0개로 바뀌어 있었다. 이번 실행은 아무것도 못 가져왔으니 결과가 0개인 게 당연한데, 문제는 스크립트가 “이번 결과(0개)“를 예전 파일 위에 그냥 덮어써버렸다는 것이었다. 어제 힘들게 모은 577개가 그렇게 사라졌다.
막힘 → 해결
- 막힘: 스크립트를 “다시 실행”하는 게 이렇게 위험한 일인 줄 몰랐다. 결과 저장 로직에 “이번 게 더 나은지” 체크가 전혀 없었다.
- 해결: 저장하기 직전에 이전 파일과 비교하는 코드를 넣었다.
if (totalCandidates < previousTotal) {
// 이번 결과가 더 적으면 원본은 그대로 두고, 별도 파일로만 저장
const partialPath = outPath.replace(".json", `-partial-${Date.now()}.json`);
writeFileSync(partialPath, JSON.stringify(result, null, 2));
} else {
// 같거나 더 많을 때만 진짜로 덮어씀
writeFileSync(outPath, JSON.stringify(result, null, 2));
}
After
- 다행히 완전히 다 잃진 않았다. 그 전날 만들어둔 “상위 30개 후보” 파일은 별도 파일이라 무사했다.
- 원본 577개 상세 리스트는 결국 못 살렸지만, API가 복구되면 스크립트를 다시 돌려서 재생성할 수 있다는 것도 확인했다 (업종코드는 매일 바뀌는 데이터가 아니라서).
- 지금부터는 같은 스크립트를 몇 번을 다시 돌려도, “이전보다 나쁜 결과”가 원본을 덮어쓰는 일은 없다.
배운 것 / 재사용 자산
결과를 파일로 저장하는 자동화 스크립트를 짤 때 기본으로 넣을 것
- 저장하기 전에 “기존 파일이 있다면, 이번 결과와 비교”하는 코드를 먼저 넣는다.
- 비교 기준은 단순해도 괜찮다 (예: 개수). 완벽한 판단이 아니어도, “숫자가 갑자기 확 줄면 뭔가 잘못됐다”는 신호로 충분히 유용하다.
- 이번이 더 나쁘면 원본을 바꾸지 말고 타임스탬프 붙은 별도 파일로 저장해서, 사람이 나중에 판단할 수 있게 남겨둔다.
- 이 판단 기준(개수)에는 한계가 있다는 것도 인지한다 — 개수는 같은데 내용이 틀렸거나, 정당한 이유로 개수가 줄어든 경우는 이 장치가 못 잡는다. 그래도 “아무 장치가 없는 것”보다는 훨씬 안전하다.
가장 큰 교훈은: “테스트로 한 번 더 돌려보는 것”조차 데이터를 망가뜨릴 수 있다는 걸 몸으로 겪었다는 것. 자동화 스크립트는 편리한 만큼, 안전장치 없이 쓰면 그만큼 빠르게 실수도 커진다.
잠재고객 수만 개를 만들려다 마주친 3가지 현실의 벽
누구에게 도움: “일단 되는 것”과 “실제로 쓸 수 있게 만드는 것” 사이의 간극을 겪고 있는 사람. 프로토타입은 잘 됐는데 스케일을 키우려니 막막해진 사람.
Before
지난 며칠간 리드젠 에이전트가 15개 회사까지는 문제없이 채워졌다. 회사 하나씩 조사하는 과정(공공데이터 조회 → 홈페이지 확인 → 뉴스 검증 → 시트 기록)도 스킬로 만들어서 반복 가능하게 해뒀다. **“이제 이걸 수백~수만 개로 늘리기만 하면 되겠다”**고 생각했다.
실제로 부딪힌 것
스케일을 키우려고 대량 스크리닝 스크립트를 만들어서 돌려보니, 생각보다 훨씬 근본적인 문제 3가지가 드러났다.
1) “적합한 회사를 찾는 방법론” 자체가 아직 부족하다
업종코드 필터와 정성 체크리스트를 만들긴 했다. 그런데 실제로 대량 스크리닝을 돌려서 상위 후보 5개를 검증해보니, 5개 중 확실히 통과한 게 0개였다 (스캠 사이트, 엉뚱한 회사 정보, 방치된 홈페이지 등). 지금 로직이 “명백히 틀린 것”은 잘 걸러내지만, “진짜 좋은 후보”를 정확히 골라내는 데는 아직 한참 부족하다는 게 드러났다.
2) 홈페이지를 열 때마다 사람이 “허용”을 눌러야 한다
새로운 회사 홈페이지를 열 때마다, 브라우저가 “이 사이트를 열어도 될까요?” 하고 한 번씩 확인을 받는다. 회사가 몇 개면 괜찮은데, 수백~수만 개가 되면 이 지점 하나만으로도 사람이 하루 종일 매달려야 한다. 이걸 없애는 방법을 아직 못 찾았다 — 이건 도구 자체의 권한 설정이 아니라 브라우저에 내장된 별도 보안 장치라서, 지금 알고 있는 방법으로는 못 끈다.
3) 공공데이터 접근 자체가 차단당했다
스크립트를 빠르게 돌리려다가 API 접속이 통째로 막혔다. 속도를 늦추고 하루 호출 한도를 정해두는 식으로 재발 방지책을 만들긴 했지만, 정확히 어떤 기준을 넘으면 차단되는지는 여전히 모른다. 추측으로 안전선을 그어둔 것일 뿐, 진짜 안전한 선인지는 확신이 없다.
지금 상태 (아직 미해결)
초기 테스트(15개)는 잘 됐지만, 진짜 목표(수백~수만 개)에 필요한 세 가지 — 정확한 판별 방법론, 사람 개입 없는 완전 자동화, 안정적인 데이터 접근 — 가 전부 아직 완성되지 않았다. 오늘은 이 문제들을 명확히 “발견”한 날이지, “해결”한 날은 아니다.
배운 것
- 작은 규모에서 되는 것과 큰 규모에서 되는 것은 다른 문제다. 15개에서 통했던 방식이 577개·수만 개로 가면 완전히 새로운 장애물을 만난다.
- 문제를 명확히 인식하는 것 자체도 진전이다. 세 가지 벽의 정체를 알았으니, 다음엔 “막연한 불안”이 아니라 “구체적인 과제” 세 개를 풀면 된다.
- 걱정되는 게 정상이다. 없던 문제를 만들어낸 게 아니라, 원래 있었는데 작은 규모에서는 안 보였던 문제를 이제야 마주한 것뿐이다.
다음에 풀어야 할 것 (재사용 자산 대신 — 체크리스트)
- ICP 판별 방법론을 더 정교하게 — 지금의 업종코드+체크리스트보다 더 신뢰할 수 있는 근거 필요
- 브라우저 사이트 승인을 우회하지 않으면서도 사람 개입을 줄일 다른 방법 탐색 (예: 홈페이지 확인을 API 기반 다른 방식으로 대체하는 것도 고려)
- 공공데이터 API의 공식 이용 제한을 반드시 찾아서, 추측이 아닌 확실한 안전선 확보
승인 팝업을 0으로 만들기까지 — 허용 목록을 넓히는 건 답이 아니었다
한 줄 요약 — 자동화가 자꾸 멈추는 이유가 “허용을 안 해줘서”인 줄 알았는데, 사실은 내가 명령을 감싸고 있어서였다.
이런 분께 도움 — 클로드 코드로 반복 작업을 자동화하는데 승인 팝업 때문에 자리를 못 뜨는 분.
Before — “자동화”인데 내가 계속 앉아 있어야 했다
회사 정보를 찾아 구글시트에 채우는 에이전트를 만들었다. 그런데 회사 한 곳을 조사할 때마다 이런 팝업이 여러 번 떴다.
이 명령을 실행하도록 허용하시겠습니까?
회사가 5곳이면 팝업도 그만큼 늘었다. 결국 화면 앞에 앉아 계속 “허용”을 눌러줘야 했다. 이건 자동화가 아니라 그냥 클릭 노동이었다.
📸 여기에 승인 팝업 화면 스크린샷을 넣으면 좋아요
목표를 이렇게 정했다.
“회사 N개 조사해줘”라고 했을 때 허용 요청이 아예 없을 것.
시도 ① — 허용 목록에 명령을 추가했다 (부분 성공)
제일 먼저 떠오른 방법이다. 설정 파일에 “이 명령은 물어보지 말고 그냥 해”라고 적어두는 것.
.claude/settings.json
{
"permissions": {
"allow": [
"Bash(node agent/opendart-lookup.mjs *)",
"Bash(gws sheets spreadsheets values get *)"
]
}
}
조회는 조용해졌다. 그런데 팝업은 계속 떴다.
한참 헤맸다. 분명 허용해뒀는데 왜 또 물어보지? 이때는 원인을 몰라서 “허용 목록을 더 넓게 적어야 하나” 쪽으로 생각이 흘렀다. 그게 함정이었다.
시도 ② — 팝업이 뜨는 자리를 스크립트로 대체했다 ★ 진짜 전환점
원인을 추적해보니, 팝업은 명령 자체가 아니라 명령을 부르는 방식 때문에 떴다.
- 홈페이지를 볼 때 쓰는 브라우저 도구는 사이트마다 승인을 요구한다 → 회사가 늘면 승인도 비례해서 는다
- 시트 목록을 볼 때 출력이 길어서
| head를 붙였다 → 파이프를 붙이는 순간 막힌다 - 시트에 쓸 때 지저분한 안내 문구를
| grep -v로 걸러냈다 → 역시 막힌다
세 개 다 “내가 뭘 덧붙였기 때문에” 막힌 거였다. 그래서 덧붙일 필요가 없게 만들었다.
| 팝업이 뜨던 자리 | 왜 떴나 | 어떻게 바꿨나 |
|---|---|---|
| 홈페이지 확인 | 브라우저 도구는 사이트마다 승인 | fetch-site.mjs를 만듦 — 규칙 한 줄로 허용되고, 회사가 몇 곳이든 승인이 안 늘어남 |
| 시트 현황 보기 | 출력이 길어 | head를 붙임 | sheet-list.mjs를 만듦 — 출력을 스크립트 안에서 이미 정리해서 파이프가 필요 없음 |
| 시트에 쓰기 | 안내 문구를 | grep -v로 걸러냄 | sheet-write.mjs가 그 문구를 스크립트 안에서 삼키게 고침 |
핵심은 허용 범위를 넓힌 게 아니라, 감쌀 이유를 없앤 것이다. 파이프를 붙이고 싶어지는 자리를 전부 스크립트 안으로 옮겼다.
그리고 새로 만든 스크립트를 허용 목록에 넣었다.
"Bash(node agent/fetch-site.mjs *)",
"Bash(node agent/sheet-write.mjs *)",
"Bash(node agent/sheet-list.mjs)",
"Bash(node agent/sheet-list.mjs *)"
⚠️ 문법 함정 —
Bash(X *)는 뒤에 인자가 붙어야 매칭된다.node agent/sheet-list.mjs처럼 인자 없이 부르는 명령은 따로 한 줄을 더 넣어야 한다. 위에 비슷해 보이는 두 줄이 나란히 있는 게 그 이유다.
시도 ③ — 그런데 또 떴다 (내 습관이 문제였다)
②를 다 해놓고도 팝업이 또 떴다. 회사 5곳을 한 번에 처리하면서 이렇게 묶었기 때문이다.
for f in curexo kctech ...; do node agent/sheet-write.mjs --append $S/$f-values.json; done
승인창에 낯선 문구가 떴다 — Contains simple_expansion.
금지 대상이 파이프만이 아니었다. 세 가지 전부였다.
| 쓰면 막히는 것 | 예시 |
|---|---|
| 파이프 | 명령 | head, 명령 | grep |
| 반복문 | for f in ...; do ... done |
| 셸 변수 | $S/$f-values.json |
그래서 규칙을 이렇게 바꿨다.
회사가 10곳이면 명령을 10줄로 따로 부른다. 경로는 변수 없이 전체 경로를 그대로 적는다.
5줄, 10줄이 지저분해 보여도 그게 승인 0회를 지키는 유일한 방법이었다.
부끄러운 기록도 하나 남는다. 오전에 이 교훈을 메모까지 해놓고, 오후에 같은 실수를 또 했다. 심지어 “승인 0회 달성”이라고 잘못 보고했다가 스크린샷으로 정정당했다. 습관은 메모 한 줄로 안 바뀐다.
시도 ④ — 조용한데 뚫려 있던 구멍
팝업이 안 뜨게 된 뒤 전수 점검을 하다가 이걸 발견했다.
"Bash(gws sheets *)" // 모든 시트 명령이 무승인 통과 — 다른 시트에 쓰는 것까지
승인은 안 떴다. 하지만 “우리 시트에만 쓴다”는 울타리가 이미 뚫려 있었다. 전용 스크립트를 만들어 시트를 제한해뒀는데, 이 규칙 한 줄이 그 옆으로 지나가는 샛길이었다.
"Bash(gws sheets +read *)" // 읽기만 허용. 쓰기·삭제·생성은 전부 차단
로 좁혔다. 이제 시트에 쓰는 길은 전용 스크립트 하나뿐이다.
승인이 안 뜬다고 안전한 게 아니다. 조용한 것과 안전한 것은 다르다.
After — 승인 0회
회사 4곳(자이언트스텝·엘오티베큠·효성중공업·HD현대일렉트릭)을 조사해서 시트에 기록하는 전 과정에서 팝업이 한 번도 안 떴다. 직접 확인했다.
| Before | After | |
|---|---|---|
| 회사 1곳당 승인 | 여러 번 | 0회 |
| 회사가 늘어나면 | 승인도 비례해서 늘어남 | 안 늘어남 |
| 사람이 있어야 하나 | 계속 앉아 있어야 함 | 자리를 떠도 됨 |
마지막 줄이 제일 중요하다. 이게 되니까 매일 정오에 알아서 회사 10곳을 조사하는 예약 실행을 걸 수 있었다. 승인이 한 번이라도 뜨면 거기서 멈춰버리니까, 0이 아니면 애초에 불가능한 일이었다.
가져가서 쓸 체크리스트
자동화가 자꾸 멈춘다면 이 순서로 점검해보세요.
- 명령에 파이프(
|)를 붙이고 있지 않은가? → 출력이 지저분하면 파이프 말고 스크립트 안에서 정리하게 고치기 - 반복문(
for ... done)으로 묶고 있지 않은가? → 개수만큼 명령을 따로 부르기 - 셸 변수(
$경로)를 쓰고 있지 않은가? → 전체 경로를 그대로 적기 - 사이트·파일마다 승인이 필요한 도구를 쓰고 있지 않은가? → 규칙 한 줄로 허용되는 전용 스크립트로 대체
- 인자 없이 부르는 명령이 있는가? →
Bash(명령)규칙을 따로 한 줄 추가 - 넓게 허용해둔 규칙이 남아 있지 않은가? → 조용해도 뚫려 있을 수 있으니 좁히기
배운 것
허용 목록을 넓히는 건 답이 아니었다. 넓힐수록 팝업은 줄지 몰라도 울타리가 사라진다. 실제로 통한 건 반대 방향이었다 — 승인이 필요할 일 자체를 없애는 것.
그리고 순서가 있었다. 시도 ②가 8할, ③이 나머지다. 좋은 스크립트를 만들어놔도 그걸 for로 묶는 순간 원점이라, 도구를 고치는 것과 습관을 고치는 것이 둘 다 필요했다.
시도 ①만으로는 절대 0이 안 됐다는 게 이 이야기의 핵심이다. 처음 떠오른 방법이 가장 그럴듯했는데, 가장 오래 헤매게 만든 길이기도 했다.
3주차 — 걱정 3개로 시작해서, 매일 도는 에이전트로 끝난 주
한 줄 요약 — 주 초엔 “이대로는 규모를 못 키우겠다”는 걱정 3개를 안고 시작했다. 주 말엔 그 셋이 다 풀렸고, 매일 정오에 알아서 도는 에이전트가 남았다.
이런 분께 — AI에게 반복 작업을 시키는데 자꾸 멈춰서 결국 옆에 붙어 있게 되는 분.
시작점 — 계획은 다 끝냈는데 걱정만 남았다
이 주는 앞주에 몰아서 끝낸 작업의 뒷맛에서 시작됐다. 판별 로직을 강화하고 대량 파이프라인까지 만들어 계획표는 전부 체크됐는데, 마음이 편하지 않았다.
| 그때 걱정 | 왜 |
|---|---|
| 진짜 잠재고객인지 판별하는 방법이 부족하다 | 업종코드만으론 한계가 보였다 |
| 홈페이지 열 때마다 사람이 승인을 눌러야 한다 | 이러면 규모를 못 키운다 |
| 공공데이터가 왜 차단됐는지 모르겠다 | 원인을 모르니 또 당할 것 같았다 |
**“계획을 다 지켰는데 목표엔 못 다가갔다”**는 느낌이었다. → 그때 기록
그 직전에 큰 오해도 하나 발견했다. 자동차 딜러사를 잠재고객으로 넣어뒀는데, 딜러사는 우리 제품을 사는 곳이 아니라 “우리 제품으로 뭔가 만들어 파는 회사”의 고객이었다. 진짜 잠재고객은 딜러사가 아니라 딜러사에 납품하는 그 회사였다. 한 단계를 잘못 보고 있었던 것이다. 제품을 얕게 알면 그 위에 쌓는 게 전부 흔들린다.
그래서 이번 주 목표를 이렇게 잡았다.
“prospects 100개를 조사해줘”라고 하면, 멈춤 없이 알아서 조사하고 시트에 기록하는 에이전트.
핵심은 100이라는 숫자가 아니라 **“멈춤 없이”**였다.
벽 1 — 100개는커녕 1개에서 멈췄다
회사 한 곳을 조사하는 동안에도 팝업이 여러 번 떴다.
이 명령을 실행하도록 허용하시겠습니까?
며칠째였다. 팝업이 뜰 때마다 내가 화면 앞에 있어야 하니, 자동화가 아니라 클릭 노동이었다.
📸 여기에 승인 팝업 스크린샷을 넣으면 좋아요
처음 시도한 방법은 오답이었다. 설정 파일에 명령을 하나씩 추가해 “묻지 말고 그냥 해”라고 적어두는 것. 조회는 조용해졌는데 팝업은 계속 떴다.
진범은 명령이 아니라 내가 명령에 덧붙인 것들이었다.
| 이러면 막힌다 | 예시 |
|---|---|
| 파이프 | 명령 | head |
| 반복문 | for f in ...; do ... done |
| 셸 변수 | $경로/$파일 |
허용된 명령이라도 이 셋으로 감싸는 순간 전체가 막힌다. 그래서 방향을 뒤집었다 — 허용을 넓히는 게 아니라, 감쌀 이유를 없애기. 출력이 길어 파이프를 붙이던 자리는 스크립트가 직접 정리하게 고쳤고, 사이트마다 승인이 필요한 브라우저 도구는 전용 스크립트 하나로 대체했다.
결과는 승인 0회. → 자세한 과정
벽 2 — 이번엔 공공데이터가 나를 차단했다
속도를 내려고 동시에 8개씩 요청했더니 연결이 끊겼다. 그 뒤로 모든 조회가 막혔다.
한 번에 보내는 개수도 제약이지만, 그보다 중요한 건 간격이었다. 하루 총량이 아니라 순간 속도가 진짜 원인이었다.
동시 요청을 2개로 줄이고, 요청 사이에 딜레이를 넣고, 실패하면 재시도하고, 중간 결과를 저장해 다시 실행하면 이어서 진행되게 고쳤다. 속도를 올리면 자동화가 오히려 멈춘다. → 진단 과정
그러다 막힌 진짜 질문
두 벽을 넘으면서 계속 마음에 걸린 게 있었다. 승인 0회에 도달하기까지, 돌이켜보면 AI가 여러 번 잘못된 방향을 안내했던 것 같았다. 결국 될 때까지 내가 계속 묻고 요청하고 탐색해서 도달한 것이다.
문제가 풀릴 때까지 인간이 AI에게 계속 반복 요청해야 하는 걸까? 이게 내 오해인가, 현실인가?
물어봤더니 오해가 아니라 절반은 현실인데, 이유가 중요했다.
- AI는 승인 팝업이 떴는지 볼 수가 없다. 팝업은 내 화면에 뜨고, 대화 기록에는 승인 여부가 안 남는다. 고치려는 대상을 AI가 관측할 수 없었다.
- 그래서 이 문제에선 내가 유일한 센서였다. “또 떴어”라고 말해주지 않으면 AI는 고친 줄 알고 넘어간다. 실제로 “승인 0회 달성했습니다”라는 틀린 보고를 받고 내가 스크린샷으로 정정한 적도 있다.
반복을 줄이는 방법도 같이 배웠다.
| 방법 | 실제 차이 |
|---|---|
| 결과를 AI가 직접 볼 수 있게 만들기 | 발표 슬라이드는 “잘려 보이나요?” 묻는 대신 넘치는 높이를 프로그램으로 재게 했더니 한 번에 6장을 찾아 고쳤다. 승인 팝업은 잴 방법이 없어서 며칠 걸렸다 |
| ”다시 해봐” 대신 “왜 안 됐는지 먼저 찾아줘” | 원인 추적을 시키자 파이프라는 진범이 나왔다. 재시도만 반복하면 비슷한 답만 돌아온다 |
| 알아낸 걸 규칙으로 박아두기 | 다음 대화는 그 지점부터 시작한다 |
현실적인 목표는 “사람이 개입을 안 하는 것”이 아니라 “같은 걸 두 번 설명하지 않는 것”이었다.
재밌는 건, 이게 내가 만들던 에이전트와 똑같은 문제라는 점이다. 에이전트에 회로차단기와 덮어쓰기 방지를 넣은 것도 결국 “사람이 지켜보지 않아도 되게” 만든 거니까. 같은 문제를 양쪽에서 푼 셈이다. (실제로 이 주에 애써 모은 결과 577개를 0개로 덮어쓰는 사고도 겪었다 → 안전장치로 고친 이야기)
벽 3 — 그제야 보인 토큰
멈추지 않게 되고 나니 다음 문제가 드러났다. 실제로 재봤더니:
- 누적 토큰의 98%가 컨텍스트 재읽기였다. 새로 만든 글은 극히 일부.
- 대화가 길어지면서 회사 1곳 처리 비용이 8배로 뛰었다.
비용은 “얼마나 말했느냐”가 아니라 **“얼마나 쌓였고 그걸 몇 번 다시 읽었느냐”**로 정해진다. 그래서 도구 출력의 기본값을 요약으로 바꾸고(홈페이지 읽기 93% 감소), 회사 5곳마다 새 대화로 넘어가기로 했다.
그래서 100개를 포기했다 — 정확히는 목표를 바꿨다
숫자를 정하는 기준이 바뀐 것이다. 처음엔 “기계가 허락하는 최대”를 찾고 있었는데, 실제로 정한 건 이거였다.
하루에 이만큼 돌려도, 같은 도구로 다른 일을 할 여유가 남는 선.
API는 훨씬 많이 허락한다. 하지만 내 하루가 안 허락하면 그게 진짜 상한이다. 그래서 하루 10곳으로 정했다.
After — 지금 상태
매일 낮 12시, 회사 10곳을 알아서 조사해 시트에 기록하고 브리핑까지 올려준다.
| 주 초 | 주 말 | |
|---|---|---|
| 회사 1곳당 승인 | 여러 번 | 0회 |
| 회사가 늘어나면 | 승인도 비례해 증가 | 안 늘어남 |
| 사람이 있어야 하나 | 계속 앉아 있어야 함 | 자리를 떠도 됨 |
| 실행 방식 | 내가 불러야 돎 | 매일 정오 자동 |
마지막 줄이 이번 주의 결론이다. 처음으로, 내가 부르지 않아도 움직이는 게 생겼다.
그리고 주 초의 걱정 3개는 이렇게 정리됐다.
| 그때 걱정 | 지금 |
|---|---|
| 판별 방법이 부족하다 | 업종코드를 세분류까지 정밀화 → 오탐 4곳 제거 |
| 승인을 계속 눌러야 한다 | 0회 |
| 왜 차단되는지 모르겠다 | 총량이 아니라 순간 속도였음 |
걱정을 정확하게 적어둔 게 다음 할 일 목록이 됐다. 막연히 “잘 안 되네”로 넘어갔으면 뭘 고쳐야 할지 몰랐을 것이다.
📸 여기에 시트 화면과 브리핑 결과를 넣으면 좋아요
가져가서 쓸 것
자동화가 자꾸 멈춘다면 이 순서로 점검하세요.
- 명령에 파이프·반복문·셸변수를 붙이고 있지 않은가 → 붙일 이유를 없애기
- 사이트·파일마다 승인이 필요한 도구를 쓰고 있지 않은가 → 전용 스크립트로 대체
- 차단당했다면 개수만 줄이지 말고 간격을 두었는가
- 실패 시 재시도·중간저장이 있는가 (없으면 처음부터 다시)
- AI가 결과를 직접 확인할 방법이 있는가 → 없으면 내가 매번 봐줘야 한다
- 안 될 때 “다시 해봐” 대신 **“왜 안 됐는지 먼저 찾아줘”**라고 하고 있는가
목표를 정할 때 물어볼 것 — “기계가 얼마나 허락하나?”가 아니라 “내 하루가 얼마를 허락하나?”
다음에 해보고 싶은 것
업태 코드로 후보 기업을 회사명 + 사업자번호까지 먼저 전부 리스트업하고, 그다음 전체를 적은 토큰으로 scoring하는 방법을 찾아보고 싶다.
지금은 회사를 한 곳씩 깊게 조사하느라 비용이 크다. “넓게 얕게 먼저 → 좁혀서 깊게” 순서로 가면 훨씬 많은 후보를 감당할 수 있을 것 같다. 처음 그렸던 100개에 다가가는 길도 아마 여기일 것이다.
목표를 낮춘 게 아니라, 어디를 낮추고 어디를 지킬지 알게 된 주였다.
4주차
개념 — ICP(이상적인 고객 프로필), 그리고 왜 우리는 6개로 나눴나
프로젝트 문서 곳곳에 “잠재고객 프로필(ICP)“이라고 적혀 있는데, 이 세 글자가 뭔지 짚고 넘어간 적이 없어서 정리한다.
ICP = Ideal Customer Profile
우리말로 “이상적인 고객 프로필”.
우리 제품이 제일 잘 맞는 회사는 어떤 회사인지, 미리 그려둔 그림.
업종은 뭐고, 규모는 어느 정도고, 어떤 문제를 안고 있는 회사인지를 조건으로 적어두는 것이다. 왜 굳이 적어두냐면, 그래야 회사를 찾을 때 “이 조건에 맞나?”로 기계적으로 판단할 수 있기 때문이다.
느낌으로 “이 회사 괜찮아 보이는데”라고 하면 사람마다 답이 다르고, 무엇보다 스크립트가 판단할 수 없다. 이 프로젝트에서 상장기업 3,981개를 자동으로 걸러낼 수 있었던 것도, 프로필이 업종코드 같은 확인 가능한 조건으로 적혀 있었기 때문이다.
B2B 영업·마케팅에서 오래 쓰는 표준 용어라 그냥 써도 통한다.
헷갈리기 쉬운 것 — ICP는 “회사” 단위
| 단위 | 예시 | |
|---|---|---|
| ICP | 회사 | ”자체 R&D 조직이 있는 반도체 장비 제조사” |
| 바이어 페르소나 | 사람 | ”그 회사의 3D 설계팀장, 도입 예산 결재권 있음” |
둘 다 “누가 고객인가”를 그리지만 층이 다르다. 회사를 먼저 찾고(ICP), 그 안에서 누구에게 말을 걸지 정하는 것(페르소나) 순서다.
이 프로젝트는 ICP 단계까지만 한다. 담당자 개인 정보는 공공데이터에 없어서 처음부터 범위 밖으로 뒀다.
이 프로젝트에서 어떻게 쓰고 있나
프로필 6개(A~F)를 만들어두고, 회사를 시트에 넣을 때 어느 프로필에 해당하는지 같이 기록한다. 그래야 나중에 “D 프로필만 모아서 보기”가 가능하다.
우선순위도 매겨져 있다. 정부 메가프로젝트와 맞물린 D·E·F가 앞이고, A·C·B가 뒤다.
왜 6개로 나눴나 — 교과서와 다르게 간 부분
원래 ICP는 보통 하나로 정의한다. “우리의 이상적인 고객은 이런 회사다” 하고 한 장으로 정리하는 게 일반적이다.
그런데 이 프로젝트의 PRD엔 이렇게 적혀 있다.
“이런 회사가 잠재고객”을 하나로 뭉뚱그리지 않고, 여러 프로필로 다양하게 나눈다.
이유는 Day 10에 발견한 것 때문이다. 우리 제품을 둘러싼 회사가 성격이 완전히 다른 세 종류였다.
| 유형 | 어떤 회사 |
|---|---|
| ① 직접 고객 | 제품을 사서 자기가 쓰는 회사 |
| ② ISV·인티그레이터 파트너 | 이 제품으로 뭔가 만들어서 남에게 파는 회사 |
| ③ 서비스파트너·리셀러 | 도입을 대신 해주거나 되파는 회사 |
이 셋을 한 프로필로 묶으면 조건이 서로 모순된다. ①은 “자체 설계 조직이 있는가”를 보는데, ②는 “남의 제품으로 솔루션을 만들어 파는가”를 본다. 하나의 조건표로는 둘 다 못 거른다.
실제로 이걸 구분하지 못했을 때 자동차 딜러사를 잠재고객으로 잘못 넣는 일이 있었다. 딜러사는 셋 중 어디에도 안 들어가고, ②번 회사의 고객일 뿐이었다. 한 단계를 잘못 본 것이다.
정리
| 단어 | 쉬운 뜻 |
|---|---|
| ICP | Ideal Customer Profile. 우리 제품이 제일 잘 맞는 회사의 조건을 미리 적어둔 것 |
| 바이어 페르소나 | ICP가 회사 단위라면 이건 사람 단위. 그 회사에서 누가 구매를 결정하는지 |
| 프로스펙트 | 조건에 맞는지 확인까지 끝난 잠재고객. 그냥 후보 명단보다 한 단계 위 |
| 아웃바운드 | 이쪽에서 먼저 연락해 영업하는 방식. 반대는 고객이 찾아오는 인바운드 |
| ISV | Independent Software Vendor. 남의 제품·기술 위에 자기 소프트웨어를 만들어 파는 회사 |
한 줄로 남길 것 — ICP는 “좋은 고객”을 그리는 게 아니라, 기계가 판단할 수 있는 조건으로 옮겨 적는 일이다. 그래야 수천 개를 자동으로 거를 수 있다.
AI가 만든 발표 자료를 절반 넘게 다시 썼다 — 무엇이 어긋났나
한 줄 요약 — AI에게 발표 자료를 맡겼더니 사실은 다 맞는데 내가 하고 싶은 이야기가 아니었다. 절반 넘게 고치면서 알게 된 것.
이런 분께 — AI에게 발표 자료나 보고서 초안을 시켰는데, 틀린 건 없어 보이는데 자꾸 손이 가는 분.
Before — 재료는 다 있었다
4주 동안 만든 게 있었다. 학습일지 13편, 사례글 13편, 회고 4편, 스크립트 12개, 그리고 그날 정오에 실제로 돌아간 자동화 결과까지. 자료가 부족한 상황이 아니었다.
그래서 이렇게 부탁했다.
“4주 챌린지 발표 자료 만들자. B2B 리드젠 에이전트 프로젝트야.”
초안 9장이 나왔다. 예쁘고, 사실관계도 맞았다. 그런데 넘겨볼수록 이게 내 발표가 아니라는 느낌이 들었다.
무엇이 어긋났나 — 4가지
| AI 초안 | 내가 원한 것 |
|---|---|
| ”싸고 거칠게 많이 → 비싸고 정확하게 조금” 깔때기 그림 | 실제로 만든 다섯 단계 흐름 |
| ”잘 도는 것보다 잘 멈추는 게 어려웠다” 같은 문학적 표현 | 뭘 했는지 알 수 있는 기술적 서술 |
| AI가 고른 “제일 어려웠던 것” (오탐 회사 걸러낸 이야기) | 내가 실제로 힘들었던 것 (연결 오류, 승인 팝업) |
| 결과 표에 직원수·매출액 | 왜 잠재고객인지 · 뉴스 신호 |
전부 “틀린 것”이 아니라 “고른 것이 다른” 문제였다. 그래서 처음엔 뭐가 불편한지 말로 설명하기가 어려웠다.
어떻게 고쳤나 — 실제로 한 요청들
1) “이 슬라이드 설명해줘”가 뜻밖의 검증이 됐다
깔때기 슬라이드가 계속 걸렸다. 그래서 고치라고 하는 대신 이렇게 물었다.
“pg. 3 의 내용을 설명해줘. 잘 이해가 안되”
설명을 듣다가 사실관계 문제가 드러났다. 118,581 → 577 → 30으로 좁혀지는 그림이었는데, 확인해보니 시트의 30곳은 그 파이프라인을 타고 온 게 아니었다. 파이프라인은 만들어뒀지만 실제 흐름에 연결돼 있지 않았던 것이다.
고치라고 했으면 못 찾았을 것이다. “설명해줘”가 검증이 됐다.
📸 여기에 초안의 깔때기 슬라이드 스크린샷을 넣으면 좋아요
2) 톤을 정확히 지적했다
“현재 pg. 4 의 전반적인 표현이 너무 추상적이고 문학적인 표현이다. 실제로 무엇을 했는지는 알 수가 없다. 구체적으로 어떤 문제가 있었고, 어떻게 해결했는지 기술적인 내용으로 적어줘”
이 한 번의 요청으로 슬라이드가 완전히 바뀌었다. “잘 멈추는 게 어려웠다” 같은 문장이 증상 → 원인 → 고친 방법 표로 바뀌었고, 실제 명령어와 에러 문구가 들어갔다.
3) 내용은 내가 직접 줬다
“제일 어려웠던 것”은 AI가 고른 것과 내 기억이 아예 달랐다. 그래서 목록을 직접 적어줬다.
“pg. 8 제일 어려웠던 것은 1. 구글 MCP 설정을 클로드코드가 알려줘서 진행했는데, 처음에는 되었다가 며칠 뒤 에러 발생. 근본 원인을 못 찾음. 그래서 gws CLI로 해결 2. 기업 조사 과정에서 ‘허용’을 묻는 단계가 기업 1개당 3~4번. ‘완전 허용’은 위험하다고 해서 며칠 고민. 다시 논의하니 다른 해법을 알려줌 (다만 기술적인 내용이라 나는 충분히 이해 못 함)”
여기서 “나는 충분히 이해 못 함”까지 그대로 쓰라고 한 게 나중에 이 발표에서 제일 정직한 부분이 됐다.
4) 뺄 것을 정했다
- “pg. 11 전체 삭제” — AI가 결론이라며 만든 슬라이드
- “현재 pg. 8의 잘못된 기업 선정 fix 한 것은 일단 제외 (향후 improve 할 내용으로 넣고 싶어)” — 성과가 아니라 진행 중인 과제로 위치를 옮김
넣는 것보다 빼는 것에서 방향이 더 분명해졌다.
After
| 초안 | 최종 | |
|---|---|---|
| 장수 | 9장 | 12장 |
| 손댄 슬라이드 | — | 3~11번 (타이틀·마무리 빼고 거의 전부) |
| 무게중심 | 만든 것 자랑 | 어려웠던 것과 그 원인 |
| ”어려웠던 것” 분량 | 슬라이드 1장에 4칸 | 각각 한 장씩, 총 3장 |
그리고 고치는 과정에서 뜻밖의 소득이 있었다. 8월 3일부터 못 풀던 연결 오류의 원인을, 발표 자료를 만들며 기록을 다시 뒤지다가 찾았다. 그때는 “권한 오류”로만 보였던 게 사실은 테스트 상태 OAuth의 7일 토큰 만료였다.
가져가서 쓸 것
AI에게 발표 자료를 시키기 전에 정해줄 것
- 말하고 싶은 핵심 3가지 — 이게 없으면 AI가 “있는 재료 중 그럴듯한 것”을 고른다. 그건 내 기준이 아니다
- 제일 어려웠던 것 목록 — AI는 로그에 많이 남은 걸 고르지, 내가 밤에 잠 못 잔 걸 고르지 않는다
- 톤 — “문학적 vs 기술적”, “성과 중심 vs 과정 중심”을 미리 말한다
- 뺄 것 — 자랑하고 싶지 않은 것, 아직 진행 중인 것
- 듣는 사람 — 같은 내용도 대상에 따라 고르는 게 달라진다
초안을 받은 뒤 쓸 문장 두 개
이 슬라이드 내용을 설명해줘. 잘 이해가 안 돼.
→ 고치라고 하기 전에 이걸 먼저. 사실관계 오류가 드러난다.
표현이 너무 추상적이다. 실제로 뭘 했는지 알 수가 없다.
구체적으로 어떤 문제가 있었고 어떻게 해결했는지 기술적으로 적어줘.
→ 톤이 한 번에 바뀐다.
배운 것
AI 초안이 어긋난 건 재료 문제가 아니라 기준 문제였다. 사실은 전부 맞았다. 다만 그중 무엇을 앞에 둘지를 정하는 건 내 몫이었는데, 그걸 안 정해주고 시작한 게 절반을 다시 쓰게 만들었다.
그리고 고치면서 얻은 게 하나 더 있다. 내가 이 프로젝트에서 뭘 중요하게 생각하는지가 더 또렷해졌다. 초안을 그대로 썼으면 그건 몰랐을 것이다. 시간은 많이 썼지만 헛되지는 않았다.
다음에 발표 자료를 부탁할 땐, 만들어달라고 하기 전에 “내가 하고 싶은 말 세 줄”부터 써서 줄 생각이다.
AI알못이 4주 만에 매일 도는 에이전트를 만든 방법 — GPTers 23기 AI 온보딩 후기
한 줄 요약 — “공부부터 해야 쓸 수 있다”고 믿어서 켜보지도 못했던 클로드 코드로, 진도표를 따라 4주 동안 대화만으로 매일 정오에 혼자 도는 B2B 리드젠 에이전트를 만들었다.
이런 분께 — AI를 챗으로는 쓰는데 “코딩 도구”라는 이유로 클로드 코드는 시작도 못 하고 있는 AI 입문자.
Before — “공부하고 나서 써야 한다”고 생각했다
“클로드 코드는 코딩 도구니까, 사용법을 공부하고 나서 써야 한다.”
4주 전 내 생각이었다. 클로드는 챗으로만 썼고, 코워크는 써보기 시작했지만 클로드 코드는 아무것도 시도해 보지 않고 있었다. 코딩을 모르니 뭘 어떻게 물어봐야 할지조차 감이 안 왔다.
참가한 건 GPTers 23기 AI 온보딩 — AI가 처음인 사람을 위한 4주 챌린지다. 특정 주제를 정해주지 않는다. 각자 자유 주제를 정하고, 스터디장 아루나님이 만든 진도표와 가이드를 따라 클로드 코드와 대화하며 하나씩 만들어간다.
어떻게 — 매일 하나씩, 대화로만
1) 하루는 늘 같은 모양이었다
오늘의 가이드 → AI와 대화 → 하나 만든다 → 학습일지 → 사례글. 순서를 내가 정할 필요가 없었다. 오늘 뭘 만들지는 진도표가 알려줬고, 나는 “이걸 하고 싶어”라고 말만 하면 됐다.
2) 실제로 이렇게 진행됐다 — 가이드 ↔ 내가 만든 것
| 진도 | 가이드 | 내가 실제로 만든 것 |
|---|---|---|
| 1주 1일 | 나의 학습메이트 만들기 | 콩콩 — 말투와 행동 원칙까지 정한 AI 학습메이트 |
| 1주 2일 | 로드맵과 랜딩 페이지 | 책 목차로 시작했다가 3일 만에 갈아엎고 B2B 에이전트로 |
| 1주 3일 | 인터넷에 올리기 (배포) | 내 주소가 생김 — my-learning-hub-mu.vercel.app |
| 1주 5일 | 내 프로젝트 PRD 만들기 | AI가 하나씩 물어보게 해서 PRD 완성, 그 인터뷰를 스킬로 저장 |
| 2주 5일 | 바깥 기능 끌어오기 (API·MCP) | 공공데이터(OpenDART) 조회 + 구글시트 자동 기록 |
| 3주 1일 | 완성 기준 정하기 | ”회사 30곳과 걸러낸 2곳의 근거를 5분 안에 설명할 수 있으면 완성” |
| 3주 3일 | 반복하는 일을 AI에 넘기기 | 매일 정오에 10곳 조사하는 예약 실행 |
| 3주 4일 | 내가 만든 게 남한테도 되나 | 처음 보는 사람 시점으로 점검 → 막히는 지점 6개 발견 |
3) 막혔을 때 실제로 쓴 방법
4주 내내 막혔다. 도구가 갑자기 안 되고, 승인 창이 계속 뜨고, 데이터가 날아갔다. 그때마다 이 세 문장을 그대로 썼다.
이런 에러가 떴어. (화면 캡처를 붙여넣기만 해도 된다)
다시 해줘 대신 → 왜 안 됐는지 먼저 찾아줘
(그래도 안 풀리면) 그날 안에 다시 물어보기
막힘 → 해결: 실제로 겪은 세 가지
① 되던 게 며칠 뒤 안 됐다 구글시트 연결을 클로드 코드가 알려준 대로 **커스텀 커넥터(MCP)**로 설정했고 처음엔 됐다. 며칠 뒤 같은 설정인데 에러가 났고, 그땐 원인을 못 찾았다. → 다른 도구(gws CLI)로 우회해 해결했다. 원인은 나중에 발표를 준비하며 찾았다 — 테스트 상태 인증의 7일 만료였다.
② 회사 1곳당 ‘허용’을 3~4번 눌러야 했다
브라우저 도구는 사이트마다 승인을 요구했고, 허용해둔 명령도 **파이프(| head)**를 붙이면 문자열이 달라져 다시 막혔다. “전부 허용”은 위험하다고 해서 그대로 며칠 멈춰 있었다.
→ 승인 없이 되는 전용 스크립트로 대체하고, 명령을 감싸지 않고 그대로 호출. 결과 승인 0회 — 예약 실행이 가능해졌다.
③ 공공데이터가 나를 차단했다 빨리 끝내려고 동시에 8개씩 요청했다가 접속 자체가 막혔다. 가짜 키로도 같은 에러가 나는 걸 보고 **키가 아니라 접속 자체(순간 속도)**가 원인임을 확인했다. → 동시 1개(순차) + 요청 간 딜레이 700ms + 실패 시 재시도. 속도를 올리면 자동화가 오히려 멈춘다.
셋 다 코드를 몰라서 막힌 게 아니었다. 원인을 찾고 다음 수를 정하는 과정이었고, 그건 전부 대화로 했다.
After — 매일 정오, 사람 없이 10곳이 들어온다
| Before (4주 전) | After (지금) | |
|---|---|---|
| 클로드 코드 사용 | 켜본 적 없음 | 매일 대화로 운영 |
| 잠재고객 조사 | — | 매일 정오 10곳 자동 |
| 조사할 때 승인 | — | 0회 |
| 오늘 쓴 공공데이터 호출 | — | 42 / 300 |
| 시트에 쌓인 회사 | 0 | 40곳 |
우선순위대로 D→E→F→A→C→B 순서로 정확히 순환했다. 설계한 대로 결과가 나온 걸 눈으로 확인한 순간이었다.
📸 여기에 정오 자동 실행 결과 화면이나 구글시트 캡처를 넣으면 좋아요
배운 것 — 이해가 먼저가 아니라 경험이 먼저였다
공부 → 사용이 아니라 사용 → 이해였다. 솔직히 지금도 클로드 코드가 뭔지 다 이해하진 못했다. 그런데 결과물 하나를 만들었기 때문에 친밀감이 생겼고, 앞으로도 이렇게 쓰면 되겠다는 자신감이 조금 생겼다.
혼자였으면 흐지부지됐을 것이다. 스터디장님의 체계와 일정표, 스터디원들의 공유와 격려가 건강한 채찍질이 됐다. 그리고 학습허브 사이트에서 가이드받고 기록을 남기니 프로젝트 칸반·위키·전자책이 저절로 쌓였다. 완성물 하나를 경험하고 나니, 앞으로도 혼자 나아갈 자신감과 체계를 둘 다 갖게 됐다.
가져가서 쓸 것
AI 입문자가 클로드 코드를 시작할 때 체크리스트
- 코딩 몰라도 된다. “이걸 만들고 싶어”라고 말로 시작하면 된다
- 처음엔 작은 것 하나부터 (학습메이트, 랜딩페이지 등) — 완성 경험이 먼저다
- 막히면 “다시 해줘” 대신 “왜 안 됐는지 먼저 찾아줘”
- 그래도 안 풀리면 포기하지 말고 그날 안에 다시 물어보기
- 혼자보다 정해진 진도표 + 함께하는 사람이 있으면 훨씬 오래간다
지난 한 달, 체계를 만들어 이끌어 주신 스터디장 아루나 님께 감사드립니다.
4주 회고 — "공부 먼저 해야 쓸 수 있다"고 믿었다
한 줄 요약 — 4주 전엔 클로드 코드를 켜보지도 못했다. 코딩 도구니까 공부를 먼저 해야 쓸 수 있다고 생각했기 때문이다. 4주 뒤, 매일 정오에 혼자 도는 에이전트가 생겼다.
이런 분께 — AI 도구를 앞에 두고 “이건 배우고 나서 써야지” 하며 미루고 있는 분.
4주 전의 나
클로드는 챗만 썼다. 클로드 코드는 아예 사용도 못 했다.
이유가 있었다. 코딩과 관련된 것이니 챗과는 다른 사용법이 있을 것이고, 그게 뭔지 공부를 먼저 해야 쓸 수 있다고 생각했다. 그래서 켜보지도 않았다.
첫날 기록에 이런 게 남아 있다 — AI가 “파일에 저장했어요”라며 링크를 줬는데, 그 링크가 내 컴퓨터에서 안 열려서 한참 헤맸다. 채팅 속 링크가 실제 파일이 아니라는 걸 그때 처음 알았다.
4주 동안 무슨 일이 있었나
| 주차 | 무슨 일이 있었나 | 그 주에 고친 것 |
|---|---|---|
| 1주차 | 책 목차로 시작했다가 3일 만에 로드맵을 통째로 갈아엎었다 | 주제 |
| 2주차 | 2주치 계획을 하루에 끝냈다. 그런데 스케일업의 벽이 보였다 | 규모에 대한 생각 |
| 3주차 | 걱정 3개(판별·승인·차단)로 시작해 매일 도는 에이전트로 끝냈다 | 목표 수치 (100개 → 하루 10곳) |
| 4주차 | 발표 준비가 검증이 됐고, AI 초안을 절반 넘게 다시 썼다 | 발표에서 할 이야기 |
관통하는 게 하나 있다. 매주 “계획대로 됐다”가 아니라 **“계획을 고쳤다”**였다. 주제를, 규모를, 수치를, 이야기를 — 매주 뭔가를 바꿨다.
처음엔 그게 실패처럼 느껴졌는데, 지금 보니 고칠 수 있을 만큼 구체적으로 만들어봤기 때문에 고칠 수 있었던 것이다.
무엇이 바뀌었나 — 순서가 뒤집혔다
이번 4주에서 제일 크게 배운 건 기술이 아니라 순서다.
클로드 코드도 클로드 챗처럼 대화를 나누며 목표를 세우고, 그 목표를 위해 한 단계씩 같이 만들고 문제를 해결하면 결과물이 나온다.
공부 → 사용 이 아니라 사용 → 이해였다. 그리고 솔직히 말하면 지금도 클로드 코드가 뭔지 제대로 이해한 건 아니다.
그런데 4주 동안 결과물 하나를 만들었기 때문에, 경험을 통한 친밀감이 생겼고 앞으로도 이런 식으로 더 쓰면 되겠다는 자신감이 생겼다.
이해가 먼저가 아니라 경험이 먼저였다. 이게 4주의 결론이다.
만든 것
| 리드 시트 | 40곳 (유효 38 + 제외 판정 2), ICP 프로필 6개 전부 채움 |
| 자동 실행 | 매일 낮 12시, 사람 없이 10곳씩 |
| 회사 1곳당 승인 | 0회 |
| 직접 만든 것 | 스크립트 12개 · 반복 작업을 담은 스킬 8개 |
| 기록 | 공개 글 23편 · 학습일지 13편 |
| 사이트 | 이 학습허브를 직접 만들어 배포 |
다시 한다면 — 한 가지
승인 팝업 때문에 며칠 멈춰 있던 것.
“완전 허용은 위험하다”는 답을 듣고 맞는 말이라 그대로 멈췄다. 그런데 그 자리에서 더 집요하게 파고들었다면 훨씬 빨리 풀렸을 것 같다. 나중에 같은 문제를 다시 꺼내 논의했더니 다른 해법이 나왔고, 승인은 0회가 됐다.
포기하지 않고 다시 물은 것이 유일한 차이였다. 그걸 며칠 뒤가 아니라 그날 했으면 됐다.
이건 3주차에 배운 것과 정확히 이어진다 — “현실적인 목표는 사람이 개입을 안 하는 것이 아니라, 같은 걸 두 번 설명하지 않는 것.” 여기에 하나를 더 붙이고 싶다.
첫 답이 막다른 길이면, 그날 다시 물어라.
나머지는 겪어야 했던 시간이라고 본다. 로드맵을 갈아엎은 것도, 연결 오류로 돌아간 것도, 발표 초안을 다시 쓴 것도 — 그 과정에서 내가 뭘 중요하게 생각하는지가 또렷해졌다.
남은 것
- 후보 발굴이 아직 웹검색에 기대고 있다. 업태 코드로 회사명·사업자번호까지 먼저 리스트업하고, 전체를 적은 토큰으로 scoring하는 쪽으로 가고 싶다
- 아직 나만 쓸 수 있는 도구다. 시트 도구 설치 안내·승인 규칙·실명 검사가 전부 내 컴퓨터에만 있다
- 판별 정확도는 넓히면 오탐 · 좁히면 누락 사이를 아직 더듬는 중이다
4주 전엔 켜보지도 못한 도구로, 지금은 내가 자는 동안에도 도는 걸 만들었다. 여전히 다 이해하지는 못한 채로.
그래도 괜찮다는 걸 알게 된 게, 이번 4주의 제일 큰 수확이다.
4주 회고 — 스터디그룹과 학습허브가 준 체계
🧭 발표 슬라이드 — “AI알못, 클로드 코드와 대화로 만들었다” (11장) 이 회고는 위 발표 자료의 내용을 정리한 것이다.
한 줄 요약 — 결과물(B2B 에이전트) 자체보다, 그걸 만들 수 있게 한 체계가 이번 4주의 진짜 소득이었다.
시작할 때 저를 막고 있던 것
“클로드 코드는 코딩 도구니까, 사용법을 공부하고 나서 써야 한다.”
4주 전 내 생각이었다. 그래서 켜보지도 않았다. 클로드는 챗으로만 썼고, 코워크는 써보기 시작했지만 클로드 코드는 코딩을 좀 공부한 후에 쓸 수 있는 것이라 생각하고 아무것도 시도해 보지 않고 있었다.
GPTers 23기 · AI 온보딩이라는 틀
이 스터디는 AI가 처음인 사람들을 위한, 코딩 없이 매일 하나씩 만들며 배우는 4주 챌린지다. 특정 주제를 정해주지 않는다. 각자 자유 주제를 정하고, 스터디장 아루나님이 만든 진도표와 가이드를 따라 클로드 코드와 대화하며 하나씩 만들어간다.
| 주차 | 배우며 만드는 것 | 손에 남는 것 |
|---|---|---|
| 1주차 · 기획 | 학습메이트 → 로드맵·랜딩 → 배포 → PRD·세부계획 → MVP 첫 조각 | 살아있는 내 사이트 + 시작된 프로젝트 |
| 2주차 · 제작 | MVP 본격 만들기 + 개념페이지 쌓기 | 작동하는 MVP + 프로젝트 카드 |
| 3주차 · 완성 | MVP 완성·다듬기 + 반복작업 자동화 | 완성된 MVP |
| 4주차 · 회고·발표 | 한 달 돌아보고 발표, 전자책 마무리 | 학습허브 + 포트폴리오 + 전자책 1권 |
하루는 늘 같은 모양으로 굴러갔다. 오늘의 가이드 → AI와 대화 → 하나 만든다 → 학습일지 → 사례글. 이 글들이 위키에 쌓여 4주 뒤 전자책이 됐다. 나는 이 루틴을 학습일지 13편, 공개글 24편으로 채웠다.
가이드가 시킨 것 ↔ 내가 실제로 만든 것
진도표는 방향만 줬다. 실제로 뭘 만들지는 내 몫이었다.
| 진도 | 가이드 | 내가 실제로 만든 것 |
|---|---|---|
| 1주 1일 | 나의 학습메이트 만들기 | 콩콩 — 말투와 행동 원칙까지 정한 AI 학습메이트 |
| 1주 2일 | 로드맵과 랜딩 페이지 | 책 목차로 시작했다가 3일 만에 갈아엎고 B2B 에이전트로 |
| 1주 3일 | 인터넷에 올리기 (배포) | 내 주소가 생김 — my-learning-hub-mu.vercel.app |
| 1주 5일 | 내 프로젝트 PRD 만들기 | AI가 하나씩 물어보게 해서 PRD 완성, 그 인터뷰를 스킬로 저장 |
| 2주 5일 | 바깥 기능 끌어오기 (API·MCP) | 공공데이터(OpenDART) 조회 + 구글시트 자동 기록 |
| 3주 1일 | 완성 기준 정하기 | ”회사 30곳과 걸러낸 2곳의 근거를 5분 안에 설명할 수 있으면 완성” |
| 3주 3일 | 반복하는 일을 AI에 넘기기 | 매일 정오에 10곳 조사하는 예약 실행 |
| 3주 4일 | 내가 만든 게 남한테도 되나 | 처음 보는 사람 시점으로 점검 → 막히는 지점 6개 발견 |
| 4주 1일 | 최종 발표 | 이 발표 |
막혔을 때는 어떻게 했나
4주 내내 막혔다. 도구가 갑자기 안 되고, 승인 창이 계속 뜨고, 데이터가 날아갔다. 코딩으로 푼 게 아니라 대화로 풀었다.
- 증상을 그대로 말한다 — “이런 에러가 떴어”, 화면을 캡처해 붙여넣기만 해도 된다
- 원인을 찾게 시킨다 — “다시 해봐”가 아니라 “왜 안 됐는지 먼저 찾아줘”
- 안 풀리면 다시 묻는다 — 첫 답이 막다른 길이면 그날 다시 꺼낸다
제일 아쉬운 지점도 여기 있다. 승인 창 문제로 며칠을 멈춰 있었는데, 그날 더 집요하게 물었으면 훨씬 빨리 풀렸을 것이다. 기술이 아니라 다시 묻는 것이 관건이었다.
여기서부터 내 프로젝트 — B2B Sales Lead 에이전트
회사에서 잠재고객을 찾는 일은 마케팅 에이전시에 회사 1곳당 약 1,500원을 주고 맡겨왔다. 아웃바운드 콜 1,000개면 1천5백만원이다. 기업DB를 사도 결국 사람이 홈페이지를 하나씩 열어 확인해야 했다. 그 반복을 AI에게 넘기고 싶었다.
다섯 단계로 만들었다
- 솔루션 학습 — 직접 쓰는 고객과 이 제품으로 만들어 파는 파트너를 구분
- 고객 프로필 6개 — 업종·규모·시그널 조건표(ICP) + 업종코드 판별 규칙 + 정성 체크리스트
- 후보 탐색 — “회사 N개 찾아줘” → 비어 있는 프로필부터 우선순위 순으로
- 검증하고 기록 — 공공데이터·홈페이지·뉴스로 확인 → 근거·출처와 함께 시트 한 줄로
- 매일 정오 10곳 — 조사부터 시트 기록, 브리핑까지 사람 없이
1·2는 한 번 세우면 계속 쓰이고, 3~4가 회사마다 반복되는 부분이다. 5는 그 반복을 나 없이 돌게 만든 것이다.
매일 정오, 사람 없이 10곳이 들어온다
시트 40곳, 승인 0회, 오늘 쓴 공공데이터 호출 42/300, 예약 실행 시각 12:03. 우선순위대로 D→E→F→A→C→B 순서로 정확히 돌았다.
가장 어려웠던 세 가지
1. 되던 게 며칠 뒤 안 됐다
구글시트 연결을 클로드 코드가 알려준 대로 **커스텀 커넥터(MCP)**로 설정했고 처음엔 됐다. 며칠 뒤 같은 설정인데 에러가 났고, 그땐 원인을 못 찾았다.
→ 다른 도구(gws CLI)로 우회해 해결. 원인은 발표를 준비하며 찾았다 — 테스트 상태 인증의 7일 만료였다.
2. 회사 1곳당 ‘허용’ 3~4번
브라우저 도구는 사이트마다 승인을 요구했고, 허용해둔 명령도 **파이프(| head)**를 붙이면 문자열이 달라져 다시 막혔다. “전부 허용”은 위험하다고 해서 그대로 멈춰 있었다.
→ 승인 없이 되는 전용 스크립트로 대체하고, 명령을 감싸지 않고 그대로 호출. 결과 승인 0회 — 예약 실행이 가능해졌다.
3. 공공데이터가 나를 차단했다
빨리 끝내려고 동시에 8개씩 요청했다가 접속 자체가 막혔다. 가짜 키로도 같은 에러가 나는 걸 보고 **키가 아니라 접속 자체(순간 속도)**가 원인임을 확인했다.
→ 동시 1개(순차) + 요청 간 딜레이 700ms + 실패 시 재시도. 속도를 올리면 자동화가 오히려 멈춘다.
셋 다 코드를 몰라서 막힌 게 아니었다. 원인을 찾고 다음 수를 정하는 과정이었고, 그건 전부 대화로 했다.
”내 학습허브”가 지속적인 학습메이트가 되어
뒤집힌 순서
공부 → 사용이 아니라 사용 → 이해였다. 지금도 다 이해하진 못했지만, 결과물 하나를 만들었기 때문에 자신감이 생겼다.
스터디그룹의 힘
혼자였으면 흐지부지됐을 것이다. 스터디장님의 체계와 일정표, 스터디원들의 공유와 격려가 건강한 채찍질이 됐다.
학습허브의 체계
가이드받고 기록을 남기면 프로젝트 칸반·위키·전자책이 쌓인다. 완성물 하나를 경험하고 나니, 앞으로도 혼자 나아갈 자신감과 체계를 둘 다 갖게 됐다.
지난 한 달, 체계를 만들어 이끌어 주신 스터디장 아루나 님께 감사드립니다.