오늘도 공부

이 글의 핵심은 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)가 공개한 리드 생성 자동화 가이드를 읽다가 흥미로웠던 것도 이 부분이었다.그가 설명하는 시스템의 출발점은 ‘어떻게 더 많이 연락할까?’가 아니다.누가 이미 문제를 가지고 있는지 먼저 찾아내는 것.그리고 그 사람이 실제로 사용하는 언어와 행동 데이터를 모은다. 그다음에야 광고나 제안을 만든다.이 순서를 뒤집지 않는 것이 핵심이다.사실 리드 생성은 하나의 데이..

NVIDIA SoL-Pi가 보여주는 ‘모델이 아니라 하네스를 최적화하는 방법’최근 AI 코딩 에이전트를 사용하다 보면 한 가지 재미있는 현상을 볼 수 있다.모델 자체는 상당히 똑똑하다.그런데 일을 오래 시키기 시작하면 토큰 사용량이 빠르게 늘어나고, 응답은 점점 무거워진다.특히 Codex나 Claude Code 같은 코딩 에이전트가 실제 작업을 수행하는 과정을 살펴보면 그 이유를 어느 정도 이해할 수 있다.대략 다음과 같은 루프가 반복된다.사용자 요청 ↓LLM 판단 ↓Tool 호출 ↓실행 결과 ↓LLM 판단 ↓다음 Tool 호출 ↓실행 결과 ↓LLM 판단 ...파일을 읽고, 수정하고, 테스트를 실행하고, 로그를 읽고, 다시 수정한다.이 방식은 에이전트 시스템의 기본적인 동작 ..

더 똑똑한 모델에는 더 짧고 명확한 지시가 필요하다GPT-6 Astra가 등장하면서 프롬프트 엔지니어링의 방향도 조금 달라졌다.이전 모델에서는 개발자가 모델의 행동을 하나하나 명시하는 경우가 많았다.“관련 파일을 모두 읽어라.”“작업이 끝나면 테스트하라.”“스스로 결과를 다시 검토하라.”“문제가 해결될 때까지 계속 작업하라.”하지만 GPT-6 Astra에서는 이런 지시를 무조건 많이 넣는 것이 반드시 좋은 전략은 아니다.OpenAI 공식 문서에서도 Astra가 이전 모델보다 instruction following과 장기 작업 수행 능력이 향상되었으며, 반대로 AGENTS.md, Skill 파일 등 컨텍스트에 포함된 지시의 영향을 더 민감하게 받을 수 있다고 설명한다. 따라서 기존 모델을 위해 쌓아놓은 지..

AI 코딩 도구를 팀에서 사용하기 시작하면 금방 새로운 문제가 생긴다.누군가는 Claude Code를 사용하고, 다른 개발자는 Codex나 Cursor를 사용한다. 개발자마다 사용하는 SKILL.md, 코딩 규칙, MCP 서버, 프롬프트, 개발 지식도 달라진다.결국 AI를 사용하면서 쌓인 경험이 개인의 로컬 환경에만 남는 문제가 발생한다.Tencent가 공개한 TeamAI CLI는 이 문제를 해결하기 위한 오픈소스 프로젝트다.단순한 Skill 동기화 도구라기보다는,팀의 AI 개발 환경을 하나의 Git 저장소를 기준으로 관리하는 AI Agent Harness에 가깝다.현재 TeamAI는 Claude Code, Codex, Cursor, CodeBuddy, WorkBuddy, OpenCode, Qoder 등..