PowerShell → XML 변환기
PowerShell 객체나 해시테이블을 붙여넣으세요. 깔끔한 XML을 돌려드립니다.
이 도구가 하는 일
PowerShell 설정을 XML 파일로 내보내야 했던 적이 있다면 — DSC 리소스, MSBuild 태스크, app.config 템플릿, SoapUI 픽스처 등 — 어떻게 돌아가는지 이미 아실 겁니다. ConvertTo-Xml을 돌리고 보기 싫은 <Object Type="..."> 래퍼를 직접 쳐내거나, Export-CliXml을 써서 PowerShell 밖에서는 아무도 못 읽는 CLIXML 페이로드를 받아드는 식이죠. 여기에 PowerShell을 붙여넣으면, 일반 XML 파서가 받아들이는 잘 구성된 XML을 돌려드립니다 — <Property Name="..."> 잡음도, CLIXML 타입 태그도 없이, 데이터만.
PowerShell 코드가 실제로 쓰는 형태를 이해합니다. PSCustomObject는 각 프로퍼티 이름을 따르는 자식 엘리먼트를 가진 엘리먼트가 됩니다. 해시테이블 @{ Name = "Ava" }도 같은 식으로 동작합니다. @(...)로 만든 배열은 아이템마다 자식 하나를 가진 컨테이너 엘리먼트가 됩니다. 부모 객체 안에 중첩된 [PSCustomObject] 값은 문자열로 뭉뚱그려지지 않고 중첩 엘리먼트로 그대로 나옵니다. 불리언($true, $false)과 숫자는 출력에서 네이티브 타입을 유지합니다. $null은 필드가 조용히 사라지는 대신 빈 자체 종료 엘리먼트가 되어, 형태가 예측 가능하게 유지됩니다.
언어의 몇 가지 특성은 사람이 기대하는 대로 처리됩니다. 큰따옴표 문자열은 $var 같은 보간 마커를 확장하지 않고 통과합니다 — 붙여넣은 그대로 보존합니다. 히어 문자열(@" ... "@)은 여러 줄 텍스트 콘텐츠로 취급됩니다. [datetime]"2026-04-21"처럼 쓴 날짜는 ISO-8601 문자열로 나옵니다. 하이픈이 들어간 프로퍼티 이름에는 안전한 엘리먼트 이름이 부여됩니다 (PowerShell은 해시테이블에서 "User-Agent" = "..."라고 쓸 수 있지만, 이는 원시 XML 태그로는 불법입니다 — 출력이 계속 파싱 가능하도록 변환합니다). 형태는 입력에 충실하게, XML은 쓸 만한 상태로 유지됩니다.
사용법
세 단계. 해시테이블 하나를 붙이든 설정 스크립트 전체를 붙이든 동작은 똑같습니다.
PowerShell 붙여넣기 (또는 샘플 사용)
왼쪽 에디터에 스크립트를 넣으세요. 단일 [PSCustomObject]@{...}, 중첩 해시테이블, 객체 @(...) 배열, 설정 블록 전체 — 모두 괜찮습니다. 현실적인 주문(Order) 페이로드로 먼저 놀아보고 싶다면 샘플 불러오기를 누르세요.
사전에 주석을 지우거나 param() 블록을 빼거나 스크립트를 다듬을 필요 없습니다. 가진 그대로 붙여넣으세요. 객체 리터럴만 읽고 나머지는 무시합니다.
변환 누르기
초록색 변환 버튼을 누르세요. 도구가 PowerShell 구조를 훑고, 모든 프로퍼티와 배열 아이템을 보존해, 한 번에 XML을 만듭니다. 실행되는 동안 짧은 로딩 표시가 뜹니다.
XML 복사하기
오른쪽 패널에 표준을 따르는 파서가 받아들일 들여쓰기된 XML이 채워집니다. DSC 구성, MSBuild 파일, 또는 필요한 곳에 그대로 넣으세요.
실제로 쓸모 있는 순간
DSC 구성 페이로드 작성
노드 구성을 기술한 PowerShell 해시테이블이 있고, DSC가 아닌 소비자나 문서용으로 XML 버전이 필요할 때. 붙여넣고 변환, 끝 — ConvertTo-Xml 출력을 더 이상 어르고 달랠 필요 없습니다.
Azure DevOps 파이프라인 변수 파일
파이프라인이 변수 그룹을 XML로 기대할 때가 있습니다. 이미 유지 중인 PowerShell 해시테이블을 붙여넣으면 <code>variables.xml</code>에 바로 들어가는 XML이 나옵니다 — 손으로 고칠 일 없이.
Windows 이벤트 로그 페이로드 내보내기
PowerShell에서 이벤트 레코드를 PSCustomObject로 만들어 XML을 받는 로깅 파이프라인에 넘겨야 할 때, 전용 직렬화기를 짜는 수고를 덜어줍니다. 중첩된 형태가 그대로 통과합니다.
app.config / web.config 시드 템플릿
PowerShell 설정 해시테이블을 직접 편집할 수 있는 시작점 <code>app.config</code>으로 바꿉니다. 처음부터 쓰는 것보다 빠르고, 키를 스크립트와 동기화해두기도 쉽습니다.
자주 묻는 질문
내 객체에 ConvertTo-Xml을 돌리는 것과 뭐가 다른가요?
ConvertTo-Xml은 모든 것을 제네릭한 <Object Type="..."><Property Name="..."> 봉투로 감쌉니다 — PowerShell에서는 읽히지만 다른 곳에서는 못 봐주겠죠. 이 도구는 프로퍼티 이름을 실제 XML 엘리먼트로 내보내서, 사람이 손으로 쓴 것 같은 XML이 나옵니다. <Property Name> 간접 계층도, 타입 속성 잡음도 없습니다.
Export-CliXml처럼 CLIXML을 만드나요?
아니요 — 그게 포인트입니다. Export-CliXml은 CLIXML을 출력합니다. 이는 PowerShell로 다시 돌려오기 위한 PowerShell 전용 포맷입니다. XML을 PowerShell이 아닌 시스템 (Java 서비스, 설정 리더, XSD로 검증되는 파이프라인)에 넘겨야 한다면 CLIXML은 맞는 형태가 아닙니다. 이 도구는 대신 평범하고 읽히는 XML을 돌려드립니다.
.ps1 파일 전체를 붙여도 되나요, 아니면 객체 리터럴만인가요?
가진 걸 붙여넣으세요. 스크립트에 변수에 할당된 객체 리터럴 하나가 있다면 그게 출력됩니다. 최상위에 여러 해시테이블이나 PSCustomObject가 있다면 각각 자신의 엘리먼트로 나옵니다. 함수 본체, param() 블록, import, Write-Host 줄은 무시됩니다 — 데이터 형태만 중요합니다.
$null, $true, $false, 빈 배열은 어떻게 처리되나요?
$null은 빈 자체 종료 엘리먼트가 되어 형태가 일관되게 유지됩니다 (필드가 사라지지 않습니다). $true와 $false는 리터럴 문자열 true와 false가 됩니다. 빈 @()는 빈 컨테이너 엘리먼트가 됩니다. 그래서 일부 필드가 비어 있어도 하류 도구는 항상 같은 구조를 봅니다.
유효한 XML 이름이 아닌 해시테이블 키 — 하이픈, 공백, 숫자로 시작 — 는요?
"User-Agent"나 "2024-Q1" 같은 키는 PowerShell 해시테이블에서는 합법이지만 원시 XML 엘리먼트 이름으로는 불법입니다. 안전한 형태로 다시 쓰고 (의미가 있다면 원본을 속성으로 유지) 출력이 파싱 가능하게 유지합니다. 소비자 측에서 중요하다면 생성된 태그를 먼저 훑어보세요.
제 코드가 저장되나요?
코드는 변환을 위해 백엔드로 전송되며 저장되지 않습니다 — 페이로드를 로그에 남기지 않습니다. 스크립트가 정말 민감하다면(프로덕션 자격 증명, 내부 경로), 온라인 도구 쓸 때처럼 붙여넣기 전에 마스킹하세요.
함께 쓰면 좋은 다른 도구
PowerShell → XML은 퍼즐의 한 조각입니다. 이 도구들과 궁합이 좋아요: