30개의 MCP 서버를 사용해봤습니다... 모든 바이브 코더에게 필요한 9가지

Sean Kochel 구독자 2,190명

요약

AI 기반 개발 워크플로우에서 속도만으로는 지속 가능한 성과를 낼 수 없습니다. 이 영상에서는 영상 제작자 Sean이 수십 가지 MCP 서버를 시험해보고 매주 실제로 사용하는 9가지 MCP 서버를 소개합니다. 각 도구가 어떤 역할을 수행하는지, 현업에서 어떻게 활용할 수 있는지 실용적인 예시와 함께 설명하며, AI 코딩을 구조적으로 관리하는 핵심 가이드를 제공합니다.

주요 키워드

Linear Perplexity GitHub MCP Supabase Context7 Playwright Semgrep Vibe Check Pieces Vibe coding

하이라이트

🔑 구체적이고 체계적인 이슈 관리를 위해 Linear MCP를 사용해 백로그에 자동으로 티켓을 추가하고 우선순위를 매길 수 있습니다.
⚡️ Perplexity MCP는 새로운 기능 연구와 디버깅 단계에서 최적의 접근 방식을 제안해 개발 효율을 높입니다.
🌟 GitHub MCP를 활용하면 브랜치 관리·이슈 생성·풀 리퀘스트 자동화로 버전 관리를 체계화할 수 있습니다.
📌 Supabase MCP로 테이블 상태와 엔트리를 실시간 조회해 SQL 없이도 데이터베이스 구조와 데이터를 빠르게 이해합니다.
🚀 Context7 MCP는 라이브러리·프레임워크 문서를 최신화해 LLM이 잘못된 가정(환각)을 하지 않도록 방지합니다.
🛠 Playwright MCP를 이용한 자기 채점 UI는 자동으로 스냅샷을 비교·검증해 인터페이스 품질을 반복적으로 개선합니다.
🔐 Semgrep MCP로 코드베이스 전반의 보안 취약점을 자동 스캔하고 종속성을 점검해 보안 리스크를 줄입니다.
🔄 Vibe Check MCP는 패턴 관성과 사고의 고착화를 막기 위해 개발 중간마다 반성 지점을 삽입해 계획을 재조정합니다.
🧠 Pieces MCP는 로컬 환경에서 개발 과정을 '메모리'로 저장해 과거 해결책을 빠르게 검색하고 회상으로 생산성을 높입니다.

용어 설명

MCP 서버

AI 기반 에이전트가 외부 서비스나 도구와 상호작용하도록 중재하는 미들웨어 구성 요소

바이브 코딩(Vibe coding)

AI 언어 모델을 효율적으로 활용해 직관적이고 반응적인 개발 워크플로우를 만드는 방식

백로그(backlog)

개발 중 발생한 버그·개선사항·기능 요청을 기록하고 우선순위를 매겨 관리하는 목록

자기 채점 UI(Self-grading UI)

Playwright 등으로 브라우저 스냅샷을 기준 삼아 자동으로 품질을 검증·반복 개선하는 시스템

패턴 관성(pattern inertia)

LLM이 초기 계획을 수정 없이 지속하면서 비효율적·과도한 구조로 이어지는 현상

환각(hallucination)

LLM이 존재하지 않는 함수나 잘못된 정보를 자신 있게 생성하는 오류

• 수천 개 MCP 서버 사이에서 올바른 도구를 찾는 고충을 공유합니다. • Sean의 경력(스타트업·마케팅 스케일업)을 바탕으로 실무에 바로 적용 가능한 튜토리얼을 약속합니다. • 영상에서 다룰 9가지 MCP 서버와 활용 방안을 미리 안내합니다.

[00:00] YouTube 크리에이터 Sean이 자신이 실제로 사용해본 수십 개의 MCP 서버 중에서 매주 사용하는 톱 9를 소개하겠다고 말하며, 실용적인 개발 워크플로우에 도움이 되는 것들을 중심으로 설명할 예정이라고 언급합니다.

• 개발 도중 발생하는 버그·기능 아이디어를 Linear에서 이슈로 즉시 기록합니다. • 우선순위 기반 백로그 관리로 '빌딩 모드'와 '수정 모드'를 구분해 워크플로우를 체계화합니다. • Claude 연동 예시를 통해 자동 티켓 생성·코드 스니펫 첨부·우선순위 결정 과정을 보여줍니다.

[01:37] 첫 번째 MCP인 Linear를 소개하며, 이슈 추적과 기능 빌드 관리, 백로그 관리를 통해 더 빠르고 체계적인 개발을 가능하게 한다고 설명합니다. Claude에게 앱 성능 분석을 요청하는 예시를 들어 Linear MCP의 실용적 활용법을 보여줍니다.

[02:37] Linear MCP를 사용한 백로그 관리의 중요성에 대해 설명하며, 개발 과정에서 발생하는 문제들을 체계적으로 우선순위를 정하고 관리할 수 있다는 점을 강조합니다.

[03:04] 실제 사례를 통해 데이터베이스 쿼리, 프론트엔드 캐싱 등의 문제를 Linear MCP를 활용해 우선순위별로 정리하고 티켓을 생성하는 과정을 보여줍니다.

[04:01] 나중에 맥락 없이 프로젝트에 돌아왔을 때도 Linear MCP를 통해 이전 문제를 다시 불러와 요약하고 구현 계획을 세울 수 있는 장점을 설명합니다.

[04:37] AI 코딩의 빠른 속도로 인한 혼란을 방지하기 위해 체계적인 시스템의 필요성을 강조하며, 지속 가능한 AI 개발을 위한 Linear의 역할을 정리합니다.

• 전문 분야가 아닐 때도 Perplexity로 최신 베스트 프랙티스를 조사합니다. • 새로운 기능 설계나 버그 해결 방안을 인터넷 상 사례와 함께 제안받아 효율적으로 학습합니다. • Gemini API 기반 이미지 객체 인식·inpainting 워크플로우 추천 예시로 실제 활용법을 설명합니다.

[05:05] 다음 도구인 Perplexity MCP를 소개하며, 특히 전문가가 아닌 분야에서 새로운 기능을 연구할 때의 가치에 대해 언급합니다.

[05:20] 에이전트 개발에 익숙하지 않은 개발자들이 패턴과 모범 사례를 학습하는 데 Perplexity가 어떻게 도움이 되는지 설명합니다.

[05:28] Perplexity는 문제 디버깅과 해결책 연구에 유용하며, 비슷한 문제를 겪은 다른 사람들의 경험을 찾아주어 최적화된 솔루션 개발을 도와줍니다.

[05:53] 캐싱 문제 해결을 위한 모범 사례 검색 예시를 보여주며, 새로운 기능 개발을 위한 연구 과정을 시연합니다.

[06:13] Gemini API를 활용한 이미지 객체 인식 및 제거 기능 개발에 대한 구체적인 연구 요청을 통해 Perplexity의 활용 방법을 보여줍니다.

[06:29] 60초 내에 구체적인 기술적 권장사항을 받았으며, Gemini Flash API를 통한 이미지 분할, 대화형 UI, 인페인팅 모델 활용 등의 구체적인 구현 방안을 제시받았습니다.

[07:01] Perplexity는 단순 정보 검색을 넘어 맥락을 이해하고 여러 검색을 결합해 실제 구현 계획을 제공하는 저평가된 도구임을 강조합니다.

[07:25] AI는 빠른 코딩이 가능하지만 개발자의 기준과 방향성이 필요하며, Perplexity가 가능성과 최적화 사이의 격차를 메우는 역할을 한다고 설명합니다.

[07:49] 현대적인 바이브 코딩은 추측이 아닌 정보에 입각한 결정을 위해 올바른 맥락을 제공하는 것이며, 이것이 Perplexity의 핵심 가치라고 결론짓습니다.

• 브랜치·커밋·PR 관리를 AI로 자동화해 버전 관리 모범 사례를 실천합니다. • 버그 브랜치 생성→이슈 작성→수정→풀 리퀘스트→머지까지의 프로세스를 데모로 시연합니다. • 속도만 추구하면 결국 기술 부채가 누적된다는 경고와 함께 구조적 접근을 강조합니다.

[08:02] GitHub MCP 서버를 소개하며 레포지토리 관리, 이슈 관리, 브랜치 관리 등이 초보자들에게는 복잡할 수 있다고 설명합니다. 특히 개발 초심자들이 경험자들에게는 당연한 기본기들로 어려움을 겪는다고 언급합니다.

[08:27] 댓글에서 보이는 초보자들의 실수 사례를 유머러스하게 소개하면서, 하나의 브랜치에서만 작업하는 것의 위험성을 강조합니다. 올바른 버전 관리 시스템 습관의 중요성을 설명합니다.

[08:50] GitHub MCP의 주요 사용 사례로 레포지토리 관리를 들며, 커밋 검토, 이슈 생성, 풀 리퀘스트 자동화를 통한 머지 추적 등을 설명합니다. 바이브 코딩 프로젝트라도 개발 모범 사례를 익혀야 한다고 강조합니다.

[09:30] 실제 예시를 통해 새로운 버그 브랜치 생성부터 GitHub MCP를 활용한 이슈 생성, 버그 수정, 풀 리퀘스트 생성까지의 전체 워크플로우를 단계별로 설명합니다.

[09:51] GitHub 레포지토리에서 생성된 풀 리퀘스트를 확인하는 과정을 보여주며, 문제와 해결책의 요약, 테스트 실행, 파일 변경사항 검토, 메인 브랜치로의 머지 과정을 설명합니다.

