Vibe Coding 개발 방법에 대해 (1)
바이브코딩을 할 때는 이런 거 생각하면 좋을 것 같아요!
Vibe Coding
바이브 코딩은, ai에게 자아를 의탁하는 행위다. 코드의 내부를 인간이 아니라 AI가 헤집고다닌다. 때문에 인간과 비교도 할 수 없을 만큼 엄청난 양의 코드를 생산할 수 있다. 물론 “코드”를 생산한다는 것이다.
아마 개발해보면…
AI없이 개발을 해본 사람이라면 아마 체감이 들 것이다. 정말 빠르고 쉽게 내가 원하는 걸 잘 짜주는 것 같은데… 한계가 있다! 말을 하다보면 진짜 듣지를 않는다. 내가 원하는 걸 찰떡같이 알아들어줬으면 좋겠지만, 늘 그렇지는 않다. 진짜 답답할 정도로 못 알아들을 때는 진짜 화가 날 정도다. 대체 왜 그런 걸까. 나는 나름 말을 잘 해줬던 것 같은데.
AI는 어떻게 생각하는 걸까?
멘토님께서도 이런 고민을 많이 하신 것 같았다. 대체 무슨 생각을 하길래 이렇게 답답한 거지? 우리는 이런 대화형 AI의 생각방식에 대해 조금 더 자세히 분석해볼 필요가 있다. 그래야 조금이라도 답답한 게 가실 것 같았다.
AI는 한 번에 목표로 가는 생각을 할 수가 없다. 애초에 그게 가능한 인간도 몇 없기도 하다. 생각은 반드시 Step by Step, 단계적 절차가 있어야하고, AI 역시 단계를 두어 생각을 두는 방식으로 진행한다. 우리의 목표가 우리가 정한 골에 가는 긴 여정이라면, AI는 그 사이사이에 마일스톤을 두어, 그 과정을 개발할 수 있도록 크기를 나눈다는 얘기다. 굉장히 합리적인 방식이고, 그렇기 때문에 아마 AI가 그 방식을 채택한 게 아닐까.
그런데 그게 왜?
문제는, AI가 제대로 Step by Step을 거치지 않은 경우에 생긴다. AI는 정답을 알고 있는 해설지가 아니다. AI는 예측기다. 사람들이 많이 했던 것들을 기반으로 다음 스텝을 예측하는 예언자에 불과하다. 그리고, 예측기는 틀릴 가능성이 있다. 현재같이 불안정한 과도기는 더욱 그렇다. AI는 본인이 아주 알맞은 단계를 밟고 있다고 생각하고 있지만, 마일스톤이 우리가 생각한 최적루트와 전혀 다른 방향을 가려할 수도 있다.
AI의 생각에는 관성이 있다!
마일스톤의 위치가 중요한 이유는, AI의 관성때문에 그렇다. 마일스톤은 마치 자석과도 같아, 한 번 박힌 마일스톤은 좀처럼 AI의 머릿속에서 없애기가 어렵다. 하얀코끼리를 상상하기 어렵듯이, AI가 한 번 떠올린 마일스톤은 바꾸기가 더럽게 어렵다.
마일스톤을 옮겨서 제대로 된 루트에 올려놓기만 한다면, 분명 AI는 엄청난 생산량을 자랑할 것이다. 그러나 어떻게? 우리는 두 가지 문제가 있다.
- 마일스톤의 위치가 올바른지 개발자인 우리도 사실 잘 모른다.
- 어디에 마일스톤을 설치했는지 AI는 우리에게 공유하지 않는다.
1번의 경우는… 솔직히 안타깝지만, 아직은 명시적인 해결책을 찾을 수 없었다. 완벽한 해답을 찾을 수 없는 건 알지만, 그럴 듯한 솔루션조차 찾지 못한 건, 주니어 개발자로서 아직 부족한 역량이라고 생각한다. 그러나 2번의 경우는 멘토님께서 강력한 방법론을 가져와주셔서 아래에 기술하고자 한다.
프롬프트 리포트
멘토님께서는 프롬프트를 보고서의 형식으로 뽑아보는 게 유효한 전략이었다고 설명을 주셨다. 당장에 내가 보기에도 상당히 크리티컬하다고 생각했다. 어떻게 이런 아이디어를 찾으신 건지, 역시 주니어 개발자는 부족한 점이 많다고 생각했다. 실제 현업에서도 코드를 직접 보고받지 않고, 진척사항 및 개발목표 들을 데일리나 위클리 리포트로 보고받는다고 하셨다. 이 방법을 AI에게도 적용했더니, 유의미한 결과가 나왔다고 했다.
제미나이한테 한 번 여태 개발한 내용을 보고서로 작성해보라고 했다. 그랬더니 개발 보고서를 예쁘게 작성해주었다. 멘토님께서는 Claude Code를 이용해서 마크다운 파일로 만들 수 있도록 더욱 정교한 모델을 제시해주었다. 프롬프트를 시각화해서 현재 어떤 것들이 맥락으로 들어갔는지, 그리고 어떤 걸 수정해주어야 하는지를 확실하게 알 수 있었다.
이런 식으로 하면 또 좋은 점이 있다. 새로운 AI 에이젼트가 오더라도, 맥락을 빠르게 학습시킬 수 있다는 것이다. AI는 본인이 이해할 수 있는 프롬프트의 한계가 있기 때문에, 주기적으로 캐시를 지우면서 새로운 프롬프트를 받는다. 그러다보면 기존에 학습된 내용이 지워질 수 있는데, 그러다보면 맥락이 흐려지게 된다. 그러나 정적파일로 리포트를 남겨두게 되면, 설사 에이전트가 바뀌더라도 그것을 읽어내면 되기 때문에 문제가 되지 않는다. 내가 학습시키고자 하는 프롬프트를 시각적으로 보고, 정적으로 저장할 수 있다는 강력한 장점이 있다.
결론
바이브 코딩에서는 프롬프트 엔지니어링이 굉장히 중요해보인다. 이번에 다룬 방식은 프롬프트를 리포트로 남기는 방식에 대한 얘긴데, 나중에 진짜 프로젝트에 대한 내용을 다루면, 더 구체적인 사례를 통해서 말해줄 수 있을 것 같다.