바이브 코딩을 넘어 AI 주도형 개발 패러다임의 도래와 인간-AI 협력의 미래

1. 서론: ‘바이브 코딩’ 비관론의 근원과 새로운 패러다임의 제언

본 보고서는 ’바이브 코딩(Vibe Coding)’에 대한 현재의 지배적인 비관론이 ’사용자의 미숙한 요구사항 전달’이라는 단방향 소통의 근본적 한계에서 비롯된다는 핵심적 문제의식에서 출발한다. 사용자는 인공지능(AI)이 단순히 지시를 이행하는 수동적 도구에 머무는 것이 아니라, 스스로 개발 계획을 수립하고 부족한 요구사항을 능동적으로 질의하며 사용자와 대화하는 새로운 시대가 도래할 것이라는 선구적인 가설을 제시했다. 이는 현재의 AI 코딩 패러다임이 가진 문제의 본질을 정확히 꿰뚫고, 그 해결책을 위한 구체적인 방향성을 제시하는 통찰력 있는 주장이다. 본 보고서는 이 가설을 학술적 연구와 산업계 동향을 바탕으로 심층적으로 검증하고, 그 기술적 실현 가능성과 미래상을 구체화하는 것을 목표로 한다.

보고서의 구조는 총 4개의 장으로 구성된다. 제1장에서는 현행 바이브 코딩의 명확한 정의와 그 이면에 존재하는 본질적 한계를 다각도로 분석한다. 특히, 사용자의 모호한 지시가 어떻게 기술 부채, 보안 취약점, 신뢰성 저하라는 구체적인 위험으로 이어지는지를 상세히 규명한다. 제2장에서는 논의의 이론적 기반을 다지기 위해, 소프트웨어 공학의 수십 년 역사를 관통하는 불변의 원칙인 ’요구사항 명세’의 절대적 중요성을 고찰한다. 이를 통해 현재의 문제가 기술의 미성숙이 아닌, 공학적 원칙의 부재에서 비롯됨을 명확히 한다.

제3장에서는 사용자의 가설을 본격적으로 탐구하며, AI가 개발의 주도권을 쥐고 사용자와 양방향으로 소통하는 ’AI 주도형 개발 모델’의 부상을 논증한다. 수동적 조수에서 능동적 행위자로 진화하는 ’에이전틱 AI(Agentic AI)’의 개념을 소개하고, AI가 명확화 질문을 통해 요구사항을 도출하는 새로운 상호작용 모델의 작동 원리를 구체적으로 제시한다. 마지막으로 제4장에서는 이러한 미래를 구현할 AI 에이전트의 기술적 아키텍처와 당면 과제를 상세히 분석한다. 다중 에이전트 협업 프레임워크와 같은 구체적인 구현 모델을 살펴보고, 신뢰와 통제, 그리고 AI가 생성한 코드의 검증 문제 등 해결해야 할 과제를 심도 있게 논의한다. 이를 통해 본 보고서는 단순한 미래 예측을 넘어, 다가올 패러다임 전환에 대비하기 위한 구체적인 기술적 청사진과 전략적 방향을 제시하고자 한다.

2. 현행 패러다임의 명암: ’바이브 코딩’의 본질과 한계

2.1 ’바이브 코딩’의 정의와 부상 배경

’바이브 코딩’은 개발자가 자연어 프롬프트를 통해 인공지능의 도움을 받아 기능 코드를 생성하는 새로운 소프트웨어 개발 방식을 지칭하는 신조어다.1 이 용어는 2025년 2월, OpenAI의 공동 창립자이자 전 테슬라 AI 책임자인 안드레이 카르파티(Andrej Karpathy)가 처음 제안하며 널리 알려졌다.3 그는 AI와 대화하듯 소프트웨어를 만드는 과정을 “코딩의 흐름에 몸을 맡기는 것“이라 표현하며 ’Vibe Coding’이라 명명했다.3 이는 전통적인 코딩 방식이 요구하는 엄밀한 논리나 사전 설계보다는, 직관과 느낌(‘Vibe’)에 의존하여 창의적이고 자유롭게 소프트웨어를 만들어나가는 접근법을 상징한다.3

바이브 코딩의 등장은 소프트웨어 개발 패러다임에 중대한 변화를 예고하며 큰 기대를 모았다. 가장 큰 장점은 개발 속도의 혁신적인 향상이다.6 AI가 반복적이고 정형화된 코딩 작업을 대신 처리해주면서, 개발자는 제품 설계, 아키텍처 구상, 비즈니스 로직 최적화 등 보다 창의적이고 고차원적인 문제 해결에 집중할 수 있게 되었다.2 이는 특히 스타트업이나 1인 개발자에게 강력한 무기가 된다. 최소 기능 제품(MVP, Minimum Viable Product)의 개발 속도를 획기적으로 단축시켜, 적은 인력과 자원으로도 빠르게 시장의 반응을 살피고 경쟁 우위를 확보할 수 있는 기회를 제공한다.6 실제로 2025년 와이콤비네이터(YC) 겨울 배치에 참여한 스타트업의 25%가 코드베이스의 95%를 AI로 작성했다고 보고될 정도로 그 영향력은 빠르게 확산되고 있다.3

더 나아가 바이브 코딩은 소프트웨어 개발의 진입 장벽을 극적으로 낮추는 역할을 한다.2 프로그래밍 언어의 복잡한 문법이나 구조를 알지 못하는 비전문가도 자연어로 원하는 기능을 설명하기만 하면 아이디어를 현실화할 수 있게 된 것이다.7 이는 소프트웨어 개발을 소수 전문가의 영역에서 모두의 영역으로 확장시키는 민주화의 가능성을 내포한다. 이처럼 바이브 코딩은 생산성 극대화와 접근성 향상이라는 두 가지 강력한 가치를 앞세워 차세대 개발 방식으로 각광받기 시작했다.2

2.2 비관론의 핵심: 단방향 지시와 요구사항의 모호성

그러나 이러한 장밋빛 전망에도 불구하고, 바이브 코딩에 대한 비관론은 빠르게 주류 의견으로 자리 잡았다. 그 근본적인 원인은 기술 자체의 결함이 아니라, ’인간-AI 상호작용 모델’의 근본적인 설계 실패에 있다. 현재의 바이브 코딩은 사용자가 AI에게 일방적으로 지시를 내리고 AI는 그 지시를 수동적으로 수행하는 ‘명령-실행(Command-Execution)’ 모델에 기반한다. 이 모델이 성공적으로 작동하기 위한 전제 조건은 ’사용자가 자신의 요구사항을 명확하고, 완전하며, 모순 없이 전달할 수 있어야 한다’는 것이다. 하지만 현실은 이와 정반대다. 대부분의 사용자는 자신이 무엇을 원하는지 정확히 알지 못하거나, 알더라도 그것을 구조화된 언어로 표현하는 데 극도로 미숙하다. 이것이 바로 사용자의 질의에서 정확히 지적한 비관론의 핵심 원인이다.

