메신저 서비스 회사의 새해 준비

안녕하세요. 저는 LINE Plus 서비스 엔지니어링 팀의 권용찬이라고 합니다. 올해로 LINE에 입사한 지 4년 차입니다. 모르는 것도 없지만 다 알지도 못하는 애매한 연차라고 할 수 있겠습니다. 글의 시작을 세기말 자기소개서처럼 시작하는 이유는 제가 IT 인력치고 노령(?)인 탓도 있겠지만... 사람을 만나면 처음 하는 것이 인사일 것이고 인사를 할 때는 예의를 갖춰 간단한 자기소개로 시작하는 것이 일반적인 것 아닌가 생각하기 때문입니다. 회사에서 운영하는 기술 블로그라 개인 블로그처럼 블링 블링한 스티커를 쓰기는 어렵지만 그래도 나름대로 글을 쓰면서 상상으로나마 하트도 넣고 LINE 캐릭터 스티커도 넣어보고 있습니다.  :)  (하... 하얀 화면에 글만 쓰자니 왠지 바삭바삭하다...) 

누구나 인사를 한다

과거 얼굴 보고 하는 인사가 최고였고(덕분에 12월은 형님들 따라다니면서 인사하느라 한 달 내내 바빴습니다), 여의치 않으면 전화로 목소리라도 전달해야 인사로 인정받던 시절에는 삐삐 암호화 숫자나 부의 상징이었던 SMS 문자 인사는 예의상 전하는 지라시 취급을 받았죠. 당시 이미 메신저가 있었기에 젊은 사람들은 메신저로 축하 인사를 주고받곤 했습니다(삐삐 이야기는 건너 뛰겠습니다... 도저히... 라떼는 말입니다...). 시간이 좀 흐른 뒤에는 휴대폰 MMS(Multimedia Messaging Service)를 이용한, 사진이나 이미지에 '새해 복 많이 받으세요'와 같은 문구를 추가한 메시지가 나름 핫했습니다. 꽃 사진에 좋은 말씀 붙여 넣은 메시지의 연말 버전 정도 되겠습니다.

사람들이 잔뜩 모여 가뜩이나 모자란 통신망에 이미지 전송은 대역폭 부족을 가중시켰습니다. 사람이 많이 모이는 종로와 혜화동, 신촌, 홍대 등지에 모자란 통신 대역폭을 커버하기 위해 이동형 기지국이라고 부르는 안테나 달린 트럭들이 배치됐습니다. 왠지 트럭 곁에서 전화하면 더 전화가 잘 될 것 같은 느낌적인 느낌 때문에 기지국 차량 근처에는 사람들이 북적북적했습니다. 인터넷이 안 될 때 공유기 옆에서 노트북을 켜는 느낌이랄까요. 모든 공중전화기에는 '엄마 나 오늘 늦어'를 시전하기 위해 사람들이 모여 들었고, 나름 부자의 상징이었던 2G폰 사용자와 찬란하게 타올랐다 사라져 간 일명 시티폰 사용자들은 발을 동동 구르며 00시 00분에 누군가에게 메시지를 보내기 위해 노력했습니다. 당시 트래픽 문제는 인터넷 회선이 부족해서라기보다는 전신 교환기 병목과 무선 주파수의 대역폭이 부족해서 단말기 접속 자체가 불가능해지는 상황이었던 터라 지금과는 양상이 달랐는데요. 한 번에 쏟아지는 통화량에 매해 연말이면 통신사들이 비상이었다는 신문기사를 읽은 기억이 납니다.

30년 정도 지난 지금은 달라졌을까요? 개인적인 생각으로 주파수 대역폭이 부족하고 교환기가 밀리던 그때나, 인터넷 회선이 부족하고 서버 처리량이 부족해서 이에 대응하기 위해 IT 인력들이 고민하는 지금이나 넓게 보았을 때 큰 차이가 없어 보입니다. 차이라면 안테나를 등에 지고 산과 건물 꼭대기에 오르거나 이동형 기지국 차량을 끌고 다니던 물리적인 행동이 네트워크 사업자와 계약해서 소프트웨어로 대역폭을 확충하고 클라우드에서 서버를 몇 대 할당받을지 고민하는 것으로 바뀐 정도라고 할까요? 아날로그 방식이 디지털로 변했지만 거시적으로는 크게 변한 것이 없다는 생각이 듭니다. 

그리고 그때나 지금이나 중요한 가치는 통신이 아니라 '인사'라고 생각합니다. 우리는 누구나 적절한 때가 되면 인사를 합니다. 인사는 서로 간의 관계를 이어가기 위해 노력하는, 인간의 기본적인 욕구에 가깝다고 생각합니다(인사할 타이밍을 놓쳐서 안절부절해 본 적 있으시죠?). 우리는 가까운 누군가에게 마음을 전달하려고, 또는 의무감이 들거나 필요해서 인사를 전합니다. 4년간 LINE에서 근무하면서 LINE의 서비스에 대해 생각할 때, 저는 제가 사람들 사이의 연결을 유지해 주기 위해서 일하고 있다고 생각했습니다. 그리고 올해에는 그 인사들이 잘 전달되도록 준비하는 LINE의 연말 준비 과정인 '신년 대응'을 담당하게 되어, 신년 대응과 함께 2022년 새해를 맞이하게 되었습니다. 

감성이 숫자가 될 때

우리가 전하는 인사는 감성적인 의미를 상대에게 전하는 행위라고 생각합니다. 좋아하는 사람이 보낸 인사에는 행복해하면서 몇 년간 얼굴도 보지 못한 비즈니스 관계의 사람이 뿌리는 해 뜨는 사진에는 투덜거리기도 하지요. 이런 감성적인 행동이 여러분의 단말기에서 출발해서 아시아, 유럽, 북미의 통신사를 거쳐 해저 인터넷망을 타고 지역 서버에까지 들어오면 우리는 그것을 '트래픽'이라고 부릅니다.

