🎯 4주 챌린지 최종 발표 슬라이드 (12장) — 2026-08-13 발표 왜 만들었나 · 다섯 단계로 만든 과정 · 제일 어려웠던 세 가지와 그 원인 · 오늘 정오 첫 자동 실행 결과
🧭 발표 슬라이드 — “AI알못, 클로드 코드와 대화로 만들었다” (11장) — 2026-08-14, GPTers 23기 AI 온보딩 관점 버전 절반은 학습허브 프레임워크(진도표·가이드↔결과물) · 절반은 이 프로젝트의 구조와 결과물
4주 챌린지 기간 — 1주차 기획(7/23~7/29) · 2주차 제작(7/30~8/5) · 3주차 완성(8/6~8/12) · 4주차 회고·발표(8/13~8/17) 매일 학습일지를 쓰고, 그중 보여줄 만한 걸 사례글로 다듬어 아래 작업 기록에 쌓았다.
지금 상태 (2026-08-13 기준)
매일 낮 12시에 사람 없이 회사 10곳을 조사해 구글시트에 채운다. 오늘이 첫 자동 실행이었고, 30곳 → 40곳이 됐다.
| 시트에 쌓인 회사 | 40곳 (유효 38 + 제외 판정 2) |
| 회사 1곳당 승인 | 0회 — 사람이 자리를 떠도 진행된다 |
| 오늘 API 사용 | 42회 / 상한 300회 |
| 프로필 순환 | 우선순위대로 D→E→F→A→C→B 순서로 돌았다 |
이걸 1차 완성으로 본다. 다만 아래 두 가지는 분명히 해둔다.
- 후보를 “떠올리는” 단계는 아직 웹검색에 기대고 있다. 대량 스크리닝 파이프라인(
bulk-screen→score-candidates)은 만들어뒀지만 일상 흐름에는 아직 연결돼 있지 않다. 시트의 40곳은 프로필별로 한 곳씩 조사해 들어온 것이다. - 하루 10곳으로 정한 기준은 API 한도가 아니라 토큰 예산이다. 10곳이면 API는 44회로 여유가 많다. 이만큼 돌려도 같은 도구로 다른 일을 할 여유가 남는 선을 택했다.
무엇을
회사의 특정 솔루션(○○ 솔루션, 사명 비공개)을 에이전트가 이해하고, 그 솔루션에 맞는 잠재고객 프로필을 스스로 세운 뒤, 그 프로필에 맞는 한국 회사를 찾아내고 정보를 검증·보강해 구글시트에 채워주는 미니 에이전트.
이 에이전트의 핵심은 이메일 작성이 아니라 “제대로 된 잠재고객을 찾아내는 것”이다. 아래 기능 요구사항도 이 순서(난이도 높은 순)로 정리했다.
왜
지금까지는 잠재고객 조사를 마케팅 에이전시에 회사 1개당 약 1,500원 단가로 (예를 들어 1,000개 outbound call을 진행하면 1천5백만원을 지불) 아웃소싱을 했었다. 또는 기업DB를 수십만원을 주고 산 후, 사람이 회사 홈페이지를 일일이 방문해 정보를 보완해왔다. 비용이 크고 정보도 금방 낡는다. 반복되는 조회·필터링·입력 작업을 AI가 대신하게 하고 싶다.
누구를 위해
체이스 혼자 쓰는 개인 도구. (→ 4주 로드맵에서 이미 정한 내용)
어떻게 (기능 요구사항 — 난이도 높은 순)
1. ○○ 솔루션 이해
에이전트가 잠재고객을 찾기 전에, 먼저 ○○ 솔루션이 어떤 문제를 풀어주는 제품인지, 어떤 회사에 value add가 되는지를 학습한다. 이 이해가 얕으면 뒤의 모든 단계(프로필 설정·후보 발굴)가 다 부정확해진다.
2. 잠재고객 프로필(ICP) 여러 개 설정 — 하나로 뭉뚱그리지 않기
“이런 회사가 잠재고객”을 하나로 뭉뚱그리지 않고, 여러 프로필로 다양하게 나눈다. (예: “제조업 중 스마트팩토리 막 도입 시작한 곳” / “이미 경쟁 솔루션을 쓰고 있어서 교체 수요가 있는 곳” 처럼 프로필마다 노리는 각도가 다를 수 있음) 각 회사가 시트에 채워질 때 어느 프로필에 해당하는지도 같이 남긴다.
3. 후보 회사 발굴 + 정보 검증·보강(enrich) — 이 프로젝트에서 제일 어려운 부분
처음엔 “회사명을 입력하면 조회”로 계획했지만, 에이전트가 후보를 직접 찾고, 찾은 정보를 검증·보강까지 해야 한다는 게 확정됨. 어려운 이유는 공개된 정보만으로는 한계가 있어서 — 공공데이터만으로는 “진짜 이 회사가 잠재고객이 맞는지”까지 판단하기 부족하다. 그래서 여러 단계로 교차 확인한다.
- 1차 리스트업: 공공데이터(업종·규모 조건)로 프로필에 맞는 후보 회사를 넓게 뽑는다.
- 홈페이지 확인: 후보 회사의 홈페이지에 들어가 실제 사업 내용이 프로필과 맞는지 확인한다.
- 뉴스 검색으로 보강: 그 회사가 언급된 뉴스를 검색해 최신 동향(투자·신사업·이슈 등)으로 정보를 검증·보강한다.
- 이 세 단계를 거쳐야 “그럴듯한 회사 목록”이 아니라 제대로 된 prospect가 나온다.
실행 규칙:
- 실행할 때마다 먼저 “몇 개 회사를 추가로 찾아드릴까요?”라고 체이스에게 물어봄
- 이미 시트에 있는 회사는 중복해서 다시 찾지 않음
4. 구글시트에 정보 채우기 — 많을수록 좋음
정보는 최대한 많이 채운다. 특히 “어디서 이 정보를 얻었는지”의 출처를 항상 URL과 함께 별도 컬럼으로 남긴다 (나중에 사람이 직접 확인할 수 있어야 하므로).
| 구분 | 항목 |
|---|---|
| 기본 정보 | 회사명 · 업종 · 주소 · 사업자상태 |
| 규모 정보 | 직원수 · 매출액 · 설립일 |
| 잠재고객 프로필 | 어느 ICP 프로필에 해당하는지 + 왜 이 회사가 잠재고객인지 한 줄 설명 |
| 공공데이터 출처 | 어떤 데이터셋/API에서 가져왔는지 + 출처 URL (별도 컬럼) |
| 홈페이지 정보 | 홈페이지에서 확인한 사업 내용 요약 + 홈페이지 URL (별도 컬럼) |
| 뉴스 보강 정보 | 검색으로 찾은 관련 뉴스 요약 + 뉴스 URL (별도 컬럼) |
| 담당자 연락처 | 이번 4주는 보류 — 빈 칸 또는 “수동 확인 필요”로 표시 (공공데이터엔 없는 개인정보라 다음 단계 과제) |
5. 실행 방식
체이스가 콩콩과의 대화창에서 말로 요청한다. (예: “회사 5개 더 찾아줘”) 터미널 명령어를 몰라도 됨.
구현 방법 — 2026년 7월 기준 조사
가장 쉽고 많이 쓰는 최신 방식을 조사한 결과, 두 가지 선택지가 있었다.
- 구글시트 MCP 서버 연결 ← 선택 구글 클라우드에서 서비스 계정을 만드는 1회성 설정(~20분, 콩콩이 대부분 진행)만 하면, 이후엔 클로드 코드에게 “이 데이터 시트에 추가해줘”처럼 자연어로 말만 하면 됨. 클로드 코드를 직접 다루는 학습 목표와도 맞음.
- 완전 노코드 관리형 커넥터 (Composio·Porter 등) 가입 → 구글 계정 인증 → URL 복사해서 붙여넣기. 설정은 제일 쉽지만, 구글 접근 권한을 외부 서비스에 한 번 더 맡기게 되어 이번엔 선택하지 않음.
공공데이터 API(data.go.kr, OpenDART 등) 조회는 전용 MCP가 없어서, 클로드 코드로 직접 스크립트를 짠다.
참고 자료
- Google Sheets MCP Integration with Claude Code | Composio
- How to connect Google Sheets MCP with Claude Code
- Step-by-Step: Connect Claude to Google Sheets Using MCP (No Code, 2026)
재확인 (2026-07-30, 세부계획 세우기 전 다시 조사)
세부계획을 짜기 전에 “지금도 이게 제일 맞는 선택인지” 다시 조사했다. 결론: 직접 연결을 그대로 유지. 다만 요즘 나오는 튜토리얼은 Composio·Merge 같은 관리형 커넥터(외부 회사가 구글 인증을 대신 보관·관리) 쪽이 더 많다는 걸 확인했다 — 설정은 10~30분으로 더 짧지만, 구글 접근 권한을 외부 회사에도 주게 된다. 체이스는 이 트레이드오프를 다시 확인한 뒤 직접 연결을 재확정했다. 구글 클라우드 콘솔의 정확한 클릭 순서는 지금 미리 적어두지 않는다 — 설치 방법은 자주 바뀌므로, 실제 진행하는 날 콩콩이 최신 공식 문서로 다시 확인하며 안내한다.
추가 참고 자료
- Feature Request: Built-in Google Sheets connector · Issue #34953 · anthropics/claude-code
- Google Sheets connector for Claude (MCP) — Porter Metrics
- Claude + Google Sheets: What the Integration Can (and Can’t) Do in 2026
- Native Connector vs. MCP: Which Google Sheets Integration Does Your Workflow Actually Need?
결과 — 계획은 MCP였지만, 실제로는 gws CLI를 쓴다 (2026-08-13 정리)
위에서 고른 건 MCP 서버 연결이었는데, 실제 운영은 gws CLI로 하고 있다. 두 단계로 그렇게 됐다.
| 시점 | 무슨 일 |
|---|---|
| 8/3 | MCP 서비스계정 방식이 권한 오류로 막혀 어쩔 수 없이 gws로 우회 (원인은 위 Day 1 참고) |
| 8/12 | 승인 0회를 만들면서 의도적으로 gws를 전용 스크립트 안에 가두는 쪽을 선택 |
결과적으로 CLI 쪽이 더 안전해졌다. 이유는 세 가지다.
- 시트 하나로 묶인다 —
agent/sheet-write.mjs에 시트 ID가 박혀 있어 다른 시트는 건드릴 수 없다. MCP 도구는 어느 시트든 쓸 수 있어서 매번 승인이 필요했다. - 안전장치를 붙일 자리가 생긴다 — 값이 있는 행이면 거부, 17칸이 아니면 거부, 쓴 뒤 다시 읽어 검증. 스크립트 안이라 가능한 것들이다.
- 승인 0회 — 규칙 한 줄(
Bash(node agent/sheet-write.mjs *))로 허용된다.
다만 한계가 분명하다.
gws는 이 컴퓨터에 설치·로그인돼 있어서 동작하는 것이다. 이 에이전트를 남에게 넘기려면 그 설치 안내부터 만들어야 한다. (mcp-gsheets는1.10.0으로 버전 고정한 채 남아 있지만 이 흐름에서는 호출하지 않는다 — 8/11에 자동 업데이트된 1.10.1이 세션을 통째로 죽인 뒤 고정해둔 것)
세부계획 — 실행 계획 (2026-07-30 작성, 2026-08-04 3주차 추가)
로드맵의 “만들기” 부분(1주차 나머지 + 2주차)을 하루 단위로 잘게 쪼갠 것. 이전 단계 결과가 다음 단계 재료가 되도록 순서를 짰고, PRD의 “난이도 높은 순” 기능 요구사항을 실행 순서로 풀어냈다.
진행 상황 (2026-08-03 기준): Day 1~9 전부 완료. 원래 2주(근무일 기준)로 잡았던 계획을 하루 만에 다 끝냄.
로드맵 1주차 나머지 — 기반 세팅 + 이해·설계
Day 1 — 구글시트 MCP 서버 연결 세팅 ✅ 완료 (2026-08-03)
- 목표: 클로드 코드가 체이스의 구글시트에 직접 읽고 쓸 수 있게 연결
- 할 일: 구글 클라우드 프로젝트 생성 → 구글시트 API 활성화 → 전용 “서비스 계정” 만들기 → 그 계정에 시트 공유 → 클로드 코드에 MCP 서버로 등록 (콩콩이 대부분 진행, 체이스는 권한 팝업만)
- 완료 확인: 빈 구글시트에 클로드가 테스트로 아무 값이나 써넣는 데 성공
- 실제로는: 계획한 MCP 서비스계정 방식이 계속 권한 오류로 막혀서, 로컬에 이미 인증돼 있던
gwsCLI로 우회해서 완료함
⚠️ 원인 규명 (2026-08-13 추가) — 그때는 root cause를 못 찾았는데, 발표 자료를 만들며 기록을 다시 뒤져 찾았다. 두 가지가 겹쳐 있었다.
① 서비스 계정에 시트가 공유되지 않음. 남아 있는 에러 메시지가 그대로 말하고 있었다 —
Error: Permission denied / Please ensure the service account has access to the spreadsheet.MCP는 내 계정이 아니라 별도의 로봇 계정으로 접속하고, 그 계정에 공유되지 않은 시트는 존재하지 않는 것과 같다.② “테스트” 상태 OAuth의 7일 토큰 만료. 게시 상태가 테스트인 OAuth 클라이언트의 갱신 토큰은 7일 뒤 만료된다(구글 공식). 8/1 기록에 동의 화면·테스트 사용자 추가 작업이 남아 있으니 테스트 상태였다는 뜻이다. 8/11에도
Token has been expired or revoked가 재발했다.왜 그때 못 찾았나 — 화면에 뜬 건 “권한 오류”인데 실제로 바뀐 건 설정이 아니라 시간이었다. 로그 어디에도 “며칠이 지나서”라고 적혀 있지 않다. 근본 해결은 OAuth를 프로덕션으로 전환하거나 서비스 계정에 시트를 공유하는 것.
Day 2 — 공공데이터 API 키 발급 ✅ 완료 (2026-08-03)
- 목표: 회사 정보를 조회할 데이터 출처 확보
- 할 일: 공공데이터포털(data.go.kr) 회원가입 + 기업정보 API 인증키 발급, OpenDART 오픈API 키 발급
- 완료 확인: 두 사이트 다 인증키를 받아서 안전하게 기록해둠
Day 3 — ○○ 솔루션 이해 정리 ✅ 완료 (2026-08-03)
- 목표: 에이전트가 뭘 판매하는 건지 제대로 알기 (기능 요구사항 1번)
- 할 일: 콩콩과 함께 ○○ 솔루션 소개자료·웹사이트를 같이 살펴보고, “이 솔루션이 어떤 문제를 풀어주는지” 한 페이지로 정리
- 완료 확인: 정리한 내용을 체이스가 읽고 “맞다” 확인
- 실제로는: 체이스가 갖고 있던 2026 트렌드 리포트(PDF)까지 같이 읽어서, 실제 고객 성공사례 13개까지 반영해 강화함
Day 4 — 잠재고객 프로필(ICP) 여러 개 설정 ✅ 완료 (2026-08-03)
- 목표: “이런 회사가 잠재고객”을 다양한 각도로 나누기 (기능 요구사항 2번)
- 할 일: Day 3 정리를 바탕으로 프로필 2~3개 확정 (업종·규모·특징까지)
- 완료 확인: 프로필별 조건표 완성
- 실제로는: 정부 3대 메가프로젝트(반도체 인프라·AI 데이터센터·Physical AI)까지 반영해 6개 프로필·우선순위로 확정함
Day 5 — 공공데이터로 1차 리스트업, 회사 1개로 첫 성공 ✅ 완료 (2026-08-03)
- 목표: 프로필 조건에 맞는 후보를 실제로 찾는 첫 성공 (로드맵의 “MVP 첫 성공”과 같은 목표)
- 할 일: 클로드 코드로 공공데이터 API 호출 스크립트 작성, 회사 1개 검색해서 정보 가져오기까지 성공
- 완료 확인: 회사 1개의 기본정보(업종·주소·사업자상태 등)를 화면에서 확인
- 실제로는:
agent/opendart-lookup.mjs스크립트로 한미반도체(프로필 D) 기본정보 조회 성공
로드맵 2주차 — 시트 자동화 + 정보 보강
Day 6 — 구글시트에 기본 정보 자동으로 채우기 ✅ 완료 (2026-08-03)
- 목표: Day 5의 결과를 구글시트에 자동으로 쓰기
- 할 일: 기본정보·규모정보 컬럼 + “공공데이터 출처/URL” 컬럼까지 자동 채우기 연결
- 완료 확인: 회사 1개 정보가 시트 한 줄에 자동으로 채워짐
Day 7 — 홈페이지 확인 단계 추가 ✅ 완료 (2026-08-03)
- 목표: 후보 회사가 진짜 프로필에 맞는지 검증 (기능 요구사항 3번)
- 할 일: 후보 회사 홈페이지를 클로드가 방문해 사업 내용 확인, “홈페이지 정보/URL” 컬럼 채우기
- 완료 확인: 시트에 홈페이지 요약과 링크가 채워짐
Day 8 — 뉴스 검색으로 정보 보강 ✅ 완료 (2026-08-03)
- 목표: 정보를 한 번 더 검증·보강
- 할 일: 회사 관련 뉴스 검색 → “뉴스 보강 정보/URL” 컬럼 채우기
- 완료 확인: 시트에 뉴스 요약과 링크가 채워짐
Day 9 — 여러 회사로 확장 + 중복 방지 ✅ 완료 (2026-08-03)
- 목표: 5~10개 회사를 한 번에 처리
- 할 일: “몇 개 찾아드릴까요?” 질문 흐름 붙이기, 이미 시트에 있는 회사는 건너뛰는 중복 방지 로직 붙이기
- 완료 확인: 회사 5개를 한 번에 요청해서 전부 시트에 채워짐
- 실제로는: 시트에 총 15개 회사까지 채웠고, 이 전체 과정을 “리드조사” 스킬로 저장해 반복 가능하게 만듦
로드맵 3주차 — ICP 판별 로직 강화 + 대량 스케일 자동화 (2026-08-04 추가)
Day 9까지 끝내고 실제로 채운 15개 회사를 검토하다가, 두 가지 근본 문제를 발견해서 3주차를 아래처럼 다시 짰다.
- 판별 로직이 얕음: 자동차 판매업(코오롱모빌리티그룹·한성자동차)처럼, 업종 카테고리만 느슨하게 매칭해서 실제로는 안 맞을 수 있는 회사가 잡힘. 제품 자체에 대한 이해가 (체이스도 콩콩도) 아직 충분치 않은 게 근본 원인.
- 스케일이 안 됨: 채팅으로 회사를 하나씩 불러 조사하는 지금 구조로는, 수백~수만 개 회사를 조사한다는 목표에 절대 못 미침. 사람 개입(승인·확인)이 회사마다 필요해서 진짜 “자동화”가 아님.
Day 10 — 제품 이해를 함께 깊이 쌓기 ✅ 완료 (2026-08-04)
- 목표: “어떤 회사가 진짜 고객인지” 판단하기 전에, 제품을 훨씬 깊이 이해하기 (Day 3의 이해는 트렌드리포트 기반이라 아직 얕음)
- 할 일:
- 트렌드리포트를 다시 비판적으로 읽기 — 특히 “실제 구매고객 vs 솔루션을 만들어주는 파트너/인티그레이터” 구분을 명확히 하기 (예: NXRT는 자동차 딜러사가 아니라, ○○ 솔루션으로 3D 콘텐츠를 만들어 딜러사에 납품하는 인티그레이터일 가능성 — 그렇다면 “자동차 딜러”가 아니라 “NXRT 같은 인티그레이터 회사”가 진짜 잠재고객일 수 있음)
- ○○ 솔루션의 공식 웹사이트에서 업종별 솔루션 페이지, 가격/패키징, “누구를 위한 제품인지” 포지셔닝 자료를 콩콩이 웹서치로 조사
- 실제 구매 결정을 누가 하는지(사내 3D/엔지니어링팀? 외주 인티그레이터? 마케팅팀?) 정리
- 완료 확인: 체이스와 콩콩이 각자 이해한 걸 맞춰보고, “이 제품을 직접 쓸 회사 유형”과 “이 제품으로 뭔가 만들어서 남에게 파는 회사 유형”을 구분한 정리본 완성
- 실제로는: ○○ 솔루션은 좌석 단위 라이선스 + 공식 파트너 프로그램(ISV·서비스파트너·리셀러)을 운영한다는 걸 확인해서, 잠재고객을 ①직접 구매·사용 고객 / ②ISV·인티그레이터 파트너 / ③서비스파트너·리셀러 3유형으로 구분하는 프레임워크를 세움. 이 기준으로 보니 자동차 딜러사(코오롱모빌리티그룹·한성자동차)는 셋 다 아니라 “②의 고객”일 뿐이라는 걸 발견 — 프로필 C를 “자동차 딜러사”에서 “한국의 XR/3D 솔루션 개발사(②ISV, NXRT류 포지션)“로 수정함
Day 11 — ICP 판별 로직 강화: 업종 기반 1차 필터 + 제외 기준 수립 ✅ 완료 (2026-08-04)
- 목표: Day 10에서 다진 이해를 바탕으로, “판매업인데 잡히는” 문제의 근본 원인(느슨한 업종 매칭)을 고침
- 할 일: 6개 프로필 각각에 “적합 KSIC 업종코드” + “기본 제외 업종코드(도소매업 45~47류 등)” 규칙표 작성. 예외를 허용하려면 “왜 예외인지” 근거를 명시하는 기준도 같이 정함
- 완료 확인: 기존 15개 회사를 새 기준으로 재검토 — 몇 개가 걸러지는지, 왜 걸러지는지 리포트
- 실제로는: 6개 프로필 KSIC 규칙표 완성(메모리에 저장). 기존 15개 회사를 재검토한 결과 코오롱모빌리티그룹·한성자동차 2곳이 KSIC 45110(자동차 판매업=도소매업)으로 정확히 걸러짐 — 시트에 “제외됨” 표시로 남기고(삭제하지 않음) 근거 기록. 나머지 13개는 유지. 부수적으로 프로필 C(XR·3D 솔루션 개발사형)는 유효 회사가 0개가 돼서, 새 정의에 맞는 후보를 다시 찾아야 함이 확인됨
Day 12 — 2차 정성 검증 체크리스트: “진짜 쓸 수 있는 회사인지” ✅ 완료 (2026-08-04)
- 목표: 업종코드만으론 못 거르는 애매한 케이스(제조업이지만 실제론 단순 조립·유통만 하는 회사 등)를 한 번 더 거름
- 할 일: “자체 설계/R&D/생산라인 보유 여부”를 홈페이지에서 확인하는 체크리스트 작성(연구소·특허·자체 공장 등 키워드 기준), “리드조사” 스킬에 반영
- 완료 확인: 애매한 케이스 몇 개를 체크리스트로 재검증
- 실제로는: 5항목 체크리스트 완성(메모리에 저장), 기존 13개 유효 회사 중 애매할 수 있는 3곳(파크시스템스·신성이엔지·지엔씨에너지) 재검증. 파크시스템스·신성이엔지는 통과, **지엔씨에너지는 “조건부 통과”**로 판정(핵심 발전기 엔진은 외산이지만 전력시스템 설계·통합은 자체 역량) — 근거를 시트에 남김
Day 13 — 대량 후보 스크리닝 스크립트 (사람 개입 없이 수백~수천 개) ✅ 완료 (2026-08-06)
- 목표: 채팅으로 회사 하나씩 부르는 지금 구조를, 스크립트가 알아서 대량으로 걸러내는 구조로 전환
- 할 일: 이미 받아둔 OpenDART 전체 기업코드 목록(
CORPCODE.xml, 10만+개)을 Day 11 업종코드 필터로 자동 스크리닝하는 배치 스크립트 작성 — 채팅 개입 없이 스크립트 혼자 실행 - 완료 확인: 스크립트 한 번 실행으로 500개 이상 1차 후보 리스트 자동 생성
- 실제로는: 전체 118,581개 중 업종코드 조회가 가능한 상장기업(3,981개)으로 1차 스코프를 현실적으로 한정(비상장 전체를 매번 조회하는 건 API 호출량상 비현실적).
agent/bulk-screen.mjs작성해서 실행한 결과 577개 후보 확보(목표 초과 달성). 다만 동시 8개로 돌렸다가 OpenDART가 연결을 끊는(rate limit 추정) 문제가 발생해서 이후 모든 API 호출이 막힘 — 속도를 높이면 자동화가 오히려 멈춘다는 걸 실전에서 확인. 스크립트를 동시 2개+요청간 딜레이(250ms)+실패시 재시도+중간 캐시 저장(재실행시 이어서 진행)으로 고쳐둠
Day 14 — 2단계 파이프라인: 대량 필터 → 소수만 정밀검증 자동 연결 ✅ 완료 (2026-08-06)
- 목표: 수천 개 중 진짜 유망한 상위 후보만 골라, 그 회사들만 지금 방식(홈페이지·뉴스 정밀검증)으로 넘기기
- 할 일: 1차 후보에 적합도 점수를 매기는 로직 추가, 상위 N개만 “리드조사” 스킬로 자동 연결
- 완료 확인: “대량 필터 → 점수화 → 상위 후보만 정밀검증”이 한 번에 이어지는 걸 시연
- 실제로는:
agent/score-candidates.mjs작성(프로필 우선순위·홈페이지 존재·핵심업종코드 일치도로 점수화, 기존 시트 회사 자동 중복제외). 상위 5개를 정밀검증한 결과 3곳에서 데이터 품질 문제 발견(홈페이지가 스캠 사이트로 리다이렉트되는 경우, OpenDART의 홈페이지 정보가 다른 회사를 가리키는 경우, 사이트가 수년째 업데이트 안 된 경우) — 5개 중 확실히 통과한 건 0개였지만, 이건 파이프라인이 의도대로 오탐을 걸러낸 것. 이 교훈을 [[b2b-agent-quality-checklist]]에 항목 2개(사이트 진위 확인·정보 최신성) 추가로 반영
Day 15 — 실제 규모 테스트: 사람 개입 최소로 100개+ 돌려보기 ✅ 완료 (2026-08-06)
- 목표: 진짜로 “수백~수천 개” 자동 처리가 가능한지 검증
- 할 일: 남은 승인 마찰 지점 점검, 배치를 백그라운드로 오래 돌리는 법·실패 재시도·로그 남기는 법 적용
- 완료 확인: 100개 규모로 실제 실행해서, 이전 대비 사람 개입 횟수가 얼마나 줄었는지 기록
- 실제로는: OpenDART API가 계속 막혀있는 상태를 역이용해 회로차단기(연속 8회 실패시 전체 중단) 실전 테스트를 진행 — 정상 작동 확인(2.5시간 낭비를 몇 초로 방지). 테스트 중 결과 파일 덮어쓰기 버그(577개→0개)를 실제로 겪어서 발견·수정함(“새 결과가 이전보다 부실하면 덮어쓰지 않기” 안전장치 추가). 사람 개입 지점은 이제 “시트에 실제로 쓸 때”와 “새 회사 홈페이지 첫 방문 때” 단 2곳으로 줄었고, 이건 회사 수가 늘어나도 비례해서 늘지 않음. 3주차(Day 10~15) 전부 완료.
3주차 마무리 — 무인 실행을 막던 것들 제거 (2026-08-13 추가)
Day 15까지 끝내고 보니, “사람 개입 2곳”이 남아 있는 한 예약 실행은 불가능했다. 8/10~8/12에 그 둘을 없앴다.
Day 16 — 승인 요청을 0회로 ✅ 완료 (2026-08-12)
- 원인이 세 갈래였다: ①브라우저·WebFetch는 도메인마다 승인을 요구 ②허용 규칙은 명령 문자열을 통째로 비교해서
| head하나만 붙어도 매칭 실패 ③for반복문·셸 변수$경로도 같은 이유로 차단(Contains simple_expansion) - ‘완전 허용’은 이 명령들이 아니라 모든 명령을 허용하는 것이라 쓰지 않았다. 대신 감쌀 이유를 없앴다 —
fetch-site.mjs(홈페이지를 텍스트로 요약)·sheet-list.mjs(출력을 스크립트가 미리 정리)·sheet-write.mjs(gws의 keyring 안내를 stderr째 삼킴) - 부수 발견:
Bash(gws sheets *)가 다른 시트 쓰기까지 무승인 통과시키고 있어 읽기 전용(+read)으로 축소 - 완료 확인: 회사 4곳을 조사·기록하는 전 과정에서 팝업 0회를 직접 확인
Day 17 — 토큰 소모 구조 파악과 절감 ✅ 완료 (2026-08-12)
- 실측: 누적 토큰의 98%가 컨텍스트 재읽기였고, 대화가 길어지며 회사 1곳 비용이 8배로 뛰었다
- 조치: 도구 출력의 기본값을 요약으로(홈페이지 읽기 93%↓, 시트 목록 76%↓), 회사 5곳마다 새 세션
- 배운 것: 비용은 “얼마나 말했나”가 아니라 **“얼마나 쌓였고 몇 번 다시 읽었나”**로 정해진다
Day 18 — 매일 정오 예약 실행 ✅ 완료 (2026-08-12, 첫 실행 2026-08-13)
- 매일 12시에 회사 10곳을 조사·기록하고 브리핑까지 올리는 작업을 등록
- 개수를 10곳으로 정한 기준은 API 한도가 아니라 하루 토큰 예산 — 이만큼 돌려도 다른 일을 할 여유가 남는 선
- 곁들여 OpenDART 하루 상한을 100 → 300회로 상향(1곳당 4.4회 실측)
- 완료 확인: 8/13 정오 첫 실행에서 승인 0회로 10곳 추가, 프로필이 우선순위대로 순환
계획이 밀리면
하루치가 계획대로 안 끝나도 괜찮다. 다음 날로 넘기지 말고, 그 자리에서 막힌 걸 콩콩에게 바로 알린다. Day 1~9는 하루 만에 끝냈으니, 3주차(Day 10~15)도 여유를 갖고 진행한다.
처음에 못 정했던 것들 — 어떻게 정해졌나
계획 단계에서 “아직 확정 안 된 것”으로 남겨뒀던 항목들의 결말이다.
| 그때 미정이던 것 | 지금 |
|---|---|
| 어떤 공공데이터 API로 후보를 찾을지 | OpenDART(기업개황·직원현황·재무제표)로 확정. 회사 1곳당 약 4.4회 호출 |
| 한 번에 찾을 회사 수의 상한 | 하루 10곳. 기준은 API 한도가 아니라 토큰 예산이었다 |
| ICP를 몇 개로 나눌지 | 6개(A~F) + 우선순위. 구매자 유형 3가지(①직접고객 ②ISV파트너 ③리셀러)와 함께 씀 |
| 홈페이지·뉴스 보강에 걸리는 시간 | 홈페이지는 fetch-site.mjs 요약으로 83%가 한 번에 판단 가능. 브라우저는 실패했을 때만 |
다음 과제
- 후보 발굴을 검색에서 데이터로. 업태 코드로 후보 기업을 회사명 + 사업자번호까지 먼저 전부 리스트업하고, 그다음 전체를 적은 토큰으로 scoring하는 방법을 찾고 싶다. 지금은 검색에 안 걸리는 회사가 영원히 후보에 못 들어온다.
- 판별 정확도. 업종코드를 세분류까지 좁혀 오탐 6곳을 걸러냈지만, 넓히면 오탐 · 좁히면 누락 사이는 아직 더듬는 중이다.
- 남에게 넘길 수 있게.
gws설치 안내, 승인 규칙, 실명 검사 — 셋 다 이 컴퓨터에만 있다.
이번 4주엔 안 한 것
- 담당자 개인 성명·연락처 자동 수집 — 공공데이터에 없는 개인정보라 범위 밖
- 콜드 이메일 관련 기능 전체 (초안 작성·발송 모두) — 리드 발굴·검증이 핵심이라 범위에서 제외