[카테고리:] 한국어

보기 좋은 화면과 맞는 결과는 다를 수 있다. USGS 공개 CSV로 만든 대시보드의 첫 화면에는 필터와 카드, 차트와 표가 모두 있었다. 그러나 저장한 파일의 지진 2,274건 가운데 규모 값이 2.5 미만인 행이 17건 있었고, 화면은 ‘규모 2.5 이상’이라고 설명하면서 2,274건을 전부 표시했다. 미리 계산해 둔 기본 조건의 답은 2,257건이었다. 자연어 수정 한 번 뒤에야 화면과 검산값이 일치했다.

이 사례가 도구 선택의 출발점이다. 가장 빨리 만들어 주는 제품을 찾기 전에, 내가 만들려는 결과를 어떻게 확인할지부터 정해야 한다. 이 글에서 바이브코딩은 원하는 기능을 자연어로 설명하고 AI가 코드를 만들고 고치게 하는 방식을 뜻한다.

아래 선택표는 아홉 주제의 기록을 목적별로 다시 묶은 것이다. 같은 과제를 여러 도구에 준 비교는 AI 구독 답변과 PPTX 자동화 앱뿐이었다. 나머지는 서로 다른 입력, 환경, 완료 기준을 사용한 단일 사례다. 따라서 시간·수정 횟수·성공 여부를 합산해 종합 순위를 만들 수 없다. Codex는 OpenAI의 코딩 에이전트다. 이 시리즈에서는 일부 결과물을 만드는 도구이면서, 실제 초보 참가자 대신 정해진 절차로 화면 조작과 검증을 수행한 운영자이기도 했다. 합성 입력은 실제 자료를 흉내 내 만든 가짜 샘플을 뜻한다.

한눈에 보는 목적별 선택표

이 표의 ‘관련 편’은 각 관찰의 자세한 조건을 담은 글 번호다. 넷째 열은 이 실험의 미확인 목록이 아니라 독자가 자기 과제에서 다시 확인할 항목이다. 제품 전체의 성능표가 아니며, 검증하지 않은 용도까지 추천하는 표도 아니다. 웹사이트 빠른 시안 행에는 실행 결과 자체가 없다.

선택 순서는 세 질문부터 시작한다

첫째, 로그인·결제·다른 사람의 정보가 들어가는가? 그렇다면 프로토타입이 작동하는 것과 실제 운영이 안전한 것은 별개의 단계다. 로그인 앱 사례에서는 가입과 로그인이 되었고 생성된 기능 테스트도 통과했다. 그러나 별도 점검에서는 반복 시도 제한, 계정 존재를 짐작하게 할 수 있는 응답시간 차이, 기본 관리자 비밀번호 같은 문제가 드러났다. 결제는 시험하지 않았으므로 이 결과를 결제 앱의 안전성 판단으로 확대할 수 없다.

둘째, AI의 설명과 별개로 대조할 답이 있는가? 정답표는 복잡한 테스트 코드일 필요가 없다. 원본 파일 수와 파일이 바뀌지 않았는지 확인하는 고유값(해시), 손으로 계산한 샘플 세 줄, 열어 본 슬라이드 한 장, 공식 페이지의 현재 가격도 답이 된다. 대시보드의 2,274와 2,257 차이도 사전에 계산한 값이 있었기 때문에 발견했다.

셋째, 코드와 데이터를 꺼내 다시 실행할 수 있는가? ‘코드는 사용자 소유’라는 문구와 실제 이동 가능성은 다르다. 이번 호스팅형 빌더 실험에서는 결과 PPTX는 내려받았지만 앱 코드 전체의 GitHub·ZIP 내보내기와 다른 환경 재실행은 시험하지 않았다. 확인하지 않은 이동성을 장점으로 계산해서는 안 된다.

세 질문 중 하나라도 답하기 어렵다면 더 비싼 도구를 고르기 전에 과제를 줄이는 편이 안전하다. 실제 자료 대신 복사본이나 작은 합성 샘플을 쓰고, 맞아야 할 값 하나를 적고, 첫 결과를 보존하는 식으로 시작할 수 있다.

작은 로컬 도구 한 건은 확인된 첫 버전에 빠르게 도달했다

준비된 개발 환경에서 만든 로컬 할 일 앱은 첫 요청 뒤 약 6분 만에 주요 브라우저 확인까지 도달했다. 할 일을 추가하고 완료로 바꿀 수 있었고, 새로고침 뒤에도 내용이 남았다. Calendar 새 일정 화면에는 제목과 시간이 채워졌다. 자동 테스트 8개도 통과했다.

그러나 약 6분은 설치와 인증이 이미 끝난 Mac에서 Codex가 조작한 한 번의 기록이다. 삭제 버튼의 실제 화면 클릭과 실기기 모바일 사용은 끝까지 확인하지 못했다. 이 수치는 ‘초보자도 6분’이라는 약속이 아니다. 낮은 위험의 합성 입력을 사용했고, 확인할 동작이 작았기 때문에 빠른 후보가 됐다는 관찰이다.

자동화가 끝나도 예외와 검토는 남았다

Cursor 파일 정리 실험은 합성 파일 10개로 먼저 이동 예정표만 보는 미리보기 실행(dry run)을 했다. 실제 이동 뒤에는 분류 위치와 파일 내용이 바뀌지 않았는지 대조했고, 같은 명령을 다시 실행했을 때 추가 이동은 0건이었다. 생성 코드는 이 제한된 과제를 수정 없이 통과했다. 다만 폴더 접근 범위, 중복 이름 처리, 위험 표시 해석은 사람이 정해야 했다.

