pandaterry's 개발로그

모던 자바의 새로운 API들은 개발자에게 더 나은 코드를 작성할 수 있는 도구를 제공합니다. 하지만 이러한 API들의 설계 의도를 제대로 이해하지 못하고 사용하면 오히려 코드 복잡도를 높이고 성능을 저하시키며, 시스템 설계에 구조적인 문제를 야기할 수 있습니다. 이는 해외 자바 커뮤니티와 언어 설계자들도 지적하는 중요한 문제입니다. Optional: 메서드 반환 타입으로만 설계된 API 설계 의도: null을 명시적으로 표현Optional의 핵심 설계 의도는 "null을 반환할 수 있는 메서드의 반환 타입"으로 사용하는 것입니다. Java Language Architect Brian Goetz는 "Optional은 메서드 반환 타입으로만 사용하도록 설계되었다"고 명시했습니다. 안티패턴: 메서드 파라미터..

JPA와 도메인 모델을 함께 사용하면서 객체지향적으로 설계하다 보면, 조회 쿼리가 복잡해지는 문제에 직면하게 됩니다. 특히 페이지네이션이 필요할 정도의 복잡한 조회에서는 이 문제가 더욱 두드러집니다. 이는 해외 스프링부트 및 자바 커뮤니티에서도 오래 논의된 주제입니다. 실무에서 겪는 문제들 객체지향과 SQL의 근본적 불일치도메인 모델은 비즈니스 로직과 불변성 보장을 위해 풍부한 연관관계를 가져야 합니다. 하지만 이는 조회 쿼리를 복잡하게 만듭니다. JPA는 CRUD 보일러플레이트를 피할 뿐만 아니라 관리되는 엔티티에서 작업할 때 대부분의 수동 레포지토리 호출을 피할 수 있게 해줍니다. 하지만 동작이 신비롭게 느껴질 수 있으며, 쓰기에는 편리하지만 읽기에는 제어권이 부족한 것이 문제입니다. N+1 문제연관..

CH5. 책임 할당하기 도입부 공감이 되는 문장 책임 할당하는 것의 가장 어려운 지점은 어떤 객체에게 어떤 책임을 할당할지 정하는 것이다. 객체지향 설계에서 가장 중요한 것은 올바른 책임 할당입니다. 하지만 어떤 객체에게 어떤 책임을 할당해야 할지 결정하는 것은 쉽지 않습니다. 책임 할당 작업 자체가 트레이드오프 과정이며, 다양한 관점에서 설계를 평가할 수 있어야 합니다. 이번 장에서는 GRASP 패턴을 사용하여 책임을 올바르게 할당하는 방법을 학습합니다. GRASP는 General R..

CH4. 설계 품질과 트레이드오프 도입부 공감이 되는 문장 설계는 변경을 위해 존재하고 변경에는 어떤 식으로든 비용이 발생한다. 훌륭한 설계는? 합리적인 비용 안에서 변경을 수용할 수 있는 구조 결합도가 낮고 응집도가 높은 설계 훌륭하지 못한 설계는? 객체를 단순히 데이터의 집합으로 보는 설계 → 변경에 취약 (구현이 인터페이스에 노출) ..

옛날에도 읽었지만 업무를 하면서 체화가 안되었다고 판단해서 다시 읽어보면서 정리해보려 합니다. 여러번 읽어도 괜찮은 책이라 생각하기도 하고, 더 광범위한 사례가 필요할 때 다른 책도 구매해보려 합니다. 암튼 목표는! 데이터 중심 사고에서 어느정도 벗어나서 객체지향적인 사고를 해봐야겠습니다. 1. 협력협력이란?다양한 객체들이 영화 예매라는 기능을 구현하기 위해 메시지를 주고 받으며 상호작용하는 것여기서 협력에 참여하기 위해 수행하는 로직이 책임협력 안에서 수행하는 책임들이 모여 역할을 구성 메시지 전송객체 사이 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단왜 유일하냐면, 내부 구현에 직접 접근할 수 없기 때문. 메시지 전송만을 통해 요청을 전달가능메시지 발신자가 메서드를 실행하여 메시지를 보내고, ..

인공지능의 뇌와 인간의 뇌를 구분짓는 기준은 뭘까요? 인간은 세상이 어떻게 될지를 먼저 예측하고 그에 맞게 학습하고 재시도하는 등의 루프를 만들어서 행동합니다. 뇌는 정답을 만드는 방향보단 오답을 줄이는 방향으로 작동한다고 합니다. 단순히 받아들이는게 아닌 예측을 하고 빗나가면 수정하는게 인간의 뇌입니다. 물론 인공지능도 예측하고 수정하는 등의 작업을 거칩니다. 하지만, 배운 것만 하게 되고, 오감이 없기에 세상을 계속 먼저 앞서서 느끼기엔 한계가 있을 수 밖에 없죠. 그래서 인간은 많은 시도를 하면서 예측하고 수정하는 행동을 많이 해야 해당 영역에 능통하게 됩니다. 근데 여기서 반문을 할 수 있습니다. 당연한거 아니야? 당연하다고 느낄 수는 있습니다. 하지만, 여기서 중요한 포인트는 세상..

서비스 클래스가 점점 무거워질 때, 우리는 한 번쯤 이런 생각을 합니다.“나는 오케스트레이션만 하니까 괜찮지 않나?”“도메인 객체는 그냥 데이터 구조잖아.”“유효성 검사는 서비스에서 다 하면 되는 거 아냐?” 실제로 몇몇 개발자들도 이런 구조를 문제 삼지 않고 넘기곤 합니다. SRP를 지켰다거나, 도메인을 분리했다는 형식적 명분으로 충분하다고 느낄 수도 있기 때문입니다. 하지만 진짜 중요한 건 그 구조가 정말 도메인의 책임과 역할을 반영하고 있는가입니다. 이번 글에서는 흔히 "이 정도면 괜찮다"라고 여겨지는 코드들이 실제로는 어떤 문제를 유발할 수 있는지를 검토하고, 그에 대한 개선 방향을 구체적인 코드와 함께 살펴보았습니다. 총 4가지 예시를 준비해봤습니다 :) 예시 1. OrderService – ..

웹 백엔드를 운영하다 보면 캐시는 거의 본능처럼 사용하게 됩니다. 대부분은 Redis나 Memcached에 “정확히 일치하는” 키를 기반으로 결과를 저장하곤 합니다. 예를 들어, product:summary:2024-05 같은 키는 5월 상품 요약 데이터를 조회할 때 잘 맞는 구조입니다. 이렇게 명확히 정해진 키로 식별할 수 있는 요청은 캐시하기가 쉽습니다. 그런데 최근에는 자연어 기반 인터페이스가 많아지고 있습니다. LLM을 활용해 데이터를 조회하거나, 자연어로 분석 보고서를 생성하는 시스템이 점점 늘어나고 있습니다. 문제는 이런 자연어 요청은 매번 다르다는 점입니다. 예를 들어 사용자가 이런 식으로 요청할 수 있습니다.“5월 매출 요약 보여줘”“지난달 실적 정리해줘”“이번 분기 매출 추이는?”이 요..