GenUI 디자인 — AI가 UI를 만들 때 디자이너가 설계해야 하는 것

gskinner의 2026년 6월 16일 글 **“Designing for GenUI: What Changes When AI Builds the UI?”**는 AI가 화면을 런타임에 조립하는 시대에 제품 디자인이 어떻게 달라지는지 다룹니다. 핵심은 단순합니다. 디자이너가 더 이상 모든 화면을 직접 완성하는 사람이 아니라, AI가 화면을 만들 때 따라야 할 재료와 규칙을 설계하는 사람이 된다는 것입니다. 원문: Designing for GenUI: What Changes When AI Builds the UI? TL;DR 핵심 정리 화면에서 규칙으로 이동한다: GenUI에서는 모든 화면을 미리 설계하는 대신, AI가 어떤 상황에서 어떤 컴포넌트를 써야 하는지 정의한다. Hatcha가 사례다: gskinner는 Google 발표를 위해 Flutter 기반 이벤트 플래닝 앱 Hatcha를 만들며, 초대장과 대시보드가 맥락에 맞게 조립되는 경험을 실험했다. 디자인 시스템은 재고가 된다: 컴포넌트는 예쁜 부품이 아니라, AI가 목적에 맞게 꺼내 쓰는 선택 가능한 도구 목록이다. 고정 UI와 GenUI를 나눠야 한다: 내비게이션, 규제 절차, 감사 가능한 흐름은 고정 UI가 낫고, 개인화와 가변성이 큰 영역은 GenUI가 빛난다. 디자이너의 사용자 이해가 더 중요해진다: 컴포넌트 조건, 프롬프트, 가드레일은 결국 사용자를 얼마나 잘 이해했는지의 표현이다. GenUI가 바꾸는 기본 전제 전통적인 UI는 미리 구성됩니다. 디자이너가 화면을 그리고, 사용자는 그 화면 사이를 이동합니다. 플로우차트, 와이어프레임, 프로토타입은 모두 “어떤 화면이 어떤 순서로 나오는가"를 정하는 데 초점이 있습니다. ...

July 8, 2026 · 4 min

Understanding Is the New Bottleneck - AI 시대의 병목은 이해다

Geoffrey Litt의 글 Understanding Is the New Bottleneck은 AI 코딩 시대의 병목이 어디로 이동하는지 묻는다. 예전에는 구현 속도가 문제였다. 이제는 AI가 초안을 빠르게 만들기 때문에, 사람이 그 결과를 이해하고 다음 판단으로 연결하는 능력이 더 큰 제약이 된다. Bottleneck 핵심 정리 병목 이동: AI는 작성 속도를 올리지만, 사람이 시스템을 이해하는 속도까지 자동으로 올리지는 않는다. 이해의 목적: 코드를 승인하기 위해서만 이해하는 것이 아니라, 다음 아이디어와 설계 판단에 참여하기 위해 이해해야 한다. 인지 부채: 읽지 않은 코드, 설명되지 않은 결정, 머릿속에 남지 않은 맥락은 나중에 더 큰 비용으로 돌아온다. 도구 방향: 좋은 AI 개발 환경은 사람을 생략하는 것이 아니라, 사람이 더 빠르게 파악하고 개입하도록 도와야 한다. 1) AI는 생산 병목을 없애지 않고 옮긴다 AI 코딩 도구가 잘하는 일은 분명하다. 함수 초안, UI 구현, 리팩터링, 테스트 보강 같은 작업을 사람이 직접 타이핑하는 것보다 훨씬 빠르게 만든다. 그래서 표면적으로는 “만드는 속도"가 올라간다. ...

July 8, 2026 · 4 min

Some New Agentic Patterns - 에이전트가 동료 에이전트를 위해 도구를 고치는 방식

Jesse Vincent의 Some new agentic patterns는 에이전트를 더 잘 쓰는 프롬프트 팁이 아니다. 핵심은 에이전트를 위한 제품을 만들 때, 실제 사용자 역할의 에이전트가 구현 에이전트와 직접 대화하게 하는 개발 방식이다. 원문: Some new agentic patterns Agent Loop 핵심 정리 새 패턴: 사람이 중간에서 피드백을 전달하지 않고, Claude Code가 Slackline을 통해 Ada-sen에게 직접 테스트를 요청했다. 사용자 모델: Sen 2.0은 단순 비서가 아니라 자기 도구, 메모리, 작업공간, 자격 증명을 가진 장기 실행 동료 에이전트로 설계된다. 보안 전제: Lethal Trifecta를 완전히 없애는 대신, 외부 통신 권한과 자격 증명 접근을 임시 서브에이전트와 중재자 에이전트로 분리한다. 실무 포인트: 코딩 에이전트에 맞는 컨텍스트 압축은 여러 대화를 동시에 이어가는 페르소나형 에이전트에는 맞지 않을 수 있다. 결과: Ada가 스펙을 검토하고, Claude가 구현하고, Ada가 다시 테스트하면서 품질 개선 목록과 수정 요청까지 생성했다. 1) 배경: Slack 안의 여러 에이전트 Prime Radiant에는 여러 에이전트가 Slack 안에서 일한다. Scribble은 문제 보고와 새 정보를 듣고 티켓을 열거나 내부 위키를 갱신한다. Nora는 go-to-market 업무를 돕는 주니어 동료처럼 행동한다. Spec-together는 멀티플레이어 Brainstorm 앱의 초기 실험이었다. ...

July 7, 2026 · 5 min

The annotated PyTorch training loop - PyTorch 학습 루프의 순서가 중요한 이유

