바이브코더를 위한 개발 설계의 정석

코드를 화면·정책·저장 세 층으로 나누라고 AI에게 지시하고, AI가 내놓은 설계에 반론하면서 가계부 앱 하나를 끝까지 만들어 본 라이브예요.

이 노트를 읽고 나면 할 수 있는 것

1. 내 프로젝트나 내가 쓰는 서비스를 Presentation / Logic / Data 세 층으로 나눠 설명할 수 있어요.
2. 방송에서 쓴 프롬프트 세 개(스탠스 · TRD 설계 · 테스트 설계)를 순서대로 넣어 3계층 프로젝트를 시작할 수 있어요.
3. AI가 낸 설계에서 "이건 어느 층의 책임이냐"를 짚어 고치게 할 수 있어요.

다시보기: https://youtu.be/1zWoVKtf7jo (2시간 18분. 강의 본편 약 1시간 25분, 이후 Q&A)

목차

• 같은 도구인데 결과가 갈리는 이유 ▶ 0:07:31
• 코드를 세 층으로 나누기 ▶ 0:13:17
• 층을 나누면 고칠 곳이 먼저 보여요 ▶ 0:22:43
• 아는 서비스를 세 층으로 뜯어보기 ▶ 0:32:39
• 가계부 프로젝트를 만들고 AI의 입장부터 정하기 ▶ 0:40:45
• TRD는 바로 쓰게 하지 말고 논의점부터 받기 ▶ 0:54:02
• AI가 그은 경계에 반론하기 ▶ 1:05:25
• 층은 나뉘었는데 코드는 더러웠어요 ▶ 1:12:50
• 단일 책임 원칙으로 한 번 더 쪼개기 ▶ 1:36:10
• Q&A ▶ 1:42:46
• 다음에 쓸 프롬프트 두 개 ▶ 1:29:51
• 오늘 해볼 것 ▶ 1:30:07

같은 도구인데 결과가 갈리는 이유 ▶ 0:07:31

버그를 고치느라 프롬프트를 더 넣고, 토큰은 모자라고, 코드는 산으로 가요. 취미 수준이라면 20달러 요금제로도 토큰은 넉넉한데, 이상하게 만들고 그걸 또 이상하게 고치느라 낭비하는 거예요.

오픈클로를 만든 피터 스타인버거(Peter Steinberger)는 읽지도 않는 코드를 배포한다는데, 같은 클로드 코드나 코덱스를 쓰면서 왜 이렇게 차이가 날까요?

답은 GIGO(Garbage In, Garbage Out — 쓰레기를 넣으면 쓰레기가 나온다)예요. ▶ 0:09:41 피터도 코드는 안 읽지만 기획에는 가장 많은 시간을 들인대요.

우리가 갖춰야 할 역량은, AI가 어떤 방향을 제안했을 때 반론을 제기하고 수정하고 확인할 수 있는 거예요. ▶ 0:10:19

제 예전 라이브도 초기 설계에 1시간을 쓰고, 구현은 프롬프트 한 번으로 24분 만에 끝났어요. ▶ 0:11:58

오늘 나누려는 건 개발자가 요구사항을 머릿속에 미리 그려 보는 시야예요.

코드를 세 층으로 나누기 ▶ 0:13:17

오늘 다룬 건 3계층 구조(3-tier Layered Architecture) 하나예요. 프로젝트의 코드를 세 층으로 나누는 거예요.

세 역할 모두 전문 지식이 필요해서, 한 직원에게 다 시키면 너무 복잡해져요. 코드도 파일 하나가 이 역할을 전부 하지 않고, 파일마다 특정 역할만 하게 만드는 거예요. 이게 레이어드 아키텍처예요. ▶ 0:20:38

층을 나누면 고칠 곳이 먼저 보여요 ▶ 0:22:43

어떤 수정을 할 때 어느 레이어를 건드리겠다는 감이 있으면, 내 지시로 코드베이스가 어떤 범위까지 바뀔지가 그려져요. ▶ 0:22:54

