book review - 나는 LINE 개발자입니다.

나는 LINE 개발자입니다 - 강윤신 외 지음, LINE Developer Relations 팀 엮음/한빛미디어

오랜만에 쓰는 책 리뷰이다.

책 내용이 무겁지도 않은데다가 LINE 개발자의 LINE 입성기, LINE 자랑 정도의 글인데 순식간에 읽어 나갔다. 심지어 같은 사람이 쓴 글이 아닌 12명의 개발자들이 쓴 글이라 글 스타일이 다른데도 말이다.

크게 느끼는 부분이 몇 가지가 있어서 적어본다.

• 정말 중요하고 소중하게 느껴지는 코드 리뷰의 문화
• 나의 경우에도 제대로된 코드 리뷰를 해 본지도 꽤 오래된거 같다. 모두 각자 맡은 프로젝트가 있고 바쁘다 보니 코드 리뷰는 거의 사치가 되어 간다. 나는 내 코드를 스스로 리뷰한다. 리뷰-리팩토링-고민-리뷰로 이어지는 스스로의 리뷰는 남들과 함께 하는 리뷰에 많이 목이 마르다.
• 그렇다고 회사에서 코드 리뷰를 하지 말라고도 하지 않았고, 해도 큰 문제는 없어 보인다. 그렇지만 뭔가 더 생산적인 일을 해야 한다는 느낌을 강하 받는다. 그건 누가 얘기하지도 않고 강요한 사람도 없지만, 모인 사람들의 분위기가 그렇게 되는 것 같다.
• 라인은 대기업인데도 스타트업(?)의 느낌을 살려 팀 단위로 일을 하고 코드리뷰를 한다고 한다. 코드리뷰를 잘 하고 못하고의 문제가 아니라 한다는 게 권장되는 문화가 매우 부럽다.
• 문서화의 중요성
• 이건 나도 100% 동감하는 부분인데, 문서화는 정말 중요하다.
• 라인에서도 역시 문서화를 중요하게 생각하는데 내가 생각한거 보다 더 많은 문서를 작성하는 거 같다. 팀이 모든 문서를 보고 공유를 한다고 하고 팀의 누구와 얘기해도 내용이 공유가 된다고 하니, 이것 또한 부러울 따름이다.
• 그렇다고 회사에서 문서화를 안하느냐 그런건 아니다. 업무 진행과 이슈에 관련된 문서는 다른 회사들도 마찬가지로 잘 적는 편인데, 기술 문서에 대한 부분이 조금 부족한 것 같다. 나는 그런 문서가 중요하다고 생각해서 잘 적는 편이지만 공유가 된다기 보다는 그냥 참고용 정도로만 취급하는 정도라 중요도에 있어서는 크지는 않다.
• 스스로 해야 할 일을 찾는 자율성
• 이건 우리 회사도 크게 다르지는 않지만, 방향이 좀 다르다.
• 라인은 해야 할 일을 찾아서 하지만 팀원들과 함께 부족한 부분을 찾는다던가 지속적으로 대화하고 공유하는 형태이다.
• 우리 회사는 도달해야 하는 목표치를 정해 놓고 그 안에서 자율적으로 움직인다. 협업이라기 보다는 이슈가 생기지 않게 잘 하고 보고를 하는 형태라 조금 그 느낌이 다르게 느껴진다.
• 다만, 개발쪽으로는 최대한 많은 자율성을 보장해 주므로 필요하다면 얼마든지 원하는 기술과 할 일을 찾아서 할 수 있긴 하다.

책에 나온 사람들은 뭔가 대단한걸 했던 사람들이고 당연히 이런 사람들이 LINE에서 일한다는 어떤 예시를 든거 같다. 그건 어떻게 보면 좋은 조직의 문화가 좋은 사람들을 모이게 한다는 뜻이기도 할 것이다. 우리 회사도 그런 문화를 가진 회사로 발전했으면 좋겠고 거기에 내가 많은 참여와 기여를 할 수 있었으면 한다.

Interview review #1

이 글은 취업 활동을 위한 인터뷰가 아닌 재직 중에 인터뷰를 진행했던 리뷰를 적으려 한다. 퇴사가 예정되어 있어서 퇴사 예정 기간 전에 인터뷰 한 것마저 포함되지 않는다. 즉 취업활동을 위한 인터뷰를 제외한 순수하게 인터뷰를 진행한 리뷰이며, 인터뷰에 성공해서 입사를 제안 받았던 아니면 탈락 했던 간에 중요한건 인터뷰를 진행한 이후에 회사 생활에는 큰 문제가 없었던 것들만 적어 보려 한다.

