JSON 정렬은 공백만 바꾸고 그 밖에는 아무것도 바꾸지 않아야 합니다. 그 일을 해 주겠다는 도구 대부분이 그보다 많은 것을 바꾸고, 그중 어느 것도 그 사실을 말하지 않습니다. 무엇을 지켜봐야 하는지, 파일이 파싱되지 않을 때 오류를 어떻게 읽는지, 그리고 설정 파일을 붙여 넣는 그 상자가 왜 한 번쯤 생각해 볼 만한 것인지 정리했습니다.
JSON 포매터 열기JSON, XML, HTML, CSS, YAML을 정렬하거나 변환합니다. 남의 서버에 붙여 넣는 것은 없습니다.
# 누구에게도 넘기지 않고 JSON을 정렬하는 방법
JSON 정렬은 공백만 바꾸고 그 밖에는 아무것도 바꾸지 않아야 합니다. 그 일을 해 주겠다는 도구 대부분이 그보다 많은 것을 바꾸고, 그중 어느 것도 그 사실을 말하지 않습니다. 무엇을 지켜봐야 하는지, 파일이 파싱되지 않을 때 오류를 어떻게 읽는지, 그리고 설정 파일을 붙여 넣는 그 상자가 왜 한 번쯤 생각해 볼 만한 것인지 정리했습니다.
[JSON 포매터 열기](https://abox.tools/ko/json-포맷터/): JSON, XML, HTML, CSS, YAML을 정렬하거나 변환합니다. 남의 서버에 붙여 넣는 것은 없습니다.
마지막 업데이트 2026년 8월 26일
## 짧은 답
[텍스트와 코드](https://abox.tools/ko/json-포맷터/)를 열고 JSON을 상자에 붙여 넣은 다음 읽으세요. 배치는 입력하는 동안 이루어지고, 언어는 텍스트를 보고 알아내며, 들여쓰기는 따로 말하지 않는 한 공백 두 칸입니다. 아무것도 업로드되지 않습니다. 갈 곳이 없기 때문입니다. 파서는 이미 열려 있는 그 탭에서 도는 수백 줄짜리 JavaScript입니다.
아래는 다른 어떤 대안에 설정 파일을 붙여 넣기 전에 알아 둘 값어치가 있는 부분입니다. 포매터가 무엇을 바꿔도 되는지, 그런데도 대부분이 무엇을 바꾸는지, 그리고 파일이 아예 파싱되지 않을 때 오류를 어떻게 읽는지.
한 줄이 들어가고 읽을 만한 것이 나옵니다. 그러기 위해 어디로도 아무것도 보내지 않았습니다.
## 정렬이란 무엇이고, 무엇이 아닌가
JSON에는 문법이 거의 없습니다. 객체, 배열, 문자열, 숫자, 그리고 `true`, `false`, `null` 세 낱말. 그 조각들 사이에서 공백은 아무 뜻도 없습니다. 이 파일과
```
{"name":"thing","tags":["local","offline"]}
```
이 파일은
```
{
"name": "thing",
"tags": [
"local",
"offline"
]
}
```
같은 문서입니다. 정렬은 앞의 것에서 뒤의 것으로 옮기는 일이고, *그게 일의 전부*입니다. 포매터가 남의 파일에 그 밖에 하는 일, 그러니까 순서를 바꾸거나 반올림하거나 버리는 일은 부탁받지도 않고 문서의 내용을 바꾸는 짓입니다.
그중 셋은 이름을 붙여 둘 만큼 흔합니다. 조용히 일어나고, 하루 만에 쓴 포매터가 기본으로 하는 일이기 때문입니다.
## 포매터가 바꾸면 안 되는 세 가지
### 키의 순서
사람들이 걸려 넘어지는 그것입니다. JavaScript로 JSON 포매터를 쓰는 뻔한 방법은 `JSON.parse`를 부르고 들여쓰기를 넣어 `JSON.stringify`를 부르는 것인데, 그 짝은 정수처럼 생긴 키의 순서를 지키지 않습니다.
```
Object.keys(JSON.parse('{"10":"a","2":"b","x":"c"}'))
// ['2', '10', 'x']
```
누구의 코드에 있는 버그도 아닙니다. JavaScript 객체는 정수처럼 생긴 키를 숫자 오름차순으로 앞에 두도록 명세되어 있고, `JSON.parse`를 지나가는 모든 값은 JavaScript 객체가 됩니다. 그렇게 만든 포매터는 id나 포트 번호, 연도, HTTP 상태 코드로 키를 붙인 파일을 재배열하고, 한마디 말도 없이 그렇게 합니다.
그게 문제가 되는지는 파일에 달렸습니다. JSON 객체는 원칙적으로 순서가 없으니 기술적으로 망가진 것은 없습니다. 다만 저장소에 있는 판본과의 diff가 어마어마해지고, 리뷰는 읽을 수 없게 되며, 하류의 무언가가 그 파일을 순서대로 읽고 있었다면 동작이 달라집니다.
### 숫자의 자릿수
JSON은 숫자가 얼마나 커도 되는지 말하지 않지만 JavaScript는 말합니다. 모든 숫자가 배정밀도 수입니다. 그래서 배정밀도로 파싱했다가 도로 찍어 내는 포매터는 배정밀도가 담지 못하는 것을 잃습니다.
```
JSON.stringify(JSON.parse('{"id":123456789012345678901}'))
// {"id":123456789012345680000}
JSON.stringify(JSON.parse('{"size":1e999}'))
// {"size":null}
```
트위터 id나 스노플레이크 id, 은행 참조 번호 같은 스물한 자리 id가 다른 숫자로 돌아오고, 배정밀도로 담기에 너무 큰 값은 `null`이 되어 돌아옵니다. 두 파일 다 여전히 파싱되지만, 어느 쪽도 처음에 넣은 그 파일이 아닙니다.
빠져나오는 길은 숫자를 아예 파싱하지 않는 것입니다. 포매터는 문서를 배치하기 위해 숫자가 어디서 시작하고 어디서 끝나는지만 알면 되지 그 값은 필요 없습니다. 그러니 안전한 방법은 적힌 그대로 자릿수를 옮기는 것이고, 여기 도구가 하는 일이 그것입니다.
### 중복된 키
`{"a": 1, "a": 2}`는 올바른 JSON이고, 표준은 둘 중 어느 쪽이 이기는지 말하기를 거부합니다. 실제로 파서마다 다릅니다. 대부분은 마지막 것을 남기고, 어떤 것은 첫 번째를 남기며, 몇몇은 문서를 거부합니다. 조용히 하나만 내보내는 포매터는 대신 그 결정을 내려 버린 것이고, 훨씬 쓸모 있는 사실을 숨긴 것입니다. 둘이 있었다는 사실 말이죠. 그건 거의 언제나 파일의 실수이고, 눈으로 봐야 하는 실수입니다.
## 파일이 파싱되지 않을 때
실패하는 JSON은 대개 별난 것이 아닙니다. 여섯 가지쯤 중 하나이고, 오류가 어디인지를 찾아갈 수 있는 말로 알려 준다면 어느 것인지도 말해 줍니다. `position 4193` 같은 오프셋은 그렇지 않고, 줄과 칸은 그렇습니다.
- **끝에 붙은 쉼표.** `{"a": 1,}`는 JavaScript 에서는 되고 JSON에서는 안 됩니다. 가장 흔한 단일 원인이고, 대개 목록의 마지막 항목을 지우면서 남습니다.
- **작은따옴표.** `{'a': 1}`는 JavaScript 객체 리터럴이지 JSON이 아닙니다. 문자열도 키도 큰따옴표를 쓰고, 키에는 언제나 따옴표가 붙습니다.
- **따옴표 없는 키.** `{a: 1}`. 같은 실수의 반대 방향이고, 대개 파일이 아니라 코드에서 무언가를 붙여 넣다가 생깁니다.
- **주석.** `// 이런 것`도 JSON이 아닙니다. 그건 VS Code 설정과 `tsconfig.json`이 쓰는 JSONC이고, 다른 데서는 파싱되지 않습니다. 주석이 꼭 남아야 한다면 관례는 키로 넣는 것입니다. `"_comment": "..."`
- **문자열 안의 진짜 줄바꿈이나 탭.** `\n`과 `\t`로 적어야 합니다. 셸 명령이나 인증서를 손으로 값에 붙여 넣을 때 보통 여기서 어긋납니다.
- **JSON이 허용하지 않는 숫자.** 앞에 붙은 0 (`01`), 홀로 선 소수점(`.5`), `NaN`, `Infinity`, `+1`. 사람들이 쓰는 것들이고 그중 어느 것도 JSON이 아닙니다.
오류가 아닌데 오류처럼 보이는 것이 하나 있습니다. 바이트 순서 표시로 시작하는 파일입니다. 대부분의 편집기에서 보이지 않고, 공백도 아니며, 문서의 맨 첫 글자를 예상 밖의 것으로 만듭니다. 멀쩡해 보이는 파일에서 오류가 1행 1열에 있다면 그것입니다.
읽히지 않을 때는 어디가 문제인지 메시지가 말해 줍니다. 남는 쉼표가 가장 흔한 원인이고 눈으로는 가장 찾기 어려운 원인입니다.
## 눌러 담기, 그리고 대개 얼마나 적게 얻는지
공백을 짜내는 것은 같은 작업의 반대 방향이고, 그것으로 무엇을 얻는지에 대해서는 현실적일 만합니다. 공백은 반복이 아주 심하고, 서버에서 독자까지 가는 길목의 모든 것이 이미 gzip이나 Brotli로 응답을 압축하는데, 그것들이 바로 그런 종류의 반복에 아주 능합니다.
그래서 눌러 담은 JSON은 파일로는 흔히 30% 작지만 회선에서는 몇 퍼센트만 작습니다. 값어치를 하는 자리는 앞에 압축이 없는 곳들입니다. 데이터베이스 열에 담긴 값, 로그 한 줄의 필드, QR 코드 안의 페이로드, 또는 헤더에 Base64로 넣으려는 문서 같은 것들이죠.
치르는 것은 읽기 쉬움이고, 파일이 저장소에 커밋되어 있다면 diff까지 치릅니다 한 줄짜리 파일은 안에서 무엇이 바뀌든 통째로 바뀌니까요. 편집기로 들어가는 길이 아니라 나가는 길에 눌러 담으세요.
## 키 정렬, 그리고 하지 말아야 할 때
모든 객체의 키를 정렬하는 것은 기본으로 적용되지 않고 선택 항목으로 제시 됩니다. 파일을 실제로 바꾸는 일이고, 그 값어치가 이어서 하려는 일에 전적으로 달렸기 때문입니다.
두 환경의 설정이나 변경 전후의 API 응답처럼, 같은 말을 해야 하는 두 문서를 비교할 때 도움이 됩니다. 그중 하나가 키를 다른 순서로 늘어놓고 있을 때요. 둘 다 먼저 정렬하면 전부의 diff가 실제로 다른 두 줄의 diff가 됩니다.
순서가 무언가를 하고 있었다면 해가 됩니다. `package.json`에는 무엇이 먼저 오는지에 대한 관례가 있고, 손으로 쓴 설정 파일은 관련된 항목을 묶어 두는 경우가 많으며, 도구로 키를 정렬해 커밋한 파일은 어마어마하고 의미 없는 커밋 하나를 만들어 냅니다. 원본이 아니라 사본을 정렬하세요.
알아 둘 만한 세부가 하나 있습니다. 여기 정렬은 코드 포인트가 아니라 키가 읽히는 대로 이루어져서, `item2`가 `item10` 뒤가 아니라 앞에 옵니다. 코드 포인트로 정렬하면 `item10`이 1로 시작하는 것들 사이에 끼는데, 기술적으로는 맞고 읽는 사람에게는 쓸모가 없습니다.
## JSON 파일 두 개 비교하기
믿을 만한 방법은 둘 다 같은 방식으로 먼저 정렬하는 것입니다. 같은 말을 하는 두 문서도 하나는 눌러 담겨 있고 다른 하나는 아니라면 모든 줄이 다를 수 있고, 어떤 diff도 그것을 꿰뚫어 보지 못합니다.
그러니 첫 번째를 정렬하고, 두 번째를 정렬하고, 두 결과를 비교하세요. 여기서는 세 단계가 모두 같은 페이지에 있습니다. *비교* 탭이 정확히 이 이유로 *정렬*과 상자를 함께 쓰거든요. 둘이 키를 서로 다른 순서로 늘어놓고 있기까지 하다면, 정렬하는 김에 둘 다 키까지 정렬해 보세요. 비교가 찾고 있던 그 차이 하나로 접힙니다.
## 아무도 페이지에 적지 않는 부분
JSON 포매터를 검색하면 상자가 놓인 사이트를 수십 개 만나게 됩니다. 그 상자에 붙여 넣는 것이 곧 업로드입니다. 클립보드에 있던 것이 무엇이든 고객 주소가 담긴 API 응답이든, 접속 문자열이 담긴 설정 파일이든, 디버깅하던 토큰이든, 내가 통제하지 않는 기기로 전송된 것입니다. 이제 그건 그쪽의 로그 파일이고 오류 보고서이고 백업입니다.
악의에 대한 가정이 아닙니다. 더없이 선의로 운영되는 사이트도 접속 로그를 남기고, 분석을 돌리고, 호스팅 업체를 둡니다. 가장 안전한 데이터는 애초에 떠나지 않은 데이터이고, 전부가 문자열 조작인 작업에서 그것이 떠나야 할 이유는 하나도 없습니다.
확인 두 가지입니다. 이 사이트뿐 아니라 같은 주장을 하는 어떤 사이트에도 통합니다.
1. **개발자 도구의 '네트워크' 탭을 켜 놓고 무언가를 정렬해 보세요.** 텍스트가 전송되고 있다면 그걸 실은 요청이 있습니다. 그와 동시에 참일 수 있는 다른 이야기는 없습니다.
2. **인터넷을 끊고 다시 해 보세요.** 브라우저에서 일하는 도구는 아무 영향도 받지 않습니다. 텍스트를 어딘가로 보내는 도구는 즉시, 완전히 멈추고요.
두 가지를 더한 더 긴 판본이 [파일을 올려도 안전한가](https://abox.tools/ko/가이드/파일-업로드-안전한가/)에 있습니다.
## YAML과 XML, 그리고 나머지는
같은 페이지가 XML과 HTML, CSS, YAML을 읽고, JSON과 그중 첫 번째·마지막 사이를 변환합니다. 위에서 이어 올 만한 것이 둘 있습니다. 옷만 다를 뿐 같은 이야기이기 때문입니다.
- **YAML을 JSON으로 바꾸면 주석을 잃습니다.** JSON에는 그것을 넣을 자리가 없기 때문입니다. "같은 노드를 두 번"이라고 말하는 YAML의 방식인 앵커와 별칭도 표현할 수 없어서, 여기서는 짐작하는 대신 거부합니다.
- **`no`는 문자열입니다.** YAML 1.1에서는 `yes`, `no`, `on`, `off`가 불리언이었고, 노르웨이가 든 국가 코드 목록이 `false`를 달고 돌아오곤 했던 이유입니다. YAML 1.2가 그것을 걷어 냈고 이 도구도 그렇습니다. 다만 그 낱말들은 여전히 따옴표를 씌워 씁니다. 다음에 그 파일을 여는 것이 1.1 리더일 수 있으니까요.
짧은 답
텍스트와 코드를 열고 JSON을 상자에 붙여 넣은 다음 읽으세요. 배치는 입력하는 동안 이루어지고, 언어는 텍스트를 보고 알아내며, 들여쓰기는 따로 말하지 않는 한 공백 두 칸입니다. 아무것도 업로드되지 않습니다. 갈 곳이 없기 때문입니다. 파서는 이미 열려 있는 그 탭에서 도는 수백 줄짜리 JavaScript입니다.
아래는 다른 어떤 대안에 설정 파일을 붙여 넣기 전에 알아 둘 값어치가 있는 부분입니다. 포매터가 무엇을 바꿔도 되는지, 그런데도 대부분이 무엇을 바꾸는지, 그리고 파일이 아예 파싱되지 않을 때 오류를 어떻게 읽는지.
한 줄이 들어가고 읽을 만한 것이 나옵니다. 그러기 위해 어디로도 아무것도 보내지 않았습니다.
정렬이란 무엇이고, 무엇이 아닌가
JSON에는 문법이 거의 없습니다. 객체, 배열, 문자열, 숫자, 그리고 true, false, null 세 낱말. 그 조각들 사이에서 공백은 아무 뜻도 없습니다. 이 파일과
누구의 코드에 있는 버그도 아닙니다. JavaScript 객체는 정수처럼 생긴 키를 숫자 오름차순으로 앞에 두도록 명세되어 있고, JSON.parse를 지나가는 모든 값은 JavaScript 객체가 됩니다. 그렇게 만든 포매터는 id나 포트 번호, 연도, HTTP 상태 코드로 키를 붙인 파일을 재배열하고, 한마디 말도 없이 그렇게 합니다.
그게 문제가 되는지는 파일에 달렸습니다. JSON 객체는 원칙적으로 순서가 없으니 기술적으로 망가진 것은 없습니다. 다만 저장소에 있는 판본과의 diff가 어마어마해지고, 리뷰는 읽을 수 없게 되며, 하류의 무언가가 그 파일을 순서대로 읽고 있었다면 동작이 달라집니다.
숫자의 자릿수
JSON은 숫자가 얼마나 커도 되는지 말하지 않지만 JavaScript는 말합니다. 모든 숫자가 배정밀도 수입니다. 그래서 배정밀도로 파싱했다가 도로 찍어 내는 포매터는 배정밀도가 담지 못하는 것을 잃습니다.
트위터 id나 스노플레이크 id, 은행 참조 번호 같은 스물한 자리 id가 다른 숫자로 돌아오고, 배정밀도로 담기에 너무 큰 값은 null이 되어 돌아옵니다. 두 파일 다 여전히 파싱되지만, 어느 쪽도 처음에 넣은 그 파일이 아닙니다.
빠져나오는 길은 숫자를 아예 파싱하지 않는 것입니다. 포매터는 문서를 배치하기 위해 숫자가 어디서 시작하고 어디서 끝나는지만 알면 되지 그 값은 필요 없습니다. 그러니 안전한 방법은 적힌 그대로 자릿수를 옮기는 것이고, 여기 도구가 하는 일이 그것입니다.
중복된 키
{"a": 1, "a": 2}는 올바른 JSON이고, 표준은 둘 중 어느 쪽이 이기는지 말하기를 거부합니다. 실제로 파서마다 다릅니다. 대부분은 마지막 것을 남기고, 어떤 것은 첫 번째를 남기며, 몇몇은 문서를 거부합니다. 조용히 하나만 내보내는 포매터는 대신 그 결정을 내려 버린 것이고, 훨씬 쓸모 있는 사실을 숨긴 것입니다. 둘이 있었다는 사실 말이죠. 그건 거의 언제나 파일의 실수이고, 눈으로 봐야 하는 실수입니다.
파일이 파싱되지 않을 때
실패하는 JSON은 대개 별난 것이 아닙니다. 여섯 가지쯤 중 하나이고, 오류가 어디인지를 찾아갈 수 있는 말로 알려 준다면 어느 것인지도 말해 줍니다. position 4193 같은 오프셋은 그렇지 않고, 줄과 칸은 그렇습니다.
끝에 붙은 쉼표.{"a": 1,}는 JavaScript 에서는 되고 JSON에서는 안 됩니다. 가장 흔한 단일 원인이고, 대개 목록의 마지막 항목을 지우면서 남습니다.
작은따옴표.{'a': 1}는 JavaScript 객체 리터럴이지 JSON이 아닙니다. 문자열도 키도 큰따옴표를 쓰고, 키에는 언제나 따옴표가 붙습니다.
따옴표 없는 키.{a: 1}. 같은 실수의 반대 방향이고, 대개 파일이 아니라 코드에서 무언가를 붙여 넣다가 생깁니다.
주석.// 이런 것도 JSON이 아닙니다. 그건 VS Code 설정과 tsconfig.json이 쓰는 JSONC이고, 다른 데서는 파싱되지 않습니다. 주석이 꼭 남아야 한다면 관례는 키로 넣는 것입니다. "_comment": "..."
문자열 안의 진짜 줄바꿈이나 탭.\n과 \t로 적어야 합니다. 셸 명령이나 인증서를 손으로 값에 붙여 넣을 때 보통 여기서 어긋납니다.
JSON이 허용하지 않는 숫자. 앞에 붙은 0 (01), 홀로 선 소수점(.5), NaN, Infinity, +1. 사람들이 쓰는 것들이고 그중 어느 것도 JSON이 아닙니다.
오류가 아닌데 오류처럼 보이는 것이 하나 있습니다. 바이트 순서 표시로 시작하는 파일입니다. 대부분의 편집기에서 보이지 않고, 공백도 아니며, 문서의 맨 첫 글자를 예상 밖의 것으로 만듭니다. 멀쩡해 보이는 파일에서 오류가 1행 1열에 있다면 그것입니다.
읽히지 않을 때는 어디가 문제인지 메시지가 말해 줍니다. 남는 쉼표가 가장 흔한 원인이고 눈으로는 가장 찾기 어려운 원인입니다.
눌러 담기, 그리고 대개 얼마나 적게 얻는지
공백을 짜내는 것은 같은 작업의 반대 방향이고, 그것으로 무엇을 얻는지에 대해서는 현실적일 만합니다. 공백은 반복이 아주 심하고, 서버에서 독자까지 가는 길목의 모든 것이 이미 gzip이나 Brotli로 응답을 압축하는데, 그것들이 바로 그런 종류의 반복에 아주 능합니다.
그래서 눌러 담은 JSON은 파일로는 흔히 30% 작지만 회선에서는 몇 퍼센트만 작습니다. 값어치를 하는 자리는 앞에 압축이 없는 곳들입니다. 데이터베이스 열에 담긴 값, 로그 한 줄의 필드, QR 코드 안의 페이로드, 또는 헤더에 Base64로 넣으려는 문서 같은 것들이죠.
치르는 것은 읽기 쉬움이고, 파일이 저장소에 커밋되어 있다면 diff까지 치릅니다 한 줄짜리 파일은 안에서 무엇이 바뀌든 통째로 바뀌니까요. 편집기로 들어가는 길이 아니라 나가는 길에 눌러 담으세요.
키 정렬, 그리고 하지 말아야 할 때
모든 객체의 키를 정렬하는 것은 기본으로 적용되지 않고 선택 항목으로 제시 됩니다. 파일을 실제로 바꾸는 일이고, 그 값어치가 이어서 하려는 일에 전적으로 달렸기 때문입니다.
두 환경의 설정이나 변경 전후의 API 응답처럼, 같은 말을 해야 하는 두 문서를 비교할 때 도움이 됩니다. 그중 하나가 키를 다른 순서로 늘어놓고 있을 때요. 둘 다 먼저 정렬하면 전부의 diff가 실제로 다른 두 줄의 diff가 됩니다.
순서가 무언가를 하고 있었다면 해가 됩니다. package.json에는 무엇이 먼저 오는지에 대한 관례가 있고, 손으로 쓴 설정 파일은 관련된 항목을 묶어 두는 경우가 많으며, 도구로 키를 정렬해 커밋한 파일은 어마어마하고 의미 없는 커밋 하나를 만들어 냅니다. 원본이 아니라 사본을 정렬하세요.
알아 둘 만한 세부가 하나 있습니다. 여기 정렬은 코드 포인트가 아니라 키가 읽히는 대로 이루어져서, item2가 item10 뒤가 아니라 앞에 옵니다. 코드 포인트로 정렬하면 item10이 1로 시작하는 것들 사이에 끼는데, 기술적으로는 맞고 읽는 사람에게는 쓸모가 없습니다.
JSON 파일 두 개 비교하기
믿을 만한 방법은 둘 다 같은 방식으로 먼저 정렬하는 것입니다. 같은 말을 하는 두 문서도 하나는 눌러 담겨 있고 다른 하나는 아니라면 모든 줄이 다를 수 있고, 어떤 diff도 그것을 꿰뚫어 보지 못합니다.
그러니 첫 번째를 정렬하고, 두 번째를 정렬하고, 두 결과를 비교하세요. 여기서는 세 단계가 모두 같은 페이지에 있습니다. 비교 탭이 정확히 이 이유로 정렬과 상자를 함께 쓰거든요. 둘이 키를 서로 다른 순서로 늘어놓고 있기까지 하다면, 정렬하는 김에 둘 다 키까지 정렬해 보세요. 비교가 찾고 있던 그 차이 하나로 접힙니다.
아무도 페이지에 적지 않는 부분
JSON 포매터를 검색하면 상자가 놓인 사이트를 수십 개 만나게 됩니다. 그 상자에 붙여 넣는 것이 곧 업로드입니다. 클립보드에 있던 것이 무엇이든 고객 주소가 담긴 API 응답이든, 접속 문자열이 담긴 설정 파일이든, 디버깅하던 토큰이든, 내가 통제하지 않는 기기로 전송된 것입니다. 이제 그건 그쪽의 로그 파일이고 오류 보고서이고 백업입니다.
악의에 대한 가정이 아닙니다. 더없이 선의로 운영되는 사이트도 접속 로그를 남기고, 분석을 돌리고, 호스팅 업체를 둡니다. 가장 안전한 데이터는 애초에 떠나지 않은 데이터이고, 전부가 문자열 조작인 작업에서 그것이 떠나야 할 이유는 하나도 없습니다.
확인 두 가지입니다. 이 사이트뿐 아니라 같은 주장을 하는 어떤 사이트에도 통합니다.
개발자 도구의 '네트워크' 탭을 켜 놓고 무언가를 정렬해 보세요. 텍스트가 전송되고 있다면 그걸 실은 요청이 있습니다. 그와 동시에 참일 수 있는 다른 이야기는 없습니다.
인터넷을 끊고 다시 해 보세요. 브라우저에서 일하는 도구는 아무 영향도 받지 않습니다. 텍스트를 어딘가로 보내는 도구는 즉시, 완전히 멈추고요.
같은 페이지가 XML과 HTML, CSS, YAML을 읽고, JSON과 그중 첫 번째·마지막 사이를 변환합니다. 위에서 이어 올 만한 것이 둘 있습니다. 옷만 다를 뿐 같은 이야기이기 때문입니다.
YAML을 JSON으로 바꾸면 주석을 잃습니다. JSON에는 그것을 넣을 자리가 없기 때문입니다. "같은 노드를 두 번"이라고 말하는 YAML의 방식인 앵커와 별칭도 표현할 수 없어서, 여기서는 짐작하는 대신 거부합니다.
no는 문자열입니다. YAML 1.1에서는 yes, no, on, off가 불리언이었고, 노르웨이가 든 국가 코드 목록이 false를 달고 돌아오곤 했던 이유입니다. YAML 1.2가 그것을 걷어 냈고 이 도구도 그렇습니다. 다만 그 낱말들은 여전히 따옴표를 씌워 씁니다. 다음에 그 파일을 여는 것이 1.1 리더일 수 있으니까요.
