PG연동

PG 연동은 대부분의 견적서에서 한 줄짜리 항목으로 들어갑니다. 실제로 테스트 결제 한 건을 성공시키는 데까지는 오래 걸리지 않습니다. 문제는 오픈 이후에 드러납니다.

결제가 되는 것과 정산이 맞는 것은 다른 문제입니다. 결제창은 성공 화면을 보여줬는데 주문 상태는 ‘결제대기’로 남아 있는 건이 하루에 몇 건씩 쌓입니다. 고객센터에는 “카드에서는 금액이 빠져나갔는데 주문 내역이 없다”는 문의가 들어오고, 월말에는 PG사 정산 내역과 자사 주문 합계가 맞지 않습니다. 어긋난 건을 찾으려면 주문, 결제, 취소, 정산 네 곳을 사람이 눈으로 맞춰봐야 합니다.

이런 상황은 드물지 않습니다. 이 단계에서 개발사에 연락하면 대부분 “연동은 정상입니다”라는 답을 받습니다. 틀린 말이 아닙니다. 연동은 정상입니다. 설계되지 않은 것은 예외 처리와 정산 대사(對帳)입니다.

그래서 이 글은 PG 연동을 직접 구현하는 방법이 아니라, 그 예외를 누가 책임지는 구조로 발주할 것인가를 다룹니다.

디비컨설팅(디비스쿨)은 시원스쿨 계열의 IT 아웃소싱 기업으로, 한국인 PM이 검증된 글로벌 개발팀을 직접 관리하는 방식으로 100개 이상의 프로젝트를 수행했습니다. 50개 이상의 글로벌 파트너사와 개발팀을 운영하고 있고, 고객 만족도는 98%입니다. 이커머스 영역에서는 건강 커스터마이징 쇼핑몰인 뉴트리 3.3, B2B 유통 플랫폼인 유통닷컴을 구축했습니다. 아래 내용은 그 과정에서 반복적으로 확인한 것들입니다.

PG사(결제대행사)란?

PG사는 쇼핑몰 대신 카드사, 은행, 간편결제사와 가맹 계약을 맺고 결제 승인과 정산을 중계하는 사업자입니다. PG사를 쓰지 않으면 카드사마다 개별 가맹 계약과 개별 연동이 필요합니다. PG사를 통하면 한 번의 연동으로 여러 결제 수단을 붙이고, 수수료를 차감한 금액을 정해진 주기로 정산받습니다.

국내에서 자주 쓰이는 선택지는 다음과 같습니다. 토스페이먼츠는 개발 문서와 기술 지원이 좋아 신규 구축에서 선호됩니다. 나이스페이는 결제 수단 범위가 넓습니다. KG이니시스는 오래된 PG로 기업 고객 레퍼런스가 많습니다. KCP는 대기업 계열로 안정성 측면에서 선택됩니다.

어디를 쓰든 연동 난이도 차이는 크지 않습니다. 실제 프로젝트의 난이도는 PG사 선택이 아니라, 그 아래에서 발생하는 예외 상황을 어디까지 설계했는가에서 갈립니다.

결제 개발에서 반복되는 실수 5가지

아래 다섯 가지는 기술 이슈처럼 보이지만, 실제로는 모두 “누가 책임지기로 했는가”의 문제입니다. 각 항목 끝에 개발사에 직접 물어볼 질문을 하나씩 붙였습니다.

실수 1 — 결제 성공과 실제 결제 완료를 같다고 보는 것

결제창이 성공을 반환하는 것은 카드사 승인이 떨어졌다는 신호일 뿐입니다. 그 승인 금액이 주문 금액과 같은지, 이미 처리된 주문이 아닌지, 주문에서 허용한 결제 수단인지는 서버가 PG사 API로 다시 조회해 확인해야 합니다.

프론트엔드가 전달한 금액을 그대로 믿고 주문을 완료 처리하면, 요청 값을 임의로 바꾼 주문이 정상 주문으로 들어옵니다. 또한 사용자가 결제 직후 브라우저를 닫으면 성공 처리 로직이 실행되지 않아, 돈은 승인됐는데 주문은 없는 상태가 남습니다.

