[개안뽑] ㉑결제 모듈을 분리해야 보안, 속도 문제를 개선할 수 있다

결제 모듈이 서비스와 결합되어 있으면 해킹 당했을 때 회사가 망할 수도 있다
최소한 결제 부분이 분리되어야 해킹 당해도 소비자 피해는 막을 수 있어서 분리는 필수
결제 기능 분리하니 속도 개선, 관리 개선, 운영 개선까지 함께 따라와
이미 플러그인들이 다 나와있어서 분리 작업도 긴 시간 쓰지 않아도 됐음

워드프레스로 만든 웹페이지를 통째로 갈아엎고 다시 만든 적은 많지만, 서비스 페이지를 만들었다가 포기하거나 다시 뜯어고친 적은 10번 남짓 밖에 되지 않는다. 그 중 가장 가볍게 잘 돌아갔던 페이지를 고르라면 당연히 글 100개 남짓 이외에는 아무것도 없던 파비블로그고, 가장 불만이 많았던 페이지는 내가 직접 만든 경우는 파비클래스 시즌1, 개발이 만든 페이지는 SIAI 홈페이지다.

불만이 많았던 페이지들은 공통적으로 각종 기능들이 많이 붙어있었는데, 워드프레스라는 서비스 자체가 플러그인을 하나씩 추가할 때마다 서비스가 무거워진다. 웹사이트 로딩 속도만 느려지는 것이 아니라, 서비스 관리 자체가 총괄적으로 다 느려지기 때문에,

최대한 성능에 영향을 주지 않는 플러그인을 골라야
플러그인을 효율적으로 쓸 수 있도록 각종 셋팅 조정을 해야

한다. 아마 이 문제를 해결하기 위해 찾아봐야 하는 수 많은 문서가 영어로 되어 있기 때문에 한국에서 일반인들이 워드프레스를 이용한 웹사이트 제작을 망설이는 것이리라.

결제 모듈 분리 – 보안, 속도 문제의 작은 해결책

개발자들을 다 내보내고, 우리 회사 웹서비스들을 직접 하나하나 다 만들면서 내가 느낀 것은, 워드프레스에 대한 각종 비난, 비판에 대응하려고 수 많은 문서들을 이미 서비스들이 만들어놨고, 그걸 단순히 적용만해도 대부분의 문제를 해결할 수 있는데도 불구하고 사람들이 너무 정보를 찾는데 인색하다는 것이었다. 개발자들 용어로 ‘바닐라 (Vanilla) 상태’, 즉 아무것도 손을 안 댄 상태에서 모든 게 잘 돌아가야 한다는 생각들을 하시는 것 같은데, 당장

‘딥러닝이 무조건 제일 좋은거 아닌가요?’,
‘제일 좋은 딥러닝 놔두고 왜 통계학 배워야하나요?’

처럼 뭔가 지적 대화를 하고 싶은 생각이 들지 않는 사람들이 연상된다.

학생들에게 데이터 상황에 맞게, 풀어야 하는 문제에 맞게, 주어진 데이터와 모델을 어떻게 뜯어고쳐야하는지를 끊임없이 가르쳐서 학위를 주는 대학 교육 과정을 운영하고 있는 사람 입장에서, 서비스 상태에 맞게 워드프레스를 조금씩 보완해야한다는 설명은 그렇게 새롭게 들리지 않는다. 당연한 것 아닌가? 모든 곳에 공통적으로 다 적용되는 만능 해결사, 즉 ‘자동화’에 대한 맹렬한 갈망이 있는 공돌이들이 아니라면, 사람마다 다 선호가 다르고, 회사마다 사정이 다 다르고, 결국 고객과 회사 사정에 따라 다른 시스템을 만들어야 한다는 것을 상식적으로 받아들일 수 있을 것이다.

이번에 결제 모듈, 특히 정기 결제 모듈을 붙이면서 내가 가장 고민했던 내용은 결제 웹사이트 분리였다. 이미 해킹을 여러차례 당했고, 정기 결제 시스템을 돌리던 중간에 또 해킹을 당하면 회사 손해가 막대한 것은 둘째 문제고 자칫 개인정보 유출의 위험도 컸기 때문이다. 최소한 서비스 페이지가 해킹을 당하는데서 막을 수 있으면, 결제 서비스가 살아있으니, 서비스는 복구만 하면 문제가 크게 커지기 전에 막을 수 있다. 결제 페이지 보안만 몇 배로 더 강화하고, 서비스 백업을 좀 더 자주하면 충분히 막을 수 있는 문제가 되는 것이다.

1월 말, 2월 초 당시에 개발자들이 네이버/카카오 소셜 로그인 연동도 제대로 못 하고 있던 시절, 결제 모듈을 파비뉴스 대신에 파비페이로 만들어서 붙여넣고, 파비뉴스와 파비페이 연동을 시키면 안 되겠냐고 물어본 적이 있다. 그 분들이 당황한 표정을 짓고, 그렇게 모를 때는 그간 경험상 학습하는데 장시간을 쓸 것 같아서 결국 포기를 했었는데, 이번에 내가 이 부분에 쓴 시간은 2일, 그 후 웹사이트 속도 개선을 위한 캐시와 충돌일어나는 문제 보완, 파비페이 페이지 디자인 등등에 쓴 시간을 모두 포함해서 추가 1주일을 더 쓰지는 않은 것 같다.

그간 개발자들을 뽑아서 쓴 경험을 미뤄봤을 때, 나보다 몇 배의 시간이 더 걸렸을 것이다는 수준이 아니라, 아예 못했을 것이라고 꽤나 확신할 수 있다. RESTful API가 만들어져 있고, Webhook 연동만 하면 되는데, 이게 그렇게 경력직 개발자들의 표정을 얼어붙게 할만큼 어려운 일들이었나?

