OnePaperHoon Blog

Linux ioctl, 디바이스를 제어하는 전용 채널

onepaperhoon — Mon, 6 Apr 2026 19:40:42 +0900

`read()`/`write()`로는 데이터를 주고받을 수 있지만,
"이 센서의 샘플링 레이트를 변경해줘" 같은 제어 명령은 어떻게 전달할까요?
그 답이 `ioctl`입니다.

1. ioctl이 왜 필요한가?

Linux에서 디바이스와 통신하는 기본 방법은 `read()`와 `write()`입니다.
그런데 이 두 가지로 표현하기 어려운 명령들이 있습니다.

"샘플링 레이트를 1000Hz로 설정해줘"
"현재 온도를 읽어줘"
"버퍼를 초기화해줘"
"카운터 값을 99로 교환하고 기존 값을 돌려줘"

이런 디바이스 고유의 제어 명령을 전달하는 시스템 콜이 `ioctl`(Input/Output Control)입니다.

/* 유저스페이스에서 호출하는 방식 */
int ioctl(int fd, unsigned long request, void *arg);

인자	설명
`fd`	열린 디바이스 파일 디스크립터
`request`	명령 코드 (매직 넘버 + 번호 + 방향 + 크기 인코딩)
`arg (void *)`	명령에 따라 정수값 또는 구조체 포인터

2. ioctl은 언제 쓰나요?

디바이스를 다루다 보면 read()/write()로 표현하기 애매한 순간이 생깁니다.

"샘플링 레이트를 1000Hz로 바꿔줘"
"현재 버퍼를 비워줘"
"카운터 값을 99로 설정하고 기존 값을 돌려줘"

데이터를 "읽고 쓰는" 것이 아니라 디바이스에 명령을 내리는 상황입니다. ioctl은 바로 이 용도로 설계된 시스템 콜입니다.

실제로 Linux의 주요 드라이버들이 이 방식을 씁니다.

드라이버ioctl 용도

V4L2 (카메라)	해상도, 프레임레이트 설정
ALSA (사운드)	샘플링 레이트, 채널 수 설정
네트워크 소켓	IP 주소, 인터페이스 정보 조회
TTY (시리얼)	Baud rate, 흐름 제어 설정

3. ioctl 명령 코드 설계

ioctl의 핵심은 명령 코드(command number)를 어떻게 정의하느냐입니다. 커널은 명령 코드를 32비트 정수로 인코딩합니다.

32비트 명령 코드 구조:
┌────────────┬────────────┬─────────────────┬──────────────────┐
│  direction│    size   │  type (magic)  │   number (nr)  │
│   2 bits  │  14 bits  │   8 bits       │    8 bits      │
└────────────┴────────────┴─────────────────┴──────────────────┘

이걸 직접 계산하면 실수가 생깁니다. 커널이 제공하는 매크로를 씁니다.

`ioctl_cmd.h` — 커널과 유저가 함께 공유하는 헤더

#ifndef IOCTL_CMD_H
#define IOCTL_CMD_H

#include <linux/ioctl.h>

/* Magic number — 이 드라이버의 고유 식별자 */
#define IOCTL_MAGIC 'k'

/* 명령어 정의 */
#define IOCTL_RESET     _IO  (IOCTL_MAGIC, 0)            /* 데이터 없음 */
#define IOCTL_GET_COUNT _IOR (IOCTL_MAGIC, 1, int)       /* 커널 → 유저 */
#define IOCTL_SET_MSG   _IOW (IOCTL_MAGIC, 2, char[256]) /* 유저 → 커널 */
#define IOCTL_GET_MSG   _IOR (IOCTL_MAGIC, 3, char[256]) /* 커널 → 유저 */
#define IOCTL_EXCHANGE  _IOWR(IOCTL_MAGIC, 4, int)       /* 양방향 */

#define IOCTL_MAXNR 4

#endif

매크로 4종 정리

매크로	방향	데이터 크기 포함	용도
`_IO(magic, nr)`	없음	아니오	단순 제어 (reset, start 등)
`_IOR(magic, nr, type)`	커널 → 유저	예	값 읽기
`_IOW(magic, nr, type)`	유저 → 커널	예	값 설정
`_IOWR(magic, nr, type)`	양방향	예	값 교환

Magic Number란?

#define IOCTL_MAGIC 'k'

명령 코드의 상위 8비트를 차지하는 드라이버 고유 식별자입니다.

다른 드라이버 명령 코드와 충돌하지 않도록 드라이버마다 다른 문자를 씁니다.

커널 소스의 `Documentation/userspace-api/ioctl/ioctl-number.rst`에 이미 할당된 매직 번호 목록이 있습니다.

헤더 파일 공유 전략: `ioctl_cmd.h`를 커널 모듈(`chardev_ioctl.c`)과
유저 프로그램(`test_ioctl.c`) 양쪽에서 #include 합니다.
명령 코드를 한 곳에서 관리해 불일치를 원천 차단합니다.

4. 커널 측 구현 - `unlocked_ioctl`

file_operations에 등록

static struct file_operations fops = {
    .owner          = THIS_MODULE,
    .open           = device_open,
    .release        = device_release,
    .read           = device_read,
    .write          = device_write,
    .unlocked_ioctl = device_ioctl,  /* ioctl 핸들러 */
};

unlocked_ioctl vs ioctl

필드	커널 버전	특징
`.ioctl`	2.6.36 이전	호출 전 BKL(Big Kernel Lock) 자동 획득
`.unlocked_ioctl`	2.6.36 이후	BKL 없이 호출 — 드라이버가 동기화 책임

현대 커널에서는 반드시 `. unlocked_ioctl`을 써야 합니다.

ioctl 핸들러 구현

static long device_ioctl(struct file *file, unsigned int cmd,
                         unsigned long arg)
{
    int value;
    char user_msg[MSG_SIZE];

    /* ① 매직 넘버 검증 — 엉뚱한 명령 차단 */
    if (_IOC_TYPE(cmd) != IOCTL_MAGIC)
        return -ENOTTY;

    /* ② 명령 번호 범위 검증 */
    if (_IOC_NR(cmd) > IOCTL_MAXNR)
        return -ENOTTY;

    /* ③ 명령별 처리 */
    switch (cmd) {

    case IOCTL_RESET:
        access_count = 0;
        strcpy(message, "Reset!");
        break;

    case IOCTL_GET_COUNT:
        /* 커널 → 유저: copy_to_user() */
        if (copy_to_user((int __user *)arg, &access_count, sizeof(int)))
            return -EFAULT;
        break;

    case IOCTL_SET_MSG:
        /* 유저 → 커널: copy_from_user() */
        if (copy_from_user(user_msg, (char __user *)arg, MSG_SIZE))
            return -EFAULT;
        user_msg[MSG_SIZE - 1] = '\0';
        strcpy(message, user_msg);
        break;

    case IOCTL_GET_MSG:
        if (copy_to_user((char __user *)arg, message, MSG_SIZE))
            return -EFAULT;
        break;

    case IOCTL_EXCHANGE:
        /* 유저 값 읽기 → 기존 카운터 반환 → 새 값 적용 */
        if (copy_from_user(&value, (int __user *)arg, sizeof(int)))
            return -EFAULT;
        if (copy_to_user((int __user *)arg, &access_count, sizeof(int)))
            return -EFAULT;
        access_count = value;
        break;

    default:
        return -ENOTTY;  /* 알 수 없는 명령 */
    }

    return 0;
}

왜 -ENOTTY를 반환하나?

"Not a typewriter"의 약자로, 역사적으로 터미널 제어에서 유래했습니다.

오늘날에는 "이 디바이스는 이 ioctl을 지원하지 않는다"는 POSIX 표준 오류 코드로 쓰입니다.

`IOCTL_EXCHANGE` 양방향 동작 원리

포인터 하나로 값을 읽고 같은 포인터에 다른 값을 씁니다.

유저:  value = 999  →  ioctl(fd, IOCTL_EXCHANGE, &value)
                              │
커널:  copy_from_user → value 읽음 (999)
       copy_to_user  → access_count 반환
       access_count  = 999  적용
                              │
유저:  value 에 기존 카운터 값이 들어있음

5. 유저스페이스 측 구현

#include "ioctl_cmd.h"   /* 커널과 동일한 명령 코드 사용 */
#include <sys/ioctl.h>
#include <fcntl.h>

int main(void)
{
    int fd = open("/dev/ioctl_dev", O_RDWR);
    if (fd < 0) { perror("open"); return 1; }

    int count;
    char message[256];

    /* 카운터 읽기 */
    ioctl(fd, IOCTL_GET_COUNT, &count);
    printf("Count: %d\n", count);

    /* 메시지 설정 */
    strcpy(message, "Hello from OnePaperHoon!");
    ioctl(fd, IOCTL_SET_MSG, message);

    /* 메시지 읽기 */
    memset(message, 0, sizeof(message));
    ioctl(fd, IOCTL_GET_MSG, message);
    printf("Message: %s\n", message);

    /* 값 교환 */
    int value = 999;
    ioctl(fd, IOCTL_EXCHANGE, &value);
    printf("Exchanged, got back: %d\n", value);

    /* 리셋 */
    ioctl(fd, IOCTL_RESET, NULL);

    close(fd);
    return 0;
}

6. 빌드 및 실행

파일 구성

day5-ioctl/
├── chardev_ioctl.c   # 커널 모듈
├── ioctl_cmd.h       # 명령 코드 정의 (공유 헤더)
├── test_ioctl.c      # 유저 테스트 프로그램
└── Makefile

Makefile 구성

이 Makefile은 커널 모듈과 유저 프로그램을 함께 빌드하고, 디바이스 파일 생성까지 관리합니다.

obj-m := chardev_ioctl.o
KDIR  := /lib/modules/$(shell uname -r)/build
PWD   := $(shell pwd)
USER_PROG := test_ioctl

all: module userspace

module:
	$(MAKE) -C $(KDIR) M=$(PWD) modules

userspace:
	gcc -o $(USER_PROG) test_ioctl.c

clean:
	$(MAKE) -C $(KDIR) M=$(PWD) clean
	rm -f $(USER_PROG)

load:
	sudo insmod chardev_ioctl.ko
	dmesg | tail -10

create-dev:
	@read -p "Enter major number: " MAJOR; \
	sudo mknod /dev/ioctl_dev c $$MAJOR 0; \
	sudo chmod 666 /dev/ioctl_dev

test:
	./$(USER_PROG)
	dmesg | tail -20

unload:
	sudo rmmod chardev_ioctl
	sudo rm -f /dev/ioctl_dev

.PHONY: all module userspace clean load create-dev test unload

Makefile 타깃 요약

명령어	동작
`make`	커널 모듈 + 유저 프로그램 빌드
`make load`	모듈 로드 + dmesg
`make create-dev`	`/dev/ioctl_dev` 생성
`make test`	테스트 프로그램 실행
`make unload`	모듈 언로드 + 디바이스 파일 삭제

실행 순서

# 1. 빌드
$ make

# 2. 모듈 로드
$ make load
[ 100.001] ioctl_dev: Registered with major 240
[ 100.002] ioctl_dev: Create device:
[ 100.003]   sudo mknod /dev/ioctl_dev c 240 0

# 3. /dev 파일 생성 (메이저 번호는 dmesg 확인)
$ make create-dev
Enter major number: 240
/dev/ioctl_dev 생성 완료

# 4. 테스트 실행
$ make test
====================================
ioctl Test Program
====================================

1. Getting count...
   Current count: 1

2. Setting message...
   Message set: Hello from OnePaperHoon!

3. Getting message...
   Message: Hello from OnePaperHoon!

4. Exchanging value...
   Sending: 999
   Received: 1

5. Getting count (after exchange)...
   Current count: 999

6. Resetting...
   Reset done!

7. Getting count (after reset)...
   Current count: 0

====================================
Test Complete!
====================================

# 5. 언로드
$ make unload

7. 마치며

ioctl은 /proc보다 복잡하지만, 실제 드라이버에서 훨씬 많이 사용됩니다.

명령 코드는 `_IO` / `_IOR` / `_IOW` / `_IOWR` 매크로로 만든다.
헤더 파일을 커널과 유저가 공유해 명령 코드 불일치를 막는다.
핸들러에서 매직 넘버를 검증하고 알 수 없는 명령은 `-ENOTTY`를 반환한다.
unlocked_ioctl을 쓰면 동기화는 드라이버가 직접 책임진다.

카메라(`V4 L2`), 사운드(`ALSA`), 네트워크(`SIOCGIFADDR`) 등

Linux의 주요 드라이버 인터페이스는 대부분 `ioctl` 기반입니다. 이 구조를 이해하면 그 코드들이 낯설지 않을 겁니다.

참고 자료

Linux Kernel Documentation: Documentation/userspace-api/ioctl/ioctl-number.rst
linux/ioctl.h 커널 소스
man 2 ioctl
LDD3(Linux Device Drivers 3rd Edition) — Chapter 6. Advanced Char Driver Operations

Linux/proc 파일시스템, 커널과 대화하기

onepaperhoon — Fri, 3 Apr 2026 17:36:38 +0900

`cat /proc/cpuinfo`,`cat /proc/meminfo` - 써본 적 있으신가요?
이 파일들은 디스크에 없습니다. 커널이 즉석에서 만들어냅니다. 오늘은 그 원리를 직접 구현해 봅니다.

1. /proc 파일시스템이란?

터미널에서 이런 명령을 써본 적 있을 겁니다.

$ cat /proc/cpuinfo      # CPU 정보
$ cat /proc/meminfo      # 메모리 사용량
$ cat /proc/uptime       # 부팅 후 경과 시간

이 파일들은 실제로 디스크에 존재하지 않습니다. `/proc`은 가상 파일 시스템(virtual File System)입니다.
커널이 메모리 위에 만들어 놓은 인터페이스로, `cat`으로 읽으면 커널 함수가 호출되어 데이터를 즉석에서 생성합니다.

디스크
┌──────────────────┐
│ /home, /etc, ...│  ← 실제 파일
└──────────────────┘

메모리 (커널)
┌──────────────────┐
│ /proc/cpuinfo   │  ← cat 하면 커널 함수 호출
│ /proc/meminfo   │
│ /proc/mymodule  │  ← 우리가 만들 것
└──────────────────┘

이 메커니즘을 이용하면 커널 모듈이 유저스페이스 앱과 파일처럼 통신할 수 있습니다.

2. 동작 원리 - cat 하면 무슨 일이 생기나?

유저스페이스                     커널스페이스

cat /proc/onepaperhoon_info
  │
  │  open() 시스템 콜
  ▼
  proc_open()  ─────────────►  single_open(file, proc_show, NULL)
                                  seq_file 초기화

  │  read() 시스템 콜
  ▼
  seq_read()   ─────────────►  proc_show(seq_file *m, void *v)
                                  seq_printf(m, "Access count: %lu\n", ...)
                                  버퍼에 데이터 채움

  │  결과 출력
  ▼
Access count: 1
Current jiffies: 4298765432
...


echo reset > /proc/onepaperhoon_info
  │
  │  write() 시스템 콜
  ▼
  proc_write() ─────────────►  copy_from_user(cmd, buffer, count)
                                  "reset" 감지 → access_count = 0

핵심은 `cat`과 `echo`가 일반 파일처럼 동작하지만, 실제로는 커널 함수를 호출한다는 점입니다.

3. 핵심 API 설명

① proc_ops — 커널 5.6부터 필수

static const struct proc_ops proc_fops = {
    .proc_open    = proc_open,
    .proc_read    = seq_read,
    .proc_write   = proc_write,
    .proc_lseek   = seq_lseek,
    .proc_release = single_release,
};

커널 5.6 이전에는 `file_operations`를 썼습니다. 5.6부터 `/proc`전용 `struct proc_ops`가 도입됐습니다.
Raspberry Pi의 커널 6.x에서는 반드시 `proc_ops`를 써야 합니다. `file_operations`를 쓰면 컴파일 에러가 납니다.

② seq_file — 버퍼 걱정 없이 출력

`/proc`파일을 읽을 때 단순히 문자열을 반환하면 대용량 데이터에서 페이지 경계 문제가 생깁니다.

`seq_file`은 커널이 제공하는 순차 출력 인터페이스로, 버퍼 관리를 자동으로 처리해 줍니다.

함수	역할
single_open(file, show_fn, data)	단일 페이지 출력용 seq_file 초기화
seq_printf(m, fmt, ...)	seq_file 버퍼에 포맷 출력
seq_read	표준 read 핸들러 (직접 구현 불필요)
single_release	single_open 대응 release 핸들러

③ copy_from_user() — 유저 → 커널 안전 복사

if (copy_from_user(cmd, buffer, count))
    return -EFAULT;

유저스페이스와 커널스페이스는 메모리 주소 공간이 분리되어 있습니다. `echo reset` 으로 데이터를 쓰면 그 데이터는 유저 공간 메모리에 있습니다. 커널에서 직접 포인터로 접근하면 페이지 폴트나 보안 문제가 생깁니다. `copy_from_user()`가 유저 공간 -> 커널 공간으로 안전하게 복사해 줍니다.

④ `__user` 어노테이션

static ssize_t proc_write(struct file *file, const char __user *buffer, ...)

`__user`는 실행에 영향을 주지 않는 컴파일러 어노테이션입니다. `sparse` (커널 정적 분성 도구)가 이 포인터를 유저 공간 주소로 인식해, `copy_from_user()` 없이 직접 역참조 하면 경고를 발생시킵니다. 빌드 타임에 실수를 잡아주는 안전장치입니다.

⑤ jiffies — 커널의 시간 단위

seq_printf(m, "Current jiffies: %lu\n", jiffies);

`jiffies`는 커널 부팅 이후 타이머 인터럽트가 발생한 횟수입니다. 1초에 `HZ`번 증가합니다. (보통 250 또는 1000).

`/proc/uptime` 같은 파일이 이 값으로 경과 시간을 계산합니다.

4. 코드 전체 구조

#include <linux/init.h>
#include <linux/jiffies.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#include <linux/uaccess.h>

#define PROC_NAME "onepaperhoon_info"

static unsigned long access_count = 0;

/* ① cat 할 때 호출 — 출력 내용 정의 */
static int proc_show(struct seq_file *m, void *v)
{
    access_count++;
    seq_printf(m, "====================================\n");
    seq_printf(m, "OnePaperHoon Kernel Module Info\n");
    seq_printf(m, "====================================\n");
    seq_printf(m, "Access count: %lu\n", access_count);
    seq_printf(m, "Current jiffies: %lu\n", jiffies);
    seq_printf(m, "Module: %s\n", THIS_MODULE->name);
    seq_printf(m, "====================================\n");
    return 0;
}

/* ② open 시 seq_file 초기화 */
static int proc_open(struct inode *inode, struct file *file)
{
    return single_open(file, proc_show, NULL);
}

/* ③ echo 할 때 호출 — "reset" 명령 처리 */
static ssize_t proc_write(struct file *file, const char __user *buffer,
                           size_t count, loff_t *pos)
{
    char cmd[10];

    if (count > sizeof(cmd) - 1)
        return -EINVAL;

    if (copy_from_user(cmd, buffer, count))
        return -EFAULT;

    cmd[count] = '\0';

    if (strncmp(cmd, "reset", 5) == 0) {
        access_count = 0;
        printk(KERN_INFO "proc_basic: Counter reset!\n");
    }
    return count;
}

/* ④ proc_ops 등록 (커널 5.6+) */
static const struct proc_ops proc_fops = {
    .proc_open    = proc_open,
    .proc_read    = seq_read,
    .proc_write   = proc_write,
    .proc_lseek   = seq_lseek,
    .proc_release = single_release,
};

static struct proc_dir_entry *proc_entry;

/* ⑤ insmod 시 /proc 파일 생성 */
static int __init proc_basic_init(void)
{
    proc_entry = proc_create_data(PROC_NAME, 0666, NULL, &proc_fops, NULL);
    if (!proc_entry) {
        printk(KERN_ERR "proc_basic: Failed to create /proc/%s\n", PROC_NAME);
        return -ENOMEM;
    }
    printk(KERN_INFO "proc_basic: Created /proc/%s\n", PROC_NAME);
    return 0;
}

/* ⑥ rmmod 시 /proc 파일 제거 */
static void __exit proc_basic_exit(void)
{
    if (proc_entry)
        remove_proc_entry(PROC_NAME, NULL);
    printk(KERN_INFO "proc_basic: Total accesses: %lu\n", access_count);
}

