코드한입

[리눅스 프로그래밍 시리즈 28편]epoll 기반 채팅 서버 만들기: 멀티 클라이언트 브로드캐스트 구현

코드한입 — Wed, 8 Apr 2026 16:52:19 +0900

목표: epoll을 활용해 여러 클라이언트가 동시에 대화하는 서버를 구현한다
결과: 클라이언트가 보낸 메시지를 모든 접속자에게 전달(브로드캐스트)할 수 있다

1. 프로젝트 목표

이번 편에서는 다음 기능을 구현한다.

여러 클라이언트 동시 접속
메시지 수신
모든 클라이언트에게 전달 (broadcast)

구조:

Client A → 서버 → Client B, C, D

2. 핵심 구조

epoll
  ↓
이벤트 발생 (read)
  ↓
메시지 읽기
  ↓
모든 클라이언트에게 write

3. 서버 코드 (epoll 기반 채팅)

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <arpa/inet.h>
#include <sys/epoll.h>

#define MAX_EVENTS 10
#define PORT 8080

int main() {

    int server_fd = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = INADDR_ANY;
    addr.sin_port = htons(PORT);

    bind(server_fd, (struct sockaddr*)&addr, sizeof(addr));
    listen(server_fd, 5);

    int epfd = epoll_create1(0);

    struct epoll_event ev, events[MAX_EVENTS];

    ev.events = EPOLLIN;
    ev.data.fd = server_fd;
    epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev);

    printf("Chat server started on %d...\n", PORT);

    while(1) {

        int n = epoll_wait(epfd, events, MAX_EVENTS, -1);

        for(int i = 0; i < n; i++) {

            int fd = events[i].data.fd;

            if(fd == server_fd) {

                int client_fd = accept(server_fd, NULL, NULL);

                ev.events = EPOLLIN;
                ev.data.fd = client_fd;
                epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev);

                printf("Client connected: %d\n", client_fd);

            } else {

                char buf[1024];
                int len = read(fd, buf, sizeof(buf));

                if(len <= 0) {
                    close(fd);
                    printf("Client disconnected: %d\n", fd);
                } else {

                    // broadcast
                    for(int j = 0; j < MAX_EVENTS; j++) {
                        int target = events[j].data.fd;
                        if(target != fd && target != server_fd) {
                            write(target, buf, len);
                        }
                    }
                }
            }
        }
    }

    return 0;
}

4. 테스트 방법 (netcat)

서버 실행:

gcc chat_server.c -o chat_server
./chat_server

클라이언트 접속 (여러 터미널):

nc 127.0.0.1 8080

한 클라이언트에서 입력하면 다른 클라이언트에 출력된다.

5. 개선 포인트 (실무 관점)

현재 코드는 학습용이다. 실제로는 다음이 필요하다.

클라이언트 리스트 관리 (배열/리스트)
닉네임 기능
메시지 포맷 (JSON 등)
non-blocking 소켓
EPOLLET 적용

6. 브로드캐스트 구조 개선 팁

현재는 events 배열 기반이라 문제가 있다.

실제로는 별도의 client list를 유지해야 한다.

int clients[1024];

7. 자주 하는 실수

이벤트 배열을 클라이언트 리스트로 착각
non-blocking 설정 안함
disconnect 처리 누락

8. 28편 요약

epoll로 멀티 클라이언트 처리
메시지 브로드캐스트 구현
채팅 서버 기본 구조 완성

이제 실무형 서버의 기초를 만든 단계다.

메인 키워드

리눅스 채팅 서버
epoll 채팅 서버 C
Linux chat server example
TCP broadcast server

서브 키워드

epoll multi client chat
리눅스 네트워크 프로젝트
C socket chat server
서버 브로드캐스트 구현

[WPF 실무 34편] WPF MVVM Navigation 고급 패턴 (View 완전 분리 구조)

코드한입 — Wed, 8 Apr 2026 16:04:39 +0900

규모가 커질수록 Navigation 로직이 복잡해집니다.
View에서 직접 화면을 바꾸는 구조는 유지보수가 어려워집니다.

그래서 실무에서는
Navigation을 ViewModel에서 완전히 분리하는 구조를 사용합니다.

1. 기존 Navigation 문제

MainFrame.Navigate(new HomePage());

문제

✔ View에 의존
✔ 테스트 어려움
✔ 구조 확장 불가

2. 목표 구조

View → ViewModel → NavigationService → ViewModel

✔ View 제거
✔ ViewModel 기반 전환

3. NavigationService 설계

public interface INavigationService
{
    void Navigate<TViewModel>();
}

4. 구현

public class NavigationService : INavigationService
{
    private readonly Func<Type, object> _viewModelFactory;
    private readonly MainViewModel _mainViewModel;

    public NavigationService(Func<Type, object> factory, MainViewModel main)
    {
        _viewModelFactory = factory;
        _mainViewModel = main;
    }

    public void Navigate<TViewModel>()
    {
        var vm = (TViewModel)_viewModelFactory(typeof(TViewModel));
        _mainViewModel.CurrentViewModel = vm;
    }
}

5. MainViewModel

public class MainViewModel : ObservableObject
{
    private object _currentViewModel;

    public object CurrentViewModel
    {
        get => _currentViewModel;
        set => SetProperty(ref _currentViewModel, value);
    }
}

6. View 연결 (DataTemplate)

<DataTemplate DataType="{x:Type vm:HomeViewModel}">
    <views:HomeView/>
</DataTemplate>

<DataTemplate DataType="{x:Type vm:SettingsViewModel}">
    <views:SettingsView/>
</DataTemplate>

<ContentControl Content="{Binding CurrentViewModel}"/>

✔ View 자동 매핑

7. ViewModel에서 Navigation 호출

_navigation.Navigate<SettingsViewModel>();

✔ View 몰라도 됨

8. 실무에서 자주 하는 실수 1 — ViewModel에서 View 생성

new SettingsView()

절대 금지

9. 실무에서 자주 하는 실수 2 — NavigationService 없이 직접 변경

CurrentViewModel = new ViewModel();

✔ 확장성 없음

10. 실무 확장

✔ DI 컨테이너 연결
✔ Navigation 히스토리 관리
✔ Parameter 전달

11. 한 줄 핵심 정리

Navigation은 View가 아니라 ViewModel에서 제어해야 한다.

WPF MVVM Navigation
WPF NavigationService
WPF ViewModel 화면 전환
WPF DataTemplate Navigation
WPF MVVM 구조

[리눅스 프로그래밍 시리즈 27편]epoll 완전 이해: 고성능 이벤트 기반 서버의 표준 (edge/level trigger)

코드한입 — Tue, 7 Apr 2026 13:27:17 +0900

목표: epoll의 동작 원리와 select와의 차이를 이해한다
결과: 대규모 동시 접속을 처리하는 고성능 서버 구조를 설계할 수 있다

1. 왜 epoll이 필요한가?

select는 다음 한계가 있다.

fd 수 제한(보통 1024)
매 호출마다 fd_set 복사
O(n) 스캔

epoll은 이 문제를 해결하기 위해 등장했다.

O(1)에 가까운 이벤트 처리
대규모 연결 처리에 적합

2. epoll 개념

epoll은 관심 있는 fd를 커널에 등록해두고,

이벤트가 발생한 fd만 반환받는다.

즉 불필요한 스캔이 없다.

3. epoll 핵심 API

#include <sys/epoll.h>

int epoll_create1(int flags);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

4. epoll_create1

int epfd = epoll_create1(0);

epoll 인스턴스 생성
epfd = epoll 전용 fd

5. epoll_ctl (등록/수정/삭제)

struct epoll_event ev;
ev.events = EPOLLIN;
ev.data.fd = sock;

epoll_ctl(epfd, EPOLL_CTL_ADD, sock, &ev);

옵션:

EPOLL_CTL_ADD → 등록
EPOLL_CTL_MOD → 수정
EPOLL_CTL_DEL → 삭제

6. epoll_wait (이벤트 대기)

struct epoll_event events[10];

int n = epoll_wait(epfd, events, 10, -1);

이벤트 발생한 fd 개수 반환
events 배열에 결과 저장

7. 기본 epoll 서버 예제

#include <stdio.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/epoll.h>

int main() {

    int server_fd = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = INADDR_ANY;
    addr.sin_port = htons(8080);

    bind(server_fd, (struct sockaddr*)&addr, sizeof(addr));
    listen(server_fd, 5);

    int epfd = epoll_create1(0);

    struct epoll_event ev, events[10];

    ev.events = EPOLLIN;
    ev.data.fd = server_fd;
    epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev);

    while(1) {

        int n = epoll_wait(epfd, events, 10, -1);

        for(int i = 0; i < n; i++) {

            if(events[i].data.fd == server_fd) {

                int client_fd = accept(server_fd, NULL, NULL);

                ev.events = EPOLLIN;
                ev.data.fd = client_fd;
                epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev);

            } else {

                int fd = events[i].data.fd;
                char buf[100];

                int len = read(fd, buf, 100);

                if(len <= 0) {
                    close(fd);
                } else {
                    write(fd, buf, len);
                }
            }
        }
    }

    return 0;
}

8. Level Trigger vs Edge Trigger

Level Trigger (기본)

데이터가 남아있는 동안 계속 이벤트 발생
안정적, 사용 쉬움

Edge Trigger (EPOLLET)

상태 변화 시 1번만 이벤트 발생
성능 좋지만 구현 난이도 높음

9. epoll 장점

특징설명

고성능	O(1) 이벤트 처리
대규모 연결	수만 개 연결 처리 가능
커널 관리	효율적 이벤트 처리

10. 실무에서 사용하는 구조

epoll + non-blocking socket
worker thread
event loop

대표 예:

nginx
redis

11. 자주 하는 실수

non-blocking 설정 안함
ET 모드에서 반복 read 안함
epoll_ctl 관리 실수

12. 27편 요약

epoll은 고성능 이벤트 기반 I/O 핵심
select의 한계를 해결
ET/LT 모드 이해 중요
실무 서버 구조의 기반

이제 리눅스 서버 프로그래밍 핵심을 이해한 단계다.

메인 키워드

epoll 사용법
리눅스 epoll 서버
Linux epoll example
epoll vs select

서브 키워드

epoll edge trigger
epoll level trigger
고성능 서버 구조
Linux event loop

[리눅스 프로그래밍 시리즈 26편]select 완전 이해: 여러 소켓을 동시에 처리하는 이벤트 기반 I/O

코드한입 — Mon, 6 Apr 2026 10:04:54 +0900

목표: select를 이용해 여러 파일 디스크립터를 동시에 감시하는 방법을 이해한다
결과: 단일 프로세스로 다수의 클라이언트를 처리하는 서버를 구현할 수 있다

1. 왜 select가 필요한가?

25편의 fork 서버는 단순하지만 비용이 크다.

프로세스 생성 비용
컨텍스트 스위칭 증가
좀비 프로세스 관리

해결: 이벤트 기반 I/O

하나의 프로세스가 여러 소켓을 동시에 처리한다.

2. select 개념

select는 여러 파일 디스크립터(fd)를 감시하다가

읽기/쓰기 가능한 fd가 생기면 알려준다.

3. select 함수

#include <sys/select.h>

int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *exceptfds, struct timeval *timeout);

핵심:

readfds → 읽기 가능 감시
writefds → 쓰기 가능 감시
nfds → 가장 큰 fd + 1

4. fd_set 사용법

fd_set set;

FD_ZERO(&set);        // 초기화
FD_SET(fd, &set);     // fd 추가
FD_CLR(fd, &set);     // 제거
FD_ISSET(fd, &set);   // 이벤트 확인

5. 기본 흐름

1. fd_set 구성
2. select 호출
3. 이벤트 발생 fd 확인
4. read/write 처리

6. 간단한 select 서버 예제

#include <stdio.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/select.h>

int main() {

    int server_fd = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = INADDR_ANY;
    addr.sin_port = htons(8080);

    bind(server_fd, (struct sockaddr*)&addr, sizeof(addr));
    listen(server_fd, 5);

    fd_set master, readfds;

    FD_ZERO(&master);
    FD_SET(server_fd, &master);

    int maxfd = server_fd;

    while(1) {

        readfds = master;

        select(maxfd + 1, &readfds, NULL, NULL, NULL);

        for(int i = 0; i <= maxfd; i++) {

            if(FD_ISSET(i, &readfds)) {

                if(i == server_fd) {

                    int client_fd = accept(server_fd, NULL, NULL);
                    FD_SET(client_fd, &master);

                    if(client_fd > maxfd) maxfd = client_fd;

                } else {

                    char buf[100];
                    int n = read(i, buf, 100);

                    if(n <= 0) {
                        close(i);
                        FD_CLR(i, &master);
                    } else {
                        write(i, buf, n);
                    }
                }
            }
        }
    }

    return 0;
}

7. 동작 구조

select()
  ↓
이벤트 발생 fd 확인
  ↓
각 fd 처리

하나의 프로세스로 다수 클라이언트 처리

8. select의 한계

문제설명

fd 개수 제한	보통 1024
매번 fd_set 복사	성능 저하
O(n) 탐색	비효율

그래서 등장한 것이 epoll

9. 언제 select를 쓰나?

간단한 서버
학습용
작은 규모 시스템

10. 자주 하는 실수

readfds 재설정 안함
maxfd 갱신 안함
FD_CLR 누락

11. 26편 요약

select는 멀티 I/O 처리 도구
fd_set으로 여러 fd 관리
단일 프로세스로 다수 클라이언트 처리
하지만 성능 한계 존재

이벤트 기반 서버의 시작이다.

메인 키워드

select 사용법
리눅스 멀티 I/O
Linux select example
select 서버 구현

서브 키워드

fd_set 사용법
리눅스 이벤트 기반 서버
select socket server
Linux multiplexing

[리눅스 프로그래밍 시리즈 24편] 소켓 프로그래밍 기초: TCP 서버/클라이언트 구현 (connect, bind, listen, accept)

코드한입 — Thu, 2 Apr 2026 11:10:46 +0900

목표: TCP 소켓의 기본 흐름을 이해한다
결과: 간단한 서버와 클라이언트를 직접 구현할 수 있다

1. 소켓이란?

소켓(Socket)은 프로세스 간 네트워크 통신의 끝점(endpoint) 이다.

우리가 사용하는 대부분의 네트워크 프로그램은 소켓을 기반으로 동작한다.

예:

웹 브라우저
채팅 프로그램
API 서버

2. TCP vs UDP

프로토콜특징

TCP	연결 지향, 신뢰성 높음
UDP	비연결, 빠름

이번 편에서는 TCP를 사용한다.

3. 서버 측 기본 흐름

socket()
 ↓
bind()
 ↓
listen()
 ↓
accept()
 ↓
read()/write()

4. 클라이언트 측 기본 흐름

socket()
 ↓
connect()
 ↓
read()/write()

5. 서버 예제 코드

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <arpa/inet.h>

int main() {

    int server_fd = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = INADDR_ANY;
    addr.sin_port = htons(8080);

    bind(server_fd, (struct sockaddr*)&addr, sizeof(addr));

    listen(server_fd, 5);

    printf("Server listening on 8080...\n");

    int client_fd = accept(server_fd, NULL, NULL);

    char buffer[100];
    read(client_fd, buffer, 100);

    printf("Received: %s\n", buffer);

    write(client_fd, "Hello Client", 12);

    close(client_fd);
    close(server_fd);

    return 0;
}

6. 클라이언트 예제 코드

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <arpa/inet.h>

int main() {

    int sock = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in server;
    server.sin_family = AF_INET;
    server.sin_port = htons(8080);
    inet_pton(AF_INET, "127.0.0.1", &server.sin_addr);

    connect(sock, (struct sockaddr*)&server, sizeof(server));

    write(sock, "Hello Server", 12);

    char buffer[100];
    read(sock, buffer, 100);

    printf("Server reply: %s\n", buffer);

    close(sock);

    return 0;
}

7. 실행 방법

서버 실행:

gcc server.c -o server
./server

클라이언트 실행:

gcc client.c -o client
./client

8. 핵심 함수 정리

함수역할

socket	소켓 생성
bind	주소/포트 할당
listen	연결 대기
accept	클라이언트 연결 수락
connect	서버 연결
read/write	데이터 송수신

9. 실무에서 중요한 개념

포트 번호 관리
동시 접속 처리 (멀티 프로세스 / 멀티 스레드)
논블로킹 I/O
select / epoll

이 내용은 다음 편에서 이어진다.

10. 자주 하는 실수

bind 포트 충돌
htons / inet_pton 누락
read/write 버퍼 처리 오류

11. 24편 요약

소켓은 네트워크 통신의 기본 구조
TCP는 연결 기반 통신
서버: socket → bind → listen → accept
클라이언트: socket → connect

리눅스 네트워크 프로그래밍의 시작점이다.

메인 키워드

리눅스 소켓 프로그래밍
TCP 서버 클라이언트 C
Linux socket example
socket bind listen accept

서브 키워드

connect 사용법
리눅스 네트워크 프로그래밍
TCP socket tutorial C
서버 클라이언트 통신 예제

[WPF 실무 32편] WPF Messenger 패턴 (ViewModel 간 통신 완전 정리)

코드한입 — Thu, 2 Apr 2026 10:57:40 +0900

MVVM 구조에서 가장 많이 막히는 부분 중 하나는
ViewModel 간 데이터 전달입니다.

예를 들어

A 화면 → B 화면 데이터 전달
Dialog 결과 전달
전역 이벤트 처리

이럴 때 사용하는 것이 바로
Messenger 패턴 (CommunityToolkit.Mvvm) 입니다.

1. 왜 Messenger가 필요한가?

MVVM에서는

ViewModel끼리 직접 참조하면 안 됨

문제

결합도 증가
테스트 어려움
구조 깨짐

그래서 중간 전달자 필요

2. Messenger 개념

Sender → Message → Receiver

✔ 메시지를 보내고
✔ 필요한 ViewModel만 받는다

3. Toolkit Messenger 사용 준비

using CommunityToolkit.Mvvm.Messaging;

4. 메시지 클래스 정의

public class UserSelectedMessage
{
    public string UserName { get; }

    public UserSelectedMessage(string userName)
    {
        UserName = userName;
    }
}

5. 메시지 보내기 (Sender)

WeakReferenceMessenger.Default.Send(
    new UserSelectedMessage("홍길동"));

✔ 어디서든 전송 가능

6. 메시지 받기 (Receiver)

WeakReferenceMessenger.Default.Register<UserSelectedMessage>(
    this,
    (r, m) =>
    {
        SelectedUser = m.UserName;
    });

✔ 필요한 ViewModel만 수신

7. 자동 해제 (중요)

WeakReferenceMessenger.Default.UnregisterAll(this);

✔ 메모리 누수 방지

8. 실무에서 자주 하는 실수 1 — StrongReferenceMessenger 사용

StrongReferenceMessenger

문제

✔ GC 안됨 → 메모리 누수

반드시 WeakReferenceMessenger 사용

9. 실무에서 자주 하는 실수 2 — Unregister 안 함

등록만 하고 해제 안 하면

계속 이벤트 받음 + 메모리 문제

10. 실무 활용 예

✔ 화면 간 데이터 전달
✔ Dialog 결과 전달
✔ 글로벌 이벤트 (로그인 상태 등)

11. Messenger vs Event 비교

구분EventMessenger

결합도	높음	낮음
구조	직접 연결	중간 전달
MVVM 적합	낮음	매우 높음

12. 한 줄 핵심 정리

Messenger는 ViewModel 간 결합 없이 데이터를 전달하는 구조다.

WPF Messenger 패턴
CommunityToolkit Messenger
WPF ViewModel 통신
WPF MVVM 메시지 전달
WeakReferenceMessenger

[WPF 실무 32편] WPF Messenger 패턴 (ViewModel 간 통신 완전 정리)

코드한입 — Tue, 24 Mar 2026 15:02:24 +0900

MVVM 구조에서 가장 많이 막히는 부분 중 하나는
ViewModel 간 데이터 전달입니다.

예를 들어

A 화면 → B 화면 데이터 전달
Dialog 결과 전달
전역 이벤트 처리

이럴 때 사용하는 것이 바로
Messenger 패턴 (CommunityToolkit.Mvvm) 입니다.

1. 왜 Messenger가 필요한가?

MVVM에서는

ViewModel끼리 직접 참조하면 안 됨

문제

결합도 증가
테스트 어려움
구조 깨짐

그래서 중간 전달자 필요

2. Messenger 개념

Sender → Message → Receiver

✔ 메시지를 보내고
✔ 필요한 ViewModel만 받는다

3. Toolkit Messenger 사용 준비

using CommunityToolkit.Mvvm.Messaging;

4. 메시지 클래스 정의

public class UserSelectedMessage
{
    public string UserName { get; }

    public UserSelectedMessage(string userName)
    {
        UserName = userName;
    }
}

5. 메시지 보내기 (Sender)

WeakReferenceMessenger.Default.Send(
    new UserSelectedMessage("홍길동"));

✔ 어디서든 전송 가능

6. 메시지 받기 (Receiver)

WeakReferenceMessenger.Default.Register<UserSelectedMessage>(
    this,
    (r, m) =>
    {
        SelectedUser = m.UserName;
    });

✔ 필요한 ViewModel만 수신

7. 자동 해제 (중요)

WeakReferenceMessenger.Default.UnregisterAll(this);

✔ 메모리 누수 방지

8. 실무에서 자주 하는 실수 1 — StrongReferenceMessenger 사용

StrongReferenceMessenger

문제

✔ GC 안됨 → 메모리 누수

반드시 WeakReferenceMessenger 사용

9. 실무에서 자주 하는 실수 2 — Unregister 안 함

등록만 하고 해제 안 하면

계속 이벤트 받음 + 메모리 문제

10. 실무 활용 예

✔ 화면 간 데이터 전달
✔ Dialog 결과 전달
✔ 글로벌 이벤트 (로그인 상태 등)

11. Messenger vs Event 비교

구분EventMessenger

결합도	높음	낮음
구조	직접 연결	중간 전달
MVVM 적합	낮음	매우 높음

12. 한 줄 핵심 정리

Messenger는 ViewModel 간 결합 없이 데이터를 전달하는 구조다.

WPF Messenger 패턴
CommunityToolkit Messenger
WPF ViewModel 통신
WPF MVVM 메시지 전달
WeakReferenceMessenger

[WPF 실무 31편] ObservableProperty / RelayCommand 자동화 심화 (Toolkit 고급 기능 완전 정리)

코드한입 — Mon, 23 Mar 2026 17:02:14 +0900

30편에서 CommunityToolkit.Mvvm의 기본 사용법을 배웠습니다.

이번 편에서는 실무에서 자주 쓰는 고급 기능을 다룹니다.

✔ ObservableProperty 연동 처리 ✔ NotifyPropertyChangedFor 사용법 ✔ NotifyCanExecuteChangedFor 사용법 ✔ RelayCommand 파라미터 전달 ✔ 비동기 Command (AsyncRelayCommand) 를 정리합니다.

1. ObservableProperty 복습

30편에서 배운 기본 구조입니다.

public partial class MainViewModel : ObservableObject
{
    [ObservableProperty]
    private string name;
}

✔ Name 프로퍼티 자동 생성 ✔ PropertyChanged 자동 호출

2. NotifyPropertyChangedFor — 연관 프로퍼티 알림

프로퍼티가 변경될 때 다른 프로퍼티도 함께 갱신해야 하는 경우가 많습니다.

예: FirstName이 바뀌면 FullName도 갱신

public partial class MainViewModel : ObservableObject
{
    [ObservableProperty]
    [NotifyPropertyChangedFor(nameof(FullName))]
    private string firstName;

    [ObservableProperty]
    [NotifyPropertyChangedFor(nameof(FullName))]
    private string lastName;

    public string FullName => $"{FirstName} {LastName}";
}

✔ FirstName 변경 → FullName도 PropertyChanged 발생 ✔ lastName 변경 → FullName도 PropertyChanged 발생

