MediDev Journey

[FastAPI 4일차] 동기와 비동기, asyncio

Vogueyoung — Fri, 16 Jan 2026 02:32:54 +0900

동기(Synchronous)와 비동기(Asynchronous)

동기 함수

@app.get("/sync")
def sync_task(): 
	time.sleep(3) 
    return "끝"

동기 함수는 작업이 끝날 때까지 서버가 멈춥니다.
위의 예시로 3초 동안 서버는 다른 요청을 처리하지 못합니다.

비동기 함수

@app.get("/async") 
async def async_task(): 
	await asyncio.sleep(3) 
    return "끝"

비동기 함수는 await를 만나면 현재 요청을 잠시 멈추고 서버가 다른 요청을 처리하도록 양보합니다.
그래서 여러 요청을 동시에 처리하는 것처럼 동작합니다.

실제로는 동시에가 아니라 따닥 따닥! 스위칭 되면서 동작하는 것으로 알면 됩니다.

서버 내부에서 일어나는 흐름

동기 방식

요청1: [ 실행 ───────────── 끝 ] 
요청2:                  [ 실행 ─ 끝 ] 
요청3:                       [ 실행 ─ 끝 ]

비동기 방식

요청1: [ 실행 ─ await ─ 멈춤 ───── 재개 ─ 끝 ] 
요청2:     [ 실행 ─ 끝 ] 
요청3:         [ 실행 ─ 끝 ]

이 구조 때문에 비동기 서버는 동시에 여러 요청을 처리하는 것처럼 보이게 됩니다.

실상은 빠르게 스위칭 되면서 각각 처리 되고 있습니다.

await의 의미

await는 단순히 "기다린다"가 아니라 다음 의미를 가집니다.

"이 요청은 여기서 잠시 멈출 테니 서버는 다른 요청을 먼저 처리하세요."

그래서 비동기 서버가 효율적으로 동작합니다.

asyncio

asyncio는 비동기 작업을 관리하는 파이썬 라이브러리입니다.
FastAPI는 내부적으로 asyncio 이벤트 루프를 사용하여 여러 요청을 번갈아 처리합니다.

import asyncio 

async def work(): 
	print("작업 시작") 
    await asyncio.sleep(2) 
    print("작업 끝")

이 코드에서 sleep 동안 서버는 다른 작업을 처리할 수 있습니다.

이렇게 보면 멀티태스킹에 능해보이는 비동기가 효율적이어 보이지만, 비동기가 항상 좋은 것은 아닙니다.

비동기는 대기 시간이 긴 작업에 효과적입니다.

상황	추천
DB 조회, 파일 읽기, API 호출	비동기
복잡한 계산, 순서가 중요한 로직	동기

CPU 계산같이 기다리는 시간이 없는 작업은 비동기로 만들어도 효과가 거의 없습니다.

FastAPI에서 비동기 사용 예제

from fastapi import FastAPI 
import asyncio 

app = FastAPI() 

@app.get("/data") 
async def get_data(): 
	await asyncio.sleep(2) 
    return {"message": "완료"}

이 API는 2초 동안 멈추는 것처럼 보이지만,
그동안 서버는 다른 요청을 계속 처리합니다.

간략하게 정리해보았습니다.

개념	의미
동기	한 요청 끝날 때까지 서버가 멈춤
비동기	요청을 멈춰두고 다른 요청 처리
await	현재 요청 일시 정지
asyncio	비동기 작업 관리자

비동기는 속도를 빠르게 만드는 기술이 아니라 서버가 놀지 않게 만드는 기술이라고 볼 수 있습니다!

[FastAPI 2일차] Type Hints, 상태 코드, 에러 처리

Vogueyoung — Thu, 15 Jan 2026 21:17:15 +0900

Type Hints

Type Hints는 변수, 함수, 데이터의 의도된 타입을 코드에 명시하는 문법입니다.
FastAPI의 자동 검증, 자동 문서화 기능은 모두 Type Hints를 기반으로 동작합니다.

Type Hints의 역할

코드 가독성 향상
IDE 자동 완성 및 오류 사전 탐지 가능
Pydantic, FastAPI 런타임 검증 기반

- 기본 Type Hints 문법

name: str = "apple" 
price: int = 1000 
ratio: float = 0.5 
is_active: bool = True 

score: int | float

Type Hints는 Python 실행 자체에는 영향을 주지 않는 문법 기능입니다.

- 함수에서의 Type Hints

def add(a: int, b: int) -> int: 
	return a + b

입력값과 반환값의 타입을 명확하게 표현할 수 있습니다.

- 컬렉션 타입 Type Hints

names: list[str] = ["a", "b"] 
scores: dict[str, int] = {"math": 90} 

users: list[dict[str, int | str]] = [ 
	{"id": 1, "name": "alex"}, 
 	   {"id": 2, "name": "bob"}, 
	]

리스트와 딕셔너리 내부 구조까지 명확히 표현할 수 있습니다.

- Optional Type Hints

Optional Type은 값이 있을 수도 있고 없을 수도 있는 타입입니다.

name: str | None = None

Request Body

Query와 Path는 URL 기반 입력입니다.
JSON 데이터는 Request Body를 통해 전달합니다.

Pydantic

Pydantic은 데이터 검증과 파싱을 담당하는 라이브러리이며 FastAPI의 핵심 구성 요소입니다.

사용 목적

Request Body(JSON) 검증
Response 구조 명확화

Pydantic 기본 모델

from pydantic import BaseModel 

class Item(BaseModel): 
	name: str 
    price: int

item = Item(name="apple", price=1000) 
item.model_dump() 
Item.model_validate({"name": "apple", "price": 1000}) 
Item(name="apple", price="cheap")

잘못된 타입 입력 시 자동 검증 오류가 발생합니다.

Field를 이용한 검증 강화

from pydantic import BaseModel, Field 

class Item(BaseModel): 
	name: str = Field(..., min_length=2)
    	price: int = Field(..., ge=0)

문자열 길이와 숫자 범위를 제한할 수 있습니다.

FastAPI에서 Request Body 사용

@app.post("/items") 
def create_item(item: Item): 
	return item

Request Body는 자동으로 Pydantic 모델 객체로 변환됩니다.

기본값과 선택 필드

class Item(BaseModel): 
	name: str 
    	price: int description: str | None = None 
    	is_active: bool = True

필수 필드와 선택 필드를 명확히 구분할 수 있습니다.

중첩 모델

class User(BaseModel): 
	id: int 
	name: str 
    
class Order(BaseModel): 
	user: User 
    	amount: int

@app.post("/orders") 
def create_order(order: Order): 
	return order

JSON 구조를 그대로 모델로 표현할 수 있습니다.

Response Model

@app.post("/items", response_model=Item) 
def create_item(item: Item): 
	return { 
    	"name": "apple", 
        "price": 1000, 
        "category": "fruit" 
    	}

Response Model은 응답 구조를 고정하고 불필요한 필드를 자동으로 제거하며 응답 검증을 수행합니다.

상태 코드(HTTP Status Code)

상태 코드는 서버가 요청을 어떻게 처리했는지를 숫자로 표현하는 값입니다.

@app.post("/items", status_code=201) 
def create_item(item: Item): 
	return item

201은 리소스 생성 성공을 의미합니다.

에러 처리(Error Handling)

FastAPI는 의도한 형태의 HTTP 에러 응답을 반환할 수 있도록 지원합니다.

from fastapi import HTTPException 

raise HTTPException(
	status_code=404, 
    detail="Item not found"
)

에러 상황을 정상적인 HTTP 응답 구조로 변환합니다.

[FastAPI 1일차] 개념, Path Parameter, Query Parameter

Vogueyoung — Thu, 15 Jan 2026 18:23:59 +0900

이번 포스트에서는

FastAPI의 개념부터 Path Parameter와 Query Parameter를 이용해 간단한 API를 만드는 흐름까지 다뤄보았습니다.

FastAPI란?

FastAPI는 Python 기반 고성능 웹 API 프레임워크입니다.

가장 큰 장점은 이름처럼 '빠르다(Fast)'는 것과, 코드를 작성할 때 변수의 타입을 미리 정해두는 타입 힌트 기능을 사용하면 데이터 검증과 문서 작성이 자동으로 된다는 점입니다.

