ha2yong 님의 블로그

머신러닝 / Pipeline / ColumnTransformer / GridSearchCV

ha2yong — Tue, 18 Nov 2025 19:12:45 +0900

머신러닝 파이프라인(Pipeline), 컬럼 변환기(ColumnTransformer), GridSearchCV 완전 정리

본 문서는 머신러닝 실무에서 가장 많이 사용되는
Pipeline, ColumnTransformer, GridSearchCV를
정의부터 사용법, 주요 메소드, 실전 예시, 그리고 데이터 전처리 및 모델 학습 팁까지
하나의 문서로 정리한 자료입니다.

이 글만 읽으면 머신러닝 워크플로우 전체를 이해하고 바로 적용할 수 있습니다.

────────────────────────────────────────────

1. Pipeline

1-1. Pipeline이란?

여러 단계의 데이터 전처리와 모델 학습 과정을
하나의 흐름(Workflow)으로 묶어주는 Scikit-Learn 기능.

기존 방식(수동으로 전처리 → 모델 학습)은
GridSearchCV, Cross Validation에 문제를 일으킬 수 있지만
Pipeline은 모든 단계를 일관된 구조로 관리해준다.

1-2. 언제 사용하는가?

전처리 + 모델 학습을 하나의 작업으로 묶고 싶을 때
GridSearchCV가 전처리까지 포함하여 교차검증을 수행하도록 만들고 싶을 때
train/test 간 데이터 누수를 방지하고 싶을 때
모델 구성과 파라미터 튜닝을 체계적으로 하고 싶을 때

1-3. 주요 메소드

메소드	설명
fit(X, y)	전체 파이프라인 학습
predict(X)	예측값 반환
predict_proba(X)	확률 기반 예측
named_steps	파이프라인 내부 단계 접근
set_params(**kwargs)	파라미터 변경

1-4. 기본 사용 예시

from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler, OneHotEncoder

numeric_features = ['lead_time', 'adr']
categorical_features = ['hotel', 'deposit_type']

preprocessor = ColumnTransformer([
    ('num', StandardScaler(), numeric_features),
    ('cat', OneHotEncoder(handle_unknown='ignore'), categorical_features)
])

────────────────────────────────────────────

2. ColumnTransformer

2-1. ColumnTransformer란?

컬럼별로 다른 전처리 방법을 적용할 수 있도록 해주는 도구.

예:

숫자 컬럼 → 표준화(StandardScaler)
범주형 컬럼 → OneHotEncoder
특정 컬럼만 log 변환

2-2. 주요 기능

컬럼별로 서로 다른 Pipeline 적용 가능
수치/카테고리/날짜/특수 컬럼을 자동 분리하여 처리
전처리 후 전체 특징 벡터를 하나로 결합

2-3. 주요 메소드

메소드	설명
fit_transform(X)	컬럼별 전처리 + 변환
transform(X)	학습된 전처리로 변환
get_feature_names_out()	OneHot 후 생성된 전체 feature 이름 반환
named_transformers_	내부에 어떤 변환기가 있는지 조회

2-4. 기본 사용 예시

from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler, OneHotEncoder

numeric_features = ['lead_time', 'adr']
categorical_features = ['hotel', 'deposit_type']

preprocessor = ColumnTransformer([
    ('num', StandardScaler(), numeric_features),
    ('cat', OneHotEncoder(handle_unknown='ignore'), categorical_features)
])

────────────────────────────────────────────

3. GridSearchCV

3-1. GridSearchCV란?

모델의 하이퍼파라미터를 자동으로 탐색하는 기능.

여러 파라미터 조합을 시도
Cross Validation 기반 평가
가장 성능 좋은 파라미터를 best_params_로 반환
해당 파라미터가 적용된 전체 Pipeline을 best_estimator_로 반환

3-2. 주요 속성

속성	설명
best_params_	최고 성능의 파라미터 조합
best_estimator_	최고 성능의 Pipeline 전체 모델
best_score_	최고 CV 성능
cv_results_	모든 조합별 성능 상세결과

3-3. param_grid 키 이름 규칙

형식:

'스텝이름__파라미터이름'

예:

'model__n_estimators'
'preprocess__num__scaler__with_mean'

3-4. 기본 사용 예시

from sklearn.model_selection import GridSearchCV

param_grid = {
    'model__n_estimators': [100, 200],
    'model__max_depth': [5, None],
    'model__min_samples_split': [2, 5]
}

grid = GridSearchCV(pipeline, param_grid, cv=5, scoring='roc_auc')
grid.fit(X_train, y_train)

best_model = grid.best_estimator_

────────────────────────────────────────────

4. Pipeline + ColumnTransformer + GridSearchCV 종합 예시

아래 예시는
숫자/범주형 컬럼 전처리 → 랜덤포레스트 분류 → 하이퍼파라미터 탐색
전체 ML Workflow를 하나의 구조로 구현한 실전 예시입니다.

from sklearn.pipeline import Pipeline
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler, OneHotEncoder
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import GridSearchCV, train_test_split
from sklearn.metrics import roc_auc_score, accuracy_score, f1_score

# 1. 데이터 분리
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42)

# 2. 컬럼 정의
numeric_features = X_train.select_dtypes(include=['int64', 'float64']).columns
categorical_features = X_train.select_dtypes(include=['object', 'bool']).columns

# 3. 컬럼 변환기 정의
preprocessor = ColumnTransformer([
    ('num', StandardScaler(), numeric_features),
    ('cat', OneHotEncoder(handle_unknown='ignore'), categorical_features)
])

# 4. 전체 파이프라인 구성
pipeline = Pipeline([
    ('preprocess', preprocessor),
    ('model', RandomForestClassifier())
])

# 5. 하이퍼파라미터 탐색
param_grid = {
    'model__n_estimators': [100, 200],
    'model__max_depth': [5, None],
    'model__min_samples_split': [2, 5]
}

grid = GridSearchCV(
    pipeline, param_grid, cv=5, scoring='roc_auc', n_jobs=-1)

grid.fit(X_train, y_train)
best_model = grid.best_estimator_

# 6. 테스트 성능 평가
y_pred = best_model.predict(X_test)
y_proba = best_model.predict_proba(X_test)[:, 1]

print("Test ROC-AUC:", roc_auc_score(y_test, y_proba))
print("Test Accuracy:", accuracy_score(y_test, y_pred))
print("Test F1:", f1_score(y_test, y_pred))

────────────────────────────────────────────

5. 머신러닝 전처리 및 모델 학습 팁

5-1. 데이터 전처리 팁

숫자형 컬럼은 StandardScaler 또는 MinMaxScaler 적용
범주형은 OneHotEncoding
Boolean은 categorical로 처리하는 것이 일반적
로그 변환은 음수/0 존재 여부 반드시 확인
결측값은 반드시 train/test split 이전에 split하고, Pipeline 안에서 처리

5-2. 모델 학습 팁

RandomForest / XGBoost는 scale에 크게 민감하지 않지만
LinearRegression / SVM / KNN은 반드시 표준화 필요
분류 문제 평가 지표는 Accuracy만 보면 위험
ROC-AUC, F1을 반드시 함께 확인
데이터 누수(Leakage) 방지
Target과 관련된 뒤늦게 알 수 있는 컬럼은 반드시 제거해야 함

