본문 바로가기

📂 에러로그

라이브러리 사용하기 전에 꼭! 버전 체크하기 💥

   상황: Sentry를 추가하려다 에러를 마주했다!

이번 프로젝트를 진행하면서 이것저것 새로운 기술들을 많이 알게 되었는데요, 그 중에 하나가 바로 Sentry입니다.
지금 저희 프로젝트의 서버에는 Sentry가 달려있는데, 경험해본 결과 정!말 개발의 질이 올라가더라구요 ?!

 

전 API를 연결할 때, 알 수 없는 오류 응답을 마주하는 경우가 많습니다,,
(개인적으로 가장 답답한 경우는 proxy 또는 관련 설정이 잘못 되어서 무작정 404에러를 주는 경우입니다.......... 흑흑)
좋지 않은 습관일 수도 있지만 그럴 때마다 전 항상 우선은 제 탓을,, 해보며 코드를 이리 저리 뜯어봅니다. . .
그리고 정말 도~저히 답이 안나올 때가 되어서야 백엔드 팀원분께 한번 봐달라고 요청을 하는 편입니다.
만약 백의 문제였다면 전 약간의 시간 낭비를 한 셈이죠,,ㅎㅎ

++ 사실 이런 경우가 종종 있었어서, 제가 너무 백엔드에 무지한 탓인가.. 싶어서 백을 더 공부하고 싶은 마음이 있는 것 같아요!

 

 

Sentry 최대 장점 처음으로 마주한 순간 ✨

 

아무튼,
Sentry가 추가된 지금 프로젝트에서는 백엔드 쪽 문제로 인해 연결이 잘 안되는 경우라면 바로 슬랙으로 알림이 오기 때문에 '오호 백 문제때문이구나?! 그럼 이건 나중에 체크하고 다른 개발을 하고 있어야 겠다!' 라고 정확히 프론트, 백 어디 쪽 문제인지 확인할 수 있고, 개발 회전(?)이 빨리빨리 되기 때문에 (제 기준) 시간 낭비를 하지 않아도 되고, 프론트 입장에서 개발하기 너무 편하다! 라는 느낌을 받았습니다.

 

 

 

두 번째로는 이런 저런 테스트 data를 넣어볼 때 예기치 못한 에러를 잡아낼 때! 너무 좋을 것 같더라구요.

프로젝트 배포를 하다보면 QA 단계에서 아무리 꼼꼼하게 한다고 해도, 모든 유저의 행동 case를 다 테스트해볼 수는 없다고 생각해요. 물론 모든 case를 테스트해보며 오류 없는 코드를 짜는 게 베스트겠지만, 개발자도 사람이니까 항상 완벽할 순 없겠죠!

 

그리고 지극히 개인적인 의견이지만 웹 개발에 지식이 없던 시절의 저를 생각해보면,, 웹페이지를 사용하는 데 뭔가 에러가 발생했다? 그럼 사실 새로고침 몇 번 해보고 그냥 그 페이지를 닫을 것 같거든요... 그럼 개발자 입장에서는 해당 행동을 직접 해보거나(하지만 안해볼 확률이 높다고 생각합니다... 개발하면 할수록 개발자입장에서 자꾸 페이지를 사용하게 되는.....~) 누군가 제보를 해주기 전까지는 절대 알 수가 없겠죠,, 그동안 유저에게 계속 에러가 노출될 거구요!

 

이런 점에서 Sentry를 달아 놓으면 해당 에러가 발생했을 때 바로 알림이 올테니까 개발자가 바로바로 대처할 수 있겠죠?! 특히 직접 유저가 사용하는 부분을 담당하는 프론트에서는 이런 점이 굉장한 장점일 것 같다고 느껴졌어요. 저희 프로젝트에서 아직 프론트는 Sentry를 달지 못해서 이 점이 매우매우*999 부럽습니다 .. 늘 제가 만드는 서비스에 애정을 가득가득 담는 개발인으로서,, 유저에게 저희 아이의 예쁜 점들만 보여주고 싶지, 오류를 보여주고 싶지는 않거든요....... 상상만 해도 매우매우 속상,,,

 

 

