개발 수명주기 모델에서의 테스팅에 대해 알아보니..

개발 수명주기 모델에서의 테스팅에 대해 알아보았습니다.

 

 

소프트웨어 개발 수명주기(SDLC)는 요구사항 분석부터 유지보수까지 다양한 단계로 이루어지며, 이 각 단계에서는 품질 확보와 결함 예방을 위해 다양한 테스팅 활동이 수행됩니다.

1. 개발 수명주기 모델 개요

개발 수명주기 모델은 소프트웨어를 체계적으로 개발하기 위한 프로세스로, 일반적으로 다음과 같은 주요 단계를 포함합니다:

• 요구사항 분석 (Requirement Analysis): 고객 및 사용자 요구를 도출하고 명세서를 작성하는 단계입니다.
• 설계 (Design): 시스템 아키텍처 및 세부 모듈의 구조를 정의하고, 구현 전략을 마련합니다.
• 구현 (Implementation): 실제 코드를 작성하고, 기능들을 개발하는 단계입니다.
• 테스트 (Testing): 개발된 소프트웨어의 기능, 성능, 보안, 사용자 경험 등을 검증하고 결함을 찾아내는 단계입니다.
• 배포 및 운영 (Deployment & Operation): 완성된 소프트웨어를 실제 환경에 배포하고, 운영하면서 유지보수를 수행합니다.

각 단계마다 테스팅 활동은 단순히 마지막에 “검증하는” 역할을 넘어, 초기부터 품질 확보를 위한 중요한 수단으로 작용합니다.

2. 단계별 테스팅의 역할과 방법

2.1. 요구사항 분석 단계에서의 테스팅

• 검증(Verification)과 검증(Validation)의 기초 마련: 요구사항 명세서를 작성할 때, QA팀은 문서상의 요구사항이 명확하고 완전한지, 중복되거나 누락된 부분은 없는지 검토합니다.
• 테스트 기본 계획 수립: 요구사항 추적 매트릭스(Traceability Matrix)를 작성하여, 나중에 각 요구사항이 어떤 테스트 단계에서 검증될지 계획합니다.
  
  
  • Verification (검증): "우리가 제품을 제대로 만들고 있는가?"
    Verification은 개발 과정에서 설계 문서나 규격대로 제품이 잘 구현되었는지 내부적으로 점검하는 과정입니다.
    → Mnemonic: "제대로 만들었는가?"
    예) 코드 리뷰, 단위 테스트, 통합 테스트 등
    
    마치 건축 현장에서 건물이 구조도와 시공 기준에 따라 제대로 지어졌는지를 확인하는 작업입니다.
    (예: 벽돌 배열, 시멘트 혼합비율 등)
    
    
    
  • Validation (유효성 검사): "우리가 올바른 제품을 만들고 있는가?"
    Validation은 실제 사용자 요구나 기대에 부합하는지, 최종 제품이 올바른 문제를 해결하는지를 외부적으로 평가하는 과정입니다.
    → Mnemonic: "올바른 제품인가?" 예) 사용자 수용 테스트, 현장 테스트, 베타 테스트 등
    
    건물이 실제 거주자에게 안전하고 편리한지, 요구하는 기능(예: 방 크기, 위치, 편의시설 등)을 충족하는지를 확인하는 작업입니다.
    

이 두 질문, "제대로 만드는가?"와 "올바른 제품을 만드는가?"를 서로 연상하면 두 용어의 차이를 쉽게 기억할 수 있습니다

2.2. 설계 단계에서의 테스팅

• 설계 리뷰와 워크스루: 시스템 설계 및 상세 설계 문서를 기반으로, 설계 리뷰를 통해 디자인 결함이나 잠재적 위험 요소를 미리 파악합니다.
  
  

워크스루(Walkthrough)는 소프트웨어 개발 및 품질 보증 과정에서 사용되는 비공식적 검토 기법 중 하나입니다.

워크스루는 작성자가 자신의 산출물(예: 요구사항 문서, 설계서, 코드, 테스트 케이스 등)을 팀원이나 동료들에게 설명하면서, 피드백과 개선점을 도출해내기 위한 회의 형식의 검토 활동입니다.

워크스루의 주요 특징

