용어

Engine

특정 프로그램을 위해 핵심적이고 본질적인 기능을 수행해주는 프로그램

Context

프로그래밍에서의 Context 의미 프로그래밍에서 "context"는 다양한 상황에서 사용되며, 일반적으로 다음과 같은 의미를 가집니다:

1. 실행 컨텍스트 (Execution Context)

프로그램이 실행되는 동안 특정 시점에서의 상태와 관련된 정보를 나타냅니다.

• JavaScript에서 함수 호출 시 생성되며, 지역 변수, 매개변수, this 값 등을 포함.
• 스택 형태로 관리되며, 현재 실행 중인 컨텍스트는 스택의 맨 위에 위치.

2. 그래픽 컨텍스트 (Graphics Context)

그래픽스 시스템에서 렌더링 설정(예: 색상, 폰트, 브러시 등)을 관리하는 객체입니다.

• HTML5 캔버스의 CanvasRenderingContext2D 객체가 해당.

3. 보안 컨텍스트 (Security Context)

보안 측면에서 사용자의 인증 정보, 권한, 정책 등을 관리하는 데 사용됩니다.

• 예: 데이터베이스 접근 시 사용자의 권한에 따른 접근 제어.

4. 스레드 로컬 컨텍스트 (Thread-local Context)

다중 스레드 환경에서 각 스레드가 개별적으로 유지하는 데이터를 나타냅니다.

• Java의 ThreadLocal 클래스를 사용해 스레드별 독립적인 데이터 관리.

5. 어플리케이션 컨텍스트 (Application Context)

애플리케이션 전반에서 공유되는 설정 정보나 상태를 나타냅니다.

• 스프링 프레임워크에서 ApplicationContext는 빈(bean)의 생명 주기를 관리하고 설정 정보를 제공.

6. 데이터베이스 컨텍스트 (Database Context)

데이터베이스와의 상호작용을 관리하는 객체나 구조체입니다.

• Entity Framework에서 DbContext는 데이터베이스 연결 및 쿼리 수행을 관리.

Hooking

프로그래밍에서 "후킹(hooking)"은 특정 이벤트가 발생했을 때 사용자 정의 코드를 실행할 수 있도록 시스템이나 애플리케이션의 동작을 가로채거나 변경하는 기법을 말합니다. 후킹은 다양한 용도로 사용되며, 주로 다음과 같은 방식으로 구현됩니다:

API 후킹

• 운영 체제의 API 호출을 가로채서 원래의 함수가 호출되기 전에 사용자 정의 코드를 실행합니다. 이를 통해 함수의 동작을 변경하거나 추가 기능을 삽입할 수 있습니다.
• 예를 들어, 파일 읽기 함수가 호출될 때마다 로그를 남기거나, 특정 조건이 만족되면 파일 읽기 동작을 차단할 수 있습니다.

메시지 후킹

• 윈도우 프로그래밍에서 윈도우 메시지를 가로채서 처리하는 기법입니다. 이는 주로 GUI 애플리케이션에서 사용자 인터페이스 이벤트를 처리하기 위해 사용됩니다.
• 예를 들어, 키보드나 마우스 입력을 가로채서 특정 키가 눌렸을 때 별도의 동작을 수행하게 할 수 있습니다.

프로세스 후킹

• 실행 중인 프로세스의 특정 함수나 메서드를 가로채는 기법입니다. 디버깅, 모니터링, 또는 프로세스의 동작을 변경하기 위해 사용됩니다.
• 예를 들어, 게임의 특정 기능을 변경하거나, 악성 소프트웨어의 동작을 분석하는 데 사용됩니다.

라이브러리 후킹

• 동적으로 로드되는 라이브러리(DLL)의 함수 호출을 가로채는 기법입니다. 특정 라이브러리 함수가 호출될 때마다 사용자 정의 코드를 실행할 수 있습니다.
• 예를 들어, 네트워크 통신을 가로채서 패킷을 수정하거나 로깅하는 데 사용할 수 있습니다.

후킹의 사용 사례

• 디버깅 및 프로파일링: 프로그램의 실행 흐름을 추적하고 성능을 분석하기 위해 후킹을 사용합니다.
• 보안 소프트웨어: 바이러스 백신이나 침입 탐지 시스템에서 악성 동작을 모니터링하고 차단하기 위해 API 후킹을 사용합니다.
• 게임 모드 및 치트: 게임의 특정 기능을 변경하거나 새로운 기능을 추가하기 위해 후킹 기법을 사용합니다.
• 사용자 인터페이스 확장: 기존 애플리케이션의 UI 요소를 확장하거나 변경하기 위해 메시지 후킹을 사용합니다.

