AWS 기술 블로그

생성형AI를 통한 데브옵스 강화 – Part 1.소프트웨어 딜리버리 가속화

이 게시글은 생성형 AI를 통한 데브옵스 강화 시리즈의 첫 번째 게시글 입니다. DevOps Research and Assessment(DORA)에서 제시한 데브옵스 성숙도 측정 4가지 핵심 지표는 처리량 지표(변경 적용 시간, 배포 빈도)와 안정성 지표(변경 실패율, 장애 복구 시간)로 구분됩니다. Part 1에서는 처리량 지표 개선을 위한 소프트웨어 딜리버리 가속화에 초점을 맞추며, Part 2에서는 안정성 지표 향상을 위한 운영 안정성 강화 방안을 소개합니다.

데브옵스를 도입해야하는 이유

오늘날 비즈니스 환경에서 소프트웨어는 단순한 지원 도구가 아닌 핵심 경쟁력으로 자리 잡았습니다. 이러한 변화 속에서 데브옵스(DevOps)는 조직이 빠르게 변화하는 시장 요구에 대응하고 고객 가치를 지속적으로 전달하기 위한 필수 요소가 되었습니다.

전통적인 소프트웨어 개발 방식은 마치 한 팀이 레고 조각을 설계 및 제작하고 다른 팀이 설명서 없이 그것을 조립하는 것과 같았습니다. 즉, 개발자들이 코드를 작성하고 나면 이 후 코드를 실행하고 운영하는 것은 IT 운영팀의 몫이 되었습니다. 이러한 사일로화된 접근 방식은 세 가지 주요 문제를 야기했습니다:

  1. 조직 또는 팀간의 소통하는 데 소비되는 시간으로 인해 모든 과정이 지나치게 오래 걸렸습니다.
  2. 운영팀은 코드에 대한 세세한 부분을 알지 못하기 때문에 문제 발생 시 빠르게 대처하기 어려웠습니다.
  3. 조직들은 장애 복구에 막대한 비용을 지출해야 했습니다.

데브옵스는 이러한 문제를 해결하기 위해 전통적인 소프트웨어 개발과 IT 운영을 결합하며, 문화, 프로세스, 기술을 통합합니다. 이는 계획(Plan), 코드(Code), 빌드(Build), 테스트(Test), 배포(Deploy), 운영(Operate), 모니터링(Monitor)의 연속적인 사이클로 이루어집니다.

데브옵스를 도입함으로써 얻을 수 있는 주요 이점은 다음과 같습니다:

  • 확장성(Scale): 데브옵스 도구와 관행은 중단 없이 애플리케이션과 서비스를 원활하게 반복적으로 확장할 수 있도록 도와줍니다.
  • 속도(Speed): 지속적 통합(CI)과 지속적 배포(CD)를 통해 코드 커밋부터 프로덕션 환경까지의 시간을 단축합니다.
  • 안정성(Reliability): 데브옵스는 일관된 성능을 제공하고, 장애로부터의 빠른 복구, 지속적인 모니터링을 통해 고객에게 영향을 미치기 전에 문제를 포착할 수 있게 합니다.
  • 협업(Collaboration): 기존의 사일로화된 팀들이 서로 다른 목표와 목적을 가지고 협업하던 방식에서 벗어나, 통합된 책임과 목표로 함께 일하는 방식으로 전환합니다.
  • 보안(Security): 보안은 더 이상 마지막 단계의 체크리스트가 아닙니다. DevSecOps를 통해 개발 라이프사이클 전반에 보안을 적용합니다.

데브옵스 성숙도 측정

데브옵스 여정을 시작하거나 개선하기 위해서는 현재 조직의 데브옵스 성숙도를 객관적으로 측정하는 것이 중요합니다. DORA에서 제시한 4가지 핵심 지표는 데브옵스 성숙도를 측정하는 데 널리 사용됩니다:

  1. 변경 적용 시간(Lead Time for Changes): 코드 변경이 커밋에서 프로덕션까지 걸리는 시간
  2. 배포 빈도(Deployment Frequency): 코드가 프로덕션에 배포되는 빈도

위 두 지표는 처리량 지표(Throughput Metrics)로, 시간에 따른 속도를 측정합니다.

  1. 변경 실패율(Change Failure Rate): 프로덕션 배포 후 수정이 필요한 비율
  2. 장애 복구 시간(Mean Time to Recovery, MTTR): 서비스 중단 시 복구까지 걸리는 평균 시간

위 두 지표는 안정성 지표(Stability Metrics)로, 배포의 품질과 장애 대응 능력을 측정합니다.

