바이브코딩 시대, 왜 다시 DDD, TDD, 애자일인가

개요

• 출처: damoang.net (다모앙 AI당), 2026.06.01
• 저자: 지나가던행인이
• 조회: 1,310 | 댓글: 14
• 주제: AI 바이브코딩 시대에 DDD, TDD, 애자일이 다시 의미 있게 결합하는 이유
• 분류: 소프트웨어 공학, AI 개발 방법론, 바이브코딩

내용 분석

서론: 빛 좋은 개살구였던 방법론들

애자일: 2001년 선언문은 고결했지만 실제 현장에서는 퇴화

• "데일리 스크럼=취조", "지라 티켓 상태 옮기기"
• "기획은 매일 바꾼다 + 출시일은 절대 못 미룬다"라는 가짜 애자일
• 결과: 개발자의 야근과 번아웃

DDD, TDD: 내일 아침 기획이 뒤집히고 다음 주에 마감인 전쟁터에서

• 도메인 경계 나누기, 테스트 먼저 짜기 = "사치재", "오버헤드"로 치부

왜 지금 다시 필요한가

핵심 논점: AI가 타이핑을 대신하는 시대에 이르러서야 인간은 "설계와 검증"에 집중할 수 있게 됨. 그때 비로소 DDD, TDD, 애자일이 작동하는 생태계가 완성됨.

① DDD — AI에게 공통 언어를 주입하는 나침반

문제: 같은 개념을 두고 "대화 조각", "검색 점수", "결과 합치기"라고 혼용하면 AI가 매번 다른 변수명과 꼬인 데이터 흐름을 만듦.

해법: 보편적 언어(Ubiquitous Language) 정의

예시 — AI 에이전트 세션 검색 엔진:

• Session: 터미널 에이전트와 나눈 대화 한 건
• Chunk: 세션을 검색 단위로 자른 조각. 오버랩 포함
• BM25 score: 형태소 기반 키워드 매칭 점수
• Vector score: 임베딩 기반 의미 매칭 점수
• RRF: 두 점수를 하나로 합치는 순위 융합 방식

이 용어 정의를 AI 시스템 프롬프트에 주입하면 "Chunk를 자를 때 한국어 형태소 경계가 깨지지 않도록 Lindera 토크나이저 결과를 기준으로 오버랩 구간을 잡는 어댑터를 짜줘"라는 한 줄의 바이브로도 정확한 코드를 생성.

Bounded Context 전략: 대형 시스템을 AI가 소화 가능한 크기로 슬라이싱

• Core Domain: 하이브리드 검색 엔진 (BM25 + 벡터 + RRF)
• Supporting Domain: 세션 파서 (Claude Code/Codex/Gemini 로그 포맷 처리)
• Generic Domain: Obsidian 호환 vault 출력

경계가 격리되어 있으면 AI에게 전체 프로젝트를 읽힐 필요 없음. 검색 코어 도메인의 타입 정의만 피딩한 채 좁고 깊은 명령을 내릴 수 있음.

한계: 도메인이 불확실한 초기 탐색 단계의 프로젝트에서는 경계를 미리 긋는 게 발목을 잡음. DDD는 도메인이 어느 정도 잡힌 다음에 힘을 발휘함.

② TDD — AI의 폭주를 막는 안전벨트

문제: AI가 겉보기에 문법적으로 완벽한데 특정 에지 케이스에서 런타임 에러를 내거나, 잘 돌아가던 핵심 기능을 소리 없이 망가뜨리는 코드를 수십 줄씩 만듦.

흐름 변화:

• 과거: 개발자가 로직 구상 → 테스트 작성(Red) → 구현(Green) → 리팩토링. 수작업 반복으로 속도 문제로 환영받지 못함.
• 바이브코딩 시대:

1. [인간] 비즈니스 목적지 정의 (실패하는 테스트 프롬프팅)
2. [AI] 테스트 통과를 위한 구현 초고속 작성 (Green)
3. [인간+AI] 기존 테스트 전체 실행으로 회귀 검증 및 리팩토링

