"AI 시대에 살아남는 핵심 역량은 코딩 실력 이 아니라 문제를 잘 정의하는 능력 이다." — 안상현 (커리어해커 알렉스), Meta 시니어 개발자

---

도입 — 누가 되어야 하는가 의 질문

4 장과 5 장이 어디에 서 있는가 의 질문이었다면, 6 장은 누가 되어야 하는가 의 질문이다.

3 장에서 본 4 단계 모델 의 알렉스 — 그가 30 년 현업에서 도달한 결론을 한 줄로 기록한다.

핵심 역량 = 코딩 실력 ❌ / 문제 정의 능력 ⭕

이 한 줄을 "여러분이 알고리즘 4 년 공부한 게 다 헛것이다" 로 읽으면 오해 다. 정확한 메시지는 — 알고리즘·OOP·DB 가 그대로 쓸모 있는데, 적용 위치 가 바뀐다. 6 장이 그 적용 위치 이동 을 그린다.

핵심 명제 미리.

코드는 AI 가 쓴다. 설계는 여러분이 한다.

---

두 사람의 같은 결론 — 수렴 증거

이 결론을 알렉스 한 명 만 말하는 게 아니다. 2 장에서 만난 4 인의 거인들 외에 또 한 사람이 동일 결론에 수렴 한다.

Aman Sanger — Cursor 공동 창업자. 그가 한 인터뷰에서 한 말.

"개발자는 코더 (coder) 에서 아키텍트 (architect) 로 옮겨가야 한다."

이건 알렉스의 발언 과 서로 모르는 사이에 같은 결론에 도달한 사례다. Meta 의 30 년 차 시니어 와 Cursor 의 공동창업자 — 서로 다른 회사, 서로 다른 위치 에서 같은 진단. 이런 수렴 이 일어나면 우연이 아니다.

이 책의 모든 장이 같은 패턴을 따른다 — 외부 권위 1 (알렉스) + 외부 권위 2 (Sanger) 가 같은 결론을 가리킨다 + 제품의 UX 가 그 결론을 강제 한다 (2 장의 3 도구). 이 세 갈래가 만나면 *권위 논리를 넘어 시대적 수렴 * 이 된다.

---

전통 개발 vs 바이브 코딩 — 5 축 비교

이 역할 전환 을 5 축 비교표 로 정리한다.

표의 5 축 모두에서 변화가 일어났지만, *진짜 변화는 3 축 (핵심 역량) + 5 축 (개발자 역할) * 에 있다. 다른 축은 *그 두 변화의 부산물 * 이다.

3 축 — 핵심 역량의 위치 이동 :

• 전통 — *문법·알고리즘 구현 * 능력. 즉 손의 능력.
• VBC — 문제 정의 + 맥락 설계 능력. 즉 머리의 능력.

5 축 — 역할의 호칭 변화 :

• 전통 — 코더. 코드를 쓰는 사람.
• VBC — 아키텍트 (또는 오케스트레이터). 시스템을 설계하고 AI 에게 일을 분배하는 사람.

이 호칭 변화 가 채용 공고에 그대로 기록되었다 (서문 참조). "엔지니어 5 년 경력" 이 "아키텍처 설계 / 에이전트 오케스트레이션 경험" 으로 바뀐 것 — 그 변화가 5 축의 결과다.

---

아키텍트 라는 단어의 부담 — 오케스트레이터 로도 부른다

"아키텍트" 라는 단어가 부담스럽게 들릴 수 있다. 건축 설계자처럼 멀고 거대한 사람 같은 인상.

이 책에서는 오케스트레이터 라는 보조 호칭을 함께 쓴다. 오케스트라 지휘자 처럼 — 여러 연주자 (= AI 에이전트들) 에게 정확한 지시를 주고 전체를 한 곡으로 만드는 사람.

여러분이 학기 프로젝트에서 팀장 역할 을 해 본 적이 있다면, 그 경험이 정확히 이 오케스트레이터 의 축소판이다. 다른 점은 — *연주자가 사람이 아니라 AI 에이전트들 * 이라는 것뿐.

같은 일을 대상만 바꿔서 하는 자리다. 그래서 "아키텍트가 되어야 한다" 는 말은 완전히 새로운 사람이 되라는 게 아니라 — 지금 여러분이 팀 프로젝트에서 하고 있는 일 을 AI 와 함께 더 큰 규모 로 한다 는 뜻이다.

---

주니어 vs 시니어 — 집중점의 이동

같은 메시지를 경력 단계 로 다시 본다.

주니어 (코더) 의 집중점:

• 코드 줄 (LOC)
• 문법 준수
• 버그 수정
• "이 함수가 맞게 작동하는가?"

시니어 (아키텍트) 의 집중점:

• 전체 시스템 구조
• 비즈니스 요구사항 (PRD) 정의
• 에이전트 간 상호작용 설계
• "이 시스템이 6 개월 뒤에도 굴러가는가?"