기존 방식이었다면 setter마다 수동 호출 필요 Toolkit은 어트리뷰트 한 줄이면 끝

3. NotifyCanExecuteChangedFor — Command 자동 갱신

프로퍼티가 변경될 때 Command의 CanExecute도 갱신해야 할 때 사용합니다.

public partial class MainViewModel : ObservableObject
{
    [ObservableProperty]
    [NotifyCanExecuteChangedFor(nameof(SaveCommand))]
    private string name;

    [RelayCommand(CanExecute = nameof(CanSave))]
    private void Save()
    {
        // 저장 로직
    }

    private bool CanSave()
    {
        return !string.IsNullOrEmpty(Name);
    }
}

✔ Name이 변경되면 SaveCommand의 CanExecute 자동 재평가 ✔ 버튼 활성화/비활성화가 자동으로 처리됨

30편에서 수동으로 NotifyCanExecuteChanged() 호출하던 것을 어트리뷰트 하나로 해결

4. RelayCommand에 파라미터 전달

Command에 값을 전달해야 할 때가 있습니다.

[RelayCommand]
private void Delete(int id)
{
    // id로 삭제
}

XAML

<Button Content="삭제"
        Command="{Binding DeleteCommand}"
        CommandParameter="3"/>

✔ CommandParameter 값이 Delete(int id)로 전달됨

5. 비동기 Command (AsyncRelayCommand)

실무에서는 비동기 작업이 필수입니다. API 호출, DB 저장 등

[RelayCommand]
private async Task LoadDataAsync()
{
    IsLoading = true;
    var data = await _service.GetDataAsync();
    Items = new ObservableCollection<string>(data);
    IsLoading = false;
}

✔ async Task 메서드에 [RelayCommand] 붙이면 ✔ AsyncRelayCommand 자동 생성됨

XAML

<Button Content="불러오기" Command="{Binding LoadDataCommand}"/>

메서드명 LoadDataAsync → Command명 LoadDataCommand Async 접미사는 자동으로 제거됨

6. AsyncRelayCommand의 IsRunning 활용

비동기 Command는 실행 중 상태를 확인할 수 있습니다.

<Button Content="불러오기"
        Command="{Binding LoadDataCommand}"/>

<ProgressBar IsIndeterminate="True"
             Visibility="{Binding LoadDataCommand.IsRunning,
                          Converter={StaticResource BoolToVisibility}}"/>

✔ IsRunning → 실행 중이면 true ✔ 로딩 표시를 별도 프로퍼티 없이 처리 가능

7. OnPropertyChanged 부분 커스텀

값 변경 시 추가 로직이 필요하면 partial 메서드를 사용합니다.

[ObservableProperty]
private string name;

partial void OnNameChanged(string value)
{
    // Name이 변경된 후 실행되는 로직
    Debug.WriteLine($"Name 변경됨: {value}");
}

partial void OnNameChanging(string value)
{
    // Name이 변경되기 직전 실행되는 로직
    Debug.WriteLine($"Name 변경 예정: {value}");
}

✔ OnXxxChanged → 변경 후 콜백 ✔ OnXxxChanging → 변경 전 콜백

setter를 직접 작성할 필요 없음

8. 실무에서 자주 하는 실수

실수 1 — NotifyPropertyChangedFor에 필드명 사용

[NotifyPropertyChangedFor(nameof(fullName))]  //

해결

[NotifyPropertyChangedFor(nameof(FullName))]  // ✔ 프로퍼티명 사용

실수 2 — async void 사용

[RelayCommand]
private async void LoadData()  //  예외 처리 불가

해결

[RelayCommand]
private async Task LoadDataAsync()  // ✔ Task 반환

실수 3 — partial 클래스 누락 (30편 복습)

public class MainViewModel  //

해결

public partial class MainViewModel  // ✔

9. 30편 기본 vs 31편 고급 비교

기능 30편 (기본) 31편 (고급)

프로퍼티	[ObservableProperty]	+ NotifyPropertyChangedFor
Command	[RelayCommand]	+ CanExecute 자동 갱신
파라미터	없음	CommandParameter 전달
비동기	없음	AsyncRelayCommand
콜백	없음	OnXxxChanged / OnXxxChanging

10. 한 줄 핵심 정리

Toolkit의 어트리뷰트를 조합하면 ViewModel 코드의 90%를 자동 생성할 수 있다.

WPF ObservableProperty 심화 WPF NotifyPropertyChangedFor WPF AsyncRelayCommand WPF MVVM Toolkit 고급 WPF 비동기 Command

[WPF 실무 30편] WPF MVVM Toolkit 사용법 (CommunityToolkit.Mvvm으로 코드 줄이기)

코드한입 — Mon, 23 Mar 2026 17:00:12 +0900

MVVM 패턴을 적용하다 보면 반복되는 코드가 많습니다.
INotifyPropertyChanged, RelayCommand, PropertyChanged 호출...

이걸 전부 자동으로 처리해주는 것이 바로
CommunityToolkit.Mvvm (MVVM Toolkit) 입니다.

이번 글에서는

✔ MVVM Toolkit 개념
✔ 설치 방법
✔ ObservableProperty 사용법
✔ RelayCommand 자동 생성
✔ 기존 MVVM 코드와 차이

를 실무 기준으로 정리합니다.

1. MVVM Toolkit이란?

MVVM Toolkit은 Microsoft에서 제공하는 라이브러리로

MVVM 코드를 자동으로 생성해주는 도구입니다.

즉

✔ 코드량 감소
✔ 유지보수 쉬움
✔ 실수 감소

2. 설치 방법

NuGet에서 설치

CommunityToolkit.Mvvm

설치 후 바로 사용 가능

3. 기존 MVVM 코드 문제

public class MainViewModel : INotifyPropertyChanged
{
    private string _name;

    public string Name
    {
        get => _name;
        set
        {
            _name = value;
            OnPropertyChanged(nameof(Name));
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;

    protected void OnPropertyChanged(string name)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
    }
}

문제

✔ 코드 길어짐
✔ 반복 구조

4. ObservableObject 사용

using CommunityToolkit.Mvvm.ComponentModel;

public partial class MainViewModel : ObservableObject
{
    [ObservableProperty]
    private string name;
}

✔ 자동으로 Property 생성됨
✔ PropertyChanged 자동 처리

코드 80% 감소

5. RelayCommand 자동 생성

using CommunityToolkit.Mvvm.Input;

public partial class MainViewModel : ObservableObject
{
    [RelayCommand]
    private void Save()
    {
        // 저장 로직
    }
}

XAML

<Button Command="{Binding SaveCommand}"/>

✔ Command 자동 생성됨

6. CanExecute 자동 처리

[RelayCommand(CanExecute = nameof(CanSave))]
private void Save()
{
}

private bool CanSave()
{
    return IsValid;
}

✔ 버튼 활성화 자동 제어

7. 실무에서 자주 하는 실수 1 — partial 누락

public class MainViewModel

동작 안 함

해결

public partial class MainViewModel

필수

8. 실무에서 자주 하는 실수 2 — 필드 이름 규칙

private string Name;

생성 안 됨

해결

private string name;

camelCase 필드 필요

9. 기존 방식 vs Toolkit 비교

구분기존 MVVMToolkit

코드량	많음	적음
PropertyChanged	수동	자동
Command	직접 구현	자동 생성
생산성	낮음	매우 높음

10. 실무 추천

✔ 신규 프로젝트 → Toolkit 사용
✔ 기존 프로젝트 → 점진적 적용

11. 한 줄 핵심 정리

MVVM Toolkit은 MVVM 코드를 자동으로 만들어주는 도구다.

WPF MVVM Toolkit
CommunityToolkit.Mvvm 사용법
WPF ObservableProperty
WPF RelayCommand 자동 생성
WPF MVVM 최신 방법

[WPF 실무 29편] WPF Validation (입력 검증 + ValidationRule 사용법 완전 정리)

코드한입 — Mon, 23 Mar 2026 16:50:21 +0900

사용자가 잘못된 값을 입력했을 때
UI에서 바로 피드백을 주는 것은 매우 중요한 UX 요소입니다.

WPF에서는 Validation 시스템을 통해
바인딩 단계에서 입력 값을 검증할 수 있습니다.

이번 글에서는

✔ Validation 구조
✔ ValidationRule 사용법
✔ ErrorTemplate 적용
✔ MVVM 방식 검증

을 실무 기준으로 정리합니다.

1. WPF Validation 구조

WPF Validation은 Binding 과정에서 동작합니다.

입력 → Binding → Validation → ViewModel

✔ 잘못된 값이면 Binding 중단
✔ UI에 오류 표시

2. ValidationRule 기본 구현

public class NumberValidationRule : ValidationRule
{
    public override ValidationResult Validate(object value, CultureInfo cultureInfo)
    {
        if (int.TryParse(value?.ToString(), out int result))
        {
            if (result >= 0 && result <= 100)
                return ValidationResult.ValidResult;
        }

        return new ValidationResult(false, "0~100 사이 값 입력");
    }
}

3. XAML에서 Validation 적용

<TextBox>
    <TextBox.Text>
        <Binding Path="Score" UpdateSourceTrigger="PropertyChanged">
            <Binding.ValidationRules>
                <local:NumberValidationRule/>
            </Binding.ValidationRules>
        </Binding>
    </TextBox.Text>
</TextBox>

✔ 입력 시 실시간 검증

4. ErrorTemplate 적용 (UI 표시)

<Style TargetType="TextBox">
    <Setter Property="Validation.ErrorTemplate">
        <Setter.Value>
            <ControlTemplate>
                <DockPanel>
                    <TextBlock Foreground="Red"
                               Text="⚠"
                               Margin="5"/>
                    <AdornedElementPlaceholder/>
                </DockPanel>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

✔ 오류 발생 시 아이콘 표시

5. 오류 메시지 표시

<TextBlock Foreground="Red"
           Text="{Binding (Validation.Errors)[0].ErrorContent,
                  RelativeSource={RelativeSource Self}}"/>

✔ 사용자에게 구체적인 오류 메시지 제공

6. 실무에서 자주 하는 실수 1 — UpdateSourceTrigger 미설정

<Binding Path="Score"/>

기본값은 LostFocus

증상

✔ 입력 중에는 검증 안 됨

해결

UpdateSourceTrigger="PropertyChanged"

7. 실무에서 자주 하는 실수 2 — 예외 처리 안 함

int.Parse(value.ToString())

문제

잘못된 입력 시 예외 발생

해결

✔ TryParse 사용

8. MVVM 방식 Validation

실무에서는 ValidationRule 대신

✔ IDataErrorInfo
✔ INotifyDataErrorInfo

사용하기도 합니다.

예 (IDataErrorInfo)

public string this[string columnName]
{
    get
    {
        if(columnName == "Score" && Score < 0)
            return "0 이상 입력";

        return null;
    }
}

✔ ViewModel에서 검증 처리

9. 실무 추천 방식

✔ 간단 검증 → ValidationRule
✔ 복잡한 비즈니스 검증 → ViewModel

두 방식 혼합 사용이 일반적입니다.

10. 한 줄 핵심 정리

Validation은 UI가 아니라 Binding 단계에서 처리된다.

WPF Validation
WPF ValidationRule 사용법
WPF 입력 검증
WPF TextBox Validation
WPF IDataErrorInfo

[리눅스 프로그래밍 시리즈 23편] 공유 메모리 & 메시지 큐: 고급 IPC(프로세스 간 통신) 완전 이해

코드한입 — Mon, 23 Mar 2026 16:37:32 +0900

목표: 공유 메모리와 메시지 큐의 개념과 사용법을 이해한다
결과: 프로세스 간 빠르고 안전하게 데이터를 주고받을 수 있다

1. IPC의 진짜 핵심 단계

18편에서 pipe를 배웠다.

하지만 pipe는 한계가 있다.

단방향 통신
부모/자식 관계 필요

그래서 더 강력한 IPC가 필요하다.

공유 메모리 (Shared Memory)
메시지 큐 (Message Queue)

2. 공유 메모리란?

여러 프로세스가 같은 메모리 영역을 공유하는 방식.

구조:

프로세스 A
      │
      ├── 공유 메모리 ──┤
      │
프로세스 B

장점:

매우 빠름 (메모리 직접 접근)
대용량 데이터 처리 가능

3. 공유 메모리 생성 (shmget)

#include <sys/ipc.h>
#include <sys/shm.h>

int shmid = shmget(IPC_PRIVATE, 1024, IPC_CREAT | 0666);

설명:

1024 바이트 메모리 생성
접근 권한 0666

4. 메모리 연결 (shmat)

char *data = (char *)shmat(shmid, NULL, 0);

이제 일반 변수처럼 사용 가능.

strcpy(data, "Hello Shared Memory");

5. 메모리 해제

shmdt(data);
shmctl(shmid, IPC_RMID, NULL);

6. 공유 메모리 예제

#include <stdio.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <string.h>

int main() {

    int shmid = shmget(IPC_PRIVATE, 1024, IPC_CREAT | 0666);

    char *data = (char *)shmat(shmid, NULL, 0);

    strcpy(data, "Hello IPC");

    printf("Data: %s\n", data);

    shmdt(data);
    shmctl(shmid, IPC_RMID, NULL);

    return 0;
}

7. 메시지 큐란?

메시지 큐는 데이터를 메시지 형태로 주고받는 방식이다.

구조:

프로세스 A → 메시지 큐 → 프로세스 B

특징:

비동기 통신
구조화된 데이터 전달

8. 메시지 큐 생성

#include <sys/ipc.h>
#include <sys/msg.h>

int msgid = msgget(IPC_PRIVATE, IPC_CREAT | 0666);

9. 메시지 구조 정의

struct msgbuf {
    long mtype;
    char mtext[100];
};

10. 메시지 보내기

struct msgbuf msg;
msg.mtype = 1;
strcpy(msg.mtext, "Hello Queue");

msgsnd(msgid, &msg, sizeof(msg.mtext), 0);

11. 메시지 받기

msgrcv(msgid, &msg, sizeof(msg.mtext), 1, 0);

printf("Received: %s\n", msg.mtext);

12. 공유 메모리 vs 메시지 큐

방식특징

공유 메모리	빠름, 동기화 필요
메시지 큐	안전함, 구조화됨

13. 언제 어떤 걸 써야 할까?

대용량 데이터 → 공유 메모리
안정적 통신 → 메시지 큐

실무에서는 세마포어(semaphore) 와 함께 사용한다.

14. 초보자가 자주 하는 실수

공유 메모리 동기화 안함
shmctl로 제거 안함
메시지 타입(mtype) 무시

15. 23편 요약

공유 메모리 → 빠른 IPC
메시지 큐 → 안전한 IPC
둘 다 커널 기반 통신
고성능 시스템에서 필수 기술

리눅스 고급 IPC의 핵심이다.

메인 키워드

리눅스 공유 메모리
메시지 큐 IPC
Linux shared memory
Linux message queue

서브 키워드

shmget shmat 사용법
msgsnd msgrcv example
리눅스 IPC 종류
시스템 프로그래밍 IPC

[리눅스 프로그래밍 시리즈 22편] signal 처리 완전 이해: SIGINT, SIGTERM, SIGCHLD로 프로세스 제어하기

코드한입 — Fri, 20 Mar 2026 15:04:47 +0900

목표: 리눅스 시그널의 개념과 처리 방법을 이해한다
결과: 프로그램에서 인터럽트/종료/자식 종료를 안전하게 처리할 수 있다

1. 시그널(signal)이란?

시그널은 프로세스에게 보내는 비동기 이벤트 알림이다.

예:

Ctrl + C → SIGINT
kill 명령 → SIGTERM / SIGKILL
자식 종료 → SIGCHLD

즉 OS가 프로세스에게 "이런 일이 발생했다"고 알려주는 방식이다.

2. 주요 시그널 종류

시그널의미

SIGINT	인터럽트 (Ctrl+C)
SIGTERM	정상 종료 요청
SIGKILL	강제 종료 (무시 불가)
SIGCHLD	자식 프로세스 종료
SIGSEGV	잘못된 메모리 접근

3. 기본 동작(Default Action)

각 시그널은 기본 동작이 있다.

종료
무시
코어 덤프

예:

SIGINT → 프로그램 종료

4. signal 함수로 처리하기

#include <signal.h>

void handler(int sig) {
    printf("Signal received: %d\n", sig);
}

int main() {

    signal(SIGINT, handler);

    while(1);

    return 0;
}

Ctrl+C를 눌러도 종료되지 않고 handler가 실행된다.

5. sigaction (권장 방식)

signal보다 더 안정적인 방식.

#include <signal.h>
#include <stdio.h>

void handler(int sig) {
    printf("Caught signal %d\n", sig);
}

int main() {

    struct sigaction sa;
    sa.sa_handler = handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;

    sigaction(SIGINT, &sa, NULL);

    while(1);

    return 0;
}

6. SIGCHLD 처리 (중요)

자식 프로세스 종료 시 발생.

이걸 처리하지 않으면 → 좀비 프로세스 발생

void handler(int sig) {
    wait(NULL);
}

int main() {

    signal(SIGCHLD, handler);

    fork();

    return 0;
}

7. kill 명령으로 시그널 보내기

터미널에서:

kill -SIGTERM PID

또는

kill -9 PID

-9 = SIGKILL

8. pause로 시그널 대기

#include <unistd.h>

pause();

시그널이 올 때까지 대기한다.

9. 안전한 시그널 처리 주의점

시그널 핸들러에서는 다음을 주의해야 한다.

printf 남용
복잡한 로직
malloc/free 사용

간단하게 처리해야 한다.

10. 실무 활용 예

서버 종료 처리 (SIGTERM)
Ctrl+C graceful shutdown
자식 프로세스 관리 (SIGCHLD)
타이머 이벤트

11. 자주 하는 실수

SIGKILL 잡으려 함 (불가능)
signal vs sigaction 차이 모름
wait 처리 안함

12. 22편 요약

시그널은 프로세스 이벤트 알림 시스템
signal / sigaction으로 처리 가능
SIGCHLD로 좀비 방지
kill로 시그널 전송 가능

리눅스 프로세스 제어의 핵심 메커니즘이다.

메인 키워드

리눅스 signal 처리
SIGINT SIGTERM SIGCHLD
Linux signal handler
sigaction 사용법

서브 키워드

signal vs sigaction
리눅스 시그널 처리 방법
Linux kill command signal
프로세스 시그널 관리

[리눅스 프로그래밍 시리즈 21편] exec 시스템 콜 완전 이해: 현재 프로세스를 다른 프로그램으로 바꾸는 방법

코드한입 — Thu, 19 Mar 2026 11:32:02 +0900

목표: exec 계열 함수의 동작 원리를 이해한다
결과: fork와 exec를 조합해 새로운 프로그램을 실행할 수 있다

1. exec는 무엇인가?

fork()가 프로세스를 복제한다면,

exec()는 현재 프로세스의 내용을 다른 프로그램으로 교체한다.

즉,

fork()  → 새 프로세스 생성
exec()  → 프로세스 내용 교체

exec 호출 이후에는 기존 코드로 돌아오지 않는다.

2. exec 계열 함수 종류

대표적으로 다음 함수들이 있다.

execl
execlp
execv
execvp
execve (기본)

가장 많이 쓰는 것은 execvp다.

3. execvp 기본 사용법

#include <unistd.h>

int execvp(const char *file, char *const argv[]);

예:

char *args[] = {"ls", "-l", NULL};
execvp("ls", args);

설명:

"ls" 프로그램 실행
"-l" 옵션 전달

4. exec 동작 특징

exec가 호출되면

현재 코드 사라짐
새로운 프로그램 로드
PID는 그대로 유지

즉 프로세스는 그대로, 내용만 바뀐다.

5. fork + exec 구조 (핵심)

리눅스에서 프로그램 실행의 표준 구조:

fork()
 ↓
(자식)
exec()

부모는 유지되고
자식이 새로운 프로그램을 실행한다.

6. fork + exec 예제

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

int main() {

    pid_t pid = fork();

    if(pid == 0) {

        char *args[] = {"ls", "-l", NULL};
        execvp("ls", args);

        // exec 실패 시만 실행
        perror("exec failed");

    } else {
        printf("Parent Process\n");
    }

    return 0;
}

7. exec 실패 처리

exec는 성공하면 절대 돌아오지 않는다.

따라서 다음 코드는 실패 시에만 실행된다.

execvp("ls", args);
perror("exec failed");

8. PATH 환경변수와 execvp

execvp는 PATH를 자동으로 검색한다.

그래서 다음이 가능하다.

execvp("ls", args);

반면 execv는 전체 경로 필요.

execv("/bin/ls", args);

9. 쉘이 동작하는 원리

쉘은 내부적으로 다음 구조를 사용한다.

사용자 입력
 ↓
fork()
 ↓
exec()
 ↓
프로그램 실행

즉 우리가 입력하는 모든 명령은

fork + exec 구조로 실행된다.

10. dup2 + exec 조합 (중요)

리다이렉션과 함께 자주 사용된다.

예:

int fd = open("out.txt", O_WRONLY | O_CREAT, 0644);
dup2(fd, 1);
execvp("ls", args);

결과:

ls 출력이 파일로 저장된다.

11. 자주 하는 실수

exec 이후 코드 실행된다고 착각
NULL 종료 안함
exec 실패 처리 안함

12. 21편 요약

exec는 프로세스 내용을 교체하는 시스템 콜
fork + exec 구조가 프로그램 실행의 핵심
exec 성공 시 기존 코드로 돌아오지 않음
execvp는 PATH 기반 실행

리눅스 프로세스 실행 구조의 핵심이다.

메인 키워드

exec 시스템 콜
fork exec 구조
Linux execvp example
리눅스 프로그램 실행 원리

서브 키워드

execv execvp 차이
리눅스 프로세스 실행
fork exec 관계
Linux process exec

[WPF 실무 28편] WPF Binding 심화 (MultiBinding / PriorityBinding 완전 정리)

코드한입 — Tue, 17 Mar 2026 13:45:16 +0900

WPF의 가장 강력한 기능 중 하나는 바로 데이터 바인딩(Data Binding) 입니다.
대부분의 UI 로직은 Binding으로 해결할 수 있지만,
실무에서는 단순 Binding만으로 해결되지 않는 경우도 많습니다.

예를 들어

여러 값을 합쳐서 표시해야 할 때
값이 없으면 다른 데이터를 표시해야 할 때

이럴 때 사용하는 것이 바로 MultiBinding과 PriorityBinding입니다.

이번 글에서는

✔ MultiBinding 개념
✔ IMultiValueConverter 사용법
✔ PriorityBinding 동작 방식
✔ 실무 활용 패턴

을 정리합니다.

1. MultiBinding이란 무엇인가

MultiBinding은 여러 Binding 값을 하나의 결과로 합치는 방식입니다.

예를 들어

FirstName = "John"
LastName = "Doe"

두 값을 합쳐서

John Doe

처럼 표시할 수 있습니다.

2. MultiBinding 기본 사용 예

<TextBlock>
    <TextBlock.Text>
        <MultiBinding Converter="{StaticResource NameConverter}">
            <Binding Path="FirstName"/>
            <Binding Path="LastName"/>
        </MultiBinding>
    </TextBlock.Text>
</TextBlock>

3. IMultiValueConverter 구현

MultiBinding은 반드시 IMultiValueConverter를 사용합니다.

public class NameConverter : IMultiValueConverter
{
    public object Convert(object[] values, Type targetType,
                          object parameter, CultureInfo culture)
    {
        string first = values[0]?.ToString();
        string last = values[1]?.ToString();

        return $"{first} {last}";
    }

