윤재의 서버 로그

3주차에 JdbcTemplate으로 GET /books, POST /books를 만들어보면서 꽤 불편한 게 많았습니다. titel 오타 하나 냈다고 500이 터지고, 응답에는 book_id, is_available 같은 DB 컬럼명이 그대로 나가고, ? 개수랑 파라미터 순서는 눈으로 하나하나 맞춰야 했습니다. 이번 4주차는 새 기능을 만드는 게 아니라, 이 API를 JPA랑 DTO로 다시 짜보는 주차였습니다.사실 JPA는 그냥 "SQL 안 짜도 되는 거" 정도로만 알고 있었는데, 워크북에 ORM이 SQL을 없애주는 게 아니라는 말이 있더라고요. 그래서 이번엔 아예 로그를 켜놓고 JPA가 실제로 무슨 SQL을 날리는지 보면서 진행해봤습니다. 설정부터: SQL 로그 켜기 yamlspring: jpa: ..

1주차에는 ERD로 무엇을 저장할지 정했고, 2주차에는 SQL로 데이터를 꺼냈습니다. 그런데 지금까지는 Workbench에서 Ctrl + Enter를 제가 직접 눌렀습니다.3주차는 그 버튼을 서버가 대신 누르게 만드는 주차였습니다. Postman이 요청을 보내면 Spring 서버가 DB에 SQL을 날리고, 결과를 JSON으로 돌려주는 첫 API를 만들었습니다.이번 주차는 일부러 DTO와 ORM 없이 Raw SQL + Map으로만 구현했습니다. 편한 도구를 쓰기 전에 그 도구가 없으면 무엇이 불편한지 먼저 겪어보는 구성이었습니다. 워크북은 Spring Boot와 NestJS 코드를 함께 제공했는데, 저는 Spring Boot로 진행했습니다.INSERT: 2주차에 실행만 하고 넘어간 그 문법2주차 02_se..

1주차에는 요구사항을 보고 "어떤 데이터를 어떤 모양으로 저장할지"를 ERD로 설계했습니다. 2주차는 그 반대 방향입니다. 설계한 테이블에서 화면에 필요한 데이터를 SQL로 꺼내는 주차였습니다.프론트를 할 때는 API 응답 JSON이 "원래 그렇게 생긴 것"처럼 느껴졌습니다. 이번 주차를 해보니 그 JSON 한 덩어리가 사실 SELECT ... JOIN ... WHERE ... 한 줄의 결과였다는 게 연결됐습니다. 실습 환경: 다시 만난 127.0.0.1MySQL Community Server와 Workbench를 설치하고 로컬 연결을 만들었습니다.Host: 127.0.0.1Port: 33060주차에 정리했던 루프백 주소와 포트가 여기서 바로 나왔습니다. "내 컴퓨터 안(127.0.0.1)의 MySQL..

0주차에서 클라이언트-서버와 HTTP를 정리했다면, 1주차는 그 서버 뒤편, 데이터가 실제로 어떻게 저장되는가를 설계하는 주차였습니다. 솔직히 저는 지난 기수 내내 프론트를 하면서 API가 내려주는 JSON을 받아 화면에 뿌리기만 했지, "이 데이터가 DB에 어떤 모양으로 들어있는지"는 거의 신경 쓴 적이 없었습니다. 이번 주차는 그 반대편, DB를 직접 설계(ERD 작성) 해보는 시간이라 개인적으로 제일 낯설면서도 얻어간 게 많았습니다.왜 다들 RDB를 메인 DB로 쓸까먼저 짚은 건 "왜 스타트업부터 대기업까지 십중팔구 MySQL/PostgreSQL 같은 RDB를 1순위로 두는가"였습니다. 단순히 익숙해서가 아니라, 데이터 사고를 막아주는 무기들이 있어서였습니다. 단일 진실 공급원(SSOT): 주문마다..

11기가 시작되었습니다. 정규 커리큘럼 전에 몸을 푸는 자율 워밍업 파트라 부담 없이 접근했는데, 오히려 그동안 당연하게 써오던 개념들을 다시 정리하기에 딱 좋은 주차였습니다.지난 기수 내내 프론트에서 API를 붙이고 데이터를 패칭하면서도, 정작 "서버가 뭔데?", "요청과 응답 사이에서 실제로 무슨 일이 일어나지?"라는 질문에는 뭉뚱그려 답하고 있었습니다. 이번 0주차는 그 뭉뚱그린 부분을 한 번 짚고 넘어가는 시간이었습니다.클라이언트-서버 ≠ 프론트엔드-백엔드가장 먼저 바로잡은 건 이 부분이었습니다. 저도 은연중에 "프론트 = 서버 없음, 백엔드 = 서버 개발자"라고 생각하고 있었는데, 사실 틀린 전제였습니다.프론트엔드도 웹이라면 HTML/CSS/JS를 웹 서버에 배포합니다. 새 컴퓨터로 처음 nav..

