복잡성의 벽: 왜 많은 AI 기반 MVP들이 정확히 같은 지점에서 멈추는가

창업자 커뮤니티 전반에서 이제는 이름을 붙일 수 있을 정도로 구체적인 패턴이 나타나고 있습니다. 바로 '복잡성의 벽 (the complexity wall)'입니다. 창업자가 AI 도구를 사용하여 빠르게 구축하고, 며칠 만에 실제 결과물을 출시하며, 초기 견인력 (traction)을 얻습니다. 그러다 모든 새로운 기능이 이전보다 더 오래 걸리고, 예전에는 안정적이었던 곳에서 버그가 나타나기 시작하며, AI 도구 자체가 다른 것을 망가뜨리지 않고 변경 사항을 만드는 데 어려움을 겪기 시작하는 지점에 도달합니다.

이것은 무작위적인 현상이 아닙니다. 예측 가능한 원인을 가진 예측 가능한 실패 모드 (failure mode)이며, 이에 대한 데이터는 이제 실제로 지도를 그릴 수 있을 만큼 충분히 견고합니다.

속도는 실재합니다
과장되지 않은 사실부터 시작하겠습니다. AI 코딩 도구는 개인이 소프트웨어를 구축하는 속도를 진정으로 변화시켰습니다. 대다수의 전문 개발자들은 이제 최소한 매주 AI 코딩 도구를 사용하고 있으며, 과거에 며칠이 걸리던 일을 몇 시간 만에 끝내는 창업자의 이야기는 마케팅적 주장이 아닙니다. 이는 Indie Hackers 및 유사한 커뮤니티의 빌드 로그와 커뮤니티 글에서 일관되게 나타납니다. 배포 파이프라인 (deployment pipeline)을 설정하는 법을 배운 적이 없는 디자이너, 제품 관리자 (product managers), 그리고 비기술적 창업자들도 이제 혼자서 작동하는 소프트웨어를 출시할 수 있습니다. 이러한 접근성의 변화가 핵심이며, 이는 사라지지 않을 것입니다.

첫날에는 나타나지 않는 부분
여기서부터 구체적인 내용이 나옵니다. 실제 프로덕션 코드베이스 (production codebases)에 대한 코드 건강도 (code health) 분석 결과, AI 코딩 어시스턴트는 특히 이미 코드 건강도가 낮은 프로젝트에서 결함 위험 (defect risk)을 유의미한 수준으로 증가시킨다는 사실이 발견되었습니다. 즉, AI가 첫 번째 문제를 일으키는 것이 아니라, 이미 존재하는 패턴이 무엇이든 간에 그것을 가속화한다는 의미입니다. 깨끗하고 잘 구조화된 코드베이스는 AI의 도움을 받아도 더 오랫동안 그 상태를 유지하는 경향이 있습니다. 반면 지저분한 코드베이스는 더 빠르게 저하되는데, 이는 도구가 파일에 이미 존재하는 내용(불일치 포함)을 바탕으로 패턴 매칭 (pattern-matching)을 수행하기 때문입니다.

이는 직관에 반하는 통제 연구에서 발견된 바와 일치합니다. 실제 작업을 수행하는 AI 코딩 도구를 사용하는 숙련된 개발자들은 이 도구가 훨씬 빠를 것이라고 미리 예측했음에도 불구하고, 실제로 사용하지 않는 개발자들보다 측정 가능하게 느렸습니다. 기대 속도와 실제 속도의 간격이야말로 바로 '복잡성의 벽(complexity wall)'이 존재하는 지점입니다. 도구는 첫 주에는 코드가 작고 깔끔하기 때문에 빠르게 느껴집니다. 하지만 6주가 지나면, 같은 도구가 사용하지 않을 때보다 더 느려지는데, 이는 이제 빈 공간을 탐색하는 것이 아니라 누적된 불일치성(inconsistency)을 헤쳐나가야 하기 때문입니다.

왜 이런 불일치성이 특히 AI 지원 코딩에서 축적될까요? 생성되는 모든 변경 사항은 그 자체로 작은 의사결정들을 도입하는 경향이 있습니다. 예를 들어, 5개 파일 떨어진 함수와 약간 다른 방식으로 인증을 확인하거나, 이미 존재하는 유틸리티를 중복하는 새로운 유틸리티를 만들거나, 작동하지만 앱의 나머지 부분이 사용하는 패턴을 무시하는 데이터베이스 쿼리 등이 그렇습니다. 이들 중 어느 것도 개별적으로 버그는 아닙니다. 하지만 이것들이 복합적으로 작용합니다. 체계적인 검토 프로세스 없이 팀원이나 단독 창업자가 비디오 코딩(vibe-coding)을 하는 것은, 그 워크플로우의 본질상 매 프롬프트마다 정확히 이런 종류의 부채를 축적하고 있습니다. 그리고 인간 팀에서 발생하는 부채와 달리, AI는 코드를 작성한 사람처럼 코드베이스 전체를 기억하지 못하기 때문에 '잠깐, 우리 이거 이미 만들지 않았나?'라는 본능적인 순간이 없습니다.

