서론

Day 19!

Day 18에서는 작업 관리를 위해 고양이들로 이루어진 회사를 세웠습니다. 오늘은 직원 근무일입니다. 저는 관리자인 Rusuban-neko에게 실제 업무를 맡겼습니다 🐱

사용한 것: Ollama (qwen2.5:7b) / Claude Code / DGX Spark / Slack

오늘의 계획

• 원하는 것: 네 가지 — Rusuban-neko를 가동하고, 네 명의 직원 고양이들을 구체화하며, Claude 사용량 제한에 대비하고, Slack 받은 편지함 감시기를 수정하기
• 완료의 의미: 폴더에 메모를 떨어뜨리면, 제가 확인할 때쯤에는 Rusuban-neko가 준비 작업을 완료했다는 뜻입니다.
• 결과:
  • Rusuban-neko가 가동되었습니다. 추가 API 비용이 없고, 몇 초 만에 답장을 합니다. 문제는: 중국어로 바뀌어 버립니다
  • 제한 대비책이 마련되었습니다 (사용량 확인 및 Codex로 인계)
  • 받은 편지함 감시기를 LLM에서 분리했습니다. 유휴 상태일 때 API 비용이 들지 않으며, 반응 시간이 최대 4분에서 몇 초로 줄었습니다
  • 지사 사무실 Necco가 이제 DGX에 거주하여, 제 노트북이 잠겨 있을 때도 Slack을 사용할 수 있습니다.

① Rusuban-neko 가동

Rusuban-neko란 무엇인가? = DGX에서 작동하는 로컬 LLM (qwen2.5:7b)인 직원입니다. 폴더에 메모를 떨어뜨리면, 요약과 태그, 그리고 다음 후보 행동을 작성하여 답장합니다.

이것은 전적으로 DGX 내부에서 실행되므로 API 비용이 들지 않습니다. 제 메모의 내용물도 집 밖으로 나가지 않습니다.

세 가지 구축할 것이 있었습니다.

1. 기반: Ollama (표준 로컬-LLM 런타임)는 이미 DGX에 있었으므로, 그대로 사용했습니다. 모델은 경량화된 qwen2.5:7b입니다.
2. 페르소나:

심지어 "다음 주 수요일까지 결정하기"와 같은 마감 기한까지 파악했으며, 답변은 몇 초 만에 돌아왔습니다.

② 네 마리의 직원 고양이 구체화

실제로 회사를 운영하며 배운 점들을 18일 차에 정의했던 네 마리의 직원 정의에 추가했습니다.

③ 한계치에 도달할 때 Codex로 인계

Claude에는 사용량 제한(usage limit)이 있습니다. 작업 도중에 끊기는 것은 고통스러운 일이기에, 두 가지를 구축했습니다.

• 읽기 도구 (The readout): 화면 하단에 항상 표시되는 사용량 (ccusage라는 도구)
• 인계 (The handoff): 제한에 가까워지면, 남은 일상적인 업무를 인계 문서(handoff document)에 작성하여 하청업체인 Codex로 넘깁니다.

인계 문서에는 세 가지 부분이 포함됩니다: 완료된 작업, 내가 원하는 작업(수락 기준 (acceptance criteria) 포함), 그리고 건드리지 말아야 할 것. 내가 돌아오면, Mekiki-neko가 해당 기준에 따라 결과를 검사합니다.

이 모든 작업은 총 1시간 미만이 소요되었습니다.

④ Slack 편지함 감시 기능을 LLM에서 분리

18일 차에 구축한 Slack 편지함은 Necco가 4분마다 직접 확인하러 가는 방식으로 작동했습니다.

• 이는 하루에 360번의 확인을 수행하며, 실제 메시지는 몇 개 되지 않습니다.
• 순찰 대화가 이전 기록을 계속 끌고 가기 때문에, 매 라운드마다 이전보다 더 많은 비용이 발생합니다.

저는 이를 무언가 도착했을 때 Slack이 나에게 알려주는 방식 (Socket Mode)으로 전환했습니다. 작은 Python 스크립트가 수신을 처리하며, Necco는 실제로 무언가 도착했을 때만 깨어납니다.

휴대폰으로 게시물을 올리자 몇 초 만에 파일에 저장되었습니다. 두 가지 문제점(잘린 설정값 붙여넣기 및 비공개 채널 권한 누락)에 대한 자세한 내용은 아래에 기술했습니다.

⑤ 지사 Necco가 DGX로 이동하다

노트북이 절전 모드인 상태에서도 이동 중에 Slack을 사용할 수 있도록, 24시간 가동되는 DGX에 응답 에이전트인 **지사 Necco (branch-office Necco)**를 배치했습니다.

휴대폰 → Slack → DGX가 새 메시지를 감지
  → 지사 Necco가 원장(ledger)과 일지(journal)를 읽고 Slack으로 응답

매 응답마다 완전히 새로운 Necco(마지막 8번의 대화 내용만 포함)가 소환됩니다. 이는 "대화가 길어질수록 비용이 높아지는" 문제를 우회합니다. 이 에이전트는 읽기 전용이며, 30분이 지난 메시지에는 응답하지 않습니다.

한 가지 문제점이 있었습니다. 노트북과 DGX 양쪽에서 수신기를 동시에 실행했을 때, 알림이 두 기기로 분산되었습니다. 세상에 수신기는 단 하나여야 한다는 것이 규칙입니다.

따라서 이제 Slack은 제 노트북이 전혀 개입하지 않아도 작동합니다.

고양이 회사의 현재 상태

19일 차 종료 시점의 현황입니다.

                    🧑 나
                   /        \
          (대화)  /           \ (휴대폰으로 게시)
...

수석 비서는 제 노트북에 머물러 있으며, 자리를 지키고 이동 중인 저를 상대하는 일은 DGX에서 수행됩니다. DGX 측에서는 대기하는 동안 API 비용이 전혀 발생하지 않습니다.

오늘의 요점

• 지시문(instructions)으로 작은 모델의 한계 보완하기: 중국어 유출 문제는 프롬프트 작업만으로도 억제할 수 있었습니다.
• 사전 작업은 로컬에서 수행하기: API 비용이 들지 않고, 몇 초면 끝나며, 데이터가 외부에 유출되지 않고 집에 머뭅니다.
• 감시와 사고의 분리: 스크립트가 대기하고, 무언가 도착한 후에야 LLM이 시작됩니다.
• AI의 기억은 파일이다: 지사 Necco의 응답 품질은 원장(ledger)과 일지(journal)가 얼마나 잘 작성되었느냐에 달려 있습니다.

세부 사항

DGX 조사 및 모델 선정

which ollama                 # → /usr/local/bin/ollama
systemctl list-units | grep ollama   # → ollama.service active (running)
ss -tlnp                     # → LISTEN on 127.0.0.1:11434
...

• 새로운 서버(포트 8591)를 구축할 계획이었으나, 조사 결과 Ollama가 이미 실행 중임을 확인하여 추가 구축이 필요하지 않았습니다.
• Ollama는 11434 포트에서 OpenAI 호환 API (/v1/chat/completions)를 제공합니다. 이것이 그대로 Rusuban-neko의 정문(front door)이 되었습니다.
• 127.0.0.1에만 바인딩(bind)되어 있어, "외부에 노출되지 않아야 한다"는 요구 사항을 이미 충족했습니다.
• 설치된 모델: qwen2.5:7b (4.7GB) / qwen2.5vl (6.0GB) / qwen2.5-coder:32b (19GB) / qwen2.5:72b (47GB). 요약, 분류 및 태깅을 위해 가장 가벼운 7b 모델을 선택했습니다.
• llama.cpp 서버로 전환하는 것을 고려했으나, 품질은 서버 소프트웨어보다는 모델에서 나오기 때문에 기존의 Ollama를 유지했습니다.
• 참고: nvidia-smi의 메모리 열에 [N/A]가 표시됩니다. DGX Spark (GB10)는 CPU와 GPU 간에 메모리를 공유하므로, GPU 전용 사용량이 나타나지 않습니다.

