하드웨어 개발에서의 요구사항 엔지니어링

솔직히 말해 요구사항에 흥미를 느끼는 사람은 많지 않습니다. 하지만 모든 하드웨어 팀은 불명확한 요구사항이 초래하는 대가를 경험해 본 적이 있습니다. 늦게 드러나는 재작업이 생기거나, 이해관계자가 실제로 요청한 내용을 반영하지 못한 채 빌드가 완료되는 경우가 그렇습니다. 

요구사항 엔지니어링(RE)은 최종 제품이 올바른 문제를 해결하도록 요구사항을 정의하고, 문서화하고, 관리하는 구조화된 프로세스를 따르는 분야입니다. 이를 제대로 적용하면 실수를 초기에 발견하고, 팀의 정렬을 유지하며, 출하되는 결과물이 실제로 합의된 내용대로 만들어졌다는 확신을 모두에게 제공합니다.

하지만 이 용어는 소프트웨어 엔지니어링과 하드웨어 제품의 시스템 엔지니어링 양쪽에 뿌리를 두고 있기 때문에 자주 혼동됩니다. 

이 글에서는 요구사항 엔지니어링의 명확한 정의와 하드웨어 제품 개발에서의 역할을 설명합니다. 이론적 개요와 함께, 실제 하드웨어 프로젝트에서 어떻게 적용되는지에 대한 실용적 프레임워크, 현실적인 예시, 가장 흔한 함정과 이를 피하는 방법까지 다룹니다.

핵심 요점

• 요구사항 엔지니어링은 하드웨어 팀이 설계 의도를 명확한 요구사항으로 전환하고 팀 전체의 정렬을 유지하도록 도와줍니다.
• 요구사항은 초기 기획과 설계부터 시험, 변경, 최종 문서화에 이르기까지 프로젝트 전반을 이끕니다.
• 좋은 요구사항 프로세스는 개발 팀이 문제를 초기에 발견하고, 비용이 많이 드는 재설계를 피하며, 최종 제품이 합의된 내용을 충족하도록 보장하는 데 도움이 됩니다.

요구사항 엔지니어링이란?

요구사항 엔지니어링은 하드웨어 제품 개발 중 요구사항을 정의, 문서화, 관리하기 위한 체계적이고 규율 있는 접근 방식입니다.

이를 통해 팀은 해결해야 할 문제를 이해하고, 이해관계자의 요구를 명확히 하고 분석하며, 충돌과 트레이드오프를 조정하고, 제품이 달성해야 할 내용을 문서화하며, 제품이 발전함에 따라 이러한 이해를 최신 상태로 유지할 수 있습니다.

실무적으로 요구사항은 이해관계자와 엔지니어링 팀 사이에 무엇을 왜 만드는지, 그리고 최종 제품이 설계 의도를 충족하는지 어떻게 판단할 것인지에 대한 공통된 이해를 만들어 줍니다.

요구사항 엔지니어링의 이점

RE가 제대로 수행되면 오해와 비용이 큰 실수를 방지하고, 팀의 정렬을 유지하며, 최종 제품이 요구사항을 충족하도록 돕습니다.

RE의 주요 이점은 다음과 같습니다.

• 공유된 비전: 이해관계자, 관리자, 엔지니어링 팀이 무엇을 만들고 있는지에 대해 동일한 이해를 갖도록 정렬해 줍니다.
• 명확한 범위: 무엇이 프로젝트 범위에 포함되고 무엇이 포함되지 않는지 명확히 하여, 스코프 크리프(scope creep)로 알려진 통제되지 않은 범위 확장을 방지하는 데 도움이 됩니다.
• 비용이 큰 실수 감소: 요구사항의 문제를 초기에 발견해, 그것이 값비싼 설계 재작업, 새로운 프로토타입 제작, 반복 시험으로 이어지기 전에 대응할 수 있게 합니다.
• 계획 및 일정 수립 개선: 무엇을 만들어야 하는지에 대한 더 명확한 그림을 제공해, 작업량을 산정하고 현실적인 일정을 수립하기 쉽게 합니다.
• 제품 품질 향상: 최종 제품이 합의된 대로 동작하고 요구되는 품질 기준을 충족하도록 돕습니다.

요구사항 엔지니어링 분야의 발전

요구사항 엔지니어링은 시스템 엔지니어링과 소프트웨어 엔지니어링 양쪽에 뿌리를 두고 있습니다. 이 두 계보는 서로 다른 엔지니어링 맥락에서 발전해 왔기 때문에, 출처에 따라 이 용어의 범위가 지금도 약간씩 다를 수 있습니다.

