teji

tede

AI 에이전트, 트레이딩 봇 개발 중인 남편의 일기 🤖
화장품에 진심인 간호사 아내의 코덕로그 💄

전체보기

클로드코드(Claude Code) AI 비서 만들기 2편: projects.yaml 하나로 여러 프로젝트 라우팅하는 방법 (2026)

클로드코드 Claude Code AI 비서 만들기 2편 프로젝트 라우팅 썸네일

AI 비서 하나가 여러 프로젝트를 헷갈리지 않고 나눠 맡게 하는 방법은, 프로젝트 명부(레지스트리) 파일 projects.yaml을 두고 메시지의 키워드(intent_hints)로 담당 프로젝트를 고른 뒤 그 프로젝트의 CEO 에이전트에게 위임하는 거예요. 판단이 모호하면(1등과 2등 점수 차가 ambiguity_threshold 0.6보다 작으면) 추측하지 않고 사용자에게 되묻고, 봇 종료, 실주문, 배포 같은 위험 명령은 위임 전에 반드시 확인을 받아요. 이 글은 그 판단 구조와 실제 설정 파일을 그대로 보여드려요.

1편에서는 클로드코드(Claude Code)를 텔레그램으로 부르는 MCP 채널 연결법을 다뤘어요. 저는 가상자산 거래소에서 데이터 분석과 사업 기획을 하고, 개인용 AI 비서 “tede”를 직접 만들어 매일 쓰고 있어요.

이 글에서 다루는 내용

  • 비서 하나가 여러 프로젝트를 헷갈리지 않고 나눠 맡는 원리
  • 그걸 가능하게 하는 projects.yaml 레지스트리의 정체 (실제 파일 공개)
  • 말이 모호할 때 추측하지 않고 되묻게 만드는 안전장치

왜 라우팅이 필요한가요?

저는 트레이딩 봇, 앱, 뉴스 수집기, 시장 분석기를 동시에 굴려요. 처음엔 프로젝트마다 터미널을 따로 열었는데, 각 프로젝트의 맥락을 머리에 다시 올리는 것부터 일이었어요. 그래서 1편에서 창구를 텔레그램 하나로 합쳤어요.

그러자 새 문제가 생겼어요. 창구가 하나가 되니 “지금 이 말이 트레이딩 얘기인지, 앱 얘기인지”를 비서가 스스로 판단해야 해요. “포지션 어때?”는 트레이딩으로, “빌드 돌려줘”는 앱으로 넘어가야 하죠. 이 판단을 사람이 매번 지정하지 않아도 되게 만드는 게 라우팅이에요.

핵심 아이디어: 프로젝트 명부 projects.yaml

Claude Code AI 비서 라우팅 구조: projects.yaml 레지스트리로 메시지를 프로젝트 CEO 에이전트에 분배

비서에게 프로젝트들을 명부(레지스트리)로 알려줘요. 각 프로젝트가 무엇을 하는지, 어떤 말이 나오면 그 프로젝트 얘기인지, 무슨 일을 시킬 수 있는지를 파일 하나에 적어두는 거예요. 저는 이걸 projects.yaml이라고 불러요. 실제 파일을 민감한 값만 빼고 그대로 보여드릴게요.

version: 1

policy:
  workspace_root: "C:/Users/me/works"
  require_user_confirm_for:        # 이 명령들은 위임 전에 반드시 다시 물어본다
    - "trading.stop_bot"           # 봇 종료
    - "trading.execute"            # 실주문
    - "app.deploy_production"      # 배포

projects:
  - id: trading
    name: "자동매매 봇"
    description: "퍼페추얼 DEX 자동매매. 실거래 중."
    intent_hints: ["트레이딩", "봇", "포지션", "PnL", "equity"]
    capabilities:
      - project.status             # 공통: 상태 조회
      - trading.query_positions    # 활성 포지션 조회
      - trading.tail_log           # 로그 마지막 N줄
      - trading.stop_bot           # 봇 정지 (확인 필수)
    ceo:
      type: "claude_code_subagent"
      entrypoint: "trading/.claude"

  - id: app
    name: "서비스 앱"
    description: "모바일 앱 + 백엔드."
    intent_hints: ["앱", "빌드", "배포", "APK"]
    capabilities:
      - project.status
      - app.build
      - app.deploy_production      # 배포 (확인 필수)
    ceo:
      type: "claude_code_subagent"
      entrypoint: "app/agents/ceo"

routing:
  ambiguity_threshold: 0.6         # 1등과 2등 점수 차가 이보다 작으면 재질문
  fallback: "ask_user"             # 모호하면 추측하지 말고 되물어라

포인트는 세 덩어리예요.

  • intent_hints: “이런 단어가 나오면 이 프로젝트”라고 알려주는 힌트예요
  • capabilities: 그 프로젝트에 시킬 수 있는 일의 목록이에요
  • ceo: 실제 일을 할 담당(그 프로젝트의 CEO 에이전트)이 어디 있는지예요

비서는 어떤 순서로 판단하나요?