[10:30] 구조 없는 속도는 숨겨진 기술 부채라고 경고하며, AI가 코딩을 민주화했지만 여전히 신중하고 의도적인 접근과 체계적인 시스템이 필요하다고 강조합니다. 최고의 AI 개발자들은 기본기를 건너뛰지 않는다고 마무리합니다.

[10:54] 개발자들이 기본기를 건너뛰는 것이 아니라 합리적인 부분을 자동화하고 있다고 설명하며 Supabase MCP를 소개합니다. 이는 Supabase를 사용하는 개발자들에게 매우 유용한 개발 도구라고 강조합니다.

• SQL 쿼리 없이 Supabase MCP를 통해 테이블·엔트리 상태를 확인합니다. • 프롬프트 저장소 앱에서 버전 히스토리가 로드되지 않을 때 원인 분석 과정을 자동화합니다. • 앱과 데이터베이스 간 정보 흐름의 불일치를 간편하게 탐지·해결합니다.

[11:07] 개발 중 코드 문제 발생 시 데이터베이스 테이블과 데이터를 확인해야 하는 번거로움을 설명합니다. MCP 없이는 수동으로 SQL 쿼리를 작성하거나 직접 데이터베이스에 접근해야 하는 골치 아픈 과정이 필요하다고 언급합니다.

[12:03] 채널에서 작업 중인 프롬프트 저장소 앱을 예시로 들며, 프롬프트 편집과 버전 히스토리 기능을 소개합니다. Design Maker 프롬프트의 버전 히스토리가 로딩되지 않는 문제 상황을 가정하여 실제 사용 사례를 제시합니다.

[12:55] Supabase MCP를 사용하여 버전 히스토리 로딩 문제를 해결하는 과정을 보여줍니다. 직접 SQL 쿼리를 작성할 필요 없이 AI가 자동으로 프로젝트를 찾고 조사해주는 편리함을 강조합니다.

[13:20] Supabase 도구가 프로젝트 구조를 이해하고 데이터베이스에서 필요한 정보를 찾아내는 과정을 설명합니다. 이 도구는 앱과 데이터베이스 간의 연결 문제를 해결하는 데 도움이 됩니다.

• LLM의 '환각' 문제를 방지하기 위해 항상 최신 공식 문서를 제공받습니다. • 라이브러리·프레임워크 ID 검색 후 관련 API·패턴·예제 코드를 실시간으로 가져옵니다. • 운영 토큰 절감형 대안(Ref)도 함께 소개하며 문서 기반 개발의 중요성을 설명합니다.

[14:03] Context 7 도구를 소개합니다. 언어 모델이 가끔 내용을 지어내고 오래된 문서를 사용하는 문제점을 지적하며, 항상 최신 문서가 필요함을 강조합니다.

[14:44] 멀티 에이전트 팀 구축 사례를 통해 Context 7의 사용법을 설명합니다. 퍼플렉시티 연구자, 주제별 전문가, 작가 등 다양한 에이전트가 협력하여 프롬프트를 개선하는 시스템을 구상합니다.

[15:28] Context 7이 작동하는 방식을 설명합니다. 라이브러리 이름을 검색하여 ID를 가져온 후, 관련 문서를 검색하여 필요한 정보를 제공합니다. 다만 많은 토큰을 반환하는 단점이 있어 ref 같은 대안도 제시합니다.

[16:07] Context 7이 Crew AI 문서에서 자동으로 정보를 추출하여 작업 설계 방법과 프로세스를 보여주는 예시를 설명합니다. 순차적 작업과 계층적 작업의 개념, 그리고 질문에 기반한 컨텍스트 제공 능력을 소개합니다.

[16:37] Context 7의 활용 사례를 구체적으로 설명하며, 구현 방법 연구와 기존 작업의 문서 활용(예: Supabase 쿼리 최적화)에 유용함을 강조합니다.

[16:55] AI의 양면성에 대해 설명합니다. 항상 자신감을 갖는 것이 장점이자 동시에 허위 정보를 만들어내는 약점이 될 수 있으며, 올바른 컨텍스트 제공의 중요성과 전문가의 지속적인 필요성을 강조합니다.

[17:32] Playwright MCP를 소개하며, 일반적인 브라우저 테스트 자동화 용도를 넘어서 '자체 평가 UI' 구현에 활용하는 방법을 설명합니다.

• 실제 브라우저 테스트를 통해 UI 스냅샷을 비교·검증해 설계 기준 충족 여부를 자동 평가합니다. • LLM이 생성한 코드를 목표 설계와 대조한 뒤, 피드백을 반영해 반복 개선하는 셀프 체크 루프를 구현합니다. • 이 과정을 통해 AI를 단순 실행기가 아닌 협업 파트너로 활용하는 방법을 제시합니다.

[18:03] 자체 평가 UI의 작동 원리를 설명합니다. 모델이 자신의 작업을 문서화된 기준에 맞춰 자동으로 평가하고 반복적으로 개선하는 시스템의 개념을 소개합니다.

[18:16] 실제 구현 과정을 단계별로 설명합니다. 웹 앱 구축 후 브라우저 테스트 단계에서 UX/UI 시스템을 기준으로 결과물을 평가하는 과정과, 실제 구현에서 발생할 수 있는 지름길이나 부정확한 구현 문제를 지적합니다.

[18:50] Playwright MCP를 활용한 해결책을 제시합니다. 브라우저 스냅샷을 촬영하고 설정된 UI 기준에 맞춰 자동으로 평가하는 시스템의 구체적인 작동 방식을 설명합니다.

[19:01] Playwright MCP를 통해 브라우저 스냅샷을 촬영하고, 설정된 UI 표준에 따라 평가한 후 LLM에게 피드백을 제공하여 자기 수정 루프를 만드는 시스템을 설명합니다.

[19:24] AI의 다음 진화는 언어 모델이 결과물을 생성한 후 객관적 기준에 따라 스스로 반성하고 개선하는 자기 수정 루프를 통해 품질 높은 파트너가 되는 것이라고 강조합니다.

[19:52] 바이브 코더들이 직면하는 문제는 '모르는 것을 모르는' 상황으로, 보안 전문가에게는 명백한 취약점을 자각 없이 만들 수 있다는 점을 지적합니다.

• Semgrep MCP로 프로젝트 종속성·인증 핸들러·미들웨어 구성을 자동 스캔합니다. • 발견된 보안 취약점 수준과 권장 수정 작업을 리포트 형식으로 제공받습니다. • Linear MCP와 연계해 보안 관련 작업을 백로그에 추가·우선순위화할 수 있습니다.

[20:25] SemGrep MCP는 코드 내 보안 검사를 자동화하여 프로젝트의 취약점을 파악하고 보고서를 제공합니다. 초기 스캔에서는 인증 핸들러, 서버 액션, 미들웨어 등을 검사합니다.

[21:06] 포괄적인 스캔 결과, 발견된 취약점들은 주로 의존성 업데이트와 관련되어 있으며, Clerk, Next.js, ESLint 업데이트를 권장합니다. 이러한 보안 작업은 Linear MCP를 통해 우선순위를 매겨 관리할 수 있습니다.

[21:50] 보안의 중요성을 강조하며, 빠른 개발보다는 확장 가능하고 안전한 개발이 우선되어야 한다고 설명합니다. 보안을 고려하지 않으면 마치 눈을 감고 액셀을 밟는 것과 같아서 결국 충돌하게 된다며, Semgrep 사용을 권장합니다.

• 과도한 설계·패턴 관성으로 인한 로직 복잡화를 방지하기 위해 중간 반성 지점을 삽입합니다. • 계획과 실행의 불일치를 실시간 감지하고 '이대로 진행해도 괜찮은지' 묻는 체인을 제공합니다. • 애매모호한 요청에서도 체크포인트를 강제해 올바른 방향성을 유지합니다.

[22:11] Vibe Check라는 MCP를 소개합니다. 이는 작은 개발자가 만든 도구로, 자율 AI 에이전트를 위한 플러그 앤 플레이 메타인지 감독 레이어입니다. LLM을 정렬되고 반성적이며 안전하게 유지하는 연구 기반의 MCP 서버라고 설명합니다.

[22:43] AI가 야심찬 프로젝트에서 과도한 엔지니어링을 하며 복잡하게 발전하는 문제를 설명합니다. 패턴 관성과 추론 잠금이라는 개념을 통해, 대형 언어 모델이 결함 있는 계획을 자신 있게 따를 수 있음을 지적합니다.

[23:19] Vibe Check MCP가 프로세스 중간에 반성적인 일시정지를 제공하여 특정 가정들을 당연하게 여기지 않고 올바른 방향으로 구축할 수 있도록 도와준다고 설명합니다. 체인 패턴 인터럽트라는 연구 기반 접근 방식을 사용하여 위험한 순간에 적절한 일시정지를 주입합니다.

[24:01] Vibe Check를 다양한 프로젝트와 통합할 수 있다고 설명하며, 첫 번째 도구인 Vibe Check 기능을 소개합니다. 시스템 설정의 메인 에이전트 정의에 넣어서 모델 사용 시마다 컨텍스트로 추가하며, 반복적인 실수를 포착하여 저장할 수 있다고 설명합니다.

[24:33] MCP 설치와 claw.markdown 파일 설정을 통해 vibe check 기능을 활성화하는 방법을 설명합니다. 이 기능은 계획 수립 후와 주요 작업 전에 호출되어 작업의 적절성을 검증합니다.

[24:57] vibe check가 실행되면 목표와 계획, 그리고 진행 상황을 분석하여 피드백을 제공하고, 필요시 구현을 개선하도록 제안합니다. 실제 예시에서는 접근성 기능 추가를 제안했습니다.

