압솔공방

윈도우에서 80과 443 포트를 방화벽으로 허용한 후, WSL 내부 서비스(예: 웹 서버)에 호스트 IP로 연결하려면 포트 포워딩 설정이 필요합니다. WSL2는 별도 네트워크를 사용하므로 netsh 명령어로 윈도우에서 WSL IP로 트래픽을 전달해야 합니다.24hours-beginner.tistory+1

IP 주소 확인

먼저 PowerShell(관리자)에서 윈도우 IP를 ipconfig로 확인하고, WSL 터미널에서 ip addr show eth0 또는 hostname -I로 WSL IP(예: 172.x.x.x)를 확인하세요.

방화벽 규칙 추가

PowerShell(관리자 권한)에서 다음 명령어를 실행해 80, 443 포트 인바운드 허용:

New-NetFirewallRule -DisplayName "Allow 80-443 WSL" -Direction Inbound -LocalPort 80,443 -Protocol TCP -Action Allow

이 규칙은 TCP 인바운드 트래픽을 허용하며, 필요 시 Outbound도 추가하세요.velog+1

포트 포워딩 설정

PowerShell(관리자)에서 WSL IP(예: 172.20.0.1)를 사용해 명령어 실행:

netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=<WSL_IP>
netsh interface portproxy add v4tov4 listenport=443 listenaddress=0.0.0.0 connectport=443 connectaddress=<WSL_IP>

설정 확인: netsh interface portproxy show v4tov4.junho85+1

연결 테스트

WSL에서 서버(예: nginx on 80)를 실행한 후, 다른 기기 브라우저에서 윈도우_IP:80 또는 윈도우_IP:443으로 접근하세요.

다음은 안될 떄, 추가로 확인 절차

windows에서 ipconfig로 IP확인(WanIP, LanIP)

WSL에서 IP확인
ip addr show eth0
$ hostname -I

먼저 확인할 것

아래 두 가지가 가장 흔한 실패 원인입니다.

• WSL 안의 웹 서버가 127.0.0.1에만 바인딩되어 있으면 portproxy로 못 들어옵니다. 반드시 0.0.0.0:80, 0.0.0.0:443처럼 바인딩되어야 합니다.gwangtori+1
• Windows 방화벽 규칙은 열었더라도, Hyper-V/WSL 방화벽 규칙이 따로 막을 수 있습니다. Microsoft 문서도 WSL용 Hyper-V 방화벽 규칙을 별도로 다룹니다.learn.microsoft

방법 1: Windows Hosts 파일 수정 (가장 추천)

스마트폰(외부망)에서 접속이 된다는 것은 포트 포워딩, 윈도우 방화벽, 그리고 WSL 내부의 Nginx 설정이 모두 완벽하게 작동하고 있다는 뜻입니다. 이제 전 세계 어디서든 사용자님의 서버에 접속할 수 있는 상태가 되었습니다.

로컬 컴퓨터에서 자신의 공인 IP(220.68.77.33)로 접속이 안 되는 현상은 **’NAT Loopback’ 또는 ‘Hairpinning’**이라고 불리는 네트워크 기술적 특성 때문입니다. 윈도우 시스템이 자기 자신에게 할당된 외부 IP로 나갔다가 다시 들어오는 패킷을 정상적으로 처리하지 못하는 경우가 많습니다.

로컬 컴퓨터에서만 220.68.77.33을 127.0.0.1로 인식하게 만들어 루프백 문제를 우회합니다.

1. 메모장을 관리자 권한으로 엽니다.
2. C:\Windows\System32\drivers\etc\hosts 파일을 엽니다.
3. 맨 아래에 다음 내용을 추가하고 저장합니다:
   text
   127.0.0.1 220.68.77.33
4. 이제 브라우저에서 http://220.68.77.33을 입력하면 즉시 로컬 서버(WSL)로 연결됩니다.

WSL IP로 연결 다른 방법

외부 IP로 연결이 안 되는 문제는 WSL 2의 기본 네트워크 모드(NAT)와 netsh portproxy의 불안정성 때문일 가능성이 큽니다. 특히 현재 WSL 내부에서 443 포트가 리스닝 상태가 아니며, 윈도우 호스트와 WSL 간의 방화벽 차단으로 인해 프록시가 정상 작동하지 않고 있습니다.