module_init(proc_basic_init);
module_exit(proc_basic_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("OnePaperHoon");
MODULE_DESCRIPTION("Basic /proc filesystem example - Week 5 Day 3");
MODULE_VERSION("1.0");

5. 자주 하는 실수 모음

❌ 실수 1: 커널 5.6 미만 API 사용

/* 나쁜 예 — 5.6 이상에서 컴파일 에러 */
static const struct file_operations proc_fops = {
    .open    = proc_open,
    .read    = seq_read,
    ...
};

/* 좋은 예 — 5.6 이상 필수 */
static const struct proc_ops proc_fops = {
    .proc_open = proc_open,
    .proc_read = seq_read,
    ...
};

Raspberry Pi 커널 6.x에서는 반드시 `proc_ops`를 써야 합니다.

❌ 실수 2: copy_from_user() 없이 직접 접근

/* 나쁜 예 — 커널 패닉 또는 보안 취약점 */
static ssize_t proc_write(struct file *file, const char __user *buffer, ...)
{
    char cmd[10];
    memcpy(cmd, buffer, count);  /* 직접 접근 — 절대 금지 */
}

/* 좋은 예 */
if (copy_from_user(cmd, buffer, count))
    return -EFAULT;

`__user` 포인터를 직접 역참조하면 커널 패닉이 발생합니다.

❌ 실수 3: remove_proc_entry() 누락

/* 나쁜 예 — exit에서 제거 안 함 */
static void __exit proc_basic_exit(void)
{
    /* remove_proc_entry() 깜빡! */
    printk(KERN_INFO "Unloaded\n");
}

모듈이 제거된 후에도 `/proc` 엔트리가 남아 있으면, `cat /proc/onepaperhoon_info` 시 커널 패닉이 발생합니다. `exit` 함수에서 반드시 `remove_proc_entry()`를 호출하세요.

❌ 실수 4: count 검증 없이 copy_from_user()

/* 나쁜 예 — 버퍼 오버플로우 가능 */
if (copy_from_user(cmd, buffer, count))
    return -EFAULT;

/* 좋은 예 — 크기 검증 먼저 */
if (count > sizeof(cmd) - 1)
    return -EINVAL;
if (copy_from_user(cmd, buffer, count))
    return -EFAULT;

`count`를 먼저 검증하지 않으면 버퍼 오버플로우가 생길 수 있습니다.

7. 마치며

`/proc` 파일시스템은 커널 모듈과 유저스페이스가 대화하는 가장 단순한 방법입니다.

/proc 파일은 디스크에 없다 — cat 하면 커널 함수가 실행된다.
커널 5.6부터 proc_ops를 써야 한다.
유저 → 커널 데이터 복사는 반드시 copy_from_user()를 거쳐야 한다.
remove_proc_entry() 없이 rmmod 하면 커널 패닉이 난다.

다음 글에서는 `/dev` 디렉터리에 파일을 만들어 유저스페이스 앱과 `read()`/`write()`/`ioctl()`로 통신하는 Character Device Driver를 다룰 예정입니다.

참고 자료

Linux Kernel Documentation: Documentation/filesystems/proc.rst
linux/proc_fs.h, linux/seq_file.h 커널 소스
linux/uaccess.h — copy_from_user() 구현

Linux Kernel Module Parameters

onepaperhoon — Wed, 1 Apr 2026 19:27:46 +0900

1. Module Parameter가 왜 필요한가요?

이전 글에서 만든 Hello 모듈은 동작이 고정되어 있었습니다.

인사 횟수를 바꾸거나 이름을 바꾸려면 코드를 수정하고 다시 빌드해야 했죠.

실제 드라이버에서는 이런 상황이 자주 생깁니다.

GPIO 핀 번호를 하드코딩하지 않고 로드 시 지정하고 싶다.
디버그 로그를 켜고 끄고 싶다
디바이스 개수나 버퍼 크기를 유연하게 조정하고 싶다

이럴 때 Module Parameter를 씁니다.

# 파라미터 없이 로드 - 기본값 사용
sudo insmode params.ko

# 파라미터 지정해서 로드
sudo insmode params.ko count=3 name="Hoon" debug=1

코드 수정 없이 동작을 바꿀 수 있습니다.

2. module_param() 기본 문법

module_param(변수명, 타입, 권한);

세 가지만 기억하면 됩니다.

/* ① 변수 선언 — 기본값도 여기서 설정 */
static int   count = 1;
static char *name  = "OnePaperHoon";
static bool  debug = false;

/* ② module_param()으로 외부에 노출 */
module_param(count, int,  0644);
module_param(name,  charp, 0644);
module_param(debug, bool, 0644);

변수를 먼저 선언하고 기본값을 설정한 뒤,`module_param()`으로 커널에 등록하는 구조입니다.

`insmod`시 파라미터를 넘기지 않으면 선언 시의 기본값이 그대로 사용됩니다.

3. 파라미터 타입 종류

`module_param()`의 두 번째 인자로 쓸 수 있는 타입들입니다.

타입	C 변수 타입	설명
int	int	정수
long	long	긴 정수
short	short	짧은 정수
uint	unsigned int	부호 없는 정수
ulong	unsigned long	부호 없는 긴 정수
bool	bool	true / false (1 / 0)
charp	char *	문자열 포인터

이 코드에서 쓴 타입은 세 가지입니다.

static int   count = 1;       /* int   — 정수 */
static char *name  = "...";   /* charp — 문자열 */
static bool  debug = false;   /* bool  — true/false */

문자열은 `char`가 아니라 반드시 `charp`를 씁니다. `char`로 쓰면 컴파일 에러가 납니다.

4. 권한 (Permission) 설정

`module_param()`의 세 번쨰 인자는 sysfs에서의 접근 권한입니다. Linux 파일 권한과 동일한 8진수 표기법을 씁니다.

module_param(count, int, 0644);
/*                        ↑
 *   0 = 특수 권한 없음
 *   6 = owner: read(4) + write(2)
 *   4 = group: read(4)
 *   4 = other: read(4)
 */

권한값	sysfs 노출	읽기	쓰기	용도
`0000`	노출 안 됨	-	-	로드 시에만 설정 가능
`0444`	노출	가능	불가	읽기 전용 파라미터
`0644`	노출	가능	가능	런타임 변경 가능

이 코드는 세 파라미터 모두 `0644`로 설정했습니다. 즉 모듈 로드 후에도 sysfs를 통해 값을 읽고 쓸 수 있습니다.

커널 코드에서 권한값을 쓸 때는 `S_IRUGO`,`S_IWUSR` 같은 매크로를 쓰는 것이 더 명확합니다.
`S_IRUGO`는 모든 사용자 읽기 허용, `S_IWUSR`은 owner 쓰기 허용입니다.
`0644`는 `S_IRUGO | S_IWUSR`과 동일합니다.

5. MODULE_PARM_DESC()

파라미터에 설명을 붙입니다.

MODULE_PARM_DESC(count, "Number of greetings (default=1)");
MODULE_PARM_DESC(name,  "Name to greet (default=OnePaperHoon)");
MODULE_PARM_DESC(debug, "Enable debug mode (default=false)");

이렇게 해두면 `modinfo` 명령으로 파라미터 설명을 볼 수 있습니다.

$ modinfo params.ko
filename:       params.ko
description:    Kernel Module with Parameters - Week 5 Day 2
author:         OnePaperHoon
license:        GPL
version:        1.0
parm:           count:Number of greetings (default=1) (int)
parm:           name:Name to greet (default=OnePaperHoon) (charp)
parm:           debug:Enable debug mode (default=false) (bool)

협업하거나 나중에 다시 볼 때 `modinfo` 한 방으로 파라미터 목록과 의미를 확인할 수 있어서 반드시 작성하는 습관을 들이는 게 좋습니다.

6. sysfs를 통한 런타임 변경

`0644` 권한으로 등록한 파라미터는 모듈 로드 후에도 stsfs를 통해 값을 바꿀 수 있습니다.

# 파라미터 위치
/sys/module/<모듈명>/parameters/<파라미터명>

# 현재 값 읽기
$ cat /sys/module/params/parameters/count
1

# 런타임에 값 변경
$ echo 5 | sudo tee /sys/module/params/parameters/count
5

# 변경 확인
$ cat /sys/module/params/parameters/count
5

단, sysfs로 값을 바꿔도 이미 실행된 Init 함수는 다시 실행되지 않습니다.
런타임 변경이 의미 있으려면 모듈 내부 로직이 파라미터 변수를 주기적으로 참조하거나, 변경 시 콜백을 처리하는 구조여야 합니다.

7. 실습 - Raspberry Pi에서 직접 확인하기

파일 구성

params_module/
├── params.c
└── Makefile

Makefile

# Week 5 Day 2: Module Parameters
# Makefile for params module

obj-m := params.o

KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

all:
	@echo "========================================="
	@echo "Building params.ko kernel module..."
	@echo "========================================="
	$(MAKE) -C $(KDIR) M=$(PWD) modules
	@echo ""
	@echo "Build complete! Generated files:"
	@ls -lh params.ko 2>/dev/null || echo "Build failed!"

clean:
	@echo "Cleaning build files..."
	$(MAKE) -C $(KDIR) M=$(PWD) clean
	@echo "Clean complete!"

# 파라미터 없이 로드
load:
	@echo "========================================="
	@echo "Loading module (default parameters)..."
	@echo "========================================="
	sudo insmod params.ko
	@echo ""
	@echo "Kernel log:"
	dmesg | tail -15

# 파라미터와 함께 로드
load-custom:
	@echo "========================================="
	@echo "Loading module with custom parameters..."
	@echo "========================================="
	sudo insmod params.ko count=3 name="Hoon" debug=true
	@echo ""
	@echo "Kernel log:"
	dmesg | tail -15

# 언로드
unload:
	@echo "========================================="
	@echo "Unloading module..."
	@echo "========================================="
	sudo rmmod params
	@echo ""
	@echo "Kernel log:"
	dmesg | tail -10

# 모듈 정보
info:
	@echo "========================================="
	@echo "Module Information:"
	@echo "========================================="
	modinfo params.ko

# /sys 확인
sysfs:
	@echo "========================================="
	@echo "Module parameters in /sys:"
	@echo "========================================="
	@ls -la /sys/module/params/parameters/ 2>/dev/null || echo "Module not loaded"
	@echo ""
	@echo "Parameter values:"
	@cat /sys/module/params/parameters/* 2>/dev/null || echo "Module not loaded"

# 파라미터 런타임 변경
change-param:
	@echo "========================================="
	@echo "Changing parameters at runtime..."
	@echo "========================================="
	@echo "Before:"
	@cat /sys/module/params/parameters/count
	@echo ""
	@echo "Changing count to 5..."
	@echo 5 | sudo tee /sys/module/params/parameters/count
	@echo ""
	@echo "After:"
	@cat /sys/module/params/parameters/count

help:
	@echo "Available targets:"
	@echo "  make              - Build module"
	@echo "  make clean        - Clean build files"
	@echo "  make load         - Load with default params"
	@echo "  make load-custom  - Load with custom params"
	@echo "  make unload       - Unload module"
	@echo "  make info         - Show module info"
	@echo "  make sysfs        - Check /sys parameters"
	@echo "  make change-param - Change parameter at runtime"

.PHONY: all clean load load-custom unload info sysfs change-param help

명령어	동작
`make`	모듈 빌드 -> `params.ko` 생성
`make load`	기본 파라미터로 로드
`make load-custom`	`const=3 name="Hoon" debug=true`로 로드
`make unload`	모듈 언로드
`make info`	`modinfo`로 파라미터 목록 확인
`make sysfs`	`/sys`경로에서 현재 파라미터 값 확인
`make change-param`	런타임에 `count`를 5로 변경
`make clean`	빌드 파일 정리

params.c 전체

/*
 *
 * params.c - Kernel Module with Parameters
 * Week 5 Day 2: Module Parameters
 */

#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/moduleparam.h>

/*
 * 모듈 파라미터 선언
 */
static int count = 1;
static char *name = "OnepaperHoon";
static bool debug = false;

/*
 * module_param(변수명, 타입, 권한)
 * 권한:
 *   0000 - /sys에 나타나지 않음
 *   0444 - 읽기 전용
 *   0644 - 읽기 / 쓰기
 */

module_param(count, int, 0644);
MODULE_PARM_DESC(count, "Number of greetings (default=1)");

module_param(name, charp, 0644);
MODULE_PARM_DESC(name, "Name to greet (default=OnePaperGoon)");

module_param(debug, bool, 0644);
MODULE_PARM_DESC(debug, "Enable debug mode (default=false)");

/*
 * 모듈 초기화
 */
static int __init params_init(void) {
  int i;

  printk(KERN_INFO "=======================================\n");
  printk(KERN_INFO "Module Parameters Demo\n");
  printk(KERN_INFO "=======================================\n");

  if (debug) {
    printk(KERN_DEBUG "[DEBUG] Module loaded with:\n");
    printk(KERN_DEBUG " count = %d\n", count);
    printk(KERN_DEBUG " name = %s\n", name);
    printk(KERN_DEBUG " debug = %s\n", debug ? "true" : "false");
  }

  // count만큼 인사 출력
  for (i = 0; i < count; i++) {
    printk(KERN_INFO "Hello, %s", name);
  }
  printk("====================================\n");
  return 0;
}

static void __exit params_exit(void) {
  printk(KERN_INFO "======================================\n");
  printk(KERN_INFO "GoodBye, %s!\n", name);
  printk(KERN_INFO "Module unloaded\n");
  printk(KERN_INFO "======================================\n");
}

module_init(params_init);
module_exit(params_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("OnePaperHoon");
MODULE_DESCRIPTION("Kernel Module with Parameters - Week 5 Day 2");
MODULE_VERSION("1.0");

빌드 및 실행

$ make
=========================================
Building params.ko kernel module...
=========================================
make -C /lib/modules/6.1.21+/build M=/home/pi/params modules
  CC [M]  params.o
  LD [M]  params.ko
Build complete! Generated files:
-rw-r--r-- 1 pi pi 7.2K params.ko

$ make load-custom
=========================================
Loading module with custom parameters...
=========================================
sudo insmod params.ko count=3 name="Hoon" debug=true
Kernel log:
[DEBUG] count = 3
[DEBUG] name  = Hoon
[DEBUG] debug = true
Hello, Hoon!
Hello, Hoon!
Hello, Hoon!

$ make sysfs
=========================================
Module parameters in /sys:
=========================================
-rw-r--r-- 1 root root 4096 /sys/module/params/parameters/count
-rw-r--r-- 1 root root 4096 /sys/module/params/parameters/debug
-rw-r--r-- 1 root root 4096 /sys/module/params/parameters/name
Parameter values:
3
true
Hoon

8. 마치며

Module Parameter는 드라이버를 유연하게 만드는 핵심 도구입니다.

`module_param(변수, 타입, 권한)`으로 파라미터를 등록한다.
`MODULE_PARM_DESC()`로 설명을 반드시 붙인다.
`0644` 권한이면 sysfs로 런타임 변경도 가능하다.

실제 드라이버 코드를 보면 GPIO 핀 번호, 디바이스 주소, 디버그 레벨 같은 값들이 대부분 `module_param()`으로 노출되어 있습니다.
이제 그 코드가 낯설지 않을 겁니다.

다음 글에서는 `/proc`파일 시스템을 통해 커널 내부 정보를 유저 스페이스에서 읽는 방법을 다룰 예정입니다.

참고 자료

Linux Kernel Documentation: `Documetation/driver-api/basics.rst`
`linux/moduleparam.h` 커널 소스
`modinfo`,`sysfs` man page

Linux Kernel Module 개발 입문 - Hello World 부터 시작하기

onepaperhoon — Sat, 28 Mar 2026 20:19:34 +0900

1. 커널 모듈이란?

Linux 커널은 하나의 거대한 프로그램입니다. 그런데 모든 드라이버를 커널에 정적으로 포함시키면 커널 크기가 엄청나게 커지고, 새 드라이버를 추가할 때마다 커널을 다시 컴파일해야 합니다.

이 문제를 해결하는 것이 Kernel Module(커널 모듈) 입니다.

커널 모듈 = 실행 중인 커널에 동적으로 추가하거나 제거할 수 있는 코드 조각

USB를 꽂으면 드라이버가 자동으로 로드되고, 뽑으면 언로드되는 것이 바로 커널 모듈 덕분입니다.

Linux 커널 (실행 중)
┌─────────────────────────────────────┐
│  Core Kernel                     │
│  ┌──────────┐  ┌──────────┐        │
│  │ Module A │  │ Module B │  ← 동적 로드/언로드 가능
│  └──────────┘  └──────────┘        │
│  ┌──────────┐                     │
│  │ Module C │  ← 우리가 만들 것    │
│  └──────────┘                     │
└─────────────────────────────────────┘

커널 모듈로 만들 수 있는 것들:

디바이스 드라이버 (GPIO, I2C, SPI, UART 등)
파일시스템 (ext4, FAT 등)
네트워크 프로토콜
시스템 콜 후킹 (보안, 모니터링)

2. 유저스페이스 vs 커널스페이스

커널 모듈을 이해하려면 이 개념이 반드시 필요합니다.

Linux는 메모리를 두 영역으로 엄격하게 분리합니다.

메모리 공간

높은 주소 ┌─────────────────────┐
          │                  │
          │   Kernel Space   │ ← 커널, 드라이버, 모듈
          │   (보호된 영역)    │    직접 하드웨어 접근 가능
          │                  │
          ├────────────────────┤ ← 경계선 (ARM: 0xC0000000)
          │                  │
          │   User Space     │ ← 일반 앱 (bash, python 등)
          │   (제한된 영역)    │    하드웨어 직접 접근 불가
          │                  │
낮은 주소 └─────────────────────┘

유저스페이스

일반 애플리케이션이 실행되는 영역
하드웨어에 직접 접근 불가
잘못된 메모리 접근 → 프로세스만 죽음 (시스템은 안전)
printf(), malloc(), read() 같은 libc 함수 사용 가능

커널스페이스

커널과 드라이버가 실행되는 영역
하드웨어에 직접 접근 가능
잘못된 메모리 접근 → 커널 패닉, 시스템 다운
libc 사용 불가 → printk(), kmalloc() 같은 커널 API 사용

⚠️ 커널 모듈은 커널스페이스에서 실행됩니다. printf() 대신 printk(), malloc() 대신 kmalloc()을 써야 합니다. 잘못 짜면 시스템이 죽습니다.

유저스페이스에서 하드웨어에 접근하려면?

User App
   │
   │  시스템 콜 (read, write, ioctl ...)
   ▼
Kernel (드라이버)
   │
   │  레지스터 접근
   ▼
Hardware

유저 앱은 시스템 콜을 통해 커널에 요청하고, 커널(드라이버)이 대신 하드웨어를 제어합니다.

3. 커널 모듈 기본 구조

커널 모듈의 최소 구조는 딱 두 함수입니다.

#include <linux/init.h>
#include <linux/module.h>

/* 모듈 로드 시 실행 — insmod 할 때 */
static int __init hello_init(void)
{
    printk(KERN_INFO "Hello, Kernel!\n");
    return 0;  /* 0 반환 = 성공, 음수 반환 = 실패 */
}

/* 모듈 언로드 시 실행 — rmmod 할 때 */
static void __exit hello_exit(void)
{
    printk(KERN_INFO "Goodbye, Kernel!\n");
}

module_init(hello_init);  /* init 함수 등록 */
module_exit(hello_exit);  /* exit 함수 등록 */

/* 모듈 메타데이터 */
MODULE_LICENSE("GPL");
MODULE_AUTHOR("OnePaperHoon");
MODULE_DESCRIPTION("Hello Kernel Module");

각 요소 설명

__init / __exit 매크로

static int __init hello_init(void)

__init은 이 함수가 초기화 시에만 쓰인다는 힌트입니다. 모듈 로드 후 해당 함수 코드를 메모리에서 해제해 공간을 절약합니다.

printk() vs printf()

printk(KERN_INFO "Hello, Kernel!\n");

커널에는 printf()가 없습니다. 대신 printk()를 씁니다. 앞의 KERN_INFO는 로그 레벨입니다.

로그 레벨의미

KERN_EMERG	시스템 불능
KERN_ERR	에러
KERN_WARNING	경고
KERN_INFO	일반 정보
KERN_DEBUG	디버그

MODULE_LICENSE("GPL")

반드시 선언해야 합니다. GPL이 아닌 라이선스를 선언하면 일부 커널 심볼을 사용할 수 없고, 로드 시 "tainted kernel" 경고가 뜹니다.

4. Makefile 작성법

커널 모듈은 일반 C 프로그램과 빌드 방식이 다릅니다. 커널 빌드 시스템(Kbuild)을 활용합니다.

# Makefile

obj-m += hello.o          # 빌드할 모듈 이름 (.o 확장자)

# Raspberry Pi에서 직접 빌드할 경우
KDIR := /lib/modules/$(shell uname -r)/build

all:
	make -C $(KDIR) M=$(PWD) modules

clean:
	make -C $(KDIR) M=$(PWD) clean

Makefile 핵심 설명

obj-m

obj-m은 "이 파일을 모듈로 빌드하라"는 Kbuild 문법입니다. obj-y는 커널에 정적으로 포함시키는 것이고, obj-m은 동적 모듈(.ko 파일)로 빌드합니다.

$(KDIR)

현재 실행 중인 커널의 빌드 디렉토리입니다. uname -r로 커널 버전을 가져와 경로를 자동으로 맞춥니다. 크로스 컴파일(다른 머신에서 빌드)할 때는 이 경로를 대상 보드의 커널 소스로 바꿉니다.

-C $(KDIR) M=$(PWD)

커널 빌드 시스템 디렉토리로 이동해서(-C), 현재 디렉토리(M=$(PWD))의 모듈을 빌드하라는 뜻입니다.

5. 빌드 및 실행 — insmod / rmmod / lsmod

빌드

$ make

성공하면 hello.ko 파일이 생성됩니다. .ko가 커널 오브젝트(Kernel Object), 즉 모듈 파일입니다.

$ ls -l
-rw-r--r-- hello.c
-rw-r--r-- Makefile
-rw-r--r-- hello.ko   ← 이게 생겼으면 성공

모듈 로드 — insmod

$ sudo insmod hello.ko

insmod는 insert module의 약자입니다. 커널에 모듈을 삽입합니다.

로드 확인 — lsmod

$ lsmod | grep hello
hello                  16384  0

lsmod는 현재 로드된 모듈 목록을 보여줍니다. grep으로 필터링해서 확인합니다.

printk 출력 확인 — dmesg

$ dmesg | tail -5
[  123.456789] Hello, Kernel!

printk() 출력은 터미널에 바로 보이지 않습니다. 커널 로그 버퍼에 저장되고, dmesg 명령으로 확인합니다.

모듈 언로드 — rmmod

$ sudo rmmod hello
$ dmesg | tail -5
[  123.456789] Hello, Kernel!
[  145.678901] Goodbye, Kernel!

rmmod는 remove module의 약자입니다.

명령어 정리

명령어기능

insmod hello.ko	모듈 로드
rmmod hello	모듈 언로드
lsmod	로드된 모듈 목록
modinfo hello.ko	모듈 정보 출력
dmesg	커널 로그 확인

6. 실습 — Raspberry Pi에서 Hello, Kernel!

환경 준비

# 커널 헤더 설치 (Raspberry Pi OS 기준)
$ sudo apt update
$ sudo apt install kernel-headers-$(uname -r)

# 설치 확인
$ ls /lib/modules/$(uname -r)/build
```

### 파일 구성
```
hello_module/
├── hello.c
└── Makefile

hello.c

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

static int __init hello_init(void)
{
    printk(KERN_INFO "[hello] module loaded\n");
    printk(KERN_INFO "[hello] kernel version: %s\n", UTS_RELEASE);
    return 0;
}

static void __exit hello_exit(void)
{
    printk(KERN_INFO "[hello] module unloaded\n");
}

module_init(hello_init);
module_exit(hello_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("OnePaperHoon");
MODULE_DESCRIPTION("Hello Kernel Module for Raspberry Pi");
MODULE_VERSION("1.0");

빌드 및 실행

# 빌드
$ make
make -C /lib/modules/6.1.21+/build M=/home/pi/hello_module modules
  CC [M]  /home/pi/hello_module/hello.o
  MODPOST /home/pi/hello_module/Module.symvers
  CC [M]  /home/pi/hello_module/hello.mod.o
  LD [M]  /home/pi/hello_module/hello.ko
make[1]: Leaving directory '/usr/src/linux-headers-6.1.21+'

# 로드
$ sudo insmod hello.ko

# 확인
$ dmesg | tail -3
[ 1234.567] [hello] module loaded
[ 1234.568] [hello] kernel version: 6.1.21+

# 언로드
$ sudo rmmod hello
$ dmesg | tail -1
[ 1289.012] [hello] module unloaded

7. 자주 하는 실수 모음

❌ 실수 1: printf() 사용

/* 나쁜 예 — 컴파일 에러 */
printf("Hello\n");

/* 좋은 예 */
printk(KERN_INFO "Hello\n");

커널 모듈에서 libc 함수는 사용할 수 없습니다.

❌ 실수 2: init에서 0이 아닌 값 반환

static int __init hello_init(void)
{
    /* 초기화 실패 상황 */
    return 1;  /* 나쁜 예 — 양수 반환 */
    return -ENOMEM;  /* 좋은 예 — errno 음수값 반환 */
}

init 함수는 실패 시 반드시 음수 errno 값을 반환해야 합니다. 양수를 반환하면 예상치 못한 동작이 생길 수 있습니다.

❌ 실수 3: 커널 버전 불일치

$ sudo insmod hello.ko
insmod: ERROR: could not insert module hello.ko: Invalid module format

모듈은 빌드한 커널 버전과 로드할 커널 버전이 정확히 일치해야 합니다. 커널 업데이트 후에는 반드시 재빌드하세요.

# 현재 커널 버전 확인
$ uname -r
6.1.21+

# 모듈이 빌드된 커널 버전 확인
$ modinfo hello.ko | grep vermagic
vermagic: 6.1.21+ SMP preempt mod_unload modversions ARMv7

8. 마치며

커널 모듈은 Linux 드라이버 개발의 시작점입니다.

커널 모듈은 커널스페이스에서 실행된다 — 실수하면 시스템이 죽는다.
printf 대신 printk, malloc 대신 kmalloc.
빌드한 커널 버전과 로드할 커널 버전이 일치해야 한다.

Hello World 수준이지만, 이 구조를 이해하면 GPIO 제어, I2C 드라이버, character device 구현까지 자연스럽게 이어집니다.

STM32 NVIC, 인터럽트 우선순위 완전 정복

onepaperhoon — Tue, 24 Mar 2026 21:38:28 +0900

"버튼 누르면 UART 수신이 씹혀요", "두 인터럽트가 동시에 터졌는데 어떻게 되나요?"
NVIC를 모르면 반드시 겪는 문제들입니다.

1. 인터럽트가 뭔가요?

CPU는 기본적으로 코드를 위에서 아래로 순서대로 실행합니다.

그런데 현실에서는 "지금 당장" 처리해야 할 일이 생깁니다.

버튼이 눌렸다
UART로 데이터가 들어왔다
타이머가 만료됐다

이럴 때 CPU에게 "하던 일 잠깐 멈추고 이거 먼저 처리해"라고 신호를 보내는 것이 인터럽트 (Interrupt)입니다.

일반 실행 흐름:

main() ──────────────────────────────────────►
         [코드 A] [코드 B]  [코드 C] [코드 D]


인터럽트 발생 시:

main() ──────────────┐         ┌──────────────►
         [코드 A] [코드 B]     [코드 C] [코드 D]
                     │         ↑
                     ▼         │ 복귀
                  [ISR 실행] ───┘

CPU는 하던 일을 잠깐 멈추고 ISR(Interrupt Service Routine)을 실행한 뒤, 원래 자리로 돌아옵니다.

2. NVIC란?

NVIC = Nested Vectored Interrupt Controller

이름을 풀면

단어	의미
Nested	인터럽트 안에서 더 높은 우선순위 인터럽트가 끼어들 수 있음
Vectored	각 인터럽트마다 처리 함수(ISR) 주소가 벡터 테이블에 등록됨
Interrupt Controller	인터럽트를 관리하는 하드웨어 블록

쉽게 말하면 "인터럽트 교통정리 담당자"입니다.

여러 인터럽트가 동시에 발생했을 때:

어떤 걸 먼저 처리할지 결정하고
더 급한 인터럽트가 오면 현재 ISR을 중단하고 그것부터 처리하게 해주는

하드웨어 모듈이 NVIC입니다.

NVIC는 ARM Cortex-M 코어에 내장된 기능입니다.
STM32 뿐 아니라 Cortex-M 기반 MCU라면 모두 동일한 개념이 적용됩니다.

3. NVIC 핵심 개념

우선순위 숫자, 낮을수록 높다

NVIC에서 우선순위 숫자가 낮을수록 높습니다.

Priority 0  →  가장 높은 우선순위 (가장 급함)
Priority 1  →  그 다음
Priority 2  →  그 다음
...
Priority 15 →  가장 낮은 우선순위

처음엔 헷갈리지만, "0번이 1등"이라고 기억하면 됩니다.

Priority Group (우선순위 그룹)

STM32는 우선순위를 두 파트로 나눠서 관리합니다.

4비트 우선순위 레지스터
┌────────────────────────────────────────┐
│  Preemption Priority │ Subpriority  │
└────────────────────────────────────────┘

이 4비트를 어떻게 나눌지 결정하는 것이 Priority Group 설정입니다.

Priority Group	Preemption 비트	Subpriority 비트	Preemption 단계	Subpriority 단계
NVIC_PRIORITYGROUP_0	0비트	4비트	1단계	16단계
NVIC_PRIORITYGROUP_1	1비트	3비트	2단계	8단계
NVIC_PRIORITYGROUP_2	2비트	2비트	4단계	4단계
NVIC_PRIORITYGROUP_3	3비트	1비트	8단계	2단계
NVIC_PRIORITYGROUP_4	4비트	0비트	16단계	1단계

STM32 HAL의 기본값은 NVIC_PRIORITYGROUP_4 (Preemption 4비트, Subpriority 없음)입니다.

4. Preemption vs Subpriority, 뭐가 다른가요?

이게 NVIC에서 가장 헷갈리는 부분입니다. 핵심만 짚겠습니다.

Preemption Priority (선점 우선순위)

"실행 중인 ISR을 중단시킬 수 있는가"를 결정합니다.

상황: ISR_A 실행 중 → ISR_B 발생

ISR_B의 Preemption이 ISR_A보다 높으면:
  ISR_A 중단 → ISR_B 실행 → ISR_A 재개  ← 선점(Preemption) 발생

ISR_B의 Preemption이 ISR_A보다 낮거나 같으면:
  ISR_A 완료 → ISR_B 실행  ← 선점 없음

Subpriority (부우 선순위)

"같은 Preemption 우선순위끼리 동시에 발생했을 때 누가 먼저냐"를 결정합니다.

Subpriority는 선점을 일으키지 않습니다
동시에 pending 상태일 때 처리 순서만 결정합니다

정리

비교 항목	Preemption Priority	Subpriority
선점 가능 여부	가능	불가능
영향 범위	실행 중인 ISR을 끊음	대기 중인 인터럽트 순서만 결정
중요도	더 중요	덜 중요

실무 팁 : 대부분의 STM32 프로젝트에서는 NVIC_PRIORITYGROUP_4를 쓰고 Preemption만 관리합니다. Subpriority까지 쓰면 복잡도만 올라갑니다.

5. STM32 CubeMX에서 NVIC 설정하기

CubeMX에서 NVIC 설정은 두 곳에서 합니다.

① System Core → NVIC 탭

Pinout & Configuration
└── System Core
    └── NVIC
        ├── Priority Group 선택  ← 전체 그룹 설정
        └── 각 인터럽트별 Enable / Priority 설정

② 각 Peripheral 설정 탭의 NVIC 섹션

예를 들어 USART2를 설정할 때:

Connectivity → USART2 → NVIC Settings 탭
    [✓] USART2 global interrupt   Preemption: 1   Sub: 0

설정 예시 — 버튼(EXTI) + UART 수신 공존

Priority Group: NVIC_PRIORITYGROUP_4 (Preemption 4비트)

EXTI0 (버튼)         Preemption: 2
USART2 (UART RX)     Preemption: 1  ← 더 높은 우선순위
TIM2 (타이머)         Preemption: 3

UART 수신이 더 급하다고 판단해 우선순위를 높게 (숫자 낮게) 설정한 예입니다.

6. 실제 코드로 확인하기

CubeMX가 생성해 주는 코드를 보면 NVIC 설정이 어떻게 되는지 이해할 수 있습니다.

HAL이 생성하는 초기화 코드

/* main.c 또는 stm32f4xx_hal_msp.c */

/* Priority Group 설정 (HAL_Init() 내부에서 자동 호출) */
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);

/* USART2 인터럽트 설정 */
HAL_NVIC_SetPriority(USART2_IRQn, 1, 0);  // Preemption=1, Sub=0
HAL_NVIC_EnableIRQ(USART2_IRQn);

/* EXTI0 (버튼) 인터럽트 설정 */
HAL_NVIC_SetPriority(EXTI0_IRQn, 2, 0);   // Preemption=2, Sub=0
HAL_NVIC_EnableIRQ(EXTI0_IRQn);

ISR 등록 — stm32 f4 xx_it.c

/* USART2 인터럽트 핸들러 */
void USART2_IRQHandler(void)
{
    HAL_UART_IRQHandler(&huart2);  // HAL이 내부에서 콜백 호출
}

/* EXTI0 인터럽트 핸들러 */
void EXTI0_IRQHandler(void)
{
    HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);
}

콜백 함수에서 실제 처리

/* UART 수신 완료 콜백 */
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
    if (huart->Instance == USART2)
    {
        /* 수신된 데이터 처리 */
        /* ISR 안이므로 최대한 짧게 — 플래그 세우고 main에서 처리 권장 */
        rx_flag = 1;
    }
}

