[잔소리 프로젝트] 24.07.30 ~ 08.01 진행 사항 점검

현재 기능의 구현 정도 점검

 2024.07.09 에서 개발을 시작하여 27일이 되었는데, 여기까지 개인 사정으로 개발을 자주하지 못해서 대략 10일 정도  작업을 한 것 같습니다. 이번 시간을 통해 약 10일 동안 현재 구현된 부분을 정리해보고 앞으로 방향성에 대해서 정리해볼까 합니다. 

 

알림 설정

보고서 옵션 설정

사용자가 맞춤형 보고서를 받아볼 수 있도록 알림을 등록하기 전에 여러 옵션을 리스트화 하여 확인할 수 있는 기능을 도입하였습니다. 여기서 보고서 옵션의 형식은 애드센스에서 조회할 수 있는 다양한 옵션 중 일반적으로 광고 수익의 정도를 판가름하는 데 사용되는 주요 옵션을 select 태그를 사용해 선택할 수 있도록 하였습니다.

 

NextJS 14 버전을 사용하고 있기 때문에 최대한 클라이언트 측에서가 아닌 서버측에서 즉시 데이터를 처리할 수 있도록 각 항목은 server action 을 사용하여, 별도의 onChange 이벤트 사용 없이 데이터베이스에 저장할 수 있도록 구현 하였습니다. 

 

 

보고서 옵션 목록

revaildatePath 를 적용한 목록 즉시 갱신

앞서 보고서 옵션의 설정을 통해서 생성된 보고서는 [보고서 옵션 목록] 을 통해서 즉시 확인할 수 있습니다. 이전에 명언 웹 사이트를 만들 때 재유효화에 대한 이해 부족으로 SWR을 불필요하게 많이 사용하였는데, NextJS 공식문서를 탐독하고나니 굳이 그러지 않아도 충분히 캐싱된 데이터를 최신 데이터로 갱신할 수 있다는 사실을 알게 되었습니다. 따라서 보고서를 사용자가 생성하게 되면, revaildatePath 를 적절한 타이밍(ex. 데이터 페치가 성공한 직후)에 적용하여 일치하는 경로에 한하여 캐싱된 데이터를 버리고, 변경된 데이터로 즉시 갱신 업데이트될 수 있도록 하였습니다. 

불필요한 onClick 이벤트와 상태관리 줄이기

현재 알림 설정 페이지의 경우에는 전체적으로 서버 컴포넌트로 되어 있기 때문에, 드롭다운을 구현하기 위해 onClick 이벤트를 사용하는 것은 상태가 각 자식 컴포넌트로 분산되는 문제로 이어졌습니다.

 

특히, 여러 컴포넌트 상태에 대한 의존성을 가지는 경우에는 이를 관리하는 새로운 컴포넌트를 생성하거나, 기존 서버컴포넌트를 클라이언트 컴포넌트로 바꿔야 하는 등 의도했던 컴포넌트의 단일 책임을 유지하기 위해 오히려 prop 은 깊어지는 문제가 생기게 되어,  고민이 생겼던 부분입니다.

 

때 마침 details 태그를 이용하면 별도의 이벤트와 상태관리 없이도 드롭다운을 구현할 수 있었기 때문에, 좋게 좋게 넘어가서 다행이었습니다. 만일 여러분도 저와 같은 상황에 직면하신다면 최대한 기존에 지원하는 도구들을 찾아보는 것도 좋은 경험이 되지 않을까 싶습니다.

 

알림 예약 목록

앞서 보고서 옵션 목록에서 사용자가 '세부정보' 를 클릭하면, 드롭다운이 되면서 해당 보고서를 받아볼 수 있는 일정을 선택할 수 있는 버튼이 보입니다. 해당 버튼을 클릭하고, 등록된 스케줄이 있다면 알림 에약 목록에 표시되도록할 생각 입니다. 현재 까지는 크론 작업에서 잠깐 곤란을 경험하고 있어서, 현 기능은 구현이 안 되어 있는데, 7.31 경으로 크론작업과 알림 예약 부분이 동시에 완료되지 않을까 기대 중입니다.

 

사용자는 등록된 알림 내역을 보면서, 자신이 어느 날짜 마다 보고서를 받아볼 수 있는지 알 수 있고, 필요에 따라 알림을 취소할 수도 있게 됩니다.

 

컴포넌트 구조화

이번에 프로젝트를 하면서 최대한 하나의 컴포넌트를 다양한 형태로 재사용할 수 있도록 구조를 설계하고 있습니다. 바로 아래와 같은 형식인데, className, elementName, children 을 상속 받아 하나의 컴포넌트로 필요에 따라 다양한 상황에서 동적으로 JSX 를 변경할 수 있도록 하고 있습니다. 이 방식의 장점은 직관적이어서 일반적인 div 이런 태그보다 알아보기 쉽다는 점입니다. HTMLAttributes<HTMLElement> 의 모든 속성을 PropsType 으로 확장되므로 보다 유연한 속성 바인딩이 가능하다는 점에서 여러모로 애용하고 있는 패턴입니다.

 

 

