하얀하얀IT

오라클 클라우드 Always Free 정책 변경 - ARM 인스턴스 4 OCPU/24GB → 2 OCPU/12GB로 축소하기

WHITE_FROST — Sun, 14 Jun 2026 15:38:41 +0900

Oracle Cloud의 ARM 인스턴스를 활용하고 있다. 그런데 최근 Oracle Cloud의 Always Free 정책에 변경 사항이 생겼다는 알림을 받았다.

핵심은 기존 ARM(A1.Flex) 인스턴스의 Always Free 한도가 4 OCPU / 24GB → 2 OCPU / 12GB로 줄어들었다.

이 한도를 초과해서 계속 사용하면 표준 요금이 부과되거나, 사용이 강제로 중지될 수 있다고 한다. 그래서 기존에 4 OCPU / 24GB로 운영하던 인스턴스를 새로운 한도에 맞춰 줄이는 작업을 진행했다. 이 글에서는 변경 사항과 대응 방법을 정리한다.

1. 무엇이 바뀌었나

오라클 공식 문서(Always Free Resources) 기준으로 정리하면 다음과 같다.

OCI Ampere A1 Compute (ARM) : VM.Standard.A1.Flex 셰이프 사용 시, 매월 1,500 OCPU시간 + 9,000 GB시간까지 무료
Always Free 테넌시 기준으로 환산하면 2 OCPU + 12GB 메모리에 해당
A1.Flex는 유동 셰이프(flexible shape)이기 때문에, 이 자원을 단일 인스턴스에 모두 할당하거나 1 OCPU + 6GB씩 인스턴스 2개로 나눠서 사용할 수도 있음

즉, 기존에 익숙했던 "4코어 24GB" 구성은 더 이상 Always Free 범위가 아니고, 2코어 12GB가 새로운 기준선이 된 것이다.

2. 한도 초과 시 어떻게 되나

공지에 따르면 변경된 기준을 초과한 사용량에 대해서는

표준 요금이 부과되거나
사용이 강제로 중지될 수 있음

이라고 안내되어 있다. 즉, 그동안 4 OCPU / 24GB로 잘 쓰고 있던 인스턴스를 그대로 두면 어느 시점부터 과금 대상이 되거나 강제 조치를 당할 수 있다는 뜻이다. 무료로 계속 쓰고 싶다면 새 기준에 맞춰 직접 사양을 줄여야 한다.

3. 인스턴스 사양 줄이는 방법

OCI 콘솔에서 직접 수정할 수 있다. 절차는 다음과 같다.

1. OCI 콘솔 → Compute → Instances로 이동해 대상 인스턴스로 들어간다.

2. 인스턴스 상세 페이지에서 Action(추가 작업) → Edit을 클릭한다.

3. Edit Instance 화면에서 Ampere Shape Configuration 항목으로 이동한다.

Number of OCPUs를 4 → 2로 변경한다.

5. Amount of Memory (GB)를 24 → 12로 변경한다.

6. 변경 사항을 저장한다.

저장 후 인스턴스가 새 사양으로 재구성되며, 이제부터는 Always Free 한도 내에서 운영되는 상태가 된다.

4. 후기

솔직히 두 달 정도 4 OCPU / 24GB 환경에서 잘 써왔던 터라, 갑자기 사양이 절반으로 줄어드는 건 꽤 아쉬웠다. 돌리고 있던 서비스들 입장에서는 자원이 빠듯해질 수도 있는 변화다.

그래도 어쨌든 무료로 계속 쓸 수 있다는 게 가장 중요하니, 새로운 한도에 맞춰 운영하는 쪽으로 정리했다. "그래도 무료서버니까 쓰자" 하는 마음으로

5. 참고: 남은 자원 활용 팁

공식 문서에 따르면 Always Free A1.Flex 자원(2 OCPU / 12GB)은 꼭 단일 인스턴스에만 쓸 필요는 없다. 1 OCPU / 6GB씩 인스턴스 2개로 나눠서 운영하는 것도 가능하다.

용도별로 인스턴스를 분리하면 한쪽에 문제가 생겨도 다른 쪽에 영향을 주지 않는다는 장점이 있다. 예를 들어 하나는 웹서버/리버스 프록시용, 다른 하나는 백엔드 서비스용으로 나누는 식이다. 현재는 2 OCPU / 12GB 단일 인스턴스로 운영 중이지만, 추후 용도가 늘어나면 분리 운영도 고려해볼 만하다.

참고 문서

Oracle Cloud - Always Free Resources

오라클 클라우드 VPN 서버 구축 (WireGuard VPN)

WHITE_FROST — Tue, 26 May 2026 12:54:50 +0900

개요

오라클 클라우드 프리티어 싱가포르 인스턴스에 WireGuard 기반 VPN 서버를 구축하는 과정이다. wg-easy라는 Docker 이미지를 사용해 웹 UI로 간편하게 관리할 수 있도록 구성한다.

환경

Oracle Cloud Infrastructure (OCI) Free Tier
리전: ap-singapore-1 (싱가포르)
OS: Ubuntu (ARM Ampere A1)
Docker 29.4.3
Docker Compose 5.1.3

1. Docker 설치

# 패키지 업데이트
sudo apt update && sudo apt upgrade -y

시스템 패키지 목록을 최신화하고 업그레이드한다.

# Docker 공식 설치 스크립트 실행
curl -fsSL https://get.docker.com | sh

Docker 공식 스크립트를 받아 자동으로 설치한다.

# 현재 유저를 docker 그룹에 추가
sudo usermod -aG docker $USER

이 명령어 없이는 docker 명령어를 실행할 때마다 sudo가 필요하다. 그룹에 추가하면 일반 유저 권한으로도 docker를 사용할 수 있다.

# 그룹 변경 즉시 적용
newgrp docker

재로그인 없이 docker 그룹 권한을 현재 세션에 바로 적용한다.

# 설치 확인
docker --version
docker compose version

정상 설치 시 아래와 같이 출력된다.
Docker version 29.4.3, build 055a478
Docker Compose version v5.1.3

2. 오라클 콘솔 Security List 포트 개방

오라클 클라우드는 방화벽이 2중 구조다

인터넷 → OCI Security List (콘솔) → 서버 내부 iptables → 서비스

두 곳 모두 포트를 열어줘야 한다.

OCI 콘솔에서 Ingress Rules 추가

Networking → Virtual Cloud Networks
→ VCN 클릭 → Security 탭
→ Default Security List → Add Ingress Rules

Ingress Rule 1 (WireGuard 터널)

항목	값
Stateless	체크 해제
Source Type	CIDR
Source CIDR	0.0.0.0/0
IP Protocol	UDP
Destination Port	51820

51820은 WireGuard의 기본 포트. 실제 VPN 터널 트래픽이 이 포트로 들어온다.

Ingress Rule 2 (wg-easy 웹 UI)

항목	값
Stateless	체크 해제
Source Type	CIDR
Source CIDR	0.0.0.0/0
IP Protocol	TCP
Destination Port	51821

51821은 wg-easy 웹 관리 UI 포트. 브라우저에서 VPN 클라이언트를 추가하고 QR코드를 발급받는 용도이다.

3. 서버 내부 iptables 포트 개방

오라클 Ubuntu는 ufw가 기본 설치되어 있지 않아 iptables를 직접 사용한다.

