들어가며

소프트웨어를 개발하고 사용하는 곳이라면 어느 곳이든 장애가 없을 수 없을 것입니다. 사용자가 많고 트래픽 규모가 크고 연관된 서비스가 많은 복잡한 소프트웨어일수록 장애가 여러 포인트에서 발생하기 마련입니다. 이번 글에서는 다양한 서비스를 제공하면서 점점 복잡해지고 있는 소프트웨어의 장애를 LINE에서 어떻게 관리하고 있는지와 개인적으로 인상깊었던 사례를 소개하고자 합니다.

장애를 대하는 방법

개발자가 계속 일을 하는 한 장애는 발생할 수 밖에 없다고 생각합니다. 장애가 발생하지 않는다면, 그건 일을 하지 않고 있다는 뜻일지도 모릅니다. :) 그런데 장애가 발생했을 때 책임을 추궁하는 문화라면, 사람들은 새로운 것을 도입해 보거나 도전적으로 무언가를 시도해 보지 못하게 되고, 그렇게 위축된 상태에서 보수적으로 운영하기 때문에 혁신이 일어나지 못하게 됩니다. LINE에서 일하면서 가장 좋다고 생각하는 것 중 하나가 장애가 발생했을 때 개발 담당자나 운영 담당자를 꾸짖거나 책망하는 것에 초점을 맞추지 않는다는 점인데요. LINE에서는 책임을 추궁하기 보다는 시스템 관점에서 장애에 어떻게 잘 대응할 수 있을까라는 부분에 초점을 맞추고 있습니다.

LINE에서 장애에 대응할 때 초점을 맞추는 것들

• 앞으로 어떻게 하면 같은 장애가 또 발생하지 않게 할까
• 어떻게 하면 더 빨리 감지할까
• 장애가 발생하더라도 그 영향 범위를 최소화하려면 어떻게 해야 할까
• 시스템이 자동으로 복구되게 만들 수 없을까

장애는 인재인 경우도 많은데요. 사람이 실수하더라도 그것을 시스템에서 사전에 방지할 수 있는 방법이나, 새로운 사람이 왔을 때 같은 실수가 반복되는 것을 막을 수 있는 방법에 대해서도 계속 고민하고 있습니다.

그리고 장애를 숨기지 않고 적극적으로 드러내어 공유하고 장애 회고를 통해 서로 도와주는 문화가 형성되어 있는데요. 이 부분도 좋은 점이라고 생각하는 부분입니다. 다른 팀의 시니어 개발자로부터 좋은 아이디어를 얻기도 하고, 아예 직접적인 도움을 받기도 하고, 때로는 획기적인 아이디어를 얻어 장애 해결에 큰 도움을 받기도 합니다. 이에 대해서는 사례를 설명하면서 좀 더 소개하겠습니다. 

장애 처리 프로세스

장애 처리 프로세스는 상황에 따라 조금씩 차이가 있을 수 있지만 LINE 내 모든 서비스에서 기본적으로 사용할 수 있는 가이드를 마련해 놓았는데요. 장애 처리 프로세스는 다음과 같이 크게 5단계로 나눠 볼 수 있습니다. 

장애 탐지

장애는 모니터링 도구의 알람이나 관계 부서 혹은 사용자의 보고를 통해서 탐지하게 됩니다. 보통은 해당 서비스의 개발자나 운영 담당자가 모니터링 알람을 직접 받지만, 특별한 서비스의 경우에는 24시간 감시 팀이 있고 그들이 기본적으로 도구을 사용해 감시하다가 알람이 오면 장애 내용을 서비스 담당자에게 알려주기도 합니다. 장애가 발생하면 LINE 내 서비스 담당자들이 먼저 감지하는 경우가 대다수지만, LINE의 설정 화면 중에서 구석진 곳에 위치한 설정과 같이 사용자가 많이 사용하지 않는 기능이나, 발견하기 힘든 보안 이슈인 경우에는 외부의 보고를 통해서 뒤늦게 발견하는 경우도 있습니다. 

현재 운영하고 있는 장애 모니터링 도구로는 자동으로 메일을 발송해 주는 알람 시스템, 자동으로 메시지를 보내주는 감시 봇, 장애를 발견한 사내 임직원이 이를 알릴 수 있는 슬랙 채널, 외부에서 보고할 수 있도록 온라인에 준비해 놓은 LINE CS form 등이 있습니다. 

장애 전파