특히 어떤 회사 재직중에 이런 인터뷰를 진행했는지, 또 몇 년도에 진행했는지는 밝히지 않는다. 또 회사에 합격했는지 안했는지가 중요한 리뷰가 아닌 인터뷰를 진행하면서 어떤 걸 느꼈는지에 대한 내용 위주로 작성한다.

#1 외국계 인터넷 온라인 쇼핑 회사

링크드인에서 종종 헤드헌터들의 친구 요청이 많고, 외국 사람들의 친구 요청도 많은데 그런 사람들은 대부분 개인적으로 인터뷰 제안을 하는 사람들은 아니고 그냥 Job position이 있는데 관심 있으면 지원해 볼래? 아님 말고 식의 사람들이다. 이런 친구들이 이렇게 찌라시(?)를 뿌리는 수준이라 친구 추가는 하지만 이후 별 다른 활동이 없으면 친구 삭제를 하는 식으로 인맥 관리를 하고 있고 지금도 그렇게 하고 있다.

그런 와중에 외국계 회사에서 면접 제안을 해 왔는데 개인 메일로 왔고 포지션 및 제안 내용도 꽤나 구체적이었다. 다음달에 오프라인 인터뷰를 위해 한국에서 진행할 것이고 사전 온라인 코딩 테스트도 진행하기 때문에 관심있으면 지원해달라는 식이어서 "한번 해볼까?" 라는 생각이 들게 됐다.

그래서 조금 적극적으로 해보기 위해 이력서를 전달했고 온라인으로 진행하는 코딩 테스트는 언제 하는게 좋을지에 대해서도 물어봐서 일부러 오후 반차를 내고 평일 오후 시간에 하겠다고 회신을 했다.

여기서 온라인 코딩 테스트는 이 회사가 처음이었는데, 그 전에 다른 회사에서 오프라인으로 진행한 인터뷰는 손코딩 알고리즘 테스트나 사전 알고리즘 문제 까지는 풀어봤지만 온라인에서 진행한건 신선했기 때문에 어떻게 진행됐는지 아직도 생생하게 기억이 난다.

우선 온라인 코딩 테스트 링크를 클릭하니 보통 알고리즘 문제 푸는 사이트들과 방식이 좀 달랐다.

• 문제 설명에 맞게 코드를 작성하는 건 당연한데 실행 방법, 제약 조건 등 프로그램 명세에 대한 간단한 설명을 추가로 작성해야 하는 점
• 이 코드를 테스트하기 위한 테스트 방법에 대한 설명과 그 코드를 별도로 작성해야 하는 점 (보통 온라인 코딩 테스트는 문제를 풀기 위한 코딩만 하면 시스템이 테스트를 자동을 해 주고 pass, fail 결과를 자동으로 알려줌)
• 문제를 풀기 위한 시간 제한이 있었고 그 화면이 녹화가 되면서 진행된 점

이때만 해도 테스트 코드를 작성하는 것 까지는 했는데 이걸 테스트 하는 방법에 대한 걸 설명하는게 너무 어색해서 "Just run" 이라고만 적었던 게 기억이 난다. 나중에 생각해 봤을 때 "이 문제를 테스트하는 함수를 호출할 때 클래스 객체를 생성하고 함수를 호출할 때 파라미터 값으로 int 값을 넣어야 한다" 이렇게 적었어야 하는게 맞지 않았나 하는 생각이 든다.

그러니까 여태까지 테스트 코드를 작성할 줄만 알았지 테스트 코드를 어떻게 실행해야 하는지에 대한 설명을 해본 적이 없기 때문에 당황했던 것이다.

그리고 화면 녹화를 했다는 건 제 시간에 결과를 낸 코드를 작성하는게 중요한게 아니라 어떤 과정을 거쳐서 코드를 작성했고 그 설명을 어떻게 써 내려갔는지를 보고 싶어한다는 것도 알았다.

비록 온라인 코딩 테스트는 코드 자체는 맞게 써서 제출은 했지만 통과하지는 못했다. 우리나라에서 했던 방식과는 달랐던 것에 당황을 했고 이때 이후로 코딩 테스트를 평가하는 것에 대한 많은 생각을 하게 됐다. 단순히 어떤 지식을 아는지 모르는지에 대한 테스트가 아니라 설명을 해 나가는 방식의 코딩 테스트가 좋은 평가를 하는 방법이라는 걸 이 회사의 코딩 테스트를 해보고 나서 알게 되었다.

결과적으로 이 회사에서 진행했던 온라인 코딩 테스트는 좋은 경험이었다고 볼 수 있었는데, 나중에 내가 인터뷰를 진행하는 사람으로 참여해서 사전 코딩 테스트 문제를 내고 코드 리뷰를 하는 방식으로 발전 시켰고 좋은 결과를 얻었기 때문이다.