프레임워크는 애플리케이션을 만들 때 반복해서 필요한 기본 구조와 규칙을 미리 만들어 둔 개발 뼈대입니다. 쉽게 말하면, 개발자가 모든 걸 처음부터 조립하는 게 아니라, 프레임워크가 제공하는 흐름과 틀 안에서 필요한 기능만 채워 넣도록 도와주는 형태입니다.

핵심은 두 가지입니다.
첫째, 구조와 흐름을 표준화해 줍니다. 예를 들어 요청 처리 흐름, 예외 처리 방식, 계층 분리 같은 기본 아키텍처를 프레임워크가 권장하는 방식으로 잡아주기 때문에, 프로젝트가 커져도 일관성을 유지하기 쉽습니다.
둘째, 공통 기능을 제공해 줍니다. 웹 개발이라면 라우팅, 인증/인가, 트랜잭션, 데이터 접근 같은 반복 요소를 기본으로 지원해서, 개발자는 비즈니스 로직에 더 집중할 수 있습니다.

그리고 라이브러리와 자주 비교되는데, 차이는 보통 제어 흐름의 주도권에 있습니다. 라이브러리는 개발자가 필요할 때 호출해서 쓰는 도구에 가깝고, 프레임워크는 전체 실행 흐름을 프레임워크가 주도하면서 개발자는 그 규칙에 맞춰 확장하는 방식에 가깝습니다.

서버 사이드 로직은 사용자 요청을 서버에서 처리해서 결과를 만들어 주는 핵심 처리 과정입니다.

클라이언트가 버튼을 누르거나 API를 호출하면, 서버는 그 요청을 받아서 인증·인가 확인, 입력값 검증, 비즈니스 규칙 적용, DB 조회·저장, 외부 서비스 연동 같은 처리를 한 뒤, 최종적으로 응답 데이터나 화면 결과를 내려줍니다.

예를 들면 로그인 성공 여부 판단, 게시글 등록 시 권한 체크, 주문 결제 처리, 통계 계산처럼 보안과 데이터 정합성이 중요한 작업은 보통 서버에서 담당합니다. 이렇게 서버에서 처리하면 규칙을 한곳에서 통제할 수 있어서 일관성이 좋아지고, 민감한 정보도 상대적으로 안전하게 다룰 수 있습니다.

ORM은 객체(Object)와 관계형 데이터베이스(Relational DB) 테이블을 매핑해서, SQL을 직접 많이 쓰지 않고도 DB를 다루게 해주는 기술입니다.

자바에서는 보통 엔티티 같은 객체를 만들고, ORM이 그 객체를 테이블의 행(row)처럼 저장·조회·수정·삭제할 수 있게 변환해 줍니다. 그래서 개발자는 SQL 작성보다 도메인 로직과 객체 모델링에 더 집중할 수 있고, 반복적인 CRUD 코드도 줄어듭니다.

다만 ORM이 SQL을 대신 만들어 주는 만큼, 실제로 어떤 쿼리가 나가는지 확인하고 성능 이슈(N+1 같은 것)를 관리하는 감각은 필요합니다.

Spring Data JPA는 JPA 기반 데이터 접근을 "Repository" 추상화로 제공해서, CRUD 같은 반복 코드를 크게 줄여주는 스프링 모듈입니다.

💡 괄호 안에 Hibernate라고 적는 이유는?

Spring Data JPA는 "JPA 기반 Repository 추상화"이고, 실제로 DB에 붙어서 SQL 생성·실행 같은 ORM 동작을 하는 JPA 구현체(Provider)가 Hibernate인 경우가 많기 때문입니다.

특히 Spring Boot에서는 JPA를 쓸 때 기본 JPA Provider로 Hibernate가 자동 설정되는 흐름이 일반적이라, "우리는 Spring Data JPA를 쓰고, 그 아래 엔진은 Hibernate다"를 한 줄로 명확히 보여주려고 괄호에 Hibernate를 붙입니다.

템플릿은 서버에서 HTML 화면을 만들기 위한 "화면 뼈대"를 뜻합니다. 그리고 Thymeleaf 같은 템플릿 엔진이 그 뼈대(HTML)에 데이터를 끼워 넣어서 최종 HTML을 렌더링해 브라우저에 내려줍니다.

필요한 상황은 보통 이렇습니다.

