좋은 개발 문화란 결국 다양한 개별의지가 충돌하는 답 없는 문제로 귀결된다.

Keyword

[Agile Process, Code Review, Scrum, Sprint, 회고, 각종 툴, 개인의 성장을 위한 활동, Pair programming & blogging, Tech blog, etc]

Issue

• 본인은 현재 GroupBy 라는 스타트업에 입사한지 한 달차 인 백엔드 개발자이다. 아직은 플랫폼 개발팀이 없는 상태이고, 웹 개발자도 5개월차 백엔드인 본인뿐이다.

• 이전 개발자 분들(프1, 백1)이 사용하다가 남겨놓은 레거시들이 있지만, 각자가 혼자서 개발을 하셨다보니 솔플(solo play)의 흔적이 많이 남아 있는 상태다.

• 당연히 이렇다 할 개발 문화는 존재하지 않았고, 앞으로 꾸려질 개발팀에 도입하고픈 개발 문화에 대해 내가 직접 고민을 해야하는 상황이다.

• 여러가지 개발 문화에 대해 리서치하고 생각들을 정리하는 것이 이 포스팅의 목적이다.
  
  

Think hard

어느 데브옵스 분의 개발 문화 정착 실패담

개발 문화를 도입해야한다 라는 의견을 들었을 때, 아래와 같은 생각들이 머리를 스쳐갔다. 그리고 리서치를 하면서 생각에 변화가 일어났다.

• 좋은게 좋은거지. 괜찮은 문화 가져다 쓰자!
  문화는 상징적인 것이다. 개개인이 다른 만큼 원하는 문화도 다양하다.
  남들이 좋다는 문화를 그냥 가져다 쓴다면 맞지 않는 옷을 억지로 입은 것처럼 어색하고 불편하기만 할 뿐이다.

• 개발팀이 이제야 꾸려지는데, 이거 맞아?
  스타트업, 그 중에서도 IT나 소프트웨어 개발이 목적이 아닌 일반 서비스에 종사하는 스타트업은 개발팀이 열악하거나 아예 없는 무주공산일 가능성이 크다.
  이런 경우, 혼자서 할 수 있는 것이 많지 않다. 그러나 작은 일이라도 하나씩 모아놓고, 정리하고, 파악해 둔다면 2명이 되는 그 순간부터 팀의 문화가 시작 될 수 있을 것이다.

• 경력직(사수) 있으니까 괜찮겠지. 알아서 하실테니, 따라만 가자.
  시니어 or 리드급 개발자에 의해 문화가 만들어질 수도, 아닐 수도 있다. 리더가 자기성장욕구도 강하고 후배 개발자들에게 관심이 많다면 자연스레 다양한 방법들로 문화 정착에 힘 쓸 확률이 높다. 혹은 실험이나 도전의지가 강한 사람이라면 이 또한 여러 방법들을 시도해보고 싶어 할지도 모른다. 개발팀이 완전 새로이 만들어 졌거나, 열악하다면 여러가지 시도를 해보는 것만으로도 좋은 경험이 된다. 그러나 최악의 경우, 너는 너, 나는 나 식 대로 회사일만 하고 따로 국밥이 되는 경우도 생길 수 있을 것이다. 주니어에겐 난감한 상황일 뿐만 아니라, 퇴사 의지를 불러 일으킬지도 모른다.

• 개발 문화? 그냥 코드 리뷰하고 데일리 스크럼하고 그런거 아닌가?
  기업에 따라 개발 문화는 해당 조직의 문화가 될 수도 있다. 대부분의 기업에는 개발팀 뿐만 아닌 여러 개발과 무관한 팀들이 존재한다. 예를 들어 '코드 리뷰'는 개발팀만 수행 할 수 있지만, '독서 모임'은 아무나 참여가 가능하다. 이처럼 문화는 어떠한 프로세스가 아닌 목적에 따른 구성원들의 참여 그 자체인 것이다. 설령 '독서 모임'이 개발자들 사이에서 시작 했을지라도 다른 팀원들이 합류하고 책의 종류가 다양해 지면서 모임의 규모가 전사적으로 커진다면 충분히 '조직 문화', '기업 문화' 로 불리어 질 수 있는 것이다.
  
  

