개발 일지

여러 LLM API를 오가며 자동화 파이프라인을 만들다 보면, 같은 이름의 파라미터라도 플랫폼마다 지원 범위와 동작이 미묘하게 다르다는 걸 자주 느낀다. 헷갈릴 때마다 매번 문서를 다시 뒤지는 대신, 한 번 정리해뒀다. 기본 파라미터 정의 temperature: 확률 분포를 얼마나 평평하게(무작위성을 높게) 만들지 조절. 값이 낮을수록 결정적이고 반복 가능한 출력, 높을수록 다양하고 창의적인 출력. top_p (nucleus sampling): 누적 확률이 p에 도달할 때까지의 후보 토큰만 남기고 샘플링. top_k: 확률 상위 k개 토큰만 후보로 남기고 샘플링. frequency_penalty / presence_penalty: 이미 등장한 토큰의 재등장 확률을 낮춰 반복을 억제. stop_sequence: 특정 문자열이 등장하면 생성을 중단. 플랫폼별 지원 범위 파라미터 OpenAI Claude Gemini(2026 최신) xAI Grok temperature 0~2 0~1 지원(단, 최신 플래시 모델은 비권장) 지원 top_p 0~1 지원 지원(최신 모델은 비권장) 지원 top_k 미지원 지원 지원(최신 모델은 비권장) 지원 frequency_penalty -2~2 미지원 제한적 지원 presence_penalty -2~2 미지원 제한적 지원 눈에 띄는 트렌드 두 가지 1. Claude는 애초에 파라미터 폭이 좁다. temperature도 0~1 범위로 제한되어 있고, frequency/presence penalty 자체가 없다. 게다가 최근 Opus급 최상위 모델 중 일부는 기본값 이외의 샘플링 오버라이드 자체를 거부하는 경우도 있었다. 세밀한 샘플링 튜닝보다는, 프롬프트 자체의 품질로 원하는 출력을 유도하는 방향에 무게를 두는 설계 철학으로 보인다.

Claude Code로 작업하다 보면 세션 하나가 몇 주씩 이어지는 경우가 생긴다. 아이맥 로컬 LLM 실험, 루팅폰 서버 관리, 사이드 프로젝트 기획까지 — 한 대화창 안에 여러 프로젝트가 뒤섞여 쌓이다 보니, 어느 순간 “이 대화가 너무 무거워졌다"는 느낌이 들었다. 특히 이 세션은 특정 컴퓨터(아이맥)에 대한 파일 접근 권한까지 물고 있어서, 더더욱 새 세션으로 넘어가고 싶어졌다. 문제는 그동안 나눈 대화에 흩어져 있는 결정사항, 삽질 기록, 설정값들을 그냥 버리기는 아깝다는 점이었다. 세션을 닫기 전에 정리부터 그래서 새 세션으로 넘어가기 전에, 지금까지의 대화 내용을 주제별로 정리한 문서를 먼저 만들어두는 방법을 썼다. Claude Docs(Claude가 만드는 살아있는 문서) 기능을 이용해서, 세션 안에서 다룬 프로젝트 하나당 탭 하나씩으로 나눠 정리했다.

루팅과 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)는 문제없이 설치됐다.

지금까지 나는 유휴 휴대폰 두 대를 각각 다른 용도의 서버로 굴리고 있었다. 갤럭시 퀀텀2는 Cloudflare Tunnel로 노출된 FastAPI 기반 업비트 시세 서버, 갤럭시 S9는 루팅해서 만든 IRIS 카카오톡 봇 서버. 이번에 이 두 서버의 기능을 S9 하나로 합쳤다. 왜 합쳤나 두 폰을 따로 유지보수하는 비용이 생각보다 컸다. 각 폰마다 Termux 환경, proot-Ubuntu, Claude Code 원격 세션을 따로 관리해야 했고, 장애가 나면 어느 폰의 어느 서비스인지부터 확인해야 했다. 서버 자체의 부하는 두 서비스를 합쳐도 충분히 감당할 수준이라 판단해서, 한 대로 통합하는 쪽을 택했다.

상시 구동 서버로 쓰고 있는 루팅 갤럭시 S9(SM-G960N)의 저장 공간이 빠듯해졌다. RAM도 4GB에 실제 스왑은 2GB뿐이라, “SD카드를 추가로 사서 스왑으로 쓰면 메모리 부족 문제까지 같이 해결되지 않을까” 하는 생각이 들었다. 결론부터 말하면 그렇게 하지 않기로 했다. 안드로이드는 이미 zram을 쓰고 있다 먼저 확인해야 했던 건 이 폰이 이미 스왑 비슷한 걸 쓰고 있는지였다. cat /proc/swaps free -h /dev/block/zram0 항목이 보이면, 이미 zram(RAM 일부를 압축해서 스왑처럼 쓰는 방식)이 동작 중이라는 뜻이다. 디스크 기반 스왑이 아니라 RAM 안에서 압축·해제하는 방식이라, SD카드 스왑을 추가로 얹는 것과는 성격이 다르다.

놀고 있던 인텔 아이맥 하나로 시작한 실험이 어느새 17편짜리 시리즈가 됐다. 하드웨어 한계를 확인하는 글로 시작해서, Homebrew 설치 차단, MCP 바이너리 부재, 네 개 모델 실측 비교, 그리고 결국 프로젝트를 접기로 한 결정까지 — 매 단계에서 부딪힌 벽과 우회로를 그때그때 기록해뒀다. 돌아보니 남는 것 시리즈를 마치고 다시 훑어보면, 이 프로젝트에서 진짜 값진 건 “로컬 LLM 파이프라인을 완성했다"는 결과가 아니라 왜 안 되는지를 실측으로 확인한 과정 쪽이었다. GPU 가속이 안 된다는 걸 처음부터 알고도 CPU로 밀어붙였고, 그 판단이 얼마나 순진했는지는 재현성 테스트(같은 모델, 같은 프롬프트인데 소요 시간이 2.4배 벌어지고 요청하지 않은 함수까지 추가된 사례)에서 명확하게 드러났다. 결론을 성급하게 내리지 않고 두 번째 실행까지 검증해본 덕분에, “빠르고 안정적인 모델"이라는 잘못된 결론으로 파이프라인을 그대로 밀어붙이는 일은 막을 수 있었다.

이번에 인텔 아이맥에 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는 이 경로에 패키지를 풀어야 하는데, 권한이 없으니 거부당하는 것이다.

지금까지의 벤치마크에서 속도 문제는 대부분 모델 추론(CPU 바운드 decode) 탓으로 돌렸다. 그런데 문득 이런 의문이 들었다. “Aider 자체는 병목이 아닐까? 모델한테 뭘 보내는지, 그 준비 과정 자체가 느린 건 아닐까?” Aider가 매 턴마다 하는 추가 작업 Aider는 단순히 사용자 프롬프트만 모델에 던지지 않는다. 매 요청마다 다음과 같은 부가 작업이 들어간다. 1. repo-map 생성 프로젝트 전체 구조를 파악해서, 지금 대화와 관련 있을 법한 파일·함수 목록을 요약한 “지도"를 만든다. 이 작업은 tree-sitter라는 파서를 이용해 코드를 구문 분석하는 방식으로 이뤄진다. 프로젝트가 작을 땐(이번 테스트의 계산기 모듈처럼) 무시할 만한 수준이지만, 파일 수가 많은 대형 저장소에서는 이 repo-map 생성 자체에 시간이 걸릴 수 있다.

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 실행파일이 서로 다른 설치본을 가리킬 가능성이 있다.