eHelper: Selenium 스크립트를 Chrome Extension으로 다시 만든 과정

1. 시작은 Python 과제였다

eHelper는 처음부터 제품으로 기획한 프로젝트는 아니었습니다.
1학년 Python 과제로 프로그램을 만들어야 했고, 그때 가장 먼저 떠오른 문제가 eCampus 과제 확인이었습니다.

과제 하나를 확인하려면 대시보드에서 과목으로 들어가고, 다시 과제 페이지로 들어가 제출 여부와 마감일을 봐야 했습니다.
과목이 여러 개면 같은 과정을 반복해야 했고, 온라인 강의나 퀴즈까지 확인하려면 더 많은 페이지를 열어야 했습니다.

그래서 처음 만든 버전은 단순했습니다.

• eCampus에 접근한다
• 과제 정보를 가져온다
• 한 번에 확인할 수 있게 출력한다

Python과 Selenium으로 이 흐름을 자동화했습니다.
과제 결과는 괜찮았지만, 직접 써보니 개인용 스크립트에 가까웠습니다.

2. 스크립트로는 부족했던 점

첫 버전은 제 문제를 줄여주긴 했지만, 다른 사람이 쓰기에는 불편했습니다.

• 터미널에서 실행해야 했다
• 설치 과정이 개발자 친화적이었다
• 실제 eCampus 사용 흐름과 분리되어 있었다
• 일반 학생이 쓰기에는 진입 장벽이 높았다

이때부터는 "정보를 가져올 수 있는가"보다 "어떻게 쓰게 할 것인가"가 더 중요해졌습니다.
실행 방식이 어렵다면 기능이 있어도 계속 쓰기 어렵기 때문입니다.

그래서 eHelper를 Chrome Extension으로 다시 만들기로 했습니다.
사용자는 이미 브라우저에서 eCampus를 쓰고 있었고, 로그인된 페이지 근처에서 동작하는 확장 프로그램이 가장 맞는 형태라고 봤습니다.

3. Chrome Extension 구조로 다시 나누기

Chrome Extension으로 옮기는 일은 단순히 UI를 붙이는 작업이 아니었습니다.
Selenium 스크립트에서는 한 파일 안에서 페이지 접근, 데이터 수집, 출력까지 처리해도 됐습니다. 하지만 확장 프로그램에서는 역할을 나누지 않으면 금방 꼬입니다.

그래서 구조를 세 영역으로 나눴습니다.

• Popup UI: 대시보드와 필터 상태
• Content Script: eCampus 페이지 접근과 HTML 파싱
• Background Service Worker: 다운로드처럼 Chrome API 권한이 필요한 작업

데이터 흐름은 이렇게 잡았습니다.

1. Popup에서 과제, 퀴즈, 강의 정보를 요청한다
2. Content Script가 로그인된 eCampus 페이지의 HTML을 읽는다
3. 필요한 데이터를 파싱해 Popup으로 전달한다
4. Popup은 받은 데이터를 과목, 마감 상태, 자료 유형 기준으로 재구성한다
5. 파일 다운로드처럼 브라우저 권한이 필요한 작업은 Background로 메시지를 보내 처리한다

중요한 것은 UI와 브라우저 권한 작업을 섞지 않는 것이었습니다.
Popup은 화면 상태만 다루고, Background는 Chrome downloads API처럼 권한이 필요한 작업만 맡게 했습니다.

이렇게 나누니 문제가 생겼을 때 화면, 파싱, 브라우저 API 중 어느 쪽을 봐야 하는지 구분하기 쉬웠습니다.

4. 핵심은 한 화면에 다시 정리하는 것

eHelper가 하려던 일은 단순히 eCampus 데이터를 가져오는 것이 아니었습니다.
여러 페이지에 흩어진 정보를 한 화면에서 볼 수 있게 정리하는 쪽에 가까웠습니다.

대시보드에서는 다음 정보를 함께 보여줬습니다.

• 과목별 과제
• 퀴즈
• 온라인 강의
• 완료 여부
• 마감일

필터도 같이 넣었습니다.

• 마감 상태
• 과목
• 자료 유형
• 미완료 퀵 필터

특히 미완료 필터는 단순하지만 자주 쓰일 기능이라고 봤습니다.
전체 목록보다 "지금 해야 할 것"을 먼저 보는 경우가 많았기 때문입니다.

5. 한계는 HTML 파싱이었다

가장 까다로웠던 부분은 확장 프로그램 문법보다 데이터 수집 방식이었습니다.
eCampus의 정보가 한 페이지에 모여 있지 않았기 때문에, 필요한 정보를 얻으려면 여러 페이지의 HTML을 직접 가져와 파싱해야 했습니다.

이 방식은 빨리 만들기에는 괜찮았지만 한계가 있었습니다.

• 페이지 수가 늘어날수록 로딩 시간이 길어진다
• HTML 구조가 바뀌면 파싱 코드가 깨질 수 있다
• 사용자에게 필요한 정보와 실제 수집해야 하는 정보의 범위가 달라진다

이때 "일단 동작하는 것"과 "계속 쓰기 괜찮은 것"은 다르다는 걸 알게 됐습니다.
처음에는 데이터를 많이 가져오면 된다고 생각했지만, 실제로는 어떤 데이터를 언제 가져올지가 더 중요했습니다.

다시 만든다면 가장 먼저 개선하고 싶은 부분도 이 지점입니다.
초기 로딩에 필요한 데이터와 상세 확인 때 필요한 데이터를 나누고, 모든 페이지를 한 번에 파싱하는 구조를 줄일 것 같습니다.

6. 배포하면서 챙긴 것들

eHelper를 학교 커뮤니티에 공유하면서 실제 사용자가 생기기 시작했습니다.
이때부터는 코드 밖의 일도 같이 봐야 했습니다.

• Chrome Web Store 배포 준비
• Manifest V3 권한 설정 검토
• Host Permission 범위 정리
• 개인정보와 정책 문서 작성
• 빌드 후 업로드 기준 테스트

로컬에서 동작하는 것과 스토어에 올릴 수 있는 상태는 달랐습니다.
특히 확장 프로그램은 어떤 권한을 요청하는지, 왜 필요한지 설명할 수 있어야 했습니다.

기능이 끝났다고 바로 배포 가능한 것은 아니었습니다.
설치, 권한, 정책 문서, 업로드 후 테스트까지 같이 챙겨야 했습니다.

배포 흐름을 CI/CD 파이프라인처럼 정리하면 아래와 같습니다.

코드 수정
  ↓
로컬 빌드
  ↓
확장 프로그램 패키징
  ↓
권한 / Manifest 점검
  ↓
Chrome Web Store 업로드 (수동)
  ↓
검수
  ↓
배포

7. 정리

eHelper를 만들면서 개인용 자동화와 사용자용 도구는 기준이 다르다는 걸 알게 됐습니다.

남은 점은 세 가지입니다.

• 기능보다 실행 방식이 더 중요할 때가 있다.
• Chrome Extension은 UI뿐 아니라 권한과 메시지 흐름을 같이 봐야 한다.
• 빠르게 만든 데이터 수집 구조는 나중에 성능 문제로 돌아올 수 있다.

처음 Selenium 버전은 제가 쓰려고 만든 자동화였습니다.
Chrome Extension 버전은 같은 문제를 다른 사람도 쓸 수 있는 형태로 바꾼 작업이었습니다.

이 프로젝트는 확장 프로그램을 만들어본 경험이기도 했지만, 개인용 스크립트를 배포 가능한 형태로 다시 정리해본 경험에 더 가깝습니다.