5-3. GridSearchCV 팁

param_grid는 Pipeline 스텝 이름 기반으로 작성
scoring='roc_auc'는 이진 분류에서 가장 안정적인 지표
n_jobs=-1로 CPU 전체 사용
cv=5~10이 안정적

5-4. 모델 해석 팁

RandomForest/XGBoost는 feature_importances_로 중요도 확인
ColumnTransformer.get_feature_names_out()으로 실제 feature 목록 생성
SHAP 값을 통해 개별 데이터의 예측 근거 분석
ConfusionMatrix로 FP/FN 패턴 확인

────────────────────────────────────────────

6. 마무리

Pipeline, ColumnTransformer, GridSearchCV는
전처리부터 모델 학습, 하이퍼파라미터 튜닝까지
전체 머신러닝 과정을 일관된 구조로 자동화할 수 있는 핵심 기술입니다.

이 세 가지를 자유자재로 활용하면
데이터 분석 프로젝트의 수준이 한 단계 올라가며,
데이터 누수 방지, 안정적 모델 평가, 자동 최적화 구성이 가능해집니다.

모델 양자화에 대한 생각

ha2yong — Wed, 5 Nov 2025 14:16:35 +0900

최근 AI 최적화 기술을 공부하면서 가장 흥미롭게 느끼는 지점이 있다.
바로 양자화(Quantization)라는 개념이다.

처음에는 단순히,
"모델을 가볍게 해서 엣지 디바이스에 올리기 위한 기술이겠지" 정도로 생각했다.
스마트폰이나 임베디드 환경에서,
적은 리소스로도 딥러닝 모델을 돌리기 위한 압축·경량화 도구쯤으로 말이다.

하지만 공부할수록 이 기술은 단순한 '경량화' 영역이 아니었다.
오히려 AI 모델을 어떻게 더 효율적으로 발전시킬 것인가에 대한
철학이자 방향성에 가깝다는 생각이 들기 시작했다.

"작음 = 약함"일까?

대규모 언어 모델 시대가 열리면서,
‘큰 모델이 곧 강한 모델’이라는 인식이 자연스럽게 자리 잡았다.
실제로 GPT-4, Llama 3, Mistral 등
모든 거대 모델이 매개변수를 키우면서 성능을 끌어올렸다.

당연하게도 우리는 그 흐름에 익숙해졌다.
더 크고, 더 많은 파라미터, 더 많은 GPU.
스케일링 법칙이 증명한 것처럼 모델이 커질수록 성능도 비례했다.

그런데 여기서 양자화를 보면 다른 질문이 생긴다.

"정말 모델은 무조건 커져야만 더 똑똑해지는 걸까?"

만약 우리는 4bit, 8bit, 혹은 더 낮은 정밀도에서도
거의 동일한 성능을 유지시킬 수 있다면?

그렇다면 이는 단순히 “작게 만들기”를 넘어서,
같은 크기에서 더 많은 표현력을 담을 수 있는 기술이라는 의미가 되지 않을까.

반도체의 미세공정과 닮아 있다

반도체 세계에서는 나노 공정이 줄어들수록,
같은 면적에 더 많은 트랜지스터를 몰아넣을 수 있다.
즉, 공정이 작아질수록 효율과 성능이 모두 증가한다.

양자화를 보며 비슷한 흐름을 느낀다.

같은 연산 자원
더 작은 수 표현
동일하거나 유사한 성능 유지

이건 단순히 “작아진다”가 아니라,
밀도를 끌어올리는 과정이라고 볼 수 있다.

그리고 이 밀도 향상은
현재 AI가 맞이하고 있는 다음 성장 국면의 방향성일지도 모른다.

효율이 새로운 성능이다

지금까지 AI 산업은 크기 경쟁을 해왔다.
더 많은 GPU, 더 많은 메모리, 더 큰 파라미터.

하지만 앞으로는 다른 경쟁이 시작될 것이다.

동일한 계산 자원에서
얼마나 많은 지능을 담을 수 있는가.

32bit 대신 8bit로도 똑같이 생각할 수 있는 모델
4bit로도 기존 16bit 모델에 근접하는 언어 능력
더 작지만 실제 환경에서는 더 빠르고 유용한 시스템

이건 단순한 “압축”이 아니라
지능의 효율화를 향한 진화라고 느껴진다.

개인적인 기대

양자화와 프루닝, sparsity, distillation 같은 기술들은
지금은 최적화 영역이라 불리지만,
앞으로는 본질적인 AI 아키텍처 발전 축이 될 것 같다.

거대 모델 시대가 계속되더라도
결국 우리가 가야할 길은 하나다.

"적은 자원으로 더 높은 지능을 구현하는 기술"

그 방향성 위에서 양자화를 보면,
이 기술이 단순한 엣지 기술이 아니라
AI 발전의 또 하나의 스케일링 전략으로 보인다.

체감상
AI의 다음 도약은 단순한 모델 크기 확장보다
이런 효율성 혁신에서 시작될 가능성이 크다.

그리고 바로 그 지점이,
내가 이 기술을 흥미롭게 느끼는 이유다.

마치며

더 크고 강한 모델도 중요하다.
하지만 그만큼 중요한 건
더 똑똑하고, 더 효율적이며, 더 우아한 모델이다.

양자화는 그 우아함을 향해 가는 기술이라는 생각이 든다.

이제는 단순히 “작게 만드는 기술”이 아니라,
지능을 더 촘촘하게 담는 기술이라고 부르고 싶다.

ONNX, TensorRT, 양자화(Quantization) 정리

ha2yong — Wed, 5 Nov 2025 14:04:28 +0900

딥러닝 모델을 실제 환경(특히 Edge AI, GPU 환경)에서 빠르게 실행하기 위해서는 단순히 학습만 잘한다고 끝이 아니다.
현장에서 어떤 방식으로 모델을 배포하고 최적화해야 하는지 이해하는 과정에서 ONNX, TensorRT, 그리고 양자화 개념을 정리했다.

왜 최적화가 필요한가
ONNX란 무엇인가
- 개념
- 왜 사용하는가
- 비유
TensorRT란 무엇인가
- 개념
- 동작 원리
- 비유
양자화(Quantization)란 무엇인가
- 개념
- FP32, FP16, INT8, INT4 비교
- 비유
ONNX → TensorRT → Edge 실행 흐름
실제 적용 시 주의점
정리 및 느낀점

1. 왜 최적화가 필요한가

딥러닝 모델은 연구용 환경에서는 GPU가 빠르게 처리해주지만, 실제 현장에서는 다음 문제들이 발생할 수 있다.

GPU가 없거나 리소스가 제한된 환경
전력 소비 제한(드론, 로봇, 스마트 카메라 등)
실시간 응답 지연 문제(예: 1초 이내 반응 필요)
네트워크 환경이 불안정하여 클라우드 의존이 어려운 경우

따라서 모델을 가볍게, 빠르게, 안정적으로 만드는 과정이 필요하다.

