PTY REPL 멈춤: 띄운 지 1분 안에 write(2)에서 막힌 세션, 확인 순서와 우회법

PTY 기반 에이전트 세션에서 브라우저 자동화 CLI의 aside repl을 장기 실행한 뒤 응답이 끊긴다면, REPL을 더 만지기 전에 출력 경로부터 확인해야 한다. 2026년 10월 12~13일 운영 기록에는 REPL을 띄운 지 1분 안에 세션이 세 번 멈췄고, 메인 스레드가 write(2)에서 기다렸다고 남아 있다. 우회는 장기 REPL을 메인 세션 PTY에서 빼고 단발 실행이나 PTY 밖 FIFO 입력으로 돌리는 것이고, 커널 수준의 원인은 증명하지 못했다.

살아 있는 프로세스가 답하지 않았다

터미널 화면과 텔레그램 응답이 함께 멈췄다. 운영 메모에는 세 번 모두 메인 세션에서 REPL을 띄운 뒤 1분 안에 같은 정지가 나타났다고 적혀 있다. 한 번의 긴 작업이 아니라, 같은 실행 방식 뒤에 반복된 정지였다.

이 세션은 감시기(supervisor)가 띄운 PTY 안에서 돈다. 감시기가 PTY 출력을 계속 읽어 pty.log에 남겨야 세션이 다음 출력을 쓸 수 있다.

그 pty.log가 더 이상 진행하지 않았다. sample로 본 메인 스레드는 쓰기 대기 상태였고, 감시기 쪽 PTY에는 읽을 출력이 없었다. REPL을 종료해도 응답이 돌아오지 않아 세션을 재시작해야 했다.

이 세 가지는 서로 다른 관찰이다. 로그 정지는 출력이 진행하지 않는다는 신호이고, 스택은 어느 호출에서 기다리는지를 보여 준다. REPL 종료 뒤에도 풀리지 않았다는 사실은 자식 프로세스 하나를 끄는 것으로 복구되지 않았다는 뜻이다.

처음에는 감시기를 잘못 의심했다

이틀 동안 정지는 네 번이었다. 그중 세 번이 aside repl을 띄운 지 1분 안에 일어났고, 처음에는 이 연관을 보지 못했다.

첫 가설은 감시기가 빈 읽기를 한 번 만나면 출력 감시를 끊는다는 것이었다. 빈 읽기 뒤에도 감시를 다시 걸고, 그때마다 pty_eof 기록을 남기도록 고쳤다. 다음 정지 때 이 기록은 한 번도 남지 않았다.

두 번째 가설은 kqueue가 "읽을 출력이 있다"는 알림을 놓친다는 것이었다. 알림이 없어도 1초마다 출력을 직접 비우도록 바꿨다. 그래도 세션은 다시 멈췄고, 그때 감시기 쪽에는 읽을 출력이 없었다.

두 수정은 효과가 없어 모두 되돌렸다. 남은 것은 REPL을 띄운 시각과 정지 시각이 세 번 맞물렸다는 패턴이었다. 마지막 정지는 REPL을 띄우고 11초 뒤였다.

메인 프로세스가 정확히 어느 대상에 쓰다가 막혔는지는 관리자 권한 없이 확인하지 못했다. 그래서 운영 규칙만 먼저 바꿨다. 메인 세션의 백그라운드 PTY에 REPL을 띄우고 bash_input으로 스크립트를 보내는 방식을 중단했다.

최소 재현은 명령보다 연결 순서다

당시 실행 순서를 줄이면 다음과 같다. 실제 운영 세션이 아니라 재시작할 수 있는 별도 세션에서 확인할 절차다. 이 순서가 모든 환경에서 반드시 멈춤을 만든다는 뜻은 아니다.

  1. PTY 기반 하네스에서 bash의 run_in_background: true로 aside repl을 실행한다.
  2. 반환된 bash_id에 bash_input으로 REPL 입력을 보낸다.
  3. 세션 응답, 감시기의 출력 로그, 메인 프로세스의 스택을 함께 확인한다.

REPL에 보낼 입력은 원래 작업의 실행 조건을 보존해야 한다. 당시 스크립트 전문이 없는 상태에서 새 입력을 정답처럼 붙일 수는 없다. 위 절차는 문제의 연결 형태를 재구성한 것이고, 독립 실행 가능한 커널 버그 재현 코드는 아니다.

어떻게 감지할까

