dev.daisy

이번에 기술 선택 이유를 고민해보면서 TypeScript와 버전 선택이 서비스 안정성과 유지보수에 미치는 영향을 생각해보게 되었습니다. 또 서비스 구조와 데이터 흐름을 미리 분석하며, 정적 타입 검사와 명확한 인터페이스 정의가 런타임 오류를 줄이고 개발 효율성을 높일 수 있다는 점을 확인헤 명확한 이유를 가지고 기술을 선택한 경험이 좋았습니다.무작정 개발 먼저 들어가거나 좋아하는 기술이라는 이유로 사용하기보다는, 설계 단계에서 타입 시스템과 프레임워크 환경을 충분히 검토하는 것이 대규모 서비스 개발의 안정성과 효율성을 결정짓는 요소가 될 것이라고 생각합니다.2. TypeScript 5.4.42-1. 선정 이유튜닝 서비스는 유저 기반 데이터와 인터랙션, 서버와의 비동기 통신 등 복잡한 데이터 상태와 흐름을..

팀 프로젝트를 시작하기 전에 설계 문서를 작성했는데, 단순히 기술을 나열하기거나 '사용해보고 싶은 기술'이라는 이유로 선택하기보다 여러 스택을 비교해보며 왜 이 구조가 서비스에 가장 적합한가를 끊임없이 고민했습니다. 기술은 결국 문제를 해결하기 위한 수단이라는 점을 다시 한 번 깨달았고, 앞으로도 모든 선택에 근거를 가지고 기술을 선택하는 개발자가 되고 싶다는 목표를 가지게 되었습니다.0. 서비스 소개개발하고 있는 서비스 튜닝은 조직 기반의 소셜 매칭 커뮤니티 플랫폼으로, 동일한 소속(학교, 회사, 부트캠프 등)을 기반으로 AI가 관심사가 비슷한 사람과 자연스럽고 신뢰할 수 있는 인연을 만들어주는 서비스입니다.동일한 소속을 바탕으로 신뢰를 기반으로 한 자연스러운 만남을 유도하며, 단순한 매칭을 넘어서 뉴..

Fiber가 중요한 작업 먼저 처리하고 나머지는 뒤로 미루는 전략을 사용하는 것을 보면서, 개발자는 UI 흐름에서 어떤 부분이 사용자에게 더 중요한지 판단하고 그 맥락을 코드 구조에 반영해야 한다는 점을 깨달았습니다.React의 최신 기능들(Concurrent Mode, Suspense, Server Components)은 모두 Fiber 엔진 위에서 작동하고 있기 때문에, Fiber 아키텍처를 중심으로 React 내부 구조를 계속 학습하는 것은 진화하는 React 생태계에서 꼭 알아야할 필수적인 개념이라고 생각합니다. 찾아볼수록 어렵다고 느껴져 끊임없이 공부하며 글을 개선해보겠습니다 :)React를 사용하는 대다수의 개발자는 JSX → Virtual DOM → Reconciliation → DOM 업데..

기본적인 메서드이지만 코딩테스트를 공부하다보면 각각의 함수명이 제대로 생각나지 않아 꼭 구글링해보기 마련인데, 이 기회에 제대로 정리해보게 되어 좋았습니다. 앞으로 Set, Map 함수를 더 효율적으로 사용해 시간복잡도의 장점을 살려서 문제를 풀어보려고 합니다.자바스크립트로 코딩테스트를 풀다 보면 꼭 마주하는 개념인데, 알고리즘에 집중하다 헷갈리는 경우가 많아 글로 정리해보려고 합니다.1. Set: 중복 없는 값들의 집합자바스크립트의 Set은 중복을 허용하지 않는 유일한 값들의 집합입니다. 배열과 비슷하지만 중복을 자동으로 제거해 준다는 점에서 차이가 있습니다. Set은 주로 고유한 값들을 저장하거나 배열에서 중복을 제거할 때 유용하게 사용됩니다.Set의 주요 메서드new Set(): 비어 있는 Set을..

문서로만 공부했던 테스트코드를 직접 작성해보며 안정성 향상, 리팩터링 안전성 보장, 개발 속도 단축이라는 성과를 직접 체감해보았습니다. 특히 테스트 코드를 작성함으로써 코드의 입력과 결과값을 명확하게 보여준다는 점에서 코드를 처음 보는 사람에게는 사용법을 문서화하는 효과가 있을 것 같다고 느꼈고, 앞으로는 E2E 테스트와 성능 테스트를 통해 개발 생산성과 코드 품질을 끊임없이 개선해 나갈 예정입니다.이번에는 Jest와 React Testing Library를 중심으로 한 견고한 테스트 환경을 구축했는데, Next.js, React Query, Zustand 등 최신 라이브러리들과의 통합 테스트를 진행하며 상호작용 하는 모습이 새롭게 다가왔습니다. 앞으로도 지속적인 테스트 커버리지 향상과 더 나은 도구 도..

