'바이브 코딩'의 함정, 그리고 엔지니어링의 본질을 다시 생각하다

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 개발자 채용 인터뷰나 사내 코드 리뷰를 진행하다 보면, LLM(거대언어모델)을 다루는 방식에서 흥미로우면서도 우려되는 패턴을 발견하곤 합니다. 불과 1~2년 전만 해도 GPT-4가 유일한 정답 같았지만, 이제는 수십 가지의 모델과 도구가 쏟아지고 있죠. 특히 Cursor와 같은 AI 기반 에디터는 개발 생산성을 비약적으로 높여주었습니다. 하지만 최근 저는 팀원들에게 "도구에 매몰되지 말고, 맥락(Context)을 장악하라"는 이야기를 자주 합니다. 오늘은 그 이유에 대해 조금 깊이 있는 이야기를 나눠보려 해요.

최근 업계에서는 이른바 '바이브 코딩(Vibe Coding)'이라는 용어가 화두입니다. 영어 프롬프트 몇 줄만 입력하면 앱 하나가 뚝딱 만들어지는, 마치 SF 영화 같은 경험을 의미하죠. 저 역시 초기에는 이 방식에 매료되었습니다. 하지만 시간이 지나면서 이 '바이브 코딩'이 엔지니어링의 정밀함을 해치고 있다는 사실을 깨달았습니다.

가장 큰 문제는 '토큰 비효율성'과 그로 인한 도구들의 '터널 시야(Tunnel Vision)' 현상입니다. 예를 들어보죠. 랜딩 페이지의 특정 섹션에 있는 아이콘이 마음에 들지 않는다고 가정해 봅시다. 숙련된 개발자라면 해당 파일을 열고 아이콘 이름을 수정하거나, CSS 한 줄을 고치면 끝날 일입니다. 하지만 바이브 코딩에 익숙해진 개발자는 LLM에게 "아이콘 좀 바꿔줘"라고 다시 프롬프트를 보냅니다.

이 과정에서 LLM은 전체 맥락을 다시 읽고, 불필요한 연산을 수행합니다. 사용자가 "아니, 그거 말고 다른 거"라고 반복할수록, 도구는 비용 절감을 위해 필연적으로 최적화를 수행하게 됩니다. Cursor나 Windsurf 같은 도구들이 전체 코드를 읽는 대신, 현재 관련된 100~200줄의 코드만 읽거나 `ripgrep` 같은 검색 도구로 필요한 부분만 발췌해서 컨텍스트에 넣는 방식으로 진화한 배경입니다.

이것이 바로 위기 상황을 초래합니다. 단순한 UI 변경에는 이런 방식이 효율적일지 모릅니다. 하지만 서로 복잡하게 얽혀 있는 비즈니스 로직을 다룰 때, 도구는 코드베이스의 다른 부분에 존재하는 의존성을 놓치게 됩니다. "왜 이미 만들어둔 유틸리티 함수 X를 안 쓰고 새로 만들었니?"라고 물으면 AI는 "죄송합니다"라고 답하죠. 이건 AI의 지능 문제가 아니라, 도구가 비용 효율을 위해 시야를 좁혔기 때문에 발생한 구조적인 문제입니다. 즉, 편리함을 추구한 '바이브 코딩' 스타일이 역설적으로 전문적인 엔지니어링 도구로서의 가치를 떨어뜨린 셈입니다.

저는 이 문제를 해결하기 위해, 역설적이게도 더 원시적인 방법으로 회귀했습니다. 바로 '컨텍스트를 직접 통제하는 것'입니다.

최근 저는 복잡한 설계를 할 때, 자동화된 에이전트 기능을 끄고 Google AI Studio나 Claude의 프로젝트 기능을 활용해 직접 컨텍스트를 주입합니다. 필요한 모든 모듈과 파일을 하나의 거대한 텍스트 뭉치로 만들어 LLM에게 던져주는 방식이죠. 특히 Gemini 2.5 Pro나 Claude 3.5 Sonnet/Opus 모델에 전체 코드베이스의 맥락을 온전히 제공했을 때, AI는 비로소 '추측'이 아닌 '이해'를 바탕으로 코드를 작성합니다.

우리는 편의성이라는 함정에 빠져 '엔지니어링'을 '채팅'으로 대체하려 했는지도 모릅니다. 코드를 직접 보지 않고 느낌(Vibe)만으로 개발하려는 시도는 결국 기술 부채로 돌아옵니다. 주니어 개발자분들께 특히 강조하고 싶습니다. AI는 훌륭한 도구이지만, 그 도구가 무엇을 보고 있고 무엇을 보지 못하는지를 판단하는 것은 결국 인간 엔지니어의 몫입니다.

자동화된 도구가 주는 달콤함에 취해 코드의 전체 구조를 놓치지 마세요. 때로는 조금 불편하더라도, 전체 맥락을 손에 쥐고 AI를 리딩하는 'Human-in-the-loop' 방식이 가장 빠르고 정확한 길임을 잊지 않으셨으면 합니다. 기술이 발전할수록, 본질을 꿰뚫어 보는 눈은 더욱 중요해지니까요.