29일차. IT 개념 정리

---

---

컨텍스트. 컨테이너, 컴포넌트

🟦 1. 컨텍스트(Context) — 프로그램이 돌아가는 ‘상태·환경 정보’

IT에서 컨텍스트는

어떤 코드가 실행되는 순간의 환경·상태·부가 정보 전체를 의미합니다.

✔️ 어디서 많이 쓰일까?

• 안드로이드 개발: Context 객체 → 앱 리소스 접근, 권한 확인 등에 사용
• 웹 백엔드: 요청(Request)의 컨텍스트 → 사용자, 쿠키, 세션, IP 등
• 프레임워크 내부: 현재 함수가 실행되는 환경(변수, 설정, 인증 상태 등)

✔️ 쉽게 설명하면

“이 코드가 지금 어떤 상황에서 실행 중인지 알려주는 정보 묶음”

---

🟦 2. 컨테이너(Container) — 앱을 실행하기 위한 ‘독립된 실행환경 패키지’

IT에서 컨테이너는 주로 Docker(도커) 개념을 떠올리면 가장 정확합니다.

✔️ 정의

애플리케이션과 그 실행에 필요한 모든 요소(라이브러리, OS 일부, 설정)를 묶어서 어디서나 동일하게 실행되도록 만든 가상화 기술

✔️ 특징

• 어디서 실행하든 결과가 동일함
• 서버 간 이동이 쉬움 (AWS → Azure 이렇게 이동 가능)
• 무거운 가상머신보다 훨씬 가볍고 빠름

✔️ 쉽게 표현하면

“앱을 담은 휴대용 포장박스 — 어디에 두든 똑같이 잘 돌아감”

---

🟦 3. 컴포넌트(Component) — 재사용 가능한 UI·기능 단위

프론트엔드 개발에서 특히 중요한 개념입니다.

✔️ 정의

앱을 구성하는 조립 가능한 단위 기능 요소(UI + 로직)

✔️ 예시

• 버튼 컴포넌트
• 카드(Card) 컴포넌트
• 네비게이션 바
• 입력폼(Form Input)

✔️ 어디서 가장 많이 사용할까?

• React, Vue, Angular 같은 프론트엔드 프레임워크
• 디자인 시스템(Figma 컴포넌트 등)

✔️ 쉽게 말하면

“앱 화면을 만드는 레고 블록”

---

🟩 세 개념 요약 비교

 

개념	핵심 IT 의미	비유
컨텍스트	실행 환경, 상태 정보	현재 상황 설명서
컨테이너	앱 실행용 통합 패키지	이동 가능한 포장 상자
컴포넌트	재사용 가능한 UI·로직 단위	레고 블록

 

---

🟦 텐서의 기본 정의

숫자를 여러 차원으로 배열해 놓은 데이터 구조

쉽게 말하면 **확장된 형태의 행렬(matrix)**입니다.

---

🟦 텐서를 차원별로 쉽게 이해하기

1차원 텐서 = 벡터(Vector)

예) [3, 7, 9]
→ 길이만 있는 일렬 데이터

2차원 텐서 = 행렬(Matrix)

예)

 

[ [1, 2], [3, 4] ]

→ 가로·세로가 있는 데이터

3차원 텐서

예) 여러 장의 2D 이미지가 쌓여 있는 형태

 

[ [ [1,2], [3,4] ], [ [5,6], [7,8] ] ]

4차원 텐서

예) 딥러닝 이미지 입력 데이터
(batch, height, width, channel) 구조

✔️ 한 문장 정리

스칼라 → 벡터 → 행렬 → 텐서(다차원) 순서로 일반화된 개념

 

🟦 0차원 텐서(스칼라, Scalar)란?

하나의 숫자만 존재하는 텐서
즉, 차원이 없는 단일 값

✔️ 예시

 

7 3.14 -12

이런 값들은 길이도 없고, 행도 없고, 열도 없는 단일 숫자죠.
그래서 텐서 구조에서 “0차원”이라고 부릅니다.

---

🟦 텐서 차원을 다시 정리하면

차원이름예시설명

