SDLC는 끝났는가 — AWS가 말하는 AI-DLC와 개발 방식의 재설계

소프트웨어 개발 방법론은 10년 주기로 한 번씩 뒤집혔다. 폭포수에서 애자일로, 애자일에서 데브옵스로. 그리고 지금 AWS는 “다음 전환이 시작됐다”고 말한다. 이번엔 AI-DLC다.

AI-DLC(AI-based Development Life Cycle). 이름만 보면 또 하나의 마케팅 용어 같다. Copilot을 쓰고, AI 코드 리뷰를 붙이고, 자동화 파이프라인을 강화한 — 그냥 SDLC의 업그레이드 아닌가?

결론부터 말하면, 그렇게 볼 수도 있고 전혀 다르게 볼 수도 있다. 어떤 시각으로 보느냐에 따라 팀이 도구를 바꾸는 데 그치느냐, 일하는 방식을 근본적으로 재설계하느냐가 갈린다.

SDLC가 전제한 것들

전통적인 SDLC(Software Development Life Cycle)는 이런 흐름이다.

요구사항 정의 → 설계 → 구현 → 테스트 → 배포 → 운영

이 흐름이 설계된 시대에는 몇 가지 전제가 있었다.

• 사람이 코드를 쓴다. 자동으로 생성되는 코드는 템플릿 수준이거나 보일러플레이트였다.
• 각 단계는 순서가 있다. 설계 없이 구현 못 하고, 구현 없이 테스트 못 한다.
• 병목은 실행 속도다. 더 빠른 개발자, 더 많은 개발자가 곧 더 빠른 속도였다.
• 리뷰와 검증은 뒤에 온다. 코드를 먼저 쓰고, 나중에 검사한다.

AI-DLC는 이 전제들 중 상당수가 더 이상 유효하지 않다는 인식에서 출발한다.

AI-DLC가 다시 설계하는 것

AWS가 Amazon Q Developer를 중심으로 제시하는 AI-DLC는 각 단계에 AI를 얹는 개념이 아니다. 각 단계의 역할과 경계 자체를 다시 그린다.

요구사항 단계: 문서가 프롬프트가 된다

기존엔 요구사항 문서가 개발자가 읽고 해석하는 자료였다. AI-DLC에서는 이 문서가 AI의 입력이 된다. 잘 구조화된 요구사항은 곧 더 정확한 코드 생성으로 이어진다.

Amazon Q Developer는 자연어 설명을 받아 코드 초안, 테스트 케이스, 문서 초안을 동시에 생성한다. 이 말은 요구사항의 품질이 곧 코드의 품질에 직결된다는 뜻이다. “모호하게 써도 개발자가 알아서 해석한다”는 관행이 통하지 않는다.

설계 단계: AI가 아키텍처 리스크를 먼저 본다

AWS의 Amazon CodeGuru는 코드가 작성되기 전 단계에서도 작동한다. 설계 패턴을 분석하고, 보안 취약점이 발생하기 쉬운 구조를 사전에 감지한다. 더 나아가 Amazon Q Developer의 /review 명령은 PR이 올라오기 전에 코드베이스 전체 맥락에서 잠재적 리스크를 찾아낸다.

기존에 설계 리뷰는 시니어 개발자의 경험에 의존했다. AI-DLC에서 시니어의 역할은 리뷰어에서 AI가 놓치는 판단을 하는 사람으로 이동한다.

구현 단계: 작성에서 검증으로

Amazon Q Developer의 핵심은 코드 자동완성이 아니다. 오히려 “이 코드가 맞는지 설명하라”는 방향으로 흐름이 역전된다. 개발자는 코드를 쓰는 사람에서 AI가 쓴 코드를 검증하고 방향을 잡는 사람으로 바뀐다.

이게 단순한 시간 절약이 아니라는 것, 아래 수치가 보여준다.

병목이 구현에서 검증으로 옮겨간다. 이건 개발자의 시간 배분 자체를 바꾼다.

테스트 단계: 후행에서 전행으로

전통적인 TDD(Test-Driven Development)는 이론상 훌륭하지만 실전에서 잘 안 되는 이유가 있다. 테스트 코드를 먼저 쓰는 게 구현보다 어렵고 느리기 때문이다.

AI-DLC에서 Amazon Q Developer는 구현 코드와 동시에 테스트 케이스를 생성한다. 에지 케이스, 경계 조건, 예외 흐름까지 초안을 만들어준다. 개발자는 생성된 테스트를 검증하고 빠진 케이스를 추가하는 역할이 된다.

테스트 단계가 “구현 후 확인”에서 “구현과 동시에 설계”로 바뀐다.

배포/운영 단계: 사후 대응에서 사전 예측으로

AWS의 Amazon DevOps Guru는 ML 기반 이상 탐지로, 장애가 발생하기 전에 비정상 패턴을 감지한다. Amazon Q Developer의 운영 지원 기능은 CloudWatch 로그를 실시간으로 분석하고, 이상 징후에 대한 조치 방안을 제안한다.

