My Jev Pi Durable Agent CURATES News: HYPE, FACT, or SIGNAL

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Jev와 Pi Durable로 뉴스를 수집·분류하는 상시 에이전트를 만들고, 과장·사실·실행 가능한 신호를 구분해 사용자 피드백으로 선별 기준을 조정한다.

📌 핵심 요점

1. 발표자는 뉴스를 과장, 사실, 신호로 나눈다. 사실이라도 당장 활용할 수 없다면 신호와 다르며, 신호의 기준은 사용자가 실제로 행동할 수 있는 정보인지에 있다.
2. 선제적 에이전트는 사용자의 입력을 기다리기 전에 일한다. 영상에서는 이를 지속형 에이전트에 실행 트리거와 샌드박스를 결합한 시스템으로 설명한다.
3. SQLite와 Pi Durable을 기반으로 에이전트를 API 뒤에 두고, 브라우저·터미널·CLI·cron이 접근하도록 구성한다. 클라이언트를 분리해도 같은 에이전트 상태를 확인할 수 있다.
4. 뉴스 처리 과정은 수집, 선별, 중복 제거, 순위 산정, 표시로 이어진다. Jev는 여러 단계의 분류와 필터링에 쓰이며, 더 비싼 언어 모델 호출을 줄이는 관문 역할도 한다.
5. 추천·비추천과 키워드 가중치 조정이 개인화의 핵심이다. 사용자는 계속 지시하기보다 결과를 확인하고 기준을 고치는 방식으로 직접 개입에서 간헐적 감독, 자율 실행으로 이동한다.

🧩 배경과 문제 정의

발표자는 AI 시대에 정보량과 과장이 늘면서 엔지니어의 시간과 주의력이 소모되는 문제를 제기한다. 목표는 개인에게 중요한 뉴스를 먼저 찾아 선별하고, 사용자가 준비됐을 때 결과를 확인하도록 만드는 것이다.

이를 위해 과장, 사실, 실행 가능한 신호를 구분하는 판단 기준을 세우고 지속형 뉴스 에이전트에 반영한다. 사용자는 초기 설계와 피드백에 참여하며, 이후에는 간헐적으로 감독하는 방식으로 전환한다. 영상은 제품 시연, 계층별 아키텍처, 뉴스 처리 과정, 개인화 기능을 설명하고 마지막에는 관련 교육 상품을 안내한다.

🕒 시간순 섹션별 상세정리

1. 정보 과잉과 선제적 에이전트의 역할

• 발표자는 클릭을 유도하는 정보와 과장이 늘어나는 상황에서 엔지니어의 시간과 주의력을 보호해야 한다고 드러낸다. 뉴스에서 과장·사실·신호를 가리는 도구로 선제적 에이전트를 보여준다. [00:26]
• 사람이 매번 개입하는 단계에서 가까이서 감독하는 단계, 완전히 벗어나는 단계로 이동하는 틀을 제시한다. 에이전트가 먼저 일한 뒤 사용자의 확인과 피드백을 기다리는 방식이다. [01:21]

2. 브라우저와 터미널이 연결된 지속형 에이전트

• 제품 화면은 대화형 에이전트와 생성형 UI로 구성된다. 브라우저는 M4 Mac mini에서 동작하는 에이전트에 접속하는 분리된 클라이언트이며, 터미널에서도 같은 상태를 확인한다. [02:38]
• cron 주기마다 사용자의 입력 없이 작업이 실행된다. 발표자는 선제적 에이전트를 지속형 에이전트, 트리거, 샌드박스의 결합으로 보여준다. [03:07]
• 상태는 SQLite 같은 데이터베이스에 저장하고 실제 에이전트는 API 뒤에서 동작하게 한다. 사용자가 보는 화면은 이 시스템에 접근하는 얇은 인터페이스다. [03:25]

3. 호출 비용을 줄이는 선별과 설계의 중요성

