2026/05 74

비동기 처리 첫걸음: 로딩, 성공, 실패를 안정적으로 다루는 패턴

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개프론트엔드에서 체감 품질을 크게 좌우하는 요소 중 하나가 비동기 처리입니다. 같은 API를 호출하더라도 어떤 화면은 안정적으로 느껴지고, 어떤 화면은 멈춘 것처럼 보이는 이유는 로딩·성공·실패 상태를 어떻게 설계했는지에 달려 있습니다. 초보 단계에서는 데이터만 잘 받아오면 끝이라고 생각하기 쉽지만, 사용자 입장에서 중요한 것은 결과가 아니라 진행 과정이 예측 가능한가입니다.예를 들어 버튼을 눌렀는데 반응이 없으면 사용자는 다시 클릭하고, 중복 요청이 발생해 서버와 UI 모두 꼬일 수 있습니다. 또 실패 상황에서 아무 메시지도 없으면 사용자는 원인을 알 수 없어 이탈할 가능성이 높아집니다. 그래서 비동기 처리의 기본은..

함수(Function)는 왜 필요할까? 반복을 줄이는 사고법

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개코드를 조금만 작성해도 같은 로직을 여러 번 복붙하게 됩니다. 이때 필요한 개념이 함수(Function)입니다. 함수는 단순히 문법이 아니라 반복을 줄이고, 실수를 줄이고, 코드를 재사용하게 만드는 사고 도구입니다.2. 핵심 내용함수는 작업을 이름 붙여 묶는 것여러 줄의 동작을 하나의 이름으로 묶어두면 필요할 때 호출만 하면 됩니다. 예를 들어 "할인 가격 계산"이나 "입력값 검증" 같은 반복 작업은 함수로 분리하는 것이 효율적입니다.입력(매개변수)과 출력(반환값)을 명확히좋은 함수는 무엇을 받아서 무엇을 돌려주는지 분명합니다. 입력과 출력을 명확히 하면 테스트가 쉬워지고, 다른 사람이 읽을 때도 이해가 빠릅니다.중..

[바이브코딩 HTML 웹앱 20일 챌린지] 7일차 - 완료한 일은 체크하고, 필요 없는 일은 삭제하기

7일차에서는 할 일 항목에 완료 체크와 삭제 기능을 붙입니다. 6일차에 "추가"까지 됐다면, 오늘은 목록을 실제로 관리할 수 있게 만드는 단계입니다. 완료 상태 전환 + 개별 삭제가 들어가면 웹앱 사용감이 한 단계 올라갑니다.이 단계의 핵심은 "클릭한 항목만 정확히 제어"하는 흐름입니다. 초보자도 이벤트 타겟 개념을 한 번 익혀두면 이후 필터, 진행률, 저장 기능으로 확장할 때 훨씬 유리합니다.목차1. 오늘 만들 기능 소개2. AI에게 요청할 프롬프트3. 코드 작성과 실행 과정4. 코드 이해하기5. 오늘 만든 내용 정리6. 자주 묻는 질문7. 다음 단계로 이어가기1. 오늘 만들 기능 소개오늘 기능은 두 가지입니다. 첫째, 체크박스를 눌러 완료 상태를 표시하고 완료 항목 스타일(예: 취소선, 색상 변경)을..

상태(State) 설계 입문: 어디에 저장하고 누가 바꿔야 할까?

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개프론트엔드 개발에서 버그가 반복되는 가장 큰 이유 중 하나는 상태를 어디에 둬야 하는지 초기에 정하지 않았기 때문입니다. 화면이 커질수록 같은 데이터가 여러 컴포넌트에 흩어지고, 누가 값을 바꿨는지 추적하기 어려워집니다. 결국 기능은 돌아가지만 수정할 때마다 예기치 않은 사이드 이펙트가 생깁니다. 그래서 상태 설계의 첫 질문은 단순합니다. 이 값은 어디에 저장해야 하고, 누가 변경 권한을 가져야 하는가?입문 단계에서 흔히 하는 실수는 “일단 가까운 컴포넌트에 state를 둔다”는 방식입니다. 초기엔 편하지만 기능이 늘어나면 props 전달이 깊어지고, 중간 컴포넌트가 데이터 중계 역할만 하게 됩니다. 이 문제를 줄이..

변수는 '값을 담는 이름표'다: let/const 쉬운 정리

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개JavaScript를 시작하면 가장 먼저 만나는 개념이 변수입니다. 변수는 어렵게 생각할 필요 없이 "값을 담아두는 이름표"입니다. 특히 요즘 문법에서는 let과 const를 구분해 쓰는 습관이 매우 중요합니다.2. 핵심 내용const: 바뀌지 않을 이름표const는 재할당이 불가능한 변수를 선언할 때 사용합니다. 값이 고정되어야 하는 설정값이나 참조값에 적합하며, 기본 선택지로 쓰기 좋습니다.let: 나중에 바뀔 수 있는 이름표let은 재할당이 가능한 변수를 선언할 때 씁니다. 카운트 값처럼 실행 중에 값이 변하는 데이터에 사용합니다.var는 왜 덜 쓰일까?var는 함수 스코프와 호이스팅 특성 때문에 예기치 않은 ..

[바이브코딩 HTML 웹앱 20일 챌린지] 6일차 - 버튼을 누르면 할 일이 추가되게 만들기

