2 min to read
바이브 코딩은 어디까지 유효할까
LLM 코딩 도구를 자동완성의 확장으로 바라보는 이유
들어가며
AI 시대라는 표현이 더 이상 과장이 아닌 시점이 되었습니다. 개발자 블로그를 운영하면서 개인적인 생각을 정리하는 short essay 카테고리를 유지하고 있는 입장에서, 이 주제에 대해 한 번쯤은 글을 남기고 싶었습니다.
다만 이 글은 어디까지나 개인적인 의견에 가깝습니다. 레이 커즈와일 같은 미래학자의 통찰이라기보다는, 현장에서 개발을 하며 느낀 인상을 정리한 정도에 가깝습니다. 이 글을 읽는 분들이 “아, 이 사람은 이렇게 생각하는구나” 정도로 받아들여 주신다면 충분할 것 같습니다.
2020년대 초반의 AI와 ‘환각’
2016년 알파고와 이세돌 九단의 대국 이후, AI가 사회 전반에 큰 변화를 가져올 것이라는 전망은 많은 사람들에게 자연스러운 인식이 되었습니다. 그 대국 자체도 여러모로 상징적인 사건이었지만, 개인적으로 흥미롭게 느꼈던 지점은 이세돌 九단이 승리한 제4국에서 알파고의 ‘실수’가 드러났던 순간입니다.
ChatGPT가 대중화된 이후, 소위 ‘세종대왕 맥북프로 던짐 사건’처럼 황당한 답변을 만들어내는 AI의 환각(hallucination)은 LLM을 사용해 본 사람이라면 한 번쯤 경험해 보았을 것입니다.
물론 이러한 문제를 줄이기 위해 모델은 계속 개선되고 있습니다. 더 많은 데이터를 학습하고, 검색 엔진을 통해 최신 정보를 가져오거나, 사용자 데이터를 활용하는 에이전트형 시스템도 등장했습니다. 그럼에도 불구하고 환각을 완전히 제거하는 것은 본질적으로 쉽지 않은 문제입니다. LLM이 통계적으로 다음 토큰을 예측하는 구조라는 점을 생각하면, 어느 정도는 구조적으로 발생할 수밖에 없는 현상이라고도 볼 수 있습니다.
프로그래밍 보조 도구로서의 AI와 ‘AI slop’
그 이후 GitHub Copilot이 공개되면서, 코드 작성 AI가 실제 개발 환경에서 사용될 수 있다는 가능성이 널리 알려졌습니다. 당시에는 지금처럼 누구나 바로 사용할 수 있는 서비스가 아니었고, 대기 리스트에 등록하고 초대를 받아야 사용할 수 있는 형태였습니다.
저 역시 당시 대기 리스트에 등록했지만 바로 사용해 보지는 못했고, 대신 다른 대안을 찾아보게 되었습니다. 예를 들어 당시 작성했던 tabnine 관련 글을 보면 github copilot alternative라는 문구가 마케팅 문장으로 사용되고 있었는데, 그만큼 당시의 분위기를 보여주는 사례라고 생각합니다.
흥미로운 점은 지금 돌아보면 tabnine의 설명이 꽤 솔직했다는 것입니다. 스스로를 ‘AI 자동완성(autocomplete) 도구’라고 설명했는데, 이는 LLM의 본질적인 작동 방식과 크게 다르지 않습니다. 결국 이러한 모델들은 다음 토큰을 예측하는 방식으로 문장을 생성하기 때문입니다.
물론 당시의 예측 품질은 지금보다 훨씬 낮았습니다. 그래서 아래와 같은 우스운 상황도 종종 발생했습니다.
그럴듯한 추론처럼 보이지만, 영어에서 달(month)을 나타내는 단어들은 규칙적으로 만들어진 것이 아니라 역사적으로 굳어진 표현이기 때문에 결국 12개를 각각 외워야 합니다.
저의 의견 — 자동완성 도구로서는 훌륭하지만
현재의 AI 코딩 도구들은 과거보다 훨씬 발전했습니다. 다만 여전히 관찰되는 특징이 하나 있습니다. 비교적 좁은 범위의 구현 문제에는 강하지만, 시스템 전체의 구조나 설계 맥락까지 고려하는 능력은 제한적이라는 점입니다.
예를 들어 React 코드에서 특정 상황에서 리렌더링이 발생하지 않는 문제가 있다고 합시다. 사람이 접근한다면 상태 흐름이나 컴포넌트 구조를 다시 검토할 가능성이 높습니다. 그러나 AI가 제시하는 해결책을 보면 key prop을 추가해 강제로 리렌더를 유도하는 방식처럼, 문제의 근본 원인보다는 단기적인 해결책에 가까운 경우가 종종 있습니다.
물론 이런 도구들이 쓸모없다는 의미는 아닙니다. 오히려 구현 단계에서는 상당히 강력한 생산성 도구라고 생각합니다. 다만 설계, 도메인 이해, 사용자 요구사항 해석 같은 영역까지 전적으로 맡기기에는 아직 한계가 분명합니다.
그래서 개인적으로는 AI를 ‘자동완성 도구의 확장판’ 정도로 이해하는 것이 현실적인 접근이라고 생각합니다. 간단한 프로토타입이나 개념 검증(POC)을 빠르게 만드는 용도라면 매우 유용하지만, 장기적으로 유지보수해야 하는 제품의 설계까지 전적으로 맡기는 것은 아직은 조심할 필요가 있습니다.
적어도 현재 시점에서는, 바이브 코딩이라는 방식이 모든 개발 문제의 해결책이 되기보다는 특정 상황에서만 유효한 도구에 가깝다고 생각합니다.
