AI가 DevOps를 가속화하지만, 열악한 통합이 이를 저해한다

출처: DevOps.com

AI가 소프트웨어 전달 속도를 높이는 지금, 실제 병목 현상은 스캔이나 CI가 아니라 변경 사항이 도구, 팀, 그리고 기업 사이를 얼마나 안전하고 예측 가능하게 이동하느냐에 있다.

현재 DevOps에서는 이상한 현상이 일어나고 있다. AI 코파일럿이 코드를 작성하고, 테스트를 생성하며, 사고를 분류하고, 심지어 사람의 눈이 닿기 전에 풀 리퀘스트를 요약한다. 도구 자체는 확실히 개선됐고, 팀은 그 어느 때보다 빠르게 배포하고 있다.

하지만 전체 전달 파이프라인이 눈에 띄게 빨라진 느낌은 아니다. 에스컬레이션은 여전히 팀 사이에서 사라지고, 상태 업데이트는 늦게, 잘못되게, 혹은 전혀 도착하지 않는다. 병목 현상이 이동했으며, 대부분의 조직은 그 새로운 병목이 어디인지 파악하지 못하고 있다.

코드 자체는 이제 문제가 아니다. 문제는 도구들 사이의 간극에 있다.

AI가 개별 도구를 똑똑하게 만들었지만, 그 사이 연결은 고치지 못했다

지난 2년은 DevOps 스택에서 AI가 금광을 찾은 시기였다. GitHub Copilot, Amazon CodeWhisperer, Snyk의 AI 지원 스캔, PagerDuty의 지능형 그룹화 등.

코드 생성은 빨라지고, 취약점 탐지는 더 신뢰성 있게 되며, 사고 잡음은 온콜 엔지니어에게 도달하기 전에 걸러진다.

하지만 이 도구들은 각각 독립된 세계에서 동작한다. Jira 티켓은 Jira에, Zendesk 케이스는 Zendesk에, ServiceNow 사고는 ServiceNow에 존재한다.

AI는 각 도구를 그 자체 경계 안에서 더 똑똑하게 만들었을 뿐, 데이터가 한 도구에서 다른 도구로 넘어갈 때는 거의 아무것도 하지 않았다.

그리고 어느 정도 복잡한 조직에서도 경계를 넘는 것이 실제 작업이 일어나는 지점이다.

통합에 대한 세금, 예산에 포함되지 않는다

대부분의 DevOps 리더가 공감할 시나리오다.

고객이 Zendesk 포털을 통해 버그를 보고한다. 지원팀이 이를 분류하고, 엔지니어링이 작업할 수 있도록 Jira에 등록한다.

하지만 Zendesk 티켓과 Jira 작업 항목은 서로 다른 시스템에 존재하는 별개의 객체이며, 서로 다른 팀이 서로 다른 워크플로우로 관리한다.

누군가가 정보를 수동으로 복사하거나 Slack을 통해 공유한다. 혹은 기본 웹훅이 작동해 스텁 티켓을 만든다. 어느 쪽이든, 중간에 무언가가 사라진다.

고객의 우선순위, 상태 업데이트, 그리고 엔지니어링에 중요한 커스텀 필드(환경, 영향을 받은 버전, 재현 단계) 등이 전달되지 않는다.

전통적인 통합 접근 방식이 무너지는 이유

대부분의 조직은 일종의 통합 인프라를 가지고 있다: 네이티브 커넥터, iPaaS 플랫폼, 커스텀 스크립트, 사내에서 유지되는 REST API 접착제 등.

이러한 접근 방식은 상태 필드 동기화나 알림 전송 같은 단순 시나리오에서는 충분히 작동한다. 하지만 요구사항이 복잡해지면 금방 무너지게 된다.

AI를 개별 도구에 얹어도 이러한 문제는 사라지지 않는다. 오히려 파이프라인 내 변화의 양과 속도가 증가하면서 상황은 악화된다.

즉, 자동 PR, 자동 분류된 사고, 그리고 기계가 만든 상태 업데이트가 더 많아진다. 통합 레이어가 이를 따라가지 못하면, 더 빠른 도구들이 각 핸드오프 지점마다 더 큰 백로그를 만든다.

AI가 실제로 통합에 도움이 되는 경우 (올바르게 적용될 때)

Plain-Language Configuration

