비개발자가 바이브코딩을 시작한 이유|AI로 업무 프로그램을 만들어보며 느낀 점

 


저는 개발자가 아닙니다.

회사에서 업무 시스템이나 프로세스와 관련된 일을 하다 보면 개발자와 이야기해야 할 일이 많습니다. 새로운 기능이 필요하면 요구사항을 정리하고, 현재 업무에서 어떤 부분이 불편한지 설명하고, 개발된 기능이 실제 업무 흐름과 맞는지도 확인해야 합니다.

그러다 보면 자연스럽게 이런 생각이 들 때가 있습니다.

“이 정도 기능은 내가 직접 만들어볼 수 없을까?”

예를 들어 화면에 버튼 하나를 추가하고 싶거나, 반복적으로 정리하는 데이터를 자동으로 처리하고 싶거나, Excel로 데이터를 다운로드할 수 있는 기능이 있었으면 좋겠다는 생각이 들 때가 있습니다.

예전 같으면 이런 아이디어가 있어도 개발자에게 요청사항을 전달하는 것에서 끝났을 겁니다.

하지만 ChatGPT 같은 생성형 AI가 등장하고, 최근에는 **바이브코딩(Vibe Coding)**이라는 방식까지 알려지면서 비개발자도 조금 다른 방식으로 개발에 접근할 수 있게 되었습니다.

바이브코딩에 관심을 갖게 된 이유

제가 바이브코딩이라는 개념에 관심을 갖게 된 가장 큰 이유는 코드를 직접 작성하는 능력보다 내가 만들고 싶은 것을 설명하는 능력이 중요해지고 있다는 점이었습니다.

업무를 하다 보면 개발 방법은 몰라도 업무 프로세스는 알고 있습니다.

예를 들어,

사용자가 어떤 정보를 입력해야 하는지,
어떤 조건에서 승인되어야 하는지,
승인 후에는 어떤 상태로 변경되어야 하는지,
어떤 데이터를 보고서에서 확인해야 하는지

같은 부분입니다.

개발 언어는 몰라도 **“프로그램이 어떻게 움직여야 하는지”**는 업무를 담당하는 사람이 더 정확하게 알고 있는 경우가 많습니다.

AI 코딩을 접하면서 이 부분이 꽤 흥미롭게 느껴졌습니다.

예전에는 아이디어와 개발 사이에 꽤 높은 벽이 있었다면, 이제는 자연어로 내가 원하는 기능을 설명하면서 그 사이의 거리를 조금씩 줄여볼 수 있기 때문입니다.

처음에는 “AI한테 만들어달라고 하면 되는 거 아닌가?”라고 생각했다

바이브코딩이라는 말을 처음 접하면 굉장히 간단하게 느껴집니다.

AI에게

“이런 프로그램 만들어줘.”

라고 하면 AI가 알아서 코드를 작성하고 프로그램이 완성될 것 같습니다.

하지만 관련 내용을 알아보고 AI 코딩을 활용해보면서 알게 되는 것은 요청을 구체적으로 만드는 과정이 생각보다 중요하다는 점입니다.

예를 들어,

“Excel 다운로드 기능 만들어줘.”

라고 요청하는 것과,

“현재 화면의 검색 결과를 Excel 파일로 다운로드할 수 있는 버튼을 추가하고 싶어. 기존 검색 조건이 그대로 적용되어야 하고 기존 기능은 변경하지 않았으면 좋겠어. 먼저 어떤 파일을 수정해야 하는지 확인하고 수정 방법을 설명해줘.”

라고 요청하는 것은 상당히 다릅니다.

두 번째 요청에는 현재 상황, 원하는 결과, 지켜야 할 조건이 들어 있습니다.

이 부분에서 바이브코딩이 단순히 “코딩을 AI에게 시키는 것”만은 아니라는 생각이 들었습니다.

개발을 몰라도 업무는 알고 있다는 것이 장점이었다

비개발자가 AI 코딩을 시작할 때 가장 먼저 드는 걱정은 이것일 수 있습니다.

“나는 코드를 모르는데 가능할까?”

물론 코드를 이해할 수 있다면 훨씬 유리합니다.

하지만 업무용 프로그램을 생각할 때는 또 다른 능력이 필요합니다.

바로 업무를 이해하는 능력입니다.

예를 들어 비용 처리 프로그램을 만든다고 가정해보겠습니다.

