바이브 코딩과 사양 주도 개발(SDD)은 데브옵스 팀이 AI를 사용해 애플리케이션 코드를 개발하는 두 가지 새로운 접근 방식이다. 다양한 사용 사례에 어떤 접근 방식을 사용할지에 대해서는 여러 의견이 있고, 많은 플랫폼이 서로 다른 기능과 경험을 제공한다. 신뢰할 수 있고 유지보수가 가능한 애플리케이션을 제공하는 AI의 능력에 의문을 제기하는 전문가도 있고 어느 시점이 되면 AI가 엔드투엔드 소프트웨어 개발 프로세스를 주도할 수 있게 될 것이라고 주장하는 전문가도 있다.

IT 기업이 직면한 한 가지 확실한 사실은 애플리케이션, 통합, 분석에 대한 수요가 애자일 팀과 데브옵스 엔지니어들의 공급 역량을 뛰어넘는다는 점이다. 여기에 애플리케이션 보안 취약점 해결, 클라우드를 위한 애플리케이션 현대화, 기술 부채 해소라는 비즈니스 우선순위까지 결합되면 이 불균형은 더욱 심화된다. 결과적으로 어떤 작업에 우선순위를 둘지, 그리고 소프트웨어 개발 수명 주기의 어느 부분에서 효율성 증대를 추구할지 선택하기가 어려워진다.

AI 코드 생성기가 등장하기 전에도 IT 리더들은 개발자 생산성을 높일 방법을 모색해 왔다. 4GL, 로우코드/노코드, 구성 가능한 SaaS와 같은 플랫폼은 IT 부서가 더 많은 애플리케이션을 제공하고, 개선 버전을 릴리즈하기 위해 필요한 개발자 스킬셋 부담을 낮추고, 소프트웨어 품질을 개선하는 데 도움이 됐다. 이와 같은 툴은 IT가 자바, 닷넷 및 기타 프로그래밍 언어로는 쉽게 또는 값싸게 빌드할 수 없는 온갖 종류의 애플리케이션과 분석, 통합을 개발할 수 있게 해준다.

도모(Domo)의 최고 설계 책임자이자 미래학자인 크리스 윌리스는 “소프트웨어는 오랫동안 인프라처럼 취급됐다. 즉, 장기간 지속성에 중점을 두었으며 변경하기 어렵고 교체 비용이 많이 들었다. 이제 더 작고 더 빠르게 빌드가 가능하고 특정 작업을 해결하기 위해 만들어진 애플리케이션으로 이뤄진 미래가 이 모델을 대체하고 있다”고 말했다.

코드 생성, 바이브, 또는 사양 작성

생성형 AI 모델은 소프트웨어 개발을 위한 차세대 가속기다. 최초의 툴은 코딩 지원을 위한 코파일럿이었고, 이후 LLM이 코드 스니펫을 생성했다. 필자는 앱 마이그레이션 작업에서 코드 생성 툴을 사용해 정규 표현식을 개발하고 웹 페이지에서 정보를 추출하고 데이터를 분류했다. 필자에게 직접 개발할 시간이나 기술이 없는 코드를 이런 툴을 통해 생성할 수 있었지만 코드의 결함과 통합 문제를 수정하기 위해서는 여전히 상당한 작업이 필요했다.

지금은 AI 소프트웨어 개발의 2세대로, 아마존 Q 디벨로퍼, 앱피안 AI 어시스티드 디벨롭먼트(Appian AI-Assisted Development), 볼트(Bolt), 클로드 코드, 클라인(Cline), 커서(Cursor), 제미나이 코드 어시스트, 깃허브 코파일럿, 키로(Kiro), 러버블(Lovable), 오픈AI 코덱스, 페이브(Pave), 레플릿(Replit)과 같은 플랫폼이 사용된다.

이 모든 플랫폼은 코드를 생성하지만 서로 다른 개발자 경험을 제공하고 서로 다른 종류의 작업에 사용된다. 플랫폼은 다음과 같은 3개의 범주로 분류할 수 있다.

