COCOMU

우리 팀은 코코무 프로젝트를 함께하며 작지만 반복되는 불편함들을 자주 마주했습니다. 매번 같은 내용을 공지해야 하는 번거로움, 콘솔 에러를 검색하느라 흐름이 끊기는 순간들처럼 사소하지만 쌓이면 꽤나 피로한 문제들이었죠. 프로젝트가 잠시 숨 고르기에 들어간 지금, 그동안 미뤄뒀던 아이디어들을 실현해보기로 했습니다. 이번 글에서는 우리가 어떤 문제를 겪었고, 이를 어떻게 해결했는지에 대한 개발 과정을 소개해보려 합니다. 디스코드 알림 봇 – 격일 스크럼 알림, 이젠 자동으로MVP 개발 이후 팀원들도 각자 다른 작업을 병행하게 되면서 우리 팀의 협업 방식에 조금 변화가 생겼습니다. 매일 오전 10시부터 오후 5시까지 러쉬아워에 함께 집중하던 방식에서 벗어나 이제는 격일로 스크럼을 통해 각자의 진행 상황과 다음..

MVP 개발 당시, 저희 팀은 컴포넌트를 구현할 때 임시 페이지를 하나 비워두고 해당 컴포넌트를 렌더링한 화면을 보며 작업했습니다.또한 각 기능이 잘 동작하는지 확인하려면, props를 직접 수정해가며 상태를 하나씩 확인해야 했습니다. 하지만 이런 과정을 매번 반복하는 건 매우 번거로웠고, 자연스럽게 이런 생각이 들었습니다.“컴포넌트를 따로 떼서 테스트하고 문서화할 수 있으면 좋지 않을까?”“다른 팀원에게 보여줄 때도, 상태별로 정리된 화면이 있으면 편할 텐데…” 그러다 다시 떠오른 도구, Storybook사실 Storybook은 전부터 알고 있던 도구였습니다. 하지만 당시에는 MVP 개발 제한 기간이 짧았고, 기능 구현 속도가 최우선이었죠. 저희는 프로젝트의 요구사항과 우선순위에 따라 테스트 코드는 작..

왜 코드 스플리팅이 필요했을까?cocomu는 React 기반의 SPA(Single Page Application)로 개발되었습니다.SPA는 페이지 전환 시 새로고침 없이 콘텐츠를 렌더링할 수 있다는 장점이 있지만, 그만큼 초기 진입 시점에 필요한 모든 JavaScript 파일을 한 번에 불러오는 구조적인 특성을 가지고 있습니다. 이 구조는 프로젝트가 작을 땐 문제가 되지 않지만, 페이지 수가 많아지고 컴포넌트가 복잡해질수록 초기 번들 크기가 비대해지며, 첫 화면 렌더링 속도에 직접적인 영향을 주기 시작합니다.특히 모든 페이지와 컴포넌트를 import로 정적으로 불러오는 경우, 사용자가 방문하지도 않은 페이지의 코드까지 함께 로드되기 때문에, 초기 로딩 시간이 길어지고 사용자 경험이 저하되는 문제가 발생했..

Atomic Design을 도입하기 전, 우리가 겪었던 문제들cocomu 프로젝트 이전, 저희 팀은 작은 규모의 프로젝트를 진행하면서 컴포넌트 설계에 대한 기준 부족으로 인해 여러 가지 문제를 겪었습니다. 디자인 시스템이나 명확한 UI 설계 기준도 없이, 개발자마다 개인적인 기준에 따라 컴포넌트를 나누고 작성하는 방식으로 진행되었습니다.1. 명확한 컴포넌트 설계 기준의 부재컴포넌트를 어떻게 나눌 것인지에 대한 팀 내 공통된 기준이 없었습니다.각자가 생각하는 ‘재사용 가능한 단위’, ‘하나의 책임’, ‘역할에 따른 분리’ 등의 해석이 모두 달랐기 때문에 다음과 같은 문제가 반복적으로 발생했습니다:관심사가 여러 개 섞여 있는 복잡한 컴포넌트유연하지 않은 컴포넌트 구조로 인해 재사용이 어려움상황에 따라 구현 ..

