1950년대 일본. 전쟁 후 폐허가 된 도요타 공장에서, 엔지니어들은 이상한 문제를 마주했다.

자동차를 만드는 사람, 검사하는 사람, 부품을 사오는 사람이 각자 다른 이름으로 같은 부품을 부르고 있었다. 설계도에서는 '전방 우측 브레이크 디스크', 창고에서는 '브레이크판 A타입', 구매 장부에는 '마찰재 12인치'. 모두 같은 물건이었다. 그러나 아무도 그 사실을 한눈에 알 수 없었다.

부품 하나가 빠지면 라인 전체가 멈췄다. 공장은 돌아가고 있었지만, 사실은 매일 아슬아슬하게 버티고 있었다.

BOM이 공장을 바꾼 방식 How BOM unified the factory floor

도요타를 비롯한 제조업체들이 찾아낸 해법은 단순했다. 모든 부품에 번호를 붙이는 것.

단순히 이름표를 다는 게 아니었다. 번호 하나에 모든 정보를 연결했다. 이 부품이 어떤 차종에 들어가는지, 몇 개가 필요한지, 어느 공정에서 쓰이는지, 어디서 납품받는지. 설계자, 생산자, 품질 검사자, 구매 담당자가 모두 같은 번호로 대화하기 시작했다.

BOM — Bill of Materials
이것이 BOM(Bill of Materials), 즉 부품표다. BOM이 등장하면서 공장의 언어가 통일됐다. "3번 라인에서 P-4471 재고가 떨어졌다"고 하면, 구매팀은 즉시 발주를 넣고, 품질팀은 대체 부품 스펙을 확인하고, 설계팀은 영향 범위를 파악한다. 번호 하나가 조직 전체를 연결하는 공통 언어가 된 것이다.

오늘날 BOM 없이 돌아가는 제조 공장은 없다. 자동차든, 반도체든, 스마트폰이든. 부품표는 제조업의 가장 기초적인 인프라가 되었다.

소프트웨어에는 왜 없는가 Why software never got its BOM

소프트웨어도 수많은 '부품'으로 이루어진다. 로그인 화면, 회원가입 프로세스, 결제 플로우, 관리자 대시보드. 이것들은 분명히 식별 가능한 단위들이다. 기획자는 화면 ID로 부르고, 개발자는 파일 경로로 부르고, QA는 테스트 케이스 번호로 부른다. 모두 같은 기능을 가리키고 있지만, 아무도 같은 번호를 쓰지 않는다.

제조업이 1950년대에 겪었던 그 문제가, 소프트웨어 업계에서는 지금도 매일 반복되고 있다.

한 가지 반론이 있을 수 있다. "소프트웨어에는 이미 티켓 번호가 있잖아요. Jira 이슈 번호, 깃허브 이슈 번호." 맞다. 하지만 그것은 '할 일'의 번호다. 작업이 끝나면 닫힌다. 소프트웨어의 구성 요소 자체를 영구적으로 식별하는 번호가 아니다.

구분제조업 BOM소프트웨어 현실
식별 단위 부품 (영구 ID) 티켓/이슈 (작업 완료 시 소멸)
공통 언어 설계·생산·품질·구매 모두 동일 번호 기획·개발·QA 각자 다른 참조
이력 추적 번호 하나로 전 이력 즉시 조회 흩어진 문서를 수작업으로 연결
영속성 제품 출시 후에도 유지 프로젝트 종료 후 사실상 소멸

부품이 사라지는 소프트웨어 When components have no permanent identity

이 차이가 만들어내는 문제는 생각보다 크다.

프로젝트가 끝나고 6개월 후, 고객이 묻는다. "회원가입 이메일 인증 부분, 지난번에 제대로 테스트했나요?" 이 질문에 답하려면 어디를 찾아야 할까. 당시 Jira 티켓? 깃 커밋 로그? 테스트 결과 엑셀? 아니면 그때 담당자에게 직접 물어봐야 할까.

부품 번호가 없으니, 그 기능에 대한 모든 이력이 흩어진 채로 존재한다. 연결할 실이 없다.

제조업이었다면 달랐다. 브레이크 디스크 P-4471의 품질 검사 이력, 납품 일자, 설계 변경 내역은 부품 번호 하나로 즉시 추적 가능하다. 소프트웨어의 '회원가입 화면'은 그럴 수 없다. 이름만 있고 번호가 없기 때문이다.

비즈니스 단위로 소프트웨어를 보다 Seeing software through a business lens

BOM에서 배울 수 있는 것은 번호 체계만이 아니다.

BOM의 기준 단위는 철저하게 비즈니스 단위다. 공장의 언어는 '나사 3mm 스테인리스'이지, '금속 원자 집합체'가 아니다. 현장에서 다루는 실체를 기준으로 삼는다.

소프트웨어 품질 관리에 이것을 적용하면 어떻게 될까. 기준 단위를 코드 파일이나 클래스가 아니라, 사람들이 실제로 인식하는 단위로 바꾸는 것. '로그인 화면', '비밀번호 변경 프로세스', '관리자 메뉴' — 이 단위들이 소프트웨어의 '부품'이 된다.

그리고 이 부품들에 번호를 붙인다. 기획 단계부터 개발, 테스트, 산출물까지 — 같은 번호로 연결한다. 기획자가 설계한 '회원가입 화면'과 개발자가 구현한 코드와 QA가 수행한 테스트가, 하나의 번호 아래 묶인다. 그 번호가 있으면 언제든 이력을 추적할 수 있다.

SOM의 핵심 아이디어
이것이 SOM이 제조업 BOM에서 빌려온 핵심 아이디어다. 기준 단위를 코드에서 비즈니스 단위로. 그리고 그 단위에 영구 ID를.

아이디어는 단순할수록 강하다 The simpler the idea, the more powerful

돌아보면, BOM이라는 아이디어 자체는 놀랍도록 단순하다. "모든 부품에 번호를 붙이자." 그게 전부다. 그런데 그 단순한 원칙이 현대 제조업의 근간이 되었다.

소프트웨어 품질도 마찬가지 아닐까. 복잡한 알고리즘이 필요한 게 아니다. 기준 단위를 바꾸고, 그 단위에 번호를 붙이는 것. 그 단순한 출발점이 SOM이다.

이 글은 저자의 아이디어와 경험을 바탕으로 AI(Claude)의 도움을 받아 작성되었습니다.