• 코드 생성 툴 : 엔지니어의 요청에 따라 코드를 작성함으로써 개발자 경험을 강화하며, 많은 경우 기존 개발 툴에 통합된다.
• 바이브 코딩 : 반복적인 프롬프트 기반 경험을 통해 프로토타입, 기능, 프로덕션급 애플리케이션을 생성한다.
• 사양 주도 개발(SDD) : 개발 팀이 프롬프트를 통해 반복적으로 제품 요구사항을 설정하고 기타 설계 문서를 작성할 수 있도록 한 다음 이를 바탕으로 코드를 생성함으로써 애플리케이션 생성 전의 중간 단계를 만든다.

새로운 API를 개발하거나 기존 코드를 리팩터링하거나 워크플로우를 개선하거나 새로운 기능을 구축하는 경우에는 코드 생성기만으로 충분할 수 있다. 이때 개발자의 일은 코드를 작성하는 것에서 필요한 코드, 요구사항, 개발 플랫폼 및 기타 비기능적 수용 기준을 표현하는 것으로 바뀐다.

그러나 새로운 애플리케이션, 통합, 데이터 파이프라인 또는 강력한 웹 서비스를 개발하려는 경우라면 어떨까? 필자는 코드 생성을 넘어, 개발 팀이 애플리케이션을 빌드하고 지원하기 위해 바이브 코딩과 사양 주도 개발 플랫폼을 어떻게 사용할 수 있는지를 살펴보고자 했다.

바이브 코딩의 강점

바이브 코딩에서 개발자는 빌드하고자 하는 내용을 프롬프트로 입력하고 AI가 코드를 생성하는 과정을 지켜볼 수 있다.

볼트, 러버블, 레플릿과 같은 바이브 코딩 플랫폼은 프롬프트 하나로 개발을 시작할 수 있지만 개발자가 계획 모드를 사용할 경우 더 뛰어난 역량을 발휘한다. 계획 단계에서 바이브 코딩 플랫폼은 자신이 이해한 요구사항을 복창하고 요구사항을 더 정확히 파악하기 위해 질문하고 요구사항이 명시되지 않은 경우 선택지를 제안하기도 한다.

이런 플랫폼의 “바이브”란 아이디어에서 기능하는 애플리케이션으로 개발자가 빠르게 진전할 수 있도록 돕고자 하는 의지다. 개발자는 플랫폼에 프롬프트를 입력해서 요구사항을 다듬고 변경을 요청할 수 있다. 개발자뿐만 아니라 비즈니스 소유자, 비기술적 신생업체 창업자, 그리고 기타 시민 개발자들도 바이브 코딩을 하고 있다. 다만 이들은 보안 모범 사례를 먼저 배워야 한다.

벌쳐(Vultr)의 솔루션 엔지니어링 부사장인 던컨 응은 “바이브 코딩은 기업 내 여러 그룹에서 최소 기능 제품이나 소규모 툴을 만들 수 있게 해주며 이것이 생산성을 크게 높여준다. 잠재적 사용자에게 보여주고 제품의 시장 적합성에 대한 피드백을 받기 위한 개념 증명부터, 효율성과 속도를 위해 간소화할 수 있는 노동 집약적인 프로세스까지 그 사례는 다양하다”고 말했다.

바이브는 프로덕션 측면에서 실용성이 있는가?

개념 증명(POC)이나 최소 기능 제품은 개발자에게는 충분할 수 있지만, 바이브 코딩으로 만들어진 애플리케이션이 프로덕션 환경에 적합한지에 대해서는 의문의 여지가 있다. 젠팩트(Genpact)의 부사장이자 AI 실무 리더인 라제쉬 파드마쿠마란은 “바이브 코딩은 POC, 신속한 실험, 아이디어 탐색 과정의 속도를 높여주지만 결정론적 동작의 부재로 인해 장기간의 유지보수와 확장 또는 지원이 필요한 시스템에는 근본적으로 부적합하다”고 말했다.

