초기 스타트업의 개발 문화 만들기
헤이조이스 Dev 일기 #1
최근 헤이조이스는 "제품은 고객과 함께 해야 의미가 있다"라는 핵심 가치를 두고 기존에 오프라인 중심으로 진행하던 모임을 온라인으로 전환하는 것에 성공했습니다. 누구도 예상치 못했던 코로나 사태로 오프라인 모임을 진행할 수 없게 되었고, 고민 끝에 온라인 화상 회의 도구를 사용하여 온라인 모임을 여는 실험을 거친 후 전환하는 쪽으로 결정을 내렸습니다.
이처럼 현 시점에 고객이 원하는 것이 무엇인지를 살피고 그에 맞는 기술을 적용하며 기술 기반의 제품으로 진화하고 있습니다. 현재는 고객에게 더 나은 경험을 제공하기 위해 자체 개발한 웨비나 시스템을 통해 온라인 콘퍼런스, 모임이 진행되고 있습니다.
앞으로 헤이조이스가 성장하는 과정에서 우리가 배운 것들을 이 공간에서 나누고자 합니다. 먼저, 한 명의 개발자가 동료를 모시고 개발 문화를 만드는 이야기로 시작합니다.
협업의 즐거움이 필요해!
저는 이전 조직에서 8명의 개발자로 구성된 팀을 리드하는 역할을 했습니다. 제품의 규모도 크고 함께 협업해야 하는 부서, 이해관계자도 다양해 협업 프로세스가 가장 중요했습니다.
헤이조이스는 pre-A 시리즈 단계의 어린 기업입니다. 저희와 같은 초기 스타트업의 개발 조직에게 가장 중요한 것은 무엇일까요?
서비스의 규모나 기업의 구조가 달라도 변하지 않을 바로 "협업의 즐거움"입니다. 제가 5개월 전 헤이조이스와 함께하게 되었을 때 유일한 개발자였기 때문에 우선순위가 가장 높은 일은 함께 협업할 동료를 모시는 일이었습니다.
헤이조이스의 첫 개발자 채용 공고인터뷰 과정에서는 서로에게 필요한 것들을 공유하고 상호 존중이 되는가에 집중했습니다. 저희의 예상보다 많은 분들이 지원해주셔서 Fit이 맞는 분들과 함께 할 수 있게 되었고 우리는 이렇게 함께 출발하게 되었습니다!
우리는 목표는?
이렇게 모인 구성원들이 협업을 잘하려면 가장 먼저 필요한 일이 무엇일까요? 먼저 집중해야 할 일을 명확히 정의하고 우리가 하는 일에 대한 계획, 데이터 기반의 추정, 실행, 측정하는 것을 목표로 삼았습니다.
우리가 해야 하는 일을 정리해 보는 것으로 시작했습니다
어떻게 협업해야 할까요?시스템의 구조는 그것을 설계하는 조직의 커뮤니케이션 구조를 닮는다라는 말이 있습니다. 이 범위를 제품 전체로 확대해도 유효할까요? 제품에 영향을 미치는 사람들 간의 협업 방식에 따라 제품의 구조는 달라집니다. 고객에 집중하면 제품의 변화는 빨라지고 고객이 원하는 핵심 가치를 발견할 확률이 높아집니다.
더 나아가 제품의 구조는 고객과 함께 해야 의미가 있습니다.
이 과정에서 우리는 최소 기능 제품(MVP)을 만드는 것을 즐기고 있습니다 해결해야 하는 문제의 덩어리를 잘게 나누는데 효과적인 방법이기도 하고 구체화하는 과정에서 안갯속에 가려진 가치들이 MVP를 통해 빠르게 발견되어 유연하게 대응할 수 있기 때문입니다.
매일 배포하는 조직되기
고객이 원하는 것을 발견하고 지속적으로 개선하기 위한 가장 효과적인 방법은 무엇일까요? MVP가 뼈대라고 한다면 살을 붙여가며 사람의 형태를 갖춰나가게 해야 합니다. 우리는 이것을 지속적인 배포로 효과적으로 실행하고 있습니다.
Branch의 생성부터 고객에게 배포하기 위한 프로세스를 위해 GitHub Flow을 사용합니다. Pull Request를 통해 코드 리뷰에 집중할 수 있고 Protected Branch 기능을 통해 CI 서버에서 Build, Testing 코드 품질을 관리할 수도 있습니다.
최근 3개월 동안 3명의 개발자로부터 395개의 Pull Request가 생성되었고, 하나의 Pull Request는 Squash Merge를 통해 main branch에 merge 됩니다. 이렇게 merge 된 변경내역은 GitHub Action을 통해 지속적으로 자동으로 배포되니 하루 평균 4회의 배포가 일어나고 있는 셈입니다.
Pull Request는 협업 도구인 GitHub의 한 기능으로 개발자들이 코드를 보며 서로 피드백을 주고받는 공간으로 리뷰가 완료되면 제품에 반영됩니다.
잦은 배포를 가능케 하려면 코드 리뷰와 모니터링이 중요합니다. 이 글에서는 효과적인 코드 리뷰를 위한 Pull Request에 관하여 코멘트합니다.
• 제목에서 목적을 명확히 알린다
• Branch 이름에 효과적인 정보가 포함된다 예를 들면 신규 기능인지 버그를 수정하는 일인지 Branch를 만들기 전 어떤 구체화 과정이 있었는지 이슈 번호로 쉽게 확인이 가능하다
• Commit의 범위와 메시지가 일관적이다
• Draft PR, 체크리스트를 활용해 진행 상황을 공유한다
• 테스트 코드를 통해 테스트 가능한 시나리오를 제공한다
• 경우에 따라 Self-Review를 한다
모든 인과관계는 함께하는 사람입니다
지금까지 초기 스타트업에 동료가 모이고 협업 프로세스를 만들어가는 과정을 조금이나마 공유했습니다. 우리는 즐겁게 협업하고 함께 같은 목표를 향해 나아가길 바랍니다.
우리가 만나는 많은 문제들이 혼자서 해결하기 힘든 이유로 데일리 스크럼, TDD, 코드 리뷰 등 효과적으로 협업하기 위한 방법을 활용하지만 이것을 잘하는 것이 저희의 목적은 아닙니다.
무엇보다 중요한 것은 스스로 문제를 정의하고 해결해 나아가는 사람입니다
모든 인과 관계는 결국 사람에서 나오기 때문에 개발 문화는 동료와 함께 만들어가며, 일하는 방식은 언제든지 상황에 따라 변할 수 있다고도 생각합니다.
고객이 진짜 원하는 것을 해결합니다
이 모든 실행의 목적은 고객이 진짜 원하는 문제를 해결하기 위함입니다.
우리가 하는 일에 대해 아래의 질문을 통해 이 문제를 해결하고자 합니다.
해결하려는 문제 정의가 명확한가?
고객이 정말 원하는가?
우리가 하는 일이 측정 가능한가, 어떤 데이터가 필요한가?
기술 제약 사항이 존재하는가?
다음 헤이조이스의 Dev 일기에서는 위 과정에서 아이디어를 구체화하고 기술을 통해 고객의 경험을 나아지게 만든 다양한 사례를 공유하고자 합니다. 여기까지 첫 Dev 일기를 읽어주셔서 감사합니다!
▼ 헤이조이스 구경하러 가기
