CollabOps가 말하는 Execution Layer란 무엇인가
통합 대시보드도, 단순한 자동화 엔진도 아니다. 상태·권한·실행이 한 평면에 살아 있다는 게 무슨 뜻인지.
"실행 레이어(execution layer)" 는 우리가 새로 만든 단어가 아니다. 인프라 분야에서 컨트롤 플레인(control plane) 과 데이터 플레인(data plane) 을 분리해 온 오랜 전통의 연장선이다. 다만 우리는 그것을 DevOps 워크플로우 자체 위에 올린다.
한 문장 정의
Execution Layer 는 상태(state), 권한(authority), 실행(execution) 이 같은 그래프 위에 있는 평면이다.
이 문장이 모든 것을 결정한다. 풀어 본다.
상태가 한 평면에 있다
이슈, 변경요청, 빌드, 배포, 인시던트가 모두 같은 그래프의 노드다. 각 노드는 다른 노드를 가리키고, 그 관계가 곧 추적 가능한 사실이다.
[Issue COH-1241]
└──[ChangeRequest CR-77]
├──[PR repo/web#812]
│ └──[Build #4419 PASS]
│ └──[Deploy staging-2026-04-20]
└──[PR repo/api#491]
└──[Build #4420 PASS]
└──[Deploy staging-2026-04-20]기존 도구 조합에서는 이 그래프를 사람이 머릿속에서 만든다. 우리는 이걸 데이터 모델로 만든다.
권한이 같은 평면에 있다
"누가 무엇을 할 수 있는가" 는 도구 다섯 개에 분산된 정책이 아니라, 같은 그래프 위의 역할(role) 과 경계(scope) 로 표현된다.
- role —
release-manager,qa-lead,secops-reviewer,agent:autodeploy-staging - scope — 어떤 프로젝트, 어떤 환경, 어떤 시간대에서
사람과 에이전트가 같은 권한 모델을 공유한다. 에이전트는 추가 가 아니라 확장 이다.
실행이 같은 평면에 있다
배포·롤백·재기동 같은 액션이 그래프 위의 노드를 변경 한다. 그 변경은 다시 그래프에 기록된다.
이것이 CollabOps 가 통합 대시보드와 다른 지점이다. 읽기와 쓰기가 같은 데이터 모델 위에서 일어난다.
그래서 무엇이 가능해지는가
세 가지가 자연스러워진다.
- 인과 추적 — 사고 발생 시 "이 배포가 어떤 이슈를 들고 갔고, 누가 승인했고, 어떤 빌드의 결과였는지" 가 한 쿼리로 답된다.
- 권한 감사 — "지난 분기에 production 배포 권한을 가졌던 주체와 그들이 실행한 액션 전체" 가 한 보고서로 나온다.
- AI 에이전트의 안전한 도입 — 사람과 같은 권한 모델·감사 트레이스 위에 에이전트를 올리는 것이 추가 인프라 없이 가능하다.
다음
이어지는 글에서는 이 평면 위에서 AI 에이전트가 실제로 하는 일 과 그 경계가 어떻게 정의되는지 다룬다.
비슷한 글
1억 원짜리 소프트웨어는 고객의 무엇을 바꿔야 할까
공급자가 원하는 계약 금액과 고객이 지불할 이유는 따로 설명해야 한다. 가상의 가정으로 투자 대비 효과를 끝까지 계산해 보면, 배포 한 번의 시간 절감만 세는 계산이 왜 부족한지와 함께 세야 할 항목이 무엇인지 드러난다.
백재민
고객은 Jira가 싫다고 했다. 그래서 새 Jira가 필요할까
익숙한 도구에 대한 불만은 듣기 쉽다. 근데 그 불만이 곧 구매 문제는 아니다. 한 대화에서 배운 것. 고객이 말한 불편과 조직이 지금 풀어야 하는 문제를 구분하는 법, 그리고 고객 인터뷰에서 대신 물어야 할 네 가지 질문.
백재민
기능은 늘었는데, "왜 우리 제품인가"는 더 어려워졌다
이슈·저장소·리뷰·CI/CD·문서·AI. 기능이 하나 늘 때마다 설명은 길어졌지만 고객이 지금 선택할 이유는 그만큼 선명해지지 않았다. 그래서 질문을 바꿨다. 고객이 지금 내리지 못하는 결정은 무엇인가. 우리가 Change를 제품의 중심에 놓은 이유.
백재민