참고로 Visual Studio 2022부터는 .NET Framework 4.0~4.5.1 타깃팅 구성 요소가 기본 제공되지 않으므로, 해당 프로젝트를 계속 빌드해야 한다면 VS 2017 또는 VS 2019를 사용하는 편이 적합합니다.

제시하신 .csproj 프로젝트 파일은 Visual Studio 2017과 Visual Studio 2019 모두에서 열 수 있는 구형 C# 프로젝트 형식입니다. 핵심은 프로젝트 파일의 TargetFrameworkVersion이 v4.0으로 지정되어 있다는 점입니다.

1. Visual Studio 2017과 2019에서 열었을 때의 결과

<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>

이 설정은 프로젝트가 .NET Framework 4.0을 대상으로 빌드되도록 지정합니다. Visual Studio 버전이 달라져도 이 값 자체가 자동으로 .NET Framework 4.7이나 4.8로 바뀌는 것은 아닙니다.

단, 실제 빌드 성공 여부는 설치된 .NET Framework 타깃팅 팩, C# 컴파일러, NuGet 패키지 및 프로젝트의 나머지 설정에 따라 달라집니다.

2. 실제 차이가 발생하는 부분

① 프로젝트를 여는 것과 빌드하는 것은 다릅니다

Visual Studio에서 프로젝트 파일을 열 수 있어도 빌드가 성공한다는 의미는 아닙니다.

예를 들어 .NET Framework 4.0 참조 어셈블리가 설치되어 있지 않으면 다음과 같은 오류가 발생할 수 있습니다.

MSB3644: The reference assemblies for
.NETFramework,Version=v4.0 were not found.

이 경우에는 해당 버전의 참조 어셈블리 또는 타깃팅 팩을 설치해야 합니다.

GitHub+1

② Visual Studio 버전에 따른 차이

3. 프로젝트 파일의 각 설정 의미

특히 ToolsVersion="4.0"과 TargetFrameworkVersion은 서로 다른 설정입니다. Visual Studio 2019에서 열었다고 해서 ToolsVersion을 반드시 16.0으로 변경할 필요는 없습니다.

4. 현재 APM 프로젝트에 권장하는 방법

기존 APM 소스를 그대로 유지하는 것이 목적이라면 다음 순서가 안전합니다.

1. 원본 .csproj 파일을 백업합니다.

2. Visual Studio 2017과 2019에서 각각 프로젝트를 엽니다.

3. 프로젝트 속성의 응용 프로그램 → 대상 프레임워크에서 .NET Framework 4가 선택되어 있는지 확인합니다.

4. Release 및 기존 플랫폼 설정으로 빌드합니다.

5. 생성된 EXE/DLL과 참조 DLL을 비교합니다.

주의: 두 버전에서 같은 소스 코드를 빌드하더라도 컴파일러 버전, 빌드 옵션, 참조 라이브러리에 따라 결과 바이너리가 달라질 수 있습니다.

참고로 Visual Studio 2022부터는 .NET Framework 4.0~4.5.1 타깃팅 구성 요소가 기본 제공되지 않으므로, 해당 프로젝트를 계속 빌드해야 한다면 VS 2017 또는 VS 2019를 사용하는 편이 적합합니다.

레이블이 보이게 된 이유는 InvalidateRect()는 화면을 다시 그리도록 예약만 하고, UpdateWindow()는 그리기가 필요한 영역을 즉시 다시 그리도록 하기 때문입니다.

이번 문제는 파일명 설정이나 DrawText() 자체보다는 화면 갱신 시점의 문제였을 가능성이 높습니다.

기존 코드와 수정 코드의 차이

InvalidateRect(CRect(492, 174, 606, 234));

CRect rcUpdate(492, 174, 606, 234);
InvalidateRect(&rcUpdate, FALSE);
UpdateWindow();

왜 기존에는 레이블이 보이지 않았을까요?

로그를 보면 다음과 같았습니다.

1. 프로그램 시작 시 OnPaint()가 실행됐지만 파일명은 빈 문자열이었습니다.

