Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

토스가 현대카드를 연동하는 방법에 동의하지 않습니다

얼마 전에 토스에 들어가니 현대카드 연동을 하면 3,000원을 준다고 나왔다. 난 후잉에서 가계부를 쓰고 있으므로 이렇게 카드 연동해서 명세를 보여줄 때의 유용성이 별로 없기는 하지만 3,000원에 눈이 멀어서 내 카드 정보를 넘기고야 말았다.

결론부터 얘기하자면 토스의 카드사 연동 방식이 나한테는 너무 불안해서 이해할 수 없다. 금융 쪽 도메인 지식이 없어서 좀 더 고민해봐야겠지만 일반 서비스라면 바로 탈퇴를 고려할 사항이라고 생각하고 있다. 나는 토스가 현대카드의 웹서비스 비밀번호를 내부에 저장하고 있다가 카드 명세를 사용할 때 이 비밀번호를 계속 사용하는 것으로 강력하게 의심하고 있다.(현대카드만 그런지 다른 카드사도 마찬가지인지는 나는 알지 못한다. ) 내부 구현은 모르기에 고객센터를 통해서 문의했으나 원하는 답변을 얻지 못했다. 내가 착각했나 해서 재연동을 한 후에 다시 확인해 봤지만 같은 상황으로 이어졌기에 난 여전히 같은 의심을 하고 있다.

이 글을 완성하지 못하고 저녁을 먹고 놀고 오는 와중에 고객센터에서 받은 답변과는 다른 답변을 트위터 토스 계정에서 받았고 추가로 다른 정보도 얻게 되어 글의 뉘앙스가 좀 달라지었는데 원래 쓰려던 글의 상황에 대해 설명을 하고 후반에 추가로 트위터로 받은 정보에 대해 얘기를 하려고 한다. 며칠 동안 트위터 등에서 이 일에 대해서 많이 구시렁댔고 내 글도 많이 리트윗되고 비슷한 얘기의 글이 리트윗되는 것도 꽤 봤다. 내가 트위터에 올린 글은 다 파악하고 올린 것이 아니라 그때그때 올린 것이기 때문에 더 확실히 파악된 상황에서 정리를 해보려고 한다.

상황 설명

며칠 전에 토스에서 현대카드 연동을 하니까 곧바로 현대카드에서 비밀번호가 변경되었다는 문자가 왔다. 당시에 "왜 비밀번호가 바뀌었지?"라고 생각했지만, 당시에는 다른 걸 하고 있으면서 엑티브 엑스 설치와 싸우고 있었기에 무심코 넘어갔고 이후 비밀번호를 리셋하고 현대카드 서비스를 계속 이용했다.

그리고 16일 트위터를 보다가 아래의 트윗을 보고 이게 나만 겪은 일이 아니라는 것을 깨달았다.

그러고는 이게 무슨 상황인지 고민을 하기 시작했다.

  • 연동하는데 왜 비밀번호를 바꾸었지?
  • 비밀번호를 어떻게 바꾼 거지?
  • 현대카드는 이걸 허용하나?
  • 연동하기 위해서 비밀번호를 바꾸었다면 비밀번호를 내가 다시 변경했는데 계속 연동이 되나?

여러 가지 의문이 들어서 이후에도 몇 가지 테스트를 해봤지만(과정은 아래에서 자세히 설명한다.) 아무래도 토스가 내 현대카드 비밀번호를 저장해두고 명세를 가져온다는 의심이 크게 들어서 트위터를 통해 토스에 문의했지만, 답변을 받지 못했고 다음 날 고객센터를 통해서 다시 문의했다.

토스의 1:1 고객센터 문의

여기서 중요 부분은 아랫부분이다.

임시로 변경되는 비밀번호를 저희 토스에서 수집/저장을 하는 것은 아닙니다.

분명히 비밀번호를 따로 사용하고 있지 않다고 하고 있고(수집/저장을 얘기하고 있지만, 수집/저장을 하지 않고 사용할 수는 없으니까) 이후에도 질문했지만 사용하고 있지 않고 5회 비밀번호 틀린 것은 토스가 한 것이 아니라서 토스가 대답할 수 없는 부분이라고 대답하고 있다.

그래서 전날 불안해서 토스에서 등록된 현대카드를 모두 삭제했지만(연동해제가 없어서 일일이 삭제를...) 고객센터의 답변이 정말인지 확인하기 위해서 다시 현대카드를 연동해서 테스트했다.

