Mobile menu

Requirements Management 교훈: 단위 변환 실패 사례

Mihajlo Djordjevic

| 작성 날짜: 2026/08/10 월요일

At a Glance

세 가지 단위 변환 사례는 엔지니어링 작업을 올바르게 이끌기 위해 숫자에 단순한 값 그 이상이 왜 필요한지를 보여줍니다.

Go Deeper with AI:

하드웨어 제품 개발에서는 엔지니어들이 매일 숫자를 주고받습니다. 어떤 값은 엔지니어에게서 도면으로 이동하고, 어떤 값은 사양에서 부품으로 이어지며, 또 어떤 값은 팀에서 공급업체로 전달됩니다. 대부분의 경우 이는 문제없이 작동합니다. 모두가 그 숫자의 의미와 사용된 단위를 알고 있기 때문입니다.

위험은 그 값이 인수인계 지점을 넘어갈 때 나타납니다. 양쪽이 그것을 같은 방식으로 읽지 않을 수 있기 때문입니다. 한쪽은 파운드를 기준으로 작업하는데 다른 쪽은 킬로그램을 예상할 수 있습니다. 어떤 문서는 예전의 야드파운드법 설계를 사용하고 있는데, 새 프로젝트는 미터법일 수도 있습니다. 숫자 자체는 양쪽 모두에게 맞아 보일 수 있지만, 더 이상 같은 의사결정을 이끄는 값은 아닙니다.

아래의 세 가지 엔지니어링 사례는 이런 일이 얼마나 쉽게 발생할 수 있는지를 보여줍니다:

세 가지 사례, 하나의 패턴

서로 다른 30년에 걸친 세 가지 엔지니어링 실패 사례는, 형태는 달라도 동일한 인수인계 문제를 보여줍니다. 각 사례에서 숫자는 워크플로의 한 부분에서 다른 부분으로 이동했습니다. 사용자에게는 그 숫자가 맞아 보였지만, 실제로는 두 가지 측정 체계가 동시에 작동하고 있었습니다. 인수인계 과정에서 그 숫자가 어떤 단위를 사용하는지 명확히 하지 못했던 것입니다.

에어 캐나다 143편: Gimli Glider

첫 번째 예는 1983년의 Gimli Glider입니다. 이 사례는 항공사인 에어 캐나다가 야드파운드법에서 미터법으로 전환하던 중 어떤 일이 벌어졌는지를 보여줍니다. 몬트리올에서 에드먼턴으로 향하던 보잉 767인 143편은 에어 캐나다의 첫 번째 미터법 항공기였습니다.

그날 연료량 표시 시스템(FQIS)이 작동하지 않았기 때문에 승무원들은 연료를 수동으로 측정했습니다. 이들은 나머지 기체들에서 표준으로 쓰이던 리터당 1.77파운드의 급유 밀도 값을 사용했습니다. 그러나 해당 미터법 767에는 이 값이 리터당 킬로그램 단위로 필요했고, 올바른 수치는 약 0.8이었습니다.

항공기는 승무원이 예상한 양의 절반 정도의 연료만 싣고 이륙했고, 그 결과 비행 중 두 엔진이 모두 정지했습니다. 다행히 조종사들은 기체를 안전하게 착륙시킬 수 있었습니다.

Mars Climate Orbiter

그로부터 16년 후, Mars Climate Orbiter는 영국식 단위를 미터법으로 변환하지 못해 발생한 항법 오류로 인해 손실되었습니다. Lockheed Martin의 소프트웨어는 추력기 데이터를 pound-force second 단위로 보냈습니다. NASA의 항법 소프트웨어는 이를 newton-second로 기대했는데, 두 단위는 4.45배 차이가 납니다.

이 우주선은 화성 상공 150~200킬로미터 궤도를 돌아야 했습니다. 그러나 실제로는 약 57킬로미터까지 떨어졌고, 화성 대기에서 소실되었습니다.

도쿄 디즈니랜드의 Space Mountain 롤러코스터

