테스트에서 (더 잘, 더 자주) 배우기

안녕하세요. 원더월에서 프론트엔드 개발을 하면서 테스트와 애자일을 전도하는 김태희입니다.

저는 팀에 들어온지 이제 2달째입니다. 그 동안 프롬 스토어를 런칭하고, QA를 진행하면서 많은 걸 배웠는데요. 그 중에서도 가장 큰 부분이라면… 프론트엔드 테스트에 대한 생각이 아닐까 싶습니다.

저는 전에도 테스트 에 대한 글을 여러 번 썼었습니다. 3년 넘게 프로그래밍 코치로 일해왔고, 테스트 엔지니어로 일한 경험도 있습니다. 개발자이면서 테스터인 저에게도 늘 후회하고 새롭게 시도해보는 것도 많은데요. 비슷한 고통을 겪는 분들을 위해 제가 배운 것들을 공유해볼까 합니다.

• 3줄+ 요약

  • 전에 해본 적 없는 낯선 것에 적응하고 도전할 때 학습이 일어나고, 피드백을 받아야 합니다.
  • 테스트를 미룰 수록 비용은 커지기 때문에, 테스트는 개발 초기에 일찍, 자주 해야 합니다.
  • 명세를 검토하거나 탐색하는 등 수동 테스트로 맹점을 찾아내고, 자동화는 핵심에 집중합시다.

• 시도해보실만한 것들

  • 테스트를 나중에 몰아서 하기보다, 조금씩 자주, 일찍 해보세요. 수동 테스트도 좋습니다.
  • 팀에 전문 테스터가 없더라도, 테스트를 개선하고, 테스터의 관점을 가져보세요.
  • 개발하기 전에 요구사항을 테스트 케이스로 만들고 “이런 경우는 어떻게 되지?”하는 질문을 던져보세요.
  • 실제 상황과 비슷한 테스트를 만드세요. 우리가 놓치고 있는 맹점을 탐색해보세요.
  • QA에서 보고된 에러들을 살펴보고 비슷한 걸 묶어서 패턴을 찾아보세요.
  • 테스트를 귀찮게 만드는 비용을 찾아서 줄이고 더 편하게 개선해보세요.
  • 모든 걸 자동화하기보다, 비용대비 효율이 큰 적정기술에 집중해보세요.
  • 기존 코드를 리팩토링하거나 수정하기 전에, 회귀 테스트로 안전망을 쳐두세요.

테스트를 미루는 팀이 많습니다. 자동화만 이야기하는 게 아니라, 수동 테스트도 그렇습니다. 우리는 일단 구현하고, 모든 게 끝난 뒤에 테스트는 ‘나중에’ 하려 합니다. 시간이 없기 때문에 테스트까지 할 시간은 없습니다. 우리는 ‘빠르게’ 가려 합니다. 제가 저희 팀에 들어왔을 때에도 마찬가지였고요. 사실 저도 마찬가지였습니다.

낯설고 불확실한 상황일수록 모르는 게 많고, 학습이 중요합니다

저에게, 그리고 저희 팀에게 현재 진행 중인 신규 서비스 개발은 여러모로 새로운 도전이었습니다. 회사에서 사용하는 Next나 Jotai, tanstack-query 같은 기술들은 오히려 저도 전에 사용해봤던 것이라 익숙했습니다. 문제는 기술이 아니었습니다. 새로운 비즈니스 로직과 도메인, 환경 그 자체였습니다.

예를 들어 원더월은 데스크탑 중심의 사이트였는데, 신규 서비스는 모바일이 중심이었습니다. 웹 개발자들은 습관처럼 데스크탑에서 개발을 진행했는데요. QA에 들어가서 핸드폰으로 배포된 사이트를 이용해보니… 키보드나 주소창, 백버튼, 백그라운드 상태 등 모바일에 특수한 이슈들이 우르르 쏟아졌습니다. 충분히 예상할 수 있었음에도… 기획 등에도 ‘당연한 상식’처럼 정의되지 못한 문제였죠.

또 저희 신규 서비스는 비즈니스 로직이 복잡합니다. 예를 들어 옵션이 없는 상품, 옵션이 하나인 상품, 여러 개인 상품 등이 있습니다. 그러다보니 브라우저에서 몇 번 눌러볼 때에는 괜찮아 보였던 것이… 더 많은 케이스에서는 잘못된 결과를 주는 경우도 많았습니다. 일부 에러만 고치는 게 아니라, 컴포넌트나 로직을 통째로 재작성할 일도 많았습니다.

원래 낯설고 새로운 상황에는 빼먹고 모르는 게 많은 법입니다. 이미 잘 알고 있는 걸 하는 게 아니기 때문입니다. 미지의 새로운 기회를 찾아서 우리는 도전하고 있습니다.

우리는 뼈 아픈 실수를 하고 나서야 배웁니다. 실수의 대가는 상상보다 커지기도 하죠. ‘지금 내가 아는 걸 1달 전에도 알았더라면!’ 같은 생각을 해보신 적이 있나요? 누군가 그런 기회를 준다면 거절하시겠어요?

방법이 있습니다. 바로 테스트를 일찍 시작하는 것입니다. 테스트를 더 쉽게 만들고 더 자주 하는 겁니다.