말이 들어오면 비서는 위에서부터 차례로 아래 순서를 밟아 “어디로 넘길지”를 정해요.

  1. 프로젝트를 직접 말했나? “트레이딩 봇 상태 알려줘”처럼 콕 집으면 바로 그곳으로
  2. intent_hints와 겹치나? “포지션 어때?”의 ‘포지션’이 trading 힌트와 맞으면 trading으로
  3. 공통 명령인가? “상태 알려줘”처럼 어디든 될 수 있는 건, 프로젝트를 안 정했으면 되물어요
  4. 매칭이 없거나 모호한가? 추측하지 않고 “어느 프로젝트 말씀이세요?”라고 물어요

4번이 제일 중요해요. AI가 지레짐작으로 엉뚱한 프로젝트에 명령을 넘기면 그게 사고예요. 그래서 “모호하면 무조건 되묻기”를 규칙으로 박아뒀어요.

프로젝트 intent_hints (예) 이렇게 말하면 여기로
trading 트레이딩, 봇, 포지션, PnL “포지션 어때?”
app 앱, 빌드, 배포, APK “앱 빌드 돌려줘”
news 뉴스, 다이제스트, 오늘 수집 “오늘 뉴스 요약해줘”
(없음/모호) 해당 없음 “어느 프로젝트 말씀이세요?” 재질문

넘긴 다음의 위임과 안전장치는?

AI 비서 위임 구조: 오케스트레이터가 프로젝트 CEO 에이전트에 작업을 넘기고 확인 게이트를 거치는 흐름

라우팅으로 목적지가 정해지면 실제로 그 프로젝트의 CEO 에이전트에게 일을 위임해요. 비서 본인은 직접 코딩하지 않아요. 요청을 정리해서 담당에게 넘기고, 결과를 다시 정리해서 저에게 돌려주는 중개자예요. 여기에 꼭 넣은 안전장치가 세 가지 있어요.

설계에서 지킨 3가지

  1. 모호하면 추측하지 말고 되묻기: AI의 “알아서 넘겨버리기”가 제일 위험해요. 확신이 없으면 무조건 질문하게 했어요
  2. 위험한 명령은 확인 게이트: require_user_confirm_for에 넣은 명령(봇 종료, 실주문, 배포 등)은 위임하기 전에 “이거 진행할까요?”를 반드시 물어요. 실수로 실거래가 나가면 돈이 걸린 문제예요
  3. CEO끼리 직접 대화 금지: 프로젝트 간 정보는 반드시 비서를 거쳐요. 트레이딩 CEO가 앱 CEO에게 바로 말 걸지 못해요. 각자 자기 프로젝트 맥락만 알게 해서, 한 프로젝트의 사고가 다른 곳으로 번지지 않게 격리했어요

자주 묻는 질문

Q. 프로젝트가 많아지면 비서가 헷갈리지 않나요?
그래서 intent_hints가 있어요. 점수가 애매하면(1등과 2등이 비슷하면) 추측하지 않고 되물어요. 헷갈릴 땐 “헷갈린다”고 말하게 하는 게 핵심이에요.

Q. 새 프로젝트는 어떻게 추가하나요?
projects.yaml에 항목 하나를 더 적으면 돼요. id, description, intent_hints, capabilities, ceo 위치만 채우면 비서가 다음부터 그 프로젝트를 인식해요.

Q. 왜 비서가 직접 일하지 않고 위임하나요?
프로젝트마다 맥락(코드, 규칙, 히스토리)이 무거워요. 비서가 그걸 다 짊어지면 금방 뒤죽박죽이 돼요. 비서는 얇게 두고 무거운 맥락은 각 CEO에게 맡겨야 프로젝트가 늘어도 무너지지 않아요.

Q. YAML을 꼭 써야 하나요?
아니에요. JSON이든 무엇이든 “프로젝트 명부”만 표현되면 돼요. 저는 사람이 읽고 고치기 편해서 YAML을 골랐어요.

따라하기 팩 (무료)

이번 편의 projects.yaml 예시와 라우팅 규칙 설명을 파일로 정리했어요. 본인 프로젝트 이름만 바꿔서 시작하면 돼요.

  • projects.example.yaml: 위 예시의 전체 버전 (주석 포함)
  • README.md: 항목별 채우는 법과 라우팅 판단 순서 설명

tede_routing_pack.zip 다운로드

README대로 채우면 돼요. 이것도 AI에게 통째로 보여주고 “내 프로젝트에 맞게 고쳐 줘”라고 하면 금방이에요.

시리즈 전편과 다음 편

전편은 클로드코드 텔레그램 AI 비서 만들기 1편: MCP 채널 연결이에요. 3편에서는 세션이 끊겨도 기억을 유지하는 파일 기반 메모리, 즉 비서가 어제 하던 얘기를 오늘 이어서 하게 만드는 구조를 다뤄요.

출처: 본문의 projects.yaml과 라우팅 규칙은 필자가 직접 작성해 운영 중인 tede 시스템에서 발췌해 일반화한 것이고, 민감 값(chat_id, equity, 경로 등)은 제거했어요. 참고 문서는 MCP 공식 문서(https://modelcontextprotocol.io)예요.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *