APM 시스템 기술 아키텍처 소개

1. Agent — C 기반 모니터링 데이터 수집 Agent

APM Agent는 대상 시스템에 설치되어 시스템 및 애플리케이션의 성능 데이터를 실시간으로 수집하고, 수집된 데이터를 중앙 수집 서버로 전송하는 경량형 모니터링 모듈이다.

Agent는 C 언어 기반의 Native Application으로 구현되며, 서버 시스템에 상주하면서 주기적인 Polling 또는 Event 기반 수집 방식을 통해 모니터링 데이터를 획득한다.

1.1 수집 대상

Agent에서 수집하는 주요 모니터링 대상은 다음과 같다.

Agent는 수집 대상별 Collector 또는 Monitor Module을 통해 데이터를 수집하고, 내부적으로 수집 데이터를 표준 데이터 구조로 변환 및 정규화(Normalization) 한다.

1.2 데이터 전송

수집된 데이터는 Agent에서 중앙 수집 서버로 직접 TCP 통신하는 방식이 아니라 Redis를 Message Transport Layer로 활용하여 비동기 방식으로 전송한다.

[System / DBMS / Middleware / Process / Application]
                         │
                         ▼
                ┌─────────────────┐
                │   APM Agent     │
                │   C 기반        │
                │   Collector     │
                └────────┬────────┘
                         │
                    JSON Serialize
                         │
                         ▼
                ┌─────────────────┐
                │      Redis      │
                │ Message Transport│
                └────────┬────────┘
                         │
                         ▼
                   APM Server

데이터 전송 포맷은 JSON(JavaScript Object Notation) 을 사용한다.

즉, Agent에서 수집된 Monitoring Data를 JSON 형태로 Serialization한 후 Redis에 전달하고, 서버에서는 Redis로부터 데이터를 수신하여 Deserialization 후 내부 데이터 구조로 변환한다.

1.3 주요 기술적 특징

• C 기반 Native Agent
• 저오버헤드(Low Overhead) 데이터 수집
• 실시간/주기적 모니터링
• Monitoring Data Collector 구조
• JSON 기반 Data Serialization
• Redis 기반 Message Transport
• 비동기 데이터 전송 구조
• 수집 대상별 Collector 모듈화
• Agent와 Server 간 Loose Coupling
  
  
  
  
  

2. APM Server — 데이터 수집 및 서비스 Server

APM Server는 Agent와 Client 사이에서 Monitoring Data의 수집, 저장, 조회 및 전달을 담당하는 중앙 처리 서버이다.

Server는 C 언어 기반으로 구성되며 크게 Agent 대응 영역과 Client 대응 영역으로 구분할 수 있다.

2.1 Agent 대응 — Monitoring Data 수집 및 저장

Agent에서 Redis를 통해 전달한 JSON 데이터를 Server가 수신한다.

Agent
  │
  │ JSON
  ▼
Redis
  │
  ▼
┌───────────────────────────┐
│       APM Server           │
│                           │
│  Redis Receiver           │
│       │                   │
│       ▼                   │
│  JSON Parser              │
│       │                   │
│       ▼                   │
│  Data Validation           │
│       │                   │
│       ▼                   │
│  Data Normalization        │
│       │                   │
│       ├──────────► DB      │
│       │                    │
│       └──────────► Shared  │
│                    Memory  │
└───────────────────────────┘

Server는 Redis를 통해 Agent가 전달한 데이터를 수신하고 다음과 같은 처리 과정을 수행한다.

Redis Receive → JSON Parsing → Validation → Data Processing → Storage

수신 데이터는 실시간 조회가 필요한 데이터와 장기 보관이 필요한 데이터로 구분하여 처리한다.

Shared Memory

실시간 모니터링 화면에서 빠르게 조회해야 하는 데이터는 Shared Memory 기반의 In-Memory Data Store에 저장한다.

Shared Memory를 사용하는 목적은 DB I/O를 최소화하고 Client의 반복적인 조회 요청에 대해 Low Latency 데이터 제공을 하기 위함이다.

Database

장기적인 데이터 보관이 필요한 Monitoring Data는 Database에 저장한다.

Database에는 다음과 같은 용도의 데이터가 저장될 수 있다.

• Historical Monitoring Data
• Performance Statistics
• Transaction History
• 장애 및 Event 정보
• 사용자 조회 이력
• 통계 및 분석 데이터

따라서 서버의 저장 구조는 다음과 같이 구성된다.

                    ┌───────────────┐
                    │  APM Server   │
                    └───────┬───────┘
                            │
                 ┌──────────┴──────────┐
                 │                     │
                 ▼                     ▼
          ┌─────────────┐       ┌─────────────┐
          │ Shared      │       │ Database    │
          │ Memory      │       │             │
          │             │       │ Historical  │
          │ Real-Time   │       │ Data        │
          │ Data        │       │             │
          └─────────────┘       └─────────────┘

즉,

Shared Memory = 실시간 데이터 처리 및 조회 최적화

Database = 장기 데이터 저장 및 이력/통계 조회

라는 역할 분담을 갖는다.

2.2 Client 대응 — Monitoring Data 제공

APM Client가 특정 Monitoring Data를 요청하면 Server는 요청 내용을 분석하여 Shared Memory 또는 Database에서 필요한 데이터를 조회한다.

APM Client
    │
    │ Request
    ▼
 Redis
    │
    ▼
APM Server
    │
    ├────► Shared Memory
    │
    └────► Database
              │
              ▼
        Query / Data Processing
              │
              ▼
          JSON Serialize
              │
              ▼
            Redis
              │
              ▼
          APM Client

Client의 요청에 따라 Server는 다음과 같은 처리를 수행한다.

1. Client Request 수신
2. Request Message Parsing
3. 요청 대상 및 조회 조건 분석
4. Shared Memory 또는 Database 조회
5. 데이터 가공 및 Aggregation
6. JSON Serialization
7. Redis를 통한 Client 전송

특히 실시간 Dashboard의 경우 Shared Memory를 우선적으로 활용하여 빠른 응답시간과 높은 처리량(Throughput) 을 확보할 수 있다.

2.3 Server의 핵심 역할

APM Server는 단순한 데이터 중계 역할이 아니라 다음과 같은 기능을 수행하는 Central Monitoring Data Processing Layer이다.

• Agent Data 수집
• JSON Parsing / Serialization
• Data Validation
• Data Normalization
• Real-Time Data Management
• Shared Memory Management
• Historical Data Persistence
• Monitoring Data Query
• Data Aggregation
• Client Request Processing
• Redis Message Processing
• Agent/Client 간 데이터 중계

따라서 전체 시스템에서 Server는 Data Collection Layer와 Presentation Layer를 연결하는 Core Processing Layer의 역할을 수행한다.

3. APM Client — C# 기반 Monitoring Console

APM Client는 최종 사용자가 시스템의 상태와 성능을 확인하기 위한 Monitoring Console / Visualization Layer이다.

C# 기반의 Windows Desktop Application으로 구현하며, WinForms MDI(Multiple Document Interface) Architecture를 기반으로 여러 모니터링 화면을 하나의 Main Application에서 관리한다.

3.1 데이터 요청 및 수신 구조

Client는 사용자가 화면을 실행하거나 Monitoring 화면을 활성화하면 필요한 데이터를 Server에 요청한다.

┌──────────────────────────────┐
│        APM Client            │
│          C# / WinForms       │
│                              │
│  ┌──────┐ ┌──────┐ ┌──────┐ │
│  │화면1 │ │화면2 │ │화면3 │ │
│  │Dash  │ │Grid  │ │Chart │ │
│  └──┬───┘ └──┬───┘ └──┬───┘ │
│     └────────┼────────┘      │
│              ▼               │
│        Request Manager       │
└──────────────┬───────────────┘
               │
               ▼
             Redis
               │
               ▼
           APM Server

Client에서 발생한 요청은 JSON으로 Serialization하여 Redis를 통해 Server에 전달한다.

Server의 응답 역시 JSON 형태로 전달되며 Client에서는 이를 Parsing하여 해당 화면에서 사용할 수 있는 데이터 모델로 변환한다.

3.2 Push / Pop 기반 데이터 처리

Client와 Server 사이의 데이터 교환은 Redis를 Transport Layer로 사용한다.

개념적으로 다음과 같은 구조를 가진다.

Client
  │
  │ Push Request
  ▼
Redis
  │
  ▼
Server
  │
  │ Data Processing
  ▼
Redis
  │
  │ Pop Response
  ▼
Client

Client에서는 화면별 요청을 생성하고 Redis를 통해 Server에 전달한다.

Server에서 처리된 결과는 다시 Redis를 통해 Client로 전달되며, Client는 수신 데이터를 해당 화면에 전달한다.

이를 Message-based Asynchronous Communication Architecture로 볼 수 있다.