이 문제는 현재 AI 어시스턴트가 가진 본질적인 한계와 맞물려 증폭된다. 현재의 AI 코딩 어시스턴트는 스스로 목표를 설정하거나 사용자의 모호한 지시 이면에 숨겨진 의도를 추론하는 능력이 현저히 부족하다. 이들은 행동을 취하기 위해 명확하고 구체적인 프롬프트가 반드시 필요하다.8 예를 들어, AI는 ’X와 Y를 비교하는 표를 생성하라’는 명시적 지시가 없으면 스스로 비교 분석을 수행하지 않는다.8 또한, 대화형 AI는 장기 기억(long-term memory)에 한계가 있어, 대화가 길어지면 이전의 중요한 맥락을 잊어버리고 비일관적인 결과를 내놓는 경우가 많다.5 하나의 채팅창에 너무 많은 로그가 쌓이면 성능이 저하되는 현상도 이러한 한계를 방증한다.5

결론적으로, 사용자의 불완전하고 추상적인 지시와 AI의 수동적이고 맥락 이해가 부족한 특성이 결합되면서 최악의 결과를 낳는다. “근사한 로그인 페이지를 만들어줘“와 같은 추상적인 명령이 담긴 프롬프트는 LLM이 아무리 정교해진다 한들 해결해 줄 수 없는 근본적인 한계를 내포하고 있다.5 AI는 사용자의 불완전한 지시를 바탕으로 ‘추측에 기반한’ 코드를 생성할 수밖에 없으며, 이는 필연적으로 소프트웨어의 품질 저하와 예측 불가능한 오류로 이어진다. 따라서 현재의 비관론은 AI의 코드 생성 능력이 부족하다는 것이 아니라, AI가 사용자의 모호한 의도를 명확한 ’요구사항’으로 변환하는 과정이 시스템적으로 부재하다는 점에서 기인한다. 이는 기술적 한계를 넘어선 패러다임의 한계이며, 해결책은 더 나은 코드 생성 AI를 만드는 것이 아니라, AI가 요구사항을 정의하는 과정에 능동적으로 참여하는 새로운 상호작용 모델을 설계하는 데에 있다.

2.3 모호한 요구사항이 초래하는 구체적 위험

사용자의 불완전하고 모호한 요구사항에 기반한 바이브 코딩은 단순히 결과물의 품질이 낮은 수준을 넘어, 프로젝트 전체를 실패로 이끌 수 있는 심각하고 구체적인 위험들을 내포하고 있다.

첫째, 기술 부채(Technical Debt)의 누적이다. 소프트웨어 개발에서 ’기술 부채’란, 당장의 빠른 개발을 위해 최선이 아닌 손쉬운 방식을 선택했을 때, 중장기적으로 발생하게 될 재작업 비용을 의미한다.9 사용자의 불완전한 지시로 생성된 코드는 당장은 그럴듯하게 작동하는 것처럼 보일 수 있다. 그러나 그 내부에는 구조적 결함, 비효율적인 알고리즘, 확장성을 고려하지 않은 설계 등 수많은 잠재적 문제들이 숨어 있을 가능성이 높다.10 AI 시스템을 구현하는 전체 소스코드 중 AI 알고리즘 자체의 비중은 단 5%에 불과하며, 나머지 95%는 이를 지원하기 위한 소프트웨어라는 점을 상기할 필요가 있다.9 이 95%의 영역을 체계적인 설계 없이 AI 생성 코드 조각들로 채워 넣는 것은 미래에 천문학적인 유지보수 비용을 초래하는 기술 부채를 쌓는 행위와 같다.

둘째, 보안 취약점(Security Vulnerabilities)의 내재화다. 소프트웨어 개발 경험이 부족한 사용자는 보안 관련 요구사항을 명시적으로 프롬프트에 포함시키는 경우가 거의 없다. 이 경우 AI는 보안을 전혀 고려하지 않은, 심각한 취약점을 가진 코드를 생성할 가능성이 매우 높다.11 실제로 바이브 코딩으로 작성된 코드에서 SQL 인젝션(SQL Injection)이나 크로스 사이트 스크립팅(XSS, Cross-Site Scripting)과 같은 고전적이고 치명적인 보안 취약점이 발견되는 사례는 비일비재하다.5 GitHub Copilot과 같은 도구들도 생성된 코드가 구문적으로는 올바를지라도 항상 안전하지는 않다는 점을 명시하며, 하드코딩된 비밀번호나 SQL 삽입 취약점과 같은 위험을 경고하고 있다.13 보안 사고 발생 시 그 책임은 전적으로 개발자와 운영자에게 돌아가므로, 이는 결코 간과할 수 없는 치명적인 위험이다.5

셋째, AI 할루시네이션(Hallucination)과 코드의 비신뢰성 문제다. 대규모 언어 모델(LLM)은 학습 데이터에 존재하지 않거나 잘못된 정보를 기반으로, 마치 사실인 것처럼 그럴듯한 거짓 정보를 생성하는 ‘할루시네이션’ 현상을 보인다. 이는 코드 생성 시에도 마찬가지로 발생하여, 존재하지 않는 라이브러리나 함수를 호출하거나, 문맥에 맞지 않는 잘못된 로직을 가진 코드를 생성하는 결과로 이어진다.15 이러한 현상은 모델 학습에 사용된 데이터의 품질 문제, 확률적 샘플링에 기반한 모델의 생성 방식, 그리고 사용자의 부정확한 프롬프트 등 복합적인 원인에 기인한다.17 할루시네이션으로 생성된 코드는 예측 불가능한 오류를 유발하며, 생성된 코드 자체의 신뢰성을 근본적으로 훼손한다.

