터미널 코딩 에이전트 비교: CLI에서 실제로 끝나는 작업 기준

터미널 코딩 에이전트 기준, 무엇이 달라졌나#

IDE 확장 기능이 아닌 터미널 사용에 초점을 맞춥니다. 아래는 2026-11-01 공식 문서에서 확인한 기능이며 실제 승인 화면이나 세션 복구를 같은 조건에서 시험한 결과는 아닙니다.

평가 기준: 환경·과제·채점표·제외 기준·한계#

OS, 터미널, 버전, 모델, 인증과 권한을 기록한 뒤 파일 수정과 명령 실행, 중단 후 재개, 비대화형 출력과 종료 코드를 살펴보세요. 이 페이지는 독립적인 동일 과제 시험을 수행하지 않았으며 채점표를 제시하지 않습니다.

이 표는 실행 기록의 수집 기준이며 현재 확보된 결과표가 아닙니다.

다음은 아직 수행하지 않은 재현 절차입니다. 합성 저장소·문서·로그를 쓰고 실제 자료는 쓰지 않거나 민감 정보를 제거하세요. 비밀값과 자격 증명을 없애고 공급자의 데이터 보관·학습 정책을 검토합니다. 격리 환경에서 외부 서비스 쓰기·발송·배포를 차단해 외부 부작용을 방지하고, 승인 범위는 최소화합니다.

1. 한글 파일명을 포함한 합성 저장소에 작은 수정 과제와 자동 테스트, 기대 결과를 준비하고 도구별로 같은 초기 복사본을 사용합니다.
2. OS·터미널·도구와 모델 버전·인증 방식·권한·예산을 기록합니다. 모델이나 지원 기능을 같게 맞출 수 없다면 차이를 밝히고 비교에서 제외할 항목을 정합니다.
3. 같은 한국어 요청으로 로컬 수정과 테스트를 요청한 뒤 안전한 지점에서 중단·재개를 시도합니다. 비대화형 실행을 지원하면 별도로 표준 출력·오류 출력·종료 코드를 기록합니다.
4. diff, 테스트 통과 여부와 승인 요청, 실패·중단, 비용을 사전 기준으로 기록하고 결과 공개 전 독립 검토합니다. 해당 기능이 없는 경우와 실행 실패는 구분합니다.

비교표: 8–12개 도구#

기능 설명은 공급자의 문서에 근거합니다. 나열하지 않은 기능이 없다는 뜻도 아닙니다.

자동화가 목적이라면 제품명보다 실행 명령과 검증할 출력을 나눠 비교하세요. 아래 명령은 공식 사용법의 예이며 이 페이지에서 실행한 transcript가 아닙니다.

CI에 넣기 전에는 쓰기를 허용할 파일과 명령을 제한하고 외부 서비스 발송·배포를 차단한 합성 저장소에서 확인하세요. 사람의 입력이 필요한 인증이나 승인이 남으면 비대화형 명령이 있다는 이유만으로 무인 실행을 보장할 수 없습니다.

분야별 최적 + 왜 미르가 전체 1위는 아닌가#

1. 사용하는 OS와 터미널에서 설치와 로그인 조건을 확인합니다.
2. 파일 수정, 셸 명령, 네트워크와 MCP 접근의 승인 범위를 확인합니다.
3. 동일한 저장소에서 작업을 중단하고 세션을 이어갈 수 있는지 시험합니다.
4. 자동화가 필요하면 비대화형 출력, 오류 출력과 종료 코드를 확인합니다.
5. 변경 diff와 테스트를 검토하고 모델 비용과 사용 한도를 기록합니다.

이 절차는 직접 비교하기 위한 안내입니다. 분야별 최적과 실제 성공률은 아직 측정하지 않았습니다.

미르 코드가 맞는 경우와 맞지 않는 경우#

Mirr Code의 한국어 터미널 문서, 세션 재개와 JSON 출력이 필요한지 확인하세요. 다른 모델 공급자나 IDE와 함께 쓰는 선택지가 중요하다면 해당 도구의 공식 조건도 살펴보세요. 문서상 명령이 있다는 사실만으로 운영 환경에서 작업이 성공한다고 보장할 수 없습니다.

월간 갱신 · 출처#

