코드 땜장이

스프링 부트 AutoConfiguration은 어떻게 필요한 빈만 자동 등록할까 빠른 답 AutoConfiguration의 출발점은 @SpringBootApplication 내부의 @EnableAutoConfiguration이다. AutoConfigurationImportSelector가 후보 설정을 수집하고 조건에 맞는 클래스만 남긴다. 원하지 않는 자동 설정은 exclude, excludeName, spring.autoconfigure.exclude로 제거할 수 있다. 빈 등록 결과가 예상과 다르면 --debug와 Condition Evaluation Report부터 확인하는 것이 가장 빠르다. 목차 흐름으로 보기 왜 AutoConfiguration이 필요한가: 반복 설정을 줄이는 기본 전략 @SpringBootApplication 에서 시작되는 자동 설정 진입점 AutoConfigurationImportSelector 는 어떤 순서로 후보를 고를까 조건부 자동 설정은 어떻게 읽어야 할까 실전 예시: spring-boot-starter-web 을 추가하면 무엇이 일어날까 자동 설정을 끄거나 바꾸는 실전 설정 방법 디버깅: 왜 어떤 빈은 등록되고 어떤 빈은 빠질까 실무에서 자주 하는 오해와 주의점 정리 흐름으로 보기 핵심은 단순합니다. 스프링 부트가 "마법처럼 아무 빈이나 등록하는 것"이 아니라, 자동 설정 후보를 먼저 모으고, 애플리케이션 상태를 보고, 조건을 통과한 설정만 적용하는 구조입니다. 그래서 AutoConfiguration은 감으로 이해하기보다 "후보 수집 -> 조건 평가 -> 빈 등록"의 흐름으로 보는 편이 훨씬 정확합니다. 왜 AutoConfiguration이 필요한가: 반복 설정을 줄이는 기본 전략 순수 스프링만 사용할 때는 웹 서버, JSON 직렬화기, 메시지 컨버터, 데이터소스, 트랜잭션 매니저 같은 인프라 빈을 직접 등록하는 경우가 많았습니다. 문제는 이런 설정이 프로...

톰캣이 하는 일: 서블릿 컨테이너부터 요청 처리 흐름까지 이해하기 빠른 답 톰캣은 HTTP 요청을 받아 서블릿 코드로 연결하고 응답까지 돌려주는 자바 웹 실행 환경이다. 핵심 흐름은 요청 수신, URL 매핑, 필터 실행, 서블릿 호출, 응답 반환 순서로 이해하면 된다. 서블릿은 매 요청마다 새로 만들어지는 것이 아니라 컨테이너가 생명주기를 관리한다. 실무에서는 포트 설정, 스레드 풀, 배포 경로, 로그 확인 포인트를 함께 알아야 운영이 쉬워진다. 목차 흐름으로 보기 톰캣은 무엇이고 왜 자바 웹 개발에서 자주 등장할까 브라우저 요청이 톰캣 안에서 처리되는 전체 흐름 서블릿 생명주기와 톰캣이 객체를 관리하는 방식 바인딩, 검증, 직렬화는 어디서 일어날까 설정 포인트로 보는 톰캣 운영 감각 예외와 디버깅에서 먼저 볼 단서 톰캣을 이해하면 스프링도 더 잘 보인다 흐름으로 보기 톰캣을 이해할 때는 이 다섯 단계를 먼저 잡는 것이 가장 좋습니다. 브라우저나 API 클라이언트가 보낸 요청은 톰캣의 포트로 들어오고, 톰캣은 어떤 애플리케이션과 어떤 서블릿이 이 요청을 처리해야 하는지 찾습니다. 그다음 필터 같은 공통 처리 단계를 거쳐 실제 자바 코드가 실행되고, 최종 결과가 다시 HTTP 응답으로 나갑니다. 스프링 부트를 쓰더라도 이 흐름이 사라지는 것은 아닙니다. 눈앞에 보이는 코드가 @RestController 로 바뀔 뿐, 아래쪽에서는 여전히 톰캣이 요청을 받고 서블릿 체인으로 넘겨주는 구조가 유지됩니다. 톰캣은 무엇이고 왜 자바 웹 개발에서 자주 등장할까 톰캣은 흔히 WAS라고 부르지만, 실제로는 HTTP 서버 기능과 서블릿 컨테이너를 함께 제공하는 자바 웹 실행 환경이라고 보는 편이 더 정확합니다. 핵심 역할은 단순합니다. HTTP 요청을 읽고, 그 요청을 처리할 자바 웹 컴포넌트를 찾아 실행한 뒤, 결과를 다시 HTTP 응답으로 포장해 돌려보냅니다. 정적 파일만 내려주는 서버와 비교하면 차이가 분명해집니다. /logo.png 같은 요청은...

