PM을 위한 AI 실무 사전 5편 — PG, CORS, 도메인, OAuth

누구나법률 5장(그래서 직접 벌기로 했다)에서 나온 개념 네 가지: PG(결제대행사), CORS, 도메인/DNS, OAuth.

PG(결제대행사)란

온라인에서 카드 결제를 직접 처리하려면 PCI-DSS 같은 보안 인증, 카드사별 개별 계약이 필요하다. 개인·소규모 서비스가 감당하기 어려운 진입장벽이다. **PG(Payment Gateway, 결제대행사)**는 이 복잡한 과정을 대신 처리해주고, 서비스는 PG가 제공하는 SDK/API만 붙이면 결제를 받을 수 있게 해준다. 토스페이먼츠, 아임포트(포트원), 나이스페이먼츠 같은 곳들이 국내 PG의 예다.

실무 흐름은 대체로 이렇다.

 

사용자가 "결제하기" 클릭
→ PG가 제공하는 결제창 호출 (실제 카드정보는 PG 서버가 처리, 우리 서버는 안 봄)
→ 결제 성공 시 PG가 우리 서버로 "이 결제 진짜 승인됐어요" 신호를 줌
→ 우리 서버가 그 신호를 PG 서버에 재확인(승인 API 호출)한 뒤에야 진짜로 유료 전환

마지막 재확인 단계가 중요하다. 클라이언트(브라우저)가 보내는 "결제 성공했어요" 신호만 믿으면, 그 신호를 위조해서 결제 없이 유료 기능을 쓰는 게 가능해진다. 그래서 서버가 PG 서버에 직접 물어봐서 진짜 승인된 결제인지, 금액이 맞는지 재확인하는 절차가 필수다.

CORS — 왜 프론트와 백엔드 도메인이 다르면 막히나

브라우저는 보안을 위해 "지금 보고 있는 페이지의 도메인과 다른 도메인으로 가는 요청"을 기본적으로 차단한다. 프론트엔드(예: vercel.app)와 백엔드(예: fly.dev)가 서로 다른 도메인이면, 브라우저가 자동으로 그 요청을 막아버린다. 이걸 허용하려면 백엔드가 "이 도메인에서 오는 요청은 허용한다"고 명시적으로 응답 헤더에 적어줘야 한다 — 이 메커니즘이 CORS(Cross-Origin Resource Sharing)다.

실무에서 자주 하는 실수는 허용 도메인을 하드코딩해두는 것이다. 도메인이 하나 추가되거나 바뀔 때마다 코드를 고치고 재배포해야 한다. 환경변수로 빼두면(이 프로젝트는 FRONTEND_URL), 배포 설정만 바꿔서 재배포 없이 대응할 수 있다. 여러 도메인을 동시에 허용해야 할 때는(예: 새 커스텀 도메인 + 기존 기본 도메인을 같이 살려두는 전환기) 콤마로 구분한 목록을 받아 파싱하는 식으로 처리하면 된다.

도메인 / DNS / CNAME

도메인을 사면(예: 가비아·후이즈에서 구매) 그 자체로는 아무 서버도 안 가리킨다. **DNS(Domain Name System)**에 "이 도메인으로 오면 실제로 어느 서버로 연결해라"는 레코드를 등록해야 실제로 연결된다.

자주 쓰는 레코드 타입 두 가지:

• A 레코드 — 도메인을 특정 IP 주소에 직접 연결
• CNAME 레코드 — 도메인을 다른 도메인(예: 호스팅사가 제공하는 주소)에 별칭으로 연결. Vercel·Fly.io 같은 클라우드 호스팅은 IP가 고정이 아닌 경우가 많아서 CNAME을 주로 쓴다

실무 팁 하나 — 호스팅사에 따라 "네임서버 위임"이라는 더 강력한 옵션을 제시하기도 하는데, 이건 도메인 전체의 DNS 관리 권한을 통째로 넘기는 것이다. 그 도메인 밑에 이미 다른 서비스(블로그 등)가 떠 있다면, 네임서버 위임을 잘못 설정하는 순간 그 서비스까지 같이 끊길 수 있다. 서브도메인 하나만 특정 서비스에 연결하고 싶다면, CNAME 레코드로 그 서브도메인만 추가하는 게 안전하다.

OAuth — "카카오로 로그인"의 원리

OAuth는 사용자가 우리 서비스에 비밀번호를 새로 만들지 않고, 이미 갖고 있는 다른 계정(카카오·구글 등)으로 인증하게 해주는 표준이다. 흐름을 단순화하면:

 

사용자가 "카카오 로그인" 클릭
→ 카카오 로그인 화면으로 이동, 사용자가 카카오에서 직접 인증
→ 카카오가 "이 사람 인증 완료" 코드를 우리 백엔드로 전달
→ 우리 백엔드가 그 코드로 카카오에 "이 사람 정보 좀 주세요" 요청
→ 사용자 식별값(이름 등) 받아서 우리 DB에 저장, 우리 서비스 자체 로그인 토큰 발급

여기서 실무적으로 놓치기 쉬운 지점 — 인증이 끝나면 사용자를 우리 서비스의 특정 페이지로 "돌려보내야" 하는데, 이 리다이렉트 주소가 여러 도메인을 지원하도록 잘못 설계돼 있으면 깨진 URL로 리다이렉트되는 사고가 날 수 있다. 여러 도메인을 허용하는 CORS 설정과, 실제로 사용자를 돌려보낼 "단 하나의" 리다이렉트 목적지는 서로 다른 문제라는 걸 구분해야 한다.

---

다음 실무 사전 편은 누구나법률 6장(완성 그 이후, 운영이라는 두 번째 산)이 발행된 후, 그 안에 나오는 개념들을 정리해서 이어간다.