로빈의 무기고

[Spring MVC] HandlerAdapter 의 구현체는 어떤것들이 있을까?

dragonwaterr — Tue, 7 Oct 2025 20:42:12 +0900

지난 글에서는 왜 Spring MVC에 HandlerAdapter라는 개념이 필요한가를 살펴봤다.
이번 글에서는 한 발짝 더 들어가, 실제로 존재하는 HandlerAdapter 구현체들은 어떤 것들이 있고, 각각 어떤 차이가 있는지 정리해보자.

HandlerAdapter 인터페이스의 기본 역할

다시 한 번 확인하자.
모든 HandlerAdapter는 HandlerAdapter 인터페이스를 구현해야 하며, 핵심 메소드는 두 가지다.

public interface HandlerAdapter {

	/**
	 * Whether this {@code HandlerAdapter} supports the given {@code handler}.
	 * @param handler the handler object to check
	 * @return whether the handler is supported
	 */
	boolean supports(Object handler);

	/**
	 * Handle the request with the given handler, previously checked via
	 * {@link #supports(Object)}.
	 * <p>Implementations should consider the following for exception handling:
	 * <ul>
	 * <li>Handle invocation exceptions within this method.
	 * <li>{@link HandlerResult#setExceptionHandler(DispatchExceptionHandler)
	 * Set an exception handler} on the returned {@code HandlerResult} to handle
	 * deferred exceptions from asynchronous return values, and to handle
	 * exceptions from response rendering.
	 * <li>Implement {@link DispatchExceptionHandler} to extend exception
	 * handling to exceptions that occur before a handler is selected.
	 * </ul>
	 * @param exchange current server exchange
	 * @param handler the selected handler which must have been previously
	 * checked via {@link #supports(Object)}
	 * @return {@link Mono} that emits a {@code HandlerResult}, or completes
	 * empty if the request is fully handled; any error signal would not be
	 * handled within the {@link DispatcherHandler}, and would instead be
	 * processed by the chain of registered
	 * {@link org.springframework.web.server.WebExceptionHandler}s at the end
	 * of the {@link org.springframework.web.server.WebFilter} chain
	 */
	Mono<HandlerResult> handle(ServerWebExchange exchange, Object handler);

}

supports() : 이 어댑터가 해당 핸들러를 지원할 수 있는지 확인
handle() : 지원하는 경우, 실제로 핸들러를 실행하고 ModelAndView를 반환

앞선 글에서 말했듯이, DispatcherServlet은 단순히 모든 HandlerAdapter를 우선순위대로 돌면서 supports() → handle()을 호출한다.

주요 구현체들

1. HttpRequestHandlerAdapter

public class HttpRequestHandlerAdapter implements HandlerAdapter {

	@Override
	public boolean supports(Object handler) {
		return (handler instanceof HttpRequestHandler);
	}

	@Override
	public @Nullable ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {

		((HttpRequestHandler) handler).handleRequest(request, response);
		return null;
	}

}

지원하는 컨트롤러: HttpRequestHandler 인터페이스
특징: 응답을 컨트롤러가 직접 작성 (Servlet API 스타일)
리턴: 항상 null (즉, 뷰 렌더링 단계로 가지 않음)
사용 사례: 이미지, 파일 다운로드, API 응답을 직접 쓰는 경우

2. SimpleControllerHandlerAdapter

public class SimpleControllerHandlerAdapter implements HandlerAdapter {

	@Override
	public boolean supports(Object handler) {
		return (handler instanceof Controller);
	}

	@Override
	public @Nullable ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {

		return ((Controller) handler).handleRequest(request, response);
	}

}

지원하는 컨트롤러: org.springframework.web.servlet.mvc.Controller 인터페이스
특징: 반드시 ModelAndView를 반환
리턴: ModelAndView → DispatcherServlet이 ViewResolver를 통해 뷰 렌더링
사용 사례: 스프링 초창기 방식, 지금은 거의 사용되지 않음

3. RequestMappingHandlerAdapter

@Override
protected boolean supportsInternal(HandlerMethod handlerMethod) {
    return true;
}

