기존에는 주로 Java(Spring) 기반 프로젝트를 진행했으나, 새로운 언어와 프레임워크를 활용해 개발 역량을 확장하고 싶었습니다.

Kotlin은 Java와의 높은 호환성과 간결한 문법을 강점으로 하여, Java 경험을 기반으로 빠르게 학습하고 적용할 수 있었습니다.

React는 JSP, Thymeleaf 같은 서버사이드 렌더링(SSR)과 달리 클라이언트 사이드 렌더링(CSR)을 제공하여, 프론트엔드와 백엔드 간의 역할 분리 및 데이터 전달 구조를 명확히 이해할 기회라고 판단하였습니다.

동일한 게시판 목록 기능을 서로 다른 기술 스택으로 구현하면서 차이를 명확히 비교할 수 있었습니다.

이를 통해 SSR은 초기 로딩이 빠르고 단순하지만 새로고침으로 인해 UX가 떨어지고, CSR은 초기 로딩은 무겁지만 이후에는 부드럽고 유연한 화면 전환과 명확한 역할 분리로 유지보수성과 협업 효율성이 높다는 차이를 직접 체감했습니다.

백엔드에서는 데이터를 API 형태로만 제공하고, 프론트는 해당 데이터를 활용해 화면을 구성하는 구조를 경험하며, 실제 협업 환경에서 발생할 수 있는 역할 충돌 문제(PHP 사용 시절 퍼블리셔와의 충돌)가 API 기반 구조에서는 해결될 수 있음을 확인하였습니다.

팀 프로젝트 This vs That에서는 서비스 특성상 게시글 소비가 모바일 환경에서 많이 이루어질 것이라 판단했습니다.

무한 스크롤 초기 구현 과정에서 게시글을 3개씩 불러오도록 설정했지만, 화면의 세로 길이가 긴 경우 스크롤이 바닥에 닿지 않아 추가 게시글이 로드되지 않는 문제가 발생했습니다.

이를 해결하기 위해 초기 로딩 시 화면 크기를 계산하여 필요한 페이지 수만큼 데이터를 미리 불러오도록 로직을 개선하였습니다.

모바일 환경에서 사용자들이 끊김 없이 게시글을 탐색할 수 있도록 하여 사용자 경험을 개선하였습니다.

단순히 클라이언트에서 스크롤 이벤트만 처리하는 수준이 아니라, 백엔드에서 화면 크기 및 로드 단위를 고려한 데이터 전달 로직을 구현함으로써 효율적인 데이터 로딩을 지원할 수 있었습니다.

Ajax 기반의 추가 로딩 방식을 적용하여, 서버 부하를 최소화하면서도 유연한 데이터 제공이 가능해졌습니다.

이전 Spring Framework 프로젝트에서 JPA를 사용하지 않고 개발 및 배포를 진행했을 때, 데이터베이스 테이블을 직접 생성해야 하는 번거로움이 발생했습니다.

또한 특정 DB에 종속적인 방식으로 개발하다 보니 배포 환경이 바뀔 경우 호환성 문제가 생기고, 유지보수에도 많은 시간이 소요되었습니다.

JPA를 사용하면 데이터베이스 설정만 변경해도 애플리케이션을 손쉽게 다른 환경에 배포할 수 있습니다.

ORM을 통해 객체와 테이블 간 매핑을 자동화하여 반복적인 SQL 작성과 수동 매핑 코드를 제거했습니다.

테이블 생성 및 매핑 과정의 수작업이 사라져 배포 과정이 간단해지고, 다양한 DB 환경에서도 안정적으로 동작할 수 있었습니다.

`findById(Long id)` 와 같은 직관적인 메서드 호출만으로 원하는 데이터를 조회할 수 있어 개발 속도가 향상되고 유지보수가 용이해졌습니다.