1.1.5 소프트웨어 생명주기(SDLC) 전반에 걸친 AI의 침투와 파급 효과

1. 서론: 결정론적 엔지니어링의 종말과 확률론적 패러다임의 부상

소프트웨어 엔지니어링의 역사는 본질적으로 ’제어(Control)’와 ’예측 가능성(Predictability)’을 확보하기 위한 투쟁의 기록이었다. 1960년대의 구조적 프로그래밍부터 객체 지향(OOP), 애자일(Agile), 그리고 데브옵스(DevOps)에 이르기까지, 인류가 구축해 온 모든 방법론은 인간이 작성한 명시적인 논리(Logic)가 의도한 대로 정확하게 작동하도록 보장하는 데 초점을 맞추어 왔다. 우리는 입력이 같으면 언제나 같은 출력을 내놓는 결정론적(Deterministic) 시스템을 구축하는 데 익숙해져 있으며, 이것이 소프트웨어 품질의 척도였다. 그러나 생성형 AI(Generative AI)와 거대 언어 모델(LLM)의 등장은 이 근본적인 전제를 뿌리째 흔들고 있다.

우리는 지금 ’명시적인 지시(Software 1.0)’에서 ’학습된 데이터와 확률(Software 2.0/3.0)’로 넘어가는 거대한 지각 변동의 한복판에 서 있다. 안드레이 카파시(Andrej Karpathy)가 정의한 Software 2.0은 인간이 코드를 작성하는 것이 아니라, 원하는 동작을 정의하는 데이터셋을 축적하고 신경망이 그 로직을 스스로 학습하게 만드는 패러다임을 의미한다. 여기에 더해, 자율적인 에이전트가 도구를 사용하고 복잡한 워크플로우를 조율하는 Software 3.0의 시대가 도래함에 따라, SDLC(Software Development Life Cycle)는 단순한 자동화를 넘어선 근본적인 재구성을 요구받고 있다.

이 장에서는 전통적인 소프트웨어 생명주기가 AI의 침투로 인해 어떻게 해체되고 재구성되는지를 심층적으로 분석한다. 이는 단순한 생산성 도구의 도입(Tooling) 수준을 넘어선다. 요구사항 정의부터 유지보수에 이르는 모든 단계에서 ’인간의 역할’과 ’기계의 역할’이 재정의되고 있으며, 이에 따른 새로운 형태의 기술 부채(Technical Debt)와 검증의 위기(Verification Crisis)가 발생하고 있다. 우리는 이 변화를 ’GAASD(Generative AI-Assisted Software Development) 라이프사이클’이라는 새로운 프레임워크를 통해 조망하고, 각 단계별로 발생하는 기회와 위협, 그리고 미래의 대응 전략을 상세히 기술할 것이다.

2. 계획 및 요구사항 분석 (Planning & Requirements): 의미론적 가교의 형성

전통적인 SDLC, 특히 워터폴(Waterfall) 모델이나 초기 애자일 환경에서 가장 큰 병목 구간이자 오류의 근원지는 바로 ‘요구사항 분석’ 단계였다. 인간의 불완전한 언어(자연어)를 기계가 이해할 수 있는 엄밀한 논리(코드)로 변환하는 과정에서 수많은 오해, 누락, 그리고 의미론적 간극이 발생했기 때문이다. 그러나 생성형 AI는 이 단계에서 ‘의미론적 가교(Semantic Bridge)’ 역할을 수행하며 프로세스를 혁신하고 있다.

2.1 모호함의 제거와 대화형 명세화 (Conversational Specification)

과거의 비즈니스 분석가(BA)나 제품 관리자(PM)는 사용자의 요구를 인터뷰하고 이를 문서화하는 데 수주를 소모했다. 이제 AI는 이 과정을 실시간 대화형 프로세스로 변환한다. 챗봇 형태의 AI는 이해관계자와의 대화를 통해 모호한 요구사항(“사용하기 쉽게 만들어줘”)을 구체적인 기술 명세(“로그인 프로세스는 3단계 이내여야 하며, 생체 인식을 지원해야 함”)로 변환한다. 이는 자연어 처리(NLP) 능력을 활용하여 비즈니스 용어를 엔지니어링 용어로 번역하는 과정이며, 이 과정에서 AI는 누락된 조건이나 모호한 표현을 능동적으로 질문하여 구체화한다.