자주 깜짝 놀라야 성장합니다

교육과 전문성에 대한 여러 연구에서 사람은 익숙한 것만 반복해서는 성장할 수 없다고 합니다.

학습은 놓치고 있던 것, 모르는 것, 깜짝 놀라는 “앗!” “어라?”의 순간에서 일어납니다. 단순히 회고를 하거나 피드백을 받는 것만으로는 전문가의 능력이 향상되지 않지만, “피드백에 깜짝 놀란 횟수”는 전문가의 능력을 예측할 수 있다는 연구도 있어요.

이 연구에서 흥미로운 것을 추가적으로 발견한 게 있습니다. 상담을 하고 나서 내담자로부터 피드백을 받는 것에 대해 조사를 했는데요, 단순히 피드백을 받는 횟수 등은 상담효과와 관련이 없었습니다(피드백의 중요성에 대해서는 달인이 되는 비결 참고 — 첨언하자면 그냥 피드백이 아니라 어떤 피드백이냐가 중요하다는 것). 대신 내담자의 피드백에 상담자가 놀란 횟수는 상담효과를 높은 정도로 예측할 수 있었습니다(상담효과 분산의 약 62%를 설명).

[어라가 전문가를 만든다] 김창준

코딩을 하면서 깜짝 놀라는 순간은 언제일까요? 보통 QA 기간입니다. 개발자들은 피드백을 받고 깜짝 놀랍니다. 잘 될 줄 알았는데 그렇지 않으니까요! “이런 경우가 있었단 말이야?”

즉 테스트를 뒤로 미룬다는 건 학습을 뒤로 미루는 것과 같습니다. 더 심각한 문제는 학습의 비용도 점점 커진다는 거에요.

학습을 뒤로 미룰 수록, 비용은 커지고 출시는 늦어집니다

제가 예전에 스토리북이라는 도구의 UI 테스팅 가이드를 번역한 적이 있습니다. 거기서 흥미로운 연구를 하나 보았어요.

이 연구에 따르면 에러를 뒤늦게 발견할 수록, 고치는데 드는 비용이 급격히 증가한다(Escalation)고 합니다! QA 단계에서 에러를 고치는 비용은 적게는 21배에서 크게는 177배 비싸고요. 심지어 프로덕션에서 발견한다면 그 비용은 적게는 29배에서 크게는 1615배로 증가합니다! (이 링크에서 직접 읽어보실 수도 있어요.)

생각해보면 당연합니다. 흔한 소프트웨어 개발 생명주기를 생각해봅시다. 요구사항을 만들고, 설계를 하고, 구현하고, 테스트하고, 프로덕션에 배포합니다. 요구사항 단계에서 문제를 발견한다면, 요구사항 문서를 약간 고치면 됩니다. 하지만 개발 중에 문제를 발견한다면? 뭐 좀 당황스럽긴 하겠지만 바로 수정하고 고치면 되지요.

개발이 완료된 뒤라면? 에러가 나도 원인을 찾기가 힘듭니다. 어쩌다 에러가 난 건지 재현해달라고 하겠지요. 그리고 방대한 코드를 뒤지면서 원인을 추측하고 탐정일을 시작할 겁니다. 겨우 에러의 원인을 알아내면 운이 좋아도 고쳐야 하고요. 심하면 처음부터 다시 만들어야 합니다. 흠…

그런데 코드리뷰와 QA를 통과해서 프로덕션까지 나갔다면? 고객센터에 불만접수로 시작하겠죠.

하지만 사람들은 테스트를 뒤로 미루거나, 안 하려 합니다. 그리고 “시간이 없다”고 늘 말합니다. “기능 만들기도 바쁜데 테스트할 시간이 어디 있냐!”고 말이죠. 하지만 버그는 언젠가 나타나기 마련입니다. 카드 빚을 돌려막기 하는 것처럼 눈덩이처럼 불어나죠.

저희 팀이 겪은 상황은 이 논문이 말하는 상황과 똑같았습니다. 심각한 문제들을 뒤늦게 발견했고요. 기획도 계속 수정되거나 추가되어야 했고, 다시 만들어야 하는 일도 많았습니다. 뒤로 갈 수록 업무 강도는 강해지고, 야근을 하게 되었습니다.

그러면 어떻게 해야 에러를 조기에 발견할 수 있을까요? QA 쪽에서 이미 이야기하고 있는 방법론이 있습니다. Shift Left 테스트. 테스터가 소프트웨어 개발의 초기부터 개입하고, 처음부터 테스트를 염두에 두고 지속적으로 테스트하며 개발하자는 것이죠.

Three Amigos, 비즈니스, 프로그래밍, 테스트

쓰리 아미고는 미국 코미디 서부 영화의 이름에서 따온 애자일 프랙티스 중 하나입니다. 개발할 때 “비즈니스”, “프로그래밍”, “테스트”의 관점이 모두 필요하다는 것이죠.

보통 기획자나 제품 책임자(Product owner)가 비즈니스 역할을 맡고요. 프로그래머들이 코딩을 합니다. 그런데 신기한 건 ‘테스터’의 존재입니다.

