AI 바이브 코딩, 잘하는 사람은 Cursor를 이렇게 씁니다

요즘 개발자들 사이에서 AI 바이브 코딩이라는 말, 정말 자주 들리죠. 저도 처음엔 살짝 웃었어요. 아니, 코딩에 바이브가 어딨어… 그냥 요구사항 보고 코드 치는 거지, 뭐 이런 느낌이었거든요. 그런데 Cursor를 실무에 조금씩 넣어보고, 어느 순간부터는 생각이 좀 바뀌었습니다.

뭐랄까, 예전에는 혼자 조용히 삽질하면서 로그 찍고, 검색하고, Stack Overflow 뒤지고, 문서 읽고 그랬잖아요. 지금은 옆자리에 꽤 눈치 빠른 시니어 개발자 하나 앉혀놓고 일하는 느낌이 있어요. “이 부분은 이렇게 나누는 게 낫지 않아?”, “여기 타입이 좀 불안한데?”, “이 로직 테스트 케이스 하나 더 있어야 할 것 같은데?” 하고 계속 옆에서 툭툭 건드려주는 느낌이랄까요.

근데 또 막상 써보면 현실은 그렇게 낭만적이지만은 않습니다. 토큰은 생각보다 빨리 녹고요. 프롬프트를 대충 던지면 AI가 아주 자신감 있게 엉뚱한 코드를 만들어냅니다. 심지어 가끔은 그럴듯해서 더 위험해요. “어? 맞는 말 같은데?” 하고 넣었다가 빌드 깨지고, 테스트 터지고, 퇴근 시간 멀어지고… 네, 저도 다 겪었습니다.

그래서 오늘은 제가 Cursor를 실무에서 꽤 오래 만지작거리면서 느낀 AI 바이브 코딩을 효율적으로 하는 방법을 편하게 풀어보려고 해요. 거창한 이론 말고요. 진짜 개발자가 일하면서 써먹을 수 있는 방식들. 토큰 아끼는 법, 프롬프트를 덜 헤매게 쓰는 법, Cursor 설정에서 바꿔두면 좋은 것들까지요.

AI 바이브 코딩에서 진짜 중요한 건 토큰 관리예요

솔직히 말하면, 처음 AI 코딩 도구를 쓰는 분들은 대부분 “프롬프트를 얼마나 멋지게 쓰느냐”에 관심을 많이 둡니다. 물론 중요해요. 그런데 실무에서 오래 써보면 조금 다르게 보입니다. 저는 토큰 관리가 꽤 큰 실력이라고 봐요.

토큰은 그냥 비용 문제가 아닙니다. AI가 한 번에 이해할 수 있는 맥락의 크기이기도 하고, 응답 품질에도 영향을 줍니다. 너무 많은 걸 한 번에 던지면 AI가 오히려 중요한 부분을 놓쳐요. 사람도 그렇잖아요. 회의실에 앉혀놓고 “우리 회사 전체 시스템 구조랑 장애 원인, 개선 방향까지 지금 바로 말해봐” 하면 누구라도 버벅입니다.

저도 예전에 레거시 코드를 리팩토링할 일이 있었는데, 그때 정말 무식하게 접근했어요. 파일 하나를 통째로 복사해서 Cursor 채팅창에 붙여넣고 “이거 리팩토링해줘”라고 했거든요. 결과는요? 토큰은 토큰대로 많이 쓰고, AI는 제가 진짜 고치고 싶었던 부분이 아니라 주변부 코드만 예쁘게 만지더라고요. 그날 이후로 저는 전체 파일 던지는 습관을 거의 버렸습니다.

큰 덩어리보다 작은 단위로 던지는 게 훨씬 좋아요

제가 요즘 가장 많이 쓰는 방식은 스니펫 단위로 질문하기입니다. 함수 하나, 클래스 하나, 특정 조건문 블록 하나만 딱 선택해서 물어보는 거예요.

예를 들면 이런 식이죠.

