Prejudice

Linux PREEMPT_RT 실시간성(Jitter) 측정 및 성능 비교 - RTOS

편견장 — Mon, 6 Apr 2026 21:35:34 +0900

들어가며

최근 SW PLC에서 관심 갖고 개발 중인 내용은 Linux PREEMPT_RT 커널을 이용해 실시간성을 보장하는 작업이다.

SW PLC Runtime은 특정 Task를 매 주기마다 실행해야 한다.

따라서 OS에서 프로세스의 실행을 보장받지 못하거나, 처리 속도가 들쭉날쭉 하지 않도록 Jitter를 관리하는 것이 중요하다.

PREEMPT_RT 커널로 실시간성을 확보하고 테스트하는 일련의 과정을 정리해 보려 한다.

용어 및 개념정리 : 2026.03.19 - [개발] - Real-Time, RTOS, PREEMPT_RT, CPU Isolation 개념 정복 - 실시간 처리

Real-Time, RTOS, PREEMPT_RT, CPU Isolation 개념 정복 - 실시간 처리

들어가며'실시간(Real-time)'이라는 용어는 Embedded 및 FactoryAutomation 산업의 핵심이며,현장에서 다양한 관점과 의미로 혼용되곤 한다.또한 자연스럽게 따라오는 '처리 속도'는 모든 SW/HW의 핵심 지표

prejudice.tistory.com

테스트 시나리오 설계

㎱(나노초), ㎲(마이크로초) 단위로 처리하는 Real-Time을 제대로 구현하고 평가하기 위해 테스트 설계 과정이 중요하다.

우선 커널단에서 처리하는 과정은 다음과 같다.

Linux 커널 처리 과정

PREEMPT_RT 커널 처리 과정

테스트 목표는 Interrupt가 발생한 시점부터 Test Program(=TaskB) 이 호출될 때까지의 Jitter를 측정하고 비교하는 것이다.

목표 달성을 위해 다음과 같이 테스트를 설계했다.

HW : Linux PREEMPT_RT 커널이 올라간 BoxPC
측정 방법 : TaskB를 10㎳ 주기로 10,000회 반복 호출하며 깨어날 때의 시간을 정밀 측정
측정 환경 : ① stress-ng 툴로 CPU와 I/O에 강제 부하 인가
② QTimer, non-RT Kernel, PREEMPT_RT Kernel 각각의 조건에서 실행 후 비교
예상 결과 :
☐ QTimer는 내부의 QEventLoop 구조로 인해 Linux Basic Kernel 보다 Jitter가 클 것이다.
☐ 강력한 시스템 부하로 인해 QTimer와 non-RT Kernel의 Jitter는 변동폭이 클 것이다.
☐ 반면 PREEMPT_RT Kernel의 Jitter는 극한의 상황에서도 안정적인 수준을 유지할 것이다.

QTimer 프로그램 구현

우선 Qt6를 설치하고 QTimer를 이용해 10㎳마다 timeout 되도록 프로그램을 작성했다.

이때 Qt6.8에 도입된 Qt::PreciseTimer 를 사용해 Jitter 특성을 최소화했다.

(*Precise Timer : https://doc.qt.io/qt-6/ko/qtimer.html)

#include <QCoreApplication>
#include <QFile>
#include <QTextStream>
#include <QTimer>
#include <chrono>
#include <iostream>
#include <vector>

struct LogEntry {
    long long tick;
    double actualRunTimeMs;
    double predictMs;
    double gitterMs;
};

int main(int argc, char* argv[]) {
    QCoreApplication app(argc, argv);

    constexpr double periodMs = 10.0;
    constexpr long long totalTicks = 10000;

    // 로그 버퍼 사전 할당
    std::vector<LogEntry> logBuffer;
    logBuffer.reserve(totalTicks);

    long long tick = 0;
    const auto startTime = std::chrono::steady_clock::now();

    QTimer timer;
    timer.setTimerType(Qt::PreciseTimer);
    timer.setInterval(static_cast<int>(periodMs));

    QObject::connect(&timer, &QTimer::timeout, [&]() {
        ++tick;

        const auto now = std::chrono::steady_clock::now();
        const std::chrono::duration<double, std::milli> elapsed = now - startTime;

        const double actualRunTimeMs = elapsed.count();
        const double predictMs = tick * periodMs;
        const double gitterMs = actualRunTimeMs - predictMs;

        // I/O 없이 메모리 버퍼에만 기록
        logBuffer.push_back({tick, actualRunTimeMs, predictMs, gitterMs});

        if (tick >= totalTicks) {
            timer.stop();
            app.quit();
        }
    });

    timer.start();
    std::cout << "Started 10ms periodic timer. Logging to timer_log.csv" << std::endl;

    app.exec();

    // 타이머 루프 종료 후 한 번에 파일 기록
    std::cout << "Timer stopped after " << tick << " ticks. Writing log..." << std::endl;

    QFile logFile("timer_log.csv");
    if (!logFile.open(QIODevice::WriteOnly | QIODevice::Text | QIODevice::Truncate)) {
        std::cerr << "Failed to open timer_log.csv" << std::endl;
        return 1;
    }

    QTextStream stream(&logFile);
    stream << "index,actual_run_time_ms,predict_ms,gitter_ms\n";
    for (const auto& e : logBuffer) {
        stream << e.tick << ","
               << QString::number(e.actualRunTimeMs, 'f', 3) << ","
               << QString::number(e.predictMs, 'f', 3) << ","
               << QString::number(e.gitterMs, 'f', 3) << "\n";
    }

    std::cout << "Log written to timer_log.csv (" << logBuffer.size() << " entries)." << std::endl;
    return 0;
}

PREEMPT_RT 프로그램 구현

PREEMPT_RT 프로그램도 QTimer와 동일하게,
10㎳ 마다 RT-kernel의 시스템 타이머 인터럽트를 받아 task가 깨어나도록 구현했다.

프로그램의 main 함수 내 while문에서 clock_nanosleep 함수에서 OS호출을 대기하며 블록킹 되는데,
다음과 같은 상황에서는 실시간성을 보장받지 못하고 일반 프로세서와 동일하게 동작한다.

Linux kernel이 PREEMPT_RT 커널이 아닌 경우
실행 시 관리자(root) 권한으로 실행되지 않은 경우

해당 조건을 역이용하여 동일하게 빌드된 단일 프로그램을 통해 non-RT 커널과 PREEMPT-RT 커널 테스트를 모두 진행했다.

#include <cerrno>
#include <cstring>
#include <fstream>
#include <iomanip>
#include <iostream>
#include <pthread.h>
#include <sched.h>
#include <string>
#include <sys/mman.h>
#include <time.h>
#include <vector>

namespace {

timespec addMs(const timespec& t, long ms) {
    timespec out = t;
    out.tv_sec += ms / 1000;
    out.tv_nsec += (ms % 1000) * 1000000L;
    if (out.tv_nsec >= 1000000000L) {
        out.tv_sec += 1;
        out.tv_nsec -= 1000000000L;
    }
    return out;
}

double diffMs(const timespec& a, const timespec& b) {
    const long sec = a.tv_sec - b.tv_sec;
    const long nsec = a.tv_nsec - b.tv_nsec;
    return static_cast<double>(sec) * 1000.0 + static_cast<double>(nsec) / 1000000.0;
}

struct LogEntry {
    long long tick;
    double actualRunTimeMs;
    double predictMs;
    double gitterMs;
};

}  // namespace

int main(int argc, char* argv[]) {
    constexpr long periodMs = 10;
    constexpr long long totalTicks = 10000;
    int rtPriority = 80;

    if (argc >= 2) {
        rtPriority = std::stoi(argv[1]);
    }

    // 메모리 페이지 폴트 방지: 모든 메모리를 RAM에 고정
    if (mlockall(MCL_CURRENT | MCL_FUTURE) != 0) {
        std::cerr << "Warning: mlockall failed (" << std::strerror(errno)
                  << "). Page faults may cause jitter." << std::endl;
    } else {
        std::cout << "mlockall: memory locked." << std::endl;
    }

    // 로그 버퍼 사전 할당 (루프 전에 메모리 확보)
    std::vector<LogEntry> logBuffer;
    logBuffer.reserve(totalTicks);

    sched_param schParam{};
    schParam.sched_priority = rtPriority;

    if (pthread_setschedparam(pthread_self(), SCHED_FIFO, &schParam) != 0) {
        std::cerr << "Warning: failed to set SCHED_FIFO priority=" << rtPriority
                  << " (" << std::strerror(errno)
                  << "). Continue with current scheduler." << std::endl;
    } else {
        std::cout << "SCHED_FIFO enabled with priority=" << rtPriority << std::endl;
    }

    timespec startTs{};
    if (clock_gettime(CLOCK_MONOTONIC, &startTs) != 0) {
        std::cerr << "clock_gettime failed" << std::endl;
        return 1;
    }

    std::cout << "Started RT periodic task at 10ms. Logging to rt_task_log.csv" << std::endl;

    long long tick = 0;

    // RT 루프: I/O 없이 메모리 버퍼에만 기록
    while (tick < totalTicks) {
        ++tick;

        const timespec targetTs = addMs(startTs, static_cast<long>(tick * periodMs));

        const int sleepRet = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &targetTs, nullptr);
        if (sleepRet != 0 && sleepRet != EINTR) {
            std::cerr << "clock_nanosleep failed: " << std::strerror(sleepRet) << std::endl;
            break;
        }

        timespec now{};
        clock_gettime(CLOCK_MONOTONIC, &now);

        logBuffer.push_back({
            tick,
            diffMs(now, startTs),
            static_cast<double>(tick * periodMs),
            diffMs(now, addMs(startTs, static_cast<long>(tick * periodMs)))
        });
    }

    // RT 루프 종료 후 한 번에 파일 기록
    std::cout << "task stopped after " << tick << " ticks. Writing log..." << std::endl;

    std::ofstream logFile("rt_task_log.csv", std::ios::trunc);
    if (!logFile.is_open()) {
        std::cerr << "Failed to open rt_task_log.csv" << std::endl;
        return 1;
    }

    logFile << std::fixed << std::setprecision(3);
    logFile << "index,actual_run_time_ms,predict_ms,gitter_ms\n";

    for (const auto& e : logBuffer) {
        logFile << e.tick << ","
                << e.actualRunTimeMs << ","
                << e.predictMs << ","
                << e.gitterMs << "\n";
    }

    std::cout << "Log written to rt_task_log.csv (" << logBuffer.size() << " entries)." << std::endl;
    return 0;
}

⚠️트러블 슈팅 : 로깅 방식으로 인한 지연
위 예제 코드를 보면 vector::logBuffer에 결과를 담아두었다가 측정(10,000회)이 완전히 종료된 후 일관적으로 파일에 쓰도록 구현했다.
Real-Time 프로그램 원칙 중 disk I/O 작업을 지양해야 한다는 룰이 있다.
㎛ 수준으로 즉각 동작해야 하는 시스템 특성상, 순간적인 파일 입출력 병목이 발생하면 수 ㎳ 이상의 스레드 지연을 초래할 수 있기 때문이다.

초기에 측정 데이터를 실시간으로 보겠다는 마음으로 while 반복문 안에서 매 틱마다 로깅을 수행했다가 지연이 발생했고,
마치 Jitter가 발생한 것처럼 보이는 착시를 겪은 후 메모리 버퍼 방식으로 변경했다.

성능 비교 환경 설정

우선 BoxPC에 PREEMPT_RT Linux kernel을 활성화해야 한다.

Linux 6.12 버전부터는 PREEMPT_RT가 공식 커널에 합쳐졌기 때문에, 최신 배포판을 사용 중이라면 쉽게 활성화할 수 있다.

다만 내가 사용한 Ubuntu 24.04의 커널은 6.8 버전으로 공식적으로 통합되기 이전의 빌드였다.

따라서 커널 소스와 해당하는 버전의 RT 패치를 다운로드한 뒤 직접 빌드하여 커널을 올려주었다.

테스트를 위한 전체적인 OS 환경 세팅은 AI 도구들을 사용하면 훨씬 수월하게 구축할 수 있다.

성능 비교에 앞서 정확한 측정을 위해 두 가지 환경 설정이 더 필요하다.

첫 번째, 스트레스 테스트 도구인 stress-ng를 이용해 시스템 자원 전체에 고의적인 부하를 걸고 측정했다.
Jitter가 튀기 가장 좋은 가혹 환경을 만들기 위해 아래 명령을 사용했다.

stress-ng --cpu 0 --vm 4 --vm-bytes 1G --io 4 --timer 4 --switch 4 --timeout 120s &

옵션	효과	RT jitter 유발 메커니즘
--cpu 0	모든 코어 CPU 100% 연산	☑ 컨텍스트 스위치 유발
--vm 4 --vm-bytes 1G	메모리 할당/해제 반복	☑ 페이지 폴트, TLB flush 유발
--io 4	디스크 read/write 반복	☑ I/O IRQ 유발
--timer 4	타이머 인터럽트 생성	☑ 하드웨어 타이머 ㅁ인터럽트 경합
--switch 4	컨텍스트 스위치 폭탄	☑ 프로세스 스케줄링 간섭
--timeout 120s	120초간 지속	☑ 테스트 기간(약 100초 = 10㎳ * 10,000) 동안 유지

