Andrej Karpathy의 게시물이 바이럴되면서 “바이브 코딩(Vibe Coding)”은 올해의 유행어가 되었습니다. 이는 코드를 직접 작성하지 않고 AI의 도움만으로 프로그래밍을 수행하는 방식을 말합니다. 코드가 제대로 작동하지 않으면 AI에게 다시 시도하게 하거나, 문제를 설명하는 수정된 프롬프트를 사용합니다. Simon Willison은 바이브 코딩이 무엇인지, 언제 적절한지, 어떻게 하는지를 다룬 훌륭한 블로그 글을 작성했습니다. 그는 바이브 코딩에 긍정적인 입장이지만, 많은 사람들이 Karpathy의 트윗을 끝까지 읽지 않았다는 점에 대해 아쉬움을 드러냅니다. Karpathy는 바이브 코딩이 주말 프로젝트에 가장 적합하다고 말합니다. 그는 다음과 같은 답변을 남겼습니다:

…실제로 저는 거의 전적으로 바이브 코딩을 하지 않으며, 여전히 코드를 직접 확인하고, 복잡성을 천천히 추가하며, 시간이 지남에 따라 각 요소가 어떻게 작동하는지 배우고, 명확한 질문을 던지려 합니다.

저는 지난 몇 달간 바이브 코딩을 실험해 보았습니다. 먼저 면책 조항부터 말씀드리자면, 저는 오랫동안 프로그래밍을 해왔지만 전문 프로그래머는 아니었습니다. 제 프로그래밍은 주로 “주말 프로젝트”와 O'Reilly를 위한 빠른 데이터 분석 중심이었습니다. 바이브 코딩을 할 때 GitHub Copilot이나 Cursor 같은 도구는 일부러 사용하지 않았습니다. 특히 Claude Code는 프로그래밍의 미래를 엿볼 수 있을 것 같아 유혹을 느꼈지만, 경험을 순수하게 유지하고 싶었습니다. 그래서 모델에 프롬프트를 주고, 결과를 복사해 파일에 붙여넣고 실행하는 방식으로만 작업했습니다.
버그 수정을 위해 코드를 직접 편집한 적은 거의 없고, 편집은 두 가지 경우에만 제한했습니다: 어떤 모델이 해당 코드를 생성했는지를 설명하는 주석을 추가할 때 (지금 생각하면, 프롬프트에 포함했어야 했습니다), 공개된 모델에서 개인 정보를 보호하기 위해 더미 파일 이름과 URL을 삽입할 때입니다.

바이브 코딩은 실제로 작동합니다. 물론 항상 그런 것은 아니고, AI가 전문적인 수준의 코드를 만들어내도록 하려면 어느 정도 노력이 필요합니다. 하지만 인내심을 가지고 작업하면, 직접 작성하는 것보다 적은 노력으로 작동하는 코드를 얻을 수 있습니다. 제가 얻은 몇 가지 관찰은 다음과 같습니다:

• 모델에게 원하는 바를 정확하게 전달해야 합니다: 입력이 무엇이고, 출력이 무엇이며, (종종) 입력에서 출력으로 가는 방식까지 설명해야 합니다.
• 가능한 알고리즘이 여러 개 있을 경우, 어떤 알고리즘을 사용할지 명확히 지시해야 합니다. 관심이 없다면 생략해도 되지만, “계산적으로 효율적인 방식으로 다시 작성해줘” 정도의 지시만으로도 충분할 수 있습니다.
• AI는 사용자의 지시를 약간 잘못 해석하는 데 매우 능숙합니다. 때로는 마치 맥베스의 마녀들과 대화하는 기분이 들기도 합니다.
• AI가 생성한 코드의 품질에 대해 불평할 수도 있지만, 제가 직접 작성했을 법한 코드와 적어도 비슷한 수준이었습니다.
• AI는 테스트를 생성하는 데 나쁘지 않지만, 테스트 케이스를 선정하는 데는 서툽니다.
• AI는 많은 오류 검사와 예외 처리를 포함시키는데—솔직히 말해 짜증날 정도로 많습니다. 하지만 이러한 부분은 생산용 소프트웨어나 타인과 공유되는 코드에선 도움이 됩니다.
• AI에게 버그 수정을 시키는 일은 놀라울 정도로 간단했습니다. 오류 메시지를 채팅에 붙여넣는 것만으로도 대부분 해결되었습니다. 더 미묘한 오류(결과가 틀린 경우)에 대해서는 “입력 Y에 대한 결과 X가 틀렸습니다”라고 말하는 것으로 충분했습니다. 물론, 이 실험은 수백만 줄에 달하는 기업용 코드베이스가 아니라 단순한 코드였다는 점은 감안해야 합니다.

