조용한 개발 노트

2편에서는 Spring 애플리케이션의 출발점인 IoC 컨테이너(ApplicationContext)가 언제, 어떻게 만들어지는지를 살펴봤습니다.컨테이너가 만들어졌다면 다음 질문은 자연스럽게 이어집니다.“그럼 이 컨테이너 안에는 어떤 객체들이, 어떤 기준으로 들어가게 될까?”이번 글에서는 Spring이 Bean을 컨테이너에 등록하는 방식을 공식문서 흐름에 맞춰 정리해보겠습니다.1. Bean이란 무엇인가Spring에서 Bean은 단순한 객체가 아닙니다.한 문장으로 정의하면 다음과 같습니다.Spring IoC 컨테이너가 생성하고, 관리하며, 생명주기를 책임지는 객체즉, new 키워드로 직접 생성한 객체는 Spring 관점에서는 Bean이 아닙니다.컨테이너의 관리 대상이 되느냐, 이것이 Bean과 일반 객체를 가..

1편에서는 Spring Framework가 어떤 문제를 해결하려고 등장했는지, 그리고 그 핵심 철학이 IoC(Inversion of Control)라는 점을 살펴봤습니다.이번 글에서는 그 IoC를 실제로 구현하는 존재, IoC 컨테이너의 정체를 본격적으로 파헤쳐보려고 합니다.우리가 흔히 사용하는 @Service, @Component, @Autowired 같은 기능들은 모두 이 컨테이너 위에서만 의미를 가집니다.1. IoC 컨테이너란 무엇인가IoC 컨테이너는 한 문장으로 정리하면 다음과 같습니다.애플리케이션에 필요한 객체를 생성하고, 의존성을 연결하며, 생명주기를 관리하는 존재 Spring에서 이 역할을 수행하는 것이 바로 ApplicationContext입니다.즉, Spring 애플리케이션은 단순히 ma..

Spring을 사용하면서 우리는 자연스럽게 이런 문장들을 말합니다.“이건 스프링이 알아서 해줘요”“DI라서 테스트하기 좋아요”“설정은 Boot가 자동으로 해주잖아요”하지만 정작 Spring이 왜 이런 구조를 가지게 되었는지, 그리고 어떤 문제를 해결하려고 만들어졌는지를 정확히 설명하기는 쉽지 않습니다.이 시리즈의 첫 글에서는 코드를 거의 다루지 않고, Spring Framework가 등장하게 된 배경과 핵심 철학부터 정리해보려고 합니다.1. Spring 이전의 Java 서버 개발은 무엇이 문제였을까Spring이 등장하기 전, 엔터프라이즈 Java 개발의 중심에는 EJB(Enterprise JavaBeans)가 있었습니다. EJB는 “대규모 엔터프라이즈 애플리케이션”을 목표로 설계되었지만, 실제 개발자 경..

이 글은 gRPC Java 공식 문서의 Performance 및 Resource Usage 내용을 기준으로, gRPC 서비스를 운영할 때 메모리가 어디서 사용되고, 어떤 상황에서 OOM이나 리소스 고갈이 발생하는지, 그리고 이를 설정과 설계로 어떻게 예방하는지를 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/performance/ 📌 카테고리: Dev > gRPC1. gRPC에서 메모리 문제는 왜 늦게 드러날까?gRPC 메모리 문제는 보통 다음 특징을 가진다.에러 없이 트래픽을 정상 처리하다가부하가 누적된 뒤갑자기 OOM이나 응답 지연으로 나타난다이는 gRPC가 연결 기반이고, 메시지를 버퍼링하며 처리하기 때문이다. 즉, 요청 하나하나는 가볍지만, 누적된 리소스 사..

Spring을 처음 쓸 때 가장 많이 듣는 말이 있습니다.“Spring은 좋은데… 설정이 너무 많아.”“프로젝트 시작하려면 먼저 골격 잡다가 하루가 간다.”“로컬/개발/운영 환경 설정 분리하다가 결국 사람이 실수한다.”Spring Boot는 딱 이 지점, 즉 “잘 만들 수는 있는데 시작/표준/운영 준비가 너무 비싸다”는 비용을 줄이기 위해 등장했다. 공식 문서에서도 Spring Boot는 stand-alone 형태로 실행 가능하고, production-grade 애플리케이션을 최소한의 번거로움으로 만들기 위한 도구라고 설명한다.1) “Spring 자체가 어렵다”가 아니라, “프로젝트의 기본값이 없다”가 문제였다Spring Framework는 강력하지만 선택지가 많다.웹 서버: Tomcat? Jetty?설..