일정 : 3/13(월) ~ 3/20(금) 발표 일정: 3/20(금)

데이터 분석부터 모델링, 그리고 이를 활용한 FastAPI + JS 웹 서비스까지 구축한 전 과정을 정리하려고한다.

성과 : 리더보드 MAE 0.140.26(최종 3등)

📌 프로젝트 개요

건강 지표를 입력받아 0~1 사이의 스트레스 점수를 예측하는 회귀 모델 + 웹앱 제작. 7조 개발바닥 (조장 곽지은, 조원 정현희)

1.상식의 실패 — 가설이 먼저 틀렸다

컬럼 이름을 보고 가설을 먼저 세웠다.

핵심 인사이트: 수면·흡연처럼 직관적인 변수가 생각보다 상관이 낮았고(p=0.082), 오히려 혈압·병력 같은 생체 복합 신호가 더 유의미했다. (p<0.05) → 생활습관 변수 노이즈 배제, 생체 지표 중심으로 피벗했다.

2.주요 컬럼 & 처리 결정

결측률이 높은 컬럼이 핵심 판단 포인트였다.

3.피처 엔지니어링

파생변수 3종

def engineering_refined(df):
    df = df.copy()

    # BMI: 키·몸무게를 하나의 체질량 지표로
    df['bmi'] = df['weight'] / (df['height'] / 100) ** 2

    # 맥압: 심혈관 긴장 지표
    df['pulse_pressure'] = (
        df['systolic_blood_pressure'] - df['diastolic_blood_pressure']
    )

    # 평균동맥압(MAP): 실제 장기에 전달되는 혈압
    df['MAP'] = (
        df['systolic_blood_pressure'] + 2 * df['diastolic_blood_pressure']
    ) / 3

    # 범주형 결측 → 'None' 문자열 (정보로 활용)
    fill_cols = [
        'medical_history', 'family_medical_history',
        'smoke_status', 'activity', 'sleep_pattern'
    ]
    for col in fill_cols:
        if col in df.columns:
            df[col] = df[col].fillna('None').astype(str)

    return df

혈압 수치를 날 것으로 넣는 것보다, 두 값의 관계를 표현하는 MAP·맥압이 더 유의미한 신호를 줬다. medical_history는 결측(0.465)과 질환 있음(0.495)이 다른 그룹이므로 절대 드랍하면 안 된다.

4.모델 실험 여정

전략 1 — SVR + RobustScaler (초기 실험)

데이터에 노이즈가 심하다는 판단 하에 SVR의 마진(Margin) 특성을 활용했다.

파이프라인: Raw Data → RobustScaler → 5-Fold CV → Seed 42/121/2026 평균 → MAE 0.14

• RobustScaler: 이상치가 많은 혈압·콜레스테롤 등에 중앙값 기반 스케일링 적용
• Seed 앙상블: 3개 난수로 모델을 반복 학습 후 평균 — 변동성 통제

SVR의 커널 트릭(Kernel Trick)으로 선형 분석으로는 잡을 수 없는 변수 간 비선형 폭발 지점을 포착했다.

전략 2 — AutoGluon v3 (최종 제출, MAE 0.14026)

predictor = TabularPredictor(
    label='stress_score',
    eval_metric='mae',
    path='../models/ag_strategy_v3/',
    problem_type='regression',
)

predictor.fit(
    train_data=train,
    presets='best_quality',   # LightGBM·XGBoost·CatBoost·NN 앙상블
    num_bag_folds=10,         # 10-fold 배깅
    num_stack_levels=2,       # 2단 스태킹
    time_limit=3600 * 1.5,
    excluded_model_types=['KNN'],
    refit_full=True,
    set_best_to_refit_full=True,
)

SVR보다 AutoGluon 앙상블이 더 안정적인 점수를 냈고, 이를 최종 제출했다.

전략 3 — AutoGluon v5 + Pseudo Labeling (추가 실험)

v3 결과물을 활용해 테스트 데이터에 의사 라벨을 붙여 학습 데이터를 늘리는 시도를 했다.

# v3 예측 결과를 pseudo label로 활용
test_pseudo = test.copy()
test_pseudo['stress_score'] = v3_result['stress_score']

# 원본 100% + Pseudo 40%만 샘플링 (과적합 방지)
test_pseudo_sampled = test_pseudo.sample(frac=0.4, random_state=42)
combined_train = pd.concat([train, test_pseudo_sampled]).reset_index(drop=True)

predictor.fit(
    train_data=combined_train,
    presets='high_quality',   # best → high로 학습 시간 40% 단축
    num_bag_folds=8,
    num_stack_levels=1,       # 과적합 방지
    time_limit=3600 * 1,
    hyperparameters={
        'CAT': {}, 'XGB': {}, 
        'GBM': {'num_boost_round': 500},
        'NN_TORCH': {}
    },
    excluded_model_types=['KNN', 'RF', 'XT'],
)

Pseudo Labeling은 v3 예측 정확도가 충분히 높을 때 효과적이었다. 테스트 전체가 아닌 40%만 샘플링해 원본 데이터 비중을 높여 과적합을 방지했다.

전략별 비교

5.EDA 시각화

분석 과정에서 3가지 시각화를 작성했다.

# v3 피처 상관관계 히트맵
corr_cols = ['stress_score', 'age', 'bmi', 'pulse_pressure', 'MAP']
sns.heatmap(df[corr_cols].corr(), annot=True, cmap='Purples', fmt=".2f")

# 수면 패턴별 스트레스 분포 (Violin Plot)
sns.violinplot(data=df, x='sleep_pattern', y='stress_score', palette='Purples')

# MAP vs 스트레스 회귀선
sns.regplot(data=df, x='MAP', y='stress_score',
            scatter_kws={'alpha': 0.2, 'color': '#6a0dad'},
            line_kws={'color': '#b19cd9'})

6.백엔드 — FastAPI

# 서버 시작 시 모델 1회 로드
predictor = TabularPredictor.load(str(MODEL_DIR))

@app.post("/predict")
def predict(req: PredictRequest):
    input_df = pd.DataFrame([req.dict()])
    input_df = engineering_refined(input_df)
    input_df = input_df.drop(columns=existing_drop_cols)

    score = float(predictor.predict(input_df).iloc[0])
    score = max(0.0, min(score, 1.0))

    return {
        "stress_score": round(score, 2),
        "stress_level": "낮음" if score < 0.34 else "보통" if score < 0.67 else "높음"
    }

uvicorn main:app --reload --port 8000

포인트: 모델을 요청마다 로드하면 AutoGluon 특성상 매우 느리다. 서버 시작 시 1회만 로드해야 했다.

7.프론트엔드 — 마음날씨 웹앱

구조

page-intro → page-input(16단계) → page-result → page-reason → page-remedy

API 호출

const response = await fetch("http://localhost:8000/predict", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    age: answers.age,
    sleep_pattern: answers.sleepPattern,
    smoke_status: answers.smokeStatus,
    // ... 13개 필드
  }),
});
const { stress_score, stress_level } = await response.json();

스트레스 유형 분류 (로컬 스코어링)

ML 점수는 결과 표시용, 원인 분석·유형 분류·추천 카드는 로컬 스코어링 함수로 별도 계산.

const typeSc = {
  sleep:     sleepScore * 0.55 + fatigueScore * 0.45,
  overload:  burdenScore * 0.45 + focusScore * 0.3 + moodScore * 0.25,
  tension:   hrScore * 0.35 + bpScore * 0.35 + cafScore * 0.15 + burdenScore * 0.15,
  lifestyle: bmiScore * 0.35 + actScore * 0.35 + smokeScore * 0.3,
};
// → 4종 중 최댓값 유형 1개 자동 선택

8.디렉토리 구조

Stress-Score-Prediction/
├── backend/
│   ├── src/
│   │   ├── main.py          # FastAPI 서버
│   │   ├── train.py         # AutoGluon v3 학습 (최종 제출)
│   │   ├── train2.py        # AutoGluon v5 + Pseudo Labeling
│   │   ├── preprocess.py    # SVR 전략 전처리기
│   │   ├── predict.py       # v3 제출용 예측
│   │   └── predict2.py      # v4/v5 예측
│   ├── data/
│   │   ├── train.csv
│   │   └── test.csv
│   └── models/
│       ├── ag_strategy_v3/  # 최종 제출 모델
│       └── ag_strategy_v5/  # 실험 모델
└── frontend/
    ├── index.html
    └── src/
        ├── script.js
        └── style.css

웹앱 ppt일부

가설이 틀린 게 오히려 인사이트였다

수면·흡연이 주원인일 거라는 상식이 데이터에서 낮은 상관관계(p=0.082)로 나타났다. 이 실패가 "생활습관 변수 배제 → 생체 지표 중심으로 피벗"이라는 핵심 전략을 만들어줬다.

결측치를 정보로 쓴 것이 주효했다

medical_history 결측(0.465) vs 질환 그룹(0.495) — 이 차이를 살리기 위해 NaN → 'None' 처리로 결측 자체를 하나의 카테고리로 학습시켰다.

모델보다 피처가 먼저다

SVR이든 AutoGluon이든, 성능 차이를 만든 건 결국 어떤 변수를 어떻게 만들었냐였다.

