[우테코 5기] 레벨 1 레벨 인터뷰 정리 및 감정 회고

✔️ 레벨 인터뷰란?

드디어 레벨 1 방학 기간 동안 밀렸던 블로그 포스팅의 마지막, 레벨로그를 정리하고자 한다.
우테코에서는 매 레벨이 끝나면 조별로 '레벨 인터뷰'라는 것을 진행한다.
레벨 인터뷰는 각 레벨에서 학습한 내용을 인터뷰 형식으로 진행하는 말하기 활동으로서, 자신이 알고 있는 지식을 말로 표현하는 연습을 통해 메타인지를 기를 수 있다. (추후 기업의 기술 면접, 인터뷰에 대한 대비라고 봐도 좋다 😊)
 
그룹당 6-7명이 진행하며, 1명의 인터뷰어, 3명의 인터뷰이, 2-3명의 옵저버와 함께 진행한다.
한 사람당 총 인터뷰 20분, 그리고 피드백 10분씩 진행하는데 생각보다 이 시간이 되게 빠르다.
 
레벨 인터뷰는 총 2일간 진행되었으며, 나는 두 번째 날에 진행했기 때문에 첫 날은 재택을 했다.
코치는 브라운이었으며, 같이 진행할 크루는 라온, 아벨, 이레, 누누, 폴로, 허브였다.
 

Lv1 - 레벨 로그

이거는 제출했던 레벨로그 링크이다. 레벨 1의 미션에서 진행했던 학습 + 개인적으로 공부했던 내용들에 대해 작성하였다.
 

---

✔️ 레벨로그 준비하기

아래는 레벨 로그에 대해 정리한 내용이다. 아마란스와 바론 덕분에 조금 더 수월하게 정리할 수 있었다 🙇‍♀️
박스 안에 써있는 부분은 서로 질문을 주고받았을 때 내가 정리한 답변이다. 
이것저것 찾아보면서 정리한 내용 + 내 개인적 생각이라 다소 부정확할 수도 있지만 기록용으로 남겨두고자 한다.
 
 

💬 SOLID (객체지향 5대 원칙)

- SRP (단일 책임 원칙)
객체는 단 하나의 책임만 가져야 한다.
변화가 생겼을 때 하나의 클래스만 수정하면 되어서 유지보수가 쉬워진다.

- OCP (개방-폐쇄 원칙) → 추상화, 다형성
확장에는 열려 있고, 변경에는 닫혀 있어야 한다.
기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있다.

Q. Crystal Ball Problem이 뭔가요?

OCP는 변경에는 닫혀있지만, 확장에 열려있어야 하는 건데요! 
CBP의 경우 확장에는 열려있을 수 있지만, 실제로 OCP를 완전하게 만족할 수 있는가?에 대한 문제입니다! 
실제 구현 시에는 현재 프로그램이 어느 정도까지 확장될 수 있는지 전혀 예측할 수 없기 때문이에요 ㅎㅎ

 
- LSP (리스코프 치환 원칙) → 상속
하위 클래스의 인스턴스를 상위 클래스의 인스턴스 역할을 정상적으로 수행할 수 있어야 한다.
하위 클래스는 상위 클래스에서 정의한 메서드를 모두 구현해야 한다. = 다형성을 제공한다.
코드의 재사용성을 높일 수 있다. 유연성이 높아진다.
 
- ISP (인터페이스 분리 원칙)
클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 한다.
 
- DIP (의존 관계 역전 원칙)
추상화에 의존해야 하며, 구체화에 의존하면 안된다. 이를 지키면 결합도를 낮출 수 있어 코드의 유지보수성과 확장성이 높아진다.

Q. 의존 관계 역전 원칙을 지켰을 때 장점은 무엇인가요?

DIP는 추상 클래스나 인터페이스에 의존하여 클라이언트가 구체 클래스를 모르게 하는 것인데요! 
DIP를 지키게 되면 기본적으로 결합도가 감소합니다. 
만약 클라이언트가 parent라는 인터페이스를 가지고 있고, 자식으로 child1, child2라는 구체클래스가 있을 때 요구사항의 변경으로 인해 child2가 제거되었다고 생각해봅시당. 이때 child2를 외부에서 의존하고 있었다면 child2의 제거가 외부 로직에 큰 영향을 미치게 될 거예요! 만약 parent를 의존하고 있었다면 외부에서는 이러한 점을 모르기 때문에 변화에 유연하게 대응할 수 있다는 장점이 있을 것 같습니다 ㅎㅎ 그런 의미로 OCP에도 도움이 될 것 같아요.

