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

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

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

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

기본 테마를 떠올리면 대부분 라이트모드가 먼저 생각날 거예요. 하지만 뤼이도(Riido)는 조금 다른 길을 걸었습니다. 우리는 다크모드를 먼저 출시하고, 이후에 라이트모드를 구현했어요. 일반적으로 UI를 디자인할 때는 라이트모드를 먼저 제작한 후 다크모드를 추가하는 방식이 많지만, 뤼이도는 반대로 접근했죠. 오늘은 라이트 / 다크모드 디자인 시 주의사항과 라이트모드 제작 과정에 대해 설명할게요. 다크모드