바이브코딩의 어려움 1.
기본을 모르면 피곤하다
베타 테스트를 통한 마무리 단계
현재 500자 소설 챌린지 앱은 마무리 단계다. 마무리 단계이지만, 뜻하지 않은 내용들이 뒤늦게 발견되어 계속 살이 붙고 있는 중이다;;
그래도 기본 프로세스는 거의 정착이 되었으니 마무리 단계라 봐도 되지 않을까??
AI의 코드 생성은 경이롭지만
제미나이3는 써보지 않아서 잘 모르겠지만, 쌩초보인 나를 멱살 잡고 하드캐리한 GPT 5.1도 가공할 만한 위력을 지니고 있다.
‘내가 전체 리팩토링 해줘!’
라고 당당하게 요구를 해도 몇 백줄의 코드를 단숨에 해치우니 말이다.
다만, 이런 녀석 덕에 오히려 장시간 뺑뺑뺑 헤맬 때도 있으니 이건 어디까지나 내 취약한 기본기 탓이다.
까막눈을 위한 마법의 주문, ‘해줘!’
당장 기억에 남는 대표적인 경우가 대략 아래와 같은 구문이다.
import { EditorNextSetp } @supabaseAdmin
당연히 쌩초보인 난 이게 정확히 뭘 말하는지 몰랐다.
이제야 삽질 끝에 대략 { } 안에 든 내용을 위해 @ 뒤에 있는 경로의 파일에서 뭔가를 불러온다 정도는 알게 되었지만,
그건 불과 며칠 전에 습득한 지식이다. 당시의 난 까막눈이었다.
그런 까막눈을 위해 GPT에게 또 한 차례 리팩토링을 ‘해줘!’를 시전했고, GPT는 지시 받은 대로 씩씩하게 열일을 했다.
그런데 바로 오류가 터졌다.
솔직히 왜 오류가 터지는지도 모른다.
그저 AI가 그렇다고 하니 그러려니 하고 수정하라는 대로 몇 군데를 다시 보며, 몇 차례고 수정을 했지만 쉽게 해결되지 않았다.
supabaseAdmin, supabaseClient
그렇게 얼마나 시간이 지났는지도 모르겠다. 내 육체가 비실비실 할 때쯤
GPT가 내게 으르렁됐다.
‘그렇다면, supabaseClient 에 #######가 없을 수도 있으니 다시 아래 구문이 있는지를 확인해 주세요.’
“supabaseClient? 우린 그런 파일을 만든 적이 없잖아? 없으니 당연히 그런 구문이 없지!”
‘그럼, 혹시 supabaseAdmin 파일은 있나요? 그 안을 살펴봐 주세요.’
그래서 알게 되었다. 녀석은 나의 잦은 변경 지시에 휩쓸려
import { EditorNextSetp } @supabaseAdmin 를
import { EditorNextSetp } @supabaseClient 로 멋대로 수정해뒀던 거다.
비슷비슷한 폴더를 비슷비슷하게
AI는 평균값을 지향한다. 그건 코딩에서도 예외가 아니다.
/app 폴더 /api 폴더 route.ts 와 page.tsx
등등
꼭 그런 파일명이나 폴더명일 필요도 없지만, 사용자를 위한다는 명목으로 폴더나 파일명을 비슷비슷한 모양새로 만든다.
그러니 녀석에겐 평소 supabaseAdmin 나 supabaseClient 도 그런 맥락이었던 거다.
기본적을 DB를 supabase로 두고 사용할 수 있도록 사용자를 이끈 만큼 그것과 관련된 파일 역시 하나같이 비슷비슷한 이름이다.
예견된 오류와 쌓이는 눈치
그러니 그런 사고는 얼마든지 일어날 수 있는 경우였다.
이건 내가 기억하고 있는 대표적인 사례 중 하나일 뿐, 난 대단하지 않은 웹앱을 개발하는 동안 유사한 이유로 뺑뺑이를 돈 경험이 많다.
그나마 다행이라면, 여전히 코딩 관련 기본지식 등은 형편 없지만, GPT와 협업하는 과정에 대해서는 눈치가 점점 생긴다는 거다.
예를 들어, 에러는 배포 전에 로컬에서 최대한 사전에 잡아낸다.
코드를 알려준 대로 긁어복사해서 붙여넣기 한 것으로 끝내지 않고 비주얼스튜디오코드에서 빨간줄이 뜨는 건 사전에 해결한다. 실제 빌드 과정에서 무난히 넘어갈 때도 많았지만, 배포 이후 웹에서 막히는 경우가 많았다.
그 다음으로는 꼭 터미널에서 npm run build를 해준다.
별 거 아니라지만, 터미널에서는 에러 발생 시 대부분 이유를 바로 알려주기 때문에 배포 전에 확인할 수 있다면 감사한 일이다.
기본 중의 기본이지만
물론, 이 정도는 단순한 개발이라도 개발업무를 하는 사람에겐 기본 중의 기본일 테다.
헌데, 난 스승없이 홀로 AI와 입만 털면서 시작한 입장에서 이 사실을 담담하게 글로 옮기기까지 결코 쉽지가 않았다.
그리고 글에는 단순히 ‘경고문을 미리 처리한다’, ‘터미널에서 빌드업을 하고 처리한다’ 라고 적었지만,
중요한 건 그 둘을 해결하는 과정이다.
프로젝트가 점점 살이 붙어서 커져가고 코드가 한 페이지에 700행씩 넘어가기 시작하면,
AI도 전체를 리팩토링 해주기보다는 사용자에게 가급적 고칠 부분만을 적당히 알려주는 식으로 대응 방식을 바꾸게 된다.
아무래도 내가 위에 적은 것처럼 스스로 리팩토링 하는 과정에서 다른 파일이나 경로를 오지정하는 경우가 생길 수도 있고,
개발 흐름과 전체 코드를 동시에 다 꿰고 있는 상태가 아니다 보니 이전의 내용으로 고쳐버리거나, 이전의 잔재를 남긴 채 내버려둘 수도 있기 때문이다.
실제로 어제만 하더라도 기가 차고, 코가 막히는 경험을 또 했는데... 이건 천천히 풀도록 하겠다.