'동료 주도 개발'은 동료와 협업하여 같은 목적을 향해 달려갈 때 어떤 일을 우선으로 할 것인가에 대한 컨셉이라고 말할 수 있다. 이하 CDD(Coworker-driven development)라고 칭해본다. CDD는 함께 협력하는 동료의 관점에서 개발을 바라보게 하고, 동료가 가장 효율적이고 효과적으로 협업할 수 있는 방향으로 우리를 이끈다. 뿐만 아니라 CDD는 그것을 실천하는 우리 자신에게 많은 유익을 가져다 준다. 이 글에서는 나의 개인적인 동료 주도 개발 실천 사례와 그로 인해 서로에게 어떤 유익이 있었는지 정리해 본다. 나는 서버 개발자이고 동료는 프론트엔드 개발자이며 우리는 아래와 같은 단순한 기능을 함께 개발하기 시작했다.
“특정 장비의 설정 값을 사용자에게 입력받고 데이터베이스에 저장한다.”
1. 동료가 나에게 의존하는 일을 찾는다
서버 개발자인 나는 프론트엔드 개발자와 함께 위 기능을 사용하는 사용자의 스토리를 분석하고 그에 따른 프론트엔드 개발자의 상세 업무 그리고 프론트엔드 개발에서 서버에 의존하는 업무를 식별한다. 아래와 같이 간단히 정리할 수 있다.
2. 우리는 외부의 이벤트에 의해 움직인다
위와 같은 작업은 얼핏 보기에 동료(프론트엔드)가 나(서버)에게 필요한게 뭔지를 분석한 것 같지만, (동전을 뒤집어 보면) 내가 해야할 일의 최상위 수준 요구사항을 분석한 것이 된다. 생각해보면 서버 혼자 무언가 실행되는 경우는 없다. 서버는 어떤 입력에 반응하고 외부에 출력을 주기 위해 존재한다. 그래서 외부와의 접점을 발견하는 일은 중요하다. 외부와의 접점은 곧 자신의 시작점이 되기 때문이다. 시작점을 발견하고 시작점에서 뻗어나가면 우리는 불필요한, 시작점과 연결되지 않을 일에 시간을 낭비하지 않을 수 있다.
여기까지는 서버에 대한 프론트엔드의 기능적 의존도였다면 아래 부터는 서버 개발자의 작업 결과에 의존하는 프론트엔드 개발자의 의존을 찾아서 먼저 해결해주는 방향을 제시한다.
3. 먼저 스펙 정의하기
이제 서버와 프론트엔드 간 통신 스펙을 구체화하고 그것을 문서로 먼저 정리한다. 여기서 ‘먼저’라는 단어에 방점을 찍는다. 프론트엔드 개발자는 구체적인 통신 스펙 문서가 정의되기 전에는 서버와 연동하는 코드를 작성할 수 없다. 이 글의 흐름이 너무 자연스럽게 느껴질 수 있지만 현업에서는 내가 코드를 먼저 작성하고 내가 개발 완료한 모듈을 공개하며 문서를 함께 공개하는 경우가 훨씬 많은 듯 하다. 그렇게 되면 동료는 나를 기다리는 시간이 생기고, 해당 기능 구현에 대한 몰입도가 떨어질 수 있다. 나(서버)의 경우에는 문서를 작성하며 내가 해야할 일들을 구체화할 수 있고, 업무 가시화를 통해 내가 가진 개념들의 오류를 수정하는 기회가 되기도 한다.
4. 접점(인터페이스)을 먼저 구축한다.
통신 스펙이 정의되었다면 이제 어떤 일을 먼저 해야할까? 다음 우선순위는 프론트엔드 동료가 코드를 작성하며 즉시 테스트할 수 있도록 통신 API 인터페이스를 먼저 구현하는 것이다. REST API를 사용한다면 REST Controller를 구현하고 고정된 어떤 값들을 모의하여 고정적으로 던져주도록 구현해 둔다. 그러면 동료는 아직 완성되지는 않았지만 서버로 요청을 보내고 응답을 받을 수 있고, 고정된 어떤 값으로 화면을 처리하는 코드를 먼저 작성하고 테스트할 수 있다. 나 역시 외부와의 접점이 되는 코드를 먼저 작성해 두면 뒤에 언급하겠지만 구현 즉시 테스트할 수 있고, 구현 즉시 동료로 부터 피드백을 받을 수 있어서 유익하다.
5. 브랜치 전략
서버 API의 구체적인 구현에 앞서 주의할 부분은 내가 코드를 작성하고 관리하는 브랜치와 동료가 테스트에 사용하는 협업 브랜치를 분리하는 것이다. 동료는 빌드되고 테스트 가능한 깨끗한 상태의 협업 브랜치에서 지속적으로 테스트를 수행할 수 있어야 한다. 나 역시 하위 기능 단위로 브랜치를 관리하면 기능 한 가지에 집중하는 효과를 얻을 수 있다. 경험상 개발을 하다보면 나도 모르게 이 기능 저 기능 코딩을 왔다갔다 하는 경우가 생기는데, 기능 별로 브랜치를 관리하면 해당 기능에만 의도적으로 집중하는 효과를 얻을 수 있다.
6. 실행(테스트) 가능한 최소 단위로 점진적 통합
이 후 부터는 하위 기능들에 대한 코드가 작성되고 빌드되며 단위 테스트가 완료되는 대로 점진적으로 협업 브랜치로 통합해야 한다. 이번에도 역시 모든 하위 기능이 구현 완료되면 통합한다는 생각은 버린다. 최소 단위로 하위 기능을 개발하고 테스트를 통과시키고 협업 브랜치에 통합해 나간다.
7. 구현 즉시 테스트, 즉시 피드백
접점(인터페이스) 인프라를 먼저 구축하고, 브랜치 단위로 점진적인 개발과 통합을 실천하면 동료는 물론이고 나 역시 하위 기능을 구현하는 즉시 테스트가 가능하고, 즉시 동료로 부터 피드백을 받아 빠르게 오류를 수정할 수 있다. 반대로 내가 전체 개발을 완료하고 통합하고 이후에 동료가 전체 테스트를 시작하면 내가 다른 일을 하고 있을 때 피드백을 받게 되는데 그렇게 되면 나 또한 업무 흐름이 꼬이고 몰입에 방해가 된다.
마치며
위와 같은 동료 주도 개발의 흐름을 실천하는데는 사실 많은 노력이 필요하다. 글로 읽을 때에는 무척 자연스러운 흐름 같지만 실제로 (내가 경험하기에) 이와는 반대로 자기 중심적으로 움직이는데 우리 몸이 더 자연스러울 때가 많다. 그러나 조금만 노력하고 습관이 되게 해보자. 달리는 마차에 바퀴를 갈아 뀌우는 것 같은 환경에서 기민하게 몰입하고 서로 피드백을 주고 받으며 개발할 수 있는 좋은 방법 중 하나가 될 것이라고 확신한다. 동료 주도 개발을 실천하면 덤으로 동료와 협업하는 아름다운 하모니를 느껴볼 수 있을 것이다.
