fa
Feedback
언제 일일이 손으로 다하냐

언제 일일이 손으로 다하냐

رفتن به کانال در Telegram

인사이트 없음.

نمایش بیشتر
کشور مشخص نشده استدسته بندی مشخص نشده است
370
مشترکین
اطلاعاتی وجود ندارد24 ساعت
اطلاعاتی وجود ندارد7 روز
-530 روز
آرشیو پست ها
수빈님의 글을 보니 최근에 고민했던 내용이랑 겹치는 부분이 많네요. 이전 Trinity를 개발하면서 처음엔 “LLM judge를 잘 쓰면 되겠지”라는 생각으로 접근했는데, 실제로 돌려보니 꽤 자주 산으로 갔습니다. 문제는 judge 모델 하나를 확률적 게이트처럼 쓰면, 루프가 발산하는지, 너무 강하게 수렴해서 local optima에 빠지는지, 아니면 애초에 목적함수가 잘못 잡혔는지를 분리해서 보기 어렵다는 점이었습니다. 예를 들어 사용자는 단순히 “UI를 깔끔하게 해줘”라고 했는데, 에이전트는 갑자기 버튼을 더 만들거나, 프로젝트 흐름을 과하게 세분화하거나, 인간 입장에서는 당연히 건드리면 안 되는 영역까지 수정해버리는 식이었어요. 그러다 RAG 쪽 골든 데이터셋 구축 글을 봤는데, 꽤 힌트가 됐습니다. 질문마다 질문 type을 두고, expected answer와 evidence를 정의해서 검색 실패인지 생성 실패인지를 구분하려는 방식이었는데, 이걸 agent loop에도 비슷하게 적용할 수 있겠다는 생각이 들었습니다.
LLM loop에서도 단순히 “결과가 좋아 보이는가?”를 judge에게 묻는 게 아니라, - 사용자의 원래 목표는 무엇인가 - 건드리면 안 되는 범위는 무엇인가 - 완료를 증명하는 evidence는 무엇인가 - 실패했다면 발산인지, 과수렴인지, 목적함수 오류인지 - 이 케이스는 어떤 type의 요청인가
같은 항목을 golden scenario로 쌓아야 할 것 같습니다. 결국 loop engineering은 LLM judge를 하나 더 붙이는 문제가 아니라, 좋은 목적함수와 관측 가능한 실패 분류 체계를 만드는 문제에 더 가까워 보입니다. RAG에서 golden dataset이 검색/생성 품질을 분리해서 보게 해주는 것처럼, agent loop에서도 golden scenario가 있어야 “왜 실패했는지”를 볼 수 있고, 그래야 다음 루프를 개선할 수 있을 것 같네요.

Repost from ordinary subinium
loop engineering 혹은 /goal의 실험과 관찰 결과 대부분 실패는 llm as a judge를 확률 게이트로 쓰며 발산과 강한 수렴을 방지하지 못하기에 발생한다. 좋은 목적함수를 설계하지 않으면 실패는 당연한 결과이다. 발산과 동시에 local optima에 빠지는 경우도 종종 발생하는데, 동적으로 해당 결과물에서 다른 요소를 건드림으로 이를 빠져나올 방안을 구성에 넣어야 한다. 이 외에도 루프 엔지니어링은 하나의 추상화된 nn의 학습 프로세스와 비슷한 부분이 많다. 연장선으로 이 루프라 함은 단일 과정에서 추출 가능한 “단일 스킬”로 대체될 수 있다기 보단 잘 설계된 광범위한 월드 모델로 설계되어야 한다는 생각이 든다.

요즘 좀 나태해졌었는데 다시 동기부여 되네요. 좋은 글 감사합니다 조엘님