FastAPI는 파이썬의 타입 힌트를 적극적으로 활용합니다. 예를 들어, user_id: int라고 함수에 지정하면, 사용자가 user_id 자리에 숫자가 아닌 문자('abc')를 보내면 FastAPI가 자동으로 에러를 처리해 줍니다. 개발자가 직접 검증 코드를 짤 필요가 없어서 편리합니다.

주요 특징

빠른 성능: Starlette 기반입니다.
타입 힌트 기반 자동 검증: 타입 힌트로 입력값 검증이 자동으로 동작합니다.
자동 API 문서: Swagger 문서가 자동으로 생성됩니다.

주요 용도

백엔드 API 서버 구축
AI 또는 ML 모델을 API로 서빙할 때 사용

Django vs Flask vs FastAPI:

Django: 기능이 너무 많아서 배우기 어렵고(러닝 커브가 높음), 큰 프로젝트에 적합함
Flask: 아주 가벼워서 작은 프로젝트에 좋음. 하지만 기능이 적어 필요한 것을 직접 만들어야 함.
FastAPI: 빠르고, API 서버와 AI 모델 서빙에 특화되어 있어 요즘 많이 사용됨.

개발 환경 준비

Python 버전

Python **3.10+** 사용을 권장합니다.

가상환경 생성

python3.13 -m venv .venv

가상환경 활성화

macOS

source .venv/bin/activate

Windows

.venv\Scripts\activate

FastAPI 설치

pip install "fastapi[standard]"

FastAPI 기본 구조

FastAPI는 FastAPI()로 앱을 만들고 데코레이터로 라우트를 등록합니다.

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def root():
	return {"message": "Hello FastAPI"}

기본 구조의 이해: FastAPI 서버를 시작하는 가장 기본적인 형태입니다.

from fastapi import FastAPI: FastAPI 기능을 가져옵니다.
app = FastAPI(): 서버 애플리케이션 객체를 만듭니다.
@app.get("/"): / 경로에 GET 요청이 들어오면 바로 아래에 있는 함수(root)를 실행하라는 뜻입니다.
return {"message": "Hello FastAPI"}: 함수가 실행된 후, 이 딕셔너리(key: value 형태)를 JSON 형태의 HTTP 응답으로 클라이언트에게 돌려줍니다.

FastAPI 서버 실행 시 지피티 등 다양하게 이용하다보면 다음과 같은 다양한 명령을 보게 됩니다.

fastapi dev 000:app
fastapi dev -e 000:app
fastapi dev 000.py

대체 이게 무슨 차이가 있는 애들일까요? 아래에서 알아보았습니다.

FastAPI 실행의 기본 원리

FastAPI 서버 실행의 핵심은 Python 파일 안에 있는 app 객체를 서버에 전달하는 것입니다.

# 000.py 
from fastapi import FastAPI 

app = FastAPI()

이때 FastAPI는 다음 형식을 기대합니다.

파일이름 : 앱객체이름

정석적인 실행 방식은 다음과 같습니다.

fastapi dev 000:app

000.py 파일 안에 정의된 app 객체를 개발 서버로 실행하라는 의미

이 명령은 FastAPI 개발 서버를 실행하며, 코드 변경 시 자동 재시작 기능이 포함된 기본 개발 모드입니다.

-e 옵션의 의미

-e 옵션은 FastAPI의 환경 변수 로딩 및 개발 편의 모드를 활성화하는 옵션입니다.

fastapi dev -e 000:app

주요 기능

코드 변경 사항을 즉시 반영하는 안정적인 자동 리로드
개발 환경에 최적화된 실행
(선택적) .env 파일이 있을 경우 자동 로딩

000.py 방식이 동작하는 이유

fastapi dev 000.py

이는 FastAPI CLI의 편의 기능 때문입니다.
FastAPI는 내부적으로 다음과 같이 추정하여 실행합니다.

000.py → 000:app

즉 000.py 방식은 축약형, 000:app 방식은 정석 문법입니다.

가끔 실습을 진행하다보면 :app 은 안 되는데 .py는 실행이 될 때가 있습니다.

이 현상은 FastAPI CLI의 동작 방식 차이 때문입니다.

.py 방식은 FastAPI가 "추측"해 주는 모드입니다

.py 로 실행되면 FastAPI는 다음 과정을 자동으로 수행합니다.

000.py 파일을 찾습니다.
파일을 import 합니다.
그 안에서 FastAPI 객체(app)를 자동으로 탐색합니다.
발견되면 해당 객체를 서버로 실행합니다.

.py 방식은 FastAPI가 내부에서 "이 파일 안에 app이 있겠지?" 하고 알아서 찾아 주는 모드입니다.

그래서 경로나 구조가 조금 틀려도 실행이 되는 경우가 많습니다.

그에 반해 :app 방식은 정석 문법이며 추측이 전혀 없습니다

이 방식은 FastAPI에게 정확히 <"000" 이라는 모듈 안에서 "app" 이라는 객체를 정확히 찾아 실행하라> 라고 요구합니다.

따라서 다음 중 하나라도 어긋나면 바로 실패합니다.

실패 원인	설명
파일 위치	현재 디렉토리에 000.py 가 없는 경우
실행 위치	터미널 위치가 파일이 있는 폴더가 아닌 경우
패키지 구조	폴더 구조로 인해 import 경로가 달라진 경우
객체 이름	FastAPI 객체 이름이 app 이 아닌 경우
모듈 충돌	동일한 이름의 폴더 또는 모듈이 존재하는 경우

실습을 하다보면 실습 파일이 계속 늘어나고, 파일명을 변경한다던가 하는 이유로

:app 방식은 실패할 수도 있고 이런 차이가 있다는 것을 알 수 있었습니다.

아래와 같이 표로 간략하게 정리해봤습니다.

실행 명령	의미
fastapi dev 000:app	FastAPI 정석 실행 방식
fastapi dev -e 000:app	정석 방식 + 환경변수 자동 로딩
fastapi dev 000.py	CLI 편의 기능으로 동작하는 축약형

데코레이터 개념과 FastAPI에서의 역할

데코레이터란

함수를 감싸서 원래 함수의 동작 전후에 공통 로직을 추가하는 문법입니다.
중복 코드를 줄이고 선언적으로 기능을 표현하는 데 사용합니다.

예시는 다음과 같습니다.

def my_decorator(func): 
	def wrapper(*args, **kwargs): 
    	print("before") 
        result = func(*args, **kwargs) 
        print("after") 
        return result 
	return wrapper 
    
@my_decorator 
def hello(): 
	print("hello")

FastAPI에서 데코레이터 역할

FastAPI의 @app.get() 같은 데코레이터는 함수를 HTTP 엔드포인트로 등록합니다.
예를 들어 GET / 요청이 오면 root() 함수가 실행됩니다.

@app.get("/") 
def root(): 
	return {"message": "Hello FastAPI"}

자동 API 문서

FastAPI는 API 문서를 자동 생성합니다.

Swagger UI: http://localhost:8000/docs
Redoc: http://localhost:8000/redoc

Path Parameter

Path Parameter는 URL 경로 자체에 포함되는 값입니다.
주로 리소스를 식별할 때 사용합니다.

예시는 다음과 같습니다.

/users/3
/items/abc

{user_id} 를 경로에서 추출해 함수 인자로 받습니다.
user_id: int 같은 타입 힌트로 자동 검증이 동작합니다.

@app.get("/users/{user_id}") 
def get_user(user_id: int): 
	return {"user_id": user_id}

/users/abc처럼 타입이 맞지 않으면 422 에러로 검증 실패가 자동 처리됩니다.

Swagger 문서에도 타입 정보가 자동 반영됩니다.

또 Path 값에 조건과 설명을 붙일 수 있는데요.

ge=1은 1 이상만 허용합니다.
description은 Swagger에 설명을 표시합니다.
...는 필수값을 의미합니다.

from fastapi import Path 

@app.get("/users/{user_id}") 
def get_user(user_id: int = Path(..., ge=1, description="유저 ID (1 이상)")): 
	return {"user_id": user_id}

실습을 해보겠습니다!

요구사항

GET /items/{item_id}
예시 입력: /items/10
예시 응답: {"item_id": 10}

정답 예시

@app.get("/items/{item_id}") 
def get_item(item_id: int): 
	return {"item_id": item_id}