• 발표자는 하루 이상 뉴스를 계속 수집·필터링했으며, Jev를 앞단에 배치해 더 비싼 언어 모델 호출을 선별한다고 보여준다. 저렴한 모델도 토큰과 연산 비용을 쓰기 때문이다. [04:17]
• 코드 생성과 복제가 쉬워지는 상황에서 개발자의 취향, 판단, 시스템 설계 능력이 중요하다고 주장한다. 뉴스 에이전트가 무엇을 보여줄지에도 이러한 선택이 반영된다. [05:12]

4. 과장·사실·신호를 나누는 기준

• 과장은 근거가 부족한 흥분과 관심의 증가로 보여준다. 사실은 객관적으로 참인 정보지만, 그 자체로 사용자가 당장 활용할 수 있다는 뜻은 아니다. [05:45]
• 발표자는 수학 증명 공개와 새 모델의 사용 가능 소식을 비교한다. 자신의 업무에 즉시 적용할 수 있는 정보를 신호로 보고, 이를 뉴스 선별 기준으로 삼는다. [06:26]
• 이러한 판단 기준과 제품 목표를 먼저 정한 뒤, 그 결과를 만드는 아키텍처를 설계해야 한다고 보여준다. [06:56]

5. cron과 API로 구동하는 클라이언트·서버 구조

• cron이 API를 호출하고, 뉴스 데스크 역할의 Pi Durable Agent가 지속형 작업을 수행한다. 로컬 Mac mini와 클라우드 샌드박스에서 별도 피드를 운영하는 사례를 보여준다. [07:48]
• 사용자가 에이전트에 요청할 뿐 아니라 에이전트도 사용자에게 취향을 묻는 양방향 프롬프트 방식을 보여준다. 환경별 피드는 서로 다른 설정과 관심사를 가질 수 있다. [08:04]
• 브라우저, 터미널 UI, CLI가 분리된 클라이언트로 연결된다. 전체 시스템은 여러 구성 요소를 분리한 클라이언트·서버 애플리케이션으로 드러난다. [08:26]

6. 재사용 가능한 계층과 엔지니어의 역할

• SQLite, Pi Durable, 맞춤형 에이전트, API, Jev, SDK로 이어지는 계층을 제시한다. 브라우저·터미널·cron·CLI가 SDK를 사용하며 Jev는 분류·필터링·순위 산정을 담당한다. [08:59]
• 발표자는 소프트웨어 엔지니어링이 끝났다는 주장에 동의하지 않는다. 적절한 아키텍처를 선택하고 질문을 던지며 모델을 이끄는 실무자의 역할을 강조한다. [09:55]
• 매분 실행되는 수집 작업 중에는 새 소식이 없는 경우도 나타난다. 발표자는 이러한 반복 실행을 가능하게 하는 기반으로 계층별 구성을 다시 짚어 본다. [10:05]

7. 뉴스 처리 흐름과 중복·주장 확인

• 뉴스 수집 작업은 수집, 선별, 중복 제거, 순위 산정으로 계속된다. 후보가 반환되면 지속형 에이전트가 순위를 바탕으로 실제 표시할 내용을 정한다. [10:25]
• Jev로 관련성, 중복 여부, 같은 사건인지 등을 분류한다. 콘텐츠 해시를 먼저 사용하고 해시만으로 처리하기 어려운 중복에는 추가 분류를 적용하라고 보여준다. [11:02]
• 주장 조사 단계에서는 여러 출처를 모아 내용이 겹치는지 살피고, 이후 결과를 화면에 제시한다. [11:16]

8. 직접 개입에서 간헐적 감독과 자율 실행으로

• 발표자는 직접 대화하며 작업하는 단계에서 간헐적으로 감독하는 단계, 자율적으로 돌아가는 단계로 이동하는 것을 에이전트 엔지니어링 역량의 기준으로 제시한다. [11:39]
• 실행 횟수나 토큰 사용 자체보다 유용한 일을 지속적으로 수행하는지가 중요하다고 드러낸다. 자신을 대신해 상시 동작하는 작업 흐름을 늘리는 관점이다. [12:15]
• 이 틀을 뉴스 에이전트에 연결한 뒤 아키텍처 설명에서 실제 제품 기능 시연으로 넘어간다. [12:24]

9. 사용자 평가로 만드는 데이터 피드백

