본문 바로가기
반응형

전체 글224

[Spring boot] DataJpaTest를 이용한 Repository 테스트와 여러 문제 해결 JPA를 활용한 Repository 테스트를 작성할 때, 실제 데이터베이스와 상호작용하는 테스트가 필요할 때가 많습니다. 이를 위해 H2와 같은 인메모리 데이터베이스를 사용하여 테스트 환경을 구축할 수 있습니다. 이때, @SpringBootTest와 같은 전체 애플리케이션 컨텍스트를 로딩하는 대신, @DataJpaTest를 사용하여 JPA 관련 컴포넌트만 로드하는 방법이 효과적입니다. 또한, @Transactional을 사용하여 테스트 후 데이터베이스 상태가 롤백되도록 보장할 수 있습니다. 이 포스트에서 다루는 문제 해결은 다음과 같습니다. (트러블 슈팅 경험)DataJpaTest이용시 의존받는 일부 bean를 로드하지 못하는 문제 해결@Autowired 어노테이션을 이용시 해당 인스턴스의 상태공유가 안.. 2025. 1. 25.
[Spring boot] @Scheduled 어노테이션을 사용한 스케줄링이 작동하지 않는 문제 해결 Spring에서 주기적으로 작업을 실행하고 싶을 때 @Scheduled 어노테이션을 사용하면 매우 유용합니다. 예를 들어, Redis 큐에서 일정 시간 간격으로 메시지를 처리해야 할 때 @Scheduled을 활용해 스케줄링을 구현할 수 있습니다. 하지만, 이 어노테이션을 사용했음에도 불구하고 메서드가 주기적으로 실행되지 않는 문제가 발생할 수 있습니다. 문제 상황다음은 @Scheduled 어노테이션을 사용하여 Redis 큐에서 메시지를 2초마다 가져오는 작업을 수행하는 코드입니다@Component@RequiredArgsConstructor@Slf4jpublic class TourQueueScheduler { private final TourQueueProcessor tourQueueProcessor.. 2025. 1. 25.
[Spring Boot] 멀티-모듈 프로젝트 build시 common 모듈의 의존성 받지 못하는 문제 해결 Spring Boot 프로젝트에서 공통 모듈(common)을 사용하여 엔티티와 DTO를 관리하는 것은 코드 재사용성을 높이고 유지 보수를 용이하게 하는 좋은 방법입니다. 그러나 이 방식에서 발생할 수 있는 문제가 있습니다. 바로 common 모듈에 정의된 JPA 엔티티를 다른 모듈(예: producer나 consumer)에서 사용할 때 발생하는 오류입니다.IDE에서는 정상적으로 인식되지만, 빌드 후에는 엔티티를 찾을 수 없다는 오류가 발생할 수 있습니다. (그래서 당황해서 삽질을 많이 합니다.) 예시 파일 구조Roomie/├── common/ # 공통 모듈 (엔티티, DTO 등)│ ├── build.gradle│ ├── src/│ │ └── main/│ .. 2025. 1. 24.
[Gradle] common을 사용하는 멀티-모듈 프로젝트에서 순환참조 문제 해결 및 최적화 Spring Boot 프로젝트에서 여러 모듈을 관리할 때, 순환참조 문제는 자주 발생할 수 있는 이슈 중 하나입니다. 특히, 멀티 모듈 프로젝트에서는 공통 모듈(common)과 다른 모듈들(producer, consumer) 간의 의존성을 관리하는 데 주의가 필요합니다. 이번 글에서는 common 모듈에서 순환참조 문제를 해결한 방법을 다뤄보겠습니다.문제의 원인producer나 consumer에서 common 모듈을 사용하는 것은 자연스러운 일입니다. common 모듈은 여러 모듈에서 공통으로 사용하는 클래스나 설정을 포함하고 있기 때문에 다른 모듈들이 이를 의존하는 구조입니다. 하지만 문제는 common 모듈에서 producer나 consumer에 대한 의존성을 추가하려고 할 때 발생합니다.이렇게 의존.. 2025. 1. 24.
[Gradle] 멀티-모듈 프로젝트에서 Gradle 설정 Gradle을 활용한 멀티-서버 프로젝트에서는 여러 모듈 간 의존성 설정이 중요합니다. 이 글에서는 공통 모듈을 사용한 프로젝트 구조를 어떻게 설정하는지에 대해 다룹니다. 예시로, Roomie라는 프로젝트를 common, producer, consumer 모듈로 나누어 설명합니다. 1. 프로젝트 구조프로젝트의 루트 디렉토리는 Roomie로 설정하고, 그 아래 common, producer, consumer 폴더를 만들어 각각의 역할에 맞는 기능을 구현합니다. common 모듈은 다른 모듈들이 공통적으로 사용할 기능들을 포함하며, producer와 consumer 모듈은 각각 생산자와 소비자 서버의 역할을 합니다.Roomie/├── common/│ └── build.gradle├── producer/│.. 2025. 1. 24.
[Spring boot jpa] 찜하기/좋아요 api에서 나온 race condition 문제 해결 찜하기 기능을 구현하기 위해 하나의 PATCH API를 사용하였고, 이를 통해 찜하기와 해제 기능을 동시에 처리하도록 설계했습니다. 그러나 다량의 찜하기/해제 요청이 동시에 들어오면서, user_id와 house_id가 같은 pin 엔티티가 중복 생성되는 문제가 발생하였고, 이에 따라 서버 오류가 발생했습니다. 아래와 같이 다대다 관계로 찜/좋아요 기능을 위해 엔티티를 설계했습니다.@Entity@Table(name="pin")@Datapublic class Pin { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @ManyToOne(fetch = FetchType.LAZY, cascade = Casc.. 2025. 1. 24.
[Docker] GitHub Actions와 Docker Hub를 이용해 CI/CD 환경 구축하기 CI/CD(Continuous Integration/Continuous Deployment)는 지속적인 통합과 배포를 가능하게 하는데, 전 이벤트 기반 아키텍처로 구성된 자바 스프링 부트 프로젝트를 베포 자동화 하기 위해서 Producer, Consumer 서버 두개를 베포하는것을 했습니다..├── .github│ └── workflows│ ├── ci.yml # CI: 빌드 및 테스트용 워크플로우 파일│ └── cd.yml # CD: 배포용 워크플로우 파일├── producer│ ├── src│ ├── build.gradle│ └── Dockerfile├── consumer│ ├── src│ ├── build.gradle│ └── .. 2025. 1. 24.
[Docker] Docker Hub 이용해서 CD 환경 구축 시 최신 이미지 미적용 문제 해결하기 1. 문제 상황github actions를 이용해서 CI/CD 환경을 만들었고, push 또는 pull_request 할때마다 docker hub에 push하고 받아와서 베포 자동화 환경을 만들었다. push할때마다 정상적으로 베포가 되고 동작하고, docker ps 명령으로 새로 docker 컨테이너가 의도할때마다 생성되는것을 보고 문제 상황을 인식하기가 쉽지 않았다. 베포한 프로젝트도 정상적으로 동작하지만, 최근 커밋만 적용이 안되는 상황이라 pull이 누락됐을것이라고 생각을 못했고, 프로젝트 코드에 문제가 있다고 생각하여 무의미한 삽질만 이어나갔다.  이용했던 cd workflowname: CD with Gradle and Docker for Producer and Consumeron: push:.. 2025. 1. 24.
Implementation Issues(소프트웨어 구현 주요 이슈들)과 오픈 소스 Implementation IssuesImplementation 과정에서 자주 다뤄지지 않는 문제들에 대해 설명합니다.Reuse (재사용)대부분의 현대 소프트웨어는 기존의 구성 요소나 시스템을 재사용하여 만들어집니다. 소프트웨어를 개발할 때는 가능한 한 기존의 코드를 활용해야 합니다. 이는 개발 속도와 비용 절감을 위한 중요한 전략입니다.Configuration Management (구성 관리)소프트웨어 개발 중 여러 버전의 소프트웨어 구성 요소를 관리해야 하며, 이를 통해 버전 관리 시스템에서 각 구성 요소의 다양한 버전을 추적합니다. 또한 여러 프로그래머들이 동시에 개발하는 경우 이들을 조정하고 관리해야 합니다.Host-Target Development (호스트-타겟 개발)생산 소프트웨어는 보통 개발.. 2024. 12. 2.
Software Evolution(진화)와 유지보수, 리팩토링, 리엔지니어링 Software ChangeSoftware change is inevitable: 소프트웨어는 계속해서 변화를 겪어야 한다. 소프트웨어 사용 중에 새로운 요구사항이 생기고, 비즈니스 환경이 변하며, 에러를 수정해야 하고, 새로운 컴퓨터나 장비가 시스템에 추가될 수 있다. 또한 시스템의 성능이나 신뢰성을 개선할 필요가 있을 수 있다.Key problem for organizations: 모든 조직에서 중요한 문제는 기존 소프트웨어 시스템에 변경을 구현하고 관리하는 것이다. 대기업의 경우, 소프트웨어 예산의 대부분은 새로운 소프트웨어 개발보다는 기존 소프트웨어의 변경과 발전에 사용된다.A Spiral Model of Development and EvolutionSpiral model은 소프트웨어 개발 및 진.. 2024. 12. 1.

티스토리툴바