1년 전엔 개발자의 가치 가 무엇인지 굳이 따질 필요가 없었다. 지금은 PM 이 vibe coding 으로 데모 를 만들고, 디자이너가 Cursor 로 백엔드 를 짠다. 개발자라는 역할 자체가 재정의되고 있는 시점. 그게 어떤 모양일지 — 7년 차에서 본 회고.

TL;DR

누가 1 년 전 지금 1 년 후
PM 요구사항 정리 데모 직접 만듦 시스템 구상 + 데모
개발자 코드 작성 70% 코드 판단 70% 시스템 설계 70%
디자이너 Figma Figma + 작동 prototype UX 구조 결정
QA 테스트 케이스 작성 AI 가 케이스 생성 판단 기준 정의

역할의 이름 은 그대로지만 그 안의 일 이 달라진다. 누가 어떤 결정을 하는가 의 재편성.

1. 바이브 코딩이란 무엇인가

“vibe coding” — 2025 년 초 Andrej Karpathy 가 트윗에서 처음 쓴 말. 대충 무엇을 만들고 싶은지 자연어로 설명 하고 AI 가 코드를 채워주는 작업 방식. 키 포인트 :

  • 코드 자체를 안 본다 (또는 안 봐도 됨)
  • 결과물의 작동 만 보고 반복
  • 느낌으로 (vibe) 방향성 조정

극단적인 묘사 :

“화면에 빨간 버튼이 좀 더 오른쪽으로 가게 해주고, 그 옆에 *작은 검은 아이콘 두 개 넣어줘.*”

코딩이 대화 가 됐다. 손가락보다 입 으로 한다. 이게 PM 도 만들 수 있는 영역.

물론 진짜 시스템엔 한계가 있다. 동시성, 보안, 성능, 운영. 하지만 데모 / MVP / 작은 도구 차원은 놀랍게 잘 만들어진다. MVP 의 진입 장벽이 거의 사라졌다.

2. PM 이 코딩하기 시작했다

내가 본 변화 :

2022년 PM        : 요구사항 명세서 + 와이어프레임
2024년 PM        : Figma 으로 프로토타입
2025년 PM        : Cursor + Vercel 로 *작동하는* 데모
2026년 PM (지금) : "내가 만들었어요" — 작은 SaaS 1 인 운영

PM 이 시연 단계에서 직접 코드 가능 하면 :

  • 요구사항 → 데모 사이의 시간이 0 에 가까워짐
  • 개발자에게 *전달 하는 비용 감소
  • 틀린 가정 을 빨리 발견
  • 진짜로 필요한 기능 인지 본인이 써 보고 결정

이게 제품 사이클의 가속. 1년 전 1개월 걸린 기능이 1주일 만에 빛을 본다.

3. 개발자가 사라지는가 — 단답

아니, 그러나 지금까지의 개발자 는 사라진다.

for 문, CRUD, 단순 변환, boilerplate — 이런 코드를 손가락으로 쳤던 사람의 시장 가치는 2~3년 안에 0 에 가까워진다. AI 가 더 빠르고 더 안 틀린다.

남는 개발자의 일 은 :

  1. 판단 — 이 코드가 우리 시스템에 맞는가 결정
  2. 설계 — 없는 것을 새로 만드는 구조
  3. 디버깅 — 돌긴 도는데 뭔가 이상한 문제 추적
  4. 시스템 — 분산 / 운영 / 보안 / 성능 의 전 레이어

이 4 개는 AI 가 못 하는 게 아니라 맥락이 너무 깊어서 AI 가 지금은 못 한다. 언젠가 도 할 수 있을 것이다. 하지만 그 언젠가 가 5년 뒤 이면 지금 이 4 개에 베팅 하는 게 합리적.

4. 누가 판단을 하는가 — 핵심 질문

vibe coding 시대의 진짜 변화 는 누가 어떤 결정을 하는가 의 문제.

작년의 개발자 :

(PM 의 요구사항을 받고) “이건 이렇게 짜고, 저건 저렇게 짤게요.”

지금의 개발자 :

(PM 의 데모를 보고) “이 데모로는 동시성 문제 가 생길 거예요. 이렇게 다시 짭시다.”

판단의 무게중심이 옮겨갔다. 코드 자체 가 아니라 *코드의 *맥락. 돌아가는가 가 아니라 *돌아가는데 그게 *맞는가.

이게 개발자의 새 정체성 의 핵심.

5. 코드의 “맞다” 와 “돈다” 사이

내가 지난 주 본 코드 :

# AI 가 생성한 가격 계산
def calculate_total(items, discount):
    return sum(item.price for item in items) * (1 - discount)

돈다. 테스트도 통과한다. 맞나?

  • 할인이 100% 면 0 원. 맞나? 공짜는 회계상 다른 처리 필요.
  • 세금 은? 우리 도메인에서 세전 합산 후 세금 추가 가 맞을 텐데.
  • 통화 단위 는? 원 단위 반올림 안 했다.
  • 재고 부족 가격은 0 인 경우가 있다.
  • 이 함수가 동시 호출 되면? 가격 변동 race condition.

돌긴 도는데 우리 시스템에 맞지 않는다. 이걸 알아채는 사람 이 개발자의 새 정의.

PM 이 vibe coding 으로 만든 데모도 대부분 이 영역 에서 결함. 돌긴 돈다. 맞지 않을 뿐. 그 차이를 보는 눈 이 7년 경험 의 진짜 가치.

6. PM 의 새 부담

PM 이 코딩할 수 있게 되면 책임 도 따라온다. 작년까지의 PM :

