MEA Tools의 라이브러리는 왜 다른 사람의 것 대신 처음부터 직접 만들었을까?

직접 작성했다는 건 정말로 "처음부터"라는 뜻입니다

MEA Tools의 PDF 기반 툴 — PDF 합치기, PDF 나누기, PDF를 Word로 변환, PDF 양식 채우기, 암호화와 워터마크까지 — 거의 모두의 핵심인 pdf-lib 폴더를 예로 들어보겠습니다. 이 폴더는 37개에 가까운 JavaScript 파일, 총 1만 줄이 넘는 코드로 이루어져 있으며, 모두 처음부터 직접 작성되었습니다: 원시 PDF 객체 파서, 토크나이저, 콘텐츠 스트림 인터프리터, xref 구조 재구성기, 페이지를 이미지로 렌더링하는 래스터라이저까지요.

즉 MEA Tools가 PDF 파일을 "읽을" 때, 이것은 그냥 가져다 쓰는 남의 라이브러리 호출이 아닙니다 — PDF 파일 구조를 사양에 맞춰 바이트 단위로 실제로 파싱하는 코드가, 이 툴의 필요에 맞춰 특별히 작성되어 있습니다. 다른 폴더들도 마찬가지입니다: 이미지 압축 로직, 색상 변환, QR 코드 생성, 해시 함수까지 — 전부 직접 작성한 코드이지, import해서 바로 쓰는 npm 패키지가 아닙니다.

왜 굳이 직접 작성하는 수고를 들일까요?

단순한 기술적 자존심이 아니라 구체적인 이유가 몇 가지 있습니다:

• 더 작은 파일 크기. 범용 라이브러리는 보통 여러 사용 사례를 처리하기 위해 일반적으로 만들어지며, 그 결과 관련 없는 코드가 많이 딸려옵니다. 자신의 필요에 맞춰 작성된 코드는 훨씬 가벼울 수 있고, 이것은 모든 처리가 넉넉한 리소스의 서버가 아니라 사용자의 브라우저에서 실행되기 때문에 중요합니다.
• 동작에 대한 완전한 제어. 특정 PDF 유형에서 이상한 버그가 나타나도, 다른 라이브러리 메인테이너가 패치를 내놓기를 기다릴 필요 없이 직접 분석하고 고칠 수 있습니다 — 모든 코드가 실제로 자신의 소유이기 때문입니다.
• 유지보수가 중단될 의존성이 없음. 많은 인기 오픈소스 라이브러리가 메인테이너가 다른 일로 바빠지면서 업데이트를 멈춥니다. 툴의 기반이 그런 것 위에 세워져 있다면, 그 위험도 함께 안게 됩니다.
• 사용자 데이터에 무슨 일이 일어나는지 정확히 파악. 모든 파싱 코드 줄이 직접 작성되었기 때문에, 어떤 일을 하는지 정확히 알 수 없는 "블랙박스" 형태의 제3자가 사용자 파일을 처리하는 일이 없습니다.

하지만 전부 직접 작성한 건 아닙니다 — 그리고 그것도 의도적입니다

이 글이 홍보가 아니라 정직하려면: MEA Tools의 일부 영역은 실제로 제3자 라이브러리나 모델을 사용하며, 이는 잊어버린 게 아니라 의식적인 결정입니다.

• 사진 배경 제거는 오픈소스 AI 모델(U2Net)을 ONNX Runtime을 통해 실행합니다 — 커뮤니티에서 만든 AI 추론 엔진으로, 직접 작성한 것이 아닙니다. 신경망 추론 런타임 전체를 처음부터 다시 작성하는 것은 수십 개 중 하나의 툴을 위한 작업치고는 분명 합리적인 범위를 벗어납니다. AI 모델 파일 자체는 제3자 CDN이 아닌 MEA 서버에 호스팅되어 있지만, 이를 실행하는 엔진은 여전히 ONNX Runtime입니다.
• 이미지 해상도 확대(업스케일러)도 같은 이유로 Real-ESRGAN AI 모델을 ONNX Runtime을 통해 사용합니다.
• 이미지/스캔에서 텍스트 추출(OCR)을 하는 두 가지 툴은 이미 성숙하고 널리 신뢰받는 오픈소스 OCR 엔진인 Tesseract.js를 사용합니다. OCR 엔진을 처음부터 다시 작성하는 것은 하나의 문서 변환 툴의 범위를 훨씬 벗어나는 별도의 연구 프로젝트입니다.

흥미로운 부분은 코드 자체 안에 있습니다: 처음부터 수동으로 작성하지 않기로 일부러 결정한 또 다른 부분은 PDF 암호화를 위한 AES 함수입니다 — 이는 직접 만든 AES 구현이 아니라 브라우저 내장 Web Crypto API를 활용합니다. 그 이유는 코드 주석에 분명히 적혀 있습니다: AES는 실제 보안(PDF 내용을 다른 사람으로부터 보호)을 위해 사용되며, 브라우저 내장 AES 구현은 이미 철저히 감사되었고 타이밍 공격에도 강합니다 — 보안 감사의 보장 없이 수동으로 다시 작성한다면 매우 위험한 부분입니다.

비교해보면, 같은 툴에 있는 MD5와 RC4 해시 함수는 실제로 처음부터 수동으로 작성되었습니다 — 거기서 MD5/RC4는 민감한 보안 목적이 아니라, 오래된 PDF 데이터 형식의 필요를 위해 사용되기 때문입니다.

이게 사용자인 당신에게 왜 중요할까요?

겉보기엔 그냥 배경의 기술적 디테일처럼 들릴 수 있습니다. 하지만 그 영향은 바로 체감됩니다: 자신의 필요에 맞춰 특별히 작성된 툴은 대체로 더 가볍게 실행되고, 더 빨리 열리며, 동작을 더 예측하기 쉽습니다 — 실제로는 쓰이지 않는 범용 코드의 부담을 짊어지지 않기 때문입니다. 그리고 PDF 암호화처럼 데이터 보안에 정말 핵심적인 부분에서는, 일관성만을 위해 모든 것을 억지로 수동 작성하는 것보다 이미 검증된 구현을 사용하는 선택이 오히려 더 안전합니다.

여전히 계속 발전 중입니다

이것도 알아둘 필요가 있습니다: "처음부터 작성" 방식은 바로 쓸 수 있는 라이브러리를 설치하는 것보다 새 기능마다 더 많은 시간이 걸린다는 뜻입니다. 특히 PDF 관련해서, 직접 만든 pdf-lib는 PDF 파일로 할 수 있는 전체 영역 중 일부만을 다루고 있습니다 — PDF 형식의 세계는 넓고, MEA Tools는 아직 여기서 멈추지 않았습니다. MEA Tools 전반은 여전히 계속 개발되고 추가되고 있으므로, 지금 있는 기능 범위가 최종 버전이 아니라 시간이 지나면서 계속 늘어날 것입니다.