초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기

들어가며: 왜 Kafka 종단 간 암호화인가?

LINE 메신저에서는 매일 수십억 건의 메시지가 오갑니다. 이 방대한 데이터는 다양한 시스템으로 전달되며, 그중에는 개인 정보와 같이 매우 높은 수준의 보안이 요구되는 민감한 데이터도 존재합니다. LY Corporation은 이러한 민감 데이터를 다층적인 보안 체계로 보호하고 있으며, 위협 환경의 변화와 서비스 규모의 성장에 맞춰 보안 수준을 지속적으로 강화해 나가고 있습니다.

LINE 메신저의 대화방 메시지에는 이미 종단 간 암호화 기술인 Letter Sealing이 적용돼 있습니다. LY Corporation은 여기에 더해 사용자 데이터에 최고 수준의 보안을 적용하기 위해 Kafka 클라이언트 간 종단 간 암호화(end-to-end encryption)를 적용하기로 결정했습니다. 이 방식을 적용하면 Kafka 브로커에 저장되는 메시지 페이로드가 프로듀서에서 컨슈머에 이르기까지 암호화된 상태로 유지됩니다.

이 글에서는 LY Corporation에서 Kafka 종단 간 암호화를 설계하고 구현하여 실제 서비스에 적용한 경험과 그 결과를 공유하고자 합니다. 특히 한 팀에서 발행해 여러 팀의 컨슈머가 소비하는, 최대 초당 100만 건이 오가는 대규모 Kafka 토픽에 대해 무중단으로 종단 간 암호화를 설계·구현·적용한 경험과 그 결과를 공유합니다.

기존 Kafka 보안 모델의 한계

Kafka는 기본적으로 세 가지 핵심 보안 기능을 제공하여 데이터를 보호합니다.

• 전송 구간 암호화(TLS/SSL): HTTPS 통신에 사용되는 SSL 프로토콜을 활용하여 브로커와 클라이언트(프로듀서, 컨슈머) 간의 통신 채널을 암호화합니다. 이를 통해 네트워크를 오가는 데이터가 중간에 도청되는 것을 방지할 수 있습니다.
• 인증(authentication): SASL(Simple Authentication and Security Layer) 프로토콜을 사용하여 클라이언트가 브로커에 접근하기 전에 신원을 확인합니다. 이를 통해 허가받지 않은 사용자가 시스템에 접근하는 것을 막습니다. SASL은 아이디/비밀번호, Kerberos 등 다양한 인증 방식을 지원합니다.
• 인가(authorization): ACL(access control list)을 이용해 특정 사용자나 그룹에게 특정 토픽에 메시지를 발행하거나 소비하는 등의 작업을 수행할 수 있는 권한을 부여하거나 제한합니다.

이러한 강력한 기본 보안 기능이 있음에도 불구하고 민감한 데이터에는 한 층의 보호가 더 필요합니다. 전송 구간 암호화와 인증/인가는 데이터가 이동하는 과정과 접근 권한을 보호하는데 중점을 두는 보안 계층으로, 각 보안 계층이 보호하는 대상과 범위가 다르기 때문입니다. 브로커 서버 역시 엄격한 접근 통제 아래 운영되고 있지만 이는 '누가 접근할 수 있는가'를 통제하는 것이며, 브로커에 저장된 데이터 자체는 평문 형태로 존재합니다.

개인 정보와 같이 높은 수준의 보안이 필요한 데이터는 이러한 접근 통제에 더해 데이터 자체를 암호화하는 방어 계층까지 갖추는 것이 바람직합니다. 즉 데이터를 생산하는 시점부터 암호화하여 컨슈머가 복호화할 때까지 그 상태를 유지해야 합니다. 이것이 저희가 종단 간 암호화를 도입한 이유입니다. 접근을 제한하는 기존 보호 체계 위에 데이터 자체를 보호하는 계층을 더하는 '심층 방어(defence in depth)’ 전략입니다.

핵심 설계

안전하고 효율적인 Kafka 종단 간 암호화 시스템을 구축하기 위해 다음과 같은 핵심 요구 사항을 정의했습니다.

