필요해서 Make IT/바이브 코딩

바이브 코딩 경험담 및 커서&클라인 사용 후기

잌쿠 2025. 5. 27. 23:14

반복적인 자동화 작업을 하다 보면, ‘이걸 조금 더 똑똑하게 처리할 수 없을까?’ 하는 생각이 자주 들죠. 저 역시 그런 고민 끝에, 바이브 코딩(Vibe Coding) 이라는 새로운 접근에 도전하게 되었습니다. 전문적인 개발 지식이 없어도, 아이디어와 흐름만 잘 정리하면 시작할 수 있다는 확신이 들었고, 그렇게 하나하나 만들어가기 시작했죠.
이 글은 그 여정에서 제가 겪은 시행착오와 소소한 발견들, 그리고 도구와 AI를 활용한 저만의 ‘게으른 자동화’ 방식에 대한 이야기입니다. 비슷한 고민을 가진 분들께 작게나마 도움이 되길 바라며, 경험을 공유해봅니다.

 

바이브 코딩을 시작하게 된 배경

IT관리자라는 직업의 숙명 중 하나는, 수많은 기기를 "똑같이" 세팅해야 한다는 점입니다. 한두 대면 뭐... 손으로 하나하나 해도 괜찮지만, 열 대, 스무 대, 심지어 전국 단위로 돌아다니며 설치를 하게 되면 얘기가 달라지죠.

2022년 말, 회사의 키오스크 프로젝트에 투입되면서 본격적인 실전이 시작됐습니다. 전국 방방곡곡을 돌며 설치를 하다 보니, 기기마다 환경이 들쑥날쑥해선 곤란하더라고요. 처음엔 아는 만큼만 배치 파일을 만들어 설정했지만, 점점 윈도우의 미묘한 커스터마이징까지 손을 대야 하는 상황이 생기면서 PowerShell 스크립트에 눈을 돌리게 됐죠.

야간 공사로 밤에는 키오스크 설치를 낮에는 숙소에서 스크립트 다듬기. 그렇게 한 달쯤 지나자 어느덧 반쯤 자동화가 되기 시작했고, 마침 그 무렵 ChatGPT 베타가 공개되면서 본격적으로 AI의 도움도 받기 시작했습니다. 구글, 스택오버플로우, 그리고 이제는 ChatGPT. IT담당자의 밤은 그렇게 깊어갔습니다.

그 후로는 이것저것 만들어보기 시작했어요. 예를 들면:

지금 보면 다소 조잡하고 실험적인 툴들이긴 하지만, 필요한 걸 직접 만들면서 배우는 재미는 꽤 쏠쏠합니다.

주로 Cursor를 유료 구독해서 사용 중인데, 요즘 유튜브 보니 Cline도 핫하더라고요. 그래서 이것저것 테스트해보고 있습니다. 역시 도구는, 직접 써봐야 진짜 알 수 있는 법이죠.

Cursor 개발환경
VS Code + Cline의 개발환경

 

비개발자의 바이브 코딩 경험담

“AI야, 이거 좀 고쳐줘”

— 프롬프트로 시작한 나의 반(半)자동 개발 일기

프로그래밍을 하면서 가장 애를 먹는 건, 아이러니하게도 '코드' 자체가 아니었습니다. 어떤 문제를 풀어야 할지, 어떤 툴을 써야 할지, 심지어 어떤 구조로 짜야 할지까지는 대강 감이 오는데 — 막상 AI에게 그걸 말로 설명하려고 하면 머릿속이 하얘지더군요.

처음엔 단순했죠. “이거 코드로 짜줘.”, “이 함수 리팩토링 해줘.”,
그런데 AI는 때때로 엉뚱한 방향으로 날아가버리고, 내가 무엇을 원하는지 도통 모르는 눈치였습니다. 마치 잘못된 매뉴얼을 읽은 알바생이, 열심히 엉뚱한 테이블에 음식만 놓고 있는 것처럼요.

그래서 프롬프트를 쓰는 일은 점점 복잡해졌고, 단순히 **“이거 해줘”**가 아니라, “이건 이러이러한 조건이 있고, 이건 절대 건드리면 안 되고, 결과는 이 형식으로 나와야 해. 그리고 중복되는 로직은 공통함수로 빼줘” 같은, 꽤 긴 설계 문서처럼 변해버렸습니다.

 

하지만, 여기서 재미있는 지점이 하나 생깁니다.
처음엔 불편하고 비효율적이라 느꼈던 이 ‘설명하는 과정’이, 나중엔 내 사고를 정리해주는 일종의 **‘개발 명상’**처럼 느껴지더라는 거죠. 마치 내가 나 자신에게 "넌 지금 뭘 만들고 싶은 거야?"라고 되묻는 느낌이랄까요.

 

코드를 만들다 보면 반복적인 수정을 거치며 점점 복잡도가 높아지고, 나중엔 처음 뭘 하려고 했는지도 기억이 안 나 버릴 때가 있습니다. 그래서 저는 Cursor의 Restore 기능을 자주 활용하곤 하는데요, 이 기능이 정말 목숨줄 같은 존재더군요.

