바이브코딩, AI에게 맡기면 끝일까? 직접 앱을 만들며 배운 것들

바이브코딩, AI에게 맡기면 끝일까? 직접 앱을 만들며 배운 것들

처음 바이브코딩을 접했을 때는 꽤 단순하게 생각했습니다.

"내가 원하는 걸 말하면 AI가 코드를 짜주고, 나는 결과만 확인하면 되는 거 아닌가?"

실제로 처음에는 그렇게 시작했어요.

만들고 싶은 기능을 설명하면 AI가 코드를 만들어줬고, 

오류가 발생하면 에러 내용을 다시 보여주면서 고쳐달라고 했습니다.

그런데 강의를 듣고, 

실제로 앱 하나를 계속 만들어보면서 생각이 많이 달라졌습니다.

AI가 코드를 대신 작성해주는 건 맞지만, 

무엇을 만들지 결정하고 결과가 제대로 만들어졌는지 판단하는 일까지 대신해주는 건 아니었습니다.

오히려 바이브코딩을 계속할수록 제가 배워야 할 것도 같이 늘어났어요.

1. 바이브코딩에서 중요한 건 코딩보다 먼저 '뭘 만들 것인가'였다

처음에는 좋은 프롬프트를 작성하는 방법부터 배워야 할 것 같았습니다.

그런데 실제로 만들어보니 그보다 먼저 필요한 게 있었어요.

그래서 뭘 만들 건데?

였습니다. ㅋㅋ

AI가 아무리 코드를 잘 만들어줘도 

제가 원하는 게 불분명하면 결과 역시 계속 바뀌었습니다.

그래서 새로운 걸 만들기 전에는 최소한 이런 질문부터 해보는 게 좋았습니다.

• 무엇을 만들고 싶은가? 왜 만들고 싶은가?

• 누가 사용할 것인가?

• 그 사람은 지금 이 문제를 어떻게 해결하고 있는가?

• 기존 방법보다 내가 만들려는 것이 정말 편한가?

거창한 사업계획서까지 작성할 필요는 없었습니다.

다만 내가 해결하고 싶은 문제가 무엇인지는 명확해야 했어요.

이게 정리되지 않은 상태에서 AI와 대화를 시작하면 

기능 하나 만들다가 다른 기능이 생각나고, 

그것을 추가하다 처음 생각했던 앱과 전혀 다른 방향으로 가기도 했습니다.

저도 많이 해봤습니다. ㅋㅋ.. 

아 잠시 눈물 좀 닦을게요...훌쩍..

2. PRD는 완벽한 설계도라기보다 AI와 나의 기준점에 가까웠다

이 과정에서 PRD라는 것도 배우게 됐습니다.

PRD(Product Requirements Document)는 쉽게 말하면 

'어떤 제품을 왜, 어떻게 만들 것인지 정리해둔 요구사항 문서' 

정도로 이해하면 됩니다.

처음에는 이것도 굉장히 꼼꼼하게 작성해야 하는 줄 알았어요.

하지만 직접 작업해보니 반드시 처음부터 완벽할 필요는 없었습니다.

오히려 저는 큰 방향을 먼저 정하고,

기본 구조 작성 → 기능 하나 구현 → 확인 → 다음 기능 구현 → 중간 정리

처럼 진행하는 방식이 더 잘 맞았습니다.

실제로 작업하다 보면 생각이 바뀌기도 합니다.

처음에는 필요하다고 생각했던 기능을 빼기도 하고,

만들다 보니 새로운 기능이 필요해지기도 하니까요.

그래서 지금은 PRD를 절대로 바뀌면 안 되는 설계도라기보다는,

AI와 제가 같은 방향을 보고 작업하기 위한 기준점

에 가깝게 생각하고 있습니다.

3. 프롬프트를 잘 쓰는 게 중요한 이유도 조금 달랐다

바이브코딩을 시작하기 전에는 

'프롬프트 잘 쓰기'라고 하면 

뭔가 특별한 주문(?)을 작성하는 기술처럼 

느껴졌습니다.

직접 해보니 조금 달랐어요.

결국 중요한 건 

AI가 헷갈리지 않도록 내가 원하는 것을 정확하게 설명하는 것

이었습니다.(사실 이게 아직도 어려워요..)

예를 들어 단순하게,

로그인 기능 만들어줘.

라고 요청하는 것과,

어떤 프로젝트에서 작업하고 있는지, 

어떤 방식을 사용해야 하는지, 

어디까지 구현되어야 완료인지 알려주는 것

은 결과가 꽤 달랐습니다.

제가 AI와 작업하면서 특히 중요하다고 느낀 건 세 가지였습니다.

현재 상황, 원하는 작업, 완료 기준.

무엇을 만들고 있는지 알려주고,

이번에 무엇을 해야 하는지 알려주고,

