Prejudice

How to Use the Pirate King Hat - Crimson Desert Tips

편견장 — Sun, 7 Jun 2026 10:06:35 +0900

약 250시간 동안 플레이하며 엔딩을 보고 가장 유용하게 장비 아이템인 모자 해적왕 모자

혹여나 모자의 보물탐지 기능에 대해 모르는 사람들이 있을까 팁을 남긴다.

*게임에 대한 스포는 없음

장비 : 해적왕 모자 - 보물찾기

붉은 사막의 장비에는 다양한 기능을 하는 모자가 있고 그중 장착 시 보물 탐지 스킬을 가진 모자가 존재한다.

해적왕 모자 - 장착 시 보물 탐지

이 옵션은 액티브 스킬이 아니라, 실제 모자를 착용해서 확인해야 하는 UI 스킬이다.

보물탐지를 하기 위해서는 해적왕 모자를 꼭 착용하고 모험을 다녀야 효과가 있다.

선행조건: 투구 외형 표현 옵션

붉은사막 모자들은 특히나 멋이 없거나 스토리몰입에 방해가 되는 경우가 많기 때문에

게임 출시후 붉은 사막 패치 1.02.00 패치 때 아주 빠른 속도로 투구 외형 표현 옵션이 추가되었다.

하지만 보물 탐지 스킬을 사용하기 위해선 투구가 보이는 상태여야 하기 때문에,

기타-플레이-투구 외형 표현 옵션을 비활성화 해야 한다.

투구 외형 표현 옵션

"장착 시 보물 탐지" 스킬이란

모자의 외형에 두 가닥의 깃털을 확인할 수 있는데, 평소에는 누런빛의 일반 색을 띄지만,

보물상자가 근처에 있을 때는 밝게 빛나는 방식으로 유저에게 알린다.

해적왕 모자의 보물 탐지 스킬

해적왕 모자의 보물 탐지 스킬 GIF

보물 상자 조건/위치

보물상자는 특수한 아이템이 들어있는 일반 상자가 아닌 아래 사진과 같은 보물 상자(찾은 후 지도에 표시되는 상자)만 해당된다.

모자가 빛나면 근처에 보물상자가 있다는 것으로, 주위 20~30걸음 이내에서 보물상자를 찾을 수 있다.

붉은 사막 특성상 비밀공간 속에 있거나 집중 지정타(모아치기)가 필요한 경우가 있다.

보물상자

붉은사막 TIP: 2026.03.23 - [게임] - 붉은사막 컨트롤러 키조합 세팅 - 8BitDo 조작감 개선

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

부정적인 리뷰가 많아 남들에게 말하기 부끄럽지만,이번에 새로나온 펄어비스의 붉은사막(Crimson Desert)을 나름 즐기고 있다. 진짜 불쾌한 경험인 붉은사막의 조작감은 리뷰에서도 말이 많은데...

prejudice.tistory.com

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

Windows Jenkins 설치 - 사내 CI/CD 서버 구축 따라하기

편견장 — Fri, 5 Jun 2026 17:59:45 +0900

들어가며

임베디드를 다루는 중소기업이라면

CI/CD의 필요성은 느끼지만, 인력부족 · 레거시 시스템 유지 등등 각종 핑계로 구축을 하염없이 연기하고 있을 수 있다.

역시나 현재 다니고 있는 회사에서도

사용자 배포를 위한 최종 인스톨러를 만들고자 할 때는 따로 Linux 가상머신을 이용해 Installer를 제작하거나,

컴파일할 수 있는 담당자에게 요청하여 업무를 처리했다.

여기서 오는 위험은, 내가 부분적으로 개발한 시스템이 전체 시스템에 어떤 버그를 야기하는지 테스트해 볼 수 없다는 데 있다.

혹여나 Installer를 자주 배포하거나, 담당자가 퇴사라도 한다면 야근을 해야할지도 모른다.

사내 CI/CD를 구축해 배포용 프로그램 컴파일 자동화를 달성하기 위해서

이번 글에서는 누구나 따라할 수 있게 Windows에 Jenkins를 설치하는 방법을 정리해 보려 한다.

Windows Jenkins 설치 방법

개발자라면 Mac또는 Linux OS, Docker를 좋아할 텐데, 임베디드 개발자라면 마우스 딸깍이 있는 윈도우에서 한다!

Jenkins Installer For Windows 다운로드

우선 Jenkins Server는 거의 모든 플랫폼을 지원하고 있어 설치가 매우 쉽다.

CI/CD 서버로 사용하고자 하는 Windows PC에 설치하고 다음 과정을 진행하자.

https://www.jenkins.io/download/thank-you-downloading-windows-installer/

Thank you for downloading Windows installer

Jenkins – an open source automation server which enables developers around the world to reliably build, test, and deploy their software

www.jenkins.io

Management Web Server Port 설정

Installer를 실행하면 다음과같이 웹서버로 사용할 Port를 설정창으로 시작한다.

Jenkins의 장점은 자동화서버를 웹형식으로 접근하여 사용할 수 있는데,

예를 들어 8080 포트를 사용한다면 http://127.0.0.1:8080 주소로 접속해 자동화 Pipeline을 관리할 수 있다.

Jenkins의 관리용 웹 서버 포트 설정

Java (JDK or JRE) Home Directory 설정

다음 창으로 넘어가면 Java Home Directory 설정창을 볼 수 있다.

Jenkins는 내부적으로 Java(21 ver ~ 25 ver)를 사용하기 때문에, 서버가 되는 PC에 JAVA가 설치되어 있어야 한다.

Java Home directory 설정

JAVA를 설치할때는 너무 최신버전인 경우 지원하지 않아서,

다음 링크에서 지원하는 버전과 OS를 맞춰 설치하면 된다.

https://www.oracle.com/kr/java/technologies/downloads/#java25

JAVA SDK 25.0.3(64-bit) 설치

JAVA 설치 이후, Jenkins Installer 로 돌아와 홈 디렉터리 경로를 설정하면 된다.

JAVA를 기본 경로로 설치했다면 C:\Program Files\JAVA 폴더 안에 jdk-[xx.yy.zz] 형식으로 폴더가 있을 텐데

bin 폴더나 lib 폴더가 아닌 해당 폴더 jdk-[xx.yy.zz]를 선택하면 된다.

JAVA Home Directory 설정

방화벽 설정

아무래도 WebServer다 보니 방화벽(8080 포트)을 열어주는 옵션이 있다.
Firewall Exception 을 체크하면 기본적으로 Windows 방화벽의 인바운드 규칙(Inbound Rules)에 8080 포트로 접근하는 규칙을 추가해 외부에서 접근할 수 있도록 설정한다.

(*뒤에서 따로 방화벽 포트를 설정하는 방법이 있기에 그냥 Next를 눌러 넘어간다.)

설치시 방화벽 설정

Jenkins 설정 방법

Jenkins Web Server 설정

설치를 완료했다면 로컬 PC에서 인터넷 브라우저를 통해 웹서버에 접속할 수 있다.

http://localhost:8080 주소로 접속하면 다음과 같이 최초 비밀번호를 입력하는 창이 나온다.

초기 비밀번호 입력 창

최초 비밀번호는 위에 나온 경로인 C:\ProgramData\Jenkins\.jenkins\secrets\initialAdminPasswork 파일에 있고

ProgramData폴더는 숨김폴더로 설정돼 있어서 숨김 항목을 표시해야 확인할 수 있다.

C:\ProgramData 숨김 항목 표시

초기 비밀번호 등록 후 Jenkins가 정상적으로 켜지는 걸 볼 수 있다.

Jenkins 설정 완료

방화벽 설정

만약 Jenkins 설치 시 FireWall Exception을 체크하지 않았다면 다른 외부 PC에서 https://[ip]:8080으로 접속이 아예 안될 텐데, 방화벽에서 8080 포트를 막고 있기 때문일 수 있다.

방화벽 설정은 Windows 키를 누르고 고급 보안이 포함된 Windows Defender 방화벽에서 추가할 수 있다.

Windows 방화벽 설정

외부에서 8080 포트로 Jenkins Server로 들어올 수 있도록 허용하기 위해,

인바운드 규칙을 새 규칙-포트 로 8080 포트를 추가해 접속을 허용한다.

방화벽 인바운드 8080포트 규칙 추가

마치며

이로써 CI/CD 자동화를 위한 Jenkins(젠킨스) 서버 구축이 끝났다.

나는 사내에 24시간 구동되는 서버 PC가 있어 거기에 구축하지만, Local PC에서 컴파일할 때만 사용해도 되고, 시스템별로 서버를 여러 개 두어도 좋을 듯하다.

우선 Jenkins로 파이프라인을 만들어두면 추후 병렬컴파일이나 AI와 연동한 작업이 훨씬 쉬워지기 때문에

조금씩이라도 자동화를 구축해 나가며 시스템을 확장시켜 나가는 게 효과적일 것 같다.

앞으로 해야 할 작업은 Jenkins를 이용한 컴파일 자동화인데

형상관리도구(SVN) Update→ Windows Installer 컴파일 →Linux Installer 컴파일→AArch64 컴파일
파이프라인을 만들고,

SVN이 Checkout 될 때마다 자동으로 실행하도록 하면 쓸만한 기능이 나올 듯하다.

지난 글: 2026.01.21 - [개발] - CI 입문 ㅡ Jenkins로 C++ 빌드·유닛 테스트 자동화 따라하기

CI 입문 ㅡ Jenkins로 C++ 빌드·유닛 테스트 자동화 따라하기

들어가며최근 빌드 환경 구성이 잦아지면서 적지 않은 스트레스를 겪고 있다. 현재 진행 중인 프로젝트는 VirtualBox로 각자 빌드 환경을 구성하고,PowerShell 스크립트를 이용해 Windows, Linux, Embedded Li

prejudice.tistory.com

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

비개발자도 쓰는 AI Agent 만들기 - Copilot CLI와 바이브 코딩

편견장 — Mon, 25 May 2026 21:33:30 +0900

들어가며

지난 글에서 말했듯, 회사에서 사용하는 AI 도구를 GitHub Copilot으로 전환했고

요 몇 달간 VS Code Agent Extension, GitHub Copilot CLI, Code review 등등 다양한 도구들을 사용해보고 있다.

마침, 내년 결혼준비를 앞두고 신혼집과 결혼식에 대해 부쩍 관심을 가지기 시작했는데

비개발자인 애인도 함께 사용할 수 있는 맞춤형 AI Agent를 만들어보면 좋을 것 같아서 글을 작성해 본다.

프로젝트는 개발 지식이 있는 사람이라면 따라 할 수 있을 정도로, AI에게 개발을 요청하는 바이브 코딩 중심으로 진행했다.

최종 서비스는 비개발자도 사용할 수 있을 정도로 쉽게 만드는 것을 목표로 만들어 보자.

글에 들어가기 앞서, 프로젝트를 시작하게된 계기인 Agent-Worker패턴과 Multi-Agent패턴에 대해 알고있으면 좋다.

AGENT 개념 정리 : 2026.05.11 - [개발] - AI Agent 개념정리 - LLM · Worker-Agent 패턴 · Multi-Agent 패턴

AI Agent 개념정리 - LLM · Worker-Agent 패턴 · Multi-Agent 패턴

들어가며회사에서 사용하는 AI를 GPT에서 Github Copilot으로 변경하고 약 한 달이 지났다.VsCode, Cursor, Antigravity에 이르기 까지 AI IDE가 빠르게 발전하면서 AI Agent의 설정과 사용이 매우 쉬워졌다. 오늘

prejudice.tistory.com

서비스 구상

아이디어 컨셉

애인과 나는 둘 다 전세경험도 없고, 세대주 분리도 안되고 부모님 집에 함께 사는 중으로

결혼과 부동산에 대한 지식이 정말 백지상태라고 말할 수 있다.

며칠간 웨딩 관련 용어들을 검색해 보고 알아보며 1년 동안 준비하며 돌파해 나가는 장기간 프로젝트라는 것을 알았고,

OneNote나 Notion을 이용한 기록 보다, 우리만의 결혼정보에 최적화된 Agent가 있으면 좋을 것 같았다.

맞춤정보 (토요일 or 일요일 · 하객 인원수 · 지역 · 우선순위 등)를 데이터로 사용.
일정과 예산을 정리하고 파일로 저장할 수 있음.
모르는 용어나 과정을 검색할 수 있음.