장애를 탐지하게 되면 장애가 발생한 원인을 파악함과 동시에 관련된 부서로 장애 내용을 전파합니다. 장애의 범위가 작은 경우에는 관련된 부서에만 전파하지만 장애의 범위가 크면(예를 들어 LINE 메시징 서비스가 불안정하다든지) LINE Works나 Slack 등 별도로 준비된 커뮤니케이션 채널을 통해서 장애 내용을 광범위한 대상에게 공유합니다. 

장애 전파는 장애 해결 못지 않게 상당히 중요합니다. 관련된 부서에서 당황하지 않고 같이 대응할 수 있고, 영향을 받는 회사들이 장애 내용을 전달받아 필요한 대응을 할 수 있기 때문에 항상 강조하고 있습니다. 그러나 실제로 장애에 부딪히면 자체적으로 해결해 보려고 애쓰느라 장애 대응 상황에 대한 전파가 잘 이루어지지 않는 경우가 종종 있습니다. 장애 전파만 잘 이루어져도 장애 해결에 대해 다른 부서의 도움을 받거나, 장애에 영향을 받는 쪽에서 준비된 대응을 실시해 장애의 영향 범위를 줄이는 효과를 얻을 수도 있기 때문에 해결 만큼이나 중요하게 생각해야 합니다.

좀 더 장애가 잘 전파될 수 있도록 개선하는 프로젝트도 있는데요. 예를 들어 봇 프로그램에 명령을 내리면 장애 범위에 따라서 전파될 부서와 커뮤니케이션 채널을 선택해서 적당히 준비된 메시지와 함께 전파해 주거나 장애 관리 웹 사이트에 자동으로 등록해 주는 것과 같은 일을 시도하는 프로젝트입니다.

장애 해결

장애 전파와 동시에 장애가 지속되거나 확산되는 것을 막기 위해 노력합니다. 이때 중요한 것 중에 하나가 장애를 전파하는 사람과 장애를 해결하는 사람이 가능하면 나누어져 있어야 한다는 것인데요. 장애의 원인을 파악하고 분석하는 작업과 장애를 전파하는 작업 모두를 한 사람이 하는 것이 꽤 힘들고 장애 지속 시간을 길어지게 만들기 때문입니다. 위에서도 언급했듯이 장애 전파도 장애 해결 못지않게 중요하기 때문에 이와 같이 가이드하고 있습니다.

다음은 장애를 빨리 해결하기 위해서 많이 사용하는 방법입니다.

• 롤백
  보통 장애가 지속되거나 또는 확산되는 것을 얼른 막기 위해 선택하는 방법이 롤백입니다. 이때 롤백 가능 여부를 빠르게 판단하는 것이 필요한데요. 이게 쉽지 않은 부분입니다. 릴리스된 내용에 데이터 스키마 변경이 포함되어 있는 경우는 롤백이 어렵거나 롤백 시 더 큰 문제를 초래하는 경우도 있을 수 있기 때문입니다. 시니어라고 해도 대규모 프로젝트에서는 모든 릴리스 내용을 파악하고 있기가 쉽지 않기 때문에 판단이 어렵습니다. 이런 경우를 대비해서 만약 롤백이 불가능하다고 생각되는 경우에는 PR(Pull Request)에 다음과 같은 라벨을 붙이도록 가이드하고 있습니다. 

• 서버 재기동
  특별히 배포가 없었는데 순간적으로 유입된 트래픽이 많거나, 코드에 성능 문제가 있어서 서버의 스레드나 네트워크 등의 리소스가 부족해져 동작할 수 없게 된 경우에 주로 사용하는 방법입니다. 임시방편이기 때문에 다시 비슷한 상황에 처하면 문제가 재발할 수 있습니다. 장비를 증설하거나 핫픽스를 준비하는 것이 좋습니다.
• 장비 증설
  트래픽이 예상보다 많이 유입된 경우에 필요한 대응책입니다. 이 방법은 사전에 장비 증설이 쉬운 구조를 만들어 놓지 않으면 안됩니다. 코드나 설정 파일을 수동으로 수정해서 배포해야 증설이 되도록 만들었다면, 증설하다가 다른 장애가 다시 발생하기도 하기 때문입니다. 미리 여분의 장비를 받아놓고 바로 투입 가능한 상태로 유지하면서, 증설이 필요한 경우 드래그 앤드 드롭 등의 간편한 방법으로 증설이 되도록 만들어 두는 것이 좋습니다. 최근에는 클라우드 서비스에서 제공하는 오토스케일링 기능을 사용하면 쉽게 자동 대응이 되기도 합니다. 
