데이블 광고주 고객 메일 AI 자동 답변 생성 및 검수 대시보드

🛠️ Skills

• NestJS(TS), LangChain, HNSWLib
• Apache Airflow, AWS RDS, AWS EKS, AWS ECR

✍🏻 Description

데이블에서 신규 광고주/대행사의 대시보드 적응 중 발생하는 이탈을 방지하고 광고팀의 반복적인 단순 문의 대응 리소스 낭비를 해결하기 위해 2026년 1분기 프로젝트로 AI 시대에 맞춰 RAG 기반의 마케팅 AI 에이전트를 개발하게 되었습니다. FAQ 및 고객 대응 매뉴얼 문서 기반으로 자동화된 답변을 빠르게 제공함으로써 고객들의 정보 접근성을 높여 적응률과 잔존율을 높이고, 응대 자동화를 통해 확보된 리소스를 다른 핵심 업무에 집중할 수 있는 환경을 구축하는 것을 지향합니다. 프로젝트는 광고팀 프로젝트 리드와 함께 BE 개발 1명, FE 개발 1명으로 총 3명으로, BE 개발을 맡아 진행하고 4월 1일 정식 릴리즈를 진행하였습니다.

📝 Experience

💥 광고주 고객 메일 문의 AI 답신 생성 및 검수 후 발송 자동화 워크플로우 구축

Jan 2026 ~ Apr 2026

What’s the issue?

광고주들이 주로 사용하는 데이블 마케팅 대시보드에 챗봇 형태로 AI 에이전트를 구축하기 전, 이메일로 단순 문의를 보내는 광고주가 많고 메일 응대에 대한 리소스 소모를 줄이는 것이 선행되어야 한다는 광고팀 제안이 있었음. 이에, 광고팀 수신 메일에 대한 문서 기반 AI 답변 메일을 자동 생성하여 약간의 검수만으로 기존 대비 전체 소요 시간을 획기적으로 줄이는 시스템 구축이 필요하게 됨

What did I do?

• RAG 근간 문서인 데이블 공식 마케팅 FAQ 와 1년 치의 메일 문의 답변을 Notion에서 LangChain으로 불러와 임베딩하고 벡터 인덱스 파일로 S3에 저장하는 Airflow 크론잡 개발 ⇒ 65개 페이지에 대해 로드, 청킹, 임베딩, 인덱스 파일 생성 및 갱신까지 1분 이내 안정적으로 수행
• 문서 기반 실시간 LLM 에이전트 답변 생성 전담 NestJS 애플리케이션 구현 ⇒ Notion-S3-Gemini를 연동한 분산형 벡터 인덱스와 빠른 성능의 HNSWLib 유사도 검색 알고리즘을 더해 일일 전체 수신 메일 중 평균 95%에 대해 문서 기반 답변 생성 및 나머지 5% fallback 답변 생성
• 국내 광고팀 그룹 메일로 수신되는 문의 메일 일괄 AI 답변 생성 및 DB 상태 저장 관리 크론잡 개발 ⇒ 사내 인프라팀 보안 정책에 맞춘 Gmail API 직접 사용 제한과 Service Account 활용에 부합하여 평균 40건의 메일에 대한 전체 fetch → AI 답변 생성 → 자체 DB 저장까지 LLM 소요시간 제외, 병렬적으로 3초 이내 빠르게 수행
• 사내 직원용 백오피스 대시보드 내 광고팀 전용 AI 답변 검수 발송 시스템 API 개발 ⇒ 광고팀 매니저 개별 수동 응대로 분산되어 있던 메일 응대를 백오피스 대시보드로 일원화 하여 Gmail을 대체. 대시보드 내 구현한 자체 메일 수정/발송 기능 개발로 AI 답변 신뢰도 측정 및 내부 정보 투명성 확보

Retrospective points

• 설계 단계에서 메일 응답 자동화 워크플로우 구축 방법으로 초기엔 n8n 사용 노코드와 NestJS 서버 내 @Cron 처리를 두고 고민함. 회사 지원과 더불어 사업팀 메일 엔드포인트에 대한 처리 관심사 분리를 고려하여 n8n 구현을 염두에 뒀으나, 팀에서의 설계 리뷰 이후 구글 인증 처리, 유지보수 및 책임 주체 등 고려 사항으로 서버 구현으로 우회.
• AI 응답용 NestJS 애플리케이션에서 데코레이터로 메일 수집을 하자니 최소 2개 이상 pod로 운영되는 상용 환경에서 동일 메일 중복 처리 발생으로 bullMQ 도입으로 해소해야 하는 등 복잡성이 올라간다 판단함
• 팀 시니어 개발자님의 Airflow 처리 피드백을 수렴하여 현재의 Airflow 크론잡으로 단일 trigger 및 서비스 간 책임 격리 및 응집성 강화 구조를 확보하게 되어 모듈 독립 설계 원칙을 다시금 생각할 수 있었음
• 2FA 인증이나 key 관리 책임을 고려하여 마케팅팀 그룹 메일을 구독하는 매니저/개발자의 루트 계정으로 Gmail API를 직접 사용하는 것 대신 인프라팀에서 Service Account를 발급받아 사용하게 됨
• 메일 송수신을 위해 ‘도메인 계정 위임’이 필요한데 이는 워크스페이스 내 전체 계정에 접근이 가능한 또 다른 보안 문제를 야기하여 위임 계정과 수신 그룹 메일 지정 및 구독 상태 인증을 판단하여 Gmail API 쿼리를 중앙 처리하는 프록시 서버 개발을 전사에 도입하는 계기가 됨
• 기능 개발에 필요한 Gmail API 쿼리들을 파악하면서 직접 Gmail API를 사용했다면 발생할 보안적 위험, 불안정성을 자각하고 이러한 시스템 간 격리와 유관부서간 조율 및 협력 방식 필요성을 깨달을 수 있었음
• 구현된 프록시 서버로 Gmail 메일 목록을 불러올 때, “위임 계정”이 바뀌면 동일 메일도 고유 식별자가 바뀌고 개별 메일함 설정에 따라 누락이 발생하는 등 데이터 무결성이 깨지는 치명적인 문제가 개발 단계에서 확인됨
• 위임 계정을 광고팀 실제 직원으로 두면 퇴사, 조직 변경의 가능성을 배제할 수 없어 이를 방지하기 위해 단일 공용 계정 추가가 필요했음
• 공용 계정 발급하지 않고 위임 계정+날짜 와 같은 복합키 구성도 고안하였으나, 여전히 위임 계정 변동 시점에 나타날 수 있는 정합성 문제는 불가피했음
• 임원 설득 끝에 공용 계정 확보에 성공하여 무결성을 보장할 수 있게 되었으나, 과정에서 개발 일정이 약간 딜레이 되어 초기에 더 적극적으로 설득하고 당위성을 피력해야겠다고 생각함