전체 글 79

[바이브코딩 HTML 웹앱 20일 챌린지] 14일차 - 눈이 편한 다크모드 추가하기

14일차에서는 밝은 화면과 어두운 화면을 전환하는 다크모드를 추가합니다. 기능 자체는 단순하지만 사용성이 크게 좋아지고, 사용자 환경에 맞는 UI 제어를 익히는 좋은 단계입니다.오늘은 버튼 하나로 테마를 바꾸고, 선택한 테마를 localStorage에 저장해 다시 접속해도 같은 모드가 유지되도록 구현합니다.목차1. 오늘 만들 기능 소개2. AI에게 요청할 프롬프트3. 코드 작성과 실행 과정4. 코드 이해하기5. 오늘 만든 내용 정리6. 자주 묻는 질문7. 다음 단계로 이어가기1. 오늘 만들 기능 소개오늘 목표는 테마 전환 토글입니다. 버튼을 클릭하면 `body`에 `dark-mode` 클래스를 붙이거나 제거하고, CSS에서 이 클래스 기준으로 배경색/글자색/카드색을 바꿔서 전체 톤을 전환합니다.2. AI..

JavaScript 코드가 실행되지 않을 때 가장 먼저 볼 곳

목차1. 왜 JS가 멈춘 것처럼 보일까2. 가장 먼저 확인할 5가지3. 실제 점검 순서와 복구 방법4. 재발 방지를 위한 개발 습관5. 자주 묻는 질문1. 왜 JS가 멈춘 것처럼 보일까JavaScript가 실행되지 않을 때 가장 답답한 점은 화면만 보면 원인이 전혀 보이지 않는다는 것입니다. 버튼도 보이고 입력창도 있는데, 클릭해도 변화가 없으니 코드 전체가 고장 난 느낌이 들죠. 하지만 대다수 문제는 특정 한 지점에서 스크립트가 끊긴 상태입니다. 즉, 전부 실패한 것이 아니라 한 줄의 에러가 이후 실행을 막는 구조인 경우가 흔합니다.그래서 중요한 건 "무엇이 안 되나"보다 "어디서 실행이 멈추나"를 찾는 것입니다. 콘솔, 스크립트 로드, DOM 시점, 선택자, 캐시를 순서대로 확인하면 생각보다 빠르게 ..

“투두앱 만들어줘”보다 더 좋은 요청 방식은 무엇일까?

목차1. 왜 “투두앱 만들어줘”는 아쉬운 요청일까2. 좋은 요청이 갖춰야 할 4요소3. 실제로 바꿔 쓰는 프롬프트 예시4. 작업 속도를 높이는 운영 팁5. 자주 묻는 질문1. 왜 “투두앱 만들어줘”는 아쉬운 요청일까처음 AI 코딩을 시작하면 가장 많이 쓰는 문장이 “투두앱 만들어줘”입니다. 짧고 편하지만, 실전에서는 이 방식이 오히려 시간을 늘릴 때가 많습니다. 이유는 간단합니다. 이 요청에는 기능 범위, 사용 기술, 데이터 저장 방식, UI 기준, 예외 처리 규칙이 모두 빠져 있기 때문입니다. AI는 빠르게 결과를 내지만, 빠른 결과와 맞는 결과는 다릅니다.예를 들어 어떤 사용자는 로컬스토리지를 원하고, 어떤 사용자는 서버 API 연동을 원합니다. 어떤 사람은 모바일 반응형이 필수고, 어떤 사람은 데스..

복붙이 많은 JavaScript 코드 줄이기: 초보 코드 리뷰 Before & After

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개JavaScript를 처음 배우면 기능을 빠르게 완성하는 데 집중하게 됩니다. 이때 가장 흔한 패턴이 바로 복사해서 붙여넣기, 즉 복붙입니다. 버튼마다 거의 같은 이벤트 코드를 여러 번 작성하고, 유효성 검사도 입력칸 개수만큼 반복하고, API 호출 후 처리도 페이지마다 비슷하게 붙여넣다 보면 당장은 편해 보여도 금방 코드가 무거워집니다. 특히 수정 요청이 들어왔을 때 문제가 커집니다. 예를 들어 같은 로직이 7곳에 흩어져 있으면 1곳만 고치고 끝날 수 없고, 실수로 1~2곳을 빼먹기 쉽습니다. 결과적으로 버그가 다시 생기고, "분명 고쳤는데 왜 또 안 되지?"라는 상황이 반복됩니다.이 글은 초보 코드 리뷰 관점에서..

[바이브코딩 HTML 웹앱 20일 챌린지] 13일차 - 오늘 얼마나 해냈는지 진행률로 보여주기

13일차에서는 오늘 해낸 양을 숫자와 막대로 보여주는 진행률 기능을 만듭니다. 지금까지 쌓은 할 일/습관 데이터를 바탕으로 완료 비율을 시각화하면 사용자는 하루 성취를 더 직관적으로 확인할 수 있습니다.이 기능은 단순 계산처럼 보여도 사용자 동기 유지에 매우 효과적입니다. 초보자도 완료 개수와 전체 개수만 정확히 계산하면 쉽게 구현할 수 있습니다.목차1. 오늘 만들 기능 소개2. AI에게 요청할 프롬프트3. 코드 작성과 실행 과정4. 코드 이해하기5. 오늘 만든 내용 정리6. 자주 묻는 질문7. 다음 단계로 이어가기1. 오늘 만들 기능 소개오늘 목표는 완료한 할 일과 체크한 습관을 기준으로 진행률을 계산해 보여주는 것입니다. 예를 들어 완료 5개 / 전체 8개라면 62%를 출력하고, 진행률 바 너비도 6..

