WBS란 무엇인가? TurtleBot3 ROS 2 프로젝트 적용 사례

ROS 2 기반 이동 로봇 프로젝트를 진행하다 보면 처음에는 해야 할 일이 비교적 단순해 보입니다.

TurtleBot3를 구동하고, SLAM으로 지도를 만들고, Navigation2로 목적지까지 이동시키면 기본적인 자율주행 로봇이 완성될 것처럼 보입니다.

그러나 실제 서비스 로봇을 개발하려면 다음과 같은 작업이 추가됩니다.

1. 프로젝트 요구사항 정의
2. 로봇 하드웨어 설정
3. 센서 연결
4. 지도 작성
5. 자율주행 설정
6. 카메라와 영상 처리
7. 서비스 시나리오 구현
8. GUI 개발
9. 통신 단절 대응
10. 반복 시험
11. 문서 작성
12. 발표와 시연 준비

이 작업들을 단순한 할 일 목록으로 관리하면 개발 후반에 기능 누락, 담당자 충돌, 시험 부족, 문서 미작성 등의 문제가 발생하기 쉽습니다.

이러한 문제를 줄이기 위해 사용하는 프로젝트 관리 도구가 WBS입니다.

1. WBS란 무엇인가?

WBS는 Work Breakdown Structure의 약자로, 우리말로는 작업 분해 구조라고 합니다.

WBS는 프로젝트의 전체 범위를 계층적으로 나누어 관리 가능한 작업 단위로 분해한 구조입니다.

쉽게 말하면 프로젝트를 완료하기 위해 만들어야 할 결과물을 큰 항목에서 작은 항목으로 나누어 정리한 것입니다.

예를 들어 이동 로봇 프로젝트를 다음과 같이 분해할 수 있습니다.

1. 프로젝트 관리
2. 로봇 시스템
3. 지도와 자율주행
4. 센서와 비전
5. 서비스 기능
6. 시스템 통합
7. 시험과 검증
8. 문서와 발표

각 항목은 다시 세부 작업으로 나눌 수 있습니다.

예를 들어 지도와 자율주행 항목은 다음과 같이 분해할 수 있습니다.

1. 지도 작성 계획
2. SLAM 원본 지도 생성
3. 서비스 지도 편집
4. Localization 검증
5. Navigation2 파라미터 설정
6. 경유점 작성
7. 장애물 회피 시험
8. 복구 동작 설정

WBS의 최하위 관리 단위를 작업 패키지라고 합니다.

작업 패키지는 담당자, 기간, 산출물, 완료 기준을 명확하게 지정할 수 있는 수준까지 분해해야 합니다.

2. WBS를 작성하는 이유

WBS를 작성하는 가장 큰 이유는 프로젝트의 전체 범위를 빠짐없이 관리하기 위해서입니다.

로봇 프로젝트에서는 코드 작성뿐만 아니라 하드웨어 설정, 실험, 시험 결과, 실행 스크립트, 사용자 문서까지 모두 프로젝트 범위에 포함됩니다.

WBS를 적용하면 다음과 같은 효과를 얻을 수 있습니다.

1) 작업 누락을 줄일 수 있다

기능 구현에 집중하다 보면 시험, 로그 저장, 자동 실행, 오류 대응, 문서 작성 등이 빠질 수 있습니다.

WBS에서는 프로젝트 관리부터 최종 발표까지 전체 작업을 포함하므로 누락 가능성을 줄일 수 있습니다.

2) 담당자 간 작업 경계를 명확히 할 수 있다

Navigation 담당자와 서비스 담당자가 같은 기능을 서로의 작업이라고 생각하면 일정이 지연됩니다.

WBS 작업 패키지별로 최종 책임자를 지정하면 작업 경계가 명확해집니다.

3) 완료 여부를 객관적으로 판단할 수 있다

단순히 코드가 작성되었다고 해서 작업이 완료된 것은 아닙니다.

