들어가며

국내 가장 큰 규모의 개발컨퍼런스라고 하는데, 모든 종류의 개발자들을 대상으로 하다보니 오히려 프론트엔드 개발에 특화된 세션은 쉽사리 찾기 어려웠다. 게다가 DAY2에는 더더욱 생소한 도메인을 다루는 발표가 많아보였다. 일단 재미있을 것 같은 오전 세션에만 참여했다. 오프라인 개발 컨퍼런스는 특유의 어색하지만 설레는 분위기가 감돈다. 나도 덩달아 개발에 대한 의욕이나 열정이 다시금 싹트는 것 같아서 좋다.

자바스크립트 화이트박스 암호와 크롬 라인 메신저의 보안 강화

세션 내용 요약

• 개발 생명주기의 초기 단계에 보안 위협을 식별하고 대응하며 개발을 하는 것이 중요하지만, 언제나 그렇듯 이것은 이상적인 방향이고, 더더군다나 보안에 익숙하지 않은 프론트엔드 개발자들이 보안 요구사항을 고려하며 개발하려다보면 workflow가 중단 또는 지연되는 문제가 생긴다. 이를 위해 기존의 개발 프로세스를 방해하지 않으면서도 보안을 개발에 통합하기 위해 라인 팀에서 직접 개발한 모듈을 소개한다.
• 자바스크립트는 브라우저에서 interpret하고 실행하기 때문에 임의의 코드를 주입하기가 쉽고, 이를 통해 개인 키에 접근하는 등의 위험한 행동이 가능하다. 모바일에서는 플랫폼 자체의 시큐어 스토리지를 통해 개인키 등을 안전하게 관리하지만 브라우저 스토리지는 안전하게 저장되는 곳으로 기대할 수 없으며 토큰 유출의 우려가 있다. 앱을 리버스 엔지니어링해서 작동 방식을 파악하고 악의적으로 이를 활용(악성 봇 프로그래밍, 클라이언트를 가장 등)하는 API 어뷰징의 리스크도 있다.
• 이를 대비하기 위해 화이트박스는 공격자가 브라우저에서 실행할 수 있는 모든 권한(파일시스템, 스토리지 등)을 다 가지고 있다고 가정한다. 접근은 하더라도 키의 내용을 알 수 없도록 처리하는 것.
• Web Crypto API와 Indexed DB 조합으로도 메타데이터를 제외한 비밀키의 내용을 자바스크립트를 통해 접근할 수 없도록 보호 계층을 제공한다. 하지만 파일 시스템에 대한 접근에서는 보안을 보장할 수 없고 여타 많은 이유들 때문에 화이트박스를 사용하게 되었다고 한다.
• 화이트박스는 코드 난독화와는 달리 런타임에서도 암호화 메커니즘과 암호키를 안전하게 보관할 수 있으며, 메모리 상에서 암호키가 일반 텍스트 형식으로 노출되지 않는다. 게다가 순수 software 기반 구현이기 때문에 플랫폼에 구애받지 않은 활용이 가능하다. 화이트박스는 암호키에 대한 access에 추가적인 보호 계층을 제공함으로써 키에 직접 접근하더라도 키 내용을 알 수 없다는 것이 특징이며, 장치에 키를 바인딩할 수도 있어 합법적이지 않은 방식의 키 재사용을 막을 수 있다.
• 연산과정에서 발생하는 데이터로 키를 유추하는 부채널 공격에 대해 상용 화이트박스는 저항성을 개선해나가고 있지만, 라인 팀에서 상용 화이트박스를 공격하는 데에 성공했고 이 공격에도 저항할 수 있는, 보다 더 안전한 화이트박스를 개발했다고 한다.
• LTSM이라는 모듈을 통해 서비스에 쉽게 통합적용할 수 있도록 했으며, 웹 어셈블리를 사용하여 처음부터 네이티브에 가까운 실행 속도를 갖는다. 컴파일 전에는 C, C++, Rust로, 컴파일 후에는 자바스크립트로도 사용할 수 있도록 만들었다.

느낀 점

보안의 중요성은 아직은 그렇게까지 와닿을 일이 없었는데, 라인과 같은 글로벌 메신저에서 보안이 뚫린다고 상상하면서 들으니까 아찔하긴 했다. 특정 보안 모듈을 만들고 직접 개선해나간 경험을 들으니 새로웠다. 그리고 보안에 취약한 설계에 탁월한 보안모듈을 넣는다고 보안이 좋아질 수는 없다는 말이 와닿았다. 모든 설계가 그렇긴 하지만 보안에서도 처음 설계단계에서부터 깊이 고려해야 나중에 더 편하고 안전할 수 있다는 것.

웨일 브라우저 오픈 소스 생존기

세션 내용 요약

• 브라우저의 특징
  • 웹 플랫폼: Browser UI (주소창, 탭, 툴바 등) 부분과 웹 컨텐츠 부분으로 나뉜다.
  • 크로스(유니버설) 플랫폼: HTML, CSS, JS로 범용적으로 만들어낼 수 있다.
  • 빠르게 발전하는 플랫폼: 네이티브와 같은 다양한 기능 제공을 위해 놀라운 속도로 발전한다. (참고: 구글 크롬 팀에서 주도적으로 진행하는 Project Fugu)
