외주개발작업으로 바빠서 한동안 포스팅을 못했는데, 어제 너무 일찍 잤더니 너무 일찍 눈이 떠져서 오랫만에 또 쓸데 없는 잡담 하나 올려봅니다. 😁

빛 좋은 개살구였던 애자일

소프트웨어 공학에서 지난 20여 년간 애자일만큼 뜨겁게 찬양받고 동시에 지독하게 저주받은 단어도 드뭅니다.

"변화에 민첩하게 대응하라", "문서보다 작동하는 소프트웨어를 우선하라", "개인과 상호작용에 가치를 두라". 2001년 애자일 선언문의 구절들은 고결했습니다. 다만 실제 현장에서 마주한 애자일의 실체는 달랐습니다.

많은 조직이 애자일을 도입한다며 아침마다 개발자를 모아놓고 어제 무슨 삽질을 했는지 취조하는 데일리 스크럼을 돌렸고, 지라 티켓 상태 탭을 옮기는 데 집착했습니다. 최악은 "우리는 애자일이니까 기획을 매일 바꿀 수 있다"는 독단과 "출시일은 절대 못 미룬다"는 폭포수(Waterfall)식 통제가 결합한 가짜 애자일이었습니다. 범위와 시간이 동시에 묶인 상태에서 휘몰아치는 요구사항 변경을 온몸으로 받아낸 건 개발자의 야근과 번아웃이었습니다. 엔지니어링 기반 없는 가짜 애자일은 합법적으로 개발자를 쥐어짜는 빛 좋은 개살구였습니다.

비슷한 시기에 DDD(도메인 주도 설계)와 TDD(테스트 주도 개발)는 상아탑의 이론이거나 빅테크만 누리는 사치재로 여겨졌습니다. 내일 아침 기획이 뒤집히고 다음 주에 마감인 전쟁터에서, 도메인 경계를 엄밀히 나누고 실제 코드 전에 실패하는 테스트부터 짜는 행위는 오버헤드로 치부됐습니다.

2026년 현재 패러다임이 바뀌었습니다. LLM이 자연어 명령을 이해하고 몇 초 만에 구동 가능한 코드를 쏟아내는 바이브코딩 시대가 왔습니다. 아이러니하게도 인간이 직접 타이핑하지 않고 의도만으로 소프트웨어를 빌드하는 이 시대에 이르러서야, 과거에 개발자를 괴롭힌 가짜 애자일과 사치재로 여겨진 DDD, TDD가 하나의 생태계로 결합하며 실체를 얻기 시작했습니다.

그 결합을 추적해 볼까합니다. 다만 한 가지, 이 글은 만능 해법을 얘기하는 것은 아닙니다. 해당 방법론들이 작동하는 영역이 있고, 적용이 까다로운 영역도 있습니다. 그 경계도 같이 짚어 보았습니다.

DDD(Domain Driven Design), AI에게 공통 언어를 주입하는 나침반

바이브코딩 시대에 개발자의 주 업무는 키보드로 소스를 타이핑하는 게 아닙니다. AI 에이전트에게 비즈니스 요구사항과 아키텍처 의도를 명확히 전달하는 작업이 핵심입니다. 여기서 DDD가 AI의 환각을 줄이고 정확한 코드를 끌어내는 나침반이 됩니다.

보편적 언어의 재발견

AI에게 일을 시켜본 개발자가 다 겪는 문제가 있습니다. 같은 개념을 두고 프롬프트에 이 단어 저 단어를 혼용하면 AI가 맥락을 오해해서 엉뚱한 스키마와 데이터 흐름을 만들어냅니다.

먼저 DDD의 핵심 실천법인 보편적 언어(Ubiquitous Language)는 도메인 전문가, 기획자, 개발자가 모두 같은 의미로 쓰는 엄격한 용어 사전입니다.