이러한 지표를 통해 조직은 자신의 데브옵스 성숙도 수준을 파악하고, 개선이 필요한 영역을 식별할 수 있습니다.

Goodhart의 법칙에 따르면 “측정 지표가 목표가 되면, 그것은 더 이상 좋은 측정 지표가 아니다.” 즉, 하나의 지표에만 집중하면 다른 지표가 자연스럽게 악화될 수 있으므로, 전체적인 관점에서 균형 있는 개선이 필요합니다.

지표 최상 🏆 상 🥇 🥈 🥉
변경 리드 타임 1일 미만 1일 -1주 1주 – 1개월 1주 – 1개월
배포주기 상시 1/1일 – 1/주 1/주 – 1/월 1/주 – 1/월
실패율 5% 10% 15% 64%
복구시간 1시간 미만 1일 미만 1일 – 1주 1 – 6개월

높은 데브옵스 성숙도를 달성하기 위해 활용하는 주요 방법들은 다음과 같습니다:

  • 자동화: AWS CodePipeline, Jenkins, GitLab, GitHub 등의 CI/CD 도구를 활용한 테스트, 빌드, 배포 자동화
  • 코드형 인프라(IaC): AWS CDK, Terraform과 같은 도구를 활용하여 환경의 일관성과 버전 관리 보장
  • 테스트 모니터링: Selenium, Junia, Grafana, Prometheus 등을 활용한 사전 테스트와 모니터링
  • 버전 관리 코드 리뷰: 자동화된 병합 검사와 인적 검토를 통한 코드 품질 보장
  • 피드백 루프: 전체 개발 과정에서 일관된 모니터링과 단위 테스트
  • 자가 치유 시스템: 모니터링을 활용한 자동 확장 그룹, 서비스 재시작 등의 자동 복구 메커니즘

소프트웨어 딜리버리 가속화

개발 생산성 향상

생성형 AI는 개발자의 생산성을 크게 향상시킬 수 있습니다. Amazon Q Developer와 같은 도구는 개발자가 코드를 이해하고, 작성하고, 개선하는 데 큰 도움을 줍니다. Amazon Q Developer의 주요 기능은 다음과 같습니다:

  • 코드 이해 지원: “현재 프로젝트에 대해 설명해줘”와 같은 질문을 통해 코드베이스를 빠르게 탐색하고 이해할 수 있습니다.
  • 코드 개발: 자연어 요청을 통해 새로운 기능 구현, 기존 코드 수정, API 통합 등을 자동으로 수행하고, 개발자의 의도를 파악하여 프로젝트 컨텍스트에 맞는 최적화된 코드를 제공합니다.
  • 코드 리팩토링: 반복되는 코드 패턴을 식별하고 더 모듈화된 구조로 리팩토링하여 코드 품질을 향상시킵니다.
  • 단위 테스트 생성: 개발자들이 가장 미루고 싶어하는 작업 중 하나인 단위 테스트 작성을 자동화하여, AWS 서비스 API 모킹, 병렬 워크플로우, 엣지 케이스 등을 고려한 포괄적인 테스트 스위트를 생성합니다.

이러한 기능들은 개발자가 코드베이스를 이해하고, 변경하고, 테스트하는 데 소요되는 시간을 크게 단축시켜 줍니다. 처음 접하는 코드베이스에서도 몇 분 만에 코드를 이해하고, 개선하고, 테스트할 수 있습니다.

예시 프로젝트 소개

실제 프로젝트 예시를 통해 각 기능을 어떻게 활용하는지 살펴보겠습니다. 예시 프로젝트는 칠리콘의 동물 퀴즈 게임입니다. 이 게임은 스무고개 형식으로 진행되며, 사용자가 질문을 하면 생성형 AI가 답변을 통해 정답을 맞추는 Spring Boot 기반의 웹 애플리케이션입니다. 웹 기반 UI를 통해 사용자와 상호작용하며, 다양한 동물들이 정답으로 등록된 퀴즈 시스템과 REST API 구조로 구성되어 있습니다.

이제 우리는 이 칠리콘 게임을 개발하는 AnyCompany의 개발 팀이라고 가정하고, 데브옵스 사이클을 가속화하기 위해 생성형 AI를 활용하는 구체적인 방법들을 살펴보겠습니다.

코드 이해 지원

