여러분은 아마도 AI로 SaaS를 구축하는 것이 거의 노력 없이 가능한 것처럼 들리는 게시물들을 보셨을 것입니다:

Claude에게 프롬프트 하나를 주고, 몇 시간만 기다리면 출시할 수 있다.

제 경험은 그렇지 않았습니다.

저는 Infill을 구축하는 동안 Claude와 다른 AI 코딩 도구들을 사용했고, 그것들은 분명히 도움이 되었습니다. 저는 더 빠르게 코드를 작성했고, 버그를 더 빨리 발견했으며, 많은 반복적인 작업을 피할 수 있었습니다.

하지만 제품을 구축하는 데는 여전히 3개월 이상이 걸렸습니다.

이유는 간단합니다. 코드를 생성하는 것이 결코 가장 어려운 부분이 아니었기 때문입니다.

첫 번째 버전은 쉬웠다

초기 데모를 작동하게 만드는 데는 오래 걸리지 않았습니다.

Infill은 사용자가 반복적인 양식을 채우는 것을 도와주는 브라우저 확장 프로그램 (browser extension)입니다. 기본 아이디어는 간단해 보입니다:

1. 페이지의 필드(fields)를 읽습니다.
2. 이를 사용자의 프로필 정보와 매칭합니다.
3. 양식을 채웁니다.

AI 모델은 그러한 프로토타입 (prototype)을 빠르게 구축하는 데 도움을 줄 수 있습니다.

문제는 해피 패스 (happy path) 이외의 상황에서 어떤 일이 발생하는지 물을 때 시작됩니다.

웹사이트들은 이상한 레이블 (labels)을 사용합니다. 어떤 양식은 여러 페이지에 걸쳐 나뉘어 있습니다. 어떤 필드에는 이미 데이터가 포함되어 있습니다. 다른 것들은 숨겨져 있거나, 비활성화되어 있거나, 민감하거나, 혹은 봇 (bots)을 잡아내기 위해 설계되어 있습니다.

그다음에는 또 다른 컴포넌트 (component)를 생성하는 것과는 전혀 상관없는 질문들이 있습니다:

• 어떤 정보를 자동으로 채워야 하는가?
• 무엇이 항상 사용자의 승인을 필요로 해야 하는가?
• 프로필 데이터는 어디에 저장되어야 하는가?
• AI가 잘못된 매칭을 하면 어떻게 되는가?
• 모든 양식 제출에 비용이 얼마나 들 것인가?

그러한 결정들이 작업의 대부분이 되었습니다.

모든 것에 AI 모델을 호출하는 것은 나쁜 아이디어였다

저의 첫 번째 본능은 모든 필드 매칭을 LLM (Large Language Model)이 처리하도록 하는 것이었습니다.

데모에서는 좋아 보였습니다: 양식 필드를 모델로 보내고, 매핑 (mappings)을 받아 페이지를 채우는 방식입니다.

하지만 그 접근 방식은 매우 빠르게 비용이 많이 들게 될 것이었습니다.

모든 양식이 또 다른 API 요청을 생성할 것입니다. 더 큰 양식은 더 많은 토큰 (tokens)을 사용할 것입니다. 더 많은 사용자는 더 높은 청구서와 더 높은 지연 시간 (latency)을 의미할 것입니다.

또한 더 큰 개인정보 보호 (privacy) 문제도 있었습니다.

모델이 모든 것을 처리하게 하려면, 폼 필드(form fields)와 사용자 프로필의 일부를 외부 AI 제공업체(AI provider)로 전송해야 합니다. 폼의 종류에 따라 해당 데이터에는 이름, 주소, 전화번호, 고용 기록, 금융 상세 정보 또는 기타 민감한 정보가 포함될 수 있습니다.

다시 말해, 단순히 폼을 채우기 위해 필요 이상의 훨씬 더 많은 사용자 데이터를 노출하게 되는 것입니다.

제품은 작동할지 모르지만, 경제성(economics)과 개인정보 보호 모델(privacy model)은 작동하지 않을 것입니다.

그래서 저는 아키텍처(architecture)를 변경했습니다.

Infill은 이제 결정론적 매칭(deterministic matching)을 먼저 시도합니다. 일반적인 필드들은 AI 호출 없이 로컬에서 매칭될 수 있습니다. AI는 일반적인 규칙만으로는 충분하지 않은 경우에만 선택적인 폴백(fallback)으로 사용됩니다.

이것은 제품 전체가 자율 에이전트(autonomous agent)에 의해 구동된다고 말하는 것보다 덜 흥미로울 수 있습니다.

하지만 더 빠르고, 저렴하며, 더 프라이버시 친화적이고, 추론(reason about)하기에도 더 쉽습니다.