그래서 승인과 주문 완료 사이에는 서버 사이드 검증과 콜백(webhook) 수신이라는 두 경로가 모두 있어야 합니다. 브라우저가 닫혀도 콜백은 들어오기 때문입니다.

개발사에게 물어볼 것 — 결제 승인 결과를 서버에서 다시 조회해 금액과 주문 번호를 대조합니까, 아니면 결제창 응답을 그대로 신뢰합니까. 결제 도중 브라우저가 닫히면 그 주문은 어떤 경로로 완결됩니까.

실수 2 — 취소·환불 로직을 나중에 생각하는 것

전액 취소는 대부분 구현됩니다. 실무에서 터지는 것은 부분 취소입니다. 세 개 상품 중 하나만 반품되면 배송비 부담은 어떻게 되는지, 적립금과 쿠폰을 섞어 결제한 건에서 무엇부터 돌려주는지, 부분 취소로 결제 금액이 내려가면서 쿠폰 적용 조건이 깨졌을 때 쿠폰을 재발급할 것인지가 모두 정책 결정입니다.

여기에 PG사 정책이 겹칩니다. 카드 취소는 매입 전인지 후인지에 따라 처리가 달라지고, 결제 후 일정 기간이 지나면 PG사 API로는 취소되지 않아 계좌 환불로 처리해야 합니다. 이 규칙이 기획서에 없으면 개발팀은 전액 취소만 만들고, 나머지는 운영팀이 매일 수기로 처리하게 됩니다. 이런 정책 항목을 발주 전에 어디까지 적어야 하는지는 요구사항 정의서 글에서 따로 정리했습니다.

개발사에게 물어볼 것 — 부분 취소 시 포인트, 쿠폰, 배송비 환원 규칙이 문서로 정의되어 있습니까. PG사 취소 가능 기간을 넘긴 건은 어느 화면에서 누가 처리합니까.

실수 3 — 이중결제 방지를 생각하지 않는 것

결제 버튼 비활성화는 가장 약한 방어입니다. 더블 클릭, 결제 후 새로고침, 모바일에서 결제 완료 후 뒤로가기, 네트워크 지연 중 재시도까지 포함하면 같은 주문이 두 번 승인되는 경로는 여러 개입니다.

제대로 된 구조는 주문 생성 시점에 고유 주문 ID를 발급하고, 결제 요청에 멱등성 키(Idempotency Key)를 실어 같은 키로 들어온 두 번째 요청에는 새 결제를 만들지 않고 첫 번째 결과를 그대로 돌려주는 것입니다. 서버에서는 주문 ID 중복 체크를 DB 유니크 제약으로 걸어두는 편이 안전합니다. 애플리케이션 조건문만으로는 동시 요청에서 뚫립니다.

이중결제는 금전 환불로 끝나지 않습니다. 고객 신뢰가 깎이고, 취소 건이 늘면서 정산 대사가 다시 복잡해집니다.

개발사에게 물어볼 것 — 이중결제 방지를 프론트엔드 버튼 제어로 합니까, 서버의 멱등성 키와 DB 제약으로 합니까.

실수 4 — 모바일 결제창 테스트 부족

결제 실패의 상당 부분은 코드가 아니라 실행 환경에서 발생합니다. iOS 사파리의 팝업 차단으로 결제창이 아예 열리지 않는 경우, 카카오톡이나 네이버 인앱 브라우저에서 결제 앱으로 전환된 뒤 원래 페이지로 돌아오지 못하는 경우, Android에서 카드사 앱으로 넘어갔다가 딥링크로 복귀할 때 주문 정보가 사라지는 경우가 대표적입니다.

PC 크롬에서만 테스트하면 이 중 어느 것도 발견되지 않습니다. 그리고 국내 이커머스 결제의 다수는 모바일에서, 그중 상당수는 메신저 인앱 브라우저에서 시작됩니다. 이 검증을 전담할 조직이 있는지가 개발사를 가르는 지점이며, 그 이유는 QA 전담팀 없는 개발사 글에서 다뤘습니다.