[25:34] 명확한 작업 대신 애매한 요청을 테스트합니다. "연구와 작성 기능을 갖춘 crew AI 서비스를 만들어달라"는 모호한 요청에 대해 vibe check가 어떻게 반응하는지 관찰합니다.

• 로컬에서 실행되는 에이전트를 통해 터미널·시뮬레이터·IDE 화면 활동을 기록합니다. • 과거 디버깅·설정 변경·솔루션 과정을 메모리 형태로 저장하고 검색·회상이 가능합니다. • 장기 프로젝트나 복잡한 버그 해결 시 수개월 전 작업 내용을 빠르게 떠올릴 수 있습니다.

[26:12] vibe check가 애매한 계획의 문제점을 지적하고 Claude와 대화를 통해 구체적인 구현 사항을 결정하도록 돕습니다. 특정 기능을 구현할지 말지에 대한 판단을 제공합니다.

[26:44] 바이브 코딩을 하는 개발자들에게 이러한 MCP가 제공하는 가치를 설명합니다. 자신의 한계를 밀어붙이면서도 올바른 방향을 유지할 수 있도록 체크포인트와 메타 레이어 반성 기능을 제공합니다.

[27:06] 화자는 코딩 도구의 메타 레이어 역할에 대해 설명하며, 단순히 명령을 따르는 도구가 아닌 사용자가 올바른 방향으로 가고 있는지 성찰하게 돕는 도구의 중요성을 강조합니다.

[27:52] 'Pieces'라는 마지막 도구를 소개하며, 이 도구가 사용자의 여러 앱 활동을 관찰하고 기억을 형성하여 나중에 검색하고 대화할 수 있게 해주는 기능을 설명합니다.

[29:00] Pieces가 마치 사용자 뒤에서 모든 작업을 지켜보며 기억하는 또 다른 자신과 같다고 비유하며, 모든 처리가 로컬에서 이루어진다는 장점과 라마 모델이 내장되어 있다는 특징을 소개합니다.

[30:00] 과거 GraphQL 프로젝트에서 겪었던 인증 오류 디버깅 경험을 언급하며, 그때의 해결책을 현재 프로젝트에 적용할 수 있다면 얼마나 좋을지에 대해 이야기합니다.

[30:13] Pieces의 모든 정보가 MCP로 노출될 수 있으며, Cursor, GitHub Copilot, Claude Desktop 등 다양한 도구들과 통합 가능하다는 점을 설명합니다.

• AI 코딩은 속도뿐 아니라 구조·품질 관리를 병행해야 지속 가능하게 성장할 수 있음을 강조합니다. • 실무에서 즉시 활용 가능한 9가지 MCP 서버를 정리했고, 직접 엔드투엔드 제작 예시를 제공했습니다. • MCP 서버 제작 튜토리얼 요청과 커뮤니티 참여를 독려하며 영상 시청을 마무리합니다.

[30:42] VS Code 사용자라면 GitHub Copilot과 쉽게 연동할 수 있다고 언급하며, AI 코딩이 거의 모든 것을 가속화하지만 실수로부터 배우는 것은 예외라고 지적합니다.

[31:02] 대부분의 개발자들이 같은 실수를 반복하는 이유를 설명하고, 과거의 해결책을 되돌아볼 수 있는 도구의 중요성을 강조합니다.

[31:18] 초보자와 전문가의 차이는 단순한 기술이 아니라 패턴을 인식하고 해결책을 재사용하는 능력에 있다고 설명합니다.

[00:00] 안녕하세요 여러분! 저처럼 새로 나오는 수많은

[00:02] MCP 서버들을 보면 약간 FOMO가 생기고

[00:04] 압도당하는 기분이 드시죠? 어떤 게

[00:06] 좋은지, 어떤 게 코딩에 특화되어 있는지

[00:09] 말이에요. 이제까지 저는 수십 개의

[00:12] 다양한 MCP 서버들을 사용해봤습니다.

[00:13] 좋은 것들도 있었고, 그저 그런 것들도

[00:15] 있었죠. 특정 상황에 정말 구체적으로

[00:17] 유용한 것들도 있었고, 너무 추상적이어서

[00:20] 어떤 가치도 얻지 못한 것들도 있었습니다.

[00:22] 그래서 생각했죠, "내가 모든 걸 다 써보고

[00:24] 정말로 매주 사용하는 것들만 골라서

[00:26] 인터넷에 공유하면 좋겠다"고요.

[00:28] 저를 모르실 수도 있는데, 제 이름은

[00:30] Sean이고, 여러 SaaS 회사에서 일했고

[00:33] 마케팅 회사를 구축하고 확장해서 연 매출

[00:35] 8자리 수까지 달성하는 데 도움을 주었습니다.

[00:37] 이런 모든 경험을 바탕으로 YouTube에

[00:39] 실제 현실에서 작동하는 실용적인 튜토리얼을

[00:42] 가져오려고 합니다. 그래서 오늘은 제가

[00:45] 매주 사용하는 톱 9 MCP 서버를 소개할 거예요.

[00:47] 각각을 살펴보고, 제가 실제로 어디에

[00:49] 사용하는지, 여러분의 전체 개발 워크플로우에

[00:53] 어떤 의미가 있는지 이야기할 거예요.

[00:55] 즉, 정말 사용을 고려해야 하는지 말이죠.

[00:56] 더 적은 것으로 더 많은 것을 하는 걸

[00:58] 좋아한다면, 이 영상은 여러분을 위한 것입니다.

[01:00] 그리고 스포일러인데, 이 MCP 중 하나는

[01:01] 작은 개발자가 만든 것이지만 정말 좋아해요.

[01:03] 그러니까 끝까지 시청해 주시거나

[01:05] 아래 타임스탬프를 보고 바로 건너뛰셔도 되지만

[01:06] 그러면 YouTube가 여러분 같은 사람들에게

[01:09] 제 콘텐츠를 보여주지 않을 수도 있고

[01:10] 그러면 저는 구독자 2만 명에서 평생

[01:13] 벗어날 수 없게 될지도 모르거든요.

[01:15] 자, 시작해 보겠습니다.

[01:17] 첫 번째는 Linear MCP입니다.

[01:20] Linear는 정말로 더 빠르고 더 체계적으로

[01:22] 개발할 수 있게 해주는 앱입니다.

[01:24] 발생하는 이슈를 추적할 수 있을 뿐만 아니라

[01:26] 더 큰 기능 빌드를 관리하고 개발 과정에서

[01:28] 발견한 것들을 백로그에 추가할 수 있어요.

[01:30] 저처럼 개발하다 보면 항상 뭔가가

[01:33] 떠오르는데, 그걸 메모장에 적는 건 정말

[01:35] 끔찍한 방법이거든요. 그래서 Linear 같은

[01:38] 도구를 MCP로 개발 워크플로우에 통합하는 건

[01:40] 정말 좋습니다. 예시를 보여드릴게요.

[01:42] 많은 사람들이 개발하다가 길을 잃곤 해요.

[01:45] 이 예시에서는 Claude에게 제 앱의 성능

[01:47] 병목 현상을 분석하고 다양한 최적화를

[01:49] 추천해달라고 요청하고 있습니다.

[01:52] 그리고 필연적으로 일어나는 일은

[01:53] 이 작업이 완료되면 - 버그일 수도 있고

[01:55] 생각한 기능일 수도 있고, 백로그에

[01:57] 추가해야 할 것일 수도 있고, 지금 당장

[01:59] 고치고 싶지 않은 중요한 블로커일 수도

[02:01] 있어요. 그래서 진행 중인 작업을

[02:03] 동기화해야 합니다.

[02:05] 앱의 백로그와 함께요.

[02:08] 확인하고 우선순위를 정하고

[02:10] 작업할 수 있는 백로그 말이죠.

[02:12] 그래서 이게 정말 중요한 거예요.

[02:13] 제가 실제로 사용하는 곳이기도 하고요.

[02:15] 성능 분석을 하거나 최적화를

[02:17] 추천받을 때, 그 결과를 바로

[02:19] Linear 이슈로 생성할 수 있어요.

[02:21] 이렇게 하면 실제로 작업해야 할

[02:23] 항목들을 놓치지 않고 체계적으로

[02:24] 관리할 수 있습니다. 정말 큰 도움이

[02:26] 되는 워크플로우죠.

[02:27] 특히 팀으로 작업할 때는 더욱

[02:28] 유용합니다. 모든 이슈와 작업이

[02:30] 한 곳에서 관리되니까요.

[02:33] 그래서 Linear MCP를 정말

[02:35] 추천합니다.

[02:37] 현재 앱에서 일어나고 있는 작업을

[02:40] 체크하고 우선순위를 정하고 작업할 수 있는

[02:42] 백로그와 동기화해야 합니다. 이것은 정말

[02:44] 중요한데, 백로그는

[02:46] 우선순위가 정해져야 하기 때문입니다. 무엇을

[02:48] 수정하는 것이 중요한지, 무엇을

[02:49] 개발하는 것이 중요한지 알아야 합니다. 만약

[02:51] 개발 모드인지 수정 모드인지

[02:53] 아니면 다른 모드인지 어떻게 결정하겠습니까? Linear가 훌륭한 이유는

[02:56] 개발 과정에서 이런 문제들이 발생했을 때

[02:57] 그런 결정을 내려야 할 때

[02:59] 이것들을 백로그에 추가할 수 있기 때문입니다.

[03:02] 그럼 어떤 모습인지 살펴보겠습니다.

[03:04] 이미 몇 가지 문제를 발견했네요. 제가

[03:06] 데이터베이스를 쿼리하는 방식의 문제,

[03:07] 프론트엔드에서 정보를

[03:10] 캐싱하는 방식의 문제와

[03:12] 여러 다른 문제들 말입니다. 이제

