26J03b

Young-Kyoo Kim·6일 전

가능합니다. 다만 현재 집 PC는 “로컬 LLM 서버”가 아니라 “agentic AI 개발·검증용 홈랩 서버”로 보는 게 맞습니다.
LLM 추론은 당장은 클라우드 API + 작은 로컬 모델 병행, 회사 반입용 코드는 OpenAI-compatible/local LLM으로 교체 가능하게 추상화하는 방향이 좋습니다.

1. 현재 PC로 가능한 범위

10년 된 4core / 32GB PC라면 아래는 가능합니다.

항목가능 여부의견
Docker Compose 기반 agent 개발환경가능가장 먼저 추천
k3d/kind 기반 단일 노드 K8s가능ArgoCD/Prometheus까지는 경량으로 가능
LangGraph agent API 서버가능FastAPI + worker 정도는 충분
MCP tool server 여러 개가능read-only tool 중심이면 충분
PostgreSQL + pgvector 또는 Qdrant가능소규모 RAG에는 충분
MinIO 단일 노드가능AIStor 대체 실습용으로 충분
Open WebUI + Ollama가능작은 모델 테스트용
OpenSearch 단일 노드제한적메모리 많이 먹으므로 후순위
7B/8B 로컬 LLM CPU 추론가능하지만 느림실사용 개발 보조로는 답답할 가능성 큼
13B 이상 로컬 LLM비추천RAM은 가능해도 속도/동시 실행이 부담
70B급 로컬 LLM불가에 가까움별도 GPU 서버 영역

Ollama 모델 페이지 기준으로 7B 모델은 대체로 최소 8GB RAM, 13B는 16GB RAM, 70B는 64GB RAM이 필요하다고 안내됩니다. 단, 이건 “올라간다”는 의미에 가깝고, 오래된 4core CPU에서 “쾌적하다”는 뜻은 아닙니다. (Ollama) Ollama는 NVIDIA GPU 사용 시 compute capability 5.0 이상과 적정 드라이버를 요구하므로, GPU를 붙일 경우 호환성과 전원/케이스 여유를 먼저 봐야 합니다. (Ollama Documentation)

2. 가장 추천하는 전체 구조

집에서는 아래처럼 4계층으로 구성하는 게 좋습니다.

[개발/코딩 계층]
Claude Code / Gemini CLI / VS Code / Git

        ↓

[Agent Runtime 계층]
FastAPI
LangGraph
MCP Client
Prompt / Policy / Eval

        ↓

[Tool / Connector 계층]
MCP Git Tool
MCP Docs Search Tool
MCP Prometheus Tool
MCP K8s Read-only Tool
MCP ArgoCD Read-only Tool
MCP MinIO Tool

        ↓

[Data / Infra 계층]
Git repo
Markdown docs
PostgreSQL + pgvector or Qdrant
MinIO
Prometheus
Grafana
k3d/kind Kubernetes
ArgoCD

LangGraph는 durable execution, streaming, human-in-the-loop 같은 agent orchestration 기능에 초점을 둔 프레임워크이고, MCP는 AI 애플리케이션이 파일, DB, API, 도구, workflow 같은 외부 시스템에 표준 방식으로 연결되도록 하는 프로토콜입니다. 이 둘을 중심으로 잡으면 개인 서비스와 회사 AIOps 양쪽에 재사용하기 좋습니다. (LangChain 문서)

3. 집 PC에는 우선 Docker Compose부터 추천합니다

처음부터 Kubernetes에 다 올리면 4core PC에서 너무 무겁고, 개발 속도도 떨어질 수 있습니다. 그래서 1단계는 Docker Compose, 2단계는 k3d/kind, 3단계는 회사 반입용 Helm/ArgoCD가 좋습니다.

1단계: Docker Compose

처음에는 이 정도만 띄우면 됩니다.

agent-api
agent-worker
postgres
minio
qdrant 또는 pgvector
redis
prometheus
grafana
open-webui
ollama

이 단계의 목적은 Kubernetes 운영 실습이 아니라 에이전트 구조, RAG, MCP tool, evaluation을 빠르게 개발하는 것입니다.

2단계: k3d 또는 kind