표의 공식 문서 확인일은 항목별로 다릅니다. Codex 인증과 Cline 인증 문서는 2026-11-02, Claude 권한·헤드리스 문서와 Mirr CLI 문서는 2026-11-03에 확인했고, 나머지는 기존 2026-11-01 기록입니다. 버전과 플랜에 따라 동작이 달라질 수 있으며 확인일은 실제 작업 검증일이 아닙니다.

아직 확인하지 못한 항목: 실제 권한 승인과 세션 복구 실행 기록, mirr -p --output-format json 실행 출력, 동일 과제의 종료 코드·테스트 결과와 독립 검토.

CLI가 있다는 것과 CLI에서 일이 끝나는 것#

터미널 코딩 에이전트 비교에서는 시작 명령 하나보다 완료까지 필요한 작업을 봐야 합니다. 로그인은 브라우저에서 하고 결과 검토는 편집기에서 할 수도 있습니다. 그런 흐름이 잘못된 것은 아니지만 모든 작업이 터미널에서 끝난다고 표현하면 실제 준비를 놓칠 수 있습니다. 아래는 터미널 중심 업무를 평가하는 제안이며 제품별 성공률이나 CI 실행 결과가 아닙니다.

자신의 과제를 시작, 조사, 수정, 검증과 결과 전달로 나눠 보세요. 각 단계에서 사람이 필요한지와 어떤 화면을 사용하는지 적습니다. 비대화형 명령이 있어도 시작 전에 대화형 로그인이 필요할 수 있고 수정 뒤 사람이 diff를 봐야 할 수 있습니다. 명령 존재와 무인 실행 가능성, 안전성은 각각 확인할 항목입니다. 현재 페이지의 기능 표는 이 구분의 출발점입니다.

후보를 고를 때는 터미널 사용이 주된 작업면인지 확인하고 IDE 확장만 있는 사례와 섞지 않는 편이 좋습니다. 위 표는 공식 문서의 터미널 경로를 제시하지만 나열하지 않은 기능이 없다는 뜻은 아닙니다. 현재 버전과 계정에서 필요한 경로가 가능한지 살펴보세요. 도구 이름만 같아도 버전이 다른 설치 문서를 혼용하지 않도록 주의해야 합니다.

설치와 인증을 별도 단계로 기록하기#

설치 성공은 실행 파일을 사용할 수 있는 상태이고 인증 성공은 승인된 계정으로 요청할 준비가 된 상태입니다. 모델 요청과 파일 수정, 테스트 실행은 그 뒤의 관찰입니다. 이 단계를 나누면 “설치가 됐으니 사용할 수 있다”는 오해를 줄일 수 있습니다. 실패가 나면 어느 단계에서 멈췄는지와 비밀값을 제거한 오류 문구를 남기세요.

인증 기록에는 실제 토큰 대신 로그인 경로와 계정 역할을 적습니다. Codex 인증 문서와 Cline 인증 문서는 같은 제품 안에서도 여러 로그인 경로가 있음을 보여 줍니다. 이 문서 확인은 실제 계정으로 로그인하거나 요청을 실행한 기록이 아닙니다. 경로마다 청구와 데이터 조건을 따로 확인하세요.

자동화를 계획한다면 작업 디렉터리와 필요한 자격 증명, 비밀값을 주입할 담당자를 정하세요. 이 글은 비밀값을 읽거나 새 계정을 만들도록 요구하지 않습니다. 기존 개인 세션을 다른 실행에 무단 재사용하지 않는 편이 좋습니다. 인증 정보가 없는 합성 환경에서 확인할 수 있는 명령 구조와 실제 모델 요청이 필요한 검증을 나누어 준비할 수 있습니다.

파일·셸·네트워크 권한을 나눠 보기#

터미널 에이전트의 권한을 셸 승인 하나로 설명하기는 어렵습니다. 파일을 읽는 일과 수정하는 일, 명령 실행과 네트워크 접근, MCP 도구 호출이 각각 어떤 범위에서 허용되는지 살펴보세요. 대화에서 금지한 행동과 실행 환경이 강제하는 제한도 다릅니다. 처음 시험할 때는 실제 계정과 고객 자료가 없는 합성 저장소를 사용하고 외부 쓰기를 제외하는 편이 좋습니다.

