앞선 S3 Tables & Catalog Federation 글에서 관리형 Iceberg 레이크하우스가 s3tablescatalog 아래에 어떻게 중첩되는지, 그래서 ARN이 왜 깊어지는지를 정리했습니다. 이 federated 데이터에 한 겹 더 얹히는 권한 계층, AWS Lake Formation을 알아봅니다. Lake Formation이 ...

Series 4 1편에서 영속성 컨텍스트를, 2편에서 트랜잭션을 봤습니다. JPA(Java Persistence API, 현재 Jakarta Persistence) 를 사용할 때 자주 마주치는 성능 문제 중 하나가 N+1 selects입니다. 코드는 단순하지만 실행 SQL을 보면 예상보다 많은 SELECT가 나가는 상황입니다. N+1이 생기는 조건과 ...

JPA로 데이터를 다루다 보면 이상한 경험을 합니다. 엔티티의 필드를 바꾸기만 했는데 update() 같은 걸 부르지 않아도 DB에 반영됩니다. 같은 트랜잭션에서 같은 id를 두 번 조회하면 두 번째는 쿼리가 안 나갑니다. 이 “마법”의 정체가 영속성 컨텍스트(persistence context)입니다. 영속성 컨텍스트가 무엇이고(1차 캐시), 엔티티...

Series 4 1편에서 영속성 컨텍스트의 수명이 트랜잭션에 묶인다고 했습니다. 그 트랜잭션을 거는 도구가 @Transactional인데, 메서드에 한 줄 붙이면 트랜잭션이 시작되고 끝납니다. 그런데 정확히 어떻게 동작할까요? 언제 롤백되고, 트랜잭션 메서드가 또 다른 트랜잭션 메서드를 호출하면 어떻게 될까요? @Transactional의 동작(AOP...

매일 ./gradlew bootJar나 mvn package를 치고, 만들어진 app.jar를 java -jar로 실행합니다. 그런데 그 사이에 무슨 일이 일어날까요? 의존성에 버전을 안 적었는데 어떻게 빌드가 되고, 하나의 jar 안에 라이브러리가 전부 들어가는 건 어떻게 가능한 걸까요? Series 5(빌드/보안)의 첫 글에서는 빌드 도구가 하는 ...

지금까지 당연하게 넘긴 것들이 있습니다. 1편에서 내장 Tomcat이 알아서 떴고, 3편에서 DispatcherServlet이 알아서 등록됐으며, 2편에서 @Service/@Repository가 알아서 빈으로 스캔됐습니다. 이걸 누가 했는지는 한 번도 따지지 않았습니다. 답은 Spring Boot의 auto-configuration(자동설정) 입니다...

1편에서 “DispatcherServlet이 front controller로 모든 요청을 받아 분배한다”, “요청당 스레드 1개를 쓴다”고 선언만 했습니다. 이번 편에서는 그 안을 해부합니다. DispatcherServlet 내부가 어떻게 동작하는지, 그리고 “요청당 스레드 1개”가 정확히 무슨 의미이고 왜 그게 메모리/동시성의 갈림길인지를 다룹니다....

인프라를 다루다 보면 애플리케이션은 “컨테이너 안에서 도는 검은 상자”처럼 보일 때가 많습니다. GET /orders/42 요청 하나가 들어오면 그 안에서 무슨 일이 벌어지는지, 왜 요청이 몰리면 스레드와 메모리가 같이 올라가는지 설명하려면 결국 그 상자를 열어봐야 합니다. 먼저 요청 한 건이 Spring Boot 앱을 통과하는 경로를 계층별로 그려...

1편에서 요청이 Controller -> Service -> Repository를 거쳐 처리되고, 이들이 “전부 빈(Bean)으로 힙에 상주한다”고 했습니다. 그런데 빈이 정확히 뭐고, 왜 우리는 이 객체들을 직접 new로 만들지 않을까요? 이 글은 Spring의 가장 근본적인 질문 - “Spring은 대체 무슨 일을 해주는가”에 답합니다...

앞선 Amazon Athena & Glue Data Catalog 글에서 일반 Glue 테이블(S3 + Glue Catalog)을 기준으로 쿼리 흐름과 권한을 정리하고, 이어 Apache Iceberg 테이블 포맷 글에서 Iceberg 자체의 구조와 동작 원리를 살펴봤습니다. 그 Iceberg를 AWS가 관리형으로 감싼 Amazon S3 Tab...