Dwon'story

Planet Palette - 우주가 넓어지다: 성간공간

Dwony — Sun, 21 Jun 2026 18:48:35 +0900

나의 인생으로 우주를 만들어보면 어떨까요? 사진을 업로드만 하면 사진의 색감이 살아있는 행성이 됩니다.

https://planetpalette.vercel.app/ 바로 써보기!

플래닛팔레트 — 여행 사진이 나만의 태양계가 되다

당신이 다녀온 그곳이 행성이 된다면? 사진을 올리면 색감을 분석해 나만의 우주를 만들어드립니다. 무료, 즉시 사용.

planetpalette.vercel.app

1편 보고오기 2026.05.27 - [Project/Planet Palette] - Planet Palette - 나만의 태양계

태양계 하나로는 부족했다. 여행이 쌓이면 우주가 되어야 한다고 생각했다.

이번 업데이트에서 뭘 만들었나

사실 처음에는 작은 업데이트가 될 거라고 생각했다. 가이드 단계 하나 추가하고, 버튼 몇 개 위치 조정하고. 그런데 작업을 시작하고 나니 자연스럽게 연결된 것들이 많았다. 결국 꽤 큰 업데이트가 됐다.

성간공간뷰

크게 세 가지다.

성간공간 뷰(InterstellarView) 전면 재설계 — 12개 태양계, 단일·이중·성단 구조
UUID 기반 공유 시스템 + 내 기록 페이지 — Supabase 백엔드, 링크 공유, 소유권 검증
아이디어풀 — 유저 피드백을 직접 받는 창구
자잘하지만 중요한 UX 개선들 — 몰입 모드, 가이드 개선, 언어 선택

각각 왜 만들었고, 어떻게 만들었는지 순서대로 적어본다.

1. 성간공간 뷰 — 여행이 쌓이면 우주가 된다

문제

Planet Palette의 핵심 아이디어는 "여행이 하나의 태양계가 된다"는 거다. 그런데 태양계가 두 개, 세 개가 되면? 그냥 목록으로 보여주는 건 너무 평범하다고 느꼈다.

이전에 sc2(줌아웃 뷰)를 처음 만들 때는 태양계를 단순하게 배치하는 수준이었다. 이번에 제대로 다시 설계했다.

설계 원칙

실제 우주처럼 보이게 하되, 복잡하지 않게. 천체역학 교과서가 아니라 여행 기록 앱이니까.

세 가지 구조를 정했다:

단일항성계 — 현재 보고 있는 내 태양계. 움직이지 않는다. 화면 한쪽에 홀로 있다.
이중항성계 — 2개의 태양계가 공통질량중심(바리센터)을 기준으로 서로를 돌고 있다.
삼중항성계 — 3개씩 묶인 그룹 3개. 각 그룹이 서로 다른 속도와 방향으로 공전한다.

최대 12개 태양계를 이 구조에 순서대로 배분한다. ordered[0]은 항상 단일항성계(현재 시스템), [1..2]는 이중, [3..5], [6..8], [9..11]은 각각 삼중.

구현: CSS만으로 궤도 애니메이션

별도의 애니메이션 라이브러리 없이 CSS 키프레임으로 해결했다.

@keyframes pp-orbit-spin {
  from { transform: rotate(0deg); }
  to   { transform: rotate(360deg); }
}
@keyframes pp-orbit-spin-rev {
  from { transform: rotate(0deg); }
  to   { transform: rotate(-360deg); }
}

핵심은 래퍼 + 역회전 패턴이다. 래퍼 div가 공전하고, 실제 태양계(자식)가 반대 방향으로 같은 속도로 회전한다. 결과적으로 태양계는 항상 같은 방향을 바라보면서 궤도를 돈다. 라벨이 뒤집히지 않는 이유가 이것이다.

중간 성단은 역방향(pp-orbit-spin-rev)으로 돌도록 했다. 실제 우주에서 역행 궤도가 존재하는 것처럼. 보는 사람들이 금방 알아채기도 하고, 화면이 훨씬 생동감 있어진다.

모바일 vs 데스크톱 위치

768px를 기준으로 위치 계수(fx, fy)를 완전히 다르게 설정했다. 모바일은 세로로 긴 화면에서 겹치지 않도록, 데스크톱은 가로로 넉넉한 공간을 활용하도록.

const SINGLE_POS = {
  m: { fx: 0.74, fy: 0.38 },  // 모바일
  w: { fx: 0.82, fy: 0.18 }   // 데스크톱
};

이 숫자들은 코드가 아니라 눈으로 조정한 것들이다. "조금 위로", "오른쪽 더" 반복하면서 맞춰나갔다.

2. UUID 공유 시스템 + 내 기록 페이지

태양계마다 고유 주소를

Planet Palette의 핵심 가치 중 하나는 "내 여행을 누군가에게 보여줄 수 있다"는 거다. 그러려면 태양계마다 고유한 URL이 있어야 했다.

각 태양계에 short_id(UUID 앞 8자리)를 부여하고, /solar/[shortId] 라우트로 접근할 수 있게 했다. 링크 하나만 공유하면 누구나 그 태양계를 볼 수 있다.

// short_id 생성 — UUID 앞 8자리
const short_id = crypto.randomUUID().slice(0, 8);

소유권 검증: 로그인 vs 익명

까다로운 부분은 소유권 판단이었다. 로그인 유저는 user_id로 확인하면 되지만, 로그인 없이 만든 태양계는 어떻게 내 것임을 증명하나?

익명 유저에게는 태양계 생성 시 anon_token을 발급하고, 해시(sha-256)해서 DB에 저장한다. 원본 토큰은 localStorage에만 남긴다.

// 소유권 확인 로직
if (system.user_id) {
  // 로그인 유저: auth.getUser()와 대조
  setIsOwner(user.id === system.user_id);
} else if (system.anon_token_hash) {
  // 익명 유저: localStorage 토큰을 해시해서 대조
  const stored = localStorage.getItem(`pp_token_${system.short_id}`);
  const valid = await verifyToken(stored, system.anon_token_hash);
  setIsOwner(valid);
}

소유자만 편집·삭제할 수 있고(좌), 공유받은 사람은 보기만(우) 가능하다. 서버 세션 없이 브라우저 토큰만으로 이걸 처리했다는 게 나름 깔끔하다고 생각한다.

공유된 화면 - 읽기 전용

내 기록 페이지 (/my)

로그인 유저에게는 자신이 만든 모든 태양계를 한눈에 볼 수 있는 /my 페이지를 제공한다.

카드 썸네일은 실제 MiniStarSystem 컴포넌트를 그대로 렌더링한다. 정적 이미지가 아니라 살아있는 미니어처 태양계다. 카드 높이를 ResizeObserver로 측정해 size prop으로 내려준다.

삭제는 조심스럽게 설계했다. 카드에 hover했을 때만 삭제 버튼이 나타나고, 클릭하면 "삭제 / 취소" 확인 UI가 인라인으로 뜬다. 별도 모달 없이. 확인 후엔 Supabase Storage 파일을 먼저 지우고, DB는 CASCADE로 행성까지 한 번에 삭제된다.

내 기록 - 미니태양계 카드 보기

3. 아이디어풀 — 유저의 목소리를 듣고 싶었다

왜 만들었나

1인 개발이라 외부 피드백이 거의 없다. SNS에 올려도 댓글이 많지 않고, 주변 사람들한테 물어봐도 "좋은데?" 정도다. 실제로 서비스를 쓰면서 생긴 아이디어를 바로 전달할 수 있는 창구가 없었다.

별도 페이지보다 서비스 안에 녹여두는 게 낫겠다고 판단했다. 쓰다가 "이런 기능 있으면 좋겠다"는 생각이 들 때, 바로 그 자리에서 남길 수 있게.

진입 경로

진입점을 여러 곳에 뒀다:

NavBar — 데스크톱에서 항상 보임, 모바일에서 아이콘만 표시
태양계 뷰(sc1) 모바일 좌상단 — 공유 버튼 옆
성간공간 뷰(sc2) 모바일 좌상단
루트 페이지 하단 — 업로드 화면 맨 아래, 눈에 잘 안 띄는 위치에 조용하게
/my 페이지 NavBar

처음엔 그냥 각자 다 넣었다. 그러다 보니 70줄짜리 SVG path가 5군데에 복붙되어 있었다. 버튼 스타일을 바꾸려면 5군데를 고쳐야 한다는 뜻이다. 같은 버튼이 여러군데에 들어가니 자연스럽게 컴포넌트로 분리했다.

RLS는 anon, authenticated 둘 다 INSERT 허용. 로그인 없이도 아이디어를 낼 수 있어야 한다. 조회는 authenticated만 — 내가 Supabase 대시보드에서 직접 보면 된다.

4. 자잘하지만 중요한 것들

몰입 모드

태양계를 그냥 바라보고 싶을 때가 있다. 버튼도, 라벨도, 네비바도 없이.

화면 배경을 탭하면 모든 UI가 사라지고 태양계만 남는다. chromeHidden state 하나로 NavBar, 버튼들, 공유 아이콘 모두에 opacity-0 pointer-events-none을 건다. 다시 탭하면 복원된다.

구현은 단순하지만 경험 차이는 크다. 특히 모바일에서 전체 화면을 가득 채운 채 행성들이 돌아가는 모습은 처음 봤을 때 "아, 이거다" 싶었다.

가이드 6번 추가

기존 가이드는 줌인(태양계 뷰)까지만 안내하고 끝났다. 줌아웃해서 성간공간을 볼 수 있다는 걸 유저가 모를 수 있다.

마지막 단계에 - 버튼을 포커싱하고, "로그인해서 태양계를 더 추가하면 성간공간을 탐험할 수 있어요"라는 메시지를 추가했다. 기능 안내이자 로그인 유도이기도 하다.

가이드 리플레이 버튼(?)은 이제 모든 방문자에게 보인다. 이전엔 소유자에게만 표시했는데, 공유 링크로 처음 온 사람도 가이드를 다시 볼 수 있어야 한다고 판단했다.

남은 과제들

이번 업데이트를 하면서 자연스럽게 눈에 들어온 것들이 있다.

성간공간 뷰에서 태양계 수가 4개 미만일 때의 레이아웃 (지금은 성단 슬롯이 비어 있다)
아이디어 제출 내역을 관리자가 볼 수 있는 간단한 내부 대시보드
공유된 태양계를 보는 사람이 "나도 만들고 싶다"는 동선을 더 명확하게

특히 세 번째가 중요하다고 생각한다. 공유 링크로 유입된 사람이 그냥 보고 나가는 건 아깝다. 자연스럽게 "나도 해볼게"가 되는 흐름이 필요하다.

마치며

혼자 만드는 서비스의 장점은 "이걸 왜 만드나"를 매번 내가 결정할 수 있다는 거다. 기술적으로 멋진 게 아니라, 쓰고 싶은 걸 만드는 것. 이번 업데이트의 기준도 결국 그거였다.

성간공간 화면을 처음 완성하고 내 여행들이 각자의 궤도로 돌고 있는 걸 봤을 때, "아, 이 느낌이었구나" 싶었다. 태양계 하나는 여행이지만, 여러 개가 모이면 진짜로 우주처럼 보였다.

그걸 만드는 데 한참 걸렸지만, 그래도 괜찮다.

https://planetpalette.vercel.app/

Planet Palette - 나만의 태양계

Dwony — Wed, 27 May 2026 14:17:39 +0900

나의 인생으로 우주를 만들어보면 어떨까요? 사진을 업로드만 하면 사진의 색감이 살아있는 행성이 됩니다.

https://planetpalette.vercel.app/ 바로 써보기!

Planetpalette — Turn Your Travel Photos into a Solar System

Each photo you upload becomes a unique, color-extracted planet orbiting your very own star. Free, instant, no signup.

planetpalette.vercel.app

컨셉

여행을 다녀오거나 친구들을 만나고 나면 무수히 많은 사진이 남겨집니다. 따로 추억하는 시간을 갖지 않는 이상 휴대폰 사진첩에만 존재하는 비트맵 이미지가 됩니다. 모두에게는 각자의 우주가 있고 내가 경험한 것들 즐거웠던 순간들로 나만의 우주를 만들어보면 어떨까요?

Planet Palette는 그 욕구에서 출발했습니다.

여행 사진을 드래그앤드롭으로 올리면, 사진 속 색감을 추출해 행성 SVG 아트워크로 변환합니다. 각 행성은 그 사진만의 고유한 컬러 팔레트로 만들어진 동심원 구조를 가지며, 모든 행성이 모이면 하나의 태양계를 이룹니다. 여행이 끝나면 당신만의 우주가 생깁니다.

