Mlog

MongoDB와 레디스는 둘 다 NoSQL 데이터베이스입니다.

그러나 이 두 시스템은 구조와 용도에 있어서 주요한 차이점들이 있습니다.

1. 데이터 구조

MongoDB는 문서 지향적인 데이터베이스입니다.

JSON-like(BSON) 문서 형태로 데이터를 저장하며, 이러한 형태는 데이터의 복잡한 계층 구조를 표현할 수 있게 해줍니다.
레디스(Redis)는 key-value 스토어로, 간단한 데이터 모델을 제공합니다.

그러나 그 값은 다양한 데이터 구조(문자열, 리스트, 해시, 집합 등)를 가질 수 있습니다.

2. 데이터 유지

MongoDB는 디스크에 데이터를 저장하여 영구적으로 유지되는 데이터를 제공합니다.

따라서, 큰 규모의 데이터에 적합합니다.
레디스는 주로 메모리에 데이터를 저장하는 in-memory 데이터 스토어입니다.

이는 빠른 응답 시간을 가능하게 하지만, 용량이 제한적일 수 있습니다.

그러나, 설정에 따라 디스크에 데이터를 저장할 수도 있습니다.

3. 사용 사례

MongoDB는 상대적으로 대규모의 데이터를 처리하며, 데이터가 구조화되어 있고,

쿼리의 복잡성이 높은 상황에 적합합니다.
레디스는 빠른 데이터 액세스를 요구하는 상황에 적합합니다.

캐싱, 메시지 큐, 실시간 분석 등의 경우에 자주 사용됩니다.

4. 복제와 분산

MongoDB는 높은 가용성과 데이터의 내구성을 보장하기 위한 다양한 복제 및 샤딩 기능을 제공합니다.
레디스도 복제와 파티셔닝을 지원하지만,

복잡한 쿼리와 트랜잭션 요구 사항을 처리하는 데에는 몽고디비보다 제한적일 수 있습니다.

5. 쿼리 기능

MongoDB는 풍부한 쿼리 언어와 인덱싱 기능을 제공하여, 복잡한 쿼리를 효율적으로 수행할 수 있습니다.
레디스는 기본적으로 key-value 조회를 제공하지만, 저장된 데이터 유형에 따라 다양한 연산을 지원합니다.
이들 차이점들은 각 데이터베이스의 선택을 결정하는 요소가 될 수 있습니다.

어떤 것이 가장 적합한지는 프로젝트의 특정 요구사항에 따라 달라질 것입니다.

Spring Framework와 ASP.NET은 모두 인기 있는 웹 애플리케이션 개발 프레임워크입니다.

그러나 이들은 여러 가지 차이점을 가지고 있습니다.

1. 언어와 플랫폼

Spring: Spring Framework는 Java로 작성되었고, JVM 위에서 동작하는 애플리케이션을 위한 솔루션을 제공합니다.

이로 인해 큰 확장성과 플랫폼 독립성이 보장되며, JVM이 설치되어 있는 모든 시스템에서 동작할 수 있습니다.

ASP.NET: ASP.NET은 .NET Framework의 일부로서, 주로 C# 언어를 사용하여 개발합니다.

전통적으로 Windows 환경에서 가장 잘 동작하지만,

.NET Core의 등장으로 다양한 플랫폼에서도 동작할 수 있게 되었습니다.

2. 설계 철학과 기능

Spring: Spring Framework의 핵심 철학은 "Inversion of Control (IoC)"과 "Dependency Injection (DI)"입니다.

이를 통해 높은 수준의 모듈화와 재사용성이 가능해지며, 코드는 보다 간결하고 읽기 쉽게 됩니다.

Spring은 MVC 패턴, 보안, 트랜잭션 관리, 메시징, RESTful 웹 서비스 등과 같은 다양한 기능을 제공합니다.

ASP.NET: ASP.NET은 웹 애플리케이션 개발에 초점을 맞추며, MVC 패턴, Web API, 신원 인증,

신뢰할 수 있는 세션 관리 등을 지원합니다.

ASP.NET Core의 등장으로 이러한 기능은 크게 확장되었고, 클라우드 지원, 컨테이너 지원 등이 추가되었습니다.

3. 성능