출처 확인(2026-11-03): Claude Code 권한 문서는 권한 규칙과 여러 모드를 설명합니다. Mirr 권한 문서는 표시된 파일과 명령을 확인하고 의도와 다르면 거절할 수 있다고 안내합니다. 두 문서의 설명을 실제 승인 횟수와 같은 수준의 격리로 읽지는 마세요. 현재 설정에서 어떤 요청이 나오는지는 별도 실행이 필요합니다.

비교할 합성 과제에서는 수정할 파일과 허용 명령을 정합니다. 테스트를 실행해도 된다는 요청이 의존성 설치나 배포까지 포함하는지 모호하지 않게 적으세요. 검사가 외부 서비스에 연결한다면 로컬 검사와 별도 단계로 나눕니다. 준비되지 않은 환경을 해결하려고 권한을 계속 넓히는 대신 미실행 항목과 필요한 담당자를 남기는 편이 정확합니다.

승인 횟수는 그 자체로 품질 점수가 아닙니다. 필요한 위험을 보여 준 승인과 이미 허용한 안전한 검사를 반복해서 묻는 승인을 나눠 볼 수 있습니다. 요청이 적어도 범위가 넓어졌다면 좋은 결과라고 할 수 없습니다. 거절한 뒤 작업을 어떻게 이어 갔는지와 원래 조건을 보존했는지도 기록하면 비교에 도움이 됩니다.

세션 재개와 파일 복구를 분리해서 시험하기#

세션을 이어가는 기능은 이전 대화와 작업 맥락을 다시 불러오는 경로로 살펴볼 수 있습니다. 파일 복구는 이미 생긴 변경을 되돌리는 문제입니다. 대화를 다시 열었다고 파일이 이전 상태가 되거나 외부 변경이 취소되는 것은 아닙니다. 이 페이지는 각 도구의 복구 범위를 같은 조건에서 시험하지 않았으며 명령 이름으로 동일 동작을 보장하지 않습니다.

출처 확인(2026-11-03): Mirr CLI 문서는 --continue를 이전 대화 이어가기, --resume을 저장된 대화를 골라 이어가기로 구분합니다. Claude 비대화형 문서는 --continue로 최근 대화, --resume에 세션 ID를 주어 특정 대화를 선택하는 경로를 설명합니다. Codex 비대화형 문서는 codex exec resume와 --last 또는 세션 ID 경로를 제시합니다. 명령의 입력 방식이 같지는 않습니다.

가상 작업 A와 B를 번갈아 수행하는 사람은 “최근 것”보다 명시적인 대화 선택이 필요할 수 있습니다. A의 조사 뒤 B를 열었다면 무조건 최근 대화를 이어 가는 안은 A로 돌아간다는 목적과 다릅니다. 이 경우 후보를 고를 질문은 재개 기능의 유무가 아니라 여러 대화 중 원하는 것을 어떻게 지정하는가입니다. 각 명령은 문서에서 읽은 미실행 예이며 실제 세션을 열거나 상태를 변경하지 않았습니다.

복구 계획에는 채택할 변경과 버릴 변경, 외부 서비스에서 별도로 처리할 작업을 적습니다. 처음부터 사용자 작업이 없는 합성 저장소를 쓰면 원래 변경을 잘못 지우는 위험을 줄일 수 있습니다. 실제 저장소에서는 다른 사람이 만든 변경을 임의로 되돌리지 마세요. 자동 복구 명령이 있다는 이유로 기존 작업의 분류와 백업을 생략하면 안 됩니다.

비대화형 출력의 네 가지 확인#

비대화형 명령을 비교할 때는 표준 출력, 오류 출력, 종료 코드와 결과 파일을 함께 봅니다. JSON이 출력됐다는 사실만으로 작업이 성공했다고 판단하지 않습니다. 모델의 설명은 성공처럼 보여도 테스트가 실패했거나 파일을 만들지 못했을 수 있습니다. 반대로 경고 문구가 있어도 요구한 결과를 만들었는지는 별도로 확인할 수 있습니다.

현재 공식 설명에서 출력의 중요한 차이는 JSON 한 덩어리와 JSON Lines 이벤트 스트림입니다. Claude의 --output-format json은 결과·세션 메타데이터를 담는 구조화 출력이고 stream-json은 줄 단위 스트림입니다. Codex의 codex exec --json은 실행 중 이벤트를 stdout의 JSONL로 보냅니다. 따라서 “JSON 지원”이라는 표의 한 칸만 보고 같은 소비 프로그램을 붙일 수는 없습니다. Mirr 문서는 JSON 선택을 안내하지만 이 글이 그 실제 필드 계약을 검증한 것은 아닙니다.