2003년, 도쿄 디즈니랜드의 Space Mountain 롤러코스터에서도 설계 도면을 통해 유사한 문제가 드러났습니다. 이 놀이기구는 1995년에 야드파운드법에서 미터법으로 다시 도면화되면서 차축 직경이 44.14밀리미터에서 45밀리미터로 변경되었습니다. 그러나 이전 도면이 사용 중지되지 않았고, 그 결과 두 세트의 설계 도면이 존재하게 되었습니다.

2002년에 새로운 차축 세트를 다시 주문할 때, 주문은 1995년 이전 설계 버전을 기준으로 이루어졌습니다. 그 결과 부품 크기가 더 작게 제작되었습니다. 0.86밀리미터 차이로 인해 베어링 간극이 의도보다 훨씬 커졌고, 몇 달간 사용한 뒤 차축이 파손되었습니다.

이 세 사례 모두에서 숫자 자체는 의심스러워 보이지 않았습니다. 문제는 그 숫자가 다음 엔지니어링 단계의 기준이 되는 순간 시작되었고, 그 단위나 출처가 충분히 명확하지 않았다는 데 있었습니다.

이 그림이 주는 교훈은 분명합니다. 값은 모두에게 맞아 보일 수 있어도 여전히 틀릴 수 있습니다. 인수인계의 양쪽이 같은 단위에 합의하고 있습니까?

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

대부분의 하드웨어 팀은 항공기를 운항하거나 우주선을 발사하지 않습니다. 하지만 유사한 인수인계는 매일 일어납니다. 값은 요구사항에서 도면으로, 사양에서 부품으로, 또는 팀에서 공급업체로 이동합니다. 각 인수인계 단계에서 단위는 반드시 숫자와 함께 유지되어야 합니다. 다음의 세 가지 실천 방법이 도움이 될 수 있습니다:

모든 요구사항 값에 단위를 명시하세요

숫자만으로는 충분하지 않습니다. “45”만으로는 다음 사람이 무엇을 제작하거나 시험해야 하는지 알 수 없습니다. “45 mm”라고 해야 그 숫자에 의미가 생깁니다. 항상 값 옆에 단위를 함께 두십시오. 이것은 단순한 서식 문제가 아니라 요구사항의 일부입니다.

엔지니어링 인수인계에 책임자를 지정하세요

단위 혼선은 정보가 한 팀에서 다른 팀으로 이동할 때 자주 발생합니다. 한쪽은 한 기준 문서를 바탕으로 작업하는데, 다른 쪽은 또 다른 기준을 예상할 수 있습니다. 이런 인수인계에는 명확한 책임자가 필요합니다. 값이 후속 프로세스에 사용되기 전에, 누군가는 단위 체계, 데이터 형식, 원본 문서를 확인해야 합니다.

요구사항과 근거를 추적 가능하게 유지하세요

값이 변경되면 팀은 무엇이 그 값에 의존하는지 찾아낼 수 있어야 합니다. 즉, 요구사항, 도면, 부품, 시험, 근거가 서로 분리된 채 존재해서는 안 됩니다. 추적성은 어떤 값이 어디서 왔는지, 무엇이 그 값을 사용하는지, 그리고 값이 바뀔 때 무엇을 검토해야 하는지를 팀이 파악하도록 도와줍니다.

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

더 나은 요구사항 워크플로는 숫자, 그 단위, 책임자, 원본 문서를 서로 가깝게 연결해 둡니다. 값을 스프레드시트, 도면, 사양서에 흩어져 있는 느슨한 숫자로 취급하지 않습니다.

이 점은 특히 인수인계에서 중요합니다. 값이 요구사항에서 설계 작업이나 검증 단계로 이동할 때, 다음 담당자는 그 값의 의미, 사용 단위, 출처를 확인할 수 있습니다. 값이 바뀌면 팀은 무엇을 검토해야 하는지도 찾아낼 수 있습니다.

