eHelper: 개인용 Selenium 스크립트를 Chrome Extension 제품으로 바꾼 과정

1. 시작은 1학년 Python 과제였다

eHelper의 출발점은 대단한 제품 아이디어가 아니라, 제가 실제로 겪던 불편이었습니다.
1학년 때 Python 과제로 프로그램 하나를 만들어야 했는데, 당시 가장 먼저 떠오른 문제는 eCampus의 과제 확인 방식이었습니다.

기존 eCampus에서는 과제 제출 여부를 확인하려면 보통 이렇게 움직여야 했습니다.

알림도 충분히 직관적이지 않았기 때문에, 한 번에 요약해서 보여주는 도구가 있으면 좋겠다고 생각했습니다.

처음에는 Python과 Selenium을 사용해 eCampus 과제 정보를 모아 보여주는 프로그램을 만들었습니다.
과제 결과로는 좋은 평가를 받았고, 저에게도 "직접 느낀 불편을 자동화로 해결할 수 있다"는 첫 경험이었습니다.

하지만 한계도 분명했습니다.

즉, 문제는 어느 정도 풀었지만 "나 혼자 쓰는 도구"에 가까웠습니다.
이때부터 eHelper는 기능보다도 형태를 다시 고민하게 된 프로젝트였습니다.

시간이 지나면서 "더 많은 학생이 바로 쓸 수 있는 형태"로 바꾸고 싶어졌습니다.
로그인된 eCampus 환경과 가까이 붙어 동작해야 했기 때문에, Chrome Extension이 가장 자연스러운 형태라고 판단했습니다.

이 선택은 단순한 UI 전환이 아니었습니다.

결국 eHelper는 기존 Selenium 스크립트를 포장한 수준이 아니라, 구조부터 다시 설계한 프로젝트가 됐습니다.

UI를 그리는 일 자체는 React 경험이 있으면 비교적 익숙합니다.
하지만 Chrome Extension은 그보다 앞단에서 고려해야 할 것이 훨씬 많았습니다.

특히 확장 프로그램은 "내 페이지 안에서만 동작하는 React 앱"이 아니라,
브라우저 환경과 권한 정책 위에서 돌아가는 제품이라는 점을 처음부터 체감하게 됐습니다.

eHelper의 목표는 단순히 데이터를 긁어오는 것이 아니라,
사용자가 실제로 확인 동선을 줄였다고 느끼게 만드는 것이었습니다.

그래서 대시보드 한 화면에서 다음을 볼 수 있도록 구성했습니다.

또 실제 탐색 흐름을 줄이기 위해 다음 필터도 함께 넣었습니다.

자료 다운로드도 확장 프로그램 안에서 이어질 수 있도록, background에서 메시지를 받아 Chrome downloads API로 처리하는 흐름까지 구현했습니다.

이 프로젝트에서 가장 어려웠던 점은 확장 프로그램 구조를 배우는 것만이 아니었습니다.
데이터를 가져오는 방식 자체가 꽤 비효율적이라는 것도 동시에 체감했습니다.

Selenium만 써봤던 상태였기 때문에, 이번에는 페이지 HTML을 직접 가져와 필요한 정보를 파싱하는 방식으로 구현했습니다.
문제는 eCampus 정보가 한 페이지에 모여 있지 않다는 점이었습니다.

결국 여러 페이지의 HTML을 모두 가져와야 했고, 이 과정에서 로딩 시간이 길어지는 한계를 느꼈습니다.

이 경험은 중요한 기준을 남겼습니다.

eHelper는 학교 커뮤니티에 공유했고, 실제 사용자가 생기기 시작했습니다.
그 과정에서 구현만으로는 끝나지 않는 요소들을 처음 많이 경험했습니다.

특히 테스트 방식이 인상적이었습니다.
로컬에서 잘 돌아가는지 보는 것과, 실제 스토어 업로드를 전제로 동작을 확인하는 것은 완전히 다른 문제였습니다.

이 프로젝트를 통해 "제품 출시"는 기능 완료가 아니라, 설치와 배포, 검수까지 포함한 흐름이라는 점을 몸으로 배웠습니다.

eHelper는 저에게서 가장 분명하게 "문제 정의에서 출발한 프로젝트"였습니다.
직접 겪은 불편이 있었기 때문에 구현 동기도 강했고, 스크립트에서 제품으로 확장하는 과정도 끝까지 밀어붙일 수 있었습니다.

이 프로젝트를 하며 배운 것은 크게 세 가지였습니다.

다시 만든다면, 여러 페이지를 직접 파싱하는 현재 구조부터 먼저 개선하고 싶습니다.
그럼에도 eHelper는 제가 "실제로 쓰이는 형태의 도구"를 만들면서 제품 관점을 가장 많이 배운 프로젝트였습니다.