• 핫픽스 배포
  롤백이나 재기동으로 해결하기 쉽지 않아 문제를 수정한 버전을 배포하는 방법입니다. 롤백과 재기동이 쉽지 않은 클라이언트에서 문제가 발생했을 때 많이 사용하는 방법이며, 서버의 경우에도 롤백이 어렵다고 판단되거나 일시적인 장애라서 롤백까지는 필요 없는 경우에 이 방법을 사용합니다.

장애 대응을 하면서 매우 중요하다고 느꼈던 점 중 하나는 웹서비스가 아니라 Android나 iOS 앱과 같은 네이티브 앱을 개발할 때는 가능하면 서버에서 제어할 수 있도록 만드는 것이 좋다는 점입니다. 네이티브 앱은 배포하는 데에 상대적으로 시간이 오래 걸리기 때문에(특히 iOS는 리뷰를 거쳐야 배포가 가능하기 때문에) 문제가 되는 기능을 켜거나 끌 수 있도록 준비해두면 장애에 빨리 대응할 수 있습니다.

장애 보고

장애 대응이 어느 정도 완료되면 위키 페이지를 통해 제공하고 있는 장애 보고서 템플릿을 이용해서 장애 보고서를 작성합니다. 장애 보고서 작성을 위한 가이드 동영상도 제공하고 있어서 처음 해보는 사람도 쉽게 보고서를 생성할 수 있고, 그 동안 많은 장애 보고서 예제가 쌓여왔기 때문에 그것들을 참고하면 기본적인 내용은 쉽게 채워 넣을 수 있습니다. 

장애 보고서 템플릿의 내용은 대략 다음과 같습니다.

• 요약: 장애 상황에 대해 간략히 설명한다.
• 장애 탐지 시간: 장애가 최초 탐지된 시간을 명시한다.
• 영향받은 서비스: 장애에 영향받은 서비스를 명시한다.
• 장애 원인: 장애가 발생한 원인을 설명한다.
• 타임라인과 해결 과정: 장애가 최초 발생한 시점부터 주요 진행 과정을 순서대로 설명한다. 어떻게 대응했는지 자세한 설명을 덧붙인다.
• 해결 과정과 예방책: 장애를 어떻게 해결했는지, 어떤 예방 조치를 취해야 하는지 자세하게 설명한다. Jira 티켓 정보도 포함한다.
• 관련 문서 및 추가 정보(선택 사항): 필요하면 기타 정보를 추가한다.

장애 보고서를 작성하고 나면 1차로 이메일 공유를 합니다. 1차 이메일 발송은 가능하면 장애가 발생한 당일에 발송하는 것을 원칙으로 하고 있으며, 이때 공유해야 하는 부서는 서비스마다 다를 수 있습니다. 장애 등급은 크게 5단계로 나누어져 있고, 가이드 문서에 장애 등급에 따라 공유해야 하는 대상이 기술되어 있습니다.

그런데 초기 대응 때 장애 원인과 해결 과정, 예방책은 바로 채워 넣기가 어려울 수 있습니다. 원인을 분석하고 예방책을 만드는 것은 시간이 많이 드는 단계입니다. 때로는 원인 분석에만 몇 주가 걸리기도 하는데요. 사용하고 있는 기술의 깊은(core) 부분까지 유심히 들여다 봐야 되는 경우가 있기 때문입니다. 백엔드의 경우 Java의 GC(Garbage Collector), thread dump, memory heap dump를 깊게 파봐야 할 때도 있고, 프론트엔드는 JavaScript 엔진 코드를, 클라이언트는 Android나 iOS가 제공하는 여러 라이브러리의 코드를 직접 봐야 하는 경우도 있습니다. 이런 내용을 처음부터 파악해서 채워 넣기는 쉽지 않기 때문에, TBD(To Be Determined)로 남겨둔 채로 1차 이메일 공유를 해도 좋습니다. 

장애 회고

장애 처리의 하이라이트라고 할 수 있는 부분입니다. 장애를 돌아보면서 원인 분석 및 향후 대응책을 논의하는 자리를 갖습니다. 보통 두 단계로 진행되는데요. 팀 내부적으로 먼저 회고하는 자리를 갖고 어느 정도 정리된 내용을 토대로 관련된 개발자들이 모여서 다시 한 번 회고를 진행합니다. 예를 들어, 메시징 플랫폼의 백엔드 문제였다고 하면 해당 플랫폼의 백엔드 개발자들이 모여서 회고를 진행합니다. 

