Tech-Verse 2022에서 마상욱 님이 발표한 Easier and Safer LINE Account Transfer 세션 내용을 옮긴 글입니다.
안녕하세요. LINE에서 계정과 인증 영역 서버 개발 팀을 이끌고 있는 마상욱입니다. 서버 개발자를 포함해 모든 LINE 개발자는 사용자에게 안전하고 편리한 기능을 제공하기 위해 노력하고 있으며, 그 과정에서 안정성과 사용자 경험 사이에서 균형을 맞춰야 하는 상황을 종종 마주합니다. 두 가지 모두 사용자를 위한 것이기 때문에 어느 쪽도 놓치지 않는 방법을 찾기 위해 모두가 노력하고 있는데요. 이번 글에서는 그와 같은 과정을 거쳐 계정 이전 기능을 개선한 사례를 소개하겠습니다.
먼저 계정 이전 기능과 Letter Sealing이 무엇인지 설명하고, 계정 이전 기능에 어떤 문제가 있었는지 짚어본 뒤 문제를 해결하기 위해 적용한 두 가지 개선 방법을 설명하겠습니다. 첫 번째는 생체 인증을 사용한 더 쉬운 계정 이전 기능이고 두 번째는 안전한 백업을 통한 Letter Sealing 키 이전 기능입니다. 마지막으로 전체 내용을 간단히 정리한 뒤 향후 계획을 말씀드리겠습니다. 계정 이전 기능이란 사용자가 스마트폰을 바꾸면 새로운 스마트폰에서 LINE을 사용하기 위해 계정 식별과 소유권 인증 과정을 거칩니다. 현재 하나의 LINE 계정은 하나의 스마트폰에서만 사용한다는 스펙이 있기 때문에 이와 같은 계정 식별과 소유권 인증 과정을 '기존 기기에서 새로운 기기로 계정을 이전하는 기능'이라고 정의하고 있습니다.
계정 이전 과정에서는 전화번호와 비밀번호 등 여러 인증 수단을 사용합니다. 그런데 이런 수단 중 일부는 사용자 식별이나 인증 관점에서 한계가 있습니다. 전화번호는 다른 사용자에게 소유권이 넘어갈 수 있어서 사용자를 확실히 식별하기 어렵고, 비밀번호와 PIN 번호처럼 사용자 기억에 기반한 인증 수단은 사용자가 잊어버리거나 유출될 수 있다는 한계가 있습니다. 또한 사용자가 보안 관점에서 매우 안전한 비밀번호를 사용할 것이라고 기대하거나 그렇게 사용하도록 요구하기 어렵다는 한계도 있습니다.
Letter Sealing이란
다음으로 LINE의 종단 간 암호화 구현인 LINE Letter Sealing을 소개하겠습니다. LINE에서 메시지를 전달할 때는 Letter Sealing을 적용해 클라이언트끼리만 서로 공유하는 비밀 키 기반으로 메시지를 암호화하고 복구화하기 때문에 서버를 포함해 클라이언트와 클라이언트 사이 어떤 단계에서도 메시지 내용이 노출되지 않습니다. 클라이언트는 공개 키 암호화 방식, 더 정확히는 타원 곡선 암호화 방식에 기반해 비밀 키를 서로 공유하고, 각자 생성한 공개 키와 개인 키 쌍 중 공개 키를 서버를 통해 공유합니다. 개인 키는 클라이언트와 클라이언트 사이 단계에서는 확인할 수 없으므로 공유 비밀 키가 노출될 염려가 없습니다.
계정 이전 기능의 세 가지 목표
계정 이전 기능은 사용자에게 쉬워야 하고, 계정 탈취를 방지할 수 있어야 하며, 이전 과정을 통해 대화 내역도 매끄럽게 이전할 수 있어야 합니다. 각 사항을 하나씩 살펴보겠습니다.
사용자 기억에 기반한 인증 수단은 다른 서비스에서 노출된 정보 때문에 파훼될 수도 있고 피싱과 같은 공격에 취약하다는 한계가 있습니다. LINE에서는 이에 대응하기 위해 특정 조건에서는 기기 소유권 인증과 같은 추가 인증을 요구하고 있는데요. 이와 같은 인증 수단들이 추가되면 계정 이전 절차가 길어지고, 절차가 길어질수록 사용자 계정 이전을 마치기 어려워진다는 또 다른 문제가 발생합니다. 현재 접수되는 전체 사용자 문의의 30%가량이 계정 이전 관련 문의이기 때문에 다양한 방면으로 개선 방안을 모색하고 있습니다.
다음으로 피싱과 같은 공격으로 계정이 탈취되면 데이터 유출이나 금전 손실과 같은 심각한 피해가 발생할 수 있기 때문에 계정 탈취를 예방해야 합니다. 아래 슬라이드 하단 이미지와 같이 공격자는 LINE UI와 매우 유사한 웹페이지를 만들어서 비밀번호와 같은 정보를 입력하도록 유도하는데요. 서비스를 제공하는 입장에서 대응하기가 쉽지 않은 문제입니다.
현재 LINE에서는 계정 탈취를 막고 사용자 피해를 방지하기 위해 피싱 사이트를 탐지해서 사이트 정지를 의뢰하는 프로세스를 갖추고 있습니다. 아래 관련 공식 사이트 글과 기술 블로그 링크를 첨부하니 참고해 주시기 바랍니다.
- https://linecorp.com/en/security/article/396
- https://engineering.linecorp.com/ja/blog/anti-phishing-scams-2021(일본어)
세 번째로 계정 이전 과정에서 사용자들은 이전 기기의 대화 내용을 새로운 기기에서도 자연스럽게 볼 수 있기를 기대합니다. 여기서 기술적으로 까다로운 부분은 대화 내역뿐 아니라 Letter Sealing 키도 이전해야 한다는 점입니다. 이번 글에서 소개할 기능을 도입하기 전에는 외부 클라우드 서비스를 기반으로 대화 내역 백업과 복원을 진행했지만, 이와 같은 방식은 외부 서비스 상태에 의존할 수밖에 없고 현재 시점에서는 서로 다른 플랫폼 간에는 백업과 복원이 지원되지 않는다는 한계가 있습니다.
두 가지 개선 방법 소개
앞서 살펴본 문제를 해결하기 위해 최근에 도입한 두 가지 개선 방법을 소개하겠습니다.
생체 인증을 활용해 더 쉽게 계정 이전하기
먼저 생체 인증을 활용해 계정 이전을 더 쉽게 진행할 수 있도록 개선했습니다. 안면 인식과 지문 인식 등 스마트폰 기기에서의 생체 인증은 이미 많은 분들에게 익숙한 기술입니다. 사용자가 알고 있는 정보에 기반하지 않기 때문에 패스워드보다 더 안전하며, LINE을 사용하고 있는 기기를 통해 인증하기 때문에 보다 확실하게 대상 계정을 식별할 수 있습니다. 이번에 더 쉽게 개선한 계정 이전 기능에서는 LINE을 사용하고 있는 기기의 키 스토어(key store)에 접근하기 위해 생체 인증 과정을 거칩니다.
참고로 이번 기능에서 사용하지는 않았으나 LINE에서는 FIDO2 스펙에 기반한 기기 생체 인증 연동을 지원합니다. 아래 슬라이드 오른쪽 스크린숏처럼 LINE 설정 메뉴를 통해 연동할 수 있습니다. 이와 관련된 기술 발표 링크를 첨부했으니 발표 자료를 참고해 주시기 바랍니다.
생체 인증을 사용해 보다 쉽게 계정을 이전하는 과정을 설명하겠습니다. 먼저 이 과정은 사용자가 두 개의 기기, 현재 LINE을 사용하고 있는 기기와 LINE 계정을 옮기고자 하는 기기를 모두 소유하고 있는 상황을 가정합니다(이후 그렇지 않은 상황에서 이전하는 과정도 설명하겠습니다).
사용자가 이전 과정을 시작하면 기존 기기에서 QR 코드가 생성됩니다.
기존 기기의 데이터를 전송받기 위해 새로운 기기로 기존 기기에서 생성한 QR 코드를 스캔하면 서버로 요청이 전송됩니다. 서버에서는 사용자가 계정 이전을 시작한 것이 맞는지 기존 기기로 확인 요청을 보냅니다.
확인이 끝나면 기존 기기의 키 스토어에 접근할 수 있도록 다시 생체 인증을 거칩니다. 생체 인증이 끝나면 기존 기기에서는 키 스토어에 저장돼 있는 Letter Sealing 키를 암호화해서 서버로 전송합니다.
서버는 전송받은 데이터를 새로운 기기로 전송하고, 새로운 기기에서는 도착한 데이터를 복구한 뒤 전송받은 데이터 내용을 저장합니다. 이 과정을 통해 기존 기기의 Letter Sealing 키가 새로운 기기로 이전됩니다.
사용자 화면으로 살펴보는 계정 이전 과정
조금 더 쉽게 이해할 수 있도록 LINE 클라이언트에서 사용자에게 보이는 화면을 바탕으로 한 번 더 설명하겠습니다. 왼쪽이 기존 기기 화면이고 오른쪽이 새로운 기기의 화면입니다.
먼저 새로운 기기에서 생체 인증을 사용하는 계정 이전을 시작합니다.
사용자는 기존 기기 설정 페이지로 들어가서 계정 이전을 위한 QR 코드를 생성합니다.
새로운 기기의 카메라로 QR 코드를 스캔합니다.
기존 기기에서는 계정 이전을 진행하고 있다는 점을 확인하고 생체 인증을 실행합니다.
생체 인증이 완료되면 새로운 기기로 계정을 이전하는 작업이 완료됩니다.
전화번호와 패스워드 등에 기반한 이전 계정 이전 기능과 비교하면, 간단하고 직관적이며 사용자 기억 기반 정보에 의존하지 않기 때문에 피싱 공격에 보다 안전합니다. 또한 이전 과정에서 종단 간 암호화를 통해 Letter Sealing 키도 전송할 수 있습니다.
Letter Sealing 키 전송 과정
Letter Sealing 키를 전송할 때 중요한 점은 키 내용을 서버가 알 수 없어야 한다는 점인데요. 종단 간 암호화를 활용해 기존 기기에서 새 기기로 키를 전송하는 과정을 조금 더 상세히 설명하겠습니다.
먼저 Letter Sealing 키가 포함된 기존 기기의 데이터가 있습니다.
기존 기기에서 이전 과정을 시작하고 공개 키와 개인 키 키 쌍과 사용할 논스(nonce)를 생성합니다. 이어서 QR 코드를 생성하는데 이 QR 코드에는 공개 키와 논스 값이 포함돼 있습니다.
새로운 기기에서도 공개 키와 개인 키 키 쌍을 생성합니다.
새로운 기기에서 기존 기기에서 생성한 QR 코드를 스캔하면 기존 기기의 공개 키와 논스가 새로운 기기로 전송됩니다.
이제 새로운 기기는 공개 키와 개인 키를 사용해 복구를 위한 공유 비밀 키를 확보했습니다.
새로운 기기에서 자신의 공개 키와 전송받은 논스 값을 서버로 보냅니다.
서버는 새로운 기기에서 받은 값을 기존 기기로 전송합니다. 기존 기기에서는 이전에 생성한 논스와 수신한 논스가 일치하는지 확인합니다.
새로운 기기의 공개 키를 받았기 때문에 기존 기기 역시 데이터를 암호화하기 위한 공유 비밀 키를 확보합니다.
기존 기기에서 데이터를 암호화해 서버로 전송합니다. 서버가 알 수 없는 공유 비밀 키로 암호화했기 때문에 서버가 Letter Sealing 키를 알 수 있는 방법은 없습니다.
서버에서 암호화된 정보를 새로운 기기로 전송합니다.
새로운 기기에서 공유 비밀 키로 데이터를 복구합니다. 복구한 데이터는 새로운 기기에 저장되고 Letter Sealing 키 이전이 완료됩니다.
기존 기기가 없을 때 Letter Sealing 키 이전하기
앞서 설명한 방법에서는 사용자가 기존 기기를 갖고 있다고 가정했는데요. 기기를 분실하거나 기기가 파손되는 상황도 종종 발생하기 마련입니다. 이제 기존 기기를 갖고 있지 않은 상황에서 Letter Sealing 키를 이전하는 기능을 설명하겠습니다. 그런데 앞서 말씀드린 것처럼 Letter Sealing 키는 기기에만 저장하기 때문에 키를 새로운 기기로 이전하기 위해서는 먼저 백업하고 복원하는 기능이 필요합니다. Letter Sealing 키값 자체는 서버에서 어떤 상황에서도 알 수 없어야 하기 때문에 어떻게 안전하게 Letter Sealing 키를 백업하고 복원할 수 있을까 고민했습니다.
Letter Sealing 키 백업 인증 수단 선택 - PIN 번호
사실 이 고민을 해결하기 위한 방향을 2019년 LINE Developer Day 발표에서 공유한 적이 있습니다. 당시 Letter Sealing 키 백업에 사용할 수 있는 여러 인증 수단을 살펴봤습니다.
가장 왼쪽 아무런 암호 없이 키를 백업하고 복원하는 경우에서는 별도 입력이 필요하지 않으므로 사용자는 가장 간편하게 작업을 진행할 수 있습니다. 하지만 키가 서버에 고스란히 노출되기 때문에 사용할 수 없는 방안입니다.
임의로 생성한 높은 엔트로피의 패스워드를 사용하는 가장 오른쪽 경우를 생각해 보겠습니다. 이 경우 키값을 더 안전하게 보호할 수 있지만 사용자가 기억하고 입력하기에는 너무 긴 패스워드를 사용하기 때문에 사용성 측면에서 역시 선택할 수 없는 방안입니다. 결국 자연스러운 사용자 경험과 높은 보안을 모두 고려해 기기를 백업하고 복원하기 위한 인증 수단으로 PIN 번호를 선택했습니다.
PIN 번호를 이용한 키 백업과 복원은 기본적으로 스마트폰 화면 잠금 설정이나 OTP 카드 PIN 번호와 같은 원리를 따릅니다. 즉, 숫자로만 구성된 PIN 번호를 추측하는 것을 방지하기 위해서 PIN 번호 입력에 실패할 경우 재시도할 수 있는 횟수에 제한을 둡니다. 이런 작업은 하드웨어에 기반한 안전한 실행 환경에서 진행되기 때문에 공격자는 시도 횟수를 조작할 수 없습니다. 만약 시도 횟수가 한계값을 넘으면 더 이상 복원을 시도할 수 없도록 안전한 실행 환경 차원을 기반으로 영구적으로 막습니다.
이 원리를 실제로 구현하는 과정에서 두 가지 기술 과제에 집중했습니다.
첫 번째는 키 백업과 복원을 실행하기 위한 안전한 실행 환경을 마련하는 것입니다. 이는 Letter Sealing 키가 유출되거나 백업 혹은 복원 시도가 조작되지 않도록 방지하는 데 중요한 부분입니다.
안전 실행 환경과 관련된 구체적인 내용은 서버 사이드에서 신뢰성 높은 보안 소프트웨어 개발하기 발표를 참고 부탁드리겠습니다. 서버에서 안전한 실행 환경을 마련하는 방법과 각 실행 환경의 특성을 설명한 발표입니다.
두 번째는 PIN 번호에 대한 무차별 대입(brute-force) 공격을 막기 위한 시도 횟수 제한 구현입니다. LINE 클라이언트에서의 공격뿐 아니라 사내 네트워크 안에서의 공격도 막을 수 있는 수단을 마련했습니다. 이를 위해 각 시도의 백업과 복원 횟수를 버전으로 구분해 저장하고 사용했는데요. 이 부분에 대해서 보다 자세히 설명하겠습니다.
Letter Sealing 키 백업 및 복원 구조
아래 그림은 Letter Sealing 키를 백업하고 복원하는 구조를 간략히 표현한 그림입니다.
그림에서 공개 키와 개인 키는 안전 실행 환경 안에서의 암호화와 복구를 위한 비대칭 암호 키입니다. 안전 실행 환경은 서버 인스턴스 안에 구현돼 있기 때문에 모든 사용자의 키 백업을 저장하기에는 공간이 충분하지 않습니다. 이에 백업과 시도 횟수를 연속적으로 저장하기 위해 확장 스토리지를 도입했습니다. 백업과 시도 횟수는 먼저 안전 실행 환경에서 암호화하고 서명한 상태로 봉인해 영속 스토리지에 저장합니다. 따라서 안전 실행 환경을 거치지 않으면 키를 복원하거나 시도 횟수를 수정할 수 없습니다.
아래는 위 그림을 전반적인 서비스 환경과 유사하게 표현한 그림입니다.
백업 데이터는 먼저 클라이언트에서 공개 키와 PIN 번호를 이용해 암호화합니다. 인터넷과 회사 네트워크를 거쳐서 안전 실행 환경으로 전송하거나 반대로 클라이언트로 전송하는 과정에서 데이터는 기본적으로 암호화된 상태입니다.
다시 앞서 그림으로 돌아와서 키 백업 및 복구화 과정을 간략히 설명하겠습니다. 먼저 클라이언트에서 백업 혹은 복원 요청을 합니다.
복원 요청을 받으면 백업과 시도 횟수를 봉인해 저장해 놓은 데이터를 영속 스토리지에서 가져옵니다.
봉인 데이터를 안전 실행 환경으로 전송합니다. 안전 실행 환경에서는 조건을 확인하고 이를 충족할 때에만 데이터를 처리하는데요. 이 조건에 대해서는 이후에 조금 더 자세히 설명하겠습니다.
PIN 번호 일치 여부에 따라서 PIN 시도 횟수를 갱신하고, 그 결과를 암호화하고 서명한 뒤 봉인합니다. 봉인한 내용은 다시 영속 스토리지에 업데이트합니다.
사용자에게 그 결괏값을 반환합니다. 여기서 반환하는 정보는 키 데이터 내용 자체가 아니라 클라이언트에서 복구화해 키 데이터를 얻어낼 수 있는 암호화된 데이터입니다.
앞서 언급한, 안전 실행 환경에서 확인하는 조건을 설명하겠습니다. 안전 실행 환경에서는 영속 스토리지에서 가져온 시도 횟수와 안전 실행 환경의 시도 횟수를 비교해서, 스토리지에서 가져온 횟수가 안전 실행 환경의 횟수와 같거나 클 경우에만 처리를 진행합니다. 이 조건은 네트워크에서 재시도 공격을 방지하는 데 중요한 역할을 합니다.
공격 방어 시나리오
지금까지 설명한 구조가 대표적인 공격 시나리오를 어떻게 방어하는지 살펴보겠습니다. 만약 공격자가 클라이언트에서 PIN 번호를 알아내기 위해 여러 번 시도한다면 틀릴 때마다 시도 횟수가 증가하고, 시도 횟수가 한계값에 이르면 더 이상 복원을 시도할 수 없도록 영구적으로 차단합니다.
만약 공격자가 회사 네트워크 안에서 이전 요청 내용을 재사용해 PIN 번호를 알아내려고 시도한다면, 이전 복원 요청에서 사용한 봉인 데이터가 다시 안전 실행 환경으로 전송됩니다. 이때 이전 요청의 시도 횟수가 안전 실행 환경 안의 이전 처리에서 이미 증가된 횟수보다 작기 때문에 시도 횟수 비교 조건을 통과하지 못하고 실패합니다.
구조 구현 과정에서 마주한 두 가지 이슈
앞서 설명한 구조를 구현하는 과정에서 두 가지 이슈가 있었습니다. 첫 번째는 영속 스토리지 접근 제한과 모니터링 강화 작업입니다. 이 이슈는 이번 기능뿐 아니라 서버 환경 전체에 대한 개선점이기 때문에 앞으로 다른 글에서 소개할 기회가 있을 것 같습니다. 이번 글에서는 두 번째 이슈인 시도 횟수 불일치를 줄이거나 방지하기 위해 적용한 방안을 소개하겠습니다.
아래는 대응 방안을 소개하기 위해 안전 실행 환경 서버의 현재 상태에 가깝게 업데이트한 그림입니다. 먼저 간단히 배경을 설명하겠습니다. 안전 실행 환경은 각 환경 서버 인스턴스 내부에 마련돼 있습니다. 각 환경 안에 시도 횟수는 별도로 존재하며 서로 공유하지 않습니다. 이런 상황에서 같은 계정에 대한 시도 횟수는 하나의 안전 실행 환경에서 카운트하고 또 제한되도록 만들 필요가 있습니다. 따라서 요청이 전송될 안전 실행 환경 서버의 인스턴스는 계정 식별이라는 기준으로 결정됩니다.
다시 돌아와서, 시도 횟수 불일치가 발생할 수 있는 상황을 설명하겠습니다. 시도 횟수를 제한하기 위한 조건에서 핵심 참조 값으로 활용하기 위해 시도 횟수는 안전 실행 환경 안에 존재합니다. 한편으로 시도 횟수는 백업 정보와 함께 봉인해야 하기 때문에 영속 스토리지에도 저장해야 합니다. 시도 횟수가 영속 스토리지와 안전 실행 환경 모두에 존재하기 때문에 만약 스토리지 반영이 부분적으로 실패하면 두 값 사이에 불일치가 발생할 수 있습니다.
아래 오른쪽 그림을 보겠습니다. 두 번째 단계에서 안전 실행 환경 내 횟수가 갱신됐지만 다섯 번째 저장소 반영 단계에서 실패하면 저장소에 저장된 값이 안전 실행 환경의 값보다 작은 불일치가 발생합니다.
이런 상황이 발생할 가능성은 적지만 한 번 발생하면 좋지 않은 사용자 경험으로 이어지기 때문에 대응 방안을 생각했습니다. 불일치가 발생한 상황에서 사용자가 다시 복원을 시도하는 상황을 생각해 보겠습니다. 아래 오른쪽 그림과 같이 영속 스토리지에서 가져온 시도 횟수가 안전 실행 환경 안에 있는 시도 횟수보다 작기 때문에 시도 횟수 비교 조건에 위배되므로 안전 실행 환경에서 처리를 거부합니다. 사용자가 올바른 PIN 번호를 입력했다고 하더라도 복원에 실패한 것입니다.
이런 좋지 않은 사용자 경험을 방지하기 위해서 두 가지 방안을 적용했습니다. 먼저 불일치는 스토리지 저장 단계에서 실패해서 발생하기 때문에 저장이 성공할 때까지 재시도하는 방안을 적용했습니다.
이 방안은 LINE에서 운용하고 있는 대규모 Kafka 클러스터와 LINE에서 개발한 프레임워크인 Decaton 덕분에 구현할 수 있었습니다. 재시도해서 저장에 성공하면 불일치가 발생하지 않으므로 사용자가 올바른 PIN 번호를 입력했을 때 실패하는 일은 발생하지 않습니다. 다만 이 방법은 스토리지 실패에 따른 영향을 줄일 수는 있지만 그런 영향을 아예 배제할 수 있는 방안은 아니라는 한계가 있습니다.
두 번째 방안은 시도 횟수 불일치로 실패할 경우 다른 안전 실행 환경으로 재시도하는 방안입니다. 사용자가 올바른 PIN 번호로 시도한 경우를 다시 살펴보겠습니다.
불일치 때문에 안전 실행 환경에서의 요청이 거절되면 기능 서버에서는 다른 안전 실행 환경 서버로 요청을 다시 전송합니다. 다른 안전 실행 환경 서버에서는 해당 계정에 대한 시도 횟수 값이 없기 때문에 입력된 값에 기반해 시도 횟수를 새로 카운트합니다. 스토리지에 있는 시도 횟수와 안전 실행 환경의 시도 횟수가 서로 같은 조건에서 복원을 다시 진행하므로 좋지 않은 사용자 경험이 발생하는 것을 방지할 수 있습니다. 물론 이 방안을 적용하면 공격자가 안전 실행 환경 서버의 숫자만큼 PIN 번호 입력을 시도해 볼 수 있게 된다는 이슈가 발생하지만, 실질적으로 무차별 대입 공격으로 PIN 번호를 알아낼 수 없게 제한하는 데에는 충분하다는 점을 확인했습니다.
마치며
이번 글에서는 LINE 계정 이전 기능의 세 가지 목표를 소개하고 이와 관련해서 최근에 적용한 두 가지 개선 방법, 기존 기기를 갖고 있는 상태에서 생체 인증을 사용해 보다 쉽게 계정을 이전하는 기능과 기존 기기가 없는 상태에서 안전하게 Letter Sealing 키를 백업하고 복원하는 기능을 어떻게 구현했는지 설명했습니다.
마지막으로 향후 계획을 말씀드리겠습니다. 먼저 기존 기기를 갖고 있지 않은 상태에서 계정 이전 기능을 진행할 때에도 피싱 공격의 위협을 벗어나 더욱 안전하게 진행할 수 있도록 지속적으로 개선해 나가고자 합니다. 또한 생체 인증의 장점을 더욱 잘 활용할 수 있도록 서드 파티를 위해 LINE 클라이언트 생체 인증 기능을 LINE 웹 로그인에 적용하려고 계획하고 있습니다. 사용자에게 더 풍부한 대화 내역 백업 기능을 제공할 계획도 있습니다. 앞서 언급했던 클라우드 기반 백업은 서버에서 이미 만료된 대화 내역도 복원할 수 있다는 장점이 있는데요. 이번에 도입한 서버 기반 백업과 상호 보완 관점으로 활용할 수 있도록 다른 플랫폼 사이에서도 클라우드 기반으로 백업하고 복원할 수 있게 지원할 예정입니다.
이번 글에서 공유한 개선 방법은 최근 진행한 두 개의 큰 프로젝트의 결과물입니다. 두 프로젝트에는 서버 개발 팀과 클라이언트 개발 팀, 기획 팀, 보안 팀, 디자인 팀, UX 팀, QA 팀 등 여러 팀에서 수십 명의 사람들이 몇 달 동안 참여했는데요. 두 프로젝트에 모두 참여한 한 사람으로서 어떻게 사용자에게 더 쉬운 기능을 제공하면서 보안을 강화할 수 있을지 노력한 내용을 소개할 수 있어 기뻤습니다. 앞으로도 이와 같은 노력을 쭉 이어나가면서 또 기회가 닿는다면 그 결과물을 발표와 지면을 통해 다시 소개하겠습니다. 긴 글 읽어주셔서 감사합니다.