부품 하나가 단종됐다! 하드웨어 프로젝트에서 벌어지는 BOM 지옥

개발자는 보통 회로가 완성되면 큰 산 하나를 넘었다고 생각합니다. 그런데 어느 날 구매 담당자에게 연락이 옵니다. ‘이 부품 단종됐는데요?’ 그 순간 프로젝트는 조용히 공포영화 장르로 바뀝니다. 하드웨어 프로젝트에서는 기능 구현만큼 부품 수급과 대체품 관리가 중요합니다.

BOM과 프로젝트 계획

BOM은 부품 목록이 아니라 프로젝트의 생명줄

BOM은 Bill of Materials의 약자로 제품을 구성하는 부품 목록입니다. 하지만 실무에서는 단순한 숫자표 이상의 의미를 가집니다. 제조사, 부품 번호, 패키지, 사양, 대체 가능 여부, 구매 상태가 함께 관리되어야 합니다.

하드웨어 프로젝트가 진행될수록 BOM은 살아 움직이는 문서가 됩니다. 부품이 변경되면 회로, PCB, 펌웨어, 시험 결과, 인증 자료까지 영향을 받을 수 있기 때문입니다.

개발 일정 관리

단종보다 무서운 것은 단종을 늦게 아는 것

부품 단종 자체가 항상 치명적인 것은 아닙니다. 문제는 양산 직전이나 인증 시험 직전에 알게 되는 경우입니다. 이때 대체 부품을 찾으면 회로 수정과 PCB 변경, 소프트웨어 조정까지 연쇄적으로 발생할 수 있습니다.

중요 부품은 개발 초기부터 수명 주기와 공급 상태를 확인하고, 가능하면 2차 소싱 후보를 준비하는 것이 좋습니다. 단순히 ‘비슷하게 생겼다’는 이유로 대체하면 안 되고 전기적 특성과 열 특성, 패키지, 펌웨어 의존성까지 검토해야 합니다.

공급망과 부품

대체 부품 검토에서 가장 많이 놓치는 것

저항과 커패시터처럼 비교적 단순한 부품은 대체가 쉬울 수 있지만 MCU, 전원 IC, ADC, 센서, 통신 IC는 이야기가 달라집니다. 핀 호환이라고 해도 레지스터 구조나 초기화 순서가 다르면 펌웨어 수정이 필요합니다.

전원 IC는 출력 전압만 맞는다고 끝나지 않습니다. 스위칭 주파수, 인덕터 조건, 보호 기능, 레이아웃 요구사항까지 함께 확인해야 합니다.

디지털 관리

프로젝트 일정이 늦어지는 진짜 이유

하드웨어 프로젝트의 일정 지연은 한 가지 원인으로 설명하기 어렵습니다. 부품 납기, 시제품 제작, 디버깅, 재설계, 시험 장비 예약 등이 서로 연결되어 있기 때문입니다.

따라서 일정표에 회로설계 완료일만 적는 것보다 부품 발주, 입고, PCB 제작, 조립, bring-up, 기능시험, 검증을 각각 분리해 관리하는 것이 현실적입니다.

제품 개발과 협업

BOM 변경을 두려워하지 말고 기록하자

부품 변경이 발생했을 때 가장 중요한 것은 왜 바꿨는지 기록하는 것입니다. 단가 때문에 변경했는지, 공급 문제 때문인지, 성능 개선 때문인지가 남아 있으면 다음 담당자가 같은 고민을 반복하지 않습니다.

변경 이력에는 기존 부품, 변경 부품, 변경 사유, 영향 범위, 검증 방법과 결과를 함께 남기는 것이 좋습니다. 이런 기록은 프로젝트가 길어질수록 큰 자산이 됩니다.

하드웨어 프로젝트 생존 전략

프로젝트 초기에 핵심 부품을 분류하고 위험도를 정해보세요. 대체가 어려운 부품, 납기가 긴 부품, 단종 가능성이 높은 부품을 먼저 관리하면 리스크를 줄일 수 있습니다.