중요한 코드는 여전히 직접 작성합니다

저는 전체 코드베이스(codebase)를 AI 에이전트에게 넘겨주고 그것이 생성하는 것은 무엇이든 그대로 받아들이지 않습니다.

중요한 부분에 대해서는 여전히 제가 직접 코드를 작성합니다.

여기에는 아키텍처 경계(architectural boundaries), 디자인 패턴(design patterns), 데이터 흐름(data flow), 개인정보 보호 규칙(privacy rules), 민감한 필드 처리(sensitive-field handling), 그리고 잘못 구현될 경우 비용이 많이 들거나 위험해질 수 있는 부분들이 포함됩니다.

AI는 몇 초 안에 다섯 가지의 서로 다른 추상화(abstractions)를 제안할 수 있습니다. 하지만 어떤 것이 6개월 후에도 여전히 유효할지는 알 수 없습니다.

AI는 서비스(service), 훅(hook), 또는 리포지토리 패턴(repository pattern)을 생성할 수 있습니다. 하지만 제가 맥락(context)을 제공하지 않는 한, 시스템에 또 다른 레이어(layer)를 추가할 때 발생하는 트레이드오프(trade-offs)를 이해하지 못합니다.

일상적인 작업에 있어 AI는 훌륭합니다. 저는 스캐폴딩(scaffolding), 반복적인 코드, 테스트, 리팩터링(refactoring) 제안, 그리고 대안을 탐색하는 데 AI를 사용합니다.

하지만 제품의 형태를 결정짓는 의사결정에 있어서는 속도를 늦춥니다.

저는 경계를 설정합니다. 패턴을 선택합니다. 데이터가 시스템을 통해 어떻게 이동하는지 검토합니다. 무엇이 로컬에 머물러야 하는지, 무엇이 선택 사항이 될 수 있는지, 그리고 무엇이 절대 자동화되어서는 안 되는지를 결정합니다.

코드가 민감할수록, AI의 출력을 완성된 정답으로 취급하는 것에 대해 저는 더 조심스러워집니다.

생성된 함수는 깔끔해 보일 수 있지만, 여전히 데이터를 유출하거나, 비용이 많이 드는 API 경로를 생성하거나, 레이스 컨디션 (race condition)을 숨기거나, 코드베이스를 유지 관리하기 더 어렵게 만드는 패턴을 도입할 수 있습니다.

AI는 코드를 빠르게 작성할 수 있습니다.

하지만 저는 여전히 그 코드가 존재할 가치가 있는지를 결정해야 합니다.

AI는 나를 더 빠르게 만들었을 뿐, 완성시키지는 않았다

AI 코딩 에이전트 (AI coding agents)는 프로젝트 전반에 걸쳐 유용했습니다.

그들은 제가 스스로 할 때보다 더 빠르게 접근 방식을 탐색하고, 테스트를 생성하며, 코드를 리팩터링 (refactor)하고, 브라우저 확장 프로그램 (browser-extension) 문제를 이해하도록 도와주었습니다.

하지만 그들이 저를 대신해 제품 아키텍처 (product architecture)를 결정해주지는 않았습니다.

그들은 어떤 트레이드오프 (trade-offs)가 가장 중요한지 알지 못했습니다. 제가 어느 정도의 리스크를 감수할 수 있는지, 사용자들이 무엇을 신뢰할지, 혹은 제 API 예산이 무엇을 지원할 수 있는지 알지 못했습니다.

그리고 생성된 코드가 기술적으로는 정확하지만 제품에는 맞지 않을 때, 그것을 알아차려야 하는 것은 여전히 저였습니다.

이것이 바로 "원 프롬프트 SaaS (one-prompt SaaS)"라는 대화 속에서 놓치고 있는 부분이라고 생각합니다.

AI는 놀라울 정도로 빠르게 프로토타입 (prototype)에 도달하도록 도와줄 수 있습니다.

하지만 그 프로토타입을 신뢰할 수 있고, 프라이버시가 보장되며, 유지 관리 가능하고, 비용 효율적인 무언가로 바꾸는 데에는 여전히 실제 엔지니어링 (engineering)이 필요합니다.

AI 코딩 에이전트가 과대평가되었다고 말하는 것이 아닙니다. 저도 매일 사용합니다.

단지 "AI가 내 SaaS를 만들었다"는 말이 전체 이야기는 아니라고 생각할 뿐입니다.

더 솔직한 버전은 다음과 같습니다:

AI는 내가 더 빠르게 구축하도록 도왔지만, 제품을 구축한 것은 여전히 나였다.

여기서 Infill을 확인하실 수 있습니다:

• 웹사이트: https://useinfill.com
• 소스 코드: https://github.com/KaiBelmo/infill