AWS 기술 블로그
AWS AI-DLC를 System Maintenance 환경에 맞게 커스터마이징하기
LG CNS는 AWS 프리미어 파트너로, 다수의 대규모 엔터프라이즈 고객을 대상으로 System Maintenance(운영 유지보수)/Application Modernization(현대화)/Migration 서비스를 제공하고 있습니다. 이 글은 그중 한 고객사의 System Maintenance 프로젝트에서 AI-DLC를 도입·커스터마이징하며 축적한 실전 경험을 바탕으로 작성되었습니다.
들어가며
생성형 AI를 개발에 활용하는 방식은 빠르게 진화해 왔습니다. 좋은 프롬프트로 응답 품질을 끌어올리는 프롬프트 엔지니어링 (2022~2024), 필요한 문서·상태·기록을 정확히 주입하는 컨텍스트 엔지니어링 (2025)을 거쳐, 이제는 LLM이 통제된 환경과 규칙 안에서 일하도록 워크플로우와 품질 게이트를 설계하는 하네스 엔지니어링(Harness Engineering)(2026~)으로 중심이 이동하고 있습니다.
| 단계 | 정의 | 한계 / 효과 |
| Prompt Engineering | 좋은 입력·지시 구조로 응답 품질 향상 | 열린 Scope에서 AI가 추측, 대화가 길어지면 초기 의도 희석, 엔터프라이즈 부적합 |
| Context Engineering | 필요한 문서·상태·기록을 대화에 주입 | 단일 세션 경계, 단순 스펙/플랜 의존, 단계별 작업 분리 약함 |
| Harness Engineering | 워크플로우·품질 게이트로 통제된 환경 설계 | 추측 방지(단계별 질문·승인) · 정합성 유지 · 재현성 |
AWS AI-DLC는 바로 이 하네스 엔지니어링 흐름 위에 있는 방법론입니다. LG CNS는 2023년부터 국내 대형 엔터프라이즈 고객사의 System Maintenance 사업에서 ITSM 기반 정량적 공수관리, Amazon Q Developer 기반 코드 어시스턴트를 단계적으로 도입해 왔고, 2026년 현재 개발 라이프사이클 전반의 효율화를 위해 AI-DLC를 전면 도입하고 있습니다.
이 글에서는 AWS가 배포하는 원본 규칙 파일(aws-aidlc-rules/, aws-aidlc-rule-details/, 이하 ‘AWS 방법론 원본’)을 한 줄도 수정하지 않으면서 AWS AI-DLC를 대규모 System Maintenance 현장에 맞게 조정한 방법과, 그 과정에서 LG CNS가 만들어 낸 재사용 가능한 표준 자산을 소개합니다.
[그림 1] 프롬프트 → 컨텍스트 → 하네스 엔지니어링 변화 타임라인
AI-DLC란 무엇인가
AI-DLC(AI-Driven Development Lifecycle) 는 AWS Labs가 오픈소스로 제공하는(awslabs/aidlc-workflows) AI 개발 방법론입니다. AI 에이전트를 검증 가능하고 자가 수정 가능한 엔지니어링 워크플로우로 전환해, 요구사항 분석부터 설계·코드 생성·검증까지 개발 전 과정을 단계별 승인 게이트와 함께 구조적으로 안내합니다. 요청에 필요한 단계만 실행하는 적응형(Adaptive) 방식이면서, 실행 계획과 산출물은 항상 사람이 승인(Human-in-the-Loop)하는 것이 핵심입니다. AI-DLC의 개념·페이즈·레이어 구조에 대한 자세한 설명은 다음을 참고하세요.
- AWS 공식 소개 블로그 — https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
- 오픈소스 저장소 — https://github.com/awslabs/aidlc-workflows
- 관련 한국 기술블로그 — https://aws.amazon.com/ko/blogs/tech/kiro-subagent-structured-ai-development-workflow/
이 글의 커스터마이징을 이해하는 데 필요한 두 가지 구조를 소개합니다. AI-DLC는 INCEPTION(무엇을·왜) → CONSTRUCTION(어떻게 만들기) → OPERATIONS(배포·운영) 세 페이즈로 진행되며, 규칙을 정의하는 Rule Layer 위에 산출물을 관리하는 Knowledge Layer, 검증을 담당하는 Guardrail Layer가 얹히는 계층 구조입니다. 이 레이어 구조가 뒤에서 설명할 “원본 불변 + Override” 접근의 토대가 됩니다.
[그림 2] AI-DLC 4-Layer 구조도 (Foundation / Rule / Knowledge / Guardrail)
AI-DLC v2
awslabs 저장소에서 차세대 AI-DLC v2가 정식 출시(GA)되었습니다. 5페이즈 × 32스테이지 구조, 11개 도메인 전문가 에이전트 협업, 하네스 중립 단일 코어 등으로 확장됐습니다. 흥미롭게도 이 글에서 소개할 커스터마이징(System Maintenance 환경 고정, Knowledge 체계, 반복 교훈의 규칙화 등) 상당수가 v2에서 정식 기능으로 도입되었습니다. LG CNS는 이 v2를 기준으로 전사 확산을 진행하고 있습니다.
왜 Kiro인가: 엔터프라이즈 관점
이번 프로젝트의 실행 기반은 AWS의 에이전틱 AI IDE인 Kiro 입니다. AI-DLC가 ‘무엇을 어떤 순서로 할지’를 정의하는 방법론이라면, Kiro는 그것을 엔터프라이즈 환경에서 강제 가능하게 만드는 하네스 실행 엔진입니다. 이 글의 커스터마이징은 전부 Kiro의 기본 기능 위에서 구현되었습니다.
- Steering rules (
.kiro/steering/): 세션마다 항상 로드되는 규칙 계층으로, 3계층 Override 구조가 여기에 올라갑니다. - Hooks (
.kiro/hooks/): 이벤트 트리거 자동화. 매 프롬프트마다 핵심 규칙을 다시 알려 주는 안전장치로 활용합니다. - Skills (
.kiro/skills/): 반복 작업의 실행 단위. 산출물 게시·문서 변환 등 워크플로우 전후 작업을 자동화합니다. - MCP: Atlassian(Jira/Confluence/Bitbucket) 등 사내 시스템 연동
기능 관점만이 아니라, 엔터프라이즈 도입 결정에서 실제로 작동한 선택 기준은 세 가지였습니다.
- 토큰 사용량 최적화: LLM Routing이 작업 성격에 맞춰 모델을 배분해 토큰 비용을 구조적으로 최적화합니다. 단순 작업에 최고 사양 모델을 쓰는 낭비를 도구 차원에서 차단합니다.
- 보안: 고객사 보안 거버넌스를 준수하는 실행 환경입니다. Amazon Q Developer 시절부터 이어진 거버넌스 연속성 위에서 도입했습니다. (구체 통제 사항은 아래 “빠른 적용이 가능했던 배경” 참조)
- 비용 : 실제 운영 기준 개발자 1인당 월 $20 수준의 예측 가능한 비용으로, 대규모 System Maintenance 조직 전체에 확산 가능한 단가입니다.
규칙·권한·감사 로그가 파일 기반으로 버전 관리되므로, “개인의 프롬프트 노하우”가 아니라 팀 단위로 배포·감사 가능한 표준이 됩니다. 대규모 System Maintenance 조직에 AI를 도입할 때 필요한 통제 수준을 IDE 차원에서 제공한다는 점이 이 프로젝트에서 Kiro를 선택한 이유입니다.
이 기능들이 실제로 어떤 커스터마이징을 지탱했는지는, 핵심 설계를 모두 소개한 뒤 “구현 노트: 핵심 설계와 Kiro 기능의 매핑” 에서 하나의 표로 정리합니다.
빠른 적용이 가능했던 배경
방법론과 커스터마이징을 살펴보기 전에 먼저 짚고 넘어갈 부분이 있습니다. LG CNS가 이 고객사 현장에 Kiro 기반 AI-DLC가 공개되자마자 곧바로 현장에 적용할 수 있었던 것은 우연이 아니라, 그 시점에 이미 세 가지 조건이 갖춰져 있었기 때문입니다.
- 어플리케이션 현대화(Application Modernization) 선행 완료: 대상 시스템은 이미 현대화가 완료되어 있어, AI가 코드베이스를 분석할 수 있는 구조였습니다.
- AI 친화적 코드베이스(AI Readability): 범용 기술 스택으로 구성되어 있어, LLM이 사전 학습으로 이미 잘 아는 패턴 위에서 코드를 인지하고 생성할 수 있었습니다.
- 보안 거버넌스 사전 준수: Kiro 도입 이전부터 Amazon Q Developer를 활용하고 있어 고객사 보안 거버넌스 검토가 이미 통과된 상태였고, 새 AI 도구 도입 시 가장 오래 걸리는 보안 심사 단계를 사실상 건너뛸 수 있었습니다. Kiro 역시 같은 거버넌스 기준을 충족하도록 구성했습니다.
- SSO 기반 로그인: 인가된 사용자만 접근
- S3 프롬프트 로깅: 모든 프롬프트를 기록해 감사 추적 가능
- 웹 기능 비활성화: 통제된 IDE 환경에서만 동작
정리하면, 어플리케이션 현대화 덕분에 AI가 코드를 읽을 수 있는 상태였고, 거버넌스 덕분에 AI를 바로 사용할 수 있는 상태였습니다. 이 ‘준비된 환경’이라는 전제는 글 마지막의 시사점(어플리케이션 현대화 선행 → AI-DLC 효과)에서 다시 다룹니다.
다만 AI-DLC의 기본 워크플로우는 신규 개발(Greenfield)을 전제로 한 흐름이 강해서, 이미 운영 중인 시스템을 유지보수하는 System Maintenance 환경에서는 그대로 쓰기 어렵습니다. 지금부터 그 문제와 해결 과정을 살펴보겠습니다.
System Maintenance 환경에 적용하며 마주친 3가지 문제
System Maintenance 환경에 AI-DLC를 그대로 적용했을 때 LG CNS가 고객사의 현장에서 마주친 문제는 크게 세 가지였습니다.
1. 불필요한 반복 질문
System Maintenance 작업은 거의 항상 이미 운영 중인 기존 시스템을 다룹니다. 그런데도 기본 워크플로우는 매번 Greenfield/Brownfield를 감지하려 하고, Infrastructure Design 단계를 묻습니다. 예를 들어 AWS 방법론 원본에서는 워크플로우를 시작할 때마다 이런 질문이 나옵니다.
인프라 변경을 별도 프로세스로 처리하고 모든 작업이 기존 시스템 위에서 일어나는 환경에서는, 이런 단계가 매번 같은 답을 반복 입력해야 하는 번거로운 작업이 됩니다. Extension opt-in(OWASP 기반 15개 보안 규칙)도 마찬가지입니다. 이미 보안 체계가 갖춰진 운영 시스템의 유지보수 작업에서 매번 15개 규칙을 전부 검증하는 것은 과도합니다.
2. AI Hallucination → 컴파일 에러와 데이터 정합성 문제
운영 코드를 다룰 때 가장 빈번하고 치명적인 문제입니다.
AI가 getUserName()이라고 추측했지만 실제 메서드는 getUserNm()인 경우가 잦습니다. 존재하지 않는 메서드 호출은 컴파일 에러나 런타임 장애로 직결됩니다. 상태코드, Kafka 이벤트 토픽명 같은 코드값을 AI가 임의로 만들어 내면 데이터 정합성이 무너집니다.
3. 멀티 Repository 영향도 누락
고객사의 여러 시스템은 Frontend(FE)/Backend(BE)/Batch가 별도 Repository(repo)로 분리되어 있습니다. AI가 현재 Repository만 보고 작업하면 다른 Repository의 기존 로직을 중복 구현하거나, API 변경의 영향도를 놓치기 쉽습니다.
그리고 가장 근본적인 문제
위 문제를 해결하려고 AWS 방법론 원본 규칙을 직접 수정하면, 다음 AWS 업데이트 때 커스터마이징이 모두 사라집니다. 원본을 건드리지 않으면서 System Maintenance 환경에 맞게 조정할 방법이 필요했습니다.
해결 방안: AWS 방법론은 그대로 두고, 커스터마이징은 Override로
해결의 출발점은 ‘AWS 방법론 원본은 절대 수정하지 않는다‘ 는 원칙입니다. 대신 별도의 Override 레이어를 두고, 모든 커스터마이징을 그 위에서만 정의합니다. 앞서 본 AI-DLC의 레이어 구조를 그대로 살린 접근입니다.
[그림 3] AWS 방법론 원본과 3계층 Override 구조
네 가지 기본 원칙을 따릅니다.
- AWS 방법론에 대한 원본은 불변 :
aws-aidlc-rules/,aws-aidlc-rule-details/는 절대 수정하지 않는다. - Override 분리: 커스터마이징은 3계층 Override 구조 안에서만 정의한다.
- 최소 변경: 시스템 계층에는 “필요한 차이”만 기술한다.
- 재사용 우선: 검증된 Override 구조를 복사해 시스템 계층만 바꿔 재사용한다.
이 원칙 위에서 적용한 커스터마이징은 총 32건입니다. 세부 항목을 나열하는 대신 이 글의 핵심 1~5 구조로 묶으면 크게 세 영역입니다.
| 영역 | 건수 | 구성 |
| 개발 워크플로우·규칙 커스터마이징 (핵심 1~3) | 20건 | System Maintenance 환경 고정(4) · 산출물 경로/정렬(5) · 스테이지 추가(6) · 규칙 추가(5) |
| 지식 계층 (핵심 4) | 1건 | AI가 비즈니스 규칙을 자동 참조하는 Knowledge 체계 |
| 자동화 계층 (핵심 5) | 11건 | Skill 10종 + Hook 1종(규칙 리마인드) |
[그림 4] 3계층 Override 구조와 커스터마이징 32건 구성
핵심 1. AWS 방법론 원본을 건드리지 않는 3계층 Override 구조
문제 : 원본을 직접 수정하면 업데이트마다 커스터마이징이 소실된다.
해결책 : 전사 공통 → 도메인 → 시스템의 3계층 Override 레이어를 둡니다. 디렉토리 구조는 Kiro의 steering 규칙 체계 위에 그대로 올라갑니다.
AI가 개발 요청을 받으면 다음 순서로 로딩·병합됩니다.
aws-aidlc-rules/core-workflow.md로드 (AWS 방법론 원본)aidlc-override-loader.md로드 (Kiro steering rule, inclusion: always)- Override Config를 계층 순서로 병합: 전사 공통 → 도메인 → 시스템(최종 우선순위)
- Knowledge Index 병합 후 워크플로우 실행
병합 방식은 항목에 따라 다릅니다. 같은 키는 상위 계층이 덮어쓰고, 추가 항목은 모든 계층에 누적됩니다.
| 섹션 | 병합 전략 |
| System Profile / Path / Stage / Behavior Overrides | 상위 계층(시스템)이 덮어씀 |
| Additional Stages / Additional Rules / Knowledge | 합집합 (모든 계층 누적) |
시스템 담당자가 작성하는 것은 사실상 아래 한 파일뿐입니다.
파일을 직접 수정하지 않아도 됩니다. Kiro 채팅에 aidlc setup을 입력하면 대화형 4단계로 이 파일이 자동 생성됩니다.
결과 : 대부분의 커스터마이징은 전사 공통 계층에 이미 정의되어 있어, 각 시스템 담당자는 system/override-config.md 한 파일만 작성하면 됩니다. AWS 버전 업데이트는 aws-aidlc-rules/·aws-aidlc-rule-details/를 교체만 하면 흡수되고, Override는 그대로 유지됩니다.
핵심 2. System Maintenance 환경에 맞춘 워크플로우 조정 (4건 제거, 6건 추가)
문제: 신규 개발용 단계가 System Maintenance 환경에는 과하다.
해결책 1: 불필요한 단계 제거·고정 (Stage Overrides 4건, 전사 공통)
| 스테이지 | Override | 이유 |
| Workspace Detection | brownfield-fixed: true | System Maintenance는 항상 기존 시스템 유지보수 |
| Reverse Engineering | skip-if-exists: true | Reverse Engineering은 사전 배치, 마지막에 갱신 |
| User Stories | lower-threshold: true | System Maintenance 작업은 대부분 Medium 규모(원본 기준을 그대로 두면 User Stories가 자주 생략되어 요구사항 정리가 부실해짐) |
| Infrastructure Design | always-skip: true | 인프라 변경은 별도 프로세스 |
해결책 2: System Maintenance에 필요한 스테이지 추가 (Additional Stages 6건, 전사 공통)
| 스테이지 | 위치 | 역할 |
| ★ Implementation Decision Gate | 설계 완료 후, 코드 생성 전 | “구현 진행 / 설계만 유지” 선택. 설계만이면 이후 단계를 건너뛰고 Final Summary로 직행 |
| ★ Effort Estimation | 구현 결정 후 | Batch/Backend/Frontend 영역별 표준공수(M/D) 산정 → 개발 일정 근거 |
| ★ Test Case Generation | 코드 생성 전 | 설계 기반 변경·회귀 테스트 케이스 사전 도출 (TC-{티켓}-V/R-XXX 체계) |
| ★ Code Quality Review | 코드 생성 완료 후 | NPE 리스크 + SQL 성능 + Cross-Repository 중복 리뷰 |
| ★ Final Summary Document | Build and Test 후 | 요구사항→설계→구현→테스트 전체 요약 |
| ★ Reverse Engineering Update | 워크플로우 종료 전 | 변경된 API/컴포넌트/의존성을 Reverse Engineering 산출물에 반영 → 다음 작업에서 AI가 최신 정보로 분석 |
Override 적용 전후 워크플로우를 나란히 놓으면 차이가 분명합니다.
[그림 5] Override 적용 전후 워크플로우 비교
해결책 3: RITM 기반 산출물 추적 (경로/정렬 5건, 전사 공통)
System Maintenance 현장의 업무는 ITSM 처리번호(RITM) 단위로 돌아갑니다. 산출물 경로를 aidlc-docs/에서 aidlc-logs/{RITM-ID}/로 치환하고, 모든 산출물 폴더/파일에 01_, 02_ 접두어를 부여해 워크플로우 실행 순서대로 정렬합니다(Ordered Artifact Naming). Git 브랜치에서 티켓을 자동 인식하는 Work ID Resolution 체계도 함께 동작합니다.
결과: 산출물은 RITM/티켓별로 분리 관리되고, 표준공수 산정으로 “누가, 어떤 작업에서, 무엇을 변경했는지”가 명확해집니다. 현행(As-Is) 분석을 설계 문서에서 별도 파일로 분리해 리뷰어가 현행 분석만 따로 확인할 수 있게 한 것도 System Maintenance 리뷰 절차가 반영되도록 보완한 결과입니다.
핵심 3. AI Hallucination을 막는 3대 안전장치 규칙
문제: AI의 추측 코드가 장애로 이어진다.
해결책 (Additional Rules): 규칙 적용 전후를 코드로 직접 비교하도록 조치하였습니다.
해결책 1: 기존 코드 검증 (Existing Code Verification, 전사 공통): 기존 함수·클래스·필드를 참조하기 전 반드시 실제 소스를 읽어 확인하고, 확인이 불가능하면 [VERIFY_REQUIRED] 플레이스홀더를 사용합니다. 규칙 적용 후 AI는 설계 문서에 검증 결과를 근거와 함께 기록합니다.
해결책 2: 멀티 Repository 영향도 분석 (Cross-Repository Awareness, 전사 공통): API endpoint, 공유 DB 스키마, Kafka topic, 공유 DTO, Batch 참조 데이터가 바뀌면 관련 Repository의 Reverse Engineering 산출물·소스를 실제로 읽어 영향도와 책임 경계를 분석합니다. 설계 산출물에는 이런 분석이 포함됩니다.
이미 Frontend에 있는 포맷팅 로직을 Backend에 중복 구현하는 실수, API를 바꿔 놓고 Frontend 영향도를 놓치는 실수를 설계 단계에서 잡습니다.
해결책 3: 코드값 거버넌스 (Code Value Governance, 시스템별): Kafka Topic명, 발송 채널·결과 코드, 상태코드, 공통코드 등을 AI가 임의로 결정하지 못하게 하고, 신규 코드값은 [CODE_VALUE_TBD] 플레이스홀더로 남겨 개발자 확인을 강제합니다. Code Generation 시작 전 모든 플레이스홀더가 해소되어야 다음 단계로 진행됩니다.
결과: 컴파일 에러, 데이터 정합성 오류, 멀티 Repository 영향도 누락을 설계·코드 생성 단계에서 사전 차단합니다.
핵심 4. AI에게 업무 지식을 제공하는 Knowledge 체계
문제: 업무 도메인의 비즈니스 규칙(발송 정책, 예약 상태 전이, 업무 용어, 연계 시스템)은 코드에 다 드러나지 않는다. AWS 방법론 원본에는 AI가 이런 도메인 지식을 참조하는 메커니즘이 없다.
해결책 : 각 계층(전사/도메인/시스템)에 Knowledge Index를 두고, Kiro Steering의 선택적 로딩 기능을 활용해 AI가 분석/설계 시 자동으로 참조하도록 로딩 체계를 추가했습니다. 핵심은 두 가지 로딩 방식입니다.
| 로딩 방식 | 설명 | 사용 시점 |
| Always Load | 워크플로우 시작 시 항상 로드 | 모든 작업에서 참조해야 하는 핵심 규칙 (예: 코드값 체계) |
| On-Demand | 사용자 요청의 키워드와 매칭될 때 자동 로드 | 특정 작업에서만 필요한 규칙(컨텍스트 절약) |
“SMS 발송 로직 수정” 요청이 들어오면 AI가 sms-send-policy.md를 자동으로 읽고 분석을 시작합니다. LLM의 컨텍스트 윈도우는 유한한 자원이므로, 모든 지식을 항상 로드하는 대신 키워드 매칭으로 필요한 것만 로드하는 설계가 실전에서는 중요합니다. Knowledge가 없어도 워크플로우는 정상 동작하며, 코드에 드러나지 않는 규칙이 있을 때 추가하면 분석·설계 품질이 올라가는 opt-in 구조입니다.
핵심 5. 워크플로우 전후의 반복 업무를 자동화하는 Skill과 Hook
문제: 개발 워크플로우가 끝난 뒤에도 산출물을 Confluence에 게시하고, 표준 문서를 갱신하고, PDF로 변환해 공유 드라이브에 올리고, Jira를 조회하는 반복 작업이 남는다.
해결책 : AWS 방법론 원본에는 없는 Kiro의 Skill/Hook 계층을 활용해, 워크플로우 전후의 반복 업무를 자동화했습니다. 10개 Skill과 1개 Hook을 추가했습니다.
| Skill | 역할 | 트리거 예시 |
| aidlc-orchestrator | Jira 티켓 → AI-DLC 실행 → PR → Confluence 게시 전체 오케스트레이션 | “APP-1234 개발해줘” |
| dev-deliverable-creator | AI-DLC 산출물을 Confluence 개발 산출물로 게시 | “개발산출물 올려줘” |
| business-doc-manager | 대표업무코드별 표준 문서 자동 갱신, 변경 파일을 업로드 큐에 기록 | “문서 갱신” |
| drive-uploader | 업로드 큐 기반 공유 드라이브 업로드 | “드라이브 업로드” |
| pdf-converter | Markdown → PDF 변환 (한글 폰트·표 스타일 적용), 업로더에서 자동 호출 | “pdf 변환” |
| atlassian-query | Confluence/Jira/Bitbucket REST 조회 | “지라 조회” |
| meta-knowledge | 반복 교훈을 감지해 skill/rule/템플릿 개선으로 전환 | audit 로그·사용자 교정 발생 시 |
| skill-creator | 새 skill 생성·기존 skill 개선 | “스킬 만들어줘” |
| reviewer | 배포 전 필수 체크 일괄 검증 | “배포 전 체크” |
| fe-be-test | 테스트 케이스 산출물 → 실행 가능한 테스트 코드 생성·실행 | “테스트 실행” |
특히 business-doc-manager → drive-uploader → pdf-converter는 3개 Skill이 파이프라인으로 연동 되어, 개발 완료 후 업무 관점의 표준 문서를 생성하고 팀 공유 드라이브까지 자동 배포합니다. meta-knowledge는 여기서 한 걸음 더 나아가, 반복되는 문제를 감지하면 프로세스 자체(skill·rule·템플릿)를 개선하도록 제안하는 자기 개선 구조입니다.
Hook은 하나지만 역할이 큽니다.
| Hook | 트리거 | 역할 |
| aidlc-rule-reminder | 매 프롬프트 제출 시 (promptSubmit) | AI-DLC 핵심 규칙 7개를 매번 리마인드 |
긴 대화에서 LLM이 초기 규칙(질문은 md 파일로, 승인 대기, audit 기록, 상태 동기화 등)을 잊는 것은 잘 알려진 문제입니다. Kiro의 promptSubmit hook으로 매 턴마다 핵심 규칙을 결정론적으로 주입해 이 문제를 구조적으로 막았습니다. “AI가 기억해 주길 바라는 것”이 아니라 “시스템이 매번 상기시키는 것”, 이것이 하네스 엔지니어링의 전형적인 패턴입니다.
구현 노트: 핵심 설계와 Kiro 기능의 매핑
앞에서는 무엇을 커스터마이징했는지를 살펴봤습니다. 이 섹션에서는 그것을 어떤 메커니즘으로 반드시 실행되게 만들었는지를 다룹니다. 하네스 엔지니어링에서 이 둘은 서로 다른 문제입니다. 규칙을 문서로 쓰는 것은 어떤 도구로도 할 수 있지만, AI가 그 규칙을 매번 예외 없이 따르게 만들려면 실행 엔진의 기능이 필요합니다. 앞서 ‘왜 Kiro인가’에서 나열한 기능들을 핵심 설계와 연결하면 다음과 같습니다.
| Kiro 기능 | 강제 방식 | 어디에 썼나 |
| Steering — 상시 로드 (inclusion: always) | 세션이 시작될 때마다 결정론적으로 로드. “AI가 기억하길 기대”가 아니라 “시스템이 주입” | 핵심 1 · aidlc-override-loader.md가 항상 로드되어 3계층 병합의 진입점이 됨. AWS 방법론 원본을 한 줄도 고치지 않고 동작을 바꿀 수 있는 구조적 이유 |
| Steering — 선택적 로딩 | 항상 로드하지 않고 조건·키워드에 따라 참조 | 핵심 4 · Knowledge Index의 On-Demand 로딩(키워드 매칭 → 컨텍스트 절약). |
| Hook — 이벤트 강제화 (promptSubmit) | 사용자가 프롬프트를 보낼 때마다 자동 실행. AI가 건너뛸 수 없음 | 핵심 5 · aidlc-rule-reminder가 매 턴 핵심 규칙 7개를 재주입. 긴 대화에서의 규칙 망각을 확률 문제가 아니라 구조 문제로 해결 |
| Skill — 트리거 실행 단위 | 키워드로 호출되는 자동화 패키지, 파일로 배포·버전 관리 | 핵심 5 · 산출물 게시·문서 파이프라인·meta-knowledge 등 Skill 10종 |
| MCP / 외부 연동 | Jira·Confluence·Bitbucket 등 사내 시스템 접근 | 핵심 5 · atlassian-query 등 산출물 게시·조회 Skill의 백엔드(환경 제약 시 REST 직접 호출로 대체 가능하도록 설계) |
| 파일 기반 구성 (.kiro/) | 규칙·스킬·훅 전체가 Git으로 버전 관리 | 자산화(재사용) · .kiro/ 복사 한 번으로 다른 시스템에 하네스 전체 이식. Layer 3 자산화가 성립하는 기반. 새 시스템은 aidlc setup 대화형 설정으로 system/override-config.md만 작성하면 적용 완료 |
이 표에서 공통된 패턴을 하나 발견할 수 있습니다. 규칙의 성격에 따라 강제 메커니즘이 달라진다는 점입니다.
- 항상 지켜야 하는 것 → steering 상시 로드 (Override 병합, Hallucination 안전장치)
- 잊어버리기 쉬운 것 → hook (매 턴 리마인드)
- 필요할 때만 필요한 것 → 선택적 로딩 (Knowledge On-Demand, 컨텍스트는 유한한 자원)
- 사람이 반복하던 것 → skill (게시·변환·조회 자동화)
어떤 규칙을 만들 것인가만큼, 그 규칙을 어떤 메커니즘으로 강제할 것인가가 하네스 엔지니어링의 절반을 차지합니다. AI-DLC가 ‘무엇을 어떤 순서로 할지’라는 방법론을 제공하고, Kiro가 ‘어떻게 반드시 실행되게 할지’라는 강제 수단을 제공합니다. 이 결합이 이번 커스터마이징의 실행 기반이었습니다.
적용 효과: System Maintenance 파일럿 결과
고객사 System Maintenance 사업의 AI 도입은 3년에 걸쳐 단계적으로 축적된 결과입니다.
[그림 6] 3년에 걸친 단계적 AI 도입 여정 (2023 ITSM → 2024~ Amazon Q Developer → 2026~ AI-DLC)
5개 시스템에 대해 1개월간 총 16건의 개발성 변경요청(CSR) 에 AI-DLC를 적용한 파일럿 결과, 단순 API 추가부터 화면 개발, 대규모 기능 추가까지 작업 유형 전반에서 일관되게 표준공수를 밑돌았고, 특히 반복 패턴이 뚜렷한 작업일수록 효과가 컸습니다.
수치보다 중요한 것은 이 효과가 어디에서 왔는가 하는 점입니다. 파일럿에서 확인된 효과의 원천은 세 가지였습니다.
| 효과 원천 | 내용 | 현장에서 나타난 변화 |
| System Maintenance 맞춤 워크플로우 | 불필요 단계 제거 + 6개 스테이지 추가 (핵심 2) | 반복 질문·불필요 산출물이 사라져 작업 흐름 단축 |
| 산정 자동화 | Effort Estimation 스테이지의 표준공수 산정 | 개발 일정 수립의 근거 확보, 산정 편차 감소 |
| 코드 거버넌스·안전장치 | 코드 검증·코드값 거버넌스·품질 리뷰 (핵심 3) | 컴파일 에러·정합성 오류로 인한 재작업 감소 |
[그림 7] 코드 어시스턴트에서 AI-DLC로 확대된 라이프사이클 커버리지 (부분 최적화 → 전체 최적화)
파일럿이 남긴 또 하나의 성과: 자산화
고객사의 System Maintenance 현장에서 검증된 Override 구조·규칙·Skill은 프로젝트 유형별 Best Practice로 정리되어 사업부 표준으로 확산되고 있습니다.
- System Maintenance: 본 사례로 최적화 완료
- Migration: 금융권 프로젝트와 자사 표준 프레임워크 PoC 진행 중, 통신사 전사 클라우드 전환 프로젝트에 적용 예정
- SI: 중/소규모 프로젝트에서 E2E 테스트 자동화(TDD)와 Skill 추가 개발로 최적화 진행 중
- 신규 프로젝트: 초기 검토 단계에서 AI-DLC 적용을 심의
담당별 에반젤리스트와 1-Day Hands-on 교육이 이 확산을 뒷받침합니다.
시사점: 정답은 “우리 환경에 맞춘 AI-DLC”
가장 중요한 결론은 AWS AI-DLC가 훌륭한 기반이지만 만능 정답은 아니라는 점입니다. 같은 기반이라도 System Maintenance, 어플리케이션 현대화, 신규 개발은 필요한 단계와 안전장치가 다릅니다.
- System Maintenance 환경 → Brownfield 고정·불필요 단계 제거 + 표준공수·코드 거버넌스 + Knowledge/Skill 자동화
그래서 커스터마이징은 선택이 아니라 전제입니다. “AI-DLC를 도입한다”가 아니라 “AI-DLC를 우리 프로젝트 환경의 제약·조직·리스크에 맞게 최적화한다“ 가 실제 성공을 좌우합니다.
AI-DLC 커스터마이징 도입 전제: 어플리케이션 현대화 선행
AI-DLC 커스터마이징 도입 전 짚어야 할 조건이 하나 더 있습니다. 앞서 “빠른 적용이 가능했던 배경”에서 본 것처럼, 이 고객사는 어플리케이션 현대화가 완료되어 있었고 범용 기술 스택이라 AI가 코드베이스를 읽을 수 있는 상태였으며, Amazon Q Developer로 보안 거버넌스까지 사전에 통과해 둔 상태였습니다. AI-DLC의 분석·설계·코드 생성은 결국 AI가 기존 코드를 얼마나 정확히 인지하느냐에 달려 있으므로, 어플리케이션 현대화가 선행되지 않은 레거시 환경에서는 같은 하네스를 적용해도 효과가 제한적입니다. LLM이 사전 학습으로 알지 못하는 벤더 종속 기술이나 문서화되지 않은 복잡한 의존 구조에서는 AI가 코드를 읽는 단계부터 정확도가 떨어지고, 그 위에서 이루어지는 분석·설계·코드 생성의 품질도 함께 낮아지기 때문입니다.
여기서 실무적인 시사점 두 가지가 나옵니다.
- AI-DLC 도입을 검토한다면 어플리케이션 현대화(최소한 AI Readability 확보)가 선행되어야 합니다. 코드가 AI가 읽을 수 없는 상태라면, 하네스보다 현대화가 먼저입니다.
- 반대로, 어플리케이션 현대화를 계획하는 조직이라면 도입 단계부터 AI 기반 운영(AI-DLC)을 함께 설계해야 합니다. 어플리케이션 현대화의 목표를 “현대화된 시스템”이 아니라 “AI와 함께 운영 가능한 시스템”으로 잡으면, 전환이 끝나는 시점에 곧바로 AI-DLC의 효과를 거둘 수 있습니다.
단, 커스터마이징의 방식 이 중요합니다. 원본을 직접 고치면 업데이트 때 모두 사라집니다. ① 원본 불변 + Override 분리, ② 최소 변경, ③ 재사용 우선 원칙 위에서 커스터마이징해야 기반(AWS 방법론 원본)의 발전과 사내 맞춤을 동시에 가져갈 수 있습니다. 한 번 정립한 Override 구조는 다음 시스템에 복사한 뒤 system/override-config.md만 바꿔 재사용할 수 있어, 조직 차원의 표준 자산(Layer 3 자산화)이 됩니다.
AI-DLC는 시작점입니다. 경쟁력은 환경에 맞춘 커스터마이징, 그리고 그것을 재사용 가능한 자산으로 만드는 역량에서 나옵니다.
마치며
LG CNS는 고객사의 AWS 방법론 원본을 그대로 흡수하면서도 System Maintenance 환경에 맞는 워크플로우를 유지하는 구조를 만들었습니다. 불필요한 질문·단계를 제거해 작업 시간을 줄이고, AI가 만든 코드의 함수명·코드값 오류와 멀티 Repository 영향도 누락을 사전에 차단해 운영 장애를 줄였습니다. RITM/티켓별 산출물 추적과 표준공수 산정으로 개발 일정 수립의 근거를 확보했고, 파일럿의 16건 CSR 전반에서 표준공수를 일관되게 밑도는 결과와 재작업 감소 효과를 확인했습니다.
앞으로의 계획은 세 가지입니다.
- 워크플로우 완성도: 배포 전 체크리스트 자동 검증, 변경관리위원회(CCB) 제출용 변경 영향도 문서 자동 생성, 리뷰어·테스트 실행 Skill(reviewer, fe-be-test) 등 현재 개발 중인 규칙·Skill의 완성
- 조직 확산: 개발 유형별(System Maintenance·어플리케이션 현대화·SI·Migration) 자산 확보·자산화와 교육 프로그램을 통한 사업부 표준 확산
- AI-DLC v2 전환 : 정식 출시(GA)된 차세대 AI-DLC v2(5페이즈 × 32스테이지, 11개 도메인 전문가 에이전트, 멀티 하네스 단일 코어)를 기준으로 전사 확산을 진행 중입니다. “원본 불변 + Override 분리” 원칙을 지켜온 덕분에, v2 전환 역시 원본 교체와 Override 재정렬로 흡수한다는 것이 기본 전략입니다.
하네스 엔지니어링의 시대에 방법론은 오픈소스로 공개되어 있습니다. 차이를 만드는 것은 그것을 자기 조직의 제약에 맞게 적용하는 역량, 그리고 그 전에 토대(어플리케이션 현대화, AI Readability, 거버넌스)를 갖추었는지 여부입니다.
참고 자료
- AI-DLC 공식 사이트: https://ai-dlc.dev
- Kiro 공식 사이트: https://kiro.dev
- Kiro Steering Rules 문서: https://kiro.dev/docs/steering
- Kiro Hooks & Skills: https://kiro.dev/docs/hooks
- Amazon Q Developer: https://aws.amazon.com/q/developer/
- LG CNS AI-DLC for Enterprise (AWS Marketplace): https://aws.amazon.com/marketplace/pp/prodview-uusc5en5tx5ey