    public object[] ConvertBack(object value, Type[] targetTypes,
                                object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

✔ 여러 값을 배열로 전달받음

4. MultiBinding 실무 활용 예

다음과 같은 경우 자주 사용됩니다.

✔ 이름 + 성 결합
✔ 값 조합 계산
✔ 상태 메시지 생성

예:

온도: 23°C

Value + Unit

5. PriorityBinding이란 무엇인가

PriorityBinding은 여러 Binding 중 먼저 성공한 값을 사용하는 방식입니다.

즉

Binding1 실패 → Binding2 사용

6. PriorityBinding 예제

<TextBlock>
    <TextBlock.Text>
        <PriorityBinding>
            <Binding Path="DisplayName"/>
            <Binding Path="UserName"/>
            <Binding Path="Id"/>
        </PriorityBinding>
    </TextBlock.Text>
</TextBlock>

동작 방식

1️⃣ DisplayName 있으면 사용
2️⃣ 없으면 UserName
3️⃣ 그것도 없으면 Id

7. ❌ 실무에서 자주 하는 실수 1 — MultiBinding Converter 누락

<MultiBinding>

Converter가 없으면

→ 값을 결합할 방법이 없습니다.

8. ❌ 실무에서 자주 하는 실수 2 — 값 null 처리 안 함

MultiBinding Converter에서

values[0]

바로 사용하면

→ NullReferenceException 발생

항상 null 체크 필요

9. MultiBinding vs PriorityBinding 차이

구분MultiBindingPriorityBinding

목적	값 결합	값 선택
Converter 필요	필요	필요 없음
사용 예	이름 합치기	대체 값 표시

10. 한 줄 핵심 정리

MultiBinding은 "값을 합치고"
PriorityBinding은 "값을 선택한다".

WPF MultiBinding
WPF PriorityBinding
WPF IMultiValueConverter
WPF 여러 값 바인딩
WPF Binding 심화

[WPF 실무 27편] WPF CustomControl vs UserControl 차이 (언제 무엇을 써야 할까?)

코드한입 — Mon, 16 Mar 2026 10:37:06 +0900

WPF에서 UI 컴포넌트를 만들다 보면 다음 질문이 반드시 나옵니다.

UserControl을 써야 할까? CustomControl을 만들어야 할까?

두 방식 모두 커스텀 UI를 만들 수 있지만 목적과 사용 방식이 완전히 다릅니다.

이번 글에서는

✔ UserControl 구조
✔ CustomControl 구조
✔ 두 방식의 차이
✔ 실무에서 언제 무엇을 선택해야 하는지

를 정리합니다.

1. UserControl이란 무엇인가

UserControl은 여러 컨트롤을 묶어서 재사용하는 UI 컴포넌트입니다.

예를 들어 다음과 같은 UI를 하나의 컴포넌트로 만들 수 있습니다.

[ 아이콘 ]  사용자 이름
           상태 메시지

예시

<UserControl>

    <Grid>
        <StackPanel>
            <TextBlock Text="User Name" FontSize="16"/>
            <TextBlock Text="Online"/>
        </StackPanel>
    </Grid>

</UserControl>

✔ 여러 컨트롤을 묶어서 하나의 UI로 재사용

2. UserControl 특징

✔ 기존 컨트롤 조합
✔ 구현이 매우 쉬움
✔ 빠른 UI 제작

하지만 단점도 있습니다.

스타일 완전 변경 어려움
템플릿 교체 어려움

3. CustomControl이란 무엇인가

CustomControl은 완전히 새로운 컨트롤을 만드는 방식입니다.

기존 컨트롤을 조합하는 것이 아니라

ControlTemplate 기반으로 UI를 정의합니다.

예:

커스텀 버튼
커스텀 슬라이더
특수 UI 컴포넌트

4. CustomControl 구조

public class MyButton : Control
{
    static MyButton()
    {
        DefaultStyleKeyProperty.OverrideMetadata(
            typeof(MyButton),
            new FrameworkPropertyMetadata(typeof(MyButton)));
    }
}

그리고 스타일은

Themes/Generic.xaml

에서 정의합니다.

5. CustomControl 특징

✔ 스타일 완전 변경 가능
✔ ControlTemplate 지원
✔ WPF 기본 컨트롤과 동일한 구조

단점

구현 난이도 높음
구조 이해 필요

6. UserControl vs CustomControl 비교

구분UserControlCustomControl

목적	UI 조합	새로운 컨트롤 생성
구현 난이도	쉬움	어려움
스타일 변경	제한적	완전 가능
ControlTemplate	제한	완전 지원

7. 언제 UserControl을 써야 할까

다음 경우에는 UserControl이 가장 적합합니다.

✔ 화면 일부를 재사용할 때
✔ 복잡한 UI 묶음
✔ 빠른 개발 필요

예:

사용자 카드
리스트 아이템 UI
설정 패널

8. 언제 CustomControl을 써야 할까

다음 경우에는 CustomControl을 사용해야 합니다.

✔ 완전히 새로운 컨트롤
✔ 스타일 완전 커스터마이징
✔ 라이브러리 컴포넌트 제작

예:

커스텀 버튼
특수 그래프 컨트롤
UI 프레임워크 컴포넌트

9. 실무에서 자주 하는 실수 1 — 모든 것을 CustomControl로 만듦

CustomControl은 강력하지만

대부분 UI는 UserControl로 충분합니다.

불필요하게 복잡한 구조가 됩니다.

10. 실무에서 자주 하는 실수 2 — UserControl에 DependencyProperty 안 씀

재사용 가능한 UserControl이라면

✔ DependencyProperty
✔ Command

를 제공해야 합니다.

그래야 외부 바인딩이 가능합니다.

11. 실무 추천 규칙

UI 묶기 → UserControl
새 컨트롤 제작 → CustomControl

이 규칙이면 대부분 올바른 선택을 할 수 있습니다.

12. 한 줄 핵심 정리

UserControl은 "조합"이고 CustomControl은 "새로운 컨트롤"이다.

WPF CustomControl
WPF UserControl 차이
WPF CustomControl 예제
WPF UserControl 사용법
WPF ControlTemplate 컨트롤

[리눅스 프로그래밍 시리즈 20편] wait / waitpid 완전 이해: 좀비 프로세스(Zombie Process)와 프로세스 종료 관리

코드한입 — Mon, 16 Mar 2026 10:25:14 +0900

목표: fork로 생성된 자식 프로세스를 올바르게 종료 처리하는 방법을 이해한다
결과: 좀비 프로세스가 왜 발생하는지 알고 wait / waitpid로 해결할 수 있다

1. fork 이후 반드시 필요한 작업

19편에서 fork()를 이용해 자식 프로세스를 생성하는 방법을 배웠다.

하지만 fork만 사용하면 문제가 하나 생긴다.

좀비 프로세스(Zombie Process)

이 문제를 해결하는 시스템 콜이 바로

wait()
waitpid()

이다.

2. 좀비 프로세스란?

프로세스가 종료되더라도 바로 완전히 사라지는 것은 아니다.

커널은 다음 정보를 잠시 보관한다.

종료 상태(exit status)
CPU 사용 정보
프로세스 ID

이 정보를 부모 프로세스가 회수(wait) 해야 한다.

하지만 부모가 이 작업을 하지 않으면

좀비 프로세스가 된다.

3. 좀비 프로세스 구조

Parent Process
      │
     fork
      │
   Child Process
      │
   exit()
      │
   Zombie
      │
   wait()
      │
   완전 제거

즉 부모가 wait를 호출해야 프로세스가 완전히 정리된다.

4. wait 시스템 콜

#include <sys/wait.h>

pid_t wait(int *status);

설명:

자식 프로세스가 종료될 때까지 대기
종료 상태를 status에 저장

5. 기본 wait 예제

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

int main() {

    pid_t pid = fork();

    if(pid == 0) {
        printf("Child Process\n");
        return 0;
    }

    wait(NULL);

    printf("Parent Process End\n");

    return 0;
}

동작:

Child Process
Parent Process End

부모는 자식 종료 후 실행된다.

6. waitpid 시스템 콜

특정 자식 프로세스를 기다릴 때 사용한다.

pid_t waitpid(pid_t pid, int *status, int options);

구성:

파라미터의미

pid	기다릴 프로세스
status	종료 상태
options	동작 옵션

7. waitpid 예제

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

int main() {

    pid_t pid = fork();

    if(pid == 0) {
        printf("Child Running\n");
        return 0;
    }

    waitpid(pid, NULL, 0);

    printf("Child Finished\n");

    return 0;
}

8. 종료 상태 확인

자식 프로세스의 종료 상태를 확인할 수도 있다.

int status;

wait(&status);

if(WIFEXITED(status)) {
    printf("exit code: %d\n", WEXITSTATUS(status));
}

주요 매크로:

매크로의미

WIFEXITED	정상 종료 여부
WEXITSTATUS	종료 코드

9. 좀비 프로세스 확인 방법

리눅스에서 좀비 프로세스는 다음 명령으로 확인 가능하다.

ps aux

출력에서

상태가 보이면 좀비 프로세스다.

10. 서버 프로그램에서 중요한 이유

웹 서버나 네트워크 서버는 다음 구조를 사용한다.

fork()
 ↓
client 처리
 ↓
exit()

이때 wait 처리가 없으면

서버에 좀비 프로세스가 계속 쌓인다.

그래서 서버 프로그램에서는 반드시

wait
waitpid
signal(SIGCHLD)

처리가 필요하다.

11. 초보자가 자주 하는 실수

wait 호출 안함
fork 후 부모 종료
waitpid 사용법 혼동

12. 20편 요약

fork로 생성된 자식 프로세스는 반드시 정리해야 한다
wait → 자식 종료 대기
waitpid → 특정 자식 대기
좀비 프로세스 방지에 필수

리눅스 프로세스 관리의 핵심 시스템 콜이다.

메인 키워드

wait 시스템 콜
waitpid 사용법
좀비 프로세스 zombie process
리눅스 프로세스 종료 관리

서브 키워드

fork wait 관계
Linux wait example
zombie process 해결
리눅스 프로세스 관리

[리눅스 프로그래밍 시리즈 19편] fork 시스템 콜 완전 이해: 리눅스에서 새로운 프로세스가 만들어지는 원리

코드한입 — Fri, 13 Mar 2026 10:28:00 +0900

목표: fork 시스템 콜의 동작 원리를 이해한다
결과: 부모 프로세스와 자식 프로세스의 실행 흐름을 이해하고 활용할 수 있다

1. 리눅스에서 프로세스는 어떻게 생성될까?

리눅스에서 새로운 프로그램이 실행될 때 가장 중요한 시스템 콜이 있다.

fork()

fork는 현재 실행 중인 프로세스를 복사하여 새로운 프로세스(자식 프로세스) 를 만든다.

구조:

부모 프로세스
      │
     fork()
      │
 ┌─────────────┐
 │             │
부모          자식
프로세스      프로세스

fork 이후에는 두 개의 프로세스가 동시에 실행된다.

2. fork 함수

#include <unistd.h>

pid_t fork(void);

fork는 호출 후 두 번 반환된다.

반환값의미

>0	부모 프로세스 (자식 PID 반환)
0	자식 프로세스
-1	오류

3. 가장 기본적인 fork 예제

#include <stdio.h>
#include <unistd.h>

int main() {

    fork();

    printf("Hello Fork\n");

    return 0;
}

실행 결과:

Hello Fork
Hello Fork

이유:

fork 이후 부모와 자식이 같은 코드를 실행하기 때문이다.

4. 부모와 자식 구분하기

fork의 반환값을 이용해 구분한다.

#include <stdio.h>
#include <unistd.h>

int main() {

    pid_t pid = fork();

    if(pid == 0) {
        printf("Child Process\n");
    } else {
        printf("Parent Process\n");
    }

    return 0;
}

출력:

Parent Process
Child Process

5. 프로세스 ID 확인

리눅스에서는 각 프로세스가 PID(Process ID) 를 가진다.

6. fork 이후 메모리 구조

fork는 부모 프로세스의 메모리를 그대로 복사한다.

예:

int x = 10;

fork 이후

부모 x = 10
자식 x = 10

하지만 이후 변경은 서로 영향을 주지 않는다.

자식 x = 20
부모 x = 10

즉 메모리는 복사(copy) 된다.

7. fork + exec 구조

실제 리눅스 프로그램 실행은 보통 이렇게 이루어진다.

fork()
 ↓
exec()

fork → 새로운 프로세스 생성
exec → 새로운 프로그램 실행

쉘이 프로그램을 실행할 때 사용하는 구조다.

8. fork가 많이 사용되는 곳

대표적인 예:

리눅스 쉘
웹 서버
멀티 프로세스 프로그램
데몬 프로세스

특히 서버 프로그램에서 많이 사용된다.

9. fork 사용 시 주의점

fork는 프로세스를 복사하기 때문에 비용이 있다.

문제 상황:

너무 많은 fork 호출
좀비 프로세스 발생

이 문제는 다음 글에서 다룬다.

10. 초보자가 자주 하는 실수

fork 이후 코드 흐름 이해 못함
부모/자식 구분 안함
프로세스 종료 관리 안함

11. 19편 요약

fork는 프로세스를 복사하는 시스템 콜
부모와 자식 프로세스가 동시에 실행
반환값으로 부모/자식 구분
exec와 함께 프로그램 실행 구조 형성

리눅스 프로세스 구조를 이해하는 핵심 시스템 콜이다.

메인 키워드

fork 시스템 콜
리눅스 프로세스 생성
Linux fork example
fork 프로세스 구조

서브 키워드

fork 부모 자식 프로세스
fork exec 구조
리눅스 프로세스 생성 원리
Linux process fork

[리눅스 프로그래밍 시리즈 18편] pipe 시스템 콜: 리눅스 프로세스 간 통신(IPC)의 가장 기본 구조

코드한입 — Fri, 13 Mar 2026 09:26:03 +0900

목표: pipe 시스템 콜을 이용한 프로세스 간 통신을 이해한다
결과: 한 프로세스의 출력이 다른 프로세스의 입력으로 전달되는 구조를 구현할 수 있다

1. 프로세스는 기본적으로 서로 독립적이다

리눅스에서 실행되는 프로세스는 서로 독립적인 메모리 공간을 가진다.

즉 기본적으로는

다른 프로세스 변수 접근 불가
메모리 공유 불가

하지만 실제 프로그램에서는 프로세스 간 데이터 전달이 필요하다.

예:

쉘 파이프 (ls | grep txt)
서버 프로세스
데이터 처리 파이프라인

이런 통신을 IPC (Inter Process Communication) 라고 한다.

그리고 가장 기본적인 IPC가 바로 pipe다.

2. pipe의 기본 개념

pipe는 한 방향 데이터 통로다.

구조:

프로세스 A  →  pipe  →  프로세스 B

A는 데이터를 쓰고

B는 데이터를 읽는다.

3. pipe 시스템 콜

#include <unistd.h>

int pipe(int fd[2]);

pipe를 생성하면 두 개의 파일 디스크립터가 생성된다.

fd 번호의미

fd[0]	읽기(read)
fd[1]	쓰기(write)

4. pipe 동작 구조

        write(fd[1])
프로세스 A ---------> pipe ---------> 프로세스 B
                       read(fd[0])

즉

fd[1] → 데이터 입력
fd[0] → 데이터 읽기

5. 기본 pipe 예제

다음 예제는 pipe로 데이터를 전달하는 프로그램이다.

#include <stdio.h>
#include <unistd.h>

int main() {

    int fd[2];

    pipe(fd);

    write(fd[1], "Hello Pipe", 10);

    char buf[20];

    read(fd[0], buf, 10);

    buf[10] = '\0';

    printf("pipe data: %s\n", buf);

    return 0;
}

출력:

pipe data: Hello Pipe

6. fork와 함께 사용하는 이유

pipe는 보통 fork()와 함께 사용한다.

구조:

부모 프로세스
      │
     fork
      │
 ┌─────────────┐
 │             │
부모          자식
write         read

즉 부모가 데이터를 쓰고

자식이 데이터를 읽는다.

7. fork + pipe 예제

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

int main() {

    int fd[2];
    pipe(fd);

    pid_t pid = fork();

    if(pid > 0) {

        write(fd[1], "Hello Child", 11);

    } else {

        char buf[20];

        read(fd[0], buf, 11);

        buf[11] = '\0';

        printf("Child received: %s\n", buf);

    }

    return 0;
}

8. pipe 사용 시 중요한 점

불필요한 파일 디스크립터는 반드시 닫아야 한다.

예:

부모 → read 필요 없음
자식 → write 필요 없음

그래서 보통 이렇게 작성한다.

close(fd[0]);
close(fd[1]);

필요 없는 쪽을 닫는다.

9. 쉘 파이프 구조 이해

다음 명령을 보자.

ls | grep txt

내부적으로는 이렇게 동작한다.

ls stdout → pipe → grep stdin

이 구조 역시

pipe()
fork()
dup2()

로 구현된다.

10. pipe의 특징

특징설명

단방향	한 방향 통신
커널 버퍼 사용	데이터 임시 저장
부모/자식 프로세스에서 많이 사용	fork와 함께 사용

11. 초보자가 자주 하는 실수

read / write 방향 혼동
필요 없는 fd 닫지 않음
fork 없이 pipe 사용

12. 18편 요약

pipe는 프로세스 간 통신(IPC) 의 기본 구조
fd[0] → read
fd[1] → write
fork와 함께 사용
쉘 파이프(|)의 내부 구조

pipe는 이후 배울 프로세스 통신의 기초가 된다.

메인 키워드

리눅스 pipe 사용법
Linux pipe system call
프로세스 간 통신 IPC
pipe fork example

서브 키워드

pipe read write
Linux IPC pipe
리눅스 프로세스 통신
시스템 프로그래밍 pipe

[리눅스 프로그래밍 시리즈 17편] 파일 디스크립터와 리다이렉션: dup, dup2 완전 이해

코드한입 — Thu, 12 Mar 2026 19:22:28 +0900

목표: 파일 디스크립터 복사와 입출력 리다이렉션 구조를 이해한다
결과: 프로그램의 출력(stdout)을 파일이나 다른 곳으로 변경할 수 있다

1. 파일 디스크립터 복습

15편에서 배운 것처럼 리눅스에서는 모든 입출력이 파일 디스크립터(File Descriptor) 로 관리된다.

기본 디스크립터는 다음과 같다.

번호의미

0	stdin (표준 입력)
1	stdout (표준 출력)
2	stderr (에러 출력)

예를 들어 printf()는 사실상 stdout(1) 으로 데이터를 보내는 것이다.

2. 리다이렉션이 가능한 이유

터미널에서 다음 명령을 자주 사용한다.

ls > output.txt

이 명령은

stdout → 파일

로 연결된다.

이 기능이 가능한 이유가 바로 파일 디스크립터 변경 때문이다.

이 작업을 프로그래밍에서 수행하는 함수가 dup / dup2 다.

3. dup 함수

파일 디스크립터를 복사한다.

#include <unistd.h>

int dup(int oldfd);

동작:

기존 fd를 복사
사용 가능한 가장 작은 번호의 fd 반환

예:

old fd = 3
new fd = 4

4. dup2 함수

특정 번호의 파일 디스크립터로 복사한다.

int dup2(int oldfd, int newfd);

예:

dup2(fd, 1);

의미:

stdout → fd 파일

즉 printf 출력이 파일로 이동한다.

5. 출력 리다이렉션 예제

다음 프로그램을 만들어 보자.

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main() {

    int fd = open("output.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);

    dup2(fd, 1);

    printf("Hello Linux Redirect!\n");

    close(fd);

    return 0;
}

컴파일:

gcc redirect.c -o redirect

실행 후 output.txt 확인.

Hello Linux Redirect!

터미널이 아니라 파일에 출력된다.

6. stderr 리다이렉션

stderr도 동일하게 변경할 수 있다.

dup2(fd, 2);

이렇게 하면 에러 메시지도 파일로 저장된다.

7. 파이프와 함께 사용되는 이유

리눅스 쉘에서 다음 명령을 보자.

ls | grep txt

이 구조는 내부적으로 다음과 같다.

stdout(ls) → pipe → stdin(grep)

이 연결도 결국 파일 디스크립터 복사로 구현된다.

그래서 dup/dup2는

파이프
리다이렉션
프로세스 통신

에서 매우 중요한 역할을 한다.

8. 파일 디스크립터 흐름

예를 들어 stdout을 파일로 변경하면 구조는 이렇게 된다.

printf()
  ↓
stdout (fd=1)
  ↓
output.txt

프로그램은 그대로인데 출력 대상만 바뀐다.

9. 자주 하는 실수

dup 후 기존 fd 닫지 않음
dup2 순서 혼동
stdout / stderr 구분 안함

10. 17편 요약

리눅스 입출력은 파일 디스크립터 기반
dup → fd 복사
dup2 → 특정 fd로 복사
stdout / stderr 리다이렉션 가능
파이프와 프로세스 통신의 핵심 개념

리눅스 시스템 프로그래밍에서 매우 중요한 구조다.

메인 키워드

dup dup2 사용법
리눅스 리다이렉션 프로그래밍
Linux file descriptor redirect
stdout redirect C

서브 키워드

dup2 stdout redirect
리눅스 파일 디스크립터 복사
Linux dup2 example
시스템 프로그래밍 redirect

[리눅스 프로그래밍 시리즈 16편] lseek 완전 이해: 파일 읽기 위치를 자유롭게 이동하는 방법

코드한입 — Thu, 12 Mar 2026 18:38:10 +0900

목표: 파일 포인터 위치를 이동하는 방법을 이해한다
결과: 파일을 원하는 위치에서 읽거나 쓸 수 있는 프로그램을 만들 수 있다

1. 파일은 항상 '위치'가 있다

이전 글(15편)에서 우리는 다음 시스템 콜을 배웠다.

open()
read()
write()
close()

하지만 한 가지 중요한 개념이 있다.

파일에는 현재 읽기/쓰기 위치가 존재한다.

예:

Hello Linux

처음 read()를 실행하면

H e l l o

를 읽는다.

다음 read()는

(이어서) Linux

를 읽는다.

즉 파일에는 현재 위치(offset) 가 존재한다.

2. lseek란 무엇인가?

lseek()은 파일의 현재 위치를 이동시키는 시스템 콜이다.

#include <unistd.h>

off_t lseek(int fd, off_t offset, int whence);

구성:

fd → 파일 디스크립터
offset → 이동할 위치
whence → 기준 위치

3. whence 옵션

파일 위치 기준을 결정한다.

옵션의미

SEEK_SET	파일 시작 기준
SEEK_CUR	현재 위치 기준
SEEK_END	파일 끝 기준

4. 파일 처음으로 이동

lseek(fd, 0, SEEK_SET);

파일 포인터가 파일 시작 위치로 이동한다.

5. 현재 위치에서 이동

lseek(fd, 10, SEEK_CUR);

현재 위치에서 10바이트 앞으로 이동.

6. 파일 끝으로 이동

lseek(fd, 0, SEEK_END);

파일의 끝 위치로 이동.

로그 파일 추가 작업에서 많이 사용된다.

7. 전체 예제 코드

파일을 읽고 다시 처음부터 읽는 예제.

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main() {

    int fd = open("test.txt", O_RDONLY);

    char buf[6];

    read(fd, buf, 5);
    buf[5] = '\0';

    printf("첫 읽기: %s\n", buf);

    lseek(fd, 0, SEEK_SET);

    read(fd, buf, 5);
    buf[5] = '\0';

    printf("두번째 읽기: %s\n", buf);

    close(fd);

    return 0;
}

컴파일:

gcc seek_example.c -o seek_example

8. 파일 크기 구하기

lseek는 파일 크기를 확인하는 데도 사용된다.

off_t size = lseek(fd, 0, SEEK_END);

이 값이 파일 전체 크기가 된다.

9. Sparse File (희소 파일)

lseek는 특별한 파일도 만들 수 있다.

예:

lseek(fd, 1000, SEEK_SET);
write(fd, "A", 1);

이렇게 하면 중간이 비어있는 파일이 생성된다.

이것을 Sparse File이라고 한다.

대용량 파일 처리에서 사용된다.

10. 자주 하는 실수

lseek 반환값 확인 안함
SEEK_SET / SEEK_CUR 혼동
read 이후 위치 변경 고려 안함

11. 16편 요약

파일에는 항상 현재 위치(offset)가 존재
lseek로 위치 이동 가능
SEEK_SET / SEEK_CUR / SEEK_END 이해 중요
파일 크기 확인에도 사용 가능

파일 I/O 프로그래밍에서 매우 중요한 시스템 콜이다.

메인 키워드

리눅스 lseek 사용법
파일 포인터 이동
Linux lseek example
파일 offset 개념

서브 키워드

SEEK_SET SEEK_CUR SEEK_END
리눅스 파일 위치 이동
Linux file offset
시스템 프로그래밍 lseek

[WPF 실무 26편] WPF AttachedProperty 완전 이해 (Grid.Row 같은 속성은 어떻게 만들어질까?)

코드한입 — Thu, 12 Mar 2026 18:34:24 +0900

WPF를 사용하다 보면 다음과 같은 속성을 자주 보게 됩니다.
<Button Grid.Row="1" Grid.Column="2" />
Button에는 Row나 Column 속성이 없는데도 사용이 가능합니다.

그 이유는 바로 AttachedProperty 때문입니다.

이번 글에서는

✔ AttachedProperty 개념
✔ DependencyProperty와 차이
✔ AttachedProperty 생성 방법
✔ 실무 활용 사례

를 정리합니다.

1. AttachedProperty란 무엇인가

AttachedProperty는

다른 컨트롤에 속성을 "붙여서" 사용하는 구조입니다.

예:

Grid.Row
Grid.Column
Canvas.Left
Canvas.Top
DockPanel.Dock

이 속성들은 실제로는 Grid / Canvas / DockPanel이 정의한 것입니다.

하지만 다른 컨트롤(Button, TextBox 등)에 붙여서 사용할 수 있습니다.

2. 왜 AttachedProperty가 필요한가

레이아웃 컨테이너가 자식 요소의 위치를 제어해야 하기 때문입니다.

예:

Grid
 ├ Button
 ├ TextBox
 └ Label

Grid는 각 자식이 어느 Row / Column에 위치하는지 알아야 합니다.

그래서 Button 자체 속성이 아니라

Grid가 속성을 "붙이는" 구조를 사용합니다.

3. DependencyProperty와 차이

구분DependencyPropertyAttachedProperty

위치	자기 자신 컨트롤	다른 컨트롤에 적용
사용 예	Button.Background	Grid.Row
목적	속성 확장	레이아웃/행동 제어

즉

AttachedProperty = 확장 속성

4. AttachedProperty 선언 방법

예: Highlight 속성 만들기

public class HighlightHelper
{
    public static readonly DependencyProperty IsHighlightProperty =
        DependencyProperty.RegisterAttached(
            "IsHighlight",
            typeof(bool),
            typeof(HighlightHelper),
            new PropertyMetadata(false));

    public static void SetIsHighlight(UIElement element, bool value)
    {
        element.SetValue(IsHighlightProperty, value);
    }

    public static bool GetIsHighlight(UIElement element)
    {
        return (bool)element.GetValue(IsHighlightProperty);
    }
}

핵심 포인트

✔ RegisterAttached 사용
✔ Get / Set 메서드 필요

5. XAML에서 사용

<Button Content="Test"
        local:HighlightHelper.IsHighlight="True"/>

✔ 다른 컨트롤에 속성 추가 가능

6. PropertyChanged 활용

AttachedProperty는 값 변경 시 로직을 실행할 수 있습니다.

new PropertyMetadata(false, OnHighlightChanged);

private static void OnHighlightChanged(
    DependencyObject d,
    DependencyPropertyChangedEventArgs e)
{
    var element = d as UIElement;
}

7. 실무 활용 예

AttachedProperty는 다음 상황에서 자주 사용됩니다.

✔ Behavior 구현
✔ 공통 UI 기능 추가
✔ Validation 표시
✔ Drag & Drop 기능 확장

즉 기존 컨트롤을 수정하지 않고 기능을 확장할 수 있습니다.

8. 실무에서 자주 하는 실수 1 — Get/Set 메서드 생략

AttachedProperty는 반드시

GetProperty()
SetProperty()

메서드를 구현해야 합니다.

없으면 XAML에서 사용할 수 없습니다.

9. 실무에서 자주 하는 실수 2 — Register 사용

DependencyProperty.Register()

이렇게 하면 일반 DependencyProperty가 됩니다.

AttachedProperty는 반드시

RegisterAttached()

사용해야 합니다.

10. 한 줄 핵심 정리

AttachedProperty는 컨트롤에 기능을 "붙여서" 확장하는 구조다.

WPF AttachedProperty
WPF Grid.Row 구조
WPF RegisterAttached 예제
WPF Attached Property 사용법
WPF DependencyProperty 확장

[WPF 실무 25편] WPF DependencyProperty 완전 이해 (커스텀 컨트롤 핵심 구조)

코드한입 — Wed, 11 Mar 2026 17:44:50 +0900

WPF를 오래 사용하다 보면 반드시 만나게 되는 개념이 바로 DependencyProperty입니다.
일반 C# Property와 비슷해 보이지만 내부 동작 방식은 완전히 다릅니다.

WPF의 데이터 바인딩, 스타일, 애니메이션, 트리거 대부분이 DependencyProperty 기반으로 동작합니다.

이번 글에서는

✔ DependencyProperty 개념
✔ 일반 Property와 차이
✔ DependencyProperty 생성 방법
✔ 실무에서 사용하는 패턴

을 정리합니다.

1. DependencyProperty란 무엇인가

DependencyProperty는

WPF Property System에 등록되는 속성입니다.

일반 C# 속성

class User
{
    public string Name { get; set; }
}

WPF 속성

TextBox.Text
Button.Background
Grid.Row

이런 속성들은 대부분 DependencyProperty입니다.

2. 일반 Property와 차이

구분일반 PropertyDependencyProperty

데이터 바인딩	제한적	완전 지원
스타일 적용	불가능	가능
애니메이션	불가능	가능
값 우선순위	없음	존재

즉 WPF UI 속성 대부분은 DependencyProperty입니다.

3. DependencyProperty가 필요한 이유

WPF는 다음 기능을 위해 Property System을 사용합니다.

✔ 데이터 바인딩
✔ 스타일
✔ 트리거
✔ 애니메이션
✔ 값 상속

이 기능을 일반 Property로 구현하기 어렵기 때문에

DependencyProperty 구조를 사용합니다.

4. DependencyProperty 선언 방법

예: CustomControl에 Title 속성 추가

public class MyControl : Control
{
    public static readonly DependencyProperty TitleProperty =
        DependencyProperty.Register(
            "Title",
            typeof(string),
            typeof(MyControl),
            new PropertyMetadata(""));

    public string Title
    {
        get { return (string)GetValue(TitleProperty); }
        set { SetValue(TitleProperty, value); }
    }
}

구조

✔ PropertyKey
✔ GetValue / SetValue
✔ PropertyMetadata

5. XAML에서 사용

<local:MyControl Title="Hello"/>

또는 바인딩

<local:MyControl Title="{Binding UserName}"/>

6. PropertyMetadata

DependencyProperty는 메타데이터를 가질 수 있습니다.

new PropertyMetadata(
    "Default",
    OnTitleChanged);

값 변경 시 호출

private static void OnTitleChanged(
    DependencyObject d,
    DependencyPropertyChangedEventArgs e)
{
    var control = (MyControl)d;
}

7. 실무에서 자주 하는 실수 1 — 일반 Property 사용

public string Title { get; set; }

문제

✔ 바인딩 안 됨
✔ 스타일 적용 안 됨

CustomControl에서는 반드시 DependencyProperty 사용해야 합니다.

8. 실무에서 자주 하는 실수 2 — static 누락

public readonly DependencyProperty TitleProperty

DependencyProperty는 반드시

✔ static
✔ readonly

이어야 합니다.

9. 값 우선순위 구조

DependencyProperty 값은 다음 순서로 결정됩니다.

Animation
Local Value
Style
Template
Default

즉 애니메이션이 항상 가장 우선합니다.

10. 실무 사용 예

DependencyProperty는 주로

✔ CustomControl
✔ UserControl
✔ AttachedProperty

에서 사용됩니다.

특히 커스텀 UI 컴포넌트 만들 때 필수입니다.

11. 한 줄 핵심 정리

DependencyProperty는 WPF Property System의 핵심이다.

WPF DependencyProperty
WPF DependencyProperty 예제
WPF Property System
WPF Custom Control Property
WPF DependencyProperty Register

[리눅스 프로그래밍 시리즈 15편] 리눅스 파일 I/O 프로그래밍: open, read, write 시스템 콜 완전 이해

코드한입 — Wed, 11 Mar 2026 15:14:21 +0900

목표: 리눅스에서 파일을 직접 읽고 쓰는 시스템 프로그래밍 방식을 이해한다
결과: C 프로그램에서 파일을 열고 데이터를 읽고 쓰는 코드를 작성할 수 있다

1. 이제부터 '진짜' 리눅스 프로그래밍

지금까지는 주로

명령어
개발 도구
스크립트

위주의 내용을 다뤘다.

하지만 리눅스 시스템 프로그래밍에서는 운영체제와 직접 상호작용한다.

대표적인 방법이 바로 시스템 콜(System Call) 이다.

예:

파일 열기 → open()
파일 읽기 → read()
파일 쓰기 → write()
파일 닫기 → close()

이 함수들은 리눅스 커널과 직접 연결된다.

2. 파일 I/O의 기본 흐름

리눅스 파일 작업은 항상 다음 순서를 따른다.

open()
 ↓
read() / write()
 ↓
close()

즉

1) 파일 열기
2) 데이터 읽기/쓰기
3) 파일 닫기

