「홈랩에서 24시간 멈추지 않는 AI 에이전트 운영 인터페이스」 3주차 사례 발표
이번 사례는 네이버 검색량 분석 서버를 개발하면서
AI가 알아서 작업했거나 에러를 해결하던 부분은 제외하고,
제가 직접 판단하고 결정한 부분들, 제가 과정에서 배운 것들 위주로 정리해봅니다
1. 내가 할 수 있는 것과 못하는 것 구별
배경
· 비개발자이고, 코딩 지식과 경험이 없기 때문에, 코드를 읽고 검증할 수 없는 상태에서 AI에게 구현을 맡김
· 그래서, 읽지 않고도 검증할 수 있는 장치가 필요했음
실행 - 나
· 역할 고정: 운영자(나) = 무엇을 만들지·무엇을 포기할지(사업 판단), AI = 어떻게 만들지(설계·구현)
· 코드 작성 전에 설계 문서(PRD, VERIFICATION)를 먼저 확정하고, 이후 모든 작업은 문서 확인부터 시작
· 설계 변경은 "승인 + 정오표 기록"으로만 허용 — 코드가 아니라 문서를 정본으로 삼음
실행 - AI : 평가 기준 (무엇으로 확인했는가) 준수
· deploy/verify.sh — 재부팅 후에도 6개 항목을 한 줄로 확인
· pytest — 486개 테스트 통과 (1차 발표 시점 411개)
· VERIFICATION.md 게이트 — G0(수집 정확성)~G3(보안·성능·분석 신뢰성)
· 정오표 — 지금까지 8건, 설계가 현실에 부딪힌 기록
결론
· 코드를 못 읽어도 "문서와 실제가 어긋나는가"만 확인하면 되는 구조를 만듦
· 정오표가 쌓일수록 다음 판단의 재사용 가능한 근거가 됨
2. 교차 검증 (MOA, Mixture of Agents)
배경
· "AI가 자기 결과물을 스스로 점검하는 것"은 쉽지 않을 것으로 가정
실행 - 나
· 설계 Claude Fable5로 하고, ChatGPT 5.6 Sol에게 적대적으로 검증받는다
· 보고서 수치는 AI의 서술을 믿지 않고 DB 원장과 직접 대조한다
실행 - AI : 설계를 적대적으로 교차 검증
· 라운드: 6회
· 지적 사항: 25 → 22 → 19 → 15 → 13건
· 제 판단이 뒤집힌 횟수: 0건
· 최종 판정: 치명 0건 · 중요 0건 · 사소 6건
· 가장 치열했던 공방: 검증자가 "검색량 환산 방식 자체가 검증 불가능한 가정"이라고 문제 제기
· 제가 확보해둔 실증 데이터(기준 키워드가 44개 세그먼트 전부에서 실제 검색이 있었음을 증명)로 반박 → 3라운드 만에 수용
· 검증이 실제로 잡아낸 결함: 부분 갱신 시 데이터 조용히 소실 / 재시도 중 중복 계산 / "완료 불변" 규칙과 "삭제 가능" 규칙의 충돌
결론
· "AI 혼자 점검"보다 "다른 주체가 적대적으로 검토"하는 쪽이 압도적으로 유효함을 확인
· 이 검증 구조를 프로젝트 상시 운영 방식으로 채택(설계=독립 모델, 구현=갭 분석, 실행=VERIFICATION 게이트)
3. 모델의 역량 검증 — 모델 최적화
배경
· 같은 데이터·같은 프롬프트로 세 모델(fable·sonnet·opus)에게 같은 분석 보고서를 통해 세 모델을 비교해볼 필요성 : 궁금함+실용성&효율성
실행 - AI : 1차 실측 (누룽지 세트)
· fable — 등급(API 정가) 최상위($10/$50), 소요 8.6분, 분량 12,221자, 갈린 지점: 관찰하고 유보
· sonnet — 등급 중간($3/$15), 소요 13.3분, 분량 15,030자, 갈린 지점: 가설 제기 후 멈춤
· opus — 등급 상위($5/$25), 소요 15.3분, 분량 24,966자, 갈린 지점: 검증 방법을 스스로 찾아 반증
· 정확도는 셋 다 동일(DB 대조 전부 일치) — 갈린 건 정확도가 아니라 가설을 다루는 깊이
실행 - AI : 2차 실측 (새싹삼 세트, 재검증)
· 순서 그대로 재현: fable 9.7분·11,039자 < sonnet 10.4분·11,815자 < opus 17.8분·24,779자
· fable 보고서는 "약해서 짧은" 게 아니라 핵심 발견은 다 짚되 자기검증(합계 대조, 통계기법 명시)이 적은 스타일로 확인
모델별 특징 비교
· fable
- 성향: 과잉 확신을 피하고 불확실성을 있는 그대로 인정, 정해진 틀 안의 과제는 "빠르게 풀 문제"로 처리
- 근거: SWE-Bench Pro 80.3%로 코딩·에이전트 계열 최상위(2026 공개 벤치마크). 제3자 성격 연구: 정직·겸손 성향이 특히 강함
· opus
- 성향: 스스로 검증 방법을 찾아 논증을 쌓고, 자기 가설을 반증까지 시도
- 근거: 실측 2회(누룽지·새싹삼) 모두 자기검증 밀도가 가장 높음(합계 대조, 통계기법 명시)
· sonnet
- 성향: 가설은 세우되 단정하지 않고 멈춤, fable과 opus의 중간
- 근거: 실측 2회 모두 두 모델 사이 위치
이 특징으로 실험 결과를 해석
· fable이 짧고 간결했던 건 능력 문제가 아니라 성향 — 자유 에세이 글쓰기에서는 오히려 fable이 opus보다 더 장황·문학적이라는 것도 확인함. 즉 "이 태스크(정해진 스킬 틀 안의 분석 보고서)에서만 나타난 간결함"
· opus가 길고 자기검증적이었던 것도 "말이 많아서"가 아니라 스스로 검증 경로를 만드는 성향 — "비율이 아니라 절대량을 보면 갈린다"는 검증을 시키지 않았는데도 스스로 수행해 자기 가설을 반증한 것이 대표 사례(4번 항목 참고)
이 특징을 역할에 매핑
· 데이터 훑고 질문 만들기(brief) → fable — 과잉 확신을 피하는 성향으로 근거 없는 질문을 만들지 않음, 빠른 스캔에 적합
· 정식 보고서(detail) → opus — 스스로 검증·반증하는 성향이 보고서의 상품성(가설 검증 능력)에 직접 기여
· 추가 보고서(followup) → sonnet — 중간 성향 + 앞 보고서가 이미 범위를 좁혀둔 상태라 안정적 수행
결론
· 모델 선택을 "어느 모델이 좋은가"가 아니라 "이 성향이 이 단계에 맞는가"로 재정의
· 최종 배치: brief=fable / detail=opus / followup=sonnet
· 코드 반영은 아직 — 현재는 전부 sonnet 고정 (3차 발표 전 배선 예정)
4. 분석 렌즈 깎기
배경
· 비싼 모델(opus)이 스스로 찾아낸 검증 방법을, 규칙으로 적어두면 싼 모델도 따라 하는지 실험
실행 - 나
· 스킬에 규칙을 추가할 때는 "절차"만이 아니라 "이유"까지 적는다
실행 - AI : 4단계 실험
· 1차 — 규칙에 적은 것: 없음 / fable: 검증 안 함 / sonnet: 가설만 제기하고 멈춤
· 2·3차 — 규칙에 적은 것: 절차만("절대량으로 갈라라") / fable: 검증함(그런데 10년 창) / sonnet: 검증함(그런데 10년 창), 두 모델 모두 "10년 창"을 골 라 opus와 결론이 정반대로 나옴
: 10년 창 기준 누룽지 50대+: +492% → 사업 판단: 본 키워드에 투자
: 최근 12개월 창 기준 누룽지 50대+: −9.9% → 사업 판단: 과자·스낵에 투자
: 둘 다 DB상 정확 — 기간 선택 하나가 결론을 뒤집음
· 4차 — 규칙에 적은 것: 절차 + 이유 / fable: opus와 완전 일치 / sonnet: opus와 완전 일치
: "10년 창은 그 사이 플랫폼 이용자가 늙은 것까지 섞는다"는 이유를 추가하자 두 모델 모두 opus와 일치, sonnet은 그 이유를 자기 말로 재서술함
현재 스킬에 반영된 규칙
· 구성비가 움직였으면 절대량을 확인한다 (창 = 최근 12개월 대 직전 12개월, 이유 포함)
· 급성장은 하나의 파도인지 확인한다
· pip install 등 환경 설치 시도 금지
결론
· "판단은 규칙으로 옮겨진다 — 단, 이유를 함께 적어야 한다"
· 스킬이 쌓일수록 비싼 모델을 불러야 하는 빈도가 줄어듦
5. 대화창 개선 작업
배경
· 채팅에 실을 데이터 컨텍스트를 어떻게 구성할지 고민됨
실행 - AI
· 뷔페식(월별·계절성·교차표 등 큰 표를 전부 미리 실음) — 문제: 어떤 질문이 올지 몰라 빠진 조각이 계속 드러남(교차표·연도별 합계·연 축 순으로 계속 기움) → 카탈로그 방식으로 전환
· 카탈로그(무엇을 조회할 수 있는지만 제시, 질문에 맞는 표는 그때 조립) — 문제: 화면에서 고른 조합 밖의 값을 모델이 추측 → "조건 밖 값은 추측 금지" 명시 + 화면 기간이 전체가 아니라는 안내문 추가
결론
· 채팅은 화면에서 고른 선택(기간·연령·성별·기기) 안에서만 답하도록 재료 자체를 제한하는 것이 효과적임
: 사실과 다른 답을 하던 오류를 컨텍스트 설계로 차단
6. 검색량 데이터로만 해석 + 웹검색 경계
배경
· 원래 검색량 데이터로만 해석을 해야 웹 자료에 의한 해석 오염을 막을 수 있음
· 그러나, 웹 검색이 꼭 필요한 부분도 있지 않을까?
실행 - 나
· 웹검색을 허용하되, 용도를 명확히 나눈다
결론
· 허용: 키워드 자체의 의미 파악("이 단어가 뭘 가리키나"), 특정 구간이 튄 이유의 배경 조사(예: "2017년에 왜 튀었나")
· 금지: 추세·계절성·인구통계·요일 패턴 등 정량적 해석, 데이터 분석을 웹 검색 결과로 대체하는 것
· 웹에서 가져온 문장에는 반드시 출처 표기
· 배경 확인 후에는 다시 데이터 숫자로 돌아와 답할 것
· "정량적 해석과 결론은 반드시 데이터셋 5개 렌즈로만 낸다"는 원칙 유지
· 웹검색은 배경 조사라는 좁은 역할로 한정, 결론에는 등장하지 않음
7. 지금 구축된 아키텍처
· web — 화면·API·AI 채팅, 맥 OS 자체 실행(launchd)
· worker — 수집·분석 백그라운드 큐, 맥 OS 자체 실행(launchd)
· SQLite — 데이터베이스(약 1.15GB, 세트 5개·74키워드), 맥 로컬 파일
· cloudflared — 터널 연결, Docker 컨테이너
· Cloudflare — 전 세계 엣지, 인증서 자동 발급, 외부(SaaS)
방문자 브라우저
│ HTTPS
▼
datalab.sogoodmarketing.kr ← 도메인
│
▼
Cloudflare (전 세계 엣지) ← 무료, 인증서 자동
│ 터널 (안쪽에서 바깥으로 연결)
▼
┌──────────────────────────────────────────┐
│ 맥스튜디오 (사무실, 24시간 가동) │
│ │
│ ┌── Docker ──────────┐ │
│ │ cloudflared │ ← 터널 연결만 │
│ └─────────┬──────────┘ │
│ │ host.docker.internal:8001 │
│ ▼ │
│ ┌── 도커 밖 (macOS 자체 실행) ────────┐ │
│ │ web — 화면·API·AI 채팅 │ │
│ │ worker — 수집·분석 백그라운드 │ │
│ │ SQLite — 데이터베이스 │ │
│ └────────────────────────────────────┘ │
└──────────────────────────────────────────┘ │8. 남은 계획
· MCP 서버 구현(도구 목록 노출), 상태: 착수 전, 비고: 8/13 발표 핵심 — 화면 없이도 앱을 호출 가능하게
· 텔레그램/슬랙 채팅창에서 헤드리스로 구동, 상태: 착수 전, 비고: "이 세트 분석해줘" 한 마디로 수집→분석→보고서 실행, 결과를 채팅으로 반환
· Docker 컨테이너화(web·worker까지), 상태: 방법 확인·미착수, 비고: 구독 과금을 유지하면서 컨테이너 안에서 실행하는 방법을 확인해둠 -> 이재엽 스터디장님 도움
· 모델 단계별 배선(3번 항목 결론 적용), 상태: 결정만 하고 미적용, 비고: 지금은 전부 sonnet 고정
MCP 설계 시 풀어야 할 것
· 수 분~수십 분짜리 작업의 진행 상황을 어떻게 알릴지
· 보고서를 채팅에 어떤 형태로 돌려줄지(요약 + 링크 / 파일 첨부)