Q. SOLID를 지켜서 더 객체지향적인 코드를 작성할 수 있게 되었던 경험이 있나요?

SOLID는 기본적으로 객체 지향 프로그래밍에서 요구하는 캡슐화, 추상화, 상속, 다형성 등을 더 잘 활용하기 위해서 지킬 수 있는 원칙입니다. 개인적으로 DIP를 지키면서 유지보수가 용이해졌던 경험이 있습니다. 하위 클래스를 클라이언트에 노출시키지 않고 상위 클래스에서만 노출시켜, 하위 클래스의 변화가 상위 클래스에 전파되지 않도록 해서 추후 변화가 생겼을 때 클라이언트 쪽 코드는 크게 건들 필요가 없었습니다.

 
 

💬 객체란?

객체는 협력적이어야 한다.
명령에 복종하는 것이 아닌, 요청에 응답을 해야 하며, 여기서 응답하는 방법에 대해서는 객체가 스스로 판단해야 한다.
또한, 객체는 자율적이어야 한다. 객체가 스스로 어떤 일을 결정해야 한다.
여러 객체는 동일한 역할을 수행할 수 있다. 여기서 말하는 역할은 대체 가능성을 의미하며, 각 객체는 책임을 수행하는 방법을 자율적으로 선택할 수 있다. 
 
 

💬 클래스란?

객체가 태어나는 곳. 인스턴스화를 할 수 있는 곳이라고 할 수 있으며, 클래스는 새로운 객체를 생성하고 더 이상 사용하지 않을 때 객체를 파괴하는 책임을 가진다.

 

💬 MVC 패턴

Q. MVC 패턴에서, 사용자의 입력이 처리되는 과정을 각 요소의 역할이 드러나도록 설명해주세요.

사용자의 입력이 View를 통해 처리되고, 중개자인 controller가 입력에 대한 변화를 받아 domain에게 부여하여 비즈니스 로직을 처리할 수 있게 됩니다. MVC 패턴을 사용하게 되면 각각의 계층에 대한 역할이 구분되어지기 때문에 결합도가 낮아져서 유지보수가 편해질 것 같습니다!

- Model
처리해야 하는 데이터의 모음.
뷰와 컨트롤러에 의존해서는 안 된다.
 
- View
사용자 인터페이스 요소 입, 출력을 관리한다.
모델의 정보를 따로 저장하지 않고, 단순히 명령을 받았을 때 역할만을 수행해야 한다.
또한, 다른 요소는 참조하거나 동작하는지 알아서는 안 된다.
 
- Controller
데이터와 사용자 인터페이스 사이를 잇는 역할.
모델과 뷰의 변경을 모니터링하면서, 서로 변경 통지를 받았을 때 각각에 대해 통보하는 용도.

Q. 뷰와 도메인은 왜 상호 의존을 하면 안 될까요?

 뷰는 비교적 변경이 잦은 부분입니다. 만약 뷰의 변화가 도메인에 영향을 주게 된다면 핵심 로직인 도메인이 상당히 잦은 변화를 가지게 될 거예요. 추가적으로 도메인이 뷰를 알고 있게 된다면 사용자에게 제공되는 부분을 비즈니스 로직에 집중하고 있는 도메인이 알게 되면서 도메인이 가지고 있는 역할과 책임이 너무 많아질 수 있다는 단점이 존재합니다! 같은 이유로 뷰 역시 도메인을 의존해서는 안 됩니다. 같은 의미로 SRP 관점에서 봤을 때 서로가 가지고 있는 역할과 책임이 분명하기 때문에 의존성을 낮추는 것이 중요합니다.

 
 

💬 원시값 포장

Q. 원시값 포장을 해야 하는 이유와 주의할 점이 있다면 무엇인가요?

원시값 포장을 무조건 해야 한다고 생각하지는 않습니다. 단순히 값 객체 자체를 포장만 한다면 오히려 객체 생성 비용이 더 클 수 있기 때문입니다. 다만, 객체로서 관리해야 하거나 해당 값이 다른 객체의 필드로서 관리될 때 검증 로직이나 다른 로직이 들어있다면 해당 객체의 책임을 덜기 위해서 원시값 포장을 사용할 수 있을 것 같습니다. 또한, 불변성을 보장하도록 만들 수도 있을 것 같아요.

 
 