LINE이 사용자의 트래픽을 문제없이 수용하기 위해서는 감성을 수치로 환산해야 합니다. 메시지를 잘 전달하기 위해 각 국가의 00시 00분에 출발할 메시지의 양을 예상하고 경로와 대역폭을 판단하기 위해 bps(bit per second), pps(packet per second) 등의 수치로 환산합니다. 또한 LINE의 관문까지 도달한 메시지가 서버로 들어올 때 이를 받아들이기 위해 요청량을 RPS(request per second), TPS(transaction per second) 등으로 수치화하고, 동시 사용자(concurrent user)와 방문자, UV(unique visitor) 등 좀 더 비즈니스 관점에서 해석할 수 있는 수치로 변경하기도 합니다. LINE의 경우 메신저 회사이다 보니 초당 메시지 전달 건수를 표현하기 위해 msg/sec(message per second)라는 단위를 사용하기도 하지요. 

이와 같은 단위들은 네트워크 장비의 계산, 웹 서버와 애플리케이션 서버의 계산, 데이터베이스의 계산, 소프트웨어에서 한도 설정, 비즈니스 영역의 계산 등 각 영역에서 사용됩니다. 우리는 이렇게 수치화해서 네트워크 용량과 서버 수량, 처리할 최대 요청량 등을 사전에 계산하고 준비하는데요. IT 업계에서는 이런 행위를 '사이징(sizing)한다' 또는 '에스티메이션(estimation)한다'라고 표현하며 LINE에서는 이를 '신년 대응'이라고 합니다. 

올해 신년 대응에서 LINE은 1초에 41만 4천여 개의 새해 인사를 성공적으로 전달했습니다(피크 수치는 414,382 msg/sec). 참고로 내부 통계를 살펴보면 LINE의 하루 평균 메시지 전송량은 대략 42억 건 정도입니다.   

신년 대응 과정과 준비하는 사람들

준비의 시작은 10월

LINE의 신년 대응은 이르면 9월, 늦어도 10월에 시작됩니다. 좀 이르다 싶지만 앞서 말씀드린 사전 계획을 짜고 그에 따라 물리적인 장비들을 구입하는 데 생각보다 많은 시간이 소요됩니다. LINE에서도 AWS(Amazon Web Service)와 같은 퍼블릭 클라우드를 일부 사용하지만, 자체 클라우드인 Verda(베르다)와 함께 대부분 자체적으로 대응합니다. Verda에서 제공받는 서버 수량에 더해 추가로 장비가 필요하다면 장비 도입 시간이 필요하므로 미리미리 준비를 시작합니다.

가장 먼저 정해야 할 것은 '올해의 공대장은 누가 할 것이냐'입니다. B사의 MMORPG를 해보신 분이라면 '공대장'이라는 단어의 의미가 와닿으실 겁니다. 확실히 알 수는 없지만 LINE의 OB들이 게임 죽돌이가 아니었나... 하는 생각을 해봤습니다. 저 역시 해당 게임을 했던 사람이라 처음 듣고 피식 웃었던 기억이 납니다. 보스 몬스터를 공략하기 위한 공격대를 의미하는 '공대'라는 단어를 쓰다니... 아무튼 공대장이 모든 서비스를 담당하거나 모든 준비를 하는 것은 아닙니다. 조금 더 말씀드리자면, 하나의 레이드 공대는 여러 개의 작은 공대가 모여서 만들어집니다(아... 설명하다 보니 좀... 그렇네...). 회사에는 수많은 서비스가 있고 각 서비스를 담당하는 팀들이 있습니다. 이 팀들이 각각 담당하는 서비스에 대해 준비 작업을 진행하는데요. 이때 서비스 간에 공유해야 할 정보와 공통적으로 챙겨야 할 일들을 챙기면서 전반적인 진행 과정을 확인하고 정리하는 담당자가 있어야 하기에 한 명을 뽑습니다. 그렇게 '올해는 너 님이 공대장'이 됩니다. 서비스 단위의 이슈(장애, 이벤트 등)가 발생했을 때 필요한 인원들이 모여 대응을 하는 것을 막공(막 만든 공격대)이라고 한다면, 매해 신년 대응은 정공(정규 공격대) 정도 된다고 보면 되겠습니다.

준비 미팅

사전 준비 미팅

10월에 공대장이 정해지면 다음으로 공대원을 모집해야 합니다. 신년 대응에 참여해서 각 서비스별로 실질적인 업무를 진행할 인원을 확인해서 Wiki에 목록으로 정리하고, 각 서비스의 진행 상황을 공유합니다. 매년 하던 일이라 전년도에 참여한 분들의 목록이 이미 있으므로 대상자들에게 '올해도 때가 되었습니다'를 공지(Slack)합니다. 공대장이 만들어 놓은 템플릿에 인원을 채워 넣고, 준비하고 있는 업무 티켓(Jira)과 정리한 문서(Wiki)들을 업데이트하면서 실질적인 준비를 시작합니다.

첫 미팅에서는 '우리는 올해 이런저런 일이 있었고, 신년 트래픽 대응을 위해서 그런저런 일을 준비하고 있다'를 공유합니다. MSA(Micro Service Architecture)까지는 아니더라도 메신저 서비스를 중심으로 파생된 수많은 서비스가 있기 때문에 각 서비스는 상호 간에 영향을 주고받습니다. 예를 들어, 사용자가 신년 인사로 스티커를 보내는 과정은 세부적으로 메신저 서비스의 프런트엔드를 담당하는 부분과 실제 스티커를 서비스하는 백엔드로 분리되어 있는데요. 만약 백엔드만 준비되고 프런트엔드의 준비가 미진하다면 문제가 될 수 있습니다. 이를 방지하기 위해 사전 미팅에서는 신년 대응을 위해 준비할 사항을 공유하고 관련된 다른 서비스의 준비 사항을 체크하며 같이 협업할 지점을 파악합니다. 

최종 준비 미팅