• 팀 내 회고: 장애를 발생시킨 직접적인 원인과 근본적인 문제가 무엇인지 파악하고 해결책을 마련합니다. 원인과 근본적인 문제를 파악해서 보고서에 추가할 때에는 단순히 그래프나 발생한 사건들을 나열하지만 말고, 시나리오를 만든다는 느낌으로 작성하는 것이 좋습니다. 즉, 배경이나 히스토리뿐 아니라 원인이 되는 작업을 하게 된 이유부터 시작해서 발생한 일련의 사건들이 어떻게 서로 연결되어 문제를 일으켰는지를 설명하는 것이 필요합니다. 팀 내 회고 후에 개발자 회고를 할 때 장애를 둘러싼 상황에 대해서 잘 모르는 사람들도 있기 때문입니다. 이렇게 조각들을 짜맞추어 시나리오를 완성하는 것이 팀 내 회고를 하는 이유이기도 합니다. 원인을 분석하고 나면 해결책을 마련하는데요. 크게 세 가지로 나누어집니다. 장애가 발생하지 않도록 막는 방법(preventing future outages), 장애 탐지를 개선하는 방법(improving outage detection), 그리고 장애 처리를 개선하는 방법(improving outage handling)입니다. 가능하면, 짧은 기간에 대응 가능한 것과 오랜 기간에 걸쳐서 대응해야 하는 것으로 나누는 것이 좋고, 사람 손이 덜 가는 방향으로 만드는 것이 좋습니다. 어쩔 수 없이 사람 손이 가더라도 실천 가능하면서 명확한 항목이 좋은데요. '코드 리뷰를 더 꼼꼼히 하자'보다는 '코드 리뷰할 때 테스트 케이스가 추가되어 있는지 확인하는 체크리스트를 PR 템플릿에 추가한다'처럼 실천 가능한 액션 아이템이 좋습니다. 
• 개발자 회고: 여러 개발자들이 모여서 장애의 전체 타임라인을 살펴보며 문제를 되돌아 보는 자리입니다. 장애와 밀접하게 관련된 부서뿐만 아니라 관련 없는 부서의 관심 있는 사람들도 모여서 같이 장애의 원인과 해결책에 대해서 논의합니다. 개발 리더는 시간이 된다면 가능하면 참석하도록 가이드하고 있는데요. 시니어 개발자들의 경험에서 나오는 인사이트가 큰 도움이 되기 때문입니다. 회의에서 나오는 코멘트는 바로 자리에서 논의해서 필요한 경우 해결책 액션 아이템으로 등록합니다. 

팀 내 회고나 개발자 회고에서 자주 등장하는 액션 아이템들이 있는데요. 각 카테고리에 따라서 다음과 같은 것들이 항상 등장하는 것 같습니다.

• 장애가 발생하지 않도록 막는 방법
  • 해당 문제를 사전에 체크할 수 있도록 유닛 테스트 또는 통합(integration) 테스트 추가
  • 같은 문제가 발생하지 않도록 장기적으로 구조 개선(예: synchronous한 부분을 asynchronous하게 개선)
  • fast failure를 통해 리소스가 낭비되는 것을 막음(예: 연결(connection)에 실패하면 기다리지 말고 빠르게 실패로 처리)
• 장애 탐지를 개선하는 방법
  • 알람 시스템에 알람 항목 추가(예: request failure count > 1000)
  • 로그 추가
  • 여러 가지 수치를 한 번에 볼 수 있는 대시보드 만들기
• 장애 처리를 개선하는 방법
  • 작업 사전 공유(매번 강조해도 지나치지 않습니다. 사소한 작업이라도 사전에 공유하면 장애 대응이 훨씬 수월합니다.)

장기적으로 개선하는 작업은 종종 비즈니스적인 이유로 우선 순위에서 밀리게 되는데요. 그럴 땐 TF(task force) 팀이나 프로젝트를 만들어서 가시화하여 진행하는 것도 한 방법입니다. 그렇게 하지 않으면 1년 뒤에 유사한 장애가 발생했을 때, 이전에 만들었던 1년 묵은 작업 티켓을 발견하게 될 것입니다. 

