걸어서개발한바퀴

Mac mini M4(24GB)로 OpenClaw 세팅하기 (로컬 LLM + MCP 툴 추천까지)

jinmc — Wed, 11 Feb 2026 15:53:09 +0900

요즘 “내 컴퓨터에서 24/7로 돌아가는 개인 AI 비서”를 만들 때 가장 많이 언급되는 조합이 Mac mini + OpenClaw입니다. OpenClaw는 메신저(텔레그램/슬랙/디스코드 등)로 들어오는 요청을 받아서, 웹/파일/툴을 실제로 실행해주는 에이전트 런타임에 가깝습니다.

다만 OpenClaw 생태계는 최근 확산 속도가 매우 빠르고(인기 + 확장 기능), 그만큼 보안 이슈도 크게 터진 상태라서 “설치만 하면 끝”은 아닙니다. 스킬(확장) 설치는 특히 주의가 필요합니다.

이 글에서는 Mac mini M4 24GB 기준으로,

OpenClaw 기본 설치
24/7 구동 세팅
로컬 모델(Ollama) 연결
MCP 툴 추천
까지 한 번에 정리합니다.

0) 이 글의 전제 (Mac mini M4 24GB 기준)

**클라우드 모델(Claude/OpenAI 등)**만 쓰면 24GB는 충분하고, 오히려 여유가 남습니다.
로컬 모델까지 같이 굴리면 모델 크기에 따라 체감이 갈립니다. (7B~8B 급은 현실적으로 가능, 14B 이상은 기대치 관리 필요)

1) 사전 준비 (macOS 기본 툴)

OpenClaw는 Node 기반으로 돌아가니, 기본적으로 아래가 필요합니다.

Xcode Command Line Tools (git 포함)
Homebrew
Node.js (가이드에 따라 버전 요구가 있을 수 있음)

참고로 Mac mini에서 OpenClaw 설치/준비 과정은 커뮤니티에서도 비슷하게 정리되어 있습니다.

2) OpenClaw 설치 (가장 단순한 방법)

공식 설치 스크립트로 진행하는 방식이 가장 빠릅니다.

curl -fsSL https://openclaw.ai/install.sh | bash openclaw --version openclaw status

설치 후에는 초기 설정(온보딩)으로 들어갑니다.

openclaw onboard

여기서 모델 제공자(클라우드 or 로컬), 채널(텔레그램/슬랙 등)을 선택하고 토큰을 넣는 흐름입니다.

3) 24/7로 “항상 켜져있는” 상태 만들기

OpenClaw를 “비서”로 쓰려면 맥이 잠들면 끝입니다.

시스템 설정 → 배터리/전원에서 “디스플레이 끄기”와 “컴퓨터 잠자기”를 분리해서 관리
가능하면 **Sleep 방지(필요할 때만)**를 걸어두는 식이 깔끔합니다.

추가로, OpenClaw 설정을 손으로 만졌으면 재시작이 필요합니다(구성 파일 수정 후 반영).

openclaw gateway restart

4) (중요) 보안 기본값

최근 OpenClaw 스킬/확장 생태계에서 악성 스킬 이슈가 실제로 터졌습니다. 특히 “터미널에 이 명령 실행하세요” 류는 위험합니다.

권장 원칙:

스킬은 공식/신뢰 가능한 출처만 설치
설치 전 레포/코드 확인
OpenClaw가 접근 가능한 권한(파일/쉘/네트워크)을 최소화
외부로 열어야 한다면(원격) 인증/접근제어 필수

5) 로컬 모델을 쓰려면: Ollama 연동이 제일 편합니다

Mac mini에서 로컬 LLM은 보통 Ollama가 설치/운영이 쉽고, OpenClaw도 Ollama를 provider로 문서화해두었습니다.

5-1) Ollama 설치 & 모델 받기

brew install ollama ollama serve

모델은 일단 아래 중 하나로 시작하는 게 무난합니다.

qwen2.5:7b-instruct (가성비/툴콜 기대치 괜찮음)
llama3.1:8b-instruct (범용)
(메모리 여유 있으면) gemma 계열도 선택지

ollama pull qwen2.5:7b-instruct

5-2) OpenClaw에서 Ollama provider 연결

OpenClaw는 Ollama의 OpenAI 호환 엔드포인트 방식으로 붙는 흐름을 지원합니다.
대부분은 온보딩에서 “Local/Ollama” 고르면 자동으로 잡히고, 수동이라면 설정 파일에 Ollama baseUrl을 넣고 재시작합니다.

예시로 커뮤니티에서 공유된 설정은 이런 형태입니다(포맷 참고용).

{ "models": { "providers": { "ollama": { "baseUrl": "http://localhost:11434/v1", "apiKey": "ollama-local", "api": "openai-completions", "models": [ { "id": "qwen2.5:7b-instruct", "name": "qwen2.5:7b-instruct" } ] } } } }

수정 후:

openclaw gateway restart openclaw status

5-3) 로컬 모델 추천 (Mac mini M4 24GB 기준)

현실적인 추천만 정리합니다.

업무/툴콜/에이전트: qwen2.5:7b-instruct 류부터
대화/범용: llama3.1:8b-instruct
14B 이상은 돌아가도 “빠릿함” 기대하면 실망할 확률이 큽니다(특히 멀티스텝 에이전트).

6) MCP 툴(=MCP 서버) 뭐 쓰면 좋은가?

MCP는 에이전트가 외부 기능을 표준 방식으로 붙이는 프로토콜이고, 서버 레퍼런스/목록은 공식 저장소에 계속 업데이트됩니다.

6-1) “무조건 깔아둘만한” MCP 툴 3종

Playwright MCP (웹 자동화/브라우저 조작)

검색/클릭/로그인/스크래핑까지 에이전트가 직접 실행 가능
공식 Playwright MCP 서버 레포가 따로 있습니다.

설정 예시(클라이언트에 mcpServers로 추가):

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

File system 계열 (로컬 파일 읽기/쓰기)

“작업 결과를 파일로 저장”, “로그/리포트 생성” 같은 자동화에 필수

Git MCP

코드 수정/커밋/브랜치 작업을 에이전트가 안전하게 수행하게 만들 때 유용

(MCP 서버들을 한눈에 찾을 때는 디렉토리 사이트도 편합니다. )

6-2) “상황 따라 가치가 큰” MCP 툴

Web Search (Brave/Tavily 등): 실시간 정보가 핵심인 워크플로우에서 효율 상승 (OpenClaw 웹검색 구성도 여러 방식이 언급됩니다).
DB(Postgres 등): 사내 데이터/개인 데이터 자동 요약, 리포팅에 강함
YouTube/Transcript: 영상 요약/스크립트 자동화 파이프라인에 좋음

