밤빵's 개발일지
[TIL]20241210 알림 기능 추가에 대한 고민 본문
지금 진행하고 있는 프로젝트에서 다루고 있는 데이터들이 익숙하지않고, 잘 알고있는 게임이 아니라서 주도적으로 개선할 방법에 대한 고민이 많아졌다. 기능 추가나 최적화 외에 더 나은 사용자 경험을 제공할 수 있는 방향을 고민하다가 알림 기능은 사용자에게 중요한 정보를 전달하고 서비스의 활용도를 높일 가능성이 있지않을까란 생각에 이번 글에서는 알림 기능을 추가하려는 고민과 그 과정에서의 생각을 정리하고, 앞으로의 계획을 기록했다.
1. 왜 알림 기능을 떠올렸을까?
현재 프로젝트는 게임 관련 데이터를 사용자에게 제공하는 서비스로, 사용자가 데이터를 조회하는 데서 그치는 것이 아니라, 중요한 정보를 능동적으로 전달한다면 서비스가 더 유용해지지 않을까 생각했다. 몇 가지 예시를 생각해봤는데,
클랜 초대 알림
클랜장이 초대를 생성했을 때 사용자가 이를 놓치지 않도록 알림 제공
새로운 시즌 시작 알림
게임에서 새로운 시즌이 시작되었음을 사용자에게 알려 빠르게 준비할 수 있게 함
매치 결과 알림
사용자가 참여한 매치가 종료되었을 때 결과를 알림으로 제공
이런 느낌의 알림 기능은 사용자 만족도를 높이고, 서비스 재방문율을 증가시킬 수 있지 않을까 라고 생각했다. 알림 기능이 서비스의 필수 요소는 아닐 수 있지만, 내가 주도적으로 개선할 수 있는 점을 찾는 과정에서 의미가 크다고 느꼈다.
2. 구현 방식 고민
알림 기능을 어떤 방식으로 구현하면 좋을지 고민했다. 초보니까 일단 여러 기술적 가능성을 탐색해보고, 각각의 장단점을 정리해 봤다.
실시간 알림
- 사용자에게 정보를 즉시 전달하는 방식이다
- WebSocket이나 SSE 활용
- 하지만, 실시간 알림은 기술적으로 복잡하고 서버 리소스도 많이 소모된다. 현재 프로젝트는 실시간성이 절대적으로 필요한 서비스는 아니란 생각에 우선순위에서 제외했다.
푸시 알림
- 브라우저 푸시 알림을 활용할 수 있다. 사용자가 브라우저에서 알림을 수신할 수 있어 실시간성과 비슷한 느낌을 제공한다.
@Service
public class PushNotificationService {
private final RestTemplate restTemplate;
public PushNotificationService(RestTemplate restTemplate) {
this.restTemplate = restTemplate;
}
public void sendPushNotification(String endpoint, String message) {
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.APPLICATION_JSON);
Map<String, String> payload = new HashMap<>();
payload.put("message", message);
HttpEntity<Map<String, String>> request = new HttpEntity<>(payload, headers);
restTemplate.postForEntity(endpoint, request, String.class);
}
}
→ 하지만 HTTPS 프로토콜 요구 사항, 사용자 인증 및 구독 관리 등의 추가 구현이 필요하기때문에 현실적으로 당장 적용하기엔 무리가 있지 않을까 싶다.
이메일 알림
- 이메일은 실시간성이 부족하지만, 구현이 비교적 쉽고 사용자에게 익숙하다.
- SMTP 서버를 사용해 알림을 발송할 수 있고, 현재 프로젝트 구조(사용자 등록 시 이메일을 수집한다.)와도 잘 맞는다.
@Service
public class EmailNotificationService {
private final JavaMailSender mailSender;
public EmailNotificationService(JavaMailSender mailSender) {
this.mailSender = mailSender;
}
public void sendEmail(String to, String subject, String body) {
SimpleMailMessage message = new SimpleMailMessage();
message.setTo(to);
message.setSubject(subject);
message.setText(body);
mailSender.send(message);
}
}
이 중에서 이메일 알림과 푸시 알림을 우선적으로 고려했다. 특히 푸시 알림은 사용자 경험을 크게 높일 수 있을 것으로 기대되지만, 구현 난이도가 높은 점을 생각해서 추가 논의와 설계가 필요하다고 판단했다.
3. 고민과 느낀 점
기능 필요성
기술 구현에만 집중하는 경우가 많았는데, 이번 고민을 통해 기능이 사용자 경험에 어떤 가치를 더할 수 있는지를 우선적으로 고려해야 한다는 것을 다시 깨닫게 됐다. 알림 기능이 사용자에게 편리함을 제공할 수 있다는 점을 떠올리며, 이 기능의 필요성에 대해 이해할 수 있었다.
기술적 범위와 우선순위
처음에는 실시간 알림 구현에 의욕이 마구 솟았는데, 팀과 논의를 하고 현실적인 대안을 선택해야 할 것 같다. 내 마음대로 하고싶은 기능을 다 구현할 순 없고, 기술적 여건과 팀 리소스를 생각해야한다.
능동적 고민의 중요성
알림 기능은 팀에서 꼭 요구한 것은 아니다. 하지만 내가 능동적으로 서비스를 개선할 방법을 고민하며 제안을 해볼 수 있다는 점에서 의미가 크다고 느꼈다. 고민하면서 주도성을 키운 느낌이다..!
4. 앞으로의 계획
- 피드백 반영
- 알림 내용을 테스트해보고, 불필요하거나 과도한 알림은 없는지 점검한다.
- 기능 확장 가능성 탐구
- 브라우저 푸시 알림의 구현 가능성을 고민하고, 필요 시 적용 방안을 팀과 논의한다.
- 알림의 가치 평가
- 알림 기능이 사용자 만족도나 서비스 재방문율에 미치는 영향을 판단한다.
이번 고민을 통해 단순히 기능을 구현하는 것을 넘어, 사용자의 관점에서 기능을 기획하고 그 의미를 고민하는 과정이 얼마나 중요한지 배웠다. 기술적으로 완벽한 솔루션을 추구하는 것도 중요하지만, 사용자에게 실질적인 가치를 제공하는 것이 우선이라는 점과, 현실적인 기술적 대안을 찾아내는 과정에서 제한된 리소스와 환경 속에서도 최선의 선택을 하는 법을 배울 수 있었다. 앞으로도 이런 고민의 과정을 반복하고, 단순히 코드를 작성하는 개발자가 아니라, 사용자 경험을 향상시키는 서비스를 만들어가는 개발자로 성장하고 싶다.
'개발Article' 카테고리의 다른 글
[TIL]20241212 모든 샤드 클래스의 갱신 요청 처리 설계 (0) | 2024.12.12 |
---|---|
[TIL]20241211 Redis를 활용하기 위한 설계 초안 (2) | 2024.12.11 |
[TIL]20241209 JWT 기반 로그아웃 처리와 블랙리스트 방식 (2) | 2024.12.09 |
[TIL]20241208 Circuit Breaker 도입 고민 (2) | 2024.12.08 |
[TIL]20241207 Enum은 왜 쓰는걸까? (2) | 2024.12.07 |