오늘도 공부

구조는 이렇게 보면 가장 정확합니다.게임 상태 → Jev → 구조화된 선택 → 게임 코드가 실제 레벨 생성예를 들어 러너 게임에서 현재 상태를 Jev에 보냅니다.플레이어 위치속도현재 점프 중인지대시 사용 가능 여부현재 주변 지형최근 생성된 지형실제 글에서도 x, y, vx, vy, grounded, dash_ready 같은 게임 상태를 Jev에 전달합니다. (Sprite Fusion)그리고 중요한 부분은 Jev에게 자유롭게 "다음 맵 만들어줘"라고 시키지 않는다는 것입니다.개발자가 먼저 선택 가능한 범위를 정해놓습니다.발판 종류- Solid roof- One-way ledge폭- 2칸- 3칸- 5칸간격- 0칸- 1칸- 2칸높이- Row 4~9Jev는 여기서 다음 지형에 적합한 조합을 선택합니다. 한 번의..

AI가 코드를 쓰는 대신 UI를 조립하기 시작했다“매출 현황을 보여주는 대시보드를 만들어줘.”지금까지 AI에게 이렇게 요청하면 보통 이런 일이 벌어졌다.AI가 React 코드를 작성한다.컴포넌트를 만든다.CSS를 붙인다.차트 라이브러리를 고른다.상태 관리 코드를 만들고 버튼 이벤트도 연결한다.그리고 우리는 그 코드가 실제로 실행되기를 기도한다.컴파일 오류가 나기도 하고, 이미 회사에서 사용 중인 디자인 시스템을 무시한 새로운 버튼이 생기기도 한다. 버튼 하나를 수정해 달라고 했는데 AI가 파일 전체를 다시 작성하기도 한다.Vercel Labs의 json-render는 이 문제를 조금 다른 방향에서 바라본다.AI에게 프론트엔드 코드를 작성하게 하지 말고,우리가 허용한 UI 부품으로 화면의 ‘설계도’만 만들..

LLM에게 버튼 하나까지 생각하게 해야 할까?Jev 오픈소스 프로젝트 8개로 살펴본 AI Agent의 다음 구조AI 에이전트를 만들다 보면 이상한 순간을 자주 만나게 된다.파일을 읽고, 검색하고, 브라우저 버튼 하나를 누르고,수백 개의 Skill 중 하나를 고르는 모든 순간에 거대한 LLM을 호출한다.“이 버튼을 누를까, 저 버튼을 누를까?”“이 로그를 남길까 버릴까?”“수백 개의 Skill 중 어떤 것을 사용할까?”사람에게 물어본다면 그리 어려운 문제가 아니다.하지만 AI 시스템에서는 이런 작은 판단에도Claude나 GPT 같은 대형 모델을 호출하는 경우가 많다.결과적으로 에이전트는 느려지고,비용은 증가하며,컨텍스트는 계속 커진다.최근 등장한 Jev는 이 문제를 조금 다른 방향에서 바라본다.“모든 AI..

이 글의 핵심은 Jev를 “JSON 잘 뽑는 빠른 LLM”으로 보면 완전히 잘못 본 것이라는 주장입니다.저자가 1만 회가 넘는 API 호출과 여러 블랙박스 실험을 바탕으로 추정한 Jev의 구조는 대략 이렇습니다.LLM처럼 문장을 생성하는 모델이 아니라, LLM의 내부 표현을 이용해 “결정 확률”을 바로 읽어내는 모델일반 LLM과 비교하면 차이가 선명합니다.일반 LLMJev로 추정되는 방식프롬프트 입력state + 여러 questions 입력토큰을 하나씩 생성질문별 확률을 직접 계산"payments": "91%"라는 문자열 생성payments = 0.91이라는 분포를 readout여러 질문을 차례로 처리하기 쉬움여러 질문을 병렬 처리같은 긴 context를 반복 처리state를 한 번 계산하고 공유conf..

Jev란?Jev는 자연어와 비정형 데이터를 대상으로 빠른 의미 판단(Semantic Decision)을 수행하는 엔진으로 볼 수 있다.일반적인 LLM에게 모든 업무를 맡기는 대신,분류탐지점수화라우팅검색랭킹검증정보 추출처럼 작고 명확한 판단 작업을 Jev에 맡기는 방식이다.핵심 구조는 다음과 같다.Code ↓Jev Semantic Decision ↓Code ↓Jev Semantic Decision ↓Code즉,Control Flow는 코드가 담당하고Semantic Decision은 Jev가 담당한다.1. Classification — 분류입력된 내용을 미리 정의된 카테고리 중 하나로 분류한다.예시사용자 입력:카드를 잃어버렸어요.Jev 결과:{ "intent": "lost_card"}활용 사례고객 문의 분..