Spring: Spring Framework는 JVM 위에서 동작하므로, 성능은 JVM의 구현과 튜닝에 크게 의존합니다.

Java의 성능 최적화 기술이 발전함에 따라, Spring 기반 애플리케이션의 성능도 향상되었습니다.

ASP.NET: .NET은 컴파일러에 의해 기계 코드로 직접 컴파일되므로, 일반적으로 높은 성능을 제공합니다.

ASP.NET Core는 모듈화된 설계로 인해 특히 높은 성능을 자랑하며, 필요한 컴포넌트만 포함시켜

애플리케이션의 부하를 줄일 수 있습니다.

4. 커뮤니티와 지원

Spring: Spring Framework는 엄청난 크기의 개발자 커뮤니티를 가지고 있습니다.

많은 오픈 소스 프로젝트와 풍부한 학습 자료가 있으며, 다양한 문제에 대한 솔루션을 쉽게 찾을 수 있습니다.

ASP.NET: ASP.NET은 Microsoft에 의해 지원되며, Microsoft의 확장된 생태계와 통합성을 활용할 수 있습니다.

개발자 커뮤니티도 활발하며, Microsoft의 공식 문서와 지원이 매우 훌륭합니다.

결국, 어떤 프레임워크를 선택할 것인지는 개발 팀의 기술적 역량, 프로젝트의 요구 사항, 예산, 시간, 개발 환경 등

다양한 요인에 따라 결정됩니다. 양쪽 프레임워크 모두 강력하고 유연하며,

잘 설계된 애플리케이션을 만들기 위한 다양한 도구와 기능을 제공합니다.

Java에서 String 객체를 생성하는 두 가지 주요한 방법은 new 키워드를 사용하는 방법과 리터럴을 사용하는 방법입니다.

1. new 키워드를 사용하는 방법

new 키워드를 사용하여 String 객체를 생성하면 항상 새로운 객체가 생성됩니다. 
이 객체는 힙 메모리에 할당되며, 각각의 new 연산은 고유한 메모리 위치를 가집니다.

String str1 = new String("Hello");
String str2 = new String("Hello");

위 코드에서 str1과 str2는 내용은 같지만, 실제로는 서로 다른 메모리 위치에 있는 두 개의 서로 다른 객체입니다.

2. 리터럴을 사용하는 방법

리터럴을 사용하여 String 객체를 생성하면, 해당 문자열은 String 상수 풀(String constant pool)이라고 불리는

메모리 영역에 저장됩니다. String 상수 풀은 중복 String 리터럴의 메모리 사용량을 줄이기 위한

Java의 최적화 기능입니다. 같은 문자열 리터럴을 가진 String 객체는 모두 같은 메모리 위치를 참조합니다.

String str3 = "Hello";
String str4 = "Hello";

이러한 차이로 인해 new 키워드를 사용하여 생성된 String과 리터럴을 사용하여 생성된 String은 == 연산자로

비교할 때 다른 결과를 보일 수 있습니다. == 연산자는 두 객체가 같은 메모리 위치를 참조하는지를 비교하기 때문입니다.

하지만, equals() 메소드는 두 String 객체의 내용이 같은지를 비교하므로, 어떤 방법으로 String 객체를 생성하든

동일한 문자열 내용에 대해 true를 반환합니다.

상관 계수는 상관관계 분석에서 두 변수 간에 선형 관계의 정도를 수량화하는 측도

DataFrame의 corr() 메서드를 통해서 쉽게 계산 가능

-1 ~ 1 까지 있음

두 컬럼의 관계가 1에 가깝다는 것은 : 두 컬럼이 자주 같이 출현

두 컬럼의 관계가 -1에 가깝다는 것은 : 두 컬럼이 아주 드물게 출현, 겹치는 영역이 없음

두 컬럼의 관계가 0에 가깝다는 것은 : 두 컬럼이 관계가 거의 없음

오프라인 평가

사용자의 아이템에 대한 선호 기록과 추천 시스템이 추천한 결과를 비교하여 추천 품질을 평가

특징

* 별다른 비용 지출 없이 수집된 데이터만 이용하여 평가 가능

* 여러 모델을 동시에 평가할 수 있음

* 선호 기록이 기존에 사용하고 있는 추천 모델에 영향을 받을 수 있으므로,