웹3 생태계의 현실: 2026년 6월 편 기존 제 생각과 이번에 한국에 와서 많은 분들과 얘기를 나눈 후 얻은 인사이트를 좀 정리해 봤습니다. 지금 웹3에 진입한다면 - 내러티브 그만 따라가야 한다. 따라가던 애들은 다 망했다. - 웹2의 실존하는 문제를 해결하는 웹3 제품을 만들어야 한다. - 토큰화, 스테이블코인, 금융기관, 법제화, 인공지능 등 그나마 실생활과 연관이 있는 주제로 시작을 하자. - 진입장벽이 높아졌기 때문에, 바로 웹3로 커리어를 시작하는 건 현실적으로 힘들다. 전통금융, 웹2 빅테크, 인공지능 등에서 넘어오는 걸 추천한다. AI와 웹3 - 이 두 가지를 함께 엮고자 하는 수많은 시도가 있었으나, 사실 PMF가 있는 제품은 아직 잘 보이지 않는다. - 그나마 가장 핫한 agentic payments도 주로 명세 정의와 실증 단계에 머물러 있다. 냉정하게 말해서 현실세계에서 아직 쓰인다고 볼 수 없음. - agentic payments의 가장 큰 문제는 블록체인을 쓸 필요가 없다는 것이다. 써도 되고 안 써도 됨. - 지금은 AI가 뭘 해도 일단은 잘 되니까, 웹3가 AI의 바짓가랑이를 잡고 늘어지는 형국처럼 느껴진다. 웹3가 성공하려면 현실의 문제를 해결해야 한다. 웹3 말고 AI에 자본이 유입되는 이유는 AI가 현실의 문제를 해결해주기 때문이다. ChatGPT는 자명하게도 삶의 질을 향상시켜준다. 메타마스크가 삶의 질을 향상시켜주냐는 질문은 쉽게 답하지 못한다. 사실상 아니다. 기술은 이미 고도화되었다. 이젠 FHE, TEE, ZK 같은 고차원적인 단어들도 물론 필요하지만, 이 기술을 블록체인에 접목하여 어떠한 효용성이 있는지를 고민해야 할 때다. 기저에 깔려있는 기술은 블록체인 생태계의 존폐에 있어서 더 이상 가장 중요한 부분이 아니다. 법제화 국내 법제화는 매우 느리게 진행중이다. 법제화에는 크게 두 가지 문제가 있다. 1. 느리다. 아시아만 해도 기초적인 틀이 마련된 나라가 싱가폴, 홍콩, 일본 정도.. 나머지 한국 및 동남아 나라는 한참 멀었다. 국내 기관은 관심은 매우 많으나 금감원 눈치를 볼 수 밖에 없고 사실상 법제화 전까지 뭔가를 하긴 힘들다. 법제화를 우리가 직접적으로 앞당길 수 있는 방법은 없으니 업계는 제한된 자본 하에 실시간으로 수명이 단축되고 있다. 2. 금융기관의 안정성에 초점이 맞추어져 있다. 금융기관의 첫번째 목표는 사고가 나지 않는 것이다. 야생마와 다름없는 블록체인을 가만 둘리가 없다. 안전성과 신뢰성을 위주로 법률이 제정되면 결국 블록체인의 장점이 상실된다. 예를 들면 KYC, AML, 최대 입금, 송금 조건이 붙어 송금이 지연돠며 익명성이 박탈되는 구조. 이런 문제가 있으니 기술이 준비가 되었어도 사용할 수가 없거나 사실상 효용을 발휘하게 할 수가 없다. 기관 내러티브의 함정 1-2년 전부터 내러티브는 완전히 기관 쪽으로 바뀌었다. 기관 내러티브의 단점은 현실적이라는 것이다. 리테일은 현실세계가 바뀌고 발전하는 건 관심없다. 몇 가지 buzzword에 이끌려 유동성을 주입하고 꺼내는 걸 반복한다. 리테일은 블록체인이 현실의 문제를 해결하는 것을 신경쓰지 않는다. 기관은 다르다. 수지타산과 실용성을 철저하게 검토한다. 여기서부터 막힘.. 기관은 수많은 레거시 인프라를 가지고 있고, 현실세계는 크립토가 아닌 fiat, 즉 웹3가 아닌 웹2로 굴러가고 있다. 이 상황에서 누구 하나가 나서서 웹3로 인프라를 갈아끼우는 작업을 시작하는 것은 사실 매우 힘든 일이다. 기관은 실제 사용을 하고 싶어하기 때문에 이런 문제가 발생한다. 얼마나 업계가 아직도 발전하지 못했는지 대변해주는 부분. 사람들은 알게 모르게 이미 움직이고 있다 최근 수많은 똑똑한 지인들과 얘기를 나눴다. 모두가 AI에 더 많은 관심을 가지고 뭔가 하나라도 해 보려고 노력하고 있다. AI의 가장 큰 특징은 현실세계의 문제를 지금 해결해 준다는 것이다. 답답한 크립토의 발자취를 하나 둘씩 뒤로 하려는 움직임이 보인다. 구체적으로 무슨 일들을 하시는지는 모두 밝힐 수 없겠지만 AI로 해 볼 수 있는 모든 수익화 아이디어는 다 들어본 것 같다. 이것마저 하지 않으면 도태되고 말 것이다. 대AI 시대에 가장 필요한 특징은 똑똑함이 아닌 실행력이다. 지식의 가치는 싸다. 실행력은 아직 비싸다. 실행력의 인자인 체력과 시간은 대부분 공평하게 주어지기 때문이다. 생각은 그만하고 실행하자. 내가 아는 대단한 분들은 이미 실행하고 계신걸 보고 왔다. 지난 한 달 동안 회사 + 다이어트 + 운동 병행하며 힘들어서 좀 적당히 하면서 쉬었는데 다시 복귀해야겠다. 시간은 나의 사정을 신경 써 주진 않는다. 웹3의 미래 - 웹3가 망할 거라고 생각하지 않습니다. 단지 앞서 설명한 이유로 현재 웹3 제품으로 현실의 문제를 해결하기가 쉽진 않습니다. 특히 국내에서. - 웹3에 열정이 있는 분들은 어떻게든 현실의 문제를 해결하는 제품을 만들거나, 상황이 개선될 때까지 기다렸다가 결국 제품을 만들 것이라고 생각합니다. - 최근 웹3가 현실의 문제를 바로 해결할 수 있다고 생각되는 분야는 무역 금융. 다음 번에 한 번 심도있는 정보를 올려볼게요. 자료 저번 목요일, 토요일 행사에 참여해주신 분들께 감사의 말씀 드립니다. 행사를 위해 준비한 1시간 분량의 40장짜리 슬라이드를 공유드립니다. 제 커리어와 전반적인 Web3, AI 얘기가 담겨있습니다. P.S. 방장채널 @joelweb3kr 방장일기 @joeldiary 저 WebX 가는데 가시는분 있나요?

