[회고] 사이드 프로젝트 - Github Issue Tracker (크롬 확장프로그램) 회고 📝

들어가며

이 시리즈는 올해 제가 개인 프로젝트를 진행했던 과정, 진행하면서 느꼈던 점을 적어놓는 글입니다. 여러분께 도움이 될만한 내용이 없을 수 있음 알려드립니다. 그냥 제 일기장 중 한페이지라고 보시면 됩니다. 📖 (대신 훔쳐봐도 상관없는 일기장)

 

---

Github Issue Tracker

 

얼마전 DND 6기가에서 진행한 프로젝트가 마무리되고,, 갑자기 개인 프로젝트가 하고 싶어졌다.

다만, 이번에는 보여지기식이 아니라 진짜로 누군가가 활용할 수 있는 프로그램을 만들고 싶었다!  한창 팀(회사)에 적응하고 있을 때이다보니 사우들에게 도움이 될 수 있는 것을 만들면 좋지 않을까 하는 생각이 들었다. 이왕 하는거 진짜로 유용성을 생각하면서 만들어보자! 하는 마음으로 ~

 

괜시리 어려운 주제를 골라버리면 여러 해결하기 어려운 문제들에 치이다가 또 저 한 켠에 버려진 '아쉽게 완성은 하지못한 프로젝트 712호' 정도로 남아버릴 것 같아서 최대한 내가 혼자서도 마무리지을 수 있는 주제로 고르기로 했다. 그렇게 고민하다보니 어렵지 않게 만들 수 있으면서 실제로도 쓰일만한 수준의 프로젝트로는 크롬 플러그인이 적격이었고,  때 마침 평소에 종종 있으면 좋겠다고 생각했던 깃허브 이슈 트래킹을 도와주는 플러그인을 개발하기로 결정했다. 🙂

 

기능은?

 

여기서 '트래킹' 이란, 트래킹이지 사실 내가 봤던 이슈들을 어떤 웹 페이지에서도 바로바로 확인할 수 있고, 쉽게 이동할 수 있는 기능을 말한다. 하루종일 근무중에 제일 많이하는게 이슈 타고 다니면서 내용 파악하는건데 요걸 더 편하게 사용할 수 있으면 얼마나 좋을꼬? 하는 생각을 바탕으로 기획했다.  만들면서 몇 가지 기능이 추가되기도 했지만, 내가 기획한 큰 기능들은 아래와 같다.

• 열람한 이슈 / 미열람 이슈 하이라이팅
• 깃허브 최근 이슈 모달 
  • 검색 기능
  • 이슈 핀 기능
  • 이슈 필터링 기능
• 가장 마지막에 본 이슈로 이동 (단축키) 

 

개발과정

 

기술 스택은?

• 기본적인 코드 작성 : TypeScript를 기반으로한 Svelte
• 빌드 : rollup-js
• 크롬 제공 API (chrome extension doc)

언어는 제일 익숙한 타입스크립트, 어차피 대규모 작업이 필요한 것도 아니고, 유지보수가 잦지도 않을 것 같아서 프레임워크는 사실 뭘 쓰던 상관없었고, 평소 체험해보고싶었던 Svelte를 사용해보기로 했다. 하도 Svelte 좋다는 글들을 많이 봤었어서 궁금했다 ㅎㅎ

 

Svelte

 

평소에 React만 주구장창 사용하다가 새로운 걸 써보니까 원래 새로운 시작이 늘 그렇듯이 불편함 반, 흥미로움 반이었다. 

 

https://svelte.dev/

 

Svelte • Cybernetically enhanced web apps

 

스벨트의 가장 큰 특징으로는 virtual DOM을 쓰지 않고도 reactive 하다는 점이다!

그게 가능한 이유로는 컴파일 타임에 바닐라스크립트로 변경되고, 이 때 어떤 부분이 reactive해야하는지를 미리 정의해놓는다고 한다. 요런 포인트가 중요한 것 같아서 기억하려고 하는데 사실 100% 직관적으로 이해되지는 않았다 ㅋ;; 나중에 스벨테가 내 주 업무가 된다면 그 때 더 깊게 파고 들어가보는걸로....ㅎ (암튼 빠르고 편하다구용ㅋㅋ)

 

참고 : https://velog.io/@vnthf/svelte%EA%B0%80-%EB%B9%A0%EB%A5%B8-%EC%9D%B4%EC%9C%A0

svelte가 빠른 이유

 

편했던 점

 

가장 편했던 점은 css(디자인), HTML(마크업), JS(돔 컨트롤) 세 가지가 한 파일에 들어있다는 점이었다. 파일이 확실히 깔끔하게 정리가 되고, css 관리할 때 별다른 플러그인이나 구조 설계 없이도 커스터마이즈 하기가 매우 쉽다. (물론 작은 프로젝트라 그런 이점을 가져갈 수도 있었던 것 같다.)

 

어려웠던 점

편했던점은 잘 안떠오르는데 어려웠던 점은 꽤나 많이 떠오른다.. ㅎㅎㅎ 그 중에 가장 큰 것이 바로 레퍼런스의 부재  이다.

 