마지막으로, 전반적인 코드 품질 저하와 유지보수의 난제다. AI 코딩 도구에 과도하게 의존할 경우, 개발자는 손쉽게 코드를 생성하고 복사-붙여넣기 하는 습관에 빠지기 쉽다. 이는 프로젝트 전반에 걸쳐 중복 코드를 양산하고 코드의 복잡성을 증가시켜, 결국 전체적인 코드 품질을 심각하게 저하시키는 결과를 낳는다.19 특히, 구조 없이 뒤얽힌 ’스파게티 코드’는 유지보수를 악몽으로 만든다. 수만 줄이 넘어가는 스파게티 코드는 인간 개발자는 물론이고 현재의 AI조차 효과적으로 리팩토링하기 매우 어렵기 때문에, 프로젝트를 회복 불가능한 상태로 만들 수 있다.5 이 모든 위험들은 결국 ’부정확하고 불완전한 요구사항’이라는 단 하나의 공통된 원인으로 귀결된다.

3. 불변의 원칙: 소프트웨어 공학における 요구사항 명세의 절대적 중요성

3.1 요구사항 명세서(SRS)의 역할과 가치

바이브 코딩이 직면한 문제의 근원을 이해하기 위해서는, 시선을 잠시 AI라는 최신 기술에서 돌려 소프트웨어 공학의 가장 근본적인 원칙으로 향할 필요가 있다. 그것은 바로 ’요구사항 명세(Requirements Specification)’의 중요성이다. 요구사항 명세서(SRS: Software Requirements Specification)는 개발하고자 하는 소프트웨어의 기능, 성능, 제약 조건, 외부 인터페이스 등 모든 요구사항을 상세하고 명확하게 기술한 공식 문서를 의미한다.20

SRS는 단순한 문서가 아니다. 이는 프로젝트에 참여하는 모든 이해관계자—고객, 기획자, 설계자, 개발자, 테스터—가 공유하는 단 하나의 ’진실의 원천(Single Source of Truth)’이다. 건축에 비유하자면, SRS는 건물을 짓기 전에 모든 관계자가 합의하고 검토를 마친 ’종합 설계도’와 같다.22 이 설계도 없이는 각자가 상상하는 모습대로 건물을 짓게 되어 결국 기둥과 벽이 맞지 않는 기형적인 결과물이 탄생할 수밖에 없다. 마찬가지로, 명확한 SRS가 없다면 개발팀은 무엇을 만들어야 할지 정확히 알지 못한 채 추측에 의존해 개발을 진행하게 되고, 이는 결국 고객의 기대와 전혀 다른 소프트웨어를 만드는 결과로 이어진다.

따라서 SRS는 프로젝트 성공의 초석과도 같은 역할을 수행한다. 첫째, 명확한 SRS는 이해관계자 간의 오해를 줄여 불필요한 의사소통 비용을 획기적으로 절감한다.23 둘째, 개발해야 할 과업의 범위와 규모를 정량적으로 정의해주기 때문에, 이를 기반으로 정확한 비용과 일정을 산정할 수 있다.21 셋째, 완성된 소프트웨어가 요구사항을 제대로 충족했는지 검증하고 테스트하는 명확한 기준이 된다.25 수많은 소프트웨어 프로젝트가 실패하는 가장 큰 원인은 기술적 어려움이 아니라, 바로 이 ’요구사항의 불일치와 변경’에 있다. 국내의 많은 공공 SI 프로젝트가 초기에 애매한 제안요청서(RFP)로 시작하여 프로젝트가 진행되면서 요구사항이 계속 바뀌고, 결국 예산과 기간을 초과하며 실패로 끝나는 악순환을 반복하는 것도 SRS의 중요성을 간과한 대표적인 사례다.21

3.2 기능적 요구사항과 비기능적 요구사항

성공적인 SRS를 작성하기 위해서는 요구사항을 두 가지 핵심적인 범주로 나누어 이해해야 한다: 기능적 요구사항과 비기능적 요구사항이다.

**기능적 요구사항(Functional Requirements)**은 시스템이 사용자에게 ‘무엇을(What)’ 제공해야 하는지, 즉 어떤 구체적인 기능을 수행해야 하는지에 대한 명세다.24 예를 들어, 쇼핑몰 애플리케이션을 개발한다면 “사용자는 ID와 비밀번호를 입력하여 로그인할 수 있어야 한다”, “사용자는 상품을 검색하고 카테고리별로 필터링할 수 있어야 한다”, “관리자는 상품을 추가, 수정, 삭제할 수 있어야 한다“와 같은 것들이 기능적 요구사항에 해당한다.20 이는 시스템의 핵심적인 동작과 서비스를 정의하는 부분으로, 비교적 명확하게 식별하고 기술하기 용이하다.

반면, **비기능적 요구사항(Non-functional Requirements)**은 시스템이 특정 기능을 ‘어떻게(How)’ 수행해야 하는지에 대한 품질 속성(Quality Attributes) 및 제약 조건(Constraints)을 정의한다.23 이는 시스템의 ’성능’과 직결되는 중요한 부분이지만, 종종 간과되기 쉽다. 비기능적 요구사항의 주요 범주는 다음과 같다 22:

• 성능(Performance): “웹페이지는 3초 이내에 로드되어야 한다”, “시스템은 초당 1000개의 트랜잭션을 처리할 수 있어야 한다.”
• 보안(Security): “사용자의 비밀번호는 단방향 암호화하여 저장해야 한다”, “모든 데이터 통신은 SSL/TLS를 통해 암호화되어야 한다.”
• 신뢰성 및 가용성(Reliability & Availability): “시스템은 1년 365일, 하루 24시간 중단 없이 운영되어야 한다 (가용성 99.99%).”
• 사용성(Usability): “사용자는 세 번의 클릭 이내에 원하는 기능을 찾을 수 있어야 한다.”
• 유지보수성(Maintainability): “코드는 특정 코딩 컨벤션을 준수해야 하며, 모듈화된 구조로 설계되어야 한다.”

1장에서 지적한 바이브 코딩의 실패 사례들—느린 성능, 심각한 보안 취약점, 스파게티 코드로 인한 유지보수 불가—은 본질적으로 이러한 ’비기능적 요구사항’의 명세가 완전히 누락되었기 때문에 발생하는 문제다.

3.3 AI 시대, 왜 다시 요구사항 공학인가?

AI가 코드를 자동으로 생성해주는 시대가 도래하면, 복잡하고 지난한 요구사항 정의 과정은 더 이상 필요 없게 될 것이라는 예측이 있었다. 그러나 현실은 정반대의 방향을 가리키고 있다. AI 코딩 시대는 요구사항 공학의 중요성을 약화시키는 것이 아니라, 역설적으로 그 중요성을 역사상 그 어느 때보다 극대화하고 있다. AI는 구현(Implementation)의 부담을 인간에게서 덜어주었지만, 그 대신 명세(Specification)의 책임을 더욱 무겁게 만들었다.