7) 참고 링크 (공식/주요 레퍼런스)

아래는 “원문 확인용”으로 같이 첨부합니다.

OpenClaw GitHub (공식): https://github.com/openclaw/openclaw OpenClaw Docs (공식): https://docs.openclaw.ai Ollama ↔ OpenClaw (Ollama 문서): https://docs.ollama.com/integrations/openclaw OpenClaw Ollama Provider (공식): https://docs.openclaw.ai/providers/ollama Playwright MCP Server (공식): https://github.com/microsoft/playwright-mcp MCP 서버 모음(공식): https://github.com/modelcontextprotocol/servers MCP 예제(공식): https://modelcontextprotocol.io/examples

마무리

Mac mini M4 24GB면 OpenClaw 운용 자체는 충분히 됩니다. 다만 체감 품질은 (1) 어떤 모델을 붙이느냐와 (2) MCP 툴을 어떻게 구성하느냐, 그리고 (3) 스킬/확장 보안 습관에서 갈립니다.

[mcp tools] playwright tool에 관한 설명

jinmc — Wed, 11 Feb 2026 15:31:22 +0900

LLM 에이전트 시대에 다시 주목받는 브라우저 자동화 도구

최근 AI 에이전트, MCP, 자동화와 같은 키워드가 확산되면서 Playwright라는 이름도 자주 등장하고 있습니다.
이 때문에 “LLM 전용 라이브러리인가?”라고 오해하는 경우가 많은데, 결론부터 말씀드리면 Playwright는 LLM 라이브러리가 아니라 브라우저 자동화 도구입니다.

다만 AI 에이전트가 실제 웹 환경과 상호작용하기 위해 거의 필수적으로 사용되기 때문에 LLM 생태계에서 함께 언급되는 경우가 많습니다.

1. Playwright의 정체

Playwright는 마이크로소프트에서 개발한 웹 브라우저 자동 제어 라이브러리입니다.
코드를 통해 사람이 브라우저에서 수행하는 다양한 행동을 그대로 재현할 수 있습니다.

예를 들면 다음과 같습니다.

웹사이트 접속
버튼 클릭 및 입력 자동화
로그인 처리
스크롤 이동
파일 다운로드
스크린샷 촬영

즉, 사용자의 브라우저 행동을 코드로 자동화하는 도구라고 이해하시면 됩니다.

또한 지원 범위도 넓습니다.

Chromium, Firefox, WebKit 모두 지원
Node.js, Python, Java, .NET 환경 사용 가능

과거에는 Selenium이 널리 사용되었지만,
현재는 속도, 안정성, 개발 편의성 측면에서 Playwright로 이동하는 흐름이 뚜렷합니다.

2. 그런데 왜 LLM 분야에서 자주 등장할까?

핵심 이유는 단순합니다.

LLM은 대화를 생성할 수는 있지만, 직접 행동할 수는 없습니다.

그래서 AI 에이전트 구조에서는 항상 다음과 같은 흐름이 필요합니다.

LLM → Tool 호출 → 외부 환경에서 실제 행동 → 결과 반환

여기서 웹에서의 실제 행동을 담당하는 대표적인 도구가 바로 Playwright입니다.

대표적인 활용 예시는 다음과 같습니다.

로그인해야 접근 가능한 페이지 데이터 수집
검색 → 페이지 이동 → 정보 추출 자동화
버튼 클릭 이후에만 나타나는 동적 데이터 확보
화면 캡처 후 Vision 모델에 전달

이러한 작업은 단순 HTTP 요청 기반 크롤링으로는 불가능하며,
실제 브라우저 제어가 반드시 필요합니다.

따라서 다음과 같이 정리할 수 있습니다.

Playwright는 LLM의 ‘손과 눈’ 역할을 수행합니다.

3. MCP Tool 구조에서 중요한 이유

MCP(Model Context Protocol) 환경에서는
LLM이 외부 시스템을 직접 조작할 수 없고 반드시 Tool을 통해 행동해야 합니다.

이때 Playwright 기반 Tool을 연결하면 다음과 같은 작업이 가능해집니다.

“검색을 수행해 주세요”
“특정 사이트에 로그인해 주세요”
“버튼을 눌러 결과를 가져와 주세요”

즉, AI가 실제 웹을 조작하는 단계가 구현됩니다.

이 때문에 최근 에이전트 아키텍처에서는
Playwright가 기본 인프라 구성 요소처럼 사용되고 있습니다.

4. 언제 Playwright를 사용하면 좋을까?

다음과 같은 상황이라면 Playwright 사용이 적합합니다.

로그인 기반 데이터 수집이 필요한 경우
React, Vue 등 동적 렌더링 페이지 크롤링
사용자 행동 시뮬레이션 테스트 자동화
AI 에이전트의 웹 액션 실행

반대로 단순 정적 페이지 크롤링이라면
굳이 Playwright까지 사용할 필요는 없습니다.
이 경우에는 requests와 BeautifulSoup 조합이 더 가볍고 효율적입니다.

5. 한 줄 정리

LLM 전용 라이브러리는 아님
본질은 브라우저 자동화 도구
그러나 AI 에이전트 시대에는 사실상 필수 인프라

그래서 최근 기술 문맥에서 더욱 자주 등장하고 있습니다.

Playwright 공식 레포

Playwright (Node.js, 종합)
https://github.com/microsoft/playwright
Playwright Python
https://github.com/microsoft/playwright-python

맥(Mac)에서 n8n 로컬 서버를 외부로 연결하는 가장 깔끔한 방법 (Cloudflare Tunnel)

jinmc — Tue, 9 Dec 2025 10:03:09 +0900

n8n은 정말 강력한 워크플로우 자동화 툴입니다. 보통 도커(Docker)나 npm을 통해 맥 로컬(localhost:5678)에 띄워서 사용하곤 하는데요.

하지만 로컬에서만 돌리다 보면 치명적인 단점이 하나 있습니다. 바로 외부 서비스의 Webhook을 받을 수 없다는 점입니다. Slack, Google Sheets, GitHub 등 외부 서비스가 내 로컬 n8n에 신호를 보내려면 **공인된 주소(Public URL)**가 필요하기 때문입니다.

공유기 포트포워딩은 보안상 찝찝하고, ngrok은 무료 버전 제한이 귀찮습니다. 오늘은 Cloudflare Tunnel을 이용해 무료이면서도 보안상 안전하게 외부 접속을 허용하는 방법을 정리해 드립니다.