기존 운영 업무의 상당 부분이 “왜 터졌나 찾기”에서 “터지기 전에 잡기”로 이동하고 있다.

도구 이야기를 잠깐 걷어내면

AWS 생태계를 중심으로 설명했지만, 이 흐름은 특정 클라우드 벤더의 이야기가 아니다. GitHub Copilot, Google Gemini Code Assist, JetBrains AI Assistant — 방향은 같다.

핵심 질문은 “어떤 도구를 쓸 것인가”가 아니다. **“AI가 코드 생성을 담당한다면, 사람은 무엇을 담당하는가”**다.

이 질문에 명확하게 답하지 못한 채 도구를 도입하면, AI-DLC가 아니라 그냥 비싼 자동완성 도구를 쓰는 팀이 된다.

역할의 재배치

AI-DLC에서 진짜로 달라지는 건 개발자 역할의 무게중심이다.

주니어가 사라지는 게 아니다. 주니어가 해야 하는 일의 종류가 바뀐다. 코드를 타이핑하는 능력보다 AI가 만든 코드를 읽고 판단하는 능력이 더 중요해진다. 이 역량은 연차가 아니라 훈련으로 만들어진다.

이 역할 재배치가 팀 운영 차원에서 어떤 원칙과 구조로 이어지는지는 AI Native 팀 운영 가이드에서 다룬다.

두 가지 함정

함정 1. “AI가 다 해주니까 시니어 안 뽑아도 되겠네”

자주 나오는 오해다. 실제로는 반대다. AI 출력의 품질을 판단하려면 더 강한 도메인 이해가 필요하다. AI가 틀리게 자신감 있게 말하는 경우를 잡아내려면, 오히려 더 깊은 지식이 있어야 한다.

시니어의 가치가 사라지는 게 아니라, 시니어가 가치를 증명해야 하는 방식이 바뀐다. “내가 빨리 짠다”에서 “내가 AI가 못 잡는 걸 잡는다”로.

함정 2. “AI가 쓴 코드니까 리뷰 덜 해도 되겠지”

AI가 생성한 코드는 합리적으로 보이지만 틀릴 수 있다. 테스트를 통과하지만 보안 취약점이 있을 수 있다. 잘 동작하지만 5년 후 유지보수가 불가능한 구조일 수 있다.

AI-DLC에서 리뷰는 줄어드는 게 아니라 바뀐다. “코드가 기능적으로 맞나?”에서 “이 생성된 코드가 우리 팀의 기준과 맥락에 맞나?”로 질문이 달라진다.

지금 당장 팀에서 할 수 있는 것

AI-DLC로 전환한다는 게 거창한 도입 프로젝트를 의미하지 않는다. 방향부터 잡는 것이 먼저다.

1. 요구사항을 AI 입력으로 쓸 수 있게 구조화한다
모호한 문장, 구두 합의, 뇌 속에만 있는 컨텍스트를 글로 꺼낸다. 이것만 해도 AI 활용 품질이 올라간다.

2. AI 출력 검증 기준을 팀 차원에서 만든다
”이 코드를 그냥 머지해도 되는가”의 판단 기준이 개인 센스가 아니라 팀의 체크리스트여야 한다. 보안, 성능, 가독성, 도메인 맥락 — 각각 무엇을 반드시 확인할지 합의한다.

3. 시니어가 “기준 설계자”로 전환하도록 공간을 만든다
시니어가 여전히 가장 빠른 구현자 역할을 해야 하는 구조라면, AI-DLC의 이점을 제대로 못 뽑는다. 기준을 만들고, 검증 포인트를 정의하고, 팀의 컨텍스트를 관리하는 것이 시니어의 핵심 역할이 되어야 한다.

SDLC는 끝났는가

정확히는 이렇게 말하는 게 맞다. SDLC의 단계는 남지만, 각 단계에서 사람이 하는 일의 성격이 바뀐다.

요구사항을 정의하고, 설계하고, 구현하고, 테스트하고, 배포하고, 운영하는 흐름은 사라지지 않는다. 그 흐름 안에서 사람이 타이핑하는 시간이 줄고, 판단하는 시간이 늘어난다. 실행을 AI에 위임하고, 그 실행이 맞는지 판단하는 역할은 사람이 가져간다.

문제는 대부분의 팀이 “실행을 AI에 위임하는 것”만 하고, “판단 체계를 재설계하는 것”은 하지 않는다는 점이다.

Amazon Q Developer를 쓰는 것, GitHub Copilot을 켜는 것은 도구 도입이다. AI-DLC는 그 도구를 전제로 팀의 역할, 검증 프로세스, 요구사항 방식, 리뷰 기준을 다시 설계하는 것이다.

도구를 도입했는데 팀이 달라진 게 없다면, AI-DLC가 아니라 비싼 자동완성 도구를 쓰는 팀에 머물러 있는 것이다.

이 글에서 다룬 팀 운영 관점의 AI 도입은 AI Native 팀 운영 가이드에서 더 자세히 볼 수 있습니다.