AI 자동화 연구소

목차 MCP의 정의와 등장 배경 호스트·클라이언트·서버 구조 프리미티브와 JSON-RPC 흐름 도구 발견·호출과 전송 방식 활용 예시 결론 MCP의 정의와 등장 배경 이 글은 MCP를 특정 서비스의 사용법이 아니라, AI 애플리케이션과 외부 도구를 연결하는 표준 구조로 이해하는 것을 전제로 합니다. MCP(Model Context Protocol)는 AI 애플리케이션이 파일, 데이터베이스, API, 업무 도구 등의 기능과 정보를 일정한 방식으로 주고받도록 정한 프로토콜입니다. 기존에는 AI 서비스마다 파일, 데이터베이스, API 같은 도구와 연결하는 방식을 따로 구현해야 했습니다. 서비스와 도구의 조합이 늘어날수록 연결 코드를 각각 유지해야 하는 부담도 커집니다. MCP는 공통 규격을 제공해 연결 코드를 재사용하기 쉽게 만들고, AI가 필요한 기능을 탐색한 뒤 호출하는 흐름을 표준화한다는 점에서 실질적인 이점을 제공합니다. 호스트·클라이언트·서버 구조 호스트는 사용자가 대화하는 AI 애플리케이션입니다. 호스트 안의 MCP 클라이언트는 특정 MCP 서버와 연결을 관리하고, MCP 서버는 파일 검색이나 데이터 조회처럼 외부 시스템에 접근할 수 있는 기능을 제공합니다. 비유하면 호스트는 사무실, 클라이언트는 담당 연락 창구, 서버는 외부 협력업체에 가깝습니다. 이 구조에서는 호스트가 시스템마다 다른 연결을 직접 구현하지 않습니다. 호스트는 MCP 클라이언트를 통해 서버와 통신하고, 클라이언트는 서버가 공개한 기능과 데이터를 호스트에 전달하며 MCP 메시지를 주고받습니다. 서버는 정해진 요청만 처리하므로 기능별 권한과 책임을 분리하기 쉽습니다. 다만 MCP가 자동으로 보안을 보장하는 것은 아니므로 서버 권한, 입력 검증, 인증·권한·네트워크 보안 설정을 별도로 관리해야 합니다. 프리미티브와 JSON-RPC 흐름 MCP 서버가 제공하는 핵심 프리미티브는 Tools, Resources, Prompts입니다. Tools는 AI가 인자를 넘겨 실...

목차 먼저 알아둘 전제 일반 챗봇은 어떻게 동작할까? AI 에이전트의 동작 원리 Tool 사용 능력과 작업 범위 기억과 컨텍스트 관리 자율적 계획과 의사결정 결론 최근 AI 기술의 발전은 챗봇과 AI 에이전트라는 두 가지 주요 형태로 나타나고 있습니다. 이 둘은 모두 언어 모델을 기반으로 하지만, 작동 방식과 활용 목표에서 중요한 차이를 가집니다. 이 글에서는 챗봇과 에이전트의 근본적인 차이점과 각각의 특징을 살펴보며, 어떤 상황에서 어떤 방식이 더 적합한지 안내합니다. 먼저 알아둘 전제 구분 챗봇 (Chatbot) AI 에이전트 (AI Agent) 목표 사용자 질의에 대한 답변 생성 목표 달성 을 위한 작업 수행 외부 도구 사용 제한적 또는 선택적 Tool 을 통한 외부 시스템 연동 작업 방식 단일 질의-응답 다단계 작업 및 계획 수정 자율성 낮음 (정해진 범위 내 응답) 상대적으로 높음 (상황 판단 및 의사결정) 이 글은 AI 에이전트를 특정 서비스나 제품이 아닌, 언어 모델에 도구 사용과 작업 제어 기능을 결합한 소프트웨어 구조로 설명합니다. 구현 방식에 따라 기능과 자율성의 수준은 달라질 수 있습니다. 핵심 차이는 답변 생성에 있습니다. 일반 챗봇은 사용자의 질문에 문장으로 답하는 데 초점을 두지만, AI 에이전트는 목표를 달성하기 위해 상황을 판단하고 필요한 작업을 이어서 수행합니다. 일반 챗봇은 어떻게 동작할까? 일반 챗봇은 사용자의 입력과 이전 대화 내용을 컨텍스트(현재 답변에 참고하는 정보)로 받아 적절한 응답을 생성합니다. 예를 들어 “Docker가 무엇인가요?”라는 질문에 개념과 사용법을 설명하는 식입니다. 대부분의 챗봇은 답변 자체가 처리 결과입니다. 외부 시스템의 데이터를 조회하거나 파일을 수정하는 기능이 연결되지 않았다면, 실제 작업 대신 그 방법을 안내하는 수준에 머뭅니다. AI 에이전트의 동작 원리 AI 에이전트는 먼저 사용자의 목표를 해석하고, ...