0차원	스칼라(Scalar)	3	단 하나의 숫자
1차원	벡터(Vector)	[1, 2, 3]	길이만 있는 배열
2차원	행렬(Matrix)	[[1,2],[3,4]]	가로·세로 구조
3차원 이상	텐서(Tensor)	이미지, 영상 데이터	다차원 배열

---

🟦 왜 0차원도 텐서로 취급할까?

✔️ 1. 수학적으로 벡터·행렬의 가장 기본 단위

벡터는 스칼라가 모여 만들어지고, 행렬은 벡터가 모여 만들어집니다.
즉, 스칼라가 모든 텐서의 출발점입니다.

✔️ 2. 딥러닝 연산에서 필수

• 로스(loss) 값 → 0차원 텐서
• 특정 연산 결과가 단일 값일 때 → 0차원 텐서
• PyTorch, TensorFlow 모두 스칼라를 **tensor(0D)**로 취급

🟦 왜 딥러닝에서는 텐서를 쓸까?

✔️ 1. GPU가 텐서를 빠르게 계산하기에 최적화됨

행렬·다차원 연산을 병렬 처리하는 데 매우 효율적입니다.

✔️ 2. 딥러닝 데이터 대부분이 다차원 구조이기 때문

• 이미지 → 4D 텐서
• 음성 → 2D or 3D 텐서
• 자연어 → 문장 길이 × 임베딩 차원 = 2D 텐서
• 비디오 → 시간 축까지 포함해서 5D 텐서

✔️ 3. 모델 파라미터(가중치)도 텐서

딥러닝 모델 내부에서 모든 값(가중치·벡터·행렬)이 텐서 형태로 저장됩니다.

---

🟦 텐서를 딱 한 번에 이해하는 비유

🍱 도시락 칸 비유

• 밥(1칸) = 스칼라
• 반찬 3칸 = 1차원 벡터
• 두 줄로 정리된 칸 도시락 = 2차원 행렬
• 도시락 여러 층 = 3차원 텐서
• 도시락팩 여러 개 묶음 = 4차원 텐서

숫자를 담는 칸이 많아질수록 텐서의 차원이 늘어난다!

---

UUID가 뭐야?

**UUID(Universally Unique Identifier)**는
전 세계 어디서, 누가, 어떤 시스템에서 만들어도 겹치지 않는 고유한 식별자를 만들기 위한 규칙입니다.

쉽게 말하면,

컴퓨터가 생성하는 거의 절대로 중복되지 않는 ‘고유번호’

라고 보면 됩니다.

---

🟦 UUID의 형태(예시)

 

550e8400-e29b-41d4-a716-446655440000

• 총 32자리의 16진수
• 8-4-4-4-12 형태
• 무작위 + 시간 + 하드웨어 정보 등을 기반으로 생성

---

🟦 UUID를 왜 쓰는가?

✔️ 1. 중복될 가능성이 거의 0에 가까움

전 세계에서 동시에 만들어도 겹칠 확률이 사실상 없습니다.

✔️ 2. 순서를 맞출 필요 없는 데이터 식별에 유용

데이터베이스 PK, 세션 ID, 파일명, 트래킹 ID 등에서 사용.

✔️ 3. 서버 여러 대가 동시에 생성해도 충돌 없음

분산 시스템에서 특히 중요.

---

🟦 UUID의 버전도 존재함

버전특징

v1	시간 + MAC주소 기반
v4	난수(Random) 기반 → 가장 많이 사용
v5	이름 기반 해시(UUID + 문자열)

대부분의 서비스와 프레임워크는 UUID v4를 기본으로 사용합니다.

---

🟩 한 문장 요약

UUID는 전 세계에서 겹치지 않는 고유한 ID를 자동으로 만들어주는 규격

---

아티팩트 ID(Artifact ID)란?

Maven 또는 Gradle 같은 빌드 도구에서 프로젝트를 구분하는 고유 이름입니다.
보통 Java(Spring) 프로젝트를 만들 때 다음과 같은 정보들을 설정하죠:

• groupId
• artifactId
• version

이 중에서 **artifactId는 “프로젝트 자체의 이름”**을 의미합니다.

---

⭐ 쉽게 말하면?

아티팩트 ID = 내 프로젝트 폴더 이름(대표 이름)