@Override
protected @Nullable ModelAndView handleInternal(HttpServletRequest request,
        HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {

    ModelAndView mav;
    checkRequest(request);

    // Execute invokeHandlerMethod in synchronized block if required.
    if (this.synchronizeOnSession) {
        HttpSession session = request.getSession(false);
        if (session != null) {
            Object mutex = WebUtils.getSessionMutex(session);
            synchronized (mutex) {
                mav = invokeHandlerMethod(request, response, handlerMethod);
            }
        }
        else {
            // No HttpSession available -> no mutex necessary
            mav = invokeHandlerMethod(request, response, handlerMethod);
        }
    }
    else {
        // No synchronization on session demanded at all...
        mav = invokeHandlerMethod(request, response, handlerMethod);
    }

    if (!response.containsHeader(HEADER_CACHE_CONTROL)) {
        if (getSessionAttributesHandler(handlerMethod).hasSessionAttributes()) {
            applyCacheSeconds(response, this.cacheSecondsForSessionAttributeHandlers);
        }
        else {
            prepareResponse(response);
        }
    }

    return mav;
}

지원하는 컨트롤러: @Controller, @RequestMapping, @GetMapping, @PostMapping 등 어노테이션 기반 컨트롤러
특징:
- 다양한 리턴 타입 지원 (ModelAndView, String, ResponseEntity, Object, void 등)
- 내부적으로는 HandlerMethodReturnValueHandler 체인을 통해 리턴 값을 표준 ModelAndView로 변환
- AbstractHandlerMethodAdapter를 상속하여 handleInternal, supportsInternal을 오버라이딩 (템플릿 메소드 패턴 구조)
리턴: 최종적으로 ModelAndView 또는 null
사용 사례: 현재 Spring MVC의 사실상 표준. 우리가 흔히 쓰는 모든 @Controller 기반 로직이 여기에 해당

패키지 구조 차이

코드 레벨에서 살펴보면, 구현체들이 서로 다른 패키지에 위치한다.

HttpRequestHandlerAdapter, SimpleControllerHandlerAdapter → org.springframework.web.servlet.mvc
RequestMappingHandlerAdapter → org.springframework.web.servlet.mvc.method.annotation

이 차이는 역사적 배경 때문이다.

mvc 패키지는 레거시 컨트롤러 지원 (Spring 초창기부터 존재)
mvc.method.annotation 패키지는 어노테이션 기반 MVC 지원 (추후 추가)

즉, 호환성과 책임 분리를 위해 구조적으로 구분해 둔 것이다.

Ordered와 우선순위

모든 HandlerAdapter는 동시에 존재할 수 있고, 어떤 순서로 실행할지는 Ordered 인터페이스(또는 @Order)로 제어한다.

구현하지 않으면 기본적으로 LOWEST_PRECEDENCE (= Integer.MAX_VALUE)
DispatcherServlet은 이 순서대로 어댑터를 검사하며, supports(handler)가 true인 첫 번째 어댑터를 실행한다.

정리

HttpRequestHandlerAdapter: 컨트롤러가 직접 응답을 쓰고, 항상 null 반환
SimpleControllerHandlerAdapter: 레거시 Controller → 반드시 ModelAndView 반환
RequestMappingHandlerAdapter: 현대 MVC 표준, 다양한 리턴 타입을 수용하고 내부적으로 ModelAndView로 표준화

즉, HandlerAdapter 구현체들은 서로 다른 컨트롤러 모델을 위한 다리 역할을 한다.
레거시부터 최신 방식까지, 다양한 컨트롤러 스타일을 모두 수용할 수 있었던 이유가 바로 여기에 있다.

참고

Spring 스펙 공식문서

1. HandlerAdapter : https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/servlet/HandlerAdapter.html

2. SimpleControllerHandlerAdapter : https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/servlet/mvc/SimpleControllerHandlerAdapter.html

3. HttpRequestHandlerAdapter : https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/servlet/mvc/HttpRequestHandlerAdapter.html

4. RequestMappingHandlerAdapter : https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerAdapter.html

Spring 공식 깃허브

1. HandlerAdapter : https://github.com/spring-projects/spring-framework/blob/main/spring-webflux/src/main/java/org/springframework/web/reactive/HandlerAdapter.java

2. SimpleControllerHandlerAdapter : https://github.com/spring-projects/spring-framework/blob/main/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/SimpleControllerHandlerAdapter.java

3. HttpRequestHandlerAdapter : https://github.com/spring-projects/spring-framework/blob/main/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/HttpRequestHandlerAdapter.java

4. RequestMappingHandlerAdapter : https://github.com/spring-projects/spring-framework/blob/main/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/RequestMappingHandlerAdapter.java#L826

[Spring MVC] HandlerAdapter 가 존재하는 이유는 뭘까?

dragonwaterr — Fri, 3 Oct 2025 20:44:02 +0900

Spring MVC의 요청 처리 과정을 살펴보면, 흔히 이렇게 설명된다.

사용자의 요청이 들어오면 DispatcherServlet이 이를 가장 먼저 받는다. (Front Controller)
HandlerMapping이 요청 URL에 맞는 핸들러를 찾아낸다.
HandlerAdapter가 선택된 핸들러를 실행할 수 있는 준비를 한다. (핸들러 타입에 따라 실행 방법이 달라질 수 있음)
준비된 핸들러가 실제 컨트롤러 메서드로 호출된다.
컨트롤러 실행 결과는 ModelAndView 형태로 DispatcherServlet에 반환된다
이후 뷰 렌더링 단계(ViewResolver, View)로 넘어가 최종 응답을 사용자에게 돌려준다.

문득 이런 의문이 생겼다.

HandlerMapping에서 이미 컨트롤러를 찾았는데, 그냥 바로 실행하면 되지 않나?
굳이 HandlerAdapter를 거쳐가는 이유가 뭘까?

먼저 둘에 어떤 차이가 있는지 먼저 살펴봐야한다.

HandlerMapping vs HandlerAdapter

HandlerMapping
단순히 “이 URL에 대한 핸들러는 누구인지”를 찾아내는 역할.
HandlerAdapter
선택된 핸들러를 어떻게 실행할지 아는 존재.

즉, 무엇을 실행할지 찾는 것과 어떻게 실행할지 아는 것을 분리해둔 것이다.

그렇다면 왜 굳이 분리했을까?

핵심은 컨트롤러의 다양성에 있다.
스프링에서 컨트롤러는 한 가지 형태만 있는 게 아니다.

예전에는 Controller 인터페이스를 구현하는 전통적인 방식이 있었고,
HttpRequestHandler처럼 서블릿 API와 유사하게 동작하는 컨트롤러도 있었으며,
지금은 @Controller + @RequestMapping 기반의 어노테이션 방식이 사실상 표준이다.

만약 HandlerMapping이 단순히 컨트롤러를 찾는 것뿐만 아니라,
실행하는 방법까지 다 품고 있었다면 어땠을까?

새로운 컨트롤러 타입이 등장할 때마다 HandlerMapping의 코드도 수정해야함.
역할이 뒤섞여 복잡해지고, 확장성은 떨어짐.

HandlerAdapter가 가져오는 장점

확장성 (Open/Closed Principle)
새로운 컨트롤러 형태가 필요하다면, 그에 맞는 HandlerAdapter 구현체만 추가하면 된다. 기존 DispatcherServlet이나 HandlerMapping은 전혀 수정할 필요가 없다.
DispatcherServlet 단순화
DispatcherServlet은 “핸들러를 찾고 → 어댑터를 통해 실행한다”는 흐름만 유지하면 된다.
실행 세부사항은 Adapter에게 위임한다.
호출 방법의 다양성 수용
어떤 컨트롤러는 service(req, res) 스타일로 직접 응답을 쓰기도 하고, 어떤 컨트롤러는 ModelAndView를 반환하기도 하며,
어노테이션 기반 컨트롤러는 String, Object, ResponseEntity 등 훨씬 다양한 형태를 반환할 수 있다.
Adapter는 이런 차이를 흡수해 DispatcherServlet이 일관된 흐름을 유지할 수 있게 해준다.

추가로 알게된 부분

HandlerAdapter의 우선순위를 지정할 수 있다 : Ordered와 HandlerAdapter의 우선순위

공식 문서와 코드를 보면, HandlerAdapter 구현체들은 Ordered 인터페이스(혹은 @Order 어노테이션)를 통해
우선순위를 가질 수 있다.

1. 반드시 구현해야 하는 건 아니다.
- Ordered를 구현하지 않으면 기본적으로 LOWEST_PRECEDENCE(= Integer.MAX_VALUE)로 간주된다.
(숫자가 낮을수록 우선순위가 높음)

2. DispatcherServlet의 역할은 단순하다.
- 모든 Adapter를 우선순위대로 정렬
- 순서대로 supports(handler) 메서드를 호출
- 해당 핸들러를 처리할 수 있는 첫 번째 Adapter를 선택

즉, DispatcherServlet만의 별도 기준은 없다. “줄세우기 + supports 검사”가 전부다.

마무리

정리하자면,

HandlerMapping은 “무엇을 실행할지”를 찾고,
HandlerAdapter는 “어떻게 실행할지”를 책임진다.

이 둘의 분리 덕분에 Spring MVC는 컨트롤러의 형태가 달라져도 유연하게 대응할 수 있다.
만약 HandlerAdapter가 없었다면, 새로운 컨트롤러 타입이 등장할 때마다
HandlerMapping이나 DispatcherServlet의 코드가 복잡해졌을 것이다.

즉, HandlerAdapter는 스프링 MVC가 다양한 컨트롤러 모델을 확장 가능하게 지원하기 위해 반드시 필요한 존재다.

다음 포스팅에서는, 내용을 이어서 HandlerAdapter의 구체적인 구현체들에는 어떤 것들이 있고, 각각 어떻게 다른지를 살펴볼 예정이다.

[회고] 카테부 1~2 주차 회고입니다.. 근데 이제 반성을 곁들인

dragonwaterr — Sun, 21 Sep 2025 23:28:02 +0900

카테부 풀스택 과정을 시작한지 벌써 2주가 흘렀다. 따라만 갔는데 월화수목금 월화수목금 쏜살같이 흘러갔다. (아니 사실 못따라갔다 ..) 2주면 아직 맛도 안봤을텐데 회고를? 라고 생각 할 수 있겠지만, 지난 2주 동안 제대로 학습하는 법을 많이 배웠다고 느꼈다.

2주 전까지의 내 모습 ..

메가스터디 유튜브 : https://www.youtube.com/shorts/MJ2hHgqSTMs

1. 해야되는 공부가 아니라 하고 싶은 공부만 하고 있었다.

그렇다. 사실 공부하고 새롭게 배워야할 내용들이 엄청나게 많다는걸 머리로는 알고 있었지만

내가 잘모르고 부족하다는 걸 진심으로 인정하는게 어려웠던 것 같다. 그리고 이것보다 더 중요한 부분을 느꼈는데
바로 이것이다.

2. 설명하지 못하면 제대로 이해한게 아니다.

출처 :https://www.azquotes.com/quote/1445769

내가 안다고 착각하는 부분이 너무 많은거였다.

어떤 개념이나 동작과정에 대해 질문을 받았을 때 설명을 하려고 하니 중간중간에 근거가 명확하지 않아 설명이 막힌 부분이 너무 많았다. 그건 내가 제대로 알고있지 않아서였고, 대략적인 개념만 알고있는걸 안다고 착각한 것 뿐이었다.

'대충 이렇게 돌아가잖아' 이 멘트는 이제 진짜 졸업 해보도록 하자.

3. 넌 꼭 블로그만 보고 공식문서를 안보더라.

String (Constant) Pool 에 대해 조사하게 되는 계기가 있었다.

블로그 몇개를 통해 조사했는데, 완전 상반된 내용의 글이 두 개가 있어서 너무 당황했다.

사실 그 상황에서는 공식문서에서 해당 내용을 어떻게든 찾아서 결론을 지으면 되는 부분인데

내가 이 부분을 멍청하게 "이럴 땐 어떡하죠?" 식으로 질문을 했다.. ㅋㅋ

기술면접에 들어가서 질문에 대한 답을 했는데 뭔가 이상해서 해당 지식의 출처를 물어보니

그냥 블로그에서 봤다고 하면 그 사람을 뽑겠는가?

아직 어렵긴 하지만 조금씩 서칭능력이 향상되고 있음을 느끼니, 금방 익숙해지지 않을까 기대해본다.

4. 기술에 대한 의문을 가지지 않았다.

A에 대해 배우면서 A 이전에 사용하던 B 를 왜 버리고 A 를 사용하게 됐는가?

둘의 장단점이 무엇이며 어떤 상황에 무엇을 쓰는게 더 좋은가?

등의 의문을 가지지 않았다.

끊임없이 '왜?' 를 던지며 깊게 공부하는 주변 동료들을 보며

저렇게 공부하면 배운 개념들이 단순 조각조각이 아니라, 확장성있게 머리에 자리잡을 수 있겠다.

라는 생각을 많이 하게된 부분이었다.

오늘 회고는 반성문처럼 썼지만, 사실 이 모든 부분들을 뒤집어서 적용한다면 제대로 학습하는 방법의 메뉴얼이 될거라고 생각한다.

이제 이 부분들을 최대한 적용한 학습을 통해 카테부에서 최소한 개발자 비슷한 무언가는 되어서 나가도록 노력할 것이다.

[SWEA] 나무 높이 (D2) 풀이 (Java)

dragonwaterr — Tue, 2 Sep 2025 22:30:02 +0900

PASS 받은 정답코드는 맨 밑에 있습니다.

시간 : 50개 테스트케이스를 합쳐서 C/C++의 경우 1초 / Java의 경우 1초
메모리 : 힙, 정적 메모리 합쳐서 256MB 이내, 스택 메모리 1MB 이내

[문제]

N개의 나무가 있다. 초기의 각 나무의 키가 주어진다. 하루에 한 나무에 물을 줄 수 있다. 첫 날은 물을 준 나무의 키가 1 자라고, 둘째 날은 물을 준 나무의 키가 2 자라고, 셋째 날은 물을 준 나무의 키가 1 자라는 식으로, 홀수 번째 날은 키가 1 자라고 짝수 번째 날은 키가 2 자란다. 모든 나무의 키가 처음에 가장 키가 컸던 나무와 같아지도록 할 수 있는 최소 날짜 수를 계산하라. 어떤 날에는 물을 주는 것을 하지 않을 수도 있다.

예를 들어 나무가 2그루이고 각각의 높이가 4와 2라고 하자. 첫째 날에 물을 주게 되면, 나무의 높이를 모두 4로 만들기 위해서는 3일째까지 물을 주어야 한다. 둘째 날은 아무 일도 안 하게 된다. 하지만, 첫째 날을 쉬고 둘째 날에 물을 주면 2일 만에 나무의 높이가 모두 4가 된다.

케이스 수 30, N 제한 100, 나무 높이 최대 120

[제약사항]

나무의 개수 N은 2 이상 100 이하이다. (2 ≤ N ≤ 100)

주어지는 나무의 초기 높이는 1 이상 120 이하이다.

제시된 상황을 정리를 해보자.

N 개의 나무가 각자의 높이를 가진다.
처음 상태에서 가장 키 큰 나무의 키가 모든 나무들의 목표 키다.
하루 한 나무에만 물을 줄 수 있다. 물을 아예 안주고 넘어갈 수도 있다.
홀수날에 물주면 1cm 자라고, 짝수날에 물주면 2cm 자란다.

생각

처음에 가장 키가 컸던 나무 키를 maxH 라고 하자.

모든 나무는 maxH 보다 크거나 작아지는게 아니라, 정확하게 같은 키가 되는게 목표라는 점이 중요했다.

그렇다면, maxH 와 차이가 홀수만큼 나는 나무들은, 물을 받은 날에 홀수날이 적어도 하루는 포함되어야 한다.

왜냐하면 키를 홀수만큼 키우는 방법과 짝수만큼 키우는 방법은 다음처럼 서로 차이가 있기 때문이다.

1cm : 홀수날 하루만큼 물주기
2cm : 짝수날 하루만큼 물주기 or 홀수날 두 번에 걸쳐 물주기

홀수만큼 차이나는 나무들 물주기 과정은

코드로 다음과 같이 표현했다.

int oddDiffTrees = 0; // 1cm 를 한 번은 받아야 하는 나무 수
int totalDiff = 0;
for (int j = 0; j < n; j++) {
    int curDiff = maxH - trees[j];
    totalDiff += curDiff;
    if (curDiff % 2 == 1) {
        oddDiffTrees++;
        trees[j]++; // 차이의 짝수화
    }
}
totalDiff -= oddDiffTrees;

// maxH 와의 차이가 홀수인 나무들에 모두 1cm 를 줬을 때의 최소 days
int days = 2 * oddDiffTrees - 1; 
// days 동안 사용할 수 있었던 2cm 들의 합
int usableH = days - 1;

홀수날에 줄 물을 계산한 와중에,

짝수날에 물을 줄 수 있는 기회들은 아직 사용하지 않았기 때문에 usableH 라는 변수에 저장해둔다.

maxH 와 각 나무들의 높이 차를 모두 합한 값은 totalDiff 에 저장했다.

만약 usableH 가 totalDiff 이상이라면 더 이상 물을 줄필요가 없으므로 정답이 도출되지만

아마 그렇게 간단한 테스트케이스만 있지는 않을 것이므로 totalDiff - usableH 만큼의 물을 더 줘야하는 상황을 생각해보자.

홀수일에 최소 한 번은 물을 받야아 하는 나무들에 물을 주며

maxH 와 각 나무들의 차이를 모두 짝수화 할 수 있다.

이제 문제는 홀수날에 2cm 를 키우고, 짝수날에 1cm 를 키울 수 있으며

모든 나무가 maxH 와의 키 차이가 짝수만큼 나게되는 새로운 문제로 바뀌었다.

이렇게 모든 차이를 짝수화 하게되면 좋은 점이있다.

아까 살펴봤듯이 2cm 를 키우는 방법은 2가지가 있기 때문에,

얼마만큼 차이가 나던 간에 최적의 물주기를 보장할 수 있다.

이게 무슨 말인지 이해하기 위하여, 차이의 짝수화를 실행하지 않은 예시를 하나 살펴보자.

<차이 짝수화가 이뤄지지 않은 경우>
나무들의 높이 : [10, 9, 9, 9, 9]
maxH = 10
totalDiff = 4

차이의 짝수화를 진행하지 않았다면, 위 테스트케이스를 해결하기 위해 필요한 날짜는

총 차이 4cm 를 키울 수 있는 3일이 아닌 7일이다. (1, 3, 5, 7 일에만 물을 1cm 줘야함.)

즉 어떤 날짜를 건너뛸지 말지에 대해 생각을 해야만 한다.

반면 차이의 짝수화가 이루어진 경우를 살펴보자.

<차이 짝수화가 이뤄진 경우>
나무들의 높이 : [10, 6, 8, 6, 8]
maxH = 10
totalDiff = 12

이렇게 차이의 짝수화를 진행했다면

위 테스트케이스를 해결하기 위해 필요한 날짜는 총 12cm 를 키울 수 있는 8일이 된다.

홀/짝수날에 물주기를 쉴 것 인가에 대한 고민이 필요없어 진다는 것이다.

다만 앞에서 언급했듯이, 차이의 짝수화를 진행하면서

days 변수에 필요한 필수 홀수날을 반영했으므로

남은 높이들의 처리는 짝수날부터 시작하는 문제라고 생각하면 된다.

그럼 이제 추가로 키워야 하는 높이 총합을 totalDiff - usableH 를 toGrowH 라고 하고,

toGrowH 만큼을 키우기 위해 필요한 날짜 수를 i 라고 한다면

totalDiff - usableH <= i + (i + 1)/2

위 점화식을 만족하는 최소의 i 를 찾았을 때 i + days 가 최종 정답이 된다.

점화식은 각 날짜에 키울 수 있는 최대 키 누적합 수열을 써보면 구할 수 있다.

i : 1 2 3 4 5 6 ...
h : 2 3 5 6 8 9 ...

정답 코드에는 while 문을 통해 i를 1씩 증가시키며 최소가 되는 i 를 찾았는데,

이는 toGrowH 가 굉장히 큰 수일 경우 시간복잡도 측면에서 문제가 될 수 있다.

때문에 위 점화식을 i 를 기준으로 정리하여

다음과 같이 최적화된 계산으로 i 를 얻을 수 있다.

int i = (int) Math.ceil((2.0 * toGrowH - 1.0) / 3.0);

아래는 전체 소스코드이다.

import java.io.*;
import java.util.StringTokenizer;
 
class Solution {
    // 나무 높이 (SWEA)
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
 
        int tc = Integer.parseInt(br.readLine());
 
        for (int i = 0; i < tc; i++) {
            bw.write("#"+(i+1)+" ");
             
            int n = Integer.parseInt(br.readLine());
            int[] trees = new int[n];
            int maxH = 0;
 
            StringTokenizer st = new StringTokenizer(br.readLine());
            for (int j = 0; j < n; j++) {
                int h = Integer.parseInt(st.nextToken());
                maxH = Math.max(maxH, h);
                trees[j] = h;
            }
 
            int oddDiffTrees = 0; // 1cm 를 한 번은 받아야 하는 나무 수
            int totalDiff = 0;
            for (int j = 0; j < n; j++) {
                int curDiff = maxH - trees[j];
                totalDiff += curDiff;
                if (curDiff % 2 == 1) {
                    oddDiffTrees++;
                    trees[j]++; // 차이의 짝수화
                }
            }
            totalDiff -= oddDiffTrees;
 
            int days = 2 * oddDiffTrees - 1; // maxH 와의 차이가 홀수인 나무들에 모두 1cm 를 줬을 때의 최소 days
            int usableH = days - 1; // days 동안 사용할 수 있었던 2cm 들의 합
 
            if(usableH >= totalDiff) {
                bw.write(days + "\n");
                continue;
            }
 
            int toGrowH = totalDiff - usableH; // 더 키워야 하는 총 높이
 
            // days 는 이제 짝수일, i 는 1부터 시작하는 자연수.
            // toGrowH <= i + (i+1)/2 를 만족하는 가장작은 i 찾아 days 에 추가
            int extraDays = 1; // i
            while(toGrowH > extraDays + (extraDays+1)/2) {
                extraDays++;
            }
            days += extraDays;
            bw.write(days + "\n");
        }
        bw.flush();
    }
}

