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

이 책은 직접 구매하진 않고 기존에 가기로 했었던
'LINE 프론트엔드 개발자와 함께하는 커리어 멘토링'
이 코로나19 때문에 연기가 되면서 대신 이 책과 라인 스티커 팩을 주었다.
스티커 팩은 너무 귀여웠고 책은 호기심이 가게 디자인 되어 있었다.
하지만 딱 봐도라인이 최고의 회사다 라는 메시지를 가진 책이겠지 싶었다(ㅎㅎ)
그렇다면 왜 최고 인지에 대해 생각하면서 읽어 보자 라는 생각이 바로 들었다.

(몇개는 붙엿네요..ㅎㅎ)

책은 12명의 개발자 및 개발 매니저 역할을 하시는 분들이 4가지 주제로 나누어 자신의 경험에 대해서 말하는 형식으로 구성되어 있었다.

1. 라인 개발자의 일상
2. 개발자가 되는 법
3. 라인에서 새로운 도약을 꿈꾸는 사람들
4. 개발자라고 개발만 하나요?

라는 주제를 가지고 있었다. 책을 읽으며 마음에 드는 구절을 정리해보면

1. 라인 개발자의 일상

• 개발자에게 문화적 다양성을 접하고 글로벌 역량을 개발하는 것이 어떤 긍정적인 영향을 미치는 가에 대해 인지하지 못했었는데 중요한 깨달음은 다양한 문화와 언어, 국적 출신의 다양한 성격과 장점을 지닌 사람이 함께 일할 때 조직의 역동성이 강화되고, 다각적인 시각에서 고품질의 서비스와 솔루션을 제시할 수 있다는 점이다. 개인의 의견 차이로, 문화적 오해와 몰이해로, 언어 차이로 어려움을 겪기도 하고, 본연의 업무보다 커뮤니케이션에 시간과 노력이 집중될 때도 있지만 다양한 관점이 모여 민주적이고 수평적인 토론이 이루어지고 개선이 될 때, 팀이 성숙하고 조직이 성장한다는 점이 분명했다.
• 날렵한, 민첩한 이라는 뜻을 가진 애자일(agile) 은 불확실한 상황에서 협력과 피드백을 통해 팀 빌딩을 도모하고 개발 프로세스를 효율적으로 개선하기 위한 방법론이다. 정해진 일정과 강요에 따라 소프트웨어를 생산하는 것이 아니라, 개발자의 역량과 업무의 우선 순위에 따라 개발 환경을 유연하게 조정하고 개발 과정 전체를 개선함으로써 업무 효율성을 도모하는 것이다.

2. 개발자가 되는 법

• 개발에서는 기여(contribution)에 대한 인정(credit)이 분명하다.
• 당사자는 문서가 짧은 이유가 본인의 짧은 영어 탓이라고 했지만, 그 짧은 문서는 복잡하고 급박한 요구조건 가운데 개발자로서 당장 집중해서 구현해야 할 것은 무엇이며 어떻게 구현할 지를 명확하게 보여 줬다.
• 라인의 개발자들은 아테네 학당 이란 그림과 비슷하다. 누구나 직급이나 형식을 따지지 않고 자유롭게 대화하면서도 엄밀하게 옳고 그름을 따지고, 서로 부딪치기도 하면서, 최선의 해결책을 찾아 나간다.
• 이렇게 말을 많이 하고, 이렇게 글을 쓰고 많은 사람을 마주한다. 새로운 기술을 도입하고 싶을 때, 테크 스펙을 쓰고 일일 스크럼 모임에서 모든 팀원 앞에서 발표하며 코멘트를 듣는다. **맨땅**에서 일을 시작할 때 바라볼 것은 코드가 아니라 **사람**이다.
• 내 느낌을 **의심하고 또 의심해야 한다.**주니어라고 주눅이 들 필욘 없지만 나를 일관되게 이끌어줄 생각과 개발의 원칙을 설정하고 연습해야 할 필요성을 항상 느낀다.
• 우리 팀은 개발을 이끄는 원칙과 실천을 끊임없이 고민하고 체계화하고 **문서화**하는 팀이다. 처음 팀에 와서 감동을 받았던 점은, 팀으로서 같이 따를 원칙과 실천을 정리해놓은 방대한 문서였다.
• 빡빡한 코드 리뷰는 팀 전체가 코드를 더 명료하게 유지하고 실력을 지키기 위한 원칙이 지켜지고 있다는 신호이다. 사소하고 별것 아닌 문제에도 서로 부담없이 코멘트를 달 수 있다는 사실이 중요하다. 코드 리뷰가 정착되지 않은 팀이라면 사소한 트집을 잡는다 생각해 기분이 상할 수 있는데 그 사소한 문제들이 쌓여 기술 부채가 되고 팀 전체의 실력을 유지하기는 커녕 눈앞의 문제를 처리하는데 급급한 상황을 마주하게 될 것이다.
• 각자의 논리와 관찰을 맞대어 보고 최선의 길을 결정해서 같이 가보자 하는 마음가짐이 중요.
• tacho-23.0 release
• 내가 속한 팀은 코드 리뷰를 통해 단순히 버그를 발견하고 수정하는 수준을 넘어 가독성과 확장성이 뛰어난 코드, 일관된 스타일의 코드, 유지 보수하기 편리한 코드를 작성하려고 노력한다. 그리고 다양한 피드백과 토론을 통해 더 좋은 코드를 작성하고 경력에 따른 실력의 격차와 개발 결과물의 차이를 줄여나가고 있다.
• 코드 리뷰를 통해 함께 만들어가는 시스템이기에 문제가 발생하면 우리 모두의 문제 였다고 말하는 것으로 서로를 탓하는 데에 시간을 낭비하지 않고, 다 함께 문제를 빠르게 해결하기 위해 집중한다.
• 장애 리뷰는 충격적 이었는데 혼나거나 추궁하는 자리가 아니라 우리 시스템의 어느 부분이 부족했기 때문에 장애가 발생했는지 논의하고 향후 개선 방향에 대해서만 계속해서 이야기 했기 때문이다. 리뷰를 통해 장애가 발생한 원인을 복기하고 장대 대처의 속도와 정확도는 적절했는지 점검하여 향후 동일한 형태의 장애가 발생하지 않도록 준비한다.
• 더 많이 성장하고 싶은 주니어 개발자의 공부 팁
  • 개발에 대한 흥미를 잃지 않기
  • 이미 잘 만들어진 소프트웨어에서 배우기
  • 이론까지 탄탄한 개발자 되기.