마감
| 닉네임 | 등수 | 점수 | |---|---:|---:| | 성수 | 1등 | 2,632,530 | | pangpang | 2등 | 2,500,620 | | 고려대학교 | 3등 | 2,467,910 | | 배즙 | 4등 | 2,200,600 | | Nu_lav | 5등 | 2,156,590 | | 니니 | 6등 | 2,117,370 | | 짜짜 | 7등 | 1,899,820 | | SEON | 8등 | 1,826,560 | | 멕드로뇽인줄알았지만멕드로뇽 | 9등 | 1,741,400 | | banabana8597 | 10등 | 1,548,740 | | ooo4ever | 11등 | 1,479,830 | | lfgo5959 | 12등 | 1,089,130 | | sibarom | 13등 | 1,002,010 | | 배즙 | 14등 | 704,703 | | MapleHero | 15등 | 512,680 | | rna | 16등 | 446,090 | | 커먼센스 | 17등 | 432,980 | | cogoco | 18등 | 429,530 | | 쿠나 | 19등 | 412,456 | | donggu | 20등 | 386,980 |
텔레로 디엠한번씩만 주세요. 다들 즐겨주셔서 감사합니다 !

마감 4시간 전입니다 ! 경쟁자 얼마없어서 참여만하셔도 커피 드실듯 !!

Verse8 메이플 게임 하나 만들어봤습니다 + 이벤트 안녕하세요. 재미입니다. 메이플 게임 저도 하나 만들어보았습니다. 즐기면서 하는데 경품까지 있으면 더 좋겠죠. 짧고 굵게 이벤트 들어가겠습니다. https://verse
Verse8 메이플 게임 하나 만들어봤습니다 + 이벤트 안녕하세요. 재미입니다. 메이플 게임 저도 하나 만들어보았습니다. 즐기면서 하는데 경품까지 있으면 더 좋겠죠. 짧고 굵게 이벤트 들어가겠습니다. https://verse8.io/dl/games/T3U4x5s?referral=77LMIW
• 이벤트 기간 ~ 26.06.28 21:00까지 (일요일 저녁 9시) • 참여 방법 게임 플레이 시작전 닉네임 적으면 리더보드에 자동 등록됩니다. • 경품 1위: 치킨 1마리 2위~20위: 커피 기프티콘
이벤트 종료 시점 리더보드 기준으로 상위권 분들께 경품을 지급할 예정입니다. 재밌게 즐겨주시고, 버그나 아쉬운 점 있으면 편하게 알려주세요.

msu 게임 신청 승인얼마나 걸리나요??

Repost from 저스트코인
https://crime-radar.trade 랭킹 기능 추가 계속 업데이트 예정.

