비전공자를 위한 바이브코딩 공부

웹 기초부터 개발 도구, 데이터, 보안과 수익화까지 처음 배우는 사람의 눈높이로 설명합니다.

• 주소를 입력하면 웹페이지가 열리는 과정을 주문 배달처럼 이해하기

  웹 주소를 입력하면 브라우저는 DNS로 서버 주소를 찾고 HTTP 요청을 보냅니다. 서버가 돌려준 HTML, CSS, JavaScript와 이미지를 조합해 화면을 그리며, 404나 500 오류가 보이면 이 요청과 응답 중 실패한 구간을 확인하면 됩니다.

• 프론트엔드와 백엔드와 데이터베이스를 식당 역할로 구분하기

  프론트엔드는 사용자가 보고 누르는 화면, 백엔드는 요청과 규칙을 처리하는 보이지 않는 부분, 데이터베이스는 회원과 주문 같은 기록을 보관하는 곳입니다. 식당으로 비유하면 각각 홀, 주방, 장부에 해당하며 세 역할이 연결돼 하나의 기능이 완성됩니다.

• API와 JSON을 메뉴판과 주문서처럼 읽는 첫 연습

  API는 다른 서비스에 정해진 방식으로 기능이나 데이터를 요청하는 연결 창구이고, JSON은 그 요청과 답을 이름과 값의 묶음으로 적는 형식입니다. 메뉴판에서 가능한 주문을 확인하고 주문서에 항목을 적는 과정으로 생각하면 두 개념을 함께 이해하기 쉽습니다.

• Git 커밋과 브랜치를 게임 저장 지점처럼 이해하기

  Git 커밋은 지금 파일 상태를 다시 찾을 수 있게 남기는 저장 지점이고, 브랜치는 원본 흐름을 건드리지 않고 다른 수정을 시험하는 별도 길입니다. AI에게 코드를 맡기기 전에 커밋을 만들면 문제가 생겨도 바뀐 부분을 비교하고 안전하게 되돌리기 쉽습니다.

• 환경변수와 API 키를 서랍과 금고처럼 구분하는 법

  환경변수는 주소나 실행 모드처럼 프로그램 밖에서 바꿀 설정을 담는 서랍이고, API 키는 외부 서비스 사용 권한을 가진 비밀번호에 가깝습니다. 비밀키는 브라우저 코드나 Git 저장소에 넣지 말고 서버의 비밀 저장소에서만 읽도록 해야 합니다.

• 파일 경로를 집 주소처럼 읽고 터미널에서 길을 잃지 않는 법

  파일은 내용을 담은 문서이고 폴더는 파일을 묶는 공간입니다. 절대경로는 출발점부터 적은 전체 주소, 상대경로는 현재 폴더를 기준으로 적은 길 안내입니다. 터미널에서는 먼저 `pwd`로 현재 위치를 확인한 뒤 `ls`로 목록만 읽으면 엉뚱한 곳을 바꾸는 실수를 줄일 수 있습니다.

• HTML과 CSS와 JavaScript를 집 구조와 꾸밈과 동작으로 나누기

  HTML은 제목과 버튼 같은 내용의 구조와 의미를 만들고, CSS는 색과 간격과 배치를 꾸미며, JavaScript는 클릭 뒤 문구 변경 같은 동작을 처리합니다. 집으로 비유하면 뼈대와 방 배치, 벽지와 가구, 전등 스위치에 해당하므로 화면 문제를 세 역할로 나누면 고칠 곳을 찾기 쉬워집니다.

• 모바일 반응형 화면과 키보드 접근성을 함께 점검하는 첫 순서

  반응형 디자인은 같은 내용을 휴대전화와 큰 화면에서 읽기 좋게 재배치하는 방법이고, 접근성은 키보드나 화면 읽기 도구 등 다양한 방식으로 기능을 사용할 수 있게 만드는 기준입니다. 390픽셀 화면의 가로 넘침과 Tab 키의 이동 순서를 각각 확인해야 둘을 함께 지킬 수 있습니다.

• 입력 폼의 오류를 주문서 확인처럼 설계하는 법

  입력 폼은 잘못된 값을 바로 고칠 수 있도록 브라우저에서 형식과 누락을 알려 주고, 서버에서는 같은 값을 다시 검사해야 합니다. 브라우저 검증은 사용자를 돕지만 우회할 수 있으므로 보안 경계가 될 수 없고, 오류 문장은 문제 난 항목과 고치는 방법을 함께 알려 줘야 합니다.

• 쿠키와 세션과 브라우저 저장소를 보관함 위치로 구분하기

  쿠키는 브라우저가 보관하며 조건에 맞는 서버 요청에 함께 보낼 수 있는 작은 값이고, 세션은 보통 서버가 로그인 상태를 보관하고 쿠키에는 연결용 식별자만 두는 방식입니다. localStorage는 같은 출처의 브라우저에 남지만 요청에 자동 첨부되지 않으므로 화면 설정에는 쓸 수 있어도 비밀키 저장소로 보면 안 됩니다.

