무슨 일이냐면
Ars Technica가 삼성 스마트 냉장고 사용자들의 불만을 보도했어요. 펌웨어 업데이트가 내려온 뒤 냉장고가 먹통이 됐고, 그 사이 냉장고 안 음식이 상해버렸다는 이야기예요. 기사 제목에 '브릭(brick)'이라는 단어가 쓰였는데, 이게 뭐냐면 기기가 벽돌처럼 아무 반응이 없는 물건이 됐다는 개발자들 사이의 속어예요. 스마트폰 루팅하다 실패하면 벽돌 됐다고 하잖아요. 그게 냉장고에서 일어난 거예요.
정확한 기술적 원인은 제조사가 밝혀야 알 수 있는 부분이라 여기서 단정하진 않을게요. 대신 어떻게 하면 냉장고가 업데이트 때문에 멈출 수 있는지, 그리고 펌웨어를 배포하는 개발자라면 무엇을 챙겨야 하는지는 충분히 이야기할 수 있어요. 이건 냉장고만의 문제가 아니라 소프트웨어를 원격으로 배포하는 모든 팀의 문제거든요.
스마트 냉장고 안에는 컴퓨터가 두 개 있어요
요즘 스마트 냉장고는 보통 두 층으로 나뉘어요. 하나는 컴프레서와 온도 센서를 제어하는 작은 마이크로컨트롤러(MCU)예요. 예전 냉장고에도 있던 그 두뇌죠. 다른 하나는 화면, Wi-Fi, 앱 연동, 음성 인식 같은 '스마트' 기능을 담당하는 리눅스 계열 애플리케이션 프로세서예요. 사실상 태블릿 하나가 냉장고 문에 붙어 있는 셈이에요.
이상적인 설계에서는 두 층이 확실히 분리돼서, 스마트 쪽이 완전히 죽어도 MCU가 알아서 냉각을 계속해야 해요. 화면이 꺼지고 앱이 안 되는 건 불편하지만 음식은 안전한 거죠. 그런데 온도 설정이나 운전 모드 결정처럼 냉각과 직결된 판단을 스마트 층에 맡겨두면, 스마트 층의 업데이트 실패가 곧 냉각 정지로 이어질 수 있어요. 이런 걸 단일 장애점(single point of failure)이라고 부르는데, 하나가 죽으면 전체가 죽는 구조예요. 이번 사건이 정확히 어떤 경로였는지는 모르지만, 개발자라면 '가장 중요한 기능은 가장 단순한 부품이 담당하게 하라'는 원칙을 기억하면 좋아요.
OTA 업데이트가 실패하는 지점들
OTA(Over-The-Air)는 기기가 네트워크로 새 소프트웨어를 받아서 스스로 교체하는 방식이에요. 편리하지만 실패할 수 있는 지점이 정말 많아요. 다운로드 도중 Wi-Fi가 끊겨서 파일이 반만 내려올 수도 있고, 새 펌웨어가 특정 하드웨어 리비전에서만 부팅에 실패할 수도 있고, 예전 설정 데이터를 새 형식으로 옮기는 마이그레이션 코드가 예외를 던질 수도 있어요. 부팅은 되는데 메모리 누수로 몇 시간 뒤에 멈추는 경우도 있고요. 게다가 냉장고는 스마트폰과 달리 사용자가 재부팅 버튼을 찾기도 어렵고, 아예 전원을 뺐다 꽂는 것 말고는 손쓸 방법이 없어요.
안전한 OTA를 만드는 패턴들
그래서 임베디드 업계에는 검증된 패턴들이 있어요. 첫 번째는 A/B 파티션이에요. 저장 공간을 두 칸으로 나눠서 현재 돌아가는 A 칸은 건드리지 않고 B 칸에 새 펌웨어를 통째로 써요. 다 쓴 뒤 B로 부팅해보고, 정상 동작이 확인되면 그때서야 B를 기본으로 확정하죠. 안드로이드가 몇 년 전부터 채택한 방식이고, 테슬라나 최근 자동차 업계도 대부분 이렇게 해요.
두 번째는 워치독과 자동 롤백이에요. 워치독은 일정 시간 안에 정상 신호를 안 보내면 강제로 리셋하는 하드웨어 타이머인데요. 새 펌웨어가 부팅 후 정해진 시간 안에 '나 정상이야'라고 확인 도장을 찍지 못하면 자동으로 A 칸으로 되돌아가요. 이 두 가지만 있어도 업데이트 때문에 벽돌이 되는 일은 거의 막을 수 있어요.
세 번째는 단계적 배포예요. 전체 기기의 1%에게 먼저 내보내고, 부팅 성공률과 오류 리포트를 하루 이틀 지켜본 뒤 10%, 50%, 100%로 넓혀가는 거예요. 만약 문제가 보이면 배포를 즉시 멈추는 킬 스위치도 필요하고요. 웹 서비스에서 카나리 배포라고 부르는 것과 같은 개념이에요. 하드웨어 리비전이 여러 개인 제품은 리비전별로 테스트 기기를 두고 실제로 부팅까지 확인하는 테스트 매트릭스도 필수예요.
마지막으로 페일세이프 기본값이에요. 네트워크가 없어도, 화면이 죽어도, 설정 파일이 깨져도 냉장고는 적당히 차갑게 돌아가야 해요. 소프트웨어가 어떤 상태에 빠지든 물리적으로 안전한 기본 동작으로 돌아가게 설계하는 걸 fail-safe라고 불러요. 엘리베이터가 전원이 끊기면 브레이크가 잠기는 것과 같은 원리죠.
업계 맥락: 낯설지 않은 장면
2024년 여름에 크라우드스트라이크 사태가 있었죠. 보안 소프트웨어의 콘텐츠 업데이트 하나가 전 세계 윈도우 PC 수백만 대를 블루스크린으로 몰아넣었어요. 그때 지적된 것도 똑같았어요. 단계적 배포가 없었고, 커널 수준에서 실패했을 때 안전하게 넘어가는 장치가 부족했다는 거요. 냉장고든 서버든 한 번에 전부, 되돌릴 수 없게 배포하는 구조는 언젠가 사고가 나요.
IoT 기기의 강제 업데이트 자체도 논쟁거리예요. 사용자가 업데이트 시점을 고를 수 있어야 하는지, 제조사가 지원을 끊으면 기기가 어떻게 되는지 같은 문제요. 유럽의 사이버 복원력법(CRA)처럼 연결된 제품의 보안 업데이트 의무를 규정하는 규제가 본격화되면서, 앞으로는 업데이트를 안전하게 배포하는 능력 자체가 제품 경쟁력이 될 거예요.
한국 개발자에게 주는 시사점
한국은 가전과 IoT 제조사가 유독 많은 나라라 이 이야기가 남의 일이 아니에요. 펌웨어 개발자라면 A/B 파티션, 부팅 확인 후 커밋, 워치독 롤백, 단계적 배포 이 네 가지가 우리 제품에 다 있는지 오늘 한 번 점검해보세요. 백엔드 개발자도 마찬가지예요. 데이터베이스 마이그레이션을 한 번에 전부 돌리고 롤백 계획이 없다면 구조적으로 이 냉장고와 똑같은 상태거든요. 배포는 언제든 실패할 수 있고, 실패했을 때 되돌아갈 길이 있어야 한다는 원칙은 냉장고나 서버나 같아요.
정리
기기를 벽돌로 만드는 건 버그 자체가 아니라, 버그가 났을 때 되돌아갈 길을 만들어두지 않은 설계예요.
여러분 팀의 배포 파이프라인에는 되돌아갈 길이 있나요? 실제로 롤백을 해본 적이 언제였는지 댓글로 나눠주세요.
🔗 출처: Hacker News