상세 컨텐츠

본문 제목

그렙 개발자들은 어떤 개발 문화를 만들고 있을까

그렙 소개

by grepp 2021. 7. 30. 09:49

본문

안녕하세요, 그렙에서 개발을 하고 있는 Benjamin, James, Peter입니다.

그렙 개발팀에 관심을 갖는 개발자 분들이 가장 궁금해할 것 같은 주제, 그렙의 개발 문화를 소개합니다. 

 

 

 


1. 그렙의 개발 조직

기능 조직으로 일하는 그렙

2019년까지도 그렙 개발자들은 모두 한 팀이었으나, 2020년 이후 회사 규모가 확장되면서 모든 개발자들이 한 팀으로 일하기 어려운 시기에 도달합니다. 이 시기를 거치면서 한 팀이었던 개발자들이 각각 다른 팀으로 흩어지게 되었습니다. 그렙이 기능 조직으로 일을 하는 가장 큰 이유는 소통입니다. 개발자, 기획자, 디자이너, 운영 담당자 등등 같은 서비스를 만드는 동료들 간의 의견을 나눔으로써, 더 나은 서비스를 만들 수 있다고 생각합니다.

2021년 8월 기준으로 그렙 개발자들은 채용 서비스를 만드는 채용 플랫폼팀, 테스트에 필요한 기능을 만드는 평가팀, 개발자 학습 서비스를 만드는 교육 플랫폼팀, 총 세 개의 팀으로 흩어져서 개발하고 있습니다. 올해도 많은 개발자를 비롯하여 같이 서비스를 만들어갈 많은 분들을 모셔야 하기 때문에 새로운 팀이 또 생길 가능성은 열려있습니다.

 

팀별 개발 범위 소개

  • 채용 플랫폼팀 : 개발자 채용 플랫폼 개발
  • 평가팀 : 코딩 테스트 / 과제 테스트 기능 개발, 화상 감독 기능 개발,  AI 감독 기능 개발
  • 교육 플랫폼팀 : 개발자 학습 플랫폼 개발

 

 

 


2. 코드리뷰

그렙의 모든 코드는 코드 리뷰를 거쳐 배포됩니다. 이 과정에서 버그를 줄일 수 있고, 설계나 기획 등 맥락을 공유하여 더 나은 방법을 찾을 수 있습니다. 또 내가 생각하지 못한 문법이나 표현식을 다른 사람의 코드로부터 배울 수 있습니다. 그렇기 때문에 코드 리뷰는 중요합니다. 코드 리뷰 방식은 다른 개발 조직과 비슷합니다. feature 브랜치에서 개발이 완료되면 Pull Request를 올려서 리뷰를 신청합니다. 동료들의 리뷰를 받으면 어떻게 처리할지 명시적으로 코멘트 또는 이모지를 남깁니다. 그 후 완료되었는지 서로 확인합니다. 모든 리뷰가 끝나면 테스트를 거쳐 최종 배포를 합니다.

 

 

코드 리뷰를 하는 우리의 태도 : 배려, 질문, 칭찬

그렙은 코드 리뷰뿐만 아니라 코드 리뷰 과정에서 발생하는 소통도 중요하게 생각합니다. 자유로운 코드 리뷰 문화 정착을 위해 Reviewer와 Reviewee의 태도를 정하고 있습니다.

 

 

Reviewer의 태도

  1. DO NOT TOXIC
    • 온라인 상에서 커뮤니케이션은 의도와 다르게 공격적으로 보일 수 있습니다. 키보드와 모니터 너머에 사람이 있다는 것을 인지하고 리뷰를 작성합니다.
  2. 리뷰도 업무의 일부라고 생각하고, 되도록이면 빠르게 처리한다.
    • 할당된 리뷰는 최대 4일 안에 답변을 남겨서 Reviewee의 개발 컨텍스트를 유지시켜 주도록 합니다.
  3. 의미하는 바를 가능하면 명확하게 코멘트로 남긴다.
    • 애매한 답변으로 인해 Reviewee는 많은 시간을 고민할 수 있습니다. 또한 답변을 달았다 하더라도 Reviewer가 맘에 안 들 수도 있습니다. 비효율적인 소통으로 인한 시간 낭비를 피하기 위해서, 명확하게 답변하고 가능하면 예시 코드도 적어 줍니다. 
  4. 내가 이해하지 못하는 코드는 질문하자.
    • 바보 같은 질문은 없습니다. 부담을 갖지 말고 자유롭게 질문을 남깁시다.
  5. Reviewee에 대한 격려 
    • :+1, :clap 하나라도 적거나 남기기
    • 빠른 리뷰가 Reviewee에게 피드백과 큰 격려로 다가옵니다! 
    • 문제점에 대한 지적은 잘해도 칭찬은 안 하는 경우가 많습니다. 동료가 보람을 느끼고 성취감을 느끼도록 적극적으로 칭찬합시다.

