앱 번들에 건 패치는 포크한 캘린더 플러그인을 고치지 못했습니다

앱 번들을 직접 고치는 패치와 같은 플러그인을 업로드 플러그인으로 포크한 것은 적용 범위가 달랐습니다. 이 글은 커밋 하나(791ee078f3e0)를 따라갑니다. 무엇이 닿지 않았고, 무엇을 어디로 옮겼고, 무엇은 끝내 옮기지 못했는지를 정리합니다.

먼저 밝혀 둡니다. 커밋에는 이 패치를 처음 만들 때 무엇을 기대했는지가 남아 있지 않습니다. 화면에서 일정이나 색이 실제로 사라졌다가 돌아왔는지를 확인한 기록도 없습니다. 아래 내용은 커밋 메시지에 적힌 설계와 그 이유입니다.

알려진 것: 패치는 번들 안에 걸려 있었습니다

patch-sp.js라는 스크립트는 앱 번들 안의 google-calendar-provider를 고칩니다. 커밋 제목은 이것을 “번들 플러그인에 걸던 asar 패치 두 가지"라고 부릅니다. 두 가지는 지난 일정을 보이게 하는 것과 캘린더 색을 붙이는 것입니다.

실제로 확인한 것: 포크는 업로드 플러그인이었습니다

문제는 포크가 앱 번들 안에 있지 않다는 점입니다. 커밋은 이 포크가 업로드 플러그인이라서 번들을 고치는 패치가 닿지 않는다고 적었습니다. 그래서 원본을 끄고 포크만 쓰면 지난 일정과 캘린더 색을 다시 잃는다고 설명합니다.

정리하면, 커밋에 따르면 패치는 번들 안의 google-calendar-provider를 고치며, 업로드 플러그인인 이 포크에는 닿지 않습니다.

둘의 차이를 메우는 방법: 패치를 포크 소스로 옮겼습니다

지난 일정: 조회 시작점을 45일 전으로 당겼습니다

커밋은 조회 시작 시각(timeMin)을 45일 전으로 낮췄습니다. 이유는 월간 격자의 모양에 있습니다. 월간 격자는 그 달 1일(최대 31일 전)부터 그 앞의 패딩(최대 6일)까지 칸을 그립니다. 31일과 6일을 더해도 45일 안에 들어가므로, 데이터만 있으면 지난 칸에도 일정이 그려진다는 것이 커밋의 설명입니다.

조회 상한: 250건으로 올렸습니다

조회 구간을 넓히면 따라오는 문제가 있습니다. 커밋에 따르면 조회 구간은 2주에서 약 8주로 늘어납니다. 그래서 한 번에 받는 상한(maxResults)도 250으로 올렸습니다.

이유는 정렬 방식입니다. 시작 시각순(orderBy=startTime)으로 정렬한 채 상한을 두면, 상한에 걸릴 때 뒤쪽, 즉 미래 일정이 잘린다는 것이 커밋의 판단입니다. 실제로 일정이 잘린 것을 본 기록이 아니라, 상한에 걸리면 이렇게 된다는 설계상의 추론입니다. 같은 논리로, 250건도 상한이므로 이 구간에 그보다 많은 일정이 있으면 같은 일이 다시 일어날 수 있습니다.

캘린더 색: 별도 목록에서 받아 붙였습니다

캘린더 색은 일정 응답(events)에 들어 있지 않습니다. 커밋은 캘린더 목록(calendarList)의 backgroundColor를 받아 각 일정에 붙이는 방식을 택했습니다.

여기에 두 가지 판단이 더해졌습니다. 첫째, 읽기 경로는 주기적으로 도는데 캘린더 색은 그렇게 자주 바뀌지 않으므로 색에는 10분 캐시를 둡니다. 둘째, 색 조회가 실패하면 마지막으로 알려진 색을 유지합니다. 커밋은 그 이유를 “색은 장식이고, 일시적 실패로 띠가 깜빡이는 편이 나쁘다"고 적었습니다.

예외도 하나 있었습니다. 설정에서 캘린더를 고르지 않으면 캘린더 id가 문자열 ‘primary’가 됩니다. 그런데 calendarList는 실제 주소를 돌려줍니다. 둘이 서로 맞지 않으므로, 커밋은 ‘primary’와 실제 주소 양쪽에 같은 색을 걸었습니다.

옮기지 못한 것: 코어 컴포넌트는 포크 밖에 있습니다

모든 패치를 포크로 옮길 수 있었던 것은 아닙니다. 커밋은 Planner와 Today 칩의 띠는 코어 컴포넌트를 고쳐야 하는 부분이라 이 포크로 대신할 수 없다고 적었습니다. 그래서 결론은 patch-sp.js가 계속 필요하다는 것입니다.

결과적으로 패치는 두 갈래로 나뉘었습니다. 플러그인 안에서 끝나는 동작(조회 구간, 상한, 색 붙이기)은 포크 소스로 들어갔습니다. 코어 컴포넌트를 건드리는 부분(칩의 띠)은 번들 패치에 남았습니다.

검증 기록에 남은 것

커밋에 적힌 검증은 두 가지입니다. 테스트 24건(라우팅·삭제·조회)이 통과했고, tsc –noEmit이 통과했습니다. 이것은 커밋 기록에 적힌 내용이며, 화면에서 지난 일정과 색이 실제로 보이는지를 확인했다는 기록은 아닙니다.

그래서 무엇이 달라지는가

이 사례에서 드러난 것은 적용 범위의 차이입니다. 커밋에 따르면 patch-sp.js가 고치는 대상은 앱 번들 안의 google-calendar-provider이고, 업로드 플러그인으로 쓰는 포크는 그 범위 밖이었습니다.

비슷한 구조에서 번들 플러그인을 포크한다면, 이 커밋이 한 것처럼 두 가지를 따로 따져 볼 만합니다. 하나는 번들에 걸려 있던 패치 중 무엇이 그 플러그인을 고치고 있었는지입니다. 다른 하나는 그중 무엇이 플러그인 안에서 끝나고, 무엇이 코어 쪽을 건드리는지입니다. 이 사례에서 앞의 것은 포크 소스로 옮길 수 있었고, 뒤의 것은 번들 패치로 남겨야 했습니다.