또한, 텍스트 설명만으로 UI 목업(Mockup)이나 기능적인 프로토타입을 즉각적으로 생성(Instant Prototyping)함으로써, 기획 단계에서부터 ‘눈에 보이는’ 결과물을 놓고 논의할 수 있게 되었다. 이는 “내가 원한 것은 이게 아니다“라는 피드백을 개발 착수 전인 기획 단계로 앞당겨(Shift Left), 요구사항 정의의 불확실성을 획기적으로 낮추는 효과를 가져온다.

2.2 데이터 기반의 예측적 계획 수립 (Predictive Planning)

계획 수립 단계에서 AI는 과거 프로젝트의 방대한 데이터를 분석하여 인간의 직관보다 훨씬 정확한 견적과 계획을 제시한다. AI는 팀의 과거 스프린트 데이터, 기술적 복잡도, 유사 프로젝트의 사례를 분석하여 프로젝트의 소요 시간과 리소스를 정밀하게 예측한다. 예를 들어, “이 기능은 과거 유사 사례를 볼 때 70 맨/데이(Man-days)가 소요되었으며, 현재 팀의 속도로는 15%의 지연 리스크가 있다“는 식의 구체적이고 정량적인 인사이트를 제공한다.

더 나아가, AI는 요구사항 문서(PRD)를 스캔하여 상충되는 조건이나 기술적으로 구현 불가능한 요소를 사전에 경고하는 리스크 관리자의 역할을 수행한다. 이는 프로젝트 초기 단계에서 잠재적인 기술 부채를 식별하고 차단하는 데 기여한다.

2.3 SDLC 모델의 변화: 선형성에서 순환성으로

이러한 변화는 SDLC의 초기 단계를 선형적인 ‘문서 작성’ 작업에서 순환적인 ‘탐색 및 정제’ 작업으로 변화시킨다. 기획자가 AI에게 의도를 설명하고, AI가 초안을 생성하며, 기획자가 이를 수정하는 반복적인 루프(Loop)가 형성된다. 이는 애자일 방법론의 ‘반복(Iteration)’ 주기를 극단적으로 단축시키는 효과를 가져온다. 과거에는 스프린트 단위(1~2주)로 이루어지던 피드백 루프가 AI와의 대화 속(수 초~수 분)으로 압축되는 것이다.

3. 설계 및 아키텍처 (Design & Architecture): 창의성과 최적화의 융합

설계 단계에서 AI는 단순한 보조 도구를 넘어, 아키텍처의 구조적 건전성을 검토하고 최적의 설계를 제안하는 ’가상 아키텍트’로 진화하고 있다. 이 단계에서 AI의 역할은 방대한 설계 공간(Design Space)을 탐색하고, 최적의 해를 찾아내는 것이다.

3.1 생성형 설계를 통한 다차원적 탐색

전통적인 아키텍트가 경험과 직관에 의존하여 한정된 시간 내에 2~3가지의 아키텍처 대안을 검토했다면, AI는 수백 가지의 설계 변형을 생성하고 평가할 수 있다. 프로젝트의 비기능적 요구사항(확장성, 보안성, 유지보수성 등)을 입력하면, AI는 마이크로서비스(Microservices), 모놀리식(Monolithic), 서버리스(Serverless) 등 적합한 아키텍처 패턴을 제안하고 각 선택의 장단점(Trade-off)을 분석한다.

또한, 기존 레거시 시스템의 코드를 분석하여 현재의 실제 아키텍처가 설계 문서와 얼마나 괴리되어 있는지(Architecture Drift)를 시각화하고, 이를 해결하기 위한 리팩토링 경로를 제안한다. 이는 시스템의 복잡도가 인간의 인지 한계를 넘어선 현대의 대규모 시스템에서 필수적인 기능이 되고 있다.