3. open() 함수

파일을 열 때 사용하는 시스템 콜.

#include <fcntl.h>

int open(const char *pathname, int flags);

예:

int fd = open("test.txt", O_RDONLY);

여기서 fd는 파일 디스크립터(File Descriptor) 다.

4. 파일 디스크립터란?

리눅스에서 파일은 숫자로 관리된다.

대표적인 기본 디스크립터:

번호의미

0	stdin
1	stdout
2	stderr

새로운 파일을 열면 보통 3번부터 할당된다.

5. read() 함수

파일에서 데이터를 읽는다.

#include <unistd.h>

ssize_t read(int fd, void *buf, size_t count);

예:

char buffer[100];
read(fd, buffer, 100);

fd → 파일 디스크립터
buffer → 데이터를 저장할 공간
100 → 읽을 바이트 수

6. write() 함수

파일에 데이터를 쓴다.

ssize_t write(int fd, const void *buf, size_t count);

예:

write(fd, "Hello Linux\n", 12);

7. close() 함수

파일 작업이 끝나면 반드시 닫아야 한다.

close(fd);

파일을 닫지 않으면 파일 디스크립터 누수가 발생할 수 있다.

8. 전체 예제 코드

파일에 문자열을 쓰는 프로그램.

#include <fcntl.h>
#include <unistd.h>

int main() {

    int fd = open("test.txt", O_WRONLY | O_CREAT, 0644);

    write(fd, "Hello Linux!\n", 13);

    close(fd);

    return 0;
}

컴파일:

gcc file_write.c -o file_write

실행 후 test.txt 파일이 생성된다.

9. open 옵션 정리

옵션의미

O_RDONLY	읽기 전용
O_WRONLY	쓰기 전용
O_RDWR	읽기/쓰기
O_CREAT	파일 생성
O_APPEND	파일 끝에 추가

예:

open("log.txt", O_WRONLY | O_CREAT | O_APPEND, 0644);

10. 파일 권한 (mode)

파일 생성 시 권한을 지정한다.

예:

의미:

owner → read/write
group → read
others → read

11. 초보자가 자주 하는 실수

open 실패 체크 안함
close 호출 안함
read 반환값 확인 안함

실무에서는 반드시 에러 체크를 해야 한다.

12. 15편 요약

리눅스 파일 작업은 시스템 콜로 수행
open → read/write → close 구조
파일 디스크립터 개념 중요
O_CREAT, O_APPEND 옵션 자주 사용

이제 리눅스 시스템 프로그래밍의 핵심이 시작된다.

리눅스 파일 I/O
open read write 사용법
리눅스 시스템 콜
Linux file descriptor

서브 키워드

C open 함수
Linux read write example
리눅스 파일 디스크립터
시스템 프로그래밍 파일 처리

[리눅스 프로그래밍 시리즈 14편] Bash 쉘 스크립트 실전 자동화: 로그 분석과 서버 상태 체크 스크립트 만들기

코드한입 — Wed, 11 Mar 2026 15:04:03 +0900

목표: 실무에서 바로 사용할 수 있는 자동화 스크립트를 만든다
결과: 로그 분석, 서버 상태 확인을 자동으로 수행하는 Bash 스크립트를 작성할 수 있다

1. 왜 쉘 스크립트 자동화가 중요한가?

리눅스 서버를 운영하거나 개발 환경을 관리하다 보면 반복 작업이 매우 많다.

예를 들어:

로그에서 ERROR 개수 확인
디스크 사용량 체크
서버 상태 확인
특정 프로세스 실행 여부 확인

이런 작업을 매번 수동으로 입력하면 비효율적이다.

그래서 실무에서는 쉘 스크립트로 자동화한다.

2. 로그 분석 자동화 스크립트

먼저 간단한 로그 분석 스크립트를 만들어 보자.

파일 생성:

nano log_check.sh

내용 작성:

#!/bin/bash

LOGFILE="server.log"

ERROR_COUNT=$(grep "ERROR" $LOGFILE | wc -l)

 echo "총 ERROR 개수: $ERROR_COUNT"

실행 권한 부여:

chmod +x log_check.sh

실행:

./log_check.sh

출력 예:

총 ERROR 개수: 5

3. 디스크 사용량 체크 스크립트

서버 운영에서 디스크 용량은 매우 중요하다.

파일 생성:

nano disk_check.sh

내용:

#!/bin/bash

 echo "디스크 사용량 확인"
 df -h

실행:

chmod +x disk_check.sh
./disk_check.sh

4. 특정 프로세스 실행 여부 확인

서버에서 특정 서비스가 실행 중인지 확인하는 스크립트.

#!/bin/bash

PROCESS="nginx"

if pgrep $PROCESS > /dev/null
then
    echo "$PROCESS 실행 중"
else
    echo "$PROCESS 실행 안됨"
fi

pgrep은 프로세스 존재 여부를 확인하는 명령어다.

5. 여러 작업을 하나로 묶기

실무에서는 여러 작업을 하나의 스크립트에 넣는다.

예:

#!/bin/bash

 echo "===== 시스템 체크 ====="

 echo "현재 사용자:"
 whoami

 echo "디스크 사용량"
 df -h

 echo "메모리 상태"
 free -h

 echo "현재 실행 프로세스"
 ps aux | head

이렇게 하면 서버 상태를 빠르게 확인할 수 있다.

6. cron으로 자동 실행

쉘 스크립트는 cron을 이용해 자동 실행할 수 있다.

예:

crontab -e

예시 설정:

*/5 * * * * /home/user/log_check.sh

의미:

5분마다 스크립트 실행

7. 실무에서 자주 만드는 스크립트

대표적인 자동화 스크립트:

로그 분석 스크립트
서버 상태 체크
백업 스크립트
배포 스크립트
빌드 자동화

쉘 스크립트는 DevOps 환경에서 매우 중요한 기술이다.

8. 초보자가 자주 하는 실수

실행 권한 없이 실행
경로를 절대경로로 작성하지 않음
로그 파일 위치 오류

9. 14편 요약

Bash 스크립트로 반복 작업 자동화 가능
로그 분석, 서버 상태 체크에 많이 사용
여러 명령어를 하나의 스크립트로 묶을 수 있음
cron과 함께 사용하면 자동 운영 가능

쉘 스크립트는 리눅스 자동화의 핵심 도구다.

메인 키워드

bash 자동화 스크립트
리눅스 쉘 자동화
bash cron 자동 실행
리눅스 서버 체크 스크립트

서브 키워드

bash 로그 분석 스크립트
linux cron 사용법
bash 서버 모니터링
리눅스 자동화 스크립트

[리눅스 프로그래밍 시리즈 13편] Bash 쉘 스크립트 입문: 리눅스 작업을 자동화하는 첫 번째 단계

코드한입 — Tue, 10 Mar 2026 12:35:32 +0900

목표: Bash 스크립트를 작성하고 실행할 수 있다
결과: 반복 작업을 자동화하는 기본 스크립트를 만들 수 있다

1. 쉘 스크립트란 무엇인가?

리눅스에서 여러 명령어를 한 번에 실행하고 싶을 때가 있다.

예:

로그 파일 분석
서버 상태 확인
백업 실행
프로그램 빌드

이런 작업을 매번 명령어로 입력하는 대신 하나의 파일로 만들어 실행할 수 있다.

이 파일을 쉘 스크립트(Shell Script) 라고 한다.

가장 많이 사용하는 쉘은 Bash 이다.

2. 첫 번째 Bash 스크립트 만들기

파일 생성:

nano hello.sh

내용 작성:

#!/bin/bash

echo "Hello Linux Script"

첫 줄 의미:

#!/bin/bash

이 스크립트를 bash로 실행하라는 의미다.

3. 실행 권한 부여

스크립트를 실행하려면 실행 권한이 필요하다.

chmod +x hello.sh

4. 스크립트 실행

./hello.sh

출력:

Hello Linux Script

5. 변수 사용

Bash에서도 변수를 사용할 수 있다.

예:

#!/bin/bash

name="Linux"

echo "Hello $name"

출력:

Hello Linux

주의:

name = "Linux"

이렇게 쓰면 오류가 난다.

Bash 변수는 공백 없이 선언한다.

6. 사용자 입력 받기

read 명령어 사용.

#!/bin/bash

echo "이름을 입력하세요:"
read name

echo "Hello $name"

7. 조건문 (if)

#!/bin/bash

num=10

if [ $num -gt 5 ]
then
    echo "num은 5보다 큽니다"
fi

자주 사용하는 비교 연산자:

연산자의미

-eq	같다
-ne	같지 않다
-gt	크다
-lt	작다

8. 반복문 (for)

#!/bin/bash

for i in 1 2 3 4 5
 do
    echo "Number: $i"
 done

출력:

Number: 1
Number: 2
Number: 3
Number: 4
Number: 5

9. 파일 존재 여부 확인

#!/bin/bash

FILE="test.txt"

if [ -f $FILE ]
then
    echo "파일 존재"
else
    echo "파일 없음"
fi

옵션:

옵션의미

-f	파일 존재
-d	디렉토리
-e	파일/디렉토리 존재

10. 실습: 간단한 시스템 정보 스크립트

파일 생성:

nano sysinfo.sh

내용:

#!/bin/bash

echo "현재 사용자:"
whoami

echo "현재 디렉토리:"
pwd

echo "시스템 정보:"
uname -a

실행:

chmod +x sysinfo.sh
./sysinfo.sh

11. 초보자가 자주 하는 실수

#!/bin/bash 누락
실행 권한 없이 실행
변수 선언 시 공백 사용

12. 13편 요약

Bash 스크립트는 리눅스 자동화 도구
#!/bin/bash 로 시작
chmod +x 로 실행 권한 필요
변수, 조건문, 반복문 사용 가능

쉘 스크립트를 배우면 반복 작업을 크게 줄일 수 있다.

메인 키워드

bash 스크립트 기초
리눅스 쉘 스크립트
bash script tutorial
리눅스 자동화 스크립트

서브 키워드

bash 변수 사용법
bash if 문
bash for 문
리눅스 쉘 자동화

[리눅스 프로그래밍 시리즈 12편] ltrace 사용법: 리눅스 프로그램이 어떤 라이브러리 함수를 호출하는지 추적하기

코드한입 — Mon, 9 Mar 2026 17:32:35 +0900

목표: ltrace를 이용해 프로그램이 어떤 라이브러리 함수를 호출하는지 확인한다
결과: 라이브러리 관련 문제와 함수 호출 흐름을 분석할 수 있다

1. ltrace는 무엇인가?

11편에서 우리는 strace를 배웠다.

strace는 프로그램이 호출하는 시스템 콜(System Call) 을 추적한다.

반면 ltrace는 다음을 추적한다.

라이브러리 함수 호출 (Library Call)

예:

printf
malloc
free
fopen
strcmp

즉 프로그램이 어떤 라이브러리 함수를 호출하는지 확인할 수 있다.

2. strace vs ltrace 차이

도구추적 대상

strace	시스템 콜
ltrace	라이브러리 함수

예:

프로그램이 파일을 열 때

fopen()  → 라이브러리 함수
open()   → 시스템 콜

ltrace는 fopen을 보고

strace는 open을 본다.

둘을 함께 사용하면 프로그램 동작을 매우 깊게 분석할 수 있다.

3. ltrace 기본 사용법

프로그램 실행과 동시에 추적:

ltrace ./hello

출력 예:

printf("Hello Linux!\n") = 13

이 의미는 프로그램이 printf 함수를 호출했다는 뜻이다.

4. 특정 함수만 추적

출력이 많을 때 특정 함수만 추적할 수 있다.

예:

ltrace -e printf ./hello

printf 호출만 표시된다.

5. 실행 중인 프로세스 추적

이미 실행 중인 프로세스도 추적할 수 있다.

먼저 PID 확인:

ps aux | grep program

그 다음 attach:

ltrace -p PID

실행 중인 프로그램의 라이브러리 호출을 실시간으로 확인할 수 있다.

6. 출력 로그 저장

ltrace 출력도 파일로 저장할 수 있다.

ltrace -o trace.log ./hello

이렇게 하면 분석하기 쉽다.

7. 메모리 함수 추적 예시

다음 프로그램을 가정해 보자.

#include <stdio.h>
#include <stdlib.h>

int main() {

    int *p = malloc(sizeof(int));

    *p = 10;

    printf("%d\n", *p);

    free(p);

    return 0;
}

컴파일:

gcc -g test.c -o test

추적:

ltrace ./test

출력 예:

malloc(4) = 0x55...
printf("%d\n", 10) = 3
free(0x55...)

프로그램이 호출한 라이브러리 함수 흐름을 확인할 수 있다.

8. ltrace가 유용한 상황

다음과 같은 문제를 분석할 때 유용하다.

라이브러리 오류

프로그램이 특정 라이브러리를 제대로 호출하지 못하는 경우

메모리 관련 문제

malloc / free 호출 흐름 분석

함수 호출 분석

프로그램 내부 동작 이해

9. strace + ltrace 함께 사용하기

프로그램 분석은 보통 다음 순서로 진행한다.

1) gdb → 코드 디버깅
2) strace → 시스템 콜 분석
3) ltrace → 라이브러리 호출 분석

이 세 도구는 리눅스 개발자의 기본 디버깅 도구다.

10. 초보자가 자주 하는 실수

strace와 ltrace 차이 모름
출력이 많아 분석 포기
특정 함수 필터링 없이 사용

11. 12편 요약

ltrace는 라이브러리 함수 호출을 추적하는 도구
strace와 함께 사용하면 프로그램 내부 동작을 깊게 분석 가능
특정 함수만 필터링 가능
실행 중인 프로세스도 추적 가능

리눅스 디버깅 도구 세 가지를 정리하면

gdb + strace + ltrace

이 조합이 가장 강력하다.

메인 키워드

ltrace 사용법
리눅스 라이브러리 추적
리눅스 디버깅 도구
Linux ltrace tutorial

서브 키워드

ltrace printf 추적
strace ltrace 차이
리눅스 함수 호출 추적
Linux debugging tools

[리눅스 프로그래밍 시리즈 11편] strace 완전 입문: 리눅스 프로그램이 내부에서 무슨 일을 하는지 추적하는 방법

코드한입 — Mon, 9 Mar 2026 14:31:24 +0900

목표: strace를 이용해 프로그램이 어떤 시스템 콜을 호출하는지 확인한다
결과: 실행 오류, 파일 접근 문제, 권한 문제의 원인을 분석할 수 있다

1. strace는 무엇인가?

리눅스 프로그램은 운영체제와 직접 대화하지 않는다.

대신 시스템 콜(System Call) 을 통해 커널과 통신한다.

예를 들어 프로그램이 하는 행동:

파일 열기
네트워크 연결
메모리 할당
프로세스 생성