프로젝트가 해결해주는 문제

이번 프로젝트의 핵심은 자동화와 간편성입니다. 원래 사용자는 애드센스 정보를 직접 확인하기 위해서 애드센스 홈페이지를 방문하고  필요로 하는 보고서를 복잡하고 다양한 옵션 중에서 일일이 선택 후 직접 다운로드하여야 했기 때문에. 많은 불편함을 경험해야 했습니다

 

저는 그 모든 복잡한 옵션을 제공해주지는 못하지만, 필요한 옵션만을 제공하여 인터페이스의 복잡성은 낮추고, 사용성을 높이며, 한번의 알림등록을 통해서 원하는 주기마다 보고서를 간편하게 받아볼 수 있다는 점에서 좋은 서비스가 되지 않을까 싶습니다.

 

[~ 2024.08.01] 현재 애로 사항과 방향성

현재 애로사항은 핵심 기능이라 할 수 있는 알림 자동화의 안정성입니다. Cron 을 통해서 작업을 등록하고, 일정한 시간 이후에 작업이 실행되는 것이 생각보다 그 주기가 길수록 그 안정성을 보장하는 것이 쉽지 않다는 생각이 많이 들었습니다.

 

따라서 알림 서비스가 제대로 동작하도록 하기 위해서는 매번 로그를 추적할 필요가 있다고 생각이 들었고, 이 부분을 AWS 람다와 클라우드 와치 등을 사용해서 슬렉 등에 연동하여 일정 주기 마다 로그를 전송할 수 있도록 하면 어떨까 고민 중입니다.

 

[2024.08.01 ~ ] 알림 서비스 자동화

해당 프로젝트에서 구현하고자 했던 핵심 기능인 알림 서비스 자동화 구현이 완료 되었습니다. 다만, 프로덕션 환경에서 테스트해본 것이 아니므로 배포 후에도 동일하게 동작하는지 테스트해야 함은 분명합니다.

 

전체적으로 구현된 기능은 보고서 설정, 알림 설정과 이와 연동된 스케줄링이 핵심이고, 세부적으로 사용자가 자신이 원하는 환경에 맞춰서 옵션을 선택할 수 있도록 기능들이 추가되었습니다. 

 

전체적으로 화면의 변경은 next/navigation 의 useRouter의 refresh 기능과  서버 환경에서 처리할 때는 revaildatePath 를 사용하여 페이지를 재유효화 및 새로고침하고 있는데, 번쩍이는 새로고침 없이 부드럽게 상태의 변경이 이루어져서 정말 편하다는 느낌을 많이 받았습니다.

 

 

한 가지 아쉬운 점은 위 영상에서는 스케줄이 제대로 동작 중인지는 확인하기 어렵습니다. 시간 간격이 주, 월, 년 단위로 잡았기 때문에 즉시 알림 받기 기능을 통해서 정상적으로 통계 정보가 csv 파일로 첨부되어 사용자에게 전송되는 것으로 대체 시연하였습니다.

 

다행히 즉시 알림 받기의 경우 정상적으로 csv 파일이 생성되어 전달된 것을 확인할 수 있었습니다.

 

알림 서비스 안정성에 대한 고려

이전에 알림 서비스가 구현이 되어도 이게 장기간 이어지는 경우 정상적으로 동작할까에 대해 걱정이 많았습니다. 특히, 서버가 재부팅 이후에 이전에 등록된 스케줄이 취소되어 일관성이 떨어지는 문제가 있었는데, 이 부분은 향후 배포 이후에 이벤트를 트리거하여 재부팅이나 최초 서버 실행 시 특정 서버 경로에 API 요청을 보내게 하고, 데이터베이스에 저장된 사용자별 스케줄 정보를 바탕으로 동기화할 수 있도록 생각 중입니다. 이미 동기화가 되는 로직은 구현이 되었고, 이를 트리거하는 역할을 해줄 친구가 필요한 상황입니다.

 

나가는 말

오늘은 간략하게 어느 부분을 구현하고 있었고, 어떻게 나아갈지에 대한 부분을 정리해보는 시간을 가졌습니다.  전반적으로 코드의 안정성이 떨어진다는 느낌을 지울수가 없어서 이를 어떻게 보완해야 할지에 대해서 고민이 많이 드는 시기입니다. 개인적인 불편성을 해결하기 위해 시작한 프로젝트이지만, 애드센스를 이용하는 많은 사용자분들도 해당 서비스를 이용했을 때 삶의 질을 개선할 수 있는 좋은 서비스가 되지 않을까 하는 마음으로 부족한 부분을 더 개선하고, 보완해서 완성시켜 봐야겠습니다. 

 

그럼 이만 글을 줄입니다. 감사합니다.