[03:15] Linear MCP를 사용해서

[03:18] 실제로 이 백로그의 우선순위를 정할 수 있습니다.

[03:21] 어떤 모습인지

[03:22] 살펴보겠습니다. Linear MCP를 사용해서

[03:24] 이것들을 영향도 순서로 우선순위를 정하고

[03:26] 구현 노트를 제공하라고 말할 수 있습니다.

[03:28] 이제 이 프로세스가

[03:32] 완료에 가까워지는 것을 볼 수 있습니다.

[03:33] 처리 과정을 거쳐서

[03:35] 기본적으로 제가 해결할 수 있는 티켓들을 만들어줬습니다.

[03:38] 10월 3일부터 이 모든 것들을

[03:40] 볼 수 있습니다. 다양한 버그들과

[03:42] 개선을 위한 다양한

[03:43] 공간들도 있습니다. 예를 들어

[03:45] 캐시 무효화 전략을

[03:48] 보고 싶다면, 들어가서

[03:50] 살펴볼 수 있고, 어떤

[03:52] 영향을 미치고 있는지 볼 수 있습니다.

[03:54] 특정 코드 스니펫이 포함된 구현에 대한 노트와

[03:57] 이를 구현하기 위해 사용할 수 있는

[03:59] 다양한 솔루션들이 있습니다.

[04:01] 이것이 왜 중요한지 설명하겠습니다.

[04:04] 나중에, 예를 들어 지금으로부터 2일 후에

[04:06] 들어가서 이

[04:08] 특정 문제를 보고 싶을 때 말입니다. 예를 들어

[04:10] 이것은 81번입니다. 우리

[04:13] 프로젝트로 돌아가서

[04:15] 방금 일어난 대화에 대한 맥락이 없다면

[04:17] Linear MCP에서 이

[04:21] 문제를 가져와서 요약하라고 할 수 있습니다. 그러면

[04:23] 구현 계획을 세우라고 할 수도 있고

[04:25] 기타 등등 말입니다. 그러면

[04:27] Linear에서 그 문제를 가져와서

[04:28] 가져온 다음 거기서부터

[04:32] 작업할 수 있습니다. 됐네요.

[04:33] 문제에 대한 정확한 정의를

[04:35] 본질적으로 갖게 됐습니다. 이것이 훌륭한 이유는

[04:37] AI 코딩이 매우 빠르게 진행되지만

[04:39] 적절한 시스템이 없다면

[04:42] 그 속도가 프로세스에 혼란을 만들고

[04:44] 그러면 수정해야 할 중요한 것들과

[04:48] 나중에 개발해야 할 중요한 것들을

[04:49] 놓치게 되기 때문입니다.

[04:51] AI와 함께 지속 가능하게 개발하려면

[04:53] 이런 것들을 포착하고

[04:56] 표면화할 수 있어야 합니다. 그래야

[04:58] 계속해서 앞으로 나아가며

[05:00] 작업해야 할

[05:02] 중요한 것들을 작업할 수 있습니다.

[05:03] 다음으로 살펴볼 MCP는

[05:05] Perplexity의 MCP입니다.

[05:08] 이것이 매우 가치 있는 이유는

[05:10] 여러 가지가 있습니다.

[05:12] 새로운 기능을 연구할 때 도움이 되는데

[05:14] 특히 당신이 전문가가 아닌

[05:17] 분야에서 말입니다. 예를 들어

[05:19] 나가서 에이전트를 구축하기 시작하고 싶다고 하면

[05:20] 에이전트를 만들고 싶은데, 아시다시피

[05:22] 에이전트 개발에 그렇게 뛰어나지 않고

[05:24] 패턴이 뭔지, 모범 사례가 뭔지

[05:26] 알고 싶다면

[05:28] Perplexity가 바로

[05:29] 그런 도움을 줄 거예요. 또한

[05:31] 특정 문제를 디버깅하거나

[05:33] 해결책을 이해하려 할 때

[05:35] 정말 유용합니다.

[05:36] Perplexity는 나가서

[05:38] 이전에 비슷한 문제를 겪었던

[05:40] 다른 사람들을 찾아줄 수 있어요.

[05:42] 우리가 만들고 있는 것들과

[05:45] 모범 사례에 대한 인식 없이는

[05:46] 절대로 진정으로

[05:48] 최적화된 것을 만들 수 없죠.

[05:50] 그래서 Perplexity가 연구 단계에서 우리를 도와줍니다.

[05:53] 이걸 사용하는 한 가지 방법은

[05:55] 바로 여기서 우리가

[05:56] 방금 중단한 부분입니다. 우리는

[05:59] 캐싱 문제를 해결하기 위한

[06:01] 제안된 솔루션들이 있죠. 우리는

[06:03] Perplexity에게 나가서

[06:05] 그런 일을 하는 모범 사례를 찾아달라고 할 수 있어요.

[06:07] 하지만 우리가 새로운 기능을 위한

[06:10] 연구를 하고 싶다고 해봅시다.

[06:12] 여기 예시가 있어요. 저는

[06:13] Gemini API를 활용해서

[06:15] 사용자가 업로드한 이미지 안에 정확히 무엇이 있는지 이해하는

[06:18] 새로운 기능을 만들고 싶어요.

[06:21] 예를 들어, 이미지 속 객체들을

[06:22] 사용자가 탭해서

[06:24] 이미지에서 지울 수 있게 하는 거죠.

[06:26] Perplexity MCP를 사용해서

[06:27] 최고의 접근법을 결정해 보세요.

[06:29] 몇 초 안에, 현실적으로는

[06:30] 60초도 안 걸렸던 것 같은데

[06:33] 이제 정확히 어떻게 해야 하는지에 대한

[06:35] 구체적인 권장사항이 나왔어요.

[06:38] 우리는 이미지 분할을 위해 Gemini Flash API를 사용할 수 있고

[06:42] 실제로 한 번의 API 호출로 여러 객체를

[06:44] 식별할 수 있다고 해요. 꽤 멋지죠.

[06:46] 그리고 기본적으로

[06:47] 대화형 UI 플로우에서 그 박스들을 표시하라고 하네요

[06:51] 사용자가 클릭할 수 있게 하고

[06:53] 그다음 인페인팅 모델을 사용해서

[06:55] 실제로 그 기능을 제공하라고 해요

[06:57] 이미지에서 것들을 제거할 수 있는

[06:59] 능력을 말이에요. 그래서 Perplexity는

[07:01] 정말 저평가되고 있어요. 단순히

[07:03] 정보를 찾아주는 것만이 아니라

[07:05] 당신이 정말 원하는 것의 맥락을

[07:06] 이해하고 여러 검색을 결합해서

[07:08] 실제 계획을 제공해 줘요.

[07:10] 그래서 저는 이 프로세스를 사용하는 걸 좋아해요

[07:13] 최고의 패턴이나 워크플로우나

[07:15] API나 기술이나 프레임워크에 대한

[07:18] 구현 계획을 이해하려 할 때 말이에요

[07:21] 제가 잘 모르는 것들에 대해서요.

[07:23] 그래서 잠깐 확대해서 보면

[07:25] AI는 여러분이 생각하는 것보다 빠르게 코딩할 수 있지만

[07:28] 여러분이 무엇을 좋다고 생각하는지

[07:31] 그리고 여러분이 만들고 있는 것으로

[07:33] 어떤 방향으로 가고 싶은지 알아야 해요.

[07:35] 그래서 가능한 것과 최적인 것 사이의

[07:38] 그 격차를, Perplexity 같은 도구가

[07:40] 그 격차를 메우고 우리가

[07:43] 실현 가능하게 할 수 있는 것을 이해하고

[07:46] 그것을 개발 프로세스에 통합하는 데 도움을 줍니다.

[07:49] 현대의 바이브 코딩은 추측하거나

[07:51] 언어 모델에게 결정권을 넘겨주는 것이 아니에요.

[07:54] 올바른 맥락을 제공해서

[07:56] 정보에 입각한 결정을 내릴 수 있게 하는 거죠.

[08:00] 그리고 그것이 바로 Perplexity가 우리에게 도움을 주는 것입니다.

[08:02] 다음 MCP 서버는 GitHub의 MCP입니다.

[08:06] 올바른 레포지토리 관리, 이슈 관리,

[08:08] 브랜치 관리 등 이런 모든 작업들이

[08:11] 사실 꽤 복잡할 수 있습니다.

[08:13] 특히 초보자 입장에서는 말이죠.

[08:15] 개발을 처음 시작하는 AI 코더들은

[08:18] 이런 기본기들로 어려움을 겪을 수 있습니다.

[08:21] 10년 경력자에게는 당연한 것들이

[08:23] 초보자에게는 어려울 수 있거든요.

[08:24] 믿어주세요. 댓글에서 항상 봅니다.

[08:27] 이 사람은 flux capacitor를 사용해서

[08:30] widgety woo에 연결했다면서

[08:32] git 트리를 실시간으로 탐색하려고 했다고 하네요.

[08:34] 완전 초보네요. 하지만

[08:37] 여기서 근본적인 문제는

[08:38] 하나의 브랜치에서만 작업하는 것이

[08:40] 정말 큰 문제를 만들어낸다는 겁니다.

[08:44] 올바른 버전 관리 시스템 습관을

[08:45] 들이지 않으면

[08:47] 결국 망하게 될 겁니다.

[08:50] GitHub MCP의 사용 사례 중에서

[08:54] 제가 가장 많이 활용하는 건

[08:57] 일반적인 레포지토리 관리입니다.

[08:59] 프로젝트 전체에서 만들어진 커밋들을 살펴보고

[09:01] 특정한 것들을 이해하려고 노력하며