3.3 MDI 기반 Monitoring 화면

Client는 하나의 Main Form에서 여러 Monitoring 화면을 Child Form으로 관리하는 MDI Architecture를 사용한다.

예를 들어 다음과 같은 화면을 동시에 운영할 수 있다.

APM Main Client
│
├── System Monitoring
│
├── DBMS Monitoring
│
├── Middleware Monitoring
│
├── Process Monitoring
│
├── Application Monitoring
│
├── Transaction Monitoring
│
├── Performance Dashboard
│
└── Statistics / Analysis

각 화면은 독립적으로 Server에 데이터를 요청하고, 수신된 데이터를 해당 화면의 Visualization Component를 통해 표현한다.

3.4 Monitoring Data Visualization

Client에서 제공하는 주요 데이터 표현 방식은 다음과 같다.

Dashboard

시스템 전체 상태를 한눈에 파악할 수 있도록 주요 성능지표를 KPI(Key Performance Indicator) 형태로 표현한다.

예:

• CPU Usage
• Memory Usage
• TPS
• Response Time
• Error Count
• Active Session
• Process Count
• Queue Size

Grid

대량의 Monitoring Data 또는 상세 데이터를 Tabular Data 형태로 표시한다.

예:

• Process List
• Transaction List
• SQL List
• Application Request List
• 장애/Event List

Chart

시간에 따른 성능 변화를 시각화한다.

예:

• CPU Trend
• Memory Trend
• TPS Trend
• Response Time Trend
• Transaction Trend
• Error Trend

이를 통해 사용자는 현재 상태뿐만 아니라 Time-Series 기반의 Performance Trend를 분석할 수 있다.

전체 시스템 아키텍처

전체적으로 APM 시스템은 다음과 같은 3-Tier / Layered Architecture 형태로 구성할 수 있다.

┌─────────────────────────────────────────────────────────┐
│                    APM CLIENT                           │
│                  C# / WinForms                         │
│                                                         │
│  Dashboard │ Grid │ Chart │ Monitoring │ Statistics    │
│                         │                               │
│                  Request / Response                     │
└─────────────────────────┬───────────────────────────────┘
                          │
                          │ JSON
                          │ Redis
                          ▼
┌─────────────────────────────────────────────────────────┐
│                    APM SERVER                           │
│                       C                                 │
│                                                         │
│  Agent Receiver                                         │
│       │                                                 │
│       ├── JSON Parser                                   │
│       ├── Data Validation                               │
│       ├── Data Processing                               │
│       ├── Data Aggregation                              │
│       │                                                 │
│       ├──────────────► Shared Memory                    │
│       │                 (Real-Time Data)                │
│       │                                                 │
│       └──────────────► Database                         │
│                         (Historical Data)               │
│                                                         │
│                  Client Request Handler                  │
└─────────────────────────┬───────────────────────────────┘
                          │
                          │ JSON
                          │ Redis
                          ▼
┌─────────────────────────────────────────────────────────┐
│                    APM AGENT                            │
│                       C                                 │
│                                                         │
│  System Collector                                      │
│  DBMS Collector                                        │
│  Middleware Collector                                  │
│  Process Collector                                     │
│  Application Collector                                 │
│                                                         │
│                Monitoring Data Collection                │
└─────────────────────────────────────────────────────────┘

기술 구성 요약

한 문장으로 정리하면

APM 시스템은 C 기반 Agent가 System/DBMS/Middleware/Process/Application의 성능 데이터를 수집하고, Redis/JSON 기반의 Message-Oriented Communication을 통해 C 기반 Server로 전달하며, Server는 Shared Memory와 Database를 이용하여 실시간 및 이력 데이터를 관리하고, C# 기반 Client가 이를 요청하여 Dashboard, Grid, Chart 등의 형태로 시각화하는 3-Tier Monitoring Architecture로 구성된다.

1. Kotlin이란?

Kotlin은 프로그래밍 언어입니다.

가장 쉽게 말하면:

Java와 매우 호환성이 좋은 현대적인 언어

입니다.

Kotlin 코드는 주로 JVM(Java Virtual Machine) 위에서 실행됩니다.

Kotlin
   ↓ 컴파일
JVM Bytecode
   ↓
JVM

따라서 Java와 Kotlin은 서로 매우 밀접한 관계입니다.

2. Java와 Kotlin 관계

예를 들어 Java:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello");
    }
}

Kotlin:

fun main() {
    println("Hello")
}

Kotlin은 Java보다 비교적 간결하게 작성할 수 있습니다.

그리고 중요한 특징은:

Java Library
       ↕
Kotlin

호환성이 매우 좋다는 것입니다.

예를 들어 기존 Java 라이브러리를 Kotlin에서 사용할 수 있습니다.

3. 왜 Backend Server에 Kotlin을 사용할 수 있나?

Backend Server는 다음 역할을 합니다.

Browser
   ↓
HTTP / REST API
   ↓
Backend Server
   ↓
Redis / DB

이 Backend를 Java로 만들 수도 있습니다.

Java
+
Spring Boot

그런데 Kotlin으로도 만들 수 있습니다.

Kotlin
+
Spring Boot

즉:

Java Backend

와

Kotlin Backend

는 거의 같은 영역에서 경쟁하는 선택지입니다.

예

방식 1

Java
+
Spring Boot

또는

방식 2

Kotlin
+
Spring Boot

따라서 이전에 제가 작성한:

Backend Server 또는 Android Agent

라는 의미는 다음과 같습니다.

Kotlin을 Backend Server 개발 언어로 사용할 수 있다.
또는
Android Agent 개발 언어로 사용할 수 있다.

입니다.

4. Android Agent에 사용하는 이유

현재 Android 개발에서는 Kotlin이 매우 많이 사용됩니다.

예를 들어:

Android Application
       │
       ├─ CPU 정보
       ├─ Memory 정보
       ├─ Network 정보
       └─ Application 정보
               │
               ▼
            APM Server

APM Agent가 Android Application 안에 들어간다면 Kotlin을 사용할 수 있습니다.

Android App
    │
    ├─ Kotlin
    │
    └─ APM Agent
           │
           ▼
       APM Server

예를 들어:

fun sendMetric(cpu: Double, memory: Double) {

    // APM 서버에 데이터 전송
}

같은 형태입니다.

5. 그런데 현재 APM에서는 Kotlin이 꼭 필요한가?

아닙니다.

현재 말씀하신 환경에서는 Kotlin이 꼭 필요하지 않을 가능성이 큽니다.

현재 사용하시는 APM을 보면:

C Server
↓
Redis
↓
C# WinForms Client

입니다.

이를 Web 구조로 변경한다면:

C Server
↓
Redis
↓
Java Backend
↓
TypeScript Frontend

이면 충분합니다.

즉:

C
Java
TypeScript
HTML/CSS

만으로 구축 가능합니다.

6. Kotlin은 언제 사용하는 것이 좋은가?

Kotlin을 사용하는 대표적인 경우입니다.

① Android APM Agent

Android Application
       ↓
Kotlin APM Agent
       ↓
APM Server

가장 자연스러운 사용 사례입니다.

② Java 대신 Backend 개발

Java Spring Boot

대신:

Kotlin Spring Boot

를 사용할 수 있습니다.

하지만:

Java + Kotlin

을 굳이 동시에 사용할 필요는 없습니다.

예를 들어:

❌ 복잡할 수 있는 구조

Java Backend
+
Kotlin Backend

보다는

⭕ 하나를 선택

Java Backend

또는

Kotlin Backend

가 관리하기 쉽습니다.

7. 현재 APM에 대한 제 의견

사용자님은 현재:

• C
• C#
• WinForms
• Redis
• TCP
• APM

경험이 많으시므로, 새로운 APM을 만든다면 저는 다음을 추천합니다.

┌──────────────────────┐
│ APM Agent            │
│                      │
│ C / Java             │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ APM Collector        │
│                      │
│ C                    │
└──────────┬───────────┘
           │
           ▼
         Redis
           │
           ▼
┌──────────────────────┐
│ Backend API          │
│                      │
│ Java + Spring Boot   │
└──────────┬───────────┘
           │
     REST / WebSocket
           │
           ▼
┌──────────────────────┐
│ Web Client           │
│                      │
│ TypeScript + React   │
│ HTML + CSS           │
└──────────────────────┘

핵심 정리

따라서 현재 PC/서버 APM을 Web 기반으로 전환하는 목적이라면 Kotlin은 필수 기술이 아닙니다.

Kotlin은 Java Backend를 Kotlin으로 개발하고 싶거나, Android용 APM Agent를 개발할 때 의미가 큰 기술이라고 이해하시면 가장 정확합니다.