💬 정적 팩터리 메서드

Q. 팩토리 메서드 패턴과 정적 팩토리 메서드의 차이는 뭔가요?

팩터리 메서드 패턴의 경우 디자인 패턴이고, 정적 팩터리 메서드는 클래스의 인스턴스를 반환하는 정적 메서드입니다.
팩토리 메서드 패턴은 팩토리 메서드를 확장성 있게 사용할 수 있는 방법의 일종이고 정적 팩토리 메서드는 자바에서 구현할 수 있는 팩토리 메서드의 방법 중 하나입니다!

Q. 단순히 생성자를 사용해서 만드는 것과 무슨 차이가 있을까요? 사용하는 것이 반드시 좋을까요?

꼭 좋다고 생각하지 않습니다. 생성자는 항상 new를 통해 새로운 인스턴스를 반환하지만, 정적 팩터리 메서드의 경우 캐싱 등을 활용하여 무조건 새로운 인스턴스를 반환하지 않도록 제어할 수 있습니다.
하지만, new를 통해 객체를 명시적으로 생성하는 생성자와 달리 정적 팩터리 메서드를 사용하면 네이밍이 자유롭기 때문에 객체의 생성이 어디에서 일어나는지 협업 관점에서 잘 확인하기 어려울 수 있습니다.
또한, static 메서드 선언이기 때문에 메모리적 관점에서도 문제가 있을 것 같습니다.

 

💬 Checked Exception vs Unchecked Exception

Checked Exception은 Exception을 상속하며, 컴파일 시점에 Exception을 catch 하는지 확인한다.
컴파일 시점에 Exception에 대해 처리하지 않으면 에러가 발생한다. (throws로 던지거나, 잡아서 처리하거나)
Unchecked Exception은 RuntimeException을 상속하며, 컴파일 시점에 Exception을 catch 하는지 확인하지 않는다.
잡아서 처리할 필요가 없다.

- 예외 처리의 5가지 방법
복구 : 예외가 발생했을 때 정상 상태로 되돌리기
회피: thorws를 통해서 던진다. 단, 이 경우는 명확한 이유가 있어야 한다.
무시: 아무 처리도 하지 않고 단순히 catch를 해준다. 이것 역시 명확한 이유가 필요하다. 혹은, 단순히 로깅하는 경우도 이에 포함된다.
전환: RuntimeException으로 바꾸어서 던질 수 있다. 이렇게 되면 그 다음 호출 체어에서는 예외에 대해 처리를 해줄 필요가 없기 때문에 비즈니스 로직이 더 명확해진다는 장점이 있다.

Q. 두 가지 중에서 어떤 상황에서, 어떤 것을 사용할 것인가요?

저는 checked exception은 웬만하면 unchecked exception으로 감싸서 처리합니다. 
예외가 발생한 곳은 해당 발생 지점에서 처리하고, 외부로 전파시킬 경우 비즈니스 로직에도 예외 관련 코드가 들어가면서 코드 자체가 알아보기 힘들어질 때가 있기 때문입니다. 
또한, 스프링에서도 checked exception은 트랜잭션이 롤백되지 않기 때문에, 예외 상황에서 명시적으로 unchecked Exception을 발생시켜 예상치 못한 오류가 발생하지 않도록 하는 편입니다. (기본적으로 '예외'가 발생한 상황은 정상 실행 흐름이 아니기 때문에 트랜잭션 내부에서 실행된 행위에 대해서 다시 복구를 시키는 게 의미론적으로 맞다고 생각합니다.)

 

💬 불변 객체

불변 객체는 항상 동일한 값을 반환하는 것이 아니다. 불변 객체는 내부 상태를 변경하지 않는다는 것이다. 캡슐화되어 있는 본인의 상태를 변경하는 것도 아니고, 어떠한 특정한 것을 가리키고 있는 것도 아니다.
    
- 불변 객체는 어떻게 생성할 수 있을까?
먼저, 간단하게 final 키워드를 생각할 수 있다. 자바에서 변수는 기본적으로 가변적이기 때문에, final을 통해서 변수에 대해 변경 불가능하다고 선언할 수 있다. 이렇게 되면 컴파일 타임에 해당 변수가 변화하는 것을 캐치할 수 있다.
하지만, final 키워드는 단순히 변수의 참조값을 바꾸지 못하도록 막는 것뿐이다. collection이나 custom 객체의 참조를 통해 우리가 내부 상태를 변경하는 것 자체는 막을 수 없다.
 
