Apollo Client의 cache-and-network 재요청 중 이전 값을 지키는 법
useQuery를 통째로 감싸는 낯선 코드를 만났다. 캐시를 쓰는 GraphQL 클라이언트라면 새로고침 중에도 화면에 값이 남아있을 거라고 막연히 생각하고 있었다. 왜 이런 패턴을 사용하고 있었을까?
getServerSideProps에서 실제로 일어나는 일
getServerSideProps 코드를 보다가 "그래서 이 함수는 내부적으로 어떻게 동작하는거지?"라는 의문이 생겼다. props가 페이지 컴포넌트로 전달된다는 사실은 알고 있었지만, 그 사이 서버에서 정확히 무슨 일이 일어나는지는 설명하지 못했다. 요청 하나가 들어오는 순간부터 화면에 그려지기까지의 경로를 처음부터 따라가보고자 했다.
nginx와 애플리케이션 코드의 리버스 프록시 구분하기
nginx 뒤에 있는 Node.js 애플리케이션 코드를 들여다보다가, 그 안에도 "프록시"라고 부르는 코드가 있는 걸 봤다. 리버스 프록시는 nginx 같은 별도 서버의 몫인 줄 알았는데, 같은 이름의 개념이 애플리케이션 코드 안에도 있다는 사실이 한동안 헷갈렸다. 공식 문서를 하나씩 짚어가며 확인해보니, 두 프록시는 이름은 같아도 어느 프로세스 경계 안에 서 있는지부터 달랐다.
Apollo Client의 fetchPolicy 기본값이 cache-first인 이유
Apollo Client의 fetchPolicy 옵션 중, 최신값까지 확인하는 cache-and-network가 가장 좋은 선택이라 생각했다. 하지만, 라이브러리의 기본값은 캐시에 값이 있으면 네트워크조차 안 쓰는 cache-first였다. 왜 라이브러리는 이쪽을 선택했을까?
AI 시대에서 개발자가 시간을 써야 할 곳은 어디일까?
최근 AI로 토이 프로젝트를 진행하다가, 필터 하나를 검토 없이 승인했더니 상태 관리 구조를 통째로 다시 설계해야 했던 일이 있었다. 그 경험을 계기로, AI가 구현을 대신해주는 지금 개발자가 정작 시간을 써야 할 곳이 어디인지 정리해봤다. 결론부터 말하면, 그 판단은 뒷단이 아니라 앞단에서 이뤄져야 한다.
안쓰는 코드인 줄 알면서도 계속 검증했던 이유
사용처가 없는 코드를 지우려 할 때, 근거를 아무리 모아도 배포 전까지는 좀처럼 확신이 서지 않았다. 이 불안은 왜 생기고, 어떻게 하면 확신을 갖고 코드를 지울 수 있을까?
반복을 줄이는 것보다 역할을 드러내는 코드
클론 코딩 리뷰에서 받은 질문에 답하다 보니 컴포넌트에 옵셔널 prop이 쌓였고, 이름만으로 역할을 설명하기 어려워졌다. 컴포넌트를 나눌지 고민하던 중 리뷰어에게 "이정표"라는 개념을 듣고, 데이터 안 문자열과 JSX 안 문자열의 코드 탐색성 차이를 정리했다.
useEffect 콜백에 이름을 붙인다면
리뷰에서 useEffect 콜백에 이름을 붙여보라는 피드백을 받았다. 한 번만 쓰이는 함수에 이름이 왜 필요한지 처음엔 와닿지 않았는데, 직접 적용해보니 effect가 여러 개인 컴포넌트에서는 이름이 목차 역할을 했고 스택 트레이스에도 그대로 남았다.
첫 회사의 입사를 앞두고
취업 준비 2개월 차, 처음 본 면접에서 그동안 머릿속으로 그려왔던 이상적인 개발자의 모습을 마주했다. 감사하게도 그 면접은 합격으로 이어졌고, 이번 글에 그 과정을 정리해보려 한다. 입사를 준비하며 앞으로 어떤 개발자로 성장하고 싶은지도 함께 고민해보았다.
2026년 03월 회고
공채 시즌을 맞아 이력서 작성에 집중하다 보니, 문득 ‘내가 진짜로 하고 싶은 일이 무엇인지’, ‘어디를 향해 가고 있는지’에 대한 의문이 생겼다. 무작정 달리는 것보다 방향을 먼저 정하고 나아가는 게 맞다는 생각이 들었다. 그래서 지금의 상황과 앞으로 나아가고 싶은 길에 맞게, 목표를 다시 세워보려 한다.
Socket.IO 10,000명 재연결 부하 테스트
Socket.IO 옵션 변경이 유효한지 이론이 아닌 실제 부하 테스트로 검증한다. 서버 전체 연결이 동시에 끊기는 순간에서 현재 설정이 어디까지 버티는지, 어디서 무너지는지, 그리고 자동 재연결이 그것을 극복하는지를 측정한다.
2026년 02월 회고
부스트캠프도 끝나고 졸업도 했다. 이제는 취업 시장으로 뛰어들어, 온전히 나 혼자서 해나가야 하는 도전이 시작되었다. 조급한 마음에 이것저것 정신없이 보내기도 했지만, 다시 나만의 속도를 되찾아 차분히 앞으로 나아가보고자 한다.
로컬 LLM과 n8n으로 구축하는 에러 분석 자동화
로컬 AI와 n8n 워크플로우 엔진을 결합해, 에러가 발생하는 즉시 원인을 분석하고 해결 방안을 제시하는 자동화 파이프라인을 구축했다. 이를 통해 에러 발생 후 최대 25초 이내에 체계적인 노션 리포트가 생성되며, 개발자는 반복적인 디버깅 작업에 소모되는 시간을 줄이고 보다 본질적인 문제 해결에 집중할 수 있는 환경을 마련했다.
[네이버부스트캠프 웹・모바일 10기] 전체 과정 후기
네이버 부스트캠프 정규 과정을 마치며, 8개월 동안 달려온 시간을 돌아보자. 처음엔 무엇을 위해 지원하게 되었고, 지금까지 내가 얻은 것들을 찬찬히 짚어보자.
[네이버부스트캠프 웹・모바일 10기] 멤버십 22주차 회고
최종 발표를 Plum 라이브 데모로 성공적으로 마쳤고, 안정성과 요약 기능에 대한 긍정적인 피드백을 받았다. 리팩토링과 테스트 코드 설계에 대한 아쉬움을 남기며 그룹 프로젝트를 마무리했고, 팀원들과 Plum을 계속 개선해 나가기로 했다. 22주간의 부스트캠프가 끝났지만, 쌓아온 기록을 바탕으로 스스로 방향을 만들어 갈 것이다.
실시간 통신 로직을 계층으로 정리하기
기능이 늘어날수록 비슷한 로직이 여러 곳에 흩어지고, 무언가를 고칠 때 어디서부터 시작해야 할지 가늠하기 어려워졌다. 실시간 통신 로직을 어떻게 계층으로 나누고, 처음 보는 사람도 따라갈 수 있는 구조로 만들 수 있는지 고민하게 되었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 21주차 회고
마지막까지 딱 한 주 남았다. 테스트와 개선을 반복하면서 서비스의 완성도를 조금씩 끌어올리고 있다. 체력도, 자신감도 많이 떨어진 한 주였지만 그래도 끝까지 최선을 다해 보려 한다. 남은 기간 동안 어떤 점들을 더 개선할 수 있을지 고민해보자.
[네이버부스트캠프 웹・모바일 10기] 멤버십 20주차 회고
데모와 테스트를 통해 배포 환경에서 실제 동작을 확인해보았다. 그 과정에서 마주한 문제들과 그때 했던 고민들을 정리하며 한 주를 마무리하고자 한다. 겉보기에는 단순해 보이는 기능도, 막상 실제로 부딪쳐보면 결코 가볍게 지나칠 수 없는 지점들이 많다는 것을 다시 한 번 느꼈다.
카메라 및 마이크 On/Off UX 개선
카메라와 마이크를 끄는 기능을 구현하면서 하드웨어 제어 방식에 따라 사용자 경험이 크게 달라진다는 것을 발견했다. 하나의 방식으로 두 미디어를 처리하려 했지만, 카메라는 LED 소등이라는 시각적 신뢰성이 중요하고 마이크는 즉각적인 반응성이 중요하다는 것을 두 번의 시행착오를 통해 깨달았다. 미디어 타입별로 다른 전략을 적용해 두 문제를 동시에 해결할 수 있었다.
비디오 Consumer 수 상수화로 서버 부하 최적화
mediasoup 기반 화상 강의 서비스에서 모든 참여자의 비디오를 동시 수신하는 구조가 N×(N-1)로 Consumer를 폭증시킨다는 것을 모니터링으로 발견했다. 요청 시점 수신과 ±1 프리패치를 비교 검토한 끝에, 100명 기준 Consumer 수를 9,900개에서 210개로 줄이면서 페이지 전환 지연도 함께 해결했다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 19주차 회고
남은 기간이 짧아 시간을 효율적으로 활용해야 한다. 변화가 필요했고 명확한 목표점이 필요했다. 오픈 스테이지를 목표점으로 설정하여 다시 한번 불태워보고자 한다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 18주차 회고
만족스러운 개발 주간을 보낸 후, 다음 주는 한 걸음 더 나아가기 위해 어떤 부분을 개선할지 고민하게 되었다. 부족했던 점들을 어떻게 채워나갈지 구체적으로 생각해보았다.
나는 왜 회고를 작성하는가
매주 회고를 작성하게 된 배경과 생각에 대한 질문을 받았고, 이를 계기로 스스로를 돌아보게 되었다. 회고를 작성하게 된 계기부터 어떤 마음으로 작성하고 있는지, 그리고 회고가 나에게 어떤 의미인지를 생각해보았다.
2025년을 마무리하며
2025년의 추억을 정리하며
Notion API 블로그 성능 최적화
Notion API 기반으로 블로그를 제작하는 과정에서 API 중복 호출, 순차적 Table 블록 처리, 비효율적 관련 글 추천 등으로 성능 저하가 발생했다. 이를 계기로 API 최적화, 에러 처리, 폰트 최적화 등 개선 작업을 진행하게 되었다.
Notion API 초기 페이지 로딩 속도 개선
노션 API로 블로그를 구현하던 중, 페이지네이션과 총 게시글 수 계산을 위해 매번 전체 데이터를 불러오는 비효율적인 구조를 발견했다. 이를 개선하기 위해 메타데이터베이스 분리와 카테고리별 데이터베이스 설계 등 여러 최적화 방안을 시도했다.
WebSocket부터 이해하자
웹소켓 복구 전략을 알아보기 전, 먼저 웹소켓의 개념과 동작 원리부터 살펴보았다. 단순히 코드 수준의 복구 로직을 다루기보다는, 웹소켓이 기존 통신 방식과 어떻게 다른지부터 이해하고자 했다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 17주차 회고
기획의 모호함을 해소하기 위해 팀원들과 함께 기획서를 작성하며 방향성을 맞추었다. 이후 프로토타입을 진행하며 가설을 검증하고, 앞으로의 방향성에 대한 확신을 얻었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 16주차 회고
그룹 프로젝트의 1주차로, 팀원들과 함께 목표를 설정하고 기획을 진행했다. 세상에는 잘하는 사람도, 열심히 하는 사람도 많다. 그런 이들에게 매번 자극을 받으며 동기부여를 얻고 있다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 15주차 회고
5주간 진행된 그룹 스프린트의 여정이 드디어 끝났다. 첫 그룹 프로젝트를 돌아보며, 그 안에서 배우고 성장한 순간들을 다시금 되돌아보게 되었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 14주차 회고
팀 프로젝트를 진행하며 더 나은 코드를 작성하기 위해 노력했다. 리팩토링의 정의를 다시 생각하고, 올바른 방향으로 수행하고 있는지를 점검하는 계기가 되었다.
쉘 내부 명령어와 외부 명령어
쉘에서 명령어를 처리할 때 외부 파일 명령어와 내장 명령어의 차이가 존재한다는 것을 알게되었고 조금 더 깊게 알아보았다.
터미널 명령어 실행 과정
OS와 유사한 시스템을 구현하기 위하여 실제 OS의 동작 방식을 학습하며 적용해보고자 했다.
로그인 및 사용자 세션 시작 과정
컴퓨터 부팅 후 사용자가 로그인한 뒤, 어떤 과정이 이루어지는지 고민하며 정리하게 되었다.
컴퓨터 부팅 이후 프로세스 실행 과정
컴퓨터 부팅 과정에서 사용자가 시스템을 실제로 사용할 수 있게 될 때까지의 과정을 궁금하여 찾아보게 되었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 13주차 회고
그룹 스프린트의 마지막 구현 주차로, 새롭게 배운 협업 도구들의 활용 방법을 기록했다. 또한 리더십에 대해 다시 한 번 생각해보며, 앞으로 어떻게 나아가야 할지 고민하는 계기가 되었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 12주차 회고
브랜치 전략을 개선하고 태스크를 구체화하여 협업 효율을 높였다. 점진적으로 백엔드를 설계하며 발전시켜 나가는 과정에서 아쉬운 점도 많았고, 그러한 문제들이 왜 발생했는지 되돌아보게 되었다.
컴퓨터 부팅 과정
사용자가 컴퓨터의 전원을 켜면, 시스템이 어떤 과정을 거쳐 시작되는지 차근차근 정리해 보았다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 11주차 회고
팀 전체의 협업을 목표로 프론트엔드와 백엔드 구분 없이 전반적인 작업에 참여했다. 회의를 주도적으로 이끌며 마주한 문제들을 되돌아보고, 앞으로 어떻게 개선해 나가야 할지 고민하게 되었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 10주차 회고
10주간의 학습 스프린트가 마무리되었다. 지금까지의 과정을 돌아보며, 초반에 세웠던 목표를 얼마나 이루었는지, 그리고 초심을 잃지 않았는지를 점검하게 되었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 9주차 회고
백엔드 학습 과정에서 방향에 대한 고민이 생겨 다른 캠퍼들에게 조언을 구하며 새로운 시각을 얻었다. 리액트 기본 훅을 활용해 상태 관리 방식의 차이를 실험하고 그 효과를 확인하였다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 8주차 회고
리액트 컴포넌트 분리 기준에 대해 조언을 구하고, 실제 현업에서는 이를 어떻게 적용하는지도 물어보았다. AWS 배포 과정을 직접 경험하며, 그동안 느꼈던 AWS에 대한 두려움을 조금씩 극복할 수 있었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 7주차 회고
말하기 능력의 부족함을 느끼고 이를 보완해야 함을 인식했다. 프론트엔드 관점을 넘어 웹 개발 전반에서 쿠키와 세션의 흐름을 학습하며, 풀스택 개발의 강점을 체감할 수 있었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 6주차 회고
일관된 에러 처리 방식에 대해 고민하며, 이를 정리하고 정립하는 시간을 가졌다. 아직 부족한 점은 많지만, 일관성을 확보함으로써 보다 체계적으로 에러를 처리할 수 있었다.
Node.js WAS에서 일관된 에러 처리 구조 적용하기
WAS 게시글 조회 시 return null로 인해 에러 처리가 복잡해지는 문제를 경험하고, BaseError 상속 구조와 계층별 책임 분리를 적용하여 일관된 에러 처리 시스템을 구축하였다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 5주차 회고
오프라인에 참석해 다양한 캠퍼들과 소통하는 시간을 가졌다. AI의 도움 없이 직접 설계에 도전하며 만족감을 느꼈지만, 여러 부족한 점들을 지적받으며 이에 대한 추가 학습의 필요성을 깨달았다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 4주차 회고
피어 리뷰를 통해서 계층 역할, 트랜잭션, DTO 등에 대해 질문하며 조금씩 이해를 할 수 있었다. 아직 부족한 점이 많다고 느껴 다른 캠퍼들의 코드를 많이 살펴보려 한다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 3주차 회고
바닐라 자바스크립트에 아직 미숙하다고 느꼈다. SPA를 구현하는 과정에서 고민되는 부분이 많았고 이에 대한 학습을 진행하면서 조금씩 자바스크립트에 익숙해지고 있다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 2주차 회고
디버깅에 집중하며 조금씩 이해를 높여가고자 했다. 매번 console.log 만을 사용하는 모습을 개선하고자 더 집중해서 학습하였다.
OCR과 Open AI의 응답 속도 개선
계약서 OCR과 OpenAI 기능에서 약 2분이 걸리던 로딩 시간을 페이지 분할, 병렬 처리, 즉시 렌더링을 통해 18초까지 단축하며, 비동기 처리 설계 방식에 대해 고민하게 되었다.
[멋쟁이사자처럼 대학] 중앙 해커톤 회고
멋쟁이사자처럼에서 참여한 두 번째 해커톤이다. 프로젝트를 진행하며 다양한 시도를 통해 많은 것을 느꼈고, 운영진으로서 다른 아기사자들과 함께하며 또 다른 관점에서 많은 것을 배울 수 있었다.
[네이버부스트캠프 웹・모바일 10기] 멤버십 1주차 회고
부스트캠프 멤버십에 합격하며 기뻤지만, 학습 방법에 대한 고민은 여전히 남아 있었다. 그룹 피드백을 통해 스스로의 부족한 부분을 인식하는 계기가 되었다.
[네이버부스트캠프 웹・모바일 10기] 챌린지 수료 후기
4주라는 챌린지 기간이 지났고 많이 성장할 수 있었다. 단순히 구현에 집중하는 것이 아닌 학습하고 설계하는 과정을 익힐 수 있었고, AI에 대해서 돌아볼 수 있는 시간이었다.
[네이버부스트캠프 웹・모바일 10기] 챌린지 1~3주차 회고
다른 캠퍼의 추천으로 회고를 작성해보았다. 변하고 싶은 마음은 굴뚝같으나, 잘 하고있는지 모르겠고 벌써 챌린지 기간이 끝나간다. 마지막까지 열정적으로 참여하자.
동적 폰트 로딩 전략
손글씨 커스텀 폰트 미리보기 기능을 개발하는 과정에서, 동적 폰트를 불러오는 데 시간이 꽤 소요된다는 점을 확인했다. 이를 개선하기 위해 WOFF2, 캐싱, TanStack Query, 스켈레톤 UI를 조합하여 최적화를 진행하고자 하였다.