[GL 3기] 그로스로그 앱 백엔드, 정책과 구조를 함께 설계한 이유 🧱

커뮤니티 앱의 백엔드는 회원 정보를 저장하는 것만으로 끝나지 않습니다. 기수가 바뀔 때마다 회비와 보증금 규칙이 달라지고, 한 회원이 여러 운영팀에서 활동할 수 있으며, 이전 기수의 정책과 권한도 기록으로 남겨야 합니다. 기능이 늘수록 데이터 구조와 코드의 책임을 함께 정리해야 변경에 대응하기 쉬워집니다.

그로스로그 3기 8차 개발 세미나에서는 이태형 님이 그로스로그 앱의 백엔드 개발 과정을 소개했습니다. 기술 스택과 테이블 관계를 살펴본 뒤, 클린 아키텍처를 적용해 도메인과 웹·데이터베이스 영역을 나눈 방법, QueryDSL 조회에서 Entity와 DTO를 선택하는 기준까지 차례로 공유했습니다.

Growth-Log 앱 개발기 백엔드 편이라는 제목이 적힌 슬라이드

Spring 기반 기술을 하나의 개발 흐름으로 묶었습니다

백엔드는 Java 17과 Spring Boot를 중심으로 구성했습니다. 데이터 저장에는 Spring Data JPA를 사용하고, 조건이 복잡한 조회는 QueryDSL로 작성했습니다. 빌드 도구는 Gradle, 소스 코드 관리는 GitHub를 활용했습니다.

중요한 점은 기술 이름을 많이 사용하는 것이 아니라 각 도구의 역할을 구분하는 일이었습니다. JPA는 도메인 데이터를 저장하고 변경하는 흐름에, QueryDSL은 필요한 조건과 컬럼을 명시하는 조회에 사용했습니다. 이 구분은 뒤에서 설명한 내부·외부 영역의 분리와도 연결되었습니다.

기수가 바뀌어도 이전 정책이 사라지지 않도록 📊

그로스로그 앱에는 기수별 회비와 보증금, 지각·결석에 따른 차감액, 패널티 면제 횟수처럼 운영 정책과 관련된 데이터가 있습니다. 발표에서는 기수 테이블을 중심으로 회비 정책, 패널티 정책과 패널티 면제 정책을 각각 연결했습니다.

정책을 수정할 때 기존 행을 덮어쓰지 않고 이전 정책을 비활성화한 뒤 새로운 정책을 추가했습니다. 이렇게 하면 과거 기수에 어떤 기준이 적용됐는지 이력으로 확인할 수 있습니다. 보증금을 정산할 때는 현재 기수에서 활성화된 정책을 찾아 계산하도록 설계했습니다.

회원과 팀의 관계도 별도의 연결 테이블로 풀었습니다. 한 회원이 개발팀과 홍보팀 등 여러 팀에 참여할 수 있으므로 User와 Team은 다대다 관계가 됩니다. 자동으로 연결 테이블을 만드는 방식에 맡기기보다 user_team을 명시적으로 두어 관계에 필요한 속성과 변경 가능성을 관리했습니다.

기본키는 데이터의 사용 환경을 보고 선택했습니다

회원 테이블의 기본키는 정수형으로 설계했습니다. 정수는 고정된 크기로 저장되어 인덱스 페이지에 더 많은 키를 담을 수 있고, 비교 연산과 순차 삽입에도 유리합니다. 자동 증가 값을 사용하면 B+Tree 인덱스의 끝에 값이 추가되어 페이지 분할이 줄어드는 장점도 살펴봤습니다.

이태형 발표자가 정수형 기본키와 인덱스의 저장·검색 효율을 설명하는 모습

반면 모든 시스템에 정수형이 정답인 것은 아닙니다. 여러 데이터베이스에서 동시에 키를 생성하거나 데이터를 병합해야 한다면 UUID처럼 충돌 가능성이 낮은 값이 필요할 수 있습니다. 외부에 노출되는 식별자를 쉽게 예측하지 못하게 하거나, 데이터베이스에 키 생성을 집중시키지 않고 대량 데이터를 처리해야 할 때도 문자열 기반 식별자를 검토할 수 있습니다.

세션은 저장 효율만 비교해 결론을 내리기보다 고유성, 분산 환경, 조회 방식과 운영 요구를 함께 보고 기본키를 결정해야 한다는 관점을 보여줬습니다.

클린 아키텍처로 변경의 방향을 통제했습니다 🛠️

클린 아키텍처의 핵심은 소스 코드의 의존성이 외부에서 내부로 향하도록 만드는 것입니다. 도메인 모델과 비즈니스 규칙을 안쪽에 두고, 웹·보안·데이터베이스처럼 교체될 수 있는 기술은 바깥쪽에 배치합니다. 외부 기술이 바뀌더라도 핵심 정책까지 연쇄적으로 수정하지 않도록 경계를 만드는 방식입니다.

발표에서는 내부 영역을 도메인과 서비스 레이어로, 외부 영역을 Web, Security와 Data로 나눴습니다.

• 도메인 영역은 모델과 조회·저장 같은 비즈니스 규칙을 담당합니다.
• 서비스 레이어는 외부에서 사용할 유스케이스를 인터페이스로 정의합니다.
• Web 영역은 Controller와 DTO를 통해 요청과 응답을 처리합니다.
• Data 영역은 도메인에 정의한 Repository 인터페이스를 실제 데이터베이스 기술로 구현합니다.

Controller는 서비스 구현체를 직접 바라보지 않고 인터페이스에 의존했습니다. 화면과 주고받는 값에는 DTO를 사용해 도메인 객체가 외부로 그대로 전달되지 않도록 했습니다. 데이터 영역에서는 저장과 삭제에 JpaRepository를, 조회 쿼리에는 QueryDSL을 사용하는 방향을 택했습니다.

조회 목적에 맞춰 Entity와 DTO를 나눴습니다

Entity 조회는 도메인 상태를 변경해야 하거나 연관관계 데이터가 필요한 작업에 적합합니다. 반면 조회 전용 화면에서 일부 컬럼만 필요하다면 DTO로 바로 매핑해 가져오는 편이 네트워크 전송량과 메모리 사용을 줄일 수 있습니다.

발표에서는 대량 조회에 DTO 프로젝션을 사용하고, 여러 값을 임시로 묶은 Tuple을 서비스 바깥까지 전달하지 않는 방향을 설명했습니다. 반환 타입을 명확히 하면 조회 결과를 사용하는 코드가 어떤 값을 받는지 파악하기 쉽고, 데이터베이스 조회 로직과 서비스 로직의 책임도 분리할 수 있습니다.

그로스로그 앱 백엔드 개발기는 테이블을 많이 만드는 방법보다 변화하는 정책을 어디에 기록하고, 코드의 각 영역이 어느 방향을 바라보게 할지에 초점을 맞췄습니다. 기수별 정책 이력, 회원과 팀의 관계, 기본키와 조회 모델은 서로 다른 문제처럼 보이지만 모두 변경을 안전하게 받아들이기 위한 설계로 이어졌습니다.

백엔드 구조가 복잡해질 때는 먼저 도메인 규칙과 외부 기술을 구분하고, 변경 이유가 같은 코드끼리 모아보세요. 그 경계가 데이터 모델과 의존성 방향을 결정하는 출발점이 됩니다.