그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Spring
Spring

Spring에서 객체를 Bean으로 관리하는 이유는 무엇인가요?

실무5/5
설계4/5
인간4/5
기초3/5

면접관의 질문 의도

Bean의 장점만 줄줄 외우는지, 아니면 컨테이너 관리의 이점과 한계(상태 관리, 스코프, 테스트 대체 전략)를 함께 보는지 가른다.

큐레이션 답변

학습 자료

Spring이 객체를 Bean으로 관리하는 이유는 생성·주입·생명주기를 컨테이너가 일관되게 책임지게 만들기 위해서다. 이렇게 하면 의존성 조립이 표준화되고, 트랜잭션·보안·로깅 같은 횡단 관심사를 AOP로 한 곳에서 끼워 넣을 수 있다. 테스트에서도 대체 Bean을 주입해 검증 경계를 깔끔하게 자른다. 단, 모든 객체를 Bean으로 올리면 안 된다. 싱글톤 가변 상태, 스코프 선택, 책임 경계를 함께 설계해야 컨테이너 관리의 이점이 실제로 나온다.

좋은 답변 구조

  1. 01Bean 관리의 핵심 목적(생성·생명주기 권한 위임)을 한 문장으로 정의한다
  2. 02DI·싱글톤·AOP·테스트 대체가 이 정의에서 어떻게 따라 나오는지 연결한다
  3. 03모든 객체를 Bean으로 올리면 안 되는 경우(싱글톤 가변 상태, 스코프 오선택)를 구체적으로 짚는다
  4. 04결합도·공통 정책 일관성 관점에서 마무리한다

자주 실수하는 포인트

Bean = 싱글톤이라고만 외우고 스코프 선택과 생명주기 차이를 설명 못 한다
DI 이점만 나열하고 컨테이너 관리의 한계(싱글톤 상태 공유, 시작 시간, 순환 의존)는 언급하지 않는다
AOP·트랜잭션이 Bean 관리 위에서 동작하고 self-invocation에서는 안 걸린다는 연결을 빠뜨린다
테스트 대체 Bean 주입을 단순한 '편의'로만 설명하고 검증 경계 설계 근거를 빠뜨린다

실무 맥락

  • 서비스·리포지토리 계층 의존이 깊고 트랜잭션 경계가 여러 곳에 걸쳐 있는 백엔드 서비스
  • 보안·로깅·트레이싱 같은 횡단 관심사를 모든 요청 경로에 일관되게 끼워야 하는 운영 환경
  • 통합 테스트에서 외부 시스템 의존을 대체 Bean으로 교체해야 하는 테스트 환경
  • 스코프 설정 실수로 싱글톤이 요청별 상태를 들고 다녀 장애가 난 서비스

본인 경험에 녹이는 힌트

new로 직접 만들던 객체를 Bean으로 옮기며 의존성 그래프가 어떻게 정리됐는지 말할 수 있다면 DI의 체감 효과와 연결할 수 있다

싱글톤 Bean에 가변 상태를 잘못 뒀다가 동시성 이슈를 겪은 경험이 있다면 스코프 선택 근거와 연결할 수 있다

AOP로 트랜잭션·로깅을 끊어낸 경험이 있다면 컨테이너 관리가 이를 가능하게 한 이유를 풀어낼 수 있다

테스트에서 Mock Bean으로 외부 의존을 갈아 끼운 경험이 있다면 검증 경계 설계 이야기로 이어갈 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1싱글톤 Bean에 상태를 두면 안 되는 이유는 무엇이고, 어떤 스코프로 대체할 수 있나요
Q2순환 의존성이 생겼을 때 생성자 주입과 세터 주입 중 무엇을 택하고 왜 그런가요
Q3프록시 기반 AOP가 self-invocation에서 동작하지 않는 이유는 무엇인가요
Q4Bean 등록 방식(@Component, @Bean, 수동 등록) 중 무엇을 언제 쓰나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문