<div id="readability-page-1" class="page"><div><p><img src="https://media.vlpt.us/images/joosing/post/1d889e62-1543-436c-b96b-cb89f87fbb6d/%ED%98%91%EC%97%85.png"></p>
<h2 id="cddcoworker-driven-development">CDD(Coworker-driven development)</h2>
<p>개발에 관심이 많다면 TDD(Test-driven development), DDD(Domain-driven design) 라는 용어를 한 번 쯤 들어보았을 것이다. 그렇다면 그들은 무엇을 말하는 것일까? 그들은 어떤 특별한 관점에 대해 말하고, 관점의 변화로 부터 새로운 행동의 변화를 이끈다. 그리고 그것이 개발하는(디자인하는) 좋은 방법 중 하나라고 소개한다. TDD는 소프트웨어 개발을 테스트라는 관점으로 바라보도록 한다. 그래서 테스트 코드를 먼저 작성하고, 테스트가 용이한 코드들을 점진적으로 작성하며 소프트웨어가 개발되어 가도록 이끈다. 그리고 그것이 결국 개발을 잘하는 한 가지 방법이라고 소개한다. DDD는 무엇인가? DDD는 소프트웨어 설계를 도메인이라는 관점으로 바라보도록 한다. 그래서 도메인의 특성이 설계에 반영되도록 이끈다. 그리고 그것이 설계를 잘하는 한 가지 방법이라고 소개한다. 그렇다면 CDD(Coworker-driven development)는 무엇인가? <strong>CDD는 함께 협력하는 동료의 관점에서 개발을 바라보게 하고, 동료와 가장 효율적이고, 효과적으로 협업하는 행동으로 우리를 이끈다.</strong> 다음 사례를 통해 CDD에 한 걸음 더 가까이 나아가 보자. </p>
<h2 id="사례-소개">사례 소개</h2>
<p>우리는 특정 장비를 제어하는 기능을 개발하고 있다. 나는 API 서버 파트를 담당하고 있고, 동료는 Web UI를 담당하고 있다. Web과 API 서버는 REST API로 인터페이스 한다. </p>
<h3 id="cdd-적용-전-사고">CDD 적용 전 사고</h3>
<p>“나는 개발을 시작하며 장비 제어 모듈을 완벽히 구현한 뒤에 동료에게 API를 열어주려 한다. 왜냐하면 내 파트가 어설프게 구현된 상태에서 서비스를 열어주면 ‘이것 안된다 저것 안된다’ 하며 서로 개발 시간이 낭비될 것 같기 때문이다. 내 모듈이 완벽히 구현된 이후에 동료에게 API를 열어주는게 좋겠다.” </p>
<h3 id="cdd-기반-사고">CDD 기반 사고</h3>
<p>“나는 개발을 시작하며 동료가 나와 함께 개발을 시작할 수 있도록 REST API 스펙부터 정의하고 동료와 함께 리뷰를 한다. 그리고 아무 처리도 아직 해주지 않는 껍데기 뿐인 REST Controller를 정의하고 수신한 요청에는 고정된 응답 메시지를 전달해서 동료가 어떤 상태 값을 확인할 수 있도록 구현해 둔다. 그리고 나는 feature 브랜치를 따서 작업을 시작한다. 동료는 아무런 구체적인 동작을 하지 않지만 요청-응답을 테스트 해볼 수 있는 기존 브랜치에서 계속 작업을 한다. 나는 개발을 진행하며 하나씩 기능이 완성될 때 마다 동료가 작업하고 있는 브랜치에 내 코드를 병합하고 동료에게도 이 사실을 알려준다. ” </p>
<h2 id="얻게-된-것">얻게 된 것</h2>
<h3 id="web-ui-개발자">Web UI 개발자</h3>
<p>“Web은 API 서버 인터페이스에 의존하게 된다. API 인터페이스가 정해져 있지 않았다면 나는 다음 작업을 할 수 없고, 대기하는 동안 다른 일을 왔다 갔다 해야 했을테다. 동료가 인터페이스를 먼저 정의해 준 덕분에 한 가지 일에 쭉 집중할 수 있었다. 그리고 더미 응답을 던져 준 덕분에 완벽하지 않지만 일단 요청을 날려보고 응답도 받아 보며 내 코드를 테스트할 수도 있었다. 내가 API 연동 부분을 작성하는 동안 동료가 기능 하나씩을 브랜치에 병합하며 테스트할 수 있다고 알려줬다. 거의 내 업무 흐름과 유사하게 흘러 가는 것 같다. 나도 동료에게 빠르게 피드백을 주며 서로 잘못된 부분을 지속적으로 고쳐 나갔다.” </p>
<h3 id="api-서버-개발자">API 서버 개발자</h3>
<p>“내가 개발하는 API 서버의 첫번째 사용자는 Web UI 개발 동료이다. 사용자의 인터페이스를 먼저 정의하며 사용자 입력에 대한 출력을 생각하다 보니 사용자 관점에서 시스템의 전체 흐름이 선명해 진다. 덕분에 장비와 통신하는 기능 자체에 지나치게 함몰되지 않고 지속적으로 사용자와의 연동을 생각하게 된다. 또한 Web과 인터페이스 먼저 구현해 놓다보니 API 세부 구현을 한 후 즉시 테스트가 가능하고, 즉시 피드백을 받을 수 있다. 만약 내가 API를 완벽히 구현한 후, Web 파트 개발을 시작했다면 나는 다른 기능을 개발하는 동안 피드백을 받고 수정사항이 발생하여 다른 일을 하는 중간에 업무 스위치가 발생했을 것이다.” </p>
<h2 id="결론">결론</h2>
<p>CDD는 개발의 전 영역에서 함께 협력하는 동료의 관점에서 개발을 바라보고 협업하기 좋은 방향으로 우리의 행동을 변화함으로 실천할 수 있다. <strong>우리는 CDD를 실천함으로 효율적이고 함께 일하기 즐거운 팀을 만들 수 있다고 확신한다.</strong> 위 사례는 작은 분야의 일부 사례일 뿐인데, 내가 경험하지 못할 다른 파트의 실천도 많이 공유되었으면 하는 바램이다.</p></div></div>