개발사에게 물어볼 것 — 검수 체크리스트에 iOS 사파리, 안드로이드 크롬, 카카오톡·네이버 인앱 브라우저가 각각 별도 항목으로 들어 있습니까.

실수 5 — 결제 실패 케이스 UI를 만들지 않는 것

한도 초과, 비밀번호 오류, 카드사 정기 점검 시간, 네트워크 끊김, 결제 도중 뒤로가기. 성공 화면만 준비하면 이 모든 경우가 같은 빈 화면이나 “결제에 실패했습니다” 한 줄로 끝납니다. 사용자는 이유를 모르기 때문에 재시도하지 않고 이탈합니다.

PG사가 내려주는 오류 코드를 사용자 언어로 번역해, 다시 시도할지 다른 카드로 결제할지 장바구니로 돌아갈지 다음 행동을 제시해야 합니다. 동시에 실패 코드를 로그로 남겨야 어떤 실패가 많은지 보고 개선할 수 있습니다. 이 집계 화면은 관리자 페이지 개발 범위에서 가장 자주 빠지는 항목 중 하나입니다.

결제 실패 화면은 디자인 항목이 아니라 매출 회수 장치입니다.

개발사에게 물어볼 것 — 실패 케이스별 화면과 문구가 기획 범위에 포함되어 있습니까. 실패 원인 코드는 집계 가능한 형태로 저장됩니까.

B2B 결제의 특수성

B2B 유통 플랫폼인 유통닷컴을 구축하면서 확인한 것은, B2C 결제 설계를 그대로 옮기면 거의 맞지 않는다는 점입니다. B2B에서는 결제 수단도, 거래가 끝나는 시점도 다릅니다.

• 무통장 입금 확인 자동화 — 법인 거래는 카드보다 계좌 이체 비중이 큽니다. 입금자명이 주문자명과 다른 경우가 일상적이라 자동 매칭이 실패하고, 이를 사람이 맞추면 그 자체가 하루 업무가 됩니다. 주문별 가상계좌를 발급해 입금과 주문을 1:1로 묶는 설계가 기본입니다.
• 전자세금계산서 API — B2B에서는 결제 완료가 아니라 세금계산서 발행까지가 거래의 끝입니다. 발행 API 연동, 역발행 처리, 수정 발행, 월 합계 발행 여부를 개발 전에 정해야 합니다. 나중에 붙이면 기존 주문 데이터를 소급해서 맞춰야 합니다.
• 후불·여신 한도 — 거래처별 외상 한도와 결제 조건(월 마감, 익월 결제)이 주문 승인 로직 안에 들어가야 합니다. 한도를 넘는 주문을 시스템이 막지 못하면 영업과 재무가 수기로 막게 됩니다.
• 사업자등록번호 인증 — 가입 단계에서 진위 확인과 휴폐업 조회를 붙여야 유령 거래처와 미수금이 쌓이지 않습니다.

이 네 가지는 “PG 연동” 작업 범위에 보통 포함되지 않습니다. 견적서에 별도 항목으로 적혀 있지 않다면 포함되지 않았다고 보는 편이 맞습니다.

결제 개발 업체를 고르는 3가지 기준

앞의 다섯 가지 실수와 B2B 항목을 읽고 나면, 업체 선정 기준은 자연스럽게 한 문장으로 정리됩니다. 이것들을 책임질 수 있는 구조를 가진 업체인가입니다. 구체적으로는 세 가지를 확인하면 됩니다.

PG 계약의 주체는 누구인가

PG사 계약, 가맹점 심사, 수수료 협상의 주체는 발주사 명의여야 합니다. 개발사 명의로 계약이 되어 있으면 나중에 업체를 바꿀 때 결제 수단째로 묶입니다. 정산 계좌, 상점 아이디, 심사 이력이 전부 그쪽에 남아 있기 때문입니다.