복잡하고 노이즈 가득한 생체 데이터를 분석하고, MAE 0.14026으로 3등을 기록하고, 이를 실제 웹앱으로 연결까지 해본 경험이 가장 값졌다 🌤️

Todo 데이터를 브라우저 LocalStorage에 저장하도록 수정했다.

이제 새로고침을 해도 Todo 데이터가 사라지지 않는다.

LocalStorage란?

브라우저에 데이터를 저장할 수 있는 웹 스토리지 기능이다.

특징:

브라우저에 데이터 저장
새로고침해도 유지됨
문자열 형태로 저장됨

Todo 저장 방식

Todo 상태가 변경될 때마다 LocalStorage에 데이터를 저장하도록 구현했다.

Todo 추가 시 저장

localStorage.setItem("todos", JSON.stringify(newTodos));

Todo 삭제 시 저장

localStorage.setItem("todos", JSON.stringify(newTodos));

Todo 완료 상태 변경 시 저장

localStorage.setItem("todos", JSON.stringify(newTodos));

LocalStorage에서 데이터 불러오기

앱이 시작될 때 저장된 Todo를 불러온다.

const savedTodos = JSON.parse(localStorage.getItem("todos")) || [];

설명:

localStorage → 문자열 저장
JSON.parse → 문자열을 배열/객체로 변환

Todo 전체 삭제

clearTodos: () => {
  localStorage.removeItem("todos");
  set({ todos: [] });
}

LocalStorage에 저장된 데이터도 함께 삭제 된다.

결과물

오늘 배운 개념

JSON.stringift()

객체 / 배열 -> 문자열 변환

JSON.parse()

문자열 -> 객체 / 배열 변환

LocalStorage는 문자열만 저장 가능하기 때문에 JSON 변환 과정이 필요하다.

느낀점

처음에는 Todo가 새로고침하면 사라졌지만 LocalStorage를 이용해 데이터가 유지되는 것을 보니 작은 기능이지만 앱이 실제 서비스처럼 느껴졌다.

상태 관리와 데이터 저장 방식에 대해 조금 더 이해하게 된 하루였다.

📎 Project Link

🐙 GitHub Repository 👉 https://github.com/wjdtor2-design/Frontend-portfolio 📝 Velog Study Log

단순한 Todo 리스트를 넘어, 실무에서 필수적인 상태 제어 기능을 구현해봄.

• 상태별 필터링: 전체,완료,미완료 버튼을 누르면 목록이 실시간으로 바뀐다.
• 실시간 통계: 현재 총 개수, 완료 개수, 남은 개수를 계산하여 보여준다.
• 전역 상태 관리: Zustand를 사용해 모든 데이터를 한 곳(store)에서 관리하고, 여러 컴포넌트가 공유하도록 설계했다.

내가 마주친 벽 : "왜 이렇게 어렵게 해야하나?"

오늘 공부하면서 가장 큰 의문과 답답함이 밀려왔던 포인트는 두가지

막혔던 포인트 1: "왜 App.jsx에 다 안적고 파일을 쪼갤까?"

• 고민: 한 파일에 다적으면 한눈에 보이고 편한데, 왜 굳이 폴더를 만들어서 일을 어렵게 만드는지 궁금했음.
• 해결: '관심사 분리'라는 개념을 배움. App은 전체 배치만 하고, 일꾼(components)들에게 일을 시키는 구조여야 나중에 고장이 났을 때 범인을 찾기 쉽다는걸 깨달음.(공장과 단톡방 비유로 이해 완!)

막혔던 포인트 2: "필터 버튼을 눌러도 화면이 안변한다!"

• 실수: 수첩(store)의 필터 값은 바꾸고 있었지만, 화면을 그리는 TodoList.jsx에서는 여전히 원본목록(todos)만 보고 있었음.
• 해결: 데이터는 바뀌고 있었지만, 화면을 그리는 도구가 엉뚱한 곳을 보고 있었다는걸 알게됨.

🛠️코드 / 이유

1) 전역 상태 확장 (TodoStore.js) 가장 먼저 공유 수첩(Store)에 새로운 기준을 추가함.

const useTodoStore = create((set) => ({
  todos: [], 
  filter: "all", // 1. 기준값 추가 (전체, 미완료, 완료)

  // ... (생략)

  setFilter: (filter) => set({ filter }), // 2. 기준값을 바꾸는 리모컨 추가
}));

• 이유: 지금 화면에 "무엇을 보여줄지" 결정하는 기준이 필요하기 때문
• 작동: 사용자가 버튼을 누르면 단톡방에 "지금부터 미완료만 보자!"라고 공지를 띄우는 것과 같다.

2) 필터 버튼 컴포넌트 (TodoFilter.jsx) 사용자의 명령을 받는 스위치를 만들었음.

function TodoFilter() {
  const { filter, setFilter } = useTodoStore(); // 수첩에서 리모컨 가져오기

  return (
    <div>
      <button onClick={() => setFilter("all")}>전체</button>
      <button onClick={() => setFilter("active")}>미완료</button>
      <button onClick={() => setFilter("completed")}>완료</button>
    </div>
  );
}

• 이유: 버튼을 클릭이라는 역할만 따로 떼어내어 관리하기 위함임.(관심사 분리)

3) 필터링 로직 구현(TodoList.jsx) 오늘의 가장 중요한 하이라이트

const { todos, filter } = useTodoStore(); // 수첩에서 데이터 가져오기

// 중요! 원본은 건드리지 않고 '보여줄 목록'만 새로 만듭니다 (파생 상태)
const filteredTodos = todos.filter((todo) => {
  if (filter === "completed") return todo.completed; // 완료만 통과!
  if (filter === "active") return !todo.completed;  // 미완료만 통과!
  return true; // 전체보기
});

// 화면에는 거른 목록(filteredTodos)을 뿌려줍니다.
{filteredTodos.map((todo, index) => ( ... ))}

• 이유: 원본 창고(todos)를 뒤섞지 않고, 출력할 때만 실시간 장바구니(filteredTodos)를 만들어 화면을 갈아 끼우기 위해서임.

깨달은 핵심 개념

이번 프로젝트를 통해 머릿속에 확실히 박힌 3단계 흐름이다.

1. 입력(App): useState로 잠깐 들고 있다가 단톡방에 전달.
2. 보관(Store): Zustand라는 큰 수첩에 저장하고 공지사항 업데이트.
3. 출력(Components): 수첩을 보고 있던 일꾼들이 자기 스타일대로 요리해서 화면에 출력.

결과물

📎 Project Link

🐙 GitHub Repository 👉 https://github.com/wjdtor2-design/Frontend-portfolio 📝 Velog Study Log

• 통계 기능(Todo Stats) 추가
• 전체 Todo 개수
• 완료된 Todo 개수
• 남은 Todo 개수

예시

전체: 3
완료: 1
남은: 2

이 기능을 만들면서 배열 데이터를 계산하는 방법과 파생 상태(Derived State) 개념을 함께 이해하게됨

TodoStats 컴포넌트 만들기

Todo 통계를 관리하는 컴포넌트를 따로 분리함.

components/TodoStats.jsx

Zustand store에서 todos 상태를 가져온다.

import useTodoStore from "../store/todoStore";

function TodoStats() {
  const todos = useTodoStore((state) => state.todos);

  const total = todos.length;
  const completed = todos.filter((todo) => todo.completed).length;
  const remaining = total - completed;

  return (
    <div>
      <p>전체: {total}</p>
      <p>완료: {completed}</p>
      <p>남음: {remaining}</p>
    </div>
  );
}

export default TodoStats;

여기서 중요한 부분은 filter()를 이용한 계산.

filter()로 완료된 Todo 계산하기

배열에서 특정 조건에 맞는 데이터를 찾을 때 filter()를 사용한다

const completed = todos.filter((todo) => todo.completed).length;

설명

1) todos 배열을 순회하면서 2) completed가 true인 todo만 남기고 3) 그 개수를 length로 계산한다.

예시데이터

[
 { text: "공부", completed: true },
 { text: "운동", completed: false },
 { text: "코딩", completed: false }
]

filter결과

[{ text: "공부", completed: true }]

따라서

completed = 1

이 된다.

남은 Todo 계산하기

남은 Todo는 간단하게 계산할 수 있다.

const remaining = total - completed;

즉

남은 할 일 = 전체 - 완료

이렇게 계산한다.

Derived State (파생 상태)

이번 기능에서 중요한 개념이 파생 상태(Derived State)이다.

파생 상태란

👉 기존 상태를 기반으로 계산해서 만들어지는 값

예시

즉

todos -> 실제 데이터
통계값 -> 계산된 데이터

이런 구조를 파생 상태(Derived State) 라고 한다.

TodoStats 컴포넌트 연결

App.jsx에서 TodoStats 컴포넌트를 추가해 화면에 표시했다.

import TodoStats from "./components/TodoStats";

function App() {
  return (
    <div>
      <h1>Todo App</h1>

      <TodoList />

      <TodoStats />
    </div>
  );
}

이제 Todo를 추가하면 통계가 자동으로 업데이트된다.

결과물

GitHub Pull Request Workflow

오늘은 기능 구현뿐 아니라 GitHub 협업 방식도 함께 연습함.

진행과정