문제 상황 재현

토스에서 카드사 연동을 하면 "문자 인증으로 연결하기"라는 방식을 제공하고 있다.(다른 연결 방법은 시도해 보지 않았다.)

토스의 카드 문자인증 화면

문자로 온 인증번호를 입력하면 연동하는데 약간의 시간이 걸린 뒤 연동이 완료되는데 바로 현대카드에서 비밀번호가 변경되었다는 문자가 온다.

현대카드의 비밀번호 변경 알림

이는 토스가 실제로 내 현대카드의 계정의 비밀번호를 변경한 것이다.

토스의 카드 연동시 비밀번호 변경 안내

문의 후 확인해 보니 실제로 카드 연락하는 과정에서 안내 문구로 "안전한 임시 패스워드로 변경된다"는 안내 메시지가 나온다. 이 부분은 그냥 진행할 때는 내가 무심코 지나가서 인지 못 한 부분이긴 하다. 물론 고객센터에 문의할 때는 이런 상황이면 그냥 패스워드를 바꾼 거지 이게 왜 임시 패스워드 인지를 물었지만, 아래와 같이 비밀번호를 초기화할 때 임시로 발급하는 패스워드와 같다는 답변을 받았다.

토스 고객센터에서 받은 답변

나한테는 임시라는 것은 곧 변경할 패스워드이거나 잠시 후 복구할 패스워드여야 하는데 실제로 토스는 이 비밀번호를 계속 사용해야 하므로 임시 비밀번호라는 것을 완전히 받아들일 수는 없었지만, 비밀번호가 변경된다는 것은 내가 무심코 안 보고 넘어간 것이 맞고 해당 문구를 특히 숨기거나 한 것은 아니므로 여기서는 넘어가겠다.

이후 다른 분한테 얻은 정보에 의하면 비밀번호가 초기화된 것은 문자로 인증할 때만 인 것 같은데 난 테스트해보진 않았고 토스에서는 "문자 인증으로 연결하기"를 제일 먼저 보여주기에 크게 상관도 없다고 생각한다. 여기서 어떻게 토스가 내 계정의 비밀번호를 변경할 수 있었는가가 궁금했다.

현대카드의 비밀번호 찾기 화면

위 보는 대로 현대카드는 비밀번호를 초기화하기 위해서 4가지 방법을 제공한다. 다른 분이 자신이 문의했던 정보를 알려주어서 이 비밀번호 초기화 과정을 이해하게 되었는데 토스는 휴대폰 인증으로 내 비밀번호를 초기화하는 것으로 추정하고 있다. 이런 점을 생각하면 Puppeteer류의 브라우저 에뮬레이팅 방식으로 직접 현대카드 웹사이트에 접속해서 토스에 제공한 내 개인정보를 이용해서 위의 "휴대폰 인증"화면의 내용을 채우고 "인증번호 발송"을 하면 내 핸드폰에 문자가 오고(실제로 토스가 아니라 현대카드에서 문자가 왔다.) 내가 이 번호를 토스에 제공하면 토스가 이 번호를 현대카드에 입력한 후에 "새 비밀번호 입력"을 한 것으로 추측한다.

여기서 새 비밀번호는 아마도 토스가 임의로 생성한 비밀번호일 것이다. 이 과정에서 토스는 나한테 새로운 비밀번호를 알려주지는 않고 자연히 현대카드에서는 비밀번호가 변경되었다고 나한테 알림을 보낸다.(실제로 내가 변경한 것과 같은 과정이므로....)

이렇게 연동하고 나면 토스에서 내가 가진 현대카드 목록이 나타나고 카드 명세도 잘 나타난다.

문제는 여기서부터인데 내 현대카드의 비밀번호는 바뀌었고 바뀐 비밀번호는 내가 알지 못한다. 그러므로 현대카드 사이트에서 내가 알던 정보로 로그인은 하려고 하면 로그인을 할 수가 없다. 그러므로 당연히 나는 현대카드 사이트에서 비밀번호를 내가 원하는 비밀번호로 재설정한다.

여기서 고객센터의 답변대로라면 임시로 변경한 비밀번호를 저장하고 있지 않으므로 토스는 현대카드와의 연동에 문제가 없어야 하고 앞에서 문의했던 비밀번호 5회 틀림으로 계정이 잠기는 문제가 발생하지 않아야 한다.

