배경
저는 현업에서 2년 이상 GitOps라는 관행과 함께 개발 & 운영을 진행하고 있는 개발자입니다.
누군가에겐 이 방법론이 처음일수도, 어색할 수도, 익숙할 수도 있지만 제가 경험하고 공부했던 것들을 토대로
앞으로 여러 문서를 정리하기 전 방법론이 먼저 정리가 되어야 할 것 같아 기술하게 되었습니다.
개요
GitOps는 2017년에 Flux라는 GitOps 도구의 개발사인 Weaveworks가 도입한 개념입니다.
GitOps의 핵심은 상태를 선언적으로 최종 변경은 PR로 라고도 할 수 있습니다.
버전 관리·협업·규정 준수·CI/CD 같은 개발 관행을 운영 자동화에 적용하려는 체계 혹은 노력들이라고도 정의되곤 했습니다.
GitOps는 관점에 따라 다양한 정의가 존재하여 배우거나 적용하려는 사람들 사이엔 각자 생각하는 개념이 다를 수 있습니다.
GitOps라는 관행을 정확히 알기 위해 책과 여러 블로그, 이론 등 제가 공부했던 것들 사이의 핵심을 추려
제가 생각하는 GitOps의 정의·원칙·이점을 정리해 보도록 하겠습니다.
그전에! 여기서 잠깐 GitOps 없이 배포를 진행했을 때 실무에서 겪었던 장애들을 공유드리겠습니다.
1. 수동 배포로 인한 장애
PHP–Apache 운영, IDE로 SSH 접속해 FTP로 서버 파일 직접 수정하여 배포를 진행했으며
커머스 환경에서 건별로 들어오는 유지보수를 처리하는 상황이었습니다.
어느 날 의도와 다르게 동작하는 코드가 반영되어 장애가 발생했습니다. 직전 상태의 백업 파일이 없었고,
정확히 어떤 상태로 되돌려야 하는지도 알 수 없어 1시간 30분 이상 복구에 매달렸습니다.
여러 시도를 거쳐 서비스는 복구했지만, 과정 자체가 매우 비효율적이었습니다.
- 복구 과정에서 모든 개발자가 이전 버전으로 돌리기 위해 로컬 서버의 코드를 확인하여 누가 갖고 있는지부터
그 코드가 실제 서버에서 운영됐던 코드였는지 확인하는 매우 어지러운 상황을 거쳐 해결했다는
웃지 못할 일화로 기억됩니다..
수동 배포는 매우 불편하고 시스템이나 체계가 잘 갖춰져 있더라도 불안한 수동배포는 운영상황에 적용되기까지
사람이 프로세스에 관여해야 하며 그 과정에서의 사소한 실수는 비즈니스의 신뢰도를 떨어뜨릴 수 있는
심각한 장애로 이어질 수도 있게 됩니다.
2. 복구의 어려움
Docker기반의 배포 환경을 갖추고 있었으며 한비로라는 IDC에서 PC를 위탁 운영하는 On-Prem 환경이었습니다.
Backend는 Spring, Front는 React로 모두 Docker를 기반으로 구동하고 로그인 서비스로 기능했습니다.
- IDC 업체의 전선 관리 문제로 PC가 다운되었습니다. 이 PC에는 로그인 서버와 CI/CD를 담당하는
Jenkins가 설치되어 있어 즉시 복구가 필요했고 다른 PC에서 서비스를 구동해 라우팅을 임시 전환하려고 했었습니다. - 그런데 실제 운영에 반영된 정확한 서비스 버전을 알 수 없었습니다. Jenkins가 멈춰 파이프라인도 확인하지 못했고,
어떤 버전을 적용해야 할지 판단하지 못했습니다. 그 결과 로그인 서비스가 1시간 이상 중단되는 심각한 상황으로 이어졌습니다. - PC 복구가 지연되어 급히 저장소의 코드를 이미지로 다시 빌드하고, 다른 PC에서 서비스를 띄워 임시 복구를 진행했습니다.
서버나 기능 시스템에서 발생하는 장애는 아무리 막으려고 해도 막을 수 없으며 인지하지 못하는 곳에서도 장애가
발생하곤 합니다. 이 과정에서 중요한건 장애를 인지하는 능력, 장애를 복구할 수 있는 능력인데 장애 복구 능력은
어떤 상태로 배포되어있는 지를 알 수 있는것으로부터 올 수 있음을 깨달았으며 기술의 성숙도완 장애 복구 과정에서
무력감을 얻지 않도록 체계를 갖추는 것이 무엇보다도 중요하다고 할 수 있겠습니다...
3. 환경별 배포의 차이
커머스 회사에서 서비스별로 배포를 하는 PC가 총 20개 정도 IDC에 의해 운영되고 있었으며
각 웹서버(apache, nginx)등의 설정은 각 노드에 존재하고 노드별로, 환경을 의미하는 폴더별로
설정이 너무나 상이했습니다.
- PHP–Apache 환경에서는 PHP 코드를 런타임에 해석·실행해 응답을 반환합니다.
문제는 서비스마다, 환경마다 경로와 구조가 제각각이라 오래된 서비스일수록 “지금 어떤 코드가 어떤 상태로 올라가 있는지”를
확인하기가 매우 어려웠고 문서는 있었지만 최신화가 되어 있지 않아 직접 파악해야 할 경우가 잦았습니다. - 어떤 서버는 PHP 5, 어떤 서버는 PHP 7을 쓰고 있어 Apache의 가상호스트·모듈 설정이 달라지고,
인증서나 서버 설정을 만질 때마다 그 차이를 일일이 고려해야 했고 nginx 설정을 수정하는 것 또한 비슷하여
수정, 유지보수 , 반영의 경우 두세 번씩 점검하고서야 마무리할 수 있었습니다. - 서버의 기능을 개발하는 코드는 git에 있으나 서버 설정 인프라 버전은 git에 있지 않아 추적하기가 어려웠고
화면의 버전이 바뀌어 사용자를 임시로 다른 화면으로 라우팅 하게 하는 경우 빠른 적용을 위해 웹 서버의
설정만 고치려고 해도 개발에서 적용했던 것과 운영에서 적용했던 불일치로 작업의 어려움도 겪곤 했었습니다.
서버에서 어떤 모듈을 사용하고 있는지도 , 어떤 버전을 사용하고 있는지도 확인하기가 정말 어려웠으며
서비스가 존속한지 오래될수록 각 서비스를 구동하는 웹 서버의 버전의 차이도 너무 커 단시간에 환경의 불일치를
없앨 수 없을 때 적어도 유지보수를 위해 혹은 장애를 극복하기 위해 단서를 제공해 줄 수 있는 상태를 확인할 수 없다는
것이 얼마나 작업의 비효율성을 불러올 수 있는지 많이 경험했던 것 같습니다.
4. 배포 진행자를 알 수 없음
커머스 특성상 건별로 진행하는 유지보수 업무와 기능단위 개발이 많고 배포일정이 정해지기보단
이슈를 대응하기 위한 빠른 배포가 주를 이룰 때가 많았습니다.
- 개발 서버에서 테스트를 진행했던 기능을 기획팀장님이 배포를 진행해도 된다고 승인하기 전
해당 기능을 개발했던 외주 개발자가 그냥 배포를 진행해 버려 이슈가 발생했습니다.- 기능을 적용할 시점을 아직 확정 짓지 않았던 시점에서 기능이 먼저 올라가 버린 것 과
테스트 상황에서 발견하지 못한 장애가 발생했던 이슈였습니다.
- 기능을 적용할 시점을 아직 확정 짓지 않았던 시점에서 기능이 먼저 올라가 버린 것 과
- 사용자의 피드백으로 그제야 기능이 적용되고 장애가 생긴 것을 인지하여 원복 했으나
배포가 왜 진행됐는지를 파악하기 위해 코드 커밋 기록을 살펴보고 개발자끼리 소통하는 등
꽤 긴 시간을 거친 뒤에야 문제를 파악할 수 있게 됐었습니다.
공부하고 배웠던 것과 달리 실무에선 당연히 그렇게 진행하지 않겠지? 라는 모습이 생각보다 많이 발견되곤 합니다.
배포 진행자를 알 수 없는 것도 역시 체계를 갖추는 것으로 해결할 수도 있지만 원천적으로 해결할 수 없다고 생각하며
혹여 진행자가 잠시 부재한 경우엔 누가 진행했는지 상황을 공유하고 전파하는 것을 너무나 힘들게 합니다.
로그인 같은 중요한 서비스는 다운될 수 있으니 haproxy를 통해 여러 개의 노드로 서비스를 구동해 분산하여
중요한 서비스가 외부의 요인에 의해 다운되지 않도록 노력했었습니다.
jenkins, nexus 등 On-Prem 기반의 서비스들이 한 번에 다운되어 시스템의 장애가 발생했을 때 분석과 복구를
더디게 만드는 것을 방지하기 위해 여러 PC로 서비스를 옮겨 장애 포인트를 분산시키려 노력했습니다.
이 외에도 노력했던 것들은 다양하지만 체계가 잘 잡혀있지 않을수록 시스템이 잘 갖춰져 있지 않을수록
사소한 실수는 운영상황에서의 중대한 위험으로 이어지게 됩니다.
제가 겪은 운영상황의 장애는 이 외에도 숱하게 많지만 GitOps라는 관행이 이러한 장애를 사전에 방지하거나
이 관행 하나만으로 모든 이슈를 해결해 줄 수 있는 마법 같은 방법론이라고 소개드릴 것은 아닙니다.
하지만 그럼에도 제가 GitOps를 중요하게 생각하며 공유하는 건 인프라의 상태를
불변하는 저장소에서 확인할 수 있으며 수동 배포가 야기할 수 있는 많은 부분을 자동화해 주는 등
운영상황에서의 장애를 최소화하는 것과 시스템의 상태를 사람이 쉽게 인지하도록 도와주기 때문입니다.
그래서 GitOps란 무엇인가?
이 다음부터의 내용은 하단의 링크로 이어집니다.
2025.08.15 - [분류 전체보기] - GitOps란? 2부: 정의와 원칙
참고한 링크 및 문서
'Devops' 카테고리의 다른 글
| Argocd - Application CR 이해하기 (0) | 2026.01.03 |
|---|---|
| Iac- Terraform이란? (0) | 2025.12.13 |
| Argocd - GitOps 활용하기(App of Apps 패턴) (0) | 2025.11.05 |
| GitOps란? 2부: 정의와 원칙 (5) | 2025.08.15 |
| Docker 컨테이너 메모리 관리 및 OOM 대응 (0) | 2023.06.25 |