어떤 상태가 되면 작업이 끝난 것인지 알려주는 겁니다.

이게 잘 정리될수록 AI와

"아니 그게 아니라…."

"아까 말한 건…."

하면서 다시 설명하는 횟수가 줄었습니다.

결국 시간도 덜 들고 AI 사용량도 줄어들었어요.

4. 모르는 기술은 아는 척하지 않고 AI에게 먼저 물어봤다

비개발자로 시작하면 

애초에 정확한 개발 용어를 모르는 경우가 많습니다.

저도 마찬가지였어요.

뭔가 만들고 싶은 모습은 머릿속에 있는데 

그걸 개발 용어로 뭐라고 부르는지 모르는 겁니다.

이럴 때 억지로 전문용어를 찾아서 

프롬프트를 만들기보다 그냥 물어봤습니다.

"이런 기능을 만들고 싶은데 이걸 뭐라고 해?"

화면을 보여주면서,

"이런 걸 만들려면 어떤 방식으로 구현해야 해?"

라고 묻기도 했고요.

그러다 보면 처음에는

"그 버튼 누르면 옆에서 뭐가 나오는 거 있잖아."

수준이었던 설명이 ㅋㅋ

점점 정확한 기술 용어와 구조를 사용해서 설명하는 쪽으로 바뀌기 시작했습니다.

이 과정도 바이브코딩을 하면서 얻은 의외의 공부였습니다.

5. AI가 코딩해도 테스트는 결국 내가 해야 했다

이건 실제 앱을 만들면서 꽤 크게 느꼈습니다.

AI가

"수정 완료했습니다."

라고 말하는 것과

실제로 내 앱이 정상적으로 작동하는 것

은 다른 이야기였습니다. ㅋㅋ

코드상 오류가 없다고 해서 

제가 원했던 화면이 나오는 것도 아니었고, 

기능 하나가 정상적으로 작동한다고 

다른 기능까지 멀쩡하다는 보장도 없었습니다.

그래서 나중에는 단순히

이거 구현해줘.

로 끝내기보다,

구현 → 테스트 → 문제 수정 → 다시 테스트

하는 흐름을 중요하게 보기 시작했습니다.

AI에게 테스트 코드 작성을 함께 요청하기도 하고, 

자동 테스트가 통과하더라도 

실제 기기에서 제가 직접 눌러보며 확인했습니다.

특히 화면이나 사용성은 사람이 봐야 알 수 있는 문제가 꽤 있었어요.

버튼은 작동하지만 위치가 이상하다든지,

글자가 이상하게 줄바꿈된다든지,

기능 자체는 정상인데 실제로 사용하면 불편하다든지.

결국 

'코드가 동작한다'와 '내가 원한 제품이 만들어졌다'는 다른 문제

였습니다.

6. 그래서 에러도 바이브코딩 공부의 일부였다

지난 글에서 제 앱이 버그 덩어리가 됐다는 이야기를 했었죠. ㅋㅋ

당시에는 그냥

"왜 또 안 돼!!!"

였지만,

지나고 보면 오류를 해결하는 과정에서 배운 것도 많았습니다.

에러 메시지를 보고,

AI에게 물어보고,

수정된 파일을 비교하고,

다시 실행해보고….

이걸 반복하다 보면 

처음에는 외계어 같았던 오류 메시지에서도 

조금씩 아는 단어가 보이기 시작합니다.

중요한 건 무작정 실패를 반복하는 게 아니라,

왜 문제가 발생했는지 하나라도 이해하고 넘어가는 것이었습니다.

그렇게 보면 바이브코딩에서 시행착오는 

단순한 실패가 아니라 꽤 중요한 학습 과정이 됩니다.(중요!! 별 열개!)

물론 에러가 한꺼번에 스무 개 뜨면 그런 생각 안 듭니다.

그냥 화납니다. (엄근진)

7. AI에게 기억시키는 것도 일이었다

프로젝트가 커지면서 새롭게 생긴 문제도 있었습니다.

처음에는 채팅 몇 번이면 충분했지만 

파일과 기능이 늘어나기 시작하면 

AI가 알아야 할 것도 같이 많아졌어요.

어떤 기술을 사용하고 있는지,

폴더는 어떻게 구성하는지,

파일 이름은 어떤 규칙으로 만드는지,

UI는 어떤 방향으로 만드는지,

현재 어디까지 작업했는지….

이런 기준이 계속 필요했습니다.

그래서 점점 

작업 규칙과 프로젝트 상태를 문서로 관리하는 방식

을 사용하게 됐습니다.

예를 들어 

특정 기술 스택만 사용하도록 정하거나, 

폴더와 파일 작성 규칙을 남겨두고, 

현재 작업 상태와 다음 할 일을 기록해두는 식입니다.

처음에는 이런 문서를 만드는 게 귀찮았습니다.