질문)
APM 구축시에 기존기술 : 서버 c, 클라이언트 c# 일 경우에 아래의 변경기술로 전환시에 어떤 변경사항이 있을까요? 서버는 비슷할것 같고, 클라이언트는 어떻게 구축하는것이 바람직할까요? 아래의 기술을 통해서 변경기술 : C, Java, Kotlin, TypeScript, HTML/CSS

답변)

APM을 C 서버 + C# WinForms 클라이언트 형태로 구축하고 계신 상황이라면,

변경 기술: C, Java, Kotlin, TypeScript, HTML/CSS

로 전환할 때 가장 중요한 변화는 서버보다 클라이언트 아키텍처가 크게 바뀐다는 것입니다.

결론부터 말씀드리면 저는 다음 구조를 가장 권장합니다.

┌──────────────────────────────────────────────┐
│                  APM Agent                   │
│                                              │
│ C / Java / Kotlin 등의 서비스                │
└──────────────────┬───────────────────────────┘
                   │ TCP / HTTP / gRPC
                   ▼
┌──────────────────────────────────────────────┐
│                 APM Server                   │
│                                              │
│ C 기반 기존 수집 서버                        │
│ 또는 Java 기반 Backend                       │
│                                              │
│ 데이터 수집 / 집계 / 분석 / 저장             │
└──────────────────┬───────────────────────────┘
                   │ REST API / WebSocket
                   ▼
┌──────────────────────────────────────────────┐
│              Web APM Client                  │
│                                              │
│ TypeScript + React 또는 Vue                  │
│ HTML / CSS                                   │
└──────────────────────────────────────────────┘
                   │
                   ▼
             Chrome / Edge

1. 기존 구조

현재 구조를 단순화하면 아마 이런 형태에 가깝습니다.

[C APM Server]
       │
       │ TCP / Redis / 자체 Protocol
       ▼
[C# WinForms Client]
       │
       ├─ DataGridView
       ├─ TreeView
       ├─ ScottPlot
       └─ 각종 화면

예를 들어 현재 작업하셨던 구조처럼:

C Server
   ↓
Redis
   ↓
C# Client
   ↓
DataGridView / TreeView / Chart

입니다.

2. 변경 후 가장 큰 변화

변경 기술에:

C
Java
Kotlin
TypeScript
HTML/CSS

가 들어간다면 자연스럽게 다음과 같이 역할을 나누는 것이 좋습니다.

즉,

C# WinForms Client

가 없어지고,

TypeScript Web Client

로 변경되는 것이 가장 자연스럽습니다.

3. 서버는 기존 C를 유지할 수 있나?

네. 가능합니다.

오히려 현재 APM 서버가 이미 안정적으로 동작하고 있다면 굳이 C 서버 전체를 Java로 다시 만들 필요는 없습니다.

예:

┌────────────────────┐
│ 기존 C APM Server   │
│                    │
│ TCP 수신           │
│ 데이터 분석        │
│ Redis              │
└─────────┬──────────┘
          │
          │ HTTP API
          ▼
┌────────────────────┐
│ Java API Server    │
│                    │
│ REST API           │
│ WebSocket          │
└─────────┬──────────┘
          │
          ▼
     Web Browser

이 구조가 현실적인 점진적 전환 방법입니다.

4. 가장 권장하는 전체 구조

제가 현재 사용하시는 APM 구조를 고려하면 다음을 추천합니다.

                    APM AGENT

     C Agent       Java Agent       Kotlin Agent
        │               │               │
        └───────────────┼───────────────┘
                        │
                        ▼
              ┌─────────────────┐
              │   C Collector   │
              │                 │
              │ TCP Server      │
              │ Queue           │
              │ Parser          │
              └────────┬────────┘
                       │
                       ▼
                 Redis / DB
                       │
                       ▼
              ┌─────────────────┐
              │ Java Backend    │
              │                 │
              │ REST API        │
              │ WebSocket       │
              │ Authentication  │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │ Web Frontend    │
              │                 │
              │ TypeScript      │
              │ React/Vue       │
              │ HTML/CSS        │
              └─────────────────┘

5. 왜 C# WinForms 대신 TypeScript Web인가?

현재 C# WinForms는 다음과 같은 구조입니다.

DataGridView
TreeView
FormsPlot
Timer
Invoke()

Web에서는 이렇게 변경됩니다.

6. 현재 APM 화면을 Web로 변경하면

예를 들어 현재:

APMMain
 ├─ 서버 목록
 ├─ TreeView
 ├─ Grid
 ├─ CPU
 ├─ Memory
 ├─ TPS
 └─ Response Time Chart

라면 Web에서는:

APM Dashboard
│
├── Header
│
├── Left Menu
│
├── Server Tree
│
├── Server List Grid
│
├── CPU Chart
│
├── Memory Chart
│
└── Transaction Chart

이런 Component 구조가 됩니다.

App
│
├── Header
│
├── Sidebar
│
├── ServerTree
│
├── ServerGrid
│
├── CpuChart
│
├── MemoryChart
│
└── TransactionChart

7. TypeScript Framework는 무엇이 좋을까?

제가 가장 추천하는 것은 React입니다

TypeScript
+
React

구조입니다.

React
 ├── Component 구조
 ├── TypeScript
 ├── WebSocket
 ├── REST API
 └── 다양한 Chart/Grid Library

APM 화면은 일반 홈페이지보다:

• 실시간 데이터
• 많은 Grid
• Chart
• Tree
• Dashboard
• WebSocket

비중이 높습니다.

따라서 React가 상당히 적합합니다.

8. APM Client의 실시간 통신

현재 C#에서는 아마 이런 구조가 있을 것입니다.

Timer
   ↓
Redis 요청
   ↓
결과 수신
   ↓
Display()

예:

private void Display(PWInterface ifReceive)
{
    ...
}

Web에서는 크게 두 가지 방법이 있습니다.

방법 1. Polling

Browser
   │
   │ 1초마다 REST API
   ▼
Java Backend
   │
   ▼
Redis

TypeScript:

setInterval(async () => {

    const response =
        await fetch("/api/server/list");

    const data =
        await response.json();

    updateGrid(data);

}, 1000);

장점

• 구현 쉬움
• 기존 구조와 유사

단점

APM 서버가 많으면:

Client 100명

100명 × 1초

계속 요청이 발생합니다.

9. APM에는 WebSocket을 더 권장

APM은 실시간 화면이 많으므로:

WebSocket

이 더 적합합니다.

Browser
   │
   │ WebSocket 연결
   ▼
Java Backend
   │
   │ Redis Subscribe
   ▼
Redis

데이터가 발생하면:

APM Data 발생
      ↓
Redis
      ↓
Java Backend
      ↓
WebSocket
      ↓
Browser
      ↓
React 화면 Update

이 구조입니다.

10. 현재 C# Invoke()는 없어집니다

현재 WinForms에서는:

treeview.Invoke(new MethodInvoker(delegate
{
    ...
}));

가 필요합니다.

왜냐하면:

Worker Thread
       ↓
UI Thread

가 분리되어 있기 때문입니다.

React에서는 일반적으로:

setState(data);

처럼 상태를 변경하면 됩니다.

예:

const [servers, setServers] =
    useState<Server[]>([]);

webSocket.onmessage = (event) => {

    const data =
        JSON.parse(event.data);

    setServers(data);
};

React가 화면을 다시 렌더링합니다.

즉 현재의:

Invoke
BeginInvoke
MethodInvoker

개념이 상당 부분 없어집니다.

11. Java와 Kotlin은 둘 다 Backend에 필요한가?

개인적으로는 둘 다 사용할 필요는 없습니다.

예를 들어:

C
Java
Kotlin
TypeScript
HTML/CSS

라고 해서 모든 기술을 반드시 동시에 Backend에 사용할 필요는 없습니다.

저라면:

C          → APM Agent / Collector
Java       → Backend API
TypeScript → Frontend
HTML/CSS   → UI

를 사용합니다.

즉:

C + Java + TypeScript

중심입니다.

Kotlin은 필요하면:

Java Backend

대신 선택할 수 있습니다.

Java 또는 Kotlin

이라고 보는 것이 좋습니다.

12. 제가 가장 추천하는 실제 구성

Agent

C
Java
Kotlin

각 시스템의 Agent.

Collector

C

기존 서버를 최대한 유지.

C Collector
    ↓
Redis

Backend

Java
Spring Boot

역할:

REST API
WebSocket
로그인
권한관리
Redis 접근
DB 접근

Frontend

TypeScript
React
HTML
CSS

역할:

APM Dashboard
Grid
Tree
Chart
Monitoring

최종 권장 구조

┌──────────────────────────────────────┐
│              APM AGENT               │
│                                      │
│   C / Java / Kotlin                  │
└──────────────────┬───────────────────┘
                   │
                   │ TCP
                   ▼
┌──────────────────────────────────────┐
│             C COLLECTOR              │
│                                      │
│ 기존 APM Server                      │
│ Parser                               │
│ Queue                                │
└──────────────────┬───────────────────┘
                   │
                   ▼
              Redis / DB
                   │
                   ▼
┌──────────────────────────────────────┐
│           JAVA BACKEND               │
│                                      │
│ Spring Boot                          │
│ REST API                             │
│ WebSocket                            │
│ Authentication                       │
└──────────────────┬───────────────────┘
                   │
                   ▼
┌──────────────────────────────────────┐
│          TYPESCRIPT FRONTEND         │
│                                      │
│ React                                │
│ Grid                                 │
│ Tree                                 │
│ Chart                                │
│ Dashboard                            │
└──────────────────────────────────────┘

핵심 결론

현재 사용 중인 APM이 이미 C Server + Redis + C# WinForms 구조라면, 저는 서버를 전부 다시 개발하지 않고 다음처럼 단계적으로 전환하는 것이 가장 현실적이라고 봅니다.

현재

C Server
   ↓
Redis
   ↓
C# WinForms


변경

C Server
   ↓
Redis
   ↓
Java API Server
   ↓
WebSocket / REST
   ↓
TypeScript + React

즉, 가장 큰 변경 대상은 C# WinForms Client이고, 이것을 TypeScript 기반 Web APM Client로 재구축하는 것이 바람직합니다.

질문)
Win Form 안에 폰트를 가진 컨트롤이 여러개 있을떄에 폰트를 설정하지 않았을경우에, 어떤 폰트를 가지게 되나요?