이러한 패러다임의 전환은 다음과 같은 논리적 귀결을 낳는다. 첫째, AI는 ’구현’을 자동화한다.1 이는 개발자의 역할이 코드를 한 줄 한 줄 타이핑하는 구현 작업에서 벗어나, 무엇을 만들 것인지를 결정하는 상위 레벨의 ’설계’와 ’기획’으로 이동해야 함을 의미한다.2 둘째, 설계와 기획의 핵심은 ’무엇을 만들 것인가’를 정의하는 것이고, 이는 곧 요구사항을 정의하고 명세하는 활동과 정확히 일치한다. 따라서 AI가 구현을 더 빠르고 정확하게 처리할수록, 인간은 그 AI에게 지시할 ’요구사항’을 더욱 정밀하고 완전하게 정의해야 하는 압박을 받게 된다.

결론적으로, AI 시대의 핵심 역량은 ’코드를 잘 짜는 능력’이 아니라 ’요구사항을 정밀하게 정의하고 검증하는 능력’으로 전환된다. 이는 소프트웨어 개발 조직의 구조와 역할 분담에도 근본적인 변화를 예고한다. ’프롬프트 엔지니어’라는 새로운 역할은 단순히 AI에게 명령을 잘 내리는 기술을 넘어, 도메인 전문가와 긴밀히 협력하여 비즈니스 목표로부터 기능적/비기능적 요구사항을 체계적으로 추출하고, 이를 AI가 오해 없이 이해할 수 있는 형태로 정제하는 ’AI 시대의 요구사항 분석가’로 진화해야 한다. 미래의 개발자는 코드를 작성하는 사람이 아니라, AI 개발 에이전트들로 구성된 팀을 이끄는 ‘프로덕트 매니저’ 또는 ’시스템 아키텍트’의 역할을 수행하게 될 것이다. 이들의 핵심 업무는 비즈니스 목표를 정밀한 요구사항으로 변환하고, AI가 생성한 결과물이 그 요구사항을 완벽하게 충족하는지 검증하는 것이 될 것이다. 다만, 요구사항을 정의하고 명세하는 ’방식’은 과거의 정적인 문서(Static Document)에서 벗어나, AI와 동적으로 상호작용하는 대화(Dynamic Conversation)의 형태로 전환될 필요가 있다.

4. 패러다임의 전환: AI 주도형 개발의 서막

4.1 수동적 조수에서 능동적 행위자로: 에이전틱 AI(Agentic AI)의 등장

1장과 2장에서 분석했듯이, 현행 바이브 코딩의 한계는 AI가 사용자의 지시를 수동적으로 기다리는 단방향 상호작용 모델에서 비롯된다. 이 근본적인 문제를 해결하기 위한 기술적 돌파구가 바로 ’에이전틱 AI(Agentic AI)’의 등장이다. 에이전틱 AI는 기존의 AI 어시스턴트와는 개념적으로 차원을 달리한다. 기존 어시스턴트가 사용자의 명시적인 명령이 있어야만 작동하는 ’도구’에 가까웠다면, 에이전틱 AI는 높은 수준의 목표를 부여받으면 스스로 세부 계획을 수립하고, 필요한 도구를 활용하며, 주변 환경과 상호작용하여 과업을 완수하는 ’자율적 행위자(Autonomous Agent)’다.26

에이전틱 AI의 핵심 능력은 다음과 같은 요소들로 구성된다 27:

• 목표 분해(Goal Decomposition): “사용자 인증 시스템 구축“과 같은 복잡하고 추상적인 목표를 “데이터베이스 스키마 설계”, “회원가입 API 구현”, “로그인 UI 개발”, “보안 정책 적용” 등 구체적이고 실행 가능한 하위 작업들로 스스로 분해한다.
• 순차적 추론(Sequential Reasoning): 분해된 하위 작업들의 논리적 선후 관계를 파악하고, 최적의 순서로 작업을 배열하여 전체적인 계획을 수립한다.
• 외부 도구 사용(Tool Use): 계획을 실행하는 과정에서 코드 에디터, 컴파일러, 디버거, 버전 관리 시스템(Git), API 등 외부 도구를 능동적으로 호출하고 그 결과를 활용한다.
• 자율성(Autonomy): 일단 목표가 주어지면, 최소한의 인간 개입만으로 전체 프로세스를 주도적으로 이끌어 나간다.

이러한 특성들은 여러 단계에 걸쳐 복잡한 의사결정이 요구되는 소프트웨어 개발 과업에 이상적인 모델을 제공한다. 에이전틱 AI의 등장은 인간과 AI의 관계를 ’사용자-도구’에서 ’협력 파트너’로 재정의하며, 소프트웨어 개발 패러다임의 근본적인 전환을 이끌고 있다.28

4.2 새로운 상호작용 모델: AI가 질문하고 사용자가 답하다

사용자가 예측한 미래, 즉 AI가 개발 계획을 수립하고 부족한 요구사항을 질의하는 시대는 바로 이 에이전틱 AI가 소프트웨어 개발 프로세스에 적용되는 모습이다. 이 새로운 모델에서 AI는 더 이상 사용자의 불완전하고 모호한 명령을 맹목적으로 수행하지 않는다. 대신, 주어진 개발 목표를 성공적으로 달성하기 위해 스스로 부족한 정보를 파악하고, 그 공백을 메우기 위해 사용자에게 ’명확화 질문(Clarifying Questions)’을 적극적으로 던진다.29

이 새로운 상호작용 모델의 작동 메커니즘은 ’Q&A 프롬프트 전략’과 매우 유사하다.31 사용자가 “우리 웹 애플리케이션을 위한 사용자 인증 시스템을 구축해야 한다“는 초기 목표를 제시하면, AI는 즉시 코드를 생성하는 대신 다음과 같은 일련의 명확화 질문을 되묻는다:

• “어떤 프로그래밍 언어와 프레임워크를 사용하고 있습니까?”
• “이메일/비밀번호 기반 인증 외에 구글, 페이스북과 같은 소셜 로그인이 필요합니까?”
• “비밀번호 재설정 기능이나 다중 인증(MFA)과 같은 추가적인 보안 기능을 구현해야 합니까?”
• “GDPR이나 CCPA와 같이 준수해야 할 특정 개인정보 보호 규정이 있습니까?”
• “예상되는 동시 접속자 수는 몇 명이며, 이에 따른 성능 요구사항은 무엇입니까?” 31