예를 들어 my-spring-app 같은 이름이 아티팩트 ID가 됩니다.
빌드하면 다음과 같이 JAR 파일 이름에도 포함됩니다:

 

my-spring-app-1.0.0.jar

---

🧩 구조로 보면 이렇게 됨

Maven 또는 Gradle에서 프로젝트를 구별하기 위한 3가지 식별자

구분역할

groupId	회사/조직/도메인명(예: com.example)
artifactId	프로젝트 고유 이름(예: my-app)
version	버전 정보(예: 1.0.0)

---

3️⃣ URI와 URL, URN의 관계

• URL (Uniform Resource Locator): 위치를 알려주는 URI → 예: https://example.com/page
• URN (Uniform Resource Name): 이름만 알려주는 URI → 예: urn:isbn:0451450523
• URI = URL + URN 를 합친 개념
  즉, URI는 “자원을 식별하는 모든 것”, URL은 “그 자원이 어디 있는지 알려주는 것”이에요.

---

💡 정리:

• URI = 자원을 식별하는 이름표
• URL = 자원의 위치까지 알려주는 URI
• URN = 자원의 이름만 알려주는 URI

 

 

---

IT에서 **BP(Best Practice, 베스트 프랙티스)**를 줄여서 BP라고도 합니다. 즉 **“BP = Best Practice”**예요.

---

1️⃣ BP (Best Practice)

• 정의: 특정 IT 작업이나 프로젝트를 할 때 가장 효율적이고 안전하며 권장되는 방법
• 목적:
  • 오류 최소화
  • 유지보수 편리
  • 성능 최적화
• 예시:
  • 코드 관리: Git 브랜치 전략(Git Flow, GitHub Flow)
  • 보안: HTTPS 적용, 비밀번호 암호화
  • 클라우드 인프라: IaC(Infrastructure as Code) 적용
  • DB 설계: 정규화, 인덱스 활용

💡 포인트: “업계에서 입증된 최선의 방법” → 그래서 줄여서 BP라고 부르기도 합니다.

---

즉, IT에서 BP 비피라고 하면 그냥 베스트 프랙티스를 뜻하는 거예요.

 

---

**Docker Compose에서 볼륨(Volume)**의 의미를 쉽게 설명할게요.

---

1️⃣ 기본 개념

• 볼륨(Volume) = 도커 컨테이너와 호스트(컴퓨터) 간에 데이터를 영구적으로 저장하고 공유하는 공간
• 컨테이너는 기본적으로 임시 환경이에요.
  • 컨테이너 안에 파일을 저장하면, 컨테이너 삭제 시 데이터도 같이 사라집니다.
  • 하지만 볼륨을 사용하면 컨테이너가 삭제되어도 데이터는 유지됩니다.

💡 쉽게 말하면:

컨테이너 안의 파일 저장소가 “임시 방”이라면, 볼륨은 “집 밖 창고”에 데이터를 보관하는 것과 같아요.

 

---

⚛️ 리액트에서 구조 분해 할당 (Destructuring Assignment)

리액트(React)에서 **구조 분해 할당(Destructuring Assignment)**은 자바스크립트(JavaScript)의 문법으로, **객체(Object)**나 **배열(Array)**에서 필요한 값만 꺼내서 새로운 변수에 할당하는 편리한 방법입니다.

이 문법은 코드를 훨씬 간결하고 가독성 있게 만들어주기 때문에 리액트에서 매우 자주 사용됩니다.

---

1. 📝 기본 원리 및 문법

A. 배열 구조 분해

배열의 값을 순서대로 변수에 할당합니다.

JavaScript

 

const colors = ['red', 'green', 'blue'];
// 구조 분해 할당을 사용하지 않을 때
// const c1 = colors[0];
// const c2 = colors[1];

// 구조 분해 할당 사용
const [c1, c2, c3] = colors; 
console.log(c1); // 'red'

B. 객체 구조 분해

객체의 **키(Key)**와 동일한 이름의 변수를 선언하여 값을 할당합니다. 순서는 중요하지 않습니다.

JavaScript

 

const user = { name: 'Alice', age: 30, city: 'Seoul' };

