비개발자가 알아야 할 최소 개발 용어

용어를 몰라서 막히는 순간

바이브 코딩을 처음 시작하면 이상한 일이 벌어집니다. 분명히 우리는 "독서 기록 앱을 만들어줘"라고 말했을 뿐인데, AI는 어느 순간 이런 말을 꺼냅니다.

"프론트엔드 화면을 수정하겠습니다."

"데이터베이스에 저장되도록 연결하겠습니다."

"CRUD 기능을 추가하겠습니다."

"배포 전에 환경변수를 설정해야 합니다."

이때 많은 초보자는 생각합니다. "아, 역시 코딩은 어려운 거구나." 하지만 여기서 중요한 사실이 있습니다. 이 용어들을 개발자처럼 깊이 알 필요는 없습니다. 우리가 알아야 할 정도는 딱 하나입니다. AI에게 수정 요청을 할 수 있을 만큼만 이해하면 됩니다.

프론트엔드가 무엇인지 몰라도 앱을 만들 수는 있습니다. 하지만 "버튼 색이 이상해요"라고 말하는 것보다 "프론트엔드에서 저장 버튼이 잘 보이도록 색과 크기를 수정해줘"라고 말하면 AI가 훨씬 정확하게 움직입니다. 데이터베이스를 직접 설계하지 않아도 됩니다. 하지만 "입력한 내용이 사라져요"라고 말하는 것보다 "사용자가 입력한 독서 기록이 데이터베이스에 저장되고, 새로고침해도 남아 있게 해줘"라고 말하면 결과가 달라집니다.

이번 장은 개발 용어 시험 대비가 아닙니다. 앱을 만들다가 AI와 대화할 때 자주 만나는 단어들을 생활 속 비유로 익히는 시간입니다. 용어를 외우려 하지 말고, "아, 이 말은 대충 이 부분을 가리키는구나" 정도로 잡으면 충분합니다.

앱을 식당으로 생각해보기

개발 용어는 처음 들으면 차갑고 멀게 느껴집니다. 그래서 이번 장에서는 앱을 하나의 식당이라고 생각해보겠습니다.

손님이 식당에 들어오면 가장 먼저 보는 것은 간판, 메뉴판, 인테리어, 테이블 배치입니다. 앱으로 치면 사용자가 보는 화면입니다. 버튼, 글자, 입력창, 카드, 색상, 이미지, 메뉴가 여기에 들어갑니다. 이것이 프론트엔드입니다.

하지만 식당은 메뉴판만으로 운영되지 않습니다. 손님이 주문하면 주방에서는 재료를 확인하고, 요리를 만들고, 주문 순서를 관리하고, 계산 정보를 처리합니다. 손님 눈에는 잘 보이지 않지만 실제 일이 돌아가는 곳입니다. 앱으로 치면 데이터 저장, 로그인 처리, 계산, 권한 확인 같은 부분입니다. 이것이 백엔드입니다.

그리고 식당에는 장부가 있습니다. 오늘 어떤 주문이 들어왔는지, 재료가 얼마나 남았는지, 단골 손님 정보가 무엇인지 기록해두는 곳입니다. 앱에서는 이 역할을 데이터베이스가 합니다.

또 식당이 혼자 모든 것을 하지 않을 때도 있습니다. 배달 앱을 통해 주문을 받거나, 카드사와 연결해 결제를 처리하거나, 지도 서비스와 연결해 위치를 보여줄 수 있습니다. 앱에서 이렇게 다른 서비스와 연결해주는 통로를 API라고 부릅니다. 식당 비유로 말하면 API는 다른 가게나 서비스와 연결해주는 배달 기사 또는 연락 창구에 가깝습니다.

이 비유만 기억해도 앱 제작 대화가 훨씬 쉬워집니다.

프론트엔드: 손님이 보는 메뉴판과 인테리어

프론트엔드는 사용자가 직접 보고 클릭하는 화면 부분입니다. 식당으로 치면 메뉴판, 인테리어, 테이블 배치, 조명, 안내 문구에 해당합니다.

독서 기록 앱을 예로 들어보겠습니다. 사용자가 책 제목을 입력하는 칸, 별점을 선택하는 버튼, 저장 버튼, 기록 목록 카드, "이번 달에 3권을 읽었어요"라는 문구는 모두 프론트엔드에 해당합니다. 할 일 관리 앱이라면 체크박스, 오늘의 할 일 목록, 완료 표시, 날짜 필터가 프론트엔드입니다. 예약 문의 앱이라면 날짜 선택창, 이름 입력칸, 연락처 입력칸, 문의 내용 작성 칸이 여기에 들어갑니다.

초보자가 프론트엔드를 이해해야 하는 이유는 간단합니다. 우리가 앱을 만들면서 가장 자주 수정 요청하는 부분이 바로 화면이기 때문입니다. "예쁘게 해줘"라는 말은 너무 넓습니다. 대신 이렇게 말하면 훨씬 좋습니다.

프론트엔드 화면을 수정해줘.
전체적으로 모바일에서 보기 편하게 만들고,
저장 버튼은 화면 하단에서 잘 보이게 배치해줘.
입력창 사이 간격을 넓히고,
기록 목록은 카드 형태로 정리해줘.

