자동매매 서비스 랜딩페이지와 텔레그램 문의 접수

01서버를 두지 않은 이유

의뢰인은 이미 AWS Lightsail 인스턴스를 갖고 있었지만 거기에 올리지 않았습니다. 그 인스턴스는 거래소 API 키를 가진 실거래 시스템이라, 누구나 접속하는 웹페이지와 같은 서버에 두면 위험합니다. 게다가 페이지 하나와 접수 기능 하나 때문에 서버를 따로 두면 인증서 갱신과 OS 패치를 누군가 계속 챙겨야 합니다. 납품하고 끝나는 건에는 맞지 않습니다.

• 문의 내용은 저장하지 않습니다. 접수되면 바로 텔레그램으로 보내고 끝입니다. 저장소가 없으니 유출될 것도 없고 개인정보처리방침도 단순해집니다. 대신 실시간 신청 현황 같은 기능은 만들 수 없는데, 이 점은 의뢰인과 합의했습니다.
• 수신자는 여럿이고 동시에 보냅니다. 한 곳이라도 전달되면 접수 성공으로 처리해서, 수신자 한 명이 봇을 차단해도 문의가 사라지지 않습니다.
• 스팸은 두 가지로 막았습니다. 사람 눈에 안 보이는 입력칸이 채워져 있으면 성공한 것처럼 응답하고 버립니다. 페이지를 연 지 3초 안에 제출된 것은 거부합니다.
• 의뢰인이 유지하길 원한 신청현황 티커는 데이터를 만드는 부분을 따로 떼어 두었습니다. 나중에 그 부분만 바꾸면 실제 데이터가 나옵니다.
• FAQ 35문항은 8개만 먼저 보이고 나머지는 더 보기로 접었습니다. 전부 펼치면 3,453px이던 섹션 높이가 854px로 줄었습니다.

// functions/api/inquiry.js: 접수되면 텔레그램으로 보냄 (골자만)
export async function onRequestPost({ request, env }) {
  const f = await request.formData();
  if (f.get("website"))            return ok();        // 허니팟: 성공 위장 폐기
  if (Date.now() - +f.get("t") < 3000) return reject(); // 타임트랩
  const text = escapeHtml(`[문의] ${f.get("name")} / ${f.get("contact")}\n${f.get("msg")}`);
  const sends = env.CHAT_IDS.split(",").map(id => sendTelegram(env.BOT_TOKEN, id, text));
  const r = await Promise.allSettled(sends);
  return r.some(x => x.status === "fulfilled") ? ok() : fail();
}

02배포에서 겪은 문제

• 처음에는 접수 기능이 배포되지 않아 405 오류가 났습니다. wrangler pages deploy는 functions 폴더를 명령을 실행한 위치 기준으로 찾습니다. 상위 폴더에서 실행했더니 정적 파일만 올라갔습니다. 배포 출력에 Functions 번들을 올렸다는 줄이 없으면 함수가 빠진 것입니다.
• 엉뚱한 계정에 배포될 뻔했습니다. PowerShell이 한글 경로의 토큰 파일을 찾지 못해 인증 값이 비었는데, wrangler는 오류를 내지 않고 저장돼 있던 개발자 개인 계정으로 넘어가 빈 프로젝트를 만들었습니다. 그 뒤로는 배포 전에 wrangler whoami로 대상 계정부터 확인합니다.
• 텔레그램 봇을 교체하고 바로 테스트했더니 성공 응답이 왔는데, 실제 알림은 옛 봇으로 갔습니다. Pages는 환경변수가 배포마다 묶여 있어서, 새 배포가 퍼지기 전에는 운영 주소가 직전 배포로 응답합니다. 지금은 배포 전용 주소가 정상 응답할 때까지 기다린 뒤 운영 주소를 확인합니다.
• 토큰 권한이 모자라 중간에 멈추기도 했습니다. Pages 편집 권한만 받았더니 도메인 추가와 DNS 설정에서 인증 오류가 났습니다. 권한을 적게 받는 것은 맞지만 단계마다 의뢰인에게 다시 요청하는 쪽이 더 번거롭습니다. 이제는 배포, 도메인, DNS, 시크릿까지 필요한 권한을 미리 따져서 처음에 같이 요청합니다.

03디자인 수정이 네 번 돌았습니다

신청현황 영역은 중앙 정렬, 12건이 흘러가는 띠, 분산 배치, 알약 모양 카드 순으로 네 번 바뀌었습니다. "휑하다", "정신없다" 같은 의견을 그림 없이 말로만 주고받았기 때문입니다. 그 뒤로는 시안 두세 개 중에서 방향을 먼저 고르게 하고, 세부 조정은 그다음에 합니다. 수정 횟수가 정해진 계약에서는 이런 왕복이 그대로 손해입니다.

회원가입, 이용권, 자동 쪽지 같은 범위 밖 요구에는 별도라고만 답하지 않고 대략의 규모를 말씀드렸습니다. 규모를 듣고 의뢰인이 우선순위를 정리해 1단계만 진행했습니다. 반대로 링크가 제대로 열리지 않는 것 같은 하자는 무료로 고칩니다. 이 경계는 문서로 나눠 두었습니다.

04관련 사례