위메프로그

"위메프 개발 문화는 어때요?"

채용 면접 때 꼭 듣는 질문 중 하나입니다. 막상 이런 질문을 받으면 설명하기 참 어렵더라고요.
 
좋은 점을 열거하자니 시간이 오래 걸리고 표현도 부족해 "알고 계신 건 모두 다해요."라고 두루뭉술하게 답하곤 했는데요. 면접이 끝나면 내심 그 답변이 아쉬워져요.
 
새 단장한 공식 블로그를 통해 위메프 개발 문화를 소개할 수 있게 돼 기쁩니다. 위메프 예비 개발자분들께 도움이 됐으면 좋겠어요!

위메프 개발 문화 1편, 데일리 스크럼과 코드리뷰 이야기입니다.

좋은 개발 문화란 무엇일까요?

개발자라면 당연히 좋은 개발 문화가 있는 회사에서 근무하길 원할 겁니다. 그건 취업을 준비하는 예비 개발자뿐 아니라 현직자인 저 역시 그렇습니다. 좋은 개발 문화가 있는 회사에서 일하면 절로 실력이 향상될 거란 기대가 들기 때문이죠.

여러 회사들의 개발 문화 소개 글을 보셨을 겁니다. 그런데 글만으로 “여기 개발 문화 정말 좋네” 혹은 “나와는 맞지 않는 것 같다”라고 판단하지는 않습니다. 그렇다면 좋은 개발 문화의 판단 기준은 뭘까요?

우선 좋은 개발 문화를 위한 저희의 노력을 몇 가지 소개하겠습니다. 아래는 저희 팀 채용 공고에서 발췌한 내용입니다.

100% 충족은 어렵겠지만 위메프의 개발 문화를 어느 정도 짐작할 수 있기를 바라며 작성했습니다. 물론 이 공고를 통해 지원한 분들도 어김없이 개발 문화에 대한 질문을 하셨지만요.(웃음)

아침엔 산뜻하게 스크럼

데일리 스크럼은 많이 들어 보셨을 겁니다. 매일 아침에 전날 발생한 이슈와 오늘 할 일에 대해 간단하게 이야기하고 이슈가 있다면 의견을 교환해 더 나은 해결 방법을 찾아보는 시간입니다. 더불어 공지사항과 주요 현안도 공유하죠.

데일리 스크럼에 참여해 보신 분이라면, 딱딱하고 지루한 분위기에 지쳤던 경험도 한 번쯤 있으실 텐데요. 말 그대로 데일리 스크럼이다 보니 매일 반복하다 보면 그럴 수도 있다는 생각이 듭니다. 한 명씩 돌아가면서 본인의 업무 이야기를 하니 자연스레 시간도 길어지기 마련이고요.

그래서 저희는 스몰토크(수다^^)로 가볍게 시작합니다. 날씨, 드라마, 연예, 사회 등등 분야를 막론하고 아이스브레이킹을 한 뒤에 집중력이 상승됐을 무렵 업무 이야기로 넘어가죠. 본래 목적이니까요.

이때 이슈나 건의사항도 자연스럽게 나오는데 이 시간만큼은 즉각적인 판단보다는 의견을 경청하려고 노력합니다. 물론 팀원 수가 많아지면 시간 지연 문제도 발생합니다. 저희 팀은 JIRA BigGantt를 활용해 데일리 스크럼 전에 주요업무를 미리 확인하고 참여하는 방식으로 해결하고 있습니다.

위 차트는 스프린트 기간의 업무 진척 내용을 프로젝트 또는 에픽 기준으로 정리해 둔 것인데요. 매일 일과 시작과 끝을 지라(JIRA)로 정리하고 공유하니 효율적으로 업무를 관리하고 스크럼 시간도 줄이는 효과를 보고 있습니다.

또 팀원들도 서로의 업무 내용과 진도를 파악할 수 있어 전반적인 팀 문화에 긍정적인 영향을 줍니다. 본인 업무에만 집중하고 동료가 어떤 업무를 진행하는지 알지 못한다면 사일로*화 된 조직으로 변하는 것은 순식간이니까요.
*다른 부서와의 정보 공유 및 소통·협력을 외면하는 현상

