JSON → TypeScript 타입 변환기

JSON 객체(또는 JSON 배열)를 붙여넣으면 이에 대응하는 TypeScript interface/type 정의를 자동으로 생성합니다.

마지막 업데이트: 2026-09-20

이다음에 많이 사용하는 도구

JSON에서 TypeScript 타입 정의 만들기

API의 응답을 TypeScript로 받을 때 가장 먼저 필요한 것이 타입 정의입니다. 그런데 중첩이 깊은 JSON을 보면서 `interface`를 손으로 써 내려가는 일은 고되고, **프로퍼티를 빠뜨리거나 타입을 잘못 잡기 쉬운 작업**이기도 합니다. 이 도구는 JSON을 붙여 넣기만 하면 대응하는 `interface`／`type`을 자동으로 생성합니다.

생성에서는 값의 JavaScript상 타입으로부터 TypeScript의 타입을 추론합니다. **중첩된 객체는 별도의 interface로 떼어 내고**, 배열은 요소의 타입에서 `T[]`를 이끌어 냅니다. 루트 타입의 이름은 자유롭게 지정할 수 있어 생성물을 그대로 프로젝트에 붙여 넣을 수 있습니다. **추론은 어디까지나 붙여 넣은 샘플에 근거하므로, 생략될 수 있는 프로퍼티나 `null`을 취할 수 있는 항목은 생성 후에 `?`나 유니온 타입을 직접 더해 주세요.** 처리는 모두 브라우저 안에서 완결됩니다.

타입 정의를 생성하는 순서

JSON을 붙여 넣습니다 API의 응답 예시 등을 그대로 입력합니다. 객체든 배열이든 상관없습니다.
루트 타입의 이름을 정합니다 생성되는 최상위 interface 이름이 됩니다. 기본값 그대로도 괜찮습니다.
생성 결과를 확인합니다 중첩된 객체는 별도의 interface로 떼어져 나열됩니다.
생략 가능한 항목을 손으로 보완합니다 **샘플에 나타나지 않는 항목은 추론할 수 없습니다.** `?`나 `| null`은 직접 더해 주세요.
복사해 프로젝트에 붙여 넣습니다 그대로 `.ts` 파일에 붙여 넣을 수 있습니다.

더 잘 활용하기 위한 팁

배열의 모든 요소가 객체인 경우, 각 요소의 키를 병합하여 하나의 interface를 생성합니다. 일부 요소에만 없는 키는 자동으로 선택적(`?`) 속성으로 처리됩니다.
루트 타입의 이름은 기본값인 "Root"에서 원하는 이름(예: `User`, `ApiResponse`)으로 변경할 수 있습니다. 중첩된 객체의 interface 이름은 해당 속성 이름을 기반으로 자동 생성됩니다.
API 응답의 샘플 JSON을 그대로 붙여넣으면 프런트엔드 구현에서 사용할 타입 정의의 초안을 빠르게 얻을 수 있습니다.
생성된 결과는 어디까지나 구조로부터 추론한 타입 초안일 뿐입니다. 실제 API 사양(nullable 여부, 필수 항목 등)과 대조하여 수동으로 조정하는 것을 권장합니다.

이럴 때 쓸 수 있습니다

외부 API의 타입을 마련할 때

문서에 타입 정의가 없는 API라도 응답 예시만 있으면 출발점을 만들 수 있습니다.

기존 JSON 설정 파일에 타입을 붙일 때

설정 파일을 타입 안전하게 읽고 싶을 때 구조를 그대로 타입으로 옮길 수 있습니다.

목 데이터에서 타입을 일으킬 때

프런트엔드를 먼저 만드는 국면에서 임시 데이터로 타입을 마련할 수 있습니다.

타입의 누락을 검산할 때

손으로 쓴 타입 정의와 생성된 타입을 견주어 빠진 것을 찾을 수 있습니다.

TypeScript 용어

