JSON·Base64·JWT·해시를 혼동하지 않는 법
겉보기에는 모두 긴 문자열이지만 인코딩, 토큰 해석, 해시는 목적과 보안 성질이 다릅니다. 실제 비밀값을 넣기 전에 차이를 확인하세요.
작성: Yubook · 최종 검토: 2026-09-29
표현을 바꾸는 것과 보호하는 것은 다릅니다
Base64는 텍스트나 바이트를 전송하기 쉬운 문자로 표현하는 인코딩입니다. 누구나 다시 디코딩할 수 있으므로 암호화가 아닙니다. 이메일 주소나 비밀번호를 Base64로 바꿔 공개해도 보호되지 않습니다.
SHA-256 해시는 입력에서 일정한 길이의 값을 계산하는 단방향 함수입니다. 원문을 바로 복원하는 디코더는 없지만, 짧고 흔한 비밀번호는 후보를 반복 계산해 추측할 수 있습니다. 단순 SHA-256 결과만으로 비밀번호 저장 체계를 만들면 안 됩니다. 이 도구는 파일 무결성 비교나 예시 계산에 적합합니다.
JWT 디코딩은 서명 검증이 아닙니다
JWT의 헤더와 페이로드는 Base64URL 형식이라 비밀키 없이도 읽을 수 있습니다. 디코더가 내용을 보여 준다고 토큰이 유효하거나 안전하다는 뜻은 아닙니다. 서명 알고리즘, 키, 발급자, 대상, 만료 시각을 검증해야 인증 판단을 할 수 있습니다.
실제 서비스의 액세스 토큰은 계정 권한을 가질 수 있습니다. 디버깅할 때도 토큰 전체를 채팅, 이슈, 문의 메일에 붙이지 말고 필요한 필드만 가린 예시로 바꾸세요. 유북 도구는 브라우저에서 파싱하지만 화면 공유·클립보드 기록·브라우저 확장 프로그램 같은 주변 경로까지 통제하지는 못합니다.
JSON과 CSV 변환에서 사라질 수 있는 정보
JSON 정리는 공백과 줄바꿈을 바꾸지만 파싱 과정에서 중복 키는 마지막 값만 남을 수 있고, 매우 큰 정수는 자바스크립트 숫자 정밀도 범위를 벗어날 수 있습니다. CSV는 쉼표, 줄바꿈, 따옴표를 포함한 셀을 따옴표로 감싸야 하며 빈 열의 위치도 의미가 있습니다.
변환 전후의 레코드 수와 핵심 식별자를 비교하고, 원본을 덮어쓰지 마세요. 회계·고객 데이터처럼 손실 비용이 큰 자료는 일부 샘플로 먼저 확인한 뒤 전체를 처리합니다.
확인 목록
- Base64를 암호화로 오해하지 않기
- 실제 액세스 토큰·비밀번호 입력하지 않기
- JWT는 디코딩과 검증을 구분하기
- 큰 정수와 중복 JSON 키 확인하기
- 변환 결과의 행·열 개수를 원본과 대조하기
이 글은 유북 도구의 사용 범위와 일반적인 확인 절차를 설명합니다. 개별 거래의 세무·법률·노무 판단이나 금융상품 권유를 제공하지 않습니다.