바이브 코딩으로 ‘AI PPT 툴’ 만들어봤습니다

다행히 최근에는 이 과정을 줄여주는 감마(Gamma), 젠스파크(Genspark), 냅킨 AI(Napkin AI) 등의 다양한 AI 서비스가 등장했고, 요즘IT에도 소개된 적이 있죠. 이들은 AI의 방대한 패턴 학습과 자동화를 기반으로 사용자의 생산성을 크게 높여줍니다. 특히 반복적이고 형식화된 작업인 PPT 제작에는 아주 탁월한 성능을 보입니다.

그런데 이 서비스들을 막상 써보면 아쉬움이 없지는 않습니다. 무료로 쓰기에는 제약이 많고, 세부적인 커스터마이즈가 어렵습니다. 유료로 쓰자니 또 새로운 AI 월세를 낼 생각에 아찔해지기도 합니다. 그래서 “PPT 구성에 AI를 직접 활용하면 비용 없이도 비슷한 결과를 만들 수 있지 않을까?”라는 생각이 들었죠.

저는 AI에 추가 지식과 컨텍스트를 직접 제공하고, 결과물만 변환한다는 방향을 세운 후 사이드 프로젝트를 시작했습니다. AI가 만들어낸 마크다운 텍스트를 Quarto로 변환해, PPT로 만들어주는 도구로 말이죠. 이름하여 ‘Showmaker’입니다.

물론 이 방법에도 문제가 있었습니다. Quarto 같은 툴은 무료라는 장점이 있지만, 처음 접하는 사람에겐 꽤 불편합니다. 우리가 흔히 쓰는 프로그램처럼 실행하는 방식이 아니라, 검은 화면(터미널)이나 개발용 프로그램(IDE)에서 명령어를 입력해야 하기 때문이죠. 기술에 익숙하지 않다면 시작부터 막힐 수 있습니다.

이쯤에서 ‘아무리 좋은 도구라도 쓰는 방법이 어렵다면 활용도는 떨어질 수밖에 없다’는 생각이 들었습니다. 그렇다면 답은 하나였습니다. Quarto를 기반으로, 클릭 몇 번만으로 사용할 수 있는 GUI 프로그램을 직접 만드는 것이었죠. AI가 텍스트를 생성하고, Quarto가 이를 PPT로 변환하며, 사용자는 일반 프로그램처럼 버튼만 누르면 결과를 얻을 수 있는 구조였죠. 이러면 비용 부담 없이 누구나 손쉽게 AI로 PPT를 만들 수 있을 거라 생각했습니다.

이번 글에서는 제가 이 도구를 어떻게 기획하고, AI와 함께 ‘바이브 코딩’ 방식으로 구현했는지 그 과정을 공유하고자 합니다.

준비: 육하원칙으로 가볍게 설계하기

제가 그동안 경험한 바에 따르면, 성공적인 바이브 코딩의 흐름은 다음과 같은 단계로 구성됩니다.

먼저 어떤 것을 만들지 기획(Plan)해 보겠습니다. 사이드 프로젝트를 시작할 때는 보통 거창한 기획서를 쓰진 않습니다. 대신 일반적인 육하원칙과는 조금 다르지만, 구조를 참고하여 아주 간단하게 정리해 둡니다.

누가: 나와 AI. 글쓰기는 ChatGPT, 코딩은 코파일럿, 이미지 생성은 제미나이처럼 각자의 특기를 살려 역할을 분담했습니다. 만약 프로젝트에 여러 사람이 참여한다면, 각 사람이 어느 범위만큼의 작업을 할지 R&R을 명확하게 구분할 필요가 있습니다.

언제: ‘언제 시작할까?’보다는 ‘언제 끝낼까?’를 정했습니다. 사이드 프로젝트는 아이디어가 자꾸 커지기 때문에, 처음 목표로 했던 최소기능(MVP)을 달성할 때까지만 작업하겠다고 선을 그었습니다. 종료 기간은 이처럼 기능 단위으로 설정해도 되고, 연휴 같은 시간 단위로 정할 수도 있습니다.

