SDLC에서 AI 에이전트: 왜 작업 자동화만으로는 충분하지 않은가

오늘날 소프트웨어 개발에서의 AI에 대한 대부분의 대화는 하나의 질문을 중심으로 돌아갑니다. '어떤 작업을 자동화할 수 있을까?' AI 에이전트는 요구사항 정제(requirements refinement)를 도울 수 있습니다. 코드를 생성할 수 있고, 단위 테스트(unit tests)를 작성할 수 있으며, 문서를 준비할 수 있습니다. 코드 리뷰를 수행하거나 배포 체크리스트(deployment checklist)에 도움을 줄 수도 있습니다. 그리고 네, 작동합니다. 팀은 더 빠르게 결과를 얻습니다. 반복적인 작업이 줄어듭니다. 엔지니어들은 아이디어를 구현으로 훨씬 더 빨리 옮길 수 있게 됩니다. 하지만 이 접근 방식에는 우리가 종종 과소평가하는 한 가지 문제가 있습니다. 우리는 AI 에이전트가 무엇을 할 수 있는지에 대해 많이 이야기합니다. 하지만 AI 에이전트가 무엇을 남기는지에 대해서는 거의 이야기하지 않습니다. 문제점은 다음과 같습니다: AI가 작업을 완료했지만, 컨텍스트(context)가 사라집니다. 간단한 시나리오를 상상해 봅시다. AI 에이전트가 비즈니스 분석가(business analyst)가 사용자 스토리(user story)를 분해하는 것을 도왔습니다. '인터뷰 과정' 동안 질문을 했고, 수용 기준(acceptance criteria)을 공식화하는 데 도움을 주었으며, 몇 가지 엣지 케이스(edge cases)를 식별했고, 구조를 제안했습니다. 하지만 컨텍스트는 어떻게 되었을까요? 예를 들어: 어떤 결정이 내려졌는지; 어떤 대안들이 거부되었는지; 어떤 엣지 케이스가 발견되었는지; 어떤 가정이 남아 있는지; 다음에 어떤 질문을 확인해야 하는지. 매우 자주 이 컨텍스트는 하나의 채팅, 하나의 프롬프트 기록 안에 머물거나, 작업이 완료된 후 완전히 사라집니다. 다음 에이전트나 다음 엔지니어는 거의 제로(zero)부터 다시 시작합니다. 그들은 다시 묻습니다: '우리는 왜 이 접근 방식을 선택했나요?' '왜 다른 라이브러리를 사용하지 않았나요?' '어떤 엣지 케이스가 이미 발견되었나요?' '이전에는 어떤 배포 위험이 있었나요?' '이 프로젝트에서 좋은 솔루션이란 무엇으로 간주되나요?' 바로 여기서 AI 통합의 실제 비용이 나타나기 시작합니다. 우리는 토큰(tokens)에 대해서만 지불하는 것이 아닙니다. 사람들이 AI에서 비용 최적화에 대해 이야기할 때, 그들은 보통 더 저렴한 모델, 3S 원칙에 맞춰 조정된 짧은 프롬프트, 또는 더 작은 컨텍스트 창을 의미합니다. 이것은 중요하지만, 그것은 문제의 일부일 뿐입니다. 더 큰 문제는 조직이 동일한 컨텍스트 발견(context discovery)에 대해 반복적으로 비용을 지불한다는 것입니다.