예시: "한국어 쿼리에서 형태소 분석이 적용된 BM25 점수와 BGE-M3 벡터 점수를 RRF로 융합했을 때, 정답 문서가 상위 5개 안에 들어오는지 검증하는 단위 테스트를 짜줘" → AI가 테스트 작성 → AI가 구현 → 테스트 러너로 검증.

리팩토링의 두려움 제거: "기존 검색 테스트를 전부 통과하는 상태를 유지하면서, 벡터 인덱스를 sqlite-vec에서 usearch HNSW로 교체해줘" → AI가 인덱스 구조를 갈아엎으면 테스트 러너로 검증만 하면 됨.

한계: 입력과 출력이 명확한 영역(검색 정확도, 파싱 결과, 데이터 변환)에서 강력함. 출력이 주관적이거나 정답이 모호한 영역(LLM이 생성한 위키 문서 품질, UI 사용감)은 테스트로 가드레일을 치기 어려움.

③ 애자일 — 낮아진 구현 비용으로 만개하는 민첩성

과거 애자일 실패의 근본 원인: 삼각형의 법칙(범위-시간-비용)을 무시하고, 기획이 바뀌는 속도를 개발자의 타이핑 속도가 따라가지 못했음.

바이브코딩 시대의 변화:

핵심 통찰: "타이핑 비용이 사라진 자리를 설계와 검증 비용이 채우는 구조. 변경의 병목이 타이핑에서 사고로 옮겨 갔음."

AI가 구현 코드를 빨리 짜는 건 맞지만, 도메인을 정제하고 테스트를 설계하고 결과를 검증하는 작업에는 여전히 인간의 시간과 판단이 들어감. 오히려 그 작업의 비중이 커짐.

④ 삼위일체 실전 시나리오

상황: AI 에이전트 세션 검색 엔진 개발 중, GitHub 이슈로 기능 제안 도착

• "세션을 ingest할 때 첫 줄을 요약으로 뽑아 frontmatter에 자동으로 넣어주면 검색 결과에서 미리보기가 가능할 것 같습니다"

Step 1: DDD로 명세화 및 격리

• summary는 세션의 첫 실질 줄에서 추출하되 빈 줄과 인사는 건너뛴다
• frontmatter는 YAML 이스케이프를 적용한다
• 기존 vault 파일은 frontmatter 영역만 수정하고 본문은 불변
• 파서 도메인만 분리. 검색 코어나 vault 출력 도메인은 건드리지 않음

Step 2: TDD로 실패하는 가드레일 작성

• 빈 줄로 시작하는 세션, 인사만 있는 세션, YAML 특수문자가 포함된 첫 줄
• 에지 케이스에서 summary가 제대로 추출되고 이스케이프되는지 검증하는 테스트 셋
• 구현이 없으니 당연히 Red

Step 3: 바이브코딩으로 구현

• "방금 만든 summary 추출 테스트를 통과하도록 ingest 파이프라인에 frontmatter 생성 로직을 붙여줘. 기존 reindex 흐름과 충돌하지 않게."
• AI가 수십 초 만에 구현. 테스트 러너 돌리자 기존 테스트와 새 테스트가 전부 Green

Step 4: 애자일 배포 및 피드백

• 머지→배포→제안자에게 답변→backfill 명령 제안

결론

"타이핑의 병목이 사라진 자리에 설계와 검증과 판단 이 남습니다. 그 남은 자리가 결국 인간의 일 입니다."

"맨땅에 헤딩하는 게 에이전틱 개발이 아닙니다. 인간의 도메인 지식과 AI의 지치지 않는 작업이 맞물리는 협업입니다."

커뮤니티 반응

