공장에서 나온 기기가 주인을 찾기까지: 기기 등록 구조 설계기

공장에서 갓 나온 기기는 자기가 누구인지도, 누구 것인지도 모릅니다. 이 두 가지를 몇 초 안에, 그것도 엉뚱한 사람에게 뺏기지 않고 알아내게 하려면 무엇이 필요한지를 처음부터 끝까지 따라간 기록입니다.

---

상자를 뜯기 전에 이미 남의 것이 되어 있을 수 있습니다

IoT 제품에서 사용자가 가장 먼저 만나는 화면이 기기 등록이고, 여기서 막히면 제품은 그냥 상자입니다. 그런데 이 짧은 과정에는 서로 잡아당기는 요구가 세 개나 들어 있습니다.

"공장에서는 아무것도 안 하고 싶다. 그런데 아무나 등록하면 안 된다. 그리고 훔쳐가도 못 쓰게 해야 한다."

기기 한 대가 공장에서 사용자 손에 닿기까지 거치는 여정을 그려 보면, 이 요구들이 서로 다른 지점에서 튀어나온다는 게 보입니다.

점선 두 개가 서로 다른 지점에서 갈라져 나온다는 것이 이 그림의 요점입니다. 접속 문제는 사용자가 나타나기 전인 전원을 켜는 순간에 이미 필요하지만, 소유권 문제는 그보다 나중인 앱에서 등록할 때 생깁니다. 이 글은 이 두 점선을 어떻게 따로 다뤘는지에 대한 이야기입니다.

기기마다 다른 열쇠를 심으면 공장이 멈춥니다

기기가 클라우드에 접속하려면 자기만의 열쇠, 즉 인증서가 있어야 하고 가장 안전한 방법은 한 대마다 다른 열쇠를 공장에서 심는 것입니다. 그런데 그러면 모든 기기의 펌웨어가 서로 달라지므로, 같은 이미지를 대량으로 굽는 대신 한 대씩 개별 파일을 만들어 주입해야 합니다. 그 열쇠 목록도 공장과 안전하게 주고받아야 해서 라인 속도와 비용이 그대로 올라갑니다.

공용 열쇠만 쓰면 옆집 사람이 먼저 등록합니다

그래서 흔히 쓰는 반대 방법이 모든 기기가 같은 열쇠를 갖고 나가는 것인데, 펌웨어가 한 벌이니 공정은 단순해지지만 "이 기기가 누구 것인가"를 판단할 근거가 사라집니다. 기기는 클라우드에 잘 붙는데 주인이 없으므로, 옆집 사람이 자기 앱에서 먼저 등록해버리면 그 사람 기기가 됩니다.

소유권을 기기 안에 저장하면 초기화로 지워집니다

많은 제품이 "이 기기의 주인은 아무개"라는 값을 기기 메모리에 써두는데, 이러면 공장초기화 버튼 하나로 소유권이 지워집니다. 가져간 사람이 초기화하고 자기 앱에 등록하면 정상 기기가 되므로, 도어락이나 산업 장비처럼 물리 접근이 곧 위험인 제품에서는 치명적입니다.

세 칸의 시작점이 서로 다르다는 것을 봐주세요. ①은 공장에서, ②는 등록 순간에, ③은 도난 이후에 터지므로 한 곳을 편하게 만들면 다른 곳이 무너지고, 그래서 셋을 같은 방법으로는 막을 수 없습니다.

세 증상의 뿌리는 하나였습니다. 성격이 다른 질문 두 개를 한 덩어리로 취급한 것입니다.

질문	성격
"이 기기가 클라우드에 어떻게 접속하는가"	통신·인증의 문제. 사용자와 무관하게 기기가 켜지는 순간 필요
"이 기기는 누구 것인가"	소유·권한의 문제. 사용자가 앱에서 등록할 때 결정

시점도 다르고 다루는 주체도 다른데 대부분의 구현은 이걸 한 번에 해결하려 하고, 그래서 접속을 편하게 만들면 소유권이 허술해지고 소유권을 단단히 하면 공장이 무거워집니다.

---

공장에 열쇠를 몇 벌 넘기느냐가 전부를 정합니다

먼저 접속, 즉 신원 쪽 후보를 놓고 비교했습니다. 이 결정은 이미 사용자 손에 있는 기기의 펌웨어를 바꿔야 하므로 한 번 출하하면 되돌리기가 매우 어렵습니다.