프롬프트를 계속 업데이트해가며 사용해도 되고, 내가 만들려는 서비스의 최종 결과가 Cloud Agent와 비슷한 것 같다.
하지만 이미 GitHub Copilot 계정을 사용 중이고 여자친구도 쉽게 쓸 수 있도록 직접 만들어 보기로 했다.

Prototype Service Architecture 구성

아키텍처를 구상하면서 가장 고민한 부분은 파일 입출력이었다.

예를 들어 한번 선택해 기록한 파일이 있다면, 다음 질문에선 그 정보를 바탕으로 응답하는 맞춤형 AI를 원했다.

따라서 Copilot CLI를 설치하고 웹 서버와 연결하는 방식을 떠올렸다.

프로젝트의 역할은 크게 두 가지로 각각의 Agent를 두어 관리해 보려 한다.

Wedding Planner Agent: 결혼 준비에 관련된 정보, 일정관리, 준비목록, 체크리스트를 관리하는 역할.
APT Manager Agent: 신혼집에 관련된 청약 공고 분석, 일정관리, 자산 및 대출비용 계산 업무를 담당하는 역할.

Wedding Elder 아키텍처

너무 간단해서 아키텍처라 불러도 되나 부끄럽지만, 바이브코딩으로 개발을 진행하며 수정을 해나가려 했다.

서비스 개발

Workspace 생성

프로젝트명이 마땅히 떠오르지 않아 WeddingElder 워크스페이스를 만들었다.

나는 IDE로 VS Code를 주로 사용하기 때문에 VS Code로 워크스페이스를 열어준다.

AI 바이브 코딩을 위해 GitHub Copilot Chat Extension 을 설치하면 개발 준비가 끝난다.

Github Copilot Extension

AI Agent 생성

VS Code에서는 AI 대화창을 이용해 쉽게 Agent 프롬프트를 만들 수 있다.

/create-agent 명령으로 대략적인 프롬프트를 생성하고, 추후에 나의 상황에 맞게 프롬프트를 수정하면 된다.

나는 간단하게 "wedding-planner"라는 이름과 역할정도만 주고 생성했다.

Copilot Extension Agent생성

WeddingElder\.github\agents\ 경로에 wedding-planner.agent.md 파일이 생성된 것을 확인할 수 있다.

이 폴더구조는 VS Code의 GitHub Copilot의 전용 규칙으로 특정 Agent를 호출할 때 해당 프롬프트를 사용한다.

추후 부동산을 관리하는 APT Manager Agent를 추가할 예정이기 때문에

모든 Agent들이 공통으로 사용하는 AGENTS.md 파일을 추가했다.

*AGENTS.md 파일 또한 Copilot이 인식하는 파일로, root폴더(WeddingElder) 또는 .github 폴더 등 어디에 두든 상관없다.

 WeddingElder
 ┣   AGENTS.md # Workspace 총괄 가이드
 ┗  .github
    ┗  agents
       ┗  wedding-planner.agent.md # 결혼식 관리 Agent

WeddingElder\AGENTS.md

# 웨딩플래너 워크스페이스 가이드

## 목적
- 이 워크스페이스는 내년 10월 중반 토요일 예식을 목표로 한 결혼 준비를 위한 공간이다.
- 일반적인 소프트웨어 구현보다 일정표, 체크리스트, 예산안, 업체 비교표, 진행 메모, 의사결정 기록 같은 준비 산출물을 우선해서 돕는다.

## 작업 방식
- 추천은 실용적이고, 시점이 분명하며, 바로 실행 항목으로 옮길 수 있게 정리한다.
- 세부 정보가 비어 있으면 목표 예식 시점을 기준으로 잡고, 어떤 가정을 두었는지 명확히 적는다.
- 결과물은 메모, 스프레드시트, 작업 관리 도구에 옮기기 쉬운 구조로 제시한다.

## 선호 출력 형식
- 큰 준비 업무는 월 단위로 나누고, 필요하면 주간 다음 행동까지 이어서 정리한다.
- 업체나 선택지를 비교할 때는 비용, 가능 일정, 적합도, 리스크, 추가 확인 질문 같은 동일한 기준을 사용한다.
- 지역, 예산, 하객 수, 가족 선호에 따라 달라지는 항목은 분명하게 표시한다.

## 문서 언어
- 이 워크스페이스에서 작성하거나 수정하는 Markdown 문서는 기본적으로 한글로 작성한다.
- 외부 서비스명, 브랜드명, 계약 용어처럼 원문 유지가 필요한 표현만 예외로 둔다.

## 에이전트 사용
- 결혼 준비 일정, 예산 정리, 업체 비교 기준, 준비 체크리스트 작성은 전용 웨딩플래너 agent를 우선 사용한다.

## 파일 생성
- 파일을 생성하거나 관리할때는 /files 폴더를 사용한다.
- 엑셀을 만들때나 일회용으로 쓰는 임시파일 같은 경우는 /temp 폴더를 사용한다.

WeddingElder\.github\agents\wedding-planner.agent.md

---
name: 웨딩쀼
description: "결혼 준비를 계획하거나, 일정표를 만들거나, 예산을 정리하거나, 웨딩홀 및 업체를 비교하거나, 체크리스트를 구성하거나, 27년 10월 중반 토요일 예식을 목표로 준비할 때 사용한다."
tools: [read, edit, search, execute, todo, web]
user-invocable: true
---
이 워크스페이스 전용 웨딩 준비 전문 agent다.

역할은 사용자가 27년 10월 중반 토요일 예식을 목표로 결혼을 준비할 수 있도록, 현실적인 계획과 바로 실행 가능한 정리를 제공하는 것이다.

## 핵심 역할
- 현실적인 결혼 준비 타임라인을 만들고 유지한다.
- 막연한 목표를 구체적인 다음 행동으로 바꾼다.
- 예산, 예식장, 협력업체, 하객 수, 복장, 식순, 행정 준비를 구조적으로 정리한다.
- 선택지 비교 시 기준과 트레이드오프를 명확하게 드러낸다.

## 기본 가정
- 정확한 날짜가 아직 확정되지 않았다면, 27년 10월 중반 토요일을 목표 날짜로 가정한다.
- 지역, 예산, 하객 수는 사용자가 지정하기 전까지 미정 변수로 둔다.
- 워크스페이스 문맥이 한국어이므로, 사용자가 따로 말하지 않으면 한국 기준의 결혼 준비 관행을 우선 반영한다.

## 제약
- 실시간 가격, 실시간 예약 가능 여부, 법률 자문을 알고 있는 것처럼 답하지 않는다.
- 확정되지 않은 예약, 계약, 마감일을 사실처럼 만들지 않는다.
- 사용자가 결정이나 계획을 원할 때 막연한 아이디어 나열로 끝내지 않는다.

## 진행 방식
1. 무엇을 결정해야 하는지, 얼마나 급한지, 어떤 조건이 비어 있는지 먼저 파악한다.
2. 답변에 큰 영향을 주는 가정이 있으면 먼저 밝힌다.
3. 사용자가 파일, 표, 템플릿, 비교표, 체크리스트를 원하면 워크스페이스에서 직접 만들거나 수정한다.
4. 필요하면 마지막에 가장 작은 다음 행동이나 확인 질문을 덧붙인다.

## 출력 선호
- 일정표는 월별 또는 의사결정 단계별로 묶는다.
- 예산안은 항목, 예상 범위, 비용 리스크 메모를 함께 적는다.
- 비교 요청은 기준, 장점, 단점, 추가 확인 질문이 있는 표 형태를 우선한다.
- 체크리스트는 필수 항목과 선택 업그레이드를 구분한다.
- Markdown으로 답할 때는 기본적으로 한글로 작성한다.

## 기본 계획 영역
- 예식장과 날짜 선택
- 예산 배분과 우선순위 조정
- 스튜디오, 드레스, 메이크업, 촬영 준비
- 하객 명단과 청첩장 시점 조율
- 예식 및 피로연 진행 순서
- 신혼여행 일정 의존성 정리
- 행정 및 계약 관련 준비

## 성공 기준
모든 답변은 사용자의 불확실성을 줄이거나, 우선순위를 분명히 하거나, 27년 10월 중반 예식을 향한 구체적인 다음 단계 하나 이상을 제공해야 한다.

도구가 허용된 경우에는 필요한 검색, 파일 편집, 문서 생성, 표 정리, 셸 실행을 직접 수행해 결과물을 남긴다.

Copilot-CLI 설치와 WebServer 구현

PC에 원격으로 접근해서 VS Code의 Copilot 대화창을 이용해 AI를 사용해도 된다.

하지만 사용자가 쉽게 접근할 수 있도록 WebServer로 대화창을 제공해 보려 한다.

먼저 VS Code IDE 없이도 AI를 호출할 수 있도록 Copilot CLI 를 설치했다.

Copilot CLI는 GitHub 홈페이지에서 설치할 수 있으며, 정상적으로 설치 후 CMD 창에서 Copilot 명령으로 실행할 수 있다.

winget을 통한 GitHub Copilot CLI 설치

Windows CMD 에서 실행한 Copilot CLI

이제 VS Code IDE로 돌아가서 이 명령을 수행할 수 있도록 연결하는 웹서버를 만들어 보자.

다음과 같이 명령 후, 몇 가지 체크를 하고 권한을 주면 뚝딱뚝딱 만들기 시작한다.

▶ webserver폴더에 python으로 웹 서버 프로그램을 만들자.
웹 서버의 주요 기능은 다음과 같아.
 - 사용자가 웹 페이지에 접속해서 Local PC의 Command창과 연결 후 Copilot CLI를 사용.
 - 사용자가 웹 페이지를 통해 파일들을 다운받거나 삭제할 수 있도록 제공.
 - Copilot CLI는 현재 폴더를 기준으로 워크스페이스를 제공.
 - Copilot CLI는 파일생성/수정을 할 수 있고 임시폴더로 temp폴더를, 생성된 파일은 files폴더를 사용해 관리.
> Asking a question ...

몇가지 질문을 통해 WebServer 만드는 Copilot

AI에게 webserver 폴더에 만들라고 지정했기 때문에 폴더가 지저분해지는 것을 피하고, 나름 깔끔하게 구조를 유지할 수 있었다.

 WeddingElder
 ┣   AGENTS.md # Workspace 총괄 가이드
 ┣  .github
 ┃  ┗  agents
 ┃    ┗  wedding-planner.agent.md # 결혼식 관리 Agent
 ┣  webserver # python으로 개발된 웹 서버
 ┃  ┗  [webserver Files]
 ┣  temp # 임시 생성될 파일 경로
 ┗  files # 파일저장 경로

나의 경우 PC에 Python을 설치해 두지 않았다.
때문에 AI가 파이썬 가상환경인 venv를 설치했고, Workspace에도 따로 적진 않았지만 .venv폴더를 만들어졌다.

webserver 폴더에 들어가 python으로 웹서버 프로그램을 실행하고, 인터넷으로 접속해 Copilot CLI에 접근할 수 있었다.
(.venv) PS C:\..\WeddingElder\webserver> python.exe .\app.py

Web으로 접속한 Copilot-CLI

Agent Tool 설치 - Excel 파일 만들기

Agent의 강력한 기능은 명령 수행 시 사용할 수 있는 도구를 함께 전송해서 명령을 수행할 수 있다는 점이다.

Workspace에서 Copilot에게 엑셀파일을 만들 수 있도록 도구를 설치하라고 명령했다.

Python가상환경에 Excel파일을 만드는 라이브러리인 openpyxl을 설치했고,
wedding-planner.agent.md 파일에 tools를 추가했다.

그다음, Copilot에게 엑셀 파일로 정리해 달라고 하면 다음과 같은 과정을 통해 파일을 생성한다.

웹소켓으로 서버로 전송→Coiplot CLI(AGENTS.md)
→Excel 생성용 python코드 작성→python실행(.xlsx)

▶ 신도림 웨딩홀들을 찾고 예약일이 보통 언제쯤 열리는지 엑셀파일로 정리해
> 엑셀 파일 생성 완료!

Agent의 Excel파일 생성

계획대로라면 임시파일은 \temp폴더를 사용하고 최종 결과 파일은 \files 폴더를 사용해야 하지만,

