다음 10년의 DevOps는 에이전틱 (Agentic) 이다 — 그게 무엇을 의미하는가

지난 주 한 고객사 미팅에서 CIO 가 물었다.

"에이전트가 진짜로 우리 사람들을 대체할 수 있나?"

내가 처음으로 한 답은 "그건 잘못 짜인 질문이다" 였다. 그 자리에서 약간 무례했고, 그래서 다시 풀어 설명했다 — 그 설명이 이 글이다.

잘못된 질문 / 옳은 질문

대체냐 아니냐 — 이 프레임은 오래된 자동화 논쟁(20세기 공장 자동화) 에서 가져온 것이다. 이 일을 사람이 하느냐 기계가 하느냐 라는 이분법.

소프트웨어 엔지니어링은 그렇게 안 갈라진다. 빌드 자동화가 "엔지니어를 대체했나?" 물어보는 사람은 없다. CI 가 시간을 어디로 옮겼는지 묻는다.

옳은 질문은 같은 모양이다.

에이전트는 어떤 시간을 어디로 옮기는가.

옮기는 시간 세 가지

지난 1년 우리 고객사 데이터를 보면 세 종류의 시간이 옮겨졌다.

1차 트리아지 시간. 인시던트가 페이지로 떨어졌을 때 사람이 상황 정리 에 쓰는 3060분. 어떤 로그를 봐야 하나, 누구한테 알려야 하나, 비슷한 사고가 전에 있었나. 에이전트가 이 3060분을 거의 0으로 줄인다. 사람이 깨어났을 때 맥락이 정리된 채로 시작한다.

반복 운영 시간. PR 라벨링, 컨테이너 이미지 재빌드, 만료된 시크릿 회전, 죽은 워커 재기동. 에이전트가 24시간 떠 있고 권한 안에서 처리한다. 사람이 평일 9시에 출근해서 메시지 130개부터 읽는 패턴이 사라진다.

조사 시간. "왜 어제 이 빌드가 갑자기 느려졌나" 같은 질문. 사람이 답하려면 빌드 로그·시스템 메트릭·최근 머지 이력을 다 손으로 모아야 한다. 에이전트는 그 질문을 받자마자 그래프 위에서 답한다.

이 셋이 옮겨지면, 사람이 쓰는 시간은 어디로 가나?

사람이 쓰게 되는 시간

대체로 세 가지 쪽으로 간다.

• 설계 — 시스템을 어떻게 만들 것인가. 에이전트가 못 하는 일.
• 정책 결정 — 어떤 행동을 누구에게 위임할 것인가. 권한 모델 자체 를 그리는 일.
• 에이전트 감수 — 에이전트가 한 일을 주기적으로 점검 하는 일. 사람이 필요한 새 직무에 가깝다.

세 번째가 흥미롭다. 에이전트의 일을 검토하는 사람 이 새 역할로 등장한다. SRE 가 운영의 일부였다가 직무가 된 것처럼.

권한 경계 — 다음 10년의 진짜 이슈

대체가 안 된다고 해서 아무 일도 없는 것 도 아니다. 진짜 이슈는 권한 경계가 어디서 어떻게 그려지나 다.

2026 현재의 분기점

  사람이 1차 결정              에이전트가 1차 결정
  사람이 실행                  사람이 승인 후 에이전트 실행
        ↑
        ↑           ←──  지금 대부분의 조직이 여기쯤
        ↑
  에이전트가 1차 결정          에이전트가 1차 결정
  사람이 실행                  에이전트가 실행 + 사람 비동기 감수

오른쪽 아래로 갈수록 시간을 더 옮기는데, 권한과 감사 위험 이 더 커진다. 그 둘의 트레이드오프가 다음 10년의 모든 의미 있는 결정 이 될 거다.

CollabOps 가 만드는 실행 레이어는 오른쪽 아래로 갈 수 있게 해 주는 인프라 다. 권한 모델과 감사 트레이스가 그래프 위에 정의돼 있어서, 그 경계를 천천히 옮기는 게 안전한 결정이 된다. → Execution Layer 란 무엇인가

짧은 결말

CIO 에게 내가 다시 한 답은 이거였다.

"당신 사람들은 더 좋은 일을 할 시간을 갖게 됩니다. 단, 그 좋은 일이 무엇인지는 당신이 정의해야 합니다. 우리는 그것을 정의하지 않습니다."

그 미팅 이후로 그 회사는 우리에게 1차 트리아지 자동화부터 시작하는 PoC 를 발주했다. 6개월 뒤에 권한 경계가 어디까지 옮겨졌는지 같이 보기로 했다.

이 글을 1년 뒤에 다시 보면, 위의 다이어그램에서 우리가 얼마나 오른쪽으로 옮겼는지 가 보일 거다.

이 글이 누구에게 가치인가

조직에 AI 도입 결정을 해야 하는 임원 — 특히 보안·감사가 무거운 산업에서. 그 결정의 프레임 자체를 다시 잡고 싶으면 이 글이 출발점이 된다.

이미 에이전트를 PoC 하고 있는 엔지니어링 리드에게도 가치 있다. 위의 다이어그램을 출력해서 책상에 붙여두면, 이번 분기에 어디까지 옮길 것인가 의 결정을 더 단정적으로 할 수 있다.

스타트업 단계의 엔지니어에게는 이 글이 추상적으로 읽힐 수 있다. 그렇다면 DevOps의 진화 — 2009-2026 부터 읽으면 더 자연스럽다.