내 개발 도구에서 AI를 제거하고 그 기능을 유지한 이유

나는 일주일 동안 내 개발 도구 제품군에 AI 기능을 추가하는 데 시간을 보냈다. 자연어를 정규표현식 (Regex)으로 변환하는 기능, AI 기반의 SQL 쿼리 설명 기능 등, 2026년형 제품에서나 기대할 법한 기능들이었다. 그것들은 잘 작동했다. 사용자들은 마침내 자신이 원하는 것을 평이한 영어로 설명하고 실제 답변을 얻을 수 있었다.

그러고 나서 나는 그 기능들 밑바탕에 깔려 있던 AI를 통째로 들어냈다.

기능 자체를 없앤 것은 아니다. 일부 기능은 여전히 남아 있으며, 동일한 Pro 배지가 붙어 있고, 사용자 관점에서는 여전히 동일한 역할을 수행한다. 바뀐 점은 입력창 뒤에서 실행되는 방식이다. 원격 LLM (Large Language Model)으로의 API 호출이 사라졌다. 살아남은 기능들은 이제 수백 줄의 클라이언트 측 패턴 매칭 (Pattern Matching)으로 구동되며, 이 변화를 견디지 못한 기능들은 완전히 사라졌다.

이것은 그러한 결정이 어떻게 내려졌는지, 왜 더 많은 1인 개발자들이 동일한 결정을 내려야 한다고 생각하는지, 그리고 내가 이제 새로운 기능을 추가하기 전에 사용하는 간단한 프레임워크에 대한 이야기다.

설정 (The setup)

나는 22개의 브라우저 기반 개발 도구 제품군인 DevCrate를 운영하고 있다. JSON 포맷터 (Formatter), JWT 디코더 (Decoder), 정규표현식 (Regex) 테스터, cron 빌더와 같은 것들이다. 이 제품 전체에는 단 하나의 약속이 있다: 그 어떤 것도 당신의 브라우저를 떠나지 않는다. 계정도 없고, 추적도 없으며, 데이터가 어디로도 전송되지 않는다. JWT 디코더에 운영 환경의 비밀 키(Production secrets)를 붙여넣어도 아무것도 외부로 전송되지 않는다.

그 약속은 마케팅 문구가 아니다. 그것이 이 제품이 존재하는 이유 전체다. 다른 모든 온라인 개발 도구들은 처리를 위해 당신의 데이터를 서버로 전송한다. 대부분의 개발자들은 이를 신경 쓰지 않는다. 하지만 이를 신경 쓰는 사람들은 대안을 원한다. 내가 그렇고, 내 사용자들도 그렇다.

"훌륭한" 아이디어

정규표현식 (Regex) 도구는 인기가 있었지만, 나는 마찰 지점을 발견할 수 있었다. 사람들은 무엇을 매칭하고 싶은지는 알지만, 그것을 어떻게 작성해야 하는지는 모르는 상태로 도구에 접속한다. "이메일 주소를 매칭하되 플러스(+) 기호가 포함된 것은 제외해줘." "숫자로 시작하고 그 뒤에 마침표가 붙는 줄을 찾아줘." 설명하기는 매우 쉽지만 정규표현식으로 쓰기에는 짜증 나는 작업들이다.

해결책: 자연어 입력 (natural language input)을 추가합니다. 설명을 입력하면 패턴을 얻습니다. 배후에서는 LLM (Large Language Model)에 대한 API 호출로 작동합니다. Pro 기능입니다. 쉬운 업셀 (upsell) 요소입니다.

SQL에도 동일한 로직이 적용됩니다 — 쿼리를 붙여넣으면 쉬운 영어 설명이 나옵니다. 전 직장 동료로부터 300줄짜리 쿼리를 물려받았나요? 이제 10초 만에 그것이 무엇을 하는지 이해할 수 있습니다. Pro 기능이며, 쉬운 업셀 요소입니다.

나는 두 가지 모두를 만들었습니다. 그것들은 작동했습니다. 나는 그것들을 출시했습니다. 나는 내가 똑똑하다고 느꼈습니다.

깨달음