2. ONNX란 무엇인가

개념

ONNX(Open Neural Network Exchange)란 서로 다른 AI 프레임워크(PyTorch, TensorFlow 등)를
공통 포맷으로 변환하는 모델 교환 표준이다.

즉, 모델을 특정 프레임워크에 묶어두지 않고
다양한 플랫폼에서 동작하게 하기 위한 통합 파일 형식이다.

왜 사용하는가

PyTorch에서 만든 모델을 다른 환경(예: C++, TensorRT)에서 사용할 수 있다
모델을 동일한 포맷으로 변환함으로써, 호환성과 재사용성이 높아진다
Edge AI 보드나 NPU 칩들이 ONNX 포맷을 입력으로 받는 경우가 많다

비유

PyTorch 모델이 한국어라면, ONNX는 전 세계 어디서나 읽히는 번역 문서이다
즉, ONNX는 “딥러닝 모델의 PDF 파일”이라고 볼 수 있다

3. TensorRT란 무엇인가

개념

TensorRT는 NVIDIA가 제공하는 딥러닝 추론 최적화 엔진이다.
ONNX 모델을 입력받아, GPU에서 가장 빠르게 실행되도록 변환해준다.

동작 방식

TensorRT는 다음과 같은 작업을 수행한다:

연산 최적화 및 그래프 변환
FP16/INT8 기반 정밀도 조정
커널 선택 및 실행 경로 최적화
불필요 계산 제거 및 레이어 병합

비유

원본 모델은 기본 자동차
TensorRT로 변환하면 엔진 튜닝을 거친 스포츠카가 된다
같은 모델이지만 더 빠르고 더 적은 연료로 달린다

4. 양자화(Quantization)란 무엇인가

개념

딥러닝 모델이 사용하는 숫자의 정밀도를 낮춰
연산량과 메모리 사용을 줄이고 속도를 높이는 기술이다.

FP32(32비트) 대신 FP16, INT8, INT4 같은 형식을 사용한다.

정밀도 비교

형식	설명	특징
FP32	32비트 실수	가장 정확하지만 무거움
FP16	16비트 실수	절반 크기, 속도 향상
INT8	8비트 정수	속도와 효율이 매우 뛰어남
INT4	4비트 정수	매우 빠르지만 정확도 손실 위험

양자화의 효과

모델 메모리 사용 감소
연산량 감소 및 배터리 절약
실시간 처리 지연 감소

비유

고해상도 원본 사진을 압축하는 것과 유사
너무 많이 줄이면 화질이 깨지듯, 양자화도 과하면 정확도가 떨어진다

5. 배포 흐름 정리

일반적인 학습 및 배포 흐름은 아래와 같이 정리된다.

PyTorch 모델 (.pt)
→ ONNX 변환 (.onnx)
→ TensorRT 엔진 최적화 (.plan)
→ GPU / Edge 디바이스에서 초고속 실행

6. 적용 시 주의점

모든 연산이 ONNX로 완벽 변환되지는 않는다
TensorRT가 지원하지 않는 연산이 있을 수 있다(플러그인 필요)
과도한 양자화는 정확도 저하를 유발할 수 있다
테스트 데이터를 이용하여 캘리브레이션이 필요하다
입력 사이즈 고정 모델이 더 빠르다 (동적 입력은 성능 저하 가능)

7. 정리 및 느낀점

이번 내용을 공부하며 느낀 점:

연구용 모델과 실제 서비스용 모델은 완전히 다른 영역이다
ONNX는 플랫폼 독립성 확보에 필수적인 구조
TensorRT는 NVIDIA 환경에서 필수적인 최적화 도구
양자화는 속도와 정확도의 균형을 맞추는 기술
결국 실제 제품 수준의 AI는
"정확도 + 속도 + 전력 효율 + 안정성" 이 4개를 모두 고려해야 한다

이제 목표는
직접 ONNX로 변환하고 TensorRT 엔진을 만들어보며
FP16, INT8 등 다양한 정밀도 설정을 실험하는 것이다.

필요하면 아래도 같이 만들어줄 수 있다:

TensorRT 설치 및 환경 구성 가이드(윈도우/리눅스/Jetson)
PyTorch → ONNX 변환 코드
ONNX → TensorRT 엔진 변환 코드 예제
속도 비교 실험 템플릿
실제 블로그용 이미지/도식 제작

자유도 높은 오픈월드 게임 AI 모델에 대한 아이디어

ha2yong — Tue, 4 Nov 2025 15:11:23 +0900

최근 LLM이 문장을 생성하는 방식에서 흥미로운 점을 발견했다.
LLM은 인간의 언어를 토큰 단위로 이해하고,
다음에 올 가장 그럴듯한 단어를 추론하여 문장을 완성한다.

핵심은 이것이다:

“다음 상태를 확률적으로 예측하고 선택한다.”

즉, 모델은 문맥(Context) 아래에서 미래 상태(Token) 를 생성한다.
그 구조를 인간 플레이어의 행동 시스템에 대입할 수 있을까?

만약 우리가
“플레이어 행동을 토큰처럼 보고,
그 행동의 결과(보상/세계 변화/NPC 반응 등)를 학습”시킬 수 있다면,

언어 대신 행동을 다음 토큰처럼 예측하는 LLM 게임 엔진이 가능할지도 모른다.

아이디어 확장

가정

플레이어 행동 = 토큰
게임 월드 변화 = 문장/맥락
NPC 반응/보상/스토리 변화 = 다음 토큰 후보들의 확률적 분포

그렇다면 아래 구조가 가능하다:

LLM 개념	게임 AI 대응
토큰 시퀀스	플레이어 행동 히스토리
언어 문맥	월드 상태
Next-token prediction	다음 가능한 게임 결과 예측
Beam Search	가능한 게임 전개 Top-K 후보 유지
Self-regression(자기검증)	메타 AI가 월드 붕괴 여부 체크

아이디어 구조

행동 → 결과 세트 학습
- 유저 행동 로그
- NPC 반응, 보상, 스토리 브랜치, 월드 변화
Beam Search 방식 적용
- “다음 가능한 게임 전개” Top-K 생성
- 예: 플레이어가 왕에게 무기를 던졌다
  가능한 후보:
  - (A) 경비대 체포
  - (B) 왕이 마법 방어 후 위협
  - (C) 왕이 겁먹고 도망
  - (D) 왕이 농담으로 받아들임
    (이 때, 확률 분포가 존재할 것)
Self-regression Layer(자기회귀 밸런싱)
- 위 후보들이 “월드를 깨지 않는지” 검증
- 밸런싱 모델이 메타 평가:
  - 게임 세계관 유지?
  - 난이도 곡선 파괴?
  - 몰입도 유지?
  - “악용 루프” 생성 방지?
Root AI + Sub AI 체계
- Root AI: 전체 월드 규칙, 세계관 유지
- NPC AI: 개별 캐릭터 동작 모델
- 밸런스 AI: 스토리/경제/전투 균형 감시
- Physics/Rules AI: 룰 기반 안전장치

구조적으로는 MMORPG 운영팀 + 게임 엔진 + DM(던전마스터) 합친 느낌

필요한 요소