12월이 되면 대부분의 준비 과정이 끝나고 코드 프리즈(code freeze, 코드를 수정하지 않는 기간) 기간으로 들어갑니다. 긴급한 수정이 아니라면 더 이상 애플리케이션을 수정하지 않고 장애 위험을 줄이기 위함입니다. 이때에는 주로 시스템을 모니터링하기 위한 도구(Grafana, Kibana, elasticsearch 등)들을 준비합니다. 모니터링 지표를 좀 더 잘 볼 수 있도록 그래프를 만들고 새로 추가된 점검 항목이 있다면 추가하는 등 신년 대응 시에 시스템의 상태를 빠르게 파악하기 위해 준비합니다. 그리고 첫 번째 관문(?)인 크리스마스가 다가옵니다. 크리스마스이브의 트래픽은 사실 신년 트래픽에 비하면 높은 수준은 아닙니다. 하지만 평상시 트래픽보다는 높기 때문에 짧은 시간에 몰려오는 트래픽에 시스템이 반응하는 상태를 사전에 검토하기 좋습니다. 크리스마스가 지나면 마지막 미팅을 준비합니다. 약 100여 명이 넘는 여러 국가의 인원들이 각 서비스별 준비 사항을 최종 공유하며 새해를 맞이할 준비를 합니다.

00시 00분에는 지켜볼 뿐(준비를 열심히)

10월부터 약 3개월간 준비하고 나면 마지막 31일에는 여러 가지 사전 작업이 계획되어 있습니다. 예상한 수치에 맞춰 장비만 추가한다고 되는 것이 아니기 때문에 여러 가지 상황을 고려해서 필요에 따라 소프트웨어에서 제한을 준비하기도 합니다. 예를 들어, 원래는 LINE VOOM을 보면 동영상이 자동으로 재생되지만 연말과 연초의 일정 기간 동안에는 자동 플레이를 잠시 멈추고 사용자가 눌렀을 때 동작하게 하거나(네트워크와 저장소 부하 감소), 배치 작업 때문에 특정 시간에 서버에 걸리는 부하가 많아진다면 해당 기능을 꺼놓았다가 신년 대응이 끝나고 다시 켜는 작업 등이 있습니다. 이런 작업이 올해에는 약 76건(공식적으로 공유된 작업만) 있었고, 각 담당자들이 기능을 조정하는 작업을 사전과 사후에 수행했습니다. 이 작업은 31일 오전부터 1월 1일 새벽까지 진행하는데요. 좀 더 먼저 진행하거나 늦게 진행하는 경우도 있습니다.

이렇게 많은 준비를 끝내고 나면 정작 00시 00분에는 그다지 할 일이 없습니다. 충분히 예상하고 준비해 놓은 상태이므로 몰려오는 트래픽을 당연히 처리할 수 있어야 합니다. 만약 준비가 부족했다면 우리가 가끔 연말에 메시지가 늦게 가거나 안 갔다며 투덜거렸던 바로 그 상황이 벌어지고, 여러 담당자들은 문제점을 파악하기 위해 새벽에 고생하게 되겠지요. 사실 COVID-19 전후로 많은 것이 바뀌었습니다. 트래픽이 더 많아졌으며 오프라인에서 대응하던 대부분의 LINE 동료들은 앞서 말씀드린 준비를 원격으로 진행하게 되었습니다. 새해 당일에도 고개를 돌려 얼굴을 보고 이야기하던 환경에서 화상회의로 바뀌었고 메신저나 여러 협업 도구를 통해서 신년 대응을 진행하게 되었습니다. 이렇게 진행한 첫해(2021년의 새해)에는 처음으로 온라인으로 진행하는 신년 대응이라 서로 소통하거나 작업하면서 혼선이 발생하기도 했지만, 올해는 지난 일 년간 쌓아온 원격근무 경험을 바탕으로 큰 무리 없이 진행했다고 생각합니다.

앞으로 이런 시기가 얼마나 지속될지는 알 수 없지만 그저 근무하는 장소가 변경된 것일 뿐, 큰 문제가 될만한 상황은 없었다는 것이 원격 근무 3년 차의 생각입니다. LINE의 동료분들은 2023년 새해를 위해 올해도 열심히 준비하며 사용자들의 인사를 잘 전달할 수 있도록 노력할 것입니다.

리뷰 미팅

새해 00시 00분이 지나면 그동안 준비했던 시간들이 성적표로 나옵니다. 미진했던 부분이나 작년에 있었던 이슈가 해결되었는지 등을 정리하는 시간이 필요하기 때문에 1월 중으로 가능한 한 빠르게 리뷰 미팅을 진행합니다. 리뷰 미팅에서는 트래픽이 얼마나 유입됐는지, 계획했던 사항들이 잘 진행됐는지 등을 논의하고 미진했던 부분들은 모두 티켓(Jira)으로 정리합니다. 이 미팅까지 끝나면 비로소 신년 대응이 마무리됩니다.

가장 많은 트래픽을 기록하는 일본의 사용량은 무리 없이 수용됐습니다. 입사 후 매년 일본(GMT+9)에서는 항상 많은 애플리케이션 서버 부하가 유발됐던 터라 걱정했었는데요. 너무나 깔끔하게 진행되어 오히려 살짝 놀랐습니다(작년보다 트래픽은 늘었습니다). 이후 대만과 태국의 새해(GMT+8,7)도 무리 없겠다는 생각에 마음을 놓았지만, 항상 그렇듯이 예외는 있었습니다. 일부 요청이 지연되는 상황이 벌어졌습니다. 서비스를 준비하신 분들은 아쉬우셨을 것 같지만, 여러 이슈 때문에 변경된 네트워크 환경과 늘어난 대만과 태국의 트래픽의 영향으로 깔끔하게 넘어가지는 못했습니다. 관련 팀에서 원인을 분석한 뒤 리뷰 미팅에서 이런 상황이 발생한 이유와 대응 방안에 대해 논의했습니다.