어째서인지 AGENT가 WeddingElder\temp 폴더에 만든 것을 확인할 수 있다.

*하지만 Excel 파일 생성은 확인할 수 있었다.

생성된 .xlsx 파일

해당 문제는 파일을 관리하는 Agent를 따로 만들어서 복사를 하거나, AGENTS.md파일을 수정하여 해결할 수 있을 것 같다.

회고

코드를 한 줄도 보지 않고 개발을 한건 처음이었는데,

Agent를 커스터마이징하고 도구를 연결하는 모든 과정을 자연어로 개발하는 과정 자체에서 재미를 느낄 수 있었다.

그에반해 결과물 측면에서는 Copilot CLI의 작업 속도가 느렸고,

웹세션을 이용한 UI 부분도 기대했던 것에 비해 밤티나서 아쉬움이 남는다.

사실상 이번 프로토타입 프로젝트에서는 Copilot CLI를 오케스트레이터처럼 사용했다.

또한 LLM Model을 코드를 잘 작성하는 Calude Sonnet 4.6으로 사용했는데, Model선정에 있어서도 성능차이가 클 것이다.

추후 구조개선과 UI개선을 통해 프로젝트 완성도를 높일 수 있었으면 좋겠다.

서비스 완성도를 높이기 위해 시도해 볼 만한 것들

Orchestrator-Worker 구조로 작업 분리
파일관리 Agent 추가 : 폴더구조 관리
APT Manager Agent 추가 : 신혼집(부동산) 관련 Agent
MD 파일 수정 기능: Agent를 웹에서 커스터마이징 가능하도록 UI 제공
보안 : 인증/접근제어
온라인 개시 : 도메인 연결 (TOOL: ngrok, pyngrok)

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

프로젝트 코드 공개 (GitHub)

https://github.com/BlueBird-0/WeddingElder

GitHub - BlueBird-0/WeddingElder: AI Agent Project for management of wedding.

AI Agent Project for management of wedding. Contribute to BlueBird-0/WeddingElder development by creating an account on GitHub.

github.com

AI Agent 개념정리 - LLM · Worker-Agent 패턴 · Multi-Agent 패턴

편견장 — Mon, 11 May 2026 23:55:03 +0900

들어가며

회사에서 사용하는 AI를 GPT에서 Github Copilot으로 변경하고 약 한 달이 지났다.

VsCode, Cursor, Antigravity에 이르기 까지 AI IDE가 빠르게 발전하면서 AI Agent의 설정과 사용이 매우 쉬워졌다.

오늘은 AI Agent가 Local PC에서 행동할 수 있는 원리와, Multi-Agent의 장단점에 대해 정리해보려 한다.

LLM과 Agent의 차이점

LLM (Large Language Model)

LLM(Large Language Model)이란 텍스트를 입력받아 텍스트를 반환하는 모델이다.

사람들이 작성한 방대한 글을 학습해, 입력받은 텍스트 다음에 나올 내용을 추론하는 생성형 AI이다.

대표적인 LLM으로는 GPT-4o(OpenAI), Gemini(Google),Claude(Anthropic) 등이 있으며,
각각 학습된 데이터를 바탕으로 추론하기 때문에 사람에 비유하면 "뇌"에 비유할 수 있다.

단점으로는 사실이 아닌 내용을 사실인 듯 생성하는 환각(Hallucination) 현상과,

LLM을 만들기 위해 사용하는 방대한 데이터 처리를 위해서 거대자본이 투입되어야 한다는 한계를 가진다.

여기서 짚고 넘어갈 점은, LLM은 텍스트를 반환하는 모델일 뿐 직접적인 행동을 할 수 없다는 점이다.

[사용자] "로그인 함수 짜줘"
↓
[LLM] 코드 텍스트 생성
↓
[사용자] (직접 복사해서 편집기에 붙여 넣기)

AI Agent

AI Agent는 LLM에 실행 능력을 더한 것이다.

만약 CMD창을 조작하거나 내 PC의 조작이 가능한 LLM(=Agent)에게 요청한다고 상상해 보자.

아래와 같이 일련의 과정을 직접 수행할 수 있다.

[사용자] "로그인 함수 짜줘"
↓
[Agent] 코드 생성 → 파일 저장 → 빌드 → 결과 확인
↓
[사용자] 결과 확인

Agent가 행동하는 원리 - Tool Calling / Context Injection

Tool Calling

LLM은 텍스트만 다룰 수 있기 때문에, Agent가 파일을 만들거나 터미널 명령을 실행하려면 LLM 혼자서는 불가능하다.

이 문제를 해결하는 것이 Tool Calling(도구 호출)이다.

Agent가 도구들을 사용하기 위해서는 도구목록과 사용방법들을 미리 알고 있어야 하는데,

이전에 작성한 MCP(Model Context Protocol) 글에서 다룬 적 있다.

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

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

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

prejudice.tistory.com

Agent의 Tool Calling 핵심은 LLM이 도구에 맞는 명령을 생성하면, Agent 런타임이 실행하는 구조라 할 수 있다.

그림1. Agent↔LLM 구조

Context Injection

그림1 에서 Agent가 LLM을 호출할 때 현재 환경 정보를 프롬프트에 함께 담아 전달하는 것을 Context Injection이라고 한다.
예를 들어 PC에 설치된 컴파일러, 프로젝트 환경설정, 사용 가능한 도구들, 수행계획 등등 다양한 정보를 함께 전달하면

LLM은 이 정보를 보고 판단하여 환경에 맞는 명령을 생성한다.

Monolithic 프로젝트나 관련 리소스가 많은 경우, 모든 정보를 담아 LLM에 요청하는 일이 발생할 수 있다.
이는 응답이 너무 길어져 처리 중 중단되거나 토큰 사용량이 많이 발생하는 원인이 된다.

AI 우회 전략 - Worker Agent 패턴

최근에 회사에서 사용하는 AI를 Github Copilot으로 바꿨는데, Github Copilot Business 계정을 사용한다면 다음 제약이 있다.

VSCode Extention이나 Copilot CLI는 연결된 GitHub 계정으로 로그인하여 사용할 수 있지만,

사내 API Key는 보안이슈로 직접 만든 프로그램에서 Copilot을 호출하는 것은 정책상 불가능하다.

VSCode Extension	✅	지원
Copilot CLI	✅	지원
Github API Token (직접 호출)	❌	Business 계정 정책으로 불가능

이 제약을 우회할 수 있는 방법이 Worker Agent 패턴이다.

그림1 에서 Agent가 실행하기 위한 핵심은 LLM에게 환경을 전달하는 것을 알 수 있었다.

이때 Context Injection을 대신 수행하는 중간 Agent를 두면 직접 API 호출 없이 우회가 가능하다.

내 프로그램이 Copilot에게 직접 요청하는 대신, CLI를 대신 실행해 주는 중간 프로세스(Worker Agent)를 통하는 방식이다.

Worker Agent Pattern

Worker Agent가 단순히 CLI 한 번 호출하고 끝이라면 User가 직접 Copilot CLI를 실행해도 동일하다.
Worker Agent가 진가를 발휘하는 것은 Tool 실행 루프가 필요한 경우,
즉 LLM이 "파일 읽기→분석→빌드→테스트→파일 수정"처럼 여러 번 왔다 갔다 해야 할 때 이다.

Multi Agent - Orchestrator 패턴

Single Agent의 한계

하나의 Agent에 설계, 구현, 테스트, 리뷰를 전부 하도록 구성하면 다음과 같은 문제가 발생한다.

컨텍스트 과부하: 토큰 수가 너무 길어져 앞의 내용을 잊거나 생성 품질이 떨어진다.
역할 혼재: 서로 특성이 맞지 않는 작업을 동시에 진행하면 역효과가 난다. (ex. 소설 쓰기/정보검색을 동시에 진행하는 Agent)
재사용 불가: 특정 프로젝트에 오버피팅된 Agent는 다른 곳에 쓰기 어렵다.

Multi Agent의 장점

따라서 Agent를 역할별로 분리하고, 전체 흐름을 관리하는 Orchestrator Agent를 두는 Multi-Agent 방식이 등장했다.

전문화: 각각의 Agent가 자신의 역할에 집중, 품질상승.
컨텍스트 절약: 역할에 필요한 정보만 가지므로 토큰 낭비를 줄일 수 있음.
재사용성: Project의존성을 제거할 수 있어 재사용이 가능함.
병렬처리: 독립된 Agent끼리 동시에 작업 가능.
유지보수: 문제 발생 시 어느 Agent에서 발생했는지 특정하기 쉬움.

Multi-Agent 구조 (Orchestrator Pattern)

회고

최근 들어 항시 느끼는 것은 AI발전은 너무 빠르고 성능평가가 이루어지지 않은 채 AI를 사용하면서, 공포감을 느낀다.

생산성을 위해 AI를 필수로 사용해야 하지만,

코드를 빠르게 만들어주는 주면서 지식이 단기기억으로 들어가는 것 같다.

그나마 이번에 시간을 내 Agent에 대한 개념과 동작원리를 정리할 수 있었고, 다음번엔 Worker Agent를 직접 만들어
Github Copilot과 연동해 실행하는 프로그램을 만들어 봐야겠다.

PS. LLM에 대해 학습하며 VLM(Vision Language Model), VLA(Vision-Language-Action) 모델이라는 것을 알았다.

LLM처럼 빅데이터를 이용해 Model 생성시점부터 Vision영상분석과 Action추론이 가능하도록 만든 생성형 모델이다.

구분	LLM	VLM	VLA (피지컬 AI)
입력	텍스트	텍스트 + 이미지	텍스트 + 이미지 + 센서
출력	텍스트	텍스트	텍스트 + 행동 명령
현실 세계 상호작용	불가능	관찰만 가능	직접 조작 가능
학습 데이터	인터넷 텍스트	텍스트 + 이미지	현장 센서 + 로봇 동작

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

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

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

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

prejudice.tistory.com

ROS2를 처음 분석하며 정리한 핵심 개념 - DDS, QoS, ROS Architecture

편견장 — Wed, 29 Apr 2026 00:14:26 +0900

들어가며

최근 몇 년 간 AMR·다관절로봇이 떠오르며 ROS 경력 구인공고나, RTOS나 Micro-ROS에 포팅 수요가 많아진 걸 체감 중이다.

그만큼 임베디드 시스템에도 AI와 함께 모듈형 설계가 중요해지고 복잡성이 증가했기 때문일 것이다.

이번 글에서는 초보 개발자의 관점에서 ROS2의 강점과 특징에 대해 알아보자.

*ROS 기본 개념은 인터넷에 잘 나와있으니 다음 717lumos 님의 게시글로 대체한다..

[ROS] ROS 기본 개념

로봇 소프트웨어 플랫폼, ROS 소개, ROS 주요 개념 및 컨셉, 파일 시스템

velog.io

Embedded 개발자의 시선에서 본 ROS 주요 개념

Multi-Platform

ROS2(Robot Operating System)는 DDS 기반 미들웨어 위에 구축된 로봇 소프트웨어 프레임워크이다.

다양한 OS에서 동작할 수 있고, 계층별/언어별로 라이브러리를 제공하여 개발이 수월하다.

DDS Pub/Sub Message구조

DDS(Data Distribution Service)는 데이터를 주고받는 미들웨어 표준으로 ROS2는 DDS를 통신 미들웨어로 사용한다.

ROS2 노드 간 데이터는 Message 형태로 전송되는데, DDS Layer를 통해 Pub/Sub 구조로 통신한다.
이때 DDS추상 레이어(rmw)를 두어 벤더 독립성(Vendor Independence)을 유지하고, 시스템 복잡성을 낮춘다.

DDS의 QoS (Quality of Service)

ROS2를 AMR · 다관절 로봇에 적용하기 좋은 이유는 DDS에서 QoS를 제공하기 때문이다.

예를 들어 DDS 메시지를 구독한다고 할 때, 다음과 같은 QoS정책을 설정할 수 있다.

Deadline: 메시지가 일정 주기(ex. 10㎳) 내에 도착해야 함
Reliability: 누락된 메시지를 무시하고 진행 or 재전송 해

물론 실시간성(Deadline안에 센서 처리를 끝내고 publish까지의 과정)은 내부 칩이나 RTOS를 통해 따로 확보해야 하지만,