• “이 함수에서 예외 처리가 빠질 만한 부분만 봐줘.”
• “이 조건문이 너무 복잡한데, 가독성 좋게 나눌 수 있을까?”
• “이 로직에서 성능상 문제가 될 부분이 있는지 확인해줘.”
• “이 코드의 동작은 유지하고 TypeScript 타입 안정성만 높여줘.”

이렇게 범위를 좁혀서 물어보면 Cursor도 훨씬 집중을 잘합니다. 괜히 프로젝트 전체를 통째로 읽히려고 하지 말고, 지금 내가 해결하고 싶은 문제의 범위를 잘라서 보여주는 게 좋아요. 이게 별거 아닌 것 같아도 토큰 사용량이 확 줄고, 답변 품질도 꽤 차이 납니다.

@Codebase는 막 쓰는 게 아니라 좁혀서 써야 합니다

Cursor의 @Codebase 기능은 정말 편합니다. 프로젝트 전체 맥락을 참고해서 답을 해주니까요. 그런데 이 기능도 막 쓰면 토큰 먹는 하마가 됩니다. “@Codebase 이 프로젝트 설명해줘” 이런 식으로 던지면 답변은 장황한데 정작 쓸모 있는 내용은 별로 없는 경우가 많아요.

저는 보통 이렇게 씁니다.

• “@Codebase auth 관련 API 호출 흐름만 찾아서 설명해줘.”
• “@Codebase UserService가 호출되는 위치를 중심으로 정리해줘.”
• “@Codebase 결제 실패 시 처리되는 코드 경로만 추적해줘.”
• “@Codebase 이 에러 메시지가 발생할 수 있는 파일을 찾아줘.”

핵심은 “전체를 봐줘”가 아니라 “전체 중에서 이 부분만 찾아줘”입니다. 생각해보면 검색도 그렇잖아요. 검색어를 잘 넣어야 원하는 결과가 나오지, 그냥 “개발” 이렇게 치면 너무 많은 게 나와서 오히려 피곤합니다.

채팅보다 Ctrl+K 인라인 에디팅을 더 자주 씁니다

Cursor를 쓰다 보면 채팅창이 편해서 계속 거기에 물어보게 되는데요. 실무에서는 인라인 에디팅(Ctrl+K)이 훨씬 효율적인 경우가 많습니다.

채팅은 대화가 길어질수록 이전 맥락이 계속 쌓입니다. 그러면 토큰도 늘어나고, AI가 예전 대화까지 끌고 와서 이상한 방향으로 답할 때도 있어요. 반면 Ctrl+K는 내가 선택한 코드 블록에 집중해서 수정 요청을 할 수 있으니까 훨씬 가볍습니다.

저는 요즘 코드 수정 작업의 대부분을 Ctrl+K로 처리합니다. 예를 들어 함수 하나 선택해놓고 “early return 방식으로 가독성 좋게 바꿔줘”라고 하거나, “중복된 조건식을 변수로 빼줘”라고 하는 식이죠. 채팅은 구조 설계나 방향성을 물어볼 때 쓰고, 실제 코드 수정은 인라인으로 하는 편이 제일 편했습니다.

프롬프트는 멋있게 쓰는 게 아니라 정확하게 쓰는 겁니다

프롬프트 얘기를 하면 괜히 거창해 보이는데, 저는 그렇게 어렵게 생각하지 않습니다. 그냥 옆자리 동료에게 일을 부탁한다고 생각하면 돼요. 동료에게도 “로그인 만들어줘”라고만 하면 곤란하잖아요. 어떤 기술 스택인지, 화면은 어떤 식인지, 인증 방식은 뭔지, 에러는 어떻게 보여줄지 알려줘야 제대로 만들 수 있습니다.

AI도 똑같습니다. 프롬프트 엔지니어링이라는 말이 조금 있어 보이긴 하지만, 결국은 “내가 원하는 결과를 오해 없이 설명하는 기술”에 가깝습니다.

맥락과 제약 조건을 같이 줘야 결과물이 좋아져요