두 번째로, 객체에 대해서 불변을 유지하기 위해서는 우리가 직접 내부 필드를 private로 감춘 다음에, 해당 필드에 대해서 수정자를 없애는 방식이 있다. 또한, 외부로 필드를 꺼내올 때 (getter) 동일한 주소값을 가지지 않도록 참조값을 변경하기 위해서 새로운 객체를 할당하여 반환할 수 있다. 만약 컬랙션이라면 new ArrayList<>()를 활용하여 원본 객체와의 주소 공유를 끊을 수 있다.
        
하지만, 이는 깊은 복사라고 할 수 없다. 깊은 복사의 경우 원본과 복사본의 모든 요소들에 대한 주소가 달라야 하지만, 방어적 복사는 단순히 해당 객체를 담고 있는 컬렉션의 주소만 다르고 내부 요소들의 주소는 동일한 곳을 가리키고 있다. 그렇기 때문에, 원본 객체를 가지고 어떠한 생성자에게 주입해서 해당 객체를 생성했을 때, 원본 객체에 변화를 주게 되면 복사본의 내부 값도 바꾸게 되는 것이다.
    
- 방어적 복사와 깊은 복사
만약 Unmodifiable Collection을 활용한다면 어떨까?
이는 내부적으로 set, add 같은 메서드를 호출하게 되면 UnsupportedOperationException이 발생하게 되며, 읽기 전용으로 만들어준다. 그렇다고 해도, 사실 이 역시 불변을 보장해주지는 않는다. 여전히 내부적으로 해당 리스트는 원본 리스트를 참조하고 있기 때문에 원본에 변화가 생기면 해당 리스트도 변환이 발생한다.

완전한 불변을 하고 싶다면, List.copyOf를 활용하거나(내부적으로 `ImmutableCollections`을 활용한다) Unmodifiable Collection을 한 번 더 new ArrayList<>로 감싸야 한다.

Q. 불변을 만족하면 무엇이 좋나요?

thread-safe를 만족하게 됩니다! 처음 생성 이후에는 객체 내부의 상태가 변화하지 않기 때문에 객체의 생성 시에 오류가 발생하면 해당 객체 자체를 생성하지 않을 수 있습니다. (실패 원자성 보장)
추가적으로 불변하기 때문에 다른 객체에 의존하지 않게 되어 예상치 않게 수정되는 일을 막을 수 있습니다!

    
💬 상속과 조합

상속은 부모 클래스를 자식 클래스가 extend 하는 것으로, 부모 클래스가 할 수 있는 일을 물려받게 된다.
단, 물려 받은 일을 수행하는 방식은 스스로 변경할 수 있으며 때에 따라 추가적인 일을 할 수도 있다.
단, super() 로 인해 부모 클래스의 속성을 알게 되기 때문에 캡슐화가 깨진다.
    
조합은 한 객체가 자신이 할 수 있는 일을 하는 객체를 인스턴스 변수로 가지는 것이다.
이미 외부에서 만들어진 객체를 주입 받기 때문에, 해당 객체에서 제공하는 공개된 동작만 사용할 수 있다. 

Q. 상속과 비교했을 때 조합이 가지는 장점과 단점은 무엇이 있나요?

조합을 사용하게 되면… 우선 상속이 가지고 있는 문제를 해결할 수 있을 것 같습니다.
상속은 기본적으로 부모 클래스와 자식 클래스 사이의 강결합이 문제점으로 볼 수 있는데요!
부모 클래스의 변화가 자식 클래스의 변화까지 이어집니다. 하지만 조합을 사용하게 된다면 조합으로 가지고 있는 클래스의 내부 사항이 변경되더라도 이를 감싸고 있는 클래스는 영향을 받지 않을 것 같아요.
다만, 조합을 사용하게 되면 결국 인스턴스 필드로 관리해야 하기 때문에 해당 객체에서 관리해야 되는 책임이 많아지게 됩니다.

