테스트 가능성 vs. 자동화 가능성: 대부분의 자동화 시도가 시작되기 전에 실패하는 이유

Source: Dev.to

테스트 자동화가 실패하는 경우는 팀이 잘못된 도구를 선택했기 때문인 경우는 드뭅니다.
자동화는 훨씬 더 일찍—종종 첫 테스트가 작성되기 전부터—시스템이 테스트되거나 자동화될 방식을 고려하지 않고 설계될 때 실패합니다.

자동화가 불안정하거나 느리거나 신뢰할 수 없게 되면, 기본적인 반응은 예측 가능합니다: 테스트를 다시 작성하고, 프레임워크를 교체하고, 재시도를 추가하거나, 안정성을 약속하는 새로운 도구를 도입하는 것입니다. 이러한 조치는 일시적으로 고통을 완화시킬 수 있지만, 실제 문제를 해결하는 경우는 거의 없습니다. 시간이 지나면서 자동화는 팀이 신뢰하기보다는 견디는 대상으로 전락합니다.

근본 원인은 보통 서로 밀접하게 연관되어 있지만 근본적으로 다른 두 개념, 즉 testability와 automatability에 대한 오해입니다.

모든 것을 바꾸는 미묘한 차이

테스트 가능성(Testability)과 자동화 가능성(Automatability)은 엔지니어링 대화에서 종종 혼용되지만, 해결하는 문제가 다릅니다.

• Testability는 시스템을 얼마나 쉽게 이해하고 진단할 수 있는가에 관한 것입니다. 테스트 가능한 시스템은 자신의 상태를 명확히 드러냅니다. 무언가가 실패했을 때, 시스템은 무엇이 일어났는지, 왜 일어났는지를 파악하도록 도와줍니다. 로그는 의미가 있고, 신호는 명확하며, 행동은 추측 없이 관찰할 수 있습니다.
• Automatability는 시스템을 기계가 얼마나 신뢰성 있게 실행할 수 있는가에 관한 것입니다. 이는 결정론, 안정성, 제어에 초점을 맞춥니다. 자동화 가능한 시스템은 자동화 환경에서도 일관된 동작을 보이며, 시간이 지나도 그 일관성을 유지합니다.

팀이 흔히 저지르는 실수는 좋은 자동화가 곧 좋은 테스트 가능성을 의미한다고 가정하는 것입니다. 실제로는 자동화가 테스트 가능성에 의존합니다. 테스트 가능성이 약하면 자동화는 복잡성으로 이를 보완하려 하고, 그 복잡성은 결국 자체 무게에 눌려 무너집니다.

자동화가 희생양이 되는 이유

자동화 테스트가 명확한 설명 없이 실패하면, 자동화가 눈에 보이는 문제로 떠오릅니다. 파이프라인이 빨간색으로 바뀌고, 릴리즈에 대한 신뢰가 떨어지며, 엔지니어는 테스트 결과에 대한 신뢰를 잃게 됩니다. 이 시점에서 자동화는 더 이상 안전망으로 인식되지 않고, 잡음으로 전락합니다.

많은 경우 간과되는 점은 이러한 실패가 원인이 아니라 증상이라는 것입니다. 테스트가 시간 초과되거나, 요소를 찾지 못하거나, 일관되지 않은 결과를 내는 경우는 시스템 자체에 내재된 더 깊은 불확실성을 반영하는 경우가 많습니다. 자동화는 그 불확실성을 수동 테스트보다 더 일찍, 더 자주 드러내는 역할을 할 뿐입니다.

사람은 모호함을 보완하는 데 뛰어납니다. 페이지를 새로 고치고, 동작을 재시도하고, 의도를 추론하며 넘어갑니다. 자동화는 그런 직관이 없습니다. 명시적인 신호, 안정적인 동작, 예측 가능한 상태 전이가 필요합니다. 이러한 요소가 부족하면 자동화는 어려움을 겪고, 그 어려움이 자동화의 탓으로 돌려집니다.

도구는 근본적인 문제를 해결하지 못한다

현대 프레임워크는 자동화를 보다 접근하기 쉽고 관대하게 만들었습니다. 대기 시간을 더 잘 처리하고, 풍부한 진단 정보를 제공하며, 보일러플레이트 코드를 줄여줍니다. 하지만 근본적인 설계 문제를 해결할 수는 없으며, 해결할 수도 없습니다.

어떤 도구도 보완할 수 없는 문제들:

• 안정적인 식별자 없이 지속적으로 다시 렌더링되는 사용자 인터페이스
• UI 이벤트 핸들러 안에 숨겨진 비즈니스 로직
• 관찰 가능한 완료 신호가 없는 비동기 워크플로우
• 결과를 프로그래밍적으로가 아니라 시각적으로만 노출하는 시스템

이러한 상황에서 도구를 바꾸면 일시적으로 마찰이 줄어들 수 있지만, 근본적인 불확실성을 바꾸지는 못합니다. 결국 같은 문제가 다른 API를 통해 다시 나타납니다.

자동화 마찰은 실패가 아니라 신호입니다

팀이 할 수 있는 가장 중요한 사고 방식 전환 중 하나는 자동화의 어려움을 테스트 실패가 아니라 시스템에 대한 피드백으로 다루는 것입니다.

테스트를 작성하기 어렵고, 안정화하기 어렵고, 디버깅하기 어려울 때, 시스템이 무언가를 알려주고 있는 것입니다. 행동이 명시적이라기보다 암시적이며, 상태가 관찰 가능하기보다는 숨겨져 있고, 제어가 의도적이라기보다 흩어져 있다는 신호입니다.

이 피드백에 귀를 기울이는 팀은 테스트뿐만 아니라 아키텍처, 진단 가능성, 운영 성숙도까지 향상시킵니다. 반면 이를 무시하는 팀은 자동화 부채를 쌓아 결국 테스트 스위트의 큰 부분을 포기하게 됩니다.

자동화가 규모화되기 전에 이것이 중요한 이유

테스트 가능성과 자동화 가능성을 오해하는 비용은 규모가 커질수록 증가합니다. 프로젝트 초기에 설계 선택이 좋지 않으면 몇 개의 테스트가 느려지는 정도에 그칠 수 있습니다. 시간이 지나면서 이는 불안정한 파이프라인, 긴 트라이에지 사이클, 그리고 깨지기 쉬운 릴리스 프로세스로 이어집니다.

이 때문에 자동화 전략은 시스템 설계와 분리될 수 없습니다. 자동화는 나중에 들어오는 단계가 아니라, 소프트웨어를 처음부터 구축할 때 영향을 미쳐야 하는 제약 조건입니다.

테스트 가능성과 자동화 가능성의 차이를 이해하는 것이 자동화를 부채가 아니라 자산으로 만드는 첫 번째 단계입니다.

다음에 올 내용

다음 글에서는 팀들이 지속적으로 겪는 질문을 더 깊이 파고들겠습니다:

실패한 테스트가 자동화 자체의 문제인지, 애플리케이션 설계의 문제인지를 어떻게 판단하나요?

이 구분이 대부분의 자동화 작업이 안정화되거나 서서히 무너지게 되는 지점입니다.

자동화를 자신감 있게 확장하고 싶다면, 마찰 없이 진행되는 시리즈를 팔로우하세요.