후킹은 매우 강력한 기법이지만, 잘못 사용될 경우 시스템 안정성을 해칠 수 있으며, 악의적인 목적으로 사용될 수도 있습니다. 따라서 후킹을 사용할 때는 신중하게 접근하고, 보안과 안정성을 고려해야 합니다.

Artifact

소프트웨어 개발에서 "아티팩트(artifact)"란 개발 과정 중에 생성되거나 사용되는 다양한 형태의 문서, 코드, 모델 등을 말합니다. 아티팩트는 소프트웨어 개발의 각 단계에서 중요한 역할을 하며, 프로젝트의 효율적인 진행과 관리를 위해 필수적입니다. 다음은 아티팩트의 주요 유형과 그 예시들입니다

• 요구사항 아티팩트
  • 요구사항 명세서: 시스템의 기능적, 비기능적 요구사항을 기술한 문서.
  • 사용자 스토리: 애자일 개발에서 사용자의 요구사항을 간단하게 설명한 문서.
• 설계 아티팩트
  • 아키텍처 다이어그램: 시스템의 구조와 주요 구성 요소들을 시각적으로 표현한 다이어그램.
  • 데이터 모델: 데이터베이스 구조와 그 관계를 나타낸 모델.
• 개발 아티팩트
  • 소스 코드: 실제 프로그램을 구성하는 코드 파일.
  • 스크립트: 자동화된 작업을 수행하기 위해 작성된 코드.
• 테스트 아티팩트
  • 테스트 계획서: 테스트의 범위, 접근 방법, 자원, 일정 등을 설명한 문서.
  • 테스트 케이스: 특정 조건 하에서 시스템을 테스트하기 위한 입력값, 실행 조건, 예상 결과 등을 기술한 문서.
• 배포 아티팩트
  • 배포 패키지: 소프트웨어를 설치할 수 있도록 패키지화한 파일 집합.
  • 릴리즈 노트: 새로운 기능, 버그 수정, 알려진 문제점 등을 포함한 릴리즈에 관한 정보.
• 유지보수 아티팩트
  • 버그 리포트: 소프트웨어의 결함이나 문제를 설명한 문서.
  • 변경 이력: 소프트웨어의 변경 사항을 기록한 문서.

아티팩트는 특정 작업(Task)을 수행한 결과로 생성되는 산출물입니다. 이는 프로젝트를 진행하며 발생하는 모든 결과물을 포함하며, 각 작업의 목적과 과정에 따라 다양한 형태를 가질 수 있습니다. 쉽게 말해, 어떤 일을 했을 때 나오는 결과물이 바로 아티팩트입니다.

RichText

"Rich Text"라는 용어는 컴퓨터 과학과 디지털 문서 편집 분야에서 유래했습니다. 이 용어는 텍스트 데이터를 단순한 순수 텍스트(plain text)보다 더 풍부한 형태로 표현하기 위해 사용됩니다. Rich Text는 일반적으로 서식 정보(예: 글꼴, 색상, 굵게, 기울임, 밑줄 등)와 같은 추가적인 메타데이터를 포함합니다. Rich Text의 역사는 1970년대와 1980년대로 거슬러 올라갑니다. 이 시기에는 컴퓨터 기술의 발전과 함께 문서 편집 및 처리 기술도 크게 발전하였습니다. 주요 시기와 용어의 발전 과정을 간략히 살펴보면 다음과 같습니다:

• 초기 워드 프로세서
  • 1970년대와 1980년대에 워드프로세서가 개발되면서 사용자가 서식을 지정할 수 있는 기능이 등장했습니다.
  • 이 시기의 워드프로세서는 텍스트를 굵게, 기울임, 밑줄 등으로 포맷팅할 수 있는 기능을 제공했으며, 이는 단순한 텍스트 파일과 구별되는 "Rich Text"의 초기 형태라고 할 수 있습니다.
• Rich Text Format (RTF)
  • 1987년 마이크로소프트는 Rich Text Format (RTF)이라는 파일 형식을 도입했습니다.
  • RTF는 문서 간에 서식 있는 텍스트를 교환하기 위한 표준 파일 포맷으로, 텍스트와 함께 서식 정보를 포함할 수 있었습니다.
  • RTF의 도입은 "Rich Text"라는 용어의 사용을 더욱 보편화시켰습니다.