개발자는 회로만 보고 구매 담당자는 가격만 보는 식의 분리가 아니라, 개발·구매·생산이 같은 BOM을 바라보는 구조가 가장 좋습니다. 하드웨어 프로젝트는 결국 여러 사람이 같은 숫자표를 얼마나 정확하게 공유하느냐의 싸움이기도 합니다.

부품 리스크를 숫자로 관리하는 방법

부품마다 단종 위험, 납기 위험, 대체 난이도, 가격 영향도를 간단한 등급으로 표시해보세요. 모든 부품을 똑같이 관리할 필요는 없습니다. 프로젝트의 기능과 공급망에 큰 영향을 주는 핵심 부품부터 관리하면 됩니다.

대체품을 미리 확보하는 것과 실제로 제품에 적용 가능한지 검증하는 것은 다른 문제입니다. 샘플이 들어오면 전기적 특성과 펌웨어 동작, 열 특성, 생산성까지 단계적으로 확인하는 것이 좋습니다.

대체 부품을 선정할 때의 현실적인 순서

첫 단계는 기능이 같은 부품을 찾는 것입니다. 두 번째는 전기적 사양을 비교합니다. 세 번째는 패키지와 PCB 수정 필요성을 확인합니다. 네 번째는 펌웨어와 생산 공정에 미치는 영향을 검토합니다.

마지막으로 샘플을 실제 보드에 적용해 기능 시험을 진행해야 합니다. 데이터시트 숫자가 비슷하다는 이유만으로 동일한 동작을 보장할 수는 없습니다.

특히 MCU나 통신 IC처럼 소프트웨어 의존성이 큰 부품은 초기화 코드, 레지스터 설정, 타이밍까지 함께 확인해야 합니다.

양산 단계에서 BOM이 더 중요해지는 이유

시제품에서는 몇 개의 부품을 구매해 조립하면 되지만 양산에서는 수량과 납기, 포장 단위, 공급처가 중요해집니다. 같은 부품이라도 대량 구매 시 포장 방식과 생산 로트 관리가 필요할 수 있습니다.

따라서 하드웨어 프로젝트에서는 개발 BOM과 생산 BOM의 차이를 명확하게 관리하는 것이 좋습니다. 제조 현장에서 실제 사용하는 부품 번호가 개발 문서와 다르면 추적성이 떨어질 수 있습니다.

프로젝트가 커질수록 BOM은 개발팀만의 문서가 아니라 구매와 생산, 품질이 함께 사용하는 기준 문서가 됩니다.

BOM 관리가 프로젝트의 기억을 보존한다

프로젝트가 1년 이상 이어지면 담당자와 부품 상황이 바뀔 수 있습니다. 당시 어떤 부품을 왜 선택했는지 기록이 없다면 같은 검토를 다시 해야 합니다.

부품 선정 이유와 대체 후보를 BOM이나 관련 문서에 남겨두면 프로젝트의 의사결정이 자산으로 남습니다. 개발자의 머릿속에만 있는 정보는 퇴사나 조직 변경과 함께 사라질 수 있지만 기록은 다음 프로젝트까지 이어집니다.

마무리

하드웨어 프로젝트는 특정 기능 하나만 잘 구현한다고 끝나는 분야가 아닙니다. 요구사항을 이해하고 설계하며 구현하고 시험하는 전 과정이 맞물려야 비로소 제품다운 결과가 나옵니다. 현장에서 가장 강력한 무기는 거창한 비법보다 문제를 작게 나누고 원인을 확인하는 습관입니다.

기술은 정답을 외우는 것보다 왜 그런 결과가 나왔는지 설명할 수 있을 때 비로소 내 것이 됩니다. 오늘 하나의 문제를 제대로 기록해두면 다음 프로젝트에서는 그 기록이 꽤 비싼 시행착오를 대신해줄지도 모릅니다.

Threads 게시용

부품 하나가 단종되면 왜 프로젝트 전체가 흔들릴까요? BOM 관리, 대체 부품 검토, 일정 지연까지 하드웨어 프로젝트에서 벌어지는 ‘BOM 지옥’을 현실적으로 정리했습니다. 👉 https://7jaytee7.tistory.com/

티스토리 링크: https://7jaytee7.tistory.com/