나쁜 프롬프트는 보통 너무 짧고 막연합니다.

• “로그인 기능 만들어줘.”
• “이거 고쳐줘.”
• “리팩토링해줘.”
• “버그 찾아줘.”

이런 요청을 받으면 AI는 자기 마음대로 빈칸을 채웁니다. 문제는 그 빈칸이 우리 프로젝트 기준과 다를 수 있다는 거죠. 그래서 저는 최소한 맥락(Context)과 제약 조건(Constraint)은 같이 줍니다.

예를 들면 이렇게요.

“이 프로젝트는 React 18과 TypeScript를 사용하고 있어. 로그인 폼은 이메일과 비밀번호만 받고, 유효성 검사는 react-hook-form으로 처리해줘. 인증은 JWT 기반이고, API 호출은 이미 만들어진 axios 인스턴스만 사용해야 해. 에러 메시지는 한국어로 보여주고, UI 라이브러리는 추가하지 말아줘.”

이 정도만 적어도 결과물이 확 달라집니다. 특히 “하지 말아야 할 것”을 적어주는 게 은근히 중요해요. AI는 친절해서 뭘 자꾸 추가하려고 하거든요. 패키지 설치하고, 구조 바꾸고, 유틸 만들고… 고맙긴 한데 실무에서는 그런 친절이 오히려 부담이 될 때가 많습니다.

“원하는 결과물의 형태”를 말해주면 훨씬 덜 헤맵니다

AI에게 질문할 때 저는 결과물 형태도 자주 지정합니다. 예를 들어 설명이 필요한 경우에는 “표로 정리하지 말고 코드 흐름 중심으로 설명해줘”라고 하고, 코드 리뷰를 받고 싶을 때는 “심각도 높은 문제부터 짚어줘”라고 합니다.

이런 식이죠.

• “수정 코드만 주지 말고, 왜 그렇게 바꿨는지도 짧게 설명해줘.”
• “전체 파일을 다시 쓰지 말고 변경된 부분만 보여줘.”
• “가능하면 기존 함수명과 파일 구조는 유지해줘.”
• “리팩토링 방향을 2가지로 나눠서 장단점을 비교해줘.”
• “테스트 코드까지 같이 제안해줘.”

이게 귀찮아 보여도, 한 번 습관 들이면 오히려 시간이 줄어듭니다. AI가 처음부터 내가 원하는 모양에 가깝게 답을 주니까 다시 물어보는 횟수가 줄어들거든요.

한 번에 끝내려고 하지 말고 단계로 쪼개보세요

제가 실무에서 정말 자주 쓰는 방식이 멀티스텝 프롬프팅입니다. 한 번에 “이 버그 고쳐줘”라고 하지 않고, AI에게 먼저 관찰하게 하고, 그다음 판단하게 하고, 그다음 수정하게 하는 방식이에요.

예를 들면 이런 흐름입니다.

• “이 코드에서 버그가 생길 가능성이 있는 지점을 찾아줘. 아직 수정하지 말고 원인만 설명해줘.”
• “방금 찾은 문제 중 실제 운영 장애로 이어질 가능성이 높은 순서대로 정리해줘.”
• “가장 위험한 문제부터 기존 구조를 크게 바꾸지 않는 방식으로 수정 코드를 제안해줘.”
• “수정 후 깨질 수 있는 테스트 케이스를 예상해줘.”

이렇게 나누면 AI가 훨씬 차분하게 답합니다. 사람도 마찬가지예요. “문제 찾아서 고치고 검증까지 해줘”라고 한 번에 던지는 것보다, “일단 어디가 문제인지 같이 보자”라고 시작하면 대화가 더 안정적으로 흘러가잖아요.

.cursorrules 파일은 초반에 꼭 만들어두는 게 좋습니다

Cursor를 쓰면서 꽤 큰 차이를 만든 기능이 바로 .cursorrules 파일입니다. 이건 프로젝트 루트에 만들어두는 일종의 규칙 파일인데요. Cursor에게 “우리 프로젝트에서는 이런 방식으로 코드를 작성해줘”라고 미리 알려주는 용도라고 보면 됩니다.