[JPA] 영속성 컨텍스트에 대해 알아보자

dragonwaterr — Fri, 22 Aug 2025 21:15:39 +0900

잘못된 정보를 발견하셨다면 지적과 수정요청 언제나 환영입니다 감사합니다 ! ! !

JPA/Hibernate 를 학습하다보면 영속성 컨텍스트(Persistence Context) 가 등장한다. 이것에 대해 알아보자.

0. 영속성 컨텍스트란 ?

먼저, 영속성 컨텍스트에 대한 정의는 java docs 의 Interface EntityManager 문서에서 찾아볼 수 있다.

~~음 ... 완벽하게 이해했어!~~

우선 드래그한 부분을 한글로 해석해보자.

영속성 컨텍스트는 영속(Persistent) 상태의 엔티티들이 관리되는 집합 공간이다.
영속성 컨텍스트 내에서는 각 엔티티의 고유한 식별자에 대해 단 하나의 엔티티 인스턴스만이 존재하며,
이 엔티티 인스턴스들과 그 생명 주기(Lifecycle)가 관리된다.

위 설명을 통해 아래의 2가지 정보를 알 수 있다. 이 정보들을 기준으로 영속성 컨텍스트에 대해 더 알아보자.

1. 영속성 컨텍스트는 엔티티의 '상태' 를 기준으로 관리여부를 결정한다.
2. 엔티티 인스턴스들의 생명주기를 관리하기 위해 영속성 컨텍스트가 제공하는 기능이 존재한다

