핵심 내용 요약
이 글은 기업의 “AI 원생 개발”(AI-native development) 실践을 중심으로 다루며, 기업이 AI 원생 개발을 추구할 때 왜 “소외감”을 느끼는지(개인은 AI를 사용해 효율성을 높일 수 있지만 조직 차원에서의 도입이 어렵다는 점)를 설명합니다. 그 후 SDD(Spec-Driven Development, 사양 기반 개발)라는 조직 차원의 AI 원생 솔루션을 소개하고, 프로젝트 재구조화를 통해 Spec-Kit과 BMAD라는 두 도구의 특징과 장단점을 비교합니다. 마지막으로 AI 원생 개발의 핵심은 협업 프로세스의 재조정에 있다고 강조합니다. 즉, 모든 직원이 AI 도구를 사용하는 것이 아니라, 팀 전체가 AI의 역량에 적응하도록 하는 것입니다.
1. 기업이 AI 원생 개발을 추구할 때 왜 “쿨하지 않다”고 느끼나요?
개인은 AI를 사용해 코드를 작성할 때 효율성이 크게 향상된다고 느끼지만, 기업이 AI 원생 개발을 추진할 때는 여러 가지 “비효율적인” 문제에 직면합니다:
- 권한은 어떻게 설정해야 할까요? 어떤 작업은 AI가 자동으로 처리할 수 있을까요? PR는 누가 검토해야 할까요?
- AI가 생성한 할 일 목록이 중복되면 어떻게 해야 할까요? 단일 테스트에 실패했을 때 책임은 누가 지어야 할까요?
- 자동 코드 병합 과정에서 문제가 발생하면 누가 책임져야 할까요? AI가 자료를 요청할 때 동료에게 불쾌감을 줄 수 있는 말투는 없을까요?
이러한 사소한 규칙과 보장 메커니즘들 때문에 기업은 AI 원생 개발을 “저효율적”이라고 생각할 수 있지만, 이는 필수적입니다. 개인에게는 “속도”가 중요하지만, 조직에게는 “안정적인 속도”가 더 중요합니다. 가끔의 놀라운 결과보다는 프로세스 내에서 AI가 오류 없이 작동하고 통제 가능한 것이 더 중요하기 때문에, 이러한 “비효율적인” 세부 사항들이 바로 AI 원생 개발의 핵심입니다.
2. AI 원생 개발의 핵심: “모든 직원이 AI를 사용하는 것”이 아니라, “AI가 협업에 참여하는 것”
많은 기업들이 “모든 직원이 ChatGPT를 사용해 코드를 작성하는 것”을 AI 원생 개발로 착각하지만, 이는 잘못된 생각입니다.
AI 원생 개발의 진정한 핵심은 AI를 팀의 업무 흐름, 협업 흐름, 배포 흐름에 통합하여 가상의 팀원으로 만드는 것입니다. 예를 들어, AI가 다음과 같은 역할을 할 수 있습니다:
- 그룹 채팅이나 로그를 자동으로 모니터링하고 문제를 식별하며 할 일 목록을 정리합니다.
- 코드를 작성할 수 있는 AI는 요구 사항을 생성하고, 코드를 수정하며, 테스트를 실행하고, PR을 제출합니다.
- 상황이 불분명할 때 책임자에게 자료를 요청합니다.
- 심지어 두 개의 모델을 사용해 저위험도 코드를 교차 검토하기도 합니다.
중요한 변화는 “AI가 코드를 작성해 줄 수 있을까?”에서 “AI가 어떤 기준에 따라 코드를 작성할까?”로의 전환입니다. AI에게 명확한 규칙, 요구 사항의 경계, 비즈니스 로직을 제공하여 안정적인 결과물을 만들어내도록 해야 합니다.
3. SDD: AI에게 규칙을 정하는 “사양 기반 개발”
SDD(Spec-Driven Development)는 AI에게 명확한 규칙을 제공하는 방법입니다. 즉, 명확한 “사양”(요구 사항, 계획, 작업 내용)을 사용하여 AI 개발을 이끌어내고, AI의 임의적인 판단을 방지합니다. GitHub의 Spec-Kit는 이러한 개념을 널리 알리는 데 기여했습니다.
주요 역할: AI에게 안정적인 환경(요구 사항의 경계, 코드 규칙, 비즈니스 제약 조건)을 제공하여 조직 차원에서의 AI 사용을 더 체계적으로 만들고, 재작업과 내부 갈등을 줄입니다. 예를 들어, Spec-Kit는 분산된 요구 사항, 계획, 작업 내용을 표준화하여 AI가 단계별로 작업할 수 있도록 합니다.
본질: AI를 “자유롭게 활동하는 도우미”에서 “규칙에 따라 일하는 직원”으로 전환시켜 팀 협업에 일관된 기준을 제공합니다.
4. Spec-Kit vs BMAD: 두 도구의 실제 사용 사례 비교
1. Spec-Kit: “고정된 프로세스 템플릿”과 같습니다.
- 특징: 프로세스가 명확하며(지정 → 계획 → 작업 → 구현), 표준화를 강제합니다. 단일 기능이나 팀의 기반 시설이 잘 갖춰진 경우(규칙이 있고, 여러 저장소가 관리되는 환경)에 적합합니다.
- 문제: 실제 프로젝트가 복잡할 때(여러 저장소, 다양한 역할이 필요한 경우), 많은 추가 메커니즘이 필요합니다(예: 여러 저장소 간의 호환성 처리, 접근 제어 등). 예를 들어, 작성자는 Spec-Kit을 사용할 때 AI가 프론트엔드와 백엔드 코드가 어디에 있는지 알 수 있도록 명령어를 직접 포장해야 하며, API 간의 충돌을 확인해야 합니다.
2. BMAD: “AI 가상 팀”과 같습니다.
- 특징: 제품 설계자, QA 등의 AI 역할이 내장되어 있으며, 다양한 역할 간의 협업을 통해 문제를 해결합니다. 예를 들어, 작성자가 코드를 재구조화할 때 온라인 전환이나 기존 시스템의 문제점을 발견하고 불필요한 요구 사항 13개를 제거하는 데 도움을 줍니다.
- 문제: 검토 작업량이 많으며 정신적 부담이 큽니다. 모든 세부 사항을 검토해야 하며, 자신이 잘 모르는 분야(예: 프론트엔드 개발자가 백엔드 계획을 검토하는 경우)에서 더 힘들 수 있으며, 초기 단계의 작업 시간이 인간 협업보다 길어질 수 있습니다.
5. 도구 선택은 팀 상황에 따라 결정해야 합니다:
- BMAD는 개인/소규모 팀, 역할이 부족한 경우(예: 아키텍트가 없는 경우)에 적합합니다. AI가 역량의 한계를 보완하는 데 도움을 줍니다.
- Spec-Kit은 팀의 역량이 뛰어나고 기반 시설이 잘 갖춰진 경우(규칙이 있고, 여러 저장소가 관리되는 환경)에 적합합니다. AI가 기존 시스템 내에서 효율적으로 작동할 수 있도록 도와줍니다.
결론적으로, AI 원생 개발은 단순한 도구의 집합이 아니라 협업 프로세스의 재조정입니다. 팀이 AI의 역량에 적응할 때만 AI의 효율성을 조직의 효율성으로 실제로 전환할 수 있습니다.