잘했다면 잘했다고 칭찬을 합시다

 

Reviewee의 태도

  1. 코드에 대한 코멘트를 나에 대한 공격으로 받아들이지 않는다.
    • 자신의 코드와 나 자신을 동일시하지 않는 게 제일 중요합니다. 그리고 상대는 절대 그럴 의도가 아니었을 겁니다. (그럴 겁니다)
  2. 리뷰에 대한 반응을 빨리 한다.
    • 리뷰에 대한 응답을 즉각적으로 하여 자신의 개발 컨텍스트를 유지하고, 빠른 커뮤니케이션이 되도록 하고 있습니다.
  3. Reivewer가 남긴 코멘트가 항상 정답은 아니다.
    • Reviewer도 실수할 수 있습니다. 항상 Reviewer의 의견대로 코드를 수정할 이유는 없습니다. 내 생각과 다르다면 그에 대한 코멘트를 달고, 합의점에 도달할 수 있도록 합니다. 정답이 안 나올 경우 다른 팀원들과 논의하여 정합니다. 
      애매한 내용이면 전체 개발자들과 논의해서 결정을 합니다.
  4. '이것도 몰라?'라는 생각은 지양한다. 모든 코멘트에 넓은 마음으로 답변한다.
    • 앞서 언급한 것과 마찬가지로, 바보 같은 질문은 없습니다. 
  5. Reviewer에 대한 감사
    • +1, :clap 하나라도 적거나 남기기
    • 리뷰에 대한 반응이 리뷰어에게 큰 도움이 됩니다!

주니어 개발자 입장에서는 다른 사람의 코드를 보고 배우기도 하고, 어떤 부분에서는 더 잘 알 수도 있습니다. 무엇보다 시니어 개발자도 실수를 할 수 있기 때문에 Reviewer를 지정할 때 연차에 무관하게 지정하고 있습니다. 각자의 태도에 대해 서로 이해를 하고 있으면 적극적이고 효율적인 리뷰를 할 수 있습니다. 그렙 개발자들은 이런 방식으로 리뷰를 하고 있습니다.

 

 

 

빠른 코드 리뷰 문화 만들기 : 매일 아침 코드 리뷰

빠른 코드 리뷰 문화는 그렙이 자랑하는 개발 문화 중 하나입니다. 업무를 하다 보면 리뷰를 못할 때가 있고, 이러한 상황이 반복되면 결국 배포 일정에 차질이 생기게 됩니다. 코드 리뷰는 동료들의 개발 일정에 영향을 주기 때문에 최우선으로 처리해야 합니다. 그렙 개발자들은 매일 오전을 코드 리뷰 하는 시간으로 정해서 리뷰 요청에 드는 커뮤니케이션 비용을 줄이고 있습니다.

 

오전에 업무를 시작하면 다른 것보다 먼저 올라온 PR(Pull Request)에 대해서 코드 리뷰를 진행합니다. 매일 아침에 출근을 하면 reminder가 리뷰해야 할 PR 목록을 알려줍니다. 이렇게 오전에 코드 리뷰를 함으로써 리뷰를 기다리는 동료를 배려할 수 있습니다. 또한 피드백 기간을 짧게 하여, 개선에 집중할 수 있는 환경을 만듭니다.

 

출근시간 오는 알림

 

 

 

원활한 리뷰를 위한 노력 : PR 템플릿 사용

처음엔 PR를 남길 때 양식이 없었습니다. 양식이 없다 보니 각자가 쓴 PR에 대한 정보가 너무 달랐기 때문에 그렙만의 템플릿을 만들어서 어떤 정보를 남길지 원칙을 정했습니다. PR 템플릿은 리뷰어에게 히스토리와 컨텍스트를 공유합니다. 더불어 중점적으로 봐야 할 부분이 무엇인지 명시하여 원활한 리뷰가 진행될 수 있도록 돕습니다.

 

