아마존닷컴 계정 막혔다가 다시 푼 이야기

8월초 아마존닷컴에 접속했더니 오랫만에 와서 그랬는지 어쨌는지 비밀번호를 변경해야 하는데 그 전에 먼저 핸드폰 번호를 넣으라고 나왔다. 막히고 나서야 아차 싶었던것이 핸드폰 끝번호 두자리를 먼저 보여줬는데 그걸 무시하고 원래 내 핸드폰 번호를 넣었다. 틀리다고 한다. 어라? 국가번호 82부터 넣었어야 했나? 뺐어야 했나? 다시 입력, 또 틀리단다. 82뒤에 010을 8210으로 써야 하나 82010으로써야 하나? 다시 시도. 또 틀리단다. 이렇게 몇번 틀리고 나니 너무 많이 틀렸다면서 계정이 잠겨버렸다. 아! 생각해보니 먼저 나왔던 끝자리 번호 두개는 배대지 서비스에서 제공하는 현지 사무소 전화번호 끝자리였다.

다시 로그인 시도하니 가입한 메일로 OTP번호를 보낼테니 인증하라고 나왔다. 그래 그럼 그렇지. 하고 메일로 받은 6자리 숫자를 넣었다. 이때 화면 캡춰를 하지 않은게 아쉬운데, OTP번호를 맞게 넣었지만 계정에 문제가 있으니 고객센터로 연락을 하란다. 그런데 고객센터라는 것이 아무리 찾아도 일단 로그인을 하고 문의를 하게 되어 있었고 한참을 찾은 링크는 비로그인 상태에서도 접수를 할 수 있는 폼메일이었으나 반복적으로 일시적 장애 화면이 떴다. 브라우저를 바꿔도 보고 VPN도 켜보고 별 수를 다 써도 계속 같은 오류가 반복되었다.

다음날, 다다음날 해봐도 마찬가지. 아마존닷컴에서 물건 산것도 많이 없으니 계정을 새로 파던지 해야할까…하고 며칠 방치하다가 어제 밤에 아마존 프라임 비디오건으로 다시 로그인을 시도해 봤다. 오! 처음에 봤던 그 전화번호 입력 요구가 떴다. 얼른 배대지 사이트를 열고 전화번호를 찾아 입력했다. 됐다. 비빌번호 변경 창이 나왔다. 새로 비밀번호를 지정하고나서 정상적으로 로그인을 할 수 있었다. 8월 9일경 처음 그 사달이 났고 중간에 로그인 시도했지만 OTP번호를 맞게 넣어도 풀리지 않았던 일까지 감안하면 얼추 열흘 정도 후에 다시 시도했을 때 (아마존이 보기에) 비정상적인 계정에 대한 잦은 로그인 시도 차단이 풀린 것같다. 물론 3일나 5일뒤에 풀렸을수도 있겠지만 그 사이에 접속시도를 하지 않았으니 확인할 수는 없고.

입력된 전화번호 확인 요구에 막혀 계정이 잠긴 경우 열흘정도 쉬었다가 로그인하면 해결할 수 있을 것이고 용감하다면 더 짧은 시간안에 시도해볼 수도 있을것이다. 성공하면 다행. 실패하면 대기 기간 다시 처음부터. ㅎ…

옥션의 이상한 반품진행 메세지

어제 옥션에서 물품을 하나 구입했는데 기대했던 제품이 아니었다. 다시 제품 설명 사진을 살펴보았더니 아뿔사 내 착각이었다. 할수없이 구매자 귀책사유로 반품신청을 했다. 신청 후 5분쯤 지나서 메일과 문자가 날아왔는데 반품 요청과 사유에 대해 판매자가 반품보류란다.

무슨 소린가 해서 반품정보에 가보니 아무튼 그렇게 됐단다. 4시55분에 반품신청을 하고 반품배송비를 결제하라고 해서 했더니만 6분뒤에 물품이 도착하지 않아 반품을 보류한단다.

고객센터에 전화해서 무슨 상황인지 물었다. 자동반품처리(?)던가 그런 비슷한 용어였는데, 그리 처리되지 않게 하기 위해 자동으로 보류처리가 된거란다. 고객 입장에서는 이해할 수 없는 안내문, 메일, 문자를 받았다고 하니 자기네도 알고 있고 개선요청을 했으나 아직 수정되지 않았다 한다.