여기서 코드를 몰라도 괜찮습니다. 중요한 것은 "내가 보는 화면 쪽 문제구나"라고 구분하는 감각입니다.

백엔드: 손님에게 보이지 않는 주방

백엔드는 사용자가 직접 보지는 않지만 앱이 제대로 작동하도록 뒤에서 처리하는 부분입니다. 식당으로 치면 주방입니다. 손님은 주방 안을 보지 못하지만, 주문이 들어가고 요리가 나오려면 주방이 꼭 필요합니다.

예를 들어 강의 후기 수집 앱을 만든다고 해보겠습니다. 수강생이 이름, 별점, 후기를 입력하고 제출 버튼을 누릅니다. 화면에 입력창이 보이는 것은 프론트엔드입니다. 그런데 제출한 후기가 어딘가에 저장되고, 관리자 화면에서 모아 보이고, 중복 제출을 막고, 특정 강의별로 후기를 구분하는 일은 백엔드에 가깝습니다.

백엔드를 처음부터 깊게 이해할 필요는 없습니다. 다만 앱에서 "저장", "불러오기", "로그인", "권한", "계산", "자동 처리"라는 말이 나오면 대체로 백엔드와 관련이 있다고 보면 됩니다.

초보자가 자주 겪는 문제도 여기에 많습니다. 화면에서는 저장됐다고 나오는데 새로고침하면 사라집니다. 로그인한 사람마다 다른 데이터를 보여줘야 하는데 모두에게 같은 내용이 보입니다. 관리자만 봐야 할 정보가 일반 사용자에게도 보입니다. 이런 문제는 단순히 버튼 색을 바꾸는 일보다 난이도가 높습니다.

이럴 때는 AI에게 이렇게 요청할 수 있습니다.

현재 앱에서 입력한 데이터가 새로고침 후 사라집니다.
프론트엔드 화면에만 임시로 보이는 것이 아니라,
백엔드 또는 데이터베이스에 실제로 저장되도록 수정해줘.
저장 후에는 목록 화면에서 다시 불러와 보여줘.

좋은 요청은 문제를 탓하지 않습니다. 어디에서 어떤 일이 일어나야 하는지를 차분히 설명합니다.

데이터베이스: 앱의 장부 또는 엑셀 파일

데이터베이스는 앱이 기억해야 할 정보를 정리해두는 저장소입니다. 쉽게 말하면 장부 또는 엑셀 파일입니다.

소상공인의 예약 문의 앱이라면 고객 이름, 연락처, 희망 날짜, 문의 내용, 처리 상태가 데이터베이스에 저장될 수 있습니다. 운동 루틴 기록 앱이라면 운동 날짜, 운동 종류, 세트 수, 무게, 메모가 저장됩니다. 블로그 글감 저장소 앱이라면 글감 제목, 카테고리, 핵심 문장, 참고 링크, 작성 상태가 저장됩니다.

데이터베이스를 어렵게 느끼는 이유는 "테이블", "필드", "레코드" 같은 말이 함께 나오기 때문입니다. 이것도 엑셀로 생각하면 편합니다. 엑셀 파일 하나에 시트가 있고, 시트에는 열과 행이 있습니다. 데이터베이스의 테이블은 엑셀 시트와 비슷하고, 필드는 열 제목과 비슷하며, 레코드는 한 줄의 기록과 비슷합니다.

예를 들어 독서 기록 앱의 데이터베이스를 엑셀처럼 보면 이런 모습입니다.

초보자가 알아야 할 포인트는 하나입니다. 앱이 기억해야 하는 정보가 있다면 데이터베이스가 필요할 가능성이 높습니다. 반대로 잠깐 입력하고 결과만 보는 계산기 앱이라면 처음에는 데이터베이스가 없어도 됩니다.

AI에게 데이터베이스를 요청할 때는 "무엇을 저장할지"를 구체적으로 말해야 합니다.

독서 기록 앱에 데이터베이스 저장 기능을 추가해줘.
각 기록에는 책 제목, 저자, 읽은 날짜, 별점, 한 줄 메모가 저장되어야 해.
사용자가 기록을 추가하면 목록에 바로 보이고,
새로고침해도 기록이 사라지지 않게 해줘.

"저장되게 해줘"보다 "무엇이 저장되어야 하는지"를 말하는 것이 훨씬 강력합니다.

API: 다른 서비스와 연결해주는 배달 기사

API는 앱과 다른 서비스가 서로 정보를 주고받기 위한 약속된 통로입니다. 식당 비유로는 다른 가게와 연결해주는 배달 기사, 또는 주문 전달 창구라고 볼 수 있습니다.

예를 들어 내 앱에서 날씨 정보를 보여주고 싶다면 날씨 서비스의 API를 사용할 수 있습니다. 주소를 입력하면 지도를 보여주고 싶다면 지도 API를 쓸 수 있습니다. AI가 회의록을 요약해주는 기능을 넣고 싶다면 AI 모델을 제공하는 서비스의 API를 연결할 수 있습니다.

