프로그래밍 핵심 개념

셋은 완전히 다른 것이 아니라 '속성'과 '기능' 중 무엇을 가졌는지로 갈린다. 객체는 속성과 기능을 모두 가진 완전체이고, 여기서 기능을 빼면 저장만 가능한 개체, 속성을 빼면 변환만 가능한 함수가 된다.

• 객체(Object) = 속성 + 기능 — 상태를 관리하면서 행위도 수행한다
• 개체(Entity) = 객체 − 기능 — 저장만 가능하며 데이터베이스 테이블에 대응한다
• 함수(Function) = 객체 − 속성 — 데이터 변환만 담당하며 화면·로직에 대응한다

설계도 위의 개념과 메모리 위의 실체를 구분하는 것이 시작이다. 개체가 메뉴판에 적힌 '스테이크'라면 객체는 실제로 접시에 나온 스테이크다. 마찬가지로 데이터는 가공되지 않은 원시 재료, 값은 타입이 정해져 의미가 생긴 결과물이다.

• 개체(Entity)는 개념적 모델, 객체(Object)는 코드로 구현된 메모리 실체
• 데이터(Data)는 가공 전 원시 정보, 값(Value)은 타입이 결정된 구체적 의미
• 문자열(String)은 텍스트지만 객체로 취급되어 자체 기능을 갖는다
• 스레드(Thread)는 실행의 주체로, CPU 자원을 써서 여러 작업을 동시에 처리한다

괄호가 붙어 있으면 동작을 수행하는 기능이고, 없으면 데이터를 담은 속성이다. 리모컨으로 비유하면 버튼을 눌러 채널을 바꾸는 것이 기능, 색상이 검정이고 배터리가 80%인 상태가 속성이다.

• 기능은 괄호 `()`가 있고 동작을 수행한다 — `window.alert(msg)`
• 속성은 괄호가 없고 데이터 값 자체다 — `data.message`
• 선언(Declaration)은 이름과 종류만 등록하는 것, 정의(Definition)는 구체적 로직을 채우는 것
• 상수는 변하지 않는 외부 골격, 변수는 상황에 따라 바뀌는 내부 알맹이

튜링 머신의 규칙표는 실행 내내 절대 바뀌지 않는 상수이고, 현재 읽고 있는 기호와 헤드의 위치는 매 순간 바뀌는 변수다. '~라면 ~한다'는 규칙 자체가 틀이고, 그 틀에 들어가는 현재 상태가 알맹이다.

• 상수(Constant): 절대 변하지 않는 레시피 — 프로그램의 규칙과 정책
• 변수(Variable): 메모리에 저장되어 수시로 갱신되는 현재 상태
• 포인터(현재 위치)와 헤드가 읽는 기호는 모두 변수에 해당한다

웹·객체지향·메모리 세 영역에서 반복되는 같은 대립 구조다. 처음 정해진 기록을 고수하면 정적, 실행 중 사용자 개입으로 실시간 상태를 반영하면 동적이다.

• 웹: HTML 문서에 박힌 Attribute(초기 설정값) ↔ DOM 객체의 Property(현재 실시간 값)
• 객체지향: 모든 인스턴스가 공유하는 클래스 변수 ↔ 개별 인스턴스가 독립적으로 갖는 값
• 메모리: 실행 내내 고정된 상수 ↔ 코드 흐름에 따라 재할당되는 변수

클래스는 설계도이고 인스턴스는 그 설계도로 실제 지은 집이다. 하나의 설계도로 여러 채의 집을 지을 수 있고, 각 집은 서로 다른 가구(인스턴스 변수)를 갖는다.

• 클래스 = 청사진, 인스턴스/객체 = 실제로 지어진 집
• 인스턴스 변수 = 집마다 다른 가구 (101호는 파란 소파, 102호는 빨간 침대)
• 메서드 = 가구의 기능 (냉장고 열기, 의자에 앉기)
• 지역 변수 = 작업 중에만 쓰는 임시 부품, 전역 변수 = 단지 전체 공지사항

구조는 그대로 유지되고 이름만 바뀐 패러다임 전환이다. 객체의 필드는 컴포넌트의 HTML/JSX 속성이 되고, 객체의 메서드는 컴포넌트의 스크립트 로직이 된다.

