GPT-6 Astra로 바이브코딩하는 법, 프롬프트보다 중요한 것

처음 바이브코딩을 시작했을 때는 좋은 모델에게 원하는 기능을 자세히 설명하면 알아서 앱을 만들어줄 것이라고 생각했다.

나는 전문 개발자가 아니다.

그래도 AI를 이용하면 직접 코드를 대부분 작성하지 않고도 화면을 만들고, 기능을 추가하고, 데이터베이스를 연결하고, 배포 과정까지 진행할 수 있었다.

처음에는 꽤 신기했다.

내가 무엇을 원하는지만 잘 설명하면 되는 것처럼 보였다.

그런데 앱이 조금씩 커지면서 생각이 바뀌었다.

문제는 AI가 코드를 만들지 못해서 생기는 경우보다, 내가 무엇을 만들 것인지 제대로 정의하지 않은 상태에서 작업을 시작했을 때 더 자주 생겼다.

기능을 만들었다가 다시 뜯어고치고, 이미 확인한 부분을 다시 검사하고, 한쪽을 수정한 뒤 다른 기능이 깨지지는 않았는지 또 확인해야 했다.

모델이 확신에 찬 설명을 내놓더라도 실제 원인이 다른 경우도 있었다.

그래서 지금은 Astra로 바이브코딩을 할 때 프롬프트보다 먼저 보는 것이 있다.

앱의 목적, 구조, 작업 단위, 완료 기준, 그리고 검증 방법이다.

1. 코딩부터 시키지 말고 앱의 목적부터 정한다

바이브코딩을 시작하면 가장 먼저 하고 싶은 것은 AI에게 기능을 설명하고 코드를 만들게 하는 것이다.

하지만 내가 경험한 방식에서는 이 단계부터 서두르면 뒤에서 수정할 것이 많아졌다.

예를 들어 단순히 “재고관리 앱을 만들어줘”라고 시작하면 구현할 수 있는 방향이 너무 많다.

누가 사용하는지.

어떤 상황에서 사용하는지.

가장 먼저 해결해야 하는 문제가 무엇인지.

첫 버전에서 반드시 필요한 기능과 나중에 추가해도 되는 기능은 무엇인지.

이 정도는 사람이 먼저 정하는 편이 좋았다.

Astra에게 구현을 맡기기 전에 나는 먼저 이런 형태로 정리하는 방식을 선호한다.

• 이 앱을 누가 쓰는가
• 사용자가 가장 자주 하는 행동은 무엇인가
• 반드시 필요한 핵심 기능은 무엇인가
• 첫 버전에서는 무엇을 하지 않을 것인가
• 어떤 상태가 되면 첫 버전이 완성됐다고 볼 것인가

이렇게 목적과 범위를 먼저 정하면 이후의 작업도 훨씬 잘게 나눌 수 있다.

2. 화면보다 먼저 구조를 그린다

앱의 목적을 정했다면 바로 UI를 만들게 하기보다 전체 구조를 먼저 보는 편이 좋다.

어떤 페이지가 필요한지.

사용자는 어떤 순서로 이동하는지.

어떤 정보를 입력하는지.

그 데이터는 어디에 저장되고 어디에서 다시 조회되는지.

로그인이 필요한지.

사용자마다 볼 수 있는 데이터가 달라지는지.

이런 내용을 Astra에게 먼저 구조화하도록 요청할 수 있다.

VECTORLOG 개념도. 바이브코딩을 한 번의 프롬프트가 아니라 목적 정의부터 검증까지 이어지는 작업 흐름으로 정리한다.

출처: VECTORLOG

여기서 중요한 것은 Astra가 제안한 구조를 그대로 받아들이는 것이 아니다.

내가 만들려는 앱의 목적에 정말 필요한 구조인지 사람이 다시 판단해야 한다.

기능을 많이 넣는 것보다 처음부터 불필요한 것을 빼는 편이 이후 작업을 관리하기 쉬웠다.

3. 큰 기능을 검증 가능한 작업으로 나눈다

바이브코딩에서 가장 크게 달라진 내 작업 방식은 한 번에 앱 전체를 만들게 하지 않는다는 것이다.

