바이브코딩은 매순간 똥싸고 퇴사하는 직원이다..
정상적으로 함께 일하던 개발자가 퇴사하면 그 프로젝트는 흔들립니다.
메인개발자가 나가면 흔들리는 정도가 아니라 망합니다.
그 방대한 코딩 양의 숨은 의도와 맥락을 쉽게 이해할 수 없기 때문입니다.
GPT(포크레인처럼 프롬프트형 AI총칭)로 바이브코딩을 하는 것의 문제는
점점 의도와 맥락을 이해하기 어려워진다는 것입니다. 그 양이 늘어날수록.
앞으로 바이브코딩은 그 문제가 드러났을 때 많은 시간이 들어가게 될 겁니다.
마치 퇴사한 직원이 싸놓은 똥을 치우는 것만큼 들어갈 겁니다.
GPT는 진짜 아는게 아니라 몇가지 힌트를 보고 아는 척을 하는 것이라서
쉽게 엉뚱한 방향으로 설계가 진행됩니다. 앞으로 더욱 개선되지도 않을 겁니다.
아는 척에 대한 실수를 애매하게 회피하는 쪽으로 더 성장하고 있다고 느껴집니다.
실제로는 GITHUB등에서 질문에 언급된 주제로 사람이 작성한 예제 소스코드를
퍼와서 리믹스하여 제안할 뿐이라고 생각합니다.
트렌디한 질문에 의해 정확히 맞는 예제가 나오면 놀라운 결과라는
착각을 유발하지만 결국 전 세계 어떤 개발자가 짜서 공개한 것입니다.
누군가 사람이 작성한 코드를 GPT가 다른 사람에게 전달하는 것입니다.
GITHUB저장소 3억개에서 맞춤 정보를 재구성해주는 검색엔진이라고 봐야 합니다.
그럼 GPT라는 너무나도 편리한 도구를 어떻게 사용해야 할까요?
1) 살아있는 API도큐먼트로 사용해야 합니다.
내가 API도큐먼트를 찾는 시간을 획기적으로 줄여주는 정도로 타협점을 찾아야 합니다.
결국 코드는 내가 설계해야 합니다. 완벽한 설계는 없습니다. 왜냐면 정답이 없으니까요.
미래에 코드를 보고 유지보수할 나 자신을 위한 설계여야 합니다. 그게 바로 생산성입니다.
코드량이 나의 기억을 넘어설 만큼 방대해져도 내가 다시 직관적으로 이해하고
업무속도가 항상 최고를 유지할 수 있는 코드. 남이 나중에 내 코드를 보고
연결해서 일한다? 5~10% 성능밖에 나질 않습니다.
내가 퇴사하면 단계적으로 내 코드도 새로운 개발자의 코드로 교체되어야 맞습니다.
2) 코드리뷰어로 사용해야 합니다.
내가 짠 코드를 제 3자가 다른 관점에서 내가 놓친 문제점을 지적해 주는
역할을 부여해야 합니다. 마치 정적분석도구와 같은 역할이죠. 친절하기까지 한.
코드를 커밋할때 GPT코드리뷰를 한 결과를 링크로 붙여도 좋을 것 같네요.
3) 독시즌을 대신할 도구로 써야 합니다. (아직은 별로지만)
앞으로 내 코드를 함수내 알고리즘 맥락까지 분석하여 도큐먼트화를 해주는 도구로 쓰면
좋을 것 같습니다. 아직은 좀 어설프긴 합니다만 앞으로 더 개선되리라 생각합니다.
어설픈 이유는 GPT의 방식이 내 질문을 완전히 이해하는 것이 아니라 내 질문의 몇몇 단어를
통해 가장 유사한 사례를 때려 맞춰서 대답하는 것이기 때문에 내가 짠 함수의 맥락도
유사하게 때려 맞춘 GITHUB의 다른 예제와 그 설명에서 힌트를 얻어 조합해 대답하는
것이라서 아주 새로운 형태의 내 함수는 엉뚱한 판단을 할 수도 있습니다.
그럴 땐 애꿎은 GPT를 탓하기 말고 주석을 달아서 GPT에게 힌트를 더 주면 됩니다.
GPT는 너무나 사랑스러운 조수입니다.
가끔은 꽤 오랫동안 거짓말을 쳐서 나를 당황하게도 하지만
대체로는 내 삽질의 시간들을 크게 줄여주는 비서이자
내가 부족한 도메인지식이나 관련법을 미리 깨우쳐주는 선지자입니다.
바이브코딩이라는 트렌드도 열심히 파보시길 바랍니다.
저도 아직 GPT를 1년정도 써본 개발자에 불과해서 제가 틀릴 수도 있겠죠.
그러나 결국 책임지는 것이 개발자라는 사람이라는 것도 분명합니다.
내 실력과 이해력이 성장하지 않는 개발방법은 독입니다.
자신의 나약함을 스스로 이겨내야 성장합니다.
내 책임과 역할을 떠넘길 생각을 하지 말고
곁에서 도움을 받는 고마운 존재로 삼으라는 것입니다.
