전사 배포 시스템을 만들기 전 알았으면 좋았을 것들 (SRE 밋업 3회)

주요 구간

• 01:25 Kontrol 특징과 배포 현황
• 03:58 개발팀과 SRE 팀의 이해관계
• 07:36 컨셉과 팀 문화가 부딪힌 두 사례
• 11:40 포장도로와 비포장도로, 핵심 지표
• 17:20 ArgoCD의 한계와 이벤트 기반 컨텍스트
• 21:25 Grafana Annotation으로 배포 시점 표시

배포 규칙과 팀별 작업 방식의 충돌

Kontrol은 개발자가 직접 배포·재시작·스케일을 처리하는 셀프 서비스 배포 플랫폼입니다. Dockerfile과 Jib 빌드를 지원하며 진입 문턱을 낮추는 것이 목표입니다. 이용 프로젝트는 2022년 6월 45개에서 2023년 6월 129개로 늘었습니다. 같은 기간 ArgoCD는 122개에서 134개로 약 10% 증가했습니다.

개발팀은 빠른 배포와 롤백, 신속한 문제 파악을 원했습니다. SRE 팀은 파편화된 구성을 일괄 관리하며 안정적으로 운영하려 했습니다. Kontrol 사용이 늘면서 이 기대 차이가 드러났습니다.

안정성을 위한 공통 규칙은 일부 팀에 불편을 줬습니다. 이미지를 한 번만 빌드해 모든 환경에서 공유하도록 했지만, 프런트엔드 팀은 환경별 빌드가 필요했습니다. 모든 실서비스 배포가 알파 환경을 거쳐야 한다는 규칙은 광고 플랫폼 팀과 부딪혔습니다. 이 팀은 장애가 곧 매출 손실이라 핫픽스를 바로 내보내야 했습니다. 발표자는 한 팀의 불신이 퍼지면 아무도 이 시스템을 원하지 않게 될 수 있다고 봅니다.

강제 대신 선택권, 그리고 운영 컨텍스트

당근은 Kontrol 사용을 강제하지 않고 포장도로와 비포장도로를 선택할 수 있게 했습니다. Kontrol이 권장하는 경로인 포장도로는 인지 부하가 낮고 대체로 목적지에 쉽게 닿으며, 비포장도로의 속도는 개발팀 역량에 달려 있습니다. 발표자는 강제 전환에 설득 비용과 반발 위험이 따른다고 설명합니다. 선택권을 두면 SRE 팀도 개발팀이 실제 이득을 얻도록 시스템을 만들 동기를 갖게 됩니다.

운영 중 변경 내용을 찾는 수고도 줄였습니다. ArgoCD에서는 설정 변경을 Git에서, 시크릿 변경을 AWS 파라미터 스토어에서 따로 찾아야 했습니다. 장애 대응 중 누가 무엇을 바꿨는지도 공유되지 않았습니다. Kontrol은 배포·재시작·스케일 같은 사용자 이벤트를 Redis Pub/Sub으로 보내고, 구독한 워커가 GitLab 커밋 코멘트, Slack 배포 이력 채널, Grafana Annotation에 기록합니다. 배포 목록에서는 설정 변경 이력을, 워크로드 화면의 액티비티 뷰에서는 재시작·스케일을 실행한 사람과 시점을 확인할 수 있습니다.

개발팀이 실제로 이득을 보는지 확인하려고 기간별 배포 수, 배포별 소요 시간, 배포 실패율을 쌓습니다. 실패 원인을 추적해 자주 실패하는 지점부터 고칩니다. 사내에서 직접 만든 시스템이라 지표 수집도 밑바닥부터 시작해야 했습니다. 발표자는 수집을 늦게 시작한 점을 아쉬워하며 되도록 일찍 지표를 쌓으라고 권합니다.

결과

• 2023년 1분기 배포는 약 5700건, 하루 평균 76건
• Grafana Annotation으로 서비스 대시보드의 메트릭 변화가 어떤 배포나 재시작 때문인지 바로 확인
• 설정 변경을 여러 화면에서 따로 찾던 불편이 줄었다고 설명

적용 전에 살필 점

발표에는 개선 전후를 정량으로 비교할 수치가 없습니다. 규칙과 팀 문화의 충돌로 일부 팀의 Kontrol 사용률이 낮았다고 밝힙니다. SRE 팀은 이 문제를 풀기 위해 팀 내부의 입장을 맞추는 데도 신경을 쓴다고 합니다.