초보자에게 API가 중요한 이유는 "AI 기능"이나 "외부 서비스 연결"을 하고 싶을 때 거의 반드시 등장하기 때문입니다. 하지만 처음 앱을 만들 때부터 API를 꼭 써야 하는 것은 아닙니다. 독서 기록 앱, 할 일 관리 앱, 운동 루틴 기록 앱처럼 입력하고 저장하고 보여주는 구조라면 API 없이도 첫 버전을 만들 수 있습니다.

API가 필요한 예시는 다음과 같습니다.

• 회의록 정리 앱에서 긴 회의 내용을 AI가 요약하게 만들 때

• 예약 문의 앱에서 접수 내용을 문자나 이메일로 보내고 싶을 때

• 가족 일정 공유 앱에서 구글 캘린더와 연동하고 싶을 때

• 블로그 글감 저장소 앱에서 AI가 제목 후보를 추천하게 만들 때

다만 API를 쓸 때는 보안 문제가 함께 따라옵니다. 특히 API 키라는 것이 나오면 조심해야 합니다. API 키는 외부 서비스에 "내가 허가받은 사용자입니다"라고 보여주는 비밀번호 같은 값입니다. 이 값이 화면이나 공개된 코드에 노출되면 다른 사람이 내 계정으로 비용을 발생시킬 수도 있습니다. API 키와 환경변수는 뒤에서 더 자세히 다루겠지만, 지금은 이렇게만 기억하면 됩니다. API 키는 금고 비밀번호처럼 다룬다.

AI에게 API 연결을 요청할 때는 이렇게 말할 수 있습니다.

이 앱에 AI 요약 기능을 추가하고 싶어.
사용자가 회의록 텍스트를 입력하면 AI가 핵심 요약, 결정 사항, 할 일을 나눠서 보여주게 해줘.
API 키는 코드에 직접 적지 말고 환경변수로 관리하도록 구성해줘.
초보자가 나중에 설정할 수 있도록 필요한 값의 이름도 설명해줘.

여기서 중요한 표현은 "코드에 직접 적지 말고 환경변수로 관리"입니다. 아직 정확한 방법을 몰라도 이 문장을 알고 있으면 위험한 실수를 줄일 수 있습니다.

배포: 가게 문을 열고 손님이 들어오게 하는 일

배포는 내가 만든 앱을 다른 사람이 접속할 수 있게 인터넷에 올리는 일입니다. 식당으로 치면 가게 문을 열고 손님이 들어올 수 있게 하는 것입니다.

앱 빌더형 도구에서 작업할 때는 미리보기 화면에서 앱이 잘 보일 수 있습니다. 하지만 미리보기는 주방에서 직원끼리 시식하는 것과 비슷합니다. 친구나 고객, 수강생, 가족에게 링크를 보내 실제로 쓰게 하려면 배포가 필요합니다.

초보자가 배포에서 헷갈리는 지점은 "내 화면에서는 되는데, 다른 사람에게는 안 되는" 상황입니다. 내 작업 공간에서는 잘 작동하지만 공유 링크에서는 데이터가 저장되지 않거나, 모바일에서 화면이 깨지거나, 로그인 없이 접근하면 오류가 날 수 있습니다. 그래서 배포는 끝이 아니라 점검의 시작입니다.

배포 전에 최소한 다음을 확인해야 합니다.

• 공유 링크가 다른 기기에서도 열리는가?

• 모바일 화면에서 버튼과 입력창이 잘 보이는가?

• 입력한 데이터가 정상적으로 저장되고 다시 보이는가?

• 개인정보나 API 키가 화면에 노출되지 않는가?

• 사용자가 무엇을 해야 하는지 첫 화면에서 이해할 수 있는가?

AI에게 배포 전 점검을 요청할 때는 이렇게 말해보세요.

배포 전에 이 앱을 점검해줘.
모바일 화면, 버튼 작동, 입력 데이터 저장, 한국어 문구, 개인정보 노출 위험을 확인해줘.
초보 사용자가 처음 들어와도 무엇을 해야 하는지 알 수 있게 개선할 부분을 제안해줘.

배포는 "완성"의 표시가 아니라 "이제 다른 사람이 만져볼 수 있는 상태"가 되었다는 뜻입니다. 작동하는 것과 서비스로 운영 가능한 것은 다릅니다. 첫 앱에서는 운영 가능한 완벽한 서비스보다, 안전하게 공유해보고 피드백을 받을 수 있는 상태를 목표로 삼는 것이 좋습니다.

버그와 디버깅: 주문이 꼬인 지점을 찾는 일

버그는 앱이 기대한 대로 작동하지 않는 문제입니다. 식당으로 치면 김치찌개를 주문했는데 된장찌개가 나오거나, 주문이 주방에 전달되지 않거나, 계산서에 엉뚱한 금액이 찍히는 상황입니다.

디버깅은 그 문제가 어디서 생겼는지 찾아 고치는 과정입니다. "손님이 잘못 말했나?", "직원이 잘못 적었나?", "주방에서 다른 주문과 섞였나?", "계산 시스템이 이상한가?"를 하나씩 확인하는 일입니다.

앱에서 흔한 버그는 다음과 같습니다.

• 저장 버튼을 눌러도 아무 반응이 없다.

• 입력한 내용이 목록에 나타나지 않는다.

• 새로고침하면 데이터가 사라진다.

