바이브마피아의 세컨브레인 MCP를 소개합니다

한 줄 핵심

세컨브레인 MCP는 AI가 자주 틀리는 판단만 카드로 축적해 필요할 때 검색·참조하게 만들어, 프롬프트보다 안정적으로 개발·기획·디자인 의사결정을 보정하는 실전형 작업 보조 도구다.

시간별 요약

1. 0:00
   시작 대기 방송 시작 전 준비 과정에서 오디오와 진행 상태를 점검한다.
2. 2:45
   인사 — 오늘 주제, 세컨브레인 MCP 세컨브레인 MCP의 개념과 활용법을 소개하고, 실제 작업에 어떻게 도움이 되는지 시연하겠다고 예고한다. 기존 세컨브레인 담론보다 실무 협업에 초점을 둔 도구라는 방향이 드러난다.
3. 6:04
   스킬·프롬프트로는 강제가 안 되던 실수 프롬프트나 스킬만으로는 반복 실수를 안정적으로 막기 어려워, 판단을 외부에서 조회하게 만드는 MCP 방식이 필요하다고 정리한다. 개인이 축적한 교정 사례를 재사용하면 생산성과 점검 품질이 함께 오른다.
4. 9:01
   내 지식을 다 옮기지 않은 이유 — AI가 모르는 것만 이미 AI가 알고 있는 지식까지 옮기면 중복과 컨텍스트 낭비가 생기므로, AI가 자주 틀리는 교정 사례만 담는다고 설명한다. 세션 시작 시 일반 원칙을 주고, 중요한 순간에만 관련 판단 카드를 검색해 쓰는 구조다.
5. 12:19
   적용 사례 — 결제 기능·랜딩 디자인 결제 기능 검토에서는 위험을 먼저 짚고, 랜딩 디자인에서는 여러 시안을 비교하게 만들어 더 나은 협업 흐름을 만든다. 기획·디자인·개발 전반에 걸쳐 상황별 태그로 관련 판단만 불러오는 방식이 핵심이다.
6. 16:00
   가격, 그리고 매일 늘어나는 판단 카드 구독형 상품으로 제공할 계획이며, 라이브와 작업을 거치며 판단 카드가 매일 추가되는 성장형 구조라고 설명한다. 실제 사용 중 불편한 점을 계속 개선하는 살아 있는 지식베이스로 운영된다.
7. 17:17
   어떤 판단 카드가 들어 있나 라이브러리 선택, 공통화 시점, 테스트 전략, 문구 작성 같은 실무 판단 기준이 카드로 들어 있다. 이미 AI가 잘하는 일반론보다, 잘 못하는 부분을 보정하는 지침만 남긴다.
8. 20:04
   다른 도구(포니테일·드라이포지)와 같이 써도 될까 포니테일처럼 단순한 일반 규칙 주입 도구보다, 마피아 브레인 MCP는 상황별 판단 검색이 가능해 더 구체적이라고 본다. 드라이포지와는 용도와 철학이 다르며 함께 써도 문제없다고 말한다.
9. 22:25
   시연 — 캡컷 같은 영상 편집기 만들기 실제 예시로 캡컷 유사 편집기를 만들며 MCP가 어떤 판단을 불러오는지 보여 준다. 처음부터 무작정 구현하기보다, 관련 카드들을 검색해 방향성을 먼저 잡는다.
10. 25:03
    처음부터 만들지 마세요 — 오픈소스부터 찾는 판단 영상 편집기를 새로 만드는 대신 오픈소스를 활용하거나 화면 없는 자동화를 먼저 시도하라는 판단이 나온다. 불편함이 확인된 뒤에만 새 구현으로 넘어가라는 현실적인 개발 전략이 제시된다.
11. 27:23
    브레인에 없는 주제를 물으면? 세컨브레인은 모든 지식을 담는 저장소가 아니라, 판단 기준과 설계 원칙을 담는 도구다. 완전히 생소한 주제보다는, 실무에서 자주 부딪히는 의사결정 영역에 강하다.
12. 33:12
    판단 카드끼리 부딪히면 새 판단 카드가 기존 카드와 충돌하면 확인을 거치고, 갱신되면 이전 버전은 폐기한다. 채택률과 맥락을 함께 관리해 판단 체계를 최신 상태로 유지한다.
13. 38:13
    편집자 대신 Claude에게 편집 맡기기 영상 편집은 사람보다 Claude가 더 잘할 수 있다고 느끼며, 편집보다 기획 역할이 더 중요해질 수 있다고 본다. 다만 무거운 작업은 검증 시간이 길어질 수 있어 구조와 파이프라인이 중요하다.
14. 41:11
    기획하는 사람만 살아남을까 AI가 구현을 쉽게 만들수록 기획과 문제 정의 능력이 더 중요해진다고 본다. 젊은 세대는 아이디어를 빠르게 실험할 수 있어 오히려 유리할 수 있다고 전망한다.
