Claude Code로 시작하는 바이브 코딩

개요

지난 1년간 Github Copilot을 사용하면서 느낀점을 소개하자면 "(제안된 코드를 이해하고 자신의 스타일로 활용할 수 있다면) 쓰면 좋다" 라고 축약할 수 있겠다. 그러나, 이 평가는 아주 부분적인 것이다. 다른 이들은 어떨지 모르겠지만 나는 Ghost Text로 제안되는 코드를 활용하거나 가 데이터를 생성할 때 잘 활용하였다. 또한, 가끔 Chat 기능을 통한 프로젝트 전체에 대한 구조 설정을 몇 번 해본것이 전부다.

성능 개선에 대한 문제를 해결하기 위해 몇 번 유의미한 결과를 LLM 모델을 통해서 해결한 적이 있었고 나머지 경우에서는 그렇게 크게 도움이 되었다고는 느끼지 못하였다. 물론 이것은 너무 익숙해져서 그렇게 느끼는 걸 수도 있겠다.

넷상에 Vibe Coding의 멋짐과 Vibe Debugging의 고통스러움을 비교하는 자조적인 농담의 밈을 보고서 "역시 그럼 그렇지"라면서 안도섞인 조롱을 하는 사람도 있고 "그런 사소한 오류가 뭐 대수냐? 끝내준다"라며 더 적극적으로 적용하는 사람들도 있었다. 이 두 온도차에 대한 의문과 내가 잘 활용하지 못하고 있는 것은 아닐까? 하는 불안으로 이어졌다.

A to Z를 손수 핸들링하는 구세대적 프로그래밍에 익숙한 내 시선으로는 항간에 떠도는 "바이브 코딩" 이라는 것이 매우 생소하기도 하고 추상적이다. Github Copilot을 활용하여 작업을 진행하고 있지만 그 바이브 코딩이라는 단어가 가지는 쿨함과 세련됨을 느낀적이 그렇게 많지 않기 때문이기도 했다.

Copilot, ChatGPT, SunoAI, Stable Diffusion, FLUX 등 여지껏 사용해본 LLM 모델의 출력결과들을 생각해보면 "그래도 좀..." 이라는 생각이 우선적으로 든다. 내가 이제 개발자로서는 뒷방 늙은이가 되어서 일까? 유행이 된지도 상당 기간이 흘렀지만 여전히 나는 AI에게 전권을 이양하고 무수한 랜덤박스를 통해 내가 막타를 치겠다는 발상이 서비스와 연결하기가 쉽지 않다.

이러한 이유들로 내가 정말로 바이브 코딩을 잘 활용하고 있는가? 에 대해서 되짚어보고 그 한계점이 어디까지 도달했는지, 앞으로는 어떨지를 가늠해보고자 이 포스트를 작성하기로 하였다.

바이브 코딩

사전적 의미는 코딩할 때 AI 모델을 사용해서 문제를 해결하는 방법론을 의미하는데 ChatGPT를 통해 답을 얻어 작업을 개선하거나 Copilot을 활용한 작업도 이 범주에 포함된다.

Github Copilot

Copilot Ghost Text 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

IDE 환경에 통합되어 작업자가 막힘없이 작업을 진행할 수 있도록 보조한다. 작업자는 제안된 출력결과를 사용하여 작업의 속도와 퀄리티를 향상한다. 이러한 일련의 작업이 모두 키보드 단축키를 통해 진행되거나 자동으로 진행된다. 바이브 코딩의 가장 이상적인 형태라고 볼 수는 없지만¹ 말 그대로 AI와 공명_바이브하며 막힘없이 작업을 진행할 수 있다.

Copilot Chat 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

Ghost Text뿐만 아니라 ChatGPT처럼 채팅할 수 있는 프롬프트 인터페이스도 제공하며, 프로젝트 내에서 필요한 파일들을 등록하여 Copilot이 능동적으로 코드를 수정하게 하여 수정내역을 검토하고 응용할 수 있다. 코파일럿 채팅의 경우 GPT 모델과 Claude 모델등을 선택하여 사용할 수 있다.

