---
title: "UI 컴포넌트 이름 헷갈릴 때, 동작 계약까지 뽑아주는 퀴즈형 도구"
published: 2026-07-27T09:28:17.000Z
canonical: https://jeff.news/article/5091
---
# UI 컴포넌트 이름 헷갈릴 때, 동작 계약까지 뽑아주는 퀴즈형 도구

NameThatUI는 웹 UI 요소의 이름을 맞히는 데서 끝나지 않고, 비슷한 UI 패턴을 비교한 뒤 구현 가능한 동작 명세로 정리해주는 도구다. Tooltip, Popover, Hover Card처럼 생긴 건 비슷하지만 접근성, 포커스, 닫힘 규칙이 다른 패턴을 구분하는 데 초점을 둔다. 코딩 에이전트나 컴포넌트 라이브러리에 잘못된 이름을 던져서 엉뚱한 구현이 나오는 문제를 줄이려는 접근이다.

- NameThatUI는 “이 UI 요소 이름이 뭐지?”를 맞히는 퀴즈처럼 보이지만, 실제 목표는 구현 가능한 UI 계약을 뽑아내는 쪽에 가까움
  - 웹 인터페이스 전용 도구이고, 사용자가 본 UI 요소의 생김새나 행동을 설명하면 가능한 UI 패턴을 비교해줌
  - “작은 팝업”처럼 애매한 시각적 라벨보다 “포커스하면 카드가 열리고 안에 링크가 있다” 같은 관찰 가능한 행동을 더 중요하게 봄

- 이 도구가 강조하는 첫 단계는 이름을 찍는 게 아니라 증거를 모으는 것임
  - 무엇이 UI를 여는지, 어디에 나타나는지, 뒤쪽 페이지를 계속 쓸 수 있는지, 어떤 콘텐츠가 들어가는지, 어떻게 닫히는지를 적게 함
  - 컴포넌트 이름을 몰라도 괜찮고, 오히려 구체적인 동작 설명이 더 유용하다는 관점임

- 비슷한 후보를 일부러 2-3개 남겨두는 것도 포인트임
  - 첫 키워드 매칭으로 답을 정해버리지 않고, Tooltip, Popover, Hover Card처럼 헷갈리기 쉬운 후보를 비교함
  - 그다음 결과를 바꿀 수 있는 질문만 던져서 후보를 줄이는 식임
  - 생긴 건 비슷해도 상호작용 가능 여부, 유지 시간, 포커스 규칙이 다르면 구현은 완전히 달라질 수 있음

> [!IMPORTANT]
> 이 도구의 핵심은 UI 용어 암기가 아니라 “테스트 가능한 구현 브리프”임. 잘못된 이름 하나가 접근성, 키보드 조작, 모바일 동작까지 줄줄이 틀리게 만들 수 있다는 문제의식이 깔려 있음.

- 최종 출력은 production code가 아니라 구현 명세임
  - 트리거, 닫힘 방식, 모달 여부, 포커스, 키보드 동작, 배치, 모바일 동작을 정리함
  - 제외된 대안과 관찰 가능한 acceptance check도 함께 남김
  - 코딩 에이전트에게 이 브리프를 넘긴 뒤, 라벨을 믿는 게 아니라 결과 동작을 검증하라는 흐름임

- UI element, UI component, UI pattern을 구분하는 설명도 꽤 실용적임
  - UI element는 사용자가 화면에서 볼 수 있는 버튼, 필드, 패널, 아이콘 같은 넓은 표현임
  - UI component는 디자인 시스템이나 코드베이스에서 재사용되는 구현 단위임
  - UI pattern은 특정 인터페이스 문제를 풀기 위한 반복 가능한 해법이고, 트리거·포커스·키보드·닫힘·배치·모바일 적응까지 포함함

- 이름이 중요한 이유는 이름이 곧 구현 가정이 되기 때문임
  - 사용자가 떠 있는 표면 안의 링크를 클릭해야 하는데 Tooltip이라고 부르면 접근성상 맞지 않는 구현이 나올 수 있음
  - 사용자가 옵션을 입력하고 필터링해야 하는데 Select라고만 부르면 필요한 작업을 막는 UI가 될 수 있음
  - 결국 유용한 결과는 단어 하나가 아니라, 그 단어가 암시하는 행동 계약을 검증하는 것임

- NameThatUI는 닫힌 범위의 도구라는 점도 명확히 밝힘
  - 39개 웹 UI 개념을 대상으로 후보를 검토함
  - 근거가 부족하면 무조건 답을 내는 대신 “맞는 항목 없음”을 반환할 수 있음
  - 프레임워크 중립적인 구현 브리프와 관찰 가능한 체크를 제공하지만, 실제 컴포넌트 라이브러리 선택과 검증은 사용자가 해야 함

---

## 기술 맥락

- 이 도구가 다루는 선택은 “UI를 이름으로 지시할 것인가, 행동 계약으로 지시할 것인가”예요. 왜냐하면 Tooltip, Popover, Hover Card는 화면에 떠 있는 작은 표면처럼 보일 수 있지만, 포커스와 닫힘, 내부 상호작용 규칙이 다르거든요.

- 특히 코딩 에이전트에게 UI를 맡길 때 이 차이가 커져요. 에이전트는 사용자가 쓴 컴포넌트 이름을 강한 힌트로 받아들이기 쉬운데, 이름이 틀리면 키보드 조작이나 접근성 기대치까지 틀어진 구현을 만들 수 있어요.

- NameThatUI는 그래서 코드를 바로 생성하지 않고 브리프를 만들어요. 트리거, dismissal, modality, focus, keyboard behavior, placement, mobile behavior, excluded alternatives 같은 항목을 남기는 이유는 나중에 사람이든 에이전트든 같은 기준으로 결과를 테스트할 수 있게 하려는 거예요.

- 범위를 39개 웹 UI 개념으로 닫아둔 것도 의미가 있어요. 아무 이름이나 그럴듯하게 붙이는 도구가 아니라, 검토된 후보 안에서만 답하고 근거가 부족하면 매칭하지 않는 쪽이 실제 구현에서는 더 덜 위험해요.

## 핵심 포인트

- NameThatUI는 웹 인터페이스 전용 UI 패턴 진단 도구이며, 닫힘 방식·포커스·키보드 동작 같은 관찰 가능한 행동을 기준으로 패턴을 좁힌다.
- 최종 결과는 코드가 아니라 트리거, 모달 여부, 배치, 모바일 동작, 제외된 대안, 검증 기준을 담은 구현 브리프다.
- 도구는 39개 웹 UI 개념의 닫힌 집합을 다루며, 근거가 부족하면 맞지 않는 이름을 억지로 내지 않을 수 있다.

## 인사이트

요즘 코딩 에이전트에게 UI를 맡길수록 “이거 팝오버야, 툴팁이야, 호버 카드야?” 같은 이름 문제가 바로 구현 품질 문제가 된다. 이 도구는 용어 맞히기 놀이처럼 보이지만, 실제로는 UI 요구사항을 테스트 가능한 계약으로 바꾸는 쪽에 가깝다.