v0.1에서 v0.5.22까지, 156일, 116개 릴리스. 여기 적은 것은 기능 목록이 아니라 우리가 밟은 함정, 그 대가로 얻은 규칙, 그리고 아직 채우지 못한 공백입니다.
데이터 스냅샷 2026-11-01 · 수치는 sync-facts와 health:arch가 Liri 메인 저장소에서 수집했습니다
타임라인으로 이동2026년 5월 25일, Liri의 첫 버전 v0.1은 실질 커밋 100개와 실제로 동작하는 터미널 AI 비서였습니다.
처음 풀고 싶던 문제는 구체적이었습니다. 대형 모델이 웹 입력창에서 대화하는 데 그치지 않고 터미널에 실제로 앉아 파일을 읽고 명령을 실행하며 코드를 고치게 하는 것. 로컬 모델을 우선한 것은 개인 파일을 다른 사람의 서버로 보내고 싶지 않아서였고, 「보안 내장」을 택한 것은 그것이 API가 아니라 실제 기기를 넘겨받기 때문입니다.
이후 석 달 동안 기능이 하나씩 펼쳐졌습니다: 도구, 메시지 채널 27개, 데스크톱 클라이언트, 음성, 지식 베이스. 8월이 되자 저장소에는 4,000개가 넘는 파일이 있었습니다.
문제가 처음으로 명확히 지적된 것도 그때입니다. 2026년 6월 18일 코드 리뷰에서 LocalHTTPService 7,200줄, ChatManager 3,263줄, 테스트 파일 150개, 소스 파일 3,742개가 확인되었습니다. 두 달 뒤 첫 아키텍처 건전성 점수가 나왔습니다: 10/40, D 등급, 초과 파일 105개 전부 미등록.
그때 깨달았습니다. 프로젝트를 다른 사람이 이어받을 수 있는지는 기능이 얼마나 많은지가 아니라, 함정을 밟은 뒤 어떤 규칙이 자라났는지로 판가름됩니다.
인과 순서로 정렬했으며 달력 순서가 아닙니다 — 시간상 서로 겹칩니다.
↳ 참여 방법 — 새 기능을 추가하려면 app/src 아래에 모듈을 만들고, 커널에 밀어 넣지 마세요.
↳ 참여 방법 — 초과 파일 하나의 분할을 맡아 주세요(아래 참여 방법 참고).
↳ 참여 방법 — CD01–CD07에 따라 「죽은 코드 후보」 하나를 점검해 주세요.
↳ 참여 방법 — 푸시 전에 로컬 게이트(bun run ci)를 한 번 돌리고, 빨간 곳을 고치세요.
↳ 참여 방법 — 커널 경계 밖의 새 기능은 app/src에서 시작하며 커널에 들어갈 필요가 없습니다.
아키텍처를 새로 발명한 것은 아닙니다. 얇은 커널, 서브시스템 경계, 의존 방향, 게이트와 관측성 — 이 조직 방식은 운영체제가 수십 년 쌓아 온 엔지니어링 실천에서 왔습니다. 지난 2년간 공개된 에이전트 설계 패턴과 엔지니어링 가이드 역시 계층, 경계, 상태, 거버넌스, 평가라는 같은 문제군으로 수렴했습니다. 우리는 전자의 방식으로 자신을 제약하고, 후자의 체크리스트로 자체 점검합니다.
운영체제 개념 → Liri 현황
| 개념 | Liri에서의 대응 | 상태 |
|---|---|---|
| 커널 | @openliri/kernel 독립 패키지, 대외에는 얇은 인터페이스만 노출, K01–K08 게이트 | 반영됨 |
| 서브시스템 | 도구 / 채널 / 메모리 / 라우팅 / 샌드박스 / 작업 / 음성 / 데스크톱, 각자 진입점과 경계 보유 | 수렴 중 |
| 드라이버 | 프로바이더 어댑터, 채널 어댑터, 샌드박스 백엔드 6가지 (Landlock / Docker / SSH / PTY / macOS / Windows) | 반영됨 |
| 프로세스와 스케줄링 | 세션 실행, PDCA, Swarm, Cron | 반영됨 |
| 권한 모델 | 5계층 방어 + 승인 4단계 (requested → presented → decided → recorded) | 외부 감사 대기 |
| 관측성과 감사 | 이벤트 로그, 비용 원장, 근거 대장 | 반영됨 |
| 유지관리자(MAINTAINERS) | 아직 없음: 서브시스템 owner와 인수 경로가 없습니다 | 공백 |
공개된 에이전트 설계 패턴과 엔지니어링 가이드에 항목별로 대조했습니다: 21개 패턴 모두 실제 구현이 있지만 그중 3개의 핵심 스위치는 기본적으로 꺼져 있습니다 — 그래서 대외에는 「구현이 있다」고만 하고 「기본으로 동작한다」고는 말하지 않습니다. 엔지니어링의 주된 흐름도 같은 5단계로 자체 점검합니다: 아키텍처, 빌드, 실행, 거버넌스, 튜닝.
owner가 없으면 인수 경로도 없습니다. 가장 운영체제답고, 가장 빠진 부분입니다.
계약 설계안은 있지만 대장 / LoopProfile이 반영되었는지는 확인되지 않았습니다 — 인터페이스 안정성 약속은 아직 확정되지 않았습니다.
리뷰 당시 약 4%; CI에는 20여 개 아키텍처 검사가 있지만 커버리지 임계값은 아직 없습니다.
솔직히 말하면: 아키텍처 건전성은 여전히 D(10/40)이고, 초과 파일 142개 중 141개가 아직 미등록이며, 가장 큰 것은 여전히 chat 모듈입니다(ChatManager는 7,036줄에서 2,570줄로 분할). 커널은 생겼고 경계는 수렴 중이며 유지관리자 제도는 아직 없습니다 — 이것이 「아직 끝나지 않았다」는 뜻입니다.
진입점에서 피드백까지 8개 기능 계층; 엔지니어링 측면에서는 6계층 의존성 게이트(entry > ui > app > service > infra > core)로 강제합니다
매달 한 줄, 아키텍처와 거버넌스 변화만 기록하며 일반 커밋은 넣지 않습니다.
이후의 월간 업데이트도 계속 여기에 추가됩니다.
이 페이지는 결산 보고서가 아니라 초대장입니다. 세 가지 일 모두 사람이 부족합니다.
Domain-first 지식 영역 격리는 설계안이 있고 Phase A/B/C는 미구현입니다; 커널 경계 밖의 기능도 커널에 먼저 들어갈 필요가 없습니다.
작업 맡기초과 파일 142개(141개 미등록)가 분할을 기다리고 있습니다; 테스트 커버리지 임계값도 아직 없습니다.
작업 맡기5계층 방어와 샌드박스 백엔드 6가지는 구현되어 있고 규칙 소스도 확인할 수 있지만, 서드파티 감사는 아직 없습니다. 이것이 우리가 가장 원하는 피드백입니다.
감사 체크리스트 보기진입점: app/src/security, app/src/sandbox, app/src/permission.
취약점 세부 내용은 SECURITY.md에 따라 비공개로 신고하고 공개 이슈를 열지 마세요. 공개 이슈에서는 감사 절차와 범위만 논의합니다.