1. feature/day05 브랜치 생성
2. Todo Stats 기능 개발
3. GitHub에 Push
4. Pull Request 생성
5. Merge
6. 브랜치 삭제

이 과정은 실제 개발에서 사용하는 Git Workflow와 동일.

📌 오늘 배운점

단순히 기능을 추가하는 것뿐 아니라 React에서 중요한 개념들을 함께 배울 수 있었음.

• 배열 데이터 계산(filter)
• 파생 상태(Derived State)
• 컴포넌트 역할 분리
• Zustand 전역 상태 활용
• GitHub Pull Request Workflow

📎 Project Link

🐙 GitHub Repository 👉 https://github.com/wjdtor2-design/Frontend-portfolio 📝 Velog Study Log

• Zustand로 Todo 전역 상태 관리하기
• props drilling 문제 이해하기
• 컴포넌트 분리 연습하기
• 상태를 어디에 둬야 하는지 기준 세우기

Day03 복습

Day03에서는 useState를 사용해 App에서 todos를 관리함.

const [todos, setTodos] = useState([]);

그리고 TodoList로 props를 전달함.

App
 └ TodoList

처음에는 단순했지만, 이런 생각이 들었음.

👉 컴포넌트가 더 깊어지면 props가 계속 내려가야 하는 거 아닌가?

이게 바로 Props Drilling 문제.

Props Drilling이란?

Props는 부모가 자식에게 전달하는 데이터다.

<Child name="Julie" />

하지만 구조가 이렇게 깊어지면?

App
 └ Parent
     └ Child
         └ GrandChild

GrandChild가 데이터를 필요로 하면 중간 단계 컴포넌트도 모두 props를 전달해야 한다.

-> 코드 복잡 -> 유지보수 어려움 -> 구조가 지저분해짐

이문제를 해결하기 위해 전역 상태 관리가 등장함.

전역(Global)상태란?

전역상태란 👉 앱 어디서든 공통으로 사용할 수 있는 데이터

를 의미함.

비유하자면:

• Props -> 부모가 직접 주는 용돈
• 전역 상태 -> 거실에 두고 누구나 꺼내 쓰는 간식 바구니

전역 상태가 되면 부모 -> 자식 전달 과정이 필요 없다.

각 컴포넌트가 직접 가져다 쓰면 된다.

Zustand 적용하기

Zustand는 전역 상태 관리 라이브러리

store를 만들어 상태를 중앙에서 관리한다.

const useTodoStore = create((set) => ({
  todos: [],
  addTodo: (text) =>
      set((state) => ({
      todos: [...state.todos, { text, completed: false }],
    })),
}));

그리고 각 컴포넌트에서 이렇게 사용한다.

const { todos, deleteTodo, toggleTodo } = useTodoStore();

중요한 점은 👉 props를 전혀 사용하지 않았다는 것.

컴포넌트 분리 후 구조

        store
        /    \
     App   TodoList

App과 TodoList는 부모-자식 관계이지만 상태를 서로 주고받지 않는다.

둘 다 store를 직접 구독한다.

이부분이 오늘 가장 크게 이해된 지점이었다.

input은 왜 store에 넣지 않았을까?

처음에는 이런 고민을 했다.

👉 input 값도 전역 상태로 관리해야 하나?

하지만 정리해보니 기준이 생겼다.

input 값은 App에서만 사용되는 임시 데이터다. 따라서 전역 상태로 만들 필요가 없다.

store는 "공용 창고"일 뿐, 모든 상태를 넣는 곳은 아니다.

오늘의 가장 큰 깨달음

Day04는 기능이 복잡한 날은 아니었다.

하지만

• 상태를 어디에 둬야 하는지
• 왜 전역 상태가 필요한지
• props와의 차이는 무엇인지

를 고민한 하루였다.

이제는 단순히 코드를 작성하는 것이 아니라

👉 " 왜 이렇게 설계하는가 ? "

를 생각하게 되었다.

🔥Day04정리

✔ 전역 상태 개념 이해 ✔ Props Drilling 문제 이해 ✔ Zustand 구조 이해 ✔ 컴포넌트 분리 경험 ✔ 상태 설계 기준 세우기

기능은 단순했지만 설계 관점이 바뀐 날이었다.

📎 Project Link

🐙 GitHub Repository 👉 https://github.com/wjdtor2-design/Frontend-portfolio 📝 Velog Study Log

• Todo 추가
• 삭제 기능 구현
• 완료 체크 기능 추가
• Enter로 제출 처리
• React에서 왜 "직접 수정하면 안되는지" 이해하기

처음 막혔던 부분 - "todo가 뭐지?"

처음엔 todo의 개념 자체가 헷갈렸음.

• input에 입력하는 건 문자열
• 여러 개의 할 일을 관리하려면 배열이 필요

그래서 구조를 이렇게 잡음.

const [todos,setTodos] = useState([]);

그리고 단순 문자열이 아니라 객체로 저장하도록 변경함.

{
    text: "공부하기"
    compleated: false
}

👉 이유 : 완료 상태까지 관리해야 하기 때문.

push를 쓰면 왜 안될까?

처음에 이렇게 생각했다.

todos.push(newTodo);
setTodos(todos);

하지만 React는 기존 배열을 직접 수정하는 걸 좋아하지 않는다.

🔥 핵심 개념 : 불변성(Immutability)

React는 상태가 바뀌었는지 확인할 때 값을 깊게 비교하지 않고 참조값(주소)을 본다.

push는 기존 배열을 수정하기 때문에 주소가 그대로다.

그래서

setTodos([...todos, newTodo]);

👉 기존 배열을 복사해서 👉 새로운 배열을 만들어 넣어준다.

map으로 특정 요소만 수정하기

완료 체크 기능을 구현하면서 또 한 번 막혔다.

const handleToggle = (index) => {
  setTodos(
    todos.map((todo, i) =>
      i === index
        ? { ...todo, completed: !todo.completed }
        : todo
    )
  );
};

여기서 이해한 것 :

• map은 새 배열을 만든다
• 클릭한 index만 수정하고
• 나머지는 그대로 반환해야 한다 (: todo)

왜 ...todo를 쓰는가?

기존 객체를 복사한 뒤 completed 값만 덮어쓰기 위해서.

{ ...todo, completed: !todo.completed }

👉 기존 내용 유지 + 특정 속성만 변경

filter로 삭제 구현

setTods(todos.filter((_, i) => i !== index));

filter는 👉 특정 조건을 만족하는 것만 남겨서 👉 새 배열로 반환한다.

그래서 삭제할 index만 제외하면 된다.

Enter 키 중복 문제

처음엔 onKeyDown과 버튼 클릭이 동시에 실행되어 중복 추가 문제가 발생했다.

해결 방법 :

<form onSubmit={handleAdd}>

그리고

e.preventDefault();

👉 Enter는 원래 form 제출 동작이기 때문에 form + onSubmit 구조가 가장 안정적이란걸 알게됨.

이걸 통해 이벤트 흐름도 이해하게 되었음.

오늘 깨달은 핵심 정리

✔ React는 직접 수정하면 안된다 ✔ 항상 "새 배열/새 객체"를 만들어야한다 ✔ spread 문법은 복사 ✔ map은 수정 ✔ filter는 삭제 ✔ form + onSubmit이 Enter 처리의 정석

결과물

📎 Project Link

🐙 GitHub Repository 👉 https://github.com/wjdtor2-design/Frontend-portfolio 📝 Velog Study Log

• 기존 Counter 기능 확장
• Reset 버튼 추가
• 조건에 따른 버튼 비활성화 구현
• 렌더링 흐름 복습

오늘 추가한 기능

✏️ Reset 버튼 추가

<button onClick={() => set Count(0)}>
  reset
</button>

• state를 0으로 초기화
• setCount 호출 -> 재렌더링 발생

✏️ count 10이상이면 증가 버튼 비활성화

<button
  onClick{() => setCount(prev => prev +1)}
  disabled = {count >= 10}
>
  증가버튼
</button>

📌 핵심 개념 :

• disabled는 HTMl 기본 속성
• true면 클릭 불가
• count 값에 따라 동적으로 변경됨

✏️ 이해한 핵심 흐름

count가 9 -> 10이 될 때:

1. setCount 실행
2. state 값 변경
3. App 함수 재실행 (렌더링)
4. JSX 재계산
5. disabled 값 true로 변경
6. 브라우저 UI 업데이트

✏️ 깨달은 점

• 렌더링은 화면 새로고침이 아니다.
• 컴포넌트 함수가 다시 실행되는 것이다.
• state가 바뀌면 return안의 JSX는 다시 계산된다.
• 조건부 렌더링은 화면뿐 아니라 속성에도 적용된다.

Day 01 -> Day 02 성장차이

Day 01 : 단순 카운터 구현 Day 02 : 상태 기반 UI 제어 및 조건부 속성 이해

📎 Project Link

🐙 GitHub Repository
👉 https://github.com/wjdtor2-design/Frontend-portfolio 📝 Velog Study Log

• useState 이해하기
• 렌더링 개념 이해하기
• 조건부 렌더링 구현하기
• Git 브랜치 -> PR -> Merge까지 해보기

오늘 구현한 기능

📌 증가 / 감소 버튼 구현

• 버튼 클릭시 count 증가
• 버튼 클릭시 count 감소