• 모글리: "좋은 글 감사합니다"
• 홍천브람스: "모델이 더 발달해서 저것마저도 알아서 척척 해줬으면 하는 바램이 있습니다" → 작성자: "이런 글도 조만간 레거시가 되어서 필요없는 시대가 오지 싶습니다"
• writer: "근거 부족한 낙관론, 비관론, 푸념, 일반화, 사득한 글만 보다가.. 가장 실용적인 참고할만한 글"
• writer: "애자일이 일정부분 발목을 잡고 있다고 느껴요. 애자일 스크럼팀이 일주일동안 손가락 빨고 인터넷 쇼핑이나 하게 될것같아요" — 애자일 미니멀리즘을 린 개념으로 개조할 필요성 주장
• pizzataco: "antigravity 쓰면서 어떻게 명령을 내려야할 지 고민을 많이 했었는데 핵심 개념을 잘 정리. DDD, TDD 에 유의하면서 적용해 봐야겠습니다"
• MethodMan: "좋은글 감사합니다"

전반적으로 긍정적 반응. 특히 "실용적"이라는 평가가 눈에 띔.

새로운 시각

"가짜 애자일"의 진짜 원인

과거 애자일이 실패한 것은 방법론 자체의 문제가 아니라 기술의 한계였음. AI가 구현 속도를 해결해주기 전에는 애자일은 개발자에게 재앙이었음. 이 관점은 "방법론이 나쁜 게 아니라 타이밍이 아니었다"는 역사적 해석을 제공.

DDD = AI 프롬프트 엔지니어링의 상위 개념

보편적 언어가 AI와의 소통 비용을 줄인다는 주장은 DDD를 단순한 아키텍처 방법이 아니라 AI 프롬프트 엔지니어링의 체계화로 재정의함. "AI에게 일을 시켜본 개발자가 다 겪는 문제"를 DDD가 해결한다는 것은 DDD를 AI 시대의 핵심 역량으로 격상시킴.

TDD = AI 신뢰성의 수량화

TDD를 "AI의 폭주를 막는 안전벨트"로 정의한 것은 새로운 관점. 테스트 통과 = AI 코드 신뢰도 100%라는 수식. 이는 "AI를 어떻게 신뢰할까"라는 실용적 질문에 대한 구체적 해답.

"설계와 검증 비용"의 등장

타이핑 비용이 0에 수렴할 때, 설계와 검증 비용이 상대적으로 증가한다는 관찰. 이는 "AI 시대에 개발자의 역할이 어떻게 바뀌는가"에 대한 구체적 예측: 타이퍼 → 검증자 → 설계자.

미래 영향

개발 조직에 주는 교훈

1. DDD를 AI 소통 도구로 재정의: 도메인 전문가가 AI 프롬프트의 보편적 언어를 정의해야 함
2. TDD를 AI 검증 파이프라인으로 구축: AI가 작성한 코드를 배포하기 전 테스트 통과가 필수
3. 애자일을 구현 비용 하락의 수혜자로 재탄생: 변경 비용이 낮아진 환경에서 진정한 애자일 실현

자녀 교육 시사점

• 시스템 설계 사고: 코드를 타이핑하는 능력이 아니라 시스템을 설계하는 능력이 핵심 역량으로 전환
• 검증 마인드: AI가 만든 결과물을 맹신하지 않고 검증하는 태도
• 도메인 지식의 중요성: AI는 도메인 지식을 가지고 있지 않음. 인간이 도메인 전문가가 되어야 AI를 효과적으로 지시할 수 있음

의료 AI 연결

• DDD: 의료 도메인의 보편적 언어 정의 (진단 코드, 약물 상호작용, 검사 지표)
• TDD: 의료 AI의 출력 검증 (진단 정확도, 약물 처방 안전성)
• 애자일: 의료 환경의 빠른 변화에 대응하는 민첩성

관련 링크

• 원문
• Wayback Machine 아카이브

키워드

#바이브코딩 #DDD #TDD #애자일 #AI개발방법론 #소프트웨어공학 #프롬프트엔지니어링 #도메인주도설계 #테스트주도개발

관련 노트

• AI 시대의 소프트웨어 장인정신
• Claude로 디자인