# WireGuard 포트 허용
sudo iptables -I INPUT -p udp --dport 51820 -j ACCEPT

-I INPUT : INPUT 체인 맨 앞에 규칙 삽입
-p udp : UDP 프로토콜
--dport 51820 : 목적지 포트 51820
-j ACCEPT : 해당 트래픽 허용

# wg-easy 웹 UI 포트 허용
sudo iptables -I INPUT -p tcp --dport 51821 -j ACCEPT

# 재부팅 후에도 규칙 유지되도록 저장
sudo apt install iptables-persistent -y
sudo netfilter-persistent save

iptables 규칙은 기본적으로 재부팅하면 초기화된다. iptables-persistent 패키지가 부팅 시 규칙을 자동으로 복원

# 규칙 적용 확인
sudo iptables -L INPUT | grep -E '51820|51821'

아래와 같이 출력되면 정상

ACCEPT     tcp  --  anywhere   anywhere   tcp dpt:51821
ACCEPT     udp  --  anywhere   anywhere   udp dpt:51820

4. wg-easy란?

WireGuard VPN 서버를 쉽게 관리할 수 있는 Docker 이미지다.

wg-easy
  ├── WireGuard 서버 (51820 UDP) → 실제 VPN 터널
  └── 웹 UI (51821 TCP)          → 클라이언트 관리 페이지

웹 UI에서 클라이언트 추가 시 QR코드를 발급해줘서 폰에서 스캔만 하면 바로 연결된다.

5. 비밀번호 해시 생성

wg-easy는 보안을 위해 평문 비밀번호 대신 bcrypt 해시를 사용한다

docker run --rm -it ghcr.io/wg-easy/wg-easy wgpw '원하는비밀번호'

--rm : 명령어 실행 후 컨테이너 자동 삭제
-it : 터미널 입출력 활성화
wgpw : wg-easy 내장 비밀번호 해시 생성 명령어

이미지가 없으면 자동으로 pull 해오기 때문에 별도 설치 없이 바로 실행 가능하다.
실행 결과로 아래와 같은 해시가 출력된다.

$2b$12$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

이 값을 복사해둔다.

6. docker-compose.yml 작성

mkdir ~/wg-easy && cd ~/wg-easy
nano docker-compose.yml

아래 내용을 붙여넣는다.

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy
    container_name: wg-easy
    environment:
      - LANG=en
      - WG_HOST=<서버_공인IP>
      - PASSWORD_HASH=$$2b$$12$$나머지해시
    volumes:
      - ~/.wg-easy:/etc/wireguard
    ports:
      - "51820:51820/udp"
      - "51821:51821/tcp"
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

환경변수 설명

LANG=en : 웹 UI 언어 설정
WG_HOST : 서버 공인 IP (클라이언트가 접속할 주소)
PASSWORD_HASH : 웹 UI 로그인 비밀번호 해시

주의: $ → $$ 로 변환 필수
docker-compose.yml에서 $는 변수 선언 특수문자로 인식됩니다. 해시값의 모든 $를 $$로 바꿔야 정상 동작한다.

원본: $2b$12$xxxx 변환: $$2b$$12$$xxxx

볼륨/권한 설명

~/.wg-easy:/etc/wireguard : WireGuard 설정 파일 영구 저장
NET_ADMIN : 네트워크 인터페이스 제어 권한
SYS_MODULE : 커널 모듈 로드 권한
net.ipv4.ip_forward=1 : IP 포워딩 활성화 (VPN 트래픽을 인터넷으로 전달하기 위해 필수)

저장은 Ctrl+X → Y → Enter

7. 컨테이너 실행

docker compose up -d

-d : 백그라운드 실행 (detached mode)

아래와 같이 출력되면 성공이다.

[+] Running 2/2
 ✔ Network wg-easy_default  Created
 ✔ Container wg-easy        Started

8. 웹 UI 접속

브라우저에서 아래 주소로 접속한다.

http://<서버_공인IP>:51821

로그인 화면이 뜨면 설정한 비밀번호를 입력한다.

9. 클라이언트 추가 및 연결

앱 설치

기기	설치
iPhone	App Store → WireGuard
Android	Play Store → WireGuard
MacBook	Mac App Store → WireGuard

클라이언트 추가

웹 UI → + New Client → 이름 입력 (예: iPhone, MacBook) → Create → QR코드 생성

폰에서 연결

WireGuard 앱 → + 버튼 → QR코드 스캔 → 터널 추가됨 → 토글 ON

10. VPN 연결 확인

브라우저에서 아래 사이트 접속 후 IP 확인

https://ifconfig.me

서버 공인 IP(싱가포르 IP)로 표시되면 VPN이 정상적으로 동작한다.

보안 관련 참고사항

51821 포트(웹 UI)를 24시간 열어두면 봇들의 로그인 시도가 발생할 수 있다.

운용 방식	장점	단점
항상 열어두기	편함	브루트포스 시도 노출
필요할 때만 열기	안전	콘솔 접속 번거로움

비밀번호를 충분히 강하게 설정했다면 열어두는 것도 현실적으로 큰 문제는 없다.. wg-easy 자체적으로 로그인 실패 횟수 제한이 있어 브루트포스를 어느정도 방어한다.

YOLO11 실전 배포에서 마주친 이미지 처리 문제들

WHITE_FROST — Mon, 25 May 2026 18:34:22 +0900

이미지

어떤 프로젝트였나

AI 영양제 관리 플랫폼을 개발하면서 YOLO11 모델을 직접 학습시켜 영양제를 인식하는 기능을 구현했다. 이 과정에 모델을 학습시키는 것에서 생기는 문제를 마주쳤고, 그 과정을 기록한다.

문제 1. 학습은 잘 됐는데 실제 서비스에서 인식을 못 한다?

가장 오래 헤맸던 문제다.

모델 학습은 분명히 잘 됐는데, 실제로 핸드폰으로 찍은 사진을 넣으면 인식을 제대로 못 하는 상황이 반복됐다.

원인은 해상도 차이였다.

학습할 때 사용한 이미지는 1000×1000 이내로 맞춰서 넣었는데, 실제 서비스에서는 핸드폰으로 찍은 원본 이미지를 그대로 모델에 박아버렸던 것이다. 최신 스마트폰 사진은 3000×4000을 훌쩍 넘는다.

모델 입장에서는 학습 때 본 적 없는 크기의 이미지가 들어오니 특징을 제대로 추출하지 못한 거였다.

해결책: 비율 유지 리사이징

# 가로 또는 세로가 1000px 초과 시 비율 유지하며 리사이징
img.thumbnail((1000, 1000))

가로세로 비율을 유지하면서 1000×1000 박스 안에 들어오도록 줄여주면 인식률이 확 올라갔다.

만약 학습데이터가 적을경우 학습한 데이터의 종류도 확실히 파악하고 처리를하자

문제 2. 리사이징 했는데도 가끔 인식을 못 한다?

리사이징을 적용했는데도 여전히 인식이 안 되는 케이스가 있었다. 그런데 이상하게 수동으로 편집한 이미지는 잘 됐다.

원인은 EXIF 회전 정보였다.