두 번째, CPU 동적 클럭 제어 비활성화 PREEMPT_RT에서 clock_nanosleep함수로 깨어나는 순간,
절전 모드 등 cpu 코어의 동작 클럭이 낮아져 있다면 다시 연산 클럭을 끌어올리는 과정에서 미세한 지연 시간(Latency)이 발생할 수 있다. 따라서 CPU Governor 설정을 performance 모드로 변경해, 항상 최대 클럭이 유지되도록 강제했다.

# CPU Performance 모드로 변경
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

QTimer vs PREEMPT_RT 성능 비교

☑ QTimer는 내부의 QEventLoop 구조로 인해 Linux Basic Kernel 보다 Jitter가 클 것이다.

QTimer 3회 측정 결과

Linux non-RT kernel 3회 측정 결과

두 호출 방식의 결과는 예상대로 압도적인 차이가 발생했다.

이상치에 해당하는 Jitter를 제외(상하위 10%를 제외)한 평균시간에서도 약 50배 가까이 차이가 확인되었다.

QTimer 평균 지연 = 0.576987 ㎳
Linux non-RT Kernel 평균 지연 = 0.011389 ㎳

☑ CPU부하로 인해 QTimer와 non-RT Kernel의 Jitter는 들쭉날쭉할 것이다

또한 non-RT kernel 환경의 테스트 결과를 보면, 시스템 컨디션에 따라 Jitter가 발생하는 것을 확인할 수 있었다.

첫 번째 측의 경우 운이 좋게도 OS 스케줄러 간섭 없이 매끄럽게 통과했지만,

세 번째 측정 결과(3rd)에서는 최대 0.65 ms까지 값이 튀는 것을 볼 수 있었다.

이는 Inturrupt 발생 시점부터 Task 실행까지 운이 좋으면 11㎲, 운이 나쁠 때는 650㎲까지 지연될 수 있음을 의미한다.

☑ RT Kernel의 Jitter는 시스템 부하에서도 안정적이어야 한다.

Linux PREEMPT_RT Kernel 3회 측정 결과

이 글의 목적인 PREEMPT_RT Kernel에서는 Jitter가 확실하게 잡혀 안정적으로 프로그램이 실행되는 것을 확인할 수 있었다.

Linux PREEMPT_RT kKernel 3번째 측정 결과

non-RT 환경에서 실행 시간의 변동성이 가장 컸던 세 번째 케이스를 PREEMPT_RT 위에서 돌렸을 때,
평균 11㎲ 최악의 경우 70㎲ 실행속도를 측정했다.

순간적으로 650㎲ 까지 지연됐던 범용 커널에 비해 훨씬 신뢰도 높고 예측 가능한 움직임을 보여주었다.

회고

데이터의 처리 성능(Throughput)이 중요한 비전(Vision) 프로그램을 다룰 때 주로 테스트 설계를 고민해 왔었는데,

오랜만에 이렇게 마이크로초(㎲) 단위의 응답성을 다투는 정밀도 테스트를 설계하고 검증해 보니 시스템 코어 개발마의 색다른 재미를 느낄 수 있었다.

내심 "나노초 단위까지 제어할 수 있는 결과를 볼 수 있지 않을까?"라는 기대와는 달라 아쉬운 점도 있었지만,
무거운 범용 운영체제인 Linux에서 RTOS가 아님에도 커널 패치로 이 정도의 성능을 끌어낸다는 점에서 PREEMPT_RT 기술의 우수성을 엿볼 수 있었다.

CPU Isloation과 IRQ가 RT-CPU를 방해하지 않도록 하는 IRQ Affinity 조정방법을 통해 실행시간을 좀 더 단축할 수 있겠지만,

이번 프로젝트의 PoC 차원에서 진행된 테스트 프로그램의 결과물로는 이 정도로 만족스럽다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

Windows 한글 계정명에서 발생하는 CMake 빌드 에러 원인과 해결 방법

편견장 — Tue, 31 Mar 2026 10:59:32 +0900

들어가며

최근 CMake를 C++ 프로젝트를 빌드하면서 특정 Windows PC에서만 빌드 에러가 발생하는 흥미로운 버그를 만났다.

향후 비슷한 문제를 마주했을 때 빠르게 원인을 파악하고 대처할 수 있도록,

이번 트러블 슈팅 과정에서 배운 버그 발생 원인과 해결방법을 정리해 보려 한다.

문제 상황

이 빌드 에러는 다음과 같은 특정 환경에서만 발생했다.

OS: Windos
Windows 사용자 계정: 한글 이름 사용 (예: C:\Users\전인학\...)
OS 설정: "시간 및 언어 > 언어 및 지역 > Beta: ...Unicode UTF-8" 옵션이 꺼져 있는 상태

원인 분석: 빌드 도구 간의 인코딩 불일치

사용자 계정명이 한글일 때 오류가 발생하는 원인을 조사해 보니,

빌드 파이프라인에 동원되는 각 도구별로 사용하는 인코딩(코드 페이지)이 달라서 발생하는 문제라는 걸 알았다.

예를 들어, MinGW를 이용해 컴파일 및 링킹을 수행하는 과정은 다음과 같다.

CMake → mingw32-make → g++ → ld → 실행파일(.exe) / 라이브러리(.dll)

여기서 문제는, 이 도구들이 문자열(경로, 인자 등)을 주고받을 때 작동하는 방식이다.

*인코딩 형식은 대부분 툴이 빌드될 때 결정되며, 최신 도구들은 자체적으로 UTF-8을 기본으로 사용하는 경우가 많다.

MinGW를 이용한 빌드과정

영어 알파벳, 숫자, 범용 특수문자(/, \, _, - 등)와 같은 ASCII 문자로만 이루어진 경로라면

읽는 쪽과 보내는 쪽이 UTF-8이든 UTF-16이든 문자가 깨질 일이 없다.

하지만 경로 중간에 한글이 섞여 있다면 어느 한 구간에서라도 양쪽 도구 간 파싱하는 인코딩이 어긋날 경우 텍스트가 깨지고,

파일을 찾지 못하는 치명적인 빌드 에러로 직결된다.

버그 검증 및 재현

제일 먼저 Windows OS의 활성 코드 페이지 설정을 확인했다.

Windows11 기준으로, cmd창에서 chcp 명령어를 입력하면 UTF-8 옵션 활성화 여부에 따라 코드페이지가 달라지는 것을 확인할 수 있었다.

Windows11 OS UTF-8 Codepage사용 옵션

옵션 체크 시 (65501=UTF-8)

옵션 해제 시 (949=EUC-KR 확장)

원인 파악 후, Windows에 한글 유저 계정을 추가하고 간단한 C++ HelloWorld 프로젝트를 구성하여 버그를 재현할 수 있었다.

CMakeLists.txt

cmake_minimum_required(VERSION 3.15)
project(TinyClassTest LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

add_executable(tiny_test
    src/main.cpp
)

src/main.cpp

#include <iostream>

int main() {
    std::cout << "Hello, World!" << std::endl;
    return 0;
}

파일 생성 후 다음 명령어로 빌드를 수행해 보면, 옵션 활성화 여부에 에러 양상이 갈리는 것을 확인할 수 있다.

▶ cmake -S . -B build -G "MinGW Makefiles"
-- The CXX compiler identification is GNU 8.1.0 
-- Detecting CXX compiler ABI info 
-- Detecting CXX compiler ABI info - done 
-- Check for working CXX compiler: C:/Qt/Tools/mingw810_32/bin/c++.exe - skipped 
-- Detecting CXX compile features 
-- Detecting CXX compile features - done 
-- Configuring done (1.0s) 
-- Generating done (0.0s) 
-- Build files have been written to: C:/Users/전인학/Desktop/cmake-utf16-test/build
▶ cmake --build build
CMake Error: Target DependInfo.cmake file not found 
mingw32-make.exe[2]: *** No rule to make target 'C:/Users/전인학/Desktop/cmake-utf16-test/src/main.cpp', needed by 'CMakeFiles/tiny_test.dir/src/main.cpp.obj'.  Stop. 
mingw32-make.exe[1]: *** [CMakeFiles\Makefile2:82: CMakeFiles/tiny_test.dir/all] Error 2 
mingw32-make.exe: *** [Makefile:90: all] Error 2

해결 방법

이 문제를 해결하기 위해 고민해 본 몇 가지 방법들이 있고, 나는 ①번 방식으로 버그를 해결할 수 있었다.

① ASCII 경로만 사용하기 (공용 폴더 활용 / ASCII Staging)

모든 프로젝트 경로와 인자에 한글이 포함되지 않는 ASCII 문자열만 사용하는 방식이다.

이 방식을 채택할 땐 경로의 접근 권한이 사용자 고유 권한인지 범용 공유 권한인지 잘 고려해야 한다.

예시 경로	설명
C:\Users\전인학\...	'전인학' 사용자의 고유 위치로 인식되어 보안상 좋지만, 한글 경로 문제가 생길 수 있음
C:\ProgramData\TempStage\	여러 사용자가 공유하는 범용 위치로 인식되며 경로에 한글이 없어 인코딩 충돌을 우회할 수 있음

② Windows의 subst 명령어 활용

Windows 커맨드인 subst를 사용하여 기존의 긴 경로를 가상의 논리 드라이브로 간단하게 매핑할 수 있다.

예: 커맨드 라인에 subst M: C:\Users\전인학\... 등록
이후 빌드 툴에는 "M:\TempStage"처럼 ASCII로만 이루어진 맵핑 경로만 전달되므로 문제를 회피할 수 있음.

③ 빌드 도구 인코딩 강제 일치시키기 (비추)

모든 빌드툴의 인코딩 방식을 강제로 일치시켜 해결하는 방법.

하지만 MinGW 대신 Ninja로 툴을 전환한다거나, 내부 구현을 알 수 없는 서드파티 툴이 파이프라인에 섞일 경우 제어가 불가능해지기 때문에 현실적인 문제가 많아 옳은 방식은 아닌 것 같다.

회고

이번 트러블 슈팅 과정에서 조금 어려웠던 점은,

현재 프로젝트의 경우 빌드가 사용자 PC환경에서 실행되고 빌드 툴 로그를 별도로 수집하지 않아 디버깅이 까다로웠다는 점이다.

하지만 결과적으로 Windows 환경에서는 사용자 계정 명에 한글이 자유롭게 쓰일 수 있다는 예외 상황을 경험해 볼 수 있었다.

이에 더해 빌드 툴들의 인코딩 처리 메커니즘, OS의 코드 페이지 동작 방식, 그리고 subst 나 공용 폴더 격리 같은 실용적인 회피 기법까지 다양하게 배울 수 있는 계기가 되었다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

Antigravity 구독 취소 방법(환불정책)

편견장 — Thu, 26 Mar 2026 16:05:49 +0900

들어가며

개발에 본격적으로 AI Agent를 사용하기 시작하면서

Cursor를 사용했다가 Antigravity로 넘어왔지만, 회사에서 Github Copilot을 구매지원을 해 주면서 불필요해졌다.

AI도구는 워낙 빠르게 엎치락 덮치락 하다 보니 도구 변경이 잦고 계속 적응해야 살아남는 시대가 된 것 같다.

이런 환경에서 구독 서비스가 워낙 많아, 서비스요금제를 잘못 구매하거나 안 쓰는 서비스를 방치하지 않는지 조심하자.

Antigravity 환불 정책

26년 3월 26일 기준 Antigravity는 월 구독 서비스이다.

Antigravity를 사용중이라면 한국 기준으론 부분환불 정책은 없어, 한 달 단위로 요금을 지불해야 한다.

단, 요금제를 잘못 선택하거나 실수로 구매한 경우에는 구매한 방법에 따라 환불 정책이 다르게 적용된다.

GoogleOne으로 구매한 경우는 어렵다고 보면 되고,

PlayStore에서 구매한 경우 환불 정책에 의해 48시간 이내, 문의를 통해 시도해 볼 수 있다.

https://support.google.com/googleplay/workflow/9813244?hl=ko

*다만 최근에는 환불요청을 거절당하는 사례가 늘고있다고 한다.

Antigravity 구독 취소 방법

https://antigravity.google/pricing 에 접속해 로그인을 위해 Pricing-Get plan 를 선택한다.

1. Antigravity 접속

로그인 후 멤버십 관리 탭에서 현재 요금제를 확인할 수 있다.

아래로 스크롤해 멤버십 취소 를 선택하자.

2. 현재 구독 요금제 확인

3. 멤버십 취소

멤버십 정기결제 탭에서 정기 결제 취소 로 멤버십을 취소할 수 있다.

4. 정기 결제 취소

나의 경우 다음 결제일이 4.23일 인 것을 볼 수 있는데 환불정책에 의해 다음달까지 사용할 수 있다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

Antigravity 사용 후기 : 2026.02.17 - [개발] - 구글 Antigravity 사용 후기 - QML프로젝트로 AI IDE 특징 알아보기

구글 Antigravity 사용 후기 - QML프로젝트로 AI IDE 특징 알아보기

들어가며요즘 AI를 활용한 이른바 '바이브 코딩(Vibe Coding)'은 더 이상 특별한 일이 아니다.간단한 프로젝트 생성부터 기능 추가, 빌드 자동화까지 AI에게 맡기는 흐름이 자연스러워지고 있다. 특

prejudice.tistory.com

Antigravity 사용 예제 : 2026.02.26 - [개발] - AI와 공장 자동화(FA)연동 따라하기 - PLC 예제로 구현한 MCP

AI와 공장 자동화(FA)연동 따라하기 - PLC 예제로 구현한 MCP

들어가며최근 AI가 빠르게 발달하면서 FA(Factory Automation) 업계에서도 AI의 적극적인 도입을 검토하는 움직임이 있다. 현장에서는 "우리 공장 설비(서비스)를 AI와 연동할 수 있을까?"에 대한 수요가

prejudice.tistory.com

붉은사막 컨트롤러 키조합 세팅 - 8BitDo 조작감 개선

편견장 — Mon, 23 Mar 2026 21:47:42 +0900

부정적인 리뷰가 많아 남들에게 말하기 부끄럽지만,

이번에 새로나온 펄어비스의 붉은사막(Crimson Desert)을 나름 즐기고 있다.

진짜 불쾌한 경험인 붉은사막의 조작감은 리뷰에서도 말이 많은데...

컨트롤러의 키조합 기능을 이용하면 조금이나마 잘 즐길 수 있을 것 같아 글을 남긴다.

8BitDo ultimate 2 컨트롤러 후면버튼

사용 컨트롤러 : 8BitDo Ultimate 2

이 컨트롤러의 특징은 후면부에 위치한 N 4개의 추가 키(L4, R4, PL, PR) 이다.

8Bitdo ultimate 2 전면부

8Bitdo ultimate 2 후면부

키조합 기능

저 4개의 키는 별도의 SW 다운로드 없이, 여러 키를 조합하여 매핑할 수 있다.

예를들어 R4 = RB + A 이런식으로 매핑을 하면 R4키가 RB버튼과 A버튼을 동시에 누른것으로 동작한다.

조합키 등록 방법. (R4 버튼에 RB+A 조합 사용시)

1) R4 + RB + A 버튼을 동시에 누르기

