비쥬얼 자동화 툴 만들기

서론 : 어떤 걸 테스트 해야 하는 거지?

QA가 없는 환경에서 일을 하다 보니, 테스트와 QA를 더 쉽게 할 순 없을까 하는 고민을 많이 했다.

비단 나 뿐만이 아니라 많은 동료들이 빠르게 스프린트를 진행하다보니 기능 개발에 밀려 테스트는 항상 우선순위가 낮았고, 이는 언제나 사소하거나 또는 큰 장애로 번져 유저 경험을 악화시키고 롤백을 해야 하는 상황을 만들었다.

이제는 AI를 많이 활용해서 개발을 하다보니 AI가 짠 코드가 실제 내가 원하는 수준의 결과물인지를 검증해야 하는 입장이 되었고, 코드 추상화 레벨이나 아키텍쳐, 요구사항은 다 반영되었는지 등에 신경 쓰다 보면 구현이 얼추 되고 나서 확인해봤을 때 AI는 항상 시각적으로 디자이너가 작업한 디자인과는 (많이) 다르게 화면을 그리는 경우가 많았다.

처음에는 단순히 테스트 코드를 잘 작성하면 이 문제를 해결할 수 있지 않을까라고 단순히 생각했다. 하지만 그건 나의 착각이었다.

AI에게 테스트 코드를 작성하게 한 다음 돌려보면 모든 테스트가 통과한다. 그런데도 여전히 시각적으로 문제가 되는 부분은 알 수가 없다. 그럼 테스트 코드를 왜 짜지? 테스트는 통과하지만 여전히 반쪽자리 결과물이다.

여기서 나의 테스트 코드에 대한 심각한 문제 의식이 발견된다.

테스트 코드의 관심사는 시각적으로 디자이너의 의도대로 구현되었는지를 테스트 하는 게 아니다.

테스트 코드는 유저가 하려는 행동이 실제로 행해졌을 때 내가 짠 함수나 컴포넌트가 기대하는 값을 리턴하고 렌더링이 되는지를 검증하는 도구다. 즉, "버튼을 클릭하면 상태가 'on'으로 변경된다.' 라는 시나리오를 짜고 이걸 검증하기 위해서 fireClickEvent를 하고 실제로 'on'이 잘 렌더링 되었는지를 빠르게 가상 돔에서 찾아서 테스트 하면 되는 거다. 이 시나리오에서 'on'이라는 텍스트가 font-size 14px에 font-weight는 bold인지 semibold인지를 검증하는 게 아니다.

시각적으로 디자이너가 의도한대로 잘 구현되었는지를 보기 위해서는 결국 사람의 눈으로 봐야 하는 부분이다.

이걸 더 쉽게 할 순 없을까?

왜 그럴까?

그럼 AI는 왜 그럴까? 이걸 커버할 수는 없을까? 하는 고민을 했었고, 가장 먼저 AI를 잘 쓰기 위해서 만들었던 게 "디자인 시스템" 이었다. 내가 입사했을 때만 하더라도 올팜에는 공통 컴포넌트라는 게 거의 없었다. (v2는 논외) 작업자마다 매번 컴포넌트를 새로 만들고, js + css로 만들 수 있는 것들도 전부 이미지 처리 해버린 경우가 많았다.

처음에는 시스템 가이드라는 개념이 없이 그냥 디자이너가 자주 반복해서 쓰는 UI들을 공통 컴포넌트로 만들어서 쓰기 시작했다. 다이얼로그, 모달, 토스트(토스트는 처음에는 이미 서비스 곳곳에서 사용하고 있던 third party 라이브러리를 쓰고 있었다.)

AI를 가지고 잘 일하기 위해선 단순히 "이렇게 생긴 버튼을 만들어줘" 라고 말하기 보단, 이미 잘 만들어진 컴포넌트를 제시하면서 "여기는 DS 패키지의 Button 컴포넌트를 사용해서 만들어줘" 라고 말하면 Button 컴포넌트를 찾아서 화면을 더 잘 구성했다.

패키지 컴포넌트를 배포할 때 사용 가이드를 담은 md 파일도 같이 export 했는데 패키지 컴포넌트들을 가져다 쓸 때 md 파일이 있으면 같이 읽으라고 미리 프롬프팅(룰) 세팅해두면 AI가 파일들을 읽을 때 사용 가이드도 같이 읽을 수 있어서 AI가 추론하면서 사용하는 대신, 원하는대로 방식을 강제하는 데 좋았다.

하지만 언제나 그랬듯 은탄환은 없기에, 디자인 시스템을 이제 처음 만들어보는 나로서는 그것은 그것대로 구성하는 게 쉽지 않았어서 디자인 시스템 제작기에 대한 이야기는 다른 포스팅에서 풀도록 하겠다.

디자인 시스템 컴포넌트를 써도 여전히 현재까지 구현된 사항과 실제 디자인을 비교하면서 수동 QA를 해야 하는 일은 줄지 않았다.

1. 디자인 시스템이 모든 화면을 커버해 줄 수 없음
 
2. 기존 존재하던 프로덕트에 신규 디자인 시스템을 얹다보니 기존 CSS와 스타일이 충돌하면서
   미세하게 디자인시스템 컴포넌트도 스타일이 깨지는 문제
 