스마트폰은 사진을 찍을 때 픽셀 데이터는 항상 센서 기준(가로 방향)으로 저장하고, "이 사진은 90도 돌려서 봐야 해"라는 정보를 EXIF 메타데이터에 따로 저장한다. 갤러리 앱이나 브라우저는 이걸 읽어서 자동으로 돌려서 보여주니까 우리 눈엔 항상 정방향으로 보이는 것이다.

문제는 PIL 같은 라이브러리가 이 EXIF 정보를 기본적으로 무시한다는 것. 그래서 모델한테는 영양제가 옆으로 누운 이미지가 그대로 들어가버린다.

해결책: exif_transpose() 적용

from PIL import Image, ImageOps

img = Image.open("photo.jpg")
img = ImageOps.exif_transpose(img)  # EXIF 회전 정보를 실제 픽셀에 반영

exif_transpose()는 Pillow에서 공식으로 제공하는 함수로, EXIF의 회전 정보를 읽어서 픽셀 데이터를 실제로 돌려준다. 이걸 리사이징 전에 먼저 적용해야 한다.

문제 3. 인식은 됐는데 바운딩 박스 위치가 이상하다?

리사이징한 이미지로 분석하면 좌표도 리사이징된 이미지 기준으로 나온다. 그런데 프론트엔드에서는 원본 고해상도 이미지 위에 바운딩 박스를 그려야 했다.

해결책: 좌표 역스케일링

원본 좌표 = 리사이즈 좌표 × (원본 크기 / 리사이즈 크기)

리사이즈 비율만큼 다시 곱해주면 원본 이미지 기준 좌표로 복원할 수 있다.

정리

문제	원인	해결
원본 이미지 인식 불가	학습 해상도와 입력 해상도 차이	1000px 이내로 비율 유지 리사이징
리사이징 후에도 인식 실패	EXIF 회전 정보 미처리	`exif_transpose()` 선적용
바운딩 박스 위치 틀림	리사이즈 좌표 그대로 사용	역스케일링으로 원본 좌표 복원

AI 서비스에서 이미지를 다룰 때는 해상도 정규화와 메타데이터 처리 두 가지를 반드시 챙겨야 한다.

결과

리사이징시에는 정확하게 인식	원본 사진은 인식을 못한다
리사이징 시에는 정확히 인식	원본사진은 제대로 인식을 못함

오라클 클라우드에 접속하는 봇들을 막자

WHITE_FROST — Sun, 24 May 2026 17:20:20 +0900

오라클 클라우드 무료 티어로 서버를 하나 띄웠다. 처음엔 WireGuard VPN만 올려두고 아무것도 안 했다. 그런데 SSH 로그를 열어봤더니 이미 난리가 나 있었다.

May 11 23:26:00 sshd: Connection closed by authenticating user root 158.180.74.12 [preauth]
May 11 23:27:17 sshd: Connection reset by authenticating user root 2.57.122.196 [preauth]
May 11 23:28:13 sshd: Disconnected from authenticating user root 176.65.132.50 [preauth]
May 11 23:31:19 sshd: Connection reset by authenticating user root 2.57.122.194 [preauth]

공개 IP가 할당된 순간부터 전 세계 봇들이 이미 두드리고 있었던 거다. 내가 서버를 켠 게 아니라 IP가 생긴 것만으로 표적이 된 셈이다.

왜 이런 일이 생기나?

인터넷에는 24시간 돌아가는 자동화 스캐너들이 있다. 이 봇들은 전 세계 IP 대역을 순서대로 훑으면서 열린 포트를 찾고, SSH 같은 서비스가 뜨면 자동으로 로그인을 시도한다.

주로 시도하는 계정은 root, admin, ubuntu, test 같은 기본 계정들이다. 비밀번호도 123456, password, admin 같은 걸 리스트로 돌린다. 이걸 브루트포스 공격이라고 한다.

로그에서 [preauth]가 붙어있는 건 인증 단계조차 넘지 못했다는 뜻이다. 즉, 시도는 했지만 전부 실패한 거다.

오라클 클라우드 기본 설정은 꽤 튼튼하다

다행히 오라클 클라우드 인스턴스는 기본적으로:

SSH 비밀번호 로그인이 비활성화되어 있다
키 파일(pem)이 없으면 접속이 불가능하다
root 직접 로그인도 막혀있다

그래서 봇들이 아무리 두드려도 키 없이는 들어올 수 없다. 하지만 그렇다고 마냥 방치하는 건 찜찜하다. 로그가 쌓이고, 서버 리소스도 조금씩 낭비된다.

Fail2ban으로 자동 차단하기

Fail2ban은 로그를 실시간으로 감시하다가 일정 횟수 이상 실패한 IP를 자동으로 차단해주는 도구다.

설치는 간단하다:

`sudo apt install fail2ban -y
sudo systemctl enable fail2ban --now`

설치 후 차단된 IP 목록 확인:

`sudo fail2ban-client status sshd`

이런 식으로 출력된다:

`Status for the jail: sshd
|- Currently failed:  3
|- Total failed:      47
`- Banned IP list:    2.57.122.189 45.148.10.121 ...`

아까 로그에서 계속 보이던 2.57.122.xxx 같은 봇들이 여기 들어오게 된다.

더 나아가서 — SSH 포트 바꾸기

봇들은 대부분 기본 포트인 22번만 스캔한다. SSH 포트를 22가 아닌 다른 번호로 바꾸는 것만으로도 봇 트래픽의 99%가 사라진다.

`sudo nano /etc/ssh/sshd_config
# Port 22 → Port 2222`

단, 포트를 바꾸면 오라클 콘솔의 Security List에서도 새 포트를 열어줘야 한다.

정리

공개 IP를 가진 서버는 켜는 순간부터 공격 대상이 된다. 이건 특별한 일이 아니라 인터넷에서 서버를 운영한다는 게 원래 그런 거다.

중요한 건:

SSH 키 인증만 허용 — 비밀번호 로그인은 비활성화
Fail2ban 설치 — 반복 시도 IP 자동 차단
포트 변경 (선택) — 봇 트래픽 대부분 차단

이 세 가지만 해도 웬만한 자동화 공격은 다 막힌다. 로그를 보면서 봇들이 튕겨나가는 걸 확인하는 것도 나름 재미있는 경험이었다.

클로드 디자인(Claude Design) 종속성 벗어나기: 완벽한 로컬 오픈소스 대안, OpenDesign 리뷰

WHITE_FROST — Sun, 3 May 2026 23:38:45 +0900

최근 AI를 활용한 UI/UX 프로토타이핑 도구들이 쏟아지는 가운데, 단연 돋보이는 것은 Anthropic이 발표한 Claude Design 이다. 간단한 프롬프트만으로 와이어프레임부터 고해상도 프로토타입, 슬라이드 덱까지 순식간에 만들어내는 퍼포먼스는 개발자 입장에서도 상당히 인상적이다. 하 지만 강력한 기능 이면에는 항상 '종속성’이라는 고민이 따른다.

Claude Design 요금

클로드가 아무리 뛰어난 결과물을 내어준다고 해도, 결국 우리는 플랫폼이 정해놓은 '주간 한도' 와 '불투명한 요금제'라는 울타리 안에서만 움직일수밖에 없다. 개발 환경에서 특정 SaaS에 완전히 종속된다는 것은 장기적인 생산성 관점에서 리스크가 될 수 밖에 없다.