이를 해결하기 위해 가장 현대적이고 확실한 방법인 **미러드 네트워크 모드(Mirrored Networking Mode)**로 전환하는 계획을 세웠습니다. 이 모드에서는 별도의 포트 포워딩 설정 없이 WSL의 서비스를 호스트 IP에서 직접 접근할 수 있습니다.

주요 제안 사항:

1. Mirrored Mode 활성화: .wslconfig 설정을 통해 WSL이 호스트의 IP를 직접 공유하도록 변경합니다. [NEW] .wslconfig
Enable mirrored networking in the user’s home directory. Location: C:\Users\User\.wslconfig (or equivalent %USERPROFILE%\.wslconfig)

ini
[wsl2]
networkingMode=mirrored

2. 기존 설정 초기화: 혼선을 방지하기 위해 netsh interface portproxy 설정을 삭제합니다.

powershell
netsh interface portproxy reset

3. WSL 재시작: 설정을 적용하기 위해 wsl --shutdown을 실행합니다.

Run wsl --shutdown to apply the new networking configuration.

이후

관리자 권한으로 PowerShell 또는 명령 프롬프트를 열고 다음 명령어를 실행해 주세요:

powershell# 기존 포트 포워딩 규칙 삭제 (관리자 권한 필수)
netsh interface portproxy reset

그 후, WSL로 돌아가서 Nginx를 다시 시작하면 포트 80으로 외부 접속이 가능해집니다:

bash
sudo service nginx restart

Ubuntu에서 Ollama를 운영할 때는 보통 설치 → systemd 서비스 확인 → 모델 pull → GPU/원격접속 설정 → 모니터링/업데이트 순서로 관리하면 됩니다. 공식 Linux 문서도 systemd 서비스 파일을 사용하는 운영 방식을 안내합니다.

기본 설치

• 설치는 공식 스크립트로 진행합니다: curl -fsSL https://ollama.com/install.sh | sh 또는 Ubuntu용 안내에 맞는 설치 방법을 사용합니다. 설치가 끝나면 ollama.service가 만들어지고 자동 시작됩니다. docs.ollama+1
• 상태 확인은 systemctl status ollama로 하고, 실행 중인지 ss -napt | grep 11434 또는 curl http://127.0.0.1:11434/api/tags로 확인합니다. 기본적으로 Ollama API는 127.0.0.1:11434에서 열립니다. server-world

서비스 운영

• ollama serve는 수동 실행, systemd는 상시 운영에 적합합니다. 터미널을 닫아도 계속 돌아가게 하려면 systemd 서비스로 운용하는 것이 정석입니다.reddit+1
• 재시작은 sudo systemctl restart ollama, 중지는 sudo systemctl stop ollama, 자동 시작은 sudo systemctl enable ollama로 관리합니다.server-world+1

모델 관리

• 모델은 ollama pull llama3.1:8b, ollama pull qwen3:8b처럼 내려받고, ollama list로 확인합니다. 이후 ollama run 모델명으로 테스트합니다.docs.ollama
• 실제 서비스에서는 자주 쓰는 모델만 유지하고, 나머지는 지우거나 교체해 디스크와 메모리를 아끼는 편이 좋습니다.docs.ollama

GPU 설정

• Linux에서 Ollama가 systemd로 실행될 때는 환경변수를 서비스 오버라이드로 넣는 방식이 권장됩니다. 예를 들어 sudo systemctl edit ollama.service 후 [Service]에 Environment="OLLAMA_HOST=0.0.0.0:11434" 같은 식으로 추가합니다.mostlytech+1
• NVIDIA/AMD/Intel GPU 활용 여부는 드라이버와 환경에 따라 달라지며, GPU가 없으면 CPU-only로 동작합니다. Ubuntu 안내에서도 GPU가 없을 경우 CPU 모드로 실행된다고 설명합니다.server-world

원격 접속

• 다른 PC에서 쓰려면 OLLAMA_HOST=0.0.0.0:11434로 바인딩을 바꾸고, ufw에서 포트를 열어야 합니다. 예: sudo ufw allow 11434/tcp 또는 LAN만 허용하는 규칙을 쓰는 것이 안전합니다.glukhov+1
• 단, Ollama는 기본적으로 인증/레이트리밋이 없으므로 공개 인터넷에 직접 노출하면 안 됩니다. 가능하면 Tailscale/WireGuard/SSH 터널 같은 방식으로 제한하는 것이 좋습니다.serverman.co+1

