🧭 다사다난했던 릴리즈 회고

💡 흔들리는 일정 속에서, 내가 지켜낸 것들

신입이자 1인 QA로서 몇 번의 릴리즈를 겪다 보니, 이제는 단순히 "버그를 얼마나 잡았는가"보다 "이 상황에서 어떤 리스크를 어떻게 판단했는가"가 훨씬 더 크게 남는다. 이번 릴리즈는 그런 감각이 유난히 선명해진 릴리즈였다.
 
일정 변동 가능성은 어느 정도 예상하고 있었지만, 진짜 힘들었던 건 지연 자체보다 지연이 계속 다른 형태로 반복됐다는 점이었다. 릴리즈 직전까지 일정이 여러 차례 변경되었고, 배포 시점에서도 예기치 못한 이슈로 재조정이 반복되었다. 그 과정에서 장시간 대기와 긴장 상태가 이어졌고, 체력과 멘탈 모두 큰 소모를 느꼈다.
 
이번 릴리즈를 통해 다시 한 번 체감한 건, QA가 일정의 가장 후단에 위치한 구조상, 일정 변동의 영향을 직접적으로 받을 수밖에 없다는 걸 체감했다. 이 경험 이후로 계속 머릿속에 남은 질문은 하나였다. "일정이 계속 밀릴 때, QA는 어떻게 대응하는 게 최선일까?"
 

💡 사소한 디테일은 왜 늘 마지막에 남을까

이번 릴리즈에서는 디자인 리뷰 단계부터 Shift Left Testing을 의식적으로 더 적극적으로 시도했다. 초기 단계에서 최대한 자세히 듣고, 질문을 많이 하면서 나중에 터질 수 있는 문제를 미리 줄여보려 했다.
 
실제로 도움이 된 부분도 분명히 있었다. 그런데 이 과정에서 다시 한 번 강하게 느낀 게 있다. 사실 이전 릴리즈까지는 기획서에 Annotation 자체가 거의 없는 상태였다. Figma 기획서는 UI 위주로만 정리되어 있었고, 세부 기획은 댓글로 흩어져 있거나 구두로 전달되는 경우가 대부분이었다.
 
처음 이 구조를 접했을 때, QA 관점에서 놓치기 쉬운 부분이 있었다. QA 입장에서는 UI만 보고 테스트 케이스를 작성할 수가 없다.

• 버튼이 언제 활성화되는지
• 버튼을 누르면 어떤 화면이 노출되는지
• 어떤 조건에서 Validation이 걸리는지

이런 것들은 전부 기획의 일부인데, 그 핵심 정보들이 문서가 아니라 댓글과 구두 설명에 흩어져 있었다.
 
그러다 보니 자연스럽게 문제가 생겼다. 누군가는 이 내용을 알고 있고, 누군가는 모르고 있고, 결과적으로 다들 뭔가를 빠뜨리는 상황이 반복됐다. "이걸 왜 빠뜨리지?" 싶을 정도의 디테일들이 계속 누락됐다. 그래서 입사 후 첫 릴리즈를 마친 뒤, 이런 방식의 기획 전달에는 분명한 한계가 있다고 느꼈고 QA 입장에서 그 문제를 그대로 전달했다.
 
그 결과 이번 릴리즈부터는 기획서에 Annotation이 추가되었고, 어떤 부분이 수정되었는지를 확인할 수 있도록 업데이트 로그도 함께 도입되었다. 이 덕분에 변경 사항이 댓글에 흩어지지 않고, "언제, 어떤 부분이, 왜 바뀌었는지"를 QA와 개발자가 동일한 기준으로 확인할 수 있게 되었고, 기획 전달 측면에서는 분명히 한 단계 개선되었다고 느꼈다.
 
그럼에도 불구하고, 또 한 번 느끼게 된 게 있다. 아주 사소한 디테일은, Annotation과 업데이트 로그가 있어도 여전히 빠진다는 점이었다. 개발자도, QA도, 기획자도 큰 흐름은 잘 챙기는데, 버튼 하나의 조건, 화면 전환 타이밍, 예외 케이스 같은 정말 디테일한 부분은 여전히 놓치게 된다.
 
