SDLC에서의 AI: 엔지니어링 리더들이 놓치고 있는 것

AI는 이미 여러분의 소프트웨어 개발 생명주기 (SDLC)에 들어와 처리량 (throughput)을 높이고 있으며, 아마 여러분은 이미 데이터에서 이를 확인하고 있을 것입니다 – 더 많은 코드, 더 많은 풀 리퀘스트 (pull requests) 등등. 하지만 소프트웨어 인도 (software delivery) 성능은 같은 속도로 향상되지 않고 있습니다. 아마 코드는 여전히 리뷰 단계에 머물러 있을 것입니다. 테스트와 배포가 여전히 흐름 (flow)을 제한하고 있습니다. 예측 가능성은 개선되지 않았습니다:

리뷰 대기열이 길어짐
소프트웨어 테스트가 병목 현상 (bottleneck)이 됨
결함 (defects)과 재작업 (rework)이 증가함
인도가 덜 예측 가능해짐

시스템은 더 빠르게 움직이고 있습니다. 하지만 더 빠르게 '인도'하고 있는 것은 아닙니다.

이 상황이 익숙하게 들린다면, 여러분만의 문제가 아닙니다. 하지만 이것은 도구의 문제도 아닙니다 – 시스템의 문제입니다. AI는 SDLC가 작동하는 속도를 높이고 있습니다. 이것이 더 나은 소프트웨어 인도로 이어질지는 전적으로 그 시스템이 압박 속에서 어떻게 작동하느냐에 달려 있습니다.

AI가 실제로 SDLC를 변화시키는 방식

적절한 조건 하에서 AI는 엔드 투 엔드 (end-to-end)로 인도를 개선할 수 있습니다. 높은 수준에서 보면, 이점은 명확합니다:

소프트웨어 엔지니어링 계획 및 요구사항 정의가 빨라짐
코드 인도가 빨라짐
테스트를 더 일찍 생성할 수 있음
CI/CD 파이프라인이 더 자동화되고 반응적으로 변함

대부분의 팀은 동일한 지점, 즉 개발 (development)에서 시작합니다. 코드 생성 (code generation)을 도입하면 출력량이 거의 즉시 증가하며, 갑자기 더 많은 풀 리퀘스트, 더 많은 변경 사항, 더 많은 작업이 시스템을 통해 이동하게 됩니다. 하지만 SDLC의 나머지 부분은 같은 속도로 변하지 않습니다.

따라서 여러분이 실제로 한 일은 이미 제약 사항 (constraints)이 존재하는 시스템에 작업이 유입되는 속도를 높인 것입니다.

그리고 소프트웨어 인도는 여러분이 얼마나 빨리 작업을 시작할 수 있느냐에 의해 제한되지 않습니다.

그것은 작업이 시스템을 통해 얼마나 빨리 이동할 수 있느냐에 의해 제한됩니다. 대부분의 조직에서 이러한 흐름은 이미 제약되어 있습니다. AI는 기본적으로 이러한 제약을 제거하지 않습니다. 오히려 제약을 드러내고, 그 제약에 압박을 가합니다. 리뷰 (review), 테스트 (testing), 릴리스 (release), 그리고 심지어 상류 단계의 명확성 (upstream clarity) 개선과 같이 이러한 제약이 있는 단계 전반에 AI를 적용한다면, 실질적인 이득을 얻을 수 있습니다.

그렇게 하지 않는다면, 결과는 예측 가능합니다. 더 많은 작업이 시스템으로 유입되지만, 더 빠르게 배출되지는 않습니다.

과제는 소프트웨어 개발에 AI를 구현하는 것이 아니라, 병목 현상 (bottlenecks)을 완화하기 위해 전체 SDLC (Software Development Life Cycle) 전반에 걸쳐 AI를 통합하는 것입니다. 여기에서 소프트웨어 엔지니어링 병목 현상을 식별하고 해결하는 방법을 알아보세요.

리더들이 잘못하고 있는 것: 생성 시점에서 AI를 측정하는 것

이 문제가 실제로 발생하는 지점은 팀이 일어나고 있는 일을 측정하는 방식입니다. 대부분의 팀은 의미 있는 엔지니어링 생산성 지표 (engineering productivity metrics) 대신 다음과 같은 활동 (activity)을 추적합니다:

도입 (adoption)
프롬프트 사용 (prompt usage)
생성된 코드 (code generated)
오픈된 풀 리퀘스트 (pull requests opened)

이는 이해할 수 있는 부분입니다. 눈에 잘 보이고 빠르게 움직이기 때문입니다. 하지만 이는 가장 의미 없는 신호가 발생하는 지점이기도 합니다. AI는 코드가 작성될 때 가치를 창출하는 것이 아니라, 그 코드가 품질을 유지하며 제시간에 프로덕션 (production)에 전달될 때 가치를 창출합니다. 만약 개발 활동 (development activity)에만 집중한다면, 실제 배포 (delivery)가 어디에서 느려지는지를 놓치게 됩니다.