운영 팁

• 안정성 우선이면 systemd 상시 구동 + LAN/VPN 제한 + 필요한 모델만 pull이 가장 깔끔합니다.glukhov+1
• 성능 우선이면 GPU 드라이버를 먼저 잡고, 큰 모델 대신 7B~8B급 모델로 시작하는 편이 관리가 쉽습니다.mostlytech+1

가능합니다. 가장 쉬운 방법은 OLLAMA_KEEP_ALIVE=-1로 서버를 띄워서, 현재 많이 쓰는 1개 모델만 메모리에 계속 유지하는 것입니다. Ollama는 기본적으로 모델을 약 5분 후 언로드하지만, OLLAMA_KEEP_ALIVE나 요청별 keep_alive로 유지 시간을 조절할 수 있습니다.insiderllm+1

1개 모델만 상시 유지하는 방법

방법 A: 서버 전체에 적용

ollama.service에 환경변수를 넣습니다.

bashsudo systemctl edit ollama.service

아래 추가:

text[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

적용:

bashsudo systemctl daemon-reload
sudo systemctl restart ollama

이렇게 하면 서버가 실행되는 동안 모델이 계속 메모리에 남아 있게 됩니다.docs.ollama+1

방법 B: 특정 모델만 유지

한 번만 호출해서 그 모델을 계속 유지시킬 수도 있습니다.

bashcurl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "keep alive",
  "keep_alive": -1
}'

이 방식은 그 요청으로 활성화한 1개 모델만 오래 붙잡는 용도로 쓰기 좋습니다.insiderllm+1

3개 모델 중 1개만 상시 운영할 때

Ollama는 기본적으로 현재 메모리에 올라간 모델이 있으면 그 모델을 유지하고, 다른 모델을 쓰면 그쪽으로 바뀌면서 메모리를 다시 사용합니다. 그래서 실무적으로는:

• 상시 쓸 1개 모델만 keep_alive=-1
• 나머지 2개는 필요할 때만 호출
• 필요 없는 모델은 ollama stop 모델명으로 내리기

이 방식이 가장 단순합니다.ollama.apidog+2

추천 운영 방식

항상 붙여둘 모델

• 캘린더 CRUD, 음성 명령 처리용이면 가장 자주 쓰는 1개 모델만 상시 유지하세요.
• 예: qwen3:8b 또는 glm-4.7-flash 같은 주력 모델 1개.ollama+1

나머지 모델

• 테스트용, 백업용, 고성능 모델은 필요할 때만 로드
• 사용 후 ollama stop 모델명으로 정리

bashollama stop qwen3:8b

확인 명령

현재 어떤 모델이 올라와 있는지 보려면:

bashollama ps

이걸로 실제로 메모리에 상주 중인 모델을 확인할 수 있습니다.

Ollama LLM을 별도 서버에 설치하고 OpenClaw에서 원격으로 사용하는 방법은 서버에서 Ollama를 외부 접근 가능하게 설정한 후, OpenClaw 구성 파일에서 서버 주소를 지정하는 것입니다. 이 과정은 Ubuntu나 Linux 서버에서 주로 적용되며, 보안 주의가 필요합니다.

Ollama 서버 설정 (별도 서버)

• 서버(Linux/Ubuntu)에 Ollama 설치: curl -fsSL https://ollama.com/install.sh | sh 실행.recording-it.tistory
• 원격 접근 허용: OLLAMA_HOST=0.0.0.0:11434 환경변수 설정.
  systemd 서비스 편집 (systemctl edit ollama.service) 후 [Service] Environment="OLLAMA_HOST=0.0.0.0" 추가하고 재시작 (sudo systemctl daemon-reload && sudo systemctl restart ollama).
• 모델 다운로드: ollama pull llama3.1:8b (또는 원하는 모델, 추천 8B).
• 방화벽 확인: sudo ufw allow 11434로 포트 개방, 서버 IP 확인 (예: 192.168.x.x).blog.naver

OpenClaw 클라이언트 설정 (다른 컴퓨터)