Joo's Work

JooSing

CDD(Coworker-driven development)
개발에 관심이 많다면 TDD(Test-driven development), DDD(Domain-driven design) 라는 용어를 한 번 쯤 들어보았을 것이다. 그렇다면 그들은 무엇을 말하는 것일까? 그들은 어떤 특별한 관점에 대해 말하고, 관점의 변화로 부터 새로운 행동의 변화를 이끈다. 그리고 그것이 개발하는(디자인하는) 좋은 방법 중 하나라고 소개한다. TDD는 소프트웨어 개발을 테스트라는 관점으로 바라보도록 한다. 그래서 테스트 코드를 먼저 작성하고, 테스트가 용이한 코드들을 점진적으로 작성하며 소프트웨어가 개발되어 가도록 이끈다. 그리고 그것이 결국 개발을 잘하는 한 가지 방법이라고 소개한다. DDD는 무엇인가? DDD는 소프트웨어 설계를 도메인이라는 관점으로 바라보도록 한다. 그래서 도메인의 특성이 설계에 반영되도록 이끈다. 그리고 그것이 설계를 잘하는 한 가지 방법이라고 소개한다. 그렇다면 CDD(Coworker-driven development)는 무엇인가? CDD는 함께 협력하는 동료의 관점에서 개발을 바라보게 하고, 동료와 가장 효율적이고, 효과적으로 협업하는 행동으로 우리를 이끈다. 다음 사례를 통해 CDD에 한 걸음 더 가까이 나아가 보자. 
사례 소개
우리는 특정 장비를 제어하는 기능을 개발하고 있다. 나는 API 서버 파트를 담당하고 있고, 동료는 Web UI를 담당하고 있다. Web과 API 서버는 REST API로 인터페이스 한다. 
CDD 적용 전 사고
“나는 개발을 시작하며 장비 제어 모듈을 완벽히 구현한 뒤에 동료에게 API를 열어주려 한다. 왜냐하면 내 파트가 어설프게 구현된 상태에서 서비스를 열어주면 ‘이것 안된다 저것 안된다’ 하며 서로 개발 시간이 낭비될 것 같기 때문이다. 내 모듈이 완벽히 구현된 이후에 동료에게 API를 열어주는게 좋겠다.” 
CDD 기반 사고
“나는 개발을 시작하며 동료가 나와 함께 개발을 시작할 수 있도록 REST API 스펙부터 정의하고 동료와 함께 리뷰를 한다. 그리고 아무 처리도 아직 해주지 않는 껍데기 뿐인 REST Controller를 정의하고 수신한 요청에는 고정된 응답 메시지를 전달해서 동료가 어떤 상태 값을 확인할 수 있도록 구현해 둔다. 그리고 나는 feature 브랜치를 따서 작업을 시작한다. 동료는 아무런 구체적인 동작을 하지 않지만 요청-응답을 테스트 해볼 수 있는 기존 브랜치에서 계속 작업을 한다. 나는 개발을 진행하며 하나씩 기능이 완성될 때 마다 동료가 작업하고 있는 브랜치에 내 코드를 병합하고 동료에게도 이 사실을 알려준다. ” 
얻게 된 것
Web UI 개발자
“Web은 API 서버 인터페이스에 의존하게 된다. API 인터페이스가 정해져 있지 않았다면 나는 다음 작업을 할 수 없고, 대기하는 동안 다른 일을 왔다 갔다 해야 했을테다. 동료가 인터페이스를 먼저 정의해 준 덕분에 한 가지 일에 쭉 집중할 수 있었다. 그리고 더미 응답을 던져 준 덕분에 완벽하지 않지만 일단 요청을 날려보고 응답도 받아 보며 내 코드를 테스트할 수도 있었다. 내가 API 연동 부분을 작성하는 동안 동료가 기능 하나씩을 브랜치에 병합하며 테스트할 수 있다고 알려줬다. 거의 내 업무 흐름과 유사하게 흘러 가는 것 같다. 나도 동료에게 빠르게 피드백을 주며 서로 잘못된 부분을 지속적으로 고쳐 나갔다.” 
API 서버 개발자
“내가 개발하는 API 서버의 첫번째 사용자는 Web UI 개발 동료이다. 사용자의 인터페이스를 먼저 정의하며 사용자 입력에 대한 출력을 생각하다 보니 사용자 관점에서 시스템의 전체 흐름이 선명해 진다. 덕분에 장비와 통신하는 기능 자체에 지나치게 함몰되지 않고 지속적으로 사용자와의 연동을 생각하게 된다. 또한 Web과 인터페이스 먼저 구현해 놓다보니 API 세부 구현을 한 후 즉시 테스트가 가능하고, 즉시 피드백을 받을 수 있다. 만약 내가 API를 완벽히 구현한 후, Web 파트 개발을 시작했다면 나는 다른 기능을 개발하는 동안 피드백을 받고 수정사항이 발생하여 다른 일을 하는 중간에 업무 스위치가 발생했을 것이다.” 
결론
CDD는 개발의 전 영역에서 함께 협력하는 동료의 관점에서 개발을 바라보고 협업하기 좋은 방향으로 우리의 행동을 변화함으로 실천할 수 있다. 우리는 CDD를 실천함으로 효율적이고 함께 일하기 즐거운 팀을 만들 수 있다고 확신한다. 위 사례는 작은 분야의 일부 사례일 뿐인데, 내가 경험하지 못할 다른 파트의 실천도 많이 공유되었으면 하는 바램이다.

일하는 방법 | CDD(Coworker-driven development) 컨셉과 사례 소개

댓글