• 모바일에서 버튼이 화면 밖으로 밀린다.

• 삭제 버튼을 눌렀는데 엉뚱한 항목이 삭제된다.

• 한국어 문구가 깨지거나 어색하게 나온다.

초보자가 버그를 만났을 때 가장 많이 하는 실수는 "안 돼요. 고쳐줘요."라고만 말하는 것입니다. 물론 AI가 어느 정도 추측할 수는 있지만, 문제를 정확히 설명할수록 고칠 가능성이 높아집니다.

좋은 오류 수정 프롬프트에는 세 가지가 들어갑니다. 내가 한 행동, 기대한 결과, 실제 결과입니다.

오류를 수정해줘.
내가 한 행동: 독서 기록을 입력한 뒤 저장 버튼을 눌렀어.
기대한 결과: 입력한 책 제목과 메모가 아래 목록에 추가되어야 해.
실제 결과: 버튼을 눌러도 아무 변화가 없고, 새 기록이 보이지 않아.
가능한 원인을 찾아 단계별로 수정해줘.
수정 후에는 같은 문제가 다시 생기지 않도록 간단한 확인 방법도 알려줘.

이 정도만 말해도 "안 돼요"보다 훨씬 좋은 요청입니다. 디버깅은 겁먹을 일이 아닙니다. 주문이 어디서 꼬였는지 하나씩 확인하는 일입니다.

CRUD: 앱의 기본 동작 네 가지

CRUD는 Create, Read, Update, Delete의 앞글자를 모은 말입니다. 한국어로는 생성, 조회, 수정, 삭제입니다. 대부분의 작은 앱은 이 네 가지를 조합해서 만들어집니다.

처음 보면 영어 약어라 어렵게 느껴지지만, 실제로는 아주 익숙한 행동입니다. 독서 기록 앱에서 새 책을 추가하는 것은 Create입니다. 기록 목록을 보는 것은 Read입니다. 별점이나 메모를 바꾸는 것은 Update입니다. 잘못 입력한 기록을 지우는 것은 Delete입니다.

할 일 관리 앱도 마찬가지입니다. 할 일을 추가하고, 목록을 보고, 제목이나 마감일을 수정하고, 완료한 일을 삭제하거나 완료 처리합니다. 강의 후기 수집 앱에서는 후기를 제출하고, 관리자가 후기를 보고, 오타를 수정하고, 부적절한 후기를 삭제할 수 있습니다.

초보자가 첫 앱을 기획할 때는 "내 앱에 CRUD가 필요한가?"라고 물어보면 좋습니다. 무언가를 기록하는 앱이라면 거의 필요합니다. 하지만 처음 버전에서는 네 가지를 모두 넣지 않아도 됩니다. 예를 들어 강의 후기 수집 앱의 첫 버전은 수강생이 후기를 제출하고 관리자가 목록을 보는 것만 있어도 충분합니다. 수정과 삭제는 관리자 기능으로 나중에 추가할 수 있습니다.

AI에게 CRUD를 요청할 때는 이렇게 말할 수 있습니다.

이 앱에 기본 CRUD 기능을 만들어줘.
사용자는 새 항목을 추가하고, 목록에서 확인하고, 기존 항목을 수정하고, 필요 없는 항목을 삭제할 수 있어야 해.
삭제할 때는 실수 방지를 위해 "정말 삭제하시겠습니까?" 확인 창을 넣어줘.
처음에는 로그인 없이 개인용으로 사용할 수 있는 MVP로 만들어줘.

CRUD라는 말을 알면 앱의 기본 뼈대를 설명하기 쉬워집니다.

MVP와 프로토타입: 처음부터 정식 매장을 열지 않기

MVP는 Minimum Viable Product의 줄임말입니다. 한국어로 억지로 번역하면 "최소 기능 제품" 정도입니다. 쉽게 말하면 정식 매장을 열기 전의 팝업스토어입니다. 모든 메뉴와 인테리어를 갖춘 완벽한 식당이 아니라, 사람들이 정말 이 음식을 원하는지 확인할 수 있는 작은 실험입니다.

바이브 코딩에서 MVP는 특히 중요합니다. AI에게 처음부터 "완벽한 예약 관리 플랫폼을 만들어줘. 로그인, 결제, 관리자, 통계, 문자 발송, 고객 등급, 쿠폰, 알림까지 넣어줘"라고 요청하면 결과가 복잡해지고 오류도 늘어납니다. 반대로 "이름, 연락처, 희망 날짜, 문의 내용을 입력받고 목록으로 확인하는 예약 문의 앱을 MVP로 만들어줘"라고 하면 성공 가능성이 높아집니다.

프로토타입은 실제 완성품 전의 시제품입니다. 모양과 흐름을 확인하기 위한 임시 모델이라고 생각하면 됩니다. 새로 카페를 열기 전에 메뉴판 시안, 좌석 배치도, 팝업 부스를 만들어보는 것과 비슷합니다.

MVP와 프로토타입은 비슷하지만 초점이 조금 다릅니다. 프로토타입은 "이런 모양과 흐름이면 괜찮을까?"를 확인하는 데 가깝고, MVP는 "최소 기능으로 실제 문제를 해결할 수 있을까?"를 확인하는 데 가깝습니다.