이 모든 작업은 시스템 콜을 통해 수행된다.

strace는 바로 이 시스템 콜을 추적하는 도구다.

즉 프로그램이 내부적으로 무엇을 하는지 그대로 볼 수 있다.

2. strace가 필요한 상황

실무에서 다음과 같은 문제를 자주 만나게 된다.

프로그램 실행이 안 된다
파일을 찾지 못한다
권한 오류 발생
라이브러리 로딩 실패

이때 strace를 사용하면

프로그램이 어떤 파일을 열려고 했는지
어떤 시스템 콜에서 실패했는지

정확히 확인할 수 있다.

3. strace 기본 사용법

프로그램을 strace로 실행하는 방법:

strace ./hello

출력 예시:

execve("./hello", ["./hello"], 0x7ffd...) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY) = 3
read(3, ... ) = 832
write(1, "Hello Linux!", 12) = 12

이 출력은 프로그램이 실행되는 동안 발생한 시스템 콜 목록이다.

4. 특정 시스템 콜만 보기

전체 출력은 매우 길기 때문에 필터링이 필요하다.

예: 파일 관련 시스템 콜만 보기

strace -e trace=open ./hello

또는

strace -e trace=file ./hello

파일 접근 관련 시스템 콜만 출력된다.

5. 실행 중인 프로세스 추적

이미 실행 중인 프로그램도 추적할 수 있다.

먼저 PID 확인:

ps aux | grep program

그 다음 attach:

strace -p PID

이렇게 하면 실행 중인 프로그램의 시스템 콜을 실시간으로 확인할 수 있다.

6. 출력 파일로 저장

strace 출력은 매우 길기 때문에 보통 파일로 저장한다.

strace -o trace.log ./hello

그러면 결과가 trace.log 파일에 저장된다.

7. 파일 접근 문제 분석 예시

예를 들어 프로그램이 특정 파일을 열지 못하는 경우.

strace ./program

출력 예:

open("config.txt", O_RDONLY) = -1 ENOENT

의미:

ENOENT = No such file or directory

즉 프로그램이 config.txt 파일을 찾지 못했다는 의미다.

이렇게 문제 원인을 바로 확인할 수 있다.

8. 네트워크 시스템 콜 추적

네트워크 관련 동작도 확인할 수 있다.

strace -e trace=network ./program

확인 가능한 시스템 콜:

socket
connect
send
recv

네트워크 디버깅에 매우 유용하다.

9. strace + grep 조합

출력이 많기 때문에 grep과 함께 사용하는 경우가 많다.

예:

strace ./program 2>&1 | grep open

파일 open 시스템 콜만 확인 가능하다.

10. 초보자가 자주 하는 실수

strace 출력이 너무 많아 이해 못함
시스템 콜 의미를 모름
로그 저장 없이 터미널로만 분석

11. strace 핵심 정리

프로그램의 시스템 콜을 추적하는 도구
파일 접근 문제 분석에 매우 유용
실행 중인 프로세스도 추적 가능
네트워크 동작 분석 가능

리눅스 디버깅에서 gdb와 strace는 핵심 도구다.

메인 키워드

strace 사용법
리눅스 시스템콜 추적
리눅스 디버깅 도구
strace 파일 접근 분석

서브 키워드

strace open 추적
strace network 추적
리눅스 프로그램 분석
Linux strace tutorial

[WPF 실무 24편] WPF Command 패턴 (MVVM에서 버튼 이벤트 처리 완전 정리)

코드한입 — Mon, 9 Mar 2026 09:38:19 +0900

MVVM 구조에서 가장 처음 부딪히는 문제 중 하나가 바로 버튼 이벤트 처리입니다.
CodeBehind에서 Click 이벤트를 처리하면 MVVM 구조가 깨지기 때문입니다.

이 문제를 해결하는 핵심이 바로 Command 패턴입니다.

이번 글에서는

✔ Command 패턴 개념
✔ ICommand 구조
✔ RelayCommand 구현
✔ MVVM에서 버튼 이벤트 처리 방법

을 실무 기준으로 정리합니다.

1. MVVM에서 Click 이벤트를 쓰면 안 되는 이유

일반적인 WPF 방식

<Button Content="저장" Click="Save_Click"/>

private void Save_Click(object sender, RoutedEventArgs e)
{
    SaveData();
}

문제

✔ View → CodeBehind → 로직 연결
✔ ViewModel 분리 불가

MVVM 구조 깨짐

2. Command 패턴 구조

Command 패턴은 다음 구조로 동작합니다.

Button
  ↓ Command
ViewModel
  ↓ Execute
Business Logic

즉

✔ View → Command 호출
✔ 실제 로직 → ViewModel

3. ICommand 인터페이스

WPF Command는 다음 인터페이스를 구현합니다.

public interface ICommand
{
    event EventHandler CanExecuteChanged;

    bool CanExecute(object parameter);

    void Execute(object parameter);
}

역할

✔ Execute → 실제 실행 로직
✔ CanExecute → 버튼 활성화 여부

4. RelayCommand 구현

실무에서는 ICommand를 직접 구현하지 않고
RelayCommand를 만들어 사용합니다.

public class RelayCommand : ICommand
{
    private readonly Action _execute;
    private readonly Func<bool> _canExecute;

    public RelayCommand(Action execute, Func<bool> canExecute = null)
    {
        _execute = execute;
        _canExecute = canExecute;
    }

    public bool CanExecute(object parameter)
    {
        return _canExecute == null || _canExecute();
    }

    public void Execute(object parameter)
    {
        _execute();
    }

    public event EventHandler CanExecuteChanged;
}

5. ViewModel에서 Command 생성

public ICommand SaveCommand { get; }

public MainViewModel()
{
    SaveCommand = new RelayCommand(SaveData);
}

private void SaveData()
{
    // 저장 로직
}

6. XAML에서 Command 연결

<Button Content="저장"
        Command="{Binding SaveCommand}"/>

✔ 버튼 클릭 → Command 실행

CodeBehind 필요 없음

7. CanExecute로 버튼 활성화 제어

public ICommand SaveCommand { get; }

public MainViewModel()
{
    SaveCommand = new RelayCommand(SaveData, CanSave);
}

private bool CanSave()
{
    return IsDataValid;
}

✔ 조건에 따라 버튼 활성화

8. 실무에서 자주 하는 실수 1 — Command를 View에서 생성

Button.Command = new RelayCommand(...)

문제

✔ View → 로직 연결

MVVM 구조 깨짐

9. 실무에서 자주 하는 실수 2 — CanExecuteChanged 갱신 안 함

버튼 활성화 상태를 갱신하려면

CommandManager.InvalidateRequerySuggested();

호출 필요

10. CommandParameter 사용

버튼에서 데이터를 전달할 수 있습니다.

<Button Content="삭제"
        Command="{Binding DeleteCommand}"
        CommandParameter="{Binding}"/>

public RelayCommand DeleteCommand => new RelayCommand(obj => DeleteItem(obj));

11. 한 줄 핵심 정리

MVVM에서 버튼 이벤트는 Click이 아니라 Command로 처리한다.

WPF ICommand 사용법
WPF RelayCommand 예제
WPF MVVM Command 패턴
WPF Button Command
WPF CanExecute

[리눅스 프로그래밍 시리즈 10편] gdb 디버깅 입문: 리눅스에서 프로그램 오류를 찾는 가장 강력한 방법

코드한입 — Mon, 9 Mar 2026 09:33:34 +0900

목표: gdb를 사용해 프로그램 내부 상태를 확인하고 버그를 찾을 수 있다
결과: 실행 중인 프로그램을 멈추고 변수, 스택, 흐름을 분석할 수 있다

1. 왜 gdb를 배워야 할까?

프로그램을 만들다 보면 반드시 이런 상황을 만나게 된다.

프로그램이 갑자기 종료된다
segmentation fault 발생
값이 이상하게 나온다
어디서 문제가 발생하는지 알 수 없다

printf로 디버깅할 수도 있지만 한계가 있다.

이때 사용하는 도구가 gdb (GNU Debugger) 이다.

gdb는 실행 중인 프로그램을 멈추고 내부 상태를 확인할 수 있는 도구다.

2. gdb 사용을 위한 컴파일 옵션

디버깅을 위해서는 프로그램을 다음 옵션으로 컴파일해야 한다.

gcc -g hello.c -o hello

-g 옵션은 디버깅 정보를 포함한다.

이 옵션이 없으면 gdb 분석이 어려워진다.

3. gdb 실행

gdb ./hello

실행하면 다음과 같은 프롬프트가 나타난다.

(gdb)

여기서 다양한 디버깅 명령을 사용할 수 있다.

4. 프로그램 실행

run

또는

프로그램이 실행된다.

5. 브레이크포인트 설정

브레이크포인트는 프로그램 실행을 특정 위치에서 멈추게 한다.

예:

break main

또는

b 10

10번째 줄에서 프로그램이 멈춘다.

6. 코드 한 줄씩 실행

프로그램이 멈춘 상태에서 다음 명령을 사용할 수 있다.

next

다음 줄 실행

step

step

함수 내부로 들어가며 실행

7. 변수 값 확인

현재 변수 값 확인:

print 변수명

예:

print count

출력:

$1 = 5

8. 호출 스택 확인

프로그램이 어디서 호출되었는지 확인할 수 있다.

backtrace

또는

bt

특히 segmentation fault 분석 시 매우 중요하다.

9. 프로그램 계속 실행

continue

다음 브레이크포인트까지 실행된다.

10. gdb 주요 명령 정리

명령의미

run	프로그램 실행
break	브레이크포인트 설정
next	다음 줄 실행
step	함수 내부 실행
print	변수 값 확인
backtrace	호출 스택 확인
continue	실행 계속

11. 실습 예제

다음 프로그램을 만들어 보자.

#include <stdio.h>

int main() {

    int a = 10;
    int b = 0;

    int c = a / b;

    printf("%d\n", c);

    return 0;
}

컴파일:

gcc -g test.c -o test

실행하면 오류가 발생한다.

이때 gdb로 실행한다.

gdb ./test
run

그리고

bt

어디서 문제가 발생했는지 확인할 수 있다.

12. 초보자가 자주 하는 실수

-g 옵션 없이 컴파일
브레이크포인트 없이 실행
print 대신 printf 디버깅만 사용

13. 10편 요약

gdb는 리눅스 디버깅 핵심 도구
-g 옵션으로 컴파일 필요
break / next / step / print 필수
backtrace는 오류 분석 핵심

대부분의 리눅스 개발 환경에서 gdb는 기본 도구다.

메인 키워드

gdb 사용법
리눅스 디버깅
C 프로그램 디버깅
gdb 브레이크포인트

서브 키워드

gdb next step

[리눅스 프로그래밍 시리즈 9편] Makefile 입문: 리눅스 빌드 자동화와 의존성 관리 제대로 이해하기

코드한입 — Fri, 6 Mar 2026 15:12:48 +0900

목표: 여러 개의 C 파일을 효율적으로 빌드하는 방법을 이해한다
결과: Makefile을 사용해 자동으로 프로젝트를 빌드할 수 있다

1. 왜 Makefile이 필요한가?

프로젝트가 커지면 파일 구조가 보통 이렇게 늘어난다.

main.c
math.c
math.h
util.c
util.h

초보자는 보통 이렇게 컴파일한다.

gcc main.c math.c util.c -o program

처음에는 문제없다.

하지만 파일이 20개, 50개가 되면 문제가 생긴다.

매번 전체 파일을 다시 컴파일해야 함
컴파일 시간이 길어짐
의존성 관리가 어려움

이 문제를 해결하기 위해 사용하는 도구가 make + Makefile이다.

2. make의 핵심 개념: 의존성 (Dependency)

make는 변경된 파일만 다시 컴파일한다.

예를 들어 프로그램 구조가 이렇게 있다고 가정하자.

program
 ├─ main.o
 ├─ math.o
 └─ util.o

여기서

main.c 수정 → main.o 다시 컴파일
math.c 수정 → math.o 다시 컴파일

즉 변경된 파일과 관련된 부분만 빌드한다.

이게 make의 가장 중요한 특징이다.

3. 가장 기본적인 Makefile 구조

Makefile 파일 이름은 반드시 다음 중 하나여야 한다.

Makefile
makefile

예시:

program: main.o math.o
	gcc main.o math.o -o program

main.o: main.c
	gcc -c main.c

math.o: math.c
	gcc -c math.c

구조 설명:

타겟: 의존성
	실행명령

여기서 중요한 포인트

⚠ 명령어 앞에는 반드시 TAB이 들어가야 한다.

스페이스를 사용하면 오류가 발생한다.

4. make 실행

Makefile이 있는 폴더에서 다음 명령어를 실행한다.

make

make는 Makefile을 읽고 필요한 컴파일 작업을 자동으로 수행한다.

예시 출력:

gcc -c main.c
gcc -c math.c
gcc main.o math.o -o program

5. 변경된 파일만 다시 컴파일되는 과정

예를 들어 math.c만 수정했다고 가정해보자.

다시 실행:

make

출력:

gcc -c math.c
gcc main.o math.o -o program

main.c는 다시 컴파일하지 않는다.

이것이 빌드 시간 단축의 핵심 원리다.

6. 변수 사용 (실무에서 필수)

Makefile에서는 변수를 사용해 코드를 깔끔하게 만들 수 있다.

CC=gcc
CFLAGS=-Wall

program: main.o math.o
	$(CC) main.o math.o -o program

main.o: main.c
	$(CC) $(CFLAGS) -c main.c

math.o: math.c
	$(CC) $(CFLAGS) -c math.c

이렇게 하면 컴파일러나 옵션을 쉽게 변경할 수 있다.

7. clean 타겟 만들기

빌드 파일을 삭제하는 용도로 많이 사용한다.

clean:
	rm -f *.o program

실행:

make clean

보통 프로젝트에서 반드시 포함되는 타겟이다.

8. 자동 변수 (중요)

Make에는 자동 변수들이 존재한다.

변수의미

$@	현재 타겟
$<	첫 번째 의존성
$^	모든 의존성

예:

%.o: %.c
	gcc -c $< -o $@

이 방식은 큰 프로젝트에서 많이 사용된다.

9. 실무 프로젝트 구조 예시

project/
 ├─ src/
 │   ├─ main.c
 │   ├─ math.c
 │
 ├─ include/
 │   ├─ math.h
 │
 ├─ build/
 ├─ Makefile

Makefile이 프로젝트 전체 빌드를 관리한다.

10. 초보자가 자주 하는 실수

TAB 대신 스페이스 사용
의존성 누락
clean 타겟 없음
모든 파일을 한 번에 컴파일

11. 9편 요약

Makefile은 빌드 자동화 도구
변경된 파일만 다시 컴파일
변수와 자동 변수 활용 중요
clean 타겟은 필수

프로젝트 규모가 커질수록 Makefile의 중요성은 더 커진다.

메인 키워드

Makefile 사용법
리눅스 make 명령어
C 프로젝트 빌드
리눅스 빌드 자동화

서브 키워드

Makefile dependency
make clean 의미
리눅스 Makefile 예제
gcc make 빌드

[WPF 실무 23편] WPF 비동기 UI 처리 (async/await + Dispatcher 완전 정리)

코드한입 — Fri, 6 Mar 2026 15:04:44 +0900

버튼을 눌렀는데 프로그램이 멈춘 것처럼 보인다.
데이터 로딩 중 화면이 프리징 된다.

WPF에서 가장 흔한 문제 중 하나가 바로 UI Thread 블로킹입니다.

이번 글에서는

✔ WPF UI Thread 구조
✔ async / await 사용법
✔ Dispatcher 사용 이유
✔ UI 멈춤 문제 해결 패턴

을 실무 기준으로 정리합니다.

1. WPF UI Thread 구조

WPF는 기본적으로 Single UI Thread 모델입니다.

즉,

UI 업데이트
버튼 클릭 처리
렌더링
이벤트 처리

모두 같은 Thread에서 실행됩니다.

따라서 오래 걸리는 작업을 UI Thread에서 실행하면

화면이 멈춥니다.

2. UI 멈춤이 발생하는 코드

private void LoadButton_Click(object sender, RoutedEventArgs e)
{
    LoadBigData();
}

private void LoadBigData()
{
    Thread.Sleep(5000);
}

증상

✔ 버튼 클릭 후 UI 멈춤
✔ 창 이동도 안됨

원인

UI Thread가 작업에 묶여 있음

3. async / await 사용

가장 간단한 해결 방법은 비동기 처리입니다.

private async void LoadButton_Click(object sender, RoutedEventArgs e)
{
    await Task.Run(() => LoadBigData());
}

✔ UI Thread 차단 없음
✔ 작업은 백그라운드 Thread에서 실행

4. UI 업데이트 문제

백그라운드 작업에서는

UI 요소를 직접 변경할 수 없습니다.

잘못된 코드

Task.Run(() =>
{
    StatusText.Text = "완료";
});

예외 발생

The calling thread cannot access this object

5. Dispatcher 사용

UI 업데이트는 반드시 UI Thread에서 실행해야 합니다.

Dispatcher.Invoke(() =>
{
    StatusText.Text = "완료";
});

또는

Application.Current.Dispatcher.Invoke(() =>
{
    StatusText.Text = "완료";
});

6. 실무 패턴 (추천 구조)

private async void LoadButton_Click(object sender, RoutedEventArgs e)
{
    StatusText.Text = "Loading...";

    var result = await Task.Run(() => LoadData());

    StatusText.Text = "Done";
}

✔ 데이터 처리 → 백그라운드
✔ UI 업데이트 → UI Thread

7. 실무에서 자주 하는 실수 1 — async void 남용

public async void LoadData()

문제

✔ 예외 처리 불가
✔ 디버깅 어려움

8. 실무에서 자주 하는 실수 2 — Task.Result 사용

var result = Task.Run(() => LoadData()).Result;

문제

UI Thread 다시 블로킹

9. Progress UI 업데이트

장시간 작업 시 진행 상태 표시

var progress = new Progress<int>(value =>
{
    ProgressBar.Value = value;
});

await Task.Run(() => LongWork(progress));

void LongWork(IProgress<int> progress)
{
    for(int i=0;i<=100;i++)
    {
        Thread.Sleep(50);
        progress.Report(i);
    }
}

✔ UI 안전 업데이트

10. 한 줄 핵심 정리

WPF UI는 한 개의 Thread만 사용한다.

무거운 작업은 반드시 백그라운드로 보내라.

WPF async await
WPF UI 멈춤 해결
WPF Dispatcher 사용법
WPF Task.Run
WPF 비동기 처리

[WPF 실무 22편] WPF Dialog / Modal 창 구조 (MVVM 친화적인 팝업 구현)

코드한입 — Fri, 6 Mar 2026 14:54:47 +0900

프로그램을 만들다 보면 확인창, 설정창, 경고 메시지 같은 팝업 UI가 필요합니다.
단순히 Window를 새로 띄우는 것처럼 보이지만,
MVVM 구조에서는 Dialog 처리 방식이 따로 존재합니다.

이번 글에서는

✔ Modal / Modeless 차이
✔ Dialog 창 구현 방법
✔ MVVM에서 Dialog 처리 패턴
✔ 실무에서 자주 하는 실수

를 정리합니다.

1. Modal vs Modeless 차이

Modal Dialog

var dialog = new SettingsWindow();
dialog.ShowDialog();

특징

✔ 현재 창을 막음
✔ 사용자가 Dialog 닫을 때까지 대기

예:

설정창
확인 메시지
파일 선택

Modeless Window

var win = new LogWindow();
win.Show();

특징

✔ 여러 창 동시에 사용 가능
✔ 작업 계속 진행 가능

예:

로그 창
모니터링 화면

2. 기본 Dialog 구현

Dialog Window 생성

Add → Window → ConfirmDialog.xaml

<Window Height="200" Width="350"
        WindowStartupLocation="CenterOwner"
        ResizeMode="NoResize">

    <Grid Margin="20">

        <TextBlock Text="삭제하시겠습니까?"
                   FontSize="16"
                   VerticalAlignment="Center"/>

        <StackPanel Orientation="Horizontal"
                    HorizontalAlignment="Right"
                    VerticalAlignment="Bottom">

            <Button Content="확인" Width="70" Margin="5" Click="Ok_Click"/>
            <Button Content="취소" Width="70" Margin="5" Click="Cancel_Click"/>

        </StackPanel>

    </Grid>

</Window>

3. Dialog 결과 반환

private void Ok_Click(object sender, RoutedEventArgs e)
{
    DialogResult = true;
}

private void Cancel_Click(object sender, RoutedEventArgs e)
{
    DialogResult = false;
}

사용:

var dialog = new ConfirmDialog();

if(dialog.ShowDialog() == true)
{
    DeleteItem();
}

✔ Dialog 결과 기반 처리

4. Owner 설정 (실무 중요)

Dialog는 항상 Owner를 지정하는 것이 좋습니다.

var dialog = new ConfirmDialog();
dialog.Owner = Application.Current.MainWindow;

dialog.ShowDialog();

이유

✔ 부모 창 위에 표시
✔ 작업 표시줄 중복 방지

5. 실무에서 자주 하는 실수 1 — DialogResult 직접 Close()

Close();

이렇게 하면

Dialog 결과를 받을 수 없습니다.

✔ 반드시 DialogResult 설정

6. 실무에서 자주 하는 실수 2 — ViewModel에서 Window 직접 생성

var dialog = new ConfirmDialog();
dialog.ShowDialog();

문제

ViewModel → View 참조

MVVM 구조 깨짐

7. MVVM Dialog Service 패턴

실무에서는 DialogService를 사용합니다.

Services/
 └ DialogService.cs

public class DialogService
{
    public bool ShowConfirm(string message)
    {
        var dialog = new ConfirmDialog();
        dialog.MessageText.Text = message;

        return dialog.ShowDialog() == true;
    }
}

ViewModel

if(_dialogService.ShowConfirm("삭제하시겠습니까?"))
{
    DeleteItem();
}

✔ MVVM 구조 유지

8. 실무 추천 Dialog 구조

Views/
 ├ Dialogs/
 │   ├ ConfirmDialog.xaml
 │   └ MessageDialog.xaml

Services/
 └ DialogService.cs

✔ 팝업 관리 중앙화
✔ 코드 재사용

9. 한 줄 핵심 정리

Dialog는 Window가 아니라 서비스로 관리하라.

WPF Dialog 구현
WPF ShowDialog 사용법
WPF Modal Window
WPF MVVM DialogService
WPF 확인 팝업

[WPF 실무 21편] WPF 화면 전환 구조 (Frame / Page / Navigation 패턴 완전 정리)

코드한입 — Thu, 5 Mar 2026 13:22:41 +0900

프로그램 규모가 커지면 하나의 Window 안에서 여러 화면을 전환해야 하는 경우가 많습니다.
메뉴 클릭 → 다른 화면 표시
설정 페이지 이동
검사 결과 화면 전환

이때 사용하는 것이 바로 WPF Navigation 구조 (Frame + Page) 입니다.

이번 글에서는
✔ Frame / Page 기본 개념
✔ 화면 전환 구현 방법
✔ MVVM 환경에서 사용하는 네비게이션 패턴
✔ 실무에서 자주 하는 실수
를 정리합니다.

1. WPF 화면 전환 기본 구조

WPF의 기본 화면 전환 구조는 다음과 같습니다.

Window
 └ Frame
     └ Page (화면)

즉 Window는 그대로 유지하고
Frame 안의 Page만 교체합니다.

✔ 메모리 효율적
✔ UI 전환 자연스러움

2. Frame 생성

<Window x:Class="MainWindow">

    <Grid>
        <Frame x:Name="MainFrame"/>
    
    </Grid>

</Window>

Frame은 화면을 표시하는 컨테이너입니다.

3. Page 생성

Visual Studio에서

Add → New Item → Page

예: HomePage.xaml

<Page>

    <Grid>
        <TextBlock Text="Home Screen"
                   FontSize="30"
                   HorizontalAlignment="Center"
                   VerticalAlignment="Center"/>
    </Grid>

</Page>