• OpenClaw 설치: npm install -g openclaw (Node.js 필요).recording-it.tistory
• 온보딩 실행: openclaw 명령으로 마법사 실행, Quick Start 선택 후 Ollama provider 선택.recording-it.tistory
• 구성 파일 수정 (~/.openclaw/openclaw.json 또는 해당 경로):
  text{ "agent": { "provider": "ollama", "model": "llama3.1:8b", "baseUrl": "http://서버IP:11434" } }서버 IP를 실제 주소로 변경.open-clawai+1
• 재시작: openclaw restart 또는 systemctl restart openclaw-gateway.recording-it.tistory

테스트 및 주의사항

다른 컴퓨터에서 curl http://서버IP:11434/api/tags로 Ollama 연결 확인.growth-coder.tistory
OpenClaw에서 Telegram 등 앱 연동 후 “hello” 테스트. GPU 서버 추천, 보안 위해 VPN/SSH 터널 사용.fdcservers+1

AI를 활용해 딸깍하고 개발하는 프로세스를 단계별로 예를 들어 자세히 설명할게. 요청하신 네 가지 도구(PRD, Speckit, Pumasi, Ralph-loop)를 중심으로 각 단계가 어떻게 이어지는지 차근차근 정리합니다.

---

1. PRD로 서비스 기획 및 개발 문서 작성

• 서비스의 목표, 주요 기능, 사용자 요구사항 등을 상세히 정리하는 문서
• 예시)
• 목표: 대학생 자녀를 둔 부모를 위한 교육 관리 앱 개발
• 주요 기능: 로그인, 강의 일정 확인, 알림, 성적 관리, 커뮤니케이션 기능
• 요구사항: 모바일과 웹 모두 지원, 보안 인증 반드시 포함
• PRD 작성 과정을 통해 팀과 공유할 명확한 로드맵과 요구사항이 만들어진다.

---

2. Speckit으로 SDD(설계 문서) 진행

• PRD에서 정의한 기능과 요구사항을 바탕으로 시스템 설계 문서 작성
• 구체적인 데이터 흐름, 아키텍처, 인터페이스, API 명세 등을 명확히 함
• 예시)
• 사용자 로그인 방식: JWT 인증 방식을 채택
• DB 테이블 설계: 사용자, 강의, 알림, 성적 테이블 구조 작성
• API 명세: /login, /lectures, /notifications 등 REST API 설계
• Speckit을 통해 명확하고 일관된 설계 문서 작성, 개발자와 디자이너가 공유

---

3. Pumasi로 코드 작성 및 병렬 개발

• Claude Code와 Codex 같은 AI 코딩 도구를 병렬로 활용하여 빠르게 코드 생성
• 명확하게 작성된 SDD를 기반으로 AI가 필요한 모듈과 기능을 동시에 개발
• 예시)
• Claude Code가 로그인 모듈을 작성하고, Codex가 강의 조회 API 코드를 동시에 개발
• 이후 병렬로 작성된 코드들을 Pumasi 플랫폼에서 리뷰 및 머지(통합)
• 자동 테스트 및 코드 스타일 검증 병행하여 품질 유지
• AI 도움으로 개발 속도를 극대화하고 병목 없는 병렬 작업 가능

---

4. Ralph-loop를 통한 끊임없는 SDD 진행 및 개선

• 실제 개발 및 테스트 중 발생한 문제점과 요구 변경을 Ralph-loop에 반영
• SDD 문서를 지속해서 업데이트하고 코드도 개선하는 무한 루프 수행
• 예시)
• 사용자 피드백 반영해 기능 추가 및 설계 변경
• 보안 취약점 발견 시 즉시 SDD에 반영하고 관련 코드 수정
• Ralph-loop에 의해 문서와 코드가 동시에 최신 상태로 유지됨
• 이렇게 반복해서 프로세스가 계속 돌면서 서비스 완성도 상승

---

요약

단계	역할	주요 작업	도구 활용 예시
1. PRD	서비스 구상, 요구사항 정의	목표 설정, 기능 리스트 작성	PRD 문서 작성
2. Speckit	시스템 설계(SDD)	아키텍처, DB 설계, API 명세	설계 문서 작성 및 공유
3. Pumasi	AI 병렬 코드 작성, 병합	AI 코딩(Claude, Codex), 코드 병합 및 테스트	AI 코드 자동 생성 및 머지
4. Ralph-loop	지속적 설계 및 개선	설계 문서 업데이트, 코드 보완 반복	무한 루프 피드백 및 개선