Excel 100개 실험에서는 91개에 정상값이 있었고, 4개에는 값이 없었으며, 5개에는 후보가 중복됐다. 첫 후보는 정상값 60개를 정확히 찾았지만 31개를 놓쳤고 차트도 빠졌다. 규칙과 차트를 보완한 뒤 83개를 자동 확정했으며, 나머지 17개는 검토 대상으로 남았다. 스크립트 자체는 1초 미만에 실행됐지만 사람의 100개 수작업 시간과 전체 요구 정리·수정·검산 시간을 재지 않았다. ‘사람보다 몇 배 빠르다’는 결론은 낼 수 없다.

여기서 도구보다 중요한 것은 결과가 원본 파일·시트·셀로 되돌아갈 수 있는지, 누락·중복·결측이 검토 목록으로 분리되는지다. 입력 형식이 제각각이고 정답 샘플이 없다면 빠른 실행은 품질을 보장하지 않는다.

유효한 파일과 바로 쓸 수 있는 파일은 달랐다

Lovable·Bolt·Replit에는 같은 합성 PPTX 두 개와 같은 요구를 보냈다. 세 도구 모두 최종적으로 20장과 111개 문구를 보존한 유효한 파일을 만들었다. 하지만 세 출력 모두 글자와 배경의 대비가 부족하거나 내용이 보이지 않는 슬라이드가 남아 일관된 가독성 기준에는 미달했다.

이는 PPTX 포맷 통일이라는 한 과제의 결과다. 세 서비스의 웹사이트 제작 품질이나 일반적인 우열을 뜻하지 않는다.

웹사이트 시안 실험에는 실행 결과가 없다

v0로 랜딩 페이지를 만드는 별도 실험은 로그인 전에 중단됐기 때문에 생성 품질, 크레딧 소비, 모바일 화면, 공개 배포에 관해 관찰한 결과가 없다. 공식 문서에 기능이 있다는 사실을 실험 성공으로 바꾸지 않는다.

데이터 화면은 차트보다 숫자 관계를 먼저 고정해야 했다

USGS 피드에서 저장한 파일은 2,276행이었고, 이 가운데 지진은 2,274행이었다. 피드 이름은 M2.5+였지만 고정 스냅샷에는 저장된 규모 값이 2.5 미만인 지진 17행이 있었다. 단일 스냅샷만으로 그 값의 이전 버전이나 수정 이력까지 확인한 것은 아니다. 첫 화면은 최소 규모 값을 비워 둔 채 2,274건을 모두 보여 주면서 ‘2.5 이상’이라고 설명했다. 자연어로 초기 최소 규모와 초기화 값을 2.5로 맞춘 뒤 기본 건수는 2,257건이 됐고 사전 계산과 일치했다.

수정 뒤에는 다섯 필터 조합, 오류 파일, 375×812 화면, 키보드 조작, 내보낸 폴더 재실행을 확인했다. 브라우저 관찰에서는 로컬 주소 127.0.0.1 밖으로 나간 요청이 없었다. 이는 정적 앱 한 개의 제한된 네트워크 관찰이지 Codex나 다른 공급사의 개인정보 처리 점수가 아니다. USGS 피드는 계속 바뀌므로 같은 URL의 현재 값과 이 고정 스냅샷도 구분해야 한다.

유지보수는 새 기능보다 다시 확인할 범위가 늘어났다

별도 앱 Pocket Tasks에는 우선순위, 마감일, 제목 편집을 차례로 추가했다. 자동 테스트는 7개에서 18개로 늘었고, 실제로 실행한 검사에서는 기존 기능이 깨지는 회귀를 발견하지 못했다. AI에 보낸 수정 요청도 0회였다.

그렇다고 유지보수가 쉽다는 뜻은 아니다. 빈 줄을 뺀 앱 코드는 214줄에서 361줄, 테스트는 37줄에서 123줄로 늘었다. 삭제 동작 일부와 손상된 저장값을 화면에 직접 넣는 검사는 반복하지 못했다. 이 사례가 보여 준 것은 테스트가 이전 동작을 반복해서 확인할 경로를 제공했다는 점과, 기능이 늘수록 검증 표면도 커진다는 점이다.

가격은 순위가 아니라 발행일의 조건이다

구독 질문 실험에서도 기본 모드가 서로 다른 ChatGPT·Claude·Grok의 첫 답변 모두에 오류나 과장이 있었고, 공식 원문을 다시 확인한 뒤에야 개선됐다. 그래서 가격 정보는 AI 답변이 아니라 2026년 9월 6일 다시 확인한 공식 페이지를 기준으로 삼았다. 여러 무료 시작 경로가 있었지만 서비스마다 무료 사용량 단위가 빌드 크레딧, 토큰, 에이전트 크레딧, 메시지 수로 달라 서로 환산할 수 없다. 추가 결제 0원으로 실험했다는 사실도 모든 독자가 무료로 같은 결과를 얻는다는 뜻이 아니다.

결제하거나 공개 발행하기 직전에는 ChatGPT, Claude, Grok, Lovable, Bolt, Replit, v0, Cursor의 현재 공식 페이지를 다시 확인해야 한다. USGS 데이터의 필드와 갱신 조건은 USGS CSV 문서, 로그인 보안의 출발점은 OWASP Authentication Cheat Sheet와 NIST SP 800-63B에서 확인할 수 있다.

결론: 제품보다 먼저 멈출 기준을 고르자

아홉 주제는 하나의 최고 도구를 가리키지 않았다. 대신 낮은 위험의 작은 과제에서는 합성 입력과 독립적인 정답이 있을 때 첫 결과가 빠르게 실제 도구 후보가 될 수 있음을 보여 줬다. 반대로 화면이 완성처럼 보여도 숫자, 가독성, 권한, 보안, 내보내기, 유지보수는 따로 확인해야 했다.

시작할 때는 다음 여섯 단계로 시작할 수 있다.

