💡 Figma와 Claude를 활용한 테스트 자동화 구조 개선 경험

🧩 자동화는 코드가 아니라 구조라는 걸 느꼈던 경험

스타트업에서는 짧은 스프린트 단위로 기능이 빠르게 변경되다 보니, 정말 다양한 경험과 버그를 계속해서 마주하게 되는 것 같다. 바쁜 일정 속에서도 가끔 일주일 정도 여유가 생기는 시기가 있는데, 그럴 때마다 기존에 어느 정도 구현되어 있던 자동화 코드를 개선해보려고 시도했다.

 

기존 자동화 코드에는 일부 UI 요소에 data-testid가 적용되어 있었다. 전임자께서 자동화 안정성을 고려해 추가해두신 것이었지만, 해당 정보가 별도의 문서로 정리되어 있지 않고 매 스프린트마다 작성되는 기획 문서에만 일부씩 흩어져 있었다.

 

그 결과 data-testid 관련 정보는 여러 문서에 분산되어 있었고, 어떤 화면에 어떤 식별자가 존재하는지 한 번에 파악하기 어려웠다. 자동화 코드와도 직접적으로 연결되어 있지 않았기 때문에, 실제로는 존재하는 식별자를 제대로 활용하지 못하는 상태였다.

 

새로운 테스트를 작성할 때마다 UI를 다시 분석해야 했고, 기존 테스트를 수정할 때도 locator를 다시 찾아야 했다. 결국 자동화가 누적될수록 효율이 좋아지는 것이 아니라, 오히려 유지보수 비용이 계속 증가하는 구조였다.

 

이 문제를 해결하기 위해 단순히 locator를 바꾸는 것이 아니라, 자동화에서 사용할 수 있는 기준 자체를 만들어야 한다고 판단했다. 그리고 그 기준을 정리하기 위한 방법으로 Figma를 활용해 자동화 대상 UI 구조를 정리하기 시작했다.

 

🎯 왜 별도의 기준 파일을 만들었는가

기존 자동화 코드는 대부분 UI 요소를 xpath나 텍스트 기반으로 탐색하고 있었다. 이 방식은 빠르게 작성하기에는 편하지만, 다음과 같은 한계를 가지고 있었다.

• UI 구조가 조금만 변경되어도 테스트 코드가 쉽게 깨짐
• 텍스트 변경, 다국어 대응 시 locator를 대량으로 수정해야 함
• 기획 및 개발 변경이 자동화 안정성에 직접적인 영향을 줌

결국 이 방식은 장기적으로 유지하기 어려운 구조였고, UI 요소를 보다 구조적이고 의미 있는 기준으로 식별할 필요가 있다고 느꼈다. 그래서 그 기준을 정리하기 위해 별도의 Figma 파일을 생성하게 되었다.

 

🧱 Figma를 자동화 기준으로 사용한 방식

이 파일은 단순히 화면을 모아두는 용도가 아니라, 자동화 코드 구조와 직접 연결될 수 있도록 설계했다.

 

하나의 화면 단위를 하나의 페이지로 구성하고, 그 페이지는 자동화 코드의 Page Object와 대응되도록 만들었다. 즉, 화면 구조와 코드 구조를 분리하지 않고 동일한 기준으로 맞춘 것이다. 이렇게 구성하면서 UI 구조와 자동화 코드 구조가 자연스럽게 연결되었고, 화면이 변경되었을 때 어떤 코드에 영향을 주는지도 예측할 수 있게 되었다. 또한 Page Object의 책임 범위도 명확해졌다.

 

이 과정에서 Figma는 단순한 디자인 도구가 아니라, 자동화 대상 UI를 정의하고 구조를 기록하는 기준 공간으로 사용되었다.

 

각 화면에서 어떤 UI가 어떻게 보이는지, 어떤 요소가 존재하는지를 Figma에 정리하고, 그 화면 안에 있는 실제 요소들 하나하나에 직접 annotation을 달기 시작했다. 그리고 이 annotation에는 설명이 아니라, 해당 요소에 부여되어야 할 식별자 값 자체를 기록했다. 즉, 이 요소는 어떤 역할을 하는지 설명하는 것이 아니라, “이 요소에는 이 data-testid가 들어간다”는 값을 그대로 정의한 것이다.

 

이렇게 되면서 Figma 문서는 단순한 UI 정리 문서가 아니라, 요소 단위 식별자 정의서 역할을 하게 되었다.

 

🏷 식별자 네이밍 기준 정리

{page-name}__{section/component}__{element-role}