2. 다운로드가 진행되면서 파일명이 0002_AMS.dll, 0003_AMS.pdb 등으로 정상 설정됐습니다.

3. InvalidateRect()도 정상 호출됐지만, 이후 OnPaint() 로그는 나타나지 않았습니다.

4. UpdateWindow()를 추가하자 레이블이 보였습니다.

따라서 기존에는 파일명 데이터가 준비된 뒤 해당 영역의 다시 그리기가 적절한 시점에 처리되지 않았던 것으로 보입니다.

최종 권장 코드

레이블이 정상적으로 표시된다면 우선 다음 형태로 사용하면 됩니다.

CRect rcUpdate(492, 174, 606, 234);

InvalidateRect(&rcUpdate, FALSE);
UpdateWindow();

다만 이 코드는 UI 스레드에서 실행되는 것이 전제입니다. 다운로드 처리 중 UI가 잠시 멈추거나 화면 갱신이 지나치게 자주 발생한다면, UpdateWindow()를 모든 처리 경로에 추가하기보다 필요한 위치에만 두는 것이 좋습니다.

참고로 InvalidateRect() 호출 후에도 OnPaint()가 실행되지 않았다는 로그만으로 메시지 처리 실패를 확정할 수는 없습니다. 이번 테스트에서 UpdateWindow()를 통해 즉시 그리기가 이루어졌다는 점이 핵심입니다.

질문)
with tbl_now_clock as ( select imf_nowclock-2 now_clock from dual ) tbl_now_clock은 테이블의 의미이고, now_clock은 필드의 의미인가요?

답변)

네, 개념적으로는 맞습니다. 다만 tbl_now_clock은 실제 데이터베이스 테이블이 아니라 CTE(Common Table Expression, 공통 테이블 표현식)의 이름입니다.

WITH tbl_now_clock AS (
    SELECT imf_nowclock - 2 AS now_clock
    FROM dual
)

각 요소의 의미는 다음과 같습니다.

실행 결과를 개념적으로 표현하면 다음과 같습니다.

이후 다음과 같이 참조할 수 있습니다.

SELECT now_clock
FROM tbl_now_clock;

즉, tbl_now_clock은 테이블 역할을 하는 이름이고, now_clock은 그 안에 있는 컬럼(필드)의 이름입니다.

단, tbl_now_clock은 실제 테이블처럼 보이지만 이 SQL 문 안에서만 사용할 수 있는 조회 결과의 이름이며, 데이터베이스에 영구적으로 생성되는 테이블은 아닙니다.

현재 디렉터리에서 아래 명령어를 순서대로 실행해 보세요.

① 종료 코드 확인

APM.exe
echo ExitCode=%ERRORLEVEL%

종료 코드는 프로그램이 종료된 상태를 파악하는 단서입니다. 다만 종료 코드만으로 정확한 원인을 확정할 수는 없습니다.

② Windows 이벤트 로그에서 오류 확인

PowerShell을 열고 다음 명령어를 실행합니다.

Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    StartTime = (Get-Date).AddMinutes(-10)
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.ProviderName -match 'Application Error|\.NET Runtime|Windows Error Reporting'
} |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-List

Application Error 또는 .NET Runtime 관련 기록에 예외 유형, 오류가 발생한 모듈, DLL 이름 등이 표시될 수 있습니다.

4. 실행 실패 원인을 구분하는 기준

RedisClient 생성과 실제 TCP 연결 시점의 차이

조금 더 기술 문서답게 쓰면:

• RedisClient 객체 생성과 TCP 연결(ESTABLISHED)의 관계
• ServiceStack.Redis의 RedisClient 생성과 TCP 연결 시점
• RedisClient Timeout 설정과 TCP 연결 상태의 관계
• RedisClient 생성 → Redis 명령 실행 → TCP ESTABLISHED 흐름

네. 서로 다른 관점입니다. 그리고 지금 질문하신 부분이 정확히 핵심입니다.