Claude Code

Copilot을 사용하면서 프로젝트 전체에 대한 구조나 설정과 같은 작업들을 맡기기에는 배보다 배꼽이 더 큰 경우가 많았기도 하고 몇 번 시도해본 이후로는 아무래도 손이 가지 않았다. 최근 클로드 모델이 이쪽으로 평가가 좋다는 이야기가 많아 마침 Copilot의 구독만료 기간과 겹쳐서 다른 모델을 사용해볼 수 있는 좋은 기회였다.

Claude Price 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

ChatGPT를 사용할 때에는 OpenAI API를 활용해서 내가 쓴 만큼만 결제하는 방식을 취하고 있었는데 이 경우 코드를 대상으로 하여 토큰이 얼마나 사용될지 감이 없기도 하고 한 달정도만 체험하는 느낌으로 사용할 계획이라 $20에 pro 버전으로 결제하였다.

설치

# Claude Code 설치
npm install -g @anthropic-ai/claude-code

# 프로젝트로 이동
cd your-awesome-project

# Claude와 함께 코딩 시작
claude

VSCode Claude Code 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

설치 가이드를 따라 npm 모듈을 설치하고 VSCode용 확장프로그램을 설치하면 사용준비는 완료이다.

사용법

Claude Code Test Project 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

요즘 많이 소개되는 형태로 사용해보기로 했다. 빈 프로젝트를 만들고 VSCode를 열어 PROGRAM.md 파일을 만들었다. md 파일을 열면 우측 상단에 Claude Code 버튼이 나타난다.

Claude Code 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

버튼을 클릭하면 별도의 탭에서 Claude Code 확장프로그램이 실행되는데 계정 로그인을 진행하면 몇 가지 설정 후에 프롬프트가 준비된다. 설정은 주의사항과 클로드가 파일을 분석하고 출력하기위한 현재 프로젝트 디렉토리에 대한 권한요청 등이다.

Claude Code Test Project Markdown 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

프롬프트가 입력준비를 마쳤으니 어떤 프로그램을 구성할지 간단한 설명을 MD 파일에 작성했다.

Claude Code Test Project Prompt 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

Claude Code Running 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

작성 후에는 "PROGRAM.md" 파일에 설명대로 프로그램을 작성하라고 프롬프트를 입력하였다. 클로드가 바로 작업을 시작하는데 생각보다 오랜 시간이 걸렸다. 물론, 1분내 완료이기 때문에 인간에 비해서 월등한 효율이지만 기대와는 조금 달랐다.

Claude Code Complete Message 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

Claude Code First Output 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

그 이유는 완료까지 사용되는 토큰이 생각보다 많기도 했고_{7k 이상} 첫 출력은 오류를 포함하고 있었다. 브라우저 오류를 다시 프롬프트로 전달하여 내용을 수정하고 난 후에야 정상적인 결과물을 볼 수 있었지만 세간의 평가와는 조금 괴리가 있는 듯 느껴졌다. 만약 사용자 인터렉션이나 조금 복잡한 프로젝트의 경우라면 여러 번 수정 작업을 반복해야 할 것이다.

Claude Code Repaired Output 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

그럼에도 클로드가 인기를 누리는 이유는 프로그램에 대해 아무것도 모르는 사람들도 일상의 언어로 원하는 결과물을 만들 수 있다는 점 때문일 것이다. 여기서 진행한 테스트는 아주 간단한 형식이지만 유튜브에 공개된 영상들 중에는 복잡한 작업도 뛰어난 작품으로 만들어내는 다양한 팁들이 많다.

진입장벽이 없어졌다고 봐도 될 정도이다. 윈도우즈 프로그래밍에 대해서 일자무식인 나도 비쥬얼 어쩌구 같은 기초학습은 무시하고 영상을 따라 "~해줘" 반복 작업을 통해 결과를 낼 수 있다는 말과 같다. 끝내주진 않아도 문제를 해결할 수 있는 간단한 프로그램 정도는 만들 수 있을 것이고 조금만 더 공부하거나 더 좋은 모델을 사용하면 당연히 결과물의 퀄리티도 올라갈 것이다.