예를 들어 가족 일정 공유 앱을 만든다면 프로토타입은 달력 화면, 일정 추가 화면, 가족별 색상 표시가 어떻게 보일지 확인하는 버전일 수 있습니다. MVP는 가족 구성원이 일정을 입력하고, 날짜별로 모아 보고, 중요한 일정에 표시를 남길 수 있는 실제 사용 가능한 첫 버전입니다.

AI에게 MVP를 요청하는 문장은 책 전체에서 자주 쓰게 될 것입니다.

처음부터 완성형 서비스로 만들지 말고 MVP로 만들어줘.
가장 중요한 기능은 사용자가 기록을 추가하고 목록에서 확인하는 것이야.
로그인, 결제, 알림, 복잡한 통계는 첫 버전에서 제외해줘.
나중에 기능을 추가하기 쉽도록 구조는 단순하게 잡아줘.

첫 앱은 작을수록 좋습니다. 작다는 것은 초라하다는 뜻이 아닙니다. 작다는 것은 확인 가능하다는 뜻입니다.

반응형: 휴대폰에서도 보기 좋게 만드는 것

반응형은 화면 크기에 맞게 앱의 모양이 자연스럽게 바뀌는 것을 말합니다. 컴퓨터에서는 넓게 보이고, 휴대폰에서는 세로로 보기 좋게 정리되는 방식입니다.

한국 독자들이 만드는 작은 앱은 생각보다 모바일 사용 비중이 높습니다. 강의 후기 수집 앱은 수강생이 강의장 자리에서 휴대폰으로 작성할 가능성이 큽니다. 예약 문의 앱은 고객이 인스타그램 링크를 눌러 모바일로 들어올 수 있습니다. 운동 루틴 기록 앱은 헬스장에서 휴대폰으로 열어볼 수 있습니다. 가족 일정 공유 앱도 부모님이나 배우자가 휴대폰으로 확인할 가능성이 높습니다.

그래서 첫 앱을 만들 때 "반응형으로 만들어줘"라는 말을 넣으면 좋습니다. 더 정확히는 "모바일 우선"이라고 요청할 수 있습니다. 모바일 우선은 휴대폰 화면에서 먼저 편하게 보이도록 설계해달라는 뜻입니다.

이 앱은 모바일에서 주로 사용할 예정이야.
반응형으로 만들고, 특히 휴대폰 화면에서 입력창과 버튼이 잘 보이게 해줘.
버튼은 손가락으로 누르기 편한 크기로 만들고,
목록은 세로 카드 형태로 정리해줘.
PC 화면에서는 너무 넓게 퍼지지 않도록 가운데 정렬해줘.

화면이 예쁜 것보다 중요한 것은 사용자가 실수 없이 쓸 수 있는 것입니다. 모바일에서 작은 버튼은 예쁜 버튼이 아니라 불편한 버튼입니다.

인증과 로그인: 출입증을 확인하는 일

인증은 사용자가 누구인지 확인하는 과정입니다. 식당보다는 사무실 출입증에 가깝습니다. "이 사람이 들어와도 되는 사람인가?"를 확인하는 일입니다. 로그인은 인증을 하기 위한 대표적인 방법입니다. 아이디와 비밀번호, 구글 계정, 카카오 계정 등으로 사용자를 확인합니다.

초보자는 앱을 만들 때 습관처럼 "로그인 기능도 넣어줘"라고 말하는 경우가 많습니다. 하지만 로그인은 생각보다 난이도가 있습니다. 사용자 정보 저장, 비밀번호 보안, 권한 관리, 로그아웃, 비밀번호 재설정 같은 일이 따라오기 때문입니다.

개인용 독서 기록 앱이나 혼자 쓰는 할 일 앱은 처음부터 로그인이 필요 없을 수 있습니다. 반면 가족 일정 공유 앱처럼 사람마다 일정을 구분해야 하거나, 강의 후기 관리자 페이지처럼 관리자만 봐야 하는 화면이 있다면 로그인이나 간단한 접근 제한이 필요할 수 있습니다.

초보자의 기준은 이렇게 잡으면 됩니다. "누가 써도 같은 화면을 봐도 되는가?" 그렇다면 첫 버전에는 로그인 없이 시작해도 됩니다. "사람마다 다른 정보를 봐야 하는가?" 그렇다면 로그인이나 권한 관리가 필요할 가능성이 있습니다.

이 앱은 첫 버전에서는 로그인 없이 사용할 수 있게 만들어줘.
다만 나중에 사용자별 데이터를 구분할 수 있도록 구조를 너무 복잡하지 않게 준비해줘.
관리자만 봐야 하는 화면이 있다면 간단한 관리자 접근 방식도 제안해줘.

유명한 서비스처럼 보이게 하려고 처음부터 로그인을 넣을 필요는 없습니다. 처음에는 불필요한 문을 줄이는 것이 더 좋은 선택일 때가 많습니다.

컴포넌트, UI, UX: 화면을 만드는 블록과 사용감

컴포넌트는 화면을 이루는 재사용 가능한 조각입니다. 레고 블록이라고 생각하면 됩니다. 버튼, 카드, 입력창, 메뉴, 알림창, 목록 항목 같은 것들이 컴포넌트가 될 수 있습니다.

