본문 바로가기
바이브 코딩(Vibe Coding)/비개발자에게 바이브 코딩이란?

[5회] 비개발자가 알아야 할 바이브 코딩 필수 개발 용어

by eplus 2026. 7. 8.

화면, API, 서버, 빌드, 배포, 로그까지 쉽게 이해하기

앞선 1~4회에서는 개발언어, 개발툴, DB, 프로그램의 종류에 대해 알아봤습니다.

이번 5회에서는 바이브 코딩을 할 때 자주 등장하는 개발 용어를 정리하겠습니다.

비개발자가 AI에게 프로그램을 만들게 하려면 모든 개발 지식을 깊게 알 필요는 없습니다.
하지만 자주 쓰는 용어는 알아야 합니다.

용어를 모르면 AI가 답을 줘도 이해하기 어렵습니다.
오류가 나도 무엇이 문제인지 알기 어렵습니다.
“API 호출이 실패했습니다”, “빌드 오류입니다”, “런타임 예외입니다”, “패키지명이 중복됩니다”, “권한이 필요합니다” 같은 말을 이해하지 못하면 작업이 막힙니다.

바이브 코딩의 핵심은 질문을 잘하는 것입니다.
질문을 잘하려면 기본 용어를 알아야 합니다.


1. 프로젝트

프로젝트는 프로그램을 만들기 위한 작업 단위입니다.

예를 들어 MAUI 앱 하나, C# WinForms 프로그램 하나, 웹 사이트 하나가 각각 하나의 프로젝트가 될 수 있습니다.

프로젝트 안에는 코드 파일, 화면 파일, 이미지, 설정 파일, 라이브러리 정보, 빌드 정보가 들어 있습니다.

바이브 코딩에서 “프로젝트 전체를 보고 수정해줘”라고 할 때의 프로젝트가 바로 이것입니다.


2. 솔루션

솔루션은 여러 프로젝트를 묶어 관리하는 단위입니다.

Visual Studio에서는 .sln 파일이 솔루션 파일입니다.

예를 들어 MES 시스템을 만든다고 하면 다음처럼 구성할 수 있습니다.

MES.WinForms
MES.Api
MES.Common
MES.Models
MES.Tests

이 여러 프로젝트를 하나로 묶은 것이 솔루션입니다.

비개발자는 솔루션을 “프로그램 작업 묶음”이라고 이해하면 됩니다.


3. 소스코드

소스코드는 사람이 작성한 프로그램 명령문입니다.

C#, Python, JavaScript, Dart 같은 언어로 작성됩니다.

AI가 만들어 주는 것도 결국 소스코드입니다.

예를 들어 다음 파일들이 소스코드입니다.

MainPage.xaml.cs
frmItem.cs
Program.cs
app.py
index.js

바이브 코딩에서는 AI가 소스코드를 만들고, 수정하고, 설명합니다.


4. 화면 또는 UI

UI는 User Interface의 약자입니다.
사용자가 보는 화면입니다.

버튼, 입력창, 목록, 체크박스, 이미지, 탭, 메뉴, 팝업 등이 UI에 해당합니다.

비개발자가 AI에게 가장 많이 요청하는 부분이 UI입니다.

예를 들어 이렇게 요청합니다.

“하단 탭을 홈, 조회, 설정으로 만들어줘.”

“입력 필드 높이를 조금 키워줘.”

“저장 버튼은 오른쪽 상단에 배치해줘.”

“오류 팝업을 깔끔하게 색상 넣어서 만들어줘.”

UI는 프로그램의 얼굴입니다.


5. UX

UX는 User Experience의 약자입니다.
사용자가 프로그램을 사용하면서 느끼는 경험입니다.

UI가 화면의 모양이라면, UX는 사용하기 편한 흐름입니다.

예를 들어 버튼이 예쁘게 생긴 것은 UI입니다.
버튼 위치가 손가락으로 누르기 편하고, 저장 후 다음 작업으로 자연스럽게 이어지는 것은 UX입니다.

현장용 프로그램에서는 UX가 매우 중요합니다.

작업자가 장갑을 끼고 사용할 수 있는가?
10인치 태블릿에서 버튼이 충분히 큰가?
필수 항목만 먼저 보이는가?
오류 메시지가 이해하기 쉬운가?
작업 순서가 실제 현장 흐름과 맞는가?

이런 것이 UX입니다.


6. 프론트엔드

프론트엔드는 사용자가 직접 보는 부분입니다.

웹에서는 HTML, CSS, JavaScript, React, Vue 등이 프론트엔드에 해당합니다.

앱에서는 XAML, Flutter 화면, MAUI 화면 등이 프론트엔드 역할을 합니다.