• 객체의 속성(Field) → 컴포넌트의 Property(HTML/JSX)로 사용자에게 보일 UI 구조 정의
• 객체의 기능(Method) → 컴포넌트의 Script(JS/TS)로 데이터 처리와 상태 로직 관리
• 메서드 로직이 컴포넌트 로직이 되는 것이 핵심 변화

백엔드의 클래스·인스턴스·메서드 구조가 프론트엔드에서도 컴포넌트·렌더링된 객체·이벤트 핸들러로 그대로 대응된다. 양쪽은 JSON 데이터를 주고받으며 연결된다.

• 백엔드: 클래스(스키마) → 인스턴스(RAM/DB의 객체) → 인스턴스 변수 · 메서드 · 지역 변수
• 프론트엔드: 컴포넌트(UI 청사진) → DOM에 렌더링된 컴포넌트 → props/state · 이벤트 핸들러 · 임시 상태
• 최상위에는 양쪽이 공유하는 컨텍스트와 전역 변수가 있다

스코프는 안쪽에서 바깥쪽으로 로컬 변수 → 필드 → 클래스 → 전역 → 컨텍스트 순으로 확장된다. Next.js와 FastAPI 양쪽에서 각 계층이 무엇에 대응하는지 매핑해 두면 스택을 옮겨도 구조가 보인다.

• 중심: 로컬 변수와 메서드 — 함수 내부 블록 `{}`
• 중간층: 클래스와 필드 — React 컴포넌트 / SQLAlchemy ORM 클래스
• 외부층: 전역 변수와 컨텍스트 — Zustand 스토어 / Python 모듈 레벨 변수
• 가장 바깥: 환경 변수 — `.env.local`, `.env`에 담긴 DB 접속 정보와 API 키

모래시계 구조로 보면 위쪽 함수의 로컬 변수와 아래쪽 함수의 로컬 변수는 완전히 분리된 메모리다. 두 공간을 잇는 유일한 통로가 매개변수이고, 이름이 같아도 서로 다른 메모리를 쓴다.

• 상단 스코프의 로컬 변수는 외부에서 직접 접근할 수 없다
• 중앙 격리선: 스코프는 완전히 분리되어 메모리가 섞이지 않는다
• 매개변수(Parameter)는 외부 데이터를 안전하게 수신하는 단 하나의 관문
• 전달받은 값은 하단 스코프에서 새 로컬 변수에 할당된다 — 이름만 같을 뿐 독립적이다

보통 함수는 실행이 끝나면 스택 프레임과 함께 지역 변수가 사라진다. 하지만 내부 함수가 외부 변수를 참조하고 있으면 그 변수는 힙에 남아 상태를 유지한다. 이것이 클로저다.

• 일반 동작(무상태): 함수 실행이 끝나면 스택 프레임이 정리된다
• 클로저 생성: 내부 함수가 외부 스코프 변수를 감싸 안은 채 객체로 만들어진다
• 상태 유지: 참조 카운트가 남아 있어 가비지 컬렉션 대상에서 제외된다
• 이후 호출마다 저장된 카운터가 이어서 증가한다 — 상태를 기억하는 함수

페널티 에어리어 안에서만 통하는 규칙이 지역 스코프라면, 경기장 전체에 적용되는 규칙이 전역 스코프다. 좁은 영역에서만 쓰이는 화살표 함수와 경기장 전체를 감싸는 클로저·클래스의 차이로 볼 수 있다.

• 페널티 에어리어 = 좁은 지역 스코프 (화살표 함수, 메서드)
• 필드 전체 = 넓은 전역 스코프 (클로저 함수, 클래스)
• 스코프를 좁게 유지할수록 예상치 못한 부작용이 줄어든다

문자 하나에서 시작해 차원을 하나씩 더하면 텐서까지 이어진다. 머신러닝에서 다루는 데이터 구조를 기하학적 형상으로 이해하면 shape 개념이 훨씬 명확해진다.

• 0차원 — 캐릭터/스칼라: 점(Point), 가장 기초적인 단일 데이터
• 1차원 — 스트링/벡터: 선(Line), 단일 데이터의 일렬 나열 `[1, 2, 3]`
• 2차원 — 매트릭스: 면(Plane), 가로와 세로의 행렬 구조 (엑셀 시트)
• 3차원 이상 — 텐서/큐브: 체(Volume), 매트릭스가 여러 겹 쌓인 고차원 데이터