게다가 클로드의 Claude Design은 아직까지는 요금제가 정해지지 않은 상태이다. 결국 점점 더 큰 요금제를 강요하게 될 수 밖에 없다.

1. Claude Design, 무엇이 강점이고 무엇이 한계인가?

대안을 살펴보기 전에 원본인 클로드 디자인의 워크플로우를 먼저 살펴보자

Claude Design 선택화면

현재 클로드 디자인은 크게 다음 4가지 기능을 지원한다.

Prototype: 간단한 와이어프레임부터 고해상도 프로토타입 제작
Slide deck: 슬라이드 및 프레젠테이션 제작
From template: 템플릿을 활용한 짧은 쇼츠 영상 제작
Other: 디자인 시스템 구축 등 기타 기능

Claude Design 실행화면

Prototype 실행하면 다음과 같은 화면이 나오게 된다.

여기서 나는 좌측 하단 프롬프트 입력창에 아래사진과 같이 입력했다.

프롬프트 입력

그 결과로 아래와 같은 새로운 입력창이 나온다.

Claude QNA

클로드 디자인 아니 클로드의 가장 큰 장점인 프롬프트를 단순하게 받아들이지 않고 사용자의 목표나 목적등을 구체적으로 역질문 하면서 프롬프트를 더 깎아 나가준다.

결과

결과페이지

결과가 생각보다 만족스럽지는 않았지만, 그래도 이정도의 퀄리티를 빠르게 만드는 부분은 정말 항상 대단하다고 느낀다.

또 결과물 역시 단순한 이미지가 아니라, Vercel이나 로컬 환경으로 즉시 넘길 수 있도록 HTML/React 기반 코드로 Handoff를 지원한다.

하지만 바로 이 지점에서 치명적인 한계가 발생한다. 아무리 클로드 디자인이 훌륭하게 디자인을 뽑아내 준다고 한들, 이 모든 작업은 결국 막대한 토큰 소모와 직결되서 , 디자인 시안을 몇 번만 수정하고 코드로 변환하다 보면 금세 토큰을 다 써버리거나 주간 한도 초과 메시지를 만나게 될것이다.

개발자 입장에서 편히 작업을 돌릴 수 없다는 것이 도구로서 엄청난 제약일 수 밖에 없다.

2. 완벽한 탈중앙화 대안: OpenDesign

클로드의 훌륭한 워크플로우는 그대로 가져가되, 실행 환경의 주도권은 내가 쥐고 싶다면 nexu-io/open-design이 훌륭한 해답이 된다.

Open Design 설명

Apache 2.0 라이선스로 공개된 이 프로젝트로 "클로드 디자인의 95%를 가져온 오픈소스 대안"이라고 소개 할만큼 대안이 될 정도로 충분하다고 생각한다.

자체적인 AI를 강제하는 대신, 내 로컬에 깔려있는 Claude Code, Cursor, Gemini CLI 등을 감지하여 디자인 워크플로우에 연결해 주는 것을 직접 통제할 수 있다

설치와 실행은 아래와 같이 간단하다.

git clone https://github.com/nexu-io/open-design.git
cd open-design
corepack enable
corepack pnpm --version   # 10.33.2
pnpm install
pnpm tools-dev run web

설치하면 바로 아래와 같은 화면이 나오게 된다.

Open Design 모델 선택

세팅 화면에 진입하면 현재 내 환경에 설치된 CLI 도구들을 자동으로 스캔하여 실행 모드를 선택할 수 있다. 특정 AI에 종속되지 않고 언제든 백엔드 모델을 교체할 수 있는 유연성이 보인다.

Open Design 실행이미지

어디서 많이 보질 않았는가? 괜히 Claude Design의 95% 를 가지고 왔다는게 아니다.

진행 방식도 비슷하게 된다. 처음 Claude Design 과는 다르게 " 면접관에게 보여줄 개발자 랜딩 페이지 " 라 프롬프트를 쳤다.

Open Design QnA

그 결과로 여기도 역시 이렇게 질문을 해주는 QnA 창이 등장한다.

Open Design Color 선택

비주얼 톤, 컬러 팔레트와 타이포그래피 등을 세밀하게 조정할 수 있는 설정창도 나오는게 인상적이다. 아마 색까지 디테일하게 물어보면 더 좋게 이미지를 뽑아주지 않을까 싶다.

결과

Open Design 결과

더 좋은점

여기에 더 좋은 점은, OpenDesign이 단순한 UI/UX 디자인 생성기에 그치지 않는다. 상단 탭을 보면 디자인뿐만 아니라 Image, Video, Audio 생성 툴까지 통합되어 있는 걸 볼 수 있다..

다만 한 가지 주의할 점은, Image 생성 같은 기능들을 사용할 때는 별도의 API Key를 요구한다. 이 부분은 미리 세팅할 때 참고하시면 좋을 듯.

총평: 도구의 주인이 되기 위한 한 걸음

OpenDesign을 직접 로컬에 띄워 테스트해 보며 느낀 점은, 이제 AI 기반의 디자인 제너레이터 역시 특정 기업의 독점적인 서비스에서 점차 오픈 생태계로 풀려나오고 있다.

여전히 완성도 면에서는 공식 클로드 디자인이 한 발 앞서 있을 수 있다. 하지만, 구독료나 토큰 제한의 눈치를 보지 않고, 내가 선호하는 LLM 모델을 붙여 무제한으로 디자인 이터레이션을 돌려보는것은 개발자에게 엄청난 자유도를 부여한다.

단순히 남이 만들어둔 SaaS를 소비하는 것에 그치지 않고, 로컬 환경에서 직접 워크플로우를 통제하고 싶으시다면 OpenDesign은 충분히 클론하고 세팅해 볼 가치가 있는 프로젝트다.

클로드 코드 공부 기록

WHITE_FROST — Tue, 21 Apr 2026 04:51:48 +0900

클로드코드를 사용하고 있지만 막상 사용하다보면 “내가 이걸 잘 쓰고 있는건가?” , “다른 사람들은 나보다 더 잘 쓰는거 같은데?” 라는 생각과 함께 계속해서 새롭게 들어오는 지식들과 합쳐지다 보니 뇌속에 정리가 안되어있다.

때문에 클로드 코드 공부 내용을 기록 하려고한다.

1단계 : 아무거나 만들어보기

to-do app , 랜딩페이지, 계산기 같은 간단한 SaaS 서비스 하나 만들어보기

완벽한 결과물일 필요도 없고, 클로드 코드가 어떻게 돌아가는지 알아보는 단계이다.
다만 중요한점은 / 명령어로 작업 환경과 감각을 익혀보자

2단계 : 결과물이 마음에 안든다 → SDD / TDD

1단계에서 최종결과물로 만들어졌지만 구조가 지저분하고 수정해도 만족스럽지 못할때 활용

기준을 먼저 세우는기획의 단계이다.

설계 하는 단계이다.
“어떤 하나를 만들어달라” 라는 요청의 개념에서 이 기능의 목적은 뭐고, 입력은 뭐고, 성공조건, 실패케이스 등 어떻게 통과하는지를 주는것이다.
SDD , TDD 작성하기

3단계 : 반복되는 작업이 보인다. → Skills

3단계 에서는 작업하는 단계에서 계속 반복하는 작업이 있을것이다. 이 부분을 캐치하는것이다.

