도구스개발

JSON Patch 적용기

RFC 6902 JSON Patch 문서(add·remove·replace·move·copy·test)를 원본 JSON에 순서대로 적용해 결과를 보여줍니다. 중간 연산이 실패하면 몇 번째 연산에서 왜 실패했는지 알려줍니다.

원본 JSON

JSON Patch 배열

적용 완료

연산 2개

아래가 결과 문서입니다

결과 JSON

{
  "name": "도구스",
  "tools": 1680,
  "categories": [
    "money",
    "date",
    "unit"
  ]
}
remove·replace·test는 대상이 이미 있어야 합니다. RFC 6902가 그렇게 정해 뒀습니다. 하나라도 실패하면 그 앞 연산까지 적용된 중간 상태가 아니라, 패치 전체가 실패한 것으로 봅니다.

사용 방법

  1. 1원본 JSON 문서를 붙여넣습니다.
  2. 2JSON Patch 배열(op·path·value 등)을 붙여넣습니다.
  3. 3연산이 순서대로 적용된 결과 문서가 나옵니다.
  4. 4중간에 실패하면 몇 번째 연산에서 왜 실패했는지 표시됩니다.

자주 묻는 질문

RFC 6902가 정의한, JSON 문서를 부분적으로 수정하는 표준 형식입니다. {"op": "add", "path": "/a/b", "value": 1} 처럼 연산을 배열로 나열하면 순서대로 적용됩니다. HTTP PATCH 요청에서 전체 문서를 다시 보내지 않고 바뀐 부분만 보낼 때 씁니다.

RFC 6902가 정의한 6가지 전부입니다 — add(추가), remove(삭제), replace(교체), move(이동), copy(복사), test(검사, 값이 다르면 패치 전체를 실패시킵니다). path·from 은 RFC 6901 JSON Pointer 표기("/a/b/0")를 쓰고, 배열 맨 끝은 "/a/-"로 가리킵니다.

패치 전체가 실패합니다. RFC 6902 3절은 이 세 연산의 대상이 반드시 이미 존재해야 한다고 정합니다. 반대로 add는 없던 자리에 새로 만드는 연산이라 부모 컨테이너만 있으면 되고, 같은 이름이 이미 있으면 덮어씁니다.

아니요. 몇 번째 연산에서 실패했는지는 알려주지만, 결과 문서는 아예 나오지 않습니다. 패치는 전부 적용되거나 전부 취소되는 단위로 다뤄야 중간 상태가 남지 않습니다.

알아두면 좋은 점

  • 별도의 법령·요율 검증이 필요 없는 순수 스펙 구현입니다. RFC 6902 부록 A의 공식 예제로 동작을 검증했습니다.
  • 숫자 비교는 JSON 값 기준입니다(1과 1.0은 파싱되면 같은 숫자라 test에서 같다고 봅니다).

함께 보면 좋은 도구

JSON 비교두 JSON을 키 단위로 재귀 비교해 추가·삭제·값변경·타입변경을 찾아냅니다.JSON 포맷JSON을 보기 좋게 정렬하거나 한 줄로 압축합니다.JSON 스키마JSON 예시를 붙여넣으면 JSON Schema(draft 2020-12)를 만들어 줍니다.JSON Merge PatchRFC 7396 JSON Merge Patch를 원본 JSON에 적용해 결과를 보여줍니다.gitignore 판정.gitignore 규칙과 경로를 넣으면 그 파일이 무시되는지, 어느 줄이 마지막으로 이겼는지 알려줍니다.

마지막 검증: 2026년 9월 10일 · 결과는 참고용 추정치입니다.