끄적이는 개발노트

260730_강의 정리 (Dart와 Flutter 2)

크런키스틱 — Thu, 30 Jul 2026 09:26:16 +0900

mobile · flutter

Flutter와 Dart 정리 — Widget, State, Lifecycle

Dart 기반 크로스플랫폼 GUI 프레임워크, Widget 트리로 UI 구성
StatelessWidget vs StatefulWidget, setState()로 리빌드 제어
Widget Lifecycle과 BuildContext로 화면 생명주기 관리

1. Dart 언어와 Flutter 개요

Dart 기반으로 동작하는 GUI 프레임워크 — 하나의 코드로 여러 플랫폼 대응

GUI programming — 그래픽 기반 사용자 인터페이스 구성
Event based programming — 사용자 입력(터치, 클릭)에 반응하는 방식
Component(Widget) based programming — 모든 UI 요소를 위젯 단위로 조립
Object-oriented programming — 클래스와 객체 기반 설계
Cross platform — 하나의 코드베이스로 iOS/Android/Web 대응
AOT/JIT 컴파일 지원 — 개발 중엔 JIT(Hot Reload), 배포 시엔 AOT(고속 실행)

새 개념

JIT / AOT 컴파일 Just-In-Time / Ahead-Of-Time

JIT — 개발 중 실시간 컴파일, Hot Reload 가능
AOT — 배포 전 네이티브 코드로 미리 컴파일, 실행 속도 빠름

개발할 땐 JIT로 빠르게 수정 확인, 앱스토어 배포 시엔 AOT로 빌드

변수 선언 키워드 dynamic / var / final / const

dynamic — 타입 자유, 런타임에 타입 결정
var — 선언 시 타입 추론, 이후 타입 고정
final — 런타임에 한 번 값 할당 후 불변
const — 컴파일 타임에 값이 정해지는 완전한 상수

final은 실행 중 계산된 값 저장 가능, const는 실행 전부터 값이 고정돼야 함

Dart는 컴파일 방식을 상황에 따라 전환하며, 개발 속도(JIT)와 실행 속도(AOT)를 동시에 확보하는 전략을 씀

2. Widget 기본 개념

Flutter의 모든 화면 요소는 Widget이다 — 데이터 표현, 레이아웃, 스타일, 위치 정렬까지 전부 위젯으로 처리

display 데이터 표현 위젯

화면에 보여줄 실제 콘텐츠를 담당

Text, Image, Icon, Card, ListView, DataTable, Checkbox, Radio

layout 레이아웃 위젯

다른 위젯들을 배치하는 뼈대 역할

Row, Column, Scaffold, Stack

style 스타일 위젯

텍스트나 색상 등 시각적 속성 지정

TextStyle, Color

align 정렬 위젯

자식 위젯의 위치와 여백을 조정

Center, Padding

위젯은 "화면에 보이는 모든 것"이라고 이해하면 됨 — 텍스트 한 줄도, 버튼도, 화면 전체 레이아웃도 위젯

⚖️

3. StatelessWidget vs StatefulWidget

"상태(데이터)가 바뀌는가?" — 두 위젯을 가르는 기준

구분	StatelessWidget	StatefulWidget
상태 변경	불가능 (한 번 그려지면 고정)	가능 (setState()로 재빌드)
사용 예	고정 텍스트, 아이콘	카운터, 폼 입력, 애니메이션
내부 구조	build()만 존재	State 객체 별도 존재

새 개념

setState()

상태 값을 변경하고 Flutter에게 "다시 그려야 한다"고 알리는 함수
호출 시 dirty flag가 true로 바뀌며 build() 재실행 트리거

카운터 앱에서 버튼 클릭 시 setState(() => count++)로 화면 숫자 갱신

StatefulWidget 다이어그램에서 STATE가 Widget model을 감싸는 구조로 표현되는 이유는, 위젯 자체는 불변이고 State 객체가 별도로 값을 들고 있다가 재빌드를 트리거하기 때문

4. Widget Tree와 BuildContext

위젯들은 부모-자식 관계의 트리 구조로 조립되며, 각 위젯은 자신의 트리 위치 정보(BuildContext)를 가짐

Scaffold

화면 전체 뼈대, 하위에 여러 named parameter를 가짐

appBar 파라미터 → AppBar 위젯

화면 상단 바 영역 지정

body 파라미터 → Center → Column → Text

중첩 레이아웃 — Center 안에 Column, 그 안에 Text

floatingActionButton 파라미터 → FloatingActionButton → Icon

화면 우하단 플로팅 버튼과 그 안의 아이콘

AppBar, Center, FloatingActionButton은 서로 형제 위젯이 아니라, Scaffold의 서로 다른 이름 붙은 파라미터(appBar:, body:, floatingActionButton:)에 각각 들어가는 구조임 — 나란히 그려져 있어도 병렬 관계가 아님

새 개념

BuildContext

위젯이 트리 안 어디에 위치하는지를 나타내는 참조 객체
부모 위젯 정보 탐색, 테마·미디어쿼리 접근 등에 사용

Navigator.of(context).push(...)처럼 항상 context를 통해 트리 정보에 접근

5. Widget Lifecycle

StatefulWidget은 생성부터 소멸까지 정해진 순서의 생명주기를 거침

createState()

StatefulWidget으로부터 State 객체 생성

initState()

State 객체 초기화, 최초 1회만 실행

didChangeDependencies()

의존 데이터 변경 시 호출

build()

실제 UI 렌더링, dirty=true일 때마다 재실행

setState() / didUpdateWidget()

상태 변경 시 dirty=true로 전환 → build() 재호출

deactivate()

트리에서 일시적으로 제거될 때

dispose()

완전히 제거, 리소스 정리 (mounted=false)

dirty flag가 true가 되는 경로는 두 가지 — setState() 직접 호출, 또는 부모 위젯이 재빌드되며 didUpdateWidget()이 호출되는 경우

6. Navigator와 화면 전환

화면 이동은 Stack(스택) 구조로 관리됨

Navigator — 화면(Route)들을 스택 형태로 관리하는 객체
push — 새 화면을 스택 위에 쌓음
pop — 현재 화면을 스택에서 제거하고 이전 화면으로 복귀

새 개념

Hot Reload vs Hot Restart

Hot Reload — 코드 변경분만 반영, 상태(State) 유지, 수 초 내 반영
Hot Restart — 앱 전체 재시작, 상태 초기화

UI 스타일만 바꿀 땐 Hot Reload, 초기화 로직 바꿀 땐 Hot Restart

정리
· Flutter는 "모든 것이 Widget"이라는 원칙 위에 설계됨
· StatelessWidget/StatefulWidget 구분, Widget Tree 구조, Lifecycle 흐름이 서로 맞물려 동작

260729_강의 정리 (Dart와 Flutter)

크런키스틱 — Thu, 30 Jul 2026 09:22:03 +0900

flutter · dart

Dart 언어와 Flutter, Fuchsia 정리

Dart 언어의 핵심 특징과 문법 요소
Dart와 Flutter의 관계
구글의 실험적 프로젝트, Fuchsia 개요

1. Dart는 어떤 언어인가

Flutter를 구동하는 구글의 크로스 플랫폼 언어

크로스 플랫폼 지원 — Web, Mobile, Desktop, Server 모두 대응
객체 지향 프로그래밍 기반 — Java·C#처럼 모든 것이 객체
C처럼 main() 함수로 실행 시작
클래스 기반 + 함수 기반 프로그래밍 모두 가능 (함수도 일급객체)

새 개념

일급객체 First-class function

