제안서 AI 에이전트 개발도전기 1편

10년차 수주제안컨설턴트가 바이브코딩으로 제안서 AI 에이전트를 만들어봤다.

코드를 몰라도 괜찮다고? AI와 대화하면서 원하는 서비스를 만들 수 있다는 얘기에 솔직히 반신반의 했다. 하지만 해봤다. 감동도 있었고, 벽도 있었다. 그 경험을 그대로 적어본다.

나는 왜 직접 만들려 했나

수주제안 컨설팅을 10년 넘게 해오면서 가장 반복적으로 하는 일이 있다. RFP를 분석하고, 고객을 이해하고, 경쟁사 전략을 가늠하고, 차별화 포인트를 찾고, 그것을 제안서의 언어로 풀어내는 것이다. 매번 새로운 프로젝트지만, 이 흐름 자체는 크게 다르지 않다.

ChatGPT가 나왔을 때부터 이 반복적인 흐름의 일부를 AI가 도울 수 있지 않을까 생각했다. 처음엔 단편적으로 썼다. 스토리라인 아이디어를 얻거나, 문구를 다듬거나, 경쟁사 전략을 가상으로 시뮬레이션하는 식으로. 도움이 됐다. 그런데 늘 아쉬움이 남았다. 매번 처음부터 맥락을 설명해야 했고, 내가 중간에서 계속 연결해줘야 했다.

그래서 생각했다. 이 흐름 자체를 하나의 에이전트로 만들 수 있지 않을까? RFP를 넣으면 전략 방향을 제안하고, 목차를 잡고, 섹션별 내용까지 이어지는 흐름으로…

---

바이브코딩이란 무엇인가

바이브코딩(Vibe Coding)은 코드를 직접 작성하는 대신, AI에게 원하는 것을 말로 설명하면서 서비스나 기능을 만들어가는 방식이다. 개발자가 아닌 사람도 자신이 구상하는 서비스의 초안을 빠르게 만들어볼 수 있다는 점에서 최근 주목받고 있다.

핵심은 대화다. “이런 기능을 만들고 싶다”, “이 버튼을 누르면 이렇게 작동했으면 좋겠다”, “여기서 오류가 나는데 어떻게 고치면 될까” — 이런 식으로 AI와 주고받으면서 코드가 만들어진다. 내가 코드를 이해하지 못해도, 원하는 결과를 설명할 수 있으면 된다.

바이브코딩을 시작하기 위해 알아야 할 것들

• 만들고 싶은 것을 기능 단위로 구체적으로 설명할 수 있어야 한다. “제안서 에이전트”보다 “RFP를 입력하면 목차 5개를 제안해주는 기능”이 더 잘 작동한다.
• 한 번에 완성하려 하지 말고 단계별로 확인하면서 만들어야 한다. 너무 많은 것을 한꺼번에 요청하면 오류가 복잡해진다.
• 오류가 났을 때 오류 메시지를 그대로 AI에게 붙여넣기하는 것이 가장 빠른 해결법이다.
• 같은 오류가 반복된다면 다른 AI 모델에게 동일한 코드를 가져가 물어보는 것도 방법이다.
• 바이브코딩으로 만든 결과물은 프로토타입이다. 실제 서비스로 배포하려면 별도의 기술 전문성이 필요하다.

---

나는 AI를 이미 이렇게 쓰고 있었다

에이전트를 만들기 전부터 다양한 업무에 여러 AI를 함께 쓰고 있었다. (전부 유료 모델이다…) 각 AI마다 잘하는 것이 다르다는 걸 경험으로 알게 됐고, 목적에 따라 달리 사용하는 방식이 자연스럽게 자리 잡혔다.

AI 모델	주로 쓰는 용도	특징
ChatGPT	아이디어 발산 전략 방향 초안	할루시네이션을 역이용해 예상치 못한 아이디어를 얻는 데 활용
Gemini	리서치 논리 분석	정밀한 정보 탐색과 구조적 분석에 강함
Claude	문구 다듬기 글 매끄럽게	맥락을 유지하며 글을 자연스럽게 다듬는 데 강함