Kubernetes 축소판을 만들 때는 k3d나 kind를 쓰면 됩니다. kind는 Docker 컨테이너를 Kubernetes “node”로 사용해 로컬 클러스터를 띄우는 도구이고, k3d는 k3s를 Docker 안에서 쉽게 실행하는 경량 래퍼입니다. (kind.sigs.k8s.io)

집 PC 기준으로는 k3d 단일 노드를 더 추천합니다. 리소스가 적고 빠르게 띄우기 좋습니다.

k3d cluster
  ├─ ArgoCD
  ├─ Prometheus
  ├─ Grafana
  ├─ MinIO
  ├─ agent-api
  ├─ mcp-git
  ├─ mcp-docs
  └─ mcp-k8s-readonly

3단계: 회사 반입용 GitOps 패키징

집에서 검증한 뒤 회사에 가져갈 때는 아래 산출물이 중요합니다.

Helm chart
Kustomize overlay
container image tar
Python wheelhouse
pip/uv lock file
model/provider abstraction
offline install script
sample docs
sample metrics
sample logs
test cases
SOP

4. 현재 PC에서의 권장 리소스 배분

32GB RAM 기준으로는 이렇게 나눠 생각하면 됩니다.

구성요소권장 메모리
OS2~4GB
Docker/k3d 기본4~8GB
PostgreSQL/pgvector1~3GB
Qdrant1~2GB
MinIO512MB~2GB
Prometheus/Grafana1~3GB
Agent API/worker1~3GB
Ollama 작은 모델4~10GB
여유분4~8GB

즉, 모든 것을 한 번에 무겁게 띄우면 부족하고, 단계별로 켜야 합니다. 특히 OpenSearch는 집 PC에서는 후순위입니다. 회사에서 OpenSearch를 쓰더라도, 집에서는 처음에 OpenSearch adapter interface만 만들고, 실제 OpenSearch 컨테이너는 통합 테스트 때만 잠깐 띄우는 식이 좋습니다.

5. 가장 먼저 돈을 쓴다면 GPU보다 SSD입니다

현재 PC가 HDD 기반이면, 첫 업그레이드는 GPU가 아니라 SSD입니다.

우선순위는 이렇습니다.

순위업그레이드이유
1SSD 1~2TBDocker image, vector DB, Git repo, MinIO, 로그 저장에 가장 체감 큼
2RAM 64GB 가능 여부 확인보드가 지원하면 매우 좋음
3NVIDIA GPU 12~16GB VRAM로컬 LLM을 쾌적하게 쓰고 싶을 때
4새 미니 PC/워크스테이션기존 PC에 GPU/전원/발열 한계가 있을 때

기존 PC가 10년 됐다면 GPU를 억지로 붙이기 전에 다음을 확인해야 합니다.

lscpu | egrep 'Model name|Socket|Core|Thread|avx|avx2'
free -h
lsblk
df -h
lspci | grep -i nvidia
sudo dmidecode -t memory

확인 포인트는 다음입니다.

CPU가 AVX2를 지원하는가?
RAM을 64GB까지 올릴 수 있는가?
SSD가 장착 가능한가?
전원공급장치가 GPU를 버틸 수 있는가?
케이스에 GPU가 들어가는가?
소음/발열을 감당할 수 있는가?

개인적으로는 지금 PC에 무리하게 고성능 GPU를 붙이기보다, 일단 SSD만 보강해서 홈랩으로 쓰고, LLM 추론은 클라우드 API 또는 별도 GPU 장비로 분리하는 쪽이 더 현실적입니다.

6. LLM 전략은 이렇게 잡는 게 좋습니다

집에서 개발할 때

집에서는 개발 속도가 중요하므로 다음 조합이 좋습니다.

코딩/설계/복잡한 reasoning:
  Claude / Gemini / OpenAI API 또는 CLI 도구

로컬 호환성 테스트:
  Ollama + 작은 모델

회사 반입 코드:
  OpenAI-compatible interface
  local model endpoint 교체 가능 구조

Open WebUI는 self-hosted AI 플랫폼이고 Ollama와 OpenAI-compatible API를 지원하며, 오프라인 동작도 염두에 둔 도구입니다. 홈랩에서 로컬 모델과 클라우드 모델을 같은 UI로 비교하는 용도에 적합합니다. (Open WebUI)

현재 PC에서 돌려볼 만한 로컬 모델

