포트원 API 시크릿키를 며느리도 모르고, GPT도 몰랐다
결제도입 이모저모
결제의 벽을 넘다
앞서 잠시 이야기했었지만, 토스 페이먼츠 도입 검토를 폐기하고, 포트원 서비스를 이용하기로 했다.
독립몰이지만 수수료를 내지 않고 이용할 수 있다는 점에서 묻지마 선택!
그렇게 사흘인가?
정말 열심히 뺑이쳤다 ㅎㅎㅎㅎㅎ
생각만큼 쉽지 않았던 결제 도입의 벽
우선 어떤 서비스를 이용하느냐 부터 쉽지가 않았다. 내가 임대형 쇼핑몰을 쓰고 있었다면 모두 해결될 문제였지만, 난 워드프레스 같은 타입도 아니고 완전히 독립된 자체 플랫폼인지라 직접 PG사들과 계약하고 결제 도입을 되려면 가입비와 연회비가 발생하는 구조였다.
이때 알게 된 게 포트원이었다.
그들은 나와 같은 입장의 사람들에게 보다 쉽게 PG사들을 연결시켜주는 플랫폼이었고, 감사하게도 포트원을 통하면 가입비와 연회비가 발생하지 않았다. 다만, 이건 이용 건당 별로 수수료가 조금 더 나가는 식인데, 스타트업에겐 충분히 감당할 수 있는 범위였고 매출이 넘어선다면 그때까서 PG사들과 직거래로 전환을 해도 좋으니 문제될 게 없었다.
포트원의 수익 모델
그럼, 대체 포트원 같은 업체는 왜 가맹비와 연회비를 면제해주는 걸까? 그들이 대납을 해주나?
수익 모델이 궁금해질 만 한데, 그건 바로 개발자 맞춤의 편의성 때문이다.
PG회사들도 당연히 웹으로 판을 벌렸으니 회사에 개발자들이 있고, 그들이 가맹점들에게 이용안내를 해주기도 한다.
헌데, 그게 서로에게 여간 어려운 게 아니다. 사용자들은 아무런 고민 없이 쓰는 기기와 시스템들이지만, 소프트웨어로 쌓아 올린 시스템이란 게 그렇다. 기기 별로 되는 놈도 있고, 안되는 놈도 있으며, 의외의 구간에서 종종 에러도 터지는데, 그게 또 개발 환경 별로도 차이가 발생한다. 문자 그대로 ㅈㄹ인 셈이다.
그럴 때 포트원 같은 업체가 등장해서 교통 정리를 해주니 PG사들은 감사할 뿐이다. 일단 PG사는 어차피 가맹비나 연회비가 없어도 결제 건당 수수료로 이익을 취할 수 있다. 거기에 가맹비나 연회비를 포기하는 대신 그만큼의 불편한 as전화를 받지 않아도 그만큼의 인력과 자원을 아낄 수 있게 되는 셈이다. 어찌 보면 조금 덜 벌더라도 번거로움과 리스크를 확 줄이고 순수하게 생산성만 더 챙기는 셈이니 서로에게 윈윈인 셈이다.
개발자들이 쓰는 용어로 좀 단적으로 말해보자면, 포트원은 여러 PG사들이 저마다의 개발 기술로 만든 '콜백', 즉 '웹훅' 시스템에 자신들만의 표준 껍데기를 씌워서 사용자들에게 제공해 주고 있다.
쉽게 말해, 토스의 개발 언어는 전라도 사투리를 쓰고, kg이니시스는 강원도 사투리르 쓰고, 카카오는 경남, 네이버는 경북, nhn kcp는 충청도 사투리를 쓰고 있었다면,
내가 토스와 거래를 하다가 어느 순간 kg이니시스로 서비스를 변경하려면 난리가 나는 거다. 왜냐면, 같은 걸 두고도 서로 표현하는 개발 언어가 달라서 거기에 익숙해지는 데에만 꽤 긴 시간이 필요해질 테니 말이다.
그런데 포트원 같은 업체가 튀어나와서 표준어로 갈무리를 해주는 거다.
네? 암호화를 어찌하신다고요? MD5? 그걸 아직도 쓰셔요? 아니, 그쪽은 SHA-256이라고요? 아뇨, 다들 들어보세요. 서울 경기도는 이렇게 합니다.
멋지지 않은가? 개발 도구의 일원화를 통한 편의성 확보가 그들의 무기다. 나처럼 대략 느낌적인 느낌으로다가 바이브코딩 하는 얼간이에겐 최고인 셈이다.
웹훅이란?
우선 웹훅의 개념부터 말하자면...
내가 주유소를 운영하는 사장이라고 치자. 그리고 내 사업체에 하루에 수십, 수백 대의 차량이 다녀간다고 치자. 그럼 수금하기만 해도 바쁠 텐데 카드 승인 전체 과정을 하나하나, 다 실시간으로 직접 확인할 수가 있을까?
그거야 카드사가 알아서 해주겠지? 물론, 알아서 해주긴 해준다. 다만, 그걸 어떻게 신뢰할 수 있냐는 거다.
이때 등장하는 신뢰의 도구가 콜백, 웹훅이다. 아날로그틱한 구시대적인 감성으로 이야기하자면, 확인 전화란 말이다.
손님의 카드를 단말기에(온라인 사이트 결제창에) 긁는다. 그럼, 카드사가 PG에게 전화를 하고, PG사가 다시 우리 주유소로 전화를 준다.
"사장님, 그거 정상 승인 났어요!"
물론, 이런 번잡한 과정을 손님들은 알 필요가 없다. 사장인 나도 앞에서 티낼 필요가 없다. 그러니 등뒤로 몰래 알려주는 거다.
그러니 몰래 확인시켜주는 전화가 웹훅이란 소리다.
포트원의 장점이자 단점, 웹훅
그런데 이 웹훅의 과정을 표준어로 구사하는 게 포트원 같은 플랫폼 업체라고 보면 된다고 했었다.
나머지는 다 저마다의 개발 언어를 쓰고 있다고. 그러니 이건 분명 포트원의 강력한 장점이다.
그리고 아이러니하게도 이게 곧 단점이기도 하다.
어째서?
아무리 번듯한 표준어라도 나처럼 이웃 나라나 외계에서 온 사람에겐 낯선 말에 불과하기 때문이며, 결국 이들도 개발자들이다 보니 실제 포트원 서비스를 이용하는 사람들(그러니까 결제 시스템을 현장에서 연결 시켜주는 실무자들)의 수준을 기본적으로 꽤 높게 잡아둔 모양새다.
그만큼 관리자 페이지 등이 좀 허술한 면이 있다.
그리고 그 허술함 덕에 난 꼬박 사흘을 날렸다
웹훅에 대한 기본 기대치의 차이로 어긋난 시작
지난 사흘간의 삽질에 대해 하나하나 써보자면 정말 끝이 없다.
대충 큰 사건 몇 가지만 말해보자면
웹훅에 대한 기본적인 기대치가 있었다. 그래서 필수적으로 몇몇 정보를 알려주리라 생각했는데, 주질 않았다. 덕분에 잘못된 설계를 하게 되었고, 대체 왜 결제가 정상완료가 되지 않는 것인지... 처음에는 이해를 못했었다.
페이먼트id 복사 매핑 시도와 전환. 1번의 삽질 끝에 알게 된 건 내가 고객들로부터 받는 주문서와 pg사가 결제요청을 받은 건이
내 개념에서는 동일하지만, 그건 내 생각일 뿐이었다는 거다.
결국 사용자가 남긴 주문 정보와 결제요청을 시도한 사용자가 동일인이란 걸 누군가는 확인시켜줘야 한다.
어이없게도 이게 쉽지가 않았다;;; 내가 그간 내 상식 선에서 쉽겠다고 생각했던 많은 게 ㅋㅋㅋㅋㅋ 실제 개발 현장에서는 쉬운 게 하나도 없었다ㅎ
여튼 우여곡절 끝에 GPT의 활약으로 결제 최종 단계 정보 매핑이 이루어졌었다.
그리고 딱 30분 정도 행복했었다. 왜냐면, 이후 이제 로직이 완성되었다며, 하나하나 디버그 로그를 걷어내며 코드를 안정화 시키는 과정에서 날려먹었던 거다. 뭐를? 여태, 아직까지도 모를, 뭔가를 ㅋㅋㅋㅋㅋ
정말이다. 난 지금도 이해가 가질 않는다. 대체 어째서 갑자기 되던 게 안되는 걸까???? 지금도 미스테리다. 왜냐면, 후에 알게 된 문제와도 연결이 되지 않기 때문이다. 정말 귀신에 홀린 기분이다. 절대 결제승인이 나서는 안되는데, 났었던 것이기 때문이다.
그럼, 대체 왜 승인이 나면 안되었던 것인지부터 말해보자.
그건 내가 환경변수에서 포트원 V2 API의 시크릿키 설정을 잘못했기 때문이다. ㅡㅡ;;; 아, 포트원 V2 API의 시크릿키가 뭐냐고? 음... 쉽게 말해 아무나 암호화 된 전화를 도청해서는 안되는 거니까. 키를 가진 사람들만 통신을 하는 거다.
그 키의 번호를 내가 허튼 걸 집어넣고 있었단 소리다.
그런데 그걸 꼬박 하루하고 반나절을 더 허비하는 동안 전혀 모르고 있었다. 왜냐면, 정상적으로 로그 확인이 어려운 환경 탓이었다.
일단 결제가 정상적으로 되는지를 보려면 테스트 결제라도 실제와 똑같이 결제창이 뜨고, 닫혀야 한다. 온라인에서 카드를 실제로 긁어봐야 한다는 소리다.
문제는 PG사의 카드결제창이 뜨면 개발자 콘솔 브라우저 지원이 안된다. 보안의 문제이다 보니 강제로 개발자 콘솔은 열리지 않게 되는 거다. 게다가 이게 또 로컬에서는 테스트조차 안되는 경우가 많다. ㅡㅡ;;; 수정할 때마다 온라인으로 재배포를 하면서 봐야 하는 완전 노가다다;;;
여튼, 그래서 평소와는 달리 개발자 콘솔 로그를 볼 수 없으니 차선책으로 verel의 로그를 본다던가 supabase에서 별도의 테이블을 생성해서 봐야하는 식이었다. (그러니 이것들을 그 환경에 맞춰서 만드는 것부터가 일이란 소리다...)
일이 이렇다보니 시크릿키를 잘못 넣었을 거란 상상을 못했다. 일단 그것 자체는 vercel 로그에 찍히지도 않기 때문이다. 그냥 웹훅 신호가 왔다가 결과가 넘어가지 않고 뻗어버리는 식이었다 ㅡㅡ;;;
그러니 다음 페이지로 넘어가지 못하는 이유를 모른 채 주구장창 잘못된 온갖 가설을 GPT와 검증해가며 미세조정만 해댄 거다 ㅎㅎㅎㅎ
결국 해피엔딩
그렇게 사흘 간 몇 번이나 설계 관점을 변경했었고, 그에 따른 로직을 새로 짰고, 몇 개의 라우터 폴더, 파일과 프론트 페이지 파일을 만들고, 폐기하고...
여튼 그랬다.
그리고 오늘이다.
중간에 애들도 아팠고, 나도 아직 아프고, 다른 일도 해야 하는데 ㅡ 이게 마무리가 빨리 나지 않다보니 꽤 오래 빙빙빙 돌아서 왔다.
이제 남은 건 주문 관리자 페이지 생성과 결제자와 배송정보 공유. 그리고 부가적인 간편 결제 도입과 해외 결제 도입이 남았다.
뭐, 어쨌든 1월 중에는 다들 끝나주길 바란다.