새로운 개발자가 프로젝트에 투입될 때, 조직의 좋은 온보딩이나 잘 정리된 문서가 있으면 문제없지만 그렇지 않은 경우가 많습니다. 이럴 때 Amazon Q Developer를 활용하면 빠르게 프로젝트를 파악할 수 있습니다. @workspace를 입력하면 현재 작업 중인 프로젝트의 코드 파일, 구성 파일, 디렉토리 구조 등을 자동으로 분석하여 프로젝트전체의 컨텍스트를 Q Developer에게 제공합니다. 이를 통해 Q Developer는 프로젝트의 아키텍처, 사용된 기술 스택, 코딩 패턴 등을 이해하여 더 정확하고 프로젝트에 맞는 코드 제안을 할 수 있습니다. “@workspace 현재 프로젝트에 대해 설명해줘”라고 입력합니다.

질문을 통해 코드베이스를 빠르게 탐색하고 이해할 수 있으며, 컨텍스트를 참고하여 다음과 같은 정보를 자동으로 제공합니다:

  • 현재 프로젝트 설명과 게임 규칙
  • 기술 스택 및 주요 컴포넌트
  • 주요 기능 및 UI 구조

코드 개발

신규 개발자에게 새로운 사용자 스토리가 할당되었을 때, 실제 소스 코드를 보거나 디버깅하면서 기능을 어디에 추가할지 파악하는 작업은 시간이 많이 소요됩니다. 특히 코드의 가독성이 떨어지는 경우 코드 분석과 이해에 더 많은 시간이 필요합니다. 이럴 때 Q Developer의 /dev 에이전트 기능을 활용하여 시간을 절약할 수 있습니다. “/dev 정답 동물에 고양이를 추가해 줘”라고 입력합니다.

Q Developer의 /dev 에이전트 기능을 활용하면 자연어 요청을 통해 새로운 기능 구현, 기존 코드 수정, 외부 서비스 연동 등을 자동으로 생성할 수 있습니다. 에이전트는 단순히 채팅으로 코드를 생성하는 것과 달리 다음과 같은 자율적 프로세스를 수행합니다:

  • 목표 달성을 위한 코드 분석 및 플랜 수립
  • 진행 상황 평가 및 필요시 계획 조정
  • 개발자의 의도를 파악하여 프로젝트 컨텍스트에 맞는 최적화된 코드 제공

코드 리팩토링

REST API 코드에서 가독성과 유지보수성을 높이기 위한 리팩토링 작업, 특히 여러 메서드에 중복된 코드나 개선이 필요한 패턴을 발견했을 때, 이를 하나하나 고치는 것은 많은 시간과 노력이 필요합니다. Amazon Q Developer를 이용하면 한번에 리팩토링이 가능합니다. 전체 소스 코드를 선택하고 마우스 우클릭 > Amazon Q > Refactor를 클릭합니다.

해당 Controller에서는 요청, 응답 타입을 의미 있는 DTO를 사용해서 리팩토링할 것을 안내하고 있습니다. 반복되는 코드 패턴을 식별하고 더 모듈화된 구조로 리팩토링하여 코드 품질을 향상시킵니다.

단위 테스트 생성

개발자들이 가장 미루고 싶어하는 작업 중 하나인 단위 테스트 작성을 자동화하여, AWS 서비스 API 모킹, 병렬 워크플로우, 엣지 케이스 등을 고려한 포괄적인 테스트 스위트를 생성합니다. 유닛 테스트를 작성할 파일을 열고 /test를 입력합니다.

/test를 입력하면, 에이전트 기능을 통해 다양한 시나리오를 고려한 포괄적인 테스트 케이스를 자동으로 생성해줍니다.

SDLC 병목 식별

소프트웨어 개발 라이프사이클(SDLC)에서 요구사항 불명확, 설계단계에서 아키텍처 결정 지연등의 Plan, Design 단계에서의 병목 현상은 전체 개발 프로세스의 속도를 저하시킬 수 있습니다. 이를 개선하기 위해서 ALM(Application Lifecycle Management)나 이슈 트래커등에서의 로그들을 활용하여 분석할 수 있지만, 번거롭고, 시간이 오래걸린다는 문제가 있습니다. 이때 Amazon Q Developer를 사용하여 로그들을 분석하면 개발 프로세스의 병목 지점을 빠르고 쉽게 식별할 수 있습니다.

해당 파일은 이슈 트래커에서 추출한 로그 파일입니다. 여기에는 신규 요구사항이나 요구사항의 상태 변경 기록이 포함되어 있기 때문에 개발 수명주기 전반을 이해할 수 있습니다.

“이 데이터에서 프로젝트 개발 수명주기의 개선점을 찾아 줘”라고 질문하면 다음과 같은 주요 병목 지점들이 식별되고, 추가로 해결방안들을 제시합니다.

