Java 신입 시스템 설계 기술면접

사용자 리소스는 '/users'로 표현하고, 조회는 GET /users 또는 GET /users/{id}, 생성은 POST /users, 수정은 PUT /users/{id} 또는 PATCH /users/{id}, 삭제는 DELETE /users/{id}로 설계합니다. URL에는 동사를 사용하지 않고 명사로 리소스를 표현하며, HTTP 메서드로 행위를 구분하는 것이 RESTful 설계 원칙입니다. PATCH는 부분 수정, PUT은 전체 수정에 사용하며, 상황에 맞게 선택할 수 있습니다.

Controller는 HTTP 요청을 받아 응답을 반환하는 프레젠테이션 계층, Service는 비즈니스 로직을 처리하는 계층, Repository는 데이터베이스 접근을 담당하는 계층입니다. 이렇게 계층을 분리하면 각 계층의 책임이 명확해지고, 코드의 재사용성과 유지보수성이 향상됩니다. 또한 특정 계층의 변경이 다른 계층에 영향을 최소화하며, 테스트 작성도 용이해집니다. 예를 들어 데이터베이스를 MySQL에서 PostgreSQL로 변경할 때 Repository 계층만 수정하면 됩니다.

API 응답은 HTTP 상태 코드와 응답 본문을 활용하여 설계합니다. 성공 시에는 200, 201 등의 상태 코드와 함께 data 필드에 실제 결과를 담고, 실패 시에는 400, 404, 500 등의 상태 코드와 함께 error 객체에 에러 코드, 메시지, 상세 정보를 포함합니다. 공통 응답 구조로 success(성공 여부), message(응답 메시지), data(실제 데이터), timestamp(응답 시간) 등을 포함하면 클라이언트에서 일관되게 처리할 수 있습니다. 특히 에러 응답에는 errorCode를 포함하여 클라이언트가 에러 유형별로 적절히 대응할 수 있도록 합니다.

Post 테이블에는 id(PK), title, content, author_id, created_at 등을 두고, Comment 테이블에는 id(PK), post_id(FK), content, author_id, created_at 등을 설계합니다. 이는 일대다 관계로 Comment 테이블의 post_id가 Post 테이블의 id를 참조합니다. 인덱스는 Comment 테이블의 post_id에 추가하여 특정 게시글의 댓글 조회 성능을 향상시키고, created_at에도 인덱스를 고려하여 최신순 정렬을 빠르게 처리할 수 있습니다. 복합 인덱스 (post_id, created_at)을 생성하면 특정 게시글의 댓글을 시간순으로 조회하는 쿼리가 더욱 효율적입니다.

Look-Aside(Cache-Aside) 패턴을 사용하여 먼저 캐시를 조회하고, 캐시에 없으면 DB에서 조회 후 캐시에 저장하는 방식을 적용합니다. Redis와 같은 인메모리 캐시를 사용하며, TTL(Time To Live)을 설정하여 일정 시간 후 자동으로 만료되도록 합니다. 상품 정보가 수정될 때는 해당 상품의 캐시를 즉시 삭제(Cache Invalidation)하여 다음 조회 시 최신 데이터를 가져오도록 합니다. Spring의 @Cacheable, @CacheEvict 어노테이션을 활용하면 선언적으로 캐싱을 구현할 수 있습니다.

API 버전 관리는 URI에 버전을 포함하는 방식(/api/v1/users, /api/v2/users), Header에 버전 정보를 담는 방식(Accept: application/vnd.company.v2+json), 또는 Query Parameter로 전달하는 방식(?version=2) 등이 있습니다. 가장 명시적이고 직관적인 URI 버전 관리 방식을 권장하며, v1과 v2 컨트롤러를 별도로 구현하여 유지합니다. 기존 v1 API는 deprecation 공지 후 일정 기간 유지하다가 단계적으로 종료하며, 클라이언트에게 충분한 마이그레이션 기간을 제공합니다. 문서화도 버전별로 명확히 구분하여 제공해야 합니다.

수평 확장 시 로드밸런서를 앞단에 두고 여러 애플리케이션 서버로 트래픽을 분산시킵니다. 이때 각 서버는 Stateless하게 설계되어야 하며, 세션 정보는 서버 메모리가 아닌 외부 저장소에 보관해야 합니다. Redis와 같은 중앙 세션 저장소를 사용하거나, JWT 토큰 기반 인증으로 서버에 세션을 저장하지 않는 방식을 선택할 수 있습니다. 데이터베이스 커넥션 풀 설정도 서버 수에 맞게 조정해야 하며, 파일 업로드와 같은 공유 리소스는 S3 같은 외부 스토리지를 활용합니다. 로그도 중앙 집중식 로깅 시스템을 구축하여 관리해야 합니다.

인증(Authentication)은 사용자가 누구인지 확인하는 것이고, 인가(Authorization)는 해당 사용자가 특정 리소스에 접근할 권한이 있는지 확인하는 것입니다. 세션 기반 인증은 서버에 세션 정보를 저장하고 클라이언트에게 세션 ID를 쿠키로 전달하는 Stateful 방식입니다. JWT 기반 인증은 토큰 자체에 사용자 정보를 포함하여 서버에 상태를 저장하지 않는 Stateless 방식으로, 수평 확장에 유리합니다. JWT는 Access Token과 Refresh Token을 함께 사용하여 보안성을 높이며, Spring Security와 같은 프레임워크를 활용하여 구현할 수 있습니다.

페이징 처리는 Query Parameter로 page(페이지 번호)와 size(페이지 크기)를 받아 처리합니다. 예를 들어 GET /posts?page=1&size=10 형태로 요청을 받습니다. 응답에는 실제 데이터 목록뿐만 아니라 totalElements(전체 데이터 수), totalPages(전체 페이지 수), currentPage(현재 페이지), size(페이지 크기), hasNext(다음 페이지 존재 여부) 등의 메타 정보를 포함합니다. Spring Data JPA의 Pageable과 Page 인터페이스를 활용하면 쉽게 구현할 수 있으며, 데이터베이스 쿼리는 LIMIT과 OFFSET을 사용합니다.

Spring의 @ControllerAdvice와 @ExceptionHandler를 사용하여 전역 예외 처리기를 구현합니다. 비즈니스 예외는 커스텀 예외 클래스를 정의하고, 각 예외 유형별로 적절한 HTTP 상태 코드를 매핑합니다. 예를 들어 NotFoundException은 404, InvalidInputException은 400, UnauthorizedException은 401로 응답합니다. 에러 응답 형식은 errorCode, message, details, timestamp 등을 포함하여 일관되게 유지하며, 개발 환경에서는 stack trace를 포함하되 운영 환경에서는 제외합니다. 로그는 적절한 레벨로 기록하여 모니터링과 디버깅에 활용합니다.