반드시 이렇게만 쓰는 건 아니다. 상황에 따라 섞어 쓰기도 한다. 다만 각 AI의 특성을 의식하고 쓰는 것과 그냥 쓰는 것은 결과에서 차이가 난다. 도구의 특성을 알고 쓰는 것이 더 좋은 결과를 만든다.

ChatGPT의 할루시네이션은 단점이 아니다. 내가 미처 생각하지 못한 방향을 꺼내주는 브레인스토밍 파트너로 쓰면 오히려 유용하다.

---

어떻게 만들었나 — Gemini에서 시작해서 Claude로

에이전트 제작은 Gemini로 시작했다. 기본 구조를 잡고 실제로 작동하는지 확인하는 단계를 Gemini와 함께 했다. Gemini는 코드를 만들고, 오류를 분석하고, 해결책을 제시하는 과정에서 비교적 빠르게 방향을 잡아줬다.

이후 같은 코드를 Claude로 옮겨서 두 버전을 비교해봤다. 사용성이나 결과물에서 큰 차이는 없었다. 다만 Claude는 요청한 것을 반영하고 화면에서 바로 확인할 수 있게 만들어주는 속도가 빨랐고, 시각적으로 정리된 형태를 빠르게 보여줬다.

그리고 Claude에서는 전략 개발 부분을 제외하고 RFP 분석 → 목차 개발 → 목차별 제안서 작성만 처리하는 심플한 버전도 따로 만들어봤다. 에이전트의 범위를 좁히니 훨씬 안정적으로 작동했다.

---

감동도 있었고, 벽도 있었다

순간 01 · 감동 : 내가 구상한 대로 작동했을 때

에이전트가 내가 생각했던 형태로 처음 작동했을 때는 정말 감동적이었다. 예시 데이터를 넣었을 때 제대로 된 결과가 나오는 걸 확인했을 때의 기쁨은 직접 겪어봐야 안다.

순간 02 · 한계 : API 오류를 하루 종일 붙잡고 있을 때

Claude 버전에서 API 연동 오류가 반복됐다. 같은 오류가 계속 나왔고, AI도 적절한 해결책을 바로 제시하지 못하고 재작업을 거듭했다. 결국 이 문제는 해결하지 못했고, Claude 버전의 사용에 제한이 생겼다.

순간 03 · 발견 : 분량이 많아질수록 정밀성이 떨어졌다

제안서 분량이 늘어날수록 목차 설정과 내용 구성의 정밀성이 낮아졌다. 에이전트의 현실적인 한계를 확인한 순간이었다.

순간 04 · 아쉬움 : 나만 쓸 수 있는 구조가 됐다

내가 사용하는 목적은 달성했다. 하지만 다른 사람들이 바로 쓸 수 있는 구조는 만들지 못했다. 완성이 아닌 버전 1.0이었다.

---

바이브코딩으로 배운 것

바이브코딩은 내가 구상하는 서비스의 초안을 빠르게 잡아보는 데 분명히 유효하다. 코드를 몰라도, 원하는 것을 구체적으로 설명할 수 있다면 시작할 수 있다. 아이디어를 실제로 눈에 보이는 형태로 빠르게 확인할 수 있다는 것은 큰 장점이다.

다만 바이브코딩으로 만든 것은 프로토타입이다. IT 서비스로 만들어 배포하거나, 다른 사람들이 안정적으로 쓸 수 있는 구조를 갖추는 것은 별개의 전문성이 필요하다. 이 경계를 처음부터 인식하고 시작하는 것이 중요하다.

그리고 한 가지 더. 어떤 AI 도구를 쓰느냐보다, 무엇을 만들려는지가 명확한 사람이 더 좋은 결과를 만든다. 이건 제안서 작성과 다르지 않다.

바이브코딩의 한계는 코드가 아니다. 내가 원하는 것을 얼마나 구체적으로 설명할 수 있느냐가 결과를 결정한다.

* 2편 예고 : AI로 좋은 제안서를 쓰려면, 기준이 필요하다

AI가 만든 제안서는 왜 밋밋할까. 이기는 제안서와 그렇지 않은 제안서의 차이는 기술이 아니라 전략에 있다. AI를 활용한 제안서 개발의 기준을 다음 편에서 정리해 보려고 한다.

제안서 AI 에이전트 개발도전기 2편