함수를 변수에 담거나 다른 함수의 인자로 전달할 수 있는 성질

var add = (int a, int b) => a + b;

Dart는 정적 언어의 안정성과 동적 언어의 유연성을 함께 노리는 하이브리드 언어임

2. 타입 시스템 — var, final, dynamic

정적 타입과 동적 타입을 함께 지원하는 하이브리드 구조

var — 타입을 추론한 뒤 이후 타입이 고정됨
final — 런타임에 한 번만 값이 할당되는 불변 변수
dynamic — 타입 검사를 생략하는 완전 동적 타입

새 개념

Null Safety Null 안정성

? — nullable 타입임을 표시
! — 값이 null이 아님을 단언
late — 나중에 초기화될 값임을 선언

String? name; // null 허용 → String name2 = name!;

3. 기능 재사용 — extension, mixin, interface

코드를 상속 없이도 확장하고 재사용하는 세 가지 방법

새 개념

extension 기존 클래스 확장

이미 만들어진 클래스에 새 기능을 나중에 추가하는 문법

extension StringExt on String { bool get isEmail => contains('@'); }

mixin 다중 상속 대체

여러 클래스가 동일한 코드를 공유할 수 있게 해주는 문법

class Bird with Flying { }

interface 암묵적 인터페이스

Dart는 별도 키워드 없이 모든 클래스가 인터페이스 역할을 겸함

class Duck implements Flyable { }

Dart에는 interface 키워드가 따로 없고, 모든 클래스가 암묵적으로 인터페이스가 됨 — implements로 구현함

4. 자료구조 & 비동기 처리

다양한 컬렉션 타입과 비동기 처리 문법을 지원함

자료구조 — List, Set, Map, Queue, LinkedList, HashSet, HashMap
비동기 처리 — Future, Stream, async / await

새 개념

Future vs Stream 비동기 반환 방식

Future — 한 번의 비동기 결과값을 반환
Stream — 여러 번에 걸쳐 연속적으로 값을 반환

Future<String>은 결과 1개, Stream<int>는 연속된 값의 흐름

⚙️

5. 컴파일 방식 — JIT + AOT

개발 중엔 빠르게, 배포할 땐 최적화되게

개발 단계

→

JIT 컴파일

→

핫 리로드로 즉시 확인

배포 단계

→

AOT 컴파일

→

네이티브 코드로 최적화

새 개념

JIT Just-In-Time

실행 중에 컴파일하여 코드 변경 사항을 빠르게 반영 (핫 리로드)

AOT Ahead-Of-Time

실행 전에 미리 컴파일하여 실행 속도를 최적화

이 두 방식을 함께 지원하기 때문에 Flutter는 빠른 개발 속도와 빠른 실행 속도를 동시에 챙길 수 있음

6. Dart → Flutter, 그리고 Fuchsia

Dart 위에 세워진 두 개의 그림 — Flutter와 Fuchsia

Dart

→

Flutter (크로스 플랫폼 UI 프레임워크)

→

Window Programming (전통적 네이티브 개발 방식)

Flutter 특징 — GUI 프로그래밍 / 컴파일 기반 / 객체 지향 / 이벤트 기반 / 컴포넌트 기반 / 크로스 플랫폼
pub.dev — Dart의 패키지 생태계, npm과 유사한 역할

Fuchsia는 구글이 실험 중인 프로젝트로, 원래는 Dart 기반 차세대 범용 OS를 목표로 했으나 현재는 Nest Hub 등 일부 기기에 한정 적용된 상태임

260723_강의 정리 (Redux, JWT)

크런키스틱 — Thu, 23 Jul 2026 16:09:29 +0900

Frontend · Auth

Redux 상태 관리와 RBAC · JWT 인증 정리

Redux의 단방향 데이터 흐름과 useDispatch / useSelector 동작 원리
역할 기반 접근 제어(RBAC)의 3요소 구조
JWT의 Header.Payload.Signature 구조와 토큰 저장 전략

1. Redux 데이터 흐름

"React 컴포넌트끼리 데이터를 주고받는 규칙을 하나로 통일한 것" — 전역 상태 관리 라이브러리

Action: 무슨 일이 일어났는지 정의하는 객체 (type + payload)
Reducer: Action을 받아 새로운 State를 계산하는 순수 함수
Store: 앱 전체의 State를 보관하는 단일 저장소
View Component: Store를 구독하고 화면에 렌더링

View Component → Action 발송

useDispatch 훅으로 Action을 Store에 전달

Reducer가 새 State 계산

Action 타입에 따라 이전 State를 기반으로 새 State 반환

Store 업데이트

계산된 새 State로 Store 내부 값 교체

구독 컴포넌트 리렌더링

useSelector로 구독 중인 컴포넌트만 자동으로 다시 그려짐

새 개념

useDispatch hook

컴포넌트에서 Action을 Store로 보내는 훅

"편지를 보내는 우체통" 역할

useSelector hook

Store의 State 중 필요한 부분만 선택해 구독하는 훅

"진열대에서 원하는 물건만 골라 담는 것"

Provider (등록 과정)

<Provider store={'{'}store{'}'}>로 React 앱 최상단을 감싸 하위 모든 컴포넌트가 Store에 접근 가능하게 함

다이어그램의 Store → ReactDOM "등록" 화살표가 이 과정

Redux는 메모리(런타임) 상태 관리 도구일 뿐, 새로고침하면 초기화됨 → 영구 저장은 별도 처리 필요

2. Redux와 영구 저장소

Redux 자체는 영구 저장이 불가능 — 브라우저 저장소와 연동해야 데이터가 유지됨

저장소	특징	주의점
localStorage	만료 없음, 용량 약 5~10MB	JS로 직접 접근 가능 → XSS 취약
sessionStorage	탭 닫으면 자동 소멸	임시 데이터용, 탭 간 공유 불가
Cookie	요청마다 서버로 자동 전송	HttpOnly 설정 시 XSS 방어, 단 CSRF 주의 필요
IndexedDB	대용량·구조화 데이터에 적합	비동기 API, 사용법이 상대적으로 복잡

인증 토큰 저장 시 유의
· localStorage는 JS로 접근 가능해 XSS 공격에 취약
· HttpOnly Cookie가 상대적으로 안전한 선택지로 많이 사용됨

새 개념

redux-persist middleware

Redux State를 localStorage 등 브라우저 저장소에 자동으로 동기화해주는 미들웨어

→ 새로고침해도 로그인 상태 등이 유지되도록 함

3. RBAC (Role Based Access Control)

"역할에 따라 접근 권한을 다르게 부여하는 방식" — 사용자 개별이 아닌 역할 단위로 권한을 관리

User(Role)

→

Permission(Group)

→

Resource

새 개념

User(Role)

사용자에게 역할을 부여 (예: admin, editor, viewer)

Permission(Group)

역할에 묶인 권한 집합 (예: 읽기, 쓰기, 삭제)

Resource

권한이 적용되는 대상 (예: 게시글, 회원정보)

사용자마다 권한을 개별 설정하지 않고 역할 단위로 관리 → 확장성과 유지보수성 확보

4. JWT (JSON Web Token)

"로그인 정보를 서버가 저장하지 않고도 검증할 수 있게 만든 토큰" — Stateless 인증 방식

구조: Header.Payload.Signature (Base64URL 인코딩, 점으로 구분)

Header

Payload

Signature

새 개념

Header

알고리즘 및 토큰 타입 정보 (원본 슬라이드에서 Payload로 오기됨 → 수정)

Payload

사용자 데이터 및 Claims (예: user_id, exp)

Signature