소프트웨어 엔지니어링 맥락에서는 초점이 주로 소프트웨어 개발 요구사항에 맞춰집니다. 즉, 소프트웨어가 무엇을 해야 하는지, 어떻게 동작해야 하는지, 어떤 품질 속성을 충족해야 하는지에 관한 것입니다. 소프트웨어 엔지니어는 기능 요구사항과 비기능 요구사항을 사용자 스토리, 유스 케이스, 인수 기준의 형태로 문서화해 생각합니다. 반면 시스템 엔지니어링 맥락에서는 범위가 더 넓습니다. 여기서 요구사항은 하드웨어, 소프트웨어, 사람, 프로세스, 인터페이스, 운용 조건, 기타 시스템 특성을 포함한 전체 시스템을 의미합니다. 시스템 엔지니어는 시스템 수준 요구사항을 하드웨어, 기구, 전기, 펌웨어, 안전 요소로 할당해 내려보내며, 이를 정형화된 요구사항 문장과 요구사항 추적성 매트릭스로 기록합니다.

하드웨어 개발에서 RE는 이 두 관점을 함께 아우릅니다. 이는 BOM 비용, 열 제약, 제조 한계를 다루기 위해 필요한 시스템 엔지니어링의 엄격성과 다분야적 범위를, 요구사항이 시험 가능하고 개발 전반에 걸쳐 연결된 상태를 유지하도록 하는 소프트웨어 엔지니어링의 생애주기 추적성과 결합합니다.

요구사항 엔지니어링과 관련된 분야

요구사항 엔지니어링은 다른 제품 개발 분야와 밀접하게 관련되어 있으며, 특히 시스템 엔지니어링과 제품 관리와의 연관성이 큽니다.

시스템 엔지니어링

시스템 엔지니어링은 제품을 하나의 완전한 시스템으로 바라봅니다. 시스템 엔지니어는 하드웨어, 소프트웨어, 기계 부품, 테스트와 같은 서로 다른 요소들이 올바르게 함께 작동하고 충돌하지 않도록 보장합니다.

이는 RE와 밀접하게 연결되어 있는데, 요구사항이 이러한 모든 팀에게 제품이 무엇을 달성해야 하는지에 대한 공통 기준점을 제공하기 때문입니다.

비유를 들자면 집을 짓는 것과 같습니다. 기초, 전기, 배관, 난방은 각기 다른 전문가가 담당하지만, 결국 이 모든 요소가 하나의 완전한 구조물로 제대로 맞물리는지 확인할 사람은 필요합니다. 제품 개발에서 시스템 엔지니어링이 바로 그 역할을 합니다.

제품 관리

제품 관리 는 무엇을 왜 만들지 결정하는 데 도움을 줍니다. 제품 관리자는 고객과 대화하고, 시장을 조사하고, 경쟁사를 분석하며, 비즈니스와 협력해 어떤 문제가 해결할 가치가 있는지, 어떤 기능이 가장 중요한지를 결정합니다.

이 역시 RE와 연결되는데, 이러한 상위 수준의 고객 요구와 비즈니스 목표가 제품 요구사항을 정의하는 출발점이 되기 때문입니다.

요구사항 엔지니어링 프로세스의 단계

RE 프로세스는 적용 분야, 참여 인원, 조직에 따라 다양한 방식으로 구성될 수 있습니다. 어떤 프로젝트에서는 활동이 대부분 순차적으로 진행되는 반면, 다른 프로젝트에서는 팀이 더 많은 것을 알아갈수록 반복적으로 수행되고 다시 검토됩니다.

 Requirements Engineering journal에 게재된 한 논문에서 설명하듯, 일반적인 교과서적 접근은 RE 프로세스를 네 가지 핵심 활동(단계)으로 나눕니다.

• 요구사항 도출: 이해관계자와 기타 출처로부터 요구사항을 수집해, 시스템이 무엇을 해야 하고 어떤 조건에서 동작해야 하는지 이해하는 단계입니다.
• 요구사항 분석 및 명세화: 수집한 내용을 검토하고, 불명확하거나 상충하는 정보를 해소하며, 이를 엔지니어링 팀이 사용할 수 있는 명확한 요구사항으로 바꾸는 단계입니다.
• 요구사항 검증: 요구사항이 정확하고 완전하며, 시스템이 달성하려는 바를 제대로 설명하고 있는지 확인하는 단계입니다.
• 요구사항 관리: 시간이 지나면서 요구사항과 그 변경 사항을 추적하는 활동으로, 왜 변경되었는지와 어떤 다른 요구사항, 설계 작업, 시험이 영향을 받는지도 포함합니다.

