주말 안에 앱을 만들어 배포하는 것, 이제 진짜로 가능하다. Lovable, Cursor, Bolt 같은 Vibe Coding 도구들은 '자연어로 설명하면 AI가 코드를 쓴다'는 약속을 현실로 만들었다. Inithouse의 실전 사례처럼, 첫 번째 프롬프트만으로 원하는 결과의 70~80%를 얻는 경험은 분명 짜릿하다. 문제는 그다음이다.
빠르게 만든다는 것과 잘 만든다는 것은 다른 문제다. Vibe Coding의 진짜 가치는 '주말 배포'가 아니라 그 배포를 통해 사용자 반응을 빠르게 검증하고, 그 위에 제대로 된 시스템을 쌓아 올리는 흐름에 있다. 그런데 대부분의 논의는 '어떻게 만드느냐'에서 멈춘다. '그 이후를 어떻게 유지하느냐'는 거의 다뤄지지 않는다.
AI가 새로운 추상화 계층이 됐다는 말의 진짜 의미
벨로그에 올라온 'AI 시대의 프로그래머' 분석은 이 지점을 정면으로 다룬다. AI는 기계어 위에 어셈블리가, 어셈블리 위에 객체지향이 쌓였던 것처럼, 코드 작성이라는 행위 위에 얹힌 새로운 추상화 계층이다. 하지만 추상화가 늘어날수록 그 아래 계층의 복잡성이 사라지는 게 아니라 감춰진다는 점을 잊으면 안 된다.
AI가 닉네임 수정 기능을 뚝딱 만들어줘도, '빈 문자열을 허용할지', '네트워크 오류 시 어떻게 처리할지', '수정 도중 화면을 벗어나면 어떻게 되는지'—이 디테일들은 여전히 개발자가 정의해야 한다. 오히려 구현 비용이 낮아질수록, 생성된 코드를 조립하고 검증하는 비용의 중요성이 커진다. 빠른 생성이 검증의 필요성을 없애주지 않는다.
비결정성이라는 조용한 위험
전통적인 코드는 같은 입력에 같은 출력을 돌려준다. AI는 그렇지 않다. 같은 프롬프트도 오늘과 내일의 결과가 다를 수 있고, 대규모 리팩터링을 요청했을 때 기능이 살아있어 보여도 삭제된 코드가 정말 불필요했는지, 새로운 부작용이 숨어있지는 않은지—이 판단은 AI가 대신해주지 않는다. 그래서 앞선 분석이 강조하는 개념이 '하네스'다. 컴파일러, 타입 검사기, 자동화 테스트, 린터, 검증 게이트—비결정적인 AI의 출력을 결정적인 도구로 붙잡는 인프라가 없으면, 빠른 코드 생성은 빠른 오류 누적으로 이어진다.
맥락은 저절로 유지되지 않는다: Claude Code 메모리 운용의 교훈
dev.to에 공개된 Claude Code 60개 이상의 메모리 엔트리 운용 실전기는 이 문제를 더 구체적으로 드러낸다. 혼자 인프라 서비스를 운영하면서 쌓은 교훈의 핵심은 단순하다. '무엇을 했는지'가 아니라 '왜 그렇게 했는지'를 기록해야 한다는 것. systemd로 전환했다는 기록은 git 로그로도 알 수 있다. 이 VPS 공급사는 타 테넌트의 워크로드로 OOM killer가 발생해서 컨테이너가 죽는다, 그래서 systemd 프로세스로 운영한다—이 한 줄이 세 번의 재구축을 막는다.
AI 에이전트와 협업할수록 맥락 관리는 점점 더 중요한 설계 문제가 된다. 메모리가 썩는다는 표현이 정확하다. 6개월 전에 기록한 파일 경로가 이미 삭제된 파일을 가리키고 있으면, 그 메모리는 도움이 되는 게 아니라 에이전트를 오염시킨다. 주기적으로 감사하되, 실효성 있는 방법은 '읽는 순간 즉시 판단'이다. 맞으면 두고, 틀리면 그 자리에서 수정하거나 삭제한다. 메모리는 백업이 아니라 살아있는 의존성이다.
또 하나의 반직관적인 통찰: 메모리 인덱스의 한 줄 설명이 파일 본문보다 더 중요하다. AI 에이전트는 인덱스를 먼저 읽고, 그 설명을 바탕으로 파일을 열지 말지 결정한다. webhook stuff라고 적힌 항목은 열리지 않는다. Stripe webhook 재처리 시 idempotency-key 충돌 vs event_id 재사용 판단 기준이라고 적힌 항목은 정확한 타이밍에 열린다. 검색 가능성 설계가 곧 컨텍스트 설계다.
개발자 역할의 재정의: 코드를 쓰는 사람에서 AI를 조율하는 시스템 설계자로
이 세 흐름이 가리키는 결론은 하나다. AI 코딩 도구의 시대에 개발자가 잃어버리는 것은 타이핑 업무가 아니라, 그 타이핑을 통해 자연스럽게 행사하던 '판단의 기회'다. 코드를 직접 쓸 때는 디테일을 채우는 과정 자체가 설계였다. AI가 코드를 쓰면 그 과정이 블랙박스 안으로 들어가고, 개발자는 결과물만 받아든다.
그렇기 때문에 판단을 구조화하는 것이 더 중요해진다. 프롬프트에 '어떻게 구현할지'가 아니라 '왜 필요한지, 무엇을 달성해야 하는지, 변경해서는 안 되는 제약이 무엇인지'를 담아야 한다. 작업을 명세 → 테스트 → 구현 → 리팩터링 → 검증으로 분리하고, 각 단계에서 AI에게 요구하는 산출물을 하나로 제한해야 한다. 마크다운으로 정리된 SKILL.md나 메모리 엔트리는 단순한 문서가 아니라 AI의 행동을 결정하는 실행 규칙이다.
전망: Vibe Coding 이후의 진짜 경쟁력
Vibe Coding 워크플로우가 성숙해질수록, '빠르게 만드는 능력'은 점점 더 범용 자원이 된다. 경쟁 우위는 그 이후에 결정된다. 생성된 코드를 검증하는 하네스를 얼마나 촘촘하게 설계했는지, 맥락을 얼마나 정교하게 유지하고 있는지, AI에게 위임한 판단의 경계를 얼마나 명확하게 그었는지—이 세 가지가 주말에 배포한 앱이 실제 제품으로 성장할 수 있느냐를 결정한다.
주말 배포는 시작이다. 진짜 설계는 그 이후부터다.