상황 (S)
Runky 프로젝트를 개발하면서 주간 운동 기록(거리, 시간, 페이스 등)을 시각화할 필요가 있었다. 이를 위해 차트 라이브러리를 도입했고, 디자이너가 요청한 디자인은 바(bar)의 끝 부분이 둥근 모서리(border-radius) 를 적용한 형태였다.
공식 문서를 참고해 plotOptions.bar.borderRadius 옵션을 적용한 결과, 데스크톱 뷰에서는 문제없이 구현되었다.
- 데스크톱 뷰 (정상 적용)
하지만 모바일 뷰에서는 radius가 적용되지 않는 문제가 발생했다. Runky는 웹뷰 기반 프로젝트였기 때문에 해결이 필요했다.
문제 분석 & 시도한 방법 (A)
먼저 비슷한 문제를 겪은 개발자가 있는지 조사했다.
조사 결과, ApexCharts는 path 태그를 사용해 바를 그리는데, Webkit 기반 브라우저(사파리, 크롬 모바일) 에서 border-radius 처리가 정상적으로 렌더링되지 않는 버그가 있었다.
개발자 도구로 확인한 결과 역시 path 태그에서 radius가 제대로 표현되지 않았다.
-
사파리 (문제 발생)
-
Firefox 기반 젠 브라우저 (정상 작동)
같은 문제를 제기한 개발자가 7월에도 이슈를 올렸지만 아직 수정되지 않았고, 비슷한 질문도 Stack Overflow에 다수 존재했다. ApexCharts가 깔끔한 문서와 UI를 제공한다는 장점이 있지만, 버그 이슈가 많다는 점에서 신뢰성이 떨어졌다.
결국, 빠른 개발을 위해 다른 차트 라이브러리로 교체하기로 결정했다.
결과 & 배운 점 (R)
- 공식 문서와 예제가 잘 되어 있어 선택했지만, 실제 크로스 브라우징 테스트에서 문제가 드러났다.
- 다행히 간단한 기능에서 발생했지만, 프로젝트 후반부의 복잡한 구현에서 이런 문제가 생겼다면 훨씬 더 큰 리스크가 되었을 것이다.
- 이번 경험을 통해 라이브러리를 선택할 때 필요한 기능들이 안정적으로 지원되는지 반드시 검증해야 한다는 점을 배웠다.
- 또한, 평소 크롬 위주로 개발하던 습관을 바꿔, 실제 배포 환경과 유사한 조건(사파리, 파이어폭스 등)에서 테스트해야 한다는 필요성을 느꼈다.
결론적으로, 이번 문제는 단순한 border-radius 이슈였지만, 개발 환경 세팅과 라이브러리 선택 기준에 대해 다시 생각해보게 된 사례였다.
끝!
