안녕하세요 강의 질문 드립니다

네. 말씀하신 대로 import 대상은 스캔이 될 필요도 없으니 동작 기능만을 생각한다면 굳이 @Component를 붙이지 않아도 됩니다.

그런데 @Component와 같은 애노테이션은 꼭 스캔 등의 기능을 위해서만 붙이는 건 아닙니다. 이 클래스가 스프링의 컴포넌트(빈)이라는 것을 나타내는 주석(annotation)으로 부여할 수도 있는 것이지요. 코드를 읽을 때 ServerProperties를 보고, 이 클래스도 빈으로 등록되고, 다른 빈에 DI될 수도 있구나라고 인식할 수 있습니다.

스프링 @Import의 문서를 보면
Indicates one or more component classes to import — typically @Configuration classes.

라고 되어있습니다.

여기서 component class가 꼭 @Component가 붙은 클래스라는 의미는 아니지만 스프링의 컴포넌트라고 생각한다면 적절한 애노테이션이 붙어있는게 좋다고 생각합니다. Import하는 대표적인 컴포넌트인 @Configuration도 @Component를 메타 애노테이션으로 가지고 있는 애노테이션이죠.

Import 대상 중에서 @Component를 안 붙이는 관례를 가지는 경우도 있긴합니다.
ImportSelector and ImportBeanDefinitionRegistrar implementations 두 가지인데요. 이건 @Enable 류의 애노테이션에서 import되는 것이 유일한 사용 용도이기도 하고, 클래스의 구현 인터페이스를 보면 용도를 분명하게 알 수 있기에 굳이 @Component 등을 붙이지 않고 씁니다. 붙여도 상관은 없고요.

반면 ServerProperties는 인터페이스 등을 보고 이게 스프링의 빈이 될 거라는 힌트는 전혀 없으니 저는 @Component를 붙이는 것도 좋다고 생각합니다.

근데 강의에서는 스프링부트의 동작방식을 보여주기 위해서 Properties 클래스도 빈으로 등록된다는 걸 설명하기 위해서 이런 접근방법을 썼던 것이고요. 실제로 커스톰 Properties를 애플리케이션 레벨에서 사용한다면 스프링부트가 제공하는 @ConfigurationProperties 메카니즘을 활용하게 됩니다.