앱 생성 다음에 무엇을 확인할까? 2026년 바이브코딩 기록 읽기

AI에게 원하는 동작을 설명하며 소프트웨어를 만드는 바이브코딩에서, 화면 생성 다음에는 무엇을 확인할까? 이 블로그에서 앞서 따로 진행한 아홉 실험·점검 기록을 다시 읽었다. 새 실행이나 하나로 연결한 제작 과정은 없으며, 2026년은 기록의 시점이지 시장 변화나 작년보다 나아진 정도를 뜻하지 않는다.

새로고침 뒤에도 기록이 보인다면, 정말 저장된 걸까? 저장 실험의 별도 브라우저 시연에서는 페이지를 강제로 다시 불러온 뒤 브라우저 안의 세 저장 공간(sessionStorage·localStorage·IndexedDB)에서 기록이 다시 보였다. 메모리에만 두거나 쓰기를 버리는 조건(drop-write)에서는 기록이 비어 있었다. 새로고침 성공만으로 서버에 저장됐다고 판단할 수는 없었다. 당시 관찰 기록을 근거로 했으며, 이번 종합에서는 브라우저의 원본 화면·동작 기록으로 별도 확인하지 않았다. 페이지를 다시 불러오는 일과 서버 프로그램을 껐다 켜는 일, 브라우저 자체를 종료했다 여는 일은 서로 다른 검사다.

자료의 범위: 하나로 이어진 작업 과정은 아니다

근거는 2026년 9월 5~20일의 선행 실험·점검 기록이며, 9월 27일 이 블로그의 실험 기록 폴더에서 대조했다. 원고의 검증·편집은 보존된 기록과의 대조이며, 실험을 다시 실행한 것은 아니다. 결과는 당시 환경과 입력에 한정된다.

‘다시 사용하기’, ‘맡기고 받아들이기’, ‘화면에서 확인한 것, 전달 전에 남은 것’은 읽기 위한 분류이며, 숙련 단계나 연결해 검증한 제작 과정은 아니다. 실제 실행, 전제 확인 중 중단, 서비스 호출 없는 리허설이 섞여 있어 통과 수를 합쳐 성공률을 낼 수도 없다.

관찰: 다시 사용하기

저장 실험에는 앞의 브라우저 시연과 별개로, 로컬 서버와 SQLite 데이터베이스를 확인한 실행이 있다. SQLite는 이 실험에서 서버 쪽 기록을 보관한 데이터베이스다. 실제 로그인 대신 요청에 가상의 사용자 식별 정보(합성 헤더)를 붙인 조건이었다. 지정한 저장·수정·삭제와 서버 프로그램을 한 번 껐다 켠 뒤의 상태가 각각 독립 SQLite 검사와 일치했다. 이 성공은 실행한 검사에 한정되며, 배포 검사는 실행하지 않았다.

다만 다른 기기에서 열기, 외부 서버에 배포하기, 브라우저 자체를 종료했다 다시 열기는 확인하지 않았다. 기존 정보가 없는 새 브라우저 프로필의 화면, 백업, 실제 서비스의 로그인·보안도 검증 범위 밖이다. 브라우저 시연과 데이터베이스 검사는 서로 다른 곳에 남은 기록을 서로 다른 조작 뒤에 확인했으므로 증거를 섞으면 안 된다.

절차 재사용 실험에서는 같은 업무 설명 파일을 복사한 새 대화에서 파일 로딩을 확인했다. 그러나 로딩 성공이 더 정확한 답을 뜻하지는 않았다. 일반 요청, 본문에 절차를 넣은 요청, 도구에 마련된 절차 호출 기능인 스킬을 명시적으로 부른 요청의 주요 답변 12개가 모두 사실 항목을 통과했다. 별도의 암묵적 호출 진단 두 개는 이 12개에 포함하지 않았다. 모두 통과해 사실 점수의 이점은 관찰되지 않았지만, 세 방식의 효과가 같거나 파일이 도움이 되지 않는다고 입증한 것은 아니다.

가상의 한국어 사례 두 개를 조건별로 한 번씩 AI가 실행·채점한 비교이므로, 장기 기억이나 학습 효과, 시간 절약으로 넓혀 말할 수 없다.