쉽게 말해 화면 쪽입니다.

프론트엔드 개발 요청 예시는 다음과 같습니다.

“로그인 화면을 만들어줘.”

“카드형 목록으로 보여줘.”

“모바일 화면에서도 깨지지 않게 반응형으로 만들어줘.”


7. 백엔드

백엔드는 서버에서 동작하는 프로그램입니다.

사용자가 화면에서 저장 버튼을 누르면 백엔드가 요청을 받아 DB에 저장합니다.

백엔드는 보통 다음 일을 합니다.

로그인 처리
DB 저장
DB 조회
권한 확인
API 제공
파일 업로드 처리
메일 발송
외부 API 연동

비개발자는 백엔드를 “서버 쪽 프로그램”이라고 이해하면 됩니다.


8. 서버

서버는 서비스를 제공하는 컴퓨터 또는 프로그램입니다.

웹 사이트를 열면 어딘가의 서버가 화면을 보내줍니다.

앱에서 데이터를 조회하면 서버가 DB에서 데이터를 찾아 앱에 보내줍니다.

회사 내부 서버일 수도 있고, 클라우드 서버일 수도 있습니다.

예를 들어 다음과 같은 서버가 있습니다.

웹 서버
API 서버
DB 서버
파일 서버
메일 서버
소켓 서버

서버는 여러 사용자가 함께 사용할 때 중요합니다.


9. 클라이언트

클라이언트는 서버에 요청하는 쪽입니다.

스마트폰 앱
웹 브라우저
윈도우 프로그램
태블릿 앱

이런 것들이 클라이언트가 될 수 있습니다.

예를 들어 스마트폰 앱이 서버에 “현재 날씨 정보를 주세요”라고 요청하면 앱은 클라이언트이고, 정보를 주는 쪽은 서버입니다.


10. API

API는 프로그램과 프로그램이 데이터를 주고받는 약속입니다.

예를 들어 앱이 서버에 다음처럼 요청합니다.

“현재 위치 기준 관광지 목록을 주세요.”

서버는 다음처럼 응답합니다.

“관광지명, 주소, 거리, 이미지 URL 목록입니다.”

이 요청과 응답의 약속이 API입니다.

공공데이터 API, 기상청 API, 관광공사 API, 금융위원회 API 같은 것도 모두 API입니다.

바이브 코딩에서 API를 요청할 때는 다음 정보를 주면 좋습니다.

API 주소
요청 방식
요청 파라미터
응답 예시
인증키 필요 여부
오류 처리 방법


11. Endpoint

Endpoint는 API 주소입니다.

예를 들어 다음과 같은 주소가 있습니다.

/api/items
/api/workorders
/api/stock/current
/api/login

품목 목록을 조회하는 주소, 작업지시를 저장하는 주소, 로그인하는 주소가 각각 Endpoint입니다.

비개발자는 Endpoint를 “API의 세부 주소”라고 이해하면 됩니다.


12. Request와 Response

Request는 요청입니다.
Response는 응답입니다.

사용자가 앱에서 조회 버튼을 누르면 앱이 서버에 Request를 보냅니다.

서버는 처리 결과를 Response로 돌려줍니다.

예를 들어 다음과 같습니다.

Request: 품목코드 A001 조회 요청
Response: 품명, 규격, 단위, 현재고 응답

API를 만들 때는 Request와 Response 구조를 정확히 정해야 합니다.


13. JSON

JSON은 데이터를 주고받을 때 많이 사용하는 형식입니다.

예를 들어 품목 정보는 다음처럼 표현할 수 있습니다.

{
  "itemCode": "A001",
  "itemName": "모터브라켓",
  "unit": "EA",
  "stockQty": 120
}

앱, 웹, 서버, 공공데이터 API에서 JSON을 많이 사용합니다.

바이브 코딩을 할 때 “응답은 JSON 형식으로 해줘”라는 말을 자주 사용합니다.


14. DB 연결

DB 연결은 프로그램이 DB에 접속하는 것입니다.

DB에 접속하려면 보통 다음 정보가 필요합니다.

서버 주소
포트
DB명
사용자 ID
비밀번호

예를 들어 MariaDB는 보통 3306 포트를 사용합니다.

DB 연결이 실패하면 프로그램이 데이터를 저장하거나 조회할 수 없습니다.


15. SQL

SQL은 DB와 대화하는 언어입니다.

대표적으로 네 가지가 중요합니다.

SELECT: 조회
INSERT: 추가
UPDATE: 수정
DELETE: 삭제

바이브 코딩에서 DB를 다룬다면 SQL 개념은 반드시 알아야 합니다.

