AI가 32시간 만에 지은 집, 누구나 본 것처럼 똑같이 생긴 이유

AI가 32시간 만에 지은 집, 누구나 본 것처럼 똑같이 생긴 이유

빠르게 만드는 것과 제대로 된 것을 만드는 것—Claude Code 32시간 빌드 경험이 드러낸 AI 워크플로우의 진짜 구멍

Claude Code AI 워크플로우 디자인 의사결정 컨텍스트 설계 SaaS 검증 프로덕트 사고 AI 코딩 에이전트
광고

'AI로 웹사이트를 10분 만에 뚝딱.' 유튜브 썸네일과 트위터 스레드가 약속하는 세계다. 그런데 실제로 Claude Code를 붙들고 프로덕션 웹사이트를 완성하기까지 32시간이 걸렸다는 고백이 dev.to에 올라왔다. 8번의 세션, 30개 이상의 커밋, 9개 페이지. 그리고 SVG 좌표계와 CSS 트랜스폼이 서로 다른 수학적 우주에서 작동한다는 사실을 백팩 아이콘 기울기 문제로 처음 깨닫는 순간까지.

이 이야기에서 가장 인상적인 장면은 버그 목록이 아니다. 디자인 의사결정에만 첫 3시간을 통째로 썼다는 대목이다. 코딩이 아니라 '어떤 파란색인가'를 고르는 데 3시간. AI는 5가지 배경 옵션을 초 단위로 렌더링했지만, 인간은 여전히 20분을 들여 눈을 가늘게 뜨고 비교하고 마음을 바꿔야 했다. 데모 영상에서 이 장면이 편집되는 이유는 간단하다—촬영이 시작되기 전에 이미 끝나 있기 때문이다.

더 날카로운 통찰은 '옵션의 중립성'에 관한 것이다. Claude에게 크립토 대시보드에 어울리는 파란색 5가지를 요청하면, 돌아오는 팔레트는 모델이 학습한 수천 개의 크립토 대시보드에서 추출된 분포 위에 있다. 사용자가 내리는 '선택'은 사실 이미 필터링된 범위 안에서의 선택이다. 같은 모델에게 같은 질문을 던지는 다른 팀도 동일한 범위 안에서 고른다. 결과? 어두운 배경, 모노스페이스 폰트, 카드 레이아웃—런칭 몇 주 후 발견한 다른 AI 빌드 크립토 프로젝트와 구별하기 어려운 사이트. 두 팀이 각자 '인간적인 선택'을 했는데 결과물이 하나였다.

이것이 단순한 미적 문제가 아닌 이유가 있다. AI는 '생성'에 최적화되어 있지 '보존'에 최적화되어 있지 않다. 이미 승인된 컴포넌트를 보여주면 AI의 첫 번째 본능은 '더 좋게 개선하는 것'이다. 실제로 이 프로젝트에서 Claude Code는 공들여 만든 봇 카드 4개를 '디자인 시스템에 맞게 개선'하겠다며 통째로 재설계했다. 창의적 재설계에 1시간이 낭비됐고, 원본 그대로 포팅하는 데는 20분이 걸렸다. '더 나은 것'이 '이미 검증된 것'을 이길 수 없다는 교훈—이것도 두 번 이상 다시 배워야 했다.

가장 구조적인 문제는 메모리다. 6번째 세션에서 Claude Code는 이전 세션에서 자신이 직접 구축한 홈페이지, 대시보드, 다이어리 페이지의 시각적 규칙을 전혀 기억하지 못한 채 새 페이지를 백지에서 설계했다. 컨테이너 너비가 달랐고, 섹션 헤더 스타일이 달랐고, 완전히 다른 시각 언어가 등장했다. 공동창업자의 반응—"이전 세션의 누군가가 페이지 레이아웃 규칙을 적어두지 않은 게 가능한 일이냐"—은 절망이자 정확한 진단이었다. 해결책은 696줄짜리 스타일 가이드였다. 전문적이어서가 아니라, 기억이 없는 코더를 위한 보철 메모리가 필요했기 때문에.

이 경험을 다른 축에서 바라보면, 'SaaS를 먼저 빌드했다가 실패했다'는 또 다른 고백과 겹쳐 읽힌다. dev.to의 또 다른 글에서 저자는 배포 채널 없이 제품을 먼저 만들었다가 아무도 쓰지 않는 결과를 맞이한 과정을 털어놓는다. 그의 결론은 '서비스 먼저, 배포 채널 둘째, 제품 셋째'—코드를 짜기 전에 실제 고객의 워크플로우에 먼저 들어가야 한다는 것이다. AI가 코드를 짜주는 시대에도 '무엇을 만들 것인가'를 결정하는 과정은 여전히 인간의 몫이라는 점에서 두 이야기는 같은 곳을 가리킨다.

둘을 합치면 하나의 패턴이 보인다. AI 빌드 워크플로우에서 병목은 코드 생성 속도가 아니다. 병목은 세 곳에 있다. 첫째, 취향과 판단이 필요한 디자인 의사결정—AI가 옵션을 순식간에 만들어도 선택은 여전히 느리다. 둘째, 세션 간 컨텍스트 유지—AI는 이전 세션을 기억하지 못하므로 누군가 설계해서 문서화해야 한다. 셋째, '무엇을 만들 것인가'에 대한 검증—빠르게 만들수록 잘못된 방향으로 가속할 위험이 커진다.

결국 AI 코딩 도구를 둘러싼 가장 큰 오해는 '속도'를 '방향'과 동일시하는 것이다. Claude Code는 30개의 커밋을 빠르게 쌓아 올렸지만, 그 속도가 의미 있으려면 각 세션마다 인간이 방향을 점검하고, 규칙을 문서화하고, AI의 창의적 본능에 '아니오'를 말할 수 있어야 했다. 696줄의 스타일 가이드를 쓰고 난 뒤 다음 페이지 승인에 5분이 걸렸다는 결말은 시사적이다—AI 워크플로우의 ROI는 도구의 성능이 아니라 컨텍스트 설계의 품질에서 나온다.

앞으로의 질문은 '어떤 AI 도구를 쓸 것인가'가 아니다. '어떤 컨텍스트를 먼저 설계할 것인가', '어디서 AI의 제안에 저항할 것인가', 그리고 '빠르게 만들기 전에 무엇을 검증했는가'다. 모두가 같은 모델에게 같은 질문을 하는 시대에, 차별화는 프롬프트의 영리함이 아니라 AI가 대답하기 전에 인간이 먼저 내리는 판단에서 시작된다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요