오픈소스 개인 AI 에이전트부터 코덱스 업무 사례까지, 프로덕트 메이커가 볼 만한 흐름

OpenHuman이 노리는 지점

• OpenHuman은 “내 업무 도구를 한 번에 연결하는 개인 AI 에이전트”를 목표로 하는 오픈소스 프로젝트임

  • 5월 12일 출시 뒤 일주일 만에 GitHub 트렌딩 1위, Product Hunt 일간·주간·월간 1위를 모두 찍었음
  • 출시 2주차 기준 GitHub 스타가 29,000개를 넘겼다는 점도 꽤 강한 신호임

• 문제의식은 단순함 — AI 에이전트를 업무에 붙이려면 아직 너무 귀찮다는 것

  • Gmail, Notion, GitHub, Slack 같은 도구가 흩어져 있어서 사람이 매번 컨텍스트를 옮겨 붙여야 함
  • 어제 한 대화를 기억하지 못해 오늘 또 처음부터 설명해야 하는 경우도 많음
  • 도구 호출 결과와 긴 스크랩 데이터가 모델에 그대로 들어가면 토큰 비용과 지연도 빠르게 쌓임

• OpenHuman의 핵심 기능은 118개 이상 도구 연결, 장기 기억, 토큰 압축, 로컬 우선 구조로 정리됨

  • Gmail, Notion, GitHub, Slack, Stripe, Calendar, Drive, Linear, Jira 등을 OAuth로 연결하고 20분마다 새 데이터를 자동으로 가져옴
  • 모든 데이터를 3,000토큰 이하 마크다운 청크로 나눈 뒤 Memory Tree로 묶고, 로컬 SQLite와 Obsidian 호환 vault에 저장함
  • TokenJuice는 HTML을 마크다운으로 바꾸고 긴 URL과 장황한 출력을 줄여 비용과 응답 지연을 최대 80%까지 줄인다고 주장함

• 재밌는 디테일도 있음
  • 데스크톱 마스코트가 떠 있다가 말하고 주변 작업에 반응함
  • Google Meet에 실제 참여자로 들어가 STT, ElevenLabs 기반 TTS, 립싱크를 조합할 수 있음
  • agentmemory 백엔드를 켜면 클로드 코드, 커서, 코덱스, OpenCode 같은 다른 에이전트와 같은 메모리 저장소를 공유할 수 있음

댄 쉬퍼의 예측에서 건질 부분

• 댄 쉬퍼는 앞으로 일이 코덱스나 클로드 코워크 같은 환경 안에서 이뤄질 수 있다고 봄

  • 이메일, 문서, 리서치가 각각의 SaaS 안에 갇히는 게 아니라 AI 작업 환경 안에서 열리는 그림임
  • 예전에는 SaaS 안에 AI가 들어갔다면, 이제는 SaaS가 AI 작업 공간 안의 브라우저처럼 들어온다는 관점임

• “자동화는 거짓말이다”라는 말이 제일 현실적임

  • 그의 마크다운 에디터 Proof는 vibe 코딩으로 만든 뒤 출시 다음 날부터 10분마다 다운됐고, 본인은 잠을 못 자고 고치다 팔꿈치 활액낭염까지 겪었다고 함
  • 시니어 엔지니어 벤치마크에서는 GPT 5.5와 Opus 4.7 plan 조합이 100점 만점 약 60점, 인간 시니어 엔지니어는 80~90점으로 나왔다고 함
  • 결론은 AI가 자동화를 잘해도 “무엇을 풀어야 하는지 정의하는 일”은 여전히 사람이 해야 한다는 것임

• PM과 디자이너의 역할이 오히려 세질 수 있다는 예측도 흥미로움

  • Every의 Spiral 책임자 Marcus는 PM인데, 커서와 클로드 코드를 익힌 뒤 팀 누구보다 빠르게 제품을 출시한다고 함
  • 디자이너도 더 이상 디자인만 넘기는 게 아니라 직접 PR을 만들 수 있고, AI 결과물이 비슷해질수록 안목과 인터랙션 감각이 차별화 포인트가 됨

• Forward Deployed Engineer도 새 역할로 제시됨

  • 원래 고객 현장에 붙어 기술·비즈니스 문제를 푸는 엔지니어를 뜻하는데, 여기서는 사내 AI 에이전트를 운영하는 역할로 쓰임
  • Every의 Nitesh는 내부 에이전트 Claudy와 Slack에서 계속 대화하며 “왜 이런 멍청한 짓을 했는지”를 고치고 운영한다고 함

