당신의 '바이브 코딩(Vibe-Coded)' 앱이 작동하나요? 그렇다면 정말 괜찮은 앱인가요?

요약 (TL;DR) -
앱을 실행시키는 것은 이제 쉬운 부분이 되었습니다. AI는 첫 시도에 바로 작동하는 결과물을 만들어내는 데 매우 능숙하며, 그것이 실제로 출시되어야 하는지 여부에는 무관심합니다. 소프트웨어 실험가와 자신의 창작물을 대중에게 출시하고 공유하는 사람을 구분 짓는 기술은 데모 이후에 시작되는 작업입니다. 즉, 해당 기능이 의도한 대로 작동하는지, 누군가의 데이터가 노출되지는 않는지, 그리고 그것을 만든 사람이 작동 원리를 설명할 수 있는지 확인하는 작업입니다. 흐름은 '먼저 구축하고, 그 다음에 감사(Audit)하는 것'입니다. 어떻게 그리고 무엇을 감사해야 하는지 배우는 가장 빠른 방법은 앱을 만든 바로 그 AI를 앱을 심문하는 도구로 전환하고, 지금까지 발생한 모든 오류의 목록을 계속 작성해 나가는 것입니다.

앱이 실행됩니다. 데모가 작동합니다. 누군가 친구에게 보낼 수 있는 실제 URL에 배포되었습니다. AI로 처음 앱을 만드는 대부분의 사람들에게 이것이 결승선입니다. 하지만 현실적으로 이것은 중간 지점에 더 가깝습니다.

"작동한다(Works)"와 "좋다(Good)"는 두 가지 서로 다른 질문이며, 대개 서로 다른 요소들에 의해 답변됩니다. 현대의 AI 에이전트(AI Agent)는 첫 번째 질문에 놀라울 정도로 능숙합니다. 원하는 것을 설명하면, 종종 첫 시도에 바로 실행되는 무언가를 만들어냅니다. 하지만 그 결과물이 정말 좋은지 — 즉, 보안이 철저한지, 시연된 모습이 아니라 실제로 의도한 대로 작동하는지, 제작자 이외의 사람이 사용할 때도 견뎌낼 수 있는지 — 는 AI 에이전트가 훨씬 덜 신뢰할 수 있는 별개의 문제입니다. 그 질문이야말로 진짜 작업과 진짜 배움이 존재하는 곳입니다.

이것은 첫 번째 바이브 코딩(Vibe-coded) 프로젝트 이후의 자연스러운 다음 단계입니다. 구축은 끝났습니다. 이제 만들어진 결과물을 가지고 무엇을 해야 할까요?

AI가 벽돌을 생성합니다. 집을 짓는 것은 여전히 사람의 몫입니다.

이 과정에서 AI가 무엇을 하고 무엇을 하지 않는지를 정의하는 유용한 방식이 있습니다. AI는 완성된 구조물이 아닌 원자재 (raw material)를 생산한다는 점입니다. 에이전트 (Agent)는 몇 초 만에 작동하는 코드를 생성할 수 있습니다. 하지만 그 코드가 실제 사람들이 사용할 만한 결과물에 속하는지는 판단의 영역이며, 그 판단은 모델이 아닌 사람이 내려야 합니다.

이는 업계 전반이 계속해서 마주하고 있는 동일한 문제입니다. 완전 초보자, 소프트웨어 제작자, 그리고 생산적인 개발자 사이의 간극은 그 어느 때보다 좁아졌습니다. 하지만 AI가 여정의 초기 단계를 압축하면서, 과거 중간 단계에 존재했던 전문성 계층 — 즉, 개발자가 팀 내에서 실제 문제들과 씨름하며 '좋은 것'이 실제로 어떤 모습인지 천천히 배워나갔던 수년의 시간 — 을 확보하기가 더 어려워졌습니다. 소프트웨어 제작자에게 있어 좋은 소식은 이 격차가 단순히 걱정해야 할 대상만이 아니라는 점입니다. 이는 행동해야 할 대상입니다. 그 행동이란 구축된 것을 감사 (auditing) 하는 것이며, 이는 바로 첫 번째 프로젝트에서부터 시작될 수 있습니다.