AI 음성 기술은 텍스트를 사람처럼 자연스러운 음성으로 바꾸고(TTS), 사람의 말을 정확하게 텍스트로 옮기는(STT) 기술을 통해 인간과 기계가 소통하는 방식을 근본적으로 변화시키고 있습니다. 이 기술은 일상의 편리함을 넘어 정보 접근성을 높이고 새로운 형태의 콘텐츠를 가능하게 합니다. 이 글에서는 AI 음성 기술의 핵심 원리를 살펴보고, 다양한 활용 사례를 통해 그 가치를 조명합니다. 목차 음성 생성(TTS)의 기본 원리 음성 인식(STT)의 기본 원리 음성 기술을 구동하는 주요 딥러닝 모델 AI 음성 기술의 핵심 활용 사례 결론 음성 생성(TTS)의 기본 원리 음성 생성(Text-to-Speech, TTS)은 글자를 소리로 바꾸는 기술입니다. 이 과정은 입력된 텍스트를 음운학적 단위로 분석해 음소(phoneme) 같은 음성 표현으로 변환하는 단계로 시작합니다. 이 음성 표현을 기반으로 AI 모델은 멜 스펙트로그램(mel spectrogram)과 같은 음향 특징을 생성하고, 마지막으로 보코더(vocoder)가 이 음향 특징을 실제 사람의 음성과 유사한 음향 파형으로 합성하여 소리로 출력합니다. 음성 인식(STT)의 기본 원리 음성 인식(Speech-to-Text, STT)은 사람의 음성을 글자로 변환하는 기술입니다. 이 기술은 마이크를 통해 들어온 음성 신호에서 특징을 추출한 뒤, AI 모델이 소리의 패턴과 언어적 문맥을 함께 분석하여 가장 가능성 높은 텍스트를 생성합니다. 주변 소음이나 말하는 사람의 특성에도 영향을 덜 받으며 잘 작동하는 것이 중요합니다. 음성 기술을 구동하는 주요 딥러닝 모델 AI 음성 기술의 핵심에는 방대한 데이터를 학습한 딥러닝 모델이 있습니다. 음성 생성(TTS) 분야에서는 Tacotron, FastSpeech, VITS 같은 모델과 트랜스포머(Transformer) 기반 아키텍처가 주로 활용됩니다. 최근에는 확산(Diffusion) 및 생성형 음성 모델도 연구되며, 이들은 텍스트의 문맥적 특징을 반영하여...