사용자는 이러한 질문에 답하는 과정을 통해, 자신도 미처 생각하지 못했던 중요한 요구사항들을 구체화하게 된다. 이 대화의 결과로, 2장에서 논의된 기능적 요구사항(소셜 로그인, 비밀번호 재설정)과 비기능적 요구사항(보안 규정 준수, 성능 목표)이 자연스럽게 명세화된다. AI는 이렇게 명확해진 요구사항을 바탕으로 비로소 개발 계획을 수립하고 코드 생성을 시작한다.

이러한 모델의 타당성은 여러 학술적 연구를 통해서도 강력하게 뒷받침된다. ArXiv에 발표된 “Large Language Models Should Ask Clarifying Questions to Increase Confidence in Generated Code“라는 제목의 논문은 이 아이디어를 정면으로 다룬다.30 이 연구는 최고 수준의 소프트웨어 엔지니어들이 코딩을 시작하기 전에 요구사항의 모호성을 줄이기 위해 수많은 질문을 던지는 행위를 모델링했다. 그리고 이를 바탕으로, 사용자와 상호작용하며 명확화 질문을 던지는 ’커뮤니케이터 LLM(Communicator LLM)’과, 명확해진 요구사항을 전달받아 코드를 생성하는 ’코더 LLM(Coder LLM)’이 협력하는 새로운 개발 프로세스를 제안했다.30 이는 사용자의 핵심 가설을 학술적으로 뒷받침하는 매우 강력한 증거다.

4.3 대화형 요구사항 도출(Conversational Requirement Elicitation)

AI가 질문하는 새로운 패러다임은 ’요구사항 도출(Requirement Elicitation)’이라는 소프트웨어 공학의 전통적인 활동을 완전히 새로운 방식으로 혁신할 잠재력을 가지고 있다. 인터뷰, 설문조사, 워크숍 등 전통적인 요구사항 도출 방식은 많은 시간과 비용이 소요될 뿐만 아니라, 분석가의 역량에 따라 결과의 질이 크게 좌우되고, 이해관계자 간의 소통 오류가 발생할 가능성이 높다는 고질적인 문제점을 안고 있었다.32

AI 챗봇을 활용한 ‘대화형 요구사항 도출’ 연구는 이러한 한계를 극복할 수 있는 효과적인 대안을 제시한다. 이 접근법에서 AI 챗봇은 자연어 처리(NLP) 기술을 기반으로 사용자와 자연스러운 대화를 나누며 요구사항을 수집한다.33 중요한 점은, 이 챗봇이 단순히 사용자의 말을 받아 적는 수동적인 역할에 그치지 않는다는 것이다. 챗봇 내부에는 특정 산업(예: 금융, 헬스케어)에 대한 도메인 지식이 지식 베이스 형태로 내장되어 있어, 이를 바탕으로 완전하고 명확한 요구사항을 수집하기 위해 반드시 필요한 질문들을 사용자에게 던질 수 있다.35 예를 들어, 사용자가 “결제 기능이 필요하다“고 말하면, 챗봇은 “어떤 결제 수단(신용카드, 계좌이체)을 지원해야 합니까?”, “할부 기능이 필요합니까?”, “보안을 위해 어떤 규정을 준수해야 합니까?“와 같은 후속 질문을 통해 요구사항을 구체화한다.

더 나아가, 이렇게 대화를 통해 수집된 자연어 요구사항들은 서포트 벡터 머신(SVM)이나 다항 나이브 베이즈(MNB)와 같은 기계 학습 모델을 통해 기능적 요구사항과 비기능적 요구사항으로 자동 분류될 수 있다.35 이는 요구사항 분석 과정을 자동화하고, 인간 분석가의 주관적 판단으로 인한 오류를 줄여준다. 이처럼 대화형 AI 기술은 요구사항 공학의 전 과정을 보다 효율적이고, 정확하며, 체계적으로 만들어주는 핵심 동력이 될 것이다.

사용자가 제안한 미래 모델은 단순히 ’더 똑똑한 AI’의 등장을 의미하는 것이 아니다. 이는 소프트웨어 개발의 본질을 ’명령’에서 ’협상(Negotiation)’으로 바꾸는 근본적인 패러다임 전환을 의미한다. 이 새로운 모델에서 AI와 사용자는 공유된 목표(성공적인 소프트웨어 개발)를 달성하기 위해 서로가 가진 지식(사용자의 비즈니스 및 도메인 지식, AI의 방대한 기술 및 구현 지식)을 교환하고, 상호 질의응답을 통해 최적의 솔루션에 대한 합의(정밀한 요구사항 명세)를 도출해 나가는 대등한 ’협상 파트너’가 된다. 이러한 ‘협상’ 모델이 보편화되면, 소프트웨어 개발의 성공 여부는 개별 AI 모델의 기술적 성능(예: 코딩 벤치마크 점수)뿐만 아니라, AI가 얼마나 효과적으로 사용자의 머릿속에만 존재하는 암묵적 지식(Tacit Knowledge)을 끌어내고 구조화할 수 있는지, 즉 ’대화의 질’에 의해 결정될 것이다. 이는 향후 AI 개발의 연구 초점이 순수한 모델 성능 향상에서 인간-AI 상호작용(HCI) 및 인지 심리학적 측면으로까지 확장되어야 함을 강력하게 시사한다.

5. AI 주도형 개발의 아키텍처와 구현 과제

5.1 다중 에이전트 협업 프레임워크 (Multi-Agent Collaborative Frameworks)

AI 주도형 개발이라는 미래 비전을 현실로 구현하기 위한 아키텍처는 단일 거대 언어 모델(monolithic LLM)이 모든 것을 처리하는 방식이 아닐 가능성이 높다. 대신, 인간 소프트웨어 개발팀이 프로젝트 관리자, 시스템 아키텍트, 개발자, 테스터, 코드 리뷰어 등 각기 다른 전문성을 가진 역할들로 구성되는 것처럼, 미래의 AI 개발자 역시 특정 역할을 수행하도록 전문화된 여러 AI 에이전트들의 협력체(a team of specialized agents) 형태로 구성될 것이다. 이러한 다중 에이전트 시스템은 복잡한 소프트웨어 개발 과업을 보다 체계적이고 효율적으로 처리할 수 있게 해준다.

