Msty Go · 글 22편Msty Go
  1. Msty Go 시작하기 — 설치부터 첫 실행 검증까지
  2. Msty Go 에이전트 만들기와 관리
  3. Msty Go Working Styles — 다섯 가지 작업 방식 고르기
  4. Msty Go 모델 제공업체 설정과 Model Assignments
  5. Msty Go Managed Services — 로컬 AI와 부가 서비스를 앱이 대신 준비하기
  6. Msty Go 보안 설정 — 발신자, 폴더, 네트워크, 승인
  7. Msty Go Airlock — 에이전트가 접속할 웹사이트 정하기
  8. Msty Go 도구 설정 — MCP 서버, 웹 검색, Skills Hub, Computer Use
  9. Msty Go Context Scout — 보내기 전에 관련 파일 찾아 붙이기
  10. Msty Go Extensions — 확장 기능 찾기, 설치, 만들기, 공유
  11. Msty Go Mission Control — 도우미 에이전트와 승인을 한곳에서 보기
  12. Msty Go Pulse — 일을 시작하기 전에 받는 브리핑
  13. Msty Go Side Chat — 주 대화를 건드리지 않고 짧게 묻기
  14. Msty Go Memory Bank — Working Brief와 Memory Pack으로 맥락 이어 가기
  15. Msty Go 작업 공간 프로필 파일 — SOUL.md, IDENTITY.md, USER.md
  16. Msty Go Playbooks — 잘된 실행을 반복 가능한 절차로 만들기
  17. Msty Go Tasks — 프롬프트, 알림, 감시, Playbook 예약하기
  18. Msty Go Shortcuts — 자주 쓰는 지시를 슬래시 명령으로 만들기
  19. Msty Go Rules — 이벤트에 따라 안내하고, 막고, 점검하기
  20. Msty Go 채널 — Discord, Telegram, WhatsApp, 모바일로 에이전트와 주고받기
  21. Msty Go Cloud Sync — 기기 간 암호화 동기화와 휴대전화 연결
  22. Msty Go General Settings — 앱 전체 기본값 정하기

이 글에서 다루는 것Go에서 클라우드·로컬 모델 제공업체를 연결하는 방법, 사용자 정의 모델과 메타데이터, 작업별 모델 배정(Model Assignments), 로컬 모델 검색과 설치를 설명합니다.

왜 가장 먼저 설정하는가

모델 제공업체(Provider)는 Go가 대화, 에이전트, Playbook, Task에서 모델을 부를 때 어디로 요청을 보낼지 정합니다. 이 부분이 불안정하면 그 위의 모든 기능이 흔들립니다. Setup 문서가 “나중의 실패 대부분은 제공업체 층이 불안정해서 생기는 증상”이라고 적은 이유입니다.

설정 위치는 Settings > Model Providers입니다.

세 가지 운영 전략

문서는 대부분의 팀이 다음 중 하나를 쓴다고 설명합니다.

전략 특징
제공업체 하나만 쓰기 단순합니다
주 제공업체 + 예비 제공업체 장애에 강합니다
로컬 제공업체 개인정보에 민감한 업무에 맞습니다

하나를 의도적으로 고르고 문서로 남겨 두라고 합니다. 정책 없이 섞어 쓰면 응답 지연, 결과 품질, 실패 양상이 들쭉날쭉해집니다.

제공업체마다 입력하는 항목

항목 설명
Type 제공업체 종류
Display name 화면에 표시할 이름
Base URL 요청을 보낼 주소
API key 필요한 경우에만
Model list behavior 모델 목록을 어떻게 다룰지

설정한 뒤에는 에이전트나 예약 자동화에 배정하기 전에, 실제 업무와 비슷한 프롬프트를 적어도 하나 보내 봅니다.

Type에서 고를 수 있는 제공업체의 전체 목록은 이 문서 페이지에 나열되어 있지 않습니다.

로컬과 클라우드

  • 클라우드 제공업체는 인증 정보와 원격 엔드포인트를 씁니다.
  • 로컬 제공업체는 내 컴퓨터의 서비스 엔드포인트를 씁니다.

문서의 지침은 두 가지입니다. 에이전트를 배정하기 전에 로컬 엔드포인트가 정상인지 확인하고, 중요한 작업은 예비 경로를 적어도 하나 시험해 둡니다.

둘의 차이는 통제와 편의의 교환입니다. 로컬은 개인정보 보호와 예측 가능성에 유리하고, 클라우드는 규모 확장과 모델 선택 폭에서 편합니다.

