이 버그는 개발한 너의 잘못이야?

조용하던 사무실에 난데 없이 이런 고성이 터져 나옵니다. 필시 운영 중인 서비스나 배포된 앱에서 심각한 문제가 발생하였습니다.

이 프로그램 누가 만들었어!!!

이번 글은 최근 페이스북에 한 분이 질문하신"개발자가 실수로 버그를 만들었습니다. 여러분이 상사라면 어떻게 하시겠습니까?" 글에 대해 필자의 생각을 정리해 보았습니다.

이 버그는 개발한 너의 잘못이야?

특정 기능에 문제가 발생했을 때 그 기능을 개발한 개발자의 잘못으로 생각하는 팀도 있습니다. 설령 팀 구성원 또는 팀의 관리자는 그런 생각을 하지 않는다 하더라도 개발자 스스로가 그런 생각을 하는 경우도 많이 있습니다. 이런 개발자나 팀이 있다면 필자는 절대로 그런 생각을 할 필요가 없다고 말하고 싶습니다. 특히 개발자에게는 더 강조하고 싶습니다. 심지어 버그나 잘못된 구현에 대해 더 당당해야 할 필요가 있습니다.

내가 만든 코드이지만 나의 잘못이 아니다.^[1]

라고 말입니다.

코드를 만드는 것은 전체 중 일부일 뿐

필자가 이렇게 주장하는 것은 하나의 기능이 배포되기 위해서는 많은 과정이 필요한데 그 과정 중에 코드를 만드는 것은 일부분이기 때문입니다. 일반적으로 정상적으로 운영되는 개발 팀이라면 다음과 같은 과정을 거쳐 기능이 배포될 것입니다.

• 서비스 기획 -> 개발팀 기술 검토 -> 서비스 기획 확정 -> 개발 -> 개발자 자체 테스트(단위 테스트 등) -> QA 테스트 -> 배포 -> 배포 후 모니터링 및 배포 후 테스트

각 과정에 참여하는 구성은 팀이 될수도 있고 팀내 개인이 될 수도 있고, 한명이 여러 역할을 같이 수행할 수도 있습니다. 큰 조직이라면 기획팀, 개발팀, QA팀이 분리되어 있을 것이며, 더 큰 조직인 경우 개발팀도 다시 백앤드 개발팀, 프론트앤드 개발팀, 앱 개발팀 등으로 세분화 되어 있을 것입니다.

필자의 경우 책임 소재 여부를 잘 따져 보지는 않지만 이번 글이 책임 소재를 따져보자는 글이기 때문에 각 단계에 대해 필자가 생각하는 책임은 대략 다음 정도입니다.

• 배포된 기능에서 오류가 발생하는 경우: QA 팀
• QA 팀으로 테스트 요청시 발생하는 오류: 개발팀
• 서비스 자체에 대한 불만: 기획팀

물론 모든 참여자가 문제 발생에 대한 책임에 자유로울 수는 없지만 위의 구분은 책임을 가장 많이 가져 가는 역할에 대한 생각입니다. 이런 관점에서 보면 배포된 기능에서 문제가 발생하면 개발자의 책임이라기 보다는 QA의 책임이 더 크다고 할 수 있습니다. 이렇기 때문에 최종 배포 가능여부에 대한 의사 결정도 QA 담당자가 해야 한다고 생각합니다. 최종 승인은 Product Owner 또는 서비스 관리자가 하겠지만 이번 배포 건에 대해 배포 가능 여부에 대한 의견을 이들 최종 승인자에게 해야 합니다.

개발자(팀)는 책임이 없나?

그러면 모든 책임은 QA나, 관리자에게만 있고 개발자에게는 없을까요? 물론 아닙니다. QA 팀은 개발팀의 에러율을 지표로 관리를 해야 합니다. 이 지표는 배포된 기능에 대한 에러율 보다는 QA  팀으로 이관되어 배포 전 테스트에서 발생하는 에러율이어야 합니다. 그래야 앞에서 언급한 각 팀의 책임 범위 내에서 업무가 이루어 지기 때문입니다. 대략 다음 정도로 관리할 수 있겠죠.