1. 기밀성: 메시지는 프로듀서에서 암호화해 전송해야 하며, 오직 허가된 컨슈머만 복호화할 수 있어야 합니다.
2. 확장성: 프로듀서와 컨슈머는 유동적으로 추가하거나 삭제할 수 있어야 합니다. 새로운 컨슈머를 시스템에 쉽게 추가할 수 있도록 유연한 구조를 갖춰야 합니다.
3. 최소한의 성능 오버헤드: 암호화와 복호화 과정에서 발생하는 추가 리소스(CPU, 메모리) 및 메시지 크기 증가를 최소화해야 합니다.

이 세 가지 요구 사항 중 '기밀성'을 전제로, '확장성'과 '성능'을 함께 만족하는 방향으로 메시지 구조를 설계했습니다.

레코드 단위 암호화

암호화 설계에서 가장 먼저 결정해야 했던 것은 ‘암호화를 어느 단위로 적용할 것인가’였습니다.

‘배치 단위 암호화’는 여러 레코드를 배치 상태로 모은 뒤 브로커로 전송하기 전에 암호화하는 방법입니다. 암호화 전에 압축할 수 있기 때문에 효율이 좋고 CPU 오버헤드가 적으며 처리 속도가 빠릅니다. 하지만, Kafka 클라이언트가 제공하는 공식 확장 포인트(인터셉터 등)는 모두 레코드 단위로 작동하며, 배치가 조립되는 시점 이후에는 개입할 수 없습니다. 따라서 배치 레벨에서 암호화하려면 Kafka 클라이언트 내부 코드를 직접 수정해야 합니다.

‘레코드 단위 암호화’는 여러 레코드를 배치 상태로 쌓기 전에 각 레코드별로 암호화하는 방법입니다. 배치 단위 암호화와 비교해 압축 효율이 매우 떨어지기 때문에 암호화 비용이 다소 높고 메시지 크기가 소폭 증가하지만, Kafka의 표준 확장 포인트를 활용할 수 있다는 결정적인 이점이 있습니다.

레코드 단위로 암호화할 경우 Kafka가 공식 제공하는 확장 포인트인 인터셉터를 활용할 수 있습니다. 표준 API를 사용하면 Kafka 버전 업그레이드 시에도 암호화 로직의 안정성이 보장되며, 기존 프로듀서와 컨슈머에서 Kafka 클라이언트를 수정하지 않고도 암호화를 적용할 수 있습니다. 이러한 이유로 레코드 단위 암호화를 최종 선택했습니다.

DEK-KEK 구조

단일 키 방식은 키 노출 시 전체 보안이 무너질 위험이 있습니다. 저희는 DEK(data encryption key)로 데이터 보호의 효율성을, KEK(key encryption key)로 키 관리의 유연성을 모두 확보하기 위해 DEK-KEK 이중 키 구조를 채택했습니다.

• DEK: DEK에는 프로듀서가 메시지 페이로드를 암호화하는 데 사용하는 AES 대칭 키를 사용하며, 페이로드 암호화에는 AES-GCM 모드를 사용합니다. 대칭 키 알고리즘 특성상 연산 속도가 매우 빠릅니다.
• KEK: KEK로는 허가된 컨슈머들이 공유하는 ECC(타원 곡선) 기반 비대칭 키 쌍을 사용합니다. 키 쌍은 KMS(key management service)에 등록해 관리합니다. 프로듀서는 KMS에서 공개 키를 조회하여 DEK를 암호화하고, 권한을 부여받은 컨슈머는 KMS에서 비공개 키를 조회하여 암호화된 DEK를 복호화합니다. DEK 암호화에는 ECIES(Elliptic Curve Integrated Encryption Scheme) 방식을 사용하며, 타원 곡선으로는 secp521r1을 채택했습니다.

DEK-KEK 구조 도입으로 얻은 이점

1. 대규모 Kafka 환경에서의 성능 최적화

비대칭 키(KEK)만으로 대용량 페이로드 전체를 암호화하면 연산 비용이 매우 커집니다. 이에 따라 저희는 실제 데이터 암호화에는 연산 속도가 빠른 대칭 키(DEK)를 사용하고, 처리 비용이 큰 비대칭 키 연산은 짧은 DEK를 암호화할 때로 한정해 사용합니다. 이를 통해 높은 트래픽을 처리하는 Kafka 환경에서도 암호화 오버헤드를 최소화할 수 있습니다.

2. 메시지 크기를 일정하게 유지(다중 컨슈머 대응)