Pathfinding

문화는 2명 이상이어야 존재 할 수 있다.

바람직한 스타트업 개발문화의 조건

개발 문화에 대해 리서치한 이유에는 앞으로 꾸려질 개발팀에 도입하면 좋을 듯한 것들을 미리 물색하기 위함과 동시에 현재 우리 회사에 필요한 것은 없는지 알아보기 위한 것도 포함되어 있다. 허나, 내가 근무하고 있는 조직에는 이미 좋은 문화들이 도입되었고 정착되어 있었다.

• 데일리 스크럼
  매일 아침 10시에 이루어지는 전체 미팅. 전체 회의이지만 어제 한 일, 오늘 할 일, 추가적인 의논이 필요한 일들에 대해서 간단히 대화하는 시간이다.

• 월요일 오지랖 회의
  매주 월요일 오전에 실시하는 전체 회의. 지난주에 대한 간단한 회고를 하고 이번 주에 진행 할 일에 대해서 부연 설명과 함께 팀원들에게 알리는 시간이다.

• 간트 차트
  경영팀에서 선 도입 후 전사적으로 확대시킨 스케줄 차트. 우리 팀 뿐만 아니라 다른 팀원들의 주간, 월간 계획을 한 곳에서 살펴 볼 수 있도록 돕는다.

• 업무의 투명화
  슬랙의 오픈 채널들을 통해 경영팀은 무엇을 진행중인지, 마케팅은 어떤 형태로 이루어 졌는지, 컨택한 회사는 어디이고 미팅을 진행할 회사는 어디인지 등등. 갖가지 이벤트들을 당연한 듯이 투명하게 공개하고 의견을 묻고 답하는 행위가 자연스럽다.

• 수평적 관계
  '~님' 으로 호칭이 통일 되고, 지시하는 형태의 업무 방식이 아닌 필요에 의한 원하는 업무를 스스로 택하는 방식을 취하고 있다.

언뜻 보기엔 당연하기도하고 쉬워보이기도 한 방식들이지만, 의외로 많은 기업들이 흐지부지 되고 의미가 퇴색되는 등 유지에 애를 먹는다고 한다. 그렇게 되지 않기 위해 인원이 늘고 규모가 커지면 좀 더 디테일한 관리가 필요하겠지만, 이 정도를 유지하는 것만으로도 성공적이라 할 수 있겠다.

앞으로 탄생할 개발팀에도 조직 문화와 더불어 개발자들 만의 좋은 문화가 생길 텐데, 이것만큼은 꼭 있었으면 하는 세 가지 문화를 추려보았다.

• Code Review
  코드 리뷰는 성장을 바라는 개발자라면 누구나 바라는 문화가 아닐까 싶다. 본인의 코드 뿐만 아니라 타인의 코드에도 열린 마음을 갖고 코드를 분석하는 것은 팀 전체가 성장하는 알찬 시간이 될 것이다.

• Pair Coding
  페어 코딩은 두 명이 짝을 이루어 각자의 역할을 갖고 코딩을 하는 형태를 말한다. 대개 한 명은 리드를 다른 한 명은 배우는 역할인 경우가 많으며, 다른 기업에서도 신입을 가르치거나 키울 때 흔히 사용하는 방법이라고 한다.

• 포스트모템 문화
  특정 과제 완료 후 그 프로젝트 전 과정을 되돌아보면서 잘된 점이 무엇인지, 잘못된 점이 무엇인지를 살펴보는 작업을 의미한다. 개발자에게 회고는 새로운 것을 학습 하는 것 만큼이나 중요하다고 생각한다. 개인이 혼자서 회고를 하는 것보다 팀 전체의 시각에서 회고를 한다면 훨씬 더 많은 것들이 보이고 다양한 해결책들이 나올 수 있을 것이다.
  
  