실제 사용자의 만족도와 평과 결과가 다를 수 있음

온라인 평가

만들어진 추천 시스템을 직접 사용자에게 노출시켜 사용자의 반응을 수집하여 평가

특징

* 실제 사용자의 만족도를 측정한다는 측면에서 정화한 방식

* 비용이 비싼 평가 방식 (사용자의 만족도 감소 가능성 등)

Knowledge-based Filtering

추천하고자 하는 분야의

도메인 지식을 활용해 추천하는 방식

ex. 성별/연령별로 많이 팔리는 상품들을 모아 추천에 활용

Content-based Filtering

추천하려는 아이템의

콘텐츠 정보를 분석하거나,

정리된 메타 정보를 활용해

콘텐츠별로 특징 정보를 만들고

이를 활용해 추천

ex. 상품 페이지 하단에

같은 카테고리에 있는 인기 상품 추천

Collaborative Filtering

소비자들의 소비 이력을 사용해

소비하지 않은 새로운 아이템을 추천

ex. 클릭 이력을 바탕으로

소비자가 다음으로 클릭할 만한 상품을 추천

검색 필터링

정보의 양이 폭증함에 따라 정보 소비자가 원하는 정보를 얻는데 시간과 노력이 많이 필요

정보  소비자에게 원하는 정보를 쉽게 얻도록 도와주는 분야

정보 필터링의 대표적인 분야

* 검색

* 추천 시스템

추천 시스템

정보 소비가자 원하는 정보를 찾아 소비자에게 추천하는 시스템

검색과의 차이점

* 검색은 소비자가 관심사를 표현하는 검색이라는 행위를 해야함 (액티브)

* 추천은 특별한 행위 없이도 정보 전달이 가능 (패시브)

추천 시스템 분류

시나리오에 따른 분류

* 연관된 아이템 추천

** 현재 소비되고 있는 아이템과 연관된 아이템을 추천

* 개인화 아이템 추천

**소비중인 아이템이 없더라도, 개인의 관심사를 찾아 소비할 만한 아이템을 추천

피드백 종류에 따른 분류

* 명시적 피드백을 사용하는 추천 시스템

**영화 평점/좋아요, 싫어요와 같이 소비자가 명시적으로 자신의 선호를 표현한 데이터

* 암시적 피드백을 사용하는 추천 시스템

** 웹 페이지 접속 기록(상품), 음악 청취 기록과 같이 소비자가 명시적으로 표현하지는 않았지만,

   선호를 보여주는 피드백

업데이트 주기에 따른 분류

* 오프라인 추천 시스템

** 특정 시점의 데이터를 사용해 추천 결과를 계산하는 방식

* 온라인 추천 시스템

** 지속적으로 사용자의 데이터를 받아 추천 결과를 업데이트 하는 방식 (요즘 거의 주로 사용))

현업에서는 다양한 추천 로직이 섞인 하이브리드 추천 시스템을 많이 사용합니다.

Graphics Pipeline

물체를 화면에 그리는데 필요한 과정을 의미한다.

우리가 이용하는 모니터에서 3D 영화나 게임이 재생될 때 사용자는 3차원 물체를 모두 그린다고 착각할 수 있지만

실제로 화면에 그려지고 있는 것은 자원의 효율적인 활용을 위하여 2차원의 형태를 그리고 있는 것이다.

이렇게 3차원의 정보를 2차원의 형태로 변환하고 모니터에 찍어내기 위해 필터링 과정을 거치는 작업을

그래픽스 파이프 라인이라고 한다.

본 글에서는 DirectX 11을 기준으로 서술할 예정이고

DX9 나 OpenGL은 세세한 부분은 다르지만 큰 틀에서 보면 비슷하다고 하기에 따로 정리하진 않을 예정이다.

마이크로소프트에서 제공하는 도큐먼트에서는 상기 이미지와 같이 그래픽스 파이프라인을 정리하였다.

가장 눈에 띄는 것은 Hull Shader에서 Domain Shader 까지의 과정이다.

이 과정을 Tessellation(테셀레이션) 과정이라고 하며 D9에서 D11로 넘어오면서 추가된 기능이다.

'테셀레이션'은 '쪽매붙임' 이라고도 하는데 바닥에 타일을 깔때 빈틈이 생기는 부분을