개발자는 프로그램을 구현하는 방법을 잘 알지만 실제 업무 담당자는 다른 부분을 알고 있습니다.

어떤 필드가 필수인지, 어떤 경우에는 승인이 추가로 필요한지, 어떤 상태에서는 수정하면 안 되는지, 사용자가 어떤 부분에서 자주 실수하는지 같은 것입니다.

AI가 코드를 작성해줄 수 있게 되면서 이런 업무 지식과 개발 사이의 연결이 예전보다 쉬워지고 있다는 생각이 들었습니다.

큰 기능보다 작은 기능부터 시작하는 게 중요했다

바이브코딩을 처음 접하면 욕심이 생길 수 있습니다.

“Invoice 관리 시스템 만들어줘.”

“회사 Expense 시스템 만들어줘.”

“승인 시스템 전체를 만들어줘.”

하지만 이렇게 범위가 큰 요청은 확인해야 할 것도 많아집니다.

그래서 업무 프로그램을 AI로 만들어본다면 기능을 작은 단위로 나누는 방식이 훨씬 현실적입니다.

예를 들어 Expense 시스템이라면 한 번에 전체를 만드는 것이 아니라,

화면 만들기 → 입력 필드 추가 → 저장 기능 → 파일 첨부 → 승인 기능 → 상태 변경 → 알림

처럼 나눠볼 수 있습니다.

하나씩 결과를 확인하고 다음 단계로 넘어가면 문제가 생겼을 때 어느 부분에서 잘못되었는지도 찾기 쉬워집니다.

이 방식은 실제 업무에서 개발 요구사항을 정리할 때와도 비슷합니다.

AI가 코드를 만들어줘도 사람이 확인해야 했다

바이브코딩에 대해 이야기할 때 가장 조심해야 할 부분도 있습니다.

AI가 코드를 작성했다고 해서 그 코드가 항상 맞는 것은 아닙니다.

겉으로는 화면이 정상적으로 작동하는 것처럼 보여도 다른 기능에 영향을 줄 수 있고, 중요한 조건이 빠질 수도 있습니다.

특히 회사 업무 시스템이라면 더 조심해야 합니다.

권한, 개인정보, 재무 데이터, 승인 프로세스처럼 잘못 처리되면 문제가 되는 부분이 있기 때문입니다.

그래서 AI 코딩은

요구사항 작성 → AI 코드 생성·수정 → 결과 확인 → 테스트 → 다시 수정

과정을 반복하는 것이 중요하다고 생각합니다.

바이브코딩이 개발 지식을 완전히 필요 없게 만드는 것이라기보다 개발을 시작할 수 있는 문턱을 낮춰주는 도구에 더 가깝게 느껴지는 이유입니다.

오류가 발생하는 것도 과정의 일부였다

AI 코딩을 접하면서 재미있는 점 중 하나는 오류가 생겼을 때의 접근 방법도 달라졌다는 것입니다.

예전에는 에러 메시지를 보면 개발자가 아닌 사람에게는 그 자체가 하나의 장벽처럼 느껴졌습니다.

하지만 이제는 오류 메시지와 상황을 AI에게 설명하고,

“이 오류가 발생하는 원인을 먼저 설명해줘. 바로 코드를 수정하지 말고 어떤 부분을 확인해야 하는지 알려줘.”

처럼 물어볼 수 있습니다.

여기서 중요한 것은 무조건 AI에게

“고쳐줘.”

라고 하는 것보다 왜 문제가 발생했는지 먼저 이해하려는 것이라고 생각합니다.

원인을 조금씩 이해하다 보면 다음에 비슷한 문제가 발생했을 때 AI에게 무엇을 물어봐야 하는지도 더 명확해집니다.

바이브코딩을 하면서 프롬프트에 대한 생각도 달라졌다

처음에는 프롬프트를 AI에게 질문하는 문장 정도로 생각하기 쉽습니다.

하지만 업무용 AI 코딩에서는 프롬프트가 거의 개발 요구사항처럼 느껴집니다.

예를 들어 다음 다섯 가지를 넣으면 훨씬 구체적인 요청이 됩니다.

Context → Goal → Constraints → Process → Verification

현재 상황은 무엇인지, 무엇을 만들고 싶은지, 무엇을 변경하면 안 되는지, 어떤 순서로 작업했으면 하는지, 마지막으로 무엇을 확인해야 하는지를 설명하는 것입니다.

결국 AI가 좋아질수록 사람에게 필요한 능력도 조금 달라지는 것 같습니다.

