본업 틈틈이 개인 개발을 계속하다 보면, "떠오른 아이디어를 구체화할 시간이 없다"라는 벽에 몇 번이고 부딪히게 됩니다. AI(Gemini, Claude 등)와 대화하며 코드를 작성하는, 이른바 "바이브 코딩 (Vibe Coding)"을 실천하게 되면서 상황은 변했지만, 처음에는 "일단 통째로 맡기기"를 해버려서 기대와 다른 구현이 돌아오고 재작업이 다발하는 실패를 반복하고 있었습니다.

본 기사에서는 시행착오 끝에 도달한 "AI에게 의뢰를 던지는 패턴"을 재현 가능한 형태로 언어화합니다.

현재는 하나의 기능 추가당 "요건 분할 → 각 분할 단위로 AI에게 구현 의뢰 → 동작 확인 → 통합"이라는 4단계 패턴으로 정착되었습니다. 한 번의 프롬프트 (Prompt)로 다루는 범위를 작게 유지함으로써, 재작업 횟수가 크게 줄었습니다.

의뢰를 던질 때는 다음 4가지를 반드시 포함하도록 하고 있습니다.

현재 상태: 무엇이 동작하고 있고, 무엇이 아직 없는지 -
하고 싶은 것: 한 문장으로 단정 지을 수 있는 입도(Granularity)까지 분할한 것 -
제약 조건: 건드리지 않았으면 하는 파일이나, 지켜주었으면 하는 규칙 -
확인 방법: 어떻게 동작해야 성공이라고 말할 수 있는지

실제로 사용하고 있는 템플릿을 추상화한 것입니다.

[현재 상태]
〇〇을 수행하는 함수는 이미 존재하지만, △△ 케이스를 고려하지 않고 있다.
[하고 싶은 것]
...

가장 큰 실패는, "대략 이런 느낌으로"라는 입도가 거친 의뢰를 던지고, AI의 구현을 리뷰하지 않고 그대로 채택해 버린 것이었습니다. 동작하는 것처럼 보여도 엣지 케이스 (Edge Case) 고려가 누락된 경우가 많아, 나중에 버그로 밝혀졌습니다.

이후로는 AI가 작성한 코드도 내가 작성한 코드와 동일한 기준으로 리뷰한다는 규칙을 철저히 지키도록 하고 있습니다. "AI가 작성했으니 맞을 것이다"라는 선입견을 버리는 것이 결과적으로 가장 빠른 지름길이었습니다.

의뢰의 입도를 작게 하고, 리뷰를 생략하지 않는 것. 당연해 보이지만, 이를 패턴으로서 명문화함으로써 개인 개발의 속도와 품질을 양립할 수 있게 되었습니다. 다음에는 이 패턴을 사용하여 실제로 Google Apps Script (GAS)와 Gemini API로 매일 아침 메일 발송을 자동화한 사례를 소개하겠습니다.