AI가 코드를 짜는 시대, 개발자는 무엇을 해야 할까?

지금, 코딩을 직접 하지 않고도 프로덕트를 만들 수 있는 시대가 왔습니다.Cursor와 GPT가 코드를 대신 짜주고, 클릭 몇 번으로 앱이 완성됩니다.하지만, 이 변화 속에서 개발자의 역할은 어떻게 바뀔까요?

이 글은 Cursor 시리즈의 첫번째 글입니다.

이런 분들에게 이 글을 추천합니다

지금은 바야흐로 바이브코딩의 시대

바이브코딩 정의

요즘 IT 업계에서 핫한 개념 중 하나가 바로 ‘Vibe Coding’입니다.바이브코딩이란 AI 모델과의 대화형 상호작용을 통해,코드의 세부 구조나 작성 방식에 집착하지 않고 그저 ‘느낌대로(Vibe)’ 개발을 진행하는 방식을 의미합니다.

해당 개념은 AI 연구자이자 전 테슬라 AI 총괄이었던 Andrej Karpathy의 트윗에서 널리 알려졌습니다.그는 최근 자신이 개발할 때 거의 키보드를 사용하지 않고, SuperWhisper를 통해 말로 명령하고 Cursor Composer에 그대로 전달해 앱을 만든다고 이야기했습니다. 예를 들어 “사이드바 패딩을 반으로 줄여줘”처럼 구체적이지 않은 요구도 AI가 충분히 알아듣고 처리해준다는 겁니다.

Karpathy는 이렇게 말합니다.“이젠 코드를 거의 읽지도 않고, diff도 확인하지 않은 채 ‘Accept All’을 누릅니다.에러가 나면 그냥 에러 메시지를 복붙해서 AI에게 해결하게 합니다. 대부분은 잘 됩니다.”

즉, 코딩 자체보다 의도를 표현하는 방식이 더 중요해졌다는 이야기 입니다.더 이상 코드를 직접 ‘작성’하지 않고, 보고 → 말하고 → 실행하고 → 복사/붙여넣기 하는 사이클을 반복하는 식으로 일할 수 있게 되었습니다.물론 일회성 사이드 프로젝트나 프로토타이핑에 더 적합하며, 실무에선 위 방식대로 코딩한 결과물을 적용하기엔 한계가 있습니다.그렇지만 그만큼 코딩이라는 행위의 본질이 빠르게 바뀌고 있다는 신호탄이기도 하죠.

결국 Vibe Coding은 “코딩을 직접 하지 않아도 코딩이 되는 시대”, “아이디어를 바로 구현하는 흐름” 을 뜻합니다.GPT, Cursor, Copilot, SuperWhisper 같은 도구들이 발전하면서, 개발 경험 자체가 GUI화되고, 점점 더 텍스트 중심의 설계 인터페이스로 진화하고 있는 것입니다

바이브코딩의 실제 사례

잘 와닿지 않는 분들을 위해, 이러한 바이브코딩 방식으로 유명한 실제 사례를 하나 소개해드리겠습니다.유명 인디 해커인 피터 레벨스는 바이브코딩 도구인 Cursor만으로 웹 기반 비행 시뮬레이션 게임을 단 3시간 만에 개발했습니다.놀라운 건 이 게임이 단순 프로토타입 수준임에도 불구하고, 출시 17일 만에 약 1억 2천만 원을 벌어들였다는 점입니다.

피터는 이 모든 과정을 X(트위터)에서 매일 공유하며 화제를 이끌었고,일론 머스크의 리트윗까지 받아 글로벌 관심을 끌어올렸습니다.

바이브코딩의 장점과 한계

지금까지는 “코드를 내가 짜야 한다”는 것이 당연했지만, 이제는 “말하거나 프롬프트를 입력하면, AI가 짜준다”는 방식으로 패러다임이 빠르게 바뀌고 있습니다. 특히 Cursor, Copilot, chatGPT 등 LLM을 활용한 코딩이 늘며, 개발자들이 AI가 작성한 코드를 적극 활용하는 사례가 늘어나고 있습니다.

