[레벨1] 레벨 인터뷰 정리

 

🎤 레벨 인터뷰

레벨1을 모두 마친 시점에서 그동안 학습했던 내용을 기반으로 서로 인터뷰하는 활동이다. (면접 비슷한 느낌?)

인터뷰 이틀 전까지 크루들은 각자 자신이 학습한 내용을 1장 분량으로 정리해서 제출한다.

 

우리 조는 총 6명이었고, 구구 코치님과 인터뷰를 진행했다. 그리고 각 크루는 번갈아가면서 인터뷰이, 인터뷰어, 옵저버를 맡는다.

• 인터뷰이 1명, 인터뷰어 3명, 옵저버 2명
• 코치님은 인터뷰어로 참여

 

💬 인터뷰 과정

각 크루마다 세 명의 인터뷰이를 담당하게 된다. 나는 웨이드, 강산, 새로이의 인터뷰어로 참여하게 되었고, 세 크루의 학습 로그를 토대로 질문지를 만들었다.

 

하지만 실제 인터뷰에서 미리 준비한 질문들을 거의 하지 못했다. 첫 질문만 크루들이 던져주고, 이후에는 구구 코치님이 꼬리질문 혹은 다른 질문으로 이어가셨는데 코치님 질문이 더 좋아서 끼어들 틈이 없었기 때문이다.. ㅎ.ㅎ

 

앞 순서에서는 객체지향 질문이 많았고, 이후에는 기술/개념적인 질문이 주로 나왔다. 특히 우리 조는 코치님이 일부러 학습 로그에 작성하지 않은 내용들도 질문해주셨다.

그리고 이러한 진행 방식 덕분에 놓친 학습 내용들이 무엇인지 파악할 수 있었다.

 

레벨1 학습 키워드

각 미션을 하면서 노션/블로그에 정리했던 내용들을 토대로, 학습 키워드를 다음과 같이 정리했다.

• 일급 컬렉션
• 불변 객체
• getter
• TDD
• 레이어드 아키텍처
• 추상화
• 상속과 합성

 

인터뷰 질문/답변 정리

일급 컬렉션

• 일급 컬렉션은 무엇인가요?
  

👉🏻 일급 컬렉션이란, 단일 컬렉션을 객체로 감싸서 캡슐화한 것입니다.
일급 컬렉션을 처음 접했을 때 Integer나 String 등이 아닌 "컬렉션"을 캡슐화해야하는 이유에 대해서 고민했습니다. 그리고 다른 원시 값과 다르게 컬렉션은 final 키워드 만으로는 완전한 불변을 보장할 수 없기 때문에, 컬렉션의 불변을 보장하거나 변화를 제어하기 위해서 일급 컬렉션을 사용한다고 이해했습니다.

• 그렇다면 컬렉션은 무조건 객체로 감싸야하나요? 실제로 어떤 경우에 일급 컬렉션을 사용했나요?

👉🏻 아닙니다.
컬렉션 필드의 불변을 보장해야하는 하는 경우에도 사용할 수 있지만, 컬렉션 연산만으로 요구사항의 의미를 파악하기 어려울 때도 사용할 수 있다고 생각합니다. (따라서 불변성이 필요하지 않은 경우, 혹은 컬렉션이 필수 요구사항과 밀접한 관계를 갖지 않는 경우에는 굳이 객체로 감쌀 필요가 없다고 생각합니다.)

이번 장기 미션에서 보드판을 구현할 때, Map 자료구조로 각 장기 기물의 위치를 관리했습니다. 이때, 각 장기 기물 위치를 관리하는 데 있어서 Map의 put이나 delete와 같은 연산만으로는 "장기 기물의 위치를 옮긴다"와 같은 요구사항의 의미를 파악하기 어렵다고 생각해서 일급 컬렉션을 적용했습니다.

• (추가질문) 상태가 없는 객체도 객체인가요?

👉🏻 네, 저는 상태가 없는 객체도 객체로 볼 수 있다고 생각합니다.
요구사항에 맞게 객체들이 서로 소통하는 과정에서, 어떤 메시지가 필요하냐에 따라서 객체가 결정된다고 생각합니다. 즉, 객체 외부에서는 객체가 어떤 인터페이스를 가지고 있는지만 관심이 있을 뿐, 해당 객체가 어느 상태 값을 갖는지는 전혀 관심이 없습니다.

