많은 공공기관과 공기업이 DevOps를 도입합니다. CI/CD 파이프라인을 구축하고, 컨테이너를 도입하고, 자동화 도구를 배치합니다. 그러나 기대했던 효과—빠른 배포, 안정적 운영, 빠른 장애 복구—는 좀처럼 나타나지 않습니다.
왜 그럴까요?
도구 도입과 운영 변화는 다르다
DevOps는 도구가 아니라 운영 방식입니다. Jenkins를 설치했다고 DevOps가 되지 않듯이, 파이프라인을 구축했다고 운영이 바뀌지 않습니다.
공공 시스템에서 흔히 나타나는 패턴은 이렇습니다.
- 배포 자동화 도구는 있지만, 배포 권한은 여전히 특정 담당자 한 명에게 집중
- 코드 변경은 Git으로 관리하지만, 실제 운영 변경(설정, 인프라, 데이터)은 구두 보고로 처리
- 모니터링 대시보드는 있지만, 경보를 받았을 때 누가 무엇을 해야 하는지 정의되지 않음
이 상태에서 DevOps 도구는 장식에 가깝습니다. 프로세스와 책임 구조가 바뀌지 않으면, 도구는 새로운 복잡성을 더할 뿐입니다.
공공 조직의 구조적 충돌
민간 기업과 달리 공공 조직에는 DevOps 문화와 정면으로 충돌하는 요인이 있습니다.
책임의 집중화. 공공기관에서 시스템 변경은 보통 결재 체계를 거칩니다. 빠른 반복과 지속적 배포는 이 구조와 잘 맞지 않습니다. 결재를 빠르게 받을수록 위험하다는 인식이 있고, 느린 배포가 "안전하다"고 여겨집니다.
감사와 추적의 부재. 역설적으로, 감사를 중시하는 공공기관에서 운영 변경 이력이 체계적으로 기록되지 않는 경우가 많습니다. 담당자 개인의 메모나 엑셀 파일에 의존합니다. 누가 언제 무엇을 바꿨는지 알 수 없습니다.
담당자 의존. 특정 시스템은 한 명의 담당자만 알고 있습니다. 그가 자리를 비우면 운영이 멈춥니다. DevOps가 지향하는 공유된 소유권(shared ownership)과 정반대입니다.
실패의 공통 패턴
현장에서 반복적으로 관찰되는 실패 패턴입니다.
"우리는 이미 DevOps를 하고 있다." 도구 도입을 DevOps 완료로 인식합니다. 파이프라인이 있으면 됐다는 식입니다. 정작 배포 빈도, 장애 복구 시간, 변경 실패율 같은 지표는 측정하지 않습니다.
자동화된 수작업. 수작업으로 하던 작업을 스크립트로 감쌌을 뿐, 프로세스는 그대로입니다. 배포 스크립트를 담당자만 실행할 수 있고, 실행 여부는 Slack 메시지로 공유됩니다.
도구 간 단절. CI/CD, 모니터링, 티켓 시스템이 각각 따로 돌아갑니다. 배포와 장애 사이의 연결 고리가 없습니다. 어떤 배포가 어떤 장애를 일으켰는지 추적할 수 없습니다.
구조를 바꿔야 한다
DevOps를 실질적으로 작동시키려면 도구 이전에 두 가지를 정해야 합니다.
운영 책임의 명시화. 누가 어떤 시스템의 무엇을 책임지는지 명확하게 정의해야 합니다. 개인 의존이 아니라 역할 정의입니다. 담당자가 바뀌어도 운영이 돌아가는 구조입니다.
변경의 가시화. 모든 운영 변경—코드, 설정, 인프라, 데이터—이 기록되어야 합니다. 누가 언제 무엇을 바꿨는지 검색할 수 있어야 합니다. 이것이 없으면 장애 원인 분석도, 감사도 불가능합니다.
DevOps 도입에 실패했다면 도구를 탓하기 전에 먼저 물어야 합니다. 우리 조직의 운영 책임 구조가 명확한가? 변경이 추적되고 있는가?
파인만소프트는 이 질문에서 시작합니다.