프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: OpenHuman - 내 도구 118개를 한 번에 연결하는 오픈소스 개인 AI 에이전트
참고할 것: AI의 역설 - 1년 전 클로드 코드의 부상을 일찍 짚은 Dan Shipper의 12가지 새 예측
적용해볼 것: 코딩 너머로 확장된 코덱스 활용 사례 52선

오픈소스 개인 AI 에이전트 OpenHuman — <출처: openhuman 깃허브>

1. 써볼 것: 내 도구 118개를 한 번에 연결하는 오픈소스 개인 AI 에이전트

AI 에이전트가 매주 새로 등장하지만, 막상 내 작업 환경과 연결해 쓰려 하면 손이 많이 갑니다. 도구마다 따로 로그인하고, 컨텍스트를 매번 새로 알려주고, 잘 안 되면 결국 익숙한 LLM 챗봇으로 돌아오게 되죠. OpenHuman은 그 진입 장벽을 겨냥한 오픈소스 프로젝트입니다. 5월 12일 출시 후 일주일 만에 GitHub 트렌딩 1위, Product Hunt 일, 주, 월간 1위를 모두 차지했고 출시 2주차인 현재 GitHub 스타가 29,000개를 넘겼습니다.

창업자 Steven Enamakel이 직접 밝힌 시작점은 의외로 평범합니다. 아버지를 위해 오픈소스 AI 에이전트를 설치해드리려 했는데 너무 복잡해서 본인이 새로 만들기로 했다는 거죠. 그 출발점이 OpenHuman의 디자인 원칙인, 비기술자도 클릭 몇 번이면 쓸 수 있어야 한다는 것으로 이어집니다.

무슨 문제를 해결해 주나요?

AI 에이전트를 업무에 본격적으로 쓰려 할 때 부딪히는 문제는 보통 세 가지입니다. OpenHuman은 아래 세 문제를 동시에 다루는 오픈소스 프로젝트입니다.

첫째, 도구가 서로 단절돼 있습니다. 메일은 Gmail, 노트는 Notion, 코드는 GitHub, 메시지는 Slack 같은 곳에 흩어져 있는데 에이전트는 그중 하나만 보고 답하니까, 사람이 매번 컨텍스트를 옮겨붙이는 일이 반복됩니다.
둘째, 에이전트가 어제 한 대화를 기억하지 못해서 오늘 또 처음부터 설명해야 하는 경우가 많습니다.
셋째, 토큰 비용과 유지보수 부담이 큽니다. 도구 호출 결과나 긴 스크랩 데이터가 그대로 모델에 들어가면서 비용이 빠르게 쌓이고, 직접 운영하다 보면 SSH로 서버를 만지는 단계까지 가게 됩니다.

어떻게 쓰나요?

설치 방법은 환경에 따라 다릅니다. 공식 README가 권장하는 방식은 네이티브 패키지예요.

# macOS (Homebrew)
brew tap tinyhumansai/openhuman
brew install openhuman

# Linux (Debian/Ubuntu) — 서명된 apt 저장소
# Windows — 서명된 .msi 다운로드 (Releases 페이지)

더 간단한 한 줄짜리 스크립트 설치도 있지만, README가 직접 무결성 검증이 없다고 경고하고 있으니 가능하면 네이티브 패키지 쪽을 쓰는 게 좋겠습니다. 데스크톱 앱은 tinyhumans.ai/openhuman이나 GitHub Releases 페이지에서 직접 다운로드받을 수도 있어요.

OpenHuman의 핵심 기능은 네 가지입니다.