QoS정책 설정으로 아키텍처가 단순해지고 모듈별로 책임을 세분화할 수 있다.

ROS2 Architecture

ROS1 vs ROS2 차이점

가장 큰 차이는 위에서 언급한 통신 방식의 차이이다.

ROS1은 TCP/UDP 프로토콜을 사용했고 따라서 QoS 측면에서 한계가 있었다.

ROS2는 DDS를 사용해 QoS 설정 및 신뢰성을 확보함과 동시에 Pub/Sub 구조로 기존의 ROS Master노드가 불필요해졌다.

호환성

ROS1과 ROS2는 통신 방식이 달라 상호 호환되지 않는다. (ROS1 ≠ ROS2)

또한 ROS2 내부에서도 버전 간 완전한 호환성이 보장되지 않기 때문에 동일한 버전을 쓰는 것이 안전하다.

환경 의존성이 큰 ROS를 배포할 때는, Docker/Container를 활용해 배포하거나 패키지 매니저를 통해 배포하는 경우가 많다.

특히 DDS 구현방식과 QoS 설정에 따라 동작이 달라질 수 있다.

	패키지 명 (출시일)
ROS 2 (권장 버전)	Jazzy Jalisco (2024.05 - LTS)
	Iron Irwini (2023.05)
	Humble Hawksbill (2022.05 - LTS)
	Galactic Geochelone (2021.05)
	Foxy Fitzroy (2020.06 - LTS)
ROS 1 (Legacy)	Noetic Ninjemys (2020.05 - 마지막 ROS1)
ROS 1 (Legacy)	Melodic Morenia (2018.05)

*ROS2의 릴리즈는 연 1회 발표하며, LTS는 발표된 이후 5년간 지원한다.
*ROS 인터페이스 배포를 위해서는 ROS 배포판, QoS, 토픽 타입, 빌드 환경 등을 맞춰야 한다.

회고

ROS2를 살펴보며, 복잡한 센서 및 로봇 시스템에 적용할 경우 아키텍처를 단순화하고 개발 시간을 크게 단축할 수 있는 프레임워크라는 점을 확인할 수 있었다.

DDS 기반의 강력한 통신 구조를 바탕으로 모듈화와 확장성을 자연스럽게 확보할 수 있다는 점 역시 인상적이다.

다만, 실제로 유저 레벨까지 서비스를 제공하는 관점에서는 배포 방식이나 버전 관리, 실행 환경 구성 등에서 추가적으로 고려해야 할 요소들이 많고 운영 측면의 고민이 함께 필요한 분명한 장단점을 가지는 기술이라 느꼈다.

최근 PLC 프로젝트가 고도화되며 조직이 Robot Control Solution 팀으로 개편된 만큼,

향후 AMR이나 Motion 기능 개발을 진행하게 된다면 ROS를 이용해 작업하며 실무에 관한 글을 이어갈 수 있을 것 같다.

글을 작성하며 SW개발자의 관점에서 가장 궁금한 점은,

단순한 아키텍처 구조 속에서 DDS기반 데이터 통신이 실제 환경에서 어느 정도의 성능과 안정성이 나올지 궁금하다.

앞으로 이를 직접 검증해 보는 과정이 재밌는 과제가 될 것 같다.

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

Linux실시간성에 관한 글: 2026.04.06 - [개발] - Linux PREEMPT_RT 실시간성(Jitter) 측정 및 성능 비교 - RTOS

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

들어가며최근 SW PLC에서 관심 갖고 개발 중인 내용은 Linux PREEMPT_RT 커널을 이용해 실시간성을 보장하는 작업이다. SW PLC Runtime은 특정 Task를 매 주기마다 실행해야 한다.따라서 OS에서 프로세스의

prejudice.tistory.com

ROS공식 Documents: https://docs.ros.org/en/rolling/

ROS 2 Documentation — ROS 2 Documentation: Rolling documentation

docs.ros.org

C++ Preemptive Task Scheduler 구현 및 성능 비교 (Windows · Linux · Linux PREEMPT_RT)

편견장 — Sat, 18 Apr 2026 00:26:29 +0900

들어가며

최근 며칠 동안 진행 중인 SW PLC 프로젝트의 핵심 로직인 멀티 태스킹(Multi-Tasking) 기능을 구현하는 데 집중하고 있다.

이번 작업의 세부 목표는 총 3가지이며, 최종적으로는 사용자의 다중 Task를 선점 스케줄링(Preemptive Scheduling) 방식으로 수행하는 클래스를 개발하려 한다.

Multi-Platform 지원: 'Windows', 'Linux', 'Linux PREEMPT_RT Kernel' 환경에서 모두 정상 동작할 것.
실시간성(Real-Time) 확보: 선점 스케줄링 방식으로 Task를 관리하되, 스레드 전환 및 스케줄링 작업이 무겁지 않아야 함.
Task세분화: Task의 종류를 CycleTask(정 주기 실행)와 EventTask(이벤트 트리거 실행) 두 가지로 구성할 것.

개발에 들어가기 앞서 3개의 태스크가 선점형으로 동작하는 최종 모습을 타이밍 차트로 그려 정리했다.

그림1. 선점 스케줄러의 3개 Task 동작 예시

Multi Task / Preemptive Task Scheduler 설계

우선 시스템의 가장 단순한 UML을 구상하고, 각 클래스별로 책임과 역할을 선정했다.

TaskManager : 다중 태스크(사용자 태스크)의 리스트와 전체 생명주기를 관리
TaskThread : OS에 맞춰 Thread 등록 / 실제 Task Logic을 실행
TaskScheduler : Preemptive Task Queue 관리 / TaskThread들을 우선순위에 따라 유예 · 실행 · 재개

선점형 스케줄링 기능을 직접 제어하기 위해, 크로스 플랫폼 개발 중임에도 QThread를 사용하지 않고 OS Thread를 사용했다.

OS Thread의 경우 스래드 실행 중에 suspend()호출로 현재 스택 포인터(SP)를 저장하고 resume()을 통해 재개할 수 있다.

이는 그림1 처럼 Task 중간에 멈추고 다른 Task를 실행하기에 적합하다.

Component Diagram

실제 로직 구현을 위한 Class Diagram을 다음과 같이 그릴 수 있다.
TaskThread::createForPlatform() 은 Factory 패턴을 사용해 OS에 맞춰 각각 독립적인 Thread 인스턴스를 생성한다.

Class Diagram

TaskThread 인스턴스의 정 주기 신호, 혹은 외부 trigger() 신호가 발생하면 TaskScheduler::scheduleTask(task) 를 호출하여 스케줄러에게 스케줄링을 요청한다.

요청을 받은 스케줄러는 동기화 락 구조 안에서 Task의 우선순위에 따라 여러 태스크를 제어(Suspend · Resume · Execute)한다.

scheduleTask() 가 발생했을 때의 로직흐름은 다음과 같다.

Task Scheduleing Flowchart

Multi Task / Preemptive Task Scheduler 구현

구조와 역할을 잘 분리해 둔 덕분에 실제 구현은 어렵지 않았지만, 애를 먹은 부분은 테스트였다.

Windows, Linux(일반 커널), Linux(PREEMPT_RT 커널) 등 3가지 환경에서 실행하고 검증해야 했으며,

특히 Scheduling 전환 작업이 밀리초(㎳) 단위로 빠르게 실행되기 때문에 I/O를 사용하는 Log 출력으로 인해 느려지는 버그나,

OS 타이머 분해능, 객체 동적 할당 지연 등을 고려해야 했다.

 TaskTest
┃  TaskTest.pro  # Qt Project
┃  main.cpp
┃  TaskManager.cpp
┃  TaskManager.h
┃  TaskScheduler.cpp
┃  TaskScheduler.h
┗  TaskThread
  ┣  TaskThread.cpp
  ┣  TaskThread.h
  ┣  TaskThreadLinux.cpp
  ┣  TaskThreadLinux.h
  ┣  TaskThreadWin.cpp
  ┗  TaskThreadWin.h

TaskTest.zip

0.01MB

QT = core
CONFIG += console
CONFIG -= app_bundle

# POSIX 스레드/실시간 라이브러리 (Linux 전용)
unix:LIBS += -lpthread -lrt

# Windows 멀티미디어 타이머 라이브러리
win32:LIBS += -lwinmm

# 정적 링크: libstdc++와 libgcc를 실행 파일에 포함
unix:QMAKE_LFLAGS += -static-libstdc++ -static-libgcc

# RPATH 설정: Qt 라이브러리용
unix:QMAKE_LFLAGS += -Wl,-rpath,\'\$$ORIGIN/lib\'

TARGET = TaskTest
TEMPLATE = app

DESTDIR     = $$PWD/build
OBJECTS_DIR = $$PWD/build
MOC_DIR     = $$PWD/build

INCLUDEPATH += $$PWD/TaskThread

SOURCES += \
    main.cpp \
    TaskThread/TaskThread.cpp \
    TaskScheduler.cpp \
    TaskManager.cpp

unix:SOURCES  += TaskThread/TaskThreadLinux.cpp
win32:SOURCES += TaskThread/TaskThreadWin.cpp

HEADERS += \
    TaskThread/TaskThread.h \
    TaskScheduler.h \
    TaskManager.h

unix:HEADERS  += TaskThread/TaskThreadLinux.h
win32:HEADERS += TaskThread/TaskThreadWin.h

#include <QCoreApplication>
#include <QTimer>
#ifdef __linux__
#include <sys/mman.h>
#endif
#ifdef _WIN32
#include <windows.h>
#include <mmsystem.h>
#endif
#include <iostream>
#include "TaskManager.h"

#ifdef __linux__
// Stack prefaulting - prevent page faults
static void prefaultStack()
{
    unsigned char dummy[8 * 1024];  // 8KB stack
    memset(dummy, 0, sizeof(dummy));
}
#endif

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

#ifdef __linux__
    // RT memory locking and stack prefaulting (need root)
    if (mlockall(MCL_CURRENT | MCL_FUTURE) == 0) {
        std::cout << "[RT] Memory locked (no page faults)" << std::endl;
    } else {
        std::cout << "[RT] Failed to lock memory (need root)" << std::endl;
    }

    prefaultStack();
#endif

    TaskManager manager;
    manager.start();

    QTimer::singleShot(5000, &app, SLOT(quit())); // Quit after 5 seconds

    return app.exec();
}

#include "TaskManager.h"
#include "TaskThread.h"

#include <iostream>

TaskScheduler *g_scheduler = nullptr;

TaskManager::TaskManager()
{
    g_scheduler = new TaskScheduler();
    
    TaskThread *primaryTask = TaskThread::createForPlatform("PrimaryTask", 0, 300, 1000, g_scheduler);
    TaskThread *taskB       = TaskThread::createForPlatform("TaskB",       1, 1300, 2500, g_scheduler);
    // TaskThread *taskC       = TaskThread::createForPlatform("TaskC",       2, 1500, 0, g_scheduler); // 0 = 외부 트리거

    m_tasks.push_back(primaryTask);
    m_tasks.push_back(taskB);
    // m_tasks.push_back(taskC);
}

TaskManager::~TaskManager()
{
    for (TaskThread *task : m_tasks)
        delete task;
    
    delete g_scheduler;
    g_scheduler = nullptr;
}

void TaskManager::start()
{
    std::cout << "=== TaskManager started ===" << std::endl;
    std::cout << "  PrimaryTask : 1000ms period  priority=0  work=300ms" << std::endl;
    std::cout << "  TaskB       : 2500ms period  priority=1  work=1300ms" << std::endl;
    std::cout << std::endl;

    g_scheduler->resetBaseTime();

    for (TaskThread *task : m_tasks)
        task->start();
}

void TaskManager::stop()
{
    for (TaskThread *task : m_tasks)
        task->stop();
}

#ifndef TASKMANAGER_H
#define TASKMANAGER_H

#include <vector>
#include "TaskScheduler.h"

extern TaskScheduler *g_scheduler;

class TaskThread;

class TaskManager
{
public:
    explicit TaskManager();
    ~TaskManager();

    void start();
    void stop();

private:
    std::vector<TaskThread*>   m_tasks;
};

#endif // TASKMANAGER_H

#include "TaskScheduler.h"

#include <iostream>
#include <cstdio>
#include <cstring>
#include <time.h>