어디서: 코딩 작업인 만큼 장소는 크게 중요하지 않았습니다. 대신 결과물을 어디서 만들고, 어디에 배포할지를 고민했습니다. 저는 VS code를 사용하고, 깃허브의 Release를 활용해 누구나 무료로 내려받을 수 있도록 했습니다.

왜: 동기는 단순했습니다. “비용을 들이지 않고, AI로 슬라이드를 만들 수 있지 않을까?” 짧지만 프로젝트 기획에서 가장 중요한 부분이라고 생각합니다.

무엇을: 앞선 왜와 이어지는 항목입니다. AI가 만든 마크다운 텍스트를 Quarto로 변환해 PPT를 만드는 GUI 프로그램을 만들 것이고, 추가로 어떤 것을 할지 뿐만 아니라, 어떤 것을 하지 않을지 정하는 것도 중요합니다.

어떻게: Quarto를 GUI 프로그램으로 만들기 위해서 저는 자바스크립트(Javascript)와 러스트(Rust)를 사용하는 타우리(Tauri)라는 프레임워크를 선택했습니다. 비슷한 역할을 하는 일렉트론(Electron)보다 가볍고 빨라, 이번 프로젝트와 잘 맞는다고 생각했습니다.

이렇게 육하원칙으로 정리해 두니, 프로젝트의 방향을 잡는 데 큰 도움이 됐습니다. 아이디어가 중간에 새로 떠올라도, 처음 정한 기준 덕분에 길을 잃지 않았습니다.

물론 이런 기획 작업도 AI에 맡길 수 있습니다. 하지만 저는 아이디어를 구체화하는 부분은 사람이 직접 하는 게 낫다고 생각합니다. 프로그램의 방향을 결정하는 건 결국 사람의 상상력과 필요에서 나오니까요. 대신 정리한 내용을 문서로 작성해 두고, 이를 AI에게 피드백용으로 제공하는 방식은 효과적이었습니다. 예를 들어, 저는 spec.md 같은 파일에 이번 프로젝트의 목적, 목표, 제약사항을 간단히 적어 두었습니다.

이런 문서를 AI에게 추가 컨텍스트로 제공하면, 같은 질문을 하더라도 훨씬 목적에 맞는 답변을 얻을 수 있습니다. 필수 단계는 아니지만, 겸사겸사 정리해 두면 프로젝트 진행이 한결 매끄러워지죠.

이제 기획 이후의 단계는 실질적인 바이브 코딩 단계로, 프롬프트를 넣고 원하는 결과가 나올 때까지 수정하는 과정의 반복입니다.

바이브 코딩: AI와 함께한 개발 과정

본격적인 개발은 깃허브 코파일럿과 함께 시작했습니다. 저는 주로 GPT-4.1 모델과 Ask 모드를 썼습니다. Agent 모드는 AI가 코드를 알아서 수정, 생성해 주는 방식인데요. AI가 잘못된 결정을 진행해 버리면 되돌리기 어렵기 때문입니다. 실제로 다른 프로젝트에서 Agent 모드를 사용하다가, 엉뚱한 수정 때문에 AI가 스스로 전체 코드를 날려버린 적도 종종 있는데요. 가능하면 사용자가 직접 결정을 내리는 Ask 모드로 진행하는 걸 추천합니다.

개발 과정은 단순히 설명하면, AI에 프롬프트 전달 - AI가 코드 생성 - (검토 및 코드 수정) - 프로그램 실행 - 오류 수정의 반복으로 사실 전통적인 코딩 방식과 크게 다르지 않습니다. 유의미한 차이가 있다면, 에러 로그를 구글에서 검색하는 대신 AI에게 물어본다는 점 정도입니다.

AI만으로는 부족할 때, Search가 필요하다

위에서 본 바이브 코딩 흐름에서 제가 특히 강조하고 싶은 부분은 ‘Search’입니다. 즉, AI만 믿고 문제를 해결하려 하기보다는, 상황에 따라 직접 문제를 검색해서 답을 찾는 게 훨씬 빠르고 확실했습니다. 예를 들어, AI가 제시하는 방법을 따라가다 보면, 최신 버전과 맞지 않는 코드를 알려주는 경우가 있습니다.

