"여러분의 과제는 곡선 왼쪽. 졸업하면 오른쪽 으로 갑니다. 이 책은 그 오른쪽으로 갈 때를 대비 하라는 책입니다."

---

도입 — 우수한 학생일수록 던지는 한 질문

이 책 한 권 전체를 반박 하는 단 하나의 질문이 있다. 우수한 학생일수록 더 자주 던진다.

"교수님, 제 과제는 100 줄 / 3 일짜리인데 — 설계 안 해도 잘 돌아갔는데요?"

이 질문이 틀린 질문이 아니다. 맞는 관찰 이다. 그리고 이 책이 그 관찰을 부정하지 않는다. 다만 위치를 바꿔서 본다.

이 장의 목표는 그 질문 한 가지에 6 페이지 전체로 답하는 것 이다. 만약 이 장이 끝났을 때 여러분이 "아, 내 과제는 곡선 왼쪽이고, 졸업하면 오른쪽으로 가는구나" 라는 한 줄을 얻어 간다면 — 5 장은 성공이다.

핵심 명제 미리 박기.

설계의 필요도는 프로젝트의 규모 와 시간 축 에 따라 비선형으로 증가한다.

100 줄에서 조금 늘면 설계가 조금 필요해지는 게 아니다. 어느 임계점 을 넘는 순간 급격히 필요해진다. 그 임계점이 어디인지 — 이 장에서 그린다.

---

규모별 설계 곡선 — 한 표

먼저 표를 던지고 시작한다.

이 표가 비선형 인 이유를 봐야 한다. 100 줄 → 1,000 줄 (10 배 증가) 일 때 설계 비율은 0% → 5~10%. 1 만 → 100 만 (100 배) 일 때는 25% → 80%. 즉 규모가 100 배 늘면 설계 비율은 급격히 늘어난다.

왜? 복잡도가 제곱 으로 증가하기 때문 이다. 100 줄짜리 시스템에는 상호작용 가능 짝 이 적다. 100 만 줄짜리에서는 모든 모듈이 모든 모듈과 영향을 주고받을 수 있다 — 그 조합 공간 을 설계 없이는 머리에 들어오지 않는다.

---

곡선 위 5 점 — 자세히

각 점이 무엇인지 풀어 본다.

점 1 — 100 줄 / 1 일 (설계 0%)

과제 다. 알고리즘 1 개, 자료구조 1 개, 입력 → 출력 이 명확. 머릿속에 전체가 들어온다. 설계 문서 없이도 정상 작동한다. Cursor 자동완성을 그대로 받아도 큰 문제 없다.

→ 이게 여러분이 지난 4 년 동안 평가받아 온 자리다. 그래서 "설계 필요 없다" 라는 경험적 결론 이 자연스럽게 기록된다.

점 2 — 1,000 줄 / 3 일 (설계 5~10%)

팀 프로젝트 또는 작은 개인 프로젝트. 3 인 팀이 *한 학기에 간단한 웹 앱 한 개 를 만드는 자리. 여러분이 3 주째에 막히는 자리다.

여기서 처음으로 설계 부재의 통증이 보인다. 한 명이 고친 변수명 을 다른 명이 모른다. *3 주차에 와서 서로 다른 가정 으로 짠 코드가 합쳐지지 않는다.

이 자리에서 5 ~ 10% 의 설계를 미리 했다면 — 역할 분담 / 함수 시그니처 합의 / 테스트 골격 1 시간 토론 — 3 주차의 통증이 없어졌을 것이다. "우리 그때 회의 1 시간 더 했어야 했는데" 라는 후회의 자리.

점 3 — 10,000 줄 / 2 주 (설계 25%)

졸업작품 본체, 또는 해커톤. 부록 A 의 Crossbeam 해커톤 우승 사례가 이 자리다. 2 일 만에 만들어 우승 한 팀이 — 왜 우승했는가? 전체 코드 시간의 25% 를 설계에 투입 했기 때문이다. 4 시간을 설계에 쓴 다음 12 시간을 코딩에 썼다.

이 자리부터는 *AI 가 도와줘도 — 설계 없이는 결과물이 팀 안에서도 합쳐지지 않는다. 팀이 4 명 이상 이거나 *기능이 5 개 이상 이면 — 머릿속에 다 안 들어간다.

점 4 — 100,000 줄 / 2 개월 (설계 50%)

스타트업 MVP. 부록 A 의 Elisa 프로젝트 (1 주일 39,000 줄) 가 이 자리에 가깝다. 1 인이 1 주일에 4 만 줄을 만든 비결이 AI 능력 만이 아님을 1 장에서 봤다 — 아키텍처 + 명세 + 1,500 테스트 를 수동으로 짜고 그 위에 AI 가 타이핑을 했다.

여기서 설계 비율 50% 가 의미하는 것은 — 총 시간의 절반 을 코드를 쓰지 않는 활동 에 쓴다는 뜻이다. 명세 작성, 테스트 골격, 검증 루프 설계, CLAUDE.md 작성, 모듈 경계 결정. 그 절반이 없으면 — 다음 1 주일에 시스템이 무너진다.