견적서에 “PG 연동”이라고만 적혀 있으면 네 가지를 물어야 합니다. 계약 주체는 누구인지, 가맹점 심사 서류는 누가 준비하는지, 테스트 상점 계정 발급과 실계정 전환은 누가 진행하는지, 간편결제나 가상계좌 같은 결제 수단을 추가할 때 그 작업이 견적에 포함되는지입니다. 이런 항목을 계약서 단계에서 어떻게 못 박는지는 개발 외주 계약서 글에 정리되어 있습니다.

좋은 개발사는 계약을 대신 해주겠다고 말하지 않습니다. 발주사 명의 계약을 전제로 서류와 일정만 대신 끌고 갑니다.

보안 책임은 어디까지인가

먼저 카드 정보를 자사 서버에 직접 저장하지 않는 구조인지 확인해야 합니다. PG사 결제창 방식이나 빌링키(정기결제용 토큰) 방식이면 카드 번호는 PG사가 보관하고 가맹점은 키만 보유합니다. 저장하지 않는 것이 가장 확실한 보안 대책입니다.

다음은 문서입니다. 개인정보 처리 위탁 계약이 체결되어 있는지, 수탁사 관리·감독 책임이 어떻게 적혀 있는지, 재위탁이 가능한 구조인지를 봐야 합니다. 해외 개발팀이 참여한다면 운영 DB 접근 권한이 누구에게 열려 있는지, 접속 로그가 남는지, 개발·스테이징·운영 환경이 분리되어 있고 운영 데이터가 개발 환경으로 복제되지 않는지까지 확인 대상입니다. 해외 개발팀을 쓸 때 실제로 통제해야 하는 범위는 외주 개발 보안 글에서 따로 다뤘습니다.

보안은 기능이 아니라 계약 조항입니다. 기능은 나중에 추가할 수 있지만, 조항은 사고가 난 뒤에 추가할 수 없습니다.

정산 검수를 누가 설계하는가

결제는 성공했는데 정산 데이터가 틀리면 그 차이는 그대로 돈으로 손해가 납니다. 그래서 주문, 결제, 취소, 정산 네 테이블이 서로 대사되는 구조인지가 핵심입니다. 각 테이블의 건수와 금액 합계가 PG사 정산 내역과 맞는지, 맞지 않는 건을 자동으로 찾아내는 화면이 있는지를 봐야 합니다.

그다음은 검수 기준서입니다. 인수 테스트 항목에 부분 취소 후 정산, 기간 경과 취소, 이중 승인 건 처리 같은 정산 대사 시나리오가 들어 있어야 합니다. 이 시나리오가 없으면 오픈 직후에는 아무 문제가 없어 보이고, 문제는 첫 정산일에 나타납니다. 무엇을 기준으로 완성이라고 승인할지는 개발 검수 기준 글에서 항목별로 정리했습니다.

검수 기준이 없는 견적은 싼 것이 아니라 범위가 미정인 것입니다. 미정인 범위는 오픈 후에 추가 작업으로 돌아옵니다.

어떤 구조로 맡길 것인가

세 가지 기준을 놓고 보면, 발주 방식마다 책임이 어디에 놓이는지가 달라집니다. 단가만 비교하면 보이지 않는 부분입니다.

구분	국내 대형 SI	국내 소규모 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀 (디비컨설팅)
개발 단가	높음	보통	낮음	낮음~보통
요구사항·정산 설계 책임	개발사 (문서 중심)	발주사와 혼재	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	많음	매우 많음	적음
PG·보안 문서 대응	대응 가능	담당자 역량에 따라 다름	발주사 본인	한국 PM이 대응
재작업 리스크	낮음	보통	높음	낮음
총비용 관점	단가가 지배	재작업 여부가 지배	관리 비용이 지배	단가와 관리 비용의 균형

해외 개발팀을 직접 쓰면 단가는 내려가지만, 요구사항 정의와 정산 설계, PG·보안 문서 대응이 전부 발주사 담당자에게 넘어옵니다. 그 시간은 견적서에 적히지 않을 뿐 실제로 발생하는 비용입니다.