이제 간단한 관찰은 이쯤하고, 좀 더 자세히 살펴보겠습니다.

AI가 테스트 케이스를 잘 선택하지 못한다는 점을 이야기했는데, 새로운 모델을 시험할 때 제가 가장 좋아하는 테스트 중 하나는 “소수가 아닌지 확인하는 프로그램”을 작성하게 하는 것입니다. 그런데 프로그램이 제대로 작동하는지 어떻게 알 수 있을까요? 저는 1억 이하의 모든 소수를 담은 파일을 가지고 있어서, 그 중 몇 개의 숫자를 뽑아 테스트를 작성하도록 했습니다. 모델은 2, 3, 5, 7, 11—처음 다섯 개의 소수만을 테스트 케이스로 선택했습니다. 만족스럽지 않았습니다. 그래서 “파일에서 무작위로 소수를 선택하고, 소수가 아닌 수를 테스트하기 위해 두 개의 소수를 곱하라”고 요청했습니다. 결과적으로 프롬프트는 훨씬 길고 어색해졌지만, 더 나은 테스트가 생성되었습니다. 비슷한 상황은 다른 경우에도 있었습니다. 모델이 특별히 요구받지 않으면, 지나치게 단순한 테스트를 생성했습니다.

알고리즘 선택은 또 다른 문제였습니다. 소수 판별 프로그램을 처음 바이브 코딩으로 만들었을 때, 모델은 단순한 무차별 대입 방식을 사용했습니다. 이건 성능이 부족했습니다. 그래서 Miller-Rabin 알고리즘을 명시하자, 약간의 버그는 있었지만 그 알고리즘을 기반으로 한 코드가 나왔습니다. 또 다른 모델에게 성능이 좋은 알고리즘으로 해달라고 요청했더니 역시 Miller-Rabin을 선택했습니다. 프롬프트가 항상 매우 명확할 필요는 없다는 뜻이기도 합니다. AKS 알고리즘을 요청했을 때는—정확한 결과를 보장하는 더 복잡한 방식입니다—모델이 “AKS는 구현이 어렵다”며 대신 Miller-Rabin을 제안했습니다. 비슷한 경험은 행렬식 계산에서도 있었습니다. 처음 요청했을 땐, 팩토리얼 시간 복잡도를 가진 재귀 구현을 제시했는데, 이는 우아하지만 비실용적이었습니다. LU 분해를 명시하자 Python의 NumPy 라이브러리를 사용해 비교적 적절한 코드를 제공했습니다. 라이브러리 없이 LU 분해를 수행하는 코드를 요청했을 때는 작동하지 않았습니다. 재미는 없었지만, 현실적으로는 라이브러리를 활용하는 것이 낫다는 걸 알게 되었습니다. AI가 가져오는 라이브러리가 실제 존재하는지도 항상 확인해야 합니다.