프로세스에 참여하는 사람들

RE 프레임워크에는 제품이 무엇을 해야 하는지 정의하기 위해 함께 일하는 몇 가지 핵심 역할이 포함됩니다.

• 요구사항 오너: 모호한 이해관계자 요구를 받아 적절한 질문을 던지고, 이를 엔지니어링 팀이 실제 제품 개발에 사용할 수 있는 요구사항 세트로 바꾸는 엔지니어입니다. 보통 시스템 엔지니어, 리드 엔지니어 또는 유사한 책임을 가진 사람이 맡습니다.
• 기술 제품 리더십: 이해관계자/비즈니스 측과 소통하고 그들의 요구를 이해한 뒤, 그 요청을 명확한 제품 목표로 바꾸는 사람들입니다. 여기에는 제품 관리자, 프로그램 관리자 또는 유사한 역할이 포함될 수 있습니다.
• 구현 엔지니어: 정의된 요구사항을 바탕으로 제품을 설계하고 구축하는 엔지니어입니다. 전자, 기계, 소프트웨어 또는 펌웨어 엔지니어가 여기에 포함될 수 있습니다.
• 검증 오너: 요구사항을 어떻게 시험할지 결정하고, 필요한 리뷰와 시험이 완료되도록 보장하는 사람입니다. 검증 엔지니어, 테스트 엔지니어 또는 QA 엔지니어가 여기에 포함될 수 있습니다.

하드웨어 개발을 위한 실용적인 요구사항 엔지니어링 프레임워크

위의 네 가지 활동이 RE 프로세스의 핵심을 정의하지만, 하드웨어 팀에는 이를 프로젝트 전반에 걸쳐 적용할 수 있는 실용적인 방법이 필요합니다.

다음은 하드웨어 개발을 위한 요구사항 엔지니어링 프레임워크를 실무 관점에서 정리한 것으로, 각 단계에서 요구사항이 어떻게 들어맞는지를 보여줍니다.

프로젝트 킥오프: 의도 포착

프로젝트 시작 시 기술 리드는 일반적으로 고객 요청, 제안요청서(RFP), 비즈니스 목표, 비용·크기·일정 제약과 같은 다소 모호한 입력을 받습니다. 예를 들어 고객은 특정 사용 사례를 지원하는 더 작은 장치를 요청할 수 있습니다.

기술 리드는 요구사항 오너와 함께 무엇이 필요한지 명확히 하고, 이러한 입력을 제품이 달성해야 할 바를 설명하는 상위 수준 요구사항으로 전환합니다.

요구사항 엔지니어링: 요구사항 정의

프로젝트 킥오프 단계에서 나온 상위 수준 요구사항은 아직 상세 설계를 하기에 너무 포괄적입니다. 이 단계에서 요구사항 오너는 전체 시스템을 정의하고, 이를 부분과 서브시스템으로 나눈 뒤, 상위 수준 요구사항을 각 부분에 대한 보다 구체적인 요구사항으로 전환합니다.

또한 요구사항 간 충돌이 없는지, 중요한 내용이 빠지지 않았는지, 각각이 명확하고 시험 가능한지도 확인합니다. 그 결과 엔지니어링 팀이 제품 설계의 출발점으로 사용할 수 있는, 합의된 요구사항 세트가 만들어집니다.

구현: 설계 개발

구현 엔지니어는 합의된 요구사항을 바탕으로 제품의 자신이 맡은 부분을 설계하고 구축합니다. 이는 회로도를 작성하는 것일 수도 있고, 3D 부품을 모델링하는 것일 수도 있으며, 소프트웨어나 펌웨어를 작성하는 것일 수도 있습니다. 설계가 발전함에 따라 각 요구사항은 이를 충족하는 설계 기능과 연결됩니다. 이러한 연결은 프로젝트의 추적성을 형성하며, 요구사항 오너가 요구사항이 어떻게 구현되었는지 파악하는 데 도움을 줍니다.

검증 및 확인: 테스트 및 검증