발신자 인증 + 무결성 검증 — 비밀키로 서명해 위변조 여부 확인

simplejwt djangorestframework-simplejwt

Django REST Framework용 JWT 발급·검증 라이브러리

백엔드에서 로그인 시 Access/Refresh 토큰 발급을 담당

JWT는 암호화(encryption)가 아닌 인코딩(encoding) — Payload는 디코딩하면 누구나 읽을 수 있어 민감 정보 저장 금지

5. 종합 정리

Redux · 클라이언트 상태 관리

RBAC · 서버 권한 체계

JWT · 인증 토큰 형식

로그인

→

JWT 발급

→

저장(Cookie 등)

→

요청 시 토큰 전송

→

RBAC 권한 확인

→

리소스 접근 허용

Redux, RBAC, JWT는 서로 별개 개념이지만 실무 인증 흐름에서 자연스럽게 함께 사용됨

260722_강의 정리 (Component Lifecycle)

크런키스틱 — Wed, 22 Jul 2026 09:34:11 +0900

frontend · react

React Component Lifecycle — Class와 Hooks 대응 정리

Render phase와 Commit phase로 나뉘는 이유
Class의 3단계 lifecycle이 useEffect 하나로 통합되는 원리
props drilling 문제와 useContext를 통한 해결

⚙️

1. Lifecycle 개요 — Render phase vs Commit phase

React는 렌더링을 왜 두 단계로 나누는가?

Render phase — 현재 state를 기반으로 화면 구성을 계산하는 단계
Commit phase — 계산된 결과를 실제 DOM에 반영하는 단계

새 개념

Render phase

순수 계산만 수행, side effect(DOM 조작·API 호출 등) 금지
중단·재시작이 가능해 우선순위 높은 작업이 끼어들 수 있음

→ constructor, getDerivedStateFromProps, shouldComponentUpdate, render

Commit phase

계산 결과를 실제 DOM에 반영, side effect 허용
한번 시작하면 중단 없이 끝까지 실행됨

→ componentDidMount, componentDidUpdate

️

2. Class 컴포넌트의 3단계 Lifecycle

Mounting → Updating → Unmounting 순서로 진행되는 컴포넌트 생애주기

Mounting

constructor → getDerivedStateFromProps → shouldComponentUpdate → render → componentDidMount

Updating

New props / setState() / forceUpdate() 발생 → 동일 render 경로 재실행 → componentDidUpdate

Unmounting

componentWillUnmount — 컴포넌트 제거 직전 정리 작업 수행

메서드	역할
getDerivedStateFromProps	props 변경에 따라 state를 동기화 (드물게 사용)
shouldComponentUpdate	불필요한 리렌더링을 막는 최적화용 훅, false 반환 시 render 생략

3. Hooks로의 통합 — useState & useEffect

3단계 Class lifecycle이 Hooks에서는 어떻게 하나로 합쳐지는가?

useState — constructor에서의 state 초기화 역할을 대체
useEffect — componentDidMount + componentDidUpdate + componentWillUnmount를 하나의 Hook으로 통합

Class lifecycle	대응 Hook
constructor (state 초기화)	useState
componentDidMount	useEffect(fn, [])
componentDidUpdate	useEffect(fn, [deps])
componentWillUnmount	useEffect 내부 cleanup(return) 함수

Class는 목적별로 메서드가 나뉘지만, Hooks는 하나의 useEffect가 의존성 배열에 따라 여러 역할을 수행함

⏱️

4. useEffect 실행 조건 3가지

두 번째 인자(의존성 배열)에 따라 실행 시점이 달라짐

형태	실행 시점
useEffect(() => {...})	매 렌더링마다 실행 (최초 마운트 포함)
useEffect(() => {...}, [])	최초 1회만 실행 — componentDidMount 대응
useEffect(() => {...}, [a, b])	a 또는 b가 변경될 때만 실행 — 선택적 componentDidUpdate

새 개념

Cleanup 함수 useEffect 내부 return

다음 effect 실행 직전, 또는 컴포넌트 unmount 시 호출되는 정리 함수
componentWillUnmount와 동일한 역할 수행

→ useEffect(() => { const id = setInterval(...); return () => clearInterval(id); })

️

5. Hook 생태계 3대 기능 구역

역할에 따라 크게 세 구역으로 분류할 수 있음

구역	포함 Hook
상태 관리 (State Management)	useState useReducer useContext
사이드 이펙트 제어 (Side Effects)	useEffect
성능 최적화 및 참조 (Optimization & Refs)	useMemo useCallback useRef

1강에서 다룬 useContext + useReducer 결합 패턴은 모두 상태 관리 구역 안에서의 조합임

6. Events Handler — App ↔ Virtual DOM ↔ DOM

이벤트와 렌더링 결과가 양방향으로 오가는 흐름

DOM (이벤트 발생)

→

Virtual DOM

→

App (상태 반영)

App (상태 변경)

→

Virtual DOM

→

DOM (갱신)

양방향 흐름이지만, DOM에 실제 반영될 때는 1강에서 다룬 Diffing을 거쳐 변경분만 최소 적용됨

️

7. Props Drilling 문제

props를 여러 단계 거쳐 전달해야 할 때 생기는 문제는?

최상위 컴포넌트의 데이터를 하위 컴포넌트까지 전달하기 위해, 중간 컴포넌트들이 사용하지도 않는 props를 계속 릴레이해야 하는 상황
트리가 깊어질수록 중간 컴포넌트 코드가 불필요하게 복잡해짐

해결책
· 1강에서 다룬 useContext가 대표적 해결 방법 — 중간 단계 없이 필요한 컴포넌트에 직접 데이터 전달 가능

260722_강의 정리 (개발환경, JSX, Virtual DOM 정리)

크런키스틱 — Wed, 22 Jul 2026 09:30:02 +0900

frontend · react

React 시작하기 — 개발환경, JSX, Virtual DOM 정리

WSL 기반 개발환경 세팅부터 컴포넌트 개념까지 정리
JSX가 실제 브라우저에서 동작하는 원리(Babel 트랜스파일)
Virtual DOM이 빠른 진짜 이유 — Diffing(재조정) 과정

️

1. 개발 환경 세팅

React 프로젝트를 시작하기 전 필요한 기본 도구들 설치 순서

Windows 환경에서는 WSL(Windows Subsystem for Linux) 위에 Ubuntu 22.04 LTS를 설치해 리눅스 개발환경 구성
Ubuntu 위에 Node.js 설치 → JavaScript를 브라우저 밖(서버·터미널)에서 실행 가능하게 함
Node.js 설치 시 함께 제공되는 npm(Node Package Manager)으로 라이브러리 설치·관리
프로젝트 루트의 package.json이 설치된 패키지 목록과 버전, 실행 스크립트 관리

새 개념

WSL Windows Subsystem for Linux

Windows 안에서 리눅스 커널을 직접 실행하는 호환 계층

가상머신 없이 Windows에서 Ubuntu 명령어를 그대로 사용

npm Node Package Manager

Node.js용 패키지(라이브러리) 설치·버전 관리 도구

→ npm install react 명령으로 React 라이브러리 설치

2. HTML programming vs React

"HTML template를 React가 왜, 어떻게 대체하는가?"

기존 HTML programming — 태그 기반, GUI 기반, 이벤트 기반으로 화면 구성
React는 컴포넌트 기반(Component base) 프로그래밍 방식
컴포넌트 구성 요소: Props(속성), State(상태), JSX(마크업), Side effect(부수효과)