리뷰 미팅의 목적은 발생했던 이슈들을 정리해서 해결하는 것도 있지만, 일련의 과정들을 잘 남겨서 다음 신년 대응 준비에 반영하고 확인하기 위함도 큽니다. 리뷰 미팅을 마지막으로 신년 대응은 모두 끝나며, 신년 대응에서 확인된 이슈들은 별도 티켓으로 진행해서 모두 리포팅하고 문서로 남깁니다. 

2022년 신년 대응을 돌아보며

기술 관점에서 살펴보기

서비스 수용 능력 관리

서비스 조정

약 3개월의 준비 기간 동안 서비스를 담당하는 인원들은 각자 담당한 서비스의 처리 능력을 고민합니다. 실제 부하를 측정(BMT, benchmark test)하고 연말에 몇 배나 증가할지 예상한 뒤 예상한 수치만큼 물리적인 서버를 준비하는 과정을 거칩니다. 하지만 늘 그렇듯 환경이 변하거나 이슈가 발생해서 예상 수치를 뛰어넘는 트래픽이 들어올 수 있습니다. 이런 트래픽을 제한하기 위해 흔히 말하는 서킷 브레이커(circuit breaker, 회로 차단기)를 준비합니다. 예상했던 트래픽보다 많은 요청량이 들어오면 서버가 넘치는 부하를 처리하려고 동작하다가 모든 요청이 정지되는 상황이 벌어질 수 있습니다. 이런 문제를 피하고자 사전에 일정 수치 이상의 값이 들어오면 그다음 요청은 포기하거나 지연시키는 기능을 넣어 둡니다. 또는 능동적으로 대응하기 위해서 비율로 차단할 수 있도록 준비하고, 트래픽 증가량에 따라 유연하게 부하를 조정하며 대응합니다(예를 들어 트래픽의 10% 차단). 이와 같이 각 서비스 담당자들은 신년 트래픽이 유입되는 것을 실시간으로 모니터링하다가 이슈가 발생하면 앞서 말씀드린 작업들을 수행하면서 새해를 맞이합니다.

장비 대수 조정

LINE에서 서빙하는 많은 서비스의 최전방에는 사용자 요청을 수용하는 메시징 서비스용 서버들이 있습니다. 대략 1천여 대의 프런트엔드 서버들이 약 1억 8천9백만 MAU(Monthly Activity User)를 처리합니다(2021년 11월 기준). 이 서버 대수가 지속적으로 증가하는 것은 아닙니다. MSA(Micro Service Architecture) 요구로 인하여 서비스 그룹이 추가되면서 증가하기도 하지만, CPU 성능과 같은 서버 자체의 처리 능력이 점차 증가해서 한 대당 처리하는 능력이 늘어나 서버를 통합해 줄이기도 합니다. 800여 대에서 1천 대 사이에서 증가와 감소를 반복합니다. 또한 신년에는 예상치 못한 상황에 대응하기 위해 VM(virtual machine)과 PM(physical machine)을 포함해 약 100여 대를 대기 장비로 할당해 서버 자원 문제에 대응할 수 있도록 준비합니다. 이런 대기 장비는 신년 대응이 끝나면 다른 곳에서 사용할 수 있도록 Verda에 반납합니다.

네트워크 대역폭 관리

글로벌 트래픽 경로 설정

네트워크는 IT 인프라의 기반이라고 할 수 있습니다. 잘 동작할 때는 아무도 신경 쓰지 않지만 한 번 이슈가 발생하면 대규모 장애의 원인이 되기도 합니다. 글로벌 네트워크를 담당했던 지인이 해도 욕, 안 해도 욕이라며 푸념하던 기억이 납니다. 뭔가 문제가 생기면 많은 의심(?)을 받기 때문에 그런 문의에 대응하다 보면 진이 빠지기도 할 테고, 비용이 높아서 절감하려고 대역폭을 줄이려면 걱정되는 일이 한두 가지가 아닐 것이므로 힘들만하다고 생각했습니다. LINE에서는 제가 직접 네트워크 부문 업무를 담당하지 않기 때문에 잘 알지는 못하지만 비슷한 어려움이 있지 않을까 생각해 봅니다. 많은 경우에서 네트워크에 문제가 발생하면 아주 빠르게 대규모 문제가 발생합니다. 담당자끼리 대화를 나누면서 무슨 문제인지 찾을 여유가 있을 정도라면 대부분 네트워크 문제가 아니었다는 것이 제 경험입니다.

LINE의 네트워크는 신년 대응뿐 아니라 평소에도 지속적으로 트래픽에 대응하는 작업을 진행합니다. 서비스 단위 수준의 이벤트나 이슈가 아니라 전체 서비스의 대역폭을 관리해야 하므로 신년 대응을 위해 무엇을 한다기보다는 년 단위 계획을 잘 세워야 합니다. 이때 고려해야 할 점은 네트워크를 증설하는 것이 생각보다 빠르게 진행할 수 있는 일이 아니라는 점입니다. 이미 네트워크 사업자와 계약해서 대역폭을 직접 제어하고 있다면 가능할 수 있겠지만, 그게 아니라면 계약한 대역폭을 넘어가는 부하에 대응한다는 것은 사실 어렵다고 볼 수 있습니다. 그렇기 때문에 미리 충분한 대역폭을 확보하기 위해 노력하지만, 연초 짧은 기간 동안의 증가에 대응하기 위해 고가의 네트워크 사용 비용을 지속적으로 지불하는 것은 어려운 일인데요. 이런 경우에 네트워크의 경로 설정(routing)을 변경하는 작업으로 대응할 수 있습니다. 예를 들어 기존에는 사용자 국가에서 직접 서버로 트래픽을 보내고 있었다면, 일부를 다른 경로로 우회시켜서 하나의 네트워크 회선에 몰리는 트래픽을 분산해 단기적인 부하 문제를 회피할 수 있는 것이지요. 비단 글로벌 네트워크에 국한된 방법은 아닙니다. 국내 망에서도 특정 망에 트래픽이 몰리지 않도록 적용할 수 있는 방법입니다.

