플로팅 위젯으로 광고·제휴 문의 수집 시작
목차
광고나 제휴 제의를 받을 창구가 필요했다. 메인 네비게이션에 숨겨진 링크보다는, 방문자 눈에 띄는 곳에 항상 열어둔 문의 창이 낫다고 판단했다. 그래서 우하단 플로팅 위젯 + 자동 메일 발송 API를 한 묶음으로 추가했다.
플로팅 위젯, 왜 우하단인가
사이트 중단에 떴다 내렸다 하는 플로팅 UI는 position: fixed 기반으로 항상 화면에 고정된다. 모바일/데스크톱 모두 접근 가능하고, 사용자가 스크롤해도 따라다닌다. 문제는 배치다.
- 우상단: 헤더/메뉴와 겹치기 쉬움
- 좌하단: 모바일에서 뒤로가기·메뉴 버튼과 충돌
- 우하단: 대부분 비어있고, 우측 스크롤바 영역을 피함
광고·제휴 같은 B2B 문의는 긴급성이 낮으니, 너무 눈에 띄지 않으면서도 필요할 때 찾을 수 있는 위치가 이상적이다. 우하단은 그 사이 어딘가다.
기술 구성: Astro 컴포넌트 + API 라우팅
변경 파일들이 역할 분담을 잘 보여준다.
| 파일 | 역할 | 변경 의도 |
|---|---|---|
src/components/AdInquiryWidget.astro |
위젯 UI (폼, 버튼, 스타일) | 새로 생성 — 플로팅 창 렌더링 |
src/layouts/Base.astro |
사이트 기본 레이아웃 | 위젯 컴포넌트 임포트 + 모든 페이지에 포함 |
src/pages/api/ad-inquiry.ts |
백엔드 API | 폼 제출 수신 → 메일 발송 처리 |
package.json / package-lock.json |
의존성 관리 | 이메일 발송 라이브러리 추가 (nodemailer 등) |
특히 Base.astro 에 위젯을 심는 게 핵심이다. Astro의 레이아웃은 모든 페이지가 상속하는 템플릿이니, 여기 한 곳에만 추가하면 전체 사이트에서 위젯이 나타난다. 이렇게 하면 페이지마다 위젯 참조를 반복할 필요가 없다.
API 엔드포인트의 역할
사용자 폼 제출
↓
POST /api/ad-inquiry
↓
메일 헤더·본문 조합
↓
SMTP 전송
↓
응답 (성공/실패)
API 라우터는 폼 데이터를 받아 메일로 변환하는 게이트웨이 역할한다. 프론트엔드(Astro 컴포넌트)는 폼 UI만 담당하고, 실제 메일 발송·에러 처리·인증 같은 민감한 작업은 서버에서만 일어난다.
이렇게 분리하면:
- 클라이언트에서 SMTP 자격증명 노출 안 함 (보안)
- 메일 발송 로직을 나중에 변경 가능 (유연성 — SMS 추가, 큐 시스템 적용 등)
- 폼 유효성 검사를 서버에서도 재확인 (방어)
운영 관점: 자동화와 추적
문의가 오면 내 메일로 바로 도착한다. 이전에는 문의 폼이 없거나 있어도 깔려 있어서, 제휴 제의를 많이 놓칠 수밖에 없었다. 이제 메일이 자동으로 들어오니, 반응 속도도 빨라진다.
다만 한 가지 주의할 점이 있다. 플로팅 위젯을 너무 공격적으로 하면 사용자 경험을 해친다. 닫기 버튼이 쉽게 보여야 하고, 팝업처럼 자동으로 모달을 열면 안 된다. 문의가 필요한 사람만 클릭하도록 유도하는 게 맞다.
비슷한 패턴들
플로팅 위젯은 이후에도 여러 용도로 쓸 수 있다:
- 고객 지원: 채팅/이메일 문의 창
- 피드백: "이 페이지 도움이 되셨나요?" 버튼
- 뉴스레터: 구독 유도 CTA
- 공지: 중요 업데이트 배너
핵심은 "항상 접근 가능 + 한 번에 스스로 사라짐" 이다. 너무 자주 보이거나 닫기 어려우면 사용자는 짜증낸다.
회고
이번 작업을 통해 느낀 점:
-
UI 배치는 전략이다. 플로팅 위젯의 위치 선택이 간단해 보이지만, 사용자 행동·화면 크기·기존 UI와의 충돌을 모두 고려하는 작은 의사결정이다.
-
기술과 운영을 함께 본다. 폼을 만드는 것과 메일을 받는 것은 분리되지 않는다. 자동화가 운영 부담을 줄이는 만큼, 스팸/오류 처리도 함께 고려해야 한다.
-
작은 기능도 영향은 크다. 플로팅 위젯 하나가 제휴 제의 채널을 열어주는 셈이다.
다음은 이 위젯으로 들어오는 문의를 추적·분류하는 대시보드를 고려 중이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.