• 1. 비공식적이고 협업 중심
     • 워크스루는 공식적인 검증 절차보다는 비교적 자유로운 분위기에서 진행됩니다.
     • 작성자와 참여자들이 열린 대화를 통해 의견을 교환하며, 서로의 이해를 돕고 문제점을 도출하는 데 집중합니다.
  2. 교육적 효과 및 지식 공유
     • 팀원들이 산출물의 내용을 함께 살펴보며, 각자의 관점에서 개선점을 제시하기 때문에 전반적인 제품 품질 향상에 기여합니다.
     • 특히 신규 팀원이나 관련 부서 간의 지식 공유와 기술적 이해도를 높이는 데 도움이 됩니다.
  3. 초기 결함 발견
     • 빨리 산출물을 공유하고 검토함으로써, 후속 단계에서 발견될 수 있는 중대한 결함이나 오류를 조기에 식별할 수 있습니다.
     • 이를 통해 비용이 많이 드는 재작업을 예방할 수 있습니다.
  4. 소통 및 피드백 활성화
     • 워크스루 회의에서는 질문, 토론, 피드백이 활발하게 이루어지므로, 산출물에 대한 다양한 관점을 공유하고 개선 아이디어를 도출할 수 있습니다.

워크스루 진행 과정

• 1. 준비 단계:
     • 작성자는 검토할 산출물(예: 설계 문서, 코드 등)을 준비하고, 주요 논의 사항이나 의문점, 검증하고자 하는 부분을 미리 정리합니다.
     • 참여자들에게 사전에 관련 자료를 공유하여, 미리 검토할 수 있도록 합니다.
  2. 설명 및 발표:
     • 작성자가 자료를 차례로 설명하며, 의도와 설계 방향, 기능 등을 상세히 풀어 나갑니다.
     • 이 과정에서 작성자는 자신의 결정에 대한 근거와 각 요소가 왜 그렇게 구현되었는지를 설명합니다.
  3. 피드백 및 토론:
     • 참여자들은 설명 내용을 기반으로 질문을 하거나, 개선점, 우려 사항 등을 제시합니다.
     • 활발한 토론을 통해 문제점을 도출하고, 해결 방안이나 추가 수정 사항에 대해 논의합니다.
  4. 정리 및 후속 조치:
     • 회의 후, 도출된 피드백과 이슈 사항을 정리하여 문서화하고, 추후 산출물 수정이나 개선 계획에 반영합니다.
     • 워크스루 결과는 차후 품질 개선 및 검증 자료로 활용됩니다.

워크스루의 장점과 한계

장점:

• 빠른 피드백 및 문제점 도출: 산출물의 오류나 개선 사항을 조기에 식별할 수 있습니다.
• • 팀 내 소통 강화: 다양한 의견을 공유함으로써 팀원 간 협업과 지식 공유를 촉진합니다.
  • 비용 절감: 초기 단계에서 결함을 발견해 수정함으로써, 나중에 발생할 수 있는 큰 비용을 줄일 수 있습니다.

한계:

• • 비공식적 특성: 구조화된 검증 절차에 비해 일정 부분 엄격한 검토가 어려울 수 있으므로, 모든 오류를 놓칠 위험이 있습니다.
  • 참여자의 경험에 의존: 참석한 팀원들의 경험과 전문성에 따라 피드백의 질이 달라질 수 있습니다.
  • 시간 관리: 모든 참석자들이 자료를 충분히 사전에 검토하지 않으면, 회의 시간이 길어지고 효율성이 떨어질 수 있습니다.

결론

워크스루는 소프트웨어 산출물에 대한 초기 검토와 피드백 수집을 위해 매우 유용한 방법입니다.
공식적인 검토 방식보다는 자유로운 분위기에서 진행되므로, 팀원 간의 활발한 소통과 협업, 그리고 지식 공유를 통해 결함을 조기에 발견하고 개선할 수 있습니다.
QA 엔지니어뿐만 아니라 개발자, 설계자 모두가 참여하여 상호 검증 및 토론하는 과정을 통해 전반적인 제품 품질 향상에 기여할 수 있습니다.

• 테스트 전략 계획: 각 모듈 또는 기능에 대해 단위 테스트, 통합 테스트, 시스템 테스트 등 구체적인 테스트 계획을 수립합니다.
• 모듈 분리와 인터페이스 정의: 명확한 모듈 분리와 인터페이스 정의는 후속 통합 테스트나 시스템 테스트에서 오류를 줄이는 중요한 요소입니다.
  
  