더 작은 조각으로 채우는 기법에서 유래된 듯하다.

(옛날부터 있던 기법인데 환경의 문제 때문에 D11이 되서야 실현 가능해졌다고 한다.)

이 외에 Vertex Shader, Geometry Shader, Rasterizer, Pixel Shader 등의 과정은 이전 버전에도 존재했으며

각각, 입력받은 정점 정보를 토대로 수학적인 효과를 부여한다거나 (Vertex Shader)

그 처리된 정점을 추가/제거 하여 정점 수를 조절하고 선, 삼각형을 생성한다거나 (Geometry Shader)

만들어진 결과물을 화면에 띄우기 위해 픽셀 이미지화 시키고 다듬고 (Rasterizer)

래스터화 된 이미지의 픽셀들의 색을 계산하는 역할을 한다. (Pixel Shader)

0. Shader

컴퓨터 그래픽스 분야에서 셰이더(shader)는 소프트웨어 명령의 집합으로

주로 그래픽 하드웨어의 렌더링 효과를 계산하는 데 쓰인다.

셰이더는 그래픽 처리 장치(GPU)의 프로그래밍이 가능한 렌더링 파이프라인을 프로그래밍하는 데 쓰인다.

1. Vertex Shader

버텍스 셰이더는 주로 물체의 정점 정보에 수학적인 연산을 함으로써 물체에 특별한 효과를 주는 데 쓰인다.

각각의 정점이 정의되는 방법은 다양하다. 정점이 가지는 정보는 예를 들어 3차원의 위치를 나타내는 x, y, z 좌표나,

색상, 텍스처, 조명 정보 등이 있다. 버텍스 셰이더는 이런 정점의 정보값을 변화시켜서,

물체를 특별한 위치로 옮기거나, 텍스처를 바꾸거나, 색상을 바꾸는 등의 일을 할 수 있다.

하지만 기존의 정점을 지우거나 새로운 정점을 추가하는 등의 작업은 할 수 없다.

2. Geometry Shader

지오메트리 셰이더는 버텍스 셰이더에서는 할 수 없는 점이나, 선, 삼각형 등의 도형을 생성할 수 있는 기능이 있다.

지오메트리 셰이더 프로그램은 버텍스 셰이더가 수행되고 난 뒤에 수행된다. 지오메트리 셰이더 프로그램은 

버텍스 셰이더를 거쳐온 도형 정보를 입력받는데, 예를 들어 정점 3개가 지오메트리 셰이더에 들어오면,

셰이더는 정점을 모두 없앨 수도 있고 더 많은 도형을 만들어 내보낼 수도 있다.

지오메트리 셰이더를 지나간 도형 정보는 레스터라이즈를 거친 뒤 픽셀 셰이더를 통과하게 된다.

지오메트리 셰이더는 테셀레이션이나 그림자 효과, 큐브 맵을 한번의 처리로 렌더링하는 데에 주로 쓰인다.

지오메트리 셰이더는 어셈블리어나, Cg, HLSL, GLSL 등으로 프로그래밍할 수 있다.

지오메트리 셰이더는 DirectX 10 버전부터 시작되었으므로, DirectX10 버전 이상의 HLSL로만 프로그래밍 할 수 있다. OpenGL 은 3.2 이상부터 GLSL 로 프로그래밍 할 수 있다.

3. Fragment Shader

프래그먼트 셰이더는 오브젝트가 화면에서 차지하고 있는 모든 픽셀마다 실행되는 프로그램이며

보통 각 픽셀의 컬러를 계산하고 출력하기 위해 사용된다. 화면에는 보통 수백만 개의 픽셀이 있으며

프래그먼트 셰이더는 이 모든 픽셀에 대해 실행된다.

프래그먼트 셰이더를 최적화하는 것은 전반적인 게임 성능에 있어 매우 중요한 부분이다.

4. Pixel Shader

픽셀 셰이더는 렌더링 될 각각의 픽셀들의 색을 계산한다.

때문에 픽셀 셰이더는 최종적으로 픽셀이 어떻게 보일지를 결정한다.

픽셀 셰이더는 간단하게 언제나 같은 색을 출력하는 간단한 일에서부터, 텍스처로부터 색을 읽어오거나,

