메시징 사이드 프로젝트 - 개발 일지, 기존소스 날리고 복구중

목차

• 만들었던 구조 (기억나는 대로)
• 앞으로 쓸 것

그동안 "이건 이렇게 하면 더 낫지 않았을까" 싶었던 것들을 직접 만들어 보기로 했습니다. 제일 먼저 손댄 건 Email과 Push였습니다. 둘 다 결국 TCP 위에서 도는 거고, Gmail·Naver SMTP나 FCM·APNs(유료료) 개발자 계정으로 공짜로 테스트할 수 있어서 부담이 없었습니다.

AI와 1:1로 붙어서 모듈을 하나씩 만드는 건 생각보다 쉬웠습니다. 발송, 템플릿, 설정을 각각 돌아가게 만드는 데까지는 금방 갔습니다.

문제는 욕심이었습니다. 개별 모듈에서 멈추지 않고 "메시징 플랫폼"이라는 하나의 배포 가능한 서비스로 합치고 싶어서, 모듈을 통합하고 React로 프론트까지 붙이기 시작했습니다. 여기서부터 꼬였습니다.

git 브랜치가 갈라졌습니다(diverged). 로컬과 원격, 통합 브랜치와 모듈 브랜치가 서로 다른 방향으로 가버렸고, 그걸 억지로 맞추는 과정에서 모듈 간 의존성이 엉키면서 소스가 하나둘씩 사라졌습니다. 결국 테스트 자체가 안 도는 상태가 됐습니다.

하필 그때 7년 된 데스크톱이 맛이 가기 시작했습니다. 점점 느려지더니 화면이 주기적으로 멈췄습니다. 버텨 보려고 불필요한 보안 프로그램부터 지우고, Docker나 하이퍼바이저처럼 리소스를 잡아먹는 것들을 지우고, 디스크 정리도 했는데 멈춤은 그대로였습니다. 결국 포맷하기로 했습니다. "프로젝트는 백업했고 GitHub에도 다 올렸으니까 괜찮아" 하는 마음으로요.

포맷하고 나니 컴퓨터는 멀쩡해졌습니다. 백업도 잘 돼 있었습니다. 그런데 통합 작업을 이어가려고 보니 — git 이력이 GitHub에 전부 올라가 있지 않았고, 통합하다 날린 소스가 진짜로 없어진 상태였습니다. "올렸다"는 건 제 착각이었고, 실제로 원격에 반영됐는지는 한 번도 확인을 안 했던 겁니다.

그래서 울며 겨자 먹기로 복원을 시작했습니다. 작업 전에 Notion에 써 둔 명세서, 남아 있는 소스 조각들, 그리고 AI를 붙여서요. 처음엔 진짜 막막했는데, 그 Notion 명세서가 딱 지금 이 wiki가 하는 역할을 대신해 줬습니다. 뭘 어떤 순서로 만들려고 했는지가 글로 남아 있으니까, AI에게 "이 기능은 이런 흐름이었다"고 설명하면서 뼈대를 다시 세울 수 있었습니다.

100%는 아니지만 구현했던 기능은 어느 정도 되살아났습니다. 7월 28일 기준으로 대략 절반 정도 복원된 것 같습니다. 이 페이스면 9월엔 실제로 배포해서 클로즈 베타 정도는 열어 볼 수 있을 것 같습니다.

이번 일로 확실히 배운 건, 만드는 것보다 만든 걸 안전하게 두는 게 먼저라는 겁니다. push 하고 나서 GitHub에 진짜 올라갔는지 확인하는 걸 습관으로 만들거나, 알림으로 주요 프로젝트의 백업 상태를 주기적으로 받아 보게 해 둬야겠습니다. "올렸다는 생각"과 "올라간 사실"은 다릅니다.

---

만들었던 구조 (기억나는 대로)

역할을 발송 / 컨텍스트 / 설정 세 개로 나눴습니다. 스택은 Java 21, Spring Boot WebFlux(논블로킹), Spring Batch, 그리고 ThreadPoolExecutor를 여기저기 썼습니다.

발송 모듈은 DB를 아예 안 타는 순수 발송 계층으로 잡았습니다. 전송할 데이터를 TCP로 바로 받거나 MQ를 거쳐서 받고, Push면 FCM·APNs로, Email이면 SMTPS(587·465)나 표준 25 포트로 메일 서버에 던졌습니다. 메일은 Gmail과 Naver 기준으로 테스트했습니다.

컨텍스트 모듈은 보낼 메시지의 형태(템플릿)를 만드는 쪽입니다. Push는 Pushwoosh 템플릿 종류를 참고해서 알림형·캐러셀·버튼형 같은 걸 세분화해 봤고, 도움을 받아 실제 안드로이드 단말에서 받아 보는 것까지 확인했습니다. Email은 RFC 5321을 AI에게 학습시키고 그동안 다뤄 봤던 걸 살려서 SSL, DKIM, DMARC, canonicalization 같은 걸 붙였습니다.

설정 모듈은 각 모듈이 설정 파일에 박아 두던 값을 실행 중에도 바꿀 수 있게 하고 싶어서, Spring Cloud Config 서버를 세워 봤습니다. JVM이 뜰 때 고정되던 걸 동적 설정 서버로 뺀 셈입니다.

이 셋을 각각 docker-compose로 컨테이너를 띄워서 테스트했을 때 실제로 발송 성공까지 확인했는데 — 스크린샷이든 로그든 증빙을 안 남겨 둔 게 지금 제일 아쉽습니다. 다음에 다시 돌릴 땐 성공 로그와 수신 화면을 꼭 저장해 둬야겠습니다.

---

앞으로 쓸 것

• 9월 클로즈 베타 배포 결과
• 원격 백업(원격에 실제로 올라갔는지) 확인 자동화
• 모듈별 발송 성공 증빙 남기기