예를 들어 AI 에이전트 세션을 검색하는 로컬 검색 엔진을 만든다고 해봅시다. AI에게 "대화 조각", "검색 점수", "결과 합치기"라고 두루뭉술하게 지시하면, AI는 매번 chunk, segment, score, rank, merge 같은 제멋대로인 변수명과 꼬인 데이터 흐름을 뱉어냅니다.

그런데 도메인 용어를 다음과 같이 정의하고 AI의 시스템 프롬프트 구조로 주입하면 달라집니다.

• Session: 터미널 에이전트와 나눈 대화 한 건

• Chunk: 세션을 검색 단위로 자른 조각. 오버랩을 포함

• BM25 score: 형태소 기반 키워드 매칭 점수

• Vector score: 임베딩 기반 의미 매칭 점수

• RRF: 두 점수를 하나로 합치는 순위 융합 방식

이제 개발자가 "Chunk를 자를 때 한국어 형태소 경계가 깨지지 않도록 Lindera 토크나이저 결과를 기준으로 오버랩 구간을 잡는 어댑터를 짜줘"라고 한 줄의 바이브만 던져도, AI는 보편적 언어 안에서 도메인 규칙에 맞는 코드를 생성합니다. DDD가 AI와의 소통 비용을 크게 떨어뜨립니다.

전략적 설계와 하위 도메인 격리

아무리 좋은 LLM이라도 수만 줄의 모놀리식 코드 전체를 한 번에 이해하고 완벽한 수정본을 내는 건 불가능합니다. 컨텍스트 윈도우 한계와 토큰 소모, 집중력 저하 때문입니다.

DDD의 Bounded Context 전략은 거대한 시스템을 독립적으로 분리된 경계로 쪼갭니다. 검색 엔진을 예로 들면 이렇게 나뉩니다.

• Core Domain: 하이브리드 검색 엔진. BM25 + 벡터 + RRF (src/search/)

• Supporting Domain: 세션 파서. Claude Code / Codex / Gemini 각각의 로그 포맷 처리 (src/parser/)

• Generic Domain: Obsidian 호환 vault 출력 (src/vault/)

경계가 격리되어 있으면 AI에게 전체 프로젝트를 다 읽힐 필요가 없습니다. 검색 코어 도메인의 타입 정의만 피딩한 채 "여기에 RRF 융합에서 k 상수를 조정하고 BM25와 벡터 점수의 정규화 로직을 분리해줘"라고 좁고 깊은 명령을 내릴 수 있습니다.

DDD는 대형 프로젝트를 AI가 소화 가능한 크기로 슬라이싱하는 전략 도구입니다.

여기서 한 가지 짚을 게 있습니다. 도메인 경계가 깔끔하게 나뉘는 프로젝트가 있고, 그렇지 않은 프로젝트도 있습니다. 검색 엔진처럼 책임이 분명한 시스템은 경계가 잘 나뉩니다. 다만 도메인 자체가 아직 불확실한 초기 탐색 단계의 프로젝트는 경계를 미리 긋는 게 오히려 발목을 잡을 수 있습니다. DDD는 도메인이 어느 정도 잡힌 다음에 힘을 발휘하는 도구입니다.

TDD(Test-Driven Development), AI의 폭주를 막는 안전벨트

바이브코딩의 가장 큰 축복은 속도지만 가장 큰 재앙은 AI가 쏟아내는 회귀 오류입니다. AI는 겉보기에 문법적으로 완벽한데 특정 에지 케이스에서 런타임 에러를 뿜거나, 잘 돌아가던 핵심 기능을 소리 없이 망가뜨리는 코드를 수십 줄씩 만들어냅니다.

이 폭주에 가드레일을 쳐주는 실천법이 TDD입니다.

타이퍼에서 검증자로

과거 TDD는 개발자가 로직을 구상하고 → 테스트를 짜고(Red) → 구현하고(Green) → 개선(Refactor)하는 수작업 반복이었습니다. 속도가 생명인 환경에서 환영받지 못한 이유입니다.

