이 글을 처음 쓰기 시작한 건 2023년 12월 6일이지만, 너무나도 쓸게 많아서 2024년 1월 1일이 되었음에도 글을 마무리하지 못한 상태이다. 처음에는 월별로 하나 이상의 큰 이벤트들에 대해 작성해보려고 했다. 2023년은 새롭게 시작한 것들도 많고, 굉장히 변화가 많은 한 해였다. 월별로 소제목을 정하다보니 너무나도 많은 일이 있었음을 발견하게 됐는데, 아쉽게도 모든 내용에 대한 회고를 작성하기에는 에너지가 부족하여,, 이 부분은 포기한다. (올해는 반기별로 회고를 남기는게 좋을 것 같다.)

기억에서 사라지는 건 또 아쉬워서 제목만 남겨본다. 매일 매일 특별할 것 없이 반복되는 일상을 보낸 듯 싶으면서도, 돌아보니 특별한 일들이 가득했다. 캘린더에 모든 것을 기록한 것 같았지만, 생각보다 메모장을 많이 사용했고, 사진을 찍었으면 좋았을법한 일이 많았다. 올해는 사진을 더 많이 찍어야겠다.

월별 메인 이벤트

1월 - 처음 해보는 취업준비 / 처음 해보는 맹장수술
2월 - 수술 후 만난 첫 회사 / 반석 기타교실
3월 - 예비군 소대장 / 마커스 워십 예배 인도자 컨퍼런스
4월 - Datadog / 클라이밍
5월 - Cloudflare
6월 - 새벽 작업(RDS Blue green 배포, 그러나 늦잠)
7월 - ECU 여름 수련회 / EKKL 신앙 특강
8월 - 스마일 라식
9월 - 러닝(무릎 부상)
10월 - Custom ESLint Rule
11월 - 배재 클래스 미션 / 수영 시작
12월 - 회복 / 청소년 세례교육

올해에는 웹 기술을 교회 연합 행사, 선교 단체, 찬양팀에 적용한 사례가 몇 가지 있었다. 반복되는 작업의 피로도를 낮추고, 소통 문제를 도구를 통해 해결해보려는 분이 있다면 이 글이 도움이 될 수 있을 것 같다.

아래의 세 가지 사례 모두 구글 스프레드 시트를 사용했다는 공통점이 있다.

1. DMC QR Reader

festa 2월에는 경신교회, 무궁교회, 반석교회, 태평교회와 함께 연합 행사를 진행하게 됐었다. 각 교회별 리더들이 모여서 행사를 준비했었다. 교회별로 사람들이 어울릴 수 있도록 조를 편성했고, 자신이 어떤 조 인지는 입장 당일에 알 수 있도록 했다. 아무래도 여러 교회에서 사람들이 많이 모일 것이 예상되다보니, 각 사람이 어느 조인지를 입장할 때 빠르게 알 수 있어야했다.

festa 에서 참가 등록을 받았고, 여기서 신청한 사람들 정보를 바탕으로 조를 편성했다. (교회 / 성별 / MBTI 등 최대한 고려했..~~지만 결국엔 휴먼 랜덤을 돌리게 됐~~다.) 이벤트 등록을 하게 되면 개인에게 티켓이 발급되는데 이 때 티켓에 QR 코드가 있다. festa 내에서도 QR코드로 체크인 기능이 존재하지만, QR 코드를 찍음과 동시에 자신이 어떤 조에 해당하는지를 함께 안내할 수가 없었다. 그래서 해당 기능을 대체할 수 있는 QR 코드 리더 서비스를 단 시간 내에 제작했다.(타입은 전혀 신경쓰지 않았고 JS로만 개발했다. GitHub) 발급된 티켓의 QR 코드를 찍게 되면 festa의 체크인 API를 호출하는 구조를 확인했다. 이 때, 해당 사용자의 티켓 번호와 함께 호출되는 것을 발견했고, QR코드로 호출되는 URL의 티켓 번호를 읽어내 하면 우리가 원하던 조 편성 안내 기능을 구현했다.

express 서버에 React로 제작한 프론트 페이지를 띄우고, 해당 서버는 Google Cloud Run을 통해 배포했다. 별도의 db는 사용하지 않고, festa로 등록한 사용자 정보를 구글스프레드 시트에 저장해놓고 사용했다. 해당 시트에 조 편성 정보를 추가로 입력한 뒤, 체크인 여부를 해당 시트에 표시함과 동시에 화면에서는 몇 조인지를 알려줄 수 있도록 했다.

