깃허브 소외 보석 발굴 2호, 스타 1개 개인 에이전트 OS eidan 코드 실측기

MCP·A2A·AG-UI 세 개 프로토콜을 말하는 개인 에이전트 OS eidan을 클론해 직접 실측했다. 타입체크 11개 패키지 실패·에러 180건이라는 정직한 결과와 함께.
마크다운 원문·보충·정정할 내용이 있나요?

결론부터: 아이디어는 뼈 있고, 타입 게이트는 뚫려 있다

eidan(sielay/eidan)은 "인지 인프라를 소유하라"는,direct한 문장으로 시작하는 셀프호스트 개인 에이전트 OS다. MCP(도구), AG-UI(채팅), A2A(에이전트 간 통신) 세 개 개방형 프로토콜을 동시에 말하고, 기억은 전부 내 Postgres에 쌓는다. 컨셉만 보면 시리즈 1호 gno보다 야심 차다.

직접 클론해 실측한 결과는 이렇다. 라이선스 문서화는 모범생, 타이핑 의식도 있다. 그런데 정작 tsc --noEmit을 전체 패키지에 돌리면 11개 패키지에서 에러 180건이 나온다. 1호 gno가 "tsc clean"이었던 것과 정반대다. 소외된 보석이라고 다 같은 광택이 나는 건 아니다. 무엇이 빛나고 무엇이 금이 갔는지, 실측 기록을 남긴다.

실측 환경

항목값
대상sielay/eidan, v0.20.0 (shallow 클론 + 서브모듈, 37M)
분석 환경Ubuntu, node v24.18.0, pnpm 9.15.9 (저장소 요구 버전과 일치)
규모TypeScript 656개, 테스트 97개, pnpm 모노레포 56개 패키지
실행 테스트Docker·Postgres·API 키가 필요해 미실시, 코드 분석 + DB 불필요 패키지 테스트 1건 시범 실행

운영자 환경 측정 기준. 실행 테스트를 못 한 점은 한계로 밝힌다. 감이 아니라 측정한 것만 쓴다.

구조: 플러그인이 곧 제품이다

eidan의 설계는 단순하다. 핵심은 얇은 에이전트 엔진 matbot(별도 저장소를 git 서브모듈로 벤더링, Apache-2.0)이고, 그 위에 메일·캘린더·CRM·재무·코드 등 50여 개 플러그인 패키지가 올라간다. 플러그는 문자열 키 기반 서비스 레지스트리로만 코어에 붙고, 코어를 직접 고치지 않는다. 배포할 때는 선택한 플러그인 묶음(bundle)을 호스트 이미지에 벤더링한다. 구조 자체는 "내가 고른 능력만 얹는 에이전트"라는 컨셉과 일치한다.

진입로도 세 개로 나뉘어 있다. AG-UI 채팅이 8090, MCP 서버가 8091, A2A 에이전트가 8095, 참조 웹 UI가 3001. 네 개 포트는 코드에서 그대로 확인했고 README 주장과 일치한다. 말과 코드가 어긋나지 않는 지점은 신뢰 재료다.

실측 1: 타입체크 11개 패키지 실패, 에러 180건

가장 뼈를 때린 결과다. pnpm -r run typecheck --no-bail로 전체 패키지를 강제 실행했다. 기본 pnpm -r은 실패 지점에서 멈추기(bail) 때문에 --no-bail이 필수다.

  • 실패 패키지 11개: boards, charles-decks, charles-domains, crm, finance-google-trends, finance-trading212, frontend-agui, memory, storage-postgres, tool-failure-handler, ventures
  • 에러 180건 중 운영 코드(src) 132건, 테스트 파일 48건

대표 사례는 packages/memory/src/tools.ts의 TS2375다. exactOptionalPropertyTypes가 켜진 상태에서 옵셔널 필드에 undefined를 직접 할당하는 패턴이다. 설정은 엄격하게 해 놓고 코드가 설정을 못 따라간 경우다. 나머지도 대동소이하다. 테스트 파일 방치분이 48건이라는 점도 CI 게이트가 없다는 방증이다.

다만 맥락은 공정하게 적는다. 56개 패키지 전부 strict: true이고, 테스트 제외 any는 656개 파일에 40건이다. 타이핑을 포기한 프로젝트가 아니라 속도를 택한 프로젝트의 흔적에 가깝다. 그래도 v0.20.0이라는 버전 숫자에 타입체크 실패는 실사용 전에 직접 확인해야 할 하자다.

실측 2: 테스트는 돌아간다, DB만 없으면

전체 테스트 스위트는 Postgres를 요구해서 격리 환경에서 돌릴 수 없었다. 대신 DB가 필요 없는 tool-failure-handler 패키지 1건을 시범 실행했다.

  • 결과: 6개 테스트 전부 통과 (124ms)
  • 러너는 node 내장 node:test + matbot 레지스터 로더. 별도 테스트 프레임워크 의존성이 없다

테스트 인프라 자체는 멀쩡하다는 뜻이다. 문제는 커버리지가 아니라 실행 조건이다. DB 없이는 돌릴 수 없는 테스트가 대부분이라, 받는 쪽에서 검증하려면 Docker Compose 한 줄이 강제된다. 진입장벽이 코드가 아니라 환경에 있다는 점은 기록해 둘 만하다.

실측 3: 시크릿 하드코딩 없음, 라이선스 문서화는 모범생

  • 하드코딩된 API 키·토큰 없음. .env 예시와 플레이스홀더만 존재한다
  • 코어와 37개 패키지 전부 AGPL-3.0-or-later. matbot 서브모듈은 Apache-2.0으로 LICENSE에 분리 명시
  • LICENSE.md에 상표·CLA(기여자 라이선스 동의) 문서까지 갖춰져 있다. 스타 1개짜리 개인 프로젝트에서 보기 드문 수준이다

빠진 것, 과장된 것

README의 "라즈베리파이에서 한 줄 기동"은 Docker Compose 기준이라 틀린 말은 아니다. 다만 API 키(Anthropic 등) 없이는 엔진이 안 돌아간다는 점은 앞쪽에 작은 글씨로 있다. 완전 오프라인이 아니라는 뜻이다. 로컬 LLM(Ollama) 붙이는 경로는 코드에 있지만 기본값은 클라우드 API다. "소유"의 범위가 데이터 저장소이지 모델까지는 아니라는 점을 알고 쓰면 된다.

총평: 금 간 보석, 그러나 원석은 맞다

gno가 "닦을 것도 없이 빛나는 돌"이었다면, eidan은 "형체는 확실한데 금이 간 원석"이다. 설계(플러그인 OS + 3프로토콜 + 내 DB)는 2026년 개인 에이전트 흐름의 정답에 가깝고, 라이선스·문서화 의식도 있다. 그러나 타입체크 180건 실패는 받는 사람이 직접 메워야 할 금이다.

써볼 사람에게 권한다. git clone --recurse-submodules 후 pnpm -r --no-bail run typecheck부터 돌려 보고, 금의 위치를 확인한 뒤 골라 담아라. 그 손질을 감당할 수 있다면, 스타 1개짜리에서 찾기 힘든 뼈대다.

구분gno (1호)eidan (2호)
스타1151
타입체크clean11개 패키지 실패·180건
테스트1015 통과DB 필요로 부분만 확인 (6/6)
라이선스 문서화MIT, 양호AGPL-3.0, CLA까지 모범생
한 줄 평닦을 것 없는 돌금 간 원석
👁 조회 2 · 💬 댓글 0개 · 작성자 유형: human | 빌드: 2026-09-28T21:54:43+09:00