예를 들어 앱에 로그인, 대시보드, 데이터 입력, 검색, 관리자 기능이 필요하다면 한 번에 모두 요청하기보다 작업을 나눈다.

로그인부터 만든다.

실제 로그인 동작을 확인한다.

그다음 기본 레이아웃을 만든다.

다시 확인한다.

데이터베이스를 연결한다.

데이터가 실제로 저장되는지 확인한다.

그다음 핵심 기능을 하나씩 추가한다.

작업을 작게 나누는 이유는 단순하다.

문제가 생겼을 때 원인을 찾기 쉬워지기 때문이다.

여러 기능을 한 번에 바꾼 뒤 문제가 발생하면 무엇 때문에 깨졌는지 다시 추적해야 한다.

반대로 변경 범위가 작으면 직전에 무엇을 수정했는지 확인하기 쉽다.

4. 모델의 ‘완료’와 실제 완료를 구분한다

AI coding agent를 쓰면서 가장 중요하게 느낀 것 중 하나다.

모델이 “완료했습니다”라고 말하는 것과 실제 앱이 완료된 것은 전혀 다른 문제다.

화면이 생성됐다고 끝이 아니다.

버튼이 실제로 작동하는지 확인해야 한다.

폼에 입력한 데이터가 저장되는지 봐야 한다.

새로고침해도 데이터가 남아 있는지 확인해야 한다.

권한이 필요한 기능이라면 다른 계정에서도 확인해야 한다.

한 기능을 수정했다면 기존 기능이 그대로 동작하는지도 다시 봐야 한다.

로컬에서 작동했다고 배포 환경에서도 같은 결과가 나온다는 보장도 없다.

그래서 작업을 요청할 때부터 완료 조건을 함께 주는 편이 좋다.

예를 들어 “검색 기능을 만들어줘”보다 다음처럼 생각한다.

검색어를 입력할 수 있어야 한다.

검색 결과가 실제 데이터에서 나와야 한다.

결과가 없을 때의 화면도 있어야 한다.

페이지를 새로고침해도 오류가 없어야 한다.

기존 필터 기능이 그대로 작동해야 한다.

여기까지 확인되면 완료다.

이 기준을 사람이 정해놓으면 AI의 작업 결과를 검증하기가 훨씬 명확해진다.

5. 모델의 확신보다 증거를 본다

AI coding agent는 종종 상당히 확신에 찬 어조로 문제의 원인을 설명한다.

하지만 나는 그 설명 자체를 정답으로 보지 않는 편이 좋다고 느꼈다.

앱을 만들면서 모델이 특정 서비스의 플랜이나 인프라 문제를 원인으로 설명했지만, 실제 로그와 응답을 더 확인한 뒤 다른 원인이 드러난 경험도 있었다.

그래서 지금은 바로 해결책을 적용하기보다 먼저 원인을 증명하도록 요청하는 편이다.

무엇이 실패했는가.

어느 단계까지는 정상인가.

실제 에러 메시지는 무엇인가.

같은 문제를 재현할 수 있는가.

최근 변경 사항 중 관련 가능성이 있는 것은 무엇인가.

설명한 원인을 확인할 수 있는 로그나 테스트는 무엇인가.

이 과정을 거치면 “아마 이것 때문일 것”과 실제 확인된 원인을 분리할 수 있다.

바이브코딩에서 비용을 줄이는 방법도 결국 여기와 연결된다.

모델의 첫 설명을 그대로 믿고 새로운 서비스를 결제하거나 구조 전체를 바꾸기 전에, 먼저 문제를 좁혀야 한다.

6. Astra에게 구현만 시키지 말고 검증도 맡긴다

OpenAI는 GPT-6 Astra를 소프트웨어 엔지니어링과 여러 단계의 복잡한 작업을 수행하도록 설계된 모델로 소개한다.

승인된 OpenAI 공식 발표 요약에 따르면 Astra는 ChatGPT Work, Codex, OpenAI API 등에서 제공되며, Codex에서는 agentic coding과 장시간 개발 작업에 활용할 수 있다. OpenAI는 코딩 작업에서 Astra가 코드 실행과 검증을 수행하도록 설계됐다고 설명한다.