원래도 토스 앱의 카드 쪽에서 카드 정보를 갱신하려고 하면 시간이 오래 걸렸는데(브라우저를 에뮬레이팅하느라?) 비밀번호를 초기화한 후에는 아예 갱신하는 스피너에서 멈춰서 아예 아무것도 안 되는 느낌이었다. 실제로 갱신이 안 되는지 확인하기 위해서 온라인 쇼핑몰에서 물건을 사서 현대카드 결제를 했다.(테스트하려고 이렇게까지) 실제로 카드명세는 연동하고 내가 비밀번호를 바꾼 이후에는 아무것도 나오지 않았다.

현대카드에서 비밀번호 5회 틀림으로 로그인이 안되는 화면

토스 앱의 재시도 로직을 알지 못하지만, 시간을 두고 여러 번 앱을 껐다 켜면서 카드 명세를 조회하다 전날과 마찬가지로 현대카드 사이트에서 비밀번호가 5회 틀렸다면서 계정이 잠기었다. 전날과 달리 이때는 완전히 테스트를 위한 시도였기 때문에 토스 앱을 켜기 전에 현대카드에 로그인을 실제로 해본 뒤에 토스앱만 여러 번 켜보면서 로그인을 시도했기 때문에 하필 비슷한 시간에 누가 내 아이디로 로그인 시도를 한 것이 아니라면 토스 앱이 비번이 5번 틀렸다고 생각할 수밖에 없고 이는 고객센터의 답변과 달리 토스가 변경한 내 현대카드 비밀번호를 저장하고 있다고 이후 명세 조회에 사용한다고 생각할 수밖에 없다.

이후 받은 답변

여기까지가 내가 확인한 사항이고 고객센터의 얘기와 달리 토스는 변경한 비밀번호를 저장한 뒤 이후 조회에 계속 사용하고 있다. 앞에서 얘기한 대로 테스트를 마치고 상황에 대한 글을 쓰다가 저녁을 먹으러 나가서 놀다 오던 와중에 토스 트위터 공식 계정을 통해 이 상황에 대한 추가 답변을 받았다.

이 추가 답변은 금요일 저녁 9시 10분경에 왔는데 나 혼자만의 추측으로는 내가 이틀 동안 트위터에서 구시렁댄 게 토스 내부에 공유되었고 내부 회의를 통해 상황정리를 하고 나한테 답변이 온 거라고 생각하고 있다. 그렇지 않으면 금요일 저녁 늦게 답변을 이유가 없으니까... 이게 잘못됐다고 얘기하는 것은 아니고 괜히 평온한 금요일 저녁에 야근하게 한 것 같아서 미안한 마음이 있을 뿐이다. 그래도 나름대로는 문제라고 인식했을 때 내가 트위터 공식 계정에 문의했던 게 이 답변을 받기 24시간 전이고 고객센터에 문의했던 것도 이날 아침이었기 때문에 사용자 입장에서는 충분히 문의하지 않았나 싶다. 토스 공식 계정이 답변한 것도 내 질문에 대한 답변이 아니고 이 문제에 대해 떠들던 다른 글에 대한 답변이었기 때문에...

결론적으로 정리하면 토스 앱은 서버는 아니고 클라이언트에서 새로 초기화한 비밀번호를 암호화해서 저장해 놓고 이후 조회해 사용하는 것이 맞다. 고객센터의 답변은 내가 혼동한 것인지는 모르겠지만 회사에 다녀본 입장에서 이런 문의보다 실제로 비밀번호를 잘못 알고 하는 문의가 더 많을 것이므로 고객센터의 잘못이라고 얘기하고픈 생각은 없다.

뭐가 문제인가

문제라고 인식하는 수준은 사람마다 다를 것인데 나는 이 상황을 큰 문제로 인식하고 있다.

비밀번호를 복호화할 수 있다

비 개발자에게 설명하기 쉬운 얘기는 아니지만 보통 비밀번호는 해싱이라는 방식으로 저장한다. 해싱이라는 것은 기본적으로 aaa -> xxx로 바꾸는 방식인데 반대로 xxxaaa를 알아낼 수는 없다. 이는 컴퓨터 알고리즘으로 거의 보장되는 방식이기에 내부 개발자라고 하더라도 사용자의 비밀번호를 알아낼 수 없고 새로운 비밀번호를 부여할 수만 있다. 그래서 거의 모든 서비스가 기존 비밀번호를 알려주는 방식이 아니라 본인 인증 후에 새 비밀번호를 입력하는 방식을 사용하는 것이다.

