인코딩 하나 하려고 광고투성이 사이트에 들어가기 싫어서: anyTools를 만든 이유

개발 작업을 하던 중 설정 파일에 들어 있는 문자열 하나를 급히 Base64로 디코딩해 볼 일이 있었습니다. 검색창에 "base64 디코딩"을 입력하고 상단에 나온 사이트에 들어갔는데, 입력창을 찾기도 전에 화면 절반을 덮은 배너 광고와 가짜 다운로드 버튼이 먼저 눈에 들어왔습니다. 겨우 찾은 입력창에 문자열을 붙여 넣으려는 순간 손이 멈췄습니다. "이 문자열 안에 API 토큰이나 내부 접속 정보가 섞여 있으면 어떡하지? 이 사이트는 내가 붙여 넣은 값을 서버로 전송해서 로그에 남기지 않을까?" 결국 그날은 창을 닫고 터미널을 열어 직접 명령어를 입력했습니다.

이 글은 그런 반복되는 보안 우려와 사용성 불편을 해결하기 위해 anyTools(애니툴즈)라는 클라이언트 기반 웹 유틸리티 모음(30종)을 직접 설계하고 구축한 이야기입니다. 일상과 개발 업무에서 겪었던 일곱 가지 불편과, 이를 웹 표준 기술로 어떻게 풀었는지 정리해 보겠습니다.

불편 하나: 도구보다 광고가 먼저 보이는 화면

인코딩이나 JSON 포맷팅, 단위 변환 같은 작업은 대개 10초면 끝납니다. 그런데 그 10초를 위해 들어간 페이지에서 입력창이 광고 아래로 한참 밀려 있거나, 실행 버튼인 줄 알고 눌렀더니 외부 광고 페이지로 이동하는 경험은 누구나 한 번쯤 겪어보셨을 겁니다. 모바일 화면에서는 이런 불편이 더욱 치명적입니다.

anyTools를 설계할 때 가장 먼저 세운 원칙은 페이지에 진입하자마자 입력 영역과 실행 결과가 첫 화면(Above the fold)에 바로 보여야 한다는 것이었습니다. 불필요한 장식을 덜어내고 '붙여넣기 → 즉시 변환 → 복사'로 이어지는 핵심 동선이 한눈에 들어오도록 레이아웃을 통일했습니다.

불편 둘: 민감한 데이터와 문서를 외부 서버에 올려도 될까

온라인 유틸리티 사이트를 쓸 때 가장 신경 쓰이는 부분은 내가 입력한 텍스트나 업로드한 파일이 외부 서버로 전송되는지 알 수 없다는 점입니다. 실무에서 다루는 API 응답 JSON에는 고객 식별자나 내부 도메인 구조가 들어 있을 수 있고, 인코딩 문자열에는 JWT나 인증 키가 포함되기도 합니다. PDF 병합이나 HWP·오피스 문서 뷰어처럼 파일을 선택해야 하는 도구라면 보안 우려는 더욱 커집니다.

그래서 anyTools는 입력한 텍스트와 선택한 파일을 원격 서버로 업로드하지 않고, 100% 사용자의 웹 브라우저 내부(Client-Side) 메모리에서만 처리하는 아키텍처로 구현했습니다. Base64·URL 변환, JSON 포맷팅, 이미지 포맷 변환·압축, PDF 병합·분리, HWP/Office 문서 열람까지 모두 Web API(`FileReader`, `Canvas`, `WebAssembly`, `ArrayBuffer`)를 통해 현재 사용 중인 기기 안에서만 동작합니다. 브라우저 개발자 도구의 Network 탭을 열어보시면 파일 변환 중 외부 서버로 어떠한 데이터 전송도 발생하지 않는 것을 직접 확인하실 수 있습니다.

불편 셋: 작업마다 매번 다른 사이트를 검색해 찾아다니는 피로

하루 동안 개발과 문서 작업을 하며 쓰는 소소한 도구를 떠올려 보면 종류가 생각보다 많습니다. 오전에는 API 응답 JSON을 정렬하고, 점심에는 팀원들과 더치페이 금액을 계산하고, 오후에는 관공서에서 받은 HWP 첨부파일을 맥북에서 열어야 하고, 저녁에는 블로그에 올릴 스크린샷 용량을 줄여야 합니다. 그때마다 검색하고, 낯선 UI에 적응하는 과정이 불필요한 소모처럼 느껴졌습니다.

anyTools는 이렇게 자주 쓰는 도구를 한 도메인 안에 30종으로 통합하고 한국어·영어·일본어·중국어·프랑스어·러시아어 등 6개 국어를 지원하도록 구성했습니다.

• 개발자 도구 (4종): JSON 포매터·검증기, UTF-8 안전 Base64 변환기, URL 인코더/디코더, 암호학 난수 기반 비밀번호·UUID v4 생성기
• 문서·뷰어 (7종): HWP/HWPX 한글 뷰어, Word·Excel·PPT 오피스 뷰어, 오피스·이미지 PDF 변환기, PDF 병합·분리·회전, 문서 스캐너, 마크다운 에디터, 텍스트 도구
• 미디어·그래픽 (6종): 이미지 포맷 변환·압축, QR 코드 생성기, SVG 색상 편집 및 React JSX 변환, GIF 프레임 에디터, 로딩 스피너 생성기
• 생활·금융 계산기 (13종): 국내 4대보험·소득세 반영 연봉 실수령액 계산기, 글로벌 실수령액, VAT/Sales Tax, N빵 계산기, 통합 단위·날짜·만 나이·퍼센트·BMI 계산기, 일본 연호·전각/반각 변환기 등

