피드로 돌아가기
Dev.toInfrastructure
원문 읽기
Cross-vendor 추상화 및 스케줄러 도입으로 Agent 런타임 독립성 확보
oh-my-agent: cross-vendor scheduling, Kimi and OpenCode land
AI 요약
Context
특정 런타임에 종속된 Agent 구조로 인한 유연성 부족 및 세션 간 리소스 누수 문제 발생. CLI 벤더별로 상이한 인증 및 실행 방식이 워크플로우 통합의 병목으로 작용함.
Technical Solution
- SchedulerPort 추상화 계층 도입을 통한 OS별(launchd, systemd, crontab, schtasks) 스케줄링 통합 관리
- Kimi Code 및 OpenCode CLI를 First-class Vendor로 통합하여 CLI 독립적인 하네스 구조 설계
- Serena LSP 스택의 유휴 자원 회수를 위한 Reaper 메커니즘 도입으로 메모리 효율 최적화
- argv Fast path 및 Command tree Lazy-loading 적용을 통한 Prompt 진입 지연 시간 단축
- 500라인 초과 모듈의 세분화 및 공통 헬퍼 통합을 통한 코드 복잡도 감소 및 유지보수성 향상
- Repository-layer 응답 캐시(Drift, TanStack Query) 강제화를 통한 Mobile 환경의 Offline-first 전략 구현
Impact
- oma hook 실행 시간: 0.54s에서 0.32s로 약 40% 단축
- UserPromptSubmit aggregate timeout: 21s에서 15s로 하향 조정
- 문서 깨진 참조(Broken refs): 6,611개에서 394개로 94% 감소
- Serena LSP 유휴 메모리 점유: 프로젝트당 1.5GB 이상의 낭비 리소스 회수
Key Takeaway
특정 벤더의 API나 CLI에 의존하지 않는 추상화 레이어(Harness)를 구축함으로써 런타임 교체 비용을 최소화하고 시스템 확장성을 확보할 수 있음.
실천 포인트
- 외부 CLI 의존성이 높은 시스템 설계 시 인터페이스 추상화 계층을 먼저 정의했는가? - 리소스 점유가 큰 프로세스(LSP 등)에 대해 유휴 상태 기반의 Reaper/GC 메커니즘이 존재하는가? - CLI 도구의 응답 속도 개선을 위해 Lazy-loading이나 Fast path를 적용할 수 있는 지점이 있는가? - 모바일 환경의 API 호출 최적화를 위해 Repository-layer 캐싱 전략을 수립했는가?