Playbook · 실전

AI 에이전트로 웹서비스 운영하기

OIYO는 사람 1명 + AI 에이전트 조직이 사이트 6개(테스트·강의·사전·게임·뉴스·AI)를 운영합니다. 이 페이지는 그 실제 구성을 그대로 옮긴 것입니다.

운영의 4개 기둥

① 에이전트 조직

역할별로 권한을 나눈 AI 직원들. 설계는 architect, 구현은 builder, 검증은 verifier처럼 도구 경계를 하드로 강제.

② 회사 두뇌

모든 결정·실패·맥락을 마크다운 위키(Obsidian)에 축적. 새 세션의 AI가 이걸 읽고 이어받음.

③ 자동화 루프

시장 분석·트렌드 정찰·SEO 감사·검증 게이트 같은 반복 작업을 스케줄 실행(크론·상시 에이전트)으로 넘김.

④ 검증 게이트

빌드·타입체크·테스트·감사를 통과해야만 "완료". AI의 주장보다 게이트의 판정을 믿음.

하루가 굴러가는 방식 (설계 패턴)

아침  시장·트래픽 데이터 수집 → 브리핑 생성 → 사람에게 전달   (평일 자동)
주1회  리서치 스냅샷·성과 리포트·다음 목표 초안
낮    기술 트렌드 수집 → 큐레이션 → 뉴스 사이트 자동 발행
밤    사이트별 full 검증 게이트 (사이트 수만큼 순차)
심야  하루 요약 → 완료 보고와 게이트 결과 대조
사람이 하는 일: 브리핑 읽기, 배포 승인, 방향 결정

정확한 시각·잡 개수는 팀 규모와 사이트 수에 맞춰 정하면 됩니다. 패턴의 핵심은 수집·실행은 자동, 승인·방향은 사람이라는 경계입니다.

핵심 설계 결정 5가지

  1. 완료는 게이트가 정의한다 — AI가 "끝났다"고 말해도 빌드·테스트·감사가 green이어야 done. 검증 없는 완료 보고를 금지하는 게 규율의 시작.
  2. 배포는 사람 승인 + 배치 — 로컬 커밋은 자유, 푸시(=배포)는 모아서 명시 승인 후. 비용과 사고를 동시에 줄임.
  3. 실패를 두뇌에 남긴다 — 같은 실수를 반복하지 않도록 "실패한 접근" 문서를 별도로 축적. 성공보다 실패 기록이 더 값짐.
  4. 역할별 도구 경계 — 검증 에이전트는 읽기 전용, 리서치 에이전트는 코드 수정 불가. 프롬프트가 아니라 권한으로 강제.
  5. 비싼 모델은 판단에, 싼 모델은 물량에 — 설계·판단은 상위 모델, 대량 번역·정찰은 무료·경량 모델로 라우팅.
거버넌스 원문

AI 위험은 기능 하나가 아니라 수명주기 전체에서 식별·측정·관리·운영해야 합니다. 이 운영 원칙의 공공 기준으로 NIST AI Risk Management Framework를 참고합니다. NIST 링크는 OIYO의 개별 구현을 인증하거나 보증한다는 뜻이 아닙니다.

최소 구성으로 시작하기 (첫 달)

6사이트 규모가 아니라 사이트 1개로 시작해도 구조는 같습니다:

  1. 정적 사이트 + 무료 호스팅 — Astro/Next + Cloudflare Pages·GitHub Pages. 서버 관리 비용 0.
  2. 코딩 에이전트 1개 — Claude Code 또는 무료로 시작하려면 Gemini CLI. 저장소 루트에 CLAUDE.md부터 작성(가이드).
  3. 두뇌 폴더 1개 — 마크다운 폴더에 결정·실패·할일을 기록. Obsidian으로 열면 위키가 됨.
  4. 검증 스크립트 1개 — "빌드 + 링크 체크"만이라도. 게이트 없는 자동화는 사고로 이어짐.
  5. 크론 1개 — 주 1회 "깨진 링크·빌드 상태 점검"부터. 자동화는 관측에서 시작.

이 최소 구성의 상세 절차는 매뉴얼 01 — 시작하기에, 에이전트 조직 확장은 매뉴얼 02에 있습니다.

흔한 실패 (우리가 겪은 것)

← 플레이북 목록 · AI-native 운영 체계 →