솔직히 이거 처음엔 저도 대충 넘겼습니다. “에이, 규칙 몇 줄 적는다고 얼마나 달라지겠어?” 싶었거든요. 그런데 팀 프로젝트에 적용해보니 생각보다 효과가 컸습니다. 매번 프롬프트에 같은 말을 반복하지 않아도 되고, AI가 제안하는 코드 스타일이 훨씬 일관돼졌어요.

.cursorrules에 넣어두면 좋은 내용들

프로젝트마다 다르겠지만, 저는 보통 이런 규칙을 넣습니다.

• 이 프로젝트는 TypeScript를 사용하며 any 타입 사용을 최대한 피한다.
• React 컴포넌트는 함수형 컴포넌트로 작성한다.
• 상태 관리는 기존 프로젝트에서 사용하는 패턴을 따른다.
• API 호출은 공통 axios 인스턴스를 통해 처리한다.
• 에러 처리는 try-catch를 사용하고, 사용자에게 노출되는 메시지는 한국어로 작성한다.
• 새로운 외부 라이브러리는 꼭 필요한 경우가 아니면 추가하지 않는다.
• 기존 파일 구조와 네이밍 컨벤션을 우선적으로 유지한다.
• 테스트 코드는 기존 테스트 스타일에 맞춰 작성한다.

이렇게 적어두면 매번 “우리 프로젝트는 이렇게 해”라고 설명할 필요가 줄어듭니다. 이게 생각보다 토큰 절약에도 도움이 되고요. 특히 팀에서 Cursor를 같이 쓴다면 더 좋습니다. 사람마다 프롬프트 습관이 다르더라도 기본 규칙이 있으니까 결과물이 너무 제각각으로 튀는 걸 막아주거든요.

규칙은 너무 길게 쓰지 않는 게 오히려 좋아요

한 가지 조심할 점도 있습니다. .cursorrules를 너무 길고 빡빡하게 쓰면 오히려 AI가 답답하게 움직입니다. 모든 상황을 규칙으로 묶으려고 하면 예외 상황에서 이상한 답을 할 때가 있거든요.

저는 보통 “반드시 지켜야 하는 팀 컨벤션”과 “자주 반복해서 말하게 되는 기준”만 넣습니다. 예를 들어 코드 스타일, API 호출 방식, 타입 처리 원칙, 테스트 작성 방식 정도요. 너무 세세한 업무 로직까지 넣으면 관리하기도 힘들고, 나중에 규칙이 낡았는데 아무도 안 고치는 일이 생깁니다. 그럼 AI가 예전 기준으로 코드를 제안하는 묘한 상황이 벌어져요.

Cursor 설정 몇 가지만 바꿔도 손맛이 달라집니다

많은 분들이 Cursor를 설치하고 거의 기본 설정 그대로 씁니다. 물론 그래도 충분히 쓸 만해요. 그런데 몇 가지 설정을 손봐두면 체감이 꽤 다릅니다. 이런 건 약간 개발 환경 세팅이랑 비슷해요. 처음엔 귀찮은데, 한번 맞춰두면 매일 조금씩 편해지는 그런 느낌입니다.

Tab 제안 수락은 신중하게 다루는 게 좋습니다

Cursor의 자동완성은 편하지만, 가끔 너무 적극적입니다. Tab 한 번 눌렀을 뿐인데 제안된 코드가 통째로 들어가고, 그게 또 얼핏 맞아 보여서 지나치기 쉽습니다. 저는 이 부분이 은근히 위험하다고 봐요.

그래서 Tab to Accept 관련 설정은 본인 스타일에 맞게 꼭 확인해보는 걸 추천합니다. 저는 전체 제안을 무조건 받아들이는 것보다, 가능한 경우 단어 단위나 작은 단위로 수용하는 쪽을 선호합니다. AI가 제안한 코드를 그대로 믿기보다는, 내가 운전대를 잡고 조금씩 받아들이는 느낌이 좋더라고요.