1. 실제 자료 대신 복사본이나 작은 합성 샘플을 넣는다.
2. 맞아야 할 숫자·문구·동작 하나를 먼저 적는다.
3. 첫 결과를 덮어쓰지 않고 보존한다.
4. 결과 파일이나 코드를 도구 밖으로 꺼내 실제 프로그램에서 연다.
5. 같은 입력으로 다시 실행하고 결과가 유지되는지 본다.
6. 로그인·타인의 정보·결제처럼 위험이 큰 기능인데 대조할 답이 없다면 범위를 줄이거나 전문가 검토를 받는다.

이것은 실제 초보자 집단에서 검증한 완전한 안전 절차가 아니다. 이 시리즈가 그럴듯한 결과와 확인된 결과를 구분하기 위해 사용한 출발점이다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

CSV 파일 하나를 AI에게 주면 대시보드가 바로 완성될까? 이번에는 조건을 최대한 좋게 잡았다. 미국 지질조사국(USGS)이 제공하는 ‘최근 30일 규모 2.5 이상 지진’ CSV를 내려받아, 필터·요약 카드·차트·표가 있는 로컬 대시보드를 자연어로 만들었다.

먼저 분명히 할 점이 있다. 이것은 실시간 지진 모니터링이나 경보·안전 판단 도구가 아니다. 2026년 9월 4일에 저장한 30일 이동 구간의 고정 스냅샷을 보는 실험이다. 공식 피드는 매분 갱신되므로 같은 URL의 내용은 달라질 수 있다. USGS는 이 CSV를 스프레드시트 분석에 적합한 형식으로 설명하며 필드 정의를 공개한다. USGS 제작 정보는 미국 내 퍼블릭 도메인으로 안내되지만, 출처 표기는 요청한다.

“코딩 없이”의 기준부터 정했다

무코드를 넓게 잡으면 무엇이든 성공으로 만들 수 있다. 그래서 운영자가 할 수 있는 행동을 먼저 고정했다. 자연어 프롬프트를 보내고, 자연어로 증상을 설명하고, 생성된 폴더를 복사하고, README의 실행 명령을 그대로 쓰는 것까지 허용했다. 소스 코드를 열거나 직접 고치고, 함수명이나 줄 번호를 지목하면 무코드 실패다.

이번 조작 경로는 Codex가 수행했다. 인간 비개발자가 직접 써 본 사용성 실험은 아니다.

정확성 검사는 별도였다. 앱을 만들기 전에 포함할 행, 결측치 처리, 필터의 이상·이하 조건, UTC 날짜, 규모 구간, 반올림, 빈 결과 표시를 ‘정답표’로 고정했다. 앱 코드와 연결하지 않은 Python 검산기로 다섯 가지 필터 조합을 계산했다. 검산기는 작성자까지 독립적이지 않으므로 ‘독립 검증’이라고 과장하지 않았다.

첫 화면은 멀쩡했지만, 의미가 틀렸다

Codex CLI 0.149.0의 gpt-5.6-sol에 사전 조건을 자세히 적은 한 번의 자연어 요구를 보내자 약 5분 뒤 HTML·CSS·JavaScript·README가 만들어졌다. 설치 패키지나 외부 차트 라이브러리는 없었다. CSV는 로컬에서 읽었고, 쉼표가 든 위치 텍스트도 깨지지 않았다. 필터 네 개, 요약 네 개, 차트 두 개, 표까지 처음부터 동작했다.

그런데 첫 결과에는 꽤 중요한 오류가 있었다. 화면은 “2.5 이상”이라고 쓰면서 최소 규모 기본값은 비어 있었다. 그 결과, 유형만 지진으로 정리한 2,274행을 전부 보여 줬다. 보기 좋은 화면과 의미상 맞는 화면은 달랐다.

세 숫자는 서로 다른 처리 단계를 뜻한다.

1. 2,276행 — 저장한 CSV 전체: 지진 2,274행과 산사태(landslide) 2행이 들어 있었다.
2. 2,274행 — 유형 정리 뒤: 산사태 2행을 빼고 type=earthquake인 행만 남긴 수다. 최초 화면은 여기까지 적용했다.
3. 2,257행 — 수정된 기본 필터 뒤: 지진 2,274행 가운데 저장 시점의 규모가 2.5 미만인 17행을 mag >= 2.5 조건으로 더 제외한 수다.

즉 2,276 - 2 = 2,274, 다시 2,274 - 17 = 2,257이다. 앞의 2건은 지진이 아닌 자료를 유형으로 정리한 것이고, 뒤의 17건은 지진이지만 저장된 규모가 기본 표시 기준 아래여서 필터링한 것이다. 피드 이름이 ‘M2.5+’여도 저장 시점의 각 행이 모두 2.5 이상이라고 가정할 수 없었다.

“초기 최소 규모와 초기화 값을 2.5로 맞춰 달라”는 자연어 수정 한 번을 보냈다. 코드 파일은 열지 않았다. 수정 뒤 기본 건수는 2,257건으로 검산값과 일치했다. 첫 생성은 부분 성공, 최종 결과물은 자연어 수정 1회 뒤 성공으로 판정했다.

숫자는 어디까지 맞았나

사전 등록한 다섯 조합에서 건수, 평균 규모, 최대 규모, 평균 깊이, 규모 구간, UTC 일별 합계가 모두 검산기와 같았다. 대표 조합의 건수는 다음과 같았다.

• 규모 4.5 이상: 651건
• 규모 3.0 이상·깊이 70km 이하·reviewed 상태: 1,195건
• 위치 텍스트에 Alaska 포함: 855건

평균 규모는 USGS CSV의 규모 유형 필드인 magType 9종이 섞인 mag 값의 단순 산술평균일 뿐 에너지나 피해의 평균이 아니다.

위 건수는 모두 2026년 9월 4일 저장본 기준이며 현재 공식 피드와 다를 수 있다. 어떤 값도 안전 판단의 근거로 쓰면 안 된다.

