1
핵심 개요 — 빠른 개발의 진짜 비결
0:00
| 항목 | 내용 |
|---|
| 주장 | 새 프로젝트가 기획→동작 화면까지 빨랐던 건 실력이 아니라 코드베이스가 잘 깔려 있어서 |
| 코드베이스 | 프로젝트 전체 소스코드의 구조·기반. 잘 정리돼 있으면 새 기능을 끼울 "자리"가 명확함 |
| 핵심 비유 | 도면 잘 나온 집 vs. 벽돌 막 쌓은 집 — 살아보면 동선·콘센트 위치에서 완전히 갈림 |
| 경고 대상 | 바이브 코딩(분위기·느낌대로, 계획 없이 짜는 코딩)의 구조적 위험 |
2
핵심 구조 — 좋은 코드베이스의 두 기둥
0:56
기둥 ① DDD (도메인 분리)
- 코드를 결제·회원·주문 등 비즈니스 단위로 나눔
- 결제 로직은 결제 도메인, 회원 로직은 회원 도메인 안에
- 새 개발자도 "결제 문제면 결제 폴더만" 보면 됨
기둥 ② 기술 스택 분리
- 프론트엔드 = Next.js(화면 그리기에 강함, 서버사이드 렌더링·자동 라우팅)
- 백엔드 = Python(데이터 처리·머신러닝·외부 API에 강함)
- 제작자는 둘을 한 저장소에 모은 모노레포 사용
3
기술적 맥락 — DDD를 회사 부서에 비유하면
1:52DDD(Domain-Driven Design, 도메인 주도 설계): 코드를 업무 영역별로 나누는 설계 방식. 회사로 치면 인사팀·재무팀·영업팀처럼 부서를 나누는 것과 같다.
한 사무실에 다 섞인 경우 (분리 X)
- 누가 무슨 일 하는지 모름
- 책임 소재가 흐릿함
- 하나 고치면 엉뚱한 데가 터짐
부서로 나눈 경우 (DDD 적용)
- 각 팀이 자기 일에만 집중
- 필요할 때만 다른 팀과 협업
- 결제 코드 고쳐도 회원 가입이 안 망가짐
왜 Python을 백엔드로? 데이터 처리·AI 모델 구동·API 통신에 유리하고, 코드량이 적어 AI가 코드를 짤 때 더 효율적이며 읽고 쓰기도 편하다.
4
전략적 의미 — 바이브 코딩이 무너지는 지점
4:10바이브 코딩(Vibe Coding): 아무런 기반 없이 맨땅에서 분위기·느낌대로, 계획 없이 코드를 짜는 방식. 처음엔 정말 빠르지만 시간이 갈수록 무너진다.
잘 짜인 코드베이스 (시간이 갈수록 안정)
- 초반 속도는 다소 느려도 기반이 탄탄
- 한 달 뒤에도 속도 유지, 디버깅 쉬움
- 버그가 한 영역에 갇혀 번지지 않음
바이브 코딩 (처음만 빠름)
- 초반엔 빠르지만 한 달 뒤 급격히 느려짐
- 어디 건드리면 어디 터질지 모름 → 디버깅 지옥
- 버그 하나가 전체로 번짐, 작은 기능에 1주일
5
핵심 워크플로우 — 기능 하나 추가하는 흐름
2:49예시: "회원이 결제하면 알림 보내기" 기능 추가 — 잘 깔린 코드베이스에서는 다른 영역을 거의 건드리지 않는다.
레고 블록 원리: 결제·알림 도메인이 이미 잘 정리돼 있으니 그 위에 기능만 살짝 얹으면 끝. 기반 블록이 깔려 있으면 새 모양 만들기는 금방이다.
01
신규 프로젝트 셋업
시작 단계에서 DDD로 도메인을 나누고 Next.js+Python 스택을 깔아 두면, 이후 기능 추가 속도가 근본적으로 빨라진다.
02
레거시 리팩터링
작은 기능에 1주일씩 걸리기 시작하면 코드베이스 자체를 다시 짜야 할 신호. 영역 분리부터 손대 디버깅 비용을 줄인다.
03
팀 협업
프론트 담당은 백엔드를, 백엔드 담당은 화면을 신경 안 써도 됨. 영역이 분리돼 각자 빠르게 움직일 수 있다.
요지: AI 코딩 시대에도 속도의 본질은 "빨리 치는 것"이 아니라 잘 정리된 기반에 있다. 감으로만 가는 바이브 코딩은 처음만 빠를 뿐, 기반이 없으면 디버깅·확장에서 반드시 무너진다. 바이브 코딩을 하더라도 DDD로 영역을 나누고 검증된 스택을 까는 등 "조금 더 잘 짜인" 방식으로 가야 지속 가능하다.