긴 이름을 위한 UI 설계: 줄바꿈, 말줄임, 전체 보기의 선택

이름을 잘라도 되는 조건은 남은 글자로 올바른 항목을 식별할 수 있고, 필요할 때 전체 값을 확인할 수 있는 것입니다. 문서 세 개의 앞부분이 길고 같다면 끝에 말줄임표를 붙였을 때 모두 같은 이름처럼 보일 수 있습니다. 사용자가 찾는 차이를 숨긴다면 열이 가지런해 보여도 소용이 없습니다.

실용적인 UI 타이포그래피 체계(영어)를 바탕으로, 이름의 어느 부분이 작업에 필요한지 정합니다. 모든 글자가 들어갈 때까지 글자 크기를 줄이는 것은 정보 문제를 가독성 문제로 바꾸는 일입니다.

선택을 바꾸는 이름의 부분 찾기

프로젝트 산출물을 선택하는 화면에 다음 파일 세 개가 있다고 가정해 보겠습니다.

• Northstar_customer-onboarding_research-notes.pdf
• Northstar_customer-onboarding_flow-v03.pdf
• Northstar_customer-onboarding_flow-v04-approved.pdf

사용자는 승인된 플로를 찾아야 합니다. 앞부분의 프로젝트 이름은 맥락을 주지만, 올바른 파일을 구분하는 부분은 끝에 있습니다. 좁은 패널에서 세 파일을 모두 “Northstar_customer-on…”으로 표시하면 선택에 꼭 필요한 정보가 사라집니다.

표시 방식을 고르기 전에 각 값의 어느 부분이 식별, 비교, 행동을 돕는지 확인하세요. 고객 이름은 앞부분으로 구분할 수 있지만 파일명에는 확장자와 버전 표시가 필요할 수 있습니다. 레코드 식별자는 모든 문자가 중요할 수도 있습니다. 같은 위치의 말줄임표가 세 경우를 모두 해결하지는 못합니다.

디자인 검증에는 실제로 예상되는 극단적인 콘텐츠를 넣습니다. 짧은 값, 보통 길이의 값, 유난히 긴 값, 끝부분만 다른 여러 값을 준비하세요. 무작위로 긴 임시 문구를 넣으면 넘침은 찾을 수 있어도 식별 문제는 놓칠 수 있습니다.

줄바꿈에 쓰는 공간이 작업에 도움이 되는지 보기

이름이 핵심 콘텐츠라면 줄바꿈이 가장 분명한 선택일 때가 많습니다. 두 줄은 목록을 훑어보기 쉽게 유지하면서 항목을 구분하는 글자를 더 남길 수 있습니다. 산출물 선택 화면에서는 장식용 썸네일을 옆에 끼워 넣는 것보다 파일명을 줄바꿈하는 편이 유용할 수 있습니다.

행 높이가 달라지면 다른 요소에도 영향이 생깁니다. 보조 정보의 정렬을 의도적으로 정하고, 버튼이 어느 항목에 속하는지 유지하며, 긴 이름 때문에 유일한 조작 수단이 패널 밖으로 밀리지 않게 합니다. 짧은 행 사이에 긴 행 하나만 넣지 말고, 긴 행이 여러 개 이어지는 상황을 시험하세요.

줄 수를 제한해도 전체 값을 공개하는 규칙은 필요합니다. 세 번째 파일명이 두 줄을 넘는다면 어디에서 전체 이름을 읽고 복사할지 정해야 합니다. “두 줄”은 레이아웃 제약이지, 중요한 글자가 모두 들어간다는 보장이 아닙니다.

식별자나 공백 없는 긴 문자열처럼 자연스럽게 끊기 어려운 값은 개발자와 줄바꿈 동작을 정합니다. 화면에서 줄이 바뀌었다고 사용자가 복사한 값에 문자가 추가되어서는 안 됩니다.

덜 중요한 부분을 생략하기

이 예시에서 “Northstar_…_flow-v04-approved.pdf”처럼 중간을 줄이면 프로젝트 단서와 식별에 필요한 끝부분을 남길 수 있습니다. 시험해 볼 만한 안이지 무조건 정답은 아닙니다. 폭이 더 좁아지면 끝부분이 대부분을 차지해 프로젝트 맥락을 잃을 수 있습니다. 이때는 줄바꿈이나 내용에 집중할 수 있는 상세 화면이 더 분명할 수 있습니다.

MDN의 text-overflow 설명(영어)은 잘린 넘침을 어떻게 표시하는지 다룹니다. 이 속성이 스스로 넘침 조건을 만들거나 전체 값을 읽는 방법을 제공하지는 않습니다. 중간 생략에도 적절한 구현이 필요합니다. 디자이너가 임의의 중앙 위치를 자르도록 지정하고 CSS 설정 하나가 그대로 재현할 것이라고 가정해서는 안 됩니다.

말줄임표는 글자가 생략되었음을 전달하는 기호로 사용하고, 완전한 값 뒤에 장식처럼 붙이지 않습니다. 원래 이름은 보존합니다. 파일명을 복사하면 일반적으로 축약된 화면 표시가 아니라 전체 파일명이 복사되어야 합니다.

마우스를 올리지 않아도 전체 값에 접근하게 하기

