이 글은 2026년 11월 6일에 썼습니다.
AI 도구는 하루가 다르게 바뀝니다. 하지만 사용자가 요청한 작업이 제대로 처리되었는지 피드백을 전달해야 하는 의무는 쉽게 변하지 않습니다. button, link, label, error, toast, skeleton, empty state, tooltip. 이 요소들은 페이지가 사용자에게 응답하는 구체적인 방법입니다. 아이콘의 트렌드는 달라질 수 있어도, 정직하게 결과를 알려주는 규칙은 그대로 남습니다. 이 글은 부품 목록 안내서가 아니라 화면의 정직함에 관한 가이드입니다.
응답을 제대로 주지 않는 페이지를 만나면 사람들은 같은 버튼을 두 번씩 누르게 됩니다. 첫 번째 누름이 제대로 전달되었다는 확인을 받지 못했기 때문입니다. AI 모델은 버튼을 누르는 모양은 잘 그려내지만, 별도로 명시해서 요청하지 않으면 처리 결과에 대한 응답을 제대로 그리지 못합니다. 응답은 한갓 장식이 아닙니다. 실제로 예약을 받아 처리하는 진짜 폼과, 겉모습만 그렇게 보이는 껍데기 폼을 가르는 핵심 요소입니다.
button은 작업을 실행하고, link는 다른 장소로 이동한다
button은 현재 화면에서 무언가를 변경하는 조작을 수행합니다. 데이터 보내기, 저장하기, 예약하기, 삭제하기 등이 이에 해당합니다. link는 완전히 다른 공간으로 이동시키는 역할을 합니다. 내일의 일정 페이지, 지도 화면, 이용 약관 등이 대표적입니다. AI 모델이 모든 텍스트 요소를 button으로 구성해 버리면 사용자는 이동과 행동을 구분하기 어려워집니다. 반대로 모든 행동 조작을 link로 만들어버리면, “삭제” 같은 중요한 행동이 그저 페이지 이동처럼 보이고 실제로 새 페이지로 이동해버리는 더 나쁜 상황이 발생합니다. 프롬프트를 작성할 때 동작을 나타내는 동사에는 button을, 목적지로 이동하는 경로에는 link를 명확히 지정해 주십시오. 화면에서 가장 두드러지는 주 button은 하나면 충분합니다. 나머지 보조 조작들은 더 조용하게 표현되어야 합니다. 주 button이 두 개 이상 배치되어 있다면, 그것은 페이지가 우선순위를 제대로 정하지 못하고 다투고 있는 모양새입니다.
button에 들어갈 텍스트는 나중에 결과로 확인할 수 있는 명확한 동사로 적어주어야 합니다. “진료 예약하기”는 작업 완료 후 결과를 확인할 수 있는 명확한 표현입니다. 하지만 “계속”이나 “확인” 같은 단어는 무엇이 처리되었는지 구체적으로 알 수 없습니다. 한국어 사용자를 위한 서비스라면 사용자 눈에 보이는 버튼 문구는 당연히 한국어로 적어야 합니다. 다만 AI에 붙여넣을 부품 명칭인 button, link라는 단어는 영어로 유지해주시면 됩니다.
form은 정확한 이름이 붙은 질문들의 집합이다
form은 그저 회색 입력 상자들을 쌓아놓은 묶음이 아닙니다. 각 입력 상자는 input이며, 모든 input에는 텍스트를 입력하기 시작해도 사라지지 않는 명확한 label이 위에 붙어 있어야 합니다. 상자 안에 옅게 적힌 placeholder 텍스트는 보조 힌트일 뿐, 입력 칸의 진짜 이름이 아닙니다. 글자를 입력하는 순간 placeholder가 사라지면 사용자는 자신이 무엇을 적던 칸이었는지 잊어버리게 됩니다. 번역 작업을 하는 사람이나 스크린 리더 도구 역시 사라진 이름을 읽어낼 수 없습니다. 모든 input 상자 위에 읽는 사람의 언어로 된 label을 눈에 보이게 배치하라고 프롬프트에 명시하십시오.
error 메시지는 해당 input 바로 곁에 명확한 글자로 표시되어야 하며, 여러 칸에서 동시에 오류가 발생했다면 양식 상단에도 요약하여 함께 보여주어야 합니다. 색상만으로 error 상태를 표현해서는 안 됩니다. 빨간색과 초록색 구분은 색각 이상을 가진 많은 이들의 눈에 제대로 구분되지 않으며, 모델이 가장 쉽게 때워버리는 방식이기도 합니다. 프롬프트에는 “색상뿐만 아니라 반드시 해당 입력 칸 옆에 명확한 글자로 error를 표기할 것”이라고 작성해 주십시오.
필수 입력 여부를 단순히 별표(*) 하나에 의존하지 마시고 명확한 조건으로 적어줍니다. 어떤 칸을 비워두어도 되는지 명시하십시오. 어느 나라에서는 필수 입력 항목인 전화번호가 다른 나라에서는 선택 사항일 수 있습니다. 이러한 세부 기준은 영어 프롬프트 아래에 자신의 언어로 구체적으로 적어주시면 됩니다.
사라지는 소식, 남는 소식, 그리고 빠뜨리기 쉬운 소식
toast(snackbar라고도 부릅니다)는 작업 수행 후 나타났다가 몇 초 뒤 스스로 사라지는 짧은 알림이며, 주로 화면 아래쪽에 배치됩니다. “저장되었습니다.”, “링크가 복사되었습니다.”처럼 3초 정도면 충분한 소식에 씁니다. 실패나 오류에 대한 유일한 기록을 toast로 처리해서는 안 됩니다. 오류 메시지는 사용자가 내용을 수정할 때까지 해당 입력 칸 옆이나 form 상단에 계속 남아있어야 합니다. “예약에 실패했습니다”라는 중요한 메시지를 toast로 띄웠다가 슥 사라지게 만들면, 사용자는 소통을 잃어버리게 됩니다.
skeleton은 진짜 데이터가 로딩되어 오기 전까지 화면의 틀을 회색 상자 형태로 미리 보여주는 요소입니다. 아무것도 없는 흰 화면으로 멍하니 대기하게 만드는 것보다 낫고, 무슨 일이 일어나는지 설명도 없는 돌아가는 로딩 아이콘(spinner)보다 훨씬 훌륭합니다. 데이터 목록을 새로 불러올 때 활용합니다. 다만 이것을 영구적인 화면 디자인으로 굳혀서는 안 됩니다. 데이터를 끝내 불러오지 못했다면, skeleton은 로딩을 포기하고 empty state 화면으로 전환되어야 합니다.
empty state는 아직 보여줄 데이터나 콘텐츠가 없을 때 나타나는 전용 화면입니다. 예약 내역 없음, 이번 주 등록된 수업 없음, 검색 결과 없음 등의 상황입니다. 비어 있다는 사실을 명확한 이름으로 안내하고, 다음 행동으로 이어지는 버튼 하나를 제시해 줍니다. 빈 테이블 틀만 덩그러니 남겨두는 것은 empty state가 아닙니다. 그것은 사용자에게 성의 없이 어깨를 으쓱해 보이는 화면일 뿐입니다. 작은 조직에서 자주 빠뜨리곤 하지만, 방문자가 서비스 첫날 목록이 비어 있을 때 가장 먼저 만나게 되는 중요한 화면입니다.
tooltip은 마우스 커서를 올리거나 키보드 포커스가 닿았을 때 짧은 부연 설명을 띄워주는 요소로, 그렇지 않으면 의미를 알기 어려운 아이콘의 도움말용입니다. 중요한 정책이나 핵심 안내문을 넣어두는 장소가 아니며, 모바일 환경에서는 툴팁 동작을 신뢰하기 어렵습니다. 만약 그 내용이 정말 중요하다면 화면에 항상 보이는 텍스트로 써야 합니다. tooltip은 보조적인 label 역할일 뿐, 문서나 설명문이 아닙니다.
두 번째 버튼 누름이 일어나는 이유
어느 학부모가 퇴근길 버스 안에서 휴대폰으로 자녀의 수업을 신청하고 있었습니다. 신청 버튼에는 그저 “계속”이라고만 적혀 있었습니다. 버튼을 누른 후 화면에는 아무런 반응도 보이지 않았고, 불안해진 학부모는 버튼을 한 번 더 눌렀습니다. 결국 센터에는 동일한 신청이 두 건 접수되었습니다. 안내 데스크에서는 학부모의 조작 실수라고 말했지만, 진짜 원인은 페이지의 피드백 부재였습니다. “계속”은 결과를 확인할 수 있는 동사가 아니었고, 아무런 응답이 없는 화면은 신청이 접수되었다는 확인이 될 수 없었던 것입니다.
제대로 작동하는 응답성 높은 페이지는 기본에 충실합니다. 버튼에는 학부모의 언어로 “이 수업 신청하기”라고 명확히 적혀 있습니다. 각 입력 칸의 label은 글자를 써도 사라지지 않습니다. 전화번호 칸을 비워두면 그 입력 칸 바로 옆에 안내 글자가 나타나 그대로 유지됩니다. 신청이 성공적으로 접수되면 toast 알림이 떠서 접수 사실을 알려준 뒤 자연스럽게 사라지고, form 화면 자체도 학부모가 나중에 다시 확인해볼 수 있는 짧은 접수 확인증 형태로 전환됩니다. 아직 개강 일정이 올라오지 않아 수업 목록이 비어 있다면, empty state 화면이 그 사실을 정직하게 알리고 수업 문의 버튼 하나를 제공합니다. 고장 난 것처럼 보이는 빈 표를 보여주지 않는 것입니다. 이것은 그저 시각적인 스타일의 문제가 아닙니다. 사용자가 결과를 불필요하게 짐작하지 않도록 페이지가 정직하게 응답하는 것입니다.
이러한 구성을 AI에게 프롬프트로 요청할 때 부품 명칭은 영어로 적어줍니다. button, label, error, toast, empty state. 하지만 사용자가 읽을 모든 문장은 해당 지역의 언어로 작성해 주십시오. 영어 label 조건만 전달받은 AI 모델은 사용자에게도 영어 label을 그대로 노출해 버리기 십상입니다. 이는 toast 알림이 빠진 것과는 또 다른 형태의 실패이며, 실무에서 매우 흔하게 발생하는 실수입니다. 화면의 동작 방식이 올바르게 구현되도록 구조 명칭은 영어로 공유하고, 사용자가 방금 자신이 수행한 일을 명확히 알 수 있도록 안내 문구는 본래의 언어로 지켜내는 것입니다.
프롬프트 작성 예시
Build a booking form. Each input has a visible label. Errors are written beside the field in words, not by color alone. After a successful send, show a toast that says the visit is requested and leaves after a few seconds. If sending fails, keep the error on the form. If there are no visits yet, show an empty state with one button to add the first.
이 영문 프롬프트를 제시한 뒤, 실제 label 이름과 error 안내 문장을 읽는 사람의 언어로 구체적으로 작성해 주시면 됩니다. 위의 영어 프롬프트가 화면의 틀과 구조를 잡는다면, 아래에 적히는 문장은 사용자에 대한 배려와 정성입니다. AI 모델은 우리 동네 병원이나 센터에서 어떤 따뜻한 문장으로 안내하는지 알지 못합니다. 그것을 아는 사람은 바로 여러분입니다. 다음 글에서는 화면의 움직임(motion), 그리고 이러한 기본 응답이 모두 갖춰지기 전까지는 미루어 두어도 좋을 장식적 효과들에 대해 이야기합니다.