20240502 (목) 오랜만에 적는 모의면접 일기 - 인텔리픽 모의면접

5월 2일자 인텔리픽 모의면접 받은 질문들과 그때 제대로 답변하지 못했던 것들을 정리하기 위한 면접 질문지

 

1. 자기소개

 

2. 최종프로젝트에서 맡은 부분과 그 부분에 대한 설명

 

내가 맡은부분 + 그 기술이 필요했던 이유 + 많은 기술중 그 기술을 고른 이유

 

3. 인터페이스와 추상클래스의 차이

 

코틀린의 인터페이스와 추상 클래스는 주로 사용 목적과 상태 관리 방식에서 차이가 나타납니다. 다음은 그 차이점을 간결하게 정리한 내용입니다:

1. 목적:

-인터페이스: 다양한 구현을 가능하게 하고 다중 상속을 지원하여 유연성을 제공합니다.

-추상 클래스: 공통의 코드와 상태를 재사용하고자 할 때 사용되며, 부분적으로 구현된 상태로 존재할 수 있습니다.

2. 상태 관리:

-인터페이스: 상태(필드)를 직접 유지할 수 없습니다. 속성은 추상이거나 커스텀 게터를 통해 제공되어야 합니다.

-추상 클래스: 상태(필드)를 유지할 수 있고, 생성자를 통해 초기 상태를 설정할 수 있습니다.

3. 구현과 상속:

-인터페이스: 여러 인터페이스를 한 클래스에서 구현할 수 있습니다. 기본 구현을 제공할 수 있는 메소드를 포함할 수 있습니다.

-추상 클래스: 하나의 클래스는 오직 하나의 추상 클래스만 상속받을 수 있으며, 하나 이상의 추상 메소드와 완전하게 구현된 메소드를 포함할 수 있습니다.

4. 생성자:

-인터페이스: 생성자를 가질 수 없습니다.

-추상 클래스: 생성자를 포함할 수 있어, 상속받는 클래스가 부모 클래스의 생성자를 호출할 수 있습니다.

 

추가 자료

https://velog.io/@k906506/Kotlin-%EC%B6%94%EC%83%81-%ED%81%B4%EB%9E%98%EC%8A%A4-VS-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4

[코틀린 완전정복] 추상 클래스와 인터페이스

 

4. val / var 의 차이

 

-val로 선언된 변수는 불변(immutable) 입니다. 이는 변수가 한 번 초기화되면 그 값을 변경할 수 없다는 것을 의미합니다. val 변수는 자바의 final 변수와 유사합니다.

불변성은 코드를 더 안전하고 예측 가능하게 만듭니다.

 

-var로 선언된 변수는 가변(mutable) 입니다. 이는 변수의 값을 초기화한 후에도 변경할 수 있다는 것을 의미합니다.

var 변수를 사용하면 편리할 수 있지만, 코드의 복잡성과 오류 가능성이 증가할 수 있습니다.

 

5. 인덱스란?

 

데이터베이스에서의 인덱스는 데이터 검색 속도를 효율적으로 높이기 위해 사용되는 자료 구조입니다. 

데이터베이스에 데이터가 많을 때, 특정 데이터를 검색하기 위해 테이블의 모든 행을 순차적으로 검색하는 것은 매우 비효율적입니다. 인덱스를 사용하면 검색 성능을 대폭 향상시켜 데이터를 빠르게 찾을 수 있습니다.

장점:

검색 속도 향상: 인덱스를 통해 데이터 접근 시간이 단축됩니다.

정렬 및 그룹화 연산 최적화: 데이터가 이미 인덱스에 의해 정렬되어 있기 때문에, 정렬이나 그룹화 연산이 더 빨라집니다.

단점:

공간 사용: 인덱스는 추가적인 디스크 공간을 사용합니다.

유지 관리 비용: 데이터가 삽입, 수정, 삭제될 때마다 인덱스도 업데이트되어야 하므로, 이로 인한 오버헤드가 발생할 수 있습니다.

 

6. JPA 2차캐시로 레디스 사용하는 방식을 고려해본적 있으신가요?

 

1차캐시와 2차캐시의 차이점
https://develoyummer.tistory.com/87

[프로젝트] 2차 캐시의 적용/ 1차캐시와 2차캐시 차이

 