2) 누른 상태로 전면부의 ■ 버튼을 눌렀다 때기 (중앙 LED가 깜빡이면 등록됨)

조합키 해제 방법. (R4 버튼에 등록된 기능 해제시)

1) R4 버튼 누르기

2) 누른 상태로 ■ 버튼을 누르기

주의) 만약 컨트롤러 전용 SW(8BitDo Ultimate Software V2) 를 사용중이라면
Profiel 을 비활성 했을 경우에만 조합키 사용이 가능하다.

붉은사막에 적용

나는 키조합 기능을 다음과 같이 사용한다.

1. 섭리의 힘 : PL 버튼에 (L누름) 키를 매핑

L누름키다 보니 저상태로 이동하기가 굉장히 어색한데, 버튼 하나로 할 수 있다.

섭리의 힘 키 매핑

2. 찌르기 : R4 버튼에 (RB + Y) 키 매핑

찌르기키는 RB 일반공격키와 Y를 조합해 가끔 일반공격이 나갈때가 있는데

키조합을 사용하니 달리면서 쓰거나 모아쓰기에 확실히 편했다.

찌르기 키 매핑

3. 회전가르기 : PR 버튼에 (RB+RT) 키 매핑

내 기준으로 가장 괴랄한 스킬인 회전가르기는, 오른쪽 검지로 누르는 RB와 오른쪽 검지로 당기는 RT키를 같이 눌러야 해

컨트롤러 파지법을 바꿔야 쓸 수 있는 스킬이였다... 조합키 기능으로 중지로 누를 수 있어 행복하다.

*영상에 평타를 섞어 쓴 회전가르기는, 평타중 바로 스킬을 쓸 수 있다는걸 보여주기 위함입니다...

회전가르기 키 매핑

붉은사막은 왜 이 기초적인것들을 기본 옵션으로 제공 하지 않는지, 솔플 액션게임인데 왜 조작을 어렵게 해둔건지,

괴랄한 키 조합은 누구 머리에서 나온건지 궁금해지며 글을 마친다.

컨트롤러를 많이 쓰지않아 듀얼센스나 엑박은 써보지 않았고, 엑스박스는 키가 적은 기초적인 버전만 써봐서 키매핑 기능이 있는지 모르겠다.

8BitDo 의 키매핑 기능을 처음 써봤는데 등록/해제가 쉽고 진짜 잘 만든 컨트롤러로 느껴진다.

ps. 컨트롤러 광고나 게임광고 절대 아닙니다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

Real-Time, RTOS, PREEMPT_RT, CPU Isolation 개념 정복 - 실시간 처리

편견장 — Thu, 19 Mar 2026 17:41:05 +0900

들어가며

'실시간(Real-time)'이라는 용어는 Embedded 및 FactoryAutomation 산업의 핵심이며,

현장에서 다양한 관점과 의미로 혼용되곤 한다.

또한 자연스럽게 따라오는 '처리 속도'는 모든 SW/HW의 핵심 지표이지만, 실시간성과 도일한 개념으로 혼동되기 쉽다.

이번 글에서는 개발자의 입장에서 실시간성, RTOS, RT패치, CPU Isolation 등의 개념을 정리하고,

실제 개발 시 고려해야 할 점들을 학습해 보려 한다.

범용 OS가 발전하고 소프트웨어 아키텍처가 복잡해짐에 따라
OS 스케줄링, 인터럽트, 동시성(Concurrency)과 병렬성(Parallelism) 등 성능에 영향을 미치는 요소가 많아진다.
이 글에서는 기초적인 운영체제 지식이 있다고 가정하며, 직관적인 이해를 위해 극단적인 상황을 가정한다.

실시간성 (Real-time)

실시간성(Real-time)이란 데이터 처리나 시스템 응답이 정해진 시간제한(Deadline) 내에 반드시 완료되는 것을 의미한다.

예를 들어, 주기적으로 센서 값을 읽고 제어 신호를 출력하는 시스템의 데드라인이 1ms라면,

해당 작업은 반드시 1ms 이내에 완료되어야 한다.

이때는 애플리케이션 내부 로직뿐만 아니라 최대 응답 시간에 직접적인 영향을 주는 요소들을 함께 고려해야 한다.

OS Scheduling 지연
Interrupt 처리 지연
Mutex 등 동기화 메커니즘에 의한 대기 시간
Context Switching 비용
Garbage Collector와 같은 메모리 등록 및 해제 시간

Hard Real-Time System vs Soft Real-Time System

두 시스템의 차이는 Deadline을 넘겼을 때 얼마나 치명적인 가로 구분된다.

Soft Real-Time: deadline가 품질 저하로 이어짐. (ex. 영상/음성 스트리밍, 게임 렌더링, 회복/대응이 가능한 공장시스템 등)
Hard Real-Time: deadline miss가 곧 실패. (ex. 미사일, 항공, 의료, 인공위성 제어 등)

프로그램이 Deadline을 만족하는지 확인하고 보장하는 방법에는 두 가지 측면이 있다.

측정 기반(Measurement-based)
다양한 조건과 시뮬레이션을 수없이 반복하여 경험적인 최악의 실행 시간(WCET, Worst Case Execution Time)을 도출한다.
계산 및 증명 기반(Static Analysis)
코드 수준에서 구조적 실행 횟수가 확정적이라면 수학적으로 WCET를 엄밀하게 계산할 수 있다.
예를 들어, 다음의 코드에서 최악의 조건 분기에서 반복문을 1,000번 수행함을 보장할 수 있으므로, 하드웨어 명령어 처리 시간을 기반으로 전체 소요 시간을 증명할 수 있다.

// 한 명령어 시간 = CPU 클럭 + 명려어 사이클 수 + 메모리 접근 조건
if(condition) {
  for (int i=0; i<10; i++)
  	sum += i;
} else {
  for (int i=0;i <1000; i++)
    sum += i;
}

RTOS (Real-Time Operating System)

RTOS는 실시간 작업에 대해 예측 가능한 응답 시간(Determinism)을 지원하도록 설계된 운영체제이다.

범용 OS에 비해 우선순위 기반 스케줄링, 짧고 예측 가능한 인터럽트/스케줄링 지연, 단순한 커널 구조를 갖추어 개발자가 실시간성을 분석하고 보장하기 아주 쉬운 구조와 API를 제공한다.

즉, RTOS는 실시간성을 분석하고 보장하기 쉬운 구조 를 제공한다.

범용OS 와 RTOS의 차이

RTOS에 대해 가지는 오해

첫 번째는 ❌RTOS는 무조건 빠를 것 이라는 생각이다.

OS 동작 측면에서 불필요한 스위칭이나 군더더기가 없어 즉각적이라고 할 수는 있지만,

순수 연산의 실행 속도는 CPU 클럭에 비례한다.

오히려 여러 작업을 동시에 처리해야 하는 상황에서는

멀티코어 최적화 및 GPU 가속을 적극적으로 활용하는 범용 OS의 전체 처리량(Throughput)이 훨씬 높고 빠를 수 있다.

따라서 RTOS의 본질은 '단순 속도'가 아니라 '결정성(Determinism)'에 있다.

두 번째 오해는 ❌RTOS를 사용하면 Deadline을 절대 넘기지 않는다 는 바람이다.

RTOS 자체가 지연을 없애주지는 않고, 시스템 설계가 잘못되어 인터럽트가 폭주하면 RTOS도 당연히 지연된다.

다만, 범용 OS는 이런 지연의 크기를 계산하기 불가능해 사후 장애로 인지하게 된다면,

RTOS는 그 지연 시간의 최댓값을 사전에 분석 가능하고 통제 가능하게 설계할 수 있다.

범용 OS : 인터럽트 발생 시 얼마나 늦을지 계산이 어려움 → 막연하게 기다리며 사후에 알게 됨
RTOS : 인터럽트 실행 전 예측가능함 → 대응 로직 설계 가능

RTOS의 종류와 빌드

대표적인 RTOS는 FreeRTOS, VxWorks, Micrium, QNX 등이 있다.

주로 C/C++ 언어로 개발하며 OS별로 호환되는 특정 툴체인을 통해 펌웨어를 빌드하게 된다.

RTOS는 커널 코어가 공통된 스케줄링 및 락 메커니즘을 제공하지만, ARM Cortex-M, RISC-V, x86 등 타깃 시스템이 되는 CPU 아키텍처에 맞춘 포팅 계층(Porting Layer)이 필요하다.

저수준의 콘텍스트 스위칭 기법, 타이머 Tick 발상 제어, 스택 프레임 구조 등 하드웨어 의존적인 파트를 이어줘야 하기 때문이다.

더불어 타깃 보드의 주변장치(UART, SPI, I2C, GPIO 등)를 제어하려면 하드웨어 초기화 코드와 드라이버 모음인 BSP(Board Support Package) 혹은 HAL(Hardware Abstraction Layer) 과의 결합이 필수적이다.

다행히 일반적인 실무 개발에서는 커널을 직접 짜는 대신, 이미 잘 만들어진 RTOS 커널과 벤더의 HAL을 융합해 그 위에서 애플리케이션 Task를 얹어 개발할 것이다.

RT 패치 (PREEMPT_RT)

정식 명칭은 PREEMPT_RT로 기존 리눅스(Linux) 커널의 구조를 수정하여 실시간성을 지원하도록 만든 기술이다.

커널의 선점·락·인터럽트 동작 구성을 변경해 실시간성을 제공한다.

RT 패치라고 용어는 Linux에 덧붙이던 '패치 셋'으로 출발했기 때문에 과거에 불리던 이름이다.
Linux Kernel 6.12 버전부터 공식적으로 병합되어 PREEMPT_RT라는 이름으로 발표되었다.

PREEMPT_RT의 기술적 핵심은 커널 내부의 비선점 구간을 최소화하고, 인터럽트 처리를 스레드로 처리 하여 개발자가 우선순위 기반으로 인터럽트 처리를 스케줄링을 가능하게 만드는 데 있다.

실시간성을 가져야 하는 'Task B'가 동작하는 Linux OS의 타임라인을 상상해 보자.

기존 Linux 커널은 Hardware IRQ 처리를 최우선시하여 모든 IRQ를 처리 한 뒤 Task B가 실행된다.

최악의 경우 Interrupt가 많이 발생한다면, Task B는 아예 실행되지 못할 수 있다. (실시간성을 보장하지 못함)

기존 Linux Kernel의 Inturrupt 처리 타임라인

반면 PREEMPT_RT 커널은 Kernel이 선점하는 구간을 줄이고 IRQ 후처리를 Thread로 처리하는 구조이다.

따라서 Task B의 우선순위가 높다면 IRQ thread보다 먼저 실행되도록 보장받을 수 있다.

이는 인터럽트 발생 시 TaskB가 실행될 것을 예측할 수 있음을 의미한다. (실시간성 보장)

PREEMPT_RT Kernel의 Inturrupt 처리 타임라인

Jitter (지터)
Jitter의 사전적 의미는 전송 신호가 이상적인 기준 시간으로부터 미세하게 흔들리는 지연시간을 의미한다.
즉, 기존 Linux 커널에서는 하드 IRQ나 커널의 비선점 락에 치여 Task B의 시작 주기가 일정하지 않게 흔들릴 수 있다.
반면, PREEMPT_RT는 태스크를 선점가능하게 만들어 Jitter를 줄이고 분석 가능하게 만들었다는 데 의미를 가진다.

예시) 1ms 주기의 태스크 실행

Task 실행 1회 차 Task 실행 2회 차 Task 실행 3회 차

범용 OS 1.0ms 1.7ms 2.3ms

RTOS 또는 PREEMPT_RT 1.0ms 1.01ms 1.03ms

CPU Isolation

앞서 Jitter에 대해 살펴본 내용을 기준으로 보면,