다시 말해, 에이전트(agent)는 이미 이전에 발견된 사항들, 즉 아키텍처 원칙(architectural principles), 제품 제약 조건(product constraints), 비즈니스 규칙(business rules), 알려진 결함(known defects), 전형적인 엣지 케이스(typical edge cases), 기술적 트레이드오프(technical trade-offs)의 이면에 있는 이유, 배포를 통해 얻은 교훈(deployment lessons learned) 등을 이해하기 위해 시간과 토큰(tokens)을 소비합니다. 만약 모든 AI 상호작용이 단순히 작업 출력물로만 끝난다면, 우리는 속도는 얻을 수 있지만 지식은 축적하지 못하게 됩니다. 이는 문제를 빠르게 해결하지만, 아무런 메모도, 설계도도, 그리고 왜 솔루션이 이런 방식으로 설계되었는지에 대한 설명도 남기지 않고 떠나버리는 매우 똑똑한 컨설턴트를 고용하는 것과 같습니다. 네, 작업은 완료되었습니다. 하지만 다음 사람은 여전히 처음부터 다시 시작해야 할 것입니다. AI 도입의 다음 단계는 자동화뿐만 아니라 컨텍스트 축적(context accumulation)에 있습니다. 제 생각에 SDLC에서 AI 도입의 다음 단계는 단순히 작업 자동화(task automation)만을 중심으로 구축되어서는 안 됩니다. 컨텍스트 축적의 문제도 해결해야 합니다. 모든 AI 보조 작업은 하나의 결과가 아닌 두 개의 결과를 만들어내야 합니다. 첫 번째 결과는 명확하며, AI 에이전트(AI Agent)로부터 기대되는 결과물입니다. 예를 들어: 정제된 사용자 스토리(user story), 생성된 코드(generated code), 테스트 케이스(test cases), 코드 리뷰 코멘트(code review comments), 릴리스 노트(release notes), 배포 계획(deployment plan), 기술 문서(technical documentation) 등이 있습니다. 두 번째 결과는 덜 명확하지만 장기적인 효율성을 위해 훨씬 더 중요합니다. 그것은 재사용 가능한 컨텍스트 자산(reusable context asset), 즉 향후에 재사용할 수 있는 컨텍스트 산출물(context artifact)입니다. 예를 들어: 정제 과정에서 발견된 비즈니스 규칙(business rule), 아키텍처 결정(architectural decision), 특정 라이브러리가 거부된 이유, 전형적인 인수 기준(acceptance criteria) 패턴, 알려진 실패 패턴(failure pattern), 업데이트된 배포 체크리스트(deployment checklist), 보안 제약 조건(security constraint), 테스트 데이터 가정(test data assumption), 프로젝트 특정 코딩 규칙(project-specific coding rule), 향후 확인해야 할 엣지 케이스(edge case) 등이 있습니다. 아이디어는 간단합니다. AI 에이전트는 단순히 작업을 완료하는 것에 그쳐서는 안 됩니다. 다음 작업을 더 저렴하고, 빠르고, 더 낫게 만드는 컨텍스트를 남겨야 합니다.

실제 사례에서는 다음과 같이 보일 수 있습니다

요구사항 에이전트(Requirements agent)
전통적인 접근 방식: 에이전트가 사용자 스토리를 명확히 하고 인수 기준(acceptance criteria)을 생성합니다.

Context Accumulation (문맥 축적) 접근 방식: 에이전트가 사용자 스토리(user story)를 명확히 하고 인수 기준(acceptance criteria)을 생성할 뿐만 아니라, 재사용 가능한 문맥(context)을 저장합니다. 예를 들어: 새로운 비즈니스 규칙, 미결 질문 목록, 용어 및 용어집, 이해관계자와 내린 결정, 유효한 동작 및 유효하지 않은 동작의 예시, 향후 사용자 스토리를 위한 전형적인 패턴 등이 이에 해당합니다. 그러면 다음 정제(refinement) 프로세스는 처음부터 시작하지 않습니다. 에이전트는 이미 이전의 비즈니스 규칙과 패턴을 사용할 수 있습니다.