상속은 행동 호환성을 만족할 때 = 완전히 대치될 수 있을 때 = is-a 관계일 때 사용하는 것이 좋습니다.
즉, 부모 클래스의 타입으로 자식 클래스를 사용해도 괜찮을 때 사용하면 좋을 것 같습니다.

 
 

💬 do-while 구조

Q. 선언과 초기화가 떨어져있을 때 어떤 점이 안 좋을까요?

선언부 이전의 어떠한 로직이 들어온다면 NPE가 발생할 수 있습니다.
null 체크 로직이 들어가야 하며, 코드 가독성의 측면으로 봤을 때 좋지 않습니다.
또한, 초기화와 선언이 붙어있는 형태라면 레거시 코드에서 변수에 대한 변화를 추적하기가 쉽다는 장점이 있습니다!

 
 

💬 전략 패턴

전략 패턴은 객체 지향 프로그래밍에서 사용하는 디자인 패턴 중 하나로, 실행 중에 알고리즘을 선택할 수 있도록 한다.
보통 상속을 이용해 구현하며, 각각의 전략 객체를 정의한 다음 클라이언트가 적절한 전략 객체를 선택하여 실행하도록 만든다.

Q. 테스트 코드를 작성할때, 전략패턴을 적용하기 전엔 어떤 문제가 있었고 어떻게 개선했는지 경험에 기반해서 얘기해주세요.

저는 전략 패턴을 사다리 게임에서 사용했었는데요! 사다리의 선을 만들 때 true - false를 랜덤으로 제너레이팅하여 선을 만들지 말지를 결정했습니다. 하지만 테스트 코드를 작성 시 랜덤하게 동작하는 부분에 대해서 제가 직접 수정할 수 없었기 때문에 제너레이터에 대한 인터페이스를 생성하고, 테스트 시에 항상 같은 값을 반환하는 인터페이스의 구현체를 생성하여 실제 비즈니스 로직에서는 랜덤하게, 테스트에서는 원하는 값이 나오도록 설계하여 TDD 시 더 원활하게 진행할 수 있었습니다!

💬 String pool

String pool은, JVM에서 String 객체를 메모리에서 관리하기 위한 일종의 '저장소'이다.
'new'를 통해 생성한 String 객체는 heap 영역에 저장되고, 리터럴로 생성한 객체는 'String pool'에 저장한다.
이때, String pool은 Heap 내부에 존재하며, JVM 이 시작될 때 생성되고, 클래스 파일이 로드될 때 초기화된다.
그렇기 때문에 프로그램이 실행될 때마다 새로운 String pool이 생성되는 것이 아닌, JVM이 시작될 때 한 번 생성되고 그 이후로는 계속해서 재사용된다. 리터럴을 활용하게 되면 이미 존재하는 값이 있을 때 해당 값을 가리키도록 한다.

Q. String pool을 사용하는 이유는 뭔가요?

string은 정말 많이 사용하는 클래스입니다. 하지만 new를 통해서 계속 생성하게 된다면 heap에 저장되면서 메모리의 문제가 발생할 수 있습니다! 반면, string pool을 사용하게 된다면 이미 존재하고 있는 객체에 대해서 재사용을 할 수 있기에 메모리 측면에서 이득을 볼 수 있습니다. 

💬 Try-With-Resources

Q. try-with-resources은 이전에 사용되었던 자원반환 방법에 비해 어떤 장점이 있나요?

이전에는 개발자가 직접 finally 구문에서 close를 통해 명시적으로 닫아줘야 했습니다! 개발자가 직접 작성하는 부분인 것만큼 예상치 못한 리소스 누수가 생길 수 있었다는 게 단점인데 try-with-resources를 사용하면 개발자가 그걸 신경쓸 필요 없이 알아서 close를 호출해주기 때문에 비교적 관리해야 하는 포인트가 줄어들게 됩니다! 

Q. 그럼 개발자의 실수를 방지할 수 있다는 것 외에는 다른 장점은 없나요?

그외에는 코드가 간결해진다는 장점이 있습니다. 만약 try 구문 내에서 또 다시 리소스 할당이 발생할 수 있는 지점이 발생한다면 depth가 매우 커질 텐데 try-with-resources을 사용하면 처음에 한 번에 쓸 자원들에 대해서 열어줄 수 있습니다.
또한, 상위에서 오류가 발생하더라도 finally에서 오류가 발생한다면, finally에서 발생한 오류만 남게 되어서 상위의 오류를 잡아먹히게 되는데 suppressed exception를 활용하여 이러한 부분을 해결할 수 있습니다.

