'AI를 넣었더니 더 좋아졌다'는 이야기는 넘쳐난다. 그런데 요즘 눈에 띄는 건 반대 방향의 사례들이다. AI를 걷어낸 뒤 오히려 제품이 더 단단해졌다는 회고들. 세 가지 인디 개발자 프로젝트를 같이 읽다 보면, 공통된 결론이 보인다. 진짜 설계 판단은 무엇을 추가할지가 아니라 무엇을 덜어낼지에서 나온다.
AI를 제거한 건 기능이 아니라 의존이었다
Dev.to에 올라온 DevCrate 제작기는 솔직하다. 개발자 도구 모음을 운영하는 저자는 '브라우저 밖으로 데이터를 절대 보내지 않는다'는 단 하나의 제품 약속 위에 서비스를 쌓아왔다. 그런데 자연어로 정규식을 생성하는 AI 기능을 붙이는 순간, 네트워크 탭에 api.anthropic.com 요청이 떴다. CORS로 막혔지만, 의도된 아키텍처 자체가 문제였다.
저자가 택한 해법은 흥미롭다. AI 기능은 살리고, AI 의존만 제거했다. 정규식 자연어 입력 UI는 그대로 유지하되, 뒤에서 돌아가는 건 이메일·전화번호·UUID 등 30여 개 패턴을 하드코딩한 50줄짜리 함수로 교체했다. SQL 설명 기능은 LLM 없이는 성립이 안 되니 통째로 삭제했다. 결과적으로 '기능이 멍청해진 게 아니라 제품 약속이 다시 정직해졌다'는 표현이 핵심이다.
여기서 끌어낼 수 있는 프레임이 있다. 기능을 추가하기 전에 던져야 할 질문은 세 가지다. "이 기능을 가장 지루하고 정확하게 설명하면 홈페이지 약속과 충돌하는가?" "AI 없이도 사용자 니즈의 80%를 커버할 수 있는 가장 단순한 버전은 무엇인가?" "이 기능이 이득을 주는 건 나인가, 사용자인가?" — 이 세 질문은 AI 기능만이 아니라 모든 피처 결정에 적용된다.
백엔드 없이 72개 도구를 만든 아키텍처 선택
같은 맥락에서 ToolKnit의 기술 회고도 읽힌다. 혼자 77일 만에 브라우저 전용 도구 72개를 완성한 저자는 Node.js 서버도, 서버리스 함수도 없이 Nginx 위에 정적 HTML만 올렸다. 핵심 기술 선택은 세 가지였다.
첫째, WebAssembly. 동영상 변환, 오디오 트리밍 같은 무거운 작업은 FFmpeg.wasm으로 처리한다. 초기 로드에 25MB가 추가되는 트레이드오프가 있지만, 사용자가 파일을 선택하는 순간에만 지연 로딩해서 체감 속도를 잡았다. 둘째, Service Worker 기반 PWA. 모든 도구 페이지를 프리캐시해서 오프라인에서도 작동한다. 셋째, 단일 JSON 데이터 소스. 70개 HTML 파일에 관련 도구 목록을 인라인으로 박아두다가 배포 지옥을 경험한 뒤, tools.json 하나로 정리했다. 가장 지루한 배포가 가장 임팩트 있는 리팩터링이었다는 회고가 인상적이다.
프라이버시 측면의 설계 결정도 눈여겨볼 만하다. 익명 분석을 위해 IP를 로그에 남기다가, '데이터를 공유하지 않는다'는 게 충분하지 않다는 걸 스스로 깨닫고 하루를 통째로 써서 SHA-256 해싱으로 마이그레이션했다. 사용자 눈에는 아무것도 달라지지 않는 변경이다. 그런데 저자는 그 배포 이후 잠을 더 잘 잔다고 했다. 이게 프로덕트 약속을 진지하게 대하는 팀의 태도다.
Sharp + Next.js, 서버리스로 고품질 처리를 구현하는 방식
Favicraft는 방향이 조금 다르다. 완전한 클라이언트 사이드가 아니라 Next.js 서버리스 API 라우트와 Sharp 라이브러리를 조합해 파비콘 생성 파이프라인을 구현했다. 주목할 부분은 기술 선택의 이유다. 기존 파비콘 도구들이 바이리니어 리사이즈로 뿌연 결과를 내는 문제를 Lanczos3 다운샘플링으로 해결했고, 대부분의 도구가 사용자가 직접 작성해야 했던 site.webmanifest와 browserconfig.xml까지 자동 생성해서 ZIP 하나로 프로젝트에 드롭하면 끝나게 만들었다.
이미지 처리 자체는 서버(Vercel 서버리스)에서 돌지만, 이미지를 저장하거나 로깅하지 않는다는 점을 명시했다. 데이터를 처리하는 것과 보유하는 것의 차이를 명확히 선언한 것이다. DevCrate의 '아무것도 보내지 않는다'와는 다른 방식이지만, 사용자에게 무엇이 일어나는지 투명하게 알리는 설계 태도는 같다.
시사점: 기술 선택 이전에 제품 약속을 먼저 써라
세 프로젝트가 공유하는 설계 원칙은 하나다. 기술 선택보다 제품 약속이 먼저 확정되어야 한다. WebAssembly를 쓸지, 서버리스를 쓸지, AI API를 붙일지는 그 다음 문제다. DevCrate가 LLM을 제거한 건 AI가 나빠서가 아니라, AI가 제품의 핵심 약속을 깨뜨렸기 때문이다. ToolKnit이 백엔드를 쓰지 않은 건 비용 때문만이 아니라, 파일이 서버를 거치지 않는다는 약속을 지키기 위해서였다.
우리가 매일 다루는 결정들, 예를 들어 분석 SDK를 붙일지, 어떤 외부 API를 호출할지, 어디까지 클라이언트에서 처리할지는 사실 기술 문제가 아니다. 그건 제품이 사용자에게 무엇을 약속하는가의 문제다. AI 도구가 개발 속도를 올려줄수록, 이 판단을 명확히 갖고 있는 개발자와 그렇지 않은 개발자의 차이가 결과물에서 훨씬 선명하게 드러난다.
앞으로 브라우저 네이티브 기술(WebAssembly, File System Access API, Web Audio API)의 성숙도가 높아질수록, 서버 의존 없이도 무거운 처리가 가능한 영역은 계속 넓어진다. AI를 붙이느냐 마느냐보다 중요한 질문은, 지금 내 제품에서 서버(혹은 외부 API)가 정말 필요한 이유가 있는가다. 그 답이 명확하지 않다면, DevCrate의 사례처럼 걷어내는 게 더 나은 설계일 수 있다.