트러블슈팅 on Simon의 AI 시대에 살아남는 법

부팅 스크립트 한 줄이 서비스 전체를 막다 — 첫 워치독의 오탐까지

Tue, 03 Nov 2026 10:05:00 +0900

이 글은 ‘폰 서버 안정화 일지’ 시리즈의 첫 번째다. 재부팅만 하면 절반쯤의 서비스가 안 올라오던 시절, 원인이 부팅 스크립트의 한 줄이었다는 이야기와, 그걸 고치려고 만든 첫 워치독이 거꾸로 건강한 봇을 매번 죽이던 이야기다.

증상: 재부팅 뒤 Claude 세션이 안 뜬다

폰을 재부팅하면 카카오톡 봇은 살아나는데 Claude Code 세션과 터널 몇 개가 안 올라오는 날이 반복됐다. 재부팅 직후 tmux 세션 목록을 보면 iris만 있고 claude, cloudflare, blogadmin 같은 세션이 없었다. 하루는 수동으로 띄우고 넘어갔지만, 같은 일이 세 번째 반복되자 부팅 스크립트를 처음부터 끝까지 읽었다.

IRIS.apk가 설치되지 않을 때 — 미서명 APK 재서명과 수동 기동 매뉴얼

Mon, 26 Oct 2026 18:05:00 +0900

루팅과 Termux 환경까지 다 갖춰놓고도, 정작 카카오톡 봇의 핵심인 IRIS 서버 APK 하나가 설치되지 않아 발목을 잡힌 적이 있다. 원인과 해결법, 그리고 이후 장애 복구 때마다 참고하는 수동 기동 절차를 정리해둔다.

Termux 사이드로딩부터 막혔다

Termux 자체를 F-Droid나 GitHub에서 받은 arm64-v8a apk로 설치하려는 시도부터 전부 “패키지를 파싱하는 중 문제가 발생했습니다"로 실패했다. adb install로 우회해봐도 이번엔 INSTALL_FAILED_VERIFICATION_FAILURE로 막혔다.

원인은 Play Protect였다. 설정 → Play 스토어 → Play Protect → “기기에서 앱 검사” 토글이 켜져 있으면, Play 스토어 밖에서 받은 apk의 설치 자체를 사전 검증 단계에서 막아버린다. 이 폰은 개인용이 아니라 전용 서버로만 쓸 것이므로 이 토글을 영구적으로 꺼두기로 했다. 이후 Termux(v0.118.3, GitHub release)는 문제없이 설치됐다.

npm install -g에서 EACCES가 뜨는 진짜 이유와 sudo 없이 고치는 법

Thu, 22 Oct 2026 10:55:00 +0900

이번에 인텔 아이맥에 Claude Code CLI를 새로 설치하면서 겪은 EACCES 에러를, 다른 프로젝트에서도 반복해서 마주쳤던 참에 한 번 근본 원인부터 정리해두기로 했다.

에러가 나는 이유

$ npm install -g @anthropic-ai/claude-code
npm error code EACCES
npm error syscall access
npm error path /usr/local/lib/node_modules

npm의 전역 설치 기본 경로(/usr/local/lib/node_modules 또는 Homebrew/Node 버전에 따라 다른 시스템 경로)는 macOS·리눅스 배포판 대부분에서 일반 사용자 계정에 쓰기 권한이 없는 시스템 디렉터리다. npm install -g는 이 경로에 패키지를 풀어야 하는데, 권한이 없으니 거부당하는 것이다.

Aider가 스스로 업그레이드했다는데 버전은 그대로 — 사소하지만 신경 쓰인 불일치

Tue, 20 Oct 2026 20:10:00 +0900

Aider를 실행할 때마다 새 버전이 있다는 안내가 떴다. 안내를 따라 자체 업그레이드를 진행했는데, 완료 메시지에는 분명 0.86.2로 올라갔다고 나왔다. 그런데 이후 aider --version을 찍어보면 여전히 이렇게 나왔다.

$ aider --version
aider 0.82.3

큰 문제로 이어지진 않았지만, 왜 이런 불일치가 생겼는지는 짚고 넘어갈 만하다.

의심되는 원인들

1. 여러 개의 pip/python 경로 공존

pip install --user aider-chat으로 설치했는데, 시스템에 Python 경로가 여러 개 있는 환경(macOS는 특히 Xcode Command Line Tools의 Python, Homebrew Python, python3.9 등이 뒤섞이기 쉽다)이라면, 업그레이드 명령이 실행되는 pip과 실제로 PATH에서 먼저 잡히는 aider 실행파일이 서로 다른 설치본을 가리킬 가능성이 있다.

여러 로컬 LLM 모델을 번갈아 테스트할 때 알아야 할 것 — ollama ps와 keep_alive

Sat, 17 Oct 2026 18:25:00 +0900

