[실밸개발자] 바이브코딩 클럽

3단계 확장 학습 노트: 바이브코딩 클럽에서 읽은 AI 작업 운영체제

Deep Dive · MCP, 세컨브레인, 커뮤니티, 번역 시장을 하나의 운영체제 관점으로 묶어 읽는다.

바이브코딩 클럽의 2026-05-31 대화는 표면적으로는 매우 산만하다. MCP Bridge 링크가 나오고, Upstage Solar Pro 4와 DeepSeek v4 Flash 비교가 나오고, 우푸님의 Upusium 식사 모임이 길게 이어지고, Claude Code가 “마님”이라고 부르는 문제로 웃다가, 밤에는 Graphify와 LLM Wiki, NotebookLM, 번역 온톨로지 이야기로 간다. 하지만 학습 관점에서 보면 이 산만함이 오히려 중요하다. 실제 AI 실무는 논문 하나, 모델 하나, 프레임워크 하나로 진행되지 않는다. 도구 연결, 작업 환경, 지식 축적, 커뮤니티 신뢰, 콘텐츠 재가공, 비용 관리가 뒤섞인 상태로 움직인다. 1단계 흐름으로 보면, 새벽의 MCP Bridge는 “AI가 도구를 더 안정적으로 쓰게 하는 방법”에 대한 신호다. MCP Bridge by Appfactor는 타입이 지정된 스키마, 인증, 속도 제한, 응답 처리를 포함하는 MCP 도구 정의를 자동 생성한다고 소개됐다. 링크는 https://www.mcp-bridge.ai/ 이다. 여기서 초보자는 “API를 MCP로 쉽게 바꿔주는구나”까지만 읽기 쉽다. 하지만 한 단계 더 들어가면, MCP의 진짜 문제는 연결이 아니라 운영이다. 도구가 성공할 때는 누구나 데모를 만든다. 문제는 인증이 만료될 때, rate limit에 걸릴 때, API 응답이 바뀔 때, 모델이 잘못된 인자를 넣을 때다. 그래서 MCP Bridge를 볼 때는 자동 생성보다 실패 처리, 스키마 안정성, 클라이언트 호환성, 로그 관찰 가능성을 먼저 봐야 한다. 2단계 인사이트로 보면, 우푸님의 Upusium은 이 방의 기술 문화가 어떻게 관계 자본으로 확장되는지 보여준다. 링크는 https://upusium.vercel.app/ 이다. 우푸님은 서울 이직을 계기로 도움을 준 사람들과 식사하고 싶다고 했고, 회비 없이 본인이 부담하겠다고 했다. 여기까지만 보면 훈훈한 모임 공지다. 그런데 신청 이유를 LLM이 추론해 순위를 매기고, 정기 운영과 후원 가능성까지 언급한 대목을 보면 이것은 커뮤니티 운영 실험에 가깝다. AI 커뮤니티에서 학습은 문서나 강의로만 일어나지 않는다. 누가 누구를 신뢰하는지, 누가 실제로 프로젝트를 끝까지 밀어붙이는지, 누가 질문에 답하고 누가 피드백을 주는지의 네트워크 안에서 학습이 가속된다. Upusium은 그런 온라인 신뢰를 오프라인 관계로 바꾸려는 시도다. 3단계 더 깊게 들어가면, 밤의 세컨브레인 대화가 가장 중요하다. 아웃라이너님은 세컨브레인을 제대로 만들려고 하니 그래프 연결로 끝나는 게 아니라 입력 파이프라인, LLM 가공 방식, 표시 방식까지 필요하다고 했다. 부담님은 Graphify를 가져왔고, James Baek님은 Graphify가 코드처럼 함수 호출과 의존성이 명확한 영역에서는 토큰을 아껴주지만 자연어 위키에서는 일반 RAG와 비슷해질 수 있다고 설명했다. 링크는 https://graphify.net/kr/ 이다. 이 설명은 매우 실전적이다. 많은 사람이 “지식 그래프를 붙이면 똑똑해진다”고 생각하지만, 실제로는 엔티티를 어떻게 식별하고, 새 데이터가 들어올 때 기존 엔티티와 같은지 어떻게 조정하고, 관계가 틀렸을 때 어떻게 고치는지가 더 어렵다. 이것이 reconciliation 또는 entity resolution 문제다. 번역 시장 질문도 같은 흐름이다. 안지훈님은 DeepL이나 ChatGPT가 이미 번역을 잘하는데 어떤 페인포인트가 남아 있는지 물었다. 마스트님은 회사나 개인의 온톨로지를 지식 그래프로 만들고 번역 시스템과 결합하는 방향을 말했다. 이 답변은 짧지만 핵심을 찌른다. 일반 번역 품질은 이미 상향 평준화됐다. 하지만 회사마다 제품명, 부서명, 사람 이름, 프로젝트 코드, 금칙어, 선호 문체가 다르다. 고객사가 돈을 낼 가능성이 있는 지점은 “문장이 더 자연스럽다”가 아니라 “우리 회사의 말을 정확히 안다”이다. 즉 번역 제품의 차별점은 모델이 아니라 고객 조직의 지식 구조화가 된다. Claude/Codex 작업 환경 대화도 운영체제 관점으로 봐야 한다. Claude가 “마님”, “형님” 같은 호칭을 섞는 문제는 웃기지만, output 문서에 말투 오염이 섞일 수 있다는 DV님의 우려는 실제 품질 문제다. 한글 데이터, 번역 습관, Discord MCP의 말투, 장기 컨텍스트가 뒤섞이면 모델 output이 예상치 못하게 변할 수 있다. 이를 막으려면 단순히 “하지 마”라고 쓰는 것보다 output style, 금지 표현, 리뷰 단계, 샘플 기반 검수를 운영해야 한다. 토큰락, OOM, Zed와 VS Code 선택, cmux 전환, CLAUDE_CODE_EFFORT_LEVEL 설정도 같은 맥락이다. AI 개발 생산성은 모델 성능보다 작업 환경의 마찰을 줄이는 데서 온다. 따라서 이 방의 핵심 학습 과제는 세 가지다. 첫째, MCP 도구를 하나 골라 성공/실패 계약을 문서화해 본다. 둘째, 내 자료 20개만 가지고 LLM Wiki 또는 세컨브레인 파이프라인을 만든 뒤, Graphify 같은 그래프 계층이 실제로 토큰을 줄이는지 확인한다. 셋째, 내가 만드는 문서나 번역 output에서 말투 오염과 용어 불일치가 생기지 않도록 검수 규칙을 만든다. 이 세 가지를 해보면 31일 대화는 단순 잡담이 아니라 AI 작업 운영체제를 만드는 재료가 된다. 추가 워크북 1: MCP Bridge를 실제로 평가하는 방법. 먼저 사내나 개인 프로젝트에서 자주 쓰는 API 하나를 고른다. 예를 들어 Notion, Google Drive, GitHub Issues, 사내 CRM, 번역 용어집 같은 것이다. 그 API를 MCP로 붙일 때 첫 번째로 적을 문서는 “무엇을 할 수 있는가”가 아니라 “무엇을 하면 안 되는가”여야 한다. 모델이 삭제 API를 호출할 수 있는지, 호출할 수 있다면 dry-run이 필요한지, 같은 요청을 두 번 보냈을 때 idempotent한지, rate limit에 걸리면 사용자에게 어떤 문장으로 설명해야 하는지를 먼저 적는다. 그 다음에야 create, read, update, search 같은 도구 정의를 만든다. 좋은 MCP 도구는 화려한 기능보다 안전한 실패를 잘한다. 실패가 설명 가능하면 사람은 다시 시도할 수 있고, 실패가 모호하면 모델은 같은 실수를 반복한다. 추가 워크북 2: 세컨브레인을 만들 때 바로 그래프부터 만들지 않는다. 첫 주에는 원문 저장소와 출처 표시만 만든다. 둘째 주에는 요약과 태그를 만든다. 셋째 주에는 같은 사람, 같은 회사, 같은 프로젝트를 같은 엔티티로 묶는 규칙을 만든다. 넷째 주에야 Graphify나 knowledge graph 계층을 붙인다. 이 순서가 중요한 이유는 지식 그래프가 틀렸을 때 수정 비용이 크기 때문이다. 자연어 문서는 애매한 표현이 많다. “OpenAI”, “오픈AI”, “ChatGPT 만든 회사”가 같은 엔티티인지 판단해야 하고, “Claude Code”와 “Claude 앱”을 같은 것으로 묶으면 안 된다. 이 작업을 LLM에게 전부 맡기면 처음에는 그럴듯하지만 데이터가 늘어날수록 오류가 누적된다. 그래서 엔티티 후보, 확정 엔티티, 병합 이력, 사람이 승인한 규칙을 분리해야 한다. 추가 워크북 3: AI 번역 제품을 만든다면 테스트 문장을 일반 뉴스로 잡지 말아야 한다. 일반 뉴스는 이미 ChatGPT와 DeepL이 잘한다. 대신 회사 내부 문서에서 나오는 고유명사, 제품 약어, 직급, 고객사 이름, 법무 문구, 이전 번역 메모를 넣어야 한다. 평가 기준도 BLEU 같은 자동 점수보다 “이 회사 사람이 봤을 때 우리 말투인가”가 중요하다. 번역 틈새시장은 언어 모델 경쟁이 아니라 고객 지식 운영 경쟁이다. 온톨로지를 만든다는 것은 거창한 그래프 데이터베이스를 먼저 도입한다는 뜻이 아니다. 처음에는 CSV로도 된다. 용어, 금지 번역, 선호 번역, 예문, 출처, 승인자, 마지막 수정일만 있어도 시작할 수 있다. 추가 워크북 4: 커뮤니티 운영을 제품처럼 본다면 Upusium에서 배울 점이 많다. 좋은 커뮤니티는 정보가 많아서만 유지되지 않는다. 누가 실제로 도움을 줬고, 누가 후속 행동을 했고, 누가 새 사람을 환대했는지가 남아야 한다. LLM으로 참석 이유를 순위화하는 실험은 재미있지만, 편향도 생길 수 있다. 글을 잘 쓰는 사람이 과대평가되고, 조용히 기여하는 사람은 빠질 수 있다. 그래서 커뮤니티 AI 운영에는 항상 사람의 보정이 필요하다. 이 관점은 AI 제품에도 그대로 적용된다. 모델이 추천한 순위가 사람의 신뢰를 완전히 대체하면 안 되고, 사람이 판단할 수 있는 근거를 보여줘야 한다. 추가 워크북 5: Claude/Codex 말투 오염을 막는 방법. 첫째, output style에 금지 호칭과 문체를 명시한다. 둘째, 최종 문서 생성 전 금지어 스캔을 돌린다. 셋째, 장기 컨텍스트에 농담이나 역할극이 섞였으면 새 세션을 연다. 넷째, 문서 본문과 채팅 농담을 같은 컨텍스트에 오래 두지 않는다. 다섯째, 한국어 데이터가 많을 때는 번역투와 호칭 오염을 별도 리뷰 항목으로 둔다. 이 문제는 웃고 넘길 수 있지만, 고객에게 보내는 문서나 리포트에 섞이면 신뢰가 바로 떨어진다. 따라서 output 품질은 모델 감성이 아니라 운영 체크리스트로 관리해야 한다. 추가 학습 질문: 이 대화를 내 업무에 옮긴다면 무엇을 먼저 바꿀 것인가. 첫째, 지금 내가 반복해서 설명하거나 복사해 붙이는 작업을 하나 고른다. 둘째, 그 작업의 입력과 출력 예시를 3개씩 모은다. 셋째, 실패 사례를 일부러 적는다. 넷째, AI가 처리할 부분과 사람이 승인할 부분을 나눈다. 다섯째, 다음 실행 때 결과가 좋아졌는지 확인할 기준을 만든다. 이 다섯 단계를 거치면 오픈채팅에서 본 도구와 링크가 단순 정보가 아니라 내 작업 시스템을 바꾸는 재료가 된다. 추가 학습 질문: 좋은 자동화와 나쁜 자동화의 차이는 무엇인가. 좋은 자동화는 사람이 보던 판단 기준을 숨기지 않고 드러낸다. 나쁜 자동화는 “AI가 알아서 했다”고 말하면서 근거와 실패 가능성을 감춘다. 좋은 자동화는 실패했을 때 어디서 깨졌는지 알 수 있다. 나쁜 자동화는 실패해도 원인을 찾을 수 없다. 좋은 자동화는 작은 단위로 다시 실행할 수 있다. 나쁜 자동화는 전체를 처음부터 다시 돌려야 한다. 따라서 AI 도구를 붙일 때는 성공 화면보다 실패 화면을 먼저 설계해야 한다. 추가 학습 질문: 커뮤니티 대화에서 사람을 어떻게 읽을 것인가. 링크를 많이 공유하는 사람은 레이더 역할을 한다. 실제 경험담을 말하는 사람은 운영 지식을 제공한다. 질문을 던지는 사람은 시장의 불편함을 드러낸다. 농담이나 실패담을 말하는 사람도 중요하다. 그 안에 모델의 실제 결함, 작업 환경의 마찰, 초보자가 막히는 지점이 들어 있기 때문이다. 리포트의 목표는 모든 발언을 동등하게 요약하는 것이 아니라, 이 역할들을 구분해 학습 가능한 신호로 바꾸는 것이다. 추가 학습 질문: 다음 날 같은 주제가 반복된다면 무엇을 추적할 것인가. MCP는 도구 연결에서 운영 안정성으로 가는지, LLM Wiki는 개인 지식관리에서 조직 지식관리로 가는지, Claude/Codex 환경 논의는 모델 성능에서 작업대 설계로 가는지, 콘텐츠 자동화는 생성에서 검수 파이프라인으로 가는지 추적한다. 하루치 리포트가 쌓이면 단순 뉴스 요약이 아니라 커뮤니티의 관심 이동 그래프가 된다. 바이브코딩 클럽에 적용하면, 다음 관찰 포인트는 “실험이 제품으로 바뀌는 순간”이다. 우푸님의 Upusium, 아웃라이너님의 수족관, 마포구비둘기님의 투자 대시보드, noon님의 NotebookLM 오디오 사례는 모두 작은 실험이 공개 피드백을 받는 장면이다. 이 방의 강점은 완성품보다 진행 중인 시행착오가 많이 보인다는 점이다. 그래서 앞으로 리포트는 단순히 링크를 모으는 대신, 누가 어떤 실험을 공개했고 어떤 피드백을 요청했으며 다음 버전에서 무엇이 바뀔 가능성이 있는지를 추적하면 좋다.