왜 웹폰트 최적화를 해야 했을까?SPA(Single Page Application)는 새로고침 없이 자바스크립트로 콘텐츠를 동적으로 로드하는 구조이기 때문에, 초기 진입 시점에 많은 리소스를 한 번에 불러오는 경향이 있습니다. 이는 초기 로딩 속도에 병목이 생기기 쉬운 구조입니다. 특히 웹폰트는 사용자에게는 보이지 않지만, 렌더링 지연의 주요 원인 중 하나입니다. 웹폰트가 늦게 로드되면 텍스트가 기본 폰트로 먼저 렌더링됐다가 나중에 바뀌는 FOUT(Flash of Unstyled Text) 현상이 발생하거나, 텍스트 자체가 아예 보이지 않다가 늦게 표시되는 FOIT(Flash of Invisible Text) 현상으로 이어질 수 있습니다.이러한 현상은 사용자에게 페이지가 느리게 뜨거나 덜 완성된 느낌을 ..

프로젝트를 시작할 때, 팀 내에서 가장 뜨거운 논쟁 중 하나는 "스타일링은 무엇으로 할 것인가?"였습니다. 선택지는 Styled-components, Emotion, 그리고 Tailwind CSS 세가지 였습니다 실제로 프로젝트 초기 기술 스택을 결정할 때, 사진에서 보이는 것처럼 디스코드 채널을 통해 가장 많은 비교가 이루어졌습니다. 그렇기에, 다시 한 번 각 기술의 장단점을 정리해보고, 저희가 어떤 고민과 과정을 거쳐 최종적으로 Emotion을 선택하게 되었는지를 공유해보고자 합니다.  각 기술의 장단점 비교해보기Styled-components장점컴포넌트 단위로 스타일을 정의할 수 있어, React와의 결합도가 높고 코드 구조가 직관적입니다.CSS-in-JS 방식이라 JavaScript 변수, 로직과..

웹 개발을 하다 보면 언제나 등장하는 두 갈래 길이 있습니다. 바로 API 요청을 처리하기 위한 Axios와 Fetch 중 하나를 선택하는 문제입니다. 둘 다 훌륭한 도구지만, “어떤 상황에서 무엇을 선택해야 하는가?”는 언제나 개발자들을 고민에 빠뜨리는 주제라고 생각합니다. 이번 글에서는 우리가 프로젝트에서 Axios를 선택하게 된 이유, 그 과정에서 겪은 기술적 고민과 결정을 정리해보려 합니다! Axios와 Fetch, 같은 목적 다른 방식Axios와 Fetch는 둘 다 HTTP 요청을 보내기 위한 도구라는 공통점이 있지만, 사용하는 방식과 제공하는 기능은 꽤 다릅니다. Fetch는 브라우저에 기본 내장되어 있는 API로, 별도의 설치 없이 사용할 수 있으며, Promise 기반으로 작동합니다. 가볍..

우리 팀은 이전에 Redux Toolkit을 사용한 프로젝트를 진행하면서 상태 관리에 대한 다양한 경험을 했습니다.  당시 프로젝트에서 Redux Toolkit은 전역 상태 관리에 강력한 기능을 제공했지만, 실제로 활용하는 과정에서 몇 가지 문제점이 나타났습니다. Redux Toolkit의 문제점1. Store가 크고 복잡해짐프로젝트 규모가 커질수록 Redux의 store 구조도 함께 비대해졌습니다. 상태와 데이터가 여러 slice로 분산되고 각 로직이 복잡하게 얽히면서, 전체 흐름을 파악하거나 디버깅하는 데 시간이 많이 소요되는 문제가 발생했습니다. 2. 상태 관리와 API 호출 코드가 지나치게 혼재됨Redux Toolkit에서는 상태 관리를 위한 slice 정의와 API 요청을 위한 비동기 로직(cr..