코드 리뷰 (code review)에서 대기 중인 작업
소프트웨어 테스트 및 QA (Quality Assurance)에서 쌓이는 대기열 (queues)
병합 (merge)과 배포 (deployment) 사이의 지연
SDLC (Software Development Lifecycle) 단계 사이의 차단 요소 (blockers)

이러한 지연은 코드 산출물보다 가시성이 낮기 때문에 종종 무시됩니다. 이것이 팀들이 잘못된 진척도 (false sense of progress)를 느끼게 되는 방식입니다. 흔히 다음과 같은 패턴이 나타납니다:

더 많은 결함 (defects) 발생
더 많은 재작업 (rework) 및 버그 수정 (bug fixing)
지원 및 유지보수 (support and maintenance)에 더 많은 역량 (capacity) 투입
로드맵 달성 (roadmap delivery)에 할애되는 시간 감소

결과적으로 시스템은 더 바빠지지만, 그 노력 중 가치에 기여하는 부분은 줄어듭니다. 가치 전달 (value delivery)을 줄이면서 출력량 (output)만 쉽게 늘릴 수 있습니다. 만약 흐름 (flow)이 개선되지 않았거나 품질 (quality)이 저하되고 있다면, 의미 있는 개선은 이루어진 것이 아닙니다. 그저 시스템이 흡수해야 할 작업량만 늘어난 것입니다.

소프트웨어 개발 생명주기 (SDLC)에서 AI의 영향력을 측정하는 방법

AI가 활성화된 SDLC를 시스템 수준에서 바라보는 것이 중요한 이유는, 우리가 AI의 영향을 네 가지 연결된 차원인 **집중 (Focus), 속도 (Speed), 예측 가능성 (Predictability), 그리고 품질 (Quality)**을 통해 살펴보기 때문입니다.

우리는 이를 **생산성의 네 가지 기둥 (Four Pillars of Productivity)**이라고 부릅니다.

이 요소들이 함께 개선되고 있다면 AI가 제대로 작동하고 있는 것입니다. 만약 하나는 개선되는데 다른 요소들이 저하된다면, 실제로 생산성 이득을 얻고 있는 것이 아닙니다. 단지 문제를 다른 곳으로 옮기고 있을 뿐입니다.

기둥 1: 집중 (Focus) – 더 많은 가치를 창출하고 있습니까, 아니면 단지 더 많은 작업을 만들고 있습니까?

첫 번째 실패 모드 (failure mode)는 간단합니다. 팀이 활동 (activity)을 진척 (progress)으로 착각하는 것입니다.

AI는 출력량 (output)을 증가시킵니다. 이는 명백합니다. 하지만 중요한 것은 당신의 역량 (capacity)이 어디로 향하고 있느냐 하는 것입니다. 만약 AI가 다음과 같은 결과를 초래한다면:

더 많은 결함 (defects)

더 많은 재작업 (rework)
더 많은 지원 및 유지보수 (support and maintenance)
구축 (building) 대신 수정 (fixing)에 더 많은 시간을 소비하게 된다면, 이는 집중력이 향상된 것이 아니라 감소한 것입니다. 바로 이 지점에서 많은 팀이 조용히 뒤처지기 시작합니다. 그들은 더 바빠 보이지만, 실제 노력 중 로드맵 (roadmap)을 앞으로 나아가게 하는 데 쓰이는 비율은 더 작아집니다. AI는 가치 전달 (value delivery)에 소비되는 시간을 늘려야 합니다. 많은 팀에서 AI는 그 반대의 결과를 초래합니다.

Pillar 2: 속도 (Speed) – 더 빠르게 전달하고 있습니까, 아니면 그저 시스템에 더 빠르게 먹이를 주고 있습니까?

대부분의 팀은 여기서 가장 먼저 이득을 보지만, 바로 이 지점이 많은 팀이 실제로 일어나고 있는 일을 오해하는 부분입니다. 그렇습니다, AI는 개발자를 더 빠르게 만듭니다. 하지만 전달 속도 (delivery speed)는 코딩 속도 (coding speed)가 아닙니다. 그것은 작업이 아이디어에서 프로덕션 (production)으로 얼마나 빨리 이동하느냐 하는 것입니다. 그리고 바로 그 지점에서 문제가 발생하곤 합니다. 더 많은 코드를 생성하지만:

PR (Pull Request)이 리뷰 (review) 단계에서 더 오래 머무름

시니어 엔지니어 (senior engineers)가 병목 현상 (bottlenecks)이 됨
머지 (merge) 전에 대기열 (queues)이 쌓임
테스트 (testing) 및 검증 (validation)이 뒤처짐