예를 들어 “품목 목록 조회 SQL을 만들어줘”, “재고 수불 이력 조회 SQL을 만들어줘”라고 요청할 수 있습니다.


16. CRUD

CRUD는 프로그램의 기본 기능 네 가지입니다.

Create: 생성
Read: 조회
Update: 수정
Delete: 삭제

대부분의 업무 프로그램은 CRUD를 기반으로 합니다.

품목관리도 CRUD입니다.
거래처관리도 CRUD입니다.
작업지시관리도 CRUD입니다.

바이브 코딩에서 “품목관리 CRUD 화면 만들어줘”라고 하면 품목 등록, 조회, 수정, 삭제 기능이 있는 화면을 의미합니다.


17. 빌드

빌드는 소스코드를 실행 가능한 프로그램으로 만드는 과정입니다.

C# 프로그램은 빌드를 해야 exe나 앱 패키지로 만들 수 있습니다.

MAUI 앱도 빌드를 해야 Android Emulator에서 실행하거나 APK, AAB 파일로 만들 수 있습니다.

빌드 오류는 프로그램을 만들 수 없다는 뜻입니다.

예를 들어 문법 오류, 파일 누락, 라이브러리 오류, 네임스페이스 오류가 있으면 빌드가 실패합니다.


18. 실행

실행은 프로그램을 실제로 켜 보는 것입니다.

빌드가 성공해도 실행 중 오류가 날 수 있습니다.

예를 들어 빌드는 성공했지만, 버튼을 누르면 앱이 종료될 수 있습니다.
DB 연결이 실패할 수도 있습니다.
API 호출이 실패할 수도 있습니다.

그래서 빌드 성공과 실행 성공은 다릅니다.


19. 디버그

디버그는 오류 원인을 찾는 과정입니다.

개발자는 디버그를 통해 코드가 어떤 순서로 실행되는지 확인합니다.

비개발자가 깊게 알 필요는 없지만, 다음 정도는 알아두면 좋습니다.

오류가 언제 발생했는지
어떤 버튼을 눌렀는지
어떤 값을 입력했는지
오류 메시지가 무엇인지
재현이 되는지

이 정보를 AI에게 주면 오류 수정이 쉬워집니다.


20. 로그

로그는 프로그램의 처리 기록입니다.

예를 들어 다음 내용이 로그에 남을 수 있습니다.

앱 실행 시간
사용자 로그인
API 호출 결과
DB 저장 성공
오류 메시지
예외 상세 내용

로그는 오류를 찾는 데 매우 중요합니다.

바이브 코딩을 할 때는 이렇게 요청하면 좋습니다.

“오류가 발생하면 log 폴더에 날짜별 txt 파일로 기록해줘.”

“사용자에게는 쉬운 메시지를 보여주고, 상세 오류는 로그에 남겨줘.”


21. 예외 처리

예외 처리는 오류가 발생했을 때 프로그램이 갑자기 종료되지 않게 처리하는 것입니다.

예를 들어 DB 연결이 실패했을 때 앱이 꺼지는 것이 아니라 다음처럼 표시해야 합니다.

“네트워크 또는 DB 연결을 확인해 주세요.”

그리고 상세 오류는 로그에 기록합니다.

예외 처리는 실무 프로그램에서 매우 중요합니다.

AI에게는 이렇게 요청합니다.

“오류가 발생해도 프로그램이 종료되지 않게 try-catch로 예외 처리해줘.”


22. 패키지와 라이브러리

라이브러리는 다른 개발자가 만들어 둔 기능 묶음입니다.

예를 들어 엑셀 파일을 읽는 라이브러리, JSON을 처리하는 라이브러리, DB에 접속하는 라이브러리가 있습니다.

패키지는 이런 라이브러리를 설치 가능한 형태로 묶은 것입니다.

C#에서는 NuGet 패키지를 많이 사용합니다.

Python에서는 pip 패키지를 많이 사용합니다.

JavaScript에서는 npm 패키지를 많이 사용합니다.

AI가 코드를 만들 때 패키지를 추가하자고 할 수 있습니다.
이때 꼭 필요한지 확인해야 합니다.


23. 프레임워크

프레임워크는 프로그램을 만들기 위한 기본 틀입니다.

예를 들어 다음이 프레임워크입니다.

.NET MAUI
WinForms
WPF
ASP.NET Core
Flutter
React
Django
Spring

프레임워크는 개발자가 매번 처음부터 만들지 않아도 되게 기본 구조를 제공합니다.

바이브 코딩에서는 프레임워크를 정확히 지정해야 합니다.

