Testability vs. Automatability: 대부분의 자동화 시도가 시작되기 전에 실패하는 이유 - Part 2

Source: Dev.to

읽기 파트 1.

자동화가 실패할 때, 보통 설계 문제

자동화가 일정 기간 적용된 후, 팀은 패턴을 눈치채기 시작합니다. 특정 테스트는 간헐적으로 실패하고, 다른 테스트는 통과하기 위해 재시도가 필요합니다. 일부 실패는 로컬에서 다시 실행하면 사라지지만 파이프라인에서는 다시 나타납니다. 시간이 지나면서 테스트 스위트는 엔지니어들이 신뢰하기보다는 우회하도록 배우는 대상이 됩니다.

이 단계에서 질문이 불가피하게 떠오릅니다: 우리의 자동화가 잘못된 것인가, 아니면 시스템 자체에 문제가 있는가?

그 질문에 올바르게 답하는 것은 지속 가능한 자동화를 구축하는 데 가장 중요한 역량 중 하나입니다. 많은 팀이 경험 부족 때문이 아니라, 자동화 실패가 설계 결함보다 눈에 더 잘 띄기 때문에 잘못 판단합니다.

Why Automation Takes the Blame

자동화는 공개된 환경에서 동작합니다. 자동화가 실패하면 파이프라인이 빨갛게 표시되고, 알림이 발생하며, 진행이 중단됩니다. 반면 애플리케이션 설계 문제는 종종 눈에 보이지 않습니다. 이러한 문제는 모호함, 숨겨진 결합, 혹은 불명확한 상태로 나타나며, 사람들은 이를 의식하지 못하고 적응합니다.

자동화 테스트가 시간 초과되거나 요소를 찾지 못하거나 일관되지 않은 결과를 내면, 실패 메시지는 바로 테스트 자체를 가리킵니다. 시스템 자체는 침묵합니다. 시간이 지나면서 이는 잘못된 이야기를 만들게 됩니다: 자동화는 취약하고, 느리며, 신뢰할 수 없다는 것입니다.

실제로 자동화는 이미 불확실했던 동작을 드러내는 경우가 많습니다. 단지 그것을 일관되게, 편견 없이 보여줄 뿐입니다.

핵심 진단 질문

자동화 문제와 설계 문제를 구분하는 유용한 방법은 간단한 질문을 하는 것입니다:

인간 테스터가 이 실패를 여러 번 테스트를 다시 실행하지 않고도 명확하고 일관되게 설명할 수 있을까요?

답이 아니오라면, 그 문제는 거의 자동화와 관련이 없습니다.

인간이 페이지를 새로 고치거나, 동작을 반복하거나, “그냥 다시 시도해 보세요”라고 해야 할 경우, 이는 시스템에 누락된 신호를 보완하고 있는 것입니다. 자동화는 그런 가정을 할 수 없으며, 시스템이 명시적으로 제공해야 합니다.

자동화 실패로 위장된 설계 모호성

많은 자동화 문제는 시스템 동작을 흐리게 만드는 설계 결정에서 비롯됩니다. 예측할 수 없게 다시 렌더링되는 사용자 인터페이스, 상태가 아니라 타이밍에 의존하는 워크플로, 결과를 시각적으로만 노출하는 시스템은 자동화가 추측하도록 강요합니다.

이러한 추측은 깨지기 쉬운 셀렉터, 복잡한 대기 조건, 재시도 형태로 나타납니다. 이러한 기법으로 테스트가 통과될 수는 있지만, 근본적인 문제를 가립니다: 시스템이 자신이 무엇을 하고 있는지 명확히 전달하지 못한다는 점입니다.

테스트가 “요소를 찾을 수 없음”이라는 오류로 실패할 때, 실제 문제는 시스템이 아직 해당 요소가 존재해야 함을 표시하지 않았기 때문인 경우가 많습니다. 자동화가 조급하다고 비난받지만, 실제로는 시스템이 침묵하고 있을 뿐입니다.

진정한 자동화 문제의 모습

모든 실패가 설계와 관련된 것은 아닙니다. 실제 자동화 문제도 존재하며, 이를 인식하는 것이 중요합니다.

자동화 문제의 전형적인 특징:

• 동일한 위치에서 결정적으로 실패한다
• 더 나은 도구나 구현으로 크게 개선된다
• 수동 테스트 동작에 영향을 주지 않는다
• 시나리오 전반에 퍼지기보다 테스트 코드에 국한된다

예시로는 부실한 셀렉터 전략, 자동화 프레임워크 오용, 혹은 하위 수준 테스트로 충분한 상황에서 엔드‑투‑엔드 테스트에 과도하게 의존하는 경우가 있습니다. 이러한 문제는 실제이며, 시간이 지남에 따라 해결이 비교적 쉽고 비용도 적게 듭니다.

반면 설계 문제는 도구 변경에 저항하고 프레임워크와 무관하게 다시 나타납니다.

The Cost of Misdiagnosis

디자인 문제를 자동화 문제로 잘못 분류하면, 팀은 시스템을 개선하기보다 테스트를 강화하는 방향으로 대응합니다. 재시도 로직을 추가하고, 타임아웃을 늘리며, 추상화 레이어를 쌓아갑니다. 테스트 스위트는 점점 느려지고 이해하기 어려워지는 반면, 시스템은 여전히 이전과 마찬가지로 불투명합니다.

결국 자동화 스위트가 취약해지는 이유는 테스트 자체가 잘못 작성되었기 때문이 아니라, 불명확한 동작을 보완하려는 부담을 떠안고 있기 때문입니다. 바로 이 시점에서 팀은 자동화의 가치를 전반적으로 의심하기 시작합니다.

자동화와 싸우기보다 듣기

자동화는 설계상의 약점이 대규모로 드러나는 첫 번째 지점인 경우가 많습니다. 자동화는 시스템과 끊임없이 상호작용하며 모호함을 용납하지 않습니다. 이 피드백을 억누르는 대신, 고성능 팀은 이를 신호로 간주합니다.

테스트를 작성하기 어렵고, 안정화하기 어렵거나 디버깅하기 어려울 때, 그들은 시스템이 무엇을 전달하지 못하고 있는지를 묻습니다. 누락된 상태 신호, 불분명한 경계, 숨겨진 의존성을 찾습니다. 이러한 문제를 해결하면 자동화가 개선되고 일반적으로 프로덕션 동작도 개선됩니다.

Shifting the Conversation

가장 생산적인 팀은 대화를 “이 테스트를 어떻게 고칠까?”에서 “시스템이 명시하지 않는 것이 무엇인가?”로 옮깁니다.

이러한 전환은 실패를 처리하는 방식을 바꿉니다. 자동화 실패는 좌절의 원천이 아니라 시스템 명확성을 향상시킬 기회가 됩니다. 시간이 지나면서 자동화는 테스트가 더 복잡해졌기 때문이 아니라 시스템 자체가 더 이해하기 쉬워졌기 때문에 더 신뢰할 수 있게 됩니다.

앞으로의 전망

다음 글에서는 자동화 불안정성의 가장 흔한 원인 중 하나인 느리고 비동기적인 사용자 인터페이스에 대해 살펴보겠습니다. Part 1 을 읽어보세요.

성능 문제가 자주 오진되는 이유, 대기가 전략이 될 수 없는 이유, 그리고 신뢰할 수 있는 자동화를 위한 핵심은 속도가 아니라 관찰 가능성이라는 점을 탐구할 것입니다.

자동화 스위트가 시스템에 대한 불편한 진실을 드러내고 있다면, 올바른 방향으로 가고 있는 것입니다.