브라우저 주소창에 URL을 입력하면 화면이 뜨기까지: DNS부터 렌더링까지 빠른 답 주소 입력 뒤 바로 화면이 뜨는 것이 아니라 DNS 조회, 연결 수립, TLS 협상, HTTP 요청, 렌더링이 순서대로 진행됩니다. 첫 화면 속도는 서버 응답 시간만이 아니라 CSS 다운로드, JavaScript 실행, 레이아웃·페인트 비용에도 크게 영향을 받습니다. HTTPS 사이트는 요청 전에 인증서 검증과 키 협상이 들어가므로 TLS 단계가 별도 병목이 될 수 있습니다. 병목은 Chrome DevTools의 Network와 Performance 탭으로 네트워크 지연과 렌더링 비용을 나눠 확인하는 것이 가장 빠릅니다. 목차 흐름으로 보기 왜 이 과정을 같이 봐야 하나 연결이 열리기 전: DNS, TCP, TLS, HTTP 응답이 화면이 되는 핵심: DOM, CSSOM, 렌더 트리 레이아웃, 페인트, 컴포지팅은 각각 무엇을 하나 첫 화면을 늦추는 흔한 비용 DevTools로 병목을 어떻게 찾나 구성과 설정으로 줄일 수 있는 비용 면접과 실무에서 자주 틀리는 설명 흐름으로 보기 1 DNS 조회 ↓ 2 TCP 연결 ↓ 3 TLS 협상 ↓ 4 HTTP 요청/응답 ↓ 5 DOM·CSSOM 생성 ↓ 6 레이아웃·페인트·컴포지팅 이 여섯 단계는 웹 페이지 로딩의 가장 큰 뼈대입니다. 앞쪽은 리소스를 받아오는 네트워크 흐름이고, 뒤쪽은 받은 데이터를 실제 화면으로 바꾸는 브라우저 렌더링 흐름입니다. 페이지가 느릴 때 원인을 정확히 찾으려면 이 둘을 섞지 말고 끊어서 봐야 합니다. 왜 이 과정을 같이 봐야 하나 브라우저 주소창에 https://www.google.com 을 입력하는 행동은 단순히 “서버에 요청한다”로 끝나지 않습니다. 브라우저는 먼저 어디로 연결할지 찾아야 하고, 안전한 연결을 만들어야 하며, HTML과 정적 자원을 받아온 뒤 그것을 다시 화면용 구조로 바꿔야 합니다. 사용자가 보는 첫 화면은 서버 응답 그 자체가 아니라, 브라우저가 수행한 렌더링 파이...