그렙 PR 템플릿

 

 

 

코드리뷰 효율성 더 높이기 : 작은 단위 PR 만들기

너무 긴 PR은 리뷰어에게 큰 부담을 주게 되고, 로딩 시간도 오래 걸려서 너무 비효율적이었습니다. 

너무 많은 변경사항과 쌓이는 코멘트들은 브라우저 로딩에도 꽤 시간을 잡아먹습니다.

효율적인 코드 리뷰를 위해 큰 단위의 작업은 작게 쪼개서 PR을 생성하는 방식으로 리뷰를 진행하고 있습니다. 이런 경우 어느 브랜치에서 파생이 되었고, 어느 브랜치가 먼저 merge 되어야 하는지 정보를 남기도록 하고 있습니다.

 

PR을 쪼갠 경우 그에 대한 정보를 남깁니다.

 

 

 

열린 코드 리뷰 : 자유로운 의견 교환을 통한 코드 개선

코드 리뷰는 작업자가 리뷰를 받고 싶어서 지정한 리뷰어 이외에도 회사 Github의 계정을 가진 사람은 누구라도 자유롭게 의견을 남길 수 있습니다. 심지어 개발자가 올린 PR에 디자이너 분이나 운영을 담당하시는 분도 코멘트를 남겨서 서로의 의견을 교환하고 더 좋은 방향으로 코드가 개선될 수 있도록 합니다. 다른 회사와는 다르게 디자이너 분과 개발자 분이 함께 협업하여 코드를 수정하고 PR을 올리기도 합니다.

 

디자이너 Dana가 올린 개선 사항 PR

 

 

 

 

 

 


3. 페어프로그래밍

지식 교환을 돕는 페어프로그래밍 문화

새로운 회사로 출근하게 되면 모든 것들이 낯설어 보입니다. 이는 개발자뿐만 아니라 모든 직무가 마찬가지일 텐데요, 그래서 많은 조직들이 사수, 부사수를 맺어주나 봅니다. 사수, 부사수 문화는 어떻게 보면 유연한 스타트업 문화와 비교하면 경직되어 보일 수도 있을 것 같습니다. 그렙에서는 따로 사수, 부사수의 개념이 없이 새로운 개발자 동료가 입사를 하면 기존의 시스템을 이해할 수 있도록 설명과 페어 프로그래밍을 자주 진행합니다. 꼭 같은 팀이 아니라도 누구든 자유롭게 페어 프로그래밍을 신청할 수 있습니다. 또한 관심이 있는 다른 개발자들도 누구나 참여할 수 있도록 공개 채널에서 줌(Zoom)으로 진행합니다. 페어 프로그래밍을 할 때는 JetBrains IDE가 제공하는 Code With Me라는 기능을 사용하기도 합니다. 동료들을 IDE 프로젝트에 초대할 수 있어서, 실시간 라이브 페어 프로그래밍을 하면서 서로 지식을 나누고 코드를 개선합니다.

 

 

 

재택근무 환경에서 지식 전이 일으키기

이외에도 그렙에서는 Discord라는 툴을 간헐적 협업 리듬을 유지하기 위하여 사용하고 있습니다. 평소에는 방해받지 않는 환경에서 일하다가, 외롭거나 심심할 때에는 라운지에서 화면을 공유하면서 일하기도 합니다. 다른 동료들이 들어와 작업하는 것을 보며 의견을 주기도 하고, 작업하는 방식을 보며 배우기도 합니다. 이때 좋은 툴이 있으면 공유하기도 하고, 자신만의 비법(?)을 공개하기도 합니다. 사무실에서 이루어지는 지식 전이가 온라인에서도 원활히 일어날 수 있도록 항상 서로서로 노력을 합니다. 개인 성향에 따라 음악실에 모여서 음악을 듣기도 하고, 다른 파트에서 일어나는 일들을 라디오처럼 들으며 일하기도 하며, 여러 회의실에서 일어나는 일들이 궁금하면 언제든 들어가 보기도 합니다.

 

Discord에서 코드 보기

 

 

영어 이름이 주는 소통의 자율성 : CEO도 동료 개발자가 될 수 있다