일단은 MVP이므로 서버가 없습니다. 사진이 어디로도 전송되지 않습니다. 모든 처리가 브라우저 안에서 끝납니다.

주요 기능

1. 사진 → 행성 변환

사진을 업로드하면 color-thief-browser 라이브러리가 대표색 1개와 팔레트 5색을 추출합니다. 총 6가지 색을 HSL 명도(L) 기준 내림차순으로 정렬한 뒤, 각각 행성의 동심원 링에 배치합니다.

가장 밝은 색 → 행성 핵(core)
가장 어두운 색 → 행성 외곽

행성 표면의 크레이터(반점)는 mulberry32 시드 기반 의사난수로 생성합니다. 시드는 파일명 길이 × 파일 크기 + lastModified 값으로 계산되어, 같은 사진을 올리면 항상 같은 행성이 만들어집니다.

행성 외곽에는 Atmosphere Glow(대기 후광)를 radialGradient로 구현했고, 점선 궤도 링과 2~3개의 위성도 달립니다.

2. 실시간 태양계 애니메이션

업로드한 행성들이 중앙 별 주위를 공전합니다. requestAnimationFrame 기반의 애니메이션 루프가 매 프레임마다 행성의 공전 각도와 자전 각도를 계산해 DOM에 직접 적용합니다.

공전 속도와 자전 속도 모두 각 사진의 시드로 결정되어, 사진마다 다른 리듬으로 움직입니다. 배경에는 200개의 별이 흩뿌려져 있으며 이 역시 시드 기반으로 고정 생성됩니다.

행성에 마우스를 올리면 공전이 멈추고 미리보기 카드가 뜹니다. 클릭하면 상세 모달이 열립니다.

Planet Palette - Planet View

3. 행성 상세 모달

행성을 클릭하면 사이드 오버레이가 열립니다.

원본 사진 + 행성 SVG 나란히 표시
추출된 6색 팔레트 스와치
행성 이름 인라인 편집 (클릭해서 바로 수정)
삭제 버튼
키보드 방향키(←/→)로 행성 간 이동
모바일에서 스와이프로 이동

Planet Palette - Planet Modal

4. 여행 정보 등록

중앙 별을 클릭하면 Trip Info 모달이 열립니다. 여행 이름과 날짜를 입력하면 PNG/MP4 내보내기 시 함께 포함됩니다.

Planet Palette - Trip Info

5. 내보내기 — PNG 이미지 & MP4 배경화면

다운로드 버튼을 누르면 두 가지 옵션이 제공됩니다.

PNG 이미지: html-to-image 라이브러리로 현재 태양계 뷰를 고해상도로 캡처합니다.

MP4 배경화면: Canvas API로 매 프레임 직접 렌더링하여 15초 분량의 영상을 생성합니다.

모바일: 1080×1920 (세로 FHD), 데스크톱: 1440×2560 (세로 QHD)
MediaRecorder API로 WebM 인코딩 후 MP4 컨테이너로 저장
진행률(%)을 실시간으로 표시

부가 기능

다크/라이트 모드

시스템 설정을 기본값으로 따르되, 수동으로 전환하면 localStorage에 저장됩니다. Tailwind CSS의 dark: 유틸리티로 구현했습니다.

500

8개 언어 지원

한국어, 영어, 일본어, 중국어, 스페인어, 프랑스어, 이탈리아어, 독일어를 지원합니다. i18next + react-i18next로 구현했으며, 선택한 언어는 localStorage에 저장됩니다.

인터랙티브 가이드 투어

첫 방문 시 driver.js로 구현한 단계별 가이드가 자동으로 실행됩니다. 행성 모달 열기/닫기 같은 UI 상태 변화를 가이드 흐름에 맞춰 제어하는 로직이 포함됩니다. 한 번 본 사용자에게는 다시 표시되지 않습니다.

파일 검증

허용 형식: JPEG, PNG, WebP
최대 10장, 파일당 최대 20MB
파일명+크기 기준 중복 감지
이탈 시 beforeunload 경고

기술 스택

영역 선택

Framework	Next.js 15 (App Router)
Language	TypeScript 5 (strict)
Styling	Tailwind CSS v4
색 추출	color-thief-browser
SVG 렌더링	React 인라인 SVG
PNG 내보내기	html-to-image
MP4 내보내기	Canvas API + MediaRecorder API
가이드 투어	driver.js
다국어	i18next + react-i18next
배포	Vercel

설계에서 고민했던 것들

"같은 사진 = 같은 행성" — 의사난수 생성기에 시드를 주어 결정론적으로 만들었습니다. 덕분에 행성이 항상 재현 가능하고, 새로고침해도 동일한 결과가 나옵니다.

서버 없이 MP4 만들기 — 서버에 영상 인코딩을 맡기는 대신, 브라우저의 Canvas API와 MediaRecorder API만으로 구현했습니다. 처리 속도가 느릴 수 있지만 비용이 0이고 사용자의 사진이 어디로도 나가지 않습니다.

애니메이션과 DOM 성능 — 행성 위치를 React state로 관리하면 매 프레임 리렌더링이 발생합니다. 대신 anglesRef로 각도를 ref에 저장하고, el.style.transform으로 DOM을 직접 업데이트합니다. 10개 행성이 동시에 움직여도 React 렌더링 비용이 발생하지 않습니다.

마치며

모두에게 나만의 우주가 존재하고 여행/일상 사진이 하나의 항성계가 되어 끝내 우주가 만들어지는 아이디어로 시작한 프로젝트입니다. 서버 없이 브라우저만으로 이 정도를 구현할 수 있다는 걸 증명하는 의미도 있었습니다.

시장 반응을 보고 로그인기능과 기록기능을 추가할 예정입니다!

배포: Vercel

Dawnport — 매일 아침 뉴스 브리핑을 텔레그램으로 받아보기

Dwony — Thu, 19 Mar 2026 18:43:01 +0900

개인 투자에 관심이 생기면서 매일 아침 관련 뉴스를 챙겨보는 게 꽤 귀찮았다. 브라우저 켜고, 검색하고, 탭 여러 개 열어서 읽고... 그냥 자동으로 보내줬으면 싶었다. 그래서 직접 만들었다.

이름은 Dawn-Port. 새벽(Dawn)에 포트폴리오(Portfolio) 브리핑을 보낸다는 의미로 지었다.

관심있으시면 아래 깃허브로 들어가서 로컬컴퓨터에 설치해도 된다.

https://github.com/dwonDeV/dawnport

GitHub - dwonDeV/dawnport

Contribute to dwonDeV/dawnport development by creating an account on GitHub.

github.com

어떤 서비스인가

내가 관심 있는 키워드를 등록해두면, 매일 오전 7시에 알아서 관련 뉴스 TOP 5를 수집하고 로컬 LLM이 투자 분석까지 생성해서 텔레그램으로 보내준다. 키워드 관리도 전부 텔레그램 인라인 버튼으로 할 수 있어서 따로 앱이나 웹을 열 필요가 없다.

기술 스택은 이렇다.

프레임워크: NestJS
DB: SQLite + Prisma ORM (별도 DB 서버 불필요)
뉴스 수집: NewsAPI
AI 분석: Ollama (qwen3:8b, 로컬)
텔레그램: node-telegram-bot-api (polling 방식)
스케줄러: @nestjs/schedule

DB를 MySQL에서 SQLite로 바꾼 게 포인트다. prisma/dev.db 파일 하나로 끝나서 별도 DB 서버를 띄울 필요가 없다. 로컬에서 혼자 쓰는 개인 봇이라면 SQLite로 충분하다.

로컬 LLM을 쓴 이유는 API 비용이 0원이기 때문이다. Ollama로 qwen3:8b 모델을 띄워두면 GPT 수준은 아니어도 투자 분석 텍스트 생성에는 충분했다.

프로젝트 구조 잡기

처음엔 그냥 단일 파일로 만들까 했는데, 기능이 꽤 나뉘어서 NestJS 모듈 구조로 분리했다.

dawn-port/
├── prisma/
│   ├── schema.prisma        # DB 스키마 (SQLite)
│   ├── migrations/          # 마이그레이션 파일 (커밋됨)
│   └── dev.db               # SQLite DB 파일 (gitignore)
├── src/
│   ├── main.ts
│   ├── app.module.ts
│   ├── prisma/          # DB 연결
│   ├── keywords/        # 키워드 CRUD
│   ├── news/            # 뉴스 수집
│   ├── portfolio/       # AI 투자 분석
│   ├── telegram/        # 텔레그램 봇
│   └── scheduler/       # 스케줄러 + 수동 실행 API

각 기능이 독립된 모듈로 분리되어 있으니 나중에 뭘 바꿔도 영향 범위가 명확하다.

앱 진입점과 전역 설정

main.ts부터 보면 심플하다.

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { ValidationPipe } from '@nestjs/common';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }));
  app.setGlobalPrefix('api');
  await app.listen(process.env.PORT ?? 3000);
  console.log(`Dawn-Port server running on port ${process.env.PORT ?? 3000}`);
}
bootstrap();

ValidationPipe를 전역으로 설정해서 DTO 검증이 자동으로 되고, 모든 라우트는 /api 프리픽스를 붙인다.

app.module.ts에서는 ConfigModule.forRoot({ isGlobal: true })로 환경변수를 전역으로 쓸 수 있게 했고, ScheduleModule.forRoot()로 크론 스케줄러를 활성화했다.

Prisma로 DB 스키마 잡기

DB는 3개 테이블이다.

Keyword — 관심 키워드 목록. active 필드로 활성/비활성을 관리한다.

NewsItem — 수집된 뉴스 캐시. @@unique([url, keyword])로 같은 키워드로 같은 기사가 중복 저장되는 걸 막았다. @@index([keyword]), @@index([createdAt])으로 조회 성능도 챙겼다.

DailyReport — 발송 이력. AI가 생성한 투자 분석 전문이 저장된다.

PrismaModule은 @Global()로 선언해서 다른 모듈에서 별도 import 없이 바로 쓸 수 있도록 했다.

// prisma.module.ts
@Global()
@Module({
  providers: [PrismaService],
  exports: [PrismaService],
})
export class PrismaModule {}

// prisma.service.ts
@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
  async onModuleInit() {
    await this.$connect();
  }
}

키워드 CRUD

키워드는 단순한 CRUD다. 중복 등록은 ConflictException으로 처리했다.

// keywords.service.ts
async create(dto: CreateKeywordDto) {
  const existing = await this.prisma.keyword.findUnique({ where: { name: dto.name } });
  if (existing) throw new ConflictException(`키워드 '${dto.name}'이(가) 이미 존재합니다.`);
  return this.prisma.keyword.create({ data: { name: dto.name } });
}

findActive() {
  return this.prisma.keyword.findMany({ where: { active: true }, orderBy: { name: 'asc' } });
}

async toggleActive(id: number) {
  const keyword = await this.prisma.keyword.findUnique({ where: { id } });
  if (!keyword) throw new NotFoundException('키워드를 찾을 수 없습니다.');
  return this.prisma.keyword.update({ where: { id }, data: { active: !keyword.active } });
}

toggleActive는 현재 상태를 읽어서 반전시킨다. 별도 active 값을 받지 않고 항상 토글하는 방식이다.

REST API는 이렇게 노출된다.

메서드 경로 설명

GET	/api/keywords	키워드 전체 목록
POST	/api/keywords	키워드 추가
PATCH	/api/keywords/:id/toggle	활성/비활성 토글
DELETE	/api/keywords/:id	키워드 삭제
POST	/api/briefing/run	브리핑 즉시 실행

뉴스 수집 — NewsAPI 연동

뉴스 수집은 NewsService가 담당한다. 핵심 로직은 활성 키워드 전체를 OR로 연결해서 단일 API 요청을 보내는 것이다.

// news.service.ts
async fetchTopNews(keywords: string[]): Promise<newsarticle[]> {
  const apiKey = this.config.get('NEWS_API_KEY');
  const query = keywords.join(' OR ');

  let articles: NewsArticle[] = [];

  try {
    // 한국어 우선 시도
    const koResponse = await axios.get('<https://newsapi.org/v2/everything>', {
      params: { q: query, language: 'ko', sortBy: 'popularity', pageSize: 5, apiKey },
    });
    articles = koResponse.data.articles ?? [];

    // 결과 없으면 영어로 재시도
    if (articles.length === 0) {
      const enResponse = await axios.get('<https://newsapi.org/v2/everything>', {
        params: { q: query, language: 'en', sortBy: 'popularity', pageSize: 5, apiKey },
      });
      articles = enResponse.data.articles ?? [];
    }
  } catch (error) {
    this.logger.error(`뉴스 조회 실패: ${error.message}`);
    return [];
  }

  const top5 = articles.slice(0, 5);
  await this.saveArticles(top5, query);
  return top5;
}
</newsarticle[]>

