데이터에도 계획이 필요합니다 — 저장, 형식, 그리고 성장 이야기

안녕하세요, 채원이에요.

지난번에는 3Min API가 어떻게 시작됐는지 — 반복되는 전화, 일회성 백엔드, 흩어진 데이터 — 이야기를 했었는데요. 오늘은 이 서비스를 설계하면서 가장 많이 고민했던 부분에 대해 이야기해 볼게요.

바로 데이터예요.

대시보드나 실시간 알림 같은 눈에 보이는 기능이 아니라, 조용하지만 모든 것의 토대가 되는 것 — 데이터가 어떤 구조로 저장되고, 나중에 어떻게 활용되는지. 이 부분을 초반에 잘못 잡으면, 나중에 모든 게 어려워지거든요.

회사마다 데이터 형식이 다 다르다

일찍 깨달은 게 하나 있어요. 함께 일하는 모든 회사가 데이터를 저장하는 방식이 달랐다는 거예요. 물류 회사는 운송장번호, 출발지, 도착지, 무게 같은 필드를 쓰고, 이커머스 회사는 주문번호, 상품명, 수량, 가격을 관리해요.

같은 업종이라도 똑같은 구조를 쓰는 경우는 거의 없었어요. 각 회사의 데이터베이스 — 정보가 저장되는 시스템 — 에는 저마다의 "스키마"가 있었거든요. 스키마는 일종의 설계도예요. 어떤 종류의 데이터가 어디에 들어가는지, 뭐가 필수인지, 어떤 형식이어야 하는지를 정해놓은 것이에요.

그래서 API로 연동하려고 하면 항상 첫 번째 질문은 같았어요. "데이터 형식을 어떻게 맞출 건가요?"

JSON: 공통 언어

여기서 JSON이 등장해요. 처음 들어보셔도 괜찮아요 — 앞으로 정말 많이 듣게 될 단어니까, 지금 이해해 두시면 좋아요.

JSON은 "JavaScript Object Notation"의 약자예요. 이름에 JavaScript가 들어 있지만 코딩과는 상관없어요. 사람과 컴퓨터 모두 읽을 수 있는, 구조화된 데이터를 쓰는 간단한 방식이에요.

이렇게 생겼어요:

{
  "company": "해돋이 물류",
  "order_id": "ORD-20260301",
  "items": 12,
  "delivered": true
}

이게 전부예요. 중괄호 안에, 왼쪽은 이름(키), 오른쪽은 값. 가볍고, 유연하고, 그리고 가장 중요한 건 — API의 사실상 표준이라는 거예요. 두 시스템이 인터넷을 통해 대화할 때, 대부분 JSON으로 이야기해요.

3Min API가 JSON을 핵심 데이터 형식으로 선택한 이유가 바로 이 보편성이에요. 거래처가 JSON으로 데이터를 보내면, 저희가 JSON으로 저장하고, 나중에 기록을 다운로드할 때도 JSON으로 받으세요. 변환 과정이 없어요. 형식 맞추느라 고생할 일도 없고요.

기술 개념 중에 하나만 익혀두신다면, 이거예요. API와 JSON은 비즈니스가 성장하고 파트너가 늘어날수록 계속 등장하거든요.

잠깐 — JSON을 그대로 저장할 수 있나요?

좋은 질문이에요. 네, 가능해요. JSON을 딱딱한 행과 열로 변환하지 않고 있는 그대로 저장하도록 설계된 데이터베이스가 있어요. "문서형 데이터베이스" 또는 "NoSQL 데이터베이스"라고 부르는데, MongoDB가 아마 가장 유명할 거예요.

3Min API도 내부적으로 비슷한 방식을 사용해요. 엔드포인트로 데이터가 들어오면, 전체 JSON 페이로드를 유연한 문서 형태로 저장해요. 전통적인 데이터베이스 테이블을 미리 정의할 필요가 없다는 뜻이에요. 받고 싶은 데이터의 형태만 기술하면, 나머지는 저희가 처리해요.

하지만 만능은 아니에요

솔직히 말씀드릴게요 — JSON으로 데이터를 저장하는 게 모든 상황에 완벽한 건 아니에요.