주요 분석 결과

  • 요구사항이 명확하지 않은 문제: 일부 작업에서는 정보가 충분하지 않아 개발자와 요청자 사이에 불필요한 커뮤니케이션이 발생하고 있었습니다.
  • 작업 크기의 문제: 피쳐가 버그 픽스나 enhancement에 비해 상대적으로 작업이 크고, 기능(Feature) 작업이 버그 수정이나 작은 개선 작업보다 훨씬 더 오래 걸리고 있었으며, 이는 작업이 너무 크게 정의되어 있음을 시사했습니다.
  • 업무 분배의 문제: 업무가 특정 인원들에게 몰리는 문제가 있었습니다.

제안된 해결방안

  • 요구사항 명확화: 개발 시작 전 요구사항을 명확히 정의
  • 작업 분할: 크기가 큰 태스크를 2주 이내 완료 가능한 작은 서브 태스크로 분리
  • 전략적 업무 분배: 특정 인원에게 업무가 몰리지 않도록 균형있는 분배

이러한 인사이트를 바탕으로, 개발 프로세스를 개선하기 위한 구체적인 조치를 취할 수 있습니다. 예를 들어, 큰 기능 작업을 더 작은 하위 작업으로 분할하여 개발자가 한 번에 더 관리하기 쉬운 크기의 작업에 집중할 수 있도록 할 수 있습니다.

개발자 업무 방해 요소 제거

개발자의 생산성은 집중할 수 있는 환경에 크게 좌우됩니다. 소프트웨어 개발 과정에서 개발자들은 다양한 업무 방해 요소에 직면하게 되는데, 그 중에서도 이슈 트래커에서 발생하는 문제는 개발 흐름을 크게 저해할 수 있습니다.

이슈 트래커에서의 주요 업무 방해 요소

이슈 트래커에서 개발자의 업무 흐름을 방해하는 주요 요소들은 다음과 같습니다:

  1. 불충분한 작업 설명: 작업 설명이 모호하거나 필요한 정보가 부족할 경우, 개발자는 추가 정보를 요청하기 위해 작업을 중단해야 합니다. 이는 개발 흐름을 끊고 시간을 낭비하게 만듭니다.
  2. 과도하게 작업 범위: 너무 크거나 복잡한 작업은 개발자에게 부담을 주고, 진행 상황을 추적하기 어렵게 만듭니다.
  3. 불명확한 우선순위: 작업의 우선순위가 명확하지 않으면 개발자는 어떤 작업에 집중해야 할지 결정하는 데 시간을 소비합니다.
  4. 빈번한 컨텍스트 전환: 여러 작업 사이를 오가며 작업해야 할 때 발생하는 컨텍스트 전환은 생산성을 크게 저하시킵니다.

특히 작업 설명이 충분하지 않은 경우, 개발자는 작업을 완료한 후에야 요구사항이 자신의 이해와 다르다는 것을 알게 되어 코드를 다시 작성해야 하는 상황이 발생할 수 있습니다. 이는 개발 시간을 크게 증가시킬 수 있습니다.

이러한 문제를 해결하기 위해 Jira와 같은 이슈 트래커에 자동화를 추가하여 개발자의 업무 흐름을 방해하는 요소들을 제거할 수 있습니다.

자동화 솔루션의 주요 기능은 다음과 같습니다:

  1. 작업 설명 검증: 새로운 작업이 생성될 때, DevOps 봇이 자동으로 설명을 검증하고 충분한 정보가 포함되어 있는지 확인합니다. 정보가 부족한 경우, 봇은 필요한 정보(테스트 기준, 수락 기준 등)를 요청하고 작업을 요청자에게 재할당하여 개발자가 불필요하게 시간을 낭비하지 않도록 합니다.
  2. 하위 작업 자동 생성: 큰 기능 작업이 생성될 때, 봇은 자동으로 이를 개발자가 하루 안에 완료할 수 있는 크기의 하위 작업으로 분할합니다. 각 하위 작업에는 명확한 제목과 설명이 포함되어 있어, 개발자가 전체 목표를 달성하기 위해 무엇을 해야 하는지 쉽게 이해할 수 있습니다.

개발자 업무 방해 요소 제거 프로세스