3.2 시스템 2.0: 학습된 파라미터로서의 설계

안드레이 카파시(Andrej Karpathy)가 주창한 ‘Software 2.0’ 개념은 설계의 본질을 근본적으로 바꾸고 있다. 전통적인 Software 1.0이 문제를 해결하기 위해 프로그래머가 명시적인 알고리즘과 로직을 설계하는 것이라면, Software 2.0은 데이터셋을 구축하고 신경망이 스스로 최적의 아키텍처와 로직(가중치)을 학습하게 하는 방식이다.

이러한 변화에 따라 설계자의 역할은 ’알고리즘 작성’에서 ’데이터 큐레이션’과 ’목적함수(Objective Function) 정의’로 이동한다. 설계는 더 이상 로직의 구조화가 아니라, AI가 학습할 데이터의 품질을 관리하고, AI가 도달해야 할 목표를 명확히 정의하는 작업이 된다. 이는 소프트웨어 아키텍처가 데이터 엔지니어링 및 ML 파이프라인 설계와 융합됨을 의미한다.

4. 구현 (Implementation): 생산성의 폭발과 ’바이브 코딩’의 위험

구현 단계는 생성형 AI의 영향력이 가장 즉각적이고 파괴적으로 나타나는 영역이다. GitHub Copilot, Amazon CodeWhisperer, Cursor와 같은 도구는 개발자의 일상을 완전히 바꾸어 놓았다. 코드 생성의 한계 비용(Marginal Cost)이 거의 ’0’에 수렴하면서, 우리는 코드의 ‘희소성’ 시대에서 ’풍요’의 시대로, 더 나아가 ’과잉’의 시대로 진입하고 있다.

4.1 코딩의 상품화와 ’바이브 코딩(Vibe Coding)’의 부상

AI 코딩 도구의 보편화는 ‘코드를 작성하는 행위’ 자체의 진입 장벽을 낮추었다. 이는 **‘바이브 코딩(Vibe Coding)’**이라는 새로운 현상을 낳았다. 바이브 코딩이란 개발자가 코드의 세부적인 문법, 메모리 관리, 혹은 알고리즘의 작동 원리를 깊이 이해하지 못한 상태에서도, AI에게 자연어로 “이런 느낌(Vibe)으로 만들어줘”, “데이터를 차트로 보여줘“라고 요청하여 코드를 생성하고 실행하는 방식을 의미한다.

이 방식은 초급 개발자나 익숙하지 않은 언어를 사용하는 개발자에게는 엄청난 생산성 향상을 가져다준다. 맥킨지(McKinsey)의 연구에 따르면, 새로운 프로젝트(Greenfield)에서는 작업 속도가 최대 55%까지 향상되었다. 그러나 이는 심각한 부작용을 동반한다. 개발자가 자신이 생성한 코드를 완전히 장악하지 못하는 ‘통제력 상실’ 현상이 발생한다. 코드는 작동하지만, 그 내부 원리를 설명할 수 없는 ’블랙박스화 된 레거시’가 생성 시점부터 만들어지는 것이다. 이는 장기적으로 심각한 유지보수 문제를 야기할 수 있다.

4.2 코드 품질의 저하와 중복의 증가: GitClear 및 DORA 리포트 분석

생산성의 증가가 반드시 품질의 향상으로 이어지는 것은 아니다. 오히려 정반대의 신호들이 감지되고 있다. GitClear의 2024년 분석에 따르면, AI 코딩 도구의 도입 이후 코드의 ‘복사/붙여넣기(Copy/Paste)’ 비율이 급증하고, 코드의 재사용성을 높이는 ’리팩토링(Refactoring)’이나 ’코드 이동(Moved Code)’은 오히려 감소했다.