특히 문제가 생길 땐 혼자 끙끙대기 보다 동료들과 상의하는 것이 해결 방법도 빨리 찾고, 코드 품질도 더 향상시킬 수 있는 지름길이 될 겁니다. 이제 데일리 스크럼이 어떻게 개발 문화에 기여하는지 어느 정도 감이 오시죠?

코드리뷰를 통해 문화를 만든다

개발 문화 다음으로 가장 많이 들었던 면접 질문은 "이 회사는 코드 리뷰를 어떻게 하고 있나요?"였습니다.

 "PR전에 리뷰 요청을 하고 리뷰어들의 승인 후 배포를 하고 있습니다"라고 답했는데요. 지금 생각하니 다소 예상 가능한 답변이었네요. 그런데 중요한 것은 코드 리뷰의 형식보다 참여율입니다.

한 팀에도 다양한 프로젝트가 존재합니다. 같은 팀원이어도 서로의 업무를 알지 못한다면 리뷰를 해주는 데 한계가 있습니다. 그래서 저희 팀은 팀 내 코드 리뷰 시간을 줄이는데 집중했습니다. 최대한 많은 리뷰어들이 참여할 수 있도록요.

먼저 리뷰 요청자는 다음과 같은 정책을 준수하고 리뷰를 요청하도록 규칙을 정했습니다.

• ☑️ 코드컨벤션
• ☑️ 네이밍컨벤션
• ☑️ 클린코드
• ☑️ 코드 분석 및 품질 향상

리뷰 전에 위 사항이 정확하게 지켜진다면 바랄 게 없겠죠. 리뷰어들은 비즈니스 로직만 체크하면 되니까요.

하지만 위 사항을 모두 지켜서 정확하게 코드를 작성하시는 분은 (솔직히) 없습니다. 너무 방대한 양이니까요. 물론 린트(lint)로 정확도를 높이는 노력을 할 수 있겠죠.  하지만 업무 효율을 생각하면 린트를 높여서 정책 수립을 하는 것도 만만치 않습니다.

아무튼 위 규칙을 정한 뒤에 리뷰 요청자는 최대한 정책을 준수했다는 가정으로 리뷰 요청을 하고 리뷰어들은 비즈니스 로직과 가독성 그리고 효과적인 문법 사용에 초점을 맞춰서 리뷰를 진행할 수 있었습니다.

그 결과 리뷰 시간이 점차 짧아졌고 동료들은 비즈니스 로직 문제점을 보다 효과적으로 구성하게 됐죠.

그런데 또 이렇게 효율을 추구하다 보니 다른 이슈가 발생했습니다. 리뷰 요청자도 별다른 설명 없이 리뷰 요청을 하고, 리뷰어들도 특별한 문제가 없다면 그냥 승인 처리를 하기 시작한 거죠.

문제를 삼지 않으면 문제가 되지 않지만, 이럴 거면 코드 리뷰가 아니라 코드 검사라고 불러야 되는 것 아닌지😅 그래서 이런 코드 리뷰 가이드를 추가하게 되었습니다.

조금 더 구체적인 프로세스도 정했습니다. 리뷰를 요청할 때 지라(JIRA)의 커밋(commit) 메세지에 이슈 번호를 넣으면 리뷰어들은 스마트 커밋(Smart Commit) 기능으로 비즈니스 로직을 파악하기로요. 결과적으로 문서를 찾아서 검색하는 시간과 리뷰 시간을 줄였습니다.

지금도 진화 중

이 밖에도 저희 팀은 JetBrains의 UpSource를 이용하고 있는데요. 리뷰어의 요청을 Github 안에서 승인하는 것보다 인텔리제이(IntelliJ)에서 쉽게 리뷰를 하고 소스를 볼 수 있다면 조금 더 편리하지 않을까 하는 생각에 시도해 봤고요.

앞으로도 코드 리뷰를 더 효과적으로 할 수 있는 방법을 지속적으로 찾아서 적용해 볼 생각입니다. 찾게 되면 또다시 소개해 드릴 게요. 아니면 저희 팀으로 오셔서 같이 찾아보시는 것도 환영입니다.😉

위메프 핵심가치 중에 ‘프로팀’이 있는데요. 개발자에게 ‘프로팀’이란 동료들과 협업하며 함께 성장하는 것이 아닐까 싶습니다. 그리고 그 과정에서 개발 문화가 만들어지고 진화하는 것이겠죠.

2편(개발 문화 with 테크톡)에서 뵙겠습니다.

감사합니다.☕️