Java Persistence API (JPA)를 사용할 때 2차 캐시로 레디스(Redis)를 사용하는 방식은 여러 면에서 데이터 접근 속도를 향상시킬 수 있는 효과적인 방법입니다. 이는 특히 분산 환경이나 고성능을 요구하는 웹 애플리케이션에 유리합니다. 레디스를 JPA의 2차 캐시로 사용하는 경우의 주요 장점과 단점을 다음과 같이 설명할 수 있습니다:

장점
1. 성능 향상: 레디스는 메모리 기반의 데이터 저장소로, 빠른 읽기와 쓰기 성능을 제공합니다. 데이터베이스 접근을 줄여줌으로써 응답 시간을 대폭 줄일 수 있습니다.
2. 확장성: 레디스는 분산 캐싱 시스템으로 활용될 수 있어, 여러 서버에 걸쳐 캐시를 확장할 수 있습니다. 이는 특히 대규모 시스템에서 유리합니다.
3. 지속성 옵션: 레디스는 필요에 따라 디스크에 데이터를 저장할 수 있는 지속성 옵션을 제공합니다. 이로 인해 캐시 데이터를 보다 안전하게 관리할 수 있습니다.
4. 동시성 관리: 레디스는 내부적으로 다양한 동시성 관리 기능을 제공합니다. 이는 복수의 클라이언트가 동시에 접근할 때 발생할 수 있는 데이터 일관성 문제를 해결할 수 있도록 돕습니다.

단점
1. 추가 복잡성: 레디스를 적용함으로써 시스템의 구성이 복잡해지고, 관리해야 할 컴포넌트가 늘어납니다. 이는 시스템의 설계와 유지보수를 더 어렵게 만들 수 있습니다.
2. 비용 증가: 레디스 서버를 별도로 운영하거나 관리해야 하기 때문에 하드웨어 비용이나 운영 비용이 증가할 수 있습니다.
3. 캐시 일관성 문제: 데이터베이스와 캐시 간의 데이터 동기화를 관리해야 하는데, 이 과정에서 일관성 문제가 발생할 수 있습니다. 캐시가 최신 상태가 아닐 수 있으며, 이는 애플리케이션 로직에 영향을 줄 수 있습니다.
4. 네트워크 지연: 네트워크를 통해 레디스 서버에 접근해야 하므로, 네트워크 지연이 성능에 영향을 줄 수 있습니다. 특히 네트워크 상태가 좋지 않은 환경에서는 이 문제가 더욱 심각해질 수 있습니다.

 

7. 코틀린 init 블록이 호출되는 시점이 언제인지 아시나요?

 

코틀린에서 init 블록은 클래스의 인스턴스가 생성될 때 호출됩니다. 이 블록은 주 생성자와 함께 실행되며, 주 생성자의 파라미터를 사용할 수 있습니다. 클래스가 인스턴스화될 때, 코틀린은 다음 순서대로 작업을 수행합니다:

1. 주 생성자 파라미터 초기화: 클래스의 인스턴스가 생성될 때 주 생성자에서 정의된 모든 파라미터가 초기화됩니다.
2. init 블록 실행: 주 생성자 파라미터가 초기화된 후, 클래스 내에 정의된 init 블록이 순서대로 실행됩니다. 만약 여러 개의 init 블록이 있으면, 그것들은 코드 내에 선언된 순서대로 실행됩니다.
3. 속성 초기화: 클래스 내에 선언된 속성들이 초기화됩니다. 이 초기화는 init 블록과 속성 선언에 따라 동시에 또는 순차적으로 발생할 수 있으며, 속성은 init 블록에서 사용되기 전에 초기화되어야 합니다.
4. 보조 생성자 실행: 클래스에 보조 생성자가 있으면, 주 생성자와 init 블록 이후에 실행됩니다. 보조 생성자는 this()를 사용하여 주 생성자를 호출할 수 있습니다.

 

추가자료

https://enter.tistory.com/227

[코틀린]Kotlin 생성자(init, Constructor)의 호출

 

8. redis가 빠른이유와 MySQL 같은 데이터베이스를 전부 redis로 바꾸지 않는 이유가 무엇일까요

 

Redis가 속도가 빠른 주된 이유는 데이터를 메모리 내에서 처리하기 때문입니다. 디스크 기반의 데이터 저장과는 달리, 메모리는 데이터 접근 시간이 훨씬 짧기 때문에 높은 처리 속도와 낮은 지연 시간을 제공합니다. 

