AI 코딩 도구의 활용 범위가 코드 작성과 수정에서 요구사항 정리, 테스트 생성, 배포 준비까지 확대되고 있습니다. 개발팀이 AI에 맡길 수 있는 일이 늘어날수록 중요한 것은 각 작업을 연결하는 기준인데요. 앞 단계에서 합의한 요구사항이 구현에 반영됐는지, 생성된 코드를 누가 검토하는지, AI가 어디까지 실행해도 되는지를 함께 정해야 합니다.
이러한 변화와 맞닿아 있는 개념이 AI-DLC입니다. AI-DLC는 AI의 참여를 전제로 개발 과정과 사람의 역할을 구성하는 접근입니다. 이 블로그에서는 AI-DLC의 의미와 주요 단계를 살펴보고, 기업이 개발 현장에 적용할 때 점검해야 할 보안 과제를 정리합니다.
AI-DLC란 무엇인가
AI-DLC는 AI-Driven Development Lifecycle의 약자로, AI 주도 개발 라이프사이클을 뜻합니다.
AWS가 공개한 AI-DLC 방법론은 AI가 작업 계획과 구현을 주도하되, 사람이 중요한 의사결정과 결과 검증을 책임지는 협업 구조를 중심에 둡니다. 여기서 다루는 대상은 AI 모델 자체의 학습 과정이 아닌 AI를 활용해 소프트웨어를 개발하는 과정입니다.
기존 소프트웨어 개발 라이프사이클인 SDLC에는 요구사항 분석, 설계, 구현, 테스트, 배포와 운영이 포함됩니다. AI-DLC에서도 이 업무들은 필요하며, 달라지는 것은 수행 방식입니다. AI가 목표를 세부 작업으로 나누고 필요한 정보를 질문하면, 팀이 계획을 검토하고 승인합니다. 이후 AI가 만든 산출물을 다시 확인하며 다음 작업으로 이어갑니다.
이 과정이 일관되게 이어지려면 요구사항과 설계 결정이 대화창에만 남아서는 안 됩니다. 문서와 저장소에 기록해 다음 작업에서도 참조할 수 있어야 합니다. AI-DLC의 핵심은 AI가 사용할 맥락과 사람이 판단할 지점을 개발 절차 안에 마련하는 데 있습니다.
AI-DLC의 세 단계와 달라지는 개발 업무
AI-DLC는 크게 Inception, Construction, Operations의 세 단계로 구성됩니다. 각 단계에서 AI가 제안하거나 실행하는 작업과 사람이 확인해야 할 내용을 구분하면 전체 구조를 이해하기 쉽습니다.
1) Inception — 목표와 요구사항을 구체화하는 단계
AI가 비즈니스 목표를 분석하고 요구사항과 작업 단위를 정리합니다. 팀은 빠진 조건과 잘못된 가정을 확인하고, 무엇을 개발할지 합의합니다. 이때 기능뿐 아니라 접근 권한, 데이터 처리 범위, 성능과 같은 제약도 명확히 해야 이후 구현을 평가할 기준이 생깁니다.
2) Construction — 설계와 구현을 검증하는 단계
확정된 요구사항을 바탕으로 설계, 코드 생성, 빌드와 테스트를 진행합니다. 개발자는 아키텍처와 변경 내용을 검토하고 테스트 결과를 확인합니다. AI가 작성한 코드와 테스트가 서로 일치하는 것만으로 요구사항 충족이 입증되지는 않습니다. 실제 업무 규칙과 예외 상황을 기준으로 검증해야 합니다.
3) Operations — 배포 이후까지 관리하는 단계
개발 과정에서 축적한 맥락을 배포와 운영에 활용합니다. AI는 인프라 구성이나 배포 준비를 지원하고, 운영 데이터 분석과 문제 해결에도 활용될 수 있습니다. 운영 환경에 영향을 주는 변경은 별도의 검토가 필요하며, 실행 결과를 확인할 책임도 팀에 남습니다.
세 단계 안의 세부 절차는 프로젝트에 맞춰 조정할 수 있습니다. 모든 변경에 같은 수준의 문서와 검토를 요구하기보다 복잡도와 영향도에 따라 깊이를 정하는 방식입니다. 다만 절차를 줄이더라도 필요한 승인과 검증까지 빠지지 않도록 해야 합니다.
개발자의 업무에서도 비중이 달라집니다. AI가 작업을 수행하는 동안 개발자는 문제를 정확히 정의하고, 설계의 타당성과 변경 영향을 판단해야 합니다. 따라서 AI 활용 성과를 평가할 때도 생성한 코드의 양과 함께 검토 시간, 재작업, 배포 후 결함을 살펴보는 것이 좋습니다.
AI 시대 개발 환경에서 점검할 보안 과제
AI-DLC를 적용한다고 기존의 소프트웨어 보안 문제가 사라지지는 않습니다. 코드와 의존성의 취약점은 계속 점검해야 하며, AI에 전달되는 정보와 에이전트의 실행 권한도 관리 대상이 됩니다. 보안 검토 범위에 개발 결과물과 AI가 일하는 환경을 함께 포함해야 하는 이유입니다.
1) 작동하는 코드와 안전한 코드를 구분해야 합니다
AI가 생성한 코드에도 인증·인가 처리의 누락, 부적절한 입력 검증, 취약한 의존성이 포함될 수 있습니다. 기능 테스트가 성공했더라도 사용자가 허용된 데이터에만 접근하는지, 잘못된 입력을 안전하게 처리하는지는 별도로 확인해야 합니다.
검증 수단도 나누어 적용해야 합니다. 소스 코드의 취약 패턴을 찾는 정적 분석(SAST), 외부 구성 요소의 취약점과 라이선스를 확인하는 소프트웨어 구성 분석(SCA), 비밀정보 탐지 등을 개발 절차에 연결할 수 있습니다. 자동 검사로 판단하기 어려운 업무 권한과 데이터 처리 로직은 사람이 검토해야 합니다. AI의 코드 리뷰 역시 이러한 검증을 보조하는 수단으로 사용하는 것이 적절합니다.
2) AI에 제공하는 맥락이 정보 노출 경로가 될 수 있습니다
AI가 개발 업무를 이해하려면 소스 코드와 설계 문서, 오류 로그 등을 참조해야 합니다. 이 자료에는 API 키나 개인정보, 내부 시스템 정보가 포함될 수 있습니다. 입력할 자료의 범위와 전송 경로를 정하고, 서비스별 데이터 보관·이용 조건을 확인해야 합니다. 필요한 부분만 전달하고 민감정보를 가리는 절차도 중요합니다.
외부 문서나 도구의 응답을 읽을 때는 프롬프트 인젝션도 고려해야 합니다. 이는 입력에 포함된 지시가 AI의 동작을 의도하지 않은 방향으로 바꾸는 문제입니다. 참고 자료 속 문장을 실행 지시로 받아들이면 원래 요청과 무관한 행동으로 이어질 수 있습니다. OWASP는 외부 콘텐츠의 구분, 최소 권한, 고위험 작업의 사람 승인 등을 함께 적용하도록 권고합니다.
3) 에이전트의 권한과 연결 도구가 보안 범위를 결정합니다
파일 수정이나 명령 실행, 외부 시스템 호출이 가능한 에이전트에서는 잘못된 판단이 실제 변경으로 이어질 수 있습니다. OWASP는 과도한 기능·권한·자율성을 주요 위험 요인으로 설명합니다. 업무에 필요한 도구와 권한만 제공하고, 읽기·쓰기·배포 권한을 구분해야 합니다. 운영 환경 접근이나 중요한 데이터 변경에는 별도의 승인 조건을 두는 것이 좋습니다.
플러그인과 외부 연동 도구도 검토 대상입니다. 설치 당시의 검토만으로 이후 업데이트까지 신뢰할 수는 없습니다. 공급자의 신뢰도와 요청 권한을 확인하고, 실제 설치된 코드가 승인한 버전과 일치하는지도 검증해야 합니다. 이는 AI 코딩 에이전트의 플러그인 공급망을 분석한 최근 보안 연구에서도 확인된 점검 사항입니다.
4) 검토와 승인 이력이 연결되어야 합니다
AI가 만든 변경 사항을 추적하려면 코드 수정 이력만으로는 부족할 수 있습니다. 어떤 요구사항을 바탕으로 작업했는지, 어떤 검사를 통과했는지, 누가 배포를 승인했는지를 함께 확인할 수 있어야 합니다. 그래야 문제가 생겼을 때 원인을 찾고 같은 오류의 반복을 줄일 수 있습니다.
보안 기준을 개발 절차 안에서 작동시키는 방법
보안 원칙은 실제 개발 도구와 배포 절차에서 작동해야 합니다. AI에게 규칙을 알려주는 것과 시스템이 규칙을 강제하는 것은 구분해야 합니다.[6] 이때 보안 지침을 프롬프트나 규칙 파일에 넣는 것은 작업 방향을 잡는 데 도움이 됩니다. 다만 파일 접근 제한은 권한 설정으로, 외부 통신 제한은 실행 환경으로, 배포 조건은 파이프라인의 검사와 승인으로 구현해야 합니다. 모델이 지시를 놓치더라도 중요한 작업이 허용 범위를 벗어나지 않도록 구성하는 것입니다.
기업이 AI-DLC에 적용할 점검 항목은 다음과 같이 정리할 수 있습니다.
|
개발 단계
|
주요 점검 항목
|
남겨야 할 근거
|
|---|---|---|
|
기획과 요구사항
|
비구조화된 메시지 스레드 채널
|
구조화된 주제 기반 토론을 위한 스레드 모델
|
|
설계와 구현
|
광범위한 에코시스템(GitHub, Trello, Jira, Zoom 등)
|
기본 제공 통합 기능은 적지만 API를 통해 사용자 지정 가능
|
|
배포와 운영
|
직관적이고 초보자 친화적
|
기존의 방식보다 덜 일반적이지만 고도로 구조화된 대화
|
자동화 수준도 작업의 위험에 맞춰 조정하는 편이 좋습니다. 영향이 작고 되돌리기 쉬운 작업은 검증된 절차 안에서 자동화하고, 운영 데이터나 접근 권한에 영향을 주는 작업은 사람의 검토를 거치도록 구분할 수 있습니다. 검토자는 변경 내용과 검사 결과를 확인한 뒤 승인할 수 있어야 합니다.
기준은 한 번 정하고 끝낼 수 없습니다. 사용하는 모델과 도구, 권한 설정이 바뀌면 기존 검사로 충분한지 다시 확인해야 합니다. 실행 중 발견한 오류와 검토 결과를 요구사항과 보안 규칙에 반영하면 다음 작업의 판단 근거도 더 명확 해집니다.
AI-DLC의 생산성을 뒷받침하는 보안 체계
AI-DLC는 AI의 작업 능력을 개발 전반에 활용하면서 사람이 판단하고 검증할 지점을 체계화하는 접근입니다. 이를 안정적으로 적용하려면 개발 도구의 성능과 함께 요구사항의 명확성, 검토 책임, 실행 권한, 추적 가능한 기록을 갖춰야 합니다. 이러한 기준이 있어야 팀이 안심하고 자동화 범위를 넓힐 수 있습니다.
보안 도구도 이 과정에서 실질적인 도움을 줄 수 있습니다. 코드와 의존성 검사에 더해 AI 요청과 응답의 정책 적용, 접근 관리, 감사 기록을 지원하는 도구를 함께 검토할 수 있습니다. 도구를 도입할 때는 필요한 데이터 경로와 실행 지점에 통제가 실제로 적용되는지 확인해야 합니다. 개발 속도와 검증 가능성을 함께 확보하는 것, 이것이 기업이 AI-DLC를 지속적으로 활용하기 위한 기준입니다.
