작은 조직에서 내부 도구를 만들다 보면 깨닫는 게 있다. 당장의 구성원 편의를 위한 제품은 굳이 혁신적일 필요까진 없다는 것이다. 제1목표는 신속성과 편의성이고, 그걸 달성하는 데 드는 비용이 적을수록 좋다. 그 비용에는 내 시간뿐 아니라 구성원이 새 도구를 익히는 데 써야 하는 리소스까지 포함된다. 실험이 성공하거나 실패하면 그때 가서 내용을 피벗하여 더 투자하면 된다.
그런 맥락에서 만들게 된, 부트캠프 TIL 알림 파이프라인을 회고해본다.
왜 만들었나
우리 팀은 부트캠프 내에서 유일하게 팀원 변동 없이 유지된 팀이었다. 장점도 있었지만, 단점이 하나 있었다. 다양한 훈련생들이 어떻게 일하고 생각하는지를 접하기 어렵다는 것이었다.
네트워킹을 건의해봤지만 국비 교육 특성상 시간과 예산이 제한돼 있었고, 밍글링 한 번 외엔 타팀 사람들과 만날 기회가 없었다. 원온원 만남들도 진행해보았지만 얻고자 하는 내용을 얻는 데엔 한계까 있었다. 그래서 선택한 방법이 매일 모든 훈련생의 TIL을 직접 확인하는 것이었다.
효과는 있었다. '아, 이렇게도 문제를 정의할 수 있구나' 같은 인사이트가 꽤 많았고, 팀 내에 공유하자 팀원들도 자극을 받아 적극적으로 참고하기 시작했다. 문제는 그 과정이 너무나도 귀찮다는 거였다.
문제
당시 TIL 탐색 플로우는 이랬다.
사전 작업 (1회)
- 부트캠프 노션에서 훈련생 개인 블로그 주소를 일일이 수집
- 브라우저에 북마크로 저장하고 이름을 훈련생 이름으로 변경
매일 반복 작업
- 각 링크를 일일이 클릭해서 새 글 여부 확인
- 제목만으론 내용을 알기 어려워 글 본문까지 클릭
- 원하는 내용이 없으면 그냥 슬퍼함

인당 30분 이상. 새 글이 올라왔는지 궁금해서 수시로 확인하는 시간까지 합치면 하루 1시간은 가볍게 넘었다. 확인하는 시간이야 뭐 든다고 쳐도, 확인을 했는데 허탕일 때가 가장 문제였다. 급기야 팀원끼리 zep 음성을 켜고 "OOO님 TIL 올라왔어요!" 하고 외치는 지경에 이르렀다.
RSS 피드만 해도 40개에 달했다. 자동화가 필요했다.
해결 방법을 찾기까지
처음엔 Make로 RSS를 감지해서 슬랙에 바로 보내는 구조를 생각했다. 하지만 복병이 있었다. 부트캠프 슬랙 워크스페이스는 무료 플랜이라 외부 앱 연동이 10개로 제한돼 있었고, 이미 꽉 찬 상태였다는 것이다.
대안을 여럿 검토했다. Make에서 구글 스프레드시트 연동, 노션 DB 연동 등. 하지만 무엇보다 RSS 40개를 외부 자동화 서비스에 의존하는 구조가 마음에 걸렸다. 훈련생이 블로그를 이전하는 경우도 종종 있었고, 이 파이프라인을 추후에 채용공고나 기술 아티클 수집 등에 재사용할 수 있게 만들고 싶었다. 유지보수가 쉬운 구조여야 했다.
그러다 클로드와 머리를 모아 찾아낸 건 깃허브 액션이었다. 코드 저장소로만 알고 있었는데, 스케줄 기반 자동화가 가능하다는 걸 처음 알았다.
파이프라인 구조
이 파이프라인을 구축하는 이틀 간 우여곡절이 아주 많았다. 깃헙 액션 자체를 처음 사용해봤고 RSS의 작동 구조 이해도 필요했다. 오전 9시부터 오후 9시까지 이어지는 부트캠프 일정과도 병행해야 해서 체력적으로 아주 후달렸다. 어쨌거나 여러 실패를 거쳐 최종적으로 설계한 흐름은 다음과 같다.
깃허브 액션 (2시간마다 실행, 주로 TIL이 업로드되는 오후 6-10시에는 30분마다 실행)
→ RSS 피드 수집 및 신규 글 감지
→ 노션 DB에 제목 / 작성자 / 작성일시 / 링크 저장
→ 노션 자동화: 새 페이지 등록 감지 시 슬랙 채널에 알림 발송
마침 노션 유료 플랜을 쓰고 있었고, 부트캠프 자체적으로 팀 노션을 운영하고 있었기 때문에 팀원들이 별도 도구를 새로 익힐 필요가 없었다.
결과는 성공적이었다. 슬랙에 2시간마다 새 글 알림이 왔고, URL 미리보기로 글 초입부까지 바로 확인할 수 있었다. 쓰다 만 글도 즉각 탐지됐다. 나중에 특정 내용이나 작성자를 찾고 싶으면 노션 DB를 검색하면 됐다.