저희 회사도 그렇지만 많은 회사에는 테스트 전문가가 없습니다. 테스트는 기획자나 개발자가 알아서 하는 경우가 많고요. 애자일을 표방하는 곳에서도 뒤늦게 개발 막바지에 케이스를 정의하거나 QA를 합니다. 그게 너무 당연해보여서 다들 이상하게 생각하지 않지요.

하지만 사실 테스터는 창의적인 학습 전문가들입니다. “이러면 어떻게 되나요? What If” 라는 질문을 던지고, 우리가 놓치고 있는 허점을 발견해주는 사람들이죠.

앞서 이야기한 것처럼 에러는 요구사항 단계에서부터 이미 발견할 수 있습니다. 그렇다면 기획과 요구사항을 정의할 때부터 이 셋이 모이면 좋을 것입니다.

이를 잘 보여주는 게 다음 영상인데요. Cucumber라는 테스트 도구를 소개하는 강의 중 일부입니다. 실제로 Discovery workshop이 진행되는 예시를 보여주는데, 테스터가 명세에서 놓친 부분을 질문하면서 명확하게 정의하는 과정이 보이지요.

테스터(Tester), 개발자(Dev), 제품 책임자(PO)가 모여서 구매한 물품을 환불하는 사용자 스토리를 논의합니다.

• PO: “이 사용자 스토리에 적용되는 비즈니스 규칙은 간단해요. 고객은 영수증을 가지고 있는 경우에 구매한 물품을 14일까지 환불할 수 있어요.”
• Dev: “예시를 하나 들어주실래요?”
• PO: “좋아요. 고객이 저번 주에 주전자를 하나 샀다고 하죠. 집에 가서 보니까 찬장의 색깔이랑 안 맞아서, 마음에 들지 않았고, 저희 상점에 돌아와서 저희 직원에게 환불을 요구하는 거죠.”
• Tester: 그러면 여기서 기대하는 결과는 뭘까요? 뭘 테스트해야 하죠?
• PO: 음. 일단 그 상품의 재고를 1 올려야겠죠?
• Tester: 만약에 영수증이 없으면요? 집에 돌려보내나요?
• PO: 음. 꼭 영수증이 아니라도 구매를 입증할 기록이 있으면 될 것 같아요. 예를 들어 결제 기록이라거나? 이거는 직원이 혼자 결정하기 보다는 매니저에게 말을 해야겠죠.
• Tester: 그러면 고객은 구매를 입증을 증거가 있으면 되는 거죠, 꼭 영수증이 아니라도요.
• Dev: 음… 저희 뭔가 까먹지 않았나요? 고객은 돈을 돌려받겠죠? 저희 잔고에서는 돈이 빠지고요.
• PO: 오, 맞아요. 당연하죠.
• Tester: 그리고 시스템이 반품된 물건을 창고 쪽 직원에게 수거해가라고 알림을 줄 필요도 있지 않을까요?
• PO: 그렇죠. 지금 논의할 사용자 스토리의 범위를 벗어나는 것 같은데. 이거는 백로그에 넣어놓고 다음 스프린트에서 개발하도록 하죠.

하지만 우리는 전문 테스터가 없는데! 그거 너무 이상적인 거 아니야! 라고 생각하실 수 있습니다. 저희 팀도 마찬가지의 상황인데요.

물론 전문 테스터가 있으면 좋겠지만, 역할보다 중요한 건 행동입니다. 어느 팀에서라도 누군가는 QA를 하고, 누군가는 테스트가 하는 일을 합니다.

예를 들어 저희 팀에서는 디자이너 님이 정말 멋진 역할을 해주고 계십니다. 제가 생각이 짧은 제안을 하면 “그런데 키보드가 올라오면 어떻게 될까요?” 같은 식으로 제가 “아…”하고 놀라게 되는 질문을 던져주시고요. 이번 QA 때에도 스타일 뿐만 아니라, 수 많은 정책과 로직의 에러를 찾아주셨어요.

물론 이렇게 재능 있는 누군가에게 기대야만 하는 것도 아닙니다. 늦었다고 생각할 때가 가장 빠른 때입니다. 애자일의 중요한 원칙 중 하나가 “짧은 반복주기”인 걸 기억하세요. 이미 개발이 완료되었고 QA기간에 들어간 상황에서도 테스트를 개선할 수 있고요. 테스트에서 더 자주 배울 수 있습니다.

요구사항 명세를 테스트 케이스로 정의하고 합의하기

보통 테스트라 하면 사람들은 휘황찬란한 테스트 도구를 이용한 자동화 테스트만 생각합니다. 언뜻 편리해보이지만 자동화하기 어려운 것도 많고요. 무엇보다 자동화 테스트 스크립트도 결국 사람이 짜야 합니다. 우리가 정의하지 못한 케이스는 테스트할 수 없고, 그래서 커버리지 100%라는 프로그램도 에러가 납니다.

그보다 중요한 건 먼저 기획서, 즉 요구사항 명세부터 시작하는 겁니다.

기획서에는 저희가 만드는 제품이 어떻게 되어야 한다는 수 많은 요소들이 정의되어 있습니다. “판매 기간이 시작되기 전에는 구매할 수 없다” 처럼 언뜻 당연한 상식처럼 보이는 것들 말이죠.

