코드 땜장이

자바 Checked Exception vs Unchecked Exception: 언제 복구하고 언제 코드부터 고칠까 빠른 답 Checked Exception 은 호출자가 재시도, 대체 경로, 사용자 안내 같은 대응을 선택할 수 있을 때 API 계약으로 드러내기 좋습니다. Unchecked Exception 은 잘못된 값, 잘못된 호출 순서, 깨진 상태처럼 코드 쪽 수정이 필요한 문제를 표현하는 경우가 많습니다. 둘 다 실제로는 실행 중에 발생합니다. 차이는 예외가 아니라 컴파일러가 처리 여부를 강제하느냐에 있습니다. Error 는 일반 애플리케이션 로직에서 복구 대상으로 보기보다, JVM이나 프로세스 수준의 심각한 문제로 보는 편이 가깝습니다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 둘 다 Exception인데 처리 방식은 다를까 Error와 Exception의 차이 실전 코드와 출력 예시로 보기 언제 무엇을 선택할까 커스텀 예외는 어디에 둘까 자주 틀리는 지점 한눈에 비교 검사 시점 Checked Exception 은 컴파일 시점에 처리 여부를 검사하고, Unchecked Exception 은 컴파일러가 강제하지 않습니다. 타입 계층 checked는 보통 Exception 하위 타입 중 RuntimeException 이 아닌 예외이고, unchecked는 RuntimeException 과 그 하위 타입입니다. 의미 checked는 외부 조건 때문에 작업이 실패할 수 있음을 드러내고, unchecked는 값 오류나 상태 불일치처럼 코드 전제가 깨졌음을 드러내는 경우가 많습니다. 호출자 책임 checked는 try-catch 또는 throws 로 책임을 명시해야 하고, unchecked는 필요할 때만 잡으면 됩니다. 관찰 가능한 결과 checked를 처리하지 않으면 컴파일 오류가 보이고, unchecked는 컴파일은 되지만 실행 중 스택 트레이스로 드러납니다. 복구 방향 checked는 재시도, 기본값 사용, 다른 자원 선택으로 이어지기 쉽...

JPA N+1 문제, 왜 생기고 어떻게 줄일까: fetch join과 EntityGraph 선택 기준까지 빠른 답 EAGER 는 N+1의 해결책이 아니라 연관 조회 시점을 앞당기는 설정에 가깝다. JPQL이나 Spring Data JPA 조회 메서드가 조인을 자동 보장하지는 않는다. LAZY 는 문제를 없애는 방식이 아니라 미루는 방식이다. 목록을 읽은 뒤 연관 필드를 순회하는 순간 N+1이 다시 나타날 수 있다. 목록 조회 최적화는 fetch join , @EntityGraph , 배치 로딩( @BatchSize , hibernate.default_batch_fetch_size )을 조회 형태와 페이징 요구사항에 맞춰 나눠 쓰는 편이 낫다. 최적화 여부는 SQL 로그, 바인드 값, 쿼리 수, 실행 계획까지 같이 봐야 판단할 수 있다. 목차 시간 흐름으로 이해하기 흐름으로 보기 패치가 아니라 fetch 전략이다 N+1이 생기는 구조를 쿼리 관점에서 보기 LAZY와 EAGER는 왜 둘 다 N+1에서 안전하지 않은가 findAll 호출 뒤에 실제 SQL이 어떻게 늘어나는가 실행 계획과 인덱스로 보면 왜 더 느려지는가 fetch join, EntityGraph, 배치 로딩은 어떻게 나눠 쓰나 설정과 검증 예시 자주 부딪히는 함정과 현재 기준 버전 차이 시간 흐름으로 이해하기 T1 목록 조회 시작 → T2 루트 쿼리 실행 → T3 연관 로딩 대기 → T4 연관 필드 접근 → T5 추가 SQL 반복 Post 목록 API는 대개 루트 엔티티만 읽는 SQL로 시작한다. 문제는 그다음 시점이다. DTO 매핑이나 JSON 직렬화에서 post.getAuthor().getName() 같은 코드가 실행되면, 그 순간 연관 엔티티 초기화가 시작되고 결과 건수만큼 비슷한 SQL이 반복될 수 있다. 흐름으로 보기 흐름 다이어그램 N+1은 "첫 쿼리 하나가 느린 문제"라기보다 "첫 쿼리 뒤에 반복 SQL이 따라붙는 구조"에 가...