2.3. 구현 단계에서의 테스팅

• 단위 테스트 (Unit Testing): 개발자가 개별 함수나 모듈 단위로 수행하는 테스트로, 코드의 기본 기능이 올바르게 동작하는지 확인합니다.
• 코드 리뷰: 동료 개발자와 QA팀이 함께 코드 리뷰를 실시하여, 잠재적인 결함이나 개선점을 빠르게 공유합니다.
• 자동화 테스트 도구 활용: 지속적 통합(CI) 환경에서 단위 테스트 코드를 자동 실행하여, 코드 변경 시 빠르게 피드백을 제공합니다.
  
  

2.4. 통합 및 시스템 테스트 단계

• 통합 테스트 (Integration Testing): 개별 모듈을 통합한 후, 서로 간의 인터페이스와 데이터 흐름이 올바르게 이루어지는지 검증합니다.
• 시스템 테스트 (System Testing): 전체 시스템이 요구사항 정의에 맞게 작동하는지, 성능, 보안, 스트레스 테스트 등을 통해 종합적으로 검증합니다.
• 회귀 테스트 (Regression Testing): 새로운 기능 추가나 변경에 따라 기존 기능에 영향을 미치지 않는지를 확인하기 위해, 자동화 회귀 테스트가 자주 수행됩니다.
  
  

2.5. 배포 및 운영 단계에서의 테스팅

• 수용 테스트 (Acceptance Testing): 실제 사용자 환경에서 최종 제품이 사용자의 요구와 기대에 부합하는지 검증합니다.
• 운영 모니터링 및 피드백: 배포 후에도 지속적으로 모니터링하며, 문제가 발견되면 즉각 대응하고 수정하여 유지보수 단계에서 제품의 신뢰성을 유지합니다.
  
  

3. 테스팅의 통합적 역할

개발 수명주기 모델 내에서 테스팅은 단순히 “검증하는” 최종 단계가 아니라, 다음과 같은 통합적 역할을 수행합니다.

• 초기 결함 발견 및 비용 절감: 초기 단계부터 테스팅 활동을 수행함으로써, 나중에 발생할 수 있는 큰 오류나 결함을 사전에 발견하고 수정할 수 있어 전체 비용과 시간 소요를 줄입니다.
• 투명한 요구사항 이행 확인: 요구사항, 설계, 구현 단계에서의 산출물을 기반으로 체계적인 테스트를 진행하면, 소프트웨어가 초기 목표와 사용자의 요구를 충실히 반영하고 있는지 확인할 수 있습니다.
• 품질 문화 정착: 전 단계에서의 테스팅 활동은 개발팀과 QA팀 간의 긴밀한 협업을 유도하며, 품질 중심의 소프트웨어 개발 문화를 정착시키는 데 기여합니다.

4. ASCII 다이어그램 예시

아래는 개발 수명주기 모델 내 테스팅 활동의 흐름을 간략히 나타낸 ASCII 다이어그램 예시입니다.

 

   요구사항 분석
       │
       ▼
   √ 요구사항 검증
       │
       ▼
    설계 단계
       │
       ▼
  √ 설계 리뷰 및 테스트 계획 수립
       │
       ▼
    구현 단계
       │
       ▼
   √ 단위 테스트 + 코드 리뷰
       │
       ▼
통합/시스템 테스트
       │
       ▼
   √ 통합 & 회귀 테스트
       │
       ▼
   배포/운영 단계
       │
       ▼
   √ 수용 테스트 및 모니터링

결론

개발 수명주기 모델에서의 테스팅은 소프트웨어 개발 전 과정에 걸쳐 이루어지는 필수적인 활동입니다.

초기 요구사항 검증부터 설계 리뷰, 단위 테스트, 통합/시스템 테스트, 마지막에 수용 테스트에 이르기까지 다양한 단계에 체계적으로 배치됩니다.

이러한 통합적 테스팅 활동은 소프트웨어의 품질 및 신뢰성을 보장하고, 개발 과정에서 발생할 수 있는 결함을 조기에 발견하여 수정함으로써 전체 개발 비용과 리스크를 크게 줄이는 역할을 수행합니다.

 

# 개발 수명주기 모델에서 테스팅을 진행할 때, QA 엔지니어분들이 특히 주의해야 할 점과 이를 실제 현장에서 겪은 사례

