1. 두 개념의 본질적 차이

많은 팀이 "코드로 구현할 수 있는가?"를 먼저 묻습니다. 이것이 Automatability입니다.

반면 Testability는 "이 시스템이 검증하기 쉬운 구조를 갖추고 있는가?"를 묻습니다.

• Testability (테스트 가능성): 시스템이 검증에 얼마나 협조적인가를 의미합니다. 관측 가능성(Observability)과 제어 가능성(Control)이 핵심입니다.
  
  
• Automatability (자동화 가능성): 특정 도구나 프레임워크를 사용해 수동 동작을 스크립트로 재현할 수 있는 기술적 가능성을 뜻합니다.
  
  

2. 자동화가 ‘시작도 전에’ 실패하는 시나리오

1. 속도와 KPI 중심의 접근: 테스트 가능성(데이터 통제, 결정성)이 확보되지 않은 상태에서 "자동화 커버리지 80%" 같은 수치적 목표를 쫓으면 억지스러운 스크립트가 양산됩니다.
   
   사실 이 숫자는 얼마든지 사기칠 수 있고, 비슷한 케이스를 대량 양산할 수 있어서, 목표 달성으로 평가가 주어진다면 숫자 맞추기에 혈안되어서 실제 커버리지와 버그 발견에는 큰 의견없이 거의 비슷한 해피케이스만 도달하게 되어 실무적으로는 의미도 없고, 만드는 사람 입장에서도 동기부여 되지 않습니다.
   
   많은 조직과 관리자들이 빠지는 함정이기도 해요.
   
   
2. 누적되는 유지보수 부채: 일반적인 UI 자동화는 레이아웃, 텍스트, 위치만 바뀌어도 본질적으로 깨지기 쉬운 구조를 가지고 있습니다. 여기에 대응을 많이 한다고 해도, 대규모 개편이나 중간에 시스템 점검, 팝업등이 튀어나오는 예외케이스는 무한대에 가깝습니다.
   
   커버리지 %가 높아지고 커버하는 테스트케이스가 많아질 수록  결국 테스트를 수행하는 시간보다 고치는 시간이 더 길어집니다.
   
   따라서 이런 경우 테스트 자동화 무용론이 나오기도 합니다.
   또한 요즘처럼 애자일 스러운 시스템에서, 만들고 실험하고 바꾸는게 일상인 경우 자동화에 대한 메리트가 더욱 의심받기도 합니다.
   
   
3. 리포트 신뢰도 저하: 실패 신호가 발생했을 때 이것이 버그인지, 환경 문제인지, 혹은 불안정한 스크립트 때문인지 구분하기 어렵다면 팀은 점차 리포트를 외면하게 됩니다.
   
   버그였으나 PASS라고 리포트 되는 경우, 버그는 아니지만 UI가 달라서 실패로 나타나는 알람 등, 올바르지 않은 알람 특히 새벽이나 자는 시간 크리티컬한 알람이라고 잘못 알려주는 경우는 더 심각해집니다.
   
   어디까지 알림을 발송할지, 그것을 누가 모니터링할지도 잘 고민해야 합니다.
   따라서 리포트나 실행 주기도 너무 잦다고 꼭 좋은것은 아닙니다.

3. 실무 의사결정을 위한 비교 가이드

5. FAQ

Q1. 자동화가 가능하면 테스트 가능성도 높은 것 아닌가요?
아닙니다. UI 요소를 클릭하는 것은 가능(Automatability)할 수 있지만, 클릭 후 DB에 데이터가 정확히 쌓였는지 확인할 API나 로그가 없다면 테스트 가능성(Testability)은 매우 낮은 상태입니다.

Q2. 테스트 가능성을 높이기 위해 개발 코드를 수정해도 되나요?
네, 적극 권장됩니다. 테스트 전용 ID를 부여하거나 상태 제어용 백도어 API를 만드는 것은 제품의 품질을 높이고 장기적인 QA 비용을 낮추는 투자입니다.

Q3. 이미 구축된 자동화가 자주 깨진다면 무엇부터 해야 할까요?
스크립트를 수정하기 전에 '리포트 신뢰도'를 점검하세요. 원인 파악이 안 되는 테스트는 과감히 격리하고, 실패 신호가 정확히 제품의 결함을 지표화할 수 있도록 관측 가능성을 개선해야 합니다.