필자의 판단은 “다시 된다”의 뜻을 구체화하자는 것이다. 저장은 어디서, 어떤 재시작 뒤에 확인했는가? 절차는 새 대화에서 읽혔는가, 답의 개선도 측정했는가?

관찰: 맡기고 받아들이기

숨겨 둔 버그를 찾는 실험에서는 업무 규칙만 보고 만든 테스트 묶음을 버그가 없도록 준비한 정상 기준 앱에 적용했다. 실행 가능한 다섯 검사 중 두 개만 통과했다. 결함을 얼마나 잡는지 채점할 자격을 갖추지 못한 것이다. 이를 ‘버그를 하나도 못 찾았다’는 점수로 바꿀 수는 없다.

규칙과 앱 코드를 함께 본 테스트 묶음은 정상 기준에서 여덟 검사를 모두 통과했고, 실험자가 넣어 두고 생성 모델에게는 숨긴 세 결함을 잡았다. 실제 탐지 결과다. 다만 각 조건에서 한 번 생성했으므로 조건의 우열이나 코드 접근이 탐지 성공의 원인이라는 점은 입증하지 못한다.

코드를 함께 본 테스트 묶음을 기능 추가 뒤에 다시 적용하자 한계가 드러났다. 올바르게 기능을 추가한 앱과 새 결함이 있는 앱에서 여덟 검사 중 똑같은 다섯 개가 실패했다. 기존 결과의 모양과 정확히 같아야 한다는 검사가 정상적으로 추가된 메모 항목까지 거부했기 때문이다. 이 실패만으로는 기능 변경 뒤 생긴 오류인 회귀 결함을 정상 변경과 구별해 잡았다고 볼 수 없었다.

별도로 준비한 정답 검사는 메모가 사라져야 할 때 남는 결함을 구별했지만, 그 성과를 생성된 테스트에 돌릴 수는 없다. 처음의 세 결함 탐지 성공도 그대로 남는다.

정해진 시간에 작업을 돌리도록 설정하는 AI, 즉 예약형 에이전트에 관한 기록은 다른 종류의 근거다. 실제 예약이나 AI 모델 호출 없이, 미리 정한 사례를 로컬에서 재생한 리허설이었다. 검증 프로그램은 의도한 입력과 다른 데이터 사본(스냅샷)에 묶인 보고서 초안을 거부하고 따로 격리했다. 거부한 주체는 정해진 규칙대로 작동한 검증기다. AI가 스스로 잘못된 입력을 알아챘거나 실제 예약 서비스가 안정적으로 작동했다는 관찰은 아니다.

두 사례에서 결과물 생성과 검수는 분리돼 있었다. 필자의 판단으로는 먼저 테스트가 정상 기준 앱을 통과하는지 확인하고, “검사가 실패했는가” 다음에 “정상 변경과 잘못된 변경을 구별했는가”를 물을 필요가 있다. 보고서라면 어느 입력에서 나왔고 누가 어떤 기준으로 받아들였는지가 다음 질문이다.

관찰: 화면에서 확인한 것, 전달 전에 남은 것

채팅 안에 앱을 띄우는 대화형 앱 실험은 실험용 컴퓨터의 공식 로컬 참조 호스트에서 수행했다. 한국어·영어 입력에 반응하고 합계가 90에서 100으로 바뀌었다. 같은 실행 중인 프로그램과 같은 세션에서 화면을 새로 띄웠을 때 저장값도 복원됐다. 여기까지는 실제 상호작용의 성공이다. 서버 재시작이나 다른 기기에서도 남는 저장을 뜻하지는 않는다.

지원하지 않는 언어 코드에서는 실제 실패가 있었다. 서버는 경고와 함께 영어 결과를 보냈지만 화면은 경고 없이 한국어를 표시했다. 성공한 입력·복원과 이 불일치를 함께 남겨야 한다. 다른 검사에는 절차가 무효여서 판정에서 제외한 세 항목과 아예 시험하지 않은 여섯 항목도 있었다. 어느 쪽도 앱 실패로 세지 않는다. 상용 채팅 서비스 안에서의 동작이나 모델이 전달 내용을 실제로 받았는지도 이 결과가 증명하지 않는다.