코드를 얼마나 빨리 직접 작성하느냐뿐 아니라 내가 원하는 것을 얼마나 정확하게 정의할 수 있느냐도 중요해지고 있습니다.

비개발자에게 바이브코딩이 의미 있다고 느낀 이유

바이브코딩을 접하면서 가장 흥미로웠던 부분은 제가 개발자로 바뀌어야 하는 것이 아니라는 점입니다.

제가 잘 알고 있는 것은 업무입니다.

어떤 과정이 불편한지, 직원들이 어디에서 시간을 많이 사용하는지, 어떤 데이터를 반복해서 정리하는지, 어떤 기능이 있으면 업무가 편해지는지를 발견하는 것입니다.

AI는 그 아이디어를 실제 프로그램 형태로 만들어보는 데 도움을 줄 수 있습니다.

그래서 비개발자에게 바이브코딩의 가장 큰 가능성은 **“개발자가 되는 것”보다 “내가 가진 업무 아이디어를 직접 테스트해볼 수 있게 되는 것”**에 있다고 생각합니다.

그렇다고 개발자가 필요 없어지는 것은 아니다

바이브코딩을 이야기하다 보면 “이제 개발자가 필요 없는 것 아니냐”는 이야기도 나옵니다.

업무용 시스템을 생각하면 그렇게 단순하지 않습니다.

작은 프로토타입을 만드는 것과 여러 직원이 실제로 사용하는 시스템을 운영하는 것은 전혀 다른 문제입니다.

보안, 성능, 데이터베이스, 권한, 유지보수, 테스트 등 고려해야 할 것이 많습니다.

오히려 AI를 이용해 내가 원하는 기능을 먼저 구체화하고 작은 프로토타입을 만들어본다면 개발자와 이야기할 때 요구사항을 더 명확하게 전달하는 데 도움이 될 수 있습니다.

그래서 저는 바이브코딩을 개발자를 대체하는 방법보다는 비개발자와 개발자 사이의 거리를 줄여주는 방법으로 보는 편이 더 적절하다고 생각합니다.

바이브코딩을 시작하면서 가장 크게 달라진 생각

예전에는 프로그램을 보면서

“이건 개발자가 만드는 것.”

이라고 생각하기 쉬웠습니다.

하지만 AI 코딩을 접하고 나면 질문이 조금 달라집니다.

“이 기능은 어떻게 만들어지는 걸까?”

그리고 한 단계 더 나아가면,

“내가 AI에게 요구사항을 설명해서 작은 버전이라도 만들어볼 수 있을까?”

라고 생각하게 됩니다.

저는 이 생각의 변화 자체가 바이브코딩의 재미있는 부분이라고 봅니다.

모든 사람이 개발자가 될 필요는 없습니다.

하지만 자신의 업무에서 불편한 점을 발견하고 그것을 AI에게 정확하게 설명해 작은 도구로 만들어볼 수 있는 사람은 앞으로 더 많아질 것 같습니다.

마무리|바이브코딩은 코딩보다 문제를 발견하는 것에서 시작한다

바이브코딩을 처음 시작한다면 거창한 프로그램부터 만들 필요는 없습니다.

매일 반복해서 하는 Excel 정리, 자주 작성하는 보고서, 여러 화면에서 확인해야 하는 데이터, 반복적으로 입력하는 업무처럼 “왜 이걸 매번 사람이 하고 있지?”라는 생각이 드는 업무 하나를 찾아보는 것이 좋은 출발점입니다.

그리고 AI에게 바로 코드를 만들어달라고 하기 전에 먼저 이렇게 질문해볼 수 있습니다.

“이 업무를 자동화하려면 어떤 기능이 필요할까?”

그다음 기능을 하나씩 나누고, 작은 부분부터 만들어보고, 결과를 확인하고, 다시 수정하는 것입니다.

제가 바이브코딩에서 가장 중요하다고 생각하는 것도 바로 이 부분입니다.

코드를 얼마나 많이 아느냐보다 내가 해결하고 싶은 문제가 무엇인지 정확하게 아는 것.

비개발자에게 바이브코딩은 개발자가 되기 위한 새로운 공부라기보다, 그동안 머릿속에만 있던 업무 개선 아이디어를 직접 시험해볼 수 있는 새로운 방법이 될 수 있습니다.

Post a Comment

0 Comments

Report Abuse

About Me

Search This Blog

Labels