실제 로봇에서 실행되고, 반복 시험을 통과하고, 결과가 저장되며, 실행 방법이 문서화되어야 완료된 것입니다.

4) 요구사항과 시험 결과를 연결할 수 있다

각 요구사항에 WBS ID를 연결하고, 시험 항목에도 같은 ID를 사용하면 어떤 요구사항이 구현되고 검증되었는지 추적할 수 있습니다.

5) 프로젝트 변경을 통제할 수 있다

개발 중 새로운 기능이 추가되면 관련 코드만 변경되는 것이 아닙니다.

일정, 담당자, 인터페이스, 시험 항목, 문서도 함께 변경됩니다.

WBS를 기준으로 변경 영향을 확인하면 무분별한 기능 추가를 줄일 수 있습니다.

3. WBS와 일정표의 차이

WBS와 일정표는 비슷해 보이지만 목적이 다릅니다.

WBS는 무엇을 완성해야 하는지를 정의합니다.

일정표는 언제, 누가, 어떤 순서로 수행할지를 정의합니다.

예를 들어 다음 항목은 WBS에 해당합니다.

1. SLAM 원본 지도
2. Navigation2 설정 파일
3. ArUco 검출 노드
4. Mission Manager
5. 통합 시험 결과서

다음 항목은 일정표에 해당합니다.

1. 7월 27일 SLAM 지도 작성
2. 7월 29일 Navigation2 설정
3. 7월 31일 ArUco 기능 시험
4. 8월 3일 Mission Manager 구현
5. 8월 12일 통합 시험

WBS를 먼저 작성한 다음 각 작업 패키지에 기간, 담당자, 선행 작업을 연결하면 일정표를 만들 수 있습니다.

4. WBS 작성의 핵심 원칙

1) 산출물 중심으로 작성한다

WBS는 단순한 행동 목록보다 결과물 중심으로 작성하는 것이 좋습니다.

좋지 않은 예시는 다음과 같습니다.

1. 지도 만들기
2. 센서 테스트하기
3. 코딩하기
4. 발표 준비하기

산출물 중심으로 바꾸면 다음과 같습니다.

1. SLAM 원본 지도
2. 외부 센서 시험 결과서
3. Mission Manager 노드
4. 최종 발표 자료

2) 프로젝트 전체 범위를 포함한다

WBS에는 기능 개발만 포함해서는 안 됩니다.

다음 작업도 반드시 포함해야 합니다.

1. 요구사항 관리
2. GitHub 형상관리
3. 시험과 검증
4. 오류 대응
5. 실행 환경 구성
6. README 작성
7. 발표 자료 제작
8. 시연 영상 제작

3) 작업이 중복되지 않도록 한다

하나의 작업이 여러 작업 패키지에 중복되면 담당자와 완료 기준이 불명확해집니다.

예를 들어 ArUco 검출과 ArUco 도킹은 분리하는 것이 좋습니다.

1. ArUco 검출 노드는 카메라 영상에서 마커 위치와 각도를 계산합니다.
2. ArUco 도킹 컨트롤러는 계산된 위치와 각도를 이용해 로봇을 정렬하고 접근시킵니다.

4) 관리 가능한 크기로 분해한다

4주 프로젝트에서는 작업 패키지 하나를 약 1일에서 5일 안에 완료할 수 있는 크기로 나누는 것이 적절합니다.

작업 범위가 너무 크면 진척률을 판단하기 어렵고, 너무 작으면 관리 작업이 지나치게 많아집니다.

5) 완료 기준을 수치로 작성한다

완료 기준은 가능하면 측정 가능한 형태로 작성해야 합니다.

예시는 다음과 같습니다.

1. 1m 직진 시험 10회 수행
2. 평균 직진 오차 1cm 이하
3. ArUco 인식 시험 20회 수행
4. 도킹 시험 10회 수행
5. Wi-Fi 단절 시험 5회 수행
6. 주간 안내 시나리오 10회 반복
7. 야간 순찰 시나리오 10회 반복

