🧩 비트코인 프로젝트 회고
기획
🎯 프로젝트 목표
- 목표:
- 새로 고침 시간을 기준으로 해당 날의 1시간 단위 시세를 예측
- 코인별 모델을 사용해 가격 변동 차이 고려
- 예측할 코인
- 비트코인(KRW-BTC)
- 도지코인(KRW-DOGE)
- 이더리움(KRW-ETH)
- 리플(KRW-XRP)
- 예측할 코인
- 예측 결과를 웹 UI에서 직관적으로 확인 가능
- 핵심 포인트
- 단기 예측(1시간 단위) → 단기 트레이딩
- 코인별 맞춤 모델 → 가격 단위, 변동성 차이 반영
- 자동화 → 매일 00시 학습 및 예측
💾 데이터
- 데이터 소스: 업비트
- 데이터 기간: 예측 기준 시간 이전 24시간 데이터
- 주요 컬럼
| 컬럼명 | 의미 | 비고 (추가 설명) |
|---|---|---|
market | 마켓 구분 | KRW-BTC → 원화(KRW)로 비트코인 거래 |
예: KRW-BTC, KRW-ETH 등 | ||
trade_date | 거래일자 (UTC 기준) | YYYYMMDD |
trade_time | 거래시간 (UTC 기준) | HHMMSS |
trade_date_kst | 거래일자 (KST, 한국시간) | YYYYMMDD |
trade_time_kst | 거래시간 (KST, 한국시간) | HHMMSS |
trade_timestamp | 거래 체결 시각 (UTC, ms 단위) | Unix timestamp (밀리초) |
opening_price | 당일 시가 | 하루 시작 가격 |
high_price | 당일 고가 | 하루 중 최고 거래 가격 |
low_price | 당일 저가 | 하루 중 최저 거래 가격 |
trade_price | 최근 거래 체결가 | |
| 해당 봉의 종가(Close price) | 현재/마지막 체결된 가격 | |
| 1시간 내 마지막 거래 가격 | ||
prev_closing_price | 전일 종가 | 어제 마지막 거래 가격 |
change | 전일 대비 등락 | RISE, FALL, EVEN |
change_price | 전일 대비 가격 차이 | (오늘가 - 전일 종가) |
change_rate | 전일 대비 등락률 | |
| 전 봉 대비 수익률(변동률) | 퍼센트(소수) | |
(현재 종가 / 이전 종가) - 1 | ||
signed_change_price | 부호 포함 가격 차이 | 양수(상승), 음수(하락) |
signed_change_rate | 부호 포함 등락률 | 양수(상승), 음수(하락) |
trade_volume | 최근 체결 거래량 | 해당 거래 건의 수량 (BTC 단위) |
acc_trade_price | 누적 거래대금 (당일) | 원화 기준 합계 |
acc_trade_price_24h | 24시간 누적 거래대금 | 직전 24시간 동안 원화 거래총액 |
acc_trade_volume | 누적 거래량 (당일) | BTC 기준 합계 |
| 단위: 해당 코인 기준, 예: BTC면 BTC 수량 | ||
acc_trade_volume_24h | 24시간 누적 거래량 | 직전 24시간 동안 BTC 거래총액 |
highest_52_week_price | 52주 최고가 | 최근 1년간 최고 가격 |
highest_52_week_date | 52주 최고가 기록일 | 날짜(YYYY-MM-DD) |
lowest_52_week_price | 52주 최저가 | 최근 1년간 최저 가격 |
lowest_52_week_date | 52주 최저가 기록일 | 날짜(YYYY-MM-DD) |
timestamp | 서버 응답 시각 (ms 단위) | API 호출 기준 시간 |
1시간봉 기준 시각, KST로 변환됨 (candle_date_time_kst) |
🛣️ 데이터 수집 파이프라인
- 10초 마다 수집
- 응답값 파싱
- 파싱 불가 또는 없을시 None 처리
- 10분 마다 파일로 저장
- parquet 형식으로 저장
- 1시간 마다 s3 업로드
- upbit-ticker/yyyy-mm-dd/ 폴더 하위에 일별로 저장
- 배포
- ec2 - t3.중간
- docker container 기반
My Task (self feedback)
🏛️ Modeling
LSTM 구축을 하는 식으로 진행을 했으나, 기간상 너무 짧은 느낌이 있어서 더 많은 모델을 개발해보고 있었는데, 이 부분이 아쉬웠습니다. 또한 제가 만든 초안의 코드의 성능이 너무 낮아서 아쉬웠습니다. 또한 모델링을 하는 시간 자체가 좀 짧았던 느낌이라 뭔가를 딥하게 알아보지 못했던 것도 아쉬웠습니다.
🔙 FastAPI
일단 이 부분은 정확하게 말을 할 수 있는게 구현 과정에서는 프로젝트 후반부였기 때문에 개인적으로 느슨해진 감이 있었습니다. 이러한 부분으로 인해서 해당 부분에서 문제가 될 수 있는 부분에 대해서 어느정도는 예측을 했지만, 시간 관계상 못했다라는 생각을 했던 것 같습니다. 프로젝트 종료 이후라고 해당 부분을 수정을 해서 좀 더 좋은 결과물이 될 수 있게 수정을 해야겠다는 생각이 들었습니다.
⚒️ Streamlit
이 부분 같은 경우에는 코드를 리팩토링을 하지 못한 부분이 좀 아쉬웠습니다. 거의 모든 기능이 바이브 코딩으로 만들어 졌었기 때문에 모든 부분을 이해하면서 리팩토링 하는 것이 쉽지 않았고, 이러한 경험을 통해서 모든 기능을 바이브 코딩에 의존하면 이후 코드 리팩토링 부분에서 에러 사항이 생길 수 있다는 부분을 느꼈습니다. 당연히 하는 당시에도 알고 있었지만 빠른 결과물을 원했기 때문에 이렇게 했는데, 다음부터는 바이브 코딩을 하더라고 코드를 이해하는 과정을 추가해야겠습니다.
😲 Total
전체적으로 초반에서 후반부로 갈 수록 의욕이 떨어졌던 것 같습니다. 왜 이렇게 되었나를 생각해보니 툴 공부를 하는 부분에 취중을 하다보니까 이미 끝난 작업들이라는 생각에 다시 돌아보거나 수정할 생각을 하지 않았던 것 같습니다. 이런 부분에서도 반성을 좀 많이 하게 되는 것 같습니다. 다시 착실하게 살아가기 위해 마음가짐을 다시 먹는 프로젝트인 것 같습니다.
Feedback
1) Fast API 구조가 잘못되었다.
멘토님 피드백에서 가장 크게 반성을 했던 부분입니다. 위에서 얘기 했드시 해당 문제는 어느정도는 느끼고 있었습니다. 바로 FastAPI에 모델을 로드하고 예측하게 구현을 한 것입니다. 이렇게 되면 모델을 주기적으로 로드를 하기 때문에 서버에 부화가 과하게 들어오기 때문에 서비스적으로 문제가 있습니다. FastAPI는 추론하는 곳이아니라 서빙을 하는 곳이기 때문에 이 부분에 대해서 수정이 필요하다고 하셨습니다.
2) CI/CD 간의 yaml 구조가 이슈가 있다.
이 부분의 경우에는 github action ci/cd를 구축하는 과정에서 보안그룹을 임시로 추가하고 작업 이후에 제거하는 부분이 있었습니다. 이 부분의 경우에는 작업중에 문제가 발생하면 롤백이 구현되어 있지도 않았으며, 추가로 이러한 보안그룹 임시 추가보다는 IAM 인증 기반으로 하는것이 좋다고 피드백 해주셨습니다. action template store(?)에 해당 기능이 구현되어있는 템플릿이 있으니까 그걸로 적용하면 된다고 하셨습니다. 이 부분 피드백을 받으면서 확실히 다 아시는구나라고 느꼈던 부분이 실제로 액션 작동중에 오류가 생기면 보안그룹에 IP그 그대로 남아있는 문제가 있었습니다. 이 부분은 액션 동장간에 문제가 발생하지 않을 것이다라는 전제를 깔고 갔었기 때문에 따로 작업을 하지 않았었는데, 이러한 부분에서도 반성을 했었습니다.