현재 PC에서는 이런 용도가 적당합니다.

1B~3B 모델:
  빠른 로컬 테스트
  라우팅
  단순 요약
  작은 문서 질의

7B/8B Q4 모델:
  기능 검증
  간단한 RAG 답변
  오프라인 demo

13B 이상:
  현재 PC에서는 비추천

Llama 3.2 계열은 1B/3B 크기의 text model도 제공되고, agentic retrieval과 summarization task에 최적화되었다고 소개됩니다. 이런 작은 모델은 “성능 최종 검증”이 아니라 “로컬 호환성 테스트” 용도로 적합합니다. (Ollama)

7. 집에서 반드시 만들어야 할 핵심 구성요소

A. Agent Core

역할:
  사용자 질문 처리
  intent 분류
  필요한 도구 선택
  증거 수집
  위험도 평가
  보고서 생성
  human approval 처리

추천 스택:

Python 3.12
FastAPI
LangGraph
Pydantic
SQLAlchemy
pytest
ruff
mypy
uv 또는 poetry

B. RAG Core

역할:
  Markdown/PDF/Git 문서 수집
  chunking
  embedding
  vector search
  metadata filter
  citation 생성

추천 구성:

PostgreSQL + pgvector
또는 Qdrant
MinIO for raw documents
Markdown first
PDF parser는 후순위

처음에는 PDF보다 Markdown/Git 문서 중심이 좋습니다. 회사의 SOP, 작업계획서, 장애분석서도 결국 Markdown으로 표준화하려는 방향이므로, 집에서도 처음부터 Markdown을 source of truth로 두는 게 좋습니다.

C. MCP Tool Server

MCP tool은 agent가 외부 시스템을 읽거나 제안 작업을 만들기 위한 인터페이스입니다.

처음 만들 tool은 아래 순서가 좋습니다.

1. mcp-docs-search
2. mcp-git-search
3. mcp-prometheus-query
4. mcp-k8s-readonly
5. mcp-argocd-readonly
6. mcp-minio-readonly
7. mcp-report-writer

처음 6개월은 read-only tool 위주로 해야 합니다.

허용:
  get
  list
  describe
  logs
  diff
  query
  search
  summarize

금지:
  apply
  delete
  patch
  sync
  heal
  rotate
  restart

D. Eval / Guardrail

이게 없으면 demo는 되지만 운영 도구가 되기 어렵습니다.

필수 평가 항목은 다음입니다.

근거 문서가 있는가?
시간 범위를 명확히 썼는가?
metric/log 근거가 포함되었는가?
모르는 것을 모른다고 했는가?
위험한 명령을 제안하지 않았는가?
변경 영향도와 rollback을 같이 제시했는가?
SOP와 실제 관측값을 구분했는가?

E. Audit Log

회사 반입을 생각하면 처음부터 audit log를 남겨야 합니다.

누가 질문했는가?
어떤 tool을 호출했는가?
어떤 query를 실행했는가?
어떤 문서를 근거로 사용했는가?
어떤 답변을 생성했는가?
사용자가 승인/반려했는가?

집에서는 SQLite/PostgreSQL에 남기고, 회사에서는 OpenSearch 또는 내부 로그 체계로 보내면 됩니다.

8. 회사 데이터는 집에 가져오면 안 됩니다

이건 매우 중요합니다. 집에서 만들 때는 회사 실제 로그, 장애 이력 원문, 내부 SOP, Git repo, 계정정보, endpoint, IP, 인증서를 가져오면 안 됩니다.

대신 이렇게 해야 합니다.

집:
  synthetic docs
  synthetic metrics
  synthetic logs
  sample Kubernetes app
  sample ArgoCD repo
  fake incident history

회사:
  adapter 설정만 교체
  실제 Git endpoint 연결
  실제 Prometheus 연결
  실제 OpenSearch 연결
  실제 ArgoCD 연결
  실제 SOP repo 연결

즉, 집에서 만드는 것은 데이터가 아니라 구조입니다.

좋은 방식은 아래처럼 sample data를 만드는 것입니다.

sample-data/
  docs/
    sop/
      cilium-bgp-flap.md
      minio-quorum-error.md
      argocd-sync-failure.md
    change-plans/
      ingress-nginx-upgrade.md
      cilium-config-change.md
    incidents/
      incident-2026-05-07-minio-5xx.md
  metrics/
    prometheus-samples.yaml
  logs/
    opensearch-samples.ndjson
  git-repos/
    platform-gitops-sample/