하지만 기획서에 빈틈이 있는 경우도 많고요. 한편으로는 그 기획이 실제로 잘 개발되었다는 걸 어떻게 확인할지는 불분명한 경우도 많습니다.

그래서 개발자나 테스터 역할을 맡은 사람은 기획서를 꼼꼼하게 읽으면서, 테스트 케이스를 정의하는 걸로 시작하면 좋습니다.

로그인 기획 분석의 예시

예를 들어 로그인이 완료되면 어떤 페이지로 가야 할까요? 저희 기획서에는 ‘메인 화면’으로 돌아간다고 되어 있습니다. 이를 테스트 케이스로 정의하면 다음과 같을 것입니다.

Given 로그인 페이지로 이동한다
When 로그인을 완료하면
Then 메인 페이지로 이동한다

하지만 다른 기획을 보면 의문이 생깁니다. 예를 들어 저희 장바구니 기획을 보면 장바구니 페이지는 로그인을 해야지 볼 수 있는데요. 그래서 로그인하지 않은 채로 장바구니 페이지로 들어가면 “로그인이 필요한 서비스입니다.”하고 Dialog를 띄워줍니다. 확인을 누르면 로그인 페이지로 이동하죠.

그러면 이렇게 이동해서 로그인을 했을 때 사용자는 어떤 페이지로 돌아가길 바랄까요? 메인 페이지가 아니라, 장바구니 페이지일 것입니다!

이는 모든 페이지에서 마찬가지입니다. 사용자는 로그인을 요구 받기 전에 마지막으로 방문했던 페이지로 돌아가고 싶어하겠죠.

이러한 사용성 문제는 테스트 케이스를 머리 속으로 상상해보기만 해도 ‘아차!’하고 깨달을 수 있습니다. 어떻게 보면 ‘당연한 상식’처럼 보입니다. 그래서 개발자들은 이미 기획을 무시?하는지도 모른 채 마지막으로 방문한 페이지로 가도록 구현하고 있었지요.

테스트 케이스를 적어보면 다음과 같을 겁니다.

Given 로그인하지 않은 채로
When 장바구니 페이지로 접속하면
Then 로그인할지 AlertDialog 로 물어본다
When 확인을 누르면
Then 로그인 페이지로 이동한다
When 로그인을 완료하면
Then 장바구니 페이지로 돌아온다

결국 QA에서 이 이슈를 재발견?하고 로그인을 비롯해서, 뒤로가기 관련된 로직을 모두 재정립하게 되었습니다.

탐색적 테스팅으로 내가 모르는 것 찾기

방금 보신 것처럼… 우리가 ‘생각했던’ 명세와 케이스에만 의존하는 테스트는 위험합니다. 테스트에서 배우려면! 명세와 케이스에 질문을 던지고, 저희가 생각하지 못했던 영역을 탐색해야 합니다.

여기에 탁월한 방법론이 ‘탐색적 테스팅’입니다. 한국에는 ‘탐험적 테스팅’이라고 번역된 책에서 이를 잘 다루고 있는데요.

탐험적 테스팅에서는 엑셀에 적어놓은 케이스들을 기계적으로 눌러보거나, 코드로 짜놓은 유닛 테스트가 100% 커버리지를 달성하는지에 집중하지 않습니다. 그보다는 구체적인 목적과 수단을 가지고 다양한 경로와 상황을 ‘탐색’합니다.

실제 회원가입 과정을 탐색하는 예시

저는 기획, 디자인을 포함해서 개발팀 전체에 탐색적 테스팅을 소개하는 시간을 가졌습니다.

그 뒤에 기획자 님이랑 실제로 탐색을 해보기로 했습니다. 첫 실험 대상은… “모바일에서 네이버로 가입이 가능한지?” 였습니다.

저희 신규 서비스는 이메일로 회원가입을 하는데요. 저희는 기존에 케이스 기반의 테스트를 했습니다. 미리 정의한 케이스대로 “이메일은 입력이 잘 되는지?” “다음 단계로 잘 넘어가지는지?” “메일은 잘 오는지?” 등을 테스트했지요.

하지만 생각해보면 이런 케이스가 모호하다는 걸 알 수 있습니다. 예를 들어 “이메일”은 어떤 이메일일까요? 저는 Gmail 계정으로 가입해본 적은 있었지만, 네이버로는 안 해봤습니다.

또 신규 서비스는 웹이라, 데스크탑에서도 모바일에서도 접속할 수 있는데요. 모바일에서 회원가입을 할 때 불편한 점은 없는지도 궁금했습니다.

Gmail로 가입할 때에는 모든 게 순조로웠습니다. 제 이메일 주소를 입력하니, 인증코드가 메일로 왔고, 상단에 알림이 떴습니다. 알림을 클릭하니 인증코드를 ‘미리보기’로 볼 수 있었죠. 인증코드를 그대로 입력하니 회원가입이 순식간에 끝났습니다.

문제는 네이버였습니다! 네이버 이메일을 입력했더니 알림이 오지 않았습니다. 제가 네이버 알림을 꺼둔 것도 아니었는데 말이죠.

저는 저희 사이트에서 홈으로 빠져나왔습니다. 네이버 앱을 켜고, 메일함에 들어갔습니다. 메일함에서 인증 메일을 찾아서 열어보고 인증코드를 확인한 뒤, 저희 서비스로 돌아왔죠!

