"나는 LINE 개발자입니다"를 읽고

집 근처 도서관에 가서 책을 구경하는데 "나는 LINE 개발자입니다"라는 책이 눈에 띄었다. 다른 회사 개발자들의 삶은 어떨까 궁금해서 냉큼 빌려왔다.

 

라인에서 일하는 개발자들이 어떻게 개발자가 되었는지부터 라인에 입사하게 된 이유, 라인에서는 어떻게 일하는지 등의 이야기들이 있었다. 무엇보다 좋았던 건 나라는 개인과 지금 다니는 회사 모두에게 유익한 내용이라는 점이었다.

 

개발자 개인에게 좋은 내용을 먼저 소개하고, 회사에 도움이 되는 내용을 그다음에 소개하겠다.

더 많이 성장하고 싶은 주니어 개발자의 공부 팁

1. 개발에 대한 흥미 잃지 않기

개발자로 일하고 계신 분들은 대부분 개발을 좋아하신다. 하지만 좋아하는 정도에서는 차이가 있다고 생각한다. 개발자 분들 중에도 쉬는 시간에도 개발을 하고 새로 출시되는 자바 버전을 밥 먹을 때 얘기하는 찐 개발 덕후분들이 있고, 적당한 관심을 갖고 계신 개발자 분들도 있고, 별 관심이 없는 개발자 분들도 있다.

 

개발에 대한 흥미를 가지는 건 순전히 개인의 취향 차이 아니냐고 생각할 수도 있다. 하지만 개발을 직업으로 삼는 사람이라면 개발을 좋아해야 개발자로서의 삶을 더 길게 가질 수 있을 뿐만 아니라 일을 할 때도 즐겁게 할 수 있다.

 