이 사실을 구체적으로 보여준 보안 사고
이 장벽에 최악의 순간에 부딪힌 가장 명확한 공개 사례는, 창업자가 스스로 코드를 한 줄도 작성하지 않았다고 공개적으로 밝히며 출시한 AI 에이전트용 소셜 플랫폼에서 발생했습니다. 출시 3일 후, 보안 연구원들은 100만 개 이상의 인증 토큰(authentication tokens), 수만 개의 이메일 주소, 그리고 평문 자격 증명(plaintext credentials)이 포함된 개인 메시지가 모두 노출된 것을 발견했습니다. 지나고 보니 근본 원인은 코믹할 정도로 단순했습니다. 데이터베이스 액세스 키(database access key)가 클라이언트 측 JavaScript에 직접 노출되어 있어 개발자 도구(developer tools)를 여는 누구에게나 보였고, 키가 유출되더라도 한 사용자가 다른 사용자의 데이터를 읽는 것을 막았어야 할 데이터베이스의 행 수준 권한 시스템(row-level permission system)이 활성화되어 있지 않았던 것입니다.

이와 별개로, 몇몇 인기 있는 AI 코딩 도구들을 소수의 샘플 애플리케이션을 대상으로 테스트한 보안 평가에서는 총 수십 개의 취약점이 발견되었습니다. 그중 상당수는 '높음(high)' 또는 '심각(critical)' 등급으로 분류되었으며, 노출된 자격 증명(credentials)과 브라우저 검사기(browser inspector)를 여는 누구라도 우회할 수 있는 클라이언트 측 로직(client-side logic) 등이 포함되었습니다. 이 중 그 어떤 것도 정교한 공격자를 필요로 하지 않습니다. 단지 확인해야 할 곳을 아는 사람만 있으면 되는데, 이것이 바로 존재하는 격차입니다.

장벽이 실제로 존재하는 위치
창업자들의 글과 감사(audit) 결과에 나타난 패턴을 바탕으로 볼 때, 이 장벽은 특정 시점에 나타나는 경향이 있습니다. 바로 실제 사용자 수가 50명에서 500명 사이일 때입니다. 이 시점은 제품 사용량이 늘어나면서 단독 테스트 시에는 절대 나타나지 않았던 엣지 케이스(edge cases)들이 매일 발생하기 시작하는 때입니다. 예를 들어 동일한 행(row)에 대한 동시 쓰기(concurrent writes), 두 번 실행되는 웹훅(webhook), 주소창의 숫자를 변경하여 다른 사람의 데이터 URL 패턴을 찾아내는 사용자 등이 발생합니다. 그 이전 단계에서는 보통 창업자가 유일한 헤비 유저이며, 시스템에 부하를 주는 일이 거의 없기 때문에 거의 모든 것이 제대로 작동합니다. 하지만 그 지점을 지나면, "진짜 앱처럼 보이는 것"과 "진짜 앱처럼 구축된 것" 사이의 격차를 무시하는 것이 불가능해집니다.

이것은 우연이 아닙니다. AI 도구 사용 데이터를 살펴보면, 몇몇 인기 있는 AI 코딩 도구들의 트래픽이 초기 정점을 찍은 후 급격히 감소하는 현상이 나타나는데, 창업자들은 바로 이러한 복잡성의 한계(complexity ceiling)를 자신들이 정체되거나 외부의 도움을 구하게 된 이유로 꼽았습니다.

무엇이 실제로 이를 방해하는가
"AI 도구를 사용하지 마라"는 말은 2026년에는 진지한 답변이 될 수 없으며, 도구를 피하는 것은 그저 대가 없이 속도만을 포기하는 것일 뿐입니다. 벽을 피하거나 깔끔하게 통과하는 창업자들에게서 나타나는 패턴은 몇 가지 습관으로 요약됩니다:

• 프롬프트(prompt)를 입력하기 전의 계획: 코드를 생성하기 전에 도구에게 접근 방식을 개략적으로 설명하거나 API 계약(API contract)을 작성하도록 요청한 뒤, 그 계획을 검토하고 수정하는 과정은 코드가 작성되기 전에 불일치(inconsistency)의 상당 부분을 잡아냅니다. 이는 초기에 몇 분의 시간을 소요하지만, 나중에 훨씬 더 많은 시간을 절약해 줍니다.
• 실제 사용자가 유입된 후가 아닌, 그 전의 보안 점검: 행 수준 보안 (Row Level Security, RLS), 웹훅 검증 (webhook verification), 속도 제한 (rate limiting), 그리고 노출된 키(exposed keys) 확인 등은 위에서 언급한 침해 사고의 정확한 실패 모드(failure modes)를 잡아낼 수 있는 몇 시간의 집중적인 작업입니다. 실제 사용자 데이터가 이미 테이블에 들어있는 출시 후에 이를 수행하는 것은, 하기 전에 수행하는 것보다 범주적으로 훨씬 더 큰 작업이 됩니다.
• 변곡점에서의 숙련된 리뷰어 한 명: 반드시 풀타임 채용일 필요는 없지만, 이전에 프로덕션 수준의 SaaS를 출시해 본 경험이 있는 사람을 두어, 혼자 하는 테스트에서는 나타나지 않는 패턴들을 구체적으로 찾아내도록 해야 합니다.

벽에 가장 세게 부딪히는 창업자들은 AI 도구를 가장 많이 사용한 사람들이 아닙니다. 그들은 트래픽을 확장하기 전에 기반(foundation)을 점검할 사람을 단 한 번도 두지 않았던 사람들입니다. 벽은 속도를 늦춰야 할 이유가 아닙니다. 그것은 무게를 싣기 전에 바닥이 정확히 어디인지 알아야 할 이유입니다.

저는 비기술직 창업자들을 위해 프로덕션 수준의 SaaS MVP를 구축하고 감사(audit)합니다. 고정 가격제로 14일에서 21일이 소요되며, 침해 사고 후에 덧붙이는 방식이 아닌 첫날부터 보안 및 아키텍처 점검이 포함되어 있습니다. themvpguy.vercel.app/pricing