모바일 API용 JSON vs Protobuf: 크기, 호환성, 디버깅

모바일 앱에서 API 포맷이 중요한 이유

백엔드가 빠르더라도 모바일 앱이 느리게 느껴질 수 있습니다. 흔한 이유는 서버 시간이 아닙니다. 셀룰러 지연, 약한 신호, 재시도, 그리고 폰이 네트워크 라디오를 깨우는 데 걸리는 시간이 문제입니다. 한 화면이 세 개의 API 호출을 만들면, 그 왕복 지연 비용을 세 번 내는 셈입니다.

포맷은 바이트가 도착한 이후의 처리에도 영향을 줍니다. 앱은 여전히 응답을 파싱하고 유효성을 검사하고 UI 모델로 매핑해야 합니다. 그 작업은 CPU를 사용하고, 곧 배터리로 이어집니다. 구형 폰이나 앱이 백그라운드에서 실행될 때 작은 비효율이 누적됩니다.

페이로드 크기는 요청과 응답에 대해 와이어로 보내는 바이트 수입니다. 필드 이름과 구조 문자를 포함합니다. 작은 페이로드는 약한 네트워크에서 보통 더 빠르게 다운로드되고 데이터 요금이 적게 들며, 라디오가 활성화되는 시간이 줄고 CPU 파싱 작업이 줄어 배터리 절약에도 도움이 됩니다.

포맷 선택은 API를 안전하게 진화시키는 방식도 바꿉니다. 모바일 릴리스는 웹보다 느립니다: 사용자는 업데이트가 늦고, 일부는 업데이트를 전혀 하지 않으며, 앱 스토어 리뷰가 수정 지연을 만들기도 합니다. 구버전 클라이언트를 깨는 변경을 배포하면 여러 버전을 병행해 지원해야 하는 압박에 놓일 수 있습니다.

디버깅도 중요합니다. JSON은 페이로드를 로그에서 읽고 문제를 빠르게 찾을 수 있는 경우가 많습니다. Protobuf 같은 바이너리 포맷은 보통 스키마와 적절한 도구가 있어야 무슨 일이 있었는지 해독할 수 있습니다.

실무에서 이 결정은 나쁜 네트워크에서 화면당 로드 시간, 데이터 및 배터리 사용량, 오래된 앱을 깨뜨리지 않고 필드를 추가하는 안전성, 그리고 실패를 얼마나 빨리 검사할 수 있는지에 영향을 줍니다.

평이한 언어로 보는 JSON과 Protobuf

JSON과 Protobuf는 앱과 서버가 메시지의 의미에 동의하도록 정보를 포장하는 두 가지 방식입니다. 한쪽은 손으로 쓴 메모(JSON)처럼 보이고, 다른 쪽은 콤팩트한 바코드(Protobuf)처럼 생각하면 됩니다.