그래서 지금은 이런 고민으로 이어지고 있다. 이건 단순히 "기록이 부족해서" 생기는 문제일까? 아니면

• 구조적인 문제일까,
• 프로세스의 문제일까,
• 아니면 이 정도 누락은 어느 조직에서나 발생하는 걸까?

아직 정답은 모르겠다.
 

💡 테스트 케이스 "기능 단위"만으로는 부족했다

TC는 여전히 어렵다. 다만 이번 릴리즈를 통해 확실하게 체감한 게 하나 있었다.
 
같은 기능인데도 단일 활동에서는 정상적으로 동작하는데, 연계 활동에서는 깨지는 케이스가 있었다. 이 경험을 하면서 느낀 건, 기능 단위 테스트는 결국 고립된 상태에서의 정상 동작만 검증할 수 있다는 점이었다. 기능 하나만 떼어 놓고 보면 문제없지만, 이전 활동의 상태나 흐름이 이어지는 순간 예상치 못한 문제가 발생했다.
 
그래서 자연스럽게 이런 결론에 도달했다.

기능 단위 테스트만으로는 부족하고, 실제 사용 흐름을 기준으로 한 사용 시나리오 단위 테스트가 반드시 필요하다.

 
또 하나 크게 느낀 건, TC를 나누는 기준은 "화면이 같은가/다른가"가 아니라 "같은 컴포넌트를 사용하는가"가 훨씬 중요하다는 점이었다. 겉보기엔 같은 화면인데 서로 다른 컴포넌트를 사용해 한쪽만 수정되고 다른 쪽은 그대로 남아 있는 경우도 있었고, 반대로 완전히 다른 화면인데 내부적으로는 같은 컴포넌트를 공유해 한쪽 수정이 다른 화면까지 영향을 주는 경우도 있었다. 그래서 TC를 작성할 때도 "이 화면이 비슷해 보이냐"보다 "같은 구현 단위를 공유하느냐"를 먼저 확인하게 되었고, 그 기준에 따라 TC를 세분화할지, 묶을지를 판단하게 되었다.
 

💡 시간이 부족해지면 우선순위도 무너진다

이번 릴리즈에서는 시간 부족으로 인해 우선순위 판단이 매우 어려워졌던 순간도 있었다.
 
생성해둔 티켓들을 보면 하나같이 기획대로 구현되지 않았고, 사용자 입장에서 충분히 문제가 될 수 있는 상태였다. 이론적으로만 보면 전부 수정되어야 하는 이슈들이었다. 하지만 일정이 계속 밀리고 시간이 촉박해지면서 현실적으로는 모든 걸 다 잡고 갈 수 없는 상황이 되었고, 결국 정말 급한 것들부터 처리하는 방향으로 이미 생성해둔 티켓들의 우선순위를 다시 조정하게 되었다.
 
그 과정에서 계속 이런 고민이 들었다. "어차피 다 고쳐야 하는 이슈들인데, 내가 이 중에서 어떤 걸 더 급하다고 판단하는 게 맞을까?" 지금 돌이켜보면, 이 고민은 판단을 잘못했느냐의 문제가 아니라 우선순위 판단을 QA가 중심적으로 맡게 되는 구조 자체의 한계에 가까웠던 것 같다. 그래서 오히려 이런 생각에 이르게 되었다.

우선순위는 QA 혼자 정하는 ‘정답’이 아니라 팀이 함께 합의해서 만들어가는 '결과'여야 한다.

 

💡 CS는 "일회성 대응"이 아니라 "재사용 가능한 지식"이었다

이번 릴리즈에서는 CS 이슈도 꽤 인상 깊었다. 특히 외부 링크 리다이렉션 이슈는 내부 로직 오류라기보다는, 외부 네트워크나 보안 정책(프록시/방화벽)과 관련된 이슈일 가능성이 컸고, 실제로 에러 메시지에서도 그 힌트를 명확하게 확인할 수 있었다.
 
CS를 처리하다 보면 QA가 단순히 내용을 전달하는 역할에 머무르지 않고, 직접 원인을 파악하고 해결해야 하는 순간이 생각보다 자주 찾아온다. 이번 릴리즈에서는 자주 반복되는 CS에 대해 개발자에게 해결 방법을 전달받고, 그 과정을 상세히 기록해두는 데 특히 신경을 많이 썼다. 처음엔 "이런 것까지 기록해야 하나?" 싶을 정도로 세세하게 남겼지만, 지금 돌이켜보면 그 기록들이 엄청난 자산이 되었다.
 
