SDLC는 죽었다: AI 에이전트와 새로운 개발 루프

SDLC는 사라졌다: AI 에이전트가 개발 라이프사이클을 단단한 루프로 축소한 방법

AI 에이전트는 SDLC를 최적화한 것이 아니라, 아예 없애버렸다. 순차적인 단계, 수동 인수인계, 티켓, 그리고 각종 의식으로 구성된 전통적인 소프트웨어 개발 라이프사이클은 더 이상 현대 개발의 현실을 반영하지 않는다. 대신, 인간이 의도를 설정하고, 에이전트가 테스트와 인프라를 포함한 작동 가능한 코드를 생성하며, 관찰 시스템이 자동으로 검증·수정·배포를 관리하는 지속적이고 비동기적이며 맥락 기반의 루프라는 새로운 패러다임이 등장했다. 이는 단순한 가속이 아니라, 근본적인 기반의 변화이다.

왜 SDLC는 더 이상 하나의 프로세스로 존재하지 않는가

전통적인 SDLC(워터폴, 애자일, 데브옵스)는 요구사항 수집 → 설계 → 구현 → 테스트 → 검토 → 배포 → 모니터링이라는 분리된 단계들을 전제로 했다. 각 단계마다 고유한 도구, 지표, 역할, 그리고 의식들이 있었다: Jira는 추적을 위해, Figma는 디자인을 위해, GitHub PR은 검토를 위해, Datadog는 알림을 위해 사용됐다. 하지만 이 시스템이 구식이 된 핵심 신호는 복잡성 자체가 아니라, ‘수동 인수인계의 필요’에 있다. 에이전트가 의도부터 생산 준비 완료된 아티팩트까지 전체 스택을 처리하게 되면, 단계들 사이의 경계가 물리적으로 사라진다. 디자이너에서 개발자로의 ‘인수인계’는 더 이상 없다. 왜냐하면 에이전트가 UX 사양을 동시에 해석하고, 컴포넌트를 생성하며, 엔드투엔드 테스트를 통해 이를 검증하기 때문이다. ‘검토를 위한 대기’도 없다. 왜냐하면 검증이 생성 과정에 내재되어 있기 때문이다: 적대적 에이전트가 커밋 전에 보안, 성능, 계약 준수 여부를 분석한다. 이것은 ‘애자일 3.0’이 아니다. 프로세스 중심의 모델에서 의도 기반 아키텍처로의 전환이다.

SDLC의 각 단계가 어떻게 맥락으로 축소되었나

요구사항 수집은 더 이상 문서가 아니다. 동적 맥락으로 변모했다. PRD는 더 이상 미리 고정되지 않는다. 엔지니어가 자연어로 작업을 설명하면(“Okta를 통한 SSO용 OAuth2 지원 추가, 로컬 인증과 엄격한 토큰 검증을 백업으로”), 에이전트는 서로 다른 트레이드오프를 가진 세 가지 구현 옵션을 생성한다(상태 없는 vs 상태 있는 세션 스토어, JWT 파싱 전략). 선택은 벤치마크와 텔레메트리에 기반해 이루어진다. 요구사항은 입력 조건이 아니라, 반복의 부산물이 된다.

시스템 설계는 이제 실시간 대화가 됐다. 에이전트는 단순히 완성된 아키텍처를 구현하는 것이 아니라, 그것을 제안한다. “1만 RPS를 위한 장애 허용 이벤트 버스가 필요하다”는 요청에 대해, 에이전트는 Kafka, NATS JetStream, Materialize를 비교하고, 지연 SLA, 백만 건당 비용, 운영 복잡성을 고려하여 Terraform 모듈, 관찰 구성, 심지어 부하 테스트 스크립트까지 생성한다. 아키텍처는 더 이상 정적인 다이어그램이 아니다. 실행 가능하고 적응력 있는 계약이 된다.

구현은 완전히 위임된다. 현대 에이전트(Cursor, Continue.dev, Tabby)는 함수뿐만 아니라 Swagger 문서, 헬스체크 엔드포인트, 미들웨어 체인, 타입 안전 DTO까지 포함한 전체 마이크로서비스를 생성한다. 에이전트는 예외 상황까지 처리한다. 예를 들어, REST API용 HTTP 클라이언트를 생성할 때, 에이전트는 명시적인 프롬프트 없이도 지수적 백오프, 회로 차단, 컨텍스트 취소 기능을 갖춘 재시도 정책을 자동으로 추가한다. 인간은 코드를 작성하는 대신, 의도를 검증하는 데 집중한다.