5. TurtleBot3 ROS 2 프로젝트 개요

이번 WBS 적용 사례의 프로젝트는 TurtleBot3 Burger 기반 사무실 안내·보안 로봇입니다.

프로젝트의 기본 조건은 다음과 같습니다.

1. 프로젝트 기간은 총 4주입니다.
2. 운영체제는 Ubuntu 22.04를 사용합니다.
3. ROS 2 Humble을 사용합니다.
4. 로봇 플랫폼은 TurtleBot3 Burger입니다.
5. 카메라는 Raspberry Pi Camera 계열을 사용합니다.
6. SLAM과 Navigation2를 이용합니다.
7. OpenCV와 ArUco를 이용한 영상 처리를 적용합니다.
8. 외부 센서를 최소 3종 이상 연결합니다.
9. PyQt 기반 운영 GUI를 개발합니다.
10. 전원 인가 후 자동 실행되도록 구성합니다.
11. Wi-Fi가 끊겨도 안전 동작을 수행해야 합니다.

6. 로봇 서비스 시나리오

사무실 안내·보안 로봇은 주간과 야간에 서로 다른 서비스를 수행합니다.

1) 주간 안내 서비스

주간에는 사무실 입구 또는 지정된 위치에서 대기합니다.

방문객이나 사용자가 안내를 요청하면 다음 절차를 수행합니다.

1. 방문객 또는 호출 신호를 감지합니다.
2. 안내 음성이나 GUI 메시지를 출력합니다.
3. 사용자가 선택한 목적지를 확인합니다.
4. Navigation2를 이용해 목적지까지 이동합니다.
5. 방문객이 따라오는지 확인하며 주행합니다.
6. 목적지 도착 메시지를 출력합니다.
7. 안내가 끝나면 대기 장소로 복귀합니다.

2) 간단한 물품 운반 서비스

소형 물품을 지정 위치 사이에서 운반할 수 있습니다.

운반 서비스는 다음 순서로 구성할 수 있습니다.

1. 운반 요청을 수신합니다.
2. 물품 수령 위치로 이동합니다.
3. 물품 적재 확인을 기다립니다.
4. 배송 위치로 이동합니다.
5. 물품 수령 확인을 받습니다.
6. 대기 위치로 복귀합니다.

4주 프로젝트에서는 안내와 순찰을 필수 기능으로 두고, 물품 운반은 확장 기능으로 설정하는 것이 현실적입니다.

3) 야간 순찰 서비스

야간에는 지정된 경유점을 순서대로 이동하며 사무실 상태를 확인합니다.

순찰 기능은 다음과 같이 구성할 수 있습니다.

1. 순찰 임무를 시작합니다.
2. 지정된 10개 이상의 경유점을 이동합니다.
3. 출입문 상태를 확인합니다.
4. 장애물이나 비정상 물체를 확인합니다.
5. 온도, 습도, 조도 등의 환경 값을 확인합니다.
6. 이상 상황이 발생하면 사진을 촬영합니다.
7. 시간, 위치, 센서값을 저장합니다.
8. 관리자 GUI에 이상 상황을 전달합니다.
9. 순찰이 완료되면 시작 위치로 복귀합니다.
10. 순찰 결과 보고서를 생성합니다.

7. TurtleBot3 ROS 2 프로젝트 WBS 상위 구조

이 프로젝트의 WBS는 8개 상위 영역으로 구성할 수 있습니다.

1) 프로젝트 관리

1. 서비스 범위 정의
2. 요구사항 작성
3. GitHub 협업 환경 구성
4. 진척 관리
5. 위험 관리
6. 변경 관리

2) 로봇 시스템

1. ROS 2 작업공간 구성
2. 팀 전용 패키지 생성
3. Team_Name Bringup
4. OpenCR 연결
5. LiDAR 연결
6. 카메라 연결
7. 외부 센서 연결
8. URDF와 TF 구성
9. 오도메트리 보정
10. 로그 저장 구조 구성