구현 방식	특징
Class 컴포넌트	ES6 class 문법 기반, this 바인딩 필요, 생명주기 메서드 사용
Function + Hooks	함수 문법 기반, useState·useEffect 등 Hook으로 상태·부수효과 관리, 코드 간결

현재 권장 방식
· React 공식 문서 기준 신규 프로젝트는 Function 컴포넌트 + Hooks 방식을 권장함

3. JSX — JS와 HTML의 결합

"브라우저는 JSX를 못 읽는데 어떻게 동작하는가?"

JavaScript 문법 안에 HTML과 유사한 태그를 직접 작성하는 방식 = JSX
브라우저는 JSX 문법을 이해하지 못하므로 그대로 실행 불가
Babel이 빌드 시점에 JSX를 순수 JavaScript 함수 호출로 변환

JSX 코드

→

Babel 변환

→

React.createElement() 호출

→

브라우저 실행

새 개념

JSX JavaScript XML

JS 안에서 HTML과 유사한 태그 문법을 쓸 수 있게 해주는 확장 문법

→ <div>Hello</div> 형태로 JS 안에 마크업 작성

Babel JS 트랜스파일러

최신 문법(JSX 포함)을 구버전 브라우저도 이해할 수 있는 JS로 변환

→ <div>Hello</div> → React.createElement('div', null, 'Hello')

4. 빌드 도구 & SPA

React 코드를 실제 배포 가능한 형태로 묶어주는 도구들

React + Babel + 번들러 조합으로 개발 진행 (React: UI 라이브러리, Babel: 문법 변환, 번들러: 파일 묶음)

도구	역할
webpack	모듈 번들러, 설정 자유도 높지만 초기 빌드 속도 느린 편
Vite	개발 시 esbuild로 빠른 서버 구동, 프로덕션 빌드 시 Rollup 사용
Rollup	라이브러리 번들링에 특화, 트리 셰이킹 우수
esbuild	Go로 작성된 초고속 번들러/트랜스파일러

새 개념

SPA Single Page Application

페이지 전체를 새로 불러오지 않고, 클라이언트 측에서 필요한 부분만 갱신하며 라우팅·렌더링

→ 메뉴 클릭 시 화면 깜빡임 없이 콘텐츠만 바뀌는 방식

5. Virtual DOM ↔ Real DOM

"왜 Virtual DOM을 쓰면 빠른가?"

이벤트 발생

클릭 등 사용자 이벤트로 setState / useEffect / useContext / useReducer 트리거

Virtual DOM 갱신

변경된 state를 반영한 새로운 Virtual DOM 트리를 메모리 상에 생성

Diffing(재조정)

이전 Virtual DOM과 새 Virtual DOM을 비교해 실제로 바뀐 부분만 찾아냄

Real DOM 반영

변경분만 실제 DOM에 적용 → 불필요한 전체 리렌더링 방지

새 개념

Virtual DOM 가상 DOM

실제 DOM 구조를 JS 객체 형태로 메모리에 복제해 둔 것

→ 실제 DOM 조작보다 메모리 상 객체 비교가 훨씬 빠름

Diffing Reconciliation, 재조정

이전·이후 Virtual DOM 트리를 비교해 최소한의 변경 지점만 찾아내는 알고리즘

→ 리스트 100개 중 1개만 바뀌었다면 그 1개만 Real DOM에 반영

useRef Real DOM 직접 참조

Virtual DOM을 거치지 않고 실제 DOM 요소에 직접 접근해야 할 때 사용

→ input 포커스 강제 이동, 스크롤 위치 제어 등에 활용

Virtual DOM 자체가 빠른 게 아니라, Diffing으로 필요한 부분만 갱신하는 전략이 성능의 핵심임

6. Component Tree, Props & State

컴포넌트는 트리 구조로 중첩되며, Props와 State로 데이터를 관리함

Component Tree — 부모 컴포넌트가 자식 컴포넌트를 포함하는 계층 구조
부모 → 자식 방향으로 Props 전달, 각 컴포넌트는 자체 State 보유 가능

구분	Props	State
방향	부모 → 자식으로 전달	컴포넌트 내부에서 자체 관리
변경 가능 여부	읽기 전용(수정 불가)	가변(useState 등으로 변경)
역할	외부에서 주입되는 설정값	컴포넌트 자체의 동적 데이터

React는 단방향 데이터 흐름(one-way data flow)을 따름 — 데이터는 항상 부모에서 자식으로만 전달되어 흐름 추적이 쉬움

7. 전역 상태 관리 — useContext + useReducer 결합

"Redux 없이 전역 상태를 어떻게 관리할까?"

useContext — 컴포넌트 트리 깊숙한 곳까지 props 없이 데이터 전달
useReducer — 복잡한 상태 변경 로직을 reducer 함수로 분리 관리
두 Hook을 결합하면 Redux와 유사한 전역 상태관리 패턴 구현 가능

활용 팁
· 소규모~중간 규모 프로젝트에서 별도 라이브러리 설치 없이 Redux 대체 수단으로 활용 가능

260710_강의 정리 (TCGA, TCIA, CRDC로 보는 암 유전체 데이터 플랫폼 정리)

크런키스틱 — Sat, 11 Jul 2026 04:02:31 +0900

bioinformatics · genomics

TCGA, TCIA, CRDC로 보는 암 유전체 데이터 플랫폼 정리

NCI(국립암연구소)가 제공하는 분자·영상·임상 데이터 생태계
TCGA(분자) · TCIA(영상)를 잇는 Radiogenomics 개념
DNA→RNA→단백질→대사체로 이어지는 오믹스 4단계와 CRDC 통합 플랫폼

️

1. NCI 개요

"암 연구 데이터를 누구나 접근할 수 있게" — 미국 NIH 산하 국립암연구소가 운영하는 공개 데이터 생태계

NIH(National Institutes of Health) 산하 기관인 NCI(National Cancer Institute)가 운영
대표 사이트 cancer.gov를 통해 다양한 암 연구 데이터베이스 제공
분자 수준(Micro)부터 영상 수준(Macro)까지 암을 여러 층위에서 데이터화해 연구자에게 개방함

이후 섹션에서 다룰 TCGA(분자)·TCIA(영상)·CRDC(통합 플랫폼)가 모두 이 생태계 안에 속해 있음

2. TCGA vs TCIA — 두 축의 데이터

같은 암을 서로 다른 '해상도'로 바라보는 두 데이터베이스

TCGA

The Cancer Genome Atlas

세포 안에서 무슨 일이 일어나는지를 '문자 서열'로 기록한 데이터

분자생물학적·세포적 관점(Micro)의 데이터베이스
파일 포맷: FASTQ BAM VCF CSV/TXT
포함 데이터: DNA, RNA, Proteomics, Metabolomics

TCIA

The Cancer Imaging Archive

몸 전체 또는 조직 수준에서 암이 '어떻게 보이는지'를 이미지로 기록한 데이터

형태학적·병리학적 관점(Macro)의 데이터베이스
파일 포맷: DICOM (의료영상 국제 표준 포맷)
포함 데이터: MRI, CT, digital histopathology(디지털 병리 슬라이드) 등

새 개념

FASTQ / BAM / VCF Sequencing File Formats

FASTQ: 시퀀서가 읽어낸 원본 염기서열 + 품질점수
BAM: FASTQ를 참조 유전체에 정렬(align)한 결과
VCF: 정렬 결과에서 추출한 변이(variant) 정보만 모은 파일

→ FASTQ(원재료) → BAM(가공) → VCF(핵심 결과물) 순으로 점점 정제됨

DICOM Digital Imaging and Communications in Medicine

