2년차 서버 개발자가 바라본 LINE의 개발 문화

시작하며

작년 1월에 LINE에 입사했고, 믿기 힘들게도 어느덧 입사한 지 2년이 다 되어 갑니다. 이 글을 쓰며 회사란 참 시간이 빨리 흘러가는 무서운 공간이라는 것을 다시 한 번 느낍니다. 근 2년간 제가 LINE이라는 회사에 다니며 신입 개발자의 시선으로 바라본 회사의 모습과, 또 그 속에서 느낀 점을 자유롭게 적어보았습니다.

 

내가 생각했던 LINE

입사하기 전, ‘LINE’ 하면 가장 먼저 떠올랐던 이미지는 ‘실력이 좋은 개발자들이 많이 모인 IT 회사’였습니다. 제 주변에서도 LINE 개발자라고 하면 다들 개발 잘 하는 개발자라고 생각하고 있었고, 저 또한 글로벌 메신저 앱을 서비스하며 엄청난 트래픽을 감당하고 있는 만큼 높은 기술을 요구하는 회사일 거라고 생각했습니다.

이후 면접을 보러 면접 장소로 이동하면서 회사 내에 자리한 카페를 포함해 잠시나마 오피스 환경을 체험해 볼 수 있었는데요. 인테리어나 직원들의 옷차림, 회의하는 모습을 보며 확실히 제가 생각했던 일반적인 대기업의 이미지보다는 자유로운 분위기의 회사라는 걸 느꼈습니다. 아마도 그때, 처음 회사에 지원했을 때보다 ‘이 회사에서 일해보고 싶다’라는 마음이 더 커졌다고 생각합니다.

그렇지만 물론 입사 전에 회사의 좋은 이미지만 접했던 건 아니었습니다. 인터넷에서 찾은 ‘LINE’에 대한 글 중에는 ‘일이 너무 많다’, ‘신입이 성장하기 힘든 회사다’ 등의 부정적인 리뷰도 간간히 있었습니다. 하지만 그런 부정적인 리뷰가 별로 신경 쓰이지 않을 만큼 이미 회사에 대한 콩깍지(?)가 씐 상태였기 때문에 꼭 합격하기만을 간절히 바랬습니다.

 

LINE의 업무 문화

개발

제가 일하게 된 팀은 LINE 오픈챗(구. LINE 스퀘어) 서비스의 서버 개발 팀이었습니다. Spring Boot로 개발하고 있었고, Kafka, Hbase, Redis, MySQL 등 다양한 스토리지를 사용하여 인프라가 구축되어 있었습니다. 그런데 저는 대학교 수업 때 아주 간단한 Spring Boot 애플리케이션 서버를 만들어서 실행해 본 경험을 제외하고는 Spring Boot로 개발한 경험이 거의 없었습니다. 그런 저에게 Spring Boot란 제가 첫 번째로 마주친 거대한 산이었습니다. 더군다나 대부분의 코드가 RxJava로 작성되어 있었기 때문에 처음에는 하나의 기능에 대한 코드를 보는 것조차 저에게는 큰 어려움으로 다가왔습니다. 그때 당시만 해도 내가 PR(pull request)을 만들어 우리 서버 코드에 기여한다는 것이 아주 먼 미래의 일처럼 느껴졌습니다.

머릿속에는 얼른 성장해서 나도 팀에 기여할 수 있는 팀원이 되고 싶다는 생각뿐이었습니다. 그래서 개인적으로 책을 사서 공부하거나 동기들과 함께 스터디하며 부족한 부분을 하나씩 채워나갔습니다. 또 팀 내의 시니어 개발자가 매일 1시간씩 별도로 마련해 주었던 멘토링 시간은, 개발이나 서비스 도메인과 관련하여 1시간 동안 마음껏 질문하고 배울 수 있었던 유익한 시간이었습니다. 덕분에 팀의 일원으로 더욱 빨리 성장할 수 있지 않았나라는 생각이 듭니다. 이 글을 빌려 다시 한 번 감사하다고 전하고 싶습니다. 

 

배포

현재 제가 속한 팀에선 신입 개발자도 프로덕션 환경의 서버에 직접 배포할 수 있습니다. 이 점은 내가 자칫 실수하면 실제 수많은 사용자가 이용하고 있는 LINE 서비스에 영향을 줄 수도 있다는 부담으로 다가오기도 했고, 또 한편으로는 모든 개발자에게 권한을 준 만큼 회사가 개발자들을 신뢰하고 있다는 느낌이 들어서 좋기도 했습니다. 입사한 지 2년이 다 되어가는 지금도, 서버의 재기동 버튼을 클릭하기 전에는 항상 몇 번씩 확인하곤 합니다. 서버의 운명이 내 손에 달렸다는 것은 여전히 가슴이 떨리는 일입니다.

 