개발팀의 에러율^[2] = 테스트 과정에서 QA팀이 등록한 버그 수 / QA팀으로 이관된 기능 수

개발 에러율이 높다는 것은 개발자가 자신이 만든 프로그램을 테스트를 모두 수행하고, QA 테스트 환경으로 이관한 후 QA 팀의 테스트 시에 문제가 많이 발생했다는 것을 의미합니다. 다시 말해 개발자가 제대로 테스트를 수행하지 않았거나, 버그가 많이 있는 상태로 QA 팀으로 전달했다는 것입니다. 이렇게 되면 QA팀의 테스트 부담이 증가하여 일정 지연 또는 품질이 낮은 제품이 배포될 가능성이 많습니다. 이것을 방지하기 위해서 QA 팀 입장에서도 개발팀에게 버그가 없는 코드를 만들게 압박(?)을 할 수단이 있어야 하는데 이런 지표를 이용하여 압박을 할 수 있습니다.

운영 중인 서비스에 문제가 발생하면 어찌되었던 원작자인 개발자가 가장 많은 심리적 부담을 가지게 됩니다. 이런 부담을 많이 가지는 개발자도 있고, 덜 갖는 개발자도 있지만 이런 부담이 어떤 개발자에게는 엄청난 스트레스로 다가 오기도 합니다.  관리자가 명시적으로 압박을 주지 않아도 이미 스트레스를 많이 받고 있고 책임을 느끼고 있다고 보시면 됩니다.

긴급 배포 상황에서는

이 상황에 대한 대처가 중요한데 긴급 배포 상황이 되면 시간이 오래 걸리는 정상적인 프로세스보다는 긴급 배포 프로세스를 거치는 경우가 많습니다. 즉, 최종 승인자가 QA의 의견을 무시하고 배포를 해야 할 경우가 발생합니다. 예를 들어

• 서비스의 품질 보다는 정해진 시간에 기능을 공개하는 것이 더 중요한 경우
• 특정 기능에 대한 테스트가 실제 환경에서만 테스트 가능한 경우
• 중요한 기능에 장애가 발생하였고 테스트 시간이 많이 소요되는 경우
  • 필자는 이런 경우라면 해당 기능을 막는 코드를 먼저 배포하고
  • 제대로 테스트를 수행하고 배포하는 것이 더 바람직하다고 생각하지만, 결정은 서비스 관리자의 몫

이외 여러 경우가 있을 수 있습니다. 이때에는 한 사람을 제외한 그 어느 누구에게도 책임을 지워서는 안됩니다. 테스트 과정을 거치지 않고 배포를 승인한 사람이 책임을 져야 하는데 대부분 그 사람은 서비스 관리자이거나 스타트업의 경우 대표이사가 됩니다.

버그 없는 서비스(프로그램)은 없다

서비스 관리자나 대표이사는 개발에 대해 잘 모르는 경우 많습니다. 그리고 이런 분들의 특징은 버그가 없는 서비스를 원하는 경우가 많습니다. 물론 버그가 없는 서비스이면 좋겠지만 현실 세계에서는 이것은 불가능한 일입니다. 그 이유는 서비스나 프로그램은 사람이 한땀 한땀 만든 결과물이기 때문입니다.심지어 자동화된 라인에서 로봇이 생산한 제품에도 불량이 발생하는데 모든 것을 사람에 의해 만들어지고 그것도 한두명이 아닌 여러명이 만든 것을 조립한 결과물인데 버그가 없을리가 없습니다.  이런 상황에서 애초에 버그가 없는 결과물을 기대하는 것은 임파서벌한 미션입니다.

