개발 일지

앞선 글들에서 인텔 아이맥에 로컬 코딩 LLM 파이프라인을 설치하고, 4개 모델을 실측 비교했다. 결론부터 말하면 이 프로젝트는 여기서 접기로 했다. 그 판단에 이르기까지의 근거를 정리한다. 결정타는 “재현성 부족"이었다 가장 빠르고 안정적이었던 DeepSeek-Coder-V2-16B를, 완전히 동일한 프롬프트로 한 번 더 돌려봤다. 결과는 이랬다. 1차 2차 소요 시간 9분 30초 22분 55초 (2.4배) 커밋 feat + lint fix 시도 feat 1개뿐 함수 개수 요청한 4개 요청에 없던 4개(거듭제곱·나머지·제곱근·팩토리얼) 임의 추가 flake8 잔여 오류 일부 16건 같은 입력, 같은 모델인데 소요 시간이 2.4배 차이 나고, 심지어 요청하지 않은 기능을 마음대로 추가했다. 이건 “느리다"가 아니라 “결과물을 매번 처음부터 검토해야 한다"는 뜻이다. 무인 파이프라인의 핵심 전제 — 사람이 개입하지 않아도 일정 수준의 결과가 보장된다는 것 — 이 자체가 깨진 셈이다.

설치를 마쳤으니 이제 실측이다. Aider가 설치된 ~/Projects/pipeline-test 저장소에서, 모델별로 git 브랜치를 나눠 완전히 동일한 프롬프트를 던졌다. 간단한 계산기 모듈을 만들어줘. add, subtract, multiply, divide 함수와 각각의 pytest 테스트 코드도 함께 작성해줘. 의도적으로 아주 쉬운 작업을 골랐다. 이 정도도 제대로 못 하면 더 복잡한 작업은 아예 시도할 이유가 없기 때문이다. 결과 요약 모델 소요 시간 결과 비고 Qwen3-Coder-30B ~30분 ✅ 성공 flake8 자동 수정까지 완료. 요청하지 않은 거듭제곱·나머지·제곱근·팩토리얼 함수를 임의로 추가함 Qwen2.5-Coder-7B — ❌ 실패 whole·diff 포맷 둘 다 신뢰 불가 (아래 상세) DeepSeek-Coder-V2-16B 9분 30초 ✅ 성공 가장 빠름. flake8 일부 미해결 Qwen2.5-Coder-14B 27분 43초 ✅ 성공 가장 느림. flake8은 완전히 깨끗하게 해결 7B가 두 번 다 무너진 이유 가장 작은 모델인 Qwen2.5-Coder-7B는 흥미로운 실패 방식을 두 개나 보여줬다.

로컬 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가 내부적으로 어떤 명령을 실행하는지 직접 눈으로 확인해야 했다.

로컬 LLM 파이프라인을 만들려고 첫 삽을 뜨자마자 예상 못 한 벽에 부딪혔다. Homebrew가 Intel Mac 설치 자체를 거부한다. Homebrew on macOS is only supported on Apple Silicon processors! Homebrew 공식 문서에는 Intel Mac이 여전히 “Tier 3” 지원 대상으로 적혀 있는데, 실제 설치 스크립트는 이미 하드 블록을 걸어놨다. GitHub Discussion #7088을 뒤져보니, 2026년 9월 17일자로 메인테이너가 직접 남긴 댓글에서 이게 버그가 아니라 의도된 정책이라고 확인해준다. 문서와 실제 동작이 따로 노는 셈인데, 이미 결정된 정책이라니 우회할 수밖에 없었다.

집에 있는 구형 인텔 아이맥이 눈에 밟혔다. 3GHz 6코어 i5, Radeon Pro 570X 4GB, 32GB DDR4 — 일반 업무용으로는 여전히 충분한 사양인데, 놀고 있는 게 아깝다는 생각이 들었다. 마침 로컬 오픈소스 LLM으로 코딩 보조 파이프라인을 만들어보고 싶었던 참이라, 이 아이맥을 실험대로 삼기로 했다. 목표는 단순했다. 로컬 LLM이 코드 초안을 자동으로 작성하고, Claude Code가 그 결과를 검증·수정·커밋하는 2단계 파이프라인을 만드는 것. “결과만 정확하면 시간이 오래 걸려도 괜찮다"는 전제를 깔고 시작했다. GPU 가속, 기대는 접어야 했다 가장 먼저 확인한 건 Radeon Pro 570X로 추론을 가속할 수 있는지였다. 결론부터 말하면 불가능이다.

