개발하다 잠깐 필요한 변환·검사 도구를 모았어요. 전부 브라우저에서 돌아 사내 데이터를 외부 서비스에 붙여넣지 않아도 돼요.
JSON 을 예쁘게 정리하거나 JWT 를 열어 보려고 검색하면 도구가 수십 개 나와요. 문제는 대부분이 입력값을 서버로 보내서 처리한다는 점이에요. 그 JSON 에 고객 이메일이 들어 있고, 그 JWT 에 실제 세션 토큰이 들어 있다면, 붙여넣는 순간 그건 외부로 나간 거예요.
«어차피 만료된 토큰인데» 라고 넘기기 쉽지만, 사고 조사에서 문제가 되는 건 유출 여부가 아니라 어디까지 나갔는지 증명할 수 없다는 사실이에요.
이 카테고리의 도구는 전부 브라우저 안에서 돌아요. 확인 방법도 간단해요 — 개발자 도구 네트워크 탭을 열고 실행해 보세요. 요청이 없어요.
JSON 포맷터는 «예쁘게» 만 하는 게 아니라 파싱 오류의 위치를 알려 주는 게 실은 더 자주 쓰여요. 흔한 원인은 마지막 요소 뒤의 쉼표, 홑따옴표, 그리고 복사 과정에 섞여 들어간 보이지 않는 문자예요.
Base64 는 «암호화» 가 아니에요. 누구나 되돌릴 수 있는 인코딩이고, 비밀을 담는 용도가 아니라 바이너리를 텍스트 채널에 실어 나르는 용도예요. 그리고 URL 에 넣을 때는 `+` 와 `/` 가 문제를 일으켜서 URL-safe 변형(`-`, `_`)을 써야 해요.
URL 인코딩은 «어디를 인코딩하느냐» 가 핵심이에요. 경로 세그먼트와 쿼리 값에서 이스케이프해야 하는 문자가 다르고, 전체 URL 을 통째로 인코딩하면 `://` 까지 망가져요.
JWT 는 점으로 나뉜 세 부분(헤더·페이로드·서명)이고, 앞의 둘은 그냥 Base64URL 이에요. 즉 누구나 읽을 수 있어요. 토큰에 개인정보나 내부 식별자를 넣으면 그건 공개된 것과 같아요.
디코더가 하는 일은 그 두 부분을 읽어 주는 것뿐이에요. 서명 검증은 별개이고, 서명을 확인하지 않으면 «내용이 진짜인지» 는 아무것도 보증되지 않아요. `alg: none` 을 받아들이는 구현이 과거에 실제 취약점이었던 이유예요.
만료(`exp`)와 발급 시각(`iat`)은 유닉스 타임스탬프라 사람 눈에는 의미가 없어요. 타임스탬프 변환기를 같이 쓰면 «이 토큰이 언제 죽는지» 를 바로 볼 수 있어요.
정규식은 탐욕적(greedy) 수량자에서 가장 많이 어긋나요. `.*` 는 가능한 한 길게 먹기 때문에, `<.*>` 는 태그 하나가 아니라 첫 `<` 부터 마지막 `>` 까지를 잡아요. `.*?` 로 게으르게 바꾸는 게 첫 처방이에요.
Cron 표현식에서 흔한 함정은 요일과 일자를 동시에 지정하는 것이에요. 대부분의 구현에서 이 둘은 AND 가 아니라 OR 로 동작해서, 의도한 것보다 훨씬 자주 실행돼요. 그리고 서버의 시간대가 무엇인지 확인하지 않으면 «새벽 3시» 가 남의 시간대의 새벽 3시일 수 있어요.
CIDR 계산에서는 사용 가능한 호스트 수가 `2^(32−prefix)` 가 아니라 거기서 네트워크 주소와 브로드캐스트 주소 둘을 뺀 값이에요. /30 이 4개가 아니라 2개인 이유이고, /31 은 점대점 링크용 특례예요.
타임스탬프 변환은 초 단위와 밀리초 단위를 헷갈리는 게 사고의 대부분이에요. 10자리면 초, 13자리면 밀리초예요. 1000배 차이라 «1970년» 이나 «5만 년 후» 가 나오면 이걸 의심하세요.
텍스트 비교(diff) 는 줄 단위와 문자 단위 중 무엇을 볼지에 따라 결과가 완전히 달라요. 코드 리뷰에는 줄 단위가, 문장의 오타 찾기에는 문자 단위가 맞아요.
색상 변환은 HEX·RGB·HSL 을 오가는 건데, HSL 이 «조금 더 밝게» 같은 조정에 훨씬 편해요. 명도만 올리면 되니까요.
QR 생성은 오류 정정 레벨을 정할 수 있어요. 레벨을 올리면 코드가 조금 더 복잡해지는 대신 인쇄물이 더러워지거나 일부가 가려져도 읽혀요.
서버 용량 계산은 대기행렬 이론의 기본식인 Little's Law 위에 서 있어요 — 시스템 안에 있는 요청 수는 «도착률 × 체류 시간» 이에요. 여기서 필요한 동시 처리 수가 나와요.
직관과 다른 부분은 이용률이 100%에 가까워질수록 대기 시간이 급격히 폭발한다는 점이에요. 70%에서 80%로 올릴 때보다 90%에서 95%로 올릴 때 응답 시간이 훨씬 크게 나빠져요. 그래서 «CPU 여유가 아직 10% 남았다» 는 안전 신호가 아니에요.
이건 정상 상태 근사라, 순간적인 트래픽 급증이나 재시도 폭풍 같은 것은 모델에 들어 있지 않아요. 용량 계획의 출발점으로 쓰고 실제 부하 테스트로 검증하세요.
전부 브라우저에서 돌아 오프라인에서도 동작하고, 입력한 코드·토큰·설정값이 서버로 가지 않아요. 회원가입이 없어서 어떤 값도 계정에 묶이지 않아요.
반대로 브라우저 안이라는 제약도 있어요 — 매우 큰 파일은 메모리를 많이 쓰고, 실제 네트워크 요청이 필요한 검사(포트 스캔, TLS 인증서 체인 검증 등)는 할 수 없어요.