원클릭 OAuth로 118개 이상의 도구 연결
Gmail, Notion, GitHub, Slack, Stripe, Calendar, Drive, Linear, Jira 등 일상에서 쓰는 서비스 대부분이 들어가 있어, 한 번 연결해두면 OpenHuman이 20분마다 자동으로 새 데이터를 가져와 최신 상태로 유지합니다(auto-fetch). 별도 프롬프트나 폴링 작업 없이 백그라운드에서 진행됩니다.
Memory Tree와 Obsidian Wiki
모든 데이터를 3,000 토큰 이하의 마크다운 청크로 정리한 뒤, 계층적 요약 트리로 묶어 로컬 SQLite에 저장합니다. 동시에 같은 청크가 Obsidian 호환 vault에 .md 파일로 저장돼서, 사용자가 직접 열어 보고 편집할 수 있습니다. 이는 Andrej Karpathy(안드레이 카파시)가 제안한 LLM-wiki 워크플로우에서 영감을 받았다고 밝혔습니다.
TokenJuice 토큰 압축
도구 호출 결과, 스크랩 데이터, 이메일 본문, 검색 페이로드가 모델에 도달하기 전에 미리 압축됩니다. HTML을 마크다운으로 변환하고, 긴 URL을 단축하고, 장황한 출력을 요약합니다. 한국어, 일본어처럼 멀티바이트 텍스트는 grapheme 단위로 보존해 깨지지 않게 처리하며, 비용과 응답 지연이 최대 80%까지 줄어든다고 합니다.
로컬 우선, 원하면 클라우드
민감한 데이터는 기기에 머무르고, 모델 라우팅으로 작업 종류에 따라 추론, 빠른 응답, 비전 모델을 자동 배분합니다. Ollama 기반 로컬 모델 옵션도 있어 외부 API 없이 돌리는 것도 가능하죠.

눈에 띄는 디테일들

기능 외에도 몇 가지 디테일이 더 있어 짧게 소개드립니다.

데스크톱에 마스코트가 떠 있다가 말도 하고 주변 작업에 반응하기도 합니다.
사용자가 입력을 멈춘 동안에도 백그라운드에서 사고를 이어갑니다.
Google Meet에 실제 참여자로 합류할 수도 있습니다. 음성 인식(STT), ElevenLabs 기반 음성 출력(TTS), 마스코트 립싱크가 결합된 형태로요. 회의 노트 정리나 후속 작업 위임에 활용할 수 있는 구조입니다.
agentmemory 백엔드 옵션을 켜면 클로드 코드, 커서, 코덱스, OpenCode 같은 다른 에이전트와 동일한 메모리 저장소를 공유할 수 있어요. 한 곳에 정리된 컨텍스트를 여러 도구에서 같이 쓸 수 있습니다.
개인적으로는 마스코트나 회의 참여 같은 부분이 호불호 갈릴 수 있다 싶었는데, OpenHuman이 향하는 방향은 일관되어 보입니다. AI 에이전트를 옆에 있는 동료처럼 느끼게 만들겠다는 디자인 의도가 기능 곳곳에 깔려 있습니다.

누구에게 좋을까요?

AI 에이전트를 작업에 끼워넣어 본 적은 있지만 도구 간 단절 때문에 손을 놓은 사람
ChatGPT나 클로드에 매번 컨텍스트를 붙여넣는 게 답답한 사람
내 데이터는 가능하면 내 기기에 두고 싶은 사람

알아두면 좋을 점

OpenHuman은 출시 2주차의 초기 단계 프로젝트입니다. 80% 토큰 절감 같은 수치는 자기 보고된 값이고, 일부 외부 리뷰에서 install 스크립트 검토를 권장하고 있어요. 메인 기기에 바로 도입하기보다 보조 작업 환경에서 며칠 써본 뒤 판단하는 정도가 적당합니다. 118개 OAuth를 한꺼번에 연결하는 구조 자체가, 굉장히 많은 권한을 한 도구에 모아주는 일이라는 점도 인지하고 시도하는 게 좋습니다. 보안 관점에서 부담을 느끼는 분은 Linear나 GitHub처럼 업무 도구부터 시작하는 것도 한 방법입니다.

OpenHuman: https://github.com/tinyhumansai/openhuman

Lenny's Podcast Dan Shipper — <출처: Lenny's Podcast 유튜브>

2. 참고할 것: 1년 전 클로드 코드의 부상을 일찍 짚은 Dan Shipper의 12가지 새 예측

Lenny Rachitsky의 팟캐스트에 다시 출연한 Dan Shipper(댄 쉬퍼)의 12가지 예측이 5월 24일 공개됐습니다. Dan은 Every(에브리)의 공동창업자 겸 CEO로, Every는 30명 규모의 미디어·소프트웨어 회사입니다. 또 그는, 1년 전 같은 팟캐스트에서 "클로드 코드는 비개발자에게도 강력한 도구인데 사람들이 그걸 놓치고 있다"고 짚은 적이 있죠. 지금 보면 그의 예측은 얼추 들어맞은 것처럼 보입니다. (1년 전 출연 영상) 그래서 이번 새로운 12가지 예측 중, 프로덕트 메이커에게 의미 있어보이는 5가지를 추려보았습니다. 전체 내용이 궁금하신 분들은, 유튜브 영상을 참고 부탁드립니다.