• 서버 사이드 렌더링(SSR)으로 화면을 직접 내려줄 때
• 로그인/관리자 페이지처럼 "페이지 단위"가 명확한 웹 화면을 빠르게 만들 때
• 프론트가 SPA여도 "풀백 화면"이 필요할 때

반대로, 백엔드가 REST API만 제공하고 화면은 React 같은 SPA가 전부 담당하면, 일반적인 페이지 렌더링 용도로는 템플릿 엔진이 필수는 아닙니다.

처음에 하나의 HTML 문서를 로드해 두고, 이후 화면 전환은 페이지를 통째로 다시 받지 않고 브라우저에서 자바스크립트로 필요한 부분만 갱신하는 방식입니다.

그래서 보통 서버는 "화면"을 계속 만들어 보내기보다, 화면에 필요한 데이터(API 응답)를 주고, 라우팅과 렌더링은 클라이언트에서 처리하는 형태가 많습니다. 장점은 화면 전환이 매끄럽고 앱처럼 빠르게 느껴질 수 있다는 점이고, 대신 초기 로딩 부담이나 검색엔진 노출(SEO)·크롤링 대응 같은 부분은 신경 써야 합니다.

서버 사이드 렌더링은 브라우저가 화면을 만들기 전에, 서버가 먼저 페이지의 HTML을 완성해서 내려주는 방식입니다. 즉, 사용자가 URL로 들어오면 서버가 데이터까지 반영한 "완성된 HTML"을 만들어 응답하고, 브라우저는 그 HTML을 바로 그려서 화면을 보여줍니다.

반대로 클라이언트 사이드 렌더링은 브라우저가 자바스크립트로 화면을 조립하는 방식이라, 초기에는 비교적 "빈 HTML + JS"를 받고 브라우저에서 렌더링이 진행됩니다.

Spring MVC에서 Thymeleaf 같은 템플릿 엔진으로 서버가 HTML을 만들어 내려주는 구조가 대표적인 SSR 사례라고 보면 됩니다.

💡 SSR이 유리한 경우

• 첫 화면이 빨리 보여야 할 때: 서버가 HTML을 완성해서 보내므로, 사용자는 초기 화면을 더 빨리 “보는 느낌”을 받을 수 있습니다.
• SEO/공유 미리보기 같은 ‘문서 기반’ 노출이 중요할 때: 처음부터 콘텐츠가 포함된 HTML을 받는 구조가 유리합니다.

💡 CSR이 유리한 경우

• 대시보드/툴처럼 상호작용이 많은 앱: 페이지 전환을 매번 서버에서 HTML로 만들 필요 없이, 브라우저에서 화면 일부만 갱신하므로 앱처럼 부드러운 UX를 만들기 좋습니다.
• 로그인 후 사용자 개인 데이터 중심 화면: 검색 노출보다 “빠른 화면 갱신, 풍부한 인터랙션”이 핵심이면 CSR이 맞는 경우가 많습니다.

결론은 “SSR vs CSR”보다 “혼합 전략”이 흔합니다. 요즘은 초기 진입은 SSR/SSG로 빠르게 보여주고, 이후 화면 전환·상호작용은 클라이언트에서 처리하는 식으로 절충하는 방식이 일반적입니다(하이드레이션/서버+클라이언트 컴포넌트 조합 등).

애플리케이션이 "지금 정상 동작 중인지", 그리고 "트래픽을 받을 준비가 됐는지"를 외부에서 기계적으로 확인할 수 있게 해주는 점검 방식입니다. 보통은 아주 가벼운 HTTP 엔드포인트로 제공하고, 결과를 보고 장애를 감지하거나(모니터링), 트래픽을 차단하거나(로드밸런서), 필요하면 재시작(오케스트레이터) 같은 자동 조치를 하게 됩니다.

💡 헬스체크를 하는 이유

• 장애를 빨리 감지해서 운영/배포 자동화가 판단할 근거를 만들기 위해서입니다.(정상/비정상 신호)
• 트래픽 제어를 위해서입니다. 예를 들어 "서버는 떠 있지만 DB 연결이 안 된다"면, 사용자 요청은 받지 않게 막는게 낫습니다.(ready가 아님)
• 컨테이너 환경에서는 보통 헬스체크를 Liveness / Readiness / Startup으로 나눠서 씁니다.

