12/13, 열다섯 번째 날의 TIL(앙상블학습, Redis)

벌써 세 번째 주의 마지막 날이다. 매일 12시간씩 공부를 해도 시간이 너무 빨리 가는 것 같다. 개인 공부 외에 스터디도 따로 두개 하고 있고, 수준별 학습반에서 하는 화요일 프로젝트반/ 목요일 스터디 및 연구 반에 모두 참여 할 것이기 때문에 앞으로 매우 바빠질 예정이다. 하지만 이 캠프를 하러 온 것이 놀러 온 것이 아니라 취업이라는 목표를 가지고 들어왔기 때문에 그걸 이루기 위해 최선을 다할 것이다.

---

1. 배깅과 부스팅, 그리고 랜덤 포레스트

대학교에서 앙상블학습에 대한 내용을 배울 때, 배깅과 부스팅이 무엇인지, 어떤 원리인지. 랜덤 포레스트도 마찬가지로 무엇이고 어떤 원리인지 배운 다음 각각 실습을 하고 넘어가는 정도로 공부를 했다. 그래서 깊게는 아니고 내용을 알고만 있는 정도였는데, 이번에 모델을 많이 돌려보고 이론을 더 깊이 공부하면서 궁금한 점이 생겼다. 배깅과 부스팅, 랜덤 포레스트에 대해서 간단하게 보면

 

• 배깅(Bagging): 데이터를 여러 샘플로 나눠 각각 독립적으로 학습한 모델들을 결합해 결과를 도출하는 방식으로, 주로 분산을 줄여 예측 성능을 향상시킨다.(예: 랜덤 포레스트)
• 부스팅(Boosting): 약한 학습기를 순차적으로 학습시키며, 이전 학습기의 오류를 보완하는 방식으로 강력한 모델을 만드는 기법(예: AdaBoost, Gradient Boosting).
• 랜덤 포레스트(Random Forest): 배깅과 의사결정나무를 결합한 알고리즘으로, 데이터 샘플링과 특성 선택을 무작위로 하여 다수의 결정나무를 학습시킨 후 평균을 통해 최종 결과를 도출한다.

각각의 개념인데, 궁금한 부분은 배깅과 랜덤 포레스트에 관한 내용이였다. 배깅도 데이터를 여러 샘플로 나눠 독립적으로 학습한 모델의 결과를 결합하고, 랜덤 포레스트는 배깅과 의사결정나무를 결합한 알고리즘이면 배깅 안에 랜덤 포레스트가 들어가지 않나? 어떤 점이 다를까 하고 생각하게 되었는데, 알아보았더니

• 공통점 : 둘 다 배깅 기법 사용, 각각의 결정 트리가 독립적으로 학습되며 예측 결과를 회귀하거나 다수결로 결합
• 공통적 목적 : 모델의 편향을 줄이고 분산을 낮춰 일반화성능을 향상
• 차이점
  • 특성 샘플링 : 랜덤 포레스트는 각 결정 트리에서 사용할 특성을 무작위로 선택(배깅은 모두 사용)
  • 하이퍼파라미터 조정 : 랜덤 포레스트는 추가적인 하이퍼파라미터 제공
  • 랜덤 포레스트는 더 강력한 성능을 제공 : 더 다양한 트리를 생성하므로. 배깅은 더 높은 분산을 가질 수 있다.

다음과 같았다. 결론적으로 말하면, 랜덤 포레스트 모델이 더 복잡하고 다양한 방법을 시도해서 성능이 좋은 반면 구현이 더 복잡하고 속도가 더 느릴 수 있고 배깅은 성능이 좀 떨어지는 대신 간단하고 빠르게 구현이 가능한 것이다.

그리고 모델이 복잡하다는게 차원이 높아서 고차원의 저주 때문에 과적합이 되는 것이 아니라, 여러 하이퍼파라미터가 많고 샘플링도 다양하게 하기 때문에 랜덤 포레스트 모델이 과적합 방지 능력이 더 뛰어나다.

 