아무도 경고해주지 않는 소프트웨어 제작의 한 부분

빠르다는 것은 취약할 수 있다는 뜻이기도 합니다. 만드는 데 오후 한나절밖에 걸리지 않은 앱이 라이브로 배포된 후, 불과 몇 시간 만에 사용자가 제공한 모든 데이터를 유출할 수 있습니다.

이는 가설이 아닙니다.

초보자가 만든 앱들이 데이터베이스를 기본적으로 완전히 개방한 채, 인증이 필요한 엔드포인트 (endpoint)에 인증 절차를 누락하거나, 비밀 키 (secret keys)를 공개 코드에 그대로 커밋 (commit) 한 상태로 프로덕션 (production) 환경에 배포된 사례들이 있습니다. 코드가 실행되었기 때문에 빌드가 완료되었다고 느꼈던 것입니다. 누락된 부분은 문제가 발생하기 전까지는 보이지 않는 영역이었습니다.

이러한 일이 매우 빈번하게 발생하는 이유는 구조적인 문제입니다. AI가 설정(setup)과 상용구 코드(boilerplate)를 처리할 때, 느린 방식으로 직접 빌드하는 사람이라면 적어도 스쳐 지나가며 보았을 수백 가지의 작은 결정들을 조용히 대신 처리해 버립니다. 그 결정 중 일부는 보안(security)에 관한 것입니다. 대부분의 기본값(defaults)은 시스템을 '작동'하게 만들기 위해 설계되었지, '안전'하게 만들기 위해 설계된 것이 아니며, "작동하는 것"과 "안전한 것"은 동일한 기본값이 아닙니다. 근본적인 개념을 배우지 못한 소프트웨어 제작자는 무엇이 잘못되었는지, 어디를 살펴봐야 하는지, 그리고 다음에 무엇을 물어봐야 하는지 모를 수 있습니다. 하지만 만약 그들이 감사(audit)를 업무의 일부로 취급한다면, 다른 누구보다 먼저 문제를 잡아낼 실질적인 기회를 얻게 될 것입니다.

전략: 먼저 빌드하고, 그 다음에 감사하라

"감사(Audit)\

모든 에이전트는 "작동하게 만들기" 위해 트레이드오프(trade-offs)를 수행합니다. 초안 작성을 느리게 만들 수 있는 에러 핸들링(Error handling), 검증(validation), 보안 관행(security practices) 등은 누락될 가능성이 가장 높으며, 동시에 직접적으로 질문해 볼 가치가 가장 높은 요소들입니다.

단 한 명의 사용자만이 아닌 상황이 되면 어떻게 될까요? 단 한 명의 관객을 위해 빌드되고 테스트된 앱은, 열 명 혹은 만 명의 사용자가 동시에 나타날 때 다르게 동작합니다. 이러한 변화를 상상하는 것만으로도 혼자서 데모를 할 때는 결코 드러나지 않았던 문제들이 표면 위로 떠오릅니다.

이 중 그 어떤 것도 정답을 미리 알고 있을 필요는 없습니다. 질문해야 한다는 사실을 아는 것만으로 충분합니다. 그리고 답을 얻는 가장 효율적인 방법은, 애초에 그 코드를 작성했던 바로 그 도구에게 질문하는 것입니다.

AI를 사용하여 AI를 감사하기 (Using AI to Audit AI)

AI 에이전트를 사용할 때 가장 흔히 범하는 실수는 이를 단순 노동자(grunt worker)로 사용하거나, 무엇을 입력할지 지시한 뒤 결과로 나오는 것을 그대로 받아들이는 것입니다. 대신 코치(coach)로 활용한다면, 동일한 도구는 지금까지 발명된 것 중 가장 훌륭한 학습 방법 중 하나가 됩니다. 이러한 코칭 방식은 빌드(building)뿐만 아니라 평가(evaluation)에도 똑같이 적용됩니다. 핵심 비결은 에이전트가 내놓은 결과물을 다시 에이전트에게 가리키며 비판적으로 검토하라고 요청하는 것입니다.

