Your Vibe-Coded App Works. Is It Any Good?
TL;DR - Getting an app to run is now the easy part. AI is very good at producing something that...
TL;DR — 앱을 실행시키는 건 이제 쉬운 부분이 됐다. AI는 첫 시도에서 돌아가는 무언가를 만드는 데 능숙하지만, 그걸 출시해도 되는지는 전혀 신경 쓰지 않는다. 소프트웨어를 그냥 만드는 사람과 실제로 세상에 내보내는 사람을 가르는 기술은 데모 이후의 작업에서 시작된다 — 의도한 대로 작동하는지 확인하고, 누군가의 데이터가 노출되지 않았는지 점검하고, 만든 사람이 어떻게 돌아가는지 설명할 수 있는지 확인하는 것. 먼저 만들고, 그 다음 감사하라. AI가 만든 앱을 감사하는 가장 빠른 방법은 그 앱을 만든 AI를 심문자로 돌려쓰고, 지금까지 깨진 것들의 목록을 계속 관리하는 것이다.
앱이 실행된다. 데모가 작동한다. 친구에게 보낼 수 있는 실제 URL에 배포됐다. AI로 처음 무언가를 만드는 사람 대부분에게 이것이 결승선처럼 느껴진다. 하지만 현실에서는 절반 지점에 가깝다.
"작동한다"와 "좋다"는 두 가지 다른 질문이고 두 가지 다른 기준으로 답해야 한다. 현대 AI 에이전트는 첫 번째 질문에 놀라울 정도로 능숙하다. 원하는 걸 설명하면 첫 시도에서 돌아가는 무언가를 만들어낸다. 그게 좋은지 — 보안이 되어 있는지, 데모용이 아닌 실제 의도한 동작을 하는지, 만든 사람이 아닌 다른 사람이 써도 버텨내는지 — 는 AI 에이전트가 훨씬 덜 믿을 수 있는 별개의 질문이다. 그 질문이 진짜 작업과 진짜 배움이 있는 지점이다.
이건 첫 번째 바이브코딩(vibe coding, AI와 대화하듯 소통하며 앱을 만드는 방식) 프로젝트 이후의 자연스러운 다음 단계다. 빌딩은 끝났다. 이제 만들어진 것으로 무엇을 해야 하는지 살펴보자.
AI는 벽돌을 만든다. 집은 여전히 누군가가 짓는다. #
AI가 이 과정에서 무엇을 하고 무엇을 하지 않는지를 이렇게 정리할 수 있다 — AI는 완성된 구조가 아닌 원재료를 생산한다. 에이전트는 몇 초 안에 작동하는 코드를 만들어낼 수 있다. 그 코드가 실제 사람들이 쓸 것에 속하는지는 판단의 문제이고, 그 판단은 모델이 아닌 사람에게 있어야 한다.
업계 전체가 계속 맴도는 문제이기도 하다. 초보자와 소프트웨어 창작자, 그리고 생산적인 개발자 사이의 거리는 이보다 좁았던 적이 없다. 하지만 그 중간에 있던 전문성의 층 — 개발자가 팀에서 실제 문제와 씨름하며 "좋음"이 어떻게 생겼는지 천천히 익히는 데 보낸 세월 — 은 AI가 여정의 초반부를 압축할수록 얻기가 더 어려워졌다. 소프트웨어 창작자에게 희소식은 이 격차가 걱정만 할 것이 아니라는 점이다. 행동할 수 있고, 그 행동은 만든 것을 감사하는 것에서 시작하며, 첫 번째 프로젝트에서 바로 시작할 수 있다.
아무도 경고하지 않는 소프트웨어 창작의 한 부분 #
빠를수록 노출될 수 있다. 오후 한나절에 만든 앱이 라이브로 올라가고, 몇 시간 내에 사용자가 건넨 모든 데이터를 유출할 수 있다.
가상의 이야기가 아니다.
초보자가 만든 앱이 데이터베이스를 기본값으로 완전히 열어둔 채, 인증이 필요한 엔드포인트에 인증 없이, 비밀 키를 공개 코드에 직접 커밋한 상태로 프로덕션에 올라간 사례가 있다. 실행됐으니 빌드가 완성된 것처럼 느껴졌다. 빠진 부분은 보이지 않다가 갑자기 드러났다.
이런 일이 자주 일어나는 이유는 구조적이다. AI가 설정과 보일러플레이트를 처리할 때 천천히 만드는 사람이라면 적어도 한번은 지나쳤을 수백 가지 작은 결정도 조용히 처리해버린다. 그 결정들 중 일부는 보안에 관한 것이다. 대부분의 기본값은 작동하게 만들기 위해 설계됐지 안전하게 만들기 위해 설계된 게 아니며, "작동"과 "안전"은 같은 기본값이 아니다. 근본적인 개념을 배운 적 없는 소프트웨어 창작자는 뭐가 잘못됐는지, 어디를 봐야 하는지, 다음에 뭘 물어야 하는지 모를 수 있다. 하지만 감사를 작업의 일부로 여기면 다른 누군가가 발견하기 전에 잡을 기회가 생긴다.
방법: 먼저 만들고, 그 다음 감사하라 #
"감사"는 선임 엔지니어의 단어처럼 들리고 체크리스트와 컴플라이언스 담당자가 있는 회의실 얘기처럼 느껴진다. 첫 번째 프로젝트에서는 그보다 훨씬 작고 훨씬 유용하다. 이미 존재하는 것에 대해 물어볼 짧은 질문들의 집합이다. 그 질문들이 바로 기술 그 자체다.
Photo by Myburgh Roux on Pexels
- 의도한 대로 하는가, 아니면 데모한 것만 하는가? 데모는 해피 패스를 실행한다 — 올바른 입력, 예상한 클릭, 연습한 하나의 흐름. 실제 사용은 더 지저분하다.
- 빈 필드, 잘못된 파일 형식, 두 번 눌린 버튼에 어떤 일이 일어나는가?
- 누군가의 데이터가 공개적으로 노출되어 있는가? 앱이 무언가를 저장한다면 — 이메일 주소, 로그인, 업로드된 사진 한 장 — 누가 거기에 접근할 수 있는지가 문제다. 낯선 사람이 데이터베이스를 읽을 수 있는가?
- 코드 자체에 민감한 정보가 직접 박혀 있는가?
- 다른 사람에게 빌드를 설명할 수 있는가? 줄 단위가 아니라 평이한 말로 — 움직이는 부품이 무엇이고 각각 무엇을 하는가? 솔직한 "아니오"는 실패가 아니다. 오히려 새 빌더가 찾을 수 있는 가장 유용한 신호인데, 다음에 무엇을 배워야 하는지 정확히 가리키기 때문이다.
- AI가 조용히 건너뛴 것은 무엇인가? 모든 에이전트는 "실행된다"에 도달하기 위해 트레이드오프를 한다. 오류 처리, 유효성 검사, 첫 번째 초안을 늦출 보안 관행 — 이것들이 빠질 가능성이 가장 높고 직접 물어볼 가치가 있다.
- 한 사람만 쓰는 게 아닐 때 어떤 일이 일어나는가? 혼자 만들고 혼자 테스트한 앱은 열 명, 또는 만 명이 한꺼번에 몰릴 때 다르게 작동한다. 그 변화를 상상하는 것만으로도 솔로 데모에서는 절대 드러나지 않았을 문제들이 보이기 시작한다.
이 중 어느 것도 미리 답을 알아야 하는 게 아니다. 물어볼 줄 알기만 하면 된다. 그리고 답을 얻는 가장 효율적인 방법은 처음에 코드를 짠 같은 도구에게 묻는 것이다.
AI로 AI를 감사하기 #
AI 에이전트를 쓸 때 가장 흔한 실수는 단순 실행자로 취급하는 것 — 무엇을 만들지 말하고 돌아오는 결과를 그냥 받아들이는 것이다. 코치로 쓰면 같은 도구가 지금껏 나온 것 중 최고의 학습 방법 중 하나가 된다. 그 방식은 빌딩만큼이나 검토에도 잘 맞는다. 요령은 에이전트를 자신의 출력물로 되돌려 비판적으로 보도록 시키는 것이다.
이 프롬프트들이 대부분의 일을 해낸다:
- "이 코드를 줄별로 살펴보고 각 부분이 무엇을 하는지 설명해줘."
- "이걸 작동시키기 위해 어떤 보안 관행을 건너뛰었어?"
- "실제 사람들이 쓰기 전에 무엇을 바꾸겠어?"
- "사용자 데이터는 어디에 저장되고, 지금 누가 그것에 접근할 수 있어?"
- "선임 엔지니어라면 이 코드에서 무엇을 지적할까?"
답변은 두 가지를 동시에 해낸다. 수정할 구체적인 문제를 드러내고 그 문제의 배경에 있는 개념을 맥락 속에서 가르쳐준다. 데이터베이스 연결이 왜 안전하지 않은지에 대한 설명을 읽는 새 빌더는 자신이 만들고 신경 쓰는 것에 연결된 교훈이기 때문에 일주일간의 추상적인 튜토리얼보다 5분 안에 보안에 대해 더 많이 배운다.
이게 코치와 목발의 차이다. AI에게 코드가 왜 그렇게 작동하는지 설명해달라고, 건너뛴 것을 풀어달라고, 자신의 추론을 설명해달라고 요청하는 건 학습이다. AI가 프로젝트를 짜는 동안 그냥 고개를 끄덕이다가 완성됐다고 선언하도록 내버려두는 건 영상 대신 챗봇을 쓸 뿐인 똑같은 함정이다.
자신만의 사전 점검 체크리스트 시작하기 #
숙련된 개발자들은 무언가를 출시하기 전에 실행하는 개인 체크리스트를 갖고 있는데, 수십 가지 항목이 수년에 걸쳐 쌓인 것이다. 목록의 각 줄은 한번 나쁘게 깨진 구체적인 경험을 담고 있다. 이 체크리스트는 물려받은 게 아니라 지금까지 잘못된 모든 것의 압축된 기록이다.
소프트웨어 창작자는 지금 당장 하나를 시작할 수 있고 전체 과정에서 가장 높은 수익을 내는 습관 중 하나가 될 것이다. 첫 번째 버전은 항목이 하나뿐일 수 있다. 무언가가 깨지거나, 감사에서 문제가 발견되거나, AI가 건너뛴 것을 짚어낼 때마다 한 줄이 더해진다. 몇 달에 걸쳐 그 목록은 잃어버린 중간 층이 제공했던 것 — 무엇을 확인해야 하는지, 무엇이 잘못되는 경향이 있는지, "완료"가 실제로 무엇을 의미하는지에 대한 힘겹게 얻은 감각 — 이 된다.
각 감사는 목록에 추가되고 목록은 다음 감사를 더 빠르고 날카롭게 만든다. 시간이 지나면 한때 찾아봐야 했던 질문들이 빌더가 자동으로 던지는 질문들이 된다. 이게 전문성의 실용적인 정의다.
그 작업이 일상적인 열성팬을 소프트웨어 창작자로 만든다 #
안목이나 판단력은 튜토리얼에서 얻지 못한다. 실제 것들을 만들고, 깨고, 무엇이 깨졌는지 살펴보고, 같은 일을 하는 다른 사람들과 비교하는 데서 온다. AI는 빌딩을 빠르게 만들었다. 하지만 자신이 만든 것을 면밀히 살펴보고 그게 실제로 좋은지 판단하는 건 AI가 대신할 수 없다.
그게 잘하게 될 가치가 있는 부분이고, 다른 사람들과 함께 배우는 게 가장 좋다.
MLH 해커톤은 주말에 무언가를 출시하고 몇 걸음 앞선 다른 사람들과 함께 깨는 장소다.
DEV는 감사가 포스트가 되는 곳이다 — 무엇을 만들었는지, 무엇이 잘못됐는지, 코드 리뷰에서 무엇이 나왔는지, 무엇이 수정됐는지.
하나에서 창작물을 만들고 다른 곳에서 그것이 가르쳐준 것을 적어두면, 첫 앱을 출시하는 다음 사람이 당신보다 조금 더 앞에서 시작할 수 있다.
FAQ #
작은 개인 프로젝트라서 아무도 사용하지 않는데 정말 감사해야 하나?
프로젝트가 진정으로 다른 사람의 데이터를 건드리지 않고 온라인에 올라가지 않는다면 보안 위험은 낮고 감사는 가볍게 할 수 있다. 하지만 습관은 버려도 될 프로젝트에서도 쌓을 가치가 있는데, 질문들이 곧 근본적인 개념을 배우는 방법이기 때문이다. 작은 프로젝트에서 물어보는 비용은 몇 분이다. 실제 프로젝트에서 물어볼 줄 모르는 비용은 훨씬 높다.
충분히 알지 못해서 AI의 답변을 판단할 수가 없다. 그게 바로 문제 아닌가?
거의 모든 사람의 솔직한 출발점이고 막다른 길이 아니다. 감사의 목적은 이미 답을 아는 게 아니다. 개념을 시야에 끌어들이는 질문을 하고 맥락 속에서 하나씩 배우는 것이다. 첫 번째 감사는 완전히 이해되지 않는 것들을 드러낼 것이다. 그것들이 바로 커리큘럼이다.
AI가 그냥 다 괜찮다고 말하지 않을까?
그렇게 유도하는 방식으로 물어보면 그럴 것이다. "이거 좋아?"는 안심을 주는 답이 나오는 경향이 있다. "무엇을 건너뛰었고, 선임 엔지니어라면 무엇을 지적할까?"는 유용한 답이 나오는 경향이 있다. 찾을 것이 있다고 가정하는 프롬프트는 대체로 찾아낸다.
이것이 전통적인 방식으로 코딩을 배우는 것과 어떻게 다른가?
전통적인 경로는 기초를 앞에 뒀다 — 실제 것을 만들기 전에 수개월의 문법과 설정. 이 경로는 순서를 뒤집는다. 먼저 만들어서 모멘텀을 잡고 그 다음 만든 구체적인 것을 통해 기초를 배우기 위해 돌아간다. 두 경로 모두 결국 같은 근본적인 판단력이 필요하다. 이 경로는 그것에 더 오래 붙어 있기 쉬운 방향으로 도달할 뿐이다.
이 글은 위 출처의 내용을 바탕으로 작성된 초안입니다. 원문의 의견과 정보를 그대로 전달하며, 별도의 견해를 포함하지 않습니다.