docker (8) 썸네일형 리스트형 Claude Desktop과 VSCode에 n8n MCP 서버 연결하기 AI 개발 환경에서 워크플로우 자동화 도구인 n8n을 활용하기 위해 Model Context Protocol(MCP) 서버를 Claude Desktop과 VSCode에 연결하는 방법을 상세히 알아보겠습니다. 두 환경의 설정 방식이 다르므로 각각의 특징과 해결 과정을 설명하겠습니다.MCP와 n8n이란? Model Context Protocol(MCP)는 AI 모델이 외부 도구와 서비스에 접근할 수 있도록 하는 개방형 표준입니다.오늘 다룰 n8n은 시각적 워크플로우 자동화 플랫폼으로, 다양한 서비스를 연결하여 복잡한 자동화 작업을 수행할 수 있습니다.n8n MCP 서버를 통해 다음과 같은 기능을 AI 환경에서 직접 사용할 수 있습니다:525개의 n8n 노드 검색 및 탐색워크플로우 템플릿 검색 및 다운로드노드.. AWS EC2에서 Docker 컨테이너의 스토리지 동작 원리 완전 분석 지난 포스팅에서 AWS EC2 인스턴스에 Docker를 설정하고 인스턴스 스토어를 활용하는 방법을 다뤘습니다. 오늘은 한 단계 더 나아가 Docker 컨테이너가 실제로 어떤 스토리지를 사용하는지, 그리고 각 디스크별 역할과 데이터 저장 경로를 실험을 통해 상세히 분석해보겠습니다. EC2 인스턴스의 스토리지 구성 이해하기각 디스크와 파티션 정리EC2 인스턴스에서 사용되는 스토리지를 정확히 이해하는 것이 중요합니다. 흔히 헷갈리는 /dev/root와 실제 EBS 디스크의 관계부터 살펴보겠습니다.# 루트 파티션이 실제로 어떤 장치에 마운트되었는지 확인findmnt -T /# 모든 블록 디바이스 확인lsblk# 모든 마운트된 파일시스템 확인 (EFS 포함)df -hT핵심 포인트/dev/root는 부팅 시점에 커.. AWS 인스턴스 스토어(ephemeral0)로 EBS 용량 한계 극복하기 지난 글에서 "이 모델이 진짜 8GB 디스크 환경에서 돌아갈 수 있을까"에 대한 실험을 진했했습니다.결론은 Stable Diffusion API 컨테이너를 돌리려면 최소 20~30GB 이상 여유가 필요하다는 점이었습니다.문제는 EBS를 크게 잡으면 비용이 올라간다는 것이죠.그런데 AWS에서 이미 무료로 제공하는 디스크 공간이 있다는 사실, 알고 계셨나요?바로 인스턴스 스토어(Instance Store), 여기서는 ephemeral0라는 이름으로 나타납니다.이 디스크 공간을 사용해서 8GB 환경에서 Stable Diffusion 모델을 결국 돌릴 수 있었습니다!인스턴스 스토어란?EC2 호스트 물리 서버에 직접 연결된 로컬 NVMe/SSD 디스크EBS보다 I/O 속도가 빠르지만, 인스턴스 Stop/Termi.. EBS 최소 볼륨 실험기 & gp3로 전환한 이유 “이 모델이 진짜 8GB로 돌아갈 수 있을까?”라는 질문에서 시작된 실험. 그리고 비용, 성능, 탄력성을 모두 고려해 gp3로 갈아탄 이야기. 실험 배경: EBS 볼륨 너무 크게 쓰고 있진 않을까?Stable Diffusion 기반 API를 운영하면서, 모델 구성 요소는 이미 EFS에 분리 저장한 상태였다.그렇다면 애플리케이션 서버가 직접 사용하는 EBS는 꼭 125GiB까지 필요할까?현재 서버는 g4dn.xlarge 타입인데, 여기에 다음 두 가지 스토리지가 기본으로 붙는다:루트 디스크 (EBS) — 기본 125GiB (수정 가능)ephemeral0 (임시 스토리지) — 디폴트로 제공하지만 실제로 EBS를 얼마나 쓰는지, 그리고 어디까지 줄여도 안정적으로 운영할 수 있는지는 확인이 필요했다.그래서 시.. 🐳 Stable Diffusion API Docker 패키징: 로컬 모델 조립 → 컨테이너화까지 Stable Diffusion 모델 구성요소를 로컬에서 조립한 다음, 이를 Docker 기반 API 서버로 패키징한 과정을 정리했다. 작업 배경앞선 포스팅에서 from_pretrained() 없이 로컬에 저장된 모델 구성 요소들만으로 Stable Diffusion 파이프라인을 조립했다. 그리고 이후에는 이 모델들을 EFS에 저장하고 API 서버에서 직접 로딩하는 구조로 개선했다. 이제 남은 건 이 환경을 실제 운영에 적합한 형태로 포장하는 일. 즉, Docker 컨테이너로 패키징해서 어디서든 실행 가능하게 만드는 것이었다.Dockerfile 구성패키징 대상은 다음과 같다:FastAPI 기반 API 서버 코드 (main.py)Stable Diffusion 구성 요소를 로드하는 로직requirements.t.. EFS에 모델 구성요소 저장하고, 컨테이너에서 불러오는 구조로 전환하기 컨테이너 재빌드 없이 모델을 안정적으로 불러오기 위해, EFS에 모델 구성요소를 저장하고 Docker에서 직접 마운트하는 구조로 전환했다. 왜 이 작업이 필요했을까?이전까지는 모델 구성 요소들을 로컬에 저장하고, 컨테이너 안에서 로드하는 구조였다. 이 방식도 잘 작동하긴 했지만, 다음과 같은 불편함이 있었다:컨테이너를 새로 빌드하거나 다른 인스턴스에서 실행할 경우 모델을 다시 복사해야 함모델 파일 용량이 수 GB 단위라 이미지 용량도 불필요하게 커짐장기적으로 여러 서버에서 공유하려면 중앙 저장소가 필요함그래서 Amazon EFS(Elastic File System)를 활용하기로 했다. EC2 인스턴스에 EFS 마운트먼저 EFS를 EC2 인스턴스에 /mnt/efs 경로로 마운트했다. 이후 Stable Di.. PyTorch 모델 저장 시 ModuleNotFoundError 오류 해결기: pickle과 버전 호환의 함정 모델을 저장하고 다시 불러오기만 했을 뿐인데 에러가 났다. 그 원인은 다름 아닌 pickle이었다.🧩 문제는 환경의 “미묘한 차이”였다Stable Diffusion 기반 API 서버를 개발하는 과정에서 .pth 파일로 저장한 모델을 불러오는 도중 다음과 같은 오류를 만났다.ModuleNotFoundError: No module named 'diffusers.models.unets' 흥미로운 점은 같은 서버에서 저장한 모델임에도, Docker 컨테이너에서 실행했을 때 이 오류가 발생했다는 것이다. 알고 보니 로컬 환경과 컨테이너 내부의 라이브러리 버전이 미묘하게 달랐고, 바로 그 차이로 인해 모델을 제대로 불러올 수 없었던 것이다.왜 이런 일이 발생했을까?# 저장 시[UNet2DConditionModel.. [Docker] 가상화 기술, 하이퍼바이저, 컨테이너의 이해: 하나의 OS에서 모든 소프트웨어를 실행하면 왜 위험할까? 하나의 컴퓨터에서 여러 개의 소프트웨어를 실행한다고 생각해봅시다. 이론상 문제 없어 보이지만, 현실에서는 다양한 문제가 발생할 수 있습니다.예를 들어, 하나의 프로그램이 오류를 일으키거나 과도한 리소스를 사용하게 되면, 다른 프로그램까지 영향을 받을 수 있죠.이런 문제를 해결하기 위해 등장한 기술이 바로 가상화 기술(Virtualization)입니다. 가상화 기술이란?가상화(Virtualization)는 하나의 물리적 컴퓨터 안에 여러 개의 논리적 OS 환경을 만들어 각각 독립적으로 소프트웨어를 실행할 수 있도록 해주는 기술입니다.이를 통해 리소스를 직접 분배하거나, 서로 격리된 환경에서 소프트웨어를 안정적으로 운영할 수 있습니다.가상화의 장점프로그램 간 리소스 충돌 방지하나의 에러가 다른 서비스에 영향.. 이전 1 다음