[09:03] 이슈를 생성하고 풀 리퀘스트 생성을 자동화해서

[09:06] 메인 프로젝트로 만들려고 하는

[09:08] 머지들을 추적할 수 있도록 하는 거죠.

[09:10] 그런 모든 작업들 말입니다.

[09:12] 다시 말하지만, 단순히 바이브 코딩을 하는 프로젝트라고 하더라도

[09:14] 이런 습관을 들이고 싶을 겁니다.

[09:18] '아, 언젠가 이게 정말

[09:19] 뭔가 대단한 게 될 것이고

[09:21] 지금부터 개발 모범 사례를 익혀두는 게 좋겠다.

[09:24] 평생 하나의 브랜치에서만

[09:27] 무작정 작업하지 말고.' 이런 생각을요.

[09:28] 자, 예시를 보겠습니다.

[09:30] goal 78 이슈를 해결하기 위해

[09:32] 새로운 버그 브랜치를 만들 겁니다.

[09:35] 그 다음 GitHub MCP를 사용해서

[09:37] 이슈를 생성해 주세요.

[09:40] 그걸 완료하면 버그를 수정하세요.

[09:42] 그걸 완료하면 GitHub MCP를 사용해서

[09:45] 이슈를 수정하는 풀 리퀘스트를 생성하고

[09:47] 변경사항에 대한 피드백을 남기고

[09:49] 이슈를 완료 처리하세요.

[09:51] 이제 GitHub로 다시 돌아가서

[09:53] 우리 레포지토리로 가보면

[09:55] 열려있는 풀 리퀘스트가 보입니다.

[09:57] 여기 들어가서 살펴보면

[09:59] 실제 문제가 무엇이었는지

[10:01] 그리고 해결책이 무엇이었는지 요약을 볼 수 있습니다.

[10:05] 지금 별도의 린팅 이슈가 있어서

[10:08] Vercel의 제 프로젝트에 배포가 안 되고 있습니다.

[10:10] 하지만 여기서 진행할 수 있습니다.

[10:12] 테스트를 실행할 수 있고

[10:15] 실제 파일 변경사항들을 검토할 수도 있습니다.

[10:19] 모든 게 좋다면

[10:21] 이걸 메인 브랜치에 실제로 머지할 수 있습니다.

[10:24] 이제 메인 브랜치로 다시 돌아가면

[10:26] 짜잔, 방금 이 풀 리퀘스트를

[10:28] 푸시한 걸 볼 수 있습니다.

[10:30] 구조 없는 속도는

[10:33] 그냥 기다리고 있는 기술 부채입니다.

[10:35] 가장한 채로 있을 뿐이에요.

[10:37] 아직 모습을 드러내지 않았지만

[10:39] 거기 있습니다. 그래서

[10:42] AI가 코딩 프로세스를 민주화하고 있지만

[10:43] 여전히 중요한 것은

[10:46] 여러분이 하고 있는 일에 대해

[10:47] 신중하고 의도적이어야 한다는 것이고

[10:50] 하고 있는 일 뒤에 시스템이 있어야 한다는 겁니다.

[10:52] 최고의 AI 개발자들은 기본기를 건너뛰지 않습니다.

[10:54] 이치에 맞는 부분들을 자동화하는 거죠. 자, 다음으로

[10:56] 살펴볼 MCP는 바로

[10:58] Supabase MCP입니다. 이걸 다루는 이유는

[11:00] 정말 유용한 개발 도구이기 때문이에요.

[11:03] 여러분 중 많은 분들이

[11:05] Supabase를 사용하고 계시잖아요.

[11:07] 이게 왜 유용하냐면

[11:08] 개발할 때, 특히

[11:10] 코드에서 문제가 발생했을 때

[11:12] 여러분들은 결국

[11:14] 다양한 테이블들과

[11:16] 그 안의 데이터들을 확인해서

[11:18] 왜 어떤 것이

[11:20] 예상한 대로 동작하지 않는지

[11:21] 파악해야 하거든요.

[11:23] 실제로 데이터베이스의 상태를 참조해서

[11:25] 뭐가 깨졌고 뭐가 정상인지

[11:27] 확인할 수 있어야 해요. 만약

[11:29] 이 MCP 서버를 사용하지 않는다면

[11:31] 수동으로 SQL 쿼리를 만들어서

[11:33] 코딩 환경에서

[11:35] 직접 실행하거나, 아니면

[11:37] 지금 보시는 것처럼

[11:39] 데이터베이스 테이블을 직접 들어가서

[11:42] 어떤 컬럼들이 있는지

[11:44] 있어야 할 컬럼들은 뭔지

[11:45] 없어야 할 것들은 어떤 건지

[11:47] 이런 걸 다 파악하면서

[11:48] 뭐가 문제인지

[11:49] 정확히 알아내려고 노력해야 해요.

[11:52] 어떤 컬럼을 실제로 가져와서

[11:54] 시스템에 다시 보내서

[11:56] 예시 데이터를 제공할지 알아야 하거든요. 정말 짜증나는

[11:59] 골치 아픈 일이죠. 그런데 MCP를 사용하면

[12:01] 왜 그런 번거로움을 겪어야 할까요?

[12:03] 이번에는 우리가 작업 중인

[12:05] 앱을 살펴보겠습니다.

[12:06] 채널의 여러 영상에서

[12:08] 작업해온 건데요. 일반화된 프롬프트

[12:11] 저장소 같은 앱이에요. 지금은

[12:13] 자세히 설명하지 않을 텐데

[12:14] 기본적으로는

[12:16] 프롬프트를 저장하고

[12:17] 그 프롬프트를 편집해서

[12:20] 실시간 버전 히스토리를

[12:22] 유지하는 기능이 있어요. 자, 이제

[12:25] 이 특정 프롬프트에

[12:27] 여러 번 수정을 가했는데

[12:29] 버전들이 전혀 보이지 않는다고 가정해봅시다.

[12:31] 그러면 '음, 분명히 변경했는데

[12:33] 있어야 하는데 왜 안 보이지?'

[12:35] 뭔가 잘못됐나 확인해보자

[12:36] 테이블이 제대로

[12:38] 생성되지 않았을 수도 있고

[12:40] 데이터가 제대로

[12:41] 들어가지 않았을 수도 있고

[12:44] ID 키들이 매칭되지 않아서

[12:46] 이 특정 프롬프트에 대한

[12:49] 특정 버전들을

[12:50] 가져올 줄 모를 수도 있어요.

[12:52] 여러 가지 가능성이 있겠죠. 그래서

[12:55] 'Design Maker라는

[12:56] 프롬프트의 버전 히스토리가

[12:58] 로딩되지 않고 있어요. Supabase MCP를

[12:59] 사용해서 왜 그런지 알아보세요'라고 말할 수 있어요.

[13:02] 그러면 프로젝트 내에서

[13:04] Supabase MCP를 사용해서

[13:06] 모든 것을 조사하는 과정을 볼 수 있어요.

[13:09] 우리가 직접

[13:10] SQL 쿼리를 만들어서

[13:12] 이런 것들을 찾을 필요 없이

[13:14] AI가 나가서 찾아줄 거예요.

[13:15] 먼저 우리가 말하는 실제 프로젝트를 찾고

[13:18] 그다음에 가서

[13:20] 우리가 얘기했던 프롬프트의 제목을 찾아낸 거죠, 그렇죠?

[13:22] 그래서 이 도구는

[13:23] 우리 프로젝트와 우리가 정확히 무엇을 말하고 있는지 이해합니다

[13:25] 그리고 어디서 찾아야 할지 알고 있어요

[13:28] 그것을 찾아낼 수 있습니다. 그래서 이 경우의 결과는

[13:30] 명백히 실제로 찾아냈다는 것입니다

[13:31] 왜냐하면 그것들이 존재한다는 것을 알고 있거든요

[13:32] 따라서 명백히 이 경우에는

[13:34] 단순한 사용자 오류였습니다. 하지만 이것은

[13:36] 정말 도움이 될 수 있습니다

[13:38] 문제에 부딪혔을 때 시작할 수 있어요

[13:41] 앱과 데이터베이스 사이에 연결이 끊어진 것이 명확한 곳에서

[13:43] 그리고 두 시스템 간에 정보가 어떻게 움직이는지 말이죠

[13:46] 따라서 바이브 코딩은

[13:48] 정말 잘 작동합니다

[13:50] 여러분의 기대치를 쉽게 맞출 수 있을 때

[13:53] 실제로 일어나고 있는 현실과 일치시키고

[13:55] 확실히 하는 것

[13:57] 이 두 세계 사이에 연결 끊김이 없도록 하는 것

[13:58] 이런 도구가 우리가 꽤 쉽게 할 수 있도록 도와줍니다

[14:01] 다음 목록에 있는 것은

[14:03] Context 7이라고 불리는 도구입니다. 그래서 근본적인 문제는

[14:06] 많은 언어 모델들이

[14:08] 여전히 때때로 내용을 지어낸다는 것입니다

[14:10] 그래서 새로운 것을 구축할 때

[14:12] AI는 종종 오래된 문서를 사용합니다

[14:16] 이것을 볼 수 있습니다

[14:17] 존재하지 않는 엔드포인트를 환각으로 만들어내는 곳에서 말이죠

[14:20] 그들은 존재하지 않는 함수를 만들어내는 것을 좋아하고

[14:23] 결국 많은 아키텍처를 구축하게 됩니다

[14:24] 실제로는 그렇게 작동하지 않는 것을 중심으로 말이죠

[14:26] 그래서

[14:28] 우리가 해결해야 할 것은 항상 최신 문서를 갖는 것입니다

[14:30] 당신이 사용하고 있는 프레임워크나 라이브러리가 무엇이든

