JSON → TypeScript 변환기 (타입 생성)
JSON을 붙여넣으면 TypeScript interface를 자동 생성
API 응답 예시를 붙여넣으세요
최상위 interface·type 의 이름
붙여넣은 샘플로부터 추론합니다 — 샘플에 없는 필드·타입은 알 수 없으니, 생성된 타입은 출발점으로 쓰고 실제 명세와 대조해 optional·nullable 을 보강하세요.
예시 하나로 타입을 얻는다
API를 다룰 때 가장 번거로운 일 중 하나가 응답 JSON에 맞는 타입을 손으로 적는 것입니다. 이 도구는 실제 응답 예시(JSON) 하나를 붙여넣으면, 그 구조를 읽어 TypeScript interface를 만들어 줍니다.
{ "id": 1, "name": "홍길동", "tags": ["a","b"],
"profile": { "age": 30, "city": null } }
↓
export interface Root {
id: number;
name: string;
tags: string[];
profile: Profile;
}
export interface Profile {
age: number;
city: null;
}객체는 interface가 되고(중첩 객체는 별도 interface로 분리), 배열은 원소 타입의 []가 됩니다. 이렇게 만든 타입을 코드에 붙이면 필드 자동완성과 컴파일 단계의 오타 검출을 바로 얻습니다. 단순히 JSON을 보기 좋게 정렬하거나 검증하는 일은 JSON 포맷터가 맡습니다 — 이 도구는 그 JSON을 타입으로 바꿉니다.
추론의 세 가지 판단: optional · union · 병합
배열 안에 비슷한 객체가 여럿 있으면, 이 도구는 그것들을 종합해 판단합니다.
- 병합 —
[{id:1,name:"a"}, {id:2}]같은 객체 배열은 하나의 interface로 합칩니다. - optional(?) — 어떤 객체엔 있고 어떤 객체엔 없는 키(
name)는name?: string으로 표시합니다. - union(|) — 한 필드에 여러 타입이 섞이면(
[1, "two"])number | string으로 만듭니다.
이건 ‘추론’이다 — 그 한계
가장 중요한 점입니다. 이 변환은 붙여넣은 샘플로부터의 추론입니다. 실제 API가 어떤 상황에서 다른 필드를 보내거나 null을 줄 수 있어도, 샘플에 그 경우가 없으면 도구는 알 방법이 없습니다.
- 빈 배열
[]은 원소 타입을 몰라unknown[]으로 둡니다 —any[]로 뭉개 통과시키지 않습니다. null만 있는 필드는null타입이 됩니다. 실제 값이 있는 응답도 함께 넣으면string | null처럼 더 정확해집니다.
그래서 생성된 타입은 출발점으로 쓰고, 실제 명세와 대조해 optional·nullable을 보강하는 편이 안전합니다. 없는 정보를 지어내지 않는 것 — 그게 이 도구가 택한 정직한 방식입니다. 응답이 이스케이프된 유니코드(가)로 와서 읽기 어렵다면 유니코드 이스케이프 변환기로 먼저 풀어 보세요.
자주 묻는 질문
- JSON을 TypeScript 타입으로 왜 바꾸나요?
- API 응답 같은 JSON을 코드에서 안전하게 다루기 위해서입니다. TypeScript 인터페이스로 만들어 두면, 응답 객체의 필드 이름을 자동완성으로 받고 오타나 없는 필드 접근을 컴파일 단계에서 잡을 수 있습니다. 실제 응답 예시(JSON) 하나만 붙여넣으면 이 도구가 그 구조에 맞는 interface를 만들어 주므로, 손으로 타입을 하나하나 적는 수고를 덜 수 있습니다.
- optional(?)과 union(|)은 어떻게 정해지나요?
- 배열 안 객체들을 비교해서 정합니다. 예를 들어 [{id:1,name:'a'},{id:2}]처럼 어떤 객체엔 name이 있고 어떤 객체엔 없으면, name은 optional(name?: string)로 표시됩니다. 또 한 필드에 여러 타입이 섞여 있으면(예: [1,'two']) union(number | string)으로 만듭니다. 즉 이 도구는 여러 샘플을 종합해 '있을 수도, 없을 수도' 있는 필드와 '여러 타입일 수 있는' 필드를 추론합니다.
- 샘플에 없던 필드나 타입도 알아서 넣어 주나요?
- 아니요, 그럴 수 없습니다. 이 변환은 어디까지나 '붙여넣은 샘플로부터의 추론'입니다. 실제 API가 어떤 상황에서 다른 필드를 보내거나 null을 줄 수 있어도, 샘플에 그 경우가 없으면 도구는 알 방법이 없습니다. 그래서 생성된 타입은 출발점으로 쓰고, 실제 명세(문서·스키마)와 대조해 optional·union·nullable을 직접 보강하는 것이 안전합니다. 없는 정보를 지어내지 않는 것이 정직한 동작입니다.
- 빈 배열이나 null은 어떻게 처리되나요?
- 빈 배열([])은 원소 타입을 알 수 없으므로 unknown[]으로 둡니다(any[]로 뭉개 통과시키지 않습니다). null 값은 null 타입으로 표시하는데, 실제로는 'string이지만 가끔 null'인 경우가 많으므로 samples에 실제 값이 있는 다른 응답도 함께 넣으면 string | null처럼 더 정확해집니다. 이 도구는 샘플이 말해 주는 것만 정직하게 반영합니다.
- interface와 type 중 뭘 쓰나요?
- 이 도구는 객체 구조를 interface로, 최상위가 배열이거나 원시값이면 type 별칭으로 냅니다. 둘은 대부분의 객체 타입에서 사실상 같게 동작하지만, interface는 나중에 같은 이름으로 선언을 합쳐 확장(declaration merging)할 수 있고 객체 형태를 표현하는 관례라 이 도구의 기본으로 삼았습니다. 유니온·튜플처럼 interface로 표현할 수 없는 형태만 type으로 냅니다.