RTOS 또는 PREEMPT_RT는 커널 내부의 비선점 구간과 인터럽트 처리 지연을 줄여 Kernel Jitter를 완화한 것을 알 수 있다.

하지만 여전히 다음과 같은 이유로 OS Jitter가 발생할 수 있다.

context switch 시간
mutex, semaphore 등 동기화 객체 대기 시간
같은 우선순위 태스크 간 round-robin 스케줄링
주기적 timer tick
IRQ thread, kworker, RCU callback 등 커널의 housekeeping 작업
드라이버 및 백그라운드 시스템 작업

이러한 수십 마이크로초 수준의 방해마저 용납할 수 없는 환경에서, 멀티코어 자원을 분할하는 CPU Isolation을 고려할 수 있다.

CPU Isolation란 특정 CPU 코어를 특정 작업에 사용하도록 격리 하여 OS작업과 분리하는 기법이다.

일반 CPU 코어	IRQ 처리, 커널 스레드, 백그라운드 작업 수행
Isolated CPU 코어	중요한 실시간 태스크 위주로 실행

이를 통해 태스크가 실행되는 환경을 더 단순하고 조용하게 만들어, OS Jitter를 좀 더 줄일 수 있다.

마치며

이번에는 "실시간성"이라는 단어로 시작해, 평소 막연하던 다가왔던 추상적 개념들을 공부해 보았다.

필요성이 대두될 때 가장 밀도 있게 성장하듯, 현재 개발 중인 SW PLC 프로젝트에 도입하기 위해 집중적으로 학습할 수 있었다.

최근에는 생산 설비가 정교하고 민감해짐에 따라, 과거 군사 제어기나 항공 우주 등급에서나 주로 논의되던 이러한 딥다이브 기술들이 일반 Factory Automation 산업에도 빠르게 들어오는 것을 느꼈다.

이번 기회를 통해 기초적인 개념을 정확하게 잡았고,

특히 RealTime → RTOS → PREEMPT_RT → CPU Isolation 과정으로 스토리를 가지고 개념을 확실하게 다질 수 있었다.

이제 앞으로 다가올 현장의 시스템 한계점과 장단점을 부딪혀가며 기술 영역을 보다 넓게 확장해 나가야겠다.

ps. 작년 Qt Coco 툴을 사용한 Code Coverage 분석교육을 들었는데, 이번에 WCET(Worst Case Execution Time) 개념에서, 프로그램 코드를 통해 최악의 소요시간을 수학적으로 측정하고 증명한다는 포인트가 굉장히 흡사하고 흥미로웠다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

SW USB 동글 라이선스 인증 구현하기 - Sentienl API와 C++ 클래스 설계

편견장 — Fri, 13 Mar 2026 17:27:39 +0900

들어가며

지난 글에서는 USB 동글 보안의 원리를 학습하고, Sentinel EMS를 통해 USB 동글을 프로비저닝 하는 과정을 다뤘다.

이번 글에서는 해당 동글을 제어하는 C++ Class를 설계하고,

실제 Software PLC 시스템에 적용할 USB 동글 기반 라이선스 인증 기능을 구현해 보려 한다.

2026.03.04 - [개발] - HW USB 동글 보안 시스템 구축하기 - Sentinel EMS 프로비저닝 실무

HW USB 동글 보안 시스템 구축하기 - Sentinel EMS 프로비저닝 실무

들어가며지난 글에서 USB 동글 보안 원리를 학습하고, Sentinel 동글 솔루션의 구조를 분석했다.이번 글에서는 한 단계 더 나아가 실제 Sentinel USB 동글에 라이선스 정보를 저장해 보려고 한다. 최종

prejudice.tistory.com

SW 요구사항 정리

개발에 앞서 이번 라이선스 인증 모듈에서 처리해야 할 핵심 소프트웨어 요구사항은 다음과 같다.

☑ HMI 서비스: FeatureID 1 사용
☑ PLC(MuLiN) 서비스: FeatureID 2 사용
☑ 통합 동글 지원: Feature1과 Feature2가 함께 존재하면 HMI + PLC 통합 라이선스로 동작
☐ PLC 서비스만의고유 데이터 저장 (후순위 고려)

메모리 구조 및 클래스 설계

Sentinel USB 동글은 내부에 고유한 구조로 메모리가 저장된다.

Sentinel USB 동글 메모리 구조

그리고 Sentinel의 보안 스택을 살펴보면,

Application Area와 RTE(Runtime Environment)가 분리되어 있는 Server-Client 구조임을 알 수 있다.

Sentinel API가 FeatureID 단위로 로그인 세션을 관리하는것을 확인해,

이를 바탕으로 통합 제어가 가능한 C++ 클래스를 설계했다.

클래스의 주요 역할
☑ HMI와 PLC 서비스의 FeatureID 구분 및 관리
☑ 사내 고유 VENDOR_CODE의 안전한 저장
☑ Sentinel API 호출 래핑 (로그인, 로그아웃, 메모리 제어 등)

SentinelClient Class

SentinelClient C++ 클래스 구현

동글 제어의 핵심인 SentinelClient 클래스 이다.

Sentinel API의 x64 라이브러리 파일은 Sentinel EMS-Developer-RTE Installer 에서 다운로드할 수 있다.

현재 개발 중인 프로젝트는 MinGW 32bit 컴파일러를 사용하고 있으므로, 구버전 라이브러리를 사용하여 구현할 수 있었다.

 SentinelClient
┃  SentinelClient.cpp
┃  SentinelClient.h
┣  include
┃ ┗  hasp_api.h
┗  lib
  ┣  hasp_windows_109675.dll
  ┗  hasp_windows_109675.lib

SentinelClient.h

#pragma once

#include "include/hasp_api.h"
#include <map>

namespace Sentinel {
enum FeatureID {
  HMI = 1,
  MulinStandard = 2,
};

const static unsigned char vendorCode[] =
    "[Private Vendor Code...]";

class SentinelClient {
public:
  SentinelClient();
  ~SentinelClient();

  bool login(FeatureID id);
  void logout(FeatureID id);
  bool hasHandle(FeatureID id) const;
  bool checkAlive(FeatureID id);

  bool readReadWriteMemory(FeatureID id, unsigned int offset, unsigned int length, void *buffer);
  bool readReadOnlyMemory(FeatureID id, unsigned int offset, unsigned int length, void *buffer);

private:
  std::map<FeatureID, hasp_handle_t> m_handles;
};

} // namespace Sentinel

SentinelClient.cpp

#include "SentinelClient.h"
#include <iostream>

using namespace Sentinel;

SentinelClient::SentinelClient() {}

SentinelClient::~SentinelClient() {
  for (auto it = m_handles.begin(); it != m_handles.end();) {
    hasp_logout(it->second);
    it = m_handles.erase(it);
  }
}

bool SentinelClient::login(FeatureID id) {
  if (hasHandle(id)) {
        return true;
  }

  hasp_handle_t handle;
  const hasp_status_t status = hasp_login(id, vendorCode, &handle);

  if (status == HASP_STATUS_OK) {
    m_handles.emplace(id, handle);
    return true;
  }

  return false;
}

void SentinelClient::logout(FeatureID id) {
  if (!hasHandle(id)) {
    return;
  }
  hasp_logout(m_handles[id]);
  m_handles.erase(id);
}

bool SentinelClient::hasHandle(FeatureID id) const { return m_handles.find(id) != m_handles.end(); }

bool SentinelClient::checkAlive(FeatureID id) {
  if (!hasHandle(id)) {
    return false;
  }

  unsigned char buf[16] = {0};
  const hasp_status_t status = hasp_encrypt(m_handles.find(id)->second, buf, sizeof(buf));

  if (status == HASP_STATUS_OK) {
    return true;
  }

  logout(id);
  return false;
}

bool SentinelClient::readReadWriteMemory(FeatureID id, unsigned int offset, unsigned int length, void *buffer) {
  if (!hasHandle(id)) {
    return false;
  }

  const hasp_status_t status = hasp_read(m_handles[id], HASP_FILEID_RW, offset, length, buffer);

  if (status == HASP_STATUS_OK) {
    return true;
  } else {
    std::cerr << "Sentinel Read Failed. Error Code: " << status << std::endl;
    return false;
  }
}

bool SentinelClient::readReadOnlyMemory(FeatureID id, unsigned int offset, unsigned int length, void *buffer) {
  if (!hasHandle(id)) {
    return false;
  }

  const hasp_status_t status = hasp_read(m_handles[id], HASP_FILEID_RO, offset, length, buffer);

  if (status == HASP_STATUS_OK) {
    return true;
  } else {
    std::cerr << "Sentinel Read Failed. Error Code: " << status << std::endl;
    return false;
  }
}

GoogleTest를 활용한 Unit Test 검증

하드웨어(USB 동글)에 직접 의존성을 가지는 API이므로,

코드의 신뢰성을 높이기 위해 GoogleTest를 이용해 유닛 테스트를 작성했다.

클래스의 목적과 역할이 분명하기 때문에, AI의 도움으로 테스트 코드를 빠르게 작성할 수 있었다.

테스트 전제 조건
하드웨어 동글 기반 API 테스트이기 때문에, PC와 연결된 HW 동글 상태에 따라 결과가 다르게 나온다.
1. Sentinel USB 동글의 연결 유무
2. 동글 내부에 발급된 Feature Key의 존재 유무

 SentinelClient
┗  tests
  ┣  CMakeLists.txt
  ┗  SentinelClientTest.cpp

CMakeLists.txt

cmake_minimum_required(VERSION 3.10)
project(SentinelClientTests)

# Use C++17
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# Configure googletest from local directory
include(../../googletest/googletest.cmake)

# Add the test executable
add_executable(SentinelClientTests
    SentinelClientTest.cpp
    ../SentinelClient.cpp
)

# Include directories
target_include_directories(SentinelClientTests PRIVATE
    ${CMAKE_CURRENT_SOURCE_DIR}/..
    ${CMAKE_CURRENT_SOURCE_DIR}/../include
)

# Link libraries
target_link_libraries(SentinelClientTests PRIVATE
    gtest
    gtest_main
    "${CMAKE_CURRENT_SOURCE_DIR}/../lib/hasp_windows_109675.lib"
)

# For MinGW: statically link the standard libraries to avoid missing DLL errors at runtime (0xc0000135)
if(MINGW)
    target_link_options(SentinelClientTests PRIVATE -static -static-libgcc -static-libstdc++)
endif()

# Copy the required DLL to the output directory so the test can run
add_custom_command(TARGET SentinelClientTests POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E copy_if_different
        "${CMAKE_CURRENT_SOURCE_DIR}/../lib/hasp_windows_109675.dll"
        $<TARGET_FILE_DIR:SentinelClientTests>
)

# Add test
include(GoogleTest)
gtest_discover_tests(SentinelClientTests
    PROPERTIES ENVIRONMENT "PATH=${CMAKE_CURRENT_SOURCE_DIR}/../lib;$ENV{PATH}"
)

SentinelClientTest.cpp

#include "../SentinelClient.h"
#include <gtest/gtest.h>

using namespace Sentinel;

TEST(SentinelClientTest, InitializationTest) {
  SentinelClient client;
  EXPECT_FALSE(client.hasHandle(MulinStandard)); // Should not be logged in initially
}

TEST(SentinelClientTest, CheckLogin) {
  SentinelClient client;
  bool plcResult = client.login(MulinStandard);
  std::cout << "PLC Login Result: " << plcResult << std::endl;

  bool hmiResult = client.login(HMI);
  std::cout << "HMI Login Result: " << hmiResult << std::endl;
}

TEST(SentinelClientTest, LoginLogoutTest) {
  SentinelClient client;
  bool plcResult = client.login(MulinStandard);

  bool plcCheckResult = client.checkAlive(MulinStandard);
  EXPECT_TRUE(plcCheckResult);

  if (plcResult) {
    EXPECT_TRUE(plcResult);
    client.logout(MulinStandard);
    EXPECT_FALSE(client.hasHandle(MulinStandard));
  }
}

TEST(SentinelClientTest, ReadTest) {
  SentinelClient client;
  bool result = client.login(MulinStandard);
  if (result) {
    unsigned char buffer[16] = {0};
    bool readSuccess = client.readReadWriteMemory(MulinStandard, 0, 16, buffer);
    EXPECT_TRUE(readSuccess);
    if (readSuccess) {
      std::cout << "Read Data (16 bytes at offset 0): ";
      for (int i = 0; i < 16; ++i) {
        printf("%02X ", buffer[i]);
      }
      std::cout << std::endl;
    }
    client.logout(MulinStandard);
  } else {
    GTEST_SKIP() << "Login failed. Sentinel Dongle may not be connected.";
  }
}

Unit Test 결과

기존에 프로비저닝 해둔 MuLiN (PLC) 라이선스 동글을 꽂고 테스트 시 유닛 테스트를 통과하는 것을 확인했고,

이를 기반으로 HMI 동글만 있는 경우, 둘 다 꽂혀있는 경우, 하나도 없는 경우 등 다양한 지 케이스에 대한 검증을 마쳤다.

MuLiN License USB연결 후 실행된 Test 결과

Qt 연동 중 발견한 버그와 해결 과정 (Troubleshooting)

유닛 테스트 통과 후, 실제 애플리케이션과 결합하기 위해 QObject를 상속받는 LicenseManage 클래스를 추가했다.

LicenseManager Class