디비컨설팅은 그 중간 관리 계층을 한국인 PM이 맡는 구조입니다. 발주사는 한국어로 요구사항을 말하고, 그 문서화와 개발팀 전달, 검수 기준 설계를 PM이 책임집니다. 국내 채용 대비 평균 40~60% 수준의 비용 절감이 가능한 이유도 여기에 있습니다. 다만 그 절감은 설계와 검수가 제대로 되었을 때만 유지됩니다.

디비컨설팅은 이 과정을 어떻게 통제합니까

① 상담 및 요구 분석 — 한국인 PM이 현재 운영 중인 쇼핑몰 구조, 사용 중인 결제 수단, 취소·환불 정책, 정산 주기를 먼저 정리합니다. 이 단계의 결과물은 한국어 요구사항 문서이며, 앞에서 말한 부분 취소 규칙과 정산 대사 항목이 여기에 들어갑니다.

② 개발팀 구성 — 요구사항이 확정되면 2~4주 내에 전담팀을 구성합니다. 결제 프로젝트에는 PG 연동 경험이 있는 백엔드 인력을 우선 배치하고, 모바일 결제창 검증이 필요한 경우 QA 범위를 미리 넓혀 잡습니다.

③ 프로젝트 개발 — 애자일 방식으로 짧은 주기로 산출물을 공유합니다. 결제 영역은 기능 단위가 아니라 시나리오 단위로 확인합니다. 결제 성공, 부분 취소, 기간 경과 취소, 이중 요청, 실패 복귀를 각각 보여드리는 방식입니다. 진행 상황은 발주사가 언제든 볼 수 있게 공유합니다.

④ 테스트 및 배포 — QA 프로세스에 기기·브라우저·인앱 조합을 명시하고, 정산 대사 시나리오를 인수 테스트 항목으로 포함합니다. 테스트 상점에서 실계정으로 전환하는 절차와 롤백 기준도 배포 전에 문서로 정합니다.

⑤ 운영 및 유지보수 — 오픈 후 실패 코드 로그를 보며 이탈 구간을 줄여 나갑니다. 소스코드 소유권은 발주사에 귀속되며, API 명세와 DB 스키마, 배포 절차 문서까지 인계합니다. 내부 개발 조직이 생기면 그대로 넘겨받을 수 있는 상태로 두는 것이 원칙입니다.

쇼핑몰 프론트엔드까지 함께 다시 만드는 경우라면 웹 개발 외주, 모바일 앱에 결제를 붙이는 경우라면 앱 개발 외주 범위에서 함께 검토합니다.

실제 구축 사례

뉴트리 3.3 — 건강 커스터마이징 이커머스 몰. 사용자 상태에 따라 구성이 달라지는 상품을 판매하는 구조여서, 주문 구성과 결제 금액, 취소 단위를 어떻게 묶을지가 설계의 핵심이었던 프로젝트입니다.

유통닷컴 — B2B 유통 플랫폼. 거래처 단위 주문, 무통장 입금 확인, 세금계산서, 여신 조건까지 포함되는 B2B 거래 흐름을 다룬 사례입니다. 앞의 B2B 항목은 이 과정에서 정리된 내용입니다.

이커머스 외에도 디비컨설팅은 삼성물산(홈닉), GS건설(엘리시안 리조트), 하나투어(하나오픈챗), LS일렉트릭(테크스퀘어), 직방(호갱노노), 교보생명(글펍), 가천대학교(학사관리), 와디즈 등 국내 기업·기관 프로젝트를 수행해 왔습니다. 결제 개발과 직접 관련된 사례는 위의 두 건이며, 나머지는 대기업 수준의 요구사항 관리와 검수 절차를 다뤄 온 이력으로 봐주시면 됩니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 이커머스를 운영 중이거나 준비 중인데, 결제·정산 설계를 책임지고 문서로 정리해 줄 담당자가 사내에 없는 경우
• 개발 인력은 외부에 두되, 요구사항 정리와 검수 기준은 한국어로 통제하고 싶은 경우
• B2B 거래가 포함되어 무통장 입금, 세금계산서, 여신 한도까지 시스템에 들어가야 하는 경우
• 기존 쇼핑몰의 결제 모듈만 재구축하거나, 결제 수단을 추가해야 하는 경우
• 전담팀을 빠르게 붙여 일정 안에 오픈해야 하는 경우