“C#으로 만들어줘”보다
“C# WinForms로 만들어줘”가 더 정확합니다.

“앱 만들어줘”보다
“.NET MAUI로 Android 앱 만들어줘”가 더 정확합니다.


24. 플랫폼

플랫폼은 프로그램이 실행되는 환경입니다.

예를 들어 다음이 플랫폼입니다.

Windows
Android
iOS
Web
Linux
macOS

바이브 코딩에서 플랫폼은 매우 중요합니다.

Android 앱 코드와 Windows 프로그램 코드는 다릅니다.
웹 프로그램과 PC 프로그램도 다릅니다.

AI에게 요청할 때는 반드시 플랫폼을 알려줘야 합니다.


25. 권한

권한은 앱이나 프로그램이 특정 기능을 사용하기 위해 필요한 허가입니다.

스마트폰 앱에서는 특히 중요합니다.

위치 권한
카메라 권한
마이크 권한
파일 접근 권한
알림 권한
인터넷 권한

예를 들어 위치 기반 앱을 만들려면 위치 권한이 필요합니다.

AI에게는 이렇게 요청합니다.

“Android에서 현재 위치를 사용해야 하므로 위치 권한 요청까지 포함해줘.”


26. 배포

배포는 만든 프로그램을 사용자에게 전달하는 과정입니다.

윈도우 프로그램은 exe 파일이나 설치 파일로 배포합니다.

Android 앱은 APK 또는 AAB로 배포합니다.

웹 프로그램은 서버에 올려 배포합니다.

배포는 개발의 마지막 단계가 아니라 중요한 운영 단계입니다.

프로그램이 잘 만들어져도 배포가 안 되면 사용자가 쓸 수 없습니다.


27. APK와 AAB

Android 앱에서 자주 나오는 용어입니다.

APK는 스마트폰에 직접 설치할 수 있는 파일입니다.

AAB는 Google Play에 업로드하는 파일입니다.

테스트용으로는 APK를 많이 사용합니다.

구글플레이 등록용으로는 AAB를 사용합니다.

바이브 코딩으로 앱을 만들 때는 다음 흐름이 많습니다.

Emulator 실행
APK 생성
실제 폰 설치 테스트
AAB 생성
Google Play 비공개 테스트
프로덕션 출시


28. 버전

버전은 프로그램의 변경 단위입니다.

예를 들어 다음처럼 표시합니다.

1.0.0
1.0.1
1.1.0
2.0.0

Android 앱에서는 사용자에게 보이는 버전명과 내부 버전코드가 따로 있습니다.

새 AAB를 Google Play에 올릴 때는 내부 버전코드를 반드시 올려야 합니다.


29. 패키지명

패키지명은 앱의 고유 이름입니다.

예를 들어 다음과 같습니다.

com.eplus.myapp

Android 앱에서는 패키지명이 매우 중요합니다.

Google Play에 한 번 등록한 패키지명은 쉽게 바꿀 수 없습니다.

앱을 만들기 전에 신중히 정해야 합니다.


30. 서명키

서명키는 앱을 만든 사람을 증명하는 도장과 같습니다.

Android 앱을 배포하려면 서명키가 필요합니다.

APK나 AAB를 만들 때 Keystore 파일과 비밀번호를 사용합니다.

주의할 점은 서명키를 잃어버리면 앱 업데이트에 문제가 생길 수 있다는 것입니다.

반드시 안전하게 백업해야 합니다.


31. Emulator

Emulator는 PC에서 가상 스마트폰을 실행하는 도구입니다.

Android 앱을 실제 폰 없이 테스트할 수 있습니다.

MAUI나 Android 앱 개발에서 자주 사용합니다.

하지만 Emulator에서 잘 되더라도 실제 폰에서 문제가 생길 수 있습니다.
그래서 실제 기기 테스트도 필요합니다.


32. 테스트

테스트는 프로그램이 제대로 동작하는지 확인하는 과정입니다.

단순히 한 번 실행해 보는 것이 테스트의 전부가 아닙니다.

정상 입력 테스트
필수값 누락 테스트
네트워크 오류 테스트
DB 오류 테스트
권한 거부 테스트
실제 기기 테스트
여러 화면 크기 테스트
재실행 테스트

이런 것이 모두 테스트입니다.

바이브 코딩으로 만든 프로그램일수록 테스트가 중요합니다.


33. 운영

운영은 실제 사용자가 프로그램을 사용하는 단계입니다.

개발이 끝나도 운영이 시작되면 새로운 문제가 나옵니다.

사용자 오류
DB 증가
서버 장애
네트워크 오류
앱 업데이트
권한 문제
로그 관리
백업
보안 점검