전통적인 Jira‑to‑ServiceNow 통합은 설정, 테스트, 배포에 2~3주가 걸린다. Aida 같은 AI 지원 도구를 사용하면 몇 시간 안에 압축된다.

대화식으로 요구사항을 설명한다: “ServiceNow의 고우선순위 사고를 버그로 동기화하고, 내부 댓글과 상태를 양방향으로 업데이트해 주세요.”

AI는 양쪽 시스템의 실제 스키마를 기반으로 동작하는 Groovy 스크립트를 생성한다. 사용자는 검토하고, 테스트하고, 배포한다.

Status and Custom Field Mapping

Zendesk의 “Open”이 Jira의 “Open”과 동일하지 않을 수 있다. “Pending”은 워크플로우에 따라 “In Progress” 혹은 “To Do”로 매핑된다. 한쪽에만 존재하는 커스텀 필드, 드롭다운 리스트 등을 수동으로 매핑하는 일은 규모가 커지면 불가능하다.

스크립팅 AI는 양쪽 스키마를 분석하고 필드명, 데이터 타입, 사용 패턴을 기반으로 매핑을 제안한다. 모든 상태 전환을 직접 코딩하는 대신 매핑을 설명하면 AI가 조건 로직을 생성한다.

또한 사용자는 여러 Zendesk 티켓을 하나의 Jira 작업 항목으로 통합하거나, “feature‑request” 태그는 Story로, “bug” 태그는 다른 Jira 프로젝트의 Bug으로 자동 라우팅할 수 있다.

Cross-Company Integration

MSP가 고객과 티켓 데이터를 공유하거나, 벤더가 구현 파트너와 동기화하고, 기업이 공급업체와 협업할 때, 각 측은 자신이 공유할 내용과 들어오는 데이터를 내부적으로 어떻게 매핑할지 독립적으로 제어해야 한다.

실제 사례: 15개 고객을 서비스하는 MSP가 조직 식별자를 기준으로 Jira 에스컬레이션을 해당 고객의 Azure DevOps 프로젝트로 라우팅한다. 각 고객은 자신의 작업 항목만 볼 수 있고, MSP는 모든 계정에 대한 가시성을 유지한다.

Error Handling and Troubleshooting

API가 타임아웃되거나 스키마가 변경되고, 대량 작업 중에 레이트 리밋에 걸릴 수 있다. AI 기반 트러블슈팅은 오류 상황을 컨텍스트와 함께 분석하고, 구체적인 동기화 규칙에 기반한 해결책을 설명하고 제시한다.

대규모 환경에서는 15분 안에 해결되는 문제와 하루 종일 소요되는 화재 훈련의 차이를 만든다.

Closing the Sales-to-Support Loop

고객이 Salesforce에서 제품 업그레이드를 요청하는 케이스를 만든다. 지원팀은 이를 Freshdesk 혹은 Zendesk에서 평가해야 한다. 두 시스템이 동기화되지 않으면 누군가가 수동으로 상세 정보를 복사하고, 중간에 컨텍스트가 손실될 위험이 있다.

AI 지원 통합을 사용하면 계정 데이터, SLA 세부 정보, 커스텀 필드가 트리거 기반으로 자동 복제된다. 지원팀이 이슈를 해결하면 상태 업데이트가 Salesforce로 되돌아간다.

엔지니어링 에스컬레이션의 경우, “VIP” 태그가 붙은 Zendesk 티켓이 중요한 우선순위일 때 자동으로 해당 팀 스프린트 보드에 P1 Jira 버그가 생성되고, 첨부 파일과 대화 요약이 함께 들어간다.

병목은 이동했지만, 여러분의 아키텍처는?

AI는 코딩과 테스트를 가속화하고 있다.

하지만 소프트웨어 전달은 도구들의 집합이 아니라 시스템이다. 시스템에서는 제약이 가장 약한 고리로 이동한다. 현재 그 고리는 통합 레이어이며, 여기서 변경 사항, 데이터, 컨텍스트가 도구, 팀, 기업 사이를 오간다.

이 변화를 인식한 조직은 통합을 1급 관심사로 다루고, 내부 파이프라인에 적용하는 것과 동일한 엄격함으로 기업 간 데이터 교환을 처리할 수 있는 아키텍처를 구축한다.

그 외의 조직은 왜 모든 AI 투자가 실제 속도 향상으로 이어지지 않는지 계속 궁금해 할 것이다.