idlemachines의 The annotated PyTorch training loop는 PyTorch 학습 루프를 한 줄씩 해부하는 글입니다. 겉으로는 단순한 for 문처럼 보이지만, 실제로는 모델 상태, gradient buffer, autograd graph, optimizer state, scheduler state가 맞물려 돌아갑니다. 그래서 줄 하나가 조금만 엉뚱한 곳에 있어도 에러 없이 학습이 망가질 수 있습니다. 원문: The annotated PyTorch training loop PyTorch 핵심 정리 핵심 순서: model.train() -> zero_grad() -> forward -> loss -> backward() -> clipping -> optimizer.step() -> scheduler.step() -> model.eval() + no_grad()가 기본 골격이다. 가장 위험한 점: 잘못된 위치의 코드가 항상 예외를 내지는 않는다. 학습이 안 되거나, 너무 느리거나, 메모리가 계속 늘어나는 형태로 드러난다. 역할 분리: loss.backward()는 .grad를 채우고, optimizer.step()은 weight를 바꾼다. 이 둘을 같은 일로 보면 루프를 잘못 고치기 쉽다. 검증 루프: model.eval()은 레이어 동작을 바꾸고, torch.no_grad()는 graph 생성을 막는다. 검증에는 보통 둘 다 필요하다. GPU 효율: 모델과 batch를 같은 device에 두고, mixed precision, pinned memory, prefetch, torch.compile을 상황에 맞게 적용해야 GPU가 놀지 않는다. 1) 학습 루프는 작은 상태 머신이다 PyTorch 학습 코드는 보통 이렇게 생겼습니다. ...

June 27, 2026 · 6 min

에이전틱 소프트웨어 엔지니어링 — 에이전트 구축은 쉽지만 프로덕션 운영은 분산 시스템 문제다

Ashpreet Bedi(Agno 창업자)가 에이전트 구축과 프로덕션 운영 사이의 격차를 지적하며, 에이전틱 소프트웨어를 분산 시스템으로 다뤄야 한다는 체계적 프레임워크를 제시합니다. 원문: Systems Engineering: Building Agentic Software That Works / Agentic Software Engineering 핵심 주장 “에이전트 구축은 쉽지만, 프로덕션 환경에서 안정적으로 운영하는 것은 어렵다” 사용자 식별, 상태 유지, 동시 요청 처리, 환불 같은 민감한 작업, 실패한 도구 호출 처리가 필요한 순간, 그것은 더 이상 “LLM + 도구의 루프"가 아닌 분산 시스템 이 된다. 에이전틱 소프트웨어 배포의 3단계 단계 설명 핵심 Build(구축) 모델, 도구, 지식베이스, 메모리, 저장소, 보호 장치 정의 AI 엔지니어링 중심. 대부분의 프레임워크가 지원하는 영역 Serve(서빙) API로서 제공. 사용자별 범위 지정, 세션 관리, 수평 확장 대부분의 에이전트 제품이 여기서 정체됨 — 인프라 부족 Connect(연결) 사용자가 있는 곳과 통합 (Slack, Discord, MCP 등) “노트북의 에이전트는 실험, 사용자가 있는 곳의 에이전트가 제품” 에이전틱 소프트웨어의 6가지 기둥 1. Durability(내구성) 에이전트가 15단계 중 12단계에서 충돌하면, 재시작 시 부작용이 중복되거나 중요 컨텍스트가 손실된다. 일시 중지, 재개, 체크포인트, 우아한 복구가 필요하며, 내구성은 완전 재시작이 아닌 재개로 실패를 전환 한다. ...

April 11, 2026 · 3 min

LLM 에이전트를 위한 강화학습 환경 분류법 — 모델이 아닌 환경이 에이전트의 행동을 결정한다

모델 아키텍처와 사후 학습(post-training)에만 집중하는 현재 AI 개발 패러다임을 비판하며, “에이전트가 무엇을 배울 수 있는지 결정하는 것은 강화학습 환경"이라고 주장합니다. 환경 설계가 시스템 성능의 절반을 차지한다는 것이 핵심입니다. 원문: RL Environments for LLM Agents 핵심 주장 단일 턴 Q&A로만 학습한 모델은 50단계 엔터프라이즈 워크플로우에서 실패하고, 보상 함수가 형편없으면 모델이 문제를 풀기보다 지표를 조작하도록 학습된다. 모델이 아닌 환경이 에이전트의 행동을 형성 한다. 정준 루프(Canonical Loop): E = {T, H, V, S, C} RL 환경을 다섯 가지 요소로 정의한다: ...

April 11, 2026 · 5 min

software 팩토리: AI 코딩 에이전트가 개발 팀을 바꾸는 방식

출처: https://alexop.dev/posts/the-software-factory/ 핵심 메시지 AI 코딩 에이전트(Claude Code 등)를 활용해 “software 팩토리” 를 구축하면, 개발 팀의 작업 방식이 완전히 바뀐다. 개발자는 더 이상 코드를 직접 많이 작성하지 않고, 설계·아키텍처·검토·의사결정 에 집중한다. 결과적으로 팀 규모는 크게 줄고, 출시 속도는 몇 시간 단위로 빨라진다. 기존 방식 vs. software 팩토리 기존 방식 (Beer Commerce 예시) 12명 체크아웃 팀 한 기능(할인 코드 추가) 추가에 10~14일 소요 대부분 시간이 핸드오프(BA → PO → Dev → QA)와 커뮤니케이션에서 사라짐 실제 코딩 시간은 고작 2~3일 software 팩토리 방식 ...

March 24, 2026 · 2 min