최근 디자인 시스템을 개발하면서, 컴포넌트가 예상과 다르게 동작하는 상황에 대한 두려움을 절실히 느끼고 있습니다. 그래서 그동안 미뤄왔던 테스트 코드 작성이라는 숙제를 다시 펼쳐 보기로 결심했는데요. 마침 토스의 모닥불에서 테스트 코드에 대한 내용을 쉽고 재미있게 다룬 영상을 보게 되었습니다. 오늘은 이 영상을 시청한 뒤 디자인 시스템 개발자로서 제가 느낀 점들을 간단히 이야기해 보려고 합니다.
피드백 사이클 단축
프론트엔드 코드는 대부분 브라우저에서 동작합니다. 따라서 이를 테스트하려면 개발 서버를 실행하고, 원하는 페이지까지 직접 이동한 뒤 테스트를 진행해야 합니다. 작은 프로젝트라면 이 과정이 크게 부담스럽지 않을 수 있지만, 프로젝트의 규모가 커질수록 상황은 달라집니다. 개발 서버의 로딩 속도는 느려지고, 페이지 경로는 많아질테니, 결국 이런 작업은 점점 더 번거롭게 느껴질 수밖에 없습니다.
테스트 코드를 도입하면 이러한 과정들, 즉 내가 작성한 코드에 대한 피드백을 받는 주기를 단축할 수 있다는 것입니다. 확실히 브라우저에서 직접 테스트하며 시각 정보를 판단하는 과정을 생략하고 성공과 실패라는 명확한 결과로 피드백을 받을 수 있으니, 직관성과 생산성이 크게 향상될 것이라는 데는 공감이 됩니다.
다만, 제가 아직 테스트 감수성이 부족해서인지, UI 테스트에 대해서는 완전한 신뢰성을 느끼지 못하고 있습니다. 예상치 못한 변수가 너무 많을 것 같고, 복잡한 상호작용이 동반되는 경우에는 직접 실행하고 눈으로 확인하는 것만큼 신뢰할 수 있는 방법이 없다고 생각이 들거든요. 더욱이, 저는 디자인 시스템 개발자로서 다양한 상황에 맞는 형태를 테스트하는 것도 중요하다고 생각합니다. 그런데 이를 시각적으로 확인하지 않고 테스트 코드만으로 검증하는 것이 과연 얼마나 신뢰할 수 있을지에 대해서는 여전히 의문이 남습니다.
안정성
개발을 하다 보면 기존에 작업한 내용을 변경해야 하는 상황이 자주 발생합니다. 이때 새로운 기능을 추가하기 위해 기존 코드를 수정하면서, 잘 동작하던 기능에 버그가 생기는 경우도 종종 있습니다. 실제로 최근 디자인 시스템의 기존 코드를 수정하거나 새로운 기능을 추가하는 과정에서, 컴포넌트의 동작이 기존과 달라졌음을 미처 확인하지 못하고 QA 단계에서야 이를 발견한 경험이 있었습니다. QA 단계에서 발견되어 다행이었지만, 만약 이 문제가 그대로 사용단에 전달되었더라면 사용자들의 신뢰를 떨어뜨릴 수 있었을 것이라는 생각에 아찔하기도 했습니다. 또한, 기존에 확인한 내용들을 다시 점검해야 했기 때문에 불필요한 리소스 낭비가 발생했다는 점도 해결해야 할 문제였습니다.
테스트 코드를 잘 작성해두면 기존 스펙이 여전히 잘 작동하는지 쉽게 확인할 수 있기 때문에, 이러한 불안감에서 벗어나 지속적이고 안정적인 유지보수가 가능합니다. 이 부분에 대해서는 정말 큰 공감을 했습니다. 패키지에 새로운 기능이 추가될 때마다 기존 내용을 일일이 확인하는 것이 아니라, 테스트 코드를 통해 기존 스펙과의 차이점을 직관적으로 확인할 수 있습니다. 이는 버그 발생률을 줄이고, QA에 소요되는 리소스도 대폭 절감하는 데에도 큰 도움이 될 것입니다.
장기적인 생산성
테스트 코드가 중요하다고 생각하면서도, 실제로 작성하지 않는 사람이 많은 것 같습니다. 물론 이는 자신의 현재 상황에도 많은 영향을 받겠지만, 지금 당장의 생산성을 더 중요시 하기 때문이라고 주장하는 경우도 있습니다. 눈앞에 개발해야 할 기능들이 쌓여 있는데, 사용자가 테스트 코드가 있는지도 모른 채 작성하는 것이 충분히 비효율적으로 느껴질 수 있을 것 같습니다.
그러나 유지보수가 전혀 필요하지 않은 기능이라면 생산성이 떨어진다고 볼 수도 있겠지만, 대부분의 경우 우리가 작성한 코드는 변경됩니다. 그래서 새로운 기능을 추가할 때 기존 코드와의 관계를 고려해야만 하는데, 이때 기존 코드에 문제가 있다면 추가하려던 기능을 잠시 미루고 그 문제를 해결해야 할 것입니다. 결국, 하나의 기능을 추가하기 위해 소요되는 시간이 점차 지연되고 생산성이 떨어질 수밖에 없습니다.
물론, 테스트 코드가 모든 버그를 잡아주는 것은 아니기 때문에 장기적으로 봐도 여전히 버그가 남을 수 있습니다. 하지만 기능을 개선하면서 테스트 코드도 점차 개선될 것이고, 이를 통해 더 견고하고 안정적인 코드가 될 것입니다. 결국, 테스트 코드를 작성했을 때 그렇지 않은 경우보다 버그가 없을 확률이 훨씬 높아질 것입니다.