4. 코드에서 화면 전환

MainFrame.Navigate(new HomePage());

또는

MainFrame.Navigate(new SettingsPage());

✔ Frame 내부 Page 교체

5. XAML에서 초기 화면 설정

<Frame Source="Pages/HomePage.xaml"/>

앱 시작 시 해당 페이지 자동 로드됩니다.

6. 실무에서 자주 하는 실수 1 — Window를 계속 새로 생성

var win = new SettingsWindow();
win.Show();

문제

✔ Window 계속 증가
✔ 메모리 사용 증가
✔ UX 불편

해결

단일 Window + Frame 구조 사용

7. 실무에서 자주 하는 실수 2 — Page에서 Window 직접 접근

((MainWindow)Application.Current.MainWindow)

문제

MVVM 구조 깨짐

해결

NavigationService 사용

8. NavigationService 사용

Page 내부에서는 NavigationService를 사용할 수 있습니다.

NavigationService.Navigate(new SettingsPage());

✔ Window 참조 필요 없음

9. MVVM 네비게이션 패턴

실무에서는 NavigationService를 래핑해서 사용합니다.

예:

Services/
 └ NavigationService.cs

public class NavigationService
{
    private Frame _frame;

    public NavigationService(Frame frame)
    {
        _frame = frame;
    }

    public void Navigate(Page page)
    {
        _frame.Navigate(page);
    }
}

ViewModel에서 호출

_navigation.Navigate(new HomePage());

10. 뒤로가기 기능

Frame은 기본적으로 히스토리를 관리합니다.

MainFrame.GoBack();

✔ 브라우저처럼 이전 화면 이동 가능

11. 한 줄 핵심 정리

WPF 화면 전환은 Window가 아니라 Frame을 교체하는 구조다.

WPF 화면 전환
WPF Frame Page 사용법
WPF NavigationService
WPF 페이지 전환
WPF MVVM 네비게이션

[리눅스 프로그래밍 시리즈 8편] gcc 컴파일 구조 완전 이해: C 프로그램이 실행 파일이 되는 과정

코드한입 — Thu, 5 Mar 2026 13:20:23 +0900

목표: 리눅스에서 C 프로그램이 어떻게 컴파일되는지 이해한다
결과: gcc 컴파일 과정과 기본 빌드 구조를 이해한다

1. 왜 gcc 컴파일 구조를 알아야 할까?

리눅스에서 개발을 시작하면 가장 먼저 만나게 되는 도구가 gcc다.

많은 초보자는 단순히 이렇게만 사용한다.

gcc hello.c -o hello

하지만 실제로는 이 한 줄 안에서 여러 단계가 수행된다.

1) 전처리 (Preprocessing)
2) 컴파일 (Compilation)
3) 어셈블리 (Assembly)
4) 링크 (Linking)

이 구조를 이해하면

컴파일 오류 분석
라이브러리 문제 해결
빌드 시스템 이해

가 훨씬 쉬워진다.

2. 예제 프로그램 준비

먼저 간단한 C 프로그램을 만든다.

nano hello.c

내용 작성:

#include <stdio.h>

int main() {
    printf("Hello Linux!\n");
    return 0;
}

컴파일:

gcc hello.c -o hello
./hello

출력:

Hello Linux!

3. 전처리 단계 (Preprocessing)

전처리는 다음 작업을 수행한다.

#include 처리
#define 매크로 확장
주석 제거

전처리 결과 확인:

gcc -E hello.c

출력되는 코드는 매우 길다.

stdio.h 내용까지 모두 포함되기 때문.

4. 컴파일 단계 (Compilation)

C 코드를 어셈블리 코드로 변환한다.

gcc -S hello.c

생성 파일:

hello.s

이 파일은 CPU가 이해할 수 있는 어셈블리 코드다.

5. 어셈블리 단계 (Assembly)

어셈블리 코드를 오브젝트 파일로 변환한다.

gcc -c hello.c

생성 파일:

hello.o

이 파일은 아직 실행 파일이 아니다.

6. 링크 단계 (Linking)

오브젝트 파일과 라이브러리를 결합하여 실행 파일을 만든다.

gcc hello.o -o hello

여기서 printf 같은 함수는

표준 라이브러리(libc) 와 연결된다.

7. 컴파일 과정 한눈에 보기

hello.c
   │
   ▼
전처리
   │
   ▼
컴파일
   │
   ▼
어셈블리
   │
   ▼
hello.o
   │
   ▼
링크
   │
   ▼
hello (실행파일)

8. 자주 사용하는 gcc 옵션

디버그 정보 포함

gcc -g hello.c

→ gdb 디버깅 가능

경고 표시

gcc -Wall hello.c

코드 문제를 미리 발견 가능.

최적화

gcc -O2 hello.c

실행 성능 개선.

9. 여러 파일 컴파일

예:

main.c
math.c
math.h

컴파일:

gcc main.c math.c -o program

실무 프로젝트는 대부분 여러 파일로 구성된다.

10. 실무에서 중요한 포인트

개발이 커질수록 다음 문제가 발생한다.

파일 수 증가
컴파일 시간 증가
의존성 관리

이를 해결하기 위해 등장하는 것이

Makefile

다음 편에서 자세히 다룬다.

11. 8편 요약

gcc는 단순 컴파일러가 아니다
전처리 → 컴파일 → 어셈블리 → 링크 단계 존재
hello.c → hello.o → 실행 파일 생성
디버그(-g)와 경고(-Wall)는 필수 옵션

메인 키워드

gcc 사용법
리눅스 C 컴파일
gcc 컴파일 과정
리눅스 gcc 옵션

서브 키워드

gcc -Wall 의미
gcc -g 디버그
gcc 링크 과정
리눅스 C 빌드 구조

[리눅스 프로그래밍 시리즈 7편]sed와 awk 실전 정복: 로그를 '가공'하는 진짜 리눅스 실무 기술

코드한입 — Tue, 3 Mar 2026 12:14:54 +0900

목표: grep을 넘어서 로그를 수정·추출·가공할 수 있다
결과: 반복되는 로그 분석을 자동화할 수 있다

1. 왜 sed와 awk를 배워야 할까?

6편에서 우리는 grep으로 "찾기"를 배웠다.

하지만 실무에서는 단순 검색으로 끝나지 않는다.

특정 컬럼만 추출
문자열 치환
조건에 따라 다른 출력
로그 형식 재구성

이걸 가능하게 하는 도구가 바로 sed와 awk다.

2. sed 기본 개념 (Stream Editor)

sed는 텍스트를 "치환"하는 데 특화된 도구다.

기본 형태

sed 's/원본/변경/' 파일명

예:

sed 's/ERROR/WARNING/' server.log

ERROR를 WARNING으로 변경하여 출력.

※ 원본 파일은 수정되지 않음.

전체 치환 (g 옵션)

sed 's/ERROR/WARNING/g' server.log

파일 직접 수정 (-i 옵션)

sed -i 's/ERROR/WARNING/g' server.log

⚠ 실무에서는 백업 후 사용 권장

3. awk 기본 개념 (컬럼 처리 도구)

awk는 "공백 기준 컬럼 처리"에 강하다.

예제 로그

echo "2026-03-01 ERROR DatabaseFail" >> server.log

특정 컬럼만 출력

awk '{print $2}' server.log

$1 → 첫 번째 컬럼
$2 → 두 번째 컬럼

4. grep + awk 조합 (실무 핵심)

에러 발생 시간만 추출:

grep "ERROR" server.log | awk '{print $1}'

날짜만 출력 가능

5. 특정 조건 필터링

두 번째 컬럼이 ERROR인 줄만 출력:

awk '$2 == "ERROR" {print $0}' server.log

6. 로그 통계 계산

에러 횟수 세기:

awk '$2 == "ERROR" {count++} END {print count}' server.log

grep 없이도 가능

7. 실습: 로그 자동 분석 스크립트 만들기

nano analyze.sh

내용 작성:

#!/bin/bash

LOG=server.log

echo "총 에러 수:"
awk '$2 == "ERROR" {count++} END {print count}' $LOG

실행 권한 부여:

chmod +x analyze.sh
./analyze.sh

8. sed vs awk 차이 정리

구분sedawk

목적	문자열 치환	컬럼/조건 처리
사용 난이도	쉬움	중간
실무 활용	로그 치환	로그 분석/통계

9. 자주 하는 실수

sed -i 사용 후 원본 날림
awk에서 따옴표 오류
컬럼 구분자가 공백이 아닐 때 실수

10. 7편 요약

sed → 문자열 치환 도구
awk → 컬럼 분석 도구
grep + awk 조합은 실무 핵심
로그 자동화 스크립트 작성 가능

이제 텍스트 처리 단계는 거의 끝났다.

메인 키워드

리눅스 sed 사용법
리눅스 awk 사용법
리눅스 로그 분석 자동화
awk 컬럼 추출

서브 키워드

sed 문자열 치환
awk 조건 필터링
grep awk 조합
리눅스 로그 통계

[리눅스 프로그래밍 시리즈 6편]grep과 파이프(|) 완전 정복: 리눅스 로그 분석을 지배하는 핵심 기술

코드한입 — Tue, 3 Mar 2026 12:11:32 +0900

목표: grep과 파이프(|)를 이용해 원하는 데이터를 추출할 수 있다
결과: 서버 로그 분석을 혼자서 수행할 수 있다

1. 왜 grep과 파이프가 중요한가?

실무에서 리눅스를 쓰는 이유 중 하나는

"로그 분석" 때문이다.

서버 문제 발생 시 가장 먼저 하는 행동:

로그 파일 열기
특정 키워드 검색
에러 개수 확인
시간대별 분석

이 모든 작업의 중심이 바로 grep + 파이프(|) 다.

2. grep 기본 사용법

기본 형태

grep "검색어" 파일명

예:

grep "ERROR" server.log

server.log 파일에서 ERROR가 포함된 줄만 출력.

자주 쓰는 옵션

grep -i "error" server.log

i → 대소문자 무시

grep -n "ERROR" server.log

n → 줄 번호 표시

grep -r "ERROR" .

r → 하위 디렉토리까지 검색

3. 파이프(|)란 무엇인가?

파이프는 "앞 명령어의 출력 결과를 뒤 명령어의 입력으로 전달"한다.

형태:

명령어1 | 명령어2

4. grep + wc 조합 (실무에서 매우 많이 사용)

에러 개수 세기:

grep "ERROR" server.log | wc -l

wc -l → 줄 수 계산

서버 에러 발생 횟수 확인 가능

5. 여러 조건 필터링

예:

grep "ERROR" server.log | grep "2026-03-01"

특정 날짜의 에러만 필터링.

6. tail과 함께 실시간 로그 보기

tail -f server.log

실시간 로그 확인.

에러만 보고 싶다면:

tail -f server.log | grep "ERROR"

실시간 에러 모니터링 가능

7. 정규표현식 활용 (기초)

숫자 포함 줄 검색:

grep "[0-9]" file.txt

IP 주소 포함 줄 검색:

grep -E "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" access.log

8. 실습: 가짜 로그 만들고 분석하기

cd ~/linux-lab

로그 파일 생성:

echo "INFO Start" > server.log
echo "ERROR Database failed" >> server.log
echo "INFO Retry" >> server.log
echo "ERROR Timeout" >> server.log

에러 개수 확인:

grep "ERROR" server.log | wc -l

9. 실무 시나리오 예시

① 웹 서버 500 에러 분석

grep "500" access.log | wc -l

② 특정 사용자 요청 추적

grep "192.168.0.10" access.log

③ 특정 시간대 필터링

grep "14:3" access.log

10. 자주 하는 실수

로그를 직접 열어서 스크롤로 찾기
대소문자 구분 때문에 검색 실패
파이프 대신 && 사용

11. grep + 파이프 핵심 정리

grep → 텍스트 필터
| → 출력 연결
wc -l → 개수 계산
tail -f → 실시간 모니터링

이 네 가지 조합은 실무에서 매일 쓰인다.

메인 키워드

리눅스 grep 사용법
리눅스 파이프 사용법
리눅스 로그 분석
tail -f 사용법

서브 키워드

grep wc 조합
리눅스 로그 필터링
리눅스 실시간 로그 확인
리눅스 정규표현식

[WPF 실무 20편] WPF 애니메이션 기본 (Storyboard 실무 사용 패턴 완전 정리)

코드한입 — Tue, 3 Mar 2026 11:36:33 +0900

버튼이 자연스럽게 나타나고,
패널이 부드럽게 슬라이드되고,
화면 전환이 끊기지 않는 UI.

이 모든 것은 WPF의 Storyboard 애니메이션으로 구현됩니다.

이번 글에서는
✔ 기본 애니메이션 구조
✔ Storyboard 사용법
✔ 실무에서 많이 쓰는 패턴
✔ 성능 고려사항
을 정리합니다.

1. WPF 애니메이션 기본 개념

WPF 애니메이션은 다음 구조로 동작합니다.

Animation → Storyboard → Target 속성 변경

✔ DoubleAnimation → 숫자 변경
✔ ColorAnimation → 색상 변경
✔ ThicknessAnimation → Margin 변경

Storyboard는 여러 애니메이션을 묶는 컨테이너입니다.

2. 가장 기본적인 예제 (Opacity 페이드인)

<Grid>
    <Grid.Triggers>
        <EventTrigger RoutedEvent="Grid.Loaded">
            <BeginStoryboard>
                <Storyboard>
                    <DoubleAnimation
                        Storyboard.TargetProperty="Opacity"
                        From="0" To="1"
                        Duration="0:0:0.5"/>
                </Storyboard>
            </BeginStoryboard>
        </EventTrigger>
    </Grid.Triggers>
</Grid>

✔ 화면 로딩 시 0 → 1로 부드럽게 변경

3. 버튼 클릭 시 애니메이션 실행

<Button Content="Click">
    <Button.Triggers>
        <EventTrigger RoutedEvent="Button.Click">
            <BeginStoryboard>
                <Storyboard>
                    <DoubleAnimation
                        Storyboard.TargetProperty="Width"
                        To="200"
                        Duration="0:0:0.3"/>
                </Storyboard>
            </BeginStoryboard>
        </EventTrigger>
    </Button.Triggers>
</Button>

✔ 클릭 시 Width 변경

4. 코드에서 Storyboard 실행하기

<Window.Resources>
    <Storyboard x:Key="FadeOut">
        <DoubleAnimation
            Storyboard.TargetProperty="Opacity"
            To="0"
            Duration="0:0:0.5"/>
    </Storyboard>
</Window.Resources>

var sb = (Storyboard)FindResource("FadeOut");
sb.Begin(MyGrid);

✔ MVVM 구조에서도 활용 가능

5. 실무에서 많이 쓰는 패턴 1 — 슬라이드 패널

<TranslateTransform x:Key="SlideTransform"/>

<DoubleAnimation
    Storyboard.TargetProperty="(UIElement.RenderTransform).(TranslateTransform.X)"
    From="-300" To="0"
    Duration="0:0:0.3"/>

✔ 왼쪽에서 슬라이드 인
✔ 메뉴 패널 구현에 자주 사용

6. 실무에서 많이 쓰는 패턴 2 — Hover 확대 효과

<Style TargetType="Button">
    <Setter Property="RenderTransformOrigin" Value="0.5,0.5"/>
    <Setter Property="RenderTransform">
        <Setter.Value>
            <ScaleTransform/>
        </Setter.Value>
    </Setter>

    <Style.Triggers>
        <Trigger Property="IsMouseOver" Value="True">
            <Trigger.EnterActions>
                <BeginStoryboard>
                    <Storyboard>
                        <DoubleAnimation
                            Storyboard.TargetProperty="(UIElement.RenderTransform).(ScaleTransform.ScaleX)"
                            To="1.1" Duration="0:0:0.2"/>
                        <DoubleAnimation
                            Storyboard.TargetProperty="(UIElement.RenderTransform).(ScaleTransform.ScaleY)"
                            To="1.1" Duration="0:0:0.2"/>
                    </Storyboard>
                </BeginStoryboard>
            </Trigger.EnterActions>
        </Trigger>
    </Style.Triggers>
</Style>

✔ 버튼 Hover 시 자연스러운 확대 효과

7. 실무에서 자주 하는 실수 1 — Layout 속성 애니메이션 남발

Width / Height / Margin 변경은

→ 레이아웃 재계산 발생
→ 성능 저하

실무 권장

✔ RenderTransform 사용
✔ Opacity 사용

레이아웃 변경 대신 렌더링 레벨 애니메이션 사용

8. 실무에서 자주 하는 실수 2 — Storyboard 재사용 안 함

매번 코드에서 새로 생성하면

→ 성능 저하
→ GC 부담 증가

해결

✔ Resource에 등록 후 재사용

9. 애니메이션 성능 팁

✔ Duration 0.2~0.3초가 가장 자연스러움
✔ EasingFunction 사용하면 부드러움 증가
✔ 너무 많은 동시 애니메이션 금지

예:

<DoubleAnimation.EasingFunction>
    <CubicEase EasingMode="EaseOut"/>
</DoubleAnimation.EasingFunction>

10. 한 줄 핵심 정리

WPF 애니메이션은 레이아웃이 아니라 RenderTransform을 움직여라.

WPF Storyboard 사용법
WPF 애니메이션 예제
WPF DoubleAnimation
WPF RenderTransform 애니메이션
WPF 버튼 Hover 효과

[리눅스 프로그래밍 시리즈 5편] 리눅스 프로세스 완전 정복: ps, top, 백그라운드 실행, kill까지 실무 정리

코드한입 — Sun, 1 Mar 2026 11:55:54 +0900

목표: 리눅스에서 실행되는 프로그램(프로세스)의 구조를 이해한다
결과: 프로세스 문제를 스스로 분석하고 제어할 수 있다

1. 프로세스란 무엇인가?

리눅스에서 실행 중인 모든 프로그램은 프로세스(Process) 다.

터미널
웹 서버
데이터베이스
내가 실행한 C 프로그램

전부 프로세스다.

리눅스는 결국 "프로세스를 관리하는 OS"라고 봐도 된다.

2. 현재 실행 중인 프로세스 확인하기

① ps 명령어

ps

기본적으로 현재 터미널에서 실행 중인 프로세스만 표시된다.

② 전체 프로세스 보기 (실무에서 자주 사용)

ps aux

출력 예:

USER   PID  %CPU %MEM  VSZ   RSS TTY  STAT START  TIME COMMAND

중요 항목:

USER → 실행 사용자
PID → 프로세스 ID
%CPU → CPU 사용률
%MEM → 메모리 사용률
COMMAND → 실행 명령

PID는 반드시 기억해야 한다. (kill 할 때 사용)

3. 실시간 모니터링: top

top

실시간으로 CPU, 메모리 사용량을 확인할 수 있다.

종료: q

htop (추천)

sudo apt install htop
htop

더 직관적인 프로세스 관리 도구.

4. 포그라운드 vs 백그라운드 실행

① 포그라운드 실행

./hello

실행이 끝날 때까지 터미널 점유.

② 백그라운드 실행 (& 사용)

./hello &

출력 예:

[1] 2345

2345 = PID

③ 실행 중인 작업 확인

jobs

④ 다시 포그라운드로 가져오기

fg %1

5. 프로세스 종료하기

① 정상 종료 요청

kill PID

기본적으로 SIGTERM(15) 신호 전송.

② 강제 종료

kill -9 PID

-9 = SIGKILL

⚠ 주의: 강제 종료는 마지막 수단

6. 실습: 프로세스 직접 다뤄보기

sleep 100

다른 터미널에서:

ps aux | grep sleep
kill PID

7. 프로세스 상태 이해 (STAT 컬럼)

ps aux 출력에서 STAT 값 예:

R → Running
S → Sleeping
Z → Zombie

Zombie 프로세스란?

부모 프로세스가 자식 종료 상태를 회수(wait)하지 않은 상태.

시스템 프로그래밍에서 fork/exec 배울 때 등장.

8. nice와 우선순위 조정

nice -n 10 ./program

값이 클수록 우선순위 낮음.

기존 프로세스 변경:

renice 5 -p PID

9. 실무에서 자주 겪는 상황

① 서버 CPU 100% 사용

top

원인 프로세스 확인 → 필요 시 kill

② 포트가 이미 사용 중

sudo netstat -tulpn

PID 확인 후 종료

③ 백그라운드 작업이 멈춘 것처럼 보임

jobs 확인 후 fg

10. 자주 하는 실수

무조건 kill -9 사용
root 권한으로 모든 프로세스 종료
PID 잘못 확인하고 다른 프로세스 종료

11. 프로세스 관리 핵심 정리

ps aux → 전체 프로세스 확인
top → 실시간 모니터링
kill PID → 종료 요청
kill -9 PID → 강제 종료
jobs / fg / & → 작업 제어

리눅스 운영에서 프로세스 제어는 기본기다.

메인 키워드

리눅스 프로세스
ps aux 사용법
리눅스 kill 명령어
리눅스 top 사용법

서브 키워드

리눅스 백그라운드 실행
리눅스 jobs 명령어
리눅스 zombie 프로세스
리눅스 nice renice

[리눅스 프로그래밍 시리즈 4편] 리눅스 권한 완전 정복: chmod, chown, sudo, 실무에서 진짜 쓰는 개념 정리

코드한입 — Sun, 1 Mar 2026 11:19:18 +0900

목표: 리눅스 권한 구조를 완전히 이해한다
결과: 권한 문제를 스스로 해결할 수 있다

1. 리눅스에서 가장 많이 막히는 지점 = 권한

리눅스를 쓰다 보면 반드시 보게 되는 메시지:

Permission denied

초보자는 당황한다.

하지만 실무에서는 권한을 이해하지 못하면

서버 설정 변경 불가
파일 수정 불가
서비스 실행 실패
보안 사고 발생

으로 이어진다.

권한은 선택이 아니라 필수다.

2. 리눅스 권한 구조의 핵심 개념

리눅스 파일에는 세 가지 주체가 있다.

1) Owner (소유자)
2) Group (그룹)
3) Others (그 외 사용자)

그리고 각각에 대해 세 가지 권한이 있다.

r (read) : 읽기
w (write) : 쓰기
x (execute) : 실행

3. ls -l로 권한 읽는 법

ls -l

예시 출력:

-rwxr-xr-- 1 sujin sujin  1200 Jun 10 10:00 test.sh

구조 분석:

- rwx r-x r--
  │   │   │
  │   │   └─ Others
  │   └───── Group
  └──────── Owner

첫 글자: 파일 타입
rwx: 소유자 권한
r-x: 그룹 권한
r--: 기타 사용자 권한

4. chmod 사용법 (권한 변경)

방법 ① 기호 방식

chmod u+x file.sh

u = owner
g = group
o = others
a = all

예:

chmod go-w test.txt

방법 ② 숫자 방식 (실무에서 더 많이 사용)

권한 숫자 체계:

r = 4
w = 2
x = 1

예:

chmod 755 script.sh

의미:

7 = 4+2+1 (rwx)
5 = 4+1 (r-x)
5 = 4+1 (r-x)

5. chown (소유자 변경)

sudo chown user:group file.txt

예:

sudo chown sujin:sujin test.txt

6. 디렉토리 권한의 특별한 점

디렉토리에서 x 권한은

"그 안으로 들어갈 수 있는 권한"

예:

chmod 700 private_folder

소유자만 접근 가능.

7. sudo의 의미

sudo는 관리자 권한으로 명령 실행.

sudo apt update

주의:

습관적으로 sudo 남발 금지
모든 파일을 777로 만드는 행위 금지

8. 절대 하면 안 되는 실수

chmod 777

chmod 777 file.txt

모든 사용자에게 읽기/쓰기/실행 허용.

보안 사고의 지름길

9. 실습: 권한 직접 테스트

cd ~/linux-lab

echo "secret" > secret.txt
chmod 600 secret.txt
ls -l secret.txt

600 의미:

소유자: rw
그룹: 없음
기타: 없음

10. 실무에서 자주 보는 상황

① 웹 서버가 파일을 못 읽는 경우

→ 웹 서버 실행 계정 확인
→ 그룹 권한 확인