• 사용자의 입력과 평가를 코드·에이전트가 받아 제품을 개선하는 데이터 플라이휠을 강조한다. 뉴스 카드의 추천·비추천을 그 출발점으로 보여준다. [13:03]
• 새 모델 소식의 원문과 공식 발표를 열어 확인한다. 발표자는 이 소식을 자신이 관심을 갖는 신호로 보고, 분류기가 사실·신호·과장 점수를 함께 부여한 결과를 보여준다. [13:45]
• 추천을 통해 해당 정보가 중요하다는 피드백을 순위 산정에 반영할 수 있다고 보여준다. [13:53]

10. 키워드와 출처 가중치로 조정하는 개인화

• 발표자가 Gemini의 가중치를 높여 달라고 요청하자 메시지가 대기열에 들어가고, 에이전트가 취향 설정을 읽어 기존 키워드 가중치를 1.2에서 1.3으로 올린다. [14:49]
• 개인 취향에 맞는 고신호 피드는 사용자와 지속형 에이전트 사이의 피드백으로 만들어진다고 보여준다. 관심이 낮은 은행 감독 관련 뉴스는 비추천으로 처리한다. [15:23]
• 키워드뿐 아니라 뉴스 출처의 가중치도 조정하기 시작했다고 밝히며, 자신이 참고하는 여러 기술 정보 출처를 보여준다. [15:43]

11. 뉴스 업무 전용 도구와 반복 실행

• 제품을 구별할 수 있는 고유한 행동을 에이전트에 부여해야 한다고 강조한다. 뉴스 수집, 후보 조회, 항목 읽기, 웹 검색, URL 수집, 조사, Jev 분류, 뉴스 표시, 취향 질문 등을 도구로 제시한다. [16:20]
• 초기에는 사람이 개입해 도구와 시스템을 만들고, 이후 그 시스템이 더 적은 주의력으로 일하게 하는 것이 목표라고 보여준다. 매분 실행하며 최대 일곱 개의 카드를 대상으로 Jev 순위 산정을 수행하는 설정도 보여준다. [16:55]
• Pi Durable과 Pi 에이전트를 사용하는 이유로 직접 통제하고 맞춤화하며 확장할 수 있다는 점을 든다. [17:16]

12. 감독 단계를 거치는 전환과 초기 구현의 한계

• 지속형 에이전트가 직접 개입과 완전 자율 실행 사이의 중간 단계를 제공한다고 보여준다. 유용한 시스템을 만들려면 단계가 높아질수록 엔지니어링 능력도 더 필요하다고 주장한다. [18:25]
• 뉴스 에이전트와 이전의 온콜 사고 대응 에이전트를 구체적 사례로 묶는다. 실행 내역과 추적 기록, 키워드 설정, 로컬·클라우드 실행 환경을 다시 보여준다. [19:05]
• 공개할 시스템을 각자 설정해 사용하라고 권하며 자신의 설정은 제공하지 않겠다고 드러낸다. 초기 구현을 계속 개선할 예정이며, 에이전트는 먼저 일한 뒤 피드백을 기다린다는 메시지를 반복한다. [19:44]

13. 교육 상품 안내와 운영 비용 관리

• 중급·고급 엔지니어 대상 교육 상품을 소개하고 기존 교육 참여자 할인, 사전 등록, 몇 주 뒤 사전 판매, 11월 말 출시 계획을 안내한다. 일정은 촬영 시점의 발언이다. [20:25]
• 뉴스 에이전트에 API 제공자와 링크를 추가하고 개인 목적에 맞게 조정하라고 권한다. 현재 피드에도 개선할 부분이 많다고 인정한다. [21:00]
• 비용이 거의 움직이지 않았다고 말하면서 시스템의 토큰 경제성을 주의 깊게 살핀다고 보여준다. Jev와 저렴한 언어 모델을 비용 관리의 주요 구성 요소로 제시한다. [21:14]

14. 마지막 동기화 확인과 피드백 중심 운영