며칠 후 한 사용자가 내게 이메일을 보냈습니다. 정중하지만 직설적이었습니다: "잠시만요, 그 AI 기능이 제 쿼리를 API로 전송하는 것 아닌가요? 저는 브라우저 밖으로 아무것도 나가지 않는 것이 핵심이라고 생각했습니다."

나는 답변을 준비해 두었습니다. Pro AI 기능들은 선택 사항 (opt-in)이었습니다. 버튼을 클릭했을 때만 실행되었습니다. 무료 도구들은 여전히 완전히 클라이언트 측 (client-side)에서 작동했습니다. 프라이버시 약속을 어기는 것은 없었습니다 — 단지 더 미묘해졌을 (more nuanced) 뿐이었습니다.

나는 그 답변을 타이핑했습니다. 하지만 보내지는 않았습니다.

왜냐하면 내가 논쟁하려 했던 내용은 다음과 같았기 때문입니다: "제품은 여전히 핵심 약속을 지키고 있으며, 단지 어떤 부분이 그런지 알기 위해 세부 조항 (fine print)을 읽어야 할 뿐입니다." 그런데 이것은 다른 모든 도구가 하는 방식과 정확히 일치했습니다. 모든 분석 SDK (analytics SDK)는 "선택 사항 (opt-in)"입니다. 모든 트래커 (tracker)는 "사용자의 이익을 위한 것"입니다. 모든 데이터 수집 기능은 그것들을 하나씩 나열해 보기 전까지는 합리적으로 들리는 정당성을 가지고 있습니다.

DevCrate가 존재하는 이유 전체가 바로 내가 그런 제품들에 지쳤기 때문입니다. 그런데 내가 바로 그런 짓을 하고 있었습니다.

내가 실제로 한 일

이 부분은 대부분의 블로그 포스트가 지나치게 단순화하는 지점이기에, 나는 구체적으로 말하고 싶습니다. 나는 자연어 정규표현식 (natural-language regex) 기능을 제거한 것이 아닙니다. 그 배후에 있는 AI를 제거한 것입니다. 여기에는 차이가 있으며, 그것은 중요합니다.

완전히 삭제된 것:

• AI SQL 쿼리 설명기. 기능 전체가 사라졌습니다 — 임의의 SQL 쿼리를 LLM을 거치지 않고 설명할 방법은 없으며, 나는 그렇게 할 의사가 없었습니다. 그래서 그 기능은 사라졌습니다.

재설계되었지만 유지된 것:

• 정규표현식 (regex) 도구의 자연어 입력. 동일한 입력창, 동일한 Pro 배지, 동일한 "Generate →" 버튼을 유지합니다. 하지만 버튼 뒤에는 이메일, 전화번호, UUID, 16진수 색상(hex color), IPv4, "숫자로 시작하는 줄" 등 가장 흔한 요청을 다루는 약 30개의 하드코딩된 패턴 (hardcoded patterns)을 가진 함수가 있습니다. 만약 당신의 설명이 이 중 하나와 일치하면, 즉시 정규표현식을 얻게 됩니다. 일치하지 않는다면, 어떤 문구가 지원되는지 설명하는 메시지와 함께 당신이 시도했던 내용이 미리 채워진 내 문의 양식 링크를 받게 됩니다. 이를 통해 실제 사용자들이 실제로 무엇을 요청하는지에 기반하여 패턴 목록을 확장할 수 있습니다.
• cron 도구의 자연어 입력. 동일한 방식입니다. 일반적인 일정("매 평일 오전 9시", "매 15분마다", "매월 첫째 날")을 다루는 약 15개의 하드코딩된 패턴이 있습니다. API 호출은 없습니다. 일치하지 않으면 "패턴 제안하기" 링크가 나타납니다.

사용자 관점에서 보면, 정규표현식과 cron 기능은 일반적인 경우에 여전히 작동합니다. Pro 배지도 그대로 있습니다. "원하는 것을 설명하고 패턴을 얻으세요"라는 홍보 문구도 그대로입니다. 달라진 점은 그 기능들을 사용할 때 단 1바이트도 브라우저를 떠나지 않는다는 것입니다. 기능은 더 단순해졌지만, 제품의 약속은 다시 정직해졌습니다.

