step3. Phase 1. 무중단 시스템 인프라 구축 (2) - TroubleShooting
NAS 인프라 구축 중 마주친 3가지 치명적 에러와 해결책
화려한 아키텍처 이면에는 언제나 뼈아픈 시행착오가 존재합니다. 시놀로지 NAS 기반 퀀트 시스템(Docker, 역방향 프록시, SSL, DB)을 세팅하며 겪은 삽질의 기록과 필수 생존 노하우를 공개합니다.
설계도(Architecture)를 그릴 때는 모든 데이터가 물 흐르듯 완벽하게 통신할 것 같지만, 막상 실서버에 인프라를 올리다 보면 예상치 못한 곳에서 에러 로그가 쏟아집니다. 앞선 포스팅에서 소개한 '나만의 AI 퀀트 인프라'를 시놀로지 DS224+에 세팅하면서 직접 몸으로 부딪히며 해결한 핵심 트러블슈팅(Troubleshooting) 사례 3가지를 공유합니다.
시스템 트레이딩을 위해 개인 서버를 구축하려는 분들이라면 무조건 한 번쯤 마주치게 될 함정들이니, 이 글을 통해 삽질하는 시간을 며칠은 단축하시길 바랍니다.
💣 소리 없는 암살자, 도커 로그(Docker Log)
데이터를 수집하는 파이썬(Python) 데몬이나 매매 신호를 쏘는 Java 서버를 Docker Container로 띄우고 "잘 돌아가네!" 하고 방치했다가 며칠 뒤 갑자기 생각이난 '도커 컨테이너 로그'였습니다. 역시나 확인했을때 Log 설정을 하지않은걸 확인. Log가 끝도 없이 쌓일뻔한 아찔한 순간이었습니다. 초 단위, 분 단위로 시세를 가져오는 봇의 특성상 로그가 며칠 만에 수 기가바이트(GB)를 갉아먹으며 디스크 공간을 점령할뻔한 것입니다.
Docker의 기본 로깅 드라이버는 파일 크기 제한이 없습니다. 이를 해결하기 위해 docker-compose.yml 파일에 로그 로테이션(Log Rotation) 설정을 강제로 주입해야 합니다.
services: datacollectpy: # ... 기존 이미지 및 포트 설정 생략 ... logging: driver: "json-file" options: max-size: "30m" # 로그가 30MB에 도달하면 분할 max-file: "7" # 최대 7개의 파일(210MB)만 유지하고 오래된 것 삭제
이 단 4줄의 코드를 넣고 컨테이너를 재시작한 이후부터는 디스크 용량 압박에서 완벽하게 해방될수있습니다. 퀀트 시스템 구축 시 선택이 아닌 필수 생존 세팅입니다.
🌐 서브도메인, 역방향 프록시, 그리고 무한 리디렉션의 늪
API 서비스를 위해 서브도메인 api.jajaksystem.co.kr 인증을 위한 auth, 대시보드 접근을 위한 visit 등 다양한 서브도메인을 NAS 내부의 각기 다른 포트(Docker, VM 등)로 연결해야 했습니다. 사용중인 인터넷회사의 공유기에 접속하여 포트포워딩 설정과 시놀로지의 '역방향 프록시(Reverse Proxy)'를 활용해 라우팅을 구성했는데, 외부망에서 접속 시 HTTPS 인증서 오류가 나거나 접속이 무한 루프(ERR_TOO_MANY_REDIRECTS)에 빠지는 현상이 발생했습니다.
- 1. 대상 포트 일치화: 역방향 프록시 설정 시, 소스(외부)는 HTTPS(443)로 받되, 대상(내부 NAS)은 컨테이너가 실제로 열어둔 포트(예: HTTP 8080)로 정확히 꽂아주어야 합니다. 대상을 무작정 HTTPS로 넘기면 컨테이너 내부 웹서버가 처리하지 못해 에러를 뱉습니다.
- 2. 와일드카드 인증서 vs 개별 인증서: Let's Encrypt를 통해 SSL 인증서를 발급받을 때, 서브도메인이 늘어날 때마다 새로 발급하는 대신
*.jajaksystem.co.kr형태의 와일드카드 인증서를 적용하여 하나로 통합 관리하는 것이 인증서 만료 및 갱신 에러를 막는 지름길이라고 하지만... 여러번의 시도에도 알수없는 이유로 계속 설정 실패하여.. 치명적인 오류도 아닌 단순 설정문제이니 그냥 개별 인증서를 사용해서 해결. 원인파악에 많은 시간을 투자하였지만. 해결되지않아 깔끔하게 포기하였습니다. - 3. DNS 전파의 인내심: 도메인 DNS 레코드(CNAME 등)를 수정한 직후 접속이 안 된다고 설정을 계속 바꾸면 오히려 캐시가 꼬입니다. 설정 후에는 시크릿 모드나 모바일 LTE망으로 확인하며 최소 10~30분은 기다리는 '인내심'이 최고의 트러블슈팅이었습니다.
🧠 '과유불급' 리소스 할당의 함정과 VM 프리징
16GB RAM을 추가 증설해 총 18GB의 넉넉한 하드웨어를 갖췄다는 자신감에 치명적인 실수를 저질렀습니다. AI 에이전트 구동을 위해 Rocky Linux 가상머신(VM)을 띄우면서, 성능을 극대화하겠다는 욕심에 CPU 코어 3개, 메모리 8GB를 통 크게 할당한 것이 화근이었습니다. VM을 부팅하고 OpenClaw Gateway 세팅 후 텔레그램으로 첫 대화를 시도하는 순간, NAS의 CPU와 RAM 점유율이 90%를 뚫고 솟구치며 전체 서비스가 완전히 멈춰버리는 '프리징(Freezing)' 현상이 발생했습니다.
범인은 물리적 스펙 부족이 아닌 '자원 분배 실패(Over-provisioning)'였습니다. Synology DS224+의 두뇌인 인텔 셀러론 J4125는 쿼드코어(4코어) 프로세서입니다. VM에 코어 3개를 고정으로 줘버리니, NAS의 메인 운영체제(DSM)와 쉼 없이 돌아가는 무수한 Docker 컨테이너(MariaDB, 데이터 수집 데몬 등)들이 남은 '단 1개의 코어'를 두고 피 터지게 싸우며 엄청난 병목이 발생한 것입니다.
이를 해결하기 위해 VM의 자원 할당을 CPU 2코어, RAM 6GB로 다이어트(최적화)시켰습니다. 호스트 OS와 Docker 컨테이너들이 숨 쉴 공간(여유 코어 2개 및 넉넉한 메모리)을 확실하게 보장해 주자, OpenClaw가 무거운 응답을 처리할 때도 NAS 전체 시스템이 멈추는 일 없이 쾌적하게 돌아가기 시작했습니다. 무중단 인프라 구축에서 가장 중요한 것은 특정 봇에 자원을 몰아주는 것이 아니라, '시스템 전체의 밸런스'를 맞추는 것임을 뼈저리게 배웠습니다.
단단한 토대 위에 AI를 올릴 시간
지금까지 비용과 효율을 모두 고려한 온프레미스 인프라를 구축하며 겪은 주요 시행착오들을 정리해 보았습니다. 인프라 세팅은 눈에 보이는 화려한 결과물은 없지만, 이 과정에서 포트를 열고, 보안을 강화하고, 디스크를 관리하며 다져진 지식들은 훗날 퀀트 시스템에 문제가 생겼을 때 스스로 고칠 수 있는 강력한 무기가 됩니다.
지반 공사와 배수관 공사가 끝났으니, 이제 이 튼튼한 요새 위에 본격적으로 '지능(Intelligence)'을 탑재할 차례입니다. 다음 포스팅에서는 이 독립된 환경에 에이전트(OpenClaw)를 설치하고 LLM과 연동하는 흥미진진한 과정을 다루겠습니다.
