“모두를 위한 단일 도구”가 실패하는 이유 – 요구사항 공학에서 미래 지향적인 아키텍처 확보하기
툴체인을 연결하여 추진력을 유지하고 전체 요구사항 공학 프로세스 전반에 걸쳐 원활한 통합을 실현하십시오
Iain Cunningham이 작성한 이 미니 시리즈의 2부에서는 분산된 시스템에 대한 일반적인 대응 방안을 살펴봅니다.
미래의 과제를 해결하기 위해 복잡한 시스템을 구축합니다. 그러나 초기 의도가 희미해지고 툴체인이 연결을 끊으면, 조직은 종종 모든 구성원이 사용할 수 있는 단일 통합 도구를 찾게 됩니다. 하지만 이러한 접근 방식은 종종 팀의 부담을 가중시킵니다. 우리는 엔지니어링에는 추측이 아닌 명확성이 필요하다고 믿습니다. 다양한 역할에 단일 인터페이스를 강요하는 것이 왜 마찰을 일으키는지 알아보고, 개별 워크플로를 존중하면서도 원활한 통합을 유지하는 미래 지향적인 아키텍처를 구축하는 방법을 배워보세요.
일을 더 쉽게 하도록 디자인된 도구가 오히려 일을 더 어렵게 만들고 있다는 사실을 처음 깨달은 순간은 언제였나요?
요구사항 엔지니어들에게 이는 매력적으로 들릴 수 있습니다. 내보내기 작업이 줄어들고, 수동으로 설명해야 할 부분도 줄어듭니다. 요구사항, MBSE, 설계, 구현, 때로는 테스트 및 검증에 이르기까지 전반적으로 추적성이 향상됩니다. 무엇보다도, 그들이 ‘프로세스의 빈틈을 메우는 역할’을 수행해야 하는 회의에 참석할 필요가 없어집니다. 하지만 이러한 접근 방식은 종종 중요한 현실을 간과합니다. 문제는 노력의 양이 아닙니다. 바로 불일치입니다.
문제는 사람들이 이러한 도구를 사용하기를 꺼려한다는 것이 아닙니다. 문제는 그 도구들이 실제로 작동하는 방식과 맞지 않는 방식으로 사용하도록 요구받고 있다는 점입니다. 각기 다른 역할은 요구사항 및 추적성과 근본적으로 다른 방식으로 상호작용합니다. 요구사항 엔지니어는 구조와 의도를 유지 관리합니다. 엔지니어와 팀 리더는 변경 시 그 영향을 평가합니다. 테스트 및 검증 팀은 커버리지와 검증 증거를 파악해야 합니다. 의사결정권자와 규정 준수 관련 이해관계자들은 요구사항이 단순히 정의된 것뿐만 아니라 명백하게 검증되었다는 확신을 필요로 합니다.
모든 사람에게 단일한 경험을 강요하면 그 결과는 뻔합니다.
“단일 도구” 접근 방식이 가져오는 가시적인 효과
- 가끔 이용하는 사용자들이 사용자 인터페이스 사용에 어려움을 겪기 때문에 리뷰 작성 속도가 느려집니다.
- 관계자들이 관심을 잃고 오프라인 사본을 요청합니다.
- 기술적으로는 추적 가능성이 존재하지만, 팀들이 이를 일관되게 사용하지 않습니다.
- 요구사항 엔지니어들이 여전히 신뢰할 수 있는 정보원 역할을 하기 때문에 질문이 다시 그들에게 돌아갑니다.
시간이 지남에 따라 요구사항 엔지니어들은 종종 ‘인간 추적성 매트릭스’가 되어, 시스템과 역할, 그리고 누락된 맥락 사이의 간극을 메워야 하는 기대를 받게 됩니다. 더 깊이 들여다보면, 이는 피할 수 있는 문제처럼 보입니다. 엔지니어링은 단순히 명확성을 유지하기 위해 임시방편에 의존해서는 안 됩니다.
규제 산업에서는 이로 인해 추가적인 위험이 발생합니다. 추적성은 단순히 협업을 위해서만 사용되는 것이 아닙니다. 각 요구사항이 test 케이스와 검증 증거를 포함한 검증과 연결되어 있음을 입증하는 데에도 사용됩니다. 이러한 연결 고리가 여러 도구에 분산되어 있다면, 팀은 시간적 압박 속에서 커버리지와 증거를 수동으로 재구성해야만 합니다. 규제 환경에서는 이는 선택 사항이 아닙니다. 모든 요구사항이 단순히 정의된 것이 아니라 검증되었음을 입증할 수 있어야 합니다.
현대적인 반복적 개발 방식에서 이 과제는 시간과 버전 관리 문제로 인해 더욱 심화됩니다. 요구사항, test 케이스, 검증 증거는 여러 반복 과정을 거치며, 종종 병렬 구조의 개발 브랜치 전반에 걸쳐 진화합니다. 단순히 요구사항이 검증되었는지 묻는 것만으로는 더 이상 충분하지 않습니다.
팀은 또한 다음 질문에 답해야 합니다:
- 어떤 버전의 요구사항이 검증되었는가?
- 해당 버전에 어떤 test 케이스가 적용되는가?
- 어떤 실행 증거가 해당 검증을 뒷받침하는가?
버전 기반 추적성이 없다면 커버리지는 불분명해지고 증거는 신뢰할 수 없게 됩니다. 이러한 질문을 해결해야 하는 부담은 종종 요구사항 엔지니어에게 돌아갑니다. 이 시리즈의 이 시점에서 한 가지 분명한 사실이 드러나야 합니다. 쟁점은 도구 자체가 아니라, 서로 다른 역할들이 추적성과 어떻게 상호작용해야 하는지에 대한 기대치입니다.
돌이켜보면, 여러분의 환경에서 “모두를 위한 단일 도구” 접근 방식이 실패하기 시작했다는 첫 징후는 무엇이었나요?
대화에 참여하여 시스템 설계의 미래를 함께 만들어 가세요. LinkedIn에서 Iain Cunningham을 팔로우하고, 그의 원문 기사 댓글란에 여러분의 경험을 공유해 주세요.