이 페이지는 AI 코딩 에이전트와 그 주변 도구를 다룬 글 일곱 편을 읽는 순서로 묶은 안내입니다. 순서는 세 덩어리입니다. 먼저 에이전트 CLI를 사람 없이 돌릴 때 멈추거나 빈손으로 끝나는 경우, 다음으로 에이전트에 도구와 파일을 붙이는 MCP 서버, 마지막으로 외부 저장소의 스킬과 상태 정보를 읽어 들이는 단계입니다. 일곱 편 모두 Debian 13에서 오류를 먼저 재현하고 고친 뒤의 출력을 근거로 썼기 때문에, 각 글의 판단 기준이 종료 코드와 실제로 생긴 파일이라는 점이 같습니다.
마지막 업데이트: 2026년 10월 17일
에이전트 CLI를 예약 작업으로 돌릴 때
첫 글은 codex exec Reading additional input from stdin 멈춤 해결입니다. codex exec는 표준 입력이 열려 있으면 입력의 끝을 기다리고, 그 상태로 시간 상한에 걸리자 codex_exit=124가 남았습니다. < /dev/null로 입력을 닫고 -o로 답변을 저장하자 codex_exit=0과 out.md가 남았고, 없는 작업 경로는 os error 2로 끝나서 존재하는 -C 경로로 바꿨습니다. 저장소 밖에서 돌릴 때의 trusted directory 메시지에는 --skip-git-repo-check를 해당 실행에만 붙였습니다. 프롬프트를 고치기 전에 입력과 작업 위치부터 고정해야 한다는 것이 이 글의 결론입니다.
두 번째 글 grok -p가 0으로 끝나도 파일이 없을 때: Grok CLI 승인 옵션은 반대 방향의 문제를 봅니다. 실행은 종료 코드 0으로 끝났는데 다음 역할이 읽을 brief.md가 없었습니다. --always-approve로는 brief.md와 draft.md가 생겼고, --permission-mode acceptEdits만 준 실행에서는 파일이 생기지 않았습니다. 정기 작업에 고른 조합은 --allow Write와 역할별 지시문 절대 경로, 그리고 결과 파일이 비어 있으면 실패로 처리하는 단계별 검사입니다. 첫 글이 멈춤을, 이 글이 거짓 성공을 다루므로 둘을 이어 읽으면 예약 작업의 성공 조건을 종료 코드와 산출물 두 가지로 세우게 됩니다.
두 글을 나란히 두면 예약 작업에 넣을 점검 항목도 겹칩니다. codex exec 글은 실행마다 답변과 로그를 보관하고 요청한 작업 파일을 읽어 결과를 확인하는 절차를 운영 스크립트에 넣으라고 적었습니다. Grok CLI 글은 다시 돌리기 전에 기존 brief.md와 draft.md를 구별할 수 있게 작업 폴더를 준비해, 오래된 파일 때문에 성공으로 처리되는 일을 막으라고 적었고, 다음 단계는 이번 실행의 결과가 준비된 뒤에만 시작합니다.
에이전트가 만든 내용을 납품 형식으로 내보내야 한다면 CLI-Anything LibreOffice로 HWP 내보내기? Unknown preset hwp로 넘어갑니다. CLI-Anything의 LibreOffice 하네스에 -p hwp를 주면 Unknown preset과 종료 코드 1로 끝나고 파일은 생기지 않았습니다. PDF는 pdftotext로, DOCX는 document.xml로 한글 제목과 문단이 남았는지 대조했고, PATH가 비면 LibreOffice is not installed, 같은 경로를 다시 쓰면 Output file exists와 --overwrite 안내가 나왔습니다.
MCP 서버로 도구와 파일을 연결할 때
MCP SDK 2.3.0 FastMCP ModuleNotFoundError와 MCPServer 전환은 mcp 2.3.0에서 from mcp.server.fastmcp import FastMCP가 첫 임포트에서 ModuleNotFoundError로 멈춘 경우입니다. MCPServer로 옮긴 서버를 stdio 클라이언트로 띄워 add와 count_hangul을 호출했고, 당장 고칠 수 없는 v1 서비스는 버전을 고정하는 길과 헬스체크·배포 설정이 같이 바뀌어야 하는 부분을 함께 비교했습니다. 도구 서버를 처음 세운다면 이 글이 먼저입니다.
서버가 뜬 다음에는 무엇을 열어 줄지가 남습니다. MCP filesystem Access denied: 허용 폴더 밖 읽기는 막힙니다에서는 @modelcontextprotocol/server-filesystem 1.0.0에 허용 폴더 하나를 주고 read_text_file을 불러, 폴더 밖 경로가 Access denied – path outside allowed directories로 거부되는 것을 확인했습니다. 심볼릭 링크 대상 검사, Windows 형태 경로, 클라이언트의 Roots가 명령줄 목록을 대신하는 경우도 같은 패키지로 비교했습니다. 도구 목록 14개에 write_file, edit_file, move_file이 들어 있으므로, 읽기 오류 하나를 없애려고 상위 폴더를 넓게 여는 대신 좁은 전용 폴더만 허용하는 구성을 글에서 먼저 권합니다.
외부 저장소의 스킬과 상태를 읽어 들일 때
superpowers SKILL.md Not Found, depth 1 클론으로 스킬 15개 읽기는 obra/superpowers의 저장소 API 응답에 skills 키가 없고 skills/SKILL.md 요청이 Not Found로 끝난 데서 출발합니다. contents API로는 디렉터리 15개를, depth 1 클론으로는 SKILL.md 15개와 보조 파일, plugin.json의 7.0.0까지 읽었습니다. 저장소 식별만 필요하면 API 한 번, 디렉터리 이름이면 contents API, 본문과 구조 검사까지 필요하면 클론이라는 식으로 질문마다 조회 방법이 달라집니다.
스킬이나 도구를 의존성으로 들이기 전에 저장소가 관리되고 있는지 보고 싶다면 GitHub API open_issues_count는 PR까지 셉니다를 함께 읽습니다. User-Agent 없는 요청은 GitHub가 거절했고, 저장소 객체의 open_issues_count는 열린 풀 리퀘스트까지 센 값이라 PR 적체로 읽으면 다른 열과 맞지 않았습니다. 푸시 여부는 저장소 객체 한 번으로, 적체와 머지 시각은 검토 대상에만 풀 리퀘스트 조회를 더하는 구성으로 정리했습니다.
지금 하려는 일에 따라 들어갈 글
cron이나 스크립트로 에이전트를 돌리는데 로그가 멈춘다면 codex exec 글을, 정상 종료인데 결과 파일이 없다면 Grok CLI 글을 엽니다. 결과를 PDF나 Word로 넘겨야 하면 CLI-Anything 글이, 에이전트에 도구 서버를 붙이려면 MCP SDK 글과 filesystem 경로 제한 글을 그 순서로 읽는 흐름이 맞습니다. 외부 스킬을 가져오려면 superpowers 글을, 그 저장소를 의존성으로 들일지 판단하려면 GitHub API 글을 이어서 보십시오.
각 글의 버전, 요금, 한도 정보는 글마다 적힌 확인 기준일 시점의 내용입니다. 사용 전에 공식 문서를 다시 확인하세요.