또한, 여기서 소개하는 IDE의 활용만을 두고 평가하기에는 불공평하다. Claude에서는 많은 종류의 플러그인_커넥터을 제공하며, MCP를 활용하면 Figma로 디자인된 페이지를 빠르게 퍼블리싱 할 수도 있는 등 다양한 방면으로의 활용방법이 존재한다. LLM은 한정된 곳에 사용할 때보다 부족한 다방면을 채울 수 있다는 것이 더 큰 장점이다.

생각해볼만한 점

자신이 주요 고객층인지 명확히 할 것

어느정도 프로그래밍에 이해가 있는 사람은 코드에 대한 책임과 예상되는 오류들로 인해 사용하기가 꺼려질 수 있다. 그렇다면 누가 주 고객층이 될까? 좋을 수록 비싼 것은 당연하지만 AI 서비스들은 개인로써 사용하기엔 부담스러운 가격을 책정하고 있다.

왜 일까? 정말 최선두의 최신기술이라 비싼걸까? 실상을 까보면 그렇게 끝내주진 않는데도 말이다. 내 생각에는 주요 타겟층이 아니기 때문에 그렇게 느끼는 것 같다. 이전에도 이야기 했었지만 비용을 투자하고 결과물을 내야하는 고용주나 관리직의 입장에서 항목을 정리해보면 더 명확해진다.

완벽하진 않지만 출력결과가 어느정도 퀄리티를 만족한다.
어차피 사람이 작성해도 오류는 발생하며 AI의 환각현상도 피차 다를거 없다.
그렇다면 굳이 그 돈으로 사람을 써야 할까?

Github Copilot의 경우 누가봐도 주요 고객층이 프로그래머다. 다른 AI 서비스에 비해 절반정도 저렴한 가격인걸 생각해보면 컴쟁이들의 성향은 대게 비슷한 것 같다.

활용하려는 분야를 명확히 할 것

아무리 최고의 모델이라고 하더라도 현 시점에서 환각현상은 여전히 존재하고 만들어진 출력물을 수정하는 것은 더 까다롭다. 점점 더 정밀하고 잘 알아듣지만 그 한계는 다들 마음속으로는 느끼고 있을 것이다.

전체 서비스를 맡기기에는 부족하지만 나의 작업을 보조하는 것은 정말 더할 나위 없이 최고의 경험을 할 수 있다. 보조작업뿐만 아니라 간단한 연산 프로그램이나 사이트 정도는 기가막히게 뽑아내기 때문에 그 한계를 잘 가늠하고 활용처를 잘 선정하는 것 또한 사용자에게 주어진 숙제이기도 하다.

결과물에 대한 검증

위에서 소개한 "Copilot Chat" 사진을 자세히 보면 알 수 있듯이 LLM모델이 제시하는 결과는 언제나 검증을 필요로 한다. 기존의 tailwindcss 코드를 3버전에서 4버전으로 마이그레이션 하면서 진행한 결과였는데 헥스로 지정된 컬러를 hsl 컬러로 변환하는 과정을 담은 사진이다.

Color from google 저작자: luasenvy
이 저작물은 "CC BY 4.0 국제규약" 라이선스로 배포되었습니다.

값을 확인하기 위해 구글 검색을 진행해보면 위 같은 결과화면을 볼 수 있다. Copilot이 제시한 값이 전혀 다른 값이라는 걸 확인할 수 있다. rgb는 맞췄다만 안타깝게도 hsl는 다른 값이 나왔다.

css의 값을 변환하는 방법이나 왜 저런 값이 나오는지는 모른다. 하지만 출력결과에 대해서 검증하고 사용해도 되는지 결정하는 것은 언제나 사용자의 몫으로 남아있다.

고용주 입장에서의 비용