예측 1. 일의 미래는 코덱스 또는 클로드 코워크 안에서

일상 업무 자체가 코덱스나 클로드 코워크 같은 환경 안에서 이뤄지게 된다는 겁니다. 이메일도, 문서도, 리서치도 모두 그 안에서. Dan의 표현대로 작업의 새 "운영체제"가 되는 셈입니다. 기존엔 AI를 SaaS 안에 끼워 넣는 그림이었다면, 이제는 SaaS가 코덱스나 클로드 코워크 안의 브라우저로 열리는 그림으로 바뀐다는 게 핵심입니다. Dan 본인도 원래 클로드 코드를 가장 적극적으로 추천했던 사람인데, 지금은 코덱스를 주력으로 쓴다고 합니다. 다만 더 좋은 게 나오면 또 옮길 거라고 덧붙였죠.

예측 2. 자동화는 거짓말이다

"Automation is a lie. Every agent needs a human." 자동화할 때마다 그 자동화가 잘 돌아가는지 확인하는 사람이 그 위에 필요하다는 의미입니다. Dan이 직접 vibe 코딩으로 만든 Proof라는 마크다운 에디터가 출시 다음 날부터 10분마다 다운됐고, 잠을 못 자고 코딩하다 팔꿈치에 활액낭염까지 왔다고 합니다(본인이 "vibe coder elbow"라고 부름). 거기서 영감을 받아 시니어 엔지니어 벤치마크를 만들었는데, 결과는 이렇습니다.

GPT 5.5와 Opus 4.7 plan 조합: 100점 만점에 약 60점
인간 시니어 엔지니어: 100점 만점에 80~90점

Dan의 결론은 이렇습니다. 벤치마크는 글로 정리할 수 있는 문제에서만 점수를 매길 수 있는데, 어떤 문제를 풀어야 할지 정의하는 일 자체는 사람이 해야 한다는 겁니다. 그래서 AI가 자동화를 더 잘하게 돼도 그는 여전히 사람을 채용한다고 말합니다. Every 직원 규모도 1년 만에 15명에서 30명으로 두 배 커졌죠.

예측 3. PM이 번성한다

Every의 작문 앱 Spiral 책임자 Marcus(마커스)는 본업이 PM입니다. 그는 Axios에서 작문 제품 PM으로 큰 팀을 이끌며 연매출 수천만 달러까지 키운 뒤, 1년 정도 일을 쉬면서 AI에 푹 빠져 커서와 클로드 코드를 익혔다고 합니다. Dan은 그를 "lightly technical"이라고 표현하죠. 이는 직접 코딩하지는 않지만 데이터베이스 마이그레이션 같은 용어를 알고 코드를 보면 이해할 수 있는 수준이라는 뜻입니다.

지금 Marcus는 팀 누구보다 빠르게 제품을 출시하고, 사용자 한 명 한 명의 대화를 직접 보면서 다음 방향을 정합니다. Dan은 강한 프로덕트 감각과 가벼운 기술 이해에 AI 도구가 결합된 이런 사람을 "위험할 정도로 무서운 조합"이라고 표현합니다. 이젠 PM이 다른 사람의 손을 거치지 않고 직접 제품을 만들 수 있게 됐고, Dan은 AI에 푹 빠진 PM이라면 누구에게나 같은 길이 열려 있다고 봅니다.

예측 4. 풀스택 디자이너가 슈퍼히어로가 된다

이전엔 디자이너가 디자인을 넘기면 엔지니어가 "이대로 구현하긴 좀 힘들 것 같은데요" 같은 반응을 보이면서 갭이 생겼는데, 이제는 디자이너가 PR을 직접 만든다는 겁니다.

Dan이 강조하는 건 차별화입니다. AI로 만든 페이지가 다 비슷해지는 시점이 되면, 결국 디자이너의 안목과 인터랙션 감각이 차이를 만들거든요. "AI로 짠 디자인은 보면 바로 AI 디자인 같다"는 게 그의 표현이죠. 이 예측이 맞는지는 미국 채용 시장 데이터로 확인할 수 있는데, 아직 디자이너 채용은 늘지 않고 있다는 게 Lenny의 관찰입니다. 1년쯤 더 지켜봐야 알 수 있을 것 같아요.

예측 5. Forward Deployed Engineer가 새 필수 역할