이는 보안과 관련된 더 복잡한 얘기로 이어지지만, 비밀번호란 것은 데이터베이스가 통째로 빼앗겼을 때도 최대한 안전하게 보호할 수 있도록 소위 스트레칭(strengthing)이나 솔팅(salting)같은 방법을 추가로 사용하고 있다. 다른 정보와 달리 그냥 암호화하는 것만으로는 안전하지 않은 중요한 정보이기 때문에 가능한 한 최대한의 보안을 유지하는 것이 비밀번호 저장의 핵심이다(라고 나는 생각한다).

그런데 여기 토스 앱에서는 내 비밀번호를 복호화할 수 있다. 여기서 복호화한다는 것은 데이터베이스에 저장되어 있을 때는 알아볼 수 없는 값으로 저장되었지만 특정 키를 통해서 복호화를 하면 내 원래의 비밀번호가 뭔지 알 수 있다는 의미이다. 물론 서버의 데이터베이스에 저장되지 않고 클라이언트에만 저장된다는 것은 불의의 사고로 토스의 모든 사용자의 현대카드 패스워드가 빼앗기는 일은 일어나지 않고 내 폰의 해킹 등을 통해서 나만 빼앗긴다는 의미이다. 그러므로 공격자는 한 명을 타게팅해서 패스워드를 빼앗거나 한 명만 빼앗아도 그 정도의 이득이 있어야 한다. 그리고 현대카드 아이디/패스워드로 결제를 하는 것은 아니므로(아마도?) 권한을 모두 확인해 보지 않았지만, 아이디/패스워드와 이 정도 보안이면 괜찮다고 판단했을 수도 있다.

그런 면에서 클라이언트에만 저장한다는 것은(내가 확인할 수는 없지만) 어느 정도는 유효한 접근방식이지만 나는 내 비밀번호가 복호화가 가능하다는 것이 탐탁지 않다. 그리고 보안의 민감하지 않은 대부분 사용자는 아이디/비밀번호는 많은 서비스에서 같게 사용하고 있을 것이기 때문에 토스 앱에서 이 비밀번호를 뺏을 수 있는 취약점을 찾을 수 있다면 앞에 말한 대로 한 명만 공격할 이유가 생길 수도 있다. 당연히 복호화가 불가능하다면 이렇게 빼앗더라도 이 비밀번호를 찾기 위해서 추가 비용이 많이 들기 때문에 공격할 이유가 추가로 현저하게 줄어든다.

사용자가 인지할 수 없는 내용이다.

내가 개발자라서 이 상황을 보고 이를 유추할 수 있었을 뿐이지 사용자가 과연 이를 인지할 수 있는지 의문이다. 앞에서 받은 답변에서는 "ID/PW를 재입력하는 불편을 방지하기 위함"이라고 답변을 받았는데 나로서는 사용자의 불편을 가중할 뿐이다.

실제로 연동할 때 "임시로 패스워드를 변경"이라고 표현해서 패스워드 변경의 중요성을 낮추었지만 실제로 이 패스워드 변경은 연동에 엄청 중요한 사항이고 이후 연동테스트를 계속해보진 않았지만, 토스가 내 현대카드 패스워드를 임시가 아니라 영원히 알고 있어야 가능한 방식이다. 그래서 실제로 카드 메뉴에도 토스에서 비밀번호를 재설정하는 메뉴가 있고 내 예상으로는 토스 연동 이후에는 현대카드에서 비밀번호를 바꾸지 않고 토스에서 비밀번호를 관리해야 계속 카드명세를 볼 수 있다.

이 내용을 이해할 수 있는 사용자가 몇 명이나 될지 나는 의문이다. 열심히 이 글을 썼지만, IT 종사자가 아니라면 이 글을 다 읽어도 10명 중 1명 정도만 상황을 이해할 수 있다고 생각한다.

내가 예상하는 시나리오는...

  1. 토스 앱에서 현대카드를 연동한다.
  2. 현대카드 앱은 이미 로그인되어 있으므로 사용하는 데 문제가 없다.
  3. 그러므로 일정 시간이 지나서 토스 앱을 생각하지 못하는 시점 언젠가 ID/PW로 현대카드에 로그인하려고 할 때 로그인에 실패한다.
  4. 사용자는 왜 실패하는지 이해 못 하기 때문에 비밀번호를 잃어버렸다고 생각하고 비밀번호를 초기화한다.
  5. 다시 일정 시간이 지난 시점에 토스 앱에 들어와 보니 현대카드 명세가 갱신이 안 되고 있다.
  6. 여러 가지를 시도해 보다가 다시 연동한다.
  7. 패스워드가 변경된다.
  8. 3번으로 돌아간다.