실제로 Tauri에서 저장 기능을 구현할 때도, AI가 업데이트 이전 버전의 코드 사용 방식을 제안해서 문제가 생겼습니다. 이런 상황에서는 최신 공식 문서를 직접 찾아보고, 거기서 얻은 내용을 다시 AI에게 알려주는 방식이 훨씬 효과적이었습니다. AI의 한계를 이해하고 사람의 검색과 판단을 적절히 섞으면, 바이브 코딩의 생산성을 더 향상시킬 수 있죠.

UI 추가와 반복적인 수정

저장 기능 문제를 해결하는 것 외에도, 프로그램에 실제 사용자가 쓸 수 있는 UI를 구현하는 과정도 바이브 코딩으로 해결할 수 있었습니다. 마크다운 파일을 업로드할 수 있는 창, 변환을 실행하는 버튼 같은 기본 기능이었지만, AI가 작성한 코드는 처음부터 매끄럽지는 않고, 버튼 위치가 틀어지거나 레이아웃이 깨지는 일이 종종 발생합니다. 그래서 결국은 다시 AI 코드 제안 - 실행 - 깨짐 확인 - 수정의 과정을 여러 번 반복해야 했죠. 이 과정이 번거로웠지만, 사이드 프로젝트에서는 빠르게 실행 화면을 보는 게 큰 동기부여가 되기도 합니다.

여러 차례 수정을 거친 끝에, 드디어 실행되는 프로그램 화면을 볼 수 있었습니다. 하지만 이 단계의 프로그램은 여전히 개발 환경 안에서만 돌아갔는데요. VS Code에서 tauri dev라는 명령어를 실행해야 했고, 개발 중인 PC에서는 구동됐지만, 다른 사람이 파일을 받아 더블클릭만으로 실행할 수 있는 수준은 아니었습니다.

이제 VS Code의 실행과 관계없이, 독립적으로 실행할 수 있는 프로그램으로 만드는 ‘빌드’ 작업이 필요합니다.

빌드와 배포: 누구나 실행할 수 있게 만들기

이 프로그램은 저의 맥OS PC뿐만 아니라, 많은 사용자를 가지고 있는 윈도우 환경에서도 실행할 수 있도록 빌드해야 합니다. 이를 위해 AI에 윈도우에서의 빌드 방법을 물어보고, 윈도우 PC에서 이후 단계를 진행했습니다. 그 결과 맥OS에서는 프로그램을 설치할 수 있는 dmg, 윈도우에서는 msi 파일을 생성할 수 있었습니다.

이 ‘exe’ 설치 파일들을 AI의 가이드를 참고해 깃허브 릴리즈 페이지에 업로드하면, 프로젝트의 1차 목표는 달성됩니다.

바이브 코드 리뷰

기본 기능이 동작하는 프로그램을 만든 뒤에는, 유지보수를 염두에 두고 AI로 코드 리뷰를 진행해 보려 합니다. 코드 품질을 조금 더 높이려는 시도인데요. 이는 VS Code에서 단순히 ‘코드를 리뷰해 줘’라는 프롬프트를 사용하는 것보다 깃허브에 풀 리퀘스트를 작성하고, 제미나이 코드 어시스트 같은 별도 서비스를 활용하는 것도 좋습니다.

AI가 제안하는 코드 리뷰는 대체로 참고할 만한 개선점을 담고 있지만, 모든 제안이 꼭 필요한 수정은 아닙니다. 따라서 비판적인 시각을 유지하며, 사람이 다시 한번 검토하는 과정이 필요합니다.

오픈소스 리뷰 기준 참고하기

코드 단위의 품질을 넘어, 프로그램 단위의 품질 향상을 위해 또 하나 참고한 기준은 ‘오픈소스 소프트웨어 저널(Journal of Open Source Software, JOSS)’의 리뷰 기준입니다. 이는 연구 목적의 소프트웨어를 평가하는 기준이지만, 사이드 프로젝트에도 상당히 유용합니다.