https://github.com/plugin87/ux-ui-agent-skillsUX UI 디자인 스킬 설명 및 사용 방법문서 목적이 문서는 현재 Codex 환경에 설치된 plugin87/ux-ui-agent-skills 계열 스킬과 함께 사용할 수 있는 핵심 UX/UI 스킬을 한눈에 이해하고 실제 작업에 적용하기 위한 안내서입니다. 스킬은 디자인 방향을 정하거나, 화면을 설계하고, 코드를 만들고, 접근성과 품질을 검증하는 작업을 역할별로 나누어 줍니다.가장 안정적인 사용 순서는 방향 정의 → 토큰 설계 → 화면·컴포넌트 설계 → 코드 구현 → QA와 검토입니다. 한 번에 모든 스킬을 호출하기보다 현재 작업의 단계에 맞는 스킬만 선택하면 결과가 더 일관되고 검증하기 쉽습니다.스킬을 호출하는 기본 방법C..

요즘 AI를 조금 깊게 쓰기 시작하면 이상한 단어를 계속 만나게 된다.Context Engineering, Harness Engineering, Loop, Memory, Skill, Hook….그리고 최근에는 또 하나가 자주 보인다.Graph Engineering.처음 이 말을 들었을 때는 나도 조금 피곤했다.“또 새로운 개념인가?”그런데 내용을 들여다보면 사실 완전히 새로운 기술은 아니다.우리가 이미 가지고 있는 문서와 지식을AI가 실제로 찾아갈 수 있도록 연결해주는 일에 더 가깝다.그리고 생각보다 이 문제가 꽤 중요하다.AI에게 자료를 줬는데, 왜 계속 엉뚱한 답을 할까예를 들어 이런 상황을 생각해보자.나는 몇 달 동안 AI와 일을 하면서 수많은 자료를 만들었다.브랜드 가이드고객 분석글쓰기 스타일회의..

요즘 개발자끼리 만나면 비슷한 이야기가 나온다.“이제 코드를 직접 짤 일이 별로 없지 않아요?”과장만은 아니다.나 역시 예전이라면 직접 구현했을 코드를 먼저 AI에게 던진다. 코드를 작성하게 하고, 실행 결과를 보고, 이상한 부분을 수정하게 한다. 어느 순간부터 개발에서 내가 보내는 시간은 ‘타이핑’보다 ‘판단’ 쪽으로 이동하고 있다.Anthropic의 Dario Amodei는 2026년 다보스포럼에서 자사 엔지니어 중 일부는 이미 코드를 거의 직접 작성하지 않는다고 말했다.모델이 코드를 만들고, 사람은 그것을 편집하고 주변의 일을 처리한다는 것이다.여기까지만 보면 조금 무섭다.그렇다면 개발자는 결국 필요 없어지는 걸까.그런데 AI 시스템을 조금만 아래쪽까지 내려가 보면 전혀 다른 풍경이 나타난다.모델은..

개발자가 코드를 직접 작성하지 않는 시대가 정말 올까.몇 년 전만 해도 이런 이야기를 하면 꽤 먼 미래의 이야기처럼 들렸다. AI에게 코드를 만들어 달라고 부탁해도 결국 사람이 다시 뜯어고쳐야 했고, 복잡한 프로젝트에서는 별 도움이 되지 않는 경우도 많았다.그런데 분위기가 꽤 빠르게 달라지고 있다.Microsoft CoreAI를 이끄는 Jay Parikh는 최근 Microsoft의 새로운 기술 블로그 Command Line을 소개하면서 흥미로운 이야기를 꺼냈다.요지는 단순하다.AI 때문에 개발 속도가 빨라진 정도가 아니라, 소프트웨어를 만드는 방식 자체가 바뀌고 있다는 것이다.코드를 작성하고, Pull Request를 만들고, 사람이 검토하고, 테스트하고, 배포하는 기존 개발 흐름이 AI 에이전트의 등장..

리드 생성 자동화의 핵심은 이메일을 많이 보내는 것이 아니다영업 자동화라고 하면 대개 이런 장면부터 떠올린다.어딘가에서 이메일 주소를 수천 개 수집하고, AI가 영업 메일을 작성한 뒤 하루에 몇백 통씩 발송한다. 답장이 오면 CRM에 넣는다.기술적으로는 자동화다.그런데 좋은 자동화라고 부르기는 어렵다.최근 X에서 Chris(@everestchris6)가 공개한 리드 생성 자동화 가이드를 읽다가 흥미로웠던 것도 이 부분이었다.그가 설명하는 시스템의 출발점은 ‘어떻게 더 많이 연락할까?’가 아니다.누가 이미 문제를 가지고 있는지 먼저 찾아내는 것.그리고 그 사람이 실제로 사용하는 언어와 행동 데이터를 모은다. 그다음에야 광고나 제안을 만든다.이 순서를 뒤집지 않는 것이 핵심이다.사실 리드 생성은 하나의 데이..