AI로 만든 서비스에서 가장 많이 “거의 다 됐는데…”라고 느끼는 구간이 로그인과 결제입니다. 화면만 보면 버튼 몇 개를 붙이면 끝날 것 같지만, 실제로는 외부 서비스 계정, 보안키, Redirect URL, 서버 검증, 주문 상태, 실패 처리처럼 코드 밖의 절차와 운영 규칙이 절반 이상입니다.
이 글에서는 비개발자 대표가 서비스 런칭을 준비할 때 로그인과 결제를 어떤 순서로 붙여야 하는지 설명합니다.
1. 로그인부터: 직접 비밀번호 시스템을 만들지 않는 이유
초기 서비스라면 이메일·비밀번호 인증을 처음부터 직접 구현하기보다 관리형 인증 서비스를 쓰는 것이 일반적으로 안전하고 빠릅니다. 관리형 Auth는 회원가입, 로그인, 이메일 인증, 비밀번호 재설정, OAuth 연동 같은 복잡한 기능을 이미 제공합니다.
직접 구현하면 생각보다 많은 문제가 생깁니다.
- 비밀번호 해싱 방식
- 로그인 시도 제한
- 비밀번호 재설정 토큰
- 이메일 인증
- 세션 만료
- 로그인 유지
- 탈퇴 사용자 처리
- 소셜 로그인 계정 중복
AI는 이런 기능의 코드를 빠르게 만들 수 있지만 “코드가 생성됐다”와 “인증 시스템이 안전하다”는 같은 말이 아닙니다.
2. 로그인은 화면이 아니라 세션 설계다
로그인 버튼을 눌러 성공했다면 그 다음 질문은 **“서버가 이 사람이 누구인지 어떻게 계속 아는가?”**입니다.
보통 세션 쿠키 또는 토큰 기반으로 사용자 상태를 유지합니다. 여기서 대표가 이해해야 할 것은 기술 이름보다 다음 세 가지입니다.
- 로그인 성공 정보를 브라우저 어디에 보관하는가
- 서버 API를 호출할 때 본인임을 어떻게 증명하는가
- 로그아웃·만료·탈퇴 시 그 권한을 어떻게 끊는가
운영에서 자주 생기는 오류는 localhost에서는 쿠키가 유지되는데 실제 HTTPS 도메인에서는 쿠키 설정이 달라 로그인 상태가 풀리는 것입니다.
3. 소셜 로그인은 “키 발급 + Redirect URL”이 핵심
카카오, 네이버, Google, Apple 로그인은 버튼 디자인보다 외부 개발자 콘솔 설정이 중요합니다.
일반적인 흐름은 다음과 같습니다.
사용자 → 소셜 로그인 화면 → 동의 → 서비스의 Callback URL → 우리 서버/인증 서비스가 사용자 확인 → 세션 생성
개발 중에는 localhost Callback을 쓰다가 운영 도메인으로 바꾸는 순간 실패하는 이유가 많습니다. 소셜 제공자 콘솔에 운영 URL이 등록되어 있지 않거나, 앱 상태·심사·동의항목 설정이 다르기 때문입니다.
따라서 소셜 로그인은 마지막 날 붙이는 기능이 아니라 운영 도메인이 생긴 직후부터 테스트해야 하는 기능입니다.
4. 로그인 후 반드시 필요한 권한 구분
모든 로그인 사용자가 같은 권한을 가지면 관리자 URL만 알아도 민감한 화면에 접근할 수 있는 문제가 생길 수 있습니다.
최소한 다음 역할은 구분하는 것이 좋습니다.
- 일반 사용자
- 운영자
- 관리자
중요한 것은 메뉴를 숨기는 것이 아니라 서버에서 권한을 검사하는 것입니다. 브라우저 화면에서 관리자 메뉴를 보이지 않게 해도 API 호출 권한이 열려 있으면 보안이 되지 않습니다.
5. 결제는 ‘결제창’보다 주문 상태 설계가 먼저다
결제를 붙이기 전 데이터 구조부터 정해야 합니다.
최소한 하나의 주문에는 다음 상태가 필요합니다.
- 주문 생성
- 결제 대기
- 결제 완료
- 취소 요청
- 취소 완료
- 실패
서비스 성격에 따라 환불, 부분취소, 구독, 가상계좌처럼 더 많은 상태가 필요합니다.
이 상태가 없으면 “결제는 성공했는데 서비스 이용권이 지급되지 않음”, “환불했는데 주문은 결제완료로 남음” 같은 운영 문제가 생깁니다.
6. 결제는 브라우저 성공 화면만 믿으면 안 된다
일반적인 결제는 다음 두 단계로 생각하면 이해하기 쉽습니다.
- 사용자가 결제수단 인증을 완료한다.
- 우리 서버가 PG의 승인 API를 호출해 최종 결제를 확정한다.
브라우저에서 success 페이지가 열렸다고 주문을 바로 “결제완료”로 바꾸지 않는 것이 중요합니다. 서버가 PG와 최종 검증한 결과를 기준으로 상태를 변경해야 합니다.
토스페이먼츠 공식 문서 역시 API 호출에 시크릿 키를 사용하며, 시크릿 키를 외부에 노출하지 말아야 한다고 안내합니다. 브라우저 코드나 GitHub에 시크릿 키를 넣는 것은 피해야 합니다.
7. 테스트 키와 라이브 키를 분리한다
결제 서비스는 대개 테스트 환경과 실제 결제 환경을 분리합니다. 개발 초기에 실제 카드 결제가 일어나지 않도록 테스트 키로 충분히 검증한 뒤, 계약·심사·운영 설정을 마치고 라이브 키로 전환합니다.
여기서 실무 체크포인트는 다음입니다.
- 테스트/라이브 키를 섞지 않았는가
- 라이브 Secret이 서버에만 저장되는가
- 운영 도메인이 결제 서비스 설정에 등록되어 있는가
- 결제 성공/실패 URL이 운영 주소인가
- 개발용 주문 데이터와 실결제 주문을 구분하는가
8. 웹훅은 “나중에 상태가 바뀌는 결제”에 필요하다
웹훅(Webhook)은 결제 상태가 바뀌었을 때 PG가 우리 서버에 알려주는 방식입니다. 예를 들어 결제 취소, 가상계좌 입금, 일부 결제상태 변경처럼 사용자가 우리 화면에 없을 때도 상태가 바뀔 수 있습니다.
토스페이먼츠 공식 문서도 결제 상태 변경 등을 Webhook 이벤트로 제공합니다. 따라서 주문 상태를 브라우저 리다이렉트만으로 관리하지 말고, Webhook과 조회 API를 함께 고려하는 것이 좋습니다.
9. 환불/취소를 첫날부터 설계해야 하는 이유
초기 팀은 “매출이 발생하면 그때 환불을 만들자”고 생각하기 쉽습니다. 하지만 실제 첫 고객부터 오입력, 중복결제, 일정 변경, 서비스 불만 같은 상황이 생길 수 있습니다.
최소 관리자 기능에 다음이 필요합니다.
- 결제 내역 조회
- 주문번호·결제키 확인
- 취소 실행 또는 취소 요청 처리
- 취소 결과 기록
- 부분취소 가능 여부 확인
- 고객에게 취소 완료 안내
개발자가 없을 때 PG 관리자 콘솔에서 직접 취소할 수 있더라도, 우리 서비스 DB의 주문 상태와 맞지 않으면 나중에 정산이 꼬입니다.
10. 로그인과 결제를 붙이는 현실적인 순서
1단계 — 운영 도메인 확보
소셜 로그인 Callback과 결제 URL을 미리 운영 주소 기준으로 테스트할 수 있게 합니다.
2단계 — 관리형 인증 도입
이메일 로그인을 먼저 붙이고 회원 ID 체계를 안정화합니다.
3단계 — 사용자 프로필과 권한 구조 확정
Auth ID와 우리 서비스의 User/Profile 데이터를 어떻게 연결할지 정합니다.
4단계 — 소셜 로그인 1~2종 추가
타깃 고객에게 중요한 채널부터 붙입니다.
5단계 — 주문 테이블부터 설계
상품, 금액, 주문상태, 사용자, 생성일시, 결제 식별값을 저장합니다.
6단계 — PG 테스트 결제
테스트 키로 요청 → 인증 → 서버 승인 → 주문상태 업데이트 전체 흐름을 완성합니다.
7단계 — 실패/취소/중복 요청 처리
정상 성공만 테스트하지 말고 실패 케이스를 만듭니다.
8단계 — Webhook과 운영 로그
상태 변경을 놓치지 않게 하고, 결제 관련 오류를 추적할 로그를 남깁니다.
9단계 — 라이브 전환
PG 계약/심사 및 운영 설정이 끝난 후 라이브 키로 바꿉니다.
운영 전 체크리스트
| 항목 | 확인 질문 |
|---|---|
| Auth | 비밀번호/세션을 직접 불안전하게 구현하지 않았는가 |
| OAuth | 운영 Redirect URL이 모두 등록되어 있는가 |
| 권한 | 관리자 API가 서버에서 권한 검증되는가 |
| Secret | Secret Key가 클라이언트와 Git에 노출되지 않는가 |
| 주문 | 결제 상태를 저장할 데이터 구조가 있는가 |
| 승인 | 브라우저 성공 화면이 아니라 서버 승인 결과를 기준으로 하는가 |
| Webhook | 비동기 상태 변경을 받을 준비가 되어 있는가 |
| 취소 | 환불/취소 후 서비스 DB도 함께 갱신되는가 |
| 로그 | 결제 실패 사유를 추적할 수 있는가 |
정리
로그인과 결제는 “AI가 코드를 잘 짜느냐”보다 서비스의 사용자·권한·주문 상태를 얼마나 명확하게 설계하느냐가 중요합니다. 초기에는 복잡한 자체 인증이나 결제 엔진을 만들지 말고 검증된 관리형 서비스를 이용하되, 계정과 Secret, 주문 데이터는 반드시 회사가 통제해야 합니다.
완주 관점의 핵심: 로그인 버튼과 결제창이 뜨는 것이 완료가 아니라 관리자가 고객과 주문 상태를 이해하고, 문제 발생 시 직접 대응할 수 있는 상태가 완료입니다.
참고자료
- 토스페이먼츠 API 키 안내: https://docs.tosspayments.com/reference/using-api/api-keys
- 토스페이먼츠 인증 헤더: https://docs.tosspayments.com/reference/using-api/authorization
- 토스페이먼츠 Webhook 가이드: https://docs.tosspayments.com/guides/v2/webhook