/* GPIO EXTI 콜백 */
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
    if (GPIO_Pin == GPIO_PIN_0)
    {
        /* 버튼 처리 */
    }
}

선점이 실제로 일어나는 상황

/* 시나리오:
   EXTI0 ISR 실행 중 → USART2 인터럽트 발생
   USART2 Preemption(1) < EXTI0 Preemption(2) → 선점 발생 */

void EXTI0_IRQHandler(void)
{
    // 여기 실행 중...
    HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);
    // ↑ 이 중간에 USART2 인터럽트가 오면
    //   EXTI0 ISR이 중단되고 USART2_IRQHandler가 먼저 실행됨
    //   USART2 완료 후 여기로 복귀
}

7. 자주 하는 실수 모음

❌ 실수 1: ISR 안에서 오래 걸리는 작업

/* 나쁜 예 */
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
    HAL_Delay(100);          // ISR 안에서 delay — 절대 금지!
    process_large_buffer();  // 무거운 연산 — 금지!
}

/* 좋은 예 */
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
    rx_flag = 1;  // 플래그만 세우고
                  // 실제 처리는 main loop에서
}

ISR은 최대한 짧게, 플래그 세우고 빠져나오는 것이 원칙입니다.

❌ 실수 2: FreeRTOS와 함께 쓸 때 우선순위 범위 착각

FreeRTOS를 사용하는 경우 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 이상의 우선순위(낮은 숫자)를 가진 ISR 안에서는 FreeRTOS API를 호출하면 안 됩니다.

/* FreeRTOS 사용 시 — ISR 안에서는 FromISR 버전 사용 */
xQueueSendFromISR(queue, &data, &xHigherPriorityTaskWoken);

❌ 실수 3: Priority Group 중간에 변경

Priority Group을 바꾸면 이미 설정된 모든 인터럽트 우선순위 해석이 달라집니다. 반드시 초기화 시점에 한 번만 설정하세요.

8. 마치며

NVIC를 이해하면 임베디드 개발에서 겪는 타이밍 버그의 절반은 원인을 파악할 수 있게 됩니다.

우선순위 숫자가 낮을수록 높다.
Preemption은 선점, Subpriority는 대기 순서.
ISR은 짧게, 무거운 일은 main loop에서.

이 세 가지만 기억해도 NVIC 관련 문제의 대부분을 다룰 수 있습니다.

다음 글에서는 UART Interrupt 모드와 DMA 모드를 비교하며, NVIC 설정이 실제 통신 안정성에 어떤 영향을 주는지 실습해 볼 예정입니다.

UART 통신, 제대로 이해하기

onepaperhoon — Tue, 24 Mar 2026 21:38:09 +0900

임베디드를 시작하면 가장 먼저 만나는 통신 프로토콜, UART. "그냥 시리얼 통신이잖아요"라고 넘기기기엔 아는 만큼 보이는 게 달라집니다.

1. UART가 뭔가요?

UART는 Universal Asynchronous Receiver/Transmitter의 약자입니다.

이름을 풀어보면 그 자체로 설명이 됩니다.

단어	의미
Universal	다양한 디바이스와 호환
Asynchronous	클럭 신호 없이 통신 (비동기)
Receiver/Transmitter	송신과 수신을 모두 담당

임베디드 개발을 하다 보면 UART를 가장 먼저, 가장 많이 만납니다. MCU와 PC를 연결해 디버깅 메시지를 출력하거나, 두 MCU끼리 데이터를 주고받을 때 쓰입니다.

2. 직렬 vs 병렬 통신

UART를 이해하려면 먼저 직렬(Serial) 통신이 무엇인지 알아야 합니다.

병렬 통신 (Parallel)

데이터: 0b10110101

선 8개 → 한 번에 8비트 전송
D7 ──────────────
D6 ──────────────
D5 ──────────────
...
D0 ──────────────

빠르지만 선이 많이 필요하고, 거리가 멀어질수록 신호 간 간섭(노이즈) 문제가 생깁니다.

직렬 통신 (Serial)

데이터: 0b10110101

선 1개 → 1비트씩 순서대로 전송
TX ─ 1 ─ 0 ─ 1 ─ 1 ─ 0 ─ 1 ─ 0 ─ 1 ──

선이 적고 안정적입니다. 느린 것처럼 보이지만, Baud Rate를 높이면 충분히 빠릅니다.

UART는 직렬 통신입니다.

3. UART의 동작 원리

연결 구조

UART는 단 2개의 선으로 통신합니다.

MCU A                MCU B
  
  TX  ───────────────► RX
  RX  ◄─────────────── TX
  GND ─────────────── GND  ← 반드시 공통 GND!

GND를 꼭 연결해야 합니다. 전압 기준이 달라지면 신호를 제대로 읽지 못합니다.

비동기(Asynchronous)란?

I2C나 SPI 같은 통신은 클럭 신호(CLK)를 함께 보내서 "지금 데이터 읽어"라는 타이밍을 맞춥니다.

UART는 클럭이 없습니다. 그럼 어떻게 타이밍을 맞출까요?

송수신 양쪽이 미리 같은 속도 (Baud Rate)를 약속합니다.

약속된 속도를 기준으로 수신 측이 스스로 타이밍을 계산해 비트를 읽습니다.

이 "약속"이 조금이라도 어긋나면 데이터가 깨집니다. 그래서 파라미터 설정이 중요합니다.

4. 핵심 파라미터

UART를 쓸 때 반드시 양쪽이 동일하게 설정해야 하는 4가지입니다.

① Baud Rate (보드레이트)

1 초에 몇 비트를 전송하는가를 나타냅니다.

주요 Baud Rate	특징
9600	가장 기본값, 느리지만 안정적
115200	임베디드 개발에서 가장 많이 씀
921600이상	고속, 노이즈에 민감

예를 들어 115200 bps라면, 1비트를 전송하는 데 걸리는 시간은 약 8.68 μs입니다.

② 데이터 비트 (Data Bits)

한 번에 전송하는 데이터의 비트 수입니다. 보통 8비트를 씁니다. (7비트도 가능)

③ 패리티 비트 (Parity Bit)

오류 검출을 위한 비트입니다. 보통 None(없음)으로 설정합니다.

설정	의미
None	패리티 없음 (가장 일반적)
Even	1의 개수가 짝수가 되도록
Odd	1의 개수가 홀수가 되도

④ 스톱 비트 (Stop Bit)

프레임의 끝을 알리는 비트입니다. 보통 1비트를 씁니다.

정리: "115200 8N1"

임베디드 개발에서 UART 설정을 간단히 표현할 때 이런 식으로 씁니다.

115200  8   N   1
  │     │   │   └─ Stop bit: 1
  │     │   └───── Parity: None
  │     └───────── Data bits: 8
  └─────────────── Baud Rate: 115200

5. UART 프레임 구조

실제로 데이터가 어떻게 전송되는지 프레임 구조를 보면 명확해집니다.

평상시 (Idle) → Start → D0 D1 D2 D3 D4 D5 D6 D7 → (Parity) → Stop → Idle

HIGH ─────┐                                           ┌──────────
          │  S  0  1  0  1  0  0  0  1  N  P         │
LOW       └──────────────────────────────────────────────┘
          ↑                                              ↑
        Start bit (항상 LOW)                    Stop bit (항상 HIGH)

Idle 상태: 아무것도 안 보낼 때는 HIGH를 유지합니다
Start bit: 전송 시작을 알리는 LOW 신호 1비트
Data bits: LSB(최하위 비트)부터 순서대로 전송
Stop bit: 전송 종료를 알리는 HIGH 신호

6. UART vs USART

STM32 같은 MCU의 데이터시트를 보면 USART라는 용어가 자주 등장합니다.

	UART	USART
풀네임	Universal Aysnc R/T	Universal Sync/Async R/T
클럭 라인	없음	있음 (동기 모드 지원)
일반 사용	비동기 통신	대부분 비동기로 사용

USART는 UART의 상위 호환입니다. 동기 모드 (SCLK 포함)도 지원하지만, 실제로는 대부분 비동기 (UART) 모드로 사용합니다.

7. 실제로 어디에 쓰이나요?

임베디드 개발에서 UART가 활약하는 대표적인 상황들입니다.

디버깅 (가장 중요!)
`printf()`로 변수값이나 상태 메시지를 PC 터미널에 출력합니다. 임베디드에서의 `console.log()`라고 생각하면 됩니다.
GPS 모듈 연동
GPS 모듈은 대부분 UART로 NMEA 포맷 데이터를 전송합니다.
블루투스/Wi-Fi 모듈
HC-06, ESP8266 같은 모듈이 UART로 MCU와 통신합니다.
MCU 간 통신
두 MCU가 간단한 데이터를 주고받을 때 UART가 편리합니다.

8. 마치며

UART는 단순해 보이지만, 임베디드 개발의 기초 중 기초입니다.

Baud Rate가 다르면 데이터가 깨져서 해석이 불가능하다
GND를 연결하지 않으면 통신이 안 된다.
TX->RX, RX->TX로 교차 연결해야 한다.

이 세 가지만 기억해도 UART 관련트러블 슈팅의 절반은 해결됩니다.

[IPC] Shared Memory - 가장 빠른 프로세스 간 통신

onepaperhoon — Fri, 27 Feb 2026 16:03:55 +0900

들어가며

지난 글에서 FIFO (Named Pipe)를 다뤘는데, 실습하면서 한 가지 아쉬운 점이 있었습니다. 바로 속도였죠. 간단한 메시지 주고받기에는 충분했지만, 큰 데이터를 전송하려니 느렸습니다.

왜 느릴까요? FIFO는 Kernel을 거쳐서 데이터를 복사하기 때문입니다.

FIFO 방식:
Writer → [User Space]
       ↓ (복사!)
     [Kernel Space]
       ↓ (또 복사!)
     [User Space] → Reader

→ 2번 복사! 느림!

"메모리를 그냥 공유하면 안 되나?" 라는 생각이 들었습니다. 그게 바로 오늘 다룰 Shared Memory (공유 메모리)입니다.

Shared Memory란?

개념

Shared Memory는 여러 프로세스가 같은 메모리 영역을 공유하는 IPC 방식입니다. 복사 없이 직접 접근하기 때문에 IPC 중 가장 빠릅니다.

Shared Memory 방식:
Process A ──→ [Shared Memory] ←── Process B
             (공유된 메모리)

→ 복사 없음! 빠름!

성능 비교 (1MB 데이터 전송)

직접 벤치마크를 돌려봤습니다:

FIFO:            8.5 ms
Shared Memory:   0.8 ms

→ 약 10배 차이

FIFO vs Shared Memory

특징	FIFO	Shared Memory
속도	보통 (~8ms)	매우 빠름 (~0.8ms)
복사	2번 (User→Kernel→User)	0번
동기화	자동 (Kernel이 처리)	수동 (Semaphore 필요)
사용 난이도	쉬움	중간
데이터 크기	작은 메시지	큰 데이터

언제 뭘 쓸까?

간단한 통신 → FIFO
대용량 데이터 → Shared Memory
실시간 성능 중요 → Shared Memory

실전: Shared Memory 구현

이론은 여기까지! 직접 만들어 봅시다.

POSIX vs System V

Shared Memory에는 두 가지 API가 있습니다:

System V: 오래된 방식 (shmget, shmat)
POSIX:    최신 방식 (shm_open, mmap)

→ POSIX를 사용합니다 (더 깔끔함)

1단계: Shared Memory 생성

#include <sys/mman.h>
#include <fcntl.h>

#define SHM_NAME "/my_shm"
#define SHM_SIZE 4096

int main(void)
{
    // 1. Shared Memory 객체 생성
    int fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666);
    if (fd == -1) {
        perror("shm_open");
        exit(1);
    }

    // 2. 크기 설정
    ftruncate(fd, SHM_SIZE);

    // 3. 메모리 매핑
    void *ptr = mmap(NULL, SHM_SIZE, 
                     PROT_READ | PROT_WRITE,
                     MAP_SHARED, fd, 0);

    if (ptr == MAP_FAILED) {
        perror("mmap");
        exit(1);
    }

    printf("Shared Memory created!\n");
    printf("Address: %p\n", ptr);

    // 이제 ptr을 일반 메모리처럼 사용!
    strcpy(ptr, "Hello, Shared Memory!");

    return 0;
}

2단계: Writer 프로그램

// shm_writer.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>

#define SHM_NAME "/chat_shm"
#define SHM_SIZE 4096

int main(void)
{
    // SHM 생성
    int fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666);
    ftruncate(fd, SHM_SIZE);

    // 메모리 매핑
    char *ptr = mmap(NULL, SHM_SIZE, 
                     PROT_READ | PROT_WRITE,
                     MAP_SHARED, fd, 0);

    printf("=== Writer ===\n");
    printf("Enter messages (type 'quit' to exit):\n");

    while (1) {
        printf("You: ");
        fgets(ptr, SHM_SIZE, stdin);

        if (strncmp(ptr, "quit", 4) == 0)
            break;

        printf("Written to shared memory!\n");
        sleep(1);  // Reader가 읽을 시간
    }

    // 정리
    munmap(ptr, SHM_SIZE);
    close(fd);
    shm_unlink(SHM_NAME);

    return 0;
}

3단계: Reader 프로그램

// shm_reader.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>

#define SHM_NAME "/chat_shm"
#define SHM_SIZE 4096