답변)

WinForms에서는 컨트롤마다 폰트를 따로 지정하지 않았다고 해서 폰트가 없는 상태가 되는 것은 아닙니다. 기본적으로 부모 컨트롤의 Font를 상속(inherit) 받습니다.

예를 들어

Form
 ├─ Panel
 │   ├─ Label1
 │   ├─ Label2
 │   └─ Button1
 └─ TextBox1

Form의 폰트를:

this.Font = new Font("맑은 고딕", 12F);

로 지정하고 각각의 컨트롤에는 Font를 지정하지 않았다면:

Form
 ↓
맑은 고딕 12
 ↓
Panel
 ↓
Label1     → 맑은 고딕 12
Label2     → 맑은 고딕 12
Button1    → 맑은 고딕 12

처럼 부모의 Font를 물려받습니다.

그런데 중요한 부분이 있습니다

WinForms 컨트롤의 Font 속성을 보면 보통 디자이너에서:

Font = [System.Drawing.Font]

처럼 보이더라도 실제로는 Control.Font가 Ambient Property(주변 속성) 방식으로 부모에게서 값을 상속받을 수 있습니다.

즉:

label1.Font

을 호출했을 때 반드시

"Label 자체에 저장된 Font"

를 의미하는 것은 아닙니다.

부모로부터 상속받은 최종 Font가 반환될 수 있습니다.

그럼 Form에도 Font를 설정하지 않았다면?

여기가 질문의 핵심일 것 같습니다.

예를 들어:

public Form1()
{
    InitializeComponent();
}

이고

this.Font

도 별도로 설정하지 않았다면, WinForms의 기본 Font가 사용됩니다.

Windows/WinForms 환경에서는 일반적으로 시스템 기본 UI 폰트를 기준으로 하며, 현대 Windows에서는 Segoe UI 계열이 기본인 경우가 많습니다.

다만 OS 버전, DPI, WinForms 런타임/테마 등의 환경에 따라 실제 기본 Font가 달라질 수 있으므로 "항상 Segoe UI다"라고 고정해서 생각하면 안 됩니다.

실제로 확인하려면

현재 프로그램에서 다음 코드를 실행해 보면 됩니다.

MessageBox.Show(
    "Form Font : " + this.Font.Name +
    "\nSize : " + this.Font.Size);

또는:

MessageBox.Show(
    "Label Font : " + label1.Font.Name +
    "\nSize : " + label1.Font.Size);

예를 들어:

Form Font : Microsoft Sans Serif
Size : 8.25

처럼 나올 수도 있고,

환경에 따라:

Segoe UI
9

등으로 나올 수도 있습니다.

부모-자식 관계가 중요합니다

예를 들어:

this.Font = new Font("맑은 고딕", 10F);

panel1.Font = new Font("굴림", 12F);

// label1은 Font를 설정하지 않음

이라면:

Form
└─ Font = 맑은 고딕 10

   Panel
   └─ Font = 굴림 12

      Label
      └─ Font = 굴림 12  ← Panel에서 상속

입니다.

즉 가장 가까운 부모의 Font를 따라갑니다.

반대로 Label에 직접 Font를 지정하면

this.Font = new Font("맑은 고딕", 10F);

panel1.Font = new Font("굴림", 12F);

label1.Font = new Font("Arial", 20F);

이면:

Form
 └─ 맑은 고딕 10
     │
     └─ Panel
          └─ 굴림 12
               │
               └─ Label
                    └─ Arial 20  ← 직접 지정

이 됩니다.

그리고 지금 하시는 WinForms 변환 작업에서는 이 부분이 상당히 중요합니다.

기존 C1 컨트롤이나 다른 서드파티 컨트롤에서 컨트롤별 Font가 개별적으로 저장되어 있었다면, DataGridView, TreeView 등으로 바꾸면서 Font를 별도로 지정하지 않았을 때 부모 Form의 Font를 따라가면서 화면이 달라질 수 있습니다.

그래서 기존 화면과 동일하게 만들려면 단순히:

dataGridView1.Font = ...

만 보는 게 아니라,

Form.Font
   ↓
Panel.Font
   ↓
컨트롤.Font

의 Font 상속 구조 자체를 확인하는 것이 좋습니다.

질문)
BeginInit() / EndInit()을 생략한 경우와 생략하지 않았을경우에 극단적으로 차이를 보여주는 예제코드를 작성해주세요.

보통 WinForms 디자이너가 자동으로 넣어줍니다

예를 들어 어떤 컨트롤이 ISupportInitialize를 구현하고 있고, Visual Studio 디자이너가 해당 컨트롤을 초기화할 때 필요하다고 판단하면 .Designer.cs에 다음과 같이 생성합니다.

((System.ComponentModel.ISupportInitialize)(this.someControl)).BeginInit();

this.someControl.Location = new System.Drawing.Point(10, 10);
this.someControl.Name = "someControl";
this.someControl.Size = new System.Drawing.Size(200, 100);

((System.ComponentModel.ISupportInitialize)(this.someControl)).EndInit();

즉, 직접 매번 작성하는 것이 아닙니다.

특히 디자이너에서 컨트롤을 배치하고 속성을 변경하면 Visual Studio가 필요한 경우 자동으로 .Designer.cs에 넣어줍니다.

그래서 제가 한 문장으로 표현한다면:

BeginInit() / EndInit()의 존재 이유는 "초기화 작업을 하나의 원자적인 초기화 과정처럼 처리하기 위해서"이고, 그 결과로 불필요한 반복 처리와 처리시간을 줄일 수 있다.

답변)

BeginInit() / EndInit()의 차이가 극단적으로 보이도록 하려면, 실제 WinForms 컨트롤보다 ISupportInitialize를 직접 구현한 테스트 클래스를 만드는 것이 가장 명확합니다.

아래 예제에서는 BeginInit()이 없으면 설정할 때마다 무거운 작업을 실행하고, BeginInit() / EndInit()을 사용하면 마지막에 딱 한 번만 실행하도록 만들어 보겠습니다.

예제 1 — 차이가 극단적으로 보이는 코드

using System;
using System.ComponentModel;
using System.Diagnostics;

public class MyControl : ISupportInitialize
{
    private bool _initializing = false;

    private int _width;
    private int _height;
    private string _text;
    private int _value;

    public void BeginInit()
    {
        _initializing = true;

        Console.WriteLine(">>> BeginInit()");
    }

    public void EndInit()
    {
        _initializing = false;

        Console.WriteLine(">>> EndInit()");

        // 최종 설정이 끝났으므로 한 번만 실행
        HeavyWork();
    }

    public int Width
    {
        get { return _width; }
        set
        {
            _width = value;

            if (!_initializing)
                HeavyWork();
        }
    }

    public int Height
    {
        get { return _height; }
        set
        {
            _height = value;

            if (!_initializing)
                HeavyWork();
        }
    }

    public string Text
    {
        get { return _text; }
        set
        {
            _text = value;

            if (!_initializing)
                HeavyWork();
        }
    }

    public int Value
    {
        get { return _value; }
        set
        {
            _value = value;

            if (!_initializing)
                HeavyWork();
        }
    }