festa에서 이메일로 별도의 QR코드를 보내주지는 않았었기에, festa 홈페이지에 들어가야만 QR 코드를 확인할 수 있었다. 그래서 당일에 해당 홈페이지에 로그인 후 등록한 티켓을 찾는 과정에 대한 안내가 필요했었다. 이 부분을 사전에 꼼꼼히 확인하고 소통하지 않았던게 아쉽다. ~~(어떤 분은 스프레드 시트에서 몇 조인지 확인하는게 더 빠르기도 했다..)~~ + 당시 코로나로 인한 사회적 거리두기 제한은 풀렸었으나, 맥락이 제대로 전달되지 못했어서 코로나 QR 체크로 이해하시는 분도 계셨다. (사전 안내가 부족했기에 충분히 그럴 수 있었고, 이 부분을 신경쓰지 못해 아쉬웠다.)

동대문구의 여러 교회가 연합하는 행사를 열심히 기획하고, 지금도 애쓰고 있는 타 교회 리더분들께 감사하다.

2. 주보 자동화 (ECU Weekly)

선교단체 ECU 는 학기중에 매주 토요일 학교별 연합 모임이 있다. 모임은 아래 주보에 나와있는 일정대로 주로 진행된다. 이 때 기도 / 봉독 / 목사님께서 전해주시는 말씀 / PBS 본문 이 매주 달라지기 때문에, 해당 내용을 종합해서 멤버들에게 전달하는 것이 필요했다. 기도 순서는 미리 정해져있고(가끔 변경될 수도 있고), PBS는 매주 사무엘상 한 장씩 진행됐다.(이제는 사무엘하를 하고 있다.) 기존에는 미리캔버스에 주보 양식이 작성되어있었고, 해당 양식을 수정 후, 이미지로 저장해서 박영덕 목사님 유튜브 채널 커뮤니티와 ECU 멤버들이 있는 카톡방에 금요일 저녁 혹은 토요일 아침에 업로드 했다.

weekly

위 이미지에 빈 칸을 채우기 위해서 구글 스프레드 시트에서 다음 모임에 해당할 내용을 읽어올 수 있도록 했다. 해당 서비스는Next.JS 로 작성되었고, 최초에는 Google Cloud Run으로 배포했다가 현재는 Netlify 로 배포했다.

`M월 W주` 이슈

2024년 1월 1일은 1월 첫째주 라고 말할 수 있다. 그런데 2024년 3월 1일은 3월 첫째주 라고 해도 될까? 국가기술표준원에서 정한 기준은 월요일이 주의 시작이고, 2.2.10 역주 수 부분을 보면 다음과 같이 되어있다.

2.2.10
역주 수 (calendar week number)
처음 역주의 법칙에 따르면, 역년 내, 역주를 나타내는 서수는 일 년의 첫 번째 목요일을 포함하는 수이다. 역년의 마지막 역주는 다음 역년의 첫 번째 역주 바로 이전의 주이다.

간단히 결론만 이야기하면, 2024년 3월 1일은 KSXISO8601 기준으로는 2월 5주가 된다. 한 달의 첫 번째 주는 목요일을 포함하면 그 주가 해당 월의 첫째 주가 된다. 그렇지 않으면 그 주는 그 전달의 마지막 주로 본다. 일단 이 기준을 따랐는데, 왜냐하면 매주 캠퍼스에서 전도한 통계를 종합한 내용을 주보에서 보여줄 때 M월 W주 형태의 워딩 길이가 짧았고, 그래서 이 형태로 보여주기 위해 M월 D일을 M월 W주 로 변환하는 로직이 필요했다. 이 부분을 구글 시트에서 다양한 엑셀 함수를 조합하는 식으로 작성하는 것이 좋을까, App Script를 활용할까, Next.JS 서버에서 변환하는게 좋을까 생각을 했었고, 결국에는 구글 시트에서 작성하는 방식을 선택했다. App Script를 사용하고 있는 부분이 이미 있어서 해당 로직이 추가될 때 복잡성이 증가할 것으로 보였고, 시트 내에서 엑셀 함수를 조합해서 변환되는 과정을 추적하는 것이 디버깅하기에 유용했다. (코드로 해당 로직을 작성하는 것은 꽤 복잡한데 재밌다. 한번 해보길 추천한다.)

이미지 저장 / 업로드 관련 자동화 이슈

이미지 저장하는 것도 피로감을 느꼈기에, Slack 봇 연동으로 한단계 더 자동화 시키려고 했으나, Puppeteer를 적용한 서버를 Google Cloud Run으로 배포하는 과정에서 삽질하는 시간이 길어졌다. (작동은 했지만, 가끔은 요청이 실패하고 헤드리스 브라우저가 뜨는 과정에서 시간이 굉장히 오래걸렸다.) 이 부분은 weekly 프론트 단에html2canvas 를 적용시켜서 직접 다운로드 받도록 했다. 유튜브 커뮤니티에 주보 이미지를 업로드 하는 과정은 Google Cloud Scheduler에서 YouTube API를 호출하도록 자동화를 생각하기도 했지만, 간혹 모임이 없는 날도 있고, 방학 때는 수련회 준비 등으로 인해 모임을 잠시 쉬기 때문에, 이 부분은 사람이 신경쓰는 것이 필요해서 자동화의 이점을 보기가 어려울 것으로 판단했다. (만약 이런 시스템으로 관리해야하는 단체가 여러곳이라면 자동화를 더 고려해봤을 것 같다. 현재 상태에서 오버 엔지니어링 영역으로 판단했다.)

