IoT 및 제한된 네트워크를 위한 CBOR(RFC 8949) 바이너리 직렬화
CBOR의 데이터 모델과 짧은 바이너리 표현, 결정적 인코딩의 실제 의미, COSE 서명과의 경계를 표준 문서에 근거해 설명합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
CBOR(Concise Binary Object Representation)는 JSON보다 넓은 데이터 모델을 가진 IETF 바이너리 형식입니다. 작은 값은 전송 바이트를 줄일 수 있지만 항상 JSON보다 작지는 않으며, 서명·암호화도 제공하지 않습니다. RFC 8949는 형식을, RFC 9052는 CBOR 기반 COSE 보안 구조를 정의합니다.
JSON을 출발점으로 삼되 그대로 복사하지 않는다
CBOR의 데이터 모델은 JSON 데이터 모델을 확장한 형태입니다. 정수, 문자열, 배열, 맵, 불리언, null 같은 값뿐 아니라 JSON에 바로 대응되지 않는 바이트 문자열, 태그, 더 넓은 수 범위 등의 요소도 표현할 수 있습니다. 따라서 애플리케이션 데이터의 구조를 JSON과 비슷하게 생각하면서, 바이너리 전송에 맞는 타입과 크기를 선택할 수 있습니다. 하지만 CBOR는 JSON 문법을 바이너리로 바꾼 단순 압축판이 아닙니다. 두 형식 사이에 변환할 때 표현할 수 없는 값이나 변환 규칙을 고려해야 합니다.
초기 바이트가 타입과 부가 정보를 나타내며, 값이 커지면 길이 표현도 늘어납니다. RFC 8949의 예에서 정수 0은 00, 24는 18 18입니다. 실제 절감량은 값, 반복 키, 프로토콜 헤더, 인코더에 따라 달라집니다.
짧은 인코딩이 언제 유리한가
IoT 센서처럼 작은 메시지를 자주 보내거나 전력·메모리·네트워크 비용이 제한된 경우, 간결한 숫자·배열·맵 표현은 전송량을 줄이는 데 도움을 줄 수 있습니다. 특히 문자열 대신 짧은 정수 키를 사용하는 프로토콜은 반복되는 키 이름을 전송하지 않도록 설계할 수 있습니다. 반면 사람이 직접 읽고 편집하기 어렵고, 디버깅 도구가 필요하며, 스키마와 키 할당을 별도로 관리해야 합니다. 데이터를 압축하기보다 진단 가능성과 운영 단순성이 더 중요한 서비스라면 JSON이 더 적합할 수 있습니다.
크기 비교는 실제 payload로 측정해야 합니다. 같은 데이터 모델이어도 키가 짧은지, 문자열이 얼마나 반복되는지, 숫자가 어느 범위인지, 메시지 묶음 방식이 무엇인지에 따라 결과가 달라집니다. CBOR 자체의 헤더 바이트뿐 아니라 프로토콜 프레이밍, 암호 태그, 전송 계층 오버헤드를 포함해 비교해야 합니다. 한 샘플에서 작다는 사실을 전체 트래픽의 비용 절감으로 일반화하지 마세요.
결정적 인코딩은 프로토콜이 선택하는 규칙이다
바이너리 데이터의 의미가 같아도 인코더가 서로 다른 바이트열을 만들 수 있습니다. 예를 들어 맵 항목의 순서나 숫자의 표현 폭이 다르면 같은 값으로 디코딩되더라도 원본 바이트는 같지 않을 수 있습니다. RFC 8949는 여러 프로토콜이 필요에 따라 결정적 형식을 정의할 수 있으며, 디코더가 해당 규칙을 확인할 수도 있다고 설명합니다. 즉, “CBOR이 자동으로 단 하나의 표준 바이트열을 만든다”는 뜻은 아닙니다.
해시·서명·캐시 키가 바이트열에 의존한다면 송신자와 수신자가 어떤 결정적 인코딩 규칙을 따르는지 명시해야 합니다. 맵 키 순서, 정수와 부동소수점의 표현, 허용되는 길이 형식, 태그 처리와 같은 세부사항을 구현체 사이에서 합의해야 합니다. 라이브러리의 기본 인코딩 결과를 표준 규칙으로 가정하면, 서로 다른 구현이 같은 데이터를 다른 바이트로 직렬화해 서명 검증이나 캐시 일치에 실패할 수 있습니다.
COSE는 CBOR에 보안 메시지 구조를 더한다
COSE는 CBOR 객체에 서명, 메시지 인증 코드, 암호화를 적용하기 위한 구조와 절차를 정의합니다. RFC 9052의 COSE_Sign은 여러 서명을 담을 수 있고, COSE_Sign1은 서명자 한 명의 구조입니다. 두 구조는 서명 계산에 어떤 형식인지가 포함되므로 서로 바꾸면 검증에 실패할 수 있습니다. 서명된 객체에는 보호(protected) 및 비보호(unprotected) 헤더, payload, 서명 필드가 정해진 구조로 들어갑니다.
전문가 관점의 질문은 어떤 바이트와 헤더가 서명 대상이며 분리 payload가 바뀌지 않게 전달되는가입니다. RFC 9052는 보호 헤더와 이 책임을 다루지만, 키 관리·알고리즘 정책·재전송 방지·권한 검증까지 해결하지는 않습니다.
도입 전에 확인할 구현 조건
먼저 JSON과 CBOR 사이에서 손실 없이 변환되어야 하는 타입을 정의합니다. 바이트 문자열, 큰 정수, 태그, 부동소수점 처리와 맵 키 제약을 확인하고, 프로토콜의 스키마 또는 CDDL로 허용 구조를 공유합니다. 이후 대표 메시지뿐 아니라 최대 길이, 잘못된 입력, 알 수 없는 태그, 중복 키, 잘림 데이터도 테스트합니다. RFC 8949는 잘못 구성된 CBOR 항목을 디코더가 정상 데이터로 반환하지 않도록 요구합니다.
결정적 인코딩이 필요하다면 적용 규칙을 문서화하고 독립 구현 간 동일 바이트가 나오는지 시험하세요. 보안이 필요하면 RFC 9052가 정의한 COSE 메시지 형태와 선택한 알고리즘을 따로 검토하고, 서명 대상 payload가 정확히 보존되는지 확인합니다. 마지막으로 실제 기기와 네트워크에서 전송 크기, 처리 시간, 메모리, 오류 복구와 관측성을 JSON 구현과 비교합니다. 이 측정 결과가 CBOR의 복잡성을 감수할 이유를 결정합니다.
CBOR의 가치는 바이너리라는 사실만으로 정해지지 않습니다. 작은 표현과 확장 가능한 타입을 필요로 하는 환경에서는 좋은 선택이 될 수 있지만, 결정성·스키마·보안 메시지 처리의 책임도 함께 생깁니다. RFC 8949의 직렬화 규칙과 RFC 9052의 COSE 구조를 구분해 설계하면 크기 절감과 검증 가능한 상호운용성을 함께 평가할 수 있습니다.