방식	어떤 구조인가	장점	결정적 한계
① 공용 출입권 → 개인 출입증 교환 (Fleet Provisioning by Claim)	공장에서는 공용 임시 출입권 하나만 심고, 기기가 처음 켜질 때 자기 전용 출입증으로 바꿔 받음	모든 기기가 같은 펌웨어 한 벌. 공정·비용이 가장 낮고 기기 SDK가 기본 지원	공용 출입권이 전 기기 공통. 하나 유출되면 전량이 영향권
② 자체 발급소 운영 (JITR)	회사가 발급 기관을 직접 운영해 기기마다 서명된 출입증을 주입	공용 출입권이 없어 가장 안전	발급 설비·공정·키 관리 비용이 큼
③ 수량만큼 미리 발급해 개별 주입	클라우드에서 필요한 수량만큼 미리 뽑아 한 대씩 심음	안전	관리 부담이 수량에 비례. 소량 생산에만 현실적
④ 시큐어 엘리먼트	열쇠를 꺼낼 수 없는 전용 칩을 기판에 얹음	보안 최상. 펌웨어를 덤프해도 열쇠가 안 나옴	원가 상승. 그리고 이건 대안이 아니라 보강

차이는 표보다 공장 라인 그림에서 더 잘 보이는데, 핵심은 펌웨어 이미지가 몇 벌이냐입니다.

오른쪽에서는 열쇠 발급이 공장이 아니라 클라우드로 옮겨갔다는 점이 핵심입니다. 공장이 하는 일은 기록하고 라벨 붙이기로 줄어들고, 대신 기기가 처음 켜지는 순간 클라우드가 할 일이 생깁니다.

돌아보면 여기서 한참 헤맸는데, 처음에는 ①부터 ④까지를 나란히 놓고 하나를 고르려 했기 때문입니다. ④는 ①·②와 경쟁하는 항목이 아니라 위에 얹는 것이었고, ①과 ④를 함께 쓰는 조합이 실제로 가장 강합니다.

성숙한 플랫폼도 소유권까지는 풀지 않았습니다

오픈소스·상용 IoT 플랫폼(ThingsBoard · EMQX · Golioth · Magistrala 등)의 등록 구조도 함께 대조해 봤습니다. 접속 쪽은 대체로 ①에 해당하는 방식이 표준이었는데, 흥미로운 건 소유권 쪽이었습니다. 대부분이 기기를 고객사에 붙이는 것까지는 하지만 "공장초기화해도 소유권이 유지된다"는 모델을 갖춘 곳은 드물었고, 초기화하면 사실상 미등록 상태로 돌아가는 구현이 많았습니다.

즉 접속은 업계를 따라가면 되는 영역이고, 소유권은 우리가 더 나아갈 여지가 있는 영역이었습니다.

---

그래서 신원과 소유권을 따로 풀었습니다

①을 고르고 그 위에 소유권 단계를 따로 얹었으니, 택일이 아니라 둘 다입니다. 두 단계가 각각 무엇을 푸는지부터 나눠 보면 이렇습니다.

왼쪽에는 사용자가 아예 등장하지 않는다는 점을 봐주세요. 신원은 기기와 클라우드끼리 끝내는 일이고 사람은 오른쪽에서만 필요한데, 이 둘을 한 덩어리로 묶으면 앞에서 본 세 증상이 나옵니다.

기기 한 대가 거치는 상태로 바꿔 보면 중간에 낯선 칸이 하나 있습니다.

"등록됨 · 미소유"라는 상태가 따로 있다는 것이 이 그림의 전부입니다. 기기는 클라우드에 붙어 있지만 아무 권한이 없는 시간을 반드시 거치고, 되돌아가는 화살표는 소유자가 직접 해제할 때 하나뿐이라 공장초기화로 되돌아오는 길은 없습니다.

용어를 한 번만 정리하겠습니다.

이름	쉽게 말하면	어디에 있나
공용 출입권 (claim 인증서)	건물 로비까지만 들어가는 임시 카드	공장에서 펌웨어에 심음. 생산 로트별로 다름
전용 출입증 (기기 인증서)	그 기기만의 사원증	기기가 처음 켜질 때 클라우드가 발급
등록열쇠 (claimToken)	기기마다 다른 일련번호 뒤에 숨긴 비밀 숫자	공장에서 기기 저장소에 기록. 인쇄물에는 없음

공장은 같은 이미지 한 벌만 구우면 됩니다