UI는 User Interface의 줄임말로, 사용자가 앱과 만나는 화면 요소를 말합니다. 버튼이 어디에 있는지, 글자가 얼마나 큰지, 색상이 어떤지처럼 눈에 보이는 부분입니다.

UX는 User Experience의 줄임말로, 사용자가 앱을 쓰며 느끼는 전체 경험입니다. 버튼이 예뻐도 어디를 눌러야 할지 모르겠다면 UX가 좋지 않은 것입니다. 반대로 디자인이 아주 화려하지 않아도 사용자가 헤매지 않고 원하는 일을 끝낼 수 있다면 UX가 좋다고 말할 수 있습니다.

예를 들어 회의록 정리 앱에서 UI는 텍스트 입력창, 요약 버튼, 결과 카드, 복사 버튼입니다. UX는 사용자가 회의록을 붙여넣고, 버튼을 누르고, 요약 결과를 복사해 보고서에 붙이는 전체 흐름입니다.

초보자는 디자인 요청을 할 때 UI와 UX를 함께 말하면 좋습니다.

UI와 UX를 함께 개선해줘.
화면은 깔끔한 업무용 SaaS 느낌으로 만들고,
사용자가 1단계: 내용 입력, 2단계: 요약 실행, 3단계: 결과 복사 순서로 자연스럽게 사용할 수 있게 구성해줘.
각 단계마다 안내 문구를 짧게 넣어줘.

앱은 예쁜 그림이 아니라 사용자가 일을 끝내는 도구입니다. UI는 보이는 모양이고, UX는 사용하는 느낌입니다.

로컬 저장과 클라우드 저장: 내 책상 서랍과 공동 장부

앱에서 "저장"이라는 말은 한 가지가 아닙니다. 로컬 저장은 내 기기 안에 저장하는 방식입니다. 내 책상 서랍에 메모지를 넣어두는 것과 비슷합니다. 같은 기기에서는 다시 볼 수 있지만, 다른 기기에서는 보이지 않을 수 있습니다.

클라우드 저장은 인터넷에 연결된 저장소에 데이터를 보관하는 방식입니다. 여러 사람이 함께 보는 공동 장부에 가깝습니다. 휴대폰에서 입력한 내용을 노트북에서도 보고 싶거나, 가족이 함께 일정을 공유해야 한다면 클라우드 저장이 필요할 가능성이 높습니다.

첫 앱에서는 로컬 저장이 더 간단할 때가 있습니다. 예를 들어 혼자 쓰는 프롬프트 보관함 앱은 처음에 로컬 저장으로 시작해도 됩니다. 하지만 강의 후기 수집 앱처럼 여러 사람이 제출한 내용을 관리자가 모아 봐야 한다면 클라우드 저장 또는 데이터베이스 연결이 필요합니다.

AI에게 저장 방식을 요청할 때는 사용 상황을 함께 말해야 합니다.

이 앱은 여러 사람이 각자 휴대폰으로 후기를 제출하고,
관리자인 내가 한 화면에서 모든 후기를 모아봐야 해.
따라서 로컬 저장이 아니라 클라우드 데이터베이스에 저장되는 방식으로 만들어줘.

반대로 개인용이면 이렇게 말할 수 있습니다.

이 앱은 나 혼자 쓰는 개인용 MVP야.
처음에는 로그인 없이 로컬 저장으로 간단히 만들어줘.
나중에 필요하면 클라우드 저장으로 확장할 수 있게 해줘.

저장 방식은 앱의 난이도를 크게 바꿉니다. "누가, 어떤 기기에서, 함께 쓰는가?"를 먼저 생각하면 선택이 쉬워집니다.

실제 예시로 용어 연결하기

이제 용어를 따로따로 보지 말고 하나의 앱에 연결해보겠습니다. 예시는 "강의 후기 수집 앱"입니다.

강사는 수업이 끝난 뒤 수강생들에게 링크를 보냅니다. 수강생은 휴대폰으로 링크를 열고 이름, 별점, 좋았던 점, 개선할 점을 입력합니다. 강사는 관리자 화면에서 후기를 모아 보고, 좋은 후기를 복사해 홍보 문구로 활용합니다.

이 앱에서 프론트엔드는 수강생이 보는 후기 입력 화면과 강사가 보는 후기 목록 화면입니다. 백엔드는 후기가 제출될 때 저장하고, 관리자 화면에서 불러오는 처리입니다. 데이터베이스는 수강생 후기들이 쌓이는 장부입니다. CRUD 중 Create는 후기 제출, Read는 후기 목록 보기, Update는 오타 수정, Delete는 부적절한 후기 삭제입니다. 반응형은 수강생이 휴대폰으로 편하게 작성할 수 있게 하는 조건입니다. 배포는 링크를 만들어 수강생에게 공유하는 일입니다. 버그는 제출 버튼을 눌러도 후기가 저장되지 않는 문제이고, 디버깅은 그 원인을 찾는 과정입니다. MVP는 처음에 후기 입력과 목록 보기만 가능한 작고 단순한 버전입니다.