1. QA 엔지니어가 주의해야 할 점

1.1. 요구사항 및 설계 문서의 철저한 검토

• 요구사항의 명확성 및 완전성: 초기 요구사항 문서에 모호하거나 누락된 부분이 없도록 꼼꼼하게 검증해야 합니다.
  요구사항 추적 매트릭스(Traceability Matrix)를 활용하여 각 기능이 테스트 케이스에 정확히 반영되었는지 확인하는 것이 중요합니다.
  
  
  

  요구사항 ID	요구사항 설명	설계 문서 참조	구현 모듈/클래스	테스트 케이스 ID	상태
  REQ-001	사용자 로그인 기능 구현	설계서 3.2	LoginService.java	TC-001, TC-002	완료
  REQ-002	비밀번호 암호화 기능 구현	설계서 3.3	EncryptionUtil.java	TC-003	진행중
  REQ-003	사용자 프로필 조회 및 수정 기능 구현	설계서 4.1	ProfileController.java	TC-004, TC-005	완료

  
  
  1. 요구사항 ID:
     • 고유 식별자로, 각 요구사항을 쉽게 구분할 수 있도록 합니다.
  2. 요구사항 설명:
     • 요구사항의 내용을 간략하게 설명합니다. 예를 들어, “사용자 로그인 기능 구현”과 같이 핵심 기능을 기술합니다.
  3. 설계 문서 참조:
     • 해당 요구사항이 반영된 설계 문서의 섹션이나 페이지 등을 기입하여, 설계 기준을 쉽게 확인할 수 있게 합니다.
  4. 구현 모듈/클래스:
     • 실제 코드에서 해당 요구사항을 구현한 모듈이나 클래스를 기재합니다.
  5. 테스트 케이스 ID:
     • 해당 요구사항을 검증하기 위해 작성된 테스트 케이스의 ID를 나열합니다.
  6. 상태:
     • 요구사항의 개발 및 테스트 상태를 기록합니다. 예를 들어, “완료”, “진행중” 등의 상태를 명시합니다.

이와 같이 요구사항 추적 매트릭스를 작성하면, 전체 개발 및 테스트 활동 중에 각 요구사항이 어떻게 반영되고 있는지 쉽게 추적할 수 있어, 변경 관리나 품질 보증에 큰 도움이 됩니다.

• 설계 문서와 실제 구현과의 연계성: 설계 단계에서 정의된 내용이 실제 코드로 구현될 때 누락되거나 다른 방식으로 적용되는 경우가 발생할 수 있으므로, 설계 문서를 지속적으로 재검토하여 구현과의 불일치를 사전에 방지해야 합니다.

1.2. 변경 관리 및 테스트 케이스 업데이트

• 요구사항 및 설계 변경에 대한 신속한 대응: 개발 과정 중에 요구사항이나 설계 변경이 발생하면, 이에 따른 테스트 케이스와 문서를 즉각 업데이트해야 합니다. 이런 프로세스를 마련하지 않으면 나중에 회귀 테스트 단계에서 큰 리스크로 작용할 수 있습니다.
• 버전 관리 도구 활용: 문서와 테스트 케이스의 변경 이력을 철저하게 관리하여, 언제 어떤 변경이 발생했는지 추적할 수 있도록 합니다.

1.3. 단계별 테스팅 철저 수행

• 단위 테스트: 각 기능 단위의 코드가 올바르게 동작하는지 확인합니다. 개발자가 작성한 코드에 대한 자동화 단위 테스트를 구축하여, 코드 변경 시 빠르게 오류를 감지할 수 있도록 해야 합니다.
• 통합 테스트 및 시스템 테스트: 여러 모듈을 결합했을 때 인터페이스 및 데이터 흐름의 오류를 사전에 파악합니다.
  특히 통합 테스트에서는 모듈 간 상호작용에 주의하여, 테스트 케이스를 설계해야 합니다.
• 수용 및 회귀 테스트: 최종 사용자 환경에서 기능이 정상 작동하는지 검증하는 수용 테스트와, 새로운 기능이 추가될 때 기존 기능에 영향을 미치지 않는지 확인하는 회귀 테스트를 체계적으로 수행해야 합니다.

1.4. 팀 간의 긴밀한 커뮤니케이션

