운영 환경에서 장애가 발생하면 개발 조직은 하던 일을 멈추고 모두가 달려든다. 신입 시절부터 몸에 익히는 이 반사 신경은 소프트웨어 조직의 기본 규율이다. 그런데 정작 개발자 자신이 매일 의존하는 빌드 시스템, CI 파이프라인, QA 환경, 개발 도구가 고장 났을 때는 같은 수준의 긴급함이 좀처럼 발동되지 않는다. Jerry Orr는 최근 글에서 이 비대칭을 정면으로 지적한다. 개발 팀에게 개발 파이프라인은 그 자체로 하나의 운영 시스템이며, 그것이 멈추면 고객 서비스 장애와 똑같이 '프로덕션 장애'로 취급해야 한다는 것이다.
논지의 출발점은 단순하다. 개발자의 일은 회사를 위해 가치를 전달하는 것이고, 그 가치는 새 기능이든 긴급 버그 수정이든 결국 파이프라인을 통과해야 사용자에게 도달한다. 그런데 코드가 컴파일되지 않으면 개발자는 아무것도 만들어낼 수 없다. 팀 관점에서 이것은 명백한 생산 중단이다. QA 서버가 내려가면 테스터가 일을 할 수 없고, 팀은 '동작하는' 소프트웨어를 내놓지 못한다. QA 팀에게 이것 역시 운영 장애다. 필자는 이런 상황을 모두 최우선 순위로 다뤄야 한다고 말한다.
왜 내부 장애는 방치되는가
흥미로운 대목은 제조업과의 대비다. 공장에는 조립 라인의 다운타임을 예방하고 최소화하기 위한 방대한 프로세스와 절차가 존재하고, IT 서비스 운영에도 유사한 장애 대응 체계가 갖춰져 있다. 그러나 필자의 관찰에 따르면 이런 절차 대부분은 '고객에게 제공되는 서비스'의 장애에 초점이 맞춰져 있을 뿐, 정작 그 서비스를 만들고 지탱하는 사람들이 겪는 장애에는 관심이 적다. 고객이 보는 화면이 멈추면 경보가 울리지만, 개발자의 빌드가 30분째 깨져 있는 것은 '원래 그런 것'으로 넘어가는 식이다.
이 온도차가 생기는 이유는 짐작하기 어렵지 않다. 외부 장애는 매출 손실, 고객 이탈, 평판 훼손처럼 눈에 보이는 숫자로 환산되지만, 내부 파이프라인의 마비는 손실이 조직 내부에 숨는다. 열 명의 개발자가 반나절 동안 CI 큐가 풀리기를 기다리는 비용은 어느 대시보드에도 빨간불로 뜨지 않는다. 그러나 실제로는 인건비와 지연된 릴리스라는 형태로 고스란히 지출되고 있으며, 단지 청구서가 눈에 띄지 않을 뿐이다.
실무에 적용한다면
한국의 개발 조직 관점에서 이 주장은 몇 가지 구체적인 함의를 갖는다. 우선 내부 도구의 장애에도 대응 우선순위와 담당 체계를 명시적으로 부여할 필요가 있다. 많은 팀이 서비스 장애에는 온콜 로테이션과 인시던트 등급을 두면서도, 빌드 서버나 사내 QA 환경이 죽으면 '누군가 시간 날 때 보는' 일로 미뤄 둔다. 파이프라인 구성 요소에도 소유자를 지정하고, 다운타임을 장애로 기록·집계하기 시작하면 그동안 보이지 않던 비용이 비로소 관리 대상이 된다.
필자는 '고객이 무언가를 원한다'는 지점에서 '그 무언가가 고객에게 전달된다'는 지점까지, 그 사이를 잇는 모든 구성 요소를 하나의 흐름으로 놓고 바라보라고 권한다. 소스 관리, 빌드, 테스트 자동화, 스테이징 환경, 배포 도구가 모두 이 흐름의 일부다. 어느 한 마디라도 끊기면 완제품이 나오지 않는다는 점에서, 이들은 부차적 편의 도구가 아니라 생산 설비 그 자체다. 이 관점을 받아들이면 사내 인프라 투자에 대한 논의의 언어도 달라진다. '개발 편의 개선'이 아니라 '생산 능력 유지'의 문제가 되기 때문이다.
다만 이 글은 문제의식을 환기하는 짧은 에세이라는 점을 감안해 읽는 편이 좋다. 파이프라인 장애를 어떤 등급으로 나눌지, 어느 수준의 다운타임부터 '전원 투입'을 발동할지, 예방 투자와 즉시 대응 사이의 균형을 어떻게 잡을지 같은 실무 설계는 온전히 각 조직의 몫으로 남는다. 모든 내부 도구 결함을 최고 등급 장애로 격상하면 오히려 경보 피로를 부를 수 있다. 그럼에도 '개발 파이프라인은 우리에게 운영 시스템'이라는 한 문장은, 내부 도구의 고장을 관성적으로 참아 온 조직에 우선순위를 다시 세울 유용한 렌즈를 제공한다.