과제설명

행동-결과 데이터	실제 인간 간 상호작용, 게임 로그
밸런스 모델	경제, 스토리, 전투, 보상 시스템
Self-Check AI	세계관 파괴 감시, 논리검증
Hierarchy AI	루트 월드 → NPC/퀘스트/경제 세분화

이건 사실상
게임 디자인 자동화 시스템이기도 하고
LLM 에이전트 멀티유니버스 시뮬레이터와도 닮아 있다.

이런 시스템이 가능하면…

플레이어 행동이 극도로 자유로운 오픈월드 구현
NPC는 “프리-정해진 스크립트” 없이 행동
메타-운영자 없이도 세계관 유지
완전히 Emergent Gameplay 기반 MMO

결과적으로
게임이 “피동적 콘텐츠”가 아니라
스스로 성장하는 “살아있는 세계”가 된다.

왜 이 생각이 중요한가

지금의 오픈월드는 사실 “거짓 자유”다.
플레이어는 이미 설계된 트랙 위에서만 움직인다.

반면 이 아이디어는
“플레이어 행동이 곧 게임 세계의 입력값이 되어,
AI가 세계를 즉석에서 생성하고 유지한다.”

이는 기존 게임 디자인 모델(선형 설계, 분기형 시나리오)을 깨는 접근이다.

콘텐츠는 더 이상 디자이너가 전부 만들지 않는다.
AI가 동작하는 세계 엔진이 생성한다.

맺으며

언어 모델이 문장 속 다음 단어를 예측하듯
미래의 오픈월드 AI는 세계 속 다음 사건을 예측할지도 모른다.

그 세계에서는
플레이어는 단순한 참가자가 아니라,
모델이 학습하는 새로운 토큰 시퀀스의 원천이 된다.

“언어 모델이 문장을 만들듯,
게임 모델은 세계를 만든다.”

그때 게임은 더 이상
제작된 세계가 아니라
살아 움직이는 세계가 될 것이다.

아이디어 소스

LLM 에서 다음에 나올 단어를 추론하는 방법중에 탐욕알고리즘, Beam Search 등이 있다고 한다.
이때 Beam Search는 top-k개의 후보를 유지한채, 다음에 나올 단어로 가장 적합한 후보를 선택한다고 한다.
LLM은 인간의 문맥을 토큰단위로 학습하여 다음 나올 토큰을 선택한다.

만약 모델이 학습하는것이 유저의 행동에 대한 결과라면...?
유저의 행동 -> 결과(보상, 퀘스트, npc대응 등 멀티모달)
유저의 행동과 그에 따른 결과를 세트로 학습한다면 자유도있는 오픈월드를 구현할 수 있지 않을까?

아이디어

1. 유저 행동에 따른 가능성있는 top-k 후보를 추론하도록 구성한다.
2. 그리고 추론결과를 바로 반환하는것이 아니라, 추론 결과가 전체적인 월드를 해치지 않는지 자기회귀(self regression) 하도록 구성한다.

자기회귀에 사용되는 tool을 밸런싱조절 ai 모델로 구성하면 어떨까?

필요사항

1. 사람과 사람간의 행동-결과 데이터

2. 밸런싱 모델(보상 밸런스, 퀘스트 밸런스, 스킬 밸런스)

3. AI와 AI간의 연결 (모든것을 관장하는 Root AI, 그 안에 다양한 AI 모델들..)

bisect 이진탐색 모듈

ha2yong — Thu, 23 Oct 2025 10:33:54 +0900

1️⃣ 개념 정리

bisect는 정렬된 리스트(sorted list) 를 다룰 때,
특정 값이 들어갈 위치를 이진 탐색 방식(O(log N)) 으로 찾아줍니다.

핵심 포인트: 리스트를 “정렬 상태로 유지한 채로” 삽입할 때 매우 유용

2️⃣ 기본 사용법

import bisect

nums = [1, 3, 4, 7, 9]
x = 5

# 삽입할 위치 찾기
pos = bisect.bisect(nums, x)
print(pos)   # 3

→ 5는 인덱스 3 위치에 들어가야 [1,3,4,5,7,9]가 정렬 상태를 유지합니다.

⚙️ 3️⃣ 주요 함수 4가지

함수	동작	설명
bisect_left(a, x)	왼쪽 기준 삽입 위치	동일 값이 있을 때 왼쪽으로 붙음
bisect_right(a, x) 또는 bisect(a, x)	오른쪽 기준 삽입 위치	동일 값이 있을 때 오른쪽으로 붙음
insort_left(a, x)	실제로 리스트에 삽입 (왼쪽 기준)	자동으로 정렬 유지
insort_right(a, x) 또는 insort(a, x)	실제로 리스트에 삽입 (오른쪽 기준)	자동으로 정렬 유지

4️⃣ 예시로 이해하기

import bisect

arr = [10, 20, 30, 30, 40]

print(bisect.bisect_left(arr, 30))   # 2  ← 30 앞에 삽입
print(bisect.bisect_right(arr, 30))  # 4  ← 30 뒤에 삽입

bisect.insort(arr, 25)
print(arr)  # [10, 20, 25, 30, 30, 40]

# 4 ← 30 뒤에 삽입 bisect.insort(arr, 25) print(arr) # [10, 20, 25, 30, 30, 40]

⏱️ 5️⃣ 시간 복잡도

삽입 위치 찾기 (bisect_left, bisect_right) → O(log N)
→ 이진 탐색으로 위치를 찾음
실제 삽입 (insort) → O(N)
→ 위치 찾기는 빠르지만, 리스트는 배열 구조라 한 칸씩 밀어야 함

6️⃣ 실무에서 어떻게 쓰이나?

상황	왜 bisect 쓰는가
데이터가 항상 정렬된 상태로 유지돼야 할 때	매번 sort()보다 효율적
순위(rank), 중간값(median), 통계 백분위 계산	빠른 위치 찾기
시간/점수/가격 같은 정렬된 이벤트 스트림	새 데이터 실시간 삽입
이진 탐색 기반 조건 검사	직접 while 루프 짤 필요 없음

7️⃣ 예제 — 정렬된 리스트에 값 삽입

import bisect

scores = [10, 30, 50, 70, 90]
new_score = 65

idx = bisect.bisect_left(scores, new_score)
scores.insert(idx, new_score)
print(scores)  # [10, 30, 50, 65, 70, 90]

8️⃣ 예제 — 범위 내 원소 개수 구하기 (이진 탐색 응용)

예를 들어 [1,3,5,7,9,11,13] 에서 5 ≤ x ≤ 10 인 원소의 개수를 찾고 싶다면:

from bisect import bisect_left, bisect_right

arr = [1,3,5,7,9,11,13]
left = bisect_left(arr, 5)
right = bisect_right(arr, 10)
print(right - left)  # 3 (5,7,9)

→ O(log N) 만에 범위 개수 계산 가능 (리스트 길이에 비례하지 않음)

9️⃣ 예제 - 정렬된 리스트에서 특정 숫자가 존재하는지 여부

정렬된 리스트 arr에서 어떤 값 x가 존재하는지는 이렇게 판단할 수 있어요