• 정기 회의 및 리뷰: 개발팀, 설계팀, 그리고 QA팀 간의 정기적인 회의 및 문서 리뷰를 통해 변경 사항과 이슈를 공유해야 합니다. 이를 통해 초기 단계에서의 오류나 누락 사항을 신속히 보완할 수 있습니다.
• 협업 도구 활용: 프로젝트 관리 및 변경 관리 도구(Jira, Confluence 등)를 활용하여, 팀 내의 소통과 실시간 업데이트를 원활하게 진행할 수 있도록 합니다.

1.5. 자동화 테스트 도구의 적극적인 활용

• 지속적 통합 (CI) 시스템: 자동화된 테스트 스크립트를 CI 환경에 통합하여, 코드 변경 시 자동 회귀 테스트를 수행함으로써, 빠른 피드백과 결함 조기 발견에 힘써야 합니다.
  
  

2. 실제 사례

사례 1: 항공 전산 관리 시스템 개발 프로젝트

• 상황: 항공 전산 관리 시스템을 개발하는 과정에서, 초기 요구사항 문서에서 일부 중요한 기능이 누락되는 문제가 있었습니다. QA 팀은 요구사항 추적 매트릭스를 바탕으로 테스트 케이스를 작성했지만, 해당 누락된 부분은 반영되지 않았습니다.
• 문제점: 설계 단계 이후, 시스템 테스트 단계에서 누락된 기능 때문에 중요한 항공 데이터 처리 오류가 발견되었습니다. 이로 인해 재검토와 수정 작업이 필요했고, 프로젝트 일정이 지연되는 결과를 초래했습니다.
• QA 대응 및 결과: 이 문제를 계기로 QA 엔지니어는 요구사항 명세서를 다시 점검하고 변경 사항을 철저하게 관리하는 프로세스를 도입하였습니다. 이후, 정기적인 리뷰 회의를 통해 업데이트된 요구사항과 테스트 케이스의 일치 여부를 확인하여 유사한 오류의 재발을 방지하였습니다.
  
  

사례 2: 모바일 금융 애플리케이션 개발 프로젝트

• 상황: 모바일 금융 앱 개발 프로젝트에서는 사용자 요구 사항 변화와 설계 변경이 빈번하게 발생하였습니다.
  초기 계획에 따라 작성된 테스트 케이스가 시간이 지남에 따라 구버전으로 남아있어, 새롭게 반영된 기능과 일치하지 않는 문제가 발견되었습니다.
• 문제점: 변경된 설계가 테스트 케이스에 즉각 반영되지 않아, 신규 기능 통합 시 기존 기능과의 호환성 문제가 발생하고 일부 오류가 시장 출시 후 사용자에게 노출되었습니다.
• QA 대응 및 결과: QA 팀은 개발팀과의 정기적인 스크럼 회의를 통해 요구사항과 설계 변경 사항을 실시간으로 공유받고, 테스트 케이스를 즉각 업데이트하기 시작했습니다. 또한, 자동화 회귀 테스트 도구를 도입하여 변경 사항 반영 후 즉시 전체 시스템 검증을 실시함으로써, 이후 유사한 문제 발생률을 크게 낮추는 성과를 얻었습니다.

스크럼 회의는 애자일 방법론인 스크럼 프레임워크 내에서 팀원들이 짧고 집중적으로 진행 상황을 공유하고 장애물을 해결하기 위해 마련된 데일리 스탠드업 미팅이라고도 부릅니다.

 

1. 스크럼 회의란?

• 정의: 스크럼 회의는 스크럼 팀의 모든 구성원이 매일 짧은 시간(일반적으로 15분 내외) 모여 진행 상황을 공유하고 당면한 문제나 장애물을 빠르게 파악하는 미팅입니다.
• 기본 개념: 회의를 ‘스탠드업’ 형식으로 진행하는 이유는 짧고 집중적인 대화가 이루어지도록 하여 불필요한 논의를 최소화하기 위함입니다.

2. 스크럼 회의의 목적

• 진행 상황 공유: 각 팀원이 어제 무엇을 완료했으며, 오늘은 무엇을 할 것인지에 대해 간략하게 보고합니다.
• 장애물(Impede Identifying) 파악: 진행 중에 발생한 문제나 장애물을 팀원들과 공유하여, 빠른 해결 방안을 논의하고 지원을 요청합니다.
• 팀의 동기 부여 및 조율: 팀원들 간의 투명한 소통을 통해 목표 달성을 위한 협업을 촉진하고, 전체 팀의 우선순위를 재확인합니다.