사용자 정의 모델과 메타데이터

관리형이 아닌 제공업체에서는 모델 항목을 손으로 추가할 수 있습니다. 이때 선택적으로 넣는 메타데이터가 두 가지 있습니다.

  • Context window tokens (맥락 창 크기)
  • Reserved output tokens (출력용으로 남겨 둘 토큰)

이 값을 넣어 두면 답이 중간에 잘리는 일이 줄고 경로 선택이 예측 가능해집니다. 답이 잘리거나 비용이 늘어난다면 메타데이터와 모델 선택부터 다시 보라는 것이 문서의 조언입니다.

관리형 모델 내려받기

관리형을 지원하는 로컬 제공업체는 설정을 저장한 뒤 앱 안에서 모델을 내려받는 버튼이 나타날 수 있습니다. 관리형이 무엇인지는 Managed Services에서 설명합니다.

Model Assignments — 작업별로 다른 모델 쓰기

Settings > Model Assignments에서 배경 작업마다 쓸 모델을 따로 정할 수 있습니다. 현재 배정할 수 있는 대상은 다음과 같습니다.

배정 대상 쓰이는 곳
Memory 기억 관련 처리. Memory Bank 참고
Context Scout 보내기 전 작업 공간 탐색. Context Scout 참고
Context Summary 맥락 요약
Conversation Titles 대화 제목 만들기
Side Replies (/btw) Side Chat의 답
Pulse Pulse 브리핑 작성

배경 작업에는 값싸고 빠른 모델을, 핵심 대화에는 성능이 좋은 모델을 쓰고 싶을 때 씁니다. 문서는 이것이 품질을 잃지 않고 비용 효율을 높이는 가장 쉬운 방법 가운데 하나라고 설명합니다.

대상별로 알아 둘 동작이 있습니다.

  • Pulse는 모델을 명시적으로 배정해야만 실행됩니다. 최근 작업을 읽고 브리핑을 쓰는 역할이기 때문입니다.
  • Context Scout는 배정된 제공업체를 쓸 수 없으면 지금 대화에서 쓰는 모델로 넘어갑니다.
  • Side Replies도 모델이 배정되어 있지 않으면 가능한 경우 대화 모델로 넘어갑니다.

Context Summary와 Conversation Titles의 세부 동작은 공식 문서에 설명이 없습니다.

로컬 모델 찾기와 설치

로컬 런타임용 제공업체 설정에는 검색·설치 흐름이 들어 있습니다.

런타임 찾는 방법
Ollama 카탈로그 검색, 또는 name:tag 형식으로 직접 입력해 설치
MLX Hugging Face의 author/model 형식으로 찾기
LLaMA.cpp Hugging Face의 GGUF 저장소와 파일 지정

잘못되었거나 호환되지 않는 입력에 대한 검사가 강화되었습니다. 문서의 예는 GGUF 런타임에서 GGUF가 아닌 파일을 고른 경우입니다.

문서는 검색과 설치를 운영 점검 단계로 다루라고 합니다. 넓게 쓰기 전에 모델의 정확한 이름, 형식 호환성, 기대한 성능을 확인합니다.

대화 중에 모델 바꾸기

최근 버전에서 대화 화면의 모델 목록과 전환 기능이 빨라졌습니다. 작업 중에 특정 모델에서 오류가 날 때 빠르게 다른 모델로 넘어가는 용도입니다. 버튼의 정확한 위치는 공식 문서에 설명이 없습니다.

문서의 실용 권고

  • 잘 시험된 기본 모델 하나로 시작합니다.
  • 전문 모델은 쓰임새가 분명할 때만 더합니다.
  • 제공업체나 기본 모델을 바꾼 뒤에는 중요한 에이전트를 다시 시험합니다.

기본값이 바뀌었을 때는 간단한 시험 프롬프트 하나가 아니라 실제 업무를 대표하는 작업 묶음을 다시 돌려 보라고 합니다.

문제가 생겼을 때

증상 먼저 볼 것
모델을 고를 수 없다 제공업체의 Base URL, API key, 로컬 서비스 접속 여부
답이 중간에 잘린다 모델 메타데이터(맥락 창, 출력 토큰)와 모델 선택
Pulse가 실행되지 않는다 Model Assignments에 Pulse 모델이 지정되었는지
로컬 모델 설치가 거부된다 런타임에 맞는 형식인지(예: GGUF 런타임에는 GGUF 파일)

참고한 문서