그리고 물리적인 USB 탈착 시 실시간으로 라이선스를 재검증하기 위해 Windows 이벤트 콜백과 LicenseManager::verifyLicense() 함수를 Signal/Slot으로 연결했다.

QObject::connect(&usbNotifyWindow, SIGNAL(deviceArrived()), g_licenseManager, SLOT(verifyLicense()));
QObject::connect(&usbNotifyWindow, SIGNAL(deviceRemoved()), g_licenseManager, SLOT(verifyLicense()));

연동 테스트 도중 라이선스 검증이 실패하는 버그를 발견할 수 있었다.

버그명	USB 이벤트 직후 라이선스 검증 실패
원인	Windows 장치 콜백 이벤트가 Sentinel RTE 엔진보다 빨리 발생함
문제	장치 인식 완료 전에 verifyLicense()가 호출될 수 있음
영향	정상 USB 동글이 "동글없음"으로 오인식 발생
대응	윈도우 이벤트 발생 후 500ms 지연 후 검증 수행

해당 버그는 LicenseManager::verifyLicenseDelayed() 지연시간을 부여하는 방식으로 해결할 수 있었다.

LicenseManager.h

#ifndef LICENSEMANAGER_H
#define LICENSEMANAGER_H

#include <QObject>
#include <QTimer>
#include <QElapsedTimer>

#include "SentinelClient.h"

class LicenseManager : public QObject
{
    Q_OBJECT
public:
    explicit LicenseManager(QObject *parent = nullptr);
    void startTimer();
    void stopTimer();

signals:
    void licenseActivated();
    void licenseDeactivated();
    void licenseExpired();

public slots:
    void verifyLicense();
    void verifyLicenseDelayed(); // USB인식을 위해, 500ms 대기후 라이선스를 실행

private slots:
    void onWatchdogTimeout();

private:
    static const quint64 k_interval = 30* 60 * 1000; // 라이선스 검사 주기
    static const quint64 k_expire = 30 * 60 * 1000; // 라이선스가 없을 때 유지시간

    Sentinel::SentinelClient m_sentinelClient;
    QTimer m_watchdog;
    QElapsedTimer m_expireTimer;

    bool tryLicenseLogin();
};

extern LicenseManager* g_licenseManager;

#endif // LICENSEMANAGER_H

LicenseManager.cpp

#include "LicenseManager.h"

using namespace Sentinel;

LicenseManager* g_licenseManager = NULL;

LicenseManager::LicenseManager(QObject *parent) :
    QObject(parent)
{
    m_watchdog.setInterval(k_interval);
    connect(&m_watchdog, &QTimer::timeout, this, &LicenseManager::onWatchdogTimeout);
}

void LicenseManager::startTimer()
{
    m_watchdog.start();
    verifyLicense();
}

void LicenseManager::stopTimer()
{
    m_watchdog.stop();
}

void LicenseManager::verifyLicense()
{
    if (tryLicenseLogin()) {
        if (m_expireTimer.isValid()) {
            m_expireTimer.invalidate();
            emit licenseActivated();
        }
    } else {
        if (!m_expireTimer.isValid()) {
            m_expireTimer.start();
            emit licenseDeactivated();
        } else {
            if (m_expireTimer.hasExpired(k_expire)) {
                emit licenseExpired();
            }
        }
    }

    if (m_watchdog.isActive()) {
        m_watchdog.start();
    }
}

void LicenseManager::verifyLicenseDelayed()
{
    QTimer::singleShot(500, this, SLOT(verifyLicense()));
}

void LicenseManager::onWatchdogTimeout()
{
    verifyLicense();
}

bool LicenseManager::tryLicenseLogin()
{
    if (m_sentinelClient.hasHandle(FeatureID::MulinStandard)) {
        return m_sentinelClient.checkAlive(FeatureID::MulinStandard);
    }

    return m_sentinelClient.login(FeatureID::MulinStandard);
}

회고

Sentinel API를 래핑 하는 C++ 클래스 설계부터 GoogleTest 검증, 실제 Qt 프로젝트 연동 중 발생하는 타이밍 이슈까지 다뤘다.

이번 개발을 진행하면서 범용성을 갖는 구조와 메모리 후킹 또는 오작동이 없도록 노력했다.

난이도 자체는 높지 않았지만 USB 동글 메모리 구조와 보안 스택에 대해 새롭게 배웠고,

Sentinel EMS를 통한 라이선스 프로비저닝 방식은 산업용 소프트웨어 배포 구조에서 좋은 레퍼런스로 보인다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

이전글: 2026.02.12 - [개발] - USB 동글 보안 시스템 동작 원리 ㅡ KeyLock 보안 스택

USB 동글 보안 시스템 동작 원리 ㅡ KeyLock 보안 스택

들어가며이번 프로젝트가 Open Beta 출시를 앞두고, HW USB 동글을 활용한 보안 기능 개발을 담당하게 되었다. 프로젝트는 MuLiN이라는 SW PLC로,WindowsLinuxARM 기반 HW환경에서 동작하며,USB 동글이 꽂혀

prejudice.tistory.com

이전 글: 2026.03.04 - [개발] - HW USB 동글 보안 시스템 구축하기 - Sentinel EMS 프로비저닝 실무

HW USB 동글 보안 시스템 구축하기 - Sentinel EMS 프로비저닝 실무

prejudice.tistory.com

HW USB 동글 보안 시스템 구축하기 - Sentinel EMS 프로비저닝 실무

편견장 — Wed, 4 Mar 2026 20:48:57 +0900

들어가며

지난 글에서 USB 동글 보안 원리를 학습하고, Sentinel 동글 솔루션의 구조를 분석했다.

이번 글에서는 한 단계 더 나아가 실제 Sentinel USB 동글에 라이선스 정보를 저장해 보려고 한다.

최종 목표는 현재 개발 중인 Software PLC 시스템에 USB 동글 기반 라이선스 인증 기능을 추가하기 위함이다.

이전 글 : 2026.02.12 - [개발] - USB 동글 보안 시스템 동작 원리 ㅡ KeyLock 보안 스택

USB 동글 보안 시스템 동작 원리 ㅡ KeyLock 보안 스택

prejudice.tistory.com

기존 동글 시스템 분석

개발을 시작하기 전에 기존 HMI 서비스에서 사용 중인 USB 동글 구조를 먼저 분석했다.

확인된 주요 특징은 다음과 같다.

Feature ID = 1
USB 동글 메모리에 Application 고유 데이터 저장

이를 기반으로 새로운 PLC 서비스용 동글 설계를 위해 다음과 같은 체크리스트를 작성했다.

☑ 기존 HMI용 USB와 호환성 유지
☑ PLC 서비스용 Feature ID = 2 사용
☑ Feature 1 + Feature 2가 함께 존재하면 HMI + PLC 통합 동글로 동작
☑ PLC 서비스만의 고유 데이터 저장

USB 동글 보안 설계

Sentinel에서 제공하는 hasp API를 분석한 뒤 최소 기능만 갖춘 구조로 클래스를 설계했다.

License Manager : 실제 라이선스 로직 처리
SentinelClient : Sentinel API호출 담당 및 동글 데이터 접근

Sentinel Client 클래스 설계를 통해 동글에 고유 데이터가 없다는 것을 확인했고, 바로 프로비저닝 구성으로 들어갈 수 있었다.

최소한의 기능만 갖춘 SentinelClient Class 설계

Sentinel EMS 프로비저닝 환경 구성

Sentinel은 USB 동글 관리 및 라이서스 발급을 위해

EMS(Entitlement Management System) 라는 웹 기반 관리 시스템을 제공한다.

EMS 설치 후 http://[ip]:8080/ems 주소로 접속할 수 있었다.

Feature 생성

먼저 PLC 서비스에서 사용할 Feature ID를 생성했다.

Catalog-Features-NewFeatur 버튼으로 Feature ID = 2 를 등록했다.

새로운 서비스로 사용할 Feature

*이미 상품화되어 사용중인 Feature가 있다면, 삭제 또는 수정에 주의하자.

새로운 Feature가 추가된 상태

Dynamic Memory 생성

Sentinel USB 동글 메모리를 사용하는 방법은 두 가지가 있다.

Fixed Memosy : 주소 기반으로 메모리를 직접 지정 (start address + size)
Dynamic Memory : 파일 형태로 접근 (File ID 기반 접근)

기존 HMI 시스템은 Fixed Memory를 사용하고 있었지만 테스트를 위해 Dynamic Memory 방식을 사용해 보기로 했다.

Catalog-DynamicMemory-New Memory 를 선택하여 100 Bytes의 크기를 갖도록 생성했다.

Dynamic Memory 생성 화면

Product 생성

Sentinel EMS에서 Product는 다음 요소를 포함하는 패키지 개념이다.

Feature
Memory
License 정책

이번 PLC 시스템을 위해 MuLiN_Standard 라는 신규 Product를 생성했다.

여기에 조금전 생성한 Feature2 와 Dynamic Memory를 등록했다.

PLC Software용 Product 생성

Product 설계 시 패키지구성이 중요한데 동글을 따로 팔기 위해서는 각각의 Product를 가지도록 구성해야 한다.

예를 들어 ProductA = Word + PPT + Excel 로 구성할 경우, 각각의 제품을 USB로 제작할 수 없다.

따라서 각각의 제품을 팔기 위해서는 다음과 같이 구성한 뒤, USB 생산 과정에서 조합하는 방식이 좋다.

ProductA = Word,ProductB = PPT,ProductC = Excel

프로비저닝 버닝 작업

Entitlements 생성 (주문서)

USB 동글 시스템

Sentinel에서는 실제 USB 동글 생산을 Entitlement (주문서) 단위로 관리한다.

즉 프로비저닝 환경구성이 끝났다면, 제조/운영 환경은 Entitlement 로 관리할 수 있다.

우선 Entitlement-Entitlements-New Entitlement 로 새 주문서를 생성하고,

Product Details탭에서 새로 만든 MuLiN_Standard Product를 추가하고 Produce로 주문서를 발행한다.

*기존에 있던 HMI 서비스 권한과 새로 만든 PLC 서비스 권한을 가진 USB제품을 다음과 같이 제작할 수 있다.
All-In-One USB = HMI Product + PLC Product
단, 두 Product 간 고정메모리 영역을 사용할 경우 데이터가 덮어써지지 않도록 주의해야 한다.

USB Burn 작업

주문서 생성 후 실제 USB 동글을 연결 하면

EMS에서 바로 Burn 작업을 진행할 수 있다.

예상치 못한 문제
바로 Burn 작업을 진행했으나 회사에서 사용하는 HL Pro 동글 모델은 Dynamic Memory를 지원하지 않았다.
결국 임시로 메모리 기능 없이 Feature만 기록해 USB를 구웠다...

Entitlements-Check In Key-Check In 로 동글 정보(Feature, Memory)를 확인할 수 있다.

USB 동글에 구워진 MuLiN_Standard 정보

회고

완성된 보안 USB 동글

이번 글에서는 Sentinel EMS를 사용해 USB 동글을 실제로 프로비저닝 하는 과정을 다뤘다.

이전 글에서 동글 보안 구조를 공부했기 때문에

Feature, Product, Entitlement 개념을 이해하는데 큰 도움이 되었다.

실무적으로 흥미로웠던 부분은

개발자가 어디까지 담당해야 하는지였다.

우리 회사의 경우, ERP 주문관리 및 USB제작은 생산팀이 담당하는데

이번 실습을 통해 개발 영역과 생산 영역의 경계를 이해할 수 있었다.

다음 글에서는 실제로 제작한 USB 동글을 이용 해

라이선스를 검증하는 C++ 클래스를 구현하는 과정을 정리해 보려고 한다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

프로그래밍 책 추천 - 코딩의 깊이를 더해준 인생 최고의 개발자 책 추천 BEST 3

편견장 — Fri, 27 Feb 2026 14:34:27 +0900

들어가며

C언어로 처음 프로그래밍을 처음 시작했던 중학생 때를 떠올려 보니, 어느덧 14년이라는 시간이 흘렀다.

14년 동안 공부하면서 대학, 대학원, 국비지원 학원의 교육 과정을 거쳤고,

실제 개발 경력도 만 3년이 돼가는 시점에서 그동안 읽었던 최고의 IT 도서들을 요약해 보려 한다.

개발을 처음 시작할 때 읽는 책은 주로 사용하는 프로그래밍 언어의 영향을 많이 받는데,

나는 다음과 같은 흐름으로 프로그래밍 언어를 공부했다.

C언어 : 프로그래밍 기본 개념 (절차적 언어의 특성, 함수, 구조체 등)
C++ : 언어에 대한 확장 (객체지향의 도입)
JAVA : 객체지향 개념에 대한 확장 (상속, 캡슐화, 라이브러리) 및 JVM 개념
C++ : 메모리 관리 개념에 대한 심화 (포인터 & Modern C++)
Python, Kotlin, C#, JavaScript : 그때그때 필요할 때마다 짧게 공부

객체지향의 사실과 오해

지금 내가 가지고 있는 "객체 지향"에 대한 개념을 확립해 준 책이다.

프로그래머가 지향해야할 설계 방법을 현실에 기반한 예시로 알기 쉽게 설명해 준다.

클래스 설계 뿐 아니라 UML작성, 아키텍처 설계 등에 있어 "객체 지향"으로 사고하는 방법을 알려주며,