컨슈머가 아무리 늘어나도 프로듀서는 페이로드를 단 한 번만 암호화하면 됩니다. 메시지 헤더에는 KEK로 암호화된 짧은 DEK 값만 포함되므로, 전체 메시지 크기를 일정하게 유지하면서도 다수의 컨슈머에게 데이터를 안전하게 전달할 수 있습니다.

3. 암호화 권한과 복호화 권한의 분리

비대칭 키 구조를 활용하면 ‘암호화 권한’과 ‘복호화 권한’을 명확히 분리할 수 있습니다. 프로듀서에게는 공개 키 기반의 암호화 권한만 부여하고, 인가된 컨슈머에게만 비공개 키 기반의 복호화 권한을 부여합니다. 이를 통해 최소 권한 원칙을 실현하며, 혹여 공개 키가 외부로 유출되더라도 기존 메시지의 기밀성을 안전하게 보호할 수 있습니다.

메시지 구조

다음은 기존 Kafka 메시지와 E2EE 적용 후 메시지 구조를 비교한 것입니다.

메시지를 성공적으로 복호화하려면 암호화된 데이터와 함께 복호화에 필요한 정보(메타데이터)를 전달해야 합니다. 외부 저장소(DB, 캐시 등)를 사용하면 시스템 의존성이 복잡해지기 때문에 저희는 메시지 자체에 메타데이터를 포함시키는 방식을 선택했습니다.

컨슈머는 메시지를 수신한 후 메타데이터를 확인하여 자신이 복호화할 수 있는 KEK가 있는지 식별합니다. 이후 해당 KEK로 DEK를 복호화하고, 최종적으로 암호화된 메시지 페이로드를 복호화합니다.

• 키(key): 메시지 파티션을 결정하는 데 사용되는 기존 키는 그대로 유지합니다.
• 헤더(header): Kafka 0.11.0 버전부터 사용 가능한 헤더에 복호화에 필요한 메타데이터를 담았습니다. 여기에는 '컨슈머를 식별할 수 있는 KEK ID'와 'KEK로 암호화된 DEK'가 포함됩니다.
• 바디(body): DEK로 암호화된 최종 페이로드가 들어갑니다.

시스템 아키텍처

앞서 설계한 메시지 구조를 바탕으로, 실제 시스템은 다음과 같이 프로듀서와 컨슈머가 각자의 역할을 수행하도록 구현했습니다.

프로듀서: 인터셉터를 활용한 암호화 및 DEK 캐싱

프로듀서는 메시지를 암호화하여 브로커로 전송하는 역할을 담당합니다.

• DEK 생성: 메시지 페이로드를 암호화하기 위한 대칭 키(DEK)를 생성합니다.
• DEK 암호화: 미리 전달받은 공개 키(KEK)로 DEK를 암호화합니다.
• 메시지 생성: 암호화된 DEK를 헤더에, DEK로 암호화된 페이로드를 바디에 담아 최종 메시지를 완성합니다.

이 모든 암호화 과정은 Kafka 인터셉터(interceptor)와 시리얼라이저(serializer)에서 처리합니다.

• 인터셉터: 헤더를 처리합니다. 메시지가 전송되기 직전에 가로채서 DEK를 생성하고, KEK로 DEK를 암호화한 후 이 정보를 헤더에 삽입합니다.
• 시리얼라이저: 페이로드를 처리하며, 기존 데이터 시리얼라이저를 감싸는 래퍼(wrapper) 형태로 구현했습니다. 1차로 직렬화된 바이너리 데이터를 전달받아, 인터셉터가 준비한 DEK를 사용하여 2차로 암호화를 수행합니다.
• DEK 전달: 인터셉터와 시리얼라이저가 동일한 실행 스레드를 공유하는 특성을 활용하여, 생성된 DEK를 ThreadLocal에 담아 전달하고 처리가 끝나면 자원을 정리합니다.

매 메시지마다 DEK를 새로 생성하고 KEK로 암호화하는 것은 불필요한 리소스 낭비입니다. 따라서 저희는 DEK를 일정 시간 캐싱해 놓고 해당 시간 동안 전송되는 메시지에는 같은 DEK를 사용하도록 구현했습니다. 이렇게 하면 대부분의 메시지는 평문 데이터를 암호화하는 추가 리소스만 사용하기 때문에 프로듀서의 성능을 크게 향상시킬 수 있습니다.

컨슈머: 디시리얼라이저를 통한 복호화 전략

컨슈머는 브로커가 전달하는 암호화된 메시지를 받아 복호화하는 역할을 수행합니다.