좋은 프로그램은 개발뿐 아니라 운영까지 고려해야 합니다.


34. 유지보수

유지보수는 프로그램을 계속 고치고 개선하는 일입니다.

오류 수정
기능 추가
화면 개선
속도 개선
DB 구조 변경
정책 변경 대응
새 Android 버전 대응

바이브 코딩은 유지보수에도 유용합니다.

다만 기존 기능을 깨지 않도록 수정 범위를 명확히 해야 합니다.


35. 리팩토링

리팩토링은 기능은 그대로 두고 코드 구조를 개선하는 작업입니다.

예를 들어 긴 코드를 여러 함수로 나누고, 중복 코드를 공통 함수로 만들고, 파일 구조를 정리하는 것입니다.

리팩토링은 프로그램의 유지보수성을 높입니다.

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

“기능은 변경하지 말고 코드 구조만 정리해줘.”

이 문장을 꼭 넣는 것이 중요합니다.


36. 바이브 코딩에서 자주 쓰는 요청 문장

비개발자가 바로 사용할 수 있는 문장은 다음과 같습니다.

“기존 기능은 유지하고 필요한 부분만 수정해줘.”

“수정한 파일 목록과 변경 내용을 요약해줘.”

“오류가 발생해도 프로그램이 종료되지 않게 처리해줘.”

“사용자에게는 쉬운 메시지를 보여주고 상세 오류는 로그에 남겨줘.”

“DB 접속정보는 코드에 직접 넣지 말고 설정 파일에서 읽게 해줘.”

“SQL은 문자열 결합 대신 파라미터 바인딩을 사용해줘.”

“기존 네임스페이스와 클래스명은 변경하지 말아줘.”

“빌드 오류가 없도록 전체 파일 기준으로 작성해줘.”

“수정 후 테스트 방법도 같이 알려줘.”

“운영 DB가 아니라 테스트 DB 기준으로 작성해줘.”


37. 비개발자가 용어를 알아야 하는 이유

바이브 코딩은 AI가 코드를 만들어 주는 방식입니다.

하지만 AI에게 무엇을 요청할지는 사람이 정해야 합니다.

용어를 모르면 다음과 같이 말하게 됩니다.

“이거 안 돼요.”
“프로그램 이상해요.”
“저장되게 해줘.”
“앱 만들어줘.”

용어를 알면 이렇게 말할 수 있습니다.

“저장 버튼 클릭 시 DB INSERT는 되지만, 저장 후 목록 새로고침이 안 됩니다.”

“MainPage.xaml의 x와 MainPage.xaml.cs의 namespace가 맞지 않아 InitializeComponent 오류가 납니다.”

“API Response의 JSON 구조가 변경되어 목록 바인딩이 실패합니다.”

“Android 위치 권한을 거부했을 때 예외 처리가 없어 앱이 종료됩니다.”

이 차이가 바이브 코딩의 품질을 크게 바꿉니다.


38. 5회차 핵심 정리

프로젝트는 프로그램 작업 단위입니다.

솔루션은 여러 프로젝트를 묶은 단위입니다.

UI는 화면이고, UX는 사용 경험입니다.

프론트엔드는 사용자가 보는 부분입니다.

백엔드는 서버에서 처리하는 부분입니다.

API는 프로그램 간 데이터 통신 약속입니다.

JSON은 데이터를 주고받는 대표 형식입니다.

DB 연결과 SQL은 데이터 저장과 조회의 핵심입니다.

빌드는 실행 가능한 프로그램을 만드는 과정입니다.

로그는 오류 원인 파악에 중요합니다.

예외 처리는 프로그램이 갑자기 종료되지 않게 하는 처리입니다.

배포는 사용자가 프로그램을 쓸 수 있게 전달하는 과정입니다.

APK는 Android 직접 설치 파일이고, AAB는 Google Play 업로드 파일입니다.


마무리

비개발자가 바이브 코딩을 잘하기 위해 모든 개발 지식을 깊이 배울 필요는 없습니다.

하지만 기본 용어는 알아야 합니다.

용어를 알면 AI에게 더 정확히 요청할 수 있습니다.
AI가 만든 결과를 더 잘 이해할 수 있습니다.
오류가 났을 때 원인을 더 빨리 찾을 수 있습니다.
개발자와 대화할 때도 훨씬 수월합니다.

바이브 코딩은 “개발을 몰라도 되는 방식”이 아닙니다.

정확히 말하면,
“전문 개발자가 아니어도 개발에 참여할 수 있게 해주는 방식”입니다.

그리고 그 출발점은 기본 용어를 이해하는 것입니다.

반응형