개발고찰

실무에서 insert 로직을 작성하다 보면 이런 고민을 하게 된다.“어차피 값 몇 개만 바꿔서 한 번 더 insert 하는 건데객체를 새로 만들지 않고 재사용해도 되지 않을까?”결론부터 말하면 insert에서 객체 재사용은 피하는 게 맞다.특히 이력성·동의성 데이터라면

리뉴얼 프로젝트에 들어가기 전까지는DTO를 그저 DB 결과를 담는 그릇 정도로 생각했다.그런데 레거시 시스템을 유지한 채 구조를 바꾸는 대규모 리뉴얼을 겪으면서,DTO가 생각보다 훨씬 많은 역할을 하고 있다는 걸 체감하게 됐다.대규모 리뉴얼 프로젝트를 겪으면서 DTO

Spring에서 @Transactional을 붙였는데분명 예외가 발생했는데도 롤백이 되지 않는 경험을 한 적이 있다.처음에는 MyBatis 문제인가 싶었고,DB 설정 문제인가 싶었고,격하게 삽질을 했다.결론은 단순했다.트랜잭션이 안 먹은 게 아니라, 프록시를 타지 않았

백엔드 개발을 하다 보면 한 번쯤 이런 에러를 보게 된다.auto increment인데 왜 중복이 발생할까?처음에는 DB가 자동으로 값을 잘 관리해줄 거라고 생각하기 쉽다.하지만 실제로는 그렇지 않다.결론부터 말하면시퀀스는 테이블 상태를 전혀 모른다.PostgreSQL

웹 개발을 하다 보면 세션은 너무 당연하게 사용된다.로그인을 유지하고, 사용자 상태를 기억하는 데 필수적인 요소다.하지만 실제로 세션이 어떻게 동작하는지,특히 멀티 WAS 환경에서 어떤 문제가 발생하는지 이해하고 있는 경우는 많지 않다.이 글에서는 JSESSIONID를

백엔드 개발하다 보면 한 번쯤 이런 상황 겪는다.“DB도 정상이고 CPU도 널널한데, 왜 API만 느리지?”이럴 때 의외로 많이 걸리는 게 커넥션 풀이다.나도 처음엔 maxPoolSize만 늘리면 해결되는 줄 알았는데, 구조를 이해하고 나니까 문제 보는 시선이 완전히