코드보다 PG 계약이 더 어려웠다... — Agreeon 개발기

#agreeon#pg#결제연동#사이드프로젝트#개발기

@agreeon

15일 전

링크 복사 또는 네이티브 공유

Agreeon은 스쿠버다이빙처럼 활동 전 동의서와 서명이 필요한 곳을 위한 전자서명 서비스입니다.

처음 시작할 때만 해도 생각은 단순했습니다.

종이로 받던 동의서를 온라인으로 받고,

서명한 문서를 관리할 수 있으면 훨씬 편하지 않을까?

스쿠버샵에서는 교육이나 체험 전 참가자의 정보를 받고, 여러 동의사항을 확인한 뒤 서명을 받아야 합니다.

이 과정을 조금 더 간단하게 만들어보자는 생각에서 Agreeon을 만들기 시작했습니다.

처음에는 전자서명이 가장 어려울 줄 알았습니다

개발을 시작할 때는 당연히 서명 기능이 가장 고민이었습니다.

동의서 생성
참가자 정보 입력
웹에서 서명
서명된 문서 보관
운영자가 서명 현황 확인

이런 기능들을 하나씩 만들다 보면 어느 정도 서비스의 모습이 갖춰집니다.

그런데 실제로 서비스를 운영하려고 하니 예상하지 못했던 곳에서 훨씬 많은 시간을 쓰게 됐습니다.

바로 결제였습니다.

결제 버튼 하나를 붙인다고 끝나는 게 아니었다

처음에는 개발자답게 생각했습니다.

PG API 연동하고 결제 버튼 만들면 되는 것 아닌가?

실제로 개발 환경에서 결제를 붙이는 것 자체는 그렇게 낯선 작업은 아니었습니다.

PortOne을 이용하면 여러 PG사를 비교적 동일한 인터페이스에서 연동할 수도 있습니다.

문제는 테스트가 아니라 실제 운영 결제였습니다.

운영 환경으로 넘어가려면 PG사와 계약하고 심사를 받아야 합니다.

그리고 여기부터는 코드와 완전히 다른 세계였습니다.

PG 심사는 생각보다 확인할 것이 많았다

Agreeon에서는 단순히 상품 하나를 판매하는 것보다, 서비스 이용권이나 반복 결제까지 고려하고 있었습니다.

이 과정에서 KG이니시스와 NHN KCP 등의 결제 방식을 알아봤고, 실제 계약 절차도 진행했습니다.

그런데 알아볼수록 단순히

사업자등록 → PG 신청 → 승인

정도로 끝나는 과정은 아니었습니다.

서비스가 무엇인지, 무엇을 판매하는지, 결제 방식은 무엇인지, 실제 사이트가 어느 정도 구현되어 있는지 등 여러 부분을 확인하게 됩니다.

특히 제가 알아보는 과정에서는 업종이나 사업 형태, 결제 상품의 성격에 따라 심사 기준이 달라질 수 있다는 점이 가장 어렵게 느껴졌습니다.

개발자는 기능을 구현하면 된다고 생각하기 쉬운데, PG사 입장에서는 결국 실제 돈이 오가는 서비스이기 때문에 보는 관점 자체가 달랐습니다.

정기결제를 붙이면서 새로운 용어들을 배우기 시작했다

NHN KCP 정기결제를 준비하면서는 처음 보는 항목도 많았습니다.

예를 들어

자동결제 서비스 부가합의서
보증보험
상점 ID
정기자동결제 그룹 ID
본인인증 관련 설정
과세 구분
수동 승인 사용 여부

같은 것들입니다.

개발 문서만 보고 있을 때는 보이지 않던 것들이 실제 계약 단계로 가면서 하나씩 등장했습니다.

특히 정기결제는 단순 카드 결제와 달리 한번 인증한 결제수단을 이후에도 사용해야 하기 때문에 일반 결제보다 확인해야 할 부분이 많았습니다.