Spring Boot Actuator는 운영(Production) 환경에서 애플리케이션을 모니터링·관리하기 위한 기능들을 엔드포인트 형태로 제공하는 Spring Boot 모듈입니다. HTTP 또는 JMX로 상태/지표를 노출할 수 있고, 기본 제공 엔드포인트도 여러 개 있습니다.

• 대표적으로 /actuator/health가 헬스체크 엔드포인트이고, 전체 상태(status)와 구성요소별 상태(components)를 내려줄 수 있습니다.
• 또한 Actuator는 metrics 같은 지표 엔드포인트를 제공하고, 내부적으로 Micrometer 자동 설정을 통해 Prometheus, Datadog 등 다양한 모니터링 시스템으로 내보낼 수 있게 연결해 줍니다.

즉, "모니터링/헬스체크"는 서비스가 살아있는 확인(health) + 관측 지표 제공(metrics 등)을 한 패키지로 맡는 기술이 Actuator이다.

React는 웹(그리고 React Native 같은 환경)에서 UI를 컴포넌트 단위로 만들고 렌더링하는 자바스크립트 라이브러리입니다.

💡 라이브러리이지만 구분이 프레임워크인 이유는?

1. React는 공식적으로 “라이브러리”라서 용도를 UI 라이브러리로 쓰는 게 맞습니다.
2. 다만 실무에서 React로 앱을 만들 때 라우팅, 상태관리, 빌드/폴더 구조 같은 것까지 함께 묶어서 쓰다 보니, 스택 표의 “구분”을 크게 잡을 때 관용적으로 프레임워크 칸에 넣는 경우가 많습니다(분류 칸이 단순해서요).

프레임워크와 라이브러리의 핵심 차이는 보통 제어 흐름의 주도권(IOC, Inversion of Control)입니다.

• 라이브러리: 내가 필요할 때 라이브러리 함수를 호출하고, 호출이 끝나면 제어가 다시 내 코드로 돌아옵니다.
• 프레임워크: 큰 실행 흐름을 프레임워크가 쥐고 있고, 내 코드는 정해진 지점에 “끼워 넣는” 형태로 프레임워크가 내 코드를 호출합니다.

TypeScript는 자바스크립트에 “타입 문법”을 추가한 언어(자바스크립트의 상위집합)이고, 최종적으로는 일반 JavaScript로 컴파일(변환)되어 실행됩니다.

💡 TypeScript의 용도는 타입 안정성이다. 이유는?

용도가 타입 안전성인 이유는, TypeScript의 핵심 목표가 코드가 실행되기 전에 정적 타입 검사로 타입 오류를 잡아주는 것이라서입니다. 예를 들어 잘못된 프로퍼티 접근이나 함수 인자 타입 실수 같은 문제를 개발 단계에서 미리 발견하게 해 주고, 그 결과 자동완성·리팩토링 같은 도구 지원도 더 정확해집니다.

정리하면, “JavaScript로도 구현은 가능하지만, TypeScript는 타입을 통해 실행 전에 오류를 잡아 주고 자동완성·리팩토링 같은 도구 지원이 좋아서 유지보수성이 올라갑니다.”

사용자 입장에서 "URL이 바뀌면 다른 화면이 보이는" 내비게이션을 프론트에서 관리해야 하기 때문입니다. 특히 SPA에서는 페이지를 새로 받아오지 않으니, URL ↔ 화면(컴포넌트) 매핑을 해주는 라우터가 필요합니다.

💡 1. React Router DOM

React 웹 앱에서 라우팅을 구현하는 라이브러리로, URL 경로에 따라 어떤 컴포넌트를 보여줄지 정하고, 브라우저의 뒤로가기/앞으로가기 같은 탐색도 자연스럽게 동작하도록 도와줍니다.

💡 2. React Router DOM을 사용한 이유

React Router DOM을 선택하는 가장 흔한 이유는 “React에서 가장 표준적으로 쓰이는 라우팅 솔루션이고, 운영·유지보수 관점에서 리스크가 낮기 때문”입니다. 구체적으로는 보통 아래 이유가 큽니다.