그럼 각각의 모델은 어느 상황에 사용해야 할까? 우선 배깅은 작은 데이터셋에서 잘 동작하므로 데이터 양이 많지 않고, 빠르게 구현해야 할 때 사용하면 좋고 랜덤 포레스트는 데이터 양이 방대하고 높은 정확도가 필요한 경우에 사용하면 좋을 것이다. 모델을 공부하더라도, 그냥 이런 모델이구나 하지 말고 다른 모델과 비교도 해보고 어디에 쓰이는지도 찾아보는 중인데 이 방법대로 공부하니까 더 깊은 내용을 알 수 있어서 좋은 것 같다.

---

 

2. Redis에 대해서

Redis에 대한 새로운 스터디를 시작했다. 지금까지 데이터베이스는 MySQL,Oracle밖에 다뤄보지 않았기 때문에 다른 것도 사용해보고 싶었는데, 마침 기회가 생겨서 Redis에 대한 강의를 보며 공부를 해보았다.

 

정리하자면, Redis는 '키-값' 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈소스 기반의 비관계형 DBMS이다. Redis를 사용하는 이유는 모든 데이터를 인메모리에 저장해서 처리 성능이 굉장히 빠르기 때문인데, RDBMS의 경우에는 대부분 디스크에 데이터를 저장해서 성능이 느리다.

 

왜 처리 속도가 빨라야 하는지, 어디에 쓰이는지 알아보았는데 캐싱, 메시지 큐, 속도제한, 세션 관리, 실시간 분석 및 통계 등에 사용된다고 한다. 이 중에서 캐싱에 대해서 중점적으로 공부했는데 Brew로 Redis를 설치하고 간단한 명령어들을 익혀보았다. 데이터를 입력하고 조회, 삭제하는 등 대부분의 기능은 비슷했는데 특이한 기능이 하나 있었다. 바로 TTL이다.

 

TTL은 Time To Leave의 약자로, 시간을 설정해놓으면 해당 시간 이후 데이터가 사라지게 된다. 처음에는 데이터가 사라지는 명령어가 있다는 사실이 신기했고, 그 다음에는 어디에 이 기능이 사용되는지 궁금했다. 데이터는 민감하고 사라지면 안되는 내용이 있을텐데 데이터를 해당 시간 이후에 삭제한다는 것이 이상했기 때문이다.

 

그래서 처음에 내 의견은, 인증키나 개인정보같은 민감한 내용이 포함되어 있을 경우에 이 내용의 보안을 위해 시간이 지나면 삭제되게 했나보다 라고 생각했지만, 그 목적은 아니었고 다른 목적이 있었다. 그걸 설명하려면 먼저 Redis가 어떻게 동작하는지 알아야 하는데, 데이터가 입력되면 입력된 데이터는 바로 데이터베이스로 간다. 하지만 데이터를 조회했을 때, 조회를 데이터베이스가 아니라 Redis에 먼저 한다. Redis에 해당 데이터가 있으면 빨리 가져올 수 있기 때문이다.

데이터가 있으면 바로 가져오고, 없으면 데이터베이스로 가서 조회를 한 다음 가져오고 같은 내용을 Redis에 저장한다.

이 과정을 글로 정리한다면

1. 처음엔 아무 데이터가 없다.
2. 일부 사용자가 데이터를 저장하면 바로 데이터베이스에 저장한다.
3. 데이터를 요청할 때는, 데이터베이스가 아니라 Redis에 먼저 요청하게 된다.
4. 데이터가 Redis에 없으면 데이터베이스를 조회한 뒤 응답한다.
5. 응답 뒤에 해당 데이터를 Redis에 저장한다.
6. 다른 데이터를 조회하는 경우에
7. Redis에 해당 데이터가 있으면 바로 가져온다.

위와 같다. 그래서 여기서 TTL을 사용하는 이유가 나오는데, 데이터가 계속 쌓이게 되면 공간이 부족해진다. 데이터베이스가 아니라 인메모리에 데이터를 저장하기 때문에 공간이 크지 않기 때문이다. 그래서 TTL을 이용해 필요한 데이터는 바로 사용하다가, 시간이 지나서 삭제되면 공간을 비울 수 있는 것이다. 세상에는 다양한 해결법이 참 많은 것 같다.

---

새로운 내용도 계속 공부하고, 기존의 내용은 더 깊이 공부하려고 노력중이다. 앞으로의 내용들도, 그냥 알고 넘어가는게 아니라 더 깊이 공부하고 연관된 내용이나 실제 사용 사례도 계속 알아볼 예정이다.

앞으로의 시간도 화이팅