Conclusion

누가 뭐래도 최고의 복지는 언제나 최고의 동료다.

• 처음에도 언급했지만, 좋은 개발 문화라는 것은 특정한 답이 정해져 있는 것이 아니다. 이번 프로젝트에서 도입했던 문화가 회고 후 사라질 수도 있고 누군가의 반대 의견에 의해 도입되지 않을 수도 있는 것이다. 개개인의 성향, 의지, 공통의 목표와 같이 다양한 의지들이 모인 상태에서 수 많은 대화와 협력을 통해 조금씩 만들어져 가는 것이 문화다.
  개인적으로, 무엇보다 중요한 것은 해당 팀 구성원의 자유의지가 아닐까 한다. 자율적인 의지가 수반되어야 본인 스스로도 스트레스 받지 않고 프로세스를 받아 들일 수 있을 것이고, 마주앉는 팀원과도 그 프로세스를 같이 함에 따라 신뢰가 생김으로써 좋은 효과와 성과를 얻을 수 있는 문화가 정착 될 수 있을 것이다.
  
  

Ref.

여러 기업의 개발 문화 참고 블로그

독특한 개발 문화들

• 오늘의 집
  칸반 보드 및 아이데이션 보드 운영. 전사 모든 팀원이 아이디어를 공유할 수 있는 현황판을 운영한다.
  개발팀을 나누고 도식화가 잘 되어 있어 각 팀이 어떤 역할을 하는지 파악이 쉽다.

• 마켓컬리
  몹 프로그래밍(몹 프로그래밍은 한 명의 드라이버와 여러 명의 프로그래머가 하나의 PC로 코딩 또는 문서화 작업을 진행하는 개발 방식으로 1:1방식인 페어 프로그래밍을 1:n으로 확장시킨 형태이다. 여기서 n은 에자일 개발팀 전체 인원수로 팀 전원이 참여한다는 것이 특징이다). 페어코딩을 활성화 하여 적용함.

• 우아한 형제들
  KPT 툴을 사용하여 의견을 나누고 대안을 찾거나, 새로운 방향으로 나아가는 방식을 취했다.
  K: Keep(잘하고 있는 점, 계속 했으면 좋겠다 싶은 점)
  P: Problem(뭔가 문제가 있다 싶은 점, 변화가 필요한 점)
  T: Try(잘하고 있는 것을 더 잘하기 위해서, 문제가 있는 점을 해결하기 위해서 우리가 시도해 볼 것들)

• 요기요
  '천하제일 망함대회' 달에 한 번 전 직원이 모인 자리에서 자신이 실수했거나 망한 작업을 발표하고 그 문제에 대해 해결하는 대회가 있다. 실패를 공유하면서 실패에 대한 두려움을 없애는 데에 효과적.

• 리디북스
  포스트모템 프로세스 도입. 프로젝트를 팀 전체가 회고하면서 모든 팀원이 완전 습득에 가깝게 프로젝트를 이해하는 구도를 만듦.

• 토스
  본 것중 가장 독특한 팀 구조를 가지고 있다.
  

Silo(사일로) : Product Owner, Designer, Developer 등 약 8-9명의 메이커로 구성된 조직
Chapter(챕터) : Frontend Chapter, Backend chapter, Designer Chapter 등 같은 종류의 일을 하는 팀원들이 모인 조직
Guild(길드) : 특정 과제를 진행/해결하기 위해 결성하는 모임

• 스포티파이
  토스와 유사하지만 한 단계 더 많은 구조를 가지고 있다.
  

Agile Manifesto - 애자일 선언문

우리는 소프트웨어를 개발하고,
또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.