• KEK 조회: KEK는 토픽 오너가 생성하여 KMS에 등록합니다. 각 컨슈머는 인가 절차를 거친 후 KMS에서 비공개 키를 조회하여 메시지 복호화에 사용합니다.
• DEK 복호화: 수신된 메시지의 헤더에서 암호화된 DEK를 찾아, 자신이 가진 KEK의 개인 키로 복호화합니다.
• 페이로드 복호화: 복호화된 DEK를 사용하여 메시지 바디에 담긴 페이로드를 복호화합니다.

이 복호화 과정은 디시리얼라이저(deserializer)에서 처리합니다. 디시리얼라이저는 기존의 역직렬화 로직을 감싸는 형태로 구현합니다. 메시지를 수신하면 먼저 헤더의 메타데이터를 기반으로 DEK를 복호화하고, 이 DEK로 페이로드를 복호화한 후 역직렬화를 수행합니다.

여러 프로듀서는 각각 서로 다른 DEK를 사용할 수 있습니다. 따라서 컨슈머는 암호화된 DEK와 복호화된 DEK 쌍을 캐싱해 동일한 암호화 DEK가 다시 수신되면 복호화 과정을 건너뛰도록 했습니다. 이 전략으로 DEK 복호화에 소요되는 리소스를 줄여 컨슈머의 효율을 높일 수 있었습니다.

KMS

KEK의 생성, 배포, 교체는 모두 KMS를 통해 관리합니다. 토픽 오너가 비대칭 키 쌍을 생성하여 KMS에 등록하면, 프로듀서는 공개 키를, 권한을 부여받은 컨슈머는 비공개 키를 조회하여 사용합니다. 새로운 컨슈머가 추가될 때는 KMS에서 해당 비공개 키에 대한 접근 권한을 요청하고, 토픽 오너의 승인을 거쳐 복호화 권한을 얻습니다.

대규모 서비스에 적용하기 위한 최적화 전략

설계와 구현을 완료한 후 실제 LINE 서비스에 적용하는 과정에서 세 가지 핵심 도전 과제가 있었습니다. 메시지 크기 증가, 무중단 마이그레이션, 운영 중 키 교체입니다.

메시지 크기 최소화: 공유 KEK(Shared KEK) 도입

종단 간 암호화 시스템을 실제 서비스에 적용하면서 마주한 가장 큰 도전 과제는 ‘메시지 크기 증가 문제’였습니다. Kafka 토픽의 특성상 여러 팀의 컨슈머가 존재하거나 계속해서 추가될 수 있는데요. 이때 컨슈머마다 고유한 키를 부여하면 메시지 헤더에 컨슈머 수만큼 메타데이터가 누적되어 메시지 크기가 그에 비례해 늘어납니다. 메시지 크기 증가는 시스템 전체의 성능 저하를 유발하는 치명적인 요인입니다. 하나의 배치에 담기는 레코드 수가 줄어들 뿐만 아니라 네트워크 대역폭과 CPU, 메모리 등 시스템 자원 소모량이 전반적으로 급증하기 때문입니다.

특히 앞서 언급한 초당 최대 100만 건의 대규모 트래픽 환경에서는, 컨슈머별로 다른 KEK를 사용했을 때 헤더 사이즈가 급격하게 증가해 전체 시스템의 성능이 저하됩니다. 또한 신규 컨슈머가 추가될 때마다 헤더에 메타데이터가 추가되기 때문에 오래 지속하기 어려운 구조였습니다.

저희는 이 문제를 근본적으로 해결하기 위해 처음부터 여러 컨슈머가 하나의 KEK를 공유하는 방식을 채택했습니다. 공유 KEK를 사용하면 컨슈머 수와 무관하게 메시지 헤더에는 단 하나의 메타데이터만 포함됩니다. 공유 KEK는 컨슈머별 키 격리 대신 일정한 메시지 크기를 택한 트레이드오프로, 이를 보완하기 위해 KMS 인가와 주기적 키 교체를 함께 운영합니다.