FDE(Forward Deployed Engineer)는 원래 컨설팅·B2B 솔루션 회사에서 고객 현장에 파견돼 기술·비즈니스 문제를 해결하는 엔지니어를 가리키는 용어입니다. Dan은 이 개념을 빌려와서, 회사 안의 AI 에이전트가 잘 돌아가게 책임지는 엔지니어를 같은 이름으로 부르고 있어요. AI 에이전트를 "고객 현장"처럼 다루면서 문제를 풀어주는 사람이라는 의미죠.

Every의 AI 엔지니어 Nitesh(니테시)가 그 역할인데, 대부분의 시간을 Slack에서 내부 에이전트 Claudy(클로디)와 대화하며 보낸다고 합니다. Claudy는 Every의 컨설팅 업무 전반을 운영하는 에이전트인데, "왜 이런 멍청한 짓을 했어, 이거 고치자" 같은 대화를 계속 주고받는 게 Nitesh의 일이죠. 코드도 짜지만, 본질은 에이전트를 봐주는 일에 가깝습니다. 큰 모델 회사들도 내부에 이런 팀을 두고 운영합니다.

프로덕트 메이커가 가져갈 만한 것

Dan은 "어떻게 살아남느냐"는 질문에 단 하나로 답했어요. "Ride the models." 새 모델이 나올 때마다 내 작업에 직접 시도해 보는 것. 작년에 안 됐던 일이 올해는 될 수도 있으니 계속 "돌을 뒤집어 보는" 자세가 필요하다는 의미입니다. AI를 만드는 사람들도 어떻게 써야 잘 쓰는지 다 알지 못합니다. 진짜 사용자가 새 모델을 자기 일에 적용하면서 발견하는 영역이 따로 있고, 한국에서 일하는 프로덕트 메이커가 모델을 자기 맥락에 끼워 넣는 시도 자체가 일종의 발견이 됩니다.

Lenny's Podcast 유튜브: The AI paradox: More automation, more humans, more work | Dan Shipper

3. 적용해볼 것: 코딩 너머로 확장된 코덱스 활용 사례 52선

오픈AI 개발자 문서에는 코덱스로 어떤 작업을 할 수 있는지 보여주는 활용 사례 페이지가 있습니다. 최근 이 페이지가 12개에서 52개로 대폭 늘었어요. PRD 초안 작성, 현금흐름 예측, 회의 후속 작업까지 추가되면서, 코덱스를 전사 협업 도구로 넓히려는 오픈AI의 의도가 읽힙니다. 52개를 다 보긴 부담스러우니, 이 소식 역시 프로덕트 메이커에게 의미 있는 5개를 골라보았습니다.

사례 1. PRD 초안 작성하기 (PM)

PRD(제품 요구사항 문서)를 쓸 때 PM은 보통 자료가 여기저기 흩어져 있는 상황을 마주합니다. Linear 프로젝트 정보, Slack 채널의 논의, Notion 문서, 회의 노트, 리서치 자료 같은 것들이죠. 이 자료들의 위치를 코덱스에 알려주고 PRD 초안을 요청하면, 흩어진 정보를 모아 검토 가능한 PRD로 정리해줍니다.

이를 위해선 먼저 PRD에 어떤 항목이 들어갈지 코덱스에 알려줘야 합니다. 문제 정의, 사용자, 요구사항, UX, 기술 고려사항, 출시 계획, 일정, 결정사항, 미해결 질문처럼 항목을 미리 정해주면 코덱스가 그 형식에 맞춰 채워줍니다. 권장 작업 순서는, 코덱스가 어떤 자료에서 무엇을 가져왔는지 보여주는 출처 정리표를 먼저 확인하는 것입니다. 그다음 요구사항과 미해결 질문을 다듬어가면 됩니다. 신뢰할 수 있는 PRD를 만들려면 출처 추적이 필수니까요.

사례 2. Figma 디자인을 코드로 전환하기 (디자인)

Figma의 MCP 서버를 코덱스에 연결하면, 코덱스가 특정 디자인 노드의 컨텍스트, 변수, 에셋, 디자인 변형을 가져옵니다. 그다음 기존 코드베이스의 디자인 시스템에 맞춰 코드로 옮겨줍니다.