직원_노동자으로써의 삶을 계획하고 있다면 돈을 주는 고용주의 입장을 고려해야할 필요가 있다. 개발자 신입을 고용하여 그럴듯한 결과물을 얻어내기위해 적어도 3년은 투자하여 성장시키고 제품 개발을 진행해서 5년째에나 볼까말까 한 것이 현실이다. 대한민국 기준 초봉이 3천이라고 한다면 연봉동결로만 꾸역꾸역 진행해도_{2년차에 도망가겠지...} 1.5억이다.

조금 큰 프로젝트라면 이러한 사람이 여러 명 필요하고 분야별로도 필요하다. 정말 할 수 있는지 없는지도 시간이 지나야 알 수 있으며 5년간의 물가상승과 연봉협상, 그리고 중간에 다른 회사로 도망가거나 예기치 못한 상황 등을 모두 고려해야만 한다.

이런 난관을 뚫고 서비스가 성공적으로 런칭 되고난 이후는 또 어떤가? 모두들 성공을 꿈꾸기 때문에 대박이 터졌다고 가정해보자. 열심히 제품을 만들 때는 몰랐지만 계좌에서 돈이 빠져나가는 걸 보고 있노라면 저것들이 앉아서 돈을 빨아먹기만 하는 것 같지 않겠는가? 유지보수나 고객응대도 LLM으로 될 것만 같고 노동법과는 다르게 구독 취소만하면 그만이다. 짱구를 어떻게 굴려봐도 LLM을 활용하는 쪽이 압도적으로 비용효율적이고 리스크도 적다.

개발자라는 직종이 필요없다거나 일자리를 빼앗길 것이라는 이야기는 안해도 될 것 같다. 솔직히 발전속도를 보고 있자면 머지 않은 것 처럼 느껴지기도 하지만 걱정되지 않는 이유는 어차피 소프트웨어 개발도 결국 사람이 하는 일이기 때문이다.

아직은 사람이 하는 일

300원짜리 껌을 씹어도 안에서 돌이 나오면 고객센터로 전화부터 걸고 안 받으면 뉴스에 보내는게 사람이다. 수천만원에서 수억원대의 소프트웨어라면 고객의 입장에서 오류가 납득이 가겠는가?

더 좋고 무료인 GNU/Linux를 두고 업체가 보증하는 Redhat을 쓰는 이유가 다 있다. 현실세계에서는 결국 사람이 결정하고 일이 터지면 누군가 수습하고 책임을 져야하기 때문이다. 고객의 원성에 LLM이 그래쪄요 뿌우 하고 끝낼 수는 없다는 이야기다.

그래서 나는 정말로 LLM이 인류의 노동력을 대체하려면 자타공인 인류보다 뛰어난 AI여야만이 납득 할 수 있다고 생각한다. 그 누구도 책임을 지지 않을 수 있을 때 말이다. _{우리보다 뛰어나다면 킹쩔 수 없지...}

이런 꿈 같은 이야기들을 차치해도 문제는 많다. 비약적 발전으로 소수의 인력을 구성되어도 기획/설계/개발/테스트/운영/유지보수 라는 피할 수 없는 개발 사이클과 그 안에 있는 구현, 문서화, 고객응대, 이슈트래킹, 정기점검, 추가사업제안, 기타 등등 관련된 업무를 진행하기 위해서는 어찌되었든 사람이 필요하다. 그리고 필연적으로 저렇게 많은 일을 하는 유니콘 인력이라면 차라리 자기 회사 차리는게 낫다고 생각하지 않을까?

이런 것들로 불안감이 든다면

이유가 어쨌든 역사의 흐름은 LLM을 배제할 수 없는 수순을 지나고 있다. 전문성 있는 극소수의 인력은 여전히 필수적이지만 그럼 나머지는 시장에서 버려질 것인가? 이 생각은 어디까지나 LLM 기술이 몇 번의 기술적 돌파_{break through}를 이뤄내고 꽃을 피워 인류의 지성을 평균적으로 뛰어넘었을 때, 출력결과에 대해서 그 어떤 책임도 지지않고 그 누구도 논리적으로 반론 할 수 없을 때의 이야기라고 생각한다.