1. 영속성 컨텍스트가 인식하는 엔티티의 상태 종류

아래 내용을 이해하기 위해서는 영속성 컨텍스트 내부의 1차 캐시에 대해 이해하고 있어야 한다.

* 영속성 컨텍스트의 1차 캐시
1차 캐시는 한 번 조회한 엔티티 인스턴스 정보를 임시로 저장해두는 공간이다. 1차 캐시가 없다면 같은 엔티티를 여러번 조회하더라도 매번 DB에 쿼리를 통해서만 얻을 수 있기 때문에, 1차 캐시는 엔티티의 효율적인 관리를 위해서 필수적이다.
엔티티 인스턴스는 Map 형태로 저장되는데,
Key = 엔티티의 @Id 값 / Value = 엔티티 인스턴스 그 자체 (new 를 통해 생성된 객체의 메모리 주소) 가 된다.

1차 캐시는 영속성 컨텍스트와 생명주기를 함께한다. Spring에서 주로 사용하는 Transaction Scoped 영속성 컨텍스트의 경우, 일반적으로 하나의 트랜잭션 범위와 동일하게 유지된다. 트랜잭션이 종료되거나 em.close() 를 실행하면 영속성 컨텍스트가 종료되고 1차 캐시도 함께 사라진다.

1. 비영속 / Transient(New)

객체를 생성만 했을 뿐 아직 영속성 컨텍스트에 의해 관리되지 않는 상태이다.

em.persist() 를 통해 영속(Managed) 상태로 만들 수 있다. (em 은 생성한 EntityManager 인스턴스)

2. 영속 / Managed(Associated)

EntityManager 에 의해 엔티티가 영속성 컨텍스트의 관리대상에 등록된 상태이다.

영속성 컨텍스트의 변경 감지(Dirty Checking) 기능이 동작한다.

3. 준영속 / Detached

ID는 할당이 되었지만, em.detach() 로 영속성 컨텍스트에서는 분리된 상태이다.
삭제와는 다르게 아직 ID가 살아있기 때문에, em.merge() 로 다시 영속 상태로의 전환이 가능하다.

(ID가 할당되었다는 말은, 일단 영속성 컨텍스트에 최소 한 번은 등록되었다는 뜻이다.)

준영속 상태가 되는 경우는 em.detach(), em.clear(), em.close() 호출 시이다.

4. 삭제 / Removed

em.remove() 를 통해 삭제 예정 상태로 마킹한다. DB에서 실제로 삭제되는 시점은 flush() 를 호출한 이후다.

flush()는 수동으로 호출하거나, 트랜잭션 커밋 시점에 자동으로 호출된다.

2. 영속성 컨텍스트가 제공하는 기능

1. 1차 캐시

앞서 설명한 기능이다. 영속성 컨텍스트 내부의 엔티티를 임시 저장소다.

1. em.find()를 통해 엔티티를 조회
2. 1차 캐시에서 해당 ID를 가진 엔티티가 있는지 조회
3. 만약 존재한다면 DB에 접근하지 않고, 메모리에서 바로 엔티티를 반환

위 과정을 통해 DB 접근이 아닌 메모리에서 바로 엔티티를 반환하여 조회 성능을 크게 향상 시킬 수 있다.

만약 조회하는 엔티티가 1차 캐시에 존재하지 않아서 DB를 조회했다면, 앞으로 1차 캐시를 활용할 수 있도록 해당 엔티티 정보를 1차 캐시에 저장한다. 1차 캐시는 세션 범위 내에서만 유효하다.

2. 동일성 보장

같은 트랜잭션 내에서 동일한 ID를 가진 엔티티를 여러 번 조회해도, 영속성 컨텍스트는 항상 최초에 조회된 동일한 메모리 주소의 인스턴스를 반환한다.

// memberA는 ID가 "user1"인 회원 엔티티
Member a = em.find(Member.class, "user1");
Member b = em.find(Member.class, "user1");

System.out.println(a == b); // true

이처럼 참조값을 비교하는 == 연산의 결과가 true로 나오는, 즉 '동일성'이 보장된다.

마치 자바 컬렉션에서 같은 객체를 여러 번 꺼내 쓰는 것처럼, 애플리케이션의 예측 가능하고 일관된 동작을 보장한다.

3. 변경 감지(Dirty Checking)

영속성 컨텍스트의 가장 강력한 기능 중 하나이다.

별도의 update 메서드를 호출하지 않아도, 엔티티의 변경 사항을 자동으로 감지하여 데이터베이스에 반영해준다.

1. JPA는 엔티티를 1차 캐시에 저장할 때, 해당 엔티티의 최초 상태를 복사하여 스냅샷(Snapshot)으로 저장해둔다.
2. 트랜잭션이 커밋(commit)되는 시점에, 1차 캐시에 있는 현재 엔티티와 이전에 만들어둔 스냅샷을 비교한다.
3. 만약 두 상태가 다르다면, JPA가 자동으로 UPDATE SQL을 생성하여 DB로 전송한다.

4. 쓰기 지연(Write Behind)

em.persist() 가 호출될 때 바로 DB에 INSERT SQL이 전송되지 않는다.

영속성 컨텍스트는 실행해야 할 쿼리들을 쓰기 지연 SQL 저장소에 모아두고, 트랜잭션 커밋 시점이 되어서야

모아두었던 SQL 쿼리들을 한꺼번에 DB로 전송한다. 이를 통해 불필요한 DB 접근 횟수를 줄일 수 있으며,

관련 설정을 추가하면 여러 SQL을 하나의 묶음으로 만들어 보내는 JDBC BATCH 기능을 활용한 성능 최적화가 가능하다. 변경 감지(Dirty Checking)에 의해 생성된 UPDATE 쿼리나, em.remove() 에 의해 생성된 DELETE 쿼리 역시 쓰기 지연 SQL 저장소에 저장되었다가 함께 처리된다.