3) 지도와 자율주행

1. 지도 작성 계획
2. SLAM 원본 지도 생성
3. 서비스용 지도 편집
4. AMCL Localization 검증
5. Navigation2 설정
6. 경유점 작성
7. 주행 경로 작성
8. 장애물 회피 설정
9. 복구 동작 설정
10. 후진 안전 동작 구현

4) 센서와 비전

1. 센서 브리지 노드
2. 외부 센서 3종 연동
3. 카메라 기본 구동
4. 카메라 보정
5. ArUco 검출
6. 마커 자세 추정
7. 음성 안내
8. LED 상태 표시
9. 효과음 출력
10. PyQt 운영 GUI

5) 서비스 기능

1. Mission Manager
2. 대기 상태
3. 안내 상태
4. 운반 상태
5. 순찰 상태
6. 복귀 상태
7. 도킹 준비 상태
8. 도킹 완료 상태
9. 이상 감지
10. 증거 저장
11. 관리자 명령 처리
12. 순찰 보고서 생성

6) 시스템 통합

1. 전체 Launch 파일
2. ArUco 정밀 파킹
3. 전원 인가 자동 실행
4. 노드 실행 순서 관리
5. 노드 자동 재시작
6. Wi-Fi 단절 대응
7. Watchdog 구성
8. CPU와 메모리 최적화
9. 토픽 주기 최적화
10. 최종 파라미터 통합

7) 시험과 검증

1. 단위 시험
2. 컴포넌트 시험
3. 직진 성능 시험
4. 회전 성능 시험
5. 목표점 도착 시험
6. 좁은 통로 시험
7. 장애물 회피 시험
8. 교차 주행 시험
9. 주간 안내 시나리오 시험
10. 야간 순찰 시나리오 시험
11. 통신 단절 시험
12. 노드 종료 시험
13. 최종 인수 시험

8) 문서와 발표

1. 사용자 요구사항 문서
2. 시스템 요구사항 문서
3. 시스템 구성도
4. 소프트웨어 설계서
5. ROS 2 인터페이스 명세서
6. GUI 설계서
7. 시험 결과서
8. README
9. 설치 매뉴얼
10. 실행 매뉴얼
11. 시연 영상
12. 발표 자료
13. 최종 Release 생성
14. 프로젝트 회고

8. 주요 작업 패키지 작성 사례

1) 사용자·시스템 요구사항

WBS ID는 1.3으로 지정합니다.

주요 작업은 서비스 시나리오를 사용자 요구사항과 시스템 요구사항으로 변환하는 것입니다.

산출물은 다음과 같습니다.

1. 사용자 요구사항 문서
2. 시스템 요구사항 문서
3. 요구사항 추적표

완료 기준은 모든 요구사항에 ID, 검증 방법, 관련 WBS 번호가 등록되고 팀 검토가 완료되는 것입니다.

2) 오도메트리 보정

WBS ID는 2.3으로 지정합니다.

TurtleBot3의 wheel radius와 wheel separation 값을 보정합니다.

시험 절차는 다음과 같습니다.

1. 로봇을 1m 직진시킵니다.
2. 실제 이동 거리를 측정합니다.
3. 같은 시험을 10회 반복합니다.
4. 90도와 180도 회전 시험을 수행합니다.
5. 오차를 계산합니다.
6. 파라미터를 수정합니다.
7. 수정 전후 결과를 비교합니다.

산출물은 측정 CSV 파일, 보정 전후 비교표, 최종 파라미터입니다.

3) SLAM 원본 지도

WBS ID는 3.2로 지정합니다.

강의실과 강의실 입구 복도 일부 공간을 TurtleBot3로 주행하면서 SLAM 지도를 생성합니다.

산출물은 다음과 같습니다.