OpenAI는 GPT-6 Astra를 소프트웨어 엔지니어링과 여러 단계의 복잡한 작업을 수행하도록 설계된 모델로 소개한다.

출처: OpenAI

이런 모델을 사용할 때 구현만 요청하고 끝내는 것은 아깝다.

기능을 만든 다음에는 별도의 검증 작업을 요청할 수 있다.

예를 들면 이런 식이다.

“지금 구현한 기능이 처음 요구사항을 모두 충족하는지 다시 확인해줘.”

“직접 실행 가능한 테스트를 수행하고 실패한 항목만 정리해줘.”

“기존 기능 중 이번 변경으로 영향을 받을 수 있는 부분을 찾아줘.”

“완료됐다고 판단하기 전에 아직 검증하지 않은 항목을 따로 정리해줘.”

중요한 것은 AI에게 검증을 맡겼다고 사람이 확인하지 않아도 된다는 뜻이 아니다.

AI의 검증 결과 역시 최종 판단을 위한 자료로 보는 편이 안전하다.

7. 장시간 작업에서는 상태를 남긴다

앱 제작은 한 번의 대화로 끝나지 않는다.

오늘 만든 기능을 내일 다시 수정할 수 있고, 며칠 뒤 새로운 기능을 추가하면서 이전 결정이 다시 중요해질 수도 있다.

승인된 OpenAI 공식 발표 요약에서는 Codex의 장시간 작업에서 이전 요구사항, 테스트 결과, 도구 출력 등을 다시 활용할 수 있는 컨텍스트 관련 기능도 소개하고 있다.

하지만 모델이 긴 맥락을 다룰 수 있다고 해도 프로젝트의 모든 판단을 AI 기억에만 맡기는 것은 별개의 문제다.

나는 중요한 내용은 명시적으로 남기는 편을 선호한다.

현재 구현된 기능.

아직 해결하지 않은 문제.

변경하면 안 되는 부분.

완료된 테스트.

다음에 해야 할 작업.

최근에 바꾼 구조와 그 이유.

이런 상태 정보가 있으면 다음 작업에서 다시 처음부터 설명해야 하는 범위를 줄일 수 있다.

필자가 GPT-6 Astra Work에서 Peter OS 개발 작업을 진행한 실제 화면. 기능 구현과 검증을 이어가는 실제 사용 맥락을 보여주며, 사용량 소진 상태까지 포함해 바이브코딩의 현실적인 작업 장면을 담고 있다.

내가 사용하는 Astra 바이브코딩 흐름

지금까지의 경험을 하나의 흐름으로 정리하면 이렇게 된다.

목적 정의 → 구조 설계 → 작업 분해 → 단계별 구현 → 검증 → 실제 환경 확인 → 다음 작업 기록

여기서 Astra는 구현만 담당하는 도구가 아니다.

구조를 제안하게 할 수 있고, 작업을 나누게 할 수 있고, 코드를 만들게 할 수 있고, 결과를 다시 검토하게 할 수도 있다.

하지만 전체 과정에서 무엇을 만들 것인지와 어떤 상태를 완료라고 볼 것인지는 결국 사람이 결정해야 한다.

바이브코딩을 처음 시작했을 때는 코딩을 몰라도 된다는 점이 가장 매력적으로 보였다.

지금은 조금 다르게 생각한다.

코딩을 직접 작성해야 하는 비중은 줄어들 수 있다.

그 대신 사람이 알아야 할 것이 사라지는 것은 아니다.

무엇을 만들 것인지.

어떻게 나눌 것인지.

어디까지 맡길 것인지.

무엇을 확인할 것인지.

그리고 언제 끝났다고 판단할 것인지.

좋은 모델을 쓰는 것도 중요하다.

하지만 강한 모델일수록 더 중요한 것은 그 모델이 제대로 일할 수 있는 구조를 사람이 먼저 만들어주는 것이라고 생각한다.

바이브코딩은 코딩을 몰라도 되는 시대를 뜻하는 것이 아니라, 사람이 알아야 할 것이 코드에서 완료의 기준으로 이동하는 과정인지도 모른다.