4개 모델을 순서대로 벤치마크하던 중, 이상하게 다음 모델의 로딩이 평소보다 느리게 느껴지는 순간이 있었다. ps aux로 확인해보니 원인이 바로 보였다.

$ ps aux | grep llama-server
simon 41203 539.6 ... llama-server --model .../qwen2.5-coder-14b ...
simon 40891 0.0 ... llama-server --model .../deepseek-coder-v2-16b ...

새로 시작한 14B 테스트는 CPU 539.6%로 활발히 계산 중인데, 바로 아래에 방금 전에 테스트했던 DeepSeek 16B 프로세스가 CPU 0%로 여전히 살아있었다. 이미 다른 터미널에서 Aider 세션을 종료했는데도 말이다.

keep_alive, 알아서 안 꺼주는 5분

원인은 Ollama의 keep_alive 메커니즘이었다. Ollama는 한 번 로드한 모델을 요청이 끝난 뒤에도 기본 5분간 메모리에 유지한다. 같은 모델로 연속 요청이 들어올 걸 대비한 최적화인데, 이게 여러 모델을 짧은 간격으로 번갈아 테스트하는 상황에서는 오히려 방해가 된다 — 이전 모델이 여전히 RAM을 점유하고 있어서, 새 모델이 로드될 때 쓸 수 있는 메모리 대역폭이 줄어들기 때문이다.

npm 패키지에 내 아키텍처용 바이너리가 없을 때 — MCP 로컬 LLM 서버를 소스로 빌드하기

Thu, 08 Oct 2026 21:15:00 +0900

로컬 LLM 파이프라인에는 두 가지 활용 방식이 있다고 생각했다. 하나는 Aider가 터미널에서 로컬 모델로 자율 작업을 하는 방식, 다른 하나는 Claude Code 세션 안에서 필요할 때만 로컬 모델에 작업을 위임하는 MCP(Model Context Protocol) 서버 방식이다. 이 둘은 서로 배타적이지 않고 병행할 수 있어서, 일단 MCP 쪽도 붙여보기로 했다.

CONNECTION_CLOSED

claude mcp add local-llm -- npx -y mcp-local-llm

등록은 됐는데, claude mcp list로 확인하면 상태가 이렇다.

local-llm: npx -y mcp-local-llm - ✘ Failed to connect — CONNECTION_CLOSED

에러 메시지만으로는 원인을 알 수 없었다. npx가 내부적으로 어떤 명령을 실행하는지 직접 눈으로 확인해야 했다.

Python 3.14 환경에서 막힌 numpy·aider 설치기

Sat, 03 Oct 2026 04:02:00 +0900

지난 글에서 잠깐 언급했던, Gemini 원격 코딩 어시스턴트를 만들면서 겪은 설치 문제를 이번 글에서 자세히 다룹니다. 최신 환경이 오히려 발목을 잡는, 은근히 자주 마주치는 종류의 문제였습니다.

증상: 기본적인 패키지 설치가 안 된다

aider를 설치하려고 하니 의존 패키지 중 하나가 설치 단계에서 실패했습니다. 에러 메시지를 따라가 보니 distutils.msvccompiler를 찾을 수 없다는 식의, 파이썬 빌드 도구 체인과 관련된 에러였습니다. numpy처럼 오래되고 널리 쓰이는 과학계산 라이브러리조차 순순히 설치되지 않았습니다.

원인: 너무 최신 파이썬

이 환경의 기본 파이썬 버전은 3.14였습니다. 최신 버전을 쓰는 것 자체는 보통 좋은 일이지만, 이번엔 오히려 문제가 됐습니다. distutils는 오래전부터 파이썬 표준 라이브러리에서 단계적으로 제거되어 온 모듈이고, 여러 과학계산·빌드 관련 패키지들이 이 모듈에 의존한 채로 아직 최신 파이썬 버전에 맞춰 업데이트되지 않은 상태였습니다. 결과적으로 “너무 최신이라서” 오래된 패키지들과 호환이 깨지는, 흔치 않지만 실제로 마주치면 당황스러운 상황이었습니다.

채팅 랭킹 시스템과 모바일 브라우저 onchange 버그

Sun, 27 Sep 2026 07:00:00 +0900

이번 글은 겉보기엔 서버 쪽 로직이 아니라 아주 평범한 웹 프론트엔드 버그처럼 보였지만, 실제로는 모바일 브라우저의 특성을 몰라서 한참 헤맸던 사례입니다.

채팅 랭킹과 등급 시스템

Iris 봇에는 누적 채팅 수에 따라 자동으로 등급이 올라가는 채팅 랭킹 시스템이 있습니다. 이번에 포팅하면서 기존 방식(누적 채팅수 기반 자동 승급)에 더해, 포인트를 소모해서 등급을 직접 “구매"하는 방식도 선택적으로 켤 수 있도록 기능을 추가했습니다. 등급 자체의 개수(최대 6개)도 방마다 다르게 설정할 수 있게 만들었습니다.

증상: 줄이기는 되는데 늘리기가 안 된다