내가 자주쓰는 방식, 체크리스트, 플레이북, 노하우를 Claude가 다시 사용할 수 있게 만드는것
Skills 는 MCP 와 다르게 재사용 가능한 능력의 개념이다.
/ 형태로 호출해보기, 직접 Skills 만들어보기, 다른사람이 만든 Skills 사용하기

4단계 : 메모리와 컨텍스트 관리

프로젝트 룰, 파일 구조를 매번 다시 설명하고 있을때 사용한다.

CLAUDE.md 를 작성할것, /init 을 통한 초안 작성하고 메모리를 점진적으로 축적할 것
빌드 / 테스트 명령, 폴더 역할, 선호 라이브러리, 커밋전 점검 항목
메모리 관리, 컨텍스트 관리

5단계 : 자동화의 시작 → Hooks 를 통한 외부 연결

Claude 에게 일을 시키는 것이 아니라 작업 흐름 자체를 자동화 한다.

Hooks 의 개념 → 클로드 코드 라이프 사이클에서 특정 지점에 자동 실행되는 사용자 정의 명령어
파일 수정후 → 포맷팅, 검증, 알림, 규칙 위반시 차단등자동화 작업이다.
MCP로 외부 서비스 연결 가능
Chrome, Github Actions, 스케줄 같은 작업 연결

6단계 : 프로젝트가 커졋을때 → Subagents / Agent Teams

파일도 많아지고 역할도 나뉘고 병렬처리의 시작이다.

Subagents 는 한 세션 안에서 분리된 컨텍스트로 하위작업을 수행하고 요약된 결과를 메인으로 돌린다.
Agent Teams 는 독립적인 세션들이 서로 소통하며 협업 구조이다. (front , back, test)
Subagents는 짧고 집중된 작업을 깨끗하게 분리할때 좋다.
Agent Teams 는 서로의 역할을 나누면서 조금 더 큰단위의 일을 굴릴때 사용

7단계 : 클로드 코드 작업 시스템을 설계하는 단계 Agent Harness

Claude Code 위에 도구, 컨텍스트 관리, 실행 환경을 넣은 하나의 agentic harness단계이다.

AI agents 가 코드를 잘 짤 수 있는 환경을 만들어주는것이 Harness ( AI 가 인간의 개입 없이 최대한 스스로 만들 수 있게끔 하는 그 시스템을 만들자 하는게 하네스 엔지니어링의 시작 )

즉 위에서 했던 모든 단계 , 제약 조건 + 도구 + 피드백 루프 + 문서화 등 이 모든것의 전체 운영 환경을 만들어주는것이 Harness engineering 이다.
Harness engineering : 하네스를 체계적으로 설계하고 개선하는 기술
실수 시 프롬프트 변경이 아니라 실수가 구조적으로 재발하지 못하도록 만들어내는것!

7단계의 Claude 에 관한 개발단계를 적었다. 직접 해본 경험이 있어서 추후에 빠른 학습이 될거 같다.

각각 단계별로 글을 추가적을 작성하겠다.

4월에 글을 다시 시작하며

WHITE_FROST — Thu, 16 Apr 2026 09:26:33 +0900

지난 1월의 마무리 글에 매달 시작과 끝에 내 상황에 대한 정리를 다시 해보겠다고 작성했다.

개인 일정으로 인해 매달 초랑 말에 글을 쓰지 못했지만 그래도 1월의 내용을 리뷰하며 글을 작성해보겠다.

1월의 다짐은 다음과 같이 총 5개를 작성했다.

[스펙] ADsP & SQLD 시험 접수 / OPIc 등급 상향
[취업] 마스터 자소서 완성 및 10곳 지원 / 포트폴리오 최적화
[인프라] 가상화와 자동화가 적용된 '홈랩(Home Lab)' 구축
[AI] 바이브 코딩 루틴 정립 & 개발자의 본질적 가치 찾기
[알고리즘] 백준 골드 1 달성 (문제 해결력 기르기)

각각의 회고를 하나씩 하고 1~4 월이 되는동안 어떤 일이 있었고 무엇을 했는지 정리해보자

[스펙] ADsP & SQLD 시험 접수 / OPIc 등급 상향 (Fail)

스펙적으로는 나아진게 없다. 우선 ADsP 는 신청을 하지 못했고 SQLD는 이번에 아쉽게 떨어졌다. OPIc 역시 준비를 하지 않았기때문에 변동사항은 없다. 이번 취업준비를 하면서 대부분의 서류가 떨어졌는데, 이유를 분석하면 확실히 영어 등급의 상향이 필수적이라는 생각이 든다.

[취업] 마스터 자소서 완성 및 10곳 지원 / 포트폴리오 최적화 ( Half-success )

우선 10곳 이상은 확실히 지원했다. 결과가 안좋지 이번에 자기소개서를 적으면서 경험을 최적화시킨게 제일 좋은경험 아니였을까 싶다. 포트폴리오도 만들었다. 하지만 더 보충이 필요하다.

[인프라] 가상화와 자동화가 적용된 '홈랩(Home Lab)' 구축 (Success)

저번 알리익스프레스에서 산 미니피씨에 홈랩을 구축했다.

홈랩 구축이야기는 나중에 천천히 해보겠다. 현재는 도메인 구입후 연결까지한 상태

[AI] 바이브 코딩 루틴 정립 & 개발자의 본질적 가치 찾기 ( Half-success )

아이러니한 부분인 AI시대에 개발자의 본질적인 가치는 찾았다. 하지만 오히려 바이브 코딩 루틴은 적립하지 못했다.

[알고리즘] 백준 골드 1 달성 (Success)

삼성 소프트웨어 B형 시험을 하면서 여러 문제를 풀다보니 자연스럽게 골드 1을 달성했다.

그 동안 무엇을 했는가?

1 ~ 2 월은 AI 영양제 분석 프로젝트를 진행했고 2 ~ 4월은 중고거래 플랫폼 관련 프로젝트를 했다.

두개의 프로젝트를 하면서 나의 AI에 대한 도전을 계속했다. OCR 및 모델 튜닝 생성을 하기도 하였고 AI 검색이라는 기능도 개발한 경험이 되었다. 다만 아쉬운 점은 서류에서 많은 탈락이있어서 자존감이 조금 낮아졌다.

SSAFY 종료까지 아직 3개월 남았다. 3개월안에 취업하자

더 나은 UX를 위한 프론트엔드 전략에 관하여

WHITE_FROST — Thu, 12 Feb 2026 14:16:05 +0900

TMC25 | Engineering - 더 나은 UX를 위한 프론트엔드 전략

https://www.youtube.com/watch?v=Q-_crvz4tv8

해당 내용을 참고해서 글을 작성했습니다.

사용자의 경험을 결정 짓는 최고의 UX

다음 3가지로 정의된다.

유려한 UI : 보기 좋고 사용하기 편한 디자인
화면의 안정성 : Layout Shift 없는 견고한 화면
로딩 속도 : 사용자가 기다리는 시간의 최소화

여기서 로딩 속도를 이용하여 사용자의 UX를 개선하는 계획들을 살펴봤다.

1. SSR(Server Side Rendering)의 전략적 활용이 필요하다.

토스(Toss)의 렌더링 전략: 선택과 집중

화면이 위의 사진과 같다면