1분 만에 끝나는 **'간편 방법'**과 도메인을 고정해서 쓰는 '정석 방법' 두 가지가 있으니 상황에 맞춰 골라보세요.

준비물

Mac (Homebrew 설치됨)
n8n (로컬 5678 포트에서 실행 중)
(선택) Cloudflare 계정과 도메인 (정석 방법 사용 시 필요)

공통 단계: Cloudflared 설치

어떤 방법을 쓰든 Cloudflare의 데몬 툴인 cloudflared가 필요합니다. 터미널을 열고 설치해 줍니다.

brew install cloudflared

방법 1: 1분 컷! 초간단 연결 (Quick Tunnel)

추천 대상:

지금 당장 외부 접속 테스트만 해보고 싶은 분
도메인이 없는 분

복잡한 설정이나 로그인 필요 없이 명령어 한 줄이면 됩니다.

cloudflared tunnel --url http://localhost:5678

명령어를 실행하면 터미널 창에 아래와 같은 로그가 뜹니다.

Your quick Tunnel has been created! Visit it at:
https://random-word-1234.trycloudflare.com

저 https://....trycloudflare.com 주소가 바로 여러분의 외부 접속 주소입니다. 브라우저에 입력하면 내 로컬 n8n이 뜹니다!

⚠️ 주의할 점 (치명적 단점)

이 방식은 프로그램을 껐다 켜거나 재부팅하면 URL 주소가 매번 바뀝니다.
n8n Webhook URL을 Slack 같은 곳에 등록해 뒀는데, 재부팅할 때마다 주소가 바뀌면 매번 설정을 바꿔줘야 해서 장기적으로 쓰기엔 매우 불편합니다.

방법 2: 주소 고정하기 (Named Tunnel)

추천 대상:

n8n을 계속 켜두고 자동화를 돌릴 분
내 도메인(예: n8n.mydomain.com)을 쓰고 싶은 분

URL이 바뀌지 않도록 내 도메인에 고정하는 방법입니다. Cloudflare에 가입되어 있고 도메인이 등록되어 있어야 합니다.

1. 로그인

cloudflared tunnel login

브라우저가 뜨면 Cloudflare에 로그인하고 사용할 도메인을 선택(Authorize)해 줍니다.

2. 터널 생성

터널의 이름을 지어줍니다. (예: n8n-local)

cloudflared tunnel create n8n-local

이때 생성되는 **Tunnel ID(UUID)**를 잘 봐두세요.

3. 도메인 연결 (DNS 라우팅)

내 도메인(n8n.mydomain.com)으로 들어오면 방금 만든 터널로 연결되도록 설정합니다.

cloudflared tunnel route dns n8n-local n8n.mydomain.com

4. n8n 환경변수 설정 (중요!)

n8n에게 **"나의 공식 주소는 https://n8n.mydomain.com 야"**라고 알려줘야 합니다. 이 설정을 안 하면 n8n UI에서 Webhook URL을 생성할 때 여전히 localhost 주소를 보여줘서 헷갈립니다.

n8n을 실행할 때 아래 환경변수를 추가해 주세요.
(Docker 사용 시 -e 옵션으로 추가)

export WEBHOOK_URL=https://n8n.mydomain.com
n8n start

5. 터널 실행

이제 마지막으로 터널을 가동합니다.

cloudflared tunnel run --url http://localhost:5678 n8n-local

이제 https://n8n.mydomain.com으로 접속해 보세요. 언제 접속해도 주소가 변하지 않는 나만의 n8n 서버가 완성되었습니다!

요약: 뭘 써야 하나요?

1. 방법 1 (Quick Tunnel)

장점: 명령어 한 줄로 즉시 실행. 가입 필요 없음.
단점: 재시작하면 주소가 바뀜 (random.trycloudflare.com)
용도: "지금 잠깐 테스트만 할래!"

2. 방법 2 (Named Tunnel)

장점: 주소가 영구 고정됨 (n8n.mydomain.com). 안정적.
단점: Cloudflare 도메인 필요. 초기 설정 필요.
용도: "제대로 자동화 시스템 구축할래!"

처음엔 방법 1로 통신이 잘 되는지 테스트해 보시고, 본격적으로 n8n 워크플로우를 만드실 때는 방법 2로 정착하시는 것을 추천합니다.

Google 에이전트 스택 비교 — ADK · Agent Builder · Agent Engine · A2A (+ Agent Starter Pack)

jinmc — Fri, 7 Nov 2025 13:35:45 +0900

Google은 에이전트 개발을 프레임워크(ADK), 전주기 제품군(Agent Builder), 관리형 런타임(Agent Engine) 으로 나눠 제공합니다. 이름이 비슷하지만 역할과 책임이 명확히 다르므로, 선택 전에 개념을 정리하시는 게 좋습니다.

한 줄 정의

ADK (Agent Development Kit): 오픈소스, 코드 중심 프레임워크입니다. Gemini에 최적화되어 있지만 모델·배포 비종속(agnostic)으로 설계되어 다른 프레임워크/런타임과도 호환됩니다. https://google.github.io/adk-docs/
Vertex AI Agent Builder: 에이전트 전주기(빌드→배포→거버넌스) 를 아우르는 제품군입니다. 빌드는 ADK 등으로 하고 배포·운영은 Agent Engine을 쓰는 흐름을 가이드합니다. https://cloud.google.com/agent-builder/overview
Vertex AI Agent Engine: 관리형 런타임/운영 레이어입니다. 배포·확장·관측·평가·메모리 등 운영 기능을 제공하며, ADK/LangGraph/LangChain 등 여러 프레임워크를 지원합니다. https://cloud.google.com/agent-builder/agent-engine/overview
A2A (Agent-to-Agent Protocol): 프레임워크/벤더를 가로지르는 에이전트 상호운용 표준입니다. 현재는 Linux Foundation 산하 오픈 표준으로 문서화되어 있습니다. https://a2a-protocol.org/latest/
Agent Starter Pack: Google Cloud용 프로덕션 템플릿/인프라 번들입니다. 템플릿, CI/CD, 관측, 보안, 그리고 Agent Engine/Cloud Run 배포 흐름을 제공합니다. https://github.com/GoogleCloudPlatform/agent-starter-pack

각 도구를 빠르게 이해하기

ADK — “코드로 만드는” 에이전트 프레임워크