[14:33] 그리고 제가 그것을 하기 위해 좋아하는 도구는

[14:36] Context 7이라고 불립니다

[14:37] 여기 매우 직접적인 선형적인 방법이 있습니다

[14:41] 이런 것을 사용하는 종류의 방법 말이죠

[14:44] 제가 멀티 에이전트 팀을 구축하고 싶습니다

[14:46] 사용자를 위해 프롬프트를 개선할 수 있는

[14:49] 다시 말해 이것은 우리가 구축하고 있는

[14:51] 이런 종류의 앱의 일부입니다

[14:53] 이것을 한다고 가정해 봅시다

[14:55] 또는 제가 원하는 방식으로 일어나는 방법은

[14:57] 루트 오케스트레이터를 사용하는 것입니다

[15:00] 다양한 도구와 페르소나에 접근할 수 있는

[15:01] 퍼플렉시티로 구동되는 연구자 같은

[15:03] 주제별 전문가 예를 들어 코딩 도메인을 위한 것이라면

[15:07] 음, 실제로 할 수 있는 작가

[15:09] 프롬프트를 다시 쓸 수 있는 작가. 따라서

[15:11] 모든 이 다른 에이전트들에 접근할 수 있지만

[15:13] 저는 정말로 최선의 관행을 이해해야 합니다

[15:15] 그리고 crew AI의 관례를

[15:17] 이것을 하기 위해서 말이죠

[15:19] 그리고 저는 Context 7을 사용하고 싶습니다

[15:22] 그 문서를 가져와서 저를 도와주기 위해

[15:24] 그 이해를 구축하는 데 도움을 주기 위해

[15:26] 그래서 그것이 하는 것은 먼저 나가서

[15:28] 이름을 검색하고 그 이름에 대한 라이브러리 ID를 가져오는 것입니다

[15:30] 그리고 나서 그것은 통과할 것이고

[15:34] 시작할 것입니다

[15:35] 그 라이브러리를 통해 검색하여

[15:37] 관련 문서를 가져올 것입니다

[15:39] 정말로 제가 찾고 있는 답을 얻습니다

[15:42] 이제 Context 7의 유일한 잠재적 단점은

[15:45] 많은 토큰을 반환한다는 것입니다

[15:48] 하지만 이것을 줄이는 데 도움이 될 유료 옵션들이 있습니다

[15:51] 예를 들어 ref 같은 것

[15:53] Context 7의 대안이 되는 것

[15:55] 전체 문서 목록을 반환하지 않는 것

[15:57] 지능적으로 결정하는 종류의 것

[16:00] 당신에게 무엇을 전달할지

[16:02] 그래서 role, goal, backstory 이런 패턴이 crew AI가 작동하는 방식입니다

[16:05] 이것이 crew AI가 작동하는 방식입니다

[16:07] 문서에서 이 내용을 추출해낼 수 있었고

[16:08] 예시를 제공하기 시작했습니다

[16:10] 실제로 작업을 설계하는 방법을 보여주고 있어요

[16:13] 실제로 사용하는 프로세스 유형을

[16:15] 보여주고 있습니다

[16:17] Crew 같은 도구로 에이전트를 구축할 때

[16:19] 순차적으로 진행되는 작업의 개념이 있습니다

[16:22] 하나씩 차례로 진행되거나

[16:24] 또는 계층적 작업으로

[16:27] 루트 오케스트레이터가 전문가들에게 지능적으로 위임할 수 있죠

[16:30] 정말 많은 좋은 컨텍스트를

[16:32] 우리가 한 질문에 기반해서

[16:34] 가져오고 있습니다

[16:37] Context 7은 이것을 가장 잘 구현하는 방법에 대한

[16:39] 연구에 정말 좋습니다

[16:42] 또한 이미 알고 있는 작업에 대한

[16:44] 문서를 가져오는 데도 좋고요

[16:46] 예를 들어 Supabase 쿼리를 최적화하고 싶다면

[16:48] Supabase 문서를 가져와서

[16:50] 내가 하고 있는 작업을 개선하는 데

[16:52] 사용할 수 있습니다

[16:55] AI의 가장 큰 장점은 항상 자신이 하는 일에

[16:58] 확신을 갖는다는 것인데

[16:59] 동시에 이것이 가장 큰 약점 중 하나이기도 합니다

[17:01] 허위 응답을 만들어내고

[17:03] 그것이 사실이라고 확신시키죠

[17:06] 코딩이나 비즈니스, 인생의 모든 영역에서

[17:08] AI를 제대로 사용하는 미래는

[17:10] 시스템에 필요한 최고의 컨텍스트를

[17:13] 정확히 어떻게 제공할지 아는 것입니다

[17:15] 그래야 여전히 매우 빠르게 움직이면서도

[17:18] 당신이 제공한 특정 컨텍스트 범위 안에서

[17:21] 작업할 수 있거든요

[17:23] 그리고 이것이 전문가들이 절대 사라지지 않을 이유입니다

[17:25] 그들이 기초 지식을 제공하고

[17:28] 새로운 영역의 경계를 확장하기 때문이죠

[17:30] 다음으로 제가 정기적으로 사용하는 MCP는

[17:32] Playwright MCP입니다

[17:35] Playwright는 일반적으로

[17:38] 엔드투엔드 브라우저 테스트 자동화에 사용됩니다

[17:41] 실제로 브라우저와 상호작용하고

[17:43] 거기서 일어나는 일들을 테스트할 수 있죠

[17:46] 제가 Playwright를 사용하는 용도는

[17:48] 소위 '자체 평가 UI'를 만드는 것입니다

[17:50] 모델이 스스로를 자동으로 수정하도록 하는 거죠

[17:54] 모델이 자동으로 자신의 작업을

[17:58] 우리가 문서화한 기준에 맞춰

[18:00] 평가할 수 있다는 뜻입니다

[18:03] 그래서 모델이 스스로를 검사하는

[18:05] 시스템을 통해 반복적인 개선을 만들어냅니다

[18:09] 이 과정이 일반적으로 어떻게 작동하는지 보여드리겠습니다

[18:12] 먼저 무언가를 구축합니다

[18:13] 이 경우에는 웹 앱이라고 하고

[18:16] 우리는 브라우저 안에 있습니다

[18:18] 일반적으로 브라우저에서 테스트하는

[18:20] 이 단계에 도달하기 전에

[18:22] 웹 앱을 만들고

[18:23] 브라우저에서 테스트하고 그런 모든 것들을 하기 전에

[18:26] 이상적으로는 어떤 종류의

[18:28] UX/UI 시스템을 구축했을 것입니다

[18:30] 이것이 구축해야 할 목표로 말이죠

[18:31] 그래서 문제는 완료되었을 때

[18:34] 실제로 우리가 원하는 방식으로

[18:36] 우리가 원하는 것을 구축했는지입니다

[18:38] 자주 일어나는 일은

[18:40] 지름길을 택한다는 것이고

[18:42] 훌륭한 디자인 시스템이 있어도

[18:46] 실제로는 제대로 구현하지 않는다는 것입니다

[18:48] 그래서 이 시스템이 하는 일은

[18:50] Playwright를 MCP로 사용해서

[18:51] 브라우저 스냅샷을 찍고

[18:54] 우리가 UI를 만들고 싶은 방식에 대해

[18:57] 설정한 기준에 맞춰 평가하는 것을 가능하게 합니다

[19:01] 우리가 설정한 기준에 따라 그 스냅샷들을 평가합니다.

[19:04] 우리가 원하는 UI 제작 방식의 표준말이죠.

[19:07] 그런 다음 그 피드백을 LLM에게 보내서

[19:10] LLM이 자신이 범한 실수를 수정할 수 있게 합니다.

[19:13] 그리고 이 과정이 계속 반복되도록 할 수 있죠.

[19:16] 앞뒤로, 앞뒤로, 앞뒤로

[19:18] 계속해서 말이에요.

[19:20] 우리가 만족할 수 있는 UI가 나올 때까지요.

[19:24] 제가 이걸 좋아하는 이유는

[19:25] AI의 다음 큰 진화 중 하나가

[19:28] 코딩뿐만 아니라 전반적으로

[19:31] 언어 모델을 사용해서 결과물을 생성하되

[19:33] 우리가 원하는 객관적 기준을 바탕으로

[19:35] 스스로 반성하고 시간이 지나면서 개선하도록 강제하는 것이기 때문입니다.

[19:38] 자신이 한 일을 돌아보고 개선하게 하는 거죠.

[19:40] 이런 자기 수정 루프는

[19:43] AI를 실제로 도움이 되는 파트너로 만들어줍니다.

[19:45] 반복을 통해 여러분이 찾고 있는

[19:47] 품질을 구축할 수 있게 도와주는 파트너로요.

[19:49] 다음 MCP는 SemGrep이라고 불립니다.

[19:52] 문제는 우리가 모르는 것을 모른다는 것입니다.

[19:54] 이것이 바이브 코더들이 직면하는

[19:56] 가장 큰 문제 중 하나입니다.

[19:58] 정말 잘 아는 사람에게는

[20:00] 매우 명백한 보안 취약점을

[20:03] 만들 수 있습니다.

[20:05] 정말 잘 아는 사람에게는

[20:06] 그런 걸 실제로 깨닫지도 못하고 할 수 있어요.

[20:08] 그래서 일이 제대로 되지 않을 때

[20:10] 해야 할 방식으로 되지 않을 때

[20:12] 근본적으로 망가졌거나

[20:14] 안전하지 않은 것을 배포하는 건

[20:16] 정말 원하지 않습니다.

[20:19] 특히 보안과 관련해서는요.

[20:21] 사람들의 개인 데이터와 정보 말이에요.