나는 내가 "AI를 제거했다"고 주장하는 버전보다 이러한 구분이 더 유용하다고 생각합니다. 많은 AI 기능들이 이런 방식으로 결정론적 로직 (deterministic logic)으로 대체될 수 있습니다. 질문은 당신의 기능에 AI가 존재하는가가 아니라, AI가 하드코딩된 함수가 할 수 없는 일을 수행하고 있는가입니다.

내가 현재 사용하는 프레임워크

이것은 일회성 작업이 아니었습니다. 모든 제품에는 핵심 약속 (core promise)이 있습니다. 즉, 제품이 무엇인지를 정의하기 위해 자신과 사용자에게 말하는 것입니다. 개인정보 보호 우선 (Privacy-first). 오픈 소스 (Open source). 구독 없음. 초보자 친화적. 번개처럼 빠른 속도. 그것이 무엇이든, 당신의 기능은 그 약속을 강화하거나 혹은 침식시킵니다.

이제 나는 새로운 기능을 추가하기 전에 세 가지 질문을 던집니다:

1. 이 기능이 무엇을 하는지에 대해 정직하게 말했을 때도 여전히 작동하는가?

테스트 방법: 해당 기능에 대한 마케팅 문구를 가능한 한 가장 지루하고, 기술적이며, 정확한 방식으로 작성해 봅니다. 과장(spin)은 배제합니다. 만약 "AI 정규표현식 생성기 (AI regex generator)"가 "사용자의 설명을 OpenAI/Anthropic/기타 서비스로 보내고, 그들이 정규표현식 패턴을 반환합니다"로 바뀌었는데, 이 문장이 내 홈페이지의 다른 내용과 모순된다면 그 기능은 문제가 있는 것입니다. 반드시 치명적인 문제는 아닐지라도, 출시 전에 해결할 가치가 있는 문제입니다.

SQL 설명기 (SQL explainer)의 경우, 정직한 설명은 "사용자의 쿼리를 제3자 LLM (Large Language Model)으로 보냅니다"였습니다. 이는 홈페이지의 약속을 어기는 것이었습니다. 결국 그 기능은 폐기되었습니다.

정규표현식 자연어 입력 (regex natural-language input)의 경우, 정직한 설명은 "브라우저 내의 일반적인 패턴 목록과 사용자의 설명을 대조합니다"가 되었습니다. 이는 아무 문제 없이 작동합니다. 따라서 이 기능은 살아남았습니다.

2. 여전히 유용하면서도 이 기능의 가장 멍청한 버전은 무엇인가?

AI 정규표현식 생성기는 LLM 호출 방식이었습니다. AI가 없는 버전은 하드코딩된 패턴이 포함된 50줄짜리 함수였습니다. 이 멍청한 버전은 실제 사용자 요청의 80%를 처리할 수 있었고, 즉각적으로 실행되었으며, 비용이 들지 않았고, 사용자의 기기에서 단 1바이트의 데이터도 외부로 전송하지 않았습니다. 인상적이기는 덜했지만, 제품 측면에서는 더 나았습니다.

저는 AI 반대론자가 아닙니다. 저는 DevCrate를 만들기 위해 매일 AI 도구를 사용합니다. 질문은 AI가 유용한가 아닌 것이 아니라, _이 특정 기능_이 가치를 전달하기 위해 반드시 AI가 필요한지, 아니면 AI가 단지 기능을 출시하기 위해 그럴듯하게 들리는 방식일 뿐인지에 대한 것입니다.

3. 내가 이것을 추가했을 때 누가 이득을 보는가 — 나인가, 아니면 사용자인가?

이 질문은 뼈아픕니다. 제가 AI 기능들을 출시했을 때 저에게는 명확한 서사가 있었습니다: 프로(Pro) 플랜 업셀링, 현대적인 기능 세트, 그리고 제품이 "진짜"라는 시장 신호. 이것들은 모두 나에게 이득이 되는 이유들입니다. 사용자는 ChatGPT에 직접 물어보는 방식으로 이미 존재하던 기능을 얻었을 뿐이며, 차이점이라면 이제 나에게 그 대가를 지불한다는 것이었습니다.