int main(void)
{
    // SHM 열기
    int fd = shm_open(SHM_NAME, O_RDONLY, 0666);
    if (fd == -1) {
        perror("shm_open");
        exit(1);
    }

    // 메모리 매핑
    char *ptr = mmap(NULL, SHM_SIZE,
                     PROT_READ,
                     MAP_SHARED, fd, 0);

    printf("=== Reader ===\n");
    printf("Reading from shared memory...\n");

    char prev[SHM_SIZE] = {0};

    while (1) {
        // 내용이 바뀌었으면 출력
        if (strcmp(ptr, prev) != 0) {
            printf("Received: %s", ptr);
            strcpy(prev, ptr);

            if (strncmp(ptr, "quit", 4) == 0)
                break;
        }

        usleep(100000);  // 100ms마다 체크
    }

    // 정리
    munmap(ptr, SHM_SIZE);
    close(fd);

    return 0;
}

컴파일 & 실행

# 컴파일 (중요: -lrt 옵션!)
$ gcc shm_writer.c -o writer -lrt
$ gcc shm_reader.c -o reader -lrt

# 터미널 1
$ ./reader
=== Reader ===
Reading from shared memory...

# 터미널 2
$ ./writer
=== Writer ===
Enter messages:
You: Hello!
Written to shared memory!

# 터미널 1 출력
Received: Hello!

함정: 동기화 문제

처음 실행했을 때 이상한 현상이 발생했습니다.

Writer: "Hello World!"
Reader: "Hello Wor"
Reader: "Hello World!"
Reader: "Hello World!!@#$%"  ← 쓰레기 값!

문제: Writer가 쓰는 도중에 Reader가 읽음!

Race Condition

T0: Writer: ptr[0] = 'H'
T1: Writer: ptr[1] = 'e'
T2: Reader: 읽기! → "He" (불완전!)
T3: Writer: ptr[2] = 'l'
...

이게 바로 Race Condition입니다. FIFO는 Kernel이 알아서 처리해줬는데, Shared Memory는 우리가 직접 처리해야 합니다!

해결책: Semaphore

Semaphore로 동기화를 구현합니다.

#include <semaphore.h>

sem_t *sem;

// Writer
sem = sem_open("/my_sem", O_CREAT, 0666, 1);

sem_wait(sem);      // Lock
strcpy(ptr, msg);   // 쓰기
sem_post(sem);      // Unlock

// Reader
sem_wait(sem);      // Lock
strcpy(buf, ptr);   // 읽기
sem_post(sem);      // Unlock

완전한 코드:

// shm_writer_sync.c
int main(void)
{
    int fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666);
    ftruncate(fd, SHM_SIZE);
    char *ptr = mmap(NULL, SHM_SIZE, 
                     PROT_READ | PROT_WRITE,
                     MAP_SHARED, fd, 0);

    // Semaphore 생성
    sem_t *sem = sem_open("/chat_sem", O_CREAT, 0666, 1);

    while (1) {
        printf("You: ");
        char msg[256];
        fgets(msg, sizeof(msg), stdin);

        if (strncmp(msg, "quit", 4) == 0)
            break;

        // Critical Section
        sem_wait(sem);
        strcpy(ptr, msg);
        sem_post(sem);

        printf("Written safely!\n");
    }

    // 정리
    sem_close(sem);
    sem_unlink("/chat_sem");
    munmap(ptr, SHM_SIZE);
    close(fd);
    shm_unlink(SHM_NAME);

    return 0;
}

이제 안전합니다!

Shared Memory의 특징

1. 파일처럼 보이지만 메모리

# SHM 확인
$ ls -l /dev/shm/
-rw-r--r-- 1 user user 4096 Feb 27 15:00 chat_shm

→ /dev/shm에 파일처럼 생김
→ 실제로는 RAM!

2. 프로세스 종료 후에도 남아있음

$ ./writer  # 실행 후 종료

$ ls /dev/shm/
chat_shm  # 여전히 존재!

→ 명시적으로 삭제 필요: shm_unlink()

3. 크기 제한

# 시스템 최대 크기 확인
$ cat /proc/sys/kernel/shmmax
18446744073692774399  # 약 16EB (충분함)

# 실제 사용 중인 SHM
$ ipcs -m

실무 활용 사례

1. 고성능 데이터베이스

PostgreSQL, Redis 등:
- Index를 SHM에 캐싱
- 여러 프로세스가 동시 접근
- 빠른 읽기 성능

2. 멀티미디어 처리

비디오/오디오 스트리밍:
- 프레임 버퍼를 SHM에
- Encoder/Decoder가 공유
- 복사 없이 처리 → 실시간 가능

3. IPC 최적화

대용량 데이터 전송:
- 파일 공유
- 메모리 캐시
- 공유 큐

주의사항

1. 동기화 필수!

// ❌ 위험
strcpy(shm_ptr, data);  // Race Condition!

// ✅ 안전
sem_wait(sem);
strcpy(shm_ptr, data);
sem_post(sem);

2. 크기 설정 필수

// ftruncate() 없으면 크기가 0!
shm_open(...);
ftruncate(fd, SIZE);  // 필수!
mmap(...);

3. 정리 필수

// 프로그램 종료 시
munmap(ptr, SIZE);
close(fd);
shm_unlink(SHM_NAME);  // 삭제!

안 하면 /dev/shm에 파일 계속 남음!

성능 측정

직접 벤치마크를 돌려봤습니다.

테스트 환경

CPU: Apple M1
RAM: 16GB
OS: macOS (Linux 유사)
데이터: 1MB

결과

// FIFO
for (int i = 0; i < 1000; i++) {
    write(fifo_fd, data, 1024);
}
→ 평균: 8.5ms

// Shared Memory
for (int i = 0; i < 1000; i++) {
    memcpy(shm_ptr, data, 1024);
}
→ 평균: 0.8ms

속도 차이: 약 10배!

디버깅 팁

SHM 확인

# 현재 SHM 목록
$ ls -lh /dev/shm/

# SHM 크기 확인
$ du -h /dev/shm/chat_shm
4.0K    /dev/shm/chat_shm

# SHM 내용 보기
$ cat /dev/shm/chat_shm
Hello, Shared Memory!

ipcs 명령어

# System V SHM (옛날 방식)
$ ipcs -m

# 특정 SHM 삭제
$ ipcrm -m <shmid>

gdb로 메모리 확인

$ gdb ./writer
(gdb) break main
(gdb) run
(gdb) print ptr
$1 = 0x7f1234567000

(gdb) x/10s 0x7f1234567000
0x7f1234567000: "Hello"

마치며

Shared Memory를 구현하면서 속도와 안전성의 트레이드오프를 배웠습니다.

배운 점:

복사 없는 직접 접근 → 10배 빠름
동기화는 직접 해야 함 (Semaphore)
ftruncate() 필수
shm_unlink()로 정리 필수
/dev/shm에서 확인 가능

FIFO는 간단하지만 느리고, Shared Memory는 빠르지만 복잡합니다. 상황에 맞게 선택하는 게 중요합니다.

FIFO (Named Pipe) : 프로세스 간 통신의 기본

onepaperhoon — Sun, 22 Feb 2026 17:35:22 +0900

들어가며

프로세스 간 통신(IPC)을 공부하다 보면 가장 먼저 만나는 개념이 Pipe입니다.
그런데 Pipe는 부모-자식 프로세스처럼 혈연관계가 있는 프로세스들끼리만 통신할 수 있다는 제약이 있죠.

만약 완전히 독립적인 두 프로그램이 통신하려면 어떻게 해야 할까요?
바로 여기서 FIFO(Named Pipe)가 등장합니다.

이 글에서 FIFO의 개념부터 실제 구현까지, 직접 코드를 작성하며 겪은 문제들과 해결 과정을 공유하겠습니다.

FIFO란?

FIFO = First In First Out

FIFO는 "First In First Out"의 약자로, 먼저 들어간 데이터가 먼저 나오는 자료구조입니다.

마치 은행 대기줄처럼 선착순으로 처리되죠.

입구 →  [A][B][C][D]  → 출구
        ↑           ↓
      나중에       먼저
      들어감       나감

Named Pipe = FIFO

Linux에서 FIFO는 "Named Pipe"라고도 불립니다.

왜냐하면 일반 Pipe와 달리 파일시스템에 이름을 가진 파일로 존재하기 때문입니다.

$ mkfifo /tmp/myfifo
$ ls -l /tmp/myfifo
prw-rw-r-- 1 user user 0 Feb 21 10:00 /tmp/myfifo
↑
p = pipe (FIFO)

파일 타입이 `p`로 표시되는 것을 볼 수 있습니다. 이것이 바로 FIFO 파일입니다.

Pipe vs FIFO

두 개념을 비교하면 차이가 명확해집니다.

특징	Pipe	FIFO (Named Pipe)
이름	익명 (이름 없음)	파일명으로 접근
프로세스 관계	부모-자식 관계 필수	완전히 독립적
파일시스템	존재하지 않음	파일로 존재
생성 방법	pipe()	mkfifo()
사용 예시	ls \| grep	독립 프로그램 간 통신

Pipe의 제약

// Pipe는 fork() 필수
int pipefd[2];
pipe(pipefd);
fork();  // 부모-자식 관계!

if (pid == 0) {
    // 자식: read
} else {
    // 부모: write
}

FIFO의 자유로움

// 프로세스 A (writer.c)
int fd = open("/tmp/myfifo", O_WRONLY);
write(fd, "Hello", 5);

// 프로세스 B (reader.c) - 완전히 독립!
int fd = open("/tmp/myfifo", O_RDONLY);
read(fd, buf, 100);

실전: FIFO Chat 만들기

이론만으로는 부족하죠. 직접 간단한 채팅 프로그램을 만들어 봅시다.

1단계 : FIFO 생성

#include <sys/stat.h>

#define FIFO_PATH "/tmp/chat_fifo"

// FIFO 생성
if (mkfifo(FIFO_PATH, 0666) == -1) {
    perror("mkfifo");
    exit(1);
}

// 권한: 0666 = rw-rw-rw-

2단계 : Writer 프로그램

// fifo_writer.c
int main(void)
{
    char message[256];
    int fd;
    
    // FIFO 열기 (쓰기 모드)
    fd = open(FIFO_PATH, O_WRONLY);
    
    while (1) {
        printf("You: ");
        fgets(message, sizeof(message), stdin);
        
        if (strcmp(message, "quit\n") == 0)
            break;
        
        // 메시지 전송
        write(fd, message, strlen(message) + 1);
    }
    
    close(fd);
    return 0;
}

3단계 : Reader 프로그램

// fifo_reader.c
int main(void)
{
    char message[256];
    int fd;
    
    // FIFO 열기 (읽기 모드)
    fd = open(FIFO_PATH, O_RDONLY);
    
    while (1) {
        ssize_t n = read(fd, message, sizeof(message));
        
        if (n == 0) {  // EOF
            printf("Writer disconnected\n");
            break;
        }
        
        printf("Received: %s", message);
    }
    
    close(fd);
    unlink(FIFO_PATH);  // FIFO 삭제
    return 0;
}

실행 방법

# 터미널 1
$ gcc fifo_reader.c -o reader
$ ./reader
Opening FIFO...
(Waiting for writer...)

# 터미널 2
$ gcc fifo_writer.c -o writer
$ ./writer
Connected!
You: Hello!
You: How are you?
You: quit

길이 프로토콜

실무에서는 메시지 길이를 먼저 보내는 프로토콜을 많이 사용합니다.

// Writer
uint32_t msg_len = strlen(message) + 1;
write(fd, &msg_len, sizeof(msg_len));  // 길이 먼저
write(fd, message, msg_len);           // 메시지

// Reader
uint32_t msg_len;
read(fd, &msg_len, sizeof(msg_len));   // 길이 먼저
read(fd, message, msg_len);            // 정확히 msg_len만큼

이렇게 하면 메시지 경계를 정확히 알 수 있어서 훨씬 안정적입니다.

FIFO의 특성

Blocking I/O

FIFO의 기본 동작은 blocking입니다.

// Writer
fd = open("/tmp/myfifo", O_WRONLY);
// ↑ Reader가 열 때까지 블로킹!

// Reader
fd = open("/tmp/myfifo", O_RDONLY);
// ↑ Writer가 열 때까지 블로킹!

동작 순서:

T0: Reader: open() 호출 → 블로킹...
T1: Writer: open() 호출
T2: 둘 다 연결됨!
T3: Reader: open() 리턴
T4: Writer: open() 리턴

EOF 처리:

Writer가 FIFO를 닫으면 Reader는 EOF를 받습니다.

// Writer
write(fd, "Last message", 13);
close(fd);  // EOF 전달!

// Reader
while (1) {
    n = read(fd, buf, size);
    if (n == 0) {  // EOF
        printf("Writer disconnected\n");
        break;
    }
    process(buf);
}

실무 활용 사례

1. 로그 수집 시스템

Application → [FIFO] → Log Collector → File/DB

여러 애플리케이션이 하나의 FIFO에 로그를 쓰면
Log Collector가 중앙에서 수집/저장

2. 프로세스 간 명령 전달

Application → [FIFO] → Log Collector → File/DB

여러 애플리케이션이 하나의 FIFO에 로그를 쓰면
Log Collector가 중앙에서 수집/저장

3. 파이프라인 구축

$ mkfifo /tmp/data_pipe
$ producer > /tmp/data_pipe &
$ consumer < /tmp/data_pipe

주의 사항

1. FIFO는 단방향

양방향 통신이 필요하면 FIFO 2개를 만들어야 합니다.

mkfifo("/tmp/fifo_to_server", 0666);
mkfifo("/tmp/fifo_to_client", 0666);

// Client
write(fd_to_server, request, len);
read(fd_from_server, response, len);

2. 정리 필수

프로그램 종료 시 FIFO 파일을 삭제해야 합니다.

close(fd);
unlink(FIFO_PATH);

3. SIGPIPE 조심

Reader가 먼저 종료하면 Writer가 SIGPIPE 시그널을 받아 종료될 수 있습니다.

// 해결책: SIGPIPE 무시
signal(SIGPIPE, SIG_IGN);

// 또는 에러 처리
if (write(fd, data, len) == -1) {
    if (errno == EPIPE) {
        printf("Reader closed\n");
    }
}

성능 비교

FIFO vs Shared Memory 벤치마크 (1MB 데이터 전송):

FIFO:           5-10 ms
Shared Memory:  0.5-1 ms

→ FIFO는 SHM의 약 10배 느림

이유는 FIFO는 Kernel을 경유하기 때문입니다.

FIFO:
Process A → [User Space]
          ↓
        [Kernel Space]  (복사!)
          ↓
        [User Space] → Process B

Shared Memory:
Process A ↔ [Shared Memory] ↔ Process B
           (복사 없음!)

속도가 중요하다면 Shared Memory를, 간단한 통신이면 FIFO를 사용하는 게 좋습니다.

디버깅 팁

FIFO 상태 확인

# FIFO 파일 확인
$ ls -l /tmp/myfifo
prw-rw-r-- 1 user user 0 Feb 21 10:00 /tmp/myfifo

# FIFO 내용 확인 (주의: 블로킹!)
$ cat /tmp/myfifo  # Reader처럼 동작

# 다른 터미널에서
$ echo "test" > /tmp/myfifo  # Writer처럼 동작

strace로 시스템 콜 추적

$ strace -e trace=open,read,write ./reader

open("/tmp/chat_fifo", O_RDONLY)       = 3
read(3, "Hello\0", 256)                = 6
read(3, "World\0", 256)                = 6

마치며

FIFO는 가장 기본적인 IPC 메커니즘 중 하나지만, 실제로 구현해 보면 생각보다 고려할 게 많습니다.

배운 점:

Null terminator 처리의 중요성
버퍼 초기화 필수
길이 프로토콜로 견고하게
Blocking 특성 이해
EOF 처리

다음 공부는 Shared Memory를 공부해볼 예정입니다.

참고 자료

https://man7.org/linux/man-pages/man3/mkfifo.3.html

mkfifo(3) - Linux manual page

mkfifo(3) — Linux manual page mkfifo(3) Library Functions Manual mkfifo(3) NAME top mkfifo, mkfifoat - make a FIFO special file (a named pipe) LIBRARY top Standard C library (libc, -lc) SYNOPSIS top #include #include i

man7.org

https://man7.org/linux/man-pages/man7/fifo.7.html

fifo(7) - Linux manual page

fifo(7) — Linux manual page fifo(7) Miscellaneous Information Manual fifo(7) NAME top fifo - first-in first-out special file, named pipe DESCRIPTION top A FIFO special file (a named pipe) is similar to a pipe, except that it is ac

man7.org

싱글톤 패턴(singleton pattern) - C++

onepaperhoon — Sun, 22 Feb 2026 14:15:17 +0900

1. 개념 이해

싱글톤 패턴이란?

프로그램 전체에서 인스턴스가 단 하나만 존재하도록 보장하는 디자인 패턴

하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있지만, 그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반으로 로직을 만드는데 쓰이며,

하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어드는 장점이 있다.

따라서 보통 싱글톤 패턴이 적용된 객체가 필요한 경우는 그 객체가 리소스를 많이 차지하는 역할을 하는
무거운 클래스일 때 적합하다.

대표적으로 보통 설정(Config) 관리자, 로그(Logger) 시스템, DB 커넥션 풀, 네트워크 소켓 매니저, 데이터 베이스 연결 모듈에 많이 사용된다.

데이터 베이스 연결 모듈을 예로 들자면, 데이터 베이스에 접속하는 작업(I/O 바운드)은 무거운 작업에 속하며 또한 한 번만
객체를 생성하고 돌려쓰면 되는 것을 굳이 여러 번 생성할 필요가 없기 때문이다.

이러한 객체들은 재생성을 하여 사용될 일도 없으며 사용해도 리소스 낭비이다. 따라서 코드 내에서 유일해야 하는 것을 싱글톤 객체로 만들면 된다고 보면 된다.

2. C++ 에서의 싱글톤 구현

기본 구현 (Eager Initialization)

가장 단순한 형태의 싱글톤은 다음과 같다.

class Singleton {
private:
    static Singleton* instance;
    
    // 생성자를 private으로 → 외부에서 new 불가
    Singleton() {}

public:
    // 복사 생성자, 대입 연산자 삭제
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

    static Singleton* getInstance() {
        if (instance == nullptr) {
            instance = new Singleton();
        }
        return instance;
    }
};

// 정적 멤버 초기화
Singleton* Singleton::instance = nullptr;

핵심은 세 가지로 볼 수 있다.

1. 생성자를 private으로 선언 = 외부에서 new Singleton()을 호출할 수 없게 막는다.

2. 복사 생성자와 대입 연산자를 delete - Singleton copy = *Singleton::getInstance(): 같은 복사를 원천 차단한다.

3. static 매서드로 접근 - 유일한 인스턴스에 대한 전역 접근점을 제공한다.

하지만 이 방식에는 치명적인 문제가 있다.

⚠️ 문제점: 멀티스레드 환경에서의 Race Condition

위 기본 구현은 멀티 스레드 환경에서 안전하지 않다. 두 스레드가 동시에 getInstance()를 호출하면 인스턴스가 두 번 생성될 수 있다.

//   Race Condition 시나리오
// Thread A: if (instance == nullptr)  → true 진입
// Thread B: if (instance == nullptr)  → true 진입 (A가 아직 생성 안 함)
// Thread A: instance = new Singleton()  → 첫 번째 생성
// Thread B: instance = new Singleton()  → 두 번째 생성! (메모리 누수)

이 문제를 해결하기 위해 등장한 것이 Double-Checked Locking 패턴이다.

보완 1: Double-Checked Locking

#include <mutex>

class Singleton {
private:
    static Singleton* instance;
    static std::mutex mtx;
    Singleton() {}

public:
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

    static Singleton* getInstance() {
        if (instance == nullptr) {              // 1차 검사 (lock 없이)
            std::lock_guard<std::mutex> lock(mtx);
            if (instance == nullptr) {          // 2차 검사 (lock 안에서)
                instance = new Singleton();
            }
        }
        return instance;
    }
};

1차 검사는 이미 인스턴스가 생성된 이후에는 매번 lock을 걸지 않기 위한 성능 최적화이고, 2차 검사는 실제로 lock을 획득한 후 다른 스레드가 먼저 생성하지 않았는지 확인하는 것이다.

스레드 안전 문제는 해결했지만, 여전히 아쉬운 점이 있다.

코드가 복잡하다 — mutex 관리, 이중 검사 로직이 필요하다
명령어 재배치(instruction reordering) 위험 — C++ 메모리 모델상 컴파일러나 CPU가 명령어 순서를 바꿀 수 있어 미묘한 버그가 발생할 수 있다
메모리 관리가 수동 — new로 생성했으므로 어딘가에서 delete를 해줘야 한다

이런 복잡성을 근본적으로 해결하는 방법이 C++11에서 등장했다.

보완 2: Meyer's Singleton (C++11 이상) 권장

C++11 부터는 지역 정적 변수 (Local Static Variable)의 초기화가 스레드 안전하도록 표준에서 보장한다.
이를 활용한 것이 Scott Meyers가 제안한 방식이다.

class Singleton {
private:
    Singleton() {}

public:
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

    static Singleton& getInstance() {
        static Singleton instance;  // C++11: 스레드 안전 보장
        return instance;
    }
};

이 방식의 장점은 명확하다.

1. 스레드 안전: 컴파일러가 알아서 보장해 준다 (C++11)

2. Lazy Initialization: getInstance()가 처음 호출될 때 생성된다.

3. 메모리 누수 없음: new를 쓰지 않으므로 프로그램 종료 시 자동 소멸

4. 코드가 간결: mutex나 포인터 관리가 필요 없다

기본 구현의 스레드 안전 문제, Double-Checked Locking의 복잡성과 명령어 재배치 위험을 모두 해결한 방식이다.

C++11 이상을 사용한다면 사실상 정답이라고 볼 수 있다.

3. 싱글톤 패턴 자체의 한계

구현 방식을 아무리 잘 선택해도, 싱글톤 패턴 자체가 갖는 구조적인 문제들이 있다.

소멸 순서 문제 (Dead Reference Problem)

싱글톤이 하나만 존재할 때는 문제없지만, 여러 싱글톤이 서로 의존하는 경우 소멸 순서가 꼬일 수 있다.

class Logger {
public:
    static Logger& getInstance() {
        static Logger instance;
        return instance;
    }
    void log(const std::string& msg) { /* ... */ }
    ~Logger() { /* 파일 닫기 등 정리 작업 */ }
};

class Database {
public:
    static Database& getInstance() {
        static Database instance;
        return instance;
    }
    ~Database() {
        //   이 시점에 Logger가 이미 소멸되었을 수 있다!
        Logger::getInstance().log("Database 종료");
    }
};

