7년 동안 화면을 만들었습니다. 이제, 화면을 움직이는 지능을 만듭니다.

문제

AI 에이전트는 처음 보는 화면 앞에서 헤맵니다. 스크린샷은 토큰을 쏟아붓고, DOM 스캔은 페이지가 바뀔 때마다 어긋납니다. 사내 ML 플랫폼을 아무리 교육해도 “사용법을 모르겠다”는 말이 돌아오던 시기였습니다.

판단

화면을 더 잘 읽게 만드는 대신, 화면이 스스로를 설명하게 만들었습니다. 개발자가 조작 가능한 지점을 어노테이션으로 선언하면 AI는 그 계약만 읽습니다. 적용 범위를 ‘자기 앱’으로 좁히는 대신, 정밀도와 토큰 효율을 얻는 트레이드오프입니다.

증거

54회 비교 실험 · 헤맴 지표 0.06 vs 0.39 · 실패 조건(반복 작업)까지 기록해 재설계에 반영 · npm 배포, 테스트 135개

문제

AI는 유능하지만, 매일 처음 만난 사람처럼 굴었습니다. 도구를 바꿀 때마다 맥락은 끊기고, 같은 설명을 반복해야 했습니다.

판단

기억을 도구 밖으로 꺼냈습니다. 에이전트 기억 서버(Honcho)를 셀프호스팅하고, 모든 AI 도구가 하나의 기억을 읽고 쓰도록 수집 파이프라인과 정책(MemoryPolicy)을 설계했습니다. 어떤 도구를 쓰든, 나는 같은 사람으로 기억됩니다.

증거

• 한 달의 공백 후, 기억에서 프로젝트 18개를 복원
• 연결된 도구 — Claude · Codex · Gemini · Hermes, 하나의 기억으로
• 그리고 지금 읽고 있는 이 전시의 원고 역시, 이 기억 시스템이 회상해낸 것입니다

문제

5GB 학습 데이터를 올리면 서버가 죽었습니다. 서버 메모리 할당은 5GB, OOM은 반복됐습니다. MLOps 플랫폼에서 업로드는 모든 것의 입구였습니다.

판단

1차 스트리밍 전환은 네트워크 백프레셔 누적으로 실패했습니다. 실패를 기록하고, 보안 정책(Presigned URL 불가)을 전제로 청크 분할–서버 병합 구조로 재설계했습니다. 화려한 동시성보다 단일 업로드의 확실한 안정을 택했습니다.

증거

10GB+ 파일 안정 업로드 · OOM 재발 구간 제거 · 라온피플, 이미지 기반 MLOps 플랫폼

문제

LLM의 대답은 본질적으로 느립니다. 챗봇 서비스에서 ‘기다림을 어떻게 설계할 것인가’가 화면의 일이 되었습니다.

판단

SSE 스트리밍으로 문장이 도착하는 즉시 흐르게 하고, Markdown을 실시간으로 렌더링했습니다. 100개가 넘는 페르소나를 오가는 사용 패턴을 관찰해 캐싱 계층을 다시 설계했습니다.

증거

EC2 → S3 + CloudFront 전환 · 튜닙, LLM 챗봇 ‘디어메이트’ · 감소 폭이 클수록 좋은 지표입니다

문제

에이전트는 늘어나는데, 누가 무엇을 왜 하는지는 보이지 않습니다. 통제는 금지에서 시작되지 않습니다. 가시성에서 시작됩니다.

판단

실행을 캔버스 위에 올렸습니다(numen) — 하네스와 모델을 노드로 잇고, 줌 레벨에 따라 라이브 터미널이 살아나는 관측 가능한 오케스트레이션. 그 아래에는 회상을 닮은 기억 엔진(neuromem) — 활성화 확산과 헤비안 가소성을 Rust로 구현했습니다. AI에게 경로를 주지 않습니다. 목적지와 울타리, 통과 기준을 줍니다.

증거

• numen — 캔버스 · 라이브 터미널(xterm/WebGL) · LOD 렌더링, 1단계 빌드 완료
• neuromem — Rust 엔진, 엔진·제품 계약 테스트 11개 통과
• 이 두 개의 궤도는 아직 그려지는 중입니다