서비스를 배포하기 전에 꼭 필요한 단계 — 테스트, QA, 스테이징

새 기능을 부탁하면 개발팀에서 이런 말이 돌아올 때가 있습니다. “스테이징에 올렸으니 확인해 주세요”, “QA 끝나면 배포할게요”, “테스트부터 통과해야 합니다”. 만든 것을 곧바로 사용자에게 내보내지 않고, 그 사이에 무언가를 거치는 단계가 있다는 뜻입니다.

지난 글에서 문제가 터지면 핫픽스와 롤백으로 대응한다고 했습니다. 그런데 가장 좋은 것은 애초에 문제를 사용자가 만나기 전에 걸러 내는 일입니다. 이번 글에서는 그 일을 맡는 세 단계, 테스트, QA, 스테이징을 코드 없이 풀어 보겠습니다.

테스트는 코드가 의도대로 동작하는지 자동으로 확인합니다 #

테스트는 만든 코드가 의도한 대로 동작하는지 미리 확인하는 일입니다. 사람이 매번 손으로 눌러 보는 것도 테스트이지만, 개발에서 말하는 테스트는 대부분 자동으로 실행되는 검사를 가리킵니다.

예를 들어 “1,000원짜리 두 개를 담으면 합계가 2,000원이 된다"처럼, 입력과 기대하는 결과를 미리 적어 두는 것입니다. 그러면 코드를 고칠 때마다 이 검사들이 한꺼번에 자동으로 실행되면서, 어딘가 어긋난 곳이 없는지 빠르게 알려 줍니다.

자동 테스트가 특히 유용한 때는 기존 기능이 망가졌는지 확인할 때입니다. 새 기능을 더하다 보면 멀쩡하던 다른 곳이 덩달아 깨지는 일이 잦은데, 미리 적어 둔 검사들이 그 변화를 곧바로 잡아내 알려 줍니다. 사람이 모든 화면을 매번 다시 눌러 볼 수는 없으니, 이 자동 검사가 그 점검을 대신 맡아 줍니다.

QA는 사용자 입장에서 품질을 점검합니다 #

테스트가 코드 단위의 검사라면, QA는 한 발 물러나 완성된 기능을 사용자 입장에서 점검하는 일입니다. 품질 보증을 뜻하는 말로, 이 일을 전담하는 직군을 QA라고 부르기도 합니다.

QA는 정해진 대로 잘 동작하는지뿐 아니라, 사용자가 예상 밖으로 행동할 때 어떻게 되는지를 집요하게 따집니다. 입력란을 비운 채 누르면 어떻게 되는지, 결제 도중 뒤로 가기를 누르면 어떤 일이 벌어지는지, 느린 인터넷에서 화면이 어떻게 보이는지 같은 것들입니다. 만든 사람은 정상 경로를 따라가기 쉽지만, QA는 일부러 예상을 벗어난 행동까지 시도해 문제를 미리 들춰냅니다. “잘 만드는 일"만큼이나 “잘못된 것을 찾아내는 일"이 중요하기 때문에 존재하는 단계입니다.

스테이징은 운영과 똑같이 꾸민 점검용 공간입니다 #

여기서 한 가지 의문이 생깁니다. 이 점검들을 대체 어디서 할까요. 실제 사용자가 쓰는 곳에서 시험하다가는 사고가 그대로 사용자에게 갑니다. 그래서 운영 환경과 똑같이 꾸며 둔 별도의 공간을 두는데, 이것이 스테이징입니다.

스테이징은 실제 서비스와 거의 같은 환경이지만 사용자는 들어오지 않는 별도 공간입니다. 새로 만든 기능을 먼저 이곳에 올려, 실제와 같은 조건에서 마지막으로 점검합니다. 기획자나 디자이너가 결과물을 미리 확인하는 것도 보통 이 스테이징에서 이루어집니다. 여기서 문제가 없다고 확인되면, 비로소 사용자가 쓰는 운영 환경으로 내보냅니다. “스테이징에서 확인해 주세요"라는 말은 사용자에게 닿기 전, 이곳에서 결과물을 먼저 봐 달라는 뜻입니다.

함께 모이면 사용자 앞의 사고가 줄어듭니다 #

세 단계는 사용자에게 닿기 전 차례로 거치는 점검입니다. 코드 단위의 어긋남은 자동 테스트가 거르고, 사용자 입장의 허점은 QA가 들춰내며, 그 모든 점검이 운영과 똑같은 스테이징에서 이루어집니다. 이 단계를 잘 갖출수록 사용자가 버그를 만나는 일이 줄고, 핫픽스나 롤백으로 급히 수습할 일도 줄어듭니다. 미리 거르는 데 드는 시간이 결국 나중의 사고를 막는 셈입니다.

왜 비개발자가 알면 일이 편해지는가 #

• “확인해 주세요"가 어느 단계인지 압니다. 스테이징에서 봐 달라는 요청이 어떤 점검을 뜻하는지 알면, 무엇을 어떤 기준으로 점검해야 하는지 분명해집니다.
• 일정에 점검 시간을 넣습니다. 테스트와 QA에 드는 시간을 일정에 미리 잡아 두면, 막판에 쫓기며 검증을 건너뛰는 일을 줄일 수 있습니다.
• 버그를 잘 신고합니다. 어떤 환경에서 무엇을 어떻게 하다가 문제가 났는지 적어 주면, QA와 개발팀이 같은 상황을 재현해 원인을 빨리 찾습니다.

마무리 #

오늘은 만든 것을 사용자에게 내보내기 전에 거르는 세 단계를 살펴봤습니다. 테스트는 코드가 의도대로 동작하는지 자동으로 확인하고, QA는 사용자 입장에서 품질을 점검하며, 스테이징은 그 점검이 이루어지는, 운영과 똑같이 꾸민 공간입니다. 이 세 단계가 탄탄할수록 사용자 앞에서 터지는 사고가 줄어듭니다.

문제가 터진 뒤의 대응이 궁금하다면 버그, 핫픽스, 롤백을, 왜 기능 하나에도 점검까지 시간이 드는지 궁금하다면 왜 간단해 보이는 기능이 오래 걸릴까를 함께 읽어 보시길 권합니다.