• 브라우저 개발을 위해 필요한 것: 웹표준, 성능, 그리고 보안
• 오픈소스를 활용할 수 밖에 없는 브라우저 개발: 웹플랫폼 발전 속도 때문에 한 회사에서 이를 따라잡기란 쉽지 않고, MS도 오페라도 결국 자체 엔진을 포기하고 오픈소스인 크로미움으로 갈아탐
• 크로미움과 브라우저 개발
  • 크로미움은 구글 제품인 크롬의 오픈소스화 된 버전으로, 크롬과 비교하면 QA나 코덱(제품화하기 위한 기능들)이 빠져있고 파란색 아이콘을 가졌다.
  • 브라우저를 만드는 공통된 프레임워크로, 전체적인 구조를 보자면 UI를 담당하는 Chrome, 웹 플랫폼(엔진)의 모든 것을 담당하는 Content, 시스템 소프트웨어를 담당하는 Base 이렇게 세가지라고 볼 수 있다.
  • 크로미움을 사용하는 데에도 (1) Base를 따로 뽑아서 사용하거나, 거기에 (2) Content의 웹 엔진도 가져다 사용하거나, (3) 브라우저 UI 뼈대까지 가져다가 사용하는 방법 등이 있는데, 웨일의 경우도 웨일OS에는 (2)까지, 웨일 브라우저는 (3)까지 사용한다고 한다.
  • 그렇지만 웨일OS와 웨일브라우저 모두 기존 기능들에 유의미한 추가기능들을 덧붙였는데, 특히 브라우저에 추가한 기계 번역이나 음성 인식, 음성 합성 등 AI 관련 기술은 벤더사에서 제공한 기능을 뛰어넘는 훌륭한 기술이라고 자랑했다. 웨일 OS에는 디바이스 제어를 위한 기능이 추가적으로 개발되었다고 한다.
• 리베이스의 무게를 견뎌라
  • 리베이스: 사용 중인 오픈소스의 버전을 최신 버전으로 가져오는 작업
  • 브라우저는 앞서 말했듯 빠르게 발전하는데, 이를 따르지 않는다면 사이트 호환이나 보안 등에 뒤쳐지기 때문에 리베이스는 브라우저의 생존과 직결되는 문제이다.
  • 리베이스는 방대한 코드 사이즈와 멀티플랫폼 대응, UI 및 웹엔진 테스트 때문에 굉장히 어려운 일인데, 거기에다가 크롬이 배포 주기를 6주에서 4주로 단축하겠다는 선언을 하면서 웨일 팀도 상시 리베이스 프로젝트로 대응해야 했다. 이에 따라 기능 기반 배포였던 팀 문화를 일정 주기 배포로 바꾸고, 리베이스봇을 개발하며 커밋 단위가 아닌 파일 단위로 변경사항을 관리하는 등을 비롯한 새로운 리베이스 룰을 만들어 컨플릭트를 최소화하고자 했다.
• 웨일 팀은 브라우저를 개발하는 것에 그치지 않고 국내 웹 생태계 이슈를 웹 표준에 반영하려고 노력하거나(공인인증서 기반 전자서명) 피싱사이트를 식별하기 위한 머신러닝 기능을 개발하는 등 오픈소스에 적극적으로 기여하고 있다.

느낀 점

브라우저는 도대체 누가 어떻게 만드는 것일까 라는 의문을 조금 해소할 수 있었던 시간. 크로미움의 강력한 영향력에 대해 알게 되었다. 오픈소스, 게다가 브라우저 오픈소스는 결국 리베이스의 무게를 견뎌내야 한다는 얘기가 발표자가 얘기했듯이 발표의 주 내용이었다. 오픈소스가 결국 깃 클론해서 리베이스를 하는 것이라는 게 신기했다.

리베이스가 필요한 이유(빠른 발전, 사이트 호환이나 보안에 뒤쳐질 수 있다는 리스크), 리베이스에서 겪는 어려움(방대한 코드사이즈, 멀티 플랫폼을 다 대응해야 함, 테스트도 다 해야함), 이를 해결하기 위해 기능 기반 배포 에서 일정 주기 배포로 개발문화 및 팀의 work cycle을 전환하고 자동화를 한 이야기들이 재미있게 다가왔다.

또한 그저 오픈소스를 소비하는 데에 그치지 않고, 오픈소스에 기여하고, 피싱사이트를 식별하는 기술을 개발한다거나 국내 웹 생태계 이슈를 해결하고자 한다는 웨일 팀의 방향성도 굉장히 바람직하다고 느꼈다. 일단 내가 생존하는 것도 중요하지만 같이 사는 곳을 잘 만들어가는 것도 역시 중요하다는 큰 깨달음을 얻어간다.

나가며

오프라인 컨퍼런스는 FECONF 이후 두 번째다. “미래를 향한 개발자의 시선, 탁월함을 나누고 함께 성장합니다”라는 행사 슬로건에 걸맞게, 다양한 분야에서 자신들의 고민과 그 결과를 떨리는 목소리로 나누는 발표자들이 대단하다고 느꼈다.

프론트엔드가 들을만한 세션들이 다 DAY1에 있다던데 나는 참가신청에 실패해서 DAY2로 간 것은 아쉬웠다. 그치만 오늘 들은 이 두 세션에서도 충분히 몇달 또는 몇년에 걸쳐 고생했을 팀의 노력들이 겹쳐보이는 듯 했다. 이슈가 생겼는데 화이트박스 개발진에게 요청하기엔 시간이 오래걸려서 직접 땜질한 이야기, 크롬이 배포주기를 줄이면서 팀의 개발스타일이 송두리째 바뀐 이야기들이 45분으로 커버하기엔 너무나 길었을 것이다.

아무튼 앞으로의 많은 개발 컨퍼런스도 오늘과 같이 조금은 어렵지만 그래도 알아들을 수 있으면 좋겠다. 오늘도 알찬 하루였다.