코드 리뷰

코드 리뷰에서도 신입 개발자든 시니어 개발자든 상관없이 자유롭게 서로의 코드에 대해 피드백을 남길 수 있습니다. 어떻게 보면 상대방이 작성한 코드를 지적하는 것이기 때문에 상대방의 기분이 상할 수도 있지 않냐고 생각할 수도 있습니다. 하지만 리뷰어는 어떠한 악의도 없이 순수하게 코드의 품질을 향상시키고자 코드를 평가하고 피드백을 주는 것입니다. 따라서 리뷰를 받는 사람은 리뷰어가 자신이 생각하지 못한 더 나은 구현 방법을 알려주거나 자신의 실수를 찾아주면 오히려 리뷰어에게 큰 감사함을 느끼게 됩니다. 저는 LINE에 코드 리뷰 문화가 잘 정착되어 있다고 생각합니다. 내가 만든 PR에 여러 개발자의 코멘트가 수십 개씩 달릴 때도 있고, 어떤 날은 내 코드를 작성하는 시간보다 동료의 코드를 리뷰하는 데에 더 많은 시간을 할애할 때도 있습니다.

팀 프로세스상 원칙적으로 코드 리뷰를 통과하지 못한 코드는 공통 브랜치에 절대 머지(merge)할 수 없고, 따라서 릴리스도 할 수 없습니다. 이러한 코드 리뷰라는 안전 장치 덕분에, 개발자는 동료를 믿고 더욱 안심하고 코드를 작성할 수 있지 않나 생각합니다. 만약 제 코드에 대한 코드 리뷰가 없었다면, 제 코드가 만들어 낸 버그가 얼마나 많은 사용자를 괴롭혔을지 상상만 해도 아찔합니다.

 

모니터링

서버 개발자 업무의 꽃(?)이라고 할 수 있는 모니터링 역시 팀에서 신경 쓰고 있는 중요한 활동입니다. 효율적인 모니터링을 위해 팀 내에서는 매주 1명씩 돌아가며 ‘온콜(oncall)’이라는 당번을 정하고 있습니다. 온콜은 업무 시간과 업무 시간 후에도 서버를 모니터링하는 임무를 부여받습니다. 그렇다고 하루 종일 그래프만 보고 있을 필요까지는 없습니다. 서비스의 장애를 빠르게 감지할 수 있도록 이미 곳곳에 알람이 설정되어 있어서 그 알람에 주의를 기울이면 됩니다. 일주일 동안 알람이 하나도 안 울린다면 온콜에게는 정말 행복한 일주일이 되겠지만, 보통은 크고 작은 알람들이 몇 번씩 울립니다. 만약 높은 레벨의 알람이 울린다면 온콜은 빠르게 원인을 파악하여 유관 부서에 공유해야 합니다.

사실 학생 때도 프로젝트에 참여하여 개발하고 배포하는 것까지는 흔하게 경험해 볼 수 있지만, 대규모 서비스를 운영하며 모니터링 경험을 쌓는 것은 쉽게 해 볼 수 있는 일이 아닙니다. 저 또한 처음에는 모니터링 업무에 익숙하지 않아서 어떤 장애가 났을 때 어떤 그래프를 봐야 하는지 판단하기 어려웠습니다. 그때마다 시니어 개발자가 그러한 상황에서 어떤 부분을 중점적으로 보는지, 어떤 순서로 원인을 파악하는지를 어깨너머로 계속 관찰하며 배워나갈 수 있었습니다.

 

커뮤니케이션

글로벌 회사이다 보니, 다양한 국가의 여러 외국인 개발자와 함께 협업하게 되는 경우가 자주 발생합니다. 그래서 커밋 내용과 코드 주석, 코드 리뷰, 개발 문서 등을 모두 영어로 작성하고 메신저에서도 영어로 커뮤니케이션합니다. 사실 오픈 소스 활동을 하거나 영어로 개발 문서를 써 본 분들은 아시겠지만 개발에서 쓰이는 영어는 어느 정도 한정적이고, 또 저희 곁에는 항상 ‘Google 번역기’와 ‘papago 번역기’라는 든든한 동반자가 있기 때문에 웬만한 영작은 번역기의 도움으로 쉽게 할 수 있습니다.