from bisect import bisect_left

# 1️⃣ 정렬된 상태의 리스트
arr = [1, 3, 4, 7, 9, 11]

# 2️⃣ x가 들어갈 위치를 이진 탐색으로 찾는다
x = 7
idx = bisect_left(arr, x)

# 3️⃣ 그 위치가 리스트 범위 안에 있고 arr[idx] == x 이면 존재
if idx < len(arr) and arr[idx] == x:
    print("✅ 존재함")
else:
    print("❌ 존재하지 않음")

⏱️ 시간복잡도 비교

방법	복잡도	설명
x in arr (list)	O(N)	선형탐색
bisect_left + 비교	O(log N)	이진탐색
x in set	평균 O(1)	해시 탐색 (정렬 불필요)

9️⃣ 요약

항목설명

모듈	import bisect
핵심 기능	정렬 리스트 내 빠른 삽입 위치 탐색
시간 복잡도	O(log N) (탐색), O(N) (삽입)
주요 함수	bisect_left, bisect_right, insort_left, insort_right
비슷한 내장 함수	list.index() (O(N), 정렬 불필요)
대표 사용 사례	실시간 정렬 유지, 순위 계산, 범위 개수 세기

[순차탐색] in 연산자 시간복잡도 비교

ha2yong — Thu, 23 Oct 2025 10:18:43 +0900

https://wiki.python.org/moin/TimeComplexity

TimeComplexity - Python Wiki

This page documents the time-complexity (aka "Big O" or "Big Oh") of various operations in current CPython. Other Python implementations (or older or still-under development versions of CPython) may have slightly different performance characteristics. Howe

wiki.python.org

주제: in 연산자는 어떤 자료형을 탐색하느냐에 따라 시간복잡도의 차이가 발생한다.

1) list / tuple / deque

구조: 연속 배열(리스트/튜플), 양방향 연결 버퍼(deque)
동작: 왼쪽부터 순차 비교(Linear scan) → 값이 같을 때까지 하나씩 == 비교
복잡도: 평균/최악 O(N)
비고: 정렬된 리스트라면 in 대신 이진탐색(예: bisect)을 쓰면 O(log N) 로 가능.
단, in 자체는 이진탐색을 쓰지 않습니다.

x in [a, b, c, ...]     # O(N)
x in tuple_of_items     # O(N)
x in deque_of_items     # O(N)

2) set / dict

구조: 해시 테이블
동작: hash(x)로 버킷을 계산해 해당 버킷에서만 비교
복잡도: 평균 O(1), 최악(충돌 심함) O(N)
(파이썬은 리사이즈·로드팩터 관리로 평균 O(1)를 잘 유지)
주의: 원소는 해시 가능(불변·hashable) 해야 함. list/dict는 안 되고, tuple(내부도 불변이면)는 가능.
딕셔너리의 in: 키에 대한 멤버십 검사입니다.
x in my_dict → x in my_dict.keys()와 동일(평균 O(1)).
- x in my_dict.values() / x in my_dict.items() 는 선형탐색 O(N) 이라 느립니다.

x in {a, b, c}          # 평균 O(1)
key in {"k": 1}         # 평균 O(1)  (키 검사)
val in {"k": 1}.values()# O(N)       (값 검사)

(해시 기반이 O(1)인 이유)

set/dict는 버킷 배열을 두고, hash(x) % capacity 로 위치를 바로 찾아갑니다.
동일 해시의 원소가 많아지면 충돌 체인을 따라 비교하므로 느려질 수 있어 로드팩터 임계에서 자동 리사이즈합니다.
평균적으로 충돌 길이를 짧게 유지하여 상수 시간에 가깝게 동작합니다.

3) str (문자열)

단일 문자 검사: ch in text → 선형 탐색, 평균 O(N)
부분문자열 검사: pat in text → 전통적으론 O(N·M) 이지만 CPython은 Two-Way 등 최적화로 평균 O(N)에 가깝게 동작.
비고: 매우 큰 텍스트에서는 re(정규식), find(), index() 등 전용 알고리즘을 쓰는 게 더 낫습니다.

'a' in 'banana'       # O(N)
'ana' in 'banana'     # ~O(N) (내부 최적화)

4) 왜 “list→set 변환”이 빠를까?

멤버십 검사를 여러 번 할 때는, 한 번의 변환 비용(O(N))을 내고 평균 O(1) 조회를 반복하는 편이 압도적으로 유리합니다.

리스트에서 M번 검사: O(M·N)
세트로 변환 후 M번 검사: O(N) + O(M)

의사결정 팁
– 한 번만 검사하면: 그냥 리스트에서도 괜찮음
– 많이 검사하면(M이 크면): set으로 변환이 유리
– 이미 키만 검사하면: dict 키 집합을 그대로 활용

menus = ['ramen', 'sushi', 'pasta', ...]   # N개
queries = ['sushi', 'taco', ...]           # M개

# 느린 버전: O(M·N)
for q in queries:
    if q in menus:
        ...

# 빠른 버전: O(N) + O(M)
menu_set = set(menus)
for q in queries:
    if q in menu_set:   # 평균 O(1)
        ...

5) 요약 표

컨테이너 x in container 평균 복잡도 내부 구조 비고

컨테이너	x in container 평균 복잡도	내부 구조	비고
list / tuple / deque	O(N)	배열/연결버퍼	선형 탐색
set	O(1)	해시 테이블	원소는 hashable 필요
dict	O(1) (키)	해시 테이블	x in d는 키 검사
dict.values() / .items()	O(N)	선형 탐색	값/쌍 검사
str (문자/부분문자열)	~O(N)	특화 검색	내부 최적화 있음

참고:

이진탐색시에 문자열 "가나다" 도 크기 비교가 가능하다.

한글을 유니코드값으로 바꿔서 크기를 비교함

2. collections 활용 패턴

ha2yong — Wed, 22 Oct 2025 13:58:38 +0900

1. Counter — 토큰/클래스 빈도 분석, 통계 기반 전처리

자연어 처리(NLP)에서 단어 빈도(Word Frequency) 계산
분류(Classification) 문제에서 클래스 불균형 확인

from collections import Counter

# 예: 토큰 빈도 계산
tokens = ["apple", "banana", "apple", "grape", "banana", "apple"]
word_freq = Counter(tokens)

print(word_freq.most_common(2))  # [('apple', 3), ('banana', 2)]

# 예: 데이터셋 클래스 비율 확인
labels = ["cat", "dog", "cat", "bird", "cat", "dog"]
label_dist = Counter(labels)

for cls, cnt in label_dist.items():
    print(f"{cls}: {cnt/len(labels):.2%}")

✅ 활용 포인트

토큰 출현 확률(P(word)) 계산 → 언어 모델 확률분포에 사용
클래스 imbalance 체크 후 가중치(weighted loss) 조정
TF-IDF 전처리 시 빈도 기반 정규화 계산

2. deque — 실시간 데이터 스트림·슬라이딩 윈도우 버퍼

영상/음성/센서 데이터를 최근 N개만 유지하며 스트림 처리
실시간 추론에서 FPS 고정 or moving average 계산

from collections import deque
import numpy as np