    private void HeavyWork()
    {
        Console.WriteLine(
            "HeavyWork 실행 : " +
            "Width=" + _width +
            ", Height=" + _height +
            ", Text=" + _text +
            ", Value=" + _value);

        // 극단적인 차이를 만들기 위한 가상의 무거운 작업
        System.Threading.Thread.Sleep(500);
    }
}

이제 생략한 경우를 보겠습니다.

1. BeginInit() / EndInit()을 생략

static void TestWithoutInit()
{
    MyControl control = new MyControl();

    Stopwatch sw = Stopwatch.StartNew();

    control.Width = 100;
    control.Height = 200;
    control.Text = "Hello";
    control.Value = 100;

    sw.Stop();

    Console.WriteLine();
    Console.WriteLine(
        "소요 시간 = " + sw.ElapsedMilliseconds + " ms");
}

실행하면 대략:

HeavyWork 실행 : Width=100, Height=0, Text=, Value=0
HeavyWork 실행 : Width=100, Height=200, Text=, Value=0
HeavyWork 실행 : Width=100, Height=200, Text=Hello, Value=0
HeavyWork 실행 : Width=100, Height=200, Text=Hello, Value=100

소요 시간 = 2000 ms

즉,

Width 설정
    ↓
HeavyWork()

Height 설정
    ↓
HeavyWork()

Text 설정
    ↓
HeavyWork()

Value 설정
    ↓
HeavyWork()

총 4번 실행됩니다.

2. BeginInit() / EndInit() 사용

이번에는:

static void TestWithInit()
{
    MyControl control = new MyControl();

    Stopwatch sw = Stopwatch.StartNew();

    control.BeginInit();

    control.Width = 100;
    control.Height = 200;
    control.Text = "Hello";
    control.Value = 100;

    control.EndInit();

    sw.Stop();

    Console.WriteLine();
    Console.WriteLine(
        "소요 시간 = " + sw.ElapsedMilliseconds + " ms");
}

실행하면:

>>> BeginInit()

>>> EndInit()

HeavyWork 실행 : Width=100, Height=200, Text=Hello, Value=100

소요 시간 = 500 ms

이번에는:

BeginInit()
    ↓
Width 설정       ─┐
Height 설정       │
Text 설정         ├── HeavyWork 실행 안 함
Value 설정        │
                  │
EndInit()         ─┘
    ↓
HeavyWork()       ← 딱 한 번

따라서 극단적으로 비교하면:

설정하는 속성이 100개라면:

BeginInit/EndInit 없음
→ HeavyWork 100회
→ 약 50초

BeginInit/EndInit 사용
→ HeavyWork 1회
→ 약 0.5초

이렇게까지 차이가 날 수 있습니다.

그런데 실제 WinForms에서는 조금 다릅니다

여기가 중요합니다.

실제 ISupportInitialize 컨트롤이 반드시 위와 같이 동작한다는 뜻은 아닙니다.

BeginInit() / EndInit()의 정확한 동작은 그 컨트롤을 만든 개발자가 어떻게 구현했느냐에 따라 달라집니다.

예를 들어 실제 컨트롤 내부가:

public void BeginInit()
{
    _initializing = true;
}

public void EndInit()
{
    _initializing = false;
    Rebuild();
}

처럼 만들어져 있을 수도 있고,

public void BeginInit()
{
    // 아무 것도 안 함
}

public void EndInit()
{
    // 아무 것도 안 함
}

일 수도 있습니다.

따라서

ISupportInitialize를 구현했다 = BeginInit/EndInit을 빼면 반드시 문제가 발생한다

는 것은 아닙니다.

가장 중요한 핵심

BeginInit() / EndInit()의 본질은 "초기 설정을 하는 동안 컨트롤에게 아직 최종 상태가 아니라고 알려주는 것"입니다.

예를 들어 디자이너가 다음처럼 20개의 속성을 설정한다고 생각해 보겠습니다.

control.Width = 100;
control.Height = 200;
control.Text = "TEST";
control.Value = 10;
control.Font = ...;
control.Color = ...;
control.DataSource = ...;

// ...

이때 컨트롤 입장에서:

Width = 100
    ↓
"아직 초기화 중이네"

Height = 200
    ↓
"아직 초기화 중이네"

Text = TEST
    ↓
"아직 초기화 중이네"

...

마지막
    ↓
EndInit()
    ↓
"이제 설정 끝났구나!"
    ↓
실제 초기화

라는 구조를 만들 수 있습니다.

그리고 BeginUpdate()와 비교하면 더 쉽게 이해됩니다

지금 작업하시는 TreeView의 경우:

treeview.BeginUpdate();

treeview.Nodes.Clear();

treeview.Nodes.Add(...);
treeview.Nodes.Add(...);
treeview.Nodes.Add(...);
treeview.Nodes.Add(...);

treeview.EndUpdate();

이것은:

화면 그리기를 잠시 중단했다가 한 번에 보여준다.

입니다.

반면:

control.BeginInit();

control.Width = 100;
control.Height = 200;
control.Text = "TEST";

control.EndInit();

이것은:

컨트롤의 초기 설정 작업을 하나의 초기화 과정으로 묶는다.

입니다.

즉,

BeginInit / EndInit
        ↓
"컨트롤 초기화"

BeginUpdate / EndUpdate
        ↓
"화면 업데이트"

라고 구분하면 거의 정확합니다.

한마디로 표현하면:

Windows에 설치된 하나의 Redis/MySQL 서비스를 Windows의 C# Client와 WSL Ubuntu의 APM Server가 TCP/IP를 통해 공동 사용한다.

1. WSL의 가상 네트워크

WSL Ubuntu는 Windows와 별도의 Linux 환경이지만, Windows Host와 네트워크로 연결되어 있습니다.

따라서 Ubuntu 입장에서는 Windows에서 실행 중인 Redis/MySQL을:

로 접근할 수 있습니다.

예를 들어:

2. Redis/MySQL의 TCP 서버

Redis와 MySQL은 단순히 "Windows 프로그램"이 아닙니다.

핵심적으로는 TCP 서버입니다.

따라서 접속하는 프로그램이 Windows 프로그램이든 Linux 프로그램이든 상관없습니다.

Redis/MySQL이 어떤 OS에서 실행되고 있는지는 클라이언트 입장에서는 중요하지 않습니다.

설치하려는 ScottPlot.WinForms 5.1.59는 .NET Framework 4.6.1을 지원하지 않습니다.

따라서 이전에 제가 말씀드린 "4.6.2 이상도 지원"이라는 부분은 현재 설치하려는 ScottPlot 5.1.59 기준으로는 정확하지 않았습니다.

가장 적절한 해결 방법

현재 프로젝트를 가능하다면:

로 올리는 것을 가장 추천합니다.

특히 지금 프로젝트가 기존 C1Chart 기반의 오래된 WinForms 프로그램이므로, 당장 .NET 8로 전환하는 것보다 .NET Framework 4.8로 먼저 올리는 것이 훨씬 안전합니다.

1. 현재 프로젝트의 Target Framework 변경

Visual Studio에서:

을

로 변경합니다.

프로젝트를 다시 로드하라는 메시지가 나오면 재로드합니다.

2. 다시 설치

Package Manager Console에서:

실행합니다.

그러면 현재처럼

이 아니라

을 대상으로 패키지를 설치하게 됩니다.

만약 .NET Framework 4.6.1을 절대 변경할 수 없다면

그 경우에는 ScottPlot 5.1.59를 사용하면 안 됩니다.

ScottPlot의 구버전 중 현재 프로젝트와 호환되는 버전을 찾아야 합니다.

Windows 11에서는 .NET Framework 4.8 계열이 기본적으로 포함되어 있습니다. Microsoft 공식 문서에서도 Windows 11 21H2에는 4.8, 이후 버전에는 4.8.1이 포함되어 있다고 명시합니다.

중요한 점은 오프라인 설치 Windows 11이라는 조건입니다.

Windows 11 버전별

즉, Windows 11이라면 최소한 .NET Framework 4.8이 기본적으로 들어있다고 생각하셔도 됩니다.

그리고 아주 중요한 부분이 하나 있습니다.

4.8.1이 설치되어 있어도 4.8 프로젝트를 실행할 수 있습니다

.NET Framework 4.x는 In-place Update 방식이라 한 시스템에 4.6.1, 4.8, 4.8.1을 각각 독립적으로 설치하는 구조가 아닙니다. 4.8.1은 기존 4.x를 대체하며 4.8용으로 작성된 프로그램도 지원합니다.

따라서 현재 프로젝트를:

로 변경해도, Windows 11 배포 PC에서 별도의 .NET Framework 4.8 설치 프로그램을 반드시 실행해야 하는 것은 아닙니다.

다만 개발 PC에서 Visual Studio가 **.NET Framework 4.8 Developer Pack / Targeting Pack**을 필요로 할 수 있습니다. 이것은 런타임과 별개의 문제입니다. Microsoft도 개발 환경에서는 Developer Pack이 필요할 수 있다고 설명합니다.