…그런데 사이트가 휴면 상태에 들어갔는지 새로고침이 되면서 사이트를 다시 불러오는 게 아니겠어요! 제가 입력한 이메일도 날아가고 회원가입을 처음부터 다시 시작해야 했습니다.

그리고 기획자 님 핸드폰으로 똑같이 해보았는데요. 이번에는 문제가 없었습니다. 메일을 열고 돌아와도 사이트는 그대로 있었고, 회원가입을 계속 진행할 수 있었죠.

그러면 왜 제 핸드폰만 안 되는 것인지… 빠르게 메일을 보고 오기도 하고요. 핸드폰을 재부팅도 해봤습니다. 여러 번 다시 시도했지만 제 핸드폰에서는 회원가입을 완료할 수 없었습니다.

하지만 결국 문제의 원인을 찾아냈습니다! 핸드폰에 여러 앱이 켜져 있으니 메모리가 부족했습니다. 브라우저가 백그라운드 모드가 되었을 때, 저희 사이트를 휴면 상태로 만들어서 메모리를 절약했죠. 핸드폰을 재부팅해도 기존에 켜져 있던 앱들을 다시 복구시켜주었기 때문에… 메모리는 여전히 부족했습니다. 실행 중인 앱을 모두 종료시켜주고 나서야 회원가입을 완료할 수 있었습니다.

저희 서비스는 해외 고객도 많은데요. 해외에는 한국보다 성능이 떨어지는 스마트폰을 사용하는 고객도 많으니, 비슷한 이슈를 겪는 사용자가 생각보다 많을지도 모릅니다.

저희는 그래서 회원가입 도중에 사이트를 벗어났다가 돌아와도, 회원가입이 진행 중인 상태를 영속(Persist)할 수 있도록 하는 기능을 논의했습니다.

철저한 계획 vs 자주 학습하기

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

• 공정과 도구보다 개인과 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협력을
• 계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

애자일 선언문

정리해봅시다. 우리가 새로운 걸 시도할 때… 처음 만든 요구사항과 구현은 불완전하고 놓치는 게 많습니다. 일찍 문제를 탐색하고 발견하고 학습해야 더 큰 문제로 번지기 전에 문제를 해결할 수 있습니다.

이러면 우리는 철저하게 준비하고 계획해야 한다는 환상에 빠지기 쉽습니다. 하지만 세상은 변하고, 실제로 해보지 않고 상상만 해서는 깨닫지 못하는 것도 많습니다. 즉 실제로 실험해보고 변화에 대응하는 게 중요합니다.

그러면 이 역설?이 어떻게 조화될 수 있을까요? 그 답은 짧은 반복 주기(Iteration)입니다.

• 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
• 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라. 애자일 선언 이면의 원칙 중에서

2주 전후의 짧은 주기로 기획-개발-테스트-배포 의 사이클이 돌아가야 합니다. 중요한 건 전체 사이클을 한 바퀴 도는 겁니다.

다들 애자일이 좋다고 하니까. 애자일을 한다고 그럽니다. 그래서 다들 칸반 보드를 만들고 2주 스프린트를 한다고 하지요.

하지만 그렇게 구색만 맞추고 실제로는 폭포수 개발을 하는 경우가 많습니다.

2주 스프린트로 개발한다는데 2주마다 기획-배포-테스트의 사이클을 도는 게 아니라, 4주 동안 기획 스프린트를 하며 철저히 준비하고, 또 4주 동안 개발 스프린트를 두 번 하고, 마지막 2주는 QA 스프린트라는 식으로 사이클을 크게 만들기도 합니다.

과거로 돌아가려 하고, 출시 전에 몇 주 씩 QA를 하려 합니다. 많은 팀이 배포 전에 별도에 QA기간을 두고, 개발 중에는 테스트를 진지하게 하지 않습니다. “QA 때 하죠”라는 말로 버그는 방치되고 QA기간으로 미뤄집니다.

기획에 문제가 우르르 발견되면 기획과 준비 기간을 늘리려 합니다. 1달, 2달 넘게 기획을 철저하게 검토하면 예상치 못한 문제를 모두 발견하게 될 거라 착각합니다.

아니 이게 애자일이 아니었단 말이야? 그게 왜 문제지?하는 분도 계실지 모르겠는데요.

보통 초기에 완벽한 기획도 구현도 불가능합니다. 우리가 모르는 분야에서 시작하니까요! TDD를 한다고 해도 처음부터 완벽한 테스트 케이스를 만들 수가 없습니다. 초반부터 테스트를 한다고 하면 개발을 시작하기도 전에 테스트 케이스를 수 백 개씩 작성하고 시작해야 한다고 오해하는 경우도 생기지요.

그러면 우리는 잘못된 요구사항과 기획서를 들고, 프로젝트가 진행될 수록 뒤통수를 맞게 됩니다. 뒤늦게 버그를 밟게 만들고요. 버그가 백엔드에서 난 건지, 프런트에서 난 건지… 버그를 재현하는 케이스를 만들고, 스크린샷과 영상을 찍고, 티켓을 만들고, 작업자를 할당하고, 브랜치를 만들고, PR을 보내고, 다시 리뷰하고, 기존의 에러가 재발되지 않았는지 확인하는 오버헤드를 만듭니다.