전진 배치와 캐시

LINE 초창기에는 일본 IDC(Internet Data Center)에 배치된 서버들로 운영되었으나 서비스가 동남아시아와 북미, 유럽으로 확장되면서 서비스 분산, 이미지 등의 정적인 콘텐츠를 사용자에게 전달하기 위한 지연시간이 이슈가 되었고, 라스트 마일(last mile)이라고 부르는 사용자 서비스 최종 단계의 품질(간단하게 서비스 속도)을 보장하기 위해 프런트엔드 서버(민감 정보가 없는 일반 콘텐츠 서비스)의 경우 세계 여러 국가의 IDC에 전진 배치했습니다. 또한 대륙 간에 데이터를 이동하는 경우 사용자 체감 속도에 영향을 주므로 CDN(Content Delivery Network)이라는 지역 네트워크 캐시 서비스를 적용해 라스트 마일을 개선하기 위해 노력하고 있습니다. 이번 신년 대응 시에도 CDN의 이모지나 스티커의 캐시 기간을 조정하거나(평소보다 캐시 기간을 축소해 단발성 데이터가 캐시를 과다 점유하는 것을 방지), CDN 회사(Akamai, CloudFront 등)의 캐싱을 추가(추가적인 캐시)하고, 사용자 편의를 위해 제공하던 메신저의 백그라운드 전송 기능을 일시 정지하는 등의 여러 작업을 진행했습니다.

측정 가능하고 장기적인 지표 관리

부하에 대응하기 위해서 서버를 증설해야 한다면 어떤 기준으로 서버를 늘려야 할까요? 생각만으로 CPU와 메모리의 양을 정하거나 서버를 늘릴 수는 없습니다. 결국 전부 비용이고 비용을 사용하기 위해서는 근거가 필요합니다. 이때 가장 좋은 참고 자료는 과거에 누적해 놓은 데이터입니다. 단순하게 예를 들어 작년에 한 대의 웹 서버에 최대 100명의 사용자가 동시에 접속했다면, 이 숫자를 최대 몇 명까지 처리할 수 있도록 서버 수를 늘릴 것인가의 기준으로 사용할 수 있습니다. 만약 이런 수치가 없다면 BMT(benchmark test)라는 작업을 수행합니다. 서버에 가상 또는 실제 부하를 요청해서 최대 처리할 수 있는 수치를 산출해 보는 것이지요. 이 수치 역시 서버 수량을 계산하는 기준값으로 사용할 수 있습니다. 또한 우리 회사가 10년간 매해 신년이나 이벤트 때 최대 사용자 수를 잘 정리해 놓았다면, 그래프를 그려서 매해 몇 %나 증가했는지 비율을 알아낼 수도 있습니다. 그렇다면 앞서 판단한 하나의 서버에서 처리할 수 있는 사용자와 올해 증가될 비율을 조합해서 최종 서버 수량을 계산해 낼 수 있을 것입니다. 설명하기 위해 단순한 예를 들었기 때문에 잘 맞지 않을 수도 있지만, 대부분 4칙연산과 이동 평균 또는 추이 정도로 예측하는 것이 사실입니다. 그리고 놀랍게도 이런 추정이 대부분 잘 맞는 편입니다. 이때 사용한 숫자들과 산정한 값들을 우리는 '지표'라고 부릅니다.

좀 딱딱한 이야기지만, 지표는 거시적인 추이 변동을 예측하기 위한 수치적 근거를 의미합니다. 만약 매번 변경되거나 장기적 관점에서 적합하지 않은 항목을 지표로 삼는다면 매해 시스템의 자원을 산정할 때 어려움을 겪게 됩니다. 기업의 구성원은 각자의 업무에 따라 각기 다른 수치를 지표로 삼을 수 있습니다. OS를 관리하는 엔지니어의 경우에는 CPU 사용량을 지표로 관리할 수 있고, 프로그램 개발자의 경우에는 기능의 동작 건수를, 경영진이나 기획, 마케팅의 경우에는 좀 더 추상적인 수치인 한 달간 접속한 사용자 수나 활성화 상태의 사용자 수를 지표로 삼을 수 있습니다. 비즈니스 관점의 지표인 월간 활성 사용자(monthly activity user, MAU)는 사업의 방향이나 전략을 수립하는 데 사용할 수 있고, 좀 더 낮은 수준의 데이터인 초당 처리량(transaction per second, tps)이나 대역폭 사용량(bit per second, bps) 등은 장비 수량을 산정하거나 네트워크 대역폭을 증설하기 위한 근거로 사용할 수 있습니다. LINE의 개발자들은 이런 지표를 관리하기 위해 자체적인 모니터링 시스템(imon)과 여러 가시화 도구들(Grafana, Kibana 등)을 사용하며, Hive에 누적된 대량의 운영 로그를 분석하고 지표를 추출해서 매해 리뷰 미팅에서 공유하고 정보를 남기고 있습니다. 이런 정보는 내년에, 또 그 이후에도 지속적으로 참조할 수 있는 중요한 지표가 됩니다. 

동료들과의 커뮤니케이션 도구

COVID-19 상황이 심각해지면서 LINE의 원격 근무는 3년 차를 맞이하고 있습니다. 초기에는 일주일에 몇 회 정도 출근했지만 지금은 사무실에서 제 책상이 사라졌습니다(와이프가 잘린 거냐고... 😂 ). 모바일 오피스로 새로 단장한 사무실은 출근해서 내 자리를 지정한 뒤 사용하면 됩니다. 그다지 불편하다고 생각되는 부분은 없습니다. 오히려 작은 골방(?) 스타일의 포커스 룸에서는 집중해서 업무를 할 수 있고 온라인 미팅할 때도 좋은 것 같습니다. 이렇게 아무 때나 출근하기도, 아무 때나 원격으로 근무를 하기도 하다 보니 걱정되는 부분은 신년 대응 때 100여 명의 사람들이 어떻게 서로 의견을 전달할 것인가 였습니다. 다행히도 LINE은 메신저 회사이고, LINE 메신저나 LINE WORKS 등을 이용해 일하는 것이 익숙한 환경이었기에 원격 근무를 시작한 후에도 큰 부침 없이 적응한 것 같습니다. 다만 비대면 문자 교환만으로는 부족한 부분들이 있었기에 이후 몇몇 도구들을 추가로 사용하기 시작했습니다. 신년 대응은 아래 열거한 커뮤니케이션 도구를 사용해 문제없이 진행할 수 있었습니다. 

