서론개발자로 살아남기 위해서 개인 포트폴리오 관리는 필수적이라고 생각한다. 글을 시작하기에 앞서 본 글은 '어떻게 포트폴리오를 작성하느냐'가 아닌, '어떻게 홈서버에 안전하고 편리하게 배포할까'를 중심으로 서술하였음을 미리 안내한다. 필자는 취업 준비를 하며 포트폴리오를 처음 만들었고, 그 이후로는 단 한 번도 유지보수한 적이 없었다.그런 의미에서, 처음 홈서버 및 도메인을 구매할 때 상상만 하였던 것을 이번 글을 통해 실제로 만들어보고자 한다. 다만 필자는 백엔드 개발자이니만큼, 포트폴리오 디자인에 집착하기보다는안정적인 배포 파이프라인 구성 및 홈서버 인프라 세팅을 중심으로 하여 다뤄보고자 한다. 참고로 포트폴리오는 Astro 프레임워크의 템플릿을 통해 만들었다.디자인을 비롯한 프론트엔드 성능 최적화는..

서론현재 Proxmox OS 기반의 홈서버를 구축하여 아래처럼 서비스들을 운용하고 있다. 기본적으로 헤놀로지(XPEnology) NAS를 중심으로 하여 각 서비스들을 사용하는 구조이다. 현재 서비스들은 헤놀로지의 공유 폴더를 Proxmox OS로 마운트 한 뒤,해당 마운트 디렉토리를 다시 각 VM, LXC 컨테이너 내부로 연결하여 사용하는 구조이다. 일례로, Dockge LXC 컨테이너 내부에 Immich(사진 관리 서비스)는 다음과 같은 흐름으로 구성된다.XPEnology Volume → Proxmox Mount → Dockge Mount → Immich Container Volume 대충 아래같은 그림이라고 생각하면 되겠다. 위와 같은 구조를 설계하는 와중 지속적으로 겪은 문제가 존재하는데,마운트 된..

서론드디어 서버가 도착했다.25.08.21에 구매하고 25.09.23에 수령하였으니, 거의 한 달이 걸린 셈이다. 참고로 사용할 서버의 스펙은 다음과 같다.베어본 : AOOSTAR WTR PRO AMD Ryzen 7 5825u 4 Bay Nas Mini PCRAM : PUSKILL DDR4 16GB 3200 x 2 pcs, 총 32GBSSD : Western Digital WD BLACK SN850X M.2 NVMe 1TBHDD : Western Digital WD RED 5400/64M 2TB x 4, 총 8TBHDD는 거의 새것과 같은 중고로 구매해서 총 60만 원 정도 들었다. 이제 실제 사용할 서비스들을 올릴 건데,서비스를 올리기에 앞서 외부(WAN) 접근을 고려하여 방화벽을 먼저 설정하고자 한다..

서론지난 글과 지지난 글을 통해 자동매매의 기본적인 틀을 잡았다면, 이를 최적화하는 옵티마이저를 만들어보고자 한다.Scheduler (Celery Beat) : 주기적으로 작업을 트리거Redis : 메시지 브로커Collector : 시세(분봉) 데이터를 수집하여 DB에 적재Trader : 전략에 따라 매수/매도 시그널을 실행Optimizer : 전략 파라미터(가중치 등)를 백테스트하여 최적화Database (TimescaleDB) : 시계열 데이터 저장소 원래는 서버 세팅 글부터 쓰려했는데 주문한 모델이 잘못 배송돼서 교환 중이다.그래서 미뤄두었던 자동매매 봇 개발을 우선 마무리지으려고 한다. 참고로 누가 볼 진 모르겠으나, 현재까지 개발된 코드는 아래 깃허브에서 확인할 수 있다. GitHub - big..

서론최근 구매한 서버의 인프라 세팅을 위해 자료들을 조사 중, 아래와 같은 글을 발견하였다.물론 아직 서버가 도착한 건 아니다. 분명 반송한 게 도착했다곤 하는데 언제 보내줄련지 모르겠다 상기 글에 워낙 잘 정리가 되어 있다 보니 혹여 관심있는 사람들도 그대로 따라 해도 무방할 것 같다. 다만 해당 구성에서 좀 꺼려졌던 부분은 이미지와 같이 구성할 경우 Proxmox GUI가 외부로 노출된다는 점이다.물론 ID, PW 혹은 2FA 인증 등을 설정할 수 있으나 어찌 되었든 외부로 공격 포인트가 노출된다는 점에서 좀 꺼려졌다. 그래서 내가 보완하려 한 구조는 pfSense 방화벽으로 모든 트래픽을 1차 검증하고,검증된 트래픽에 한해서만 서버 및 서비스에 접근할 수 있도록 하는 방식으로 보완하고자 하였다. ..