Altium Requirements Portal은 요구사항, 책임 관계, 추적성, 검증 작업을 하나의 공유 환경에 유지함으로써 이러한 워크플로를 지원합니다. 이것이 엔지니어의 판단을 대체하는 것은 아닙니다. 대신 값이 후속 단계에서 사용되기 전에 단위, 책임자, 관련 엔지니어링 맥락을 계속 보이도록 도와줍니다.

핵심 요점

단위 혼선은 대개 인수인계에서 시작됩니다. 즉 값이 다른 팀, 문서 또는 시스템으로 이동할 때, 그 단위가 명확히 전달되지 않을 때 발생합니다.
숫자가 다음 엔지니어링 단계의 기준이 되기 전에, 팀은 그 값이 어디서 왔고 누가 책임지는지 알고 있어야 합니다.
추적성은 값이 변경되거나 후속 단계로 넘어가기 전에 무엇이 그 값에 의존하는지 팀이 파악하도록 도와줍니다.

프로젝트의 모든 숫자는 완전합니까?

이 모든 사건은 예방할 수 있었습니다. 더 뛰어난 엔지니어링이 아니라, 인수인계 시점에 명확한 질문을 던졌다면 말입니다:

요구사항의 모든 값에 단위가 포함되어 있습니까?
팀 간의 모든 인터페이스에 대해 책임지는 사람이 있습니까?
현재 유효한 사양서 버전이 무엇인지 분명합니까?
내일 어떤 것이 바뀐다면, 무엇을 검토해야 하는지 프로세스가 보여줄 수 있습니까?

이제 여러분의 프로젝트에도 같은 질문을 해보십시오. 이 중 어느 하나라도 답이 “아마도”라면, 이미 어디서부터 시작해야 할지 알고 계신 것입니다.

팀 전체가 사용할 수 있는 요구사항 관리 도구로, 모든 인수인계 단계에서 중요한 엔지니어링 정보를 명확하고 쉽게 점검할 수 있도록 하세요.

Requirements Portal 시작하기 →

자주 묻는 질문

엔지니어링 프로젝트에서 단위 변환 오류는 왜 발생하나요?

이런 혼선은 대개 계산 실수에서 비롯되지 않습니다. 값이 팀, 도구, 문서 사이를 이동하는 인수인계 지점에서 발생합니다. 한쪽은 그 값이 어떤 단위라고 가정하지만, 다른 쪽은 다른 단위로 읽을 수 있습니다. 값 자체는 여전히 맞을 수 있지만, 잘못된 가정을 기준으로 맞는 값인 것입니다.

완전한 요구사항 값에는 무엇이 포함되어야 하나요?

완전한 요구사항 값에는 숫자, 단위, 그리고 그것을 올바르게 사용하는 데 필요한 맥락이 포함되어야 합니다. 예를 들어 “45”만으로는 충분하지 않고, “45밀리미터”라고 해야 합니다. 또한 팀은 그 값이 적용되는 조건, 원본 문서, 그리고 그 요구사항의 책임자가 누구인지도 알아야 할 수 있습니다.

추적성은 인수인계 실수를 줄이는 데 어떻게 도움이 되나요?

추적성은 어떤 값과 그 값에 의존하는 모든 요소를 연결합니다. 즉 상위 요구사항부터 그 아래의 부품, 시험, 그리고 책임자까지 이어 줍니다. 값이 변경되면 이러한 연결을 통해 무엇을 추가로 검토해야 할지 더 쉽게 찾을 수 있습니다. 이렇게 하면 오래된 사양, 불명확한 단위, 또는 구식 시험이 실수로 계속 사용될 가능성을 줄일 수 있습니다.

Altium's Requirements Solutions Explore Requirements Portal Guide to Requirements Portal Requirements Documentation

작성자 정보

Mihajlo Djordjevic is an expert in requirements management and systems engineering workflows. He brings over six years of experience in hardware, embedded systems, and technical content creation, with a background in writing educational and product-focused content for embedded development tools, PCB design workflows, and electronics engineering audiences. He is passionate about making complex engineering topics easier to understand and turning them into clear, practical content that helps technical teams improve the way they develop products.

더 많은 콘텐츠 Mihajlo Djordjevic