이렇게 하면 회사에 가져갔을 때 sample connector만 real connector로 바꾸면 됩니다.

9. 집에서의 최소 설치 목록

필수

Linux bare-metal
Docker 또는 Podman
Docker Compose
Git
Python 3.12
uv 또는 poetry
Node.js LTS
PostgreSQL
MinIO
Qdrant 또는 pgvector
FastAPI
LangGraph
MCP SDK
Prometheus
Grafana
Ollama
Open WebUI

선택

k3d 또는 kind
ArgoCD
Loki
OpenSearch
Vault dev server
Keycloak dev server
Jenkins dev server
Gitea
Harbor 또는 registry:2

현재 PC 기준으로는 선택 항목을 한꺼번에 다 띄우지 않는 게 좋습니다.

10. 추천 홈랩 단계

Phase 0: PC 정리

Linux 설치
SSD 확보
Docker 설치
Git 기본 설정
devcontainer 또는 venv 표준화

OS는 회사 환경과 맞추려면 Rocky Linux 9 계열도 좋고, 개발 편의성은 Ubuntu Server LTS가 좋습니다. 회사 반입을 생각하면 Dockerfile/Helm/manifest가 OS에 덜 의존하게 만드는 것이 더 중요합니다.

Phase 1: Docker Compose 기반 agent platform

목표:
  local docs를 읽고 근거 기반 답변을 생성하는 agent

구성:
  agent-api
  postgres
  minio
  qdrant
  ollama
  open-webui

이 단계의 성공 기준은 다음입니다.

Markdown 문서를 넣는다
질문한다
관련 chunk를 찾는다
근거 포함 답변을 만든다
답변/근거/tool call 로그가 저장된다

Phase 2: MCP tool 추가

목표:
  agent가 문서뿐 아니라 도구를 호출하게 만든다

tool:
  docs_search
  git_search
  shell_readonly
  report_writer

여기서 shell tool은 매우 제한적으로 만들어야 합니다.

허용 명령:
  ls
  cat
  grep
  git log
  git diff
  kubectl get
  kubectl describe

금지 명령:
  rm
  mv
  chmod
  chown
  kubectl apply
  kubectl delete
  helm upgrade

Phase 3: k3d/kind + ArgoCD 실습

목표:
  회사 GitOps 환경의 축소판 만들기

구성:
  k3d single node
  ArgoCD
  sample app
  Prometheus
  Grafana
  MinIO

이 단계의 질문 예시는 다음입니다.

“현재 sample app의 배포 상태를 요약해줘.”
“ArgoCD diff를 보고 위험한 변경을 찾아줘.”
“Prometheus에서 5xx 증가 여부를 확인해줘.”
“변경계획서 초안을 만들어줘.”

Phase 4: AIOps Copilot prototype

목표:
  장애/변경 분석 agent 만들기

workflow:
  질문 분류
  관련 SOP 검색
  Git 변경 이력 검색
  Prometheus query
  K8s 상태 조회
  원인 후보 정리
  추가 확인 항목 제시
  작업계획서/rollback 초안 생성

이 단계에서는 답변 형식을 표준화합니다.

1. 요약
2. 확인한 근거
3. 가능성 높은 원인
4. 아직 배제하지 못한 원인
5. 추가 확인 명령
6. 조치 제안
7. 위험도
8. rollback 고려사항

Phase 5: 회사 반입 패키지 만들기

목표:
  air-gap 환경으로 옮길 수 있게 만들기

산출물:
  images.tar
  helm-chart.tgz
  python-wheels.tar
  models-manifest.yaml
  install.sh
  values-airgap.yaml
  sample-data.tar
  smoke-test.sh
  README.md
  SOP.md

회사 반입 전에는 아래를 만족해야 합니다.

외부 인터넷 호출 없음
모델 provider 교체 가능
Secret은 values에 직접 저장하지 않음
read-only mode 기본값
감사 로그 저장
모든 image tag 고정
모든 dependency lock
restore/reinstall 절차 문서화

11. 개인 서비스와 회사 AIOps를 같이 고려한 repo 구조