최근 학계에서 제안된 ‘AgentMesh’ 프레임워크는 이러한 비전을 구체화한 대표적인 사례다.36 AgentMesh는 소프트웨어 개발 프로세스를 네 가지 핵심적인 역할을 수행하는 전문 에이전트들의 협업 파이프라인으로 설계했다:

• Planner 에이전트: 워크플로우의 가장 첫 단계에 위치하며, 사용자가 제시한 높은 수준의 요구사항을 분석하여 구체적인 개발 계획과 실행 가능한 하위 작업 목록으로 분해하는 역할을 맡는다. 이는 프로젝트의 전체적인 청사진을 그리는 시스템 설계자나 프로젝트 관리자의 역할과 유사하며, 사용자의 가설에서 제시된 ‘AI가 개발 계획을 수립하는’ 핵심 기능을 담당한다.
• Coder 에이전트: Planner가 수립한 계획을 전달받아, 목록화된 각 하위 작업을 순서대로 실제 코드로 구현한다. 이 에이전트는 순수한 코드 생성 능력에 특화되어 있다.
• Debugger 에이전트: Coder가 코드 조각을 생성할 때마다 즉시 호출되어, 해당 코드를 테스트하고 문법적 오류나 간단한 버그를 찾아 수정한다. 이는 코드가 전체 시스템에 통합되기 전에 품질을 확보하는 역할을 한다.
• Reviewer 에이전트: 모든 하위 작업의 코딩과 디버깅이 완료된 후, 전체 코드베이스를 최종적으로 검토한다. 이 에이전트는 코드가 최초의 요구사항을 모두 충족하는지, 전체적인 아키텍처가 일관성을 유지하는지, 잠재적인 성능이나 보안 문제는 없는지 등을 종합적으로 평가하여 최종 품질 보증을 책임진다.

또 다른 프레임워크인 ’AutoDev’는 AI 에이전트가 실제 개발 환경과 어떻게 상호작용할 수 있는지에 대한 구체적인 방법을 제시한다.37 AutoDev는 ’에이전트 스케줄러’를 통해 여러 AI 에이전트들의 작업을 조율하고, 모든 작업을 Docker 컨테이너 기반의 안전한 가상 환경 내에서 실행시킨다. 이 환경 안에서 AI 에이전트들은 단순한 코드 생성을 넘어, 파일 편집, 코드 컴파일 및 빌드, 단위 테스트 및 통합 테스트 실행, 그리고 Git을 통한 버전 관리 및 협업 등 실제 개발자가 수행하는 복잡한 엔지니어링 작업을 자율적으로 수행할 수 있는 권한과 도구를 부여받는다. 이러한 프레임워크들은 미래의 AI 개발이 단일 AI의 지능에 의존하는 것이 아니라, 잘 설계된 ’에이전트 간의 협업 및 조정(Orchestration) 아키텍처’에 의해 좌우될 것임을 보여준다. 가장 큰 기술적 과제는 Planner, Coder, Debugger와 같은 전문 에이전트들 간에 컨텍스트, 계획, 코드, 테스트 결과물 등을 원활하게 전달하고 동기화하는 효율적인 파이프라인을 설계하는 것이다.

5.2 개발자 의도 파악(Developer Intent Deciphering)의 중요성

소프트웨어 공학 분야의 오랜 연구는 이 분야의 가장 근본적인 어려움이 ’개발자의 의도를 파악하고 명확히 하는 것(deciphering and clarification of developer intent)’에 있음을 지속적으로 지적해왔다.26 아무리 뛰어난 개발자라도, 무엇을 만들어야 하는지에 대한 의도가 불명확하다면 결코 올바른 결과물을 만들어낼 수 없다. 이는 AI에게도 동일하게 적용된다. 에이전틱 AI 기술이 소프트웨어 개발에 성공적으로 도입되기 위해서는, 이러한 ‘의도 추론(Intent Inference)’ 능력에서 개념적인 진보를 이루는 것이 필수적이다.

바로 이 지점에서 3장에서 논의된 ’질문하는 AI’의 역할이 다시 한번 부각된다. AI가 사용자에게 명확화 질문을 던지는 대화형 프로세스는, 단순히 정보를 수집하는 행위를 넘어 ’개발자의 의도를 파악’하는 핵심적인 메커니즘으로 작동한다. 사용자의 모호하고 비정형적인 자연어 표현 뒤에 숨겨진 진짜 의도, 즉 정확한 기능적/비기능적 요구사항을 명확하고 구조화된 명세로 변환하는 역할을 AI가 주도적으로 수행하는 것이다. 이 과정이 없다면, 아무리 정교한 다중 에이전트 프레임워크라 할지라도 ‘쓰레기를 넣으면 쓰레기가 나오는(Garbage In, Garbage Out)’ 문제를 피할 수 없다. 따라서 성공적인 AI 주도형 개발 시스템은 뛰어난 코드 생성 능력과 더불어, 사용자와의 깊이 있는 대화를 통해 숨겨진 의도를 발견하고 구체화하는 탁월한 의사소통 능력을 반드시 갖추어야 한다.

5.3 기술적 및 윤리적 과제

AI 주도형 개발 패러다임이 현실화되기까지는 해결해야 할 수많은 기술적, 윤리적 과제들이 남아있다.

첫째, 대규모 컨텍스트 관리(Large Context Management) 문제다. 현대의 소프트웨어 프로젝트는 수십만, 수백만 라인의 코드로 구성되며, 수많은 모듈과 라이브러리가 복잡하게 얽혀있다. AI 에이전트가 의미 있는 작업을 수행하기 위해서는 이 방대한 코드베이스의 전체적인 맥락과 아키텍처를 이해해야 하지만, 현재의 언어 모델은 한 번에 처리할 수 있는 컨텍스트의 양(Context Window)에 명백한 한계를 가지고 있다.

둘째, **신뢰와 통제(Trust and Control)**의 문제다. Devin과 같이 자율적으로 코드를 수정하고, 테스트하며, 심지어 배포까지 수행할 수 있는 AI 에이전트에게 어느 수준의 권한을 부여할 것인가는 매우 민감한 문제다.38 AI가 내리는 결정 과정을 인간이 이해하고 감사할 수 있도록 투명성을 확보하는 방법, 그리고 AI의 실수로 인해 시스템 장애나 데이터 유실과 같은 심각한 사고가 발생했을 때 그 책임 소재를 어떻게 규명할 것인지에 대한 사회적, 기술적 합의가 필요하다.5