한국어 뉴스를 먼저 시도하고, 결과가 없으면 영어로 재시도하는 fallback 로직이 있다. 뉴스는 popularity 순으로 상위 5개만 선택하고 DB에 upsert로 저장해서 중복을 방지한다.

NewsAPI 무료 플랜은 하루 100회 요청 제한이 있고 24시간 이전 뉴스만 조회된다는 점도 주의해야 한다.

AI 투자 분석 — Ollama 연동

PortfolioService에서 Ollama를 호출한다. 로컬에서 qwen3:8b 모델을 띄워두고 /api/chat 엔드포인트로 요청을 보낸다.

// portfolio.service.ts
const prompt = `다음은 오늘의 최신 뉴스입니다:

${newsContext.join('\\n')}

위 뉴스를 바탕으로 한국 투자자 관점에서 다음을 분석해주세요:

1. 시장 동향 요약 (2-3줄)
2. 단기 투자 전략 (1-4주): 구체적인 섹터/종목/ETF 추천과 이유
3. 중기 투자 전략 (1-6개월): 포지션 구축 전략
4. 장기 투자 전략 (6개월 이상): 자산 배분 및 포트폴리오 구성
5. 리스크 요인: 주의해야 할 사항

마크다운 문법(*, **, #, - 등)은 절대 사용하지 마세요. 일반 텍스트로만 작성하세요.`;

const response = await axios.post(
  `${this.ollamaHost}/api/chat`,
  {
    model: this.model,
    messages: [{ role: 'user', content: prompt }],
    stream: false,
    options: {
      temperature: 0.7,
      num_predict: 2000,
    },
  },
  { timeout: 120000 },
);

프롬프트에 마크다운 문법 사용 금지를 명시한 게 포인트다. 텔레그램으로 보낼 때 **, # 같은 기호가 섞이면 보기 불편하기 때문이다. timeout을 120초로 넉넉하게 준 이유는 로컬 LLM이 생각보다 느릴 수 있어서다.

텔레그램 봇 — 인라인 버튼 UI

텔레그램 봇의 핵심은 인라인 버튼으로 모든 걸 조작할 수 있게 한 것이다. /start를 치거나 서버가 시작되면 메인 메뉴 버튼이 나온다.

메인 메뉴
├──   키워드 목록
│   ├── [✅/⏸ 키워드명] → 클릭 시 활성/비활성 토글
│   ├── [  삭제] → 삭제 확인 → 삭제
│   └── [➕ 키워드 추가] / [← 뒤로]
├── ➕ 키워드 추가 → 텍스트 입력 대기 → 추가
└──   브리핑 지금 실행 → 실행 확인 → 브리핑 시작

버튼 콜백을 처리하는 방식을 보면, callback_data로 어떤 액션인지를 구분하고, 메시지를 새로 보내는 게 아니라 기존 메시지를 수정(editMessageText)하는 방식으로 채팅창이 지저분해지지 않게 했다.

// telegram.service.ts - 콜백 핸들러 일부
this.bot.on('callback_query', async (query) => {
  if (!this.isAllowed(query.message.chat.id)) return;
  await this.bot.answerCallbackQuery(query.id);
  const data = query.data;

  if (data === 'menu')             return this.sendMainMenu(chatId, msgId);
  if (data === 'list_keywords')    return this.sendKeywordList(chatId, msgId);
  if (data === 'add_keyword')      return this.promptAddKeyword(chatId, query.from.id, msgId);
  if (data === 'run_briefing')     return this.confirmBriefing(chatId, msgId);
  if (data === 'confirm_briefing') return this.runBriefing(chatId, msgId);

  if (data.startsWith('toggle_')) {
    const id = parseInt(data.split('_')[1]);
    return this.toggleKeyword(chatId, id, msgId);
  }
  // ...
});

키워드 추가는 상태 머신 방식으로 구현했다. userStates Map에 유저 ID를 키로 'adding_keyword' 상태를 저장해두고, 다음 텍스트 입력을 가로채서 키워드로 등록한다.

보안도 간단히 처리했다. TELEGRAM_CHAT_ID에 등록된 채팅 ID만 허용하도록 isAllowed() 체크를 모든 핸들러 첫 줄에 넣었다.

스케줄러와 순환 의존성 문제

SchedulerService가 TelegramService를 쓰고, TelegramService가 SchedulerService를 쓰는 순환 의존성이 생겼다. NestJS에서는 forwardRef()로 해결할 수 있다.

// scheduler.module.ts
@Module({
  imports: [KeywordsModule, NewsModule, PortfolioModule, forwardRef(() => TelegramModule)],
  // ...
})
export class SchedulerModule {}

// telegram.module.ts
@Module({
  imports: [KeywordsModule, forwardRef(() => SchedulerModule)],
  // ...
})
export class TelegramModule {}

서비스 쪽에서도 @Inject(forwardRef(() => TelegramService))처럼 주입을 받아야 한다. 양쪽 모두 수정해야 하므로 나중에 건드릴 때 주의가 필요하다.

크론 스케줄은 매일 UTC 22:00, 즉 KST 오전 7시에 실행된다.

// scheduler.service.ts
@Cron('0 22 * * *', { timeZone: 'UTC' })
async runMorningBriefing() {
  this.logger.log('모닝 브리핑 시작...');
  await this.executeBriefing();
}

executeBriefing()은 스케줄러와 텔레그램 버튼 양쪽에서 모두 호출할 수 있게 분리했다. REST API(POST /api/briefing/run)에서도 같은 메서드를 호출한다.

전체 브리핑 흐름 정리

실제로 브리핑이 실행될 때 어떤 순서로 돌아가는지 정리해보면 이렇다.

매일 오전 7:00 KST 자동 실행 (또는 수동 트리거)
          │
          ▼
활성 키워드 전체를 OR로 합쳐 NewsAPI 단일 요청
(한국어 우선 → 결과 없으면 영어)
          │
          ▼
popularity 순 상위 5개 뉴스 선택 → DB 저장
          │
          ▼
Ollama(qwen3:8b)로 투자 분석 생성
          │
          ▼
텔레그램으로 결과 발송 (4000자 초과 시 분할)
          │
          ▼
DailyReport DB에 이력 저장

텔레그램 메시지는 4000자 초과 시 splitMessage()로 자동 분할해서 보내도록 했다.

실행 방법

# 의존성 설치
npm install

# 환경변수 설정
cp .env.example .env
# .env 파일에 아래 값들을 채워 넣는다

# DB 마이그레이션 (SQLite 파일 자동 생성)
npx prisma migrate deploy

# 개발 서버 실행
npm run start:dev

환경변수는 이렇게 구성된다.

DATABASE_URL="file:./dev.db"

NEWS_API_KEY=your_newsapi_key_here
TELEGRAM_BOT_TOKEN=your_telegram_bot_token
TELEGRAM_CHAT_ID=your_chat_id

OLLAMA_HOST=http://localhost:11434
OLLAMA_MODEL=qwen3:8b
PORT=3000

CHAT_ID는 봇에게 텔레그램에서 아무 메시지나 보낸 뒤 브라우저에서 https://api.telegram.org/bot{TOKEN}/getUpdates에 접속하면 result[0].message.chat.id 값으로 확인할 수 있다. README.md에 자세히 적어놓았으니 참고바란다.

마무리

생각보다 만드는 데 시간이 많이 걸리지 않았다. NestJS 모듈 구조가 기능 분리를 강제해줘서 코드가 꽤 정돈되게 나왔다. MySQL 대신 SQLite를 쓰니까 DB 세팅 시간이 거의 없어진 것도 만족스럽다. 순환 의존성 문제가 잠깐 당황스러웠는데 forwardRef()로 해결되는 걸 알게 됐다.

개선하고 싶은 부분은 아직 있다. 지금은 NewsAPI 무료 플랜 한계로 24시간 이전 뉴스만 조회되는데, 유료 플랜이나 다른 뉴스 소스를 추가하면 더 유용해질 것 같다. AI 분석 품질도 모델을 바꾸거나 프롬프트를 더 다듬으면 개선될 여지가 있다.

⚠️ 이 서비스가 제공하는 투자 분석은 AI가 뉴스를 바탕으로 생성한 정보이며, 실제 투자 조언이 아니다. 투자 결정에 따른 손익은 전적으로 본인의 책임이다.

코인 자동매매 봇 (코이너) — v2 전면 재설계, WebSocket과 3단 아키텍처

Dwony — Sun, 8 Mar 2026 17:21:47 +0900

v1을 3편에 걸쳐 만들고 실제 돈으로 돌렸다. 초반엔 +18% 수익이 났다. 잘 된다 싶었는데, 이후 -20% 손실을 맞았다. 수익을 다 반납하고 원금까지 까먹은 상황이었다.

손실이 난 이유를 분석해봤다. 가장 큰 문제는 손절 반응 속도였다. v1은 1분 cron 단일 루프로 LLM 분석과 손절 체크를 한 큐에 처리했는데, LLM 응답을 기다리는 30~60초 동안 가격이 급락해도 아무것도 할 수 없는 구조였다. 거기에 투자금 배분 버그, LLM이 현재 RSI를 모르는 채 RSI 조건을 설정하는 구조적 모순까지 겹쳤다.

그래서 v2를 설계했다.

v1의 문제점

v1 구조는 이랬다.

매 1분 0초:
  LLM 분석 (30~60초 대기) → 손절/익절 체크 → 매수/매도

한 루프 안에 모든 게 들어있다 보니 문제가 층층이 쌓였다.

문제 설명

손절 반응 최대 60초 지연	LLM 응답 기다리는 동안 가격 급락 대응 불가
LLM이 매 분 블로킹	분석 중에는 손절 체크 자체가 멈춤
LLM RSI 조건 설정 모순	"RSI 45 이하 진입" 설정하는데 현재 RSI가 62인 경우 발생
투자금 불균등 배분	매수할 때마다 "남은 KRW × 비율"이라 3번째 종목은 1번째의 1/4 금액

손절이 60초 늦으면 어떤 일이 벌어지는지는 실제로 경험해봤다. 급락 구간에서 60초는 생각보다 훨씬 길다.

v2 아키텍처: 3레이어 분리

핵심 아이디어는 단순했다. 빠른 것과 느린 것을 섞지 않는다.

LLM은 느리다. WebSocket은 빠르다. 이 둘을 같은 루프에 넣으면 느린 쪽에 발목이 잡힌다. 그래서 3개의 독립 레이어로 분리했다.

┌──────────────────────────────────────────────────────┐
│  레이어 1: WebSocket 실시간 (~수십 ms)                │
│  Upbit WSS ticker 수신 → 손절 / 최대익절 즉시 실행   │
├──────────────────────────────────────────────────────┤
│  레이어 2: 지표 스케줄러 (1분마다)                    │
│  1분봉 갱신 → RSI/MA 진입·청산 조건 체크 → 매수/매도 │
├──────────────────────────────────────────────────────┤
│  레이어 3: LLM 전략 스케줄러 (15분마다)               │
│  후보 종목 선정 → TradingRule 생성 (진입·청산 조건)   │
└──────────────────────────────────────────────────────┘

LLM은 이제 "어떤 조건에서 사고 팔지" 규칙만 만든다. 실제 실행은 WebSocket과 지표 스케줄러가 담당한다. LLM이 30초 걸려도 손절/익절에 아무 영향이 없다.

속도 비교가 이렇게 달라졌다.

항목 v1 v2

손절 반응	최대 60초	~수십 ms
최대익절 반응	최대 60초	~수십 ms
LLM 호출 빈도	매 1분 (블로킹)	15분마다 (백그라운드)

신규 파일 3개

trading.rule.ts

LLM이 만드는 종목별 거래 규칙 인터페이스다. 진입·청산 조건 외에 손절/익절 기준도 종목별로 담는다.