코드에서 상수를 제거하는 것이 좋은 습관이듯, 프롬프트에서도 상수 사용을 피하는 것이 좋습니다. 예를 들어, 스프레드시트의 세 번째 탭을 사용하도록 지시했을 때, 모델은 pandas가 0부터 인덱스를 시작한다는 사실을 알고 있어 코드에는 2를 사용했습니다. 하지만 저는 Polars 라이브러리에 대해 궁금해졌고, Claude에게 코드를 변환해달라고 요청했더니, 2는 그대로 유지되었습니다. Polars는 1부터 시작하기 때문에 디버깅이 필요했습니다. 이 사례는 인위적으로 보일 수 있지만, 실제로는 모델을 변경하거나 새로운 세션을 시작하는 일이 흔하다는 점에서 중요한 교훈입니다. 코드에서 상수를 제거하고 사람과 AI가 모두 이해하기 쉬운 코드를 작성하는 습관은 프롬프트에서도 두 배로 중요합니다.

비슷한 맥락에서, 프롬프트에 사용자 이름, 비밀번호, API 키 등 자격 증명을 포함하지 마세요. 어디로 전달될지 알 수 없습니다. 구성 파일에서 읽어들이는 방식이 좋습니다. 온라인 데이터의 파일 이름이나 URL 또한 민감할 수 있습니다. 회사 데이터를 다루는 경우라면 “더미 URL을 사용하고, 실행 전 채워 넣겠습니다”라고 지시할 수 있습니다. 저는 두 가지 접근 방식을 시도해 보았습니다: 작게 시작해 점진적으로 확장하는 방식, 가능한 한 완전하게 문제를 설명하는 방식입니다.

첫 번째는 제 개인적인 프로그래밍 스타일과도 비슷하고, Karpathy가 제안한 방식과도 유사합니다. 예를 들어, 스프레드시트 작업을 시작할 때 먼저 행 수를 출력하는 간단한 코드부터 작성합니다. 이후 계산 단계를 하나씩 추가하고, 매 단계마다 테스트를 진행합니다. 마치 개인적인 “애자일” 프로세스처럼요. 이런 방식은 오류를 빨리 발견하고 AI에게 수정 요청을 하기 쉽습니다. 반면, 두 번째 방식은 수백 단어짜리 거대한 프롬프트로 문제를 한 번에 설명하는 것입니다. 이 방식도 동작하지만 오류가 더 자주 발생했습니다. 그리고 종종 버그의 원인은 AI가 아니라 제가 빠뜨린 정보였습니다. AI에게 수정 사항을 다시 설명하는 일도 더 복잡해졌습니다. 이럴 땐 아예 새 세션을 시작하는 것이 쉬울 수도 있지만, 그 경우 기존 맥락이 모두 사라집니다. 결론적으로, 두 가지 접근 방식 모두 가능하니 자신에게 더 편한 방법을 선택하면 됩니다.

AI 지원 프로그래밍에 대해 글을 쓴 많은 사람들이 공통적으로 말하는 바는 이것입니다:  “AI 덕분에 전에는 시도하지 않았을 일도 해볼 수 있었다.”

저도 그랬습니다. 처음에는 Google Drive에서 스프레드시트를 다운로드하는 것으로 시작했지만, 15분 만에 한 시간 걸릴 프로그램을 완성한 뒤엔 이런 생각이 들었습니다: “프로그램이 직접 스프레드시트를 다운로드하면 어떨까?” “아예 데이터를 직접 가져오면 어떨까?” “로컬 복사본이 없을 때만 다운로드하게 하면 어떨까?”

몇 분간의 바이빙만으로도 저는 많은 것을 배웠습니다. 그중 하나는 자동화가 오히려 수동보다 더 많은 작업을 요구할 수도 있다는 점이었습니다. 하지만 적어도 이제는 그런 선택이 가능한 시점과 불가능한 시점을 판단할 수 있게 되었습니다. 또한 현재 AI 모델이 기존 코드를 망가뜨리지 않고 기능을 추가하는 데 꽤 능숙하다는 것도 알게 되었습니다. 짧은 프로그램에 한정되긴 하지만, AI가 기존 코드를 다시 작성할까봐 걱정할 필요는 없었습니다. 대부분의 온라인 AI 챗 서비스는 제가 생각하는 사이에도 흐름을 유지할 만큼 충분히 빠르게 작동했습니다. 하지만 프로그램이 길어질수록 “설명 말고 코드만 보여줘”라고 말하고 싶어질 만큼 느려지기도 했습니다. Steve Yegge의 예측에 공감하게 된 순간이었습니다. 다음 단계는 여러 모델을 동시에 사용하는 대시보드가 될 것입니다.