이렇게 자유롭게 소통할 수 있는 문화 기반에는 회사 전체의 자율적인 문화 기반과 영어 이름을 사용하는 것이 도움이 됩니다. CEO도 예외 없이 Young, Samuel로 부릅니다. 두 분 모두 오랜 개발 경험이 있으셔서 필요할 때마다 멘션을 하여 물어보기도 한답니다. 심지어 Young과 같이 페어 프로그래밍도 하고, 실제로 5시간 넘게 페어 프로그래밍하면서 기존의 설계를 파악한 적이 있습니다.

 

 

 

 

 

 


4. 지식을 넓히는 개발자 모임들

그렙은 개발자들의 성장을 위한 다양한 모임을 적극 권장합니다.

 

 

불금개 : 불타는 금요일 개발자 모임

불금개에 놀러온 뭉치 (1살)

 

그렙 공식 개발자 모임 불금개는 불타는 금요일 개발자 모임의 줄임말입니다. 일을 할 때는 각자 팀으로 흩어져서 일을 하지만, 이 시간만큼은 모든 개발자들이 모여서 크게 개발자라는 유대감과 소속감을 느낄 수 있습니다. 불금개는 아재스러운 이름과 다르게 매주 금요일 오후 2시에 개발자들이 기술과 관련된 논의를 하는 재미있는 모임입니다. 최신 트렌드에 크게 관심이 없는 개발자도 다양한 정보를 얻어갈 수밖에 없는 유익한 시간이라고 장담합니다. 물론 기술과 관련된 이야기만 하는 것이 아니라 기술 기업에 대한 이야기, 개발하다가 재밌던 썰, 기타 잡다한 이야기들도 합니다.

 

개발자 어셈블!

 

불금개에서는 백엔드 프론트엔드 가리지 않고 의견이 오고 가기 때문에 한쪽에 매몰되지 않고 다양한 견해를 얻을 수 있어서 개발자들의 만족도도 아주 높습니다. 여기서 나온 의견을 업무에 반영하기도 했습니다. 프론트엔드 폴더 구조에 대한 컨벤션을 논의하고 결정하기도 하였고, 특정 모듈에 대한 설계를 논의하여 의견을 받아 진행시킨 경우도 있습니다. 요즘은 초기에 정한 코딩 컨벤션에 대해 논의하고 개선을 하고 있습니다.

 

최근에는 그렙 개발자가 점점 많아지면서 불금개 진행 방식의 개선을 고민하고 있습니다. 대표적으로 모든 개발자가 모여서 이야기하는 불금개 1부와 랜덤 하게 조를 나눠서 이야기하는 불금개 2부로 나누는 것을 시도하고 있습니다. 이처럼 그렙 개발 조직에 급속 성장함에 따라오는 부작용을 줄이고, 개발자들의 유대감을 강화하기 위해 항상 새로운 방법을 찾고 있습니다.

 

 

 

자율적인 개발 스터디

그렙에는 성장하고 싶어 하고, 성장하기 위해 실천하는 동료 개발자들이 많습니다. 평소에 관심 있었던 기술 분야를 공부하고 싶을 때, 주제 또는 책을 선정하여 스터디를 진행합니다. 누구나 스터디를 만들 수 있으며 모든 스터디는 자율적으로 운영됩니다.

 

"테스트 주도 개발" 스터디 알림

 

* 운영 중인 스터디들

  • 켄트 벡의 "테스트 주도 개발" 책 읽는 스터디 | 매주 목요일 11시 30분
  • 우당탕탕 주니어들의 개발자의 레일즈 스터디
  • 토끼책(객체 지향의 사실과 오해) 스터디

 

스터디에서 배운 것들은 제품 개발에서도 적용하기도 하고, 또 사례를 공유하면서 서로의 성장을 돕습니다. 아래는 "화상 시험의 감독관 기능 사용성 개선" 작업을 TDD로 진행한 Sonny가 공유했던 내용입니다.

 

좌측에 있는 채팅 목록과 우측의 응시자 카드 목록을 동기화하는 작업이었는데요, 기존 앱에서는 전역 스토어에 chatRooms: ChatRoom[]와 subscribedTokenIds: number[]로 상태가 분리되어 있었다고 합니다. 몇 가지 추가적인 요구사항 때문에 두 컴포넌트가 모두 하나의 상태 값을 보도록 할 수는 없는 상황. 쏘니는 기존의 스토어 레이아웃을 유지하고, 변이를 감지하여 chatRooms ↔ subscribedTokens 간 동기화가 달성되도록 반응형 스크립트를 작성하기로 하였습니다.