이건 단순한 트렌드가 아닙니다.

새롭게 적응해야 할 변화이며, 앞으로의 개발 패러다임을 크게 바꿀 것입니다.

그럼 이 새로운 코딩 방식이 실무에 어떤 의미를 줄까요?

소프트웨어 개발의 구루이신 마틴 파울러님의 의견을 가져왔습니다.AI 도구가 초안을 생성하는 데 유용하지만, 그 초안에는 오류가 포함될 수 있으므로 인간의 검토가 필수적이라고 강조합니다.이처럼 AI가 생성한 코드를 적극적으로 활용하되, 이는 어디까지나 초안이기 때문에, 개발자가 적극적으로 리뷰하고 개선하는 과정이 필요합니다.

바이브코딩 장점

생산성의 폭발적 향상

바이브코딩의 가장 큰 장점은 말할 것도 없이 속도입니다.예전 같으면 1~2시간 걸릴 로그인 API를, 이제는 단 몇 분 만에 완성할 수 있습니다.

“Spring Boot에서 로그인 API 만들어줘. JWT 기반으로 하고, 이메일 인증 포함시켜줘.”1분 이내에, 실제 작동 가능한 코드가 생성됩니다.

게다가 반복 작업이나 보일러플레이트 코드를 자동으로 생성해주기 때문에,개발자는 더 이상 ‘반복되는 일’에 시간을 쓰지 않아도 됩니다.

프로그래밍 러닝 커브 단축: 코드 베이스 없이도 개발 흐름 체험 가능

이제는 초보자도 아이디어만 있으면 직접 개발을 시도할 수 있는 시대입니다.

GPT, Cursor, Claude 같은 도구를 활용하면 코딩을 ‘배우기 전’에도 결과물 중심의 접근이 가능해집니다.심지어 예전에는 어려웠던 설정 파일 구성, 패키지 구조 설계, 테스트 코드 작성도 이제는 AI가 자동으로 만들어주기 때문에,학습자 입장에서는 빠르게 성취감을 얻으며 개발을 즐길 수 있는 환경이 됩니다.

실험과 창작의 문턱을 낮춘다

이제는 마음속에 떠오른 아이디어를 “해볼까?”라는 가벼운 마음으로 실현할 수 있습니다.피터 레벨스(Pieter Levels)의 바이브코딩 사례가 대표적입니다.

그는 Cursor를 활용해 단 3시간 만에 비행 시뮬레이터 게임을 만들어냈고,이를 기반으로 1억 원 이상의 수익을 올리는 데 성공했습니다.

이 과정에서 사용된 기술은 WebGL, Three.js, PeerJS, WebSocket 등 전문적인 스택이었지만,그가 직접 모든 코드를 짰던 것은 아닙니다. 대부분의 코드와 구조 설계는 GPT와 Cursor의 도움을 받아 구현된 것이죠.

즉, 이제는 실험이 쉬워졌고, 시행착오의 비용이 획기적으로 줄어든 시대입니다.

페어 프로그래머로서 AI

AI는 더 이상 단순한 자동완성 도구가 아닙니다.GPT, Copilot, Claude는 "생각 파트너"에 가까운 존재가 되고 있습니다.

이런 질문을 던졌을 때, AI는 꽤 성실하게 리뷰어이자 멘토처럼 반응합니다.특히 설계 방향이나 테스트 전략을 묻는다면, 생각보다 수준 높은 인사이트를 제공해줄 수 있습니다.즉, 바이브코딩은 혼자 일해도 팀처럼 일할 수 있는 구조를 가능하게 합니다.

바이브코딩 단점

도메인 맥락 고려 부족: '무엇'을 만들지보다 '왜' 만드는지를 이해하지 못함