결과
가장 직접적인 변화는 시간이었다. 인당 30~60분씩 5명이 매일 쓰던 시간이 슬랙 알림을 훑는 3초로 줄었다.
그런데 더 크게 느껴진 건 시간보다 인지적 소모의 제거였다. 팀 작업을 하면서 "타팀은 지금 어디쯤 왔을까", "오늘 TIL 올라왔나" 하며 신경을 쓰지 않게 되었다. 능동적으로 확인하러 가지 않아도 됐으니까.
노션 DB가 생기면서 예상 못했던 효과도 있었다. 별도로 스크랩할 필요가 없어졌고, 시계열로 쌓인 데이터 덕분에 타팀의 스프린트 사이클을 한눈에 파악할 수 있었다. 노션 안에서 논의할 때 TIL 스크랩 페이지를 바로 검색하고 멘션할 수 있었던 것도 예상 밖의 수확이었다. 직업훈련이라는 부트캠프 본래 목적에 더 충실하게 배움을 이어나갈 수 있었다.
역설적으로, 자동화 이후에 TIL 확인이 오히려 더 활발해졌다. 좋은 글이 슬랙에 올라오면 모두가 슬랙 알림을 받았기에 자연스럽게 이야기가 시작됐고, 잘 쓰는 훈련생의 글을 보며 함께 논의하는 시간이 늘었다.
돌이켜보면 이 파이프라인을 만들면서 직접적으로 배운 건 자동화 기술이었지만, 문제를 다르게 정의하는 방식이야말로 진짜 수확이었던 것 같다. 처음엔 "어떻게 하면 TIL을 빠르고 편하게 볼 수 있을까"를 고민했는데, 실제로 풀어야 했던 문제는 "왜 우리는 매일 1시간을 쓰면서도 문서화와 논의는 충분히 하지 못했는가"였다. 그리고 구성원들이 새로운 툴을 배울 필요 없이 문제를 해결할 수 있게 된 것도 큰 수확이었다.
코드도 재사용할 수 있었다. 간단하게는 RSS 피드 주소만 바꾸면 됐기 때문에, 비슷한 워크플로우로 채용공고 스크랩 에어테이블과 기술 블로그 아티클 수집 노션 DB, 개인 블로그 아티클 수집 사이트까지 이어서 만들었다.


조직 생산성 향상을 위한 작은 시도들
'Try-Catch' 카테고리의 다른 글
| 기능 수정하다 개발자 반응 보고 UI 전면 개편했던 이야기 (0) | 2026.03.09 |
|---|---|
| 약간의 노력으로 자리비움 보고체계 만들기 (0) | 2026.02.01 |
| [대학일기] 엑셀과 노션 버무려서 영문 페이퍼 쓰기 (0) | 2021.02.16 |
| [대학일기] AI 외 잡다한 기술 버무려서 영어 강의 듣기 (0) | 2021.02.14 |