Query Parameter

Query Parameter는 URL 뒤에 ?key=value 형태로 붙는 값입니다.
필터링, 정렬, 페이지네이션에 자주 사용합니다.

예시
/search?q=fastapi&limit=10

q는 필수입니다. 기본값이 없습니다.
limit은 선택입니다. 기본값이 10입니다.

@app.get("/search") 
def search(q: str, limit: int = 10): 
	return {"q": q, "limit": limit}

Query에는 조건을 걸 수 있습니다.

min_length, max_length는 문자열 길이 제한입니다.
ge, le는 숫자 범위 제한입니다.

from fastapi import Query 

@app.get("/search") 

def search( 
	q: str = Query(..., min_length=2, max_length=30), 
    limit: int = Query(10, ge=1, le=100), 
): 
    
    return {"q": q, "limit": limit}

Path + Query 같이 쓰기

원칙은 다음과 같습니다.

리소스 식별은 Path입니다.
옵션은 Query입니다.
URL 경로 상에 존재하면 Path입니다.
존재하지 않으면 Query입니다.

예시로 /users/3/posts?limit=5가 제시 되었을 때 아래와 같이 쓸 수 있습니다.

@app.get("/users/{user_id}/posts") 

def list_posts(user_id: int, limit: int = 10): 
    return {"user_id": user_id, "limit": limit}

이것도 실습을 해보겠습니다.

요구사항

GET /products/search?q=apple&limit=5
응답: {"q": "apple", "limit": 5}

정답 예시

@app.get("/products/search") 
def product_search(q: str, limit: int = 10): 
	return {"q": q, "limit": limit}

[자연어처리] 마무리 개념 확인용

Vogueyoung — Sat, 10 Jan 2026 20:39:28 +0900

텍스트 마이닝의 개념과 활용 목적

텍스트 마이닝은 자연어처리 기술을 기반으로 비정형 텍스트 데이터를 정제·가공하여 특정 목적에 부합하는 유의미한 정보와 패턴을 추출하는 분석 기법이다. 텍스트 데이터를 수치화하고 구조화하여 빈도, 관계, 주제, 의미를 분석한다. 텍스트의 표면적 의미뿐 아니라 반복 구조와 잠재된 주제를 파악하는 것이 목적이다.
연구 동향 분석, 정책 분석, 여론 분석, 설문 질적 자료 분석, 뉴스 기사 분석 등에 활용된다.
예를 들어 10년간 언론 기사 데이터를 분석해 사회적 이슈의 변화 흐름을 파악할 수 있다.

텍스트 데이터 수집 과정과 전처리의 필요성

텍스트 데이터 수집은 웹 크롤링, 공공 데이터 포털, 크롤링 SaaS 도구 등을 통해 수행된다.

수집된 텍스트는 분석 목적과 무관한 정보가 다수 포함되어 있다.

전처리는 분석 정확도를 확보하기 위한 필수 과정이며, 이후 모든 분석 결과에 직접적인 영향을 미친다.
전처리는 불용어 제거, 형태소 추출, 기본형 변환, 사용자 사전 반영 등의 단계를 포함한다.
예를 들어 전처리 사전에서 특정 단어를 삭제하면 빈도 분석, N-gram, 네트워크 분석 결과가 모두 변경된다.

형태소 분석의 개념과 형태소 추출 과정

형태소 분석은 문장을 의미를 가지는 최소 단위로 분해하는 과정이다.

한국어는 교착어이므로 형태소 분석을 통해 조사와 어미를 분리해야 한다.

형태소 분석기는 내부 사전을 기반으로 품사를 판별하며, 분석기마다 품사 기준이 다를 수 있다.

분석 목적에 따라 명사, 동사, 형용사 등 특정 품사만 추출한다.

예를 들어 연구 동향 분석에서는 명사 중심 분석이 일반적이다.

단어 빈도분석과 TF-IDF 분석의 차이

단어 빈도분석(TF)은 전체 문서 집합에서 단어가 등장한 횟수를 기준으로 중요도를 판단한다.

전체 텍스트의 주요 관심사를 파악하는 데 적합하다.
TF-IDF는 특정 문서에서의 단어 중요도를 반영하며, 전체 문서에서 흔한 단어의 가중치를 낮춘다. 문서별 핵심 키워드 도출에 적합하다.
예를 들어 “연구”, “결과”는 TF는 높지만 TF-IDF는 낮다. 반면 특정 문서에서만 반복되는 전문 용어는 TF-IDF가 높다.

N-gram의 개념과 문맥 정보 반영 방식

N-gram은 연속된 n개의 단어를 하나의 분석 단위로 묶는 기법이다.

단어 간 순서와 결합 관계를 반영해 문맥 정보를 부분적으로 포함한다.
Unigram은 단어 빈도 분석과 동일하며, 2-gram과 3-gram이 실무와 연구에서 가장 많이 사용된다.
예를 들어 “프로그램”이라는 단어의 의미를 파악하기 위해 “프로그램 개발”, “프로그램 운영” 같은 2-gram을 분석한다.

동시출현 단어 분석과 네트워크 해석

동시출현 단어 분석은 단어들이 동일 문서 또는 문맥에서 함께 등장하는 관계를 분석한다.

단어는 노드, 단어 간 관계는 엣지로 표현된다.
연결중심성, 근접중심성, 매개중심성, 위세중심성을 통해 단어의 구조적 역할을 해석한다.
예를 들어 연결중심성이 높은 단어는 여러 주제와 연결된 핵심 개념으로 해석된다.

텍스트 기반 단어 빈도분석 또는 TF-IDF 수행

형태소 분석 후 단어문서행렬(TDM)을 생성한다.

TDM은 텍스트를 정형 데이터로 변환하는 핵심 구조이다.
분석 목적에 따라 빈도 상위 단어를 선정하거나 TF-IDF 상위 키워드를 활용한다.
연구 논문에서는 일반적으로 빈도 상위 30~50개 단어를 분석 대상으로 사용한다.

LDA 토픽 모델을 통한 주요 토픽 추출

LDA는 문서 집합에서 잠재된 주제를 확률적으로 추정하는 토픽 모델이다.

문서는 여러 토픽의 혼합으로 구성되어 있으며, 각 토픽은 단어 확률 분포로 표현된다.
토픽을 구성하는 상위 단어를 기반으로 토픽의 의미를 해석하고 명명한다.
예를 들어 “호날두, 메시, 유럽, 바르셀로나”로 구성된 토픽은 해외 축구 선수 토픽으로 해석된다.

LDA의 작동 원리와 확률적 생성 과정

LDA는 전체 문서가 K개의 토픽으로 구성되어 있다고 가정한다.

각 문서는 토픽 비율을 가지며, 각 단어는 특정 토픽에서 생성된 것으로 가정된다.
알고리즘은 문서-토픽, 토픽-단어 간 확률을 반복적으로 조정하며 최적의 분포를 추정한다.
이 과정은 확률적 생성 모델에 기반하며, 결과는 항상 확률 분포 형태로 출력된다.

Perplexity, Coherence, LDAvis를 활용한 토픽 수 선정

Perplexity는 모델의 예측 정확도를 평가하며 값이 낮을수록 좋다.

Coherence는 토픽 내 단어들의 의미적 응집도를 평가하며 값이 높을수록 해석이 용이하다.
일반적으로 Coherence를 우선적으로 고려하고, Perplexity는 참고 지표로 활용한다.
LDAvis는 토픽 간 거리, 토픽별 핵심 단어 분포를 시각적으로 확인하는 도구이다.

Word2Vec의 기본 개념과 단어 임베딩

Word2Vec은 주변 단어 정보를 활용해 단어를 벡터로 표현하는 모델이다.

의미적으로 유사한 단어는 벡터 공간에서 가까이 위치한다.
CBOW와 Skip-gram 방식이 있으며, 의미 유사도 계산과 단어 관계 분석에 활용된다.
예를 들어 “의사”와 “간호사”는 벡터 공간에서 가까운 위치에 놓인다.

BERT의 등장 배경과 기존 임베딩 기법과의 차이

기존 임베딩 기법은 단어 단위 또는 단방향 문맥에 한계가 있었다.