셋째, AI 생성 코드의 검증(Verification & Validation of AI-generated code) 문제다. AI가 생성하는 코드의 양이 폭발적으로 증가함에 따라, 인간 개발자가 이 모든 코드의 정확성과 안전성을 일일이 검토하고 검증하는 것은 물리적으로 불가능해질 것이다. 이는 코드 검증 자체가 개발 프로세스의 새로운 병목이 될 수 있음을 의미한다. 이 문제를 해결하기 위해, AI가 생성한 코드를 또 다른 AI가 자동으로 검증하고 테스트하는 ‘AI 기반 V&V’ 기술이 미래 소프트웨어 공학의 필수적인 연구 분야로 부상하고 있다.26

마지막으로, 법적 및 윤리적 문제들이다. AI가 학습한 수많은 오픈소스 코드를 기반으로 새로운 코드를 생성했을 때, 그 결과물의 저작권은 누구에게 귀속되는가?.39 개발 과정에서 AI가 민감한 개인정보나 기업 비밀에 접근하게 될 경우, 데이터 프라이버시는 어떻게 보호할 것인가?.40 AI 모델이 특정 프로그래밍 언어나 개발 방식에 대한 편향을 학습하여 다양성을 저해할 가능성은 없는가? 이러한 문제들은 기술만으로는 해결할 수 없으며, 법률, 윤리, 사회적 합의를 통해 신중하게 다루어져야 한다.

이러한 도전 과제들은 완전 자율적인 AI 개발 에이전트의 등장이 결국 ‘AI 거버넌스(AI Governance)’ 문제를 소프트웨어 개발 조직의 핵심 이슈로 부상시킬 것임을 시사한다. 미래의 기술 리더들은 ’누가, 언제, 어떤 조건 하에서 AI가 코드베이스를 수정하고 배포하도록 허용할 것인가’에 대한 명확한 정책과 기술적 통제 장치(Guardrails)를 수립해야만 한다. 이는 단순한 기술 문제를 넘어, 조직의 문화와 리스크 관리 철학이 반영되어야 하는 고도의 전략적 의사결정 영역으로 확장될 것이다.41

6. 결론: ’바이브 코딩’을 넘어 ’협력적 지능’으로

본 보고서는 ’바이브 코딩’을 둘러싼 현재의 비관론이 AI 기술 자체의 한계라기보다는, 사용자의 불완전한 요구사항을 일방적으로 전달하는 단방향 소통 모델의 구조적 결함에서 비롯된다는 점을 명확히 했다. 그리고 AI가 스스로 개발 계획을 수립하고 사용자에게 명확화 질문을 던지는 양방향 대화 모델이 그 근본적인 해결책이 될 것이라는 사용자의 선구적인 가설이, 최신 학술 연구와 기술 동향을 통해 충분한 타당성을 확보하고 있음을 다각도로 논증했다.

이러한 패러다임의 전환은 미래 소프트웨어 개발자의 역할을 근본적으로 재정의할 것이다. 인간의 역할은 코드를 한 줄 한 줄 작성하는 ’구현자(Implementer)’에서, 전문화된 AI 에이전트들로 구성된 개발팀을 지휘하고, 비즈니스 목표와 기술적 구현 사이의 간극을 메우는 ’지휘자(Orchestrator)’이자, AI가 생성한 결과물의 최종적인 품질과 가치를 책임지는 ’검증자(Final Verifier)’로 진화할 것이다.42 미래 개발자에게 요구되는 핵심 역량은 특정 프로그래밍 언어에 대한 숙련도가 아니라, 복잡한 문제를 정의하고 분해하는 분석적 사고력, 새로운 솔루션을 구상하는 창의성, 그리고 가장 중요하게는 AI라는 새로운 파트너와 효과적으로 소통하고 협상하는 능력이다.

우리가 맞이할 미래는 인간이 AI를 단순히 도구로 사용하는 시대를 넘어, 인간과 AI가 각자의 고유한 강점—인간의 창의성, 비판적 사고, 복잡한 사회적 맥락에 대한 이해, 그리고 도메인 전문성, AI의 압도적인 처리 속도, 방대한 기술 지식, 지치지 않는 실행력—을 유기적으로 결합하여 함께 문제를 해결하는 ’협력적 지능(Collaborative Intelligence)’의 시대다. 이 새로운 패러다임은 소프트웨어 개발의 생산성과 품질을 지금과는 비교할 수 없는 차원으로 끌어올릴 거대한 잠재력을 지니고 있다.

이 거대한 변화의 물결에 성공적으로 올라타기 위해, 개발자와 기술 조직은 지금부터 전략적인 준비를 시작해야 한다. 첫째, 개발자 개인은 AI와의 협업 능력을 체계적으로 기르고, 프롬프트 엔지니어링을 넘어 요구사항 분석 및 AI 에이전트 관리 역량을 함양해야 한다. 둘째, 조직은 소규모 프로젝트부터 AI 주도 개발 프로세스를 실험적으로 도입하여 기술적 노하우와 운영 경험을 축적해야 한다. 셋째, AI의 자율성과 권한에 대한 명확한 정책과 통제 방안을 포함하는 AI 거버넌스 체계를 수립하여, 혁신과 리스크 사이의 균형을 찾아야 한다. AI를 단순한 코딩 보조 도구로 여기고 현상 유지에 안주하는 조직은 결국 도태될 것이다. 반면, AI를 진정한 개발 파트너로 받아들이고 인간과 AI의 협력 모델을 선도적으로 구축하는 조직만이 다가올 미래의 경쟁에서 승리할 것이다.

7. 참고 자료

