스타트업 개발문화 도입기 -하-
CTO로 스타트업에서 살아남기 3편
이번 편에서는 실제 개발 문화에 대한 이야기들을 하려 한다. 물론 내가 했던 방식이 정답은 아니지만, 다른 많은 회사들의 개발 문화를 공부하면서 제일 좋다고 생각했던 점들을 쏙쏙 뽑아와 적용했다.
코드 리뷰 해주세요!
우리는 Pull Request (or Merge Request)를 수행할 때 코드 리뷰를 필수적으로 거쳐야만 하도록 약속했다. 코드 리뷰를 수행하는 이유는 많지만 내가 가장 중요하다고 생각하는 이유는 서로가 생각하지 못하는 부분을 살펴주는 것이다. 먼저 코드 리뷰를 요청한 요청자의 입장에서는 차마 발견하지 못한 버그를 확인할 수 있다. 또 불필요한 코드나 구조들의 개선에 다양한 의견을 받고 수정할 수 있다. 나는 개발팀에게 주석을 최소화할 수 있도록 부탁했다. 이유는 로직이 이해가 안 가도 주석이 있다면 아, 이런 로직이겠거니 하고 넘어갈 수 있기 때문이다. 이건 좋은 리뷰가 아니라고 생각해 주석을 최소화했다. 자연스럽게 읽는 사람은 로직을 꼼꼼히 살펴야 했고 불필요한 부분을 쉽게 캐치해 줄 수 있었다고 생각한다.
그럼 리뷰를 해주는 사람의 입장에서 좋은 점은 무엇일까? 배울 수 있다는 점이다. 보통 무언가를 공부하고 배울 때 어떻게 하는지 생각해보자, 책을 읽는 사람이 대부분일 것이다. 코드 리뷰를 통해 다른 사람의 코드를 읽으면서 배우고 좋은 코드에 대해 고민해 볼 수 있다고 생각한다. 또한 코드의 중복을 최소화할 수 있으며 다른 개발자가 작성한 코드를 나의 코드에 적용하는 것도 쉬워진다.
위에 내가 말한 장점은 코드 리뷰가 가지는 내가 생각하는 최고의 장점이지만 장점의 전부는 아니다. 이 이야기를 본 다른 개발자들은 반대의 의견을 내비칠 수 있다고 생각한다. 이럴 때 하는 말이 in my opinion일 것이다. 하지만 내 생각에는 최소한 위에 작성한 내용을 생각하며 코드 리뷰를 수행한다면 요청자와 리뷰자 모두에게 도움이 될 것이라 말할 수 있겠다.
아, 이거 꼭 해야 해요? 핵심 파이프라인 (Lint와 Test)
얼마 전 블라인드(직장인 커뮤니티)에서 TDD, 테스트 코드를 작성하는 것에 대해 이해를 할 수 없다고 작성한 글을 보았다. 난 어느 정도 공감하는 부분도 있다. 하지만 기본적으로 우리는 개인 프로젝트를 하는 것이 아닌 비즈니스를 하는 사람들이다. 때문에 테스트는 매우 중요하다고 생각한다.
나는 팀원들에게 TDD(프런트 엔드는 BDD와 함께)를 하라고 종용했다. 테스트 코드를 먼저 작성하고 정의한 스펙에 따라 코드를 작성하라고 요청했다. TDD를 처음 접해본 팀원들은 모두 힘들어했다. 스펙을 먼저 정의하고 그에 따라 코딩하는 프로세스는 당연히 힘들다. 테스트를 어떤 식으로 수행해야 내가 원하는 기능이 잘 작동하는 거지? 어디서 어디부터 테스트를 해야 하지?라는 끝없는 의문은 같이 따라온다. 나는 팀원들에게 항상 이야기한다. 사용자가 절대 내지 않는 버그에 대해 테스트를 짜지 말아라, 사용자가 하는 행동을 생각하라고 강조한다.
테스트가 스펙에 맞춰 개발하는 것이 라면 그냥 내가 머릿속에 스펙을 잘 가지고 개발하면 되는 것 아닌가요?라고 물어볼 수 있다. 이건 비즈니스 측면에서 봐야 한다. 이런 테스트 파일은 규모가 커지고 새로운 로직을 도입했을 때 정말 큰 도움이 된다. 새로운 기능을 추가했을 때 버그가 주르륵 나는 경험을 개발자라면 반드시 한 번은 해봤을 거라 생각한다. 그런데 그런 버그가 실제 배포된 서비스에서 발생한다고 생각해보자 끔찍하다. TDD나 유닛 테스트를 수행하는 행동은 모두 이런 버그를 미연에 방지해주기 때문에 비즈니스적인 측면에서 중요하다.
내가 테스트에 대해 열변을 토한 이유는 우리가 PR을 작성할 때 자동으로 Lint와 Test의 실패 성공 여부를 자동으로 확인하기 때문이다. 이런 프로세스를 통해 내가 작성한 기능이 다른 테스트에 영향을 미치는지 미리 확인하고 팀이 약속한 컨벤션을 해치는지에 대해 확인하는 과정을 거치게 된다.
그럼 Lint는 무엇일까? Lint는 위에서 말한 코드 컨벤션을 의미한다. 가장 쉬운 예시로는 카멜 표기법을 따르는지, 공백은 몇 줄로 하고, indent의 개수를 정하는 코딩 스타일의 모든 것을 의미한다. 이런 스타일을 팀별로 통일하는 것이다. 코딩 컨벤션을 통일함으로써 팀이 얻는 이득은 상당히 크다. 새로운 개발자가 합류했을 때 통일된 스타일로 전임자의 코드를 습득하기 쉽다. 또한 실수를 줄여주며 Ctrl + F를 통한 변수 찾기, 이름 찾기에서도 큰 도움을 주게 된다. 구글에게 물어보면 다른 부가적인 장점들이 더 많이 나올 것이다.
내가 Lint를 확인하는 프로세스를 개발 문화에 도입한 가장 큰 이유는 역시 통일된 코딩 스타일을 통해 얻는 이득이다.
이번 편에서는 파이프라인에 대해 이야기한 것 같다. 두서없이 작성되었지만 개발 문화의 핵심으로 디거의 개발팀이 수행하는 파이프라인을 정리하자면 아래와 같다
개발 - PR - Lint테스트 - Unit Test 수행 - 코드 리뷰 -
리뷰에 따른 코드 수정 / 적용 - Merge or Rebase
이번 편도 결국 분량 조절에 실패하고 이런저런 이야기를 한 것 같다.. 다음 편은 조금 더 잘 정리해보도록 하겠다.