BERT는 양방향 문맥을 동시에 고려하는 사전학습 언어모델이다.
동일한 단어라도 문맥에 따라 서로 다른 임베딩을 생성한다.
예를 들어 “은행”은 금융 문맥과 자연 지형 문맥에서 다른 의미로 처리된다.

SentenceBERT의 특징과 문장 유사도 계산

SentenceBERT는 문장 단위 임베딩을 생성하도록 BERT를 확장한 모델이다. 문장을 고정 길이 벡터로 변환하여 코사인 유사도를 계산한다.
문서 검색, 문장 군집화, 질의응답 시스템에 활용된다.
예를 들어 질문 문장과 가장 유사한 답변 문장을 자동으로 탐색할 수 있다.

LLM의 정의와 주요 특징

LLM은 대규모 텍스트 데이터로 학습된 언어모델이다.

사전학습과 미세조정을 통해 다양한 언어 작업을 수행한다.
텍스트 생성, 요약, 정보 추출, 추론이 가능하다.
기존 통계 기반 모델과 달리 의미 기반 이해와 생성이 가능하다.

토큰, 토큰화, 임베딩, 의미 공간

토큰은 텍스트 처리의 최소 단위이다.

토큰화는 문장을 토큰 단위로 분해하는 과정이다.
임베딩은 토큰을 벡터로 변환한 것이며, 의미 공간은 벡터들이 배치되는 고차원 공간이다.
의미적으로 유사한 토큰은 공간상 가까이 위치한다.

OpenAI Chat API 활용

OpenAI Chat API는 대규모 언어모델을 외부 시스템에서 활용할 수 있도록 제공되는 인터페이스이다.
프롬프트를 통해 텍스트 요약, 정보 추출, 분류, 질의응답을 수행할 수 있다.
예를 들어 여러 뉴스 기사를 입력해 핵심 내용만 요약하도록 자동화할 수 있다.

[일오갓생] 오늘이 과연 마지막 글일까?

Vogueyoung — Fri, 2 Jan 2026 21:24:56 +0900

DAY 10

10일동안 매일 하루에 대해 기록하고 내 생각을 남겼다.

HTML, CSS, Git, 네트워크 구조, eCRF 화면에서 느꼈던 UI 불편함, 병원 내부망과 외부망 이야기, AI헬스케어 특강 정리 등

꽤나 많은 내용을 썼고 주제가 생각보다 넓었던 것 같다.

이쯤 되면 대체 왜 10일 동안 굳이 15분일까에 대한 의문이 생긴다.

신규 간호사 시절 정말 호되게 나를 가르쳐주던 선임 중에 나한테 "이거 궁금하지 않아? 왜 안 궁금해?" 라고 물으며

계속 나한테 일하면서도 궁금한게 생기게끔 말하던 선생님이 계셨다.

반복해서 질문하시니까 좀 많이 무섭긴 했는데 호기심이 있어야 사람이 발전한다는 뜻에서 계속 물어보셨었다.

오늘은 일오갓생 마지막 날인만큼 왜 굳이 10일동안 15분이었는지 궁금증이 생겨서 써보려고 한다.

오늘의 갓생 - 일오갓생, 왜 10일 15분일까?

호기심이 생길때 사람의 중뇌의 변연계에 있는 도파민 경로가 활성화 된다.

이 도파민 신호는 감정 뿐 아니라 학습 관련 기억 강화에도 영향을 준다.

궁금해 하는 순간 뇌에서 보상 신호(도파민)이 올라가고 그 경험을 기억으로 저장하려는 경향이 강해지는 것이다.

특히 심리학/교육학 분야에서는 호기심이 학습에 긍정적으로 작용한다는 증거가 있다.

George Loewenstein (1994) 같은 학자는 정보 격차 이론 (Information Gap Theory) 에 대해 제시하면서

'사람들이 무언가를 배우려는 이유는 '지식의 부족→알고 싶다' 라는 인지적 감정에서 시작된다' 라고 말했다.

즉 사람들이 모르는 걸 깨달았을 때 생기는 인지적 불편함(gap)이 학습을 유도하고 동기화 한다는 것이다.

호기심이 성적을 올려주진 않지만 학습 동기에 영향을 준다는 것이다.

아마 내 선임 선생님도 계속 호기심을 가지고 일했음 좋겠는 마음에 자극을 주셨던 것 같다.

사실 그 때 말씀 주셨던 걸 토대로 계속 일했고 지금도 그렇긴 하다.

그렇다면 이제 진짜로 일오갓생에 대해 나름 써보고자 한다.

먼저 뇌는 단순한 저장장치가 아닌 변화하는 구조라는 것이 오래전부터 밝혀져 있다.

특히 뇌과학에선 뇌가 경험과 반복에 따라 실제 구조와 기능이 바뀐다는 사실이 알려져 있는데

이를 신경가소성(Neuroplasticity) 이라고 한다.

(오즈코딩스쿨 베이스캠프 미션 때도 다뤘던 내용인 것 같다. 티스토리에 업로드 한 적 있던듯..!)

반복적인 학습이나 행동이 뇌의 신경회로를 강화하고 재구성한다는 개념인데

실제로 강박적으로 연주 연습을 한 음악가의 뇌 부위가 더 발달한다든가

택시기사의 공간 기억 관련 부위가 더 커진다는 사례도 연구로 보고되어 있다.

쉽게 말하자면 특정 행동이나 학습을 반복하면 그 행동을 담당하는 신경세포, 즉 뉴런 사이의 연결이 점점 강화되고

시냅스 전달 효율이 높아지면서 그 회로가 실제로 자주 쓰는 길 처럼 굳어지게 된다.

신경가소성에 대해 잘 설명된 그림이다. 왼쪽은 안 좋은 생활습관으로 신경 연결이 약해진 모습을 보여주고, 오른쪽은 학습, 운동, 명상 등을 통해 신경 연결을 강화시켜서 뇌 기능이 실제로 좋아진다는 의미이다. 이를 통해 안 쓰는 회로는 정리 되고 자주 쓰는 회로만 남아 뇌가 효율적으로 재구성 되는 방식을 보여준다.

처음 어떤 행동을 할 때는 대뇌피질의 <전전두엽> 이 많이 관여한다.

여기가 바로 계획, 판단, 집중, 의지 등을 담당하는 영역인데

그래서 처음에는 모든 행동이 의식적으로 노력하는 것이기 때문에 피로감을 많이 느끼게 된다.

행동이 반복되면 어떻게 되느냐,

그 정보는 점차 <기저핵> 이라고 부르는 곳으로 넘어간다.

기저핵은 우리가 습관 이라고 부르는 자동화 행동을 담당하는 부위인데 이때부터는 행동이 의식적 판단이 아닌

신경 회로 차원의 자동 반응으로 바뀌는 것이다.

행동은 점점 뇌의 <의식적인 판단 영역(전전두엽)> 에서

<자동 행동을 담당하는 영역(기저핵)> 으로 옮겨간다. 대신 작동하게 되는 것이다.

"해야지" 라고 매번 다짐하지 않아도 몸이 먼저 움직이게 되는 단계로 넘어간다는 건데

보통 7~10일 정도 반복하면 이 초기 자동화 회로가 만들어지기 시작한다고 한다.

특히 중요한건 시간보다 '빈도' 이다.

한 번에 오래 하는 것보다 짧게라도 '자주 반복하는 학습'이 기억과 학습 효과가 훨씬 좋다는 연구 결과들이 많았다.

심리학에서는 이걸 분산 연습(distributed practice) 라고 부른다.

하루 3시간 공부하는 것보다 하루 15분씩 10일 동안 반복하는 것이 뇌에는 훨씬 강한 학습 신호로 남는 것이다.

심리적으로 가장 크게 바뀌는 것은 자기효능감이다.

매일 조금이라도 해냈다는 기록이 쌓이면 사람은 자연스럽게 내부 신념을 갖게 된다.

이게 쌓이면 계획을 세우는 방식도 바뀌고, 실패를 해석하는 방식도 달라지고, 다음 행동의 수준도 올라간다.

하루 15분은 뇌가 피로를 크게 느끼지 않으면서도 신경 회로를 자극하기에 충분한 시간이다.

10일 동안 크게 실력이 늘지 않았더라도 분명히 바뀐게 있다면 사고 방식과 행동 구조일 것이고