점 5 — 1,000,000 줄 / 6 개월 (설계 80%)

회사 코드베이스. 여러분이 졸업하고 입사한 첫 직장 의 자리. 신입 개발자가 첫 6 개월에 마주칠 자리.

여기서는 설계가 코드보다 더 큰 산출물 이 된다. CLAUDE.md, 디자인 문서, RFC, 의사결정 로그, 아키텍처 다이어그램, 테스트 정책, 보안 정책. 코드는 그 설계 산출물의 부산물 처럼 보인다.

여러분이 *입사 첫 주에 기존 시스템을 이해하기 위해 보내는 시간 * 이 정확히 이걸 보여 준다. 한 주 내내 PR 한 줄 안 적고 — 문서를 읽고 회의에 참여하고 시스템 다이어그램을 그린다. 이게 설계 80% 의 일상이다.

---

비선형 의 의미 — 임계점 통과의 신호

곡선이 부드러운 직선이 아니라 급격히 꺾이는 자리 가 있다고 했다. 그 임계점이 정확히 어디인지 학생들이 자주 묻는다. 답을 기록한다.

임계점 = 팀 인원이 4 명을 넘거나 / 기능이 5 개를 넘거나 / 기간이 2 주를 넘는 순간.

이 셋 중 한 가지가 일어나면 머릿속에 시스템 전체가 안 들어온다. 전체가 안 들어오면 — 부분 결정이 다른 부분과 충돌한다. 충돌이 누적되면 3 개월의 벽 이 도착한다 (4 장).

여러분이 학기 프로젝트에서 3 주째에 막혔다면 이 임계점을 넘은 거다. 짧게 압축하면 — "학기 프로젝트 = 3 개월의 벽의 1/4 축소판". 회사에서 일어나는 *6 개월짜리 사고의 3 주짜리 버전 * 을 *학교에서 미리 경험하는 것이다.

이걸 부정적으로 읽지 마라. *학교에서 3 주에 한 번 그 통증을 무료로 경험해 본다는 것 — 그게 학교의 가치다. 회사에서는 3 개월에 한 번 그 통증이 유료 로 온다. (그 유료 비용이 4 장의 7 건 사고들이다.)

---

Vercel 도 설계를 한다 — 형태가 다를 뿐

이 곡선을 보면 반례 가 떠오를 수 있다.

"하지만 Vercel 은 설계 문서 없이 빠르게 배포하잖아요?"

이게 흔한 오해 다. Vercel 은 설계를 안 하는 게 아니라 — 설계의 형태 가 다르다. 무거운 워터폴 문서 가 아닐 뿐, 결정의 기록 이 곳곳에 있다.

표로 비교해 본다.

Vercel 도 GitHub 에 Issues 와 RFC 가 곳곳에 있다. 새 기능을 추가하기 전 RFC 를 올려 팀 토론 을 거친다. 그 RFC 문서가 곧 설계 다. 무거운 UML 한 장이 아니라 — *결정을 기록하는 한 페이지짜리 문서 * 다.

즉 "설계 = 무거운 문서" 가 아니다. 설계 = 의사결정을 글로 기록하는 행위. 형태는 시대마다 다르다. 2020 년대 AI 시대의 형태가 — CLAUDE.md / AGENTS.md / .cursorrules. (14 장에서 다시 자세히 만난다.)

---

학생을 위한 한 줄 가이드 — 위치 인식

이 장의 결론을 행동 지시 한 줄로 기록한다.

여러분이 곡선의 어느 위치 에 서 있는지 매번 의식 하라.

100 줄 / 1 일짜리 과제에 50% 설계 를 넣으면 — 과한 설계 (Analysis Paralysis) 다. 그 자리에는 그냥 하면 된다.

100 만 줄 / 6 개월짜리 회사 코드베이스에 0% 설계 를 들이대면 — 3 개월의 벽 이 온다.

이 두 함정 사이의 적정선 이 곡선이다. 학생일 때는 곡선 왼쪽에서 안전하게 연습 하고, *졸업할 때 오른쪽으로 옮겨갈 체계만 손에 들고 가면 — 입사 후 첫 6 개월의 격차가 베테랑 5 년 차와 다르지 않다.

이 책 8~14 장이 그 체계 를 다룬다. 5 장은 *왜 그 체계가 필요한지의 위치 * 를 박았을 뿐이다.

---

5 장 정리 — 과제 ↔ 회사 의 다리

여러분의 지금 위치 와 졸업 후 위치 는 같은 일 의 서로 다른 점 이다. 둘 사이가 연속 이라는 것 — 그게 5 장의 한 줄.

표어로 닫는다.

AI-Native Vibe Coding: No Design, No Code. — No Design 이 의미가 변하지 않는다. 단지 과제 규모 에서는 눈에 안 보일 뿐. 졸업하면 보인다.

다음 6 장에서는 그 오른쪽 자리 에서 여러분이 어떤 사람 이 되어야 하는지 의 역할 전환 을 본다. 코더 → 아키텍트.

*"알렉스 (메타 시니어) 가 명확히 한 줄로 답한다 — 핵심 역량은 코딩 실력이 아니라 문제 정의 능력.""