ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [바닐라코딩 6기] 자바스크립트 에러 트래킹 모듈 / 파이널 프로젝트 후기 - Vanilla Coding Bootcamp 6
    Review, Chat 2019. 11. 21. 16:19

     

     

    파이널 프로젝트가 끝났다.

    부트캠프도 끝났다.

     

    좀 진부한 얘기지만 부트캠프 시작한지 별로 안된 것 같은데 어느새 끝이라니.

    시간이 참 빨리 간다.

     

    지난주 토요일에 파이널 프로젝트 발표회가 있었다.

    이전 기수를 수료하고 현재 개발자로 일하시는 분들과

    다음 기수 사람들이 우리들이 하는 발표를 들으러 왔다.

    우리 기수 사람들끼리 소소하게 발표했던 1차 프로젝트때와 분위기가 많이 달라서 정말 떨렸다.

     

    하필 발표 순서가 맨 마지막이어서 더욱 떨렸던 것 같다.

    그래도 발표 연습을 많이 했어서 떨렸지만 무사히 잘 끝냈다.

     

     

    오늘은 내가 2주라는 시간 동안 어떤 프로젝트를 어떻게 기획해서 어떻게 구현했는지에 대한 소개와

    다 끝내고나서 지난 시간들을 뒤돌아보며 어떤 부분이 발전했고 어떤 부분이 아쉬웠는지를 정리해보려고 한다.

     

     

     


     

     

     

    Bugcide Preview

     

     

    Bugcide, 에러 트래킹 모듈

    내가 파이널 프로젝트로 만든건 Bugcide라는 이름의 자바스크립트 에러 트래킹 모듈이다.

    그러니까 쉽게 말해서 자바스크립트로 프론트엔드 개발을 할 때 

    내가 만든 Npm Module을 설치해서 적용하면

    프로젝트를 진행하는 동안에 발생한 에러들을 수집해서 기록해준다.

    (React 프로젝트의 경우에는 Npm Module 외에 Webpack Plugin도 설치해야한다.)

     

    재미있는 부가 기능으로 에러가 동시다발적으로 많이 발생하면

    콘솔 창에 응원 메시지를 띄워주는 기능이 있다.

     

    Bugcide는 내가 try catch문으로 핸들링한 에러들은 수집하지 않는다.

    그러니까 즉, 내가 미처 핸들링하지 못해서 발생하는 에러들을 기록해주는 모듈인 셈이다.

     

    지원하는 개발 환경은 바닐라 자바스크립트와 리액트이다.

    자세한 기능에 대한 설명과 코드는 아래 GitHub repository에서 확인할 수 있다.

     

     

    Why Bugcide?

    프로젝트 이름은 Insecticide(살충제)라는 영어 단어에서 영감을 받았다.

    벌레를 박멸할 때 쓰듯이 자바스크립트 에러를 박멸하자(?)는 취지이다.ㅎㅎ

     

    개발자에게 에러란 존재는 뗄레야 뗄 수 없는 그런 존재이다.

    사실 개발자라는 직업 자체가 평생 에러와 함께 해야하는 직업이라고 생각한다.

     

    예전에 어떤 사람이 개발 커뮤니티 사이트에

    에러를 볼 때마다 너무 스트레스가 쌓인다고 고민 글을 써놓은 것을 본 적이 있다.

    평생 함께 해야 하는 에러를 볼 때마다 스트레스를 받는다면 

    개발자로 일을 하는 것이 얼마나 고통스러울까?

     

    나는 에러가 발생해서 해결하는 그 일련의 작업을 재미있어하고 즐기는 편이지만

    그래도 예상치 못한 에러가 갑자기 발생해서 당황한 순간들을 많이 겪었고 앞으로도 계속 겪을 것이다.

     

    에러들을 그냥 외면하고 지나치는 것이 아니라 어딘가에 기록을 해두고
    내가 언제 어떤 에러를 발생시켰는지 나중에라도 꺼내볼 수 있다면 얼마나 좋을까?

     

    그렇게해서 개발하게 된 것이 Bugcide이다.

    에러를 봐도 기분이 좋을 수 있도록 디자인을 신경써서 예쁘게 만들었다.

     

    에러 메시지 검색을 조금이라도 편하게 하라고 버튼 하나만 클릭하면

    에러 메시지로 구글 검색을 하도록 만들었다. 

    예쁜 그래프로 시각화도 해준다.

     

    에러가 일정량 발생하면 콘솔 창에 따뜻한 응원 메시지도 띄워준다.

     

     

     

    Project Scheduling

    1차 프로젝트때와 비슷한 2주 반 정도의 시간이 주어졌는데

    이미 프로젝트 경험을 해봤던터라 아이디어를 전개하고 기획하는 시간을 단축시킬 수 있었다.

     

    이번에는 Client와 Server를 구축하는 것 뿐만 아니라

    Npm Module까지 만들어야했기 때문에 기획을 할 때

    너무 많은 기능을 넣기보다는 핵심 기능 위주로 넣기로 했다.

    기능을 단순하게 넣으면서도 최대한 완성도 높게 결과물을 만드는 것이 목표였다.

     

     

     

    이번에도 Trello를 활용하여 프로젝트 Task 관리를 하였다.

    일정을 넉넉하게 짜는 대신에 일정 보다 빠르게 단축시킬 수 있으면

    최대한 단축시키는 방향으로 진행하였다.

     

    지난 번 프로젝트 때 보다는 Task를 만들 때 상세하게 기획하였고

    본 기능 구현을 할 때 변동하는 부분이 없게끔 공들였다.

    결과적으로 1차 프로젝트에 비해서 기능 구현할 때 기획을 변경하는 일이 거의 없었고

    후반부에 시간적으로 여유가 생겨서 E2E 테스트 등 다양한 테스트 코드를 작성해볼 수 있었다.

     

    기획이 바뀐 부분은 이런 이유 때문이었다.

    나는 처음에 브라우저 에러만 잡으면 바닐라 자바스크립트 프로젝트 뿐만 아니라

    리액트 프로젝트의 에러들도 전부 잡을 수 있을 것이라 생각했다.

     

    그런데 리액트 프로젝트의 경우에는 모든 Syntax 에러가

    Webpack compile 단계에서 발생해서

    브라우저에서는 전혀 잡히지 않았다.

     

    그래서 이 부분을 고민하다가 Webpack Plugin을 만드는 방법으로 해결하였다.

     

     

     


     

     

    아쉬운 점

    이번 프로젝트에서 가장 아쉬운 점은 처음 생각했던대로

    기능 구현을 최대한 줄이고 단순한 기능을 완성도 높게 구현하자는 것이었는데,

    막상 다 완성하고 나니까 기능을 조금 더 추가해볼 걸 그랬다는 아쉬움이 남았다.

    차트도 딱 2개밖에 넣지 못한 점도 아쉽다.

     

    추후에 에러 즐겨찾기 기능이나 

    에러별로 사용자가 개인 메모를 작성할 수 있도록 하는 메모 기능도 만들고 싶다.

    (그런 기능을 추가하면 에러 해결 방법을 적어두고 공부하기에 참 좋을 것 같다.)

     

    이번 프로젝트에서는 프론트 환경에서의 에러만 잡아주는데

    Node.js 환경에서 발생하는 서버 에러를 잡지 못해서 아쉽다.

    시간이 난다면 Node.js도 지원하도록 만들고 싶다.

     

     

     

    지난 프로젝트에 비해서 나아진 점

    지난 프로젝트를 했을 때 가장 아쉬웠던 점은 짧은 시간 내에 리액트 네이티브로 구현하면서 

    리덕스를 적용하지 못했고 프로젝트 구조가 깔끔하지 못했다는 점인데

    이번 프로젝트 때는 리덕스를 적용하여 상태 관리를 했고

    프로젝트 구조와 코드를 최대한 깨끗하게 관리하였다.

    Presentational Component와 Container도 완벽하게 분리하였다.

     

    에러가 발생할 때마다 디비 스키마에 시간대별 에러 발생량과

    에러 타입별 에러 발생량을 따로 저장하여

    그래프를 그릴 때 서버에서 저장된 수십개, 수백개의 에러 정보를

    모두 가져와서 계산하는 일이 없도록 하였다.

     

    가장 많이 신경쓴 부분은 브라우저 에러가 갑자기 

    동시다발적으로 여러 개가 발생하는 케이스였다.

     

    서버에 각각 API 요청을 보내는 것이 아니라

    약 2초 동안의 시간을 두고 에러를 배열에 담아서 한꺼번에 요청을 보내도록 했다.

    또한 연속적으로 동일한 에러가 발생하는 경우에

    에러를 합쳐서 횟수를 기록하여 전달하는 방식으로 배열을 압축해서 요청을 보내도록 만들었다.

    이 부분에 대해서는 내가 생각한 방법 외에 더 좋은 방법이 있는지 계속 생각중이다.

     

    그 외에도 이번에는 지난 번 프로젝트에 비해서 프론트엔드 테스트 코드를 다양하게 작성해보았고

    Cypress를 이용해서 E2E 테스트도 경험해보았다.

    사용자의 입장에서 테스트를 진행해보고 그 과정을 시각적으로 보여주는 E2E 테스트는 정말 신기했다.

    (게다가 실제로 이 테스트를 통해서 내가 생각치 못했던 버그를 수정할 수 있었다.)

     

     

     

    프로젝트를 마치며

    이번 프로젝트를 통해서 좋았던 점은

    단순히 프론트 페이지만 만든 것이 아니라 다양한 경험을 해볼 수 있었다는 점이다.

    React로 프론트 사이트도 만들고 Node.js로 서버도 만들고

    Npm Module이랑 Webpack 플러그인도 각각 만들어서 배포해보았다.

     

    지금까지는 항상 Create React App(CRA)을 사용해서

    이미 세팅이 다 완료된 앱만을 만들어보았는데

    이번에 처음으로 Webpack 설정부터 Babel, Style Loader등

    나에게 필요한 모듈들을 직접 다운로드하고 컴파일하여 리액트 앱을 시작하는 경험을 해보았다.

     

    Npm Module이나 Webpack Plugin같은 것들은

    항상 남이 만든 것을 다운받아서 쓸 줄만 알았지

    내가 직접 만들어서 배포하는 것은 상상해본 적도 없는데

    이번 프로젝트를 통해서 이런 모듈들이 어떤 식으로 만들어지고

    어떤 식으로 구동되는지를 경험할 수 있어서 많은 것을 배웠다.

     

    하나의 리액트 앱이 어떤 식으로 돌아가며 

    Webpack이 우리를 위해 어떤 작업들을 해주는 것인지 배우는 시간들이었다.

     

    이제 부트캠프도 수료했고 취업 준비만이 남았는데

    꼼꼼하게 잘 준비해서 얼른 블로그에 취업 성공 후기를 남길 수 있게 되길 바란다(!)

     

    반응형

    COMMENT