JSON은 데이터가 텍스트로 전송되고 필드 이름이 매번 포함됩니다. 간단한 사용자 객체는 {\\\"id\\\": 7, \\\"name\\\": \\\"Sam\\\"}처럼 보일 수 있습니다. 그 자체로 읽을 수 있어 로그에서 검사하거나 버그 리포트에 복사하거나 기본 도구로 테스트하기 쉽습니다.

Protobuf는 데이터를 바이너리 바이트로 전송합니다. 와이어상에서 "id"나 "name" 같은 필드 이름을 매번 반복하는 대신, 양쪽이 미리 1번은 id, 2번은 name이라고 약속합니다. 메시지는 대부분 값과 짧은 숫자 태그로 이루어져 작아집니다.

텍스트 vs 바이너리, 이론 없이 핵심만

실용적 트레이드오프는 간단합니다:

• JSON은 자기 설명적입니다: 메시지 자체에 필드 이름이 들어 있습니다.
• Protobuf는 스키마 주도입니다: 의미는 공유된 정의 파일에서 옵니다.
• JSON은 읽고 손으로 편집하기 쉽습니다.
• Protobuf는 콤팩트하고 일관되지만 도구 없이는 읽기 어렵습니다.

이 공유 정의가 스키마입니다. Protobuf를 사용하는 팀은 보통 스키마를 계약으로 취급하고 버전을 관리하며 백엔드와 모바일 클라이언트에서 동기화합니다. JSON에서는 스키마가 선택 사항인 경우가 많습니다. 많은 팀이 문서화는 하지만(예: OpenAPI), 기술적으로는 스키마 없이도 API를 내보낼 수 있습니다.

일상 업무에서 이 차이는 협업 방식에 영향을 줍니다. Protobuf는 형식적 API 변경(필드 추가, 이전 필드 번호 예약, 깨지는 이름 변경 회피)을 권장합니다. JSON은 더 느슨한 변경을 허용하지만, 그 유연성이 클라이언트가 필드가 항상 존재한다고 가정하거나 타입이 항상 같다고 가정할 때 놀라움을 만들 수 있습니다.

현장에서는 JSON이 공개 REST API와 빠른 통합에 흔히 쓰이고, Protobuf는 gRPC 서비스, 내부 서비스 간 트래픽, 대역폭과 지연이 중요한 모바일 앱에서 많이 사용됩니다.

페이로드 크기: 실제로 와이어에서 무엇이 바뀌나

원시 크기는 중요하지만, 더 중요한 것은 어떤 바이트가 반복되는지, 어떤 바이트가 압축에 잘 걸리는지, 얼마나 자주 보이는지입니다.

JSON이 보통 더 큰 이유

JSON은 읽을 수 있는 텍스트를 많이 담습니다. 가장 큰 비용은 값 주변의 단어들인 경우가 많습니다:

• 필드 이름이 각 객체마다 반복됩니다("firstName", "createdAt", "status").
• 숫자가 텍스트로 전송되므로 "123456"는 컴팩트한 바이너리 정수보다 더 많은 바이트를 씁니다.
• 깊게 중첩되면 중괄호, 콤마, 따옴표가 늘어납니다.
• 예쁘게 포맷된(pretty-printed) 응답은 클라이언트에 전혀 도움이 되지 않는 공백을 추가합니다.

API가 200개의 항목 목록을 반환하고 각 항목이 10개의 필드 이름을 반복한다면, 그 반복되는 이름들이 페이로드를 지배할 수 있습니다.

Protobuf가 보통 더 작은 이유

Protobuf는 필드 이름을 숫자 태그로 대체하고 컴팩트한 바이너리 인코딩을 사용합니다. 패킹 인코딩은 반복되는 숫자를 효율적으로 저장할 수 있고(예: 많은 ID), 와이어 포맷에 타입 정보가 있으므로 정수와 불리언은 일반적으로 JSON 텍스트 버전보다 적은 바이트로 인코딩됩니다.

유용한 사고 모델: JSON은 필드마다 세금(tax)을 내는 셈(키 이름). Protobuf는 더 작은 필드당 세금을 냅니다(태그).

압축이 비교를 바꾼다

gzip 또는 brotli를 사용하면 JSON은 반복되는 문자열이 많아 크게 줄어드는 경우가 많습니다. 반복되는 필드 이름은 압축에서 매우 효율적입니다. Protobuf도 압축되지만 반복이 적어 상대적 이득이 작을 수 있습니다.

실무에서는 Protobuf가 여전히 크기 면에서 유리한 경우가 많지만, 압축을 켜면 격차가 종종 줄어듭니다.

언제 ‘작음’이 가장 중요한가

요청이 자주 발생하거나 네트워크가 불안정할 때 페이로드 크기가 가장 중요합니다. 예를 들어 모바일 앱이 로밍 중에 10초마다 업데이트를 폴링하면, 각 응답이 약간 더 커도 데이터가 빠르게 소모됩니다. 채팅이 많은 화면(검색 제안, 실시간 대시보드)이나 낮은 대역폭 사용자의 경우에도 중요합니다.

한 세션에 엔드포인트를 몇 번만 호출한다면 절약 효과는 실질적이지만 극적이지는 않습니다. 수백 번 호출된다면 작은 차이도 빠르게 눈에 띕니다.

속도와 배터리: 파싱, CPU, 그리고 현실적 제약

모바일에서는 네트워크가 이야기의 절반일 뿐입니다. 모든 응답은 디코딩되어 객체로 변환되고 종종 로컬 DB에 씁니다. 그 작업은 CPU 시간을 소모하고, CPU 시간은 배터리로 이어집니다.

JSON은 텍스트입니다. 파싱은 문자열을 스캔하고 공백을 처리하고 숫자를 변환하고 필드 이름을 매칭해야 합니다. Protobuf는 바이너리이므로 대부분 그 과정을 건너뛰고 앱이 실제로 필요한 값에 더 가깝게 도달합니다. 많은 앱에서 이것은 응답당 CPU를 덜 사용한다는 뜻이며, 특히 깊게 중첩된 페이로드나 필드 이름이 반복되는 리스트에서 그렇습니다.

폰에서 ‘더 빠르다’의 실제 의미

파싱 비용은 콜드 스타트와 저사양 기기에서 가장 크게 느껴집니다. 앱이 열리고 즉시 큰 홈 피드를 불러오면, 느린 디코딩은 더 긴 빈 화면 또는 첫 인터랙션 지연으로 나타날 수 있습니다.

Protobuf가 자동으로 성능 문제를 해결한다고 가정하면 안 됩니다. 응답이 작거나 병목이 이미지, TLS 핸드셰이크, 데이터베이스 쓰기, UI 렌더링 등에 있다면 포맷 선택은 큰 차이를 만들지 못합니다.

서버 측 처리량도 중요

인코딩과 디코딩은 서버에서도 일어납니다. Protobuf는 요청당 CPU를 줄이고 처리량을 높여 많은 클라이언트가 폴링하거나 자주 동기화할 때 도움이 됩니다. 하지만 백엔드 시간이 데이터베이스 쿼리, 캐싱 또는 비즈니스 로직에 의해 지배된다면 차이는 미미할 수 있습니다.

공정하게 측정하려면 테스트를 통제하세요: 동일한 데이터 모델과 레코드 수를 사용하고, 압축 설정을 맞추거나 둘 다 비활성화하고, 실제 모바일 네트워크(빠른 Wi‑Fi만이 아님)에서 측정하며, 다운로드 시간뿐 아니라 디코드 CPU까지 포함하세요. 최소 하나의 저사양 기기를 포함하세요.

간단한 규칙: 구조화된 데이터를 자주 많이 보낼 때 바이너리 포맷이 이득을 주며, 파싱 시간이 지연이나 배터리 사용의 의미 있는 부분인지 보여줄 수 있어야 합니다.

백워드 호환성: API를 안전하게 진화시키는 방법

백워드 호환성은 서버의 새 버전을 배포한 뒤에도 구버전 앱이 계속 동작하는 것을 뜻합니다. 모바일에서는 사용자가 즉시 업데이트하지 않기 때문에 이게 더 중요합니다. 실사용 중에 3~4개의 앱 버전이 동시에 존재할 수 있습니다.

실용적인 규칙은 서버 변경을 추가적(additive)으로 만드는 것입니다. 서버는 구 요청을 받아들이고 구 클라이언트가 이해할 수 있는 응답을 반환해야 합니다.

JSON에서는 추가적 변경은 보통 새 옵션 필드를 추가하는 것입니다. 구 클라이언트는 사용하지 않는 필드를 무시하므로 대체로 안전합니다. 흔한 함정은 JSON 자체가 아니라 가정 깨뜨리기입니다: 필드 타입 변경(문자열→숫자), 필드 이름 변경, 의미 변경(이름은 같지만 의미가 달라지는 경우), 또는 안정적 값이 갑자기 열린 형식으로 바뀌는 경우입니다.

Protobuf에서는 규칙을 따르면 호환성이 더 엄격하고 신뢰할 만합니다. 계약은 필드 번호입니다, 필드 이름이 아닙니다. 필드를 제거하면 그 번호를 재사용하지 말고 예약하세요. 필드 타입 변경이나 repeated↔non-repeated 변경은 구버전 클라이언트를 깨뜨릴 수 있으니 피하세요.

두 포맷에서 안전한 변경 예시는 다음과 같습니다:

• 새 옵션 필드를 추가하고 합리적 기본값을 제공하세요.
• enum 값을 추가할 때 클라이언트가 알 수 없는 값을 처리하도록 만드세요.
• 기존 필드의 타입과 의미를 안정적으로 유지하세요.
• 필드를 먼저 deprecated로 표기하고 구버전 사용자가 사라진 뒤 삭제하세요.

버전 관리에는 두 가지 일반적 스타일이 있습니다. 추가적 진화는 하나의 엔드포인트를 유지하며 시간이 지남에 따라 스키마를 확장하는 방식으로, 모바일에 보통 적합합니다. 버전된 엔드포인트(v1, v2)는 정말로 깨지는 변경이 필요할 때 유용하지만, 테스트와 지원 작업이 두 배가 됩니다.

예: 앱이 주문 목록을 보여줄 때 delivery ETA를 추가하고 싶다면 delivery_eta를 옵션으로 추가하세요. status 필드를 타임스탬프를 포함하도록 재목적화하지 마세요. 새 모델이 필요하면 v2 응답을 고려하고 v1은 구 사용자가 사라질 때까지 계속 제공하세요.

디버깅과 관찰성: 문제를 빠르게 파악하는 법

모바일 연결에서 문제가 발생하면 보통 세 가지 단서가 있습니다: 클라이언트 에러, 서버 로그 라인, 요청 트레이스. 포맷은 그 단서들이 답으로 이어지는 속도에 영향을 줍니다.

JSON은 사람이 읽을 수 있어 로그나 캡쳐에서 바로 페이로드를 복사해 문제를 이해할 수 있습니다. 릴리스 중 디버깅을 하거나 비백엔드 팀원이 실제로 앱이 무엇을 보냈는지 확인할 때 이점이 큽니다.

Protobuf도 충분히 디버깅할 수 있지만 준비가 필요합니다. 페이로드가 바이너리이므로 필드 내용을 보려면 스키마와 디코딩 단계가 필요합니다. 많은 팀은 핵심 필드의 안전한 디코드 요약(원시 바이트가 아니라)을 요청 메타데이터와 함께 로그에 남기는 방식으로 이 문제를 해결합니다.

Protobuf를 실무에서 디버깅 가능하게 만드는 방법

다음 습관들이 크게 도움이 됩니다:

• 요청의 전체 메시지 대신 디코드된 요약(예: user_id, request_type, item_count)을 로그에 남기세요.
• .proto 파일을 버전 관리하고 인시던트 담당자가 접근할 수 있도록 하세요.
• 모든 응답과 로그 라인에 요청 ID와 트레이스 ID를 포함하세요.
• 명확한 enum 이름을 사용하고 여러 의미로 필드를 재사용하지 마세요.
• 비즈니스 규칙을 일찍 검증하고 읽기 쉬운 에러 코드를 반환하세요.

관찰성은 또한 민감한 데이터를 유출하지 않고 추적하는 문제이기도 합니다. 어떤 포맷이든 로그에 무엇을 남기고, 무엇을 마스킹해야 하며, 무엇이 절대 장치를 떠나면 안 되는지 초기에 결정하세요. 이메일, 전화번호, 정확한 위치, 결제 정보 같은 PII는 로그에 저장하기 전에 필터링해야 합니다.

간단한 시나리오: 지원팀에서 특정 사용자가 불안정한 모바일 데이터에서 폼 제출을 못 한다고 보고합니다. JSON이라면 캡처된 요청에서 빠르게 누락된 country 필드를 볼 수 있습니다. Protobuf라면 스키마 버전과 함께 country: unset 같은 디코드된 스냅샷을 로그로 남겨 동일한 결론에 도달할 수 있습니다.

선택 방법: 단계별 의사결정 프로세스

JSON과 Protobuf 중 선택은 회사 전체의 일회성 결정이 되는 경우가 드뭅니다. 대부분 팀은 실제 사용량을 기준으로 기능 영역별로 결정하는 편이 낫습니다.

간단한 5단계 프로세스

엔드포인트를 그룹화해 계측할 수 있게 만드세요. 각 화면 로드에서 어떤 호출이 발생하는지, 드물게 호출되는지 구분하세요. 현재 전송하는 것(평균 및 p95 응답 크기, 활성 사용자당 호출 빈도)을 측정하세요. 그런 다음 클라이언트 현실을 고려하세요: 저사양 폰, 불안정한 네트워크, 오프라인 동작, 사용자가 얼마나 빨리 업데이트하는지 등.

그런 다음 그룹별로 결정하세요: 사람이 읽고 빠르게 문제를 해결하는 것이 중요한 곳은 JSON을 유지하고, 크기와 파싱 속도가 병목으로 증명된 곳은 Protobuf를 사용하세요. 마지막으로 작은 파일럿을 운영하세요: 고트래픽 영역 하나를 전환해 제한된 사용자에게 배포하고 결과를 비교한 뒤 표준화를 결정하세요.

측정 후 패턴은 보통 명확합니다: 소수의 엔드포인트가 대부분 데이터 사용량과 대기 시간을 유발합니다. 이들이 바이너리 포맷의 최적 후보입니다.

파일럿에서 볼 항목들

구축 전에 성공 기준을 정의하세요. 유용한 지표로는 중간값과 p95 요청 시간, 세션당 전송 바이트, 크래시 프리 세션 비율, 응답 파싱에 소비된 CPU 시간(특히 저사양 기기)이 있습니다.

예: 하루에 30번 호출되는 피드 엔드포인트가 있고 반복 필드가 많은 큰 리스트를 반환한다면 Protobuf는 투자 대비 효과를 줄 수 있습니다. 반대로 지원에서 “무슨 일이 일어났는지 알 수 없다”는 게 가장 큰 문제라면, 해당 영역은 JSON을 유지하는 것이 비용보다 더 큰 가치를 줄 수 있습니다.

팀들이 자주 저지르는 실수

팀들은 숫자도 없이 포맷을 놓고 논쟁하다가 불필요한 작업을 추가하고 지연/배터리/데이터 비용을 거의 바꾸지 못한 전환을 하는 경우가 많습니다.

흔한 패턴은 “바이너리가 더 작다”는 이유로 JSON을 Protobuf로 교체한 뒤 실제 문제는 과도한 이미지, 통신이 잦은(채티한) 엔드포인트, 잘못된 캐싱이라는 사실을 나중에 발견하는 것입니다. 반드시 실제 기기와 실제 네트워크에서 먼저 측정하세요. 사무실의 빠른 Wi‑Fi만으로 판단하지 마세요.

자주 보이는 실수는 베이스라인 없이 포맷을 바꾸는 것, 작은 스키마 편집(이름 변경, 타입 변경, Protobuf 필드 ID 재사용)으로 클라이언트를 깨뜨리는 것, 모든 곳에 바이너리를 남용하는 것, 프로덕션 디버깅 경험을 무시하는 것, 압축과 캐싱을 잘못 구성하고 시리얼라이제이션 포맷 탓을 하는 것 등입니다.

실무 예: 팀이 피드 엔드포인트를 Protobuf로 옮기고 스테이징에서 30% 페이로드 감소를 축하합니다. 그런데 프로덕션에서 앱은 여전히 느립니다. 피드는 다섯 개의 별도 요청을 만들고, 어느 것도 캐시되지 않으며 서버는 "혹시 몰라"라는 이유로 계속 필드를 추가하고 있었습니다. 포맷이 주된 문제는 아니었던 셈입니다.

예시 시나리오: 잦은 업데이트가 있는 모바일 앱

대화 목록, 타이핑 인디케이터, 전달 확인, 가끔 있는 프로필 업데이트 같은 채팅 유사 기능이 있는 모바일 앱을 상상해보세요. 메시지는 작고 자주 도착하며 많은 사용자가 연결이 불안정한 네트워크에 있습니다.

"최신 업데이트 가져오기"의 전형적인 JSON 응답은 초기에는 작지만 시간이 지남에 따라 커집니다. 처음에는 메시지 텍스트, 발신자, 타임스탬프만 반환하지만 이후 반응, 기기별 읽음 상태, 모더레이션 플래그, 더 풍부한 사용자 객체 등이 추가됩니다. JSON은 이런 추가를 내보내기 쉽게 하지만 필드 이름이 각 항목마다 반복되어 페이로드가 불어날 수 있고 팀은 종종 옵션 블록을 "혹시 몰라" 하며 계속 추가합니다.

{
  "messages": [
    {
      "id": "m_1842",
      "text": "On my way",
      "sentAt": "2026-01-29T10:12:03Z",
      "sender": {"id": "u_7", "name": "Maya"},
      "reactions": [{"emoji": "👍", "count": 3}],
      "readBy": ["u_2", "u_5"]
    }
  ],
  "typing": ["u_7"]
}

동일한 데이터는 Protobuf로 와이어에서 더 작게 인코딩되는 경우가 많습니다. 필드가 숫자 태그와 컴팩트한 타입으로 인코딩되기 때문입니다. 업데이트가 잦고 사용자가 제한된 요금제를 쓰는 경우 이점이 큽니다. 단점은 조정 비용입니다: 스키마, 코드 생성, 변경에 대한 더 엄격한 규칙이 필요합니다. 디버깅은 "로그에서 바로 읽기"에서 "올바른 스키마로 디코딩하기"로 이동합니다.

실무 결과는 보통 분할 접근입니다. 로그인, 설정, 기능 플래그, 관리자 화면처럼 사람들이 자주 검사하는 항목은 JSON으로 남기고, 메시지 동기화, 증분 업데이트, 프레즌스/타이핑 이벤트, 반복 객체가 많은 대화 목록, 분석 배치 같은 고용량 트래픽에는 Protobuf가 빛을 발합니다.

롤아웃을 구버전 앱에 안전하게 적용하려면 한 번에 모든 것을 바꾸지 마세요. 둘 다 병행 운영하세요(예: Protobuf를 요청하는 헤더를 통해). 기본값은 합리적으로 유지하고 호환성 규칙을 엄격히 지키세요. Protobuf에서는 필드 번호를 절대 재사용하지 마세요. JSON에서는 새 필드를 옵션으로 유지하고 타입을 은밀하게 변경하지 마세요.

빠른 체크리스트 및 다음 단계

이 결정을 트렌드나 취향이 아니라 트래픽과 릴리스 현실에 기반해 내리세요. 포맷 선택은 사용자 고통(느린 화면, 타임아웃, 배터리 소모)이나 팀 고통(깨지는 변경, 디버깅 난항)을 줄일 때만 가치가 있습니다.

간단한 직감 체크:

• 응답이 정기적으로 수백 KB 이상인가요, 아니면 세션당 수십 회 호출되나요(피드, 채팅, 트래킹, 동기화)?
• 구버전 앱이 몇 달 동안 활성 상태로 남아 있나요?
• API 변경 시 스키마 규율을 강제할 수 있나요?
• 지원과 QA가 문제 재현을 위해 페이로드를 복사·붙여넣어 검사해야 하나요?

경험 법칙: 페이로드가 작고 사람들이 자주 읽어야 한다면 초반에는 JSON이 보통 이깁니다. 빈번하고 무거운 페이로드가 있고 엄격한 스키마를 유지할 수 있다면 Protobuf가 효과적일 수 있습니다.

정직한 다음 단계 계획:

1. 바쁜 엔드포인트 하나(홈 피드나 동기화)를 고르세요.
2. 동일한 필드와 동작으로 JSON과 Protobuf 구현을 만들어 비교하세요.
3. 와이어상 크기, 중간값/95백분위 응답시간, 중간급 폰에서의 파싱 시간, 오류율, 디버깅 시간을 측정하세요.
4. 필드를 추가·폐기하는 방식과 클라이언트가 알 수 없는 필드를 처리하는 정책을 문서화하세요.

빠르게 프로토타입을 만들고 싶다면 AppMaster (appmaster.io)가 정의된 데이터 모델에서 백엔드 API와 앱을 생성할 수 있어, 많은 코드를 손으로 쓰지 않고도 사이드바이사이드 파일럿을 운영하고 스키마 변경을 반복하기가 더 쉽습니다.