💬 인터페이스 vs 추상 클래스

Q. 인터페이스와 추상클래스 중 어느 것을 사용하는 것이 더 좋다고 생각하시나요?

상황에 따라 다르지만 저는 개발적인 관점에서 보았을 때 별도의 관리해야 하는 필드가 필요하다면 추상 클래스를, 하나의 객체가 다양한 행위를 해야 할 때 (= 다중 상속이 필요할 때) 인터페이스를 사용하는 것이 좋다고 생각합니다. (둘이 동일한 역할을 해야 한다고 가정)

또한, 객체와 객체 사이의 관계성이 아닌 객체가 해야 하는 행동 규약을 정의할 때는 인터페이스를, 객체의 상태와 밀접하게 연관도니 객체라면 추상 클래스를 사용하는 편입니다.

'a는 b에 속한다' 라는 개념이라면 추상 클래스를 (여러 개에 속할 수 없는 상황일 때), 'a는 b를 할 수 있다'라는 개념이라면 인터페이스를 사용할 수 있다. 만약, 다중에 대한 개념을 제외하고 단일적인 관점에서 본다면 '연관이 되어 있는지, 그리고 할 수 있는지' 이 2가지 관점으로 바라볼 것 같습니다!

---

✔️ 레벨 인터뷰 후기

레벨 인터뷰를 준비하면서 인터뷰어 2번, 인터뷰이, 옵저버 3번 이런 식으로 진행했다.
우리는 코치님이 인터뷰어로 계속 참여했기 때문에 인터뷰이 입장에서는 3명의 인터뷰어와 3명의 옵저버를 상대해야 했다 💦

딱 이런 배치도였다. 굉장히 압박면접 같은 배치도였다... ㅎ
 
 

🌱 인터뷰어로 느낀 점

처음 시작했을 때 인터뷰어로 진행을 했었는데, 인터뷰어 입장에서는 그렇게 떨리지 않았다.
오히려 질문하는 게 재밌었다... (죄송합니다 ㅎ)
인터뷰이가 준비한 레벨 로그를 읽으면서, '나는 이렇게 생각하는데, 인터뷰이는 어떻게 생각할까?'라는 마음 가짐으로 질문했다.
특히 혼자 공부하면서 잘 몰랐던 부분이나 애매했던 부분, 그리고 의견을 나누고 싶은 부분에 대해서 질문을 드렸었는데,
인터뷰이가 답변하는 내용을 들으면서 내 생각도 정리하고, 타인의 의견을 들을 수 있었어서 좋았다.
인터뷰이로서 얻어가고 싶다면 단순히 개념에 대해서 질문하는 것보다는, 상대가 질문에 대한 본인의 생각을 풀어나갈 수 있도록 의도하는 게 중요하다는 생각이 들었다.
 
그러면서 동시에, 면접관은 면접자를 공격하려는 의도가 아니라, 정말 이거에 대해 어떻게 생각하고, 질문에 대한 본인의 의견을 확립하고 있는지 알아보려고 질문하는구나... 싶었다. 면접자가 잘못된 의견을 말하더라도, 그에 대해 본인만의 명확한 사고를 가지고 있고, 어떻게 해서 그런 의견으로 도출했는지 설명할 수 있다면 좋을 것 같다.
물론, 이 과정에서 면접관이 잘못된 것에 대해서는 짚어주는 게 맞다고 생각한다. 다만, 직접적으로 짚어줄 필요는 없다.
왜 면접에서 꼬리질문을 하냐면, 연쇄적인 질문을 통해 본인의 개념이 어느 순간 어긋난 걸 면접자 자신이 파악할 수 있기 때문이다.
면접을 통해서 본인이 명확하게 알고 있는 것, 그리고 잘 모르는 것에 대해서 파악하는 것 (=메타인지)이 면접의 순기능일 것 같다.
 

 
🌱 옵저버로 느낀 점

사실 인터뷰어로 있을 때는 인터뷰이가 말하는 답변 내용을 상세하게 적으려고 노력했었다. 
글로 적으면서 상대가 답변한 것의 의도를 파악하고, 이에 대해 다시 질문을 던질 수 있기 때문이다.
하지만 옵저버로 있을 때는 인터뷰이의 대답, 그리고 태도까지 한 번에 봐야 했어서 20분이 정말 빠르게 지나갔다.
동시에, 인터뷰어가 어떤 질문을 하는지도 파악해야 했다. (그래서 더 힘들었던 것 같다 ㅎㅎ)
 