• 채택률/생태계가 압도적이라 레퍼런스가 많음
• React에 “자연스럽게” 붙는 설계(선언적 라우팅, 컴포넌트 기반)
• 실전에서 필요한 기능이 기본으로 탄탄함
• 데이터 라우팅(Loader/Action 등) 같은 확장 기능까지 커버
• 유지보수/신뢰도(메인테이너·히스토리)

참고로 “다른 걸” 선택하는 경우도 분명 있습니다. 예를 들어 타입 안전한 라우팅을 아주 강하게 가져가고 싶으면 TanStack Router가 매력적인 대안이 될 수 있고, 반대로 Next.js를 쓰면 라우팅이 프레임워크에 내장돼서 React Router DOM을 따로 둘 필요가 없기도 합니다.

💡 3. 용도가 SPA 라우팅인 이유

용도가 “SPA 라우팅”인 이유는, React Router DOM이 서버에 새 HTML을 요청해서 페이지를 바꾸는 방식이 아니라 클라이언트에서 URL만 바꾸고 화면을 교체하는 “클라이언트 사이드 라우팅”을 제공하기 때문입니다.

💡 4. SPA 라우팅의 개념

페이지 새로고침 없이 URL 변경(pushState/replaceState 등)과 화면 렌더링을 클라이언트에서 처리하는 방식입니다.

Next.js는 React로 풀스택 웹 애플리케이션을 만들기 위한 프레임워크입니다. React 컴포넌트로 UI를 만들고, Next.js가 그 위에서 라우팅, 렌더링(SSR/정적 생성 등), 빌드·번들링 같은 개발/운영에 필요한 기능과 최적화를 함께 제공합니다.

• 파일 기반 라우팅: 폴더/파일 구조로 URL 경로를 정의하는 방식(특히 App Router).
• 서버 사이드 렌더링(SSR) 등 다양한 렌더링 전략 지원: 페이지를 요청마다 서버에서 HTML로 만들어 주는 SSR 같은 방식을 공식적으로 지원합니다.
• React 개발에 필요한 툴링을 추상화/자동 설정: 번들링·컴파일 등 설정 부담을 줄여 애플리케이션 개발에 집중하게 해줍니다.

Axios(액시오스)는 브라우저와 Node.js에서 HTTP 요청(GET/POST 등)을 보내기 위한 Promise 기반 HTTP 클라이언트 라이브러리입니다. 요청/응답을 공통 API로 다루면서, 인터셉터(요청·응답 가로채기), 데이터 변환, 타임아웃/취소 처리 같은 기능을 제공해 API 통신 코드를 깔끔하게 관리하는 데 자주 사용합니다.

Node.js는 브라우저 밖에서 JavaScript를 실행할 수 있게 해주는 런타임 환경입니다. Chrome의 V8 엔진을 기반으로 하고, 서버 개발에 필요한 파일 시스템, 네트워크 같은 기능을 제공합니다.

💡 TypeScript로 만든 React 프로젝트에서 Node.js가 자주 같이 언급되는 이유

1. Axios가 “브라우저 + Node.js” 모두에서 동작하는(isomorphic) HTTP 클라이언트라서요.
   Axios 문서 자체가 “node.js와 브라우저용”이라고 설명하고, 브라우저에서는 XHR을 쓰고 서버(Node.js)에서는 Node의 http 모듈을 쓴다고 명시합니다.
   즉, React 프론트에서는 보통 브라우저에서 Axios를 쓰지만, Axios가 원래 양쪽 환경을 지원하다 보니 Node.js가 설명에 같이 나옵니다.
2. 프론트엔드 개발 과정에서 빌드/개발 서버/패키지 설치 같은 “도구”가 Node.js 위에서 돌아가서입니다.
   React 공식 문서도 Vite 같은 빌드 도구를 설치해서 개발 서버와 빌드를 한다고 안내하는데, 이런 도구들은 통상 Node 환경에서 실행됩니다.
   그리고 TypeScript도 결국 JavaScript로 변환되어 실행되는데, 그 JavaScript가 실행되는 환경이 브라우저일 수도, Node.js일 수도 있다고 공식 사이트에서 설명합니다.

정리하면, React+TypeScript 앱 자체는 브라우저에서 실행되지만, 개발·빌드 도구와 일부 서버 사이드 코드에서 Node.js가 쓰이기 때문에 기술 스택 설명에서 함께 등장하는 경우가 많습니다.