서론지난 글에 이어 이번에는 본격적인 인프라 설정 및 자동매매의 기본 플로우를 구현해보고자 한다. 본론1. 인프라 구축자동매매 시스템의 전반적인 파이프라인은 다음과 같은 구성요소들로 이루어져 있다.Scheduler (Celery Beat) : 주기적으로 작업을 트리거Redis : 메시지 브로커Collector : 시세(분봉) 데이터를 수집하여 DB에 적재Trader : 전략에 따라 매수/매도 시그널을 실행Optimizer : 전략 파라미터(가중치 등)를 백테스트하여 최적화Database (TimescaleDB) : 시계열 데이터 저장소 전체 컴포넌트들과 그 사이의 데이터 흐름을 도식화해 보면 아래와 같다. 스케쥴러가 주기적으로 작업들을 트리거하고 각 워커들이 작업을 수행하는 매우 간단한 구성이다. 사실..

서론필자는 암호화폐(이하 코인)에 대해 무지하다. 그리고 지금도 마찬가지이다. 그럼에도 불구하고 암호화폐 자동매매 봇을 개발하고자 하는 이유는 단순하다.최근 개인용 서버를 구매하였는데, 여기에 돌릴만한 게 없나 하고 찾아보다가 자동매매 봇을 떠올렸기 때문이다.사실 개인 NAS용으로 구매하려 한 건데, '그돈씨' 하다 보니까 스펙이 생각보다 높아졌다 서버는 24시간 돌아가니, 24시간 시장이 열려 있는 코인과는 궁합이 맞지 않겠는가.그래서 전지전능하신 ChatGPT님과 Cursor님의 도움을 받아 자동매매 봇 개발에 뛰어들게 되었다. 본론어떤 전략을 활용해야 하는가?앞서 언급한 것처럼 코인에 대해 무지한 상태에서 뛰어들다 보니, 어떤 전략을 선택할지가 가장 고민이었다.아는 게 없다 보니 강의나 책을 구매..

서론Django REST Framework를 사용하면서 filterset_class를 설정하고 필터링을 적용하는 건 매우 흔한 일이다. 필터셋을 통해 URL 파라미터만으로 복잡한 조건 필터링을 쉽게 구현할 수 있고, django-filter 라이브러리를 활용하면 필드 단위, 메서드 단위로 커스텀 필터도 자유롭게 정의할 수 있다. 필자 또한 filterset_class에 커스텀 메서드를 정의하여 필터링을 적용했다.하지만 API 성능을 점검해보는 과정에서, 단일 응답에 수백 개의 SQL 쿼리가 발생하는 문제를 발견했다.해당 문제를 아래 흐름으로 살펴보며 구체적인 원인을 파악해보고자 한다.filterset은 정확히 어떤 시점에 동작하는가?filterset 내부에서 Model.objects.filter()를 ..

서론DRF(Django REST Framework)를 사용하여 개발을 할 때, 시리얼라이저를 커스텀하는 것은 빈번한 일이다.나 또한 마찬가지로 개발을 진행하던 중 DRF 시리얼라이저를 커스텀하였는데, 예상과 다른 동작이 일어났다. 입력값은 엑셀 파일에서 단일 행으로 제공되고, 이를 여러 모델로 정규화하여 나누는 과정에서 문제가 발생하였다. 보다 구체적으로 설명하면, A 시리얼라이저는 B, C, D, E라는 네 개의 모델 시리얼라이저를 포함하며,B 모델은 F 모델을 외래키로 참조하고 있는 상황이다. 이러한 구조 때문에 A 시리얼라이저의 입력값은 프리픽스를 활용해 각 모델로 분류하여 처리하도록 구현하였다.class BSerializer(serializers.ModelSerializer): f_ids =..

서론Django를 통해 WAS 서버를 구성하다 보면 당연시하며 사용하는 것이 있다. 바로 'request(요청)' 객체가 이에 해당된다.너무나도 당연시하며 사용하곤 있었지만 어떻게 이 'request' 객체가 생성되는지 흐름을 알고 있진 못하였다. 따라서 본 글에서는 WSGI 서버와 Django(장고) 사이에서 어떻게 'request' 객체가 생성되고,비즈니스 로직이 담겨있는 뷰(View)를 거쳐 'response(응답)' 객체로 반환되는지를 알아보고자 한다. 본론중국의 딥시크(R1) 모델의 발표로 인해 그 위상이 약간은 추락하신 Chat GPT 님께 자문을 구하였다.Django에서 클라이언트의 요청이 들어와 실제 뷰(View)에 전달되기까지의 흐름을 간단히 요약하면 아래와 같습니다.1. 클라이언트 (..