MRI·CT 등 의료영상을 저장·전송하기 위한 국제 표준 포맷
영상 데이터 + 촬영 장비·환자 정보 등 메타데이터를 함께 담음

→ 병원마다 장비가 달라도 DICOM 덕분에 영상을 공통 형식으로 주고받을 수 있음

3. Radiogenomics — 두 관점을 잇는 다리

"영상에서 보이는 암의 형태가, 유전자 수준의 어떤 변화와 대응되는가?"

TCGA(분자 데이터)와 TCIA(영상 데이터)를 연결하는 융합 연구 분야
예시: CT 영상에서 종양 경계가 불규칙한 패턴이 특정 유전자 변이와 상관관계를 보이는지 분석
의의: 침습적인 생검(biopsy) 없이 영상만으로 분자적 특성을 예측하려는 시도 → '영상 바이오마커' 개발로 이어짐

TCGA (분자)

→

Radiogenomics

→

TCIA (영상)

비유: 혈액검사(분자)와 X-ray(영상)를 따로 보지 않고, 두 결과가 서로 어떤 관계인지 함께 분석하는 것과 비슷함

4. 오믹스(Omics) 4단계

분자생물학의 중심원리(Central Dogma): DNA → RNA → 단백질 순으로 유전정보가 흐름 — 각 오믹스는 이 흐름의 서로 다른 단계를 포착하는 스냅샷

DNA — Genomics (유전체)

타고난 유전 정보, 돌연변이 존재 여부를 담고 있음 · 대표 기법: WGS(전장유전체시퀀싱), WES(엑솜시퀀싱)

RNA — Transcriptomics (전사체)

유전자가 실제로 '발현'되고 있는 정도를 나타내며 BioMarker로 활용됨 · 세포 안팎의 환경 변화나 스트레스, 질병 상태를 반영 · 대표 기법: RNA-seq, microarray

단백질 — Proteomics (단백체)

세포 내 공장(리보솜)에서 번역(Translation)되어 만들어진 최종 기능 분자 · 대표 기법: Mass spectrometry(질량분석)

대사체 — Metabolomics (대사체)

포도당·아미노산·지질·젖산 등 대사산물 · 생명체의 '현재 건강 상태'와 '실제 표현형(Phenotype)'을 드러냄 · 대표 기법: NMR, LC-MS

비유: DNA가 '요리 레시피'라면, RNA는 '지금 만들고 있는 요리의 주문서', 단백질은 '실제 완성된 요리', 대사체는 '그 요리를 먹은 후 몸에 남는 흔적'. DNA는 잘 변하지 않지만 뒤로 갈수록 실시간 변화에 민감해짐

5. 환자 임상 데이터 — EMR과 HL7 FHIR

분자·영상 데이터뿐 아니라 임상 기록도 표준화가 필요함

새 개념

EMR Electronic Medical Record

병원에서 관리하는 환자의 진단·처방·검사 이력 등 디지털 기록

HL7 FHIR Fast Healthcare Interoperability Resources

서로 다른 병원·시스템 간 EMR 데이터를 표준화된 형식으로 주고받기 위한 국제 프로토콜

→ 유전체 데이터가 FASTQ·DICOM으로 표준화되듯, 임상 데이터도 FHIR로 표준화되어야 다기관 연구가 가능해짐

️

6. CRDC — 통합 데이터 플랫폼

CRDC(Cancer Research Data Commons)는 TCGA·TCIA 등 개별 데이터베이스를 하나의 플랫폼으로 통합해 제공함

약어	풀네임	설명
GDC	Genomic Data Commons	유전체 데이터(TCGA 등) 통합 저장소
PDC	Proteomic Data Commons	단백체 데이터 저장소
IDC	Imaging Data Commons	영상 데이터(TCIA 등) 저장소
SB	Seven Bridges (CGC)	클라우드 기반 분석 환경 제공 — 데이터를 다운로드하지 않고도 분석 가능

접근 방법: Download(대용량 파일 직접 다운로드) 또는 Search(조건별 탐색) 기능 제공
TCIA 데이터는 별도로 "TCIA Data Retriever" 도구를 통해 다운로드해야 함

정정 사항
· 원본 표에 있던 "GC = Genomic Data Commons" 항목은 GDC와 동일 대상을 가리키는 중복 기재로 판단되어, 위 표에서는 GDC 한 줄로 통합함

전체 요약
· TCGA(분자) + TCIA(영상) + EMR(임상) 데이터가 각기 다른 해상도로 암을 기록함
· Radiogenomics는 분자와 영상 데이터를 잇는 융합 연구 분야
· DNA→RNA→단백질→대사체 오믹스 4단계는 Central Dogma를 따라 세포 상태를 점점 더 실시간으로 반영함
· 이 모든 데이터는 CRDC 플랫폼(GDC·PDC·IDC·SB)에서 통합적으로 접근 가능함

260709_강의 정리 (Transformer 구조와 LLM)

크런키스틱 — Thu, 9 Jul 2026 17:00:10 +0900

deep learning · llm

Transformer 구조와 LLM Agent 생태계 정리

Encoder-only(BERT)와 Decoder-only(GPT) 구조의 차이와 GPT-3의 실제 스케일
Agent와 Agentic의 개념 구분, Agent를 구성하는 핵심 요소
LangChain · LangGraph · LlamaIndex 3종 프레임워크의 역할 비교

1. Transformer 구조 복습 — Encoder vs Decoder

"같은 Transformer인데 왜 BERT는 이해를 잘하고 GPT는 생성을 잘할까" — 구조를 반쪽만 쓰느냐의 차이임

Transformer는 원래 Encoder와 Decoder가 함께 있는 구조로 설계됨
Encoder-only 모델(BERT): 문장 전체를 양방향으로 한 번에 읽어 문맥을 파악 → 분류, 검색, 임베딩 생성에 강함
Decoder-only 모델(GPT): 왼쪽에서 오른쪽으로 순차적으로 다음 단어를 예측 → 텍스트 생성에 특화됨

새 개념

Encoder / Decoder Encoder / Decoder

Encoder는 입력을 양방향으로 이해하는 역할, Decoder는 출력을 순차적으로 만들어내는 역할

Encoder는 "책 한 권을 다 읽고 이해하는 독자", Decoder는 "한 글자씩 이어 쓰는 작가"에 비유됨

GPT-3의 스케일 d_model, layers, heads

파라미터 수: 약 1,750억 개
hidden dimension(d_model): 12,288 — 단어 하나가 12,288차원 벡터로 표현됨
레이어 수: 96개, attention head: 96개(head당 128차원)

→ d_model = 12,288 은 GPT-3가 각 단어를 얼마나 "풍부한 벡터"로 표현하는지를 나타내는 수치

정리
· 같은 Transformer 구조라도 Encoder만 쓰느냐 Decoder만 쓰느냐에 따라 모델의 특기가 갈림
· GPT-3의 압도적인 스케일(12,288차원 × 96레이어)이 오늘날 LLM Agent가 가능해진 기반이 됨

2. LLM Agent란 무엇인가

"한 번 물어보고 한 번 답하는 것"과 "알아서 계획하고 스스로 고쳐가며 일하는 것"의 차이임

Agent(에이전트): 역할·목표·도구(Tools)를 가지고 스스로 작업을 수행하는 독립적인 소프트웨어 시스템
일반 LLM 호출과 달리 계획 → 실행 → 검토 → 수정을 여러 단계에 걸쳐 스스로 반복하는 자율적 프로세스를 가짐
Agent vs Agentic: Agent는 자율 작업을 수행하는 시스템 자체를 가리키고, Agentic은 그 시스템이 "얼마나 자율적으로 계획·판단·행동하는지"의 성질을 가리킴