'AI가 알아서 기억하면 안 되나?' 싶었거든요.

그런데 프로젝트가 길어질수록 문서가 있는 편이 오히려 편했습니다.

AI가 바뀌거나 새로운 대화에서 작업을 시작해도 프로젝트의 기준을 다시 알려줄 수 있었기 때문입니다.

이건 여러 AI를 돌아다니다 앱을 한 번 제대로 꼬아본 뒤 더 중요하게 생각하게 된 부분이기도 합니다. ㅋㅋ

8. 결국 사람도 같이 똑똑해져야 했다

처음에는 AI가 발전하면 제가 개발을 많이 몰라도 점점 더 쉽게 만들 수 있을 거라고 생각했습니다.

그 생각 자체가 완전히 틀린 건 아닌 것 같아요.

실제로 예전보다 시작하기는 훨씬 쉬워졌으니까요.

그런데 계속 만들어보니 재미있는 점이 하나 있었습니다.

제가 아는 게 많아질수록 AI도 더 잘 써먹을 수 있었습니다.

제가 정확한 용어를 알고 있으면 원하는 기능을 더 정확하게 설명할 수 있고,

데이터가 어떻게 움직이는지 조금이라도 이해하면 문제가 발생한 위치를 더 쉽게 설명할 수 있습니다.

AI가 이상한 결과를 내놨을 때도

"뭔가 이상한데?"

에서 끝나는 게 아니라,

"여기가 내가 요청한 구조와 다른 것 같은데?"

라고 말할 수 있게 되고요.

결국 AI만 똑똑하면 되는 게 아니었습니다.

AI를 사용하는 사람도 같이 배우면 결과가 훨씬 좋아졌습니다.

9. 그리고 앱은 '실행됐다!'에서 끝나는 게 아니었다

처음 앱 화면이 실제 휴대폰에서 실행됐을 때는 정말 신기했습니다.

내가 생각했던 게 진짜 화면에서 움직이니까요.

비개발자가 바이브코딩에 재미를 붙이는 데 이 경험은 정말 큰 것 같습니다.

그런데 앱을 하나 계속 만들어보니….

실행은 시작에 가까웠습니다. ㅋㅋ

기획하고,

화면을 만들고,

기능을 구현하고,

테스트하고,

오류를 수정하고,

배포 준비를 하고,

실제 사용자에게 테스트를 부탁하고,

피드백을 받아 다시 수정하고….

'앱 하나 만든다' 안에 생각보다 많은 단계가 있었습니다.

개발자가 되기 위해 

이 모든 분야를 처음부터 깊게 공부해야 한다는 뜻은 아닙니다.

저 역시 그렇게 하고 있지 않고요.

다만 지금 내가 어느 단계에 있고 

이 단계에서는 무엇을 확인해야 하는지 정도는 알아야 

AI에게 제대로 일을 시킬 수 있었습니다.

바이브코딩은 '딸깍'보다는 함께 만드는 것에 가까웠다

처음 생각했던 바이브코딩은 이랬습니다.

아이디어 → AI에게 요청 → 딸깍 → 완성!

지금 제가 생각하는 바이브코딩은 조금 다릅니다.

아이디어 → AI와 기획 → 구현 → 내가 확인 → 문제 발견 → AI와 수정 → 테스트 → 다시 개선

코드를 직접 작성하는 비중은 확실히 줄일 수 있습니다.

그리고 개발 경험이 많지 않은 사람도 

자신의 아이디어가 실제로 움직이는 모습을 

훨씬 빨리 볼 수 있게 됐습니다.

그렇다고 해서 생각까지 AI에게 전부 맡길 수 있는 건 아니었습니다.

무엇을 만들 것인지 결정하고, 

AI에게 설명하고, 

결과를 판단하는 건 결국 사람의 역할이었습니다.

그래서 요즘은 세상에 나오는 모든 AI 도구를 다 따라가려고 하지 않습니다.

그것만 해도 하루가 끝날 것 같거든요. ㅋㅋ

제가 만들고 싶은 것에 필요한 도구를 찾아보고, 

필요한 기술을 하나씩 배우고, 

새로운 AI 소식도 필요한 만큼 따라가는 정도로 

방향을 잡았습니다.

바이브코딩으로 

처음부터 거대한 서비스를 만드는 건 

여전히 쉽지 않을 겁니다.

하지만 내가 잘 아는 분야에서,

"이런 거 하나 있으면 진짜 편할 텐데?"

했던 작은 문제를 해결하는 도구를 직접 만들어보는 것.

그 시작은 예전보다 훨씬 쉬워졌다고 느끼고 있습니다.

저 역시 아직 배우면서 만드는 중입니다.

그래도 예전에는 머릿속에만 있던 아이디어가 

실제 앱으로 움직이는 모습을 보고 있으니,

일단 계속 만들어보려고 합니다. :)