AI는 코드만 봅니다.그 코드가 어떤 비즈니스 목적을 가지는지, 어떤 사용자 흐름을 고려해야 하는지 도메인 맥락은 알지 못합니다.

“상품 검토 시작 시 문자 메시지를 보내는 이벤트를 추가해줘.”

AI는 문자만 보내줍니다. 하지만 이 메시지가

AI에게 코딩을 위임하려면, 이러한 맥락을 풍부하게 작성해서 프롬프트로 전달해야 합니다.결국 맥락 전달은 사람의 영역입니다. 설계와 정책을 세우는 능력 없이는 바이브코딩이 오히려 엉뚱한 코드를 양산하는 도구가 될 수 있습니다.

무지성 코딩의 위험: 코드만 맞고 구조는 틀리다

바이브코딩의 속도에 취하면, 종종 “일단 만들어보고 보자” 식의 개발에 빠지게 됩니다.그러나 코드가 돌아간다고 해서 그 구조가 옳은 것은 아닙니다.

예를 들어, AI가 작성해준 코드가 한 메서드에 수십 줄의 로직이 몰려 있고, 서비스 레이어가 컨트롤러와 리포지토리,외부 API 호출을 모두 떠안고 있을 수 있습니다.이런 구조는

AI는 "결과"는 잘 만드나, "구조와 규칙"은 사람이 설계해줘야 하는 이유입니다.설계 없이 빠르게만 만든 코드는 단기적으로는 편하지만 장기적으로는 비용을 키웁니다.

AI가 작성한 코드는 아무리 잘 프롬프트로 짰더라도, 개발자의 시야로 리팩토링이 필요합니다.이는 코드베이스를 건강하게 만드는 데, 도움을 줍니다.이러한 코드를 베이스로 Cursor와 같은 툴에서 더 좋은 코드를 생성할 수 있습니다.

정답을 맹신하는 태도

GPT나 Cursor가 보여주는 코드는 언뜻 보기에 완성도가 높고 자연스럽습니다.그러나 이 코드가 실제 서비스 환경에서 성능적으로, 보안적으로, 유지보수적으로 적절한지는 검증 없이 알 수 없습니다.혹시나 해당 로직에 대해 잘 모르는 사람이,

“AI가 짜줬으니까 맞겠지”라고 생각한다면, 이는 큰 착각입니다.

오히려 이 시점에서 중요한 건

라는 비판적 사고입니다.

취준생, 개발자들은 이 현상을 어떻게 바라봐야 할까?

이제 취업을 앞둔 개발자거나 저와 같은 개발자들은 이 현상을 어떻게 바라봐야 할까요?

문제정의를 더 횔씬 더 뾰족하게 하자.

이제 개발자의 역량은 문제를 얼마나 깊이 이해하고 정의하느냐에서 시작됩니다.무엇보다 중요한 건 “이 기능이 사용자에게 어떤 가치를 줄 수 있는가?”를 먼저 묻는 일입니다.

문제정의를 잘 하기 위해선, 다음 네 가지 질문이 선행 되어야 합니다.

이 과정을 거쳐야 정말 필요한 기능을 정의하고 서비스 정책을 수립할 수 있고,AI에게도 더 정확한 컨텍스트를 줄 수 있어 정교한 코드를 제안받을 수 있습니다.

가장 중요한 건, 단순히 구현을 시작하기 전에,“이 문제를 왜 해결해야 하는가?” 에 충분히 답하고 시작하는 것입니다.그게 바로 설계자의 사고 방식이고,AI와 함께 일할 수 있는 개발자의 핵심 역량이라고 생각합니다.

학습의 도구로 삼자.

GPT나 Copilot이 추천해주는 코드를 무턱대고 붙여넣는 건 학습에 전혀 도움이 되지 않습니다.이해되지 않는 코드를 프로젝트에, 그대로 붙여 넣어선 안됩니다.그 대신, 이렇게 질문해보세요.