분명 철저하게 준비하고 검토했는데도 말이죠!

더 심각한 문제는… 문제가 이미 널리 퍼진 뒤라는 겁니다. 처음 잘못 알고 있던 실수를 모든 페이지에서 복사 붙여넣기 하며 반복했기 때문이죠. 한 페이지를 고쳐도 그 후에 만든 페이지에는 에러가 남아 있고, 다시 또 티켓을 만들게 됩니다.

하지만 2주마다 테스트까지 했다면 어땠을까요? 우리는 더 자주 배우고, 다음 스프린트 때에는 같은 실수를 반복하지 않을 겁니다. 기획자는 상상 속의 요구사항 기획서가 아니라 실제로 동작하는 프로토타입을 사용해보면서, 놓치고 있던 사실을 일찍 발견합니다.

“앗 이런 문제가 있었네요. 다른 개발에 고칠 수 있을까요?”를 일찍, 자주 하게 될 겁니다. 학습이 빠르게 일어나는 거죠.

철저한 준비나 뒤늦은 테스트로 에러를 없앨 수는 없습니다. 그보다는 ‘자주’ 학습하고 놀라야 합니다. 애초에 프로세스를 개선하는 싸이클을 돌아야 합니다. 근본적인 원인을 해결하면 애초에 에러가 많이 생기지 않을 겁니다.

에러의 패턴 분석하기

문제는 그 다음이었습니다. 저희는 다양한 상황에서 탐색적 테스팅을 진행했는데요. 그 결과는… 처음에 이야기했던 것처럼 저희가 생각하지 못했던 이슈들을 우르르 발견했습니다.

문제를 잔뜩 발견하면 우리는 모든 걸 고치려 하기 쉽습니다. 하지만 근본적인 원인을 해결하지 않으면 문제는 반복되고요. 문제 하나를 고쳐도 2개가 더 나오게 됩니다.

이런 때에는 잠시 뒤로 물러서서 이슈가 나온 에러들의 큰 그림을 살펴볼 필요가 있습니다.

모바일… 우리가 놓치고 있던 맹점

저희 팀은 QA나 개발 중에 나온 이슈들을 지라로 관리하는데요. 지라에 끝없이 이슈가 쌓이고 있던 무렵. 저는 어떤 패턴이 있는지 궁금했습니다. 그래서 하나씩 살펴보면서 비슷한 것들끼리 묶고, 범주화를 해봤습니다.

그러자 패턴이 하나 둘씩 보이기 시작했습니다.

• 데스크탑에서는 여러 창을 한 번에 띄워두기 쉽지만, 모바일은 화면이 좁아서 한 번에 하나의 앱만 볼 수 있습니다. 그래서 앞서 이야기했던 회원가입이 불가능한 문제가 생겼습니다.
• 모바일 사파리에서 vh는 주소창을 포함한 크기입니다. 그래서 주소창이 있을 때에는 페이지 하단에 있는 요소가 보이지 않았습니다.
• 모바일 화면에서 키보드가 올라오면 화면을 덮습니다. 그래서 ‘로그인하기’나 ‘구매하기’처럼 핵심적인 버튼이 화면 ‘아래’에 있으면 키보드에 가려져서 터치할 수 없게 됩니다.

이렇듯 모바일, 그리고 아이폰이나 사파리에 특수한 이슈들이 꽤 있었습니다! (그 외에도 몇 가지 범주를 더 발견했습니다)

그러면 프로그래머들은 왜 이런 이슈들을 미리 알아차리고 예방하지 못했을까요? 어떻게 해야 뼈 아픈 교훈을 새기고 다음부터 이런 일이 없게 할 수 있을까요?

테스트의 비용 줄이기

프론트엔드 개발자들은 보통 화면을 보면서 개발을 합니다. 요즘은 HMR이 발달해서, 코드를 수정하면 바로 결과를 확인할 수 있죠. 그러다보니 테스트를 짜기보다는 눈으로 보는 걸 더 좋아합니다.

문제는 그 화면이 웹 개발자들에게는 보통 데스크탑이라는 것이었습니다. 코딩은 컴퓨터에서 하지 폰에서 하지 않으니까요.

핸드폰으로 개발 중인 사이트를 열려면 여러모로 불편합니다. 모바일에는 개발자 도구도 없고요. 로컬호스트 개발 서버에 접속하기도 귀찮습니다. USB를 핸드폰에 연결한 뒤에 chrome://inspect#devices 같은 걸 이용해서 포트포워딩을 해주거나 하는 번거로운 과정이 필요하죠.

그러다보니 저희 웹 개발자들은 모바일을 본의 아니게 등한시하게 되었습니다!

이를 더 일반화하자면, 원래 사람은 귀찮은 일은 잘 안 합니다. 그게 중요한 걸 몰라서 그런 게 아니고요. 비용이 크니까 그렇습니다.

그러면 어떻게 해야할까요? 비용을 줄이고 쉽게 만들어야 합니다.

예를 들어 저희는 Vercel을 이용해서, github에 push를 할 때마다 preview 배포를 하고 URL도 생성됩니다. 배포된 URL이기 때문에 쉽게 핸드폰으로도 접속해서 테스트할 수 있지요.