Development agent (개발 에이전트)
전통적인 접근 방식: 에이전트가 코드를 생성하거나 변경합니다.
Context Accumulation (문맥 축적) 접근 방식: 에이전트가 코드를 생성하면서 향후 변경에 유용할 수 있는 문맥을 포착합니다. 예를 들어: 어떤 코딩 패턴이 사용되었는지, 어떤 트레이드오프(trade-offs)가 이루어졌는지, 어떤 의존성(dependencies)이 추가되었으며 그 이유는 무엇인지, 어떤 제약 사항(constraints)이 고려되었는지, 솔루션의 어느 부분을 재사용할 수 있는지, 향후 리팩터링(refactoring) 시 주의가 필요한 영역은 어디인지 등을 저장합니다. 이는 AI가 여러 엔지니어를 동시에 지원하는 팀에서 특히 중요합니다. 공유된 문맥이 없다면, 각 에이전트는 서로 다른 스타일과 접근 방식을 제안할 수 있으며 동일한 실수를 반복할 수 있습니다.

QA agent (QA 에이전트)
전통적인 접근 방식: 에이전트가 테스트 케이스를 생성합니다.
Context Accumulation (문맥 축적) 접근 방식: 에이전트가 테스트 케이스를 생성하고 재사용 가능한 테스트 지식을 저장합니다. 예를 들어: 발견된 엣지 케이스(edge cases), 회귀 시나리오(regression scenarios), 테스트 데이터 가정, 알려진 실패 패턴, 위험한 제품 영역, 향후 점검을 위한 규칙, 특정 모듈의 변경 후 항상 테스트해야 하는 시나리오 등이 있습니다. 그러면 에이전트가 테스트를 "아무 근거 없이" 생성하지 않기 때문에 다음 QA 사이클이 더 빨라집니다. 에이전트는 축적된 제품 문맥에 의존하게 됩니다.

Deployment agent (배포 에이전트)
전통적인 접근 방식: 에이전트가 릴리스 계획 또는 배포 체크리스트 작성을 돕습니다.
Context Accumulation (문맥 축적) 접근 방식: 에이전트가 배포 계획을 준비하고 학습된 교훈(lessons learned)을 포착합니다.

예를 들어: 이전 배포 중에 무엇이 고장 났는지, 어떤 롤백 (rollback) 경로가 작동했는지, 어떤 환경 변수 (environment variable)가 누락되었는지, 어떤 알림 (alerts)이 추가되어야 하는지, 어떤 수동 점검 (manual checks)이 남아 있는지, 다음 릴리스 (release) 전에 어떤 리스크 (risks)를 확인해야 하는지 등을 포함합니다. 이렇게 하면 배포 지식이 릴리스 사이에 소실되지 않습니다. 이는 문서화 (documentation)와는 다릅니다. 어떤 이들은 "하지만 이것은 단지 문서화일 뿐이다"라고 말할 수도 있습니다. 정확히는 그렇지 않습니다. 전통적인 문서화는 종종 작업이 완료된 후에 생성됩니다. 작업은 이미 종료되었고, 팀은 다음 스프린트 (sprint)로 넘어갔으며, 일부 세부 사항은 이미 잊혀진 상태입니다. 문맥 축적 (Context accumulation)은 다르게 작동합니다. 문맥은 작업의 실행 중에 포착됩니다. 에이전트는 단순히 작업만 수행하는 것이 아닙니다. 작업으로부터 재사용 가능한 작은 지식 파편들을 추출합니다. 아무도 읽지 않는 거대한 20페이지짜리 문서가 아닙니다. 대신 다음에 사용할 수 있는 짧고 구조화된 문맥 자산 (context assets)입니다. 예를 들어:

context_asset : type : business_rule title : 송장 생성 전 취소 description : 프리미엄 사용자는 송장이 생성되기 전까지만 구독을 취소할 수 있음. source : requirements_refinement status : validated reusable_for : - requirements_agent - qa_agent - support_documentation

또는:

context_asset : type : failure_pattern title : ECS 배포 중 환경 변수 누락 description : 대상 환경에 PAYMENT_API_URL이 구성되지 않아 배포가 실패함. source : deployment_review status : validated reusable_for : - deployment_agent - release_checklist - infrastructure_review