테스트는 생성 단계에 통합된다. 에이전트는 코드와 함께 유닛, 통합, 엔드투엔드 테스트를 생성하며, 같은 의미론을 사용한다. calculateTax(amount, region) 함수를 생성할 때, 에이전트는 즉시 경계값, 유효하지 않은 지역, 화폐 변환에 대한 테스트를 작성한다. TDD는 방법론이 아니라, 기본 행동이 된다. QA라는 역할은 사라졌다: ‘QA에게 인수인계’가 없기 때문이다. 왜냐하면 검증이 루프 내에서 이루어지기 때문이다.

코드 리뷰는 수동 프로세스로서의 의미를 잃었다. 하루에 500개의 PR을 사람이 검토하는 것은 기술적으로 말도 안 되는 일이다. 대신 다음과 같은 방식이 사용된다:

• 적대적 코드 리뷰: 두 번째 에이전트가 생성된 코드를 보안 취약점(CWE-79, CWE-89), 성능 안티패턴(N+1 쿼리, 무제한 재귀), 내부 RFC 준수 여부 등을 분석한다.
• 맥락 인식 린팅: 규칙이 에이전트의 LSP 서버에 내장되어 실시간으로 트리거된다.
• 인간-인-더-루프는 오직 고위험 변경에만 적용된다: 아키텍처 결정, 핵심 도메인 로직 변경, 또는 에이전트의 신뢰 점수가 0.92 미만일 때.

배포는 지속적이고 자율적이게 되었다. 에이전트는 코드뿐만 아니라 기능 플래그, 카나리아 분석, 자동 롤백을 포함한 CI/CD 파이프라인까지 생성한다. 예:

- name: 트래픽 전환과 함께 배포
  uses: actions/deploy@v3
  with:
    canary-percent: 5
    success-threshold: "latency_p95 < 200ms && error_rate < 0.1%"
    rollback-on-failure: true

릴리스는 이벤트가 아니라 상태다: 코드는 게이트를 통과한 직후 바로 라이브가 되고, 기능 활성화는 라우팅 규칙(예: Envoy RDS)에 의해 제어된다. 에이전트는 배포를 모니터링하고 실시간으로 트래픽을 조정한다.

남은 것: 맥락과 폐쇄 루프 피드백

SDLC 전체에서 살아남은 요소는 단 두 가지뿐이다:

• 맥락—유일한 진실의 원천. 맥락의 품질(사양의 정확성, 도메인 모델의 깊이, 아키텍처 제약의 관련성)이 결과를 직접 결정한다. 맥락 엔지니어링은 새로운 시스템적 기술이다: 의도를 공식화하고, 맥락 변화의 이력을 관리하며, 비즈니스 규칙을 버전화하는 것이다.
• 관찰—온콜 엔지니어를 위한 도구가 아니라, 에이전트를 위한 폐쇄 루프 피드백이다. 메트릭스, 로그, 트레이스는 에이전트가 해석할 수 있도록 구조화되어야 한다. 예를 들어, error_rate{service="payment", version="v2.4"}는 에이전트를 트리거하고, 에이전트는 v2.4를 v2.3과 비교해 validateCardExpiry()에서의 회귀를 발견한 후 핫픽스를 제안한다.

무엇이 중요한가

• SDLC는 더 이상 속도를 내는 것이 아니라, 선형 프로세스로서 사라졌다; 남은 것은 단지 의도 → 구축 → 관찰 루프뿐이다.
• 코드 리뷰는 수동 PR 검사로서의 역할은 러디즘이다. 대신 적대적 에이전트와 고위험 결정을 위한 인간-인-더-루프를 사용해야 한다.
• 요구사항과 아키텍처는 이제 문서에 고정되는 것이 아니라, 실시간으로 생성되고 검증된다.
• 배포와 릴리스는 분리되었다: 코드는 지속적으로 배포되고, 기능 활성화는 트래픽에 의해 관리된다.
• 미래의 핵심 기술은 Jira나 GitFlow를 아는 것이 아니라, 맥락 엔지니어링이다.

에이전트가 하루에 수백 건의 변경을 배포하는 세상에서는, 전통적인 프로세스가 느리다는 것만이 문제가 아니다. 오히려 오류의 원천이다. 관찰 시스템을 폐쇄 루프로 전환해 텔레메트리가 에이전트를 직접 제어하도록 한 팀들은 속도뿐만 아니라 회복력까지 얻는다: 회귀는 사람들이 알아차리기도 전에 더 빨리 수정된다. 반면 다른 팀들은 Datadog에서 대시보드를 계속 조정하면서, 데이터가 이미 에이전트에 의해 자동 복구에 사용되고 있다는 사실조차 모르고 있다—그들의 개입 없이 말이다.

— Editorial Team