export interface TradingRule {
  market: string;
  bias: 'bullish' | 'bearish' | 'neutral';
  entry: EntryCondition;   // rsiBelow, rsiAbove, maSignal
  exit: ExitCondition;     // rsiAbove, rsiBelow, maSignal
  stopLossPercent?: number;   // 종목별 손절 기준 (%)
  takeProfitMax?: number;     // 종목별 즉시 익절 기준 (%)
  goalProfitMin?: number;     // 종목별 매도 허용 최소 수익률 (%)
  reason: string;
  createdAt: number;
  expiresAt: number;          // 30분 TTL
}

upbit-websocket.service.ts

Upbit WSS(wss://api.upbit.com/websocket/v1) 연결·구독 관리다.

subscribe(markets[]) / unsubscribe(market) — 구독 목록 동적 변경 후 즉시 재전송
연결이 끊기면 3초 후 자동 재연결
SIMPLE 포맷 ticker 수신 → onTickerUpdate 콜백 호출

indicator.engine.ts

종목별 인메모리 캔들 버퍼다. 1분봉을 누적하며 실시간으로 지표를 계산한다.

engine.seed(market, candles);          // 초기 캔들 로드
engine.updatePrice(market, price);     // WebSocket 수신 시 현재가 반영
engine.get(market) → RealtimeIndicators  // RSI, MA5/20, volumeRatio, maSignal

LLM 전략 고도화

v1의 LLM이 가진 가장 큰 모순은 이거였다. RSI 조건을 직접 설정하면서 정작 해당 종목의 현재 RSI를 모른다는 것이다. "RSI 45 이하 진입"이라고 설정해놨는데, 지금 RSI가 62라면 그 조건은 의미가 없다. LLM이 현실을 모른 채 규칙만 만들고 있었다.

v2에서는 후보 종목의 1시간봉 RSI/ATR/MA를 계산해서 프롬프트에 넣었다. LLM이 실제 현황을 보고 조건을 설정하도록 바꿨다.

v1과 v2의 planStrategy 입력 데이터 비교다.

입력 데이터 v1 v2

공포/탐욕 지수	✅	✅
김치 프리미엄	✅	✅
종목 현황 (가격/등락률/거래대금)	✅	✅
전체 전략 성과 (DB)	✅	✅
BTC 1시간봉 추세	❌	✅
후보 종목 1h RSI / ATR / MA	❌	✅
종목별 봇 과거 통계 (승률·평균수익)	❌	✅
최근 6시간 손절 종목 (쿨다운)	❌	✅

쿨다운 로직도 추가했다. 최근 6시간 내에 손절된 종목은 MongoDB에서 조회해 LLM 프롬프트에 ⚠️최근손절 표시로 전달한다. LLM이 특별한 이유 없으면 해당 종목을 배제하도록 유도하는 방식이다.

종목별 봇 통계도 넣었다. KRW-XRP: 5회 승률 80% 평균 +3.2% 같은 정보를 제공해 이 봇에서 역사적으로 잘 동작한 종목을 LLM이 선호하도록 한다.

투자금 배분 버그 수정

v1에 조용히 살아있던 버그다. 당연히 되겠지 하고 넘어갔던 부분이었는데, 실제로 계산해보니 의도와 전혀 달랐다.

v1 (버그)

매수할 때마다: 현재 남은 KRW × TRADE_RATE_KRW

예) 총 10만원, TRADE_RATE_KRW=0.3, 3종목
  1번: 10만 × 0.3 = 3만원  (남은 KRW: 7만)
  2번:  7만 × 0.3 = 2.1만원 (남은 KRW: 4.9만)
  3번: 4.9만 × 0.3 = 1.47만원
  → 총 투자 6.57만원 (65.7%), 종목별 금액 제각각

TRADE_RATE_KRW=0.3이면 전체 자본의 30%를 쓰겠다는 뜻인데, 실제로는 65.7%가 투자되고 있었다. 게다가 첫 번째 종목에 두 배 넘게 몰리는 구조였다.

v2 (수정)

전체 자본(현금 + 이미 투자 중인 금액) × TRADE_RATE_KRW ÷ maxPositions

예) 총 10만원, TRADE_RATE_KRW=0.3, maxPositions=3
  종목당: 10만 × 0.3 ÷ 3 = 1만원 (균등)
  → 총 투자 3만원 (30%) ← TRADE_RATE_KRW 의도와 일치

const totalCapital =
  krwBalance + this.positions.reduce((sum, p) => sum + p.amountKrw, 0);
const amount = Math.floor(
  (totalCapital * this.tradeRateKrw) / this.maxPositions,
);

전체 자본 기준으로 계산하고 maxPositions으로 나눠서 균등 배분이 된다.

LLM이 손절·익절 기준 직접 설정

v1에서 손절/익절 기준은 .env의 환경변수로 모든 종목에 동일하게 적용됐다. 변동성이 낮은 종목이나 높은 종목이나 같은 기준을 쓰는 게 비효율적이었다.

v2에서는 LLM이 planStrategy 단계에서 종목별 ATR을 보고 개별 기준을 설정한다.

{
  "market": "KRW-XRP",
  "stopLossPercent": 3,
  "takeProfitMax": 8,
  "goalProfitMin": 2,
  ...
}

변동성 낮은 종목 → 손절 좁게, 익절 낮게
변동성 높은 종목 → 손절 넓게, 익절 높게
LLM이 값을 반환하지 않으면 환경변수 기본값으로 fallback

Position 구조도 바꿨다.

// v1
interface Position {
  market, startPrice, currentPrice, amountKrw, profitPercent
}

// v2
interface Position {
  market, startPrice, currentPrice, amountKrw, profitPercent,
  stopLossPercent,  // 포지션별 손절 기준
  takeProfitMax,    // 포지션별 즉시 익절 기준
  goalProfitMin,    // 포지션별 매도 허용 최소 수익률
}

텔레그램 상태 메시지에도 종목별 기준이 표시된다.

KRW-XRP | +2.3% | 손절: -3% / 익절: 8%

변경된 환경변수

변수 v1 v2

TRADE_CHECKING_PERIOD	✅ (cron 주기)	❌ 삭제
ANTHROPIC_API_KEY	❌	❌ (시도 후 제거)
GOAL_PROFIT_MIN_PERCENT	고정 적용	LLM 미설정 시 fallback
GOAL_PROFIT_MAX_PERCENT	고정 적용	LLM 미설정 시 fallback
GOAL_STOP_LOSS_PERCENT	고정 적용	LLM 미설정 시 fallback
TRADE_RATE_KRW	종목당 남은 KRW 비율	전체 자본 균등 분배 비율

코드 변화량

18개 파일 변경
+1,214줄 추가
-521줄 삭제

신규 파일 3개(trading.rule.ts, upbit-websocket.service.ts, indicator.engine.ts), 삭제 파일 3개(app.controller.ts, app.service.ts, app.controller.spec.ts).

사용하지 않는 메서드와 인터페이스도 전부 정리했다. OllamaService.selectMarkets(), OllamaService.selectMarket(), UpbitService.getCurrentPrice() 등 WebSocket과 새 전략 스케줄러로 대체된 것들이다.

정리

v1에서 +18% 수익을 냈다가 -20% 손실로 끝난 게 v2를 만든 직접적인 계기였다. 손절이 60초 늦는 구조, 투자금이 불균등하게 배분되는 버그, LLM이 현재 RSI를 모르는 채 조건을 설정하는 모순. 이 세 가지를 고쳐야 했다.

v2는 아직 운영 중이다. WebSocket 실시간 손절이 실제로 얼마나 차이를 만드는지는 좀 더 지켜봐야 알 수 있다. LLM 전략 고도화도 마찬가지다. 결과는 나중에 따로 정리할 예정이다.

코인 자동매매 봇 (코이너) — 모델 업그레이드, 수익 최적화

Dwony — Mon, 23 Feb 2026 23:21:26 +0900

전 편에서 텔레그램과 MongoDB가 붙어서 스마트폰으로 봇을 제어할 수 있게 됐다. 이번 편에서는 판단 품질을 더 높여보고 싶어서 이것저것 좀 더 구해본 과정이다.

목표 수익률을 범위값으로

처음엔 GOAL_PROFIT_PERCENT=3이면 수익률 3% 달성하자마자 무조건 매도하는 구조였다. 하지만 생각해보면 3%를 넘어도 더 오른다 싶어서 기다리는 상황이 올 수 있다. LLM이 더 오를 것 같다고 판단하면 홀드하고, 내릴 것 같다고 판단하면 그때 파는 구조가 더 자연스럽다.

범위값 방식으로 바꿨다.

수익률 < -손절%    → 즉시 손절
수익률 >= 정시 철수(7%)  → 강제 매도

3% ~ 7% 구간:
  LLM SELL 판단 → 매도
  LLM HOLD 판단 → 더 기다림

3% 미만:
  LLM SELL 와도 무시 (3%는 되어야 나가준다)

코드에서도 이 흐름대로 도는데, LLM 프롬프트에도 현재 수익률과 허용 범위를 알려서 LLM이 상황을 인지한 뒤 판단하도록 했다.

private async handlePosition(pos: Position) {
  // 1. 손절 (최우선)
  if (pos.profitPercent <= -this.stopLossPercent) {
    await this.executeClose(pos, '손절');
    return;
  }

  // 2. 최대 목표 돌파 → 강제 매도
  if (pos.profitPercent >= this.goalProfitMax) {
    await this.executeClose(pos, `최대 목표 달성 (+${pos.profitPercent.toFixed(2)}%)`);
    return;
  }

  // 3. LLM 판단
  const decision = await this.ollama.analyze(
    pos.market, candles1m, candles15m, candles1h,
    { profitPercent: pos.profitPercent, goalMin: this.goalProfitMin, goalMax: this.goalProfitMax },
  );

  // 최소 목표 이상일 때만 SELL 허용
  if (decision.signal === 'SELL' && pos.profitPercent >= this.goalProfitMin) {
    await this.executeClose(pos, `LLM 매도 (+${pos.profitPercent.toFixed(2)}%)`);
  }
}

.env도 두 개로 나눴다.

GOAL_PROFIT_MIN_PERCENT=3
GOAL_PROFIT_MAX_PERCENT=7

투자 비율 기반으로 변경

TRADE_AMOUNT_KRW로 고정 금액을 설정하던 방식을 TRADE_RATE_KRW로 명칭을 바꾸고, KRW 잔고의 비율로 투자하도록 바꿨다.

// 변경 전: 고정 금액
const amount = Math.min(this.tradeAmountKrw, krwBalance);

// 변경 후: 잔고 비율
const amount = Math.floor(krwBalance * this.tradeRateKrw);

잔고가 100,000원에서 TRADE_RATE_KRW=0.3으로 설정하면 첫 번째 매수는 30,000원, 두 번째 매수 시점 잔고가 70,000원이라면 21,000원 식으로 자동으로 조절된다.

LLM 모델 업그레이드

llama3.2:3b는 3B 파라미터 모델이라 추론 품질에 한계가 있었다. JSON 포맷을 엄격하게 지켜야 하는 우리 봇 구조에서는 모델의 JSON 신뢰도가 중요했다.

모델 비교

모델 RAM 속도 추론 JSON 안정성

llama3.2:3b (기존)	2GB	매우 빠름	낙음	보통
llama3.1:8b	8GB	빠름	중간	좋음
qwen2.5:7b	5GB	빠름	중상	좋음
deepseek-r1:14b	14GB	매우 느림	높음	보통
qwen2.5:14b	8GB	빠름	높음	실패 적음

M2 Pro 16GB 환경에서 qwen2.5:14b가 가장 적합하다. 모델 크기가 약 8.2GB라 운영체제 메모리 여유를 남기면서 Apple Silicon GPU 가속으로 초당 30~50 토큰 속도가 나온다. deepseek는 내부적으로 thinking 토큰을 먼저 생성해서 응답이 느려 타임아웃 위험이 있어서 제외했다.

모델 변경

.env에서 한 줄만 바꾸면 된다.

OLLAMA_MODEL=qwen2.5:14b

14b 모델은 응답이 느릴 수 있어서 타임아웃도 맞게 늘렸다.

// analyze: 60s → 90s
// selectMarkets/selectMarket: 30s → 60s
await axios.post(url, body, { timeout: 90000 });

qwen2.5:14b 모델을 풀받았다.

모델이 다운로드됐다면 ollama list 명령어로 확인할 수 있다.

LLM 타임아웃 문제 해결

모델을 바꿔도 "LLM 분석실패" 오류가 자꾸 뜨다. Ollama는 기본적으로 5분 동안 요청이 없으면 모델을 메모리에서 내린다. 5분봉 봇이니까 가끔 모델이 내린 시점에 요청이 오면 재로드에 15~20초가 걸리면서 타임아웃이 발생하는 것이었다.