이 등급 개수를 설정하는 UI는 숫자 입력창(스피너)이었습니다. 테스트해보니 이상한 패턴이 나타났습니다 — 값을 줄이는 건 잘 되는데, 늘리는 조작만 화면에 반영되지 않는 것처럼 보였습니다. 처음엔 서버 쪽 유효성 검사 로직이 최댓값을 잘못 제한하고 있는 줄 알고 그쪽을 한참 들여다봤지만 문제가 없었습니다.

에디터가 세 번 망가진 이유 — 템플릿 리터럴 이스케이프 이중 해석 버그

Fri, 25 Sep 2026 08:02:07 +0900

블로그 관리자 페이지의 글쓰기 에디터를 세 번 연속으로 다시 만들었다. 세 번 다 “고쳤다"고 생각했는데, 실제로 브라우저를 열면 카테고리 목록도 안 뜨고 툴바 버튼도 하나도 반응하지 않았다. 원인은 라이브러리가 아니라, 훨씬 더 근본적인 곳에 있었다.

처음 시도는 Tiptap이었다. esm.sh CDN에서 @tiptap/core, @tiptap/starter-kit, @tiptap/extension-placeholder를 각각 따로 불러왔는데, 패키지마다 별도로 번들링된 esm.sh 특성상 같은 클래스가 서로 다른 인스턴스로 중복 로드될 위험이 있는 조합이었다. 전혀 동작하지 않아서 Quill.js로 바꿨다 — 단일 UMD 스크립트라 이 위험 자체가 없는 선택이었다. 그런데도 여전히 안 됐다.

파이썬 모듈을 여러 파일로 쪼갤 때 만난 main 순환참조 문제

Fri, 25 Sep 2026 07:00:00 +0900

지난 글에서 카카오톡 봇 Iris를 관리자·랭킹·경제·경마·미니게임·경매·AI 등 9개 파일로 나눴다는 이야기를 했습니다. 이번 글은 그 과정에서 실제로 부딪힌, 파이썬을 오래 써도 은근히 잘 모르고 지나가는 함정 하나를 기록합니다.

증상: 봇이 두 번 뜬다

메인 파일 irispy.py를 python3 irispy.py로 직접 실행해서 봇을 띄웠습니다. 문제는 서브 모듈(예: 랭킹 기능 파일)에서 메인의 봇 인스턴스나 DB 헬퍼 함수를 쓰려고 import irispy를 했을 때 발생했습니다. 봇이 두 개가 뜬 것처럼 동작하거나, 초기화 로직이 중복 실행되는 이상한 증상이 나타났습니다.

이미지에 한글 텍스트 그릴 때 겪은 폰트 문제와 해결 과정

Sun, 20 Sep 2026 20:20:00 +0900

이 블로그의 글마다 붙어 있는 썸네일 이미지들은 전부 Python의 Pillow(PIL) 라이브러리로 직접 그린 것입니다. 그런데 이 기능을 처음 만들 때, 정작 가장 중요한 한글 텍스트가 화면에 텅 빈 네모 박스로만 나오는 문제를 겪었습니다. 이번 글은 그 원인과 해결 과정입니다.

증상: 글자가 전부 빈 네모로 나온다

썸네일 생성 스크립트를 처음 실행했을 때, 제목이나 카테고리 배지에 들어가야 할 한글 텍스트가 화면에 아예 보이지 않거나 깨진 네모(이른바 “tofu”)로만 표시됐습니다. 처음엔 좌표 계산이 잘못됐나 의심했지만, 텍스트의 bbox(경계 상자)를 찍어보니 높이가 0으로 나오는 경우까지 있어 좌표 문제가 아니라는 걸 알게 됐습니다.

apt-get이 자꾸 멈출 때: GitHub Releases .deb 직접 설치로 우회하기

Sun, 20 Sep 2026 18:00:00 +0900

이 서버를 세팅하면서 가장 자주 반복된 문제 하나를 꼽으라면 단연 apt-get입니다. Hugo, Caddy, 한글 폰트 패키지까지 — 덩치가 좀 있는 패키지를 설치하려 할 때마다 모바일 네트워크 환경에서 다운로드가 멈춘 채로 응답이 없는 상황을 여러 번 겪었습니다. 이번 글은 그 문제를 어떻게 우회했는지 기록입니다.

증상: 멈췄는지 느린 건지 구분이 안 된다

apt-get install -y <패키지>를 실행하면 진행률 표시 없이 그냥 멈춘 것처럼 보이는 경우가 많았습니다. timeout 60으로 감싸서 실행해도 60초 안에 끝나지 않고 그대로 종료(exit code 143)되는 일이 반복됐는데, 재시도해도 같은 패턴이 이어졌습니다. 원인은 명확히 특정하지는 못했지만, 모바일 데이터/와이파이 전환 구간에서 저장소 미러 서버와의 연결이 불안정했던 것으로 추정합니다.