가끔 쓰고 싶은 웹 서비스 5가지

2026년 8월 · 브라우저에서만 돌아가는 유틸리티 제작기

왜 이런 도구를 직접 만들었나?

돈을 낼 만큼은 아닌데, 없으면 곤란한 작업들이 있다. 그게 이번 도구 5종의 출발점이다.

서류를 넣으려는데 “5MB 이하”에 막힌다. 1년에 두세 번 있는 일이다. 이걸 위해 월 구독을 결제하는 사람은 없다.
그래서 검색해서 나오는 무료 사이트를 쓴다. 문제는 그 무료 사이트들 대부분이 파일을 자기네 서버로 올린 다음 처리해서 돌려준다는 점이다. 광고 몇 번 보고 결과를 받는 대가로, 신분증 사진이나 계약서를 남의 서버에 넘기고 있는 셈이다.

개인 파일이면 그러려니 할 수도 있다. 그런데 회사 자료라면 이야기가 달라진다. 나는 이 지점이 계속 걸렸다.
기술적으로 서버가 꼭 필요한 작업이 아니기 때문이다.
이미지 압축도, zip 파일명 디코딩도, PDF 합치기도 요즘 브라우저 안에서 전부 된다.
서버를 거치는 이유는 기술이 아니라 사업 모델이다. 파일을 받아야 트래픽이 잡히고, 그래야 유료 전환을 걸 수 있으니까.

그럼 서버를 안 쓰는 쪽을 만들면 되겠다 싶었다. 광고는 붙이되 파일은 안 받는 방식으로.

무엇을 만들었나 — 도구 5종

전부 lab.n8n-diy.com 아래에 있다. 기존에 있던 HWP→Markdown 변환기, AI 타로와 같은 자리다.

사진 용량 줄이기는 품질 슬라이더 대신 목표 용량을 받는다.
“300KB 이하”라고 입력하면 품질을 바꿔가며 실제로 여러 번 압축해 보고, 그 안에 들어가는 가장 좋은 품질을 찾아낸다.
아이폰 HEIC를 그대로 올려도 되고, 세로 사진이 눕는 문제도 회전 정보를 읽어 잡는다. EXIF 위치정보는 기본으로 지운다. 중고거래에 사진 올렸다가 집 위치가 같이 나가는 걸 막으려는 것이다.

압축파일 한글 깨짐 복구는 다섯 중 기술적으로 제일 까다로웠다.
윈도우 압축 프로그램은 한글 파일명을 CP949로 저장하는 경우가 많은데, 맥은 UTF-8로 읽으려 한다.
같은 바이트를 다르게 해석하니 글자가 깨진다. 복구한 결과는 표로 먼저 보여준다.
깨진 이름과 되살린 이름을 나란히 놓고 확인한 뒤에 받으라는 뜻이다. 일본어 zip을 위한 Shift_JIS도 골라 쓸 수 있다.

글자수 세기는 제일 단순하지만 실용성은 높다.
공백 포함·제외를 같이 보여주고, 목표 글자수를 넣으면 초과분을 본문에서 색으로 표시한다.
어디를 줄일지 눈으로 찾으라는 것이다. UTF-8·EUC-KR 바이트 수와 원고지 매수도 같은 화면에 있다.
작성 중인 글은 브라우저에 자동 보관돼서 실수로 창을 닫아도 남아 있다.

이미지 이어붙이기는 대화 캡처나 상세페이지 조각을 한 장으로 만든다.
폭이 제각각인 캡처를 기준에 맞춰 정리해 주고, 간격과 배경색도 조절된다.
모바일에서는 드래그 대신 위·아래 버튼으로 순서를 바꾼다. 드래그만 넣으면 폰에서 못 쓴다.

사진·PDF 묶기는 계획서보다 범위가 넓어진 케이스다.
원래는 “사진 여러 장 → PDF”만 만들 생각이었는데, 실제로 써 보니 손에 있는 게 PDF 몇 개랑 사진 몇 장이 섞여 있는 상황이 훨씬 많았다. 그래서 PDF 합치기까지 넣었다.
PDF를 합칠 때는 페이지를 이미지로 변환하지 않고 원본 페이지를 그대로 옮긴다.
글자가 뭉개지지 않고 인쇄해도 선명하다. 제출처 용량 제한도 입력해서 맞출 수 있다.

왜 서버를 안 쓰기로 했나?

이건 성능이나 비용 문제가 아니라 이 서비스를 제공하기로 결정한 이유가 부담없이 사용할 수 있는 서비스를 구현하는 것이었기 때문이다.
계획 단계에서 아예 못을 박아 뒀다. 서버 함수도 없고 파일 업로드도 없다라고.

덕분에 따라온 이점이 몇 가지 있다.
파일 크기 제한을 걸 이유가 없고, 트래픽이 몰려도 서버 비용이 오르지 않는다.
개인정보 보관 문제도 애초에 생기지 않는다. 저장할 서버가 없으니까.

대신 브라우저가 감당할 수 있는 만큼만 된다는 제약이 붙는다.
그래서 무거운 라이브러리는 처음부터 안 불러온다.
HEIC 변환기, PDF 처리기, 압축 라이브러리는 사용자가 파일을 넣는 순간에 동적으로 불러온다.
글자수만 세러 온 사람이 PDF 라이브러리를 내려받을 이유는 없다.