await axios.post(
  `${this.baseUrl}/api/generate`,
  {
    model: this.model,
    prompt,
    stream: false,
    format: 'json',
    options: { num_predict: 200 }, // 불필요한 토큰 생성 차단
    keep_alive: '30m',             // 모델 메모리 유지 30분
  },
  { timeout: 90000 },
);

keep_alive: '30m'를 설정하니 재로드 없이 메모리에 상주해서 바로 응답한다. num_predict: 200으로 토큰 생성에도 상한을 세팅하니 생성 토큰을 딱 필요한 수준으로만 제한했다. 두 개를 적용한 후엔 타임아웃이 없어졌다.

수익 개선 아이디어 구현

수익률을 더 올릴 수 있는 아이디어를 정리해보니 우선순위가 이렇게 나왔다.

1순위: ATR 변동성 필터 — 손절 횟수 감소 효과 확실
2순위: 김치 프리미엄 — 무료, 한국 시장 특성에 직접적
3순위: 업비트 투자유의 공시 필터 — 입출금 중단 종목 매수 회피

세 개를 한번에 적용했다.

1. ATR 변동성 필터

ATR(Average True Range)은 일정 기간 동안의 실제 가격 영역을 측정하는 지표다. 변동성이 클 때는 매매를 피하면 손절 횟수를 줄일 수 있다.

private calcATR(candles: Candle[], period = 14): number {
  if (candles.length < period + 1) return 0;
  const trs: number[] = [];
  for (let i = 0; i < period; i++) {
    const high = candles[i].high_price;
    const low = candles[i].low_price;
    const prevClose = candles[i + 1].trade_price;
    trs.push(Math.max(high - low, Math.abs(high - prevClose), Math.abs(low - prevClose)));
  }
  return trs.reduce((a, b) => a + b, 0) / period;
}

private atrDesc(candles: Candle[]): string {
  const atr = this.calcATR(candles);
  const price = candles[0]?.trade_price ?? 1;
  const atrPct = (atr / price) * 100;
  if (atrPct >= 3) return `${atrPct.toFixed(2)}% → 매우 과도한 변동성 (진입 자제 권장)`;
  if (atrPct >= 1.5) return `${atrPct.toFixed(2)}% → 일반 변동성`;
  return `${atrPct.toFixed(2)}% → 낙은 변동성 (안정적)`;
}

LLM 프롬프트에는 이렇게 전달된다.

변동성 (ATR 14, 1분봉 기준): 2.31% → 일반 변동성

2. 김치 프리미엄

한국 거래소와 해외 거래소 가격 차이인 김치 프리미엄을 LLM에 넘겨준다. 김프가 높으면 한국만 과열된 상황이라 하락 위험이 있고, 역프(음수)이면 해외 대비 저평가 신호다.

Binance 공개 API로 BTC 해외 가격을 가져오고, USD/KRW 환율은 open.er-api.com에서 1시간 단위로 캐싱해둔다.

private usdKrwCache: { rate: number; cachedAt: number } | null = null;

private async getUsdKrw(): Promise {
  const now = Date.now();
  if (this.usdKrwCache && now - this.usdKrwCache.cachedAt < 3600_000) {
    return this.usdKrwCache.rate;
  }
  const res = await axios.get('<https://open.er-api.com/v6/latest/USD>');
  const rate = res.data.rates.KRW;
  this.usdKrwCache = { rate, cachedAt: now };
  return rate;
}

private async fetchKimchiPremium(): Promise {
  const [upbitRes, binanceRes, usdKrw] = await Promise.all([
    axios.get<upbittickeritem[]>('<https://api.upbit.com/v1/ticker?markets=KRW-BTC>'),
    axios.get('<https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT>'),
    this.getUsdKrw(),
  ]);
  const upbitPrice = upbitRes.data[0].trade_price;
  const binanceKrw = parseFloat(binanceRes.data.price) * usdKrw;
  const premium = ((upbitPrice / binanceKrw) - 1) * 100;
  return `${premium.toFixed(2)}% (${premium > 3 ? '과열 — 하락 주의' : premium < -1 ? '역프 — 저평가 기회' : '정상 범위'})`;
}
</upbittickeritem[]>

3. 업비트 투자유의 필터

업비트 API에서 투자유의 전제가 걸린 종목 목록을 가져와서 종목 선택 단계에서 제외한다. 투자유의는 입출금 중단, 급등락, 생태계 이슈 등이 있어 판단을 야기하기에 맞지 않는 종목들이다.

// upbit.service.ts
async getMarketWarnings(): Promise<Set<string>> {
  try {
    const res = await axios.get<MarketDetail[]>(
      `${this.baseUrl}/market/all?isDetails=true`,
    );
    const warnings = new Set<string>();
    for (const m of res.data) {
      if (m.market_event?.warning) warnings.add(m.market);
    }
    return warnings;
  } catch {
    return new Set<string>();
  }
}

fillPositions()에서 심용 종목과 투자유의 종목을 동시에 필터링한다.

private async fillPositions(slots: number) {
  const excludeMarkets = this.positions.map((p) => p.market);
  const [topTickers, warningMarkets] = await Promise.all([
    this.upbit.getTopMarkets(20 + excludeMarkets.length),
    this.upbit.getMarketWarnings(),
  ]);

  const available = topTickers.filter(
    (t) => !excludeMarkets.includes(t.market) && !warningMarkets.has(t.market),
  );

  if (warningMarkets.size > 0) {
    this.logger.log(`투자유의 종목 ${warningMarkets.size}개 제외: ${[...warningMarkets].join(', ')}`);
  }
  // 필터링된 available 목록으로 LLM 종목 선택
  const decisions = await this.ollama.selectMarkets(available, slots);
  ...
}

이렇게 투자유의 종목들을 사전에 필터링 하는것을 볼 수 있다.

종목별 수동 매도

LLM 판단이 너무 늦게 나오거나 특정 포지션을 직접 닫고 싶을 때 텔레그램에서 바로 매도할 수 있도록 수동 매도 기능도 추가했다.

상태 확인 메시지에 보유 중인 종목이 표시될 때 각 종목에 [매도] 버튼이 방식이다.

버튼을 누르면 해당 포지션의 수동 매도가 실행되고 텔레그램으로 매도 완료 메시지가 온다. 자동재시작 ON이라도 수동 매도는 재시작하지 않는다.

보안 점검

GitHub에 푸시하기 전에 보안 점검을 진행했다. 확인 대상은 세 가지였다.

항목 상태

.env (실제 API키, 토큰)	.gitignore에 등록됨 — 푸시 안 됨
소스코드 내 비밀값	전부 ConfigService로 환경변수 참조 — 하드코딩 없음
node_modules/, dist/	.gitignore에 등록됨

한 가지 보완할 게 있었다. .claude/ 디렉토리가 .gitignore에 없어서 settings.local.json이 푸시될 수 있는 상황이었다. .claude/를 .gitignore에 추가함으로써 해결했다.

최종 프로젝트 구조

src/
├── upbit/
│   ├── upbit.service.ts    # API, JWT인증, 투자유의 필터
│   └── upbit.module.ts
├── ollama/
│   ├── ollama.service.ts   # RSI/MA/ATR/김프/공포탐욕/CoT
│   └── ollama.module.ts
├── trading/
│   ├── trading.service.ts  # 다중포지션, 범위수익률, 자동재시작
│   ├── trading.controller.ts
│   └── trading.module.ts
├── telegram/
│   ├── telegram.service.ts # 인라인버튼, 수동매도, 알림
│   └── telegram.module.ts
├── database/
│   ├── trade-record.schema.ts
│   ├── trade-record.service.ts
│   └── database.module.ts
├── app.module.ts
└── main.ts

정리

3편에 걸쳐 보다 성숙해진 봇이 됐다.

모델을 llama3.2:3b에서 qwen2.5:14b로 올렸고, 타임아웃 문제도 해결했다.

수익률 범위 설정으로 LLM이 매도 타이밍을 직접 결정할 수 있게 됐고,

ATR / 김치 프리미엄 / 투자유의 필터로 더 명확한 근거에 기반한 판단이 가능해졌다.

수동 매도 기능도 더해져 텔레그램에서 보다 세밀하게 포지션을 컨트롤할 수 있다.

실제 돈으로 돌리면서 느낀점은, LLM은 시장을 예측하는 게 아니라 지표를 해석해서 판단에 도움을 주는 역할이라는 거다. 프롬프트를 얼마나 잘 설계하느냐두가 결국 매매 품질에 직결된다는 게 큰 교훈이었다.

앞으로 며칠간 꾸준히 돌려보고 수익률을 측정해볼 생각이다.

좋은 아이디어가 있으면 댓글로 알려주기 바란다.

감사하다.

코인 자동매매 봇 (코이너) — 텔레그램 연동, MongoDB, 프롬프트 고도화

Dwony — Mon, 23 Feb 2026 20:02:03 +0900

전편에서 NestJS 기반 자동매매 봇의 뼈대를 완성했다. 이번 편에서는 스마트폰으로 봇을 제어할 수 있게 텔레그램을 연동하고, 매매 기록을 MongoDB에 저장하고, LLM이 더 입체적으로 판단할 수 있도록 프롬프트를 고도화한 과정을 기록한다.

종목 자동 선택

처음엔 BTC만 보던 봇이었는데, 거래량 상위 코인 중에서 LLM이 직접 종목을 골라서 매수하는 방식으로 바꿨다.

동작 방식은 간단하다. 포지션이 비어있을 때마다 Upbit KRW 마켓 전체 종목을 조회해서 24시간 거래대금 상위 20개를 추린 뒤, 그 목록을 LLM에 넘겨서 { signal: "BUY", market: "KRW-ETH", reason: "..." } 형태로 종목과 매매 신호를 동시에 받는다.

포지션이 있을 때는 보유 종목의 캔들을 분석해서 SELL/HOLD만 판단한다. 종목 선택과 매도 판단이 완전히 분리된 구조다.

이제 코이너가 종목을 알아서 선택한다.

텔레그램 봇 연동

서버를 켜두고 스마트폰으로 봇을 제어하고 싶었다. 텔레그램 봇을 연동하는 게 가장 빠른 방법이었다.

봇 토큰과 Chat ID 발급

텔레그램에서 @BotFather를 검색해서 /newbot 명령어로 봇을 만들면 토큰이 발급된다.

Chat ID는 만들어진 봇에 아무 메시지나 보낸 뒤 아래 URL에 접속하면 응답 JSON에서 확인할 수 있다.

<https://api.telegram.org/bot여기에토큰입력/getUpdates>

응답에서 "chat": {"id": 123456789} 부분이 Chat ID다.

봇을 만들고 위 주소로 접속하면 이렇게 뜬다.

알아낸 봇 API토큰과 Chat ID를 .env에 추가한다.

TELEGRAM_BOT_TOKEN=여기에_봇_토큰_입력
TELEGRAM_CHAT_ID=여기에_Chat_ID_입력

패키지 설치

npm install node-telegram-bot-api
npm install -D @types/node-telegram-bot-api

인라인 버튼 구성

텍스트 명령어(/start_bot 등)도 만들었지만, 버튼이 훨씬 편했다. 모든 메시지 하단에 인라인 키보드가 자동으로 붙도록 했다.

[ ▶ 봇 시작 ]  [ ⏹ 봇 중단 ]
[   자동재시작: ON ]
[   상태 확인 ]  [   자산 조회 ]
[   매매 내역 ]  [   수익 통계 ]

코이너 채팅 화면이다.

자동 재시작 모드

목표 수익 달성이나 손절로 봇이 종료되면 5초 후 자동으로 다시 시작하는 기능도 추가했다. 기본값은 ON이다. 수동으로 ⏹ 봇 중단 버튼을 누른 경우에는 자동 재시작이 동작하지 않는다.

private autoRestart = true; // 기본 ON

private async finishBot(reason: string) {
  this.running = false;
  await this.telegram.send(`봇 종료: ${reason}`);

  if (this.autoRestart) {
    await this.telegram.send('5초 후 자동 재시작...');
    setTimeout(() => this.start(), 5000);
  }
}

HOLD 메시지 제거

처음엔 매 5분마다 HOLD 메시지가 와서 알림이 너무 많았다. HOLD일 때는 텔레그램으로 아무것도 보내지 않도록 바꿨다. 실제로 의미 있는 이벤트(매수, 매도, 목표달성, 손절, 오류)만 알림이 온다.

자산 조회 /balance

