작업 분해와 역할

"신청 앱 완성"이라는 일을 한 사람에게 통째로 맡겼더니, 코드는 있는데 취소 정책을 정하지 않았고 실행 안내도 빠져 있었습니다. 기능의 이름만으로 계획을 세우면 정책을 합의하는 일과 결과를 확인하는 일이 빠지기 쉽습니다. 이 글에서는 프로젝트의 범위를 확인할 수 있는 작업으로 나누고, 작업마다 누가 만들고 누가 확인할지 정하는 방법을 다룹니다.

범위를 작업으로 나누는 WBS

작업 분해 구조(work breakdown structure, WBS)는 프로젝트의 전체 범위를 관리할 수 있는 크기의 작업으로 차례차례 나눈 구조입니다. 화면의 기능 메뉴와 달리, 정책을 확인하는 일, 테스트, 문서, 배포 준비처럼 결과물을 만들기 위해 필요한 모든 일을 담습니다. 가장 아래 단계의 작업 묶음은 맡을 사람과 완료를 판단할 조건을 정할 수 있을 만큼 구체적이어야 합니다.

신청 기능을 "정원 검사 코드 작성" 하나로만 적지 않습니다. 정책 확정, 상태 모델, 함수 구현, 끝값 테스트, 안내 문구, 저장 방식이 모두 신청이라는 기능을 완성하는 데 필요한 서로 다른 작업입니다. 작업을 타자를 치는 수준까지 잘게 나누면 관리하는 데 드는 비용이 커지고, 너무 크게 두면 어디에서 늦어지는지 찾기 어렵습니다.

그림처럼 한 기능의 정책 합의, 코어 제작, 인수 확인은 앞 작업의 결과를 다음 작업이 넘겨받는 서로 다른 작업입니다. 작업 계획은 다음과 같은 표로 적어 둘 수 있습니다.

| 작업 | 입력과 전제 | 완료 조건 | 만드는 사람 / 확인하는 사람 |
| --- | --- | --- | --- |
| 중복 정책 확정 | 진행자가 겪은 사례 | R3 수락 조건 승인 | 업무 담당 / 진행자 |
| 신청 함수 제작 | 유효한 상태라는 전제 | 결과 코드와 상태가 요구 표와 일치 | 개발자 / 코드 검토자 |
| 끝값 테스트 | 정원과 아이디의 조건 | 끝값과 거절 사례 통과, 확인한 범위 기록 | 테스트 담당 / 개발자 |
| 안내 문구 확인 | 결과 코드 표 | 결과마다 다음 행동이 드러나는 안내 | 문서 담당 / 사용자 |

책임과 권한을 함께 정한다

책임(responsibility)은 어떤 결과를 만들거나 결정해야 하는 의무이고, 권한(authority)은 그 결정을 실제로 내릴 수 있는 범위입니다. 개발자가 구현 중에 정원 정책을 바꾸어도 되는지가 분명하지 않으면, 나중에 진행자가 다르게 결정해 다시 작업하게 됩니다. 그래서 책임을 맡기면서 그에 맞는 권한도 함께 정해 둡니다.

작업마다 누가 실행하고(responsible), 누가 최종 결정을 내리며(accountable), 누구와 상의하고(consulted), 누구에게 알리는지(informed)를 표로 정리한 것을 RACI 표라고 합니다. 한 사람이 여러 역할을 맡더라도, 사용자의 관점에서 확인하는 일과 코드의 관점에서 확인하는 일은 구분해 기록합니다.

조직의 형태가 협업에 주는 영향

기능별 조직(functional organization)에서는 구성원이 개발, 테스트, 운영 같은 전문 부서에 속해 일합니다. 전문 지식을 나누기 쉽지만, 프로젝트의 우선순위가 부서 사이에서 부딪칠 수 있습니다. 프로젝트 조직(projectized organization)은 한 프로젝트의 결과를 위해 팀을 따로 꾸리므로 결정이 빠를 수 있지만, 다른 프로젝트와 사람이나 지식을 나누기 어렵습니다. 매트릭스 조직(matrix organization)은 구성원이 전문 부서와 프로젝트 양쪽에 속하는 형태로, 두 쪽의 지시가 부딪칠 때 무엇을 먼저 따를지 분명히 정해 두어야 합니다.