모든 기기가 같은 펌웨어를 갖고 나가므로, 공장 지그가 하는 일은 일련번호와 등록열쇠를 기기 저장소에 기록하고 라벨을 붙이는 것뿐입니다.

	기기별 출입증 주입	우리 방식
펌웨어 이미지	기기 수만큼	1벌
공장에 넘기는 비밀	기기별 개인키 목록	일련번호 + 등록열쇠 목록
개인키가 다니는 경로	클라우드 → 공장 → 기기	없음. 기기 안에서 만들고 밖으로 안 나감

세 번째 줄이 핵심입니다. 기기가 자기 안에서 열쇠 쌍을 만들고 공개된 쪽만 클라우드에 보내는 방식(CSR)을 쓰기로 했으므로, 개인키가 네트워크를 타지 않아 통신이 뚫려도 열쇠 자체는 새지 않습니다. 알고리즘은 ECC secp256r1로 정했는데, 키 생성이 빨라 첫 부팅이 지연되지 않고 쓰는 칩이 하드웨어 가속을 지원하기 때문입니다.

첫 줄의 화살표가 기기 자신에게로 돌아온다는 점을 봐주세요. 개인키는 기기 안에서 만들어져 그 안에 남고 네트워크에는 공개해도 되는 쪽만 나가는데, 마지막 줄을 보면 출입증을 받았는데도 아직 아무것도 못 합니다.

기기 옆에 있는 사람만 등록할 수 있게 했습니다

소유권의 근거를 무엇으로 삼을지가 두 번째 결정이었고, 고민 끝에 고른 답은 물리적 근접이었습니다. 등록열쇠를 라벨에 인쇄하지 않고 기기 저장소에만 두었으므로, 앱은 블루투스나 기기가 잠깐 띄우는 임시 WiFi로 기기에게 직접 물어봐서 받아옵니다.

그래서 QR 라벨에는 비밀이 하나도 없습니다.

https://link.openiot.app/c?v=1&m={모델}&s={일련번호}

버전·모델·일련번호 세 가지뿐인 이 한 줄이 만드는 차이가 큽니다.

상황	인쇄형(라벨에 토큰)	우리 방식
매장 진열 중 라벨 사진 촬영	등록 가능	등록 불가: 기기에 직접 물어봐야 함
택배 송장·포장 사진 유출	등록 가능	등록 불가
정상 사용자	스캔 후 등록	스캔 후 기기 옆에서 등록

정상 사용자는 어차피 기기 옆에 있으므로 아무 차이를 못 느끼고, 공격자에게만 벽이 생깁니다.

가운데 두 줄에서 앱이 서버가 아니라 기기에게 직접 물어본다는 점이 요점입니다. 등록열쇠는 이 구간에서만 나오므로 라벨 사진만 가진 사람은 이 대화를 시작조차 할 수 없습니다.

다만 예외가 하나 있습니다. 블루투스도 WiFi도 없어 앱이 기기와 직접 대화할 수 없는 제품군은 기기 타입 설정으로 등록 방식을 분기하도록 열어뒀는데, 이 부분은 지금도 더 나은 방법이 있을 것 같습니다.

소유권은 서버에만 있어서 초기화해도 풀리지 않습니다

등록열쇠는 소멸하지 않고 기기에 영구 저장되며, 주인이 누구인지는 오직 서버의 소유자 정보로만 판정합니다. 여기서 도난 대응이 자연스럽게 나옵니다.

상황	동작
최초 등록	소유자 없음 → 등록 성공
다른 사람이 등록 시도	거부(409 · 이미 소유자 있음). 등록열쇠를 알아내도 실패
기기를 훔쳐서 공장초기화	서버 소유권 그대로 유지. 원 소유자만 재등록 가능
중고 판매	원 소유자가 앱에서 해제 → 미소유 상태 → 구매자가 등록
지인에게 양도	소유권 이전 기능으로 바로 넘김

세 번째 줄이 이 설계의 성격을 가장 잘 보여줍니다. 기기를 물리적으로 가져가도 소유권은 따라가지 않지만, 정당한 소유자는 언제든 해제하거나 이전할 수 있어 중고 거래는 막히지 않습니다.

초기화 다음 칸이 다르다는 것만 보면 됩니다. 왼쪽은 초기화가 소유권까지 지우지만 오른쪽에서 초기화가 지우는 건 기기 안의 내용뿐이라, 훔친 사람 앞에는 거부만 남고 정당한 주인 앞에는 해제와 이전 길이 그대로 열려 있습니다.