텔레그램에서 자산 조회 버튼을 누르면 현재 Upbit 잔고를 바로 볼 수 있다.

[업비트 자산 현황]

KRW: 70,000원
ETH: 0.007
  현재가: 4,230,000원
  평가금액: 29,610원
  수익률: +1.43%

총 평가금액: 99,610원

이런식으로 보유 종목을 표시해준다.

MongoDB 연동

서버를 재시작하면 매매 기록이 날아가는 게 불편했다. MongoDB를 붙여서 기록을 영구적으로 저장하기로 했다.

MySQL vs MongoDB

MySQL + TypeORM도 고려했지만 이 프로젝트엔 MongoDB가 더 맞았다. 매매 기록에 LLM 판단 근거, RSI 수치, 이동평균 신호 같은 중첩 데이터가 포함되는데, MySQL이면 별도 테이블 설계가 필요하다. MongoDB는 JSON 그대로 저장할 수 있어서 스키마 변경 부담도 없다.

Docker로 로컬 실행

MongoDB가 로컬에 없어서 Docker로 컨테이너를 띄웠다. --restart always 옵션으로 컴퓨터를 재시작해도 자동으로 올라온다.

docker run -d --name coin-bot-mongo -p 27017:27017 --restart always mongo:7

npm install @nestjs/mongoose mongoose

위 명령어로 MongoDB 이미지를 불러와 로컬에 띄웠다. 도커 데스크탑에서 확인할 수 있다.

매매 기록 저장 구조

매수/매도 시마다 아래 형태로 MongoDB에 자동 저장된다.

{
  "type": "BUY",
  "market": "KRW-ETH",
  "price": 4230000,
  "amount": 30000,
  "indicators": { "rsi": 28.3, "maSignal": "golden_cross" },
  "llmReason": "RSI 과매도 + 골든크로스 발생",
  "timestamp": "2026-02-23T10:00:00Z"
}

DataGrip으로 접속

DataGrip에서 MongoDB 접속은 간단하다. + → MongoDB 선택 후 아래 정보를 입력하면 된다.

항목 값

Host	localhost
Port	27017
Database	coin-bot

MongoDB는 데이터가 처음 저장될 때 DB가 생성된다. 아직 매매가 없으면 coin-bot DB가 보이지 않는 게 정상이다. 첫 매수가 실행되면 자동으로 생긴다.

도커의 몽고디비를 데이터그립으로 불러왔다. (좌)

트레이딩기록을 잘 남기고 있음도 확인했다. (우)

텔레그램에서 매매 내역 / 수익 통계 조회

매매 내역 버튼을 누르면 최근 10건을 볼 수 있다.

수익 통계 버튼을 누르면 승률과 누적 수익이 나온다.

이건 다음날 아침에 확인해본 데이터다. 60%면 꽤 괜찮은데?

서버 재시작 후 포지션 복구

코인을 보유한 채로 서버가 꺼지면 봇이 포지션을 모르는 상태로 재시작된다. 그러면 또 매수를 시도할 수도 있다. (실제로 그랬다.)

해결 방법으로 서버 시작 시 Upbit 잔고를 직접 조회해서 코인이 남아있으면 자동으로 포지션을 복구하도록 했다.

private async restorePositionFromBalance() {
  const balances = await this.upbit.getBalances();
  const coinBalance = balances.find(
    (b) => b.currency !== 'KRW' && parseFloat(b.balance) > 0
  );

  if (coinBalance) {
    const market = `KRW-${coinBalance.currency}`;
    const startPrice = parseFloat(coinBalance.avg_buy_price);
    this.positions.push({ market, startPrice, volume: parseFloat(coinBalance.balance) });
    await this.telegram.send(`기존 포지션 감지 — 이어서 시작\\n종목: ${market}\\n평단가: ${startPrice.toLocaleString()}원`);
  }
}

서버 재시작 시 텔레그램으로 이런 메시지가 온다.

이렇게 기존 포지션을 이어간다고 메시지가 온다.

다중 포지션 (분산투자)

한 종목에만 투자하는 게 아니라 2~3개 종목을 동시에 보유할 수 있도록 구조를 바꿨다.

.env에 TRADE_MAX_POSITIONS=3을 추가하면 최대 3개 포지션을 동시에 운용한다. 비어있는 슬롯 수만큼 LLM이 종목을 골라서 매수하고, 각 포지션은 독립적으로 손절/목표 체크를 진행한다.

@Cron('0 */5 * * * *')
async onCandle() {
  if (!this.running) return;

  // 보유 포지션 각각 체크
  await Promise.all(this.positions.map((pos) => this.handlePosition(pos)));

  // 빈 슬롯만큼 새 종목 매수
  const slots = this.maxPositions - this.positions.length;
  if (slots > 0) await this.fillPositions(slots);
}

상태 확인 메시지도 다중 포지션을 보여주도록 바꿨다.

프롬프트 고도화

멀티 타임프레임

1분봉 데이터만 보던 LLM에게 15분봉과 1시간봉을 같이 넘기도록 바꿨다. 단기 흐름과 장기 흐름을 동시에 파악해서 더 입체적인 판단이 가능해진다.

const [candles1m, candles15m, candles1h] = await Promise.all([
  this.upbit.getCandles(market, 1, 30),
  this.upbit.getCandles(market, 15, 24),
  this.upbit.getCandles(market, 60, 24),
]);

LLM 프롬프트에 이렇게 전달된다.

[1분봉] RSI(14): 28.3 → 과매도 | 골든크로스 | 거래량 급증
[15분봉] RSI(14): 45.1 → 중립 | MA5 > MA20 | 거래량 보통
[1시간봉] RSI(14): 62.4 → 중립 | 데드크로스 | 거래량 보통

"단기적으론 과매도지만 장기 하락세" 같은 판단이 가능해진다.

공포/탐욕 지수

api.alternative.me 무료 API를 활용해서 시장 전체 심리를 프롬프트에 반영했다. 별도 API 키가 필요 없다.

private async getFearGreedIndex(): Promise {
  const res = await axios.get('<https://api.alternative.me/fng/?limit=1>');
  const { value, value_classification } = res.data.data[0];
  const map: Record<string, string=""> = {
    'Extreme Fear': '극도의 공포 (강한 매수 고려)',
    'Fear': '공포 (신중한 매수 고려)',
    'Neutral': '중립',
    'Greed': '탐욕 (매도 고려)',
    'Extreme Greed': '극도의 탐욕 (강한 매도 고려)',
  };
  return `${value} (${map[value_classification] ?? value_classification})`;
}
</string,>

프롬프트에는 이렇게 들어간다.

시장 공포/탐욕 지수: 42 (공포 — 신중한 매수 고려)

https://api.alternative.me/fng/?limit=1 의 내용이다.

Chain of Thought

LLM이 결론을 바로 뱉지 않고 단계적으로 분석하도록 프롬프트를 구성했다. 추론 능력이 확실히 올라간다.

결론을 내기 전에 다음 순서로 분석해라:
1. 현재 가격의 지지선과 저항선은 어디인가?
2. 각 타임프레임의 신호가 일치하는가, 엇갈리는가?
3. 시장 심리(공포/탐욕 지수)가 현재 포지션에 유리한가?
4. 위 분석을 종합해서 최종 판단을 내려라.

반드시 JSON으로만 응답해라:
{"signal": "BUY|SELL|HOLD", "reason": "판단 근거"}

정리

이번 편에서는 봇에 실제로 쓸 수 있는 기능들을 붙였다. 텔레그램으로 언제 어디서든 봇을 제어할 수 있게 됐고, MongoDB로 매매 기록이 영구적으로 남는다. 서버가 꺼졌다 켜져도 포지션을 이어서 유지하고, 멀티 타임프레임과 공포/탐욕 지수로 LLM이 더 많은 정보를 보고 판단하게 됐다.

다음 편에서는 RSI 추가 지표, ATR 변동성 필터, 모델 업그레이드(llama3.2 → qwen2.5:14b) 과정을 다룰 예정이다.

코인 자동매매 봇 (코이너) — 프로젝트 세팅과 첫 실행

Dwony — Mon, 23 Feb 2026 19:16:58 +0900

바이브코딩으로 코인 자동매매 프로그램을 만들어봤다. Claude Code와 대화하면서 NestJS 기반의 봇을 처음부터 구축한 과정을 기록한다.

이 시리즈는 여러편으로 나눠서 작성할 예정이다. 이번 편에서는 프로젝트 초기 세팅부터 봇이 처음 실행되기까지의 과정을 다룬다.

참고로 COINER는 내가 지은 이름이다. 나노바나나한테 부탁했더니 저런 이미지를 가져왔다..

목표 설정

세 가지 조건을 만족하는 자동매매 봇을 만들고 싶었다.

외부 유료 API 없이 로컬 LLM으로 매매 판단
코드를 직접 짜지 않는 바이브코딩 방식으로 개발
목표 수익률 달성 시 자동 중단

Claude Code에 이 조건을 전달하자 5단계 개발 로드맵이 나왔다. 거래소는 Upbit, LLM은 이미 설치되어 있던 Ollama, 전략은 매 5분봉마다 LLM이 판단하는 방식으로 결정했다.

기술 스택

NestJS — 서버 프레임워크
Upbit REST API — 캔들 조회, 매수/매도
Ollama — 로컬 LLM 실행 (llama3.2)
@nestjs/schedule — Cron 기반 자동 실행
jsonwebtoken, uuid — Upbit JWT 인증

패키지 설치 중 권한 문제

패키지를 설치하려고 했더니 바로 에러가 났다.

Error: EACCES: permission denied, open 'package-lock.json'
errno: -13,
code: 'EACCES',

node_modules와 package-lock.json이 root 소유로 되어 있어서 npm이 파일을 열지 못하는 문제였다. 아래 명령어로 소유권을 바꿔줬다.

sudo chown -R dwon /Users/dwon/Desktop/PROJECT/coin-bot/node_modules
sudo chown dwon /Users/dwon/Desktop/PROJECT/coin-bot/package-lock.json

이후에는 패키지를 직접 설치하는 방식으로 진행했다.

npm install @nestjs/config @nestjs/schedule axios jsonwebtoken uuid
npm install -D @types/jsonwebtoken @types/uuid

프로젝트 구조

모듈은 크게 세 가지로 나눴다.

src/
├── upbit/
│   ├── upbit.service.ts   # 캔들 조회, 매수/매도, 잔고 조회
│   └── upbit.module.ts
├── ollama/
│   ├── ollama.service.ts  # 캔들 → 프롬프트 → BUY/SELL/HOLD
│   └── ollama.module.ts
├── trading/
│   ├── trading.service.ts # 5분봉마다 실행, 목표/손절 체크
│   ├── trading.controller.ts
│   └── trading.module.ts
├── app.module.ts
└── main.ts

Upbit는 거래소와의 통신만,

Ollama는 LLM 판단만,

Trading은 전체 매매 흐름 조율만 담당하도록 역할을 분리했다.

UpbitService 구현

Upbit API는 JWT 인증이 필요하다. 주문 API를 호출할 때 쿼리 파라미터를 SHA512로 해시해서 JWT payload에 담아 보내야 한다.

private generateToken(query?: string): string {
  const payload: TokenPayload = {
    access_key: this.accessKey,
    nonce: uuidv4(),
  };

  if (query) {
    const hash = crypto.createHash('sha512');
    hash.update(query, 'utf8');
    payload.query_hash = hash.digest('hex');
    payload.query_hash_alg = 'SHA512';
  }

  return jwt.sign(payload as object, this.secretKey);
}

캔들 조회는 인증이 필요 없는 단순 GET 요청이지만, 매수/매도 주문은 반드시 이 토큰이 필요하다.

시장가 매수와 매도는 파라미터 방식이 다르다는 점을 주의해야 한다. 매수는 ord_type: 'price'에 원화 금액을, 매도는 ord_type: 'market'에 코인 수량을 넣는다.

// 시장가 매수 — 원화 금액 기준
async buyMarketOrder(market: string, priceKrw: number): Promise<void> {
  const params = {
    market,
    side: 'bid',
    price: String(priceKrw),
    ord_type: 'price',
  };
  const query = querystring.stringify(params);
  const token = this.generateToken(query);
  await axios.post(`${this.baseUrl}/orders`, params, {
    headers: { Authorization: `Bearer ${token}` },
  });
}

// 시장가 매도 — 코인 수량 기준
async sellMarketOrder(market: string, volume: number): Promise<void> {
  const params = {
    market,
    side: 'ask',
    volume: String(volume),
    ord_type: 'market',
  };
  // ...
}