자산 영역 (상단): 내 통장에 얼마가 있는지 보여주는 가장 중요한 정보. (핵심가치)
소비 내역 (하단): 스크롤을 내려야 볼 수 있거나, 상대적으로 덜 급한 정보.

이때 토스는 '자산 영역'을 SSR로 처리하여 서버 통신과 동시에 사용자에게 즉각적으로 보여준다.

반면, 데이터 양이 많고 상대적으로 덜 중요한 '소비 내역'은 클라이언트 사이드에서 비동기로 불러오는 전략을 취한다.

보통 우리는 “서버의 부하를 막기 위해 CSR을 사용한다”거 나 혹은 “SEO(검색 최적화 엔진)을 위해 SSR을 사용한다고 알고 있었다. 하지만 위의 토스의 사례로 “사용자의 시선이 가장 먼저 닿는 곳” 을 먼저 파악하여 해당 부분만을 서버에서 미리 렌더링하여 유저의 경험을 극대화 시켜준다.

SSR 대상 선정 기준

그렇다면 어떤 컴포넌트를 SSR로 태워야 할까?

당장 위에서는 중요한 정보라고 말은 했지만 중요하다고 모든건 SSR로 돌리면 안된다.

SSR은 결국 서버 리소스를 사용하는 비용이 발생하므로 다음 두 가지 측면을 고려해서 선정해야된다.

비즈니스 측면: 사용자에게 가장 가치 있는 정보인가? (LCP와 직결)LCP는 사용자가 페이지가 떴을때 인지하는 시점이다. 토스와 같은 핀테크의 가장 큰 목적은 자산이다. 때문에, 가장 핵심 부분이 늦게 뜨면 사용자가 앱 전체가 느리다고 느끼기 때문에 결국 신뢰도 문제로 직결된다.
단순히 "중요하다"는 말을 넘어 Core Web Vitals(웹 성능 지표)와 사용자의 심리랑 이어서 생각해야된다.
기술적인 측면: 서버 부하를 감당할 수 있는가? 데이터 페칭 비용이 합리적인가?
SSR은 모든 데이터가 준비될 때까지 응답을 줄 수 없다. 만약 데이터 양이 많고 조회속도가 느린다면 이런경우는 절데 SSR을 담으면 안되다. 이런 경우 뒤의 Caching 전략으로 해결한다.

결국, SSR(Server Side Rendering)의 전략적 활용이 전체적인 UX를 향상시킨다.

2. 체감 속도를 높이는 마법 Caching)

토스는 거래 내역과 같은 데이터를 보여줄 때 로컬 캐싱 전략을 적극적으로 활용한다.

최초 진입: API를 호출하여 데이터를 받아오고, 이를 로컬 스토리지에 저장한다.
재진입:
- 즉시 렌더링: API 응답을 기다리지 않고, 저장해 둔 이전 내역을 먼저 화면에 뿌려준다.
- 백그라운드 갱신: 뒤단에서 동기 API를 호출하여 최신 데이터를 받아온다
- UI 업데이트: 데이터가 변경되었다면 자연스럽게 화면을 갱신한다.

이 방식을 통해 사용자는 앱을 켤 때마다 "로딩 없이 바로 뜬다"는 쾌적한 경험을 느끼게된다.

3. 자바스크립트 다이어트 (Bundle Diet)

이번 영상을 보며 개인적으로 가장 인상 깊었던, 그리고 미처 깊게 생각하지 못했던 부분이다.

바로 "평가 시간(Evaluation Time)"에 대한 이야기다.

우선 평가 시간이란?

브라우저는 ‘다운로드 → 파싱 → 컴파일 & 실행’ 과 같은 작업을 거치는데 이때 파싱과 컴파일 & 실행 이 평가 시간이다. '평가 시간'이 길어지면 화면은 보이지만 버튼을 눌러도 반응하지 않는(TTI: Time to Interactive가 늦어지는) 현상이 발생한다.

이러한 이유로 평가사간을 줄이기 위해 자바스크립트의 번들 사이즈를 줄여야된다.

다이어트 실천 가이드 (Webpack Bundle Analyzer)

Webpack Bundle Analyzer 같은 도구를 사용하면 프로젝트의 '비만도'를 시각적으로 확인할 수 있다.

분석 결과를 바탕으로 다음 3단계 다이어트를 진행할 수 있다.

1. 미사용 의존성 제거 (Remove Unused Dependencies)

개발을 진행하다 보면 package.json에는 남아있지만, 실제 코드에서는 더 이상 쓰지 않는 '유령 라이브러리'들이 쌓이게 된다. 이를 찾아내는 방법이다.

문제점:
- 프로젝트 초기에 테스트용으로 설치했다가 까먹고 지우지 않은 라이브러리.
- 기획 변경으로 기능이 삭제되었으나, 라이브러리 설치 내역은 남은 경우.
- 이들은 번들 사이즈를 키우고 빌드 시간을 늦추게된다.
해결 도구: depcheck
- 일일이 코드를 뒤지는 것은 불가능합니다. depcheck라는 CLI 도구를 사용하면 프로젝트를 스캔하여 쓰지 않는 의존성을 찾아준다.
- 설치 및 사용법:
```
npx depcheck
```
- 실행 결과: Unused dependencies 리스트를 보여준다.
주의할 점:
- ESLint, Prettier, Webpack 플러그인 등은 소스 코드 내에서 import 하지 않지만 설정 파일에서 쓰인다. 때문에, depcheck가 이를 '미사용'으로 오탐지할 수 있으니, 무작정 지우지 말고 개발 의존성(devDependencies) 인지 확인 후 삭제해야한다.

2. 경량화 (Lightweight Alternatives)

"기능은 같지만 몸집은 가벼운" 라이브러리를 선택하는 전략이다. 단순히 용량만 줄이는 게 아니라, 트리 쉐이킹(Tree-shaking) 지원 여부가 핵심입니다.

대표적인 예시 1: 날짜 라이브러리
- Before (Moment.js): 너무 무겁고, 객체 지향적이며, 내가 쓰지 않는 모든 언어팩(Locale)까지 번들에 포함시킨다.
- After (Day.js / date-fns): Moment.js와 문법이 거의 같으면서 용량은 약 30~100배 가볍습니다. 필요한 기능만 쏙쏙 뽑아 쓸 수 있다.
대표적인 예시 2: 유틸리티 라이브러리
- Before (Lodash): import _ from 'lodash' 형태로 통째로 불러오면 번들 사이즈가 급격히 커진다.
- After (Lodash-es): ES Module을 지원하는 lodash-es를 사용하여 필요한 함수만 import { debounce } from 'lodash-es' 형태로 가져오면, 사용하지 않는 나머지 함수들은 번들에서 제외(Tree-shaking)된다.
꿀팁 도구: Bundlephobia
- Bundlephobia.com에 라이브러리 이름을 검색하면 용량을 알려주고, 대체 가능한 가벼운 라이브러리(Similar packages)를 추천해 준다.

3. 중복 제거 (Deduplication)

이 부분은 많은 개발자가 놓치는 '숨겨진 살' 같은 존재다. 내가 설치한 라이브러리가 또 다른 라이브러리를 의존하면 발생한다.

발생 원인 (의존성 지옥):

