상황스케줄러를 통한 알림 기능을 개발하던 중 제목, 내용을 다양하게 보내야하는 상황이 발생하였다.복약 스케줄을 관리하는 서비스인데, 스케줄에 맞춰 "약을 복용할 시간입니다.", "복용하지 않은 약이 있어요" 와 같이 알림을 보내는 다른 로직들은 동일하지만 제목과 내용만 다른 상황이 발생하였다.  기존 코드와 유사하게 새로운 메서드를 만드는 것은 중복코드가 많이 발생하게 되고 이는 생산성 저하로 이어질 것으로 생각하였기에, 해결 방법을 고민하던 중 Template Method 패턴을 도입하기로 하였다.  Template Method 패턴이란??Template Method 패턴은 객체지향 설계에서 자주 사용되는 행동 패턴(Behavioral Pattern) 중 하나로,상위 클래스에서 알고리즘의 구조(템플릿)..

테스트 커버리지는 코드 테스트의 충분성을 판단하는 데 사용되는 지표다.즉, 테스트가 소스 코드의 어떤 부분까지 실행되었는지를 기준으로, 테스트의 범위와 신뢰도를 평가할 수 있다.이번 글에서는 문장 커버리지부터 MC/DC까지 자주 혼동되는 커버리지 개념들을 예제와 함께 정리해본다.문장 커버리지 (Statement Coverage)문장 커버리지는 테스트 케이스가 소스 코드의 모든 문장을 한 번 이상 실행했는지를 확인하는 커버리지다.예시 코드:if (a > 0) { System.out.println("Positive"); }이때 a = 1인 경우만 테스트했다면, System.out.println()이 실행되어 문장 커버리지는 충족되지만,a   장점구현이 간단하고 이해하기 쉬움테스트 시작 단계에서 적절한 기준단..

1. 문제 상황서비스 개발 중 FETCH JOIN을 통한 쿼리에 Pageable을 적용할 필요가 생기게 되었다.사용자의 알림 내역을 가지고 있는 Notification 테이블과, Notification에 대한 정보를 가지고 있는 Routine테이블이 N:1로 연관관계를 맺고 있는데, 네트워크 통신의 수를 줄이고자 기존에 FETCH JOIN을 통하여 쿼리하고 있었다.하지만 알림 내역은 지속적으로 쌓이는 데이터이므로 Pagenation의 추가가 필요하다고 판단하였다.기존코드 /** * 사용자의 Notification Entity List 반환 FETCH JOIN * */ @Query(value = "SELECT n from NotificationEntity n " + ..

상황 현재 개발 중인 서비스에는 1분 배치 단위로 작동하는 스케줄러가 존재한다. 사용자의 알약 복용 스케줄에 맞춰서 알림을 보내주는데, 개발 서버에 배포 후 테스트 하는 과정에서 복용 시간이 지났는데도 알림이 전송되지 않고 기록도 남지 않는 문제가 발생하였다. 처음에는 알림을 보내주는 과정에서 문제가 발생하였다고 생각하였지만, 알림 전송에 실패하는 경우에도 기록은 남기도록 로직을 작성하였기에, 복용 시간을 스캔하는 과정에서 문제가 있다고 생각하였다. 문제를 디버깅한 결과, 개발 서버의 컨테이너 시간이 UTC(세계 협정시)였기 때문에 스케줄러가 해당 루틴을 찾지 못했었던 것이다.데이터베이스에 복용 루틴을 utc를 고려한 timestamptz으로 변경하는 방법도 있지만, 국내에서만 출시를 할 계획이기 때문에..

개요 CD(Continuous Deployment)를 구축하기 위해 Github Action은 많이 사용되는 배포 자동화 도구 중 하나이다.더불어 애플리케이션을 빌드한 이미지를 보관하기 위해 이미지 보관소 (Dockerhub or ECR 등등)을 활용한다. Github Action을 통하여 AWS ECR에 접근하기 위해서는 ECR의 접근 권한이 있는 계정 정보에 대해서 알아야한다. 하지만 직접적으로 계정 정보를 명시하는 것은 보안상 좋지 않은 방법이다.  따라서 Github Action에서는 OIDC를 이용한 인증 방식을 제공한다. 이 포스트에서는 OIDC를 설정, 계정 정보 대신 AWS에 인증하는 방법을 작성할 예정이다.  AWS 역할 생성 IAM 역할은 IAM 사용자와 다르게 짧은 인증 시간을 가지고..

1. 개요데이터베이스를 설계하고 다루다 보면 같은 구조나 기능임에도 불구하고 다른 용어를 사용하는 경우를 종종 볼 수 있다.이는 데이터베이스를 바라보는 관점에 따라 부르는 이름이 달라지기 때문이다.예를 들어 어떤 사람은 "엔터티", 어떤 사람은 "테이블", 또 어떤 사람은 "파일"이라고 부를 수도 있다.결론적으로 모두 같은 대상을 가리키지만, 표현 방식이 다른 것이다.이 글에서는 데이터베이스 스키마의 세 가지 관점과 그에 따른 명칭을 정리해보았다.2. 데이터베이스 스키마의 3가지 관점데이터베이스를 설계하거나 이해할 때 다음 3가지 스키마 관점으로 나누어 생각한다.① 개념적 스키마 (Conceptual Schema)가장 추상적인 단계로, 비즈니스 요구사항을 기반으로 설계한다.사용자의 관점에서 "어떤 정보가..