버튼을 눌러도 아무 일도 안 일어날 때 확인할 것

목차1. 버튼 클릭이 먹통처럼 보이는 이유2. 가장 먼저 보는 체크리스트3. 실전 점검 순서와 수정 예시4. 다시 같은 문제를 막는 습관5. 자주 묻는 질문1. 버튼 클릭이 먹통처럼 보이는 이유버튼을 눌렀는데 화면이 조용하면 많은 분이 "코드가 전부 망가졌나?"부터 떠올립니다. 하지만 실제로는 작은 연결 문제인 경우가 더 많습니다. 특히 초보 단계에서는 버튼 자체가 고장 난 것이 아니라, 버튼과 JavaScript 함수가 서로 만나지 못한 상태가 대부분입니다.예를 들어 클릭 이벤트를 등록했는데 스크립트 파일 경로가 틀렸거나, HTML에서 사용한 id 이름과 JavaScript에서 찾는 id가 다르면 아무 일도 일어나지 않습니다. 또 콘솔에 에러가 떠도 화면에서는 조용해 보이기 때문에 문제를 늦게 발견하기..

좋은 코드를 만드는 프롬프트와 나쁜 프롬프트 비교하기

목차1. 왜 프롬프트 품질이 코드 품질을 바꾸는가2. 좋은 프롬프트 vs 나쁜 프롬프트 핵심 비교3. 바로 써먹는 개선 요청 구조4. 실전 체크리스트 정리5. 자주 묻는 질문1. 왜 프롬프트 품질이 코드 품질을 바꾸는가AI 코딩에서 결과물이 들쭉날쭉한 가장 큰 이유는 모델 성능보다 요청의 구조에 있습니다. 같은 모델이라도 “투두 앱 만들어줘”처럼 범위가 넓은 요청을 받으면, 기능 정의·UI·데이터 저장 방식·예외 처리 기준을 스스로 추측해야 합니다. 이때 추측은 빠르지만, 팀 프로젝트 기준으로는 위험합니다. 반대로 입력 조건, 목표, 제약, 출력 형식을 분리해서 전달하면 AI는 추측 대신 선택지를 줄이고, 코드의 일관성을 높입니다.핵심은 복잡한 문장을 쓰는 것이 아니라, 모호함을 줄이는 것입니다. 요구사..

배포와 운영 입문: 개발 완료 후 실제 서비스까지의 흐름

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개많은 주니어 개발자가 “기능 구현 완료 = 프로젝트 완료”라고 생각하지만, 실무에서는 배포와 운영이 시작점에 더 가깝습니다. 로컬에서는 잘 되던 기능도 실제 서버 환경에서는 설정 차이, 트래픽, 외부 API 상태 등 다양한 변수로 문제를 일으킬 수 있습니다. 그래서 개발이 끝난 뒤에는 코드보다 더 중요한 질문이 생깁니다. “이 기능을 안전하게 서비스에 올리고, 문제가 나면 빠르게 복구할 수 있는가?” 이 질문에 답하는 과정이 바로 배포와 운영입니다.입문 단계에서 가장 놓치기 쉬운 부분은 운영 관점입니다. 배포를 한 번 성공시키는 것보다, 반복 가능한 배포 프로세스를 만드는 것이 훨씬 중요합니다. 사람 기억에 의존한 ..

성능 최적화 기초: 체감 속도를 빠르게 만드는 우선순위

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개성능 최적화라고 하면 많은 개발자가 복잡한 기법부터 떠올리지만, 실제로 체감 속도를 좌우하는 요소는 의외로 기본적인 부분에 있습니다. 사용자는 코드 구조를 보지 않고 “화면이 빨리 뜨는지”, “클릭했을 때 바로 반응하는지”만 경험합니다. 그래서 성능 개선의 출발점은 점수 올리기가 아니라, 사용자가 느끼는 지연을 먼저 줄이는 것입니다. 즉, 최적화의 핵심은 기술 난이도가 아니라 우선순위 설정입니다.실무에서 흔한 실수는 병목을 측정하지 않은 채 최적화를 시작하는 것입니다. 이 경우 시간은 많이 쓰지만 효과는 작을 수 있습니다. 반대로 초기 렌더링, 이미지 용량, 불필요한 재렌더링처럼 영향이 큰 지점을 먼저 잡으면 적은 ..

디버깅은 에러 찾기가 아니라 '원인 좁히기'다

목차1. 주제 소개2. 핵심 내용3. 적용 방법4. 정리5. 자주 묻는 질문1. 주제 소개디버깅을 "에러 메시지 찾기" 정도로 생각하면 자주 막히게 됩니다. 실제 디버깅의 핵심은 정답을 한 번에 맞히는 것이 아니라 원인 범위를 점점 좁혀가는 과정입니다. 디버깅은 추측이 아니라 가설과 검증의 반복입니다.2. 핵심 내용증상과 원인을 분리해서 본다화면이 안 보이는 것은 증상이고, 잘못된 상태값/렌더 조건/비동기 타이밍 문제는 원인입니다. 증상만 보고 바로 수정하면 임시방편이 되기 쉽습니다.재현 가능한 최소 조건을 만든다문제가 언제 발생하는지 입력값, 클릭 순서, 환경을 고정해 "재현 시나리오"를 만드는 것이 우선입니다. 재현이 되면 원인 추적 속도가 급격히 빨라집니다.로그와 브레이크포인트로 범위를 좁힌다con..