15. 47:51
    디자인 개선 — 브레인 없이 vs 브레인과 함께 브레인 없이 시키면 디자인이 애매해지기 쉽지만, 브레인과 함께하면 레퍼런스 조사와 시안 비교가 포함된 구조적인 개선이 이뤄진다. 성공 기준을 숫자로 정하는 카드도 함께 작동한다.
16. 52:24
    실측이 너무 오래 걸릴 때 — 교정을 카드로 남긴다 실측이 지나치게 오래 걸리면 그 자체가 최선인지 의심하고, 우회 검증이 가능한지 다시 점검해야 한다. 이렇게 발견한 교정 포인트는 새 카드로 남겨 다음 작업에 반영한다.
17. 1:02:19
    디자인 시안은 여러 개를 나란히 비교 디자인은 한 번에 하나보다 여러 시안을 병렬로 만들고 비교해야 품질이 오른다. 뻔한 미사여구보다 실제 교정 포인트만 반영된 시안이 더 유용하다.
18. 1:09:15
    다른 프로젝트에서도 한 줄로 쓰기 프로젝트마다 길게 설명하지 않아도, 한 줄로 MCP 사용을 지시하면 관련 카드를 불러와 작업한다. 기술 검토나 새 서비스 계획 같은 맥락에서도 카드 기반 판단이 일관되게 작동한다.
19. 1:15:09
    아키텍처 기술 검토 결과 — 조건부 적합 기술 검토는 적합/부적합보다 기준을 먼저 정의하는 과정이 중요하며, 조건부 적합 같은 판단이 나온다. 기존 코드를 최대한 활용하되, 숫자와 기준으로 검증 가능한 형태로 의사결정한다.
20. 1:17:10
    성공 기준은 숫자로 에이전트 작업은 목표가 숫자로 정의되지 않으면 방향을 잡기 어렵다. 완성 실패, 미사용 실패, 버그 실패 같은 리스크를 세분화해 사전에 제거하는 방식이 효과적이다.
21. 1:21:43
    설계 후 점검을 맡기면 교정할 게 줄어든다 설계를 먼저 한 뒤 MCP로 점검하면 최종 설계에서 손볼 부분이 크게 줄어든다. 비즈니스 전략이나 방향성 같은 상위 판단만 남고, 세부 교정은 적어진다.
22. 1:29:12
    오픈소스 편집기가 ffmpeg보다 14배 느리다 오픈소스 편집기는 브라우저 런타임 구조 때문에 성능이 크게 떨어져, 네이티브 ffmpeg 기반으로 바꿔야 한다는 결론이 나온다. 기존 자산을 버리기보다 성능만 개선하는 방향이 권장된다.
23. 1:32:42
    검증 게이트는 빨라야 한다 에이전트가 자주 실행하는 게이트는 30초 이내로 끝나게 최적화해야 한다. 너무 느린 검증은 개발 흐름을 막지만, 에이전트는 그 느림을 스스로 문제 삼지 않기 때문이다.
24. 1:44:35
    AI로 창업하기 — 오토 Y컴비네이터 AI 에이전트가 아이디어 탐색, 팀 빌딩, 시장 검증을 자율적으로 수행하는 창업 실험을 소개한다. 사람처럼 행동해야 하는 비즈니스는 배제하고, 광고와 실험으로 가설을 검증하는 구조를 쓴다.
25. 1:49:08
    에이전트는 사람인 척하지 않는다 에이전트가 사람인 척하며 커뮤니티를 속이는 방식은 기만이므로 금지한다. 대신 별도 전화번호·이메일·SNS를 주되, 허용된 채널과 페이드 마케팅 중심으로 검증하게 한다.
26. 1:59:21
    세컨브레인 MCP를 만든 계기 AI가 내린 설계를 사람이 하나하나 교정하는 일이 너무 비효율적이어서, 아예 MCP로 박제해 자동 참조하게 만들었다. 앞으로는 노하우를 설명문으로 풀기보다 연결 가능한 지식 시스템으로 제공하는 흐름이 강해질 것으로 본다.
27. 2:02:05
    노션은 미팅 노트로만 쓴다 노션은 미팅 노트와 공유 문서 정리에 가장 적합해서 계속 쓴다. 다만 지식베이스 원천으로 쓰기엔 한계가 있고, 더 적극적인 자동화는 로컬 DB와 에이전트로 대체한다.
28. 2:06:52
    내보내기 30분 → 2분 30초 오픈소스 편집기의 내보내기 시간을 30분 이상에서 2분 30초로 줄이는 데 성공한다. 웹 기반 구조의 한계를 보완하려고 데스크톱 의존 구조로 바꾼 점이 핵심이다.
