지난 글에서는 비개발자의 시선에서 ‘바이브 코딩(Vibe Coding)’과 AI Native에 대한 생각을 먼저 나눴습니다. 이번에는 그런 생각의 토대가 되었던 실제 경험을 바탕으로 이야기를 이어가고자 합니다.

내만내쓰 HTML 업무 도구

‘필요한 도구를 찾는 것보다 내가 직접 만들어서 쓰는 것이 더 빠르다’는 것을 깨달으면서 저는 바이브 코딩을 시작하게 되었습니다.
HTML 도구를 ‘개발’했다고 소개하려 하니, ‘HTML은 프로그래밍 언어가 아니다’라는 밈이 떠오르네요. 비록 HTML 파일이 주요 결과물이지만 CSS, 자바스크립트, 타입스크립트 등 작은 웹 앱 형태로 구색을 갖추는 경우도 있으니 너그러이 봐주세요. 물론, 실제 개발자 분들이 만드는 제품처럼 견고하고 확장성 있는 결과물은 아니고, 최소 기능 제품(Minimum Viable Product) 수준에서 충분히 유용하게 활용하고 있습니다.

사용할 수 있는 AI 개발 도구들이 다양한데요, 제 경험은 크게 아래 두 가지로 나누어 보겠습니다.

LLM으로 만들기 (ChatGPT/Claude/Gemini)
AI 에이전트(agent) 도구로 만들기 (Copilot Agent)

➊ LLM으로 만들기

ChatGPT, Claude, Gemini 같은 LLM(거대 언어 모델)은 요청할 때마다 결과가 조금씩 달라진다는 특징이 있습니다. 때로는 입력 데이터 중 수정하면 안 되는 부분까지 답변 생성 과정에서 수정되어 버리는 경우도 있습니다. 이런 일이 발생하면 결국 모든 데이터를 일일이 확인해야 하는 번거로움이 따릅니다.

그런데 단순히 정해진 규칙대로 반복적인 처리만 필요한 경우도 많습니다. 예를 들어, 텍스트 목록 전체에 동일한 머리말을 추가하거나, 숫자 형식을 규칙에 맞게 한 번에 변환하는 작업처럼 말입니다. 이런 경우에는 결과를 예측하기 어려운 ‘블랙박스’ 같은 LLM에게 직접 작업을 요청하는 것보다, 차라리 그 규칙대로 작동하는 간단한 도구를 만들어 달라고 하는 편이 결과의 신뢰도와 일관성을 높이는 데 훨씬 효과적입니다.

예를 들어 다음과 같이 프롬프트를 작성하면 됩니다.

{입력 데이터 형식}을 입력하면 {출력 데이터 형식}을 반환하는 {작업} 프로그램을 html 파일로 만들어 주세요.

위 이미지는 저의 첫 바이브 코딩 작품인 '영어 to 한글 키보드 변환기’입니다. 이 도구를 만들었던 2024년 하반기만 해도, 비교적 간단한 규칙 기반의 작업을 LLM이 제대로 처리하지 못하는 경우가 있었습니다. 제가 발견했던 사례는, 키보드 한/영 키를 잘못 눌러 영문으로 입력된 한글을 다시 한글로 바꾸는 작업이었습니다.
(예: dlfjs xprtmxmfmf → 이런 텍스트를)

당시 여러 프롬프트와 언어모델을 사용해 보았지만, 처음 몇 개의 알파벳은 잘 변경해 준 뒤, 그 뒤로는 앞 단어를 기반으로 새로운 문장을 창조하면서 변환 작업을 잊어버리는 것 같았습니다. 그래서 프롬프팅에 능한 동료 로빈(Robin.hwang)에게 자문을 구했고, 로빈의 추천으로 이 키보드 변환 규칙을 직접 수행하는 웹 도구를 LLM에게 프롬프팅 하여 만들게 된 것입니다. 귀여운 고양이 테마 디자인도 (역시 로빈의 아이디어로) 프롬프팅으로 추가했습니다.