TaskScheduler::TaskScheduler()
{
    // Start asynchronous logger thread
    m_logRunning.store(true);
    m_logThread = std::thread([this]() { loggerLoop(); });
}

TaskScheduler::~TaskScheduler()
{
    // Signal logger thread to stop and join
    {
        std::lock_guard<std::mutex> lock(m_logMutex);
        m_logRunning.store(false);
    }
    m_logCv.notify_one();
    if (m_logThread.joinable())
        m_logThread.join();
}

void TaskScheduler::resetBaseTime()
{
    clock_gettime(CLOCK_MONOTONIC, &m_baseTime);
}

long long TaskScheduler::getElapsedUs() const
{
    timespec now;
    clock_gettime(CLOCK_MONOTONIC, &now);
    return (now.tv_sec - m_baseTime.tv_sec) * 1000000 +
           (now.tv_nsec - m_baseTime.tv_nsec) / 1000;
}

void TaskScheduler::log(const char *msg) const
{
    LogEntry entry;
    entry.ts = getElapsedUs();
    strncpy(entry.msg, msg, sizeof(entry.msg) - 1);
    entry.msg[sizeof(entry.msg) - 1] = '\0';

    {
        std::lock_guard<std::mutex> lock(m_logMutex);
        m_logQueue.push(entry);
    }
    m_logCv.notify_one();
}

void TaskScheduler::loggerLoop()
{
    while (true) {
        std::unique_lock<std::mutex> lock(m_logMutex);
        m_logCv.wait(lock, [this]() {
            return !m_logQueue.empty() || !m_logRunning.load();
        });

        std::queue<LogEntry> batch;
        std::swap(batch, m_logQueue);
        lock.unlock();

        while (!batch.empty()) {
            const LogEntry &e = batch.front();
            printf("[t=%8lld.%03lldms] %s\n", e.ts / 1000, e.ts % 1000, e.msg);
            batch.pop();
        }
        fflush(stdout);

        if (!m_logRunning.load() && m_logQueue.empty())
            break;
    }
}

void TaskScheduler::insertByPriority(TaskThread *task)
{
    for (size_t i = 0; i < m_pendingQueue.size(); ++i) {
        if (task->priority() < m_pendingQueue[i]->priority()) {
            m_pendingQueue.insert(m_pendingQueue.begin() + i, task);
            return;
        }
    }
    m_pendingQueue.push_back(task);
}

void TaskScheduler::scheduleTask(TaskThread *task)
{
    std::lock_guard<std::mutex> lock(m_mutex);
    insertByPriority(task);

    char buf[256];
    snprintf(buf, sizeof(buf), "[Scheduler] triggered: %s  pending=%zu  running=%s",
             task->name().toUtf8().constData(),
             m_pendingQueue.size(),
             m_currentTask ? m_currentTask->name().toUtf8().constData() : "-");
    log(buf);

    if (m_currentTask != nullptr && task->priority() < m_currentTask->priority()) {
        snprintf(buf, sizeof(buf), "[Scheduler] PREEMPT: suspend %s -> run %s",
                 m_currentTask->name().toUtf8().constData(),
                 task->name().toUtf8().constData());
        log(buf);

        TaskThread *preempted = m_currentTask;
        m_currentTask   = nullptr;

        preempted->suspend();
        insertByPriority(preempted);
    }
    
    tryRunNext();
}

void TaskScheduler::notifyFinished(const char *name, long long elapsedMs)
{
    std::lock_guard<std::mutex> lock(m_mutex);
    
    char buf[256];
    snprintf(buf, sizeof(buf), "[Scheduler] finished : %s  wall=%lldms  pending=%zu", name, elapsedMs, m_pendingQueue.size());
    log(buf);

    m_currentTask = nullptr;
    
    if (!m_pendingQueue.empty())
        tryRunNext();
}

// ── Attempt to run the next task (called within mutex) ─────────────────────────────
void TaskScheduler::tryRunNext()
{
    if (m_pendingQueue.empty() || m_currentTask != nullptr)
        return;

    m_currentTask = m_pendingQueue.front();
    m_pendingQueue.erase(m_pendingQueue.begin());

    char buf[256];
    if (m_currentTask->isSuspended()) {
        snprintf(buf, sizeof(buf), "[Scheduler] resume  : %s  (priority=%d)",
                 m_currentTask->name().toUtf8().constData(),
                 m_currentTask->priority());
        log(buf);
        m_currentTask->resume();
    } else {
        snprintf(buf, sizeof(buf), "[Scheduler] execute : %s  (priority=%d)",
                 m_currentTask->name().toUtf8().constData(),
                 m_currentTask->priority());
        log(buf);
        m_currentTask->execute();
    }
}

#ifndef TASKSCHEDULER_H
#define TASKSCHEDULER_H

#include "TaskThread.h"
#include <vector>
#include <queue>
#include <mutex>
#include <condition_variable>
#include <thread>
#include <atomic>
#include <time.h>

class TaskScheduler
{
public:
    explicit TaskScheduler();
    ~TaskScheduler();

    void scheduleTask(TaskThread *task);
    void notifyFinished(const char *name, long long elapsedMs);

    timespec getBaseTime() const { return m_baseTime; }
    void resetBaseTime();
    long long getElapsedUs() const;

private:
    void insertByPriority(TaskThread *task);
    void tryRunNext();
    void log(const char *msg) const;
    void loggerLoop();

    // ── Scheduler state (protected by m_mutex) ───────────────────────────────────
    std::mutex            m_mutex;
    TaskThread           *m_currentTask{nullptr};
    std::vector<TaskThread*>    m_pendingQueue;
    timespec              m_baseTime;

    // ── Asynchronous logger ──────────────────────────────────────────────────────
    struct LogEntry { long long ts; char msg[256]; };
    mutable std::mutex              m_logMutex;
    mutable std::condition_variable m_logCv;
    mutable std::queue<LogEntry>    m_logQueue;
    std::thread                     m_logThread;
    std::atomic<bool>               m_logRunning{false};
};

#endif // TASKSCHEDULER_H

#include "TaskThread.h"
#include "TaskScheduler.h"

#ifdef Q_OS_WIN
#  include "TaskThreadWin.h"
#else
#  include "TaskThreadLinux.h"
#endif

TaskThread::TaskThread(const QString &name,
                       int priority,
                       int workMs,
                       int intervalMs,
                       TaskScheduler *scheduler)
    : m_name(name)
    , m_priority(priority)
    , m_workMs(workMs)
    , m_intervalMs(intervalMs)
    , m_scheduler(scheduler)
{
}

TaskThread::~TaskThread()
{
}

void TaskThread::trigger()
{
    if (m_scheduler) {
        m_scheduler->scheduleTask(this);
    }
}

TaskThread* TaskThread::createForPlatform(const QString &name,
                               int priority,
                               int workMs,
                               int intervalMs,
                               TaskScheduler *scheduler)
{
#ifdef Q_OS_WIN
    return new TaskThreadWin(name, priority, workMs, intervalMs, scheduler);
#else
    return new TaskThreadLinux(name, priority, workMs, intervalMs, scheduler);
#endif
}

#ifndef TASKTHREAD_H
#define TASKTHREAD_H

#include <QString>
#include <atomic>

class TaskScheduler;

class TaskThread
{
    friend class TaskScheduler;

public:
    explicit TaskThread(const QString &name,
                       int priority,
                       int workMs,
                       int intervalMs,
                       TaskScheduler *scheduler);
    virtual ~TaskThread();

    static TaskThread* createForPlatform(const QString &name,
                             int priority,
                             int workMs,
                             int intervalMs,
                             TaskScheduler *scheduler);

    QString name()     const { return m_name; }
    int     priority() const { return m_priority; }

    virtual void start() = 0;
    virtual void stop()  = 0;

    void trigger();

    bool isSuspended() const { return m_suspended.load(); }

protected:
    //  ── Scheduler-only methods (do not call from outside) ──
    virtual void suspend() = 0;
    virtual void resume()  = 0;
    virtual void execute() = 0;

protected:
    QString                m_name;
    int                    m_priority;
    int                    m_workMs; // Work time delay between tests
    int                    m_intervalMs;  // Interval (ms), 0 means external trigger only
    TaskScheduler         *m_scheduler;
    std::atomic<bool>      m_suspended{false};
};

#endif // TASKTHREAD_H

#include "TaskThreadLinux.h"
#include "TaskScheduler.h"

#include <QElapsedTimer>
#include <signal.h>
#include <time.h>
#include <sched.h>
#include <mutex>
#include <iostream>
#include <pthread.h>
#include <algorithm>

static 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;
}

// ── Thread-local sem pointers (signal handler에서 접근) ──
static thread_local sem_t *tl_suspendSem   = nullptr;
static thread_local sem_t *tl_suspendedSem = nullptr;

// ── SIGRTMIN+8 handler ──────────
static void preemptHandler(int)
{
    if (!tl_suspendSem || !tl_suspendedSem)
        return;

    sem_post(tl_suspendedSem);
    sem_wait(tl_suspendSem);
}

static void installPreemptHandler()
{
    struct sigaction sa{};
    sa.sa_handler = preemptHandler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGRTMIN + 8, &sa, nullptr);
}

// ── TaskThreadLinux ────────────────────────────────────────────────────────

TaskThreadLinux::TaskThreadLinux(const QString &name,
                                 int priority,
                                 int workMs,
                                 int intervalMs,
                                 TaskScheduler *scheduler)
    : TaskThread(name, priority, workMs, intervalMs, scheduler)
{
    sem_init(&m_executeSem, 0, 0);
    sem_init(&m_suspendSem, 0, 0);
    sem_init(&m_suspendedSem, 0, 0);

    static std::once_flag once;
    std::call_once(once, installPreemptHandler);
}

TaskThreadLinux::~TaskThreadLinux()
{
    stop();
    sem_destroy(&m_executeSem);
    sem_destroy(&m_suspendSem);
    sem_destroy(&m_suspendedSem);
}

void TaskThreadLinux::start()
{
    m_running.store(true);
    pthread_create(&m_thread, nullptr, [](void *arg) -> void * {
        static_cast<TaskThreadLinux *>(arg)->threadLoop();
        return nullptr;
    }, this);
}

void TaskThreadLinux::stop()
{
    if (!m_running.load())
        return;
    m_running.store(false);
    sem_post(&m_executeSem);
    pthread_join(m_thread, nullptr);
    m_thread = 0;
}

void TaskThreadLinux::threadLoop()
{
    tl_suspendSem   = &m_suspendSem;
    tl_suspendedSem = &m_suspendedSem;

    setRtPriority();
    long long tick = 1;
    timespec startTime = m_scheduler->getBaseTime();
    
    while (m_running.load()) {
        if (m_intervalMs > 0) {
            const timespec nextTs = addMs(startTime, tick * m_intervalMs);
            int ret = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &nextTs, nullptr);
            if (ret != 0 && ret != EINTR) {
                break;
            }
            
            if (!m_running.load())
                break;
            
            m_scheduler->scheduleTask(this);
            ++tick;
        }
        
        sem_wait(&m_executeSem);
        if (!m_running.load())
            break;

        // ── Execute task ─────────────────────────────────────────────
        m_isExecuting.store(true);

        // Reset accumulated time and start timer
        m_accumulatedMs = 0;
        m_wallTimer.start();

        volatile double acc = 0.0;
        for (long long i = 1; ; ++i) {
            acc += 1.0 / static_cast<double>(i);
            if (i % 10000 == 0) {  // Appropriate check interval
                long long totalWorkTime = m_accumulatedMs + m_wallTimer.elapsed();
                if (totalWorkTime >= m_workMs)
                    break;
            }
        }
        (void)acc;

        // ── Notify task completion ────────────────────────────────────────
        long long finalWorkTime = m_accumulatedMs + m_wallTimer.elapsed();
        m_isExecuting.store(false);
        m_scheduler->notifyFinished(m_name.toUtf8().constData(), finalWorkTime);        
    }
}

void TaskThreadLinux::setRtPriority()
{
    int rt_priority = std::max(1, std::min(80, 80 - m_priority));
    struct sched_param param;
    param.sched_priority = rt_priority;
    
    if (pthread_setschedparam(pthread_self(), SCHED_FIFO, &param) == 0) {
        std::cout << "[" << m_name.toStdString() << "] RT priority: " << rt_priority << std::endl;
    }
}

