"기능 추가하려고 코드 열었는데, 어디를 고쳐야 할지 모르겠어요. 파일은 수십 개인데 뭐가 뭔지... AI가 짠 코드라 저는 더 모르겠고, 이거 계속 추가해도 괜찮은 건가요?"
맞아요. 처음엔 AI가 코드를 만들어줘서 신기했는데, 기능 추가할 때마다 "이거 어디에 넣지?" "이거 건드려도 되나?" 막막해지는 거예요.
왜 이런 일이 생길까요?
코드가 어떤 원칙 없이 마구잡이로 쌓여서 그래요. 파일은 많은데 역할이 뒤죽박죽이면, 어디를 고쳐야 할지 찾기도 힘들고, 수정하면 다른 곳이 꼬이기도 해요.
이게 바로 아키텍처(Architecture) 문제예요. 코드를 어떤 구조로 정리하느냐에 따라 나중에 고도화가 쉬울 수도, 막힐 수도 있어요.
아키텍처를 알면 AI한테 **"레이어드 아키텍처로 가되, 서비스 레이어 분리해줘"**라고 정확히 말할 수 있어요. 그러면 AI가 확장 가능한 구조로 만들어줘요.
이 글을 읽고 나면
- 아키텍처가 뭔지, 왜 필요한지 알 수 있어요
- 주요 아키텍처 패턴 3가지를 구분할 수 있어요
- 상황에 맞는 아키텍처를 선택할 수 있어요
- AI한테 "이 아키텍처로 가자"라고 말할 수 있어요
아키텍처가 뭔가요?
아키텍처는 코드를 어떻게 구조화할지 정하는 거예요.
PART 4 복습: 자료구조에서 아키텍처로
16편에서 데이터를 어떻게 정리할지를 배웠죠?
오늘 배울 것은: 코드를 어떻게 정리할지
- 16편: 데이터를 어떻게 정리? → 배열 / 객체 / 트리 / 큐 / 스택
- 17편(오늘): 코드를 어떻게 정리? → 레이어드 / 클린 / MVC
자료구조 vs 아키텍처: 뭐가 다른가요?
같은 할 일 관리 앱이라도 관점이 달라요. 프로젝트 폴더를 보면 바로 이해돼요.
한 줄 요약:
- 자료구조: 데이터를 배열/객체/트리 중 뭘로 담을까?
- 아키텍처: 코드 파일을 어느 폴더에 둘까?
둘 다 필요한 이유: 같은 프로젝트, 다른 관점
할 일 관리 앱 하나를 만들 때, 두 개념이 동시에 적용돼요.
비유로 이해하기:
🏠 집을 짓는다고 생각해보세요
자료구조 = 가구 배치
- 거실에 소파를 어떻게 놓을까? (ㄱ자? 일자?)
- 책장에 책을 어떻게 정리할까? (장르별? 가나다순?)
아키텍처 = 방 구조
- 1층에 뭘 둘까? (거실, 주방)
- 2층에 뭘 둘까? (침실, 서재)
- 지하에 뭘 둘까? (창고)
→ 가구(데이터)를 어떻게 배치하든, 방(코드)이 잘 나뉘어 있어야
나중에 방 하나 리모델링해도 다른 방이 안 꼬여요.
자동화에서 큐와 아키텍처:
왜 아키텍처가 필요한가요?
아키텍처 없이 코드를 짜면 이런 일이 생겨요.
프론트엔드와 백엔드의 아키텍처
11편에서 프론트엔드와 백엔드를 배웠죠? 각각 구조화 방법이 달라요.
주요 아키텍처 패턴 3가지
바이브 코더가 알아야 할 아키텍처는 3개만 알면 돼요.
1. 레이어드 아키텍처: 층층이 쌓기
레이어드 아키텍처는 코드를 층으로 나누는 거예요.
레이어드 아키텍처 예시: 할 일 추가
📦 실제 폴더 구조 예시
2. MVC: 역할 3가지로 나누기
MVC는 코드를 Model, View, Controller로 나누는 거예요.
MVC 예시: 할 일 목록 화면
📦 실제 폴더 구조 예시 (프론트엔드)
3. 클린 아키텍처: 지금 당장은 몰라도 돼요
클린 아키텍처는 코드를 동심원으로 나누는 고급 기법이에요.
그래도 개념은 알아두면 좋아요:
🔧 리팩토링이 필요할 때 AI한테 이렇게 말하세요:
레이어드 vs MVC vs 클린: 어떤 걸 쓸까요?
실전 예시: 쇼핑몰 아키텍처
쇼핑몰을 만든다면 어떤 아키텍처를 쓸까요?
AI한테 이렇게 요청하세요
아키텍처를 알면 AI한테 어떤 구조로 만들지 정확히 말할 수 있어요.
상황 1: 할 일 관리 앱 (백엔드)
❌ 나쁜 예 (구조 언급 없음)
나: "할 일 관리 API 만들어줘"
→ AI가 알아서 구조를 정하는데, 파일이 어디에 뭐가 있는지 나중에 찾기 힘들 수 있어요.
✅ 좋은 예 (아키텍처 지정)
나: "할 일 관리 API 만들 건데, Next.js + Supabase 쓸 거야.
레이어드 아키텍처로 가줘.
api/ 폴더에 엔드포인트,
services/ 폴더에 비즈니스 로직,
repositories/ 폴더에 DB 접근 코드 분리해줘.
나중에 알림 기능 추가할 거니까 확장 가능하게 만들어줘."
→ AI가 3층 구조로 깔끔하게 만들어요.
상황 2: 쇼핑몰 (프론트엔드)
❌ 나쁜 예
나: "상품 목록 페이지 만들어줘"
✅ 좋은 예
나: "쇼핑몰 프론트엔드 만들 건데, Next.js 쓸 거야.
컴포넌트 기반으로 가되, 이렇게 나눠줘:
- components/: 재사용 가능한 UI (버튼, 카드 등)
- pages/: 페이지별 라우팅
- hooks/: 상태 관리 (장바구니, 인증 등)
- api/: API 호출 함수
상품 카드는 여러 페이지에서 재사용할 거니까
components/ProductCard.tsx로 만들어줘."
상황 3: 프로젝트가 복잡해졌을 때 (리팩토링)
처음부터 완벽한 구조로 시작할 필요 없어요. 일단 레이어드로 만들고, 나중에 복잡해지면 그때 리팩토링하면 돼요.
❌ 비현실적 (처음부터 완벽하게)
나: "클린 아키텍처로 가줘. core/, adapters/, infrastructure/ 분리해서..."
→ 비개발자가 이렇게 말하기 어려워요. 이건 나중에 필요할 때 하면 돼요.
✅ 현실적 (일단 만들고 → 문제 생기면 → 리팩토링)
[처음]
나: "할 일 관리 앱 만들어줘. 레이어드 아키텍처로."
→ AI가 기본 구조로 만들어줌
[몇 달 후, 파일이 많아지고 복잡해짐]
나: "services 폴더에 파일이 20개가 넘었어.
찾기가 힘들어졌는데, 구조 정리 좀 해줘."
→ AI가 도메인별로 폴더를 나누거나, 구조 개선안을 제시해줌
[더 커지면]
나: "결제 로직이랑 DB 접근 코드가 섞여 있어서
나중에 PG사 바꾸려면 다 고쳐야 할 것 같아.
분리하는 방법 알려줘."
→ AI가 클린 아키텍처 관점에서 리팩토링 방법을 안내해줌
💡 핵심: 문제가 느껴질 때 그때 정리하면 돼요.
실제 대화 예시
AI랑 아키텍처 정하면서 대화할 때 이렇게 해요.
┌────────────────────────────────────────────────────────────────┐ │ 상황: 할 일 관리 앱 백엔드 만들기 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 나: "할 일 관리 API 만들 건데, Next.js + Supabase 쓸 거야." │ │ │ │ AI: "프로젝트 구조 어떻게 할까요? │ │ 1. 파일 하나에 다 넣기 (간단) │ │ 2. 레이어드로 폴더 나누기 (권장) │ │ 3. 클린 아키텍처 (복잡)" │ │ │ │ 나: "2번으로 가줘. 나중에 알림 기능 추가할 거니까 │ │ 서비스 레이어 분리해줘." │ │ │ │ AI: "알겠어요. 레이어드 아키텍처로 구조 잡을게요: │ │ │ │ api/ (1층: API 엔드포인트) │ │ - todos.ts - 요청 받고 응답 │ │ │ │ services/ (2층: 비즈니스 로직) │ │ - todoService.ts - 할 일 추가/수정/삭제 로직 │ │ - 검증, 규칙 처리 │ │ │ │ repositories/ (3층: DB 접근) │ │ - todoRepo.ts - Supabase 쿼리만 │ │ │ │ 나중에 알림 기능 추가하면 │ │ services/notificationService.ts만 추가하면 돼요." │ │ │ │ 나: "좋아. 그렇게 만들어줘." │ │ │ │ 💡 여기서 뭐가 중요했나요? │ │ - "레이어드"라고 정확히 말함 │ │ - 나중 확장(알림) 미리 고려 │ │ - AI가 구조 제안하면 확인 후 진행 │ │ │ └────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────┐ │ 상황: 나중에 프론트엔드 추가 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 나: "프론트엔드도 만들 건데, 화면 복잡하지 않으니까 │ │ 컴포넌트만 잘 나눠줘." │ │ │ │ AI: "Next.js 프론트엔드 구조 제안합니다: │ │ │ │ app/ (페이지 라우팅) │ │ - page.tsx - 메인 페이지 │ │ - todos/ - 할 일 페이지 │ │ │ │ components/ (재사용 컴포넌트) │ │ - TodoList.tsx - 할 일 목록 │ │ - TodoItem.tsx - 할 일 항목 │ │ - AddTodoForm.tsx - 추가 폼 │ │ │ │ hooks/ (상태 관리) │ │ - useTodos.ts - 할 일 데이터 관리 │ │ │ │ lib/ (API 호출) │ │ - api.ts - 백엔드 API 호출 함수 │ │ │ │ 각 컴포넌트는 한 가지 역할만 하게 만들게요." │ │ │ │ 나: "좋아. AddTodoForm은 입력만 받고, │ │ 실제 추가는 useTodos에서 하게 해줘." │ │ │ │ AI: "네, 관심사 분리하겠습니다." │ │ │ │ [기능 확인] │ │ - 할 일 추가 → 폼(UI)과 로직(hook) 분리 ✅ │ │ - 코드 수정할 때 어디 고칠지 바로 알 수 있음 ✅ │ │ │ │ 💡 프론트와 백엔드 각각 구조화했어요 │ │ - 백엔드: 레이어드 (API → Service → Repository) │ │ - 프론트: 컴포넌트 기반 (UI / 로직 / 상태 분리) │ │ │ └────────────────────────────────────────────────────────────────┘
아키텍처 선택 체크리스트
바이브 코더는 고민할 필요 없어요. 그냥 레이어드로 시작하세요.
코드 문법 몰라도 돼요
💡 잠깐, 저는 코드를 못 짜는데요?
괜찮아요. 아키텍처 개념만 알면 돼요.
여러분이 알아야 할 것:
✅ 레이어드 = 층으로 나누기
✅ MVC = 화면 / 제어 / 데이터 분리
✅ 클린 = 핵심 로직과 구현 분리
여러분이 몰라도 되는 것:
❌ 레이어를 코드로 어떻게 만드는지
❌ MVC를 어떻게 구현하는지
❌ 클린 아키텍처 세부 원칙
→ AI한테 "레이어드로 가줘"라고 말만 하면 돼요.
→ AI가 구조 잡아줘요.
주의사항: 처음부터 완벽한 구조는 없어요
⚠️ 처음부터 모든 걸 완벽하게 설계할 수 없어요
근데 이것만은 지키세요:
- UI 코드와 로직 코드는 분리
- DB 접근 코드는 따로 모아두기
- 같은 역할은 같은 폴더에
- 파일 이름 규칙 정해두기 (todoService.ts, todoRepo.ts)
다음 단계: 디자인 패턴
아키텍처를 알았으면 이제 코드를 어떻게 짤지 정하는 게 디자인 패턴이에요.
오늘 배운 것: 전체 구조를 어떻게?
→ 레이어드 / MVC / 클린
다음 편: 코드 작성 패턴은?
→ 싱글톤, 팩토리, 옵저버 등
→ "이 컴포넌트는 Container-Presenter 패턴으로"
오늘의 핵심 정리
셀프체크
이 글을 이해했다면 아래 질문에 답할 수 있어요:
- 할 일 관리 백엔드를 만든다면 어떤 아키텍처가 적절한가요?
- 프론트엔드에서 화면과 로직을 분리하려면 어떤 패턴을 쓰면 되나요?
- 레이어드 아키텍처에서 DB 접근 코드는 어느 층에 두나요?
- 레이어드 아키텍처 (API → Service → Repository 3층 구조)
- MVC 또는 컴포넌트 기반 (View는 화면만, Controller/Hook은 로직)
- 데이터 레이어 (3층, repositories/ 폴더)
다음 글 예고
오늘은 아키텍처를 배웠어요. 코드를 레이어드로 할지, MVC로 할지, 클린으로 할지 선택하는 법이요.
근데 아키텍처만 알면 부족해요. "이 상황에서 코드를 어떻게 짤까?"도 중요해요.
다음 글에서는 디자인 패턴 개념을 알아볼게요.
18편: 디자인 패턴 개념
- "반복되는 문제를 어떻게 해결할까?"
- 싱글톤, 팩토리, 옵저버... AI한테 "이 패턴으로 해줘"라고 말하는 법
- "이 컴포넌트는 Container-Presenter 패턴으로 분리해줘"
아키텍처로 큰 구조를 잡았으면, 이제 세부 코드 작성 패턴을 배워요.
이 시리즈 로드맵
PART 3: 기술 개념 - 큰 그림
[ 10편 ] 프로그램의 종류 ✅
↓
[ 11편 ] 프론트엔드 vs 백엔드 ✅
↓
[ 12편 ] 데이터는 어디에 저장되나 ✅
↓
[ 13편 ] 서비스들이 대화하는 방법: API ✅
↓
[ 14편 ] 프로젝트 구조 ✅
↓
[ 15편 ] 데이터 흐름 ✅
↓
PART 4: 기술 개념 - 설계
[ 16편 ] 자료구조 개념 ✅
↓
[ 17편 ] 아키텍처 개념 (지금 여기!)
↓
[ 18편 ] 디자인 패턴 개념
↓
...
궁금한 점이나 다뤘으면 하는 주제가 있으면 댓글로 남겨주세요!