그래도 옵저버는 해당 인터뷰 과정에서 제외된 사람이기 때문에 인터뷰이에게 직접적으로 질문을 던질 수가 없어서, 인터뷰어가 한 질문 중에 내가 잘 모르는 개념도 종종 존재했었는데 이에 대해 중간중간 메모할 수 있었어서 좋았다. (특히 허브가 인터뷰어일 때 옵저버였었는데, 허브의 질문이 엄청 날카로워서 놀랐다... 내 인터뷰어가 아니었어서 정말 다행 ㅎ...)
 
또한, 배우고 싶었던 인터뷰이의 태도도 있었다.
인터뷰어와 인터뷰이가 서로 인터뷰를 하는 것보다는, 개발자로서 대화 나누는 것처럼 편한 분위기를 조성해준 인터뷰이도 있었다.
긴장되는 상황임에도 계속해서 인터뷰어를 바라보면서 대화를 한다든지, 적절한 제스처를 사용한다는지... 저마다의 방법들을 지켜보면서 내가 인터뷰이가 되었을 때 어떤 태도를 가지면 좋을지도 배울 수 있던 시간이었다.
 
 

🌱 인터뷰이로 느낀 점

나는 세 번째 차례였기 때문에 비교적 긴장을 떨칠 수 있을 줄 알았지만... 아니었다 🥲
처음 인터뷰이 자리에 앉았을 때 매우, 무척 떨렸다. 
특히 브라운이 String pool의 내부 동작에 대해서 여쭤보셨을 때는 잘 모르는 내용이라 당황했었는데, 내 나름대로 주관을 가지고 대답을 하니까 어떻게든 잘 넘어가게 되었다.
인터뷰를 할 때 한 가지 지킨 점은, 질문이 모호하다고 느껴지면 무조건 역질문을 진행하는 것이었다.
(제가 질문을 ~~ 이렇게 받아들였는데, 맞나요?)
그러면 인터뷰어가 이에 대해 대답하는 순간에도 내가 할 말을 정리할 수 있어서 좋았다. (일종의 시간 벌기...?)
그리고, 질문이 길어지면 최대한 나눠서 대답하려고 했다. + 두괄식 표현도 지키려고 노력...
 
사실 20분이 어떻게 지나간지 모를 정도로 확 지나갔다.
그래도 다들... 좋은 피드백을 해주셨다. 피드백 내용은 아래와 같다.
 

🌱 이번 레벨 학습 측면에서 좋은 점과 부족한 점은?

- 학습한 부분에 대한 것은 생각이 이미 잘 정리가 되어있는 것으로 느껴져서 좋았습니다.
- 궁금한 점에 대해서 바이트 코드도 뜯어보시고, 깊이있는 학습을 했다는 것이 잘 느껴졌습니다.
- 단일 책임 원칙에 대한 자동차 예시가 좋았습니다. try-with-resources를 매우 구체적으로 설명해주시는 부분이 좋았습니다.

 

🌱 인터뷰, 말하기 측면에서 좋은 점과 개선할 부분은?

[좋은 점]
- 어떤 부분을 설명할 때, 단계적으로 어떤 부분의 설명이 필요한지에 대한 부분을 인지시켜주는 방식이 굉장히 좋게 느껴졌습니다. 그리고 실시간으로 생각이 필요한 부분에서도 어떻게든 방향을 잡고 결론으로 가는 모습이 인상깊었습니다.

- 질문을 받으면, 어떤 질문인지 자신이 이해한 바를 먼저 설명하고 시작해서 좋았습니다. 전반적으로 미션마다 무엇을 배웠는지, 깊이있는 학습 경험이 구체적으로 잘 드러난 것 같아요. 초반에 SOLID원칙을 언제 적용하려고 했고 무엇을 느꼈는가에 대한 질문에서, 자동차 미션을 진행하며 받은 리뷰를 기반으로 SOLID원칙을 적용하게 되었고 특히, 스트링 풀의 작동 구조에 대한 질문이 당황스러울만도 한데 유연하게 잘 대처하신 것 같습니다. 전반적으로 개선점을 찾지 못한, 좋은 인터뷰였다.