# 최근 30프레임만 유지하는 슬라이딩 윈도우 버퍼
window = deque(maxlen=30)

for frame in stream_generator():  # 예: 실시간 카메라 프레임
    value = model.predict(frame)
    window.append(value)

    # 최근 30프레임 평균값으로 smoothing
    smoothed = np.mean(window)
    print(f"Smoothed output: {smoothed:.2f}")

✅ 활용 포인트

O(1)로 양끝 삽입/삭제 가능 → FPS 고정 루프에서 효율적
LSTM, RNN 등에서 시퀀스 윈도우 관리에 자주 사용됨
실시간 anomaly detection에서도 sliding window 기반 통계 계산

3. defaultdict — 그룹화, 임시 캐시, 파이프라인 중간 결과 저장

데이터셋을 특정 기준으로 그룹핑 (e.g., 클래스별 샘플)
전처리 단계에서 중간 캐시 생성

from collections import defaultdict

samples = [
    ("cat", "img001.jpg"),
    ("dog", "img002.jpg"),
    ("cat", "img003.jpg"),
    ("bird", "img004.jpg"),
]

grouped = defaultdict(list)
for label, path in samples:
    grouped[label].append(path)

print(grouped["cat"])  # ['img001.jpg', 'img003.jpg']

✅ 활용 포인트

데이터 로더(DataLoader) 전 단계에서 클래스별 파일 분류
학습 로그나 실험 결과를 태그별로 자동 그룹핑
json이나 yaml 구성 파싱 시 누락 키에 안전한 초기화

4. OrderedDict — 모델 레이어 순서, LRU 캐시, 설정 트래킹

PyTorch에서 모델 레이어 순서 보존 (nn.Sequential)
최근 사용된 결과 캐싱(LRU)
실험 설정(config) 순서를 명시적으로 기록

from collections import OrderedDict
import torch.nn as nn

model = nn.Sequential(OrderedDict([
    ('conv1', nn.Conv2d(3, 16, 3, padding=1)),
    ('relu1', nn.ReLU()),
    ('conv2', nn.Conv2d(16, 32, 3, padding=1)),
    ('relu2', nn.ReLU())
]))

print(model)

✅ 활용 포인트

모델 정의 순서가 정확히 일치해야 reproducibility 확보
학습 로그나 설정 저장 시 순서 보존이 중요할 때
OrderedDict.move_to_end() 활용 → 캐시, 최근 접근 관리

5. ChainMap — 다중 설정(environment + config + override)

AI 프로젝트는 여러 환경(config) 파일을 계층적으로 관리
(예: defaults.yaml, local.yaml, args, env)

from collections import ChainMap
import os

defaults = {'batch_size': 32, 'lr': 0.001}
user_cfg = {'lr': 0.0005}
env_cfg = {'batch_size': int(os.getenv('BATCH', 64))}

config = ChainMap(env_cfg, user_cfg, defaults)

print(config['batch_size'])  # 환경 변수 > 사용자 > 기본값 순서

✅ 활용 포인트

모델 학습 설정 우선순위 관리
실험 파라미터 병합 시 충돌 최소화
Hydra, OmegaConf 같은 config 라이브러리의 핵심 개념과 동일

6. namedtuple — lightweight 데이터 구조 (벡터, 설정, 예측 결과)

딥러닝 inference 결과를 (label, score, bbox) 등으로 관리
벡터/포인트 데이터 구조 표현

from collections import namedtuple

Prediction = namedtuple('Prediction', ['label', 'score', 'bbox'])
preds = [
    Prediction('cat', 0.97, (10, 20, 100, 200)),
    Prediction('dog', 0.83, (30, 40, 120, 240))
]

for p in preds:
    print(f"{p.label}: {p.score*100:.1f}%")

✅ 활용 포인트

객체 생성 오버헤드 없이 가벼운 구조체처럼 사용
PyTorch Dataset/Batch 내에서 sample 구조 관리
불변이므로 멀티프로세싱(shared memory)에서도 안전

요약표

자료구조	활용 분야	대표 예시
Counter	NLP, 데이터 통계	단어/클래스 빈도, TF-IDF
deque	실시간 처리, 슬라이딩 윈도우	FPS smoothing, stream buffer
defaultdict	데이터 그룹화, 캐시	클래스별 샘플 분류
OrderedDict	모델 정의, 캐시	nn.Sequential, LRU cache
ChainMap	설정 병합	config/환경변수 통합
namedtuple	경량 데이터 구조	예측 결과, 좌표, 설정

1. 파이썬 고급 자료구조 collections

ha2yong — Wed, 22 Oct 2025 13:55:25 +0900

클래스	핵심 목적	주요 특징/ 사용 예시
namedtuple	튜플의 필드에 이름 부여	불변(immutable) 구조, 클래스처럼 필드 접근
deque	양쪽에서 빠른 삽입/삭제	스택·큐·슬라이딩 윈도우 구현에 최적
Counter	요소 개수 세기	리스트/문자열의 빈도 분석
defaultdict	기본값을 갖는 딕셔너리	존재하지 않는 키 접근 시 자동 초기화
OrderedDict	순서가 유지되는 딕셔너리	LRU Cache 등 순서 기반 로직 구현
ChainMap	여러 딕셔너리를 묶어 하나처럼 다룸	다중 스코프 환경에서 키 검색
UserDict, UserList, UserString	커스텀 자료형 구현용 Wrapper	상속/오버라이드로 사용자 정의 자료구조 만들 때

1. namedtuple

튜플은 순서로만 접근한다.
하지만 필드 이름으로 접근하면 코드 가독성이 훨씬 좋아진다.

from collections import namedtuple

Point = namedtuple('Point', ['x', 'y'])
p = Point(10, 20)

print(p.x, p.y)   # 10 20

✅ 메모리 효율 높음
✅ 클래스보다 가볍고 빠름
✅ 불변(immutable)

2. deque — 양방향 큐 (Double-ended Queue)

리스트는 중간 삽입/삭제가 느리지만,
deque는 양쪽 끝 삽입/삭제가 모두 O(1) 이다.

from collections import deque

dq = deque([1, 2, 3])
dq.append(4)        # 오른쪽 삽입
dq.appendleft(0)    # 왼쪽 삽입
dq.pop()            # 오른쪽 삭제
dq.popleft()        # 왼쪽 삭제

✅ 큐, 스택, 슬라이딩 윈도우 등에 활용
✅ 내부적으로 양방향 링크드리스트 기반

3. Counter — 항목의 빈도(개수) 계산

from collections import Counter

cnt = Counter("banana")
print(cnt)          # Counter({'a': 3, 'n': 2, 'b': 1})
print(cnt.most_common(2))  # [('a', 3), ('n', 2)]

✅ 문자열, 리스트, 로그 등 빈도 분석에 강력
✅ 덧셈/뺄셈 연산도 가능

a = Counter("hello")
b = Counter("world")
print(a + b)  # Counter({'l': 3, 'o': 2, 'h': 1, 'e': 1, 'w': 1, 'r': 1, 'd': 1})

4. defaultdict — 기본값이 있는 딕셔너리

from collections import defaultdict