• 코드 블로트(Code Bloat): AI는 간결하고 최적화된 추상화(Abstraction)를 설계하기보다, 훈련 데이터에서 가장 흔하게 본 패턴을 통째로 생성해내는 경향이 있다. 이로 인해 불필요하게 장황하고 중복된 코드가 양산된다.
• 리팩토링의 감소: 개발자가 직접 코드를 작성할 때는 중복을 줄이기 위해 함수화하거나 모듈화하려는 유인이 존재한다. 그러나 AI가 순식간에 코드를 생성해주는 환경에서는 굳이 구조를 개선하려는 노력을 기울일 필요성이 줄어든다. 중복된 코드는 버그 수정 시 여러 곳을 동시에 고쳐야 함을 의미하며, 이는 장기적으로 기술 부채(Technical Debt)를 기하급수적으로 증가시킨다.
• 안정성의 저하: Google의 2024 DORA 리포트는 AI 도입이 25% 증가할 때마다 배포 안정성(Delivery Stability)이 7.2% 감소한다는 충격적인 상관관계를 보고했다. 이는 코드가 더 빨리 만들어지지만, 더 자주 깨진다는 것을 의미한다.

4.3 검증 병목(Verification Bottleneck) 현상

가장 심각한 문제는 생산 속도와 검증 속도 간의 불균형이다. 코드를 **작성(Writing)**하는 속도는 AI 덕분에 비약적으로 빨라졌지만, 인간이 그 코드를 **리뷰(Review)**하고 **이해(Understand)**하는 속도는 생물학적 한계에 묶여 있다.

Sonar의 ‘State of Code 2025’ 조사에 따르면, 개발자의 42%가 AI가 작성한 코드를 사용하지만, 96%는 그 코드를 완전히 신뢰하지 않는다는 모순적인 상황이 벌어지고 있다. 개발자들은 쏟아지는 AI 생성 코드를 꼼꼼히 리뷰하지 않고 “일단 작동하니까” 커밋(Commit)하는 유혹에 빠지기 쉽다. 이는 코드베이스 내에 미처 발견되지 않은 논리적 오류와 보안 취약점을 누적시키는 **‘검증 부채(Verification Debt)’**를 형성한다. 결국 개발팀의 업무는 창조적인 코딩에서 지루하고 고통스러운 ’남(AI)이 짠 코드 리뷰하기’로 변질될 위험이 있으며, 이는 개발자 만족도 저하와 번아웃(Burnout)으로 이어질 수 있다.

5. 테스팅 및 품질 보증 (Testing & QA): 오라클 문제와 새로운 검증 방법론

전통적인 테스팅은 ’예상된 입력’에 대해 ’예상된 출력’이 나오는지 확인하는 결정론적 과정이었다. 그러나 AI 모델 자체가 소프트웨어의 일부가 되거나(AI-infused system), AI가 작성한 코드를 테스트해야 하는 상황에서 기존의 테스팅 방법론은 심각한 한계에 부딪혔다.

5.1 오라클 문제(The Oracle Problem)의 심화

테스팅 분야에서 ’오라클(Oracle)’이란 테스트 수행 결과가 참인지 거짓인지 판단하는 메커니즘을 말한다. 예를 들어 “2+2“의 오라클은 “4“이다. 그러나 생성형 AI 시스템이나 AI가 생성한 복잡한 로직에서는 오라클을 정의하기가 매우 어렵다.

• 비결정론적 출력(Non-deterministic Output): 챗봇에게 “사과에 대해 설명해줘“라고 했을 때, 매번 다른 문장이 생성된다. 이때 무엇이 ’정답’인가? 문법이 맞으면 정답인가? 내용이 사실이어야 하는가? 사실 여부는 어떻게 검증하는가?
• 검증 비용의 증가: 정답을 미리 알 수 없기 때문에, 사람이 일일이 결과를 읽어보고 판단해야 하는 경우가 많아진다. 이는 자동화 테스트의 이점을 상쇄시키며, 테스트 병목 현상을 악화시킨다.

5.2 메타모픽 테스팅(Metamorphic Testing)의 부상

이러한 난제를 해결하기 위해 학계와 산업계에서는 **‘메타모픽 테스팅(Metamorphic Testing)’**을 핵심 기법으로 주목하고 있다. 메타모픽 테스팅은 입력값의 정확한 결과값을 몰라도, 입력값의 변화에 따른 출력값의 **관계(Relation)**를 통해 시스템의 정합성을 검증하는 방법이다.