텔레그램이 답하지 않을 때는 브리지의 requests에 새 요청이 쌓이는데 대응하는 state가 생기지 않는지 본다. 그다음 감시기의 pty.log가 진행하는지 확인한다. 둘을 같이 보면 요청이 들어오지 않은 상황과, 들어온 요청을 처리하지 못하는 상황을 나눌 수 있다.

이 사례에서는 메인 프로세스의 sample 결과도 판단에 들어갔다. macOS에서는 sample <PID> 3 -file /tmp/stall-sample.txt로 3초 스택을 파일로 남긴다. 확인할 항목은 메인 스레드가 write에서 대기하는지, 감시기 쪽에 읽을 출력이 있는지, REPL을 띄운 시각과 로그 정지가 맞물리는지다. 셋 중 하나만으로 원인을 확정하지 않는다.

진단 기록에는 실행 순서와 정지 시각을 함께 남기는 편이 낫다. 재시작 뒤 화면이 움직인다는 결과만 남기면, 다음 장애와 같은 조건인지 비교할 근거가 줄어든다. 실제 복구는 감시기의 재시작 절차를 따른다.

우회는 오래 사는 REPL을 분리하는 것이다

바꾼 운영 규칙은 메인 세션 안에 장기 REPL을 두지 않는 것이다. 한 번에 끝나는 aside 명령을 쓰거나, REPL이 필요하면 PTY 밖에서 FIFO로 입력을 주고 출력을 로그 파일로 분리하는 기존 방식을 쓴다. 단순히 다른 에이전트에게 같은 PTY 실행을 넘기는 것으로 끝내지 않는다.

단발 실행에서는 stdin을 닫고 종료 기한을 둔 형태로 작업을 나눌 수 있다. 아래는 입력 전달과 제한 시간 설정의 예시다. macOS에는 timeout이 기본으로 없어서 Homebrew coreutils의 gtimeout을 쓴다. 해당 aside 버전이 스크립트 인자를 받는 환경을 전제로 한다.

gtimeout 60s aside repl "console.log('probe')" </dev/null

60초는 예시 값이다. 실제 작업은 자신의 CLI 사용법과 완료 조건에 맞춰 한 번 실행하고 끝나는 단위로 바꾼다.

하네스의 bash에 있는 timeout과 셸의 gtimeout(timeout) 명령도 구분해야 한다. 로컬 터미널 도구 문서상 백그라운드 세션은 bash의 timeout으로 종료되지 않는다. run_in_background: true에 숫자만 넣었다고 장기 REPL의 수명이 제한된 것으로 보면 안 된다.

stdin을 닫고 기한을 두는 조치는 입력 대기와 실행 시간을 다루는 방법이다. 이미 막힌 메인 세션을 풀어 준다는 보장은 없다. 실제 기록에서도 REPL 종료만으로 복구되지 않았으므로, 우회 실행과 장애 복구를 다른 단계로 둔다.

결론: 멈춘 위치와 근본 원인을 구분한다

세 번의 반복과 쓰기 대기는 실행 방식을 바꿀 근거가 됐다. 하지만 PTY 버퍼, 터미널 상태, 커널의 어떤 경로가 원인인지 증명한 결과는 없다. 여기서 말할 수 있는 범위는 이 하네스의 PTY 안에서 장기 REPL을 돌린 뒤 정지가 반복됐다는 것까지다.

결국 기준은 그럴듯한 원인 이름이 아니라 다시 확인할 수 있는 증거다. 같은 증상이 보이면 요청 상태와 출력 로그, 메인 스레드의 대기를 먼저 남기고, 장기 REPL을 단발 실행이나 PTY 밖 입력 경로로 분리한다.

다음 글

댓글

댓글 쓰기

이 블로그의 인기 게시물

AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

이미지
AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...
자세한 내용 보기

M4 Max 128GB 로컬 LLM 4종 속도 비교 — 실측 기록과 한계