에이전트 오케스트레이션, 툴 연동, 멀티에이전트 구성 등을 코드로 설계할 수 있도록 한 모듈식 프레임워크입니다. model/deploy agnostic 철학을 공식 문서가 명시하고, 샘플 레포와 배포 가이드를 함께 제공합니다. 필요 시 Agent Engine으로 배포하는 경로도 지원합니다. https://google.github.io/adk-docs/

Agent Builder — “전주기를 감싸는” 제품군

Vertex AI 콘솔과 문서를 중심으로, 빌드(ADK 등 프레임워크) → 스케일(Agent Engine) → 거버넌스/관측 흐름을 제공합니다. 구성 요소로 Sessions, Memory Bank, Code Execution, Example Store 등이 연결됩니다. https://cloud.google.com/agent-builder/overview

Agent Engine — “운영을 책임지는” 관리형 런타임

프로덕션 배포·확장·관측(Trace/Logging/Monitoring)과 Memory Bank, Sessions, Evaluation, Code Execution 등을 제공하며, ADK·LangChain·LangGraph·AG2·LlamaIndex 등 다양한 프레임워크 지원 상태를 표로 명시합니다(“Full/SDK Integration/Custom template” 구분). 또한 Agent Starter Pack과의 연결을 공식 가이드에서 권장합니다. https://cloud.google.com/agent-builder/agent-engine/overview

A2A — “프레임워크를 넘나드는” 상호운용

에이전트가 서로를 발견·위임·협업할 수 있게 하는 표준입니다. 내부 기억/툴/로직을 공유하지 않고 메시지 규격만으로 상호작용하도록 설계되어 보안성과 벤더 중립성을 동시에 지향합니다. MCP와는 에이전트↔툴과 에이전트↔에이전트로 역할을 분담합니다. https://a2a-protocol.org/latest/

Agent Starter Pack — “운영 뼈대”

ReAct, RAG, 멀티에이전트, 실시간(라이브) 에이전트 등 템플릿과 함께, Terraform 기반 인프라·CI/CD(GCB/GitHub Actions)·관측(Cloud Trace/Logging) 구성을 포함합니다. Agent Engine/Cloud Run 배포 플로우와 ADK·A2A 베이스 템플릿도 포함되어 있습니다. https://github.com/GoogleCloudPlatform/agent-starter-pack

권장 아키텍처(현실적인 흐름)

ADK로 로컬/개발 환경에서 빌드·테스트 → Agent Engine으로 배포/운영(관측·보안·평가) → Agent Builder로 전주기 관리 → 필요 시 A2A로 멀티에이전트/이기종 연동, 인프라는 Agent Starter Pack으로 표준화하시는 것을 권합니다.

https://cloud.google.com/agent-builder/overview

기능 비교 한눈에

항목	ADK	Agent Builder	Agent Engine	A2A	Agent Starter Pack
역할	코드 기반 프레임워크	전주기 제품군	관리형 런타임/운영	상호운용 표준	프로덕션 템플릿/인프라
개방성	오픈소스, 모델/배포 비종속	Vertex AI 제품	Google Cloud 서비스	오픈 표준	오픈소스(레포)
주요 기능	오케스트레이션, 멀티에이전트, 툴 연동	Build·Scale·Govern	배포·스케일·관측·평가·메모리	에이전트 간 통신 규격	템플릿·CI/CD·관측·보안
프레임워크 호환	–	상위 개념	ADK·LangGraph·LangChain 등 지원	프레임워크 불문 상호운용	ADK·LangGraph·A2A 템플릿

선택 가이드

코드 유연성이 최우선이시면, ADK로 시작하신 뒤 운영 요구가 생기면 Agent Engine에 올리시는 구성이 합리적입니다.
조직 단위 거버넌스/표준화가 필요하시면, Agent Builder 관점에서 설계하고 런타임은 Agent Engine을 기본값으로 두시길 권합니다.
프로덕션 운영(관측·보안·평가·장기 메모리) 을 전제로 하시면, Agent Engine의 관리형 기능을 우선 고려하시고, 배포 뼈대는 Agent Starter Pack으로 고정하시는 게 유지보수에 유리합니다.
멀티에이전트/이기종 프레임워크 연동 방향이면, 초기 설계에서 A2A 메시지 스키마를 포함해 두시면 재작업 비용을 줄일 수 있습니다.

참고 자료

ADK 개요/철학/배포 경로: ADK Docs & GitHub(모델·배포 비종속 명시, Agent Engine 배포 가이드 포함).
Agent Builder 개요: 전주기 제품군 정의 및 “ADK로 빌드, Engine으로 배포” 워크플로.
Agent Engine 개요: 런타임·평가·Sessions·Memory Bank·Code Execution, 지원 프레임워크 표, Agent Starter Pack 연계. 마지막 업데이트: 2025-11-05(UTC).
A2A 공식 문서: 표준 소개, 핵심 개념, MCP와의 관계.
Agent Starter Pack: 템플릿 목록(ADK/A2A 포함), CI/CD·관측·보안 구성, Engine/Cloud Run 배포.

n8n을 인트라넷 전용으로 만들기 (인터넷 차단하기)

jinmc — Thu, 25 Sep 2025 17:23:11 +0900

회사 내부에서 n8n을 쓰다 보면 “혹시 n8n에서 인터넷으로 데이터가 빠져나가면 어떡하지?” 하는 걱정이 생깁니다.
저희도 똑같은 고민을 했고, 결국 n8n은 인트라넷만 쓰고, 인터넷은 절대 못 쓰게 만드는 방법을 찾았습니다.
아래처럼 하면 됩니다. ✨

1. 준비

n8n은 Docker + docker-compose로 돌리고 있다고 가정합니다.
서버는 회사 내부망에 연결돼 있습니다.

※ 여기서는 예시로 192.168.100.0/24 대역을 사용합니다. 실제 적용 시에는 각자 회사 내부망 대역에 맞춰 수정하세요.

2. 방화벽 규칙 세팅 (진짜 핵심)

리눅스 서버에서 아래 명령어를 실행합니다.
(관리자 권한 필요 → sudo su 하거나 각 줄마다 sudo 붙이기)

# (1) DOCKER-USER 체인을 싹 비웁니다. iptables -F DOCKER-USER # (2) 기존 연결은 그대로 허용 iptables -A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # (3) 도커 컨테이너 → 회사 내부망(예: 192.168.100.0/24)만 허용 iptables -A DOCKER-USER -i br+ -d 192.168.100.0/24 -j ACCEPT iptables -A DOCKER-USER -i docker0 -d 192.168.100.0/24 -j ACCEPT # (4) 나머지 전부 차단 (즉, 인터넷은 막힘) iptables -A DOCKER-USER -i br+ -j DROP iptables -A DOCKER-USER -i docker0 -j DROP