Codex의 일반 exec 문서는 스크립트·리다이렉션 흐름에서 진행을 stderr에, 최종 메시지를 stdout에 두는 예를 설명합니다. 터미널에 직접 표시할 때와 같은 계약이라고 넓히지는 않습니다. Claude 문서는 잘못된 플래그는 시작 전 stderr에 보고하고 실행 중 인증 같은 실패는 stdout 결과에 나타날 수 있다고 설명합니다. “stderr에 내용이 있으면 모두 실패” 또는 “stdout이면 모두 성공” 같은 공통 규칙을 만들기 어려운 구체적인 이유입니다. 이 차이는 2026-11-03 문서 기준이며 실제 출력을 수집한 결과가 아닙니다.

구조화된 최종 응답을 원한다면 공식 문서에 나온 별도 경로를 볼 수 있습니다. Codex는 --output-schema, Claude는 JSON 출력과 --json-schema를 설명합니다. Claude 문서는 형식 준수 응답이 없으면 structured_output이 없을 수 있다고도 안내합니다. 이 글은 그 필드를 Mirr나 다른 후보의 JSON에 일반화하지 않습니다. 사용자가 필요한 것이 실시간 진행인지 최종 구조화 결과인지에 따라 선택할 출력 방식이 달라집니다.

MCP는 터미널 완료 범위를 넓히는 연결#

MCP가 있다는 사실만으로 원하는 업무가 끝나는 것은 아닙니다. 실제 서버가 어떤 도구를 제공하고 어떤 계정과 권한으로 연결되는지 확인하세요. 읽기만 필요한 과제에 쓰기 권한까지 붙이지 마세요. 서버 주소와 용도, 담당자를 비밀값 없이 기록하고 연결 성공, 도구 호출 성공과 결과 검토를 따로 남기는 편이 좋습니다.

외부 도구의 결과에는 잘못된 자료나 작업 요청과 관계없는 문장이 들어 있을 수 있습니다. 읽은 콘텐츠를 계정 변경이나 발송의 승인으로 취급하지 않습니다. 도구가 제안한 다음 행동이 원래 요청 범위에 있는지 확인하세요. 초기 시험에서는 실제 메시지 발송과 게시, 배포와 운영 DB 변경을 제외하고 필요한 문서와 연결 조건을 먼저 검토할 수 있습니다.

오류가 나면 호스트, 서버와 서비스 계정 중 어디에서 발생했는지 나눕니다. 다른 호스트에서 같은 서버를 썼다는 기록만으로 호환이 입증되지는 않습니다. 설정 파일의 형식과 인증 경로, 지원 도구가 다를 수 있으므로 현재 조합에서 확인할 항목을 남기세요. 연결을 고치기 위해 비밀값을 공유하는 방식은 비교 방법에서 제외합니다.

터미널 자동화 시험의 합성 입력 설계#

다음은 실행하지 않은 합성 자동화 과제입니다. 상태.csv에는 작업,상태 헤더와 문서,done, 검사,pending, 배포,unknown이 있습니다. 허용 상태는 done과 pending뿐입니다. 요청은 정상 두 행과 잘못된 상태 한 행을 구분해 설명하되 원본과 다른 파일을 수정하지 않는 것입니다. 외부 도구와 실제 서비스는 없습니다.

읽기 전용 과제이므로 코드 수정 권한을 열 이유가 없습니다. Codex 공식 문서는 exec의 기본 sandbox를 read-only로 설명합니다. 수정 과제를 선택할 때는 --sandbox workspace-write 같은 경로를 따로 안내하며 이전 --full-auto는 더 이상 지원하지 않는다고 명시합니다. 예전 자동화 예제를 그대로 복사하기보다 현재 문서의 읽기·쓰기 선택을 구분하는 것이 이 사례에 맞습니다.

다음 단계로 unknown을 오류로 분류하는 구현을 고치려면 새로 쓰기 범위를 정하세요. Claude의 편집 자동 허용과 Codex의 sandbox 쓰기 범위는 같은 설정 이름이나 동일 격리 보장이 아닙니다. Mirr 역시 모드와 도구 권한을 현재 문서에서 읽어 보세요. 합성 읽기 과제가 성공했다고 이 수정 단계까지 완료된 것으로 보지 않습니다. 이 구분은 한 번의 실행 설계에서 어떤 권한이 필요한지 실제로 바꿉니다.