“기획만 하면 개발자가 만들어주니까 기능 자체에 집중.”

지금의 PM :

“내가 만들 수 있으니까 데모 만들었는데, 이게 production 에 갈 수 있나?”

PM 이 vibe coding 으로 만든 코드는 대개 production-ready 가 아니다. 그걸 production 으로 옮길지 / 다시 짤지 / 버릴지 판단해야 한다. 이 판단은 기존엔 개발자의 영역. 이제 PM 도 한쪽 발 을 담가야 한다.

PM 에게 새로 필요한 능력 :

  • 자기가 만든 코드의 수명 판단
  • production 으로 갈 수 있는 조건 이해
  • 개발자에게 언제 인계 할지 결정
  • 데모용 / 학습용 / 진짜 의 구분

이 능력이 없는 PM 은 데모를 production 으로 밀어버리는 사고를 친다. 기술 부채의 산업 규모 양산. 이미 일어나고 있다.

7. 개발자의 새 가치 — 4 가지

다시 정리. 개발자가 살아남는 이유 4 가지 :

7.1. 판단력 — 무엇이 좋은 코드인가

AI 는 돌아가는 코드 를 잘 만든다. 좋은 코드 는 맥락 의존 이라 못 만든다. 그 판단을 하는 사람이 필요.

7.2. 설계 능력 — 시스템의 구조

새로 만드는 시스템의 전체 구조 는 AI 가 못 짠다. 너무 많은 trade-off 가 우리 비즈니스 맥락 에 의존.

7.3. 디버깅 — 돌긴 도는데 이상한

가장 AI 에 안 잡히는 영역. 증상 → 원인 → 해결 의 문제 정의 자체 가 사람의 일.

7.4. 시스템 운영 — 분산 / 보안 / 성능

프로덕션의 결정적 순간 에 누가 그 새벽에 onCall 인가. AI 는 부르지 못한다.

이 4 가지는 7년 차의 일 이지 1년 차의 일 이 아니다. 그래서 1~3년 차의 시장이 가장 흔들린다. 보일러플레이트 영역이 그들의 일이었으니.

8. 내 7년 차의 일 의 실제 변화

3년 전 일과 :

코드 작성       : 50%
회의            : 20%
리뷰            : 15%
디버깅          : 10%
운영 / 알람 대응 : 5%

지금 일과 :

코드 작성       : 20%   ← 줄었다
코드 *판단*     : 30%   ← 새 영역
설계 / 회의     : 20%
리뷰            : 10%
디버깅          : 10%
운영            : 10%

총 50% → 70% 의 일이 코드 그 자체 보다 코드의 *맥락**. 그게 *개발자의 무게중심 의 이동.

내가 손가락으로 친 코드 의 양은 줄었지만 시스템을 만든 양 은 늘었다. 이게 AI 시대 개발자의 모양.

9. 그래서 나는 무엇을 해야 하나

세 종류의 사람에게 다른 권장 :

9.1. PM 또는 비개발 직군

  • vibe coding 을 익혀라. 1~2주면 충분하다.
  • 단 production / demo 의 차이 를 알아라. 그게 기술 책임 의 출발점.
  • 자기가 만든 데모를 개발자에게 인계할 시점 을 판단 할 줄 알아야 한다.

9.2. 주니어 개발자 (1~3 년차)

  • 보일러플레이트 만으로는 안 된다. 그건 AI 가 더 잘한다.
  • 판단 / 디버깅 / 시스템 운영 영역에 의식적으로 시간 을 쓰라.
  • 완성된 코드를 비판적으로 리뷰 하는 훈련. AI 가 짠 코드를 *왜 별로인지 말할 수 있어야* 한다.

9.3. 시니어 개발자 (5 년+)

  • 기존 가치는 그대로 또는 더 커진다. 단 AI 와 *함께 일하는 법* 을 익혀야 한다.
  • AI 가 짠 코드를 검토 / 판단 하는 게 주된 일 의 일부가 된다.
  • 후배 가르치는 법 이 바뀐다. for 문 가르치는 게 아니라 코드의 *맥락을 보는 눈 가르치기*.

10. 마치며 — 사라지는 건 *역할 이름 일 뿐*

                  (1990 ~ 2024)
PM        →  요구사항
개발자    →  코드 작성
디자이너  →  화면
QA        →  테스트

                  (2025 ~ )
*문제를 정의하는 사람*  →  *AI 도구 + 판단력*  →  *시스템*

오른쪽의 역할 분류 가 흐릿해진다. PM 이 코드를 짜고 개발자가 기획을 한다. 그래도 누군가는 문제를 정의 해야 하고, 결정 해야 하고, 책임 져야 한다. 그 일을 누가 할지 가 회사마다 다를 뿐.

내가 보는 진짜 변화 는 :

“무엇을 할 수 있는가” 가 아니라 *“무엇을 *해야 하는지” 가 가치의 중심이 됐다.*

할 수 있는 것 은 AI 가 다 해준다. 해야 하는 것 을 판단 하는 게 사람의 일.

PM 이든 개발자이든 디자이너이든 — 판단력 을 키우는 게 이 시대의 본질적인 학습. 그래서 시스템 사고 / 비즈니스 이해 / 사용자 공감 / 도메인 지식 이 코딩보다 가치가 커진다.

이 글은 본인 7년 차의 회고. AI 가 더 발전하면 본 글의 권장도 다시 바뀔 것이다. 지금 시점에서 합리적으로 보이는 방향일 뿐. 5년 뒤 본인이 이 글을 다시 보면 반은 맞고 반은 틀렸다 라고 할 거. 그게 변화의 속도.