이번에는 "운동 루틴 기록 앱"을 보겠습니다. 프론트엔드는 운동명, 세트 수, 무게, 메모를 입력하는 화면입니다. 데이터베이스는 날짜별 운동 기록이 쌓이는 곳입니다. CRUD는 운동 기록 추가, 조회, 수정, 삭제입니다. 반응형은 헬스장에서 휴대폰으로 쓰기 편한 화면을 의미합니다. MVP는 운동 기록 추가와 날짜별 목록 보기만 있으면 충분합니다. AI 추천 운동, 친구 공유, 그래프 분석은 나중 기능입니다.

마지막으로 "예약 문의 앱"을 보겠습니다. 프론트엔드는 고객이 날짜와 연락처를 입력하는 문의 화면입니다. 백엔드는 문의 내용을 저장하고 상태를 관리하는 부분입니다. 데이터베이스에는 고객명, 연락처, 희망 날짜, 문의 내용, 처리 상태가 들어갑니다. API는 문의가 들어왔을 때 이메일이나 문자 알림을 보내는 데 사용될 수 있습니다. 하지만 첫 버전에서는 알림 API 없이 관리자 화면에서 문의 목록만 확인해도 됩니다.

이렇게 용어는 외우는 것이 아니라 앱 안에서 위치를 잡아야 합니다. "이 기능은 화면인가, 저장인가, 연결인가, 공유인가?"라고 물어보면 대부분의 용어가 제자리를 찾습니다.

바로 써먹는 용어 기반 프롬프트

아래 프롬프트는 앱 빌더형 도구에서 그대로 복사해 쓸 수 있습니다. 도구 이름은 Lovable, Replit Agent, Bolt.new 등 무엇이든 상관없습니다. 중요한 것은 AI에게 앱의 구조를 알아들을 수 있게 설명하는 것입니다.

첫 앱 구조 설명 프롬프트

나는 코딩을 모르는 초보자야.
작은 웹앱을 MVP로 만들고 싶어.

앱 이름: 독서 기록 앱
목적: 읽은 책을 기록하고 나중에 다시 확인하기
사용자: 나 혼자 사용하는 개인 사용자

필요한 기능:
1. 책 제목, 저자, 읽은 날짜, 별점, 한 줄 메모 입력
2. 입력한 기록을 목록으로 보기
3. 기록 수정과 삭제
4. 모바일에서도 보기 좋은 반응형 화면

화면 구성:
- 상단: 앱 제목과 짧은 안내 문구
- 중간: 독서 기록 입력 폼
- 하단: 저장된 기록 목록 카드

저장 방식:
처음에는 간단한 MVP로 만들되, 새로고침해도 기록이 사라지지 않게 해줘.

제외할 기능:
로그인, 소셜 공유, AI 추천, 복잡한 통계는 첫 버전에서 제외해줘.

프론트엔드와 데이터 저장 흐름이 초보자도 이해하기 쉽게 단순한 구조로 만들어줘.

화면 수정 프롬프트

프론트엔드 화면을 수정해줘.
현재 입력창과 버튼이 너무 붙어 있어서 사용하기 불편해.
모바일에서 손가락으로 누르기 편하도록 버튼 크기를 키우고,
입력 폼과 기록 목록 사이의 간격을 넓혀줘.
기록 목록은 카드 형태로 보여주고,
각 카드에는 수정 버튼과 삭제 버튼을 명확히 배치해줘.

저장 문제 해결 프롬프트

저장 관련 문제를 확인해줘.
내가 입력한 데이터가 화면에는 보이지만 새로고침하면 사라져.
프론트엔드에만 임시로 표시되는 상태인지 확인하고,
데이터베이스 또는 지속 가능한 저장 방식에 연결해줘.
사용자가 새 기록을 추가하면 저장되고,
앱을 다시 열어도 목록에서 확인할 수 있게 수정해줘.

모바일 반응형 점검 프롬프트

이 앱을 모바일 우선 반응형으로 점검해줘.
휴대폰 화면에서 입력창이 너무 작거나 버튼이 화면 밖으로 나가지 않게 해줘.
목록은 세로 카드 형태로 정리하고,
중요한 버튼은 한눈에 보이게 배치해줘.
PC 화면에서는 콘텐츠가 너무 넓게 퍼지지 않도록 적당한 최대 폭을 적용해줘.

MVP 줄이기 프롬프트

현재 앱이 너무 복잡해졌어.
초보자가 완성할 수 있는 MVP로 기능을 줄여줘.
반드시 필요한 기능과 나중에 추가할 기능을 나눠서 정리해줘.
첫 버전에는 입력, 저장, 목록 보기, 삭제 정도만 남기고,
로그인, 통계, 알림, 외부 API 연동은 제외해줘.

실습 미션: 내 앱을 개발 용어로 번역해보기

이번 장의 미션은 코드를 쓰는 것이 아닙니다. 내가 만들고 싶은 앱을 개발 용어로 살짝 번역해보는 것입니다. 종이에 써도 좋고, 메모 앱에 정리해도 좋습니다.

다음 질문에 답해보세요.

• 사용자가 직접 보는 화면에는 무엇이 있어야 하는가?

• 앱이 기억해야 할 정보는 무엇인가?