이것은 더 이상 단순한 메모가 아닙니다. 이것은 검증되었으며 재사용 가능한 구조화된 문맥 (structured context)입니다.

이것은 단순한 에이전트 메모리 (agent memory)가 아닙니다. 또 다른 가능한 반응은 "이것은 단지 에이전트 메모리 아닌가요?"일 것입니다. 부분적으로는 맞습니다. 하지만 중요한 차이점이 있습니다. 에이전트 메모리는 보통 하나의 에이전트가 자신의 향후 상호작용을 위해 무언가를 기억하는 것을 의미합니다. 여기서의 아이디어는 더 광범위합니다. 목표는 단 하나의 에이전트가 무언가를 기억하는 것이 아닙니다.

목표는 다음과 같은 대상들이 사용할 수 있는 공유 가능한 컨텍스트 (Context)를 생성하는 것입니다: 다른 에이전트 (Agents); 다른 사람들; 다른 팀; 미래의 전달 흐름 (Delivery flows); 온보딩 프로세스 (Onboarding processes); QA; DevOps; 아키텍트 (Architects); 지원 팀 (Support teams). 즉, 컨텍스트는 한 에이전트의 개인적인 기억이 아니라, 지식 베이스 (Knowledge base)의 일부가 됩니다.

모델의 변화
현재의 모델은 대략 다음과 같습니다:
에이전트 (Agent) → 작업 결과물 (Task Output) → 완료 (Done)
하지만 이 모델에서는 가치가 종종 작업과 함께 종료됩니다.

컨텍스트 축적 (Context Accumulation) 모델은 다릅니다:
에이전트 (Agent) → 작업 결과물 (Task Output) + 재사용 가능한 컨텍스트 자산 (Reusable Context Asset) → 공유 컨텍스트 계층 (Shared Context Layer) → 다음 작업이 더 스마트하게 시작됨

이것이 바로 작업 자동화 (Task automation)에서 컨텍스트 축적 (Context accumulation)으로의 전환입니다. AI 에이전트는 단순히 작업을 완료하는 것에 그치지 않습니다. 에이전트는 공유 컨텍스트 계층에 무언가를 추가하며, 이는 나중에 생성 (Generation) 과정에서 다음 에이전트를 돕게 됩니다.

비용 절감을 위해 이것이 중요한 이유
실제로 비용 절감은 단순히 더 저렴한 모델을 사용할 때만 나타나는 것이 아닙니다. 반복적인 작업을 줄일 때 나타납니다.
동일한 내용을 설명하는 데 드는 시간이 줄어듭니다.
동일한 명확화 (Clarification) 작업에 드는 시간이 줄어듭니다.
동일한 실수를 수정하는 데 드는 시간이 줄어듭니다.
제로 베이스 (Zero)에서 시작하는 데 드는 시간이 줄어듭니다.
동일한 컨텍스트를 다시 불러오는 데 소모되는 토큰 (Tokens)이 줄어듭니다.
서로 다른 에이전트가 동일한 문제에 대해 서로 다른 솔루션을 제공할 위험이 줄어듭니다.

이것은 더 이상 단순한 토큰 최적화 (Token optimization)가 아닙니다. 이것은 비용 효율적인 AI 도입을 위한 운영 모델 (Operating model)입니다.

구현 방법
저는 거대한 기업용 지식 베이스 (Enterprise knowledge base)로 시작하지 않을 것입니다. 하나의 SDLC 흐름으로 시작하는 것이 더 좋습니다.
예를 들어:
요구사항 (Requirements) → 개발 (Development) → QA → 배포 (Deployment)

그리고 각 단계에 대해 다음을 정의하십시오:
에이전트가 생성하는 작업 결과물은 무엇인가?
에이전트가 남겨야 할 재사용 가능한 컨텍스트 자산은 무엇인가?
누가 또는 무엇이 이 컨텍스트를 검증하는가?
이것은 어디에 저장되는가?
어떤 다음 에이전트나 팀이 이를 사용할 수 있는가?
이것이 실제로 비용을 줄였거나 품질을 개선했는지 어떻게 알 수 있는가?