지금 상황에서는

현재 APM이 .NET Framework 4.6.1이고 ScottPlot 5 설치가 실패했으므로 저는 다음 순서로 진행하는 것을 추천합니다.

그리고 오프라인 배포를 고려한다면 4.8보다 4.8.1로 올릴 필요가 있는지도 별도로 판단할 수 있습니다. 현재 Windows 11이 주 대상이라면 4.8.1이 기본 포함되는 버전이 많기 때문에 4.8.1을 타겟으로 하는 것도 가능합니다.

현재 코드에서는 BLPop()을 다시 호출할 때 기존 RedisClient의 연결을 통해 다시 통신을 시도합니다. 다만 "새로운 TCP 연결을 무조건 새로 만든다"와 "Redis 서버에 다시 접속을 시도한다"는 것은 구분해야 합니다.

현재 코드 흐름은:

이것은 Init()에서 처음 한 번만 실행됩니다.

그 이후에는 계속 같은 _receiveRedis 객체에 대해:

을 호출합니다.

그리고 Worker가 끝나면:

를 다시 호출합니다.

즉:

중요한 점

RunWorkerAsync()가 다시 실행될 때:

를 다시 하는 것은 아닙니다.

따라서 코드상으로는:

이 아닙니다.

정확히는:

입니다.

여기서 실제 TCP 소켓을 내부적으로 재사용하는지, 끊어진 소켓을 ServiceStack.Redis가 내부적으로 다시 연결하는지는 현재 올려주신 애플리케이션 코드만으로는 확정할 수 없습니다. 그 부분은 ServiceStack.Redis 라이브러리의 RedisClient 구현에 해당합니다.

그래서 현재 코드에서 확실하게 말할 수 있는 것은

Redis 서버가 죽어 있을 때

→ 예외 발생
→ recvWorker_DoWork() 종료
→ recvWorker_RunWorkerCompleted() 실행
→ RunWorkerAsync()
→ 다시 BLPop(key, 10) 호출

이라는 반복 재시도 구조입니다.

따라서 서버가 복구되면 이후 BLPop() 호출에서 정상적으로 통신이 이루어질 가능성이 있습니다.

다만 "서버가 복구되면 반드시 새 TCP 연결을 맺는다"까지 현재 코드만으로 보장할 수는 없습니다.

그리고 한 가지 더 중요한 문제가 있습니다.

현재:

에서 Redis 접속 오류를 그냥 기록하고 끝냅니다.

그 후 Completed에서 무조건 다시 Worker를 시작합니다.

따라서 현재 구조는 사실상:

BLPop() → Redis 통신 실패 → 0초에 가깝게 다시 BLPop() → 실패 → 다시 BLPop()

이 될 수도 있습니다.

즉 재접속 간격을 별도로 두는 Thread.Sleep()이나 backoff 로직은 현재 코드에는 없습니다.

현재 올려주신 코드에서 Redis 접속 재시도를 직접 하는 코드는 recvWorker_RunWorkerCompleted()에 있습니다.

핵심 코드는 이것입니다.

파일 기준으로는 549~557라인입니다.

실제 흐름

Init()에서 최초 1회:

가 실행됩니다.

그러면:

에서 실제 Redis 통신:

을 합니다.

접속 실패나 timeout 등의 이유로 recvWorker_DoWork()가 끝나면 RunWorkerCompleted가 호출됩니다.

그리고 바로:

를 실행합니다.

즉:

이렇게 반복됩니다.

다만 아주 중요한 차이가 있습니다

이 코드가 new RedisClient()를 다시 하는 재접속 코드는 아닙니다.

Init()에서 만들어진:

객체를 그대로 사용합니다.

따라서 정확히 표현하면:

RedisClient를 새로 생성해서 재접속하는 것이 아니라, 기존 _receiveRedis 객체를 사용하여 BLPop()을 다시 시도하는 구조입니다.

즉 recvWorker_RunWorkerCompleted()가 하는 것은 Worker 재실행이고, 그 결과 BLPop()이 다시 호출되는 것입니다.

Send 쪽도 재시도 구조가 있습니다

sendWorker_RunWorkerCompleted()에서:

를 합니다.

따라서 Send Queue에 데이터가 남아 있다면 다시 RPush()를 시도합니다.

하지만 Receive 쪽은 Queue와 관계없이 매번 재실행되는 것이 차이입니다.

이것이 현재 코드에서의 Redis 재시도 메커니즘입니다.

올려주신 전체 APMMultipleRedisManager 코드를 기준으로 보면, 앞서 말씀드린 것보다 정확하게 판단할 수 있습니다.

결론부터 말씀드리면:

현재 코드는 접속 불능 서버에 대해서도 recvWorker가 살아서 계속 재시도하는 구조입니다.

반면 sendWorker는 작업이 들어올 때만 실행되고, Redis 통신 실패 후에는 해당 작업이 끝나면서 Worker 자체는 종료됩니다. 이후 새로운 송신 요청이 들어오면 다시 실행됩니다.

특히 recvWorker는 상당히 명확하게 10초 단위로 계속 재실행되는 구조입니다.

1. Init() 자체는 대부분 정상적으로 끝날 가능성이 높습니다

현재:

그리고:

를 수행합니다.

중요한 것은 Init()에서 실제 Redis 명령인 RPush()나 BLPop()을 실행하지 않는다는 것입니다.

따라서 단순히:

이 접속 불가능하더라도 new RedisClient() 단계에서 바로 예외가 발생하지 않는다면:

까지 실행됩니다.

즉 접속 불능이라고 해서 자동으로 해당 서버의 Worker가 생성되지 않는 구조는 아닙니다.

2. 특히 Receive Worker는 계속 살아있는 구조입니다

이 부분이 핵심입니다.

recvWorker_DoWork()에서:

을 합니다.

여기서 10은 BLPOP timeout입니다.

즉 정상적인 경우:

입니다.

그런데 더 중요한 것은 recvWorker_RunWorkerCompleted()입니다.

가 있습니다.

따라서:

이 구조입니다.

3. 따라서 Redis 서버가 완전히 죽어 있어도?

예를 들어:

Redis 서버가 아예 꺼져 있다고 하겠습니다.

그러면 대략:

가 됩니다.

실제로 recvWorker_DoWork()에는 Exception 처리가 있습니다.

그리고 finally로 종료합니다.

그 후 RunWorkerCompleted에서 다시 시작합니다.

따라서 Receive 측은

"접속이 안 되니까 Thread가 죽는다"

가 아니라,

"한 번의 Worker 실행은 끝나지만 Completed에서 다시 Worker를 시작한다"

가 정확한 표현입니다.

4. 실제로는 Thread가 계속 살아있는 것은 아닙니다

여기서 용어를 정확하게 구분해야 합니다.

현재 BackgroundWorker는:

하면 내부적으로 ThreadPool 등을 이용해서 작업을 수행합니다.

recvWorker_DoWork()가 끝나면 그 작업 스레드는 해당 작업을 끝냅니다.

그리고:

로 다음 작업을 다시 시작합니다.

따라서:

이라고 보는 것이 정확합니다.

5. Receive 쪽의 실제 메커니즘

현재 코드에서는 사실상 이런 구조입니다.

즉 Receive는 지속적인 polling/retry 구조입니다.

6. 그런데 Send Worker는 다릅니다

Send Worker는:

에서:

를 합니다.

그런데 이 메서드는 한 번에 Queue 하나만 처리합니다.

즉:

입니다.

그리고 Completed에서:

를 합니다.

그래서 Send는:

구조입니다.

7. 접속 불능일 때 Send Worker는 어떻게 되는가?

예를 들어:

에서 네트워크 오류가 발생하면:

로 들어갑니다.

그 후 sendWorker_DoWork()는 종료됩니다.

그러면 RunWorkerCompleted()가 실행됩니다.

그런데 여기서는:

입니다.

따라서 Queue에 다른 데이터가 있으면 다시 실행됩니다.

8. 여기서 상당히 중요한 문제가 하나 있습니다

접속 불능 서버에서 SendQuery()가 계속 호출되면:

가 계속 됩니다.

그런데 Redis가 안 되니까:

는 계속 실패합니다.

그러면:

가 됩니다.

따라서 접속 불능 상태에서 SendQuery가 계속 들어오면 sendQueue가 계속 증가할 가능성이 있습니다.

이 부분은 현재 코드에서 상당히 중요한 포인트입니다.

9. Receive 쪽도 특이한 부분이 있습니다

현재:

이므로 정상적인 Redis 연결 상태에서도 데이터가 없으면 10초마다 한 번씩 Worker가 종료/재실행됩니다.

즉 서버가 정상이어도:

입니다.

