AI 제안서 자동화 시스템 — 공고 수집→RAG 제안서 초안

프로젝트 배경

외주 플랫폼의 신규 공고를 수집하고, 상세 본문을 바탕으로 AI 제안서 초안을 생성하는 업무 자동화 프로토타입입니다. Project·Portfolio·Prompt를 핵심 엔티티로 나누고, 프로젝트 상태를 발견·검토·지원·미팅·계약 단계로 관리합니다.

담당 범위

• 위시켓·프리모아 공고 목록·상세 본문을 수집하는 Playwright 스크래퍼와 브라우저 세션 복원 구성
• Supabase PostgreSQL·Storage·pgvector RPC로 프로젝트·제안서·임베딩 데이터 관리
• Notion 문서를 임베딩해 기존 제안서·포트폴리오 사례를 RAG 컨텍스트로 검색하는 흐름 설계
• GPT 기반 제안서 생성·재생성·편집·상태 관리 API를 Next.js Route Handler로 구현
• Vercel Cron·Slack 알림·세션 만료 대응·운영 문서까지 자동화 운영 관점으로 정리

문제 정의

• 반복 노동 — 외주 공고를 사람이 매번 확인하고, 관련 포트폴리오를 찾아 제안서 초안을 쓰는 과정이 반복됐습니다.
• 맥락 없는 AI의 한계 — 공고만 AI에 던지면 회사의 실제 사례와 동떨어진, 그럴듯하지만 쓸 수 없는 초안이 나왔습니다. 우리 포트폴리오를 컨텍스트로 넣는 구조가 필요했습니다.
• 로그인 벽 뒤의 데이터 — 공고 상세는 로그인·세션이 필요해, 매 실행마다 재로그인하면 계정 차단·캡차 위험이 있었습니다.

기술적 의사결정

1. 포트폴리오를 RAG 검색 대상으로 배치

• 배경 — AI 초안이 회사 실제 역량과 맞물리려면, 생성 시점에 유사 사례가 컨텍스트로 들어가야 합니다.
• 선택 — 포트폴리오 문서를 Vector Store/file_search 검색 대상으로 두고, 신규 프로젝트 본문을 검색 쿼리이자 생성 컨텍스트로 사용했습니다. 공고 → 관련 포트폴리오 검색 → 제안서 초안 생성으로 이어지는 업무 흐름을 파이프라인으로 고정했습니다.
• 트레이드오프 — 자유 태깅으로 유연하게 갈 수도 있었지만, 검색 품질이 흔들립니다. 카테고리를 AI·중개플랫폼·커머스·홈페이지·앱·ERP/CRM·LMS로 고정해 검색 품질과 프롬프트 일관성을 우선했습니다.

2. 프롬프트 관리를 별도 도메인으로 분리

• 배경 — 생성 품질은 운영하며 계속 튜닝해야 하는데, 프롬프트가 코드에 박혀 있으면 매번 배포가 필요합니다.
• 선택 — 제안서 생성 로직을 코드 수정 없이 조정할 수 있도록 프롬프트 관리 API를 별도 도메인으로 뒀습니다. 생성 품질을 운영 단계에서 튜닝할 수 있는 구조로 만들었습니다.

3. 세션 복원과 스케줄링으로 수집을 자동 운영

• 배경 — 공고 상세는 로그인 뒤에 있어, 매번 로그인하면 차단·캡차 위험이 큽니다.
• 선택 — Playwright에 브라우저 세션을 복원해 재로그인 빈도를 낮추고, Vercel Cron으로 주기 수집을, Slack 알림으로 신규 공고·세션 만료를 통지해 사람이 개입할 지점만 남겼습니다.

결과

• 공고 수집 → 유사 사례 검색 → 제안서 초안 생성 파이프라인 동작
• Supabase pgvector match_proposals RPC로 유사도 검색 구성
• Project·Portfolio·Prompt 엔티티와 프로젝트 상태 파이프라인 설계
• Vercel Cron·Slack 알림·세션 복원까지 운영 관점 자동화

한계와 다음 단계

프로토타입 단계라, 생성 초안 품질은 프롬프트 튜닝에 아직 좌우되고 스크래퍼는 대상 플랫폼의 DOM 변경에 취약합니다. 실서비스화하려면 초안 품질의 정량 평가 지표, 스크래퍼의 셀렉터 회복 전략, 임베딩 갱신 주기 관리가 다음 과제입니다.