테스트 자동화가 앞 조합의 reviewed 상태와 최대 깊이 값을 지우지 못한 채 Alaska 조합을 실행해 756을 표시한 적이 있었다. 앱의 Reset으로 초기화한 뒤 다시 실행하자 정답 855와 일치했다. 이를 앱 계산 오류가 아니라 테스트 상태 초기화 오류로 기록했다.

최소 규모를 9.9로 바꾸면 건수는 0, 평균과 최대값은 숫자 0이 아니라 ‘—’로 표시됐다.

별도로 만든 시험 파일에서는 규모가 잘못되거나 깊이가 빈 행을 앱이 제외하고, 제외 건수를 화면에 알렸다. 헤더만 있는 파일, 필수 헤더 누락, 파일 404는 빈 화면 대신 원인을 담은 오류를 보여 줬다. 375×812 화면에서 페이지 가로 넘침은 없었고, 키보드로 필터와 초기화 버튼에 접근할 수 있었으며 포커스 표시도 보였다. 차트의 모든 값은 표로도 제공됐다. 다만 이것은 최소 접근성 점검이지 웹 콘텐츠 접근성 지침(WCAG) 준수 인증은 아니다.

최종 폴더는 터미널에서 README의 Python 로컬 HTTP 서버 명령을 그대로 실행해 다시 열었고 외부 네트워크 요청은 0건이었다. 즉 소스 편집은 없었지만, 호스팅까지 GUI로 끝나는 일반적인 무코드 서비스는 아니었다.

추가 결제는 없었지만 기존 ChatGPT Pro/Codex 구독을 사용했으므로 ‘무료’라고 부를 수는 없다.

생성 약 5분, 검증 약 8분, 수정 약 30초로 전체 실험은 약 14분이 걸렸다. 조사와 앞선 편집 인터뷰 시간은 포함하지 않았다.

결론: 화면 제작보다 검증 규칙이 더 중요했다

공식 설명이 잘 갖춰진 CSV 한 개, 이 Codex 모델, 정밀한 최초 프롬프트라는 조건에서는 코드를 직접 읽지 않고도 실제 동작하는 대시보드까지 갈 수 있었다. 첫 생성부터 대부분의 기능이 작동했고 자연어 수정도 한 번이면 충분했다.

하지만 “CSV를 넣으면 끝”은 아니었다. 가장 위험한 오류는 앱이 멈추는 오류가 아니라, 멀쩡한 화면이 데이터 설명과 다른 범위를 보여 주는 오류였다. 다음 세 묶음을 먼저 정하지 않았다면 놓쳤을 가능성이 크다.

• 출처·이용 조건과 고정 스냅샷
• 계산 규칙·빈 값과 시간대
• 모바일·키보드와 오류 상태

자신의 공개 CSV에 적용하려면 네 가지를 먼저 확인하는 편이 좋다. 재사용 조건이 명확한가, 시간·숫자·범주 열의 뜻이 정의돼 있는가, 실시간 API가 아닌 고정 입력으로 재현할 수 있는가, 정답을 대조할 작은 필터 조합을 만들 수 있는가. 이 조건이 없다면 멋진 차트보다 검증 비용이 먼저 커진다.

이번 결과는 문서가 잘 된 USGS CSV 한 개의 최상 조건 실험이다. 다른 공개 데이터, 실시간 연결, 지도, 재난 판단 도구까지 된다는 뜻은 아니다. 그래도 한 가지는 분명했다. AI는 대시보드의 화면과 계산을 빠르게 만들 수 있다. ‘제대로 작동한다’고 말하려면 검증 규칙과 근거를 별도로 정하고 확인해야 한다.

출처

• USGS Earthquake Hazards Program: CSV 형식과 피드 설명
• USGS: 저작권·출처 표기 안내

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

새 기능을 넣은 뒤 필터를 바꿀 때 완료·미완료를 합친 전체 건수가 틀어지거나, 새로고침 뒤 저장한 내용이 사라진다면 어떨까? 개발자는 이런 일을 ‘회귀’라고 부른다. 비개발자에게는 한 곳을 고쳤는데 전에 되던 다른 곳이 고장 난 것이라고 이해하면 충분하다.

로컬 할 일 앱 하나에 우선순위, 마감일, 제목 편집을 차례로 추가했다. 이번 실행에서는 실제로 수행한 자동 검사와 화면 확인 범위 안에서 새 기능 오류나 기존 기능 회귀를 발견하지 못했고, AI에 수정 요청도 보내지 않았다. 다만 이 결과에는 조건이 있다. 기준 앱부터 테스트와 저장 오류 처리를 요청했고, 매번 실행한 검사가 통과한 버전에서 다음 단계를 시작했다. 계획한 화면 검사를 전부 실행한 것도 아니어서 네 단계 모두 ‘부분 확인’으로 판정했다.

먼저 가져갈 결론

• 이번 한 사례에서는 기능 세 개를 추가한 뒤에도 실행한 검사가 모두 통과했다.
• ‘오류 0’은 앱 전체가 안전하다는 뜻이 아니라 수행한 검사에서 오류를 찾지 못했다는 뜻이다.
• 이번 사례에서는 기능과 함께 코드·테스트·다시 확인할 항목도 늘었다. 이 결과는 새 기능을 맡긴 뒤 예전 동작과 저장 상태를 함께 재검사하는 습관을 뒷받침한다.

이 한 사례에서 가져갈 실용적인 판단 기준은 “AI가 첫 코드를 만들어줬는가”에 그치지 않는다. 새 기능을 넣을 때마다 같은 확인 순서를 반복할 수 있는가도 함께 봐야 한다.

기능을 추가할 때 다시 볼 다섯 가지