이 부정적인 정서는 바이브 코딩만이 아니라 AI 생성 코드 전반을 향한다. 로우코드와 노코드 플랫폼도 초기에는 보안과 아키텍처, 성능, 운영 회복탄력성에 대해 비슷한 우려에 직면했다. 성공적인 플랫폼 업체들은 투명성을 통해 신뢰를 구축했으며, IT 부서는 로우코드 및 노코드 개발을 확장하는 데 필요한 구조와 프로세스, 문서화에 대해 학습했다. 바이브 코딩 플랫폼에서도 이와 비슷한 전환이 일어날 가능성이 높다.

알골리아(Algolia)의 최고 생태계 책임자인 퓨시 파텔은 “바이브 코딩은 실험의 속도를 높여주지만 명확한 아키텍처 제약, 관찰가능성, 성능 가드레일이 없으면 변동성을 초래하고, 이 변동성이 데브옵스 및 IT 운영의 다운스트림 시스템을 중단시킬 수 있다. CIO는 바이브 코딩을 프론트엔드 가속기로 취급하는 동시에 인간과 AI 모두를 위한 ‘프롬프트 계층’ 역할을 하는 잘 정의된 사양에 시스템을 고정해야 한다”고 말했다.

요구사항에서 시작하라

AI를 사용해 애플리케이션을 개발하는 또 다른 접근 방식은 사양 주도 개발이다. SDD 플랫폼은 곧바로 프롬프트로 뛰어들어 AI의 애플리케이션 개발을 조종하는 방식이 아니라 이 프로세스를 시프트 레프트해서 엔지니어가 요구사항을 문서화하도록 돕고, 요구사항이 문서화되면 이를 기반으로 애플리케이션을 개발한다.

AWS의 에이전틱 AI 부문 수석 엔지니어인 데이비드 야나첵은 “사양 주도 개발의 핵심은 구조와 책임성이다. 무엇을 원하는지, 바람직한 결과물은 어떤 형태인지 설명하면 시스템이 그 응답으로 요구사항, 기술 설계, 개발 작업의 세부 내역을 돌려준다”고 말했다.

야나첵은 AWS 키로(Kiro)의 개발 팀 자문이다. AI를 사용하지 않는 개발 프로젝트가 설계, 제품 요구사항 문서, 애자일 사용자 스토리부터 시작되는 것과 마찬가지로, SDD도 코딩에 들어가기에 앞서 비즈니스 및 기술 이해관계자들 간의 협업 필요성을 더 강화한다. 두 가지 성공적인 사례로, 3주 만에 프로덕션에 배포된 신약 발견 AI 에이전트, 그리고 한 기술 기업의 가속화된 클라우드 마이그레이션이 있다.

야나첵은 “이런 문서는 AI가 고품질 결과물에 집중하도록 한다. 개발자는 돌아가서 AI가 자신의 요청을 제대로 이행했는지 검증할 수 있다. 예를 들어 설계 문서는 코드 스니펫과 데이터베이스 스키마를 포함해 시스템의 동작을 자세히 기술한다. 시스템이나 기능이 어떻게 동작해야 하는지를 세부적으로 지정하면 에이전트는 더 나은 테스트를 더 많이 생성해 결과물을 검증할 수 있다”고 말했다.

기능적 요구사항과 비기능적 요구사항 모두에 대해 이해관계자와 협업하는 것이 중요하다는 점을 인식한 데브옵스 팀은 SDD 도입에 적극적이다.

패스틀리(Fastly)의 개발자 마케팅 선임 디렉터인 오스틴 스파이어스는 “사양 주도 개발은 바이브 코딩의 자연스러운 성숙이자 진화로, 여기서 팀은 에이전트의 컨텍스트 윈도우를 최대화하게 된다. 사양 주도 바이브 코딩은 엔지니어와 팀이 더 명확한 비전, 확고한 요구사항, 그리고 강력한 문서화 능력을 바이브 코딩의 초기 반복보다 더 우선시하도록 이끈다”고 말했다.