LINE

첫 번째는 LINE의 메신저인 LINE입니다. LINE 직원이 카카오톡으로 서로 연락하는 건 좀 이상하죠? 네. 그렇습니다. 우리는 LINE을 사용합니다. 그런데 한 번은 이런 일이 있었습니다. 업무 중에 갑자기 아무도 내 말에 대답을 하지 않는 겁니다. '뭐지?'하는 생각에 계속 메시지를 보내는데 갑자기 빨간색 아이콘이 나타나면서 재전송 버튼이 보입니다. 순간 '망했다...'라는 생각이 스쳤습니다. 다른 협업 도구인 LINE WORKS를 보니 아이콘 배지에 숫자가 잔뜩 떠 있었습니다. 그렇습니다. LINE에 장애가 발생하면 우리는 LINE으로 대화할 수 없습니다. 그래서 역설적으로 신년 대응에서는 LINE 메신저를 공식 대화 채널로 사용하지 않습니다. 그 대안으로 선택한 것이 Slack입니다.

Slack

앞서 말씀드린 딜레마 때문에 LINE 메신저 서비스와 상관없이 사용할 수 있는 도구로 Slack 엔터프라이즈를 주요 커뮤니케이션 도구로 사용하기 시작했습니다. 메신저와 비교할 때 기록을 남기기 쉽고 검색과 내용 관리가 가능해서 LINE 메신저에 있던 많은 업무 채널이 Slack으로 이전했습니다. LINE 메신저는 개인적으로 사용하기도 하기 때문에 사적 영역이 업무와 섞이는 문제를 방지하기 위해 LINE이 아닌 다른 도구를 사용하게 된 것도 어느 정도 이유가 됐을 텐데요. 수년간 LINE 메신저로 업무를 진행한 입장에서 처음에는 Slack이 낯설기도 했습니다. 지금은 적당한 선에서 주요 업무 채널은 Slack에서, 간단한 업무 관련 이야기들은 LINE 메신저를 사용하는 추세입니다. 올해에도 신년 대응을 위한 Slack 채널에 관련 사용자들이 모였고, 공지 사항과 공유해야 할 내용을 전파할 때 잘 사용했습니다.

Zoom

신년 대응을 위한 미팅을 해야 하는데 이전에는 회사의 대형 화상 회의실에 모두 모여서 미팅을 진행했지만 이제는 그런 환경에서 모일 수가 없게 됐습니다. 그래서 도입한 도구가 Zoom입니다. 엔터프라이즈 계정으로 500명까지 모여 회의할 수 있고 통역 시스템과 소회의실 구성 기능 등을 갖추고 있어서 어떻게 보면 좁은 공간에 다닥다닥 모여서 진행하던 기존 회의보다 좀 더 쾌적하게 미팅을 진행할 수 있었습니다. 처음에는 좀 어색했지만 앞서 말씀드렸듯 3년쯤 되니 Zoom을 사용하는 것이 별로 번거롭지 않고 말 꺼내기 쉽지 않은 그런 느낌도 없습니다. 그냥 메신저로 타이핑하다가 '쭘 합시다!'하고 자연스럽게 넘어갑니다

Trello

올해 처음 사용해 본 도구입니다. 신년 대응 시 80여 개의 가까운 작업을 진행하는데 그걸 하나의 채널에서 이야기하자니 한눈에 내용을 파악하기가 어려웠고, 실제로 누락되는 경우도 있었습니다. Zoom 역시 하나의 방에서 다른 주제를 가진 여러 명이 이야기하면 화상 미팅의 장점이 많이 퇴색됩니다. 그래서 프로젝트에서 작업 단위(task)별로 담당자를 지정하고 시간 추적이 가능한 도구를 찾던 중 회사에서 이미 도입해 놓은 Trello라는 도구를 발견했습니다. 칸반보드(Kanban board) 형태의 협업 도구인데요. 단순하게 말해서 포스트잇에 필요한 작업을 적어서 담당자 이름을 적어 놓은 다음, 해결되면 하나씩 떼어내서 보드를 다 비우면 작업이 끝나는... 그런 도구입니다. 여러 가지 유사한 도구가 있었지만 제가 Trello를 사용한 두 가지 이유는 시간 추적이 가능했고(시작과 만료 시간 지정이 가능하고 담당자에게 알림을 줍니다), 두 번째로 자동화 기능을 지원해 작업을 진행할 때 시간이나 작업 완료 여부에 따라 자동으로 작업을 이동시키고 정리할 수 있었습니다. 실제 적용해 본 결과 Slack 채널에 자꾸 포스팅할 필요가 없어졌고 각 담당자가 명시적으로 지정되면서 작업 프로세스가 단순화돼 전체적으로 매끄럽게 진행할 수 있었습니다. 오히려 사람들이 자신에게 할당된 작업만 조용히 진행하니 삭막하다는 농담이 나오기도 했습니다. 별다른 이슈가 없었기 때문에 다음 신년 대응을 진행할 때도 Trello를 사용하려고 생각하고 있습니다. 추가로 개선할 부분이 있다면 담당자 지정을 좀 더 세분화해서 할당하면 한 명에게 쏠리는 작업량을 분산할 수 있지 않을까 생각하고 있습니다.

LINE WORKS(네이버웍스)

