UI 컴포넌트 이름 헷갈릴 때, 동작 계약까지 뽑아주는 퀴즈형 도구

• NameThatUI는 “이 UI 요소 이름이 뭐지?”를 맞히는 퀴즈처럼 보이지만, 실제 목표는 구현 가능한 UI 계약을 뽑아내는 쪽에 가까움

  • 웹 인터페이스 전용 도구이고, 사용자가 본 UI 요소의 생김새나 행동을 설명하면 가능한 UI 패턴을 비교해줌
  • “작은 팝업”처럼 애매한 시각적 라벨보다 “포커스하면 카드가 열리고 안에 링크가 있다” 같은 관찰 가능한 행동을 더 중요하게 봄

• 이 도구가 강조하는 첫 단계는 이름을 찍는 게 아니라 증거를 모으는 것임

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

• 비슷한 후보를 일부러 2-3개 남겨두는 것도 포인트임

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

• 최종 출력은 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 개념으로 닫아둔 것도 의미가 있어요. 아무 이름이나 그럴듯하게 붙이는 도구가 아니라, 검토된 후보 안에서만 답하고 근거가 부족하면 매칭하지 않는 쪽이 실제 구현에서는 더 덜 위험해요.