브라우저는 HTML을 어떻게 화면으로 바꿀까: 렌더링 파이프라인과 성능 포인트 빠른 답 브라우저는 DOM -> CSSOM -> 렌더 트리 -> 레이아웃 -> 페인트 -> 컴포지팅 순서로 화면을 만든다. 크기와 위치를 바꾸면 레이아웃 비용이 커지고, 색상·그림자·배경 변경은 주로 페인트 비용을 만든다. transform과 opacity 중심 애니메이션은 컴포지팅 단계에서 처리돼 더 부드럽게 동작하는 경우가 많다. 성능 문제는 감으로 추측하지 말고 Chrome DevTools의 Performance, Layers, Paint flashing으로 먼저 확인한다. 목차 데이터 흐름과 상태 소유권부터 봐야 하는 이유 브라우저 렌더링 파이프라인을 왜 알아야 할까: 화면은 느린데 API는 빠른 이유 HTML이 픽셀이 되기까지: DOM, CSSOM, 렌더 트리, 레이아웃, 페인트, 컴포지팅 어떤 변경이 어디까지 전파될까: 스타일 계산, 레이아웃, 페인트, 컴포지팅 프런트엔드에서 자주 만드는 안티패턴 성능에 유리한 렌더링 구성 예시: CSS 속성 선택과 숨김 전략 렌더링 타이밍: React 리렌더링과 브라우저 페인트는 다르다 Chrome DevTools로 병목 확인하기 자주 하는 오해와 실무 체크리스트 데이터 흐름과 상태 소유권부터 봐야 하는 이유 브라우저 렌더링 파이프라인은 브라우저가 화면을 그리는 방법을 설명합니다. 하지만 실무에서 성능 문제가 시작되는 지점은 대개 그보다 앞입니다. 어떤 상태가 바뀌었고, 그 상태 변화가 어떤 컴포넌트 재계산과 DOM 변경으로 이어졌는지가 먼저입니다. 브라우저는 갑자기 화면을 느리게 만드는 주체라기보다, 애플리케이션이 만든 결과를 계산하고 그리는 쪽에 가깝습니다. 그래서 프런트엔드 성능은 브라우저 지식만으로는 잘 풀리지 않습니다. 상태를 누가 소유하는지, 변경이 어떤 방향으로 흐르는지, 작은 상호작용이 왜 큰 트리의 리렌더링으로 번지는지를 같이 봐야 합니다. 상태는 한 곳이 소유하고, 아래로 전...

리액트 성능 최적화, 무작정 memo 쓰기 전에 먼저 봐야 할 기준들 빠른 답 느린 원인을 확인하기 전에는 memo부터 늘리지 말고 React DevTools Profiler로 병목을 먼저 찾습니다. 상태를 너무 상위에 두면 하위 전체가 자주 리렌더링되므로, 상태 소유권을 필요한 범위로 최대한 좁힙니다. useMemo와 useCallback은 비용이 큰 계산이나 참조 안정성이 실제로 필요한 경우에만 적용합니다. 초기 로딩이 느리다면 라우트 단위 코드 스플리팅부터 검토하는 편이 체감 성능에 더 직접적입니다. 목차 리액트 앱은 왜 느려질까 성능 최적화의 첫 단계: 상태 소유권 좁히기 React.memo, useMemo, useCallback은 무엇이 다를까 초기 로딩이 느리다면 코드 스플리팅부터 보기 Profiler로 먼저 확인할 것 흔한 안티패턴과 디버깅 포인트 무엇부터 적용하면 좋을까 리액트 앱은 왜 느려질까 리액트 앱이 느려질 때 많은 분이 먼저 memo , useMemo , useCallback 부터 떠올립니다. 하지만 실제 병목은 대개 훅이 부족해서가 아니라, 상태가 너무 위에 있거나, 작은 변화가 너무 넓은 화면에 전파되거나, 리스트 렌더링과 정렬·필터링 같은 계산이 반복되기 때문에 생깁니다. 여기서 먼저 구분할 것이 있습니다. 리액트에서 리렌더링은 정상 동작입니다. 상태나 props 가 바뀌면 다시 렌더링하면서 다음 UI를 계산하는 것이 리액트의 기본 모델입니다. 문제는 그 렌더링 범위가 불필요하게 넓거나, 계산 자체가 무겁거나, 실제 DOM 반영 비용까지 커질 때입니다. 즉, 리렌더링이 있다 와 성능 문제가 있다 는 같은 말이 아닙니다. 성능 최적화의 목표는 리렌더링을 무조건 없애는 것이 아니라, 사용자 행동에 비해 과도한 계산과 전파를 줄이는 것입니다. 성능 최적화의 첫 단계: 상태 소유권 좁히기 프론트엔드에서 가장 먼저 봐야 할 것은 데이터 흐름입니다. 리액트는 부모에서 자식으로 내려가는 단방향 흐름을 가지므로, 어떤 상태...