불편 넷: 한글이나 이모지만 넣으면 깨지는 Base64

기존 온라인 Base64 변환기 중에는 영문 ASCII는 잘 변환하면서 한글이나 이모지를 넣으면 오류가 나거나 디코딩 결과가 외계어처럼 깨지는 곳이 적지 않습니다. 브라우저 내장 함수인 btoa()와 atob()가 1바이트(Latin1) 범위를 넘어서는 유니코드 문자를 직접 처리하지 못하기 때문입니다.

anyTools의 Base64 도구는 TextEncoder와 TextDecoder를 사용해 문자열을 표준 UTF-8 바이트 배열(Uint8Array)로 먼저 직렬화한 뒤 Base64로 변환하도록 구현하여 한글·한자·이모지가 섞인 데이터도 손실 없이 완벽히 복원합니다. 또한 JWT나 URL 파라미터에 바로 쓸 수 있는 Base64URL(`-`, `_` 치환 및 `=` 패딩 생략) 옵션도 함께 제공합니다. 자세한 동작 원리는 Base64 인코딩 원리와 한글 처리 아티클에 정리해 두었습니다.

불편 다섯: 수 메가바이트짜리 JSON을 붙여 넣으면 멈추는 브라우저

실무에서 대용량 API 응답이나 로그 덤프 JSON을 온라인 포매터에 붙여 넣었다가 브라우저 탭 전체가 수십 초 동안 얼어붙은 경험이 있었습니다. 메인 UI 스레드에서 동기식으로 거대한 문자열을 파싱하고 수만 줄의 DOM 요소를 한꺼번에 렌더링하려다 보니 발생하는 현상이었습니다.

anyTools의 JSON 포매터는 무거운 파싱·정렬 연산을 별도의 백그라운드 스레드인 Web Worker로 분리해 메인 스레드 블로킹을 막고, 화면 출력 시에도 현재 스크롤 영역에 보이는 줄만 렌더링하는 가상 스크롤(Virtual Scrolling) 기법을 적용했습니다. 이 성능 최적화 기법은 대용량 JSON 파싱 및 웹 성능 최적화 기법 글에서 코드와 함께 자세히 다루고 있습니다.

불편 여섯: 파일 하나 확인하려고 무거운 뷰어 프로그램을 설치해야 할 때

맥(macOS)이나 리눅스, 혹은 스마트폰에서 관공서 공문인 .hwp 파일을 열어봐야 할 때 한컴오피스를 새로 설치하거나 외부 변환 서버에 파일을 업로드하는 것은 번거롭고 찝찝합니다.

anyTools에는 브라우저 내장 파서만으로 동작하는 HWP/HWPX 뷰어와 Word·Excel·PPT 뷰어를 탑재해, 별도 프로그램 설치나 회원가입 없이 파일을 드래그 앤 드롭하는 것만으로 즉시 본문과 표 내용을 확인할 수 있도록 했습니다.

불편 일곱: 모바일 화면에서도 데스크톱처럼 편하게

이동 중에 메신저로 전달받은 인코딩 문자열을 풀거나 더치페이 정산을 할 때처럼 스마트폰으로 도구를 여는 경우도 많습니다. 모든 도구를 반응형 레이아웃으로 설계하여 작은 모바일 화면에서도 입력창 조작과 '결과 복사', '공유하기' 버튼 터치가 한 손으로 매끄럽게 이어지도록 다듬었습니다.

일상과 개발 업무에서 이렇게 활용합니다

• 백엔드 연동 중 중첩된 JSON 응답을 빠르게 펼쳐 구조와 문법 오류 위치를 확인할 때 JSON 포매터를 씁니다.
• 퍼센트 인코딩된 한글 쿼리스트링이나 이스케이프된 문자열을 분석할 때 URL·HTML 변환기를 활용합니다. 두 인코딩의 차이는 URL 인코딩과 HTML 엔티티 인코딩 비교 글에 정리되어 있습니다.
• 외부 기관에서 받은 HWP 공문이나 엑셀 시트를 프로그램 설치 없이 3초 만에 열람할 때 문서 뷰어를 씁니다.
• 블로그 본문에 들어갈 PNG 캡처 이미지를 WebP로 일괄 변환하고 용량을 압축할 때 이미지 도구를 사용합니다.

30가지 도구의 전체 기능과 상황별 활용 시나리오는 anyTools 사용 가이드에서 확인하실 수 있습니다.

클라이언트 처리 방식의 한계와 앞으로의 계획

모든 작업을 브라우저 내부에서 처리하는 구조는 보안과 속도 면에서 큰 장점이 있지만, 두 가지 물리적 특성이 있습니다.

• 사용자 기기 사양 의존성: 서버 자원이 아닌 현재 접속한 스마트폰이나 PC의 CPU·메모리를 사용하므로, 저사양 모바일 기기에서 수백 MB 단위의 초고해상도 영상·문서를 처리할 때는 시간이 더 소요될 수 있습니다.
• 복잡한 전용 문서 서식의 표현 범위: 브라우저 기반 HWP·오피스 뷰어는 본문 텍스트와 표 내용을 빠르고 안전하게 확인하는 데 초점을 맞추고 있으므로, 특수 폰트나 정밀한 인쇄 레이아웃이 중요한 문서는 최종적으로 전용 프로그램에서 검수하시는 것을 권장합니다.

앞으로도 도구의 개수를 무분별하게 늘리기보다는, 매일 쓰는 30가지 도구의 변환 정확도와 대용량 파일 처리 안정성을 꾸준히 고도화해 나갈 계획입니다.