인상 깊었던 장애들

담당하고 있는 '채널'이라는 플랫폼에서 발생했던 장애 중에서 인상 깊었던(힘들었거나 배운 점이 많았던) 장애를 소개하겠습니다.

참고로 채널 플랫폼은 LINE의 기능을 외부에 제공하기 위한 중간 다리 역할을 하는 플랫폼입니다. LINE과 연동하려고 하는 서비스에 제공하는 계정을 채널이라고 부르고, 연동하는 서비스 하나당 하나의 채널이 부여됩니다. 

네이티브에 제공하던 '전체 동기화(full sync) API' 때문에 발생한 장애

처음에는 LINE에 연동하는 서비스가 많지 않았고, 빨리 개발하기 위해서 LINE 클라이언트에서 모든 '채널' 정보를 한 번에 다 내려받았습니다. 그래도 처음부터 미래에 대한 대비를 어느 정도 해서 LINE 앱을 설치할 때 맨 처음에만 전체 데이터를 받고, 그 다음부터는 업데이트가 발생한 정보들만 받도록 만들었습니다. 어느 정도 점진적(incremental)으로 업데이트할 수 있도록 만들기는 한 거죠.

• 문제가 있는 방식

처음에는 정보가 몇 백 개 수준이었으나, 2015년에 LINE 로그인을 오픈하고 2016년에 봇 플랫폼을 오픈하면서 그 수가 수만 개에 달하게 되었는데요. 정보 하나하나의 크기는 크지 않았지만 수만 개가 되다보니 몇 메가에 달하는 데이터가 되었습니다. LINE 앱을 최초로 설치할 때 한 번에 다 내려받는 API가 호출되는데요. 클라이언트에도 그렇지만 서버에도 매우 큰 부담이었습니다. 몇 메가를 보내야 하는 요청은 당연히 서버 자원을 많이 사용할 수 밖에 없는데 수많은 사용자들이 호출하니 더 부담될 수 밖에 없었습니다. LINE 앱을 새로 설치하는 횟수 자체는 평소에는 그렇게 많지 않았지만, 가끔씩 데이터 스키마가 바뀌면서 전체 클라이언트에서 전체 정보를 업데이트해야 하는 경우도 발생했는데요. 그럴 때마다 서버 과부하가 발생했고, 때로는 네트워크 대역폭이 꽉 차는 경우도 있었습니다. 처음에는 전달되는 정보를 어떻게든 줄여 보려고 노력했는데요. 처음에는 큰 도움이 되었지만 점점 더 레코드 수가 늘어나면서 한계가 보이기 시작했고, 구조 자체의 변경이 시급해졌습니다. 그래서 클라이언트가 전체 데이터를 가져가지 않고, 필요한 데이터만 필요한 순간에 가져가는 방향으로 수정을 시도했습니다.

• 개선된 방식

새로운 방식은 매우 잘 동작해서 문제를 해결한 것처럼 보였습니다만, 네이티브 앱 개발에서 언제나 맞닥뜨리는 하위 버전 호환 문제가 남아 있었습니다. LINE은 무조건 최신 버전으로 업데이트하도록 강제하지 않는 정책을 가지고 있기 때문에, 기존의 문제 있는 API는 한동안 계속 사용될 수 밖에 없었으며, 계속 저희를 괴롭혔습니다. LINE 앱의 특정 버전 이하에 대한 강제 업데이트가 실시되기 전까지는요.

이 이슈는 오랫동안 저희 팀을 괴롭혔는데요. 같은 문제 때문에 여러 번 장애가 발생하기도 했습니다. 그래도 장애 회고를 통해서 가능한 한 영향이 적도록 장애를 고립시키거나, 데이터를 어떻게든 줄여서 서버의 성능을 개선시켜 장애 빈도를 낮추는 등의 여러 가지 아이디어를 얻어서 큰 도움이 되었습니다. 서버의 성능을 개선시키는 일은 시스템 엔지니어링 팀과의 협업을 통해서 진행했던 기억도 납니다. 때마침 G1GC(Garbage First Garbage Collector)를 도입하면서 메모리를 많이 사용하고 GC를 빈번히 발생시키는 이슈도 해결했습니다. 여러 가지 아이디어가 개발자 회고 과정에서 도출됐고, 역시 다같이 고민하면 더 좋은 아이디어를 얻을 수 있다는 사실을 확인했습니다. 이 장애를 통해서 개인적으로 얻었던 교훈은 '네이티브 앱 개발 시 전체 동기화 API 사용은 신중하게 생각하라'였습니다. 잘못하면 자신이 만든 앱이 스스로를 DDoS(Distributed Denial of Service)로 공격하는 형국이 되기도 하기 때문입니다. 