옆방이 아닌 이상 6분내 물품 반품이 이루어질 순 없는 노릇이고, 반품이 보류되었으면 물품은 과연 가져갈 것인지, 만약 안가져간다면 내 반품과 환불을 어찌될 것인지 고객은 어리둥절할 수 밖에 없다. 문의 메일을 넣든 문의 전화를 하든 C/S부서에 (서비스단에서 수정했다면 문의할 필요가 없는) 불필요한 문의로 서로간에 시간과 노력을 빼앗는 처리방식이 아닐 수 없다.

실명인증 후에도 로봇이 아님을 증명해야하는 페이지

인천공항을 이용하다가 친절하거나 또는 불친절한 직원을 만난 일이 있어서 이를 홈페이지를 통해 알리고자 했다. 모바일로 접속했는데 휴대폰으로 본인인증을 해야했다. 이러한 절차가 늘 그러하듯 이통사를 선택하고 이름, 성별, 국적, 생년월일과 약관 동의여부 체크박스 4개에 체크하고 인증키를 보내라고 요청했다. 잠시후 문자메세지로 숫자6개가 도착했고 모바일 홈페이지에 입력하여 본인인증을 완료했다.

나오는 양식에 제목적고 본문에 이러저러한 사연을 적고나니 자동입력방지를 위해 captcha코드를 입력하라고 한다. 자동화된 프로그램이 서버로 내용을 보내 관리자든 서버자원으로부터든 쓸데없이 시간과 비용을 소모하지 못하게 만든 ‘실제 사람임을 입증’하라는 것이다. 그런데 이 captcha는 공개게시판,손님게시판,방명록 등 불특정다수가 접근할 수 있는 게시판에서나 사용하는 것이지, 이통사에 등록된 사용자 정보를 제공하고 휴대폰으로 인증키를 받고 그 키를 웹페이지에 입력하는 과정을 거친 걸러지고 걸러진 진짜 사람에게까지 다시 또 사람임을 입증하라는 것은 넌센스다. 실명임은 확인했지만 사람임은 확인되지 않았다는 것일까?

이게 만약 매출이 일어나는 프로세스였다면 이런 괴상하고 불필요한 절차가 들어갔을리가 없다. 어쩌면 처음에는 captcha만 넣었다가 보안 강화를 위해 본인인증을 추가한 뒤에도 빼지 않았다거나, 외주 개발업체에서 그냥 그렇게 만들었거나 했을 가능성이 있다. 매우 적은 수의 고객만 홈페이지에서 이 메뉴를 이용할 것이고 그 중에서 본인인증을 완료해도 여전히 로봇이 아님을 입증하라는 과정이 이상하다고 생각하지 않을 수도 있고, 설령 불편하더라도 감수하고 입력했을 수도 있다.

이 중복인증을 보니 예전 회사 홈페이지를 외주 기획/개발은 맡겼다가 겪은 일이 생각난다. 이 업체는 본문 우측하단에 새끼손톱만하게 플로팅 UI로 페이지업, 페이지다운 버튼을 만들어 온 적이 있었다. 키보드의 page up/down 키도 아니고 그냥 스페이스바 툭툭 치는 것도 아니고, 마우스의 휠 굴리기도 아니고, 트랙패드의 제스츄어도 아니고, 커서를 그 페이지 업/다운이라는 버튼위로 가져가서 콕콕 눌러서 페이지를 이동하게 한단다. 사용자가 실제로 어떻게 쓰는지, 이게 필요한 기능인지, 이걸 써서 고객의 시간과 노력을 줄여주는지, 효율성과 어뷰징방지의 명분과 실리를 다 만족시키는지… 별로 고민하지 않고 만든 기능이었다.

워드프레스를 웹호스팅에서 AWS 프리티어로 이전완료

지금 사용하고 있는 워드프레스를 웹호스팅에서 AWS 프리티어로 이전완료하였다. 이전하게 된 동기는 워드프레스 5.2버젼에 대한 업데이트 알림이 떠서 진행하려다보니, 웹호스팅업체의 서버 PHP버젼 (5.6.7)이 낮아서 업데이트 사양(5.6.20)에 모자랐다.