- 자기의 주관을 매우 조리있게 말한다. 설명할 때 생각에 대한 이유, 근거, 예시가 있어서 좋았습니다. 갑작스러운 질문에 대해 대처를 굉장히 잘하시네요. 질문의 의도를 다시 한 번 확인하는게 대단한 것 같습니다.

[개선할 점]
- 목소리가 좀 더 컸으면 좋겠습니다.
- 목소리가 약간만 더 컸다면 져니의 의견을 더욱 잘 들을 수 있을 것 같습니다.

 
적어놓고 보니 너무 칭찬이 가득해서 민망하다... 🫠 사실 우리 인터뷰조 분들은 다들 엄청 잘하셔서 나도 칭찬만 드리긴 했다 ㅎㅎ
목소리 크기는 앞으로도 유의해야겠다. 사실 긴장하면 말이 빨라지게 되어서, 이 부분을 고치기 위해 천천히 말하려고 노력하다 보니 목소리 데시벨도 함께 작아졌었는데 어떻게... 잘 고쳐봐야하는 부분 중 하나이다.
 
인터뷰를 진행하면서 시작과 끝이 잘 맞지 않은 대답도 꽤 존재했던 것 같은데, 어떻게든 문장을 마무리하려고 하다 보니깐 그런 점들은 비교적 약하게 느껴졌던 것 같다. 인터뷰할 때 가장 중요한 점은 질문에 대한 의도 파악 및 말하는 문장에 대한 마무리인 것 같다...!
 

---

✔️ 감정 회고

우테코의 레벨 1 과정이 끝났다. 벌써 한 달이 넘은 시간이 흘렀다는 것이겠지...
우테코는 올해 선택한 일 중에서 가장 후회없는 선택 중 하나인 만큼, 내게 많은 영향을 주고 있다.
공부를 할 때든, 무엇을 하든 나는 상대한테 배우는 입장이었는데 우테코에 와서 서로에게 배우고, 알려주는 관계가 될 수 있다는 사실 하나가 나에게는 긍정적인 영향을 주었다. 뭐든 일단 배우고 나면 어떻게든 깨부가 된다는 사실을 일깨워준 것 같다.
뭔가 내가 남한테 도움을 줄 수 있다는 그 사실 하나만으로 공부를 계속해서 하게 만드는 것 같다.
 
또한, 크루들이 정말 친절하다. 다들 열정적이기도 하고, 아닌 척해도 질문하면 본인 일인 것처럼 대답을 해주신다.
그리고, 내가 모르는 점이 있다는 사실에 부끄럽게 받아들이지 않도록 만들어준다.
모른다고 절대 나쁘게 보지 않고, 본인이 생각하는 의견과 다르더라도 우선 상대의 의견을 차분하게 들어준다.
그러면서 본인의 의견을 부드럽게 표현해준다. 설득당하는 상대방의 기분이 나빠지지 않도록, 본인의 생각을 조리있게 말하는 게 참 좋았다.
내가 잘 모르는 것에 대해 부끄러워하지 않도록, 같이 배워나갈 수 있는 사람들이라서 너무 좋다 😎
 
물론 불안한 날들도 많다. 레벨 1 과정은 자바부터 다시 시작하기 때문에 이전에 했던 스프링이나 JPA 관련 지식들이 휘발됐기 때문이다.
(근데 애초에 휘발 안 될 만큼 제대로 공부하지도 않음 == 팩트)
근데 차라리 밑바닥부터 다시 시작하니까 마음은 편하다. 다 새롭게 배워가는 느낌이다.
선택과 집중을 잘할 수 있도록 하는 것 같다. 나는 레벨 1 기간 동안에는 자바 외에 다른 것들에 대해서는 아예 신경을 껐다.
옛날에는 뭐든지 잘하고 싶었는데, 요즘은 그냥 내가 공부한 부분만큼만이라도 잘하자는 생각만 든다.
 
방학 기간도 그래서 스프링이나 db나 아예 손대지도 않았다. 걍 레벨 2 때 하지 뭐... ㅎ
그냥 레벨 1 기간 동안에 했던 것들 회고 글 쓰는 거 하나로 목표로 잡았다. 회고 다 써서 마음이 편하다 ㅎㅎ
레벨 2 때는 조금 더 부지런하게 살아봐야겠다. 아자아자...!