• 사용자가 새로 추가하고, 보고, 수정하고, 삭제해야 하는 항목은 무엇인가?

• 이 앱은 혼자 쓰는가, 여러 사람이 함께 쓰는가?

• 휴대폰에서 주로 쓰는가, PC에서 주로 쓰는가?

• 다른 서비스와 연결해야 하는가, 첫 버전에서는 빼도 되는가?

• 다른 사람에게 링크로 공유해야 하는가?

예를 들어 "가족 일정 공유 앱"이라면 이렇게 정리할 수 있습니다.

프론트엔드: 달력 화면, 일정 입력 폼, 가족별 색상 표시, 일정 목록
백엔드: 일정 저장, 가족별 일정 불러오기
데이터베이스: 일정 제목, 날짜, 시간, 담당 가족, 메모
CRUD: 일정 추가, 보기, 수정, 삭제
반응형: 부모님이 휴대폰으로 보기 편해야 함
MVP: 로그인 없이 가족 공용 링크로 일정 추가와 보기부터 시작
나중 기능: 알림, 반복 일정, 개인별 로그인

이 정도면 충분합니다. 개발자처럼 정확하지 않아도 됩니다. AI가 이해할 수 있는 출발점만 만들면 됩니다.

흔한 실수와 고치는 방법

초보자가 개발 용어를 처음 만날 때 가장 흔한 실수는 모든 용어를 한 번에 완벽히 이해하려는 것입니다. 하지만 바이브 코딩에서는 용어를 백과사전처럼 외우는 것보다, 앱을 만들며 필요한 순간에 꺼내 쓰는 것이 중요합니다.

두 번째 실수는 모든 기능을 첫 버전에 넣으려는 것입니다. 로그인, 관리자 페이지, 통계, 알림, 결제, AI 추천, 외부 API 연동을 한 번에 넣으면 앱은 멋져 보이지만 실패 가능성도 커집니다. 고치는 방법은 단순합니다. MVP로 줄이세요. "이번 버전에서 사용자가 꼭 해야 하는 한 가지 행동은 무엇인가?"를 먼저 정해야 합니다.

세 번째 실수는 저장 방식을 생각하지 않는 것입니다. 화면에 보이면 저장된 것이라고 착각하기 쉽습니다. 하지만 새로고침했을 때 사라지면 실제 저장이 아닐 수 있습니다. 고치는 방법은 AI에게 "새로고침해도 남아 있게 해줘", "데이터베이스에 저장해줘", "여러 사람이 제출한 내용을 관리자가 모아 볼 수 있게 해줘"처럼 사용 상황을 설명하는 것입니다.

네 번째 실수는 개발자형 도구의 언어를 초보자용 앱 빌더에 그대로 가져오는 것입니다. Claude Code, Codex, Cursor 같은 개발자형 도구는 코드베이스, 터미널, GitHub, 테스트 같은 개발 흐름에 가깝습니다. 처음부터 이런 환경에 들어가면 용어가 한꺼번에 쏟아져 쉽게 지칩니다. 처음에는 Lovable, Replit Agent, Bolt.new 같은 앱 빌더형 도구에서 화면과 기능이 만들어지는 경험을 먼저 해보는 것이 좋습니다. 유명한 도구가 초보자에게 쉬운 도구는 아닙니다.

마지막 실수는 오류가 났을 때 감정적으로 요청하는 것입니다. "왜 안 돼?", "다시 해", "제대로 만들어"보다 "내가 한 행동, 기대한 결과, 실제 결과"를 적어주는 편이 훨씬 낫습니다. AI는 사람처럼 눈치로 화면을 보는 존재가 아닙니다. 설명이 구체적일수록 문제를 찾기 쉽습니다.

최소 용어 빠른 정리

이번 장에서 다룬 용어를 한 번에 정리해보겠습니다.

한 장 요약

개발 용어는 초보자를 겁주기 위해 있는 말이 아닙니다. 앱의 어느 부분을 말하는지 빠르게 가리키기 위한 이름표에 가깝습니다. 프론트엔드는 사용자가 보는 화면이고, 백엔드는 보이지 않는 주방입니다. 데이터베이스는 앱의 장부이고, API는 다른 서비스와 연결해주는 통로입니다. 배포는 가게 문을 여는 일이며, 버그와 디버깅은 주문이 어디서 꼬였는지 찾아가는 과정입니다.

첫 앱을 만들 때는 CRUD, MVP, 프로토타입, 반응형 정도만 알아도 충분히 대화를 시작할 수 있습니다. 더 깊은 지식은 앱을 만들면서 필요할 때 하나씩 익히면 됩니다. 바이브 코딩은 코딩을 전혀 몰라도 모든 것이 자동으로 해결된다는 뜻이 아닙니다. 내가 원하는 것을 AI가 이해하게 설명하는 기술입니다.

다음 장에서는 한 걸음 더 들어가서, 우리가 계속 말하는 "앱"과 "웹앱"이 정확히 무엇인지 살펴보겠습니다. 앱스토어에서 설치하는 앱만 앱일까요? 링크로 열리는 웹앱은 무엇이 다를까요? 이 차이를 알면 내가 만들 첫 결과물을 어디까지 생각해야 하는지 훨씬 분명해집니다.