권장 순서는 디자인 컨텍스트 가져오기, 메타데이터 확인, 스크린샷 확보입니다. 구조와 참고 자료를 먼저 확보하고 구현에 들어가는 방식이에요. Playwright(브라우저 자동화 도구)로 결과 화면을 Figma 디자인과 비교하면서 반응형 동작과 인터랙션 차이를 반복해서 맞춰갑니다. 이 작업의 핵심은 이미 만들어진 디자인 시스템에 맞춰 번역하는 것입니다.

사례 3. 현금흐름 예측하기 (재무)

코덱스가 수식이 들어간 엑셀 파일(.xlsx)을 직접 만들어줍니다.

코덱스에 입력할 데이터는 기초 현금, 예상 수입, 인건비, 외주 지급금, 부채, 세금, 자본 지출, 운전자본, 그리고 각 항목의 발생 시점입니다. 결과로 받는 건 편집 가능한 현금흐름 예측 엑셀이죠. 요약 탭에는 현금이 부족해지는 시점이 언제인지, 그리고 어떤 입력값 때문에 그 시점이 생기는지가 정리돼 표시됩니다.

생성된 엑셀을 코덱스 안에서 그대로 열어 수식, 시나리오, 가정을 검토하고 수정할 수도 있습니다. 같은 대화창에서 가정을 바꿔가며 시나리오를 비교해볼 수도 있고요. 코덱스가 코딩 도구를 넘어 재무 업무까지 다룬다는 오픈AI의 메시지가 가장 잘 드러나는 사례입니다.

사례 4. 회의를 후속 작업으로 전환하기 (영업, CS)

Zoom 회의 녹취록과 자동 요약을 코덱스에 넣으면, 고객 미팅 후 후속 작업을 만들어줍니다. 코덱스가 핵심 내용, 리스크, 기회, 결정사항, 액션 아이템을 정리한 뒤 후속 이메일, 어카운트 플랜, CRM 업데이트, Slack 알림 초안까지 만들어주는 거죠. 물론 실제 전송은 사용자가 검토한 뒤에 합니다. 코덱스는 자동 발송하지 않고 초안 단계에서 멈추고요. 영업이나 CS 팀이 미팅 직후 20분쯤 들여 정리하던 작업을 검토 단계로 줄여줍니다. Zoom, Gmail, Slack, Google Docs, CRM을 함께 연결하면 효과가 더 커집니다.

사례 5. 목표 따라가기 - /goal (장기 자율 실행)

앞 네 가지가 코덱스와 사람이 주고받으면서 진행하는 작업이라면, 이건 코덱스가 종료 조건까지 자율적으로 작업하는 방식입니다. /goal 명령어를 쓰면 코덱스가 한 번 응답하고 멈추는 대신, 미리 정해둔 종료 조건이 충족될 때까지 작업을 계속 이어갑니다.

코덱스에 명확하게 알려줘야 할 건 네 가지입니다.

목표: 무엇을 달성할 것인가
종료 조건: 어떤 조건이 충족되면 끝나는가
출발 자료: 먼저 읽어야 할 파일, 문서, 로그, 계획
진행 확인 방법: 매 체크포인트에서 진척을 증명할 명령어나 산출물

데이터베이스 마이그레이션, 큰 코드 리팩토링, 배포 재시도 루프, 실험, 프로토타입처럼 체크포인트 단위로 독립적으로 진행할 수 있는 작업에 적합합니다. 몇 시간 동안 코덱스가 알아서 돌아가는 동안 사람은 다른 일을 할 수 있어요.

다섯 사례의 공통점

첫째, 여러 출처에서 자료를 모읍니다. PRD는 Linear와 Slack과 Notion에서, 회의 후속은 Zoom과 Gmail과 CRM에서, 디자인은 Figma에서. 코덱스가 일종의 허브 역할을 하면서 흩어진 출처를 묶어주는 셈이에요.
둘째, 산출물이 항상 사람이 검토할 수 있는 형태로 나옵니다. PRD 문서, 엑셀, 코드 PR, 이메일 초안. 코덱스는 결과를 만들어내고 멈추고, 최종 결정은 사람이 합니다.
셋째, 같은 대화창에서 후속 작업을 이어갈 수 있습니다. 한 번 만든 PRD에 새 자료를 더해 다듬거나, 현금흐름 모델의 가정을 바꿔 시나리오를 추가하는 식이에요. 한 번의 응답으로 끝나지 않고 같은 맥락에서 계속 협업이 이어집니다.

Codex 활용 사례 52선 전체 보기: https://developers.openai.com/codex/use-cases

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정과 좋아요를 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!