Tailwind CSS는 utility-first(유틸리티 우선) CSS 프레임워크로, 미리 준비된 작은 스타일 클래스들을 마크업에 조합해서 원하는 디자인을 만드는 방식입니다. “필요한 스타일을 HTML/JSX 안에서 클래스 조합으로 만든다”가 핵심입니다.

💡 유틸리티 기반 스타일링이란?

한 클래스가 하나의 역할(예: 여백, 색, 정렬 등)을 담당하는 ‘단일 목적’ 클래스(utility class)를 여러 개 붙여서 최종 UI를 만드는 방식입니다. 그래서 별도 CSS를 많이 작성하지 않고도, 클래스 조합만으로 화면을 빠르게 구성할 수 있습니다.

H2는 자바로 만들어진 경량 SQL 관계형 데이터베이스로, 애플리케이션에 내장(embedded) 해서 쓰거나 서버 모드로도 사용할 수 있고 메모리(in-memory) 또는 디스크(파일) 저장을 지원합니다.

💡 "파일 기반" 용도의 의미

“파일 기반”은 DB 데이터를 메모리가 아니라 디스크의 파일로 저장한다는 뜻입니다. 그래서 애플리케이션을 껐다 켜도 데이터가 파일에 남아 유지(영속) 됩니다. 반대로 in-memory 방식은 실행 중 메모리에만 올라가서, 종료하면 데이터가 사라지는 형태입니다.

💡 파일 기반 (./data/booktine) 의미

./data/booktine 같은 표기는 DB 파일을 저장할 위치(상대 경로)를 의미합니다. 즉, 프로젝트(또는 실행 디렉터리) 기준으로 data 폴더 아래에 booktine 이름으로 DB 파일들이 만들어지고, 그 파일을 통해 데이터가 유지되는 구조라고 보시면 됩니다.

컨테이너를 만들고(이미지 빌드), 배포하고(레지스트리), 실행·관리하는(컨테이너 런) 과정을 지원하는 컨테이너 플랫폼/도구 생태계입니다. 컨테이너 이미지를 “코드+의존성”까지 포함한 실행 패키지로 만들어서, 서로 다른 환경 간 이식성을 높이는 데 목적이 있습니다.

REST(Representational State Transfer)라는 아키텍처 스타일의 원칙을 따라,HTTP로 "리소스"를 주고받도록 설계한 API를 말합니다.

REST API에서 흔히 강조하는 핵심 개념은 이 정도입니다.

• 리소스 중심: 사용자, 게시글 같은 대상을 URI로 식별하고(예: /users, /posts/{id}), 그 리소소의 표현(보통 JSON)을 주고받습니다.
• 표준 HTTP 메서드 사용: GET/POST/PUT/PATCH/DELETE처럼 HTTP 메서드로 “조회/생성/수정/삭제” 의도를 표현합니다(균일한 인터페이스).
• 무상태(Stateless): 요청 하나하나가 필요한 정보를 포함하고, 서버는 클라이언트의 상태를 세션처럼 계속 들고 있지 않는 것을 원칙으로 합니다.

💡 누가 설계하나? 백 vs 프론트

REST API는 클라이언트(프론트)가 호출해서 서버가 처리해 주는 "서버 인터페이스(계약)"라서, 보통 백엔드가 최종 설계·구현 책임을 집니다. 서버는 요청을 받아 처리하고 HTTP 응답을 돌려주는 주체이기 때문입니다.

다만 실무에서는 “백엔드만” 또는 “프론트만”이 단독으로 정하기보다, 프론트·백이 함께 API 계약을 맞추는 방식(Contract / Design-First)이 일반적입니다.

• 프론트가 주로 결정에 기여하는 부분: 어떤 화면/기능에 어떤 데이터가 필요한지, 요청/응답 바디 형태가 사용하기 편한지(소비자 관점).
• 백엔드가 주로 결정에 기여하는 부분: 리소스 모델링, 인증/인가, 트랜잭션/정합성, 성능/페이징, 에러 규격, 버전 전략 등(제공자 관점).
• 그래서 API 계약(OpenAPI 같은 명세)을 먼저 합의해두면 프론트와 백이 병렬로 개발하기가 쉬워집니다.

정리하면, “누가 설계하나?”의 답은 ‘백엔드가 책임을 지되, 프론트와 계약을 함께 맞춘다’가 가장 정확합니다.