비개발자를 위한 Vibe Coding 미로 탈출 가이드

요즘 알고 지내는 비개발자들이 Vibe Coding/Agentic Coding에 푹 빠져 사는게 보인다. 나에게도 AI는 내 아이디어를 실현해 주는 구세주와 같다. 하지만 여러 가지 개발을 해보다 보니, 어느 정도 개발이 진행되다 보면 "AI가 왜 답답하게 굴지?" 혹은 "고쳤다는데 왜 똑같은 에러가 나지?" 같은 도돌이표 상황에 빠지게 된다. 새삼, 개발자들이 AI가 만든 코드를 완전히 믿지 못한다는 것도 공감이 가기도 한다.

내 경험을 기반으로 '바이브 코딩(Vibe Coding)'의 한계를 넘어서, 프로젝트를 끝까지 완수하게 만드는 실전 팁을 정리했보았다.

1. AI가 제자리걸음을 할 땐 '피드백'을 요청하자

AI가 비슷한 코드가 너무 오래 걸린다거나, 혹은 문제 수정 상황이 반복되는 느낌이 있다면, 어떻게 하는가? 그렇다면 대화의 주도권을 가져와야 한다. 피드백을 달라고 요청해야 한다.

• 설명 요청: AI로 생성한 코드가 시간이 오래 걸리는 경우가 종종 있다. 그럼, 세우고 "어떤 동작을 하고 있는지 사용자가 알수 있도록 해줘"라고 해보자. UI로 진행 상황을 표현하기도 하고, Command Line Interface(CLI) 코드라도 중간 진행 사항을 알려준다.
• 회고 요청: "지금 상황을 설명해줘", "지금까지 시도한 방법들을 요약해줘", 혹은 "왜 실패했는지 네 생각을 말해줘"라고 시켜보자.
• 관점 전환: "지금 방식 말고 아예 다른 접근 방식 3가지만 제안해 봐"라고 요청하면, AI가 스스로 고정관념에서 벗어나 새로운 길을 찾기도 한다.

계속 같은 상황을 반복시키는 것은 토큰 낭비이기도 하지만, 귀중한 우리의 시간도 낭비하고 있게 된다.

2. AI의 눈과 귀가 되는 상세한 '로그(Log)'

개발자들이 디버깅한다는 이야기를 많이 들어보았을 것이다. 여러 가지 방법이 있지만, 가장 많은 방법이 로그를 확인하는 것이다. 우리도 내 컴퓨터 안에서 무슨 일이 일어나는지 모르지만, AI도 마찬가지이다. 문제가 일어나는 상황을 정확히 전달해야 한다.

• 로그 추가 요청: 에러 원인을 모를 땐 "어디가 문제인지 알 수 있게 로그(console.log 등)를 추가해 줘"라고 하자.
• 환경별 대응: 브라우저 콘솔, 서버 터미널, 심지어 모바일 앱에서도 로그를 뽑아 AI에게 먹여주면 정답률이 비약적으로 올라간다.

3. '정책(Policy)'과 '패턴(Pattern)' 문서화

개인적으로는 Claude Code를 초기에 많이 써서, 개발 방법을 CLAUDE.md에 저장해 두고 쓴다. 개발 세션을 시작할 때, 이런 약속들을 상기 시키고 시작한다. 하지만, 시간이 지나가거나 프로젝트가 커지면 AI는 이전에 약속했던 규칙(예: 디자인 스타일, 변수 이름 규칙 등)을 잊어버린다.

• 규칙 저장소: 반복적으로 지켜야 하는 정책이나 코드 패턴은 별도의 .md 문서(예: POLICY.md)로 정리하자.** 최근에는 LLM을 통해 생성한 결과를 json으로 받을 때, 예외가 많이 생기고 해서 이 부분을 해결하는 부분을 공통코드로 만들었다. 이 때, 패턴 문서를 만들어 AI가 참고하도록 하고 있다.
• 참조 지시: "새 기능을 짤 때 항상 POLICY.md 문서를 참고해서 작성해 줘"라고 지시하면, 프로젝트의 일관성이 유지되고 나중에 코드를 갈아엎는 불상사를 막을 수 있다. 최근에 pdf를 생성하는 규칙도 반복되니 정책(Policy)라는 이름으로 markdown 문서를 생성하고 참고하게 했다.