생성형 디자인 실험에서는 문장 입력과 직접 그린 디지털 주석 와이어프레임을 한 번씩 실행했다. 와이어프레임은 캔버스에 도형과 글자로 화면 구조를 표시한 실험용 자료다. 종이에 그린 그림이나 초보자의 제작 경험을 시험한 것은 아니다. 두 결과는 정해 둔 세 화면·두 이동 경로와 세 번의 수정을 충족했다. 텍스트를 먼저 실행했고, 만들어진 선택 방식(목록·버튼)과 일부 빈칸 입력 검사 조건은 달랐다. 어느 입력이 더 낫다는 순위는 낼 수 없다.

수정 방식도 하나가 아니었다. 첫 수정은 요소에 직접 반영됐고, 다음 두 수정은 관련 화면 일부를 다시 생성했다. 마지막 지시는 버튼 이름을 유지하면서 이동 위치만 바꾸라는 것이었다. 결과는 지시를 따랐지만 공간 목록으로라는 이름과 실제 목적지가 어긋났다. 실험 지시가 의도적으로 남긴 불일치이며, 요청한 수정을 수행하지 못한 실패는 아니다. 도구가 의미 충돌을 알아챘는지는 이 결과로 알 수 없다.

이 사례에서 필자가 주목하는 것은 지시 충족과 화면 의미의 관계다. 요청대로 바뀌었더라도 버튼 이름과 목적지가 맞는지는 별도로 볼 수 있다. 또한 내보내기를 하지 않았으므로 전달 가능한 코드나 운영 준비 상태는 확인하지 않았다. 대화형 앱의 참조 호스트와 디자인 캔버스에서 각각 움직임을 확인했지만, 둘을 연결해 배포하거나 휴대전화로 넘겨 본 과정은 없다.

실행 전에 멈춘 세 기록

다음은 제품이 동작하다 실패한 결과가 아니다. 실험을 시작하기 위한 전제를 서로 다른 범위에서 확인하다 멈춘 기록이다.

휴대전화 점검 목록에 있던 꺼진 시뮬레이터는 실제 휴대전화 실행의 증거가 아니다. 한 경로는 전제가 미입증이었고 다른 경로는 당시 환경에서 자격 조건을 충족하지 못했다. 모든 환경에서 경로가 없다는 뜻은 아니다.

이 중단은 제품의 안전성이나 이용 가능성에 대해 어느 방향의 판정도 뒷받침하지 않는다. 반대로 대화형 앱의 언어 불일치는 실제로 실행해 관찰한 실패다. ‘모른다’고 남길 자리와 ‘실패했다’고 기록할 자리를 구분하는 것도 이번 종합의 중요한 부분이다.

판단: 다음 요청에 붙일 확인 질문

이 기록들은 절차 재사용, 저장, 검수와 화면 동작을 다뤘다. 사례를 잇는 전달·배포 과정은 시험하지 않았다. 이들을 함께 읽는 것은 편집적 해석이며, 시장 변화나 완성된 운영 방식의 검증이 아니다.

기록에서 도출해 다음 작업에 붙여 볼 질문은 다음과 같다.

• 어떤 조작 뒤에, 어느 저장 위치에서 결과를 확인했는가?
• 테스트 묶음은 버그가 없는 기준 앱을 통과하는가?
• 기능 변경 뒤의 검사는 정상 변경과 잘못된 변경을 구별하는가?
• 결과를 받아들이는 사람이나 프로그램은 어떤 입력과 기준을 대조하는가?
• 수정 뒤 버튼을 눌러 보면 이름과 도착 화면이 맞는가?
• 실제로 사용할 환경과 전달 단계도 시험했는가?
• 실행 전 조건을 못 갖춘 기록은 제품 실패와 구분했는가?

이는 기록에서 도출한 편집적 제안이다. 실제 문제를 얼마나 줄이는지는 측정하지 않았다.

아래 제목은 앞서 공개한 관련 글로 연결되는 읽을거리 링크이며, 원시 증거나 현재 제품 기능을 입증하는 자료는 아니다. 이번 종합이 근거로 삼는 관찰과 실행하지 않은 범위는 링크가 아니라 이 글의 본문과 표에 담았다.

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