이미지
M4 Max 128GB에서 로컬 LLM은 얼마나 빠를까? 이 글의 과거 표에서는 gemma4:latest가 88 tok/s로 가장 높고, gemma4:26b는 85 tok/s다. gpt-oss:120b 47 tok/s, qwen3.6:35b-a3b 25 tok/s가 뒤를 잇는다. 처리량 표이지 정답률이나 코딩 품질 순위가 아니다. 작성자: 닥터조지. 2026년 4월 게시 당시 측정 기록 / 편집 보완: 2026-09-23. 기존 수치는 그대로 보존했고 이번에 모델을 다시 실행하지 않았다. 초판 제목의 llama3.3 표기와 “26B가 가장 빠르다”는 도입은 표와 일치하지 않아 바로잡았다. 원문의 장비·런타임·모델 표기는 당시 기록이다. 표의 qwen3.6:35b-a3b 는 원문에서 사용한 축약 표기이며, Q8과 qwen3.6:35b-a3b-q8_0 표기는 당시 본문 기록에서 가져왔다. 모델 파일이나 digest를 이번에 확인한 것은 아니다. 원 프롬프트 전문, 모델 digest, 반복 횟수와 개별 원시 응답이 이 글에 없어 표의 숫자를 그대로 재현했다고 확인할 수는 없다. 특히 latest 는 고정 버전 식별자가 아니다. 아래는 M4 Max 128GB 한 대에서 기록한 네 모델의 처리량이다. 모델 구조, 양자화, 크기가 동시에 다르므로 어느 한 요인만의 효과를 분리한 실험으로 읽으면 안 된다. 모델 크기만으로 속도를 예측하기 어려운 이유 원문은 gpt-oss:120b 를 총 117B, 활성 약 5.1B의 MoE로 기록했다. 활성 파라미터 수만으로 실제 생성 속도를 계산할 수는 없다. 모델 구조에 따른 메모리 접근 차이는 가능한 설명이지만, 이 표는 메모리 대역폭이나 접근 패턴을 직접 계측한 자료가 아니다. 생성 속도 차이만으로 병목의 원인을 확정하지 않는다. 당시 표의 gemma4:26b 는 gpt-oss:120b 보다 높은 생성 처리량을 보였다. 다만 이 결과를 모든 Dense 모델과 MoE 모델의 우열로 일반화할 수는 없다. 같은 ...
자세한 내용 보기

Opus 5는 더 잘 쓰고, 더 AI답게 쓴다 — 세 모델 첫날 실측

이미지
Claude Opus 5가 나온 다음 날, 세 모델에게 같은 시험지를 줬다. 결과부터 적는다. 글 품질 점수는 신형일수록 올랐다. 그런데 문장 리듬은 신형일수록 고르게, 그러니까 더 AI답게 변했다. 여기서 “AI답게”는 말투가 기계 같다는 뜻이 아니다. 문장 길이와 어미가 균질해진다는 뜻이고, 그 균질함이 통계 탐지기가 AI 글을 잡아낼 때 쓰는 바로 그 지문이다. 발표는 두 가지를 팔았다 새 모델이 나오면 벤치마크 표부터 보게 된다. 그 표는 전부 만든 쪽이 자기 시험지로 채점한 결과다. 내 작업에서 뭐가 달라지는지는 표에 없다. 그래서 표를 덮고 시험지를 직접 만들었다. 7월 24일 발표에서 Anthropic은 크게 두 가지를 내세웠다. 하나, 자기 작업을 검증하며 성공할 때까지 반복하는 능력이 강해졌다. 둘, 응답이 더 명확하고 간결해졌다. 벤치 수치는 여기 옮기지 않는다. 이 글이 확인할 건 저 두 문장이 내 작업물에서 어떻게 나타나느냐다. 같은 시험지 두 장 시험지는 두 장이다. 첫째는 글쓰기다. 주제·허용 사실·문체 규칙을 고정한 한국어 블로그 초안 스펙을 만들어 세 모델에 원샷으로 줬다. 둘째는 코딩 진단이다. 내 수집기에서 한 달 넘게 죽어 있던 실제 버그(reddit 수집 429 연쇄 실패)를 읽기 전용으로 진단하게 했다. 모든 주장에 파일과 행 번호 인용을 의무로 걸었다. 대상은 Opus 4.8, Fable 5, Opus 5. 각 모델의 정체는 시스템 프롬프트 자기보고로 확인했다. 채점은 사람 감이 아니다. 글은 발행 글 29편에서 뽑은 결정론 밴드(파이썬 스크립트)와 10점 감점제 루브릭으로, 진단은 미리 고정해 둔 정답표와 인용 실물 대조로 매겼다. 실측 1 — 더 잘 쓸수록 더 고르다 숫자부터 본다. 지표 Opus 4.8 Fable 5 Opus 5 발행 글 기준 문장 길이 변주(변동계수) 0.316 0.220 0.274 0.417 이상 행 길이 변주 0.266 0.23...
자세한 내용 보기