게시글
테스트케이스를 기획 리뷰 시점에 먼저 뽑기로 했다
구현을 끝낸 뒤 테스트케이스를 적다 보니 기획서에 답이 없는 경우가 나와, 기획 확인부터 다시 하는 일이 세 번 반복됐다. 다음 작업에서는 기획서를 받은 날 케이스부터 뽑았고, 빈틈 14건을 구현 전에 기획 리뷰에서 메웠다. 테스트케이스는 코드보다 기획서를 먼저 검증하는 문서로도 쓸 수 있었다.
AI에게 구현을 맡기며 설계를 한 번에 끝내지 않기로 했다
설계만 완벽하면 AI가 한 번의 구현으로 원하는 결과물을 뽑아낼 거라 믿었다. 하지만 아무리 공들여도 코드로 옮기는 순간 어긋나는 지점이 생겼고, 어떤 정보는 구현해 봐야만 알 수 있었다. 지금은 전체 흐름만 먼저 정하고 세부 설계는 기능 하나를 시작할 때마다 이어 가고자 한다.
React Query / SWR / Apollo는 재요청 중 이전 데이터를 어떻게 다룰까
React Query, SWR, Apollo는 조회 조건이 바뀔 때 비는 화면을 비슷한 옵션으로 메운다. 이전 값을 자동으로 병합할지와 이전 데이터라고 알려 줄지는 서로 다르고, Apollo는 값만 넘겨줘서 같은 자원을 다시 조회하는지부터 직접 구분해야 한다.
previousData로 variables 바뀔 때 이전 데이터 유지하기
Apollo Client에서 variables가 바뀌면 useQuery의 data만 비고, previousData가 그 공백을 메운다. 캐시에 값이 남아 있어도 data는 undefined가 됐고, 프로젝트의 커스텀 훅은 useQuery를 감싸 같은 일을 하고 있었다.
nginx와 애플리케이션 코드의 리버스 프록시 구분하기
nginx와 애플리케이션 코드의 reverse proxy는 이름이 같아도 실행되는 프로세스와 네트워크 경계가 다르다. Node.js 코드의 reverse proxy를 보고 서버 세 대가 통신한다고 잘못 그렸고, 요청이 프로세스 경계를 몇 번 넘는지부터 세어야 했다.
Apollo Client의 fetchPolicy 기본값이 cache-first인 이유
Apollo Client의 fetchPolicy 옵션 중, 최신값까지 확인하는 cache-and-network가 가장 좋은 선택이라 생각했다. 하지만, 라이브러리의 기본값은 캐시에 값이 있으면 네트워크조차 안 쓰는 cache-first였다. 왜 라이브러리는 이쪽을 선택했을까?
getServerSideProps는 페이지 요청마다 다시 실행된다
getServerSideProps는 최초 접속 때만 실행되고 그 뒤로는 클라이언트가 화면을 채운다고 생각했다. 하지만 next/link로 이동할 때도 /_next/data 요청이 새로 떴다. 이 함수는 요청에 묶여 있어서 요청이 서버에 닿을 때마다 다시 실행된다.
AI 시대에서 개발자가 시간을 써야 할 곳은 어디일까?
개발자가 시간을 써야 할 곳은 코드가 작성되기 전에 질문을 던지는 순간이다. AI로 토이 프로젝트를 하다가 필터 하나를 검토 없이 승인했더니 상태 관리 구조를 통째로 다시 설계해야 했다. 결정이 늦어질수록 그 위에 얹힌 코드까지 함께 고쳐야 해서 되돌리는 비용이 커진다.
안쓰는 코드인 줄 알면서도 계속 검증했던 이유
아무 데서도 참조되지 않는 쿼리 필드를 지우려는데, 커밋 기록과 슬랙까지 뒤져도 배포 전까지는 확신이 서지 않았다. 스키마에 노출된 필드는 외부에서 쓰고 있어도 우리 저장소에는 흔적이 남지 않기 때문이다. 이 불안은 왜 생기고, 어떻게 하면 확신을 갖고 지울 수 있을까?
반복을 줄이는 것보다 역할을 드러내는 코드
컴포넌트를 나눌지는 이름과 시그니처만으로 무엇을 그리는지 설명되는지로 정한다. 클론 코딩 리뷰 질문에 답하다 보니 Card에 옵셔널 prop이 쌓여 이름만으로 역할을 설명하기 어려워졌다. 코드가 조금 중복되더라도 역할이 드러나면 그 중복은 코드 안에 남긴 이정표다.
useEffect 콜백에 이름을 붙인다면
한 번만 쓰이는 useEffect 콜백에 이름이 왜 필요한지 처음엔 와닿지 않았다. 리뷰 피드백대로 붙여 보니 effect가 여러 개인 컴포넌트에서는 이름이 목차 역할을 했고 스택 트레이스에도 남았다. 본문을 열어봐야만 역할을 알 수 있다면 이름을 붙일 가치가 있다.
첫 회사의 입사를 앞두고
완벽하게 준비를 마친 뒤에야 새로운 환경에 들어갈 수 있다고 믿었다. 하지만 준비가 다 됐다고 느낀 적이 없는데도 처음 지원한 면접에서 합격했다. 준비가 끝나기를 기다리는 일은 새로운 경험을 늦추는 선택이기도 해서, 부족함을 인정한 채 시행착오로 배우려 한다.
2026년 03월 회고
방향 없는 노력은 피로만 남긴다. 첫 공채 시즌에 매일 무언가를 했지만 직무만 맞으면 지원서를 넣고 새 개념을 쌓기 바빠 어디로 달리는지 흐려졌다. 다음 달에는 무엇을 먼저 할지와 왜 하는지를 정한 뒤 움직이고, 배운 것은 내 경험과 연결해 붙잡아 두려 한다.
Socket.IO 10,000명 재연결 부하 테스트
재연결을 빠르게 하려고 Socket.IO jitter를 0.5에서 0.3으로 조였더니, 10,000명 테스트에서 재연결이 한순간에 몰려 TCP Backlog가 포화됐다. jitter를 0.5로 되돌리자 재연결 성공률이 64.5%에서 100%가 됐다. 빠른 재연결과 느슨한 재연결 중 어느 쪽이 맞는지는 이론이 아니라 재현 가능한 실험이 가려줬다.
2026년 02월 회고
남의 속도를 따라잡으려는 건 욕심이었고, 필요한 건 내 기본기였다. 부스트캠프 수료와 졸업이 한꺼번에 지나가고 혼자 하는 취업 준비가 시작되자 주변과 비교할수록 조급해졌다. 상반기에는 기본기를 다지며 이력서와 면접 준비를 반복하려 한다.
로컬 LLM과 n8n으로 구축하는 에러 분석 자동화
에러가 나면 n8n이 소스 코드와 스택 트레이스를 모으고 로컬 LLM이 원인과 수정 제안을 Notion에 남기는 파이프라인을 만들었다. 에러마다 5분 넘게 걸리던 초기 탐색이 20~25초로 줄었다. 코드를 밖으로 내보내지 않는 대가로 로컬 모델의 정확도는 아쉬웠지만, 자동화가 사람이 집중할 곳을 좁혀준다는 건 확인했다.
[네이버부스트캠프 웹･모바일 10기] 전체 과정 후기
AI가 짜준 코드를 내 실력이라 착각한 채로 부스트캠프에 들어갔다. 코드 한 줄을 설명하지 못해 막히는 순간이 쌓이면서, 키보드부터 잡던 습관은 종이에 흐름을 먼저 그리는 쪽으로, 감으로 꺼내던 의견은 근거를 갖춰 말하는 쪽으로 바뀌었다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 22주차 회고
기능은 다 돌아가는데 코드에 대한 확신은 오히려 줄어들던 한 주였다. 실제 강의 상황을 재현해 서비스를 두드리고 뭉쳐 있던 책임을 역할 단위로 나누면서 그 간극을 좁혔다. 22주의 부스트캠프가 끝났고, 남은 건 끝냈다는 감각보다 무엇을 기준으로 삼을지라는 질문이었다.
실시간 통신 로직을 계층으로 정리하기
내 머릿속에만 있는 맥락은 구조가 아니었다. 기능이 늘수록 mediasoup 로직이 여러 곳에 흩어져 하나를 고치면 어디까지 파급될지 가늠하기 어려웠다. 계층마다 이 정보를 정말 알아야 하는지 묻고 몰라도 되는 정보를 걷어내자 수정 범위가 계층 하나로 좁혀졌다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 21주차 회고
57명 앞에서 오픈 스테이지를 열었고, 서버는 버텼지만 화상 연결을 맡은 내 파트에서 허점이 연달아 드러났다. 피드백을 우선순위대로 쪼개 이틀 반 만에 다시 데모 시연에 올렸다. 체력도 자신감도 떨어졌지만 테스트하고 고치고 다시 테스트하는 사이클이 무엇을 바꾸는지는 분명히 확인했다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 20주차 회고
겉보기엔 단순한 기능도 실제 환경에 올리면 가볍게 넘길 수 없었다. 주요 기능을 마치고 팀 전체가 실제 서비스 흐름대로 테스트하며 흩어진 mediasoup 로직, 카메라를 끄는 방식, 로컬과 서버의 차이를 마주했다. 남은 2주는 동작하는 서비스를 먼저 내놓는 데 집중해야 할 것이다.
카메라 및 마이크 On/Off UX 개선
카메라와 마이크는 같은 끄기 동작이지만 사용자가 믿는 신호가 달라 전략도 달라야 했다. 한 방식으로 둘을 처리하니 카메라를 꺼도 LED가 켜져 있었고, 하드웨어를 끊으면 마이크 발언 앞부분이 잘렸다. 카메라는 track.stop()으로 끊고 마이크는 송출만 멈추게 했다.
비디오 Consumer 수 상수화로 서버 부하 최적화
±1 프리패치로 100명 기준 Consumer 수를 9,900개에서 210개로 줄였다. 그 전에는 모든 참여자의 비디오를 동시에 받는 구조라 Consumer가 N×(N-1)로 늘어나 20명만 넘어도 CPU가 급증했다. 대안을 비교할 때는 단점의 허용 범위를 먼저 정해야 했다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 19주차 회고
설계를 건너뛰고 구현부터 뛰어든 탓에 수정이 반복됐다. 기능 개발이 늦어져 대규모 테스트가 미뤄지고 팀에 피로감이 쌓인 주에, 오픈 스테이지 날짜를 못 박고 100명 테스트를 버틸 준비를 다시 세웠다. 다음 주부터는 화이트보드에 흐름을 옮긴 뒤 개발에 들어가고자 한다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 18주차 회고
목표가 할 일 목록으로 끝나면 다음 주로 이어질 피드백이 남지 않는다. 개발 첫 주 출발은 만족스러웠지만 목표를 목적과 스토리로 묶지 않았고, 안건 없는 회의가 길어졌다. 회의 전날 안건을 정리하고, 팀 안에서 내 목소리가 가진 무게를 방향을 제시하는 데 쓰기로 했다.
회고를 쓰는 이유를 다시 정의하게 만든 댓글 하나
회고를 쓰는 이유는 미화되기 전의 고민을 붙잡아 다음 걸음의 방향을 잡는 데 있다. 매주 회고를 쓰면서도 왜 쓰는지 답해 본 적이 없다는 걸 챌린지 5주차 회고에 달린 댓글 하나로 알아차렸다. 그 답을 찾는 동안 생긴 세 가지 규칙을 지금까지 지켜 왔고, 앞으로도 지킬 생각이다.
2025년을 마무리하며
완벽히 알지 못해도 아는 건 공유하고 모르는 건 질문하는 쪽이 혼자 끌어안는 것보다 훨씬 빨랐다는 걸 배운 한 해였다. 익숙한 자리를 하나씩 떠나보냈고, 부스트캠프에서 더 넓은 곳에 나가 보니 우물 안 개구리였다는 걸 알게 됐다. 붙잡아 줄 소속이 사라지는 게 불안하지만 나만의 속도로 나아가 보려 한다.
Notion API 블로그 성능 최적화
Notion API 호출을 67% 줄이고 Table 블록을 병렬로 처리해 목차가 본문과 동시에 뜨게 됐다. 적은 데이터로 빠르게 구현하느라 중복 호출과 순차 처리, 에러 처리 누락을 그대로 둔 게 원인이었다. 외부 API에 의존할수록 에러 처리는 미룰 일이 아니었다.
Notion API 초기 페이지 로딩 속도 개선
외부 API를 쓸 때는 원하는 형태로 데이터를 받을 수 있다고 가정할 수 없었다. 노션 API는 인덱스 조회도 카운트 쿼리도 없어서 페이지네이션과 전체 글 수를 위해 매번 전체 데이터를 불러왔다. 메타 데이터베이스 분리와 카테고리별 분리를 거쳐 결국 무한 스크롤로 바꿨다.
웹소켓 클라이언트 Socket.IO와 STOMP
구형 브라우저 지원은 Socket.IO나 SockJS가, 메시지 형식의 통일은 STOMP가 WebSocket 위에 얹어 메운다. 표준 API로 연결을 열고 메시지를 보내는 일은 몇 줄이면 끝나지만 이 둘은 거기서 풀리지 않는다. 둘 다 필요 없다면 표준 API로 충분하다.
WebSocket부터 이해하자
WebSocket이 HTTP와 다른 지점은 결국 핸드셰이크가 끝난 뒤에도 연결을 끊지 않고 유지한다는 것 하나로 좁혀진다. 덕분에 서버가 먼저 메시지를 보낼 수 있지만, 한쪽이 죽거나 네트워크가 끊기면 그 연결을 다시 살리는 일은 온전히 애플리케이션의 몫이 된다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 17주차 회고
같은 방향을 보는 데 들인 하루가 설계와 검증을 오히려 빠르게 했다. 그룹 프로젝트 2주 차, 팀원마다 다른 그림을 보고 있다는 걱정에 모두가 함께 기획서를 다시 썼고 대면 설계와 프로토타입 검증으로 확신을 얻었다. 방향이 흐려지면 망설이지 않고 멈춰서 다시 맞추려 한다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 16주차 회고
팀 목표에 개인의 의견이 묻히지 않도록 각자의 목표를 먼저 모아 녹였다. 마지막 그룹 프로젝트 첫 주, 아이디어를 걸러내는 대신 이어 붙이며 모두가 공감하고 확장 가능성도 큰 주제로 수렴했다. 배제하지 않고 함께 방향을 찾자 모두가 더 적극적으로 나섰고, 얼른 만들어 보고 싶어졌다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 15주차 회고
분위기가 좋은 것과 협업을 잘하는 것은 다르다는 고민에서 5주의 그룹 스프린트를 시작했다. 매주 목표를 세우고 회고하며 팀의 방식을 다듬는 사이 그 고민은 매주 반복하는 습관이 됐다. 문서화와 CS 학습, 리뷰에서 배운 것도 결국 같은 결론이었다. 성장은 함께 나눌 때 이뤄진다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 14주차 회고
2주 안에 해내기 벅찰 만큼 쌓인 작업은 MoSCoW로 우선순위를 좁혀 덜어냈다. 코드 수정뿐 아니라 PR 작성, 리뷰, 승인까지 드는 비용을 따져 자잘한 작업을 뺀 덕분에 브로드캐스팅을 제외한 모든 기능의 테스트를 마쳤다. 무엇을 할지보다 무엇을 뺄지가 더 중요했다.
터미널 명령어 실행 과정
fork와 exec이 나뉜 덕분에 자식 프로세스는 새 프로그램이 시작되기 전 짧은 틈에 파일 디스크립터를 바꿔치고 파이프를 연결할 수 있다. 토이 셸에서 리다이렉션 코드를 어디에 넣을지 찾다가 ls -l /home이 실행되는 과정을 시스템 콜 단위로 따라갔다.
컴퓨터 부팅 이후 프로세스 실행 과정
전원 버튼부터 로그인 화면까지는 여러 프로세스가 차례로 바통을 넘기는 과정이다. 커널이 하드웨어와 파일 시스템을 준비하면 PID 1번 init이 나머지 모든 프로세스를 깨운다. 알아서 뜨는 줄 알았던 로그인 화면도 결국 PID 1로 거슬러 올라간다.
쉘 내부 명령어와 외부 명령어
cd와 ls는 실행되는 경로부터 다르다. 서브셸 안에서 cd로 옮긴 디렉터리가 빠져나오면 원래대로 돌아오는 건, 서브셸도 fork로 만든 별도 프로세스라 그 안의 상태 변경이 함께 사라지기 때문이다. 쉘 자신의 상태를 바꿔야 하는 동작만 내부 명령어로 남는다.
로그인 쉘과 비로그인 쉘: 프롬프트가 뜨기까지 갈라지는 지점
로그인 쉘인지는 쉘을 실행할 때 넘긴 argv[0]가 하이픈으로 시작하느냐로 갈린다. 새 터미널마다 ~/.bash_profile이 다시 실행되는 줄 알았는데, 로그인 직후의 쉘만 전체 체인을 읽고 새 터미널은 ~/.bashrc만 읽었다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 13주차 회고
키워드만 떠오르고 개념끼리 이어지지 않는 건 챕터 단위로만 정리해 온 탓이었다. 그룹 스프린트 마지막 구현 주차, 얕게 찾아본 개념을 그대로 적용하니 구현이 실제 동작과 맞는지 확신하기 어려웠다. 리팩토링 기간에는 모듈 관계를 다이어그램으로 그려 하나의 지도로 연결하고자 한다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 12주차 회고
시간이 걸리더라도 모듈 간 관계를 먼저 설계했어야 했다. 백엔드는 사이클마다 필요한 부분만 설계하며 기능을 더해 갔는데, 새 기능이 붙을수록 의존성이 얽혀 끝내 순환 참조까지 생겼다. 피어세션에서 초기에 모듈 구조부터 잡고 순조롭게 구현하는 팀들을 보고서야 알았다.
컴퓨터 부팅 과정
전원 버튼을 누른다고 운영체제가 곧바로 켜지는 것은 아니다. 버튼이 깨우는 것은 ROM 속 BIOS이고, BIOS는 MBR의 부트로더에게, 부트로더는 커널에게 제어권을 넘긴다. 세부 동작보다 한 프로그램이 다음을 깨우고 물러나는 릴레이 구조를 봐야 한다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 11주차 회고
'다른 의견 없나요?'라는 질문만으로는 각자의 입장을 알 수 없었다. 한 팀원이 제안한 태스크 분류 기준에 반응이 없자 동의로 넘겼는데, 동의하지 않은 팀원이 있어 기준이 지켜지지 않고 작업이 멈췄다. 앞으로는 명확한 동의를 확인하고 합의한 기준은 문서로 남긴다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 10주차 회고
말에 힘이 부족하다는 걸 느껴 말하기 실력을 키우겠다는 목표를 2주차에 남겼다. 스크럼과 코드 쉐어마다 질문하고 오프라인에서는 하루 한 번 옆자리 캠퍼에게 질문하며 떨림을 줄였다. 말하기는 결국 꾸준한 연습에서 온다는 걸 느꼈고, 이전보다 의견을 나누고 질문하는 게 자연스러워졌다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 9주차 회고
모든 것을 커버하려다 보면 결국 아무것도 깊게 남지 않는다. 백엔드 요구사항이 전부 처음이라 막막하던 주, 고민을 털어놓은 캠퍼에게서 미션은 학습 키워드를 던져 주는 장치일 뿐이라는 조언을 들었다. 꼭 필요한 것을 확실히 이해하고 넘어가기로 했다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 8주차 회고
정답보다 팀 모두가 동의하고 이해할 수 있는 기준을 세우는 일이 먼저였다. 컴포넌트 파일이 급격히 늘자 한 곳에서만 쓰는 하위 컴포넌트를 같은 파일에 두는 방식이 맞는지 리뷰어에게 물었다. 팀원이 이해하기 편한지, 리렌더링을 막는지, 유지보수가 편한지라는 기준을 받았다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 7주차 회고
같은 문제를 프론트엔드와 백엔드 양쪽에서 따져볼 수 있는 게 풀스택의 강점이었다. '오늘 그만 보기' 팝업 값은 로컬스토리지면 충분하다고 여겼는데, 쿠키면 SSR에서 팝업 상태까지 그려 줄 수 있다. 읽기만 보면 쿠키가 유리했지만 쓰기 경로까지 따라가자 결론이 뒤집혔고, 이렇게 전체 흐름을 따라가는 연습을 이어가려 한다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 6주차 회고
문제의 근본 원인은 에러 처리 한 줄보다 꼬여 있던 코드 흐름이었다. 대충 처리해 둔 에러 탓에 오류가 나도 성공 응답이 돌아와 급브레이크를 밟았다. 커스텀 에러를 상속 구조로 세워 최하단에서 던지고 최상단에서 처리하게 바꿨고, 앞으로는 코드보다 흐름을 먼저 짚을 것이다.
Node.js WAS에서 일관된 에러 처리 구조 적용하기
계층마다 다르던 에러 처리를 BaseError 상속 구조로 모았다. 계기는 게시글 API가 응답은 정상인데 데이터만 비어 있던 장애였고, 원인은 에러를 return null로 삼킨 코드였다. 에러 처리는 뒤로 미뤄도 되는 일이라 여겼지만, 미룬 작업이 반영된 적은 한 번도 없었다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 5주차 회고
설계의 핵심은 각 역할을 얼마나 명확히 나누느냐에 있었다. AI가 짠 흐름에 휩쓸리는 기분이 들어 처음으로 AI 없이 구조를 설계했고 목요일까지는 만족스러웠다. 하지만 핸들러가 많아 흐름을 파악하기 어렵다는 피드백을 받고 보니 계층의 역할이 애매했다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 4주차 회고
역할과 기준이 분명한 코드는 다른 사람도 흐름을 한 번 파악하면 다음을 예측할 수 있었다. 한 페이지의 클라이언트, 서버, 데이터베이스를 끝까지 구축했지만, 리뷰에서 함수명을 질문받고서야 내 코드가 남에게는 읽기 어려울 수 있다는 걸 알았다. 잘 짠 캠퍼의 코드를 모듈 단위로 그려 보며 그 차이를 눈으로 확인했다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 3주차 회고
정답 하나보다 그때의 상황과 조건에서 가장 합리적인 선택지를 고르는 일이 중요했다. HTML을 DOM으로 만들지 문자열로 삽입할지 고민했고, 안전한 DOM 방식에서 시작했지만 기간 안에 끝내기 어려워 문자열로 바꿨다. 이번에는 구현을 멈추고 장단점을 비교한 뒤 정했다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 2주차 회고
복잡한 코드일수록 console.log를 찍는 것보다 브레이크포인트로 단계적으로 확인하는 편이 훨씬 빨랐다. 미션에 쫓겨 디버깅할 틈이 없었던 탓에 금요일 하루를 통째로 디버깅 연습에 썼고, 전체 코드 대신 간단한 예제를 만들어 멈추고 들여다보기를 반복했다.
OCR과 Open AI의 응답 속도 개선
계약서 OCR과 OpenAI 번역 페이지의 로딩 2분을 18초로 줄였다. 화면에 보이는 구역만 요청하고 페이지 단위로 쪼개 병렬로 실행하고 먼저 도착한 페이지부터 렌더링했다. 비동기 처리에서는 요청 수보다 처리 단위를 어디까지 쪼갤 수 있는지를 먼저 봐야 했다.
[멋쟁이사자처럼 대학] 중앙 해커톤 회고
작년과 달리 이번에는 파트장으로서 모두가 각자 역할에 집중할 수 있는 팀 분위기를 만드는 데 신경 썼다. 무사히 끝내긴 했지만, 기획 단계에서 두 목표를 동시에 세운 탓에 속도와 완성도가 함께 흔들렸다. 이제부터 차근차근 그 경험을 하나씩 되짚어보려 한다.
[네이버부스트캠프 웹･모바일 10기] 멤버십 1주차 회고
모르는 키워드를 그냥 지나치지 않고 한 단계 더 파고들기로 했다. 그룹 피드백에서 다른 캠퍼들은 헷갈린 개념과 해결 과정이 또렷했지만 나는 생각을 뭉뚱그린 채 핵심 키워드를 뽑아내지 못했다. 챌린지로 성장했다고 믿었던 만큼 우물 안 개구리로 돌아간 느낌이었다.
[네이버부스트캠프 웹･모바일 10기] 챌린지 수료 후기
AI가 대체할 수 없는 개발자가 되겠다며 지원했는데, 챌린지에서는 작동하는 코드부터 만드느라 개념을 겉핥기로 넘기고 있었다. 구현을 포기하고 학습에 매달리는 팀원을 보고서야 결과에만 매여 있었다는 걸 알았다. 그 뒤로는 끝까지 적어 둔 설계에서 구현을 시작했다.
[네이버부스트캠프 웹･모바일 10기] 챌린지 1~3주차 회고
회고를 쓰는 동안 끊임없이 되돌아보게 된다는 점에서 왜 쓰는지를 처음 느꼈다. 첫 주는 미션을 끝내는 데 급급했고, 둘째 주에 학습에 집중하는 그룹원을 보며 결과에만 쫓기고 있었다는 걸 알았다. 셋째 주부터 설계를 손으로 그리며 내 흐름을 찾아갔다.
동적 폰트 로딩 전략
폰트 적용 시점은 브라우저에 묶여 있어 서버 렌더링으로 깜빡임을 없앨 수는 없었다. 대신 WOFF2 변환과 두 겹의 캐싱, 스켈레톤 UI로 로딩을 줄이고 남은 순간은 가렸다. WOFF2 변환만으로 폰트 파일은 6.3MB에서 3.0MB로 줄었다.