아래 구조를 추천합니다.

agentic-platform/
  apps/
    personal-investment-agent/
    kculture-pilot/
    aiops-copilot/

  services/
    agent-api/
    agent-worker/
    web-ui/

  packages/
    agent-core/
    rag-core/
    eval-core/
    policy-core/
    report-core/

  mcp-servers/
    mcp-docs-search/
    mcp-git-search/
    mcp-prometheus/
    mcp-k8s-readonly/
    mcp-argocd-readonly/
    mcp-minio-readonly/

  infra/
    compose/
    k3d/
    helm/
    argocd/
    monitoring/

  data/
    sample-docs/
    sample-metrics/
    sample-logs/

  docs/
    architecture/
    runbooks/
    sop/
    eval-cases/
    security/

이 구조의 장점은 개인 프로젝트와 회사 프로젝트가 공통 코어를 공유한다는 점입니다.

personal-investment-agent:
  뉴스/공시/가격 근거 수집

kculture-pilot:
  트렌드/콘텐츠/다국어 생성

aiops-copilot:
  SOP/Git/metric/log 근거 수집

겉보기는 달라도 내부는 모두 다음 패턴입니다.

수집 → 검색 → 근거 정리 → 판단 → 보고서 → 승인

12. 최소 비용으로 시작하는 현실적인 구성

현재 장비 기준으로 가장 현실적인 시작점은 이겁니다.

기존 PC:
  Linux bare-metal
  Docker Compose
  PostgreSQL + pgvector
  MinIO
  Qdrant optional
  FastAPI + LangGraph
  MCP servers
  Prometheus + Grafana
  Ollama + 1B/3B/7B 모델 테스트

LLM:
  개발/코딩은 Claude/Gemini/OpenAI 같은 외부 모델 사용
  로컬 모델은 호환성/air-gap 대비용으로만 사용

K8s:
  처음엔 생략
  이후 k3d 단일 노드로 ArgoCD/Prometheus/sample app만 구성

지금 당장 굳이 하지 말아야 할 것은 다음입니다.

멀티노드 K8s 홈랩
OpenSearch 상시 기동
대형 로컬 LLM
자동 kubectl apply/delete
실제 회사 데이터 반입
처음부터 멀티에이전트 과설계

13. 장비를 추가한다면 추천 방향

A안: 현재 PC 유지 + SSD만 추가

가장 비용 효율적입니다.

대상:
  개발환경
  Docker Compose
  작은 RAG
  sample K8s
  로컬 소형 LLM 테스트

추천:
  SSD 1~2TB

B안: 현재 PC + 중고/보급형 NVIDIA GPU

로컬 LLM을 조금 더 실사용하고 싶을 때입니다.

대상:
  7B/8B Q4 모델을 더 쾌적하게 실행
  embedding 처리 속도 개선
  Open WebUI/Ollama 실사용

확인:
  PSU
  케이스 공간
  발열
  드라이버 지원
  VRAM 12GB 이상 권장

C안: 별도 소형 서버/워크스테이션

AIOps 플랫폼을 계속 키울 생각이면 가장 안정적입니다.

권장:
  8~16 core
  64~128GB RAM
  SSD 2TB 이상
  NVIDIA GPU 16~24GB VRAM 선택

다만 처음부터 C안으로 갈 필요는 없습니다. 현재 단계에서는 구조를 잘 만드는 것이 장비보다 중요합니다.

결론

현재 4core / 32GB PC로도 충분히 시작할 수 있습니다. 단, 역할을 명확히 나눠야 합니다.

현재 PC의 역할:
  agentic platform 개발 서버
  RAG/MCP/정책/eval 검증 서버
  회사 AIOps 축소판
  air-gap 패키징 연습장

현재 PC에 맡기면 안 되는 역할:
  고성능 로컬 LLM 서버
  대규모 OpenSearch 서버
  멀티노드 K8s 서버
  운영 자동조치 실험장

가장 추천하는 시작 구성은 다음입니다.

1. Linux bare-metal
2. Docker Compose
3. FastAPI + LangGraph
4. PostgreSQL + pgvector
5. MinIO
6. MCP docs/git/prometheus/k8s-readonly tool
7. Ollama + 작은 모델
8. Open WebUI
9. 이후 k3d + ArgoCD + Prometheus 추가