테스트 환경에서 본 인증 방식과 운영 환경에서 실제 제공되는 방식이 어떻게 다른지도 확인해야 했습니다.

개발보다 어려웠던 건 '무엇을 선택해야 하는가'였다

개발 중 오류가 나면 보통 원인을 찾을 수 있습니다.

로그를 보고, 문서를 보고, 코드를 수정하면 됩니다.

하지만 PG 계약 과정에서는 정답이 명확하지 않은 질문이 자주 나왔습니다.

이 항목은 무엇으로 신청해야 하지?

이 서비스는 어떤 업종으로 보는 게 맞을까?

자동결제 그룹은 어떻게 구성해야 하지?

이 서류의 효력발생일은 언제로 적어야 하지?

아직 발급받지 못한 상점 정보는 어디서 확인하지?

이런 작은 질문들이 계속 생겼습니다.

하나하나는 별것 아닌 것 같지만 실제 서비스를 처음 운영하는 사람에게는 꽤 큰 장벽입니다.

그래서 Agreeon을 만들면서 재미있었던 점은 코딩 외에 서비스를 실제 사업으로 운영하기 위해 필요한 것들을 강제로 배우게 됐다는 것입니다.

결제를 붙이니 사이드 프로젝트가 조금 다르게 보였다

결제를 붙이기 전까지 Agreeon은 제가 만든 또 하나의 웹 서비스에 가까웠습니다.

그런데 PG 계약을 진행하고, 결제 심사를 받고, 실제 운영 환경을 준비하면서 느낌이 조금 달라졌습니다.

사용자가 실제 돈을 내는 순간부터는

환불은 어떻게 할 것인지
이용권은 언제까지 사용할 수 있는지
결제 실패는 어떻게 처리할지
개인정보는 어떻게 관리할지
서비스 장애가 발생하면 어떻게 할지

같은 문제도 같이 생각해야 합니다.

기능을 하나 더 만드는 것보다 이런 운영 문제를 하나씩 결정하는 일이 오히려 서비스를 더 현실적으로 만들어주는 것 같습니다.

Agreeon은 아직 시작 단계입니다

Agreeon의 목표가 거창한 전자계약 플랫폼이 되는 것은 아닙니다.

우선은 스쿠버샵처럼 활동 전에 동의서와 서명을 반복해서 받아야 하는 곳에서 실제로 편하게 사용할 수 있는 서비스를 만드는 것이 목표입니다.

종이 동의서를 출력하고, 작성하고, 다시 보관하는 과정 대신

동의서 전송 → 참가자 작성 및 서명 → 운영자 확인

이 자연스럽게 이어지게 만들고 싶습니다.

그리고 실제 사용자가 생기면 지금 제가 생각하지 못한 불편함도 분명히 나오게 될 것 같습니다.

만들면서 계속 배우고 있습니다

Agreeon을 만들며 느낀 것은 제품을 만드는 일이 결국 코드만 작성하는 일은 아니라는 점입니다.

전자서명을 구현하는 것도 개발이고,

결제를 붙이는 것도 개발이지만,

PG사와 계약하고, 심사를 받고, 정책을 확인하고, 실제 사용자가 돈을 지불할 수 있는 상태까지 만드는 것 역시 제품 개발의 일부였습니다.

아직 Agreeon은 완성된 서비스라기보다 계속 만들어가는 서비스에 가깝습니다.

그래도 하나씩 실제 운영에 필요한 조건들을 통과하면서 조금씩 '동작하는 사이드 프로젝트'에서 '사용할 수 있는 서비스'로 넘어가는 과정을 경험하고 있습니다.

앞으로 실제 스쿠버샵에서 Agreeon을 사용해보고, 그 과정에서 생기는 시행착오 역시 계속 기록해보려고 합니다.

https://agreeon.kr

이 글이 도움됐다면 좋아요를 눌러주세요

로그인하면 댓글을 작성할 수 있습니다.