보드는 납품됐는데 장비는 켜지지 않는다. 회로 업체는 도면대로 만들었다고 하고, 펌웨어 쪽은 보드 문제라고 한다. 기구는 다른 공장에서 다음 주에 온다. 세 곳 모두 자기 몫은 끝냈는데, 손에 남은 건 아직 장비가 아니다.
문제는 실력이 아니라 경계다.
맞춤 장비 개발이란 회로와 펌웨어, 기구, 상위 프로그램까지 하나의 동작하는 장비로 묶는 일이다. 구간을 쪼개 따로 발주하면 견적은 분명히 싸진다. 대신 구간과 구간 사이의 빈칸은 아무도 맡지 않는다. 그 빈칸을 발주처가 직접 메우게 된다.
경계에서는 무슨 일이 벌어지나
경계 비용은 견적서에 항목으로 잡히지 않는다. 일정으로 나온다.
보드가 나와도 펌웨어가 없으면 그건 물건이 아니다. 펌웨어가 돌아도 데이터를 못 꺼내면 시스템이 아니다.
순서는 대개 비슷하다. 회로 업체가 시제품 보드를 보내고, 펌웨어 쪽에서 받아보니 핀 배치가 쓰던 방식과 어긋난다. 수정 요청이 회로 업체로 돌아가고, 2차 보드를 기다리는 몇 주가 그냥 사라진다. 그 사이 기구 업체는 이미 케이스 도면을 잡고 있어서, 커넥터 위치가 한 칸 밀리면 그쪽도 처음부터 다시 그린다. 누구의 잘못도 아닌데 일정만 통째로 밀린다. 세 업체 견적을 비교하며 아낀 금액은 이 지점에서 대부분 없어진다.
이런 지연에는 청구서가 없다. 그래서 더 아프다.
구간은 어떻게 나뉘고 무엇이 넘어가나
장비 하나는 네 구간을 지난다. 각 구간이 다음 구간에 무엇을 넘기는지를 보면, 경계가 어디에 생기는지도 같이 보인다.
| 구간 | 만드는 것 | 다음 구간에 넘기는 것 | 경계에서 터지는 문제 |
|---|---|---|---|
| 회로(PCB) | 보드, 부품 실장 | 핀맵, 전원 설계, 회로도 | 부품 단종, 실장 뒤에 드러나는 설계 오류 |
| 펌웨어 | 보드를 움직이는 코드 | 통신 규격, 명령어 정의 | 보드 리비전마다 달라지는 설정 |
| 기구 | 케이스, 브래킷, 방열 | 커넥터 위치, 고정 홀 | 설치 조건과 맞지 않는 치수 |
| 상위 프로그램 | 제어 화면, 데이터 수집 | 운영 데이터, 이력 | 설비가 뱉는 값을 읽을 방법이 없음 |
첫 칸에서 이미 뒤가 결정된다. 부품 선정과 핀맵을 언제 잠그느냐가 나머지 세 구간의 일정을 사실상 정한다. 도면을 넘기기 전에 확정해야 할 항목은 따로 묶어 두었다. → PCB 제작 의뢰, 도면 넘기기 전에 정해야 할 것
펌웨어는 코드를 짜는 순간보다 그 뒤가 길다. 모델이 늘면 설정과 버전도 같이 늘고, 업로드와 이력 관리가 진짜 부담이 된다. → 펌웨어 개발 외주, 업로드·이력 관리까지 묶어야 하는 이유
상위 프로그램은 두 갈래로 갈린다. 설비를 직접 잡고 움직여야 하는 일과, 값만 꺼내 모으면 되는 일은 난이도가 다르다. 앞쪽을 뒤쪽 예산으로 발주하면 중간에 범위가 부풀어 오른다. → 장비 제어 프로그램 개발, 기성 프로그램이 설비를 못 잡을 때 → 시리얼 통신 프로그램, 설비에서 데이터를 꺼내는 가장 빠른 길
어디까지 한 팀에 맡겨야 하나
기준은 하나다. 경계를 몇 개까지 감당할 수 있느냐.
최소 묶음은 회로와 펌웨어다. 이 둘은 리비전 단위로 계속 붙어 다닌다. 보드가 한 번 바뀌면 펌웨어도 같이 바뀌고, 그 왕복이 개발 기간의 상당 부분을 먹는다. 여기를 갈라놓으면 책임 소재를 가리는 회의가 개발보다 길어진다.
두 번째 묶음은 펌웨어와 상위 프로그램이다. 통신 규격을 누가 정하느냐의 문제다. 장비를 만든 쪽이 데이터 포맷까지 같이 잡아야, 나중에 값 하나 추가하는 일이 며칠짜리 협의로 번지지 않는다.
기구는 상대적으로 떼기 쉽다. 커넥터 위치와 치수만 초기에 고정하면 외부 공장과 병행해도 크게 무리가 없다.
GrowSpace가 맞춤 SW·HW 개발을 한 팀으로 묶는 이유도 여기에 있다. 상담에서 설계, 구축, 운영까지 한 곳이 이어받으면 경계 회의 자체가 없어진다. 다루는 범위는 따로 정리해 두었다. → 맞춤 SW·HW 개발
발주 전에 정해두면 싸게 끝나는 것
장비 제조사 한 곳은 모델마다 설정과 펌웨어가 달라서 업로드를 사람이 직접 했다. 손이 많이 가는 데다 잘못 올릴 위험이 늘 있었다. 장비 인식과 자동 매칭, 설정 검증, 일괄 업로드, 이력 관리를 하나의 프로그램으로 묶고 나서야 그 위험이 정리됐다.
여기서 눈여겨볼 지점이 있다. 처음 의뢰는 펌웨어였고, 실제로 문제를 끝낸 건 상위 프로그램이었다.
발주 전에 세 가지만 정해두면 대부분의 경계 사고는 미리 막힌다. 데이터를 어디까지 꺼낼 것인가. 통신 규격을 누가 확정하는가. 장비가 늘어났을 때 설정과 이력을 무엇으로 관리할 것인가.
세 질문의 답이 서로 다른 업체에 흩어져 있으면, 그 조율이 곧 프로젝트 원가가 된다.
자주 묻는 질문
회로만, 또는 프로그램만 맡길 수도 있나요? 가능하다. 다만 그 경우 경계를 관리하는 주체는 발주처가 된다. 핀맵과 통신 규격 문서를 발주처가 쥐고 업체 사이를 중계해야 한다. 사내에 그 역할을 할 인력이 있는지부터 보는 편이 낫다.
기존 설비에 붙이는 것도 맞춤 장비 개발인가요? 그렇다. 설비를 새로 만드는 일보다 오히려 흔하다. 기존 설비에서 값을 꺼내 기존 ERP나 MES로 넘기는 작업이 여기에 들어간다. 이때는 회로보다 통신과 연동이 일의 중심이다.
어느 구간부터 시작하는 게 좋나요? 데이터가 나오는 쪽부터 보는 편이 낫다. 설비에서 값을 꺼내 보면 무엇이 부족한지가 드러나고, 그다음 회로와 기구의 범위가 자연스럽게 좁혀진다.
작게 시작해도 된다. 다만 시작 전에, 이 장비가 최종적으로 어디까지 가야 하는지는 그려 두는 편이 낫다.