---

이 과정을 통해 AI가 촉진하는 개발 프로세스가 어떻게 순환하며 이루어지는지 한눈에 파악할 수 있을 거야. PRD로 시작해 Speckit에서 설계, Pumasi로 AI 병렬코딩, Ralph-loop로 끊임없는 개선을 반복하면서 개발의 효율성·품질을 최대화하는 흐름이지.

각 도구별 활용 구체 사례와 세부 절차를 단계별로 자세히 설명합니다. 이 과정에서는 실제 개발 현장에서 어떻게 활용하는지 이해하기 쉽게 실제 예시와 구체적인 절차 위주로 다뤄볼게.

---

1. PRD (Product Requirement Document) 작성

구체 사례

• 신입 사원 교육 관리 웹서비스 개발 프로젝트
• 목표: 사용자 친화적인 교육 신청 및 관리 시스템 제공
• 주요 기능: 회원가입/로그인, 강의 신청, 교육 일정 조회, 알림 발송
• 요구사항: PC/모바일 웹환경 모두 지원, 1만 명 동시 접속 가능

세부 절차

1. 이해관계자(서비스 기획자, PM, 커스터머) 미팅
2. 사용자 요구사항 수집 (인터뷰, 설문 등)
3. 기능 목록 작성 및 우선순위 정리
4. 서비스 목표 및 핵심 지표(KPI) 정의
5. 기능 상세 설명, 비즈니스 규칙 포함 작성
6. 문서 공유 및 피드백 반영 후 최종 확정

---

2. Speckit을 활용한 SDD (Software Design Document) 작성

구체 사례

• PRD 기반 로그인 시스템 설계
• JWT 토큰 기반 인증 설계 및 API 명세 작성
• 데이터베이스 테이블 스키마: Users 테이블 설계 (id, 이메일, 비밀번호(hashed), 가입일 등)

세부 절차

1. PRD 기능별 핵심 로직 추출
2. 시스템 아키텍처 설계 (클라이언트, 서버, DB 관계)
3. API 스펙 정의 (URL, HTTP 메서드, 요청/응답 데이터 형식)
4. 데이터베이스 ER(Entity-Relationship) 다이어그램 작성
5. 보안, 예외 처리, 오류 코드 정책 등 기술적 상세 명시
6. 설계문서 내역 팀원과 공유 및 리뷰 → 승인

---

3. Pumasi로 AI 병렬코드 작성 및 머지

구체 사례

• Claude Code에 로그인 기능 작성 요청
• Codex에 강의 목록 CRUD API 구현 요청
• AI가 동시에 생성한 코드 충돌 없이 병합

세부 절차

1. SDD의 API 스펙과 데이터베이스 설계를 Pumasi에 입력
2. 각 AI 엔진에 담당 모듈별 코드 생성 명령 전달
3. 자동 생성 코드 초기 검토 및 단위 테스트 실행
4. Pumasi 내 코드 자동 병합 기능 사용, 버전 관리(Git과 연동)
5. 충돌 발생 시 AI와 사람이 함께 리뷰, 수정 처리
6. 통합된 코드 리포지토리에 빌드 및 통합 테스트

---

4. Ralph-loop를 이용한 지속적 SDD 관리 및 개선

구체 사례

• 고객 피드백 반영해 교육 알림 기능에 푸시 알림 옵션 추가
• 보안 강화 위해 인증 프로토콜 일부 수정 필요 발생
• 성능 이슈로 일부 API 최적화 설계 반영

세부 절차

1. 개발 및 배포 후 사용자 또는 QA 피드백 수집
2. Ralph-loop에 피드백과 변경 요청 입력 및 설계 변경안 작성
3. 변경된 설계문서를 다시 팀 내 공유하고 검토
4. 변경된 SDD 기준으로 AI 혹은 개발자가 코드 업데이트
5. 변경 사항 테스트 후 배포, 다시 피드백 루프로 이동
6. 이 과정을 반복하면서 서비스 완성도 향상

---

이처럼 각 도구의 특징과 역할별로 명확하게 분리되어 있고, 단계별 절차도 명확해서 업무 효율과 품질을 높이는 데 도움이 된다.