두 코드를 구분하면 다음과 같습니다.

① new RedisClient(...)

_sendRedis = new RedisClient(ipAddress, Convert.ToInt32(portNo));

이것은 RedisClient 객체를 생성하는 것입니다.

즉,

"이 IP와 Port를 사용하는 Redis 연결 객체를 준비한다."

는 의미입니다.

이 코드만 보고 TCP 연결이 이미 ESTABLISHED 되었다고 단정하면 안 됩니다.

② SendTimeout, RetryTimeout

_sendRedis.SendTimeout = 10 * 60 * 1000;
_sendRedis.RetryTimeout = 10 * 60 * 1000;

이것은 TCP 연결을 만드는 코드가 아닙니다.

단순히 RedisClient의 동작에 사용할 timeout 값을 설정합니다.

즉:

new RedisClient()
        ↓
RedisClient 객체 생성
        ↓
SendTimeout 설정
RetryTimeout 설정
        ↓
아직 실제 TCP 연결이 없을 수도 있음

입니다.

③ 실제 TCP 연결이 만들어지는 시점

그 다음에 실행되는:

_sendWorker.RunWorkerAsync();

에서 sendWorker_DoWork()가 실행되고, 그 안에서 실제 Redis 명령을 수행할 때 TCP 연결이 필요해집니다.

예를 들어:

private void sendWorker_DoWork(...)
{
    _sendRedis.Set(...);
}

라면 Set() 같은 Redis 명령을 수행하기 위해 TCP 연결이 필요합니다.

그때:

C# 프로그램
   │
   │ TCP Connect
   ▼
10.112.160.71:9111
   │
   ▼
ESTABLISHED

가 될 수 있습니다.

그런데 여기서 중요한 예외가 하나 있습니다

제가 앞에서 **"new RedisClient만으로는 TCP 연결이 없을 수도 있다"**라고 말씀드렸는데, 이것은 ServiceStack.Redis의 버전/구현에 따라 실제 연결 시점이 다를 수 있기 때문에 그렇게 표현한 것입니다.

따라서 현재 사용 중인 ServiceStack.Redis 버전의 RedisClient 구현을 정확히 확인하면 더 확실하게 말할 수 있습니다.

하지만 현재 코드의 논리적인 구분은 명확합니다.

그리고 질문하신 10분 설정은 특히 중요합니다

예를 들어:

_sendRedis.SendTimeout = 10 * 60 * 1000;

은

10분 동안 netstat에서 연결을 유지한다

라는 의미가 아닙니다.

또한

10분이 지나야 ESTABLISHED가 나타난다

도 아닙니다.

이 설정은 Redis 명령을 수행하는 과정에서 timeout을 얼마나 기다릴지와 관련된 설정입니다.

따라서 현재 상황을 이렇게 이해하시면 정확합니다.

Init()
 │
 ├─ new RedisClient()
 │       │
 │       └─ RedisClient 객체 준비
 │
 ├─ SendTimeout = 10분
 │
 ├─ RetryTimeout = 10분
 │
 └─ RunWorkerAsync()
          │
          ▼
    sendWorker_DoWork()
          │
          ▼
    실제 Redis 명령
          │
          ▼
    TCP 연결 필요
          │
          ▼
    ESTABLISHED

그래서 SendTimeout = 10분 때문에 netstat에 안 보이는 것은 아닙니다.

그리고 지금 올려주신 코드에서는 제가 한 가지를 더 중요하게 보고 있습니다.

_sendWorker.RunWorkerAsync();

바로 이 부분입니다.

sendWorker_DoWork() 안에서 Redis를 어떻게 사용하고 있는지를 보면 _sendRedis의 TCP 연결이 언제 만들어지는지 거의 확정할 수 있습니다.

sendWorker_DoWork()와 recvWorker_DoWork() 두 개를 올려주시면, 각각 netstat에 몇 개가 보여야 하는지까지 실제 코드 흐름으로 계산해드릴 수 있습니다.

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에는 다음과 같이 %가 여러 곳에 존재한다.