비개발자를 위한 IT 상식 #4 버그, 핫픽스, 롤백 — 개발자가 장애에 대응하는 법
지난 글에서 개발자가 만든 코드를 서버에 올려 사용자에게 공개하는 일을 배포라고 부른다고 했습니다. 그리고 마지막에 질문 하나를 남겼습니다. 배포한 코드에 문제가 있으면 어떻게 될까요. 잘못된 변경이 운영 환경에 나가는 순간, 사용자가 곧바로 영향을 받습니다. 결제가 막히거나, 화면이 깨지거나, 앱이 아예 열리지 않을 수도 있습니다.
이런 상황을 흔히 장애라고 부릅니다. 그리고 장애가 터지면 개발팀의 대화창에 익숙한 단어들이 등장합니다. “장애 났어요”, “핫픽스 나갑니다”, “일단 롤백했어요”. 이번 글에서는 버그, 핫픽스, 롤백이라는 세 단어를 통해 개발팀이 문제에 어떻게 대응하는지 살펴보겠습니다.
이번 시리즈는 비개발자를 위한 IT 상식 5편으로 구성됩니다.
- #1 웹사이트는 무엇으로 이루어지는가 — 프론트엔드,백엔드,데이터베이스
- #2 API란 무엇인가 — 서비스끼리 대화하는 약속
- #3 서버, 클라우드, 그리고 배포
- #4 버그, 핫픽스, 롤백 — 개발자가 장애에 대응하는 법 ← 이번 글
- #5 Git과 버전 관리 — 여러 명이 한 코드를 고치는 법
버그는 의도와 다르게 동작하는 것입니다 #
버그는 프로그램이 만든 사람의 의도와 다르게 동작하는 것을 말합니다. 1,000원을 결제했는데 1,100원이 빠져나가거나, 분명히 눌렀는데 버튼이 반응하지 않거나, 목록이 엉뚱한 순서로 나오는 것이 모두 버그입니다. 코드 한 줄의 작은 실수가 사용자 화면에서는 큰 문제로 보이기도 합니다.
버그라는 단어가 어쩌다 벌레라는 뜻을 갖게 되었는지는 그 자체로 재미있는 이야기입니다. 궁금하다면 버그라는 단어는 어디서 왔을까 글을 따로 읽어 보시길 권합니다.
중요한 점은 버그라고 다 같은 버그가 아니라는 것입니다. 글자 색이 조금 어긋난 정도의 사소한 버그가 있고, 결제가 아예 안 되거나 개인정보가 잘못 노출되는 심각한 버그가 있습니다. 그래서 개발팀은 버그를 발견하면 먼저 심각도를 따집니다. 당장 서비스를 멈출 만큼 급한지, 다음 정기 배포 때 천천히 고쳐도 되는지에 따라 대응이 완전히 달라집니다.
핫픽스는 급한 불을 끄는 긴급 수정입니다 #
핫픽스는 말 그대로 뜨거운 상황을 식히는 긴급 수정입니다. 보통 새 기능은 충분히 시험하고 검토한 뒤 정해진 일정에 배포합니다. 하지만 결제가 막히는 것처럼 지금 당장 사용자가 피해를 보는 문제라면, 그 일정을 기다릴 수 없습니다.
이때 개발팀은 문제가 된 부분만 좁게 고쳐서 평소보다 빠르게 배포합니다. 이렇게 정규 일정을 건너뛰고 긴급히 내보내는 수정이 핫픽스입니다. “핫픽스 나갑니다"라는 말은 지금 급한 문제를 막기 위해 긴급 수정을 배포하고 있다는 뜻입니다.
다만 핫픽스도 공짜는 아닙니다. 급하게 고치다 보면 충분히 시험하지 못한 채 나갈 수 있고, 그러다 또 다른 문제를 일으키기도 합니다. 그래서 핫픽스는 빠르되 최대한 좁은 범위로, 꼭 필요한 부분만 건드리는 것이 원칙입니다.
롤백은 이전의 정상 버전으로 되돌리는 것입니다 #
핫픽스가 앞으로 나아가 고치는 방법이라면, 롤백은 뒤로 되돌리는 방법입니다. 방금 배포한 새 버전이 문제를 일으켰다면, 원인을 천천히 찾기 전에 일단 바로 직전의 멀쩡했던 버전으로 되돌릴 수 있습니다. 이것이 롤백입니다.
롤백의 장점은 속도입니다. 새 버전에서 무엇이 잘못됐는지 분석하려면 시간이 걸리지만, 문제가 생기기 전 버전으로 되돌리는 것은 훨씬 빠릅니다. 사용자가 겪는 피해를 먼저 멈춰 놓고, 원인은 그다음에 차분히 찾는 것입니다. “일단 롤백했어요"라는 말은 새 배포를 거두고 직전의 안정된 상태로 서비스를 돌려놓았다는 뜻입니다.
여기서 한 가지 궁금증이 생깁니다. 이전 버전으로 되돌린다는데, 그 이전 버전은 대체 어디에 보관돼 있을까요. 이 이야기는 다음 글에서 다룰 Git과 버전 관리로 이어집니다.
장애 대응은 대체로 이런 순서로 흘러갑니다 #
장애가 터졌을 때 개발팀은 보통 다음 순서로 움직입니다.
- 감지: 모니터링 도구가 이상을 알리거나, 사용자 제보로 문제를 알아챕니다.
- 응급 조치: 원인을 깊이 파기 전에, 롤백이나 핫픽스로 사용자 피해부터 멈춥니다.
- 원인 분석: 급한 불을 끈 뒤에 무엇이 왜 잘못됐는지 차분히 찾습니다.
- 재발 방지: 같은 문제가 다시 생기지 않도록 점검 절차나 시험을 보강합니다.
마지막 단계에서 개발팀은 종종 회고를 남깁니다. 누구의 잘못인지 따지기보다, 무엇이 문제를 가능하게 했고 어떻게 막을지를 정리하는 과정입니다. 좋은 팀일수록 장애를 비난이 아니라 배움의 기회로 다룹니다.
왜 비개발자가 알면 일이 편해지는가 #
장애 대응의 흐름을 알면, 문제가 터진 순간에 더 차분하고 정확하게 움직일 수 있습니다.
- 상황을 정확히 읽을 수 있습니다. “지금 롤백했고 원인 보는 중입니다"라는 말을 들으면, 사용자 피해는 일단 멈췄고 분석이 진행 중이라는 뜻으로 이해할 수 있습니다.
- 버그를 잘 신고할 수 있습니다. 무엇이 어떻게 잘못됐는지와 함께, 결제처럼 급한 문제인지 표시 오류처럼 사소한 문제인지 심각도를 같이 알리면 대응 우선순위가 빨라집니다.
- “왜 당장 못 고쳐요?“의 답을 이해할 수 있습니다. 핫픽스도 잘못 나가면 더 큰 문제를 부르기 때문에, 급한 와중에도 최소한의 확인은 필요합니다. 무조건 빨리가 아니라 안전하게 빨리가 목표입니다.
정리 #
이번 글에서는 장애 상황의 세 단어를 살펴봤습니다.
- 버그는 프로그램이 의도와 다르게 동작하는 것이고, 심각도에 따라 대응이 달라집니다.
- 핫픽스는 급한 문제를 막기 위해 정규 일정을 건너뛰고 좁게 고쳐 내보내는 긴급 수정입니다.
- 롤백은 새 배포가 문제를 일으켰을 때 직전의 정상 버전으로 빠르게 되돌리는 응급 조치입니다.
롤백이 가능하다는 것은 곧 이전 버전들이 어딘가에 차곡차곡 보관돼 있다는 뜻입니다. 여러 명의 개발자가 같은 코드를 고치면서도 버전을 잃지 않고 관리하는 방법은 다음 글의 마지막 주제인 Git과 버전 관리에서 살펴보겠습니다.