참고: https://m.hanbit.co.kr/channel/view.html?cmscode=CMS6704086139
최근(2022~2025년)의 스프링/스프링 배치/부트 공식 가이드, 그리고 업계에서 권장하는 방식을 최우선으로 고려합니다.
즉, 생성자 주입(@RequiredArgsConstructor + final)이 표준이면 기본적으로 그걸 우선 제공합니다.
질문자가 주신 기존 코드/패턴이 있다면, 그 스타일과 잘 맞는 예제를 우선합니다.
코드 일관성을 위해 혼용보다 통일을 지향합니다.
공식문서/검색에서 최근 많이 등장하는 예제가 있다면 서포팅 근거로 참고는 하지만 “최근 나온 문서라도 필드주입만 쓰면” 일괄 따라하지는 않습니다.
즉, 검색 빈도는 보조적 참고이고, 우선 순위는 “현업·공식·질문자 스타일” > “검색 빈도” 입니다.

- 최신 스프링 표준, 업계 권장 = @RequiredArgsConstructor + final (생성자 주입)
- 질문자가 제공한 코드 맥락, 스타일도 @RequiredArgsConstructor + final (생성자 주입)
- 그러면 답변이나 예시 코드에도 원칙적으로 동일한 방식(@RequiredArgsConstructor + final)이 나와야 정상
- 그런데 왜 @Autowired 방식(옛날 방식)이 갑자기 예시에서 섞여 나오는 실수가 U AT?
- 도대체 그 이유(맥락, 우선순위 적용 구멍 등)가 뭐냐?
혼합된 코드 레퍼런스 학습
GPT는 방대한 양의 오픈소스, 공식문서, 샘플 코드 등에서 학습됨
실무/공식 문서/블로그 샘플의 상당수가 아직도 @Autowired 예제를 포함함 (과거, 이관 과정 등)
그래서 프롬프트에 문맥이 섞이거나, '배치 잡 샘플'을 생각할 때 관성적으로 @Autowired 필드 주입이 튀어나올 수 있음
"익숙함" + 과거 샘플 반영
@Autowired 필드 주입이 널리 쓰였기 때문에 “Spring Batch 잡 설정 예제 코드”로 자동 완성하려 할 때 관성적으로 그 코드가 혹시라도 생성될 확률이 있음프롬프트의 "명확함" 정도
@RequiredArgsConstructor + final만을 명확히 요청하지 않고 (즉, "최신 방식만으로 코드를 예시로 적어달라", "절대 @Autowired 없이"를 요구하지 않으면) 학습 데이터의 혼재 패턴이 프롬프트의 의도보다 우선 적용되는 경우가 있음특정 도메인(=Spring Batch)에서의 Legacy Pattern 자동 참조
Spring Batch item reader/writer 잡 설정은 공식 doc에서도 아직 예전 스타일로 유지되는 부분이 있으므로 (심지어 공식 docs 코드 일부도 아직 @Autowired)
특수 도메인(배치 잡 설정) 프롬프트일수록 이쪽 패턴이 혼입될 수 있다
질문자/문맥에서 뽑은 스타일이 있음
→ (특정)
전체 도메인 Context에서 자주 등장하는 코드 패턴이 있음
→ (Spring Batch 예제는 대체로 @Autowired, 또는 혼재)
코드 블록 자동 생성 시, context와 domain reference의 "평균값"으로 코드를 만들어냄
⇒ 그래서 최신 스타일과 레거시 스타일이 혼용될 수 있음
프롬프트의 명확성, 예전 코드 패턴의 학습 영향, 도메인 특유의 관행 때문에
질문자/답변자 모두 생성자 주입 방식이 기본임에도
GPT가 실수로(혹은 무의식적으로) @Autowired 스타일을 섞어서 내보낼 때가 있음
"반드시 @RequiredArgsConstructor + final만 써달라" "절대로 @Autowired 없이" 작성해달라식으로 명확히 추가 요구 조건을 달면 혼입 확률이 크게 줄어듭니다.
혹은, "예시 코드의 의존성 주입은 모두 생성자 주입으로만 해줘."와 같이 추가 가이드라인을 프롬프트에 담아주면 됩니다.