몇 년 전만 해도 코딩을 배운 적 없는 사람이 혼자 웹사이트나 앱을 만든다는 말은 꽤 먼 이야기처럼 들렸다.
이제는 사정이 다르다.
원하는 화면을 말로 설명하고 몇 번 대화를 주고받으면 AI가 즉석에서 시제품을 만들어 준다. 아이디어를 화면으로 옮기는 첫 문턱이 확 낮아진 것이다.
물론 화면을 일단 띄우는 일과 실제 서비스로 완성하는 일은 다르다. 정식으로 운영하려면 보안, 데이터 처리, 오류 수정과 유지보수까지 살펴야 한다.
그런데 생각보다 많은 사람이 그 단계에 가기도 전에 훨씬 사소한 지점에서 막힌다. 머릿속에는 분명한 그림이 있는데, 그걸 AI에게 정확히 건넬 단어가 떠오르지 않는 것이다.
- “오른쪽에 메뉴 같은 게 나왔으면 좋겠어.”
- “스크롤할 때 좀 더 자연스럽게 움직이게 해 줘.”
- “여기에 버튼을 두고, 마우스를 올리면 볼록하게 튀어나오게 해 줘.”
사람 사이에서도 뜻이 갈릴 만한 이런 요청을 보내면, AI는 빠진 빈칸을 스스로 추측해 메운다. 화면은 그럴듯하게 나오지만 내가 상상한 모습과는 어딘가 어긋나기 일쑤다. 코드를 몰라서가 아니다. 원하는 대상을 콕 집어 가리킬 ‘정확한 이름’을 모르기 때문이다.
이번 글에서는 이런 시행착오를 줄여 주는 가장 확실한 방법 중 하나로, 원하는 화면을 단번에 가리키는 ‘필수 UI 용어 24가지’를 살펴본다.
가장 자주 쓰이는 24개 화면을 직접 움직여 보며 이해하고, AI 프롬프트에 어떻게 넣어 쓰는지 활용법까지 함께 정리했다.
아울러 왜 정확한 이름을 쓰는 일이 개발 결과를 바꾸는지도 실제 프롬프트 사례와 심리학·코딩 실험 연구를 통해 짚어 본다. 코딩 초보자뿐 아니라 사람과 AI의 소통 방식을 연구하는 교육·심리학자, 머릿속 아이디어를 직접 구현하려는 기획자와 1인 제작자에게도 실질적인 도움이 될 것이다.
왜 일상적인 설명보다 ‘정확한 이름’이 도움이 될까?
인테리어 공사를 할 때 “천장 가장자리에 파여서 불빛이 은은하게 새어 나오는 부분”이라고 길게 설명해도 뜻은 통한다. 하지만 ‘간접조명 우물천장’이라는 이름을 쓰면 작업자와 내가 떠올리는 그림이 단숨에 하나로 모인다.
웹 화면도 마찬가지다.
디자이너나 AI에게 “설정 버튼을 누르면 옆에서 서랍처럼 열리는 창”이라고 풀어서 말할 수도 있지만, 그 기능을 드로어(Drawer)라고 부르면 어떤 화면인지 훨씬 빠르게 좁혀진다.
반대로 “설정창을 띄워 줘”라는 말만으로는 화면 한가운데 뜨는 모달(Modal)인지, 옆에서 밀려 나오는 드로어인지 구분하기 어렵다. 같은 ‘창’이라도 작동 방식과 사용감은 전혀 다르다.
이 원리는 심리학의 의사소통 연구와도 닿아 있다.
1996년 수전 브레넌과 허버트 클라크는 세 차례의 실험을 통해 사람들이 같은 물체를 반복해서 설명할 때 상대와 합의한 표현을 계속 재사용하는 경향을 확인했다. 대화 상대끼리 특정 대상을 어떻게 부를지 임시로 ‘개념적 합의(conceptual pact)’를 맺고 나면, 이후에도 자연스럽게 같은 이름을 쓰게 되는 ‘어휘적 동조(lexical entrainment)’가 일어난다는 것이다.(1)
물론 이 실험은 사람과 사람 사이의 대화를 다룬 연구이지, UI 용어를 넣은 AI 프롬프트의 성공률을 측정한 실험은 아니다. 다만 서로 다른 머릿속에서 같은 대상을 떠올리려면 먼저 ‘이름’을 맞추는 일이 중요하다는 점을 잘 보여 준다.
바이브 코딩에서도 UI 용어는 내가 원하는 화면과 AI의 결과물을 연결하는 공통 좌표처럼 쓰일 수 있다.
그렇다고 전문용어가 일상적인 설명보다 무조건 우월하다는 뜻은 결코 아니다.
“화면 오른쪽에서 열리는 패널”처럼 충분히 구체적인 묘사도 좋은 요청이다. 다만 정확한 이름을 알면 생김새를 길게 설명하는 데 힘을 빼는 대신, 그 화면이 언제, 어떻게 움직여야 하는지에 더 많은 말을 정확하게 표현 할 수 있다.
실험이 보여 준 AI 코딩의 진짜 장벽은 ‘표현의 정확성’이다
실제 코딩 교육 현장에서도 비슷한 장벽이 확인됐다.
2024년 미국의 한 연구진은 기초 코딩 수업을 마친 대학생 120명을 대상으로 AI에게 코딩을 요청하고 수정하는 과정을 관찰했다. 그 결과, 기초 코딩을 배운 학생들조차 원하는 동작을 AI에게 설명하고, 잘못된 결과가 나왔을 때 요청을 고쳐 쓰는 데 어려움을 겪는다는 사실을 확인했다.
흥미로운 점은 문제를 해결하기 위해 설명을 더 구체적으로 하거나 코딩 전문용어를 추가하는 전략이 나타났다는 것이다. 이 연구는 코딩 지식과 함께 자신이 원하는 기능을 명확한 언어로 전달하는 능력이 중요하다는 사실을 보여 준다.(2)
2025년 또 다른 연구에서는 AI에게 코드 생성을 요청할 때 입출력 조건과 예외 상황, 처리 순서를 구체적으로 적으면 여러 과제에서 결과가 개선되는 것을 확인했다. 중요한 것은 긴 설명이 아니라, AI가 추측해야 할 빈칸을 줄이는 일이었다.(3)
결국 두 연구가 가리키는 해답은 하나다. AI와 일할 때는 대상을 정확히 부르고, 원하는 동작과 조건을 구체적으로 적어 줄수록 시행착오가 줄어든다는 점이다.
같은 아이디어도 이렇게 요청하면 달라진다
그렇다면 실제로는 어떻게 말해야 할까?
[AI 프롬프트 실험기 – “이렇게 쓰면 된다”는 꿀팁 7개! 진짜인지 검증해봤습니다]에서 살펴봤듯, 핵심은 막연한 부탁 대신 구체적인 조건을 건네는 데 있다. 설정 화면을 만들어 달라는 다음 두 요청을 비교해 보자.
- 막연한 요청: “설정 버튼을 누르면 오른쪽에 메뉴 같은 게 예쁘게 나오게 해 줘.”
- 구체적인 요청: “설정 버튼을 누르면 오른쪽에서 드로어(Drawer)가 열리게 해 줘. 패널 바깥을 클릭하거나 ESC를 누르면 닫히고, 모바일 화면에서도 사용할 수 있게 해 줘.”
두 번째 문장은 전문용어 하나만 덧붙인 것이 아니다. 화면의 종류(드로어), 열리는 방향(오른쪽), 닫히는 조건(바깥 클릭·ESC), 기기 환경(모바일)까지 빈칸을 미리 채워 두었다. AI가 임의로 추측해야 할 여지가 줄어드니 결과물이 내 의도에 훨씬 가까워진다.
실전에서는 복잡한 프롬프트 기법 대신 아래 공식 하나만 기억해도 충분하다.
당장 용어가 떠오르지 않는다면 “버튼을 누를 때 옆에서 나오는 메뉴를 UI 용어로 뭐라고 해?”라고 AI에게 먼저 물어봐도 된다.
이름을 익히는 목적은 개발자처럼 유창하게 보이려는 데 있지 않다.
내 머릿속 화면을 덜 잃어버리고 전달하기 위해서다.
이제 직접 써 보자: 바이브 코딩 UI 용어 24가지
아래 치트시트가 이 글의 주인공이다.
웹 화면의 큰 뼈대를 잡는 레이아웃 7개, 누르고 조작하는 부품인 컴포넌트 9개, 생동감과 움직임을 더하는 효과 8개를 한곳에 모았다. 본문에서 24개를 따로 외울 필요 없이, 필요한 순간에 눈으로 보고 바로 꺼내 쓰면 된다.
사용법은 간단하다.
검색창에 ‘서랍’, ‘모달’, ‘스크롤’처럼 떠오르는 단어나 영어 용어를 입력하거나, 상단의 ‘레이아웃·컴포넌트·효과’ 필터를 눌러 범위를 좁힌다.
- PC에서는 카드에 마우스를 올리면 움직임이 재생되고, 조작형 데모는 직접 클릭해 볼 수 있다.
- 모바일에서는 화면을 내릴 때 카드에 들어온 애니메이션이 자동으로 재생된다.
- 각 카드에 펼쳐져 있는 AI 프롬프트는 복사 버튼을 눌러 그대로 가져간 뒤, 내 프로젝트 조건에 맞게 숫자나 문구만 조금 고쳐 쓰면 된다.
바이브 코딩 UI 필수 용어 24 CHEAT SHEET
코드깎는노인 채널의 핵심 UI 용어 24가지를 체험형으로 정리했습니다. 카드에 마우스를 올리면 움직임을 바로 볼 수 있고, 조작형 화면은 직접 클릭해 보세요.
용어를 안다는 것은 결과물을 더 잘 판단할 수 있다는 뜻이다
정확한 용어로 요청했다고 해서 단번에 완벽한 웹사이트가 만들어지는 것은 아니다.
겉모습은 그럴듯한데 탭을 눌러도 내용이 바뀌지 않거나, 모달 창을 닫은 뒤 키보드 포커스가 엉뚱한 곳으로 날아간다면 아직 절반만 완성된 화면이다. 제대로 구현된 모달이라면 창이 열릴 때 키보드 포커스를 내부로 옮겨 가두고, 창을 닫을 때 원래 눌렀던 버튼으로 포커스를 돌려놓아야 한다.(4)
AI가 화면을 만들어 주면 스마트폰 폭으로 줄여서 손가락으로 눌러 보고, 마우스 없이 키보드의 Tab·Enter·ESC 키만으로도 조작해 보자. 화려하게 움직이는 효과를 넣었다면 기기의 ‘움직임 줄이기(prefers-reduced-motion)’ 설정을 켠 사용자에게 어지러움을 주지 않는지도 함께 살펴야 한다.(5)
코드는 AI가 작성하더라도, 그 결과가 내 의도와 사용자의 편의에 맞는지 최종 확인하는 몫은 여전히 사람에게 남아 있다.
24개 용어를 하루아침에 모두 외울 필요는 없다.
원하는 장면이 떠오를 때 이 페이지로 돌아와 이름을 찾고, 움직임을 확인하고, 프롬프트를 복사해 조건을 조금씩 바꿔 보면 된다. 내 생각을 화면으로 옮기는 표현이 하나씩 늘어날수록, AI에게 막연히 “예쁘게 만들어 줘”라고 맡기는 대신 어떤 화면이 왜 그렇게 작동해야 하는지 설명하고 스스로 결과물을 판단하는 눈도 함께 자랄 것이다.
바이브 코딩의 전반적인 개념과 “AI로 만든 앱으로 정말 수익까지 낼 수 있을까?”라는 현실적인 가능성과 한계가 궁금하다면, 이전 글 「바이브 코딩 – 5분 만에 만든 앱, 3천만 원 수익! 정말일까요?」에서 이어서 살펴볼 수 있다.
출처
- Conceptual pacts and lexical choice in conversation — Brennan & Clark, Journal of Experimental Psychology, 1996
- How Beginning Programmers and Code LLMs (Mis)read Each Other — Nguyen et al., ACM CHI, 2024
- More Than a Score: Probing the Impact of Prompt Specificity on LLM Code Generation — Zi, Menon & Guha, IJCNLP-AACL, 2025
- Dialog (Modal) Pattern — W3C WAI-ARIA Authoring Practices
- prefers-reduced-motion — MDN Web Docs