1. original_map.pgm
2. original_map.yaml
3. 지도 작성 주행 기록
4. 필요하면 rosbag 파일

완료 기준은 벽과 장애물 형상이 실제 공간과 유사하게 생성되고 지도 파일이 GitHub에 등록되는 것입니다.

4) 경유점과 주행 경로

WBS ID는 3.5로 지정합니다.

서비스에 필요한 경유점을 지도 좌표로 저장합니다.

프로젝트 요구조건에 따라 10개 이상의 경유점과 2개 이상의 주행 경로를 작성합니다.

산출물은 다음과 같습니다.

1. waypoints.yaml
2. 순찰 경로 설정
3. 안내 경로 설정

완료 기준은 모든 경유점 ID와 지도 좌표가 일치하고 2개 이상의 경로가 반복 실행되는 것입니다.

5) ArUco 검출과 정렬

WBS ID는 4.4로 지정합니다.

카메라 영상에서 ArUco 마커를 검출하고 로봇과 마커 사이의 거리와 각도를 계산합니다.

출력 정보는 다음과 같습니다.

1. 마커 ID
2. 이미지 중심 좌표
3. 마커 중심 좌표
4. 좌우 오차
5. 추정 거리
6. 추정 각도
7. 마커 검출 상태

완료 기준은 20회 이상의 인식 시험을 수행하고 조명 변화에 따른 성공률과 실패 원인을 기록하는 것입니다.

6) Mission Manager

WBS ID는 5.1로 지정합니다.

Mission Manager는 로봇의 전체 서비스 상태를 관리하는 핵심 노드입니다.

주요 상태는 다음과 같이 구성할 수 있습니다.

1. IDLE
2. GUIDE
3. DELIVERY
4. PATROL
5. RETURN
6. PRE_DOCK
7. DOCKING
8. DOCKED
9. ERROR
10. EMERGENCY_STOP

Mission Manager는 Navigation2 Action, 센서 이벤트, GUI 명령, 배터리 상태를 받아 상태를 전환합니다.

완료 기준은 임무 시작, 일시정지, 취소, 오류, 복귀 흐름이 모두 정의된 상태로 전환되는 것입니다.

7) 이상 감지와 증거 저장

WBS ID는 5.6으로 지정합니다.

외부 센서나 카메라에서 이상 상황이 감지되면 관련 정보를 하나의 이벤트로 저장합니다.

저장 항목은 다음과 같습니다.

1. 이벤트 발생 시간
2. 로봇 위치
3. 이벤트 종류
4. 심각도
5. 센서값
6. 촬영 사진 경로
7. 로그 파일 경로
8. 관리자 조치 결과

JSON 또는 CSV 형식으로 이벤트를 저장할 수 있습니다.

8) ArUco 정밀 파킹

WBS ID는 6.2로 지정합니다.

정밀 파킹은 Navigation2와 ArUco를 결합해 구현합니다.

전체 절차는 다음과 같습니다.

1. Navigation2로 도킹 대기 지점까지 이동합니다.
2. 카메라로 ArUco 마커를 탐색합니다.
3. 마커가 없으면 제자리 회전 또는 재탐색을 수행합니다.
4. 마커 중심 오차를 계산합니다.
5. 로봇의 방향을 정렬합니다.
6. 저속으로 마커에 접근합니다.
7. 최종 거리와 각도를 확인합니다.
8. 거리가 일정 범위 내에 있으면 도킹으로 처리하고 종료합니다.
9. 실패하면 후퇴 후 다시 시도합니다.

완료 기준은 10회 시험 결과와 성공률, 최종 위치 오차, 최종 각도 오차를 기록하는 것입니다.

9) 통신 단절과 노드 장애 대응

WBS ID는 6.4로 지정합니다.

서비스 로봇은 원격 PC나 Wi-Fi 연결이 끊어져도 위험한 동작을 해서는 안 됩니다.

시험 항목은 다음과 같습니다.

