Slack이 대시보드가 된 이유
1인 개발자에게는 동료가 없다. 아침에 출근해서 “어제 뭐 했어?”라고 물어볼 사람이 없고, 배포가 끝나도 “반영됐어요”라고 알려줄 사람이 없고, 버그 리포트가 카카오톡으로 날아와도 그게 고쳐졌는지 추적해줄 사람이 없다. 코드를 짜면서 동시에 이 모든 걸 신경 쓰는 건 멀티태스킹이 아니라 주의력 분산이다.
팀이 있으면 이런 것들이 자연스럽게 흘러간다. 스탠드업 미팅에서 어제 한 일을 공유하고, 배포 채널에 누가 알림을 올리고, Jira 티켓 상태가 바뀌면 리포터에게 이메일이 간다. 1인 개발에서는 이 모든 역할을 시스템이 대신해야 한다.
처음부터 Slack을 개발 대시보드로 설계한 건 아니었다. 모닝 브리핑이 먼저 생겼고, 배포 알림이 따로 생겼고, 피드백 루프가 또 따로 생겼다. 그런데 돌아보니 세 가지가 하나의 생태계를 이루고 있었다.
퇴근했는데도 작업이 돌아간다. 아침에 Slack을 열면 어제 내가 뭘 했는지 정리돼 있다. 배포가 끝나면 뭐가 바뀌었는지 알려준다. 사용자가 버그를 보고하면, 고쳐졌을 때 자동으로 알려준다. 이 세 가지가 1인 개발의 운영 부담을 상당 부분 덜어준다. 전부 만드는 데 내가 직접 쓴 시간은 거의 없다. Claude Code에 “이런 거 만들어줘” 하고 시켜놓고 다른 일을 했다. AI 코딩 덕분에 유료 협업 도구 없이도 이 정도 운영 인프라를 가질 수 있게 된 시대다.
각 시스템의 구체적인 구현은 후속 글에서 다룬다. 이 글에서는 전체 구조와 설계 원칙을 먼저 정리한다.
세 개의 기둥
1. 모닝 브리핑 — “어제 뭐 했더라?” 문제
매일 아침 09:00, Slack에 메시지가 온다. 어제 커밋 요약, 진행 중인 Feature 목록, 퇴근 전에 내가 남긴 메모.
구조는 이렇다. Claude Code의 스케줄 에이전트(remote trigger)가 매일 아침 Anthropic 클라우드에서 깨어나서, git repo를 clone하고, 어제 커밋과 wrap-up 기록을 분석한다. 문제는 이 에이전트가 외부 webhook을 직접 호출할 수 없다는 점이었다. 네트워크 제한 때문이다.
해결책은 의외로 단순했다. 분석 결과를 JSON 파일로 만들어서 git push하면, GitHub Actions가 이를 감지해서 Slack webhook으로 전송한다. Git이 메시지 큐 역할을 하는 셈이다.
이 시스템의 핵심은 사실 브리핑 자체가 아니라, 퇴근 전 /wrap-up이라는 로컬 루틴이다. Claude Code가 오늘 세션들을 정리하고, 내가 한 줄짜리 메모를 남긴다. “내일 PIN 통합 마무리” 같은 거. 1분이면 끝나는 이 루틴이, 다음 날 아침 15분짜리 컨텍스트 복구 시간을 없애준다.
2. 배포 알림 — “배포됐나? 뭐가 바뀌었지?” 문제
GitHub Actions CI/CD 파이프라인에서 배포가 시작되면, 진행 중/성공/실패까지 3단계로 Slack 알림이 온다. 여기까지는 평범한 CI/CD 알림인데, 한 가지를 더 넣었다.
커밋 메시지에서 [release-note]로 시작하는 줄을 자동 추출해서 배포 알림에 포함시킨다. 이건 사용자 관점의 변경 내역이다. “등록 체크리스트에서 학생/학부모에게 개별 가입 안내를 발송할 수 있습니다” 같은.
이 convention은 한번 진화를 거쳤다. 처음에는 모든 fix/feat 커밋마다 [release-note]를 달았는데, 배포 알림이 너무 길어졌다. 커밋 10개에 release-note 10줄이면 읽기 싫어진다. 그래서 바꿨다 — 개별 커밋에는 달지 않고, push 직전에 한 번만 정리해서 curated summary를 쓴다. 커밋 10개가 release-note 3줄이 되는 거다.
배포 알림이 있으면 “방금 배포했는데 잘 됐나?” 하고 Actions 페이지를 들어가볼 필요가 없다. Slack에 초록불이 뜨면 된 거고, 빨간불이 뜨면 바로 확인하면 된다.
3. 피드백 루프 — “버그 리포트가 카톡으로 오는” 문제
이건 개발 자동화라기보다 운영 자동화에 가깝다. 앱 안에 피드백 위젯을 넣었다. 사용자(원장님, 선생님)가 문제를 발견하면 스크린샷을 찍고 메모를 달아서 보낸다. 이게 자동으로 GitHub Issue가 된다. 스크린샷, 디바이스 정보, 현재 페이지 URL까지 포함해서.
여기까지만 해도 카톡으로 “이거 왜 안 돼요?” 받는 것보다 낫다. 하지만 핵심은 루프를 닫는 것이다. Issue를 close하면, GitHub Actions가 이를 감지해서 Slack으로 “피드백 해결됨” 알림을 보낸다. 리포터에게도 알림이 간다.
피드백 → 이슈 → 수정 → 알림. 이 전체 흐름에서 내가 수동으로 하는 건 “코드를 고치고 이슈를 닫는 것”뿐이다. 나머지는 자동이다.
보이지 않는 접착제: GitHub Actions
세 시스템을 관통하는 공통 레이어가 GitHub Actions다. CI/CD 도구로만 알려져 있지만, 실제로는 범용 이벤트 핸들러에 가깝다.
- push 이벤트 → 배포 시작, Slack 메시지 전송
- issue 이벤트 → 피드백 상태 변경 알림
- cron 스케줄 → (remote agent가 담당하지만, 필요하면 Actions cron도 가능)
- workflow_dispatch → 수동 배포, 롤백
Slack webhook은 단순한 HTTP POST다. 복잡한 Slack API 인증이나 봇 서버가 필요 없다. webhook URL 하나면 충분하다. 채널을 두 개로 나눠서 — checkus-notice에는 배포/피드백 같은 운영 알림, checkus-briefing에는 일일 브리핑 — 알림 피로를 관리한다.
커스텀 서버는 없다. 모든 게 이벤트 드리븐이고 서버리스다. 유지보수할 인프라가 없다는 건 1인 개발에서 큰 장점이다.
만들면서 생긴 원칙들
이 시스템들을 하나씩 만들면서 몇 가지 패턴이 반복됐다. 의도한 건 아닌데 돌이켜보니 일관된 원칙이 있었다.
알림은 짧게, 정보는 충분히. Slack 메시지가 길면 안 읽는다. 하지만 “배포 완료”만 적혀 있으면 “뭐가 배포됐는데?”라고 다시 찾아봐야 한다. 한눈에 훑을 수 있되, 필요한 정보는 다 있어야 한다. release-note 추출이 이 원칙에서 나왔다.
자동화는 보이지 않아야 한다. 잘 돌아가는 자동화는 존재감이 없다. 아침에 브리핑이 안 왔을 때 — 그제서야 “아, 이거 있었지” 하고 깨닫는 정도가 좋다. 설정하고 나면 신경 쓸 필요 없어야 한다.
피드백 루프를 닫아라. 알림이 가는 것만으로는 부족하다. 배포 알림에는 뭐가 바뀌었는지가 포함돼야 하고, 피드백 알림에는 해결 여부가 포함돼야 한다. 일방통행 알림은 결국 무시하게 된다.
설계보다 진화. 세 시스템은 각각 다른 시점에, 다른 문제를 풀려고 만들었다. 하나의 grand design이 있었던 게 아니다. 그런데 Slack + GitHub Actions라는 공통 인프라 위에 만들다 보니, 자연스럽게 일관된 생태계가 됐다. 필요에 의해 진화한 시스템이 설계된 시스템보다 오래 간다고 생각한다.
다음 단계
아직 빠져 있는 조각이 있다.
Sentry 에러 알림. 현재 Sentry는 따로 보고 있다. 프로덕션에서 새로운 에러가 터지면 Slack으로 오게 만들면, 운영 모니터링의 마지막 퍼즐이 채워진다.
배포 롤백 알림. 배포 실패 시 자동 롤백이 되는데, 이게 일어났다는 사실을 Slack으로 받아야 한다.
주간 요약. 일일 브리핑이 있으니, 이걸 모아서 주간 단위로 “이번 주에 뭘 했나” 요약을 만드는 건 어렵지 않을 것 같다.
돌아보며
직접 투입한 시간이 거의 없다고 했는데, 이게 가능했던 건 AI 코딩 덕분이다. “배포되면 Slack으로 알려줘, release-note도 뽑아서”라고 시키면 워크플로우가 나오고, “피드백 위젯 만들어줘, 스크린샷 캡처되게”라고 시키면 컴포넌트가 나온다. 내가 한 건 방향을 잡고 결과를 확인한 것뿐이다. 예전이었으면 webhook 문서 읽고, JSON 이스케이프 삽질하고, YAML 디버깅하는 데 하루 이상 걸렸을 거다. 차라리 PagerDuty나 Opsgenie를 사는 게 합리적이었다. AI가 바꾼 건 이 계산이다. 인프라 구축 비용 자체가 급락하니까, 월 수십 달러짜리 SaaS 대신 내 워크플로우에 정확히 맞는 시스템을 비용 없이 만들 수 있게 됐다.
정량적으로 보면 하루 15-20분 정도를 아껴준다. 아침 컨텍스트 복구 시간, 배포 확인, 버그 리포트 수동 트래킹에 쓰던 시간이다.
하지만 실제 가치는 시간 절약이 아니다. 정신적 부하 감소다. “혹시 뭐 놓친 거 없나?” “배포 잘 된 건가?” “그 버그 리포트 처리했나?” — 이런 잔잔한 걱정들이 사라진다. 시스템이 알아서 알려주니까. 놓칠 일이 없다는 확신이 생기면, 개발에만 집중할 수 있다.
1인 개발자에게 가장 부족한 건 시간이 아니라 주의력이다. 코드를 짜면서 동시에 운영을 신경 쓰고, 배포를 확인하고, 버그 리포트를 추적하는 건 멀티태스킹이 아니라 주의력 분산이다. 자동화의 진짜 목적은 이 분산을 줄이는 것이다.
Slack 하나에 모든 운영 정보를 모아두면, 아침에 한 번 확인하고 나서는 코드에만 집중할 수 있다. 그게 이 생태계의 존재 이유다.
이 글은 시리즈의 첫 번째 글입니다. 각 시스템의 구체적인 구현이 궁금하다면:
Comments