나는 사용자가 비밀번호 초기화와 토스앱 연동의 무한루프를 계속 돌 것으로 생각한다. 내가 이 상황을 이해해서 그런지 몰라도 여기서 "ID/PW를 재입력하는 불편을 방지"하는 요소는 보이지 않고 다른 큰 불편함만 보일 뿐이다.

차라리 "문자인증"처럼 뭔가 자동화된 과정처럼 보여주지 않고 토스 앱에 현대카드 아이디와 패스워드를 적어주세요 하는 게 사용자가 이해하기 훨씬 좋지 않은가 싶다. 실제로 아이디 패스워드를 넘긴 것과 결과가 같고 이렇게 보여주면 사용자가 토스를 믿고 넘겨줄지 말지를 결정할 수 있고 넘겨줬다고 명확하게 알 수 있으니까... 나는 마케팅은 쥐뿔도 모르고 개발 관점에서 얘기하는 거긴 하지만 사용자 관점에서 "문자인증"이 더 좋은지는 여전히 모르겠다.

모든 스크래핑 기술을 사용하는 회사에서 공통으로 이용하는 방식??

내가 제대로 이해했다면 여기서 스크래핑 기술이라고 한 것은 웹사이트에서 내용을 긁어오는 방식을 의미한 것 같다. 토스가 어떻게 하는지 모르겠지만 내가 간단히 내가 뭔가 쓸려고 만든다면 Puppeteer로 headless Chrome을 띄워서 사이트에 로그인해서 긁어오게 할 것 같다. 요즘은 헤드리스 크롬이 적당히 가벼우면서 유지보수도 편한 편이니까...

근데 여기서 일단 스크래핑 기술을 사용하는 회사의 목록이 무척 궁금하지만, 사용자가 타 서비스의 아이디 패스워드를 서비스에 알려주고 스크래핑하는 서비스가 뭐가 있는지 난 잘 생각나지 않는다. 일단 내가 쓰는 서비스에서는 없는 것 같다. 물론 내가 내 정보를 긁어오려고 프로그램을 만들어서 내 아이디와 패스워드로 긁어오게 하는 경우는 꽤 있는데 이건 내가 허용한 거니까 위에서 말한 공통적인 방식이라고 하기에는 무리가 있게 느껴진다.

이 부분은 바로 앞에서 말했듯 사용자가 인지했는지와 연결되는데 사용자가 아이디/패스워드를 명시적으로 넘겨주었다면 가능하지만 나는 그렇지 않다고 생각하기 때문에 공통적인 방식이라는 얘기에 동의 못 하고 있다.

그리고 뱅크샐러드는 어떤 방식으로 하는지 내가 잘 모르겠지만 토스 같은 서비스가 또 나오면 어떻게 할 것인가? 현대카드 사이트에서 비밀번호를 바꾸면 모든 서비스의 연동이 멈출 것이고 이 방식을 이해한다고 해도 비슷한 서비스가 2~3개 생기면 비밀번호를 바꿀 때 각 서비스에서 다 비밀번호를 바꾸어야 한다. 내가 사용하는 카드는 현대카드인데 카드 명세를 보기 위해서 현대카드 비밀번호를 바꿀 때마다 각 서비스를 돌아다니면서 사용자가 비밀번호를 바꾸어야 한다는 것은 난 받아들일 수 없는 방식이다.

현대카드와 제휴한 연동인가?

이 연동 방식을 이해했을 때 현대카드와 제휴가 된 연동인가? 하는 의문이 들었다. 왜냐하면, 사용자의 아이디/패스워드로 명세를 긁어오는 것이기 때문에 굳이 현대카드의 동의가 필요 없어 보였기 때문이다. 만일 이 방식이 현대카드와 논의했는데 현대카드가 이 방법으로 가져가라고 안내했다면 난 현대카드 해지를 고민할 정도의 사안이다.

