Title

DevOps  |

개발 조직의 문화와 제품의 개발 속도

나는 개발자로서 첫 커리어를 작은 스타트업에서 시작했다. 지금은 이직해서 다른 회사를 다니고 있고 시간도 많이 흘렀지만 아직도 기억에 남는 에피소드가 몇개 있다. 그 중 한가지는 서비스 장애에 대처하는 개발 문화와 관련된 이야기다.

문제의 그날, 오후에 갑자기 서버가 에러를 내뿜으면서 죽었고 앱에 접속할 수 없는 심각한 장애가 터졌다. 약 20분 뒤에 갑자기 서비스가 복구됐고, CTO가 모든 개발자들을 회의실에 소집했다. 그리고 누가 먼저 서비스가 안된다는 사실을 알았냐고 질문했다. 그런데 다들 서로 얼굴만 쳐다보고 말하기를 주저했다.

CTO 가 이렇게 말했다. ‘우리가 장애를 어떻게 복구했는지 알아보기 위해서 모였습니다.’ 그러자 다들 한마디씩 말하기 시작했다. CTO는 누가 무엇을 발견해서 누구에게 전달했는지 화이트 보드에 적었다. 장애발생시 부터 복구때까지 무슨일이 있었는지, 한 눈에 볼 수 있도록 정리가 됐다. 안드로이드 개발자가 제일 먼저 앱이 문제가 있다는 사실을 알았고, 서버 개발자 a 에게 확인을 요청했다. 개발자 a는 에러 로그를 보고 db 에 문제가 있다는 사실을 알았지만 혼자 해결할 수 없어서 다른 서버 개발자 b에게 해당 내용을 공유하면서 같이 해결하자고 했다. 동시에 다른 팀에 있었던 서버 개발자 c, d 는 서비스에 문제가 있다는 사실을 알아차렸고 문제의 원인도 파악했다. 그래서 바로 CTO에게 전달헀고 CTO가 장애 대응을 했다.

CTO는 다음에 만약 비슷한 상황이 벌어진다면 더 빨리 복구하기 위해서 어떤 부분을 개선할 수 있겠냐고 물어봤다. 개발자들은 화이트 보드에 적힌 타임라인에서 군더더기처럼 보이는 부분을 제거했다. 그러자 타임라인이 짧아졌고, 다음번 장애 상황에서는 누가 무엇을 해야 하는지가 명확해졌다. 이제 장애를 일으킨 사람은 더이상 그 회의의 관심사가 아니였다. 그 후에도 장애는 발생했다. 다행히 앱에 접속을 할 수 없을 정도의 치명적인 장애는 아니였다. 대응도 빨랐다.

이 조직은 이러한 과정을 거쳐서 장애를 더 빨리 극복하게 됐다. 이런 장애는 다른 회사도 경험할텐데, 다들 어떻게 풀어나가고 있을까? 그 이후 나는 몇개의 회사를 거치면서 궁금증을 해소했다. 많은 조직들이 다양한 방식으로 장애에 대응한다. 그 중 다른 의미로 인상깊었던 조직은 이렇게 문제를 해결 했다. 에러가 난 기능을 개발한 개발자를 색출해서 회의실에 몰아놓고 월급을 깎겠다고 했다. 해당 개발자의 이름을 전사원이 들어가있는 채팅방에서 장애의 원인으로 언급했다. 해당 조직은 내가 경험한 조직중에 제품 개발, 개선이 가장 느렸고 개발자 이탈률이 높은 조직이였다.

장애는 유저 이탈률에 큰 영향을 미친다. 비개발자로 구성된 경영진은 장애를 낸 개발자를 문제의 원인으로 본다. 그래서 해당 개발자에게 책임을 묻는다. 그러나 이러한 해결책은 위에 언급한 사례처럼, 무중단 서비스를 만드는 게 아니고 오히려 조직을 보수화해 기능 개발과 개선만 느려진다. 생각해보면 장애를 절대 일으키지 않는 방법은 개발을 안하는 것이기 때문이다. 개발자들 대부분은 기능 개발 및 배포를 두려워 하게 되고, 결국 기능 개발이 느린 조직이 된다. 대부분의 회사에서 개발 조직의 문화는 사업과 무관한 부분처럼 여기지만 사실은 아니다.

References

https://developers.google.com/web/fundamentals/performance/why-performance-matters