Progressive Disclosure

Hamel Husain의 글 “It’s Hard to Eval” Is a Product Smell은 AI 제품에서 자주 나오는 말, “이 제품은 평가하기 어렵다"를 다르게 봅니다. 저자의 주장은 단순합니다. 평가가 어렵다면 평가 방식만의 문제가 아니라, 제품이 사용자의 검증 과정을 충분히 돕지 못한다는 신호일 수 있습니다. TL;DR 핵심 정리 중심 주장: AI 산출물이 제품을 만든 사람에게도 확인하기 어렵다면, 사용자는 더 큰 비용을 들여 다시 검증해야 한다. 설계 방향: 최종 답만 보여주지 말고 출처, 가정, 중간 계산, 확인하지 못한 항목을 함께 보여줘야 한다. 반복 패턴: 데이터 분석, 수업 계획, 의료 보고서 모두 “완성본 생성"보다 “검증 가능한 작은 단위"가 중요하다. 실무 질문: 사용자는 무엇을 확인해야 하는가, 무엇과 비교할 수 있는가, 어떤 단위로 승인하거나 거절할 수 있는가. 1) 어려운 평가는 제품 냄새다 많은 AI 팀은 평가를 나중 문제로 둡니다. 먼저 모델이 그럴듯한 결과를 내게 만들고, 이후에 자동 평가나 사람 평가를 붙이려 합니다. Hamel은 순서가 반대여야 한다고 말합니다. 제품이 검증하기 쉬운 산출물을 만들도록 설계되어야 평가도 쉬워집니다. ...

Addy Osmani의 2026년 5월 3일 글 **“Agent Skills”**는 AI 코딩 에이전트의 본질적 문제를 명확히 짚습니다. 에이전트는 기본적으로 구현 코드만 빠르게 만들고 끝내려 하기 때문에, 시니어 엔지니어가 중요하게 보는 스펙 작성·테스트·리뷰·출시 안전장치를 자주 생략합니다. 원문: Agent Skills — Addy Osmani TL;DR 요약 문제 정의: 에이전트의 기본 보상 신호는 “task complete"라서, 검증 가능한 증거 없이도 완료를 선언하기 쉽다. 핵심 해법: “규칙 문서"가 아니라 “실행 워크플로우"를 SKILL.md로 주입해 단계별 체크포인트와 종료조건을 강제한다. 구조화된 SDLC: /spec → /plan → /build → /test → /review → /ship (+ /code-simplify)로 사람의 시니어 프로세스를 복원한다. 실무 원칙 5가지: process over prose, anti-rationalization table, verification non-negotiable, progressive disclosure, scope discipline. 실행 메시지: 에이전트 시대일수록 “diff에 안 보이는 시니어 업무"를 시스템에 박아 넣어야 사고를 줄일 수 있다. 1) Skill의 본질: “지식"이 아니라 “행동 절차” 글에서 Skill은 단순 참고 문서가 아닙니다. 상황에 따라 에이전트 컨텍스트에 주입되는 **작업 절차(runbook)**에 가깝습니다. ...

AI 에이전트를 설계할 때 규칙(Rules), 기술(Skills), 명령(Commands) 을 어떻게 구분하고 사용할지가 핵심입니다. Builder.io 블로그 글을 바탕으로 세 개념의 정의, 사용 시점, 그리고 효과적인 기술 작성 방법을 정리했습니다. 원문: Agent skills, rules, and commands 1. 핵심 개념 정의 규칙 (Rules): 예외 없이 항상 적용되는 원칙입니다. (예: “절대 .env 파일을 커밋하지 마라”, “명명 규칙 준수”) 기술 (Skills): 특정 작업 시에만 불러오는 선택적 전문 지식입니다. 에이전트가 필요할 때만 ‘지연 로딩(Lazy loading)‘하여 컨텍스트 낭비를 줄입니다. (예: “UI 변경 시 체크리스트”, “배포 가이드”) 명령 (Commands): 사용자가 직접 실행하는 반복 가능한 워크플로우입니다. (예: /release, /refactor) 2. 기술(Skills)의 특징과 장점 점진적 공개(Progressive Disclosure): 에이전트가 처음부터 모든 내용을 읽지 않고, 메타데이터(설명)를 보고 필요할 때만 전체 내용을 로드합니다. 이는 모델의 컨텍스트 창을 아끼고 성능 저하를 방지합니다. 구성 요소: 기술은 지침이 담긴 SKILL.md 파일과 관련 스크립트, 템플릿, 참고 문서로 이루어진 폴더 형태입니다. 3. 언제 무엇을 사용해야 하는가? (결정 기준) 규칙: 내가 생각하고 있지 않을 때도 에이전트가 지켜야 하는가? (Yes → 규칙) 기술: 특정 상황이나 특정 파일 작업 시에만 필요한 전문 지식인가? (Yes → 기술) 명령: 내가 직접 제어권을 갖고 특정 동작을 시작하고 싶은가? (Yes → 명령) 4. 효과적인 ‘기술(Skill)’ 작성 팁 설명(Description) 최적화: 에이전트가 기술을 잘 찾아낼 수 있도록 키워드 중심의 구체적인 설명을 작성해야 합니다. 절차 중심: 기술 본문은 위키처럼 정보를 나열하기보다, 구체적인 작업 절차와 성공 기준(Success Criteria)을 명시하는 것이 좋습니다. 분리: 내용이 너무 길어지면 별도의 참조 파일로 분리하여 에이전트가 필요할 때만 읽게 합니다. 5. 요약 비교표 개념 실행 주체 용도 컨텍스트 비용 규칙 (Rules) 도구/시스템 저장소 기본 요구사항 항상 발생 명령 (Commands) 사용자 반복적인 워크플로우 사용 시 발생 기술 (Skills) 에이전트 작업별 전문 가이드 필요 시에만 발생 결론적으로, 모든 지침을 ‘규칙’에 쏟아붓는 대신, 상시 규칙은 최소화하고 작업에 필요한 전문 지식은 ‘기술’ 단위로 모듈화하여 관리하는 것이 최신 AI 에이전트 활용의 핵심 전략입니다.