JOSS의 리뷰 기준 문서에는 ‘좋은 오픈 소스 소프트웨어’를 목적으로 하는 몇가지 조건이 제시되어 있는데요. 연구 목적이 아니더라도 ‘다른 사람이 쉽게 사용할 수 있는 소프트웨어’를 만드는 데 참고할 만한 내용이 많아, 원문을 읽어보는 걸 권장합니다.

소프트웨어의 필요성 명시
자동화된 절차를 통한 설치 안내
문제 해결을 위한 사용법 예제
핵심 기능에 대한 충분한 설명
커뮤니티 가이드라인 명시

당연히 이 기준을 AI에 전달하면, 프로젝트에 필요한 작업을 제안받는 ‘바이브-QA’ 방식으로도 활용할 수 있습니다.

바이브 코딩의 한계: 어디까지 믿을 수 있을까?

지금까지 바이브 코딩의 과정과 장점을 살펴봤으니, 이번엔 회고를 통해 바이브 코딩의 한계점을 짚어보겠습니다.

먼저 첫 번째 한계는 예시 이미지에서도 볼 수 있듯, 글 작성은 ChatGPT, 코드 보조는 Copilot, 이미지 생성은 제미나이를 사용하는 식으로 상황마다 다른 AI를 활용했습니다. 이는 한 가지 툴만으로는 아쉬운 점이 있었기 때문입니다. 물론 프롬프트를 매우 능숙하게 다룬다면 하나의 AI 서비스로도 충분할 수 있겠지만, 그렇지 않다면 ‘어떤 AI가 이 작업에 더 적합한가’를 판단하는 안목이 필요합니다.

두 번째 한계는, 중간에 동일한 에러를 세 번 묻는 이미지에서도 드러납니다. AI에게 모든 작업을 전적으로 맡기는 것은 꽤 위험합니다. AI는 자신 있게 틀린 답을 내놓을 때가 있으며, 여러 사례에서 언급되듯 아직은 사람을 온전히 대체할 만큼의 성능은 아닙니다. 특히 단순한 작업이 아니라면 더욱 그렇습니다.

AI의 역할은 어디까지나 ‘보조’일 때 효과적입니다. 보조란 사람이 이미 작업에 필요한 지식을 갖추고 있어, AI가 실수를 하더라도 이를 파악하고 바로잡을 수 있는 상태를 의미합니다. 만약 결과의 정확성을 검증할 수 없다면, 결국 또 다른 AI가 에이전트 방식으로 AI에게 작업을 요청하는 것과 크게 다르지 않다고 볼 수 있습니다.

마지막 한계는 바이브 코딩이 아직 기획 단계에서는 뛰어난 성과를 내지 못한다는 점입니다. 예를 들어, ‘어떤 사이드 프로젝트를 해볼까?’, ‘어떤 프로그램을 만들어볼 수 있을까?’와 같은 프롬프트에 대해서는 창의적인 아이디어보다는 투두 리스트처럼 완성과 성공을 목적으로 한 연습용 주제를 제안하는 경우가 많습니다.

앞서 기획 과정에서도 AI를 굳이 사용하지 않은 이유가 있습니다. 기대했던 pandoc이나 Quarto 같은 변환 방식 대신, 수동 복사·붙여넣기나 개요 기능을 활용한 자동 슬라이드 생성 같은 방법만 제안했기 때문입니다. 결국 AI가 내놓는 결과물은 바이브 코딩을 시도하는 사람의 상상력에 크게 의존한다고 볼 수 있습니다. 즉, 제 생각에 AI는 0에서 1을 만드는 아이디어에는 아직 약하지만, 이미 존재하는 아이디어를 10이나 100으로 확장하는 데는 강점을 보입니다.

정리하면, 바이브 코딩은 사용자의 상상력과 프롬프트 엔지니어링, 그리고 기존 역량에 비례해 ‘빠른 완성’과 ‘유연한 확장’을 가능하게 합니다. 하지만 프로젝트의 맥락과 깊은 이해가 없다면, 장기적인 유지보수에는 한계가 있어 아직 개발자를 완전히 대체하기는 어렵습니다.

프로젝트 회고와 정리