이 말인 즉슨 특정 객체가 상태를 가지고 있느냐 가지고 있지 않느냐도 외부에서는 전혀 알 필요가 없는 정보이기 때문에, 상태가 없는 객체도 협력 공동체의 일원으로서 충분히 행동할 수 있는 존재라고 생각합니다.

✚ 더 구체적으로는, 객체는 맞지만 인스턴스마다 고유한 특징을 가질 수 없다는 점에서 조금 아쉬운 객체(?) 라고 생각함.
만약 필드가 존재하지 않는 객체가 생성됐다면, 메서드 파라미터로 필요 정보를 모두 전달받는 형태일 것 같다. 이때, 파라미터로 전달된 데이터를 갖고 있는 주체가 스스로 처리하게 할 수는 없는지, 다시 점검해볼 필요는 있다고 생각함.

---

불변 객체

• 불변 객체는 왜 사용하나요?

👉🏻 값의 예상치 못한 변경을 막을 수 있기 때문입니다.
하지만, 불변 객체를 학습했을 때 이러한 장점보다는 불변 객체는 동일성을 통해서 효율적으로 값을 비교할 수 있다는 점이 특히 인상 깊었습니다. 서로 다른 객체가 동일한지 확인할 때, 동등성 비교가 아닌 동일성 비교만으로 연산을 빠르게 처리할 수 있기 때문입니다.
그리고 자바에서는 String이 이러한 불변 객체의 특징을 가지고 있다고 알고 있습니다.

• 그렇다면 동일성과 동등성의 차이는 무엇인가요?

👉🏻 동일성은 참조 값을 비교하기 때문에, 두 객체가 실제로 정말 똑같은 것인지 확인하는 느낌이고 동등성은 오버라이딩된 equals 메서드를 통해서 논리적 동일성을 비교하는 것입니다. 즉, 같은 메모리 주소를 갖고 있지 않더라도, 동등성 비교를 통해서 논리적으로 두 객체가 동일한지 판단할 수 있습니다.

• equals를 오버라이딩해서 동등성 비교를 적용한 사례가 있는지?

👉🏻 출석 미션에서 크루의 이름을 기준으로 동등성 비교를 할 수 있도록 equals 메서드를 재정의 했던 경험이 있습니다.
요구사항에 따르면 캠퍼스 내부에 중복되는 이름을 갖는 크루는 존재하지 않으므로, Crew 객체를 비교할 때 name 필드를 기준으로 동등성을 비교할 수 있도록 equals 메서드를 재정의 했습니다.

• String 객체가 불변의 이점을 활용하고 있다고 하셨는데, 그렇다면 new String("a")가 할당된 서로 다른 두 변수의 동일성도 성립할까요?

👉🏻 이 경우에는 동일성 비교의 결과가 false로 나올 것 같습니다.
new 키워드는 인스턴스를 생성한다는 의미기 때문에, a와 b 각각에 서로 다른 인스턴스가 할당될 것 같습니다. 이는 곧 서로 다른 참조 값을 갖는다는 의미이므로, 동일성 비교 결과가 false로 나올 것 같습니다. 그 대신 new 키워드를 사용하지 않고 String 값을 직접 할당하는 경우에는 동일성 비교가 가능할 것 같습니다.

---

TDD

• TDD가 좋은 개발 방법론이라고 생각하시나요?

👉🏻 사람마다 느끼는게 다를 것 같은데, 단계별로 개발자의 관심사 분리가 가능하다는 점에서 저에게는 잘 맞는 개발 방법론이라고 생각합니다. 다만, 미션에서 TDD를 적용했을 때 개발 속도가 많이 느려져서 미션 진행에 영향을 주기도 했습니다.

✚ 현재 레벨1이 마무리된 시점에서 되돌아보면, TDD는 설계를 학습 과정에서는 매우 좋은 도구가 될 수 있다고 생각한다.

실제로 설계 능력이 갖춰지지 않은 상태에서, 설계를 하느라 오랜 시간동안 개발은 시작도 못하는 상태에 놓인 경우가 많았기 때문이다. 하지만 TDD는 일단 개발을 시작하게 만들고, 이후 주기적인 리팩터링 단계를 통해 설계를 완성하도록 안내해준다. 따라서 설계 능력이 부족한 시점에서는 좋은 학습 도구가 될 수 있다고 생각한다.