📌 조건부 렌더링 추가

• count가 0이상이면 😊표시
• 음수이면 ⚠️ 음수입니다 출력
• 5 이상이면 "5이상입니다" 출력

📸 캡쳐

구현코드📝

import { useEffect, useState } from "react";

function App () {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log("렌더링 발생!");
  }, [count]);

  return(
    <div>
      <h1>증가, 감소 버튼</h1>
      <button onClick={() => setCount(count + 1)}>
        증가버튼
      </button>
      <button onClick={() => setCount(count - 1)}>
        감소버튼
      </button>
      {count >= 0 ? <p>😊</p> : <p>⚠️ 음수입니다</p>}
      {count >= 5 && <p>5 이상입니다</p>}
      <p>현재 값 : {count}</p>
    </div>
  );
}

export default App;

핵심 개념 정리

👉 useState란 React에서 값을 저장하는 훅(Hook). 값이 바뀌면 컴포넌트가 다시 실행된다.

👉 렌더링이란 컴포넌트 함수가 다시 실행되는 것.

새로고침이 아니라, React가 화면을 다시 계산해서 업데이트하는 과정.

👉 setState가 호출되면 일어나는 일

1. state 값 변경
2. 컴포넌트 재실행
3. return 부분 다시 계산
4. 화면 업데이트

👉 useEffect란 렌더링이 끝난 뒤 실행되는 코드.

dependency 배열에 따라 실행 시점이 달라진다.

• [] -> 처음 한 번
• [count] -> count 변경 시
• 생략 -> 렌더링 마다

Git 정리🗃️

오늘 처음으로 :

• feature 브랜치 생성
• PR 생성
• Merge
• Branch 삭제

👉 협업 기본 흐름을 경험했다.

이건 그냥 코드보다 더 중요한 경험임!

📎 Project Link

🐙 GitHub Repository
👉 https://github.com/wjdtor2-design/Frontend-portfolio 📝 Velog Study Log

네트워크 기초

컴퓨터들이 서로 소통하기 위해서는 주소와 규칙이 필요함.

• IP(Internet Protocol) : 인터넷에 연결된 기기의 고유 식별 주소.(비유:건물주소)
• Port(포트) : 한 컴퓨터 내에서 실행되는 특정 프로그램의 번호.(비유:건물 안의 방번호)
  • HTTP는 기본적으로 80번,HTTPS는 443번 포트를 사용함
• DNS(Domain Name System) : naver.com 같은 문자를 IP 주소로 변환해주는 '인터넷 전화번호부'

프론트엔드(Front-end) : 사용자의 접점

사용자가 HTTP 요청을 직접 만들지 않아도 버튼 클릭이나 입력만으로 서비스가 동작하게 해주는 프로그램

• 역할 : 사용자가 보는 UI구현, 사용자 입력 처리 및 HTTP요청 변환, 서버 응답을 화면에 반영
• 주요 기술 스택

- HTML : 화면의 구조 정의
- CSS : 스타일과 레이아웃 담당
- JavaScript : 화면의 동작과 로직 구현
- 브라우저 이해 : 사용자의 디바이스,브라우저 환경에서의 동작 제어
- HTTP / REST API : 서버와의 통신
- React /Vue /Svelte : UI와 상태 관리를 구조화

• 프론트엔드 vs 클라이언트 : 프론트엔드는 주로 브라우저에서 실행되는 웹 UI를 의미하며, 클라이언트는 웹을 포함해 모바일 앱, 데스크톱 앱 등 서버와 통신하는 모든 프로그램을 포괄하는 개념임.

백엔드(Back-end) : 서비스의 핵심 로직

클라이언트의 요청을 해석하고, 비즈니스 로직을 수행하며 데이터베이스를 관리함.

• ** 역할** : 요청 검증, 비밀번호 함호화 등 보안 처리, 데이터 조회·저장·수정, API 설계 및 제공.

• 회원가입 예시 : 사용자가 UI에 정보를 입력하면 -> 프론트엔드가 HTTP 요청을 전송 -> 백엔드가 값을 검증하고 비밀번호 암호화 후 DB에 저장 -> 성공/실패 응답 반환

• 주요 기술 스택

- 프로그래밍 언어(Python,,Java,Node.js) : 비즈니스 로직 구현
- 웹 프레임워크(FastAPI,Spring) : 요청,응답 처리 및 구조화
- HTTP /REST API : 클라이언트와의 통신 규약
- 데이터베이스 / SQL : 데이터 저장,조회,관리
- 운영체제 / 클라우드 /인프라 : 서비스 배포 및 확장
- 로그,모니터링 : 장애 분석과 안정성 확보

• API의 책임 : REST API의 설계와 일관성은 주로 백엔드가 책임지며, 프론트엔드는 정의된 스펙(계약)에 맞춰 요청을 보낸다.

데이터와 저장소 (Database)

단순한 값인 '데이터'가 맥락에 맞게 정리되면 '정보가'가 되고, 이를 활용할 때 비로소 '지식'이 됨. 즉 , 서비스에서 발생하는 모든 정보를 체계적으로 보관하는 곳임.

• RDB vs RDBMS :

  • RDB(Relational Database) : 표(Table) 형태로 구성된 관계형 데이터 모델 그 자체임
  • RDBMS(Management System) : RDB를 관리하는 소프트웨어임.(예 :MySQL,PostgreSQL,Oracle)

• 데이터 모델링의 핵심 :

  • Primary Key(PK) : 각 행을 구별하는 고유 신분증임
  • Foreign Key(FK) : 다른 테이블의 PK를 참조하여 테이블 간의 관계(Realtionship)를 맺어줌
  • 이를 통해 데이터 중복을 막고 데이터의 무결성을 유지함

정리

1. 사용자가 프론트엔드에서 행동을 하면,
2. 네트워크(IP/Port)를 타고 HTTP 요청이 백엔드로 전달됨
3. 백엔드는 데이터베이스(RDBMS)에서 필요한 정보를 꺼내 가공한 뒤,
4. 적절한 응답 코드와 함께 결과를 다시 사용자에게 돌려줌

웹 서비스(Web Service)개요

• 정의 : 웹(Web) 표준 규약(URL, HTTP, HTTPS)을 통해 인터넷상에서 자원과 정보를 제공하는 시스템
• 특징 : 플랫폼과 기기에 독립적이며, 브라우저나 설치형 클라이언트(앱)을 통해 여러 사용자가 동시에 접근할 수 있음.

-** 주요 구성 요소**:

- 사용자(User) : 서비스를 이용하는 사람
- 클라이언트(Client) : 사용자의 행동을 받아 서버에 요청을 보내는 프로그램
- 서버(Server) : 클라이언트의 요청을 처리하고 결과를 반환하는 프로그램
- API : 프로그램 간 기능을 사용하기 위한 약속된 인터페이스

웹의 동작 원리 : HTTP 프로토콜

• 기본 흐름 : 클라이언트의 요청(Request) -> 처리(Server) -> 응답(Response)

• HTTP 메시지 구성 :

- 시작 줄 : 메서드(요청 시), 상태 코드(응답 시) 등을 포함함
- 헤더(Header) : 데이터의 형식, 길이, 인증 정보 등 메타데이터가 담김
- 본문(Body) : 실제 전달하려는 데이터가 들어감(선택사항)

• HTTP 상태 코드 :

- 2xx 성공 : 
    200 OK : 정상 처리,
    201 Created : 리소스 생성 성공,
    204 No Content : 성공했지만 응답 바디없음/ 보여줄게없다
- 3xx 리다이렉션 : 
    301 Moved Permanently : 영구 이동
- 4xx 클라이언트 오류 : 
    400 Bad Request: 요청 형식 오류
    401 Unauthorized: 인증 필요
    403 Forbidden: 권한 없음
    404 Not Found: 리소스 없음
    409 Conflict: 상태 충돌
    422 Unprocessable Entity: 유효성 검증 실패
- 5xx서버 오류 : 
    500 Internal Server Error: 서버 내부 오류
    502 Bad Gateway: 게이트웨이 오류
    503 Service Unavailable: 서비스 불가

REST API 설게와 데이터 전달

• REST(Representational State Transfer) : 자원(Rescource)을 중심으로 HTTP 메서드를 사용하여 통신하는 API 설계 방식

• 주요 HTTP 메서드(CRUD) :

- GET : 자원 조회
- POST : 자원 생성
- PUT/PATCH : 자원 전체/일부 수정
- DELETE : 자원 삭제

• 데이터 전달 방식 :
  • Query Parameter: URL 뒤에 ?key=value 형태로 붙여 조회 조건이나 필터를 표현함
  • Request Body: 요청 메시지 내부에 실제 생성/수정에 필요한 데이터를 담아 보낸다

CRUD와 관계

• Create → POST

• Read → GET

• Update → PUT / PATCH

• Delete → DELETE

  CRUD는 자원에 대한 대표적인 요청의 개념적 분류이고, HTTP Method는 이를 실제 HTTP요청으로 표현하는 수단

보안과 HTTPS

• HTTPS : HTTPS에 TLS(Transport Layer Security)암호화를 더해 통신 내용을 보호하는 보안 프로토콜
• 암호화 방식
  • 대칭키 : 하나의 키로 암,복호화하며 속도가 빠름
  • 공개키 : 공개키로 암호화하고 비밀키로만 복호화하여 키 전달이 안전함