AI 코딩 도구를 쓸 때 제 철학은 단순합니다. “AI가 코드를 쓰게 하되, 결정은 내가 한다.” 이 선을 넘기 시작하면 편해지는 대신 위험해집니다.

Model은 상황에 따라 바꿔 쓰는 게 좋습니다

Cursor에서는 여러 Model을 선택해서 사용할 수 있죠. 여기서도 은근히 차이가 납니다. 모든 작업을 하나의 모델로 처리하려고 하면 속도나 품질 면에서 아쉬울 때가 있어요.

저는 보통 이렇게 나눠 씁니다.

• 간단한 코드 생성이나 리팩토링은 claude-3.5-sonnet 계열을 자주 사용합니다.
• 복잡한 디버깅이나 설계 방향 검토는 GPT-4o 같은 모델을 쓰는 편입니다.
• 빠른 자동완성이나 짧은 수정은 Cursor 자체 모델을 활용할 때도 많습니다.
• 테스트 케이스 아이디어를 뽑을 때는 설명을 잘해주는 모델을 고릅니다.

물론 이건 정답이라기보다 제 작업 스타일에 가까워요. 중요한 건 “이 모델이 좋다더라” 하고 하나만 고정해서 쓰는 게 아니라, 작업 성격에 맞춰 바꿔보는 겁니다. 몇 번만 비교해봐도 내 프로젝트에 잘 맞는 조합이 보입니다.

Codebase Answer는 켜두되 질문을 잘해야 합니다

Cursor: Toggle Codebase Answer 같은 기능은 프로젝트 전체 맥락을 볼 때 꽤 유용합니다. 현재 파일만 보는 게 아니라 코드베이스 전체를 참고해서 답을 해주니까요.

예를 들어 이런 질문을 할 때 좋습니다.

• “이 함수가 프로젝트 안에서 어디서 호출되는지 찾아줘.”
• “이 타입이 실제로 사용되는 파일들을 정리해줘.”
• “결제 실패 로그가 남는 흐름을 추적해줘.”
• “이 API 응답 값이 화면에 표시되기까지의 경로를 설명해줘.”

다만 이 기능도 질문이 흐리면 답이 흐려집니다. “이 프로젝트 구조 어때?”처럼 너무 넓게 물어보면 별로 도움 안 되는 답이 나올 수 있어요. “어떤 기준으로”, “어느 범위를”, “무엇을 중심으로” 볼지 같이 말해줘야 합니다.

VS Code 확장팩이랑 충돌나는 부분도 한 번은 봐야 합니다

Cursor는 VS Code 기반이라 익숙한 확장팩을 그대로 쓸 수 있다는 장점이 있습니다. 저도 GitLens, Prettier, ESLint 같은 확장팩은 거의 기본처럼 씁니다. 그런데 AI가 제안한 코드와 확장팩 설정이 가끔 충돌할 때가 있어요.

특히 자동 포맷팅 쪽이 그렇습니다. AI가 나름 의도를 가지고 코드를 정리했는데 저장하는 순간 Prettier나 ESLint 설정 때문에 형태가 확 바뀌는 경우가 있습니다. 대부분은 좋은 방향인데, 가끔은 변경 사항이 커져서 diff가 지저분해지기도 해요.

저는 개인적으로 Editor: Format On Save 설정을 프로젝트 상황에 따라 조절합니다. 어떤 프로젝트에서는 켜두고, 어떤 프로젝트에서는 꺼둡니다. 특히 AI가 큰 리팩토링을 하는 중이라면 저장할 때마다 자동 포맷이 들어가는 게 오히려 흐름을 방해할 때도 있더라고요.

AI가 만든 코드도 결국 리뷰해야 합니다

이건 정말 중요합니다. Cursor가 만들어준 코드라고 해서 그대로 믿으면 안 됩니다. AI는 문법적으로 그럴듯한 코드를 잘 만듭니다. 그런데 그 코드가 우리 서비스의 맥락에 맞는지, 운영 환경에서 안전한지, 장애 상황을 고려했는지는 사람이 봐야 합니다.

