데이터는 함수에서 객체로, 객체에서 개체로 간다

무상태·상태

통신 구간(예: HTTP 요청 하나하나)이 이전 요청을 기억하지 않는다는 말이지, 프론트나 백엔드 자체가 상태를 안 가진다는 말이 아닙니다.

프론트(리액트 state)도 백엔드(DB에 쌓인 값)도 각자 상태를 가지며, 무상태인 것은 그 둘을 잇는 통신 구간뿐입니다.

개념구분

선언은 이름만 만드는 것(let password;), 정의는 그 이름에 알맹이를 채우는 것(CREATE TABLE ...)입니다.

정제는 이미 있는 데이터를 다듬는 것, 파인튜닝은 이미 학습된 모델을 추가로 손보는 것으로, 뒤로 갈수록 이미 존재하는 것에 손을 대는 단계입니다.

개념구분

괄호가 없으면 속성(data.message 처럼 값을 그냥 가리킴), 괄호가 있으면 기능(alert() 처럼 실행되는 동작)입니다.

이 구분은 프론트(Property/Method), 백엔드(Attribute/Method), DB(Column/Procedure) 어디서든 같은 원리로 반복됩니다.

웹·REST

'서버의 원본이 바뀌는가'입니다. GET은 Safe(조회만, 원본 불변), POST·PUT·DELETE는 Unsafe(조작, 원본이 바뀜)입니다.

REST API는 이 축 위에서 자원(URL)·메서드·표현(주로 JSON)을 조합해 설계됩니다.

웹·REST

둘 다 텍스트가 객체(구조화된 데이터)가 되는 길입니다. DOM은 HTML 텍스트를 브라우저가 조작 가능한 트리 객체로 바꾸고, JSON은 데이터를 텍스트로 직렬화해 네트워크로 옮긴 뒤 다시 객체로 되살립니다.

리액트

화면(UI)은 상태(state)를 입력으로 받는 함수의 출력이라는 뜻입니다. state가 바뀌면 f가 다시 계산되어 UI가 다시 그려집니다.

상태를 직접 조작해 화면을 바꾸는 대신, 상태만 바꾸면 화면은 함수가 알아서 다시 그립니다.

리액트

함수가 자신을 둘러싼 스코프의 변수를 기억해, 함수 실행이 끝난 뒤(스택 프레임이 사라진 뒤)에도 그 값을 계속 참조할 수 있게 하기 때문입니다.

참조가 남아 있는 한 가비지 컬렉션이 그 값을 수거하지 않습니다.

웹·REST

프론트(입력·상태) → 백엔드(요청 처리·검증) → DB(영구 저장)의 3계층을, REST API 요청/응답이라는 연결고리가 잇습니다.

각 경계를 넘을 때마다 데이터의 형태(리액트 state → JSON → SQL row)가 바뀝니다.

스스로 확인

선언(Declaration)과 정의(Definition), 그리고 정제(Refine)입니다. 함수에서 객체로, 객체에서 개체로 갈수록 더 구체화됩니다.

스스로 확인

선언은 let password; 처럼 이름만 등록하는 것, 정의는 CREATE TABLE ... 처럼 형식과 실행 코드까지 확정하는 것입니다.

스스로 확인

alert() 가 기능입니다. 괄호가 있으면 기능(실행되는 동작), 괄호가 없으면 속성(값을 가리킴)입니다.

스스로 확인

통신 구간입니다. 프론트도 백엔드도 각자 상태를 가지며, 무상태인 것은 그 둘을 잇는 통신 구간뿐입니다.

스스로 확인

상태를 내부에 들고 있는가입니다. 함수는 무상태, 클래스(인스턴스)는 상태를 가집니다.

스스로 확인

서버의 원본이 바뀌는가(Safe/Unsafe) 축입니다. GET은 URL에, POST는 Body에 데이터가 실립니다.

스스로 확인

무상태는 REST의 여섯 제약 중 하나일 뿐입니다. RESTful ⊃ Stateless 관계입니다.

스스로 확인

둘 다 텍스트가 객체(구조화된 데이터)가 되는 길입니다.

스스로 확인

아닙니다. 전송은 axios/fetch 가 합니다. preventDefault 는 브라우저의 기본 동작(새로고침)을 막는 방패일 뿐입니다.

스스로 확인

내부 함수가 외부 스코프의 변수를 계속 참조하는 한, 가비지 컬렉션이 그 메모리를 회수하지 않기 때문입니다.

스스로 확인

HTML의 초기 checked 속성(Attribute)과 사용자가 체크박스를 클릭한 뒤의 현재 상태(Property)가 다를 수 있습니다.