_*복호화 : 암호화된 데이터를 원래의 평문(읽을 수 있는 데이터)으로 되돌리는 과정을 말함.쉽게말해, 금고 주인이 열쇠를 사용해 자물쇠를 열고 편지를 꺼내 읽는것. _

HTTP 요청시 주의사항

1. 같은 자원이라도 메서드에 따라 전혀 다른 의미의 요청이 된다.
   • GET/users -> 사용자 목록 조회
   • POST/users -> 사용자 생성
2. 행위는 URL이 아니라 메서드로 표현한다.
   • 새로운 사용자 추가
     • ❌ /createUser
     • ⭕ POST /users
   • 주문 삭제
     • ❌ /deleteOrder
     • ⭕ DELETE /orders/123

데이터베이스(Database) 기초

• 필요성 : 대량의 데이터를 정리된 구조로 안전하게 저장하고, 여러 사람이 동시에 빠르게 검색,관리하기 위해 사용함
• RDBMS(관계형 데이터베이스) : MySQL, PostgreSQL등과 같이 정형 데이터를 테이블 간의 관계(Key)를 통해 관리하는 시스템임
• 핵심 용어
  • Table : 데이터가 저장되는 표
  • Primary Key(PK) : 각 행을 유일하게 식별하는 대표 ID
  • Foreign Key(FK) : 다른 테이블의 PK를 참조하여 데이터 간 관계를 나타내는 키
  • 무결성(Intergrity) : 데이터가 손상되지 않고 정확성과 완전성을 유지하는 상태

HTTPS 동작 방식

대칭키 암호화와 공개키 암호화를 함께 사용

1. 브라우저 -> 서버 접속 요청
2. 서버 -> 인증서(공개키 포함)전달
3. 브라우저 -> 인증서 신뢰 여부 확인(CA)
4. 브라우저 -> 대칭키를 공개키로 암호화해서 전달
5. 서버 -> 비밀키로 복호화하여 대칭키 획득
6. 이후 통신 -> 대칭키로 빠르게 암호화

쉽게 말해,

1. client가 -> 브라우제에게 안녕? 얘기좀하자
2. 서버 : 그래 신분증 확인. 근데 나 진짜인지 가짜인지 몰라. ca님 이거 진짜에요?
3. ca 진품 확인
4. 오 맞네 그럼 우리끼리만 아는 암호로 만들자

1.딥러닝 학습의 본질 : 무한 오답노트

딥러닝은 결국 미분을 이용해 정답을 찾아가는 과정이다.

• 순전파(Forward) : 입력 데이터를 넣고 현재 가중치($W$)로 계산해 답을 내는 단계 (문제풀기)
• 손실 계산(Loss) : 내 답과 실제 정답의 차이를 확인. 오차
• 역전파(Backward) : 뒤에서부터 거꾸로 올라가며, 미분을 통해 각 가중치가 오차에 얼마나 기여했는지 '책임'을 묻는 단계 (범인 찾기)
• 최적화(Optimizer) : 찾은 범인(가중치)들을 수정함. 이 과정을 반복(Epoch)할수록 오차가 줄어든다.

2. ResNet (REsidual Network)

분류(Classification) 분야에 혁신을 일으킨 모델

• '깊게 쌓는 것이 무조건 좋은가?'란 질문에 대답한 모델

이론적으로는 층이 깊어질수록 더 복잡한 특징을 배울 수 있어야 함. 하지만 ResNet 이전에는 두 가지 큰 벽에 부딪혔다.

1. 기울기 소실(Vanishing Grdient) : 역전파 시 미분값을 계속 곱하며 앞으로 오는데, 층이 너무 깊으면 값이 0에 가까워져 앞쪽 층이 학습을 멈춰버림.
2. 망의 퇴화(Degradation) : 층이 깊어질수록 오히려 효율이 떨어져서, 얕은 모델보다 성능이 안 나오는 현상.

이 문제들을 해결한 것이 바로 ResNet의 Skip Connection(Shortcut)임.

✏️ Skip Connection: "하이패스" 길을 뚫어주다

다른 자료에서 말하는 '지름길'의 핵심은 불필요한 걸 버리는게 아니라, 최소한의 정보 전달 경로를 확보하는 것임.

기존 방식이 $F(x)$를 통째로 새로 학습해야 했다면, ResNet은 '기존 입력($x$)은 그대로 두고, 거기서 추가로 개선할 부분($F(x)$)만 찾아내라' 고 구조를 바꾼 것임.

• Identity Mapping : 입력을 출력에 직접 더해주는 방식.
• 네트워크는 이제 '차이(Residual)'만 학습하면 됨. 덕분에 레이어가 아무리 많아져도 최소한 이전 레이어만큼의 성능이 보장되며, 1000층 이상의 깊은 망도 안정적으로 학습할 수 있게 되엇다.

• 용도 : 이미지 분류(Classification) 및 백본 네트워크(Backbone).
• 특징 : Skip Connection을 통한 레이어의 심층화
• 의의 : 현대 딥러닝 아키텍처의 표준(standard)이 됨.

💡 질문

1. 딥러닝이란 자체가 빅데이터를 다루는 건데 ResNet을 안쓰면 안정적이지가 못해지나?

• ResNet의 '잔차학습(Residual Learnin)'개념이 없었다면 현대 초거대 Ai(GPT등)도 존재하기 어려웠다고함.
• 문제가 2개가 있는데 이를 해결한게 ResNet.(문제는 2.깊은 망의 역설과 ResNet의 등장)

2. 차이만 학습한다는게 앙상블에 있는 부스팅이랑 뭐가 다르지? 부스팅도 이전 모델들의 실수를 다음 모델이 보완해서 학습하는거는 비슷한 학습법같은데?

• 실수(잔차)를 보완하며 학습한다 즉, 이전 단계가 해결하지 못한 나머지(잔차)에 집중한다는 건 같지만, 구현방식이나 최종목적에서 큰 차이가 남.

• 부스팅 : 독립된 개별 모델들의 집합/순차적(A끝난 뒤 B), 약한모델을 모아 강하게 만들기

• ResNet(Residual Learning) 하나의 모델 내의 여러 레이어/동시적(전체 층한꺼번에)/깊은망의 학습 안정성 확보를 위해.

3. 왜 분류(Classification)에 깊은 레이어가 필요할까?

우리가 보는 이미지가 컴퓨터 입장에서는 '숫자의 바다'일 뿐이라서, 그 안에서 추상적인 개념(개,고양이)를 뽑아내려면 엄청나게 복잡한 단계가 필요하기 때문에

1. 선 -> 면 -> 형체 -> 개념의 단계 (계층적 학습) 컴퓨터는 이미지를 볼때 픽셀의 밝기 값만 본다. 이 숫자들로부터 '강아지'라는 정답을 맞히기 위해서는 단계별 학습이 필요함.

   • 초반 레이어(얕은 층) : 아주 단순한 점, 선, 대각선 같은 특징을 찾는다.
   • 중반 레이어(중간 층): 선들이 모여 만든 동그라미, 삼각형, 질감(털모양, 가죽 모양)등을 이해한다.
   • 후반 레이어(깊은 층) : 이것들을 조합해 '귀의 모양', '눈의 위치', '코의 생김새'같은 구체적인 부위를 인식함.
   • 마지막 레이어(마지막 층) : 이 모든 부위가 모였으니 이것은 골든리트리버다!라고 결론을 내림.

• 층이 깊을 수록 더 복잡하고 고차원적인 특징(예:강아지 품종차이 등)을 더 잘 구별해낼수 있음.

2. 다양한 환경에 대한 불응 (불변성, Inveriance) 분류 모델은 똑같은 강아지라도 밝은 곳에 있을 때, 어두울때, 옆모습일때, 거꾸로 매달려 있을때 동일한 강아지로 인식해야함. ResNet처럼 층이 깊으면 이런 복잡한 변화들을 층마다 나누어 처리하며 훨씬 견고한 분류성능을 낸다.

요약

ResNet은 단순히 층을 깊게 쌓은 모델이 아니라, '잔차 학습'이라는 개념으로 딥러닝의 고속도로를 뚫어준 모델임. 이 구조 덕분에 현대의 GPT 같은 초거대 AI도 탄생할 수 있음. 현대 딥러닝 아키텍처의 진정한 표준(Standard)이라 불릴만하다.

성능지표

딥러닝 모델은 단순히 "공부를 했다"는 것만으로는 부족함. 얼마나 정확하게(Precision), 하나도 놓치지 않고(Recall), 균형있게(F1-score) 찾아내느냐가 실전 사용의 핵심이기 때문임. 그래서 runs파일 -> 라벨안에 있는 지표들은 모델의 '성적표'와 같다.

Results.png

가장 먼저 봐야할 전체 흐름도!

• loss(손실) : 왼쪽의 train/box_loss, cls_loss 등 그래프가 아래로 같이 떨어지고 있음. 이 모델이 정답과 예측의 차이를 줄여나가며 잘 학습했다는 뜻임.
• Metrics(성능) : 오른쪽의 mAP50그래프가 급격히 상승해 1.0(100%)에 도달했음. 이건 모델이 학습 데이터에 대해서는 완벽하게 잘맞히고 있다는걸 의미함.