반대로 권하지 않습니다

• 이미 사내에 결제 도메인을 이해하는 백엔드 조직이 있는 경우. 이 경우 외부 팀을 넣으면 의사결정 단계만 늘어납니다.
• PG 계약과 정산 프로세스를 이미 운영 중이고 단순 기능 추가만 필요한 경우. 기존 유지보수 인력에게 맡기는 편이 빠릅니다.
• 요구사항을 정의할 내부 담당자를 지정하기 어려운 경우. PM이 문서화를 대신할 수는 있지만, 취소 정책이나 정산 기준 같은 사업 결정은 발주사가 내려야 합니다.
• 완성된 솔루션을 그대로 구매하려는 경우. 디비컨설팅은 맞춤 개발을 수행하는 조직입니다.

자주 묻는 질문

해외 개발팀이라면 의사소통은 어떻게 합니까

발주사는 한국인 PM하고만, 한국어로 소통합니다. 요구사항 정리, 회의, 진행 보고, QA 리포트, 검수 문서가 모두 한국어로 제공됩니다. 개발팀과의 영어 커뮤니케이션과 사양 전달은 PM의 업무 범위이며, 발주사 담당자가 직접 개발자와 영어로 조율할 일은 없습니다.

PG 계약은 저희가 직접 해야 합니까

네, 계약 주체는 발주사입니다. 정산 계좌와 상점 아이디가 발주사에 귀속되어야 나중에 개발사를 바꾸더라도 결제 수단이 묶이지 않습니다. 가맹점 심사 서류 준비, 테스트 계정 발급, 실계정 전환 일정은 PM이 함께 진행합니다.

기획서가 없는데 견적을 받을 수 있습니까

가능합니다. 현재 운영 중인 쇼핑몰 환경, 사용 중이거나 추가하려는 결제 수단, 취소·환불 정책, 정산 주기 네 가지만 정리되면 범위의 윤곽이 잡힙니다. 기획서 작성 자체를 요구 분석 단계에 포함해 진행하는 경우도 많으며, 정확한 범위와 일정은 그 문서가 나온 뒤 확정합니다.

소스코드 소유권은 어떻게 됩니까

소스코드 소유권은 발주사에 귀속됩니다. 프로젝트 종료 시 소스와 함께 API 명세, DB 스키마, 배포 절차 문서를 인계합니다. 결제 영역에서는 PG사 연동 설정값, 콜백 처리 흐름, 정산 대사 기준도 문서에 포함해 다른 개발팀이 이어받을 수 있도록 합니다.

결제 모듈만 부분 발주할 수 있습니까

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 범위에 맞는 계약 형태를 선택할 수 있습니다. 다만 결제만 분리해 개발하더라도 기존 주문·정산 테이블 구조와 취소 정책은 함께 확인해야 하며, 그 부분을 보지 않고 결제만 붙이면 앞에서 말한 정산 불일치가 그대로 남습니다.

정리

결제 개발의 난이도는 PG 연동 자체에 있지 않습니다. 난이도는 예외 처리와 정산에 있습니다. 서버 검증과 콜백, 부분 취소와 기간 경과 취소, 멱등성, 모바일 환경, 실패 복귀, 그리고 네 개 테이블의 대사. 이 목록은 기술 사양처럼 보이지만 실제로는 책임의 목록입니다. 그래서 업체 선정은 누가 더 싸게 붙여주는가가 아니라, 이 예외들을 누가 설계하고 누가 검수 기준에 적어 넣느냐로 결정됩니다. 견적서에서 그 항목들이 보이지 않는다면, 아직 그 일을 맡을 사람이 정해지지 않은 것입니다.