데브옵스
DevOps
데브옵스란?
- 개발과 운영의 벽을 허묾
- 빠르고 안정적인 배포 문화
- CI/CD가 핵심 실천
데브옵스가 실제로 바꾸는 것은 도구함이 아니라 장애가 났을 때 누가 깨어나느냐입니다. 예전에는 개발이 코드를 넘기는 순간 손을 떼고, 새벽 3시 알람은 운영이 받았습니다. 데브옵스 조직에서는 기능을 만든 팀이 그 기능의 배포와 모니터링, 장애 대응까지 끝까지 끌고 갑니다. 그래서 개발자가 처음부터 로그를 남기고, 롤백 경로를 만들고, 트래픽이 몰릴 때를 계산합니다. 만든 사람이 새벽에 깨는 구조가 결국 코드의 품질을 바꿉니다.
잘 돌아가는지는 느낌이 아니라 네 개의 숫자로 봅니다. 배포 빈도, 커밋부터 운영 반영까지의 리드타임, 배포가 장애로 이어진 비율, 장애 복구 시간입니다. 이 네 숫자를 한 화면에 띄우는 순간 팀 간 책임 공방이 줄어듭니다. 실천 항목도 구분해서 봐야 합니다. CI는 하루에도 여러 번 코드를 합쳐 자동으로 빌드·테스트하는 것이고, CD는 그 결과물을 사람 손을 거의 타지 않고 운영에 올리는 것입니다. 여기에 서버와 네트워크 설정을 문서가 아닌 코드로 관리하는 인프라 코드화(IaC)가 붙어야 '제 PC에서는 됐는데요'가 사라집니다.
비슷한 말들과의 경계도 정리해 두면 좋습니다. 애자일이 기획·개발 주기를 짧게 만드는 것이라면, 데브옵스는 그 결과물을 고객에게 내보내는 구간까지 짧게 만드는 쪽입니다. SRE는 데브옵스의 목표를 에러 예산이라는 숫자 계약으로 운영하는 실행 방식에 가깝고, 최근에는 파이프라인과 모니터링을 사내 공통 기반으로 묶어 각 팀이 알아서 쓰게 하는 플랫폼 엔지니어링으로 넘어가는 회사가 늘고 있습니다. 개발 인원 20명 이하라면 여기까지 가지 않아도 CI와 자동 테스트만으로 체감 효과가 납니다.
현장에서 가장 흔한 실패는 '데브옵스팀'을 새로 하나 만드는 것입니다. 벽을 허물자고 시작했는데 개발·운영·데브옵스 세 개의 사일로가 생기고, 배포 요청 티켓 단계만 하나 늘어납니다. 자동 테스트 없이 배포 자동화부터 붙이는 것도 위험합니다. 망가진 코드가 더 빨리, 더 자주 고객에게 도달할 뿐입니다. 도구를 깔고 석 달이 지났는데 여전히 배포 승인이 부장 결재 메일로 돌아간다면, 그건 데브옵스가 아니라 비싼 빌드 서버를 한 대 산 것입니다.
2009년경 개발·운영 협업 운동에서 시작됐으며, 애자일·클라우드의 확산과 함께 소프트웨어 개발의 표준 문화가 됐습니다.
가상의 사례로 살펴보겠습니다. 국내 중견 패션 이커머스 A사의 이야기입니다. 임직원 320명, 연 매출 1,400억 원 규모인데 배포는 한 달에 한 번, 토요일 새벽 2시에 서비스를 4시간 내리고 진행했습니다. 지난해 가을 프로모션 직전 배포에서 결제 오류가 터져 6시간 만에 롤백했고, 그 주에만 매출 2억 원이 날아갔습니다.
- CTO가 개발 6개 팀과 운영팀을 한자리에 모아 지난 1년치 배포 기록을 펼쳤습니다. 배포 12회 중 4회가 롤백, 평균 복구 시간은 5시간 20분이었습니다. '실력 문제가 아니라 구조 문제입니다'라는 말로 회의를 열었습니다.
- 결제팀 리더가 손이 가장 많이 가는 주문·결제 API부터 자동 테스트를 깔았습니다. 6주 동안 핵심 시나리오 180건을 스크립트로 옮겨, 커밋할 때마다 12분 안에 통과 여부가 뜨도록 했습니다.
- 인프라 담당 차장은 서버 설정을 워드 문서에서 코드로 옮겼습니다. 신규 서버 한 대 세우는 데 이틀 걸리던 일이 20분으로 줄었고, 스테이징과 운영 환경이 달라서 생기던 장애가 그 분기에 0건이 됐습니다.
- 배포 권한을 각 팀에 넘기되 '만든 팀이 배포 후 48시간 당직'이라는 규칙을 붙였습니다. 처음엔 '왜 우리가요'라는 반발이 나왔지만, 알림이 자기 휴대폰으로 온다는 사실이 코드 리뷰의 깐깐함을 바꿨습니다.
- 6개월 뒤 배포는 월 1회에서 주 11회로 늘었고, 평균 복구 시간은 5시간 20분에서 34분으로 줄었습니다. 새벽 배포 작업은 없어졌고 운영팀 야간 호출은 월 9건에서 2건으로 떨어졌습니다.