정적 객체의 소멸 순서는 생성 순서의 역순이다. 만약 Logger가 Database 보다 먼저 생성되었다면 Logger가 나중에 소멸되므로 문제없지만, 그 반대라면 이미 소멸된 Logger에 접근하게 된다.

이런 의존 관계가 있다면 초기화 시점에서 순서를 명시적으로 제어해야 한다.

class Database {
public:
    static Database& getInstance() {
        // Logger를 먼저 초기화 → 나중에 소멸되도록 보장
        Logger::getInstance();
        static Database instance;
        return instance;
    }
};

테스트가 어렵다

싱글톤은 전역 상태를 갖기 때문에 단위 테스트에서 독립적인 환경을 만들기 어렵다. 테스트마다 상태를 리섹해야 하고, mock 객체로 교체하기도 까다롭다.

의존성이 감춰진다

함수 시그니처만 봐서는 해당 함수가 싱글톤에 의존하는지 알 수 없다. 이는 코드의 결흡도를 높이고 유지보수를 어렵게 만든다.

// 싱글톤 직접 접근 — 의존성이 코드 내부에 숨어있다
class Service {
    void doWork() {
        Database::getInstance().query("SELECT ...");
    }
};

// 의존성 주입(DI) — 의존성이 명시적으로 드러난다
class Service {
    Database& db;
public:
    Service(Database& db) : db(db) {}
    void doWork() {
        db.query("SELECT ...");
    }
};

이 때문에 현대 C++ 개발에서는 싱글톤 대신 의존성 주입(Dependency Injection) 패턴을 선호하는 추세다.

마무리

싱글톤을 쓸지 판단할 때는 "이 객체가 정말 프로그램 전체에서 단 하나여야 하는가?"를 먼저 자문해 보자. 그렇다면 Meyer's Singleton으로 구현하되, 여러 싱글톤 간의 의존 관계와 테스트 용이성을 함께 고려하는 것이 좋다.

Scop 구현기 5편: 행렬과 사용 점

onepaperhoon — Thu, 17 Apr 2025 07:43:10 +0900

이전 글에서는 Model 클래스에서 OBJ 파일을 파싱하고 정점 데이터를 처리하는 흐름을 살펴보았습니다.
이번 글에서는 그 정점들이 실제로 화면에 어떻게 그려지는지를 결정짓는 핵심 요소, 바로 "행렬(Matrix)"에 대해 깊이 있게 분석합니다.
3D 그래픽스에서 행렬은 단순한 계산 도구가 아니라, '시점', '위치', '존재'를 결정하는 철학적 도구입니다.

1. 왜 행렬이 필요한가?

3D 그래픽스에서 모델을 불러온다고 해서 곧바로 화면에 보이는 건 아닙니다.
그 이유는 모델의 정점(Vertex)들이 여전히 '자기 내부(Local Space)'에 존재하기 때문입니다. 예를 들어, 정점이 (0, 0, 0)이라고 하면, 이는 오브젝트 기준의 원점을 의미하지 화면 기준의 원점은 아닙니다.

우리는 화면(스크린)이라는 2차원 공간 위에 3차원 물체를 투영하여 보여주어야 합니다. 이를 위해선 여러 좌표계의 변환이 필요하며, 그 핵심이 바로 행렬입니다.
3D 모델을 제대로 화면에 나타내기 위해선 다음과 같은 좌표계 변환이 반드시 필요합니다:

로컬 공간 → 월드 공간 (Model 행렬)
월드 공간 → 카메라(뷰) 공간 (View 행렬)
카메라 공간 → 클립 공간 → NDC → 스크린 공간 (Projection 행렬)

이 변환 과정이 없으면 아무리 모델을 잘 불러왔어도 화면에는 보이지 않습니다. 즉, 행렬은 화면에 "존재하게 만드는" 유일한 길입니다.

2. Scop에서 사용되는 3대 변환 행렬

Scop의 렌더링 파이프라인에서는 아래 세 가지 행렬이 필수적으로 사용됩니다:

Model 행렬: 오브젝트의 위치, 크기, 회전 상태를 결정합니다. 예를 들어 2배 확대하고 오른쪽으로 이동시키는 등의 작업은 이 단계에서 처리됩니다.
View 행렬: 카메라가 위치한 좌표와 그 시점을 기준으로 월드 공간의 모델들을 상대적으로 재배치합니다. 카메라가 이동하는 게 아니라 세상을 역으로 이동시키는 방식입니다.
Projection 행렬: 원근 투영 혹은 직교 투영 방식으로 3D 공간을 2D 화면에 투영합니다. 원근감을 표현하기 위해 필수적인 구성입니다.

이 행렬들은 최종적으로 셰이더에 전달되어 정점의 화면 좌표 gl_Position을 결정합니다.

3. Model 행렬 구성 (Model.cpp)

Scop에서는 Model::Draw() 함수 내에서 다음과 같은 순서로 모델 변환 행렬을 구성합니다:

multiplyMatrix(model, scaleMatrix, model);
rotateY(mRotY, model);
rotateX(mRotX, model);
multiplyMatrix(model, translate, model);

- 먼저 정점의 크기를 조절하는 스케일 행렬을 적용하고,
- 이후 Y축과 X축에 대해 각각 회전(rotateY, rotateX)을 수행하며,
- 마지막으로 위치를 이동시키는 이동 행렬을 곱합니다.

OpenGL에서의 행렬 곱 연산은 오른쪽에서 왼쪽으로 적용되므로, 실제로는 "스케일 → 회전 → 이동" 순서로 변환됩니다.

4. View 행렬 구성 (카메라 시점 정의)

View 행렬은 카메라가 어떤 위치에서 어떤 방향으로 세상을 보는지를 수학적으로 정의합니다. Scop에서는 이를 직접 createLookAtMatrix()로 구현합니다:

createLookAtMatrix({0, 0, 3}, {0, 0, 0}, {0, 1, 0}, view);

위 코드는 "카메라가 (0, 0, 3) 위치에서 (0, 0, 0)을 바라보며 위 방향은 Y축"임을 의미합니다.
LookAt 행렬의 구성은 다음과 같은 벡터 연산으로 이뤄집니다:

Forward = normalize(center - eye)
Right = normalize(Forward × Up)
Up' = Right × Forward

이 벡터들을 기반으로 한 4x4 행렬은 "카메라 기준 좌표계"를 만들어내며, 모델들은 이 좌표계 기준으로 재정렬됩니다.

5. Projection 행렬 구성 (원근 투영 정의)

Scop에서는 원근 투영 행렬을 아래처럼 직접 계산합니다. 이 방식은 OpenGL의 gluPerspective()와 동일한 역할을 수행합니다.

inline void createPerspectiveMatrix(float fov, float aspect, float neer, float far, float* matrix) {
    float rad = fov * DEG2RAD;
    float tanHalfFov = tan(rad / 2.0f);

    for (int i = 0; i < 16; ++i)
        matrix[i] = 0.0f;

    matrix[0] = 1.0f / (aspect * tanHalfFov);
    matrix[5] = 1.0f / tanHalfFov;
    matrix[10] = -(far + neer) / (far - neer);
    matrix[11] = -1.0f;
    matrix[14] = -(2.0f * far * neer) / (far - neer);
}

수학적으로 위 함수는 아래와 같은 행렬을 의미합니다:

$$ P = \begin{bmatrix} \frac{1}{a \cdot \tan(\theta/2)} & 0 & 0 & 0 \\\\ 0 & \frac{1}{\tan(\theta/2)} & 0 & 0 \\\\ 0 & 0 & -\frac{f + n}{f - n} & -1 \\\\ 0 & 0 & -\frac{2fn}{f - n} & 0 \end{bmatrix} $$

다만 이 행렬은 OpenGL이 사용하는 column-major 메모리 구조에 맞춰 작성되어야 하므로,
matrix[11]과 matrix[14]의 인덱스 위치가 수식과 달라 보일 수 있습니다. 이는 순서가 바뀐 것이 아니라 메모리 상 배치 기준이 다르기 때문입니다.

6. 최종 정점 위치 계산

위 세 행렬은 다음과 같은 순서로 곱해져서 셰이더에 전달되며, 최종적으로 정점의 위치가 결정됩니다:

gl_Position = projection * view * model * vec4(vertexPosition, 1.0);

이 수식은 다음과 같은 의미를 담고 있습니다:

Model 행렬: 오브젝트의 로컬 공간에서 월드 공간으로 이동
View 행렬: 월드 공간에서 카메라 기준 공간으로 이동
Projection 행렬: 카메라 공간에서 정규화 장치 좌표계(NDC)로 투영
gl_Position: GPU의 래스터라이저에 의해 화면 픽셀로 변환

즉, 우리가 OBJ 파일을 파싱하고 정점 정보를 넘기며 행렬을 구성하는 모든 과정은 이 한 줄의 수식을 위해 존재하는 것입니다.

Scop 구현기 4편: Model 클래스

onepaperhoon — Mon, 14 Apr 2025 09:19:48 +0900

전 편에서 Shader코드들을 분리해 클래스로 따로 만들었다

이제는 기본. obj 파일을 파싱 해서 VAO와 VBO 그리고 정점들에 대한 데이터 들을 클래스 단위로 분리해 보자!

Scop에서 가장 중요한 클래스가 아닐까 싶다

1. 왜 Model 클래스를 도입했나?

삼각형 그리기를 생각해 본다면 VAO, VBO, 위치 데이터, 셰이더 정보 등이 전부 흩어져 있다

이걸 하나로 묶지 않으면

각 객체마다 VAO/VBO를 일일이 관리해야 하고
draw 호출마다 셰이더 바인딩도 반복하고
좌표, 색상, 메시 정보를 통합적으로 다루기 어렵다

그래서 이 모든 "하나의 그릴 대상"을 감싸는 클래스를 만들게 된 것이다.

2. Model 클래스는 어떤 책임을 가져야 할까?

처음에는 단순히 "정점 데이터를 갖는 그릇" 정도로만 생각했다

하지만 직접 만들다 보니, 역할이 꽤 많았다.

역할	설명
정점 데이터 보관	VBO를 생성하고 데이터를 업로드
VAO 설정	버텍스 레이아웃을 GPU에 정의
셰이더 연동	Shader 클래스를 보관하고 사용
변환 행렬 저장	위치/회전/크기를 위한 model matrix
draw() 함수	화면에 실제로 그리는 로직
OBJ 파싱	.obj 파일을 파싱해서 정점 데이터, 메터리얼 등을 저장

즉, 단순 그리기 이상으로, 렌더링 파이프라인을 포괄하는 최소 단위가 되었다.

3. Model 클래스의 헤더부터 살펴보자

Model.hpp

생각 보다 Model 클래스의 크기가 커졌다....

천천히 하나하나 설명을 작성해 보겠습니다!

1. 생성자

Model::Model(const char* filePath, Shader* shader)
: mShaderProgram(shader)
, mScaleFactor(1.0f)
, mRotX(0.0f), mRotY(0.0f)
, mPosX(0.0f), mPosY(0.0f), mPosZ(0.0f)
, mbUseTexture(false)
, mBlendFactor(0.0f)
, mUVRotation(UVRotation::None)
{
	LoadOBJ(filePath);
	SetupMesh();
	LoadTexture("resources/sample.png");
}

생성자에서 간단하게 초기화해야 하는 멤버 변수들을 초기화하고 Model 클래스의 핵심이라고 할 수 있는 부분인 LoadOBJ로
넘 거 가게 된다.

2. LoadOBJ

void Model::LoadOBJ(const char* filePath)
{
	std::ifstream file(filePath);
	if (!file.is_open())
	{
		std::cerr << "Failed to open OBJ file: " << filePath << std::endl;
		return;
	}
	std::vector<Vec3>	temp_V;
	std::vector<Vec2>	temp_Vt;
	std::vector<Vec3>	temp_Vn;
	std::vector<Vec3>	temp_color;
	bool				hasTexCoord;

	std::string line;
	while (std::getline(file, line))
	{
		std::istringstream iss(line);
		std::string prefix;
		iss >> prefix;
		// mtl 파일 파싱
		if (prefix == "mtllib")
		{
			std::string mtlFilename;
			iss >> mtlFilename;
			mMaterials = MTLLoader::Load("resources/" + mtlFilename);
			std::cout << mtlFilename << std::endl;
		}
		else if (prefix == "v") // v 1.0123, 2.123123, -6.1235 -> 정점 좌표 정보일 경우
		{
			Vec3 v;

			iss >> v.x >> v.y >> v.z;
			temp_V.push_back(v);
		}
		else if (prefix == "vt") // vt 0~1, 0~1 -> TextureCoord일 경우
		{
			Vec2 vt;
			iss >> vt.x >> vt.y;
			temp_Vt.push_back(vt);
			hasTexCoord = true;
		}
		else if (prefix == "vn") // vn 1, 2, 5 -> Normal 정보일 경우
		{
			Vec3 vn;
			iss >> vn.x >> vn.y >> vn.z;
			temp_Vn.push_back(vn);
		}
		else if (prefix == "usemtl") // v, vn, vt 정보가 모두 처리 완료 된 후 Usemtl -> 이후 f들에게 적용할 mtl 명
		{
			iss >> mCurrentMaterial;
		}
		else if (prefix == "f") // f 정보가 나오면
		{
			Face face;
			face.mtlname = mCurrentMaterial;
			std::string vertexStr;
			while (iss >> vertexStr)
			{
				int vIdx = -1, vtIdx = -1, vnIdx = -1;
				size_t firstSlash = vertexStr.find('/'); // f 1/2/3 에서 첫번째 슬레쉬 찾기
				size_t secondSlash = vertexStr.find('/', firstSlash + 1); // 두번째 슬레쉬 찾기

				if (firstSlash == std::string::npos)
				{
					vIdx = std::stoi(vertexStr) - 1;
				}
				else if (secondSlash == std::string::npos)
				{
					vIdx = std::stoi(vertexStr.substr(0, firstSlash)) - 1;
					vtIdx = std::stoi(vertexStr.substr(firstSlash + 1)) - 1;
				}
				else if (secondSlash == firstSlash + 1)
				{
					vIdx = std::stoi(vertexStr.substr(0, firstSlash)) - 1;
					vnIdx = std::stoi(vertexStr.substr(secondSlash + 1)) - 1;
				}
				else
				{
					vIdx = std::stoi(vertexStr.substr(0, firstSlash)) - 1;
					vtIdx = std::stoi(vertexStr.substr(firstSlash + 1, secondSlash - firstSlash - 1)) - 1;
					vnIdx = std::stoi(vertexStr.substr(secondSlash + 1)) - 1;
				}

				Vertex v;
				v.position = temp_V[vIdx];
				if (vtIdx >= 0 && temp_Vt.size() != 0)
					v.texCoord = temp_Vt[vtIdx];
				if (vnIdx >= 0 && temp_Vn.size() != 0)
					v.normal = temp_Vn[vnIdx];

				mVertices.push_back(v);
				unsigned int index = mVertices.size() - 1;
				face.vertexIndices.push_back(index);
			}
			if (face.vertexIndices.size() == 3)
			{
				mFaces.push_back(face);
			}
			else if (face.vertexIndices.size() == 4)
			{
				Face f1, f2;
				f1.mtlname = face.mtlname;
				f1.vertexIndices = { face.vertexIndices[0], face.vertexIndices[1], face.vertexIndices[2] };

				f2.mtlname = face.mtlname;
				f2.vertexIndices = { face.vertexIndices[0], face.vertexIndices[2], face.vertexIndices[3] };

				mFaces.push_back(f1);
				mFaces.push_back(f2);
			}

		}
	}
	for (const auto& v : mVertices)
		mOriginalPositions.push_back(v.position);
	file.close();
	if (!hasTexCoord)
	{
		GenerateTexCoordsFromPosition();
	}
	NormalizeVertices(mVertices); // NDC 좌표계로
	ApplyFaceColorsFromIndex();
	PrintAllVertexInfo();
	// PrintAllFaceInfo();
	// 정점 및 인덱스 저장
}

전체 흐름 요약

. obj 파일 열기
v, vt, vb, f , usemtl, mtllib 등 접두어별로 처리
각 줄을 파싱해 점검, 텍스쳐 좌표, 노멀 벡터 등 임시 저장
f 라인에서 실제 정점 조합 생성 및 mVetices/mFaces 구성
정점 정규화, 텍스쳐 좌표 자동 생성, 색상 정용 등 후처리

섹션 상세 설명

1. 파일 열기

std::ifstream file(filePath);
if (!file.is_open())

ifstream으로 파일을 연뒤 열리지 않으면 경고 출력 후 리턴.

2. 정점/텍스처/ 노멀 저장용 임시 버퍼

std::vector<Vec3>	temp_V;
std::vector<Vec2>	temp_Vt;
std::vector<Vec3>	temp_Vn;

. obj는 f라인보다 v 라인이 먼저 오므로 일단 버퍼에 넣어둔다.

정점마다 (v/vt/vn) 조합이 다르므로 나중에 매칭해야 한다.

3.mtlib & usemtl 처리

if (prefix == "mtllib")
{
 // 재질 로딩
}
else if (prefix == "usemtl")
{
 // 현재 페이스에 적용할 재질 이름 저장
}

.obj 파일은. mtl 파일을 함께 사용하며, 재질 (Material) 이름은 Face에 저장된다.

그럼 나중에 렌더링 할 때 해당 재질의 색상을 불러올 수 있다.

4.f(face) 파싱

이게 핵심 부분이라고 생각한다, 각 정점은 다음 4가지 방식으로 등장할 수 있다.

형식	의미
v	정점 인덱스
v/vt	정점 + 텍스처 좌표
v//vn	정점 + 노멀
v/vt/vn	정점 + 텍스처 + 노멀

이를. find('/')로 판단하고 각 파트를 분리해 index로 처리한다.

5. Vertex 객체 생성 및 mVertices 저장

Vertex v;
v.position = temp_V[vIdx];
if (vtIdx >= 0) v.texCoord = temp_Vt[vtIdx];
if (vnIdx >= 0) v.normal = temp_Vn[vnIdx];
mVertices.push_back(v);

각각의 Face는 Vertex들의 index를 참조하여 만든다.
. obj는 인덱스 기반 구조이기 때문에, Vertex 중복이 발생할 수 있다.
여기선 간단하게 mVertices.push_back()하며 인덱스를 추적해 넣는다.

6. 4 각형 face 삼각형 분해

if (face.vertexIndices.size() == 4) {
	// 0-1-2 / 0-2-3 으로 분해
}

. obj에서 사각형(f 1 2 3 4) 구조는 삼각형 두 개로 쪼개줘야 한다.

현재 구조에서는 그래야 OpenGL이 이해할 수 있다.

7. 텍스처 좌표 없을 경우 자동 생성

if (!hasTexCoord) {
	GenerateTexCoordsFromPosition();
}

텍스처 좌표가 없는. obj 파일도 많기 때문에

그럴 경우 정점 위치 기반으로 UV를 강제로 생성해 준다.

8. 정규화 및 색상 적용

NormalizeVertices(mVertices);
ApplyFaceColorsFromIndex();

정점 위치를 OpenGL의 -1.0 ~ 1.0 영역으로 스케일링 (NDC 대응)
각 Face마다 색상을 지정해 색상을 가진 렌더링이 가능하도록 한다 (체크무늬)

3.SetUpMesh

void Model::SetupMesh(void)
{
	glGenVertexArrays(1, &mVAO);
	glGenBuffers(1, &mVBO);
	glGenBuffers(1, &mEBO);

	glBindVertexArray(mVAO);

	glBindBuffer(GL_ARRAY_BUFFER, mVBO);
	glBufferData(GL_ARRAY_BUFFER, mVertices.size() * sizeof(Vertex), &mVertices[0], GL_STATIC_DRAW);
	/*
		Vertex
		->	float * 3 : position
			float * 3 : normal
			float * 2 : texcoord
			flaot * 3 : color
	*/
	glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, mEBO);
		// 각 face의 인덱스를 모아 하나의 인덱스 버퍼 생성
	mAllIndices.clear();
	for (const Face& face : mFaces) {
		mAllIndices.insert(mAllIndices.end(), face.vertexIndices.begin(), face.vertexIndices.end());
	}
	glBufferData(GL_ELEMENT_ARRAY_BUFFER, mAllIndices.size() * sizeof(unsigned int), mAllIndices.data(), GL_STATIC_DRAW);

	glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, position));
	glEnableVertexAttribArray(0);
	glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, normal));
	glEnableVertexAttribArray(1);
	glVertexAttribPointer(2, 2, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, texCoord));
	glEnableVertexAttribArray(2);
	glVertexAttribPointer(3, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, color));
	glEnableVertexAttribArray(3);
	glBindVertexArray(0);
}

전체 흐름 요약

버퍼 객체 (VAO, VBO, EBO) 생성
정점 데이터 GPU에 업로드 (glBufferData)
인덱스 데이터 생성 및 업로드
정점 속성 포인터 설정 (glVertexAttribPointer)
마무리 정리 (glBindVertexArray(0))

섹션 상세 설명

1. 버퍼 객체 생성

glGenVertexArrays(1, &mVAO);
glGenBuffers(1, &mVBO);
glGenBuffers(1, &mEBO);

VAO: 정점 배열 객체 (Vertex Array object)
VBO: 정점 버퍼 객체 (Vertex Array object)
EBO: 인덱스 버퍼 객체 (Element Buffer object)

2. VAO 바인딩 시작

glBindVertexArray(mVAO);

이제부터의 모든 설정은 VAO에 저장된다.

즉, 한 번만 설정해 두면 glBindVertexArray(mVAO)만 해도 그 설정이 복구됨

3. 정점 데이터 GPU에 업로드

glBindBuffer(GL_ARRAY_BUFFER, mVBO);
glBufferData(GL_ARRAY_BUFFER, mVertices.size() * sizeof(Vertex), &mVertices[0], GL_STATIC_DRAW);

GL_ARRAY_BUFFER는 정점 데이터를 위한 버퍼다.
Vertex는 구조체로서 다음과 같은 레이아웃을 가진다.

struct Vertex {
	Vec3 position;   // 3 floats
	Vec3 normal;     // 3 floats
	Vec2 texCoord;   // 2 floats
	Vec3 color;      // 3 floats
};

총 11 floats = 44 bytes 짜리 구조다.

OpenGL에게 이 구조를 설명해야 하며, mVertices.size만큼 설정해야 한다.

4. 인덱스 버퍼 구성 (EBO)

mAllIndices.clear();
for (const Face& face : mFaces) {
	mAllIndices.insert(mAllIndices.end(), face.vertexIndices.begin(), face.vertexIndices.end());
}
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, mEBO);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, mAllIndices.size() * sizeof(unsigned int), mAllIndices.data(), GL_STATIC_DRAW);

