협업 운영: WBS·RACI·의사결정·변경 관리

01협업 문서가 해결하는 문제

• 공유해야 하는 상태팀원이 각자 장비를 설정해도 서로 다른 주소표와 서비스 이름을 사용하면 통합 단계에서 동작하지 않는다.

  • 채팅으로 합의한 차단 정책이 설정 담당자에게 전달되지 않거나, 작업은 끝났지만 시험 담당자가 환경 변경을 모르면 같은 문제가 반복된다.
  • 협업 문서는 작업 자체뿐 아니라 팀 사이의 기대 상태를 맞추는 기준점이다.
• 문서와 실제 작업문서의 목적은 모든 대화를 보관하는 데 있지 않다.

  • 누가 어떤 결정을 내렸고, 무엇을 언제까지 넘기며, 받은 사람이 어떤 기준으로 확인하는지가 남아야 한다.
  • 회의록에 “보안 강화”라고 쓰기보다 대상 서비스, 변경 범위, 승인자, 적용 시각, 정상 기능의 보존 기준을 적으면 구현과 검토를 연결할 수 있다.

02협업 작업을 완료하는 단계

1. 결과물 합의목표를 검토할 수 있는 산출물로 나누고 각 작업의 완료 기준을 정한다.
2. 역할과 의존성 지정수행·최종 책임·협의·통보 대상을 나누고 선행 작업과 승인 경계를 기록한다.
3. 실행과 상태 공유진행 결과, 차단 요인, 도움 요청과 다음 작업을 근거와 함께 갱신한다.
4. 이슈와 변경 결정변경 이유·대안·영향·결정자·재검토 조건을 남긴다.
5. 검토와 인계동작·시험·문서 기준을 확인하고 다음 담당자가 결과를 사용할 수 있는지 검증한다.

03WBS는 검증 가능한 결과물까지 분해하기

• 결과물 중심 분해Work Breakdown Structure는 프로젝트 범위를 더 작은 구성 요소로 나누는 구조다.

  • 요구사항, 설계, 구현, 시험, 인계처럼 큰 묶음 아래에 결과물을 갖는 작업을 둔다.
  • “서버 구축” 하나로 두면 패키지·계정·서비스·인증·백업·로그 중 어디까지 끝났는지 알기 어렵다.
  • “서비스 계정과 파일 접근 경계 구성”처럼 결과가 명확한 항목으로 나누면 완료 판정이 가능하다.
• 작업의 완료 기준WBS 자체가 일정표는 아니다.

  • 분해한 작업에 기간과 선행 관계를 붙여야 일정이 된다.
  • 인증서 이름 확정이 늦어지면 웹·메일의 TLS 시험도 지연되는 것처럼, 다른 담당자가 제공해야 할 입력을 선행 조건으로 표시한다.
  • 하위 작업의 개수만으로 진행률을 계산하면 난이도와 검토 시간을 왜곡할 수 있으므로 실제 산출물 상태도 함께 본다.

05RACI로 역할과 승인 경계를 분명히 하기

• R·A·C·IResponsible은 실제 수행 역할, Accountable은 결과의 최종 책임과 승인, Consulted는 결정 전에 의견을 구할 역할, Informed는 결정·결과를 전달받는 역할이다.

  • 같은 사람이 여러 역할을 맡을 수 있지만 수행자가 누구인지와 최종 판정자가 누구인지는 구분되어야 한다.
  • 한 작업의 최종 책임을 명확히 두면 팀 사이에 완료 판정이 떠다니는 일을 줄인다.
• 승인과 실행의 경계방화벽 정책 변경을 예로 들면 네트워크 담당자가 적용하고 서비스 소유자가 영향 검토에 참여하며 정해진 변경 승인자가 승인한다.

  • 관제 담당자는 변경 시간과 예상 로그를 전달받는다.
  • 기술적으로 설정할 권한이 있다는 사실이 정책 변경을 결정할 권한까지 뜻하지는 않는다.
  • 작은 실습 팀에서도 이 구분을 문서에 표현하면 역할 분담을 설명하기 쉽다.

06상태와 차단 요인을 구분해 보고하기