• 원리: 소스 입력(Source Input) I에 대한 결과 O를 몰라도, I를 변형한 I'에 대한 결과 O'와 O 사이의 관계(Metamorphic Relation, MR)가 유지되는지 확인한다.
• 적용 예시:
• 검색 엔진: 검색어 “AI“의 결과(A)와 “AI AND Software“의 결과(B)를 비교할 때, 정확한 검색 결과 리스트는 몰라도, “B는 A의 부분집합이어야 한다“는 관계는 검증할 수 있다.
• 감정 분석 AI: “이 영화는 재미있다“의 점수가 0.8이라면, 여기에 “매우“를 추가한 “이 영화는 매우 재미있다“의 점수는 0.8보다 높거나 같아야 한다는 관계를 테스트한다.
• 자율 주행: 비가 오는 날씨의 주행 시뮬레이션 결과는 맑은 날씨보다 안전 거리가 더 길거나 같아야 한다.

이 방식은 정답(Ground Truth)이 없는 AI 시스템을 검증하는 데 매우 효과적이며, 오라클 문제를 우회할 수 있는 강력한 도구를 제공한다.

5.3 AI를 활용한 테스팅의 자동화 (AI for Testing)

역설적으로, AI가 만든 코드의 결함을 찾는 데에도 AI가 핵심적으로 사용된다. 이는 ‘독으로 독을 제압하는(Fighting fire with fire)’ 전략과 유사하다.

• 지능형 테스트 케이스 생성: AI는 코드를 분석하여 경계값(Edge Case), 예외 상황 등을 포함한 유닛 테스트 코드를 자동으로 생성한다. 인간 개발자가 미처 생각하지 못한 복잡한 경로를 탐색하여 테스트 커버리지(Coverage)를 획기적으로 높인다.
• 자가 치유 테스트(Self-Healing Tests): UI가 변경되어 기존의 셀레늄(Selenium) 등의 테스트 스크립트가 깨지는 경우, AI가 변경된 UI 요소를 시각적으로 인식하고 자동으로 테스트 스크립트를 수정하여 테스트 파이프라인의 중단을 막는다. 이는 유지보수 비용이 높은 UI 테스트의 효율성을 극대화한다.

6. 배포 및 유지보수 (Deployment & Maintenance): AIOps와 자율 운영

배포와 운영 단계에서 AI는 시스템의 안정성을 지키는 ’디지털 면역 체계’로 작동한다. 이를 **AIOps (Artificial Intelligence for IT Operations)**라고 하며, 이는 반응형(Reactive) 운영에서 예측형(Predictive) 및 자율형(Autonomous) 운영으로의 전환을 의미한다.

6.1 인프라의 코드화(IaC)와 자동 배포 파이프라인

AI는 복잡한 클라우드 인프라 설정을 위한 스크립트(Terraform, Kubernetes YAML 등)를 자동으로 생성하고 최적화한다. 또한 배포 전략(Canary, Blue/Green)을 지능적으로 제어한다. AI는 배포 과정에서 발생하는 로그를 실시간으로 모니터링하다가, 이상 징후(에러율의 미세한 증가, 응답 속도 저하 패턴)가 감지되면 즉시 롤백(Rollback)을 수행하거나 트래픽을 차단한다. 이는 인간 운영자가 대시보드를 보고 판단하기 전에 밀리초(ms) 단위로 이루어져 서비스 중단을 최소화한다.

6.2 예측적 유지보수(Predictive Maintenance)와 근본 원인 분석

과거의 유지보수가 ‘고장 나면 고치는(Break-Fix)’ 방식이었다면, AI 시대의 유지보수는 ‘고장 나기 전에 예방하는’ 방식이다.

• 장애 예측: 시스템의 CPU 사용량, 메모리 패턴, 네트워크 트래픽, 디스크 I/O 등의 시계열 데이터를 분석하여, “30분 내에 데이터베이스 서버가 다운될 확률이 85%“와 같은 구체적인 경고를 보낸다. 이는 장애가 발생하기 전에 선제적으로 리소스를 증설하거나 서비스를 우회할 수 있게 한다.
• 근본 원인 분석(Root Cause Analysis, RCA): 장애 발생 시 수천 줄의 로그와 수백 개의 마이크로서비스 간의 트랜잭션을 분석하여 문제의 근본 원인을 찾아낸다. AI는 “서비스 A의 응답 지연이 서비스 B의 재시도를 유발하고, 이것이 DB 락(Lock)을 유발했다“는 인과 관계를 시각화하여 운영자에게 제시한다.

7. 결론: 인간 개발자의 새로운 역할과 미래 전망

AI의 SDLC 전면적 침투는 소프트웨어 개발을 ’수작업(Craftsmanship)’에서 ’산업적 공정(Industrial Process)’으로, 그리고 더 나아가 ’지휘(Orchestration)’의 영역으로 변화시키고 있다. 이 변화는 되돌릴 수 없는 흐름이며, 이에 적응하지 못하는 조직과 개인은 도태될 위기에 처해 있다.

7.1 새로운 역할: 작성자에서 리뷰어, 그리고 아키텍트로

앞으로의 소프트웨어 엔지니어는 코드를 한 줄 한 줄 작성하는 ’타이피스트’가 아니라, AI가 생성한 결과물을 검증하고 조립하는 **‘리뷰어(Reviewer)’**이자 **‘아키텍트(Architect)’**가 되어야 한다. 역설적으로, AI가 코드를 짤수록 인간에게는 더 높은 수준의 코드 이해력과 시스템적인 사고 능력이 요구된다. AI가 만든 복잡한 코드의 오류를 찾아내는 것은 직접 짜는 것보다 훨씬 높은 인지적 부하를 요구하기 때문이다.

이러한 환경에서 주니어 개발자들의 성장 경로는 심각한 도전을 받게 된다. 과거에는 단순 코딩 업무를 통해 실력을 쌓았으나, 이제 그 영역은 AI가 대체하고 있다. 따라서 교육과 훈련 시스템은 코딩 문법 교육보다 코드 리뷰, 설계 패턴, 시스템 아키텍처, 그리고 AI와의 협업 능력을 가르치는 방향으로 근본적으로 변화해야 한다.

7.2 기술 부채의 재정의: 확률적 부채와 탄소 비용

우리는 이제 ’구현 부채(Code Debt)’보다 **‘확률적 부채(Probabilistic Debt)’**를 걱정해야 한다. 시스템이 비결정론적으로 동작함에 따라, 오늘 작동하던 코드가 내일 모델 업데이트나 프롬프트의 미세한 변화로 인해 오작동할 수 있다. 이러한 불확실성을 관리(Management of Uncertainty)하는 것이 SDLC의 핵심 관리 항목이 될 것이다.

또한, AI 생성 코드의 환경적 비용도 고려해야 한다. AI 모델을 실행하여 코드를 생성하고 수정하는 과정은 인간이 코딩하는 것보다 최대 19배 많은 탄소를 배출할 수 있다는 연구 결과가 있다. 지속 가능한 SDLC를 위해서는 무분별한 AI 사용보다 효율적이고 검증된 코드 재사용이 장려되어야 한다.

7.3 에이전트(Agent) 시대로의 진입

Software 3.0이라 불리는 가까운 미래에는 자율적인 AI 에이전트들이 서로 소통하며 소프트웨어를 개발하고 유지보수할 것이다. 개발자는 에이전트들에게 “목표“를 부여하고, 에이전트들이 만든 결과물의 “품질 기준(Quality Gate)“을 설정하는 관리자의 역할을 맡게 될 것이다. SDLC는 더 이상 인간만의 생명주기가 아니라, 인간과 AI가 공진화(Co-evolution)하는 하이브리드 생명주기로 거듭나고 있다. 이 새로운 생태계에서 성공의 열쇠는 AI를 얼마나 잘 ’통제’하고 ’검증’할 수 있느냐에 달려 있다.

8. 참고 자료

