전체 글80 [Spring] JPA @NotNull @NonNull nullable=false 차이와 대안 Entity 설계 시 클라이언트 null 검증 vs DB 제약 조건 not null도메인 엔티티 필드의 유효성을 검증하는 방법에는 여러 가지가 있다.1. 필드에 @NonNull 붙이기2. 필드에 @NotNull 붙이기3. nullable = false 설정하기 각 어노테이션의 차이점과 내가 생각하는 적절한 대안이란 무엇일까 고민해본 부분에 대해서 작성해보려고 한다. @Column(nullable = false)JPA는 @Entity를 설계한 뒤 실제 Hibernate sql을 보면 자동으로 DDL을 생성한다. @Column을 통해 칼럼에 대한 제약 조건을 걸어줄 수 있는데 nullable = false로 두면 create table query에서 해당 칼럼에 not null 조건이 자동으로 명시된다. 하.. 2025. 4. 28. [Spring] @EntityScan은 언제 필요할까 기본적으로 처음 springboot 프로젝트를 생성하면 main func에 @SpringBootApplicaiton 어노테이션이 붙게 된다.그런데 해당 main func과 같은 패키지에 엔티티가 위치하는데 @EntityScan 어노테이션이 추가로 필요할까?JPA 관점에서 @SpringBootApplication을 뜯어보려고 한다. @SpringBootApplication 구성 요소해당 어노테이션은 기본적으로 아래 세 가지 기능을 내장하고 있다.- @Configuration → Spring 설정 관리- @EnableAutoConfiguration → 자동 설정을 활성화 - @ComponentScan → @Component, @Service, @Repository, @Entity, @Controller 등을.. 2025. 4. 27. [Spring] Servlet Filter access log 관리 문제 상황이전에 Spring logback을 통해서 콘솔 로그를 파일로 관리해서 보다 쉽게 디버깅을 할 수 있도록 했다면 이제는 운영 관점에서 보다 쉽게 어떤 요청이 들어왔을 때 서버에서 어떤 응답이 내려줬는지 확인하여 문제점 분석을 용이하게 하고 싶었다.실제 엑세스 로그를 관리하는 것의 중요성을 여러 경험을 통해 체감했기 때문에 이 부분은 내가 꼭 실제 구현을 해보며 짚고 넘어가고자 했다. 해결 방법 : Servlet Filter로 요청과 응답 가로채기PR 링크를 통해 filter 내용 및 req/res를 파일에 남기는 일련의 과정을 확인할 수 있다. 아래는 filter 로직 절차이다.아래 내가 공부해며 구현했던 사고 과정을 정리했다. 1. 필터란?Servlet Filter는 요청/응답 전후 공통 처리.. 2025. 4. 27. [DevOps] Git Actions Self-hosted Runner로 배포 자동화 파이프라인 구축 문제 상황: SSH 타임아웃캡스톤 플젝에 대한 게시글! 일반적으로 AWS 클라우드 서버를 사용하는데 컴공과 캡스톤 수업의 경우 대학 측에서 교내 서버를 대여해 줄 수 있다고 했고, 우리 팀은 학교 NAT 환경에서 확인한 공인 IP로 승인을 받아 해당 IP로만 학교 서버에 접근이 가능한 상황이었다.이 상황에서 일반적인 AWS 기준의 배포 스크립트를 작성할 경우 나타났던 문제점과 해결 방안에 대해 기록하고자 한다. ssh 연결을 통한 접속을 해야했기에 교내 캡스톤 서버에서 ssh-keygen을 통해서 개인키와 공개키를 이미 만들어 둔 상황이었다.개인키공개키git secret로 관리개인 settings ssh key로 관리actions runner가 서버 ssh 접속할 수 있도록 함github이 서버로부터.. 2025. 4. 9. [Spring] 양방향 맵핑 순환 참조 문제 해결 스프링부트 공부를 하고 처음 마주친 에러의 해결 과정에 대해서 기록하고자 한다. 해당 이슈는 이런 문제가 생길 수 있다~라고 대략적으로 들어보기만 했는데 실제로 맞닥뜨린 것은 처음이었다. Let's Go 문제 상황 : 객체 직렬화 시 연관된 양방향 매핑으로 인한 순환 참조 문제기존에 내가 원하던 것은 클라이언트의 req와 해당 요청에 대해 내 서버가 어떤 응답을 내렸는지를 로그 파일로 저장해두기 위해 작성했던 코드에서 발생한 에러였다.@Transactionalpublic BouquetCustomizingResponseV2 updateBouquet(BouquetCustomizingRequest request, Long memberId, Long bouquetId, List multipartFiles) { .. 2025. 4. 5. [DB] PostgreSQL pgvector Extension 이전에 PostgreSQL의 파급성과 pgvector extension에 대해 알게 되었던 경험을 바탕으로 정리를 해보려고 한다. Open Source No.1 DBMSPostgreSQL은 OSS 사상을 바탕으로 다양한 분야의 커뮤니티로 확대 적용되어 PostgreSQL Ecosystem으로 자리잡았다고 생각한다. 실제 ML/AI 분야에서도 PostgresML, pgVector, pg_sparse 등 PostgreSQL 기반의 다양한 기술들이 적용되고 있다. PostgreSQL이 대두될 수 있었던 원인은 뭘까?1. 수직적인 확장성을 보장하기 때문에2. 사용자 정의 데이터 유형도 지원하기 때문에3. 쉬운 서드파티 도구와 통합될 수 있기 때문에4. 오픈소스 및 커뮤니티 중심의 지원이 가능하기 때문에 실제 .. 2025. 4. 3. [Spring] 단일 서버 환경에서 API 기능 동시성 문제 고려하기 2024년 상반기에 진행했던 프로젝트를 2025년 상반기(현재)에 다시 훑어보며 과거에는 신경쓰지 못했던 관점이 무엇이었는지 돌아보고 있는 시간을 가지고 있다. 내가 선정한 여러 관점 중 첫번째 관점이 "동시성 Concurrency" 문제였다. 동시성 문제 상황layered-architecture 상에서 studyRelationService는 교내 재학생들을 위한 스터디 "지원 현황" 이력을 관리하는 파트이다.내가 수정을 해야겠다고 느꼈던 부분은 아래 api들이었다.1. 스터디 지원 취소 API : studyRelation의 status를 CANCEL로 업데이트 한다2. 스터디 게시자가 지원자들을 수락/거절하는 상태 업데이트 API : 지원자의 studyRelation의 status를 ACCEPT || .. 2025. 3. 10. [AWS] RDS를 cmd로 localhost에 복제하기 문제 상황2024년 2월부터 배포했던 프로젝트에서 AWS 프리티어가 이번달 (2025.02)에 종료가 되는 상황이다. 내가 2024년 2월에 시작했던 또 다른 프로젝트를 운영하면서 이용했던 rds를 따로 복제해두지 못한 것에 대한 후회가 남아 AWS의 서로 다른 RDS 인스턴스 간 Replication이 가능하지만 새로운 계정으로 서버 마이그레이션을 하기 전 이 서비스는 내 로컬 상에도 기록 용으로 복제를 해두고자 한다. 먼저 db 복제라는 것은 물리적 기기를 복제하는 것이 아니라 테이블간 관계, 그 내부의 운영 시 테이블 내 데이터 등 모든 정보를 "SQL" 파일로 만들어서 내가 원하는 db에 그 sql 파일을 그대로 실행하여 똑같은 db를 만드는 것이다. 특별한 rdb 툴 설치 없이(이제 윈도우 드라.. 2025. 2. 23. 코테 주력 언어 JAVA로 전환 후 2023년 백준을 처음 풀기 시작했었을 당시 파이썬으로만 풀었었다. 2024년 백엔드 진로로 명확하게 나아가기 시작했고 2024년 1년 동안 그리고 이 순간까지도 거의 JAVA만 썼었다. 그렇기 때문에 코테 언어도 파이썬에서 개발 언어인 자바로 바꾸는데 장기적으로 더 좋을 것 같다는 생각을 했다. 더 일찍 시작했으면 좋았겠지만 2024.12.25 크리스마스... 난 이때 계정을 다시 파서 JAVA로만 백준 문풀을 시작했고 오늘 2025.02.16 두번째 골드를 달성했다. 랭킹상으로만 골드이기 때문에 아직 부족한 점이 많지만 앞으로 더욱 정진해보자. 코테 및 개발 언어로 이제 둘다 JAVA이다. 개강 직전까지 하던 일 잘 마무리하고 2025년 다가오는 개강에도 꾸준히 해보자. 내가 1학년이었을 때 2025.. 2025. 2. 16. [Spring] 콘솔 로그를 어떻게 잘 관리할 수 있을까 개발을 하다보면 트러블 슈팅을 해야할 일이 정말 많이 생긴다. 버그를 해결하는 과정에서 개발 테스트 상 스프링부트를 재실행하면 콘솔 로그가 초기화되면서 직전 로그 내역을 다른 곳에 기록해두지 않는 이상 확인을 할 수 없게 된다. 이뿐만 아니라 프론트에서 백엔드 서버로 API 요청 시 에러 사항에 대해서 확인하고 싶을 때 ec2에 접속해서 docker-compose logs(tail 옵션 붙여서 최근 로그를 바로 확인)를 통해 해당 에러가 언제 생겼는지 훑어야 하는 불편함이 존재한다. 따라서 로그의 영구적인 관리 중요성을 느끼고 WHOA 서비스에 (이슈 링크) 적용해보고자 했다. 먼저 콘솔 창에 로그를 출력할 때 System.out.println을 쓸 경우 성능 저하가 상당하기 때문에 loggerFacto.. 2024. 12. 14. 이전 1 2 3 4 ··· 8 다음
