조합이폭발하는디자인시스템이걸눈으로도테스트하라고요

feconf2026

Transcript

1. FECONF 2026 조합이 폭발하는 디자인 시스템, 이걸 눈으로도 테스트하라고요? 유길종 | Frontend Platform Engineer Viva Republica (Toss)
2. 수많은 서비스가 디자인 시스템에 직접 의존해요 TDS 서비스 A 서비스 B 서비스 C 서비스 D
3. 시간이 흐르면서 컴포넌트 간의 의존 관계도 매우 복잡해졌어요 컴포넌트
4. 컴포넌트 하나만 건드려도 엄청 많은 컴포넌트에 영향이 가요
5. 넓게 전파되는 시각적 변화를 잘 감지하고 핸들링할 수 없을까?
6. Visual Regression Test ( 시각 회귀 테스트 )
7. 시각 회귀 테스트는 코드 변경 전과 후의 화면 스크린샷을 비교하여 의도하지 않은 UI 디자인 변경이나 오류를 감지하는 테스트
8. 시각 회귀 테스트는 코드 변경 전과 후의 화면 스크린샷을 비교하여 의도하지 않은 UI 디자인 변경이나 오류를 감지하는 테스트
9. 코드를 바꿨을 때 어떤 시각적 변경이 일어나는지 바로 알 수 있어요 의도한 변경이라면 베이스라인을 업데이트하여 새로운 기준으로 만들어요 코드 수정으로 인해 UI의 의도치 않은 변화가 생기는 회귀 문제를 차단해요
10. 여기까진 참 좋은 것 같은데..
11. 느려요 테스트를 위해 실제 웹브라우저가 필요해요 스냅샷마다 격리된 환경을 제공하기 위한 환경 설정 비용이 발생해요 화면이 안정화 될 때까지 기다렸다가 캡쳐해야 오탐이 안 생겨요 잘깨져요 사용자의 코드가 비결정적이면 매번 실행 결과가 달라져요 똑같은 코드도 실행 환경에 따라 미묘하게 결과물이 다르게 나와요 CDN 등의 외부 환경의 변화나 네트워크 환경에도 영향을 많이 받아요
12. 느린걸 잡으면 잘 깨져요 잘 깨지는걸 잡으면 느려져요
13. 느린것도 문제지만 잘 깨지는 건 더 큰 문제에요
14. 보통 업계에서는.. 01 02 렌더링 03 안정화 대기 스냅샷 캡쳐
15. Document의 폰트 로딩을 기다려요
16. Dom Tree의 변경을 옵저빙해요
17. 네트워크 요청이 잠잠해질 때 까지 기다려요
18. Math.random , new Date() 같은 함수의 반환값을 고정해요
19. +약간의 휴리스틱 네트워크 요청이 N 초 동안 발생하지 않았다면 잠잠한건가? DOM의 변경이 N 초 동안 없으면 안정화된건가? 어느정도의 휴리스틱이 필요할 수 밖에 없어요
20. 신뢰가능한 실행 환경을 만드는것도 중요해요
22. 수평 확장이 가능하면서 일관된 실행 환경을 보장해야 해요
23. 구현은 어떻게하지?
25. vitest를 쓰면 샤딩, 병렬 워커 설정등이 따라와요 Storybook을 쓰면 추가 코드 작성 없이 스냅샷 대상을 얻을 수 있어요
26. GitHub Actions를 테스트 환경의 SSOT로 삼아요
27. 명령어를 입력하면 깃허브액션 워크플로우를 트리거해요
28. CI를 통해 스냅샷이 깨진 상태로는 병합할 수 없게 해요
29. HAPPY END..?
30. 였으면 좋았을텐데요
31. 이런 일이 생기기 시작했어요 A B 개발자 A 엇 이거 왜 시각 테스트에서 안 잡혔을까요? 개발자 B 이건 시각 테스트에서 검사하는 목록에 없는 케이스여서 안 잡힌 것 같아요
32. “Program testing can be used to show the presence of bugs, but never to show their absence!” 프로그램 테스트는 버그가 존재함을 보여줄 수는 있지만, 버그가 없음을 보여줄 수는 없다.
33. 놓치는 시각 조합이 있는게 문제라면 가능한 시각 조합을 다 만들면 되는 거 아니에요?
35. Pseudo State Base Hover Active Focus
36. Color Scheme Dark Light
37. 그 외에도.. 등등등 Slot Size variant · disabled · loading · … Color
38. 모든 축의 값을 곱하면 Pseudo State ColorScheme color variant size 4 2 7 3 3 startIcon endIcon fullWidth disabled loading 2 2 2 2 2 가능한 조합 4×2×7×3×3×2×2×2×2×2 16,128
39. 게다가 우리는 컴포넌트 하나만 책임지는게 아니죠
40. MUI만 보더라도 지원하는 컴포넌트가.. 60개
41. 가능한 경우의 수가 곱셈으로 늘어나게되면 금새 감당할 수 없는 정도의 숫자가 됩니다
42. 페어와이즈 테스트 하면 되는거 아니에요? 소프트웨어의 결함은 대부분 1개 혹은 2개의 매개변수의 상호작용에서 발생한다고 봐요 모든 두요소의 조합을 한번씩만 테스트해도 90% 이상의 결함을 발견할 수 있다. 조합하는 매개변수를 늘린 3-way, 4-way test 도 있어요
43. 상태를 2개씩 가지는 매개변수 3개가 있다고 가정해봐요 전체 경우의수는 2*2*2 로 8이에요
44. 페어와이즈 기법을 적용하면 총 조합이 4로 줄어들어요 그러면서도 임의의 두 속성에서 가능한 모든 값의 조합이 한번씩 등장하죠
45. 전체 조합과 페어와이즈 전체 조합 2 16 페어 와이즈면 = 65,536 = 총 조합이 늘어날 수록 페어 와이즈의 효과도 기하급수적으로 커져요 8
46. 페어와이즈 테스트 하면 되는거 아니에요? 변인 하나만 추가 되어도 모든 스냅샷이 재생성 되어 변경점을 알기 어려워요 시각적 변경이 중요한 축들의 전체 커버리지가 보장되는 게 더 중요했어요 중요한 시각적 변경을 담는 Props를 큐레이션 하는 작업은 여전히 중요했어요
47. 조합 폭발을 막으려면 곱셈 자체를 줄여야 해요
48. 자원이 한정되어 있다면 무엇을 테스트할지를 결정하는 것도 중요해요
49. 곱셈을 어떻게 줄일 수 있을까?
50. Structure / Layout Visual / Appearance
51. Visual / Appearance의 변경은 Structure / Layout에 영향을 주지 않는다.
53. 이정도면 해볼만한데..?
54. 곱셈을 쪼갤 축만 잘 선언해주면 테스트케이스는 알아서 생성해줄 수 있을 것이다 축 선언 조합 생성 테스트 화면
55. 가능한 조합을 모두 곱하는 대신 관심 있는 축끼리만 곱할 수 있으면 어떨까? 개발자가 관심 있는 축만 잘 선언하면 시각 테스트용 화면이 알아서 생성되면 어떨까?
56. 오버레이되는 컴포넌트들은 어떻게 찍지..?
57. 화면 중앙에 뜨는 스펙의 컴포넌트들은 한 화면에 여러개를 띄우면 겹쳐져버려요
58. 내부적으로 fixed한 컴포넌트들도 각 컴포넌트마다 relative한 컨테이너를 제공해주면 어떨까? 한 스냅샷에서 여러 컴포넌트를 한번에 찍을 수 있지 않을까?
60. Select 같이 Trigger를 기준으로 오버레이되는 컴포넌트들은 Trigger 기준으로 너비나 높이를 배치해버리면 겹쳐져요
61. 오버레이되는 컴포넌트들의 너비, 높이를 고려해야하는 경우엔 너비, 높이에 대한 안전 마진을 줄 수 있는 인터페이스를 열어주었어요
63. TDS는 지금도 매일 5,000장 이 넘는 스냅샷을 검증하고 있어요
64. 일단은.. HAPPY END..!
65. 마치며 모든 선택에는 트레이드 오프가 있다. 테스트는 버그가 없음을 보여줄 수는 없다. 무엇을 원하는지 모르면 좋은 테스트를 작성할 수 없다.
66. 감사합니다