• 웹과 HTML
  • 1990년대에 월드 와이드 웹(WWW)이 등장하면서 HTML(HyperText Markup Language)이 표준으로 자리 잡았습니다.
  • HTML은 텍스트에 서식을 추가하는 능력을 갖추고 있었으며, 이는 웹 문서의 풍부한 표현력을 가능하게 했습니다.
  • HTML의 등장과 발전은 Rich Text 개념이 웹 기술과 긴밀하게 연관되게 했습니다.
• 현대의 Rich Text Editors
  • 오늘날에는 Microsoft Word, Google Docs, WYSIWYG (What You See Is What You Get) 에디터 등 다양한 도구들이 Rich Text 기능을 제공하고 있습니다.
  • 이러한 도구들은 사용자가 시각적으로 풍부한 문서를 쉽게 작성하고 편집할 수 있도록 돕고 있습니다.

요약하자면, "Rich Text"라는 용어는 텍스트 데이터에 서식 정보를 포함하여 보다 풍부한 표현력을 제공하려는 시도에서 유래되었습니다. 컴퓨터 기술의 발전과 함께 이 개념은 계속해서 진화하고 있으며, 오늘날의 디지털 문서 편집의 핵심 요소로 자리 잡고 있습니다.

런타임 에 대한 개념

언리얼 엔진에서의 런타임이라는 용어는 일반적으로 게임이나 어플리케이션이 실행되괴 있는 동안의 시기를 의미합니다. 프로젝트가 빌드되고 에디터가 실행되고 있는 순간은 런타임이 아닙니다. 빌드 과정과 에디터가 단순히 실행되고 있는 상태는 런타임에 포함되지 않습니다. 빌드 과정은 게임을 실행 가능한 형태로 준비하는 단계이고, 에디터가 실행되고 있는 순간은 게임 개발 환경이 작동 중인 상태일 뿐입니다. 런타임은 실제 게임 로직이 동작하고 게임 플레이가 진행되는 기간을 의미합니다. 이 정의는 두가지 상황에 적용될 수 있습니다.

• 에디터에서 플레이(Play) 버튼을 누른 순간부터: 언리얼 에디터에서 'Play' 버튼을 클릭하면, 에디터 내에서 게임이 실행되기 시작합니다. 이때부터 게임의 런타임이 시작된다고 볼 수 있습니다. 에디터에서의 런타임은 주로 개발자들이 게임을 테스트하고 디버그하는 데 사용됩니다.
• 빌드된 게임이 실제로 실행된 순간부터: 최종 사용자에게 배포된 게임의 경우, 사용자가 게임을 실행하여 게임이 시작된 순간부터 런타임이 시작됩니다. 이때는 독립 실행형 애플리케이션으로 동작하며, 에디터와는 독립적으로 동작합니다.

에디터가 실행되고 있을 때는 일반적으로 "에디터 모드(Editor Mode)"라고 부릅니다. 이 모드는 언리얼 엔진 에디터 내에서 게임이나 애플리케이션을 개발하고, 설정하고, 테스트하는 환경을 의미합니다. 에디터 모드에서는 다양한 툴과 기능을 사용하여 레벨을 디자인하고, 애셋을 배치하며, 게임 로직을 작성하고 디버깅할 수 있습니다. 에디터 모드에서 게임을 실행하면 런타임으로 전환되며, 게임이 멈추면 다시 에디터 모드로 돌아오게 됩니다.

• 에디터 모드(Editor Mode)
  : 언리얼 엔진 에디터가 실행 중이며, 개발자가 게임을 편집하고 설정하는 상태. 이 모드에서는 게임이 실제로 실행되지 않고, 개발 작업이 이루어집니다.
• 런타임(Runtime)
  : 게임이 실제로 실행되는 동안의 상태. 이는 에디터에서 'Play' 버튼을 눌러 게임이 시작된 순간부터 또는 빌드된 게임이 최종 사용자에 의해 실행된 순간부터 시작됩니다.

언리얼의 스마트포인터 관련 헤더파일은 Editor 관련 모듈에 있어야 할 거같은데
Runtime 모듈에 있는데 이유가 뭐야?
먼가 프로그램의 기본적인 기반 같은 단계라서 Editor 에 있어야 할거 같은데?

언리얼 엔진에서 스마트 포인터 관련 헤더 파일이 Runtime 모듈에 있는 이유는 스마트 포인터가 게임의 실행과 개발 환경 모두에서 기본적인 메모리 관리 기능을 제공하기 때문입니다. 다음은 이에 대한 구체적인 이유입니다