void TaskThreadLinux::execute()
{
    sem_post(&m_executeSem);
}

void TaskThreadLinux::suspend()
{
    m_suspended.store(true);

    while (!m_isExecuting.load())
        sched_yield();

    m_accumulatedMs += m_wallTimer.elapsed();

    pthread_kill(m_thread, SIGRTMIN + 8);  // pthread(8) is Suspend signal

    sem_wait(&m_suspendedSem);
}

void TaskThreadLinux::resume()
{
    m_suspended.store(false);
    m_wallTimer.restart();
    sem_post(&m_suspendSem);
}

#ifndef TASKTHREADLINUX_H
#define TASKTHREADLINUX_H

#include "TaskThread.h"
#include <QElapsedTimer>
#include <pthread.h>
#include <semaphore.h>
#include <atomic>

class TaskThreadLinux : public TaskThread
{
public:
    explicit TaskThreadLinux(const QString &name,
                            int priority,
                            int workMs,
                            int intervalMs,
                            TaskScheduler *scheduler);
    ~TaskThreadLinux();

    void start()   override;
    void stop()    override;
    void suspend() override;
    void resume()  override;
    void execute() override;

private:
    void threadLoop();
    void setRtPriority();

    pthread_t              m_thread{0};
    std::atomic<bool>      m_running{false};
    std::atomic<bool>      m_isExecuting{false};
    sem_t                  m_executeSem;
    sem_t                  m_suspendSem;
    sem_t                  m_suspendedSem;
    
    QElapsedTimer          m_wallTimer;
    long long              m_accumulatedMs{0};
};

#endif // TASKTHREADLINUX_H

#include "TaskThreadWin.h"
#include "TaskScheduler.h"

#include <QElapsedTimer>
#include <QDebug>

TaskThreadWin::TaskThreadWin(const QString &name,
                             int priority,
                             int workMs,
                             int intervalMs,
                             TaskScheduler *scheduler)
    : TaskThread(name, priority, workMs, intervalMs, scheduler)
{
    m_executeSem   = CreateEvent(nullptr, FALSE, FALSE, nullptr);
    m_suspendSem   = CreateEvent(nullptr, FALSE, FALSE, nullptr);
    m_suspendedSem = CreateEvent(nullptr, FALSE, FALSE, nullptr);
}

TaskThreadWin::~TaskThreadWin()
{
    stop();
    if (m_executeSem)   CloseHandle(m_executeSem);
    if (m_suspendSem)   CloseHandle(m_suspendSem);
    if (m_suspendedSem) CloseHandle(m_suspendedSem);
}

void TaskThreadWin::start()
{
    m_running.store(true);
    m_thread = CreateThread(nullptr, 0, threadProc, this, 0, nullptr);
}

void TaskThreadWin::stop()
{
    if (!m_running.load())
        return;
    m_running.store(false);
    SetEvent(m_executeSem);
    if (m_thread) {
        ResumeThread(m_thread);
        WaitForSingleObject(m_thread, INFINITE);
        CloseHandle(m_thread);
        m_thread = nullptr;
    }
}

DWORD WINAPI TaskThreadWin::threadProc(LPVOID arg)
{
    static_cast<TaskThreadWin *>(arg)->threadLoop();
    return 0;
}

void TaskThreadWin::threadLoop()
{
    setCpuPriority();
    long long tick = 1;
    QElapsedTimer startTimer;
    startTimer.start();
    
    while (m_running.load()) {
        if (m_intervalMs > 0) {
            long long nextTriggerMs = tick * m_intervalMs;
            long long sleepMs = nextTriggerMs - startTimer.elapsed();
            
            if (sleepMs > 0) {
                Sleep(sleepMs);
            }
            
            if (!m_running.load())
                break;
            
            m_scheduler->scheduleTask(this);
            ++tick;
        }

        WaitForSingleObject(m_executeSem, INFINITE);
        if (!m_running.load())
            break;

        // ── Execute task ──────────────────────────────────────────────────
        m_isExecuting.store(true);
        
        // Reset accumulated time and start timer
        m_accumulatedMs = 0;
        m_wallTimer.start();

        volatile double acc = 0.0;
        for (long long i = 1; ; ++i) {
            acc += 1.0 / static_cast<double>(i);
            if (i % 10000 == 0) { // Appropriate check interval
                long long totalWorkTime = m_accumulatedMs + m_wallTimer.elapsed();
                if (totalWorkTime >= m_workMs)
                    break;
            }
        }
        (void)acc;

        // ── Notify task completion ────────────────────────────────────────
        long long finalWorkTime = m_accumulatedMs + m_wallTimer.elapsed();
        m_isExecuting.store(false);
        m_scheduler->notifyFinished(m_name.toUtf8().constData(), finalWorkTime);
    }
}

void TaskThreadWin::setCpuPriority()
{
    if (m_thread) {
        SetThreadPriority(m_thread, THREAD_PRIORITY_TIME_CRITICAL);
    }
}

void TaskThreadWin::execute()
{
    SetEvent(m_executeSem);
}

void TaskThreadWin::suspend()
{
    m_suspended.store(true);

    while (!m_isExecuting.load())
        Sleep(0);

    m_accumulatedMs += m_wallTimer.elapsed();

    SuspendThread(m_thread); // Suspend the thread at OS level
    
    SetEvent(m_suspendedSem);
}

void TaskThreadWin::resume()
{
    m_suspended.store(false);
    m_wallTimer.restart();
    ResumeThread(m_thread);
}

#ifndef TASKTHREADWIN_H
#define TASKTHREADWIN_H

#include "TaskThread.h"
#include <QElapsedTimer>
#include <windows.h>
#include <atomic>

class TaskThreadWin : public TaskThread
{
public:
    explicit TaskThreadWin(const QString &name,
                          int priority,
                          int workMs,
                          int intervalMs,
                          TaskScheduler *scheduler);
    ~TaskThreadWin();

    void start()   override;
    void stop()    override;
    void suspend() override;
    void resume()  override;
    void execute() override;

private:
    void threadLoop();
    void setCpuPriority();
    static DWORD WINAPI threadProc(LPVOID arg);

    HANDLE                 m_thread{nullptr};
    std::atomic<bool>      m_running{false};
    std::atomic<bool>      m_isExecuting{false};
    HANDLE                 m_executeSem{nullptr};
    HANDLE                 m_suspendSem{nullptr};
    HANDLE                 m_suspendedSem{nullptr};
    
    QElapsedTimer          m_wallTimer;
    long long              m_accumulatedMs{0};
};

#endif // TASKTHREADWIN_H

Preemptive Task Scheduler 테스트 결과

구현 코드에서 보면 알 수 있듯, 스케줄러가 잘 동작하는지 테스트하기 위해 가상의 TestCase를 만들었다.

TestCase 설계

각각의 OS에서 TaskTest 프로그램을 실행하며 실제 스케줄링이 잘 되는지 확인하고 마이크로초(㎲) 단위로 시간을 확인했다.

개발을 진행하면서 Thread를 제어하는 OS 트리거 최적화가 안되거나, 로깅지연이 발생해 만들어 비동기 스레드로 전환하는 등의 문제가 있었지만, 최종적으로 테스트 결과는 예상했던 것보다 좋았다.

*참고로 Linux PREEMPT_RT의 극단적인 CPU 스트레스 테스트는 지난 PoC에서 검증했으므로,
이번 선점 스케줄러 로직 테스트는 CPU 부하가 없는 기본 유휴 상태에서 수행했다.

이전 글: 2026.04.06 - [개발] - Linux PREEMPT_RT 실시간성(Jitter) 측정 및 성능 비교 - RTOS

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

prejudice.tistory.com

Trigger Latency

설정된 매 1000㎳ 주기마다 OS에서 Task가 Trigger 되기까지 걸리는 시간을 측정.

Ideal Time	Windows	WSL Linux(non-Preempt)	Linux(PREEMPT_RT)
1000 ㎳	1000.349 ㎳ (+0.349 ㎳ )	1000.101 ㎳ (+0.101 ㎳ )	1000.196 ㎳ (+0.196 ㎳ )
2000 ㎳	2000.779 ㎳ (+0.779 ㎳ )	2000.100 ㎳ (+0.100 ㎳ )	2000.198 ㎳ (+0.198 ㎳ )
3000 ㎳	3001.640 ㎳ (+1.640 ㎳ )	3000.105 ㎳ (+0.105 ㎳ )	3000.062 ㎳ (+0.062 ㎳ )
4000 ㎳	4001.218 ㎳ (+1.218 ㎳ )	4000.127 ㎳ (+0.127 ㎳ )	4000.091 ㎳ (+0.091 ㎳ )
5000 ㎳	5001.253 ㎳ (+1.253 ㎳)	5000.110 ㎳ (+0.110 ㎳ )	5000.162 ㎳ (+0.162 ㎳ )

Windows: 최대 1.640 ㎳의 Jitter가 발생했다.
예상범위 안쪽이었지만 Linux에 비해 주기 신뢰성이 낮고 프로세스 CPU Affinity 최적화 등을 고려해 볼 수 있을 것 같다.
WSL의 Linux (non-Preempt): 약 100㎲ 내외로 훨씬 안정적인 Latency를 보여주었다.
Linux (PREEMPT_RT): 안정적인 성능을 보여줬다. 우선 Windows와 Linux와 다르게 Embedded BoxPC에서 돌린 것을 감안하더라도, 지난 PoC에서 CPU가 저전력 상태에서 600㎲ 까지는 떨어지는 것을 확인했기 때문에, 상당히 좋은 수치였다.

지난 글에서 Linux(PREEMPT_RT) 기반 PoC를 진행하며 평균 Latency 약 11㎲라는 매우 우수한 결과를 확인했다.
해당 테스트는 CPU에 지속적인 부하를 가해 클럭이 유지된 상태에서 수행되었으며, 이 경우 안정적인 실시간 성능을 확보할 수 있었다.

반면, CPU 부하가 없는 환경에서는 Idle State로 진입하면서 절전 모드(C-state)가 활성화되었고, 이로 인해 wake-up latency 가 증가하여 최악의 경우 약 600㎲까지 지연이 발생하는 것을 확인했다.

이는 PREEMPT_RT 환경에서도 CPU의 전력 관리 정책에 따라 실시간 성능이 크게 영향을 받을 수 있음을 보여준다.

Preemption Latency Comparison (선점 응답성 비교)

더 높은 우선순위의 Task가 오거나, Task가 종료된 후 다음 Task가 실행되기까지의 시간을 측정.

TaskB가 실행중일 때 Primary Task가 실행되는 경우: triggered(P) → suspend(B) → execute(P)까지의 시간을 측정
Primary Task 종료 후 유예 중인 TaskB가 실행되는 경우: finisshed(P) → resume(B)까지의 시간을 측정

Scheduling	Windows	WSL Linux(non-Preempt)	Linux(PREEMPT_RT)
3000 ㎳ ( TaskB → PrimaryTask )	0.024 ㎳	0.181 ㎳	0.028 ㎳
3300 ㎳ ( PrimaryTask → TaskB )	0.008 ㎳	0.043 ㎳	0.005 ㎳
4000 ㎳ ( TaskB → PrimaryTask )	0.016 ㎳	0.115 ㎳	0.026 ㎳
4300 ㎳ ( PrimaryTask → TaskB )	0.007 ㎳	0.046 ㎳	0.003 ㎳

Task 전환(Preemption)의 경우 모든 플랫폼에서 뛰어난 응답성을 보여줬다.

특이하게도 Windows 상에서 성능이 상당히 좋았고, 서로 큰 차이가 안 날 줄 알았던 Linux 간에 의외로 큰 차이를 보였다.

플랫폼 별 프로그램 실행 터미널 로그

▶ Windows
> === TaskManager started === 
  PrimaryTask : 1000ms period  priority=0  work=300ms 
  TaskB       : 2500ms period  priority=1  work=1300ms 