기업이나 단체의 협업을 돕기 위한 도구로 일본에서는 LINE WORKS, 한국에서는 네이버웍스로 서비스하고 있습니다. 한국 LINE에서도 LINE WORKS를 사용하는데요. 임직원을 찾고 일정을 관리하는 등의 용도로 자주 사용하고 있지만 처음 말씀드렸던 LINE 메신저와 같은 이유로 메인으로 사용하지는 않습니다. 

Wiki와 Jira

이슈나 작업의 티켓을 관리하기 위해 Jira를, 기술 정보 리포트나 각종 기획 문서를 공동으로 작업하고 저장하기 위해 Wiki를 사용하고 있습니다. LINE 초기부터 진행했던 신년 대응 정보와 지표들 그리고 연관된 티켓 정보들이 저장돼 있어서 이를 참고해 올해 계획에 반영하는 데 사용했습니다. 또한 올해 신년 대응을 위한 준비 과정과 내용, 리뷰 결과를 모든 서비스 담당자분들이 잘 정리해 주셨습니다.  

마음 관리

LINE은 COVID-19 이후 일부 원격 근무에서 완전 원격 근무 형태로 변해가고 있습니다(앞으로 어떻게 될지는 모르겠습니다). 매일 출근하고 계신 분이라면 배부른 소리라고 하실지도 모르겠습니다만... 원격 근무가 길어지면서 가끔 '외롭다? 심심하다?'라는 생각이 들기도 합니다. 끙끙거리고 코드를 짜서 잘 실행되면 '앗싸!'하는 기분에 옆 동료와 이야기하거나 가끔 식곤증이 올 때면 같이 차 한잔하며 보내던 시간이 오프라인 근무만 할 때는 미처 깨닫지 못했던 즐거움 중 하나였다고 생각합니다. 원격 근무로 전환된 뒤 새로 동료가 입사를 했는데... 면접과 오리엔테이션 모두 원격으로 진행되고 LINE으로 첫 출근하시던 날도 메신저로 '환영합니다~~~'라는 글을 쓰면서 '아... 이래도 되는 걸까...'하는 생각도 해보았습니다. 물론 팀에서 Zoom으로 수다도 떨어봤고 몇 개월이 지난 지금 새로 오신 분도 팀원들 대부분을 직접 한 번씩(?)은 만날 수 있었지만, 미안하게도 환영한다고 밥 한 끼 같이 못 먹는 매정한 시절을 지내고 있습니다. 

회사 차원의 노력, 올해도 무사히 이벤트

오프라인 시절에는 새해에 간식거리와 도시락 등이 회사로 배달됐습니다. 하지만 요즘에는 대부분의 직원이 원격 근무를 하고 있기 때문에 작년에는 회사에서 신년 대응에 참여하는 분들에게 간식을 보내주었고, 올해도 인사 팀에서 이벤트를 진행해 주신다고 해 참석자 명단을 전달드렸습니다. 며칠 후 배달 주문 쿠폰이 휴대폰으로 전송됐고(고맙습니다. 저녁에 야식 먹으라는 거죠? 야식은 살 안 찌죠... 내가 쪄요...) 회사에서 보낸 상자도 도착했습니다. 쿠키와 커피, 마늘과 도라지즙, 양말이 들어 있었습니다. 먼저 받으신 분들이 사진을 올리자 '아... 나는 언제 오나...',  '쿠키는 애들이 다 먹어버렸...', '이거 드립백 어떻게 먹는겁니꽈?', '쿠키 하나 먹으면 밥 한 공기 될 것 같은데...' 등의 드립이 올라옵니다. 엄청난 선물은 아니지만 이렇게 고생하는 사람들을 챙기고 있다는 뉘앙스를 주는 것이 중요한 게 아닌가 하는 생각을 해보았습니다.

동료들과의 비대면 대화는 오해가 없도록

커뮤니케이션과 관련해서 이번에 두 가지 생각을 해봤습니다. 첫 번째는 오해가 발생하지 않도록 '짧은 문장으로 이야기하고 설명과 문서는 자세하게'였습니다. 안 그래도 삭막한데 다크 테마를 적용한 시커먼 Slack에서 너무 길게, 또 자주 무엇인가 해달라고 요청하면 혹시나 좋지 않게 보여도 설명할 길이 없을 것 같았습니다. 그래서 Wiki에 나름 공들여 정리하고 해당 내용을 짧게 공유드렸습니다. 또한 업데이트되는 내용과 관련된 문의 사항은 DM으로 문의하면서 '나는 당신 편이에요'라는 시그널을 보내기 위해 노력했습니다. 안 그래도 바쁜데 자꾸 의미 없어 보이는 문서나 업데이트하라고 독촉하는 느낌이 들지 않도록 나름 노력했습니다만, 받아들이는 입장에서 어땠을지는 알 수가 없지요. :) 그저 열심히 해 볼 뿐입니다.

두 번째로 말을 걸 때 인사와 함께 짧게라도 내가 연락한 이유를 같이 적어서 메시지를 보냈습니다. 대부분의 업무가 비대면 메시지로 진행되는데 '안녕하세요?'하고 다음 글이 오지 않으면 숨이 넘어갈 것 같았습니다. 그래서 한 메시지에 내용을 다 담아서 보내고 나중에 보더라도 바로 용건을 확인하고 대답할 수 있도록 내용을 보내려고 노력했습니다. 다행히 LINE에서 일하면서 이런 이유로 뭐라고 하는 분은 한 명도 없으셨습니다. 갑자기 근무 환경이 바뀌다 보니 이것저것 혼자 고민하는 상황이 종종 있었고, 나름의 방법으로 대응하고 있다고 말씀드려 봅니다.

원격 근무 3년 차, 여기가 집인지 회사인지

2021년 12월 31일 23시 59분(GMT+9). '자, 잘 넘어가 보자'하고 생각하며 모니터를 보니 잔뜩 띄워 둔 그래프는 아직 숨 고르기 중이었습니다. Trello의 작업 카드들은 열심히 처리되다가 결전의 순간이 다가오자 잠잠해졌습니다.