포인터 기기에서는 호버 툴팁으로 짧은 라벨을 보완할 수 있지만, 중요한 문구에 접근하는 유일한 경로로 삼으면 안 됩니다. 터치 사용자는 안정적인 호버 상태를 쓸 수 없고 키보드 사용자도 도달 가능한 동작이 필요합니다. 작업에 따라 행 펼치기, 상세 패널, 이름이 분명한 전체 보기 버튼, 연결된 상세 페이지가 더 유용할 수 있습니다.

이름을 누르면 파일이 열리는 경우에는 이미 기본 동작이 있습니다. 첫 탭은 예상치 못하게 툴팁을 열고 두 번째 탭은 파일을 여는 방식으로 만들지 마세요. 차이가 중요한 곳에서는 열기, 선택, 전체 이름 보기를 구분합니다. 이 선택 화면에서는 행으로 산출물을 선택하고, 명확한 상세 버튼으로 전체 이름, 종류, 버전을 확인하게 할 수 있습니다.

호버나 포커스로 별도 콘텐츠를 표시한다면 WCAG 성공 기준 1.4.13 안내(영어)를 참고하세요. 지정된 예외와 함께 닫을 수 있어야 하고, 표시된 내용 위로 포인터를 옮길 수 있어야 하며, 필요한 동안 유지되어야 한다는 동작을 설명합니다. 포인터를 가까이 가져가면 사라지거나 다음 조작을 가리는 툴팁은 안정적으로 읽을 수 있는 공간이 아닙니다.

구현에서는 적절한 접근성 의미 구조를 통해 전체 텍스트를 제공하고 실제 읽히는 방식을 시험합니다. 같은 이름을 두 번 읽게 만드는 추가 접근성 라벨을 무작정 붙이지 마세요. 화면으로 접근하든 보조 기술로 접근하든 어떤 레코드를 선택하는지 일치해야 합니다.

Pixso에서 같은 이름을 두 폭으로 비교하기

Pixso 디자인 파일에 폭 280px의 선택 패널과 폭 640px의 표를 만듭니다. 이 수치는 이번 검증을 위한 폭이며 보편적인 분기점이 아닙니다. 두 레이아웃에 파일명 세 개를 모두 배치합니다. 특정 안을 좋아 보이게 하려고 문자열을 바꾸지 말고 줄바꿈, 끝 생략, 중간 생략을 비교하세요.

간결한 목록 옆에는 선택 상태와 전체 이름을 보여 주는 상세 화면을 둡니다. 리뷰어에게 승인된 플로를 찾고 전체 이름을 복사해 달라고 요청하세요. 모든 파일을 열어야 구분할 수 있다면, 글자가 넘치지 않더라도 그 표시 방식은 작업을 해결하지 못한 것입니다.

반드시 보여야 하는 부분과 전체 값을 확인하는 위치를 주석으로 남깁니다. 제안한 중간 생략 로직도 개발 전달 사항에 기록하세요. 정적인 프레임은 의도한 결과를 보여 줄 뿐이며, 실제 텍스트 처리는 구현 단계에서 시험해야 합니다.

Pixso에서 긴 콘텐츠 레이아웃 비교하기 →

글자 대신 레이아웃을 바꿔야 할 때

카드 높이를 맞추려고 오류 메시지의 필요한 부분을 숨기지 마세요. “제출하려면…” 뒤의 조건이 사라지면 사용자는 행동할 수 없습니다. 문구를 줄바꿈하거나, 계속 확인할 수 있는 적절한 영역으로 옮깁니다.

금액, 안전 지침, 상태를 한정하는 말, 행동 라벨도 마찬가지입니다. “선택 항목 삭제…”는 무엇을 삭제하는지 숨길 수 있습니다. 음수 기호나 단위가 생략되면 값의 의미가 달라집니다. 말줄임표가 무해하다고 판단하기 전에 정보의 우선순위를 정하세요.

좁은 UI에서 라벨을 설명하려고 긴 오버레이를 계속 띄워야 한다면 정보 밀도를 다시 봅니다. 보조 정보를 덜어 내거나, 상세 내용을 명확한 다음 단계로 옮기거나, 식별 정보에 더 많은 폭을 배정하세요. 추가 내용에 별도 공간이 꼭 필요하다면 툴팁·팝오버·대화상자 비교(영어)가 도움이 됩니다. 다만 빽빽한 행마다 쓰는 임시 해결책이 되어서는 안 됩니다.

텍스트가 바뀌면 결정을 다시 검증하기

글자 수만으로 글꼴, 언어, 문자 체계에 따른 실제 너비를 예측할 수는 없습니다. 번역한 라벨은 다른 위치에서 줄바꿈될 수 있고, 지정한 글꼴이 없으면 치수가 달라질 수 있습니다. 사용자가 글자를 확대하면 원래 예시에 있던 공간이 사라질 수도 있습니다. 다른 곳의 글꼴 견본만 보지 말고, 같은 인터랙션 안에서 지원하는 문자와 긴 번역 문구를 시험합니다.

좁은 폭과 확대된 텍스트로 목록을 확인한 뒤, 키보드와 터치로 전체 값에 접근해 보세요. 포커스 표시와 버튼이 보이는지, 복사 결과가 원래 데이터인지도 확인합니다. 산출물 선택 화면의 최종 질문은 단순합니다. 추측하지 않고 승인된 플로를 조사 메모와 이전 버전에서 구별할 수 있나요?