1. 주행 중 Wi-Fi 연결 해제
2. GUI 강제 종료
3. Mission Manager 종료
4. 센서 노드 종료
5. Navigation2 노드 종료
6. 로봇 컴퓨터 재부팅
7. 전원 재인가

완료 기준은 Wi-Fi 해제 5회와 핵심 노드 종료 5회에서 정의된 안전 동작이 수행되는 것입니다.

9. 4주 프로젝트 일정 사례

1) 1주차 범위와 기본 시스템

1주차 목표는 프로젝트 범위를 확정하고 TurtleBot3 기본 시스템을 구동하는 것입니다.

주요 작업은 다음과 같습니다.

1. 프로젝트 목표 정의
2. 서비스 시나리오 작성
3. 사용자 요구사항 작성
4. 시스템 요구사항 작성
5. 역할 분담
6. GitHub 저장소 구성
7. ROS 2 작업공간 구성
8. TurtleBot3 Bringup
9. 카메라와 센서 연결
10. 오도메트리 1차 측정

1주차 마일스톤은 프로젝트 범위 설정 및 기본 기능 일부 테스트입니다.

2) 2주차 핵심 기술 검증

2주차 목표는 지도, 자율주행, 센서, 비전 기능을 각각 검증하는 것입니다.

주요 작업은 다음과 같습니다.

1. SLAM 원본 지도 작성
2. 서비스 지도 편집
3. AMCL Localization
4. Navigation2 단일 목표 이동
5. 외부 센서 3종 연결
6. 카메라 영상 처리
7. ArUco 검출
8. 경유점 5개 이상 작성
9. 컴포넌트 시험

2주차 마일스톤은 핵심 기술 검증 완료입니다.

3) 3주차 서비스 통합

3주차 목표는 개별 기능을 하나의 서비스로 통합하는 것입니다.

주요 작업은 다음과 같습니다.

1. Mission Manager 구현
2. 10개 이상 경유점 작성
3. 2개 이상 주행 경로 작성
4. 주간 안내 서비스 구현
5. 야간 순찰 서비스 구현
6. PyQt GUI 구현
7. 음성, 효과음, LED 연동
8. ArUco 정밀 파킹
9. 전체 Launch 통합
10. 전원 인가 자동 실행
11. Wi-Fi 단절 대응

3주차 마일스톤은 전원 인가부터 임무 종료와 복귀까지 전체 흐름을 1회 이상 성공하는 것입니다.

4) 4주차 시험과 안정화

4주차에는 새로운 기능을 추가하기보다 성능 측정과 안정화에 집중해야 합니다.

주요 작업은 다음과 같습니다.

1. 직진 오차 측정
2. 회전 오차 측정
3. 목표점 도착 오차 측정
4. 좁은 통로 주행 시험
5. 장애물 회피 시험
6. 통신 단절 시험
7. 노드 장애 시험
8. 주간 안내 10회 시험
9. 야간 순찰 10회 시험
10. README 작성
11. 시험 결과서 작성
12. 시연 영상 제작
13. 발표 자료 작성
14. 최종 Release 생성

4주차 마일스톤은 인수 시험 완료와 최종 발표입니다.

10. 진척률 관리 방법

로봇 프로젝트에서 진척률을 개인의 주관으로 판단하면 실제 상태와 차이가 생깁니다.

다음과 같은 기준을 사용할 수 있습니다.

1. 0%는 작업을 시작하지 않은 상태입니다.
2. 25%는 개발 환경과 기본 구조가 준비된 상태입니다.
3. 50%는 정상 조건에서 기능이 한 번 동작한 상태입니다.
4. 75%는 예외 처리와 반복 시험을 진행하는 상태입니다.
5. 100%는 완료 기준 충족, 시험 증거 저장, GitHub 병합, 문서 갱신까지 끝난 상태입니다.

코드 작성만 완료된 상태는 일반적으로 50% 수준으로 보는 것이 적절합니다.