• 진행과 차단 요인대기·진행·검토·완료는 작업의 흐름을 나타내고, 차단됨은 어느 상태에서든 다음 단계로 갈 수 없는 조건이다.

  • 검토 후에 반드시 차단 상태를 거치는 순서는 아니다.
  • 차단 항목에는 필요한 결정이나 자료, 요청한 상대 역할, 지연 시 영향을 받는 작업을 적는다.
  • “아직 안 됨”은 원인과 다음 행동을 전달하지 못한다.
• 상태 보고의 필드상태 보고는 완료, 현재 작업, 차단 요인, 다음 작업, 위험을 분리한다.

  • 구현 완료와 시험 통과를 같은 칸에 쓰지 않는다.
  • 소스가 합쳐졌더라도 배포 환경에서 확인하지 않았다면 그 상태를 드러내야 한다.
  • 검토자는 설명과 코드, 시험 결과가 같은 버전을 가리키는지 확인하고 완료 상태로 이동시킨다.

작업: 로그 수집기 출력 형식 통일
담당: 수집 담당 / 검토: 분석 담당
선행 조건: 필수 필드·시간 형식 승인
완료: 정상 이벤트와 파싱 실패가 구분되어 저장됨
현재: 구현 완료, 통합 검토 대기
차단 요인: 대상 서비스의 샘플 로그 미수신
요청: 샘플 제공 역할과 기한 명시
산출물: 코드 버전·시험 ID·필드 정의서

프로젝트 문서 작성 연습용 예시. 실제 수행 결과가 아니다.

07Decision Log는 이유와 재검토 조건을 남기기

• 결정과 이유결정 로그에는 문제, 가능한 대안, 선택, 근거, 영향, 재검토 조건을 적는다.

  • 특정 배포판을 택했다는 사실만 남기면 뒤에 참여한 사람이 선택 이유를 알 수 없다.
  • 필요한 기능과 지원 패키지, 팀의 구성 경험, 자원과 일정 제약을 근거로 남기면 대안이 더 적합해지는 조건도 설명할 수 있다.
• 재검토 조건네트워크 구획·관제 시스템 연결·보안정책 전달 범위를 결정할 때도 선택 이유와 재검토 조건을 남긴다.

  • 이런 합의는 대화가 끝난 뒤 주소표·정책 명세·작업 이슈에 반영되어야 한다.
  • 회의록과 기준 문서가 다르면 어느 쪽을 따를지 혼란이 생긴다.
  • 승인된 버전과 효력 시점을 표시해 다음 작업의 입력이 한곳을 가리키게 한다.

08Risk·Issue·Dependency를 다른 항목으로 다루기

• Risk·Issue·DependencyRisk는 아직 발생하지 않았지만 목표에 영향을 줄 수 있는 사건이다.

  • Issue는 이미 발생해 해결이 필요한 문제다.
  • Dependency는 다른 작업 결과가 있어야 진행할 수 있는 관계다.
  • 인증서 발급이 늦어질 수 있다는 것은 위험이고, 실제 발급이 지연된 상태는 이슈이며, TLS 시험이 인증서에 의존한다는 것은 의존성이다.
• 추적과 에스컬레이션위험에는 발생 가능성과 영향, 예방 방법, 발생 후 대응, 담당자를 기록한다.

  • 이슈에는 재현 조건과 현재 영향, 임시 조치, 해결 기한과 결정 요청을 적는다.
  • 팀원이 부족하다는 막연한 표현보다 어떤 역할의 어떤 검토가 언제까지 필요한지를 적어야 범위 축소나 일정 조정 같은 선택을 할 수 있다.

10변경 관리와 완료 정의

• 변경의 영향범위·설계·일정이 바뀌면 요청 → 영향 분석 → 승인 또는 거절 → 기준 문서 갱신 → 작업·시험 수정 → 공유 순으로 관리한다.

  • 긴급 대응에서도 사후에 실제 변경과 이유, 복구 방법을 남겨야 다음 담당자가 현재 상태를 이해할 수 있다.
  • 영향 분석은 수정 파일뿐 아니라 통신 경로, 계정, 관제 규칙, 문서, 재시험에 미치는 범위를 포함한다.
• 완료 정의와 검토완료 정의에는 결과물, 검토, 정상·실패 시험, 문서와 인계가 함께 들어간다.

  • 회고의 개선 항목도 “소통 강화” 대신 “정책 명세에 방향·대상·예외·재시험 항목을 추가”처럼 행동으로 바꾼다.
  • 담당자와 기한이 없는 회고는 다음 프로젝트에서 같은 문제를 막기 어렵다.