- 프로젝트가 A 라이브러리와 B 라이브러리를 사용한다.
- A는 library-x의 1.0 버전을 사용
- B는 library-x의 2.0 버전을 사용
- 결과적으로 내 번들에는 library-x가 두 개(1.0, 2.0) 가 들어가게 되는 문제가 생성된다.
확인 방법:
- 터미널에 npm ls <라이브러리명>을 입력하면 중복 설치 여부를 알 수 있다.
- 또는 Webpack Bundle Analyzer를 돌렸을 때 같은 이름의 덩어리가 여러 개 보이면 100% 중복이다.
해결 방법:
1. npm dedupe (혹은 yarn dedupe): 패키지 매니저가 자동으로 버전을 호환 가능한 범위 내에서 하나로 합치려고 시도한다.
2. 강제 통일 (Resolution/Overrides): package.json에 resolutions (yarn) 또는 overrides (npm) 필드를 추가하여 특정 버전을 강제로 쓰도록 명시합니다.JSON
```
// package.json 예시
"overrides": {
  "library-x": "2.0.0"
}
```

4. API Waterfall 개선

요청 응답 → 요청 응답 → 요청 응답 → api water fall 개선을 통해 빠르게 처리하는 형식으로 변경한다.

Waterfall (나쁜 예):
- User 정보 요청 (1초 소요) → 응답 도착 → 게시글 목록 요청 (1초 소요) → 응답 도착
- 총 소요 시간: 2초
Parallel (좋은 예):
- User 정보 요청 (1초) & 게시글 목록 요청 (1초) → 동시에 시작!
- 총 소요 시간: 1초 (가장 느린 요청 기준)

API Waterfall의 발생원인

① 무의식적인 await의 연속 사용

가장 흔한 실수다. 서로 상관없는 데이터인데 습관적으로 코드를 순서대로 짜는 경우

// ❌ Bad: Waterfall 발생
async function loadData() {
  const userData = await fetchUser();       // 이거 끝날 때까지 기다림
  const bannerData = await fetchBanner();   // 윗줄 끝나야 시작함
  return { userData, bannerData };
}

② 컴포넌트 구조상의 문제 (Fetch-on-Render)

부모 컴포넌트가 다 그려지고(데이터 로딩 완료) 나서야 자식 컴포넌트가 렌더링되는데, 자식 컴포넌트 안에도 API 요청이 있는 경우다.

[부모] 사용자 프로필 로딩 중... (완료!)
- 렌더링 → [자식] 친구 목록 컴포넌트 등장!
  - [자식] 이제 친구 목록 로딩 시작... (또 기다림)

3. 해결 방법 (개선 전략)

① Promise.all로 병렬 처리 (Parallelization)

서로 의존성(인과관계)이 없는 데이터라면 동시에 출발시킨다.

// ✅ Good: 병렬 처리
async function loadData() {
  // 두 요청을 동시에 보냄
  const [userData, bannerData] = await Promise.all([
    fetchUser(),
    fetchBanner()
  ]);
  return { userData, bannerData };
}

② 데이터 프리페칭 (Prefetching) / 라우트 레벨 데이터 로딩

컴포넌트가 마운트될 때 요청하는 것이 아니라, 페이지에 진입하는 순간(라우팅 시점)이나 마우스가 버튼에 올라갔을 때 미리 데이터를 요청한다. Next.js의 getServerSideProps나 React Query의 prefetchQuery가 이런 역할을 도와준다.

객체 탐지 모델 YOLO 와 R-CNN

WHITE_FROST — Wed, 21 Jan 2026 20:48:28 +0900

현재 프로젝트를 진행하며 사진 속 요소들의 종류를 파악해야 하는 문제에 직면했다. 이를 해결하기 위해 AI 기술 중 하나인 객체 탐지 모델을 도입하기로 결정하였으며, 학습한 내용과 개인적인 견해를 정리한다.

우선 컴퓨터비전에서의 문제들은 크게 다음과 같이 분류할 수 있다.

Classification (분류)
Object Detection (객체 탐지):
Image Segmentation (이미지 분할)

이중 현재 글에 다룰것은 Object Detection 이다.

1. 객체 탐지 모델이란?

객체 탐지 모델은 사진이나 영상 속에서 물체의 종류를 식별하는 기술이다. 이 모델의 가장 큰 특징은 단순히 객체의 존재 여부를 판단하는 것을 넘어, 해당 요소가 어느 좌표에 있는지 사각형 박스로 표시한다는 점이다. 위치 정보를 정확히 파악하는 것이 중요한 프로젝트에서 핵심적인 역할을 수행한다.

객체 탐지의 대표적인 두가지와 방법이 있는데 대표적인 모델 두가지를 소개해보겠다.

2. YOLO (You Only Look Once)

YOLO는 이름 그대로 이미지를 보고 바로 물체를 찾아내는 방식이다. 기술적으로는 1-Stage Detector로 분류된다.

YOLO의 동작 방식

이미지 분할: 입력 이미지를 $S \times S$ 크기의 균일한 그리드로 나눈다.
Bounding Box 예측: 각 그리드 셀에서 $B$개의 박스를 예측한다. 일반적으로 셀당 2개씩 예측하여 총 $2S^2$개의 박스 후보를 도출한다.
신뢰도 점수 계산:
- $Confidence = Pr(Object) \times IOU(pred, truth)$
- 박스 내 객체 존재 확률($Pr$)과 실제 박스와의 겹침 정도($IOU$)를 곱해 점수를 산출한다.
클래스 확률 계산: 각 셀에서 검출된 물체가 어떤 클래스에 속하는지 확률을 구한다.
최종 검출: 신뢰도 점수가 높은 박스들만 남기고 나머지는 제거하여 최종 위치를 결정한다.

한 번의 연산으로 모든 과정을 처리하기 때문에 속도가 매우 빠르며 실시간 영상 분석에 최적화되어 있다.

3. R-CNN (Region-based CNN)

R-CNN은 YOLO와 달리 객체가 있을 법한 영역을 먼저 찾고 분류하는 2-Stage Detector 방식이다.

R-CNN의 동작 방식

영역 제안: 이미지 내에서 객체가 있을 법한 후보 영역을 약 2,000개 정도 추출한다. (주로 Selective Search 알고리즘 사용)
특징 추출: 추출된 각 후보 영역을 동일한 크기로 조절한 후, CNN 모델에 통과시켜 특징 벡터를 추출한다.
분류: 추출된 특징을 바탕으로 SVM(Support Vector Machine)을 통해 해당 영역이 어떤 물체인지 분류한다.
경계 상자 조정: 예측된 박스의 위치를 실제 물체 위치에 더 가깝도록 정밀하게 조정한다.

이 방식은 단계별로 연산이 이루어지므로 YOLO보다 속도는 느리지만, 더 높은 정확도를 기대할 수 있다.

4. YOLO vs R-CNN: 비교와 선택

두 모델은 성능과 목적에 따라 확연한 차이를 보인다.

비교 항목 YOLO (1-Stage) R-CNN 계열 (2-Stage)

속도	매우 빠름 (실시간 가능)	비교적 느림
정확도	상대적으로 낮음 (특히 작은 객체)	매우 높음 (정밀한 검출)
학습 난이도	상대적으로 낮음	복잡하고 연산 자원 많이 소모

언제 어떤 모델을 사용해야 하는가?