11. GitHub와 WBS 연결 방법(사용 가능한 경우 진행)

WBS ID를 GitHub Issue, Branch, Commit, Pull Request에 공통으로 사용하면 작업 추적이 쉬워집니다.

Issue 제목은 다음과 같이 작성할 수 있습니다.

[WBS 3.4] Navigation2 goal tolerance 튜닝

Branch 이름은 다음과 같이 작성할 수 있습니다.

feature/wbs-3-4-nav2-tuning

Commit 메시지는 다음과 같이 작성할 수 있습니다.

test: [WBS 7.2] 목표점 도착 시험 결과 추가

Pull Request에는 다음 내용을 포함합니다.

1. 작업 목적
2. 관련 WBS ID
3. 완료 기준
4. 시험 결과
5. 변경된 파라미터
6. 관련 로그와 사진
7. 관련 문서 링크

main 브랜치에는 실제 TurtleBot3에서 검증된 코드만 병합하는 것이 좋습니다.

12. WBS 적용 체크리스트

프로젝트를 시작할 때 다음 항목을 확인해야 합니다.

1. 최종 서비스와 제외 범위를 문서화했는가?
2. WBS가 산출물 중심으로 구성되었는가?
3. 요구사항과 시험 항목이 포함되었는가?
4. 문서와 발표 준비가 포함되었는가?
5. 모든 작업 패키지에 담당자가 있는가?
6. 모든 작업 패키지에 완료 기준이 있는가?
7. 작업 패키지가 1일에서 5일 수준으로 분해되었는가?
8. WBS ID를 GitHub와 시험표에 사용하고 있는가?
9. 실제 로봇에서 마일스톤을 검증하는가?
10. 확장 기능보다 필수 시나리오의 안정성을 우선하는가?
11. 통신 단절과 노드 종료 시험이 포함되었는가?
12. 설치와 실행 방법이 README에 기록되어 있는가?
13. 최종 결과가 특정 팀원의 PC에만 저장되어 있지 않은가?
14. 지도, 설정, 코드, 시험 결과가 GitHub에 남아 있는가?

13. 코드 작성보다 중요한 완료의 정의

ROS 2 프로젝트에서 코드 작성 완료와 프로젝트 완료는 다릅니다.

작업 패키지를 100% 완료로 처리하려면 다음 조건을 만족해야 합니다.

1. 코드가 정상적으로 빌드되어야 합니다.
2. 실제 TurtleBot3에서 실행되어야 합니다.
3. 정상 조건 시험을 통과해야 합니다.
4. 오류와 예외 상황을 처리해야 합니다.
5. 반복 시험 결과가 있어야 합니다.
6. 로그와 측정 데이터가 저장되어야 합니다.
7. GitHub main 브랜치에 병합되어야 합니다.
8. 파라미터와 실행 방법이 문서화되어야 합니다.

이 기준을 Definition of Done이라고 합니다.

14. 결론

TurtleBot3 ROS 2 프로젝트에서 WBS는 단순한 일정표나 할 일 목록이 아닙니다.

WBS는 서비스 로봇을 완성하기 위해 필요한 요구사항, 하드웨어, 지도, 자율주행, 센서, 비전, 서비스 로직, GUI, 안전 기능, 시험, 문서를 하나의 구조로 관리하는 기준입니다.

WBS를 적용하면 각 팀원이 무엇을 만들어야 하는지 명확해지고, 프로젝트 진행률을 실제 산출물과 시험 결과로 판단할 수 있습니다.

특히 ROS 2 기반 서비스 로봇 프로젝트에서는 기능 구현만큼 자동 실행, 통신 단절 대응, 반복 시험, 문서화가 중요합니다.

결국 좋은 WBS는 작업을 많이 적어 놓은 표가 아닙니다.

프로젝트의 전체 범위를 빠짐없이 정의하고, 각 작업의 완료 기준을 명확하게 만든 실행 기준입니다.

샘플 작성 파일