MiniMax Code Mini App의 자격증명 보호를 로컬 파일 격리로 해석하면 안 됩니다. 공식 보안 문서는 Mini App의 Node 코드가 PC에 로그인한 사용자 권한으로 실행되며, 그 사용자가 접근할 수 있는 파일을 읽고 쓰고 프로그램을 실행하거나 네트워크 요청을 할 수 있다고 설명합니다. 반복 업무용 화면을 만들 때는 연결 계정의 권한과 PC에서 실행되는 코드의 접근 범위를 따로 살펴야 합니다.
10월 22일 발표된 Mini App은 무엇인가
MiniMax는 2026년 10월 22일 MiniMax Code Mini App을 발표했습니다. 회사가 명시한 제공 범위는 macOS·Windows용 MiniMax Code 데스크톱 앱의 로컬 세션입니다. 화면과 Node.js 백엔드를 플러그인으로 묶고, 데이터를 가져오거나 결과를 저장하며 에이전트와 기능을 주고받는 구조입니다. 화면은 대화 옆에 표시하거나 별도 창으로 열 수 있다고 안내합니다.
한 번 생성한 시점의 자료만 담은 HTML 결과물과 비교하면, 계속 갱신할 데이터와 저장 기능을 앱의 백엔드에 둘 수 있다는 점이 변화입니다. 여기서 비교하는 HTML은 별도의 API·서버 연동이 없는 스냅샷입니다. 모든 웹페이지가 갱신이나 저장을 못 한다는 뜻은 아닙니다.
발표는 실행 환경, 자연어로 앱을 만드는 /miniapp-creator, 공식·커뮤니티 앱을 소개합니다. 한국 계정의 실제 이용 가능 여부, 최소 앱 버전, 플랜별 포함 범위와 한국 결제 비용은 이 발표와 아래 두 문서에서 확정하지 못했습니다. 기능 발표를 무료 제공이나 모든 기기의 지원으로 넓혀 읽지 마세요.
자격증명·포트·파일은 서로 다른 경계다
공식 Security model 문서는 호스트가 제공하는 API의 제한과 Node 프로세스의 권한을 구별합니다. 다음 표는 문서의 보호 범위와 그 설명만으로 확인할 수 없는 범위를 나눈 것입니다.
| 살펴볼 경계 | 공식 문서의 설명 | 사용자가 따로 확인할 것 |
|---|---|---|
| 연결 계정의 자격증명 | Host Connector가 승인한 계정을 사용하고 호스트 자격증명을 페이지·플러그인 코드에 전달하지 않는 구조 | 연결된 서비스와 계정, 허용한 읽기·쓰기 작업 |
| Mini App 서버 포트 | 127.0.0.1의 지정 포트와 호출자 인증으로 다른 프로세스·브라우저 탭의 접근을 제한 | 이 보호를 악성 플러그인 자체의 격리로 간주하지 않기 |
| 호스트의 Agent API | 명시한 권한으로 배경 세션 등을 사용. 자신이 만든 세션만 이어갈 수 있고 API로 기존 채팅 기록을 읽지 못함 | 호스트 API 제한과 Node가 직접 접근하는 로컬 자료의 범위를 분리 |
| Node 코드의 로컬 실행 | 로그인 사용자 권한으로 동작하며 운영체제 수준의 샌드박스는 사용하지 않음 | 실제 코드·의존성이 접근할 파일, 실행 프로그램, 외부 통신 대상 |
근거: MiniMax Agent Docs의 Security model, Mini App runtime·Host security boundaries·Limits of the Agent API·Known limitations. 확인일: 2026-10-23. 회사의 설계 설명을 대조한 표이며, 독립 침투 시험이나 차단 성능 측정 결과가 아닙니다.
특히 문서는 포트 인증이 다른 호출자의 접근을 막는 장치이고, 같은 프로세스의 악성 플러그인을 격리하지는 못한다고 명시합니다. 따라서 매니페스트에 선언된 Connector·Agent 권한만 읽고 로컬 파일 접근까지 제한됐다고 결론 내릴 수 없습니다. 배포자와 소스·의존성의 접근 범위를 함께 검토해야 하는 이유입니다.
업무 현황판을 만든다면 읽기·저장·수정을 나눈다
가상 설계 예: 팀의 주간 작업 현황판을 만든다고 가정하겠습니다. 외부 이슈 목록을 조회해 화면에 보여주기, 요약 CSV를 PC에 저장하기, 원본 이슈의 상태를 바꾸기는 서로 다른 작업입니다. ‘현황판을 만들어 달라’는 요청에 이 세 기능을 한꺼번에 포함시키기 전에 결과와 권한을 구체화하세요.
- 조회 경로를 먼저 확인합니다. 사용할 계정·프로젝트와 필요한 필드, 갱신 시점을 적습니다. 공식 제작 안내도 데이터 원본마다 읽기 전용 조회로 권한·필드·실제 응답을 확인하고 실패하면 중단하도록 설명합니다. 화면에 샘플 값이 있다는 사실만으로 연결 성공을 판단하지 않습니다.
- 저장은 별도 기능으로 정의합니다. 저장 폴더, 파일명, 덮어쓰기 여부, 보관할 필드를 정합니다. 요청서의 폴더 지정은 원하는 동작을 설명한 것이므로, 그 자체가 Node 코드의 파일 접근을 기술적으로 격리한다는 뜻은 아닙니다.
- 외부 수정의 대상을 정합니다. 상태 변경 같은 기능은 대상 항목·바뀔 값·확인 화면·실패 시 처리 방식을 명시합니다. 원본을 바꾸는 기능이 필요하지 않다면 조회·표시부터 범위를 정할 수 있습니다. 앱의 실제 코드와 연결 서비스 권한이 그 설계와 맞는지도 대조합니다.
- 남은 확인을 담당자에게 넘깁니다. 실제 설정이나 동작을 못 본 항목은 미확인으로 남깁니다. 통제별 근거·조치 기록 양식의 한 행에 대상·근거·판정·담당·완료 조건을 적으면, 무엇을 확인해야 배포 판단을 내릴 수 있는지 이어받기 쉽습니다.
이는 발표 기능을 실제 업무 요구사항으로 바꾸기 위해 제안한 설계 순서입니다. 특정 이슈 서비스와의 연동 성공이나 파일 접근 제한을 시험한 예제가 아닙니다.
제작 요청에 넣을 입력·출력 조건
다음은 위 현황판을 요청할 때 채워 넣을 빈 메모입니다. 복사한 뒤 실제 업무 범위를 적으세요. MiniMax의 필수 설정 파일이나 권한 정책 문법이 아닌 자체 요청 양식입니다.
업무 결과 / 이용자: 조회 원본 / 계정·프로젝트 / 필요한 필드: 갱신 조건 / 마지막 확인 시점 표시: 로컬 저장 위치 / 저장 필드 / 덮어쓰기 규칙: 외부 수정 대상 / 허용 작업 / 실행 전 확인: 실패·권한 부족·빈 응답을 표시할 방법: 접근 범위 검토 담당 / 실제 동작 확인 / 남은 항목:
앱의 publish와 인터넷 공개를 구별한다
공식 제작 안내에서 publish는 패키지를 검증하고 실행 서비스를 시작하거나 교체하는 동작입니다. 이어지는 open은 현재 대화에 앱을 여는 동작입니다. 이 설명만으로 동료에게 공유할 공개 웹사이트나 공동 사용 서비스가 자동 배포됐다고 판단할 수는 없습니다. 공동 이용이 목적이라면 인증·데이터 저장 위치·다중 사용자 운영 조건을 추가로 확인해야 합니다.
또 문서는 마켓플레이스에서 설치한 공식 앱을 로컬에서 직접 수정·재발행할 수 없고, 맞춤형으로 만들려면 새 pluginId로 복사본을 만들도록 안내합니다. 기존 앱의 화면 수정 요청과 새 패키지를 만드는 요청도 구별하세요.
원문 확인일: 2026-10-23. 10월 22일 출시 발표와 현재 제작·보안 문서를 함께 읽은 설명입니다. 한국 계정 제공·요금·앱별 호환 버전과 실제 업무 성능은 별도 확인이 필요합니다.