• 터미널에서 마지막으로 추가한 뉴스를 묻고, 수집 작업 뒤 대기 중이던 요청이 처리되는 모습을 보여준다. 브라우저와 같은 에이전트에 연결된 상태를 다시 확인한다. [21:33]
• Anthropic의 코드 병합 증가 소식이 주로 과장으로 분류된 결과에 발표자가 동의하며 추천한다. 이 평가는 분류기와 발표자의 판단으로 드러난다. [21:46]
• 백그라운드에서 일하고 사용자 피드백을 기다리는 에이전트, 그리고 그 피드백이 만드는 데이터 플라이휠을 재차 강조한다. 관련 영상과 상품을 안내하며 신호에 집중하고 계속 만들라는 말로 마무리한다. [22:28]

🧾 결론

• 이 사례의 중심은 뉴스 요약 자체보다 사용자가 자리를 비운 동안에도 수집과 선별이 진행되는 운영 구조다.
• 좋은 신호를 정의하는 일에는 사용자의 목적과 판단이 필요하다. 영상에서는 이를 관심 키워드, 출처 가중치, 평가 피드백으로 시스템에 반영한다.
• 발표자는 에이전트 활용 역량을 유용한 작업이 지속적으로 수행되도록 설계하는 능력과 연결한다. 아키텍처, 도구 구성, 실행 비용 관리가 함께 요구된다.
• 영상의 구현은 계속 조정 중인 초기 사례다. 발표자도 알고리즘과 설정을 더 개선할 계획이라고 밝힌다.

📈 투자·시사 포인트

• 에이전트 제품의 차별화 요소로 개인화 기준, 업무 전용 도구, 지속 실행 구조를 살펴볼 수 있다. 영상은 이러한 설계에 개발자의 판단이 반영된다고 강조한다.
• 상시 실행 시스템의 경제성은 호출 단가와 실행 빈도에 영향을 받는다. 저렴한 분류기로 후보를 거른 뒤 언어 모델을 사용하는 구성이 비용 관리의 핵심 사례로 제시된다.
• 사용자 평가가 다음 추천에 반영되는 피드백 구조는 제품 개선의 기반이 된다. 다만 영상에는 이 구조가 추천 품질을 얼마나 높였는지 보여주는 정량 결과가 없다.
• 뉴스 에이전트와 온콜 대응 에이전트를 같은 지속형 구조의 사례로 제시한다. 업무별 도구와 판단 기준을 바꾸면서 기반 구조를 재사용할 수 있다는 시사점이 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 에이전트가 현재 업무의 80% 이상을 자율 수행할 수 있다는 발언은 발표자의 주장이다. 영상에는 이를 뒷받침하는 업무별 평가나 비교 실험이 제시되지 않는다.
• Jev의 저비용·고속·신뢰성, 호출당 0.5초 미만 처리, 시스템 비용이 거의 늘지 않았다는 설명에는 상세 요금표, 처리량, 측정 조건이 없다.
• 과장·사실·신호 점수는 분류기의 판단이다. 여러 출처의 내용이 겹치는지 확인하는 방식도 언급하지만, 그 결과만으로 사실성이 검증됐다고 단정하기는 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 자신의 업무에서 바로 행동으로 옮길 수 있는 정보를 정의하고, 과장·사실·신호의 분류 기준을 적는다.
• 관심 키워드와 뉴스 출처를 선정하고 초기 가중치를 설정한 뒤, 추천·비추천 피드백을 반영해 조정한다.
• 뉴스 처리 흐름을 수집 → 선별 → 중복 제거 → 순위 산정 → 표시로 나누고, 각 단계에 필요한 도구를 정한다.
• 중복 제거에는 콘텐츠 해시를 먼저 적용하고, 같은 사건을 다르게 표현한 기사에는 추가 분류를 적용한다.

❓ 열린 질문

• 개인화된 신호를 어떤 기준으로 평가해야 중요한 소식을 놓치지 않으면서 불필요한 정보를 줄일 수 있을까?
• 키워드와 출처 가중치 조정이 반복될 때 관심 분야 밖의 중요한 정보를 발견할 여지는 어떻게 유지할까?
• 분류기 점수가 낮거나 출처 간 주장이 충돌하면 어떤 조건에서 추가 조사나 사람의 검토를 요청해야 할까?