왜 기업 DevOps는 아직도 파편화되어 있는가

엔터프라이즈 DevOps 도입을 시작한 지 10년이 넘었지만, 대부분의 기업은 여전히 여러 개의 도구를 겨우 붙여 놓은 상태다. 이슈 트래커, 저장소 호스팅, CI 빌드, 배포 자동화, 모니터링이 각자 다른 회사의 SaaS 또는 온프레미스 서버에 있고, 그 사이를 잇는 건 사람과 스크립트다.

문제는 도구 부족이 아니다. 도구 사이의 합의가 없다는 것이다.

1. 통합은 왜 매번 무너지는가

일반적인 통합 시도는 이렇게 시작한다.

• 이슈 트래커에 깃 커밋 ID를 첨부
• CI 결과를 PR 코멘트로 자동 게시
• 배포 성공/실패를 Slack 으로 푸시
• 보안 스캔 결과를 티켓으로 자동 생성

각각은 작동한다. 그런데 6개월 뒤 보면, 이 통합들이 서로를 알지 못한다. CI 가 배포 도구의 상태를 모르고, 배포 도구는 어떤 이슈가 함께 들어왔는지 모르며, 보안 스캔은 그 둘과 분리된 채로 자기 워크플로우를 갖는다.

각 도구가 "주인"인 영역만 잘 안다. 자기 영역 밖에서 일어나는 일은 webhook 으로 통보받을 뿐이고, 그것을 연결된 컨텍스트 로 만드는 건 결국 사람이 한다.

2. "위에 한 겹 더" 가 답이 아닌 이유

이 문제를 해결하기 위해 등장한 게 보통 통합 대시보드나 DevOps 플랫폼이다. 위에서 모든 데이터를 모으고, 한 화면에서 보여주고, 가능하면 액션도 트리거한다.

하지만 대시보드는 읽는 도구지 실행하는 도구가 아니다. 의사결정과 실행이 결국 원래 도구로 돌아간다. 대시보드에서 확인 → Jenkins 로 가서 재빌드 → GitLab 으로 가서 머지 → Jira 로 가서 상태 업데이트.

실행이 분산된 환경에서 통합 대시보드는 요약일 뿐, 통제 평면(control plane) 이 되지 못한다.

3. 실행 레이어란 무엇인가

CollabOps 가 정의하는 실행 레이어(execution layer) 는 다음 세 가지를 한 평면에서 보장한다.

1. 상태(state) — 이슈, 변경요청, 빌드, 배포가 같은 그래프 위에 있다.
2. 권한(authority) — 누가 무엇을 실행할 수 있는지가 한 곳에서 정의되고 감사된다.
3. 실행(execution) — 자동화 액션이 그래프 위에서 트리거되고, 결과가 같은 그래프에 다시 기록된다.

이 셋이 한 평면에 있을 때, 비로소 "이슈 → 코드 → 빌드 → 배포 → 운영" 이 연결된 사실 이 된다. 분리된 도구의 합집합이 아니다.

4. 온프레미스에서 특히 어려운 이유

이 문제는 특히 온프레미스 / 폐쇄망 환경에서 심각해진다.

• 외부 SaaS 통합 플랫폼을 못 쓴다.
• 도구마다 인증 시스템이 다르고, SSO 로 묶여 있어도 권한 모델이 도구별로 갈린다.
• 감사·추적이 도구별로 흩어져 있어 사고가 났을 때 인과를 재구성하기가 어렵다.

공공·금융 같은 규제 산업은 여기에 법적 의무가 더해진다. 누가 언제 무엇을 배포했는가를 증명 해야 한다. 도구 다섯 개에 걸친 로그를 사람이 짜맞춰서 증명할 수는 없다.

5. 다음 글에서

이어지는 글에서는 이 실행 레이어가 AI 에이전트와 만나는 지점, 그리고 왜 단순한 "AI 코드 리뷰" 가 이 문제의 해법이 아닌지 다룬다.