몇 가지 프롬프트(prompts)만으로도 대부분의 작업을 수행할 수 있습니다:

"이 코드를 한 줄씩 짚어가며 각 부분이 무엇을 하는지 설명해 줘."
"이게 작동하게 만들기 위해 어떤 보안 관행(security practices)을 생략했니?"
"실제 사용자들이 사용하기 전에 이 코드에서 무엇을 바꾸겠니?"
"사용자 데이터는 어디에 저장되며, 현재 누가 이에 접근할 수 있니?"
"시니어 엔지니어라면 이 코드에서 어떤 점을 지적할까?"

이 답변들은 두 가지 일을 동시에 수행합니다. 수정해야 할 구체적인 문제를 드러내는 동시에, 해당 문제가 발생하는 정확한 맥락 속에서 그 이면의 개념을 가르쳐 줍니다. 데이터베이스 연결이 왜 안전하지 않은지에 대한 설명을 읽는 초보 빌더는, 추상적인 튜토리얼을 일주일 동안 듣는 것보다 5분 만에 보안에 대해 더 많은 것을 배웁니다. 왜냐하면 그 교훈이 자신이 직접 만들었고 애착을 가진 대상에 연결되어 있기 때문입니다.

이것이 코치(Coach)와 의지처(Crutch)의 차이입니다. AI에게 코드가 왜 그렇게 작동하는지 설명해 달라고 요청하고, AI가 생략한 부분을 파헤치며, AI 스스로의 추론 과정을 따라가는 것은 학습입니다. 반면, AI가 고개를 끄덕이는 것을 지켜보며 프로젝트를 작성하게 두고, AI가 프로젝트가 완료되었다고 선언하게 만드는 것은 튜토리얼을 영원히 따라가는 것과 같은 함정입니다. 단지 비디오 대신 챗봇(Chatbot)을 사용하고 있을 뿐입니다.

자신만의 사전 점검 목록(Pre-Flight Checklist) 시작하기

경험 많은 개발자들은 무언가를 출시하기 전에 실행하는 개인적인 점검 목록을 구축하곤 합니다. 이는 때로 수십 개의 항목에 달하며, 수년간의 성공적이고 실패했던 출시 경험을 통해 만들어집니다. 목록의 각 줄은 한 번 발생했던, 그리고 다시는 반복할 가치가 없을 만큼 심각하게 망가졌던 특정 사건을 나타냅니다. 이 점검 목록은 누군가에게 건네받은 것이 아닙니다. 그것은 지금까지 잘못되었던 모든 것에 대한 압축된 기록입니다.

소프트웨어 제작자는 즉시 점검 목록을 만들기 시작할 수 있으며, 이는 전체 과정에서 가장 높은 수익률을 가진 습관 중 하나가 될 것입니다. 첫 번째 버전에는 단 하나의 항목만 있을 수도 있습니다. 무언가 고장 나거나, 감사(Audit)를 통해 문제가 발견되거나, AI가 생략된 부분을 지적할 때마다 항목이 하나씩 추가됩니다. 몇 달이 지나면, 이 늘어나는 목록은 과거에 '누락된 중간 계층(Missing middle layer)'이 제공하던 역할, 즉 무엇을 점검해야 하는지, 무엇이 잘못되기 쉬운지, 그리고 '완료(Done)'가 실제로 무엇을 의미하는지에 대한 어렵게 얻은 감각을 제공하게 됩니다.

이것은 또한 축적된 질문들이 보상을 받는 지점이기도 합니다. 각각의 감사는 당신의 목록을 풍성하게 만듭니다. 목록은 다음 감사를 더 빠르고 날카롭게 만듭니다. 시간이 흐르면서 한때 찾아봐야 했던 질문들은 제작자가 자동으로 던지는 질문이 되며, 이것이 바로 전문성(Expertise)의 작동하는 정의입니다.

작업은 단순한 열성 팬을 소프트웨어 제작자로 변화시킨다