Repost from ordinary subinium
웹 개발 명가 Vercel은 Agent에 필요한 라이브러리를 여럿 빠르게 배포하다 이제 Agent Framework를 공개했네요. Typescript에 파일시스템 기반으로 잘 담았다고 하는데 자연어로 어렴풋이 연결된 에이전트 시스템이 아닌 조금 더 명시적으로 tool call이나 시스템 호출을 연결해서 탄탄한 프레임워크를 지향하는 듯 합니다. https://github.com/vercel/eve/

이거 하시다가 모르는거 생기면 dm이나 채팅으로 질문주십셔 ! textual 기반이라 터미널에서 마우스 클릭도 돼요 !

겉으로는 단순한 터미널 UX지만, 내부에서는 여러 에이전트가 토론, 합의, 작업 분해, 실행, 리뷰까지 거치는 다단계 오케스트레이션이 돌아가기 때문에 작업 시간이 좀 걸릴 수 있습니다..

이제 이걸루 MSU 겜 만들러 갑니동..

안녕하세요. 재미입니다. 개발 중이던 오케스트레이터의 안정화 버전이 나왔습니다 ! Trinity 1.0 소개 요즘 AI 코딩 도구는 강력하지만, 실제 프로젝트에서는 이런 일이 자주 생깁니다. - 설계는 Claude에게 물어보
안녕하세요. 재미입니다. 개발 중이던 오케스트레이터의 안정화 버전이 나왔습니다 !
Trinity 1.0 소개 요즘 AI 코딩 도구는 강력하지만, 실제 프로젝트에서는 이런 일이 자주 생깁니다. - 설계는 Claude에게 물어보고 - 구현은 Codex에게 맡기고 - 다른 관점의 리뷰는 Antigravity에게 확인하고 - 결과를 다시 사람이 붙여 맞추고 - 실패한 작업은 어디서부터 재시도해야 할지 직접 판단합니다 Trinity는 이 흐름을 하나의 작업대로 묶는 도구입니다. 사용자는 목표를 입력하고 작업공간을 선택합니다. 그러면 Trinity가 목표를 work package로 나누고, 각 에이전트의 역할에 맞춰 병렬로 실행합니다. 작업이 끝나면 결과를 모으고, 리뷰가 필요한 지점이나 실패한 provider가 있으면 바로 집계하지 않고 사용자에게 다음 선택을 묻습니다. 핵심은 “AI 세 개를 동시에 켜는 것”이 아니라 “하나의 목표, 하나의 컨텍스트, 하나의 실행 흐름”입니다. Trinity v1.0에서 보고 있는 방향은 다음과 같습니다. - 현재 폴더 기반의 자연스러운 실행 흐름 - target workspace 선택과 실행 전 preflight - Claude, Codex, Antigravity 역할 기반 병렬 실행 - work package 단위 진행 상태와 리뷰 흐름 - provider 오류 발생 시 재시도, 제외 후 계속, 중단 선택 - 실행 실패 후 복구 가능한 패키지 재시도 - PyPI 기반 업데이트 안내
설치(bash):
python -m pip install --upgrade trinity-agent
trinity init
trinity
주요 흐름은 단순합니다. 1. 작업 목표 입력 2. 워크스페이스 선택 3. 에이전트별 병렬 실행 4. 결과 리뷰 및 재시도 5. 중앙 에이전트가 최종 요약 Trinity가 지향하는 것은 “AI 하나에게 모든 걸 맡기기”가 아니라, 설계자, 구현자, 검토자가 함께 일하는 개발 워크플로우입니다. 특히 이런 상황에 잘 맞습니다. - 기능 설계부터 구현까지 한 번에 진행하고 싶을 때 - 여러 AI CLI를 이미 사용하고 있지만 흐름이 분산되어 있을 때 - 구현 결과를 다른 에이전트가 검토하게 만들고 싶을 때 - 복잡한 작업을 work package 단위로 나눠 병렬 처리하고 싶을 때
설치:
pip install trinity-agent
실행:
trinity
GitHub: 깃헙스타점요.. Trinity 1.0은 멀티 에이전트 개발 워크플로우를 실제 CLI 환경에서 사용할 수 있게 만드는 첫 번째 안정화 버전입니다. 잘 부탁드립니다. 사실 셋 다 구독해놓고 토큰 다 못 쓰는게 아까워서 만들었어요..

Repost from 크립토메이지
AI 관련 영상들이 많아지다 보니 어디서부터 봐야 할지 헷갈리는 경우가 많습니다. 기존에 올렸던 영상들을 난이도와 활용도 기준으로 정리했습니다. ai-roadmap
AI 관련 영상들이 많아지다 보니 어디서부터 봐야 할지 헷갈리는 경우가 많습니다. 기존에 올렸던 영상들을 난이도와 활용도 기준으로 정리했습니다. ai-roadmap