로컬에서도 작은 모델을 실행해 보았습니다. Gemma 3(4B), QwQ(32B), DeepSeek R1(32B) 등을 시도했는데, 결과적으로는 “서둘러 기다리는” 경험이었습니다. 추론 전용 모드를 사용하지 않아도 프롬프트 입력부터 코드 생성까지 몇 분이 걸렸습니다. GPU가 있었다면 더 나았겠지만, 그럼에도 의미 있는 실험이었습니다. 작은 모델은 큰 모델보다 오류가 더 많았지만, 회사 재무나 의료 정보 등 데이터 유출이 우려되는 환경에선 훌륭한 대안이 될 수 있습니다. 다만 고사양 노트북이나 데스크톱(64GB RAM 이상과 NVIDIA GPU)과 많은 커피가 필요합니다.

그렇다면, 우리는 어디쯤에 있을까요? 아니면, 제가 어디에 있을까요? 바이브 코딩은 재미있었고, 분명 저를 더 효율적으로 만들어 주었습니다. 하지만 AI를 사용하는 것이 어느 순간부터 ‘지팡이’가 되는 걸까요? 저는 프로그래밍을 자주 하지는 않기 때문에 바이브 코딩을 지속적으로 사용하면 제 프로그래밍 실력이 떨어질지도 모릅니다. 그게 문제가 될까요? 플라톤은 문해력이 기억력에 위협이 된다고 걱정했습니다. 그리고 어떤 면에서는 옳았습니다. 우리는 더 이상 모든 문학을 암기한 방랑 시인을 가지고 있지 않습니다. 그게 문제일까요? 제가 프로그래밍을 시작했을 때, 저는 PDP-8 어셈블리를 좋아했습니다. 이제 어셈블리어 프로그래머는 일부 전문가 그룹에만 속해 있습니다. 그리고 장치 드라이버를 작성하지 않는 한, 거의 필요하지 않습니다. 되돌아보면, 우리는 크게 잃은 것이 없다고 생각합니다. 프로그래밍의 본질은 기계가 원하는 것을 하도록 만드는 것이지, 언어 퍼즐을 푸는 것이 아니라고 생각해왔습니다—물론 많은 사람들이 여기에 동의하지는 않을 것입니다.

우리는 갈림길에 서 있습니다. AI 지원 프로그래밍은 확실히 미래입니다. 하지만 프로그래밍을 배우는 것도 여전히 중요합니다. 바이브 코딩을 하지 않더라도, 우리는 어떤 형태로든 AI의 도움을 받게 될 것입니다. 도구들은 이미 충분히 좋고, 더 나아질 것입니다. 단 한 가지는 기억하세요: 코드를 작성한 것이 무엇이든, 누가 되었든, 그 코드는 여러분의 책임입니다. 개인 프로젝트라면 대충 해도 되지만, 그 결과로 전자 잠금장치가 작동하지 않아 집에 못 들어간다면 피해는 결국 자신에게 돌아옵니다. 직장에서라면, 품질과 보안에 대한 책임이 따릅니다. 겉보기에 멀쩡한 코드를 커밋했다가 동료들이 그 부담을 떠안게 될 수도 있습니다. 바이브 코딩을 게으름의 변명으로 삼지 마세요. 그것을 실험하고, 놀아보고, 제대로 활용하는 법을 배우세요. 그리고 계속 배우세요.

원문 : Vibing at Home

추천 강의

• 핸즈온 바이브 코딩: 프론트엔드