---

등록됐다는 것과 무언가를 할 수 있다는 것은 다릅니다

①의 유일한 약점은 공용 출입권이 전 기기 공통이라는 점이었고, 이걸 소유권 단계와 엮어서 막았습니다. 기기가 받는 권한을 두 단계로 나눈 것입니다.

단계	언제 받나	무엇을 할 수 있나
bootstrap	전용 출입증을 받은 직후	아무것도 못 함. 접속은 되지만 어떤 대화방에도 못 들어감
owned	사용자가 등록을 마친 뒤	자기가 속한 장소의 자기 채널만

owned 단계의 권한은 pools/{그 기기가 배정된 장소}/{그 기기 자신}/* 형태인데, 장소 ID가 고정값으로 박히는 게 아니라 기기 속성에서 읽어 채워지고 등록이 끝나기 전에는 이 속성이 비어 있습니다.

이 2단계가 왜 필요한지는 한 문장으로 줄일 수 있습니다. 등록은 "이 기기가 존재한다"를 클라우드가 받아들이는 일이고 권한은 "이 기기가 어느 채널을 열어도 되는가"를 정하는 일인데, 이 둘을 붙여두면 등록에 성공한 순간이 곧 통신 권한을 얻는 순간이 됩니다.

만약 등록 직후 바로 권한을 준다면, 공용 출입권은 전 기기 공통이므로 한 장만 유출돼도 그걸 쥔 사람은 누구나 정상 기기 행세를 할 수 있습니다. 반대로 권한을 소유가 확정된 뒤에 주면, 유출자가 기기를 등록하는 것 자체는 막지 못하더라도 그 기기에는 소유자가 없어 아무 채널도 열지 못하고 남는 건 빈 레코드 하나뿐입니다.

그렇다면 왜 "거의 없는 권한"이 아니라 완전 무권한으로 시작할까요. 초기 상태에 최소한의 권한이라도 열어두면 그 경로가 그대로 공격면이 되고, 공용 출입권만 있으면 누구나 도달할 수 있는 상태에 열린 문이 하나라도 있으면 그 문은 곧 전 제품군에 대해 열린 문이기 때문입니다. 혹시 같은 구조를 검토 중이시라면 이 지점을 먼저 보시길 권합니다.

두 줄기의 출발점이 똑같다는 점이 중요합니다. 유출이라는 사고 자체는 어느 쪽에서도 막지 못하고 갈라지는 곳은 등록에 성공한 다음 칸인데, 왼쪽은 등록이 곧 권한이라 사고가 그대로 피해가 되지만 오른쪽은 등록과 권한 사이에 사람이 한 번 개입해야 합니다.

오른쪽 끝까지 뚫고 가도 도착지가 "권한 없음"이라는 것을 봐주세요. 마름모 두 개 중 하나만 통과해도 그다음에서 막히고 둘 다 통과해도 얻는 건 빈 기기 하나라, 유출자가 만들 수 있는 최대치는 아무 권한도 없는 빈 레코드입니다. 여기에 생산 로트별로 공용 출입권을 분리하는 것을 더해 사고가 나도 폐기 범위가 해당 로트로 한정되게 했습니다.

1편의 관점과 이어집니다. "우리 서버 코드가 남의 장소를 조회하지 않도록 짰습니다"가 아니라 "권한 자체가 없습니다" 입니다.

---

먼저 만들어 본 구현에서 결함 여섯 개가 나왔습니다

이 결정을 확정하기 전에 같은 문제를 먼저 만들어 본 사내 구현을 뜯어봤습니다. 실제로 동작하는 코드였고 접속 방식·권한 스코프·접속 이벤트 처리까지 잘 만들어진 부분이 많아서, 그 구조를 참고하되 나온 결함들은 처음부터 반영하기로 했습니다. 전부 실제 코드에서 확인한 것이라 정직하게 적습니다.

사전 검증이 없어 무제한 등록이 가능했습니다

기기가 "나 등록해줘"라고 요청할 때 그 요청이 정당한지 확인하는 단계가 아예 없어서, 공용 출입권만 있으면 아무 일련번호로나 기기를 무한정 만들 수 있었습니다. 더 나쁜 건 중복이었는데, 이미 있는 일련번호로 다시 등록하면 기존 기기를 덮어써서 진짜 기기가 조용히 사라집니다.

대응으로 등록 요청을 가로채 검증하는 단계를 필수로 넣었습니다.

검증이 없던 구조에서는 이 마름모가 통째로 없었다는 점이 이 그림의 요점입니다. 왼쪽 요청이 곧장 오른쪽 초록 칸으로 직행했고, 붉은 네 갈래가 전부 통과였습니다.

개인키가 네트워크를 타고 있었습니다

기기의 가장 중요한 비밀인 개인키를 클라우드가 생성해 통신으로 내려주고 있었습니다. 통신 구간은 암호화되어 있으니 당장 뚫리는 건 아니지만 개인키가 네트워크를 탄다는 사실 자체가 보안 심사에서 지적 대상이라, 앞서 말한 기기 내부 생성 방식으로 전환했습니다. 기기가 스스로 열쇠를 만드는 건 무거운 연산이라 성능이 걱정됐는데, ECC로 바꾸면서 해소됐고 게다가 이 연산은 기기 생애 전체에서 최초 1회뿐입니다.

나머지 네 건은 제약을 우회하다 생긴 것이었습니다

결함	무슨 일이 벌어지나	대응
접속 ID가 전 기기 고정 문자열	같은 접속 ID로 새 연결이 들어오면 기존 연결을 끊는 규약이라, 공장에서 두 대 이상 동시에 켜면 서로를 밀어내 양산 라인이 사실상 한 대씩 직렬 처리	접속 ID를 기기 고유값(MAC) 기반으로 변경. 펌웨어만 고치면 되는 저비용 수정
일련번호가 24비트뿐	MAC 하위 3바이트만 잘라 써서 경우의 수가 약 1,678만. 다른 대역 칩이 섞여 충돌하면 먼저 있던 기기를 말없이 덮어씀	기기 이름 규약을 d-{환경}-{모델}-{일련번호} · 소문자 · 128자 이내로 먼저 재정의해 MAC 6바이트 전체를 수용
공용 출입권이 펌웨어에 평문	기기 한 대만 구해 저장소를 덤프하면 공용 출입권 획득. 위의 사전 검증 부재와 만나면 전 제품군 무제한 등록 권한	저장소 암호화 + 보안 부팅 · 로트별 출입권 분리 · 2단계 권한의 세 겹
재고·발급 파일·초기 비밀번호	안 팔린 기기가 주인 없이 쌓이고, 발급 목록 파일이 유출되면 선점 등록 가능. 공통 초기 비밀번호는 국내 보안인증 위반	미소유 90일 후 정리 · 파일 1회 다운로드 + 재발급 시 이전 토큰 폐기 · 기기별 고유 비밀번호 강제

두 번째 줄이 특히 인상적이었습니다. 코드 주석에 이유가 남아 있었는데 보안을 소홀히 해서가 아니라 기기 이름 길이 제한(32자)을 맞추려다 잘라낸 것이었고, 이름 규약을 먼저 다시 정하니 안전성 문제가 저절로 풀렸습니다.

세 번째 줄은 조합의 무서움을 보여줍니다. 각각은 중간 위험이지만 둘이 만나면 최악이 되는데, 이런 조합은 문서만 봐서는 안 보이고 코드를 열어 "이게 저것과 만나면?"을 따져봐야 나옵니다.

---

지금 손에 있는 것을 그대로 적습니다

현재 이 구조는 설계 확정 + 동작하는 화면 프로토타입 단계이고 실기기 연동과 공장 지그 연동은 다음 단계입니다. 지금까지 이야기한 것을 한 장으로 모으면 이렇습니다.

①②는 사용자가 없어도 진행되는 신원 단계이고 ③④⑤는 사람이 기기 옆에 있어야만 진행되는 소유권 단계입니다. 주인이 누구인지는 기기가 아니라 가운데 소유자 정보에만 적혀 있어서, 기기를 아무리 초기화해도 이 칸은 지워지지 않습니다.

문서가 아니라 구현이 따라야 하는 계약으로 등록 절차를 고정했습니다.

출하:         공용 출입권 + 등록열쇠를 기기 저장소에 주입
1단계 신원:    기기 → 전용 출입증 발급 + bootstrap(무권한) 부여
2단계 소유권:  앱이 등록열쇠 제시 → 소유자 확정 + 장소 배정 + owned 권한 부여

항목	확정값
QR 페이로드	.../c?v=1&m={모델}&s={일련번호}: 토큰 없음
기기 이름	d-{환경}-{모델}-{일련번호} · 소문자 · 128자 이내
접속 ID	기기 이름과 동일 (권한 변수 치환의 필수 조건)
중복 등록 응답	409 · "이미 소유자 있음"
미소유 기기 보존	90일
키 알고리즘	ECC secp256r1 · 기기 내부 생성

프로토타입은 클릭되는 화면으로 만들어 이 구조가 실제 화면으로 성립하는지 확인했고, 표시되는 값은 전부 목 데이터입니다.

화면	확인한 것
공장 프로비저닝	모델·수량으로 생산 배치를 발행하고 일련번호 구간이 예약되는 흐름. 배치별 발행 → 공장 전달 → 기록 완료 → 활성화 진행 상태. 목록 파일은 1회 다운로드이며 재발급 시 이전 토큰 폐기 경고 표시. 초기 비밀번호 "공통" 선택지는 비활성화
기기 등록 마법사	등록 방식 4종 → 기기 검색 → 소유권 확정 → 장소·방 배정 → 완료. 소유권 단계 옆에 서버가 하는 일 5줄이 그대로 표시됨
모바일 페어링	같은 5단계를 사용자 손에 쥐는 화면으로. 제품 종류에 따라 등록 방식 선택지가 달라지고, 장소 개념이 없는 제품군은 장소 선택 단계가 사라짐

등록 마법사가 특히 유용했습니다. 소유권 확정 단계에서 서버가 무엇을 하는지가 화면에 그대로 적혀 있어서, 비개발자도 왜 이 단계가 필요한지를 보고 검토에 참여할 수 있었습니다.

검증 산출물로는 사내 구현 전수 조사, 결함 6건 정리, 외부 플랫폼 대조, 화면-기능 전수 대조가 남았습니다. 마지막 것이 이번 조사의 수확이었는데, 등록 흐름은 다들 그리는데 그 앞단인 "공장에 넘길 목록을 어디서 뽑나"가 통째로 비어 있었고 이게 없으면 양산이 시작되지 않습니다.

---

택일처럼 보이던 문제는 층위가 달랐습니다

가장 크게 배운 점입니다. "공용 출입권이냐 등록열쇠냐"를 오래 고민했는데 답은 둘 다였고, 하나는 어떻게 접속하나를 풀고 다른 하나는 누구 것인가를 풀어서 애초에 경쟁 관계가 아니었습니다. 보안 칩도 후보 목록에 넣고 비교했지만 실은 다른 방식 위에 얹는 보강재였습니다. 1편에서도 같은 일이 있었으니 이제는 A냐 B냐로 오래 막히면 정말 같은 층위의 문제인지 먼저 확인하는 것이 습관이 됐습니다.

편의성의 대가가 다른 곳에서 청구된다는 것도 배웠습니다. 공용 출입권 방식은 공장을 극적으로 단순하게 만드는 대신 "하나 유출되면 전량"이라는 위험을 남기는데, 이 위험을 없앨 수는 없지만 값을 낮출 수는 있었습니다. 사전 검증·로트 분리·저장소 암호화·2단계 권한을 겹쳐 각 층이 뚫려도 다음 층이 남게 했으니, 한 방에 막는 대책은 없고 겹쳐서 값을 떨어뜨리는 것만 있었습니다.

이 구조가 고객에게 무엇을 주는지로 정리하면 이렇습니다.

고객이 얻는 것	근거
공장 공정이 단순함	전 기기 동일 펌웨어. 지그는 일련번호·등록열쇠 기록만
선점 등록이 불가능	등록열쇠를 라벨에 인쇄하지 않음. 기기 옆에 있어야 등록 가능
도난 기기가 재활용되지 않음	소유권이 서버에만 있음. 공장초기화로 안 풀림
중고 거래는 정상 동작	원 소유자의 해제·이전 기능 제공
공용 출입권이 유출돼도 피해가 안 번짐	사전 검증 + 로트 분리 + 무권한 시작
개인키가 네트워크를 타지 않음	기기 내부 생성. 보안 심사 대응

세 번째와 마지막 줄이 이 설계에서 가장 신경 쓴 부분입니다. 등록이 잘 되는 구조는 많지만, 등록이 안 돼야 할 때 확실히 안 되는 구조가 어렵습니다.

기기 등록은 결국 신원과 소유권이라는 다른 질문 두 개를 따로 푸는 일이었습니다. 비슷한 고민을 하고 계신 분께 조금이나마 도움이 되었으면 합니다.

읽어주셔서 감사합니다.