뉴 렐릭(New Relic)의 최고 기술 전략가인 닉 업체스는 “프로덕션 소프트웨어는 코딩으로 시작되지 않는다. 문제에 대해 생각하고 원하는 것이 무엇인지 파악해서 이를 팀과 소통하는 것부터 시작된다. 사양 주도 개발은 이와 같은 사고와 문서화 과정에 이름을 붙인 것으로, AI 툴을 팀으로 활용한다”고 말했다.

경쟁인가, 보완인가?

SDD와 바이브 코딩은 서로 경쟁하는 접근 방식일까? 기업은 서로 다른 두 가지 방법론을 지원하게 될까? 아니면 SDD가 바이브 코딩 경험이 진화된 형태일까? 디지털오션(DigitalOcean) 클라우드웨이즈(Cloudways) 부문 엔지니어링 선임 디렉터인 아야즈 아흐메드 칸은 “바이브 코딩과 사양 주도 개발은 서로 경쟁이 아니라 보완하는 접근 방식이며, 개발 수명 주기에서 각각의 역할을 한다. 탐색과 프로토타이핑에는 바이브 코딩을 사용하고 이를 구체화해서 출시할 때는 AI를 활용한 사양 주도 개발을 사용하면 된다. 생성형 AI로 성공하는 팀은 지속적인 피드백으로 AI를 명확하게 이끌어 프로덕션급 소프트웨어를 구축하는 팀”이라고 말했다.

바이브 코딩과 SDD가 각기 다른 비즈니스 요구와 구현 전략에 계속 기여하게 될 것이라는 전망도 있다. 튜고 테크놀로지(Tiugo Technologies)의 최고 기술 책임자인 빅토르 발크는 “바이브 코딩은 특히 유능한 에이전트 시스템과 결합될 때, 내부 툴이나 초기 POC와 같이 결함이 미치는 영향의 범위가 작은 사용자 대면 프로토타입에서 놀라운 속도를 제공한다. 그러나 대규모 프로덕션 환경, 분산 상태 또는 트랜잭션 무결성을 다루는 순간부터는 서비스 간의 사양 주도 계약이 더 유리해진다. 현재의 모델이 복잡한 시스템에 대해 추론할 수 없어서가 아니라, 프로덕션 크리티컬 인프라에 필요한 종류의 결정론적 정확성 보장을 제공하는 에이전틱 워크플로우가 아직 없기 때문”이라고 말했다.

탄력적인 릴리즈에 집중

계획과 코딩은 애플리케이션 구축과 지원에 포함된 많은 단계 중 두 가지일 뿐이다. 관찰가능성 구축, 모델 컨텍스트 프로토콜 서버 통합, 견고한 AI 에이전트 테스트 등 AI 에이전트 개발을 위한 소프트웨어 개발 수명 주기에는 AI를 사용할 다른 기회도 있다.

세계적인 수준의 IT 부서라면 애플리케이션 제공 과정에서 코딩 측면의 개선을 넘어, 바이브 코딩과 SDD가 어떻게 비즈니스 가치, 혁신, 신뢰를 이끄는지도 고려해야 한다. 비즈니스 요구사항을 충족하고 탁월한 사용자 경험을 제공하는 솔루션을 AI가 어느 정도까지 개발할 수 있는가?

페가시스템즈(Pegasystems)의 CTO이자 마케팅 및 기술 전략 부문 부사장인 돈 슈어먼은 “바이브 코딩과 사양 주도 개발 모두 비즈니스 및 IT 이해관계자들이 공통의 요구사항을 도출하는 어려운 단계가 이미 완료됐다고 전제한다. 특히 기업에서 AI를 활용하기 위해 핵심 워크플로우를 재창조, 재설계할 방법을 모색하는 상황에서는 이런 점이 더욱 두드러진다. AI의 진정한 기회는 단순히 코드 작성 속도를 높이는 것이 아니라 비즈니스 및 IT 팀이 진정으로 재창조된 애플리케이션을 위한 설계와 요구사항을 함께 생성할 수 있는 협업 캔버스를 제공하는 데 있다”고 말했다.