3. 기존 컴포넌트들과의 z-index 충돌로 인해 context stacking이 충돌하는 이슈

처음에는 프로젝트 내에 이미 다른 개발자가 설치했던 cypress 의존성이 있기 때문에 이를 활용해서 스냅샷을 찍고 잘 구현됐는지 확인하는 과정을 시도해보았다. 하지만 언제나 실제 브라우저에 무언가를 띄우는 일은 그곳까지 가는데 기본 세팅이 필요한 법.

우리 서비스는 RN 위에 올라가는 웹뷰이다보니 페이지 진입 시 url에 RN에서 들고 있던 auth token을 search query string으로 달고 들어간다. API를 정상적으로 호출해서 화면을 잘 그리고 데이터를 받아오기 위해서는 내 토큰을 스냅샷 테스트 전에 미리 토큰 세팅을 해두어야 하는 것이다. 또 서비스가 페이지 단위로 되어 있기 보다는 거의 압도적으로 모달의 형태로 신규 기능이 디자인되고 있기 때문에 테스트 용으로 모달을 직접 띄우거나 모달이 뜨는 버튼을 찾아서 열어주는 등 사전 작업이 매우 번거롭다.

그래서 몇 번 시도해보다가 이 테스트는 나에게 유의미하지 않다고 생각이 들었다. 사전 작업이 제대로 이루어지지 않으면 유의미하지 않은 빈 스냅샷만 여러 장이 찍히고 설사 잘 찍혔다 하더라도 그게 디자인 의도대로 잘 구현이 됐는지 또 피그마를 켜서 번갈아 보면서 확인을 해야 하는데 이러느니 그냥 개발 서버를 띄워서 웹에서 확인하는 게 훨씬 빠르다는 판단이었다.

고민을 하다가 생각해 낸 아이디어가 AI한테 실제 구현된 사진과 피그마 화면 두개를 전달하고 이 둘을 비교해서 AI가 시각적으로 차이가 나는 부분을 찾아 결과를 리턴해주면 되지 않을까? 그 결과를 다시 AI 에이전트에 전달시켜서 수정하게 하고 다시 검증받고 이 과정을 통하면 디자이너한테 QA를 맡기고 수정하고 다시 QA를 요청하는 이런 일을 줄일 수 있지 않을까? 하는 생각을 했다.

HOW

그래서 데모를 빠르게 만들어보았다. ✌️

1. [크롬 익스텐션] : 실제 웹에 띄워진 개발 화면을 스냅샷 찍고 피그마 토큰과 피그마 주소 피그마 API를 호출해서 비교할 피그마 프레임 목록을 불러온다.

2. [로컬 서버] : 스냅샷과 피그마 화면을 받아서 리사이징 한 후, 클로드 API를 호출해서 이 둘의 diff를 검증해달라고 요청한다. 받아온 결과를 파싱해서 다시 익스텐션에 응답으로 보낸다.

3. [크롬 익스텐션] : 비교 결과를 받아서 그린다. 스냅샷 화면과 구현 화면을 나란히 두고 슬라이더를 움직이며 바로바로 비교해서 마진이나 위치 등 상이한 점을 빠르게 시각적으로 확인할 수 있다.

실제 하루동안 작업하면서 써봤는데 개인적으로는 꽤나 만족도가 높았다. 개발 화면과 피그마를 동시에 띄우고 작업하더라도 두 개의 다른 실행 프로그램을 왔다 갔다 하는 건 모니터가 두대라도 꽤나 번거롭다. 그리고 화면과 피그마가 떨어져있기 때문에 동일 화면 사이즈에서 볼 때 위치나 패딩, 폰트 사이즈 등이 적절하게 렌더링 된 건지 단박에 구분하기가 어렵다.

그래서 이미지 슬라이드 기능은 꽤나 유효했던 것 같고, 응답 결과는 처음에 "구현 사항 타이틀 폰트가 좀 더 작은 것 같다." , "구현 컨테이너 좌측 패딩이 좀 좁은 것 같다" 등의 추상적인 상대적 표현은 오히려 다시 AI 에이전트에게 일을 시키기에 꽤나 부정확한 정보가 되었고 이를 수정하여 약 2px 정도 더 좁은 것 같다 등의 수치를 같이 표현할 수 있도록 했다.

그리고 이걸 나만 쓰는 게 아니라 우리 프론트챕터 개발자분들도 쓰면서 DX가 매우 향상되길 바라는 마음으로 열심히 홍보도 했다. 피드백을 받는 대로 추가적으로 디벨롭을 할 생각이다.

지금은 결과 텍스트를 복사해서 다시 내가 일을 시켜야 하는데, 받아온 결과를 내 에이전트가 읽어서 알아서 QA 랄프루프 돌게하는 것까지 할 수 있으면 좋을 것 같다고 생각하고 있다. 그렇게 하려면 서버를 띄우고 에이전트 MCP로 만들어서 에이전트도 바로 결과를 받을 수 있도록 구조를 변경해야 하는데 시간이 되고 이 기능이 정말 유효하다면 시도해 볼 수 있을 것 같다.

또 iOS 사용자를 위해서 iOS 환경에서도 이런 시각적 테스트를 할 수 있는 방법을 찾아서 크로스 브라우징도 대응할 수 있도록 고민해야 할 것 같다.