더 나아가서 앞서 이야기한 크롬 데브툴도 요즘은 USB가 아니라 와이파이 등을 이용해 연결할 수도 있습니다. 회사 내에서는 모두가 같은 공유기를 사용하기 때문에 192 로 시작하는 내부 ip를 이용해서 개발 중인 데브 서버에 바로 접속할 수도 있었습니다!

이렇게 개발에 맹점을 만드는 구조적인 문제를 지속적으로 찾아내고, 개선한다면… 테스트는 점점 쉬워질 수 있을 겁니다.

우리에게 필요한 적정기술부터 시작하기

이제 좋은 테스트 도구나 자동화에 대해서도 이제 생각해볼만 합니다.

저희가 모르는 문제에 대해 잘 탐색하고 배웠다면, 이를 명확하게 표현하고 우리가 아는 것으로 만들 필요가 있습니다. 우리가 이미 알고 있고 정확하게 정의한 명세를 검증하는 일은 자동화 테스트나 타입이 아주 잘 합니다.

더 많은 경우를 빠르게 테스트하기

먼저 수동 테스트보다 다양하고 치밀한 케이스들을 테스트할 수 있다는 겁니다. 복사 붙여넣기하고 조금만 바꾸면, 새로운 케이스를 추가하기 쉽기 때문이죠.

수 많은 조합, 경우의 수가 수 백 가지라면 하나하나 손으로 테스트하는 건 지루하고 힘든 일이 될 겁니다. 특히 실제 DB에 값을 넣어보거나, 결제를 하거나 배송을 해야 하는 로직들이라면 더욱 그렇죠.

정말 그런 수동 테스트를 다 하게 될까요? 사람은 귀찮은 일은 안 하려 합니다. 보통은 몇 가지만 테스트해보고 잘 될 거라고 넘겨짚는 경우가 많고요.

실제로 undefined일 수 있는 optional한 값을 받는 단순한 로직이 있었습니다. 저는 이게 어떻게 작동하는지 궁금해서 값이 있는 경우와 없는 경우를 다 넣어봤는데요. 아니나 다를까! 로직의 if문을 잘못 써서 오류가 있었습니다. 코드 리뷰도 통과하고 QA에서도 별말 없었던 로직이었는데 말이죠.

전부 수동 테스트 하더라도 누군가는 1200개의 케이스가 적힌 엑셀 파일을 보며 고통스러운 야근을 하게 될 거에요. (이게 현실적으로 보인다면 실제 사례이기 때문입니다.)

수동 테스트는 창의적으로 우리가 모르는 걸 탐색하고 사용성 문제를 발견하는데에는 효과적입니다. 하지만 기존에 잘 돌아가던 게 여전히 잘 돌아가는지 확인하는 복잡하고 지루한 회귀 테스트에는 적합하지 않습니다.

회귀 에러 방지

회귀 테스트? 이 말을 처음 들어보는 분도 계실텐데요.

에러를 고치거나 기능을 수정하다 보면 기존에 잘 돌아가던 로직을 망가트리기도 합니다. 이미 고쳤던 에러가 재발하기도 하고요. 특히 기능 자체에 근본적인 문제가 있어서 재작성하거나 수정하는 경우에는 기존에 잘 되던 동작은 유지하면서 새로운 동작을 추가해야 하는데요… 이렇듯 이미 작성한 기능이 기대대로 잘 돌아가고 있는지 검증하는 테스트를 회귀(regression) 테스트라 합니다.

자동화 테스트는 개발 도중에도 지속적으로 다시 돌릴 수 있고, 통합하거나 배포하기 전에도 자동으로 다시 돌아갑니다. 저는 QA에서 새로운 이슈가 나올 때마다 테스트를 추가하면서, 기존 테스트와 새로운 테스트를 모두 만족시키는 새로운 구현을 개발하는 식으로 작업하고 있어요.

이는 심지어 스타일에도 가능합니다. 예를 들어 기존의 스타일에 반응형 문제가 있어서, flex나 grid로 전환해야 하는 부분들이 있었는데요. 문제는 정확하게 맞춰둔 간격이나 크기가 실수로 깨질 수 있다는 것이었습니다.

다행히 playwright에는 스크린샷을 찍어서 비교해주는 기능이 있습니다. 저는 이 기능을 이용해서 수정하기 전의 스크린샷을 찍어놓고, 수정한 뒤의 스크린샷과 비교했습니다. 차이점을 한 눈에 보면서 정확하게 간격을 맞출 수 있었죠.

커버리지 100%가 아니라, 중요하고 가치있는 곳에 집중합시다

타입스크립트를 쓰고 테스트 커버리지 100%로 테스트한 코드에는 버그가 없을까요? 당연하지만 에러가 발생합니다. 그것도 아주 많이 납니다!

타입과 테스트는 우리가 알고 있고, 명시한 케이스만 테스트합니다. 100% 커버리지 같은 수치에 집착하다가… 중요한 경계값과 암묵적인 가정들은 테스트되지 않은 채로 방치된 경우도 많습니다.

예를 들어 앞에서 이야기했던 모바일에서 발생한 이슈들을 생각해봅시다. 유닛 테스트나 컴포넌트 테스트를 달아도 이런 문제들을 발견하기는 어려울 것입니다.