더 나아가 CS(컴퓨터 과학)를 공부할 때 모든 개념을 객체로 상상할 수 있는 혜안을 준다는 점에서 강력 추천한다.

객체지향의 사실과 오해_2023.01.01

모든 프로그래머라면 읽어보는 것을 추천하는 책. 객체지향에 대한 전반적인 개념을 깔끔하게 정리하여 좋았다.일명 토끼책으로 유명한 책이다. 객체지향 프로그래밍에 대해 전반적인 내용을..

blog.aladin.co.kr

패턴 그리고 객체지향적 코딩의 법칙

출퇴근하며 가볍게 읽기 좋은 책이다. 디자인 패턴에 대해 스토리 텔링 형식으로 풀어낸 글이 기억에 남는다.

디자인 패턴은 실제 코딩에 적용하여 자연스럽게 코드에 묻어나오는 것이 중요한데,

이 책은 디자인 패턴별로 스토리를 만들어 상황과 이론을 연결하는 과정이 무척 재밌었다.

예제 코드가 C++ 기반으로 작성되어 있어 프로그래밍에 대한 기본적인 지식이 필요하다.

패턴 그리고 객체지향적 코딩의 법칙_2025.11.15

다양한 디자인패턴을 알아보고, 객체지향의 눈높이를 올릴 수 있는 책출퇴근하며 간만에 재미있게 읽은 컴퓨터 책이다. C++기반으로 작성된 다양한 디자인 패턴을 보면서 OOP에 대한 ...

blog.aladin.co.kr

클린 코드 Clean Code

읽으면서 협업에 대한 생각과 코딩 스타일을 발전시켰던 책이다.

네이밍 룰, 함수, 주석, 객체지향과 프로그래밍 이론까지 다양한 범위를 커버하는 꽤 두꺼운 책으로,

책상 한편에 두고 필요한 상황마다 특정 부분만 발췌해서 읽기 좋다.

현재 자신이 겪고 있는 상황이나 배경지식에 따라 받아들이는 깊이가 다르며, 현업에 바로 적용할 수 있는 내용들로 구성되어 있다.

클린 코드Clean Code_2024.01.01

프로그래머라면 두고두고 읽으며, 협업에 대한 생각과 코딩스타일을 발전해 나갈 수 있다. 얼마나 알고있는지에 따라 새롭게 배우고 익히는 코드 리팩토링 기본서.가독성이 좋고 의미있는 ...

blog.aladin.co.kr

마치며

물론 다른 좋은 책들도 많지만 운영체제 공룡책 이나 Effective C++ 같은 책이 없어 의아할 수 있다.

이유는 두 책 모두 중도 하차한 책이고, 일단 재미가 없어서 다 읽어도 평점 5점을 주기는 어려웠을 거라 생각한다.

나는 평점에 대해 후하지 않은 편인데,

별점 4점을 준 책 중에는 테스트 주도 개발-켄트 벡 도 있다. TDD에 대한 저자의 생각(작은 Task도 단위 테스트를 먼저 작성)과 나의 생각(필요한 부분에 필요한 테스트)이 다르다는 점이 그 이유이다.

글에서 추천한 세 가지 책은 나만의 별점 5점을 준 책들로, 동료 개발자나 친구들이 꼭 한번쯤 읽어봤으면 하는 책들을 골라보았다.

선정 기준은 '책을통한 발전 정도', '내용의 깊이'뿐만 아니라 '가독성'과 '재미' 또한 중요하게 고려했으며,

읽고 난 뒤 실제로 사고방식과 코드가 달라졌다고 느낀 책들이다.

앞으로도 개발자들이 읽을만한 깊이있고 재미있는 책이 많아졌으면 좋겠다.

추천할만한 책이나 궁금한 책이 있다면 댓글로 남겨주세요.
직접 읽어보고 다음 글로 정리해 보려고 합니다.

오히려 요즘엔 인문학 책을 읽어보려 노력하고 있는데, 가끔 인문학 책에서 업무 관리 방법이나 프로그래밍 철학 등 개발자로서 깊게 생각해 볼 만한 인사이트를 얻는 경우가 많음을 느낀다.

AI와 공장 자동화(FA)연동 따라하기 - PLC 예제로 구현한 MCP

편견장 — Thu, 26 Feb 2026 17:14:04 +0900

들어가며

최근 AI가 빠르게 발달하면서 FA(Factory Automation) 업계에서도 AI의 적극적인 도입을 검토하는 움직임이 있다.

현장에서는 "우리 공장 설비(서비스)를 AI와 연동할 수 있을까?"에 대한 수요가 늘어가고,

그에 따라 AI시스템 자체는 점점 복잡해지고 있다.

이 문제를 해결하기 위한 하나의 방법으로

Anthropic에서 제안한 MCP(Model Context Protocol)을 공부해 보았다.

이번 글에서는 MCP의 개념을 살펴보고,

간단한 PLC 시스템 예시로 MCP를 어떻게 적용할 수 있을지 정리해 보려 한다.

MCP (Model Context Protocol) 이란?

MCP란 AI 모델과 외부 데이터 또는 도구를 연결하기 위한 오픈 소스 프로토콜이다.

Cluade나 Gemini, ChatGPT 같은 생성형 AI는 텍스트 생성에는 뛰어나지만,

공장 설비를 직접 제어하거나
PLC 자원을 변경하거나
파일이나 프로그램을 실행하는 행위

는 스스로 수행할 수 없다.

만약 AI가 PC의 시스템 도구들을 자유롭게 다룰 수 있다면, 다음과 같이 지시할 수 있다.

"내 PC에 있는 C:\ledOnOff.exe 프로그램에 "true" 혹은 "false" 변수를 입력하면 LED를 제어할 수 있어, LED를 켜봐"

이처럼 AI가 이런 도구를 사용할 수 있도록 시스템과 AI 사이의 다리 역할을 하는 것이 MCP이다.

MCP Architecture

MCP프로토콜은 기본적으로 Server-Client 구조를 가지며, 모든 데이터는 JSON 형식으로 데이터를 주고받는다.

MCP Server: 도구를 제공하고 실행하는 서비스 (ex: PLC 제어 프로그램)
MCP Client: 도구를 사용하는 주체(AI Model).

Server-Client 구조의 MCP Architecture

LLM Model : 텍스트를 생성하는 추론엔진. ex) GPT, Claude, Gemini
LLM Agent : LLM Model + 도구(파일/터미널/프로그램 등) + 상태/메모리로 목표를 달성하는 시스템.
Agent 기반 IDE : 통합 개발 환경. ex) Cursor, Antigravity, VSCode(Agent 확장 시)

MCP 예제 설계: FA산업에 적용

산업 자동화 환경에서 AI를 활용한다고 가정해 보자.

작업자가 동료에게 지시하듯, AI에게 PLC 자원을 조작하도록 지시하는 것을 상상할 수 있다.

이번 예제에서는 LLM 에이전트로 Antigravity 환경을, LLM 모델로 Gemini 3.1을 사용하여

Soft PLC Application을 조작하도록 아키텍처를 작성했다.

PLC App과 AI서비스 Architecture

SoftPlcApp 개발 따라 하기

PLC State 구조 설계

PLC Memory는 최대한 간단하게 구성했다.

3색 경광등 상태와 생산 공정(Mixing → Coatinga → Winding → Slitting) 상태를 메모리에 저장한다고 가정해 보자.

그리고 사용자가 LED를 어떻게 사용할지 모르니, 매칭해 놓은 Comment가 있다고 생각하자.

// Simulates the PLC State
class PlcState {
public:
    bool redLed = false;
    bool yellowLed = false;
    bool greenLed = false;
    
    std::string redComment = "red: 재료가 부족하거나 생산이 불가능함 (에러/정지)";
    std::string yellowComment = "yellow: 이차전지 생산공정이 생산 중 (가동 중)";
    std::string greenComment = "green: 생산공정이 정상적으로 대기 중 (정상 대기)";
}

MCP에서 가장 중요한 것은 AI에게 도구의 의미를 설명하는 것이다.

단순히 "스위치를 이용해 redLED를 켤 수 있어"라고만 알려주면 AI는 단순한 스위치로 인식할 것이다.

하지만 "redLED는 재료가 부족하거나 생산이 불가능한 상태를 의미해"라고 명확히 알려준다면,

"현재 PLC상태가 어때?"라는 질문에 AI가 스스로 판단하여 LED 상태를 확인하고 답변할 수 있다.

나아가 AI에게 더 많은 제어 권한을 준다면, 스스로 빨간불을 감지하고 자동으로 재료를 보충하는 수준의 고도화된 자동화도 가능할 것이다.

MCP Server 구현

MCP는 JSON-RPC 메시지 기반이며, 동기 방식의 메서드 구조를 따른다.

프로토콜에 따르면 서버는 다음과 같은 메서드를 구현해 서비스를 제공한다.

initialize : 클라이언트가 서버에 연결할 때 필수적으로 최초 1회 보내는 요청. 서버의 기능들을 서로 교환한다.
tools/list : 서버가 가진 도구(Tool)들의 설명서 설명서. ex) LED 켜기/끄기, 공정상태 변경
tools/call : LLM이 서버의 도구를 사용할 때 호출하는 기능. ex) set_red_led(true), start_process("mixing")
resources/list : 서버가 제공하는 읽기 전용 자원(Resource) 목록. ex) LED 상태, 현재 프로세스 상태
resources/read : LLM이 실제 데이터를 읽어오기 위해 호출하는 기능. ex) redLed(), currentProcess()

앞에서도 말했듯, 메서드에서 가장 중요한 설명은 Description 태그를 이용해 AI에게 전달된다.

서버는 이 설명을 바탕으로

어떤 도구를 호출할지
어떤 자원을 읽어야 할지
어떤 순서로 작업해야 할지

를 판단한다.

SoftPlcApp.exe 코드

plc_state.hpp

#ifndef PLC_STATE_HPP
#define PLC_STATE_HPP

#include <string>

class PlcState {
public:
    PlcState() {
        update_leds_from_process();
    }

    bool redLed = false;
    bool yellowLed = false;
    bool greenLed = false;
    
    std::string redComment = "red: 재료가 부족하거나 생산이 불가능함 (에러/정지)";
    std::string yellowComment = "yellow: 이차전지 생산공정이 생산 중 (가동 중)";
    std::string greenComment = "green: 생산공정이 정상적으로 대기 중 (정상 대기)";
    
    std::string currentProcess = "Idle";

    bool set_current_process(const std::string& process) {
        if (process == "mixing" || process == "coating" || 
            process == "winding" || process == "slitting" || process == "Idle") {
            currentProcess = process;
            update_leds_from_process();
            return true;
        }
        return false;
    }

private:
    void update_leds_from_process() {
        if (currentProcess == "Idle") {
            greenLed = true;
            yellowLed = false;
        } else {
            greenLed = false;
            yellowLed = true;
        }
    }
};

#endif // PLC_STATE_HPP

mcp_server.hpp

#ifndef MCP_SERVER_HPP
#define MCP_SERVER_HPP

#include <string>
#include <nlohmann/json.hpp>

#include "plc_state.hpp"

class McpServer {
public:
    McpServer();

    // Process a JSON-RPC 2.0 request and return a JSON-RPC 2.0 response
    nlohmann::json handle_request(const nlohmann::json& request);

    // Provide access to the state for testing purposes
    const PlcState& get_state() const { return plc; }

private:
    PlcState plc;

    nlohmann::json handle_initialize(const nlohmann::json& request);
    nlohmann::json handle_tools_list(const nlohmann::json& request);
    nlohmann::json handle_tools_call(const nlohmann::json& request);
    nlohmann::json handle_resources_list(const nlohmann::json& request);
    nlohmann::json handle_resources_read(const nlohmann::json& request);

    // Helpers to create JSON-RPC responses
    nlohmann::json make_response(const nlohmann::json& id, const nlohmann::json& result);
    nlohmann::json make_error(const nlohmann::json& id, int code, const std::string& message);
};

#endif // MCP_SERVER_HPP

mcp_server.cpp

#include "mcp_server.hpp"

using json = nlohmann::json;

McpServer::McpServer() {}

json McpServer::handle_request(const json& request) {
    if (!request.contains("jsonrpc") || request["jsonrpc"] != "2.0") {
        return make_error(nullptr, -32600, "Invalid Request");
    }
    
    bool is_notification = !request.contains("id");
    json req_id = nullptr;
    if (!is_notification) {
        req_id = request["id"];
    }

    if (!request.contains("method")) {
        return is_notification ? json() : make_error(req_id, -32600, "Invalid Request: missing method");
    }

    std::string method = request["method"];

    try {
        if (method == "initialize") {
            return handle_initialize(request);
        } else if (method == "notifications/initialized") {
            return json();
        } else if (method == "tools/list") {
            return handle_tools_list(request);
        } else if (method == "tools/call") {
            return handle_tools_call(request);
        } else if (method == "resources/list") {
            return handle_resources_list(request);
        } else if (method == "resources/read") {
            return handle_resources_read(request);
        } else {
            if (is_notification) {
                return json();
            }
            return make_error(req_id, -32601, "Method not found");
        }
    } catch (const std::exception& e) {
        return make_error(req_id, -32603, "Internal error: " + std::string(e.what()));
    }
}

json McpServer::make_response(const json& id, const json& result) {
    return {
        {"jsonrpc", "2.0"},
        {"id", id},
        {"result", result}
    };
}