문제는 회화인데요. 다행히 대부분의 미팅에 통역사가 함께 참석하고 있습니다. 하지만 그런 통역사가 없는 간단한 미팅에서는 결국 직접 영어로 커뮤니케이션해야 하는데요. 저희 팀원들은 다들 영어 회화에 능통했지만 그와 달리 수능형(?) 영어 공부만 해와서 회화에 약했던 저에게는 영어가 또 하나의 스트레스로 다가왔습니다. 한국말로도 설명하기 힘든 개발 내용을 영어로 설명하고, 또 반대로 영어로 설명을 듣고 이해하는 게 쉽지 않았습니다. 그래도 회사 내에 영어를 사용하는 문화가 있다는 것은 자연스럽게 어학 공부에 대한 동기 부여가 되었고, (아주)미세하게나마 영어 실력이 늘지 않았나 생각합니다. 회사에서 지원해주는 어학 교육비로 영어 학원에 다닌 것도 저의 영어 회화에 큰 도움이 되었습니다.

 

기억나는 사건들

첫 PR

2년이 다 되어가는 지금도 첫 PR을 올렸을 때가 아주 생생하게 기억납니다. 어느 날 팀 리드 님이 저에게 작은 버그 이슈 티켓 하나를 주시면서, 버그의 원인을 찾아 직접 고쳐보라고 하셨습니다. 버그 이슈 티켓에 적힌 내용을 몇 번씩 읽으면서 실제 코드의 어디에서 발생하는 문제인지를 알아내기 위해 코드의 흐름을 열심히 따라갔던 기억이 납니다. 원인을 찾아 버그를 고친 PR을 올렸고, 팀원들의 코드 리뷰 후에 내 PR이 머지되었을 때의 그 감격은 이루 말할 수 없었습니다.

아주 작은 버그이긴 했지만, 내가 작성한 코드를 통해 고쳐졌다는 것이 뿌듯했고, 그때를 계기로 자신감이 많이 생겼습니다.

 

내 작업이 릴리스 노트에!

개발자로 일하면서 가장 보람을 느끼는 순간은, 내가 개발한 기능을 실제 사용자들이 사용할 때가 아닐까 생각합니다. 제가 한 달 동안 개발에 참여했던 기능이 마침내 릴리스되었고, 우연히 LINE 앱의 릴리스 노트를 보다가 해당 내용이 적혀있는 것을 보게 되었습니다. 비록 달랑 한 줄이었지만, 그 한 줄을 보면서 제가 그동안 개발했던 과정들이 모두 스쳐 지나갔습니다. ‘이건 기념해야 해!’라고 생각하며 스크린숏을 찍어 저장하고 혼자 뿌듯해했던 기억이 납니다.

 

장애 리포트

최근에 제 실수로 서비스에 장애가 발생한 적이 있습니다. 장애의 규모가 어느 정도 큰 경우에는, 장애 리포트를 작성하여 다른 개발자들에게 공유하는 자리를 가집니다. 이 자리는 장애를 일으킨 개발자를 비난하는 자리가 아닌, 다음에 똑같은 장애가 일어나는 것을 막기 위해 어떤 방법을 취하면 좋을까에 대해서 함께 논의하는 자리입니다. 제가 일으킨 장애는 사용자에게 꽤 많은 영향을 주었기 때문에, 저 역시 장애 리포트를 작성해야 했습니다. 작성하면서 한 번 더 스스로 자책하게 되었고, 장애 리포트 작성하는 것을 도와주는 팀원들에게 고마움과 미안함을 느꼈습니다.

장애 리포트를 공유하는 자리는 아무래도 보통의 다른 회의보다는 분위기가 무겁습니다. 그 자리에서 아무도 저를 비난하지는 않지만, 그래도 왠지 모르게 죄인처럼 느껴지는 감정은 어쩔 수 없는 것 같습니다. 저의 실수로 발생한 장애였고, 제가 또 실수하지 않는다면 이런 장애는 다시 발생하지 않을 것이라고 단순하게 생각했었기 때문에, 더 논의할 만한 게 있을까라는 생각도 잠시 했었습니다. 하지만 논의에서 여러 개발자가 저마다 장애 재발을 막기 위한 해결책을 적극적으로 제시해주셨고, 덕분에 제가 생각하지 못했던 좋은 아이디어들을 많이 얻었습니다. 그리고 무엇보다도 장애를 대하는 모든 개발자의 태도가 인상 깊었습니다. 다들 장애를 누구나 일으킬 수 있는 실수로 생각하고, 이를 어떻게 하면 프로세스로 해결할 수 있을까에 대해 같이 고민해 주셨습니다. 이 경험을 통해 많은 것을 배울 수 있었습니다. 하지만, 그래도 장애는 발생시키지 않는 게 최고인 것 같습니다.

 