• 스마트 포인터의 기본 기능
  • 스마트 포인터는 메모리 관리의 기본적인 도구입니다. 게임이 실행될 때(런타임)와 에디터 모드에서 모두 필요한 기능입니다. 스마트 포인터는 메모리 누수를 방지하고 객체의 수명을 관리하는 데 중요한 역할을 합니다. 따라서, 이 기능은 게임 실행과 개발 환경 모두에서 필요합니다.
• 에디터와 런타임의 공통 요소
  • 언리얼 엔진의 에디터와 런타임 모듈은 많은 공통 요소를 공유합니다. 에디터는 런타임 모듈 위에 구축된 도구입니다. 즉, 런타임 모듈에 포함된 기본 기능을 에디터도 사용합니다. 스마트 포인터는 이러한 기본 기능의 일부로, 에디터와 런타임 모두에서 필요합니다.
• 의존성 관리
  • 스마트 포인터가 Runtime 모듈에 위치함으로써, 에디터 모듈과 런타임 모듈 모두 스마트 포인터 기능을 사용할 수 있습니다. 반대로, 스마트 포인터가 에디터 모듈에 위치하면 런타임 모듈이 에디터 모듈에 의존하게 되어, 에디터가 설치되지 않은 환경에서 런타임 모듈을 사용하는 데 어려움이 발생할 수 있습니다. 이를 방지하기 위해, 공통으로 필요한 기능을 런타임 모듈에 두는 것이 일반적입니다.
• 모듈의 역할 분담
  • Runtime 모듈은 게임이 실행되는 동안 필요한 모든 기본 기능을 제공합니다. 에디터 모듈은 주로 개발 도구와 관련된 기능을 추가합니다. 따라서, 메모리 관리와 같은 핵심 기능은 Runtime 모듈에 포함되어야 하며, 에디터 모듈은 추가적인 개발 도구와 편의 기능을 제공합니다.

이러한 이유들로 인해 스마트 포인터 관련 헤더 파일이 Runtime 모듈에 포함되어 있으며, 이는 게임 개발의 기본적인 기반을 제공하기 위한 설계 결정입니다. 이렇게 함으로써 에디터와 런타임 환경 모두에서 일관성 있고 효율적인 메모리 관리가 가능합니다.

런타임과 에디터 모두에서 필요한 기능은 런타임에 구현되어 있고,
에디터에서만 필요한 기능은 에디터에만 있나?

네, 정확합니다. 언리얼 엔진에서는 모듈의 역할과 기능을 명확히 구분하여 관리합니다. 이를 통해 개발 및 실행 환경에서 필요한 기능을 효율적으로 제공합니다. 다음은 이 구조에 대한 상세 설명입니다:

기능 배치의 원칙

공통 기능: 런타임과 에디터 모두에서 필요로 하는 기능은 런타임 모듈에 배치됩니다. 이렇게 함으로써 코드의 중복을 피하고, 두 환경 모두에서 일관되게 동작하도록 보장합니다.

에디터 전용 기능: 개발 도구와 같은 에디터 전용 기능은 에디터 모듈에 배치됩니다. 이는 런타임 모듈이 불필요하게 비대해지는 것을 방지하고, 배포된 게임의 크기와 복잡성을 줄입니다.

예시

• 스마트 포인터: 런타임 모듈에 포함되어 있어, 게임 실행 중과 에디터 작업 중 모두에서 사용됩니다.
• 레벨 디자인 도구: 에디터 모듈에 포함되어 있으며, 게임 개발 중에만 필요합니다.

이런 구조적 설계는 언리얼 엔진이 높은 성능과 효율성을 유지하면서도 강력한 개발 도구를 제공할 수 있도록 합니다.

포함관계

런타임 모듈은 게임 실행에 필요한 모든 기본 기능을 포함하고 있으며, 이 기능들은 에디터 모듈에서도 사용됩니다. 반면, 에디터 모듈은 주로 개발 도구와 관련된 기능들을 추가로 제공합니다. 따라서, 런타임 모듈이 더 기본적이고 넓은 범위를 포괄하는 개념입니다. 에디터 모듈은 런타임 모듈을 포함하며, 그 위에 개발 도구를 추가한 형태입니다.

NAT

Network Address Translation

Server

다른 컴퓨터에서 연결이 가능하도록 대기 상태로 상시 실행중인 프로그램 영업중인 식당과 유사하다 손님이 올 수 있도록 식당을 열고 대기중인 상태. 손님이 오면 식당 메뉴/정책 에 따라 서비스 제공

서버의 종류

Client

영화를 찍는것과 유사하다?