즉, 집에서는 “작은 로컬 ChatGPT”를 만드는 것보다 “회사로 가져갈 수 있는 read-only evidence-based AIOps agent platform”을 만드는 것이 핵심입니다. 이 방향이면 현재 PC로도 충분히 시작할 수 있고, 나중에 SSD/RAM/GPU만 단계적으로 보강하면 됩니다.

==

네, 집 PC는 Windows여도 됩니다.
다만 이 용도라면 “Windows에서 직접 Python/Docker/K8s를 돌린다”기보다는 Windows + WSL2를 리눅스 개발환경처럼 쓰는 방식이 가장 좋습니다.

정리하면 추천 순서는 이렇습니다.

1순위: Windows 11 + WSL2 + Docker Desktop + VS Code Remote WSL
2순위: Windows 10 + WSL2 + Docker Desktop, 단 보안 업데이트/ESU 확인
3순위: Linux bare-metal

결론

현재 PC를 계속 Windows로 쓰고 싶다면 괜찮습니다. 대신 핵심 개발환경은 WSL2 안에 둬야 합니다.

Windows
  ├─ VS Code / Cursor / Claude Code / Gemini CLI
  ├─ 브라우저 / 문서작업 / Git GUI
  └─ WSL2 Ubuntu
        ├─ Python
        ├─ FastAPI
        ├─ LangGraph
        ├─ MCP servers
        ├─ Docker CLI
        ├─ k3d/kind
        ├─ kubectl/helm/argocd
        └─ Git repo

Microsoft도 WSL을 통해 Windows에서 Linux 배포판, Linux 앱, Bash 도구를 별도 VM이나 듀얼부팅 없이 사용할 수 있다고 설명하고, wsl --install로 설치하면 새 Linux 배포판은 기본적으로 WSL2로 설정된다고 안내합니다. (Microsoft Learn)

왜 Windows + WSL2가 좋은가

사용자 목적에는 장점이 많습니다.

항목Windows + WSL2 장점
기존 PC 활용Windows를 밀지 않아도 됨
개발 편의성VS Code, Claude Code, Gemini CLI, 브라우저를 Windows에서 편하게 사용
Linux 호환성Python, Docker, kubectl, Helm, LangGraph, MCP를 Linux 기준으로 사용
회사 반입성회사 환경이 Linux/K8s 중심이므로 WSL 안에서 만든 코드가 이식하기 좋음
실험 안정성Windows는 데스크톱, WSL은 개발 서버처럼 분리 가능

Docker도 WSL2 backend를 공식 지원하며, WSL2는 full Linux kernel 기반이고 Docker Desktop과 함께 쓰면 Linux workspace를 활용할 수 있다고 설명합니다. 또한 Docker Desktop의 WSL2 backend는 동적 메모리 할당을 사용해 필요한 CPU/메모리만 요청한다고 되어 있습니다. (Docker Documentation)

단, Windows 10이면 주의가 필요합니다

집 PC가 10년 된 장비라면 Windows 10일 가능성이 있습니다. 이 경우 보안 측면을 봐야 합니다. Microsoft는 Windows 10 지원이 2025년 10월 14일 종료되었고, 이후에는 보안 업데이트나 기술 지원을 제공하지 않는다고 안내합니다. (Microsoft 지원)

그래서 권장은 이렇습니다.

현재 OS추천
Windows 11 가능Windows 11 + WSL2 사용
Windows 10이고 ESU 가능당분간 Windows 10 + WSL2 사용 가능
Windows 10이고 ESU/보안 업데이트 없음인터넷 연결 개발 PC로는 비추천
Windows 11 불가 + 장기 사용 예정Linux bare-metal 전환도 고려

개인 홈랩이라도 Docker image, API key, Git credential, 개인 투자 데이터, 실험용 서비스 코드가 들어갈 수 있으므로 보안 업데이트가 끊긴 Windows 10을 계속 인터넷에 연결해 쓰는 것은 좋지 않습니다.

Windows에서 추천하는 실제 구성

1. Windows 역할

Windows는 “작업용 데스크톱”으로 둡니다.

Windows에서 사용:
  VS Code / Cursor
  Claude Code / Gemini CLI
  브라우저
  문서 작성
  Git GUI
  Docker Desktop UI
  Open WebUI 접속

