1. 내가 해결하고자 했던 문제들..
- 서비스 안전성
- 우리는 현재 리소스가 부족하여 검수를 할 수 있는 상황이 아니였다. 하지만 1주 단위의 빠른 배포가 필요했다. 안전성을 확보하고자 테스팅툴을 알아보고 있었다.
- 디자인 시스템 의사결정 퀄리티 향상
- AS-IS는 디자이너 한명이 의사결정을 하는 구조로 이루어졌다. 나는 디자인 시스템에 참여하는 진입장벽을 낮추고 의사결정의 퀄리티를 높이고 싶었다.
- 공유에 대한 누락사항 및 의사전달 비용 절감
- 현재는 글로만, 어떻게 변경되었는지를 전달하고 있다. 하지만, chromatic을 이용하면 시각적으로 어떤 부분이 달라졌는지를 정확하게 전달 할 수 있었다. (무려 픽셀이 어떻게 달려졌는지까지도..)
2. chromatic 시작하기
1) https://www.chromatic.com/ 계정을 생성하세요
2) git을 연동하세요
3) 프로젝트에 chromatic을 설치하세요
4) chromatic 명령어를 실행하세요
3. 우리팀은 chromatic 도입 적응기를 다음과 같이 가졌어요
1) chromatic에 대해서 도입 방향에 대해서 팀내에서 발표 및 회의를 진행했어요
2) 그리고 약 1달의 도입 기간을 갖기고 하여 디자인 검수를 chromatic으로 진행하였습니다
3) 하지만 적용 당시에 어려움이 생겼습니다
4. chromatic 적용의 어려움(디자인팀 VS 개발팀(FE))
(1) chromatic으로 테스트를 진행하려면, 컴포넌트를 테스트할 수 있는 story가 구현되어 있어야 했는데, story가 기존에 등록되어 있지 않아 변경사항이 모두 'new'로 잡혀 변경된 부분만 잡아내지 못하는 상황 => chromatic에 대한 story 작업을 push하고 컴포넌트 변경사항을 분리해서 chromatic에 변경사항에 변경사항만 잡히도록 브랜치를 관리 할 것.
(2) 디자이너가 생각하는 story와 개발자가 말하는 story가 다름.
=> 디자이너가 생각하는 story는 figma에 정의된 케이스만 작성되어야 함. 개발자가 생각하는 story는 "테스트 케이스" 테스트 케이스는 디자인에서 정의해준 외의 것들을 필요에 의해서 테스트를 생성할 수 있음. "외의 것들"에 대해서 디자이너나 다른 기획자들이 보고 혼동할 수 있기 때문에 개발자의 테스트 케이스와 디자이너가 정의해준 예시를 구분해서 작성할 것.
(3) 디자이너는 결국 stroybook에서 개발자도구를 이용해 검수를 진행 함. chromatic에서 어떻게 검수해야 되는지 1개월의 도입기를 거쳤지만, 불편하고 디자인 업무의 프로세스와는 맞지 않다고 생각하심.
=> chromatic은 마치 개발자 입장에서 PR을 날리는 구조로 되어 있음, 개발자 입장에서 PR은 이미 존재하는 개념이고, 프로세스 상의 이질감이 크게 없음, 하지만 디자인의 입장에서 storybook에서 검수를 진행하고, jira에 댓글만 달면 끝나는 일인데, chromatic의 새로운 툴이 또 도입되어 chromatic도 봐야하고, storybook도 봐야하고, jira도 봐야 하는 이슈가 발생함
5. 그렇다고, chroamtic이 갖는 장점이 있는데 버릴만 한가?
1) 안전성..
2) 공유방법 개선..
3) 히스토리 관리..
4) 디자인 시스템 규모 확장 가능성..
6. 그래서 우리팀은 이렇게 결론 내렸어요
결론은 디자인팀은 "chromatic 도입 반대" 입니다.
하지만, 장점이 많으니 개발팀에서 내부적으로는 사용해도 좋다 였습니다.
하지만.. 돌릴 때 마다 발생하는 비용지원에 말씀은 없으셨다.
결국 chromatic도입은 이렇게 흐지부지 되어 버렸다.
7. 그 후 나의 도전기
- 비용이 너무 비싸서 시각적 회귀테스트를 간단하게 직접 구현해보았습니다.
- 라이브러리는 Puppeteer를 사용했고, 목표는 총 3가지로 하였습니다.
1) figma하고 비교해서 차이가 있는지 => 단순 페이지 비교
2) 이전 버전하고 비교해서 차이가 있는지 => 단순 페이지 비교
3) 액션을 통한 화면 비교(button 클릭 후 결과페이지 비교)
