실무적 선택의 기로: ID 전략부터 서비스 레이어 설계까지

게시 2026/04/09

By woolam

조회 7 분읽는 시간

“한 줄 요약: 개발은 정답 찾기가 아니라 타당한 근거를 바탕으로 최적의 선택지를 고르는 과정이다.”

1. 실무에서 마주하는 기술적 선택지

결론부터 말하면 비즈니스 요구사항과 DB 전략에 따라 다릅니다.

Long (Bigint): 가장 일반적입니다. DB 내부적으로 인덱싱 성능이 뛰어나고 저장 공간을 적게 차지합니다. (주로 Auto_Increment 사용)
UUID: 분산 서버 환경에서 ID 생성 중복을 방지하거나 URL 등에 ID가 노출될 때 데이터의 규모나 순서를 숨기고 싶을 때 사용합니다. 다만 인덱싱 성능이 Long에 비해 떨어질 수 있습니다.

HTTP 응답 헤더에 상태 코드가 포함되지만 JSON 객체 내부에 별도의 상태 필드(예: code, status)를 선언하는 것이 더 안정적입니다.

이유: 멀티 프레임워크 환경이나 다양한 클라이언트 스택에서 상태 코드 처리가 제각각일 수 있기 때문입니다. 공통 응답 포맷을 유지하면 클라이언트가 일관된 로직으로 에러를 핸들링하기 유리합니다.

DTO(Data Transfer Object)는 계층 간 데이터 교환을 위한 객체로 엔티티를 보호하는 ‘완충 지대’ 역할을 합니다.

Request DTO: 클라이언트가 보낸 JSON 데이터를 서버가 사용할 객체로 변환합니다. (주로 Controller에서 @RequestBody로 수신)
Domain Processing: 서비스 레이어에서 DTO를 기반으로 비즈니스 로직을 수행하고 엔티티를 조작합니다.
Response DTO: 가공된 엔티티 정보를 클라이언트가 필요한 데이터만 골라 담아 다시 JSON으로 변환하여 반환합니다.

장점: 조회 성능이 매우 빠름 (리스트 화면에서 별도 쿼리 없이 개수 노출 가능).
단점: 데이터 정합성(Consistency) 보장이 어려움. 동시성 이슈(두 명의 사용자가 동시에 댓글을 달 때)나 저장/삭제 실패 시 카운트가 꼬일 위험이 큼.

장점: 정합성이 100% 보장되며 구현이 단순함.
단점: 조회 시 쿼리가 1번 더 발생함.
판단 근거: 댓글 제한이 10개 내외라면 count 쿼리의 비용은 매우 미미함. 성능 손실보다 데이터의 정확성이 주는 이득이 훨씬 큼.

일정(Schedule)을 조회할 때 댓글(Comment)도 함께 조회해야 하는 상황에서의 설계 고민입니다.

잘못된 접근: Controller에서 ScheduleService와 CommentService를 둘 다 호출. -> 컨트롤러가 비즈니스 로직의 흐름(책임)을 가지게 됨.
해결 방안: ScheduleService에서 처리하되, 어떤 의존성을 가질 것인가?
- 단순 조회: ScheduleService가 CommentRepository를 직접 사용해도 무방함.
- 로직 포함: 댓글 조회 시 특정 정책(비밀댓글 제외, 차단 유저 제외 등)이 포함된다면 CommentService를 호출하는 구조가 바람직함. 즉 도메인 로직의 응집도를 높이기 위해 서비스 간 호출을 선택.

오늘 고민한 모든 내용의 공통점은 “정답은 없지만 선택에 따른 근거는 명확해야 한다” 는 것입니다.

이러한 수많은 선택 속에서 최적의 균형점을 찾는 것이 개발자의 핵심 역량임을 깨달았습니다. 기술적 결정을 내릴 때 항상 “왜(Why)” 를 스스로에게 묻고 그 선택이 가져올 장단점을 명확히 인지하는 연습이 필요합니다.

정답을 하나로 정해두고 공부하기보다 다양한 아키텍처와 전략을 경험하며 ‘선택의 폭’ 을 넓히는 데 집중하겠습니다. 특정 방식이 무조건 맞다는 편견을 버리고 현재 우리 팀과 서비스 상황에 가장 타당한 선택을 내리는 개발자가 되겠습니다.