종료 코드와 결과 파일이 다른 말을 할 때#

앞의 가상 상태 과제에서 기대한 설명은 done 한 행, pending 한 행과 unknown 오류 한 행입니다. 프로세스가 정상 종료했어도 unknown을 정상 목록에 넣었다면 과제는 틀렸습니다. 반대로 설명이 맞더라도 원본 파일을 고쳤다면 읽기 전용 요구를 어겼습니다. 출력 형식과 실제 업무 조건을 따로 보게 하는 사례입니다.

실시간 진행을 소비하는 가상 프로그램은 Codex JSONL의 중간 이벤트와 최종 완료·실패 상태를 구분하세요. 최종 결과만 필요한 프로그램이라면 그에 맞는 출력·파일 옵션을 선택할 수 있습니다. 여기에는 실제 종료 코드나 스키마를 꾸민 transcript를 넣지 않았습니다. 한 도구의 이벤트 이름을 다른 도구에 그대로 적용하지 않고 실제로 선택한 문서 계약을 따라야 합니다.

CI 도입 전에 정할 책임#

Claude 비대화형 문서는 -p가 대화형 작업 공간 신뢰 확인을 보여 주지 않으며 기본 자동 발견으로 저장소의 hook과 MCP를 읽을 수 있다고 설명합니다. 따라서 처음 보는 합성 저장소에서도 프로그램 실행 환경을 어떻게 시작할지 결정하세요. --bare는 자동 발견을 줄이는 다른 경로이지만 구독 OAuth도 사용하지 않는 조건이 있으므로 단순한 성능 플래그처럼 붙이지 않습니다. 현재 문서가 설명하는 두 시작 경로 중 어느 것이 인증과 필요한 지침에 맞는지 고르는 문제입니다. Claude 문서는 --dangerously-skip-permissions를 승인 프롬프트를 건너뛰는 경로로도 설명합니다 (2026-11-03 확인). 이는 문서상 설명입니다.

무인 실행에는 작업을 시작할 담당자와 실패를 확인할 담당자가 필요합니다. 결과를 어디에 보관하고 어떤 실패를 사람에게 알릴지 정하세요. 인증이 만료되거나 모델 한도에 도달했을 때 계속 재시도할지와 멈출지도 구분합니다. 비용을 많이 쓸 수 있다는 허가가 있더라도 업무 범위와 데이터 권한이 자동으로 넓어지는 것은 아닙니다.

비밀값은 승인된 환경 관리 방식으로 다루고 로그에서 제외합니다. 사람이 쓰던 로컬 인증 파일을 무단으로 복사해 자동화 환경을 만드는 방식은 피하세요. 초기에는 합성 자료와 외부 쓰기가 차단된 환경에서 출력과 파일 처리를 확인할 수 있습니다. 실제 CI 자격 증명과 서비스 연결을 확인하지 않았다면 그 결과를 운영 CI 검증으로 볼 수 없습니다.

실행한 코드가 저장소의 다른 스크립트를 부를 수 있다는 점도 검토하세요. 허용 명령의 이름만 보고 네트워크와 파일 영향이 제한된다고 가정하지 않습니다. 대화에 쓴 지침과 환경의 제한을 각각 기록하고 필요한 보호를 담당자가 확인하게 합니다. 자동화 준비가 부족하면 미실행 항목으로 남기고 지원 가능한 로컬 과제의 결과는 따로 보존할 수 있습니다.

결과를 비교할 때 유지할 구분#

이 표의 한계는 실제 권한·재개·JSON 출력과 같은 과제 비교가 아직 없다는 것입니다. 실제 CI와 사람의 검토도 수행한 것이 아닙니다. 명령 예시는 모두 미실행이며, 비밀값과 실제 고객 자료를 제외하고 외부 쓰기를 차단한 합성 환경을 전제로 합니다. 이 한계는 아래 결정문에서 되풀이하지 않고, 문서상 차이가 선택을 바꾸는 지점에 집중합니다.

CLI 후보를 좁히는 실제 결정문#