일오갓생을 실천한 모두의 150분은 우리의 뇌가 새로운 행동 회로를 형성해 가는 생물학적 과정이라고 봐도 될 것 같다.

✍ 기록

일오갓생 마무리
CSS 녹강 실습 복습
백준 문제풀이 (11718번)

내 얘기

10일 전의 나는 HTML 태그도 모르고, CSS 자체를 처음 보고 네트워크 라는 말 자체가 좀 막연했었는데

지금은 그래도 코드를 열어보면서 어떤 구조인지에 생각하게 되었다. 10일 만에 이런 성장을..?

처음 시작할 때는 뭐 하나라도 적으면 다행이겠다 생각이었는데

지금 돌아보면 글의 내용보다 크게 바뀐 건 학습을 하거나 내 생각을 정리하는 나의 태도 인 것 같다.

배운 걸 그냥 흘려보내려고 하지 않고 글로 남겨야 하니까 한 번 더 생각해보고

정리해서 남기는 습관이 생겼다고 할 수 있을 것 같다.

일오갓생을 하며 하루를 그냥 흘려보내지 않는 사람이 된 것 같다.

모두 이렇게 강화된 신경회로를 계속 써먹어 봤으면 좋겠다. 물론 나도!

제가 쓰는 다이어리에 이런게 있는데, 한 주간 매일 이 행동을 했는지에 대해 체크하는 사과나무입니다.

일오갓생 덕분에 귀여운 사과 나무 2그루를 완성했지용.

이 사진을 보고 있는 모두 이 사과나무처럼 귀엽고 예쁜 잘 될 사람들 뿐입니다. ‍♀️

길고 긴 모든 글 봐주셔서 감사합니다.

AI 헬스케어 특강 간단 정리

Vogueyoung — Thu, 1 Jan 2026 18:30:52 +0900

이번에 오즈코딩스쿨에서의 AI헬스케어 관련 특강을 보며 정리해본 내용입니다.

헬스케어 산업에 AI가 왜 필요한지부터 디지털 헬스케어 산업 구조, 의료 데이터와 규제 환경 그리고 취업 준비와 포트폴리오 구성 방법까지 전반적인 흐름을 정리해 보았습니다.

늦은 시간에도 열심히 강의해주신 강사님, 감사합니다. ‍♀️

헬스케어 AI가 필요한 이유

헬스케어 분야에서 AI 도입이 필수적인 이유는 다음과 같습니다.

✅ 진단과 치료의 정확도와 효율성 향상입니다.
✅ 심각해지는 의료 인력 부족 문제 해결입니다.

- 2034년 미국은 최대 120만 명의 의료 인력 부족이 예상되고 있습니다(AAMC).
✅ 기존의 집단 통계 기반 의료에서 개인 맞춤형 의료로의 전환입니다.

- 웨어러블 기기, 생활습관, 식단, 운동, 바이오 데이터 등을 활용한 정밀 의료가 확대되고 있습니다.
✅ 신약 개발 과정의 고도화입니다.

- 임상 대상자 최적화, 약물 부작용 예측 등에서 AI가 중요한 역할을 합니다.

이외에도 임상 데이터 분석 자동화, 원격 의료 서비스, 의료 행정 처리 자동화 등 다양한 영역에서 활용됩니다.

디지털 헬스케어 산업 구조

디지털 헬스케어 산업은 기술 계층에 따라 다음과 같이 구분됩니다.

✔️ Digital Device (HW): 의료 영상 장비, 웨어러블, 생체 센서
✔️ Digital Solution (SW): 진단 보조, 치료 지원, 의료 영상 분석
✔️ Digital Platform: 병원 플랫폼, 원격 의료, 데이터 관리
✔️ Digital Enabler (Data/Infra): EMR, EHR, PHR, 빅데이터, 클라우드

서비스 영역은 질병(Illness) 영역과 웰니스(Wellness) 영역으로 나뉘며,
비즈니스 구조는 B2B, B2C, B2B2C 형태로 운영됩니다.

의료 데이터와 규제 환경 (2024)

AI 헬스케어가 해결해야 할 핵심 과제는 다음과 같습니다.

데이터 연계: 의료기관 간 데이터 연계, EMR–PHR 통합
개인정보 보호: 데이터 유출 방지, 개인정보 위험 관리
윤리적 책임: 알고리즘 설명 가능성 확보, 검증 기준 수립

또한 AI 헬스케어 비즈니스 모델 설계 시 다음 요소를 고려해야 합니다.

시장 니즈 분석, 의료기기 인허가 및 관련 법규, 사용자 중심 기술 설계, 임상 검증, 데이터 품질 관리가 필수 요소입니다.

의료 데이터와 규제 정책 변화 (2025)

2025년부터 국내 보건의료 정책은 AI 기반 의료 혁신을 본격적으로 추진합니다.
AI 진단기기 140여 종을 우선 검토 대상으로 선정하였고, 의료 데이터 활용을 확대하는 정책을 통해 AI 기술의 의료 현장 도입을 가속화하고 있습니다.

부트캠프 학습 방식과 내용

부트캠프에서는 동료들과 함께 복습 스터디와 논문 스터디를 진행하며 학습하신 것을 말씀해주셨습니다.
주요 학습 내용은 CNN 구조(DenseNet, GoogLeNet, ResNet), Transformer, Attention 메커니즘 등 딥러닝 핵심 구조 전반이었습니다.

취업 준비 및 포트폴리오 전략

포트폴리오에서 가장 중요한 것은 프로젝트 설명 방식이라고 합니다.

프로젝트는 다음 구조로 정리하는 것을 추천해주셨습니다.

프로젝트 목적: 해결하고자 한 문제와 접근 방법
모델링: 데이터셋, 전처리, 모델 선택 이유, 후처리
문제 해결 과정: 발생한 문제와 해결 방법, 의사결정 과정
결과: 평가 지표, 결과, 한계점

예시 프로젝트: 흉부 CT 외상 손상 탐지

약 3천 명의 CT 데이터와 segmentation 데이터를 사용하였으며,
U-Net과 ResNet 기반 모델을 활용하여 장기별 crop 후 classification을 수행하였습니다.
3D 영상 데이터는 GPU 메모리 문제로 인해 2D stack 방식으로 처리하였고, 전처리 과정에서는 crop, padding, resize 등을 적용하였습니다.

포트폴리오 구성 방법

포트폴리오는 Cover, Profile, 프로젝트 3개 내외(ML, CV, NLP)로 구성합니다.
각 프로젝트는 전체 개요, 개인 기여도, 결과 및 배운 점을 중심으로 정리하는 것이 효과적입니다.

실제 의료 AI 개발 업무 흐름

예시로 들어주신 실제 의료 AI 개발 과정은 다음과 같습니다.

문제 정의 및 기획
데이터 탐색 및 대상 설정
데이터 확보(공공데이터, 병원 협업, IRB)
개발 전 고려사항 정리(규제, 성능 지표, 최소 데이터 기준)
모델 개발 및 학습
의료진 검증, 재학습 및 파인튜닝
목표 성능 달성 후 임상시험 및 인허가 문서 작성

이 특강을 통해 헬스케어 AI 산업의 구조와 실무 흐름, 그리고 취업 준비 방향을 좀 더 확실히 이해할 수 있었습니다. ‍♀️

[일오갓생] 새해 맞이에는 특강 정리

Vogueyoung — Thu, 1 Jan 2026 18:18:14 +0900

DAY 9

2026년 1월 1일 새해가 밝았다.

옛날에는 친구들이랑 1월 1일 00시 되면 문자고 카톡이고 하느라 바빴는데

30대가 되고 나서는 사실 그렇게 찾아가서 하는건 줄어든 것 같고 주로 연락하던 친구들이랑은

오늘 점심 메뉴 물어보듯이 새해 인사 툭 하고 말게 되는 것 같다.

이런 이벤트들에 점점 무뎌지는게 한편으로는 마음이 편해져서 좋기도 한데 한편으로는 예전처럼

설레고 들뜨던 감정이 좀 줄어드는? 것 같아서 아쉽다는 생각도 든다.

새해라는 하루를 특별하게 붙잡기 보다는 그냥 여느때와 다름 없는 하루 라는 생각으로 차분하게 맞이하고

준비하게 되는 것 같다.

1월 1일 기념으로!