29. 2:13:12
    롱폼은 어떻게 만드나 — 편집 피드백을 편집기 안에서 롱폼 제작은 전사본, 자막, 채팅 로그를 종합해 자동 편집하고, 피드백도 텍스트가 아니라 편집기 안에서 직접 주는 것이 핵심이라고 설명한다. 편집 구간을 정확히 짚기 어렵기 때문에 시각적 피드백 환경이 필요하다.
30. 2:15:36
    Claude 데스크톱이 자꾸 컴팩트할 때 세션이 지나치게 빨리 컴팩트된다면 컨텍스트 소모보다 코드 구조나 작업 방식에 문제가 있을 가능성이 높다고 본다. 리팩터링과 하네스 정리를 먼저 해야 한다는 조언이 나온다.
31. 2:21:16
    MCP 속 지침은 어떻게 고치나 MCP에는 프로젝트 특화 지침이 아니라 범용적인 판단 기준만 넣고, 프로젝트별 지침은 별도로 관리한다. 수정 사항은 하루 작업을 점검해 판단 카드로 추가하는 방식으로 반영한다.
32. 2:30:27
    오른팔 가입 안내 — 강의노트 보는 법 오른팔 회원은 사이트에서 채널 인증 후 이전 라이브의 강의노트를 정리된 글 형태로 볼 수 있다. 긴 라이브를 복습하기 쉽게 만드는 실용적 혜택이 강조된다.
33. 2:40:21
    드라이포지와 차이 — 하네스 vs 지식인 드라이포지는 프로세스에 가깝고, 마피아 MCP는 실제 판단 사례를 모아둔 지식인에 가깝다고 구분한다. 백과사전보다 질문에 답하는 지식 시스템에 가깝게 설계했다.
34. 3:03:23
    SaaS 구독 대신 직접 만들기 코딩 에이전트 덕분에 예전에는 구독해야 했던 도구를 직접 만들 수 있어, SaaS 비용을 줄일 수 있다고 본다. 중간중간 아티팩트를 남기며 작업 흐름을 이어 가는 방식이 중요하다.
35. 3:11:35
    편집기를 웹으로 만들기 어려운 이유 영상 편집은 무거운 작업이라 브라우저 기반으로는 성능 한계가 크고, 장기적으로 데스크톱 앱이 더 적합하다고 본다. 롱폼 렌더링처럼 긴 작업일수록 웹 구조의 비용이 커진다.
36. 3:25:14
    AI 컷 편집 기능 시연 AI가 컷이 말 끝 전에 잘리는 문제를 인식하고 자동으로 편집 조정을 수행한다. E2E 테스트까지 돌리며 영상 편집 기능이 실제로 작동하는지 확인한다.
37. 3:37:16
    어도비 앱을 복제해도 될까 Adobe 앱을 그대로 복제하는 것은 기능은 많지만 유지보수 부담이 너무 크므로 비추천이라고 말한다. 개인용 툴은 필요한 기능만 좁혀서 자체 구현하는 편이 낫다.
38. 3:39:53
    Opus·Sonnet·effort 고르는 기준 속도와 품질을 감안하면 Opus 5.5를 주로 쓰고, Sonnet 5.5나 낮은 effort는 특정 상황에서만 고려한다. 토큰을 아끼기보다 작업 품질을 유지하는 쪽을 선호한다.
39. 3:41:41
    LLM 위키에 쌓지 말아야 할 것 LLM이 이미 아는 내용은 위키나 세컨브레인에 또 쌓지 말아야 한다. 실제로는 개인 취향과 비즈니스 특화 안목처럼 AI가 모르는 부분만 남기는 것이 핵심이다.
40. 3:48:04
    "OO 엔지니어링"은 마케팅일 뿐일까 새로운 엔지니어링 용어가 난립하지만, 에이전트 시대에는 루프와 그래프를 설계하는 일이 실제로 중요하므로 전부 마케팅으로만 보긴 어렵다고 본다. 기술 변화가 빠르기 때문에 용어도 계속 세분화될 것이라고 전망한다.
41. 3:50:39
    마무리 세컨브레인 MCP와 영상 편집기 시연을 마치며, 앞으로도 다양한 활용 사례를 보여 주겠다고 마무리한다. 시청자에게 감사 인사를 전하고 라이브를 종료한다.

실무 인사이트

• AI가 이미 잘 아는 일반론을 지식베이스에 넣기보다, 자주 틀리는 판단만 카드화해야 검색 비용과 컨텍스트 낭비를 줄일 수 있다.
• 에이전트 작업의 품질은 프롬프트 길이보다도 성공 기준, 실패 경로, 검증 속도 같은 운영 규칙을 얼마나 명확히 설계하느냐에 더 크게 좌우된다.
• 영상 편집처럼 무거운 도메인에서는 웹 기반 자동화보다 데스크톱·네이티브 구조와 시각적 피드백 루프가 실무적으로 유리하다.