2. WSL2 역할

WSL2는 “리눅스 개발 서버”로 씁니다.

WSL2 Ubuntu에서 사용:
  git
  python
  uv / poetry
  node
  docker
  docker compose
  kubectl
  helm
  argocd CLI
  k3d 또는 kind
  langgraph
  mcp server

Microsoft의 WSL 개발환경 가이드도 Git, VS Code, Docker remote containers, DB, GPU acceleration 등을 WSL 기반 개발환경의 주요 구성으로 안내합니다. (Microsoft Learn)

파일 위치가 중요합니다

Windows + WSL2에서 가장 많이 하는 실수가 있습니다.

나쁜 방식:
  C:\Users\me\project 에 소스 저장
  WSL에서 /mnt/c/Users/me/project 접근

좋은 방식:
  WSL 내부에 저장
  /home/me/workspace/agentic-platform

즉, 프로젝트는 WSL 내부 Linux filesystem에 둬야 합니다.

mkdir -p ~/workspace
cd ~/workspace
git clone <your-repo>

Windows 탐색기에서 보고 싶으면 아래 경로로 접근하면 됩니다.

\\wsl$\Ubuntu\home\<사용자>\workspace

이렇게 해야 Git, Python 가상환경, Docker build, node_modules, vector DB 파일 접근이 덜 꼬입니다.

Docker Desktop은 써도 되나?

개인 사용이면 Docker Desktop을 써도 됩니다. Docker 공식 문서는 Docker Desktop이 개인 사용, 교육, 비상업적 오픈소스, 일정 규모 이하의 소규모 사업자에게 무료이고, 대기업/정부/무료 범위 밖의 상업적 사용에는 유료 구독이 필요하다고 설명합니다. (Docker Documentation)

집에서는 괜찮지만, 회사 air-gap 환경에 가져갈 때는 Docker Desktop 자체를 전제로 하지 않는 것이 좋습니다.

집:

Docker Desktop + WSL2

회사:

containerd / CRI-O / Kubernetes
내부 registry
Helm / Kustomize / ArgoCD

즉, 집에서 만든 산출물은 아래처럼 회사 친화적으로 남겨야 합니다.

Dockerfile
container image
Helm chart
Kustomize overlay
values-airgap.yaml
offline dependency bundle
OCI image tar
README/SOP

Docker Desktop 요구사항도 확인해야 합니다

Docker Desktop for Windows는 WSL2 사용을 위해 64-bit CPU, SLAT, 최소 8GB RAM, BIOS/UEFI virtualization 활성화를 요구합니다. 또한 현재 문서 기준으로 Windows 10 22H2 또는 Windows 11 23H2 이상 등의 지원 OS 조건이 명시되어 있습니다. (Docker Documentation)

현재 PC에서 먼저 확인할 것은 이겁니다.

systeminfo

여기서 아래 항목을 봅니다.

Hyper-V Requirements
Virtualization Enabled In Firmware
Second Level Address Translation

그리고 WSL 설치 후에는:

wsl -l -v

Ubuntu가 VERSION 2로 나와야 합니다.

k3d/kind도 Windows에서 가능

Kubernetes 실습은 Windows native보다는 WSL2 안에서 k3d 또는 kind를 실행하는 게 좋습니다.

도구의견
Docker Compose1단계 개발환경으로 가장 추천
k3d가볍고 빠름. 4core PC에 적합
kindKubernetes 표준 실습에 좋음
Docker Desktop 내장 Kubernetes간단 테스트용. AIOps 구조 실습에는 k3d/kind 선호

kind는 Docker 컨테이너를 Kubernetes node로 사용하는 로컬 클러스터 도구이고, 공식 문서에서도 WSL2, private registry, offline working 관련 문서 항목을 제공합니다. (kind.sigs.k8s.io) k3d는 k3s를 Docker에서 실행하기 위한 경량 wrapper로, 단일/멀티 노드 k3s 클러스터를 쉽게 만들기 위한 도구입니다. (K3D)

집 PC가 4core/32GB라면 처음에는 이렇게 가는 게 좋습니다.

처음:
  Docker Compose

조금 익숙해지면:
  k3d single-node

나중:
  ArgoCD + Prometheus + sample app + agent-api

추천 설치 흐름

1. WSL2 설치