'friends matrix' 데이터의 잦은 업데이트로 발생한 장애

채널 플랫폼에서는 사용자별-채널별 친구 목록을 제공하고 있는데요. 이는 나와 같은 서비스를 사용하고 있는 친구들의 목록으로 'friends matrix'라고도 부릅니다. 예를 들어, LINE 친구 중에서 LINE Rangers를 같이 플레이하는 사용자 목록이 이에 해당합니다. 

이 데이터는 HBase에 저장하고 있었는데요. 저장해야 하는 데이터를 간단하게 표기하면 (사용자, 친구 아이디, 채널 아이디)와 같은 데이터 쌍이 됩니다. LINE 사용자 10억 명 X 평균 친구 수 10명 X 평균 사용하는 채널 수 10개라고만 생각해도 저장해야 하는 데이터 쌍이 1000억 개가 됩니다. 상당히 많은 데이터입니다. 그러나 사실 더 중요한 부분은 데이터 갱신입니다. LINE에서 친구 추가와 삭제는 상당히 자주 발생하는데요. 그와 더불어 만약 내가 LINE Rangers를 새로 설치했다면, 나를 친구로 설정한 사용자들의 데이터까지 모두 업데이트해야 합니다. HBase에 분산해서 저장했지만, 이를 위한 업데이트가 상당히 자주 발생해서 HBase 쓰기 작업의 성능 저하가 심해져 장애가 발생하곤 했습니다.

이 문제도 상당히 오랫동안 저희 팀을 괴롭혔는데요. 여러 번의 장애 회고를 통해서 많은 분의 도움을 받았던 기억이 납니다. 계속해서 HBase를 튜닝했고, 데이터 압축(compression)과 재분산 작업을 진행했으며, 성능이 더 좋은 HBase 상위 버전으로 마이그레이션까지 진행했던 기억이 납니다. 또한 데이터 갱신이 다소 늦어지더라도 쓰기 작업이 한꺼번에 몰려오는 것을 막기 위해 트래픽을 제어하기도 하고, 그 와중에 발생하는 GC 문제를 해결하며, 깨진 데이터를 복구하는 등 관련하여 여러 개선 작업을 진행했습니다. 

그 중 타부서로부터 얻은 가장 혁신적인 아이디어는 'friends matrix 데이터를 미리 계산해서 HBase에 저장하지 말고, 요청이 왔을 때 바로 계산해서 반환해 주자'라는 아이디어였는데요. 과연 그런 식으로 반환하는 게 API 응답 시간을 어느 정도 만족시키면서도 가능할지 당시에는 굉장히 의구심을 가졌습니다만 결국 이 방법으로 해결된다는 것이 증명되었고, 최종적으로는 HBase를 아예 사용하지 않는 방식으로 진행되었습니다. 다시 한 번 이 자리를 빌려 이 아이디어를 내주신 분께 감사의 말씀을 전하고 싶네요. 장애 회고를 통해서 얻은 타부서의 아이디어가 얼마나 도움이 되는지 다시 한 번 느낄 수 있었습니다. 

마치며

LINE에는 우스갯소리로 '병풍친다'라는 말이 있었습니다. 장애가 발생했을 때 담당자의 뒤에 사람들이 우르르 몰려가서 병풍처럼 서서 대응하고 있는 모습을 '병풍친다'고 불렀는데요. 그래서 다들 아래처럼 병풍치게 되는 상황을 두려워했습니다.

최근에는 그런 모습을 많이 보지 못하게 되었는데요. 어느 정도 프로세스가 정립되고 커뮤니케이션 채널이 안정화되면서 굳이 담당자 뒤에 몰려가서 압박을 주지 않아도 되게 되었기 때문이라고 생각합니다. :) 

개인적으로 장애를 통해서 얻는 것이 가장 많다고 생각하는데요. LINE의 장애 대응 문화는 개인의 기술 발전뿐 아니라 회사의 기술 발전에도 큰 도움이 된다고 생각합니다. 앞으로도 장애를 통해서 배우고 발전해 나가는 문화가 지속되길 바라면서 글을 마칩니다.