개발 도구를 연결하기 전에 입력 형식부터 구분하기

Base64, URL 인코딩, JSON 정리, 정규식은 모두 텍스트를 다루지만 바꾸는 대상이 다릅니다. 서버 응답이 읽히지 않는다고 여러 도구를 차례로 적용하면 원래 데이터가 무엇이었는지 놓치기 쉽습니다. 이 글은 win-j.com에 추가한 개발 도구를 작은 입력으로 비교하고, 결과를 다음 단계로 넘길 때 확인할 조건을 정리한 기록입니다.

Base64는 바이트를 문자열로 표현하는 방식

Base64 인코더·디코더에 안녕을 입력하면 일반 Base64 결과는 7JWI64WV입니다. 현재 인코딩은 입력 문자열을 UTF-8 바이트로 바꾼 다음 Base64로 표현합니다. 다시 디코딩하면 안녕으로 돌아옵니다.

원문: 안녕
Base64: 7JWI64WV
복원: 안녕

Base64URL 옵션은 일반 Base64의 +, /를 -, _로 바꾸고 뒤쪽 =를 생략합니다. 예를 들어 a는 일반 모드에서 YQ==, URL 안전 모드에서는 YQ입니다. 송신 쪽과 수신 쪽이 어떤 형식을 기대하는지 맞춰야 합니다.

이 도구의 결과는 암호문이 아닙니다. 비밀번호나 인증 토큰을 Base64로 바꾸었다고 비밀값이 보호되는 것은 아닙니다. 또한 디코딩 결과는 UTF-8 텍스트로 표시하므로 이미지 같은 임의의 바이너리 데이터를 파일로 복원하는 용도와 구분합니다. UTF-8로 해석할 수 없는 바이트는 대체 문자로 표시될 수 있습니다.

URL 전체와 쿼리 값 하나를 다르게 처리

URL 인코더·디코더에는 전체 URL 처리 옵션이 있습니다. 검색어처럼 URL 안에 들어갈 값 하나를 인코딩하는 경우에는 전체 URL 옵션을 끕니다.

입력 값: A&B C
값 단위 인코딩: A%26B%20C

여기서 &를 그대로 붙이면 서버가 두 매개변수의 경계로 읽을 수 있습니다. 전체 URL 모드는 이런 구분 기호를 보존하기 때문에 값 하나를 보호하는 목적과 맞지 않습니다. encodeURIComponent의 처리 범위는 MDN 설명에서도 확인할 수 있습니다.

디코딩의 '+를 공백으로' 옵션도 입력 출처에 따라 선택합니다. A+B는 옵션을 끄면 A+B, 켜면 A B가 됩니다. 원래 더하기 기호가 들어 있던 값을 공백으로 바꾸지 않도록 요청을 만든 쪽의 인코딩 규칙을 확인합니다. 이미 인코딩한 문자열을 다시 인코딩하면 %까지 %25로 변하므로 결과가 두 번 처리되지 않았는지도 살펴봅니다.

JSON 정리는 데이터 검증 전체를 대신하지 않는다

JSON Pretty는 JSON을 파싱하고 들여쓰기나 압축 형식으로 출력합니다. 다음 입력은 JSON 문법에 맞습니다.

{"code":"0012","active":true,"count":3}

code는 문자열, active는 불리언, count는 숫자입니다. 키를 작은따옴표로 감싸거나 마지막 속성 뒤에 쉼표를 붙인 입력은 일반 JSON이 아닙니다. 오류가 나면 먼저 해당 위치와 인접한 따옴표·쉼표를 확인합니다.

문법이 맞아도 API가 필요한 필드, 값의 범위, 접근 권한을 만족하는지는 별도 문제입니다. 같은 키가 두 번 있는 데이터도 원문과 파싱 결과가 다를 수 있고, 큰 정수는 JavaScript 숫자로 읽는 과정에서 정밀도가 달라질 수 있습니다. 식별번호는 문자열로 전달할 수 있는지 원래 데이터 규격을 먼저 확인합니다. JSON.parse 문서

정규식은 부분 일치와 전체 일치를 나누어 시험

Regex 테스트기에서 패턴 칸에 \d{3}을 넣고 본문에 A123B를 입력하면 가운데 123이 일치합니다. 같은 본문에 ^\d{3}$를 적용하면 전체가 세 자리 숫자가 아니므로 일치하지 않습니다. 플래그를 끈 기본 조건에서 먼저 비교하고, 여러 줄 모드나 전체 검색 옵션을 하나씩 바꿔 차이를 확인합니다.

패턴 앞뒤의 /는 JavaScript 코드에서 정규식 리터럴을 표시하는 구분자입니다. 이 도구의 패턴 칸에는 필요한 패턴 본문을 넣고 플래그는 화면의 옵션으로 선택합니다. 이메일처럼 복잡한 규칙은 예제 하나가 맞았다는 이유만으로 실제 서비스 검증을 완료했다고 판단하지 않습니다.

JWT를 읽은 결과와 검증 결과 구분

JWT 디코더로 헤더와 페이로드를 읽어도 서명의 신뢰성이 확인된 것은 아닙니다. 실제 서비스에서는 발급자·대상·유효 기간과 서명 검증이 필요합니다. 디버깅 예제에는 실제 로그인 토큰 대신 가짜 데이터를 사용합니다.

2026년 9월 22일 구현을 기준으로, 각 도구의 입출력 규칙을 서로 섞지 않도록 정리했습니다. 원문 → 필요한 변환 한 단계 → 예상값 대조 순서로 진행하면 어느 단계에서 값이 바뀌었는지 찾기 쉽습니다.