아는 서비스를 세 층으로 뜯어보기 ▶ 0:32:39

오픈클로(OpenClaw)는 내 컴퓨터에 설치해 두고 디스코드·슬랙·왓츠앱으로 대화하는 AI 에이전트예요. Presentation은 메시지를 받고 보내고, Data는 메시지를 저장하고 soul.md(에이전트 페르소나 파일)와 과거 기록을 불러와요.

층 사이 규칙도 있어요. 인접한 계층끼리만 소통해야 해요. Presentation이 Data를 건드리면 절대 안 되고, 데이터가 궁금하면 무조건 Logic을 거쳐야 해요. ▶ 0:36:26

가계부 프로젝트를 만들고 AI의 입장부터 정하기 ▶ 0:40:45

실습은 간단한 가계부 앱이에요. 준비물은 Node.js(22 이상), VS Code, 클로드 코드(Claude Code)고, 슬라이드 순서는 이랬어요. 방송에서는 이미 켜 둔 클로드 코드에 이 텍스트를 그대로 붙여 넣어 시켰어요.

AI한테 "좋은 코드로 써 줘"라고 말만 하면 부족해요. 입장을 줘야 돼요. ▶ 0:52:43

TRD는 바로 쓰게 하지 말고 논의점부터 받기 ▶ 0:54:02

이제 TRD(기술 요구사항 문서) 설계 프롬프트를 넣어요.

그냥 "설계 시작", "구현 시작" 하라고 하는 것보다 논의점부터 꺼내라고 하는 게 좋아요. ▶ 0:55:10

AI가 그은 경계에 반론하기 ▶ 1:05:25

AI는 그래프의 좌표 계산을 떼어 Logic에 두겠다고 했어요. 저는 어느 좌표에 점을 찍을지는 Presentation의 일이라고 봐서 이렇게 반론했어요.

더 짚어, 더 짚어 하다 보면 짚을 게 없어서 억지로 짚는 순간이 와요. 그럴 땐 되돌려 버리고, 아무 일도 없었던 것처럼 구현하라고 해요. ▶ 1:12:30

층은 나뉘었는데 코드는 더러웠어요 ▶ 1:12:50

구현이 도는 동안 코드를 같이 읽었어요. 폴더 이름은 logic이었는데, 저라면 쓸 lib보다 나아요. lib은 너무 범용적이라 안에 핵심 로직이 있는지 감이 안 오거든요.

완성된 앱은 잔액 그래프와 인사이트까지 그럴듯했어요. ▶ 1:24:24 이 정도 서비스는 웹에서 채팅으로 시켜도 만들어 줘요. 근데 내부가 깔끔하냐는 다른 문제예요. ▶ 1:25:59

단일 책임 원칙으로 한 번 더 쪼개기 ▶ 1:36:10

Q&A에서 "리액트 코드 컨벤션을 정의하면 괜찮게 나오냐"는 질문을 받았어요. 아까 코드가 더러웠던 건 3계층으로는 모자라서, Presentation도 더 나눴어야 했기 때문이에요.

단순 컨벤션으로 해결될 문제는 아니고, 단일 책임 원칙 같은 원칙들을 잘 지키도록 가이드해야 돼요. ▶ 1:36:55 단일 책임 원칙(SRP)은 모듈 하나가 한 가지 이유로만 바뀌어야 한다는 원칙이에요.

Q&A ▶ 1:42:46

다음에 쓸 프롬프트 두 개 ▶ 1:29:51

층을 맞춰 두면 저장 방식 변경은 Data와 그 테스트만, 새 기능도 쉽게 붙일 수 있어요. 새 기능 설계 프롬프트는 방송에서 돌리진 않고 다시보기로 실습해 보시라고 했어요.

오늘 해볼 것 ▶ 1:30:07

작동 전체를 테스트하는 게 아니라 계층별로 테스트하고 조립하면 되니까, 훨씬 싸고 안전하게 테스트할 수 있어요. ▶ 1:30:31