② SSH 키 권한 오류

Permissions are too open

해결:

chmod 600 ~/.ssh/id_rsa

11. 권한 문제 해결 순서

1) ls -l 로 현재 권한 확인
2) 소유자 확인
3) 그룹 확인
4) 필요한 최소 권한만 부여

12. 4편 요약

권한은 Owner / Group / Others 구조
chmod 숫자 방식 필수 숙지
777은 금지
디렉토리 x 권한의 의미 이해
sudo 남발 금지

메인 키워드

리눅스 권한
chmod 사용법
chown 사용법
리눅스 permission denied 해결

서브 키워드

리눅스 755 의미
리눅스 777 위험성
리눅스 파일 권한 구조
리눅스 sudo 사용법

[리눅스 프로그래밍 시리즈 3편] 리눅스 파일 시스템 완전 정복: 경로, 구조, 링크, 실무 개념까지 한 번에

코드한입 — Fri, 27 Feb 2026 10:30:35 +0900

목표: 리눅스 파일 시스템의 구조를 정확히 이해한다
결과: 경로/권한/링크 개념을 실무 수준으로 이해

1. 리눅스 파일 시스템이 중요한 이유

리눅스를 공부하다 막히는 가장 큰 이유는

"경로가 헷갈려서"
"파일이 어디 있는지 몰라서"
"권한 때문에 접근이 안 돼서"

리눅스는 모든 것이 파일이다.

설정 파일
장치(device)
프로세스 정보
네트워크 정보

따라서 파일 시스템 구조를 이해하면
리눅스의 절반을 이해한 것이다.

2. 리눅스 디렉토리 구조 한눈에 보기

루트 디렉토리부터 시작한다.

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── proc
├── root
├── tmp
├── usr
└── var

이 구조는 대부분의 배포판에서 거의 동일하다.

3. 핵심 디렉토리 설명 (실무 기준)

/ (루트)

모든 파일의 시작점

/home

사용자 계정 폴더

예:

/home/sujin

우리가 작업하는 공간

/etc

설정 파일 저장 위치

예:

/etc/passwd
/etc/ssh/sshd_config

서버 문제 생기면 자주 보게 됨

/var

로그 파일 저장 위치

예:

/var/log

로그 분석할 때 반드시 사용

/usr

프로그램 설치 위치

/tmp

임시 파일
재부팅 시 삭제될 수 있음

4. 절대 경로 vs 상대 경로

절대 경로

루트(/)부터 시작

/home/user/linux-lab

상대 경로

현재 위치 기준

../
./file.txt

5. 경로 실습

pwd
ls /
cd /home
ls
cd ~
pwd

~ 는 현재 사용자 홈 디렉토리

6. 파일 확인 기본 명령어

ls
ls -l
ls -al

옵션 설명:

l → 상세 정보
a → 숨김 파일 포함

7. 숨김 파일이란?

. 으로 시작하는 파일

예:

.bashrc
.gitconfig

설정 파일이 대부분 숨김 처리됨

8. 하드 링크 vs 심볼릭 링크

심볼릭 링크 (바로가기 개념)

ln -s original.txt link.txt

하드 링크

ln original.txt hardlink.txt

차이점:

구분심볼릭 링크하드 링크

원본 삭제 시	같이 깨짐	유지됨
다른 파티션	가능	불가능

실무에서는 대부분 심볼릭 링크 사용

9. 파일 타입 이해

ls -l

맨 앞 글자 의미:

- : 일반 파일
d : 디렉토리
l : 링크
c : 문자 장치
b : 블록 장치

리눅스는 장치도 파일로 관리한다.

10. 실무 미션

~/linux-lab 이동
test.txt 생성
심볼릭 링크 생성
원본 삭제 후 링크 확인

cd ~/linux-lab
echo "hello" > test.txt
ln -s test.txt link.txt
rm test.txt
cat link.txt

왜 에러가 나는지 생각해보기.

11. 자주 하는 실수

절대 경로와 상대 경로 혼동
sudo 없이 /etc 수정 시도
/tmp 파일 영구 저장 착각

12. 3편 요약

리눅스는 모든 것이 파일
/home, /etc, /var 구조 중요
절대/상대 경로 구분 필수
심볼릭 링크와 하드 링크 차이 이해

[WPF 실무 19편] WPF 다크모드 구현 (런타임 테마 전환 구조 완전 정리)

코드한입 — Fri, 27 Feb 2026 10:27:30 +0900

요즘 대부분의 프로그램은 다크모드를 지원합니다.
단순히 배경색만 바꾸는 것이 아니라,
전체 테마 구조를 전환할 수 있어야 진짜 실무 구현입니다.

이번 글에서는 WPF에서
✔ 라이트 / 다크 모드 전환
✔ 런타임 테마 변경
✔ ResourceDictionary 기반 테마 구조
를 실무 기준으로 정리합니다.

1. 다크모드를 단순 색 변경으로 구현하면 안 되는 이유

잘못된 방식

Background="Black"
Foreground="White"

이 방식은

컨트롤마다 개별 수정 필요
유지보수 어려움
확장성 없음

실무에서는 반드시 테마 구조로 관리해야 합니다.

2. 테마 파일 분리하기

1) LightTheme.xaml


    #FFFFFF
    #222222

2) DarkTheme.xaml


    #1E1E1E
    #F0F0F0

3. App.xaml 기본 테마 적용

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="Themes/LightTheme.xaml"/>
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Application.Resources>

4. 런타임 테마 변경 구현

public static class ThemeManager
{
    public static void ApplyTheme(string themeName)
    {
        var dict = new ResourceDictionary();
        dict.Source = new Uri($"Themes/{themeName}.xaml", UriKind.Relative);

        Application.Current.Resources.MergedDictionaries.Clear();
        Application.Current.Resources.MergedDictionaries.Add(dict);
    }
}

사용:

ThemeManager.ApplyTheme("DarkTheme.xaml");

✔ 즉시 전체 UI 변경
✔ 앱 재시작 불필요

5. XAML에서 브러시 사용 방법

<Grid Background="{DynamicResource BackgroundBrush}">
    <TextBlock Text="Hello"
               Foreground="{DynamicResource ForegroundBrush}"/>
</Grid>

⚠ 반드시 DynamicResource 사용해야 런타임 변경 반영됩니다.

6. 실무에서 자주 하는 실수 1 — StaticResource 사용

Background="{StaticResource BackgroundBrush}"

증상

테마 바꿔도 UI 안 바뀜

해결

Background="{DynamicResource BackgroundBrush}"

7. 실무에서 자주 하는 실수 2 — 리소스 전체 Clear()

Application.Current.Resources.MergedDictionaries.Clear();

이렇게 하면

기존 공통 스타일도 삭제됨

실무 추천 구조

Resources/
 ├ BaseStyles.xaml
 ├ LightTheme.xaml
 └ DarkTheme.xaml

그리고 BaseStyles는 유지한 채
테마만 교체하도록 구성하는 것이 안전합니다.

8. 실무 추천 테마 구조

✔ 색상만 테마 파일에 정의
✔ 스타일은 BaseStyles에서 정의
✔ 브러시 키는 동일하게 유지
✔ UI는 DynamicResource로 참조

이 구조가 확장성과 유지보수에 가장 좋습니다.

9. 고급 팁 — 사용자 설정 저장

사용자가 선택한 테마를

Settings 파일
Registry
JSON 파일

에 저장하고
앱 시작 시 자동 적용하면 완성도 ↑

10. 한 줄 핵심 정리

다크모드는 색을 바꾸는 게 아니라

리소스를 교체하는 것이다.

WPF 다크모드 구현
WPF 테마 전환
WPF 런타임 테마 변경
WPF DynamicResource 사용법
WPF ResourceDictionary 테마

[리눅스 프로그래밍 시리즈 2편] 리눅스 실습 환경 만들기 완벽 가이드 (WSL2 설치부터 개발 세팅까지)

코드한입 — Thu, 26 Feb 2026 17:23:44 +0900

대상: Windows 사용자 기준
목표: 리눅스 프로그래밍을 위한 안정적인 실습 환경을 구축한다
결과: C 컴파일 및 개발 준비 완료 상태

1. 왜 실습 환경이 중요한가?

리눅스 공부에서 가장 많이 망하는 지점이 바로 여기다.

환경이 불안정하다
설치가 꼬인다
패키지가 충돌한다
뭔가 안 되는데 이유를 모른다

이러면 학습 집중력이 무너진다.

따라서 이번 편에서는 가장 현실적이고 안정적인 개발 환경 구성 방법을 다룬다.

2. 리눅스를 설치하는 방법 3가지 비교

① WSL2 (가장 추천 )

Windows 안에서 리눅스를 실행하는 방식

장점

가볍고 빠름
설치 간단
VSCode 연동 쉬움
Windows 파일 접근 가능

단점

완전한 커널 제어는 제한적
네트워크 실습 일부 제약

대부분의 개발 학습에는 충분하며 가장 추천

② 가상머신 (VirtualBox / VMware)

장점

실제 리눅스 서버와 거의 동일
네트워크 실습 가능

단점

무겁다
메모리 많이 사용

서버 운영 실습까지 할 경우 추천

③ 듀얼부팅

장점

완전한 리눅스 환경

단점

설치 복잡
데이터 손상 위험

초보자 비추천

3. WSL2 설치 방법 (Windows 10/11)

1단계: PowerShell 관리자 실행

wsl --install

설치 후 재부팅.

2단계: 설치 확인

wsl -l -v

Ubuntu가 있고 Version이 2인지 확인.

3단계: 리눅스 접속

wsl

또는 시작 메뉴 → Ubuntu 실행

처음 실행 시 사용자 계정 생성.

4. 기본 패키지 세팅 (필수)

리눅스 접속 후 실행:

sudo apt update
sudo apt upgrade -y
sudo apt install build-essential git curl vim net-tools -y

각 패키지 설명

build-essential → gcc, make 포함
git → 소스 관리
curl → 네트워크 테스트
vim → 텍스트 편집
net-tools → 네트워크 확인

5. 개발자 기본 환경 설정

① 실습 폴더 생성

mkdir -p ~/linux-lab
cd ~/linux-lab

② Git 사용자 정보 설정

git config --global user.name "YourName"
git config --global user.email "you@example.com"

③ alias 설정 (생산성 향상)

nano ~/.bashrc

아래 추가:

alias ll='ls -alF'
alias gs='git status'
alias ..='cd ..'

적용:

source ~/.bashrc

6. VSCode 연동 (강력 추천)

VSCode 설치
Remote - WSL 확장 설치
WSL 터미널에서 실행

code .

이제 리눅스 환경에서 바로 코드 작성 가능.

7. C 컴파일 테스트 (환경 검증)

nano hello.c

내용 입력:

#include <stdio.h>

int main() {
    printf("Hello Linux!\n");
    return 0;
}

컴파일 및 실행:

gcc hello.c -o hello
./hello

정상 출력되면 환경 구축 성공.

8. 자주 발생하는 오류 해결

sudo 권한 문제

groups

sudo 그룹 포함 여부 확인.

apt update 실패

네트워크 상태 확인:

ping google.com

gcc 명령어 없음

sudo apt install build-essential -y

9. WSL2 vs VM 선택 가이드 정리

목적추천

리눅스 기초 공부	WSL2
C 시스템 프로그래밍	WSL2
네트워크 서버 실습	VM
실제 서버 운영 연습	VM

10. 2편 요약

가장 현실적인 선택은 WSL2
필수 패키지: build-essential
hello.c 컴파일로 환경 검증
alias 설정으로 생산성 향상

이제 리눅스 개발을 시작할 준비가 완료되었다.

리눅스 설치 방법
WSL2 설치 방법
리눅스 개발 환경 구축
리눅스 프로그래밍 환경 세팅
Ubuntu WSL 설치

Windows에서 리눅스 설치
WSL2 Ubuntu 설치 가이드
리눅스 C 컴파일 환경 만들기
build-essential 설치
리눅스 gcc 설치 방법
리눅스 개발자 세팅
VSCode WSL 연동 방법

[WPF 실무 18편] WPF 창 테두리 제거 + 커스텀 타이틀바 구현 (드래그 이동까지 완전 정리)

코드한입 — Thu, 26 Feb 2026 14:55:34 +0900

기본 Window 테두리가 마음에 들지 않거나,
장비 UI / 기업용 프로그램처럼 완전한 커스텀 디자인이 필요할 때가 있습니다.

이럴 때 사용하는 것이 바로
WindowStyle 제거 + 커스텀 타이틀바 구현입니다.

이번 글에서는 창 테두리 제거, 드래그 이동, 최소화/최대화 버튼 구현까지 실무 기준으로 정리합니다.

1. 기본 창 테두리 제거하기

가장 먼저 Window 기본 스타일을 제거합니다.

<Window
    WindowStyle="None"
    ResizeMode="CanResize"
    Background="White">
</Window>

✔ WindowStyle=None → 기본 타이틀바 제거
✔ ResizeMode=CanResize → 크기 조절 유지 가능

이제 완전한 빈 창이 됩니다.

2. 커스텀 타이틀바 만들기

상단에 Grid 또는 Border를 만들어 직접 타이틀 영역을 구성합니다.

<Grid>
    <Border Background="#2C3E50"
            Height="40"
            MouseLeftButtonDown="TitleBar_MouseDown">
        <Grid>
            <TextBlock Text="My Application"
                       VerticalAlignment="Center"
                       Margin="15,0"
                       Foreground="White"/>
        </Grid>
    </Border>

    <Grid Margin="0,40,0,0">
        <!-- 실제 콘텐츠 영역 -->
    </Grid>
</Grid>

3. 창 드래그 이동 구현

타이틀바 영역에서 DragMove()를 호출합니다.

private void TitleBar_MouseDown(object sender, MouseButtonEventArgs e)
{
    if (e.LeftButton == MouseButtonState.Pressed)
        this.DragMove();
}

✔ 기본 타이틀바와 동일한 이동 기능 구현

4. 최소화 / 최대화 / 닫기 버튼 구현

XAML 버튼 추가

<StackPanel Orientation="Horizontal"
            HorizontalAlignment="Right">
    <Button Content="_" Click="Minimize_Click"/>
    <Button Content="□" Click="Maximize_Click"/>
    <Button Content="X" Click="Close_Click"/>
</StackPanel>

CodeBehind

private void Minimize_Click(object sender, RoutedEventArgs e)
{
    WindowState = WindowState.Minimized;
}

private void Maximize_Click(object sender, RoutedEventArgs e)
{
    WindowState = WindowState == WindowState.Maximized
        ? WindowState.Normal
        : WindowState.Maximized;
}

private void Close_Click(object sender, RoutedEventArgs e)
{
    Close();
}

5. 실무에서 자주 하는 실수 1 — ResizeMode=None 설정

ResizeMode="NoResize"

증상

창 크기 조절 불가
최대화 동작 이상

해결

ResizeMode="CanResize"

6. 실무에서 자주 하는 실수 2 — 최대화 시 화면 잘림

WindowStyle=None 상태에서 최대화하면
작업 표시줄을 침범하는 경우가 있습니다.

해결 방법

WindowStyle="None"
AllowsTransparency="False"

또는

this.MaxHeight = SystemParameters.WorkArea.Height;

작업 표시줄 영역 고려 필요

7. 실무에서 자주 하는 실수 3 — 드래그 이동 안 됨

DragMove()는 반드시

✔ 마우스 왼쪽 버튼 상태에서
✔ MouseDown 이벤트에서 호출해야 함

조건이 맞지 않으면 예외 발생

8. 실무 추천 구조

✔ WindowStyle=None
✔ 상단 Border를 타이틀바로 사용
✔ DragMove 구현
✔ 버튼 직접 제어
✔ ResizeMode=CanResize 유지

이 구조가 가장 안정적입니다.

9. 한 줄 핵심 정리

기본 타이틀바를 제거하면
모든 창 동작을 직접 구현해야 한다.

WPF 창 테두리 제거
WPF WindowStyle None
WPF 커스텀 타이틀바
WPF DragMove 사용법
WPF 창 이동 구현

[리눅스 프로그래밍 시리즈 1편] 리눅스 프로그래밍 입문 가이드: 기초부터 실무까지 제대로 배우는 방법 (로드맵 총정리)

코드한입 — Thu, 26 Feb 2026 13:36:39 +0900

대상: 리눅스를 처음 배우는 개발자 / 서버 개발 준비생 / 시스템 엔지니어 지망생
목표: 리눅스 기초부터 시스템 프로그래밍, 실무 운영까지 이어지는 현실적인 학습 로드맵 제시

1. 리눅스 프로그래밍, 왜 배워야 할까?

"나는 윈도우 개발자인데 리눅스까지 알아야 할까?"

결론부터 말하면, 개발을 오래 할 생각이라면 반드시 만나게 된다.

리눅스가 사용되는 영역

웹 서버 (대부분 리눅스 기반)
클라우드 서버 (AWS, GCP, Azure 대부분 Linux)
Docker / Kubernetes
네트워크 장비
임베디드 시스템
보안/해킹/포렌식

실무에서 자주 겪는 상황:

서버 로그가 이상하다 → SSH 접속해서 직접 분석
프로세스가 계속 죽는다 → top / ps로 상태 확인
메모리 누수 의심 → 시스템 콜 추적
서비스 자동 재시작 필요 → systemd 설정

즉, 리눅스는 단순한 OS가 아니라
**“개발자가 시스템을 이해하게 만드는 도구”**다.

2. 리눅스를 배우면 생기는 실력 차이

① 시스템 구조를 이해하는 능력

리눅스를 배우면 다음이 보이기 시작한다:

파일이 실제로 어떻게 저장되는지
프로세스가 어떻게 생성되는지
메모리가 어떻게 관리되는지
프로그램이 OS와 어떻게 통신하는지

이건 단순 문법 공부와 차원이 다르다.

② 문제 해결 능력 상승

리눅스는 GUI보다 CLI 중심이다.

텍스트 기반으로 문제를 분석하고 조합한다.

예:

grep "ERROR" server.log | wc -l

이 한 줄은

로그에서 ERROR만 찾고
그 개수를 세는 작업을 자동으로 처리한다.

실무에서는 이런 한 줄이 몇 시간을 줄인다.

③ 자동화 능력

리눅스는 반복 작업을 스크립트로 만들 수 있다.

예:

for file in *.log
do
  grep "ERROR" "$file"
done

반복 작업 → 자동화 → 생산성 향상

3. 이 시리즈의 최종 목표 (완주 시 도달 수준)

이 시리즈를 끝내면 다음이 가능해야 한다.

✔ 기본기

리눅스 터미널 자연스럽게 사용
파일/권한 구조 이해
프로세스 제어 가능

✔ 개발 능력

gcc로 C 코드 컴파일
make로 빌드 관리
gdb로 디버깅
쉘 스크립트 작성

✔ 시스템 프로그래밍

open/read/write 이해
fork/exec 구조 이해
pthread 멀티스레드 작성
TCP 소켓 서버 구현

✔ 실무 운영

systemd 서비스 등록
로그 분석
SSH 키 설정
기본 배포 구조 이해

단순 명령어 정리가 아니다.

리눅스 기반 개발자가 되는 과정이다.

4. 리눅스 학습 순서 (실패하지 않는 로드맵)

많이 하는 실수:

"소켓부터 배워야지!"

절대 안 된다.

기초 체력이 없으면 시스템 프로그래밍에서 반드시 막힌다.

Part 1. 리눅스 기초 체력

파일 시스템 구조
경로 개념
권한 (chmod, chown)
프로세스 (ps, top)
텍스트 처리 (grep, sed, awk)

여기서 50% 이상이 결정된다.

Part 2. 개발 도구 체인

gcc 컴파일
라이브러리 링크
make 빌드 자동화
gdb 디버깅
쉘 스크립트

개발자다운 리눅스 사용 단계

Part 3. 시스템 프로그래밍

파일 디스크립터
시스템 콜
fork / exec
pthread
TCP 소켓
epoll

이 단계부터 “리눅스 프로그래머”

Part 4. 실무 운영

systemd
로그 관리
SSH 보안
배포 기본

여기까지 오면 실무 투입 가능

5. 오늘 바로 시작하는 실습 (환경 없어도 가능)

① 실험용 폴더 만들기

mkdir -p ~/linux-lab
cd ~/linux-lab
pwd

-p 옵션은 상위 폴더가 없어도 생성한다.

② 현재 시스템 정보 확인

uname -a
whoami
pwd

uname : 커널 정보
whoami : 현재 사용자
pwd : 현재 경로

③ 도움말 보는 습관 만들기

man ls
ls --help

리눅스는 외우는 게 아니다.

찾는 능력이 곧 실력이다.

6. 초보자가 반드시 버려야 할 생각

"명령어를 다 외워야 하나요?"
→ 아니다. 필요한 걸 찾는 능력이 중요하다.

"GUI가 더 편한데요?"
→ 서버에는 GUI가 없다.

"리눅스는 어려워 보이는데요"
→ 처음엔 낯설 뿐이다. 구조를 이해하면 오히려 단순하다.

7. 오늘의 미션 (기록 습관 만들기)

~/linux-lab 생성
notes.txt 파일 생성
오늘 실행한 명령어 5개 기록

echo "uname, whoami, pwd, man, mkdir" > notes.txt
cat notes.txt

이 파일은 시리즈가 끝날 때까지 계속 누적한다.

나만의 리눅스 치트시트가 된다.

8. 1편 요약

리눅스는 개발·서버 환경의 표준
단순 명령어 학습이 아니라 시스템 이해가 핵심
학습 순서가 매우 중요
오늘부터 실험 폴더 + 기록 습관 시작

리눅스 프로그래밍 입문
리눅스 기초 공부 방법
리눅스 개발자 로드맵
리눅스 시스템 프로그래밍
리눅스 공부 순서
리눅스 실무 준비

[WPF 실무 17편] WPF 메모리 누수 원인과 해결 방법 (이벤트, 바인딩, 가상화 이슈 완전 정리)

코드한입 — Thu, 26 Feb 2026 13:25:18 +0900

WPF 프로젝트를 오래 실행하면 메모리가 계속 증가하는 현상을 경험한 적이 있을 겁니다.
창을 닫았는데도 메모리가 내려가지 않는다면, 거의 확실하게 메모리 누수입니다.

이번 글에서는 WPF에서 자주 발생하는 메모리 누수 원인과 실무에서 바로 적용 가능한 해결 방법을 정리합니다.

1. WPF에서 메모리 누수가 발생하는 이유

WPF는 이벤트, 바인딩, 시각적 트리(Visual Tree)가 복잡하게 연결된 구조입니다.

다음과 같은 경우 객체가 GC 대상이 되지 않습니다.

✔ 이벤트 구독 해제 안 함
✔ 정적 이벤트 사용
✔ CollectionView 참조 유지
✔ 가상화 꺼진 상태에서 대량 UI 유지

2. 실무에서 가장 흔한 원인 1 — 이벤트 해제 안 함

잘못된 코드

public MainWindow()
{
    InitializeComponent();
    SomeService.DataChanged += OnDataChanged;
}

창을 닫아도

→ SomeService가 MainWindow를 계속 참조
→ GC 수거 안 됨

해결 방법

protected override void OnClosed(EventArgs e)
{
    SomeService.DataChanged -= OnDataChanged;
    base.OnClosed(e);
}

이벤트는 반드시 해제해야 합니다.

3. 원인 2 — 정적(static) 이벤트 사용

잘못된 코드

public static event EventHandler GlobalEvent;

정적 이벤트는 앱 종료 전까지 살아있습니다.

→ 구독 객체 절대 해제 안 됨

해결

✔ 가능하면 static 이벤트 사용 금지
✔ WeakEvent 패턴 사용 고려

4. 원인 3 — CollectionView 참조 유지

private ICollectionView _view;

View가 닫혀도 ViewModel이 살아있으면
CollectionView가 Items를 계속 참조

→ 메모리 해제 안 됨

해결

_view.Filter = null;
_view = null;

또는 ViewModel 정리 시 참조 제거