유사한 CS가 다시 들어왔을 때는 필요한 정보들을 확인하고, 사전에 정리해 둔 절차에 따라 대응하면서, 개발자에게 추가 요청을 하지 않아도 QA 차원에서 바로 해결 가능한 케이스가 눈에 띄게 늘었다. 이 경험을 통해 느낀 건, CS는 그때그때 처리하고 끝나는 일이 아니라 한 번 정리해두면 계속 재사용할 수 있는 지식이라는 점이었다.
 

💡 일정 지연이 만든 '붕 뜬 시간', 자동화로 써봤다

이번 릴리즈에서는 TC 작성이 끝난 뒤 개발 완료를 기다리는 동안 비교적 긴 대기 시간이 생겼고, 그 시간을 자동화 구현에 집중해서 사용해볼 수 있었다. 일정 지연이 무조건 손해는 아니고, 그 시간을 어떻게 쓰느냐에 따라 자동화, 테스트 문서 정리, 새로운 기술 학습 등으로 전환할 수 있다는 가능성을 확인했다.
 
다음부터는 일정이 밀릴 때 그냥 불안해하며 기다리기보다는, "이 시간을 어떻게 활용할지"를 더 의도적으로 설계해보고 싶다.
 

💡 마무리하며

이번 릴리즈에서 가장 크게 느낀 건, 돌아서면 수정되고, 돌아서면 잘 되던 기능이 깨지고, 돌아서면 사이드 이펙트가 발생한다.
 
이 모든 변경 이력을 머릿속에 들고 있는 건 생각보다 큰 부담이었다. 그래서 이제는 "내가 더 잘해야지"보다는, 이 구조를 어떻게 팀 차원에서 인식하고 개선할 수 있을지를 더 고민해보려 한다. 물론 내가 발견하지 못한 버그에 대해 내 책임이 전혀 없다고 말할 수는 없다. QA로서 놓친 부분이 분명히 있었을 것이다. 하지만 동시에, 그 모든 누락이 개인의 역량 문제만은 아니라는 생각도 들었다.
 
일정은 계속 흔들리고, 기능이 빠르게 변화하는 상황에서, 사소한 디테일부터 사용성까지 모두 챙기는 건 현실적으로 매우 어려운 상황들이 분명히 있었다. 큰 기능들조차 안정화되지 않은 상태에서, 구현이 끝나지 않은 상황에서 "왜 여기까지 못 봤을까"라고 스스로를 몰아붙이는 건 문제를 해결하는 데 크게 도움이 되지 않았다.
 
그래서 이제는 자책하기보다는, "이 환경에서 왜 이런 누락이 반복될 수밖에 없었을까", "다음에는 이 부담을 어떻게 줄일 수 있을까"를 계속해서 고민하는 쪽이 더 중요하다고 느낀다. 사소한 디테일을 놓친 건 단순히 개인의 부족함이라기보다, 그 디테일을 놓칠 수밖에 없는 구조가 있었기 때문일 수도 있다.
 
그리고 이 과정에서 또 하나 느낀 건, 이런 고민을 혼자 끌어안고 계속 스스로를 몰아붙이다 보면 장기적으로 지속 가능성을 고민하게 만드는 구조라는 점이었다. 완벽하게 하고 싶다는 성격이 때로는 나를 성장하게 만들지만, 이 환경에서는 그 완벽함이 오히려 나를 갉아먹을 수도 있겠다는 생각이 들었다. 그래서 앞으로는 쉬어야 할 때는 쉬고, 모든 걸 혼자 책임지려 하지 않고, 천천히, 자책하지 않으면서 이 구조를 어떻게 바꿀 수 있을지를 고민해보려 한다.
 
QA가 할 수 있는 역할은 모든 걸 완벽하게 막아내는 것이 아니라, 문제가 반복되는 구조를 인식하고, 가시화하고, 조금씩이라도 바꿔보려는 시도를 멈추지 않는 것이라는 생각이 들었다.