json McpServer::make_error(const json& id, int code, const std::string& message) {
    return {
        {"jsonrpc", "2.0"},
        {"id", id},
        {"error", {
            {"code", code},
            {"message", message}
        }}
    };
}

json McpServer::handle_initialize(const json& request) {
    // Simplistic initialize response
    json result = {
        {"protocolVersion", "2024-11-05"},
        {"capabilities", {
            {"tools", json::object()},
            {"resources", json::object()}
        }},
        {"serverInfo", {
            {"name", "plc-mcp-server"},
            {"version", "1.0.0"}
        }}
    };
    return make_response(request["id"], result);
}

json McpServer::handle_tools_list(const json& request) {
    auto make_led_tool = [](const std::string& tool_name, const std::string& description, const std::string& color_cap) -> json {
        return {
            {"name", tool_name},
            {"description", description},
            {"inputSchema", {
                {"type", "object"},
                {"properties", {
                    {"state", {
                        {"type", "boolean"},
                        {"description", "True면 " + color_cap + " LED를 켭니다. False면 해당 LED를 끕니다."}
                    }}
                }},
                {"required", {"state"}}
            }}
        };
    };

    json tools = json::array({
        make_led_tool("set_red_led", plc.redComment, "Red"),
        make_led_tool("set_yellow_led", plc.yellowComment, "Yellow"),
        make_led_tool("set_green_led", plc.greenComment, "Green"),
        {
            {"name", "start_process"},
            {"description", "Start a factory automation process"},
            {"inputSchema", {
                {"type", "object"},
                {"properties", {
                    {"process_name", {
                        {"type", "string"},
                        {"enum", {"mixing", "coating", "winding", "slitting", "Idle"}},
                        {"description", "The name of the process to start"}
                    }}
                }},
                {"required", {"process_name"}}
            }}
        }
    });
    
    json result = {
        {"tools", tools}
    };
    return make_response(request["id"], result);
}

json McpServer::handle_tools_call(const json& request) {
    if (!request.contains("params") || !request["params"].contains("name")) {
        return make_error(request["id"], -32602, "Invalid params: missing tool name");
    }

    std::string tool_name = request["params"]["name"];
    json arguments = request["params"].value("arguments", json::object());

    json content = json::array();

    if (tool_name == "set_red_led" || tool_name == "set_yellow_led" || tool_name == "set_green_led") {
        if (!arguments.contains("state")) {
            return make_error(request["id"], -32602, "Invalid arguments for " + tool_name);
        }
        
        bool led_state = arguments["state"];

        std::string color;
        if (tool_name == "set_red_led") {
            plc.redLed = led_state;
            color = "red";
        } else if (tool_name == "set_yellow_led") {
            plc.yellowLed = led_state;
            color = "yellow";
        } else if (tool_name == "set_green_led") {
            plc.greenLed = led_state;
            color = "green";
        }

        content.push_back({
            {"type", "text"},
            {"text", "Successfully set " + color + " LED to " + (led_state ? "on" : "off")}
        });
    } else if (tool_name == "start_process") {
        if (!arguments.contains("process_name")) {
            return make_error(request["id"], -32602, "Invalid arguments for start_process");
        }
        
        std::string proc = arguments["process_name"];
        if (plc.set_current_process(proc)) {
            content.push_back({
                {"type", "text"},
                {"text", "Successfully started process: " + proc}
            });
        } else {
            return make_error(request["id"], -32602, "Unknown process_name");
        }
    } else {
        return make_error(request["id"], -32601, "Tool not found");
    }

    json result = {
        {"content", content}
    };
    return make_response(request["id"], result);
}

json McpServer::handle_resources_list(const json& request) {
    json resources = json::array({
        {
            {"uri", "plc://state"},
            {"name", "PLC State"},
            {"description", "Current state of the PLC including LEDs and active process"},
            {"mimeType", "application/json"}
        }
    });
    
    json result = {
        {"resources", resources}
    };
    return make_response(request["id"], result);
}

json McpServer::handle_resources_read(const json& request) {
    if (!request.contains("params") || !request["params"].contains("uri")) {
        return make_error(request["id"], -32602, "Invalid params: missing uri");
    }

    std::string uri = request["params"]["uri"];
    
    if (uri == "plc://state") {
        json state_json = {
            {"redLed", plc.redLed},
            {"yellowLed", plc.yellowLed},
            {"greenLed", plc.greenLed},
            {"currentProcess", plc.currentProcess}
        };

        json contents = json::array({
            {
                {"uri", uri},
                {"mimeType", "application/json"},
                {"text", state_json.dump()}
            }
        });

        json result = {
            {"contents", contents}
        };
        return make_response(request["id"], result);
    } else {
         return make_error(request["id"], -32602, "Resource not found");
    }
}

main.cpp

#include "mcp_server.hpp"
#include <iostream>
#include <string>

using json = nlohmann::json;

int main() {
    McpServer server;
    std::string line;

    // Read JSON-RPC requests from standard input line by line
    while (std::getline(std::cin, line)) {
        if (line.empty()) continue;

        try {
            json request = json::parse(line);
            json response = server.handle_request(request);
            
            // Output JSON-RPC response to standard output followed by a newline
            if (!response.is_null()) {
                std::cout << response.dump() << std::endl;
            }
        } catch (const json::parse_error& e) {
            // Setup an error response simulating stdio JSON-RPC transport requirements
            json error_response = {
                {"jsonrpc", "2.0"},
                {"id", nullptr},
                {"error", {
                    {"code", -32700},
                    {"message", "Parse error"}
                }}
            };
            std::cout << error_response.dump() << std::endl;
        }
    }

    return 0;
}

SoftPlcApp.exe 테스트

위에 작성된 main.cpp 를 보면 std::cin 을 통해 표준 입력으로 요청을 받는 것을 알 수 있다.

프로그램 빌드 한 뒤, PowerShell에서 직접 JSON 포맷으로 요청(request)하여 응답 메시지를 확인할 수 있다.

PS C:\Projects\MCP> echo '{"jsonrpc": "2.0", "id": 1, "method": "initialize"}' | .\build\SoftPlcApp.exe

SoftPlcApp의 response 결과

매번 콘솔 파이프라인으로 테스트하는 것은 번거롭기 때문에, gtest를 이용해 단위 테스트를 구성했다.

client_test.cpp

#include "mcp_server.hpp"
#include <gtest/gtest.h>
#include <nlohmann/json.hpp>

using json = nlohmann::json;

class McpServerTest : public ::testing::Test {
protected:
  McpServer server;

  json invoke(const json &request) { return server.handle_request(request); }
};

TEST_F(McpServerTest, TestInitialize) {
  json req = {{"jsonrpc", "2.0"}, {"id", 1}, {"method", "initialize"}};

  json resp = invoke(req);

  EXPECT_EQ(resp["jsonrpc"], "2.0");
  EXPECT_EQ(resp["id"], 1);
  EXPECT_TRUE(resp.contains("result"));
  EXPECT_EQ(resp["result"]["protocolVersion"], "2024-11-05");
  EXPECT_EQ(resp["result"]["serverInfo"]["name"], "plc-mcp-server");
}

TEST_F(McpServerTest, TestListTools) {
  json req = {{"jsonrpc", "2.0"}, {"id", 2}, {"method", "tools/list"}};

  json resp = invoke(req);

  EXPECT_TRUE(resp.contains("result"));
  EXPECT_TRUE(resp["result"].contains("tools"));

  auto tools = resp["result"]["tools"];
  EXPECT_EQ(tools.size(), 4);
  EXPECT_EQ(tools[0]["name"], "set_red_led");
  EXPECT_EQ(tools[1]["name"], "set_yellow_led");
  EXPECT_EQ(tools[2]["name"], "set_green_led");
  EXPECT_EQ(tools[3]["name"], "start_process");
}

TEST_F(McpServerTest, TestCallToolSetLed) {
  json req = {
      {"jsonrpc", "2.0"},
      {"id", 3},
      {"method", "tools/call"},
      {"params", {{"name", "set_red_led"}, {"arguments", {{"state", true}}}}}};

  json resp = invoke(req);

  EXPECT_TRUE(resp.contains("result"));
  EXPECT_TRUE(resp["result"].contains("content"));
  EXPECT_EQ(resp["result"]["content"][0]["text"],
            "Successfully set red LED to on");

  // Verify PLC State actually changed
  EXPECT_TRUE(server.get_state().redLed);
  EXPECT_FALSE(server.get_state().yellowLed);
  EXPECT_FALSE(server.get_state().greenLed);
}

TEST_F(McpServerTest, TestCallToolStartProcess) {
  json req = {{"jsonrpc", "2.0"},
              {"id", 4},
              {"method", "tools/call"},
              {"params",
               {{"name", "start_process"},
                {"arguments", {{"process_name", "mixing"}}}}}};

  json resp = invoke(req);

  EXPECT_TRUE(resp.contains("result"));
  EXPECT_EQ(resp["result"]["content"][0]["text"],
            "Successfully started process: mixing");

  // Verify PLC State
  EXPECT_EQ(server.get_state().currentProcess, "mixing");
}

TEST_F(McpServerTest, TestReadResourceState) {
  // First, set a known state
  json req_set = {
      {"jsonrpc", "2.0"},
      {"id", 5},
      {"method", "tools/call"},
      {"params",
       {{"name", "set_green_led"}, {"arguments", {{"state", true}}}}}};
  invoke(req_set);

  // Now, read the state via resource
  json req_read = {{"jsonrpc", "2.0"},
                   {"id", 6},
                   {"method", "resources/read"},
                   {"params", {{"uri", "plc://state"}}}};

  json resp = invoke(req_read);

  EXPECT_TRUE(resp.contains("result"));
  EXPECT_TRUE(resp["result"].contains("contents"));
  EXPECT_EQ(resp["result"]["contents"][0]["uri"], "plc://state");

  // The text field contains the JSON string of the state
  std::string state_str = resp["result"]["contents"][0]["text"];
  json state_json = json::parse(state_str);

  EXPECT_FALSE(state_json["redLed"]);
  EXPECT_FALSE(state_json["yellowLed"]);
  EXPECT_TRUE(state_json["greenLed"]);             // We set this to true
  EXPECT_EQ(state_json["currentProcess"], "Idle"); // Default value
}

// Entry point for tests built by gtest_main
int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

SoftPlcApp.exe unittest 결과

Antigravity IDE 연동

MCP Server 프로그램 등록

이제 완성된 SoftPlcApp.exe 도구를 LLM 기반 IDE인 Antigravity에 등록해야 한다.

다음 경로의 설정 파일을 수정하여 MCP 프로그램을 등록할 수 있다.

C:\Users\[UserName]\.gemini\antigravity\mcp_config.json

{
    "mcpServers": {
        "soft-plc-app": {
            "command": "C:/Projects/MCP/build/SoftPlcApp.exe",
            "args": []
        }
    }
}

프로그램 등록 후 Antigravity IDE를 재실행하면, 백그라운드에서 SoftPlcApp.exeSoftPlcApp.exe가 실행된다.

경로설정에서 왜 Antigravity의 최상위 폴더가 .gemini인지 이해가 안 간다...
Antigravity에서 다른 AI Model (Claude or ChatGPT)를 써도 .gemini폴더의 MCP설정 파일을 사용한다.

MCP Server 설정확인

프로그램 등록 여부는 Antigravity: Manage MCP Servers 명령으로 확인할 수 있다.

Antigravity의 MCP 사용여부 설정 파일

Manage MCPs 탭에서는 AI Model과 연결된 설정 현황과,

MCP Server가 JSON 응답을 통해 제공하는 사용 가능한 도구들의 목록을 시각적으로 확인할 수 있다.

Antigravity Manage MCPs 설정탭

Gemini 이용한 PLC 조작

MCP Server가 연동됐다면 다음과 같이 AI에게 요청해 도구를 잘 사용하는지 확인할 수 있다.

▶ AI COMMAND INPUT
> 현재 PLC상태를 요약하고, 믹싱작업이 가능한지 확인해줘.

SoftPlcApp 도구를 이용한 상태확인

AI 모델의 강력함은 여러 도구를 적절하게 엮어 스스로 최적의 판단을 내려 작업을 완료한다는 것이다.

▶ AI COMMAND INPUT
> 5분뒤 믹싱작업 시작해

커맨드를 예약해 300초 후 mixing 작업 실행

만약 모종의 이유로 5분 뒤 명령실행에 실패했더라도 그 원인이 무엇인지 스스로 분석해 알려주었을 것이다.

회고

MCP를 직접 공부하고 적용해 보면서 개발의 편리함에 한 번 놀라고, 사람처럼 느껴지는 Antigravity에 두 번 놀랐다.

프로토콜 공부를 시작할 때는 개념만 이해하는 것이 목표였다.

하지만 AI의 도움으로 막히는 부분 없이, 개념 학습과 실습을 동시에 진행했고 학습 효율을 극대화할 수 있었다.

지금까지 MCP라는 기술은 다소 생소했지만, 이번 학습을 통해

Factory Automation 산업 구조와 굉장히 궁합이 잘 맞는 기술이라는 것을 느꼈고

특히 이번 예제에서 가상의 PLC를 구현했듯, 설비 데이터의 커스터마이징 영역을 고객들에게 넘겨준다면,

기존의 레거시 시스템과의 연계와 IT/OT의 확장도 훨씬 유연할 것이라고 생각한다.

기존의 IT/OT의 연계도 수월할 것이라 생각한다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