사실 개발하다보면 내가 개발자인지 구글러인지 헷갈릴 때가 있다(?)

정보의 홍수인 킹갓 React와는 다르게 검색해도 잘 안나오다보니까 한번 까다로운 문제에 닥치니까 하루이틀을 그 문제 해결하는 데에 올인하는 일이 발생했다... (크롬 api 도 마찬가지였다..)

그 중 하나는 옵션 설정 페이지에서 크롬 스토리지 로드했을 때, 로드된 스토리지가 화면 렌더링에 반영이 안됐던 점... 겨우 해결했당ㅋ

 

 

---

번들링 - rollup.js

 

rollup.js

번들러로는 Rollup JS 를 사용했는데, webpack만 써본 나로서는 새로운 번들러를 사용해보는 것이 필요했기 때문이다. (다른걸 써봐야 기존에 쓰던게 좋은지 안좋은지 알 것이니 ㅋㄷ) 

 

사실 webpack과 큰 차이점은 못느꼈는데, 속도도 빠른 것 같고, 명령어도 심플하고 좋았다.

개인적으로 config도 뭔가 webpack보다 직관적이다. 

 

아래는 실제 내가 사용했던 rollup.config.js

import svelte from 'rollup-plugin-svelte'
import commonjs from '@rollup/plugin-commonjs'
import resolve from '@rollup/plugin-node-resolve'
import livereload from 'rollup-plugin-livereload'
import { terser } from 'rollup-plugin-terser'
import sveltePreprocess from 'svelte-preprocess'
import typescript from '@rollup/plugin-typescript'
import css from 'rollup-plugin-css-only'

const production = !process.env.ROLLUP_WATCH

const plugins = [
  svelte({
    preprocess: sveltePreprocess({ sourceMap: !production }),
    compilerOptions: {
      dev: !production,
    },
  }),
  css({ output: 'bundle.css' }),

  resolve({
    browser: true,
    dedupe: ['svelte'],
  }),
  commonjs(),
  typescript({
    sourceMap: !production,
    inlineSources: !production,
  }),

  !production && serve(),
  !production && livereload('public'),
  production && terser(),
]

function serve() {
  let server

  function toExit() {
    if (server) server.kill(0)
  }

  return {
    writeBundle() {
      if (server) return
      server = require('child_process').spawn('yarn', ['start', '--dev'], {
        stdio: ['ignore', 'inherit', 'inherit'],
        shell: true,
      })

      process.on('SIGTERM', toExit)
      process.on('exit', toExit)
    },
  }
}

export default [
  {
    input: production ? 'src/main.ts' : 'src/dev.ts',
    output: {
      sourcemap: !production,
      format: 'iife',
      name: 'main',
      file: production ? 'public/dist/main.js' : 'public/dist/dev.js',
    },
    plugins,
    watch: {
      clearScreen: false,
    },
  },
  {
    input: 'src/pages/popup/index.ts',
    output: {
      sourcemap: !production,
      format: 'iife',
      name: 'popup',
      file: 'public/dist/popup.js',
    },
    plugins,
  },
  {
    input: 'src/pages/options/index.ts',
    output: {
      sourcemap: !production,
      format: 'iife',
      name: 'options',
      file: 'public/dist/options.js',
      inlineDynamicImports: true,
    },
    plugins,
  },
  {
    input: 'src/background.ts',
    output: { name: 'background', file: 'public/dist/background.js', sourcemap: !production },
    plugins: [
      typescript({
        sourceMap: !production,
        inlineSources: !production,
      }),
    ],
  },
]

 

크롬 API

 

https://developer.chrome.com/docs/extensions/reference/

API Reference - Chrome Developers

크롬 API v2 가 deprecated 된다는 말이 있어서, v3을 사용했는데, 이 부분이 사실 하나의 어려움으로 작용했다.

 

v2에서 v3으로 넘어가면서 크롬 스토리지나 크롬 플러그인 관련 api 문법들이 꽤많이 바뀌었다. 그런데다가 검색해서 나오는 레퍼런스들은 죄다 v2 에 관한 내용들이었고, 크롬 플러그인 만드는사람이 생각보다 적은 것 같다는 것을 느꼈다. 사실 주 업무로 크롬 플러그인을 만드는 사람들은 거의 없을테니께.. 결국 삽질을 피할수가 없었다... 

사실 크롬 api 문서에 내용들이 나와있긴 한데, 요새 잘나오는 문서들에 비하면 뭔가 가독성이 떨어진다... 중복되는 내용들도 있고 내가 원하는 내용 찾기가 은근 쉽지 않았다. 그래도 결국에는 다 찾아내거나 해결한 내 자신에게 칭찬을..🤓

 

 

배포

개발에서 기능이 모두 구현되고, 이제 배포할 때가 되었다. 배포를 해야 남들도 다같이 쓸 것 아니오?

