올해 초에 페이스북을 보다 우연히 LINE(이하 라인)에서 프론트엔드 개발자를 대상으로 커리어 멘토링 행사를 진행한다는 소식을 접하게 되었습니다.
내가 봤던 멘토링 공고
탄탄대로라기보다는 잡초(?)에 더 가까운 듯한 저의 커리어를 외부인의 시각에서 평가해준다는 점이 꽤 흥미로웠습니다. 그래서 오랜만에 경력기술서도 다듬고, 그 외에 질문할 것들을 정리해서 지원을 해보았는데, 운 좋게도 참석자로 선정이 되었습니다.
하지만 멘토링 시간이 업무 시간과 겹치게 되었는데, 또 감사하게도 재직 중인 회사에서 지원을 해주셨습니다. 그렇게 두근대는 마음으로 다녀오려는 찰나…
코로나 싫어
코로나 19 때문에 행사가 무기한 연기 되었습니다. 나름 기대하고 있었는데… 아쉬웠습니다. 그래서인지 나중에 라인에서 연락을 하나 받았는데, 멘토링 참가 예정이었던 사람들에게 작은 선물을 보내주겠다는 메일을 한 통 받을 수 있었죠. 내용은 아래와 같습니다.
LINE의 개발 문화를 살펴보실 수 있는 ‘나는 LINE 개발자입니다’ 도서 1권과 LINE 개발자 스티커 패키지를 택배로 보내드리고자 합니다 :)
그렇게해서, 한 일주일 정도 기다리니 책과 스티커를 선물로 받게 되었습니다. 사실 평소에 책 읽는 거를 좀 귀찮아해서… 읽어야지, 읽어야지, 생각만 하고 있다가, 지난 주 평일 저녁에 생각이 문득 나서 그 날 밤에 후딱 읽어버렸습니다. 그래서 오늘은 책 『나는 LINE 개발자입니다』를 읽고 느낀 감상을 공유해보고자 합니다.
책 소개
선물로 받은 거 인증
이 책은 라인의 개발 문화를 홍보하는 LINE Developer Relations 팀 에서 12명의 사내 개발자 분들의 에피소드를 엮은 책입니다.
책은 크게 4장으로 구분되어 있고, 각 장마다 세 명의 개발자들이 자신들의 성장 이야기를 풀어놓았습니다.
- 라인 개발자의 일상
- 개발자가 되는 법
- 라인에서 새로운 도약을 꿈꾸는 사람들
- 개발자라고 개발만 하나요?
10대 창업자부터, 게임 마니아, 철학 전공 개발자, 아마존 출신 개발자 등 다양한 경력의 12인이 라인 개발자가 되기까지의 이야기, 그리고 라인에서 동료들과 함께 글로벌 개발자로 한 단계 성장하는 과정을 엮은 책입니다.
글로벌 서비스
이 책에서 가장 많이 언급되는 부분이 있는데, 바로 글로벌 서비스에 관한 에피소드입니다.
글로벌 경쟁력과 외국어 능력도 중요하지만, 다문화적인 감수성과 문화에 대한 이해 및 관용적인 태도를 함양하는 것도 국가 간 협업에 매우 중요했다. 예를 들어 인도네시아는 이슬람 문화권으로, 종교적인 단어 및 이미지 선택이나 라마단 기간의 풍습과 생활 모습 등을 반드시 고려해야만 로컬에 최적화된 서비스를 제공할 수 있다.
- 57p
저는 이 부분을 재밌게 읽었는데, 그 이유는 이전 직장에서 다개국어를 지원하는 글로벌 서비스 제작에 참여했던 기억이 떠올랐기 때문입니다. 당시에 저는 VR 솔루션 플랫폼의 프론트엔드 파트의 구현을 담당하고 있었고, 영어를 중심으로 한국어, 일본어까지 총 3개국어를 지원하는 서비스를 제작하고 있었습니다. 영어로 흔히 줄여서 i18n(Internationalization)이라고도 하죠.
플랫폼의 규모가 점점 커지게 되면서, 지속적인 운영이 가능하도록 플랫폼 운영에 소모되는 비용을 획기적으로 줄이기 위한 새로운 서버 모듈 개발 작업도 진행해야 했다. … 어느새 나는 여러 국가의 사용자가 사용하는 서비스를 지원하는 플랫폼 개발자가 되어 있었다.
- 94p
위 인용구처럼 저는 서버 개발자는 아니지만, 프론트엔드에서도 다국어 지원을 하면서 성능을 최적화 하기 위해 다양한 노력을 했던 기억이 납니다. 다개국어 프론트엔드 지원은 주로 제가 도맡아서 했는데 대충 아래와 같이 구현했던 기억이 납니다. 사실 이걸 가지고 누군가에게 피드백을 받은 적이 없어서, 이게 정확한 방법인지는 잘 모르겠습니다.
- 페이지나 컴포넌트 별로 출력되어야 할 텍스트들을 JSON 파일로 분리
- 이 JSON 파일을 해당 언어 원어민에게 전달하면 번역해주심
- 번역된 JSON 파일을 업로드
이런 과정들의 반복이었는데… 매 번 업데이트가 될 때마다 새로 생기거나 사라지는 텍스트들이 생기다보니, 관리하기도 어렵고 추적도 잘 안되어서 힘들었던 기억이 납니다. 그래서 어드민 권한을 가진 사람들을 대상으로 해당 언어의 JSON 파일을 웹상에서 직접 수정할 수 있게 페이지를 만들었던 기억이 나네요.
단순히 텍스트를 번역해서 관리하는 것도 쉽지 않았는데, 다문화를 고려해서 서비스를 제공한다고 하면 그 큰 규모에 압도당할 것 같기도 하고, 서비스를 어떻게 운영하고 있을까라는 호기심도 들더군요.
좋은 서버 개발자가 되기 위해서는 대규모 인프라와 트래픽을 감당할 수 있는 역량을 갖춰야 한다고 생각했다. … 따라서 대규모 인프라와 트래픽을 소화하는 개발팀에서 일할 수 있게 된다면 좋은 개발자로 성장할 수 있을 것 같다고 생각했다.
- 99p
확실히 유의미한 트래픽을 가진 큰 규모의 회사를 경험한다는 것이 개발자로서 커리어에 많은 도움이 될 것 같다 는 생각이 들었습니다.
좋은 동료
뜬금없지만 동료 하니까 생각나서 넣어봤습니다
예전에 읽었던 『소프트웨어 장인』 에서도 이야기했지만, 개발자에게 동기를 부여할 수 있는 최선의 사람은 바로 동료 개발자다 라는 말에 저는 전적으로 동의하는 편입니다. 그래서 아래와 같은 인용구를 읽었을 때 좀 공감하면서 읽었습니다.
나는 2012년 라인에 합류할 때부터 이미 최고령자 그룹에 속해 있었지만, 라인에서 일하는 동안 연령에 관계없이 동료들에게 늘 배우고 있다.
- 43p
그래서인지 “개발자가 된 철학도” 부분에서, 개발자는 함께 고민하는 직업이고, 잘 모르겠다라고 말하는 게 자연스러운 직업 이라고 얘기한 것이 좀 신선하게 와닿았습니다.
나는 지금 라인에서 개발자로 일하며 고민할 자유를 마음껏, 그것도 다른 사람들과 함께 누리고 있다. … 시니어 개발자들도 모르겠다거나 고민하고 있다고 말하는 게 자연스럽고, 문제가 일어나도 누구를 탓할 것 없이 자리에 다같이 모여서 머리를 싸매고 고뇌하는 일이 일상인 이곳에서, “괜찮다”라는 말은 우리 모두 개발자로서 같은 고뇌의 숙명과 고민의 자유를 누리고 있다는 동질감의 확인처럼 느껴지기에 위로를 받는다.
- 76p
다만 무책임한 “모른다” 라는 말을 뱉기 보다는, 질문과 토의도 책임감이 있어야 한다고 이야기 합니다. 내가 지금 어떤 상태고, 어떤 배경지식을 갖고 있고, 문제를 해결하기 위해서 어떤 노력을 했다라는 것을 잘 언급해주어야 상대방도 현 상태를 잘 이해할 수 있죠.
질문을 하는 사람으로서는 모르는 내용을 어떻게 질문해야 할지 고민해야 하고, 질문을 받는 경우는 내가 답변해야 하는 내용을 먼저 머릿속에서 정리해서 답변해야 한다. 라인에는 서로 질문하는 문화가 잘 갖추어져 있어, 많은 개발자가 함께 문제를 살펴보므로 기술을 이해하는데 좋은 환경이다.
- 104p
요거는 저도 지키려고 노력하고 있지만 종종 놓치곤 하는데, 보다 잘 챙길 수 있도록 노력해야겠다는 생각이 들었습니다.
다양한 직군
예전에 라인에서 테크니컬 라이터라는 직군이 있다는 글을 본 적이 있었습니다. 그때에도 오, 사소한 거지만 되게 잘 신경쓰네 라는 인상을 받았었죠.
책 4장 제목이 개발자라고 개발만 하나요? 인데, 제목처럼 신비한 직군들이 많이 나옵니다. 회사에서 오픈소스 프로젝트를 총괄하여 관리하는 오픈소스 매니저, 개발자를 대상으로 자사 제품을 알리고 기술을 공유하는 역할인 테크 에반젤리스트 의 이야기가 있죠.
이 분들의 글을 보고, 어떻게 보면 되게 사소하게 느껴질 수 있지만 전문적으로 담당하는 인력이 있다는 것에서 개발 문화를 꽤 섬세하게(?) 다루고 있구나 라는 것을 좀 느꼈습니다.
아래는 테크 에반젤리스트 분의 글을 인용한 건데, 인상깊었던 거라 공유해봅니다.
기술 공유를 통해 가장 많이 배우는 사람은 역시 발표자 혹은 글을 쓰는 본인이다. 가르치는 것이 가장 좋은 배우는 방법이라는 말이 있듯이, 내가 안다고 생각해서 글로 정리하기 시작하면 더 많은 것을 정확하게 공부하게 된다.
- 222p
문서화의 중요성
라인은 글로벌 기업이죠. 그만큼 문서화에도 꽤 신경을 많이 쓰는 것 같았습니다.
처음 팀에 와서 감동을 받았던 점 가운데 하나는, 팀으로서 같이 따를 원칙과 실천을 정리해놓은 방대한 문서였다.
- 누구든 팀의 프로세스와 프로젝트의 기술적인 얼개를 이해하고 체득할 수 있도록 도와주기 위한 신입 가이드 문서
- 실제 코드나 기술을 도입하는 데 필요한 배경, 설계, 구현 계획을 담아놓은 테크 스펙
- 코드를 고치고 정기적으로 배포할 때의 모든 절차를 나열한 가이드
- 비상 상황에서 참고할 지표, 대응 범위, 행동 방침을 합의해서 규정해놓은 팀 문서
일곱도 넘지 않는 팀이 당장 밀려드는 문제를 처리하는 데만 급급해하지 않고, 원칙을 되새기며 문서를 유지 보수하는 일은 결코 쉽지 않다.
- 85p
정리된 문서가 낡지 않게 갱신하는 것도 중요하다고 언급했습니다. 이런 것들을 보다 전문적으로 관리하기 위해서 테크니컬 라이터라는 직군을 따로 두는가 봅니다.
힘들게 만든 문서가 갱신되지 않고 에전 모습으로 남아있다면 오히려 혼란을 줄 수 있다. 그래서 처음 온 분들에게 온보딩 문서에 따라 진행하면서 정상 동작하지 않는 부분이 있거나, 새 버전이 나오면서 바뀐 부분이 있다면 수정을 부탁한다.
- 118p
이렇게 문서화의 중요성을 강조하는 이유에 대해서 한 개발자분은 아래와 같이 말씀해주셨습니다.
충실한 문서화 역량은 회사가 새로운 도전을 하는 데 용기를 준다. 문서화를 통해 우리는 실패를 자산화할 수 있기 때문이다.
- 188p
장애를 발전의 기회로
책의 여러 에피소드에서 공통적으로 나오고 있는 이야기 중 하나가 바로 장애를 발전의 기회로 삼는다 는 것이었습니다.
누군가의 잘못 혹은 실수로 장애가 발생했을 때 많은 경우 희생양을 찾고 빌미가 된 사람을 질타하거나 비난하기 십상이다. 하지만 라인에서는 장애가 발생한 직후부터 이미 장애 리포트가 작성되고 근거 자료의 취합이 진행될 뿐만 아니라, 장애 리포트를 공유하는 미팅도 가능한 한 많은 사람과 함께 갖는 문화가 있다. … 같은 배를 타고 있는 동료로서 목적지까지 더 잘 갈 수 있도록 서로를 돕는 이상적인 모습이라고 느꼈다.
- 27p
인간인 이상, 실수하지 않는 개발자는 없습니다. 물론 저도 사소한 오타부터 시작해서 비즈니스 로직을 잘 못 이해하거나, 배포환경을 잘 못 설정하는것 처럼 사고친 적이 꽤 있죠.
사실 이 장애 리뷰 회의를 처음 접했을 때 혼나러 가는 줄 알고 긴장하며 들어갔는데 굉장히 신선한 충격을 받은 적이 있다. ‘왜 장애를 발생시켰느냐’라는 추궁의 자리라기보다는 우리 시스템의 어느 부분이 부족했기 때문에 장애가 발생했는지 논의하고 향후 개선 방향에 대해서만 계속해서 이야기했기 때문이다.
- 101p
사람이라면 누가 잘못된 코드를 작성했는지를 따져보는 블레임(blame)의 유혹에 쉽게 빠집니다. 하지만 발생한 장애에 대해서 함께 책임을 갖고 해결하고, 이를 발전의 기회로 삼는다는 점에서 라인의 성숙한 개발 문화를 말해주는 듯 합니다.
제 잘못으로 인해 장애가 발생되면 저도 긴장되고, 풀 죽고, 자신감이 많이 떨어지는데 이에 대해서 좀 인상깊게 읽었던 문장이 있더군요.
개발자의 성장과 역량 개발의 한 축은 장애와 트러블에 대응하며 문제해결 능력을 키워나가는 데 있지 않나 하는 생각을 하게 되었다.
- 56p
느낀 점
라인… 괜찮은 것 같네?
프로그래밍은 결국 커뮤니케이션이라고 생각한다. 사람과 컴퓨터의 대화, 같이 일하는 동료들과의 커뮤니케이션에서 시작한다.
- 127p
작년 이 맘때 쯤에 제가 개발자 커리어를 통틀어서 가장 감명깊게 읽었던 책인 『소프트웨어 장인』을 올렸던 적이 있었죠. 『소프트웨어 장인』 같은 경우에는 프로페셔널한 소프트웨어 개발자가 가져야하는 마음가짐과 태도를 배울 수 있어서 감명 깊게 읽었던 것 같았는데, 『나는 LINE 개발자입니다』 의 경우에는 12명의 개발자분이 각자 살아온 인생의 썰을 푸는(?) 내용이라서 뭔가 드라마틱한 교훈을 받지는 못했습니다.
하지만 그래서인지 같은 직종의 주위 사람들 이야기를 듣는 느낌이어서 책을 읽는 내내 친근함과 현실감이 느껴졌습니다. 사실 『소프트웨어 장인』 의 경우에는 외국 개발자가 쓴 이야기라 뭔가 문화적•정서적으로 이해가 안 갔던 에피소드들이 몇 개 있었거든요. 다만 프론트엔드 분야와 관련된 이야기가 없어서 개인적으로 조금 아쉬웠습니다.
그리고 지금 재직 중인 회사에서도 위에서 언급한 요소들을 지켜가기 위해 꽤 많은 노력을 들이고 있구나 라는 것도 새삼 느꼈습니다. 예전 회사와 비교했을 때 코드의 품질을 유지시키기 위해 노력하고, 정보를 문서화하며, 서로 배울 점이 있는 뛰어난 동료가 있는 것처럼요.
사실 다음 달에 병역특례가 끝나서 소집해제를 하는데, 그 기념(?)으로 이 책에 적힌 것처럼 개발자로써 나의 커리어에 관한 요약글을 써볼까 계획하고 있었습니다. 그런 점에서 책에 수록된 각각의 에피소드들을 참고하면 글을 쓸 때에도 도움이 될 것 같네요. 뭐 아무튼, 선물로 받아서 읽게 된 책이지만 나름 재밌게 잘 읽었던 것 같습니다. :)
