AI 에이전트 가속화와 '바이브 코딩'의 한계
AI 코딩 에이전트가 프롬프트를 통해 데이터 변환, 파이프라인, 오케스트레이션 워크플로우, 검증 테스트 및 인프라 설정을 자동으로 생성하며 데이터 엔지니어링 속도를 높이고 있다. 이처럼 직관과 프롬프트에 의존해 빠르게 구현하는 방식을 '바이브 코딩(Vibe Coding)'이라 한다. 하지만 기업용 데이터 플랫폼은 서로 다른 팀이 각기 다른 기술로 구축한 파편화된 시스템 위에서 작동하므로, 바이브 코딩의 확산은 오히려 비즈니스 로직의 불일치와 중복 구현, 숨겨진 의존성 문제를 심화시킨다.
바이브 코딩의 핵심 문제는 운영 컨텍스트와 아키텍처 결정 사항, 비즈니스 지식이 시스템 자체가 아닌 프롬프트, 대화 기록, 생성된 코드, 분리된 워크플로우 속에 흩어진다는 점이다. 엔지니어는 구현 과정에서 스키마 가정, 다운스트림 의존성, 운영 제약 조건, 디버깅 이력 등 방대한 배경 정보를 제공하지만, 이 정보들은 일회성 프롬프트에 머문다. 결과적으로 시스템은 구축된 이유와 논리적 근거에 대한 '기억'을 상실하며, 이는 다운스트림 의존성 파악과 검증 가정 확인을 어렵게 만든다.
프롬프트는 본질적으로 일시적인 아티팩트다. 동일한 프롬프트라도 미래의 다른 컨텍스트에서는 동일한 구현물을 생성한다는 보장이 없으며, CI/CD(지속적 통합/지속적 배포) 워크플로우를 통한 체계적인 검증이나 점진적인 진화가 어렵다. 구현 속도는 빨라지지만, 인간의 검증과 도메인 지식, 조율 과정에 여전히 의존해야 하므로 전체 엔지니어링 효율은 비례해서 상승하지 않는다.
명세 기반 개발(SDD)의 구조와 작동 방식
명세 기반 개발(Spec-driven Development, 이하 SDD)은 프롬프트와 비즈니스 규칙, 검증 로직, 오케스트레이션 동작을 실행 가능하고 버전 관리가 가능한 '명세(Specification)'로 변환해 시스템의 일부로 통합하는 방식이다. 이는 인프라 코드화(Infrastructure-as-Code)와 GitOps(깃옵스, Git 저장소를 단일 진실 공급원으로 삼는 운영 방식)의 개념을 AI 보조 엔지니어링으로 확장한 것이다.
SDD는 선언적 시스템 정의(Declarative layer)와 실행 가능한 구현 워크플로우(Workflow-oriented instructions)의 결합으로 작동한다. 선언적 레이어는 시스템 컨텍스트, 스키마, 의존성, 제약 조건을 제공하며, 워크플로우 지침은 AI 에이전트가 시스템을 일관되게 구현하고 발전시키는 가이드 역할을 한다. 이러한 명세는 저장소에 저장되어 버전 관리되며 CI/CD 워크플로우에 통합되어 시스템의 '영구적인 운영 메모리'로 기능한다.
SDD의 구조는 프로젝트 전반의 기술 표준, 명명 규칙, 아키텍처 규칙, 거버넌스 정책을 정의하는 '헌법(Constitution)'을 기초로 하며, 그 위에 다음과 같은 계층적 명세를 둔다.
- 스키마 명세(Schema specifications): 구조적 호환성 정의
- 변환 명세(Transformation specifications): 비즈니스 로직 정의
- 검증 명세(Validation specifications): 품질 규칙 정의
- 오케스트레이션 명세(Orchestration specifications): 실행 동작 정의
- 시맨틱 명세(Semantic specifications): 공유 비즈니스 정의
- AI 워크플로우 명세(AI workflow specifications): 코딩 에이전트를 위한 재사용 가능한 구현 지침
실제 적용 시 명세는 다음과 같은 단순한 형태로 정의될 수 있다.
yaml
- load_strategy: scd2
- primary_key: order_id
이후 AI 에이전트는 위 명세를 바탕으로 다음과 같은 구체적인 워크플로우를 수행한다.
- Salesforce 고객 데이터용 Python 수집 코드 생성
- Type 2 SCD(Slowly Changing Dimension) 로직을 구현한 DBT(Data Build Tool) 모델 생성
- 시간 단위 실행을 위한 Airflow 워크플로우 생성
- 다운스트림 호환성을 위한 검증 테스트 생성
실무 도입 시 판단 기준과 운영 변화
개발자와 실무자가 SDD를 도입할 때 가장 먼저 바꿔야 할 지점은 프롬프트를 '도구'가 아닌 '시스템 계약(Contract)'으로 보는 관점이다. 기존의 바이브 코딩이 '프롬프트 최적화'에 집중했다면, SDD는 '명세의 정밀도와 관리'에 집중한다. 명세는 개발 후 작성하는 수동적인 문서가 아니라, 코드 생성과 검증, 배포를 직접 구동하는 운영 계약서로 취급되어야 한다.
운영 측면에서는 명세를 마크다운(Markdown) 기반의 운영 아티팩트로 유지하며, AI 보조 워크플로우를 통해 이를 반복적으로 정제하는 프로세스를 구축해야 한다. 엔지니어는 AI와 협업하여 명세를 업데이트하고 비즈니스 컨텍스트를 추가함으로써 구현 로직과 프롬프트 지침을 지속적으로 개선한다. 이는 전통적인 문서화 과정보다 효율적이며, AI 에이전트가 시스템의 설계 의도와 결정 이유를 정확히 파악하게 하여 릴리스나 팀 변경 시에도 일관성을 유지하게 한다.
결과적으로 SDD 도입 시 실무자는 단순 구현 속도보다 '반복 가능성(Iterability)'과 '거버넌스(Governance)'를 우선순위에 두어야 한다. 프롬프트에 매몰된 지식을 버전 관리 가능한 명세로 추출해 CI/CD 파이프라인에 태우는 작업이 선행되어야만, AI가 생성한 데이터 플랫폼의 파편화를 막고 장기적인 유지보수 효율을 확보할 수 있다.