5. 지연 로딩(Lazy Loading)

객체 그래프를 탐색할 때 성능을 최적화하기 위한 기능이다.

예를 들어 Member 엔티티가 Team 엔티티와 연관 관계를 맺고 있을 때, Member를 조회하는 시점에는 당장 필요 없는 Team 엔티티까지 함께 조회하는 것은 비효율적일 있는데, 지연 로딩을 통해 연관된 엔티티를 실제 사용하는 시점까지 DB 조회를 미룰 수 있다. 아래 박스를 통해 동작 과정을 파악하자.

1. Member 엔티티를 조회하면, Team 필드에는 실제 Team 객체 대신 Hibernate가 생성한 프록시(Proxy) 객체가 채워진다. 프록시는 실제 DB 조회가 일어나기 전까지는 초기화되지 않고, 필요할 때 쿼리를 실행하여 진짜 엔티티로 교체된다.
2. 이후 코드에서 member.getTeam().getName()처럼 Team 객체를 실제로 사용하는 시점에, JPA가 Team을 조회하는 SQL을 DB로 전송하여 진짜 객체로 바꿔치기한다.

이를 통해 불필요한 쿼리를 방지하고 애플리케이션의 전반적인 성능을 향상시킬 수 있다.

참고한 자료 (References)

[웹 문서 및 블로그]
Java 공식문서 (EntityManager Interface)

https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManager.html

Understanding EntityManager Sessions and First-Level Cache in Spring Data JPA (Ayoub seddiki)

https://medium.com/@ayoubseddiki132/understanding-entitymanager-sessions-and-first-level-cache-in-spring-data-jpa-2cf87b8c2df7

Hibernate Caching Explained: First Level vs Second Level Cache (Gaddam.Naveen)

https://medium.com/@gaddamnaveen192/hibernate-caching-explained-first-level-vs-second-level-cache-c1392a9a9e37

[인프런 강의]

김영한) 자바 ORM 표준 JPA 프로그래밍 - 기본편

https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

[유튜브]

Spring boot : JPA (Part-3) | First Level Caching in JPA (Concept && Coding - by Shrayansh)

https://www.youtube.com/watch?v=PyAjGgjBN4c

[후기] 카카오테크 부트캠프 풀스택 지원&면접 합격후기

dragonwaterr — Mon, 4 Aug 2025 21:04:53 +0900

코테 문제 / 면접 질문에 대해서는 직접적으로 언급하기 어려운 점 양해해주세요.

큰 거 왔냐 ... ?

출처) 카부캠 풀스택 과정 홈페이지 : https://kakaotechbootcamp.com/fullstack.html

0. 지원한 계기

카카오테크 부트캠프(카부캠) 3기 지원이 열렸다.

3기에는 풀스택 / AI 실무개발 / 클라우드 네이티브 이렇게 총 3가지 과정이 진행된다.

일단 AI 실무개발 쪽은 기술스택과 희망진로가 아니었어서 PASS..

풀스택과 클라우드 네이티브 중에 고민하면 되는 부분이었는데, 얼마 전에 작성한 학기 프로젝트 회고에서

풀스택 개발지식의 필요성을 크게 느낀터라 길게 고민하지 않고 풀스택 과정을 지원하기로 했다.

그것 말고도 팀프로젝트 경험이 너무 부족한 점과, 우수한 동료들과 프로젝트를 진행하면서

많이 배우고 싶은 마음이 컸기 때문에의 이유로 지원하게 되었다. (회고 내용은 아래 글을 참고해주세요.)

[회고] 쉽지않았던 4-1 학기를 마치며 (feat. 지옥의 첫 팀프로젝트)

컴퓨터공학 전공을 선택하고 처음으로 팀프로젝트를 경험했다.지난 학기에도 팀프로젝트에 참여하긴 했었으나, 여러가지 이유로 인해 찐하게 팀프로젝트를 경험하지는 못했다는 개인적인 느

dragonwaterr.tistory.com

1. 지원 및 전형과정

지난 기수까지는 지원과정이 1차(서류) - 2차(코테) - 3차(면접) 으로 구성되었었는데

이번 기수부터는 1차(서류 + 코테) - 2차(면접) 로 1차 전형에 서류와 코딩테스트가 하나로 묶였다.

지원서는 내 나름의 경험과 생각을 담아서 열심히 작성했고, 며칠 뒤 코테를 봤다.

그리고, 코테를 ... 조졌다 ...

코테 난이도 자체는 어려웠다고 생각하지 않는다.

그냥 프로젝트 바쁘다는 핑계로 학기 동안은 PS 안하던 내 잘못이다..

2025 solved 스트릭 ... 코테 잘봤을리가 없겠죠? ^^

사실 내가 지원서에서 보여줄 수 있었던 부분들이, 다른 지원자들에 비해 크게 경쟁력있다고는 생각하지 않았다.

그렇기 때문에 코테가 끝난 시점부터는 당연히 떨어졌겠구나 생각했었는데 ...

대 카 오

예...?

감사하게도 면접을 불러주셨다.

아마도 1차 전형 합격의 제 1기준이 '실력'은 아닌듯하다. (감사합니다.)

1차에서 걸러지는것 보다는 2차에서 걸러지는게 낫지 않겠는가..

이븐하게 익은 개발자가 되게 해주세요

이제 면접을 준비해야했다.

나의 전공과 관련된 부트캠프, 취업 면접 경험이 전무해서 어떻게 준비해야할지 너무 막막했다.

이미 취업한 친구들에게 면접 질문 리스트를 마냥 물어보기에는, 부트캠프 면접이 취업 면접과는 성격이 다른 것 같아서 똑같이 따라서 준비할 수도 없는 노릇이었다.

대신 내가 지원서에 작성한 내용들에 대해서는 다 커버해보자! 라는 마음으로 준비했다.

아래 사진처럼 노션에서 만들어진 문답 템플릿을 받아와 조금 수정해서 사용했는데, 상당히 유용해서 앞으로도 종종 사용할듯하다.

위 질문들은 작성자 본인이 만들어낸 예상 질문일 뿐, 절대로 실제 면접 질문과 동일하지 않습니다.

면접 후기를 말하자면, 1시간 정도의 시간으로 다대다 화상면접으로 진행되었다.

다른 지원자들의 답변 내용을 듣고 있자니 세상엔 고수들이 참 많다는 생각이 여러번 들었다.

다른 지원자들을 향한 질문과 답변을 잘 듣다가 내 차례가 되면 질문을 듣고 답변하면 된다.

질문이 한 바퀴를 돌 동안, 내 차례를 한 번 건너뛰셔서 몹시 당황했는데

생각이 많아지려던 찰나에 금방 질문을 주셔서 다시 정신을 차리고 답변할 수 있었다.

기술 질문과 지원서 기반 질문을 모두 받았고, 지원서 내용 기반 질문에는 역시 나의 생각을 침착하게 말했던 것 같다.

다만 기술 질문은 내 스스로 학습이 덜되었다는 것을 알기에 약간 자신감이 떨어졌지만

아는 부분은 대답했고 모르는 내용은 솔직하게 모른다고 답했다.

면접이 끝나고 당연히 아쉬움이 많이 남지만, 첫 면접 경험으로는 더할 나위 없는 경험이라는 생각도 든다.

아마 이 글을 읽을 분들은 거의 다 4기에 지원하는 분들일텐데,

합격까지는 아직 못해봐서 모르겠고 면접까지는 잘 준비하시면 누구나 갈 수 있다는 생각이 든다.

2. 결과

대 카 오 갓 카 오

기대를 하나도 안했다면 거짓말이지만 면접 때 잘하는 분들이 많아보여서

떨어져도 그러려니 했을 듯 하다. 하지만 정말 감사하게도 합격을 했다.

본 과정을 무사히 수료하게 된다면 수료후기도 작성해보도록 하겠다.

[Java] 자바에서 생성자를 호출할 때 생기는 일

dragonwaterr — Sat, 26 Jul 2025 20:25:47 +0900

잘못된 정보를 발견하셨다면 지적과 수정요청 언제나 환영입니다 감사합니다 ! ! !

문득 우리가 항상 사용하고 있는 new 연산자를 통해 생성자를 호출했을때

선언한 참조변수와 생성된 인스턴스가 어디에 저장되고 어떤식으로 만들어지는지 궁금했다.

약간 의식의 흐름 느낌이긴 하지만, 궁금해서 알아본 김에 글로 정리해보고자 한다.