• 키 배포: 토픽 오너가 비대칭 키 쌍을 생성하여 KMS에 등록합니다. 프로듀서는 KMS에서 공개 키를, 허가된 컨슈머는 KMS에서 비공개 키를 조회하여 사용합니다. 키의 생성과 배포 책임이 토픽 오너에게 집중됩니다.
• 접근 제어: 컨슈머가 KMS에서 비공개 키를 조회하려면 인가 절차를 거쳐야 합니다. 이 접근 제어가 암호화된 데이터의 보안 경계 역할을 합니다.
• 키 교체: 공유 키 구조의 위험을 완화하기 위해 주기적인 키 교체를 의무화합니다(무중단 교체 메커니즘은 뒤에서 설명합니다).

무중단 마이그레이션

평문 폴백

암호화 도입 시 가장 큰 리스크는 데이터 유실과 서비스 중단입니다. 모든 프로듀서와 컨슈머를 동시에 전환할 수 없으므로 암호화 메시지와 평문 메시지가 공존하는 과도기 단계를 안정적으로 지원해 넘겨야 합니다. 이를 위해 컨슈머의 디시리얼라이저가 메시지 헤더의 메타데이터 유무를 감지하여 작동을 결정하는 구조를 구현했습니다.

• 헤더 존재: 헤더가 존재하면 암호화 메시지로 판단하고 헤더에서 암호화 정보를 추출하여 복호화 후 역직렬화를 수행합니다.
• 헤더 없음: 헤더가 없으면 평문 메시지로 판단하고 복호화 과정을 생략하고 기존 방식대로 역직렬화만 수행합니다.

이와 같은 평문 폴백 구조 덕분에 다음과 같은 안전한 순서로 마이그레이션을 진행할 수 있었습니다.

1. 컨슈머 먼저 배포: 폴백 로직이 포함된 컨슈머를 먼저 배포하여, 어떤 형태의 메시지가 와도 처리 가능한 상태를 만듭니다.
2. 프로듀서 암호화 활성화: 모든 컨슈머가 준비되면 프로듀서의 암호화 기능을 활성화합니다.
3. 검증 및 완료: 모니터링 지표를 통해 평문 메시지 비중이 0%가 된 것을 확인하고 마이그레이션을 종료합니다.

점진적 배포

컨슈머가 준비되었더라도 프로듀서의 암호화 비율을 단번에 100%로 높이는 것은 위험합니다. 예상치 못한 성능 저하나 암/복호화 오류에 대비하기 위해 동적 설정 기반의 점진적 배포 전략을 취했습니다.

• 단계적 비중 확대: 초기에는 암호화 비율을 최소치(예: 1%)로 설정하여 극소수의 트래픽에만 암호화를 적용합니다.
• 지표 기반 의사 결정: 실시간으로 CPU 부하, 처리 지연 시간(latency), 에러율 등의 지표를 관찰하며 10%, 50%, 100% 순으로 단계적으로 비중을 높입니다.
• 즉각적인 롤백: 만약 이상 징후가 발견되면 설정값 조절만으로 즉시 암호화 비율을 0%로 낮춰 시스템을 롤백할 수 있습니다.

운영 안정성: 무중단 키 교체 메커니즘

공유 KEK는 여러 컨슈머가 동일한 키를 사용하는 구조이므로 키가 유출될 경우 허가되지 않은 사용자가 과거 메시지뿐 아니라 향후 메시지까지 복호화할 수 있는 위험이 생깁니다. 이를 해결하기 위해 주기적으로 키를 교체하는 것을 보안 요구 사항으로 정의했습니다. 이때 교체는 서비스를 중단하지 않고 진행해야 합니다. 이를 위해 전환 기간 동안 기존 키와 새로운 키가 공존하는 메커니즘을 구현했습니다.

무중단 교체 메커니즘

프로듀서의 인터셉터는 KMS의 공개 키 목록을 특정 주기로 폴링(polling)합니다. 변경이 감지되면 현재의 DEK를 등록된 모든 공개 키로 각각 암호화해 메시지 헤더에 함께 포함시킵니다. 따라서 키 교체 전환 기간에는 헤더에 구 KEK로 암호화된 DEK와 신규 KEK로 암호화된 DEK가 나란히 존재합니다.

컨슈머 역시 특정 주기로 KMS를 폴링하여 신규 비공개 키를 자동으로 반영합니다. 컨슈머는 헤더의 각 항목에 포함된 KEK ID를 확인하여 자신의 키와 일치하는 항목만 선택해 복호화합니다. 덕분에 예전 키를 사용하는 컨슈머와 신규 키를 사용하는 컨슈머가 전환 기간 동안 같은 메시지를 동시에 처리할 수 있습니다.