“이 코드가 왜 좋은가요?”“이 방식 대신 다른 패턴은 어떤 게 있나요?”“이 로직의 단점은 없나요?”

AI는 이런 비판적 질문에 더 정교한 답변을 해줍니다.이 과정을 반복하다 보면, 단순한 코드 사용자에서 구조적 이해를 갖춘 설계자로 성장할 수 있습니다.즉, GPT를 나의 선생님으로 활용하는 습관이 필요합니다.

또한 프로젝트로 실력을 올려봅시다.지금은 그 어느 때보다 Learn by Project가 쉬운 시대가 됐습니다.개발 진입 장벽이 현저히 낮아진 시대입니다. AI는 언제든 “페어 프로그래머”가 되어주죠.무엇이든 만들어봅시다.

GPT 하나로 거의 모든 걸 만들어볼 수 있는 시대입니다.그리고 만드는 것에서 그치지 않고, 잘 만들어봅시다.지금은 바로 그 차이를 고민해야 하는 시점입니다.

무지성 코딩을 주의하자.

바이브코딩은 쉬워보이지만, 문제는 설계 없는 구현입니다.좋은 소프트웨어를 만드는 기준 없이 무턱대고 코딩만 하다간,동작은 할 수 있을진 모르지만, 유지보수하기 어려운 코드가 됩니다.

특히 서비스 레이어에서 “어떻게 분리하고 연결할 것인가”는 여전히 사람의 몫이죠.다행히도 Cursor 같은 도구는 구조적 설계를 도와주는 기능이 잘 되어 있습니다.Cursor에 대해서도 시리즈로 자세하게 설명해봤으니, 확인해보세요!

이런 도구를 쓸수록, 더 정돈된 맥락을 가진 AI 코드 제안을 받을 수 있습니다.결국, 도구는 설계자에게 유리한 무기입니다.

설계 공부를 하자.

AI의 출현으로 코딩의 장벽은 낮아졌지만, 설계의 중요성은 오히려 더 커졌습니다.

“어떤 기능을 만들 것인가”보다,“어떻게 나눠서, 어떻게 연결할 것인가”를 더 잘 고민해야 합니다.

OOP, DDD, SOLID 같은 설계 원칙 등을 공부해두면,AI에게도 더 나은 프롬프트를 쓸 수 있고더 유지보수 가능한 구조를 제안받을 수 있습니다.

뿐만 아니라, MSA, 시스템 설계와 같은 아키텍처 설계 역량까지,갖춘다면 더 복잡한 문제를 해결 하는 실마리를 쉽게 얻을 수 있으며,처음부터 올바르게 문제를 정의하여 해결 할 수 있습니다.

요컨대, AI는 설계자의 말을 잘 듣습니다.그러나 우리가 설계 언어를 모르면, AI는 제 역할을 다 못합니다.

맺으며

이제 진짜 중요한 질문은 이것입니다.

“코딩은 AI가 해주는데, 나는 무엇을 더 잘해야 할까?”

이제 우리는 선택해야 합니다.바이브코딩을 그저 빠른 도구로만 쓸지,아니면 설계자-문제해결자로 성장하기 위한 학습의 무대로 삼을지.당신은 문제 해결의 도구로 사용하고 있나요? 아니면 그저 의존하고 있나요?오늘 프로젝트에서, 단 한 줄이라도 “왜”라고 묻고 나서 코드부터 짜보세요.그게 바로 설계자의 시작점입니다.

레퍼런스

https://martinfowler.com/bliki/RefinementCodeReview.htmlhttps://martinfowler.com/articles/exploring-gen-ai.htmlhttps://www.youtube.com/watch?v=86-Dy5U2p5Y&ab_channel=GOTOConferenceshttps://www.youtube.com/watch?v=lurbDAEU0KM&ab_channel=Refactoring