1. cloud.google.com, https://cloud.google.com/discover/what-is-vibe-coding?hl=ko#:~:text=%EB%B0%94%EC%9D%B4%EB%B8%8C%20%EC%BD%94%EB%94%A9%EC%9D%B4%EB%9E%80%20%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94,%EC%83%88%EB%A1%9C%EC%9A%B4%20%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%20%EA%B0%9C%EB%B0%9C%20%EB%B0%A9%EC%8B%9D%EC%9E%85%EB%8B%88%EB%8B%A4.
2. 바이브 코딩 설명: 도구 및 가이드 | Google Cloud, https://cloud.google.com/discover/what-is-vibe-coding?hl=ko
3. 6-1화. 굿모닝 그록, 입코딩이 뭐야?, https://contents.premium.naver.com/letsgo99/mysecretdiary/contents/250326100756627rk
4. Vibe coding, https://en.wikipedia.org/wiki/Vibe_coding
5. 바이브 코딩 - 나무위키, https://namu.wiki/w/%EB%B0%94%EC%9D%B4%EB%B8%8C%20%EC%BD%94%EB%94%A9
6. 바이브코딩이란 무엇일까? | 숨 쉴 틈 없이 발전하는 AI시대에 갖춰야 하는 필수 역량, https://www.youtube.com/watch?v=mzomjCHEPpg
7. 바이브 코딩, 누구나 쉽게? 과연 그럴까?, https://contents.premium.naver.com/codetree/funcoding/contents/250504170239972lv
8. AI 에이전트와 AI 어시스턴트 비교 | IBM, https://www.ibm.com/kr-ko/think/topics/ai-agents-vs-ai-assistants
9. [매경춘추] AI와 소프트웨어 - 매일경제, https://www.mk.co.kr/news/contributors/10760921
10. ’AI 코딩 도구’가 ‘개발자’ 대체?…찬․반 ‘논쟁’ - 애플경제, https://www.apple-economy.com/news/articleView.html?idxno=74174
11. AI로 생성한 코드 문제점과 유의 사항 - 인포그랩, https://insight.infograb.net/blog/2024/07/24/ai-code
12. 자세히 알아보기: AI 코딩 어시스턴트가 생성하는 취약점 탐색 - 블로그 - Secure Code Warrior, https://ko.securecodewarrior.com/article/deep-dive-navigating-vulnerabilities-generated-by-ai-coding-assistants
13. IDE에서 GitHub Copilot 채팅의 책임 있는 사용, https://docs.github.com/ko/enterprise-cloud@latest/copilot/responsible-use/chat-in-your-ide
14. GitHub Copilot 코드 완성의 책임 있는 사용, https://docs.github.com/ko/enterprise-cloud@latest/copilot/responsible-use/copilot-code-completion
15. 인공 지능(AI) 할루시네이션이란? - Cloudflare, https://www.cloudflare.com/ko-kr/learning/ai/what-are-ai-hallucinations/
16. LLM에 Halluciation(환각)이 발생하는 원인과 해결방안, https://moon-walker.medium.com/llm%EC%97%90-halluciation-%ED%99%98%EA%B0%81-%EC%9D%B4-%EB%B0%9C%EC%83%9D%ED%95%98%EB%8A%94-%EC%9B%90%EC%9D%B8%EA%B3%BC-%ED%95%B4%EA%B2%B0%EB%B0%A9%EC%95%88-f18759f0a959
17. AI 할루시네이션이란 무엇인가요? - IBM, https://www.ibm.com/kr-ko/think/topics/ai-hallucinations
18. BELLA QNA가 할루시네이션을 줄이는 방법 - 스켈터랩스, https://www.skelterlabs.com/blog/bellaqna-rag-hallucination
19. “AI코딩 지원도구, 부적절한 사용 시 코드품질 저하 우려” - 지디넷코리아, https://zdnet.co.kr/view/?no=20240126104717
20. 요구사항 명세서 작성방법 - 개발학습 블로그, https://do-devel.tistory.com/16
21. 요구명세 - SRS (Software Requirement Specipication) 의 중요성과 SW진흥법 전면 개정, https://it-license.tistory.com/30
22. [Project] 사용자 요구사항 정의서 (SRS)란? - velog, https://velog.io/@bagt/%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD-%EC%A0%95%EC%9D%98%EC%84%9C-SRS%EB%9E%80
23. 4장. 요구사항 개발 및 관리, https://chayan-memorias.tistory.com/72
24. 요구사항은 중요한듯 - velog, https://velog.io/@wi___s10/%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD-%EB%AA%85%EC%84%B8%EC%84%9C
25. 요구명세(SRS)의 중요성과 제도화 방향 - SPRi - 소프트웨어정책연구소, https://spri.kr/posts/view/22234?code=data_all&study_type=ai_brief
26. Agentic AI for Software: thoughts from Software Engineering …, https://www.arxiv.org/abs/2508.17343
27. AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenges - arXiv, https://arxiv.org/html/2505.10468v1
28. Small Language Models are the Future of Agentic AI - arXiv, https://arxiv.org/pdf/2506.02153
29. Understanding your users’ questions or requests - IBM, https://www.ibm.com/docs/en/watsonx/watson-orchestrate/base?topic=actions-understanding-your-users-questions-requests
30. Large Language Models Should Ask Clarifying Questions to … - arXiv, https://arxiv.org/pdf/2308.13507
31. Must Known 4 Essential AI Prompts Strategies for Developers | by Reynald - Medium, https://reykario.medium.com/4-must-know-ai-prompt-strategies-for-developers-0572e85a0730
32. (PDF) AI-Driven Software Requirements Elicitation: A Novel Approach - ResearchGate, https://www.researchgate.net/publication/377240538_AI-Driven_Software_Requirements_Elicitation_A_Novel_Approach
33. AI Techniques in Requirements Elicitation - Journal of Software, https://www.jsoftware.us/vol18/JSW-V18N4-490.pdf
34. A Literature Review on the Impact of Artificial Intelligence in Requirements Elicitation and Analysis - DiVA portal, https://www.diva-portal.org/smash/get/diva2:1784322/FULLTEXT01.pdf
35. Artificial Intelligence in Software Requirements Engineering: State-of …, https://web.ntpu.edu.tw/~myday/doc/IRI2022/IEEE_IRI2022_Proceedings/pdfs/IRI2022-2biJIxjybiQ3DOmA6IkB2x/660300a106/660300a106.pdf
36. AgentMesh: A Cooperative Multi-Agent Generative AI … - arXiv, https://arxiv.org/abs/2507.19902
37. AutoDev: Automated AI-Driven Development - arXiv, https://arxiv.org/abs/2403.08299
38. Devin | The AI Software Engineer, https://devin.ai/
39. 생성형 AI에 의한 소프트웨어 개발자 업무 영향 분석 - SPRi - 소프트웨어정책연구소, https://spri.kr/posts/view/23769?code=
40. AI 소프트웨어 개발: 컴퓨팅의 미래, 과제, 기회 - Scopic, https://scopicsoftware.com/ko/blog/ai-software-development/
41. 기업이 AI 개발에 어려움을 겪는 이유 3가지 - AI 히어로즈, https://aiheroes.ai/community/128
42. 소프트웨어 개발에서의 AI - IBM, https://www.ibm.com/kr-ko/think/topics/ai-in-software-development