시리즈 마지막 편입니다. 이번에는 코드 이야기가 아니라 프로젝트를 만들면서 느낀 점, 그리고 실제 프로덕션 트레이딩 플랫폼을 만든다면 어떤 점들을 더 고려해야 하는지 정리해봤습니다.전체 소스코드는 GitHub에 공개되어 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev1. 왜 이 프로젝트를 만들었는가평소에 궁금했던 게 있었습니다. 주식이든 코인이든, 트레이딩 화면을 보면 숫자가 쉴 새 없이 바뀝니다. 호가창, 체결 내역, 캔들 차트가 동시에 움직입니다. 이걸 프론트엔드에서 어떻게 처리하는 걸까?React로 일반적인 CRUD 앱을 만..

업비트 실시간 대시보드 시리즈 마지막 편입니다. 호가창(Order Book)을 3가지 방식으로 구현하고 실제 성능을 비교해봤습니다.전체 소스코드는 GitHub에 공개되어 있습니다. /benchmark 페이지에서 3가지 방식의 성능 차이를 직접 확인할 수 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev# http://localhost:3000/benchmark 접속1. 왜 호가창이 어려운가?호가창은 프론트엔드에서 구현 난이도가 가장 높은 컴포넌트 중 하나입니다. 이유는 단순합니다.업비트 WebSocket으로 초당 10~20회 호가 ..

업비트 실시간 대시보드 시리즈 2편입니다. 이전 글에서 WebSocket 파이프라인을 구축했고, 이번에는 그 위에 캔들 차트를 올립니다. REST API로 과거 200개 캔들을 불러오고, WebSocket 체결 데이터로 마지막 캔들을 실시간 업데이트하는 구조입니다.전체 소스코드는 GitHub에 공개되어 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev1. 왜 TradingView Lightweight Charts인가?금융 차트 라이브러리를 고를 때 D3.js, Recharts, ECharts 등을 검토했습니다. 결론은 Lightwe..

업비트 Public WebSocket API를 사용해서 실시간 암호화폐 트레이딩 대시보드를 만들어본 기록입니다. 이번 1편에서는 WebSocket 연결부터 React 훅으로 래핑하는 과정까지 다룹니다.전체 소스코드는 GitHub에 공개되어 있습니다. 직접 클론해서 돌려보실 수 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev1. 왜 WebSocket인가?실시간 암호화폐 데이터를 프론트엔드에서 보여주려면 선택지가 몇 가지 있습니다. Polling, SSE(Server-Sent Events), WebSocket.호가창은 초당 10~20..

Claude Code의 실험 기능인 Agent Teams를 Next.js 프로젝트에서 직접 돌려본 후기입니다. 팀 리드가 태스크를 분배하고, 3명의 팀메이트가 병렬로 코드를 작성하는 과정을 확인했습니다.1. 왜 해봤나?Claude Code는 원래 "하나의 AI가 하나의 세션에서 일하는" 구조입니다. 하지만 실제 개발은 그렇지 않습니다. 프론트 따로, 백엔드 따로, 테스트 따로 — 사람이 팀으로 일하듯이 AI도 팀으로 일하면 어떨까요?Anthropic이 Opus 4.6 출시와 함께 Agent Teams라는 실험 기능을 내놓았습니다. 여러 Claude Code 세션이 팀처럼 협업하는 기능입니다. 한 세션이 리드가 되고, 나머지가 팀메이트로 각자 독립된 컨텍스트에서 작업하면서 서로 메시지를 주고받습니다.기존 ..

Nginx vs AWS API Gateway vs GCP API Gateway — 우리 팀이 Nginx를 선택한 이유최근 물류 센터 자동화 프로젝트를 진행하면서, AI 추론(Inference) 서버와 일반 백엔드(Data Ops/Orchestrator) 서버를 물리적으로 분리하는 작업을 진행했습니다. GPU가 필요한 무거운 작업과 일반적인 CPU 작업을 나누어 자원 효율을 극대화하기 위함입니다.하지만 이렇게 서버를 분리하고 나니 진입점(Entry Point) 문제가 발생했습니다.1. 직면한 문제: 클라이언트가 너무 많은 주소를 알아야 한다서버를 기능별로 분리하니 네트워크 구성이 아래와 같이 되었습니다.서버역할주소GPU 서버Inference192.168.1.101:8001CPU 서버Data Ops192.1..

"이거... 폴더 이름 실수로 두 번 쓴 거 아닌가?"들어가며사내 물류 자동화 시스템을 Turborepo 모노레포로 구축하던 중이었다.packages/└── common/ ├── pyproject.toml └── common/ ← 이게 뭐야? ├── __init__.py └── utils.py처음 보는 사람은 십중팔구 "폴더명 중복 아니냐"고 묻는다. 나도 그랬다."Hatchling 설정을 잘못 건드린 건가?""common 하나만 있으면 되는 거 아닌가?"결론부터 말하면, 이건 실수가 아니다. Python 패키징의 정석 중 하나인 Flat Layout이다.하지만 팩트 체크를 하다가 충격적인 사실을 알았다. requests, 그 유명한 requests도 ..

Image Source: Generated by Nano Banana"AI 정확도가 100%가 아니면 현업에서 못 쓰는 거 아니에요?"라는 질문을 받았다. 답은 "아니다"였다.들어가며의류 반품 검수 현장은 생각보다 복잡하다.하루 반품량: 5,000벌검수 항목: 오염, 찢어짐, 변색, 보풀, 단추 이탈 등 12가지작업자 1명당 처리량: 200벌/일소요 시간: 1벌당 평균 2분문제는 검수 품질이다. 사람이 하루 종일 옷을 보면 집중력이 떨어진다. 저녁 6시쯤 되면 오탐률이 30%까지 치솟는다."AI로 자동화하면 되지 않나요?"시도해봤다. YOLOv8 기반 불량 검출 모델을 만들어서 파일럿 테스트를 돌렸다.결과:- mAP50: 0.83 (83%)- Precision: 0.79- Recall: 0.8583%면 ..

"로컬에서 잘 돌던 코드가 GPU 서버에 올리니 터진다"는 경험, 한 번쯤 있지 않은가?들어가며PyTorch로 딥러닝 모델을 개발하다 보면, 모델 아키텍처 자체보다 '학습 환경 설정(Boilerplate Code)' 때문에 스트레스를 받는 순간이 반드시 온다."로컬(CPU)에서 짤 때는 잘 돌아갔는데, 서버(GPU)에 올리니 에러가 나네?""단일 GPU 코드를 멀티 GPU(DDP)로 바꾸려니 코드를 다 뜯어고쳐야 하네?"이런 하드웨어 의존적인 코드를 획기적으로 줄여주는 Hugging Face Accelerate 라이브러리를 소개한다. 기존 PyTorch 코드와 비교하여 얼마나 생산성이 높아지는지 살펴보자.The "Before": 순수 PyTorch의 고통PyTorch만 사용하여 멀티 GPU 환경과 Mix..

Lint에 PyTorch를 설치하고 있었다.발단PR 올릴 때마다 CI가 5분씩 걸렸다. 코드 한 줄 고쳐서 올렸는데 초록불 보려면 5분. 커피 타 오기엔 애매하고, 가만히 기다리기엔 긴 시간이다."원래 CI가 이렇게 오래 걸리나?"아니었다. 뜯어보니 Lint job에서 PyTorch, transformers, ultralytics를 설치하고 있었다. ruff 돌리려고.문제의 워크플로우# Before: ci.ymljobs: lint: name: Lint & Type Check steps: - name: Install Poetry uses: snok/install-poetry@v1 - name: Install dependencies run: poetry..