바이브코딩 시대의 TDD는 흐름이 바뀝니다.

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

개발자는 구현하려고 밤새 키보드를 두드리지 않습니다. 대신 "한국어 쿼리에서 형태소 분석이 적용된 BM25 점수와 BGE-M3 벡터 점수를 RRF로 융합했을 때, 정답 문서가 상위 5개 안에 들어오는지 검증하는 단위 테스트를 짜줘"라고 AI와 함께 가드레일을 먼저 만듭니다.

이후 구현은 AI에게 맡깁니다. AI가 개판으로 짜오든 기발하게 짜오든 상관없습니다. 도메인 규칙을 명시한 테스트 셋이 이미 존재하기 때문입니다. 테스트가 전부 Green이 되는 순간, AI가 작성한 코드를 의심 없이 배포할 확신을 얻습니다.

리팩토링의 두려움 제거

AI와 개발하다 보면 스파게티 코드가 양산되고 기술 부채가 쌓입니다. 코드가 복잡해지면 "기존 게 망가질까 봐 못 고치는" 현상이 생깁니다.

TDD가 구축된 환경에서는 리팩토링이 안전해집니다. "기존 검색 테스트를 전부 통과하는 상태를 유지하면서, 벡터 인덱스를 sqlite-vec에서 usearch HNSW로 교체해줘"라고 명령할 수 있습니다. AI가 인덱스 구조를 갈아엎으면 테스트 러너를 돌려 검증만 하면 됩니다. TDD는 AI라는 야생마를 길들이는 가드레일입니다.

다만 여기도 경계가 있습니다. TDD는 입력과 출력이 명확히 정의되는 영역에서 강력합니다. 검색 정확도, 파싱 결과, 데이터 변환 같은 영역이 그렇습니다. 반대로 출력이 주관적이거나 정답이 모호한 영역, 예를 들어 LLM이 생성한 위키 문서의 품질이나 UI의 사용감 같은 자리는 테스트로 가드레일을 치기 어렵습니다. 이런 영역은 여전히 인간의 눈이 검증자로 남아야 합니다. TDD가 모든 걸 자동으로 검증해주는 건 아닙니다.

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

과거의 애자일이 빛 좋은 개살구였던 근본 원인은 삼각형의 법칙(범위-시간-비용)을 무시하고, 기획이 바뀌는 속도를 개발자의 타이핑 속도가 따라가지 못했기 때문입니다. 기획자의 변덕은 개발자에게 유연함이 아니라 재앙이었습니다.

DDD로 맥락을 확보하고 TDD로 안전벨트를 맨 바이브코딩 시대의 애자일은 마침내 그 숙제를 풉니다.

요구사항 변경 비용의 하락

전통 공학에서 요구사항 변경이 후반부에 발생할수록 비용이 치솟는다는 건 상식이었습니다. 아키텍처가 꼬이고 데이터가 깨지고 사람이 다시 분석해야 했기 때문입니다.

바이브코딩 환경에서는 이 비용이 크게 낮아집니다.

과거에는 불가능했던 "기획을 바꾸고 피드백을 즉시 제품에 녹이는 반복 주기"가 개발자의 피를 말리지 않고 가능해졌습니다.

다만 AI가 구현 코드를 빨리 짜는 건 맞지만, 도메인을 정제하고 테스트를 설계하고 결과를 검증하는 작업에는 여전히 인간의 시간과 판단이 들어갑니다. 오히려 그 작업의 비중이 커집니다. 타이핑 비용이 사라진 자리를 설계와 검증 비용이 채우는 구조입니다. 변경의 병목이 타이핑에서 사고로 옮겨 갔습니다.

그래도 이 전환은 큽니다. 애자일이 더 이상 개발자를 쥐어짜는 도구가 아니라, 낮아진 구현 비용으로 비즈니스의 불확실성을 줄이고 실시간으로 진화하는 제품을 전달하는 전략이 됩니다.