각 Face는 세 개의 정점 인덱스를 가진다 (삼각형)
이 인덱스들을 하나의 벡터로 모아 glDrawElemets용으로 만든다.
GL_ELEMENT_ARRAY_BUFFER는 EBO의 명칭이다.

5. 정점 속성 포인터 설정

glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, position));
glEnableVertexAttribArray(0);
glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, normal));
glEnableVertexAttribArray(1);
glVertexAttribPointer(2, 2, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, texCoord));
glEnableVertexAttribArray(2);
glVertexAttribPointer(3, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, color));
glEnableVertexAttribArray(3);
glBindVertexArray(0);

layout 0 -> position: 3개의 float (x, y, z)
layout 1 -> normal: 3개의 float
layout 2 -> texCoord: 2개의 float
layout 3 -> color: 3개의 float

glVertexAttribPointer(index, size, type, normalize, stride, offset);

항목	설명
index	셰이더에서 layout(location = index)와 매칭됨
size	몇 개의 요소 (position은 3, texCoord는 2등)
type	GL_FLOAT
normalize	정규화 여부 (일반적으로 false)
stride	하나의 정점 전체 크기
offset	구조체 내 해당 필드까지의 거리

6. 마무리

glBindVertexArray(0);

VAO를 바인딩 해제함으로써 설정을 마감한다.

이제 나중에 Draw() 함수에서 glBindVertexArray(mVAO)만 하면 바로 사용 가능한 상태가 되었다.

4. Draw() 함수

void Model::Draw(void)
{
	mShaderProgram->Use();
	glBindVertexArray(mVAO);

	float view[16];
	createLookAtMatrix({0, 0, 3}, {0, 0, 0}, {0, 1, 0}, view);

	float projection[16];
	createPerspectiveMatrix(45.0f, 1000.0f/1000.0f, 0.1f, 100.0f, projection);

	float model[16];
	setIdentityMatrix(model);

	float scaleMatrix[16] = {
		mScaleFactor, 0.0f, 0.0f, 0.0f,
		0.0f, mScaleFactor, 0.0f, 0.0f,
		0.0f, 0.0f, mScaleFactor, 0.0f,
		0.0f, 0.0f, 0.0f, 1.0f
	};
	float translate[16];
	createTranslationMatrix(mPosX, mPosY, mPosZ, translate);

	multiplyMatrix(model, scaleMatrix, model);
	rotateY(mRotY, model);
	rotateX(mRotX, model);
	multiplyMatrix(model, translate, model);

	UpdateBlend(mbUseTexture, 0.016f);

	mShaderProgram->SetMat4("model", model);
	// mShaderProgram->SetBool("useTexture",mbUseTexture);
	mShaderProgram->SetMat4("view", view);
	mShaderProgram->SetMat4("projection", projection);
	mShaderProgram->SetFloat("blendFactor", mBlendFactor);
	size_t indexOffset = 0;
	for (const Face& face : mFaces)
	{
		const auto it = mMaterials.find(face.mtlname);
		if (it != mMaterials.end())
		{
			const Material& mat = it->second;
			mShaderProgram->SetVec3("material.diffuse", mat.Kd.r, mat.Kd.g, mat.Kd.b);
			mShaderProgram->SetVec3("material.ambient", mat.Ka.r, mat.Ka.g, mat.Ka.b);
			mShaderProgram->SetVec3("material.specular", mat.Ks.r, mat.Ks.g, mat.Ks.b);
			mShaderProgram->SetFloat("material.shininess", mat.Ns);
		}
		glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_INT, (void*)(indexOffset * sizeof(unsigned int)));
		indexOffset += 3;
	}
	if (mAllIndices.size() % 3 != 0) std::cerr << "⚠️ Broken EBO!" << std::endl;
	glBindVertexArray(0);
}

전체 흐름 요약

셰이더 활성화
View, Projection, Model 행렬 구성 및 전달
재질 (Material) 속성 전달
glDrawElements()로 실제 그리기
VAO 해제

섹션 상세 설명

1. 셰이더 프로그램 활성화

mShaderProgram->Use();
glBindVertexArray(mVAO);

VAO를 바인딩함으로써 버퍼 세팅 정보를 불러오고,

셰이더 프로그램을 GPU에서 사용하도록 설정한다.

2.View Projection, Model 행렬 구성

float view[16];
createLookAtMatrix({0, 0, 3}, {0, 0, 0}, {0, 1, 0}, view);

float projection[16];
createPerspectiveMatrix(45.0f, 1000.0f/1000.0f, 0.1f, 100.0f, projection);

View: 카메라 위치를 기준으로 씬을 바라보는 시점 설정
Projection: 원근 투영(FOV 45도, near/far 평면)

3. 모델 변환 적용

setIdentityMatrix(model);  // 초기화
multiplyMatrix(model, scaleMatrix, model); // 스케일
rotateY(mRotY, model);                     // 회전
rotateX(mRotX, model);
multiplyMatrix(model, translate, model);  // 이동

정점 데이터를 모델 공간 -> 월드 공간으로 변환한다.

이 과정은 행렬 곱 순서가 매우 중요함

4. 유니폼 값 전달

mShaderProgram->SetMat4("model", model);
mShaderProgram->SetMat4("view", view);
mShaderProgram->SetMat4("projection", projection);
mShaderProgram->SetFloat("blendFactor", mBlendFactor);

셰이더에서 사용하는 매트릭스들은 모두 유니폼으로 전달되며,

셰이더에서는 이걸 통해 gl_Position = projection * view * model * vec4(...) 형태로 변환하게 된다.

5. 재질 정보 전달 및 드로우 호출

for (const Face& face : mFaces)
{
	const auto it = mMaterials.find(face.mtlname);
	if (it != mMaterials.end())
	{
		const Material& mat = it->second;
		mShaderProgram->SetVec3("material.diffuse", mat.Kd.r, mat.Kd.g, mat.Kd.b);
		mShaderProgram->SetVec3("material.ambient", mat.Ka.r, mat.Ka.g, mat.Ka.b);
		mShaderProgram->SetVec3("material.specular", mat.Ks.r, mat.Ks.g, mat.Ks.b);
		mShaderProgram->SetFloat("material.shininess", mat.Ns);
	}
	glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_INT, (void*)(indexOffset * sizeof(unsigned int)));
	indexOffset += 3;
}

material.diffuse, specular, ambient 등은 프래그먼트 셰이더에서 조명 연산에 사용된다.
glDrawElements는 EBO에 있는 인덱스를 3개씩 참조하여 하나의 삼각형을 그림.

6. VAO 해제

glBindVertexArray(0);

VAO 바인딩 해제!

다른 모델을 그릴 수 있도록 준비해 주는 단계.

Scop 구현기 3편: 셰이더 클래스를 만들기로 했다

onepaperhoon — Fri, 11 Apr 2025 17:51:43 +0900

OpenGL 셰이더를 매번 glCreateShader → glCompileShader → glLinkProgram 반복하는 게
너무 지저분하고 비효율적이라는 생각이 들었다.
심지어 하나만 있을 땐 모르겠는데, 앞으로 이게 10개, 20개 넘어가면… 말 다했지 뭐.

그래서 아예 셰이더 클래스를 하나 짜기로 했다.

헤더부터 깔끔하게 작성했다.

class Shader {
public:
	Shader(const char* vsPath, const char* fsPath);
	~Shader();

	void Use();
	GLuint GetId();

	void SetBool(const std::string& name, bool value) const;
	void SetInt(const std::string& name, int value) const;
	void SetFloat(const std::string& name, float value) const;
	void SetMat4(const std::string& name, const float* value) const;

private:
	GLuint mProgramId;
	std::unordered_map<std::string, GLint> mUniformLocations;

	GLuint CompileShader(const char* vsPath, const char* fsPath);
	GLuint AddShader(const char* shaderCode, GLenum shaderType);
	std::string ReadFile(const char* filePath);
	void LoadActiveUniforms();
};

초기 목표는 심플했다

.gsls 파일을 외부에서 읽어오고
컴파일/링크하고
Use()로 Activate
Uniform도 Set 가능하게

그리고 무엇보다 main에서 glsl의 코드가 안 보이게!

Shader 클래스 구조 요약

1. 생성자 & 소멸자

Shader::Shader(const char* vsPath, const char* fsPath)
{
	mProgramId = CompileShader(vsPath, fsPath);
	LoadActiveUniforms();
}

파일을 읽고
CompileShader()를 호출해 프로그램 생성
LoadAcriveUniforms()로 유니폼 목록 을 미리 로딩

Shader::~Shader()
{
	if (mProgramId != 0)
		glDeleteProgram(mProgramId);
}

프로그램 ID가 유효하면 glDeleteProgram 으로 정리

2. 셰이더 컴파일 및 추가

CompileShader

ReadFile에서 읽어온 소스 파일 내용을 토대로 ShaderProgram을 만든뒤 ShaderProgram Id를 리턴하는 함수

GLuint	Shader::CompileShader(const char* vsPath, const char* fsPath)
{
	std::string vsCode = ReadFile(vsPath);
	std::string fsCode = ReadFile(fsPath);

	if (vsCode.empty() || fsCode.empty())
	{
		std::cerr << "Error: Failed to load shader file code." << std::endl;
		return (0);
	}

	GLuint vs = AddShader(vsCode.c_str(), GL_VERTEX_SHADER);
	GLuint fs = AddShader(fsCode.c_str(), GL_FRAGMENT_SHADER);
	if (!vs || !fs)
	{
		return (0);
	}
	GLuint ShaderProgram = glCreateProgram();
	glAttachShader(ShaderProgram, vs);
	glAttachShader(ShaderProgram, fs);
	glLinkProgram(ShaderProgram);

	GLint success;
	GLchar infoLog[1024];
	glGetProgramiv(ShaderProgram, GL_LINK_STATUS, &success);
	if (!success)
	{
		glGetProgramInfoLog(ShaderProgram, sizeof(infoLog), NULL, infoLog);
		std::cerr << "Error linking shader program: " << infoLog << std::endl;
		return (0);
	}

	glDeleteShader(vs);
	glDeleteShader(fs);

	return (ShaderProgram);
}

3. 셰이더 사용

void Shader::Use()
{
	if (mProgramId != 0)
		glUseProgram(mProgramId);
}

OpenGL은 명시적으로 glUseProgram()을 호출해야 현재 셰이더가 GPU 파이프라인에서 활성화된다.
이 함수를 안 호출하면 아무것도 그려지지 않는다. 그런데 이걸 매번 glUseProgram(shaderProgram);으로 쓰면 헷갈린다.
클래스 내부에 넣어두면 깔끔하게 shader.Use(); 한 줄로 끝난다. 의외로 이 한 줄이 코드 가독성을 굉장히 올려준다.
게다가 유지보수 시에 실수도 줄일 수 있다.

4. Uniform 자동 로딩

void Shader::LoadActiveUniforms()
{
	GLint count;
	glGetProgramiv(mProgramId, GL_ACTIVE_UNIFORMS, &count);

	for (int i = 0; i < count; ++i)
	{
		GLchar	name[256];
		GLsizei	length;
		GLint	size;
		GLenum	type;

		glGetActiveUniform(mProgramId, i, sizeof(name), &length, &size, &type, name);

		GLint loaction = glGetUniformLocation(mProgramId, name);
		mUniformLocations[name] = loaction;
		std::cout << "Uniforms Name: " << name << std::endl;
	}
}

OpenGL에서 GL_ACTIVE_UNIFORMS 값을 받아서
glGetActiveUniform()으로 현재 셰이더에 등록된 유니폼 이름 및 사이즈를 전부 가져온다.
그리고 mUniformLocations 맵에 전부 캐싱해둔다!
OpenGL은 현재 프로그램에 등록된 유니폼들을 조회할 수 있는 API를 제공한다.
그걸 활용해서 glGetActiveUniform()으로 유니폼의 이름, 타입, 크기를 받아오고
해당 이름의 glGetUniformLocation()도 미리 호출해서 캐시한다.
이 과정을 통하면 런타임 중에 "유니폼 이름이 틀렸습니다" 같은 에러 없이
처음 실행 시점에 모든 유니폼 존재 여부를 체크할 수 있게 된다.
개발자 입장에선 이게 정말 심리적으로 안정감을 준다.
어디서 안 보이면, 일단 이 함수 로그만 보면 된다.

5. 유니폼 전송 함수들 (SetX 계열)

void	Shader::SetBool(const std::string& name, bool value) const
{
	GLint location = GetLocation(name);
	if (location != -1)
		glUniform1i(location, (int)value);
	else
		std::cerr << "Not Found : " << name << " Uniform" << std::endl;
}

void	Shader::SetInt(const std::string& name, int value) const
{
	GLint location = GetLocation(name);
	if (location != -1)
		glUniform1i(location, value);
	else
		std::cerr << "Not Found : " << name << " Uniform" << std::endl;
}

void	Shader::SetFloat(const std::string& name, float value) const
{
	GLint location = GetLocation(name);
	if (location != -1)
		glUniform1f(location, value);
	else
		std::cerr << "Not Found : " << name << " Uniform" << std::endl;
}

void	Shader::SetVec2(const std::string& name, float x, float y) const
{
	GLint location = GetLocation(name);
	if (location != -1)
		glUniform2f(location, x, y);
	else
		std::cerr << "Not Found : " << name << " Uniform" << std::endl;
}

void	Shader::SetVec3(const std::string& name, float x, float y, float z) const
{
	GLint location = GetLocation(name);
	if (location != -1)
		glUniform3f(location, x, y, z);
	else
		std::cerr << "Not Found : " << name << " Uniform" << std::endl;
}

void	Shader::SetVec4(const std::string& name, float x, float y, float z, float w) const
{
	GLint location = GetLocation(name);
	if (location != -1)
		glUniform4f(location, x, y, z, w);
	else
		std::cerr << "Not Found : " << name << " Uniform" << std::endl;
}

void	Shader::SetMat3(const std::string& name, const float* value) const
{
	GLint location = GetLocation(name);
	if (location != -1)
		glUniformMatrix3fv(location, 1, GL_FALSE, value);
	else
		std::cerr << "Not Found : " << name << " Uniform" << std::endl;
}

void	Shader::SetMat4(const std::string& name, const float* value) const
{
	GLint location = GetLocation(name);
	if (location != -1)
		glUniformMatrix4fv(location, 1, GL_FALSE, value);
	else
		std::cerr << "Not Found : " << name << " Uniform" << std::endl;
}

OpenGL은 유니폼을 보낼 때마다 glGetUniformLocation()을 호출해야 한다.
이건 비용이 크고, 런타임 중 호출 시 실수도 많고 성능에도 좋지 않다.

그래서 나는 mUniformLocations라는 맵을 하나 만들고,
셰이더 초기화 시에 모든 유니폼 이름과 위치를 미리 다 저장해놨다.

그 덕분에 지금은 그냥 shader.SetVec3("uColor", 1.0f, 0.0f, 0.0f); 한 줄이면 끝난다.
이 구조가 되니까 uniform 작업이 너무 편해졌고,
코드도 안정적이고 예측 가능하게 바뀌었다

5. GLSL 타입 출력 함수

static const char* GetGLTypeString(GLenum type)
{
	switch (type)
    {
		case GL_FLOAT: return "float";
		case GL_FLOAT_VEC2: return "vec2";
		case GL_FLOAT_VEC3: return "vec3";
		case GL_FLOAT_VEC4: return "vec4";
		case GL_INT: return "int";
		case GL_INT_VEC2: return "ivec2";
		case GL_INT_VEC3: return "ivec3";
		case GL_INT_VEC4: return "ivec4";
		case GL_BOOL: return "bool";
		case GL_BOOL_VEC2: return "bvec2";
		case GL_BOOL_VEC3: return "bvec3";
		case GL_BOOL_VEC4: return "bvec4";
		case GL_FLOAT_MAT2: return "mat2";
		case GL_FLOAT_MAT3: return "mat3";
		case GL_FLOAT_MAT4: return "mat4";
		case GL_SAMPLER_2D: return "sampler2D";
		case GL_SAMPLER_CUBE: return "samplerCube";
		default: return "unknown";
	}
}

void Shader::PrintActiveUniforms() const
{
	GLint count;
	glGetProgramiv(mProgramId, GL_ACTIVE_UNIFORMS, &count);

	std::cout << "Active Uniforms in Shader Program " << ": " << mProgramId <<  std::endl;

	for (int i = 0; i < count; ++i) {
		GLchar name[256];
		GLsizei length;
		GLint size;
		GLenum type;
		glGetActiveUniform(mProgramId, i, sizeof(name), &length, &size, &type, name);
		std::cout << " - " << name << " (Type: " << GetGLTypeString(type) << ", Size: " << size << ")" << std::endl;
	}
}

프린트할 때 vec3, mat4 같은 문자열로 출력해주는 유틸
디버깅용 PrintActiveUniforms()에서 사용됨

구현하면서 느낀 점

✔️ 만들고 나니까 이런 점이 좋았다:

GLSL 파일만 바꿔도 바로 적용됨 → 실시간 개발 느낌
uniform 명칭 실수 줄어듦
셰이더가 많아질수록 이 구조가 빛을 발함
PrintActiveUniforms()로 디버깅도 쉬워짐

❌ 만들면서 애먹은 점:

GLSL 읽기 실패했을 때 에러 로그 안 뜨는 것 → 로그 추가
uniform 이름이 바뀌었는데 캐시만 믿었다가 값이 안 들어감 → 리로딩 필요성 느낌

최종 사용 예시

Shader shader("shaders/basic.vert", "shaders/basic.frag");
shader.Use();
shader.SetVec3("uColor", 1.0f, 0.2f, 0.5f);
shader.SetMat4("uMVP", glm::value_ptr(mvp));

Scop 구현기 2편: VAO와 VBO의 세계

onepaperhoon — Wed, 9 Apr 2025 19:04:49 +0900

윈도우를 띄우는 것까지 했으니 이제 삼각형을 그려보겠습니다.

삼각형 그리기 전체 코드

#include <GL/glew.h>
#include <GLFW/glfw3.h>
#include <OpenGL/gl.h>
#include <iostream>

const char* vertexShaderSource = R"(
#version 330 core
layout (location = 0) in vec3 aPos;

void main() {
	gl_Position = vec4(aPos, 1.0);
}
)";

const char* fragmentShaderSource = R"(
#version 330 core
out vec4 FragColor;

void main() {
	FragColor = vec4(1.0, 0.5, 0.2, 1.0); // 주황색
}
)";

void processInput(GLFWwindow* window)
{
	if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS)
		glfwSetWindowShouldClose(window, true);
}

int main(void)
{
	if (!glfwInit())
	{
		std::cerr << "GFLW Init Failed" << std::endl;
		return (-1);
	}

	glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
	glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
	glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
	glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);

	GLFWwindow* window = glfwCreateWindow(500, 500, "scop", NULL, NULL);

	glfwMakeContextCurrent(window);
	int framebuffer_w, framebuffer_h;
	glfwGetFramebufferSize(window, &framebuffer_w, &framebuffer_h);
	glViewport(0, 0, framebuffer_w , framebuffer_h);

	if (glewInit() != GLEW_OK)
	{
		std::cerr << "GLEW Init Failed" << std::endl;
		glfwTerminate();
		return (-1);
	}

	// 정점 데이터
	float vertices[] = {
		-0.5f, -0.5f, 0.0f,
		0.5f, -0.5f, 0.0f,
		0.0f, 0.5f, 0.0f
	};

	GLuint VAO, VBO;
	// VAO & VBO 생성
	glGenVertexArrays(1, &VAO);
	glGenBuffers(1, &VBO);

	// VAO 바인딩
	glBindVertexArray(VAO);

	// VBO 바인딩 + 데이터 전달
	glBindBuffer(GL_ARRAY_BUFFER, VBO);
	glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

	// 정점 속성 지정 (position);
	glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0);
	glEnableVertexAttribArray(0);

	// 바인딩 해제
	glBindBuffer(GL_ARRAY_BUFFER, 0);
	glBindVertexArray(0);

	// --- 셰이더 컴파일 및 프로그램 생성 ---
	GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER);
	glShaderSource(vertexShader, 1, &vertexShaderSource, NULL);
	glCompileShader(vertexShader);

	GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
	glShaderSource(fragmentShader, 1, &fragmentShaderSource, NULL);
	glCompileShader(fragmentShader);

	GLuint shaderProgram = glCreateProgram();
	glAttachShader(shaderProgram, vertexShader);
	glAttachShader(shaderProgram, fragmentShader);
	glLinkProgram(shaderProgram);

	// 세이더는 프로그램에 연결 후 삭제 가능
	glDeleteShader(vertexShader);
	glDeleteShader(fragmentShader);

	while (!glfwWindowShouldClose(window))
	{
		processInput(window);
		glClearColor(0, 0, 0, 1);
		glClear(GL_COLOR_BUFFER_BIT);

		glUseProgram(shaderProgram);
		glBindVertexArray(VAO);
		glDrawArrays(GL_TRIANGLES, 0, 3);

		glfwSwapBuffers(window);
		glfwPollEvents();
	}

	// --- 종료 처리 ---
	glDeleteVertexArrays(1, &VAO);
	glDeleteBuffers(1, &VBO);
	glDeleteProgram(shaderProgram);
	glfwTerminate();
	return (0);
}

1. 삼각형은 그래픽스의 최소 단위

그래픽스에서 화면에 뭔가를 그릴 때, 그 기본은 항상 삼각형인데요

왜 삼각형인지 찾아 보았다

평면 상의 가장 단순한 다각형 (모든 다각형은 삼각형으로 나눌 수 있음)
GPU 하드웨어 친화적 (세 점이면 면이 정의됨)
렌더링 파이프 라인 구조상, 삼각형을 기준으로 rasterization이 이루어짐

rasterization

우리는 오늘 이 삼각형 하나를 그리기 위해 필요한 OpenGL파이프라인 구성을 배워볼 것이다.

2. VAO와 VBO는 왜 필요한가?

OpenGL의 Core Profile에서는 삼각형을 그리려면 정점 데이터 (Vertex Data)를 GPU에게 보내줘야 한다.

그 데이터는 버퍼에 담겨야 하, 그 버퍼를 설명하는 정보도 있어야 한다.

요소	역할
VBO (Vertex Buffer Object)	정점 데이터를 GPU에 저장
VAO (Vertex Array Object)	정점 버퍼(VBO)를 어떻게 해석할지 정의

VBO는 데이터 저장소, VAO는 데이터 해석 방법이라고 보면 된다.

쉽게 말해, VBO가 책이라면, VAO는 그 책의 목차다.

참고: VAO는 OpenGL 3.0 이상 Core Profile에선 필수. 없으면 에러!

3. 셰이더 프로그램 생성