돌이켜보면 이번 프로젝트는 거창한 목표에서 출발한 것이 아니었습니다. 단순히 ‘비용을 들이지 않고도 AI로 PPT를 만들 수 있지 않을까?’라는 작은 질문에서 시작했죠. 하지만 몇 시간의 작업 끝에 실제로 다른 사람이 사용할 수 있는 프로그램을 완성했고, 그 과정에서 많은 것을 배울 수 있었습니다.

1) 사이드 프로젝트는 아이디어가 전부다

사이드 프로젝트에서 중요한 것은 규모나 완성도가 아닙니다. 핵심은 아이디어를 빠르게 실험하고, ‘작동하는 무언가’를 만들어내는 데 있습니다. 이번처럼 직접 겪은 불편함을 해결하려는 주제라면(도그푸딩), 동기부여가 더욱 강해지고 끝까지 밀고 나갈 힘도 생깁니다.

2) 바이브 코딩의 장점과 한계

바이브 코딩은 무엇보다 빠른 성취감을 줍니다. AI와 함께라면 0에서 시작해도 금세 눈에 보이는 결과를 만들 수 있죠. 또 아이디어를 확장해가며 유연하게 발전시킬 수 있다는 점도 매력적이었습니다.

하지만 동시에 한계도 분명했습니다. AI가 제안하는 코드가 최신 문법과 다르거나 같은 에러를 반복하는 경우가 많았고, 결국 사람이 기본적인 원리를 알고 있어야 문제를 걸러내고 해결할 수 있었습니다. 장기적인 유지보수까지 맡기기에는 아직 무리가 있다는 점도 이번에 확실히 느꼈습니다.

이렇게 만든 ‘쇼메이커(Showmaker)’는 이미 제가 원했던 목적, 즉 AI로 만든 마크다운을 손쉽게 PPT로 변환하는 기능을 달성했습니다. 깃허브에 공개한 뒤 예상보다 많은 분들이 관심을 주셨죠. 무엇보다 처음 목표대로 개발과 비용을 크게 고려하지 않고도, 실제로 PPT로 변환해 활용하는 사례를 확인할 수 있었습니다.

부록: 쇼메이커 사용법

마지막으로 완성된 쇼메이커의 사용 방법을 간단히 정리해 보겠습니다. 이번 글은 사이드 프로젝트 경험담이기도 하지만, 실제 사용 흐름을 함께 살펴보면 더 쉽게 이해할 수 있을 겁니다.

1. AI로 슬라이드 초안 만들기: AI를 활용해 마크다운 형식으로 슬라이드 내용을 구성합니다. 이때 아래와 같은 프롬프트 템플릿을 활용하면, AI가 목차와 내용을 담은 마크다운 파일(slides.md)을 생성해 줍니다.

2. 쇼메이커 실행하기: 쇼메이커 프로그램을 다운로드하여 설치, 실행합니다.

3. 파일 업로드 및 변환: 프로그램을 실행한 다음, 1단계에서 AI가 만든 마크다운 파일을 업로드하면 Quarto가 이를 PPT로 변환합니다.

예를 들어, ‘영상처리 개념을 강의용 슬라이드로 구성해줘’라고 요청하면 아래 같은 마크다운 파일을 생성할 수 있습니다.

이후 과정을 거치면, 몇 분 만에 AI가 만든 초안이 실제 PPT 파일로 완성되는 경험을 할 수 있습니다. 물론 이후 디자인을 다듬거나 이미지를 추가하는 작업은 사용자의 몫이지만, 가장 번거로운 초안 작성 과정을 훨씬 가볍게 만들 수 있다는 점이 큰 장점입니다.

이번 경험을 통해 완벽하진 않지만, 바이브 코딩의 충분한 가능성을 확인할 수 있었는데요. 무엇보다 혼자였다면 망설였을 프로젝트도, 끝까지 이어갈 수 있다는 자신감을 얻었습니다. 여러분도 지금 불편하다고 느끼는 점이 있거나, 해보고 싶은 프로젝트가 있다면 바이브 코딩으로 가볍게 시작해 보시는 건 어떨까요?