1. 새 기능보다 먼저 예전 버튼을 같은 순서로 다시 누른다.
2. 필터를 바꾼 뒤 목록과 전체 건수가 어긋나지 않는지 본다.
3. 새로고침하거나 다시 열어 입력한 데이터가 남는지 확인한다.
4. 새 기능이 완료 상태나 날짜처럼 관계없는 값까지 바꾸지 않았는지 살핀다.
5. 문제가 생기면 구체적으로 다시 요청하고 처음부터 전체 순서를 반복한다.

이번에는 수정 요청이 필요하지 않았지만, 마지막 항목도 실험 전에 미리 정해 둔 대응 절차였다. 결과를 보고 나서 유리하게 만든 규칙은 아니다.

로컬 할 일 앱을 네 단계로 바꿨다

외부 서버나 실제 개인정보가 없는 로컬 앱 ‘Pocket Tasks’를 AI 코딩 도구 Codex로 만들었다. 도구 화면에 정확한 모델명이 표시되지 않아 이 글에서는 모델명을 적지 않는다. 기준 앱 요청에는 할 일 추가·완료·삭제, 상태 필터, 전체·진행 중·완료 건수 요약, 브라우저 저장 기능과 함께 단위 테스트와 저장 오류 처리를 처음부터 포함했다.

그 뒤에는 직전 단계에서 실행한 검사가 통과한 스냅숏, 즉 그 시점의 저장된 버전만 이어받아 기능을 하나씩 추가했다.

• S0: 기준 앱
• S1: 우선순위와 상태·우선순위 결합 필터
• S2: 마감일과 ‘기한 지남’ 필터
• S3: 목록 안에서 제목 편집

각 단계에서는 JavaScript 문법을 확인했다. S1부터는 이전 단계의 자동 테스트를 고치지 않은 채 전부 다시 실행하고 새 기능 테스트를 더했다. 화면 확인은 브라우저 도구로 진행했다. 추가·완료·필터·요약을 다시 확인했으며, 새로고침 때는 그 단계까지 존재한 제목·완료 상태·우선순위·날짜가 남는지 살폈다.

실행한 검사에서는 회귀를 찾지 못했다

제품 오류는 새 기능 자체의 문제, 회귀는 이전에 되던 기능이 깨진 문제로 셌다. 네 단계에서 수행한 검사 기준 제품 오류는 0건이었고, S1~S3에서 관찰된 회귀도 0건이었다. AI에 보낸 수정 요청도, 검증 뒤 사람이 직접 코드를 고친 일도 0회였다.

화면 확인도 기능이 추가된 단계별로 나눴다. S1에서는 우선순위 기능이 생기기 전에 만든 할 일이 요청한 대로 중간 우선순위로 표시됐다. S2에서는 상태·우선순위·기한 조건을 모두 만족하는 항목만 남도록 필터가 함께 작동했고, 화면에 일부 항목만 보여도 전체 건수 요약은 바뀌지 않았다. S3에서는 제목을 편집해도 완료 여부·우선순위·마감일이 유지됐고, 새로고침 뒤에도 저장한 값이 남았다. 이 확인 과정에서 생긴 검사 도구 문제는 아래에서 설명한다.

자동 검사는 Node.js의 내장 테스트 러너를 사용했다. 테스트 중 예외가 생기면 실패로 표시된다. 브라우저 데이터는 같은 출처(origin)에 값을 보존하는 localStorage에 저장했다. 자동 테스트로 확인한 상태·저장 로직과 별도로, 브라우저에서 실제 새로고침 뒤 값이 남는지도 확인했다. (Node.js Test Runner, MDN Web Storage API)

왜 네 단계 모두 ‘부분 확인’인가

사용한 브라우저 도구로는 저장소 값을 직접 바꿀 수 없었다. 그래서 손상된 저장값을 만났을 때의 동작은 화면에서 재현하지 못했고 자동 테스트로만 확인했다. 삭제 동작은 S0 화면에서는 실행했지만, S1 이후에는 검사 도구에서 동작 시점의 별도 안전 확인이 필요해 화면에서 반복하지 않았다. 대신 이전 단계부터 그대로 유지한 자동 테스트로 확인했다.

마지막 새로고침 검사에서는 검사 도구가 화면의 특정 요소를 찾는 두 번의 시도에서 시간 초과가 났다. 화면 전체 구조와 항목 목록을 한꺼번에 읽는 방식으로 저장된 제목과 나머지 값이 남아 있음을 다시 확인했다. 다만 이 도구 문제를 제품 오류로 세지도 않았고, 첫 시도에 완전히 성공한 것으로 기록하지도 않았다.

이 범위 때문에 표의 통과와 ‘0건’은 검사한 동작에 대한 관찰값이다. 실제 사용자 환경 전체, 다른 앱, 다른 프롬프트, 이미 고장 난 코드 위에서의 유지보수까지 보증하지 않는다.

참고: 코드 크기와 시간도 함께 기록했다

앱 코드는 빈 줄을 제외하고 214줄에서 361줄로, 테스트 코드는 37줄에서 123줄로 늘었다. 같은 날 같은 ESLint 9.35.0 classic 규칙으로 측정한 함수별 최대 순환 복잡도는 8에서 10으로 올라갔다. 순환 복잡도는 조건에 따라 코드 실행 경로가 얼마나 갈라지는지 세는 값이다. 미리 정한 기준인 10을 넘는 함수는 없었다. 이 ESLint 버전이 지원 종료 경고를 냈기 때문에 당일 비교용으로만 사용했다. 줄 수와 복잡도는 확인할 표면이 커졌다는 보조값이지 품질 점수가 아니다. 국제 표준 ISO/IEC 25010 역시 제품 품질을 하나의 점수가 아니라 여러 특성과 하위 특성으로 나눠 보는 참조 모델이다. (ESLint complexity, ISO/IEC 25010:2023)