먼저 켄트 벡이 가르쳐준 대로 차근차근 스펙을 작성하였습니다. 테스트 수트 이름은 각각 "chatRooms to subscribedTokenIds sync"와 "subscribedTokenIds to chatRooms sync". 당연히 아무것도 구현이 안 되어 있으니 처음에는 모든 스펙이 빨간불이겠지요? 하나하나 정복해나갑니다.chatRooms가 변이되어도, subscribedTokenIds는 전혀 변한 게 없군요, 아무것도 구현을 안했으니까요!😅  스토어 인스턴스를 생성하는 스크립트 상에서 구독subscribe API를 활용, 위 스펙을 만족시키도록 구현을 하고,만나고 싶던 운명의 초록불을 확인합니다.😊 처음 며칠은 레거시 앱에 대한 스펙을 작성하느라 진도도 안 나가고 성질이 났지만, 막상 모든 스펙을 준비해놓고 나니 그대로 따르기만 하면 되어서 마음이 든든했어요. 곧장 구현을 시작하는 것보다 느린 것 같아도 전체 일정을 생각했을 때 더 빠르고 효율적이었달까요? 물론 처음 며칠은 스펙을 작성하느라 진도도 안 나가고 성질이 났습니다.😡 제가 한 명만 더 있으면 좋겠어요, 얼른 프론트엔드 개발자를 더 뽑아주세요!

 

 

 

개발 블로그 글을 번역하는 동호회 - 인터프리터

스터디 외에도 개발 글을 번역하는 인터프리터라는 번역 동호회도 있습니다. 각종 개발과 관련된 주제의 블로그 글들을 번역하여 공유하고 있습니다.

 

이런 글들을 번역합니다.

 

 

 

"빨리 가려면 혼자 가고 멀리 가려면 함께 가라"라는 말이 있습니다. 그렙 개발자들은 다양한 방법으로 지식과 경험을 나누면서 오래오래 함께 성장하기 위해 노력하고 있습니다.

 

 

 

 

 

 


마치며

지금까지 그렙 개발 문화를 소개했습니다. 그렙 개발팀은 더 나은 개발 문화를 함께 만들어갈 동료 개발자들을 기다리고 있으니 많이 지원해주세요. 마지막으로 면접에서 자주 물어보시는 질문과 대답을 몇 가지 더 소개하면서 개발 문화 소개를 마칩니다.

 

FAQ

Q. 배포는 얼마나 자주 하나요?

A. 일주일에 정기 배포는 두 번 진행합니다. 그 이외에도 팀에서 필요하면 자율적으로 여러 번 배포하기도 합니다.

 

Q. 협업을 위해 사용하는 도구는 어떤 것들이 있나요?

A. 원활한 협업을 위해서 Jira, Slack을 주로 사용하고 있습니다. 팀마다 개성을 살려서 디스코드를 커뮤니케이션에 활용하는 등 도움이 되는 툴이 있다면 제안을 해서 도입할 수 있습니다.

 

Q. 테스트 자동화는 되어 있나요?

A. 개발자들이 생성하는 모든 PR에 대해 CI가 돌며 테스트가 통과되는지 안되는지를 확인합니다. 당연히 테스트에 실패한다면 merge 할 수 없다는 정책을 유지하고 있습니다.

 

Q. 서비스 모니터링은 어떻게 하고 있나요?

A. 상용 솔루션을 사용하여 코드 레벨의 에러를 백엔드, 프론트엔드 모두 실시간으로 감지합니다. 또한 개발자들이 개별 이슈에 대해서 대응하고 있습니다.

 

Q. Git 브랜치 전략은 어떤 것을 사용하시나요?

A. 기본적으로 Git-flow를 사용하고 있습니다. 최근에 신규 프로젝트에 대해서는 Trunk-based Development를 합의하여 진행하고 있습니다. 이처럼 합의가 있다면 어느 전략이든 사용할 수 있는 유연성을 가지고 있습니다.

 

 

 


글 작성 : Benjamin, James, Peter

 

 

 

 

 

 

 

관련글 더보기

댓글 영역