스스로 확인

결제 버튼을 두 번 누르면(POST를 두 번 보내면) 결제가 두 번 일어날 수 있기 때문입니다. 멱등하지 않은 요청은 중복 실행에 주의해야 합니다.

스스로 확인

값은 바뀌지만 화면이 다시 그려지지 않습니다. 리액트가 변경을 감지하지 못하기 때문입니다.

자주 하는 실수

프론트도 백엔드도 상태를 가집니다. 무상태인 건 통신 구간뿐입니다.

자주 하는 실수

Body에 담겨 안 보일 뿐입니다. 암호화는 HTTPS가 합니다.

자주 하는 실수

대문자로 시작해야 합니다. 소문자면 HTML 태그로 오해됩니다.

자주 하는 실수

클로저를 만들면 함수도 상태를 가집니다.

자주 하는 실수

리액트 JSX 안에서 상위 변수를 쓰는 것 자체가 이미 클로저입니다.

자주 하는 실수

Attribute는 HTML의 초기값(정적), Property는 DOM의 현재값(동적)입니다.

용어

디클러레이션은 이름만 등록하고 알맹이는 비워두는 것, 데피니션은 데이터 형식과 실행 코드·규칙까지 확정하는 것입니다.

용어

Raw Data는 가공되지 않은 날것의 데이터이고, 정형화는 서버가 읽을 수 있는 규격 포맷으로 맞추는 작업입니다.

용어

같은 입력에 항상 같은 출력을 내고 부수효과가 없는 함수입니다.

용어

GET은 조회, POST는 생성, PUT은 전체 교체 수정, PATCH는 부분 수정, DELETE는 삭제입니다.

용어

같은 요청을 여러 번 보내도 최종 상태가 같은 성질입니다.

용어

자원(Resource, 주소), 행위(Verb, 메서드), 표현(Representation, 데이터)입니다.

용어

메시지만 보고 형식을 해석할 수 있어야 한다는 REST의 제약입니다.

용어

브라우저가 HTML을 파싱해 메모리에 만든 객체 트리입니다(Document Object Model).

용어

훅은 함수 컴포넌트에서 상태·생명주기를 다루는 장치이고, useState는 상태값과 변경 함수를 한 쌍으로 돌려주는 훅입니다.

용어

변수를 못 찾으면 바깥 스코프로 올라가 찾는 규칙입니다.

용어

참조가 끊긴 메모리를 자동 회수하는 것입니다.

용어

Controller는 요청을 받아 전달하는 진입부, Service는 비즈니스 규칙을 판단하는 층입니다.

용어

무상태는 통신 구간(이전 요청을 기억하지 않음)에, 상태는 값을 내부에 저장·유지하는 설계 성질에 적용됩니다.

용어

명사로 표현됩니다. 데이터의 위치를 나타내는 주소(URI)입니다.

용어

텍스트를 해석해 객체로 만드는 구성요소입니다.

용어

화살표 함수는 ES6의 간결한 함수 문법(=>)이고, 람다는 이름 없는 익명 함수입니다.

용어

상태가 먼저 바뀌고 화면이 따라오는 흐름입니다.

용어

함수가 선언된 위치의 변수 환경입니다.

용어

참조 개수를 세어 0이면 회수하는 가비지 컬렉션 기법입니다.

용어

같은 개념이지만, 7~8강는 이것이 통신 구간에만 적용된다는 점을 강조하고, REST에서는 그것이 여러 제약 중 하나임을 강조합니다.

용어

2xx 성공 / 3xx 이동 / 4xx 요청 문제 / 5xx 서버 문제로 분류됩니다.

용어

프론트(입력·상태) → 백엔드(요청 처리·검증) → DB(영구 저장) 세 계층을 REST API 요청/응답이 잇습니다.

용어

화면(UI)은 상태(state)를 입력으로 받는 함수의 출력이라는 뜻입니다. state가 바뀌면 f가 다시 계산되어 UI가 다시 그려집니다.

용어

함수의 매개변수가 스코프 사이의 유일한 통로이듯, REST에서는 자원·행위·표현을 통해 요청이 전달되는 통로가 같은 역할을 합니다.

용어

선언은 이름만 만드는 것, 정의는 알맹이를 채우는 것, 정제는 있는 데이터를 다듬는 것, 파인튜닝은 이미 학습된 모델을 추가로 손보는 것으로, 뒤로 갈수록 이미 존재하는 것에 손을 대는 단계입니다.

용어

클래스 ↔ 인스턴스, 클래스변수 ↔ 인스턴스변수, 상수 ↔ 변수가 상태를 다루는 예시로 이어집니다.