[20:23] 그래서 제가 SemGrep을 좋아하는 이유 중 하나는

[20:25] 코드 안에서 보안 검사를

[20:27] 자동화할 수 있게 해주기 때문입니다.

[20:31] 다시 이 프롬프트 월렛 애플리케이션 안에서

[20:33] 간단하게 말할 수 있습니다.

[20:35] SemGrep을 실행해서 내 프로젝트를 이해하고

[20:36] 취약점들을 파악해줘

[20:38] 얼마나 심각한지

[20:40] 있다면 어떤 것들인지, 그리고

[20:42] 기본적으로 보고서를 돌려줘.

[20:45] 기본적으로 처음에는 최소한의 스캔을 합니다.

[20:47] 내 프로젝트를 확인한 결과

[20:50] 인증 핸들러들은 괜찮았고

[20:52] 서버 액션들도 괜찮고, 미들웨어와

[20:54] 미들웨어 설정도 좋았고

[20:56] 환경 변수를 다루는 방식도

[20:58] 좋았습니다. 그래서 그들 데이터베이스에 있는

[21:01] 규칙 세트를 기반으로

[21:03] 이 8개 파일들을 검사한 결과 문제없었습니다.

[21:06] 이제 제가 요청한 건 전체 코드베이스에 대한

[21:09] 더 포괄적인 스캔을 실행하는 것입니다.

[21:12] 그래서 지금 그 작업을 하고 있는 중입니다.

[21:14] 기본적으로 찾아낸 모든 취약점들은

[21:17] 코드 자체에서 나온 게 아니에요.

[21:19] 더 많은 건 우리가 가진 의존성들과

[21:21] 관련된 것이고

[21:22] 그것들이 실제로 필요한 곳과

[21:24] 최신 상태인지 확인하는 것입니다.

[21:25] 그래서 권장 조치사항을 제공해줍니다.

[21:28] 인증에 사용되는 Clerk 업데이트,

[21:30] 매우 중요한 일이죠.

[21:32] Next.js 업데이트 그리고

[21:34] ESLint 업데이트입니다. 물론

[21:36] 앞서 이야기한 Linear MCP 같은 걸 사용한다면

[21:39] 이걸 팀이나 본인을 위한

[21:41] 작업으로 만들고

[21:43] 여러분에게 얼마나 중요한지에 따라

[21:45] 우선순위를 매길 수 있습니다.

[21:48] 이건 중요해야 하는데 보안이기 때문입니다.

[21:50] 보안이기 때문에 중요해야 합니다.

[21:52] 빠르게 움직이는 것은 실제로

[21:54] 당신이 만들고 있는 것이

[21:56] 확장 가능하고 안전할 때만 가치가 있습니다.

[21:59] 그렇게 하지 않는다면, 마치

[22:00] 차에 타서 눈을 감고

[22:02] 액셀러레이터를 밟는 것과 같습니다.

[22:04] 꽤 빠르게 갈 수 있지만,

[22:06] 결국 충돌하고

[22:07] 뭔가를 망가뜨리게 될 것입니다.

[22:08] 보안 허점을 원하지 않는다면, Semgrep 사용을 고려해보세요.

[22:11] 다음 MCP는 Vibe Check라고 불립니다.

[22:13] 이것은 제가 언급했던

[22:15] 작은 개발자가 만든 것입니다.

[22:17] 제가 의미하는 바는

[22:18] 수천 개의 스타와 수백 개의

[22:21] 포크를 가진 레포지토리가 아니라는 뜻이지만,

[22:23] 여전히 당신의

[22:26] 바이브 코딩 과정에서 가치가 있을 수 있습니다.

[22:28] 제가 언급했듯이, 이 도구는

[22:29] Vibe Check라고 불리며,

[22:32] 플러그 앤 플레이 메타인지 감독

[22:34] 레이어라고 스스로를 설명합니다.

[22:37] 자율 AI 에이전트를 위한 연구 기반

[22:40] MCP 서버로, LLM을

[22:42] 정렬되고, 반성적이며, 안전하게 유지합니다.

[22:43] 그게 무슨 뜻일까요? 문제를 살펴보면,

[22:46] 야심찬 프로젝트를 구축하려고 시도해봤다면

[22:48] 분명히 본 적이 있을 것입니다.

[22:50] 그냥 자유롭게 두면

[22:52] 정말로 과도하게

[22:53] 엔지니어링하기 시작하고

[22:55] 매우 복잡한 것으로

[22:58] 매우 빠르게 눈덩이처럼 불어나는 것 같습니다.

[23:00] 이 레포지토리의 작성자는

[23:03] 패턴 관성과 추론 잠금이라는

[23:06] 개념에 대해 이야기합니다.

[23:09] 이는 대형 언어 모델이

[23:11] 결함이 있는 계획을 매우 자신있게 따를 수 있다는 의미입니다.

[23:13] 이런 외부적인 넛지가 없다면,

[23:16] 정말로 정렬되지 않거나

[23:18] 과도하게 엔지니어링된 것을 얻을 수 있습니다.

[23:19] 그래서 이 Vibe Check MCP는

[23:22] 프로세스 중간에

[23:25] 반성적인 일시정지를 제공하여

[23:28] 특정 가정들을

[23:30] 당연하게 여기지 않고

[23:32] 올바른 방향으로

[23:33] 구축하고 있는지 확인합니다.

[23:35] 정말 멋진 것은 이것이

[23:38] 연구 기반의 접근 방식이라는 것입니다.

[23:39] 체인 패턴 인터럽트라고 불리며

[23:42] 위험한 변곡 순간에

[23:44] 짧고 적절한 시기의 일시정지 지점을 주입하여

[23:47] 사용자가 실제로 하려는 일을 중심으로

[23:49] 에이전트를 재정렬하고

[23:51] 미친 것으로 눈덩이처럼

[23:54] 불어나는 상황을 방지합니다.

[23:55] 예를 들어, '야, 나는 이걸 만들려고 한 게 아니었는데!'

[23:58] 이것이 우리가 피하려는 상황입니다.

[24:01] 멋진 점은

[24:02] 실제로 구축하고 있는 모든 것과

[24:04] 통합할 수 있다는 것입니다.

[24:06] 이를 위한 몇 가지 다른 도구가 있습니다.

[24:08] 첫 번째는 Vibe Check로,

[24:10] 작성자는 실제로

[24:12] 시스템 설정에, 즉 메인 에이전트

[24:16] 정의에 넣을 것을 권장합니다.

[24:18] 모델을 사용할 때마다

[24:20] 컨텍스트로 추가됩니다.

[24:22] 그리고 모델이 계속해서

[24:24] 빠져나가려는 근본적인 실수를 발견하면,

[24:27] 그런 실수들을 포착하여 저장할 수 있어서

[24:30] 계속해서 반복하지 않도록 합니다.

[24:32] 첫 번째는 우리가

[24:33] MCP를 설치해야 한다는 점입니다. 그리고

[24:36] 두 번째는 이런 종류의

[24:38] 필수 필드가 필요하다는 점인데, 이 경우에는

[24:40] claw.markdown 파일에 시스템이

[24:44] 이 기능을 사용해야 한다고 알려주는 내용이 있어야 합니다.

[24:46] 구체적으로는, 계획을 세운 후

[24:47] 그리고 주요 작업을 하기 전에 vibe check를 호출해야 한다고 명시되어 있습니다.

[24:49] 이 기능이 트리거되도록 해서

[24:52] 어떻게 작동하는지 확인해보겠습니다.

[24:53] 이 기능이 실행되는 동안

[24:55] 실제로 어떻게 보이는지 볼 수 있습니다.

[24:57] 이 vibe check가 실행될 때,

[24:58] 기본적으로 우리가 하려고 했던 것을 살펴봅니다.

[25:01] 목표가 무엇이었고 계획이 무엇이었는지,

[25:04] 그리고 그 목표 달성을 위해

[25:06] 얼마나 잘 진행했는지를 평가합니다.

[25:09] 이번에는 우리가 잘 했다고 판단하는 것 같네요.

[25:11] 그리고 지금 하고 있는 일은

[25:14] 한 번 더 돌아가서

[25:16] 자신이 한 일을 재검토하는 것입니다.

[25:18] vibe check가 검증에 대한 훌륭한 지적을 했다고 말하고 있습니다.

[25:21] 또한 프레임이나 모션 컴포넌트에

[25:22] prefers reduced motion 지원을 추가해야 한다고 제안합니다.

[25:25] 그걸 추가해보겠다고 하네요.

[25:27] 이제 실제로

[25:28] 구현을 개선해나가고 있습니다.

[25:30] 그리고 이제

[25:31] 실수에서 학습하고 있습니다.

[25:34] 이번에는 대신

[25:36] 뭔가 모호한 작업을 시도해보겠습니다.

[25:38] 왜냐하면 결국

[25:39] 지금까지는 매우 잘 정의된 작업들이었거든요.

[25:41] 하지만 단순히 이런 식으로 말하면 어떨까요?

[25:43] "이런 기능을 하는

[25:44] 서비스를 만들어주세요"라고 말하고

[25:46] 좀 애매하게 만들어서

[25:47] vibe check가 나타나서

[25:49] 더 나은 피드백을 주는지 확인해보겠습니다.

[25:52] 이제 실시간으로

[25:54] 우리가 뭔가를 하려고 할 때

[25:55] 아마도 의도한 방식으로 하면 안 될 때

[25:58] 어떻게 보이는지 볼 수 있습니다.

[25:59] 다시 한번, 우리가 이런 애매한 요청을 했습니다.

[26:01] "연구와 작성 기능이 완비된

[26:04] crew AI 서비스를 만들어주세요"라고 했는데,