호스팅업체에 PHP 업데이트 계획을 문의했더니 업데이트 계획이 없다면서 서버이전 신청을 하라는 답변을 받았다. 워드프레스는 계속 버젼이 업데이트 될 것이고 여기에는 기능 향상뿐 아니라 보안 이슈 패치들이 포함될텐데 앞으로 업데이트를 할 수 없는 서버환경이라면 더 이상 사용할 수 없게 되었다고 볼 수 밖에 없었다. 서버이전도 그러하다, 고객님 현재 서버는 이러이러한데 원하시는 조건의 서버는 이런 상품군이 있으며 비용은 얼마이니 필요시 신청하시기 바란다, 라고 써줬으면 충분히 고려할 수 있었을것이다.

어제 낮에 AWS에 계정 새로 만들고 짬짬이 작업하여 방금 전 대략 이전을 마무리하였다. 기존 사용환경과 AWS 프리티어의 사용환경이 모든 사람이 동일하지 않다보니 은근한 삽질과 스트레스가 있었다.

워드프레스 백업,복원 플러그인들은 자기 서버 안에서 백업과 복원이지 다른 시스템으로의 이사(마이그레이션)은 선택지가 많지 않았다. 일단 첨부파일들은 기존 서버에서 FTP로, DB는 phpmyadmin으로 받아두었다. 그러나 복원을 위해서 신규 AWS 서버에 phpmyadmin이 없었고 ftp 접속을 위해서는 ftp데몬을 설치해야 했다. 아무튼,

생각나는대로 이전과정에서 사용한 서비스와 방법들을 정리해본다.

  • 첨부파일은 FTP로 받아서 sFTP로 업로드 했고 DB는 All-in-One WordPress migration 플러그인을 이용했다.
  • 포스트 내부에서 이 블로그의 다른 퍼머링크로 향하는 링크는 Migrate DB 플러그인으로 변환하였다.
  • 기존 hof.pe.kr/wp/archives/포스트아이디 구조는 hof.pe.kr/포스트아이디로 변경하였다. 내부 문서 간 상호 참조 링크는 위 플러그인으로 변경하였다.
  • 검색엔진이나 외부 사이트에서 이 블로그의 퍼머링크로 향하는 링크는 끊어지게 되었으나, 복구 방법을 찾는 중이다. 예전에 b2시절부터 계속(16년째) 깨지지 않게 유지하고 있는 중.
  • ftp업로드를 위해서는 vsftpd를 설치하고 포트를 열어주었다
  • 맥에서 filezilla로 ftp 업로드를 하기 위해선 개인키 파일 pem을 ppk로 변환해야 했고 이를 위해 puttygen을 설치해야 한다. 그러기 위해선 homebrew를 먼저 깔아야했다. 하..
  • 네임서버를 웹호스팅업체가 제공하는 서버에서 aws의 Route 53으로 변경하였고 큰 문제없이 수분내에 적용되었다.
  • SSL인증서는 검색해보니 AWS의 ACM(Amazon Certificate Manager)을 이용해야하는 줄 알고 인증서 발급, route 53에 등록, 로드밸런서 생성까지 나와있어서 다 따라했지만 실패. bitnami 패키지를 설치했다면 쉬운 방법이 있었다, https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/

남은 과제

  • 인증서 3개월마다 자동갱신하기 위한 크론 설정
  • 외부 사이트에서 기존 퍼머링크 구조로 들어오는 트래픽을 바뀐 퍼머링크로 리다이렉션 (redirection 플러그인)
  • 1년뒤의 이야기겠지만 프리티어 사용기한 종료 후 라이트세일로 변경

결과

  • 기존 메인화면 로딩에 1.8~1.9초 정도 걸렸었는데 이전 후 0.7초 정도로 속도 향상이 있다. 프리티어가 이 정도라면.. ㄷㄷㄷ…

