GraphQL → XML 변환기
GraphQL 스키마나 쿼리를 붙여 넣으세요. 깔끔한 XML을 돌려드립니다.
이 도구가 하는 일
XML만 다루는 팀을 위해 GraphQL API를 문서화해 본 적이 있거나, GraphQL 스키마를 레거시 SOAP 클라이언트에 물려 본 적이 있다면 그 불편함을 잘 아실 겁니다. GraphQL 타입은 일대일로 매핑되지 않습니다. 스키마나 쿼리를 여기에 붙여 넣으면 한 번의 처리로 잘 형성된 XML이 돌아옵니다. 몇 개의 type 정의든, 전체 SDL 파일이든, 인자가 달린 실제 쿼리든 결과는 동일합니다 — 데이터 모양을 그대로 반영한 완전한 XML 문서입니다.
변환기는 겉 문법만이 아니라 GraphQL 사양을 이해합니다. 스칼라 기본값은 예상대로 — String은 텍스트, Int와 Float는 숫자 텍스트, Boolean은 true/false, ID는 문자열 값이 됩니다. non-null 마커(String!)와 리스트 마커([OrderItem!]!)는 그대로 존중됩니다. 필수 리스트는 항목마다 자식을 가진 컨테이너 요소로 나타나고, 값이 없는 nullable 필드는 빈 요소로 내려와 문서의 형태가 일관되게 유지됩니다.
내장 타입 외에도 타입 시스템의 나머지도 처리합니다. input 타입은 중첩된 요소가 되고, enum 값은 문자열 텍스트로, interface와 union 타입은 실제 구체 타입으로 해석되며, 프래그먼트(명명된 것과 인라인 모두)는 인라인으로 펼쳐져 출력은 평탄하고 자기완결적입니다. DateTime, Date, JSON 같은 커스텀 스칼라는 ISO-8601 또는 문자열화된 값으로 나갑니다. 인자가 달린 query를 붙여 넣으면 인자가 최상위 요소의 일부로 보존되므로, XML은 단순한 데이터 덩어리가 아니라 요청을 충실히 기록한 결과물이 됩니다.
사용 방법
세 단계면 됩니다. 단일 타입을 붙이든, 쿼리까지 포함한 전체 스키마를 붙이든 동작은 같습니다.
GraphQL 붙여 넣기(또는 샘플 시도)
왼쪽 편집기에 GraphQL을 그대로 붙여 넣으세요. 단일 type, input/enum/interface/union이 들어 있는 SDL 파일 전체, 변수를 가진 실제 쿼리 모두 괜찮습니다. 먼저 현실적인 모양으로 시험해 보고 싶다면 샘플 불러오기를 눌러 보세요.
주석을 떼어내거나 SDL 구문을 다시 정렬할 필요는 없습니다. 에디터가 쓴 그대로 두세요 — 삼중 따옴표 독스트링과 해시 주석 모두 문제없이 통과합니다.
변환 누르기
초록색 변환 버튼을 누르세요. 도구가 스키마(또는 쿼리)를 읽어 프래그먼트와 리스트/non-null 마커를 해석한 뒤 한 번에 XML을 만들어 냅니다. 변환 중에는 짧은 로딩 표시가 나타납니다.
XML 복사
오른쪽 패널이 표준을 따르는 XML 파서라면 어디서든 받아주는 들여쓰기된 정형 XML로 채워집니다. 그대로 SOAP 요청, 문서, 픽스처, XSD 예시에 복사해 넣으면 됩니다.
실제로 도움이 되는 순간
GraphQL API를 위한 XML 기반 문서
XML(DITA, DocBook, XSD 기반 레퍼런스)로 관리되는 내부 문서나 파트너 문서. 스키마를 붙이면 실제 타입과 맞물린 예제 XML 페이로드가 나오므로 손으로 옮길 필요가 없습니다.
스키마로부터 XML 픽스처 생성
컨트랙트 테스트, 스냅샷 테스트, XML을 쓰는 목 서버. 이미 가지고 있는 스키마를 넣으면 리스트, nullable, 중첩 타입이 모두 올바른 자리에 들어간 일관된 픽스처 XML을 얻습니다.
레거시 SOAP 클라이언트와 연결
파트너 시스템은 XML 페이로드만 받는데 백엔드는 GraphQL을 쓰는 상황. 쿼리와 응답 타입을 붙이면 SOAP 요청에 그대로 넣을 수 있는 시작점 XML 바디가 나옵니다.
스키마 마이그레이션과 분석
GraphQL에서 XML 기반 API로 옮기거나 두 형태를 나란히 비교할 때. 각 타입의 XML 버전을 나란히 보여 줄 수 있어 SDL을 읽지 못하는 리뷰어도 따라올 수 있습니다.
자주 묻는 질문
type, input, enum, interface, union은 어떻게 처리되나요?
type과 input은 필드마다 자식을 가진 컨테이너 요소가 됩니다. enum 값은 일반 문자열 텍스트(SDL에 선언된 대로의 대문자 이름)로 나옵니다. interface는 구체 타입이 확인되면 자신의 필드와 구현 타입의 필드를 합쳐서 해석됩니다. union은 매칭된 멤버의 형태로 해석됩니다. 전체 규칙은 GraphQL 타입 언어 레퍼런스를 참고하세요.
String, Int, Float, Boolean, ID의 기본값은 무엇인가요?
String과 ID는 텍스트 내용이 됩니다. Int는 일반 정수. Float는 뒤쪽 0 없는 소수. Boolean은 소문자 true 또는 false 텍스트입니다. GraphQL 사양의 스칼라 정의와 맞아떨어지므로 출력은 XML 파서를 깔끔하게 통과합니다.
non-null(!)과 리스트([T]) 마커는 어떻게 다뤄지나요?
non-null(String!)은 반드시 나타나야 하는 필드로 처리되며, 값이 없는 nullable 필드는 빈 요소로 내려와 문서 구조가 예측 가능한 상태로 유지됩니다. 리스트([OrderItem!]!)는 요소 타입 이름을 딴 컨테이너 요소가 되고, 각 항목마다 자식을 둡니다 — 예를 들어 items: [OrderItem!]!은 <items><OrderItem/><OrderItem/></items>가 됩니다. 중첩 리스트([[Int]])도 같은 방식으로 중첩됩니다.
프래그먼트도 해석되나요?
네. 명명된 프래그먼트(...OrderFields)와 인라인 프래그먼트(... on Order { ... })는 인라인으로 펼쳐져 XML이 평탄하고 자기완결적이 됩니다. 프래그먼트 정의를 따로 붙일 필요는 없고, 같은 블록 안에 있으면 도구가 알아서 연결합니다. 이는 응답이 구성되기 전에 프래그먼트가 선택 집합으로 펼쳐지는 일반적인 쿼리 실행 모델과 맞습니다.
DateTime 같은 커스텀 스칼라는 어떻게 되나요?
잘 알려진 커스텀 스칼라(DateTime, Date, Time, UUID, JSON)는 관례에 따라 ISO-8601 텍스트나 문자열화된 값으로 출력됩니다 — 대부분의 스칼라 라이브러리가 하는 방식과 같습니다. 알 수 없는 커스텀 스칼라는 문자열 텍스트로 떨어져서 조용히 사라지는 값은 없습니다. 특정 포맷이 필요하면 XML을 후처리하거나 스칼라 이름을 바꾸세요.
스키마뿐 아니라 인자가 있는 쿼리도 붙일 수 있나요?
가능합니다. 변수와 인자가 있는 query, 예를 들어 query GetOrder($orderId: ID!) { order(id: $orderId) { ... } }를 붙여 넣으면 인자는 최상위 요소의 속성으로 들어갑니다. 선택한 필드가 어떤 응답 형태를 직렬화할지 결정하므로, XML은 타입 전체가 아니라 해당 쿼리가 실제로 반환하는 내용과 일치합니다.
함께 쓰면 좋은 도구
GraphQL→XML은 퍼즐의 한 조각입니다. 아래 도구들과 궁합이 좋습니다: