SDLC와 에이전틱 AI: 개발 프로세스의 진화

SDLC는 “소프트웨어를 어떻게 기획·설계·구현·운영까지 가져갈지”에 대한 전체 절차이고, AI 에이전틱 개발은 그 SDLC 각 단계를 AI 에이전트가 함께 수행·자동화하는 방식이라고 보면 이해가 쉽다. 둘은 경쟁 관계가 아니라, 기존 SDLC 위에 “AI 에이전트 레이어”가 얹어지는 구조에 가깝다. ibm

SDLC 핵심 단계 정리

일반적으로 SDLC는 다음 7단계로 많이 정리된다. harness

1. 계획(Planning): 만들 서비스의 목표·범위·리스크·일정 등을 정의한다. ibm
2. 요구사항 분석(Analysis): 유저가 진짜로 무엇을 원하는지 기능·비기능 요구사항을 문서로 구체화한다. devtron
3. 설계(Design): 아키텍처, DB 설계, 모듈 구조, API, UI를 설계 문서로 만든다. geeksforgeeks
4. 구현(Coding/Implementation): 실제 코드를 작성하고 모듈을 통합한다. devtron
5. 테스트(Testing): 단위·통합·시스템·성능 테스트 등으로 버그와 품질 문제를 잡는다. harness
6. 배포(Deployment): 운영 환경에 올리고, 사용자에게 실제로 제공한다. ibm
7. 운영·유지보수(Maintenance): 버그 수정, 성능 개선, 기능 추가, 보안 패치 등을 반복한다. devtron

이 구조는 모바일 앱, 웹 서비스, 백엔드 시스템, AI 서비스 모두에 그대로 적용된다. aws.amazon

AI 에이전틱 개발이란?

요즘 말하는 에이전틱(Agentic) AI 는 “프롬프트 한 번 던지고 끝”이 아니라, 자율적으로 목표를 향해 여러 행동을 연속적으로 수행하는 AI 에이전트 를 뜻한다. denodo

• AI 에이전트 개발: 설계·빌드·학습·테스트·배포까지 포함한 “에이전트 자체를 만드는 프로세스”를 말한다. ibm
• 에이전틱 개발(Agentic development): 개발 프로세스 안에서 AI 에이전트가 코드 작성, 리팩터링, 테스트 생성 등 상당 부분을 직접 수행하는 개발 방식이다. thegnar
• 즉, 하나는 “AI 에이전트를 제품으로 만드는 SDLC 변형(ADLC)” epam
• 다른 하나는 “일반 소프트웨어 SDLC를 돌릴 때, 개발자 대신/와 함께 일하는 AI 동료를 두는 방식”이라고 정리할 수 있다. thinkpalm

SDLC vs 에이전틱 개발 관계

에이전틱 개발 쪽에서 이미 Agentic Development Lifecycle(ADLC) 라는 개념이 제안되어 있는데, SDLC와 거의 1:1 매핑된다. epam

즉, SDLC의 프레임은 그대로 두고, 각 단계의 산출물과 체크포인트에 “AI 특유의 이슈(프롬프트, 데이터 품질, 안전성, 평가 자동화 등)”가 추가된 버전 이라고 보면 된다. epam

각 SDLC 단계에서 AI 에이전트가 하는 일

주니어 개발자 관점에서, “실제로 내 일감이 어떻게 바뀌는지”가 중요하니 단계별로 정리해 보면 다음과 같다. github

1. 계획·요구사항

   • 긴 기획서·회의록을 요약해서 핵심 요구사항/리스크 리스트를 뽑는다. thinkpalm
   • 비슷한 과거 프로젝트·레퍼런스를 찾아 주고, 가능한 범위/우선순위를 제안해 준다. leobit

2. 설계

   • 자연어 요구사항을 입력하면, 대략적인 아키텍처 다이어그램·모듈 구조·API 설계 초안을 뽑아 준다. ibm
   • 대안 설계(모놀리식 vs 마이크로서비스 등)를 비교·장단점 요약도 도와준다. epam

3. 구현

   • 스펙과 기존 코드베이스를 보고 새 기능의 코드 초안을 생성하거나, 대규모 리팩토링을 제안·적용한다. thegnar
   • 반복적인 CRUD·보일러플레이트 코드, DTO/엔티티 매핑 같은 작업을 대폭 줄여 준다. leobit

4. 테스트

   • 요구사항/코드를 분석해서 테스트 케이스 목록과 테스트 코드(Jest, JUnit 등)를 자동 생성한다. thinkpalm
   • PR마다 자동 리뷰·보안 취약점 체크·리그레션 위험 분석을 수행하는 에이전트가 붙을 수 있다. github

5. 배포

   • CI/CD 파이프라인 설정(YAML 등)과 배포 스크립트, 릴리즈 노트 초안을 만들어 준다. github
   • 롤백 전략·헬스체크·모니터링 항목 추천 등 운영 관점 체크리스트를 자동으로 채워 준다. leobit

6. 운영·유지보수

   • 로그·APM·이슈 트래커를 모니터링하면서, 이상 징후를 감지하고 “이슈 요약 + Root cause 후보 + 관련 커밋/PR”을 묶어서 제시한다. thinkpalm
   • 실제 유저 피드백을 분석해, 어떤 기능을 개선할지 우선순위 제안까지 한다. denodo

이렇게 보면, SDLC는 여전히 개발팀이 책임지는 프로세스이고, AI 에이전트는 그 안의 반복적·분석적인 작업을 자동화해주는 “동료 개발자(하지만 휴가 안 가는)” 역할 에 가깝다. github

주니어 개발자가 관점 잡을 때 팁

주니어일수록 AI를 “코드 자동완성 도구”로만 보면 손해다. 에이전틱 관점에서 보면 다음 세 가지를 의식하면 좋다. thegnar

• 단계 인지: 지금 내 작업이 SDLC 어디 단계(요구사항·설계·구현·테스트·운영)에 속하는지 항상 의식한다. ibm
• 역할 분배: 그 단계에서 “사람이 결정해야 할 것(책임·트레이드오프)”와 “AI에게 맡길 수 있는 반복 작업”을 나눈다. thegnar
• 산출물 기준: 각 단계 산출물(요구사항 명세, 설계서, 테스트 시나리오 등)을 AI가 이해하기 좋게 남겨 두면, 이후 단계에서 에이전트 활용도가 기하급수적으로 올라간다. leobit