새 개념

Agent의 3요소 Role · Tools · Memory

Role/Goal — 무엇을, 왜 하는지에 대한 정의
Tools — 외부 API, 검색, 코드 실행 등 실제 행동 수단
Memory — 이전 상호작용이나 중간 결과를 기억하는 저장소

→ 세 요소가 있어야 Agent가 "한 번의 답변"이 아니라 "여러 단계짜리 작업"을 이어갈 수 있음

RAG Retrieval-Augmented Generation

LLM이 답변을 만들기 전에 외부 데이터를 먼저 검색하고, 그 내용을 근거로 답을 생성하는 방식

→ 시험 볼 때 책을 펼쳐놓고 답을 쓰는 오픈북 방식에 가까움 — LLM이 학습하지 않은 최신 정보나 사내 문서 기반 답변에 필수적

계획

→

실행

→

검토

→

수정

️

3. Agent 프레임워크 3종 비교

셋은 경쟁 관계가 아니라 서로 다른 레이어를 담당하는 도구임

LangChain

범용 Agent 개발 플랫폼

"이 모듈이 하는 일을 한 문장으로" — Agent + Tools + Memory + RAG를 자유롭게 조합하는 재료 서랍

Agent, Tools, Memory, RAG를 자유롭게 조합해 구성 가능
커버 범위가 가장 넓은 대신, 복잡한 흐름을 세밀하게 제어하는 기능은 상대적으로 약함

LangGraph

상태머신형 Agent 흐름 관리 도구

"이 모듈이 하는 일을 한 문장으로" — Agent의 작업 흐름을 그래프로 그려 순서와 반복을 명시적으로 통제

Graph(노드와 엣지) — 작업 단계를 노드로, 단계 간 연결을 엣지로 표현
State(상태 관리) — 단계마다 데이터와 진행 상황을 유지
Cycles(순환 루프) — 조건에 따라 이전 단계로 되돌아가는 반복 처리 가능

LlamaIndex

RAG 전용 프레임워크

"이 모듈이 하는 일을 한 문장으로" — 데이터의 검색·인덱싱에 집중해 RAG 성능을 극대화

데이터의 검색, 인덱싱을 통해 RAG 성능 극대화가 목표
인덱스 종류: Vector(벡터 유사도), Tree(계층적 요약), Summary(요약 기반), Keyword(키워드 매칭)

구분	주 용도	강점	대표 사용 시점
LangChain	Agent 전체 뼈대 구성	가장 넓은 범용성, 다양한 조합	Agent 시스템을 처음부터 구성할 때
LangGraph	작업 흐름 제어	분기·반복이 많은 흐름을 명시적으로 관리	Agent 로직이 복잡해지고 순환 처리가 필요할 때
LlamaIndex	데이터 검색/인덱싱	RAG 성능 최적화에 특화	외부 문서 기반 검색·질의응답이 핵심일 때

선택 기준
· LangChain은 전체 뼈대, LangGraph는 흐름 제어, LlamaIndex는 데이터 검색 담당으로 함께 조합해서 쓰는 경우가 많음
· 단순한 챗봇 수준이면 LangChain만으로 충분하지만, 흐름이 복잡해지면 LangGraph를, 문서 기반 검색이 핵심이면 LlamaIndex를 추가로 결합함

260708_강의 정리 (RNN → LSTM → Seq2Seq → NMT → Self-Attention 정리)

크런키스틱 — Wed, 8 Jul 2026 15:41:23 +0900

deep learning · sequence models

RNN → LSTM → Seq2Seq → NMT → Self-Attention 정리

RNN의 기억력 한계를 LSTM의 게이트 구조로 해결하는 과정
Seq2Seq의 context vector 병목을 attention으로 극복하는 흐름
NMT attention과 self-attention(Transformer)의 차이점

1. RNN Cell과 그 한계

"하나의 셀이 시간에 따라 정보를 이어받으며 처리하는 것" — 순차 데이터 처리의 기본 구조

FFNN(순방향 신경망)에 내부 피드백(internal feedback)을 추가한 구조가 RNN cell임
구성 요소 — input(x): 현재 시점 입력값 / hidden(a): 이전 시점 정보를 담은 은닉 상태 / output(y): 현재 시점 출력값
하나의 cell은 feedforward network with internal feedback으로 볼 수 있음
한계: 시퀀스가 길어질수록 기울기 소실(vanishing gradient) 문제로 먼 과거 정보를 기억하기 어려움

새 개념

내부 피드백 internal feedback

이전 시점의 출력이 현재 시점 계산에 다시 사용되는 구조

어제 한 말을 기억하면서 오늘 대화를 이어가는 것

기울기 소실 문제
· 시퀀스가 길어질수록 초반 정보의 영향력이 점점 희미해짐
· 이 문제를 해결하기 위해 LSTM 등장

RNN의 5가지 입출력 구조

구조	형태	대표 태스크
one to one	입력 1개 → 출력 1개	일반 신경망(FFNN)과 동일
one to many	입력 1개 → 출력 여러 개	이미지 캡셔닝
many to one	입력 여러 개 → 출력 1개	감성 분석, 문서 분류
many to many (동기)	입력·출력 길이 동일	품사 태깅
many to many (비동기)	입력·출력 길이 다름	기계 번역

2. LSTM (Long Short-Term Memory)

"RNN의 기억력 문제를 게이트로 해결한 구조" — 장기 의존성을 학습하기 위한 셀 구조

RNN은 시퀀스가 길어지면 오래된 정보를 잊어버리는 문제가 있음
LSTM은 cell state(C_t)와 3개의 게이트로 정보 흐름을 제어함

새 개념

Forget gate f

sigmoid 함수 사용, 이전 cell state 중 얼마나 지울지 결정 (0~1)

0에 가까우면 완전히 잊음, 1에 가까우면 그대로 유지

Input gate i

sigmoid 함수 사용, 새 정보를 얼마나 반영할지 결정 (0~1)

Candidate gate g

tanh 함수 사용, 새로 추가할 후보 값 자체를 생성 (-1~1)

i가 "얼마나" 반영할지 정하면, g는 "무엇을" 반영할지 정함

Output gate o

sigmoid 함수 사용, cell state 중 얼마나 hidden state로 내보낼지 결정

→ C_t = f_t * C_(t-1) + i_t * g_t (cell state 업데이트)
→ h_t = o_t * tanh(C_t) (hidden state 출력)

게이트 요약
· f, i, o는 sigmoid(0~1) — "얼마나"를 결정
· g는 tanh(-1~1) — "무엇을" 반영할지 결정
· 네 게이트가 함께 cell state의 장기 기억을 관리함

3. Seq2Seq (Encoder-Decoder)

"입력 시퀀스를 하나의 벡터로 압축한 뒤, 그 벡터로 출력 시퀀스를 생성하는 구조" — 번역·요약 등 sequence-to-sequence 태스크의 기본 틀

Encoder: 입력 시퀀스를 순차적으로 처리해 마지막 hidden state(=context vector)로 압축
Decoder: context vector를 받아 출력 시퀀스를 한 토큰씩 생성
한계: 입력이 길어지면 하나의 고정 크기 context vector에 모든 정보를 담기 어려움

새 개념

Context vector

encoder의 마지막 hidden state, 입력 시퀀스 전체 정보를 압축한 벡터

긴 문장을 한 문장으로 요약해서 통역사에게 전달하는 메모

이 병목을 해결하기 위해 attention 메커니즘이 등장함

4. NMT (Neural Machine Translation)와 Attention

