한가지 에피소드를 살펴 볼까요?
"프로세스가 없어서 그래!"
프로젝트를 진행하면서 필요한 업무가 정의되어 있지 않을 때, 흔히들 "프로세스가 없어서 그래!!" 라고들 합니다. 그래서 프로세스를 정의해야 한다고 하면서 절차와 담당자를 지정하고 산출물을 정의한 프로세스 문서들을 많이 만들어 냅니다. 그런 다음 열심히 설명회를 하거나 교육을 진행하며, 실무자에게 프로세스를 준수 할 것을 요청합니다. 그런데 실무에서는 너무 많은 종류의 산출물로 인해 그리고 짧은 개발일정으로 인해 프로세스가 외면 받기 시작합니다. 또한 그렇게 시간이 흘러 조직이 변경되어 프로세스에 지정된 담당자가 존재하지 않거나, 프로세스 개선이란 이름으로 중간중간 누락된 절차들을 만들어 프로세스가 변화됩니다.
이 에피소드에서는 프로세스를 단순히 형식적인 절차로만 정의하고, 실질적인 필요와 실행 가능성을 고려하지 않았기 때문에 발생합니다.
또 다른 에피소드를 살펴 볼게요...
"프로세스 ≠ 프로젝트"
A 회사에서는 프로젝트 수행을 위해 소프트웨어 개발 프로세스를 수립하였습니다. 그런다음 프로젝트 수행 과정에서 나온 산출물들과 프로세스들을 통합해서 관리하고 있습니다. 그렇게 프로젝트 결과물들 을 계속해서 한 곳에서 관리하다보니, 어떤게 프로세스고, 어떤게 프로젝트인지 구분이 모호해지고 있습니다. 심지어 프로젝트별로 조금씩 다르게 프로세스를 적용하다보니, 산출물들의 일관성도 부족해 지고, 일부 프로세스는 프로젝트 별로 변질되어 버렸습니다.
이 에피소드에서는 프로세스와 프로젝트가 개념적으로 혼동되었을 때 발생하는 문제를 보여줍니다. 프로세스는 프로젝트에 일관된 절차를 제공하는 지침 역할을 하며, 프로젝트의 목표나 성격에 따라 필요에 따라 조정될 수 있습니다. 그러나 두 개념을 혼동해서는 안됩니다.
[목차]
비즈니스나 IT 분야에서는 프로세스(Process), 프로젝트(Project), 그리고 프로덕트(Product)라는 세가지 용어를 자주 사용하고 있습니다. 이 세 단어들은 발음도 매우 유사할 뿐만 아니라, 서로 밀접하게 연관되어 있어 많은 사람들이 그 의미를 혼동하거나 오해하기 쉽습니다. 물론 단어 자체의 의미를 이해하지 못한다거나, 혼동하는 것은 아닐 수 있습니다만, 이들간의 유기적인 관계를 이해하지 못해 의미상 혼용하여 사용함으로써 제품 개발에 있어 의사소통이 애매한 상황이 곧잘 발생하게 됩니다.
최근 자동차 산업에서도 SDV, Connectivity Vehicle, Autonomous Driving 등 소프트웨어 기반의 프로젝트들이 많이 생겨나고 있습니다. 성공적인 프로젝트 수행을 위해서는 각 용어들의 개념과 관계를 명확하게 이해하고, 올바르게 활용하며, 이를 평가하고 개선하는 것이 필수입니다. 또한 이런 용어들의 관계를 명확하게 이해하면 업무의 흐름과 목표 달성을 더욱 효과적으로 관리할 수 있습니다.
프로세스(Process)
프로세스란 목표를 달성하기 위해 필요한 일련의 단계나 절차를 의미합니다. 이는 반복적이며 일관성을 유지하는 것이 특징입니다. 자동차 산업에서는 설계, 부품 조달, 생산 조립, 품질 검사, 출하 및 사후 관리에 이르는 모든 절차가 프로세스에 해당합니다.
프로세스가 중요한 이유는 다음과 같습니다:
- 일관성 유지: 프로세스를 통해 작업의 표준화를 이루어 품질과 효율성을 확보할 수 있습니다.
- 문제 예방: 각 단계에서 발생할 수 있는 오류를 사전에 방지할 수 있습니다.
- 시간 및 비용 절감: 최적화된 프로세스는 반복 작업에서 시간을 단축하고 비용을 줄이는 데 도움을 줍니다.
프로세스(Process) 정의
조직의 비즈니스 목표를 달성하기 위해서는 조직 업무 영역에 관한 프로세스를 정의하는 것이 매우 중요한데, 다음은 프로세스의 정의입니다.
프로세스의 정의
프로세스란 목표를 달성하기 위해 필요한 일련의 반복적이고 체계적인 단계 및 절차를 의미합니다.
그렇다면 프로세스를 정의하기 위해 필요한 사항들은 무엇이 있을까요?
(1) 프로세스 목표 설정
먼저 프로세스 목표가 설정되어야 합니다. 프로세스 목표는 조직이 프로세스를 통해 달성하고자 하는 명확한 목적이 정의되어야 합니다. 예를 들어 소프트웨어 개발 프로세스는 고객의 요구사항을 명확하게 정의하고, 올바른 설계를 통해 코드를 개발하고, 이것이 다시 설계에 따라 올바르게 구현되었는지, 그리고 최종적으로 고객이 요구하는 요구사항을 충실히 구현하였는지를 파악하는것이 목표입니다. (예, V 모델 기반의 소프트웨어 개발 프로세스) 또한 소프트웨어 품질 관리 프로세스의 경우 개발하는 소프트웨어의 결함을 줄이고 일정 수준의 품질을 유지하는 것이 목표라고 할 수 있습니다.
(2) 프로세스 작업 단계 설정
다음으로는 목표를 달성하기 위해 필요한 작업 단계가 체계적으로 정의되어야 합니다. 예를 들어 소프트웨어 개발 프로세스는 요구사항 정의, 설계, 구현, 검증 및 확인과 같은 작업 단계가 있습니다. 소프트웨어 개발 초기부터 앞에 정의된 목표를 달성하기 위해 필요한 세부 작업 단계들이 정의되어야 합니다. 따라서, 조직 특성이나 산업 특성에 따라 다양한 단계가 정의될 수 있습니다. 다만, 작업 단계를 거치고 나면 앞서 정의된 프로세스 목표가 달성되었는지를 반드시 확인할 수 있어야 합니다.
(3) 프로세스 절차 정의
프로세스 작업 단계가 정의되면, 각 단계 내에서 수행해야 하는 세부 작업과 절차가 명시되어야 합니다. 예를 들어 소프트웨어 개발 프로세스의 요구사항 분석 단계에서 세부 작업과 절차는 먼저 요구사항 분석을 위한 고객 미팅, 초기 요구사항 모델링, 요구사항 분석, 요구사항 명세서 작성, 요구사항 명세서 검토와 같은 세부 작업과 절차가 명시되어야 합니다.
(4) 프로세스 자원 설정
프로세스 세부 작업 설정까지 완료되면, 이들 작업을 누가 할 것인지, 무엇을 가지고 할 것인지, 어떤 재료(입력)를 활용해야 하는지와 같은 인력, 장비, 재료 등의 자원이 함께 정의되어야 합니다.
(5) 프로세스 산출물 정의
산출물이란 프로세스를 통해 달성하고자 하는 프로세스 목표에 대한 근거를 의미합니다. 즉, 소프트웨어 개발 프로세스의 목표가 고객 요구사항을 달성하는 올바른 소프트웨어가 개발되었는지에 대한 근거로, 요구사항 명세서, 아키텍처, 상세설계, 검증 보고서 등의 각종 산출물들을 작성하게 됩니다. 이를 통해 해당 프로세스가 충분히 목표를 달성하였음을 증명할 수 있게 됩니다.
(6) 프로세스 평가 및 개선
마지막으로 모든 프로세스는 100% 완벽한 프로세스는 존재하지 않습니다. 조직마다 처한 여건과 비즈니스 환경이 다를 것이며, 인력 구성과 운영 방향성 그리고 시장 상황과 같은 여러 변수에 의해 프로세스를 항상 평가되고 개선되어야 합니다. 이렇게 프로세스가 효과적으로 수행되고 있는지를 평가하고, 필요한 경우 개선할 수 있는 매커니즘 즉, KPI(Key Performance Indicator)나 주기적인 프로세스 감사(Audit)이 수행되어야 하기 떄문에 이에 대한 정의가 추가되어야 합니다.
프로세스와 프로세스간 관계
프로세스는 독립적으로 작동하기 보다는 상호 연관성을 갖고 진행됩니다. 예를 들어 소프트웨어 개발 프로세스는 소프트웨어 품질 관리 프로세스와 연계되어 작동할 수 있습니다. 개발 과정에서 각 단계별 품질 기준을 정의하여, 단계 및 절차별 개발되는 산출물에 대한 품질 평가를 진행할 수 있습니다. 이러한 소프트웨어 품질 관리 프로세스도 하나의 프로세스이기 때문에, 이들이 상호 연관되어 작동해야 합니다. 또한 소프트웨어 개발 과정에서 변경 요소가 발생하는 경우, 변경관리 프로세스와도 연계될 수 있습니다. 변경 관리 프로세스란 변경이 발생한 경우 이를 식별하고, 분석하며, 영향성을 검토하여 검증까지 재수행해야 하는 단계와 절차를 기술한 것입니다. 그 밖에 외부 COTS(Commercial Off The Shelf) 제품을 구매하여 소프트웨어 개발을 수행해야 하는 경우, 소프트웨어 구매 프로세스와도 연계되어 수행될 수 있습니다.
이렇듯 하나의 프로세스는 그 자체만으로 작동하기 보다는 상호 연관성을 갖고 진행되기 때문에, 여러 프로세스와의 관계도 충분히 고려되어야 합니다. 또한 이러한 상호 연관성에는 특정한 관계 유형을 정의하여 구분할 수 있습니다.
- 선후 관계: 특정 프로세스가 완료된 후에만 다음 프로세스가 시작될 수 있습니다. 예를 들어, 설계 검토 프로세스가 완료되어야 생산 프로세스가 시작될 수 있습니다.
- 병렬 관계: 여러 프로세스가 동시에 진행될 수 있습니다. 예를 들어, 부품 조달 프로세스와 프로토타입 제작 프로세스가 병렬로 진행될 수 있습니다.
- 의존 관계: 하나의 프로세스가 다른 프로세스의 산출물을 입력으로 사용해야 하는 경우입니다. 품질 관리 프로세스는 생산 프로세스에서 생성된 제품을 검사해야 하므로 두 프로세스는 상호 의존적입니다.
- 상호 피드백: 각 프로세스에서 발생하는 문제나 개선 사항이 다른 프로세스에 영향을 줄 수 있습니다. 예를 들어, 테스트 프로세스에서 발견된 결함은 설계 프로세스를 수정하도록 요구할 수 있습니다.
프로젝트 (Project)
프로젝트는 시작과 종료 시점이 명확하며, 자원, 예산, 일정, 인력이 할당되어 목표를 달성하기 위해 실행되며, 일반적으로 다음과 같은 특징을 갖습니다:
- 고유성(Uniqueness): 프로젝트는 새로운 결과물을 창출하기 때문에 매번 다른 특성을 가집니다. 예를 들어, 새로운 자동차 모델 개발 프로젝트는 기존 모델과 다른 요구사항을 반영합니다.
- 일시성(Temporary Nature): 프로젝트는 시작과 종료가 명확하며, 목표가 달성되면 종료됩니다.
- 목적 지향성(Goal-Oriented): 프로젝트는 특정 목표나 산출물(Deliverables)을 달성하기 위해 수행됩니다.
- 복잡성(Complexity): 다양한 이해관계자와 여러 자원이 관련되며, 작업이 서로 의존하는 경우가 많아 복잡한 계획과 조정이 필요합니다.
프로젝트 정의
다음은 프로젝트의 정의입니다.
프로젝트의 정의
프로젝트란 특정 목표를 달성하기 위해 일정 기간 동안 수행되는 고유한 작업을 의미합니다.
위 정의에서도 알 수 있듯이 프로젝트는 프로세스 개념에 시간(Time) 개념이 포함되어 있습니다. 즉, 프로세스가 비즈니스 목적을 달성하기 위해 필요한 반복적인 단계와 절차라면, 여기에 시간 개념이 추가되어 언제 활동이 수행되며, 얼마동안 수행될 것이며, 누가 수행할 것인지를 의미합니다. (프로젝트 = 프로세스 + 일정(시간))
또한 프로젝트에서는 산출물을 통해 특정 목표가 달성되었는지를 확인할 수 있기 때문에 프로세스라는 용어를 산출물을 작성하기 위한 활동(단계 또는 절차)로 오해 하기 쉽습니다. 그러나 프로젝트 내에서 산출물을 작성하기 위한 구조에는 WBS(Work Breakdown Structure)라는 용어를 별도로 정의하고 있습니다.
WBS의 정의
WBS는 프로젝트를 성공적으로 수행하기 위해 필요한 작업을 계층적이고 체계적으로 분해한 구조입니다.
다시 말해 프로젝트 목표를 달성하기 위해 수행해야 할 모든 작업을 세부적으로 나눔으로써 작업의 범위를 명확히 정의하고 관리 할 수 있도록 도와주는 WBS를 이용하여 프로세스를 구현할 수 있어야 합니다. WBS에 대해서는 별도로 자세히 정의한 글을 참고하면 좋을 듯 합니다. (참고: WBS (Work Breakdown Structure): 효율적 프로젝트 관리)
WBS (Work Breakdown Structure): 효율적 프로젝트 관리
프로젝트를 성공적으로 완수하려면 체계적인 관리와 효율적인 계획이 필수입니다. 특히 대규모 프로젝트나 복잡한 시스템 개발에서는 목표 달성과 일정 준수가 중요한데, 이를 위해 많은 팀이
habana4.tistory.com
프로젝트 단위의 프로세스 실행: WBS
1. 프로세스는 WBS 작성의 기준을 제공
앞에서도 언급한바와 같이 프로세스에서 정의된 표준 절차와 작업 단계를 기반으로 WBS가 작성됩니다. 예를 들어, 소프트웨어 개발 프로젝트에서는 요구사항 분석, 설계, 개발, 테스트 등 프로세스 단계가 WBS의 상위 작업(Task)으로 포함될 수 있습니다.
- 작업 단계 정의 기준 제공: 프로세스에서 정의된 작업 절차(예: 요구사항 수집, 설계, 개발, 테스트 등)가 WBS의 상위 작업(Task)으로 포함됩니다. 또한 각 작업 단계는 프로세스에서 미리 정의된 절차에 따라 분해되어 하위 작업(Work Package)으로 세분화됩니다.
- 작업 순서 및 의존성 제공: 프로세스는 작업 단계 간의 선후 관계와 의존성을 명확히 규정합니다. 이는 WBS에서 작업 순서를 계획하고, 작업 간 의존 관계(Dependency)를 설정하는 데 도움을 줍니다.
- 산출물 기준 제공: 프로세스는 각 단계별로 요구되는 산출물을 정의하며, WBS에서는 해당 산출물을 작업 완료의 기준으로 사용합니다. 산출물 기준을 통해 프로젝트의 진행 상황을 평가하고 관리할 수 있습니다.
- 품질 관리 기준 제공: 프로세스는 각 작업 단계에서 품질을 보장하기 위한 검사 기준과 승인 절차를 제공합니다. WBS 작업에 품질 관리 활동이 포함됨으로써 프로젝트 산출물의 품질이 유지됩니다.
2. WBS는 프로젝트 단위에서 프로세스를 실행하는 도구
프로젝트에서 프로세스를 실행하기 위해 WBS를 활용하여 작업 범위를 명확히 하고, 각 단계의 책임자, 일정, 자원을 배정합니다. WBS는 프로젝트 관점에서 프로세스를 구체적으로 실행하는 데 도움을 줍니다.
- 작업 구조 명확화: 프로세스에서 정의된 절차와 단계는 WBS를 작성할 때 기준이 됩니다. 프로세스에서 제공하는 주요 작업 단계(예: 요구사항 분석, 설계, 개발, 테스트 등)가 WBS의 상위 작업(Task)으로 포함되며, 세부 작업(Work Package)으로 분해됩니다.
- 작업 범위 관리: WBS는 프로젝트의 전체 작업 범위를 명확히 정의합니다. 이를 통해 프로젝트 범위가 명확해지고, 작업 누락을 방지할 수 있습니다. 프로세스의 각 단계가 프로젝트 작업으로 구체화되면서, 프로젝트 팀은 각 작업에 대한 책임과 목표를 명확히 인식할 수 있습니다.
- 책임자 및 자원 배정: WBS를 통해 각 작업의 책임자와 필요 자원을 명확히 배정할 수 있습니다. 프로세스는 각 작업의 기준을 제공하지만, WBS는 프로젝트에서 해당 작업이 누구에게 배정되고 어떤 자원이 필요한지를 구체적으로 명시합니다.
- 일정 및 의존성 관리: 프로세스는 작업 간의 의존성과 순서를 정의하지만, WBS는 프로젝트 일정에 맞추어 작업 순서를 관리합니다. 각 작업의 시작과 완료 시점을 설정하고, 프로젝트 일정이 효율적으로 조정될 수 있도록 지원합니다.
3. 프로세스 간 산출물 흐름 관리
프로젝트가 진행되는 동안, 특정 프로세스의 산출물이 다른 프로세스의 입력으로 활용될 수 있습니다. WBS를 통해 이러한 산출물의 흐름과 의존 관계를 체계적으로 관리할 수 있습니다.
프로세스 vs. 프로젝트
프로세스와 프로젝트는 상호 보완적인 관계에 있습니다. 먼저 프로세스는 표준화된 절차를 정의하며, 이를 통해 프로젝트가 체계적으로 진행 될 수 있도록 돕습니다. 그리고 프로젝트는 프로세스를 실행하는 단위입니다. 즉, 프로젝트는 프로세스를 기반으로 작업을 수행하며, 목표를 달성합니다. 마지막으로 프로젝트가 진행되는 동안 특정 프로세스의 산출물이 다른 프로세스의 입력으로 활용되기도 하며, 작업간 의존성이 발생합니다.
프로세스와 프로젝트의 오해
실제 프로젝트 현장에서는 종종 프로세스와 프로젝트 간의 개념적 혼동이 발생합니다. 특히, 프로세스와 WBS(Work Breakdown Structure)가 혼동되어 프로젝트 수행에 문제가 생기기도 합니다.
■ 프로세스와 WBS의 개념 혼동
프로세스는 업무 수행의 표준 절차를 제공하는 반면, WBS는 프로젝트 작업을 계층적으로 체계화한 구조입니다. 프로젝트에서는 프로세스를 기반으로 작업을 정의하지만, WBS는 프로젝트 목표를 달성하기 위한 세부 작업 구조를 관리하기 위해 사용됩니다.
- 프로세스: 반복적인 절차와 단계로 구성되어 있으며, 업무의 일관성을 보장합니다.
- WBS: 프로젝트의 목표와 범위를 명확히 하기 위해 작업을 분해하고, 작업 간 의존 관계를 정의합니다.
혼동이 발생할 경우 프로젝트 팀은 작업의 범위와 책임을 명확히 이해하지 못하고, 불필요한 작업이나 절차를 중복 수행하는 문제가 발생할 수 있습니다.
■ 산출물 관리의 혼란
프로세스와 프로젝트는 각각의 산출물을 생성합니다. 그러나 산출물이 명확히 구분되지 않을 경우, 프로젝트에서는 불필요한 산출물을 중복 작성하거나 관리 부담이 증가할 수 있습니다.
- 프로세스 산출물: 프로세스 단계에서 생성되는 반복적 산출물(예: 품질 검사 보고서)
- 프로젝트 산출물: 프로젝트 목표 달성을 위한 고유 산출물(예: 최종 설계 문서)
이러한 혼란은 프로젝트 진행 중에 일정 지연과 리소스 낭비로 이어질 수 있습니다.
프로세스 기반 WBS의 활용
프로세스를 프로젝트에 효과적으로 적용하기 위해서는 WBS를 활용하여 작업 구조를 명확히 정의해야 합니다. WBS는 프로세스에서 제공하는 작업 단계를 기준으로 작성되며, 각 작업의 책임자, 일정, 자원을 체계적으로 관리할 수 있습니다.
WBS를 통한 프로세스 실행
- 작업 구조 명확화:
- 프로세스에서 정의된 절차를 기반으로 프로젝트 작업을 계층적으로 분해합니다.
- 예: 설계 프로세스를 WBS에서 '시스템 설계', 'UI 설계', '데이터 모델링' 작업으로 세분화
- 책임자 및 자원 배정:
- 각 작업에 책임자와 자원을 배정하여 작업 진행 상황을 관리합니다.
- 예: 테스트 작업에 테스트 팀 리더와 필요한 장비를 배정
- 산출물 흐름 관리:
- 작업 간 산출물 의존 관계를 설정하여, 작업 지연이나 정보 누락을 방지합니다.
- 예: 설계 작업이 완료된 후에만 개발 작업이 시작되도록 의존 관계 설정
마치며...
프로세스와 프로젝트는 비즈니스 목표 달성을 위해 필수적인 개념입니다. 프로세스는 업무를 표준화하여 일관성과 품질을 유지하는 역할을 하며, 프로젝트는 특정 목표를 달성하기 위해 제한된 기간 동안 수행되는 고유한 작업입니다. 두 개념이 혼동될 경우, 프로젝트 관리에 혼란이 발생하고 비효율성이 증가할 수 있습니다. 실제 앞선 에피소드와 같은 여러 혼선들이 생길 수 있습니다. 따라서 이 두 개념들을 정확하게 이해할 수 있어야 합니다.
프로세스는 프로젝트에 가이드라인과 기준을 제공하고, 프로젝트는 프로세스를 실행하며 새로운 산출물을 창출합니다. 이러한 상호 보완적 관계를 명확히 이해하고, 필요에 따라 유연하게 적용하는 것이 중요합니다. 특히, 프로젝트에서는 WBS(Work Breakdown Structure)와 같은 도구를 활용하여 작업 범위를 체계적으로 정의하고 프로세스를 실행해야 합니다.
어쩌면 너무 당연한 것이고, 초보적인 지식임에도 불구하고, 비 IT 분야, 특히 기계, 하드웨어 중심의 자동차 산업에서는 개념 단계의 혼동이 자주 일어나는 것을 보면서 용어에 대한 정의를 다시 한번 살펴보는 것도 좋겠다 싶었습니다.
'Software Engineering' 카테고리의 다른 글
| 소프트웨어 요구사항 모호성 & 일관성 해소: EARS (Easy Approach to Requirements Syntax)와 Glossary 활용 (0) | 2025.02.15 |
|---|---|
| Umbrella Organization (우산 조직)을 아시나요? (0) | 2025.02.02 |
| 대한민국에서 차량 제어분야 고연차 소프트웨어 엔지니어로서의 도전과 성장 (1) | 2025.02.01 |
| 소프트웨어 개발과 다품종 소량생산: 변경점 관리의 도전과 가치 (0) | 2025.01.21 |
| MECE 원칙을 활용한 소프트웨어 Fault Tolerance 중복성 설계: 신뢰성과 효율성을 극대화하는 접근법 (0) | 2025.01.04 |