ㅇㅅㅇ

지난 오류 해결 과정에서, 사이드 프로젝트에서 사용하던 gemini-1.5-flash 모델이 지원 종료되면서 500 서버 에러를 겪었습니다.급한 불을 끄기 위해 모델명을 gemini-2.0-flash로 수정해 임시 조치를 했지만, 이 방식은 신규 모델 출시나 구 모델 지원 중단 시 또다시 에러를 유발할 수 있는 ‘코드 속 시한폭탄’과 같다는 생각이 들었습니다.그래서 이번에는 같은 문제가 반복되지 않도록, 보다 근본적인 해결책을 찾기로 했습니다.오류 복구 과정을 블로그 챌린지 회고글로 정리해 올렸는데, 그 글을 본 한 분이 감사하게도 조언을 주셨습니다.그 조언은 바로 Google API에서 제공하는 https://generativelanguage.googleapis.com/v1/models 엔드포인트를 활..

열 번째 도전기 - 코드 관점의 성능 최적화, 사용자 경험을 위한 마지막 여정10주간의 항해가 드디어 마지막 과제에 도달했습니다. Chapter 4-2는 프론트엔드 개발의 완성이라 할 수 있는 코드 레벨 성능 최적화를 다루는 과제였습니다. 저희는 이 과제를 통해 단순히 기능을 구현하는 것을 넘어, "사용자가 실제로 느끼는 성능"에 대해 깊이 고민하며 개발자로서의 시야를 확장했습니다.그리고 이 모든 여정의 끝은 코치님과 팀원들과 함께한 특별한 멘토링 시간이었습니다. 10주간 쌓아 올린 지식과 경험을 '회고의 섬'이라는 형태로 시각화하고, 솔직한 대화를 통해 앞으로 나아갈 방향을 설정하며 뜻깊은 마무리를 했습니다.과제를 통해 배운 것들성능 측정의 중요성 - "측정 없이는 최적화 없다"이번 과제에서 가장 인상..

아홉 번째 도전기 - SSR과 SSG, 서버와 클라이언트의 경계를 넘나들다이번 과제는 정말 특별한 경험이었습니다. 그동안 Vue나 React Next.js로 사이드 프로젝트를 하면서 SSR/SSG 개념은 알고 있었지만, 실제로 직접 구현해보면서 "이게 어떻게 돌아가는 거지?"라는 궁금증을 해소할 수 있었습니다. 처음에는 renderToString이나 window.__INITIAL_DATA__ 같은 것들을 보니까 "이게 뭐야?" 싶었습니다. Next.js나 Nuxt.js 같은 프레임워크에서는 이런 것들을 알아서 해주니까 신경 쓸 일이 없었는데, 이번 과제에서는 그런 기능들을 직접 구현해보라고 하니까 처음에는 정말 어려웠습니다.Vanilla JavaScript로는 어느 정도 구현할 수 있었지만, React로..

여덟 번째 도전기 - TDD와 함께한 성장의 시간7주차에서 테스트 코드의 기본을 익혔다면, 이번 주차는 실제로 TDD 사이클을 따라가며 새로운 기능을 구현하는 실전 단계였습니다. TDD의 이상과 현실을 동시에 경험했습니다.또한, 이번 주차에는 개인적으로 타로를 주제로 한 발표(8주차 스피커 활동)도 병행했습니다. 테스트와 리팩토링 과제를 진행하면서 동시에 발표를 준비해야 했지만, 좋아하는 주제로 사람들과 소통할 수 있었던 의미 있는 시간이었습니다.과제를 통해 배운 것들TDD 프로세스 - Red, Green, Refactor이번 과제에서 처음으로 제대로 TDD 사이클을 의식적으로 따라가봤습니다.🔴 Red - 실패하는 테스트 작성describe('반복 일정 생성', () => { it('매일 반복 일정을..

사이드 프로젝트 MBTI x Tarot | 성향 기반 타로 조언를 정리하던 중, Gemini API 호출에서 발생한 오류를 발견해 해결한 과정을 기록했습니다.📌 문제 상황 (Problem)Vercel 배포 환경에서 타로 리딩 결과 생성을 위해 Gemini API(/api/gemini)를 POST 요청으로 호출했을 때, 그동안 정상적으로 작동하던 부분에서 405 Method Not Allowed 오류가 발생했습니다.// 에러문구POST https://your-tarot-mbti.vercel.app/api/gemini 405 (Method Not Allowed)Gemini 호출 실패: Error: 서버 오류: 405🔍 트러블슈팅 및 해결 과정 (Troubleshooting & Solution)❌ 1차 시..

일곱 번째 도전기 - 테스트 코드로 코드의 안정성 확보하기이번 챕터는 드디어 프런트엔드 개발의 핵심인 테스트 코드에 발을 디딘 시간이었습니다.저는 퍼블리셔 경력으로 자바스크립트를 사용해왔지만, 이렇게 체계적인 테스트 코드를 작성해본 경험은 전무했습니다. 하지만 채용 공고에서 자주 접했던 테스트 코드는 늘 궁금증이었고, 특히 이전 일부 과제에서 코치님들이 테스트 통과를 필수 조건으로 설정하면서 '이렇게 돌아가는구나'를 간접적으로 경험하며 그 필요성을 절감했습니다. 이번 챕터는 이러한 궁금증을 해소하고 테스트 코드의 목적과 패턴을 직접 파헤쳐보는 결정적인 시간이었습니다.사실 이번 과제는 난이도를 선택할 수 있었는데 Hard 난이도를 선택하면 환경 설정까지 직접 구축해야 하는 고난도였습니다. 저는 현재 단계에..