같이 고생하신 동료들의 책상

00시 00분. 그래프들이 꿈틀거리기 시작하던 그때! '새해다~! 와~ 종 친다~ 5학년이다~'하고 와이프와 둘째가 신이 나서 소리를 칩니다. 나에게 와서 '새해 복 많이 받아~'하고 인사하는데 급하게 Zoom 마이크를 끄고 '어...'. 이어폰으로는 Zoom 채팅방에서 오가는 인사가 들립니다. '아... 이 느낌 낯설다...' :) 다행히도 치솟는 요청량 그래프에 비해서 애플리케이션 서버의 처리 그래프는 깔끔하게 그려지고 있었습니다. 

새해 부하를 잘 버텨낼 것인가는 1~2분 내로 결판납니다. 위 그래프는 메시징 서비스의 프런트엔드 상태를 보여줍니다. 각 담당자들이 다양한 백엔드 시스템을 모니터링하고 있으며 그중 하나의 서비스에서라도 지연이 발생한다면 프런트엔드는 같이 지연됩니다. 다행히 잘 버텨냈고 별 이상 없이 안정화 상태로 접어들었습니다. 이어서 그다음 새해인 대만(GMT+8)을 지나고 태국(GMT+7)을 지났습니다. 서로 수고하셨다는 인사를 주고받으며 신년 맞이를 마무리하고 나니 시계는 03시 40분을 가리켰습니다. 중간중간 TV를 보고 있던 둘째와 와이프를 봤는데 나가보니 언제 잠들었는지 둘 다 꿈나라입니다. 둘째에게 뽀뽀해 주고 새해 복 많이 받으라는 인사도 하고 나니 다 끝났다 싶기는 한데, 커피를 너무 마신 것인지 정신은 멀쩡합니다. 이것저것 신경 쓰다 보니 세 시간이 훌쩍 지났습니다. 다른 해보다 더 정신없었습니다. 이전에 공대장 맡으셨던 분들이 존경스럽기도 하고, 이런저런 온갖 잡생각이 들어 누워도 잠이 오지 않습니다. 차라리 회사에서 밤샘 작업을 했다면 집에 올 때쯤이면 바로 쓰러져 잠들었을 것 같은데 잠드는 시간까지 여기가 집인지 회사인지 비몽사몽이었습니다. 그러다 어느 순간 저도 잠이 들었습니다. 

내년에는

커뮤니케이션 개선

Zoom

소회의실 활용

작년에도 주제나 부서가 다른 인원들이 하나의 방(Zoom 회의실)에 모였을 때 대화가 섞이는 이슈가 있었다는 의견이 있었음에도 제가 회의실을 만들 때 소회의실 기능을 활성화하지 않는 실수를 했습니다. Zoom에는 하나의 회의실에서 소회의실을 생성할 수 있는 기능이 있습니다. 이 기능을 사용하기 위해서는 Zoom 클라이언트가 아니라 웹에서 개인 프로파일로 들어가 기능을 활성화해야 합니다. 다음 신년 대응 Zoom 미팅을 준비할 때는 미리 방을 생성하고 소회의실을 분리해서 필요에 따라 회의실을 자유롭게 이동할 수 있도록 준비할 예정입니다.

별도 마이크 사용하기

이 부분은 평소에도 느꼈던 부분이라 이미 마이크를 별도로 구매해 사용하고 있었습니다. 마이크 달린 이어폰은 움직일 때 부스럭거리는 소리가 들리는 경우가 많고, 노트북 마이크는 거의 무지향성이라서 잡음과 하울링(스피커 소리가 마이크로 들어가서 울리는)이 심한 편입니다. 원격 근무를 자주 하시는 분이라면 비싸지 않더라도(3만원 미만) 지향성 마이크를 준비해서 사용하시면 서로 이야기할 때 도움이 됩니다. 

Trello

Trello는 올해 처음 적용해 본 프로젝트 관리 도구였는데 괜찮았다는 피드백을 받았습니다. 개인적으로도 사용이 어렵지 않고 작업 진행 사항을 직관적으로 살필 수 있어 좋았습니다. 다만 세부 작업할 때 Checklist 항목에서 사용자 지정이 명확하지 않았던 부분이 있었던 터라 다음에는 최초 담당자 조사 시에 실제 수행할 인원을 확인하고 명확하게 지정하려고 합니다.

올해 발생한 이슈들은 잘 정리해서 내년에 반영

올해 아무 이슈가 없었던 것은 아닙니다. 이 글을 쓰는 현재에도 발생한 이슈에 대한 리포트가 작성돼 공유되고 있고 앞으로 어떻게 진행할지 논의하고 있는 것으로 알고 있습니다. 다음 신년 대응을 준비할 때는 각 이슈 상태를 확인하고 반영할 수 있도록 준비할 예정입니다. 

마치며

올해 처음 경험한 LINE 신년 대응 경험을 이렇게 글로 적어 보았습니다. 신년 대응은 매년 있었던 터라 저보다 앞서 신년 대응을 담당했던 동료분들의 글과 영상이 있어서 이곳에 링크를 남겨봅니다. 

• LINE 메시징 서버가 새해 트래픽을 대비하는 과정(LINE Engineering 블로그)
• 새해 0시, 라인이 대규모 트래픽을 처리하는 방법 | 라인개발실록(YouTube)
• 대규모 트래픽 애플리케이션 성능 튜닝 노하우 다 알려 드림 | 라인개발실록(YouTube)

기술 블로그에 좀 덜 기술적인 내용을 적었지만 LINE에서 서비스를 지탱하기 위해 어떤 부분에서 어떤 사람들이 어떻게 노력하고 있는지 알려드리고 싶었습니다. 문과가 아닌 엔지니어가 쓴 글이니 부족하더라도 너른 아량으로 이해해 주실 것을 믿어 의심치 않습니다. :) 긴 글 읽어주셔서 감사합니다.