썸네일에 넣은 글자가 자꾸 깨져서 다른 도구로 옮겼더니, 이번엔 인물 피부가 플라스틱처럼 나옵니다. 2026년의 이미지 생성 도구는 "어느 것이 제일 좋은가"로 답이 안 나옵니다. 나쁜 도구가 거의 사라진 대신, 모델마다 실패하는 지점이 다르기 때문입니다. 구도가 달라진 이유 몇 년 전의 Midjourney·Stable Diffusion·Flux 3파전은 이제 유효하지 않습니다. OpenAI와 Google이 자사 챗봇에 이미지 모델을 직접 붙였고, 2026년 4월 21일 나온 GPT-Image-2는 공개 시점에 Image Arena 리더보드 1위를 기록했습니다. 동시에 강점이 갈라져서, 실무에서는 하나만 쓰기보다 작업마다 갈아타는 방식이 일반적입니다. 판단 축은 네 가지입니다. 이미지 속 글자가 깨지지 않는가, 지시한 배치를 지키는가, 만든 이미지를 부분 수정할 수 있는가, 비용과 라이선스가 내 용도에 맞는가. "예술적이냐 현실적이냐"는 지금은 프롬프트로 대부분 조절되므로 기준으로서의 힘이 약합니다. 비교표 항목 GPT-Image-2 Gemini(Nano Banana) FLUX.2 Midjourney V8.2 로컬(ComfyUI) 강점 텍스트·레이아웃 통제 실사 질감·조명·속도 대량 생성·멀티 레퍼런스 아트 디렉션·스타일 유지 완전한 통제·장당 비용 0 약한 곳 인물 질감 정밀 배치 지시 진입 난이도(API) 이미지 속 글자 초기 학습·설치 접근 ChatGPT / API Gemini / API API·파트너 플랫폼 웹 + Discord 내 PC 설치 비용 종량제·구독 종량제·구독 종량제 월 $10부터 GPU 초기 비용 세 가지만 덧붙입니다. Midjourney는 2024년 8월부터 웹에서 바로 쓸 수 있습니다. "Discord를 깔아야만 쓴다"는 설명이 아직 많이 돌아다니지만 지금은 틀린 정보입니다. 기본 버전은 20...

반복적인 문서 요약 작업은 많은 시간과 노력을 요구하며, AI 기술을 활용하면 이러한 과정을 더욱 효율적으로 자동화할 수 있습니다. 이 글에서는 대규모 언어 모델(LLM)을 기반으로 문서를 효율적으로 처리하고 자동화 파이프라인을 구축하는 실질적인 방법을 소개합니다. 목차 AI 자동화의 핵심: 대규모 언어 모델 (LLM) 기본 정확한 결과물을 위한 프롬프트 엔지니어링 기초 자동화 구현 전략: 문서/텍스트 전처리 기법 자동화 구현 전략: API 연동 및 활용 자동화 구현 전략: LLM 출력 후처리 결론 AI 자동화의 핵심: 대규모 언어 모델 (LLM) 기본 대규모 언어 모델(LLM)은 방대한 양의 텍스트 데이터를 학습하여 사람의 언어를 이해하고 생성하는 AI입니다. 이 모델들은 복잡한 문맥을 파악하고, 다양한 유형의 질문에 답변하며, 요청에 따라 요약, 번역, 글쓰기와 같은 작업을 수행할 수 있습니다. LLM은 단순히 단어를 나열하는 것을 넘어, 문장의 의미와 의도를 파악하여 맥락에 맞는 적절한 결과물을 도출합니다. 이러한 능력은 문서 자동화 작업에 매우 중요한 역할을 합니다. 정확한 결과물을 위한 프롬프트 엔지니어링 기초 프롬프트 엔지니어링은 AI 언어 모델에게 원하는 결과물을 얻기 위해 효과적인 명령(프롬프트)을 설계하는 기술입니다. LLM은 일관된 문맥을 유지할 수 있으나, 때때로 사실 오류를 포함할 수 있으므로, 명확하고 구체적인 지시를 통해 모델의 잠재력을 최대한 끌어내고 정확도를 높여야 합니다. 역할 부여, 예시 제공, 제약 조건 명시 등의 기법이 활용됩니다. 예를 들어, 단순히 '문서 요약해 줘' 대신 '당신은 전문 편집자입니다. 다음 보고서를 300자 이내로 핵심 내용만 요약하고, 일반 독자가 이해하기 쉽게 작성해주세요'와 같이 구체적인 역할을 부여하고 길이를 제한하면 훨씬 더 정확하고 유용한 결과물을 얻을 수 있습니다. 자동화 구현 전략: 문서/텍스트 전처리 기법 LLM에 텍스트를 전달하기...