제가 실제로 한 번은 AI가 제안한 예외 처리 코드를 거의 그대로 넣었다가, 특정 API 에러에서 사용자에게 빈 메시지가 노출되는 일이 있었습니다. 큰 장애는 아니었지만, QA 단계에서 잡혀서 다행이었죠. 그 이후로 저는 AI가 만든 코드는 꼭 “정상 케이스, 실패 케이스, 빈 값 케이스” 정도는 눈으로라도 한 번 더 봅니다.

AI 바이브 코딩을 잘하려면 질문하는 습관이 바뀌어야 합니다

Cursor를 잘 쓰는 사람들을 보면 공통점이 있습니다. AI에게 일을 통째로 맡기지 않아요. 대신 자기 생각을 먼저 세우고, AI를 그 방향으로 움직입니다.

예전 개발 방식에서는 “내가 코드를 얼마나 빨리 치느냐”가 중요했다면, 이제는 조금 달라졌습니다. 문제를 어떻게 쪼개고, 어떤 순서로 AI에게 맡기고, 어디까지 검증할지 정하는 능력이 중요해졌어요. 이게 저는 AI 시대 개발자의 새로운 기본기라고 봅니다.

좋은 질문은 보통 이런 모양을 가집니다

• 현재 상황을 짧게 설명합니다.
• 사용 중인 기술 스택을 알려줍니다.
• 원하는 결과를 구체적으로 말합니다.
• 바꾸면 안 되는 조건을 알려줍니다.
• 출력 형식을 지정합니다.
• 필요하면 한 번에 끝내지 않고 단계로 나눕니다.

예를 들면 이런 프롬프트가 훨씬 낫습니다.

“이 코드는 Next.js와 TypeScript로 작성된 주문 상세 페이지야. 현재 주문 상태에 따라 버튼 노출 조건이 너무 복잡해졌어. 기존 동작은 유지하면서 조건문을 읽기 쉽게 정리해줘. 새 라이브러리는 추가하지 말고, 변경된 코드와 변경 이유를 같이 설명해줘.”

이 정도면 AI가 어디를 봐야 하는지, 뭘 조심해야 하는지, 어떤 결과를 줘야 하는지 알 수 있습니다. 사실 개발자끼리 일할 때도 이런 요청이 훨씬 좋잖아요. AI라고 다를 게 없습니다.

Cursor는 자동 코딩 도구가 아니라 협업 도구에 가깝습니다

저는 Cursor를 쓰면서 가장 크게 느낀 게 이겁니다. Cursor는 “개발자를 대체하는 도구”라기보다는 “개발자의 사고 속도를 올려주는 도구”에 가깝습니다. 물론 단순한 CRUD 코드나 반복 작업은 정말 빠르게 만들어줍니다. 그런데 중요한 설계 판단, 장애 대응, 도메인 이해, 사용자 경험 같은 건 여전히 사람이 중심을 잡아야 해요.

AI 바이브 코딩을 잘한다는 건, 그냥 AI에게 많이 시키는 게 아닙니다. 오히려 반대에 가까워요. AI에게 시킬 일과 내가 직접 판단할 일을 잘 나누는 것. 이게 진짜 실력입니다.

저는 요즘 개발할 때 이런 흐름을 자주 탑니다. 먼저 제가 문제를 대충 쪼갭니다. 그다음 Cursor에게 후보 코드를 만들게 합니다. 나온 코드를 보고 다시 방향을 잡습니다. 마음에 안 들면 “이 방식 말고 기존 구조를 더 유지하는 방향으로 다시 제안해줘”라고 합니다. 그러다 보면 어느 순간 혼자 했을 때보다 훨씬 빠르게 좋은 지점에 도착해요.