3. 스크럼 회의의 형식과 진행 방식

• 시간 및 장소:
  • 데일리 스탠드업(Scrum Daily): 보통 매일 같은 시간에 진행되며, 장소는 물리적 회의실이나 온라인 화상회의 공간을 사용합니다.
  • 시간 제한: 15분 정도로 유지하여, 긴 회의로 이어지지 않도록 합니다.
• 주요 질문: 각 팀원은 다음 세 가지 질문에 대해 간략하게 답변합니다.
  1. 어제 무엇을 했는가? → 전날 수행한 작업 내용과 완료 여부 보고.
  2. 오늘 무엇을 할 것인가? → 당일 계획과 목표 공유.
  3. 어떤 장애물이 있는가? → 작업 진행에 있어서 방해가 되는 문제나 해결이 필요한 사항 공유.
• 진행 순서 및 역할:
  • 스크럼 마스터: 회의를 주도하며 시간 관리를 책임집니다. 논의가 필요한 중요한 이슈가 있다면 별도로 심도 있는 논의를 후속 미팅으로 분리합니다.
  • 팀원: 각자의 진행 상황을 간단명료하게 보고합니다.
  • 제품 소유자(Product Owner): 제품 관련 긴급 사항이나 우선순위 변경 사항이 있을 경우, 회의 중 전달할 수 있습니다.

4. 주요 참여자 및 역할

• 스크럼 팀원: 자신의 작업 진행 상황과 당면 과제를 공유하며, 다른 팀원의 보고 내용을 경청합니다.
• 스크럼 마스터: 회의를 원활하게 진행하도록 도와주고, 팀이 스크럼 규칙을 준수하도록 관리합니다. 장애물에 대해 즉각적으로 지원하거나 문제를 해결할 수 있도록 조율합니다.
• 제품 소유자: 필요에 따라 회의에 참여해 중요 변경 사항이나 고객의 피드백을 공유하고, 팀의 우선순위를 재조정할 수 있도록 지원합니다.

5. 스크럼 회의의 장점 및 주의사항

장점

• 빠른 정보 공유와 투명성: 팀 내 모든 구성원이 현재 진행 상황과 난관을 공유함으로써, 서로의 작업 상황을 실시간으로 파악할 수 있습니다.
• 문제 해결 촉진: 장애물이나 문제를 빠르게 인지하여, 스크럼 마스터나 관련 팀원이 즉각 지원할 수 있도록 합니다.
• 팀워크 강화: 짧은 미팅을 통해 팀원 간의 결속력을 다지고, 협업을 촉진할 수 있습니다.

주의사항

• 회의 시간 준수: 시간이 길어지면 효율이 떨어지므로, 15분을 넘기지 않도록 주의해야 합니다.
• 불필요한 논의 배제: 심도 있는 토론이 필요한 이슈는 별도의 회의로 분리하여 진행해야 하며, 데일리 스탠드업에서는 핵심 정보 공유에 집중해야 합니다.
• 준비 및 사전 공유: 팀원들이 미리 자신의 진행 상황을 정리해 오도록 하여, 회의가 원활하게 진행되도록 해야 합니다.

6. 결론

스크럼 회의는 팀원들이 매일의 진행 상황을 공유하고 문제를 신속하게 파악하여, 팀 전체가 목표에 집중할 수 있도록 돕는 중요한 애자일 속도 향상 도구입니다. 짧고 집중적인 회의를 통해 투명성을 높이고, 문제 해결과 협업을 촉진함으로써 소프트웨어 개발 프로젝트의 성공적인 진행에 기여합니다.

 

---

 

개발 수명주기 모델에서 테스팅을 수행할 때, QA 엔지니어는 요구사항 및 설계 문서의 철저한 검토, 변경 관리와 테스트 케이스 업데이트, 단계별 테스트 준비와 실행, 팀 간 긴밀한 커뮤니케이션, 그리고 자동화 테스트 도구의 적극 활용 등에 유의해야 합니다.

실제 사례에서 보듯 초기 단계에서의 누락이나 의사소통의 미흡이 후반 단계에서 큰 문제로 이어질 수 있으므로, 이러한 부분들을 사전에 철저하게 관리하는 것이 제품 품질과 안정성 확보에 큰 역할을 합니다.