AI 무료와 유료 서비스는 단순한 가격 차이를 넘어 모델 성능, 응답 속도, 데이터 처리 등 핵심적인 영역에서 큰 차이를 보인다. 많은 사용자가 AI 도구를 경험하며 무료 서비스의 한계에 부딪히거나, 유료 전환의 필요성을 느끼는 경우가 많다. 이 글은 기본적인 AI 서비스 사용 경험이 있거나 AI 도구 도입에 관심 있는 IT 입문~중급자를 대상으로, 두 서비스 유형의 실질적인 차이점을 비교 분석한다. 비교 항목 무료 AI 서비스 유료 AI 서비스 모델 성능 구형 또는 제한된 기능의 모델 최신, 고성능 AI 언어 모델 사용량 제한 엄격한 횟수 및 토큰 제한 높은 한도, 종량제 선택 가능 응답 속도 지연 발생 가능성 높음 빠르고 안정적인 응답 속도 데이터 보안 서비스마다 정책 상이 서비스·요금제별 정책 상이, 기업용 보안 기능 제공 가능 목차 모델 성능 및 최신 버전 사용량 제한 및 과금 방식 응답 속도와 처리 우선순위 데이터 처리 및 개인 정보 보호 당신에게 맞는 AI 서비스 선택하기 결론 모델 성능 및 최신 버전 유료 AI 서비스는 일반적으로 최신 AI 모델과 고급 기능을 더 넓은 범위에서 제공하는 경우가 많다. 이 모델들은 방대한 데이터를 학습하여 복잡한 질문 이해, 추론 능력, 창의적인 콘텐츠 생성 등에서 뛰어난 성능을 발휘한다. 반면 무료 서비스는 구형 모델을 제공하거나, 최신 모델의 기능을 제한된 형태로만 제공하는 경우가 많다. 이러한 차이는 복잡한 작업이나 긴 문맥을 처리할 때 답변의 품질 차이로 이어질 수 있다. 중요한 업무나 고품질의 결과물이 필요한 경우, 유료 서비스의 최신 모델이 더 안정적인 결과를 제공하는 경향이 있다. 사용량 제한 및 과금 방식 무료 AI 서비스는 대부분 엄격한 사용량 제한을 둔다. 하루에 처리할 수 있는 질문 수, 한 번에 입력할 수 있는 글자(토큰) 수, 혹은 특정 기능의 사용 횟수 등이 제한될 수 있다. 이러한 제한은 일상적인 가벼운 사용...