요청부터 첫 파일 전달까지는 단계별 52~122초, 검증은 72~126초였다. 단계마다 요구와 검사 수가 달라 이 시간만으로 AI가 더 좋아지거나 나빠졌다고 해석할 수는 없다. 마지막 검증 시간에는 화면 요소를 찾지 못한 원인이 앱인지 검사 도구인지 구분한 시간도 포함됐다.

결론: 기능 추가는 재검사가 끝나야 끝난다

이번 한 앱에서는 기능 세 개가 수정 요청 없이 추가됐고, 실행한 검사에서 기존 기능이 깨지는 모습은 발견하지 못했다. 그러나 매 단계 실행한 검사가 통과한 스냅숏에서 시작한 한 번의 연속 사례다. 이미 깨진 앱에 계속 기능을 얹는 비용은 측정하지 않았다.

바이브코딩의 유지보수는 “AI가 코드를 써줬다”에서 끝나지 않는다. 이전에 되던 것이 지금도 되는지 확인하는 일까지 포함해야 비로소 기능 추가가 끝난다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

다운로드 폴더가 어지럽다고 곧바로 Cursor에 통째로 맡겨도 될까? 이번 실험에서는 가짜 파일 10개를 이미지·PDF·텍스트·기타 폴더로 정리하는 스크립트를 만들었다. 생성된 스크립트는 코드 수정 없이 이번 세션의 규칙에 따라 가짜 파일 10개를 모두 정확히 옮겼다. 이번 세션에서는 결과를 완료로 판단하기 전에 연습 폴더 → 계획 → 미리보기 → 실행 → 검증의 다섯 단계를 차례로 확인했다.

이 결과는 인간 초보자의 사용성 시험이 아니다. AI 코딩 에이전트인 Codex가 한 Mac에서 합성 파일로 수행한 단일 세션이다. 따라서 “비개발자는 모두 여기서 막힌다”가 아니라, 실제 파일을 맡기기 전에 무엇을 확인해야 하는지 보여주는 사례로 읽어야 한다.

1. 원본 대신 연습 폴더를 연다

실험에는 개인 사진이나 업무 문서를 쓰지 않았다. 별도 작업 공간에 내용까지 전부 가짜인 파일 10개를 만들고, Cursor에서 그 격리 작업 공간을 열어 진행했다. 실제 Downloads 전체를 열면 AI가 읽거나 명령을 실행할 수 있는 범위도 함께 넓어진다. Cursor 공식 설명에 따르면 Agent는 파일을 읽고 편집할 뿐 아니라 터미널 명령도 실행할 수 있다.

처음이라면 원본이 아니라 복사본 5~10개로 연습하는 편이 낫다.

2. Plan에서 ‘정리’의 뜻부터 정한다

처음 요청은 “계획만 만들고 파일과 터미널은 건드리지 말라”였다. Plan Mode 문서는 코드를 쓰기 전에 작업 폴더를 살펴보고 질문과 계획을 만드는 흐름을 설명한다.

Plan Mode 선택만으로 실행 차단을 가정하지 않고, 이번 요청에는 파일 변경과 터미널 실행 금지를 따로 적었다.

Cursor는 두 가지를 되물었다.

1. 결과 폴더를 inbox 안에 둘까, 작업 공간 맨 위에 둘까?
2. 확장자 없는 README와 archive.zip은 텍스트일까, 기타일까?

“파일을 정리해 줘”만으로는 정답이 없다는 뜻이다. 목적지, 같은 이름 처리, 확장자 없는 파일, 하위 폴더 규칙을 먼저 말로 정해야 한다. 이번에는 네 결과 폴더를 inbox 안에 만들고, .txt만 Text로 보내며 나머지 미지원 파일은 Other에 보존하기로 했다.

3. 실행 전에 dry-run을 읽는다

계획을 확인한 뒤 파일 작성과 명령 실행이 가능한 Build 모드로 바꾸되 실제 이동은 금지하고, 먼저 아래 미리보기만 요청했다.

python3 organize_inbox.py --dry-run

dry-run은 무엇을 어디로 옮길지 보여주되 파일은 바꾸지 않는 예행연습이다. 출력에는 예정 이동 10건과 다른 위치의 파일을 가리키는 바로가기 같은 심볼릭 링크 1건을 건너뛴다는 결과가 나왔다. 같은 이름의 파일은 숫자 접미사로 둘 다 보존하고, README와 .zip은 Other로 보낼 계획이었다. Cursor와 별도로 실행한 검증에서도 대상 파일은 그대로였다.

다만 명령 옆에 잠시 Delete attempted(삭제 시도됨)라는 표시가 나타났다. 이유는 확인하지 못했다. 실제 삭제는 없었지만, 이런 표시가 보일 때 모델의 설명만 믿고 넘어가서는 안 된다. 이 표시의 의미를 실제 파일 상태로 확인하기 전에는 실제 이동을 요청하지 않는 편이 안전하다. 이번 세션의 삭제 없음 판정은 독립 검증 결과다. 출발지·목적지·파일 수·제외 항목 설명은 별도의 dry-run 범위 확인 기준이다.

4. 범위를 확인한 뒤 복사본에서 실행한다

실제 실행은 명령이 오류 없이 끝났다는 신호인 종료 코드 0을 반환했고, 파일 10개를 옮기고 심볼릭 링크 1건을 건너뛰었다. 명령을 실행해도 되는지 Cursor가 자동으로 판별하는 설정인 Auto-review가 켜진 이 세션에서 명령은 승인 버튼 클릭 없이 실행됐다. Run Modes 문서도 Auto-review가 보안 경계는 아니며 자동 판별이 틀릴 수 있다고 경고한다.