이렇게 하면 n8n 컨테이너는 인트라넷만 통신 가능, 인터넷은 완전히 차단됩니다.

3. 확인하기

① 내부망 테스트 (통과해야 함)

docker exec -it n8n ping -c 3 192.168.100.10 # 내부 서버 IP (각자 환경에 맞게 수정)

② 외부망 테스트 (막혀야 함)

docker exec -it n8n sh -lc 'wget -qO- --timeout=5 http://1.1.1.1; echo "exit code=$?"'

download timed out 같은 메시지가 나오면 성공입니다.
즉, 인터넷은 막혔다는 뜻!

4. 영구 저장하기

재부팅해도 규칙이 유지되도록 하려면:

apt-get update apt-get install -y netfilter-persistent netfilter-persistent save

5. 추가 보안 설정 (n8n 환경변수)

docker-compose.yml 안에 아래 환경변수를 추가하면 더 안전합니다.

environment: - N8N_DIAGNOSTICS_ENABLED=false # 텔레메트리 끄기 - N8N_VERSION_NOTIFICATIONS_ENABLED=false - N8N_TEMPLATES_ENABLED=false - N8N_COMMUNITY_PACKAGES_ENABLED=false # 커스텀 노드 설치 금지 - NODES_EXCLUDE=["n8n-nodes-base.httpRequest","n8n-nodes-base.smtp","n8n-nodes-base.slack","n8n-nodes-base.executeCommand","n8n-nodes-base.code"] - N8N_SECURE_COOKIE=false # (테스트용, 운영은 HTTPS 권장)

6. 결론

이렇게 세팅하면:

✅ n8n은 회사 내부 시스템만 접근 가능
❌ 외부 인터넷으로는 절대 못 나감 (데이터 유출 방지)
추가로 n8n 자체의 위험한 노드나 커스텀 노드도 막을 수 있음

✨ 한 줄 요약

“DOCKER-USER 체인에 인트라넷만 허용하고 나머지 DROP” → 이걸로 n8n은 내부 전용 서비스가 된다!

딥러닝 환경을 위한 Multi-CUDA 설치의 필요성과 실전 가이드

jinmc — Thu, 10 Jul 2025 17:35:53 +0900

1. 왜 CUDA 버전이 문제일까?

딥러닝 프레임워크(TensorFlow, PyTorch 등)는 특정 CUDA 버전과만 호환됩니다. 예를 들어:

TensorFlow 2.13 → CUDA 11.8 + cuDNN 8.6
PyTorch 2.1 → 기본적으로 CUDA 12.x까지 지원

그런데 시스템에 최신 CUDA(예: 12.8)가 설치되어 있다고 해서 모든 프레임워크가 자동으로 잘 작동하지는 않습니다.
오히려 맞지 않는 버전이면 GPU를 전혀 사용하지 못하고, CPU로만 실행되어 성능 저하가 발생합니다.

2. ⚠️ 기존 CUDA를 지우는 건 위험하다

많은 분들이 이 오류 메시지를 보면 이렇게 생각합니다:

“CUDA 버전을 바꿔야 하니까 기존 걸 삭제하고 다시 설치해야겠다!”

하지만 이는 위험한 선택입니다.

다른 프로젝트나 프레임워크에 의도치 않은 영향을 줄 수 있습니다.
시스템 전체에 설치된 CUDA를 제거하면 다른 ML 환경이 망가질 수도 있습니다.

3. ✅ 해결책은? Multi-CUDA 환경 설정!

Multi-CUDA는 말 그대로, 여러 개의 CUDA 버전을 동시에 설치하고 필요할 때마다 그 중 하나를 사용하는 방법입니다.

시스템 CUDA 12.8은 그대로 유지 ✅
CUDA 11.8은 /opt/cuda-11.8 같은 별도 경로에 설치 ✅
사용하려는 환경(Python/conda env)에서 LD_LIBRARY_PATH와 PATH만 설정하여 CUDA 11.8을 사용하도록 설정 ✅

4. Multi-CUDA가 필요한 대표적인 상황

상황설명

TensorFlow와 PyTorch를 둘 다 사용하는 경우	서로 요구하는 CUDA 버전이 다르기 때문
회사/팀에서 다양한 CUDA 기반 툴을 쓰는 경우	시스템 CUDA를 바꿀 수 없을 때
Docker를 쓰지 않는 로컬 개발 환경에서	독립적인 CUDA 환경 구성이 필요할 때
커스텀 빌드의 CUDA 의존성이 있는 라이브러리 사용 시	예: TensorRT, XLA

5. Multi-CUDA 설치 및 설정 (요약)

① CUDA 11.8 설치 (시스템과 별도로)

sudo mkdir -p /opt/cuda-11.8 cd /tmp 

wget https://developer.download.nvidia.com/compute/cuda/11.8.0/local_installers/cuda_11.8.0_520.61.05_linux.run 

chmod +x cuda_11.8.0_520.61.05_linux.run sudo ./cuda_11.8.0_520.61.05_linux.run --silent --toolkit --installpath=/opt/cuda-11.8

② cuDNN 8.6 설치

cuDNN 아카이브에서 다운로드 후:

tar -xzvf cudnn-8.6-linux-x64.tgz sudo cp cuda/include/* /opt/cuda-11.8/include/ 
sudo cp cuda/lib64/* /opt/cuda-11.8/lib64/

③ Conda 환경에서만 CUDA 11.8 사용

# 활성화된 conda env 내에 환경 변수 자동 설정 
mkdir -p $CONDA_PREFIX/etc/conda/activate.d 
echo 'export PATH=/opt/cuda-11.8/bin:$PATH' >> $CONDA_PREFIX/etc/conda/activate.d/env.sh 
echo 'export LD_LIBRARY_PATH=/opt/cuda-11.8/lib64:$LD_LIBRARY_PATH' >> $CONDA_PREFIX/etc/conda/activate.d/env.sh

6. ✅ GPU가 제대로 인식되는지 확인

python -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"

[PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]

7. ✨ 정리: Multi-CUDA는 선택이 아니라 필수

항목내용

기존 CUDA 제거 필요 여부	❌ 필요 없음
여러 CUDA 공존 가능 여부	✅ 가능 (버전 별 디렉토리로 분리)
Conda 환경 격리 설정	✅ PATH/LD_LIBRARY_PATH로 제어 가능
리스크	거의 없음 (루트 경로 안 건드림)

마무리

딥러닝 프로젝트를 여러 개 운영하거나, TensorFlow와 PyTorch를 동시에 써야 하는 상황이라면 Multi-CUDA 환경 구축은 거의 필수에 가깝습니다. 이 글에서 소개한 방식은 시스템을 깨뜨리지 않으면서도 안정적으로 CUDA 환경을 구성하는 방법입니다.

“기존 CUDA를 지우지 않고 새로운 CUDA 버전으로 TensorFlow를 GPU에서 돌리는 법”
이 주제에 고민이 있었다면, 이제는 걱정 없이 도전해보세요!

BM25란 무엇인가? (TF-IDF와의 비교 및 이후 발전)

jinmc — Mon, 28 Apr 2025 16:14:06 +0900

1. 왜 TF-IDF만으로는 부족할까?

검색 시스템이나 정보 검색(IR) 분야에서는 문서 내 특정 단어가 얼마나 중요한지를 판단해야 합니다.
가장 널리 알려진 기법이 바로 TF-IDF입니다.

하지만 TF-IDF만으로는 한계가 있습니다:

단어가 너무 자주 등장하면 점수가 비정상적으로 커지는 문제
문서 길이를 고려하지 않아서, 긴 문서가 무조건 유리해지는 문제

이러한 문제를 해결하기 위해 등장한 것이 바로 BM25입니다.

2. TF-IDF란? (개념과 수식)

✅ Term Frequency (TF)

한 문서에서 특정 단어가 얼마나 자주 등장하는지를 나타냅니다.

TF(t, d) = (문서 d에서 단어 t가 등장한 횟수) ÷ (문서 d의 전체 단어 수)

✅ Inverse Document Frequency (IDF)

전체 문서 중 해당 단어를 포함하는 문서 수에 따라 단어의 희귀성을 반영합니다.

IDF(t) = log( (전체 문서 수) ÷ (1 + 단어 t가 등장한 문서 수) )

※ 여기서 1을 더하는 이유는 0으로 나누는 것을 방지하기 위함입니다.

✅ TF-IDF

최종적으로 TF와 IDF를 곱해, 문서 내 중요 단어를 추출합니다.

TF-IDF(t, d) = TF(t, d) × IDF(t)

요약:

문서 내에서 많이 등장하는 단어이면서,

전체 문서에서는 드물게 등장하는 단어에 높은 점수를 부여합니다.

❗ TF-IDF의 한계

단어가 많이 등장할수록 점수가 무한히 커질 수 있음

문서 길이에 따른 불공평한 점수 부여 가능

3. BM25란? (개념과 수식)

BM25는 "Best Matching 25"의 약자입니다.
(25는 여러 버전을 거쳐 가장 성능이 좋았던 버전 번호라고 알려져 있습니다.)

BM25는 TF-IDF의 문제를 보완해서:

단어 빈도가 일정 이상 많아져도 점수가 포화되도록 조정하고
문서 길이에 따라 점수를 조정합니다.

✅ BM25 점수 공식

Score(q, d) = Σ (각 단어 t에 대해)
IDF(t) × [ f(t, d) × (k1 + 1) ] ÷ [ f(t, d) + k1 × (1 - b + b × (문서 길이 ÷ 평균 문서 길이)) ]

여기서,

f(t, d) = 문서 d에서 단어 t가 등장한 횟수
문서 길이 = 문서 d의 단어 수
평균 문서 길이 = 전체 문서들의 평균 길이
k1 = 단어 빈도에 대한 민감도를 조절하는 파라미터 (보통 1.2 ~ 2.0 사용)
b = 문서 길이에 대한 보정 정도를 조절하는 파라미터 (보통 0.75 사용)

4. TF-IDF와 BM25 비교

구분TF-IDFBM25

단어 빈도 처리	등장할수록 선형 증가	등장할수록 점진적 증가 (포화)
문서 길이 고려	고려하지 않음	문서 길이에 따라 점수 보정
의미적 흐름 반영	약함	다소 개선됨
계산 복잡성	간단	약간 복잡함 (파라미터 조정 필요)

5. 간단한 예시

문서내용

문서 A	"고양이 고양이 고양이 귀엽다"
문서 B	"고양이 사랑스럽다"

TF-IDF 기준:

문서 A가 "고양이"를 더 많이 포함하므로 점수가 높게 나옴.

BM25 기준:

"고양이"가 일정 횟수 이상 등장하면 점수 증가가 둔화되기 때문에,
문서 A와 문서 B가 비슷한 수준으로 평가될 수 있음.

6. BM25의 한계

아무리 좋은 알고리즘이라 해도 한계는 존재합니다. BM25도 예외는 아닙니다.

BM25의 주요 한계점:

단어의 의미적 유사성을 고려하지 못합니다.
예를 들어, "자동차"와 "차량"은 다른 단어로 인식됩니다.
질의어의 순서나 구조적 관계를 반영하지 못합니다.
자연어 질의에서 복잡한 의도나 뉘앙스를 완전히 파악하기 어렵습니다.

즉, BM25는 여전히 "단어 매칭" 중심의 방식입니다.

7. BM25 이후의 발전

최근 정보 검색 시스템은 BM25를 넘어서기 위해 다양한 방향으로 발전하고 있습니다.

BM25 이후 발전 방향:

신경망 기반 랭킹 모델:
BERT, T5 같은 대형 언어모델을 이용해 문장 간 의미를 더 깊게 파악합니다.
하이브리드 검색 시스템:
BM25 기반 키워드 검색과 임베딩 기반 의미 검색을 결합하여 서로의 단점을 보완합니다.
의미론적 검색(semantic search):
자연어 질의에 대해 문맥적 의미를 고려해 검색하는 방식이 주류로 떠오르고 있습니다.

8. 실무 적용 팁

Elasticsearch, Vespa 같은 검색엔진에서는 기본 검색 알고리즘으로 BM25를 사용합니다.
파라미터 튜닝:
- k1 값을 높이면 단어 빈도 영향이 커집니다.
- b 값을 높이면 문서 길이 보정이 강해집니다.
작은 데이터셋에서는 기본값 (k1 = 1.5, b = 0.75)으로 시작해도 무방합니다.

9. 참고 자료

✅ 요약 한 줄

TF-IDF는 기본, BM25는 실전형 기준선, 그리고 미래는 신경망 기반 의미 검색이다!

tflite를 사용했을 때 output tensor 모양 확인하기

jinmc — Tue, 4 Mar 2025 14:58:58 +0900

모바일에서 돌아갈수 있는 tflite모델을 돌리는데 있어서 output tensor의 갯수를 맞추는 것도 중요하다고 생각합니다.

import tensorflow as tf

# 모델 파일 로드
interpreter = tf.lite.Interpreter(model_path="efficientdet-lite0.tflite")
interpreter.allocate_tensors()

# 입력 및 출력 텐서 정보 가져오기
input_details = interpreter.get_input_details()
output_details = interpreter.get_output_details()

print("Input Details:", input_details)
print("Output Details:", output_details)

그럼 결과가 이런식으로 나오게 됩니다.

Input Details: [{'name': 'serving_default_inputs:0', 'index': 0, 
			  'shape': array([  1, 256, 256,   3], dtype=int32), 
              'shape_signature': array([  1, 256, 256,   3], dtype=int32), 
              'dtype': <class 'numpy.float32'>, 'quantization': (0.0, 0), 
              'quantization_parameters': {'scales': array([], dtype=float32), 
              'zero_points': array([], dtype=int32), 'quantized_dimension': 0}, 
              'sparsity_parameters': {}}]
Output Details: [{'name': 'StatefulPartitionedCall:0', 'index': 431, 
				  'shape': array([    1, 12276,     4], dtype=int32), 
                  'shape_signature': array([    1, 12276,     4], dtype=int32), 
                  'dtype': <class 'numpy.float32'>, 'quantization': (0.0, 0), 
                  'quantization_parameters': {'scales': array([], dtype=float32), 
                  'zero_points': array([], dtype=int32), 'quantized_dimension': 0}, 
                  'sparsity_parameters': {}}, {'name': 'StatefulPartitionedCall:1', 
                  'index': 429, 'shape': array([    1, 12276,    19], dtype=int32), 
                  'shape_signature': array([    1, 12276,    19], dtype=int32), 
                  'dtype': <class 'numpy.float32'>, 'quantization': (0.0, 0), 
                  'quantization_parameters': {'scales': array([], dtype=float32), 
                  'zero_points': array([], dtype=int32), 'quantized_dimension': 0}, 
                  'sparsity_parameters': {}}]

보면, output shape이 [1, 12276, 19] 이렇게 나오는데, 20이 class output length입니다.

Mediapipe Model Maker를 이용한 Object Detection 실습기

jinmc — Thu, 13 Feb 2025 10:20:31 +0900

1. 시작: TFLite Model Maker의 문제

원래는 TFLite Model Maker를 이용해서 Object Detection 모델을 학습하려고 했습니다. TFLite Model Maker는 TensorFlow Lite 모델을 간편하게 만들 수 있는 라이브러리로, 데이터셋만 준비하면 비교적 쉽게 모델을 학습하고 변환할 수 있습니다. 하지만 라이브러리를 설치하고 실행하는 과정에서 여러 가지 오류가 발생했습니다.

대표적인 문제는 다음과 같습니다:

라이브러리 의존성 충돌
특정 버전의 TensorFlow Lite와 호환되지 않는 문제
Colab 환경에서 제대로 동작하지 않는 버그

이러한 문제들로 인해 결국 TFLite Model Maker를 포기하고, Mediapipe Model Maker를 활용하기로 결정했습니다.

2. Mediapipe Model Maker로 전환

Mediapipe Model Maker는 Google의 Mediapipe 프레임워크를 활용하여 Object Detection 모델을 학습할 수 있도록 지원하는 도구입니다. Mediapipe는 주로 실시간 컴퓨터 비전에 강점을 가지며, 모바일 및 임베디드 환경에서도 원활하게 동작합니다.

TFLite Model Maker 대신 Mediapipe Model Maker를 선택한 이유는 다음과 같습니다:

Colab 환경에서 원활하게 실행 가능
비교적 간단한 API를 제공
TensorFlow 기반이라 TFLite와 호환 가능

따라서 Mediapipe Model Maker를 활용하여 Object Detection 모델을 학습하고 배포하는 과정을 진행했습니다.

3. Colab에서 Mediapipe Model Maker 실행하기

3.1. 환경 설정 및 라이브러리 설치

Colab에서 Mediapipe Model Maker를 실행하기 위해 필요한 라이브러리를 설치했습니다.

!pip install mediapipe-model-maker

설치 후 의존성 충돌이 발생하지 않는지 확인한 뒤, 다음 단계로 진행했습니다.

3.2. Colab에서 GPU 설정 문제 해결

Colab 환경에서 GPU를 제대로 인식하지 못하는 문제가 발생했습니다. 해결을 위해 다음과 같은 단계를 수행했습니다:

Colab에서 런타임 유형을 변경:
- 런타임 > 런타임 유형 변경 > 하드웨어 가속기를 GPU로 설정
현재 GPU 상태 확인:

import tensorflow as tf
print("Num GPUs Available:", len(tf.config.list_physical_devices('GPU')))

만약 0이 출력되면 GPU가 제대로 인식되지 않은 것임

NVIDIA 드라이버 및 CUDA 버전 확인:

!nvidia-smi

이 명령어를 실행했을 때, GPU 정보가 제대로 표시되지 않으면 런타임을 다시 시작하거나 CPU 모드로 실행한 후 다시 GPU로 변경

TensorFlow 및 Keras 버전 조정 (2.16 이상에서 오류 발생)

!pip install tensorflow[and-cuda]==2.15.1 keras==2.15.0 tensorboard==2.15.2 tensorflow-hub

설치 후 버전 확인:

import tensorflow as tf
import keras

print("TensorFlow Version:", tf.__version__)
print("Keras Version:", keras.__version__)

위 코드에서 TensorFlow 2.15.1, Keras 2.15.0이 제대로 표시되면 정상적으로 설정된 것임

위 과정을 거친 후, GPU가 정상적으로 인식되었음을 확인한 뒤 학습을 진행했습니다.

3.3. 데이터셋 준비

Object Detection을 위해 적절한 데이터셋이 필요했습니다. 이번 실험에서는 3마리 개(dog)를 식별하는 모델을 만들기로 했습니다. 데이터를 수집하고 라벨링하는 과정은 다음과 같습니다:

Open Images Dataset 또는 기존 이미지 데이터를 활용
이미지와 바운딩 박스를 포함한 라벨링 파일(.csv 또는 .json) 준비
Mediapipe Model Maker의 데이터 포맷에 맞게 변환

데이터셋 다운로드 및 준비 과정은 다음과 같이 진행했습니다:

!wget https://storage.googleapis.com/mediapipe-assets/dogs2.zip --no-check-certificate
!unzip dogs2.zip

train_dataset_path = "dogs/train"
validation_dataset_path = "dogs/validate"

train_data = object_detector.Dataset.from_pascal_voc_folder(
    'dogs copy/train',
    cache_dir="/tmp/od_data/train",
)

val_data = object_detector.Dataset.from_pascal_voc_folder(
    'dogs copy/validate',
    cache_dir="/tmp/od_data/validatation"
)

Open Images Dataset 또는 기존 이미지 데이터를 활용
이미지와 바운딩 박스를 포함한 라벨링 파일(.csv 또는 .json) 준비
Mediapipe Model Maker의 데이터 포맷에 맞게 변환

3.4. 모델 학습

데이터 준비가 끝난 후, Mediapipe Model Maker를 사용하여 학습을 시작했습니다. 간단한 코드 예제는 다음과 같습니다.

from mediapipe_model_maker import object_detector

# 하이퍼파라미터 설정
hparams = object_detector.HParams(batch_size=8, learning_rate=0.3, epochs=50, export_dir='exported_model')
options = object_detector.ObjectDetectorOptions(
    supported_model=object_detector.SupportedModels.MOBILENET_V2,
    hparams=hparams
)

# 모델 생성 및 학습
model = object_detector.ObjectDetector.create(
    train_data=train_data,
    validation_data=val_data,
    options=options
)

Mediapipe Model Maker는 EfficientDet 기반의 다양한 모델을 지원하며, 원하는 모델을 선택하여 학습할 수 있습니다.

3.5. 모델 평가 및 변환

학습이 완료된 후, 모델을 평가하고 TFLite 포맷으로 변환하여 모바일 환경에서 사용할 준비를 했습니다.

# 모델 평가
metrics = model.evaluate(val_data)
print("Evaluation metrics:", metrics)

# TFLite 변환
model.export(export_dir='exported_model')

4. 결론 및 느낀 점

이번 실험을 통해 Mediapipe Model Maker를 사용하여 Object Detection 모델을 성공적으로 학습할 수 있었습니다. 처음에는 TFLite Model Maker를 사용하려고 했지만, 여러 가지 문제로 인해 Mediapipe Model Maker로 전환했고, 결과적으로 더 간편하고 빠르게 모델을 만들 수 있었습니다.

Mediapipe Model Maker의 장점:

✅ Colab 환경에서 쉽게 실행 가능 ✅ TensorFlow Lite와 호환되어 모바일 배포 가능 ✅ 직관적인 API 제공

하지만 단점도 있었습니다: ❌ 공식 문서가 상대적으로 부족하여 디버깅이 어려운 부분이 있음 ❌ 일부 고급 기능(예: 커스텀 모델 구조 변경)에 제약이 있음 ❌ Colab에서 GPU 설정이 원활하지 않아 추가적인 설정이 필요함

앞으로는 Mediapipe Model Maker의 다양한 기능을 더 실험해보고, 실제 프로젝트에 적용할 방법을 모색해볼 계획입니다. Mediapipe Model Maker를 활용하여 Object Detection을 고려하는 분들에게 도움이 되었길 바랍니다!

AWS RAG Agent 워크샵

jinmc — Wed, 12 Feb 2025 14:50:12 +0900

aws를 이용해서 streamlit, bedrock, lamda를 이용해서 application을 만드는 워크샵입니다.

https://github.com/kwangwl/amazon-bedrock-workshop/blob/main/stock_agent_workshop/guardrails.py

amazon-bedrock-workshop/stock_agent_workshop/guardrails.py at main · kwangwl/amazon-bedrock-workshop

amazon-bedrock-workshop. Contribute to kwangwl/amazon-bedrock-workshop development by creating an account on GitHub.

github.com

AWS를 활용하여 Streamlit, Bedrock, Lambda를 이용해 AI 애플리케이션을 구축하는 워크샵입니다. 이 워크샵에서는 AWS의 강력한 AI 및 서버리스 기능을 활용하여 실전 프로젝트를 진행하며, RAG(Retrieval-Augmented Generation) 기법을 적용한 지능형 애플리케이션을 만들어봅니다.

워크샵 개요

이 워크샵에서는 AWS의 다양한 서비스를 조합하여 LLM 기반 애플리케이션을 구축하는 방법을 배웁니다. RAG 기술을 활용해 정보를 검색하고, 대형 언어 모델(LLM)을 통해 보다 정확하고 맥락에 맞는 응답을 생성하는 시스템을 구축합니다.

주요 학습 내용

Streamlit: 직관적인 사용자 인터페이스(UI) 개발
Amazon Bedrock: LLM을 활용한 자연어 처리 및 AI 기능 적용
AWS Lambda: 서버리스 컴퓨팅을 활용한 API 및 데이터 처리
Amazon S3 & DynamoDB: 데이터를 저장하고 효율적으로 관리하는 방법
RAG (Retrieval-Augmented Generation): 검색과 생성 모델을 결합하여 최적화된 응답을 생성하는 방법
보안 및 배포 전략: AWS IAM을 활용한 보안 관리 및 애플리케이션 배포 전략

워크샵에서 배우는 내용

1. Streamlit을 활용한 대화형 웹 애플리케이션 제작

Streamlit을 사용하여 간단한 UI를 구축하는 방법
사용자 입력을 받아 AI 모델과 연동하는 방식

2. Amazon Bedrock을 사용한 LLM 기반 AI 활용

Amazon Bedrock에서 제공하는 다양한 AI 모델을 탐색
LLM을 활용하여 자연어 처리를 수행하는 방법

3. Lambda를 이용한 API 연결 및 서버리스 환경 구성

Lambda를 통해 요청을 처리하고 데이터를 반환하는 방식
서버리스 환경에서 비용 효율적으로 AI 서비스를 운영하는 방법

4. RAG 기법을 적용한 검색 및 응답 최적화

Amazon OpenSearch 또는 자체 데이터베이스를 이용하여 검색 기능 강화
RAG 모델을 활용해 기존 LLM보다 높은 정확도의 응답을 생성하는 방법

5. 보안 및 데이터 보호 가이드라인 적용

AWS IAM을 활용한 권한 및 인증 관리
데이터 보안 및 개인정보 보호를 고려한 AI 서비스 운영 방법

실습 및 코드 예제

워크샵에서는 단계별 실습을 통해 AI 애플리케이션을 직접 구축해볼 수 있습니다. 실습 과정에서 사용할 예제 코드와 가이드라인은 아래 GitHub 링크에서 확인할 수 있습니다.

AWS RAG Agent 워크샵 GitHub Repository

이 워크샵을 통해 AWS의 다양한 AI 및 서버리스 서비스를 활용하여 실제 애플리케이션을 구축하는 경험을 쌓고, AI 기반 서비스의 가능성을 탐색할 수 있습니다!