지금은 AI가 애플리케이션 개발과 개발자 생산성을 어떻게 가속화하는지에 대다수 관심이 집중돼 있다. 그러나 배포 프로세스, 그리고 AI가 개발한 애플리케이션을 실행하기 위한 인프라는 어떤 상황일까?

최근 두드러진 추세 중 하나는 클라우드 배포 인프라와 비즈니스 프로세스 자동화 서비스가 번들로 묶인 AI 애플리케이션 개발 플랫폼이다. 앱피안의 AI 어시스티드 디벨롭먼트는 비즈니스 인터페이스인 앱피안 컴포저(Composer), 그리고 클로드, 코덱스, 키로와 같은 개발 툴을 통해 사양 주도 개발을 지원한다. 페이브는 퀵베이스(Quickbase)와 동일한 보안 인프라에 배포해 그 거버넌스 기능을 활용하는 바이브 코딩 플랫폼이다. 이 두 가지 사례는 로우코드 개발과 프로세스 관리 플랫폼이 AI 기능을 포용하기 위해 어떻게 발전하고 있는지 잘 보여준다.

IT 리더를 위한 전문가의 조언은 코딩을 하든 바이브 코딩을 도입하든 SDD를 채택하든 회복탄력성이 있는 애플리케이션을 제공하는 데 중점을 둬야 한다는 것이다.

사리타사(Saritasa)의 개발 부문 디렉터인 세르게이 콘드라토프는 “바이브 코딩과 사양 주도 개발을 서로 대립시키기보다는 엔지니어링 규율과 시스템 설계에 집중해야 한다. 오늘날 AI 보조 개발의 성공 여부는 작업이 얼마나 잘 세분화되고 제어되는지에 따라 결정된다. 이 부분이 제대로 되지 않으면 두 접근 방식 모두 실패한다”고 말했다.

여전히 해결해야 할 과제로 AI가 생성한 코드의 품질과 AI가 생성한 애플리케이션의 유지보수 용이성을 지적하는 전문가도 있다.

애니스케일(Anyscale)의 CTO 크리스찬 스타노는 “사양 주도 개발은 팀이 올바른 비즈니스 및 기술적 성과를 지향하도록 하고, AI 코딩은 속도를 높인다. 중요한 것은 프로덕션 소프트웨어가 실제로 제공되는 인터페이스다. 여기서 검토 프로세스, 인프라, 가드레일이 보조를 맞출 수 있는지와 같은 실질적인 병목을 해결하는 데 집중해야 한다. 속도뿐만 아니라 팀이 신뢰성을 타협하거나 숨은 기술 부채를 쌓지 않으면서 속도를 높이고 있는지 여부도 핵심 지표로 살펴야 한다”고 덧붙였다.

데이터이쿠(Dataiku)의 575 랩 디렉터인 한스 햅키는 “바이브 코딩은 첫 데모까지의 시간을 단축해 주지만 부채와 보안, 감사가능성에 대한 우려가 크다. 사양 주도 개발은 규율을 유지하지만 오버헤드를 더한다. 핵심 기회는 두 가지를 혼합하는 데 있다. CIO는 속도만이 아니라 릴리즈 소요 시간, 버그 발생률, 리팩터링 빈도, 개발자 만족도를 통해서도 영향을 측정해야 한다”고 말했다.

바이브 코딩과 SDD가 앞으로 더 발전하게 된다는 점은 분명하고, 두 가지 관행이 일반화된 하나의 AI 코딩 환경으로 수렴될 가능성도 어느정도 있다. 한 가지 예로 깃허브의 스펙 킷(Spec Kit)이 있다. 스펙 킷은 깃허브 코파일럿, 클로드 코드, 제미나이 CLI와 함께 작동하며, 사양 작성을 바이브 코딩과 코드 생성의 전제 조건으로 다룬다.

AI의 개발 역량이 개선됨에 따라 IT 부서는 엔드투엔드 개발 프로세스를 어떻게 발전시킬지에 대해 고민하고, 새로운 역량이 단순히 속도와 생산성 향상 이상의 역할을 하도록 해야 한다.
dl-itworldkorea@foundryco.com