사실 이 과정이 꽤 재밌습니다. 예전엔 막힌 부분에서 혼자 오래 멈춰 있었는데, 이제는 AI랑 툭툭 주고받으면서 생각을 굴릴 수 있으니까요. 다만 운전대는 꼭 내가 잡고 있어야 합니다. 이건 좀 고집스럽게 지키는 편이에요.

실무에서 바로 써먹기 좋은 Cursor 사용 습관

말이 길어졌으니, 제가 실제로 자주 쓰는 습관들을 조금 더 현실적으로 적어볼게요. 거창한 팁은 아니지만, 이런 것들이 쌓이면 꽤 큰 차이를 만듭니다.

• 전체 파일을 던지기 전에 먼저 함수 단위로 잘라서 물어봅니다. 대부분의 문제는 전체 파일이 아니라 특정 로직 안에 있습니다.
• “수정하지 말고 먼저 분석해줘”라는 말을 자주 씁니다. AI가 성급하게 코드를 바꾸는 걸 막을 수 있습니다.
• 큰 리팩토링은 한 번에 맡기지 않습니다. 이름 정리, 함수 분리, 타입 개선, 테스트 추가처럼 단계별로 나눕니다.
• AI가 새 라이브러리를 추천하면 바로 설치하지 않습니다. 기존 코드로 해결 가능한지 먼저 물어봅니다.
• 프롬프트에 “기존 동작은 유지해줘”를 자주 넣습니다. 이 한 문장이 사고를 꽤 줄여줍니다.
• 응답이 이상하면 바로 고치라고 하지 말고, 왜 그렇게 판단했는지 먼저 묻습니다. 가끔 AI의 오해 지점을 찾을 수 있습니다.
• 테스트 관점으로 한 번 더 질문합니다. “이 변경에 대해 어떤 테스트가 필요할까?”라고 물으면 놓친 케이스가 나옵니다.

이런 습관은 처음엔 조금 번거롭게 느껴집니다. 그런데 익숙해지면 AI와 협업하는 리듬이 생겨요. 그때부터는 Cursor가 단순 자동완성 도구가 아니라, 꽤 쓸 만한 페어 프로그래밍 파트너처럼 느껴집니다.

AI 바이브 코딩, 결국 개발자의 지휘력이 중요합니다

AI 바이브 코딩이라는 말이 가볍게 들릴 수도 있지만, 저는 이 흐름이 꽤 오래 갈 거라고 봅니다. 이미 개발 방식이 바뀌고 있어요. 검색해서 답을 찾던 시대에서, AI와 대화하면서 답을 다듬는 시대로 넘어가는 중입니다.

그렇다고 AI가 다 해주는 건 아닙니다. 오히려 개발자의 역할이 더 선명해지는 느낌도 있어요. 요구사항을 해석하고, 문제를 쪼개고, 기술적인 선택을 하고, 결과물을 검증하는 능력. 이건 여전히 사람 몫입니다.

Cursor를 잘 쓰고 싶다면 너무 거창하게 시작하지 않아도 됩니다. 오늘 당장 작은 함수 하나를 선택해서 Ctrl+K로 개선해보세요. .cursorrules 파일에 프로젝트 규칙 몇 줄만 적어보세요. @Codebase로 전체를 묻지 말고 특정 흐름만 추적해보세요. 이런 작은 습관들이 쌓이면, 어느 순간 “아, 이래서 사람들이 AI 바이브 코딩 얘기를 하는구나” 하고 감이 옵니다.

솔직히 저도 아직 매일 배웁니다. 20년 넘게 개발을 해도 새로운 도구 앞에서는 또 초보가 되는 순간이 있거든요. 그래도 그게 나쁘진 않아요. 오히려 재밌습니다. 예전보다 더 빠르게 실험하고, 더 자주 검증하고, 더 가볍게 시도할 수 있으니까요.

다만 이 말은 꼭 하고 싶습니다. AI에게 끌려가지는 마세요. AI를 옆에 앉혀두고, 방향은 내가 잡는 겁니다. 그게 제가 생각하는 진짜 AI 바이브 코딩입니다.

🔍 관련 정보 더 보기