interface: 객체의 형태를 나타내는 선언입니다. **같은 이름으로 여러 번 선언하면 자동으로 합쳐진다**는 점이 type과의 차이입니다.
type 별칭: 임의의 타입에 이름을 붙이는 선언입니다. 유니온 타입이나 원시 타입에도 이름을 붙일 수 있습니다.
선택적 프로퍼티: `name?: string`처럼 `?`를 붙인 항목입니다. **붙여 넣은 샘플로부터는 추론할 수 없습니다.**
유니온 타입: `string | null`처럼 여러 타입 가운데 하나를 취할 수 있음을 나타냅니다.
중첩 객체: 값이 다시 객체로 되어 있는 구조입니다. 이 도구는 별도의 interface로 떼어 냅니다.
타입 추론: 값으로부터 타입을 이끌어 내는 것입니다. **여기서의 추론은 붙여 넣은 한 건의 샘플에 근거하므로 실제 API 사양이라고는 할 수 없습니다.**

자주 묻는 질문

API 응답 샘플 JSON을 보고 수작업으로 타입 정의를 작성하는 것은 시간이 많이 걸리고, 키 이름을 잘못 입력하거나 타입을 놓치기 쉬운 작업입니다. 자동 생성을 이용하면 프런트엔드 개발자가 타입 정의 작성에 드는 시간을 크게 줄이고 이러한 실수도 방지할 수 있습니다.

배열 안의 모든 요소의 키를 병합하며, 일부 요소에만 존재하는 키는 자동으로 선택적 속성(`?`)으로 처리됩니다. 또한 같은 키라도 요소에 따라 타입이 다르면 유니온 타입(`string | number` 등)으로 표현됩니다.

생성된 타입 정의는 어디까지나 샘플 JSON의 구조로부터 기계적으로 추론한 것입니다. null 허용 여부나 향후 추가될 수 있는 필드 등 샘플 JSON만으로는 판단할 수 없는 정보가 있으므로, API 사양서와 대조하여 수동으로 조정하는 것을 권장합니다.

중첩된 객체의 interface 이름은 해당 객체가 저장된 속성 이름을 기반으로 자동 생성됩니다(예: `profile`이라는 키의 객체는 `Profile`이라는 이름의 interface가 됩니다). 같은 이름이지만 형태가 다른 interface가 필요한 경우, 끝에 번호를 붙여 구분합니다.

여담 ― 타입 추론 도구가 해결하는 "타입 불일치" 문제

TypeScript는 정적 타입을 통해 컴파일 시점에 버그를 발견할 수 있는 언어이지만, 외부 API로부터 받는 JSON 데이터의 타입은 개발자가 직접 정의하지 않는 한 TypeScript 컴파일러가 알 수 없습니다. API 사양과 샘플 응답 사이에 차이가 생기거나 필드가 추가·삭제될 때마다 타입 정의를 수동으로 갱신해야 하며, 이러한 "타입 정의와 API의 실제 모습 사이의 괴리"는 많은 프런트엔드 프로젝트에서 골칫거리였습니다.

JSON → TypeScript 변환 도구는 실제로 반환된 샘플 JSON으로부터 타입을 기계적으로 역산함으로써 이 작업을 크게 효율화합니다. 같은 부류의 도구로는 quicktype(여러 언어의 타입 정의를 생성할 수 있는 오픈소스 도구)이 유명하며, JSON Schema・GraphQL 스키마 등 다양한 입력 형식을 지원하는 고기능 구현으로 잘 알려져 있습니다.

타입 추론의 어려움은 JSON 자체에 "이 필드가 항상 존재하는지", "앞으로 null이 될 수 있는지"와 같은 정보가 담겨 있지 않다는 점에 있습니다. 그래서 자동 생성된 타입 정의는 만능이 아니며, 어디까지나 "이번 샘플 데이터의 구조"를 반영한 초안으로 취급하고 실제 API 사양과 대조하여 조정하는 것이 실무상의 정석으로 여겨집니다.

모든 여담 보기