요구사항 관리에서 얻은 교훈: Ariane 5 Flight 501

Ariane 5 Flight 501 참사는 과거 프로젝트의 요구사항, 엔지니어링 설계, 테스트를 있는 그대로 재사용하기 전에 왜 항상 한 번 더 신중히 생각해야 하는지를 보여줍니다. 

하드웨어 제품 개발에서는 이전 프로젝트의 요구사항, 소프트웨어 루틴, 테스트 케이스, 설계 결정을 재사용하는 일이 흔합니다. 이는 시간을 절약해 주지만, 그러한 선택이 타당했던 조건이 여전히 그대로 적용될 때에만 그렇습니다.

Ariane 5 Flight 501은 1996년 6월 4일 유럽의 Ariane 5 로켓이 수행한 첫 비행이었습니다. 이 로켓은 이전 유럽 로켓인 Ariane 4에서 성공적으로 동작했던 관성 기준 소프트웨어의 일부를 재사용했습니다. 하지만 Ariane 5는 다른 비행 프로파일을 따랐고, 어떤 값 하나가 소프트웨어가 예상한 범위를 초과했으며, 그 결과 로켓은 발사 후 1분도 채 되지 않아 파괴되었습니다.

교훈은 단순하지만 쉽게 잊힙니다: 과거 프로젝트의 작업을 재사용하기 전에, 동일한 가정과 동작 조건이 새 프로젝트에도 여전히 적용되는지 확인해야 합니다.

핵심 요점

• 검증된 요구사항, 소프트웨어, 테스트, 설계 결정을 재사용하면 시간을 절약할 수 있지만, 기존 맥락은 반드시 다시 검토해야 합니다.
• 다른 제품에서 동일한 요구사항을 입증하는 데 사용하기 전에 재사용된 테스트 케이스를 검토하세요.
• 요구사항, 테스트 절차, 증빙, 상태를 서로 연결해 두면 위험을 줄일 수 있습니다.

Ariane 5 발사에서 무슨 일이 있었나

1996년 6월 4일, Ariane 5는 유럽우주국의 Cluster 연구 위성 4기를 탑재하고 프랑스령 기아나의 쿠루에서 첫 비행을 했습니다. 임무는 1분도 채 지속되지 않았습니다. 비행 시작 약 37초 후, 로켓은 계획된 경로에서 벗어났고 파괴되었습니다.

문제는 로켓의 온보드 컴퓨터에 자세 및 속도 데이터를 보내는 관성 기준 시스템에서 시작되었습니다. Ariane 5는 Ariane 4의 소프트웨어를 재사용했는데, 여기에는 발사 후 약 40초 동안 계속 활성 상태로 유지되는 정렬 루틴도 포함되어 있었습니다. 이 루틴은 Ariane 4에서는 잘 동작했지만, Ariane 5는 다른 비행 프로파일을 따랐습니다.

이처럼 다른 프로파일 때문에, 여러 일이 매우 짧은 시간 안에 연쇄적으로 발생했습니다:

• 수평 속도 값이 소프트웨어의 예상보다 더 커졌습니다.
• 소프트웨어는 그 값을 64비트 부동소수점 수에서 16비트 부호 있는 정수로 변환하려 했지만, 더 이상 그 범위에 들어가지 않았습니다.
• 변환에서 오버플로가 발생했고, 관성 기준 시스템은 이를 오류로 처리해 종료되었습니다.
• 백업 시스템도 동일한 소프트웨어를 실행하고 있었기 때문에 같은 이유로 종료되었습니다.
• 유효한 비행 데이터가 없어진 온보드 컴퓨터는 대신 진단 데이터를 사용했고, 잘못된 비행 명령을 내렸으며, 결국 로켓은 파괴되었습니다.

이 사례가 요구사항 관리 측면에서 유용한 이유가 바로 여기에 있습니다. 재사용된 소프트웨어는 이전에는 잘 동작했지만, 이전 로켓에서 가져온 한 가지 가정을 포함하고 있었습니다. 즉, 이 값이 안전한 범위 안에 머물 것이라는 가정입니다. Ariane 5는 그 가정을 둘러싼 맥락을 바꾸었고, 따라서 그 가정은 새 시스템에서 다시 보이도록 하고 재검토했어야 했습니다.

이 사례는 재사용된 엔지니어링 작업에도 여전히 한 가지 단순한 확인이 필요하다는 점을 상기시켜 줍니다. 즉, 그 작업의 기반이 되는 가정이 새 시스템에서도 여전히 참인가?

하드웨어 팀이 Ariane 5 사례에서 배울 수 있는 점

대부분의 하드웨어 팀은 로켓을 만들지는 않지만, 검증된 작업을 늘 재사용합니다. 예를 들어 이전 제품의 PCB 블록을 새 설계에 복사할 수 있습니다. 펌웨어 루틴이 새 하드웨어 리비전으로 옮겨질 수도 있습니다. 전원 아키텍처가 바뀐 뒤에도 테스트 절차가 그대로 유지될 수 있습니다. 

이는 정상적인 엔지니어링 작업입니다. 재사용은 팀이 더 빠르게 움직이도록 돕습니다. 중요한 단계는 요구사항, 가정, 검증 체크가 여전히 새 시스템과 맞아떨어지는지 확인하는 것입니다.

재사용되는 요구사항 검토

한 제품에서 잘 작동했던 요구사항이라고 해서 다음 제품에서도 자동으로 유효하다고 봐서는 안 됩니다. 문구는 여전히 맞아 보일 수 있지만, 그 주변의 동작 조건은 바뀌었을 수 있습니다. 예를 들어 전류 제한, 열 범위, 인터페이스 제약은 어떤 설계에서는 안전할 수 있지만 다른 설계에서는 재검토가 필요할 수 있습니다. 요구사항을 재사용하기 전에 팀은 새 제품이 여전히 동일한 가정 안에서 동작하는지 확인해야 합니다.