물론 몇 개월 후에는 LLM 성능이 빠르게 발전했고, 지금은 이런 도구 없이 LLM 채팅창에서도 변환이 곧잘 가능해졌습니다.

생각을 시각화하기 위해 저는 가끔 머메이드(Mermaid) 문법으로 다이어그램을 그립니다. 하지만 이를 위해 VS Code를 실행하고 새 파일을 만드는 것이 번거로웠습니다(비개발자인 저는 평소에 IDE를 켜두지 않으니까요). 그래서 ‘그냥 웹에서 바로 쓰고 바로 볼 수 없을까?’ 하는 생각에, 저장 기능은 빼고 라이브 편집 기능만 갖춘 HTML 페이지를 ChatGPT에서 바로 만들었습니다. 이름하여 '머메이드 라이브 에디터’입니다.

저는 머메이드를 자주 사용하지 않는 탓에 필요할 때 문법이 기억나지 않는 경우가 많았는데요, 에디터가 로딩될 때 샘플 문법을 입력창에 미리 보여주도록 수정하니 사용이 편리했습니다. 이처럼 도구를 만들 때, 입력 형식이나 예시 데이터를 미리 작성해서 첫 화면에서 보여주는 것이 좋았습니다. 그러면 시간이 흐른 뒤에 다시 사용할 때에도 헤매지 않고 바로 사용할 수 있었습니다.

엑셀 함수로도 가능하지만, 매번 수식을 입력하거나 직접 확인하기엔 번거로운 단순 반복 작업들이 있습니다. 이런 작업들 역시 LLM에게 요청하여 규칙 기반으로 작동하는 HTML 파일 하나로 만들어 두면 필요할 때마다 편리하게 사용할 수 있습니다. 예를 들어 ‘중복 텍스트 검출기’, ‘데이터 개수 세기’, ‘랜덤 추첨기’ 같은 것들입니다. LLM에게 명확한 규칙을 알려주면, 이런 자주 쓰는 기능을 빠르고 정확하게 수행하는 도구를 쉽게 만들 수 있습니다.

여러분의 업무에서 자주 반복하는 간단한 작업들이 있다면 작은 기능 단위부터 직접 도구를 만들어 활용해 보시길 추천드립니다.

➋ AI 에이전트 도구로 만들기

에이전트는 사용자가 모든 세부 사항을 지시하지 않아도, 사용자 경험(UX)을 고려하여 전체적인 결과물을 만들어 줍니다. 단 한 줄의 프롬프트로도 수준 높은 결과물을 얻을 수 있는 것이죠. 빠른 기술의 발전 덕분에, 이제는 LLM 도구만으로도 에이전트와 유사한 경험을 할 수 있습니다. 그럼에도 예를 들어, VS Code 환경에서 코드 복사・붙여넣기 조차 직접 하지 않아도 되는 등, 에이전트 개발 도구만의 편리한 특징들이 있는 것 같습니다.

앞서 소개한 ‘중복 텍스트 검출기’를 코파일럿(Copilot)의 에이전트로 다시 만들어 보겠습니다.

우선 LLM으로 만들 때와 비슷한 프롬프트를 입력했습니다(아래 프롬프트는 ChatGPT가 썼어요).

텍스트 입력창에 줄 바꿈(한 줄당 한 항목)으로 여러 항목을 입력하면, 중복된 텍스트를 찾아서 결과 영역에 목록을 출력하는 HTML 도구를 만들어줘

그랬더니 LLM으로 만들었던 것과 유사한 결과물이 일단 나왔습니다.

여기서 에이전트가 실력을 발휘할 수 있도록 다음의 프롬프트를 입력했습니다.

좋아요. 디자인과 기능을 알아서 추가해 주세요.

이렇게 두 번의 대화로 아래의 결과물이 완성되었습니다.

