레벨1에서 학습한 내용을 한 장 내외로 요약해서 작성했다.

레벨 인터뷰의 목적은?

레벨 인터뷰 사전 문서를 작성하면서 이걸 왜 해야 하는지에 대해 한 번 생각해봤다.

레벨 1을 끝내며 내가 아는 것과 모르는 것을 정리하는 메타인지의 시간이 아닐까?
그리고 내가 '안다고 생각하는 것'을 진짜 알고 있는지는 인터뷰를 통해 검증하는 과정인 것 같다.

인터뷰를 하기 전 마음가짐

인터뷰이는 을이 아니다. 인터뷰어가 미래에 함께 일할 동료라고 생각하고, 서로 의사소통이 원활한 사람인지 판단하는 시간이라는 마음으로 임하자.

• 항상 질문 다시 하기
  • 질문을 제대로 이해했는지, 최소한 내가 이해한 대로 질문을 다시 말해보기.
• 서둘러 답변하지 말고, 잠시 말을 멈추고 생각하기
  • 빨리 대답하는 것이 중요한 것이 아니라, 좋은 대답을 하는 것이 중요하다.

[미션]

🚀 싱글톤 VS 컴포넌트 내부 상태 전달

둘 다 사용해본 결과,

• 싱글톤은 상태 접근이 편리하지만, 사용 위치가 불분명해 관심사 파편화를 유발할 수 있었다.
• 컴포넌트 상위에서 상태 관리는 Props Drilling이 발생할 수 있지만, 상태의 위치와 책임이 명확했다.
• 결론적으로 명확한 책임 분리와 캡슐화를 위해 후자의 방식을 선택했다.

🚀 함수형 컴포넌트 VS 클래스형 컴포넌트

컴포넌트 자체의 역할은 UI 렌더링이라고 생각했기 때문에,

• 함수형 컴포넌트를 선택해 코드의 간결함과 가독성을 높였다. 상태 관리는 컴포넌트 외부의 클래스에 위임해 관심사를 분리했다.
• 다만, 상태와 로직을 함께 묶어 응집도나 구조의 일관성이 중요한 상황에서는 클래스형 컴포넌트도 고려할 수 있다고 생각한다.

🚀 도메인 로직이 UI 로직에 왜 의존하면 안되는 이유

• 로또 미션처럼 UI는 요구사항이나 환경에 따라 얼마든지 변경될 수 있다.
• 하지만 도메인 로직은 그와 무관하게 일관되게 유지되어야 한다.
• 만약 도메인 로직이 UI에 의존한다면, UI가 바뀔 때마다 로직도 수정해야 하므로 재사용성과 유지보수성이 떨어진다.
• 따라서 도메인 로직은 UI로부터 분리해 독립적으로 설계하는 것이 바람직하다고 생각한다.

[OOP, 객체 지향 설계]

🚀 클래스를 써야만 OOP일까?

• OOP의 핵심은 역할, 책임, 상호작용이라고 생각한다.
• 이 세 가지를 만족해야 한다고 해서 반드시 클래스를 써야 하는 것은 아니다.
• 함수와 클로저만으로도 객체지향적인 설계는 충분히 가능하다.
• 클래스는 단지 상태와 동작을 함께 묶어 응집도를 높이기 좋은 도구일 뿐이라고 본다.

🚀 명령형 VS 선언형

• 명령형과 선언형의 차이는 관심사의 분리로, 명령형과 달리 선언형은 무엇을 할지만 표현하고 어떻게 할지는 감춘다.
• 하지만 단순한 추상화만으로는 선언형이 될 수 없고, ‘지연 실행’이 핵심이라고 생각한다.

🚀 클래스가 적은 필드를 가지게 하는 방법은?

• 필드가 많다는 건 클래스가 여러 책임을 가질 수 있다는 얘기이다.
• 그래서 기능이나 관심사에 따라 필드를 묶거나 분리할 기준을 세우는 것이 중요하다.
• 예를 들어, ‘점심 뭐 먹지’ 미션에서 음식점 클래스가 여러 상태(거리, 이름, 설명, 링크 등)를 가진 상황이 있었다. 이때 모든 상태를 하나의 클래스에 담기보다는, 상태의 필수 여부에 따라 클래스를 분리하는 것이 좋은 방법이라고 생각한다.

[TDD & 테스트]

🚀 TDD를 하면 뭐가 좋을까?

• 작은 단위부터 목표를 향해 점진적으로 개발할 수 있어, 방향성을 잃지 않고 안정적으로 구현할 수 있었다.
• 테스트가 즉각적인 피드백 루프 역할을 해줘, 오류에 대한 불안 없이 자신 있게 개발할 수 있었다.
• TDD로 작성한 테스트 코드는 단순한 검증 도구를 넘어, 기능을 설명해주는 문서로도 활용할 수 있었다.

🚀 테스트를 하는데 의존성 때문에 테스트가 어렵다면 어떻게 해야 할까?

• 테스트가 어렵다는 건 의존성이 높거나 책임이 분리되지 않았다는 신호였다.
• 의존되는 값을 인자로 주입하거나 외부로 분리하면 테스트가 쉬워졌다.
• 클래스의 경우, 인스턴스 초기화부터 테스트에 포함하면 this 사용 메서드도 테스트 가능하다.
• 테스트하기 쉬운 구조 = 잘 설계된 구조라는 점을 깨달았다.

[자바스크립트 개념]

🚀 일반 함수 VS 화살표 함수

• this 차이
  • 일반 함수: this는 호출 시점에 따라 동적으로 결정된다.
  • 화살표 함수: this는 선언 시점에 결정되며, 상위 스코프의 this를 렉시컬하게 바인딩한다.

[소프트웨어 스킬]

🚀 늘어나는 학습량을 관리하는 방법

• 문제 상황: 배울 것이 계속 쌓이다 보니, 미루기 시작하면 결국 공부하지 않게 되었다.
• 해결 방법
  1. 절대적인 시간을 계산하기
  2. 학습 키워드를 구체적으로 변경하기

🚀 페어 프로그래밍 할 때, 실력에 상관없이 함께 성장하는 방법

• 페어 피드백은 미션이 끝난 뒤보다 진행 중에 주고받는 게 더 솔직하고 의미 있었다.
• 실력이 더 뛰어난 사람은 키보드를 덜 잡고 네비게이터 역할을 길게 맡는 방식이 효과적이었다.
• 이렇게 하면 실력이 부족한 사람도 흐름을 이해하며 따라갈 수 있고, 역할을 바꿔도 자연스럽게 이어갈 수 있었다.