업비트 사이트에 들어가서 [마이페이지] > [Open API 관리] 페이지에 접속해서 API Key를 발급받을 수 있다.

나는 모든 기능을 전부 쓸것이므로 전부 체크해주었다. 내 고유 아이피를 업비트에 화이트리스트로 등록해한다. 여기를 참고하자

OllamaService 구현

Ollama는 로컬에서 실행 중인 LLM에 HTTP로 요청을 보내는 방식이다. http://localhost:11434/api/generate 엔드포인트에 프롬프트를 전달하면 JSON으로 응답이 온다.

핵심은 프롬프트 설계다. 캔들 원시 데이터를 그대로 던지는 게 아니라, RSI / 이동평균선 / 거래량 지표를 미리 계산해서 LLM이 해석하기 쉬운 문장으로 변환해서 전달한다.

private calcRSI(candles: Candle[], period = 14): number {
  if (candles.length < period + 1) return 50;
  const closes = candles
    .slice(0, period + 1)
    .reverse()
    .map((c) => c.trade_price);
  let gains = 0, losses = 0;
  for (let i = 1; i < closes.length; i++) {
    const diff = closes[i] - closes[i - 1];
    if (diff > 0) gains += diff;
    else losses += Math.abs(diff);
  }
  const avgGain = gains / period;
  const avgLoss = losses / period;
  if (avgLoss === 0) return 100;
  return 100 - 100 / (1 + avgGain / avgLoss);
}

수치를 계산한 뒤에는 사람이 읽을 수 있는 문장으로 바꿔서 프롬프트에 담는다.

private indDesc(ind: Indicators): string {
  const rsiDesc =
    ind.rsi >= 70 ? '→ 과매수 (매도 고려)'
    : ind.rsi <= 30 ? '→ 과매도 (매수 고려)'
    : '→ 중립';

  return `RSI(14): ${ind.rsi.toFixed(1)} ${rsiDesc} | MA: ${maDesc} | 거래량: ${volDesc}`;
}

LLM에게는 반드시 JSON만 반환하도록 지시했다. 자유로운 텍스트가 섞이면 파싱이 깨지기 때문이다.

async analyze(market: string, candles1m: Candle[], ...): Promise<LlmDecision> {
  const res = await axios.post(
    `${this.baseUrl}/api/generate`,
    {
      model: this.model,
      prompt,
      stream: false,
      format: 'json',
      options: { num_predict: 200 },
      keep_alive: '30m',
    },
    { timeout: 90000 },
  );
  const parsed = JSON.parse(res.data.response?.trim() ?? '{}');
  const signal = ['BUY', 'SELL', 'HOLD'].includes(parsed.signal ?? '')
    ? parsed.signal
    : 'HOLD';
  return { signal, reason: parsed.reason ?? '' };
}

keep_alive: '30m'을 설정한 이유가 있다. Ollama는 기본적으로 5분 동안 요청이 없으면 모델을 메모리에서 내린다. 5분봉 봇이니까 딱 경계에 걸리는 상황이었고, 모델이 언로드됐다가 재로드될 때 15~20초가 걸려서 타임아웃이 발생했다. 30분으로 늘리고 나서 해결됐다.

TradingService — 봇의 두뇌

@Cron('0 */5 * * * *')으로 매 5분 0초마다 실행된다. 흐름은 단순하다.

보유 포지션이 있으면 각각 손절/목표 체크 후 LLM 판단
빈 슬롯이 있으면 새 종목 탐색 후 매수

@Cron('0 */5 * * * *')
async onCandle() {
  if (!this.running) return;

  if (this.positions.length > 0) {
    await Promise.all(
      this.positions.map((pos) => this.handlePosition(pos)),
    );
  }

  const slots = this.maxPositions - this.positions.length;
  if (slots > 0) {
    await this.fillPositions(slots);
  }
}

포지션 처리 우선순위도 명확하게 설계했다. 손절이 가장 먼저고, 그 다음 최대 목표 초과 시 강제 매도, 마지막으로 LLM 판단이 개입한다.

private async handlePosition(pos: Position) {
  // 1. 손절 체크 (최우선)
  if (pos.profitPercent <= -this.stopLossPercent) {
    await this.executeClose(pos, '손절 실행');
    return;
  }

  // 2. 최대 목표 초과 시 강제 매도
  if (pos.profitPercent >= this.goalProfitMax) {
    await this.executeClose(pos, `최대 목표 수익 달성 (${pos.profitPercent}%)`);
    return;
  }

  // 3. LLM 판단 (최소 목표 이상일 때만 SELL 허용)
  const decision = await this.ollama.analyze(...);
  if (decision.signal === 'SELL' && pos.profitPercent >= this.goalProfitMin) {
    await this.executeClose(pos, 'LLM 매도 신호');
  }
}

REST API — TradingController

봇 제어는 간단한 REST API로 노출했다.

@Controller('bot')
export class TradingController {
  @Post('start')
  start(@Body() body: { goalProfitMin?: number; goalProfitMax?: number; ... }) {
    this.trading.start(body);
    return { message: '봇 시작됨', ...this.trading.getStatus() };
  }

  @Post('stop')
  stop() {
    this.trading.stop('수동 중단');
    return { message: '봇 중단됨', ...this.trading.getStatus() };
  }

  @Get('status')
  status() {
    return this.trading.getStatus();
  }
}

기본값은 .env에서 읽어오고, 요청 body로 오버라이드할 수 있다.

POST <http://localhost:1012/bot/start>
POST <http://localhost:1012/bot/start>  Body: { "goalProfitMin": 3, "goalProfitMax": 7 }
GET  <http://localhost:1012/bot/status>

bot/start 를 호출하면 JSON 데이터로 잘 리턴되는 것을 확인했다.

.env 구성

UPBIT_ACCESS_KEY=발급받은_키
UPBIT_SECRET_KEY=발급받은_키

TRADE_CHECKING_PERIOD=1
TRADE_AMOUNT_KRW=30000
TRADE_MAX_POSITIONS=3
GOAL_PROFIT_PERCENT=3
GOAL_STOP_LOSS_PERCENT=5

OLLAMA_BASE_URL=http://localhost:11434
OLLAMA_MODEL=llama3.2

PORT=1012

.env는 .gitignore에 포함되어 있는지 반드시 확인해야 한다. API 키가 GitHub에 올라가면 바로 악용될 수 있다.

첫 실행

# Ollama 모델 다운로드
ollama pull llama3.2

# 서버 실행
npm run start:dev

타입 오류 없이 서버가 올라왔다. Postman에서 POST /bot/start를 보내면 봇이 시작되고, 다음 5분 0초에 첫 판단이 실행된다.

업비트에 잔고가 없어도 실행은 된다. BUY 신호가 와도 주문하지 않고 로그만 출력하기 때문에 실제 돈을 넣기 전에 LLM이 어떤 판단을 내리는지 먼저 모니터링해볼 수 있다.

잘 시작된다!

정리

이번편에서는 NestJS 모듈 구조 설계, Upbit JWT 인증, Ollama HTTP 연동, Cron 기반 자동 실행까지 기본 뼈대를 완성했다.

다음편에서는 텔레그램 봇 연동으로 스마트폰에서 봇을 제어하고, MongoDB로 매매 이력을 저장하고, LLM 프롬프트를 고도화하는 과정을 다룰 예정이다.

최댓값과 최솟값

Dwony — Mon, 2 Feb 2026 22:56:21 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/12939?language=kotlin

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

Lv2

문자열에서 최댓값과 최솟값을 구하는 문제

~~이게 왜 레벨2??~~

class Solution {
    fun solution(s: String): String {
        val numbers = s.split(" ").map { it.toInt() }
        return "${numbers.minOrNull() ?: 0} ${numbers.maxOrNull() ?: 0}"
    }
}

풀이

풀이 할것도 없다...

코틀린 1.4 이후 버전의 Null 안정성을 기대하면서 minOrNull / maxOrNull을 써봤다.

근데 진짜 js랑 비슷하다.

HashMap의 내부 동작 원리와 시간 복잡도

Dwony — Mon, 2 Feb 2026 22:42:17 +0900

HashMap이 뭔지 확실히 알았다

BST를 공부하다가 HashMap을 비교하는 질문이 나와서 공부하게 됐다.

Key-Value 저장 방식

전화번호부를 떠올려보면 이해하기 쉽다.

이름(Key)  → 전화번호(Value)
"철수"     → "010-1234-5678"
"영희"     → "010-9876-5432"
"민수"     → "010-5555-6666"

사물함에 비유해봤다:

사물함 번호만 알면 바로 찾을 수 있다
다른 사물함을 하나씩 열어볼 필요가 없다

해시 함수라는 게 핵심이었다

해시 함수의 역할을 이해했다

"Key를 숫자로 바꾸는 마법"

Key        해시 함수       숫자(인덱스)
"철수"   ─────────→        3
"영희"   ─────────→        7
"민수"   ─────────→        1

이렇게 하면 배열의 인덱스로 바로 접근할 수 있겠구나 싶었다.

내부가 배열로 되어 있다

HashMap은 내부에 배열을 가지고 있다.

인덱스    저장된 데이터
[0]       (비어있음)
[1]       "민수" → "010-5555-6666"
[2]       (비어있음)
[3]       "철수" → "010-1234-5678"
[4]       (비어있음)
[5]       (비어있음)
[6]       (비어있음)
[7]       "영희" → "010-9876-5432"

배열이니까 인덱스로 바로 접근할 수 있다!

데이터를 저장하는 과정을 따라해봤다

map.put("철수", "010-1234-5678") 하면?

단계별로 확인해봤다:

1단계: 해시 값 계산

int hash = hashCode("철수");  // 예: 12345

2단계: 배열 인덱스 계산

int index = hash % 배열크기;  // 12345 % 16 = 3

3단계: 해당 인덱스에 저장

[3] ← "철수" → "010-1234-5678"

흐름을 그려봤다

"철수" 입력
    ↓
hashCode() 함수
    ↓
12345 (해시값)
    ↓
12345 % 16 = 3 (인덱스)
    ↓
[0] [1] [2] [3] [4] ...
             ↑
        여기 저장!

간단하구나. 해시 계산 → 인덱스 계산 → 저장!

데이터를 찾는 과정도 해봤다

map.get("철수") 하면?

1단계: 똑같이 해시 값 계산

int hash = hashCode("철수");  // 12345
int index = hash % 16;        // 3

2단계: 해당 인덱스에서 바로 가져오기

[3]에 가서 값 가져옴 → "010-1234-5678"

배열이니까 인덱스로 바로 접근! 엄청 빠르다. O(1)!

이래서 HashMap이 빠르구나 이해했다.

문제 상황을 발견했다 - 충돌

해시값이 같을 수 있다

만약 "철수"와 "영수"의 해시값이 같은 인덱스를 가리킨다면?

"철수" → hash → 12345 % 16 = 3
"영수" → hash → 51234 % 16 = 3  ← 똑같은 3번!

둘 다 [3]에 저장하려고 하네? 이게 **충돌(Collision)**이다.

해결 방법 1: Chaining

Java HashMap은 같은 인덱스에 연결 리스트로 연결한다.

[3] → ["철수":"010-1234"] → ["영수":"010-9999"]
      ↑첫번째              ↑두번째

시각적으로 보면:

배열 인덱스
[0]  →  null
[1]  →  null
[2]  →  null
[3]  →  ●──→●──→null
        │    │
     "철수" "영수"
[4]  →  null
...

이렇게 하면 충돌을 해결할 수 있겠구나.

해결 방법 2: 트리로 변환 (Java 8+)

중요한 걸 배웠다. 리스트가 8개 이상 차면 트리로 바꾼다!

리스트 길이 < 8개:  연결 리스트
리스트 길이 ≥ 8개:  Red-Black 트리로 변환

이유를 생각해봤다:

리스트 탐색: O(n) - 느림
트리 탐색: O(log n) - 빠름

시각화:

Before (리스트):              After (트리):
[3] → ●→●→●→●→●→●→●→●        [3] →     ●
     8개 이상...                       /  \
     O(n)                           ●     ●
                                   / \   / \
                                  ●  ●   ●  ●
                                 O(log n)

BST 공부한 게 여기서 도움이 되네!

용량이 부족하면 자동 확장된다

Load Factor라는 개념

HashMap은 너무 꽉 차면 크기를 늘린다.

Load Factor = 저장된 데이터 / 배열 크기

기본값: 0.75 (75%)

확장 과정을 따라해봤다