[t=    1000.349ms] [Scheduler] triggered: PrimaryTask  pending=1  running=- 
[t=    1000.370ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    1300.392ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=0 
[t=    2000.779ms] [Scheduler] triggered: PrimaryTask  pending=1  running=- 
[t=    2000.788ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    2300.903ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=0 
[t=    2501.029ms] [Scheduler] triggered: TaskB  pending=1  running=- 
[t=    2501.039ms] [Scheduler] execute : TaskB  (priority=1) 
[t=    3001.640ms] [Scheduler] triggered: PrimaryTask  pending=1  running=TaskB 
[t=    3001.648ms] [Scheduler] PREEMPT: suspend TaskB -> run PrimaryTask 
[t=    3001.664ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    3301.708ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    3301.716ms] [Scheduler] resume  : TaskB  (priority=1) 
[t=    4001.218ms] [Scheduler] triggered: PrimaryTask  pending=1  running=TaskB 
[t=    4001.227ms] [Scheduler] PREEMPT: suspend TaskB -> run PrimaryTask 
[t=    4001.234ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    4301.281ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    4301.288ms] [Scheduler] resume  : TaskB  (priority=1) 
[t=    4402.307ms] [Scheduler] finished : TaskB  wall=1300ms  pending=0 
[t=    5001.253ms] [Scheduler] triggered: TaskB  pending=1  running=- 
[t=    5001.262ms] [Scheduler] execute : TaskB  (priority=1) 
[t=    5001.310ms] [Scheduler] triggered: PrimaryTask  pending=1  running=TaskB 
[t=    5001.312ms] [Scheduler] PREEMPT: suspend TaskB -> run PrimaryTask 
[t=    5001.319ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    5301.415ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    5301.423ms] [Scheduler] resume  : TaskB  (priority=1) 
[t=    6601.518ms] [Scheduler] finished : TaskB  wall=1300ms  pending=0

▶ WSL Linux (non-preemptRT)
> [RT] Memory locked (no page faults) 
=== TaskManager started === 
  PrimaryTask : 1000ms period  priority=0  work=300ms 
  TaskB       : 2500ms period  priority=1  work=1300ms 

[t=    1000.101ms] [Scheduler] triggered: PrimaryTask  pending=1  running=- 
[t=    1000.143ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    1300.226ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=0 
[t=    2000.100ms] [Scheduler] triggered: PrimaryTask  pending=1  running=- 
[t=    2000.138ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    2300.191ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=0 
[t=    2500.117ms] [Scheduler] triggered: TaskB  pending=1  running=- 
[t=    2500.159ms] [Scheduler] execute : TaskB  (priority=1) 
[t=    3000.105ms] [Scheduler] triggered: PrimaryTask  pending=1  running=TaskB 
[t=    3000.154ms] [Scheduler] PREEMPT: suspend TaskB -> run PrimaryTask 
[t=    3000.286ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    3300.336ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    3300.379ms] [Scheduler] resume  : TaskB  (priority=1) 
[t=    4000.127ms] [Scheduler] triggered: PrimaryTask  pending=1  running=TaskB 
[t=    4000.181ms] [Scheduler] PREEMPT: suspend TaskB -> run PrimaryTask 
[t=    4000.242ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    4300.290ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    4300.336ms] [Scheduler] resume  : TaskB  (priority=1) 
[t=    4400.384ms] [Scheduler] finished : TaskB  wall=1300ms  pending=0 
[t=    5000.110ms] [Scheduler] triggered: TaskB  pending=1  running=- 
[t=    5000.158ms] [Scheduler] execute : TaskB  (priority=1) 
[t=    5000.276ms] [Scheduler] triggered: PrimaryTask  pending=1  running=TaskB 
[t=    5000.327ms] [Scheduler] PREEMPT: suspend TaskB -> run PrimaryTask 
[t=    5000.420ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    5300.483ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    5300.523ms] [Scheduler] resume  : TaskB  (priority=1) 
[t=    6600.570ms] [Scheduler] finished : TaskB  wall=1300ms  pending=0

▶ BoxPC Linux(PREEMPT_RT)
> [RT] Memory locked (no page faults) 
=== TaskManager started === 
  PrimaryTask : 1000ms period  priority=0  work=300ms 
  TaskB       : 2500ms period  priority=1  work=1300ms 

[[PrimaryTask] RT priority: 80 
TaskB] RT priority: 79 
[t=    1000.196ms] [Scheduler] triggered: PrimaryTask  pending=1  running=- 
[t=    1000.203ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    1300.223ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=0 
[t=    2000.198ms] [Scheduler] triggered: PrimaryTask  pending=1  running=- 
[t=    2000.206ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    2300.225ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=0 
[t=    2500.191ms] [Scheduler] triggered: TaskB  pending=1  running=- 
[t=    2500.199ms] [Scheduler] execute : TaskB  (priority=1) 
[t=    3000.062ms] [Scheduler] triggered: PrimaryTask  pending=1  running=TaskB 
[t=    3000.072ms] [Scheduler] PREEMPT: suspend TaskB -> run PrimaryTask 
[t=    3000.090ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    3300.102ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    3300.107ms] [Scheduler] resume  : TaskB  (priority=1) 
[t=    4000.091ms] [Scheduler] triggered: PrimaryTask  pending=1  running=TaskB 
[t=    4000.097ms] [Scheduler] PREEMPT: suspend TaskB -> run PrimaryTask 
[t=    4000.117ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    4300.151ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    4300.154ms] [Scheduler] resume  : TaskB  (priority=1) 
[t=    4402.181ms] [Scheduler] finished : TaskB  wall=1300ms  pending=0 
[t=    5000.162ms] [Scheduler] triggered: PrimaryTask  pending=1  running=- 
[t=    5000.172ms] [Scheduler] execute : PrimaryTask  (priority=0) 
[t=    5000.192ms] [Scheduler] triggered: TaskB  pending=1  running=PrimaryTask 
[t=    5300.184ms] [Scheduler] finished : PrimaryTask  wall=300ms  pending=1 
[t=    5300.187ms] [Scheduler] execute : TaskB  (priority=1) 
[t=    6600.273ms] [Scheduler] finished : TaskB  wall=1300ms  pending=0

설계 고민

Task Scheduling 클래스 구조를 설계하면서 많은 고민과 시행착오를 가졌다.

처음에 고민했던 설계는 QtFramework를 적극 활용하여 Trigger와 TaskExecutor를 디자인 패턴으로 분리하는 구조를 생각했다.

이 구조의 장점은 Task에 여러 개의 Trigger를 붙일 수 있고, Task가 실행 중이지 않아도 Trigger가 발생하는 구조였다.

현재 구조는 C++의 세마포어(Semaphore)와 Wait 루프를 이용해 자신의 작업실행 후 다음 Trigger까지 대기하는 구조이다.

이처럼 순수 C++ 코드로 구조를 단순하고 가볍게 수정하니, 오작동 포인트를 대폭 줄일 수 있었고 복잡성을 줄여 직관적이면서도 빠른 스케줄러를 설계할 수 있었다.

Trigger와 TaskExecutor class 를 분리한 초기구조

회고

지난 PREEMPT_RT 실시간 성능 PoC 테스트에 이어서, MultiTask 및 Preemptive Scheduler 모듈을 설계하고 테스트했다.

아직 SW PLC 프로젝트에 적용하기까지 수많은 예외 처리 및 I/O 제어 등의 과정이 남아있지만,

현 단계에서는 만족스러운 결과를 확인할 수 있어 기쁘다.

PREEMPT_RT Kernel에서 마이크로 초(㎲) 단위로 동작하는 프로그램을 개발하면서 C++ 개발에 대한 자부심도 생기고,

앞으로 RTOS(실시간 운영체제)나 ROS2(로봇 프레임워크) 등의 아키텍처도 깊게 공부해보고 싶어졌다.

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

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

prejudice.tistory.com

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

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

prejudice.tistory.com

Qt Executor Pattern - moveToThread로 EventLoop 분리하기

편견장 — Tue, 14 Apr 2026 14:49:20 +0900

들어가며

지난 글에서 QTimer의 동작 원리를 자세히 살펴보면서,

"Timeout" 이벤트 발화 시점에 EventLoop가 점유되어 발생하는 지연 문제를 테스트 코드로 재현해 보았다.

2026.04.09 - [Qt] - QTimer 지연/누락 버그 해결 - EventLoop 점유로 인한 tick 누락 원인과 테스트 코드

QTimer 지연/누락 버그 해결 - EventLoop 점유로 인한 tick 누락 원인과 테스트 코드

들어가며Qt Framework의 최고의 장점은 크로스 플랫폼(Cross-Platform)을 지원하는 풍부한 라이브러리다. 그중에서도 QTimer는 특정 시간마다 반복 실행하거나 시간 관련 기능을 개발할 때 매우 편리하다

prejudice.tistory.com

이전 글의 테스트 코드에서는 EventLoop를 분리하기 위해 "Runner" 인스턴스를 worker 스레드에 넘기는 방법을 사용했다.

그림1. TestCode UML

여기서 문제는 실제 인스턴스의 위치(taskManager::runner)와 실행되는 스레드(workerThread)가 달라 헷갈린다는 점이다.

이 글에서는 클린 코드 작성을 목적으로 Executor 클래스를 도입하여, 분리된 EventLoop 위에서 동작하는 깔끔한 설계를 만들어 보려 한다.

Command Pattern

Executor 클래스를 고려하기 전에, 유사한 개념의 디자인 패턴인 Command Pattern 을 먼저 살펴보자.

이 패턴의 첫 번째 장점은 "행위자"와 "행동"을 분리하여 의존성을 제거하고 재사용성을 높이는 데 있다.

Command / Behavior 의존성 제거

두 번째 장점은 행동을 호출하는 객체와 행동의 구현을 완전히 분리하는 것에 있다.

Requester는 CommandA / CommandB의 구현 세부 사항을 알 필요가 없어진다.

Command 구현부의 분리

Producer-Consumer Pattern vs Command Pattern
설계 패턴 중 프로듀서-컨슈머 패턴이란, 멀티스테드 환경에서 데이터를 생성하는 Producer와 데이터를 처리하는 Consumer를 큐로 분리하여 데이터를 순차적으로 처리하는 패턴이다.

서로 비슷한 느낌이지만 이 패턴의 핵심 목적은 큐를 통해 비동기 작업을 처리한다는 것에 있고,
커맨드 패턴은 행동을 캡슐화하여 Requester-Behavior를 분리한다는 데에 미묘한 차이가 있다.

Executor 객체를 이용한 Thread 분리

Executor Pattern은 작업의 정의와 실행 주체를 분리하는 패턴이다.

Command Pattern을 예로 들면, Command 역할을 하는 Task 객체와 이를 실제로 실행하는 Executor 객체를 분리하는 구조라고 볼 수 있다.

Executor 실행 구조

객체가 분리되면 QObject::moveToThread() 를 사용하여 Executor 객체의 thread affinity를 변경함으로써,

특정 스레드의 EventLoop에서 동작하도록 구성할 수 있다.

즉, Requester가 속한 스레드와 Executor가 동작하는 스레드를 분리할 수 있다.

이 구조의 장점은 두 가지다.

"Request"는 작업 실행을 "Executor"에 위임하므로 두 객체 간의 의존성이 감소한다.
"Task"는 "Requester" 인스턴스 안에 존재하므로 코드 가독성과 일관성이 향상된다.

위에서 살펴본 그림1. TestCode 에 적용하면 다음과 같이 정리할 수 있다.

TestCode + Executor UML

회고

오늘은 코드를 리팩토링 하며 Executor 구조를 통해 스레드를 분리하고 안정화하는 작업을 진행했다.

포스팅은 설계를 깔끔하게 하는 것을 위주로 작성했지만, 실제 진행 중인 프로젝트에서는 다른 문제가 있었다.

큰 프로젝트 안에서 Task가 Executor 역할까지 담당하면서 main EventLoop 위에서 동작하고 있었고,

특정 시점에 다른 비동기 Slot 처리로 인해 실행 지연이 발생하는 버그를 수정했다.

실제 발생한 버그와 Executor 구조는 전혀 다른 내용처럼 보이지만, 버그가 발생한 배경과 EventLoop와의 관계를 공부하다 보니 자연스럽게 "Executor 구조를 통해 의존성을 낮추는 설계"를 주제로 글을 쓰게 됐다.

포스팅을 준비하면서 개념을 더욱 확실하게 정리할 수 있었고, Command-Behavior 패턴과 Executor 구조는 앞으로도 유용하게 활용할 수 있을 것 같다.

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

함께 볼만한 글 : 2026.01.23 - [Qt] - Qt Event Loop 동작 원리 정리 ㅡ 타이머, 이벤트, 스레드 까지

Qt Event Loop 동작 원리 정리 ㅡ 타이머, 이벤트, 스레드 까지

들어가며Qt는 크로스 플랫폼 애플리케이션 개발 프레임워크로,동일한 코드로 Windows, Linux, macOS, Embedded Linux 등 다양한 운영체제에서 동작하는 App을 만들 수 있다. QObject, Signal/Event, QTimer 등을 사용

prejudice.tistory.com

함께 볼만한 글 : 2025.12.31 - [개발] - 개발 실무에서 UML을 어디까지 그려야 할까?

개발 실무에서 UML을 어디까지 그려야 할까?

들어가며실무에서 UML을 그려야 하는 상황에 부딪히면 다음과 같은 고민이 생긴다."이걸 어디까지 그려야 하지?", "UML을 잘 그리는 방법이 뭐지?"실무에서 내가 선택한 기준과 작성방법을 정리해

prejudice.tistory.com

QTimer 지연/누락 버그 해결 - EventLoop 점유로 인한 tick 누락 원인과 테스트 코드

편견장 — Thu, 9 Apr 2026 16:46:25 +0900

들어가며

Qt Framework의 최고의 장점은 크로스 플랫폼(Cross-Platform)을 지원하는 풍부한 라이브러리다.

그중에서도 QTimer는 특정 시간마다 반복 실행하거나 시간 관련 기능을 개발할 때 매우 편리하다.

오늘 SW 개발 중 시간 관련 기능을 테스트하다 버그를 발견했다.

타이머가 100㎳마다 실행되어야 함에도 약 115㎳ 주기로 실행되고 있었고, 결국 실행 횟수 누락이 발생하는 버그였다.

이번 글에서는 버그를 잡기 위해 공부한 QTimer 심화 내용을 정리하고,

QTimer에서 횟수 누락이 발생하는 테스트 코드를 만들어 보았다.

QTimer 란?

QTimer는 QEventLoop 위에서 동작하며, 객체 간 소통을 위해 Signal/ Slot 구조를 사용한다.

Event Loop의 동작 원리는 이전 글에서 다룬 바 있다.
2026.01.23 - [Qt] - Qt Event Loop 동작 원리 정리 ㅡ 타이머, 이벤트, 스레드 까지

QTimer로 개발하기 쉬운 대표적인 두 가지 사례는 다음과 같다.

특정 시간(Interval)마다 반복되는 동작
그림1. 100㎳ 간격으로 동작하는 Timer 예시
N초 지연 후 실행
그림2. 100㎳ 지연 후 동작하는 Timer 예시

QTimer 동작 원리

반복 타이머를 직접 만들어 본다고 생각하면 더 쉽게 이해할 수 있다.

그림1 상황에 task만 고려할 때, task 종료 시 sleep(반복주기 - task 소요시간) 로 이론적인 타이머를 구현할 수 있다.

그림3. sleep으로 구현한 Interval Tiemr

단, 실제로는 100㎳에 정확히 호출되지 않고 미세한 Jitter 가 발생한다.

따라서 sleep시간을 계산할 때는 예정된 시간을 기준으로 계산해야 하며, Qt Timer도 이 방식을 사용한다.

그림4. Jitter를 고려한 Interval Timer

QTimer는 여기서 한 가지를 더 고려해야 한다.

Signal / Slot으로 전달되는 QTimer는 EventLoop까지 포함하면 다음과 같이 동작한다.

그림5. Qt EventLoop가 포함된 QTimer

*차트에서 Jitter와 QEvetnLoop를 크게 표현했지만, 실제로는 매우 짧은 시간 동안 발생한다.

Qt6 Precise Timer (QChronoTimer)

그림5 에서 발생할 수 있는 문제는, 짧은 task 응답(㎲단위)을 받기에 QEventLoop가 우리 생각처럼 빠르지 않다는 점에 있다.

기존의 QTimer는 밀리초(㎳) 단위의 제어를 목표로,

CPU 전력 효율을 위해 타이머를 묶어서 처리하기 때문에 ㎲(마이크로초) 단위의 오차가 발생한다.

Qt::PreciseTimer 옵션은 Qt5부터 제공되는 옵션으로,

타이머의 전력 효율 최적화를 비활성화해 더 정밀한 EventLoop 호출을 가능하게 한다.

그러나 그럼에도 불구하고,

㎳ 단위의 정밀도를 갖는 QTimer로는 100㎲ Interval 같은 고정밀 동작을 수행하지는 못한다는 한계가 있다.

이 한계를 극복하기 위해 Qt6.8에서 도입된 것이 QChronoTimer Class이다.

QChronoTimer는 내부적으로 nanosecond 정밀도를 지원하므로, 정밀한 타이머 동작이 필요한 경우 이를 사용해야 한다.

QTimer 누적 오차 Trouble Shooting

지금까지 정리한 내용을 바탕으로 재현 가능한 오류 시나리오를 구성해 보자.

구조

main Thread 와 m_runner Thread 로 구성 (2개의 EventLoop)
main 역할1 : 100㎳ 마다 m_runner::runProcess() Slot 호출
main 역할2 : m_runner::taskFinished() Signal 처리
m_runner 역할 : runProcess() 처리

버그가 발생하도록 각 단계에 지연 시간을 추가한 구조는 다음 이미지와 같다.

지연시간을 추가한 요약구조

이 프로그램의 문제는 onTaskFinished 가 MainThread의 EventLoop를 점유해 QTimer의 발화를 방해하는 것에 있다.

Example Timing Diagram

위 그림처럼 QTimer timeout 처리가 지연되고, 그것이 누적되어 tick 누락으로 이어질 수 있다.

QTimer 누적 오차 결과 및 TestCode

tick  elapsed_ms        expected_ms   drift_ms 
----  ----------        -----------   -------- 
   1         101                100          1 
   2         216                200         16 
   3         331                300         31 
   4         501                400        101
...
=== Result ===
Total elapsed : 10015 ms
Expected ticks: 100
Actual ticks  : 76
Missing ticks : 24

테스트에서도 실제 QTimer::timeout 처리가 밀리는 것과, timeout이 누락되는 현상을 명확히 확인할 수 있었다.

main.cpp

#include <QCoreApplication>
#include <QElapsedTimer>
#include <QTextStream>
#include <QThread>
#include <QTimer>
#include <QMutex>
#include <QMutexLocker>
#include <QMetaObject>

// ── Worker ─────────────────────────────────────────
class Runner : public QObject
{
    Q_OBJECT
public:
    explicit Runner(QObject *parent = nullptr) : QObject(parent) {}

public slots:
    void runProcess()
    {
        // Simulation (WorkerThread — no impact on MainThread)
        QElapsedTimer t;
        t.start();
        volatile double acc = 0.0;
        for (long long i = 1; t.elapsed() < 70; ++i) // delay 70ms
            acc += 1.0 / static_cast<double>(i);
        (void)acc;

        emit taskFinished();
    }

signals:
    void taskFinished();
};

// ── Main Thread ─────────────────────────────────────────────────────
class TaskManager : public QObject
{
    Q_OBJECT
public:
    explicit TaskManager(QObject *parent = nullptr)
        : QObject(parent)
        , m_cycleTrigger(new QTimer(this))
        , m_stopTimer(new QTimer(this))
        , m_runner(new Runner())
        , m_tickCount(0)
        , m_busy(false)
    {
        // CycleTrigger: QTimer in MainThread
        m_cycleTrigger->setInterval(100);
        connect(m_cycleTrigger, SIGNAL(timeout()), this, SLOT(onTaskTriggered()));

        // worker thread
        m_runner->moveToThread(&m_workerThread);
        connect(&m_workerThread, SIGNAL(finished()), m_runner, SLOT(deleteLater()));
        connect(m_runner, SIGNAL(taskFinished()), this, SLOT(onTaskFinished())); // QueuedConnection

        // 10 seconds after stop
        m_stopTimer->setSingleShot(true);
        m_stopTimer->setInterval(10000);
        connect(m_stopTimer, SIGNAL(timeout()), this, SLOT(onStop()));
    }

    void start()
    {
        QTextStream out(stdout);
        out << "Interval      : 100 ms  (CycleTrigger, MainThread)\n";
        out << "Duration      : 10 s\n";
        out << "Expected ticks: 100\n";
        out << "runProcess    : ~70 ms  (WorkerThread, no impact on MainThread)\n";
        out << "onTaskFinished   : ~45 ms  (MainThread blocking)\n";
        out << QString("%1\t%2\t%3\t%4\n")
                   .arg("tick", 4)
                   .arg("elapsed_ms", 10)
                   .arg("expected_ms", 11)
                   .arg("drift_ms",    8);
        out << "----\t----------\t-----------\t--------\n";
        out.flush();

        m_workerThread.start();
        m_elapsed.start();
        m_stopTimer->start();
        m_cycleTrigger->start();
    }

private slots:
    // ── CycleTrigger (main Thread) ──────────────────────────────────
    void onTaskTriggered()
    {
        if (m_busy) {
            // just skip if the main thread is busy (simulate tick drop)
            return;
        }
        m_busy = true;
        ++m_tickCount;

        const qint64 actualMs   = m_elapsed.elapsed();
        const qint64 expectedMs = static_cast<qint64>(m_tickCount) * 100;
        const qint64 driftMs    = actualMs - expectedMs;

        QTextStream out(stdout);
        out << QString("%1\t%2\t%3\t%4\n")
                   .arg(m_tickCount, 4)
                   .arg(actualMs,    10)
                   .arg(expectedMs,  11)
                   .arg(driftMs,     8);
        out.flush();

        // RunProcess is executed in the worker thread (no impact on main timer)
        QMetaObject::invokeMethod(m_runner, "runProcess", Qt::QueuedConnection);
    }

    // ── Worker finished (main Thread, QueuedConnection) ───────────────────
    void onTaskFinished()
    {
        // syncOutputs + monitor update: main thread blocking
        syncOutputs();
        updateMonitor();

        m_busy = false;
    }

    void onStop()
    {
        m_cycleTrigger->stop();

        const qint64 totalMs = m_elapsed.elapsed();
        QTextStream out(stdout);
        out << "\n=== Result ===\n";
        out << "Total elapsed : " << totalMs     << " ms\n";
        out << "Expected ticks: 100\n";
        out << "Actual ticks  : " << m_tickCount << "\n";
        out << "Missing ticks : " << (100 - m_tickCount) << "\n";
        out.flush();

        m_workerThread.quit();
        m_workerThread.wait();
        QCoreApplication::quit();
    }

private:
    void syncOutputs()
    {
        QElapsedTimer t; t.start();
        volatile double acc = 0.0;
        for (long long i = 1; t.elapsed() < 40; ++i)
            acc += 1.0 / static_cast<double>(i);
        (void)acc;
    }

    void updateMonitor()
    {
        // monitor update (lightweight task)
        QElapsedTimer t; t.start();
        volatile double acc = 0.0;
        for (long long i = 1; t.elapsed() < 5; ++i)
            acc += 1.0 / static_cast<double>(i);
        (void)acc;
    }

    QTimer        *m_cycleTrigger;
    QTimer        *m_stopTimer;
    Runner        *m_runner;
    QThread        m_workerThread;
    QElapsedTimer  m_elapsed;
    int            m_tickCount;
    bool           m_busy;
};

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

    TaskManager manager;
    manager.start();

    return app.exec();
}

#include "main.moc"

회고

이번 버그는 테스트 간 시간 측정을 비교하는 과정에서 발견했다.

QTimer 관련 버그를 만났다면, 대부분 수많은 Signal/Slot이 얽혀 있고 아키텍처가 이미 커진 상황일 것이다.

규모가 커진 프로젝트는 디버깅이 어렵기 때문에,

동일한 문제를 재현하는 작은 테스트 프로젝트를 별도로 만드는 것이 오히려 더 빠를 수 있다.

이번 트터블슈팅을 통해 QEventLoop 사용 시 고려사항을 되짚어 볼 수 있었고,

QEventLoop와 QTimer의 동작 원리, 나아가 Qt6.8의 QChronoTimer까지 배울 수 있어서 재미있게 풀 수 있었다.

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

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 개념 정복 - 실시간 처리

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 나 공용 폴더 격리 같은 실용적인 회피 기법까지 다양하게 배울 수 있는 계기가 되었다.

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