코딩 에이전트 UI 리뷰, 8개 스킬이 순서를 바꿨다 | DAKER 커뮤니티
코딩 에이전트에게 화면을 다듬어 달라고 하면 그림자와 모서리부터 바뀌기 쉽습니다. 그러나 키보드로 닿지 않는 버튼이나 320픽셀 화면에서 잘리는 경로는 그대로 남습니다. interfaces는 표면 장식보다 접근성과 구조를 먼저 보도록 리뷰 순서를 스킬로 고정합니다.
interfaces는 접근성, 레이아웃, 문구, 타이포그래피, 색, 시각적 마무리를 분리하고 두 개의 조율 스킬을 더해 UI 리뷰 기준을 8개 스킬로 운영합니다.
오늘의 한 줄 요약
interfaces는 접근성, 레이아웃, 문구, 타이포그래피, 색, 시각적 마무리를 분리하고 두 개의 조율 스킬을 더해 UI 리뷰 기준을 8개 스킬로 운영합니다.
무슨 변화인가요?
여섯 도메인 스킬은 각 규칙의 소유권을 하나씩만 갖고, better-interface가 접근성부터 시각적 마무리까지 순서대로 호출합니다. interface-review는 변경 범위를 해석하고 지적을 Introduced, Regression, Pre-existing로 나눕니다. quick 모드는 최대 5개, full 모드는 최대 15개를 보고하지만 차단 수준 문제는 상한보다 먼저 남깁니다.
왜 지금 중요한가요?
짧은 프롬프트는 무엇을 볼지보다 눈에 띄는 것을 먼저 고치게 만듭니다. 리뷰 순서와 증거 형식을 문서로 고정하면 팀마다 달라지는 지적을 줄이고, 접근 가능한 이름이나 포커스 표시 같은 차단 문제를 표면 개선보다 앞에 둘 수 있습니다. 다만 이미 디자인 시스템이 있다면 새 규칙을 추가하기보다 기존 문서를 스킬화하는 편이 낫습니다.
실무 판단표
| 항목 | 확인 내용 | 판단 기준 |
|---|---|---|
| 접근성 | 의미 구조·키보드·이름 | 차단 문제 우선 |
| 레이아웃 | 공간·반응형·잘림 | 320px 확인 |
| 문구·타이포 | 표현과 읽기 흐름 분리 | 소유권 중복 방지 |
| 색·마무리 | 대비 측정 뒤 시각 개선 | 표면 수정은 마지막 |
바로 할 일
- UI 리뷰 범위를 화면이 아니라 사용자 경로로 적습니다.
- 접근성, 레이아웃, 문구, 타이포그래피, 색, 마무리 순서로 확인합니다.
- 모든 지적에 파일과 줄, 현재 구현 근거를 붙입니다.
- HIGH가 남으면 스타일 수정과 관계없이 배포를 멈춥니다.
주의할 점
- 이 스킬은 정확성, 보안, 성능 리뷰를 대체하지 않습니다.
- 문서형 규칙이므로 검사 결과는 사용하는 에이전트 모델에 따라 달라질 수 있습니다.
- 웹 플랫폼 중심 규칙을 네이티브 앱이나 게임 UI에 그대로 적용하면 안 됩니다.
- 기존 디자인 시스템과 충돌하면 새 규칙보다 팀의 확정된 기준을 먼저 정리해야 합니다.
DAKER에서 이어서 보기
DAKER 리서치, DAKER 학습, DACON 대회에서 이 기준을 실제 프로젝트에 연결해 보세요.
FAQ
8개 스킬을 모두 직접 호출해야 하나요?
주로 better-interface와 interface-review를 호출하고 나머지 여섯 개는 문맥에 따라 조율됩니다.
quick과 full의 차이는 무엇인가요?
quick은 주 경로와 높은 심각도 중심, full은 빈 상태·오류·좁은 화면까지 넓게 봅니다.
가장 먼저 볼 항목은 무엇인가요?
접근 가능한 이름, 키보드 경로, 포커스 표시처럼 사용 자체를 막는 문제입니다.
당신이라면 이 기술을 어느 실험부터 적용할지 DAKER에 남겨 주세요.
출처
아래 원문과 공식 자료를 기준으로 작성했습니다. 수치와 기능은 각 자료의 공개 시점을 기준으로 확인해 주세요.