공부는 조금 간단히 하고 며칠 전에 들었던 AI헬스케어 특강에서 들었던 얘기와 추가적인 생각을 좀 더 적어보고자 한다.

오늘의 갓생

이틀 전에 AI헬스케어부트캠프 특강을 들었다.

의료데이터AI와 헬스케어개발공부를 하다 보니 이런 특강은 더욱 관심 가지고 들여다보게 되고 내용도 더 와닿는다.

강의에서는 왜 헬스케어 산업에 AI가 필요한지, 의료 인력 부족 문제, 개인 맞춤형 의료로 바뀌는 흐름과

신약 개발, 원격 의료, 의료 행정 자동화 같은 이야기들이 나왔다.

AI가 단순 기술이 아닌 의료 시스템 전반을 바꾸는 흐름이라는 게 인상 깊었다.

디지털 헬스케어 산업 구조도 정리해주셨는데 의료 장비부터 소프트웨어, 병원 플랫폼, 데이터 인프라까지

생각보다 훨씬 넓은 산업이라는게 느껴졌다.

더 주의깊게 봐야 하는게 바로 의료 데이터와 규제 얘기였다.

AI만 잘 만든다고 끝이 아니라 개인 정보 보호, 의료기기 인허가, 법규 같은 부분이 훨씬 중요하다는 얘기였는데

이에 대해 더 알아보고 싶어서 오늘의 갓생으로 좀 더 뉴스를 찾아보고 그 내용을 하단에 기재해보았다.

요즘 한국은 의료데이터 활용을 늘리되 안전장치를 같이 세팅하는 방향으로 정책이 움직이고 있다.

출처: 보건복지부

2025년 말 보건복지부가 보건의료데이터 정책심의위원회를 열어서 AI 전환 시대에 맞춘 의료데이터 활용 활성화 방안과 공공데이터 개방·활용 개선 방향을 논의했다. 정부는 공공 보건 의료 데이터 인프라를 확충하고 국립대병원 임상데이터를 국가 빅데이터 플랫폼에 연계하기로 했고, 국가통합 바이오 빅데이터를 2028년까지 약 77만명 규모로 구축해서 단계적으로 외부에 개방할 계획을 발표했다.

출처: 보건복지부