OpenGL은 셰이더 없이 그릴 수 없다.

셰이더란 GPU에게 어떻게 그릴 지를 알려주는 프로그램이다.

Vertex Shader

#version 330 core
layout (location = 0) in vec3 aPos;

void main() {
    gl_Position = vec4(aPos, 1.0);
}

이 Vertex Shader는 아주 기본적인 형태이지만, OpenGL에서 렌더링 파이프라인의 첫 번째 관문이자 정점 처리의 핵심이다.

각 줄에 대해서 설명

#version 330 core
-> 이 셰이더는 OpenGL 3.3 Core Profile에 맞는 GLSL(OpenGL Shading Language) 문법을 사용하겠다는 뜻.
layout (location = 0) in vec3 aPos;
-> 이 부분은 GPU로부터 입력받을 정점 속성(Attribute)을 선언.
Location = 0은 C++ 코드에서 glVertexAttribPointer(0, ...)로 연결해 준 버퍼 데이터의 위치와 매핑된다.
Loaction = 1일 경우 C++코드에서 glVertexAttribPointer(1, ....)로 연결한 것
void main()
-> 셰이더 프로그램은 항상 main() 함수부터 실행된다, GPU에서 수천 개의 정점을 동시에 처리할 때 이 main()이
병렬 실행된다.
gl_Position = vec4(aPos, 1.0);
-> 핵심 부분! OpenGL은 모든 정점 위치를 동차 좌표(clip space)로 변환해야만 그릴 수 있다.
그래서 vec3인 정점 위치에 w = 1.0을 붙여서 vec4로 만들어 gl_Position에 넣는다.

여기서 gl_Position은 OpenGL 내부 파이프라인에서 꼭 필요한 예약 변수로,
이 값이 나중에 resterization 단계를 거쳐 화면 좌표로 바뀐다.

요약하면:

정점 하나하나를 처리해서 화면 좌표계로 넘기는 작업.
나중에 카메라, 변환 행렬 등이 추가되면 이 부분이 훨씬 복잡해짐.
지금은 아주 기본적인 통과 셰이더(pass-throgh shader) 역할.

Fragment Shader

#version 330 core
out vec4 FragColor;

void main() {
	FragColor = vec4(1.0, 0.5, 0.2, 1.0); // 주황색
}

이 셰이더는 삼각형이 rasterization 과정을 거친 후, 화면의 픽셀을 어떤 색으로 칠할지 결정하는 역할.

각 줄에 대해서 설명

#version 330
-> Vertex Shader와 동일하게, OpenGL 3.3 Core Profile에 맞춰 작성한 셰이더 버전.
out vec4 FragColor;
-> 이건 출력 변수. vec4는 RGBA로 구성된 최종 색상을 의미.
이 변수가 GPU 파이프라인을 통해 화면에 실제로 출력되는 색상.
void main()
-> Fragment Shader도 각 픽셀 단위(Fragment)로 실행된다.
삼각형 내부 픽셀마다 이 함수가 호출되며, 하나하나 색을 지정한다.
FragColor = vec4(1.0, 0.5, 0.2, 1.0);
-> 픽셀을 주황색(빨간색 100%, 초록색 50%, 파란색 20%, 알파 100%)으로 칠한다는 뜻.
이걸 gl_FragColor로 쓰던 시절도 있었지만, 지금은 명시적으로 out 변수로 정의해야 함.

요약하면:

정점 처리 후 생긴 픽셀마다 실행돼서, 그 픽셀의 최종 색상을 결정.
텍스처, 조명, 음영, 하이라이트 등 모두 이 단계에서 구현된다.
지금은 단순히 "색만 고정 출력"하는 기본 셰이더지만, 응용하면 거의 모든 렌더링 효과를 만들 수 있다.

4. 렌더링 루프 안에 드로우 코드 추가

while (!glfwWindowShouldClose(window))
{
	processInput(window);
	glClearColor(0, 0, 0, 1);
	glClear(GL_COLOR_BUFFER_BIT);

	glUseProgram(shaderProgram);       // 셰이더 사용
	glBindVertexArray(VAO);            // VAO 바인딩
	glDrawArrays(GL_TRIANGLES, 0, 3);  // 삼각형 그리기

	glfwSwapBuffers(window);
	glfwPollEvents();
}

이제 렌더링 루프 안에서 드로우 코드를 넣고 실행해 보면

simple Triangles

이렇게 주황색 삼각형이 보이면 성공한 것이다!

만들며 궁금했던 점들

1. gl_Position은 정의돼 있는 변수인가?

GLSL의 내장(내부) 변수가 맞다

GLSL은 OpenGL 파이프라인과 맞물리는 구조로 설계되어 있어서

그중에서도 gl_Position은 Vertex Shader에서 반드시 지정해야 하는 출력 변수로 설정되어 있다.

정확히 말하자면 gl_Position은 VertexShader가 GPU에 넘기는 최종 정점 위치를 나타내는 내장 변수다.

이 값은 클립 공간 (Clip Space) 좌표다.
이후 자동으로 NDC(Normalized Device Coordinates)로 변환되고,
다시 Viewport 변환을 거쳐 스크린 좌표로 찍히게 된다.

즉, gl_Position에 우리가 지정한 vec4(x, y, z, w)가 그래픽스 파이프 라인에 쭉 따라가서

화면에 삼각형이 보이게 되는 원인이 되는 것.

2. gl_Position과 Fragment Shader는 연결되어 있나?

Vertex Shader와 Fragment Shader는 OpenGL 파이프라인 내에서 다단계 릴레이 시스템처럼 동작한다.

Vertex Shader가 정점들을 처리해서 삼각형을 정의하고,
Rasterizer가 그 삼각형을 픽셀 단위(fragment)로 나눔
그 픽셀마다 프래그먼트 셰이더가 색상을 결정

즉, gl_Position은 삼각형이 어디에 그려질지를 결정하고,

그 삼각형 안의 픽셀들에 대해서 Fragment Shader가 색을 채우는 역할을 한다.

OpenGL이 굉장히 저수준 API이기 때문에 명확한 지시 없이는 어떤 일도 하지 않는 것 같다.

DirectX도 Vulkan도 마찬기지로. GPU는 매우 병렬적이고 강력한 하드웨어지만, 그만큼 명확한 지시 없이는 어떤 일도 하지 않는다.

Scop 구현기 1편: 윈도우 하나 띄우는 게 뭐라고 (Object Viewer)

onepaperhoon — Wed, 9 Apr 2025 15:10:35 +0900

앞선 지식들을 구현하며 공부하느라 많이 정리를 하지 못했습니다.
구현했던 순서대로 작성을 해보겠습니다!

윈도우를 만들기 위한 전체 코드

#include <GL/glew.h>
#include <GLFW/glfw3.h>
#include <OpenGL/gl.h>
#include <iostream>

int main(void)
{
	if (!glfwInit())
	{
		std::cerr << "GFLW Init Failed" << std::endl;
		return (-1);
	}

	glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
	glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
	glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
	glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);

	GLFWwindow* window = glfwCreateWindow(500, 500, "scop", NULL, NULL);

	glfwMakeContextCurrent(window);
	int framebuffer_w, framebuffer_h;
	glfwGetFramebufferSize(window, &framebuffer_w, &framebuffer_h);
	glViewport(0, 0, framebuffer_w , framebuffer_h);

	if (glewInit() != GLEW_OK)
	{
		std::cerr << "GLEW Init Failed" << std::endl;
		glfwTerminate();
		return (-1);
	}

	while (!glfwWindowShouldClose(window))
	{
		glClearColor(0, 0, 0, 1);
		glClear(GL_COLOR_BUFFER_BIT);

		glfwSwapBuffers(window);
		glfwPollEvents();
	}
	glfwTerminate();
	return (0);
}

1. OpenGL 프로젝트의 시작은 항상 창 만들기부터!

OpenGL은 "그래픽"만 담당합니다. 운영체제 창은 만들어주지 않죠.

그래서 우리는 GLFW 같은 라이브러리를 써야 해요. GLFW는 "운영체제에 독립적인 윈도우 생성 및 입력 처리"를 담당합니다.

#include <GLFW/glfw3.h>헤더를 포함한 뒤 glfw 함수를 사용하기 위해 초기화해야 합니다.

if (!glfwInit()) {
	std::cerr << "GFLW Init Failed" << std::endl;
	return (-1);
}

glfwInit() 은 GLFW를 사용하기 위해 라이브러리 초기화 함수입니다.

초기화가 성공하면 GLFW_TRUE(1)를 오류가 발생하면 GLFW_FALSE(0)가 반환됩니다.

실패하면 OpenGL을 시작도 못 하게 됩니다. 그래서 항상 체크해 주는 게 기본 중 기본입니다.

참고로 glfwInit은 내부적으로 OS에 맞는 초기화 루틴을 실행합니다.
예: 윈도우에서는 WinAPI 초기화, 맥에서는 Cocoa 세팅 등!

GLFW 사용이 끝나면, 일반적으로 프로그램이 종료되기 직전에 GLFW를 종료해야 합니다.

glfwTerminate ();

이렇게 하면 남아 있는 모든 윈도우가 삭제되고 GLFW가 할당한 다른 리소스도 해제됩니다.

이 함수를 호출한 후에는 GLFW를 다시 초기화해야 해당 리소스를 필요로 하는 GLFW함수를 사용할 수 있습니다.

2. OpenGL 3.3 Core Profile로 세팅하기

glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);

이건 뭐냐고요? 간단히 말하면,

"나는 2000년대 OpenGL 말고, 최신 방식만 쓸 거야!" 선언입니다.

GLFW_CONTEXT_VERSION_MAJOR, MINOR -> OpenGL 버전 지정(3.3은 안정적 + 최소 셰이더 기반 버전)
GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE -> 구형 API 제거, VAO/VBO 안 쓰면 에러 발생!
GLFW_OPENGL_FORWARD_COMPAT -> 더 이상 안 쓰는 기능 무시 (Mac에선 필수!)

이걸 안 하면 VAO 없이도 그려지는 이상한(?) 상태가 발생될 수 있어요.

왜 GLFW_OPENGL_CORE_PROFILE이 중요한가?

VAO 없이도 그려지는 이상한(?) 상태의 정체

glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

위 설정을 하지 않으면 기본적으로 Compatibility Profile로 실행될 수 있습니다.
그러면 OpenGL의 예전 방식, 예를 들면 glBegin, glVertex, glEnd와 같은 함수들이 여전히 살아있죠. 그뿐만 아니라, VAO (Vertex Array Object) 없이도 버퍼를 쓰는 게 “되는 것처럼 보이는” 상황이 발생합니다.

이게 왜 문제냐고요?

\Core Profile에서는 VAO 없이 그리면 명백하게 에러가 납니다. VAO가 없으면 GPU는 “어떤 버퍼에서, 어떤 방식으로 정점 데이터를 읽을지”를 알 수 없기 때문이죠.

하지만 Compatibility Profile에선 자동으로 기본 VAO 상태가 세팅되어 있는 것처럼 작동합니다. 그래서 실수로 VAO를 안 만들었는데도 삼각형이 그려지거나, 버퍼가 먹히는 일이 생깁니다.

이 상태가 바로 "이상한(?) 상태"입니다. 코드가 돌아가긴 하는데, 실제로는 명확하지도, 이식성도 없고, 최신 OpenGL 문법에도 어긋납니다.

3. GLFW 윈도우 생성과 컨텍스트 설정

GLFWwindow* window = glfwCreateWindow(500, 500, "scop", NULL, NULL);
glfwMakeContextCurrent(window);

드디어 창을 생성했습니다!

glfwCreateWindow()는 너비, 높이, 창 이름을 받고 윈도우를 만들어줘요

근데 만든다고 바로 쓰는 건 아닙니다.

OpenGL은 렌더링 컨텍스트라는 걸 만들어야만 함수들이 제대로 작동해요.

그래서 glfwMakeContextCurrent(window)로 이 창을 "현재 쓰는 컨텍스트"로 등록합니다.

참고: "컨텍스트"는 OpenGL 상태 저장소라고 보면 됩니다, OpenGL 함수들은 모두 이 상태에 종속되며.
프레임버퍼 객체에 그리지 않을 때 렌더링 명령이 그릴 (잠재적으로 보이는) 기본 프레임 버퍼를 나타냅니다.

4. Viewport 설정 - 너의 픽셀 범위는 어디니?

int framebuffer_w, framebuffer_h;
glfwGetFramebufferSize(window, &framebuffer_w, &framebuffer_h);
glViewport(0, 0, framebuffer_w , framebuffer_h);

여기서 창이 생겼다고 GPU가 그릴 공간이 자동으로 지정되는 건 아닙니다.

glViewport는 말 그래도 이 화면에서 실제로 그릴 픽셀 영역을 정해줘요.

(0, 0)은 좌측 하단의 시작점
(w, h)는 그릴 영역 크기

고해상도 모니터 (예: Retina)에서는 실제 프레임버퍼 크기가 창 사이즈보다 클 수 있어서
glfwGetFramebufferSize로 정확하게 받아와야 합니다.

5. GLEW로 OpenGL 함수 포인터 초기화

if (glewInit() != GLEW_OK) {
	std::cerr << "GLEW Init Failed" << std::endl;
	glfwTerminate();
	return (-1);
}

OpenGL 함수는 마법처럼 다 쓸 수 있는 게 아닙니다.

OS는 기본적으로 OpenGL의 정의만 알려주고, 실제 포인터 주소는 우리가 직접 가져와야 해요.

그래서 GLEW를 써서 모든 OpenGL 확장 함수 포인터를 초기화합니다.

GLEW는 Extension Wrangler의 약자
glGenBuffers, glCreateShader 등등.. 다 여기서 초기화됨

실패했을 때 위에서 glfw를 생성했기 때문에 glfwTerminate를 호출한 뒤 나가는 게 중요 포인트!

GLEW를 쓰지 않는다면? glX, wgl처럼 OS별 API로 직접 불러와야 하는 복잡한 세상에 빠집니다.

6. 루프: 그리기, 버퍼 교체, 이벤트 처리

while (!glfwWindowShouldClose(window)) {
	glClearColor(0, 0, 0, 1);
	glClear(GL_COLOR_BUFFER_BIT);

	glfwSwapBuffers(window);
	glfwPollEvents();
}

드디어 메인 루프!

창을 열고 계속해서 프레임을 갱신합니다.

glClearColor와 glClear로 매 프레임 배경색을 초기화
glfwSwapBuffers: 백 버퍼를 프론트로 교체 (더블 버퍼링)
glfwPollEvents: 마우스, 키도브, 창 크기 등 이벤트 확인

이 루프 안에서 드로잉, 물리 연산, 애니메이션 등 모든 게 돌아갑니다.

OpenGL Window

7. 종료 처리 - 메모리는 우리가 책임져야죠

glfwTerminate();
return (0);

마지막엔 GLFW가 사용한 자원을 해제해줘야 해요.

안 그러면 OS에 리소스가 남아 이상한 버그의 원인이 되기도 하죠.

다음 글 예고

지금까지는 정말 "창만 띄운" 코드였죠.

하지만 여기서부터가 진짜 시작입니다. 앞으로 우리는

VAO, VBO를 만들고
셰이더를 로딩하고
3D 모델을 로딩하고
마우스로 회전까지!

Scop 구현기 2편: VAO와 VBO의 세계

Rasterization vs Ray Tracing

onepaperhoon — Wed, 9 Apr 2025 06:30:13 +0900

렌더링 기술의 두 갈래, 무엇이 다르고 왜 중요한가?

게임 그래픽을 담당하는 개발자 A는 GPU 성능을 쥐어짜며 실시간 렌더링을 구현하고 있었습니다.

그런데 어느 날, 팀의 아티스트가 무심코 묻습니다.

"레이 트레이싱 쓰면 더 예쁘지 않아요? 왜 안 써요?"

개발자 A는 한숨을 쉬며 이렇게 답합니다.

"아름다움은 계산량과 반비례하거든요...."

그래서 오늘의 질문은 이것입니다.

왜 어떤 렌더링은 Rasterization을 쓰고, 어떤 렌더링은 Ray Tracing을 쓸까?

둘은 어떻게 다르고, 각각 어떤 장단점이 있을까?

이 글에서는 두 기술의 핵심 원리, 차이점, 그리고 실제 적용 사례까지 알아보겠습니다.

1. Rasterization - 화면에 삼각형을 빠르게 찍는 기술

Rasterization은 3D 공간의 정점을 화면 좌표계로 투영한 뒤, 삼각형 단위로 색상을 채워나가는 방식입니다.

즉, '모양'을 기준으로 빠르게 픽셀을 칠하는 방식입니다.

핵심 프로세스

모델 정점(Vertex)을 가져온다
뷰 변환 및 투영(Projection)을 적용한다
삼각형 구성 및 화면 공간으로 변환한다
삼각형 내부 픽셀 색칠 (Fragment Shader)

// OpenGL 기본 예시
glUseProgram(shaderProgram);
glBindVertexArray(vao);
glDrawArrays(GL_TRIANGLES, 0, 3); // 삼각형을 그린다

장점과 단점

장점	단점
매우 빠름 (GPU 최적화 완료)	광학 효과 표현이 제한됨
코드가 단순하고 예측 가능함	복잡한 조명은 트릭으로 구현해야 함

2. Ray Tracing - 픽셀마다 광선을 쏘는 방식

Ray Tracing은 카메라에서 출발한 광선을 따라가며

카메라에서 쏜 광선은 장면 속 물체에 닿거나, 계속 진행해 화면 밖으로 사라집니다.

광선이 어떤 물체에 닿는다면, 그 표면에서 반사되거나 굴절되어 다시 다른 경로로 나아가게 되죠.

이렇게 반사되거나 굴절된 광선은 또 다른 물체에 닿거나, 결국 광원에 도달하거나,

아니면 그냥 사라질 수도 있습니다.

이 과정을 재귀적으로 반복하면서,

빛의 흐름이 어디에서 어떻게 시작되어 카메라까지 도달하는지를 역추적합니다.

결국 광원이 닿는 경로를 찾게 되면,

그 경로를 따라 들어오는 빛의 기여도(조명, 색상, 반사율 등)를 계산해 해당 픽셀의 최종 색을 결정합니다.

이처럼 “빛이 어떻게 반사되어 이곳까지 왔는가?”를 거슬러 추적하여

이미지를 만들어내는 기법이 바로 Ray Tracing입니다.

Ray Tracing

장점과 단점

장점	단점
자연스러운 그림자, 반사, 굴절 표현 가능	매우 높은 연산량(느림)
물리 기반 조명 계산 (PBR에 최적)	실시간 처리를 위해선 RTX 등 필요

3. 요즘 게임은 왜 Ray Tracing을 쓰기 시작했을까?

예전엔 Ray Tracing을 '쓸 수 없었던 기술'이었습니다.

너무 느렸거든요.

하지만 2018년, NVIDIA가 RTX 시리즈 + 하드웨어 레이 트레이싱을 도입하면서 판이 바뀌었습니다.

이후 등장한 기술이 바로 Hybrid Rendering 입니다.

Hybrid 방식: Raster + Ray의 콜라보

기본적인 장면 그리기: Rasterization
반사, 그림자, 글로벌 일루미네이션(GI): Ray Tracing
-> 빠른 속도는 유지하고, 빛의 퀄리티는 리얼하게 가져가는 전략

Ndivia Hybrid Rendering Pipeline

대표 게임

Cyberpunk 2077
Minecraft RTX
Battlefield V
Hogwarts Legacy 등

4. 비교 요약: 언제 어떤 방식을 써야 할까?

항목	Rasterization	Ray Tracing
작동 방식	정점 -> 삼각형 -> 픽셀	카메라에서 광원 발사 -> 교차 확인
렌더링 속도	매우 빠름	상대적으로 느림
광확 효과 구현	쉐이더 기반 트릭 사용	자연스러운 표현 가능
주 사용 분야	게임, 실시간 그래픽스	영화, 시각화, 오프라인 렌더링
하드웨어 요구	GPU 기본 지원	RTX 등 특수 하드웨어 필요

5. 왜 둘은 철학이 다른가?

Rasterization은 빠른 속도와 예측 가능성이 우선인 철학입니다.

"현실을 모방한다"는 것보다는, "현실처럼 보이게 하는 트릭"에 집중하며 발전해 왔습니다.
성능을 위해 비현실적 계산도 과감히 생략합니다.

Ray Tracing은 현실을 물리 기반으로 시뮬레이션하는 철학입니다.

실제 빛의 경로처럼 반사, 굴절, 그림자를 추적합니다.
결과는 자연스럽지만, 계산량은 필연적으로 많습니다.

현실과 비슷하게 보이게 할 것이냐?
아니면, 현실처럼 "계산"할 것이냐?

이 철학적 질문이 두 렌더링 방식의 차이입니다.

셰이더는 그낭 함수일까?

onepaperhoon — Tue, 8 Apr 2025 17:18:13 +0900

GPU 프로그래밍의 착각과 진실

1. 셰이더는 정말 함수일까?

void main()
{
    gl_Position = ...;
}

처음 GLSL 셰이더 코드를 보면 진짜 함수처럼 생겼다.

C 언어와 똑같은 void main()에, 변수 선언, 수식, return 없이도 끝나는 심플한 구조까지.

그래서 흔히 이렇게 착각하곤 한다.

"아하, 셰이더도 함수니까 그냥 내가 부르면 되겠네?"

그런데 막상 실행해 보면 이상하다.

main()을 딱 한 번 쓴 것 같은데, 화면 전체에 셰이더가 작동한다.

어라? 내가 호출한 적 없는데?

그럼 셰이더는 대체 뭐지?

그냥 함수처럼 보이는데.... 진짜 함수는 아닌 걸까?

2. 셰이더란 무엇인가?

셰이더는 GPU에서 실행되는 작은 프로그램이다.

이 프로그램은 정점(Vertex), 픽셀(Fragment), 도형(geometry) 같은 그래픽 데이터를 처리하는 전용 처리 유닛으로 작동한다.

대표적인 셰이더 종류는 다음과 같다

Vertex Shader: 정점 하나하나의 위치와 속성 처리
Fragment Shader: 픽셀 하나하나의 색상 결정
(선택적) Gemetry / Tessellation / Compute 등

이 셰이더들은 모두 특정 그래픽 파이프라인의 단계에 '자동'으로 삽입되어 실행된다.

즉, 우리가 직접 호출하는 것이 아니라, GPU가 데이터를 처리할 때마다 스스로 실행된다.

3. 셰이더 구조는 함수처럼 생겼다

// vertex shader
#version 330 core
layout (location = 0) in vec3 aPos;

uniform mat4 model;
uniform mat4 view;
uniform mat4 projection;