* Sentry 관련 참고

Sentry로 우아하게 프론트엔드 에러 추적하기 | 카카오페이 기술 블로그


   에러: 그래서 무슨 에러냐면요 ,,

Sentry 까려다가 어마어마한 에러 마주친 썰푼다,,

 

어쩌다보니 Sentry에 대한 생각을 너무 주절주절해버렸군요

 

다시 본론으로 돌아와서 그렇게 Sentry의 장점을 느껴버린 저는 "오키! 당장 프엔에도 Sentry 추가한다!" 하고 아주 당차게 Sentry를 다운받는 순간 위와 같은 문제 덩어리💥와 마주하게 됩니다.

 

체크인 페이지에 사용된 마크다운 에디터 라이브러리의 dependency와 실제 리액트 버전이 충돌하여 발생한 에러였습니다. 즉, 라이브러리는 해당 라이브러리를 사용할 프로젝트의 리액트 버전로 17을 요구했지만, 실제로 저는 리액트 버전 18에서 해당 라이브러리를 사용했기 때문에 버전이 맞지 않았던 것입니다.

toast-ui/editor 라이브러리 요구 버전: 17.0.1
실제 사용 버전: 18

 

 

npm run build 했을 때 에러가 안나길래 develop 브랜치로 머지를 해버렸는데, 저 에러때문에 배포 또한 되지 않는...... 너무 속상한 상황에 빠져 있었습니다.


   원인 파악: 애초에 왜 에러가 났을까?

부끄럽지만 저는 지금까지 라이브러리를 다운받을 때 한 번도 리액트 버전을 확인해 본 적이 없었어요. 운이 좋았던 건지 지금까지 리액트 버전으로 인해 충돌을 겪었던 적도 없었습니다. 이유를 감히 추측해보자면, 주로 네임드 라이브러리만 사용해서 버전 업데이트가 빨랐거나 정~말 운이 좋게 버전이 맞는 라이브러리들만 사용했던거겠죠?

 

아무튼 위와 같은 저의 안 좋은 습관때문에 당연히 toast-ui/editor 라이브러리를 사용하기로 했을 때도 리액트 버전을 체크하지 않았습니다. 사실 npm install을 할 때, 당연히 에러가 났었는데... 무시하고 --force 설치를 감행했습니다,, 라이브러리 다운받을 때 에러 자세히 체크 안하고 무작정 --force install하는 것도 정말 안좋은 습관인 것 같아요. 지금부터 꼭! 고쳐야겠습니다. 😓😓

 

 


 

   이번 에러를 통해 배운 것들

0. peerDependencies

매번 프로젝트를 진행하며 그냥 디펜던시와 dev 디펜던시는 봤어도, 이번에 "peerDependencies"는 처음봐서 어떤 개념인지 당장 찾아보았습니다. 이번 에러를 계기로 각종 라이브러리 package.json을 찾아봤는데 리액트 버전은 전부 peer 디펜던시로 표시되어 있어서 정확한 의미가 뭔지 너무 궁금했어요!

 

라이브러리에서 직접적으로 import해서 쓰진 않지만, 호환성은 필요한 경우 peerDependencies로 명시

 

제가 이해하기로는,

- 라이브러리 자체에서 우리 프로젝트에 리액트를 직접 import해주지는 않아요. (그렇기 때문에 더더욱 버전 호환성을 명시하는 게 중요한 값이라 생각됩니다.)

- 하지만 해당 라이브러리를 사용하려면 특정 리액트 버전을 사용해야 해요.

=> 위의 경우에 버전을 peerDependencies로 표시해주는거죠!

 

만약 라이브러리에서 리액트 버전이 일반 디펜던시로 관리된다면, 사용하고자 하는 라이브러리를 다운받을 때마다 다양한 리액트 버전이 프로젝트에 설치되겠죠,,? 이렇게 생각해보면 peer 디펜던시의 필요성이 한 번에 이해가 되는 것 같아요.