장점: 세팅이 믿을 수 없을 만큼 빨라요. 몇 분 안에 데이터를 받기 시작할 수 있어요. 거래처가 새 필드를 추가해도 아무것도 다시 만들 필요 없이 적응할 수 있고요. 태생적으로 유연해요.

단점: 바로 그 유연함이 조심하지 않으면 문제가 될 수 있어요. 엄격한 스키마를 가진 전통적인 데이터베이스는 일관성을 강제하는 장점이 있어요. 모든 기록이 같은 모양이니까 검색, 정렬, 분석이 쉽죠.

유연한 형식에서는 데이터 구조를 너무 자주 바꾸면 기록마다 모양이 조금씩 달라져요. 어떤 건 필드가 5개, 어떤 건 8개. 어떤 건 order_date, 어떤 건 date_ordered. 시간이 지나면 이런 불일치가 데이터를 다루기 어렵게 만들어요 — 특히 나중에 분석하려 할 때요.

실전 팁: 운영 전에 계획을 세우세요

그래서 프로덕션에 들어가기 전에 샌드박스 환경을 충분히 활용하시길 강력히 권해요.

엔드포인트를 처음 만들 때, 거래처와 시간을 들여 데이터 구조를 협의하세요. 테스트 데이터를 주고받으면서 필드명, 타입, 전체적인 형태가 양쪽 모두에게 맞는지 확인하세요. 샌드박스가 바로 이 용도로 있는 거예요 — 아무것도 영구적이지 않고, 실수해도 비용이 들지 않는 안전한 공간이에요.

양쪽 다 형식이 맞다고 확신이 들면, 그때 프로덕션으로 배포하세요. 거기서부터 실제 데이터가 흘러요.

그리고 나중에 데이터 형식을 크게 바꿔야 한다면? 기존 엔드포인트를 수정하지 마세요. 새로 하나 만드세요. 엔드포인트 개수에 제한이 없으니까, 비즈니스에 필요한 만큼 자유롭게 만들어도 돼요. 이렇게 하면 기존 데이터는 깔끔하고 일관되게 유지되면서, 새 형식은 새 출발을 할 수 있어요.

더 큰 그림: 데이터는 비즈니스 자산이에요

여기서 모든 게 연결돼요.

3Min API를 통해 흐르는 모든 API 호출은 실제 비즈니스 거래의 기록이에요 — 접수된 주문, 요청된 배송, 확정된 예약. 시간이 지나면 이 기록들이 쌓여서 가치 있는 것이 돼요. 여러분의 비즈니스 이야기를 담은 데이터셋이요.

그래서 아카이브 기능을 만들었어요. 데이터를 JSONL 파일로 다운로드할 수 있어요 — 한 줄에 JSON 기록 하나 — 그리고 필요한 방식으로 활용하시면 돼요.

뭘 할 수 있냐고요? 생각보다 많아요:

• 엑셀이나 Google 스프레드시트에서 열어서 빠르게 훑어보기
• BI 도구 (Metabase, Redash, Google Looker Studio 등)에 넣어서 대시보드 만들기
• AI 어시스턴트에 넘겨서 일상 언어로 질문하기
• 데이터 분석가나 컨설팅 업체에 맡겨서 전문적으로 분석받기

목표는 단순히 데이터를 저장하는 게 아니라, 인사이트로 바꾸는 거예요. 어떤 상품이 가장 빠르게 팔리는지? 어떤 거래처가 주문을 가장 많이 보내는지? 미리 대비할 수 있는 계절적 패턴이 있는지?

감이 아니라 실제 데이터에 기반해서 의사결정을 하면, 비즈니스가 더 단단한 기반 위에서 성장해요. 부족한 부분은 고치고, 잘 되는 부분은 더 밀어주고. 그리고 큰 결정의 순간이 왔을 때 — 새 시장 진출, 인원 충원, 새로운 도구에 투자 — 숫자가 뒷받침해 줄 거예요.

3Min API를 쓰는 모든 팀이 그렇게 되길 바라요. A에서 B로 데이터를 옮기는 파이프가 아니라, 비즈니스를 이해하고 성장시키는 기반이 되길요.