"디코더가 매 시점마다 인코더의 모든 정보를 다시 참고하는 것" — 고정된 context vector의 한계를 극복하는 방법

NMT(Neural Machine Translation, 신경망 기계 번역): seq2seq 구조 기반 번역 모델
기존 seq2seq는 context vector 하나로만 전체 문장을 표현 → 정보 손실 발생
Attention 적용 시, decoder가 출력을 생성할 때마다 encoder의 모든 hidden state를 다시 참조함

flow

Attention 동작 순서

decoder가 매 출력마다 encoder를 다시 훑어보는 과정

① decoder의 현재 상태와 encoder의 각 hidden state 간 유사도 계산 → attention weight 산출
② attention weight로 encoder hidden state들을 가중합 → context vector 생성
③ context vector를 이용해 다음 단어 예측

새 개념

Attention weight

입력의 각 위치가 현재 출력에 얼마나 중요한지를 나타내는 가중치 (합이 1)

"Je"를 생성할 때 weight (0.5, 0.3, 0.1, 0.1)로 입력 각 단어를 참조

encoder hidden states → attention weight 계산 → context vector → decoder 출력

5. Self-Attention

"같은 문장 안에서 단어끼리 서로 얼마나 관련 있는지 계산하는 것" — Transformer의 핵심 메커니즘

NMT attention: 서로 다른 시퀀스(encoder ↔ decoder) 간 관계 계산
self-attention: 같은 시퀀스 내부에서 단어 간 관계 계산
Query, Key, Value 세 가지 벡터로 관계를 계산함

새 개념

Query

현재 기준이 되는 단어가 "무엇을 찾고 있는지"를 나타내는 벡터

Key

각 단어가 "내가 무엇을 갖고 있는지"를 나타내는 벡터, query와의 유사도 계산에 사용

Value

실제로 가중합에 사용되는 정보 벡터

도서관에서 검색어(query)로 책 제목(key)을 찾고, 실제 필요한 건 책 내용(value)인 것

① query와 각 key의 유사도로 score 계산
② score를 정규화해 가중치 산출
③ 가중치로 value들을 가중합(multiplication) → 출력 생성

NMT attention vs self-attention
· NMT attention → 서로 다른 시퀀스 간 (encoder-decoder)
· self-attention → 같은 시퀀스 내부
· 이름은 같지만 목적과 참조 대상이 다름

️

6. RNN을 이미지 데이터에 적용하는 예시 (MNIST)

"이미지를 시퀀스처럼 취급해서 RNN에 입력하는 것" — RNN 활용 예시

MNIST 손글씨 숫자 이미지(28×28)를 RNN 입력으로 사용하는 예시
이미지의 각 행(28픽셀)을 하나의 timestep 입력으로 취급
→ 28×28 이미지 = 28개 timestep × 28차원 벡터 입력
hidden size = 128 (BasicRNNCell의 은닉 차원), batch size = 128 (한 번에 학습하는 이미지 개수)
출력: many-to-one 구조로 마지막 timestep의 출력을 one-hot encoding(10, 0~9 숫자 분류)으로 매핑

새 개념

BasicRNNCell

TensorFlow/Keras 등에서 제공하는 가장 기본적인 RNN 셀 구현체
hidden 차원을 파라미터로 지정해 사용

주의
· hidden size와 batch size는 우연히 같은 숫자(128)일 뿐 다른 개념임
· 입력 시퀀스 길이(28)는 이미지의 세로 픽셀 수, 벡터 차원(28)은 이미지의 가로 픽셀 수에서 옴

260707_강의 정리 (생성모델 - AE, VAE, GAN)

크런키스틱 — Wed, 8 Jul 2026 15:24:20 +0900

deep learning · generative model

AE, VAE, GAN — 생성 모델의 기초

지도학습 vs 비지도학습, discriminative vs generative의 근본적 차이
AE(압축·복원) → VAE(확률적 잠재공간) → GAN(적대적 학습)으로 이어지는 생성모델 발전
잠재변수, KL divergence, upsampling 등 생성모델을 이해하기 위한 핵심 개념

1. 지도학습 vs 비지도학습, 그리고 생성모델

"정답이 있는가 없는가" — 학습 방식을 가르는 가장 근본적인 기준

지도학습 — 입력-정답(Target) 쌍으로 학습함
비지도학습 — 정답 없이 데이터 자체의 구조를 학습함
비지도학습의 목적 — clustering(비슷한 데이터끼리 묶기), 차원 축소/특징 추출(핵심 정보만 압축해 후속 작업에 활용)
PCA — 레이블 없이 데이터의 주요 분산 방향을 찾는 대표적인 비지도학습·차원축소 기법

새 개념

Generative vs Discriminative 생성 vs 판별

Discriminative — 데이터가 주어졌을 때 클래스를 구분함 (P(y|x))
Generative — 데이터가 생성되는 과정 자체를 학습해 새 데이터를 만듦 (P(x))

분류기는 경계선을 긋고, 생성모델은 데이터 자체를 빚어낸다

AE, VAE, GAN, RBM은 모두 "데이터를 생성할 수 있는" generative network 계열

2. AE (Autoencoder) — 압축과 복원

입력을 압축했다가 그대로 복원하도록 학습시켜 핵심 특징만 남기기

input → encode(압축) → hidden(병목) → decode(복원) → output
hidden layer가 input/output보다 작은 병목 구조라서 데이터의 핵심 정보만 남도록 강제됨

새 개념

잠재변수 latent variable

데이터의 본질적 특징을 저차원으로 압축한 표현

빙산에서 보이는 부분은 일부고, 본질은 수면 아래(압축된 잠재공간)에 있음

AE는 복원은 잘하지만, 잠재공간이 불연속적이라 "새로운" 데이터를 생성하는 데는 약함

3. VAE (Variational Autoencoder) — 확률로 압축하기

AE와 달리 입력을 하나의 벡터가 아니라 확률분포로 압축함

Encoder가 평균(μ)과 표준편차(σ)를 출력함 → 이 분포에서 샘플링: z = μ + εσ
Decoder는 샘플링된 z를 입력받아 복원(Recon)함
Loss = ReconLoss(복원 오차) + KL divergence(잠재공간을 표준정규분포 N(0,1)에 가깝게 규제)

새 개념

KL divergence Kullback-Leibler divergence

두 확률분포의 차이를 나타내는 척도임 (거리는 아님 — 비대칭: KL(p‖q) ≠ KL(q‖p))

두 분포가 얼마나 다른 모양을 하고 있는지 수치로 나타낸 것

KL(p‖q) = Σ p·log(p) − Σ p·log(q) = −H(p) + H(p,q)

H(p) — 분포 p의 엔트로피
H(p,q) — p와 q 사이의 교차 엔트로피

잠재공간이 매끄러운 확률분포를 이루기 때문에, 학습 후 임의의 z를 샘플링해서 새로운 데이터를 생성할 수 있음 — AE와의 결정적 차이

4. GAN (Generative Adversarial Network) — 경쟁하며 배우기

생성자와 판별자가 서로 속고 속이며 함께 성장하는 구조

Noise → Generator → Fake Image 생성
Real Image + Fake Image → Discriminator → Real/Fake 판별
Generator는 Discriminator를 속이도록, Discriminator는 진짜/가짜를 더 잘 구분하도록 서로 경쟁(적대적 학습)하며 발전함

example

특징 연산 (Vector Arithmetic)

Man with glasses − Man without glasses + Woman without glasses = Woman with glasses (DCGAN 논문의 대표 실험 결과)

잠재공간에서 벡터 연산으로 의미 있는 이미지 변형이 가능함