// 구조 분해 할당 사용
const { name, age } = user;
console.log(name); // 'Alice'
console.log(age);  // 30
// city는 건너뛸 수 있음

---

2. 💡 리액트에서 활용되는 두 가지 핵심 사례

구조 분해 할당은 리액트의 핵심 기능인 컴포넌트의 Props와 Hooks에서 필수적으로 사용됩니다.

A. Props (속성) 처리

리액트 컴포넌트는 부모 컴포넌트로부터 props라는 하나의 객체를 전달받습니다. 이 객체에서 필요한 값들만 깔끔하게 꺼내 쓸 때 구조 분해 할당을 사용합니다.

✅ 사용 전 (불필요한 props. 반복)

JavaScript

 

function Welcome(props) {
  return <h1>Hello, {props.username}. Your score is {props.score}.</h1>;
}

✅ 사용 후 (코드가 간결해짐)

JavaScript

 

// 함수 매개변수에서 바로 구조 분해 할당
function Welcome({ username, score }) {
  return <h1>Hello, {username}. Your score is {score}.</h1>;
}

B. Hooks (상태/State) 처리

useState와 같은 리액트 훅(Hook)은 배열을 반환합니다. 이 배열의 첫 번째 요소는 상태 값이고, 두 번째 요소는 상태를 업데이트하는 함수입니다.

✅ useState에 구조 분해 할당 사용

JavaScript

 

import React, { useState } from 'react';

// useState()는 항상 [현재 상태, 상태 설정 함수] 형태의 배열을 반환
const [count, setCount] = useState(0); 

// count: 현재 상태 값 (0)
// setCount: count를 변경할 함수

---

3. ✨ 구조 분해 할당의 장점

• 가독성 향상: props.나 state.와 같은 반복적인 접두사 사용을 피할 수 있어 코드가 깔끔해집니다.
• 사용할 값 명시: 객체에서 어떤 값들을 실제로 사용할지 명시적으로 알 수 있습니다.
• 기본값 설정: 구조 분해 시 변수에 기본값(Default Value)을 쉽게 설정할 수 있습니다. (예: const { size = 'M' } = props;)

---

Next.js = 프레임워크

리액트 = 라이브러리

💻 Next.js와 React의 관계 정리

말씀해주신 구분은 웹 개발, 특히 자바스크립트 생태계에서 두 기술의 역할을 가장 정확하게 설명합니다.

1. 리액트 (React): 라이브러리 (Library)

• 정의: 사용자 인터페이스(UI)를 구축하기 위한 JavaScript 라이브러리입니다.
• 역할:
  • 오직 뷰(View) 계층만을 담당합니다. 즉, 화면에 무엇을 보여줄지(컴포넌트)를 만드는 역할에 집중합니다.
  • "어떻게 데이터를 가져올지(Fetch)?", "라우팅은 어떻게 할지?", "어떻게 서버에서 렌더링할지(SSR)?" 등에 대한 해결책은 제공하지 않습니다.
• 특징: 개발자가 원하는 기능(라우팅, 상태 관리, 데이터 요청 등)을 직접 선택하고 조합하여 앱을 만들어야 합니다.

2. Next.js: 프레임워크 (Framework)

• 정의: React를 기반으로 구축된 풀스택(Full-stack) 웹 프레임워크입니다.
• 역할:
  • React의 UI 구축 기능을 포함하면서, 대규모 애플리케이션을 만들 때 필수적인 모든 구조와 기능을 제공합니다.
  • 라우팅, 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), API 라우트(백엔드 기능), 코드 분할 등 개발에 필요한 모든 것을 "프레임(뼈대)" 안에 갖추고 있습니다.
• 특징:
  • 개발자가 정해진 규칙과 구조(컨벤션) 안에서 개발하게 하여 생산성을 높여줍니다.
  • React의 **단점(SEO 취약, 초기 로딩 속도)**을 보완하고, 엔터프라이즈급 앱 개발에 최적화된 환경을 제공합니다.

요약하자면:

• React는 "집을 지을 때 쓰는 벽돌"과 같습니다. (재료)
• Next.js는 "집을 짓는 데 필요한 설계도, 자재, 공구까지 모두 제공하는 건설 키트"와 같습니다. (구조와 환경)