삼위일체 실전 시나리오

DDD, TDD, 애자일, 바이브코딩이 실제로 어떻게 맞물리는지 구체적 시나리오로 봅니다.

AI 에이전트 세션을 검색하는 로컬 검색 엔진을 개발 중이라고 합시다. 어느 날 GitHub 이슈로 기능 제안이 들어옵니다.

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

과거라면 파서 전체를 다시 손봐야 하나 고민하며 며칠을 끌었을 시나리오입니다. 준비된 팀은 다르게 움직입니다.

Step 1: DDD로 명세화 및 격리

요청을 도메인 용어로 정제합니다. summary는 세션의 첫 실질 줄에서 추출하되 빈 줄과 인사는 건너뛴다, frontmatter는 YAML 이스케이프를 적용한다, 기존 vault 파일은 frontmatter 영역만 수정하고 본문은 불변. 이 명세를 파서 도메인의 타입 정의와 함께 AI에 주입합니다. 검색 코어나 vault 출력 도메인은 건드리지 않습니다.

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

AI에게 실패하는 테스트부터 짜게 합니다. 빈 줄로 시작하는 세션, 인사만 있는 세션, YAML 특수문자가 포함된 첫 줄. 이런 에지 케이스에서 summary가 제대로 추출되고 이스케이프되는지 검증하는 테스트 셋을 만듭니다. 구현이 없으니 당연히 Red입니다.

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

AI에게 바이브를 줍니다. "방금 만든 summary 추출 테스트를 통과하도록 ingest 파이프라인에 frontmatter 생성 로직을 붙여줘. 기존 reindex 흐름과 충돌하지 않게." AI가 수십 초 만에 구현을 짜냅니다. 테스트 러너를 돌리자 기존 테스트와 새 테스트가 전부 Green이 됩니다. 파서를 고쳤는데 검색 코어와 vault 출력이 망가지지 않았음이 증명된 순간입니다.

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

검증이 끝나면 머지하고 배포합니다. 이슈를 올린 사람에게 "제안 감사합니다. 바로 구현했습니다"라고 답하고, 추가로 기존 vault에 summary를 채우는 backfill 명령까지 제안합니다. 제안자가 또 다른 요청을 던져도 프롬프트 창을 열 뿐입니다.

개발 공학의 본질로

바이브코딩 시대의 도래는 소프트웨어 개발의 종말이 아닙니다. 단순 노동으로서의 타이핑이 끝나고 설계와 공학의 비중이 커진다는 신호입니다.

가짜 애자일이 빛 좋은 개살구에 머문 건 그것을 지탱할 아키텍처(DDD)와 검증 인프라(TDD), 구현 속도(AI)가 갖춰지지 않았기 때문입니다. 기술이 이상을 못 따라온 결과였습니다.

이제 무기는 어느 정도 갖춰졌습니다.

• DDD로 AI와 소통할 개념적 질서를 세웁니다

• TDD로 AI의 폭주를 통제할 가드레일을 만듭니다

• 그 위에서 AI라는 구현 엔진으로 불확실성을 돌파하는 애자일을 실현합니다

다만 이 세 가지가 만능은 아닙니다. DDD는 도메인이 잡힌 다음에 힘을 발휘하고, TDD는 정답이 명확한 영역에서 강하고, 애자일은 변경 비용을 낮출 뿐 없애지는 못합니다. 도구의 작동 영역과 한계를 같이 아는 사람이 도구를 도구로 씁니다.

타이핑의 병목이 사라진 자리에 설계와 검증과 판단이 남습니다. 그 남은 자리가 결국 인간의 일입니다. 맨땅에 헤딩하는 게 에이전틱 개발이 아닙니다. 인간의 도메인 지식과 AI의 지치지 않는 작업이 맞물리는 협업입니다. 개살구를 버리고 공학의 본질로 돌아갈 시간입니다.