바이브 코딩이라는 개념이 개개인의 프로그래밍 방식을 구글링에서 프롬프팅으로 바꾼 것은 명백하다. 그러나 개인적으로는 개발인력시장이 크게 영향을 받았다는 느낌은 들지 않는다. 오히려 물가, 부동산 시장, 연봉책정, 사용하는 운영체제, 사용 언어 같은 것들이 더 큰 장벽이다. 당장 가장 중요한 프로젝트는 이미 돈 받고 팔려나간 프로젝트이고 인력을 필요로 하는 곳은 대부분 실무에 즉각 투입될 수 있는 능력이 요구되기 때문이다.

그렇기 때문에 정도_正道가 왕도 라고 말하고 싶은 이 사견은 조금씩 줄어드는 입구의 크기를 깨닫지 못하는 나의 편협한 관점에서 비롯하겠지만 아직까지는 입구의 위치까지 바뀌었다고는 생각하지 않는다. 4차 산업 혁명이니 IoT니 지능형 유비쿼터스 친환경 기가테라 인공지능 하이퍼 삐슝빠슝 어쩌구니해도 여전히 우리는 물리적 스위치를 눌러서 기계를 작동시키고 안 될때는 껐다 키는게 빠른 현실에서 살고 있지 않은가?

항상 새롭고 더 좋은 것을 갈구하는 인간의 특성에 따른 것인지 모르겠지만 이 "바이브 코딩"이라는 단어도 마케팅 언어 중 하나일 가능성이 크다. 교육사업도 새로운 강좌를 내어야 사람들이 몰리고 사람들이 몰려야 돈이 모이는 법이니까. 더 빠르게 퍼지는 정보와 마치 온 세상이 그런 것 같은 분위기에 나만 뒤쳐지는 듯한 불안감이 들 수 있겠지만 한 번쯤은 차분히 깊게 생각해보자.

그러나 시대는 바뀌게 되어있다

이 글을 통해 회의적인 생각을 강화할지 모르겠으나 시대는 바뀌게 되어있다는 것을 절대 잊어서는 안된다. TV가 안 나오면 후드려까던 옛날 습관처럼 여전히 LCD 모니터를 두들겨팬다면 있다면 분노조절장애 진단을 받게 될 것이다.

인공지능에 대해 눈길도 주지 않던 사람들이 알파고와 이세돌의 경기를 통해 충격받았던 것 처럼 기술은 반드시 발전하게 되어 있다. 매일매일 조금씩 우리가 모르는 곳에서 발전을 거듭하고 매스컴을 통해 소식을 접하게 되면 이미 늦었다는 신호이다. 불과 20년전만해도 지금 우리가 생각하는 스마트폰_{iPhone이 2007년에 나왔다}이 대중화 되지 않았다는 것을 명심하자. 기술의 발전 속도는 이전과는 비교할 수 없고 지금도 가속하고 있다.

당장은 LLM에 대한 맹목적인 믿음을 경계해야 하겠지만 거부감이 들더라도 결코 외면하지 않고 자신만의 활용법을 만들어 나가는 것이 지혜로워 보인다. 하다못해 서비스를 사용해보고 감이라도 익혀두는 것이 분명 도움이 될 것이다.

더불어 가장 중요한 것은 자신의 분야에 기본을 갈고 닦는 것이다. LLM의 결과물을 통해 무언가를 해보겠다는 것은 생각보다 더 험난한 길일 수 있다. 탄탄한 기초를 통해 LLM의 그럴듯한 개소리_환각현상를 멋진 시로 완성하는 능력이 우선되어야 하겠다.

바이브 코딩이 LLM의 도움을 받아 작업하는 것이기 때문에 ChatGPT 앱을 켜서 일상의 언어로 질문을 하는 것 처럼 가장 이상적인 형태는 사람의 육성으로 프로그램이 작성되는 모습일 것이다. ↩