다만, 이미 좋은 설계 능력이 갖춰진 상태에서는 TDD를 굳이 쓸 필요가 있을까? 라는 생각이 들었다. TDD도 결국 개개인의 설계 역량에 따라서 결과물이 달라질 수밖에 없다고 느꼈기 때문이다. (= 설계 능력이 이미 좋지 않은데, TDD를 썼다고 해서 기존 역량보다 뛰어난 설계를 완성할 수는 없다고 생각한다)

• TDD는 시간이 오래 걸린다고 하셨는데, 그 이유가 무엇이라고 생각하시나요?

👉🏻 TDD는 각 사이클마다 refactor 단계를 포함하고 있습니다. 즉, 주기적으로 리팩터링 과정이 필요합니다.
그만큼 개개인의 설계 능력이 TDD 개발 시간에 영향을 줄 수밖에 없다고 생각합니다.

제가 생각하기에, 스스로 아직 설계 능력이 많이 부족한 것 같아서 그만큼 refactor 단계에서 많은 시간을 소요했던 것 같습니다. 이러한 부분이 개발 시간을 오래 걸리게 만든 원인이 아니었을까 생각합니다.

---

레이어드 아키텍처

• 레벨1에서 레이어드 아키텍처를 학습하게 된 배경

👉🏻 출석 미션에서 레이어드 아키텍처를 적용했었는데, 리뷰어가 이에 대한 리뷰를 남겨주셔서 레이어드 아키텍처에 대한 오개념을 재정립할 수 있었습니다.

이전에는 레이어드 아키텍처를 단순히 객체의 역할을 분류하기 위한 목적에서 사용하는 것으로 이해하고 있었습니다. 하지만 리뷰를 통해서 레이어드 아키텍처는 도메인 로직과 어플리케이션 로직을 분리하기 위해 등장한 것이며, 그렇기 때문에 어플리케이션 로직이 존재하지 않는 레벨1 미션에서는 레이어드 아키텍처가 불필요하다는 것을 깨달았습니다.

• 도메인 로직과 어플리케이션 로직이 무엇인지 설명해주세요.

👉🏻 도메인 로직은 요구사항을 충족하기 위해 반드시 필요한 로직입니다. 장기 미션을 예로 들면 장기 기물을 움직이는 것, 게임 결과를 계산하는 것 등이 있습니다.
어플리케이션 로직은 도메인 로직에 해당되진 않지만, 서비스 운영에 반드시 필요한 로직입니다. 예를들어 트랜잭션을 관리하는 것, DB 작업을 롤백하는 것 등이 있습니다.

• 실제 미션에서 레이어드 아키텍처를 적용했던 사례가 있나요?

👉🏻 출석 미션 step1에서 레이어드 아키텍처를 적용했다가, 관련 리뷰를 받은 후 도메인 로직만 남겼습니다.
그리고 아직 실제로 적용하지는 않았지만, 장기 미션 step2에서는 DB 요구사항이 추가됨에 따라서 레이어드 아키텍처를 충분히 적용해볼 수 있을 것 같습니다.

• 출석 미션에서 csv 파일을 읽어오는 부분도 어떻게 보면 외부와 상호작용하는 것, 즉 외부에 의존하는 것으로 볼 수 있지 않나요?

👉🏻 맞습니다.
해당 부분은 도메인 영역보다는 서비스 계층에 더 가깝다고 생각합니다. 실제로 미션에서 파일 입력 부분은 서비스 계층에 구현했습니다. (-> 이 부분은 실수로 잘못 답변했다. step1에서 서비스 계층에 넣었지만 리팩터링 과정에서 서비스 계층을 없애버려서, 최종 제출 코드에는 서비스 계층에 들어있지 않고 전부 도메인 계층에 있음 💦)

---

추상화

• 추상화가 무엇인지 설명해주세요. 객체지향에서 말하는 추상화는 무엇인가요?

제대로 답변하지 못 함 (너무 비유적인 표현으로 장황하게 설명해버렸다)

---

클린 코드

• 클린 코드에 대해서 알고 있나요?

클린 코드에 대해서 이야기는 많이 들어봤지만, 따로 추가적인 학습은 진행하지 않아서 잘 모르겠습니다.

---

제네릭

• 제네릭은 왜 사용하나요?