이 두 자리 사이의 거리는 4 ~ 5 년 의 시간이다. 정확히 *여러분이 졸업하고 입사 후 5 년 * 의 자리. 즉 *6 장의 메시지는 지금 당장 아키텍트가 되라는 게 아니라 — *그 자리를 지금부터 의식하라 * 는 것이다.

알렉스의 표현으로 "오케스트레이터로서 군림한다" — 이게 시니어 아키텍트 의 자리. 여러분이 입사 후 5 년 차에 도달할 자리 다. 그 자리에 체계적으로 도착하는 길 이 — 이 책 8 ~ 14 장에서 다루는 하네스 + 설계 언어 다.

---

시간 압축의 위력 — 2 일 / 1 주일 의 비밀

5 축 변화가 얼마나 강력한가 를 두 사례로 본다 (부록 A 에서 자세히).

여기서 반드시 함께 말해야 하는 한 줄 이 있다.

속도는 AI 가 담당. 방향과 품질 기준 은 아키텍트가 담당.

Crossbeam 2 일 도, Elisa 1 주일 도 — AI 가 다 해 준 게 아니다. *인간이 2 일 / 1 주일 안에 명확한 방향과 검증 기준을 명세로 박았기 때문에 * AI 가 그 안에서 빠르게 코드를 만든 것이다. *그 명세가 없었다면 — 2 일 만에 3 개월의 벽 * 이 도착했을 것이다.

알렉스의 다른 인용 한 줄.

"2 주가 소요될 개발 작업을 단 몇 시간 만에 완료하여 C-level 미팅에서 실체적인 결과물로 설득력을 극대화."

몇 시간 만에 2 주 분량 — 이게 명세 + AI 의 위력이다. 그러나 그 몇 시간 안에는 명세 작성 + 검증 설계 + AI 지시 + 결과 검토 + 재지시 가 다 들어 있다. *"AI 한테 던져 두고 오라" 가 아니라 집중적으로 오케스트레이션 * 한 결과 다.

---

CS 학생을 위한 핵심 메시지 — 적용 위치 이동

이 장의 오해 한 가지를 미리 차단한다.

"그럼 알고리즘 / OOP / DB 안 배워도 되겠네?"

❌ 완전히 틀린 결론. 정확한 메시지는 적용 위치가 바뀐다 다. 표로 본다.

알고리즘을 모르면 — AI 에게 어떤 알고리즘으로 풀라 고 지시할 수 없다. 정렬을 모르면 "이걸 정렬해서 보여줘" 외에는 못 한다. 어떤 정렬이 적합한지 를 판단하는 능력은 알고리즘을 배운 사람만이 갖는다.

객체지향을 모르면 — AI 에이전트들의 역할 분리 를 설계할 수 없다. 클래스 / 인터페이스 / SOLID 원칙 을 *AI 에이전트의 경계 설계 에 그대로 적용 * 한다. (14 장에서 카파시 4 원칙 ↔ OOP 5 원칙 의 1:1 매핑을 다룬다.)

DB 를 모르면 — AI 의 컨텍스트 윈도우 를 어떻게 채울지 모른다. 정규화, 인덱스, 트랜잭션 의 사고 방식이 *AI 에게 무엇을 영구 기억하게 하고 세션 에서 잊게 할지 * 의 설계로 그대로 옮겨간다.

즉 4 년 동안 배운 모든 것이 재배치 되어 다시 쓰인다. 단지 어디에 쓰는가 가 바뀐다. 이게 5 장의 규모별 곡선 의 의미 — *왼쪽에서 배운 도구를 오른쪽으로 이동시키는 * 자리.

---

6 장 정리 — 코드는 AI 가, 설계는 여러분이

이 장의 결론 한 줄을 기록한다.

코드는 AI 가 쓴다. 설계는 여러분이 한다.

이걸 부정적으로 읽으면 "AI 가 내 일을 빼앗는다" 다. 긍정적으로 읽으면 "AI 가 내 시간을 진짜 중요한 일 (설계) 에 쓸 수 있게 해 준다".

알렉스의 또 다른 표현 — "AI 시간은 이제 내 시간이다." 즉 AI 가 코드를 짜는 그 시간 이 — 여러분이 설계 / 검토 / 다음 작업 명세 에 쓸 수 있는 추가 시간 으로 옮겨간다는 뜻이다.

표어로 닫는다.

AI-Native Vibe Coding: No Design, No Code. *— 코드는 AI 가 쓴다. 그 위의 설계자가 나 다. 이게 6 장의 한 줄.

다음 7 장에서는 그러면 어떻게 균형 을 잡는가 를 본다. VBC vs SDD 하이브리드 + 알렉스 4 대 전략 — 이번 부의 마지막 장이다.

"바이브 코딩과 사양 우선 개발을 어떻게 섞는가?"