식별자는 위와 같은 형태의 규칙으로 정의했다. 이 규칙의 목적은 이름만 보고도 해당 요소의 위치와 역할을 이해할 수 있도록 만드는 것이었다. 예를 들어 특정 버튼이 어떤 화면의 어떤 영역에 속해 있고 어떤 역할을 하는지, 식별자만으로도 바로 파악할 수 있도록 구성했다. 

 

🤖 가장 중요했던 변화: Claude를 활용한 자동화

이 작업을 하면서 가장 크게 느낀 변화는 따로 있었다.

 

QA 입장에서 서비스 코드를 깊게 분석하는 것은 현실적으로 부담이 크다. 컴포넌트 구조를 전부 파악해야 하고, 어떤 요소에 어떤 locator를 넣어야 하는지 직접 추적해야 하기 때문이다.

 

그런데 이 구조를 만든 이후, 접근 방식 자체가 완전히 달라졌다.

 

각 요소에는 annotation이 달려 있고, 이 요소들은 하나의 화면 안에서 최상단 레이어에 포함되어 있다. 이 상태에서 해당 화면의 최상단 레이어 선택 항목 링크만 전달하면, AI는 그 레이어 내부 구조를 그대로 탐색한다. 그리고 내부 요소들을 순회하면서 annotation이 달려 있는 요소를 찾아내고, 그 안에 적혀 있는 식별자 값을 그대로 읽는다. 이후 코드에서 해당 UI 요소를 찾아, 그 값을 data-testid 또는 testID로 그대로 적용한다.

 

사람이 요소를 하나씩 설명하거나 매핑해줄 필요 없이, 레이어 하나만 전달하면 구조와 식별자를 함께 해석하고 적용하는 흐름이 만들어진 것이다.

 

여기서 끝이 아니다.

기존에 xpath 기반으로 작성되어 있던 자동화 코드도, 새롭게 정의된 식별자를 기준으로 자연스럽게 개선할 수 있었다. 코드에서 해당 요소를 찾아 식별자 기반으로 locator를 교체하고, 테스트 코드까지 함께 정리하는 흐름으로 이어졌다.

 

결과적으로, 사람이 직접 UI를 보고 locator를 작성하던 방식에서 벗어나, 구조를 정의하면 자동화까지 이어지는 방식으로 바뀌게 되었다결국 내가 한 일은 단순히 자동화 코드를 개선한 것이 아니라, 자동화가 구조를 기반으로 동작하도록 만드는 방식으로 접근을 바꾼 것이었다.

 

🧠 정리하며

스타트업 환경에서는 각 팀이 모두 바쁘게 움직이기 때문에, 자동화 코드 개선을 위해 필요한 요소들을 협업으로 정리하는 것 자체도 쉽지 않은 경우가 많다.

 

이번 경험을 통해 느낀 점은, AI의 발전으로 이러한 작업을 QA 혼자서도 어느 정도 해결할 수 있는 환경이 만들어지고 있다는 것이었다. Figma에 구조와 식별자 기준을 정리해두면, 그 정보를 기반으로 실제 코드까지 반영하는 과정이 자연스럽게 이어질 수 있었다.

 

결국 단순히 자동화 코드를 개선한 것이 아니라, 정보를 기록하고 그 기록이 실제 코드까지 연결되는 구조를 만든 것에 가까웠다. 회사 생활을 할수록 정보 기록과 공유의 중요성을 더 크게 느끼게 되는데, 이번 작업은 그 흐름을 유지하면서도 자동화의 유지보수까지 함께 개선할 수 있었던 경험이었다.

 

또한 업데이트 로그나 식별자 기준, 페이지 구성 안내 등을 함께 정리하면서, 이 구조를 지속적으로 관리하고 확장할 수 있도록 만드는 것도 중요한 부분이었다.

 

다만 이 방식이 모든 영역에 항상 효율적인 것은 아니라고 생각한다. 자동화는 서비스의 모든 영역을 커버하기보다는, 변경사항은 적지만 서비스에서 핵심적인 역할을 하고 매 릴리즈마다 반드시 확인이 필요한 영역에 적용할 때 가장 효과적이다.

 

반대로, 변화가 잦은 화면이나 구조가 자주 바뀌는 영역에까지 동일한 기준을 적용하면, 오히려 annotation 관리와 구조 유지 비용이 더 커질 수 있다. 그렇기 때문에 이 방식은 전체에 일괄 적용하기보다는, 안정성이 중요하고 반복적으로 검증이 필요한 영역에 선택적으로 적용하는 것이 더 효율적이라고 느꼈다.