꼬깔콘을 먹는 북극여우님의 면접 결과

의존성 주입의 핵심 개념과 장점을 정확하게 이해하고 계시며, 특히 A클래스와 B클래스를 활용한 구체적인 예시를 통해 개념을 명확히 설명해주신 점이 매우 좋았습니다. 결합도 감소, 확장성, 테스트 용이성 등 주요 장점들을 잘 언급해주셨고, "제3의 클래스에서 주입"이라는 표현으로 DI 컨테이너의 역할도 암시해주신 것이 인상적이었습니다. 다만 의존성 주입의 구체적인 방법들(생성자 주입, setter 주입, 인터페이스 주입)이나 IoC(Inversion of Control) 같은 핵심 전문용어를 추가로 언급하시면 더욱 완성도 높은 답변이 될 것 같습니다. 전반적으로 개념에 대한 이해도가 높고 실무 관점에서의 장점을 잘 파악하고 계신 것으로 보입니다.

결합도의 개념을 올바르게 이해하고 계시고, 외부 객체에 대한 의존 정도와 하드코딩의 관계를 잘 설명해주셨습니다. 또한 객체 변경 시 연쇄적으로 발생하는 문제점과 의존성 주입이 이를 해결하는 방법이라는 점도 정확하게 파악하고 계십니다. 다만 답변을 더욱 완성도 있게 만들려면 강결합과 약결합이라는 전문용어를 사용하시고, 구체적인 예시를 들어 설명해주시면 좋겠습니다. 예를 들어 "DatabaseConnection을 직접 생성하는 것(강결합)과 인터페이스를 통해 주입받는 것(약결합)"과 같은 실무 예시를 추가하시면 더욱 명확한 답변이 될 것입니다.

구체적인 할인 정책 예시를 들어서 객체 변경 시 발생하는 문제를 잘 설명해주셨고, 변경의 여파가 확산되는 과정을 논리적으로 설명한 점이 좋았습니다. 다만 답변에서 핵심적인 부분이 빠져있는데, 의존성 주입이 이러한 문제를 어떻게 해결하는지에 대한 설명이 필요합니다. 예를 들어, 할인 정책 인터페이스를 도입하고 외부에서 구체적인 구현체를 주입받으면 할인 정책이 변경되어도 사용하는 객체의 코드는 변경할 필요가 없다는 점을 추가로 설명하면 더 완성도 있는 답변이 될 것입니다. 앞으로는 문제 제시뿐만 아니라 의존성 주입을 통한 해결책까지 함께 설명하는 연습을 해보시기 바랍니다.

의존성 주입을 통해 추상화를 활용하여 구현체를 자유롭게 교체할 수 있다는 핵심 개념을 잘 이해하고 계시는 것 같습니다. 하지만 답변이 다소 추상적이어서 구체적인 코드 변경 사례를 보여주지 못한 점이 아쉽습니다. 예를 들어 "기존에는 `class OrderService { private DiscountPolicy policy = new FixedDiscountPolicy(); }`였다면, 의존성 주입 적용 후에는 `class OrderService { private DiscountPolicy policy; public OrderService(DiscountPolicy policy) { this.policy = policy; } }`로 변경되어 외부에서 구현체를 주입받는다"는 식의 before/after 코드를 제시하면 더 명확한 설명이 될 것입니다. 앞으로는 "구체적으로 어떻게 변경되나요?"라는 질문에 실제 코드 레벨의 변화를 보여주는 연습을 해보시기 바랍니다.