결제 모듈이 분리된 서비스, 원래는 개발자들이 당연하게 생각하는 서비스

예전에 어느 영어권 서비스 개발자들이 영어권 커뮤니티인 Reddit에서 갑론을박을 벌인 글을 본 적이 있는데, 워드프레스에서 가장 널리 쓰이는 결제 연동 플러그인인 ‘우커머스(Woocommerce)’가 웹사이트를 너무 느리게 하는 주 원인이고, 해킹 당하면 DB에 있는 모든 정보를 빼갈 우려가 있으니까 워드프레스를 쓰면 안 된다는 주장을 한 댓글이 있었다.

반박 댓글에서 그럼 독립적인 웹사이트 하나를 더 만들고, 웹서비스/DB 비밀번호를 다르게 설정하고, DB에 글을 쓰는 기능이 있는 모든 플러그인을 결제 웹사이트에서 없애버리면 되지 않냐는 답변을 본 적이 있다.

그럼 실제 서비스에 설치한 어느 플러그인이 해킹을 당해도 결제 정보까지 외부로 유출되는 일은 없을 거란다.

같은 정보가 실제로 한국 개발자들 사이에서도 통용되고 있나 싶어서 구글 검색을 해 보면, 한국에서도 개발자들이 계속 서비스가 기능이 많아지고 콘텐츠가 많아져서 DB가 무거워지는 것이 부담이라는 개발자 커뮤니티의 글이 있고, 결국에는 결제 기능을 분리해야 서비스 속도는 물론 안전성도 높일 수 있다는 댓글도 볼 수 있다.

즉, 위의 내용은 특별히 뭔가 고급 지식이 아니라, 개발자들 사이에서 통용되는 상식이었던 것이다. 근데 왜 그렇게 당황하고 충격먹은 표정이었을까? 왜 일을 시켜놓으면 ‘공부’하는데만 족히 1달은 넘게 걸릴 것 같은 표정이었을까?

영어권에 검색을 해보면 멤버십 서비스 운영을 돕는 대부분의 플러그인들이 우커머스 연동을 안 해 놨다. 아마 따로 부가 수수료를 달라고 했기 때문일 것 같은데, 덕분에 우커머스와 멤버십 서비스들을 연동해주는 각종 플러그인들이 이미 나와있고, 위에서 설명한대로 대부분은 워드프레스의 RESTful API를 이용해 Webhook 연동을 해주는 방식이다.

여느 기능과 마찬가지로, 연간 100~200달러 남짓을 내면 코드 한 줄 안 치고도 서비스에 적용할 수 있도록 서비스들이 나온지 이미 몇 년이 지난 상태, 서비스들이 이미 ‘검증’이 다 된 상태인 것이다.

누워 잠들기 전에 검색 몇 번을 해 보고는 위의 정보를 얻으면서, 역시 개발자를 뽑을 필요가 없었다는 확신을 또 갖게 됐다.

보안 문제, 속도 문제, 관리 문제, 운영 문제……

워드프레스 멀티사이트에 올려놓은 서비스 중 현재 돌아가는 서비스가 15개, 내년 말까지 돌리려고 하는 서비스는 30개가 넘는다. 만약에 결제 기능이 필요한 모든 사이트에 우커머스를 설치했으면, 결제 관련해서 장부정리를 해야할 때마다 모든 사이트들을 들락날락거려야 했을 것이다.

근데 이렇게 1개 서비스에 모아놓으면, 굳이 그럴 필요가 없어진다. 상품 이름만 바꿔서 검색하면 끝이다. 분리된 상황이었으면 최소한 각각의 우커머스 DB를 읽어와서 결합하는 SQL문을 하나 작성해서 갖고 있었어야 하고, 우커머스 특수 기능으로 플러그인을 하나 사면, 모든 사이트에 적용하기 위해 라이선스를 1개가 아니라 수십개를 사야했다.

보안 이슈도 모든 사이트에 다 적용해야했고, 모든 사이트가 우커머스 결제 모듈 때문에 느려지는 것도 다 고민해야했고, 기자, 편집자, 총괄 관리자 등등에게 적용되는 권한들도 다 수정을 해야했다. 콘텐츠 총괄 관리자가 굳이 우리 결제 금액을 볼 수 있도록 열어줄 필요는 없지 않나?

근데 이렇게 웹사이트를 아예 분리해버리면 위의 모든 문제들이 깔끔하게 해결된다. 어차피 결제가 하루 수만, 수십만건 일어나는 서비스도 아닌데, 괜히 설치가 되어 있다는 이유만으로 서비스를 무겁게 하는 것을 뻔히 알면서 속을 썩힐 필요도 없고, 관리하고 싶으면 독립된 결제 서비스에만 들어가보면 되는 구조가 됐다.

한국에서 결제가 많은 서비스를 하고 있었으면 스타트업 대상으로 소형 결제 모듈 서비스 등록할 수 있도록 열어준 금감원 규정을 이용해서 아예 결제 모듈을 공식 서비스로 등록하는 것도 생각해볼 수 있겠지만, 그런 회사가 아니니까 이 정도에서 손을 놓을 생각이다. 차라리 결제 모듈에 부가 기능을 더 넣어서 사용자 경험을 더 개선하는 것이 맞는 것 같다.

코드 한 줄 안 치고 이런 문제들을 다 해결할 수 있도록 이미 글로벌 솔루션들이 다 나와있는데, 이걸 왜 Step1부터 막히는 개발자들에게 시켰을까? 조금만 더 열심히 읽고 찾아봤으면 매년 수억원의 개발자 급여를 아낄 수 있었을텐데….