따라서 이것은 서버 장애 여부와 관계없이 원래 그렇게 설계된 코드입니다.

10. IsStopConsole도 주목해야 합니다

코드에:

가 있습니다.

즉 BLPOP이 거의 10초 동안 기다리면:

로 설정합니다.

그런데 이 파일 안에서는 이 값을 다시 false로 만드는 것이 아니라 Init()에서:

로 초기화하고 있습니다.

따라서 한 서버의 Receive Worker에서 BLPOP이 9초 이상 걸렸다는 이유만으로 전역 APMMemory.GetInstance.IsStopConsole이 true가 될 수 있습니다.

서버가 여러 개라면 이것도 확인할 필요가 있습니다.

최종적으로 현재 코드의 서버별 동작을 정리하면

따라서 질문하신 핵심에 대한 답은:

접속 불능이라고 해서 해당 서버의 APMMultipleRedisManager 자체가 죽는 것은 아닙니다.

특히 Receive 측은:

이라는 자동 재시도 메커니즘이 이미 들어가 있습니다.

그리고 Send 측은 송신 Queue가 있는 동안 실패 → 재실행을 반복할 수 있습니다.

따라서 현재 프로그램은 "접속 불능 서버를 제거하는 방식"이 아니라 "접속 불능이어도 Worker를 유지하면서 계속 재시도하는 방식"에 가깝습니다.

특히 여러 서버 중 하나가 죽었을 때 전체 프로그램이 영향을 받는지, 또는 죽은 서버의 _recvWorker가 계속 재시도하면서 CPU/로그/네트워크에 부담을 주는지를 보려면 현재 구조에서 RunWorkerCompleted()의 재실행 부분이 핵심입니다.

결론

Redis QCS 응답 또는 SQL 데이터가 비정상적으로 변경된 것이 아니라, printf(reply->element[1]->str)와 sprintf(tmpText, reply->element[1]->str)에서 발생한 Format String 취약성/오용이 직접적인 원인으로 판단된다.

특히 SQL의 LIKE 'OTRMES%', LIKE 'dr\\_%', LIKE '%ME' 등의 % 문자가 printf()의 format specifier로 해석되면서 정의되지 않은 동작이 발생했고, 그 결과 0x0p+0, 6.951058E-310 등의 비정상적인 값이 삽입된 것처럼 출력된 것이다.

따라서 Redis 서버, hiredis, redisReply, SQL 생성부를 우선 의심할 문제가 아니라 출력 및 문자열 복사 과정의 printf/sprintf 사용법을 수정하는 것이 1차적인 해결책이다.

질문)

1. 올바른 출력
printf("%s", reply->element[1]->str);
결과)
instancename like 'OTRMES%'                                                 and monname in ('ME', 'MR')             )d                                 ON
dr_re.RESNAME like 'dr\\_%' ESCAPE '\\' and dr_re.RESTYPE = 'apppms' 

2. 잘못된 출력
printf(reply->element[1]->str); 출력시에
결과)
like 'OTRMES 0x0p+0nd monname in ('ME', 'MR')
re.RESNAME not like 'dr\\_ 6.951058E-310SCAPE '\\' and re.RESTYPE = 'apppms' 

1. 올바른 출력과 
2. 잘못된 출력으로 나타난 결과입니다. 해석과 리포트용으로 작성해주세요.

답변)

printf() 사용 방식에 따른 Redis Reply 문자열 변형 현상 분석 보고서

1. 현상 개요

Redis redisReply 구조체의 reply->element[1]->str에 저장된 SQL 문자열을 출력하는 과정에서 출력 방식에 따라 원본 문자열이 정상적으로 출력되거나 비정상적으로 변형되는 현상이 확인되었다.

동일한 reply->element[1]->str에 대하여 다음 두 가지 방식으로 출력하였다.

정상적인 출력

출력 결과:

비정상적인 출력

출력 결과:

즉, Redis에서 전달받은 SQL 자체가 변경된 것이 아니라 printf() 호출 방식에 의해 문자열이 잘못 해석되고 있는 것으로 판단된다.

2. 원인 분석

문제의 핵심은 다음 코드이다.

C 언어의 printf()에서 첫 번째 인자는 단순한 문자열이 아니라 format string으로 취급된다.

즉,

와

는 완전히 다른 의미를 가진다.

3. 정상적인 코드의 동작

다음 코드는:

첫 번째 인자인:

를 format string으로 사용하고,

두 번째 인자인:

을 %s에 대응하는 문자열 데이터로 전달한다.

따라서 SQL 내부에 %가 존재하더라도 문제가 없다.

예를 들어 Redis 데이터가:

라면 %는 reply->element[1]->str의 일반적인 문자열 데이터일 뿐이다.

따라서 정상적으로:

가 출력된다.

4. 비정상적인 코드의 동작

반면 다음 코드는:

reply->element[1]->str 자체를 format string으로 사용한다.

문제는 SQL 안에 %가 포함되어 있다는 것이다.

예를 들어 원본 SQL:

이 printf()에 직접 전달되면:

의 %를 printf()가 format specifier의 시작으로 해석한다.

또한 SQL에는 다음과 같이 %가 여러 곳에 존재한다.

따라서 SQL 문자열 전체가 printf()의 format string으로 해석되면서 의도하지 않은 format 처리가 발생한다.

5. 0x0p+0, 6.951058E-310 등이 나타나는 이유

이번 현상에서 특히 중요한 부분은 다음과 같은 값이다.

그리고:

이 값들은 원본 Redis 데이터에 존재하는 값이 아니다.

printf()가 format string 안에서 %를 발견하면 그 뒤의 문자를 보고 어떤 타입의 인자를 가져올지 결정한다.

그런데 현재 코드:

에서는 printf()가 요구하는 추가 인자를 전달하지 않았다.

예를 들어 format string에 특정 부동소수점 형식이 해석되면 printf()는 해당 값이 인자로 전달되었다고 가정하고 호출 규약상의 레지스터/스택 영역에서 값을 읽게 된다.

그러나 실제로는 그러한 인자를 전달하지 않았기 때문에 정의되지 않은 동작(Undefined Behavior) 이 발생한다.

그 결과 우연히 메모리나 레지스터에 있던 값이 해석되어:

또는:

같은 의미 없는 값으로 출력될 수 있다.

따라서 다음과 같은 변형:

은 실제 Redis 문자열이:

였다는 의미가 아니다.

printf()가 %를 잘못 해석한 결과이다.

6. 현재 확인된 데이터 변형

원본 데이터:

정상 출력:

결과:

반면:

결과:

즉 원본의:

부분이 변형되었다.

또 다른 원본:

정상 출력:

비정상 출력:

여기에서도 원본의 %가 존재하는 부분에서 문자열이 변형되었다.

7. 기존 sprintf() 코드와의 관계

앞서 사용한 코드:

역시 동일한 문제가 발생한다.

printf()와 sprintf() 모두 첫 번째 인자를 format string으로 취급하기 때문이다.

따라서:

뿐만 아니라:

도 잘못된 사용이다.

잘못된 코드

정상적인 코드

또는 보다 안전하게:

8. Redis 데이터 자체의 문제인지 여부

현재 현상만 놓고 보면 Redis 또는 hiredis가 SQL을 변형한 것으로 볼 근거는 없다.

동일한 reply->element[1]->str에 대해:

를 사용했을 때:

등이 정상적으로 출력되고 있다.

이는 Redis에서 전달받은 문자열이 정상적으로 존재하고 있음을 보여준다.

따라서 문제 발생 위치는 다음과 같이 판단할 수 있다.

9. reply->element[1]->len이 달라지는 현상과의 관계

앞서 확인한:

와 같은 현상 역시 이 문제와 연관성이 높다.

Redis의:

은 Redis에서 전달받은 문자열의 실제 길이를 나타낸다.

반면:

는 sprintf()로 변형된 문자열의 길이를 측정한다.

따라서:

로 문자열이 변형되면:

가 될 수 있다.

따라서 LEN[4374]와 같은 결과가 나타난 것은 Redis 데이터의 길이가 잘못된 것이 아니라 format string 오용으로 인해 복사/출력 과정에서 문자열이 변형되었기 때문으로 판단된다.

10. 최종 판단

원인

및

와 같이 외부에서 전달받은 문자열을 format string으로 직접 사용한 것이 원인이다.

특히 SQL에는:

문자가 다수 포함되어 있으므로 문제가 쉽게 발생한다.

증상

• %가 포함된 SQL 부분이 변형됨
• 0x0p+0 등의 비정상적인 값이 출력됨
• 6.951058E-310 등의 부동소수점 형태의 의미 없는 값이 출력됨
• 원본 SQL과 출력 SQL의 길이가 달라짐
• reply->element[1]->len과 strlen() 결과가 달라짐
• 결과적으로 기존 코드에서 reply(FAIL)-LEN이 발생함