Next.js는 React를 핵심 엔진으로 사용하여 완성된 애플리케이션을 구축하게 돕는 훌륭한 프레임워크입니다.

 

---

Flux 아키텍처 (Flux Architecture)

Flux는 Facebook(현 Meta)에서 개발한 소프트웨어 디자인 패턴으로, 특히 복잡한 클라이언트 사이드 웹 애플리케이션(예: React 앱)에서 데이터의 흐름을 관리하기 위해 고안되었습니다. Flux의 핵심은 **단방향 데이터 흐름(Unidirectional Data Flow)**을 강제하여 애플리케이션의 예측 가능성과 디버깅 용이성을 높이는 것입니다.

React는 뷰(View)를 렌더링하는 역할만 하기 때문에, 복잡한 앱에서 데이터 상태를 관리하기 위해 Flux와 같은 패턴이 필요해졌습니다.

---

1. 단방향 데이터 흐름의 중요성

기존 MVC(Model-View-Controller) 패턴에서는 데이터의 흐름이 양방향으로 발생하여, 하나의 데이터 변경이 여러 모델에 영향을 주면 상태 변화의 경로를 추적하기 어려워지고 버그가 발생하기 쉬웠습니다.

Flux는 이 문제를 해결하기 위해 데이터가 항상 하나의 통로를 통해서만 흐르도록 강제합니다.

2. Flux의 4가지 핵심 구성 요소

Flux 아키텍처는 다음 네 가지 구성 요소로 이루어져 있으며, 데이터는 항상 Action $\rightarrow$ Dispatcher $\rightarrow$ Store $\rightarrow$ View의 단일 경로로 흐릅니다.

1. 📢 액션 (Action)

• 역할: 애플리케이션에서 발생한 **모든 변화(이벤트)**를 캡슐화한 객체입니다.
• 특징: 무엇이 발생했는지 설명하는 **타입(Type)**과 변경에 필요한 **데이터(Payload)**를 포함합니다.
• 예시: 사용자가 "좋아요" 버튼을 눌렀을 때의 액션 (Type: LIKE_POST, Payload: { postId: 123 })

2. 🚦 디스패처 (Dispatcher)

• 역할: 모든 액션의 유일한 통로이자 중앙 허브입니다.
• 특징: 액션을 받아서 모든 스토어에게 전달(브로드캐스팅)하는 역할을 합니다. 디스패처는 한 번에 하나의 액션만 처리하도록 보장하여 복잡한 데이터 변경 순서를 단순화합니다.

3. 💾 스토어 (Store)

• 역할: 애플리케이션의 상태(State)와 비즈니스 로직을 담고 있는 곳입니다.
• 특징:
  • 특정 도메인(예: 사용자 정보, 장바구니 목록)과 관련된 모든 데이터를 관리합니다.
  • 디스패처로부터 액션을 받으면, 그 타입에 따라 자신의 상태를 변경할지 결정합니다.
  • 상태를 변경한 후에는 뷰에게 변경 사실을 알립니다(Emit Change). 직접 데이터를 외부에 노출하지 않습니다.

4. 👁️ 뷰 (View)

• 역할: 사용자 인터페이스(UI)를 담당하며, React 컴포넌트가 이 역할을 수행합니다.
• 특징:
  • 스토어로부터 상태 변화 알림을 받으면, 스토어에 직접 접근하여 변경된 데이터를 가져옵니다.
  • 가져온 데이터로 화면을 다시 렌더링합니다.
  • 사용자와의 상호작용(버튼 클릭 등)이 발생하면 새로운 액션을 생성하여 디스패처로 보냅니다.

---

3. Flux와 Redux의 관계

Redux는 Flux 패턴을 기반으로 만들어졌지만, 몇 가지 원칙을 추가하고 단순화한 라이브러리입니다.

특징	Flux	Redux
Dispatcher	자체 Dispatcher가 있음.	Dispatcher가 없음. Store가 통합하여 관리.
Store	여러 개의 도메인별 Store가 존재 가능.	오직 하나의 중앙 집중식 Store만 사용.
주요 원칙	단방향 데이터 흐름.	단일 진실의 근원(Single Source of Truth).

 

이제 리덕스로 바뀜!!!