Continuous Delivery, Staging, … and Reality

근 1년여를 유행하는 buzz-word 중에 “Continuous Delivery”라는 게 있다, 혹은 상당히 유사한 의미로 Continuous Deploy도 있다.[1]

여하튼 요는 적정 수준의 자동화된 테스트(unit-test, acceptance-test, …)가 있을 때,

코드 베이스의 변경 사항이 테스트와 Q/A를 통과하면 실제 프로덕션 서버에 릴리즈 한다

라는 것. 즉, 변경 사항을 incremental 하게 반영하되, 내부적으로는 적절한 staging을 거쳐서, 최대한 문제없이 내보낸다는 것. 다만 실제 서비스에서 문제가 일어나면, 바로 이전 릴리즈로 되돌리고, 근본 원인을 찾아서 다시 릴리즈 하라는 것. 자세한 사항은 오라일리 레이더에 있는 이 글(Continuous Deployment In 5 Easy Steps) 참조.

이런 조금씩 자주 릴리즈하는 건 해당 서비스와 연동하는 다른 시스템에 적당히 도움이 된다. 크게 바꿀 것도 없고, 변화에 대응하기도 쉽고, 문제 찾기도 쉬우니 말이다…

나는 이걸 개개인의 개발자가 수행하는 코드 작성 -> 빌드 -> 테스트하며 피드백 받는 사이클을 좀 더 넓은 수준(=개별 팀이나 서비스 단위)으로 확대한 거라고 생각한다. 그러니까 한 명의 개발자가 할 수 없는 일, 더 큰 단위의 소프트웨어 개발을 하기 위해선 당연히 하게 되는 일이란 것.

하지만 전혀 그렇지 않다는 건(…) 실제 체험으로 아주 뼈저리게 느끼고 있다. 최근 최근 몇 일간 – 지난 주 월, 수, 목요일 그리고, 다시 오늘 이런 부분이 전혀 이루어지지 않는 어떤 서비스 때문에개고생 했다. 얼마 전에 지금 만들고 있는 게임과 사내의 다른 인프라에 해당하는 특정 서비스 연동 작업을 했다. 그리고 그 뒤치다꺼리를 한 건데, 나는 코드 한 줄 바꾸지 않아도, 서비스 연동이 깨지는 상황을 겪고 나니 정말 암담하기 그지 없다. 이 기간 동안엔 퇴근하면 아들 자는 얼굴밖에 못 봤음. -_-

나는 그 원인의 상당 부분이 해당 서비스를 개발하는 팀에서,

  • 제대로 테스트되지 않고, 자동화된 테스트가 (아마) 없으며
  • 적절한 스테이징 서버를 거치지 않고,
  • 문제 발생 후에도 감지하는데 시간이 걸리며[2]
  • 문제 발생 후 원인을 실제 서버에서 찾는다는 것,
  • 그리고 문제가 발생하면 영향을 받을 수 있는 이해 당사자들에게 시스템에 변경이 있다는 걸 알리지 않는 점

에 있다고 본다. 즉, 내가 위에서 언급한 “지속적인 시스템 배포(=Release)”를 했다면 상당 부분 막을 수 있다고 생각한다.

만약 제대로 된 테스트가 있다면 작은 원인 – 여기에 그거 써 놓기도 부끄러운 수준의 실수 – 은 금방 찾았을 것이다.

스테이징 서버가 있고 거기서 테스트했다면 자동화된 테스트가 없어도 상당 수준의 버그는 잡혀야 한다. 최소한 독립된 두 개의 테스트 시스템이 있는데, 두 곳 모두에서 동시에 문제가 발생한다는 건 x잡고 반성할 일이다.

문제 발생을 감지하지 못한다면 – 그러니까 스테이징 서버 좀 – 버그는 원래 잡을 수 없는 것이고, 하다 못해 이걸 실제 서버에서 찾는 건 제 정신이 아니다. 문제를 찾는 건 개발 서버 혹은 스테이징 서버에서 할 일이고, 실제 서비스는 이전 상태로 롤백 한 후 다른 이해 당사자가 영향 받는 일이 없어야 한다.

결정적으로 내가 가장 분노한 부분은, 내가 당장 해당 부분을 담당하고 있는데, 오늘 퇴근할 때 까지 메일 한 통 안 왔다. 내가 뭘 어떻게 대응하란 건지… 내가 변경 사항이 있다는 걸 파악한 건, 게임 서버(우리 쪽 스테이징 서버)를 테스트 중이던 QA 팀에서 show-stopper가 있다고 알려온 뒤라는 점이… 그리고 문제가 된 부분 중 하나가 업데이트된 바이너리를 우리 쪽에 전달 하지 않았다 라는 게…

이미 몇 년 – 그러니까 내가 입사한 2007년보다도 이전 – 전에도 동작하고 있던 서비스인데, 제대로 된 스테이징 서버와 QA가 없다는 점이 정말 이해가 안 간다. 최소한 자기가 만드는 물건에 자부심을 가질 정도의 노력은 보여줘야 하지 않겠나? 뭐 하나 바꿀 때마다 이 서비스 쓰는 팀에서 문제를 찾고 (역으로) 원인을 추정하고 있다면 확실히 문제가 있다고 본다.

내가 짜증내면서 줄어든 기대 여명에 대해, 이 팀에 생명 수당을 청구하는 걸 진지하게 고민해 봐야겠다.

  1. 물론 내면적으론 Continuous Deploy –> Continuous Delivery이고, 그 역은 아니란 차이가 있지만 []
  2. 외부에서 리포팅 해야 인지한다는 건 문제가 있다 []

Published by

rein

나는 ...

10 thoughts on “Continuous Delivery, Staging, … and Reality”

  1. > 제대로 테스트되지 않고, 자동화된 테스트가 (아마) 없으며

    내가 본 코드에 UnitTest 코드가 있다면………

  2. 한 두해 문제 아닌데 여전히 그러고 있는걸 보면
    1. 개발자로서의 사명(?)감 따위는 아웃오브안중이고 일이란 그저 돈버는 것만 아니면 당장에라도 때려칠 생각을 하고 있다거나
    2. 뭣 좀 해볼만 하면 조직변경 or 부서이동을 시켜서 제대로 된 시스템을 구축할 의지를 꺾어버린다거나
    3. 항상 일이 넘쳐 흘러서 다른것을 해 볼 엄두를 못낸다거나
    일텐데

    내가 볼 때는 셋 다 인듯

    1. 저 세 가지 중 뒷쪽 두 가지에 대해선 동정의 여지가 있다손 쳐도,

      문제가 생기면 스스로가 발견 못하는 것
      개발 서버와 서비스 서버(망 별로)가 제대로 분리되지 않은 것

      같은 건 당장이라도 고칠 수 있는 부분인데, 적어도 지난 4년간 변하지 않았다는건 욕먹을만하다고 생각해요.

  3. 밥그릇 문제를 넘어서서 제대로 동작하는 세계를 만들기 위해 노력할 수 있으면 좋겠는데요.

Leave a Reply