주로 개발자(본인)에게 이득이 되고 사용자에게는 부차적인 이득만 주는 기능들은 조용히 신뢰를 갉아먹는 경향이 있습니다. 사용자는 이를 말로 설명하지 못하더라도 느낄 수 있습니다.

내가 말하고자 하는 바가 아닌 것

제품에 AI를 추가하지 말라는 뜻이 아닙니다. 많은 제품이 AI 기능으로부터 진정으로 이득을 얻고 있으며, 그것이 업계 전체가 그 방향으로 움직이는 이유입니다. Cursor, GitHub Copilot, Linear의 AI 기능, 그리고 Claude 그 자체까지. 이들은 모두 그 자리에 있을 가치가 있는 AI를 출시합니다.

제가 말하고자 하는 것은 이것입니다: 당신의 특정 기능이 실제로 가치가 있는지에 대해 정직해지라는 것입니다. 개인정보 보호를 우선시하는 브라우저 도구의 경우, 데이터를 제3자 LLM (Large Language Model)으로 전송하는 것은 잘못된 일이었습니다. 그것이 선택 사항(opt-in)이었을 때도, 유료 기능이었을 때도, 홈페이지의 설명이 기술적으로 여전히 정확했을 때조차도 말입니다. 로컬 머신에서 실행되는 코드 에디터의 경우, LLM을 호출하는 것은 괜찮습니다. 트렌드보다 카테고리가 더 중요합니다.

또한 제가 DevCrate에 실제 AI를 절대 다시 도입하지 않겠다는 뜻도 아닙니다. 만약 제가 WebLLM이나 작은 WASM (WebAssembly) 모델 같은 것을 사용하여 모델이 완전히 클라이언트 측(client-side)에서 실행되는 기능을 만든다면, 그것은 개인정보 보호 약속을 지키는 일이 될 것입니다. 기술은 이미 존재합니다. 제가 염두에 두었던 사용 사례에 적용하기에는 아직 준비가 되지 않았지만, 점점 가까워지고 있습니다. 준비가 된다면, 그것은 출시할 가치가 있는 기능이 될 것입니다.

요점 (The takeaway)

기능을 제거하는 것은 자신이 틀렸음을 인정하는 것처럼 느껴집니다. 때로는 실제로 틀렸을 수도 있습니다. 그것은 괜찮습니다. 3개월 차에 출시하는 제품이 1개월 차에 상상했던 제품과 반드시 일치할 필요는 없습니다. 제품은 사용자가 당신에게 실제로 필요로 하는 것과 일치해야 하며, 이는 보통 더 많은 것을 하는 것이 아니라 더 적은 것을 하는 것을 의미합니다.

하지만 이 교훈의 더 나은 버전은 "기능을 제거하라"가 아닙니다. 그것은 바로 기능과 구현(implementation)을 분리하라는 것입니다. AI는 구현 방식이었습니다. 핵심 가치(pitch)는 기능이었습니다. 어떤 기능들은 구현 방식을 교체함으로써 유지될 수 있습니다. 어떤 것들은 그렇지 못합니다. 무엇이 무엇인지 아는 것이 작업의 대부분입니다.

다음에 당신이 제품의 핵심 약속과 모순되지 않는 이유를 설명하기 위해 각주(footnote)가 필요한 기능을 추가하려 한다면, 멈추십시오. 그 각주를 작성해 보세요. 그리고 소리 내어 읽어보세요. 스스로를 믿을 수 있을지 결정하십시오.

만약 당신 자신조차 믿지 못한다면, 사용자들도 믿지 않을 것입니다.

저는 DevC<em>rate를 만든 개발자 William입니다. 만약 당신이 혼자 무언가를 만들고 있으며 비슷한 결정들로 고민하고 있다면, 진심으로 그 이야기를 듣고 싶습니다.

당신의 제품에서 어떤 기능을 제거했나요 (혹은 제거했어야 했다고 생각하나요)? 댓글로 남겨주세요 — 저는 모든 댓글을 읽습니다.