Precision-Recall(PR) 곡선

• 의미 : 정밀도(Precision)와 재현율(Recall)사이의 관계임.
• 보는 방법 : 선이 오른쪽 상단 구석(1,1)에 붙어 있을수록 좋음. 현재 그래프는 면적이 0.0995로, 거의 완벽한 사각형을 그림. 매우 우수한 성능이다라는걸 알수있음.

F1-Confidence 곡선

• 의미 : "몇 %이상의 확신이 들 때 박스를 쳐야 가장 효율적일까?"를 알려줌.
• 보는 방법 : F1-score는 정밀도와 재현율의 평균값임. 그래프를 보면 Confidence 0.0874정도에서 F1-score가 0.99로 최대치가 됨. 즉, 모델이 "이건 87% 확률로 happy_face야"라고 판단할 때 가장 믿을 만하다는 뜻임.

혼돈 행렬 (Confusion_matrix)

• 의미 : 모델이 헷갈려 하는 클래스가 있는지 보여줌
• 보는 방법 : 대각선 방향(happy_face vs happy_face)에만 숫자가 있고 나머지는 깨끗함. 즉, 배경을 얼굴로 착각하거나 얼굴을 배경으로 놓치는 실수가 전혀 없다는 뜻임.

주의할 점 (Insight)

현재 데이터가 20장으로 매우적은데 지표가 1.0(100%)에 가깝게 나오고 있음.이 두가지 가능성있다고생각함!

1. 성공적인 학습 : 대상(happy_face)의 특징이 매우 뚜렷해서 적은 데이터로도 완벽히 학습됨.
2. 과적합(Overfitting)위험 : 학습한게 20장의 사진은 잘 찾았지만, 새로운 장소나 다른 조명에서 찍은 사진을 보여주면 아예 못찾을 확률이 크지않을까

1.전이학습(Transfer Learning)

모든 모델을 처음부터(From Scratch) 학습시키는 것은 비효율적임. 대규모 데이터로 이미 학습된 모델의 '지식'을 빌려오는 것이 핵심임.

• *Pretrained Model(사전 학습 모델) *: Google이나 Meta같은 곳에서 100만 장 이상의 이미지(ImageNet 등)로 미리 학습시켜둔 모델임.

• Transfer Learning의 원리

  • *A(거인) *: 빅데이터와 고사양 GPU로 이미 세상의 특징을 다 배워둔 모델.
  • *B(나) *: 적은 데이터와 저사양 GPU만 있어도 A의 모델을 가져와 내 문제에 맞춰 '추가 학습'만 하면 됨.

• ** 핵심 용어**

  • Open Weights : 소스코드처럼 딥러닝 모델의 파라미터(지식)가 공개된 것
  • Fine-tuning(미세 조정) : 내 데이터에 맞제 가중치를 미세하게 업데이트하는 과정.

2.파인튜닝(Fine-tuning)전략

노션의 'Fine-tuning Strategies'섹션에 있는 내용을 바탕으로 한 실무 전략임.

1. Freeze(동결) : 기존 모델의 앞부분(특징 추출기)은 이미 똑똑하므로 학습되지 않게 고정함.
2. Classifier / Head 교체 : 기존 모델의 마지막 출력층을 내 문제(예: 강아지/고양이 2진 분류)에 맞는 개수로 갈아 끼운다.
3. Train : 내가 가진 소량의 데이터로 교체된 Head 부분 위주로 학습을 진행함.

3.실무에서의 AI 성능 향상 팁

• 데이터 정규화 (Normalization) : 특정 데이터의 수치가 너무 크면 모델이편향되므로, 반드시 0~1사이 혹은 표준정규분포로 맞춰야 함.
• Batch Normalization : 각 레이어 사이에서 데이터 분포를 조정하여 학습 속도를 높이고 안정화함.
• 통계적 검증 (t-test) : 내 모델이 이전보다 좋아졌을 때, 그것이 우연인지 아니면 정말 실력이 좋아진 것인지 통계적으로 증명하는 능력이 중요함!!

💡 5일간의 과정을 마치며

5일간 딥러닝의 본질부터 실전 기법까지 쉼 없이 달려왔고 달려가는중 ! 단순히 코드를 복붙하는 개발자가 아니라, 모델의 구조를 이해하고 결과물을 엄격하게 평가할 수 있는 AI 엔지니어로 성장해보자!!

1.이미지의 공간 정보를 읽는 CNN(Convolutional Neural Network)

이미지는 인접한 픽셀 간의 관계가 중요함. 이를 위해 탄생한 것이 합성곱(Convolution) 연산임.

• 핵심 개념

  • Convolution(합성곱) : 필터(커널)가 이미지를 스캔하며 특징을 추출함. 과거에는 사람이 필터를 설계했지만, CNN은 필터 속 숫자 자체를 학습함.
  • Padding & Stride : 이미지 크기를 유지하거나(Padding), 필터가 이동하는 간격(Stride)을 조절하여 특징 추출의 밀도를 결정함.
  • Pooling : 중요한 정보만 남기고 데이터 사이즈를 줄여 계산 효율을 높인다.(예 : Max Pooling)

• 장점

  • 이미지의 지역적 특징을 잘 잡아낸다.
  • 슬라이딩 윈도우 방식이지만, 같은 필터로 한꺼번에 연산이 가능해** 병렬 연산(GPU)**에 매우 유리함.

  

2.흐름을 기억하는 RNN(Recurrent Neural Network)

주식 가격, 날씨, 텍스트처럼 순서(Sequence)가 중요한 데이터에 사용됨.

• 핵심 구조 : 이전 시점(t-1)의 연산 결과가 다음 시점(t)의 입력으로 들어가는 순환 구조임.

• 한계점

  • Long-term Dependency : 문장이 길어지면 앞부분의 정보를 잊어버리는 '기억력의 한계'가 있음
  • 병렬 연산 불가 : 이전 연산이 끝나야 다음 연산을 할 수 있어 속도가 느림.

• 진화된 RNN

  • *LSTM / GRU *: 'Gate'라는 구조를 도입하여 어떤 정보를 기억하고 잊을지 스스로 결정하게 만들어 RNN의 단점을 보완함.
  • 실무에서는 보통 양방향 다층(Bi-LSTM)구조가 국룰로 통함.

3.CNN vs RNN vs Transformer (연산 효율성 비교)

수업에서 강조된 시간/공간 복잡도와 병렬 연산 가능 여부임.

4.실무 데이터 Shape 이해하기

RNN류를 다룰 때 가장 헷갈리는 데이터 형태를 꼭 기억해야함!!

• Input Shape : (배치 사이즈, 시계열 길이, 특징 차원)
• 예시 : 환자 1명의 5일간 맥박/체온/호흡 데이터 -> (1, 5, 3)

💡요약

1. 이미지는 CNN으로 공간적 특징(필터 학습)을 잡는다.
2. 시계열은 RNN(LSTM)으로 흐름을 잡지만, 병렬 연산이 안 된다는 단점이 있다.
3. 현재는 RNN의 단점을 극복하고 병렬 연산이 가능한 Transformer 구조가 대세로 자리 잡았다.

1.딥러닝의 영원한 숙제 : 과적합(Overfitting)

• 과적합 : 모델이 학습 데이터의 패턴뿐만 아니라 노이즈(불필요한 정보)까지 통째로 외워버린 상태.
• *현상 * : 학습 데이터에 대한 Loss는 계속 떨어지는데, 검증(Validation) 데이터에 대한 Loss는 오히려 올라감.
• 목표 : 훈련 오차와 데이터 오차 사이의 간극을 줄여 '일반화(Generalization)'를 달성하는 것.

2.역전파(Backpropagation)와 옵티마이저 심화

어떻게 가중치를 효율적으로 업데이트할 것인가에 대한 고민임.

• 역전파 : 출력층의 오차를 입력층 방향으로 거슬러 올라가며 전파하는 과정임. 이때 Chain Rule(연쇄법칙)이 핵심적인 역할을 함.
• 옵티마이저(Optimizer)의 진화
  • SGD : 가장 기본적인 경사하강법. 단순하지만 일반화 성능이 의외로 좋을 때가 있음.
  • Momentum : 관성을 추가하여 경사면을 따라 더 빠르게 내려가게 돕는다.
  • Adm : 현재 가낭 많이 쓰는 국룰 옵티마이저. 방향(Momentum)과 보폭(RMSProp)을 동시에 고려하여 똑똑하게 최적화함.

3.과적합을 막는 정규화(Regularizatin) 기법

모델이 특정 데이터에만 매몰되지 않도록 '제약'을 거는 방법들임.

1. Weight Decay(L2 Regularization) : 가중치($W$) 값이 너무 커지지 않게 패널티를 줌. 모델이 특정 피처에 과도하게 의존하는 것을 방지함.
2. Dropout(드롭아웃) : 학습 시 무작위로 일부 노드르 '꺼버림'.이를 통해 모델이 특정 경로에 의존하지 않고 더 강건하(Robust)특징을 배우게 함.
3. Batch Normalization(배치 정규화) : 각 레이어를 통과할 때마다 데이터의 분포를 일정하게 맞춰줌. 학습 속도가 빨라지고 초기화에 덜 민감해지는 효과가 있음.