요구사항은 또한 리뷰와 테스트에서 무엇을 확인해야 하는지도 정의합니다. 검증 엔지니어는 각 요구사항을 어떻게 확인할지 정의하고, 구현 엔지니어와 협력해 필요한 리뷰, 측정, 시험을 수행하며, 그 결과를 기록합니다. 이를 통해 제품이 달성해야 했던 내용과 그것을 실제로 달성했는지를 보여주는 증거가 연결됩니다.

변경 관리: 수정 및 반복

요구사항과 제품 설계는 개발 중 자주 변경됩니다. 어떤 요구사항은 충족이 불가능하다는 것이 드러날 수 있고, 어떤 부품은 시장에서 더 이상 구할 수 없게 될 수 있으며, 새로운 제약이 나타날 수도 있습니다. 이런 일이 발생하면 요구사항 오너는 무엇이 변경되었는지, 왜 변경되었는지, 그리고 어떤 요구사항, 설계 부분, 시험이 영향을 받는지를 추적합니다.

문서화 및 인계: 프로젝트 납품

프로젝트가 끝날 무렵, Requirements Owner는 Verification Engineer 및 나머지 팀원들과 함께 요구사항, 설계 검토, 검증 활동을 마무리합니다. 최종 문서는 무엇이 요구되었는지, 무엇이 구축되었는지, 그리고 그것이 어떻게 검증되었는지를 추적 가능하게 기록해야 합니다. 고객, 제조업체, 감사 담당자 또는 이후에도 제품 작업을 계속할 팀은 나중에 이 정보를 필요로 하게 됩니다.

요구사항 엔지니어링 사례

의료기기에서의 요구사항 엔지니어링

요구사항 엔지니어링은 의료 및 케어 기술 제품 전반에 걸쳐 사용됩니다. 요구사항은 개발 전 과정에서 제품과 함께 유지됩니다. 팀은 이해관계자의 요구를 구조화된 시스템 요구사항으로 전환하고, 사양이 변경되더라도 이들을 서로 연결된 상태로 유지하며, 이를 바탕으로 검증을 계획하고 테스트 결과를 문서화합니다.

의료기기에는 규제라는 추가 계층이 존재합니다. 팀은 추적성, 검증, 문서화 및 관련 서류 작업에 더 많은 노력을 기울입니다. 이는 미국의 FDA 21 CFR Part 820 및 EU와 기타 시장의 ISO 13485:2016와 같은 프레임워크에 따른 규제 승인을 지원합니다.

HitIQ 마우스가드는 안전 요구가 모든 기술 사양을 좌우하는 의료용 웨어러블의 한 예입니다. 전체 고객 성공 사례에서 그 방법을 확인해 보세요.

소비자 및 산업용 전자기기에서의 요구사항 엔지니어링

요구사항 엔지니어링의 핵심 프로세스는 소비자 전자기기와 산업용 전자기기 전반에서 유사하지만, 제품은 서로 다른 조건에서 개발됩니다. 스마트 홈 기기나 웨어러블 같은 소비자 제품은 대량으로 판매되고 빠르게 출시됩니다. PLC(Programmable Logic Controller)나 모터 드라이브 같은 산업용 제품은 가혹한 환경에서 수년간 작동해야 합니다.

두 경우 모두 팀은 제품이 수행해야 할 일을 문서화하고, 각 요구사항을 설계에 연결하며, 변경이 생기면 요구사항을 업데이트하고, 이를 기준으로 테스트를 수행합니다.

달라지는 점은 팀이 추가적인 노력을 어디에 투입하느냐입니다. 소비자 전자기기에서는 빠른 변화에 대응하는 데 중점을 둡니다. 요구사항 하나만 잘못 이해해도 보드를 다시 설계해야 할 수 있기 때문입니다. 산업용 전자기기에서는 검증에 더 많은 노력을 기울입니다. 제품이 출하되기 전에 긴 수명과 가혹한 조건에 대해 테스트되어야 하기 때문입니다.

안전 규정을 준수하는 신뢰할 수 있는 하드웨어를 구축하려면 요구사항과 설계 변경을 서로 연결된 상태로 유지하는 것이 핵심입니다. MakeSafe Tools가 이를 어떻게 관리하는지 전체 성공 사례에서 확인해 보세요.

일반적인 요구사항 엔지니어링 함정을 피하는 방법

요구사항 엔지니어링에는 몇 가지 흔한 과제가 따릅니다. 무엇이 잘못될 수 있는지 알고 있으면 문제를 조기에 발견하고 하드웨어 제품 개발 중 이를 피하기가 더 쉬워집니다.