따라서 “위험하면 Cursor가 반드시 물어볼 것”이라고 기대하면 안 된다. 실행 요청을 보내는 행위 자체를 승인으로 보고, 그 전에 dry-run의 범위가 맞는지 확인해야 한다.

5. 성공 메시지 대신 파일 상태를 확인한다

종료 코드 0은 명령이 오류 없이 끝났다는 뜻일 뿐, 결과가 맞다는 보장은 아니다. 이번에는 별도 정답표와 검증기로 다음을 확인했다.

• 가짜 파일 10개가 정해 둔 네 범주 중 하나에만, 빠지거나 중복되지 않고 존재했다.
• 파일 내용의 지문 값인 해시가 10/10 보존됐다.
• 같은 이름의 두 파일이 덮어써지지 않았다.
• inbox 밖에 일부러 둔, 건드리면 안 되는 확인용 파일과 심볼릭 링크가 바뀌지 않았다.
• 같은 명령을 다시 실행했을 때 추가 이동이 0건이었다.

심볼릭 링크 대상을 단순히 읽었는지까지는 탐지하지 못했다. 그래도 실제 사용자는 원본을 남기고, 미리보기와 실행 후의 파일 수를 비교하고, 같은 이름이 둘 다 살아 있는지 확인하는 것부터 시작할 수 있다. Agent의 마지막 문장보다 실제 파일 상태를 완료 기준으로 삼는 것이 핵심이다.

이 사례에서 권하는 확인 순서

1. 원본이 아닌 복사본 5~10개로 연습 폴더를 만든다.
2. Plan에서 “계획만, 파일 변경과 터미널 실행 금지”라고 쓴다.
3. 목적지·중복 이름·확장자 없는 파일·하위 폴더 규칙을 답한다.
4. “덮어쓰기·삭제 금지, 심볼릭 링크 건너뛰기”를 명시한다.
5. Build에서 스크립트와 --dry-run까지만 요청한다.
6. 미리보기의 출발지·목적지·건수·제외 항목을 확인한다.
7. 범위가 맞으면 복사본에서 실제 실행을 한 번 요청한다.
8. 실행 후 파일 수와 같은 이름 파일이 모두 남았는지 확인한 뒤, dry-run을 다시 실행해 추가 예정 이동이 0건인지 본다.

실험에서는 두 번째 실제 실행으로 추가 이동 0건을 확인했다. 위 권고는 독자가 불필요한 실제 재실행 대신 dry-run으로 다시 확인하도록 더 좁힌 절차다.

참고: 이번 실험의 조건과 기술적 한계

• 기준일: 합성 실험 2026년 9월 2일, 공식 문서 재확인 2026년 9월 6일
• 환경: Cursor 3.18.25, Cursor Grok 4.6 Medium, Apple Silicon Mac
• 로그인: 로그인 전 시도는 Log In과 Sign Up 화면에서 멈췄고, 계정 소유자가 로그인한 뒤 별도 세션에서 재개. 절차의 난이도와 시간은 미측정
• 결과: 자연어 메시지 5회, 추가 질문 2개, 코드 수정 요청 0회, 기능 오류 0회
• Cursor 표시 Agent 작업 시간: 8분 31초. 설치·사용자 로그인·독립 검증 시간은 제외
• 판정: 이 합성 파일 10개에 한정해 첫 실행 성공, 분류 10/10, 두 번째 실행 추가 이동 0건
• .cursorignore는 AI 문맥에서 파일을 제외하지만 Agent의 터미널·외부 도구 접근까지 막는 경계는 아니다.
• Privacy Mode 설명에서 학습에 쓰지 않는다는 말은 파일 내용이 Cursor 서버를 거치지 않는다는 뜻이 아니다. 이번 세션에서는 Privacy Mode 활성 여부를 측정하지 않았다.
• Checkpoint는 Agent 변경용 로컬 복원 지점이지 완전한 백업이나 Git 대체물이 아니다. 이번 세션에서는 복원을 시험하지 않았다.

이 세션에서 코드 수정 요청은 0회였다. 그 뒤에도 확인할 대상은 남았다. 작게 격리하고, 계획을 읽고, 미리 본 뒤, 실제 파일 상태를 확인하는 순서다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

이 글은 AI 웹사이트 제작 도구 v0로 랜딩 페이지를 생성해 본 후기가 아니다. 2026년 9월 2일, Codex 에이전트가 정해 둔 30분 실험을 시작하려 했지만 에이전트가 쓸 수 있는 두 브라우저 모두 v0에 로그인되어 있지 않았다. 계정이나 로그인 상태를 바꾸지 않는다는 규칙에 따라 에이전트는 프롬프트를 보내기 전에 멈췄고, 타이머도 시작하지 않았다.

따라서 이번 기록으로는 v0로 30분 안에 랜딩 페이지를 완성해 공개하고 확인할 수 있는지 판단할 수 없다. 대신 무엇을 확인해야 ‘30분 완성’이라고 부를 수 있는지, 실행 전에 고정한 체크리스트를 정리한다.

실제로 확인한 것은 로그인 전 화면뿐이다

정해진 절차를 수행하는 Codex 에이전트는 두 곳에서 v0 홈을 열었다. 하나는 에이전트가 사용하는 내부 브라우저, 다른 하나는 에이전트가 조작할 수 있게 연결된 일반 Chrome이었다. 내부 브라우저의 v0.dev 홈에는 Log In, Sign Up이 보였고, Chrome의 v0.dev 탭에서도 메뉴를 열자 같은 두 항목이 나타났다. 두 환경 모두 기존 세션이 없었다. 홈 화면에 v0 Max라는 이름도 보였지만 로그인 전 화면에 표시된 문구였을 뿐이다. 무료 계정에서 실제로 어떤 모델이 쓰이는지에 대한 증거로는 삼지 않았다.