[26:06] 이건 정말로

[26:07] 결국 꽤 애매한 요청이죠.

[26:09] 그리고 지금 vibe check 도구가

[26:12] 검사를 요청하고 있습니다.

[26:16] 이것이 실행되도록 하고

[26:17] 어떤 결과를 얻는지 확인해보겠습니다.

[26:20] 지금 보시는 것처럼

[26:22] 시작하기에는 꽤 명확한 계획이라고 하지만

[26:24] 그다음에는 모든 종류의

[26:25] 애매함이 있다고 말하고 있습니다.

[26:28] 지금 여기서 보고 있는 것은

[26:30] vibe check가 기본적으로

[26:33] Claude와 이 경우에 주고받는 대화로,

[26:35] 이러한 애매함을 고려해야 하고

[26:37] 당신의 피드백을 바탕으로

[26:40] 특정 기능들을 구현하고 다른 것들은

[26:42] 구현하지 말아야 한다고 알려주고 있습니다.

[26:44] 특히 바이브 코딩을 하는 사람들에게는

[26:46] 자신의 이해의 한계를 밀어붙이려고 하지만

[26:47] 동시에 머릿속에서는

[26:49] 올바른 방식으로 일을 하고

[26:51] 궤도에서 완전히 벗어나서

[26:52] 바보 같은 일을 하지 않으려는 마음이 있다는 것을 알고 있을 때,

[26:54] 이런 종류의 MCP는

[26:57] 시스템에 매우 좋은 체크포인트를 제공해서

[26:59] 언제 멈춰서 반성해야 하는지 알 수 있고

[27:02] 이런 종류의

[27:04] 메타 레이어를 갖게 됩니다.

[27:06] 정확히 당신이 무엇을 하고 있는지를

[27:08] 반성하는 메타 레이어이고, 당신이

[27:11] 올바르게 하고 있는지, 완전히

[27:13] 잘못된 일을 하고 있는지,

[27:14] 멈춰서 '잠깐, 내가 생각해야 할

[27:16] 것들이 있다'고 말해야 하는지를

[27:17] 판단할 수 있게 해줍니다. 이 도구는

[27:20] 강제로 그런 성찰을 하게 만드는

[27:22] 훌륭한 도구입니다. 따라서 이것은

[27:25] 우리의 코딩 도구를 '내가 시키는 대로 해'

[27:28] 타입의 관계에서 '이게 올바른 선택인지

[27:30] 생각해보고 지금 내가 놓치고 있는

[27:32] 것이 무엇인지 도와달라'는 관계로

[27:34] 바뀌게 도와줍니다. 이제 이 목록의

[27:38] 마지막 도구인데 정말 좋아하는

[27:41] 도구입니다. 특히 그 개념 자체가

[27:43] 좋고, 이런 타입의 도구는 AI 산업이

[27:45] 성숙해감에 따라 점점 더 우리 삶에

[27:48] 통합될 것이라고 생각합니다. 정말

[27:50] 이 도구를 좋아하고 활발하게

[27:52] 개발되고 있으며 'Pieces'라고 불립니다.

[27:55] 이 도구가 하는 일은 머신에서

[27:58] 실행되고 있는 여러 앱들을

[28:00] 설정해서 기본적으로 관찰하게

[28:03] 만들 수 있다는 것입니다. 즉, 그 화면들과

[28:06] 무슨 일이 일어나고 있는지를 보고

[28:09] 그 정보를 사용합니다. 그래서 예를 들어

[28:10] 터미널에서 클라우드 데스크톱으로,

[28:12] 클라우드 코드로, 그리고 iOS 시뮬레이터로

[28:15] 이동하면서 프로젝트나 작업 세트에서

[28:18] 같은 기본적인 것들을 작업하며

[28:20] 이곳저곳을 돌아다닐 수 있습니다.

[28:23] 이 시스템이 하는 일은 당신이

[28:26] 실제로 한 일들을 중심으로 기억을

[28:29] 형성하고 그 기억을 찾을 수 있게

[28:32] 해줍니다. 예를 들어, 내가 Tailwind

[28:34] 설정을 다루었던 곳을 찾고 싶다면

[28:36] 그런 것들을 검색할 수 있습니다.

[28:39] 그리고 이 기억 안에서 구체적으로

[28:41] 무엇을 다루고 있었는지에 대해

[28:44] 대화를 나눌 수도 있습니다. 아마도

[28:46] 그것이 버그였고 어떤 종류의 해결책을

[28:49] 찾았는지 기억하려고 할 때, 시스템을

[28:51] 사용해서 다시 무슨 일이 일어났는지,

[28:55] 우리가 무엇을 겪었는지, 그리고

[28:58] 궁극적으로 어떻게 문제를 해결했는지

[29:00] 대화를 나눌 수 있습니다. 당신 뒤에서

[29:02] 항상 당신이 하는 모든 일을 지켜보고

[29:04] 당신이 내린 해결책이나 완전히

[29:06] 넘어서지 못한 장애물들을 기억하는

[29:08] 또 다른 버전의 당신이 있다고

[29:10] 상상해보세요. 미리 말씀드리자면

[29:12] 이 모든 것은 로컬에서 처리됩니다.

[29:18] 즉, 시스템이 하는 모든 일, 모든

[29:21] 머신러닝이 실제로 당신의 머신에서

[29:24] 실행된다는 뜻입니다. 설정으로

[29:26] 들어가서 원한다면 클라우드 환경에서

[29:29] 그런 것들을 실행하도록 선택할

[29:32] 수 있지만, 현재 저는 모든 것을

[29:34] 실제 로컬 디바이스에서 실행하고

[29:37] 있습니다. 다시 말하지만 정말 멋집니다.

[29:40] 라마가 설치되어 활성화되어 있습니다.

[29:42] 따라서 특정 오픈소스 모델을 사용해서

[29:44] 모든 것을 실행할 수 있고, 아니면

[29:45] 클라우드 기반 제공업체를 선택해서

[29:48] 요청을 그곳으로 보낼 수도 있습니다.

[29:50] 다시 말해, 정말 구체적인 예를

[29:52] 들어보면 이것이 어디에 유용할지,

[29:54] 저는 이 인증 오류를 디버그해야

[29:56] 했던 적이 있습니다

[30:00] 2개월 전에 GraphQL 프로젝트로

[30:02] 작업했던 때를 생각해보면, 만약 내가

[30:05] 그때 해결했던 방법을 다시 찾아볼 수 있다면

[30:08] 얼마나 좋을까요? 그 해결책을

[30:11] 현재 프로젝트에 바로 적용할 수 있을 텐데요.

[30:13] 자, 이제 MCP 얘기로 넘어가면,

[30:16] 이 모든 정보는 원한다면 MCP로

[30:19] 노출시킬 수 있어요. 그리고

[30:22] 여기에 깔끔한 가이드가 있어서

[30:24] 실제로 워크플로우에 어떻게

[30:26] 통합할 수 있는지 설명해줍니다.

[30:28] Cursor, GitHub Copilot,

[30:30] Claude Desktop 같은 도구들과 함께 사용할 수 있고,

[30:33] 정말 부지런하다면 MCP를

[30:36] 컴퓨터에 로컬로 실행해서

[30:37] Claude와 연결할 수도 있어요.

[30:40] 어떤 방법을 택하든 매우 유용한 도구입니다.

[30:42] 제가 이 예시에서 사용하는 것처럼 VS Code를 쓴다면,

[30:46] GitHub Copilot과 함께 쉽게 사용해서

[30:48] 모든 시스템과 프로세스에

[30:50] 통합할 수 있습니다.

[30:52] AI 코딩은 거의 모든 것을 가속화하지만,

[30:55] 실수로부터 배우는 것만큼은 예외죠.

[30:58] 우리 대부분은 같은 실수를 계속해서

[31:01] 반복하는 경향이 있어요.

[31:02] AI가 문제를 만들고, AI가 해결하면,

[31:04] 우리는 그냥 "좋아, 다음으로 넘어가자"라고

[31:06] 말하거든요. 그래서 과거를 되돌아보고

[31:08] 그 해결책들을 반성할 수 있게 해주는

[31:09] 도구가 있다는 게 얼마나 멋진가요?

[31:11] 그래서 시간을 넘나들며

[31:13] 그것들을 끌어올 수 있어요.

[31:15] 다시 말하지만, 초보자와 전문가의 차이는

[31:18] 단순히 기술이 아니라,

[31:20] 패턴을 인식하고 해결책을

[31:23] 재사용할 줄 아는 능력입니다.

[31:25] 자, 여기까지가 제가 거의 매일

[31:28] 사용하는 실용적인 MCP들입니다.

[31:30] 이 주제와 관련해서, 만약 여러분이

[31:34] 실제로 MCP 서버를 구축하는 방법을

[31:36] 보고 싶다면 아래에 댓글로 알려주세요.

[31:39] 제가 조금씩 생각해온 프로젝트가 있는데,

[31:41] 아직 실제로 구축해보지는 못했거든요.

[31:43] 머릿속에 있는 걸

[31:44] 모든 분들과 함께

[31:45] 만들어보면 재미있을 것 같아요.

[31:47] 그러니까 좋아요와 구독 버튼 누르는 걸

[31:49] 잊지 마시고, 아래 커뮤니티에도 참여하세요.

[31:52] 실제 프로젝트를 구축하고

[31:55] 서로 피드백을 주고받으며

[31:58] 멋진 일들을 함께 하려는

[31:59] 훌륭한 사람들의 커뮤니티예요.

[32:01] 누가 그런 곳에 참여하고 싶지 않겠어요?

[32:03] 이번 영상은 여기서 마치겠습니다. 다음에 만나요!