Iris 봇에 포팅한 기능 중 가장 설계가 복잡했던 건 경마 게임이었습니다. 특히 “마주”(말 소유자) 시스템은 단순한 베팅 게임을 넘어서는 작은 경제 시스템에 가까웠습니다. 기본 구조: 경마 게임 채팅방 유저들이 정해진 시간에 경주에 참여하고, 결과에 따라 포인트를 얻거나 잃는 방식의 미니게임입니다. 여기까지는 흔한 구조입니다. 이번 포팅에서 신경 쓴 부분은 그 위에 얹힌 “마주” 시스템이었습니다. 마주 시스템: 말을 소유한다는 것 마주 시스템은 유저가 포인트를 내고 특정 말의 소유권을 살 수 있게 하는 기능입니다. 소유한 말이 경주에서 우승하면, 소유자는 그 경주의 상금과는 별개로 일정 비율의 수수료를 받습니다. 즉 직접 경주에 참여하지 않아도, 좋은 말을 소유하고 있는 것만으로 꾸준한 수익을 기대할 수 있는 구조입니다.

이 시리즈의 마지막 글입니다. Gemini 원격 코딩 어시스턴트는 “채팅으로 요청하면 관리자 검토 없이 바로 라이브 봇 코드가 고쳐진다"는 구조입니다. 편리하지만 동시에 가장 위험할 수 있는 구조이기도 합니다. 이번 글은 그 위험을 어떻게 관리했는지에 대한 기록입니다. 왜 안전장치가 특히 중요했나 관리자가 매번 코드를 리뷰하고 승인하는 구조였다면 위험 부담이 훨씬 적었을 겁니다. 하지만 채팅으로 요청하면 곧바로 적용되는 구조를 원했기 때문에, “AI가 실수로 코드를 망가뜨리면 어떻게 할 것인가"라는 질문에 관리자 개입 없이도 답할 수 있는 장치가 필요했습니다.

지난 글에서 잠깐 언급했던, Gemini 원격 코딩 어시스턴트를 만들면서 겪은 설치 문제를 이번 글에서 자세히 다룹니다. 최신 환경이 오히려 발목을 잡는, 은근히 자주 마주치는 종류의 문제였습니다. 증상: 기본적인 패키지 설치가 안 된다 aider를 설치하려고 하니 의존 패키지 중 하나가 설치 단계에서 실패했습니다. 에러 메시지를 따라가 보니 distutils.msvccompiler를 찾을 수 없다는 식의, 파이썬 빌드 도구 체인과 관련된 에러였습니다. numpy처럼 오래되고 널리 쓰이는 과학계산 라이브러리조차 순순히 설치되지 않았습니다. 원인: 너무 최신 파이썬 이 환경의 기본 파이썬 버전은 3.14였습니다. 최신 버전을 쓰는 것 자체는 보통 좋은 일이지만, 이번엔 오히려 문제가 됐습니다. distutils는 오래전부터 파이썬 표준 라이브러리에서 단계적으로 제거되어 온 모듈이고, 여러 과학계산·빌드 관련 패키지들이 이 모듈에 의존한 채로 아직 최신 파이썬 버전에 맞춰 업데이트되지 않은 상태였습니다. 결과적으로 “너무 최신이라서” 오래된 패키지들과 호환이 깨지는, 흔치 않지만 실제로 마주치면 당황스러운 상황이었습니다.

봇 코드를 고치고 싶을 때마다 매번 이 S9에 직접 붙어서 작업하기는 번거로웠습니다. 그래서 브라우저로 접속해서 자연어로 요청하면 실제로 코드를 고쳐주는 원격 코딩 어시스턴트를 만들게 됐습니다. 이번 글은 그 구축 과정입니다. 1차 버전: 웹 터미널 처음 만든 버전은 단순했습니다. ttyd로 웹 터미널을 띄워서, 브라우저에서 이 폰의 셸에 직접 접속할 수 있게 했습니다. 터미널에서 평소처럼 AI 코딩 도구를 실행하면 되는 구조였습니다. 동작은 했지만, 실제로 써보니 터미널 UI 자체가 진입장벽이었습니다 — 매번 정확한 명령어를 기억해서 입력해야 했고, 모바일에서 터미널을 조작하는 것도 불편했습니다.