프로젝트 생성, 프롬프트 전송, 결과 미리보기, 수정, 배포는 하나도 실행하지 않았다. 사용량 화면도 관찰하지 않아 시작·종료 크레딧을 기록하지 못했다. 그래서 생성 품질, 수정 횟수, 반응형 화면, 접근성, 폼 동작, 비용, 프로덕션 주소는 모두 미검증이다. 로그인 화면에서 멈춘 사실은 제품 실패도, 30분 성공도 증명하지 않는다.

‘30분’에는 생성 뒤의 확인까지 들어가야 한다

예쁜 첫 화면이 나타난 순간을 완료로 잡으면 걸린 시간은 짧아 보일 수 있다. 이 실험은 첫 프롬프트 전송부터 생성 대기, 요구사항 확인, 자연어 수정, 반응형·키보드 검사, 프로덕션 배포, 로그아웃 상태 확인까지를 하나의 연속 타이머에 넣도록 설계했다.

2026년 9월 10일 확인한 v0의 공식 빠른 시작은 프로덕션 게시를 생성·편집 뒤의 별도 단계로 안내하며, 이 처음부터 게시까지의 종단 경로에 걸리는 총시간을 약속하지 않는다. 별도로 정한 실험 절차는 실행이 시작될 경우 네 시점—첫 화면 표시, 마지막 수정(수정한 경우), 게시 클릭, 로그아웃 상태 확인—을 기록하도록 한다.

비개발자가 확인할 완성 체크리스트

아래 항목을 모두 확인하기 전에는 ‘30분 안에 랜딩 페이지를 완성해 공개했다’고 판정하지 않는다.

• 요구사항: 필요한 섹션과 행동 버튼이 있고, 예시 후기와 가상 서비스를 실제 고객·실서비스로 오해하지 않게 표시했는가?
• 기능: 페이지 안의 특정 위치로 이동하는 링크, 버튼, 필수 입력 검사, 폼 전송 뒤의 완료 표시가 실제로 동작하는가?
• 반응형: 스마트폰·태블릿·데스크톱 크기인 375×812, 768×1024, 1440×900 CSS 픽셀 모두에서 가로 스크롤·겹침·핵심 내용 잘림 없이 표시되는가?
• 접근성 기본선: 마우스 없이 링크·버튼·폼으로 이동할 수 있고, 지금 어디에 있는지 테두리 등으로 보이는가? 입력란에 이름표가 있고 제목 순서가 자연스러우며, 주요 글자·행동 버튼과 배경의 색 차이가 눈에 띄게 부족한 곳이 없는가?
• 배포: 미리보기나 공유 링크가 아니라 프로덕션 게시로 만든 고정 주소를 로그아웃 상태에서도 열 수 있는가?
• 무료 범위: 시작·종료 크레딧과 메시지 수를 기록했고 결제나 유료 전환 없이 끝났는가?
• 데이터 안전: 실제 개인정보, 외부 API, 데이터베이스, 실제 이메일 전송을 모두 배제했는가?
• 고친 뒤 확인: 문구나 필수 입력 검사의 오류를 고친 뒤에도 나머지가 그대로 동작하는가? 수정할 항목이 없다면 해당 없음으로 기록했는가?

앞의 여섯 항목은 결과와 사용 조건을 확인하는 기준이고, 마지막 두 항목은 안전과 ‘고친 뒤 다른 곳이 깨지지 않았는지’를 보는 기준이다. 여덟 항목은 모두 최종 판정 전에 확인하고, 실행할 상황이 없었던 항목은 해당 없음과 그 이유를 남긴다. 이 체크는 완전한 접근성 감사나 전문 디자인 평가가 아니다. 기본적인 실패를 놓치지 않기 위한 최소선이다. 한 번 통과하더라도 모든 비개발자가 같은 시간 안에 성공한다고 일반화할 수 없다.

무료 기능과 실제 운영 조건은 구분해야 한다

2026년 9월 10일 v0 공식 가격 페이지를 확인했을 때 Free 플랜은 월 0달러, 월 5달러 크레딧, 하루 7개 메시지로 안내됐다. 같은 날 확인한 가격 문서에 따르면 토큰 사용량은 입력·출력 길이와 대화 기록·소스 파일을 포함한 관련 문맥에 따라 달라진다. 하루 7개 메시지라는 숫자만으로 한 페이지를 끝낼 수 있다고 계산할 수는 없다.

같은 날 확인한 배포 문서는 프로덕션 게시가 v0 작업을 연결된 Vercel 프로젝트의 고정된 프로덕션 주소에 반영한다고 설명한다. 같은 날 확인한 Vercel Hobby 플랜은 개인·비상업 용도로 제한된다. 무료 실험에 성공하더라도 Hobby 플랜에서 상업용 사이트 운영이 허용된다는 뜻은 아니다. 가격·기능·약관은 바뀔 수 있으므로 실제 실행일과 발행 전에 다시 확인해야 한다.

지금 내릴 수 있는 결론은 ‘미검증’이다

공식 문서가 기능을 나열한다고 해서 30분 안에 품질 확인과 공개 검증까지 끝난다는 뜻은 아니다.

이번 시도는 타이머를 시작하기도 전에 멈췄다. 따라서 답은 성공도 실패도 아닌 미검증이다. 직접 시험한다면 먼저 완료 기준을 적고, 첫 화면 표시가 아니라 로그아웃 상태의 프로덕션 주소 확인까지 시간을 재자. 확인하지 못한 칸을 결과처럼 채우지 않는 것이 ‘30분 완성’ 주장을 검증하는 출발점이다.

브라우저 사전 확인은 Codex 에이전트가 정해진 절차와 안전 경계에 따라 수행했습니다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

공식 자료

• v0 Quickstart
• v0 Pricing
• v0 Pricing documentation
• v0 Deployments
• Vercel Hobby plan