Weekly 서비스의 아쉬운 점은 빈칸에 대한 대응과 홍보이다. 목사님께서 전해주실 말씀이 정해지지 않은 상태일 때는, 주보를 형태를 보여주지 않고 "아직 준비중입니다." 와 같은 화면을 보여주는 고려를 할 수도 있었지만, 이 부분은 그냥 빈칸을 보여주도록 했다. 그리고 별도의 광고(홍보?)를 하지는 않고 있어서,, 멤버들 중에서도 이 서비스가 존재하는지 아는 사람은 드물 것이다. (많이 알려질 필요는 없는 것 같다. 굳이 이 서비스에 접속해서 주보를 확인하기보다는, 단체 카톡방에 주보 이미지가 올라오는 것을 보는게 편하다고 생각한다.)

3. Cloudflare 를 사용한 서브도메인 라우팅

해당 블로그 글을 작성한 이후에도, 서브도메인 라우팅을 편리하게 진행하고 있다. (ecukorea 도메인으로 google docs 로 향하는 url shortner 사용하기 등등..) Kubernetes 환경에서 Nginx Ingress Controller를 사용하듯이, Cloudflare에서 원하는대로 라우팅을 할 수 있어서(별도의 서버 자원 관리에 드는 비용 없이 무료로), 트래픽 규모가 작은 단체에서는 여러개의 서비스가 존재할 때 Cloudflare를 유용하게 활용하면 좋을 것 같다.

4. 찬양팀 로스터

필요하신 분이 혹시 있을까봐 구글시트 양식 링크를 남겨드립니다. 사본을 만들어서사용해주세요.

사용방법

파일 - 사본 만들기
만들어진 사본의 "명단" 시트를 우리 찬양팀 사람의 이름으로 수정한다.
"스케쥴" 시트에 이름이 반영된 것을 확인한다.
사람별로 역할을 일정에 맞게 부여한다.
- 만약 역할이 악기 외에 추가로 필요하다면 그냥 "스케쥴" 시트에 역할을 입력하면 "밸런스" 시트에 알아서 역할이 추가된다.
- 역할에 별도의 서식이 필요하다면 조건부 서식을 추가한다.
기존에 작성된 내용이 있는 상태에서 명단이 추가되었을 때, "명단" 시트의 사람들을 이름 순으로 정렬하면 "스케줄" 시트의 사람 순서도 변경되니 주의 (이름과 역할의 관계를 별도로 저장해놓고 있지 않음)

Roaster

balance

상황

로스터를 만들게 된 이유에 대해 이야기하면 왜 이런 형식으로 시트를 작성했는지 이해가 될 것 같다. 올해 나는 교회에서 여러 찬양팀에 속해있었다. (청소년부, 청년부, 11시 예배 찬양팀) 청소년부 / 청년부 찬양팀은 거의 고정 멤버로 진행됐기 때문에 딱히 로스터를 짜서 공유할 필요가 없었지만, 11시 예배 찬양팀은 인도자도 매주 바뀌고, 인도자가 바뀌면 각 세션 담당자가 바뀌어야했다. 청년들은 한 가지 섬김만 하고 있는 것이 아니라 교육부서에서 다양한 형태로 섬기고 있었기 때문에, 번아웃이 와도 이상하지 않은 상황이었다. 그래서 한달에 한번 정도는 찬양으로 섬기는 것은 쉴 수 있도록 했다.(더 기쁜 마음으로 찬양하는데 도움이 될 거라는 것에 다들 동의했다.)

로스터를 짤 때 고려했던 것은 아래 정도였다.

인도자가 토요일에 연습 참여가 가능한가?
최소한의 악기가 존재하는가?
혹시 소외되고 있는 세션이 있는가?
쉼이 적절히 부여되고 있는가?

위의 내용을 고려하면서 매달 11시 예배 때 섬길 사람들을 배치했다. 감사하게도 성도분들과 함께 기쁜 마음으로 하나님을 찬양할 수 있었다. 언제까지 찬양 인도를 할 수 있을지 모르지만, 지금 찬양할 수 있음에 감사하다. 나를 사용해주시는 하나님과 함께 내일 하루도 마냥 기쁘게 살아가야겠다.

게으른 그리스도인 개발자의 2023년 회고