홈 NAS는 이제 단순한 파일 저장 장치를 넘어, 개인용 데이터 센터이자 자동화 서버의 핵심으로 자리 잡았습니다. 수많은 데이터를 안전하게 보관하고, 다양한 서비스를 24시간 운영하기 위해 어떤 NAS 플랫폼을 선택해야 할지 고민하는 분들이 많을 것입니다. 목차 NAS 선택의 주요 기준 Synology와 QNAP 비교표 Synology의 강점과 약점 QNAP의 강점과 약점 사용 상황별 선택 가이드 결론 NAS 선택의 주요 기준 NAS는 단순히 파일을 저장하는 것 이상으로, 미디어 서버, 백업 솔루션, 심지어는 웹 서버나 애플리케이션 플랫폼으로 활용될 수 있습니다. 특히 Docker와 같은 컨테이너 기술을 활용하면 그 활용 범위는 더욱 넓어집니다. 따라서 NAS를 선택할 때는 OS의 사용 편의성, 하드웨어 사양, 확장성, 그리고 애플리케이션 생태계와 Docker 지원 여부를 중요하게 고려해야 합니다. 저의 UGREEN DXP4800 Plus NAS는 단순 파일 서버를 넘어 kiwoom-bot , shorts-trend , n8n 같은 다양한 자동화 컨테이너를 Docker Compose로 운영하는 핵심 서버 역할을 합니다. PostgreSQL 데이터베이스까지 24시간 구동되죠. 이처럼 NAS를 단순히 저장 장치가 아닌 상시 구동되는 서버로 활용하려면, OS의 안정성과 Docker 지원 여부, 그리고 충분한 하드웨어 자원이 매우 중요합니다. Synology와 QNAP 비교표 Synology와 QNAP은 홈 NAS 시장의 대표적인 두 제조사입니다. 각 플랫폼의 특징을 비교표를 통해 살펴보겠습니다. 비교 항목 Synology (시놀로지) QNAP (큐냅) OS/UI DSM(DiskStation Manager), 직관적, 안정적 QTS(QNAP Turbo Station), 기능 풍부, 복잡 성능/하드웨어 보급형 모델 중심, 적당한 성능 고성능 모델 다양, 강력한 하드웨어 앱 생태계 사용자 친화적, 풍부한 ...

AI 언어 모델을 활용해 주식 자동매매 봇 개발을 시작하는 것은 매력적인 아이디어였습니다. 초기 개발 시간을 크게 단축할 수 있을 것이라는 기대감은 현실의 복잡한 기술적, 시장적 변수 앞에서 중요한 교훈을 안겨주었습니다. 이 글은 키움증권 Open API+를 활용한 자동매매 봇 개발 과정에서 AI 언어 모델을 사용하며 겪었던 경험을 공유합니다. 이 글은 투자 손실 위험에 대한 면책 문구를 포함하며, 실제 투자 결과보다는 기술 구현 과정에 초점을 맞춥니다. 또한, 키움 API는 Windows 32bit 환경이 필수라는 점을 전제로 합니다. 목차 AI가 단축시킨 개발 초반 현실과 부딪힌 AI 코드 AI 전략과 현실 시장의 괴리 결론 및 교훈 AI가 단축시킨 개발 초반 처음 자동매매 봇 개발을 구상했을 때, AI 언어 모델은 매력적인 출발점이었습니다. 기본적인 파이썬(Python) 코드 구조, 데이터베이스 연동(SQLite 또는 PostgreSQL), 스케줄링 로직 등 반복적인 초기 코드를 생성하는 데 많은 시간을 절약할 수 있었습니다. 특히, 기본적인 UI 구성(PyQt5)이나 웹 요청 처리 같은 일반적인 프로그래밍 패턴은 AI의 도움으로 빠르게 초안을 만들 수 있었습니다. AI 언어 모델은 키움 API 연동 코드 초안을 생성하는 데도 기여했습니다. 키움 API의 기본적인 함수 호출 방식이나 이벤트 처리 구조에 대한 파이썬 스켈레톤 코드를 제시했습니다. 덕분에 API 문서를 처음부터 전부 읽고 이해하는 시간을 절약하고, 실제 구현에 빠르게 착수할 수 있었습니다. 현실과 부딪힌 AI 코드 그러나 AI가 생성한 키움 API 연동 코드는 실제 작동 가능한 수준까지 많은 수정이 필요했습니다. 키움 API는 윈도우(Windows) 전용 32비트 환경과 파이썬의 PyQt5를 통한 COM 객체 연동이라는 특수성을 가집니다. AI 언어 모델은 이러한 낮은 수준의 운영체제 및 COM 인터페이스의 세부 동작을 정확히 이해하고 반영하지 못했습니다. 결국, 개...