결과적으로 시스템으로 유입되는 처리량 (throughput)은 증가하지만, 시스템을 통과하는 흐름 (flow)은 증가하지 않습니다. 이는 가치 도달 리드 타임 (lead time to value) 및 사이클 타임 (cycle time)과 같은 지표에 나타납니다. 이것이 리드 타임이 개선되지 않고, 어떤 경우에는 실제로 악화되는 이유입니다.

Pillar 3: 예측 가능성 (Predictability) – 여전히 전달 과정을 제어하고 있습니까?

이 지점은 AI가 더 깊은 문제들을 드러내기 시작하는 곳입니다. 출력량 (output)이 증가함에 따라 변동성 (variability)도 함께 증가합니다. 다음과 같은 현상이 나타납니다:

스프린트 (sprint) 중간에 더 많은 범위 변경 (scope change)

덜 안정적인 계획 (planning)
더 일관성 없는 전달 (delivery)
조정 (coordination)에 대한 더 큰 의존도

시스템이 압박을 받고 있기 때문입니다. 더 많은 코드는 더 많은 의사결정을 의미합니다. 더 많은 의사결정은 더 많은 의존성 (dependencies), 더 많은 핸드오프 (handoffs), 그리고 상황이 느려질 수 있는 더 많은 기회를 의미합니다.

강력한 전달 규율 (delivery discipline) 없이는, AI는 팀을 더 예측 가능하게 만들지 않습니다. 오히려 시스템을 제어하기 더 어렵게 만듭니다.

Pillar 4: 품질 (Quality) – 출력량을 확장하고 있습니까, 아니면 재작업 (rework)을 확장하고 있습니까?

이것은 가장 위험한 실패 모드이며, 대부분의 팀이 가장 과소평가하는 부분입니다. 더 빠른 코드 생성은 진전이 이루어지고 있다는 환상을 만들어내지만, 결국 품질 문제가 뒤따라오게 됩니다. 만약 리뷰(Review)와 테스트(Testing)가 확장되지 않는다면, 다음과 같은 결과가 발생합니다:

더 많은 결함(Defects) 유입
출력 단위당 더 많은 버그(Bugs) 발생
더 길어지는 해결 시간(Resolution times)
늘어나는 결함 백로그(Defect backlogs)

그리고 시간이 흐르면서, 더 구조적인 문제가 발생합니다. 단순히 코드뿐만 아니라 시스템 전반에 걸쳐 기술 부채(Technical debt)가 쌓이기 시작합니다:

이해하고 리뷰하기 더 어려워진 코드
더 취약해진 통합(Integrations)
변경 사항을 안전하게 적용하기 위해 더 많은 노력 필요

이 시점에 이르면, 시스템은 스스로를 갉아먹기 시작합니다.

새로운 가치를 전달하는 대신, 이미 구축된 것을 수정하고, 재작업(Reworking)하고, 안정화하는 데 점점 더 많은 역량이 투입됩니다. 바로 이때 AI는 승수(Multiplier)로서의 역할을 멈추고 오버헤드(Overhead)가 되기 시작합니다.

SDLC에 AI를 구현하는 방법 (전달력을 해치지 않으면서)

대부분의 팀은 소프트웨어 엔지니어링에서의 AI 도입을 단순한 도구 배포(Tooling rollout)로 취급합니다. 이들은 사용량을 추적하고, 실험을 장려하며, 결과가 뒤따라오기를 기대합니다. 하지만 결과가 나타나지 않을 때, 그 이유가 무엇인지는 명확하지 않습니다. 도구가 사용되는 방식의 문제일까요? SDLC의 문제일까요? 아니면 영향력(Impact)을 측정하는 방식의 문제일까요?

우리는 2,000개 이상의 팀을 대상으로 한 벤치마크 데이터와 우리가 협업하는 기업들을 통해 이를 반복적으로 목격해 왔습니다. 팀들은 결국 _"우리가 AI를 사용하고 있는가?"_에서 바로 _"ROI(투자 대비 효율)는 무엇인가?"_로 건너뛰어 버리지만, 정작 그 답이 들어있는 단계는 건너뛰고 맙니다.

우리는 엔지니어링 리더들이 이 문제를 해결할 수 있도록 **RACER 프레임워크 (RACER Framework)**를 사용합니다. 이는 AI 도입을 실제 진행되는 순서에 따라 하나의 시스템으로 바라보는 방식입니다.

R – Rollout (배포)

팀들이 일상 업무에서 도구들을 사용하고 있습니까? 하지만 Rollout은 AI가 어디에 존재하는지만 알려줄 뿐입니다. 그것이 인도(delivery)를 개선하고 있는지에 대해서는 아무것도 말해주지 않습니다.

A – Approach (접근 방식)