• 이렇게 당연한 걸 왜 상대방은 이해하지 못할까 하는 생각을 많이 했다. 지나고 나서 보니, 생각보다 더 다양한 사람이 다양한 경험을 기반으로 성장한다. 서로 다른 경험을 가진 사람들이 팀으로 모이게 되면 제일 먼저 발생하는 문제가 **의사소통** 이다.
• 영어가 너무 힘들어 국문 문서를 참고하고 싶다면 영어 원문을 번역한 글보다 차라리 한국 개발자들이 직접 겪은 내용이 담긴 블로그를 참고하는 편이 낫다.
• 질문이 같이 근무하는 동료의 시간을 뺏는 것이라, 최대한 짧은 방해로 궁금한 부분을 해결해야 하다보니 스트레스가 이만저만이 아니다. 진짜 어려운 부분은 **어떻게 물어봐야 하는가**라는 부분이다. 핵심은 **내 상황을 정확하게 알리자** 질문이 어려운 이유가 내가 어떤 상황인지 파악이 어렵기 떄문이다.

3. 라인에서 새로운 도약을 꿈꾸는 사람들

• "로켓에 올라타세요. 회사가 빠르게 성장할 때에는 많은 충격이 있고 커리어는 알아서 성장하게 되어 있습니다. 그런데 회사가 빠르게 성장하지 못하고 회사의 미션이 별로 애기가 안될 때에는 정체와 사내 정치가 시작된다. 로켓에 자리가 나면 그 자리가 어디 위치했는지 따지지 말고 우선 올라타세요.

• 회사를 경영하며 느낀 점 세가지만 애기해보자면

  1. 직원들의 전문 영역인 기술 능력을 다른 영역에까지 기대하게 되는데 어떤 한 분야을 잘한다고 해서 다른 분야까지 잘할 수 있을 거라는 것은 오산이다.
  2. 최첨단을 지향하는 해커들이 모여있다보니 엔지니어로서 하고 싶은 연구와 돈을 벌수 있는 연구와 괴리가 있다.
  3. 너무 geek한 엔지니어들만 모이면 스타트업 생태계를 꾸리기 어렵다.

• 회사 생활을 하다보면 사소한 것이든 큰 것이든 문제는 항상 발생할 수 밖에 없다. 엔지니어 입장에서는 납득이 되는 근거를 상사에 전달했을 때 그에 대한 지원을 회사에서 해준다면 더 바랄 것이 없다.

• 라인의 조직문화를 엿보면 많은 점을 배울 수 있었는데

  1. 팀의 내부 정보 교류가 굉장히 잘된다. 나중에 놀란 점은 위키와 버그 추적 시스템을 활발하게 활용한다는 점을 제외하면 다른 어떤 마법도 존재하지 않았다. 반대로 이야기하면, **잘 기록하고 다른 사람의 기록을 잘 읽는다**는 기본이 기업의 강력한 자산이 될 수 있다는 뜻이다.
  2. 엔지니어링 친화적인 조직이다. 프로젝트 리더들이 모두 엔지니어 였거나 현재도 엔지니어링을 하여, 협업 모델의 구현 수준에 대해서도 구체적인 수준의 대화를 어려움 없이 나눌 수 있었다.
  3. 상당히 적극적으로 API를 개방한다.