만들면서 제일 막혔던 세 가지는?

겉보기엔 간단한 도구인데 안에서는 성가신 지점들이 있었다. 세 가지만 꼽는다.

1. 아이폰 사파리가 조용히 빈 이미지를 뱉는 문제

이게 제일 골치 아팠다. 브라우저는 한 번에 그릴 수 있는 이미지 크기에 상한이 있다. iOS 사파리는 특히 낮다.
문제는 이 한계를 넘겼을 때 에러가 안 난다는 것이다. 그냥 아무것도 없는 빈 이미지가 저장된다. 세로로 긴 캡처 열 장쯤 이어붙이면 쉽게 도달한다.

그래서 그리기 전에 크기를 미리 계산해서 막도록 했다. 한계를 넘을 것 같으면 알려주고, 전체를 줄여서 한 장으로 만들지 원래 크기로 여러 장에 나눌지 고르게 한다. 조용히 실패하게 두는 게 최악이다. 사용자는 뭐가 잘못됐는지도 모른 채 시간만 쓰게 된다.

2. zip 라이브러리를 그냥 쓰면 안 되는 이유

한글 파일명 복구는 흔한 zip 라이브러리의 기본 API로는 안 된다. 그 API들이 파일명을 UTF-8로 강제 디코딩해 버려서 원본 바이트가 이미 사라진 상태로 넘어오기 때문이다. 깨진 글자를 되돌리려면 깨지기 전 바이트가 필요한데, 그게 없다.

그래서 zip 파일 구조를 직접 파고들었다. 파일 끝의 중앙 디렉토리를 찾아 엔트리를 순회하면서 파일명 원본 바이트와 플래그를 직접 읽는다. 플래그에 UTF-8 표시가 없으면 CP949로 해석한다. 디코딩 자체는 브라우저에 내장된 기능이라 별도 라이브러리도 필요 없었다.

3. 목표 용량을 어떻게 맞출 것인가

“300KB 이하로”는 계산으로 딱 나오는 값이 아니다. 사진마다 압축률이 다르기 때문이다. 그래서 품질을 바꿔가며 실제로 압축해 보고 목표 안에 들어오는 가장 좋은 품질을 찾는 방식을 썼다. 범위를 반씩 좁혀 들어가서 몇 번 안에 끝난다.

이 로직은 한 번 만들어서 세 도구가 같이 쓴다. 사진 압축, 이어붙이기 결과 저장, PDF 용량 맞추기가 전부 같은 코드를 부른다. 도구를 따로따로 만들었으면 세 번 만들었을 것이다.

왜 도메인 하나 아래 다섯 경로인가?

도구 다섯 개를 각각 별도 사이트로 만들 수도 있었는데 그렇게 안했다.
이유는 다음과 같다. 뭐 그냥 귀찮아서!? ㅋ

• 검색엔진은 도메인 단위로 신뢰를 쌓는다. 쪼개면 기존 HWP 변환기가 쌓아 둔 몫을 새 도구가 못 물려받는다.
• 도구끼리 이어지는 흐름이 있다. 사진 압축 → 이어붙이기 → PDF 묶기는 실제로 연속된 작업이다. 각 페이지 하단에 나머지 도구 링크를 넣었다.
• 공통 코드를 다섯 번 복제하지 않아도 된다. 이미지 디코딩, 압축, 다운로드는 전부 공유한다.
• 운영이 5분의 1이다. DNS, 빌드, 배포, 애널리틱스를 한 번만 설정한다.

다만 신규 도구는 저장소를 분리하고 프록시로 붙였다.
기존 사이트는 프레임워크가 섞여 있는 상태라, 여기에 새 빌드를 얹으면 의존성이 엉킨다.
분리해 두면 신규 쪽 배포가 실패해도 기존 트래픽이 멀쩡하다.
이번 작업에서 제일 우선한 조건이 그거였다. 기존 URL이 단 한 순간도 깨지지 않을 것.

배포하고 나서도 한동안은 아무도 못 찾았을 것이다. 허브 페이지에 링크가 없어서 크롤러가 새 페이지에 닿을 길이 없었고, sitemap에도 빠져 있었으니. 도구를 만드는 것과 사람들이 도구에 도착하는 것은 별개의 작업이라고 본다.
지금은 허브를 문서 도구·이미지 도구·AI 서비스 카테고리로 나눠 정리해 뒀다.

언제 쓰면 되나?

자주 묻는 질문

마무리

거창한 서비스는 아니다. 1년에 몇 번 쓸까 말까 한 기능들이다. 그런데 딱 그때 없으면 매우 귀찮아진다.

이런 건 구독할 만큼은 아니고, 그렇다고 파일을 남의 서버에 올리기도 찜찜하다.
그 사이 어딘가가 비어 있다고 봤고, 그래서 만들었다. 필요할 때 그냥 열어서 쓰면 된다.
북마크에 하나 넣어 두면 언젠가 쓸 일이 온다.

써 보고 안 되는 게 있거나 이런 것도 있으면 좋겠다 싶은 게 있으면 댓글로 남겨 달라. 다음에 만들 것을 정하는 기준이 그거다.