정상적인 처리 방법

문자열 복사라면:

또는 Redis reply의 정확한 len을 유지하려면:

결론

Redis QCS 응답 또는 SQL 데이터가 비정상적으로 변경된 것이 아니라, printf(reply->element[1]->str)와 sprintf(tmpText, reply->element[1]->str)에서 발생한 Format String 취약성/오용이 직접적인 원인으로 판단된다.

특히 SQL의 LIKE 'OTRMES%', LIKE 'dr\\_%', LIKE '%ME' 등의 % 문자가 printf()의 format specifier로 해석되면서 정의되지 않은 동작이 발생했고, 그 결과 0x0p+0, 6.951058E-310 등의 비정상적인 값이 삽입된 것처럼 출력된 것이다.

따라서 Redis 서버, hiredis, redisReply, SQL 생성부를 우선 의심할 문제가 아니라 출력 및 문자열 복사 과정의 printf/sprintf 사용법을 수정하는 것이 1차적인 해결책이다.

질문)
위의 SQL문장을 c#클라이언트에서 Push로 Redis로 보내는부분입니다. 위의 SQL 일부에 re.RESNAME not like 'dr\_%' ESCAPE '\' and re.RESTYPE = 'apppms' 는 redis에서 POP해서 c언어에서 파싱할수 있도록 하기 위해서 특수문자를 넣는것이라고 볼수 있나요? 아니면 원래 저렇게 사용하는것인가요?

답변)

네. re.RESNAME not like 'dr\_%' ESCAPE '\'는 Redis로 보내기 위해 특수문자를 넣은 것이 아닙니다.
이것은 Oracle SQL의 LIKE 문법에서 _를 문자 그대로 검색하기 위해 원래 사용하는 SQL 표현입니다.

핵심은 LIKE에서 _가 특별한 의미를 갖는다는 점입니다.

1. Oracle LIKE에서 _의 의미

Oracle에서:

LIKE 'dr_%'

라고 하면 _는 임의의 문자 1개를 의미합니다.

즉,

dr_abc
drXabc
dr1abc
dr-abc

등이 모두 조건에 걸릴 수 있습니다.

2. 그런데 dr_라는 문자열 자체를 의미하고 싶다면?

현재 SQL은:

re.RESNAME not like 'dr\_%' ESCAPE '\'

입니다.

여기서:

ESCAPE '\'

는 백슬래시 \를 LIKE의 escape 문자로 사용하겠다는 뜻입니다.

따라서:

dr\_%

에서

\_

는 "_를 LIKE의 특수문자로 해석하지 말고 실제 _ 문자로 취급하라"는 의미입니다.

즉 이 조건은:

RESNAME이 "dr_"로 시작하지 않는 것

을 의미합니다.

예를 들어:

dr_ABC
dr_MES_001
dr_TEST

는 제외되고,

abc_ABC
drXABC
MES_001

등은 제외되지 않습니다.

3. ESCAPE '\'가 없으면?

예를 들어:

re.RESNAME not like 'dr_%'

이면 _가 와일드카드이므로:

drA123
drX001
dr12345

같은 것도 dr_... 패턴에 매칭될 수 있습니다.

반면:

re.RESNAME not like 'dr\_%' ESCAPE '\'

이면 정확히 dr_로 시작하는 문자열을 대상으로 합니다.

4. Redis → C 파싱을 위해 넣은 문자가 아닙니다

따라서 현재 구조가

C# 프로그램
   ↓
SQL 문자열 생성
   ↓
Redis PUSH
   ↓
C 프로그램 POP
   ↓
Oracle에서 SQL 실행

이라고 하더라도,

dr\_%

의 \는 Redis 전송용 escape가 아닙니다.

C 프로그램에서 Redis에서 POP한 후 SQL 문자열을 파싱한다고 해서 특별히 넣은 것도 아닙니다.

Oracle SQL 자체에서 필요한 문자입니다.

5. 특히 현재 SQL에서는 두 군데가 있습니다

질문하신 부분:

re.RESNAME not like 'dr\_%' ESCAPE '\'

그리고 아래에도:

dr_re.RESNAME like 'dr\_%' ESCAPE '\'

가 있습니다.

둘 다 같은 이유입니다.

첫 번째:

re.RESNAME not like 'dr\_%' ESCAPE '\'

→ dr_로 시작하는 RESNAME 제외

두 번째:

dr_re.RESNAME like 'dr\_%' ESCAPE '\'

→ dr_로 시작하는 RESNAME 선택

즉 하나는 일반 apppms 리소스, 다른 하나는 dr_ 리소스를 구분하기 위한 것으로 보입니다.

결론

'dr\_%' ESCAPE '\'

의 \는 Redis 때문에 들어간 것이 아니라 Oracle LIKE에서 _를 일반 문자로 사용하기 위한 SQL 문법입니다.

따라서 C# → Redis → C 구조가 아니더라도 원래 SQL에 그대로 있어야 하는 표현입니다.

참고로 C#에서 이 SQL을 @"..." verbatim string으로 만들었기 때문에 현재처럼:

@"... 'dr\_%' ESCAPE '\' ..."

라고 작성할 수 있습니다. 일반 C# 문자열("...")이었다면 백슬래시 처리 방식이 달라집니다.

질문)

{"param":{"stmt":" with tbl_now_clock as ( select /*+ APM UI(UAPAMSQ0600-1) */ imf_nowclock-2 now_clock from dual ) SELECT title, MAX(bStatus), NVL(MAX(bitemid),0), NVL(MAX(mrDRSNDCNT),0), NVL(MAX(meDRSNDCNT),0), NVL(MAX(dstatus),'N'), NVL(MAX(drgstatus),'EMPTY'), MAX(RESADDR3), RESNAME from ( select re.RESADDR2 title,a.RESADDR3 RESADDR3, NVL(c.STATUS,'DOWN') bStatus, c.itemid bitemid, MONNAME, decode() and re.RESNAME not like 'dr\\_%' ESCAPE '\\' and re.RESTYPE = 'apppms' and re.RESADDR3 like '%me%' LEFT JOIN ( select itemid, case status when 1 then 'ACTIVE' when 2 then 'STANDBY' when 3 then 'WARM' else 'DOWN' end status RESADDR3 like '%me%' LEFT JOIN ( select itemid, case status when 1 then 'ACTIVE' when 2 then 'STANDBY' when 3 then 'WARM' else 'DOWN' end status from imt_mams_instance where clock= (select now_clock from tbl_now_clock) ) dr_c on dr_b.ITEMID = dr_c.ITEMID where dr_a.groupname like '%ME' and dr_a.itemkey = 'mams.me' and dr_a.resaddr3='STK' and dr_a.RESADDR1 = 'MES' and dr_b.itemkey='mams.me' ) DRG on substr(DRG.RESNAME,4) = a.RESNAME where a.groupname like '%ME' and a.itemkey = 'mams.me' and a.resaddr3='STK' and a.RESADDR1 = 'MES' and b.itemkey='mams.me') group by title,RESNAME order by RESNAME ","colcnt":"7"},"proto":"r","sender":"1127001637917220102/5940","id":"QUERY.0000658546.001","ts":"1786401234","method":"dynbigsel","screen":"UAPAMSQ0600-1"}

위는 LENGTH:[4410] 입니다.

위를 
byte[] jsonByte = sendQueue.Dequeue();
resultCode = _sendRedis.RPush("QCS", jsonByte); 

보낸다면 reply = redisCommand(stRedis, "BLPOP QCS") 에 대한 reply 결과는

답변)

네. 중요한 점은 Redis BLPOP의 reply에는 JSON 내용이 그대로 reply->element[1]->str에 들어온다는 것입니다.

보내는 쪽이:

byte[] jsonByte = sendQueue.Dequeue();
resultCode = _sendRedis.RPush("QCS", jsonByte);

이고 jsonByte의 길이가 4410 byte라면, Redis에 다음과 같은 형태로 저장됩니다.

QCS
 └── [4410 byte의 JSON 데이터]

서버에서:

reply = redisCommand(stRedis, "BLPOP QCS");

를 실행하면 reply는 대략 다음 구조가 됩니다.

reply
│
├── type      = REDIS_REPLY_ARRAY
├── elements  = 2
│
└── element
    │
    ├── [0]
    │    ├── type = REDIS_REPLY_STRING
    │    ├── len  = 3
    │    └── str  = "QCS"
    │
    └── [1]
         ├── type = REDIS_REPLY_STRING
         ├── len  = 4410
         └── str  = "{\"param\":{\"stmt\":\" with tbl_now_clock ... "

즉:

reply->element[0]->str

은

QCS

이고,

reply->element[1]->str

이 실제 JSON 데이터입니다.

실제로 보면

서버에서 다음과 같이 출력하면 됩니다.