바이브코딩을 이야기할 때 사람들은 종종 웹서비스나 앱부터 떠올립니다. 무언가 멋진 결과물을 만들고, 화면을 예쁘게 구성하고, 새로운 기능을 붙이는 쪽이 먼저 눈에 들어오기 때문입니다.
그런데 실제로는 그런 것보다 훨씬 먼저, 훨씬 자주 마주치는 귀찮음이 있습니다. 바로 반복해서 해야 하는 실무 작업입니다.
저는 그중 하나가 한글오피스 문서 초안 작업이라고 느꼈습니다. 한국에서는 여전히 보고서, 기안문, 공문, 내부 문서 같은 것들을 한글 양식 기준으로 다루는 경우가 많습니다. 그런데 AI가 초안을 잘 써준다고 해도, 그걸 다시 HWPX 양식에 맞춰 옮기고 정리하는 과정은 여전히 사람 손이 많이 갑니다.
말하자면 AI는 내용을 잘 만들어주는데, 실제 내가 써야 하는 문서 형태까지는 아직 거리가 있는 상태였던 것입니다.
그래서 저는 단순히 “AI에게 문서를 써달라고 하는 것”을 넘어서, 한글오피스 초안 작업 자체를 덜 귀찮게 만드는 흐름을 만들고 싶었습니다.
이번 글은 그 이야기를 하려는 글입니다. 정확한 스킬 파일을 공개하려는 것은 아니지만, 대신 어떤 문제를 해결하려고 했는지, 어떤 원리로 접근했는지, 그리고 비슷한 스킬을 만들려면 어떤 식으로 생각하면 좋은지를 정리해보려고 합니다.
처음에는 AI가 문서를 잘 써주기만 하면 될 줄 알았습니다. 실제로 초안 자체는 꽤 잘 나옵니다. 보고서 개요를 잡거나, 문단 흐름을 만들거나, 필요한 내용을 정리해주는 데에는 이미 충분히 도움이 됩니다.
그런데 실무에서는 여기서 끝나지 않습니다.
- 문서는 특정 양식을 따라야 하고
- 표지 형식이 있고
- 날짜 형식이 있고
- 목차 방식이 있고
- 본문 기호 체계가 있고
- 붙임/참고 같은 구조가 있고
- 결국 최종 결과는 한글오피스에서 열렸을 때 자연스러워야 합니다
즉 문제는 “AI가 문장을 못 만든다”가 아니라, 내가 실제로 써야 하는 문서 구조와 바로 이어지지 않는다는 점에 더 가까웠습니다.
이 차이는 꽤 큽니다. 왜냐하면 이 지점부터는 단순한 프롬프트보다 작업 흐름 설계가 더 중요해지기 때문입니다.
이 문제를 겪고 나서 느낀 건, 이건 단순히 프롬프트를 더 잘 쓰는 것으로만 해결될 일이 아니라는 점이었습니다.
필요했던 건 이런 흐름이었습니다.
- 어떤 양식을 기준으로 쓸지 먼저 정하고
- 그 양식 안에 어떤 자리가 바뀌어야 하는지 파악하고
- 사용자가 준 문서 양식이 있으면 그걸 우선 쓰고
- 기본 템플릿도 준비해두고
- 초안 내용을 맞는 위치에 넣고
- 마지막엔 문서가 깨지지 않게 후처리하는 흐름
즉 중요한 건 AI가 똑똑하냐보다, AI가 어떤 작업 구조 안에서 움직이게 만들 것이냐였습니다.
이건 바이브코딩에서 꽤 중요한 감각이라고 생각합니다. 사람들은 종종 AI에게 한 번만 잘 말하면 모든 게 해결될 것처럼 기대하지만, 실제로는 많은 문제가 좋은 구조를 먼저 만들어두는 것에서 풀릴 때가 많기 때문입니다.
이 지점에서 저는 스킬이라는 걸 조금 다르게 보게 됐습니다.
처음엔 스킬이라고 하면 거창하게 들립니다. 뭔가 복잡한 기능을 새로 만들고, 어려운 코드를 짜고, 특별한 자동화를 구축하는 것처럼 느껴질 수 있습니다.
그런데 실제로는 이렇게 생각하는 편이 더 맞았습니다.
스킬을 만든다는 건, 내가 반복해서 귀찮아하던 절차를 AI가 따라올 수 있게 정리하는 일이다.
이 관점으로 보면 훨씬 쉬워집니다.
예를 들어 이번 경우라면:
- 어떤 양식을 우선할지 정한다
- 템플릿을 어떻게 다룰지 정한다
- 어디를 조사하고 바꿔야 하는지 정한다
- 결과를 어떻게 검증할지 정한다
- 마지막에 어떤 후처리가 필요한지 정한다
이런 것들이 다 스킬의 일부가 됩니다.
즉 스킬은 멋진 기술이기 전에, 내가 하던 일을 순서와 규칙으로 정리한 작업 설계도에 가깝습니다.
이번 작업에서 특히 중요하다고 느낀 건 두 가지였습니다.
1. 양식 우선
실무 문서는 내용보다 형식이 먼저인 경우가 많습니다. 그래서 빈 문서를 새로 만드는 것보다, 기존 양식이나 템플릿을 먼저 기준으로 삼는 것이 훨씬 안정적이었습니다.
이건 아주 중요합니다. 왜냐하면 많은 실무 문서는 결국 “무슨 내용을 쓰느냐”만큼이나 “어떤 형식 안에 들어가느냐”가 중요하기 때문입니다.
즉 AI가 초안을 잘 쓰더라도, 양식 기준이 없으면 결국 사람이 다시 많이 손봐야 합니다.
2. 후처리
실전에서는 “생성됐다”가 끝이 아닙니다. 문서가 실제로 열렸을 때 깨지지 않고 자연스럽게 보이는지도 중요합니다.
즉 스킬을 만든다는 건 단순히 내용을 넣는 게 아니라, 결과물이 실제로 쓸 수 있는 상태로 마무리되게 만드는 것까지 포함해야 합니다.
이 부분은 사람들이 생각보다 자주 놓치는 지점인데, 실전형 스킬에서는 오히려 이 마무리 단계가 핵심일 때가 많습니다.
물론 이번 사례는 HWPX라는 아주 한국적인 문서 환경에서 출발했습니다. 하지만 저는 이 글의 핵심이 단지 “한글 문서 자동화”만은 아니라고 생각합니다.
더 중요한 건 이 사고방식입니다.
- 내가 반복해서 귀찮아하는 작업이 무엇인지 본다
- 그냥 한 번 시키는 걸 넘어서 작업 흐름을 쪼개본다
- 어떤 기준과 규칙이 필요한지 적어본다
- 템플릿이 필요한지, 검증이 필요한지, 후처리가 필요한지 본다
- 그걸 AI가 따라올 수 있는 절차로 정리한다
이건 HWPX 말고도 그대로 응용할 수 있습니다.
예를 들면:
- 회사 보고서 초안 만들기
- 자주 쓰는 양식 문서 자동화
- 블로그 초안 포맷 정리
- 카드뉴스 문구 초안 만들기
- 반복 메일/요약/정리 업무 자동화
이런 것도 결국 비슷합니다. 핵심은 “AI가 똑똑하냐”보다, 내가 내 일을 어떤 구조로 넘겨줄 수 있느냐에 더 가깝습니다.
이걸 하면서 가장 크게 느낀 건, 좋은 스킬은 단순히 AI 기능 덩어리가 아니라는 점입니다.
오히려 그보다 더 중요한 건:
- 내가 어떤 일을 반복하는 사람인지
- 어디서 귀찮음을 느끼는지
- 어떤 부분은 AI에게 넘기고 싶은지
- 무엇이 실제 결과물의 기준인지
를 스스로 알고 있는가였습니다.
즉 잘 만든 스킬은 “AI가 대단한 걸 한다”보다 내 업무가 어떻게 굴러가는지 내가 잘 알고 있다는 신호에 더 가깝습니다.
그래서 저는 바이브코딩을 점점 “코드를 잘 치는 기술”보다 내 일을 더 덜 하게 만들기 위해 구조를 짜는 기술로 보게 됩니다.
이건 비전공자에게도 굉장히 좋은 관점입니다. 왜냐하면 처음부터 대단한 서비스를 만들지 않아도, 이미 내 안에 있는 귀찮음 하나만 잘 정의해도 시작할 수 있기 때문입니다.
많은 사람들은 바이브코딩을 시작할 때 너무 큰 결과부터 떠올립니다. 하지만 실제로는 이런 것부터 시작해도 충분하다고 생각합니다.
- 매번 손으로 옮기는 문서 초안
- 자주 반복하는 보고서 형식
- 같은 양식의 텍스트 채우기
- 매번 다시 정리해야 하는 출력물
- 파일마다 반복하는 귀찮은 변환 작업
이런 것들을 줄이는 것만으로도 이미 충분히 강력합니다.
왜냐하면 이건 실제로 내 시간을 줄이고, 내 피로를 줄이고, 결과를 눈에 보이게 바꾸기 때문입니다.
그리고 저는 바로 이런 종류의 결과가 바이브코딩을 “멋진 유행어”가 아니라 실제로 내 삶과 업무를 덜 귀찮게 만드는 도구로 느끼게 해준다고 생각합니다.
다음 글 예고
다음 글에서는 오늘 이야기한 사례처럼, 내 업무 안에서 반복되는 귀찮음을 발견했을 때 그것을 AI에게 넘길 수 있는 스킬 구조로 어떻게 쪼개서 생각하면 좋은지를 더 구체적으로 정리해보려고 합니다.
이 글은 AI의 도움을 받아 작성되었습니다.