0. 이 과정에 관여되는 메모리 영역들

JVM 은 프로그램을 실행하기 위해 메모리를 여러 영역으로 나누어 사용하는데,

new 연산자를 통한 생성자의 실행 과정에 관여되는 메모리 영역들 중심으로 알아보자

- 스택(Stack) 영역

스택 영역에는 메소드의 호출 정보, 지역 변수, 기본형 변수가 저장된다.

각 스레드마다 별도로 스택이 생성되고, 각 스택마다 메소드가 호출되면 스택 프레임(Stack Frame) 이 쌓이게 되며, 이는 메소드가 종료되면 사라진다. 구조는 스택이기에 LIFO(Last-In, First-Out) 구조이다.

- 힙(Heap) 영역

new 키워드를 통해 생성된 인스턴스와 배열 등이 저장되는 공간이다.

모든 스레드가 이 영역을 공유하며, 가비지 컬렉터(Garbage Collector) 에 의해 관리되는 영역이기도 하다.

- Metaspace 영역

Java - Metaspace vs PermGen space (https://www.javainuse.com/java/metaspace)

이 부분이 특히 생소했는데, 주의깊게 볼만한 점은

Java 7 까지 Permanent Generation (PermGen) 이라는 영역이 있었지만

Java 8 이후로 Metaspace 영역이 도입되어 사용되었는데, 여기에는 클래스에 대한 정보들(이름, 부모 클래스 이름, 필드 정보, 메소드 바이트코드, 생성자 바이트코드 등)과 static 변수, 상수 등이 저장된다.

모든 스레드가 공유하는 특징이 있고, 프로그램의 시작 시 생성되어 종료 시까지 유지된다.

위 사진과 아래 비교정리를 통해 PermGen과 Metaspace의 차이점에 대해 알아보고 넘어가자.

PermGen 과 Metaspace 의 차이점

PermGen 과 Metaspace 의 가장 큰 차이점은, 바로 해당 영역의 관리 주체다.
Java 7 까지 사용되던 PermGen은 JVM이 관리하였고, Java 8 이후 이를 대체한 Metaspace 는 운영체제(OS)가 관리한다.
PermGen 은 JVM 이 관리하기 위해 크기가 고정되었기에, 클래스 로딩이 많아지면 OutOfMemory 에러가 많이 발생하고, Full GC 대상이 아니라서 GC 빈도가 낮아 메모리 누수가 발생할 수 있다고. 이 문제를 해결하기 위해 Metaspace는 네이티브 메모리 영역에 할당되어서 크기가 동적으로 조정되고, Metaspace에 저장된 클래스 메타데이터는 GC 의 대상이 되며, 클래스로더가 종료되면 Metaspace 의 메모리가 해제되는 등 유연한 메모리 관리가 가능한 점에서 PermGen 에서 발생했던 문제를 해결할 수 있다.

여기서 다루지 못한 여러 개념들은 이후 JVM 과 GC 관련 포스팅을 따로 준비할 듯 하다..!

1. 생성자를 호출했을 때 생기는 일

이제 어떤 영역들이 존재하는지 알아봤으니, 생성자의 호출과 실행과정을 통해서

여러 변수들이 어떤 메모리 공간에 저장되고, 어떤 정보를 담고 있는지에 대해 알아보자.

아래와 같은 클래스가 있다.

예시 클래스

이제 아래와 같이 new 연산자를 통해 생성자 호출 코드를 실행한다.

생성자 호출

그렇다면 다음과 같은 타임라인으로 진행된다.

T0: 실행 전 상태

T1: 클래스 로딩

T2: 힙 메모리 할당 및 기본값 초기화

T3: 명시적 초기화

T4: 생성자 실행 시작

T5: 생성자 코드 실행

T6: 생성자 완료 및 참조 할당

객체 생성 완료

이제 타임라인에 따라가며 Stack, Heap, Metaspace 영역들이 어떻게 변하는지 살펴보자.

T0: 실행 전 상태

코드 실행 직전, JVM은 main 메소드를 위한 스택 프레임을 스택 영역에 생성한다.

이 시점에는 아직 객체가 생성되지 않았으므로 힙 영역은 비어있는 상태이다.

메타스페이스 영역에는 프로그램 실행에 필수적인 JDK 핵심 클래스들(java.lang.Object, java.lang.String) 이 JVM 시작 시점에 미리 로드되어 있다.

T1: 클래스 로딩

JVM이 'new MyClass()' 구문을 만나면, 메타스페이스에서 MyClass 의 클래스 메타데이터를 탐색한다.

만약 로드되어 있지 않은 클래스라면, 클래스 로더가 해당 .class 파일을 읽어 클래스 구조, 필드 정보, 메소드 바이트코드 등의 정보를 메타스페이스에 적재한다.

그리고 static 변수 type 도 초기화된다.

static 변수 자체는 클래스 메타데이터의 일부로서 메타스페이스에 위치하고, 이 변수가 참조하는 진짜 데이터인 "MyType" 문자열 리터럴 객체는 힙 내부의 String Constant Pool (SCP) 에 생성된다.

String Constant Pool (SCP) ?
자바에서는 문자열 리터럴 객체에 대한 저장공간을 힙 영역 내부에 마련했는데, 바로 String Constant Pool 이다.
만약 String 을 'new String' 키워드로 생성했다면 그 문자열은 SCP 에 들어가지 않지만, 큰 따옴표(" ") 로 초기화한 String 은 따옴표의 내용을 SCP 에 저장하고, 오로지 내용을 기준으로 저장하기 때문에, 똑같은 내용의 String 타입 변수 두 개를 따옴표로 초기화 했다면 두 변수는 SCP에 저장된 동일한 문자열 리터럴 객체를 참조하게 된다. 이러한 전략을 통해 메모리 낭비를 줄일 수 있다.

T2: 힙 메모리 할당 및 기본값 초기화 & T3: 명시적 초기화

T2: 힙 메모리 할당 및 기본값 초기화

T3: 명시적 초기화

클래스 로딩이 완료되면, JVM은 new 키워드를 통해 힙 영역에 MyClass 인스턴스를 위한 공간을 할당한다.

할당 직후에 이 공간의 모든 인스턴스는 기본값으로 초기화된다. (null, 0)

이어지는 명시적 초기화 과정에서, name 는 SCP에 존재하는 "기본값" 문자열 객체의 참조를 갖게 된다.

T4: 생성자 실행 시작

드디어 인스턴스 초기화의 마지막 단계인 생성자가 호출된다.

이제 스택 영역에는 'MyClass("홍길동")' 을 실행하기 위해 새로운 스택 프레임이 push 된다.

이 스택 프레임 내부에는 힙 영역에 생성된 인스턴스의 참조인 this 와 인자로 전달된 "홍길동" 문자열의 참조가 지역 변수로 저장된다.

T5: 생성자 코드 실행

이젠 생성자 내부의 코드를 실행할 차례다.

this.name = name; 구문에 의해 인스턴스 변수 name의 참조가 인자로 받은 "홍길동" 문자열 객체로 변경되고,

this.age = age; 구문은 age 값을 25로 변경한다. 이로써 힙에 생성된 인스턴스는 모든 초기화 과정을 마쳤다.

T6: 생성자 완료 및 참조 할당

생성자의 모든 코드가 실행을 마쳤기 때문에, 스택 영역 최상단에 있던 생성자 스택 프레임은 제거(pop) 된다.

그 후, 드디어 new 연산의 최종 결과물인 힙 영역의 객체 주소(참조)가 main 메소드의 스택 프레임에 있는 지역 변수인 obj 에 할당된다.

이 시점부터는 obj 변수를 통해 해당 인스턴스에 접근하고 메소드를 호출할 수 있게 된다.

[회고] 쉽지않았던 4-1 학기를 마치며 (feat. 지옥의 첫 팀프로젝트)

dragonwaterr — Thu, 24 Jul 2025 19:43:36 +0900

컴퓨터공학 전공을 선택하고 처음으로 팀프로젝트를 경험했다.

지난 학기에도 팀프로젝트에 참여하긴 했었으나, 여러가지 이유로 인해 찐하게 팀프로젝트를 경험하지는 못했다는 개인적인 느낌이 있다. 이번 학기에 진행한 종합설계 팀프로젝트 경험을 중심으로, 협업과 관련하여 느낀 부분들을 적어보고자 한다.

0. 배경

팀프로젝트를 진행하는 종합설계 과목은 마지막 학기의 졸업작품으로 이어지며, 졸작의 프로토타입을 만드는게 목표인 프로젝트 과목이다. 사실 프로토타입이라고 말은 했지만, 거의 완성품을 만들고 졸작때는 약간의 기능만 추가하면 통과가 되는 시스템이므로 이번 학기 프로젝트에 힘을 많이 줄 수 밖에없는 형태이다.

프로젝트 배경과 진행을 짧게 소개하자면,
프로젝트 주제 : 화장품 쇼핑몰
내용 : 기능 구성이 { 1) 관리자 2) 판매자 3) 소비자 } 로 나뉘는 권한에 따라 분류되는 형태