Redis의 장단점

장점
1. 빠른 성능: 데이터를 메모리에서 처리하기 때문에 읽기와 쓰기 속도가 매우 빠릅니다.
2. 다양한 데이터 구조 지원: 문자열, 리스트, 세트, 해시 맵, 비트맵, 하이퍼로그로그 등 다양한 형태의 데이터 구조를 지원하여, 다양한 유형의 애플리케이션 요구 사항을 충족시킬 수 있습니다.
3. 지속성 옵션 제공: 메모리에 저장되는 데이터이지만, 정기적으로 데이터를 디스크에 저장하거나 변경사항을 디스크에 기록하는 등 여러 지속성 옵션을 제공하여 데이터의 안전성을 보장합니다.
4. 발행/구독 모델 지원: 이벤트 발생 및 메시징 시스템을 구축할 수 있는 강력한 발행(Publish)/구독(Subscribe) 기능을 제공합니다.
5. 원자성과 트랜잭션 지원: Redis 명령어는 원자적으로 실행되며, 여러 명령어를 한 번에 실행할 수 있는 트랜잭션 기능을 지원합니다.

단점
1. 메모리 용량 제한: 모든 데이터가 메모리에 저장되므로, 시스템의 물리적 메모리 용량이 한계가 될 수 있습니다.
2. 데이터 보안 및 암호화 제한: 기본적으로 Redis는 암호화되지 않은 통신을 사용하고, 내부 보안 기능이 제한적이어서, 보안이 중요한 환경에서는 추가 보안 조치가 필요합니다.
3. 비용: 메모리를 많이 사용하므로, 비용이 높을 수 있습니다. 특히 대용량 데이터를 처리하는 환경에서는 더욱 비용이 증가할 수 있습니다.
4. 분산 처리 복잡성: Redis 클러스터를 구성하고 운영하는 것은 비교적 복잡할 수 있으며, 데이터 샤딩과 복제를 통한 확장성 확보는 관리가 필요합니다.

 

모든 데이터베이스 요구사항을 Redis로 대체한다면 다음과 같은 문제가 발생할 수 있습니다:

1. 데이터 유실 위험: Redis는 주로 메모리를 사용하기 때문에 전원 장애나 시스템 다운 등이 발생하면 데이터가 유실될 위험이 높습니다. 비록 Redis가 디스크 지속성 옵션을 제공하지만, 이는 일반적인 관계형 데이터베이스(RDBMS)가 제공하는 안정성과는 다소 차이가 있습니다.

2. 비용 문제: 메모리는 비용이 비싼 리소스입니다. 대규모 데이터를 처리해야 하는 경우, 필요한 메모리 양이 많아져 비용이 크게 증가할 수 있습니다.

3. 복잡한 데이터 관계 처리의 어려움: Redis는 키-값 저장소로, 복잡한 쿼리나 조인, 복잡한 트랜잭션 관리 등 관계형 데이터베이스에서 제공하는 기능들을 지원하지 않습니다. 이로 인해 관계형 데이터 모델링이 필요한 어플리케이션에서는 사용하기 어려울 수 있습니다.

4. 보안 문제: Redis는 기본적으로 암호화되지 않은 통신을 사용하며, 내부 보안 기능도 제한적입니다. 따라서 보안이 중요한 어플리케이션에서 추가 보안 설정과 조치 없이 사용하기에는 리스크가 있을 수 있습니다.

5. 분산 처리의 복잡성: Redis 클러스터는 확장성과 고가용성을 위한 좋은 솔루션을 제공하지만, 설치와 관리가 복잡할 수 있으며, 데이터 샤딩과 복제를 통한 관리는 추가적인 노력을 요구합니다.

따라서 일반적으로 웹 어플리케이션에서 Redis를 주 데이터베이스로 사용하기보다는, 특정 작업(예: 캐싱, 세션 저장, 메시지 브로킹 등)을 위한 보조 도구로 활용하는 것이 더 일반적이며 효율적입니다.

 

결국 Redis의 단점과 JPA에서 2차캐시로 Redis를 사용했을때의 단점, 모든 데이터베이스를 Redis로 바꾸지 않는 이유는 서로 일맥상통 한다고 볼수 있습니다.