5. 원인 4 — ScrollViewer로 가상화 끄기

<ScrollViewer>
    <DataGrid ItemsSource="{Binding Items}"/>
</ScrollViewer>

가상화 꺼짐 → 모든 Row 생성
→ 메모리 급증

해결

외부 ScrollViewer 제거

6. 원인 5 — 대용량 이미지 바인딩

<Image Source="{Binding ImageData}"/>

BitmapImage를 캐시 안 하면
메모리 해제 지연

해결

bitmap.CacheOption = BitmapCacheOption.OnLoad;
bitmap.Freeze();

Freeze() 호출 필수

7. 원인 6 — DispatcherTimer 미정리

DispatcherTimer timer = new DispatcherTimer();
timer.Tick += OnTick;
timer.Start();

Timer가 Window를 계속 참조

해결

timer.Stop();
timer.Tick -= OnTick;

8. 메모리 누수 확인 방법

✔ Visual Studio Diagnostic Tools
✔ dotMemory
✔ GC.Collect() 테스트 (임시 확인용)

창 닫은 뒤에도 객체가 남아있으면 누수입니다.

9. 실무 체크리스트

✔ 이벤트 해제
✔ static 이벤트 최소화
✔ Timer 정리
✔ 가상화 유지
✔ CollectionView 참조 해제
✔ 이미지 Freeze 처리

이 6가지 점검하면 대부분 해결됩니다.

10. 한 줄 핵심 정리

WPF 메모리 누수의 90%는 이벤트 참조 문제다.

WPF 메모리 누수
WPF GC 안됨
WPF 이벤트 해제
WPF static 이벤트 문제
WPF DataGrid 메모리 증가

[WPF 실무 16편] WPF 프로젝트 구조 추천 (실무 폴더 설계 완전 정리)

코드한입 — Thu, 26 Feb 2026 10:43:56 +0900

프로젝트 초반에 구조를 제대로 잡지 않으면
기능이 늘어날수록 코드가 엉키고 유지보수가 어려워집니다.

WPF는 특히 MVVM 기반이기 때문에
초기 폴더 구조 설계가 매우 중요합니다.

이번 글에서는 실무에서 가장 많이 사용하는 WPF 프로젝트 구조와
대형 프로젝트 기준 폴더 설계 방법을 정리합니다.

1. 왜 프로젝트 구조가 중요한가?

✔ 기능 추가 시 충돌 방지
✔ 코드 위치 예측 가능
✔ 협업 시 생산성 향상
✔ 테스트 구조 분리 용이

특히 MVVM 구조에서는
View / ViewModel / Model 분리가 핵심입니다.

2. 기본 MVVM 구조 (소형 프로젝트)

MyProject/
 ├ Views/
 ├ ViewModels/
 ├ Models/
 ├ Resources/
 └ App.xaml

각 폴더 역할

Views → XAML 화면
ViewModels → 로직 처리
Models → 데이터 구조
Resources → 스타일, 템플릿, Converter

소형 프로젝트에서는 이 정도면 충분합니다.

3. 실무 표준 구조 (중형 프로젝트)

MyProject/
 ├ Core/
 │   ├ BaseViewModel.cs
 │   ├ RelayCommand.cs
 │   └ Services/
 │
 ├ Models/
 │
 ├ ViewModels/
 │   ├ MainViewModel.cs
 │   └ DataGridViewModel.cs
 │
 ├ Views/
 │   ├ MainView.xaml
 │   └ DataGridView.xaml
 │
 ├ Resources/
 │   ├ Styles.xaml
 │   ├ DataGridStyles.xaml
 │   └ Converters.xaml
 │
 └ App.xaml

핵심 포인트

✔ Core → 공통 로직
✔ Services → 파일/DB/메시지 처리
✔ Resources → 스타일 전역 관리

4. 대형 프로젝트 구조 (실무 장비 UI 기준)

MyProject/
 ├ Modules/
 │   ├ Inspection/
 │   │   ├ Views/
 │   │   ├ ViewModels/
 │   │   └ Models/
 │   ├ Monitoring/
 │   └ Settings/
 │
 ├ Core/
 ├ Infrastructure/
 ├ Resources/
 └ App.xaml

✔ 기능 단위 모듈화
✔ 독립 개발 가능
✔ 유지보수 용이

장비 UI / 기업용 프로그램에서 자주 사용됩니다.

5. 실무에서 자주 하는 실수 1 — View와 ViewModel 한 폴더에 섞음

MainWindow.xaml
MainWindowViewModel.cs

같은 위치에 두는 방식

문제

규모 커지면 혼란
기능별 분리 어려움

해결

반드시 View / ViewModel 분리

6. 실무에서 자주 하는 실수 2 — 공통 로직 중복 작성

RelayCommand, BaseViewModel을
각 ViewModel에 복붙

문제

유지보수 지옥
코드 중복 증가

해결

Core 폴더에 공통 클래스 분리

7. 실무에서 자주 하는 실수 3 — Resources 정리 안 함

스타일을 각 View에 작성

문제

스타일 중복
디자인 일관성 깨짐

해결

ResourceDictionary 전역 관리

8. 실무 추천 규칙

✔ View는 로직 작성 금지
✔ ViewModel은 View 참조 금지
✔ 공통 클래스는 Core에
✔ UI 스타일은 Resources에
✔ 기능별 모듈 분리

이 5가지만 지켜도 프로젝트 품질이 크게 달라집니다.

9. 폴더 구조 vs 네임스페이스

폴더 구조와 네임스페이스는 동일하게 맞추는 것이 좋습니다.

예:

MyProject.ViewModels
MyProject.Views
MyProject.Core

구조가 명확하면 협업이 쉬워집니다.

10. 한 줄 핵심 정리

WPF는 구조가 곧 품질이다.

처음에 설계한 구조가 프로젝트 수명을 결정한다.

SEO 키워드

WPF 프로젝트 구조
WPF MVVM 폴더 구조
WPF 실무 구조 설계
WPF 대형 프로젝트 구조
WPF MVVM 구조 예제

[WPF 실무 15편] WPF ResourceDictionary 완전 정리 (스타일 전역 관리 실무 구조)

코드한입 — Thu, 26 Feb 2026 09:13:22 +0900

스타일을 여기저기 Window 안에 작성하다 보면
프로젝트가 커질수록 관리가 어려워집니다.

실무에서는 스타일을 한 파일에 모아 관리합니다.
그 핵심이 바로 ResourceDictionary입니다.

이번 글에서는 WPF ResourceDictionary의 개념, 분리 방법, 병합 방법, 그리고 실무에서 자주 하는 실수까지 정리합니다.

1. ResourceDictionary란 무엇인가?

ResourceDictionary는

✔ 스타일
✔ 템플릿
✔ 브러시
✔ Converter

같은 리소스를 한 곳에 모아 관리하는 구조입니다.

즉,

“스타일 저장소”

라고 생각하면 됩니다.

2. 기본 사용 방법

Window 내부에 리소스 정의

<Window.Resources>
    <Style TargetType="Button">
        <Setter Property="Background" Value="LightBlue"/>
    </Style>
</Window.Resources>

✔ 해당 Window에서만 적용

하지만 이 방식은 규모가 커지면 관리가 어렵습니다.

3. ResourceDictionary 파일 분리하기

1) 새 ResourceDictionary 파일 생성

예: Styles.xaml

2) App.xaml에 병합

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="Styles.xaml"/>
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Application.Resources>

✔ 이제 프로젝트 전체에서 사용 가능

4. 스타일 사용 방법

<Button Content="확인"
        Style="{StaticResource PrimaryButtonStyle}"/>

✔ 전역 스타일 적용 완료

5. 실무에서 자주 하는 실수 1 — Build Action 설정 안 함

ResourceDictionary 파일의 Build Action이

None

이면 로드되지 않습니다.

해결

✔ Build Action → Page

6. 실무에서 자주 하는 실수 2 — StaticResource vs DynamicResource 혼동

StaticResource

✔ 로드 시점에 한 번만 바인딩
✔ 성능 좋음

DynamicResource

✔ 런타임 변경 가능
✔ 테마 변경 시 사용

실무 팁

일반 스타일은 → StaticResource
테마 변경 가능 UI는 → DynamicResource

7. 실무에서 자주 하는 실수 3 — 리소스 병합 순서 문제

MergedDictionaries는 아래에 있는 것이 우선 적용됩니다.

<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="BaseStyles.xaml"/>
    <ResourceDictionary Source="OverrideStyles.xaml"/>
</ResourceDictionary.MergedDictionaries>

✔ OverrideStyles가 우선

순서 잘못되면 스타일 덮어쓰기 안 됨

8. 실무 추천 폴더 구조

Resources/
 ├ Colors.xaml
 ├ Styles.xaml
 ├ DataGridStyles.xaml
 ├ ButtonStyles.xaml
 └ Converters.xaml

✔ 기능별 분리
✔ 유지보수 쉬움
✔ 대형 프로젝트에 적합

9. DataGrid 전용 리소스 분리 예시

<ResourceDictionary>
    <Style TargetType="DataGridRow">
        <Setter Property="Height" Value="30"/>
    </Style>

    <Style TargetType="DataGridColumnHeader">
        <Setter Property="FontWeight" Value="Bold"/>
    </Style>
</ResourceDictionary>

DataGrid 관련 스타일은 별도 파일로 분리하는 것이 좋습니다.

10. 실무 결론

✔ 스타일은 Window에 직접 작성하지 말 것
✔ ResourceDictionary로 분리할 것
✔ App.xaml에서 병합 관리
✔ 파일 기능별 분리

이 구조가 장기 유지보수에 가장 좋습니다.

11. 한 줄 핵심 정리

스타일이 많아지면 → ResourceDictionary로 분리하라.

WPF ResourceDictionary 사용법
WPF 스타일 전역 관리
WPF MergedDictionaries
WPF StaticResource DynamicResource 차이
WPF 스타일 분리 방법

[WPF 실무 14편] WPF ControlTemplate 완전 이해 (스타일이 안 먹는 진짜 이유)

코드한입 — Wed, 25 Feb 2026 10:48:50 +0900

Setter를 줬는데 적용이 안 된다.
Background를 바꿨는데 색이 안 바뀐다.
정렬을 바꿨는데 그대로다.

이런 문제의 80%는 ControlTemplate 때문입니다.

이번 글에서는 WPF 스타일 구조의 핵심인 ControlTemplate을 실무 기준으로 정리합니다.

1. WPF 스타일 구조 이해하기

WPF 컨트롤 렌더링 구조는 다음과 같습니다.

Style → ControlTemplate → Visual Tree → 실제 UI 표시

즉,

✔ Style은 속성 값을 설정하는 단계
✔ ControlTemplate은 실제 모양을 정의하는 단계

Template이 다르면 Style이 무시될 수 있습니다.

2. ControlTemplate이란 무엇인가?

ControlTemplate은 컨트롤의 “외형 구조”를 정의합니다.

예를 들어 Button은 내부적으로 다음과 같은 구조를 가집니다.

Border
ContentPresenter
Trigger

Template을 재정의하면 버튼 모양 자체를 바꿀 수 있습니다.

3. 간단한 ControlTemplate 예제

<Style TargetType="Button">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="Button">
                <Border Background="LightGray"
                        CornerRadius="10"
                        Padding="10">
                    <ContentPresenter HorizontalAlignment="Center"
                                      VerticalAlignment="Center"/>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

✔ 기본 버튼 구조 완전 교체
✔ 디자인 완전 자유화 가능

4. 왜 스타일이 안 먹는가?

예시

<Setter Property="Background" Value="Red"/>

하지만 Template 안에

<Border Background="White"/>

처럼 고정되어 있으면?

→ Template이 Style 값을 덮어씀

5. 올바른 Template 설계 방식

Template 내부에서 TemplateBinding을 사용해야 합니다.

<Border Background="{TemplateBinding Background}">

이렇게 해야 Style에서 준 Background가 적용됩니다.

6. 실무에서 자주 하는 실수 1 — TemplateBinding 안 씀

잘못된 코드

<Border Background="White"/>

증상

Style에서 Background 바꿔도 적용 안 됨

해결

<Border Background="{TemplateBinding Background}"/>

7. 실무에서 자주 하는 실수 2 — ContentPresenter 누락

Template 재정의했는데 텍스트가 안 보이는 경우

원인

ContentPresenter를 안 넣음

해결

<ContentPresenter/>

반드시 포함해야 함

8. 실무에서 자주 하는 실수 3 — Trigger 위치 오류

Trigger는 반드시 Template 안에 정의하거나
Style.Triggers에 올바르게 작성해야 합니다.

구조 잘못 잡으면 아예 동작 안 합니다.

9. Template vs Style 차이 정리

구분StyleControlTemplate

역할	속성 설정	외형 정의
모양 변경	제한적	완전 교체 가능
정렬/색상 문제	일부 해결	근본 해결

10. 언제 Template을 수정해야 할까?

✔ Style이 적용되지 않을 때
✔ 기본 디자인을 완전히 바꿔야 할 때
✔ 내부 구조를 수정해야 할 때

Setter로 안 되면 거의 Template 문제입니다.

11. 한 줄 핵심 정리

Style이 안 먹는다 = Template을 의심하라.

WPF ControlTemplate 설명
WPF 스타일 안 먹음
WPF TemplateBinding 사용법
WPF ControlTemplate 예제
WPF 스타일 문제 해결

[WPF 실무 13편] WPF DataGrid 정렬 / 필터 구현 완전 정리 (CollectionView 제대로 쓰는 법)

코드한입 — Tue, 24 Feb 2026 16:11:32 +0900

DataGrid에서 정렬은 되는데 필터는 안 되거나,
필터를 구현했더니 원본 데이터가 망가지는 경험을 해본 적 있을 겁니다.

WPF에서 정렬과 필터는 직접 리스트를 조작하는 방식이 아니라
CollectionView를 통해 처리하는 것이 정석입니다.

이 글에서는 DataGrid 정렬과 필터를 실무에서 안전하게 구현하는 방법을 정리합니다.

1. 왜 List를 직접 건드리면 안 될까?

잘못된 방식

Items = Items.Where(x => x.Age > 30).ToList();

문제점

원본 데이터 손실
필터 해제 어려움
정렬 충돌 발생
UI 갱신 문제

실무에서는 절대 이렇게 하지 않습니다.

2. 정석 방법 — CollectionView 사용

using System.ComponentModel;

private ICollectionView _view;

public MainViewModel()
{
    _view = CollectionViewSource.GetDefaultView(Items);
}

CollectionView는 원본 컬렉션을 유지한 채
정렬/필터/그룹화를 지원합니다.

3. 정렬 구현 방법

_view.SortDescriptions.Clear();
_view.SortDescriptions.Add(
    new SortDescription("Age", ListSortDirection.Ascending));

✔ 원본 데이터 유지
✔ 여러 컬럼 정렬 가능
✔ 동적 정렬 가능

4. 필터 구현 방법

_view.Filter = item =>
{
    var user = item as User;
    return user.Age > 30;
};

✔ 조건식 자유롭게 작성 가능
✔ 필터 해제 쉬움

필터 해제:

_view.Filter = null;

5. XAML에서 DataGrid 연결

<DataGrid ItemsSource="{Binding Items}"/>

중요한 점:

✔ Items는 그대로 ObservableCollection 유지
✔ 정렬/필터는 View에서 처리됨

6. 실무에서 자주 하는 실수 1 — CollectionView를 새로 만듦

_view = new ListCollectionView(Items);

문제

바인딩 연결 깨질 수 있음
예기치 않은 동작

해결

항상

CollectionViewSource.GetDefaultView(Items);

사용

7. 실무에서 자주 하는 실수 2 — Filter 안에서 예외 발생

_view.Filter = item =>
{
    return ((User)item).Name.Contains(searchText);
};

문제

searchText가 null이면 예외 발생

안전한 코드

_view.Filter = item =>
{
    var user = item as User;
    return string.IsNullOrEmpty(searchText)
        || user.Name?.Contains(searchText) == true;
};

8. 실무에서 자주 하는 실수 3 — Filter 후 Refresh 안 함

필터 조건이 변경되었는데 UI가 갱신 안 될 때

_view.Refresh();

반드시 호출해야 함

특히 검색어 바뀔 때 필요

9. 실무 추천 구조

✔ Items → ObservableCollection 유지
✔ CollectionView → 정렬/필터 전용
✔ Filter 변경 시 Refresh() 호출
✔ 원본 데이터 절대 직접 수정 금지

이 구조가 가장 안전합니다.

10. 고급 팁 — 다중 정렬

_view.SortDescriptions.Add(
    new SortDescription("Age", ListSortDirection.Ascending));

_view.SortDescriptions.Add(
    new SortDescription("Name", ListSortDirection.Descending));

✔ 1차 정렬 → Age
✔ 2차 정렬 → Name

11. 한 줄 핵심 정리

DataGrid 정렬/필터는 리스트를 바꾸는 게 아니라
View를 바꾸는 것이다.

WPF DataGrid 정렬 구현
WPF DataGrid 필터 구현
WPF CollectionView 사용법
WPF SortDescription 예제
WPF DataGrid Filter

[WPF 실무 12편] WPF DataGrid 성능 최적화 완전 정리 (대용량 데이터 느려짐 해결)

코드한입 — Tue, 24 Feb 2026 13:54:04 +0900

DataGrid에 데이터가 1,000건 이상만 들어가도 갑자기 느려지는 경험을 해본 적 있을 겁니다.
스크롤이 버벅이고, 클릭 반응이 늦고, 심하면 UI가 멈춰 보이기도 합니다.

이 글에서는 WPF DataGrid가 느려지는 이유와 실무에서 반드시 적용해야 하는 성능 최적화 방법을 정리합니다.

1. 왜 DataGrid는 느려질까?

WPF DataGrid는 기본적으로 모든 Row와 Cell을 UI 요소로 생성합니다.

데이터 10,000건 = 10,000개의 Row 객체 생성

여기에 컬럼이 20개면?

→ 200,000개의 Cell UI 생성

당연히 무거워질 수밖에 없습니다.

2. 가장 중요한 옵션 — 가상화(Virtualization)

가상화는 화면에 보이는 Row만 생성하는 기능입니다.

반드시 확인해야 할 설정

<DataGrid
    EnableRowVirtualization="True"
    EnableColumnVirtualization="True"
    VirtualizingPanel.IsVirtualizing="True"
    VirtualizingPanel.VirtualizationMode="Recycling"/>

✔ EnableRowVirtualization = 보이는 Row만 생성
✔ Recycling = 기존 Row 재사용 (성능 ↑)

3. 실무에서 자주 하는 실수 1 — ScrollViewer 감싸기

잘못된 코드

<ScrollViewer>
    <DataGrid ItemsSource="{Binding Items}"/>
</ScrollViewer>

문제

가상화 완전히 꺼짐

→ 전체 Row 생성됨
→ 성능 급격히 저하

해결

DataGrid는 자체 ScrollViewer를 가지고 있음

절대 외부 ScrollViewer로 감싸지 말 것

4. 실무에서 자주 하는 실수 2 — RowHeight Auto 사용

<DataGrid RowHeight="Auto"/>

문제

각 Row 높이를 매번 계산
→ 성능 저하

해결

고정 높이 사용

<DataGrid RowHeight="30"/>

5. 실무에서 자주 하는 실수 3 — 복잡한 CellTemplate 남발

<DataGridTemplateColumn>

TemplateColumn은 유연하지만

✔ 시각적 트리 깊어짐
✔ UI 객체 증가
✔ 렌더링 비용 증가

해결

가능하면

✔ DataGridTextColumn 사용
✔ 필요할 때만 TemplateColumn

6. 대용량 데이터 처리 팁

1) UI Thread에서 대량 Add 금지

foreach (var item in bigList)
{
    Items.Add(item);
}

→ UI 멈춤

해결

await Task.Run(() => LoadData());

또는

Range 추가
Bulk Update 구조 사용

2) CollectionView 사용

필터/정렬을 위해 직접 리스트 조작하지 말고

CollectionViewSource.GetDefaultView(Items);

사용 권장

7. 성능 체크리스트 (실무용)

✔ EnableRowVirtualization=True
✔ VirtualizationMode=Recycling
✔ 외부 ScrollViewer 제거
✔ RowHeight 고정
✔ TemplateColumn 최소화
✔ 대량 데이터는 비동기 로딩

이 6가지만 지켜도 체감 성능 크게 개선됩니다.

8. 실무 결론

DataGrid 느려짐의 80% 원인은

가상화 꺼짐
불필요한 UI 요소 생성

입니다.

성능 문제는 대부분 구조 문제입니다.

9. 한 줄 핵심 정리

DataGrid 성능 최적화 = 가상화 유지 + UI 요소 최소화

WPF DataGrid 성능
WPF DataGrid 느려짐
WPF DataGrid 가상화
WPF EnableRowVirtualization
WPF DataGrid 최적화

코드한입

[리눅스 프로그래밍 시리즈 28편]epoll 기반 채팅 서버 만들기: 멀티 클라이언트 브로드캐스트 구현

1. 프로젝트 목표

2. 핵심 구조

3. 서버 코드 (epoll 기반 채팅)

4. 테스트 방법 (netcat)

5. 개선 포인트 (실무 관점)

6. 브로드캐스트 구조 개선 팁

7. 자주 하는 실수

8. 28편 요약

메인 키워드

서브 키워드

[WPF 실무 34편] WPF MVVM Navigation 고급 패턴 (View 완전 분리 구조)

1. 기존 Navigation 문제

2. 목표 구조

3. NavigationService 설계

4. 구현

5. MainViewModel

6. View 연결 (DataTemplate)

7. ViewModel에서 Navigation 호출

8. 실무에서 자주 하는 실수 1 — ViewModel에서 View 생성

9. 실무에서 자주 하는 실수 2 — NavigationService 없이 직접 변경

10. 실무 확장

11. 한 줄 핵심 정리

[리눅스 프로그래밍 시리즈 27편]epoll 완전 이해: 고성능 이벤트 기반 서버의 표준 (edge/level trigger)

1. 왜 epoll이 필요한가?

2. epoll 개념

3. epoll 핵심 API

4. epoll_create1

5. epoll_ctl (등록/수정/삭제)

6. epoll_wait (이벤트 대기)

7. 기본 epoll 서버 예제

8. Level Trigger vs Edge Trigger

Level Trigger (기본)

Edge Trigger (EPOLLET)

9. epoll 장점

10. 실무에서 사용하는 구조

11. 자주 하는 실수

12. 27편 요약

메인 키워드

서브 키워드

[리눅스 프로그래밍 시리즈 26편]select 완전 이해: 여러 소켓을 동시에 처리하는 이벤트 기반 I/O

1. 왜 select가 필요한가?

2. select 개념

3. select 함수

4. fd_set 사용법

5. 기본 흐름

6. 간단한 select 서버 예제

7. 동작 구조

8. select의 한계

9. 언제 select를 쓰나?

10. 자주 하는 실수

11. 26편 요약

메인 키워드

서브 키워드

태그

[리눅스 프로그래밍 시리즈 24편] 소켓 프로그래밍 기초: TCP 서버/클라이언트 구현 (connect, bind, listen, accept)

1. 소켓이란?

2. TCP vs UDP

3. 서버 측 기본 흐름

4. 클라이언트 측 기본 흐름

5. 서버 예제 코드

6. 클라이언트 예제 코드

7. 실행 방법

8. 핵심 함수 정리

9. 실무에서 중요한 개념

10. 자주 하는 실수

11. 24편 요약

메인 키워드

서브 키워드

[WPF 실무 32편] WPF Messenger 패턴 (ViewModel 간 통신 완전 정리)

1. 왜 Messenger가 필요한가?

2. Messenger 개념

3. Toolkit Messenger 사용 준비

4. 메시지 클래스 정의

5. 메시지 보내기 (Sender)

6. 메시지 받기 (Receiver)

7. 자동 해제 (중요)

8. 실무에서 자주 하는 실수 1 — StrongReferenceMessenger 사용

9. 실무에서 자주 하는 실수 2 — Unregister 안 함