위 사례는 단일 HTML 파일 작업이라, 에이전트의 장점이 크게 와닿지 않으실 수도 있습니다. 하지만 여러 파일을 오가며 작업하거나, 오류를 해결할 때 등, 번거로운 작업이 늘수록 에이전트의 편리함을 체감하게 됩니다.

이 사례처럼 간단한 도구를 만들 때는 프롬프트가 짧아도 훌륭한 성능을 경험할 수 있습니다. 반면 복잡한 요구사항을 정확히 반영해야 하는 경우에는, 처음부터 최대한 완성도 높은 결과물을 만든 뒤, 세부적인 부분만 조금씩 수정해 나가는 방식이 더 효과적이었습니다. 초기 지시가 명확하지 않은 상태에서 일단 시작하고 기능을 계속 덧붙이다 보면, 결과물이 의도와 다르게 나올 수 있습니다. 기존에 잘 작동하던 기능이 갑자기 사라지는 경우도 자주 겪었습니다. 특히 버전 관리나 코드 변경 이력 확인에 익숙하지 않다면, 이런 수정을 막거나 되돌리기가 더 어려운 것 같습니다.

따라서 에이전트와 복잡한 작업을 시작할 때 좋은 초기 결과물을 얻으려면, 무엇보다 첫 프롬프트를 구체적이고 명확하게 작성하는 것이 좋았습니다. 어떻게 프롬프트를 써야 할지 모르겠다면, 아래와 같이 LLM으로 프롬프트 초안을 작성하면 됩니다.

{목적}하는 프로그램을 html 파일로 만들기 위한 프롬프트를 작성해 주세요.

단 LLM이 작성해 준 긴 프롬프트에 내가 의도한 세부사항이 잘 반영되었는지는 스스로 읽고, 요구사항에 맞도록 수정해서 사용해야 합니다.

다시 한번, Disclaimer

제가 AI로 만든 이 결과물들은 ‘동작하는 무언가’를 직접 만들고 사용한다는 점에서 재미있는 경험이었습니다. 하지만 이는 프론트엔드 개발이라는 거대한 빙산의 일각일 뿐입니다. 실제 사용자에게 안정적인 서비스를 제공하기 위해 필수적인 보안 설계, 성능 관리, 테스트 자동화, 접근성 등 수면 아래에 있는 방대한 전문성의 영역은 이 프로젝트에서 논할 수 있는 수준이 아닙니다.

다음 단계

최근에는 Claude Code나 OpenAI Codex CLI처럼 터미널 환경에서 사용하는 코딩 에이전트 도구도 주목받고 있습니다. 터미널 UI가 비개발자에게 친숙한 영역은 아니기에, 비개발자의 정체성을 유지하고 거리를 둘 것인가, 여러 개발 도구들에 익숙해질 것인가는 추구하는 방향성에 따라 고민할 지점입니다.

현재는 제가 만든 도구와 페이지를 다른 사람들과 공유하기 위해 서버를 띄우고, 데이터를 함께 입력하고 저장하는 등의 기능적 확장성을 실험하고 있습니다. 다루는 파일의 수가 점점 많아지고, 배워야 하는 기술들이 나타날 때, 이것을 개발지식을 학습해서 해결할 것인지, 혹은 AI Native한 방법을 찾아갈 것인지 역시 고민입니다. 헤매는 모든 과정이 의미있는 경험이 될 것 같습니다.

다음 글에서는 Copilot을 비롯한 AI 도구들로 제 나름의 최대치의 결과물을 만들어 본 것을 소개해 드리고 싶습니다. 다만 저의 본업이 Vibe Coder가 아닌 관계로, 당분간은 다시 본업을 하다가, 잊으시기 전에 3편으로 돌아오겠습니다.

Vibe-Coding 관련 글 모아보기

Vibe Coding하는 비개발자는 개발자인가(2)