또 의료 AI 스타트업과 중소기업이 데이터를 활용할 수 있도록 2025년에 8개 수준이던 [의료데이터 활용 바우처(데이터이용권)] 을 2026년에는 40개까지 크게 늘리기로 했다는 내용도 나왔다.(https://www.mohw.go.kr/board.es?act=view&bid=0032&list_no=1488202&mid=a20401000000&utm_source=chatgpt.com)

이 말인 즉슨 단순 데이터 공개 뿐이 아닌 실제 AI 의료 솔루션을 만드는 팀들이 직접 데이터를 쓸 수 있는 환경을 만들겠다는 말이다.

이렇게 데이터를 쓸 수 있게 하는만큼 안전하게 쓰기위한 제도도 정비되고 있다.

개인정보 보호 기반을 다지기 위해 보건의료 분야에서 개인정보 관리 전문기관을 지정해 의료 마이데이터 같은 활용을 위한 신뢰 기반을 만드려는 움직임도 있었고, 데이터 심의 과정도 표준 심사 절차를 정리해 의료 기관이 데이터를 제공할 때 불필요한 병목이 안 생기도록 개선하겠다는게 정책 방향이다. (https://www.korea.kr/briefing/pressReleaseView.do?newsId=156737715&pWise=sub&pWiseSub=C1&utm_source=chatgpt.com)

AI 의료기기나 의료 AI 솔루션이 실제 병원에서 쓰이도록 하는 AI 실증(실사용) 프로그램도 확대한다는 얘기가 최근 나왔다.

2026년 부터는 병원 중심으로 의료 AI 소프트웨어의 성능·효과를 현실 의료 현장에서 검증하도록 지원하는 실증 과제 20개가 신설된다는 계획이다. 이건 단순 연구를 넘어서 실제 환자 진료 환경에서 쓰일 수 있도록 정부가 제도적으로 뒷받침 하겠다는 신호로 볼 수 있다. (https://www.rapportian.com/news/articleView.html?idxno=230433&utm_source=chatgpt.com)

요약하자면 지금은

의료데이터 접근성·활용성 확대 + 데이터 안전·심의 체계 정비 + AI 실증 지원

이 세가지 축으로 정책이 움직이고 있는 것으로 보인다.

사실 예전에는 우리나라에서 의료 데이터나 개인정보 관련해서 적극적으로 풀겠다는 얘기가 쉽게 나오지 않았다.

민감한 정보이기에 법적·윤리적 요건이 좀 까다롭기도 하고, 의료 기관 간 데이터 연계도 많이 제한적이었다.

이 공부를 하면서도 데이터를 다루어보기에 나도 "데이터가 과연 많이 활용될 수 있을까?" 에 대한 걱정이 많았다.

그러나 2025년 이후 흐름을 보면 방향이 조금 달라졌다는게 느껴진다.

물론 아직도 법적 절차나 기관별 심의 같은 것들이 많이 남아있기도 하고 쉽게 바뀌지 않겠지만

데이터 활용을 좀 더 필요성에 의해 현실적으로 열어주면서도 안전 관리 체계도 같이 만드려는 흐름이 보인다.

✍ 기록

백준 문제풀이 (10871번)
특강 정리 티스토리 업로드
DACON 조금.. (아주 조금)

내 얘기

이 특강에서 특히 좋았던 건 강사님 얘기였다.

비전공자 출신에 부트캠프를 통해 이쪽 분야로 들어가셨다고 말씀해주셔서 마음이 놓이기도 했다.

요즘 비전공자AI도전이 가능하다고는 해도 막상 불안한 주제이긴 했으나

현실적인 커리어 이야기를 듣고 나니 내 길에 대해 조금 더 틀이 잡혔다.

의료 현장을 알고 있다는게 나의 장점이지만 이걸 잘 살릴 수 있을지에 대한 고민과

이걸 AI기반프로젝트에서 어떤 식으로 녹여 낼지에 대해 좀 더 생각해봐야겠다.

아직 많이 부족하지만

이렇게 걱정하는 하루하루가 쌓여서 미래의 나를 좀 더 온전히 완성시켜낼 것이라고 생각한다! ✨

[일오갓생] 2025년 12월 31일

Vogueyoung — Wed, 31 Dec 2025 22:39:57 +0900

DAY 8

2025년의 마지막 날이다.

고생한 나 그리고 이 글을 읽는 모두에게 한 해 너무 고생했고 수고했다고 박수 쳐주고 싶다.

2025년을 보내면서 하는 건.. 오즈코딩스쿨과 함께하는 일오갓생 ✨

오늘의 갓생

오늘은 CSS 기초를 배우면서

border, padding, margin, box model 등 + style.css 파일로 스타일을 분리해서 관리하는 방법을 배웠다.

웹 요소가 화면에서 어떤 구조로 배치되는지를 들여다 본 것 같다.

또 display 속성, 그리고 inline 요소와 block-level 요소의 차이도 배웠다.
block-level 요소는 한 줄을 통째로 차지하는 구조고,

inline 요소는 글자처럼 흐름 안에 들어가는 구조다! 라는 개념을 지금 잘 이해하고 기억해야 될 것 같은 느낌도 뿜뿜 왔다.

복습하면서 예전에 인스타에 저장해둔 Happy New Year 2026 애니메이션 예제가 떠올랐다.

예전에 보고 오 괜찮은데? 하고 저장하고 넘겼었는데 오늘 한 번 열어보려고 한다.

먼저 해당 코드를 제공하는 사이트는

https://codingstella.com/how-to-make-happy-new-year-2026-animation-using-html-and-css/?utm_source=sp_auto_dm

How to make Happy New Year 2026 Animation using HTML and CSS | Coding Stella

Let’s create a Happy New Year 2026 Animation using HTML and CSS. This project will help you design a festive animation with glowing text, smooth transitions,

codingstella.com

이곳이다.

아마 사람들이 흥미있어할법한 코드를 만들어서 가지고 오시는 분 같다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

HTML은 생각보다 단순했다.

<div class="feliz">, <div class="ano_novo">, <div class="fogos">
이렇게 화면을 구성하는 <div> 큰 덩어리들이 있고,
그 안에서 <span>들이 숫자와 불꽃 조각들을 만들고 있었다.

화면의 큰 틀은 전부 <div>로 만들고, 숫자 하나씩 작은 불꽃 요소는 <span>으로 나눠 둔 구조였다.
오늘 배웠듯이 block으로 전체 구조를 잡고 inline 요소로 세부 조각을 구성한 방식이었다.

그리고 대망의 CSS를 열어보았다.

CSS 코드를 보자마자 오늘 배운 것들이 몇 가지 보였다.

box-sizing: border-box;

margin: 0; padding: 0;

width, height, padding, border 값...

박스 하나가 화면에서 차지하는 영역이 box model 구조로 계산되고 있었고
position, display, justify-content, align-items 같은 속성으로 요소들이 화면 가운데에 정렬돼 있었다.

코드를 보다가 @keyframes라는 게 계속 보여서 그냥 지피티한테 물어봤다.

알고 보니 @keyframes는 CSS에서 애니메이션의 흐름을 미리 설계해 두는 코드라고 한다.
처음엔 어떤 상태, 중간엔 어떤 상태, 마지막엔 어떤 상태인지 시간 순서대로 적어두는 방식이다.

비유를 들어보자면 만화를 그릴 때

1컷: 서 있는 모습 / 2컷: 점프 하는 중 / 3컷: 착지

이런식으로 장면을 나눠서 그리는데, @keyframes 은 그걸 코드로 적는 것이다.

@keyframes move {
  0%   { left: 0; }
  50%  { left: 100px; }
  100% { left: 0; }
}

위와 같은 코드를 쓴다고 했을 때

처음(0%)엔 왼쪽 끝에 있다가
중간(50%)엔 오른쪽으로 갔다가
마지막(100%)엔 다시 돌아와라

그리고 이 설계도를 어떤 요소에 붙인다고 해보면?

.box {
  animation: move 2s infinite;
}

이런식으로 되는데 그럼 .box 가 2초 동안 이 설계도대로 계속 움직인다는 것이다.

지피티에게 설명을 듣고 보아하니 숫자가 이동하는 애니메이션, 풍선이 날아가는 애니메이션,
불꽃이 터지는 효과 전부 @keyframes로 정의돼 있고 시간 순서에 맞게 연결되어서 움직이는구나 하고 알 수 있었다.

왠지 이렇게까지 한 번 뜯어보고나니 조금 HTML 을 보는 눈..? CSS를 읽는 눈..? ️

여튼 조금은 성장한 것 같은 뿌듯함도 느낄 수 있었다. ✨

✍ 기록

HTML/CSS 강의 1일차 정리본 티스토리 업로드
DACON
백준 문제 풀이 (2742번)
애니메이션 예제 코드 구조 뜯어보기
2025년 회고 다이어리 작성

내 얘기

새해라고 별 거 있겠습니까 그냥 전기장판 켜놓은 따뜻한 침대에서 푹 자고 일어나기~

매 년 다이나믹 하지만 올 한해는 조금 더 다이나믹하지 않았나 싶다.

올 해 초반에는 면접을 많이 봤지만 결국 원하는 회사에 들어가지 못해 자신이 꺾였었고

그러다 그냥 하던 일이나 할까 싶어 다시 시작한 연구간호사는 결국 몇 달 내로 그만두게 되었고

커리어를 어떻게 발전시킬까 라는 고민으로 시작한 AI헬스케어부트캠프에서 다양한 동기들을 만나고

한 해를 마무리 하면서 일오갓생을 쓰고 있다.

나는 챗지피티가 나왔을 당시 완전 초반부터 결제해서 쓰고 있었기 때문에 이 친구와 꽤 돈독한 사이인데,

문득 얘가 생각하는 내 자신이 궁금해져서 물어봤다.

일단 힘들어도 대가리 박고 해보는 사람으로써 지피티가 정확히 봐줬다는게 좀 기특하기도 했다.

내가 되게 좋아하는 문구가 있다.

We can’t direct the wind, but we can adjust the sails.
바람의 방향을 정할 순 없지만, 돛은 조정할 수 있다.

내가 통제할 수 없는 상황은 많지만, 그 상황에 대응하는 방식은 정할 수 있다는 것이다.

인생에서 일어나는 일들 자체는 어차피 내 마음대로 안 되는것이 너무너무너무 많다.

그 상황을 어떻게 버티고 어떤 방향으로 가느냐는 선택할 수 있으니 지금 내가 할 수 있는 선택을 해야한다.

그 선택이 잘한건지 못한건지는 대봐야 아는거고 결국 선택을 했으니 어디로든 나아갈 수 있는 것이다.

최선의 선택이 무엇인지 누가 알 수 있을까? 지금 이 순간은 다들 처음이다.

내년에는 더 행복할겁니다 우리 모두

걱정 많고 탈도 많은 2025년 감사했습니다.

새해 복 많이 받으십시오 ‍♀️

TMI

오늘 오목에서 승우 조교님을 이겼다. (내가 ◼️흑돌!)

연습 많이 해오십시오 조교님.

[HTML 1일차] HTML 기본 개념 ~ 완전 기초 실습

Vogueyoung — Wed, 31 Dec 2025 17:40:03 +0900

H T M L (HyperText Markup Language)

HTML은 웹 페이지의 구조를 정의하는 언어입니다.

이는 글의 제목, 문단, 이미지, 링크와 같은 웹 페이지의 뼈대(구조)를 만드는 역할을 수행합니다.

서버가 HTML 문서를 브라우저에 전달하면, 브라우저는 이를 읽고 화면의 기본 구조를 그립니다.

1. 웹과 HTML의 관계

웹 페이지가 화면에 보이기까지의 기본 흐름은 다음과 같습니다.

서버가 HTML 문서를 만들어 브라우저에 전달합니다.
브라우저는 HTML을 읽고 화면의 기본 구조를 그립니다.

즉 서버 → HTML 전달 → 브라우저 → 화면 구조 생성 입니다.

HTML 기본 구조태그의 기본 규칙

HTML 문서는 항상 일정한 기본 틀을 가집니다.
HTML 문서는 태그(tag)들의 조합으로 구성됩니다.
태그는 <태그이름> 형태로 작성합니다.
각 태그마다 요소의 의미와 역할이 정해져 있습니다.
대부분의 태그는 여는 태그와 닫는 태그로 이루어집니다.

정말 간단한 기본 예시는 다음과 같습니다.

<h1>제목</h1>
<p>문단 내용</p>

2. 태그의 중첩 구조

HTML에서는 태그 안에 또 다른 태그가 들어갈 수 있습니다.
이런 구조를 중첩 구조라고 하며,
이 중첩 구조로 문서의 계층이 만들어집니다.

예시는 다음과 같습니다.

<body>
  <h1>제목</h1>
  <p>내용</p>
</body>

3. HTML 기본 구조

<!DOCTYPE html>
<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    Hello, HTML
  </body>
</html>

빨간색으로 표시한 부분이 <title> 에 입력한 부분,

파란색으로 표시한 부분이 <body> 에 입력한 부분입니다.

요소	설명
<!DOCTYPE html>	문서가 HTML5임을 브라우저에 알리는 선언 (최상단)
<html>	HTML 문서의 최상위 태그 (모든 요소 포함)
<head>	화면에 직접 보이지 않는 설정 영역 (제목, 인코딩, CSS, 메타 정보 등)
<title>	브라우저 탭 및 검색 결과에 표시되는 제목
<body>	브라우저 화면에 실제로 보이는 내용 영역 (텍스트, 이미지, 버튼 등 모든 화면 요소)

4. HTML 문서가 화면에 표시되는 과정

브라우저가 서버에 HTML 요청
서버가 HTML 문서 응답
브라우저가 HTML을 해석(parsing)
화면 구조(DOM) 생성
CSS 적용 → 화면 표시

DOM (Document Object Model)

DOM은 브라우저가 HTML 문서를 해석해 만든 객체 기반 구조입니다.

HTML을 트리 구조로 표현
각 태그와 텍스트가 노드(node)가 됨
HTML = 설계도, DOM = 브라우저 안의 실제 구조
JavaScript가 화면을 조작할 때 사용하는 대상

✨ DOM(문서 객체 모델)은 웹사이트의 지휘 본부입니다.

HTML이 종이에 그린 설계도라면 DOM은 그 설계도대로 브라우저 메모리 속에 실제로 만들어진 입체적인 구조물입니다.

자바스크립트는 이 DOM을 조작해서 화면의 내용을 바꾸거나 움직이는 등 동적인 기능을 구현합니다.

갑자기 왠 자바? 싶을 수 있습니다.

HTML 을 배우다 보면 DOM 설명에서 항상 JavaScript가 같이 등장합니다.

DOM 이라는 개념의 정체를 설명하기 위해서인데요.

DOM은 브라우저가 HTML 문서를 해석해서 만든 화면의 구조 정보이고,

이 구조를 실제로 만지고 바꾸는 도구가 JavaScript 이기 때문에 자연스럽게 같이 나오는 겁니다.

즉 DOM 은 "브라우저가 만들어 둔 화면 구조", JavaScript는 "나중에 그 구조를 조작하는 도구" 입니다.

주요 HTML 태그 (요소)

태그	역할	예시
<p>	문단(Paragraph)을 정의. 일반 텍스트 문단.	<p>내용</p>
<h1> ~ <h6>	제목(Heading)을 정의. h1이 가장 큰 제목.	<h1>제목</h1>
<hr>	수평선(Horizontal Rule)을 삽입.	<hr>
<ul>/<ol> + <li>	순서 없는 목록(ul) / 순서 있는 목록(ol)의 항목(li) 정의.	<ul><li>항목</li></ul>
<table>	표 구조를 정의 (<thead>, <tbody>, <tr>(행), <th>(헤더), <td>(데이터)).	<table>...</table>
<img>	이미지를 삽입. (src, alt 속성 사용)	<img src="image.png" alt="설명">
<a>	하이퍼링크를 생성. (href 속성 사용)	<a href="url">링크</a>
<form>	사용자 입력을 서버로 전송하기 위한 양식 정의.	`<form action="url" method="get
<div>	단순한 컨테이너 역할, 공통 스타일 적용을 위해 요소를 묶을 때 사용.	<div class="intro">...</div>

캡쳐에서는 위에서부터 차례대로 <h1>, <h2>, <h3> 태그를 적용해서 제목의 크기가 다른 모습을 볼 수 있습니다.

문단 내용들은 'lorem' 이라고 입력하면 디자인 시안 작업 시 레이아웃의 시각적 효과를 보여주기 위해 사용하는 의미 없는 라틴어 기반의 더미 텍스트를 쓸 수 있습니다. (lorem100 이라고 입력할 경우 더미 텍스트 100자가 나옵니다!)

요소들은 한번씩 실습해보시는 것이 좋습니다.

추가로, <li> 태그의 예시는 아래와 같습니다.

<ul>
  <li>HTML</li>
  <li>CSS</li>
  <li>JavaScript</li>
</ul>

[일오갓생] 예쁜 화면보다 편한 화면

Vogueyoung — Tue, 30 Dec 2025 23:22:47 +0900

DAY 7

벌써 일주일이나 매일 글을 썼다. 어떻게 했지?

처음엔 매일 강의도 듣고 복습도 해야하고 과제도 하고 데이콘도 해야하는데 일오갓생을 언제 써 싶었지만

15분을 투자해서 (가끔은 더 투자해서) 오늘 강의에 대한 내용과 내 경험을 같이 풀어 쓰는 시간을 가지게 된게

앞으로의 나에게도 도움이 될 알찬 시간이 될 것 같다.

오늘의 갓생 - CSS를 복습하면서

오늘 강의에서 CSS의 기초를 배웠다.
HTML은 웹페이지의 뼈대를 만드는 언어고, CSS는 그 뼈대에 색, 위치, 크기 같은 디자인을 입히는 도구다.

align 같은 기본 정렬 개념이랑, CSS로 화면 요소를 배치하는 방식을 처음으로 만져봤다.
아직은 <div> 위치 옮기는 수준이지만, 화면이 어떻게 구성되는지는 이제 조금 보이기 시작했다.

어떻게 하면 가독성이 좋아지고 하는지를 조금 보면서 예전에 쓰던 eCRF 화면들이 떠올랐다.

eCRF는 이전에 말했듯이 임상시험 데이터를 입력하는 전자 기록 시스템이다.
이 시스템들은 사이트마다 구조도 다르고 사용감도 꽤 많이 달랐다.

어떤 eCRF는 바탕이 회색에 선택하는 창들이 푸른색이었고,

어떤 eCRF는 바탕이 흰색에 주로 쓰는 아이콘이 초록색인 곳도 있었다.

너무 다양하다보니 각 사이트마다 설명해주는 영상이 따로 있고, 그 영상을 다 확인했다는

증명서 같은 것도 받아야 했던 적도 많았다 (왠만하면 가이드북이 함께 pdf 파일로 제공된다)

또 어떤 eCRF는 병원 내부의 정보를 미리 받아 시스템에 연동돼 있어서 검사 결과 단위 같은 게

숫자만 입력해도 자동으로 반영되었지만 어떤 곳은 단위를 전부 연구간호사가 직접 선택해야 했는데..

아래는 실제 사용했던 예시 페이지들이다.

내가 쓰던 페이지. 이런식으로 미리 반영되어있으면 참 좋지만, 어떤 사이트는 일일이 찾아서 눌러야했다.

혹은 암 관련해서 입력해야하는 정보가 있을 때 방향에 대해 입력하는 칸이 저렇게 있다보니 내가 원하는걸 찾으려고 한참 스크롤 했던 적도 있다. 이제보니까 뭔가 확실하게 나눠놔서 실수는 덜하지만 찾는 스트레스가 컸던 것 같다.

특히 eCRF에서 힘들었던 게 혈액검사 수치 단위 입력이었다.
혈액검사 하나만 해도 단위가 전부 다른데 심지어 병원마다도 검사실에서 주로 보는 단위가 다르다.

그 중에서도 몇 개를 짚어서 예를 들자면
WBC는 x10³/µL, RBC는 x10⁶/µL, Hb는 g/dL, Hct는 %, D-dimer는 µg/mL FEU 같은 식이다.

이 단위들이 자동으로 들어오지 않고

eCRF 화면에서 연구간호사가 직접 선택해야 하는 구조인 경우가 많았다.
선택지에는 mg, µg, ng, g/dL, mmol/L, IU/L 같은 비슷한 단위들이 열댓개 넘게 한꺼번에 쭉 나열돼 있어서
정신 없이 마구잡이로 입력하다 보면 잘 못 선택하기 딱 좋은 케이스였다.

입력 방식도 복잡하고 단위 선택도 까다로우니 자주 “왜 이렇게 만들었지”라는 생각을 하게 됐다.

그때는 그냥 일이 힘들어서 불편하다고 느꼈는데 오늘 수업을 들으면서 예전에 들었던 생각들이 떠올랐다.

“이건 병원에서 쓰는 단위랑 자동으로 매칭되면 좋았을 텐데”,
“단위 선택은 여기 말고 옆에 고정해두면 실수가 줄었을 텐데”,
“숫자랑 단위 입력칸을 한 세트로 묶어두면 훨씬 덜 헷갈렸을 텐데”
같은 생각들.

예쁜 화면보다 정확한 데이터가 입력되는 것이 중요한 사이트에서는 어떤 식으로

배치했으면 좋았을지에 대해 생각을 해보게 되었다.

당장 화면을 예쁘게 꾸미는 것보다 사람들이 많이 쓰고 나서
어디서 헷갈리는지, 어디서 실수하는지 사용 데이터가 쌓이고 나서야 진짜 개선을 할 수 있다는 걸

내가 직접 체험해 본 만큼 헬스케어개발공부 이후에

나만의 웹사이트를 구축하거나 혹은 일을 시작하게 되었을 때 이 경험을 최대한 살려봐야겠다.

✍ 기록

HTML/CSS 강의 복습
예제 페이지 수정해보기
과제-CSS Diner 문제 풀이
백준 문제 풀이(5337번) 너무 쉬운 문제라 양심이 찔리지만 오늘은 좀 지쳐서,,
DACON

내 얘기

“집중해서 일하는 것만큼이나, 멀리 물러서서 쉬는 것도 중요하다.”
- 스티브 잡스