1년 정도 알고 지냈던 동기 한 명과 팀구성을 시작했고, 둘 다 이렇다 할 프로젝트 경험이 없었다. 5~6명 팀을 만들어야 했어서 에브리타임에 구인글을 게시해서 백엔드 1명을 구했고, 프론트 3명은 랜덤으로 배정을 받았다. 사실 2명만 받기를 원했는데, 그 부분은 내 권한이 아니라 어쩔 수 없었고, 한국인 팀원1, 외국인 팀원 2명이 배정되었다..

최종 팀구성

[백엔드 2] : 본인(팀장), 팀원1(에타로 구인)

[프론트엔드 4] : 동기, 팀원2,3,4 (임의 배정 받은 3인)

꽃길만 있을거란 기대는 당연히 안했지만, 초반 기획단계가 너무 재미있었어서 기대감이 고조된 상태였다. 팀원들과 전체회의를 통해 기능명세서를 작성하고, 엔티티, DB 설계까지 착착 진행되었는데, 문제는 개발 단계에 들어가면서 발생했다.

1. 모두가 같은 방향을 바라보는 것은 아니다.

내가 간과한 첫번째 요소다. 프로젝트 주제를 선정하고, 포트폴리오에 넣을 수 있는 프로젝트를 만들고자 생각한 나와 달리, 누군가는 그저 학점만 받기고 넘기면 되는 것이라 생각할 수 있었다. 이 때문에 팀원간의 개발속도 차이가 상당히 벌어졌다.

'팀원 수준에 맞는 업무 분배에 실패한거 아니야?' 라고 물을 수 있다. 진행 초반만 말하자면 사실이다. 하지만 이 문제는 몇 주 간의 관찰과 회의를 통해 합의된 업무 분배에도 불구하고 프로젝트 끝까지 지속되었다. 과제의 난이도를 낮췄음에도 계속해서 한 번도 기한을 못맞춘 팀원들이 있었다는 것이다. 프로젝트 말미에 알게된 사실인데, 프로젝트 개발에 할애한 시간이 일주일 중 토요일 하루 뿐인 팀원도 있었다. 프로젝트에 기한 내에 기능을 완성하기 위해 수업까지 출튀해가면서 진행했던 나로서는 .. 음... 충격적이긴 했다. 생산성을 높이기 위한 도구 사용을 추천했을뿐, 시간을 더 투입하라고는 차마 말하지 못했다. 언급했듯이, 모두가 같은 방향을 바라보는 건 아닐 수 있기 때문이다.

팀원간의 능력 차이는 어떤 팀을가도 발생할 수 밖에 없는 부분일것이다. 그리고 팀장은 각 팀원들의 능력에 맞는 업무를 분배하는 능력을 가져야한다. 하지만 그보다 훨씬 중요하고 근본적인게 있다면, 하나의 프로젝트를 함께하는 팀원들이 같은 방향을 바라보고 가야한다는 점이다. 이번 프로젝트에서 느낀 가장 중요한 부분이며, 이렇게 만드는게 팀장이 가져야할 중요한 능력이 아닌가 생각든다.

2. 우린 대화가 필요해.

멘토님을 한 분 배정받아서 2번의 멘토링을 받을 수 있었다.
우리팀의 경우에는 여러 검색포털과 커머스등 여러 빅테크에서 백엔드 개발자 커리어를 보내신 멘토님인데, 적은 횟수의 멘토링에도 불구하고 고작 몇시간 동안 정말 많은 인사이트를 얻을 수 있었던 부분에 지금도 감사하다.

한 번은 현업에서 마주치는 애자일의 진실에 대해 소개 해주셨는데, 여러 통계자료를 보여주며 실제로 애자일을 프로젝트에 도입했음에도 불구하고 초기에 잡은 목표 기간까지의 실제 완성도는 보통 60% 에 남짓한다고 한다. 그런데 이건 상당히 높은 수치라고 !!즉 현업에서도 기간을 못맞추는 상황은 비일비재 하다는 것인데, 그럼에도 이 정도의 완성도를 가능하게한 요소로 '매일매일 소통'을 꼽으셨다. 좀 더 자세하게는, 매일 아침 Slack 에서 업무채널에 Daliy Standup Bot 을 활용한 일종의 작은 데일리 스크럼을 진행하여 각자의 업무 진행상황과 그날의 목표 지점등을 공유한다. 그리고 오후에는 종일 책상 앞에서 개발에만 몰두하는게 아니라, 잠깐이라도 팀원들과 짧은 티타임을 가지신다고. 그런데 놀라운 부분은, 바로 이 짧은 시간에 1) 팀원들 마다의 현재 업무가 각 팀원에게 적합한 수준인지, 2) 현재 어느정도 진행되었고 3) 오늘 어느정도까지 진행될 수 있는지 등을 모두 파악할 수 있다고 한다.

우리 팀에게도 Slack 을 활용한 짧은 주기의 소통을 추천하셨다. 물론 프로젝트 후반부에 그 조언을 들은터라 실제 적용은 못해봤지만, 조금 귀찮더라도 초반부터 Daliy Standup Bot 과 같은 유용한 도구들을 활용했다면 프로젝트 진행과정이 크게 달라지지 않았을까 생각해본다. 우리는 매주 두 번의 회의를 진행했는데 월요일은 온라인으로, 금요일은 오프라인으로 진행했다.

지금 돌이켜보면 너무 팀원들에게 부담을 주고 싶지 않은 마음에 원하던 것보다 적은 횟수의 회의를 진행했었는데, 이는 장기적으로 절대 팀원들을 위한 선택이 아니었음을 깨달았다. 위에서 한 팀원이 일주일에 프로젝트에 대해 할애한 시간을 알게된게 프로젝트 말미였다고 말했었는데, 어찌보면 이걸 말미에 알았다는것부터 효과적인 소통이 부족했다는 것을 증명하는게 아닌가 싶다.

우리는 각자 하는일이 모두 다르고, 본인의 상황을 생각했을때 절대 한가하다고 생각하지 않는다. 때문에 누군가가 적극적으로 소통을 유도하지 않으면 프로젝트 진행에 대한 파악이 불가능하다.이는 어쩌면 미움받을 용기(?)가 필요하다. 그것 역시 훌륭한 팀장의 역할이라고 느꼈다.

3. 프로젝트와 학기를 마무리하며

제목이 '4-1학기를 마치며' 기 때문에 종합설계 프로젝트를 제외한 다른 부분을 짧게 언급하자면, 이론 과목들과 AI 팀프로젝트, IoT 팀프로젝트까지 총 3개의 팀프로젝트를 진행했다. 다행히 능력이 뛰어난 팀원들을 만나, 내가 할 일만 잘하면 순조롭게 진행되는 흐름이었고 발표까지 잘 마무리했다. 이론 과목들의 기말고사 점수는 ... ㅠㅠ (수업까지 째가며 프로젝트를 진행한 사람의 시험 성적은 말하지 않아도 ...)

결과적으로 종합설계 프로젝트는 잘 마무리되었다. 시연 발표때 교수님의 반응도 좋았고. 무엇보다 한 프로젝트의 진행과정을 처음부터 끝까지 느낄 수 있는 경험이 가장 유의미한 수확이었다. 비록 2가지 기능은 구현에 실패했고 우리가 봤을 때도 구조적으로 엉망인 부분이 많았지만 이는 여름방학과 2학기에 충분히 개선이 가능하며, 이후 추가할 기능들에 대한 기대감도 생기고 있다.

개인 커리어에 대한 생각으로는 풀스택 개발자가 되어야겠다. 는 생각을 많이하게된 프로젝트였다. 체계가 잘갖춰진 큰 조직에서는 내가 이런저런 업무를 모두 담당할일이 적겠지만, 언제나 그런 환경만 있지는 않을것이고, 그런 상황에 잘 대처하기 위해서는 내가 하나도 모르는 일에 투입될 가능성을 줄여야한다. 그럴 일이 적은 집단에 들어가는 옵션과, 내가 모두 어느정도 대처가능 하도록 공부하는 옵션 중에 두 번째를 선택했고, 앞으로 그 방향을 지향할 것 같다.