빛을 적용하는 것, 범프 매핑, 그림자, 반사광, 투명처리 등 복잡한 현상 등을 수행할 수 있다.

픽셀 셰이더는 각각의 픽셀들이 렌더링될 때 수행되기 때문에, 다른 픽셀들과 아무런 연관이 없다.

픽셀 셰이더는 오직 한 픽셀만을 연산하기 때문에, 주변의 픽셀이나, 그리는 도형에 대한 정보를 알 수 없다.

이 때문에 픽셀 셰이더는 스스로 매우 복잡한 효과를 만들어 낼 수는 없다.

픽셀 셰이더는 픽셀의 색 말고도 깊이(Z버퍼에 쓰인다)나 또 다른 색(다른 렌더 목표물에 쓰인다)을 출력할 수 있다.

1. IL2CPP

유니티 엔진의 내부는 C++로 구성되어있다.

따라서, 유니티가 C#을 사용하여 느리다 라는 것은 어느 정도 잘못된 말이지만

개발자 스크립팅 부분은 C#을 사용하였기에 아쉬운 점이 있던 것은 사실이다.

하지만, IL2CPP는 이런 유니티의 단점을 커버해준다.

IL2CPP는 Unity 프로젝트의 성능, 보안 및 플랫폼 호환성을 개선하는 등의 용도로 사용된다.

IL2CPP는 결과적으로 스크립팅 부분도 C++로 돌아가게끔 해주기 때문이다.

2. Mono

IL2CPP에 대해서 자세하게 알아보기 전에 몇가지 더 알아둬야 할 것이 있다.

본래 C#은 MS에서 윈도우 전용으로나 사용되던 언어였다. (현재는 .NET Core를 사용한다.)

 IOS나 안드로이드 같은 다른 환경에서는 .NET Framework가 구동되지 않았기 때문이었다.

크로스 플랫폼이 기본이 되어가는 어플리케이션 환경 속에서

이런 C# .NET의 단점은 너무나도 치명적이었다

이 단점을 보완하기 위하여 시미안(Ximian)이라는 곳에서 Mono 프로젝트가 오픈 소스로 공개되었고

Mono 프로젝트는 여러 플랫폼에서 .NET을 사용할 수 있게 해주었다.

현재는 MS에서 인수하여 개발을 진행하고 있다.

Unity 또한 게임 어플리케이션을 주로 개발하는데 사용하기에 Mono로 빌드하여 사용하였으나,

Mono 프로젝트가 오래되었고 IOS 환경에서 구동할 수 없는 치명적인 단점.

JIT(Just In Time) 방식의 컴파일러이기 때문에 유연하지만 느리다는 단점이 있어서 (게임은 퍼포먼스가 중요하다.)

IL2CPP라는 스크립팅 백엔드를 개발하게 된다.

3. IL2CPP의 특징

IL2CPP는 AOT(Ahead Of Time) 방식으로 구동된다.

말 그대로 소스 코드를 '미리' 컴파일 하는 방식으로 CIL을 C++로 미리 바꿔서 사용한다.

Mono의 JIT 방식은 코드를 CIL로 가지고 있다가 플랫폼에 맞춰 변환한다.

IL2CPP가 미리 컴파일 된 방식을 사용하는 만큼 속도 면에서 더 유리하다.

하지만, JIT 방식이 가지고 있던 핫 리로드와 같은 장점은 사용할 수 없다.

또한, IL2CPP로 빌드된 파일은 디컴파일로 코드를 제대로 확인하기 힘들어

어셈블리로 해석해야 하는 상황에 놓이기 때문에 최소한의 보안 역할도 할 수 있다.

4. IL2CPP의 구동 방식

1. Unity 스크립팅 API코드를 일반 .NET DLL로 컴파일
2. 관리되는 바이트코드 스트리핑을 적용 -> 빌드된 게임의 크기를 크게 줄여줍니다.
3. 모든 관리되는 어셈블리를 표준 C++ 코드로 전환
4. 생성된 C++코드와 IL2CPP의 런타임 부분을 네이티브 플랫폼 컴파일러로 컴파일
5. 대상 플랫폼에 따라 실행 가능한 파일이나 DLL에 코드를 연결

더 간단하게 보면 아래의 그림과 깉이 될 것이다.

https://www.youtube.com/watch?v=-9X965jXrn8