이전 글 : 2026.02.17 - [개발] - 구글 Antigravity 사용 후기 - QML프로젝트로 AI IDE 특징 알아보기

구글 Antigravity 사용 후기 - QML프로젝트로 AI IDE 특징 알아보기

prejudice.tistory.com

QML Stopwatch 구현 따라 하기 - MVVM 구조로 설계한 Qt 아키텍처

편견장 — Fri, 20 Feb 2026 16:40:55 +0900

들어가며

이전 글에서 QML의 내부 동작 원리와 C++ 연동 방법을 정리했다.

QML은 상태 기반 UI에 강점이 있고,

C++은 성능과 로직 처리에 강점이 있다.

하지만 두 영역을 철저히 분리하지 않으면 금방 스파게티 코드가 되어버리고,

유지보수 비용은 기하급수적으로 상승한다.

이번 글에서는 Stopwatch 예제를 통해

MVVM 원칙을 따르는 설계 방식을 정리해 보려 한다.

글을 작성하며 느낀 점은,
MVVM을 설명하는 과정이 곧 객체지향 개념을 설명하는 과정과 매우 닮아 있다는 것이었다.

내가 객체지향을 이해하는데 가장 큰 도움을 준 책은
<객체지향의 사실과 오해> 였다.
이 책은 "상태가 아니라 행동을 중심으로 설계하라"는 메시지를 강조한다.

이번 예제 역시 그 관점에서 접근했다.
https://blog.aladin.co.kr/Bbird/16866413

객체지향의 사실과 오해_2023.01.01

blog.aladin.co.kr

MVVM 기본 원칙

MVVM은 Model + View + ViewModel로 구성되는 아키텍처 패턴으로,

UI와 비즈니스 로직의 분리를 목표로 한다.

Qt에 대입하면 다음과 같이 정리할 수 있다.

패턴	구현방법	역할	원칙
View	QML	☑ UI 구성 ☑ 사용자 입력 전달 ☑ 상태 표현	로직을 넣지 않는다
ViewModel	QObject 기반 클래스	☑ UI 상태 제공 ☑ Signal / Slot 연결	Model과 View를 연결
Model	순수 C++ 로직	☑ 비즈니스 로직 구현	View와 ViewModel을 알지 못한다

설계 접근 방식

이번 예제에서는 View보다 Model부터 설계했다.

객체지향 설계에서는 "화면이 무엇을 보여줄 것인가?" 보다

"사용자가 무엇을 할 수 있는가?"가 더 중요하기 때문이다.

사용자의 행동은 다음 네 가지다.

Start
Stop
Reset
Lap

행동을 먼저 정의하고,

행동에 필요한 최소한의 상태를 추가해 Model을 설계했다.

Model (순수 C++)

StopwatchModel은 Qt와 의존성을 가지지 않고, 시간은 std::chrono::steady_clock으로 관리한다.

이렇게 의존성 없이 설계했을 때의 장점은 다음과 같다.

유닛 테스트가 쉽다
Qt에 종속되지 않는다 (개별 빌드가 가능하다)
재사용 가능하다

이 Model은 오직 시간 계산과 상태 관리만 담당한다.

핵심: Model은 View와 ViewModel을 모른다.

StopwatchModel.h

#pragma once
#include <chrono>
#include <vector>

class StopwatchModel {
public:
    struct Lap {
        int index;
        std::chrono::milliseconds elapsed;
    };

    void start();
    void stop();
    void reset();
    void lap();

    const std::vector<Lap>& laps() const { return m_laps; }
    std::chrono::milliseconds elapsed() const {
        if (m_running)
            return m_accum + std::chrono::duration_cast<std::chrono::milliseconds>(Clock::now() - m_startPoint);
        return m_accum;
    }
    bool isRunning() const { return m_running; }

private:
    using Clock = std::chrono::steady_clock;

    bool m_running = false;
    Clock::time_point m_startPoint{};
    std::chrono::milliseconds m_accum{0};
    std::vector<Lap> m_laps;
};

StopwatchModel.cpp

#include "StopwatchModel.h"

void StopwatchModel::start() {
    if (m_running) return;
    m_running = true;
    m_startPoint = Clock::now();
}

void StopwatchModel::stop() {
    if (!m_running) return;
    m_running = false;
    m_accum += std::chrono::duration_cast<std::chrono::milliseconds>(Clock::now() - m_startPoint);
}

void StopwatchModel::reset() {
    m_running = false;
    m_accum = std::chrono::milliseconds{0};
    m_laps.clear();
}

void StopwatchModel::lap() {
    if (!m_running) return;
    Lap l;
    l.index = static_cast<int>(m_laps.size() + 1);
    l.elapsed = m_accum + std::chrono::duration_cast<std::chrono::milliseconds>(Clock::now() - m_startPoint);
    m_laps.push_back(l);
}

일부러 StopwatchModel은 Qt에 의존하지 않도록 설계했다.

하지만 프로젝트의 성격에 따라 Qt 타입(QElapsedTimer, QString 등)을 사용하거나, 경우에 따라 QObject를 상속해도 무방하다.

중요한 것은 의존성을 선택할 수 있는 구조를 만드는 것이다.

이 구조에서는 Model을 gtest 같은 프레임워크로 단위 테스트가 가능하다.
UI 없이도 Stopwatch의 동작을 검증할 수 있다는 점이 구조적 분리의 가장 큰 장점이다.

View (QML)

QML은 명령을 수행하는 곳이 아니라 상태를 반영하는 곳이다.

따라서 View에서 로직을 작성하기 시작하는 순간 MVVM 구조는 무너지기 시작한다.

View를 설계할 때는 UI와 연결되는 객체의 상태를 중심으로 질문해야 한다.

"Start 버튼을 누르면 어떤 동작을 할까?" → 동작(로직)에 관한 잘못된 질문
"Start버튼이 활성화될 수 있는 상태는 무엇인가?" → 상태에 관한 질문

Button { 
    text: "Start"
    enabled: !vm.isRunning
    onClicked: vm.start()
}

이 코드에는 시간계산 로직도 없고, 상태변경 로직도 없다.

핵심: View는 상태를 표현하고 사용자의 입력을 ViewModel로 전달한다.

Main.qml

import QtQuick
import QtQuick.Controls
import QtQuick.Layouts
import antigravityTest

Window {
    width: 400; height: 500
    visible: true
    title: "Stopwatch"

    StopwatchViewModel { id: vm }

    ColumnLayout {
        anchors.fill: parent
        anchors.margins: 20
        spacing: 12

        Text {
            Layout.alignment: Qt.AlignHCenter
            text: vm.elapsedText
            font.pixelSize: 48
            font.family: "Courier New"
        }

        RowLayout {
            Layout.alignment: Qt.AlignHCenter
            spacing: 10

            Button { text: "Start"; onClicked: vm.start(); enabled: !vm.isRunning }
            Button { text: "Stop";  onClicked: vm.stop();  enabled: vm.isRunning }
            Button { text: "Lap";   onClicked: vm.lap();   enabled: vm.isRunning }
            Button { text: "Reset"; onClicked: vm.reset() }
        }

	// 사용자가 Lap을 통해 기록한 상태를 어떻게 보여줄까? → List로 보여주자
        ListView {
            Layout.fillWidth: true
            Layout.fillHeight: true
            model: vm.laps
            delegate: Text {
                text: "Lap " + modelData.index + "  " + modelData.elapsed
                font.family: "Courier New"
            }
        }
    }
}

ViewModel

ViewModel은 Model과 View를 연결하는 계층이다.

사용자가 UI로 호출하는 행동은 SLOT으로 정의하고,

Q_PROPERTY와 시그널을 바인딩했다.

QML과 Model을 연결하다 보면 다음과 같이 부족한 점들을 발견하게 된다.

Model의 Laps() 행동은 std::vector 형태를 반환하는데 QML의 labs상태는 QVariantList 형태를 취급한다.
Model은 시간을 "계산"할 수 있지만 QML이 그 변화를 감지할 수 있는 "신호"는 제공하지 않는다.

이러한 문제를 생각하다 보면 ViewModel의 역할이 뚜렷해지고,

깊게는 최적화와 관련된 내용으로 이어지기도 한다.

핵심: View와 Model 사이에서 View에 맞게 데이터를 가공한다.

StopwatchViewModel.h

#pragma once
#include <QObject>
#include <QTimer>
#include <QVariantList>
#include "StopwatchModel.h"

class StopwatchViewModel : public QObject
{
    Q_OBJECT
    Q_PROPERTY(bool isRunning   READ isRunning   NOTIFY isRunningChanged)
    Q_PROPERTY(int  elapsedMs   READ elapsedMs   NOTIFY elapsedChanged)
    Q_PROPERTY(QString elapsedText READ elapsedText NOTIFY elapsedChanged)
    Q_PROPERTY(QVariantList laps READ laps NOTIFY lapsChanged)

public:
    explicit StopwatchViewModel(QObject *parent = nullptr);

    bool        isRunning()   const { return m_model.isRunning(); }
    int         elapsedMs()   const { return static_cast<int>(m_model.elapsed().count()); }
    QString     elapsedText() const { return formatMs(m_model.elapsed().count()); }
    QVariantList laps()       const;

public slots:
    void start();
    void stop();
    void reset();
    void lap();

signals:
    void isRunningChanged();
    void elapsedChanged();
    void lapsChanged();

private:
    StopwatchModel m_model;
    QTimer         m_timer;
    QString formatMs(qint64 ms) const;
};

StopwatchViewModel.cpp

#include "StopwatchViewModel.h"

StopwatchViewModel::StopwatchViewModel(QObject *parent)
    : QObject(parent)
{
    // ~60fps update for smooth display
    m_timer.setInterval(16);
    connect(&m_timer, &QTimer::timeout, this, &StopwatchViewModel::elapsedChanged);
}

void StopwatchViewModel::start()
{
    if (m_model.isRunning()) return;
    m_model.start();
    m_timer.start();
    emit isRunningChanged();
    emit elapsedChanged();
}

void StopwatchViewModel::stop()
{
    if (!m_model.isRunning()) return;
    m_model.stop();
    m_timer.stop();
    emit isRunningChanged();
    emit elapsedChanged();
}

void StopwatchViewModel::reset()
{
    m_timer.stop();
    m_model.reset();
    emit isRunningChanged();
    emit elapsedChanged();
    emit lapsChanged();
}

void StopwatchViewModel::lap()
{
    if (!m_model.isRunning()) return;
    m_model.lap();
    emit lapsChanged();
}

QVariantList StopwatchViewModel::laps() const
{
    QVariantList result;
    const auto &laps = m_model.laps();
    for (const auto &lap : laps) {
        QVariantMap m;
        m["index"]   = lap.index;
        m["elapsed"] = formatMs(lap.elapsed.count());
        result.prepend(m); // most recent lap first
    }
    return result;
}

QString StopwatchViewModel::formatMs(qint64 ms) const
{
    int minutes = static_cast<int>(ms / 60000);
    int seconds = static_cast<int>((ms % 60000) / 1000);
    int centis  = static_cast<int>((ms % 1000) / 10);
    return QString("%1:%2.%3")
        .arg(minutes, 2, 10, QChar('0'))
        .arg(seconds, 2, 10, QChar('0'))
        .arg(centis,  2, 10, QChar('0'));
}

회고

실행된 QML Stopwatch 프로그램

프로그램은 단순하지만 설계는 단순하지 않았다.

처음에는 "QML 프로젝트 따라 하기"로 글을 쓰려했다.

하지만 더 명확하게 설명하기 위해 MVVM 구조를 적용했다.

그 과정에서 QML의 동작방식과 객체지향적 사고력을 키울 수 있었다.

요즘엔 AI딸깍으로 프로젝트가 생성되기 때문에 SW 아키텍처가 더욱 중요시되고,

작은 프로젝트라도 직접 만들어보며 깊이 생각해 보는 시간이 필요한 것 같다.

부족한 부분이나 더 궁금한 주제가 있다면 댓글로 남겨주세요.
직접 공부해서 다음 글로 정리해 보려고 합니다.

이전 글 : 2026.02.10 - [Qt] - Qt6 QML 따라하기 ㅡ 프로젝트 생성부터 C++ 연동까지

Qt6 QML 따라하기 ㅡ 프로젝트 생성부터 C++ 연동까지

들어가며이전 글에서 QML의 이론적 배경을 정리했다.런타임 리플렉션을 활용한 pub/sub 구조와,프레임 기반 렌더링을 통한 최적화 개념을 살펴보며QML이 QWidget보다 충분히 경쟁력 있는 기술이라는

prejudice.tistory.com

이전 글 : 2026.02.02 - [Qt] - Qt QML 내부 동작 원리 이해하기 ㅡ Property Binding, Event Loop, Scene Graph

Qt QML 내부 동작 원리 이해하기 ㅡ Property Binding, Event Loop, Scene Graph

들어가며QtFramework에 대해 공부하며 QEventLoop, QObjec, moc(Meta Object Compiler)에 대해 공부했다.이 글은 지금까지의 내용을 배경지식을 활용하여 QML에 대해 공부해 보려 한다.2026.01.23 - [Qt] - Qt Event Loop

prejudice.tistory.com

	Task 실행 1회 차	Task 실행 2회 차	Task 실행 3회 차
범용 OS	1.0ms	1.7ms	2.3ms
RTOS 또는 PREEMPT_RT	1.0ms	1.01ms	1.03ms