웹호스팅에 워드프레스 돌리는 것과는 비교할 수 없이 어려웠다. 서버관리에 대한 지식의 수준에 따라 차이가 있겠지만 말이다. 조금씩 차근차근 배워가는 것이 아니라 aws계정 등록하고 곧바로 서버 셋팅과 필요한 패키지, 보안와 트래픽 정책, 과금에 대한 고려, 데이타 마이그레이션과 워드프레스 설정 등 필요한 전체 지식이 한꺼번에 필요했다. 이전하기 전에 다른 블로그와 도움말등을 통해서 미리 감을 잡아보았으나 실전은 또 다른문제였고 모든 요소들과 정책들이 내 경우와 동일한 사람은 없었다. 블로그 하나 운영하기 위해 이런 노력을 들이는 것이 필요할까, 서버 유지보수에 대한 앞으로의 부담까지 져야할 가치가 있을까… 하는 고민이 아직도 있긴하다.

일단 블로그는 AWS에서 돌아가게 됐고 차차 사용성을 보아가며 향후 정책을 정하기로 하였다.

맥북프로 액정고장 및 수리

5일전 아침에 일어나서 잠시 맥북을 사용하다가 화면이 껌뻑거리기 시작했다. 외장모니터를 주력으로 사용하고 맥북은 그 앞에 45도 정도만 열어놓고 키보드와 트랙패드를 사용하도록 구성해두었는데 반쯤 접힌 맥북이 번쩍번쩍하는것이었다. 화면을 열어보니 세로줄무늬와 깨진 격자등이 난무해서 도저히 알아볼 수가 없었다. 반면 외부모니터는 아무 이상없치 평온한 상태.애플 고객센터에 전화해서 예약을 잡은 후 다음날 오전에 가로수길 애플 지니어스바를 방문했다.

제품을 본 담당자는, 이런 문제는 액정을 자주 열고 닫거나 화면 상단덮개쪽에 압력이 가해진 경우에서 비롯된 경우가 많다고 하였다. 덮개와 본체를 이어주는 플렉스 케이블쪽 문제가 있으면 이렇게 세로방향 문제가 생긴단다. 수리는 공휴일 포함 5일 정도 걸릴 것이라 하였다.

예정보다 하루 빠르게 4일만에 수리가 완료되었다는 연락을 받고 다시 애플 가로수길을 찾아갔다. 액정뿐 아니라 상판뚜껑까지 전체를 교환하였다고 한다. 뚜껑 바깥쪽 애플로고를 보호하는 테이프가 붙어있는 점이 특이했다. 신품 구매시에는 없던 것 같았는데..

수리비는 86만원가량이 나왔으나 다행이 애플케어 보증프로그램이 적용되었다. 그러고보니 기본 보증 외 구매한 애플케어 보증이 작년 7월부터 내년 7월까지인데, 작년 가을에 키보드 문제로 하판 (키보드 및 키보드를 둘러싸고 있는 케이스 전체와 배터리)을 교체받았고 이번에는 액정과 뚜껑쪽을 교체받았으니 보드,CPU, 램 및 저장장치를 뺀 거의 전체를 보증프로그램으로 교체한 셈. 작년 수리비가 46만원돈이었으니 이번 수리건까지 포함하면 30여만원짜리 보증연장 프로그램 구매 효과는 톡톡히 봤다.

고장 원인 중 하나인 기기에 가해진 압력은, 고양이 녀석이 가끔 맥북을 뚜껑덮고 자리를 비우면 그때 남은 온기를 즐기느라 맥북에 올라와서 엎드리는 경우가 있는데 그것 말고는 압력받을 환경이 아니었다. 고양이가 쿵쿵 뛰는것도 아니고 슬그머니 엎드리는건데 이런 압력이 고장으로까지 이어지는 치명적인 요인이었을까..를 생각하면 갸우뚱 하긴 하다. 어쩌면 그저 다양한 요인이 합쳐지고 이른바 뽑기운이 안좋아서 좀 까리한 맥북이 그냥 기계들이 고장나듯, “그냥 고장”난 것일 수도 있다.

그래도 혹시나 싶어 맥북을 접어두고 외부 키보드와 마우스를 한번 써볼까 싶긴 하다. 한번 해보니 의외로 이 구성이 더 편리할 수도 있는 일 아니겠는가.