팀이 추적성 편차를 막기 위해 시도하는 세 가지 방법 – 요구사항 공학에서 미래에 대비한 아키텍처 확보
툴체인을 연결하여 추진력을 유지하고, 전체 요구사항 공학 프로세스 전반에 걸쳐 원활한 통합을 실현하십시오
Iain Cunningham이 집필한 이 미니 시리즈의 4부에서는, 엄격한 규율이나 경직된 통제만으로는 추적성 편차를 막기에 결코 충분하지 않은 이유를 살펴봅니다.
여러분은 미래의 과제를 해결하기 위해 복잡한 시스템을 구축합니다. 그러나 초기 의도가 희미해지고 툴체인이 연결을 끊으면, 조직은 종종 선의에서 비롯된 전략을 도입하지만 실제 배포 환경에서는 기대에 미치지 못하는 경우가 많습니다. 우리는 엔지니어링에는 추측이 아닌 명확성이 필요하다고 믿습니다. 규율, 통제, 공유 구조가 각각 단독으로 적용될 때 왜 실패하는지 알아보고, 역할, 버전, 시간을 초월하여 진정한 검증을 지원하는 미래 지향적인 아키텍처를 구축하는 방법을 배워보세요.
귀 조직은 어떤 방식을 가장 많이 활용해 왔습니까? 더 엄격한 규칙, 더 강력한 control 객체, 아니면 더 나은 구조 중 어느 것입니까?
지금까지 이 시리즈에서는 분리된 시스템 간에 의도가 희미해지는 이유, 모든 사용자를 위한 단일 사용자 인터페이스가 종종 한계에 부딪히는 이유, 그리고 추적 가능성이 대개 최소한 세 가지 유형의 사용자에게 서비스를 제공해야 하는 이유를 살펴보았습니다. 추적 가능성을 개선하기 위해 일반적으로 어떤 조치가 취해질까요? 대개 조직은 다음 세 가지 전략 중 하나를 배포합니다:
추적성 편차를 방지하기 위한 세 가지 일반적인 접근 방식
- 추적성을 강제하는 규율: 팀은 요구사항, 설계, 검증 산출물 간의 연계성을 유지하기 위해 엄격한 규칙을 설정합니다. 초기에는 효과적이지만, 특히 반복적 개발 방식에서 요구사항이 진화함에 따라 업무 부담이 금세 감당하기 힘든 수준에 이릅니다. 처음에는 규율로 시작했던 것이 결국 고된 업무로 변질되어, 실제 엔지니어링 작업과 직접적으로 경쟁하게 됩니다.
- 워크플로우 및 승인 단계를 통한 통제: 이 접근 방식은 활동을 공식화하여 위험을 줄이는 것을 목표로 합니다. 실제로는 진행 속도를 늦추고 비정기적인 사용자들의 참여 의욕을 떨어뜨립니다. 검증 증거가 파편화되고, 언뜻 보기에는 추적 가능성이 완벽해 보이지만 시간이 지남에 따라 구조와 증거가 연결을 끊어 신뢰도는 여전히 낮습니다.
- 공유 구조를 통한 일관성: 공통 데이터 백본을 통해 가공품을 연결하는 방식이 가장 큰 잠재력을 지니지만, 이는 요구사항에서 test 케이스로, 다시 요구사항으로 이어지는 완전하고 버전 정보를 반영하는 체인을 지원할 때에만 가능합니다. 이것이 없다면, 아무리 잘 구조화된 시스템이라도 신뢰하기 어려워집니다. 특히 이질적인 툴 생태계 전반에 걸쳐 서로 다른 역할이 서로 다른 형태의 접근 권한을 필요로 할 때 더욱 그렇습니다.
이러한 접근 방식들은 실무에서 추적성이 어떻게 사용되고 필요한지를 충분히 고려하지 못하기 때문에, 그 결과는 뻔합니다. 신뢰도는 급격히 떨어지고, 재작업량은 늘어납니다. 팀원들은 무엇이 검증되었는지뿐만 아니라, 언제 검증되었는지, 그리고 어떤 버전의 요구사항을 기준으로 검증되었는지에 대해서도 의문을 품기 시작합니다. 결국 원래 예정되었던 출시 일정은 현실적으로 달성하기 어려워집니다.
대개 경량화 방식을 채택한 사용자들이 맥락을 하나하나 맞춰야 하는 수고를 피하려다 보니 이러한 문제들을 가장 먼저 드러냅니다. 요구사항 엔지니어들은 이미 명확해야 할 내용을 다시 해석하고 설명해야만 하며, 구조, 적용 범위, 검증 증거 간의 간극을 메워야 하는 상황에 또다시 내몰리게 됩니다.
더 깊은 차원에서 보면, 이런 과정은 필요하지 않아야 합니다. 엔지니어링은 단순히 의사결정을 내리기 위해 검증 맥락을 끊임없이 재구성해야 하는 노력이 되어서는 안 됩니다. 규율, 통제, 구조를 개별적으로 적용하는 것만으로는 충분하지 않습니다. 추적성은 역할, 버전, 시간을 초월하여 작동하도록 설계되어야 합니다.
다음 기사에서는 무엇이 실패하는지 파악하는 단계에서 벗어나, 무엇이 실제로 효과가 있는지를 정의하는 단계로 넘어가겠습니다. 실제delivery 조건 하에서 추적성 접근 방식이 유효한지 평가할 수 있는 간단한 방법을 살펴보겠습니다.
그동안 실제로 어떤 사례를 목격하셨나요? 여러분의 환경에서는 ‘규율’, ‘control 객체’, ‘일관성’ 중 어떤 접근 방식이 먼저 도입되었나요?
시간이 지남에 따라 도움이 되었나요, 아니면 단순히 업무 부담을 다른 곳으로 옮긴 것일 뿐이었나요? 토론에 참여하여 시스템 설계의 미래를 함께 만들어 가세요. LinkedIn에서 Iain Cunningham을 팔로우하고, 그의 원문 기사 댓글란에 여러분의 경험을 공유해 주세요.