하지만 완벽한 해결책은 아닙니다. 파일 단위로만 복구되다 보니, 이전에 생긴 파일이 그대로 남거나, 수정 전 상태로 완벽하게 돌아가기 어려운 경우가 많습니다. 그럴 땐 “차라리 Git으로 커밋할 걸...” 하는 후회가 밀려오죠.
그래서 요즘엔 아예 프롬프트를 입력하기 전, Git에 커밋부터 남겨놓고 시작하는 습관을 들였습니다.

한 줄이라도 저장해놓으면 마음이 조금은 든든하더라고요.

 

그런데 말입니다. 개발환경이 복잡해질수록 내 컴퓨터는 서서히 괴물이 되어갑니다. 
파이썬 모듈을 이것저것 설치하다 보면, 충돌은 일상이 되고, 환경은 지저분해지고, 언젠가는 “이 컴퓨터 왜 이렇게 느려졌지...” 하며 머리를 감싸 쥐게 되죠.

그럴 때 가장 좋은 방법은 Docker를 써라 입니다. 처음엔 어렵고 귀찮지만, 한 번 익히면 그 어떤 문제보다 강력한 예방주사입니다.
모든 실험은 Docker 안에서. 내 PC는 깨끗하게. 이건 마치 찌개는 냄비에, 찌든 때는 닦지 말고 새 냄비를 쓰는 법을 배운 것과 비슷합니다.

 

이렇게 AI를 도구 삼아 개발을 하다 보니, 분명 새로운 세상이 열리긴 했습니다.
속도는 빨라졌고, 반복 작업에서 해방됐고, 단순한 오류 수정도 예전처럼 머리 싸맬 일은 줄었습니다.

하지만…
게을러졌습니다. 진심입니다.

이젠 코드가 에러 나도, 그냥 붙여넣고 “이거 왜 안 돼?” 하고 던지면 AI가 뭔가 해석해줍니다.
쇼츠에서 손가락 까딱하는 것처럼 “~해줘”를 연발하게 되는 자신을 볼 수 있습니다.
에러가 나면, 복붙후. "검토해", 예외처리? 복붙후 "이거이거 예외처리해", 
결과만 나면 그만. “아 됐어, 이제 잘 되네.”

문제는 그 순간, 내가 ‘왜 이게 돌아가는지’를 모를 수도 있다는 것이 영 찜찜하기도 합니다.

 

이런 습관이 무서운 건, 스스로 생각하는 능력이 줄어든다는 점입니다. AI가 나보다 똑똑한 건 맞지만, AI가 나 대신 ‘이유’를 기억해주진 않거든요. 그래서 진지하게 개발하고 싶을 땐, 다시 마음을 고쳐먹습니다. 프롬프트도 정성껏, 조목조목 써 내려가며 내가 진짜 원하는 걸 스스로 되새기는 거죠.

그리고 이 과정에서 느낍니다. "아, 내가 개발을 배우고 있구나."

 

또 한 가지 흥미로운 점이 있습니다. AI 에이전트에게 지시할 때, 칭찬이나 감정 섞인 말보다도 단호하고 정확한 지시가 훨씬 잘 먹힌다는 겁니다. 말 그대로 ‘노예처럼 부리기’가 더 효과적이랄까요.

“이거 좀 해줄래?”보단 “이렇게, 이 순서로, 이 조건에 맞게 해.” 이게 훨씬 더 열심히 한다라는 느낌이 들더라구요.(기분탓일 수도 있습니다.)

심지어 “Gemini가 만든 코드보다 못하네” 같은 비교도, 결과물을 달라지게 만든다고 합니다. 물론 AI에게 감정은 없지만, 패턴엔 예민하니까요.

이제는 “칭찬은 고래도 춤추게 한다”가 아니라 **“칭찬은 인공지능도 춤추게 한다”**가 맞는지도 모르겠습니다.

 

AI와 함께하는 개발은 결국 ‘도구’의 문제가 아니라 ‘사고방식’의 문제라는 걸 요즘 들어 자주 느낍니다.
내가 얼마나 구체적으로, 얼마나 논리적으로, 그리고 얼마나 겸손하게 이 도구를 다루느냐가 중요하다는 이야기겠지요.

그러니 지금도 저는 또 다른 프롬프트를 다듬고 있습니다.
에러와 씨름하며, "이건 왜 이러지?"를 외치면서도, 여전히 이 AI라는 동료에게 뭔가를 기대하며 말이죠.

“AI야, 이거 좀 고쳐줘.” 이 말이, 나의 다음 프로젝트를 여는 열쇠가 될지도 모르니까요.

 

 

커서(Cursor)와 클라인(Cline) 비교