금융권에서 일해본 적은 없지만, 국내 금융권의 IT는 형편없다고 생각하는 편이라서 이를 연동하기 위한 API 같은 것도 전혀 없거나 제공하더라도 수준이 사용할 수 없는 편이라고 생각한다. 나는 그런 면에서 카드사를 포함한 국내 금융권은 새로운 흐름에 위협을 느끼거나 한번 무너져야 한다고 생각하는 편이다. 그런 면에서 토스나 카카오뱅크 같은 신규 서비스를 응원하고 편하게 이용하고 있는 편이라 이런 환경에서 서비스에 기능을 추가하려면 다른 금융사나 카드사가 협조하지 않더라도 방법을 찾을 수밖에 없었다고 생각하기도 한다.

이런 해킹 방법에는 여러 가지가 있고 가능하지만 내 개인정보에 관해서는(여기서는 아이디/비밀번호) 지지 여부와 상관없이 나는 동의할 수 없다.

정리

처음 이 상황을 점점 이해하면서 내 의심이 확실하여갈 때는 나는 토스 탈퇴까지 고려하고 있었다. 심지어 이 글의 제목은 "내가 토스를 탈퇴하는 이유" 같은 거로 생각하고 있었다. 토스도 응원하고 있고 토스에서 일하고 계신 친분 있는 개발자분들도 있지만 그런 분들도 각 개발 상황이나 의사결정을 모두 다 알고 있는 것은 아니므로 일부러 공식 채널을 통해서 상황을 파악했다. 친분 있는 내부 사람들한테 물어보면 글을 쓰기도 서로 더 불편해질 것 같았다.

최대한 상황을 이해하려고 했고 노력했지만, 내부 사정을 다르므로 잘못 이해하고 얘기한 부분이 있을 수도 있다. 그런 부분을 지적해주면 반영하려고 노력할 예정이다.

결론을 얘기하면 위에서 동의할 수 없다고 한대로 토스는 계속 사용하겠지만 내 아이디와 비밀번호를 토스에 제공할 게 없으므로 토스에서 연동한 현대카드는 모두 삭제했다. 처음 사용했을 때는 연동해제가 아니라 카드 삭제만 하는 게 찝찝했지만, 비밀번호를 바꿨기 때문에 카드 삭제만으로도 충분해 보인다.(지속적인 재시도로 내 현대카드 계정을 잠그지만 않는다면... 이 테스트는 아직 못 해봤다.)

2019/05/18 02:33 2019/05/18 02:33

기술 뉴스 #126 : 19-05-15

웹개발 관련

  • HTTP headers for the responsible developer : 제목은 HTTP 헤더라고 되어 있지만, 웹페이지를 더 안전하고 빠르게 하려고 다양한 HTTP 헤더와 HTML 태그를 설명하고 있다. HTTPS로 페이지를 안전하게 관리하는 방법부터 CSP와 인코딩 방법 등 필요한 이유와 사용방법을 설명하는데 콘퍼런스에서 발표한 내용을 글로 정리한 것이다. 이런 쪽에 관심 있다면 알만한 부분이긴 하지만 내용이 잘 정리되어 있고 이미지 사이즈를 제어하는 Accept-CHFeature-Policy는 잘 몰랐던 부분이라 다음에 사이트를 만들 때 자세히 봐야겠다 싶다.(영어)
  • Google I/O 2019: Day 1 후기 : 이번에 열린 구글 I/O에 참석한 후기인데 웹 관련 기술을 위주로 이번 I/O에서 어떤 발표를 했는지 살펴볼 수 있다. 특히, Duplex on the Web, <img loading="lazy" />이나 WebAuthn등이 흥미로웠다. Day 2 후기 참고.(한국어)
  • 마이리얼트립 웹사이트 성능 측정 및 최적화 Part 1. 리소스 로딩 : 마이리얼트림의 웹사이트의 사용자가 여행지 등 네트워크가 좋지 않은 곳에서 이용하는 경우가 많으므로 초기 웹사이트의 로딩 속도를 높이기 위해 최적화한 과정을 정리한 글이다. webpack-bundle-analyzer로 자바스크립트 파일을 분석해서 불필요한 용량을 제거하고 Code splitting을 적용하고 외부 라이브러리 사용을 최적화하고 이미지 스프라이트를 적용해서 로딩 사이즈를 많이 줄이고 메인 페이지의 구성상 초기에 불러오지 않아도 되는 이미지와 내용을 지연 로딩을 통해서 속도를 개선한 내용이 나와 있다.(한국어)
  • The new evergreen Googlebot : 이제 웹사이트를 크롤링하는 구글봇이 최신 크로니움 렌더링 엔진으로 동작(현시점에서는 74 버전)으로 동작한다고 한다. 이로써 구글봇이 ES6 등 최신 JS 기능을 지원하고 Lazy Loading이나 웹 컴포넌트 등을 지원한다고 한다.(영어)

