2025년 초 입사 당시 뤼이도에는 디자인 시스템이 없었습니다. 도메인마다 UI를 복사해서 사용했고, global.css에는 어디에서, 어떤 목적으로 사용하는지 파악하기 어려운 class가 쌓여 있었습니다. 간단한 UI 하나를 구현하려고 해도, 먼저 비슷한 코드를 찾고 공통으로 쓸 수 있는 컴포넌트가 있는지, 왜 이런 스타일이 적용돼 있는지 그동안의 히스토리를 확인해야 했습니다. 기능 구현보다 파일을

빠르게 만드는 것. 지난 3년 동안 Riido 프론트엔드 팀이 가장 자신 있어 하던 일이었습니다. 기획이 나오면 누구보다 먼저 화면을 띄웠고, 필요한 기능은 그때그때 붙여 나갔습니다. AI가 코드를 쓰기 시작하면서 이 장점이 흐려졌습니다. 빨리 만드는 일은 이제 누구나 할 수 있게 됐고, 오히려 빠르게 쌓아 온 코드가 저희 발목을 잡고 있었습니다.

이번 아티클에서는 뤼이도팀에 도입하여 성공적으로 활용 중인 프론트엔드 상태 관리 전략에 대해 공유해 드리려고 합니다. 프론트엔드 개발에서 상태 관리는 항상 중요한 과제인데요, 저희는 서버 데이터의 중복 관리와 불필요한 보일러플레이트 코드, 데이터 일관성 유지 문제를 서버 상태와 클라이언트 상태를 명확히 구분하는 접근법을 통해 해결할 수 있었습니다. 1. 상태 관리의 두 가지

Riido는 사용자가 보다 직관적으로 프로젝트를 관리할 수 있게끔 여러 영역에서 계층 구조를 활용하고 있습니다. 프로젝트-목표-작업으로 이루어진 3계층 작업 관리, 백로그섹션-백로그와 같은 구조로 계층이 구현되어 있습니다. 이러한 계층 구조는 사용자가 프로젝트를 논리적으로 구성하고 관리하는 데 큰 도움이 되지만, 프론트엔드 성능 측면에서 상당한 도전과제가 되었습니다. 초기에 Riido는 백로그 데이터를

LLM 기반의 서비스를 개발할 때 가장 중요한 것은 모델을 서비스의 목적에 맞게 적용하는 것입니다. 일관된 형식의 응답 데이터가 필요할 수도 있고, 사용자에게 응답을 실시간으로 보여주어야 할 수도 있죠. 이러한 기능은 대부분의 LLM 모델이 제공하는 구조화된 출력과 응답 스트리밍을 활용해 간단히 적용 가능합니다. 하지만 둘 다 필요한 경우는 어떨까요? 이번 아티클에서는

안녕하세요. 이번 글에서는 Riido가 기존 다크모드의 서비스에 라이트모드를 추가하는 경험을 개발팀의 입장에서 공유하고자 합니다. Riido에 라이트모드를 도입하게 된 배경 Riido는 출시 당시 다크모드만을 지원하는 서비스로 시작했습니다. 하지만 서비스가 성장하면서 다크모드를 자주 사용하는 개발자 뿐만 아니라, 디자이너와 같이 라이트모드를 선호하는 직군의 사용 비율이 점차 높아지며, 다양한 피드백을 받게 되었습니다. 💡“어두운 배경만