블로그 글을 코드로 자동 발행하려면 Blogger API와 OAuth 2.0 인증이 필요합니다. 실제로 이 블로그를 운영하는 자동화 서버가 사용하는 흐름을 기준으로, 액세스 토큰 발급부터 글 생성과 공개 전환까지 정리합니다. 이 글의 가정 : Google 계정과 Blogger 블로그가 있고, Google Cloud에서 OAuth 클라이언트(client_id, client_secret)와 refresh token을 이미 발급받았다고 가정합니다. 발급 절차 자체는 Google 공식 인증 흐름을 따릅니다. 비밀값은 코드에 직접 쓰지 말고 환경변수로 관리합니다. OAuth 2.0 refresh token 흐름 refresh token(장기 보관용 재발급 토큰)은 한 번 발급받아 두고, API를 호출할 때마다 짧은 수명의 access token(실제 요청에 쓰는 접근 토큰)으로 교환해서 사용합니다. 즉 "refresh token → access token → API 호출" 순서입니다. 액세스 토큰 발급 토큰 교환은 Google 토큰 엔드포인트에 grant_type=refresh_token 으로 요청합니다. 아래는 비동기 HTTP 클라이언트 httpx를 사용한 예입니다. import os, httpx TOKEN_URL = "https://oauth2.googleapis.com/token" API_BASE = "https://www.googleapis.com/blogger/v3" async def get_access_token(): async with httpx.AsyncClient(timeout=10.0) as client: resp = await client.post(TOKEN_URL, data={ "client_id": os.environ["BLOGGER_CLIENT_ID"], "clie...

유튜브 쇼츠를 직접 촬영하지 않고 Python으로 자동 생성하는 시스템을 실제로 운영하고 있다. UGREEN DXP4800PLUS NAS에서 YouTube API로 트렌드 데이터를 수집하고, 성장률 분석 → 주제 선정 → 대본 생성 → 음성 합성 → 영상 합성까지 자동으로 처리한다. 현재 약 1,100개 영상 데이터를 수집 중이며, 30분마다 트렌드 분석을 수행한다. 이 글은 그 파이프라인 전체 구조와 실제로 막혔던 부분들을 정리한다. 전체 파이프라인 구조 YouTube API ↓ PostgreSQL (영상 데이터 저장) ↓ 성장률 분석 (6시간 / 24시간) ↓ AI 언어 모델 (대본 생성) ↓ Edge-TTS (한국어 음성 합성) ↓ FFmpeg (자막 + 배경 합성) ↓ drafts/ 폴더 저장 ↓ 수동 검토 ↓ YouTube 업로드 각 단계가 독립적인 Python 스크립트로 구성돼 있어서 문제가 생긴 단계만 수정하고 나머지는 그대로 쓸 수 있다. 1. PostgreSQL에서 트렌드 주제 선정 단순히 조회수 높은 영상이 아니라 6시간 성장률 기준으로 지금 뜨는 주제를 고른다. 성장률 계산 구조는 이전 글 PostgreSQL로 YouTube 조회수 성장률 계산하기 에서 다뤘다. import asyncpg async def get_trending_topics(): conn = await asyncpg.connect(DATABASE_URL) rows = await conn.fetch(""" SELECT v.title, v.content_cluster, s.growth_6h FROM videos v JOIN video_snapshots s ON v.video_id = s.video_id WHERE s.recorded_at = (SELECT MAX(recorded_at) FROM video_snapshots) ...

YouTube 쇼츠 트렌드를 분석하면서 깨달은 게 있다. 조회수 자체는 별로 의미가 없다는 것이다. 조회수 100만짜리 영상도 6개월 전에 터진 거라면 지금 트렌드가 아니다. 반면 조회수 5,000인 영상이 어제 올라와서 24시간 만에 5,000이 찍혔다면 지금 뜨는 영상이다. 그래서 조회수 대신 성장률 을 기준으로 트렌드를 판단하는 구조를 만들었다. 현재 UGREEN DXP4800PLUS NAS에서 운영 중인 시스템에는 영상 약 1,100개, 스냅샷 약 74,000개가 쌓여 있다. 이 글은 그 구조를 만든 이유와 실제 PostgreSQL 쿼리를 정리한다. 왜 YouTube 조회수 스냅샷 방식이 필요한가 처음에는 단순하게 접근했다. 영상 정보를 수집할 때 현재 조회수를 같이 저장하면 된다고 생각했다. 문제는 바로 드러났다. 오늘 조회수: 12,000 어제 조회수: 알 수 없음 (덮어쓰여서 사라짐) 현재 값만 저장하면 변화량을 계산할 수 없다. 성장률은 이전 값과 현재 값의 차이 에서 나온다. 그래서 조회수를 덮어쓰는 대신 시간마다 찍어서 쌓는 스냅샷 방식을 선택했다. PostgreSQL 테이블 구조 설계 핵심 테이블은 두 개다. -- 영상 기본 정보 CREATE TABLE videos ( id SERIAL PRIMARY KEY, video_id VARCHAR UNIQUE NOT NULL, title VARCHAR, channel_name VARCHAR, tags TEXT, content_cluster VARCHAR, format_type VARCHAR, collected_at TIMESTAMP DEFAULT NOW() ); -- 시간별 조회수 스냅샷 CREATE TABLE video_snapshots ( id SERIAL PRIMARY KEY, video_id VARCHAR REFERENCES videos(video_id), ...

 처음에는 단순히 유튜브 쇼츠 트렌드를 수집하려고 했다. 그런데 데이터를 저장할 DB가 필요했고, 자동화 워크플로가 필요했고, TTS가 필요했고, 컨테이너 관리가 필요했다. 하나를 해결하면 다음 문제가 보였다. 결국 하나의 AI 자동화 시스템으로 발전했다. 이 글은 UGREEN DXP4800PLUS NAS 위에서 실제로 운영 중인 AI 자동화 시스템의 전체 구조를 정리한 글이다. 각 컴포넌트를 왜 선택했는지, 어떻게 연결했는지를 중심으로 설명한다. 각 기술의 상세 내용은 개별 글 링크로 연결한다. 전체 아키텍처 YouTube API ↓ Collector (수집기) ↓ PostgreSQL (데이터 저장) ↓ FastAPI (대시보드 + API) ↓ Edge-TTS (음성 생성) ↓ Video Generator (영상 합성) ↓ drafts 폴더 저장 n8n (워크플로 자동화) ↓ Telegram (알림) 모든 서비스는 UGREEN DXP4800PLUS NAS에서 Docker 컨테이너로 운영된다. 왜 NAS를 선택했는가 클라우드 서버를 쓰면 월 고정 비용이 발생한다. 여러 서비스를 동시에 운영하면 비용이 빠르게 늘어난다. UGREEN DXP4800PLUS는 현재 20개 이상의 Docker 컨테이너를 동시에 운영하면서도 CPU와 메모리에 여유가 있다. 초기 구매 비용이 있지만 월 운영 비용은 전기세뿐이다. Docker 계층: 모든 서비스의 기반 Docker가 없었다면 PostgreSQL, FastAPI, n8n을 각각 별도로 설치하고 관리해야 했다. Docker Compose로 각 서비스를 컨테이너 단위로 격리하고 하나의 스택으로 관리한다. NAS 재부팅 후에도 restart: unless-stopped 설정으로 모든 서비스가 자동 복구된다. 처음 구축할 때 depends_on 만으로는 서비스 시작 순서가 보장되지 않는다는 것을 겪었다. healthchec...

 매일 아침 정책자금 공고를 직접 찾아보는 게 번거로웠다. 기업마당(bizinfo.go.kr)에 매일 새로운 공고가 올라오는데 일일이 확인하기가 쉽지 않았다. n8n으로 자동화하면 되겠다는 생각에 워크플로를 만들었다. 결과적으로 매일 오전 9시에 새로운 정책자금 공고가 Telegram으로 자동 발송되는 시스템이 완성됐다. 이 글에서는 UGREEN DXP4800PLUS NAS에서 운영 중인 n8n으로 Telegram 자동 알림 워크플로를 구축하는 방법을 정리한다. n8n이란 n8n은 노코드/로우코드 워크플로 자동화 도구다. 200개 이상의 서비스와 연동할 수 있고 Docker로 셀프 호스팅이 가능하다. 현재 UGREEN DXP4800PLUS NAS에서 Docker로 운영 중이다. bash docker ps | grep n8n # n8n Up 6 days 0.0.0.0:5678->5678/tcp Telegram Bot 준비 n8n에서 Telegram으로 메시지를 보내려면 먼저 Telegram Bot을 만들어야 한다. 1. BotFather로 봇 생성 Telegram에서 @BotFather 검색 후 대화 시작: /newbot ↓ 봇 이름 입력 (예: MyAlertBot) ↓ 봇 username 입력 (예: my_alert_bot) ↓ API Token 발급 발급된 Token 형식: 1234567890:ABCdefGHIjklMNOpqrSTUvwxYZ 2. Chat ID 확인 봇에게 먼저 아무 메시지나 보내야 getUpdates 결과에 chat.id가 표시된다. 그 다음 아래 URL로 접속하면 된다: `https://api.telegram.org/bot{TOKEN}/getUpdates` n8n 설치 확인 n8n 웹 UI에 접속한다: http://NAS_IP:5678 처음 접속 시 계정 생성 후 로그인하면 워크플로 편집 화면이 나온다. 워크플로 구성 실제 운영 중인 워크플로 구조: Schedule Trig...

 유튜브 쇼츠 트렌드 수집 시스템을 만들면서 YouTube Data API 쿼터가 예상보다 훨씬 빠르게 소진됐다. 하루 10,000유닛이면 충분하다고 생각했는데 글로벌 AI 키워드 수집을 추가하자마자 쿼터 부족 오류가 발생했다. 로그를 분석해보니 원인은 명확했다. search.list 를 과도하게 사용하고 있었다. search.list 와 videos.list 는 같은 YouTube Data API지만 유닛 비용이 100배 차이난다. 이 차이를 이해하기 전까지는 왜 쿼터가 사라지는지 전혀 감이 오지 않았다. 정확히는 검색 속도 문제가 아니라 API 쿼터 비용 문제였다. search.list 호출 비용이 videos.list보다 100배 높아 예상보다 빠르게 할당량이 소진되고 있었다. search.list와 videos.list 차이 두 API의 핵심 차이는 용도와 비용이다. API 용도 유닛 비용 search.list 키워드로 영상 검색 100 유닛 videos.list 영상 ID로 상세 조회 1 유닛 channels.list 채널 정보 조회 1 유닛 search.list 1회 호출 = videos.list 100회 호출과 같은 비용이다. 하루 쿼터 10,000유닛 기준: search.list만 사용: 최대 100번 호출 가능 videos.list만 사용: 최대 10,000번 호출 가능 왜 search.list가 비싼가 search.list 는 단순 데이터 조회가 아니다. 호출할 때마다 내부적으로 복잡한 작업이 실행된다. 키워드 수신 ↓ 검색 인덱스 조회 ↓ 관련성 계산 ↓ 랭킹 정렬 ↓ 필터링 적용 ↓ 결과 반환 반면 videos.list 는 영상 ID를 기반으로 데이터베이스에서 직접 조회한다. 훨씬 단순한 작업이라 비용이 낮다. 잘못된 사용 패턴 가장 흔한 실수는 이미 수집한 영상이 있는데도 매번 같은 키워드로 search.list를 반복 호출하는 것이다.  신규 영상이 없어도 실행할 때마다 100유닛이 소비된...