적대적 학습 덕분에 GAN은 AE/VAE보다 훨씬 더 사실적인 이미지를 생성하는 경향이 있음

5. Upsampling — 작은 걸 다시 키우기

Decoder/Generator가 압축된 표현을 다시 원래 크기로 복원하는 방법 중 하나

Upsampling에는 max unpooling, transposed convolution, interpolation 등 여러 방법이 있음 (여기서는 max unpooling 예시)
Max Pooling — 영역 내 최댓값만 남기고 나머지는 버림, 이때 최댓값의 위치를 기억
Max Unpooling — 기억해둔 위치에만 값을 복원하고 나머지는 0으로 채워 원래 크기로 되돌림

pooling에서 기억해둔 위치 정보를 unpooling 때 그대로 활용해 공간 정보를 최대한 보존

Upsampling 방법 선택에 따라 복원된 이미지의 디테일과 학습 난이도가 달라짐

️

6. RBM — 초기 생성모델

RBM(Restricted Boltzmann Machine) — AE 이전에 등장한 초기 생성모델 계열
오늘날은 AE/VAE/GAN이 더 널리 쓰이지만, 생성모델 발전 계보의 출발점으로 의미가 있음

정리 — 생성모델의 흐름

AE (단순 압축·복원)

→

VAE (확률적 잠재공간, 생성 능력 획득)

→

GAN (적대적 학습, 사실적 생성)

260706_강의 정리 (전이학습)

크런키스틱 — Mon, 6 Jul 2026 21:59:40 +0900

deep learning · cnn

CNN 모델의 발전과 전이학습

성능 개선의 두 축 — 학습 방식 최적화 vs 네트워크 구조 혁신
VGG → ResNet → Inception → Xception/MobileNet → EfficientNet으로 이어지는 발전 흐름
전이학습으로 사전학습된 지식을 재사용하는 방법 (fine-tuning, feature-extraction, LoRA)

1. 전이학습이란

"이미 학습된 지식을 다른 문제에 재사용하는 것" — 처음부터 다시 배우지 않아도 됨

ImageNet 등 대규모 데이터로 미리 학습된 pre-trained 모델을 그대로 활용함
데이터가 적거나 학습 시간이 부족할 때 특히 유용함

새 개념

Feature-extraction 특징 추출 방식

pre-trained conv layer는 그대로 고정(freeze)함
마지막 분류기 레이어만 새로 학습함

이미 완성된 렌즈는 그대로 쓰고 카메라 설정만 바꾸는 것

Fine-tuning 미세 조정

일부 또는 전체 레이어를 새 데이터에 맞게 재학습함

렌즈까지 새로 조정해서 내 상황에 맞게 다시 맞추는 것

LoRA Low-Rank Adaptation

전체 가중치 대신 저차원 행렬만 학습해 효율적으로 미세조정함

trainable_weights 설정에 따라 학습 범위가 결정됨

전이학습의 핵심은 "무엇을 얼리고(freeze) 무엇을 학습시킬지" 결정하는 것

⚙️

2. 학습을 빠르고 정확하게 만드는 기법

네트워크 구조를 바꾸지 않고도 학습 자체를 개선하는 방법들

Batch Normalization — 레이어마다 입력 분포를 정규화해 학습 안정성과 속도를 높임
ReLU — 비선형성을 도입하고 gradient vanishing 문제를 완화함
Optimizer — 손실함수를 효율적으로 최소화하는 알고리즘 (SGD, Adam 등)

세 기법 모두 "같은 구조라도 더 빠르고 안정적으로 학습시키기 위한 도구"

3. VGG-16 — 단순하고 깊게

3x3 필터를 반복해서 쌓는 단순한 구조로 깊이를 늘림

VGG-16 구조 — Conv 블록 + Pooling 반복

Conv(3x3) + Pooling 블록을 반복해 깊은 네트워크를 구성함
5x5, 7x7 필터 하나 대신 3x3을 여러 겹 쌓으면 같은 수용영역을 더 적은 파라미터로 확보하고, 비선형성도 더 많이 추가됨

3x3 필터 2번 = 5x5 필터 1번과 비슷한 범위를 보되 파라미터는 더 적음

구조는 단순하지만 파라미터 수가 많아 무겁다는 한계가 있음 → 이후 모델들이 이를 개선

4. ResNet — 깊이의 한계를 넘다

"왜 네트워크는 깊어질수록 오히려 성능이 나빠질까?"라는 문제에서 출발

Degradation 문제 — 층이 깊어질수록 vanishing gradient로 학습이 오히려 어려워짐
Residual block(skip connection) 도입 → 입력을 그대로 더해줘서(identity) 정보 손실을 막음
Resnet-152처럼 매우 깊은 네트워크도 안정적으로 학습 가능해짐

Residual block — F(x) + x

새 개념

Residual block 잔차 블록

F(x) + x 형태로 입력(x)을 그대로 더해줌

본채(F(x))를 새로 짓되, 원래 있던 뼈대(x)는 그대로 이어붙이는 것

skip connection 덕분에 "더 깊이 = 더 좋은 성능"이 실제로 성립하게 됨

5. Inception — 한 층에서 여러 시야로 보기

필터 크기를 하나로 고정하지 않고 여러 개를 병렬로 사용함

Inception 모듈 기본 개념도

1x1, 3x3, 5x5 conv + max pooling을 병렬로 배치한 뒤 결과를 concat함
1x1 conv는 단순한 필터가 아니라 차원 축소(bottleneck) 역할을 하며 연산량 절감의 핵심임

그림은 Inception 모듈의 기본 개념도(GoogLeNet 계열)이며, 실제 Inception v4는 여기에 factorized convolution·reduction block이 추가된 구조

여러 크기의 필터를 동시에 써서 다양한 크기의 패턴을 한 층에서 포착함

6. Xception & MobileNet — 가볍게 만들기

정확도는 유지하면서 연산량을 줄이는 경량화 전략

core

Depthwise Separable Convolution

하나의 큰 연산을 두 개의 가벼운 연산으로 쪼갠다

Depthwise — 채널별로 독립적인 공간 필터링을 수행함
Pointwise(1x1) — 채널 간 정보를 조합함

Depthwise + Pointwise convolution 분리 과정

목적 — 모바일·임베디드 환경처럼 연산 자원이 제한된 곳에서도 동작 가능하게 함

일반 conv 대비 연산량이 크게 줄어듦 → 경량 모델의 핵심 아이디어

⚖️

7. EfficientNet — 균형 있게 키우기

"깊이·너비·해상도 중 하나만 키우는 건 비효율적이지 않을까?"라는 질문에서 시작

기존 방식 — depth, width, resolution 중 하나만 늘리는 unbalanced scaling
EfficientNet — 세 가지를 정해진 비율로 동시에 늘리는 compound scaling 제안
B0~B7 — compound scaling 계수를 단계적으로 키운 모델 시리즈 (해상도만 다른 것이 아님)

Model Scaling — (a) baseline부터 (e) compound scaling까지

새 개념

Compound scaling 복합 스케일링

depth·width·resolution을 동시에 균형 있게 확장함

사진을 키울 때 가로세로 비율을 유지하며 확대하는 것과 비슷한 원리

무작정 크게 만드는 게 아니라 "어떤 비율로 키울 것인가"가 EfficientNet의 핵심 통찰

정리 — 발전의 흐름

VGG (단순·깊게)

→

ResNet (깊이의 한계 해결)

→

Inception (효율적 병렬 구조)

→

Xception/MobileNet (경량화)

→

EfficientNet (균형 스케일링)