DIGGING | 파고들고, 정리하고, 내 것으로 만들기

몬디... 왜 나만 모르는데... 궁금하면 알아내야 직성에 풀리는 사람의 디깅 기록.

JPA 공부하다 보면 어느 순간 마주치는 이슈가 있다. > 겉으론 잘 작동하는데, 로그를 보면 쿼리가 엄청 많이 날아가고 있다면? > 그게 바로 N+1 문제다. > > 이 글은 내가 공부하면서 정리한 내용을 바탕으로, > N+1 문제의 개념부터 실무에서 자주 쓰는 해결

API를 만들다 보면 늘 고민이 생긴다.“이 URI가 맞는 걸까?”, “PUT이야 PATCH야?”, “이건 리소스인가 액션인가?”이 글은 내가 RESTful하게 API를 설계하면서 부딪혔던 실전 고민들을 정리한 글이다.URI 네이밍부터 HTTP 메서드, 응답 설계까지

— 실무에서 자주 쓰는 3가지 패턴 정리 > 실무에서 Redis를 왜 쓰냐고 묻는다면? > 대부분은 캐시 때문이라고 말하겠지만, > 사실 Redis는 그 이상으로 다양하게 활용된다. > > 이 글은 내가 Redis를 공부하면서 정리한 내용을 바탕으로, > 실무에서

서비스 레이어가 점점 길어지고, 보기 싫어진다면?책임이 너무 많아진 서비스 코드를 리팩토링할 때 필요한 기준과 실제 방법을 정리했다.“서비스는 얇게?” 혹은 “서비스는 두껍게?” 라는 논쟁보단,"왜 이렇게 비대해졌는지", \*\*"어떻게 분리할 수 있는지"\*\*에 집

프로젝트를 진행하다 보면 > “컨트롤러에서 Entity를 그대로 반환해도 괜찮지 않나?”라는 생각이 들 수 있다. > 처음엔 편하고 잘 작동하는 것처럼 보여도, > 실제로는 성능, 보안, 유지보수 측면에서 여러 가지 문제가 발생할 수 있다. 이 글은 프로젝트 중에 겪

예외 처리를 분명히 했다고 생각했는데, 왜 클라이언트는 500 에러를 받았을까?@ControllerAdvice로는 못 잡는 예외도 있고,Filter, Interceptor, 비동기 처리에서는 전혀 다른 방식으로 대응해야 한다.실무에서 안정적이고 일관된 예외 응답을 위해

Controller가 점점 비대해진다고 느껴졌다면?나도 처음엔 Controller에서 바로 로직을 처리했지만,나중에는 테스트도 어렵고, 로직 재사용도 안 됐다."이 로직, Controller가 진짜 가져가야 할까?"구조적으로 응집도를 높이기 위해 내가 고민한 기준을 정

Controller에 로직이 몰려 있을 땐 테스트를 아예 안 하게 되거나, Mock을 과하게 쓰게 된다.구조를 바꾼 뒤 테스트 작성은 더 쉬워졌고, 테스트 자체의 품질도 높아졌다.Controller 단에서 Mock 대상이 너무 많음 (Service, Repository

신입으로 입사한 뒤, 프로젝트 구조를 처음 봤을 때 가장 당황스러웠던 건 디렉토리였다.내가 개인 프로젝트나 학원에서 쓸 때는 대부분 아래처럼 단순한 구조였다.그런데 회사 프로젝트는 이렇게 구성돼 있었다.처음엔 그냥 “이름만 다른건가?”라고 생각했는데, 하나하나 코드를

Windows 환경에서 개발하면 자주 터지는 문제가 하나 있다.로컬에서는 잘 되는데Linux 서버(Docker / CI)에서만 import 에러로 터지는 것이다.원인은 단순하다.Windows → 파일 경로 대소문자 구분 안 함Linux → 대소문자 엄격예를 들어 실제