테스트 자동화를 가장 마지막에 이야기한 이유이기도 합니다. 자동화 테스트는 그저 수 많은 방법 중에 하나인데도 사람들에게 종교처럼 여기는 면이 있습니다. 하지만 테스트를 전도한다는 말은 우스겟소리이지, 자동화에 집착하면 유지보수 비용은 크고 이득은 별로 없는 테스트를 만드는데 시간을 낭비하게 됩니다.

물론 대부분은 (자동화) 테스트가 지나치게 많기 보다는, 너무 덜 하는 경우가 많습니다만. 그렇기에 테스트를 처음 도입하기 시작하는 팀일 수록 중요한 부분에 집중해야 합니다. 명확한 목적과 이익을 생각하고, 비용과 저울질해보세요.

예를 들어 저희 팀에서는 여러 경우의 수가 많고 복잡한 로직에서 에러가 많이 발생하고 있습니다. 이런 로직은 디비에 가짜 데이터를 넣고 직접 눌러보는 과정도 고통스럽습니다. 유닛 테스트를 하면 단순하고 비용은 적게 드는데 이익은 크기 때문에 테스트를 만듭니다. 실수한 부분이 있어도 빠르게 피드백을 받을 수 있어서, 금방 수정할 수 있고요. 코드 리뷰를 받을 때 팀원들이 새로운 테스트 케이스를 제안해주기도 합니다.

반면에 데이터를 가져와서 그저 보여주기만 하는 부분들은 번역이나 포매팅, api 연결을 위주로 E2E 테스트를 합니다. 모킹은 결제나 이메일 등을 제외하면 되도록 하지 않습니다. E2E는 백엔드까지 전구간을 테스트할 수 있는데, 모킹을 하게 되면 백엔드에서 API 계약을 깨트려서 사용자에게 UI가 깨지는 경우를 놓치게 됩니다. 예를 들어 특정 페이지만 1970년도로 나오는 에러가 있었는데요. 서버에서 다른 페이지는 밀리세컨드로 날짜를 보내주는데, 이 페이지만 초 단위로 데이터를 보내줘서 생긴 문제였지요.

타입이나 린트 등으로 정적 분석할 수 있는 부분도 생각보다 많습니다. 예를 들어 과거에는 번역을 빠트린 부분을 코드 리뷰로 지적했었는데, 이제는 eslint의 no-literal-string 룰을 이용해서 잡아내고 있습니다.

그 외에도 자동화하기 어려운 부분들을 명확히 식별하고, 저희가 잘 모르고 탐색적 테스팅이 필요한 부분들을 의사결정합니다.

여러분의 팀은 어떠신가요? 세상의 모든 팀은 다른 상황에 놓여 있고, 다른 문제를 풉니다. 특정 도구에 집착하지 않고, 문제와 상황에 맞는 적정 기술을 이용한다면… 고통 받는 일은 줄어들고 더 행복하게 개발을 할 수 있으시리라 생각합니다.

결론: 학습을 개선해나가기

최근에 팀에 새로운 동료 분이 오셨습니다. 같이 TDD로 한 단계씩 그림도 그리고 기능도 정의하면서 개발하니, 전보다 이해가 잘 된다고 하시더군요. 테스트는 온보딩에도 유용한 학습 도구였던 셈입니다.

앞으로 1달 뒤, 2달 뒤에 저희 팀은 어떤 모습일지 상상해봅니다. (이 글을 읽고 계신 여러분이 미래에 제 동료가 되실지도 모르지요?) 저희 팀은 어떻게 변해있을까요? 저는 그 미래를 위해 어떤 노력을 해야 할까요?

우리는 더 행복하게 노동할 권리가 있습니다. 학습을 뒤로 미루지 말고, 매일 배우고 개선합시다. 고통을 참지 말고, 자신을 돌보세요.

우리는 개발이 단순히 뭔가를 열심히 만드는 과정이라 착각합니다. 2배의 시간을 들이면 2배 더 많이 생산할 수 있다는 식으로 말이죠. 이런 사고 방식 아래에서는 더 열심히 일하고 야근하는 것 밖에 방법이 없을 것 같습니다. 아니면 나 대신 책임을 져줄 전문가를 뽑아서 맡기거나요. 학습을 뒤로 미룰 수록, 문제는 더 많이 생기고 일은 밀리게 되지요.

하지만 인간은 배우고 변합니다. 매일 “어라?”하고 깜짝 놀라고 새로운 시도를 하면서 말이죠.

테스트는 그렇게 깜짝 놀라게 도와주는 학습의 도구입니다. 전문 테스터가 있다고 해도, 학습은 모두의 책임입니다. 세상에 완벽한 팀은 없습니다. 그럼에도 우리의 문제를 인지하고, 나아갈 방향이 무엇인지 생각할 수는 있습니다. 변화는 오랜 시간이 걸리는 일이라고 하지만, 지금 당장 이 상황에서 할 수 있는 일도 많이 있습니다.

오늘 이야기해드린 여러 사례와 방법론도 그러한 시행착오의 기록입니다. 앞으로도 할 일이 많습니다. 할 이야기도 많을 것 같습니다.