연말 대응

LINE 메신저 서버 개발자들에게 12월 31일은 1년의 마지막 날이라는 의미, 그 이상의 의미를 가진 특별한 날입니다. 평소 트래픽보다 3~4배나 많은 트래픽을 직접 경험해볼 수 있는 날이기 때문입니다. 이날은 보통 새벽까지 모니터링해야 하므로 대부분 오후 늦게 출근합니다. 오후에 출근하면 폭풍이 오기 전의 고요함과 같은 분위기를 느낄 수 있습니다. 서비스하고 있는 각 국가의 0시가 우리나라 시간대하고 다르기 때문에, 보통 0시부터 3시까지 매시간 모니터링해야 합니다. 특정 나라가 0시가 되는 순간, 새해 인사를 나누는 사용자들의 메시지로 트래픽이 급격하게 증가하는 것을 그래프를 통해 직접 확인할 수 있습니다. 이는 LINE에서만 경험해볼 수 있는 특별한 경험이 아닐까 생각합니다.

저는 아직 연말 대응을 작년 한 번밖에 경험해 보지 못했습니다. 그런데 안타깝게도 그때 약간의 장애가 발생했었습니다. 다들 분주하게 문제의 원인을 찾기 위해 조사하고 대응하는 모습은 마치 수많은 트래픽에 맞서 싸우는 전쟁터의 군인들 같았습니다. 비록 매년 다들 제야의 종소리 대신 에러 알람 소리를 들으며 새해를 맞이하지만, 각자 담당하고 있는 서버나 스토리지를 모니터링하기 위해 새벽까지 열정적으로 근무하는 모습을 보며 경외감을 느꼈습니다. 저 또한 그날 새벽 3시쯤에 퇴근했고, 사무실을 나와 새해의 첫 밤공기를 마셨을 때 말로 설명하기 힘든 여러 감정을 느꼈습니다. 올해는 아무 장애 없이 새해를 맞이하게 되기를 아주 조심스레 바랍니다.

 

직접 다녀본 LINE

경력 개발자의 비중이 높은 회사이기 때문에, 다른 회사에 비해 신입 개발자가 스스로 알아가야 하는 부분이 많은 편이라고 생각합니다. 그렇지만 혼자 진행하다 막히는 부분에 대해 시니어 개발자들에게 물어보면, 다들 적극적으로 친절하게 도와줍니다. 그리고 팀 내에 지정된 멘토가 있어서 멘토의 도움을 받아 더 빨리 회사 업무에 적응하고 성장해 나갈 수 있습니다.

다른 회사와 비교할 순 없지만, 업무량은 적지 않은 편이라고 생각합니다. 코딩 업무에 더해 여러 회의에 참석하고, 또 메신저에 쏟아지는 수많은 업무 관련 메시지를 읽다 보면 어느덧 하루가 지나가 있습니다. 하지만 업무 분위기가 자유로운 편이고, 맡은 업무의 데드라인도 어느 정도 조정이 가능하므로 개인적으로 업무량에 비해 받는 스트레스는 적은 것 같다고 생각합니다.

 

2년을 돌아보며

이렇게 글을 쓰다 보니, 제가 미처 글에 담지 못한 작은 사건들까지 모두 합치면 참 많은 일이 있었다는 생각이 듭니다. ‘나는 2년 동안 성장하였는가?’라고 스스로에게 물어본다면, ‘YES’라고 대답할 수 있을 것 같습니다. 분명 입사 전과 비교했을 때, 개발 지식 측면에서나 동료와의 커뮤니케이션 측면에서 많은 성장이 있었다고 생각합니다. 하지만 ‘나는 2년이라는 기간에 걸맞은 성장을 하였는가?’라고 다시 물어본다면, 그 대답은 ‘NO’일 것 같습니다. 제가 입사 전에 꿈꿨던 2년 후의 LINE 개발자의 모습에는 아직 미치지 못했다고 생각합니다. 여전히 개발 구현에 대해 모르는 게 많고, 어떠한 현상의 원인을 파악하고 조사하는 데 많은 시간이 걸린다고 느끼고 있습니다. 이는 아직 저에게 남은 숙제라고 생각합니다. 앞으로 더 분발하여 3, 4년 후에는 ‘신입’이라는 딱지를 떼도 전혀 어색하지 않은 개발자가 되어 있기를 희망합니다.