비개발자의 도전:
바이브코딩으로 웹앱 만들기
HWP-MD 변환기 개발 20일의 솔직한 기록 📝
맥북 쓰는 친구한테 HWP 파일 보낸 적 있어?
그때 듣게 되는 저 익숙한 대답. "야, 나 한글 파일 못 열어..." 😅
이 문제를 해결하는 방법은 간단하다.
온라인 변환기 검색하면 수십 개 나오니까. 근데 난 다른 생각을 했다.
"내가 직접 만들면 어떨까?"
문제는 하나 있었다. 나는 개발자가 아니라는 거다.
Python 문법도 헷갈리고, Git은 대략 정의만 알고 있을 뿐이다.
그런데도 지금 실제로 작동하는 웹앱을 만들었고, 사람들이 사용할 수 있도록 해놨다.
🎬 시작: moai-adk와의 만남
먼저 moai-adk를 만들어주신 goos님께 감사 인사부터 드려야겠다.
단순히 바이브코딩만 적용했더라면 이렇게 실제 사람들이 쓸 수 있는 웹앱으로 보여줄 수 없었을 것이기 때문이다.
제일 처음에 내가 한 고민은 "뭘 만들까?"였다.
욕심이 생겨서 정말 거창하고 복잡한 프로그램 제작을 시도했는데...
근데 Git도 GitHub도 제대로 모르고 시작했으니 당연히 문제가 생겼다.
💥 첫 번째 실패: Git 브랜치의 늪
작업 브랜치 만들어서 작업한 후 main에 병합하는 걸 까먹었다. 며칠 동안 공들여 만든 코드가 뒤섞이고 망가지는 경험을 여러 번 겪었지. 진짜 멘탈 나갔다... 😭
이 경험 후에 방향을 완전히 바꿨다.
정말 기본적인 기능만 담은 마이크로 웹앱을 만들면서 바이브코딩에 익숙해지기로 한 거다.
그 첫 번째 프로젝트가 바로 HWP-MD 컨버터였다.
한글 파일(.hwp, .hwpx)을 마크다운(.md)으로 변환하는 단순하지만 실용적인 도구. 딱 내 수준에 맞는 프로젝트였다고 본다.
📋 SPEC 작성: AI에게 명확한 지도 그려주기
바이브코딩의 핵심은 뭘까? 바로 명확한 SPEC이라고 생각한다.
내가 원하는 기능을 AI가 이해할 수 있게 정리하는 게 전부라고 해도 과언이 아닐 것이다.
🤖 SPEC 작성에 활용한 AI 도구들
- Gemini: 초기 기능 명세서 작성
- ChatGPT: SPEC 검토 및 보완
- Claude Code + GLM 4.6: 실제 코드 구현
처음 만든 SPEC은 완벽하지 않았다. Gemini와 ChatGPT에게 "내가 원하는 기능을 구현할 수 있도록 SPEC을 만들어줘"라고 요청했고, 그걸 여러 번 읽으면서 수정했다.
"이 기능이 들어가 있나?", "사용자가 이렇게 하면 어떻게 되지?" 이런 질문들을 계속 던지면서 SPEC을 다듬었다. 처음엔 이게 시간 낭비 같았는데, 나중에 보니 이게 제일 중요한 과정이었더라.
SPEC이 완성되고 나서 Claude Code에 GLM 4.6 모델을 올려서 실제 작업을 진행했다.
약 7-8일이 지난 후 "HWP 파일과 HWPX 파일 모두 MD로 변환하는 기능이 완료됐다"는 메시지를 받았다.
🔧 시행착오: 실제로는 더 많은 문제가 있었다
"완료됐다"는 말을 듣고 설레는 마음으로 실행해봤다. 프론트엔드 UI는 맘에 안 들었지만, 일단 기능이 되는지만 확인하려고 했는데...
⚠️ 발견한 문제들
- 한글 인코딩 문제: 변환된 텍스트가 깨져서 나왔다
- 표 형식 텍스트 누락: 표 안에 있는 내용이 전혀 변환되지 않았다
한글 인코딩 문제는 여러 번 시도 끝에 해결했다.
UTF-8 인코딩을 명시적으로 지정하고, 파일 읽기/쓰기 과정에서 인코딩을 일관되게 유지하니까 해결됐다.
근데 표 형식은 완전히 다른 문제였다. GLM 4.6 모델로 여러 번 시도했는데, "완료했습니다"라고 말은 하지만 실제로는 전혀 진전이 없었다. 몇 시간을 여기에 쏟아부었는데도 안 되더라.
💡 해결책: 더 똑똑한 모델의 도움
결국 Google의 Gemini 3 Pro에게 도움을 요청했다. "표 형식을 고쳐주고, 지금 구현된 코드를 개선할 계획을 세워줘"라고 말이다. 놀랍게도 HWPX의 표 형식은 제대로 읽어서 변환하도록 개선됐다!
다만 HWP 파일(구 버전)의 표 변환은 끝까지 완성하지 못했다.
한글 파일 포맷에 대한 정보를 웹에서 찾아서 보여주고 "이걸 참고해서 고쳐줘"라고 해봤지만 계속 실패했다.
결국 어느 순간 깨달았다. 매일 사용량 한도가 있는 AI 모델과 계속 씨름하는 것보다, 일단 기본 동작하는 웹앱을 상용화하는 게 먼저다라고. 그래서, 완벽주의를 버리고 현실적으로 접근하기로 했다.
🚀 배포: 세상에 내보내기
다시 Claude Code로 돌아와서 배포를 진행했다.
"어디에 배포하는 게 가장 효율적이야?"라고 물어보고, 추천받은 플랫폼들을 비교한 후 결정했다.
🏗️ 배포 아키텍처
- Backend: Render (파일 변환 로직 처리)
- Frontend: Netlify (사용자 인터페이스)
- Domain: lab.n8n-diy.com (커스텀 도메인 연결)
- Security: HTTPS 보안 연결 설정 완료
여러 번 수정 끝에 백엔드와 프론트엔드가 제대로 통신하는 걸 확인했다.
로컬에서는 잘 되는데 배포하면 안 되는 CORS 문제도 있었고, 환경 변수 설정도 몇 번 바꿔야 했다.
도메인 설정과 보안 연결까지 완료하고 나니 진짜 내 웹앱이 세상에 나온 기분이었다.https://lab.n8n-diy.com 이 주소로 접속하면 내가 만든 변환기가 뜬다는 게 신기했다. 😊
📣 홍보 전략
만들었으면 알려야지! 타겟 사용자를 명확히 정하고 홍보했다:
- 맥 사용자 커뮤니티: HWP 파일 못 여는 문제 해결
- 개발자 커뮤니티 (OKKY): 오픈소스 도구로 소개
- 노션 커뮤니티: MD 파일 활용도 높은 사용자들
막 환호하는 반응은 아니었지만, 많은 분들이 좋아해 주셨다. "이거 필요했는데!", "맥에서 바로 쓸 수 있어서 좋네요" 같은 댓글들을 보면서 보람을 느꼈지.
🔮 다음 단계: 계속 발전시키기
현재 버전이 완벽하진 않다. 아직 개선할 부분들이 많이 보인다:
🎯 진행 중
- HWP 표 변환 완성
- 글 스타일 유지 (제목, 소제목, 리스트 등)
💭 계획 중
- 이미지 추출 기능
- 일괄 변환 (여러 파일 동시 처리)
HWP-MD 컨버터 외에도 다른 프로젝트들을 진행하고 있다:
- Wood-Cut Optimizer: 합판 재단을 최적화해서 재료 낭비를 줄이는 도구
- AI Tarot: AI 기반 타로 카드 리딩 웹앱
이 모든 프로젝트를 통해 바이브코딩에 점점 더 익숙해지고 있다. 처음엔 Git 브랜치도 헷갈렸는데, 이제는 기본적인 워크플로우는 자연스럽게 진행할 수 있게 됐다.
💬 비개발자에게 전하고 싶은 말
"비개발자도 개발할 수 있는 시대가 되었다."
지금은 웹앱으로 시작했지만, 실제 생활에 필요한 제품들까지 확장해 나갈 수 있지 않을까? 사용하는 것도 좋지만, 만드는 것도 좋다는 걸 모두 느껴 봤으면 좋겠다.
내가 이 글을 쓴 이유는 간단ㅓ하다. SPEC 중심의 바이브코딩으로 실제 사용 가능한 웹앱을 제작할 수 있다는 걸 알려주고 싶었다.
완벽하지 않아도 괜찮다. HWP 표 변환이 아직 안 되지만, 그래도 사람들이 내 변환기를 사용하고 있다. 작게 시작해서 점진적으로 개선해 나가는 것, 그게 바이브코딩의 진짜 매력이라고 생각한다.
🎓 내가 배운 교훈들
- 작게 시작하자: 거창한 프로젝트보다 마이크로 앱이 학습에 좋아
- SPEC이 전부다: 명확한 요구사항 정리가 개발의 80%
- 완벽주의 버리기: 작동하면 일단 배포하고 개선해 나가자
- 적절한 도구 선택: 각 AI 모델의 강점을 파악하고 활용하자
- 커뮤니티 힘: 타겟 사용자에게 직접 홍보하면 피드백이 빨라
🚀 지금 바로 시작해보자
){kind=link}
HWP 파일 변환이 필요하다면 한번 써봐. 맥 사용자 친구들한테도 공유해 주면 좋겠다! 😊
💬 여러분의 이야기를 들려주세요
바이브코딩으로 뭔가 만들어 보셨나요? 아니면 만들고 싶은 아이디어가 있나요? 댓글로 공유해 주세요! 같이 고민하고 해결 방법을 찾아보면 좋겠어.
- 어떤 프로젝트를 시도해 볼까 고민 중이신가요?
- 개발 과정에서 막힌 부분이 있나요?
- HWP-MD 변환기 사용 후기를 남겨주세요!
댓글 쓰기