SSR은 무엇이고 언제 써야 할까: CSR, 하이드레이션, Next.js까지 현재 기준으로 정리 빠른 답 SSR은 첫 화면 HTML을 서버에서 먼저 만들어 보내는 방식이다. 다만 버튼과 입력이 실제로 반응하는 시점은 하이드레이션 이후일 수 있다. 브라우저는 SSR 페이지도 DOM, CSSOM, 렌더 트리, 레이아웃, 페인트, 컴포지팅을 그대로 거친다. SSR은 브라우저 렌더링을 없애는 기술이 아니라 시작 시점을 바꾸는 쪽에 가깝다. SEO와 초기 콘텐츠 노출이 중요하면 SSR이 도움이 되지만, 요청마다 HTML을 만들면 TTFB와 서버 비용이 늘 수 있다. 2026-04-07 기준 Next.js는 getServerSideProps 만으로 SSR을 설명하기 어렵다. App Router의 서버 컴포넌트, 스트리밍, 캐시 모델까지 함께 봐야 현재 동작과 가깝다. 목차 시간 흐름으로 이해하기 흐름으로 보기 SSR이 다시 중요해진 이유와 흔한 오해 SSR, CSR, SSG를 먼저 구분해 두기 요청부터 화면 반응까지: HTML, DOM, CSSOM, 하이드레이션 브라우저 렌더링 관점에서 보면 왜 SSR도 느릴 수 있을까 Next.js 현재 기준으로 다시 보기 스트리밍과 캐시를 같이 봐야 하는 이유 무엇을 측정해야 SSR의 효과가 보일까 언제 SSR을 선택하는 편이 잘 맞을까 현재 기준에서 바꿔 읽어야 할 오래된 설명 공식 문서와 참고 링크 시간 흐름으로 이해하기 요청 시작 브라우저가 URL을 요청하고 네트워크 왕복이 시작된다. → 서버 생성 서버가 요청 시점 데이터로 HTML을 만들거나 캐시된 결과를 꺼낸다. → 첫 표시 HTML과 CSS가 도착하면 브라우저가 첫 화면을 그리기 시작한다. → 연결 단계 자바스크립트가 로드되고 React가 기존 DOM에 연결된다. → 상호작용 가능 이벤트 핸들러가 붙고 클릭, 입력, 토글이 기대한 대로 동작한다. 흐름으로 보기 흐름 다이어그램 이 순서를 먼저 잡아두면 SSR이 바꾸는 구간과 바꾸지 않는 구간이 자연스럽...

웹 접근성은 왜 기능이 아니라 기본 품질일까: 구조부터 점검까지 실무적으로 이해하기 빠른 답 웹 접근성은 일부 사용자를 위한 부가 기능이 아니라, 더 많은 사용자가 같은 기능을 실제로 사용할 수 있게 만드는 기본 품질입니다. 출발점은 복잡한 위젯이나 ARIA 가 아니라 HTML 구조, 제목 체계, 버튼과 링크의 의미 같은 기본 마크업입니다. ARIA 는 시맨틱 요소를 대체하지 못하고, 이름·역할·상태를 보강해야 할 때만 의미가 있습니다. 자동 검사 점수보다 중요한 것은 키보드와 스크린 리더로 핵심 사용자 흐름을 끝까지 수행할 수 있는지입니다. 목차 점검 순서 흐름으로 보기 웹 접근성을 기본 품질로 보는 이유 사용자는 어디에서 막히는가 시맨틱 구조가 접근성의 출발점인 이유 폼, 버튼, 모달에서 바로 적용하는 코드 예시 ARIA는 언제 필요하고 언제 멈추는 편이 나은가 키보드 포커스, 대비, 오류 메시지는 함께 봐야 한다 개발 과정에 녹이는 설정과 자동 점검 개선 우선순위를 잡을 때 놓치기 쉬운 점 점검 순서 제목 구조, 랜드마크, 버튼·링크의 의미를 먼저 확인합니다. 마우스를 치우고 Tab , Shift+Tab , Enter , 방향키만으로 이동해 봅니다. 폼 입력, 오류 메시지, 제출 실패 흐름이 읽히는지 점검합니다. 모달·탭·드롭다운 같은 복합 UI에 필요한 ARIA 만 보강합니다. 자동 진단 도구로 누락을 찾고, 마지막에 실제 보조기기 탐색으로 우선순위를 다시 조정합니다. 이 순서가 유용한 이유는 접근성 문제가 대개 화려한 인터랙션보다 기본 구조에서 먼저 드러나기 때문입니다. 처음부터 속성을 많이 덧붙이기보다, 문서 구조와 상호작용 흐름을 바로잡는 편이 실제 사용성 개선으로 이어지는 경우가 많습니다. 흐름으로 보기 1 구조 작성: 제목, 랜드마크, 입력 요소, 버튼의 의미를 마크업에 담습니다. ↓ 2 브라우저 해석: DOM 과 기본 시맨틱을 바탕으로 접근성 트리가 만들어집니다. ↓ 3 보조기기 전달: 스크린 리더는 요소의 ...