void main()
{
    gl_Position = projection * view * model * vec4(aPos, 1.0);
}

// fragment shader
#version 330 core
out vec4 FragColor;

void main()
{
    FragColor = vec4(1.0, 0.5, 0.2, 1.0); // 주황색
}

이 코드를 보면 정말 함수처럼 생겼다.

심지어 void main() 도 똑같고, 변수도 선언하고, 곱셈 연산도 하고, 값을 대입하고...

하지만 이 셰이더는 우리가 실행하지 않는다.

대신 OpenGL이 glDraw*()를 호출하는 순간 수천 번 자동 실행한다.

예를 들어 1000개의 정점이 있다면, vertex shader의 main()은 1000번 실행된다.

4. CPU함수 vs GPU 셰이더의 결정적 차이점

항목	CPU함수	GPU 셰이더
실행 주체	내가 호출함	GPU가 자동 실행
실행 횟수	호출한 만큼	정점/픽셀 개수 만큼 반복 실행
입출력 구조	인자, 반환값	in/out, uniform, gl_Position등 특수 변수
실행 위치	CPU의 한 쓰레드	GPU의 수천 개 코어에서 동시에 실행
목적	논리 처리, 계산	그래픽 처리 전용

5. 데이터가 흐르면 실행되는 파이프라인

셰이더는 함수처럼 생겼지만, 실행 흐름이 함수가 아니다.

우리는 vertexShader.main() 같은 걸 호출하지 않는다.

대신 우리가 하는 일은 단 하나다.

glDrawArrays(...);

그러면 GPU는 내부적으로 다음과 같은 일을 한다

버퍼에 담긴 정점 데이터를 꺼냄
정점 개수만큼 vertex shader의 main()을 병렬 실행
삼각형 조립 -> rasterization -> 각 픽셀마다 fragment shader의 main() 병렬 실행

즉, 셰이더는 데이터 흐름에 붙은 작은 프로그램이다.

마치 공장 컨베이어 벨트 위의 자동화 로봇팔처럼,

데이터가 지나갈 때 알아서 일하는 프로그램이다.

6. 함수처럼 짜긴 짤 수 있다

vec3 brighten(vec3 color, float power) {
    return clamp(color + vec3(power), 0.0, 1.0);
}

void main()
{
    FragColor = vec4(brighten(vec3(1.0, 0.3, 0.1), 0.2), 1.0);
}

GLSL은 일반적인 함수도 지원한다.

그래서 셰이더 안에서도 보조 함수를 정의해서 재사용할 수 있다.

하지만 이 코드도 픽셀 수만큼 main()이 실행되며,

그 안에서 각각 brighten()이 호출되는 것일 뿐이다.

결국 구조는 함수 같지만, 전체 흐름은 병렬 파이프라인에 속해 있다.

7. "프로그래머가 직접 호출하지 않는 함수"

프로그래밍의 본질은 "함수를 정의하고 호출"하는 데 있다고 생각할 수 있다.

하지만 셰이더는 다르다.

우리는 직접 호출하지 않는다.
호출 순서를 정하지도 않는다.
return 값도 없다.

그럼에도 불구하고, 정의된 코드는 자동으로 동작하며 세상을 바꾼다.

이건 마치 JavaScript의 이벤트 리스너 같기도 하고,

함수형 프로그래밍의 map/filter처럼 데이터에 따라 자동 호출되는 콜백 구조와도 닮았다.

셰이더는 "나를 불러줘"가 아니라
"내가 그 자리에 있으면 알아서 불러주겠지"에 가까운 존재다.

8. 요약 - 셰이더는 GPU의 함수 같지만, '그런 함수'는 아니다

셰이더는 함수처럼 보이지만,
파이프라인에서 자동으로 실행되며,
GPU의 수많은 코어에서 병렬적으로 작동하는 그래픽 전용 프로그램이다.

이런 점에서 셰이더는 일반적인 프로그래밍 함수보다

GPU 병렬 처리에 특화된 작은 데이터 기반 스크립트라고 보는 게 더 정확하다.

OpenGL의 좌표계, 진짜로 이해하기

onepaperhoon — Tue, 8 Apr 2025 11:00:38 +0900

"왜 0, 0, 0에 두었는데 화면에 안 보일까?

1. 좌표계가 헷갈리는 이유

OpenGL에서 처음 물체를 렌더링 할 때 이런 경험이 있다면 당신만 그런 게 아니다

분명히 (0, 0, 0)에 모델을 뒀는데 화면에 아무것도 안 보인다.
카메라는 설정했는데 방향이 어디를 보는지 감이 없다.
gl_Position 계산했는데 화면이 시커멓다.

이런 혼란의 원인은 대부분 좌표계와 변환에 대한 이해 부족이다.

OpenGL에서의 렌더링은 단순한 그리기가 아니라,

"모델의 좌표를 변환해 최종 스크린까지 도달시키는 여정"이다.

2. 좌표계란 무엇인가?

좌표계(Coordinate System)는 공간의 기준을 정의하는 약속이다.

어디를 기준으로 (0, 0, 0)인지, 각 축이 어느 방향을 향하는지를 정의한다.

OpenGL은 총 6단계의 좌표계를 거치며 위치를 변환한다

Object -> World -> View -> Clip -> NDC -> Screen

각 단계는 행렬(Matrix) 연산으로 이어지며,

이는 다음과 같은 연산으로 요약된다

gl_Position = Projection * View * Model * vec4(position, 1.0);

즉, 하나의 정점(Vertex)을 최종 위치로 변환하는 데는 3개의 행렬과 6개의 좌표계가 필요하다.

시작하기 앞서 OpenGL에서 기본적으로 사용하는 좌표계 방향을 알아보자

Right Handed system

OpenGL에서는 기본적으로 오른손 좌표계를 사용하고 있고

기본 뷰 카메라는 -Z방향을 보고 있기 때문에 흔히 하는 실수는

물체를 +Z 축 방향으로 이동시키면 카메라의 뒤쪽으로 물체를 보내버리는 셈이라 화면에 보이지 않게 된다.

3. 좌표계 흐름 완전 정복

이제 각 좌표계가 무엇을 의미하고, 왜 존재하는지를 하나씩 세세히 알아보자.

1. 모델 좌표계 (Model Space, 또는 Local/Object Space)

"이 물체 자체 안에서 좌표가 어떻게 생겼나?"

각 정점은 오브젝트 기준으로 표현됨
예: 정육면체는 중심을 (0, 0, 0)으로 하고, 꼭짓점은 (-1, -1, -1) 같은 값

Model행렬은 이 모델을 "어디에", "얼마나 회전시켜", "얼마나 확대/축소할지" 결정한다

model = Translate * Rotate * Scale;

Model -> World

2. 월드 좌표계 (World Space)

"이 오브젝트를 세상 안에 어떻게 배치할까?"

모델이 속해있는 월드 좌표 기준으로 변환.
모든 물체들이 공유하는 절대적 위치 기준
서로 다른 모델들이 이 좌표계에서 충돌 검사, 카메라 연산 등을 할 수 있게 된다.

3. 뷰 좌표계 (View Space, Camera Space)

"카메라의 시점에서 이 물체는 어떻게 보일까?"

카메라를 원점 (0, 0, 0)으로 이동시키는 것처럼 동작
월드 공간의 모든 물체들을 카메라 기준으로 뒤로 이동시키는 연산
View행렬은 LookAt() 같은 방식으로 만든다

view = glm::lookAt(cameraPos, targetPos, upVector);

4. 클립 좌표계 (Clip Space)

"투영(projection)을 거쳐 계산된 공간. 아직 정규화는 안 됨"

Perspective(원근) 또는 Orthographic(직교) 방식으로 변환됨
Z 축 깊이 정보가 보존되지만, 아직 w를 나누기 전이라 왜곡되지 않음
모든 좌표계 중 가장 수학적인 단계

Perspective orthographic

5. NDC (Normalized Device Coordinates)

"좌표계를 -1 ~ 1 사이로 정규화"

클립 공간 좌표를 w로 나누어 정규화한 좌표계

OpenGL에서 그릴 수 있는 범위는 반드시 -1 ≤ x, y, z ≤ 1 이내여야 함

이 범위를 넘으면 자동으로 잘려(Clipping) 버려짐

Cplipping

쉽게 비유하면, 클립공간에서 NDC좌표계로 변환되며 -1~1의 범위를 넘어가는 경우

카메라로 촬영할 때 카메라의 뷰파인더와 같이 뷰파인더 안에 들어온 장면만 필름에 담기고,

바깥은 잘려나가는 것과 같다

NDC는 해상도에 상관없는 '가상 화면' 개념

따라서 1920x1080이든, 300x300이든 NDC의 좌표값은 같다.

6. 스크린 좌표계 (Screen Space)

"정말로 픽셀이 존재하는 화면"

NDC의 -1~1 범위를 실제 해상도 (예: 800x600)에 매핑
Viewport 설정에 따라 달라짐

giViewport(0, 0, screenWidth, screenHeight);

4. w로 나누는 이유 - 원근 투영의 핵심

OpenGL은 gl_Position = vec4(x, y, z, w); 로 셰이더에서 좌표를 출력한다.

그런데 렌더링 전에 GPU는 자동으로 다음과 같은 연산을 수행한다.

x' = x / w
y' = y / w
z' = z / w

이게 바로 원근(Perspective) 투영의 핵심이다.

w 값은 보통 카메라로부터의 거리와 관련된 값이다.
멀리 있는 물체일수록 w값이 커지고, 그 결과 x/w, y/w는 작아져서 더 작게 보인다.

즉, 원근 왜곡 효과는 이 w 나눗셈에서 시작된다.

5. 자주 생기는 좌표계 관련 실수

상황	원인	해결 방법
물체가 안 보인다	NDC 범위 밖에 있음	View/Projection 설정 점검
화면에 물체가 너무 큼	FOV나 Neer/Far Plane 이상함	Projection 행렬 확인
텍스처가 뒤집혀 보임	UV좌표계와 스크린 좌표계 차이	텍스처 flip 설정 확인

6. 좌표계 흐름 요약표

좌표계	설명	변환 행렬
모델	오브젝트 내부 기준	Model
월드	전역기준 좌표	Model
뷰	카메라 기준	View
클립	투영된 좌표	Projection
NDC	정규화된 -1~1 공간	w 나눗셈
스크린	실제 해상도 픽셀 기준	Viewport 매핑

참고 자료

• LearnOpenGL - Coordinate Systems

• OpenGL Wiki - Vertex Transformation

• Scratchapixel - 3D Perspective Projection

정점(Vertex)이란 무엇인가? - 그래픽 세계의 가장 작은 시작점

onepaperhoon — Tue, 8 Apr 2025 07:00:46 +0900

1. 정점이라는 단어, 너무 자주 보인다

컴퓨터 그래픽스를 막 시작하면 다음과 같은 단어들을 자주 보게 된다

Vertex Buffer
Vertex Shader
gl_Position
layout (location = x)

이 단어들은 모두 정점(Vertex)이라는 개념과 밀접하게 연결되어 있다.

하지만 처음엔 너무 당연하다는 듯 쓰이기 때문에

"그래서... 정점이라는 게 도대체 뭐야?"
라는 질문이 생기기 마련이다.

2. 정점은 '점'이 아니다

단어 뜻 그대로만 보면, 정점(Vertex)은 공간 위의 점 하나로 생각할 수 있다.

하지만 그래픽에서의 정점은 단순한 위치 정보만 담고 있는 것이 아니다.

정확히 말하자면, 정점은 '위치 + 속성 정보들'의 묶음이다.

예를 들어, 게임 캐릭터의 얼굴 한 지점은 단순히 (x,y,z) 위치 외에도

거기에 어떤 색상이 칠해져야 하는지
어떤 텍스처 좌표(UV)를 갖는지
빛에 어떻게 반응해야 하는지(Normal)

등의 정보가 모두 하나의 정점 데이터에 포함되어 있어야한다.

일반적으로 하나의 정점은 다음 정보를 포함하고 있다

구성 요소	설명
위치(Position)	3D 공간상의 좌표 (x,y,z)
색상(Color)	RGB 또는 RGBA
텍스쳐 좌표(UV)	이미지 매핑 좌표
노멀 벡터(Normal)	조명 계산용 방향 백터
접선(Tangent)	(선택적) 고급 조명 계산용

3. 정점 -> 삼각형 -> 메시(mesh)

그래픽에서 도형은 정점으로부터 만들어진다.

정점 3개를 연결하면 삼각형
삼각형 수십 개가 모이면 메시(Mesh)
메시 수백 개가 모이면 모델(Model)

PolyGon Mesh

정점만 있어서는 아무것도 보이지 않지만,

정점을 조합하면 도형이 되고, 도형은 결국 화면에 보이는 모든 3D 그래픽의 기반이 된다.

4. 렌더링 파이프라인에서의 정점

정점은 GPU의 렌더링 파이프라인에서 가장 먼저 처리되는 단위다.

즉, 정점이 없으면 렌더링 자체가 시작될 수 없다.

단계	정점의 역할
Vertex Specification	정점 데이터를 CPU -> GPU로 전달
Vertex Shader	좌표 변환 수행 (모델 좌표 -> 클립 공간)
Primitive Assembly	정점 3개를 삼각형으로 묶음
Rasterization	정점 간의 값 (색상, UV 등)을 보간하여 픽셀 생성

이 괴정을 통해 정점은 위치 정보만 전달하는 것이 아니라,

그래픽 전체에 영향을 주는 주요 정보 전달자 역할을 하게 된다.

5. 실용적인 예: 정점 구조체

struct Vec3{
    float x;
    float y;
    float z;
};

struct Vec2{
    float x;
    float y;
};

struct Vertex{
    Vec3 position;	// 위치
    Vec3 normal;	// 조명 계산용 방향 벡터
    Vec2 texCoord;	// 텍스처 좌표
    Vec3 color;		// 정점 색상
};

이 구조체를 std::vector <Vertex> 등에 담아 VBO(Vertex Buffer Object)로 넘기고,

셰이더에서는 각 속성을 layout(location = x)로 받아 처리한다.

이렇게 정점 데이터가 그래픽 파이프라인에 연결되면,

하나의 정점이 단순한 점을 넘어 화면 위 픽셀 색상까지 영향을 주는 데이터 단위가 된다.

6. 왜 정점이 중요한가?

정점은 모든 그래픽 정보의 시작이다.

정점이 없다면 도형이 만들어질 수 없다.
정점이 많을수록 더 정밀한 메시와 부드러운 곡선 표현이 가능하다.
조명 효과, 그림자, 텍스처 표현 등도 정점 간 정보 보간을 통해 자연스럽게 처리된다.

하지만 너무 많은 정점은 GPU에 부담을 주기 때문에,

정점 데이터 최적화(예: LOD, 정점 캐시 등)는 실전 렌더링에서 굉장히 중요한 요소다.

7. 요약

항목	설명
정점이란?	위치 + 다양한 그래픽 속성 정보
어디 쓰이나?	모든 그래픽 렌더링의 시작점
어떻게 구성?	구조체 -> VBO -> VAO -> 셰이더
왜 중요?	그래픽 품질, 최적화, 보간 전부에 영향

9. 참고 자료

• LearnOpenGL - Vertex Specification

• OpenGL Wiki - Vertex Specification

• GPU Gems 3 - Efficient Vertex Data

렌더링 파이프라인: 그래픽이 만들어지는 과정

onepaperhoon — Mon, 7 Apr 2025 23:05:58 +0900

1. glDrawElements() 또는 glDrawArrays() 줄 뒤에 무슨 일이?

우리가 흔히 쓰는 glDrawElements()나 glDrawArrays() 같은 함수.
이 한 줄의 호출 뒤에, 정확히 무슨 일이 벌어지고,
어떻게 해서 한 줄의 코드가 화면에 그림을 그릴 수 있을까?

2. 렌더링 파이프라인 전체 그림

"정점 데이터가 픽셀이 되는 과정"

OpenGL Grphics Pipe Line

1. Vertex Specification (정점 입력)

CPU가 넘겨준 정점 데이터를 GPU가 이해하도록 연결
glVertexAttribPointer() 등을 통해 설정
위치, 색상, 텍스처 좌표 등

Vertex Specification

glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, position));
glEnableVertexAttribArray(0);

glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, normal));
glEnableVertexAttribArray(1);

glVertexAttribPointer(2, 2, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, texCoord));
glEnableVertexAttribArray(2);

glVertexAttribPointer(3, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, color));
glEnableVertexAttribArray(3);

2.Vertex Shader (정점 변환)

각각의 정점에 대해 실행됨
주 역할: 모델 좌표 -> 클립 공간으로 변환
출력: gl_Position

Vertex Shader 원본 https://webglfundamentals.org/webgl/lessons/webgl-how-it-works.html

gl_Position = projection * view * model * vec4(position, 1.0);

3.Tessellation (정점 세분화) - 선택적

정점 간격을 기준으로 더 촘촘한 삼각형을 만들어 고품질 메시 생성
프래그먼트 셰이더에서 보간 정확도 증가
픽셀당 연산의 의미가 커짐 (특히 PBR, Normal Mapping 등)

4. Geometry Shader (도형 단위 변형) - 선택적

삼각형 전체(3개의 정점 단위)를 입력으로 받아 새로운 정점을 추가하거나 제거 가능
예: 실시간 실루엣 생성, 그림자용 볼륨 생성

Geometry Shader

5. Vertex Post-Processing (좌표계 보정 & 클리핑)

클립 공간에서 NDC로 변환
화면 밖 정점 제거(Clipping)
보이지 않는 Primitive들을 삭제해 버림.
vertex의 좌표계가 clipspace에서 window space로 변환됨

6. Primitive Assembly (도형 조립)

정점들을 삼각형, 선, 점 등 기하 도형(Primitive)으로 묶음
예: 3개의 정점 -> 하나의 삼각형

Primitive Assembly

7. Rasterization (픽셀로 분할)

삼각형 내부를 스캔하여 화면상의 픽셀 좌표(Fragment) 생성
이때 보간(interpolation)도 같이 수행됨 (예: UV, 색상)

Fragment & interpolation

8. Fragment Shader ( 픽셀 색상 계산)

각 프래그먼트에 대해 실행됨
텍스처, 조명, 그림자 계산 등 모두 여기서 처리됨
출력: 최종 색상(out vec4 FragColor)

원본 https://webglfundamentals.org/webgl/lessons/webgl-how-it-works.html

9. Per-Sample Operations (테스트 & 블렌딩 후처리)

Depth Test: 더 가까운 픽셀만 화면에 남김
Stencil, Alpha, Blending 등 후처리
통과한 픽셀만 프레임 버퍼에 기록됨

Stencil Testing

이 모든 과정을 거쳐

GPU는 수천 개의 정점 데이터를 병렬로 처리해
매 프레임마다 수백만 개의 픽셀을 그린다.

요약 표

단계	역할
Vertex Spec	정점 입력
Vertex Shader	좌표 변환
Tessellation	고해상도 분할
Geometry Shader	도형 조작
Post-Process	클리핑, 변환
Assembly	도형 만들기
Rasterization	픽셀 분할
Fragment Shader	색 계산
Per-Sample	테스트 & 블렌딩

컴퓨터 그래픽스에서 말하는 '그래픽'이란 무엇인가?

onepaperhoon — Mon, 7 Apr 2025 14:45:07 +0900

Graphic

1. 그냥 "그림"이 아니다

우리가 "컴퓨터 그래픽스"를 배운다고 할 때, "그래픽"은 도대체 뭘 말하는 걸까?

컴퓨터로 무언가를 그리고, 표현하고, 만들어내는 일을 통틀어 우리는 "그래픽스(Graphics)"라고 부른다.

그런데 막상 그 그래픽이 구체적으로 뭘 말하는지 명확히 설명되지 않는 경우가 많다.

"그래픽이 중요해"

"GPU는 그래픽을 위해 존재해"

"셰이더는 그래픽을 조정하는 코드야"

이렇게 말하긴 쉬운데, 정작 "그래픽"이 뭔지를 정확하게 묻는다면 우리는 뭐라고 대답할 수 있을까?

2. 그래픽은 '시각적 정보'다

컴퓨터 그래픽스에서 그래픽(Graphics) 이란

렌더링(rendering) 과정을 통해 화면에 나타나는 모든 시각적 결과물을 의미한다.

이를 구성하는 대표적인 요소들은 다음과 같다

요소	설명
정점 (Vertex)	점 하나하나의 위치 정보
도형	선(Line), 삼각형(Triangle), 사각형 등
색상(Color)	픽셀 단위의 색 정보
텍스처(Texture)	이미지로 표현되는 표면 정보
조명(Light)	빛의 방향, 강도, 색 등

이 모든 것은 '그래픽'이라는 이름으로 묶인다.

그래픽은 단순히 "보이는 것"을 넘어, 디지털 세계와 우리 눈 사이의 인터페이스다.

3. 왜 '그래픽'이 그렇게 중요할까?

1. 현실과의 연결고리

현실에서는 모든 것이 시각적으로 존재한다.

우리는 화면을 통해 디지털 세계를 보고, 상호작용하고, 판단한다.

그 모든 것은 결국 "그래픽"을 통해 표현된다.

게임에서 캐릭터가 움직인다 -> 그래픽
웹에서 버튼이 빛난다 -> 그래픽
CAD에서 설계 도면을 그린다 ->그래픽

시각적으로 표현되지 않으면, 그것은 존재하지 않는 것이나 다름없다.

2. 하드웨어도 그래픽을 중심으로 발전해 왔다

GPU(Graphics Processing Unit)는 이름 그대로 그래픽 연산을 위한 전용 장치다.
OpenGL, Vulkan, DirectX 등 모든 그래픽스 API는 그래픽 데이터를 다루기 위한 표준이다.
심지어 AI 연산도 GPU에서 빠르게 처리할 수 있는 이유는, 그래픽이 고도로 병렬적인 데이터 처리를 필요로 하기 때문이다.

4. 비유로 이해해 보자

분야	그래픽에 해당하는 것
음악	소리
요리	맛과 비주얼
수학	그래프
연극	무대와 조명

컴퓨터 세계에선?

→ 그래픽은 화면에 보이는 모든 것이다.

→ 그것이 없다면 사용자는 아무것도 볼 수 없다.

5. 요약

그래픽은 단순한 그림이 아니다.
컴퓨터 그래픽스에서 말하는 그래픽은 정점, 선, 색, 텍스처, 조명 등 모든 시각정 요소의 총합이다.
우리는 그것을 만들기 위해 GPU를 쓰고, API를 공부하고, 셰이더를 작성한다.
결국 그래픽은 보이기 위해 존재하며, 보여주기 위해 존재한다.