Web payment API 의 현재와 미래 - DEVIEW 2015 Day 1

NAVER D2 DEVIEW Day 1

Web Payments API 의 현재와 미래

방진호/임동우 삼성전자

---

네이버 D2 DEVIEW Day 1 의 첫 세션 트랙 2 의 "Web Payments API의 현재와 미래" 라는 주제의 발표였다.

발표자는 삼성전자의 방진호, 임동우 연구원님들.

우연히도 내가 지금까지 해왔던 일이 결제 모듈을 사용하는 Si 성 웹 개발이였고 그 조그마한 배경지식 덕분에 이해에 큰 도움이 되었다.

Web Payments API 는 현재 w3c 주도하에 크롬, 모질라, ms, 애플, 삼성 등 브라우저를 개발하는 기업들에게는 큰 이슈로, Remove difficulty form, just one button 이라는 슬로건을 내세우며 아직은 개발 단계라고 한다.

이 이슈라는게 무엇이냐 하면은, 우선 우리가 지금 사용하고 있는 온라인 결재 시스템을 알아 보아야 한다.

지금은 결재가 다음과 같이 이루어진다.

고객 > 서버 > PG사 결제모듈 > 결제 > PG사 결제모듈 > 서버 > 고객

나름 정형화된 과정이라고 볼 수도 있겠지만 여기에는 큰 맹점이 존재한다. PG사마다 결제모듈 구현 방식이 대부분 상이하다는 점과

고객이 처음 입력하는 결제 정보 폼이 사이트마다 제각각이라는 점이다.

이는 웹 표준이라는 궁극적인 목표를 가지고 있는 w3c 측에서는 매우 거슬리는 존재였고 그에 대한 해결책으로 나온것이

바로 Web Payments API 인 것이다.

이 Web Payments API 는 두 가지로 지원되는데 첫 번째는 간단한 결제 폼의 역할을 하는 것이다.

우리가 가지고 있는 카드 중에는 VISA 나 Union Pay, maestro 등의 마크가 찍혀 있는 카드가 있는데 이런 카드들의 정보(카드번호와 사용년월, 뒷면 CVC 번호 등) 를 통해 결제 할 수 있다. 이 결제 양식의 경우 결제사를 통해 간단하게 결제를 완료할 수 있으므로 Web Payments API 를 통해 원활하게 결제 할 수 있게 된다.

두번째는 단지 결제 정보 저장소만의 역할을 하는 것인데, 이 경우는 아무래도 국내 결제 수단에 좀 더 적합해 보였다.

브라우저가 표준화된 결제 정보를 저장하고 있고 결제 요청이 들어오면 이에 대한 결제정보(결제 카드정보, 를 반환해준다.

이는 서버가 저장해야 하는 정보들을 브라우저 또는 기기에서 저장해놓게 하여 관리해야하는 개인정보에 대한 부담을 줄일 수 있다고 한다.

대신 이 경우는 Web Payments API 를 통하긴 하지만 PG 모듈은 여전히 사용해야 하므로 단계가 추가되어 오히려 더 비효율적이게 되버린다는 점을 언급했고, 지적 당했다.

뭐 이거야 우리나라 PG 결제모듈 작동방식이 통일되어있지 않고 각각 다른 요청 파라미터나 반환형식 등 생김새 자체가 우악스러워서 그렇다고 생각한다.

Web Payments API 의 장점은 다음과 같다고 한다.

User

모든 online mall 에서 익숙한 UX를 사용하여 결제를 진행

처음 이용하는 online mall 에서 쇼핑을 하더라도 저장된 신용카드를 사용 가능

Merchant

결제 시스템을 위한 UX등의 개발 노력 절감

각 merchant가 신용카드 저장을 위한 높은 보안수준의 서버 운용 비용 절감

Web Payments API 라는 Service Worker 가 돌고 웹에서 API 를 호출하게 되면 이 워커가 동작하여 브라우저와의 콜백 이벤트를 통해 진행되는데, 예시에서는 api 호출과 ECMA 스크립트 es6의 Promise 를 통하여 사용하는 모습을 보여주었다.

추가로 API에 대해 자세한 설명이 필요하다면 아래 링크를 추천한다.

https://www.youtube.com/watch?v=FajnnR-9mhE

개인적인 소견으로는

" 국내에 정착하려면 적어도 5~10 년은 걸릴듯 싶다. " 이다.

내가 보고 있는 Web Payments API 의 가장 큰 문제점은 하위 호환이다. 아무래도 브라우저에서 직접 지원하는 API 이다 보니깐 브라우저가 최신 버전이 아니라면(지원 전 버전이라면) 사용을 못하게 되는 것이다.

당장 돈 받고 파는 PG 모듈에서도 볼 수 있는 NP-API 문제나 Active X 문제만 봐도 그렇다. 뭐 이건 기어오는 IE 6~10 사용자들을 지원하다가 최신 브라우저 사용자들을 놓친 경우지만 얘넨 도대체 PG 결제 모듈 개발이 자신들의 주 사업인데도 왜 이렇게 느린 대응을 보이는지 모르겠다.

물론 국내의 IT 문화가 아직 최신 동향과 뒤떨어진것일 뿐 조금만 기다리면 나아질 것이라고는 하지만 이건 사람이 주체가 되는 문제기 때문에 격려한다고 금방 바뀔 수 있는게 아닌 것 같다.

그래서 친구와 얘기 중 나온게 위 소견이다.

국내 정착이 언제 될지에 대하여 데뷰에 같이 참석한 친구는 3년을 불렀지만 나는 3년은 너무 모자라다고 하였다. 개발 완료에는 3년은 충분하고도 남는건 맞다. 잘 하면 해외에서는 3년안에 널리 사용하게 될 지도 모른다.

하지만 국내는 아니다. 황무지에 씨뿌리고 물준다고 농사 안된다.

일단 국내는 뿌리에 깊게 박힌 "하위버전 지원" 에 대한 집착부터 버려야 한다고 생각한다.

물론 고객층이 하위버전을 쓰고 있기에 어쩔수 없다고 할 수도 있지만 당장의 변명일 뿐이다. 사회의 주력 고객층의 연령대가 조금 씩 낮아지면서 최신 문물에 눈을 뜨고 있다. 열심히 지원해봤자 지원하는 쪽만 고생한다. 그렇다고 상황이 나아지느냐, 그것도 아닌게 이미 눈에 보이고 있지 않은가...

뭐 사실 내가 아무리 이렇게 얼굴 벌개져서 투덜대봤자 바뀌려면 멀었다 난 그저 언제 쯤 웹 개발자들이 IE 하위버전 polyfill 에 골머리 썩이는 일을 그만둘 수 있을지 모르겠다.

ㅜㅜ