핵심 규칙은 간단합니다: 모든 에이전트는 작업 결과물뿐만 아니라, 재사용을 위한 결과물도 생성해야 합니다.

검증 (Validation)은 매우 중요합니다. 위험 요소가 존재합니다: 만약 에이전트가 잘못된 컨텍스트 (Context)를 저장하기 시작하면, 조직은 실수를 확장하게 됩니다. 그렇기 때문에 재사용 가능한 컨텍스트가 자동으로 신뢰할 수 있는 정보의 원천 (Source of truth)이 되어서는 안 됩니다. 검증이 필요합니다. 이는 다음과 같은 방식이 될 수 있습니다: 인간의 승인; 자동화된 테스트; 다른 에이전트에 의한 검증; 코드 리뷰 (Code review); 아키텍처 리뷰 (Architecture review); 보안 리뷰 (Security review); 초안 (Draft) / 검증됨 (Validated) / 폐기됨 (Deprecated)과 같은 상태 값. 이것이 없다면, 공유된 컨텍스트 계층 (Shared context layer)은 빠르게 공유된 혼란 계층 (Shared confusion layer)이 될 수 있습니다. 그렇기 때문에 단순히 텍스트뿐만 아니라 상태, 출처, 소유권이 포함된 구조화된 컨텍스트 (Structured context)를 저장하는 것이 중요합니다.

어떤 지표를 사용할 수 있는가? 만약 우리가 이것을 도입 모델 (Adoption model)로서 관리하고자 한다면, 단순히 사용된 에이전트의 수나 생성된 코드 라인 수만을 측정해서는 안 됩니다. 가능한 지표는 다음과 같습니다: AI 보조 작업이 얼마나 많은 재사용 가능한 컨텍스트 자산을 생성했는지; 얼마나 많은 컨텍스트 자산이 검증되었는지; 컨텍스트 자산이 얼마나 많이 재사용되었는지; 개선 시간 (Refinement time)이 감소했는지; 반복되는 명확화 질문의 수가 감소했는지; 반복되는 결함이 감소했는지; 코드 리뷰의 일관성이 향상되었는지; 신입 엔지니어 또는 에이전트의 온보딩 (Onboarding) 시간이 감소했는지; AI 보조 작업당 평균 비용이 감소했는지. 핵심 질문은 이것입니다: 이 작업이 다음 작업을 더 저렴하고, 빠르고, 더 좋게 만들었는가?

결론
오늘날 많은 기업이 개별 작업의 자동화를 통해 SDLC에 에이전트형 AI (Agentic AI)를 도입하려고 시도하고 있습니다. 이것은 올바른 시작점입니다. 하지만 모든 작업이 단순히 출력물로만 끝난다면, 우리는 가치 있는 정보의 거대한 부분을 잃게 됩니다. 성숙한 AI 도입 모델은 에이전트를 단순한 작업 수행자뿐만 아니라 컨텍스트 생산자로 바라보아야 합니다. 모든 AI 보조 작업은 다음 작업을 위해 유용한 무언가를 남겨야 합니다. 그때 비로소 AI 도입이 플라이휠 (Flywheel)처럼 작동하기 시작합니다. 각 작업은 다음 작업을 조금 더 저렴하게 만듭니다. 각 결정은 미래의 불확실성을 줄입니다. 발견된 각 엣지 케이스 (Edge case)는 다음 QA 사이클을 개선합니다. 학습된 각 배포 교훈은 다음 릴리스의 리스크를 줄입니다.

어쩌면 이제는 단순히 "에이전트가 작업을 완료했는가?"라는 관점으로만 생각하는 것을 멈춰야 할 때인지도 모릅니다. 대신 다음과 같은 질문을 시작해야 합니다: "이 작업이 다음 작업을 더 똑똑하고, 저렴하고, 빠르게 만들었는가?"