Repost from GeekNews
GLM 5.2 출시 - GLM-5.2는 실제 사용 가능한 1M 컨텍스트와 장기 과제 독립 수행을 지원하는 오픈소스 모델로, 복잡한 에이전트 애플리케이션 구축 기반을 제공함 - 프런티어 모델 접근이 비기술적 이유로 갑자기 차단되는 상황에서 과학은 세계적이어야 하며 AGI로 가는 길은 높은 장벽에 갇히면 안 됨 - AGI는 소수 규칙이 독점하고 언제든 회수할 수 있는 특권이 아니라, 인류가 지능의 경계를 함께 탐구하고 복잡한 과제를 푸는 공동 기반이어야 함 - GLM-5.2는 Zhipu의 현재까지 가장 강력한 오픈소스 모델이며, 자국 최강 코딩 모델을 만들기 위… https://news.hada.io/topic?id=30478

한줄 입력해서 만들고 15분 타입에러만 잡아줬는데 생각보다 쓸만하게 나오네요. 에셋 갈아끼우고 잔버그 수정하면 퀄 좋아질듯

이번에 만든 오케스트레이터로 테스트 중.. 한 문장으로 게임 MVP 만들어보기 시도 중인데 잘되면 msu vibe 참가해볼거 같네요. 모델은 GLM-5.1, GPT-5.5, gemini-3.5-flash 입니다
이번에 만든 오케스트레이터로 테스트 중.. 한 문장으로 게임 MVP 만들어보기 시도 중인데 잘되면 msu vibe 참가해볼거 같네요. 모델은 GLM-5.1, GPT-5.5, gemini-3.5-flash 입니다

요즘 @cuna_max와 같이 만들고 있는 것. 장이 좋지도 않고, 코인에서 제가 할 수 있는 플레이도 예전보다 제한적이다 보니 자연스럽게 다른 쪽을 보게 됐습니다. 이미 구독하고 있는 AI 에이전트들을 어떻게 하면 더 효율
+2
요즘 @cuna_max와 같이 만들고 있는 것. 장이 좋지도 않고, 코인에서 제가 할 수 있는 플레이도 예전보다 제한적이다 보니 자연스럽게 다른 쪽을 보게 됐습니다. 이미 구독하고 있는 AI 에이전트들을 어떻게 하면 더 효율적으로 쓸 수 있을까 하는 생각에서 시작한 프로젝트입니다. 아이디어는 단순합니다. 사용자가 터미널에서 하나의 프롬프트를 던지면, 여러 프론티어 모델이 동시에 그 요청을 받아 각자 기획과 설계를 합니다. 이후 서로의 의견을 비교하고, 합의 가능한 방향을 정리한 뒤, 실제 코드 작성 단계에서는 작업을 나눠 병렬로 실행합니다. 지금은 Claude, Codex, Antigravity 같은 에이전트들을 하나의 터미널 프로그램 안에서 굴리는 구조로 만들고 있습니다. 한 모델에게 전부 맡기는 방식보다는, 모델마다 잘하는 역할을 나누고 서로 검토하게 만드는 쪽이 더 안정적일 거라고 보고 있습니다. 기획은 기획대로, 구현은 구현대로, 검토는 검토대로 분리하고, 실행 과정에서 어떤 에이전트가 어떤 작업을 언제 시작하고 끝냈는지도 확인할 수 있게 만들고 있습니다. 아직 다듬을 부분이 많지만, 방향은 꽤 마음에 듭니다. 결국 목표는 제가 직접 여러 AI 툴을 오가며 관리하던 과정을 줄이고, 터미널 안에서 하나의 요청만으로 설계, 합의, 구현, 검증까지 이어지게 만드는 것입니다. 요즘은 이걸 계속 만지고 있습니다.

gemini cli 쓰시는 분들은 Antigravity CLI 로 전환하셔야할 것 같네요. 6월 18일부로 깃헙 조직 신규설치 지원 종료한다구 합니다. (엔터프라이즈 접근 권한은 유지됨) 기사 | 안티그래비티 CLI
gemini cli 쓰시는 분들은 Antigravity CLI 로 전환하셔야할 것 같네요.
6월 18일부로 깃헙 조직 신규설치 지원 종료한다구 합니다. (엔터프라이즈 접근 권한은 유지됨) 기사 | 안티그래비티 CLI