튜토리얼을 통해서는 안목(Taste)이나 판단력(Judgement)을 얻을 수 없습니다. 안목은 실제 결과물을 만들고, 그것을 망가뜨리고, 무엇이 망가졌는지 조사하며, 같은 일을 하는 다른 사람들과 의견을 비교함으로써 얻어집니다. AI는 제작 과정을 빠르게 만들었습니다. 하지만 AI는 제작자가 만든 것을 면밀히 살펴보고 그것이 실제로 좋은지 결정할 수는 없습니다.

그 부분이 바로 숙련도를 높일 가치가 있는 부분이며, 다른 사람들과 함께 배울 때 가장 효과적입니다.

MLH 해커톤은 무언가를 출시하고, 자신보다 몇 단계 앞서 있는 사람들과 함께 주말 동안 그것을 망가뜨려 볼 수 있는 장소입니다.

DEV는 감사가 포스트(post)가 되는 곳입니다. 무엇을 만들었는지, 무엇이 잘못되었는지, 코드 리뷰(code review)에서 무엇이 발견되었는지, 그리고 무엇이 수정되었는지를 기록합니다.

한 곳에서는 당신의 창작물을 만들고, 다른 한 곳에서는 그것이 당신에게 무엇을 가르쳐 주었는지 기록하세요. 그러면 자신의 첫 앱을 출시하는 다음 사람은 당신보다 조금 더 앞선 지점에서 시작할 수 있게 됩니다.

FAQ

아무도 사용하지 않을 작은 개인 프로젝트를 정말로 감사(audit)해야 하나요?
만약 프로젝트가 정말로 타인의 데이터에 전혀 접촉하지 않고 온라인에 연결되지도 않는다면, 보안상의 위험은 낮으며 감사는 가볍게 진행할 수 있습니다. 하지만 일회성 프로젝트라 할지라도 이러한 습관을 기를 가치가 있습니다. 왜냐하면 핵심은 근본적인 개념들을 어떻게 학습하느냐에 있기 때문입니다. 작은 프로젝트에서 이러한 질문을 던지는 비용은 단 몇 분에 불과합니다. 하지만 실제 프로젝트에서 질문하는 법을 모를 때 치러야 할 비용은 훨씬 더 높습니다.

AI의 답변을 판단할 만큼 충분히 알지 못합니다. 그것이 바로 문제의 핵심 아닌가요?
그것은 거의 모든 사람에게 정직한 시작점이며, 막다른 길은 아닙니다. 감사의 목적은 이미 정답을 알고 있는 것이 아닙니다. 개념들을 시야로 끌어올 수 있는 질문을 던지고, 맥락 속에서 하나씩 배워나가는 것입니다. 첫 번째 감사는 완전히 이해하지 못한 부분들을 드러내 줄 것입니다. 바로 그 부분들이 커리큘럼(curriculum)이 됩니다.

AI가 그냥 모든 것이 괜찮다고 말하지 않을까요?
AI가 그렇게 유도하는 방식으로 질문할 때만 그렇습니다. "이거 괜찮나요?"라고 물으면 안심시키는 답변을 얻기 쉽습니다. 반면 "무엇을 건너뛰었나요? 그리고 시니어 엔지니어라면 무엇을 지적할까요?"라고 물으면 유용한 답변을 얻는 경향이 있습니다. 무언가 발견할 것이 있다고 가정하는 프롬프트(prompt)는 일반적으로 실제로 무언가를 찾아냅니다.

이것이 전통적인 방식으로 코딩을 배우는 것과 어떻게 다른가요?
전통적인 경로는 기초를 앞부분에 집중시켰습니다. 즉, 실제 무언가를 만들기 전에 몇 달 동안 구문(syntax)과 설정(setup)을 익히는 방식입니다. 이 경로는 그 순서를 뒤집습니다.

먼저 구축하여 추진력(momentum)을 얻은 다음, 구축된 구체적인 결과물을 통해 기초(foundations)를 다시 학습합니다. 두 경로 모두 결국 동일한 근본적인 판단력(judgment)을 필요로 합니다. 다만 이 방식은 경로를 유지하기가 더 쉬운 길을 통해 그 판단력에 도달할 뿐입니다.