그 밖의 프로그래밍 관련

  • Introducing GitHub Package Registry : GitHub에서 저장소에 바로 연결해서 운영할 수 있는 패키지 저장소를 공개했다. 이곳에 배포된 패키지는 GitHub의 CDN으로 배포되고 npm, Maven, RubyGems, NuGet를 지원한다. 현재는 아직 클로즈 베타 상태이다.(영어)
  • git rebase in depth : git rebase는 Git에서 배우기 어려워하는 기능 중 하나이지만 배워두면 강력한 기능이기도 하다. Reabse를 이용해서 커밋을 합치고 순서를 조정하고 다시 쪼개는 방법을 설명하는 문서인데 따라해 볼 수 있도록 설명하고 있어서 이해하기가 좋다.(영어)
  • (번역) WSL 2를 공개하며 : 이번 Build 2019에서 Microsoft가 공개한 WSL 2(Windows Subsystem for Linux)을 공개하는 글을 번역한 글이다. WSL 2에서는 Linux 커널이 완전히 내장되었고 이번 버전에서는 4.19 버전의 커널을 포함 시킬 예정이라고 한다. 커널을 내장함으로써 WSL 1보다 훨씬 빠르게 실행할 수 있고 업데이트도 빨리 적용할 수 있게 되었다.(한국어)
  • 타다 클라이언트 개발기 : 언젠가부터 믿고 읽게 되는 타다의 글이다. 3달 반 정도의 기간 안에 타다 앱을 만들어서 배포한 과정을 설명하고 있다. 기간이 짧았기 때문에 필요한 스펙을 제한해서 정하고 RIBs라는 iOS, Android에서 같이 사용할 수 있는 오픈소스 아키텍처를 사용하고 Protocol Buffer로 서버와 데이터를 주고받았다고 한다. 각 영역에서 어떤 기술을 선택해서 사용했는지 설명하면서 성공적으로 출시한 이후의 회고까지 잘 나와 있다.(영어)
  • 딥러닝 추천 시스템 in production : 당근마켓에서 사용자가 보는 피드에 개인화 추천을 하기 위해 추천 시스템 개발에 대한 접근은 딥러닝 개인화 추천에서 설명하고 이 글에서는 Kubeflow Pipelines를 사용해서 어떻게 서비스에 적용했는지를 설명하고 있다. 유튜브와 핀터레스트에서 공개한 내용을 통해 2단계 학습을 적용하는 시스템을 실제 당근마켓 서비스에 맞게 적용한 과정이 자세히 나와 있다. 딥러닝은 거의 모르기는 하는데 실제 서비스의 적용하는 과정이라서 재미있게 읽었다.(한국어)
  • 구글, 도커 컨테이너 기반 서버리스 서비스인 클라우드 런 발표 : 이번에 발표된 GCP의 클라우드 런을 설명하는 글이다. 클라우드 런은 서버리스로 Docker 컨테이너를 바로 운영할 수 있는 서비스로 마치 AWS의 Lambda와 Fargate의 장점을 섞어놓은 듯한 서비스인데 간단한 글이지만 이 글을 통해 클라우드 런의 특징을 이해할 수 있다.(한국어)
  • Linkerd or Istio? : 서비스 메시 프로젝트인 Istio와 Linkerd의 기능을 비교하는 글이다. 트래픽 관리, 보안, 설치, 지원 환경, 관측성, 정책 관리, 성능으로 나누어서 특징을 설명하고 영역마다 기능을 표로 만들어서 비교해 줘서 차이점을 쉽게 파악할 수 있다.(영어)