6일차에서는 드디어 버튼 클릭으로 할 일이 실제로 추가되게 만듭니다. 5일차에 준비한 입력창, 버튼, 목록 UI에 JavaScript를 연결해서 사용자 입력이 화면에 반영되는 첫 동작을 구현하는 날입니다.이 단계부터 "정적인 페이지"가 아니라 "반응하는 웹앱"으로 넘어갑니다. 초보자 기준에서는 모든 문법을 완벽히 이해하려고 하기보다, 클릭 이벤트가 어떤 순서로 실행되는지 흐름을 잡는 데 집중하면 훨씬 빠르게 성장할 수 있습니다.목차1. 오늘 만들 기능 소개2. AI에게 요청할 프롬프트3. 코드 작성과 실행 과정4. 코드 이해하기5. 오늘 만든 내용 정리6. 자주 묻는 질문7. 다음 단계로 이어가기1. 오늘 만들 기능 소개오늘의 목표는 입력창에 작성한 할 일을 버튼 클릭 한 번으로 목록에 추가하는 것입니다..

기능 쪼개기: 큰 화면을 컴포넌트 단위로 분해하는 기준

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개화면 하나를 통째로 만들기 시작하면 처음에는 빠르게 보이지만, 수정이 반복될수록 코드가 급격히 무거워집니다. 버튼 하나를 고치려 해도 파일 전체를 훑어야 하고, 작은 변경이 다른 영역을 망가뜨리는 일이 자주 생깁니다. 그래서 실무에서는 큰 화면을 먼저 완성하려고 하지 않고, 초기에 컴포넌트 단위로 나누는 기준부터 잡습니다. 이 과정이 흔히 말하는 “기능 쪼개기”입니다.핵심은 디자인을 그대로 조각내는 것이 아니라, 역할과 변경 주기를 기준으로 분해하는 것입니다. 자주 바뀌는 영역과 거의 고정된 영역을 분리하면 이후 요구사항 변경이 들어와도 영향 범위를 예측하기 쉬워집니다. 예를 들어 대시보드 화면이라면 필터 영역, 통..

클래스(class)와 아이디(id), 언제 뭐를 써야 할까?

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개HTML을 작성하다 보면 class와 id를 언제 써야 할지 헷갈립니다. 둘 다 요소를 식별하는 이름표이지만 쓰임새가 다릅니다. class는 여러 개를 묶는 공용 이름, id는 문서 안에서 단 하나만 갖는 고유 이름이라고 기억하면 쉽습니다.2. 핵심 내용class: 반복되는 스타일과 그룹에 적합여러 카드, 버튼, 배지처럼 같은 디자인을 공유하는 요소들에는 class를 사용합니다. 한 요소에 class를 여러 개 붙일 수 있어 재사용성과 조합이 좋습니다.id: 한 페이지에서 유일한 대상에 사용헤더, 특정 섹션 앵커, 고유한 입력 필드처럼 "딱 하나"를 정확히 지목해야 할 때 id를 씁니다. 같은 id를 여러 요소에 중..

[바이브코딩 HTML 웹앱 20일 챌린지] 5일차 - 할 일을 입력하는 공간 만들기

5일차에서는 사용자가 할 일을 입력할 수 있는 공간을 만듭니다. 지금까지는 보기 좋은 구조와 스타일을 준비했다면, 오늘은 실제 상호작용을 위한 UI를 올리는 단계입니다. 입력창, 추가 버튼, 목록 영역을 먼저 완성해두면 내일 JavaScript 동작을 붙이기 훨씬 쉬워집니다.이 단계의 핵심은 아직 "작동"이 아니라 "준비된 화면"입니다. 초보자 기준에서는 기능 구현 전에 화면 요소를 분리해두는 습관이 중요하고, 바이브코딩에서도 AI에게 요청 범위를 줄여 정확한 코드를 받는 데 큰 도움이 됩니다.목차1. 오늘 만들 기능 소개2. AI에게 요청할 프롬프트3. 코드 작성과 실행 과정4. 코드 이해하기5. 오늘 만든 내용 정리6. 자주 묻는 질문7. 다음 단계로 이어가기1. 오늘 만들 기능 소개오늘 만들 기능은..

요구사항을 코드로 바꾸는 법: “무엇을 만들지” 한 줄로 명확히 쓰기

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개개발을 시작할 때 가장 자주 부딪히는 문제는 기술이 아니라 방향입니다. 무엇을 만들어야 하는지 팀 안에서 같은 그림을 갖지 못하면, 코드는 빠르게 늘어나도 결과물은 계속 흔들립니다. 그래서 실전에서는 요구사항 문서를 길게 쓰기보다 먼저 한 줄 목표를 명확하게 만드는 습관이 중요합니다. 예를 들어 “사용자가 3분 안에 회원가입을 끝낼 수 있는 화면을 만든다”처럼 사용자, 행동, 제한 조건이 모두 들어간 문장은 구현 우선순위를 결정하는 기준이 됩니다. 이 한 줄이 있으면 디자이너는 어떤 입력이 꼭 필요한지 판단할 수 있고, 개발자는 어떤 API가 먼저 필요한지 바로 정리할 수 있습니다.반대로 목표 문장이 모호하면 작은 ..