PowerShell 관리자 권한에서:

wsl --install -d Ubuntu
wsl --set-default-version 2
wsl -l -v

2. Docker Desktop 설치

설치 후 설정에서:

Settings
  → General
    → Use WSL 2 based engine

Settings
  → Resources
    → WSL Integration
      → Ubuntu 활성화

Docker 문서도 WSL2 backend를 켜고, WSL Integration에서 기본 WSL 배포판에 Docker CLI 접근을 활성화하는 방식을 안내합니다. (Docker Documentation)

3. WSL 안에 개발 도구 설치

Ubuntu WSL에서:

sudo apt update
sudo apt install -y git curl unzip jq make build-essential ca-certificates

curl -LsSf https://astral.sh/uv/install.sh | sh

4. 프로젝트는 WSL 내부에 생성

mkdir -p ~/workspace
cd ~/workspace
mkdir agentic-platform
cd agentic-platform

5. Docker Compose부터 시작

초기에는 이 정도만 올리는 게 좋습니다.

postgres + pgvector
minio
qdrant 또는 chroma
redis
agent-api
agent-worker
ollama
open-webui
prometheus
grafana

4core PC에서는 OpenSearch, Keycloak, Vault, ArgoCD, k3d를 처음부터 다 켜지 않는 게 좋습니다.

WSL 리소스 제한 설정

Windows 전체가 버벅이지 않도록 .wslconfig를 설정하는 게 좋습니다.

Windows 사용자 홈에 생성:

C:\Users\<사용자>\.wslconfig

예시:

[wsl2]
memory=20GB
processors=3
swap=8GB
localhostForwarding=true

그 다음:

wsl --shutdown

4core/32GB PC라면 처음에는 이렇게 잡는 게 무난합니다.

항목추천
WSL memory16~20GB
WSL processors3
swap8GB
Windows 여유 RAM최소 8~12GB

Windows로 할 때 피해야 할 것

피해야 할 것이유
/mnt/c 아래에서 Python/node 프로젝트 운영파일 I/O, 권한, line ending 문제 가능
Windows Python과 WSL Python 혼용가상환경/경로 꼬임
Docker Desktop Kubernetes에 과도하게 의존회사 K8s/ArgoCD 구조와 차이 큼
OpenSearch/Keycloak/Vault/ArgoCD를 처음부터 모두 상시 기동4core/32GB에서는 무거움
회사 실제 데이터/로그/Git을 집 PC에 복사보안상 위험
Windows 10 무보안 업데이트 상태로 인터넷 개발보안 위험

Windows와 Linux bare-metal 중 선택 기준

Windows 유지가 좋은 경우

기존 Windows 프로그램을 계속 써야 한다
Claude Code/Gemini CLI/브라우저/문서작업을 편하게 쓰고 싶다
PC를 가족/일반 용도로도 쓴다
Linux 설치/드라이버 관리에 시간을 쓰고 싶지 않다

Linux bare-metal이 좋은 경우

Windows 11 업그레이드 불가
Windows 10 보안 업데이트가 없음
Docker/WSL 이슈가 자주 생김
PC를 거의 서버처럼 24시간 켜둘 예정
GPU/로컬 LLM 실험을 본격적으로 할 예정

사용자 상황에서는 일단 Windows + WSL2로 시작하는 게 좋습니다. 나중에 불편하면 Linux로 전환해도 됩니다.

최종 추천

집 PC가 Windows여도 됩니다. 오히려 처음에는 이 구성이 가장 현실적입니다.

Windows 11 또는 보안 업데이트 가능한 Windows
  + WSL2 Ubuntu
  + Docker Desktop WSL2 backend
  + VS Code Remote WSL
  + Docker Compose
  + 이후 k3d/kind

핵심 원칙은 하나입니다.

Windows는 작업용 데스크톱,
WSL2는 리눅스 개발 서버,
Docker/K8s/Agent/RAG/MCP는 모두 WSL2 기준.

이렇게 구성하면 지금 PC로도 개인 관심사 에이전트, K-pop/K-food pilot, 회사 반입용 read-only AIOps Copilot 구조를 충분히 만들 수 있습니다.

profile
Young-Kyoo Kim
engineer
이전 포스트

26J03a

다음 포스트

26J05a

0개의 댓글