개발자를 위한 모음

개발자가 자주 쓰는 변환기·검사기·파일 도구를 묶었어요. 전부 브라우저에서 처리해 코드나 데이터를 외부로 보내지 않아요.

5개 도구

  • 개발자 도구 — JSON·Base64·URL·정규식·타임스탬프·JWT·Cron·CIDR·Diff.
  • 서버 부하 시뮬레이터 — 서버 스펙·런타임·DB 구성으로 최대 TPS와 병목을 예측해요.
  • 이미지 압축 — 업로드 없이 브라우저에서 이미지를 압축·리사이즈해요.
  • PDF 병합 — 업로드 없이 브라우저에서 PDF 여러 개를 하나로 합쳐요.
  • 이미지 PDF 변환 — 사진 여러 장을 업로드 없이 한 PDF로 만들어요.

자세히 알아보기

브라우저 안에서 끝난다는 게 왜 중요한가

여기 묶인 도구는 전부 파일도 문자열도 서버로 보내지 않아요. JSON 정렬, Base64 디코딩, JWT 뜯어보기, 이미지 압축, PDF 병합이 전부 탭 안에서 일어나요.

이게 취향 문제가 아닌 이유는 개발 중에 다루는 문자열의 정체 때문이에요. 디코딩해 보려는 그 JWT 에는 대개 실제 사용자 식별자와 서명이 들어 있고, 정렬해 보려는 그 JSON 응답에는 운영 데이터가 들어 있어요. 온라인 «포매터» 에 붙여 넣는 순간 그건 제3자 서버에 남는 로그예요.

사내 규정이 외부 도구 사용을 막는 곳이 많은데, 막는 대상은 «도구» 가 아니라 데이터 전송이에요. 전송이 없으면 그 조건은 자동으로 충족돼요. 네트워크 탭을 열어 두고 써 보면 요청이 안 나가는 걸 그대로 확인할 수 있어요.

장애 대응 중에 손이 가는 순서

로그에 찍힌 정체불명의 문자열부터 풀어요. 눈으로 봐서 `eyJ` 로 시작하면 JWT 고, 끝에 `=` 가 붙어 있으면 Base64 예요. JWT 는 암호화가 아니라 서명이라 페이로드는 그냥 읽혀요 — 만료 시각(`exp`)과 발급 시각(`iat`)이 서버 시계와 맞는지 보는 게 첫 확인이에요.

그다음이 타임스탬프예요. `1970` 근처의 날짜가 나오면 초 단위 값을 밀리초로 읽었거나 그 반대예요. 로그의 시각이 UTC 인지 로컬인지 헷갈릴 때도 여기서 변환해 보면 한 번에 갈려요.

설정 파일에서 어긋난 부분을 찾을 땐 Diff 를 써요. 배포 전후 설정을 나란히 두면 «아무것도 안 바꿨는데» 가 사실이 아니었다는 게 대개 여기서 드러나요.

Cron 표현식은 사람이 가장 자주 틀리는 축이 요일과 «매 N분» 이에요. `*/5` 와 `5` 는 완전히 다른 스케줄이고, 이 차이가 배치 잡을 288배로 돌리거나 하루 한 번만 돌게 만들어요.

용량 산정은 감이 아니라 대기행렬로

«이 서버로 몇 명까지 받을 수 있나» 는 스펙표를 본다고 나오지 않아요. 실제로 필요한 건 리틀의 법칙이에요 — 동시 처리 수 = 도착률 × 평균 응답시간. 서버 부하 시뮬레이터가 계산하는 게 이거예요.

여기서 자주 놓치는 게 병목의 위치예요. CPU 코어를 두 배로 늘려도 커넥션 풀이 20개면 최대 처리량은 커넥션 풀에서 잘려요. 앞단을 아무리 키워도 가장 좁은 구간이 전체 처리량을 정해요.

응답시간이 늘어나는 구간도 선형이 아니에요. 사용률이 70% 를 넘어가면 대기 시간이 급격히 치솟아요. 그래서 «평상시 사용률 50%» 같은 여유가 낭비가 아니라 지연시간을 사는 값이에요.

이 계산은 정확한 예측이 아니라 자릿수 확인이에요. 필요한 서버가 2대인지 20대인지를 회의 전에 알고 들어가는 용도예요. 실제 값은 부하 테스트로 재야 해요.

이미지와 PDF 를 굳이 여기서 처리하는 이유

스크린샷을 이슈에 붙이려는데 8MB 라 거절당하는 상황, PDF 세 장을 하나로 합쳐 제출해야 하는 상황은 개발자에게도 자주 와요. 그때마다 ImageMagick 을 설치하거나 온라인 변환 사이트에 파일을 올릴 필요는 없어요.

이미지 압축은 두 축을 같이 봐요 — 해상도(리사이즈)와 품질(재인코딩) 이에요. 4000px 짜리를 품질만 낮추는 것보다 1600px 로 줄이는 쪽이 화질 손해 대비 용량 감소가 훨씬 커요. 문서용 스크린샷은 대개 긴 변 1600px 이면 충분해요.

PDF 병합과 이미지→PDF 변환도 같은 자리에서 끝나요. 계약서·영수증처럼 올리면 안 되는 문서가 정확히 이 두 작업의 주된 대상이라, 업로드가 없다는 점이 여기서 제일 크게 작동해요.

붙여 넣기 전에 한 번 볼 것

전송이 없어도 화면은 남아요. 화면 공유 중이거나 옆자리에 사람이 있을 때 운영 토큰을 디코딩하면 그 자체가 노출이에요.

디코딩한 결과를 그대로 이슈나 채팅에 붙여 넣는 것도 흔한 사고예요. JWT 페이로드에는 사용자 id·이메일·권한이 그대로 들어 있는 경우가 많아요.

정규식을 테스트할 때 입력 데이터를 실제 운영 데이터로 쓰지 마세요. 패턴을 맞추는 데 필요한 건 형태이지 진짜 값이 아니에요.

이 묶음이 대신하지 않는 것

여기 도구들은 확인용이에요. JWT 뜯어보기는 서명 검증이 아니고, 검증은 서버가 키로 해야 해요. 페이로드가 읽힌다는 것과 그 토큰이 유효하다는 것은 다른 이야기예요.

부하 시뮬레이터는 실제 부하 테스트를 대신하지 않아요. GC 특성, 커널 파라미터, 네트워크 지연, 캐시 적중률 같은 것들이 실측에서 결과를 바꿔요.

이미지 압축은 되돌릴 수 없어요(손실 압축). 원본은 따로 두고 결과물만 배포하세요.