커서와 클라인은 모두 바이브 코딩에 유용한 도구이지만, 접근 방식에서 차이가 있다고 합니다.
커서는 Ask/Agent 모드를, 클라인은 Plan/Action 방식을 채택하고 있습니다. 언뜻 비슷해 보이지만, 실제로는 명확한 차이가 있고
작업 효율성에 영향을 명확히 주는 것 같아 보입니다. 아직은 좀더 써봐야 하겠고 인공지능 모델별로 차이가 있겠지만, 개인적으로는 클라인이 더 효과적으로 코딩하고 있는 것과 같은 느낌이 확실히 들었습니다.

그 이유를 곰곰히 생각해보니 UX 적으로 요구하는 프롬프트에 대해 plan 으로 계획을 사용자에게 설명하고 act 버튼을 누르면 실행하는 구조이기 때문인것 같습니다.

아래 표는 커서와 클라인의 주요 차이점을 정리 해 봤습니다. 참고해주세요.

커서(Cursor)와 클라인(Cline)은 모두 ‘바이브 코딩’을 가능하게 해주는 유용한 도구입니다. 하지만 접근 방식에는 확실한 차이가 있고, 이 차이는 실제 작업 효율성에도 영향을 주는 것 같습니다.

커서는 Ask/Agent 구조를 따릅니다. 사용자가 질문이나 명령을 하면, AI가 그에 맞는 응답이나 작업을 즉각 수행하는 형태죠. 반면, 클라인은 Plan/Action 방식으로 접근합니다. 프롬프트에 대한 응답을 곧바로 실행하지 않고, 먼저 ‘계획’을 보여준 뒤, 사용자가 Act 버튼을 눌러야 실행됩니다. 언뜻 보면 비슷한 것 같지만, 이 미묘한 차이가 실제로는 꽤 다르게 다가옵니다.

개인적으로는 클라인 쪽이 더 '효과적으로 코딩하고 있다'는 느낌이 강하게 들었습니다. 이유를 곰곰이 생각해보니, 클라인의 UX가 계획(Plan) 단계를 통해 결과물을 사전에 검토하게 만들고, 그 다음에야 실행(Act)하도록 유도하는 구조이기 때문인 것 같습니다.

‘일단 만들어주는’ 방식이 아니라, ‘이렇게 만들려고 하는데 괜찮아?’ 하고 물어보는 도구라는 점에서, 마치 페어 프로그래밍을 하는 느낌이 들더군요.

아래는 커서와 클라인의 주요 차이점을 간단히 정리한 표입니다. 참고해보시면 도움이 될 것 같습니다.

구분 Cursor Klein (Cline)
유형 VS Code 기반 독립 에디터(포크) VS Code 확장(Open Source)
라이선스/비용 유료(월 $20, 요청 제한 있음) 무료(오픈소스), LLM API 비용 별도
주요 특징 내장 벡터 DB 통한 코드베이스 검색, Agent 모드, 자동 에러 처리, 다중 파일 편집, 자동 커밋 메시지 생성 Plan-Action 방식, 투명한 계획 제시, LLM 유연 통합, 내부 시스템 연동, 오픈소스, 커스텀 가능
AI 모델 지원 Claude, GPT-4 등(내장) 다양한 LLM(Claude, Quent 등) 자유롭게 연동
대형 코드베이스 매우 효율적(100k+ 토큰) 대형 코드베이스에서 상대적으로 비효율적
작업 흐름 질의/에이전트 기반, 자동화된 다단계 작업 계획 수립 → 사용자 승인 후 실행(투명성 강조)
사용자 경험 일관성 높고 통합적, 빠른 구현, 자동화 강점 사용자 제어권 높음, 계획 확인 및 승인, 유연성
오류 처리 자동 에러 복구 및 핸들링 우수 오류 루프에 빠질 수 있음, 수동 개입 필요
확장성/통합 제한적(폐쇄형) 오픈소스, 자체 시스템 연동 및 커스텀 용이
적합한 환경 대규모 프로젝트, 빠른 구현, 통합 환경 선호 소규모/중규모 프로젝트, 오픈소스, 투명성, LLM 커스텀 필요시
단점 요청 제한, 일관성 변동, 비용, 폐쇄적 대형 코드베이스 비효율, 오류 처리 한계, 세팅 복잡
추천 사용자 프로 개발자, 대규모 팀, 통합 솔루션 선호자 예산 중시, 오픈소스 선호, 내부 시스템 연동 필요시

 

마치며

비전공자이다 보니 아이디어는 넘치지만, 실행력은 조금 게으른 편이라 아직은 뚜렷하게 전문적인 무언가를 완성하진 못했습니다. 그래도 하고 싶은 걸 직접 만들며 하나하나 배우고 있는 중입니다. 결국, 즐기는 사람을 이길 수는 없다고 하잖아요. 그래서 저는 오늘도 천천히, 그러나 꾸준히 이 여정을 이어가고 있습니다. 앞으로도 경험을 차곡차곡 정리해서 공유할 계획이고요. 저의 이런 기록들이, 바이브 코딩에 관심 있는 분들에게 작은 참고나 동기부여가 되었으면 좋겠습니다. ov