BFS와 DFS의 개념을 정리하며 두 알고리즘의 본질적인 차이를 명확이 이해할 수 있어 좋았습니다. 알고리즘 공부를 하다 보면 정말 많이 나오는 유형인데 단순히 개념을 암기하는 것을 넘어서 큐와 스택이라는 자료구조가 어떻게 너비 우선 탐색, 깊이 우선 탐색이라는 상반된 방식을 만들어내는지 원리적으로 공부할 수 있어 좋았습니다.기존에는 BFS와 DFS 중에 선택해서 풀 수 있는 문제가 많아 큰 기준을 두지 않고 편한 알고리즘을 위주로 구현했었는데, BFS가 최단 경로를 보장하는 대신 메모리 사용량이 크고 DFS는 메모리 효율을 보장하는 대신 최단 경로가 아니라는 명확한 트레이드오프 관걔를 파악한 후 상황에 맞는 알고리즘을 선택하는 기준이 생겼습니다. 공부한 내용을 바탕으로 앞으로는 이를 응용한 더 복잡한 ..

이번 프로젝트를 통해 성능 최적화는 단순히 기술적인 작업이 아니라, 사용자 경험에 대한 깊은 이해에서 시작된다는 것을 깨달았습니다. SSR 최적화를 진행하면서 단순히 react-icons를 이모지로 바꾼 것처럼 사소해 보이는 결정이 전체 번들 크기를 수백 킬로바이트나 줄이는 결과를 만들어내는 등 작은 변화들이 큰 파급력을 가진다는 점에 놀랐습니다. 눈에 띄지 않는 부분까지 세심하게 관리하는 것의 중요성을 다시 한 번 느꼈습니다.가장 중요한 배움은 서버와 클라이언트 역할의 재정의였습니다. 최대한 SSR을 많이 적용하려다가 오히려 성능이 안좋아지는 시행착오를 많이 겪었는데요, 이후 모든 것을 서버에서 렌더링하려 하기보다, 각 컴포넌트의 특성에 맞춰 렌더링 방식을 분리하고 최적화하는 것이 훨씬 효과적이라는 것..

FCP와 LCP 같은 주요 로딩 지표를 개선하며 사용자 경험을 향상시켰습니다. 그러나 이 과정에서 TBT가 증가하고 전체 네트워크 페이로드 크기 또한 늘어나는 예상치 못한 문제에 직면하게 되었습니다.이러한 결과는 성능 최적화가 단순히 한두 가지 지표를 개선하는 데 그치지 않고, 전체적인 시스템의 균형을 고려해야 한다는 중요한 교훈을 주었습니다. 이미지 파일 크기를 줄였음에도 불구하고 TBT가 늘어난 것은 새로운 이미지 최적화 로직이나 컴포넌트 로직이 메인 스레드에 추가적인 부담을 주었을 가능성이 있고, 최적화 후 네트워크 페이로드 크기가 오히려 60KiB가량 증가한 것은 자바스크립트 번들 등 이미지 외의 다른 리소스가 더 커졌을 수 있음을 의미합니다. 앞으로는 아래에서 말씀드릴 목표를 실천하며 단기적인 ..

이번 최적화 작업은 단순히 '잘 작동하는 코드'를 넘어, 사용자 경험을 최우선으로 고려하는 개발의 중요성을 깊이 깨닫는 계기가 되었습니다. 처음에는 막연하게 번들 크기를 줄여야 한다는 목표만 있었지만, 막상 Lighthouse를 돌려 성능 지표를 눈으로 확인하고, 어떤 지점에서 병목이 발생하는지 직접 파악하는 과정이 개발자로서 한 단계 성장하는 시간이였다고 생각합니다.특히, Lazy Loading 전략을 적용하며 'Above-the-fold'와 'Below-the-fold' 콘텐츠를 구분한 것이 가장 인상 깊었습니다. 사용자가 페이지에 진입하자마자 핵심 콘텐츠를 빠르게 보여주고, 스크롤을 내릴 때 비로소 다음 콘텐츠를 로드하는 방식이 단순한 기술 적용을 넘어 사용자에게 기다림을 최소화하는 배려라는 것을 ..

처음에는 단순히 값을 저장하는 용도로만 생각했지만, useState가 선언적(Declarative) UI 업데이트를 위한 도구라면, useRef는 명령형(Imperative) 작업을 위한 도구라는 것을 제대로 공부하게 되었습니다. useRef에 저장된 값은 컴포넌트가 수십 번 리렌더링되어도 초기화되지 않고 유지되지만, 값이 변경되어도 useState처럼 불필요한 리렌더링을 유발하지 않는 덕분에 타이머 ID, API 응답 캐싱, 또는 이전 상태(Previous State) 값을 추적하는 등 UI와 무관하게 데이터의 지속성이 필요한 경우에 useRef가 성능 최적화의 핵심적인 방법이 된다는 것을 배웠습니다. 덕분에 useRef가 React의 선언적 모델을 보완하고 클린 코드를 작성하는 데 필수적인 Hook임..