무선 업데이트가 제품을 벽돌로 만들지 않으려면 - OTA는 보내는 기능이 아니라 실패해도 되는 구조입니다

"출시 후에 무선으로 업데이트되게 해주세요." 연결 기능이 있는 제품의 개발 상담에서 빠지지 않는 요구입니다. 당연한 요구이기도 합니다. 팔린 제품의 버그를 고치고 기능을 더하는 길이 무선 업데이트, 즉 OTA이기 때문입니다. 그런데 이 요구는 대개 "업데이트를 보낼 수 있게"라는 절반만을 담고 있습니다. 나머지 절반은 업데이트가 "실패했을 때"의 이야기입니다.

결론을 먼저 말씀드리면, OTA 설계의 본체는 전송 기능이 아니라 "실패해도 제품이 살아 있는 구조"입니다. 업데이트 도중에 전원이 뽑히고, 통신이 끊기고, 배터리가 다하는 일은 수많은 사용자 환경에서 반드시 일어납니다. 그 순간 제품이 다시는 켜지지 않는 이른바 벽돌이 되는지, 아무 일 없었다는 듯 이전 버전으로 켜지는지는 운이 아니라 설계가 정합니다. 그리고 이 설계는 서버 쪽 작업이 아니라, 시제품 기판의 메모리 구성에서 시작됩니다.

업데이트의 안전은 서버가 아니라 기판 위의 메모리 구조에서 시작됩니다.

업데이트는 가장 위험한 순간을 통과하는 일입니다

펌웨어 업데이트의 본질은 제품의 두뇌를 새 것으로 바꿔 쓰는 일입니다. 쓰는 도중의 메모리는 이전 것도 새 것도 아닌 어중간한 상태이고, 바로 그 순간에 전원이 끊기면 제품은 온전한 두뇌가 없는 상태로 남습니다. 개발실에서는 안정된 전원과 가까운 통신으로 업데이트하니 이 위험이 보이지 않지만, 사용자의 세계에서는 다릅니다. 업데이트 중에 답답해서 전원을 뽑는 사용자, 와이파이가 닿을 듯 말 듯한 구석에 설치된 기기, 배터리가 간당간당한 상태에서 받는 업데이트까지, 실패의 조건은 늘 준비되어 있습니다.

한 대의 개발 보드라면 케이블을 꽂아 되살리면 그만입니다. 그러나 팔려 나간 수백, 수천 대는 다릅니다. 벽돌이 된 제품은 반품과 교환, AS 왕복 비용, 그리고 "업데이트하다 죽는 제품"이라는 평판으로 돌아옵니다. 양산 후의 진단 경로를 시제품 기판에 남겨야 한다는 이야기를 드린 적이 있는데, OTA의 실패 대비는 그보다 한 걸음 앞서 "진단조차 필요 없게" 만드는 설계입니다.

벽돌을 막는 구조의 원리: 두 자리와 되돌아갈 길

안전한 OTA의 원리는 의외로 단순합니다. "지금 돌아가는 펌웨어를 지우면서 새 것을 쓰지 않는다"입니다. 메모리에 펌웨어 자리를 두 개 마련해, 현재 버전이 한 자리에서 돌아가는 동안 새 버전은 다른 자리에 내려받는 구조입니다. 내려받기가 끝나고 검증까지 통과한 뒤에야 다음 부팅에서 새 자리로 전환하고, 전환 후 새 버전이 정상 동작을 스스로 확인하지 못하면 이전 자리로 되돌아갑니다. 어느 순간에 전원이 끊겨도 온전한 펌웨어 한 벌은 반드시 남아 있는 것입니다.

이 구조의 대가는 메모리입니다. 펌웨어 두 벌이 들어가야 하니 저장 공간이 넉넉해야 하고, 그 결정은 칩 선정과 기판 설계의 시점, 즉 시제품 단계에 내려져야 합니다. 출시 후에 OTA를 얹으려다 메모리가 모자라 구조를 포기하는 사례는 드물지 않습니다. 기판의 층수가 신호 목록으로 정해지듯, 메모리의 크기는 업데이트 전략으로 정해지는 항목입니다. 공간이 빠듯한 제품이라면 전체 대신 바뀐 부분만 보내는 방식 같은 절충도 있지만, 어떤 절충이든 "실패 시 되돌아갈 온전한 한 벌"이라는 원칙은 양보하지 않아야 합니다.

어느 순간 전원이 끊겨도 온전한 펌웨어 한 벌이 남아 있는 것이 구조의 전부입니다.

구조와 함께 설계되어야 할 것들

• "받은 것의 검증": 내려받은 펌웨어가 깨지지 않았는지, 그리고 정말 우리가 보낸 것인지를 서명으로 확인한 뒤에만 전환합니다. 검증 없는 OTA는 업데이트 통로가 아니라 공격 통로가 됩니다. 전송 중 손상만이 아니라 악의적인 가짜 펌웨어까지 걸러내는 것이 서명의 역할입니다
• "업데이트의 시점": 기기가 일하는 도중이 아니라 한가하고 전원이 안정된 때를 골라 받고, 배터리 제품이라면 잔량이 충분할 때만 전환을 허용합니다. 사용자에게 알리고 미룰 수 있게 하는 배려도 이 설계의 일부입니다
• "단계적 배포": 새 버전을 전체에 한 번에 보내지 않고 일부 기기에 먼저 보내 지켜본 뒤 넓히는 운영이, 펌웨어의 결함이 전체 사용자의 사고가 되는 것을 막습니다. 파일럿 생산이 양산의 예행연습이었듯, 단계 배포는 업데이트의 예행연습입니다
• "버전의 장부": 어느 기기가 어떤 버전인지를 서버가 알고 있어야, 문제가 생겼을 때 범위를 좁히고 다음 배포를 계획할 수 있습니다. 펌웨어 주입 기록이 생산의 추적성을 만들었듯, 버전 장부는 운영의 추적성을 만듭니다
• "모델 업데이트와의 분리": AI 기능이 있는 제품이라면, 갱신 주기가 다른 AI 모델과 펌웨어를 분리해 운영해야 한다는 이전 이야기가 이 구조 위에 얹힙니다. 자주 바뀌는 것과 신중히 바꿀 것이 같은 통로를 쓰면 양쪽 모두가 느려집니다

판단 기준은 한 문장입니다

"가장 나쁜 순간에 전원이 끊긴 기기가, 사용자의 손만으로 다시 살아나는가." 이 질문에 "예"라고 답할 수 있어야 OTA는 기능이 아니라 자산이 됩니다. 무선 업데이트는 팔린 제품을 계속 좋아지게 만드는 길이지만, 그 길의 안전 난간은 출시 전 기판 위에서만 세울 수 있습니다.

출시 후에도 좋아지는 제품의 조건은 실패해도 살아나는 업데이트 구조입니다.

제언: OTA 요구는 두 문장으로 전달하십시오