4. GitHub 저장소 활용: AI와의 협업에서 '세이브 포인트' 만들기

컴퓨터로 작업하는 사람들이 공동적이면서 기본으로 말하는 작업의 가장 중요한 부분은 백업인 것 같다. 개발자에게 backup에 해당하는 것이 코드 저장소라고 할 수 있다. Agentic Coding에서 코드 저장소(Repository)는 단순히 코드를 보관하는 창고가 아니다. AI와 대화하며 코드를 고치다 보면, 잘 되던 코드가 갑자기 엉망이 되어 "어디서부터 잘못됐지?"라고 자책하게 되는 순간이 온다.

• Commit은 '세이브'이다: 기능 하나가 성공적으로 구현될 때마다 Commit(기록)을 남기세요. "로그인 기능 구현 완료"라고 적어두면, 나중에 AI가 사고를 쳐도 클릭 한 번으로 가장 완벽했던 상태로 되돌아갈 수 있다.
• AI에게 과거를 보여주자: "이전 버전에서는 잘 작동했는데 지금은 안 돼. 이전 코드랑 비교해서 뭐가 달라졌는지 분석해 줘"라고 요청할 수 있다. GitHub에 기록된 히스토리는 AI에게 가장 강력한 학습 데이터가 된다.
• Branch로 실험하기: 새로운 기능을 시도할 때는 기존 코드를 건드리지 말고 '새 가지(Branch)'를 치자. 마음껏 실험하다가 망하면 그냥 삭제하고 원래 가지로 돌아오면 그만이다. 비개발자가 '두려움 없이' 코딩하게 만드는 가장 큰 힘이다.
• 버전 관리 도구 활용: git의 "터미널 명령어가 어렵다면 앱을 사용해도 좋다. VS Code도 기본적인 git/github 연동은 잘 되는 편이다.

5. Playwright로 '자동 검사기' 세우기

나도 마찬가지이지만, 비개발자가 가장 무서워하는 것은 "하나를 고쳤는데 기존에 잘 되던 기능이 망가지는 것"일 것이다.

• End to End (E2E) 테스트: Playwright를 사용해 사용자의 클릭과 이동 경로를 테스트 코드로 짜달라고 하자. 명령어 한 줄 혹은 자동화 기법으로 추가 개발한 내용이 기존 동작을 망가뜨리는지 확인할 수 있다.
• 안전장치: 새 기능을 넣은 후 테스트를 돌려 "기존 기능이 여전히 안전함"을 확인받는 순간, 코딩에 대한 막연한 공포가 자신감으로 바뀌게 된다.

6. GitHub Actions로 '24시간 관리자' 채용하기

위와 같은 E2E 테스트를 내가 직접 테스트를 돌리는 것조차 잊어버릴 수 있다. 이때 GitHub Actions가 해결책이 된다.

• 자동화: 코드를 올릴 때마다 서버가 자동으로 Playwright 테스트를 실행해 "합격/불합격"을 알려준다.
• 신뢰도: 시스템이 "이 코드는 안전하다"라고 보증해 주니, AI의 코드를 훨씬 더 믿고 빠르게 수용할 수 있다.

Vercel과 같은 서비스는 github action과도 잘 연계가 되어서, 내가 수정한 사항을 github에 적용하면 자동으로 배포해 준다.

개발의 최종 목표는 '시스템'

단순히 AI에게 코드를 짜달라고 하는 단계를 넘어, 나만의 검증 시스템과 규칙을 갖추게 되면 상용 수준으로 올라가는 기본이다.

1. 전략 회의: 막힐 땐 AI에게 해결 전략을 묻기.
2. 철저한 기록: 로그와 정책 문서화로 AI에게 컨텍스트 제공하기.
3. 자동 검증: Playwright와 GitHub Actions로 안전장치 만들기.

이 시스템만 갖춰지면, 비개발자도 수만 줄의 코드를 가진 복잡한 서비스를 전문가처럼 안정적으로 운영할 수 있는 기본을 갖추게 된다. 이제 AI는 단순한 도구가 아니라, 여러분의 든든한 '엔지니어링 팀'이 될 것이다.