1. 라이브러리를 다운하기 전에 package.json으로 호환성 확인하기

toast-ui/editor 라이브러리에 명시된 리액트 버전

 

이번 에러의 가장 핵심적인 원인이었고, 핵심적인 배움인 것 같습니다.

"특정 라이브러리 다운하기 전에, 라이브러리가 요구하는 리액트의 버전을 확인해야 한다."

 

 

리액트의 버전은 해당 라이브러리 코드의 package.json - peerDependencies에서 확인할 수 있습니다! 늦었지만 이제와서 toast-ui/editor 라이브러리의 package.json을 확인해보니 리액트 버전이 떡하니 17.0.1이라고 명시되어 있더라구요. 더 늦기 전에 이제라도 깨달음을 얻어서 다행이죠? ><

 

   솔루션: 호환되는 새로운 라이브러리 발견!

이번 에러의 솔루션은 호환성이 맞는 새로운 마크다운 에디터 라이브러리를 찾는 것이었습니다.

 

사실 처음에는 무작정 저희 프로젝트의 package.json에서 리액트 버전을 17로 바꿔.. 봤는데요,,, 지금보다 더 엄청난 에러들이 쏟아져 나오더라구요,,, 하핫 다른 설치되어 있는 라이브러리들은 고려하지 못한 너무 1차원적인 생각이었던 것 같습니다.

 

@uiw/react-md-editor 라이브러리에 명시된 리액트 버전

솔루션이 되어줄 새로운 라이브러리를 하나 발견해서, package.json을 살펴보니 리액트 16.8.0 이상 버전이면 호환 가능하다라고 명시되어 있는 것을 확인했습니다. 따라서 기존의 라이브러리에서 해당 라이브러리로 변경하여 체크인 페이지 개발을 마무리지을 계획입니다!

 

이렇게 라이브러리를 변경해줌으로써, 하나의 에러를 해결했는데

1. Sentry 설치 에러 2. 배포 에러 총 2가지 문제를 모두 해결하게 되는 셈이네요! 완전 럭키 에러 ~🍀✨

정말 중요한 습관 하나를 기르게 해준 에러같아서 뿌듯(?)하네요! 에러 이해 못했을 때는 답답함을 꽤 겪었지만요..ㅎㅎ


 

변경 전 라이브러리
(이제와서 제대로 찾아보니 21년이 마지막 업데이트였다 ...
라이브러리를 선정하는 것 자체도 되게 중요한 개발 포인트인것 같다,, 개발자마다 라이브러리를 선정하는 기준이 있는지 궁금해졌다 🤔 나도 한번 고민해봐야겠다! 일단 최근 업데이트 현황 확인하기,,ㅎㅎ,,,ㅎ)

https://www.npmjs.com/package/@toast-ui/editor?activeTab=code

 

@toast-ui/editor

GFM Markdown Wysiwyg Editor - Productive and Extensible. Latest version: 3.2.2, last published: 2 years ago. Start using @toast-ui/editor in your project by running `npm i @toast-ui/editor`. There are 78 other projects in the npm registry using @toast-ui/e

www.npmjs.com

 

변경 후 라이브러리

https://www.npmjs.com/package/@uiw/react-md-editor/v/4.0.4?activeTab=code

 

@uiw/react-md-editor

A markdown editor with preview, implemented with React.js and TypeScript.. Latest version: 4.0.4, last published: 5 months ago. Start using @uiw/react-md-editor in your project by running `npm i @uiw/react-md-editor`. There are 135 other projects in the np

www.npmjs.com


라이브러리 변경 후 배포 성공

 


1. 실제 업무에서 어떤 라이브러리가 필요한데, 버전이 맞는 라이브러리가 없다면 어떻게 대처하는지 궁금하다.

2. 나중에 시간되면 지금까지 주로 사용했던 라이브러리들 리액트 호환 버전 정확히 찾아봐야겠다.