어느 정도의 버그가 용납이 될 것인가? 이 질문에도 답은 없는 것 같습니다. Time to market을 위해 빠르게 새로운 기능을 내놓을 것인가? 아니면 사용자에게 안정적으로 기능을 서비스 할 것인가?에 대한 선택의 문제라고 볼 수 있습니다. 빠른 기능 출시를 원하는 경우라면 버그에 조금 더 관대해야 할 것이며, 안정적인 서비스를 원한다면 적은 버그를 가질 수 있도록 프로세스를 만들 수 있습니다.

그러면 서비스를 만들고 운영하는 개발 팀이나 회사는 버그를 쳐다보고만 있어야 할까요? 버그가 있다는 것을 인정하게 되면 버그를 없앨 수 있는 완벽한 방안을 고민하기 보다는 다음 주제로 고민을 더 하게 됩니다.

1. 출시 전 버그를 줄일 수 있는 방법은 없을까?
2. 출시 후 버그가 발생했을 때 어떻게 대처할 것인가?

1번 항목에 대해서 많은 조직은 이미 개발자에 의한 테스트 코드 기반 개발, QA 팀 또는 담당자에 의한 배포 전 테스트 과정을 진행하는 등 많은 노력을 하고 있습니다. 반면 2번 항목인 출시 후 버그가 발생했을 때에 대처 방법에 대해서는 미리 사전에 정의를 하지 않는 경우가 많이 있습니다. 이것 때문에 버그가 생겼을 때 앞에서와 같이 "누가 만들었어?" 라는 질문이 가장 먼저 나타나게 됩니다.

출시 후 버그에 대한 대처

서비스 운영 중에 특정 기능 추가 및 개선을 위해 보완된 프로그램을 배포한 후에 문제가 발생할 경우 대략 다음과 같은 정도로 대처 방법을 결정할 수 있습니다.

• 롤백
  • 기능 자체가 동작하지 않고, 해당 기능이 서비스의 핵심 기능이라서 서비스 사용자에게 중대한 불편을 주거나 매출 등에 문제가 발생하는 경우에는 즉시 해결하는 것이 좋습니다. 즉시 해결하는 방법은 롤백, 긴급 배포가 있습니다.
  • 롤백은 이런 상황에서 권장하는 방법입니다. 롤백이 잘되기 위해서는 배포 버전에 대한 형상 관리가 잘되어 있어야 하고, 배포 시 테이블 구조 등의 변경이 발생했을 때 이를 다시 원복해주는 스크립트 등이 잘 구성되어 있어야 합니다.
  • 테이블 구조 변경 등에도 롤백이 잘되게 하기 위해서는 개발, 테스트 단계에서 부담이 많이 가는 것은 사실입니다. 테스트 시에도 롤백에 대한 테스트까지 수행을 해야 하기 때문입니다. Rails의 경우 이런 상황들이 Rails 내에서 지원하고 있어 어느 정도 플랫폼의 도움을 받을 수도 있습니다. 그렇지 않은 플랫폼인 경우 Rails에서 db migration을 어떻게 처리하고 있는지에 대해 검토해보는 것을 추천합니다.
  • 개발 시 부담이 많이 되기 때문에 문제 발생 시 롤백을 생각하고 있다면 개발 요구사항을 제시할 때 반드시 롤백을 고려해 달라고 해야 하고, 개발팀은 롤백에 대한 프로그램까지 고려한 일정을 잡아야 합니다.
• 일반 이슈로 등록
  • 기능이 일부는 동작하고, 문제가 있는 기능이 서비스에 큰 영향을 미치지 않는 경우 추가로 버그 이슈로 등록하여 정상적인 프로세스를 진행하도록 합니다. 정상적인 프로세스가 의미하는 것은 우선순위 결정, 일정 수립, 개발, 테스트 등의 과정을 모두 거치는 이슈입니다.
  • 여기서 개발자나 기획자들이 유혹을 받게 되는 부분이 문제 있는 부분이 눈에 거슬리기 때문에 긴급 배포로 결정하는 경우가 많이 있습니다. 이렇게 하다보면 서비스가 정해진 마일스톤대로 진행되기 어렵고, 개발팀은 버그 해결하는데 대부분의 리소스를 사용하게 됩니다.
  • 스타트업의 대표나 서비스의 관리자에게 "부처"가 되어야 한다고 강조하는 이유이기도 합니다.