처음에는 사용하고자 하는 사람이 코드가 담겨져있는 레포 들어가서 직접 소스코드 zip파일을 다운받아서 쓰는 방식으로만 생각하고, 다운받아서 크롬 확장프로그램을 추가하는 방식을 README를 작성했었다. 요게 생각보다 간편하거덩ㅋ 근데 사람들은 그것마저 귀찮아한다는걸 안다. 왜냐? 내가 해도 귀찮거덩ㅋ

 

근데, 우리 킹갓 팀원분께서 '미등록 게시 방식' 을 알려주셨다. (https://support.google.com/chrome/a/answer/2714278?hl=ko)

'미등록 게시 방식' 이란 크롬에서 해당 플러그인에 대한 private 링크를 제공해주고 그 링크를 타고 들어온 사람만이 플러그인 설치가 가능한 방식이다!

 

처음 결과물은 사내 깃허브 이슈용이었기 때문에 요게 너무나도 적절한 방식이었고, 이 방식으로 배포를 하기로 하였다.

 

그런데!! 🤪

 

크롬 플러그인 배포.. 이 녀석... 보통 녀석이 아니다. 

 

 

우선 돈내고 개발자로 등록해야한다. 이건 뭐 그럴 수 있다 치자. 그 이후에 배포할 때 뭐 이렇게 요구사항이 많은지, 어떤 역할이고 무슨 기능을 담고 있는지 와 같은 세부 내용들을 성의있게 모두 작성해야되며,

설정값(chrome manifest.json) 에 하나라도 불필요한 크롬 API 기능이 추가되어있으면 바로 반려가 난다........ 거기다가 썸네일 아이콘, 기능이 작동하는 사진 등등도 첨부해야 되는데, 이 사진들도 사이즈, 용량 조건까지 되게 까다롭다. 까탈스럽다고 표현하는게 더 맞는 것 같다 ㅋㅋ

 

아무튼 이런 까탈스러운 크롬 플러그인 배포 조건 때문에 반려를 한 3~4번 이상은 당하고 (승인 요청부터 결과 나오는 데까지도 최소 2~3일은 소요된다.) 배포 하는데에만 1달 이상이 걸렸던 것 같다. 개발은 중간중간 재밌기라도 하지, 이거는 고런 희열도 없고 답답하고 스트레스 받는다ㅋㅋ 대신 배포 성공했을 때는 한달 묵힌 변비가 내려가는듯한 통쾌함이 있긴 했다.

 

배포 페이지

 

---

결과물

 

https://github.com/SeoSang/github-issue-tracker

GitHub - SeoSang/github-issue-tracker

 

결과물 사진이다. (https://github.com/SeoSang/github-issue-tracker)

 

근데 사실 진짜 완성품은 oss-issue-tracker 이다.  왜냐면 사내 깃허브 이름이 OSS 거덩ㅋ

히든링크를 통해 들어오면 위 사진과 같은 페이지가 뜨고, 설치 후 바로 사용이 가능하다. 

 

이 것을 조금 수정해서 오픈소스용 github-issue-tracker로 만들려고 했다. 그냥 깃허브 페이지 Element  읽어오는 부분만 수정하면 돼서 크게 어려운 부분은 아니었지만 진짜 나에게 허탈감을 준 문제는 따로 있었다

 

다 만들었더니 우연히 이 영상을 발견했다... 

 

https://www.youtube.com/watch?v=2tK0txsNd6U&t=96s 

 

 

깃허브에 커멘드 파레트라는 기능이 새로 나왔네?? 😇

내가 원했던 기능을 거의 다 담고있다 ㅎㅎ 

ㅠ

https://docs.github.com/en/get-started/using-github/github-command-palette

GitHub Command Palette - GitHub Docs

이런 불운이 있나.. 매우 슬펐지만 다행인거는, 사내 github 의 버전은 아직 커맨드 파레트가 없다는 점이었다. 다행히(?) 아직까지도 커맨드 파레트는 지원하지 않는다.

 

그래서 이게 github issue tracker로 옮기다가 이게 뭔 의미가 있나 싶어서, 옮기긴 했는데 그냥 2~3일만에 대충 옮겨놨다. (그래서  아마 버그가 있을수도 있다...ㅎ)

 

배포된 oss-issue-tracker

 

그냥 사내용 이슈 트래커를 끝까지 완성했다는 것(무려 45명의 사우님께서 설치해주셨다!) 게다가 그걸 누구보다 내가 잘 활용하고 있다는것으로 만족하기로 했다. 😀

 

 

---

마치며

 

위에서 생각나는 말들을 생각나는대로 고대로 적어뒀더니 마무리때 할말이 별로 없구만.. ㅋ

다만 한 가지 드는 생각은, 다음 사이드 프로젝트는 혼자 말고 협업 프로젝트를 하고 싶다! 

DND로 팀 프로젝트 마무리 -> Github-Issue-Tracker (솔로 프로젝트) -> 이제 팀 프로젝트 차례

역시 그래도 프로젝트는 다 같이 해야 제맛인갑다. 협업하면서 오는 스트레스도 있지만 고걸 또 해결해  나가는 재미가 있으니까 ㅎㅎ

내년 쯤에 한번 적극적으로 추진해보기로 ~~~~~