DEV Community

Cover image for 바이브코딩으로 10일 만에 완성한 자동화 도구 개발기
오승연
오승연

Posted on

바이브코딩으로 10일 만에 완성한 자동화 도구 개발기

2025년 7월 18일에 작성된 글입니다.

피드백 생성 동작

1. 바이브코딩으로 개발을 결심하기까지

반복되는 업무, 반복되는 고통

부트캠프에서 모의면접 멘토로 활동하며, 가이드대로 멘토링을 진행하고 있다. 준비하고 진행하기까지는 순조로운데, 이후 진행한 내용을 리포트로 정리해 제출해야 한다.

여기서 고통이 시작된다. 리포트 작성에 멘토링 이상의 시간이 소요된다는 것이다.

면접 중에는 멘티의 답변을 실시간으로 타이핑한다. 빠르게 치다 보니 오타가 많고, 마무리하지 못한 문장도 많다. 면접이 끝나면 메모한 내용을 자연스러운 문장으로 다듬어야 한다.

답변에 대해 피드백도 제공하는데, 멘토링 중에는 말을 함과 동시에 타이핑을 해야해서 단어 정도만 메모하고, 나중에 다시 답변을 읽으며 상세한 피드백을 작성한다. 이미 구두로 전달한 내용을 다시 떠올리는 과정이 반복된다.

자동화 가능한 지점 발견

이 과정에는 두 가지 패턴이 있다.

1. 답변 정제 작업

  • 오타 수정과 문장 완성
  • 일관된 문체로 수정
  • LLM을 통해 수정: 메모한 답변 복사+붙여넣기 → 수정 요청 → 정제된 답변 복사+붙여넣기

2. 피드백 작성 작업

  • 기술 내용에 대해 잘 파악한 점과 틀린 점 작성
  • 소프트스킬(답변 형식과 태도)에 대해 좋은 점과 아쉬운 점 작성

둘 다 형식적이고 반복적인 작업이다. 이미 LLM을 활용하고 있었지만 매번 동일한 프롬프트를 요청했고, 복붙 과정까지도 자동화하면 더 시간을 단축할 수 있겠다는 생각이 들었다.

바이브코딩에 대한 관심

얼마 전 바이브코딩 강의를 수강했다. (커서 IDE 유료 결제도 했으니 뽕을 뽑아야 했다. 😃)

강의는 준비된 프롬프트로 간단한 프로젝트를 개발하는 실습 위주로 진행됐다. 하지만 툴 사용이 익숙하지 않고 개발 프로젝트에 대한 이해도 부족해서 주도적으로 작업하기보다는 따라하며 익숙해지는 시간이었다.

이번 프로젝트가 수강한 내용을 직접 적용해보며 AI 활용 방법을 체감하기에 적합해 보였다.

참고로 내가 생각하는 바이브코딩은 AI에 의존해 기획과 개발을 하지만, 필요한 부분에서는 직접 코드 수정과 디버깅을 하면서 작업하는 것이다. (25.10.20 현시점 증강 코딩이라고 하더라.)

2. AI와 함께하는 기획부터 개발까지

문제 정의부터 다시 시작

작업의 첫 단계는 문제를 명확히 하는 것이었다. "자동화 툴을 만들려고 해. 문제 정의 단계를 하려는데 어떻게 시작하면 좋을까?"라고 하니, AI가 구체적인 질문들을 던져왔다.

  • 현재 가장 반복적으로 하고 있는 작업들이 무엇인가요?
  • 하루 중 어떤 작업에 가장 많은 시간을 쓰고 계신가요?
  • 어떤 작업이 가장 번거롭고 시간이 오래 걸리나요?
  • 완전 자동화 vs 반자동화 중 어느 방향을 선호하시나요?

이런 질문들에 답하면서 요구사항이 구체화되었다. 두루뭉술했던 아이디어가 명확한 기능 명세로 바뀌었다.

기술 스택 선택

어떤 형태의 애플리케이션으로 개발할지 고민하면서 AI에게 후보를 추천해달라고 했다.

내 개발 경험과 요구사항을 고려해서 세 가지 옵션을 제시했다. 각각의 장단점과 적합도까지 정리해줘서 따로 조사하지 않고 여러가지를 고려해볼 수 있었다.

최종적으로는 크롬 확장 프로그램으로 결정했다. 리포트 작성 툴이 구글 스프레드 시트라 별도 웹앱으로 개발하지 않고 헬퍼 도구로 사용하고자 했다.

  • Chrome Extensions
  • 번들러
    • Vite (+ HMR을 위해 crxjs)
  • 라이브러리
    • Google Sheets API: 구글 시트에서 데이터를 읽고 쓰는 용도
    • Gemini API: 텍스트 수정 작업 용도
    • React, Tailwind CSS: 확장 프로그램의 팝업 UI를 편리하게 개발하기 위한 용도
    • Vitest: 테스팅 용도

개발 워크플로우의 변화

기존 개발 방식과 가장 큰 차이점은 룰 파일을 생성하는 것과 기술 학습 시점이었다.

  • 이전 방식: 기획 → 필요한 기술 학습 → 개발 → 막히면 다시 학습
  • 바이브코딩 방식: 기획 → 룰 파일 생성 → 개발 → 필요한 부분 학습