d = defaultdict(int)  # 기본값 0
d['apple'] += 1
print(d)  # defaultdict(<class 'int'>, {'apple': 1})

✅ 키가 없을 때 자동 초기화 (KeyError 없음)
✅ 기본값 타입은 int, list, set 등 지정 가능

words = ['apple', 'banana', 'apple']
group = defaultdict(list)
for w in words:
    group[w[0]].append(w)
# {'a': ['apple', 'apple'], 'b': ['banana']}

5. OrderedDict — 순서를 기억하는 딕셔너리

파이썬 3.7 이상부터 기본 dict도 순서를 유지하지만,
OrderedDict는 순서 조작 메서드(move_to_end 등) 이 추가로 제공된다.

from collections import OrderedDict

od = OrderedDict()
od['a'] = 1
od['b'] = 2
od.move_to_end('a')   # a를 맨 뒤로
print(od)             # OrderedDict([('b', 2), ('a', 1)])

✅ LRU Cache 구현 시 자주 사용됨

6. ChainMap — 여러 딕셔너리 묶기

from collections import ChainMap

defaults = {'theme': 'light', 'lang': 'en'}
user = {'lang': 'ko'}
config = ChainMap(user, defaults)

print(config['lang'])   # ko (user 우선)
print(config['theme'])  # light (defaults에서 가져옴)

✅ 여러 설정 파일, 환경 변수 계층 구조 관리에 유용
✅ 조회 시 앞쪽 딕셔너리부터 탐색

7. UserDict, UserList, UserString — 사용자 정의 확장

from collections import UserDict

class MyDict(UserDict):
    def __getitem__(self, key):
        print(f"Accessing {key}")
        return super().__getitem__(key)

d = MyDict({'a': 1})
print(d['a'])

✅ 커스텀 자료형 제작 시 안전하고 직관적

[프로젝트 후일담] Docker 기반 런타임

ha2yong — Wed, 1 Oct 2025 14:14:57 +0900

요약

“Docker를 활용하여 리눅스 기반 런타임을 구현하였으며, 서비스별 의존성을 분리하고, 개발환경 차이에 따른 재현성을 높였으며, 추후 배포 시 이식성을 고려하였다.”

즉,

리눅스 기반 런타임: Docker Desktop(WLS2) 위에서 리눅스 컨테이너 실행
의존성 분리: YOLO, STT, LangGraph 각각 격리된 환경
재현성: 팀원/환경이 달라도 동일한 결과
이식성: 로컬 ↔ 서버 배포가 동일 이미지로 가능

A-EYE의 Docker 구조 한눈에

컨테이너 1: YOLO (객체·세그멘테이션 추론)
- HTTP API (예: POST /infer) 혹은 WebSocket로 프레임/이미지 받음 → 결과 JSON 반환
컨테이너 2: STT (음성 인식)
- WebSocket(실시간 스트림) 또는 REST(파일 업로드)로 음성 → 텍스트 반환
컨테이너 3: LangGraph (에이전트/NLP)
- POST /perception/gaze/push, POST /perception/yolo/push, POST /image/push 등으로 이벤트/프레임/검출 JSON 수신 → 추론/대화/행동 결정
컨테이너 4: FastAPI 백엔드 (허브)
- 호스트(사용자/클라이언트)에서 들어오는 요청을 받아 YOLO/STT/LangGraph와 통신하고 응답을 묶어서 반환
- 파일 저장소/캐시/인증/라우팅 등 “게이트웨이” 역할