• 수정 후 긴급 배포
  • 해당 버그를 해결하는 코드를 다시 작성한 다음 다시 배포를 하는 방식입니다.
  • 이런 조치가 발생할 경우 이 조치로 인해 다시 발생하는 버그에 대한 책임은 한명만 가져가게 됩니다.
  • 이런 경우가 많으면 해당 서비스의 품질에 문제가 있거나 개발, 배포 프로세스에 문제가 있거나, 아니면 프로세스 자체가 아예 없거나 등 정상적인 상황이 아니라고 판단해야 합니다.
  • 필자의 경험으로 긴급 배포 상황이 개발 팀 또는 서비스 당 월 1회 미만으로 발생하도록 만들어야 합니다.

지속적인 개선

버그가 잘 처리되었다 하더라도 그런 버그가 발생하지 않도록 지속적인 개선이 필요합니다. 이런 개선을 위해서는 다음과 같은 활동을 병행하는 것도 도움이 됩니다.

• 새로 배포되는 코드에는 이 버그를 재현하는 테스트 코드가 추가 되었는지 확인
• 동일한 문제 발생 시 자동으로 확인할 수 있는 방법 확인
  • 이것보다 더 좋은 것은 이런 문제가 일어날 수 있는 상황이 예측 가능한지 검토
  • 자동으로 확인할 수 있으면 상시 모니터링 항목에 추가

마치며

서비스에 문제가 발생하면 그것을 개발한 개발자의 책임이 아닙니다. 그 서비스와 관련된 모두의 책임이며, 궁극에는 대표이사, 담당임원, 서비스 관리자의 책임인 것입니다. 따라서 누구의 잘못을 찾기 보다는 "어떤 조치를 하는 것이 현재 발생한 상황을 잘 극복할 수 있을 것인가?"를 생각하여 선 조치를 하고,  이런 상황에 대처하는 룰이나 프로세스를 정의하고 다시 발생하지 않거나 미리 확인할 수 있는 모니터링 체계를 잘 구축하는데 신경을 써야 합니다.

문제가 발생해도 고개를 떨구지 마시고, 당당한 목소리로 대처 방안을 이야기 하고, 끝난 후에도 불이익을 주지 말라고 분명히 이야기 할 수 있는 회사나 팀이 많이 생겼으면 하는 바램입니다.

사족: 대부분의 개발자는 알지만 딱 그분 만 모른다.

문제는 이런 내용들을 대부분의 개발자나 테스터, 심지어 기획자도 알고 있습니다. 작은 회사면 딱 한 분, 조금 큰 회사면 사업을 총괄하거나 서비스를 총괄하는 분 들만 모르고 계시는 것 같습니다. 어쩌면 알고 있지만 의도적으로 모른척하고 그렇게 행동하실 수 도 있습니다. 이글을 쓰는 목적도 그런 분들이 스쳐 지나가면서 잠깐이라도 봤으면 하는 바램에서 두서 없이 적어 보았습니다.

각주

[1]: 버그를 찾을 때는 반대의 입장이라야 합니다. "코드를 만든 내가 잘못 만들었을 거야."라는 자세를 가지고 검토를 해야 버그를 쉽게 찾을 수 있습니다.

[2]: 이것보다 더 좋은 개념이 있을 것 같은데 더 찾아 보지는 못했습니다. 최근 Popit 저자 분들 중에 QA 분야에 계신 분들도 있으니 피드백 부탁드립니다.