BMS 펌웨어 개발을 자동화한다는 것
펌웨어는 회로에 생명을 불어넣는 코드입니다. 그런데 그 빌드가 어느 보드에서 돌아가는지, 어떤 셀 조합에 맞춰진 건지를 사람이 머릿속과 엑셀로 관리하면, 잘못된 펌웨어가 잘못된 보드에 올라가는 사고가 납니다. 그래서 먼저 한 일은 “AI가 펌웨어를 짜는 것”이 아니라, 그 관리 자체를 시스템으로 만드는 것이었습니다. 이 글은 “완전 자동화”라는 화려한 말 뒤에 어떤 지루한 토대가 먼저 와야 하는지에 대한 정직한 기록입니다.
먼저 용어부터 — 펌웨어가 무엇인가요
섹션 제목: “먼저 용어부터 — 펌웨어가 무엇인가요”배터리를 만드는 회사 이야기인데 왜 “코드”가 나오는지부터 짚겠습니다. 배터리팩 안에는 BMS(배터리 관리 시스템)라는 작은 회로 보드가 들어갑니다. 그 보드 위의 칩이 “셀이 과충전됐으니 충전을 끊어라”, “온도가 위험하니 방전을 막아라” 같은 판단을 합니다. 이 판단을 실제로 수행하는 프로그램이 바로 펌웨어입니다.
”펌웨어 자동화”라는 말의 함정
섹션 제목: “”펌웨어 자동화”라는 말의 함정”“펌웨어 자동화”라고 하면 다들 AI가 C 코드를 척척 짜 주는 그림을 떠올립니다. 멋집니다. 그런데 현장에서 진짜 사고가 나는 지점은 코드 작성이 아니었습니다. 사고는 거의 항상 “이 빌드가 어느 하드웨어에 맞는가”를 사람이 잘못 기억하는 데서 났습니다.
이유를 풀어 보면 이렇습니다. 한 제품을 개발하는 동안 PCB 리비전이 여러 개로 늘어납니다. 셀 조합(직렬·병렬 수)도 모델마다 다릅니다. 그 위에 펌웨어 빌드는 매주 쌓입니다. v로 시작하는 빌드 번호가 수십 개가 되면, “지금 양산 라인에 올려야 하는 게 정확히 어떤 빌드였지?”라는 질문에 기억으로 답하게 됩니다. 그리고 기억은 틀립니다.
그래서 먼저 만든 것 — 빌드 관리 모듈
섹션 제목: “그래서 먼저 만든 것 — 빌드 관리 모듈”화려한 코드 생성기 대신, 제일 먼저 만든 건 펌웨어 빌드 관리 모듈이었습니다. 하는 일은 단순합니다. 빌드 하나가 나올 때마다 다음을 한곳에 등록합니다.
- 빌드 번호·빌드 일자 — 언제, 무엇이 나왔는가
- 바이너리 파일 — 실제 칩에 올라갈 결과물
- 체크섬(SHA256) — 그 파일의 “지문”. 한 비트만 달라도 값이 완전히 바뀐다
- 릴리스 노트 — 이 빌드에서 무엇이 바뀌었는가
- HW 호환성 — 어떤 보드 리비전에서 검증됐는가
이 마지막 항목이 핵심입니다. 빌드와 하드웨어의 관계는 일대일이 아니라 다대다입니다. 한 펌웨어가 여러 리비전에서 돌 수도 있고, 한 리비전이 여러 빌드를 받을 수도 있습니다. 그래서 둘의 관계를 표(매트릭스)로 펼쳐, 칸마다 “여기서 검증됨 ✓ / 아님 ✗“을 찍습니다.
| HW \ FW | v3.2.1 (예시) | v3.3.0-rc1 (예시) |
|---|---|---|
| PCB Rev3 | ✓ 검증 | ✗ |
| PCB Rev4 | – | ✓ 검증 |
위 표의 버전·리비전 값은 구조를 보여 주기 위한 예시입니다. 핵심은 칸 하나하나가 “이 펌웨어를 이 보드에 올려도 되는가”라는 질문에 ✓/✗로 즉답한다는 점입니다.
체크섬 — “기억” 대신 “지문”으로 답하기
섹션 제목: “체크섬 — “기억” 대신 “지문”으로 답하기”빌드 관리에서 가장 사소해 보이지만 가장 중요한 장치가 체크섬입니다. 파일을 올리면 그 파일의 SHA256 체크섬이 자동으로 계산됩니다.
이게 왜 중요한가요. 누군가 “이게 그 빌드 맞아?”라고 물을 때, 예전엔 “맞을걸요”라고 기억으로 답했습니다. 이제는 체크섬을 대조해 증거로 답합니다. 양산 라인에 올라가는 바이너리와 등록된 빌드의 지문이 한 글자라도 다르면, 그건 다른 파일입니다. 토론할 여지가 없습니다. 잘못된 바이너리가 라인에 흘러드는 걸 막는 가장 확실하고 가장 값싼 장치입니다.
실제로 이렇게 흘러갑니다 (예시 시나리오)
섹션 제목: “실제로 이렇게 흘러갑니다 (예시 시나리오)”- 빌드 등록 — 새 펌웨어가 나오면 바이너리를 올립니다. 시스템이 자동으로 체크섬을 찍고, 빌드 번호·일자·릴리스 노트를 함께 기록합니다.
- 호환성 표시 — “이 빌드는 Rev4에서 검증됨”을 매트릭스에 ✓로 찍습니다. Rev3 칸은 비워 둡니다 = “검증 안 됨”.
- 양산 직전 확인 — 라인 담당자가 “Rev3 보드에 올릴 펌웨어”를 찾습니다. 매트릭스를 보면 Rev3 줄에 ✓ 표시된 빌드만 보입니다. 빈칸 빌드는 애초에 후보가 아닙니다.
- 지문 대조 — 올릴 파일의 체크섬과 등록된 빌드의 체크섬을 맞춰 봅니다. 같으면 진행, 다르면 중단.
- 사고 차단 — “검증 안 된 조합”과 “엉뚱한 파일” 두 가지 사고 경로가 시스템 차원에서 막힙니다.
그다음 — AI가 들어올 자리
섹션 제목: “그다음 — AI가 들어올 자리”이렇게 토대가 깔리면, 비로소 AI가 보조할 자리가 또렷해집니다. 토대 위에서 AI가 거들 수 있는 건 이런 반복 판단들입니다.
- 릴리스 노트 초안 — 변경 이력에서 “이번 빌드에서 뭐가 바뀌었나”를 뽑아 초안을 씁니다.
- 빌드 추천 — “이 보드에는 어떤 빌드를 올려야 하나”를 매트릭스 근거로 제안합니다.
- 변경 ↔ 빌드 연결 — 회로 변경 이력과 펌웨어 빌드를 이어, “이 수정이 어느 펌웨어에 반영됐나”를 추적합니다.
그리고 이 모든 것의 정점에 “펌웨어 코드 자체의 생성·검증”이 있습니다. 하지만 그건 가장 먼 단계입니다. 추적도 안 되는 상태에서 코드부터 자동 생성하면, 그 코드가 어느 보드용인지조차 모른 채 쌓일 뿐입니다. 그래서 순서가 중요합니다.
처음부터 알았다면
섹션 제목: “처음부터 알았다면”이 일의 교훈은 “토대를 먼저 깔라”는 한 문장으로 요약됩니다. 화려한 끝그림(완전 자동화)에 끌려 코드 생성부터 손대고 싶은 유혹이 늘 있습니다. 하지만 그 유혹을 누르고 “무엇이 어디에 쓰이는지”부터 시스템이 알게 만든 것 — 그게 가장 잘한 결정이었습니다. 1인 개발이라 더 그렇습니다. 사람의 기억에 기대는 부분이 많을수록, 그 사람 하나가 바쁘거나 잊으면 전부 흔들리니까요.
이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 이 토대 위에 안전 검토가 어떻게 올라가는지는 BMS 회로 검토에, 다음 자동 설계 이야기는 배터리팩 니켈플레이트 설계에 있습니다.