앞서 설명했던 이슈 트래커에서 주요 업무 방해 요소와 그를 해결하기 위한 AWS 서비스를 활용한 자동화 솔루션으로 어떻게 문제가 해결되는지 프로세스를 간단히 살펴보도록 하겠습니다. 여기서는 여러 이슈 트래커들 중 많은 기업에서 사용되고 있는 Jira를 예로 들었습니다.

  1. Jira에서 새 Task를 생성합니다.
  2. 이때 Task 작성자는 필수 값인 Summary만 입력하거나 필요한 값들을 누락하고 입력 할 수 있습니다.
  1. 이 작업은 생성형AI가 작업 설명을 평가하고, 필요한 내용이 무엇인지 DevOps Bot이 커멘트를 작성합니다.
  2. 생성된 작업을 다시 확인해보면 DevOps Bot이 비어있는 티켓에 대해 알리면서 사용자 스토리, 구현 세부사항, 테스트 기준등을 업데이트 되어야 한다고 알려주고, Assignee가 티켓 생성자로 변경 되었습니다.
  1. 이제 이를 확인하여 자세한 내용을 입력하고 다시 저장합니다.
  2. 작업 설명 평가가 통과하면 생성형AI가 이 작업을 적절한 크기의 작업들을 하위 작업들로 나누고 작업을 업데이트 합니다.
  1. 이제 개발자는 잘 설명되고, 하위 작업이 잘 나누어진 티켓을 보고 개발을 시작 할 수 있습니다.

개발자 업무 방해 요소 제거 아키텍처

이 자동화 솔루션의 아키텍처는 다음과 같습니다:

  1. Jira에서 새 작업이 생성되면 Amazon SNS 토픽이 트리거됩니다.
  2. SNS 토픽은 오케스트레이션 워크플로우를 시작하는 AWS Lambda 함수를 호출합니다.
  3. 워크플로우는 AWS Step Functions 상태 머신 내에서 실행되며, 첫 번째 작업으로 작업 설명을 평가하는 Lambda 함수를 포함합니다.
  4. 이 함수는 Amazon Bedrock을 사용하여 작업 설명을 분석하고, 품질 기준을 충족하는지 평가합니다.
  5. 평가를 통과하지 못할 경우, Jira API를 통해 티켓에 추가되야할 내용을 티켓 커멘트에 작성합니다.
  6. 평가를 통과할 경우 하위 태스크를 정의하는 Lambda함수가 호출됩니다.
  7. 하위 태스크를 Lambda함수가 Amazon Bedrock를 호출하여 티켓을 하루안에 개발 가능한 크기로 나눕니다.
  8. Jira API를 통해 하위 테스크들을 생성합니다.

이러한 자동화를 통해 개발자는 불충분한 정보로 인한 지연이나 너무 큰 작업으로 인한 부담 없이, 핵심 개발 활동에 집중할 수 있게 됩니다.

결론

생성형 AI는 데브옵스 프랙티스를 강화하고 소프트웨어 딜리버리를 가속화하는 강력한 도구입니다. Amazon Q Developer, Amazon Bedrock과 같은 도구를 활용하면 개발 생산성을 향상시키고, SDLC 병목을 식별하며, 개발자 업무 방해 요소를 제거할 수 있습니다.

특히 생성형 AI가 실제 개발 환경에서 어떻게 활용될 수 있는지를 잘 보여주었습니다. 코드 이해부터 리팩토링, 단위 테스트 생성까지, 생성형 AI는 개발자가 더 효율적으로 작업할 수 있도록 도와줍니다.

또한, 이슈 트래커와의 통합을 통해 작업 설명 검증과 하위 작업 자동 생성과 같은 자동화를 구현함으로써, 개발자가 핵심 개발 활동에 더 집중할 수 있는 환경을 조성할 수 있습니다.

이러한 도구와 방법론을 활용하면, DORA에서 정의한 처리량 지표(변경 적용 시간, 배포 빈도)를 개선하여 소프트웨어 딜리버리를 가속화할 수 있습니다. Part2에서는 운영 안정성을 위한 생성형 AI의 활용 방안에 대해 더 자세히 살펴보겠습니다.

Dohyung Kim

Dohyung Kim

김도형 Solutions Architect는 다양한 인더스트리의 고객과 협업하며 여러 프로젝트를 성공적으로 수행해왔습니다. 그간의 경험을 바탕으로 AWS 고객들이 겪는 여러가지 다양한 어려움과 문제를 적극적으로 해결하며, 최적의 솔루션과 가이드를 드리고 있습니다.

Junki Park

Junki Park

박준기 Solutions Architect는 다양한 개발 경험을 바탕으로 고객의 비즈니스 문제를 AWS를 통해 해결하도록 아키텍처 설계 가이드와 기술을 지원하고 있습니다.