가정을 검증 절차에 추적 연결하기

가장 중요한 엔지니어링 가정 중 일부는 정식 요구사항으로 문서화되지 않는 경우가 많습니다. 그런 내용은 설계 노트, 오래된 테스트 계획, 혹은 누군가의 기억 속에 남아 있습니다. 작업이 재사용될 때 이는 위험 요소가 될 수 있습니다. 어떤 가정이 설계 결정에 영향을 준다면, 팀은 그것을 검증 체크와 연결할 수 있는 방법이 필요합니다. 그렇지 않으면, 처음에 그것이 왜 안전했는지에 대한 이유를 보지 못한 채 그 결정을 재사용하기 쉬워집니다.

요구사항이 바뀔 때 테스트 검토

이전 프로젝트에서 통과한 테스트 케이스가 다음 프로젝트에서도 항상 같은 것을 입증하는 것은 아닙니다. 요구사항이 바뀌거나, 요구사항을 둘러싼 시스템이 바뀌면, 관련 테스트 절차도 함께 바뀌어야 할 수 있습니다. 이는 팀이 테스트 케이스, 승인 기준, 규정 준수 증빙을 재사용할 때 특히 중요합니다.

연결된 요구사항 워크플로가 도움이 되는 방식

더 나은 요구사항 워크플로는 요구사항을 독립된 텍스트 한 줄로 취급하지 않습니다. 대신 그 요구사항이 왜 존재하는지에 대한 이유, 그 요구사항이 영향을 미치는 설계 작업, 그리고 그것이 여전히 유효한지 보여주는 검증 작업과 연결된 상태로 유지합니다. 

무언가가 바뀔 때 가장 중요한 것이 바로 이것입니다. 재사용된 요구사항은 여전히 올바르게 보일 수 있지만, 그 뒤에 있는 가정은 더 이상 새 제품과 맞지 않을 수 있습니다. 테스트가 여전히 존재하더라도, 더 이상 올바른 조건을 확인하지 못할 수 있습니다.

연결된 워크플로에서는 팀이 중요한 요소들을 서로 가깝게 유지할 수 있습니다. 즉, 요구사항, 그 배경 맥락, 검증 방법, 절차, 결과, 증빙, 현재 상태를 함께 볼 수 있습니다. 엔지니어는 오래된 문서나 테스트 보고서를 뒤질 필요 없이 무엇이 연결되어 있고 무엇을 다시 검토해야 할 수 있는지 확인할 수 있습니다.

Altium Requirements Portal은 요구사항, 추적성, 담당자, 검증 작업을 하나의 공유 환경에 유지함으로써 이러한 종류의 워크플로를 지원합니다. 이를 통해 팀은 요구사항과 그 주변의 검증 항목이 계속 연결된 상태를 유지하므로, 검증된 작업을 더 큰 확신을 가지고 재사용할 수 있습니다.

여러분의 프로젝트에서 기존 가정은 여전히 참인가?

모든 하드웨어 팀은 검증된 작업을 재사용합니다. 이는 피해야 할 지름길이 아니라, 더 빠르게 개발하고 좋은 엔지니어링 결정을 다음 단계로 이어 가는 실용적인 방법입니다. 

유용한 질문은 재사용된 작업 주변에서 무엇이 달라졌는가입니다:

• 동작 범위가 바뀌었는가? 
• 테스트를 수정해야 하는가? 
• 원래 결정의 기반이 된 가정이 여전히 적용되는가?

팀이 이런 질문에 답할 수 있을 때, 재사용은 더 신뢰하기 쉬워집니다. 요구사항은 홀로 존재하지 않습니다. 그 요구사항의 배경이 되는 이유, 검증 체크, 증빙이 제품 맥락이 바뀔 때 팀이 검토할 수 있을 만큼 충분히 가깝게 유지됩니다. 

이것이 오늘날에도 Ariane 5가 하드웨어 팀에 주는 교훈입니다: 재사용은 그 배경 맥락이 계속 연결되어 있을 때 가장 잘 작동합니다.

팀 전체가 접근할 수 있는 요구사항 관리 도구로 재사용 결정을 더 쉽게 검토하고 더 신뢰할 수 있게 만드세요.

Requirements Portal 시작하기 →

자주 묻는 질문

엔지니어링 작업의 재사용이 위험해질 수 있나요?

엔지니어링 작업의 재사용은 제품 맥락이 바뀌었는데도 원래의 가정, 동작 한계, 검증 체크를 다시 검토하지 않을 때 위험해질 수 있습니다. 겉보기에는 여전히 맞아 보일 수 있지만, 이전 프로젝트에서 그것을 타당하게 만들었던 조건이 더 이상 적용되지 않을 수 있습니다.

요구사항, 테스트 또는 설계 결정을 재사용하기 전에 엔지니어는 무엇을 확인해야 하나요?

팀은 새 제품이 원래 프로젝트와 동일한 동작 조건, 인터페이스, 한계, 승인 기준을 사용하는지 확인해야 합니다. 또한 관련 검증 방법이 새 시스템에서도 여전히 올바른 것을 입증하는지 확인해야 합니다.

요구사항이 재사용될 때 추적성은 어떻게 도움이 되나요?

추적성은 요구사항이 설계 결정, 가정, 테스트 절차, 증빙, 상태와 어떻게 연결되는지 팀이 볼 수 있도록 도와줍니다. 재사용된 작업이 새 프로젝트로 옮겨갈 때, 이러한 연결은 무엇이 여전히 유효하고 무엇을 검토해야 할 수 있는지 더 쉽게 파악하게 해줍니다.