1. Understanding the Three Faces of AI: Deterministic, Probabilistic, https://www.mymobilelyfe.com/artificial-intelligence/understanding-the-three-faces-of-ai-deterministic-probabilistic-and-generative/
2. The Future of Software - Max Davish, https://www.maxdavish.com/blog/future-of-software
3. Software 2.0. I sometimes see people refer to neural… | by Andrej …, https://karpathy.medium.com/software-2-0-a64152b37c35
4. From Software 1 2 | PDF | System | Artificial Intelligence - Scribd, https://www.scribd.com/document/982861576/From-Software-1-2
5. The AI Verification Bottleneck: Developer Toil Isn’t Shrinking - The …, https://thenewstack.io/the-ai-verification-bottleneck-developer-toil-isnt-shrinking/
6. The Evolution of Technical Debt from DevOps to Generative AI, https://oulurepo.oulu.fi/bitstream/handle/10024/58341/nbnfioulu-202509155859.pdf?sequence=1
7. IMPACT OF GENERATIVE AI ON THE SOFTWARE DEVELOPMENT, https://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID4536700_code6075547.pdf?abstractid=4536700&mirid=1
8. Generative AI’s impact on the software development lifecycle, https://our-thinking.nashtechglobal.com/insights/generative-ais-impact-on-the-software-development-lifecycle
9. (PDF) Impact of Generative AI on the Software Development Life, https://www.researchgate.net/publication/373012726_Impact_of_Generative_AI_on_the_Software_Development_Life_Cycle_SDLC
10. Rethinking the Software Development Lifecycle with Generative AI, https://community.ibm.com/community/user/blogs/diego-colombatto/2025/04/15/rethinking-sdlc-with-generativeai
11. Software 2.0: An Emerging Era of Automatic Code Generation, https://blog.softtek.com/software-2.0-an-emerging-era-of-automatic-code-generation
12. AI in SDLC: The Revolutionary Role of Generative AI in … - SmartDev, https://smartdev.com/fr/role-of-generative-ai-in-software-deployment/
13. AI Coding’s Hidden Verification Premium | Blog | Mario Thomas, https://mariothomas.com/blog/vibe-coding-vs-classical-training/
14. AI-assisted coding: what worked for me and what didn’t (after 6, https://www.playingaws.com/posts/ai-assisted-coding-what-worked-for-me-and-what-didn-t-after-6-months/
15. 42% of Code Is Now AI-Assisted! - ShiftMag, https://shiftmag.dev/state-of-code-2025-7978/
16. How effectively does metamorphic testing alleviate the oracle, https://vuir.vu.edu.au/33046/1/TSEmt.pdf
17. The Oracle Problem in Software Testing: A Survey, http://www0.cs.ucl.ac.uk/staff/m.harman/tse-oracle.pdf
18. Testing AI Systems: Handling the Test Oracle Problem, https://dev.to/qa-leaders/testing-ai-systems-handling-the-test-oracle-problem-3038
19. METRIC+: a metamorphic relation identification technique based on, https://www.researchgate.net/publication/335108888_METRIC_a_metamorphic_relation_identification_technique_based_on_input_plus_output_domains
20. Metamorphic Testing of Relation Extraction Models - MDPI, https://www.mdpi.com/1999-4893/16/2/102
21. What is Test Oracle in Software Testing? - testRigor, https://testrigor.com/blog/what-is-test-oracle-in-software-testing/
22. Systematic Literature Review of Agentic AI and AIOps Across, https://aaltodoc.aalto.fi/bitstreams/a3aad94e-e82b-4001-b3f0-443e812dc53a/download
23. AI-assisted coding and the true Bottlenecks in Software Development, https://www.reddit.com/r/ExperiencedDevs/comments/1qwhy03/aiassisted_coding_and_the_true_bottlenecks_in/
24. Using Generative AI to Unlock Probabilistic Products, https://a16z.com/generative-ai-probabilistic-products/
25. The Risk of AI, Non-Deterministic Code Generation - Medium, https://medium.com/@sandrodz/the-hidden-risk-of-ai-non-deterministic-code-generation-3765a1c27017