• npm 패키지와 의존성을 장보기 목록처럼 읽는 법

  npm 패키지는 프로젝트에서 다시 쓸 수 있게 묶은 코드이고, 의존성은 내 프로젝트가 작동하려고 기대는 패키지입니다. package.json은 필요한 이름과 허용 버전을 적은 목록이며 package-lock.json은 실제 설치된 전체 버전을 기록하므로 둘을 함께 보관해야 같은 환경을 재현하기 쉽습니다.

• TypeScript 타입을 택배 상자 라벨처럼 읽는 첫 연습

  TypeScript 타입은 변수와 함수가 받을 값의 종류를 코드에 표시해 잘못된 조합을 실행 전에 찾도록 돕습니다. 문자열, 숫자, 참거짓 같은 라벨을 붙이면 편집기와 검사 도구가 실수를 알려 주지만, 외부에서 들어온 실제 데이터의 내용까지 자동으로 안전하게 만드는 것은 아닙니다.

• 오류와 로그를 진료 기록처럼 읽고 원인을 좁히는 순서

  디버깅은 오류 문장을 지우는 일이 아니라 같은 문제를 다시 만들 수 있는 조건을 기록하고 첫 실패 지점을 찾는 과정입니다. 화면 증상, 입력, 시간, 파일과 줄 번호, 기대 결과를 분리해 적은 뒤 한 번에 한 가지만 바꾸면 로그의 결과와 실제 원인을 혼동할 가능성이 줄어듭니다.

• 단위와 통합과 브라우저 테스트를 주방 검사처럼 나누기

  단위 테스트는 작은 함수 하나, 통합 테스트는 여러 부분의 연결, 브라우저 테스트는 사용자가 보는 화면 흐름을 확인합니다. 한 종류가 통과해도 다른 범위까지 자동으로 보장되지는 않으므로 빠른 작은 검사부터 실제 환경에 가까운 검사까지 겹쳐 배치하고 실패한 범위를 먼저 좁혀야 합니다.

• 저장과 빌드와 배포를 포장 배송 공개처럼 구분하기

  저장은 작업 파일을 남기는 일, 빌드는 소스 코드를 서비스용 결과물로 만드는 일, 배포는 그 결과물을 서버에 올리는 일입니다. 배포 성공 표시만으로 실제 공개 주소가 새 결과물을 제공한다고 단정할 수 없으므로 도메인, 번들, 핵심 기능과 메타데이터를 공개 환경에서 다시 확인해야 합니다.

• 터미널 첫 명령은 현재 위치와 파일 목록 확인부터 시작하기

  터미널을 처음 배울 때는 파일을 바꾸는 명령보다 현재 폴더를 보여 주는 pwd와 파일 목록을 보여 주는 ls부터 익히는 것이 안전합니다. 명령을 입력하기 전 현재 위치, 대상 경로, 옵션의 뜻을 확인하고 삭제·설치·권한 변경 명령은 이해할 때까지 실행하지 마세요.

• Git push와 pull을 보내기와 받아오기로 구분하는 법

  Git push는 내 로컬 커밋을 원격 저장소로 보내고, pull은 원격 변경을 받아 현재 브랜치에 합치는 명령입니다. 바로 주고받기 전에 git status와 git fetch로 차이를 읽고, 비밀 파일과 예상 밖 커밋이 없는지 확인한 뒤 공유 브랜치에는 강제 push를 피하는 것이 안전합니다.

• Git 병합 충돌에서 두 변경을 잃지 않고 해결하는 순서

  Git 병합 충돌은 두 작업 흐름이 같은 부분을 다르게 바꿔 Git이 자동 선택을 못한 상태입니다. 충돌 파일과 양쪽 변경을 먼저 보존하고 표시된 두 내용을 비교해 최종 문장을 직접 만든 뒤, 표시 제거와 테스트를 확인하고 git add와 commit으로 해결을 기록해야 합니다.

• GitHub Actions로 커밋마다 테스트가 도는 흐름 이해하기

  GitHub Actions의 CI는 push나 pull request 같은 사건이 생기면 별도 실행 컴퓨터인 러너에서 설치와 테스트 단계를 자동 수행하는 방식입니다. 워크플로 파일의 실행 조건, 권한, 비밀값 사용, 통과한 정확한 커밋을 확인해야 하며 초록 표시가 실제 배포나 모든 기능의 정상 동작까지 보장하지는 않습니다.

• 도메인과 DNS와 HTTPS가 배포 주소를 잇는 과정

  도메인은 사람이 읽는 웹 주소이고 DNS는 그 이름을 배포 서비스가 안내한 서버 위치로 연결합니다. 연결 뒤 인증 기관이 도메인 제어권을 확인해 HTTPS 인증서를 발급하면 브라우저가 암호화 통신을 할 수 있으며, DNS와 인증서와 실제 콘텐츠는 각각 따로 확인해야 합니다.