초기 상태 (크기: 16)

[0] [1] [2] [3] [4] ... [15]
 ●   ●       ●   ●      ●
 
총 12개 저장됨
12 / 16 = 0.75  ← 75%! 임계점 도달!

확장 발동!

1. 새로운 배열 생성 (크기 2배)

기존: 16 → 새로운: 32

2. 모든 데이터를 새 배열로 재배치 (rehashing)

기존 [3]의 "철수"
→ 새로운 해시 계산
→ 12345 % 32 = 13
→ 새 배열의 [13]에 저장

주의할 점: 이 과정은 모든 데이터를 다시 배치하기 때문에 느리다!

시간 복잡도를 정리했다

이상적인 경우 (충돌 없음)

연산 시간 복잡도 설명

put	O(1)	해시 계산 → 인덱스 접근 → 저장
get	O(1)	해시 계산 → 인덱스 접근 → 조회
remove	O(1)	해시 계산 → 인덱스 접근 → 삭제

평균 O(1)! 엄청 빠르다.

최악의 경우 (모두 한 곳에 충돌)

[0]  →  null
[1]  →  null
[2]  →  null
[3]  →  ●→●→●→●→●→●→●→●
        모든 데이터가 여기 모임!
[4]  →  null
...

Java 7 이하:

리스트만 사용 → O(n) (느림)

Java 8 이상:

8개 이상이면 트리로 변환 → O(log n) (괜찮음)

정리

평균: O(1)
최악(Java 8+): O(log n)
최악(Java 7): O(n)

BST와 비교해봤다

HashMap vs TreeMap

특징 HashMap TreeMap

자료구조	해시 테이블	Red-Black 트리
시간 복잡도	O(1)	O(log n)
순서	없음	Key 정렬
null Key	허용	불허
사용 케이스	빠른 조회	정렬/범위 검색

언제 뭘 쓸까?

HashMap을 쓰는 경우:

빠른 조회가 중요할 때
순서가 필요 없을 때

TreeMap을 쓰는 경우:

정렬된 순서가 필요할 때
범위 검색이 필요할 때 (예: 1000원~5000원 상품)

실제로 사용해봤다

Java로 테스트

HashMap<String, String> map = new HashMap<>();
map.put("철수", "010-1234-5678");
map.put("영희", "010-9876-5432");

System.out.println(map.get("철수"));  // "010-1234-5678"

바로 찾아진다. 빠르다!

초기 용량 설정

1000개를 저장할 거라면?

예상 데이터: 1000개
초기 용량: 1000 / 0.75 = 1333 → 1500으로 설정

HashMap<Integer, String> map = new HashMap<>(1500);

이렇게 하면 rehashing 횟수를 줄일 수 있다.

핵심 요약

학습하면서 정리한 핵심:

HashMap = 배열 + 해시 함수 + 충돌 처리
평균 O(1)의 빠른 성능
충돌 발생 시: 리스트 → 8개 이상이면 트리
75% 차면 자동으로 2배 확장
빠른 조회가 필요하면 HashMap, 정렬이 필요하면 TreeMap

동작 흐름 정리

Key 입력
   ↓
해시 함수 (Key → 숫자)
   ↓
배열 인덱스 계산
   ↓
저장/조회 (O(1))
   ↓
충돌 발생? → 리스트/트리로 해결

장단점

장점:

✅ 평균 O(1)의 빠른 성능

✅ Key로 직접 접근 가능

✅ 구현이 비교적 간단

단점:

❌ 순서 보장 안 됨

❌ 해시 충돌 발생 가능

❌ Resize 시 성능 저하

❌ 메모리 오버헤드 (Load Factor로 인한 빈 공간)

실무에서의 경험

커머스 프로젝트에서 상품 정보를 빠르게 조회하는 기능을 만들 때 HashMap을 사용했다. 상품 ID를 Key로 하고 상품 객체를 Value로 저장해서 O(1)에 조회할 수 있었다.

다만 가격 범위로 필터링하는 기능은 데이터베이스의 B-Tree 인덱스를 사용했다. HashMap으로는 범위 검색이 어려워서 그런 경우에는 BST 계열이 더 적합하다는 걸 배웠다.

면접에서 이런 실무 경험을 같이 설명하면 좋을 것 같다!

이진 탐색 트리(BST)와 균형 이진 탐색 트리

Dwony — Mon, 2 Feb 2026 22:31:09 +0900

트리(Tree)부터 이해하기

면접 준비하면서 BST를 공부하게 됐는데, 트리가 뭔지는 알고 있었지만 기초개념부터 정리했다.

트리가 뭔지?

가계도를 떠올려보니 이해가 쉬웠다.

      할아버지
     /      \
  아버지      삼촌
  /  \      /  \
나  동생   사촌1 사촌2

트리 용어들을 정리해봤다:

루트(root): 최상위 노드 (할아버지)
부모(parent): 바로 위 노드
자식(child): 바로 아래 노드
잎(leaf): 자식이 없는 노드
높이(height): 루트에서 가장 먼 잎까지의 거리

이진 트리는 뭔가?

이진 = 두 갈래. 각 노드가 최대 2개의 자식만 가질 수 있다.

이진 탐색 트리(BST) 공부하기

BST의 핵심 규칙을 알게 됐다

왼쪽 < 부모 < 오른쪽

이 규칙만 지키면 이진 탐색 트리다.

    50
   /  \
 30    70
 /\    /\
20 40 60 80

모든 노드에서:

왼쪽 자식이 자기보다 작고 (30 < 50)
오른쪽 자식이 자기보다 크다 (70 > 50)

왜 이렇게 만드는지 이해했다

60을 찾는다고 가정해봤다.

    50  ← 60 > 50이니까 오른쪽으로!
   /  \
 30    70  ← 60 < 70이니까 왼쪽으로!
 /\    /\
20 40 60 80  ← 찾았다!
     ↑

3번만에 찾았다!

만약 그냥 배열이었다면?

[50, 30, 70, 20, 40, 60, 80]
 1   2   3   4   5   6번째!

6번을 봐야 찾는다.

이래서 BST를 쓰는구나 싶었다.

문제 상황을 발견했다

1, 2, 3, 4, 5를 순서대로 넣어봤다

과정을 하나씩 따라가봤다:

1 넣기

2 넣기 (2 > 1이니까 오른쪽)

1
 \
  2

3 넣기 (3 > 1, 3 > 2니까 계속 오른쪽)

4, 5까지 넣으니...

이게 뭐지? 그냥 일렬로 늘어선 거랑 똑같잖아!

문제가 뭔지 깨달았다

5를 찾으려면?

1 → 확인 (아님)
 \
  2 → 확인 (아님)
   \
    3 → 확인 (아님)
     \
      4 → 확인 (아님)
       \
        5 ← 찾았다! (5번 확인)

5번을 다 봐야 한다. 트리의 장점이 완전히 사라졌다.

이게 **Skewed Tree(치우친 트리)**라는 걸 알게 됐다.

해결책: 균형 트리

같은 데이터를 균형있게 배치하면

똑같은 1, 2, 3, 4, 5를 이렇게 배치할 수 있다:

5를 찾으려면?

    3  ← 5 > 3, 오른쪽!
   / \
  2   4  ← 5 > 4, 오른쪽!
 /     \
1       5  ← 찾았다! (3번 확인)

3번만에 찾는다!

성능 차이를 계산해봤다

1000개가 있다면?

치우친 트리: 최악의 경우 1000번
균형 트리: 약 10번

100배 차이! 이래서 균형이 중요하구나.

균형을 어떻게 맞출까? - 회전(Rotation)

회전이라는 개념을 배웠다

오른쪽으로 치우친 상황:

이걸 왼쪽 회전하면:

  2
 / \
1   3

균형잡힌 트리가 됐다!

시각적으로 보면:

Before:          After:
  1                2
   \              / \
    2     →      1   3
     \
      3

2를 중심으로 왼쪽으로 돌린 것처럼 보인다.

실제로 따라해봤다

1, 2, 3을 순서대로 넣으면서 균형 맞추기:

1단계: 1 넣기

균형: ✓

2단계: 2 넣기

1
 \
  2

균형: ✓ (높이 차이 1까지는 괜찮음)

3단계: 3 넣기 → 치우침 발견!

삽입 직후:
1
 \
  2
   \
    3  ← 불균형!

즉시 회전:

회전 후:
  2
 / \
1   3

균형: ✓

이렇게 삽입할 때마다 자동으로 균형을 맞춘다는 걸 이해했다.

일반 BST vs 균형 BST 정리

핵심을 깨달았다

결국 형태의 차이다.

같은 데이터 1, 2, 3, 4, 5를 넣어도:

일반 BST (최악):    균형 BST:
    1                   3
     \                 / \
      2               2   4
       \             /     \
        3           1       5
         \
          4        높이: 3
           \       탐색: O(log n)
            5
            
높이: 5
탐색: O(n)

시간 복잡도를 비교했다

일반 BST

연산 평균 최악

탐색	O(log n)	O(n)
삽입	O(log n)	O(n)
삭제	O(log n)	O(n)

최악: 한쪽으로 치우쳤을 때

균형 BST

연산 평균 최악

탐색	O(log n)	O(log n)
삽입	O(log n)	O(log n)
삭제	O(log n)	O(log n)

핵심: 최악의 경우에도 O(log n) 보장!

대표적인 균형 BST들

여러 종류가 있다는 걸 알게 됐다.

AVL 트리

가장 엄격하게 균형을 유지한다.

규칙:

모든 노드에서 왼쪽-오른쪽 서브트리의 높이 차이가 최대 1

장점:

탐색이 가장 빠르다

단점:

삽입/삭제 시 회전이 많이 일어날 수 있다

Red-Black 트리

AVL보다 조금 느슨하지만 효율적이다.

규칙:

모든 노드는 Red 또는 Black
루트는 Black
Red 노드의 자식은 반드시 Black
모든 경로의 Black 노드 개수 동일

실무에서 많이 쓰인다고한다:

Java의 TreeMap
C++의 map

장점:

삽입/삭제가 AVL보다 빠르다
실전에서 유용하다

단점:

탐색은 AVL보다 약간 느리다

B-Tree

데이터베이스 인덱스에서 사용한다.

특징:

한 노드에 여러 개의 키 저장
트리 높이가 낮다
디스크 I/O를 최소화한다

일반 BST:            B-Tree:
  50                [30, 50, 70]
 /  \              /    |   |   \
30  70         [10,20] [40] [60] [80,90]

B-Tree가 한 번에 더 많은 데이터를 읽을 수 있다.

실무에서는 어떻게 쓸까?

일반 BST는 거의 안 쓴다

이유:

최악의 경우 O(n)으로 너무 느리다
성능을 예측할 수 없다

균형 BST를 쓰는 경우

1. 정렬된 순서가 필요할 때

Java로 해봤다:

TreeMap<Integer, String> map = new TreeMap<>();
map.put(3, "three");
map.put(1, "one");
map.put(2, "two");
// 자동으로 1, 2, 3 순서로 정렬됨

2. 범위 검색이 필요할 때

// 1000원~5000원 사이 상품 찾기
map.subMap(1000, 5000);

3. 최대/최소를 빠르게 찾아야 할 때

map.firstKey();  // 최소값
map.lastKey();   // 최대값

실제 경험

커머스 시스템을 만들 때 상품 가격 범위로 필터링하는 기능이 있었다. 데이터베이스가 내부적으로 B-Tree 인덱스를 사용해서 빠르게 조회할 수 있었다.

Trade-off를 생각해봤다

균형 BST의 장점

✅ 최악의 경우에도 O(log n) 보장

✅ 성능이 예측 가능하다

✅ 정렬된 순서를 유지한다

✅ 범위 검색이 가능하다

균형 BST의 단점

❌ 구현이 복잡하다 (회전, 색 관리 등)

❌ 삽입/삭제 시 재균형 비용이 든다

❌ 추가 메모리가 필요하다 (색 정보, 높이 정보)

❌ 단순 검색만 필요하면 HashMap이 더 빠르다 (O(1))

결론

실무에서는 직접 구현하지 말고 라이브러리를 쓰자:

Java: TreeMap, TreeSet
Python: sortedcontainers
C++: map, set

핵심 요약

학습하면서 정리한 핵심:

일반 BST vs 균형 BST = 형태 차이
치우친 형태 → O(n), 균형 형태 → O(log n)
회전으로 즉시 균형 유지
실무에서는 라이브러리 사용
정렬/범위 검색이 필요하면 균형 BST, 단순 검색이면 HashMap