가상 결정문입니다. 실제 실행 판정이 아니라 조건을 채운 예시로, 팀은 상태 CSV를 읽기만 하고, 진행 이벤트보다 최종 설명 하나를 원하며, 실제 배포와 계정 변경은 허용하지 않습니다. 이 경우에는 첫 과제부터 쓰기 권한이나 외부 MCP를 열 필요가 없습니다. 한국어 CLI 문서와 최종 JSON을 살펴보려면 Mirr를 후보로 둘 수 있고, 문서상 read-only 기본과 이벤트 출력을 활용하려면 Codex 경로를 검토할 수 있습니다.

반대로 팀이 기존 Claude 권한 규칙과 출력 처리를 이미 운영한다면 -p를 새 도구로 교체하기 전에 현재 JSON/stream-json과 허용 도구 조건을 정리하는 안이 있습니다. 같은 “비대화형 지원”이라도 기존 소비 프로그램이 한 개의 최종 객체를 기대하는지 줄 단위 이벤트를 기대하는지에 따라 이전 작업이 달라집니다. 이 사례의 결론은 어떤 제품이 이겼다는 것이 아니라 필요한 출력 계약을 유지할 후보를 좁혔다는 것입니다.

자동화 결과를 다시 실행할 때는 이전 출력 파일이 남아 있는지도 확인할 항목입니다. 새 실행이 실패했는데 과거 파일을 읽어 성공으로 판단하지 않도록 시작 상태와 결과의 출처를 구분하세요. 합성 시험에서는 결과를 저장할 위치와 채택할 조건을 미리 정할 수 있습니다. 실제 파일을 지우거나 덮어쓰는 행동은 그 범위를 승인받은 상태에서만 계획해야 합니다.

부분 결과를 보존한다면 완성 파일과 다른 상태로 표시하세요. 사람이 읽기 전에 다음 단계가 자동으로 소비하지 않도록 결과 계약을 정하는 것도 검토할 수 있습니다.

실행 기록을 재사용할 때의 범위#

같은 가상 상태 과제를 다음 단계에서 다시 읽는다면 원래 입력이 바뀌지 않았다는 전제를 재사용할 수 있습니다. 그러나 구현을 수정한 새 단계에서는 이전 설명의 정확성을 그대로 결과로 삼을 수 없습니다. 사용자 조건이 읽기에서 쓰기로 바뀌면 권한 선택도 달라집니다. 이처럼 재사용할 수 있는 것은 과제의 기준이고 새 단계가 요구하는 실제 결과는 별도입니다.

제품 문서에서도 재개와 저장을 다르게 선택할 수 있습니다. Codex는 세션 rollout 파일을 남기지 않는 --ephemeral 경로를 설명하고, Claude의 비대화형 문서는 최근 대화와 특정 ID를 이어가는 경로를 구분합니다. Mirr 문서는 저장된 대화를 골라 이어가는 명령을 제시합니다. 기록을 남기지 않을 요구와 다음 실행에서 이어갈 요구를 동시에 당연하게 요구하기보다 업무 목적에 맞는 저장·재개 경로를 고르는 것이 필요합니다.

또한 Claude 문서는 --bare가 자동 발견하는 hooks·skills·plugins·MCP·기억·CLAUDE.md 등을 건너뛰는 대신 구독 OAuth 로그인도 읽지 않는 경로라고 설명합니다(2026-11-03 확인). 일상 대화형 환경을 그대로 자동화에 재사용하려는 팀과 자동 발견을 줄이려는 팀의 선택이 달라지는 구체적인 지점입니다. 이 설정을 모든 클라이언트의 공통 bare 모드로 일반화하거나 실제 계정 설정을 바꾼 것으로 표현하지 않습니다.

자동화 실행 기록 양식#

비대화형 실행의 결과를 나중에 비교하려면 실행마다 같은 칸에 같은 증거를 남기세요. 아래 양식은 이 페이지의 설명을 바탕으로 한 빈 양식이며 값은 채우지 않았습니다.

판정 칸은 종료 코드만으로 채우지 않습니다. 파일 결과와 테스트 출력이 함께 맞아야 성공으로 적을 수 있습니다.

수정·보완 기록#

출처 범위: 설치 가능 여부, 승인, 세션 재개, 비대화형 출력은 공식 문서 항목으로만 적었습니다. 명령 문서는 실제 실행 로그가 아니며, JSON 출력과 종료 코드의 수집은 이 페이지에 없습니다.

관련#

• Mirr Code 터미널 명령 안내