코덱스 활용 사례가 말하는 방향

• 오픈AI 코덱스 활용 사례가 12개에서 52개로 늘어난 건 메시지가 꽤 명확함

  • 코딩 보조 도구를 넘어 PRD 초안, 현금흐름 예측, 회의 후속 작업까지 처리하는 전사 협업 도구로 넓히려는 흐름임
  • 산출물이 코드뿐 아니라 문서, 엑셀, 이메일 초안, CRM 업데이트로 확장됨

• PM 업무에서는 PRD 초안 작성이 대표 사례임

  • Linear 프로젝트, Slack 논의, Notion 문서, 회의 노트, 리서치 자료 위치를 알려주면 코덱스가 검토 가능한 PRD로 묶어줌
  • 문제 정의, 사용자, 요구사항, UX, 기술 고려사항, 출시 계획, 일정, 결정사항, 미해결 질문 같은 항목을 먼저 정해두는 게 핵심임
  • 출처 정리표를 먼저 확인하고 요구사항을 다듬는 흐름이 권장됨

• 디자인 쪽에서는 Figma MCP 연결이 실무적으로 큼

  • 코덱스가 특정 디자인 노드의 컨텍스트, 변수, 에셋, 변형을 가져와 기존 코드베이스의 디자인 시스템에 맞춰 구현함
  • Playwright로 결과 화면을 Figma와 비교하면서 반응형 동작과 인터랙션 차이를 맞추는 식임

• 재무와 영업 업무까지 들어온 것도 포인트임

  • 현금흐름 예측에서는 기초 현금, 예상 수입, 인건비, 외주 지급금, 부채, 세금, 자본 지출 등을 넣으면 수식이 포함된 편집 가능한 엑셀을 만들어줌
  • Zoom 회의 녹취록과 요약을 넣으면 핵심 내용, 리스크, 결정사항, 액션 아이템, 후속 이메일, CRM 업데이트 초안을 만들어줌
  • 실제 전송은 사람이 검토한 뒤 하는 구조라, 자동 실행보다 검토 가능한 초안 생성에 가깝게 설계돼 있음

• /goal 같은 장기 자율 실행은 개발자에게 특히 익숙한 방향임
  • 목표, 종료 조건, 출발 자료, 진행 확인 방법을 주면 코덱스가 조건이 충족될 때까지 계속 작업함
  • 데이터베이스 마이그레이션, 큰 리팩토링, 배포 재시도 루프, 실험, 프로토타입처럼 체크포인트가 있는 작업에 맞음

---

기술 맥락

• OpenHuman과 코덱스 사례가 가리키는 선택은 AI를 단일 챗봇으로 둘지, 업무 도구들을 연결하는 실행 레이어로 올릴지예요. 후자는 훨씬 강력하지만 Gmail, Slack, GitHub, Notion 권한이 한곳에 모이기 때문에 보안과 감사 흐름이 같이 필요해요.

• Memory Tree 같은 구조가 중요한 이유는 에이전트가 매번 긴 컨텍스트를 다시 읽으면 비용과 지연이 커지기 때문이에요. 데이터를 작은 마크다운 청크와 계층 요약으로 저장해두면, 필요한 맥락만 꺼내 쓰는 방식으로 바꿀 수 있어요.

• TokenJuice가 노리는 문제도 비슷해요. 도구 호출 결과나 HTML 원문을 그대로 모델에 넣으면 토큰이 낭비되니, 모델에 들어가기 전에 압축하고 정리해서 비용과 응답 시간을 줄이려는 거예요.

• 코덱스의 52개 사례에서 반복되는 패턴은 자동 완료가 아니라 검토 가능한 산출물이에요. PRD, 엑셀, 코드 PR, 이메일 초안처럼 사람이 확인하고 수정할 수 있는 형태로 멈추기 때문에, 완전 자동화보다 실무 도입 장벽이 낮아요.

• 그래서 앞으로 필요한 역량은 프롬프트만 잘 쓰는 게 아니라 목표, 종료 조건, 출처, 검증 방법을 잘 정의하는 쪽에 가까워요. AI가 일을 많이 할수록 사람이 문제를 잘게 나누고 결과를 판정하는 능력이 더 중요해져요.