컨테이너들은 같은 가상 네트워크(bridge) 위에서 돌아가며, 컨테이너 이름으로 서로를 참조합니다(예: FastAPI 내부 코드에서 http://yolo:8090).

왜 Docker를 썼나? (요점 4가지)

분리: 모델/런타임/라이브러리를 서비스별로 격리 → 서로 간 충돌/의존성 꼬임 방지
재현성: 팀원이 바뀌거나 머신이 바뀌어도 docker run / compose up만으로 동일 환경 재현
이식성: 로컬(Windows) ↔ 리눅스 서버(온프레/클라우드) 동일한 이미지로 배포
자원제어: GPU는 YOLO만, CPU는 STT만 같은 방식으로 자원 분배가 쉬움

“리눅스 기반 로컬 서버인가요?”

윈도우에서 Docker Desktop을 쓰면, 내부적으로 WSL2(리눅스 경량 VM) 위에서 리눅스 컨테이너가 돌아갑니다.
- 즉, 체감상 “내 PC에서 로컬 서버”지만, 런타임은 리눅스라고 보면 정확해요.
- 포트 매핑 덕분에 **호스트에서는 http://localhost:포트**로 접근합니다.
같은 스택을 리눅스 서버로 옮겨도 거의 그대로 동작합니다(경로/드라이버만 맞추면 OK).

통신 흐름(쉽게)

클라이언트 → FastAPI: 이미지/오디오/명령 요청
FastAPI → YOLO/STT: 필요한 모델 서비스로 요청 전달
FastAPI → LangGraph: YOLO 검출 JSON·시선/깊이 이벤트·이미지 프레임을 이벤트로 push
LangGraph → FastAPI: 의도/답변/행동 반환 → 클라이언트로 응답

컨테이너 내부에서는 http://서비스이름:포트로, 호스트(윈도우 브라우저 등)에서는 http://localhost:포트로 접근합니다.

운영 팁

네트워크: Compose 기본 bridge 사용. 컨테이너끼리는 http://서비스이름:포트, 호스트는 http://localhost:포트.
헬스체크: /health 같은 간단한 엔드포인트를 모든 서비스에 두면 자동 재시도/의존성 대기 용이.
로그/볼륨: 모델 가중치, 입력/출력 미디어는 볼륨 매핑해서 컨테이너 재시작에도 유지.
자원 분리: YOLO만 GPU, STT/LangGraph/Backend는 CPU로도 충분한 경우가 많아 비용/발열 절약.
배포 전환: 로컬에서 검증한 compose를 리눅스 서버에 그대로 가져가도 90% 이상 그대로 동작(경로/포트·보안만 맞추기).

핵심 요약

A-EYE는 서비스별 컨테이너(YOLO, STT, LangGraph, FastAPI)로 구성되고, FastAPI가 허브가 되어 상호 통신을 중재합니다.
윈도우에서 돌려도, 실제 컨테이너 런타임은 WSL2 리눅스 위에서 동작합니다(= 로컬 리눅스 서버처럼 동작).
같은 이미지를 리눅스 서버에도 그대로 이식 가능—이게 Docker 채택의 가장 큰 이점입니다.

[프로젝트] 7. 프로젝트 트러블슈팅 및 향후과제

ha2yong — Wed, 24 Sep 2025 03:37:59 +0900

프로젝트명: 시선추적 + 월드깊이맵 + YOLOE 객체탐지 + STT + LLM (LangGraph) 융합 시스템
작성일: 2025년 9월

1. 개요

본 프로젝트는 시선추적(eye tracking)과 월드카메라 깊이맵 추정을 결합하고, YOLOE 기반 객체탐지, Whisper STT, LangGraph LLM을 연계하여, 사용자의 응시 기반 인터랙션을 구현하는 것을 목표로 한다.
개발 과정에서 다양한 기술적 트러블이 발생하였으며, 이를 해결하기 위한 트러블슈팅 결과를 아래와 같이 정리한다.

2. 주요 트러블 및 해결 방안

2.1 멀티 카메라 동기화 및 지연 문제 (최고 중요도)

문제점: Eye cam과 World cam 간 타이밍 불일치 및 Wi-Fi 전송 지연(최대 7초).
원인: 저성능 하드웨어(Raspberry Pi Zero W)와 PyAV/ OpenCV 백엔드의 버퍼링.
해결책:
- PyAV 백엔드 사용 + stimeout, rtsp_transport=tcp 적용.
- 해상도/비트레이트 축소 (640×480, 1.2Mbps).
- cv2.imshow 제거 및 로컬 CPU 부담 최소화.

2.2 시선벡터 추정 정확도 문제

문제점: Mediapipe 기반 홍채 평면 법선 추정 시 노이즈가 크고, 두 눈 벡터 교차점이 불안정.
해결책:
- EMA(Exponential Moving Average) 적용으로 벡터 스무딩.
- 두 눈 교차점 대신 중간점(pmid) 활용.
- 향후 딥러닝 기반 모델(RT-GENE, Gaze360) 도입 검토.

2.3 월드 깊이맵 정합 문제

문제점: Depth-Anything V2 추정 결과와 Intrinsic/Extrinsic 불일치로 인해 광선–깊이맵 매칭 불안정.
해결책:
- 체커보드 기반 eye→world extrinsic 추정 적용.
- ray_depth_intersection_best_of_two() 사용으로 광선 방향 양쪽 탐색.
- 절대 깊이 보정식 도입: Dcorr=a⋅Dpred+bD_{corr} = a \cdot D_{pred} + b.

2.4 YOLOE 객체탐지 연동 문제

문제점: YOLO 서버 응답 포맷 불일치로 파싱 오류 및 응시점 근처 객체 탐지 실패.
해결책:
- _normalize_detections() 모듈 개발 → 응답 형식 통일.
- 응시점 좌표 기반 ROI 탐지 및 근접 객체 우선 선택.
- YOLOE 모델 교체 시에도 API 호환성 유지.

2.5 STT 및 웨이크워드 연계 문제

문제점: Whisper STT의 높은 리소스 소비로 항상 대기 시 과부하 발생.
해결책:
- Picovoice Porcupine으로 웨이크워드(Hotword) 감지 후 Whisper STT 실행 구조 도입.
- 동일 마이크 인덱스를 사용하여 STT 정확도 확보.
- Whisper 모델 크기(tiny/base 우선) 조정으로 리소스 최적화.

2.6 LangGraph LLM 연동 안정성 문제

문제점: STT 결과 전송 시 HTTP 타임아웃 및 과도한 요청 발생.
해결책:
- LGClient.push_gaze()에 요청 간격 제한(throttle_s=0.5) 적용.
- 예외 처리(try/except)를 통한 안정성 확보.
- 세션 ID(alpha) 기반 상태 관리.

2.7 시스템 리소스 관리 문제

문제점: Eye tracking, VDA, YOLO, Whisper 동시 실행 시 OOM 및 성능 저하.
해결책:
- VDA 추론 시 max_res, input_size 제한.
- GPU 환경에서 half precision(torch.autocast) 적용.
- Whisper 모델 크기 및 GUI 옵션(--no_gui) 조정으로 CPU 사용량 절감.

3. 결론

본 프로젝트는 초기 단계에서 카메라 동기화·정합 문제와 시선 추정 정확도 부족이 가장 큰 난관이었다.
그러나 EMA 기반 스무딩, Extrinsic 캘리브레이션, PyAV 최적화 등을 통해 안정성을 확보하였다.

STT/웨이크워드 및 YOLOE 연동에서도 파싱/리소스 문제를 해결하여, 현재는 “시선 → 깊이맵 → 객체탐지 → STT → LLM 연계”까지 일관된 파이프라인이 동작 가능한 수준에 도달하였다.

향후 발전 방향은 딥러닝 기반 시선추정 모델 도입, 경량화된 Whisper 대체 모델 적용, YOLOE의 open-vocabulary 탐지 활용 등이 될 것이다.

ha2yong 님의 블로그

머신러닝 / Pipeline / ColumnTransformer / GridSearchCV

머신러닝 파이프라인(Pipeline), 컬럼 변환기(ColumnTransformer), GridSearchCV 완전 정리

1. Pipeline

1-1. Pipeline이란?

1-2. 언제 사용하는가?

1-3. 주요 메소드

1-4. 기본 사용 예시

2. ColumnTransformer

2-1. ColumnTransformer란?

2-2. 주요 기능

2-3. 주요 메소드

2-4. 기본 사용 예시

3. GridSearchCV

3-1. GridSearchCV란?

3-2. 주요 속성

3-3. param_grid 키 이름 규칙

3-4. 기본 사용 예시

4. Pipeline + ColumnTransformer + GridSearchCV 종합 예시

5. 머신러닝 전처리 및 모델 학습 팁

5-1. 데이터 전처리 팁

5-2. 모델 학습 팁

5-3. GridSearchCV 팁

5-4. 모델 해석 팁

6. 마무리

모델 양자화에 대한 생각

"작음 = 약함"일까?

반도체의 미세공정과 닮아 있다

효율이 새로운 성능이다

개인적인 기대

마치며

ONNX, TensorRT, 양자화(Quantization) 정리

목차

1. 왜 최적화가 필요한가

2. ONNX란 무엇인가

개념

왜 사용하는가

비유

3. TensorRT란 무엇인가

개념

동작 방식

비유

4. 양자화(Quantization)란 무엇인가

개념

정밀도 비교

양자화의 효과

비유

5. 배포 흐름 정리

6. 적용 시 주의점

7. 정리 및 느낀점

자유도 높은 오픈월드 게임 AI 모델에 대한 아이디어

아이디어 확장

가정

아이디어 구조

필요한 요소

이런 시스템이 가능하면…

왜 이 생각이 중요한가

맺으며

아이디어 소스

아이디어

필요사항

bisect 이진탐색 모듈

1️⃣ 개념 정리

2️⃣ 기본 사용법

⚙️ 3️⃣ 주요 함수 4가지

4️⃣ 예시로 이해하기

⏱️ 5️⃣ 시간 복잡도

6️⃣ 실무에서 어떻게 쓰이나?

7️⃣ 예제 — 정렬된 리스트에 값 삽입

8️⃣ 예제 — 범위 내 원소 개수 구하기 (이진 탐색 응용)

9️⃣ 예제 - 정렬된 리스트에서 특정 숫자가 존재하는지 여부

9️⃣ 요약

[순차탐색] in 연산자 시간복잡도 비교

주제: in 연산자는 어떤 자료형을 탐색하느냐에 따라 시간복잡도의 차이가 발생한다.

1) list / tuple / deque

2) set / dict

(해시 기반이 O(1)인 이유)

3) str (문자열)

4) 왜 “list→set 변환”이 빠를까?

5) 요약 표