팀들이 실제로 업무 수행 방식을 개선하는 방식으로 AI를 사용하고 있습니까? 대부분의 팀은 즉각적이고 눈에 보이기 때문에 코드 생성 (code generation)에 집중합니다. 테스트 (testing), 문서화 (documentation), 리팩터링 (refactoring) 또는 상류 작업 (upstream work)에 AI를 적용하는 팀은 훨씬 적습니다. 따라서 시스템의 나머지 부분에서 업무가 이동하는 방식은 개선하지 못한 채, 개발 단계의 산출물만 늘리게 됩니다.

C – Constraints (제약 사항)

무엇이 이득을 제한하고 있습니까? 어느 시점에서든 모든 팀은 이에 직면합니다. AI는 처리량 (throughput)을 증가시킵니다. 그러면 SDLC 내의 다른 요소가 제한 요인 (limiting factor)이 됩니다. 그것은 리뷰 (review), 테스트 (testing), 요구사항 (requirements), 릴리스 (release) 또는 이들의 조합일 수 있습니다. 팀마다 다르지만, 항상 제약 사항은 존재합니다. 대부분의 진전이 정체되는 지점은 도구가 작동하지 않아서가 아니라, 시스템이 그 변화를 흡수할 수 없기 때문입니다.

E – Engineering Impact (엔지니어링 영향)

시스템이 실제로 더 나은 성능을 내고 있습니까? AI가 제대로 작동하고 있다면, 그것은 인도 (delivery) 측면에서 나타납니다:

가치 전달 (value delivery)에 더 많은 시간 투입
아이디어에서 프로덕션 (production)까지의 더 빠른 이동
더 예측 가능한 실행 (predictable execution)
안정적이거나 개선된 품질

만약 이 요소들이 함께 개선되지 않는다면, 그것은 생산성 향상이 아닙니다. 단지 활동량만 늘어난 것입니다.

R – Results (결과)

이것이 성과 (outcomes)로 이어지고 있습니까? 시스템이 개선되어야만 다음과 같이 결과가 명확해집니다:

가치 실현 시간 (time to value) 단축
로드맵 수용 능력 (roadmap capacity) 증가
재작업 (rework) 감소
엔지니어링 시간의 더 나은 활용

이 지점이 AI가 비즈니스 수준에서 의미를 갖게 되는 단계입니다.SDLC에서 AI 도입에 어려움을 겪고 계십니까? RACER 프레임워크를 이해해 보세요

Plandek의 역할: AI 활동을 인도 성능(delivery performance)으로 전환하기

AI는 SDLC(소프트웨어 개발 생명 주기) 전반의 처리량(throughput)을 높이고 있습니다. 하지만 이를 통해 실제로 더 나은 성능이 나타나고 있는지, 아니면 단순히 새로운 제약 사항과 리스크를 드러내고 있는지를 파악하는 것은 훨씬 더 어렵습니다. 팀들은 보통 누가, 얼마나 자주, 얼마나 많이 AI를 사용하는지는 추적할 수 있습니다. 하지만 다음과 같은 사항을 파악하는 데 어려움을 겪습니다:

인도가 실제로 더 빨라졌는지
처리량이 증가함에 따라 업무가 어디에서 지연되고 있는지
품질(quality)과 예측 가능성(predictability)이 어떻게 변하고 있는지
가용 용량(capacity) 중 얼마만큼이 가치 인도(value delivery)에 쓰이고, 얼마만큼이 재작업(rework)에 쓰이고 있는지

Plandek은 바로 그 격차를 메우기 위해 구축되었습니다. Plandek은 SDLC에 대한 시스템 수준의 뷰(view)를 제공하여, 단순히 활동(activity)이 아닌 AI가 인도 성능(delivery performance)에 어떤 영향을 미치는지 측정할 수 있게 합니다. 고립된 신호에 의존하는 대신, 시스템의 한 부분에서 발생하는 변화가 전체에 어떤 영향을 미치는지 확인할 수 있습니다. 우리가 설명한 동일한 네 가지 차원을 사용하여, Plandek은 다음 사항을 이해하도록 돕습니다:

집중(Focus) – AI가 로드맵 작업에 소요되는 시간을 늘리고 있는지, 아니면 지원, 재작업 및 기술 부채(technical debt)로 용량(capacity)을 끌어다 쓰고 있는지
속도(Speed) – 업무가 단순히 시스템에 더 빨리 유입되는 것이 아니라, 아이디어에서 프로덕션(production)까지 실제로 더 빠르게 이동하고 있는지
예측 가능성(Predictability) – 처리량이 증가함에 따라 인도가 더 일관되게 변하고 있는지, 아니면 더 변동성이 커지고 있는지
품질(Quality) – 결함(defects), 재작업(rework) 및 기술 부채(technical debt)가 증가하고 있는지 아니면 통제되고 있는지