PM DAY가 5월 말에 진행된 이후 마지막 Web 스터디를 마쳤다.총 10주차로 진행되었고 마지막 배포까지 하면서 이제 프론트엔드에서는 웬만한 기술은 다 사용하지는 못해도개념이 잡히고 이해는 바탕으로 가져갈 수 있게 되었다.처음 시작한 의도대로 개발에 조금 더 재미를 붙이고 화면을 제작하는데 시간을 쏟을 수 있게 되어서 좋았다. 그리고 머핀이라는 프로젝트에 지원했다.1차 지원에 마감할 정도로 경쟁률이 꽤 높고 인기가 있어서 어차피 지금 아니면 지원도 못하기에 고민할 것 없이 바로 작성했다.포트폴리오는 https://valanse.kr/main 의 기획 경험과 https://github.com/D5-wq/unimind_web 이 2가지를 바탕으로 기존에 동아리 지원에 사용하던 사진과 멘트들을 재활용하여 ..

안녕하세요황구/황윤재입니다. 9주차에서 "이 상태는 누가 읽고 누가 쓰는가"를 고민하며 상태를 보관하는 그릇을 골랐다면, 이번 10주차는 그 상태가 화면을 다시 그릴 때 — 즉, 불필요한 렌더링을 어떻게 줄일 것인가를 다뤘습니다. 그리고 내 컴퓨터에만 있던 결과물을 Vercel로 배포해 실제 인터넷에 띄우는 것까지, UMC 웹 파트의 마지막 퍼즐을 맞췄습니다. 핵심 키워드는 세 가지입니다. memo, useCallback, useMemo. 셋 다 "기억(메모이제이션)"이라는 같은 뿌리에서 나왔지만, 기억하는 대상이 각각 다릅니다. 1. memo — "컴포넌트"를 기억한다React는 부모가 리렌더링되면 자식도 전부 다시 그립니다. memo로 감싸면 props가 바뀌지 않는 한 자식의 리렌더링을 건너뜁니..

안녕하세요 황구/황윤재입니다. 8주차에서 Debounce와 Throttling으로 이벤트의 박자를 다듬었다면, 이번 9주차는 한 발짝 더 안쪽으로 들어가 그 이벤트가 만들어내는 상태를 어떻게 보관하고 누가 공유할 것인가 — 즉, 클라이언트 상태 관리 전략을 다뤘습니다. 핵심 키워드는 두 가지입니다. Redux Toolkit과 Zustand. 둘 다 전역 상태를 관리하지만, 철학과 코드량이 전혀 다릅니다. 1. Redux Toolkit — "단방향 흐름으로 상태를 추적한다"Redux Toolkit은 액션 → 리듀서 → 상태 변경의 단방향 흐름이 강제됩니다. 변경 이력이 명확하고 Redux DevTools로 어떤 액션이 언제 발생했는지 추적할 수 있어 디버깅이 용이하지만, 그만큼 셋업 코드가 많습니다.mi..

안녕하세요 황구/황윤재입니다.7주차에서 useMutation과 낙관적 업데이트로 서버 상태를 다뤘다면, 이번 8주차는 한 발짝 더 나아가 클라이언트에서 이벤트 자체를 얼마나 영리하게 제어하느냐를 배웠습니다.핵심 키워드는 두 가지입니다. Debounce와 Throttling. 이름은 비슷해 보이지만 목적과 동작 방식이 전혀 다릅니다.1. Debounce — "마지막 입력만 유효하다"Debounce는 이벤트가 연속으로 발생할 때, 마지막 이벤트가 끝난 후 일정 시간이 지나야 실제 로직을 실행하는 기법입니다.검색창이 대표적인 예시입니다. 사용자가 "타이핑"을 입력할 때 글자 하나하나마다 API를 호출하면 낭비입니다. 입력이 멈춘 뒤 300ms 후에 딱 한 번만 요청을 보내는 것이 훨씬 효율적이죠.useDebo..

📝 학습 목표개념 이해낙관적 업데이트(Optimistic Update)가 왜 필요한지 설명할 수 있다.TanStack Query의 useMutation 라이프사이클(onMutate, onError, onSettled) 흐름을 이해할 수 있다.invalidateQueries와 setQueryData의 차이점을 실제 사례와 함께 설명할 수 있다.구현 역량닉네임 변경, 좋아요 토글 기능에 낙관적 업데이트를 적용할 수 있다.Query Key를 기반으로 캐시를 효율적으로 관리할 수 있다.실패 시 이전 상태로 롤백하는 흐름을 구현할 수 있다.설계·품질서버 요청 실패 시 데이터 정합성을 유지하는 전략을 설계할 수 있다.경쟁 상태(중복 클릭, 응답 순서 꼬임)를 고려한 코드를 작성할 수 있다.invalidateQue..