한 일주일 페이스북에 투덜거리고 나서 이제 입 다물고 월급쟁이 모드로 일하려고 했는데, 오늘은 너무 빡쳐서 글 싸지른다.
오늘 오전에 있었던 일이다. 여긴 JIRA 티켓 단위로 deploy를 하는데, 오늘은 내가 작업한 티켓 하나와 다른 동료가 작업한 티켓 하나를 내가 묶어서 deploy하기로 했었다. 그런데 1티켓당 1브랜치가 원칙이기 때문에 두 개의 브랜치를 merge해야 하고, 프로세스상 merge해야 하는 브랜치가 3개 더 있다. 그래서 merge하는 과정에서 QA 단계에 있는 브랜치도 같이 merge된 채로 deploy를 하고 말았다. 다행히 같이 QA 중이던 브랜치는 서비스에 아무 영향을 주지 않는 브랜치였다. 티켓 상황을 구체적으로 서술하면 이렇다.
- A : Ready to deploy. 간헐적인 주문 거래 오류를 막는 패치
- B : Ready to deploy. 간단한 데이터 마이그레이션 스크립트
- C : In QA, 서비스에는 영향 없을 것으로 추정됨. 10분 이내에 확인 가능.
A + B만 deploy 해야 하는데 A + B + C를 deploy한 것이다. C가 실 서비스에 영향이 없을 듯 하니 난 당연히 확인만 하고 넘어가면 되는 줄 알았다. Working software가 무엇보다 중요한 것 아니겠는가
그렇지만 위에서 내려진 결정은 달랐다. C는 프로세스를 따르지 않았으므로, 규정에 따라 rollback 하고, 오후에 다시 A + B만다시 deploy 하라는 것. Blue Green Deployment를 하기 때문에 rollback이쉬우므로 rollback은 그냥 해도 좋지만 이미 deploy 가능 시간이 지났으므로, 다음 deploy 가능 시간대에 하라는 것이다.(여기는 deploy 가능 시간이 10시 반 이전, 3시 ~ 4시 반 사이)
하지만 제 아무리 이전 코드가 그대로 있어서 link만 바꾸면 된다고 해도 rollback이 100% 안전한 경우는 웹 서비스에는 존재하지 않는다. 당연히 rollback에도 risk가 존재하며, C가 가진 risk에 비해 작다고 하기 어렵다. 실제로도 이 의사 결정을 내리는 동안 C는 아무 문제를 일으키지 않았지만, rollback은 migration 문제를 일으켰다.
애자일 팀이라면 이 정도의 상황이면 당연히 C를 빠르게 검증하려고 들 것이다. 검증을 통과하면 제일 좋은 상황이고, 문제가 생기더라도 그 문제의 종류에 따라 대처할 것이다. 문제가 작으면 quick fix로 해결할 것이고, 문제가 크면 아마도 위의 결정처럼 일단 rollback한 후 즉시 A + B를 다시 deploy할 것이다. 하지만 애자일 팀이라면 아마도 deploy 시간에 제약이 크지 않을 것이므로 즉시 수정 deploy가 나갈 것이다.
그래서 난 그 결정에 잠시 저항했지만, 의사결정권자를 비롯한 팀원들 모두의 의견이 거의 일치했다. 이미 요기는 그런 문화가 정착해 있고, 내가 이교도다. risk를 감수하고 빠르게 전진하기보다, risk의 최소화를 가장 중요하게 생각한다. 하지만 그렇다고 정말 risk가 최소화되고 있느냐 하면 그런 것도 아니다. 내가 일한지 불과 3주인데 벌써 크고 작은 장애를 네 번 경험했고, 앱이 죽는 경우, 웹 주문이 안되는 경우 등의 대형 장애도 발생했다. PHP 쓰는 회사도 이 정도 장애는 안 난다.
얼마 전에 있었던 앱 죽는 장애도 10분 안에 죽는 것을 막을 수 있고, 15분 안에 수정 패치까지 할 수 있는 문제였지만, 복잡한 프로세스를 따르느라 1시간도 넘게 걸렸다. risk를 최소화하기 위해 프로세스를 도입했지만, 정작 그 프로세스를 지키느라 risk가 올라가고 있는 것이다.
그런데 정말 날 더 충격 속에 빠뜨린 것은, 이런 상황에 이의를 제기하는 사람이 아무도 없다는 것이다. 티켓 하나 개발해서 deploy하기까지의 프로세스를 상세히 서술하면 무려 15단계에 이른다. 티켓을 만들지 않은 일은 하면 안된다. pip_requirements 파일 하나 고치려면 새로운 티켓 만들고 브랜치 생성한 다음 staging에서 테스트하고 QA 거쳐서 deploy하고, 그래야 다시 master에 merge된다. 그게 귀찮아서 그냥 다른 티켓 브랜치에 섞여서 가면, 그 브랜치가 QA 거쳐서 deploy되기 전까지 다른 브랜치에선 그 작은 pip_requirements 변경 사항 하나가 반영이 안된다. 수동으로 다시 브랜치 찾아서 merge해 와야 한다. 이러니 오래된 작은 문제점들이 굉장히 많다. 그래서 내가 가끔 너무 복잡하다고 말하면 "복잡한가요?"라고 되묻는다. 단순히 위의 누군가가 이런 관료주의를 지향해서가 아니라 직원들 대부분이 이런 관료주의를 지지하고 있다.
뭔가 문제가 발생하면 재발 방지책을 항상 찾는다. 여기까진 좋다. 하지만 Five Why 등을 통해서 근본 원인을 찾아들어가는 것이 아니라 1차원적인 해결책만 찾는다. 그러니 문제가 하나 발생하면, 그 문제를 막기 위한 프로세스를 하나 추가한다. 이런 과정이 반복되면서 점점 프로세스가 비대해져 왔을 것이다. 프로세스가 복잡한 회사들도 처음부터 그랬던 회사는 거의 없다. 대부분 전형적인 갈라파고스형 진화 과정을 거친다.
그래서, 내가 어떻게 바꾸는 건 불가능하다. 한 명이라도 동조자가 있어야 할 텐데, 정말 그 한 명이 없다. 정말 월급쟁이 모드로 전환해야 하나. 고민이 깊어간다.