볼만한 링크

  • 뛰어난 개발자는 뽑히는 게 아니라 길러집니다. : 뛰어난 개발자가 시장에 실제로 많지 않기 때문에 뛰어난 개발자를 찾는 채용 과정에 더 노력하기보다는 채용과정을 완화하고 개발자를 뛰어난 개발자로 만드는 멘토링 과정에 신경 써야 한다는 내용의 글이다. 멘토링이 중요하다는 점에서는 동의하긴 하지만 어떻게 해야 하는지는 아직 잘 모르겠긴 하다.(한국어)
  • 밀레니얼즈가 사랑하는 Lemonade는 어떻게 보험산업을 파괴하고 있는가? : 밀레니얼즈를 타겟으로 보험료가 싸면서도 보험금을 청구하면 봇이 알고리즘으로 검사해서 빠르게 보험금을 지급하는 Lemonade라는 회사를 소개하는 글이다. Lemonade의 구조까지 자세히 나와 있는 것은 아니지만, 몰랐던 스타트업이 전통적인 보험산업을 도전하고 있다는 점에서 관심이 가는 접근이었다. 이미 Lemonade는 꽤 많은 투자를 받았고 보험 경험이 없어서 손실률이 높았지만, 점점 낮추고 있다고 한다.(한국어)
  • JMAP: A modern, open email protocol : IETF에서 오래되고 사용하기 어려운 IMAP같은 이메일 프로토콜을 개선하기 위해서 사용하기 쉬운 JAMP 이메일 프로토콜을 만들어서 공개했다. 차후에는 같은 프로토콜로 연락처와 일정도 동기화할 수 있다고 한다.(영어)
  • 4년을 기다린 인프런 서비스 리뉴얼 오픈 : 동영상 강의 플랫폼인 인프런이 초기 워드프레스로 구축한 서비스를 4년 만에 리뉴얼 하게 된 과정을 설명하는 글이다. 기술 스택에 관한 얘기가 있지만 상세한 아키텍처에 대한 이야기라기 보다는 1명인 회사에서 투자받고 9명이 되기까지 리뉴얼을 하려고 했던 큰 노력과 마침내 오픈한 리뉴얼 프로젝트의 과정 및 후기에서 그동안의 고생이 느껴진다.(한국어)
  • 안드로이드 Q의 새로운 기능을 소개합니다 : 안드로이드의 10번째 버전 안드로이드 Q의 베타 버전이 공개되었다. 5G를 지원하는 최초 OS로 온디바이스 머신러닝 기능 등이 추가되었다.(한국어)

IT 업계 뉴스

  • 우버, 뉴욕증권거래소 상장 첫날 7.6% 주가 하락 : Uber가 주당 45달러로 Facebook 이후 최대 규모로 상장했지만 7.5% 떨어진 41.57로 거래를 마쳤다. 영어지만 The Verge의 UBER GOES PUBLIC: EVERYTHING YOU NEED TO KNOW ABOUT THE BIGGEST TECH IPO IN YEARS를 읽어보면 이번 IPO 가격 책정의 배경이나 전망 등을 좀 더 살펴볼 수 있다.(한국어)
  • Git ransom campaign incident report—Atlassian Bitbucket, GitHub, GitLab : 지난 5월 2일 Bitbucket, GitHub, GitLab 모두에서 일부 사용자의 저장소(공개 비공개 모두)가 삭제되는 랜섬웨어 공격이 발생하고 이를 해제하려면 0.1 비트코인을 보내라는 메시지가 남겨졌다. 세 곳이 모두 발생해서 세 회사가 협업해서 이 문제를 조사했고 해당 공격은 모두 유효한 패스워드, 키, 토큰으로 이루어졌고 공격자의 IP와 같은 곳에서 이러한 정보의 덤프 파일이 올려져 있는 것을 발견했다고 한다. 현재 공격당한 사용자의 저장소는 모두 복구되었고 공개되어 있던 키 등도 모두 리보크했다고 한다.(영어)

프로젝트

  • go-perfbook : 고성능 Go 코드 작성에 관한 베스트 프렉티스를 모아놓은 문서.
  • This person does not exist : 페이지를 새로 고침할 때마다 AI가 만든 존재하지 않는 사람들의 얼굴 사진을 만들어 주는 사이트.
  • React Native for Windows : Windows 앱 용 React Native.
  • NetData : 실시간 성능 모니터링 도구.
  • WebAssembly Micro Runtime : 인텔에서 만든 스탠드얼론 WebAssembly 런타임.
  • Simplify : Gmail의 UI를 간단하게 만들어 주는 브라우저 확장.
  • DeepScan : JavaScript 코드 정적 분석 서비스로 오픈소스에서는 무료로 이용할 수 있다.
  • Full Metal Jacket : 1995년 미리내 소프트에서 만든 풀 메탈 자켓의 소스가 공개되었다.

버전 업데이트

2019/05/15 16:14 2019/05/15 16:14