중국어 문제 해결 내부 사항

• 시스템 프롬프트(system prompt)에 이제 "일본어로만 출력할 것. 중국어와 영어는 금지함"이라고 명시되어 있습니다.
• 출력 형식을 Markdown 템플릿(요약 / 태그 / 후보 작업)으로 고정했습니다. 자유로운 작문 공간이 줄어들수록 언어 사용이 더 안정적입니다.
• temperature(온도)를 0.3에서 0.1로 조정했습니다.
• 수정 후 사용량은 프롬프트(prompt) 158 토큰 / 완료(completion) 110 토큰이었습니다. 7b 모델이므로 응답에 몇 초가 소요됩니다.

관리자 스크립트(caretaker script) 내부 사항

• JSON을 안전하게 조립하기 위해 python3가 내장된 단일 bash 스크립트입니다 (jq 의존성 없음).
• input/ 디렉토리를 순회하며 .digest.md가 없는 파일에 대해 qwen에게 질문하고, 그 옆에 <original name>.digest.md를 작성합니다.
• 원본은 건드리지 않으며, 이미 처리된 파일은 건너뛰고, 빈 파일은 SKIP으로 표시합니다.
• 복구 단계(Ollama 재시작)는 설정 런북(runbook)에 포함되었습니다.

Rusuban-neko의 페르소나가 직원 정의 파일이 아닌 이유

네 마리의 직원 고양이는 agents/에 정의되어 있으며, 설치 스크립트가 이들을 Claude Code의 서브 에이전트(subagents)로서 ~/.claude/에 배치합니다.

Rusuban-neko도 그곳에 배치하고 싶은 유혹이 있었지만, 그렇게 하지 않았습니다. 그것은 로컬 LLM(Large Language Model)이므로, agents/에 정의를 두게 되면 **Claude Code 측에서 실제로는 qwen이 아닌

1. Truncated manifest (잘린 매니페스트): 들여쓰기가 심한 JSON을 브라우저에 붙여넣었을 때 중간에 잘리면서 JSON 에러가 발생했습니다. 압축된 버전을 다시 붙여넣으니 해결되었습니다.
2. Private channel scopes (프라이빗 채널 스코프): Slack은 스코프(scopes)를 공개(channels:*)와 프라이빗(groups:*)으로 나눕니다. 채널 ID는 두 경우 모두 C로 시작하기 때문에 구분할 방법이 없었습니다. 결국 missing_scope 에러를 통해 원인을 찾아낼 수 있었습니다.
   • 참고: 스코프를 변경한 후에는 앱을 재설치하고 수신기를 재시작해야 합니다. 토큰 문자열은 변경되지 않았습니다.

지사 Necco 내부

• 수신기(Receiver) 및 응답기(Replier) 스크립트는 DGX에서 systemd 서비스로 실행됩니다 (enable --now와 loginctl enable-linger를 사용하여 재부팅 후에도 다시 실행되도록 설정).
• 응답기는 파일 추가를 감지하면 → claude -p를 정확히 한 번 실행하며 (읽기 전용, Read/Grep/Glob 허용) → 원장(ledger)과 저널(journal)을 읽은 뒤 → 봇으로서 Slack에 게시합니다.
• 매번 새로운 짧은 컨텍스트(최근 8개의 대화만 포함)를 사용하여, 응답당 비용이 일정하게 유지되며 유휴 상태 동안 비용이 누적되지 않습니다.
• 프롬프트에 고정된 안전 장치(Safety rails): 시작 시 이미 존재하는 항목은 건너뜀 / 30분 이상 된 메시지에는 응답하지 않음 / 연속된 게시물은 하나로 일괄 처리(batch) / 쓰기 요청은 보류했다가 메인 Necco로 전달함

내일: Day 20

여섯 가지 비디오 생성 도구 정면 대결 (2026년 버전). 동일한 고양이 이미지를 여섯 가지 도구에 모두 입력하여 품질과 시간을 비교합니다.

읽어주셔서 감사합니다!