바이브 코딩으로 사내 ERP 시스템을
만들어나가길 원하는 회사 관계자 분과 미팅을 진행하며 쌓는 회고록입니다.
첫 주제는 “바이브 코딩이 뭘까” 입니다.
들어가며
최근 지인의 회사에서 코딩 에이전트를 통해 사내 ERP를 만드는 일을 진행했습니다. 특이한 점은 “비개발자들이 개발해나갈 수 있게” 하는 점이었습니다.
시제품을 만드는 것은 매우 간단한 작업이었으나, 확장성 고려가 필요했고, 부서별 수동 보고체계를 업로드하는 PoC를 거쳐, 확대될 예정이었습니다.
(회사 내 부서는 생산 / 소매 / 영업 / 안전 팀으로 구성되어 있습니다.)
따라서 새 요구사항이 들어왔을 때, 버그가 터졌을 때 관리자들이 어떻게 대응할까? 를 상상하면서 설계하였습니다. 특히 가장 주목했던 것은 비개발자(기획자)만의 SDLC를 만드는 것이었습니다.
SDLC 구축에 앞서, 제 생각에 올바른 바이브 코딩을 알려드리는 것이 중요하다 생각이 들었고, 첫 주제는 바이브 코딩에 대하여 주로 다루었습니다.
SDLC(소프트웨어 개발 수명 주기)는 소프트웨어를 계획, 개발, 테스트, 배포하기 위한 구조화된 프로세스입니다.
바이브코딩에선 예를 들어 브레인스토밍 → 디자인 → 기술 결정 → 개발 → 테스트 라는 사이클을
만들어, 개발 지식이 없더라도 안정적인 기능 개발 과정을 수립할 수 있습니다.
바이브 코딩에 대한 이해
바이브 코딩을 한 문장으로 정의하면 "프롬프트로 코딩하는 것"입니다.
하지만, 바이브 코딩이 익숙하지 않다면 좋지 않은 프롬프트로 빠지기 좋다고 생각합니다.
실제 미팅을 통해서, 직원분들의 프롬프트를 살펴보았었고, 문제점도 파악해 보았습니다.
크게 두가지 문제가 발견되었는데요.
- 첫 프롬프트를 1000줄로 전송
- “내가 아는 언어” 가 아닌 AI의 도움을 받은 “디자인 시스템 구성, DB 스키마”에 대한 프롬프트 전달
두 프롬프트 모두 이상적으로 작동한다면 최고겠지만, 1000줄의 내용엔 AI Slop (영양가 없는 AI 가 증강한내용물)이나, 정확하지 않을 수 있습니다.
따라서, 초기 프롬프트는 두가지 특징을 띄고 있어야 한다고 생각합니다.
- 내가 가장 잘 언어로 설명하기
- 논의를 유도
- 결과물을 기록하기
내가 가장 잘 아는 언어로 설명하기
“프롬프트 잘 쓰는 법” 에 대한 검색을 하면 대부분 프롬프트 엔지니어링에 대한 주제들이 나옵니다.
- 예시를 들어보세요.
- AI 에게 역할을 부여해보세요.
- 규칙과 제약을 걸어보세요.
하지만, 대부분 이런 프롬프트 엔지니어링은 과거 “일회성 에이전트 사용”에 초점을 맞추고 있고, 현재 추론 모델의 성능 + Agent Loop 형식으로 돌고 있는 코딩에이전트에서 이런 개념을 몰라도 퀄리티가 보장된다고 생각합니다.
클로드 코드의 실제 구조를 살펴 보았을 때, 모호하면 되물어보고, 검증하며 반복합니다. 여기에 더해 모델은 추론하여 정보량을 늘려나갑니다. 따라서 구체적으로만 문제를 정의한다면, 나머지는 에이전트에 맡기면 원하는 결과물을 얻을 수 있을거라 생각합니다.
그렇다면 구체적인 프롬프트는 어떻게 정의할까요?
내가 가장 잘 아는 정보를, 내가 가장 잘 아는 언어로 설명하는 것
- 디자이너라면 → 본인이 그린 와이어프레임
- 기획자라면 → 핵심만 요약된 기획
- 개발자라면 → 기술 명세를 통한 문제 해결 정의
그리고 부족한 나머지는 AI에게 맡기는 방식입니다. 디자인이 없으면 AI가 그려줄 것이고, 기획이 부족하면 논의하여 디테일을 정하면 됩니다.
예시로, 저는 개발자이기 때문에 기획 + 디자인은 최대한 AI를 빌려 쓰려 합니다.
안 쓰는 프롬프트 | 쓰는 프롬프트 |
컬러 팔레트에서 맘에드는 디자인 컬러를 지정 | "가시성이 돋보이게 포인트 컬러 골라줘" |
화면 구조를 일일이 매김 | "사용자는 대부분 모바일 환경일 거야. 작업 중에 쉽게 입력 가능해야 해. 화면 구성 네가 아이디에이션하고 나와 논의하자." |
에이전트와 논의하기
개발 초기에구체적인 프롬프트로 에이전트와 대화를 시작했을 때, “바로 구현해줘” 라는 지시보다는, “논의 해줘” 라고 해야합니다.
논의를 거친다면 몇 가지 단계를 거쳐 사용자가 납득 가능한 컨텍스트로 구체화 할 수 있습니다.
미팅에서는, 간단한 템플릿을 드리고 AI Agent와의 논의를 해보면서 그 장점을 느꼈습니다.
<내가 원하는 주제> - <설명> ### 1. 핵심 요구사항 서비스의 기능을 나열하거나, 핵심 워크플로우 전달 ### 2. 구현 디테일 모바일, 데스크탑에 지원여부와 같은 플랫폼 환경 디자인 레퍼런스 ### 3. 제약조건 생각한 개발 기한 외부적인 제약사항 --- 지금부터 위 요구사항을 여러 시각으로 다루며, 구체적인 구현을 논의할 것이다. 해당 워크플로우 대로 논의를 시작하자. 1. 구체적인 요구사항 논의 2. 기술 결정사항, 아키텍처 정의 3. 디자인 정의
해당 프롬프트를 통해서, 실제 논의를 진행하면, 구현 난이도와 맞는 세부 기획사항들을 AI에게 검증받을 수 있습니다. 부족한 기획사항은 채우고, 개발 단계에서 어떤 식으로 구현될지에 대한 기술적인 결정사항을 사용자의 머릿속에 그려보는 단계라고 생각합니다.
또한, 위 논의 화면은 바이브 코딩 경험에서도 가장 많이 보고, 유도해야 하는 단계라고 생각합니다.
기술, 기획, 디자인 컨텍스트를 차근차근 쌓아가며 엉뚱하지 않은 프로덕트를 만드는 과정입니다.
물론, 비 개발자도 이 과정에서 기술적 지식을 공부할 수 밖에 없습니다. 관련 대화도 실제 미팅에서 나누었는데요.
이는 맨 아래 여담 섹션에 적어두었습니다.
문서화 하기
- 기획의 세부사항들을 짚음
- 기술 결정사항을 정함
- 디자인 포인트를 짚음
등의 논의를 앞에서 거쳤다면, 문서화를 진행해야 합니다.
이유는 코딩 에이전트를 통해 대화를 이어간다면, 해당 대화는 모델이 중요한 맥락을 잃습니다. 보통 다음과 같은 상황에서 잃게 됩니다.
- 세션을 종료할 때
- Context Window가 꽉 찼을 때
따라서, 언제든지 클로드 세션이 새로 만들어 졌을 때, 사용자와 모델이 “중요하다고 생각하는 정보”들을 모두 문서화 해야 합니다. 이를 만드는 방법은 간단한데요.
지금까지 나눈 내용을 기반으로 알맞게 문서화 해줘.
해당 프롬프트를 입력하게 되면 폴더 내에 보통
/docs 내부에 여러 파일들이 생겨납니다. 파일은 사용자와 모델이 나눈 대화에 기반하여 늘어날 것입니다. 이제 이 문서를 로딩하기만 하면, 모델은 언제든지 프로젝트의 중요 내용을 읽어 볼 수 있습니다.마무리
여기까지 바이브 코딩에 대한 간단한 소개부터, 하네스 엔지니어링의 밑바탕인 “문서화”까지 다루어 보았습니다.
실제 ERP를 개발하는 과정은 이번에 다루지 않았습니다. 실제 개발에 들어가기 앞서 “바이브 코딩” 에 대한 일반적인 개념과 과정을 주로 설명했기 때문인데요.
따라서 다음 편에는 회사 내부와 유사한 환경을 직접 바이브 코딩 해보면서, 실제 하네스 엔지니어링을 통해 어떠한 SDLC를 구현했는지 정리하려고 합니다. 크게 다음과 같은 주제로 구성할 예정입니다.
프로토타입까지 SDLC 구성 & 개발
- 프로토타입까지 비 개발자의 입장에서 이해할 수 있는 SDLC 구축
- 개발 진행, SDLC의 효과 검증 & 개선
- 개발자가 없는 상황에서도 추가 기능 개발 가능한 시스템 구축
여담: 바이브코딩 관련 학습 방향에 대하여
추가적인 여담을 나누면서, 바이브 코딩을 접하고 공부 방향을 어떻게 잡지? 라는 이야기가 나왔습니다.
확실히 답변을 하기 어렵지만, 제가 생각했을 때의 의견을 전달해드렸습니다.
핵심은 “프로젝트의 Agent와 대화하기” 인데요.
먼저 안 좋은 학습 예시를 생각해보고, 다음과 같은 예시를 전달드렸습니다.
- 바이브 코딩 관련 CS 강의를 들으면서 “개발자” 처럼 학습하기 → ❌
- Next.js 도입 효과를 리서치 → ❌
이유는 바이브 코딩의 방향은 최대한 모델을 레버리지한 형태라고 생각합니다. 코드 퀄리티나, 시스템 디자인도 날이 갈수록 풍요로워져왔고, 잘 짜줍니다. 이를 일일히 바이브코더가 이해한다는 것은, 개발자를 준비하는 과정과 유사해 질 것 같습니다.
대신 이런 방향을 권했습니다.
- 내 프로젝트에서 내 Agent와 기술적 궁금증 해소하기
- 원리를 최대한 쉽게 설명해달라 부탁하기 (만화로 그려서 봐도 좋을 것 같습니다)
- 새로운 바이브 코딩 트렌드를 학습하기 → 체감상 3개월이면 새로운 개념이 등장합니다