해당 프로젝트는..
현재 프로젝트는 NextJS 14.2.4 버전을 기준으로 서버리스 아키텍처 기반으로 백엔드와 프론트엔드를 통합하여 진행하고 있습니다. 해당 프로젝트는 애드센스 수익 계산을 자동화하고, 이를 쉽게 원화로 변환하여 세금 신고 절차를 단순화시키는 것이 목적이며, 이러한 서비스를 제공하는 것을 주요 포인트로 잡고 있습니다. 참고로 이 글은 매우 짧으며 영양가 있는 글은 아니므로 혹여나 보셨다면, 뒤로 가기 하셔도 무방합니다.
현재, 수익 통계
현재 까지 연도별로 수익통계를 확인할 수 있도록 작업이 완료되어 있고, CSV 파일 형태로 수익정보를 보고서 형태로 확인할 수 있도록 간단하게 구현이 되어 있습니다. 보다 많은 편의성을 위해 조금씩 추가할 예정이지만, 현재 까지는 빠른 배포 및 테스트를 위해서 이 정도 까지만 구현해두었습니다.
지금 고민은 예상 수익 부분이 아니라, 실제 지금액 금액에 대한 부분인데, 2024년도 기준으로 수익금 정산을 5월 달에 진행했기에 그 외의 시간대에 정산된 금액도 받을 수 있는지 확인이 어려운 점이 애로사항으로 남아 있습니다. 정확한 테스트를 위해서는 실제 여러 차례 수익금을 정산받은 계정이 필요한데, 현재 단계에서는 이를 바로 확인해볼 수 없어서 갑갑한 상황이네요.
CSV 부분이 안 보여서 다운로드를 한다면, 아래와 같이 통계 데이터가 셀에 입력되어 표시가 됩니다. 아마 보고서를 사용자가 받는다면, 아래와 같이 취합된 자료가 메일 등으로 전달되지 않을까 싶습니다.
현재, 환율 정보
실시간으로 수익금을 실제 한화로 변환하는 작업을 자동화하기 위해서 필요한 정보는 환율 정보입니다. 다행히 해당 정보를 얻을 수 있는 사이트가 있어서 해당 API 를 사용하여 1일 단위로 받아볼 수 있게 되었습니다. 이 경우에는 '정보' 페이지에서 확인할 수 있도록 구현할 생각입니다. 하루 1000건 정도로 한정이 되어 있어서, 매일 변화되는 데이터를 받아와 사용자로 하여금 참고할 수 있게 하고, 직접 날짜를 지정해서 해당 날짜의 환율 정보도 개별적으로 받아올 수 있기 때문에, 이를 데이터베이스에 저장해두고 활용한다면 유의미한 데이터로서 활용할 수 있지 않을까 싶습니다.
현재, 고민되는 알림 서비스 고려사항
여기서 알림 서비스는 서비스에서 제공하는 앱이나 웹에 접속 시 보이는 그런 알림이 아니라, 사용자가 원하는 시간대에 원하는 제3자 서비스로 데이터를 전달받을 수 있는 서비스를 의미 합니다(물론 전자의 알림 서비스도 있습니다).
node-cron 의 간편성과 한계
알림 서비스 자체는 제일 단순하게 node-cron 을 이용하면 예약된 시간에 이메일이든, SNS 봇 이든 연동해서 하면 될 것 같지만, 문제는 알림 서비스의 신뢰성에 관한 부분입니다. 여기서 신뢰성이란 서비스에 약간의 장애가 발생하더라도 기존 서비스를 정상적으로 이용할 수 있도록 하여 사용자로 하여금 일관된 혜택을 가져갈 수 있도록 하는 것을 의미하는데, node-corn 을 사용하는 경우에는 잠시 서버가 다운되는 경우 백그라운드에서 실행중인 특성상 메모리 상에 저장되어 있던 프로그램의 실행정보도 같이 초기화되므로 서비스의 신뢰성을 보장하지 못하게 됩니다.
위 문제를 개선하고자 한다면, 동일한 처리를 하는 서버를 2대 이상 둔 상태에서 하나의 서버가 문제가 생기더라도 다른 서버에서 대신 서비스를 처리하면 되므로 문제가 발생하지 않지만, 적은 비용으로 서비스를 운영하고자 하는 현재의 입장에서는 배보다는 배꼽이 더 큰 문제로 다가왔습니다.
데이터베이스에 타임스케줄을 저장해두는 방식
앞서 node-cron 과 연동할 수 있는 부분입니다. 현재 PostgreSQL 과 Prisma ORM 을 사용 중인데, 해당 데이터베이스에 사용자별로 등록한 트리거를 저장해두고, 서버가 잠시 다운되더라도 재시작되는 순간 데이터베이스에서 읽어온 정보를 바탕으로 크론을 재시작하면 됩니다.
이 경우은 단순하지만, 원래라면 데이터베이스의 입출력이 많아지는 경우에는 제한적이라 생각되어 배제하려고 했었습니다. 그러나, 까마득한 미래(불확실하고, 현실성도 떨어지는 그런 미래)가 아니라 현재의 앱 규모를 생각한다면, 충분히 처리 가능하다고 판단하여 이 방식을 거의 확정 시 보고 있습니다. 더 찾아보니까 대규모 소프트웨어 에서는 메시지 큐를 구현하여 사용한다고 하는데, 이 경우에는 서로 분산된 시스템 간에 데이터 연동 등에 필수적으로 쓰인다고 합니다. 그런데, 제가 만드는 서비스에는 결코 필요한 방식은 아닌 것은 알 것 같습니다.
암튼, 제일 단순하면서도 활용성이 높은 DB, node-cron 을 이용한 방식으로 해봐야 겠습니다.
나가는 말
최근 까지 개인의 성장에 집중하면서 많은 것들을 알게 되었지만, 처음 보는 기능이나 컨셉을 알아가는 시간은 언제나 흥미롭고 재밌네요. 이번 프로젝트가 스스로의 필요에 의해 제작된 서비스인 만큼 오래 걸리더라도 가볍게 더 효율적인 방식으로 고도화 시켜나갈 생각입니다.
별개로, 이전에 만든 명언 웹 사이트의 경우에도 추가하고자 했지만, 프로젝트를 실행하고 있는 인프라의 비용상 문제로 확장하지 못하고 있었습니다. 이번 프로젝트에서는 가볍게 가져가면서도 이전에 구현하지 못했던 것들을 추가시켜 나가면서 유종의 미를 잘 거둬봐야 겠습니다. 그럼 이만 글을 줄여봅니다.
'프로젝트 > 잔소리' 카테고리의 다른 글
[잔소리 프로젝트] 🤔 현재 경험하고 있는 애로사항과 앞으로의 방향성 (8) | 2024.08.17 |
---|---|
[잔소리 프로젝트] 24.07.30 ~ 08.01 진행 사항 점검 (0) | 2024.08.01 |
[잔소리 ] 트러블 슈팅 (0) | 2024.07.14 |
[잔소리 프로젝트] 쉬어가는 챕터 - 생각보다 쉽지 않은 상황 (0) | 2024.07.13 |
[잔소리] TailwindCSS 를 이용한 다크모드 구현 (0) | 2024.07.09 |