작은 모임 앱이라면 한 사람이 개발과 테스트를 모두 맡더라도, 사용자 정책의 확인은 진행자에게 받아야 할 수 있습니다. 규모가 커지면 모듈별, 기능별, 기간별로 일을 나누는 방식마다 장단점도 달라집니다. 어떤 조직 형태를 고르든 그 이름만으로 소통에 드는 비용이 사라지지는 않습니다.

완료 확인이 빠진 작업을 찾는다

작업 목록을 데이터로 적어 두면, 완료를 확인한 기록이 빠진 작업을 기계적으로 찾을 수 있습니다. 다음 코드는 일정 관리 도구가 아니라, 확인 기록이 비어 있는 작업을 골라내는 작은 목록입니다.

const work = [
  { id: "policy", doneWhen: "R3 수락 조건 승인", checked: "진행자 승인 기록" },
  { id: "implementation", doneWhen: "결과 코드와 상태가 요구 표와 일치", checked: "코드 검토 기록" },
  { id: "test", doneWhen: "끝값과 거절 사례 통과", checked: "" },
  { id: "guide", doneWhen: "결과 코드마다 안내 문구", checked: "안내 문구 검토 기록" },
];
const unchecked = work.filter((item) => !item.checked).map((item) => item.id);
console.log("확인 기록이 없는 작업:", unchecked.join(", "));

확인 기록이 없는 작업: test

checked가 빈 문자열인 test 작업만 골라졌습니다. 빈 문자열은 조건식에서 거짓으로 취급되므로 !item.checked가 참이 되기 때문입니다. 다만 이 목록은 기록이 있는지만 볼 뿐, 그 기록의 내용이 완료 조건을 정말 만족하는지는 알려 주지 않습니다. 실제 계획에서는 확인 기록의 내용과 대상의 버전, 누가 검토했는지까지 살펴야 하며, 파일이 존재한다는 사실만으로 확인을 마쳤다고 세지 않습니다.

정리

• 작업 분해 구조는 프로젝트의 범위를 관리할 수 있는 작업으로 나눈 것으로, 정책 확인, 테스트, 문서처럼 기능 메뉴에 없는 일까지 담습니다.
• 가장 아래 단계의 작업은 맡을 사람과 완료 조건을 정할 수 있을 만큼 구체적이어야 하며, 너무 잘게 나누어도 관리 비용이 커집니다.
• 책임은 결과를 만들거나 결정할 의무이고 권한은 그 결정을 내릴 수 있는 범위이므로, 함께 정해야 다시 작업하는 일을 줄일 수 있습니다.
• 기능별, 프로젝트, 매트릭스 조직은 전문성의 공유, 결정의 속도, 지시의 충돌에서 서로 다른 장단점이 있습니다.
• 완료 여부는 기록이 있는지뿐 아니라 그 내용이 완료 조건을 만족하는지로 판단합니다.

연습 문제

1. 두 담당자의 충돌

테스트 담당은 취소 기능의 회귀 테스트가 없어 인수를 미루자고 하고, 프로젝트 담당은 버튼이 완성되었으니 완료로 처리하자고 합니다. 작업 분해와 결정의 책임에서 무엇이 빠졌는지, 이 갈등을 풀려면 무엇을 기록해야 하는지 설명하세요.

2. 작업의 크기

다음 작업 목록에서 너무 크거나 너무 작은 작업을 찾아 고치세요. ㉠ 신청 앱 완성 ㉡ register의 세 번째 줄에 세미콜론 넣기 ㉢ 마감 뒤 취소 정책을 진행자와 확정 ㉣ 정원의 끝값 테스트 작성

3. 확인 기록이 있으면 완료일까

본문 목록에서 implementation의 checked가 "core.mjs"처럼 파일 이름만 적혀 있었다면, 이 작업을 완료로 보아도 될까요? 무엇을 더 확인해야 하는지 적으세요.

작업을 나누었다면 그 작업에 얼마나 많은 노력이 들지도 가늠해야 합니다. 다음 글 규모·비용 추정의 가정에서는 작업의 규모를 숫자로 나타낼 때 어떤 가정을 함께 남겨야 하는지 다룹니다.