👉🏻 제네릭을 통해서 공통된 로직을 다양한 타입에 적용할 수 있기 때문입니다. List를 대표적인 예시로 볼 수 있습니다.

• 제네릭이 없었을 때는 어떤 식으로 코드가 작성되었을지 설명해주세요.

👉🏻 앞서 언급했던 리스트를 예시로 든다면, 타입마다 구현체를 모두 생성하면서 중복 코드가 증가할 것 같습니다.
예를들어 Integer 타입에 대해서 리스트 기능을 제공하는 구현체가 존재할 때, Integer가 아닌 다른 타입에 대해서도 완전히 동일한 기능을 제공하고자 하는 경우 로직은 동일하지만 타입만 다른 구현체를 계속 생성해야 하기 때문입니다.

---

싱글톤 객체

• 싱글톤 객체에 대해서 알고있나요?

👉🏻 레벨1 미션 과정에서 실제로 사용한 적은 없지만, 인스턴스가 하나만 존재하는 객체라고 알고 있습니다.

• 싱글톤 객체는 어떻게 만드나요?

👉🏻 싱글톤 객체를 만든 사례로는 볼 순 없지만, 프리코스에서 AppConfig 클래스를 만들면서 일반 객체를 싱글톤 객체처럼 사용했던 경험이 있습니다.

AppConfig 클래스 안에서 인스턴스 필드를 null 값으로 초기화하고, getter 메서드 안에서 해당 필드가 null 값인지 확인하는 방식입니다. 만약 null 값이라면 필드에 인스턴스를 할당한 후 리턴하고, null 값이 아니라면 기존에 할당되어있는 인스턴스를 리턴하는 방식으로 구현했습니다.

당시에 싱글톤 객체를 만드는 방법을 몰라서 이렇게만 설명하고 마무리했는데, 여기서 "싱글톤 객체는 어떻게 만들 수 있을지" 자바 개념을 토대로 스스로 추측할 수 있도록 질문을 더 끌어줬다면 좋았을텐데 하는 아쉬움이 남는다..

어느정도 고민하는 시간이 주어진 상태에서 논리적으로 생각해보면, static 필드의 특징을 토대로 해결책을 충분히 유추할 수 있지 않았을까 라는 생각이 들었기 때문이다. 여기에 static 관련 꼬리 질문도 가능했을 것 같고 ...

 

---

⛳️ 피드백 정리

옵저버 두 분이서 남겨주신 피드백 (상 - 학습 피드백 / 하 - 말하기 피드백)

 

옵저버뿐만 아니라 코치님한테도 공통으로 받았던 피드백은 답변할 때 자신감이 부족해 보인다는 것이었다. 특히, 긴장한 탓에 눈을 마주치면 답변을 못할 것 같아서 시선도 잘 마주치지 못했다. 이 부분은 다음 레벨 인터뷰까지 꼭 개선해야할 것 같다..

 

그리고 인터뷰를 통해 레벨1 과정에서 너무 미션에만 몰입하고 기술적인 학습이 조금 부족하지 않았나 싶다. 다음 미션부터는 추가적인 학습 계획도 세워봐야겠다.

 

 

인터뷰에서 조금 아쉬운 점은, 어려운 질문들이 앞 순서에서 이미 다 나와서 (나는 가장 마지막 순서) 내 차례 때는 생각보다 어려운 질문이 안 나왔다.

그리고 객체지향 설계 부분에서 내 철학은 어떻고 코드에는 어떻게 적용했는지 많이 이야기해보고 싶었는데, 대부분 개념 위주의 질문이어서 조금 아쉬웠다..! 사실 클린코드에 대해서 개념적으로 더 학습했다면, 클린코드 질문에 답변할 수 있었을 것이고 내가 원하는 방향으로 흐름이 충분히 이어졌을 것 같은데 많이 아쉽다.

 

그래도 다른 크루들의 순서를 지켜보면서도 혼자서 답변을 떠올려볼 수 있었고, 이 과정에서 내가 어느 부분이 부족한지도 알 수 있었다.

개념적으로 학습이 부족한 내용들은 추가로 학습한 후에 블로그 포스팅으로도 남겨보려 한다..!

 

✍🏻 느낀점

학습한 내용을 직접 코드에 녹여내는 것이 중요하다

기술의 등장 배경을 이해하면, 어떨 때 사용해야 하는지 알 수 있다