다음은 주의해야 할 가장 일반적인 함정과 이를 피하는 방법입니다:

요구사항 엔지니어링을 위한 소프트웨어 도구

소규모 요구사항 세트를 관리하는 것은 비교적 간단합니다. 하지만 프로젝트가 커질수록 모든 것을 체계적으로 정리하고 최신 상태로 유지하는 데 더 많은 노력이 필요합니다. 그 시점부터는 요구사항을 어떻게 관리하느냐가 더욱 중요해집니다.

실무에서는 팀이 보통 다음과 같은 접근 방식 중 하나를 사용합니다:

• 스프레드시트와 문서: 익숙하고 시작하기 쉬워서 소규모 프로젝트에 유용합니다. 하지만 프로젝트가 커질수록 이를 유지하기 위한 수작업이 더 많이 필요합니다.
• 전용 요구사항 관리(RM) 도구: 프로젝트가 더 복잡해질수록 더 많은 구조와 통제를 제공합니다. 다만 일부 도구는 소규모 팀에 필요 이상으로 많은 프로세스를 동반한다는 점이 절충점입니다.

목표는 프로젝트에 필요한 만큼의 구조를 활용하되, 요구사항 관리를 불필요하게 복잡하게 만들지 않는 것입니다.

스프레드시트는 이미 한계에 이르렀지만 대규모 엔터프라이즈 RM 워크플로는 필요하지 않은 소규모 하드웨어 팀에게는 Requirements Portal이 고려해볼 만한 실용적인 선택지입니다. 이는 기존 엔터프라이즈 시스템의 부담 없이 소규모 팀이 요구사항을 보다 구조적으로 관리할 수 있도록 설계되었습니다.

결론 및 다음 단계

이제 요구사항 엔지니어링의 주요 개념과 그것이 실제로 어떻게 적용되는지에 대해 명확히 이해하셨을 것입니다.

요구사항 엔지니어링에 대해 계속 학습하고 싶다면, 다음 자료들이 좋은 출발점이 됩니다:

• ISO/IEC/IEEE 29148:2018은 요구사항 엔지니어링 프로세스와 실무에 대한 국제 표준을 제공합니다. 이 표준은 요구사항이 어떻게 작성되고, 구조화되고, 문서화되며, 관리되어야 하는지에 대한 추가 지침을 제공합니다.
• NASA Systems Engineering Handbook은 시스템 개발 과정에서 요구사항이 어떻게 생성되고, 작성되고, 검토되며, 활용되는지에 대한 실질적인 지침을 제공합니다.
• Guide to the Systems Engineering Body of Knowledge (SEBoK)은 요구사항이 더 큰 시스템 엔지니어링 프로세스 안에서 어떻게 위치하는지, 그리고 시스템의 서로 다른 부분이 어떻게 함께 개발되는지를 설명합니다.
• Requirements Engineering journal은 요구사항 엔지니어링에 대한 연구, 산업 사례, 그리고 다양한 접근 방식을 더 깊이 있게 다룹니다.

이론에서 실무로 넘어갈 준비가 되었다면, Requirements Portal을 사용해 보고 실제 하드웨어 프로젝트에서 구조화된 요구사항 작업을 지금 바로 시작해 보세요. 무료이며 별도의 설정도 필요 없습니다.

자주 묻는 질문

요구사항 엔지니어링이 중요한 이유는 무엇인가요?

요구사항 엔지니어링은 설계와 개발이 너무 많이 진행되기 전에 이해관계자의 요구를 명확히 이해함으로써, 팀이 올바른 제품을 만들 수 있도록 돕기 때문에 중요합니다.

Requirements Engineer의 역할은 무엇인가요?

Requirements Engineer는 이해관계자의 요구를 엔지니어링 팀이 사용할 수 있는 명확한 요구사항으로 바꾸고, 프로젝트가 변화함에 따라 그 요구사항을 체계적으로 유지합니다. 이들은 고객과 개발 팀 사이를 잇는 가교 역할을 합니다. 

Requirements Engineering과 Requirements Management의 차이점은 무엇인가요?

Requirements Engineering은 애초에 시스템이 무엇을 해야 하는지를 파악하고, 이해하고, 문서화하는 전체 프로세스입니다. Requirements Management는 그 작업 중에서도 작성된 요구사항을 체계적으로 관리하고 이후 변경 사항을 추적하는 구체적인 부분을 의미합니다.