코딩 에이전트 UI 리뷰, 8개 스킬이 바꾼 점검 순서 | DAKER 커뮤니티
코딩 에이전트로 UI를 손볼 때 가장 먼저 바뀌는 것은 종종 그림자나 모서리 같은 표면 요소입니다. 하지만 실제 사용성에 더 큰 영향을 주는 키보드 접근, 잘리는 경로, 좁은 화면 대응은 그대로 남기 쉽습니다. 그래서 지금 필요한 것은 무엇을 먼저 볼지에 대한 기준입니다.
interfaces는 바로 이 순서를 고정합니다. 표면 장식보다 접근성과 구조를 먼저 보고, 그다음 레이아웃과 문구, 타이포그래피, 색, 시각적 마무리로 이어지도록 UI 리뷰 기준을 8개 스킬로 나눠 운영합니다.
핵심 요약
interfaces는 접근성, 레이아웃, 문구, 타이포그래피, 색, 시각적 마무리를 분리하고 두 개의 조율 스킬을 더해 UI 리뷰 기준을 8개 스킬로 운영합니다.
무엇이 달라졌나
이 구조의 핵심은 각 규칙의 소유권을 겹치지 않게 나누는 데 있습니다. 여섯 도메인 스킬은 각자 맡은 규칙만 다루고, better-interface가 접근성부터 시각적 마무리까지 순서대로 호출합니다. 여기에 interface-review가 변경 범위를 해석해 지적 사항을 Introduced, Regression, Pre-existing로 나눕니다.
리뷰 방식도 모드에 따라 구분됩니다. quick 모드는 최대 5개, full 모드는 최대 15개를 보고하지만, 차단 수준 문제는 이 상한보다 먼저 남깁니다. 즉 많이 지적하는 것보다 먼저 막아야 할 문제를 앞세우는 방식입니다.
왜 지금 중요할까
짧은 프롬프트만으로 UI를 검토하면 무엇을 봐야 하는지보다 눈에 띄는 것을 먼저 고치기 쉽습니다. 이때 리뷰 순서와 증거 형식을 문서로 고정해 두면 팀마다 달라지는 지적을 줄일 수 있습니다. 특히 접근 가능한 이름이나 포커스 표시처럼 사용 자체를 막는 문제를 표면 개선보다 앞에 둘 수 있다는 점이 중요합니다.
접근 가능한 이름, 키보드 경로, 포커스 표시처럼 사용 자체를 막는 문제가 가장 먼저 검토되어야 합니다.
다만 이미 디자인 시스템이 있는 팀이라면 새 규칙을 덧붙이기보다 기존 문서를 스킬화하는 편이 더 자연스럽습니다. 기준이 이미 있다면 그것을 일관되게 실행하는 방식이 더 효과적이기 때문입니다.
실무에서 볼 기준
| 항목 | 확인 내용 | 판단 기준 |
|---|---|---|
| 접근성 | 의미 구조·키보드·이름 | 차단 문제 우선 |
| 레이아웃 | 공간·반응형·잘림 | 320px 확인 |
| 문구·타이포 | 표현과 읽기 흐름 분리 | 소유권 중복 방지 |
| 색·마무리 | 대비 측정 뒤 시각 개선 | 표면 수정은 마지막 |
적용할 때 기억할 점
이 기준은 UI 리뷰의 순서를 정리하는 데 초점이 있습니다. 따라서 정확성, 보안, 성능 리뷰를 대신하지는 않습니다. 또 문서형 규칙이기 때문에 실제 검사 결과는 사용하는 에이전트 모델에 따라 달라질 수 있습니다.
적용 범위도 구분할 필요가 있습니다. 이 규칙은 웹 플랫폼 중심이므로 네이티브 앱이나 게임 UI에 그대로 옮기기보다는 맥락에 맞게 조정하는 것이 좋습니다. 기존 디자인 시스템과 충돌한다면 새 규칙을 추가하기보다 팀의 확정된 기준을 먼저 정리하면 됩니다.
함께 보면 좋은 자료
DAKER 리서치, DAKER 학습, DACON 대회에서 이 기준을 실제 프로젝트와 연결해 볼 수 있습니다.
FAQ
8개 스킬을 모두 직접 호출해야 하나요?
주로 better-interface와 interface-review를 호출하고 나머지 여섯 개는 문맥에 따라 조율됩니다.
quick과 full의 차이는 무엇인가요?
quick은 주 경로와 높은 심각도 중심, full은 빈 상태·오류·좁은 화면까지 넓게 봅니다.
가장 먼저 볼 항목은 무엇인가요?
접근 가능한 이름, 키보드 경로, 포커스 표시처럼 사용 자체를 막는 문제입니다.
참고 자료
당신의 팀이라면 이 8개 스킬 중 어떤 순서 고정부터 먼저 실험해 보고 싶은가요?