4.실무 필수 테크닉 : 조기 종료(Early Stopping)

수능 공부도 너무 오래 하면 오히려 역효과가 나듯, 딥러닝도 적절할 때 멈춰야 함.

• 원리 : 매 에폭(Epoch)마다 검증 데이터의 손실(Val Loss)을 체크함.
• 판단 기준 : Val Loss가 일정 횟수(patience) 이상 개선되지 않으면 학습을 강제로 중단하고, 가장 성능이 좋았던 시점의 모델을 저장함.

💡 요약

1. 모델의 목표는 학습 데이터가 아닌 새로운 데이터를 잘 맞히는 것이다.
2. Adam 옵티마이저와 Dropout은 실무에서 가장 먼저 고려되는 옵션이다.
3. Early Stopping을 통해 과적합이 발생하기 직전의 가장 좋은 모델을 확보해야 한다.

1.ML복습 : 결정트리의 진화, 앙상블(Ensemble)

데이터가 정형(표)형태이고 양이 아주 많지 않을 때는 여전히 강력한 도구임.

• 배깅(Bagging) : 병렬 구조. 여러 트리를 랜덤하게 만들어 투표함(예:Random Forest)
• 부스팅(Boosting) : 직렬 구조. 이전 트리가 틀린 문제를 다음 트리가 집중 학슴함. 가중 평균을 통해 합쳐짐(예 : XGBoost, LightGBM)
  • Tip : LightGBM이 XGBoost보다 속도가 훨씬 빨라 실무에서 선호된다함.
• 결론 : 표 형태의 데이터 + 단순 분류 문제라면 Random Forest나 LightGBM이 가성비 최고임.

2.왜 딥러닝인가 (선형 vs 비선형)

• 선형적 관계 : 운동 시간-칼로리 소모처럼 정비례하거나 반비례하는 단순한 관계.
• 비선형적 관계 : 공부 시간-성적(계단식), 가격-만족도(지수적)처럼 복잡한 관계.
• 딥러닝의 존재 이유 : 현실 세계의 데이터는 대부분 비선형적임. 딥러닝은 활성화 함수를 통해 이 비선형성을 완벽하게 모사함.

3.MLP(Multi-Layer Perceptron)의 설계 원리

퍼셉트론을 층층이 쌓은 구조.

• 지식 저장소(Parameter) : 가중치($W$)와 편향($b$)의 총합임. 이 숫자들의 모델의'지능'을 결정하며 GPU메모리를 차지하는 주범임.
• 너비 vs 깊이
  • 노드(너비)를 늘리는 것보다 레이어(깊이)를 쌓는 것이 모델의 표현력을 높이는 데 훨씬 효율적임.
• 활성화 함수의 배치 : 선형 연산($Wx+b$) 뒤에 반드시 비선형(ReLU 등)을 붙여야 층을 쌓는 의미가 생긴다.

4.모델 평가의 딜레마: 성능 지표 제대로 알기

단순히 "정확도(Accuracy)가 높다"고 좋은 모델이 아님.

• 임계치(Threshold) : 0.5라는 기준은 절대적이지 않음. 데이터 분포에 따라 조절해야 함.

• 주요 지표 4총사

  1. 정확도(Accuracy) : 데이터 불균형(예:의귀질환 0.1%)시 무의미함. 전부 음성이라 해도 99.9%가 나오기 때문임.
  2. 민감도(Recall/Sensitivity) : "실제 암 환자 중 암이라고 맞춘 비율". 놓치면 안 되는 문제에서 중요!
  3. 특이도(Specificity) : "정상인 중 정상이라고 맞춘 비율"
  4. 정밀도(Precision) : "암이라고 예측한 사람 중 실제 환자 비율".

• ACROC : 임계치를 변화시키며 민감도와 특이도의 트레이드오프 관계를 한눈에 평가하는 지표임. 1에 가까울수록 좋은 모델임.

💡요약

1. 정형 데이터에는 앙상블(LGBM 등) 모델이 효율적이다.
2. 딥러닝 모델의 성능은 파라미터의 양과 층의 깊이에 비례한다.
3. 모델 평가는 정확도뿐만 아니라 Recall, Precision, AUROC를 종합적으로 봐야 한다.

1. 머신러닝 vs 딥러닝

모든 문제에 딥러닝이 정답은 아님. 데이터와 문제의 복잡도에 따라 선택해야 한다.

• 머신러닝(ML) : 데이터가 숫자로 가볍게 표현되고 양이 적을 때 사용한다.(예 : 선형회귀, 결정트리, XGBoost 등)
• 딥러닝(DL) : 이미지, 자연어처럼 숫자로 바로 표현하기 어렵고 데이터 양이 방대할 때 필수적이다. 즉, 인공신경망을 활용해 복잡한 비선형 문제를 해결하는 과정이다.

2. 딥러닝의 핵심 단위 : 퍼셉트로(Perceptron)

딥러닝은 아주 단순한 '퍼셉트론'을 수없이 많이 쌓아 올린 것이다.

• 구조 : 입력값($x$)에 가중치($w$)를 곱하고 편향($b$)을 더한 뒤, 활성화 함수를 통과시킨다.
• 활성화 함수(Activation Function)
  • 신경망에 비선형성을 부여하는 마법의 도구임. 이게 없다면 층을 아무리 쌓아도 단층 모델과 다를 바가 없음.
  • sigmoid : 결과를 0~1사이로 수렴하게 만든다.
  • ReLU : 음수 0, 양수는 그대로 통과시키는 가장 대중적인 함수임.
  • Softmax : 마지막 출력층에서 여러 선택지 중 확률이 가장 높은 것을 고를 때 사용함.

3.학습의 매커니즘 : 순전파와 역전파

학습은 결국 손실함수를 0으로 만드는 과정임.

1. 순전파(Forward Pass) : 데이터가 입려긍에서 출력층으로 흐르며 예측값을 내놓는 과정임.
2. *손실 함수(Loss Function) *: "내 예측이 얼마나 틀렸나?"를 수치화함.(회귀:MSE, 분류:CrossEntropy 등)
3. 역전파(Backward Pass) : 미분(Gradient)을 통해 출력층에서 거꾸로 올라가며 가중치를 수정함.
4. 경사하강법(Gradient Descent) : 손실 함수의 기울기를 따라 낮은 곳(정답)으로 한 발자국씩 이동하는 최정화 기법임.

4.실전 준비 : PyTorch Tensor 조작하기

딥러닝의 모든 연산은 행렬곱이며, 이를 처리하는 단위가 바로 Tensor임.

• Tensor : GPU 연산이 가능한 다차원 행렬임

• 필수 체크 사항

  • shape : 데이터의 차원을 확인하는 습관!
  • *device *: 현재 데이터가 CPU가 있는지 GPU(CUDA)에 있는지 확인해야 연산 에러가 안난다.

• 핵심 조작

  • view / reshape : 데이터의 전체 개수는 유지하면서 모양만 바꾼다.(가장 많이 씀!)
  • transpose / permute : 차원의 순서를 바꿀 때 사용함.

  

객체 분류(Object Classification)

: 이미지 전체가 어떤 클래스인지 분류하는 작업

• 예 : 이 사진은 happy_face 인가? not_happy인가?
• 결과 : 하나의 라벨만 출력

📌 특징

• 위치 정보 X
• 가장 기본적인 CV 태스크

객체 식별(Object Recognition)

: 이미지 속에 어떤 객체가 "존재하는지"를 인식하는 작업, object detection의 개념일부

• 예 : 사진 안에 사람이 있는가? 얼굴이 있는가?
• 결과 : 객체 종류 인식(위치는 없음)

📌 분류와 차이

• 분류는 "전체 이미지"
• 식별은 "이미지 안에 무엇이 있나"

객체 탐지 & 위치 추정(Object Detection & Object Localization)

: 객체의 종류 + 위치(Bounding Box)를 함께 찾는 작업

• 예 : 웃는 얼굴이 어디에 있는지
• 결과 : 클래스 + 박스 좌표

📌 YOLO가 바로 이 작업 📌 이번 프로젝트에서 사용한 방식

객체 분할(Object Segmentation/Instance Segmentation)

: 이미지의 모든 픽셀을 클래스 단위로 분류

• 예 : 얼굴/배경/머리카락 영역을 픽셀 단위로 구분
• 결과 : 같은 클래스는 하나의 영역으로 처리

📌 특징

• 픽셀 단위
• 같은 객체 여러 개여도 하나로 취급

인스턴스 분할(Instance Segmentation)

: 객체 하나하나를 픽셀 단위로 분리

• 예 : 얼굴이 3개 있으면 각 얼굴을 개별 마스크로 분리

• 결과 : 클래스 + 개별 객체 마스크

  

📌 Semantic Segmentation보다 한 단계 더 정밀 📌 Mask R-CNN, YOLOv8-seg 등 사용

자세 추정(Pose Estimation)

: 사람 또는 객체의 관절·키포인트를 추정하는 작업 ,졸라맨같은거

• 예 : 눈, 코, 입, 어깨, 팔꿈치 위치 추정
• 결과 : 스켈레톤 형태의 포인트

📌 운동 분석, 헬스케어, 모션 캡처에 활용

