지금 거의 매일 DEV의 메인 페이지를 열어보면 AI로 생성된 컴포넌트 도구, "프로덕션 준비가 된 코드(production-ready code)"를 생성하는 AI 프롬프트, 또는 지난달까지만 해도 없었던 챗봇이 무언가에 덧붙여진 것을 발견하게 될 것입니다. 저는 이것들을 비난하려고 이 글을 쓰는 것이 아닙니다. 그중 일부는 진정으로 유용합니다. 하지만 이는 모든 로드맵 논의에서, 심지어 AI가 필요하지 않은 문제에 대해서조차 결국 "여기에 AI를 넣어야 할까?"라고 묻게 만드는 이상한 중력적 인력을 만들어냈습니다.

저는 반대 방향으로 갔습니다. 지난 1년 동안 70개 이상의 도구를 갖춘 이미지/PDF 플랫폼을 구축하면서, 실제 어려운 엔지니어링 문제는 "어떻게 AI를 추가할 것인가"가 아니라 "어떻게 서버를 제거할 것인가"였습니다.

아무도 열광하지 않는 지루한 문제

대부분의 이미지 및 PDF 도구는 파일을 서버로 업로드하고, 그곳에서 처리한 다음, 결과를 다시 보냅니다. 그것은 간단하고 잘 알려진 방식이지만, 제가 제거하기 위해 가장 많은 엔지니어링 노력을 기울인 것이기도 합니다. 서버가 나쁘기 때문이 아니라, 거대한 도구 카테고리(크기 조정, 압축, 변환, 자르기)의 경우 파일이 기기를 떠나야 할 실제적인 이유가 전혀 없기 때문입니다. 현대의 브라우저는 스스로 이 작업을 수행할 수 있습니다.

AI 모델은 관여하지 않습니다. 그저 Canvas API, 압축 파라미터에 대한 이진 탐색(binary search), 그리고 진정으로 결정론적인(deterministic) 결과만 있을 뿐입니다. 즉, 동일한 입력은 항상 동일한 출력을 생성하며, 이는 누군가가 정부 양식에 제출할 신분증 사진을 압축할 때 도구가 예측 불가능한 작업을 몰래 수행하지 않았음을 신뢰해야 하는 상황에서 매우 중요하다는 것이 밝혀졌습니다.

실제로 AI 도입을 고려했으나 사용하지 않은 부분

공정하게 반대 측의 입장도 고려하자면, 저도 몇 가지 기능에 대해 AI를 평가했습니다:

• 여권 사진용 자동 자르기/스마트 프레이밍(Auto-crop/smart framing) — 이론적으로 AI 모델이 얼굴 위치를 감지하고 자르기를 제안할 수 있습니다. 하지만 저는 대신 더 간단한 기하학적 접근 방식을 구현했습니다 (가장 큰 연속적인 피부색 영역을 감지하여 중앙에 배치). 그 이유는 즉각적이고, 오프라인에서 작동하며, — 결정적으로 — 예측 가능한 방식으로 실패하기 때문입니다. AI 자동 자르기가 잘못된 경우, 왜 틀렸는지 명확하지 않을 수 있습니다. 반면 규칙 기반 접근 방식이 잘못된 경우, 보통 어떤 가정이 깨졌는지 정확히 알 수 있습니다.
• **스마트 압축 제안(

그 결과물은 ResizeHub입니다. 70개 이상의 도구가 포함되어 있으며, 파이프라인 어디에도 AI가 없고, 서버가 파일에 단 한 번도 직접 닿지 않습니다. 그리고 결국