교체 절차

1. 신규 KEK 등록: KMS에 새 KEK 버전을 등록합니다. 이 시점에서 구 버전은 아직 유지됩니다.
2. 프로듀서 사용 확인: 약 1분 후 프로듀서가 신규 KEK를 반영했는지 지표로 확인합니다. 구 KEK와 신규 KEK 모두 나타나야 정상입니다. 이 시점부터 메시지 헤더에는 두 개의 암호화된 DEK가 포함됩니다.
3. 컨슈머 신규 키 전환 확인: 약 1분 후 컨슈머가 신규 KEK로 복호화하고 있는지 지표로 확인합니다.
4. 구 KEK 비활성화: 컨슈머의 신규 키 전환이 확인된 후에만 KMS에서 구 버전을 비활성화합니다. 이 시점을 앞당기면 컨슈머 복호화가 실패할 수 있으므로, 반드시 3단계 확인 후 진행합니다.
5. 교체 완료 모니터링: 프로듀서가 신규 KEK만 사용하고 있는지 최종 확인 후 교체를 완료합니다.

검증 및 배포

성능 테스트(벤치마크 테스트)

암호화를 실제로 배포하기 전, 운영 중인 프로덕션 토픽에 성능 관점에서 어떤 영향을 미치는지 정량적으로 측정했습니다. 이론적으로 추정하는 대신 실제 프로덕션 트래픽 규모를 재현해 테스트 환경에서 벤치마크 테스트를 수행했습니다.

테스트 설계

• 환경: 프로덕션과 동일한 서버 장비를 사용한 테스트 환경을 구성하고 기존 토픽에 영향을 주지 않도록 테스트 전용 토픽을 별도로 생성했습니다.
• 부하 재현: 부하 테스트 도구를 이용해 프로덕션에서 측정한 최대 RPS(requests per second)와 최대 메시지 크기를 동일하게 재현했습니다.
• 측정 방식: 평문·암호화 메시지를 각각 10분씩 처리하며 인스턴스당 CPU 사용량을 측정하고, 그 차이를 암호화 오버헤드로 계산했습니다.
• 컨슈머 동시성: 실제 환경의 파티션 수와 스레드 수를 기준으로 테스트 환경의 파티션 수에 맞게 동시성을 비례 조정하여 실제와 동일한 부하 조건을 구성했습니다.

테스트 결과

모든 측정 대상에서 인스턴스당 CPU 증가량이 1% 미만이었습니다. 가장 높은 RPS(~5,000건/초)와 수십 KB 규모의 메시지 크기라는 조건을 함께 갖는 토픽에서도 프로듀서와 컨슈머 모두 CPU 증가량은 약 1%에 그쳤습니다. 이 결과를 바탕으로 Kafka 암호화 도입 때문에 서버를 증설할 필요는 없다고 결론 내렸습니다.

프로덕션 배포

벤치마크 테스트로 안전성을 확인한 뒤 점진적으로 배포하면서 약 2주에 걸쳐 암호화 비율을 단계적으로 100%까지 높였습니다.

• 운영 지표: 전 배포 기간 동안 암/복호화 관련 장애 알림은 단 한 건도 발생하지 않았습니다(0건).
• 실제 부하: 프로덕션 환경에서의 실시간 CPU 증가량 역시 예측치와 동일하게 1% 이하로 유지되었습니다.

이를 통해 서비스 중단이나 인프라 비용 추가 없이, Kafka 전 구간에 걸친 종단 간 암호화를 성공적으로 적용했습니다.

마치며

이 글에서는 LINE이 Kafka 종단 간 암호화를 어떻게 설계하고 적용했는지를 살펴봤습니다.

이번 프로젝트를 통해 구축한 Kafka 클라이언트 간 종단 간 암호화 체계를 통해 LINE 메신저의 데이터 보안 수준을 한 단계 더 높은 차원으로 끌어올릴 수 있었습니다. 메시지가 생성되어 전달되고 저장되는 전 과정에서 데이터 기밀성을 원천적으로 확보함으로써, 전 세계 사용자가 LINE 메신저를 더욱 안심하고 사용할 수 있는 강력한 보안 토대를 마련했습니다. 더 안전하고 신뢰할 수 있는 메시징 플랫폼을 만들기 위한 LY Corporation의 기술적 도전은 앞으로도 멈추지 않겠습니다.