AI로 만든 앱 관리하기: 둘째 주에 대해 아무도 말해 주지 않는 것
Proyecta와 함께한 첫 주말, 당신은 진짜 무언가를 출시합니다. 작동합니다. 당신의 사용자(혹은 팀, 혹은 미래의 당신)가 쓰기 시작합니다. 그러고는 월요일이 되고 고객이 이메일을 보냅니다. “지역으로 필터링하는 드롭다운 좀 추가해 줄 수 있나요?”
유지보수의 세계에 오신 걸 환영합니다. 이건 AI 앱을 만드는 일에서 아무도 이야기하지 않는 부분이고, 대부분의 프로젝트가 오래가는 자산이 되느냐 조용히 절벽 아래로 떨어지느냐가 갈리는 부분입니다. 좋은 소식은, AI로 만든 앱을 관리하는 일이 전통적인 코드를 관리하는 일과는 다른 경험이라는 것입니다. 솔직한 소식은, “다르다”가 “공짜”라는 뜻은 아니라는 것입니다.
유지보수가 실제로 의미하는 것
전문 개발자가 “유지보수”라고 말할 때, 그들은 대략 네 가지를 뜻합니다.
- 출시 후 사람들이 부탁하는 작은 기능 추가하기.
- 망가졌거나 처음부터 잘못된 것을 고치기.
- 앱 바깥의 변화에 발맞추기 — 결제 제공업체가 API를 업데이트하거나, 새 브라우저가 나오거나, 데이터 형태가 바뀌거나.
- 코드베이스가 서서히 늪으로 변하지 않게 정리하기.
AI로 만든 앱에서도 이 넷은 여전히 일어납니다. 달라지는 것은 누가 그것들을 하느냐, 그리고 그 일이 어떻게 느껴지느냐입니다.
좋은 소식: 말을 걸 수 있다
낡은 튜토리얼에서 코드를 복사·붙여넣기 하던 시절 아무도 알려 주지 않은 부분이 여기 있습니다. AI 앱 빌더로는, 만들 때와 똑같은 방식으로 앱을 관리합니다. 원하는 것을 설명하는 방식으로요.
실제 사례입니다. 우리가 아는 한 창업자는 자신의 코칭 사업을 위한 작은 CRM을 만들었습니다 — 고객, 세션, 결제 추적, 전부 다요. 출시 3주 뒤, 한 고객이 올해 자기가 몇 세션을 했는지 보고 싶다고 말했습니다. 그녀는 앱을 열고 말했습니다. “각 고객 카드에 ‘올해 세션 수’ 카운터를 추가해 줘. 날짜가 2026년인 세션 테이블에서 가져와서.” 12분 뒤, 라이브가 됐습니다. 그녀는 다시 코칭으로 돌아갔습니다.
이 이야기는 대안을 떠올리기 전까지는 평범하게 들립니다. 프리랜서에게 연락하고, 이틀을 기다리고, 300달러를 내고, 자기가 완전히 이해하지도 못하는 PR을 검토하고, 다른 게 망가지지 않기를 기도하는 것. 유지보수 루프가 빨라진 건 AI가 프리랜서보다 똑똑해서가 아닙니다. 루프 안에 사람이 더 적어서 빨라진 겁니다.
더 어려운 소식: 작은 것들이 쌓인다
사람들이 걸려 넘어지는 부분이 여기 있습니다. AI로 만든 앱은 무언가를 더하기가 쉬워서 바꾸기 쉬워 보입니다. 쉽지 않은 건 앱이 커지는 동안 전체를 일관되게 유지하는 일입니다.
우리가 잘못되는 걸 보는 몇 가지 패턴입니다.
- 우발적인 엉킴. “결제에 할인 칸 추가해 줘”라고 부탁합니다. 여섯 번의 수정 뒤, 할인 로직이 세 군데에 흩어져 있고, 그중 맞는 건 하나뿐입니다. 아직 망가진 건 없지만, 다음 변경은 혼란스러울 겁니다.
- 잊힌 요구사항. 3월에 “50달러 이상 무료 배송”을 추가했습니다. 5월에 AI에게 “기프트 카드를 지원하도록 결제를 다시 해 줘”라고 합니다. AI가 합니다. 무료 배송 규칙이 사라졌습니다. 2주 동안 아무도 알아채지 못했습니다.
- 표류. 당신의 앱은 “나를 위한 도구”로 시작했습니다. 이제는 팀이 씁니다. AI가 작업하는 머릿속 모델은 여전히 “나를 위한” 것입니다 — 당신이 처음에 그렇게 말했으니까요. 새 기능이 묘하게 어긋난 느낌이 드는데, 왜인지 콕 짚을 수가 없습니다.
이 중 어느 것도 AI 앱 빌더의 실패가 아닙니다. 기억과 공유된 맥락의 실패입니다 — 사람 개발자 팀이 겪는 것과 똑같은 문제가, 다른 모양으로 나타나는 것뿐이죠.
스스로를 세팅하는 법
유지보수를 잘 해내는 팀들은 몇 가지 습관을 공유합니다. 대부분 기술적인 습관이 아닙니다. 앱이 무엇인지, 그리고 무엇이 바뀌었는지를 어떻게 설명하느냐에 관한 습관입니다.
“이 앱이 무엇인지” 문서를 두세요. 한 페이지로요. 청중, 목표, 규칙(“50달러 이상 무료 배송”, “일요일에는 사용자에게 절대 이메일을 보내지 않는다”, “기본 키는 이메일이 아니라 전화번호다”). AI에게 무언가를 바꿔 달라고 할 때, 해당 규칙을 프롬프트에 붙여넣으세요. AI의 지능을 우회하는 게 아니라, AI가 도저히 기억할 수 없는 맥락을 먹여 주는 겁니다.
변경을 코드가 아니라 동작으로 설명하세요. “사용자가 세션이 바뀌어도 지역 필터가 기억되는 걸 봤으면 좋겠어”가 “필터에 localStorage 추가해”보다 훨씬 나은 요청입니다. 앞의 것은 원하는 바를 설명하고, 뒤의 것은 열다섯 가지 방법 중 하나를 — 그것도 아마 최선이 아닌 것을 — 처방합니다.
한 번에 하나씩 바꾸세요. 한 프롬프트에 두 가지 변경을 넣으면 하나가 조용히 실패해도 어느 쪽인지 알 수 없습니다. AI 앱을 관리하는 가장 빠른 길은, 결과가 맞는지 한눈에 알아챌 수 있을 만큼 반복을 작게 유지하는 것입니다.
무엇이 바뀌었는지 보세요. 대부분의 AI 앱 빌더는 미리보기를 보여 줍니다. 쓰세요. 새 기능이 작동하는지 그리고 옛 기능들이 여전히 작동하는지 확인하려고 이리저리 클릭하며 쓰는 30초는, 올해 사게 될 가장 싼 보험입니다.
할 수 없는 것 (그리고 아마 하지 말아야 할 것)
AI로 앱을 만들고 나면, AI가 앱을 운영까지 해 줄 수 있다고 생각하고 싶은 유혹이 있습니다. 그럴 수 없고, 그 간극은 진짜입니다.
- 무언가가 조용히 망가졌을 때 알려 주지 않습니다. 로그, 모니터링, 온콜 당번 — 그건 여전히 별개의 관심사입니다. 대부분의 AI 앱 빌더는 백엔드 엔지니어처럼 당신의 프로덕션 앱을 지켜보지 않습니다.
- 앱 바깥 세상에 대해서는 모릅니다. 결제 제공업체가 API를 지원 중단하면, AI는 당신이 말해 주기 전까지 모릅니다. 제공업체의 변경 로그를 구독하세요. 이메일을 읽으세요.
- 제품 결정을 대신 내려 주지 못합니다. 기능을 추가할지, 어떤 트레이드오프를 택할지, 사용자가 진짜로 무엇을 원하는지 — 그건 여전히 당신입니다. AI는 아주 빠른 손이고, 두뇌는 당신입니다.
현실적인 그림
AI로 만든 앱과 6개월을 보낸 뒤, 우리가 이야기 나눈 대부분의 사람은 대략 이쯤에 도착합니다. 변경에 한 달에 두세 시간에서 네 시간쯤 쓰는데, 거의 전부가 대화로 이루어집니다. 예전에는 두려워하던 큰 재구축 — “섹션을 통째로 새로 추가하고 싶어” — 이 좋은 오후 한나절처럼 느껴집니다. 지루한 일 — “내보내기에서 날짜 형식이 틀렸어” — 은 좋은 프롬프트 하나처럼 느껴집니다.
그들에게 없는 것은 전통적인 코드베이스의 끊임없는 배경 잡음입니다. 의존성 업데이트, 프레임워크 마이그레이션, 보안 패치, 빌드 설정. 그 잡음은 플랫폼이 흡수했습니다. 당신은 플랫폼이 그걸 처리하도록 비용을 내는 것인데, 개발자에게 처리를 맡기느라 비용을 내는 것보다 훨씬 나은 거래입니다.
첫 앱을 막 만들려는 참이라면, 시작하기 전에 첫 AI 앱은 무엇이어야 하는가에 관한 글을 읽어 둘 가치가 있습니다. 그리고 이미 몇 주가 지나 위의 패턴 일부를 느끼고 있다면, 그건 정상입니다. 이번 주말에 “이 앱이 무엇인지” 문서를 쓰세요. 석 달 뒤에 새 대시보드를 부탁하게 될 미래의 당신이, 그렇게 해 둔 걸 무척 고마워할 겁니다.