오늘도 공부

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 등..

X에서 Michael Guo(@Michaelzsguo) 님 x.com 어제 꽤 흥미로운 MiniMax H3 LoRA 하나를 발견했다.Playtime-AI라는 사용자가 MiniMax H3용 Sydney Sweeney 인물 LoRA를 공개했는데, 파일 크기가 겨우 155MB다. 실제 Hugging Face에 올라온 MM-H3 - Sydney Sweeney.safetensors 파일도 155MB로 확인된다.이 LoRA를 MiniMax H3와 함께 로드하면 별도의 레퍼런스 이미지를 넣지 않고도 프롬프트에 Sydney Sweeney라는 이름을 적어 해당 인물의 외형적 특징을 반영한 영상을 만들 수 있다.여기서 재미있는 질문이 생긴다.한 사람의 얼굴은 어떻게 155MB짜리 파일 안에 들어갈 수 있을까?그리고 왜 수..

Anthropic Commerce Agents에서 읽어낸 프로덕션 AI 에이전트 아키텍처AI 에이전트를 만들기 시작하면 꽤 자연스럽게 이런 구조를 떠올리게 된다.사용자 ↓Router Agent ├─ Search Agent ├─ Recommendation Agent ├─ Order Agent ├─ Customer Support Agent ├─ Payment Agent └─ Analytics Agent업무별로 전문가를 하나씩 두는 것이다.사람 조직을 생각하면 합리적으로 보인다.검색은 검색 전문가에게 맡기고, 결제는 결제 전문가에게 맡기고, 고객지원은 고객지원 전문가에게 맡기면 더 잘하지 않을까?최근 몇 년 동안 많은 AI Agent Framework가 이런 Multi-Agent Architect..