동영상 분석(Video Analysis)

: 연속된 프레임을 분석해 시간적 변화까지 고려

• 예 : 영상에서 사람 추적, 행동 변화 분석
• 결과 : 프레임 간 객체 추적/이벤트 탐지

📌 이미지 + 시간 개념 추가

행동 인식(Activity Recognition)

: 사람의 동작이나 행동을 인식하는 작업

• 예 : 걷기,뛰기,웃기,넘어지기
• 결과 : 행동 클래스

📌 보안, 헬스케어, 스포츠 분석에 활용

이미지 해상도 개선(Resolution Enhancing)

: 저해상도 이미지를 고해상도로 복원하는 작업

• 예 : 흐릿한 얼굴을 선명하게 복원

• 결과 : 픽셀 품질 향상된 이미지

  📌 ESRGAN, Real-ESRGAN 등 사용

📌프로젝트 목표

• Task : 얼굴 이미지에서 행복한 얼굴 감지
• Model : YOLOv8(Ultralytics)
• Labeling Tool : Label Studio
• 환경 : macOS + 가상환경
• 데이터 수 : 이미지 20장 (실습/파이프라인 검증용)

✏️YOLO Object Detection 라벨 형식 이해

YOLO는 이미지마다 txt 라벨 파일 1개를 사용한다.

YOLO 라벨 형식

class_id x_center y_ceter width height

• 좌표는 0~1 사이로 정규화
• class_id는 0부터 시작
• 이번 프로젝트에서는 :

0 = happy_face

✏️Label Studio로 라벨링 환경 구성

라벨스튜디오 바로가기

프로젝트 생성

• Label Studio 실행
• 새 프로젝트 생성

라벨링 인터페이스(XML)설정 Object Detection (Bounding Box)용 XML을 직접 설정했다.

<View>
  <Image name="image" value="$image"/>
  <RectangleLabels name="label" toName="image">
    <Label value="happy_face"/>
  </RectangleLabels>
</View>

이 설정이 없으면 박스 그리는 도구 자체가 안 뜬다

✏️이미지 Import & 라벨링

• 이미지 20장 업로드
• Label 버틍 클릭 -> 라벨링 화면 진입
• 사각형(Rectangle) 도구로 얼굴 전체에 박스
• 웃는 얼굴이 없는 이미지는 박스 없이 저장

박스가 없는 이미지도 정상적인 데이터 (negative sample 역할)

✏️라벨링 결과(JSON확인)

Label Studio 내부 annotation 결과 예시 :

"result": [
  {
    "type": "rectanglelabels",
    "value": {
      "x": 15.36,
      "y": 38.23,
      "width": 83.23,
      "height": 46.77,
      "rectanglelabels": ["happy_face"]
    }
  }
]

• 박스 있음
• 라벨 있음
• YOLO 변환 가능

✏️YOLO 형식으로 Export

Label Studio Export 옵션 중에서

선택함.

• 이미지 + 라벨(txt) 함께 다운로드
• YOLOv8 학습에 바로 사용 가능

✏️YOLOv8 학습용 폴더 구조

yolo_dataset/
├── images/
│   ├── train/
│   └── val/
├── labels/
│   ├── train/
│   └── val/
└── data.yaml

• images/val, labels/val 폴더는 비어있어도 반드시 존재해야함.

✏️data.yaml 작성(중요)

path: /Users/admin/yolo_dataset

train: images/train
val: images/val

names:
  0: happy_face

❗ macOS에서는 경로 앞에 '/' 필수

✏️YOLOv8 학습 실행

❗❗중간에 겪은 주요 에러 & 해결❗❗

1. data.yaml 경로 에러

Dataset 'Users/admin/...' does not exist

->원인 : 절대경로 '/'누락

2. images/val not found 에러

images not found, missing path images/val

• 원인 :
  • val 폴더 없음
  • data.yaml의 path와 실제 폴더 불일치
• 해결 :

mkdir -p images/val labels/val

✏️결과 확인

학습 완료 후 :

• loss 정상 감소
• 예측 시 웃는 얼굴에만 박스 생성
• runs 폴더 생성됨

1. 이번 프로젝트의 목표는?

내 목표는 단순했다. 단순히 정답만 잘 맞히는 AI가 아니라, '왜 이사람이 흡연자라고 생각해?' 라는 질문에 당당하게 답할 수 있는 똑똑한 프로그램을 만들어 보는것!

2. 데이터랑 친해지기(EDA)

우선 데이터부터 꼼꼼히 뜯어봄. 혈압,콜레스테롤,간 수치까지 데이터가 정말 방대했닿...ㅎ

• 의외의 발견 : 분석해 보니 '헤모글로빈'수치랑 '간 수치'가 흡연 여부랑 연관이 깊어보였음. 역시우리 몸은 거짓말을 안함..
• 불균형의 늪 : 비흡연자가 훨씬 많아서, 단순히 정확도만 높이다간 큰일 나겠다싶었음. 그래서 이번엔 F1-socre 로 확인하기로 함.

3. 전처리하기

• 파생 변수 만들기

  df['콜레스테롤'] = df['콜레스테롤'].clip(upper=400)
  df['중성 지방'] = df['중성 지방'].clip(upper=500)
  df['공복 혈당'] = df['공복 혈당'].clip(upper=300)

• 이상치 처리 : 삭제 대신 / 클리핑 사용.
  • 극단값 제거 대신 정보 손실 최소화
  • 실제 의료 데이터 특성고려

4. 데이터 분리 ,스케일링

• Stratify 적용

train_test_split(..., stratify=y)

-> 클래스 불균형 유지

• RobustScaler 사용
  • 이상치에 강함
  • 트리 모델 + 앙상블에 안정적

5. 모델링 : 앙상블, 튜닝

하나의 모델만 쓰기엔 성능을 또 다다를수있어서 3모델을 써봄.

• XGBoost, LightGBM, CatBoost 3모델을 Soft Voting으로 묶음.
• 예측이 탄탄하고 안정적인느낌.
• XGBoost + Optuna

  study.optimize(objective, n_trials=20)

• F1-socre 기준 최적화
• learnin_rate 낮게 -> 과적합 방지

*혼자서도 충분히 강한기준 모델확보하기

• 앙상블(Soft Voting)

  VotingClassifier(
  estimators=[XGB, LGBM, CAT],
  voting='soft',
  weights=[1, 1, 2]
  )

• 서로 다른 트리 계열 모델의 장점 결합
• CatBoost 가중치 ↑
  • 범주/비선형 패턴에 강함

* 예측이 안정적이고 흔들림 적음

6. 임계값,🔥🔥0.378 !!!

제일 공을 들인 작업이기도함. 바로 임계값(Threshold)찾기 . 보통 기준 0.5지만, 0.001 단위로 조정해가면서 테스트할 결과 0.378이라는 포인트 찾음 리더보드는 0.744 나옴 . 근데 아직 만족못해서 벨로그 작성후에도 계속 코드 만져볼 예정임.

* 나의 프로젝트 하이라이트 뽀인또

7. 모델 평가 및 시각화

혼동 행렬 과 모델별 성능 비교를함. 혼동행렬은 어떤 유형에서 실수하는지 분석하고 FN/FP확인함 모델별 성능 비교는 단일 모델 vs 앙상블로함. 앙상블이 가장 균형잡힌 F1, Recall을 줌

8.SHAP

shap.TreeExplainer(best_xgb)

결과만 내놓기보다는 SHAP 분석을 통해 모델들을 들여다봄. 확인해 보니 헤모글로빈과 신장이 예측에 엄청난 영향을주고있었음. 의학적으로도 일리가 있는 결과라 모델에 대한 신뢰도가 올라감.

프로젝트 마무리

처음에는 코딩하고 점수 올리기 바빳는데, 이번 프로젝트하면서 단순 알고리즘만 돌리는게 아니라 이유 있는 결과를 찾아가는 방식으로 조금 바뀐것같음. 해석 가능한 예측모델로 만들어가는듯함. EDA → 전처리 → 앙상블 → Threshold → SHAP 단계를 거쳐보면서 전체 파이프라인 경험을 해봄. 이 미니 프로젝트 외에 이제 팀 프로젝트가 남았지만 , 그 또한 개인으로한 프로젝트를 바탕으로 조금 더 발전 해보려고함! 마지막 완성한 ppt 자료도 기록해놔야지 ㅎㅎ !

📎 발표자료(PDF)

• 흡연데이터 PPT 자료

그리고 앙상블로 LightGBM,XGBoost,CatBoost 를 써봣는데 데이터자체가 범주형이아닌데 캣부스트 수치가 높게나와서 그것또한 의문을 품고 어디가 잘못되었는지 찾고있다.

이 프로젝트를 진행하면서 그래도 조금 더 용어라던가,모델들을 어떤식으로 쓰여야하는지 이유가 무엇때문인지를 공부할수있게되는것같아서 머리는 아프긴해도 좋은것같다!

사실 오늘이 갓생일기는 마지막날이다 벗뜨, 나는 이 습관의 계기로 날마다 공부한걸 최대한 하루에하나 못해도 일주일에하나씩은 올릴 예정이다.! 그래야 조금이라도 공부한 내용도 정리할수있으니까! 힘내보쟈아아아!!!!