처음 바이브코딩을 접했을 때 가장 궁금했던 것은 이것이었습니다.
“개발자가 아닌 사람도 AI만 있으면 정말 프로그램을 만들 수 있을까?”
요즘에는 ChatGPT나 Codex 같은 AI에게 원하는 기능을 설명하면 코드를 작성해주고, 오류가 발생하면 원인을 분석해주고, 기존 코드를 수정하는 데도 도움을 받을 수 있습니다.
그래서 처음에는 조금 과장해서 생각하게 됩니다.
“이 정도면 개발을 몰라도 웬만한 프로그램은 다 만들 수 있는 것 아닐까?”
하지만 바이브코딩에 관심을 갖고 업무 프로그램에 적용할 방법을 생각하다 보니 조금 다르게 보이기 시작했습니다.
간단한 프로그램을 만드는 것과 회사에서 실제로 사용할 수 있는 시스템을 만드는 것은 상당히 다릅니다.
이번 글에서는 바이브코딩으로 어떤 것까지 만들어볼 수 있고, 어디에서부터 비개발자에게 어려워지는지 직장인의 관점에서 정리해보려고 합니다.
생각보다 작은 프로그램은 만들 수 있는 범위가 넓다
바이브코딩을 업무에 활용한다고 해서 처음부터 ERP 같은 거대한 시스템을 만들 필요는 없습니다.
오히려 직장인에게 필요한 프로그램 중에는 구조가 단순한 것이 많습니다.
예를 들어 여러 Excel 파일을 하나로 합치는 프로그램을 생각해볼 수 있습니다.
사용자가 파일을 업로드합니다.
AI가 데이터를 합칩니다.
중복 데이터를 확인합니다.
결과를 Excel로 다운로드합니다.
이 정도라면 필요한 기능도 비교적 명확합니다.
비슷하게 업무에서 반복되는 작은 기능들을 생각해볼 수 있습니다.
Invoice 데이터를 정리하는 도구, Budget과 Actual을 비교하는 화면, 반복되는 데이터를 정리하는 프로그램, 간단한 Dashboard, 업무 요청을 정리하는 화면 등이 있습니다.
이런 프로그램의 공통점은 입력값과 원하는 결과가 비교적 명확하다는 것입니다.
제가 바이브코딩을 보면서 느낀 것도 바로 이 부분입니다.
규칙을 설명하기 쉬운 업무일수록 AI에게 맡기기도 쉽습니다.
화면을 만드는 것은 생각보다 쉬워졌다
예전에는 웹 화면 하나를 만들려고 해도 HTML, CSS, JavaScript 같은 것부터 알아야 한다고 생각했습니다.
하지만 AI 코딩에서는 원하는 화면을 말로 설명하면서 시작할 수 있습니다.
예를 들어,
직원이 Invoice 파일을 업로드할 수 있는 화면을 만들어줘. 상단에는 Upload 영역을 두고 아래에는 Invoice Number, Vendor, Invoice Date, Amount를 보여주는 테이블을 만들어줘.
처럼 설명할 수 있습니다.
결과를 보고 다시,
Upload 버튼을 오른쪽으로 옮겨줘.
Status 필터를 추가해줘.
테이블 위에 검색창을 만들어줘.
처럼 수정 요청을 할 수도 있습니다.
비개발자 입장에서는 이 부분이 상당히 흥미롭습니다.
예전에는 화면을 설명하기 위해 PowerPoint나 그림으로 Mock-up을 만들어 개발자에게 전달했다면, 이제는 아이디어를 간단한 화면 형태로 빠르게 만들어보는 것도 가능해지고 있기 때문입니다.
Excel 업무 자동화도 바이브코딩과 잘 맞는다
제가 업무 자동화에서 특히 관심 있게 보는 영역은 Excel입니다.
회사에서는 여전히 많은 데이터를 Excel로 처리합니다.
그리고 Excel 업무에는 반복되는 규칙이 많습니다.
예를 들어,
파일 합치기 → 필요 없는 데이터 제거 → 날짜 정리 → 중복 확인 → 데이터 집계 → 결과 다운로드
처럼 매번 비슷한 작업을 반복할 수 있습니다.
이런 업무는 AI에게 설명하기도 쉽습니다.
여러 Excel 파일을 업로드하면 하나의 파일로 합쳐줘. Column 구조가 다른 경우에는 오류를 보여주고, 각 데이터가 어떤 파일에서 왔는지 Source File Column도 추가해줘.
이렇게 요구사항을 하나씩 구체화할 수 있습니다.
이런 작은 자동화부터 시작하면 바이브코딩이 실제 업무에서 어떻게 활용될 수 있는지 이해하기 쉽습니다.
그런데 기능이 하나씩 추가되면서 갑자기 어려워진다
문제는 여기에서 시작됩니다.
처음에는 단순한 Excel Upload 프로그램이었습니다.
그런데 실제로 사용하려고 생각하면 요구사항이 계속 생깁니다.
로그인이 필요합니다.
사용자마다 권한이 달라야 합니다.
업로드한 데이터를 저장해야 합니다.
과거 데이터를 다시 조회해야 합니다.
잘못 올린 파일은 삭제해야 합니다.
여러 사용자가 동시에 사용할 수도 있습니다.
누가 데이터를 수정했는지 기록해야 할 수도 있습니다.
갑자기 이야기가 달라집니다.
처음에는 **“Excel 파일을 합쳐주는 프로그램”**이었는데 어느 순간 사용자 관리, 데이터베이스, 권한, 로그까지 필요한 하나의 시스템이 되어버립니다.
제가 생각하는 바이브코딩의 첫 번째 현실적인 한계가 바로 이것입니다.
기능 하나를 만드는 것과 서비스를 운영하는 것은 다른 문제다.
AI가 만든 코드가 작동한다고 해서 끝이 아니었다
바이브코딩에서는 프로그램이 화면에서 정상적으로 작동하면 성공한 것처럼 느껴질 수 있습니다.
버튼을 눌렀더니 파일이 다운로드됩니다.
데이터를 입력했더니 저장됩니다.
검색도 됩니다.
하지만 회사에서 사용하는 프로그램이라면 그다음 질문이 더 중요합니다.
잘못된 데이터를 입력하면 어떻게 될까?
동시에 두 명이 수정하면 어떻게 될까?
권한이 없는 사용자가 URL을 직접 입력하면 접근할 수 있을까?
데이터가 100건이 아니라 10만 건이어도 작동할까?
오류가 발생하면 기존 데이터는 어떻게 될까?
이런 문제는 화면만 봐서는 알기 어렵습니다.
그래서 “작동한다”와 “안전하게 사용할 수 있다”는 전혀 다른 기준이라는 것을 알게 됩니다.
가장 어려운 것은 코딩보다 업무 규칙이었다
처음에는 바이브코딩에서 가장 어려운 것이 코드를 이해하는 것이라고 생각하기 쉽습니다.
하지만 업무 프로그램을 생각할수록 오히려 어려운 것은 Business Rule을 정확하게 정의하는 것이라는 생각이 듭니다.
예를 들어 승인 기능 하나를 만든다고 해보겠습니다.
“Submit을 누르면 Manager에게 승인 요청을 보낸다.”
처음에는 간단합니다.
그런데 곧 질문이 생깁니다.
Manager가 없는 직원은?
Manager가 휴가라면?
승인자가 본인이라면?
승인 후 내용을 수정하면?
이미 승인된 요청을 취소하면?
승인자가 퇴사했다면?
이런 질문의 답은 AI가 결정할 수 없습니다.
AI에게 일반적인 방법을 추천받을 수는 있지만 우리 회사에서 어떻게 처리해야 하는지는 결국 사람이 결정해야 합니다.
이 부분에서 비개발자의 업무 경험이 오히려 중요해집니다.
AI가 틀린 코드를 자신 있게 제시할 수도 있다
또 하나 조심해야 할 부분은 AI의 답변이 항상 맞는 것은 아니라는 점입니다.
AI가 작성한 코드는 그럴듯하게 보일 수 있습니다.
하지만 기존 시스템의 구조를 정확하게 이해하지 못했거나 내가 요구사항을 충분히 설명하지 않았다면 예상하지 못한 부분을 변경할 수도 있습니다.
그래서 저는 AI에게 바로
“수정해줘.”
라고 요청하는 것보다,
“먼저 현재 코드 구조를 분석해줘.”
“어떤 파일을 수정해야 하는지 알려줘.”
“기존 기능에 어떤 영향을 줄 수 있는지 확인해줘.”
“아직 코드는 변경하지 마.”
처럼 단계적으로 요청하는 방식이 중요하다고 생각합니다.
바이브코딩에서도 AI에게 일을 시키는 것만큼 AI가 무엇을 하려는지 확인하는 과정이 필요합니다.
오류가 반복되면 비개발자에게 다시 벽이 생긴다
간단한 오류는 AI에게 메시지를 보여주면 해결 방법을 찾을 수 있습니다.
하지만 문제가 여러 곳에 연결되어 있으면 상황이 달라집니다.
하나를 수정했더니 다른 기능에서 오류가 발생하고, 그 오류를 수정했더니 또 다른 부분이 작동하지 않을 수도 있습니다.
이때 코드 구조를 전혀 이해하지 못하면 AI가 제시하는 수정이 정말 맞는지 판단하기 어려워집니다.
그래서 바이브코딩을 해보면,
“코딩을 하나도 몰라도 된다.”
라는 표현보다는
“코드를 처음부터 직접 작성하지 않아도 개발을 시작할 수 있다.”
라는 표현이 더 현실적이라고 생각합니다.
기본적인 코드 구조와 데이터 흐름을 조금씩 이해할수록 AI를 훨씬 안전하게 사용할 수 있기 때문입니다.
회사 프로그램에서는 보안이라는 또 다른 문제가 있다
개인적으로 사용하는 간단한 프로그램과 회사에서 사용하는 프로그램의 가장 큰 차이 중 하나가 보안입니다.
회사 시스템에는 직원 정보, 거래처 정보, Invoice, 계약서, 회계 데이터 등 중요한 정보가 들어갈 수 있습니다.
그렇다면 프로그램이 작동하는 것만 확인해서는 안 됩니다.
누가 어떤 데이터를 볼 수 있는지, 데이터는 어디에 저장되는지, AI 서비스로 어떤 정보가 전달되는지, 회사 정책상 사용 가능한 환경인지 등을 확인해야 합니다.
특히 실제 회사 데이터를 AI에게 그대로 입력하는 것은 회사의 보안정책을 먼저 확인해야 합니다.
이 부분은 AI에게
“보안 문제 없게 만들어줘.”
라고 요청한다고 해결되는 문제가 아닙니다.
실제 업무 시스템으로 사용할수록 개발과 보안 담당자의 검토가 필요한 이유입니다.
바이브코딩으로 만들기 좋은 것과 조심해야 할 것
제가 비개발자의 관점에서 구분한다면 기준은 비교적 간단합니다.
바이브코딩으로 시작하기 좋은 것
개인 업무용 작은 도구, Excel 데이터 정리, 파일 변환, 간단한 계산기, 내부 아이디어를 보여주기 위한 Prototype, 간단한 Dashboard처럼 문제가 생겨도 영향 범위가 작고 결과를 직접 확인하기 쉬운 프로그램입니다.
반대로 조심해서 접근해야 하는 것은 여러 사용자가 사용하는 시스템, 회계처리, 결제, 개인정보, 사용자 권한, 계약 데이터, 중요한 승인 프로세스, 다른 시스템과 직접 데이터를 주고받는 기능 등입니다.
결국 중요한 기준은 프로그램의 크기보다 잘못됐을 때 얼마나 큰 문제가 발생할 수 있는가라고 생각합니다.
그래도 비개발자에게 바이브코딩이 의미 있는 이유
한계를 이야기했지만 저는 오히려 이런 한계를 알게 되면서 바이브코딩의 장점이 더 명확하게 보인다고 생각합니다.
바이브코딩의 가장 큰 가치는 비개발자가 혼자 거대한 시스템을 만드는 것이 아닐 수도 있습니다.
예전에는 새로운 아이디어가 있으면 개발자에게 말로 설명해야 했습니다.
“이런 화면이 있었으면 좋겠습니다.”
“이 버튼을 누르면 이런 결과가 나오면 좋겠습니다.”
하지만 바이브코딩을 활용하면 아이디어를 작은 Prototype으로 만들어볼 수 있습니다.
그리고 실제로 화면을 보면서,
“이 버튼은 필요 없겠다.”
“여기에 검색조건이 하나 더 필요하다.”
“사용자는 이 순서를 헷갈릴 것 같다.”
같은 것을 미리 발견할 수 있습니다.
그 상태에서 개발자와 이야기하면 단순한 아이디어보다 훨씬 구체적인 요구사항을 전달할 수 있습니다.
저는 이 부분이 비개발자에게 상당히 큰 변화라고 생각합니다.
바이브코딩을 하면서 개발자의 역할도 다르게 보였다
AI가 코드를 만들어주는 모습을 보면 처음에는 개발자의 일이 상당히 줄어드는 것처럼 보입니다.
하지만 프로그램의 범위가 커질수록 오히려 개발자가 왜 필요한지가 더 잘 보입니다.
단순히 코드를 작성하는 것만이 개발이 아니기 때문입니다.
전체 시스템 구조를 설계하고, 데이터가 안전하게 저장되도록 하고, 다른 기능에 영향을 주지 않도록 변경하고, 여러 사용자가 동시에 사용해도 문제가 없도록 하고, 장애가 발생했을 때 원인을 찾을 수 있게 만드는 것도 개발의 일부입니다.
AI가 코드 작성의 상당 부분을 도와주더라도 무엇을 만들 것인지 결정하고 결과가 올바른지 판단하는 역할은 여전히 중요합니다.
비개발자인 내가 느낀 바이브코딩의 현실적인 범위
바이브코딩으로 어디까지 만들 수 있느냐는 질문에는 하나의 답이 있는 것 같지 않습니다.
AI의 능력도 계속 발전하고 있고 사용하는 사람의 개발 지식에 따라서도 범위가 크게 달라질 수 있기 때문입니다.
하지만 비개발자 직장인의 입장에서 접근한다면 저는 이렇게 생각합니다.
아이디어를 Prototype으로 만드는 것 → 충분히 도전해볼 만하다.
반복되는 개인 업무를 자동화하는 것 → 좋은 시작점이다.
간단한 내부 업무 도구를 만들어보는 것 → 가능하지만 충분한 테스트가 필요하다.
중요한 회사 시스템을 혼자 개발해서 운영하는 것 → 훨씬 신중해야 한다.
이 정도의 선을 알고 시작하면 바이브코딩을 훨씬 현실적으로 활용할 수 있다고 생각합니다.
마무리｜바이브코딩의 진짜 장점은 '모든 것을 만들 수 있다'가 아니었다
바이브코딩을 처음 접했을 때는 이런 질문을 하게 됩니다.
“AI로 어디까지 만들 수 있을까?”
하지만 조금 더 들여다보면 질문이 바뀝니다.
“내가 해결하고 싶은 문제 중 어디까지 AI의 도움을 받아 직접 해결해볼 수 있을까?”
두 질문은 비슷해 보이지만 꽤 다릅니다.
바이브코딩의 목적은 개발자가 아닌 사람이 갑자기 모든 시스템을 혼자 만드는 것이 아니라고 생각합니다.
오히려 내가 매일 사용하는 업무에서 불편한 점을 발견하고, 작은 해결책을 직접 만들어보고, 테스트하고, 필요한 경우 개발자와 더 구체적으로 이야기할 수 있게 되는 것에 가깝습니다.
그리고 바이브코딩을 알아갈수록 한 가지는 더 분명해지는 것 같습니다.
AI가 코드를 작성하는 능력도 중요하지만, 사람이 문제를 정의하고 결과를 판단하는 능력은 여전히 중요합니다.
그래서 저는 바이브코딩을 **“코딩을 몰라도 무엇이든 만들어주는 마법”**이라기보다,
“비개발자도 아이디어를 실제로 만들어보는 단계까지 갈 수 있게 해주는 도구”
라고 생각합니다.
그 정도만으로도 비개발자에게는 꽤 큰 변화입니다.
0 Comments