바로 구현하기 전에 룰 파일을 생성하고 태스크를 정의했다. 각 태스크마다 테스트 코드를 먼저 작성하고, 구현하고, 검증하는 사이클을 반복했다.

React, Tailwind CSS를 제외하곤 처음 다루는 기술이 많아 그때그때 필요한 부분만 찾아보며 진행했다. (이는 시행착오의 아픔이 되었다.)

3. 점진적 개선 과정

초기 MVP에서 겪은 시행착오

처음에는 AI가 제안하는 대로 계속 진행했다. (노룩 Run command ⌘⏎)

TDD를 준수해 개발하도록 룰을 설정했기 때문에 테스트 코드는 통과하지만 실제로 구동해보니 동작하지 않았다. 내가 생각한 기능 범위를 벗어나 복잡한 구조로 작성하는 것도 많았다.

여러 번 작업을 복구하면서 깨달았다. 작업자인 인간이 통제권을 가지지 않으면 프로젝트가 산으로 간다.

통제권 회복하기

이후 접근 방식을 바꿨다.

  • 태스크를 더 작은 단위로 나누기
  • 각 태스크마다 동작 확인 필수
  • MVP라는 점을 계속 강조하기
  • 복잡한 기능은 과감히 제거

AI에게 완전히 맡기지 않고 명확한 지시를 주고 결과를 검토하는 방식으로 변경했다.

리팩토링에서 배운 교훈

MVP로 빠르게 만든 코드는 당연히 거칠었다. 사용하지 않는 메서드들, 일관성 없는 구조, 불필요한 타입 정의들이 많았다.

이미 AI에게 일임해 한차례 산으로 갔기 때문에 이번엔 직접 구조를 파악하며 수정하기로 했다. 그러기 위해서는 사용하는 기술의 방법을 알아야 했기에, 크롬 확장 프로그램 구조, 개발 가이드, 라이브러리 API 사용법들을 학습했다.

작은 범위에 한해서는 AI를 활용했다. (커서 IDE 요청 수를 아끼려고 Gemini CLI를 썼다. 나쁘지 않다.)

  • 사용하지 않는 코드 식별
  • 일관성 있는 구조로 수정할 때 코드 리뷰 요청
  • 폴더 구조 정리 및 import 경로 수정

단순 반복 작업은 AI가 정확하게 처리했다. 하지만 넓은 범위의 구조적 개선은 여전히 인간의 명확한 판단과 지시가 필요했다.

4. 결과 및 소감

리포트 작성 시간 단축

  • 기존: 1시간 20분 (답변 수정 20분 + 피드백 작성 1시간 이상)
  • 자동화 도구 사용 후: 20~40분
    • 답변 정제: 20초
    • 피드백 작성: 20~40분 (AI 피드백 생성 시간은 2분이지만 참고해서 작성하는 방향으로 진행)

기존 1시간 20분에서 최소 20분으로 업무 시간이 절반 이상으로 단축되었다.

AI가 잘하는 일 vs 못하는 일

바이브코딩 강의 중 강사님께서 이런 말씀을 하셨다.

“AI의 능력을 파악하세요. 바이브코딩을 반복하면서 AI가 잘하는 일, 못하는 일에 대한 경험치를 쌓으세요.”

  • 직접 경험해보니, AI가 잘하는 일은 다음과 같았다.
    추상적인 아이디어를 구체화하는 것, 핵심 요약과 정리, TDD 등의 개발 원칙을 준수해 코드를 작성하는 일, 패턴이 명확한 반복 작업, 여러 선택지를 비교하고 그 이유를 논리적으로 설명하는 일 등이 있었다.

    이런 점은 나처럼 완벽주의 성향이 있는 사람이 모호한 생각만 가지고도 일단 시작할 수 있게 만들어준다는 점에서 정말 큰 장점이다.

  • 반면, AI가 잘 못하는 일은 다음과 같았다.

    복잡하고 큰 규모에서 일관성을 유지하며 처리하는 일, 실제 동작 환경에서의 디버깅, 프로젝트의 성격이나 사용자 관점을 고려한 개선과 같은 것이다.

    사실 말로 설명할 수 있는 작업이라면 대부분 AI가 잘 해낼 거라고 생각한다. 그래서 ‘못하는 일’이라도 지시만 잘하면 상당 부분 해결할 수 있을 것이다.

결국 강사님 말씀처럼 AI와 함께 작업하며 경험치를 쌓아가고, 잘하고 못하는 일을 구분하면서 AI가 더 잘 일할 수 있도록 활용하는 방법을 익히는 게 중요하다는 걸 느꼈다.

지속 가능한 코딩 에이전트 활용 방법

10일간의 경험을 통해 얻은 인사이트를 정리하며 글을 마무리하고자 한다.

  1. AI의 모든 결과물은 반드시 리뷰할 것
    줄 단위까지 세세하게 이해할 필요는 없지만, 전체 구조와 핵심 로직은 파악해야 한다.

  2. 작업의 통제권은 작업자인 사람이 가질 것
    태스크 단위로 진행 상황을 점검하고, 복잡해질 땐 단순화하는 판단이 필요하다.

  3. (새로운 기술을 사용할 경우) 구조를 이해하고 실제 개발에 들어갈 것
    실전에 쓰기 전에 간단한 실습을 통해 구조와 동작 방식을 먼저 익힌다.

Top comments (0)