YOLO 선택 시점: 자율주행, 실시간 CCTV 보안 관제, 모바일 기기 구동 등 실시간 응답성이 최우선일 때 사용한다.
R-CNN 선택 시점: 의료 영상 분석(X-ray, MRI), 정밀한 불량품 검수 등 속도보다는 오탐 없는 정확도가 절대적으로 중요할 때 사용한다.

5. 개발 시 비용에 대한 고찰

현재 멀티모달 LLM이 등장하여 해상 사진 분석이나 OCR 결과를 매우 쉽게 얻을 수 있다. 그럼에도 불구하고 전용 모델 개발자가 개발 해야된다면 이유는 다음과 같을것 같다.

첫째, 압도적인 운영 비용,

즉 토큰을 엄청 소모한다. LLM API는 호출당 비용이 발생한다. 하루 수만 건 이상의 데이터를 처리하는 서비스라면 API 비용만으로 막대한 지출이 발생한다. 반면, 직접 구축한 YOLO 모델은 초기 학습 후 자체 서버에서 운영하므로 데이터 처리량이 늘어날수록 단가가 급격히 낮아진다.

둘째, 지연 시간과 데이터 보안 문제

API 방식은 외부 서버를 거쳐야 하므로 통신 속도의 영향을 받으며, 민감한 내부 데이터를 외부 서버로 전송해야 한다는 리스크가 있다. 직접 모델을 구축하면 로컬에서 즉각 처리가 가능하며 보안성 또한 완벽하게 확보할 수 있다.

끝으로

이러한 이유로 어떤 서비스할 때 확실히 문제에 따라 올바른 AI 솔루션을 내는것이 중요하다고 생각한다.프로젝트의 규모와 목적에 맞춰 이 둘을 전략적으로 선택하는 능력이 현대 AI 개발자의 진정한 경쟁력이라 판단한다.

참고

https://ganghee-lee.tistory.com/35

https://dotiromoook.tistory.com/24

https://www.ultralytics.com/ko/blog/what-is-r-cnn-a-quick-overview

이벤트 루프

WHITE_FROST — Wed, 14 Jan 2026 20:40:49 +0900

"이벤트 루프가 뭐예요?" 누군가 나에게 이렇게 묻다면 나는 자신 있게 답을 할 수 있을까? 솔직히 현재의 나는 명쾌하게 대답할 자신이 없다. 그래서 이 글은 미래의 나를 위해, 그리고 이 질문에 답하기 위해 작성하는 정리 노트다.

1. 자바스크립트는 싱글 스레드인데 어떻게 멀티태스킹을 할까?

이벤트 루프를 논하기 전에 먼저 해결해야 할 의문이 있다. "자바스크립트는 싱글 스레드(Single Thread) 언어다." 이 말은 한 번에 하나의 작업만 할 수 있다는 뜻인데, 실제 우리가 쓰는 웹 사이트는 파일도 다운로드하고, 애니메이션도 보여주고, 서버 요청도 동시에 처리하는 것처럼 보인다. 이게 어떻게 가능한 걸까?

. 자바스크립트 엔진은 '요청'만 보내고, 실제로 시간이 오래 걸리는 작업(네트워크, 타이머 등)은 브라우저가 제공하는 Web APIs 영역에서 수행된다.

즉, 비동기 + 논블로킹(Async + Non-blocking) 방식이다.

비동기 + 논블로킹이란? 메인 스레드가 작업을 직접 붙들고 있는 게 아니라, 다른 곳(Web APIs)에 "이거 해줘"라고 위임하고 바로 다음 일을 처리하는 방식이다. 위임된 작업이 끝나면 결과만 나중에(Callback) 받아 처리한다.

이 과정에서 동작의 타이밍을 제어하고 조율하는 관리자가 바로 이벤트 루프(Event Loop)다.

2. 이벤트 루프(Event Loop)의 정의

이벤트 루프는 브라우저 내부에서 두 가지를 끊임없이 확인하고 중재하는 역할을 한다.

호출 스택(Call Stack)에 현재 실행 중인 코드가 있는가?
태스크 큐(Task Queue)에 대기 중인 작업이 있는가?

호출 스택이 텅 비어있다면, 태스크 큐에 대기 중인 작업을 꺼내와 실행시킨다. 이 단순한 반복 작업이 자바스크립트 비동기의 핵심이다.

3. 주요 구성 요소 뜯어보기

이벤트 루프를 이해하기 위해선 다음 세 가지 친구들을 알아야 한다.

① 호출 스택 (Call Stack)

호출 스택은 자바스크립트 엔진이 코드를 실행하는 공간이다.

LIFO (Last In, First Out): 나중에 들어온 녀석이 먼저 나가는 '스택' 구조다.
함수가 실행되면 스택에 쌓이고(Push), 실행이 끝나면 스택에서 제거된다(Pop).

핵심: 자바스크립트는 싱글 스레드이므로 호출 스택이 딱 하나다. 한 번에 하나의 함수만 실행할 수 있다는 뜻이다. 만약 여기서 무거운 작업을 돌리면 브라우저는 멈춰버린다(Blocking).

② Web APIs:

브라우저가 제공하는 멀티 스레드 공간이다.

setTimeout, fetch, DOM Event 등이 여기서 처리된다.
자바스크립트 엔진이 복잡하고 어려운 작업을 Web APIs에 요청하여 백그라운드에서 열심히 일을 처리한다. 일이 끝나면 결과물(콜백 함수)을 태스크 큐로 넘겨준다.

③ 태스크 큐 (Task Queue)

Web APIs에서 처리가 끝난 콜백 함수들이 실행되기 위해 기다리는 대기실이다.

FIFO (First In, First Out): 먼저 들어온 녀석이 먼저 나간다.
이벤트 루프는 호출 스택이 비었을 때만 여기서 콜백을 꺼내간다.

4. 심화: 마이크로 태스크 vs 매크로 태스크

마이크로 태스크 큐 (Micro Task Queue)

대상: Promise (.then/catch/finally), async/await, MutationObserver 등
특징: 우선순위가 가장 높다.
호출 스택이 비면, 이벤트 루프는 매크로 태스크보다 마이크로 태스크 큐를 먼저 확인한다.
주의: 마이크로 태스크 큐에 있는 작업은 큐가 완전히 빌 때까지 계속해서 실행된다. 만약 마이크로 태스크가 계속 추가되면(무한 루프 등), 매크로 태스크는 실행 기회를 못 얻고 화면 갱신(렌더링)도 차단되어 브라우저가 먹통이 될 수 있다.

매크로 태스크 큐 (Macro Task Queue)

대상: setTimeout, setInterval, fetch, DOM 이벤트 등 일반적인 비동기 작업
특징: 마이크로 태스크 큐가 텅 비어야 실행된다.
일반적으로 매크로 태스크 하나를 실행한 후에는 브라우저가 화면을 다시 그릴(Render) 기회를 가질 수 있다.

5. 결론

이벤트 루프는 호출 스택이 비어 있는지를 지속적으로 확인하고,비어 있을 경우 태스크 큐에 대기 중인 작업을 호출 스택으로 옮겨 실행을 관리하는 메커니즘이다.

출처 및 참고 자료

https://inpa.tistory.com/entry/ -자바스크립트-이벤트-루프-구조-동작-원리

https://www.youtube.com/watch?v=8aGhZQkoFbQ