이 책에서는 IT 관련 기사와 회사의 기술 블로그를 읽는 방법을 추천하고 있다. 책에서는 어썸데브블로그(https://awesome-devblog.netlify.app/)를 알려주고 있다. 나는 읽기만 해도 재밌는 Velog(https://velog.io/) 도 가끔 들어가서 본다.

 

2. 이미 잘 만들어진 소프트웨어에서 배우기

책에서는 나에게 익숙한 프로그램을 만들어보는 것을 추천하고 있다. 예를 들면 메신저, 웹 크롤러, 봇 등이 있다. 책에서 글쓴이는 봇을 만들어서 사내에서 업무 자동화에 큰 기여를 했다고 설명했다.

 

3. 이론까지 탄탄한 개발자 되기

기술에 대한 이론, 책, 기술 문서를 공부하는 게 좋다. 예를 들어 리액트라면 리액트 공식 홈페이지에 기술 문서가 잘 정리되어 있다. (https://ko.reactjs.org/) 나에게는 다른 곳들보다 공식 홈페이지의 글이 큰 도움이 되었다. README와 CHANGELOG를 읽는 것도 좋다. 또한 기술 문서는 대부분 영어이기 때문에 번역 문서보다는 원문을 보기를 권한다고 적혀있었다.

 

라인의 개발 문화

1. 코드 리뷰 문화

"코드 리뷰 과정을 통해 내가 생각하지 못했던 잠재적인 버그를 발견한다. 작성한 코드에 대해 여러 개발자와 의견을 나눈다. 버그를 수정하는 수준을 넘어 가독성과 확장성이 뛰어난 코드, 일관된 스타일의 코드, 유지 보수하기 편리한 코드를 작성한다."

 

p75.

코드 리뷰를 받을 때마다 한 줄 한 줄 본인이 쓴 코드에 태클이 걸리고, 가끔은 종일 걸려 쓴 코드 전체를 폐기하게 될 수도 있는데, 그게 속상하고 힘들지 않느냐는 이야기였다. 그 말을 듣고 우리 팀원 한 분이 너털웃음을 지으며 말한 게 아직도 기억에 남는다. "일단 내 코드에 무조건 문제가 있을 거라 믿고 검증을 받아나가는 게 무조건 맞아요. 진짜 무조건!"

 

IT 대기업은 코드 리뷰를 빡세게 하고 중요하게 여기는 걸 알게 되었다. 지금 다니고 있는 회사는 팀장님이 코드 리뷰를 해주고 계신데 모든 팀원이 함께 코드 리뷰를 해보면 좋을 것 같다.

 

2. 탓하지 않는 문화

"많은 위기와 시스템 장애를 겪었지만 지금껏 어떤 한 사람을 콕 집어서 책임을 물었던 적이 없었다. 코드 리뷰를 통해 함께 만들어가는 시스템이기에 문제가 발생하면 우리 모두의 문제였다고 말하는 것."

 

첫 회사에 입사했을 때 업무 중에 실수를 해서 큰일이 난 적이 있었다. 그때 어떤 차장님이 내게 사람은 누구나 실수를 한다고 얘기하셨다. 그 말은 크게 낙담한 나에게 용기를 북돋고 빠른 시간 내에 수습할 수 있게 해 주었다.

 

개발 중에서 문제가 발생하더라도 개인에게 책임을 묻지 않는다는 라인의 문화가 좋아 보였다. 물론 담당자의 책임이 없진 않겠지만 누가 책임자인지 찾아내고, 왜 그렇게 했는지 추궁하고, 그 사람의 능력을 탓한다면 그 사람은 자존심에 상처를 받고 더 이상 발전할 수 없다. 잘잘못을 가리기보다는 앞으로 어떻게 해야 개선이 될지, 이런 문제가 재발하지 않을지 논의하는 게 좋은 방향이라 생각한다.

 

코드 리뷰를 통해 함께 만들어가는 시스템이기에 문제가 발생하면 우리 모두의 문제였다고 말하는 것

-> 솔직히 이 글을 보고 정말 충격을 받았다. 이렇게도 생각할 수 있다니. 그만큼 코드 리뷰를 체계적으로 하기 때문에 가능한 일인 것 같다. 회사의 입장에서는 코드 리뷰를 통해 버그를 사전에 방지할 수도 있을 것 같다.

 

3. 장애 리뷰

"장애를 해결하면 장애 보고서를 작성한다. 장애의 영향 범위, 현상, 원인, 조치 내역을 시간순으로 기록한 보고서를 작성하여 이 보고서를 토대로 유관 부서와 장애 리뷰 회의를 진행한다."

 

"왜 장애를 발생시켰느냐 라는 추궁의 자리라기보다는 우리 시스템의 어느 부분이 부족했기 때문에 장애가 발생했는지 논의하고 향후 개선 방향에 대해서만 계속 이야기했다."

 

"라인이라는 회사는 장애마저도 발전의 기회로 삼는 것 같다고 생각한다. 누군가의 잘못 혹은 실수로 장애가 발생했을 때 많은 경우 희생양을 찾고 빌미가 된 사람을 질타하거나 비난하기 십상이다. 하지만 라인에서는 장애가 발생한 직후부터 이미 장애 리포트가 작성되고 근거 자료의 취합이 진행될 뿐만 아니라, 장애 리포트를 공유하는 미팅도 가능한 한 많은 사람과 함께 갖는 문화가 있다. 메일로 장애 리포트가 담긴 위키 주소를 공유하고 장애 공유 미팅을 하면서 사람들은 새로운 아이디어를 내고 장애가 반복되지 않도록 시도할 만한 아이디어들을 제시한다."

 

이외 도움이 돼서 메모했던 글들

p51.

"아마존이 그전까지 일했던 스타트업과는 다르게 좀 더 성숙된 조직과 문화를 가지고 있었다고 느꼈던 지점은 다양했다. 우선 팀 내부적으로 목표가 분명했고 사람들의 역할도 체계적으로 나뉘어 있었다. 팀의 비즈니스도 탄탄했다. 기술적으로는 이전 스타트업에서 내가 손수 구축해야 했던 많은 시스템, 예를 들면 모니터링이나 배포 등이 이미 잘 갖쳐줘 있어 효율적으로 맡은 업무에 집중할 수 있었다. 나는 아마존의 체계화된 조직 문화를 좋아했다."

-> 아직 지금 회사가 스타트업이고 개발 인원이 적다 보니 개발 체계를 먼저 잡으면 좋을 것 같다는 생각이 들었다.

 

"내 결론은 데이터 기반 의사결정, 즉 실증 데이터와 근거를 바탕으로 한 과학적인 방법론을 적용해 문제를 해결해야 한다는 것이었다."

-> 나도 재밌는 프로젝트를 기획해서 해보고 싶은데 데이터를 기반으로 우선순위를 정하여하는 게 좋다는 것을 알게 되었다.

 

<질문하는 방법>

질문하는 방법(http://1st.gamecodi.com/board/zboard.php?id=GAMECODI_Advice&no=29)

How to Ask Questions The Smart Way(http://wiki.kldp.org/wiki.php/DocbookSgml/Ask-TRANS)

HOWTO for Beginners(https://oops.org/?t=lecture&sb=beginner&n=1)

내 상황을 정확하게 알리면서 질문하자

 

<위키와 버그 추적 시스템>

"잘 기록하고 다른 사람의 기록을 잘 읽을 수 있다면 기업의 강력한 자산이 된다."

-> 지금 회사에서 대응하는 이슈들을 위키에 잘 정리해두면 좋은 자산이 될 것이다.

 

---

한국에 파이콘(파이썬 콘테스트)을 처음으로 정착시킨 배 권한 씨는 주변 동료들이 너무 뛰어나서 주눅이 들곤 했다고 한다. 사실 개발자라면 누구나 공감할 것이다. 나는 컴퓨터공학과 3학년 때 처음 그런 감정을 느꼈다. 학교 전공 수업에서 하스켈(함수형 프로그래밍) 언어로 과제를 내준 적이 있었다. 나는 과제 마감일까지 아무리 해도 과제를 풀 수가 없었는데 학과에서 가장 잘하는 친구는 그 문제를 척척 푸는 것이었다. 결국 나는 과제를 풀지 못했고 열등감을 느끼며 나는 더 이상 발전할 수 없구나 하며 자책을 했었다.

 

2015년 미국 파이콘에서 장고 웹 프레임워크를 만든 제이컵 카플란 모스가 "나는 중간 정도 되는 개발자"라고 선언을 했다고 한다. 장고라는 유명한 웹 프레임워크를 만든 대단한 사람은 천재일 것 같은데 중간 정도 한다고 얘기한다니.

 

그는 "개발자는 뛰어나야 한다고 생각하는 편견은 오히려 개발자에게 도움이 되지 않는다"라고 얘기했다. 그런 편견에 사로잡힌다면 개발자는 주위의 동료들과 자신을 비교하면서 열등감에 빠져 발전할 수 없게 된다. 프로그래밍 스킬은 사실 대단한 것이 아니고 누구나 충분히 배울 수 있다.

 

어릴 때 처음 개발을 배웠을 때의 즐거움을 생각해보자. 그리고 시간을 내서 내가 만들어보고 싶은 것들을 개발해보자!