brunch

매거진 민주주의 활동가 그룹 빠띠

라이킷 13 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 갱그리 Oct 13. 2017

전직원 원격 근무,
빠띠는 어떻게 개발할까

빠띠의 개발문화

빠띠는 전 직원 리모트 근무(원격 근무)를 한다. 팀원은 총 일곱 명인데 그 중 한 명은 일본에, 한 명은 제주도에 산다. 모두 다 주 5일을 근무하는 것도 아니다. 주 3일, 주 4일 근무 등 근무도 유연하다. 전 직원이 주 5일, 한 사무실에서 근무하는 것과 사뭇 다르다.

그래서 그런지, 주변에서 간혹 '빠띠에선 대체 개발을 어떻게 하냐'는 질문을 하곤 한다. 여기에 대해 따로따로 답을 주기보다, 이참에 한 번 정리하여 답변하려고 한다.

#1. 페어 프로그래밍

나는 여태 Java 와 C# 으로 개발해오다가, ‘빠띠'에 와서 처음으로 Ruby 를 배우고 있다. 처음 해 보는 개발 언어인데다가 시스템도 파악해야하고 이런저런 개발 필요성 때문에 하루 한 시간 이상은 꼬박꼬박 ‘페어 프로그래밍'을 한다. 일반적인 회사에서는 사수 옆에 붙어 앉아 짝 프로그래밍을 했다면, 우리는 원격으로 화면을 공유하여 함께 코딩한다.

나는 시니어의 문제 해결 방식을 따라갈 수 있어 좋고, 시니어는 습관적으로 해오던 방식 외의 것을 발견할 기회가 있어 유용하다고 한다. 페어 프로그래밍을 할 때에는 그냥 침묵하며 코딩하는게 아니라, 왜 그렇게 코딩하는지, 무엇을 해결해야 하는지 토론하고 협의하며 진행하기 때문에 시니어의 머릿속 깊은 곳에 있는 지식들이 쏟아져 나온다. 덕택에 내게는 어떻게 문제를 해결해나가는지 배우는 좋은 기회가 된다.

#2. ‘우리는 왜 이 프로젝트를 해야 하는가?’

어떤 프로젝트를 진행하기에 앞서, 프로젝트를 함으로써 기대되는 성취와 리스크 등을 먼저 공유하는게 인상적이다. 프로젝트를 시작하는 미팅을 일반적으로 ‘킥오프 미팅' 이라고 한다. 이전에 있던 회사에도 해 본 적은 있지만 대개 프로젝트를 진행하는 목적보다는 진행 방식과 투입되는 예산, 인력 운용 방식 등이 훨씬 중요했다.

빠띠에서는 프로젝트를 진행하는 목적에 대해 가장 공들여 토론한다. 이 프로젝트가 지니는 의미, 우리가 성취해야 할 목표, 프로젝트를 제안한 파트너가 성취했으면 하는 것들 등등.. 이 목적을 잘 잡아 놓으면 나중에 개발자가 ‘도구'처럼 개발하지 않게 된다. 가치와 목적을 이해하고 집중할 수 있고, 궁극적으로 내가 하는 일의 완성된 모습이 어디로 갈 지 파악할 수 있기 때문이다.

#3. 큰 기능도 애기 걸음부터

빠띠는 분더리스트를 활용하여 업무 리스트를 공유하고 관리한다. 그러나 사실 ‘업무'라는게 모두 다 같은 레벨일 수 없다. 예컨대 ‘시스템 UX 개편하기'는 너무 스케일이 크다. 이것을 쪼개어 ‘회원가입 화면의 버튼 스타일을 바꾸기' 정도로 등록하면 또 자잘한 업무가 너무 많아진다.