[후기] 네이버 부스트캠프 웹모바일 9기 베이직 과정 수료 후기

dragonwaterr — Thu, 11 Jul 2024 02:52:26 +0900

베이직 과정을 신청한 계기

누군가 나에게 이렇게 묻는다.
" 컴퓨터공학과? 어떤 개발할거야? "

그럼 나는 이렇게 대답한다.
" 몰라요 나는 아무것도 몰라요 ~ "

방학을 앞두고 뭔가 해야한다는 압박감이 들었다. 하지만 무엇부터 어떻게 공부해야할지 모르는 나에게 무언가가 보였다. "네이버 부스트캠프 웹모바일 9기 모집". 그렇다. 어릴적 주니어네이버 부터 현재는 네이버페이까지 ... 내 인생과 쭉 함께한 바로 그 기업 네이버였다. 부스트캠프라는 이름은 나에게 성장하고 싶은 욕구를 한층 끌어올리기 충분했고 웹모바일 과정을 곧바로 지원하게 되었다.

베이직 과정은 이번 9기에 신설된 과정이었다. 취지는 자기 주도적으로 미션을 수행해 나가면서 겪는 경험들을 바탕으로, 프로그래밍으로 문제를 해결하는 것이 무엇인지 알게하는 것이다. 한 번도 사용해본적 없는 자바스크립트 언어로 과정의 미션들을 해결해야한다는 점이 조금 두려웠지만, 짧은 기간인 만큼 스스로 강도 높은 학습을 하게 하는 좋은 경험이었다.

베이직에서 배운 것들

개인미션

개인미션을 통해 배운 부분들 중 가장 핵심은, 직면한 문제를 어떻게 해결할 것인가 설계하는 과정이었다. 미션은 문제를 어떻게 해석했고, 해결에 있어서 핵심적인 부분은 무엇이며 또 문제 해결에 사용되는 여러 데이터들을 어떤 데이터 구조를 통해 저장하고 처리할 것인가? 에 대해서 끊임없이 고민하게 하는 형식이었다. 정리하자면 문제 해석 -> 설계 -> 구현 -> 기록 하는 과정의 반복이었다. 가장 힘들었던 부분은 문제를 풀어내는 것이 아니라 기록하는 과정이었다. 전에는 문제를 해결하면 "와 풀었다 ~ 이제 끝!" 이었지만 베이직 과정은 그것을 허락하지 않았다. 내가 그 문제를 왜 그렇게 접근-설계-구현했는지 누가 봐도 알 수 있도록 정리하는 과정을 요구했고, 아쉬웠던 부분과 좋았던 부분들을 정리하며 셀프 피드백을 할 수 있을만한 창구까지 모두 준비 되어있었다. 생전 처음 해보는 이미 해결한 문제를 정리하고 돌아보는 일. 이 과정은 오늘 겪은 것들을 내일 마주하는 문제에서 곧장 활용하게 해주는 신기한 경험을 제공했다. 겨우 2주 동안 얼마나 배울 수 있을까 ? 라는 생각이 베이직을 통해 깨진 것 같다. 2주는 무언가를 배우기에 결코 짧지 않은 시간이다.

‍ ‍ 그룹미션

베이직 과정에서 가장 기대했던 부분이었다. 짧은 시간이지만 새로운 사람들과 하나의 지향점을 두고 나아간다는 경험은 소중했다. 지구에 똑같은 사람은 단 한 명도 없다고 했던가. 주어진 문제에 대해 해석하는 시각이 이렇게 다를 수가 없었다. 하지만 우리는 혼자 일할 것이 아니라면, 누군가와 시선을 한 곳으로 맞추는 법을 배워야 한다. 그것을 경험하기에는 충분한 시간이었다. 처음 그룹미션을 경험하고 배운 부분들이 다음 그룹미션에서 곧바로 드러났다. 미션 해석과 설계에 대한 방향을 잡는데에 걸리는 시간도 단축되었고, 사람들과 소통하는 방식에서도 개선이 있었다. 조금 아쉬운 부분이 있다면 미션 제한시간이 조금 타이트하지 않았나 하는 부분이다. 아무래도 제시된 문제를 해결하는 과정에서 해석과 설계까지는 어렵지 않게 할 수 시간이었지만 모든 팀이 구현까지 해내기에는 시간이 조금 부족했다는 의견이다.

수료 후 ...

2주간의 베이직 과정이 바쁘게 지나가고 수료 축하 메일이 도착했다.

축하 메일의 내용대로 베이직 과정에서 경험한 매일매일의 작은 성공들은 앞으로 내가 문제를 바라보고 해결하는 방식에 대해 변화시켜주었다. 앞으로 내가 어떤 개발을 하고 살지는 모르겠지만, 앞으로의 개발자 수명에서 가장 깊은 곳에 뿌리가 될만한 부분을 배우고 가는 느낌을 받는다. 베이직을 경험하고 내가 내릴 수 있는 지속 가능한 개발자의 정의는,문제에 대해 바르게 접근하기 위해 고민하고 그것을 해결하면서 배운 부분들로 또 새로운 문제를 해결해 나갈 수 있는 사람이다. 앞으로 나보다 뛰어난 사람들을 수도 없이 만나겠지만, 베이직을 경험하고 이제 중요한 건 어제의 나보다 성장한 오늘의 내가 되는것을 알았다.

로빈의 무기고

[Spring MVC] HandlerAdapter 의 구현체는 어떤것들이 있을까?

HandlerAdapter 인터페이스의 기본 역할

주요 구현체들

1. HttpRequestHandlerAdapter

2. SimpleControllerHandlerAdapter

3. RequestMappingHandlerAdapter

패키지 구조 차이

Ordered와 우선순위

정리

참고

[Spring MVC] HandlerAdapter 가 존재하는 이유는 뭘까?

HandlerMapping vs HandlerAdapter

그렇다면 왜 굳이 분리했을까?

만약 HandlerMapping이 단순히 컨트롤러를 찾는 것뿐만 아니라, 실행하는 방법까지 다 품고 있었다면 어땠을까?

HandlerAdapter가 가져오는 장점

추가로 알게된 부분

HandlerAdapter의 우선순위를 지정할 수 있다 : Ordered와 HandlerAdapter의 우선순위

마무리

[회고] 카테부 1~2 주차 회고입니다.. 근데 이제 반성을 곁들인

1. 해야되는 공부가 아니라 하고 싶은 공부만 하고 있었다.

2. 설명하지 못하면 제대로 이해한게 아니다.

3. 넌 꼭 블로그만 보고 공식문서를 안보더라.

4. 기술에 대한 의문을 가지지 않았다.

[SWEA] 나무 높이 (D2) 풀이 (Java)

[JPA] 영속성 컨텍스트에 대해 알아보자

0. 영속성 컨텍스트란 ?

1. 영속성 컨텍스트가 인식하는 엔티티의 상태 종류

2. 영속성 컨텍스트가 제공하는 기능

1. 1차 캐시

2. 동일성 보장

3. 변경 감지(Dirty Checking)

4. 쓰기 지연(Write Behind)

5. 지연 로딩(Lazy Loading)

참고한 자료 (References)

[후기] 카카오테크 부트캠프 풀스택 지원&면접 합격후기

큰 거 왔냐 ... ?

0. 지원한 계기

1. 지원 및 전형과정

2. 결과

[Java] 자바에서 생성자를 호출할 때 생기는 일

0. 이 과정에 관여되는 메모리 영역들

- 스택(Stack) 영역

- 힙(Heap) 영역

- Metaspace 영역

1. 생성자를 호출했을 때 생기는 일

T0: 실행 전 상태

T1: 클래스 로딩

T2: 힙 메모리 할당 및 기본값 초기화 & T3: 명시적 초기화

T4: 생성자 실행 시작

T5: 생성자 코드 실행

T6: 생성자 완료 및 참조 할당

[회고] 쉽지않았던 4-1 학기를 마치며 (feat. 지옥의 첫 팀프로젝트)

[후기] 네이버 부스트캠프 웹모바일 9기 베이직 과정 수료 후기

베이직 과정을 신청한 계기

베이직에서 배운 것들

개인미션

‍ ‍ 그룹미션

수료 후 ...

만약 HandlerMapping이 단순히 컨트롤러를 찾는 것뿐만 아니라,
실행하는 방법까지 다 품고 있었다면 어땠을까?