• 많은 회사가 특정 부서만 문서화에 관심이 있거나 대부분 문서화를 별로 신경 쓰지 않는 경향이 있다. 아무래도 글로 쓰는 것보다 말로 하는 것이 더 편하기 때문인데, 일부러 신경쓰지 않으면 제대로 하기가 어려운 일 중 하나다. 문서화의 장점은

  1. 회사 내 정보 중 휘발되는 것은 거의 없기 때문에 회사 내 활동 경험이 집단적으로 축적될 수 있다. 기록이 없이 사람에 의존하는 경우, 특정 직원이 이직을 함과 동시에 집단적으로 같은 실수를 반복하는 모습을 많이 볼 수 있다. 같은 실수로 1~2년을 낭비하는 경우도 있다.
  2. 써보는 문화와 찾아보는 문화 또한 발달하게 된다. 질문을 하는 것보다 위키를 검색해보는 것이 더 빠르고 정확한 결과로 이루어지기 때문에 검색이 습관화되고 이는 회사 내 정보 교류를 무척 효율적으로 만들어준다.
  3. 충실한 문서화는 회사가 새로운 도전을 하는데 용기를 주고 **문서화를 통해 우리는 실패를 자산화** 할 수 있다. 다음 도전을 할 때의 이전의 실패를 복기하고, 그 위에서 새로운 도전을 할 수 있다면 모든 도전은 실패했어도 실패로 끝나는 것이 아니라 다음 성공을 위한 교훈이 될 수 있다.

  • 희망과 공포는 같은 것이다. 희망을 집어 드는 순간 공포도 집어들게 된다. 그러니 잘될 것 같아서 선택하는 것보다 실패해도 후회하지 않을 것 같아서 선택을 하는 것이 바람직하다.

    4. 개발자라고 개발만 하나요?

  • 이벤트 아이디어 브레인 스토밍 과정

    • 커뮤니티를 활성화하려면 사람들이 많이 유입되어야 한다.
    • 그럼 새로운 사람들의 관심을 끌만한 것이 있어야 한다.
    • 그런데 새로운 사람들에게만 신경쓰면 기존 기여자들은 서운한 느낌이 들지 않을까?
    • 그동안 한번이라도 질문을 했거나 기여했던 사람들은 분명히 우리 프로그램에 애정을 가지고 접근했을 텐데 정기적으로 활동하는 경우가 많지 않아서 아쉽다.
    • 어떻게 하면 애정을 주기적으로 불러 일으킬 수 있을까?
    • 혹시 우릴 잊지는 않았을까?
    • 다시 우리에겐 관심을 가지게 해보자.
    • 역시 돈이 최고다. 선물을 줘야한다.

  • 테크 에반젤리스트를 기술 전도사로 옮기기도 한다. 개발자들을 이해하고 소통해야 하기 때문에 소프트웨어 개발을 할 수 있어야 하지만 코딩보다는 글이나 발표를 통해 기술 공유를 하므로 개발 관련 다양한 커뮤니케이션을 즐기는 사람들에게 적합한 일이다.

  • 기술 공유를 통해 가장 많이 배우는 사람은 역시 발표자 혹은 글을 쓰는 본인이다. 가르치는 것이 가장 좋은 배우는 방법이라는 말이 있듯이 내가 안다고 생각해서 글로 정리하기 시작하면 더 많은 것을 정확하게 공부하게 된다.

  • 기술 공유는 다른 사람, 또 나 자신의 성장에 도움이 되는 것은 물론이고, 공유를 통해서 사람들의 의견을 듣고 소통하게 되므로 거기서 다양한 사람과의 관계가 형성된다. 냉철한 피드백을 통해 내가 성장하기도 하고 주제에 대한 비즈니스 기회가 생기기도 하고, 채용으로 연결되기도 한다.

  • 기술 블로그의 이점은 내가 잘 알고 있다고 생각했던 것들도 글로 남기기 위해 더 많은 공부를 하게 된다는 점이다. 단편적으로 알고 있던 내용을 글로 적다 보면 하나의 맥락으로 연결시키게 되면서 더 잘 기억에 남게 된다.

  • 세상은 개발자가 뛰어나야만 한다는 편견으로 바라보지만 이런 생각은 도움이 안 되며, 프로그래밍은 누구나 배울 수 있는 스킬로 노력해서 중간만 한다면 충분하기 떄문에 스킬 자체가 뛰어나야만 가치 있는 개발자라는 생각을 버려야 한다고 한다.

책에서 읽은 라인은 우리가 흔히 생각하는 구글(?)의 문화를 가진 회사라는 이미지가 그려진다. 그만큼 자율성도 높고 수평적이며 원인과 결과가 확실하여 논리적이다. 내가 관심이 많은 일을 잘하기 위한 다양하고 좋은 방법들이 있고 나와 같은 주니어 개발자가 성장하기에 최고의 회사라는 생각이 든다.

책을 읽으면서 내가 평소에도 생각하고 좋아하는 말들이 많이 나와서 공감이 많이 되고 재미있게 읽었던 것 같다. 예를 들면 "실패 후 자산화 하여 더 강력해진 모습으로 돌아온다" 나 의사소통, 발표, 남의 글을 잘 읽는 문화 등 평소에도 공감하고 내재 해야되는 부분 이다 라고 생각했었다.

코로나가 잠잠해진다면 이 행사를 통해 실제로 이 글을 쓴 분들과 만나 대화할 수 있는 기회가 생기면 좋을 것 같다.