그래서 우리가 합의한 분더리스트 관리 기준은, 반나절 정도에 처리할 수 있는 일을 1개의 분더리스트라고 산정해 등록하는 것이다. 한 주의 일감도 몇 개의 분더리스트를 처리했는지로 계산한다. (우리는 n분더라고 부른다. 예컨대 '그 일은 2분더 정도 걸리겠습니다' 이렇게) 몇 번의 시행착오를 거쳐 개발팀이 한 주에 처리할 수 있는 분더의 기준이 정해지면 다음 계획을 세울 때에도 그 갯수를 넘어가지 않게 한다.(예컨대 평균적으로 한 주에 개발 팀에서 18개의 분더를 처리할 수 있었다면, 그 다음 주에 계획을 세울 때에도 계획한 업무가 18개의 분더를 넘어가지 않게 한다)

그러므로 ‘시스템 UX 개편하기'를 목표로 정했을 때, 우리가 가장 먼저 하는 것은 그 안에서 구현이 필요한 기능들을 세분화하여 리스트업하고, 너무 쪼갠 것은 묶어서 ‘반나절 일감'으로 만드는 일이다.

그런 후에 각각의 업무에 담당자와 마감 날짜를 등록한다. 이렇게 하면 일해야 하는 것들이 선명하게 보인다. 눈에 잡히지 않는 큰 기능을 이야기하기보다 그것을 쪼개어 작은 기능으로 기획하고 개발하면 훨씬 빠르고 정확하게 일할 수 있다.

분더리스트를 간혹 이렇게 업무에 관련한 의견을 수집하는 창구로 쓰기도 한다. 완료된 건 바로 찍찍 긋는다.

#4. 반복 업무는 개선하고, 프로세스는 기록한다.

너무 당연한 것이지만, 실제 현업에서 잘 이행되지 않는 일이다. 반복적으로 실수하거나 단순 기계적 반복을 요하는 일들은 분더리스트에서 '개발 먼지'에 올라간다. 지금 당장은 티끌처럼 중요하지는 않지만, 쌓이면 건강에도 나빠진다는 의미다. 반복 업무는 '개발 먼지'에 등록하고, 최소 한 달에 한 건 이상 처리하도록 서로 독려한다.

특정 업무에 대한 프로세스나 포맷, 양식들은 모두 Quip 이라는 툴에 저장한다. Quip 은 구글 드라이브와 비슷한 공동 작성 문서인데, 코드 블럭 스타일도 가능하고 수정 이력이 선명하게 남아서 어떤 일로 어떻게 수정하였는지 한눈에 볼 수 있는 장점을 갖고 있다. 대개 개발 환경 셋팅 가이드나 주기적으로 해야 하는 SSL 인증서 반복 작업 같은 경우 모두 Quip 에 누가 와도 따라하기만 하면 될 정도로 상세히 적어 놓는다.

무엇보다, 모두가 참여하는 조직

개발자로 일하면서 내가 지금까지 가장 괴로웠던 부분은 ‘개발만' 해야 한다는 것이었다. 개발자가 관심 가져야 하는 영역은 늘 신기술이었지, 업무의 내용이나 목적, 가치는 전혀 아니었다. 지금 회사에서는 회사 모든 영역에 모두가 참여한다. 디자이너라고 디자인만 하지 않고, 개발자라고 개발만 하지 않는다. 회사의 규칙을 만들고, 어떤 프로젝트를 어떻게 진행할지 협의하고, 우리에게 어떤 가치가 필요한지 토론하며, 함께 민주주의를 공부한다.

빠띠는 완벽한 조직은 아니지만, 유연한 조직이다. 일주일에 한번씩 (온라인에서) 모여 함께 감정적으로 좋았던 일, 아쉬웠던 일을 기술하며 그 주의 분위기를 회고하는데 회고의 자리에서는 그 주의 실험해 볼 내용에 대해 서로 논의하기도 한다(이 내용은 다음 블로깅에서 더 자세히!). 주로 조직을 어떻게 실험해 볼 지에 관한 것이다. 스터디를 하기로 하거나 일하는 방식을 바꿔보자고 하거나 회의 시간을 조정하는 등 조직 내의 다양한 규칙들이 토론을 통해 자주 수정된다.