매일을 여행처럼

임베디드에는 가상 메모리가 없나?

onebrotravel — Sat, 30 May 2026 15:47:23 +0900

지난번에 STM32F103C8T6 칩으로 고추건조기를 만든 임베디드 프로젝트를 진행했다. STM32F103C8T6 칩은 Cortex-M3 코어에 Flash 64KB, SRAM 20KB짜리 칩이다. 그때 프로젝트를 진행하면서 가졌던 의문이 하나 있었다. "얘는 가상 메모리가 없는 것 같은데?"

데스크톱에서 돌아가는 프로그램은 가상 주소 공간 위에서 동작한다. 프로세스마다 같은 가상 주소가 서로 다른 물리 주소로 매핑되고, 그 변환을 하드웨어가 처리한다. 그런데 이 칩의 펌웨어에서는 그런 변환 계층이 보이지 않았다. 데이터시트의 메모리 맵에 적힌 주소가 코드에서 쓰는 주소와 그대로 같았다.

찾아보니 이 칩에 가상 메모리가 없는 것은 맞았다. 다만 "임베디드에는 가상 메모리가 없다"로 일반화하면 틀린다는 것도 알게 됐다. 같은 ARM 계열 안에서도 가상 메모리를 완전히 갖춘 칩이 있고, 의도적으로 빼버린 칩이 있다. 이 글은 그 경계가 어디서 갈리는지, 그리고 STM32F103이 그 안에서 어디에 위치하는지를 정리한다.

MMU와 MPU는 다른 장치다

가상 메모리를 이야기할 때 먼저 구분해야 할 두 하드웨어 블록이 있다.

MMU(Memory Management Unit)는 가상 주소를 물리 주소로 변환하는 장치다. 페이지 테이블을 참조해 가상 주소 공간을 물리 메모리에 매핑하고, 그 과정에서 페이지 단위 접근 권한도 함께 검사한다. 가상 메모리 시리즈 2편과 3편에서 다룬 페이지 테이블, TLB, 페이지 폴트가 모두 이 MMU를 전제로 한 메커니즘이다.

MPU(Memory Protection Unit)는 이름이 비슷하지만 하는 일이 다르다. MPU는 주소 변환을 하지 않는다. 미리 정의된 메모리 영역(region)별로 접근 권한과 속성만 설정한다. 예를 들어 특정 영역을 읽기 전용으로 지정하거나, 지정한 영역을 벗어난 접근에 폴트를 내도록 설정하는 식이다. 주소는 변환되지 않고 그대로 쓰이며, 위반이 발생하면 폴트를 일으킨다.

한 문장 요약

MMU는 "주소를 바꾸고 보호한다", MPU는 "주소는 그대로 두고 보호만 한다". 가상 메모리는 주소 변환에서 출발하므로 MPU만으로는 가상 메모리가 성립하지 않는다.

같은 ARM이라도 갈린다 — Cortex 프로파일

ARM Cortex는 단일 제품군이 아니라 세 개의 아키텍처 프로파일로 나뉜다. 마케팅 분류가 아니라 ARM Architecture Reference Manual에 규정된 서로 다른 아키텍처이며, 명령어 집합·예외 모델·메모리 모델이 각각 다르다.

Cortex-A (Application): MMU를 갖추고 완전한 가상 메모리를 지원한다. 리눅스, 안드로이드, Windows on Arm 같은 풀 기능 OS를 돌리기 위한 프로파일이다. 스마트폰의 메인 CPU, 라즈베리파이, 차량 인포테인먼트가 여기에 속한다.
Cortex-R (Real-Time): 실시간 처리용 프로파일. MMU 대신 MPU를 쓴다. 자동차·산업 제어처럼 마감 시한을 놓치면 실패로 간주되는 영역을 겨냥한다.
Cortex-M (Microcontroller): 저전력 마이크로컨트롤러용. MMU가 없다. 일부 모델(M7, M33, M55 등)에 MPU 옵션이 있을 뿐이다.

STM32F103은 이 중 Cortex-M 코어, 그중에서도 M3를 쓴다.

"임베디드"라는 단어 안의 두 부류

여기서 "임베디드에는 가상 메모리가 없다"는 일반화가 왜 틀리는지가 드러난다. 임베디드라는 단어는 성격이 다른 두 부류를 한데 묶는다.

한쪽은 MCU(Microcontroller Unit)다. STM32, ATmega, ESP32, RP2040이 여기 속한다. MMU가 없고, OS 없이 또는 RTOS(Real-Time Operating System) 위에서 펌웨어가 직접 돈다.

다른 한쪽은 AP/SoC(Application Processor / System on Chip)다. 라즈베리파이의 Cortex-A 코어, 안드로이드 기기, 차량 인포테인먼트 시스템이 여기 속한다. MMU를 완전히 갖추고 리눅스나 안드로이드 같은 OS 위에서 여러 프로세스를 돌린다.

둘 다 "임베디드"로 불리지만 가상 메모리 유무는 정반대다. 그래서 기준은 칩의 크기나 용도가 아니라 하나의 질문으로 좁혀진다 — OS 위에서 여러 프로세스를 격리해 돌릴 것인가. ARM의 칩 선택 가이드도 같은 기준을 제시한다. 리눅스·안드로이드처럼 MMU와 가상 메모리가 필요한 OS를 요구하면 Cortex-A를 쓰라는 것이다.

MCU가 가상 메모리를 안 쓰는 이유

MCU에 가상 메모리가 없는 것을 "메모리가 작아서"로만 설명하는 경우가 많지만, 메모리 크기는 결과적 이유에 가깝다. 더 근본적인 이유가 셋 더 있다.

하드웨어 비용

MMU는 추가 게이트와 전력을 요구하는 블록이다. 페이지 테이블 워크 로직, TLB, 권한 검사 회로가 모두 실리콘 면적과 소비 전력으로 이어진다. 수십 센트 단가에 마이크로암페어급 소비 전력을 다투는 MCU 시장에서 이 비용은 그대로 부담이 된다.

결정론(determinism)

이것이 실시간 시스템에서 가장 중요한 이유다. 가상 메모리는 본질적으로 지연을 예측 불가능하게 만든다. 페이지 폴트가 발생하면 폴트가 난 프로세스는 디스크에서 페이지를 읽어 올 때까지 블록되고, 그동안 다른 프로세스가 CPU를 쓴다. 문제는 그 비용의 크기다. 메모리와 디스크의 속도 차는 대략 10⁴~10⁵배에 이르고, 데스크톱에서는 이런 지연이 가끔 생겨도 전체 성능에 묻혀 티가 나지 않는다. 하지만 응답 시간이 마이크로초 단위로 정해진 실시간 제어에서는 폴트 한 번이 곧 데드라인 위반으로 이어진다. 페이지 폴트의 블록 동작과 메모리·디스크 속도 차는 가상 메모리 시리즈 3편에서 다뤘다.

결정론과 가상 메모리

실시간 시스템에서 "평균이 빠른 것"보다 "최악이 예측 가능한 것"이 중요하다. 가상 메모리는 평균을 개선하는 대신 최악 지연의 예측 가능성을 떨어뜨린다. 그래서 실시간 영역에서는 의도적으로 배제된다.

메모리 모델의 단순성

MCU는 단일 물리 주소 공간을 그대로 쓴다. Flash, SRAM, 그리고 주변장치 레지스터가 모두 하나의 주소 공간에 배치된다. 주변장치를 메모리처럼 주소로 접근하는 이 방식을 MMIO(Memory-Mapped I/O)라 한다. 주소 변환 계층이 없으니 포인터 주소가 곧 물리 주소이고, 데이터시트의 메모리 맵이 그대로 코드의 주소가 된다. 펌웨어 입장에서는 이 단순함이 오히려 장점이다.

여기서 짚어둘 점이 있다. MMU를 갖춘 코어에서 단순히 MMU를 끄는 것은 MCU의 단순함을 얻는 방법이 못 된다. MMU를 갖춘 코어에서 단순히 MMU를 끈다고 MCU처럼 단순해지는 것은 아니다. ARM 아키텍처에서 캐시 가능성(cacheability) 같은 메모리 속성은 페이지 테이블 안에 기록되기 때문에, MMU를 끄면 그 속성도 함께 사라진다. Armv8-A에서는 MMU가 꺼지면 모든 접근이 Device 메모리로 취급되어 캐시가 동작하지 않는다. MMU가 없는 단순함과 MMU를 끈 상태는 같지 않다 — MCU는 애초에 MMU 없이 설계되어 이 문제 자체가 없다.

메모리 크기

위 세 가지의 결과로, MCU는 애초에 페이지 단위로 관리할 만큼 큰 메모리를 갖지 않는다. 수십 KB에서 수 MB 규모의 SRAM에 가상 메모리의 페이지 관리 오버헤드를 얹는 것은 이득이 없다. 그래서 메모리가 작은 것은 가상 메모리가 없는 원인이 아니다. 순서가 반대다 — 가상 메모리가 필요 없게 설계했기 때문에 메모리도 그만큼 작은 것이다.

중간 지대 — MMU 없이 보호만 하는 영역

메모리 보호 방식은 MMU 있음과 없음으로 딱 갈리는 것처럼 보이지만, 실제로는 그 사이에 보호 메커니즘만 두는 중간 지대가 있다.

Cortex-R은 자동차·산업 실시간 영역을 위한 프로파일로, MMU 없이 MPU로 영역 단위 보호를 제공한다. 주소 변환의 불확정성은 피하면서 메모리 보호는 확보하는 절충이다.

Cortex-M + MPU + RTOS 조합에서는 MPU로 RTOS 태스크 간 메모리를 격리할 수 있다. FreeRTOS나 Zephyr 같은 RTOS는 이 MPU를 활용해 사용자 스레드와 커널 스레드를 분리한다. 가상 메모리는 없지만 "태스크가 남의 메모리를 건드리면 폴트"라는 보호는 가능하다.

TrustZone은 또 다른 격리 방식이다. 여기서 주의할 점이 있는데, TrustZone은 페이지 테이블 기반이 아니다. Cortex-M의 TrustZone-M은 SAU(Security Attribution Unit) 설정으로 메모리를 secure/non-secure 영역으로 나누고, 그 상태를 버스 인터커넥트까지 전파해 하드웨어 수준에서 격리한다. 가상 메모리의 주소 변환과는 완전히 다른 메커니즘으로, 보안 격리를 별도 하드웨어로 구현한 것이다.

그렇다면 처음의 STM32F103C8T6은 이 구분에서 어디에 속하나. MPU는 Cortex-M에서도 선택적 컴포넌트라 같은 M3 코어여도 부품마다 탑재 여부가 갈린다. 그런데 이 칩의 데이터시트(STM32F103x8/xB) Features 목록에는 MPU가 없다.

즉 그 프로젝트의 칩은 MMU도 MPU도 없는, 보호 계층이 전혀 없는 단일 주소 공간이었다. 포인터 주소가 곧 물리 주소로 보였던 것은 변환 계층이 없어서였고, 잘못된 주소에 써도 막아줄 영역 보호조차 없었다는 뜻이다.

정리

"임베디드 = 가상 메모리 없음"은 틀린 일반화다. 정확한 기준은 메모리 크기도 칩 용도도 아니라 "OS 위에서 여러 프로세스를 격리해 돌릴 것인가"이다. 그 답이 예라면 MMU를 갖춘 Cortex-A로 가고, 아니라면 MMU 없는 Cortex-M으로 충분하다. STM32F103에 가상 메모리가 없던 것은 결함이 아니라, 실시간성과 단순성과 비용을 위해 의도적으로 선택된 설계였다.

가상 메모리 ④ — 페이지 교체 정책

onebrotravel — Fri, 29 May 2026 22:24:50 +0900

들어가며

3편에서 메커니즘이 완성됐다. 스왑 공간이 있고, present bit으로 페이지 부재를 표시하고, 페이지 폴트가 발생하면 OS 핸들러가 디스크에서 가져온다. 메모리가 가득 차면 기존 페이지 하나를 내보내고 새 페이지를 들인다.

남은 질문은 하나다 — 어떤 페이지를 내보내야 하는가. 이 결정이 페이지 교체 정책(page replacement policy) 이고, 이번 편의 주제다.

이 선택의 무게는 가상 메모리에서 가장 크다. 페이지가 메모리에 있으면 접근에 약 100ns, 디스크로 내려가면 약 10ms — 약 10⁵배 차이다. 잘못 내보내서 다시 폴트가 나면 그 한 번에 명령어 수십만 개를 실행할 시간을 잃는다. 정책이 좋으면 시스템은 메모리 속도로 돌고, 나쁘면 디스크 속도로 떨어진다.

3편에서 짚었듯, 가상 메모리는 캐싱이다. 메모리는 디스크의 캐시고, 정책은 "캐시에 무엇을 둘 것인가"를 결정한다. 4편 본문은 이 캐싱 관점에서 정책을 정량적으로 본다. 그러기 위해 먼저 얼마나 좋은 정책인지 측정할 도구가 필요하다.

캐싱의 정량 — AMAT

평균 메모리 접근 시간 — AMAT(Average Memory Access Time) — 은 캐싱이 얼마나 잘 동작하는지를 나타낸다.

$$AMAT = T_M + (P_{Miss} \cdot T_D)$$

$T_M$: 메모리 접근 시간 (≈ 100ns)
$T_D$: 디스크 접근 시간 (≈ 10ms)
$P_{Miss}$: 미스율 (페이지가 메모리에 없을 확률)

메모리에서 페이지를 찾으면 $T_M$만 든다. 디스크로 내려가야 하면 $T_D$가 추가로 든다 — 그것도 매번이 아니라 미스율 확률만큼. 정책의 임무는 미스율을 최소화하는 것이다.

수치 감을 잡아 보면 — $T_M = 100ns$, $T_D = 10ms$일 때:

미스율	AMAT	메모리 속도 대비
10%	약 1ms	10,000배 느림
1%	약 100μs	1,000배 느림
0.1%	약 10.1μs	100배 느림
0.01%	약 1.1μs	10배 느림
0%	100ns	동일

미스율을 한 자릿수 줄이는 것이 성능을 한 자릿수 끌어올린다. 1%가 좋아 보여도 메모리 속도 대비 1,000배 느림이다. 캐시 미스가 얼마나 비싼지가 이 표의 핵심이다.

이상적 기준 — 최적 정책

정책의 얼마나 좋은지를 평가하려면 상한선이 필요하다. 1966년 Belady가 제시한 최적 정책(OPT, Optimal) 이 그 역할을 한다.

규칙은 단순하다 — 미래에 가장 멀리 다시 쓰일 페이지를 축출한다. 직관도 단순하다. 캐시에 남은 페이지들이 제거된 페이지보다 더 빨리 필요하다는 보장이 생긴다.

수학적으로 OPT는 미스율을 최소화하는 게 증명된 알고리즘이다. 그런데 실용성은 0이다(미래를 알아야 하기 때문). 일반적인 OS는 미래의 접근 패턴을 모른다.

그럼 왜 다루는가? 다른 정책의 채점 기준이다. 80% 히트율이라는 수치는 그 자체로는 의미가 옅다 — OPT가 82%인 워크로드에서 80%면 거의 최적이고, OPT가 95%인 워크로드에서 80%면 멀었다는 뜻이다. 얼마나 떨어졌는지를 측정하기 위해 OPT를 시뮬레이션으로 돌려 비교한다.

단순 정책 — FIFO, Random

미래를 모르니 과거나 우연에 의존한다. 가장 단순한 두 정책이 FIFO와 Random이다.

FIFO(First-In, First-Out) — 큐를 두고 가장 먼저 들어온 페이지를 가장 먼저 내보낸다. 구현이 거의 무료 — 큐의 head·tail 포인터 두 개만 있으면 된다. 캐시 히트가 나도 큐 순서를 건드리지 않는다. 페이지가 언제 들어왔는지만 본다.

Random — 그냥 무작위로 고른다. 의사난수 생성기 하나면 된다. 메타데이터 0, 결정 비용 0. 운에 맡기는 정책이다.

3페이지 캐시에 접근 시퀀스 0, 1, 2, 0, 1, 3, 0, 3, 1, 2, 1을 흘려 보면 — OPT는 6 히트, FIFO는 4 히트, LRU(Least Recently Used, 다음 절에서 다룬다)도 6 히트, Random은 평균 5 히트 수준이다. 11개 접근의 작은 예제지만 정책의 결의 차이가 드러난다.

FIFO의 문제는 명확하다 — 최근에 사용된 페이지도 진입 순서만으로 축출된다. 위 예제에서 페이지 0이 직전에 사용됐는데 FIFO는 "가장 먼저 들어왔다"는 이유로 0을 내보낸다. 직후에 다시 0이 필요해지므로 미스. 시간적 지역성을 전혀 활용하지 않는 정책의 대가다.

Belady의 이상 현상

FIFO에는 또 하나의 결함이 있다. 1969년 Belady가 발견한 사실 — 캐시 크기를 늘렸는데 미스율이 오히려 증가하는 워크로드가 존재한다. 더 큰 캐시는 더 많은 페이지를 담으니 미스가 줄어야 한다는 직관에 정면으로 반한다.

이 이상 현상은 정책이 스택 속성을 만족하지 않을 때 생긴다. 스택 속성이란 "크기 N+1 캐시의 내용이 항상 크기 N 캐시의 내용을 포함한다"는 성질이다. LRU와 OPT는 이 속성을 만족하고, FIFO와 Random은 위반한다. 즉 FIFO에서는 캐시가 커져도 *완전히 다른 페이지 집합*이 들어 있을 수 있고, 그래서 캐시 크기와 성능이 반드시 비례하지 않는다.

실용적 함의 — 메모리를 늘렸는데 성능이 떨어진다는 의외의 보고는 정책의 스택 속성 위반에서 올 수 있다. 그래서 현대 시스템의 페이지 교체 정책은 거의 스택 속성을 만족하는 LRU 계열을 쓴다.

Random은 의외로 평균적으로 FIFO보다 나쁘지 않다 — 운이 좋으면 OPT와 같고, 운이 나빠도 FIFO 같은 결정적으로 잘못된 패턴에 빠지지는 않는다. 10,000번 시뮬레이션을 돌리면 약 40%의 실행에서 OPT와 동일한 성능에 도달한다는 결과도 있다. 다만 예측 불가능하다는 게 운영 시스템에서는 단점이 된다 — 같은 입력에 같은 성능을 보장하지 못한다.

히스토리로 미래를 추측한다 — LRU

미래를 모르면 과거가 다음으로 좋은 정보다. 그리고 과거에서 미래를 추측할 수 있는 근거가 — 지역성(locality) 이다.

지역성은 1970년 Denning이 정리한 관찰로, 프로그램이 최근에 접근한 페이지나 그 주변 페이지를 곧 다시 접근하는 경향을 가리킨다. 루프, 자주 호출되는 함수, 핫한 데이터 구조 — 모두 같은 페이지에 반복 접근하는 패턴이다. 지역성은 보장되는 법칙이 아니지만 경향으로는 강력해, 거의 모든 정책의 토대다.

지역성을 이용하는 가장 직관적인 정책이 LRU다 — 가장 오래 안 쓴 페이지를 축출한다. 최근에 안 쓴 페이지는 앞으로도 안 쓸 가능성이 높다는 가정이다.

각 페이지마다 마지막으로 접근한 시각을 기록해 두고, 축출이 필요하면 그 값이 가장 오래된 페이지를 고른다. 캐시 히트가 나도 — FIFO와 달리 — 그 페이지의 시각을 갱신한다. 즉 자주 쓰이는 페이지는 계속 최신화되어 축출 대상에서 멀어진다.

위의 11개 접근 예제에서 LRU는 6 히트로 OPT와 동일하다. 우연이 아니다. 그 시퀀스에는 지역성이 충분히 있어서, 과거 정보만으로도 최적의 결정이 가능했다. 대부분의 실제 워크로드도 비슷한 결을 띤다.

LRU 계열에는 LFU(Least Frequently Used) — 가장 적게 쓴 페이지 축출 — 도 있다. 빈도를 본다는 점에서 LRU와 결이 다른데, 둘 다 지역성을 양의 방향으로 활용한다. 반대로 MRU·MFU 같은 정책도 정의는 가능하지만 — 가장 최근에 쓴 페이지나 가장 자주 쓴 페이지를 축출 — 지역성에 반하므로 일반 상황에선 비효율적이다.

워크로드가 정책을 결정한다

LRU가 항상 OPT에 근접하느냐 하면 그렇지는 않다. 워크로드에 따라 정책의 성능이 극단적으로 갈린다.

세 가지 워크로드를 보면 그림이 분명해진다.

워크로드 1 — 지역성이 없을 때: 100개의 페이지를 완전히 무작위로 10,000번 접근하는 패턴. 결과는 단순하다 — 모든 정책이 같은 성능. 지역성이 없으니 과거 정보가 의미가 없고, 정책이 무엇이든 캐시 크기에만 비례해 히트율이 올라간다. 캐시가 100페이지가 되면 모든 정책이 100% 히트율. 지역성이 없으면 정책을 정교화해도 소득이 없다.

워크로드 2 — 80-20 패턴: 페이지의 20%(핫 페이지)에 접근의 80%가 몰리고, 나머지 80%(콜드 페이지)에 20%가 흩어지는 워크로드. 파레토 법칙의 컴퓨터 버전이고 실제 애플리케이션에서 매우 흔하다. 여기서 LRU가 빛난다 — 핫 페이지가 자주 접근되니 LRU의 최근 사용 추적이 그것을 자동으로 잡아낸다. FIFO·Random은 진입 순서나 운에 따라 핫 페이지도 그대로 내보내, 의미 있게 떨어진다.

워크로드 3 — 루핑 순차 접근: 페이지 0, 1, ..., 49를 순서대로 접근한 뒤 다시 0부터 반복하는 패턴. 데이터베이스의 테이블 스캔이나 큰 배열의 반복 처리 같은 데서 흔하다. 이 워크로드에서 — 캐시 크기가 49페이지라고 가정하면 — LRU와 FIFO의 히트율이 0%다. 캐시에 페이지 0~48이 들어 있는 상태에서 페이지 49가 필요해지면, LRU는 "가장 오래 안 쓴" 페이지 0을 축출한다. 그러나 다음 루프에서 페이지 0이 가장 먼저 필요하다. 매번 정확히 다음에 필요한 페이지를 내보내는 — 최악의 패턴이다.

이 워크로드에서는 Random이 상대적으로 낫다. 운이 좋으면 다음에 필요한 페이지를 보존할 수도 있어 0%는 면한다. 일반적으로 단순한 정책에 밀리는 Random이 이런 코너 케이스에서는 이긴다 — 편향이 없다는 게 그래서 강점이 되기도 한다.

이 셋이 시사하는 바는 분명하다 — 만능 정책은 없다. 지역성이 없으면 캐시 크기만 의미 있고, 지역성이 있으면 LRU 계열이 우월하며, 특정 코너 케이스에서는 단순 정책이 외려 낫다. 그래서 현대 시스템은 LRU를 기본으로 두되 루핑 시퀀스 같은 패턴에 대한 방어를 함께 갖는다 — 뒤에서 다룰 ARC 등이 그런 방향의 진화다.

LRU의 구현 비용과 Clock 근사

LRU는 원리가 깔끔한데 구현이 깔끔하지 않다. 모든 메모리 접근마다 — 즉 명령어 인출, 데이터 읽기, 데이터 쓰기 각각에 대해 — 해당 페이지의 최근 접근 시각을 갱신해야 한다. 4GB 메모리에 4KB 페이지면 페이지가 약 100만 개고, 그 중 어느 페이지가 가장 오래됐는지를 빠르게 찾는 자료구조도 필요하다.

하드웨어 지원을 받아도 부담은 크다. 각 페이지에 타임스탬프 필드를 두고 접근마다 갱신하는 방식이 가능하지만, 축출 결정 시 100만 개의 타임스탬프를 다 살피는 일은 현실적이지 않다. 완벽한 LRU는 비용 대비 가치가 떨어진다.

그래서 실제 시스템은 LRU를 근사한다. 가장 널리 쓰는 근사가 Clock 알고리즘이다. 1969년 Corbato가 제안했고, 거의 LRU만큼의 성능을 훨씬 적은 비용에 낸다.

핵심 부품은 두 가지다.

reference bit(또는 use bit): 페이지마다 한 비트. 페이지에 접근하면 하드웨어가 자동으로 1로 설정한다. OS는 이 비트를 0으로 지우는 일만 한다.
clock hand: 페이지들을 원형 리스트로 두고, 그 위를 도는 포인터. 축출 결정 시 현재 위치에서 시작해 한 칸씩 전진하며 reference bit를 검사한다.

알고리즘은 단순하다. 축출이 필요하면 clock hand가 가리키는 페이지의 reference bit를 본다.

1이면 — "최근에 쓴 페이지다" — 축출하지 않고 0으로 지운 뒤 다음 페이지로 hand를 이동.
0이면 — "최근에 안 쓴 페이지다" — 그 페이지를 축출.

지나가면서 0으로 지운 페이지가 다시 hand에 도달했을 때 여전히 0이면 (그동안 안 쓰였다는 뜻) 축출 대상이 된다. 결과적으로 최근에 안 쓰인 페이지가 우선 축출되는 — LRU와 거의 같은 결정이다. 다만 정확히 가장 오래된 페이지가 아니라 그 근처의 페이지를 고른다는 점이 다르다.

비용은 비교가 안 된다. 모든 접근에 대해 시각 갱신이 아니라 비트 한 개 설정만 — 그것도 하드웨어가 자동으로. OS는 축출 시점에 hand를 몇 칸 전진하면 그만이다. 거의 무료 수준이고, 성능은 완벽 LRU에 매우 근접한다. 대부분의 현대 OS가 Clock 또는 그 변형을 쓴다.

더 절약하기 — Dirty 페이지 고려

Clock의 또 한 차원 개선은 축출 비용 자체의 차이에서 나온다. 페이지를 축출할 때 두 경우가 있다.

Clean 페이지 — 메모리에 적재된 뒤 수정되지 않은 페이지. 디스크의 원본과 동일하므로 그냥 메모리에서 지우면 끝. 추가 I/O 0.
Dirty 페이지 — 메모리에서 수정된 페이지. 디스크에 다시 써야(write-back) 데이터를 잃지 않는다. 추가 디스크 I/O 발생.

같은 최근에 안 쓴 페이지 두 개 중에서 — 하나는 clean이고 하나는 dirty라면 — clean을 축출하는 게 훨씬 싸다. 한 번의 디스크 쓰기를 절약한다.

이걸 지원하려면 또 한 비트가 필요하다 — dirty bit(또는 modified bit). 페이지에 쓰기가 일어나면 하드웨어가 자동으로 1로 설정한다. 읽기만 일어났으면 0 그대로.

Clock 알고리즘의 스캔 순서가 두 단계로 확장된다.

1순위 스캔 — reference bit = 0 그리고 dirty bit = 0인 페이지. 최근에 안 쓴 clean 페이지. 가장 싼 축출.
2순위 스캔 — reference bit = 0 그리고 dirty bit = 1인 페이지. 최근에 안 쓴 dirty 페이지. 1순위가 없을 때만 선택.

같은 결정을 내리는 데 비트 한 개를 더 추가해서 디스크 I/O를 한 번 절약한 셈이다. 가상 메모리 시스템 전체가 이런 작은 비트와 큰 절약의 교환들로 채워져 있다는 점이 이번 시리즈가 반복해서 보여주는 패턴이다.

시야 확장 — VM의 다른 정책들

페이지 교체가 가장 중요한 정책이지만 유일한 건 아니다. VM 서브시스템에는 다른 결정들이 함께 작동한다.

페이지 선택 정책 — 언제 가져올 것인가

지금까지 다룬 흐름 — 접근이 일어났을 때 비로소 페이지를 디스크에서 가져오는 — 이 demand paging이다. 1970년 Denning이 이름 붙였고 대부분의 OS가 채택한 기본 방식이다. 실제 필요한 페이지만 메모리에 두니 효율적이다.

그러나 OS가 미래의 접근을 합리적으로 추측할 수 있는 경우엔 미리 가져올 수도 있다. 이게 prefetching이다. 가장 흔한 사례 — 코드 페이지 P가 적재되면 P+1도 함께 가져온다. 순차적 코드 실행이라는 공간적 지역성에 베팅한 것이다.

prefetching은 맞으면 절약이고 틀리면 낭비다. 예측이 맞으면 폴트 한 번을 면하지만, 틀리면 안 쓸 페이지를 위해 메모리와 I/O를 썼다. 그래서 성공 가능성이 합리적일 때만 한다. 무작정 예측해 가져오는 prefetching은 시스템 전체를 느리게 만들 수 있다.

페이지 쓰기 정책 — 어떻게 내보낼 것인가

축출되는 dirty 페이지를 한 번에 하나씩 디스크에 쓰면 비효율적이다. 디스크는 작은 쓰기 여러 번보다 큰 쓰기 한 번이 훨씬 빠르니까 — 탐색·회전 오버헤드가 한 번에 분산된다.

그래서 OS는 dirty 페이지들을 모았다가 한 번에 쓴다 — clustering 또는 grouping. 3편의 페이지 데몬 섹션에서 이미 본 그 최적화다. 4편 관점에서 보면 이게 쓰기 정책의 한 형태 — 축출 정책이 무엇을 내보낼지를 정한다면, 쓰기 정책은 어떻게 모아 내보낼지를 정한다.

스래싱과 그 대응

워크로드의 총 작업 집합(working set) — 활발히 쓰이는 페이지들의 합 — 이 물리 메모리 크기를 초과하면 시스템은 곤란해진다. 폴트가 끊임없이 발생하고, 막 들여온 페이지가 다음 순간 또 축출된다. 새 페이지를 들이느라 옛 페이지를 내보내고, 그 옛 페이지가 다시 필요해지고 — 정책이 무엇이든 무한 사이클이다. 이 상태를 스래싱(thrashing) 이라 한다. CPU의 대부분이 유용한 작업이 아니라 페이지 교체에 쓰인다.

전통적 대응은 admission control — 프로세스의 일부를 의도적으로 중단해서 활성 working set을 메모리에 맞게 줄인다. "전부를 잘못하느니 일부만 잘하자"는 철학. 짧게 줄어들고 짧게 회복되는 자연스러운 사이클이 가능해진다.

리눅스의 현대적 대응은 더 거칠다 — OOM(Out-of-Memory) killer. 메모리 압박이 임계점을 넘으면 가장 메모리를 많이 쓰는 프로세스를 골라 그냥 죽인다. 단순하고 빠르지만 부작용이 명확하다. 중요한 프로세스가 종료될 위험이 있다. X 서버가 OOM 대상이 되어 모든 GUI 애플리케이션이 함께 사라지는 사고가 종종 있다. 정교한 admission control 대신 급진적 회복을 택한 트레이드오프다.

시리즈 마무리

1부는 페이징을 도착점으로 두고 세그멘테이션의 외부 단편화 문제를 해결했다. 동시에 두 문제를 남겼다. 변환의 속도가 두 배로 느려졌고, 페이지 테이블 자체의 크기가 4MB 단위로 커졌다.

2부는 그 둘을 해결했다. TLB가 캐싱으로 변환 속도를 회복했고, 멀티레벨 페이지 테이블이 트리 구조로 페이지 테이블 자체의 크기를 압축했다. 캐싱과 시간-공간 교환 — 1편에서 본 자료구조의 두 trade-off가 양쪽 다 회수됐다.

3부는 1편부터 깔려 있던 가정 하나를 풀었다 — "모든 페이지가 메모리에 있다." 스왑 공간과 present bit과 페이지 폴트 메커니즘으로, 메모리는 디스크의 캐시가 됐다. 가상 메모리가 비로소 "메모리보다 큰 메모리"라는 이름값을 한다.

4부는 그 캐시 위에서 작동하는 정책을 다뤘다. 미래를 모르는 채로 과거 정보로 어디까지 근사할 수 있는지 — OPT부터 LRU, Clock까지의 진화는 지역성이라는 단 하나의 가정 위에서 이뤄졌다. 가상 메모리는 지역성을 끝까지 짜내는 시스템이다.

자료구조의 관점에서 보면 시리즈 전체가 일관된 결을 띤다. 1편의 페이지 테이블 = 자료구조 선택의 자유, 2부의 TLB = 캐싱과 멀티레벨 = 트리, 3부의 present bit + PFN 필드 재활용, 4부의 use bit + dirty bit. 모두 작은 부품의 정교한 조합으로 큰 문제를 푼다.

가상 메모리는 모든 현대 OS가 당연한 듯이 제공하는 기능이지만, 그 안에는 50년 가까운 진화의 결과가 들어 있다. 페이징·세그멘테이션의 초기 아이디어부터 TLB·멀티레벨·페이지 폴트·Clock 근사까지, 작동하는 추상화가 어떻게 다듬어졌는지를 한 흐름으로 본 셈이다.

VirtualMemory Paging PageReplacement LRU Clock OSTEP CSAPP 정글 입문

가상 메모리 ③ — 스와핑과 페이지 폴트

onebrotravel — Fri, 29 May 2026 20:53:28 +0900

1편에서 페이징을 도착점으로 두고 두 문제를 남겼고, 2편에서 TLB(Translation Lookaside Buffer)와 멀티레벨 페이지 테이블로 그 둘을 해결했다. 변환은 빨라졌고 페이지 테이블은 작아졌다. 그러나 1편 시작부터 지금까지 깔려 있던 가정 하나가 아직 남아 있다. 바로 모든 페이지가 물리 메모리에 들어 있다는 가정이다.

이 가정은 현실에서 자주 깨진다. 4GB 메모리에서 8GB 데이터를 다루는 프로그램, 수십 개의 프로세스가 각자 수백 MB의 주소 공간을 가진 시스템, 메모리에 다 못 담는 큰 행렬을 다루는 과학 계산 — 모두 물리 메모리보다 큰 주소 공간을 요구한다. 가상 메모리 추상화는 이런 경우에도 "이 프로세스에는 충분한 메모리가 있다"는 환상을 유지해야 한다.

여기서 관점을 한 단계 끌어올리면 " 가상 메모리는 캐싱이다"라는 가상 메모리의 다른 얼굴이 드러난다. 물리 메모리는 디스크의 캐시이고, 자주 쓰는 페이지만 메모리에 두고 나머지는 디스크에 둔다. TLB가 페이지 테이블의 캐시였듯, 메모리는 디스크의 캐시다. 가상 메모리 시스템 전체가 캐시 계층 위에서 돌아간다 — 빠르고 작은 TLB, 그 아래 페이지 테이블이 있는 메모리, 그 아래 거대하고 느린 디스크.

3편는 이 캐싱이 어떻게 동작하는지의 메커니즘을 다룬다. 어떤 페이지를 내보낼지의 정책은 4편의 영역이고, 3편는 그 정책이 작동할 수 있는 토대 — 스왑 공간, present bit, 페이지 폴트 처리 — 를 본다.

스왑 공간

가장 먼저 필요한 것은 물리 메모리에 못 담은 페이지를 둘 곳이다. 디스크의 일정 영역을 페이지 단위로 예약해 두고 OS가 이를 메모리 확장용으로 쓴다. 이 영역을 스왑 공간(swap space) 이라 한다. 페이지를 메모리에서 디스크로 내보내는 것을 스왑 아웃(swap out), 디스크에서 메모리로 가져오는 것을 스왑 인(swap in) 이라 한다.

스왑 공간은 단순히 디스크의 일부지만, OS 입장에서 이 공간을 다루는 데에는 두 가지 추가 정보가 필요하다. 첫째, 각 페이지가 스왑 공간 어디에 있는지를 알아야 한다 — 디스크 주소를 페이지마다 추적해야 한다. 둘째, 스왑 공간의 크기가 시스템의 최대 가상 메모리 용량을 결정한다는 점이다. 물리 메모리 4GB에 스왑 공간 16GB면 시스템 전체가 가질 수 있는 활성 메모리 페이지의 상한이 20GB가 된다.

스왑 공간만 페이지의 디스크 소스가 되는 것은 아니다. 프로그램의 바이너리 자체도 디스크에 있는 페이지의 원본이다. ls나 직접 컴파일한 실행 파일의 코드 페이지는 처음부터 디스크의 그 바이너리 파일에 존재한다. OS는 실행 시점에 필요한 코드 페이지만 메모리로 읽어 들이고, 메모리가 부족하면 그 코드 페이지의 메모리 자리를 그냥 회수한다. 디스크의 바이너리는 그대로 있으니, 다음에 그 코드 페이지가 필요해지면 바이너리에서 다시 읽으면 된다. 읽기 전용 데이터라 디스크에 다시 쓸 필요도 없다.

present bit

스왑 공간이 있어도 OS가 어느 페이지가 지금 메모리에 있고 어느 페이지가 디스크에 있는지를 알지 못하면 의미가 없다. PTE(Page Table Entry) 에 이 정보를 적어 두기 위해 present bit 하나를 추가한다.

present = 1: 페이지가 물리 메모리에 현재 있음. PFN(Page Frame Number) 필드가 유효한 물리 프레임 번호를 담음.
present = 0: 페이지가 물리 메모리에 없음. 디스크에 있으며, PFN 필드는 디스크 주소로 재활용됨.

같은 비트 영역을 두 의미로 쓰는 건 빈 공간을 만들지 않으려는 절약이다. 페이지가 메모리에 있으면 PFN, 없으면 디스크 주소 — 어차피 둘 중 하나만 의미가 있고, present bit가 어느 쪽인지를 알려 준다.

이 비트가 변환 흐름에 미치는 영향은 명확하다. 변환 도중 MMU(Memory Management Unit, 또는 OS의 TLB miss 핸들러)가 PTE를 읽었는데 present = 0이면, 변환을 계속할 수 없다. PFN 필드에는 PFN 대신 디스크 주소가 들어 있으니, 그걸로 물리 주소를 만들 수 없다. 이 상황을 페이지 폴트(page fault) 라 한다.

"페이지 폴트"라는 이름의 부정확함

"폴트"는 보통 잘못된 일을 가리키는 말이지만, 페이지 폴트는 잘못된 접근이 아니다. 프로세스의 가상 주소 공간에 정당하게 매핑된 페이지에 정당한 방식으로 접근했는데 단지 그 페이지가 지금 메모리에 없는 상황일 뿐이다. 더 정확한 이름은 "페이지 미스(page miss)"이고, TLB miss·캐시 miss와 같은 결의 용어다.

이 용어가 굳어진 데는 하드웨어 사정이 있다. 페이지가 없는 상황도, 권한 위반 같은 진짜 오류도, 모두 같은 예외 처리 경로 — "하드웨어가 처리 못 함 → OS로 제어권 이전" — 를 거친다. 메커니즘이 같다 보니 둘 다 "폴트"로 묶어 부르게 됐고, 이제 와서 바꾸기엔 너무 굳어 버렸다.

그래서 문맥에 따라 의미가 갈린다. 넓게 쓰면 페이지 폴트는 PTE 관련 모든 예외 — 권한 위반, 유효하지 않은 주소, 페이지 부재 — 를 포함하고, 좁게 쓰면 본문에서 다루는 페이지 부재만 가리킨다. 이 글에서는 좁은 뜻으로 쓴다.

페이지 폴트는 누가 처리하는가

페이지 폴트가 발생하면 — 즉 MMU가 present = 0인 PTE를 만나면 — 하드웨어는 즉시 예외를 발생시켜 OS로 제어권을 넘긴다. OS의 페이지 폴트 핸들러가 실행되어 폴트를 서비스한다.

여기서 한 가지 짚을 점은 — 2편에서 본 하드웨어 관리 TLB냐 소프트웨어 관리 TLB냐와 무관하게, 페이지 폴트는 항상 OS가 처리한다. 하드웨어 관리 TLB가 보통의 TLB miss를 하드웨어로 직접 처리해도, 페이지 폴트만은 OS에 넘긴다. 이유는 두 가지다.

하나는 성능 균형의 문제다. 페이지 폴트의 비용은 본질적으로 디스크 I/O가 결정한다(수 ms 단위). OS 핸들러가 수 μs 더 걸리든 말든 전체 비용에 비하면 무시할 만한 수준이다. 하드웨어로 일부 시간을 줄여 봐야 의미가 없다.

다른 하나는 복잡성의 회피다. 페이지 폴트를 처리하려면 스왑 공간 관리, 디스크 I/O 발행, 페이지 교체 정책 — 모두 복잡하고 자주 바뀌는 정책들을 알아야 한다. 이런 걸 하드웨어에 박는 건 비효율적이다. 소프트웨어로 두면 OS마다 자유롭게 정책을 바꿀 수 있다.

처리 흐름

페이지 폴트 핸들러가 하는 일은 다음과 같다.

디스크 주소 확인 — 폴트가 발생한 페이지의 PTE를 읽는다. present = 0이므로 PFN 필드에는 디스크 주소가 들어 있다.
디스크 I/O 발행 — 그 디스크 주소에서 페이지를 읽어 물리 메모리로 가져오는 I/O 요청을 낸다.
블록(block) — I/O는 ms 단위로 느리므로 OS는 폴트가 난 프로세스를 블록 상태로 두고, 다른 준비된 프로세스를 CPU에 올린다. I/O가 진행되는 동안 CPU가 노는 일이 없다.
I/O 완료 — 디스크에서 페이지가 메모리에 적재되면, OS가 PTE를 갱신한다. present를 1로, PFN 필드에는 페이지가 들어간 새 물리 프레임 번호를 적는다.
재시도 — 블록되어 있던 프로세스를 깨운다. 원래 폴트가 났던 명령어를 다시 실행한다. 이번에는 PTE의 present = 1이고 PFN이 유효해, 정상적으로 변환이 끝난다.

이 멀티 프로그래밍(한 프로세스의 I/O 동안 다른 프로세스가 CPU를 쓰는)은 OS의 핵심 효율 기법이다. I/O 비용이 클수록 이 중첩의 가치가 커진다.

메모리가 가득 차면

지금까지의 설명은 "디스크에서 페이지를 읽어 들일 자리(빈 프레임)가 있다"는 또 하나의 가정 위에 서 있었다. 현실에서는 메모리가 거의 늘 차 있다. 새 페이지를 읽어 오려면 먼저 기존 페이지 하나를 내보내 자리를 만들어야 한다 — 페이지 교체(page replacement) 다.

어떤 페이지를 내보낼지는 페이지 교체 정책이 결정한다. 이 선택이 좋으면 시스템은 메모리 속도에 가깝게 돈다. 나쁘면 — 즉 곧 다시 필요한 페이지를 자꾸 내보내면 — 프로그램이 디스크 속도로 떨어진다. 메모리와 디스크의 속도 차이가 약 10⁴~10⁵배 수준이라, 잘못된 정책의 비용은 다른 어떤 최적화 이슈보다 크다.

3편은 정책 자체에는 들어가지 않는다(4편의 주제). 여기서 짚을 점은 정책이 작동할 자리를 메커니즘이 마련한다는 사실이다. 폴트 핸들러의 흐름에 단계 하나가 끼어든다.

수정된 흐름은 다음과 같다.

PTE 검사 — 1부의 정상 흐름. 페이지가 valid·present면 그대로 변환.
페이지 폴트 분기 — valid = 1이지만 present = 0이면 폴트 핸들러로.
유효하지 않은 접근 분기 — valid = 0이면 OS 트랩 핸들러로 (보통 SIGSEGV(segmentation violation signal)로 프로세스 종료).
폴트 처리 (OS) — 빈 프레임이 있으면 바로 디스크 I/O. 없으면 교체 정책을 돌려 내보낼 페이지를 고른다 → 그 페이지를 디스크에 쓴다(필요하면) → 그 자리에 새 페이지를 읽어 들인다 → PTE 갱신 → 명령어 재시도.

세 가지 분기가 같은 하드웨어 예외 메커니즘을 공유한다. 하드웨어는 그냥 "처리 못 함, OS가 결정하라"고 넘기고, OS가 PTE 비트들을 보고 어떤 종류의 폴트인지 가린다.

실제 시스템 — 메모리가 차기 전에 움직인다

위 흐름은 정확하지만 너무 늦다. 메모리가 완전히 찰 때까지 기다렸다가 폴트가 났을 때 교체를 시작하면, 폴트 처리 시간이 두 배가 된다 — 새 페이지를 읽기 전에 기존 페이지를 디스크에 쓰는 시간이 추가되니까. 그래서 실제 시스템은 능동적으로 동작한다.

OS는 두 개의 임계점을 둔다 — 낮은 워터마크(LW) 와 높은 워터마크(HW). 여유 페이지 수가 LW 아래로 떨어지면 백그라운드의 페이지 데몬(또는 스왑 데몬)이 깨어나 페이지를 축출하기 시작하고, HW까지 여유 페이지가 회복되면 다시 잠든다. 사용자 프로세스는 페이지 폴트 시 이미 마련된 빈 프레임을 즉시 받을 수 있어 폴트 비용이 줄어든다.

이 능동적 관리에는 부가 이점이 더 있다. 페이지 데몬은 여러 페이지를 클러스터링해 한 번에 디스크에 쓸 수 있다. 디스크는 작은 쓰기 여러 번보다 큰 쓰기 한 번이 훨씬 빠르다 — 탐색·회전 오버헤드가 분산되니까. 그래서 같은 양의 데이터를 내보내도 데몬이 일괄로 내보내는 게 폴트마다 한 페이지씩 내보내는 것보다 효율적이다.

수정된 폴트 흐름은 단순해진다. 폴트가 나면 OS는 직접 교체를 수행하지 않는다. 여유 페이지가 있으면 그걸 쓰고, 없으면 데몬에게 신호를 보내 깨운 뒤 자기는 잠시 잠들고, 데몬이 여유를 만들어 깨워 주면 재개한다. 교체의 시점과 폴트 처리의 시점이 분리된다.

정리

3편은 가상 메모리가 물리 메모리보다 큰 주소 공간을 다루기 위한 메커니즘을 깔았다. 핵심 부품은 네 개다.

스왑 공간 — 메모리에 못 담은 페이지를 보관할 디스크 영역.
present bit — PTE 한 비트로 "이 페이지가 지금 메모리에 있는지"를 표시. 없으면 PFN 필드는 디스크 주소로 재활용.
페이지 폴트 처리 — present = 0을 만난 변환은 OS의 핸들러로 넘어가 디스크에서 페이지를 가져온다. 그동안 프로세스는 블록, 다른 프로세스가 CPU를 쓴다.
백그라운드 페이지 데몬 — 폴트가 날 때가 아니라 나기 전에 미리 빈 프레임을 마련해 둔다. 워터마크와 클러스터링으로 효율을 끌어올린다.

이 메커니즘 덕분에 메모리 = 디스크의 캐시라는 캐시 계층이 비로소 작동한다. 자주 쓰는 페이지는 메모리에, 나머지는 디스크에. 페이지 폴트는 캐시 miss와 같은 성격의 사건이다.

하지만 이 메커니즘이 작동하려면 한 가지 결정이 남아 있다. 어떤 페이지를 메모리에 두고 어떤 페이지를 내보낼 것인가. 잘못된 선택의 비용이 10⁴~10⁵배라는 사실이 이 결정의 무게를 보여 준다.

다음으로

4편은 이 선택을 다룬다. 미래를 안다면 최적은 무엇인지(Belady의 OPT), 미래를 모르는 채로 어디까지 근사할 수 있는지(FIFO, Random, LRU), 그리고 실제 시스템이 LRU를 어떻게 흉내 내는지(Clock 알고리즘). 같은 지역성이라는 가정 위에서, 이번엔 자료구조가 아니라 시간을 보는 휴리스틱이다.

가상 메모리 ② — TLB와 멀티레벨 페이지 테이블

onebrotravel — Fri, 29 May 2026 19:06:51 +0900

1편은 페이징을 도착점으로 두고 끝맺었지만, 그 끝에서 두 문제가 남았다. 하나는 속도다. 모든 메모리 접근마다 페이지 테이블을 한 번 더 읽어야 하니, 단순히 페이징을 켜는 것만으로 프로그램이 두 배 가까이 느려진다. 다른 하나는 크기다. 32비트 주소 공간에 4KB 페이지면 페이지 테이블 항목이 약 100만 개, 프로세스 하나당 4MB가 든다. 대부분이 빈 항목인데도 선형 배열이라 다 만들어 둬야 한다.

VPN·오프셋 비트 빠르게 구하기

오프셋 비트 = log₂(페이지 크기) — 페이지 안의 모든 바이트를 가리킬 수 있어야 하므로

VPN 비트 = 전체 주소 비트 − 오프셋 비트 — 남는 비트가 페이지 번호

예: 32비트 주소 공간 + 4KB 페이지 → 오프셋 log₂(4KB)=12비트, VPN = 32−12 = 20비트. 페이지 테이블 항목 수 = 2^(VPN 비트) = 2²⁰ ≈ 100만 개.

2부는 이 두 결함을 해결한다. 속도는 TLB(Translation Lookaside Buffer)라는 변환 캐시로, 크기는 멀티레벨 페이지 테이블(multi-level page table)이라는 자료구조 교체로. 두 해법 모두 가상 메모리만의 발명이 아니라 컴퓨터 시스템 전체에서 반복되는 원리 — "자주 쓰는 것은 캐싱하라", "쓰지 않는 것은 만들지 말라"의 적용이다.

TLB — 속도 문제

1편의 페이징은 변환 한 번에 메모리 접근 두 번을 요구했다. 가상 주소가 들어오면 먼저 페이지 테이블에서 PTE(Page Table Entry)를 읽고, 그다음 실제 데이터를 읽는다. 메모리 접근이 두 배가 되니 페이징을 켜는 순간 프로그램이 두 배 느려진다. 가상 메모리 추상화가 아무리 유용해도 이대로면 실용성이 없다.

페이지 테이블은 어디에 있나

페이지 테이블은 프로세스 자신의 주소 공간(코드·힙·스택)이 아니라 커널이 관리하는 물리 메모리에 있다. 프로세스 생성 시 OS의 메모리 관리자가 할당하고, 그 시작 위치(물리 주소)를 PTBR에 담아 둔다.

왜 가상 주소 공간 안이 아닌가 — 페이지 테이블이 프로세스의 가상 주소 공간 안에 있다면, 그것을 읽기 위해 또 다른 변환이 필요한 닭과 달걀 문제에 빠진다. 그래서 PTBR은 가상 주소가 아니라 물리 주소를 담고, MMU는 PTBR을 따라 변환 없이 페이지 테이블에 직접 접근한다.

여기서 1편 끝의 크기 결함이 정확히 무엇을 부담하는지 드러난다 — 프로세스 100개의 페이지 테이블 400MB는 사용자 프로세스 메모리가 아니라 커널 메모리를 잠식한다.

해결은 변환 결과를 캐싱하는 것이다. CPU 안에 TLB(Translation Lookaside Buffer)라는 작은 캐시를 두고, 한 번 풀어낸 VPN(Virtual Page Number)→PFN(Physical Frame Number) 매핑을 보관한다. 같은 페이지에 다시 접근하면 페이지 테이블을 거치지 않고 TLB만 보고 즉시 물리 주소를 만든다. 이름은 buffer지만 동작은 캐시다. 즉 TLB는 MMU(Memory Management Unit) 안에 자리 잡은, 주소 변환 전용 캐시이다.

변환 흐름 — hit과 miss

가상 주소가 도착하면 하드웨어는 먼저 상위 비트에서 VPN을 뽑아 TLB를 조회한다. 매치되는 항목이 있으면 TLB hit이다. 그 항목에서 PFN을 꺼내 오프셋과 결합해 물리 주소를 만들고 곧장 메모리에 접근한다. 페이지 테이블 접근은 일어나지 않는다. 접근당 메모리 1회, 페이징이 아예 없을 때와 같다.

매치가 없으면 TLB miss다. 하드웨어는 1부에서 본 절차대로 페이지 테이블을 한 번 읽어 PTE를 가져오고, 유효성과 권한을 검사한 뒤 그 변환을 TLB에 채워 넣는다. 그리고 같은 명령어를 다시 실행한다. 두 번째 실행 때는 방금 채워진 TLB가 hit를 내므로 일반 속도로 진행된다. miss 한 번의 비용은 페이지 테이블 접근 한 번이지만, 그 미스가 채운 항목 덕분에 이후 같은 페이지에 대한 접근은 모두 빠르게 처리된다.

여기서 TLB의 효과는 명백히 확률 게임이다. miss는 비싸지만, miss가 hit를 만든다. 결국 성능은 hit율이 결정한다 — hit가 충분히 많으면 페이징의 두 배 비용은 거의 사라지고, hit율이 낮으면 TLB가 있어도 두 배 가까이 느려진다.

지역성이 TLB를 살린다

hit율이 높을 수 있는 이유는 프로그램의 지역성(locality) 때문이다. 짧은 시간에 접근하는 메모리는 좁은 영역에 몰리는 경향이 있다(공간적 지역성, spatial locality). 그리고 한 번 접근한 곳은 곧 다시 접근될 가능성이 크다(시간적 지역성, temporal locality). TLB는 작지만 이 두 지역성이 작용하는 한 hit율은 자연스럽게 올라간다.

배열 순회가 가장 단순한 예다. 10개짜리 정수 배열을 처음부터 끝까지 더한다고 하자. 페이지 크기 16바이트, 배열 시작 주소가 가상 100번지라면, 배열은 VPN 6·7·8 세 페이지에 나뉘어 들어간다(a[0]은 VPN 6의 오프셋 4, a[1]은 오프셋 8, ..., a[3]은 VPN 7의 오프셋 0...). 루프가 돌면서 TLB는 다음 패턴을 보인다.

a[0]은 VPN 6을 처음 만나니 miss. 그 miss가 TLB에 VPN 6 매핑을 채운다. 이어지는 a[1], a[2]는 같은 VPN 6이라 hit, hit. a[3]은 VPN 7로 넘어가니 또 miss, 이후 a[4]~a[6]은 hit 셋. a[7]에서 VPN 8 miss, a[8]·a[9] hit. 10번 접근에 miss 3번, hit 7번 — hit율 70%다. 처음 보는 배열인데도 공간적 지역성만으로 단번에 이 정도가 나온다.

같은 루프를 한 번 더 돌면 어떻게 될까. 이미 세 페이지의 매핑이 TLB에 있으니 10번 접근 모두 hit이다. 이번엔 시간적 지역성(방금 접근한 페이지를 곧 다시 접근)이 작동한 것이다. 실제 시스템의 페이지 크기는 4KB라 한 페이지에 정수 1024개가 들어가므로, 같은 배열의 hit율은 더 올라간다. 거의 모든 접근이 한 번의 miss 뒤에는 hit로 처리된다.

여기서 TLB의 본질이 드러난다. TLB는 모든 접근을 빠르게 만들지 않는다. 지역성 있는 접근을 빠르게 만든다. 그리고 대다수 프로그램은 (의도하지 않아도) 충분한 지역성을 갖는다. 그래서 작은 TLB(보통 64~128개 항목)만으로도 페이징의 두 배 비용이 거의 사라진다. TLB의 성공은 하드웨어 캐시 자체보다 프로그램이 본래 지역성을 갖는다는 사실에 기댄다.

미스는 누가 처리하는가

TLB miss가 나면 페이지 테이블을 읽어 변환을 가져오고 TLB에 채워야 한다. 이 작업의 주체로 두 갈래가 갈린다.

하드웨어 관리(hardware-managed) TLB는 하드웨어가 직접 페이지 테이블을 읽는다. CPU 안에 페이지 테이블 베이스 레지스터가 있고(예: x86의 CR3), miss가 나면 하드웨어가 그 레지스터를 따라 페이지 테이블을 "워킹"해 PTE를 가져온 뒤 TLB를 채우고 명령어를 재시도한다. OS는 페이지 테이블의 형식과 위치만 약속해 두면 되고, miss 처리에는 개입하지 않는다. x86 계열이 이 방식이다.

소프트웨어 관리(software-managed) TLB는 miss를 OS의 일로 떠넘긴다. TLB miss가 발생하면 하드웨어는 예외(trap)를 발생시켜 커널 모드로 전환하고, OS의 TLB miss 핸들러를 호출한다. 핸들러는 페이지 테이블에서 변환을 찾아 특별한 권한 명령어로 TLB에 써넣은 뒤 원래 명령어로 복귀한다. MIPS, SPARC v9 같은 RISC 계열이 이 방식이다.

이 트랩의 복귀는 일반 시스템 콜과 다르다. 시스템 콜은 호출 다음 명령어로 돌아가지만, TLB miss 트랩은 트랩을 발생시킨 그 명령어로 돌아가 다시 실행한다. 이번에는 TLB에 변환이 채워져 있으니 hit이 난다. 즉 명령어 입장에서는 한 번 중단되었다가 같은 자리에서 다시 시작되는 것처럼 보인다.

두 방식의 trade-off는 분명하다. 하드웨어 관리는 빠르지만 페이지 테이블 형식이 하드웨어에 박제되어 OS가 자유롭게 바꾸지 못한다. 소프트웨어 관리는 트랩 비용을 감수하는 대신 OS가 페이지 테이블 자료구조를 자유롭게 설계할 수 있다 — 해시 테이블이든 트리든. 이는 1 끝에서 본 "선형 배열 vs 다른 구조" 선택의 자유와 정확히 같은 자유다.

왜 x86은 하드웨어 관리, ARM·MIPS는 소프트웨어 관리인가 — CISC와 RISC

두 갈래는 1980년대의 명령어 집합 설계 철학 차이에서 비롯한다. CISC(Complex Instruction Set Computing)는 "복잡한 일은 하드웨어가 처리한다"는 노선이고, RISC(Reduced Instruction Set Computing)는 "하드웨어는 단순하게, 복잡한 일은 소프트웨어로"라는 노선이다. TLB 미스 처리도 이 노선을 그대로 따라간다. CISC 계열인 x86은 하드웨어가 페이지 테이블을 직접 워킹하고, RISC 계열인 MIPS·SPARC v9·ARM(일부 세대)은 OS가 트랩 핸들러로 처리한다.

현재 두 진영은 사실상 수렴했다. x86 내부는 CISC 명령어를 RISC식 마이크로 명령어로 분해해 실행하고, ARM도 세대를 거치며 하드웨어 페이지 테이블 워킹을 도입했다. 그럼에도 시장 분포는 남았다 — 데스크톱·서버는 x86(CISC 계보), 모바일·임베디드는 ARM(RISC 계보). 임베디드에서 ARM이 우세한 이유 중 하나도 RISC의 단순한 하드웨어가 전력·면적 면에서 유리하기 때문이다.

TLB 항목 안에는 무엇이 들어가는가

TLB의 한 항목은 단순히 VPN과 PFN의 쌍이 아니다. 변환을 안전하고 정확히 수행하기 위한 메타데이터가 함께 들어간다.

기본은 검색 키인 VPN과 결과인 PFN이다. 여기에 유효 비트(valid bit)가 붙어 그 항목이 실제 변환을 담고 있는지를 표시한다. 부팅 직후나 TLB를 비울 때 모든 항목은 유효 비트 0이 된다. 보호 비트(protection bits)는 페이지에 대한 읽기·쓰기·실행 권한을 담아, 변환과 동시에 권한 검사가 이뤄지게 한다. 권한 위반이면 TLB가 hit이어도 예외가 발생한다.

여기에 컨텍스트 스위치를 다루기 위한 ASID(Address Space Identifier)가 추가되곤 한다. 이게 왜 필요한지가 다음 섹션의 주제다. TLB는 완전 연관(fully associative) 캐시로 구현되는 게 보통이라, 검색 시 모든 항목과 동시에 병렬 비교가 이뤄진다. 항목 수가 32~128개로 제한된 이유(병렬 비교 회로의 비용과 전력 때문)도 여기서 나온다.

컨텍스트 스위치 — 누구의 변환인가

TLB의 한 항목은 "VPN 10번은 PFN 100번"이라고 적혀 있다. 그런데 이 매핑은 어떤 프로세스의 VPN 10번인가? 각 프로세스는 독립된 가상 주소 공간을 가지므로, 프로세스 P1의 VPN 10번과 P2의 VPN 10번은 완전히 다른 물리 페이지로 가야 한다.

P1이 실행 중 TLB에 (VPN 10 → PFN 100)을 채웠다고 하자. 컨텍스트 스위치가 일어나 P2가 실행되면서 VPN 10번을 접근한다. 이때 TLB는 hit를 내며 P1의 매핑(PFN 100)을 돌려준다 — P2 입장에서는 완전히 잘못된 물리 페이지다. 메모리 보호가 깨진다.

이 문제의 가장 단순한 해법은 컨텍스트 스위치마다 TLB를 flush(비우기) 하는 것이다. 모든 항목의 유효 비트를 0으로 설정해 무효화한다. 안전하지만 비용이 크다. 새 프로세스는 TLB가 텅 빈 상태로 시작하니 한동안 miss가 폭주한다(콜드 스타트).

더 나은 방법은 ASID를 도입하는 것이다. TLB의 각 항목에 그 변환이 속한 프로세스의 ASID를 함께 적어 둔다. PID와 비슷한 식별자지만 TLB 내 구분만 필요하므로 보통 8비트(256개)면 충분하다. CPU에는 "현재 실행 중 프로세스의 ASID"를 담는 레지스터가 있고, 컨텍스트 스위치 때 OS가 이 값을 새 프로세스의 ASID로 갱신한다. TLB는 그 자체로 비우지 않는다. 조회 시 VPN과 ASID가 둘 다 일치해야 hit이 되므로, P1의 항목이 남아 있어도 P2가 잘못 가져갈 일이 없다. 나중에 P1이 다시 스케줄되면 그때 남아 있던 항목들이 그대로 hit를 만들어 콜드 스타트 비용도 줄어든다.

TLB가 해결한 문제, 남은 문제

TLB는 1편의 속도 문제를 해결한다. hit율이 높으면 페이징의 두 배 비용이 사라지고, 프로그램은 가상 메모리가 없는 듯이 동작한다. 그래서 OSTEP의 표현대로, TLB는 가상 메모리를 실용적으로 만든 기술이다.

그렇지만 TLB가 모든 걸 해결하진 않는다. 프로그램이 짧은 시간에 접근하는 페이지 수가 TLB가 담을 수 있는 항목 수를 초과하면 — 이를 TLB 커버리지 초과라 한다 — miss율이 급증한다. 64개 항목 × 4KB = 256KB. 워킹 셋이 이를 넘는 워크로드(대규모 데이터베이스, 포인터 체이싱이 많은 자료구조 순회 등)는 여전히 TLB miss로 느려진다. 이 한계는 큰 페이지 지원으로 일부 완화할 수 있지만, 본질적인 해결은 알고리즘과 자료구조를 TLB 친화적으로 설계하는 쪽에 있다.

그리고 1편의 또 다른 문제, 크기 문제는 여전히 그대로다. 프로세스당 4MB의 선형 페이지 테이블이라는 부담은 TLB가 줄여주지 않는다 — TLB는 변환을 빠르게 할 뿐, 페이지 테이블 자체를 작게 만들지는 못한다.

멀티레벨 페이지 테이블 — 크기 문제

크기 결함을 다시 짚자. 32비트 주소 공간에 4KB 페이지면 VPN 20비트, 항목 약 100만 개, 프로세스당 4MB. 프로세스 100개가 돌면 커널 메모리에서 400MB가 페이지 테이블만으로 사라진다. 그런데 이 항목 대부분은 무효다 — 코드·힙·스택 사이의 거대한 빈 공간이 모두 항목을 할당받는다. 실제로 쓰는 페이지 수는 수십에서 수백 개에 불과한데, 100만 개를 다 가지고 있는 셈이다.

여기서 문제는 변환 자체가 아니라 자료구조 선택이다. 1편 끝에서 선형 배열을 골랐기 때문에, 안 쓰는 자리도 다 가지고 있어야 한다는 제약이 생긴 거다. 다른 자료구조를 택하면 빈 자리는 만들지 않을 수 있다. 단, 그 선택에는 대가가 따른다.

단순한 시도 — 페이지를 더 크게

가장 단순한 발상은 페이지 크기 자체를 키우는 것이다. 페이지가 커지면 같은 주소 공간에서 페이지 개수가 줄고, 항목 수도 같이 줄어든다. 32비트 주소 공간에 페이지를 4KB에서 16KB로 키우면 오프셋이 12비트에서 14비트로 늘고, VPN은 20비트에서 18비트로 줄어든다. 항목 수는 100만에서 26만으로, 페이지 테이블 크기는 4MB에서 1MB로 — 정확히 4분의 1이다. 페이지 크기를 2ⁿ배 키우면 페이지 테이블도 2ⁿ분의 1이 된다.

그런데 이 단순한 해법은 내부 단편화(internal fragmentation)를 발생시킨다. 1편에서 본 외부 단편화가 "할당 단위 사이"의 낭비라면, 내부 단편화는 "할당 단위 안의 낭비다. 페이지 단위로만 메모리를 할당할 수 있으므로, 어떤 영역이 5KB만 필요해도 16KB 페이지 통째로 할당해야 한다. 이 경우 11KB가 낭비된다. 큰 페이지를 많이 쓸수록 이런 낭비가 누적되어 시스템 전체 메모리 효율이 떨어진다.

그래서 대부분의 시스템은 페이지를 작게 유지한다 — x86은 4KB, SPARC v9는 8KB. 큰 페이지는 일부 시스템에서 선택적으로 지원되지만(2MB, 1GB 등), 이는 페이지 테이블 절약보다는 TLB 커버리지 확대(앞 섹션의 TLB 한계 회피)가 주목적이다. 페이지 크기 키우기만으로 크기 결함을 푸는 건 부족하다.

큰 페이지의 진짜 용도 — TLB 커버리지

TLB 한 항목이 한 페이지를 덮으므로, "TLB가 동시에 덮을 수 있는 총 메모리"는 항목 수 × 페이지 크기로 정해진다. 이걸 TLB 커버리지(TLB coverage)라 한다. 64항목 × 4KB = 256KB, 64항목 × 2MB = 128MB.

워킹 셋이 TLB 커버리지를 넘으면 miss가 급증한다(앞 절의 "TLB 커버리지 초과"). 데이터베이스·가상화처럼 워킹 셋이 큰 워크로드에서 huge page(2MB)나 giant page(1GB)를 켜는 이유가 이거다 — 같은 64항목으로 더 넓은 범위를 덮어 miss를 줄인다.

그래서 큰 페이지의 주목적은 페이지 테이블 절약이 아니라 TLB miss 회피다. 페이지 테이블이 작아지는 건 부수 효과이고, 큰 페이지를 시스템 전체에 적용하면 내부 단편화가 따라오므로 기본 페이지 크기는 여전히 4~8KB로 둔다. 크기 결함의 본 해법은 다른 데에 있다.

하이브리드 — 페이징과 세그멘테이션 결합

다음 시도는 1편에서 본 세그멘테이션을 페이징과 결합하는 것이다. 페이지 테이블이 큰 이유가 "주소 공간 전체를 하나의 선형 배열로 다루기 때문"이라면, 주소 공간을 코드·힙·스택 세그먼트로 나누고 각 세그먼트마다 별도의 페이지 테이블을 가지면 어떨까. 세그먼트 사이의 거대한 빈 공간은 어느 페이지 테이블에도 속하지 않으니, 그 공간만큼의 항목을 만들 필요가 없어진다.

가상 주소를 [세그먼트 번호 | VPN | 오프셋]으로 쪼갠다. 상위 2비트로 코드(01)·힙(10)·스택(11) 중 어디인지를 가린다. MMU는 세그먼트 번호로 해당 세그먼트의 페이지 테이블 베이스 레지스터를 고른 뒤, VPN을 인덱스로 그 페이지 테이블에서 PTE를 가져온다. 세그멘테이션의 베이스+바운드 메커니즘이 그대로 살아 있어 바운드 검사로 잘못된 접근을 막을 수도 있다.

이 방식은 메모리를 어느 정도 절약한다. 힙과 스택 사이의 빈 영역은 더 이상 페이지 테이블 항목을 만들지 않으니까. 그러나 두 한계가 따라온다.

첫째, 세그멘테이션의 유연성 한계가 그대로 상속된다. 코드·힙·스택이라는 미리 정해진 영역 구분을 전제로 하므로, 힙 안에서의 희소 사용 — 예를 들어 큰 희소 자료구조 — 에는 여전히 무력하다. 힙 세그먼트의 페이지 테이블은 그 세그먼트의 가장 높은 사용 페이지까지 모든 항목을 가져야 하니까.

둘째, 더 큰 문제는 외부 단편화의 재발이다. 세그먼트별 페이지 테이블은 그 세그먼트가 실제 쓰는 페이지 수에 따라 크기가 제각각이다. 작은 코드 세그먼트의 페이지 테이블, 큰 힙 세그먼트의 페이지 테이블, 중간 크기의 스택 세그먼트의 페이지 테이블 — 모두 다른 크기로 커널 메모리에 들어앉는다. 1부에서 외부 단편화를 없애려 페이지라는 균일한 단위를 도입했는데, 페이지 테이블 자체를 임의 크기로 두면 그 단편화가 다시 살아난다. OS가 페이지 테이블용 연속 공간을 찾기가 다시 어려워진다.

세그멘테이션과 페이징의 결합은 직관적이지만, 두 방식의 단점도 같이 가져온다. 더 근본적인 해법이 필요하다.

페이지 테이블 자체를 페이지로 쪼개기

근본적인 발상의 전환은 이거다 — 페이지 테이블 자체도 페이지로 쪼개 놓고, 모든 항목이 무효인 페이지는 아예 만들지 않는다. 코드·힙·스택 같은 미리 정해진 세그먼트 구분에 의존하지 않고, 빈 영역이 어디에 있든 그곳의 페이지 테이블 페이지는 생략할 수 있다.

문제는 그러면 페이지 테이블 페이지들이 띄엄띄엄 흩어져 존재하게 된다는 점이다. VPN으로 곧장 인덱싱하던 선형 구조가 깨진다. 어느 VPN이 어느 페이지 테이블 페이지에 있는지를 알려줄 추가 자료구조가 필요하다. 그게 페이지 디렉토리(page directory) 다.

페이지 디렉토리는 페이지 테이블 페이지들의 인덱스다. 각 항목 — PDE(Page Directory Entry) — 는 유효 비트 하나와 PFN 하나를 담는다. 유효 비트는 그 PDE가 가리키는 페이지 테이블 페이지 안에 유효한 PTE가 하나라도 있는지를 표시한다. 무효 PDE라면 그 페이지 테이블 페이지는 존재하지 않는다. 항목만 비어 있는 게 아니라 메모리에 만들지조차 않은 것이다. PFN은 그 페이지 테이블 페이지가 어느 물리 프레임에 있는지를 가리킨다.

VPN은 이제 두 부분으로 쪼개진다. 상위 비트는 페이지 디렉토리의 인덱스, 하위 비트는 그 PDE가 가리키는 페이지 테이블 페이지 안에서의 PTE 인덱스가 된다.

변환은 두 단계가 된다. 가상 주소가 들어오면 먼저 VPN의 상위 비트로 페이지 디렉토리에서 PDE를 꺼낸다. PDE가 유효하면 그 PFN으로 페이지 테이블 페이지의 위치를 알아내고, VPN의 하위 비트로 그 안에서 PTE를 꺼낸다. PTE에서 데이터 페이지의 PFN을 얻어 오프셋과 결합하면 최종 물리 주소다. 무효 PDE를 만나면 그 영역은 아예 매핑되지 않은 거니까 예외가 발생한다 — 페이지 테이블 페이지를 만들 필요조차 없었던 영역이다.

선형 페이지 테이블과 비교하면 효과가 분명하다. 16KB 주소 공간에 64바이트 페이지면 256개 PTE가 필요한데, 이를 페이지당 16개 PTE로 쪼개면 16개의 페이지 테이블 페이지가 된다. 코드 한 페이지, 힙 한 페이지, 스택 두 페이지만 실제로 쓴다면, 유효한 PTE를 담은 페이지 테이블 페이지는 단 두 개뿐이다. 페이지 디렉토리 하나(16개 PDE) + 페이지 테이블 페이지 둘 = 총 세 페이지. 선형으로 16페이지 다 만드는 것과 비교해 거의 5분의 1이다. 실제 32비트 시스템에서는 이 비율이 훨씬 극적이다. 4MB의 선형 페이지 테이블이 희소 주소 공간에서는 보통 수십 KB 수준으로 줄어든다.

대가 — 시간과 공간의 교환

멀티레벨 페이지 테이블의 절약은 공짜가 아니다. 선형 페이지 테이블에서 TLB miss 한 번이 메모리 접근 한 번을 의미했다면(PTE 한 번), 멀티레벨에서는 두 번이 된다 — PDE 한 번, PTE 한 번. TLB hit에는 영향이 없지만, miss 비용은 정확히 두 배가 된다. 자료구조 깊이가 한 단계 더 들어간 만큼 변환 경로도 한 단계 더 길어진 셈이다.

이 trade-off는 시간-공간 트레이드오프(time-space tradeoff) 의 전형이다. 1편 끝에 깔아둔 자료구조 관점의 두 번째 trade-off가 여기서 실물로 드러난다. 공간을 절약하려면 시간을 더 쓰고, 시간을 절약하려면 공간을 더 쓴다. 선형 배열은 시간($O(1)$ 조회)에 최적화한 선택이었고, 멀티레벨은 공간을 위해 시간을 한 단계 양보한 선택이다.

이 양보가 받아들여지는 이유는 다시 지역성에 있다. TLB hit율이 충분히 높으면 miss 자체가 드물고, miss 비용이 두 배여도 평균 변환 비용은 거의 그대로다. TLB가 깔려 있다는 전제 위에서만 멀티레벨이 실용적이다.

더 깊은 계층

위 예시는 두 단계 — 페이지 디렉토리 + 페이지 테이블 — 였지만, 주소 공간이 커지면 페이지 디렉토리 자체도 한 페이지에 안 들어갈 수 있다. 그러면 페이지 디렉토리도 페이지로 쪼개고, 그 위에 또 한 단계의 인덱스를 둔다. 3단, 4단으로 계층이 늘어난다.

64비트 주소 공간에서는 이 깊이가 4단 이상이 거의 필수다. 64비트 주소 공간이 VPN을 50비트 이상 요구하는데, 그걸 선형 배열로 둔다는 건 — 항목 수가 2⁵⁰ ≈ 천조 — 비현실적이다. 멀티레벨이 없으면 64비트 시스템 자체가 성립하지 않는다.

실제 시스템 — Intel Core i7의 4단 페이지 테이블

Intel Core i7은 64비트 CPU지만 가상 주소를 48비트만 쓴다. 64비트(2⁶⁴ ≈ 16 엑사바이트) 주소 공간 전체를 지원하는 건 현재 워크로드에 과하고, 페이지 테이블 비용도 폭증하기 때문이다. 48비트로 충분히 256TB를 가리키니 당분간 부족할 일은 없다.

이 48비트 가상 주소를 4단으로 쪼갠다. 오프셋이 12비트(4KB 페이지), 나머지 36비트를 9비트씩 네 조각으로 잘라 각각의 페이지 테이블 인덱스로 쓴다. 위에서부터 차례로 PML4(Page Map Level 4) · PDPT(Page Directory Pointer Table) · PD(Page Directory) · PT(Page Table) 이다. 한 페이지 안에 항목이 2⁹ = 512개 들어가고(64비트 항목 = 8바이트 × 512 = 4KB), 그 512항목 중 어디로 갈지를 9비트로 인덱싱한다. 정확히 한 페이지에 떨어지게 설계된 거다.

변환 시작점은 CR3 레지스터다. CR3는 그 프로세스의 PML4가 어느 물리 프레임에 있는지를 담는다(1편의 PTBR이 이걸 일반화한 이름이다). 컨텍스트 스위치 때 OS가 CR3를 새 프로세스의 PML4 주소로 바꾼다. 변환은 CR3에서 출발해 PML4 → PDPT → PD → PT를 차례로 타고 내려가, 마지막 PT에서 데이터 페이지의 PFN을 얻는다. 그 PFN과 12비트 오프셋을 결합하면 최종 물리 주소다.

이 구조의 함의는 두 가지다. 하나는 공간 절약이다. 주소 공간 중 안 쓰는 영역은 그 영역에 해당하는 PML4/PDPT/PD 항목이 무효이고, 그 아래 페이지 테이블 페이지들은 만들지조차 않는다. 64비트 공간 256TB가 워킹 셋 수MB뿐인 프로세스에서도, 페이지 테이블 자체는 수십 KB 수준으로 끝난다.

다른 하나는 변환 비용이다. TLB miss가 나면 4번의 메모리 접근이 필요하다 — PML4 항목, PDPT 항목, PD 항목, PT 항목. 1편의 선형 페이지 테이블이 한 번, 앞 섹션의 2단 멀티레벨이 두 번이었던 것과 비교하면 두 배 더 늘었다. 그래서 64비트 시스템에서 TLB는 더 중요해진다 — hit율이 떨어지면 변환 비용이 5배(=1+4)로 뛰니까. 실제로 i7은 TLB를 데이터·명령어용 L1, 통합 L2로 계층화해 hit율을 끌어올린다. TLB가 덜 미스 나게 만드는 데 더 많은 하드웨어가 들어간다.

정리

TLB는 변환 결과를 작은 캐시에 보관해 페이징의 두 배 비용을 거의 사라지게 했고, 멀티레벨 페이지 테이블은 안 쓰는 영역의 항목을 만들지 않는 방식으로 페이지 테이블 자체를 수십 KB 수준으로 줄였다. 이 둘이 결합되어야 페이징이 비로소 실용적이다 — TLB만 있으면 페이지 테이블이 여전히 4MB씩이라 메모리가 모자라고, 멀티레벨만 있으면 4단 변환 비용 때문에 TLB miss가 너무 비싸진다. 그래서 모든 현대 시스템은 둘을 함께 쓴다.

자료구조 관점에서 2편은 1편 끝에서 깔아둔 트레이드오프를 양쪽 다 회수했다. 첫째, 캐싱. TLB는 작고 빠른 저장공간으로 큰 자료구조 접근을 가속하는 전형이고, 지역성이라는 프로그램의 본성이 그 캐싱을 살린다. 둘째, 시간-공간 트레이드오프. 선형 페이지 테이블이 시간($O(1)$)을 위해 공간을 쓴 선택이었다면, 멀티레벨은 공간을 위해 시간($O(d)$, $d$=깊이)을 양보한 선택이다. 둘 다 같은 trade-off의 양극단에서 골라낸 것이지, 어느 한쪽이 절대적으로 우월한 게 아니다.

그리고 페이지 테이블이 데이터 구조라는 관점도 살아 있다. 1편에서 본 "선형 배열 vs 트리 vs 해시"라는 자료구조 선택의 자유는 멀티레벨에서 트리 구조를, 그리고 (본문에선 깊이 다루지 않았지만) 역 페이지 테이블에서 해시 구조를 선택할 수 있게 해주는 토대였다. OS는 하드웨어가 허용하는 한 그 자유를 쓴다.

다음으로

지금까지의 가정은 "프로세스의 모든 페이지가 물리 메모리에 들어 있다"였다. 그래서 페이지 테이블 항목이 valid이면 곧장 PFN으로 변환된다고 봤다. 그러나 현실에서는 물리 메모리보다 큰 주소 공간을 다뤄야 한다 — 4GB 시스템에서 8GB 프로그램을 돌리거나, 100개 프로세스가 각자 수십 MB씩 쓰는 상황. 모든 페이지를 메모리에 둘 수 없다.

3부의 주제는 이 가정의 해결한다. 일부 페이지는 디스크에 두고(스왑), 필요할 때만 메모리로 불러온다. 페이지 테이블 항목에 present bit을 추가해 "이 페이지가 지금 메모리에 있는지"를 표시하고, 없으면 페이지 폴트(page fault) 가 발생해 OS가 디스크에서 가져온다. 그 과정에서 어느 페이지를 메모리에서 내보낼지를 정하는 페이지 교체 정책 — LRU, clock 알고리즘, 워킹 셋 — 이 등장한다. 가상 메모리가 "메모리보다 큰 메모리"라는 이름값을 비로소 하는 단계다.

VirtualMemory Paging TLB MultiLevel CacheLocality ASID OSTEP CSAPP

가상 메모리 ① — 주소 공간에서 페이징까지

onebrotravel — Fri, 29 May 2026 02:16:40 +0900

프로세스는 자신이 0번지부터 시작하는 연속된 메모리를 독차지한다고 믿는다. 실제로는 물리 메모리의 어딘가에, 다른 프로세스들과 섞여, 흩어진 채로 올라가 있다. 이 간극을 메우는 운영체제의 기법이 메모리 가상화(memory virtualization)이고, 그 결과 프로세스에게 주어지는 추상화가 가상 메모리(virtual memory)다.

앞 글들에서 프로세스는 자신만의 주소 공간(address space)을 가진다고 했고, CPU 스케줄링에서는 그 프로세스를 언제 실행할지를 다뤘다. 이 글은 그 주소 공간이 실제 물리 메모리 위에 어떻게 올라가는가를 다룬다. 가상 메모리는 한 편에 담기에는 큰 주제라, 이 글(①)에서는 주소 공간이라는 추상화에서 출발해 베이스/바운드, 세그멘테이션을 거쳐 페이징에 도달하기까지를 따라간다. TLB·멀티레벨 페이지 테이블·스와핑은 다음 글(②)로 넘긴다.

왜 메모리를 가상화하는가

초기 컴퓨터는 메모리에 관한 추상화가 거의 없었다. 물리 메모리에 운영체제 루틴 한 덩어리와 실행 중인 프로그램 하나가 올라가는 것이 전부였다. 프로그램은 물리 주소를 직접 보고 다뤘다.

기계가 비싸지면서 한 대를 여러 프로그램이 나눠 쓰는 멀티프로그래밍(multiprogramming)과 시분할(time-sharing)이 등장했다. 여러 프로세스를 메모리에 동시에 올려 두고 전환하며 실행하니 CPU 활용도가 크게 올랐다. 그런데 여러 프로그램이 한 메모리에 공존하게 되자 새로운 문제가 생겼다. 한 프로세스가 다른 프로세스의 메모리를 읽거나 덮어쓸 수 있다는 것, 즉 보호(protection)의 문제다.

이 문제를 풀기 위해 운영체제는 물리 메모리를 그대로 노출하는 대신 다루기 쉬운 추상화를 제공한다. 그것이 주소 공간이다. 주소 공간은 실행 중인 프로그램이 보는 메모리 전체이며, 세 부분으로 이뤄진다. 명령어가 담기는 코드, 함수 호출과 지역 변수가 쌓이는 스택, 그리고 동적 할당에 쓰이는 힙이다. 관례적으로 코드는 맨 아래에 고정되고, 힙과 스택은 주소 공간의 양 끝에서 서로 마주 보며 자란다. 힙은 위로, 스택은 아래로 자라며 가운데 빈 공간을 사이에 둔다.

프로그램은 이 주소 공간이 0번지부터 시작한다고 가정하고 작성된다. 하지만 실제로 물리 메모리의 0번지에 올라가는 것은 아니다. 운영체제는 프로세스를 물리 메모리의 임의 위치에 배치하고, 프로세스가 그 사실을 모르게 한다. 프로세스가 사용하는 주소를 가상 주소(virtual address), 그것이 가리키는 실제 위치를 물리 주소(physical address)라 한다.

Virtual address / Physical address

그렇다면 프로세스가 내는 가상 주소를 실제 물리 주소로 바꾸는 일이 매번 필요하다. 이 변환은 CPU 안의 전용 하드웨어인 MMU(Memory Management Unit)가 메모리 접근이 일어날 때마다 실시간으로 수행한다. CPU가 가상 주소를 내면 MMU가 이를 물리 주소로 바꿔 메모리에 전달한다. 프로그램은 이 과정을 전혀 의식하지 않는다.

MMU

가상 메모리가 갖춰야 할 목표는 셋이다. 첫째는 투명성(transparency)으로, 프로세스가 메모리가 가상화되었다는 사실을 알아차리지 못해야 한다. 둘째는 효율성(efficiency)으로, 변환이 프로그램을 크게 느리게 하거나 너무 많은 메모리를 잡아먹지 않아야 한다. 셋째는 보호로, 한 프로세스가 다른 프로세스나 운영체제의 메모리에 영향을 줄 수 없어야 한다. 아래에서 보는 기법들은 이 세 목표를 어떻게 달성하는지, 그리고 어디서 부족한지를 차례로 드러낸다.

베이스와 바운드 — 첫 번째 기법

가장 단순한 변환 방법은 주소 공간을 물리 메모리의 한 자리에 통째로 올리고, 시작 위치만큼 더해 주는 것이다. 1950년대 후반 시분할 시스템에서 도입된 베이스와 바운드(base and bounds), 또는 동적 재배치(dynamic relocation)다.

CPU에 레지스터 두 개를 둔다. 베이스 레지스터는 주소 공간이 올라간 물리 메모리의 시작 위치를 담고, 바운드 레지스터는 주소 공간의 크기를 담는다. 변환은 덧셈 하나로 끝난다.

물리 주소 = 가상 주소 + 베이스

프로그램은 0번지부터 시작한다고 가정하고 작성·컴파일된다. 운영체제가 프로세스를 물리 메모리의 어디에 올릴지 정해 베이스 레지스터를 설정하면, 이후 모든 메모리 참조에서 하드웨어가 자동으로 베이스를 더한다. 4KB 주소 공간을 가진 프로세스를 물리 메모리 16KB 위치에 올렸다면, 가상 주소 0은 물리 주소 16KB로, 가상 주소 3000은 물리 주소 19384로 변환된다.

보호는 바운드 레지스터가 맡는다. 가상 주소가 주소 공간 크기를 벗어나거나 음수이면 하드웨어가 예외를 일으켜 운영체제로 넘기고, 운영체제는 해당 프로세스를 종료한다. 위의 예에서 가상 주소 4400은 4KB 범위를 넘으므로 오류가 된다. 베이스와 바운드 레지스터를 담은 이 하드웨어가 앞서 말한 MMU의 가장 단순한 형태다.

베이스와 바운드는 적은 하드웨어로 투명성·효율성·보호를 모두 얻는다. 하지만 한계가 있다. 주소 공간을 통째로 한 자리에 올리기 때문에, 힙과 스택 사이의 쓰지 않는 빈 공간까지 물리 메모리에 자리를 차지한다. 이렇게 할당된 영역 안쪽에서 낭비되는 공간을 내부 단편화(internal fragmentation)라 한다.

세그멘테이션 — 일반화된 베이스/바운드

내부 단편화는 주소 공간을 하나의 덩어리로 다룬 데서 비롯된다. 주소 공간을 코드·힙·스택이라는 논리적 단위로 나누고, 각 단위마다 베이스와 바운드 쌍을 따로 두는 기법이 세그멘테이션(segmentation)이다. 베이스/바운드를 한 쌍에서 여러 쌍으로 일반화한 것이다.

각 세그먼트를 물리 메모리의 서로 다른 위치에 독립적으로 배치하고, 실제로 쓰는 세그먼트만 메모리에 올린다. 힙과 스택 사이의 빈 공간은 더 이상 물리 메모리를 차지하지 않는다. 빈 곳이 많은 큰 주소 공간, 즉 희소 주소 공간(sparse address space)을 효율적으로 담을 수 있게 된다.

Segmentation

변환에는 "이 가상 주소가 어느 세그먼트에 속하는가"를 먼저 가려내는 단계가 필요하다. 한 가지 방법은 가상 주소의 상위 비트를 세그먼트 번호로 쓰는 것이다. 세그먼트가 셋이면 상위 2비트로 구분한다. 나머지 하위 비트는 세그먼트 안에서의 오프셋이 된다. 하드웨어는 상위 비트로 세그먼트를 정하고, 오프셋이 그 세그먼트의 바운드를 넘지 않는지 검사한 뒤, 해당 세그먼트의 베이스를 더해 물리 주소를 만든다.

스택은 다른 세그먼트와 성장 방향이 반대라 변환에 한 가지 손질이 더 필요하다. 코드와 힙은 낮은 주소에서 높은 주소로 자라지만, 스택은 높은 주소에서 낮은 주소로 자란다. 그래서 세그먼트가 어느 방향으로 자라는지를 나타내는 비트를 하드웨어에 추가하고, 스택의 오프셋은 음수로 계산한다.

예를 들어 최대 세그먼트 크기가 4KB이고 스택 베이스가 물리 28KB일 때, 가상 주소 15KB를 변환해 보자. 상위 2비트로 스택 세그먼트임을 가려내면 하위 비트가 가리키는 오프셋은 3KB다. 스택은 역방향이므로 이 오프셋을 그대로 쓰지 않고, 최대 크기(주소로 표현 가능한 4KB)에서 뺀 값을 음수 오프셋으로 삼는다. 즉 3KB − 4KB = −1KB다. 여기에 베이스를 더하면 28KB + (−1KB) = 27KB가 최종 물리 주소가 된다. 바운드 검사도 절댓값으로 한다. 이 접근의 음수 오프셋 크기 1KB가 스택에 실제 할당된 크기 2KB 안에 들어오므로 정상이다.

세그멘테이션은 코드 공유라는 이점도 준다. 코드 세그먼트는 보통 읽기 전용이라 여러 프로세스가 같은 물리 코드 세그먼트를 공유해도 안전하다. 이를 위해 각 세그먼트에 읽기·쓰기·실행 권한을 나타내는 보호 비트(protection bit)를 두고, 하드웨어가 변환 때 권한까지 함께 검사한다. 같은 프로그램을 여러 번 실행해도 코드 사본을 하나만 메모리에 두면 되니 메모리가 절약된다.

세그멘테이션은 내부 단편화를 크게 줄였지만 새로운 결함을 안고 있다. 세그먼트마다 크기가 다르기 때문에, 프로세스가 생기고 사라지기를 반복하면 물리 메모리 곳곳에 크고 작은 빈틈이 흩어진다. 전체 빈 공간을 합치면 충분한데도 연속된 자리가 없어 새 세그먼트를 못 올리는 상황이 생긴다. 이렇게 할당된 영역 바깥에 쓸 수 없는 빈틈이 흩어지는 것을 외부 단편화(external fragmentation)라 한다. 가변 크기로 메모리를 나누는 한 외부 단편화는 따라붙는다.

페이징 — 고정 크기로 문제를 피하다

외부 단편화는 세그먼트의 크기가 제각각이라는 데서 나온다. 그렇다면 메모리를 가변 크기로 나누지 않으면 된다. 페이징(paging)은 주소 공간을 모두 같은 크기의 조각으로 자른다. 가상 주소 공간을 자른 고정 크기 조각을 페이지(page), 물리 메모리를 같은 크기로 자른 조각을 프레임(frame)이라 한다. 모든 조각의 크기가 같으니 어떤 페이지든 어떤 빈 프레임에나 들어갈 수 있고, 외부 단편화는 원천적으로 사라진다.

작은 예로 64바이트 가상 주소 공간을 16바이트 페이지 4개로, 128바이트 물리 메모리를 16바이트 프레임 8개로 나눈 경우를 보자. 가상 페이지들은 물리 메모리의 빈 프레임 아무 데나 흩어져 올라간다. 어느 가상 페이지가 어느 물리 프레임에 들어갔는지는 프로세스마다 따로 관리하는 자료구조인 페이지 테이블(page table)에 기록한다. 페이지 테이블은 가상 페이지 번호(VPN, Virtual Page Number)를 물리 프레임 번호(PFN, Physical Frame Number)로 매핑한다.

가상 주소는 두 부분으로 나뉜다. 윗부분은 어느 페이지인지를 가리키는 VPN, 아랫부분은 그 페이지 안에서의 위치를 가리키는 오프셋이다. 변환은 VPN을 페이지 테이블에서 찾아 PFN으로 바꾸고, 오프셋은 그대로 붙이는 식으로 이뤄진다. 페이지 안에서의 상대 위치는 가상이든 물리든 같으므로 오프셋은 변환되지 않는다.

위 예에서 movl 21, %eax가 가상 주소 21에 접근한다고 하자. 21을 6비트 이진수로 쓰면 010101이다. 64바이트 공간에 16바이트 페이지이므로 상위 2비트가 VPN, 하위 4비트가 오프셋이다. VPN은 01 즉 1, 오프셋은 0101 즉 5다. 페이지 테이블에서 가상 페이지 1이 물리 프레임 7에 매핑돼 있다면, PFN 7(111)에 오프셋 5(0101)를 붙여 물리 주소 1110101, 즉 117을 얻는다.

페이지 테이블의 각 항목(PTE, Page Table Entry)에는 PFN 외에도 여러 비트가 들어간다. 유효 비트(valid bit)는 그 매핑이 유효한지를 나타낸다. 코드·힙·스택 사이의 쓰지 않는 페이지들을 무효로 표시해 두면 물리 프레임을 할당할 필요가 없어, 희소 주소 공간을 메모리 낭비 없이 지원할 수 있다. 보호 비트는 읽기·쓰기·실행 권한을, 현재 비트(present bit)는 페이지가 물리 메모리에 있는지 아니면 디스크로 밀려났는지를 나타낸다. 더티 비트(dirty bit)는 페이지가 수정됐는지를, 참조 비트(reference bit)는 최근 접근됐는지를 기록한다. 뒤의 두 비트는 다음 글에서 다룰 페이지 교체에서 쓰인다.

페이징은 외부 단편화를 없애고 희소 주소 공간을 깔끔히 지원하지만, 그 대가로 두 가지 새로운 문제를 안고 온다.

하나는 크기다. 페이지 테이블은 가상 페이지마다 항목을 하나씩 가진다. 32비트 주소 공간에 4KB 페이지라면 VPN이 20비트이므로 항목이 약 100만 개, 한 항목이 4바이트라면 프로세스 하나당 페이지 테이블이 4MB에 이른다. 프로세스 100개가 돌면 오직 주소 변환을 위해서만 400MB가 든다.

VPN·오프셋 비트 빠르게 구하기

오프셋 비트 = log₂(페이지 크기) — 페이지 안의 모든 바이트를 가리킬 수 있어야 하므로

VPN 비트 = 전체 주소 비트 − 오프셋 비트 — 남는 비트가 페이지 번호

예: 32비트 주소 공간 + 4KB 페이지 → 오프셋 log₂(4KB)=12비트, VPN = 32−12 = 20비트. 페이지 테이블 항목 수 = 2^(VPN 비트) = 2²⁰ ≈ 100만 개.

다른 하나는 속도다. 페이지 테이블이 메모리에 있으므로, 모든 메모리 접근마다 페이지 테이블을 한 번 읽어 변환 정보를 가져온 뒤 실제 데이터를 읽어야 한다. 메모리 접근이 두 배가 되어, 페이징은 프로그램을 두 배가량 느리게 만들 수 있다.

이 두 문제 — 페이지 테이블이 너무 크고, 변환이 너무 느린 것 — 를 푸는 것이 다음 글의 주제다. 속도는 변환 결과를 캐시하는 TLB로, 크기는 페이지 테이블 자체를 계층화하는 멀티레벨 페이지 테이블로 다룬다.

정리

메모리 가상화의 발전은 한 기법의 결함이 다음 기법의 출발점이 되는 사슬이었다. 베이스와 바운드는 적은 하드웨어로 재배치와 보호를 얻었지만 주소 공간을 통째로 올려 내부 단편화를 남겼다. 세그멘테이션은 주소 공간을 논리 단위로 쪼개 내부 단편화를 줄였지만 가변 크기 탓에 외부 단편화를 낳았다. 페이징은 고정 크기 조각으로 외부 단편화를 없앴지만 페이지 테이블의 크기와 변환 속도라는 새 문제를 들여왔다.

다음 글에서는 이 두 문제를 푸는 TLB와 멀티레벨 페이지 테이블, 그리고 물리 메모리보다 큰 주소 공간을 가능케 하는 스와핑까지 다룬다. 페이징을 작동하게 만드는 데서 나아가 잘 작동하게 만드는 단계다.

CPU 스케줄링

onebrotravel — Thu, 28 May 2026 23:35:23 +0900

CPU 스케줄링은 준비 큐(ready queue)에 있는 여러 프로세스 가운데 누구에게 CPU를 줄지, 얼마 동안 줄지를 결정하는 운영체제의 정책(policy)이다. 실행을 기다리는 프로세스는 여럿이고 CPU는 한정돼 있으므로, 그 선택을 맡은 구성 요소가 필요하다. 이것이 CPU 스케줄러다.

이전 글에서 컨텍스트 스위치(context switch)를 다뤘다. 실행 중인 프로세스를 멈추고 다른 프로세스로 갈아타는 메커니즘, 즉 방법은 거기서 정리됐다. 스케줄링은 그 메커니즘을 언제, 누구에게 쓸지를 정하는 위층의 문제다. 프로세스의 상태 전환을 누가 어떤 기준으로 결정하는가 — 그 기준을 정의한 것이 스케줄링 정책이다.

정책을 비교하려면 잣대가 필요하다. 이 글에서 쓰는 지표는 둘이다.

응답시간 vs 반환시간

반환시간(turnaround time): 작업이 도착한 순간부터 끝나는 순간까지의 시간이다. T_반환 = T_완료 − T_도착. 작업을 얼마나 빨리 완료시키는가를 본다.
응답시간(response time): 작업이 도착한 순간부터 처음 실행되는 순간까지의 시간이다. T_응답 = T_첫실행 − T_도착. 반응이 얼마나 빠른가를 본다.

두 지표는 종종 충돌한다. 한 정책이 반환시간을 줄이면 응답시간을 잃고, 그 반대도 마찬가지인 경우가 많다. 아래에서 다루는 정책들은 앞선 정책의 약점을 보완하며 발전해 왔다.

FIFO — 가장 단순한 출발점

FIFO

가장 기본적인 정책은 도착한 순서대로 처리하는 것이다. 먼저 온 작업이 먼저 실행되고, 끝날 때까지 CPU를 점유한다. 선입선출(First In, First Out)이라 FIFO, 먼저 온 순서대로 서비스한다는 뜻에서 FCFS(First Come, First Served)라고도 한다.

FIFO는 단순하고 구현이 쉽다. 작업들의 길이가 비슷할 때는 성능도 나쁘지 않다. 세 작업 A·B·C가 거의 동시에 도착해 각각 10초씩 걸린다면, A는 10초, B는 20초, C는 30초에 끝나 평균 반환시간은 (10+20+30)/3 = 20초가 된다.

문제는 작업 길이가 제각각일 때 나타난다. A가 100초, B와 C가 각각 10초이고 이 순서로 도착하면, A가 100초 동안 CPU를 점유한 뒤에야 B와 C가 실행된다. 평균 반환시간은 (100+110+120)/3 = 110초로 크게 늘어난다.

짧은 작업들이 긴 작업 하나 뒤에 줄지어 막히는 이 현상을 호위 효과(convoy effect)라 부른다. 자원을 잠깐만 쓰면 되는 작업들이 자원을 오래 쥔 작업 뒤에 묶여 한꺼번에 대기하게 되는 상황이다.

SJF — 짧은 작업 먼저

호위 효과는 긴 작업이 짧은 작업 앞에 놓이는 데서 생긴다. 짧은 작업을 먼저 실행하는 정책이 최단 작업 우선(Shortest Job First), SJF다.

앞의 예시 — A=100초, B·C=10초, 거의 동시 도착 — 에 SJF를 적용하면 B, C, A 순으로 실행된다. B는 10초, C는 20초, A는 120초에 끝나 평균 반환시간은 (10+20+120)/3 = 50초다. 110초에서 50초로 줄었다.

모든 작업이 동시에 도착한다는 가정 아래에서 SJF는 평균 반환시간을 최소화하는 최적 정책임이 증명돼 있다. 짧은 작업을 앞으로 당길 때 줄어드는 대기 시간이, 뒤로 밀린 긴 작업이 더 기다리는 시간보다 항상 크기 때문이다.

SJF에는 두 가지 한계가 있다.

첫째는 작업 길이를 미리 알아야 한다는 점이다. SJF는 가장 짧은 작업을 골라야 하는데, 실제 운영체제는 작업이 얼마나 걸릴지 대개 알지 못한다. 이 가정은 스케줄러가 미래를 내다본다고 전제하는 것과 같다.

둘째는 늦게 도착한 짧은 작업이 여전히 막힌다는 점이다. SJF는 한번 시작한 작업을 끝까지 실행하는 비선점(non-preemptive) 정책이다. A가 0초에 도착해 100초를 실행하기 시작한 뒤 10초 시점에 B와 C가 도착하면, 짧은 B·C가 도착했더라도 실행 중인 A를 멈출 수단이 없어 둘은 A가 끝나기를 기다린다. 이 경우 평균 반환시간은 다시 103.33초로 나빠진다. 호위 효과가 재현되는 셈이다.

STCF — 선점을 더하다

STCF

SJF의 둘째 한계는 실행 중인 작업을 멈출 수 없다는 데서 비롯된다. 앞 글에서 본 타이머 인터럽트와 컨텍스트 스위치가 그 멈춤을 가능하게 하는 도구다.

SJF에 선점(preemption)을 더한 정책이 최단 잔여시간 우선(Shortest Time-to-Completion First), STCF다. 선점형 SJF라고도 한다. 새 작업이 도착할 때마다 스케줄러는 남아 있는 작업들과 새 작업의 잔여 시간을 비교해, 가장 적게 남은 작업을 실행한다.

앞의 늦은 도착 시나리오에 STCF를 적용하면, A가 100초를 실행하던 중 10초 시점에 B·C가 도착했을 때 A를 멈추고 더 짧은 B·C를 먼저 끝낸 뒤 A의 나머지를 마저 실행한다. 평균 반환시간은 다시 50초가 된다. 도착 시점이 제각각이어도 STCF는 반환시간 면에서 최적이다.

작업 길이를 알고, 작업이 CPU만 사용하며, 잣대가 반환시간뿐이라면 STCF는 충분히 좋은 정책이다. 실제로 초기 배치(batch) 컴퓨팅 환경에서는 이런 정책이 잘 맞았다.

새 지표 — 응답시간

이 전제를 바꾼 것이 시분할(time-sharing) 시스템과 대화형(interactive) 사용자의 등장이다. 사용자가 터미널 앞에 앉아 입력하고 즉각적인 반응을 기대하면서, "언제 끝나는가"만으로는 정책을 평가하기에 부족해졌다. "언제 처음 반응하는가"가 중요해졌고, 그 잣대가 앞서 정의한 응답시간이다.

STCF 계열은 응답시간에 약하다. 작업 셋이 동시에 도착하면 셋째 작업은 앞의 둘이 통째로 끝난 뒤에야 처음 실행된다. 터미널에 입력해 두고 다른 작업이 끝날 때까지 첫 반응을 기다려야 한다면 대화형 환경에는 적합하지 않다. 반환시간에 강한 정책이 응답시간에는 약하다는 점이 여기서 드러난다.

Round Robin — 번갈아 돌리기

Round Robin

라운드 로빈(Round Robin, RR)은 각 작업을 끝까지 실행하는 대신, 타임 슬라이스(time slice, 스케줄링 퀀텀이라고도 한다)만큼만 실행하고 다음 작업으로 넘어간다. 준비 큐를 한 바퀴 돌고 또 도는 방식이라 타임 슬라이싱이라고도 부른다.

세 작업 A·B·C가 동시에 도착해 각각 5초씩 걸리고 타임 슬라이스가 1초라고 하자. RR은 A·B·C·A·B·C… 순으로 잘게 번갈아 실행한다. A의 응답시간은 0, B는 1, C는 2로 평균 1초다. 같은 작업을 SJF로 실행하면 응답시간은 0, 5, 10으로 평균 5초였다. 응답시간이 크게 개선된다.

타임 슬라이스 길이가 성능을 좌우한다. 짧을수록 응답시간에는 유리하지만, 너무 짧으면 컨텍스트 스위치 비용이 전체 성능을 잠식한다. 슬라이스가 10ms이고 스위치 비용이 1ms라면 시간의 약 10%가 스위칭에 쓰인다. 슬라이스를 100ms로 늘리면 그 비율은 1% 아래로 떨어진다. 고정 비용을 더 드물게 치러 총비용을 낮추는 분할상환(amortization)이다. 슬라이스는 스위치 비용을 상쇄할 만큼 길되, 시스템이 둔해질 만큼 길지는 않은 선에서 정해진다.

컨텍스트 스위치 비용은 레지스터를 저장하고 복원하는 데서만 오는 것이 아니다. 프로그램이 실행되면서 CPU 캐시·TLB·분기 예측기에 쌓아 둔 상태가 작업을 바꾸면 씻겨 나가고, 새 작업의 상태로 다시 채워야 한다. 이 보이지 않는 비용이 적지 않다.

대신 RR은 반환시간에 약하다. 앞의 예시에서 A는 13초, B는 14초, C는 15초에 끝나 평균 반환시간은 14초로, FIFO보다도 나쁠 때가 많다. RR이 모든 작업을 잘게 늘여 실행하기 때문이다. 작업이 끝나는 시점만 보는 반환시간 입장에서는 불리할 수밖에 없다.

이는 우연이 아니라 본질적인 trade-off다. CPU를 작은 단위로 공평하게 나누는 정책은 응답시간을 얻는 대신 반환시간을 잃고, 공평함을 포기하면 반환시간을 얻는 대신 응답시간을 잃는다. 두 지표를 동시에 최적화할 수는 없다.

정리하면 두 갈래다. SJF·STCF는 반환시간에 강하고 응답시간에 약하다. RR은 응답시간에 강하고 반환시간에 약하다. 그리고 아직 풀지 않은 가정이 둘 남아 있다. 작업이 I/O를 한다는 것, 그리고 작업 길이를 모른다는 것이다.

I/O를 끼워넣기

지금까지는 작업이 CPU만 사용한다고 가정했다. 현실의 프로그램은 입력을 읽고 출력을 쓴다. 작업이 I/O를 요청하면 그동안 CPU를 사용하지 못하고 블록(blocked)된다. 디스크 I/O라면 수 밀리초 이상 멈출 수도 있다. 이때 CPU를 놀리는 것은 낭비이므로, 스케줄러는 다른 작업을 올려야 한다.

A와 B 두 작업이 각각 50ms의 CPU 시간을 필요로 한다고 하자. A는 10ms를 실행하고 I/O를 거는 패턴을 다섯 번 반복하고(I/O는 각 10ms), B는 50ms를 통째로 CPU만 사용한다. A를 다 실행한 뒤 B를 실행하면 A가 I/O로 블록된 동안 CPU가 놀게 된다. 자원을 비효율적으로 쓰는 것이다.

이때 A의 10ms짜리 CPU 구간 하나하나를 독립된 작은 작업처럼 취급하면, A가 I/O로 블록된 사이에 B를 CPU에 올려 겹쳐(overlap) 실행할 수 있다. CPU와 디스크가 동시에 동작하므로 시스템 활용도가 올라간다. 각 CPU 버스트를 작업 단위로 보는 이 방식 덕분에, I/O를 자주 하는 대화형 작업은 자연스럽게 자주 실행된다.

MLFQ — 길이를 모른 채 SJF에 다가가기

MLFQ

마지막 가정은 스케줄러가 작업 길이를 안다는 것이었다. 가장 비현실적인 가정이다. 다단계 피드백 큐(Multi-Level Feedback Queue, MLFQ)는 작업 길이를 모르고도 SJF처럼 짧은 작업을 먼저 실행하고, 동시에 RR처럼 응답시간을 확보하는 정책이다.

MLFQ의 핵심은 과거 행동으로 미래를 예측하는 데 있다. 작업이 그동안 어떻게 행동했는지 관찰해, 짧은 대화형 작업인지 긴 CPU 위주 작업인지 추정한다. 이를 위해 MLFQ는 우선순위가 다른 여러 개의 큐를 두고, 높은 큐에 있는 작업을 먼저 실행한다. 규칙을 차례로 쌓아 보자.

먼저 우선순위로 누구를 고를지 정하는 두 규칙이다.

규칙 1: Priority(A) > Priority(B)이면 A를 실행한다.
규칙 2: Priority(A) = Priority(B)이면 A와 B를 RR로 번갈아 실행한다.

우선순위를 고정해 두면 의미가 없다. MLFQ의 핵심은 우선순위를 작업의 행동에 따라 바꾸는 데 있고, 다음 세 규칙이 그 변화를 정의한다.

규칙 3: 작업이 시스템에 들어오면 가장 높은 우선순위(최상위 큐)에 놓는다.
규칙 4a: 주어진 타임 슬라이스를 다 쓰면 우선순위를 한 단계 낮춘다(큐를 한 칸 내린다).
규칙 4b: 슬라이스를 다 쓰기 전에 CPU를 양보하면 같은 우선순위를 유지한다.

이 규칙들은 새 작업을 일단 짧은 작업으로 가정해 최상위에 둔다. 정말 짧은 작업이면 금세 끝나고, 긴 작업이면 슬라이스를 거듭 다 쓰며 차츰 아래로 내려가 스스로 긴 작업임을 드러낸다. 이런 방식으로 MLFQ는 작업 길이를 모른 채 SJF를 근사한다. 규칙 4b 덕분에, I/O를 자주 걸어 슬라이스를 다 쓰기 전에 양보하는 대화형 작업은 높은 우선순위에 머물러 응답성도 확보된다.

이 기본형에는 두 가지 결함이 있다.

하나는 기아(starvation)다. 대화형 작업이 너무 많으면 이들이 CPU를 모두 차지해, 아래로 내려간 긴 작업이 영영 실행되지 못한다.

다른 하나는 스케줄러 게이밍(gaming)이다. 사용자가 규칙 4b를 악용할 수 있다. 슬라이스가 끝나기 직전에 불필요한 I/O를 한 번 걸어 CPU를 양보하면, 같은 큐에 머물면서 높은 우선순위를 유지한다. 슬라이스의 99%를 사용하고 양보하기를 반복하면 CPU를 거의 독점할 수 있다.

기아를 막기 위한 규칙이 추가된다.

규칙 5: 일정 시간 S가 지날 때마다 시스템의 모든 작업을 최상위 큐로 옮긴다.

주기적인 우선순위 부스트(priority boost)다. 아래에 깔려 있던 긴 작업도 주기적으로 최상위로 올라와 실행 기회를 얻으므로 굶지 않는다. CPU 위주로 동작하다가 대화형으로 성격이 바뀐 작업도 부스트를 통해 다시 높은 우선순위를 받는다.

게이밍은 누적 사용량을 기준으로 삼아 막는다. 원인이 된 규칙 4a·4b는 슬라이스를 다 쓰기 전에 양보하면 우선순위를 유지하게 했다. 양보 횟수와 무관하게 한 큐에서 쓴 시간의 총량을 기준으로 강등하면 이 허점이 사라진다. 규칙 4a·4b를 하나로 합친다.

규칙 4: 한 큐에서 주어진 시간 할당량을 (몇 번에 나눠 썼든) 다 쓰면 우선순위를 낮춘다.

이제 한 번에 길게 쓰든 잘게 나눠 쓰든 누적 사용량이 차면 강등되므로, I/O를 끼워 넣는 방식으로는 우선순위를 유지할 수 없다.

다듬어진 MLFQ의 최종 규칙은 다섯이다.

규칙 1: Priority(A) > Priority(B)이면 A를 실행한다(B는 실행하지 않는다).
규칙 2: Priority(A) = Priority(B)이면 A와 B를 RR로 실행한다.
규칙 3: 작업이 시스템에 들어오면 가장 높은 우선순위(최상위 큐)에 놓는다.
규칙 4: 한 큐에서 시간 할당량을 다 쓰면(몇 번에 나눠 양보했든) 우선순위를 낮춘다.
규칙 5: 일정 시간 S가 지나면 모든 작업을 최상위 큐로 옮긴다.

MLFQ는 작업에 대한 사전 지식을 요구하는 대신 실행을 관찰해 우선순위를 매긴다. 그 결과 짧은 대화형 작업에는 SJF·STCF에 가까운 성능을, 긴 CPU 위주 작업에는 공평한 진척을 함께 제공한다. BSD 계열 UNIX, Solaris, Windows NT 이후의 Windows 등 많은 시스템이 MLFQ 형태를 기본 스케줄러로 사용한다.

정리 — 무엇을 언제 쓰나

다섯 정책이 같은 문제를 어떻게 다르게 푸는지 정리하면 다음과 같다.

정책	선점	길이 사전지식	반환시간	응답시간	한 줄
FIFO	✗	불필요	나쁨 (호위 효과)	나쁨	도착 순서대로
SJF	✗	필요	최적 (동시 도착)	나쁨	짧은 작업 먼저
STCF	✓	필요	최적	나쁨	선점형 SJF
Round Robin	✓	불필요	나쁨	좋음	잘게 번갈아
MLFQ	✓	불필요	좋음	좋음	관찰로 SJF 근사

이들을 관통하는 한 가지는 trade-off다. 반환시간을 최적화하는 일과 응답시간을 최적화하는 일은 본질적으로 긴장 관계에 있다. SJF·STCF는 전자를, RR은 후자를 택했고, MLFQ는 작업 길이라는 알 수 없는 정보를 관찰로 메워 둘 사이에서 균형을 잡는다.

프로세스 vs 스레드

onebrotravel — Thu, 28 May 2026 21:51:56 +0900

프로세스 — 실행 중인 프로그램이라는 추상화

프로세스는 운영체제가 실행 중인 프로그램에 대해 제공하는 추상화다. 디스크에 저장된 실행 파일은 코드와 데이터의 정적인 모음일 뿐이고, 그것이 메모리에 올라가 CPU가 명령어를 실행하기 시작하면 비로소 프로세스가 된다. 같은 프로그램을 두 번 실행하면 두 개의 프로세스가 생긴다. 프로그램은 명사, 프로세스는 그 명사가 살아 움직이는 인스턴스다.

프로세스를 구성하는 핵심은 머신 상태(machine state) — 프로그램이 실행되는 동안 읽거나 바꿀 수 있는 모든 것이다.

주소 공간(address space): 프로세스가 접근할 수 있는 메모리 전체. 명령어와 데이터가 여기 들어간다.
레지스터: 프로그램 카운터(PC, 다음에 실행할 명령어 주소), 스택 포인터, 프레임 포인터 등 실행에 필수적인 CPU 레지스터.
I/O 정보: 현재 열어둔 파일 목록 등.

메모리 레이아웃

프로세스 메모리 레이아웃

프로세스의 주소 공간은 정해진 구조를 가진다. 낮은 주소부터 코드, 데이터, 힙이 자리하고, 힙은 위로 자라며, 스택은 주소 공간 최상단에서 아래로 자란다.

코드: 프로그램 명령어. 읽기 전용.
데이터: 초기화된/초기화되지 않은 전역 변수.
힙: malloc 등으로 동적 할당되는 영역. 위로 성장.
스택: 함수 호출, 지역 변수, 매개변수, 반환 주소. 아래로 성장.

힙과 스택이 서로 마주 보며 자라는 구조라는 점을 기억해 두면, 뒤에서 스레드를 다룰 때 "스택만 따로 떼어낸다"는 말이 자연스럽게 이해된다.

프로세스 상태

프로세스 상태 전환 다이어그램

프로세스가 생성되어 종료될 때까지 늘 CPU에서 돌고 있는 것은 아니다. 프로세스는 세 가지 기본 상태를 오간다.

Running(실행): 프로세서에서 실제로 명령어를 실행 중.
Ready(준비): 실행할 준비는 됐지만 OS가 아직 CPU를 주지 않은 상태. 스케줄링 대기.
Blocked(차단): 어떤 이벤트(주로 I/O 완료)가 일어나기 전까지는 실행할 수 없는 상태. 이때 CPU는 다른 프로세스가 쓴다.

상태 사이의 전환에는 이름이 붙어 있다. Ready에서 Running으로 가는 것은 스케줄됨(scheduled), 그 반대는 디스케줄됨(descheduled)이다. Running 상태의 프로세스가 디스크 읽기 같은 I/O를 시작하면 Blocked로 내려가고, I/O가 끝나면 다시 Ready로 올라온다. 이 전환을 누가 언제 결정하느냐가 바로 스케줄러 일이다.

PCB — OS가 프로세스를 기억하는 법

OS는 시스템에서 돌아가는 모든 프로세스를 추적해야 한다. 이를 위해 프로세스마다 정보를 담은 자료구조를 두는데, 이것을 PCB(Process Control Block) 또는 프로세스 기술자라 부른다. PCB에는 프로세스의 상태, PID, 부모 프로세스 포인터, 레지스터 컨텍스트(중단된 프로세스를 재개하기 위해 저장해 둔 레지스터 값들), 메모리 정보, 열린 파일 목록 등이 담긴다.

프로세스가 잠시 멈추고 다른 프로세스에 CPU를 넘길 때, OS는 현재 레지스터 값들을 PCB에 저장하고 다음 프로세스의 PCB에서 레지스터를 복원한다. 이 과정이 컨텍스트 스위치(context switch)다.

PCB의 다른 이름들

PCB는 자료에 따라 프로세스 리스트(process list), 작업 리스트(task list), 프로세스 기술자(process descriptor)로도 불린다. 여러 프로그램을 동시에 실행하는 모든 OS는 형태는 달라도 이런 구조를 반드시 가진다.

프로세스 생성 — fork / exec / wait

프로세스는 어떻게 만들어질까? UNIX 계열은 새 프로세스를 만드는 일을 세 개의 시스템 콜로 쪼개 놓았다. 각각은 단순하지만, 조합하면 셸 같은 강력한 도구를 만들 수 있다.

fork — 자기 자신을 복제

fork 분기

fork()는 호출한 프로세스의 (거의) 정확한 복사본을 만든다. 호출하는 쪽을 부모(parent), 새로 생긴 쪽을 자식(child)이라 한다. 자식은 부모의 주소 공간, 레지스터, 열린 파일 디스크립터를 복사해서 받는다. 단, 둘은 별개의 주소 공간을 가지므로 복사 이후의 변경은 서로에게 영향을 주지 않는다.

fork()의 가장 특이한 점은 "한 번 호출하면 두 번 반환한다"는 것이다. 한 번의 호출이 부모와 자식 양쪽에서 각각 반환되는데, 반환값이 다르다.

부모에게는 자식의 PID(양수)가 반환된다.
자식에게는 0이 반환된다.
실패하면 -1.

이 반환값 차이가 부모와 자식을 구분하는 유일한 수단이다. 같은 코드를 실행하지만 if (pid == 0) 분기로 서로 다른 길을 가게 만든다.

int main() {
    pid_t pid = fork();
    if (pid < 0) {
        // fork 실패
    } else if (pid == 0) {
        // 자식 프로세스
        printf("child\n");
    } else {
        // 부모 프로세스
        printf("parent of %d\n", pid);
    }
    return 0;
}

fork 직후 부모와 자식은 둘 다 실행 가능 상태가 되고, 누가 먼저 실행될지는 스케줄러가 정한다. 즉 출력 순서는 비결정적(nondeterministic)이다. 실행할 때마다 "parent"가 먼저 나올 수도, "child"가 먼저 나올 수도 있다.

실행 순서를 가정하지 말 것

부모가 항상 먼저 실행된다거나 자식이 먼저 끝난다는 가정은 위험하다. fork 이후의 순서는 스케줄러에 달려 있고 시스템·상황마다 다르다. 올바른 프로그램은 어떤 순서로 실행돼도 동작해야 한다.

wait — 자식이 끝나기를 기다림

부모가 자식의 작업 완료를 기다려야 할 때가 있다. wait()(또는 더 세밀한 waitpid())는 자식이 종료될 때까지 부모를 멈춰 세운다. 자식이 끝나면 부모에게 제어가 돌아온다.

wait는 두 가지 일을 한다. 하나는 동기화(synchronization) — 자식이 끝날 때까지 부모를 블록해서 실행 순서를 결정적으로 만든다. fork만 썼을 때 비결정적이던 출력이, 부모가 wait를 호출하면 "자식이 먼저 끝나고 부모가 이어받는" 순서로 고정된다. 다른 하나는 자식 수거(reaping)다.

종료된 자식 프로세스는 즉시 사라지지 않는다. 부모가 종료 상태를 확인할 수 있도록, 커널은 자식을 좀비(zombie) 상태로 남겨 둔다. 좀비는 실행되지는 않지만 프로세스 테이블 엔트리를 차지한다. 부모가 wait를 호출해 종료 상태를 거둬 가면 그제야 커널이 자식을 완전히 정리한다.

좀비를 방치하면

셸이나 서버처럼 오래 도는 프로그램이 자식을 수거하지 않으면 좀비가 쌓여 프로세스 테이블을 채운다. 장기 실행 프로그램은 반드시 자식을 명시적으로 수거해야 한다. 참고로 부모가 먼저 죽으면 고아가 된 자식은 PID 1번 init 프로세스가 입양해 대신 거둬 간다.

exec — 다른 프로그램으로 변신

fork만으로는 같은 프로그램의 복사본밖에 만들 수 없다. 자식이 부모와 다른 프로그램을 실행하려면 exec() 계열 시스템 콜이 필요하다.

exec는 새 프로세스를 만들지 않는다. 현재 프로세스의 코드·데이터·힙·스택을 지정한 실행 파일의 것으로 통째로 덮어쓴다. PID는 그대로 유지되지만 내용물은 완전히 다른 프로그램이 된다. 그래서 exec는 "한 번 호출하면 절대 반환하지 않는다" — 성공하면 돌아올 원래 코드가 더 이상 메모리에 없기 때문이다.

fork가 "한 번 호출, 두 번 반환"이라면 exec는 "한 번 호출, 반환 없음"이라는 대비가 깔끔하다.

fork + exec + wait = 셸

fork+exec+wait 타임라인

이 세 조각이 합쳐지면 셸의 동작이 된다. 셸이 명령어를 실행하는 과정은 다음과 같다.

셸이 fork()로 자식을 만든다.
자식이 exec()로 사용자가 입력한 프로그램으로 변신한다.
부모(셸)는 wait()로 자식이 끝나기를 기다린다(포어그라운드 실행). 끝나면 다음 프롬프트를 띄운다.

fork와 exec를 분리한 덕분에, 그 사이(자식이 fork된 직후, exec하기 직전)에 환경을 조작할 수 있다. 출력 리다이렉션(>)이나 파이프(|)가 바로 이 틈에서 파일 디스크립터를 바꿔 끼워 구현된다. 단순한 두 시스템 콜의 조합이 셸의 고급 기능을 떠받치는 것이다.

스레드 — 같은 주소 공간 안의 여러 실행 흐름

지금까지의 프로세스는 실행 흐름이 하나였다. 즉 PC가 하나뿐이라 한 번에 한 군데의 명령어만 실행했다. 스레드는 이 가정을 깬다. 하나의 프로세스 안에 여러 개의 실행 흐름, 즉 여러 개의 PC를 두는 것이다.

각 스레드는 자신만의 PC, 레지스터 집합, 그리고 스택을 가진다. 하지만 그 외의 것 — 코드, 데이터, 힙, 열린 파일 — 은 같은 프로세스 안의 모든 스레드가 공유한다. 스레드는 프로세스와 거의 같지만, 주소 공간을 공유한다는 결정적 차이가 있다.

무엇을 공유하고 무엇을 나누는가

싱글 vs 멀티스레드 주소 공간

단일 스레드 프로세스의 주소 공간에는 스택이 하나뿐이다. 멀티 스레드 프로세스에서는 스레드마다 스택이 하나씩 생긴다. 코드·데이터·힙은 그대로 공유하면서, 스택만 스레드 수만큼 주소 공간 안에 흩어져 자리 잡는다.

스택이 스레드별로 나뉘는 이유는 분명하다. 각 스레드가 독립적으로 함수를 호출하고 지역 변수를 쌓아야 하므로, 호출 스택을 공유할 수는 없다. 반면 힙과 전역 데이터는 공유하기 때문에, 스레드끼리 데이터를 주고받기가 매우 쉽다 — 그냥 같은 변수를 읽고 쓰면 된다.

컨텍스트 스위치 관점에서도 차이가 있다. 프로세스 간 전환은 주소 공간(페이지 테이블)까지 바꿔야 하지만, 같은 프로세스의 스레드 간 전환은 주소 공간이 그대로라 레지스터만 갈아 끼우면 된다. 그만큼 가볍다. 프로세스의 상태를 PCB에 저장했듯, 스레드의 상태는 TCB(Thread Control Block)에 저장된다.

왜 스레드가 필요한가

병렬성(parallelism): 멀티코어 시스템에서 작업을 여러 스레드로 쪼개면 여러 코어에서 동시에 실행돼 속도가 빨라진다.
응답성(responsiveness): 한 흐름이 느린 I/O를 기다리는 동안 다른 흐름이 계속 일할 수 있다. 디스크나 네트워크를 기다리며 프로그램 전체가 멈추는 것을 막는다.
낮은 통신 비용: 주소 공간을 공유하므로, 프로세스처럼 IPC를 거치지 않고 메모리로 직접 데이터를 나눈다.

스레드는 부모-자식 관계가 아니라 peer(동등) 관계라는 점도 프로세스와 다르다. 모든 프로세스는 메인 스레드로 시작하지만, 메인 스레드는 그저 "첫 번째" 스레드일 뿐 특별한 권한이 없다.

프로세스 vs 스레드 비교

네 가지 축으로 정리하면 차이가 분명해진다.

구분	프로세스	스레드
자원 공유	주소 공간 완전 분리	코드·데이터·힙 공유, 스택·레지스터·PC만 분리
생성·전환 비용	무겁다 (주소 공간 복사)	가볍다 (스택·컨텍스트만)
통신 방식	IPC 필요 (파이프·소켓 등)	공유 메모리 직접 접근
격리·안정성	높다 (한쪽이 죽어도 무관)	낮다 (한 스레드 오류가 전체에 영향)

몇 가지는 부연이 필요하다. 프로세스 생성이 무거운 이유는 주소 공간 전체를 복사하기 때문인데, 실제로는 Copy-on-Write로 최적화되지만 그래도 스레드보다는 무겁다. 전환 비용도 마찬가지다 — 프로세스 간 전환은 주소 공간(페이지 테이블)까지 바꿔야 하지만, 같은 프로세스의 스레드 간 전환은 페이지 테이블을 그대로 두고 레지스터만 갈아 끼우면 되므로 더 빠르다.

요약하면, 스레드는 격리와 안정성을 일부 포기하는 대신 가벼움과 쉬운 공유를 얻는 절충이다. 어느 쪽이 맞는지는 만들려는 프로그램의 성격에 달려 있다.

pthread 기초

POSIX 스레드(pthread)는 리눅스를 비롯한 모든 UNIX 계열에서 쓰는 표준 스레드 API다. 약 60개 함수가 있지만, 시작에 필요한 것은 생성·종료·동기화 세 가지다.

생성과 종료 — create / join

#include <pthread.h>

int pthread_create(pthread_t *thread,
                   const pthread_attr_t *attr,
                   void *(*start_routine)(void *),
                   void *arg);

int pthread_join(pthread_t thread, void **value_ptr);

pthread_create는 스레드를 만들어 start_routine 함수부터 실행시킨다. 인자는 네 개다.

thread: 생성된 스레드를 가리킬 식별자가 여기 채워진다.
attr: 스택 크기 같은 속성. 보통 기본값이면 되므로 NULL.
start_routine: 스레드가 실행할 함수. void *를 받아 void *를 반환하는 형태로 고정돼 있다. void 포인터라 어떤 타입이든 넘기고 받을 수 있다.
arg: 그 함수에 전달할 인자.

pthread_join은 지정한 스레드가 끝나기를 기다리고, 그 반환값을 거둔다. 프로세스의 wait에 대응하는 역할이다. 단, wait가 "아무 자식이나"를 기다릴 수 있는 것과 달리 join은 특정 스레드만 지정해 기다린다.

void *mythread(void *arg) {
    printf("%s\n", (char *) arg);
    return NULL;
}

int main() {
    pthread_t p1, p2;
    pthread_create(&p1, NULL, mythread, "A");
    pthread_create(&p2, NULL, mythread, "B");
    pthread_join(p1, NULL);
    pthread_join(p2, NULL);
    return 0;
}

이 프로그램에서 "A"와 "B" 중 무엇이 먼저 출력될지는 정해져 있지 않다. fork와 마찬가지로 스레드의 실행 순서도 스케줄러에 달려 있다.

공유 변수와 mutex

스레드가 주소 공간을 공유한다는 것은 양날의 검이다. 전역 변수나 정적 변수, 힙의 데이터는 모든 스레드가 같은 인스턴스를 본다(지역 자동 변수는 각 스레드의 스택에 따로 존재하므로 보통 공유되지 않는다). 공유는 편하지만, 여러 스레드가 같은 변수를 동시에 건드리면 문제가 생긴다.

대표적인 예가 공유 카운터다.

static int cnt = 0;

void *thread(void *arg) {
    for (int i = 0; i < 1000000; i++)
        cnt++;       // 위험
    return NULL;
}

cnt++는 한 줄처럼 보이지만 실제로는 세 단계로 컴파일된다. 컴파일러가 만들어내는 (어셈블리)코드는 대략 이렇다.

mov 0x8049a1c, %eax    # ① cnt 값을 레지스터로 읽어옴
add $0x1, %eax         # ② 레지스터 값을 1 증가
mov %eax, 0x8049a1c    # ③ 레지스터 값을 cnt에 다시 저장

문제는 한 스레드가 이 세 명령어를 실행하는 도중에 다른 스레드로 전환될 수 있다는 점이다. 예를 들어 cnt가 50일 때, 스레드 1이 ①②까지 실행해 레지스터에 51을 들고 있는 상태에서 전환이 일어나고, 스레드 2가 ①부터 ③까지 다 실행해 cnt를 51로 만든 뒤, 다시 스레드 1이 돌아와 ③을 실행하면 자기가 들고 있던 51을 저장한다. 두 스레드가 각각 1씩 더했는데 cnt는 52가 아니라 51이다. 증가 한 번이 통째로 사라진 것이다. 두 스레드가 각각 백만 번씩 더했는데 결과가 이백만이 아닌, 매번 다른 엉뚱한 값이 나오는 이유가 이것이다.

해결책은 그 코드 조각을 한 번에 한 스레드만 실행하도록 묶는 것이다. 이를 위한 가장 기본적인 도구가 mutex다.

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

pthread_mutex_lock(&lock);
cnt++;                        // 한 번에 한 스레드만 들어옴
pthread_mutex_unlock(&lock);

pthread_mutex_lock을 호출한 스레드가 잠금을 쥐면, 다른 스레드는 그 스레드가 pthread_mutex_unlock으로 풀어 줄 때까지 잠금 획득 지점에서 기다린다. 이렇게 보호된 코드 영역을 임계 구역(critical section)이라 하고, 한 번에 하나의 스레드만 들어가도록 보장하는 성질을 상호 배제(mutual exclusion)라 한다.

여기서는 여기까지

공유 변수가 왜 깨지는지(race condition의 정확한 분석), 잠금만으로 풀리지 않는 순서 제어, 세마포어·조건 변수, 그리고 잘못 쓰면 빠지는 데드락 — 이들은 동시성을 본격적으로 다루는 별도의 글에서 이어 간다. 이 글에서는 "공유 변수는 깨질 수 있고, 임계 구역을 잠금으로 묶어 막는다"까지만 짚는다.

컴파일

pthread를 쓰는 코드는 헤더 pthread.h를 include하고, 링크할 때 -pthread 플래그를 붙여야 한다.

gcc -o main main.c -Wall -pthread

정리

프로세스와 스레드는 결국 "실행에 필요한 자원을 어떻게 묶을 것인가"에 대한 두 가지 답이다. 프로세스는 주소 공간까지 통째로 분리해 안전을 얻고, 스레드는 주소 공간을 공유한 채 실행 흐름만 나눠 가벼움과 쉬운 공유를 얻는다. fork/exec/wait가 프로세스를 다루는 기본 도구이고, pthread의 create/join/mutex가 스레드를 다루는 기본 도구다.

Git Merge vs Rebase

onebrotravel — Wed, 27 May 2026 22:56:05 +0900

두 가지 통합 방식

서로 다른 브랜치의 작업을 통합하는 방법은 두 가지다.

git merge — 양쪽 브랜치의 끝점을 묶어 새 머지 커밋을 만든다
git rebase — 한 브랜치의 커밋들을 다른 브랜치 위에 패치로 다시 적용한다

같은 최종 결과(스냅샷)를 만들지만, 이력의 모양이 달라진다.

Fast-forward merge — 분기가 없는 경우

Merge - fast forward

master에서 hotfix 브랜치를 만들어 작업한 후 다시 master로 돌아와 머지하는 시나리오. master 포인터가 hotfix의 직계 조상이므로, Git은 단순히 master 포인터를 hotfix까지 전진시키는 것으로 머지를 완료한다.

$ git switch master
$ git merge hotfix
Updating f30ab..87ab2
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

출력에 Fast-forward가 보이면 새 머지 커밋이 만들어지지 않았다는 신호다. 두 브랜치 사이에 분기가 없었으므로 합칠 것이 없고, 포인터만 옮기면 된다.

3-way merge — 분기된 경우

3-way merge mechanism

두 브랜치가 공통 조상에서 분기한 후 양쪽 모두 작업이 진행되어, 한쪽이 다른 쪽의 직계 조상이 아닌 경우다. 예를 들어 master에서 hotfix를 머지한 후 iss53 브랜치를 다시 머지할 때.

$ git switch master
$ git merge iss53
Merge made by the 'recursive' strategy.
 index.html |    1 +
 1 file changed, 1 insertion(+)

이때 Git은 3-way merge를 수행한다. 두 브랜치의 끝점(C4, C5)과 두 브랜치의 공통 조상(C2)을 비교해 변경 사항을 합치고, 두 개의 부모를 가진 새 머지 커밋(C6)을 만든다.

3-way merge

머지 커밋은 일반 커밋과 달리 부모가 둘이다. 이것이 이력에서 분기가 일어났음을 영구히 기록한다.

머지 충돌 해결

양쪽 브랜치가 같은 파일의 같은 부분을 서로 다르게 수정했다면 Git은 자동으로 합칠 수 없다.

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

머지 커밋이 만들어지지 않고, 충돌이 해결될 때까지 머지가 일시 중단된다.

충돌 확인 — `git status`

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)
    both modified:   index.html

both modified 표시가 있는 파일이 충돌 파일이다.

충돌 마커

해당 파일을 열면 Git이 충돌 영역에 마커를 추가해두었다.

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
  please contact us at support@github.com
</div>
>>>>>>> iss53:index.html

<<<<<<< HEAD ~ ======= — 현재 브랜치(master)의 내용
======= ~ >>>>>>> iss53 — 머지할 브랜치(iss53)의 내용

해결 단계

파일을 열어 한쪽을 선택하거나 두 내용을 적절히 결합한 형태로 작성
<<<<<<<, =======, >>>>>>> 마커를 모두 제거
git add <file>로 해결됨을 표시
git commit으로 머지 커밋 완료

GUI 도구 — git mergetool

충돌을 시각적으로 해결하고 싶다면 git mergetool이 시스템에 설치된 머지 도구(vimdiff, meld, opendiff 등)를 실행해준다. 도구 종료 후 Git이 자동으로 해결된 파일을 staging해주므로 git commit만 실행하면 된다.

Rebase — 다른 통합 방식

rebase mechanism

같은 통합 결과를 만드는 다른 방법이 있다. 한 브랜치의 커밋들을 가져와 다른 브랜치 위에 패치로 다시 적용하는 방식 — git rebase다.

분기된 두 브랜치 master(끝 C3)와 experiment(끝 C4)가 있다고 하자.

$ git switch experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

이 명령의 동작:

두 브랜치의 공통 조상을 찾는다
현재 브랜치(experiment)의 각 커밋이 도입한 변경(diff)을 추출해 임시 파일에 저장
현재 브랜치를 master의 끝(C3)으로 리셋
저장해둔 변경들을 순차적으로 다시 적용 — 새 커밋 C4'이 만들어짐

이후 master에서 fast-forward 머지로 마무리.

$ git switch master
$ git merge experiment

이 시점에 C4'이 가리키는 스냅샷은 머지 방식으로 만들었을 때의 C5 스냅샷과 정확히 동일하다. 차이는 이력의 모양뿐이다.

Merge vs Rebase — 결과 비교

Merge vs Rebase 결과 비교

Merge — 분기가 보존되고 두 부모를 가진 머지 커밋이 남는다. 이력이 "실제로 일어난 일"을 그대로 보여준다
Rebase — 분기 흔적이 사라지고 직선형 이력이 된다. "처음부터 차례로 작업된 것처럼" 보인다

스냅샷의 최종 상태는 같지만, 이력을 어떻게 표현하느냐가 다르다.

Rebase의 위험성

rebase danger

Rebase는 기존 커밋을 버리고 새 커밋을 만드는 작업이다. SHA-1 해시가 바뀐다. 이 사실이 협업 상황에서 큰 문제를 일으킬 수 있다.

Rebase 황금률

외부에 push된, 다른 사람이 기반으로 작업할 수 있는 커밋은 절대 rebase하지 말 것.

이 원칙만 지키면 문제없다. 어기면 협업자 전체가 혼란에 빠진다.

문제 시나리오: 누군가 push된 커밋을 rebase로 정리한 후 git push --force로 덮어쓰면, 그 커밋을 기반으로 작업하던 협업자의 로컬 저장소에 이름은 다르지만 내용은 거의 같은 커밋들이 남는다. 이후 협업자가 git pull을 하면 같은 작업을 두 번 머지하는 꼴이 되고, 이력이 엉킨다.

협업자가 이 상황을 만났을 때 git pull --rebase(또는 git fetch 후 git rebase)를 사용하면 Git이 patch-id로 중복을 인식해 자동 정리해주는 경우가 있다. 다만 완벽하지 않으므로 애초에 push된 커밋을 rebase하지 않는 것이 최선이다.

# pull이 항상 rebase 방식으로 동작하게 설정
$ git config --global pull.rebase true

어느 쪽을 선택할까

이력을 보는 두 관점이 있다.

이력 = 실제 일어난 일의 기록 — 분기·머지의 흐름을 그대로 보존해야 한다. 이 관점에서는 Merge가 정답
이력 = 프로젝트가 만들어진 이야기 — 후속 독자가 이해하기 좋은 흐름으로 재구성한다. 이 관점에서는 Rebase가 유용

실무에서 가장 흔히 권장되는 패턴은 둘의 조합이다.

로컬 작업 중(아직 push 전): 필요하면 rebase로 이력 정리
이미 push한 커밋: 절대 rebase하지 않음

이렇게 하면 깔끔한 이력의 이점을 누리면서 협업 안정성도 지킬 수 있다.

Git 브랜치 — 포인터로 이해하기

onebrotravel — Wed, 27 May 2026 17:24:12 +0900

데이터 모델 — 커밋과 부모 포인터

커밋 객체 구조

Git의 브랜치 동작을 이해하려면 먼저 커밋이 어떻게 저장되는지를 정확히 알아야 한다.

Git Basics — 변경 취소·원격 저장소·태그에서 다룬 대로, Git은 데이터를 변경 차이가 아니라 스냅샷으로 저장한다. 커밋을 만들면 Git은 다음 세 종류의 객체를 만든다.

객체	역할
blob	파일 하나의 내용을 담는 객체 (이름·경로 정보 없음)
tree	디렉터리 구조 — 어떤 파일 이름이 어떤 blob을 가리키는지
commit	루트 tree를 가리키는 포인터 + 메타데이터(작성자, 메시지, 부모 커밋 포인터)

예를 들어 파일 3개를 처음 커밋하면 저장소에 객체 5개가 생성된다 — blob 3개 + 루트 tree 1개 + commit 1개.

다음 커밋을 만들면 또 다른 commit 객체가 생기는데, 이 객체는 이전 커밋을 가리키는 부모 포인터를 가진다. 일반적인 커밋은 부모가 1개, 첫 커밋은 부모가 0개, 머지 커밋은 부모가 2개 이상이다.

이 구조 덕분에 커밋 이력은 부모 포인터를 따라 거슬러 올라가는 단방향 체인이 된다.

브랜치 = 포인터

Git에서 브랜치는 커밋 하나를 가리키는 가볍고 이동 가능한 포인터일 뿐이다. 별다른 자료구조가 아니라 단순히 커밋 SHA-1을 담은 41바이트 파일(40자 해시 + 줄바꿈).

git init 시 자동으로 만들어지는 master(또는 main)도 특별한 브랜치가 아니다. 다른 브랜치와 완전히 동일한 포인터이며, 단지 기본값으로 생성될 뿐이다.

새 커밋을 만들면 현재 브랜치 포인터가 자동으로 새 커밋을 가리키도록 이동한다.

HEAD — 현재 위치 포인터

Git이 "지금 어느 브랜치에서 작업 중인지" 알아내는 방법은 HEAD라는 특별한 포인터다. HEAD는 현재 체크아웃된 브랜치를 가리킨다.

$ git log --oneline --decorate
f30ab (HEAD -> master, testing) Add feature #32
34ac2 Fix bug #1328
98ca9 Initial commit

이 출력에서 master와 testing 두 브랜치는 같은 커밋(f30ab)을 가리키고 있고, HEAD는 master에 있다.

SVN/CVS의 HEAD와 다르다

Subversion이나 CVS의 HEAD는 "원격의 최신 리비전"을 의미했지만, Git에서 HEAD는 로컬에서 현재 작업 중인 브랜치를 가리키는 포인터다. 개념이 다르므로 혼동하지 말 것.

브랜치 만들기와 전환

브랜치 생성·전환 전후 비교

새 브랜치 만들기 — `git branch`

$ git branch testing

이 명령은 현재 위치한 커밋을 가리키는 새 포인터를 만든다. 전환은 하지 않는다. HEAD는 여전히 이전 브랜치(예: master)에 있다.

기존 브랜치로 전환

Git 2.23 이전에는 git checkout이 표준이었고, 2.23부터는 git switch가 권장된다.

# 전통 방식
$ git checkout testing

# Git 2.23+ 권장
$ git switch testing

두 명령 모두 HEAD를 해당 브랜치로 옮긴다. 동시에 작업 디렉터리의 파일 상태도 그 브랜치의 마지막 커밋 시점으로 되돌아간다.

생성 + 전환 한 번에

# 전통 방식
$ git checkout -b iss53

# Git 2.23+ 권장
$ git switch -c iss53

-c는 --create의 약자다.

브랜치 전환은 작업 디렉터리를 바꾼다

브랜치를 전환하면 작업 디렉터리의 파일들이 새 브랜치의 마지막 커밋 시점 상태로 되돌아간다. 만약 작업 디렉터리에 커밋되지 않은 변경이 있고 그게 새 브랜치와 충돌한다면, Git은 전환 자체를 거부한다.

전환 전에 변경을 커밋하거나, 임시로 치워두려면 git stash를 사용한다.

분기와 합류 — 기본 워크플로우

브랜치를 만들어 작업하다가 다른 브랜치로 잠시 전환했다가 다시 합치는 흐름은 다음과 같다.

# 1. master에서 새 기능 작업 시작
$ git switch -c iss53
$ vim index.html
$ git commit -a -m 'Create new footer [issue 53]'

# 2. 긴급 hotfix 요청 — master로 돌아가서 hotfix 브랜치 만들기
$ git switch master
$ git switch -c hotfix
$ vim index.html
$ git commit -a -m 'Fix broken email address'

# 3. hotfix를 master에 머지
$ git switch master
$ git merge hotfix

# 4. iss53 브랜치로 돌아가 작업 계속
$ git switch iss53

이 흐름의 핵심은 각 브랜치의 작업이 서로 독립적이라는 점이다. iss53에서 작업한 내용은 master에 영향을 주지 않고, 그 반대도 마찬가지다.

자세한 머지 메커니즘(fast-forward vs 3-way merge, rebase, 충돌 해결)은 다음 글에서 다룬다.

이력을 그래프로 확인하려면:

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD -> master) Make other changes
| * 87ab2 (iss53) Make a change
|/
* f30ab Add feature #32
* 34ac2 Fix bug #1328
* 98ca9 Initial commit

브랜치 관리

목록 보기

$ git branch
  iss53
* master
  testing

* 표시가 현재 체크아웃된 브랜치(HEAD가 가리키는 브랜치)다.

각 브랜치의 마지막 커밋 정보까지 보려면 -v 옵션:

$ git branch -v
  iss53    93b412c Fix javascript issue
* master   7a98805 Merge branch 'iss53'
  testing  782fd34 Add scott to the author list

삭제

$ git branch -d iss53

-d는 안전 삭제. 해당 브랜치가 현재 브랜치에 머지되지 않았다면 Git이 삭제를 거부한다.

$ git branch -d testing
error: The branch 'testing' is not fully merged.
If you are sure you want to delete it, run 'git branch -D testing'.

머지하지 않은 작업을 정말 버리고 싶다면 -D로 강제 삭제.

$ git branch -D testing

이름 변경

로컬에서:

$ git branch --move bad-name corrected-name
# 또는 짧게
$ git branch -m bad-name corrected-name

원격까지 반영하려면 새 이름으로 push하고 옛 이름을 원격에서 삭제한다.

$ git push --set-upstream origin corrected-name
$ git push origin --delete bad-name

공유 브랜치 이름은 함부로 바꾸지 말 것

다른 협업자들이 사용 중인 브랜치 — 특히 master, main, mainline 같은 메인 브랜치 — 의 이름을 바꾸면 모든 협업자의 로컬 추적 브랜치가 망가진다. 이런 경우 사전에 팀과 합의하고, CI/CD·이슈 트래커·다른 통합 도구에서 참조하는 브랜치명도 모두 함께 업데이트해야 한다.

Git Basics — 변경 취소·원격 저장소·태그

onebrotravel — Wed, 27 May 2026 13:59:45 +0900

변경 취소

작업하다 보면 어느 단계에서든 변경을 되돌리고 싶을 수 있다. Git이 제공하는 되돌리기 도구는 영역(Working/Staging/Repository)에 따라 다른 명령을 쓴다.

되돌릴 수 없는 작업도 있다

Git의 거의 모든 작업은 데이터를 추가만 하므로 복구 가능하지만, 일부 되돌리기 명령은 데이터를 실제로 잃게 만든다. 특히 커밋되지 않은 변경(Modified/Staged 상태)을 폐기하면 거의 복구되지 않는다.

`git commit --amend` — 마지막 커밋 수정

너무 일찍 커밋했을 때 — 파일을 빠뜨렸거나 메시지를 잘못 입력한 경우 — --amend로 마지막 커밋을 수정할 수 있다.

$ git commit -m "Initial commit"
$ git add forgotten_file
$ git commit --amend

이 명령은 현재 staged 상태인 내용을 마지막 커밋으로 만든다. 변경 사항이 없으면 메시지만 수정된다.

--amend는 "수정"이 아니라 "대체"

--amend는 기존 커밋을 새 커밋으로 완전히 대체한다. 원래 커밋은 이력에서 사라진다.

또한 아직 push되지 않은 커밋에만 사용해야 한다. 이미 push된 커밋을 amend하고 다시 push하면 협업자에게 문제가 생긴다.

스테이지 취소 — Unstaging

git add로 스테이지한 파일을 다시 unstaging area에서 빼는 작업.

Git 2.23 이전: git reset HEAD <file>

$ git reset HEAD CONTRIBUTING.md

Git 2.23 이후 권장: git restore --staged <file>

$ git restore --staged CONTRIBUTING.md

두 명령 모두 같은 효과 — 파일을 Staged에서 Modified로 되돌린다. 작업 디렉터리의 실제 파일 내용은 건드리지 않으므로 비교적 안전하다.

git status가 직접 어느 명령을 쓰면 되는지 알려주기 때문에 외울 필요는 없다.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

수정 내용 폐기 — Unmodifying

작업 디렉터리에서 수정한 내용을 마지막 커밋(또는 마지막 staged) 상태로 되돌리는 작업.

Git 2.23 이전: git checkout -- <file>

$ git checkout -- CONTRIBUTING.md

Git 2.23 이후 권장: git restore <file>

$ git restore CONTRIBUTING.md

이 명령들은 실제로 데이터를 잃게 한다

git restore <file>과 git checkout -- <file>은 작업 디렉터리의 변경을 강제로 폐기한다. Git이 추적하지 않은 변경이므로 복구되지 않는다.

잠시 치워두고 싶을 뿐이라면 폐기하지 말고 git stash를 사용한다.

영역별 변경 취소 흐름 다이어그램

원격 저장소

협업하려면 원격 저장소(remote repository)를 관리해야 한다. 원격은 인터넷이나 네트워크에 호스팅된 프로젝트의 복사본이다. Git은 여러 원격을 동시에 다룰 수 있고, 각각 읽기 전용 또는 읽기/쓰기 권한을 가진다.

원격 목록 보기

설정된 원격 목록을 확인한다.

$ git remote
origin

origin은 clone 시 Git이 자동으로 부여하는 기본 이름이다. -v 옵션으로 fetch/push에 사용되는 URL까지 본다.

$ git remote -v
origin  https://github.com/schacon/ticgit (fetch)
origin  https://github.com/schacon/ticgit (push)

원격 추가

새 원격을 short name(별칭)으로 등록한다.

$ git remote add pb https://github.com/paulboone/ticgit

이제 URL 전체 대신 pb로 참조할 수 있다.

$ git fetch pb

Fetch vs Pull

로컬·원격 동기화 흐름 다이어그램

두 명령 모두 원격에서 데이터를 가져오지만 동작이 다르다.

git fetch <remote> — 원격의 변경을 로컬 저장소에 다운로드만 한다. 현재 작업 중인 브랜치에는 영향 없음. 가져온 후 수동으로 병합해야 한다.

$ git fetch origin

git pull — fetch + merge를 한 번에 수행한다. 현재 브랜치가 원격 브랜치를 추적 중이라면, 가져온 변경을 현재 브랜치에 자동 병합한다.

$ git pull

Git 2.27 이후 pull.rebase 경고

Git 2.27부터 git pull 실행 시 pull.rebase 설정이 없으면 경고가 나온다. 다음 중 한쪽으로 설정해두는 게 좋다.

기본 병합 동작 (fast-forward 우선, 안 되면 merge commit): git config --global pull.rebase "false"

pull 시 rebase: git config --global pull.rebase "true"

Push

로컬 변경을 원격으로 올린다.

$ git push <remote> <branch>

예시:

$ git push origin master

이 명령은 두 조건이 모두 충족돼야 작동한다.

쓰기 권한이 있는 원격에서 clone한 경우
그 사이 다른 사람이 먼저 push하지 않은 경우

다른 사람이 먼저 push했다면 push가 거부된다. 그 경우 먼저 fetch 후 병합한 뒤 다시 push해야 한다.

원격 상세 확인

$ git remote show origin
* remote origin
  Fetch URL: https://github.com/schacon/ticgit
  Push  URL: https://github.com/schacon/ticgit
  HEAD branch: master
  Remote branches:
    master      tracked
    dev-branch  tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

URL, 추적 중인 브랜치, pull/push 시 어느 브랜치가 어디로 매핑되는지를 한눈에 보여준다.

원격 이름 변경·삭제

# 이름 변경
$ git remote rename pb paul

# 삭제
$ git remote remove paul

원격을 삭제하면 연결된 원격 추적 브랜치와 설정 정보도 함께 사라진다.

종류	특징
Lightweight	특정 커밋을 가리키는 포인터. 다른 정보 없음
Annotated	Git 데이터베이스에 객체로 저장. 태그 작성자·날짜·메시지 포함. GPG 서명 가능

Git Basics — 저장소 만들기와 변경 기록

onebrotravel — Tue, 26 May 2026 23:57:01 +0900

저장소 만들기

Git을 사용하려면 먼저 Git 저장소가 있어야 한다. 저장소를 시작하는 방법은 두 가지: 기존 디렉터리를 Git 저장소로 만들기 또는 이미 존재하는 저장소를 복제하기.

기존 디렉터리 초기화

cd /path/to/your/project
git init

이 명령은 현재 디렉터리에 .git 하위 디렉터리를 생성한다. .git 안에는 저장소의 모든 메타데이터와 객체 데이터베이스가 들어간다. 이 시점에서는 아직 어떤 파일도 추적되고 있지 않다.

기존 파일들을 추적하려면 add + commit으로 첫 커밋을 만든다.

git add .
git commit -m "Initial commit"

기존 저장소 복제

이미 존재하는 Git 저장소의 전체 사본을 받아오려면 git clone을 쓴다.

git clone https://github.com/libgit2/libgit2

이 명령은 libgit2라는 디렉터리를 만들고, 그 안에 .git 디렉터리를 초기화한 뒤 원격 저장소의 모든 데이터와 모든 이력을 가져와 최신 버전을 체크아웃한다.

다른 이름으로 받고 싶다면 두 번째 인자를 지정한다.

git clone https://github.com/libgit2/libgit2 mylibgit

Git은 다양한 전송 프로토콜을 지원한다.

https:// — HTTPS 프로토콜
git@github.com:... — SSH 프로토콜
git:// — Git 자체 프로토콜

파일 상태 확인

Git에서 작업 디렉터리의 모든 파일은 다음 두 그룹 중 하나에 속한다.

Tracked (추적되는 파일): 이전 스냅샷에 있던 파일. Modified / Staged / Unmodified 중 하나의 상태
Untracked (추적되지 않는 파일): 작업 디렉터리에 있지만 이전 스냅샷에도 없고 staging area에도 없는 파일

저장소를 처음 클론하면 모든 파일이 Tracked + Unmodified 상태다. 새로 만든 파일은 처음에 Untracked다.

파일 상태 생명주기 다이어그램

`git status`

현재 어떤 파일이 어떤 상태인지 확인하는 핵심 명령.

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    README

nothing added to commit but untracked files present (use "git add" to track)

출력에서 알 수 있는 것:

현재 브랜치 (master)
원격 브랜치와의 차이 (없음)
Untracked / Modified / Staged 파일 목록

Short status — `git status -s`

긴 출력이 부담스러울 때 압축형을 쓴다.

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

각 줄 앞의 두 글자가 상태를 나타낸다. 좌측은 staging area, 우측은 working directory.

표기	의미
`??`	Untracked
`A`	Staging area에 새로 추가됨
`M`	Modified (스테이지 안 됨)
`M`	Modified 후 staged
`MM`	Staged 했고, 그 이후 또 modified

변경 사항 보기

git diff 비교 대상 다이어그램

git status는 어떤 파일이 변경됐는지 알려주지만, 정확히 무엇이 변경됐는지 보려면 git diff를 쓴다.

git diff는 어느 영역과 어느 영역을 비교하느냐에 따라 두 가지 모드가 있다.

스테이지 안 한 변경 — `git diff`

옵션 없이 실행하면 Working Directory vs Staging Area 비교. 즉 "아직 스테이지하지 않은 변경"을 보여준다.

git diff

다음 커밋에 들어갈 변경 — `git diff --staged`

--staged (또는 동의어 --cached) 옵션을 붙이면 Staging Area vs 마지막 커밋(HEAD) 비교. 즉 "다음 커밋에 들어갈 변경"을 보여준다.

git diff --staged

변경 추적과 커밋

파일 추가·스테이징 — `git add`

git add는 두 가지 일을 모두 한다.

Untracked 파일을 추적 대상으로 만든다
Modified 파일을 다음 커밋에 포함될 변경으로 스테이지한다

git add README
git add CONTRIBUTING.md

디렉터리를 지정하면 그 아래 모든 파일을 재귀적으로 처리한다.

git add .

커밋 만들기 — `git commit`

스테이지된 변경 사항을 영구 저장하는 명령.

git commit

이 명령은 에디터를 열어 커밋 메시지 작성을 요구한다. 메시지를 저장하고 에디터를 닫으면 커밋이 만들어진다.

한 줄 메시지면 -m 옵션이 빠르다.

git commit -m "Story 182: Fix benchmarks for speed"

Staging 생략 — `git commit -a`

이미 tracked인 파일들에 한해, staging area를 거치지 않고 바로 커밋할 수 있다.

git commit -a -m "Quick fix"

이 옵션은 모든 Modified 파일을 자동으로 staging하고 커밋한다. 단, Untracked 파일은 포함되지 않는다.

-a 옵션의 트레이드오프

Staging area를 거치지 않는다는 건 "커밋에 들어갈 변경을 선별하는" 단계를 건너뛴다는 뜻이다. 작은 수정에는 편하지만, 여러 변경을 작업 단위로 나누어 커밋하는 워크플로우와는 맞지 않는다. 모든 커밋이 "이번 작업에서 바꾼 거 전부"가 되어버린다.

추적 제외 — `.gitignore`

빌드 산출물, 로그 파일, 의존성 디렉터리(node_modules 등)처럼 추적하고 싶지 않은 파일들이 있다. 이런 파일들은 .gitignore에 패턴으로 등록한다.

# 모든 .a 파일 무시
*.a

# 단 lib.a는 추적 (앞의 규칙 무효화)
!lib.a

# 현재 디렉터리의 TODO 파일만 무시 (subdir/TODO는 추적)
/TODO

# build 라는 이름의 모든 디렉터리 무시
build/

# doc/notes.txt 무시, doc/server/arch.txt는 추적
doc/*.txt

# doc/ 아래 모든 .pdf 파일 (재귀)
doc/**/*.pdf

패턴 문법 요약:

* — 임의의 문자열
! — 앞의 무시 규칙을 무효화
/ 접두사 — 루트 디렉터리에서만 매치
/ 접미사 — 디렉터리 매치
** — 재귀적 매치

GitHub가 언어·프레임워크별 표준 .gitignore 템플릿을 제공한다 → github.com/github/gitignore

파일 제거와 이동

파일 제거 — `git rm`

Tracked 파일을 작업 디렉터리에서 제거하고 staging area에서도 빼는 명령.

git rm README.md

단순히 rm만 사용해도 작동은 한다 (Modified + Deleted 상태로 잡힘). 다만 git rm이 한 번에 처리해주므로 더 깔끔하다.

디스크 파일은 남기고, Git 추적에서만 제외하고 싶다면 --cached 옵션을 쓴다.

git rm --cached config.local

.gitignore에 등록을 깜빡한 채 commit해버린 파일을 사후에 제외할 때 자주 쓴다.

파일 이동·이름 변경 — `git mv`

git mv README.md README

Git은 파일의 rename을 자동으로 추적한다. 사실 git mv는 다음 세 명령의 단축형이다.

mv README.md README
git rm README.md
git add README

이력 보기 — `git log`

커밋 히스토리를 시간 역순으로 출력한다.

git log

기본 출력은 각 커밋의 SHA, 저자, 날짜, 커밋 메시지를 모두 보여준다.

자주 쓰는 옵션

옵션	효과
`--oneline`	커밋당 한 줄 (SHA 짧게 + 메시지)
`--graph`	브랜치·머지를 ASCII 그래프로 표시
`--all`	모든 브랜치의 커밋 포함
`-p` 또는 `--patch`	각 커밋의 diff까지 표시
`--stat`	각 커밋의 변경 파일·라인 수 통계
`-<n>`	최근 n개만 (예: `git log -5`)
`--pretty=format:"..."`	커스텀 포맷으로 출력

자주 쓰이는 조합은 git log --oneline --graph --all — 모든 브랜치의 흐름을 한 화면에 압축.

출력 범위 제한

옵션	효과
`--since=<date>`, `--until=<date>`	시간 범위 (예: `--since=2.weeks`)
`--author=<name>`	특정 저자의 커밋만
`--grep=<pattern>`	커밋 메시지에 패턴이 들어간 것만
`-- <path>`	특정 파일·경로의 변경이 포함된 커밋만

여러 옵션을 조합할 수 있다.

git log --since=2.weeks --author="Alice" --oneline

자주 쓰는 조합을 alias로 등록해두면 편하다.

Git 설치와 초기 설정

onebrotravel — Tue, 26 May 2026 22:56:06 +0900

Git 설치

Git을 사용하려면 컴퓨터에 Git이 설치되어 있어야 한다. 설치 방법은 크게 세 가지: 패키지 관리자, 공식 인스톨러, 소스 빌드. 일반적인 사용 환경에서는 앞의 두 방법이면 충분하고, 최신 버전이 꼭 필요한 경우에만 소스 빌드를 선택한다.

Git 버전 호환성

Pro Git은 Git 2.x 기준으로 작성되었으며, Git은 하위 호환성이 매우 뛰어나다. 최근 버전이라면 책의 명령어 대부분이 그대로 작동한다.

Linux

배포판의 패키지 관리자를 사용한다.

Fedora · RHEL · CentOS (RPM 계열):

sudo dnf install git-all

Ubuntu · Debian 계열:

sudo apt install git-all

기타 Unix 계열 배포판은 Git 공식 다운로드 페이지 참조.

macOS

가장 간단한 방법은 Xcode Command Line Tools 설치다. macOS Mavericks(10.9) 이상에서는 터미널에 처음 git 명령을 입력하면 자동으로 설치 프롬프트가 뜬다.

git --version

Git이 없으면 위 명령에 설치 안내가 따라온다.

최신 버전이 필요하면 공식 macOS 인스톨러를 사용한다.

Windows

공식 설치 파일은 git-scm.com/downloads/win에서 받는다. 페이지 접속 시 자동으로 다운로드가 시작된다.

이 설치 파일은 "Git for Windows"라는 별도 프로젝트가 유지하며, Git 본 프로젝트와는 구분된다. 자세한 정보는 gitforwindows.org 참조.

자동화된 설치가 필요한 경우 Chocolatey 패키지로 설치할 수도 있다. 단, Chocolatey 패키지는 커뮤니티 유지보수다.

소스 빌드

바이너리 인스톨러는 최신 버전보다 다소 뒤처져 있을 수 있다. 최신 버전이 꼭 필요할 때 소스 빌드를 선택한다.

의존성 설치

# Fedora 계열
sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \
  openssl-devel perl-devel zlib-devel

# Debian 계열
sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \
  gettext libz-dev libssl-dev

문서(doc/HTML/info) 생성을 원한다면 추가 의존성이 필요하다.

# Fedora 계열
sudo dnf install asciidoc xmlto docbook2X

# Debian 계열
sudo apt-get install asciidoc xmlto docbook2x

RHEL · CentOS · Scientific Linux 추가 설정

docbook2X 패키지 설치를 위해 EPEL 저장소를 활성화해야 한다. 또한 db2x_docbook2texi의 이름이 다르므로 심볼릭 링크가 필요하다.

sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi

소스 다운로드 + 빌드

소스는 kernel.org 공식 페이지 또는 GitHub 미러에서 받는다. kernel.org는 릴리스 서명도 함께 제공하므로 다운로드 신뢰성 검증이 가능하다.

tar -zxf git-2.8.0.tar.gz
cd git-2.8.0
make configure
./configure --prefix=/usr
make all doc info
sudo make install install-doc install-html install-info

설치 후에는 Git 자체로 Git 저장소를 클론받아 업데이트할 수도 있다.

git clone https://git.kernel.org/pub/scm/git/git.git

초기 설정

Git이 설치되면 환경을 개인에게 맞게 초기 설정한다. 이 설정은 한 컴퓨터에서 한 번만 하면 되며, 업그레이드 이후에도 그대로 유지된다.

Git의 설정 도구는 git config다. 설정은 다음 세 위치 중 하나에 저장된다.

설정이 저장되는 세 위치

위치	옵션	적용 범위
`[path]/etc/gitconfig`	`--system`	시스템의 모든 사용자·저장소
`~/.gitconfig` 또는 `~/.config/git/config`	`--global`	현재 사용자
`.git/config` (저장소 내부)	`--local` (기본값)	현재 저장소만

우선순위: local > global > system. 좁은 범위의 설정이 넓은 범위를 덮어쓴다. 예를 들어 --global로 user.email을 설정해두고, 특정 저장소에서만 --local로 다른 이메일을 설정하면 해당 저장소에서는 local 값이 적용된다.

git config 스코프 다이어그램

--system은 시스템 구성 파일을 건드리므로 관리자 권한이 필요하다. 개인 작업 환경에서는 --global이 가장 자주 쓰인다.

사용자 정보 (필수)

Git을 설치한 후 가장 먼저 해야 할 설정. Git은 커밋을 만들 때마다 이 정보를 메타데이터로 영구히 기록한다.

git config --global user.name "John Doe"
git config --global user.email "johndoe@example.com"

--global을 사용하면 해당 컴퓨터의 모든 프로젝트에서 이 값이 기본값으로 쓰인다. 특정 프로젝트에서 다른 이름·이메일을 사용하고 싶다면 그 저장소 안에서 --global 없이 같은 명령을 실행하면 로컬 설정이 덮어쓴다.

기본 편집기

Git이 커밋 메시지나 기타 메시지를 작성할 때 실행하는 편집기. 설정하지 않으면 시스템 기본 편집기를 사용한다.

git config --global core.editor vim

Vim은 Unix 계열 시스템에 대부분 기본 탑재되어 있어 추가 설치가 필요 없는 경우가 많지만, 환경에 따라 직접 설치해야 할 수도 있다.

Linux

# Fedora 계열
sudo dnf install vim

# Debian 계열
sudo apt install vim

macOS

기본 탑재된 Vim을 그대로 사용하거나, Homebrew로 최신 버전을 설치할 수 있다.

brew install vim

Windows

Git for Windows 설치 시 Vim도 함께 들어가므로 별도 설치가 보통은 필요 없다. 그렇지 않은 경우 vim.org 공식 페이지에서 받는다.

설치 확인:

vim --version

다른 편집기를 쓰고 싶다면 core.editor 값을 바꾸면 된다. Emacs, VS Code 등도 같은 방식으로 설정할 수 있다.

git config --global core.editor emacs
git config --global core.editor "code --wait"

Windows에서는 편집기의 전체 경로를 정확히 지정해야 한다. 예를 들어 Notepad++:

git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

편집기 미설정 시 문제

편집기를 적절히 설정하지 않으면 Git이 편집기를 실행할 때 문제가 발생할 수 있다. 특히 Windows에서는 Git 명령이 비정상 종료되거나 커밋 메시지가 작성되지 않은 상태로 종료되는 혼란스러운 상태에 빠질 수 있다.

기본 브랜치명

Git 2.28 이전 버전은 git init 시 자동으로 master 브랜치를 생성했다. 2.28부터는 기본 브랜치 이름을 사용자가 지정할 수 있다.

git config --global init.defaultBranch main

설정 확인

현재 적용된 모든 설정을 보려면:

git config --list

user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
...

같은 키가 여러 번 출력될 수 있다. Git이 여러 설정 파일(~/.gitconfig, [path]/etc/gitconfig 등)에서 같은 키를 읽기 때문이다. 이 경우 마지막으로 읽은 값이 최종값이다.

특정 키의 값만 보려면:

git config user.name

설정의 출처까지 확인하려면 --show-origin 옵션을 사용한다.

git config --list --show-origin

예상치 못한 값이 적용되어 있을 때 어느 설정 파일이 우선 적용되었는지 추적할 수 있다.

Git을 이해하기 위한 세 가지 — VCS, 데이터 모델, Three States

onebrotravel — Tue, 26 May 2026 22:31:12 +0900

버전 관리란

버전 관리(version control) 는 파일의 변경 이력을 시간순으로 기록해두는 작업이다. 변경할 때마다 누가, 언제, 무엇을 바꿨는지 기록을 남기면 다음과 같은 일이 가능해진다.

특정 파일이나 전체 프로젝트를 과거의 어느 시점 상태로 복원
두 시점 사이에 어떤 변경이 있었는지 비교
문제를 일으킨 변경의 시점·작성자·내용 추적
실수로 손상·삭제된 파일 복구

소스 코드만의 이야기가 아니다. 이미지, 문서, 디자인 레이아웃 등 시간에 따라 바뀌는 거의 모든 파일에 적용할 수 있는 개념이다.

왜 필요한가

가장 단순한 버전 관리는 파일을 복사해서 다른 이름으로 저장하는 것이다. report.docx, report_v2.docx, report_final.docx, report_final_진짜.docx 같은 형태.

이 방식은 혼자 작업할 때조차 다음 문제를 일으킨다.

어느 파일이 최신인지 잊기 쉬움
잘못된 파일을 덮어쓸 위험
두 시점의 변경 내역을 비교하기 어려움
파일 수가 늘어날수록 디렉터리가 폭발

여러 명이 협업하면 문제가 한 차원 더 커진다. A가 수정한 부분과 B가 수정한 부분이 충돌할 때 어떻게 합칠지, 누가 어떤 시점에 무엇을 바꿨는지 파악할 방법이 없다.

이런 문제들을 체계적으로 해결하기 위해 등장한 것이 버전 관리 시스템(VCS, Version Control System) 이다.

VCS의 진화

VCS는 크게 세 세대(Local / Centralized / Distributed)로 진화해왔다.

로컬 VCS

로컬 버전 관리

파일 복사 방식을 체계화한 첫 세대. 대표적으로 RCS는 파일 간 변경을 패치(patch) 형태로 저장하고, 이를 누적 적용해 특정 시점의 파일을 복원한다.

한계: 협업 불가능. 다른 사람과 같은 프로젝트를 공유할 방법이 없다.

중앙집중식 VCS (CVCS)

중앙집중식 버전 관리(CVCS)

CVS, Subversion, Perforce 등이 속한다. 모든 버전 관리 파일을 하나의 중앙 서버에 저장하고, 클라이언트들은 서버에서 파일을 체크아웃해 작업한다.

장점:

협업 참여자가 서로의 작업 상태를 파악할 수 있음
관리자가 권한을 세밀하게 제어 가능
개별 로컬 데이터베이스보다 중앙 서버 한 곳 관리가 단순

치명적 단점: 단일 실패 지점(Single Point of Failure). 중앙 서버가 멈추면 협업도 멈춘다. 하드디스크가 손상되고 백업이 없으면 전체 이력이 사라진다.

분산 VCS (DVCS)

분산 버전 관리 시스템(DVCS)

Git, Mercurial, Darcs 등이 속한다. 클라이언트가 최신 스냅샷만 받아오는 것이 아니라 저장소 전체를 통째로 복제한다.

핵심 결과:

모든 클론이 전체 데이터의 완전한 백업
서버 손실 시 클라이언트 중 하나로 복구 가능
여러 원격 저장소와 동시에 작업 가능 → 계층적 협업 모델 등 다양한 워크플로우 지원

Git의 데이터 모델 — Snapshots, Not Differences

Git과 다른 VCS의 가장 근본적인 차이는 데이터를 저장하는 방식이다.

델타 기반 (CVS·Subversion 등)

델타 기반 저장 방식 다이어그램

파일 세트 하나를 기준점으로 잡고, 시간이 흐르며 어떤 파일이 어떻게 변경됐는지 그 차이(delta)를 누적 기록한다.

스냅샷 기반 (Git)

스냅샷 기반 저장 방식 다이어그램

커밋할 때마다 그 시점의 전체 파일 상태를 통째로 저장한다. 효율을 위해 변경되지 않은 파일은 다시 저장하지 않고 이전 버전 링크만 남기지만, 개념상 매 커밋은 독립된 스냅샷이다.

Pro Git, 1장

Git은 단순한 버전 관리 시스템이 아니라, 작은 파일 시스템 위에 강력한 도구들이 얹혀진 구조다.

스냅샷 모델이 만들어내는 결과:

거의 모든 작업이 로컬에서 즉시 처리됨 — 히스토리 조회, diff, 과거 버전 비교 모두 네트워크 불필요. 오프라인에서도 커밋 가능
무결성 보장 — 모든 데이터는 SHA-1 해시로 체크섬된다. Git이 모르게 파일이 변경되는 일은 불가능
데이터 손실에 강함 — Git의 대부분 작업은 데이터를 추가(add)할 뿐이다. 커밋된 스냅샷은 매우 제거하기 어렵다

Three States

Three States 흐름 다이어그램

Git에서 파일은 세 가지 상태 중 하나에 있다.

상태	의미
Modified (수정됨)	파일 내용을 바꿨지만 아직 Git 데이터베이스에 커밋하지 않음
Staged (스테이징됨)	변경된 파일을 다음 커밋에 포함시키도록 표시함
Committed (커밋됨)	데이터가 로컬 Git 데이터베이스에 저장됨

이 세 상태는 Git 프로젝트의 세 가지 영역과 짝을 이룬다.

영역	역할
Working Directory	실제 파일들이 디스크에 풀려있는 곳. 사용자가 편집하는 공간
Staging Area (= "index")	다음 커밋에 들어갈 변경사항 목록. `.git` 내부 파일로 존재
Git Directory (`.git`)	메타데이터와 객체 데이터베이스. clone 시 함께 복사되는 부분

기본 작업 흐름

Working Directory에서 파일을 수정한다 → Modified
다음 커밋에 포함할 변경만 골라 Staging Area에 올린다 (git add) → Staged
커밋하면 Staging Area의 내용이 .git에 영구 저장된다 (git commit) → Committed

Staging Area의 역할

Git이 add와 commit을 분리한 이유는 커밋 단위를 사용자가 직접 큐레이션할 수 있게 하기 위함이다.

작업한 모든 변경을 통째로 커밋해야 한다면 — SVN처럼 — 커밋 히스토리는 "여러 작업이 섞인 덩어리"가 된다. Staging Area가 있으면 같은 작업 디렉터리 안에서도 A 변경은 첫 커밋, B 변경은 두 번째 커밋으로 분리할 수 있다.

이것이 Git을 단순 "버전 관리 도구"가 아니라 "히스토리 디자인 도구"로 만드는 차별점이다.

정리

버전 관리는 파일의 변경 이력을 기록해 복원·비교·추적·복구를 가능하게 하는 작업이며, 협업이 더해질 때 필수가 된다
VCS는 로컬 → 중앙집중 → 분산으로 진화해왔다 — 협업·복구·신뢰성 문제를 단계적으로 해결
Git은 변경 차이(delta)가 아니라 스냅샷을 저장한다 — 로컬 즉시 처리·무결성·데이터 손실 강건성의 기반
Three States(Modified/Staged/Committed) + 세 영역(Working/Staging/.git) — Git 명령어 대부분이 이 모델 안에서 영역 간 데이터 이동으로 해석된다

Custom Git Alias 목록

onebrotravel — Tue, 26 May 2026 17:45:57 +0900

Git을 자주 쓰다 보면 checkout, branch, status, commit 같은 명령어를 하루에도 수십 번씩 타이핑한다. 명령어가 길어서가 아니라, 반복 횟수 자체가 많으니 누적되는 피로가 꽤 된다.

Git에는 자주 쓰는 명령어를 짧은 별명으로 등록하는 alias 기능이 내장돼 있다. git config로 한 번 등록해두면 그 컴퓨터의 모든 저장소에서 단축 명령으로 작동한다.

이 글에서는 내가 실제로 사용 중인 alias 7개를 그대로 공유한다.

설정 목록

~/.gitconfig에 다음 7줄을 한 번씩 실행하면 모든 alias가 등록된다.

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.ci commit
git config --global alias.last 'log -1 HEAD --stat'
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

--global 플래그

--global을 붙이면 사용자 홈 디렉토리의 ~/.gitconfig에 기록되어 모든 저장소에서 작동한다. 특정 저장소에만 적용하고 싶다면 --global을 빼고 그 저장소 안에서 실행하면 된다. 그 경우 .git/config에 저장된다.

매일 쓰는 4개

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.ci commit

alias	원본	의미
`git co`	`git checkout`	브랜치 전환, 파일 복원
`git br`	`git branch`	브랜치 목록·생성·삭제
`git st`	`git status`	작업 디렉토리 상태
`git ci`	`git commit`	커밋 생성

단순히 git status 9타가 git st 5타로 줄어드는 것 같지만 의외로 체감이 많이 된다.

마지막 커밋 확인하기

git config --global alias.last 'log -1 HEAD --stat'

가장 최근 커밋 1개의 상세 정보(변경 파일 목록 + 라인 수)를 한 줄 명령으로 확인할 수 있다.

방금 무엇을 커밋했는지 빠르게 되돌아볼 때 유용하다. git log 전체를 띄우지 않아도 직전 작업 단위만 확인 가능.

풍성한 그래프 뷰

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

graph보다 정보량을 늘린 버전. --pretty=format: 안에서 색깔별로 의미를 구분한다:

색	토큰	표시
빨강	`%h`	짧은 커밋 해시
노랑	`%d`	브랜치/태그 ref
(기본)	`%s`	커밋 메시지
초록	`%cr`	상대 시간 (예: "3시간 전")
파랑	`%an`	저자명

git lg 실행 결과

`git log --graph`를 내가 원하는 정보를 포함해서 더 자주 볼 수 있게 개량한 것. 처음 보면 "이거 좀 과한데?" 싶지만 익숙해지면 한눈에 더 많은 정보가 들어온다.

마무리

여기 정리한 7개는 출발점일 뿐, alias는 본인이 자주 치는 명령일수록 강력해진다. 며칠 작업하면서 손이 가장 많이 가는 명령을 관찰해보고, 거기서부터 alias로 옮기면 자연스럽게 본인만의 단축 세트가 만들어진다.

~/.gitconfig를 직접 열어 [alias] 섹션을 편집해도 같은 효과다.

맵(Map)과 해시 테이블(Hash Table)

onebrotravel — Mon, 25 May 2026 19:03:58 +0900

맵(Map)은 키-값 쌍을 저장하는 추상 자료형(ADT)으로, 같은 키를 가진 쌍은 최대 하나만 존재합니다. 전화번호와 이름, 단어와 빈도수, 사용자 ID와 프로필처럼 "키로 값을 찾는" 모든 곳에 쓰입니다.

해시 테이블은 Map을 구현한 자료구조 중 가장 흔히 쓰이는 형태로, 해시 함수를 통해 키를 배열의 인덱스로 변환해 평균 $O(1)$ 시간에 데이터에 접근합니다. Python의 dict, Java의 HashMap, C++의 unordered_map이 모두 해시 테이블 기반입니다.

Hash table

핵심 개념

해시 함수(Hash Function): 키를 배열 인덱스로 변환하는 함수
버킷(Bucket): 해시 테이블의 각 슬롯
해시 충돌(Hash Collision): 서로 다른 키가 같은 인덱스로 해시되는 현상
로드 팩터(Load Factor): 저장된 원소 수 / 테이블 크기

해시 함수

좋은 해시 함수의 조건

균등 분포: 키들이 테이블 전체에 고르게 분산
빠른 계산: $O(1)$ 시간에 계산 가능
결정적: 같은 키는 항상 같은 값 반환

일반적인 해시 함수들

def division_hash(key, table_size):
    """나눗셈 해시"""
    return key % table_size

def multiplication_hash(key, table_size):
    """곱셈 해시"""
    A = 0.6180339887  # (√5 - 1) / 2
    return int(table_size * ((key * A) % 1))

def string_hash(s, table_size):
    """문자열 해시 (djb2 알고리즘)"""
    hash_value = 5381
    for char in s:
        hash_value = ((hash_value << 5) + hash_value) + ord(char)
    return hash_value % table_size

def polynomial_hash(s, table_size):
    """다항식 해시"""
    p = 31  # 소수
    hash_value = 0
    p_pow = 1
    for char in s:
        hash_value = (hash_value + ord(char) * p_pow) % table_size
        p_pow = (p_pow * p) % table_size
    return hash_value

참고 영상

해시 테이블의 동작 — 키-밸류 저장, 해시 충돌, 체이닝·선형 탐사, 리사이징 — 은 그림으로 보면 한 번에 잡힙니다.

맵(Map)과 해시 테이블(Hash Table) 핵심만 모아보기 (YouTube)

충돌 해결 방법

1. 개별 체이닝 (Separate Chaining)

Hash table chaining

같은 인덱스로 해시되는 키들을 연결 리스트로 묶어 한 버킷에 함께 저장합니다. 충돌이 발생해도 테이블 외부에 데이터를 매달 수 있어 로드 팩터가 1을 넘어도 동작하지만, 한 버킷의 리스트가 길어지면 검색 시간이 그만큼 늘어나는 것이 단점입니다.

class Node:
    """체이닝용 연결 리스트 노드"""
    def __init__(self, key, value):
        self.key = key
        self.value = value
        self.next = None
        
class HashTableChaining:
    def __init__(self, size=10):
        self.size = size
        self.table = [None] * size  # 각 슬롯이 연결 리스트의 head
        self.count = 0
        
    def _hash(self, key):
        """해시 함수"""
        if isinstance(key, str):
            return sum(ord(c) for c in key) % self.size
        return key % self.size
        
    def put(self, key, value):
        """키-값 쌍 삽입"""
        index = self._hash(key)
        node = self.table[index]
        
        # 기존 키가 있는지 확인
        while node is not None:
            if node.key == key:
                node.value = value  # 값 업데이트
                return
            node = node.next
            
        # 새 노드를 리스트 맨 앞에 삽입 (head insertion)
        new_node = Node(key, value)
        new_node.next = self.table[index]
        self.table[index] = new_node
        self.count += 1
        
    def get(self, key):
        """값 조회"""
        index = self._hash(key)
        node = self.table[index]
        while node is not None:
            if node.key == key:
                return node.value
            node = node.next
        raise KeyError(f"Key '{key}' not found")
        
    def delete(self, key):
        """키-값 쌍 삭제"""
        index = self._hash(key)
        node = self.table[index]
        prev = None
        
        while node is not None:
            if node.key == key:
                if prev is None:
                    self.table[index] = node.next  # 첫 번째 노드 삭제
                else:
                    prev.next = node.next
                self.count -= 1
                return node.value
            prev = node
            node = node.next
            
        raise KeyError(f"Key '{key}' not found")
        
    def load_factor(self):
        """로드 팩터 계산"""
        return self.count / self.size
        
    def display(self):
        """테이블 출력"""
        for i in range(self.size):
            node = self.table[i]
            if node is not None:
                items = []
                while node is not None:
                    items.append(f"({node.key}, {node.value})")
                    node = node.next
                print(f"Bucket {i}: {' -> '.join(items)}")

2. 개방 주소법 (Open Addressing)

충돌이 발생하면 같은 테이블 안에서 다른 빈 슬롯을 찾아 거기에 저장합니다. 외부 자료구조 없이 배열만으로 동작하지만, 로드 팩터가 1을 넘을 수 없고 데이터가 특정 영역에 뭉치는 클러스터링 문제가 생깁니다. 빈 슬롯을 찾아가는 방식(탐사 함수)에 따라 선형 탐사·이차 탐사·더블 해싱으로 나뉩니다.

선형 탐사 (Linear Probing)

Hash table linear probing

충돌이 일어난 인덱스의 바로 다음 칸(+1)부터 차례로 빈 슬롯을 찾습니다. 구현이 가장 간단하지만, 충돌이 모인 위치 주변에 데이터가 길게 늘어붙는 1차 클러스터링이 발생해 점점 검색이 느려집니다.

class HashTableLinearProbing:
    def __init__(self, size=10):
        self.size = size
        self.keys = [None] * size
        self.values = [None] * size
        self.count = 0

    def _hash(self, key):
        if isinstance(key, str):
            return sum(ord(c) for c in key) % self.size
        return key % self.size

    def _probe(self, key):
        """선형 탐사로 빈 슬롯 또는 키 위치 찾기"""
        index = self._hash(key)
        original_index = index
        while self.keys[index] is not None:
            if self.keys[index] == key:
                return index
            index = (index + 1) % self.size

            # 테이블이 가득 찬 경우
            if index == original_index:
                raise Exception("Hash table is full")
        return index

    def put(self, key, value):
        if self.count >= self.size:
            raise Exception("Hash table is full")
        index = self._probe(key)

        # 새로운 키인 경우
        if self.keys[index] is None:
            self.count += 1
        self.keys[index] = key
        self.values[index] = value

    def get(self, key):
        index = self._hash(key)
        original_index = index
        while self.keys[index] is not None:
            if self.keys[index] == key:
                return self.values[index]
            index = (index + 1) % self.size
            if index == original_index:
                break
        raise KeyError(f"Key '{key}' not found")

    def delete(self, key):
        index = self._hash(key)
        original_index = index
        while self.keys[index] is not None:
            if self.keys[index] == key:
                value = self.values[index]
                self.keys[index] = None
                self.values[index] = None
                self.count -= 1

                # 삭제 후 재해싱 (클러스터링 방지)
                self._rehash_after_delete(index)
                return value
            index = (index + 1) % self.size
            if index == original_index:
                break
        raise KeyError(f"Key '{key}' not found")

    def _rehash_after_delete(self, deleted_index):
        """삭제 후 클러스터링 해결을 위한 재해싱"""
        index = (deleted_index + 1) % self.size
        while self.keys[index] is not None:
            key_to_rehash = self.keys[index]
            value_to_rehash = self.values[index]
            self.keys[index] = None
            self.values[index] = None
            self.count -= 1
            self.put(key_to_rehash, value_to_rehash)
            index = (index + 1) % self.size

이차 탐사 (Quadratic Probing)

충돌 시 +1, +4, +9, +16... 처럼 제곱수만큼 떨어진 위치를 탐사합니다. 선형 탐사의 1차 클러스터링은 완화되지만, 같은 인덱스로 해시된 키들은 같은 경로를 따라가는 2차 클러스터링이 남습니다.

class HashTableQuadraticProbing:
    def __init__(self, size=10):
        self.size = size
        self.keys = [None] * size
        self.values = [None] * size
        self.count = 0

    def _hash(self, key):
        if isinstance(key, str):
            return sum(ord(c) for c in key) % self.size
        return key % self.size

    def _probe(self, key):
        """이차 탐사로 빈 슬롯 또는 키 위치 찾기"""
        index = self._hash(key)
        original_index = index
        i = 0
        while self.keys[index] is not None:
            if self.keys[index] == key:
                return index
            i += 1
            index = (original_index + i * i) % self.size

            # 무한 루프 방지
            if i >= self.size:
                raise Exception("Hash table is full or cannot find slot")
        return index

    def put(self, key, value):
        if self.count >= self.size:
            raise Exception("Hash table is full")
        index = self._probe(key)
        if self.keys[index] is None:
            self.count += 1
        self.keys[index] = key
        self.values[index] = value

더블 해싱 (Double Hashing)

두 번째 해시 함수의 결과만큼 점프하면서 탐사합니다. 키마다 점프 폭이 달라지기 때문에 1차·2차 클러스터링이 모두 줄어드는 대신, 해시 함수를 두 번 계산해야 하는 비용이 있습니다.

class HashTableDoubleHashing:
    def __init__(self, size=10):
        self.size = size
        self.keys = [None] * size
        self.values = [None] * size
        self.count = 0

    def _hash1(self, key):
        """첫 번째 해시 함수"""
        if isinstance(key, str):
            return sum(ord(c) for c in key) % self.size
        return key % self.size

    def _hash2(self, key):
        """두 번째 해시 함수"""
        if isinstance(key, str):
            hash_val = sum(ord(c) for c in key)
        else:
            hash_val = key
        return 7 - (hash_val % 7)  # 7은 테이블 크기보다 작은 소수

    def _probe(self, key):
        """더블 해싱으로 빈 슬롯 또는 키 위치 찾기"""
        index = self._hash1(key)
        step = self._hash2(key)
        original_index = index
        while self.keys[index] is not None:
            if self.keys[index] == key:
                return index
            index = (index + step) % self.size
            if index == original_index:
                raise Exception("Hash table is full")
        return index

    def put(self, key, value):
        if self.count >= self.size:
            raise Exception("Hash table is full")

        index = self._probe(key)
        if self.keys[index] is None:
            self.count += 1
        self.keys[index] = key
        self.values[index] = value

동적 리사이징

Hash table resize

데이터가 일정 비율 이상 차면(보통 로드 팩터 0.75 전후) 테이블 크기를 두 배로 늘리고 모든 원소를 새 크기에 맞춰 다시 해시합니다. 테이블이 좁아져서 충돌이 잦아지는 문제를 근본적으로 해결하는 방법이며, 충돌 해결 방식과 무관하게 함께 쓰입니다. 줄이는 방향도 가능해서 데이터가 빠진 뒤 일정 수준 이하가 되면 크기를 줄이기도 합니다.

class ResizableHashTable:
    def __init__(self, initial_size=8):
        self.size = initial_size
        self.table = [[] for _ in range(self.size)]
        self.count = 0

    def _hash(self, key):
        if isinstance(key, str):
            return sum(ord(c) for c in key) % self.size
        return key % self.size

    def _resize(self, new_size):
        """테이블 크기 조정"""
        old_table = self.table
        self.size = new_size
        self.table = [[] for _ in range(self.size)]
        old_count = self.count
        self.count = 0

        # 모든 원소를 새 테이블에 재삽입
        for bucket in old_table:
            for key, value in bucket:
                self.put(key, value)

    def put(self, key, value):
        # 로드 팩터가 0.75를 초과하면 크기 두 배로 증가
        if self.count / self.size > 0.75:
            self._resize(self.size * 2)
        index = self._hash(key)
        bucket = self.table[index]

        for i, (k, v) in enumerate(bucket):
            if k == key:
                bucket[i] = (key, value)
                return
        bucket.append((key, value))
        self.count += 1

    def delete(self, key):
        index = self._hash(key)
        bucket = self.table[index]

        for i, (k, v) in enumerate(bucket):
            if k == key:
                del bucket[i]
                self.count -= 1
                # 로드 팩터가 0.25 미만이면 크기 절반으로 감소
                if self.count / self.size < 0.25 and self.size > 8:
                    self._resize(self.size // 2)
                return v
        raise KeyError(f"Key '{key}' not found")

시간복잡도

연산	평균	최악
삽입	$O(1)$	$O(n)$
삭제	$O(1)$	$O(n)$
검색	$O(1)$	$O(n)$

활용 예시

1. 단어 빈도 계산

def word_frequency(text):
    word_count = {}
    words = text.lower().split()
    for word in words:
        word_count[word] = word_count.get(word, 0) + 1
    return word_count

text = "hello world hello python world"
print(word_frequency(text))  # {'hello': 2, 'world': 2, 'python': 1}

2. 두 수의 합 찾기

def two_sum(nums, target):
    """두 수의 합이 target인 인덱스 찾기"""
    num_to_index = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in num_to_index:
            return [num_to_index[complement], i]
        num_to_index[num] = i
    return []

nums = [2, 7, 11, 15]
target = 9
print(two_sum(nums, target))  # [0, 1]

3. 그룹 애너그램

def group_anagrams(strs):
    """애너그램끼리 그룹화"""
    anagram_groups = {}

    for s in strs:
        # 정렬된 문자열을 키로 사용
        key = ''.join(sorted(s))
        if key not in anagram_groups:
            anagram_groups[key] = []
        anagram_groups[key].append(s)

    return list(anagram_groups.values())

strs = ["eat", "tea", "tan", "ate", "nat", "bat"]
print(group_anagrams(strs))  # [['eat', 'tea', 'ate'], ['tan', 'nat'], ['bat']]

4. LRU 캐시 (해시 테이블 + 연결 리스트)

class Node:
    """이중 연결 리스트 노드"""
    def __init__(self, key=None, value=None):
        self.key = key
        self.value = value
        self.prev = None
        self.next = None
        
class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.cache = {}  # 해시 테이블: key -> Node
        
        # dummy head/tail로 경계 조건 단순화
        self.head = Node()
        self.tail = Node()
        self.head.next = self.tail
        self.tail.prev = self.head
        
    def _add_to_front(self, node):
        """노드를 head 직후에 삽입 (가장 최근)"""
        node.prev = self.head
        node.next = self.head.next
        self.head.next.prev = node
        self.head.next = node
        
    def _remove(self, node):
        """노드를 리스트에서 제거"""
        node.prev.next = node.next
        node.next.prev = node.prev
        
    def get(self, key):
        if key not in self.cache:
            return -1
        node = self.cache[key]
        # 최근 접근이므로 맨 앞으로 이동
        self._remove(node)
        self._add_to_front(node)
        return node.value
        
    def put(self, key, value):
        if key in self.cache:
            # 기존 키: 값 업데이트 + 맨 앞으로
            node = self.cache[key]
            node.value = value
            self._remove(node)
            self._add_to_front(node)
        else:
            # 새 키
            if len(self.cache) >= self.capacity:
                # 용량 초과: tail 직전 노드 (가장 오래된 것) 제거
                lru = self.tail.prev
                self._remove(lru)
                del self.cache[lru.key]
            new_node = Node(key, value)
            self.cache[key] = new_node
            self._add_to_front(new_node)

해시 테이블 vs 다른 자료구조

자료구조	검색 시간	삽입 시간	삭제 시간	메모리 사용량	순서 유지
해시 테이블	$O(1)$ avg	$O(1)$ avg	$O(1)$ avg	높음	없음
배열	$O(n)$	$O(n)$	$O(n)$	낮음	있음
연결 리스트	$O(n)$	$O(1)$	$O(1)$	중간	있음
이진 탐색 트리	$O(\log n)$	$O(\log n)$	$O(\log n)$	중간	있음

장단점

장점

빠른 연산: 평균 $O(1)$ 시간복잡도
유연한 키: 다양한 데이터 타입을 키로 사용 가능
동적 크기: 필요에 따라 크기 조정 가능
메모리 효율적: 필요한 만큼만 공간 사용

단점

순서 없음: 삽입 순서나 정렬 순서 보장 안됨
해시 충돌: 성능 저하 원인
메모리 오버헤드: 추가 공간 필요
최악의 경우: $O(n)$ 시간복잡도 가능

실제 활용 분야

데이터베이스: 인덱싱, 조인 연산
캐싱: 웹 캐시, CPU 캐시
컴파일러: 심볼 테이블, 변수 관리
네트워크: 라우팅 테이블, DNS
보안: 패스워드 저장, 체크섬
빅데이터: 분산 해싱, 샤딩

Map과 해시 테이블의 관계

Map은 ADT(Abstract Data Type)다. 키-값 매핑이라는 동작 인터페이스만 정의할 뿐, 어떻게 구현하는지는 명시하지 않는다. 해시 테이블은 그 Map을 구현한 데이터 구조이며, 트리 기반(Red-Black Tree 같은) 방식으로도 Map을 구현할 수 있다. 해시 테이블이 사실상 표준처럼 쓰이는 이유는 평균 O(1) 접근 성능이다. 다만 충돌 해결 방식은 언어마다 다르다 — Python의 dict는 개방 주소법, Java의 HashMap은 체이닝을 쓴다 (JDK 8부터는 한 버킷의 노드가 일정 수를 넘으면 Red-Black Tree로 전환한다).

우선순위 큐(Priority Queue)와 힙(Heap)

onebrotravel — Sun, 24 May 2026 22:36:38 +0900

우선순위 큐는 각 원소가 우선순위를 가지며, 높은 우선순위를 가진 원소가 먼저 처리되는 추상 자료형입니다. FIFO로 동작하는 일반 큐와 달리, 들어온 순서가 아니라 원소의 우선순위에 따라 꺼내는 점이 핵심입니다.

대부분 힙(Heap)이라는 자료구조로 구현하며, 운영체제의 프로세스 스케줄링, 다익스트라 같은 그래프 알고리즘, top-K 문제 등에서 핵심 역할을 합니다.

힙은 트리지만 배열로 저장된다 — 인덱스 공식으로 부모·자식 위치 계산

핵심 개념

FIFO 큐와 우선순위 큐의 출력 순서 차이 — 같은 입력에 다른 출력

우선순위 기반: 삽입 순서가 아닌 우선순위에 따라 처리
동적 정렬: 삽입과 삭제 시 우선순위 순서 유지
힙 구조: 일반적으로 힙(Heap)으로 구현
완전 이진 트리: 힙의 특성을 이용

주요 연산

insert(item, priority): 우선순위와 함께 원소 삽입
extract_max/min(): 최고/최저 우선순위 원소 제거 및 반환
peek(): 최고 우선순위 원소 조회 (제거하지 않음)
is_empty(): 큐가 비어있는지 확인
size(): 큐의 크기 반환

참고 영상

우선순위 큐와 힙의 개념과 차이, 사용 사례 (YouTube)

구현 방법

1. 파이썬 heapq 모듈 사용

import heapq

class PriorityQueue:
    def __init__(self):
        self.heap = []

    def insert(self, item, priority):
        # 파이썬 heapq는 최소 힙이므로 음수로 변환 (최대 힙 구현 시)
        heapq.heappush(self.heap, (priority, item))

    def extract_min(self):
        if self.is_empty():
            raise IndexError("Priority queue is empty")
        return heapq.heappop(self.heap)[1]

    def peek(self):
        if self.is_empty():
            raise IndexError("Priority queue is empty")
        return self.heap[0][1]

    def is_empty(self):
        return len(self.heap) == 0

    def size(self):
        return len(self.heap)

# 사용 예시
pq = PriorityQueue()
pq.insert("task1", 3)
pq.insert("task2", 1)
pq.insert("task3", 2)

print(pq.extract_min())  # "task2" (우선순위 1)
print(pq.extract_min())  # "task3" (우선순위 2)

2. 최대 힙 구현

import heapq

class MaxPriorityQueue:
    def __init__(self):
        self.heap = []

    def insert(self, item, priority):
        # 우선순위를 음수로 만들어 최대 힙 구현
        heapq.heappush(self.heap, (-priority, item))

    def extract_max(self):
        if self.is_empty():
            raise IndexError("Priority queue is empty")
        return heapq.heappop(self.heap)[1]

    def peek(self):
        if self.is_empty():
            raise IndexError("Priority queue is empty")
        return self.heap[0][1]

    def is_empty(self):
        return len(self.heap) == 0

3. 클래스 기반 우선순위 큐

import heapq

class Task:
    def __init__(self, name, priority):
        self.name = name
        self.priority = priority

    def __lt__(self, other):
        return self.priority < other.priority

    def __repr__(self):
        return f"Task({self.name}, {self.priority})"

class PriorityQueue:
    def __init__(self):
        self.heap = []

    def insert(self, task):
        heapq.heappush(self.heap, task)

    def extract_min(self):
        if self.is_empty():
            raise IndexError("Priority queue is empty")
        return heapq.heappop(self.heap)

    def is_empty(self):
        return len(self.heap) == 0

# 사용 예시
pq = PriorityQueue()
pq.insert(Task("urgent", 1))
pq.insert(Task("normal", 5))
pq.insert(Task("high", 2))

print(pq.extract_min())  # Task(urgent, 1)

4. 직접 힙 구현

heappush — 새 원소를 끝에 추가한 뒤 sift-up으로 적절한 위치까지 올라간다, heappop — root를 추출하고 마지막 원소를 root로 옮긴 뒤 sift-down으로 내려간다

class MaxHeap:
    def __init__(self):
        self.heap = []

    def parent(self, i):
        return (i - 1) // 2

    def left_child(self, i):
        return 2 * i + 1

    def right_child(self, i):
        return 2 * i + 2

    def insert(self, key):
        self.heap.append(key)
        self._heapify_up(len(self.heap) - 1)

    def extract_max(self):
        if not self.heap:
            raise IndexError("Heap is empty")
        max_val = self.heap[0]
        self.heap[0] = self.heap[-1]
        self.heap.pop()
        if self.heap:
            self._heapify_down(0)
        return max_val

    def _heapify_up(self, i):
        if i > 0 and self.heap[i] > self.heap[self.parent(i)]:
            self.heap[i], self.heap[self.parent(i)] = self.heap[self.parent(i)], self.heap[i]
            self._heapify_up(self.parent(i))

    def _heapify_down(self, i):
        largest = i
        left = self.left_child(i)
        right = self.right_child(i)
        if left < len(self.heap) and self.heap[left] > self.heap[largest]:
            largest = left
        if right < len(self.heap) and self.heap[right] > self.heap[largest]:
            largest = right
        if largest != i:
            self.heap[i], self.heap[largest] = self.heap[largest], self.heap[i]
            self._heapify_down(largest)

시간복잡도

삽입 (insert): $O(\log n)$
삭제 (extract): $O(\log n)$
조회 (peek): $O(1)$
힙 구성: $O(n \log n)$ 또는 $O(n)$ (heapify 사용 시)

활용 예시

1. 다익스트라 알고리즘

import heapq

def dijkstra(graph, start):
    distances = {node: float('inf') for node in graph}
    distances[start] = 0
    pq = [(0, start)]

    while pq:
        current_distance, current_node = heapq.heappop(pq)

        if current_distance > distances[current_node]:
            continue

        for neighbor, weight in graph[current_node].items():
            distance = current_distance + weight

            if distance < distances[neighbor]:
                distances[neighbor] = distance
                heapq.heappush(pq, (distance, neighbor))

    return distances

2. 작업 스케줄링

import heapq
from datetime import datetime, timedelta

class Job:
    def __init__(self, name, priority, deadline):
        self.name = name
        self.priority = priority
        self.deadline = deadline

    def __lt__(self, other):
        # 우선순위가 높을수록 먼저 (숫자가 작을수록 높은 우선순위)
        if self.priority != other.priority:
            return self.priority < other.priority
        # 우선순위가 같으면 마감일이 빠른 것부터
        return self.deadline < other.deadline

    def __repr__(self):
        return f"Job({self.name}, priority={self.priority})"

class JobScheduler:
    def __init__(self):
        self.jobs = []

    def add_job(self, job):
        heapq.heappush(self.jobs, job)

    def get_next_job(self):
        if self.jobs:
            return heapq.heappop(self.jobs)
        return None

# 사용 예시
scheduler = JobScheduler()
scheduler.add_job(Job("backup", 3, datetime.now() + timedelta(hours=2)))
scheduler.add_job(Job("urgent_fix", 1, datetime.now() + timedelta(minutes=30)))
scheduler.add_job(Job("maintenance", 2, datetime.now() + timedelta(hours=1)))
print(scheduler.get_next_job())  # Job(urgent_fix, priority=1)

3. 병합 정렬된 배열들

import heapq

def merge_k_sorted_arrays(arrays):
    heap = []
    result = []

    # 각 배열의 첫 번째 원소를 힙에 삽입
    for i, arr in enumerate(arrays):
        if arr:
            heapq.heappush(heap, (arr[0], i, 0))

    while heap:
        value, array_idx, element_idx = heapq.heappop(heap)
        result.append(value)

        # 다음 원소가 있으면 힙에 추가
        if element_idx + 1 < len(arrays[array_idx]):
            next_value = arrays[array_idx][element_idx + 1]
            heapq.heappush(heap, (next_value, array_idx, element_idx + 1))

    return result

# 사용 예시
arrays = [
    [1, 4, 7],
    [2, 5, 8],
    [3, 6, 9]
]

print(merge_k_sorted_arrays(arrays))  # [1, 2, 3, 4, 5, 6, 7, 8, 9]

4. 상위 K개 원소 찾기

import heapq

def find_k_largest(nums, k):
    # 최소 힙을 사용하여 크기 k 유지
    heap = []

    for num in nums:
        if len(heap) < k:
            heapq.heappush(heap, num)
        elif num > heap[0]:
            heapq.heapreplace(heap, num)

    return sorted(heap, reverse=True)

def find_k_smallest(nums, k):
    return heapq.nsmallest(k, nums)

# 사용 예시
nums = [3, 2, 1, 5, 6, 4]
print(find_k_largest(nums, 2))   # [6, 5]
print(find_k_smallest(nums, 2))  # [1, 2]

구현 방식 비교

구현 방식	삽입	삭제	조회	공간복잡도
정렬된 배열	$O(n)$	$O(1)$	$O(1)$	$O(n)$
정렬되지 않은 배열	$O(1)$	$O(n)$	$O(n)$	$O(n)$
연결 리스트	$O(n)$	$O(1)$	$O(n)$	$O(n)$
이진 힙	$O(log n)$	$O(log n)$	$O(1)$	$O(n)$
이진 탐색 트리	$O(log n)$	$O(log n)$	$O(log n)$	$O(n)$

힙의 종류

이진 힙 (Binary Heap): 가장 일반적, 완전 이진 트리
피보나치 힙 (Fibonacci Heap): 상수 시간 삽입, 병합
이항 힙 (Binomial Heap): 병합 연산에 최적화
d-ary 힙: 각 노드가 d개의 자식을 가짐

실제 활용 분야

운영체제: 프로세스 스케줄링
네트워크: 패킷 라우팅, QoS
게임: A* 알고리즘, 이벤트 시뮬레이션
그래프 알고리즘: 다익스트라, 프림 알고리즘
데이터 압축: 허프만 코딩
실시간 시스템: 태스크 관리

장단점

장점

우선순위 기반 효율적 처리
동적 정렬 유지
다양한 알고리즘의 핵심 구조
실시간 시스템에 적합

단점

일반 큐보다 복잡한 구현
추가 메모리 오버헤드
우선순위 변경이 어려움
순차 접근 불가능

우선순위 큐와 힙의 관계

우선순위 큐는 ADT(Abstract Data Type)다. 즉 "어떤 동작들이 있는지"만 정의할 뿐 구현은 명시하지 않는다. 반면 힙은 자료 구조다 — 구현까지 정해져 있다. 우선순위 큐를 구현하는 방법은 힙 외에도 정렬된 배열, 연결 리스트, 이진 탐색 트리 등 여러 가지가 있지만, 힙이 성능 균형이 가장 좋아 사실상 표준처럼 쓰인다.

정렬(Sorting) 알고리즘 6가지 — 원리·복잡도·선택 가이드

onebrotravel — Sun, 24 May 2026 20:10:56 +0900

정렬은 컴퓨터 과학에서 가장 기본적이면서도 가장 자주 다루는 문제다. 탐색·중복 제거·통계 처리 등 거의 모든 데이터 처리의 전처리 단계로 들어가기 때문에, 어떤 정렬을 언제 쓰는지 감을 잡아두는 것이 실전에서 중요하다.

이 글에서는 정렬을 분류하는 3가지 기준을 짚고, 대표적인 6가지 정렬 알고리즘을 원리·복잡도·구현까지 살펴본다. 마지막에 상황별 선택 가이드까지 정리한다.

정렬(Sorting)이란?

정의

데이터를 특정 순서(오름차순, 내림차순)로 재배열하는 과정
컴퓨터 과학에서 가장 기본적이고 중요한 알고리즘 중 하나
탐색, 데이터 처리의 전처리 단계로 활용

정렬의 분류

1. 안정성(Stability)

정렬 안정성은 같은 키를 가진 원소의 상대 순서가 유지되는지로 구분

안정(Stable): 같은 값의 원소들의 상대적 순서 유지
불안정(Unstable): 같은 값의 원소들의 순서가 바뀔 수 있음

2. 메모리 사용

제자리 정렬(In-place): 추가 메모리 $O(1)$ 사용
외부 정렬(Out-of-place): 추가 메모리 $O(n)$ 사용

3. 적응성(Adaptive)

적응적: 이미 정렬된 데이터에 대해 성능 향상
비적응적: 입력 상태와 무관하게 일정한 성능

주요 정렬 알고리즘

1. 버블 정렬(Bubble Sort)

1 pass에서 가장 큰 값이 인접 swap을 통해 끝까지 이동

원리

인접한 두 원소를 비교하고 교환
큰 값이 거품처럼 뒤로 이동

특징

시간 복잡도: $O(n²)$
공간 복잡도: $O(1)$
안정성: 안정
적응성: 적응적 (최선 $O(n)$)

장단점

장점: 구현 간단, 안정 정렬
단점: 성능 매우 느림

구현

# 버블 정렬 알고리즘 구현하기

from typing import MutableSequence

def bubble_sort(a: MutableSequence) -> None:
    """버블 정렬"""
    n = len(a)
    for i in range(n - 1):
        for j in range(n - 1, i, -1):
            if a[j - 1] > a[j]:
                a[j - 1], a[j] = a[j], a[j - 1]

# 버블 정렬 알고리즘 구현하기 (알고리즘의 개선 1)

from typing import MutableSequence

def bubble_sort(a: MutableSequence) -> None:
    """버블 정렬(교환 횟수에 따른 중단)"""
    n = len(a)
    for i in range(n - 1):
        exchng = 0
        for j in range(n - 1, i, -1):
            if a[j - 1] > a[j]:
                a[j - 1], a[j] = a[j], a[j - 1]
                exchng += 1
        if exchng == 0:
            break

# 버블 정렬 알고리즘 구현하기 (알고리즘의 개선 2)

from typing import MutableSequence

def bubble_sort(a: MutableSequence) -> None:
    """버블 정렬 (스캔 범위를 제한)"""
    n = len(a)
    k = 0
    while k < n - 1:
        last = n - 1
        for j in range(n - 1, k, -1):
            if a[j - 1] > a[j]:
                a[j - 1], a[j] = a[j], a[j - 1]
                last = j
        k = last

# 셰이커 정렬 알고리즘 구현하기

from typing import MutableSequence

def shaker_sort(a: MutableSequence) -> None:
    """셰이커 정렬"""
    left = 0
    right = len(a) - 1
    last = right
    while left < right:
        for j in range(right, left, -1):
            if a[j - 1] > a[j]:
                a[j - 1], a[j] = a[j], a[j - 1]
                last = j
        left = last

        for j in range(left, right):
            if a[j] > a[j + 1]:
                a[j], a[j + 1] = a[j + 1], a[j]
                last = j
        right = last

2. 선택 정렬(Selection Sort)

매 단계마다 미정렬 부분의 최솟값을 정렬 부분 끝으로

원리

매번 최솟값을 선택해서 앞쪽에 배치
정렬된 부분과 미정렬된 부분을 구분

특징

시간 복잡도: $O(n²)$
공간 복잡도: $O(1)$
안정성: 불안정
적응성: 비적응적

장단점

장점: 메모리 사용 최소, 교환 횟수 적음
단점: 성능 느림, 불안정

구현

# 단순 선택 정렬 알고리즘 구현하기

from typing import MutableSequence

def selection_sort(a: MutableSequence) -> None:
    """단순 선택 정렬"""
    n = len(a)
    for i in range(n - 1):
        min = i
        for j in range(i + 1, n):
            if a[j] < a[min]:
                min = j
        a[i], a[min] = a[min], a[i]

3. 삽입 정렬(Insertion Sort)

새 원소가 정렬된 부분의 적절한 자리에 끼워넣어진다

원리

각 원소를 정렬된 부분의 적절한 위치에 삽입
카드 정렬과 유사한 방식

특징

시간 복잡도: $O(n²)$ / 최선 $O(n)$
공간 복잡도: $O(1)$
안정성: 안정
적응성: 적응적

장단점

장점: 거의 정렬된 배열에 효율적, 안정 정렬
단점: 큰 데이터에 비효율적

구현

# 단순 삽입 정렬 알고리즘 구현하기

from typing import MutableSequence

def insertion_sort(a: MutableSequence) -> None:
    """단순 삽입 정렬"""
    n = len(a)
    for i in range(1, n):
        j = i
        tmp = a[i]
        while j > 0 and a[j - 1] > tmp:
            a[j] = a[j - 1]
            j -= 1
        a[j] = tmp

# 이진 삽입 정렬 알고리즘 구현하기

from typing import MutableSequence

def binary_insertion_sort(a: MutableSequence) -> None:
    """이진 삽입 정렬"""
    n = len(a)
    for i in range(1, n):
        key = a[i]
        pl = 0
        pr = i - 1

        while True:
            pc = (pl + pr) // 2
            if a[pc] == key:
                break
            elif a[pc] < key:
                pl = pc + 1
            else:
                pr = pc - 1
            if pl > pr:
                break

        pd = pc + 1 if pl <= pr else pr + 1

        for j in range(i, pd, -1):
            a[j] = a[j - 1]
        a[pd] = key

# 이진 삽입 정렬 알고리즘 구현 (bisect.insort 사용)

from typing import MutableSequence
import bisect

def binary_insertion_sort(a: MutableSequence) -> None:
    """이진 삽입 정렬 (bisect.insort 사용)"""
    for i in range(1, len(a)):
        bisect.insort(a, a.pop(i), 0, i)

# 셸 정렬 알고리즘 구현하기

from typing import MutableSequence

def shell_sort(a: MutableSequence) -> None:
    """셸 정렬"""
    n = len(a)
    h = n // 2
    while h > 0:
        for i in range(h, n):
            j = i - h
            tmp = a[i]
            while j >= 0 and a[j] > tmp:
                a[j + h] = a[j]
                j -= h
            a[j + h] = tmp
        h //= 2

# 셸 정렬 알고리즘 구현하기 (h * 3 + 1의 수열 사용)

from typing import MutableSequence

def shell_sort(a: MutableSequence) -> None:
    """셸 정렬 (h * 3 + 1의 수열 사용)"""
    n = len(a)
    h = 1

    while h < n // 9:
        h = h * 3 + 1

    while h > 0:
        for i in range(h, n):
            j = i - h
            tmp = a[i]
            while j >= 0 and a[j] > tmp:
                a[j + h] = a[j]
                j -= h
            a[j + h] = tmp
        h //= 3

참고 영상

Shell sort vs Insertion sort — 삽입 정렬에서 셸 정렬로 자연스럽게 확장되는 흐름을 시각화한 영상. gap 크기가 정렬 진행에 어떻게 작용하는지 한눈에 들어온다.

4. 병합 정렬(Merge Sort)

정렬 안정성은 같은 키를 가진 원소의 상대 순서가 유지되는지로 구분

원리

분할 정복 기법 사용
배열을 반으로 나누고 각각 정렬 후 병합

특징

시간 복잡도: $O(n \log n)$ — 모든 경우
공간 복잡도: $O(n)$
안정성: 안정
적응성: 비적응적

장단점

장점: 안정적인 $O(n \log n)$ 성능, 안정 정렬
단점: 추가 메모리 필요

구현

# 병합 정렬 알고리즘 구현하기

from typing import MutableSequence

def merge_sorted(a: MutableSequence) -> None:
    """병합 정렬"""


    def _merge_sort(a: MutableSequence, left: int, right: int) -> None:
        """a[left] ~ a[right]를 재귀적으로 병합 정렬"""
        if left < right:
            center = (left + right) // 2

            _merge_sort(a, left, center)
            _merge_sort(a, center + 1, right)

            p = j = 0
            i = k = left

            while i <= center:
                buff[p] = a[i]
                p += 1
                i += 1

            while i <= right and j < p:
                if buff[j] <= a[i]:
                    a[k] = buff[j]
                    j += 1
                else:
                    a[k] = a[i]
                    i += 1
                k += 1

            while j < p:
                a[k] = buff[j]
                k += 1
                j += 1

    n = len(a)
    buff = [None] * n
    _merge_sort(a, 0, n - 1)
    del buff

참고 영상

Merge Sort vs Quick Sort — 두 알고리즘을 같은 입력으로 나란히 시각 비교. 분할 정복의 직관과 두 알고리즘의 성능 차이를 한 번에 잡을 수 있다.

5. 퀵 정렬(Quick Sort)

피벗 기준 분할 후 좌·우 부분에 재귀 호출

원리

피벗(Pivot) 선택
피벗보다 작은 값은 왼쪽, 큰 값은 오른쪽으로 분할
재귀적으로 정렬

특징

시간 복잡도: 평균 $O(n \log n)$ / 최악 $O(n²)$
공간 복잡도: $O(\log n)$ — 재귀 스택
안정성: 불안정
적응성: 비적응적

장단점

장점: 평균적으로 가장 빠름, 제자리 정렬
단점: 최악의 경우 $O(n²)$, 불안정

구현

# 퀵 정렬 알고리즘 구현하기

from typing import MutableSequence

def qsort(a: MutableSequence, left: int, right: int) -> None:
    """a[left] ~ a[right]를 퀵 정렬"""
    pl = left
    pr = right
    x = a[(left + right) // 2]

    while pl <= pr:
        while a[pl] < x: pl += 1
        while a[pr] > x: pr -= 1
        if pl <= pr:
            a[pl], a[pr] = a[pr], a[pl]
            pl += 1
            pr -= 1

    if left < pr: qsort(a, left, pr)
    if pl < right: qsort(a, pl, right)

# 퀵 정렬 알고리즘 구현하기 (피벗 선택 개선: 3-중앙값)

from typing import MutableSequence

def sort3(a: MutableSequence, idx1: int, idx2: int, idx3: int):
    """a[idx1], a[idx2], a[idx3]을 오름차순으로 정렬하고 중앙값의 인덱스를 반환"""
    if a[idx2] < a[idx1]: a[idx2], a[idx1] = a[idx1], a[idx2]
    if a[idx3] < a[idx2]: a[idx3], a[idx2] = a[idx2], a[idx3]
    if a[idx2] < a[idx1]: a[idx2], a[idx1] = a[idx1], a[idx2]
    return idx2

def qsort(a: MutableSequence, left: int, right: int) -> None:
    """a[left] ~ a[right]를 퀵 정렬"""
    pl = left
    pr = right
    m = sort3(a, pl, (pl + pr) // 2, pr)
    x = a[m]

    a[m], a[pr - 1] = a[pr - 1], a[m]
    pl += 1
    pr -= 2
    while pl <= pr:
        while a[pl] < x: pl += 1
        while a[pr] > x: pr -= 1
        if pl <= pr:
            a[pl], a[pr] = a[pr], a[pl]
            pl += 1
            pr -= 1

    if left < pr: qsort(a, left, pr)
    if pl < right: qsort(a, pl, right)

def quick_sort(a: MutableSequence) -> None:
    """퀵 정렬"""
    qsort(a, 0, len(a) - 1)

참고 영상

Visualization of Quick sort (HD) — 피벗 선정과 좌우 분할 과정을 단순한 시각화로. 재귀가 어떻게 작은 부분 문제로 쪼개지는지 명확히 보인다.

6. 힙 정렬(Heap Sort)

힙의 root를 정렬 부분으로 옮기며 힙 크기를 줄여 나간다

원리

배열을 최대 힙으로 구성
루트(최댓값)를 맨 뒤로 이동
힙 크기를 줄이고 반복

특징

시간 복잡도: $O(n \log n)$ — 모든 경우
공간 복잡도: $O(1)$
안정성: 불안정
적응성: 비적응적

장단점

장점: 안정적인 $O(n \log n)$ 성능, 제자리 정렬
단점: 실제로는 퀵 정렬보다 느림, 불안정

구현

# 힙 정렬 알고리즘 구현하기

from typing import MutableSequence

def heap_sort(a: MutableSequence) -> None:
    """힙 정렬"""

    def down_heap(a: MutableSequence, left: int, right: int) -> None:
        """a[left] ~ a[right]를 힙으로 만들기"""
        temp = a[left]

        parent = left
        while parent < (right + 1) // 2:
            cl = parent * 2 + 1
            cr = cl + 1
            child = cr if cr <= right and a[cr] > a[cl] else cl
            if temp >= a[child]:
                break
            a[parent] = a[child]
            parent = child
        a[parent] = temp

    n = len(a)

    for i in range((n - 1) // 2, -1, -1):
        down_heap(a, i, n - 1)

    for i in range(n - 1, 0, -1):
        a[0], a[i] = a[i], a[0]
        down_heap(a, 0, i - 1)

참고 영상

Heaps and Heap sort — 힙 자료구조 자체부터 시작해 sift down, heapify, 힙 정렬까지 차근차근. 힙이 왜 정렬에 쓰이는지 단번에 이해된다.

정렬 알고리즘 비교표

n이 커질수록 $O(n²)$는 폭주, $O(n log n)$는 완만, $O(n)$는 거의 직선

알고리즘	최선	평균	최악	공간	안정성	적응성
버블 정렬	$O(n)$	$O(n²)$	$O(n²)$	$O(1)$	안정	적응적
선택 정렬	$O(n²)$	$O(n²)$	$O(n²)$	$O(1)$	불안정	비적응적
삽입 정렬	$O(n)$	$O(n²)$	$O(n²)$	$O(1)$	안정	적응적
병합 정렬	$O(n \log n)$	$O(n \log n)$	$O(n \log n)$	$O(n)$	안정	비적응적
퀵 정렬	$O(n \log n)$	$O(n \log n)$	$O(n²)$	$O(\log n)$	불안정	비적응적
힙 정렬	$O(n \log n)$	$O(n \log n)$	$O(n \log n)$	$O(1)$	불안정	비적응적

참고 영상

Insertion Sort vs Bubble Sort + Some analysis — 버블·삽입·퀵의 비교 횟수를 차트로 분석. $N^2/2$ vs $N^2/4$ vs $N \log N$의 차이가 시각으로 와닿는다.

고급 정렬 알고리즘

1. 계수 정렬(Counting Sort)

비교 기반이 아닌 정렬
값의 범위가 제한적일 때 사용
시간 복잡도: $O(n + k)$ ($k$는 값의 범위)
공간 복잡도: $O(k)$

구현

# 도수 정렬 알고리즘 구현하기

from typing import MutableSequence

def fsort(a: MutableSequence, max: int) -> None:
    """도수 정렬(배열 원솟값은 0 이상 max 이하)"""
    n = len(a)
    f = [0] * (max + 1)
    b = [0] * n

    for i in range(n):              f[a[i]] += 1
    for i in range(1, max + 1):     f[i] += f[i - 1]
    for i in range(n - 1, -1, -1):  f[a[i]] -= 1; b[f[a[i]]] = a[i]
    for i in range(n):              a[i] = b[i]

def counting_sort(a: MutableSequence) -> None:
    """도수 정렬"""
    fsort(a, max(a))

참고 영상

Visualization of Radix sort — 계수 정렬(pigeon hole), LSD·MSD 기수 정렬, 그리고 안정 정렬(stable) 개념까지 한 영상에. 자릿수별 정렬이 어떻게 누적되어 최종 정렬이 되는지 직관적으로 보여준다.

2. 기수 정렬(Radix Sort)

자릿수별로 정렬
계수 정렬을 여러 번 적용
시간 복잡도: $O(d \times (n + k))$ ($d$는 자릿수)

3. 팀 정렬(Tim Sort)

병합 정렬과 삽입 정렬의 하이브리드
실제 데이터의 부분적 정렬 활용
Python, Java의 기본 정렬 알고리즘

정렬 알고리즘 선택 가이드

상황별로 4가지 결정 기준 — n 크기 → 안정성 → 메모리 → 최악 보장

1. 데이터 크기가 작을 때 ($n < 50$)

삽입 정렬 추천
구현 간단, 작은 데이터에 효율적

2. 안정성이 중요할 때

병합 정렬 또는 팀 정렬
동일한 값의 순서 유지 필요

3. 메모리가 제한적일 때

힙 정렬 또는 퀵 정렬
제자리 정렬로 메모리 사용 최소화

4. 평균 성능이 중요할 때

퀵 정렬 또는 팀 정렬
실제 환경에서 가장 빠른 성능

5. 최악의 경우 성능 보장이 필요할 때

병합 정렬 또는 힙 정렬
항상 $O(n \log n)$ 성능 보장

실제 구현에서의 고려사항

1. 하이브리드 정렬

큰 데이터: 퀵 정렬
작은 데이터: 삽입 정렬
최악의 경우: 힙 정렬로 전환

2. 피벗 선택 전략

중간값의 중간값 (Median-of-3)
랜덤 피벗 선택
듀얼 피벗 퀵 정렬

3. 캐시 효율성

지역성 원리 활용
메모리 접근 패턴 최적화

정리

비교 기반 정렬의 이론적 하한: $O(n \log n)$
실제 성능: 상수 팩터, 캐시 효율성도 중요
상황에 맞는 알고리즘 선택이 핵심
하이브리드 접근법이 실제 구현에서 효과적

참고 자료

위에서 인용한 영상들은 모두 같은 시리즈로, "short-sighted robot"이 정렬을 수행하는 시각화다. 정렬 알고리즘 전반을 시각으로 정리하고 싶다면 시리즈 6편을 묶어서 보는 것을 추천한다.

라즈베리파이에 셀프호스팅한 n8n으로 매일 아침 뉴스 요약 받기

onebrotravel — Thu, 21 May 2026 14:32:13 +0900

들어가며

이전 글에서 라즈베리파이에 n8n을 셀프 호스팅했다. 이번 글에서는 n8n으로 간단한 워크플로우를 구성하는 과정을 정리한다.

매일 아침 네이버 경제 뉴스를 확인하는데, 매번 네이버에 접속해서 기사를 하나하나 클릭하는 과정이 번거로웠다. AI가 기사를 요약해서 Slack으로 보내준다면 이 과정을 줄일 수 있을 거라고 생각했다.

전체 구조

n8n 워크플로우 전체 노드 구성도

워크플로우의 전체 흐름은 다음과 같다.

Schedule Trigger (매일 09:00)
  -> HTTP Request (네이버 경제 뉴스 페이지 크롤링)
    -> HTML (헤드라인 + 링크 추출)
      -> Code (상위 10개 기사 선택)
        -> Loop Over Items (기사별 반복)
          -> HTTP Request (개별 기사 본문 크롤링)
            -> Wait (1초 대기)
              -> HTML (본문 + 제목 + URL 추출)
        -> Aggregate (10개 기사 데이터 합치기)
          -> OpenAI (GPT로 요약)
            -> Slack (채널에 메시지 전송)

총 11개 노드로 구성되어 있고, 크게 네 단계로 나눌 수 있다.

단계	설명	사용 노드
1. 뉴스 목록 수집	네이버 경제 섹션에서 헤드라인과 링크 추출	Schedule Trigger, HTTP Request, HTML, Code
2. 개별 기사 크롤링	10개 기사의 본문을 하나씩 가져오기	Loop Over Items, HTTP Request, Wait, HTML
3. LLM 요약	수집한 본문을 GPT에 넘겨 구조화된 요약 생성	Aggregate, OpenAI
4. 슬랙 전송	요약 결과를 슬랙 채널에 전송	Slack

1. 뉴스 목록 수집

Schedule Trigger

Schedule Trigger 노드 설정 화면 — 매일 09:00 실행

워크플로우의 시작점이다. 매일 아침 9시에 자동으로 실행되도록 설정했다.

HTTP Request - 뉴스 페이지 가져오기

HTTP Request 노드 — 네이버 뉴스 경제 섹션 GET 요청 설정

네이버 뉴스 경제 섹션의 HTML을 가져온다.

설정	값
Method	GET
URL	`https://news.naver.com/section/101`

HTML - 헤드라인과 링크 추출

HTML 노드 — 헤드라인/링크 CSS 셀렉터 설정 화면

가져온 HTML에서 CSS 셀렉터로 기사 제목과 링크를 배열로 추출한다.

추출 대상	CSS Selector	반환 형태
헤드라인	`.sa_text_title`	배열 (텍스트)
링크	`.sa_text_title`	배열 (href 속성)

Code - 상위 10개 기사 선택

Code 노드 — 상위 10개 기사 추출 JavaScript

HTML 노드에서 추출한 배열을 받아 상위 10개만 잘라내고, 각각을 개별 아이템으로 변환한다. n8n에서 반복 처리를 하려면 데이터가 개별 아이템 형태여야 한다.

const headlines = $input.first().json.headlines;
const links = $input.first().json.links;

const articles = [];
const limit = Math.min(10, headlines.length);

for (let i = 0; i < limit; i++) {
  articles.push({
    json: {
      index: i + 1,
      title: headlines[i],
      link: links[i]
    }
  });
}

return articles;

이 시점에서 { index, title, link } 형태의 아이템 10개가 만들어진다.

2. 개별 기사 크롤링

Loop Over Items

Loop 노드 설정 화면 — Done/Loop 출력

n8n의 Split In Batches 노드로 10개 기사를 하나씩 순회한다. 이 노드는 두 개의 출력을 가진다.

출력	조건	다음 노드
Done	모든 아이템 처리 완료	Aggregate
Loop	아직 처리할 아이템 있음	HTTP Request

HTTP Request - 기사 본문 가져오기

HTTP Request 노드 — User-Agent/Accept-Language 헤더 설정

각 기사 URL로 접근해서 본문 HTML을 가져온다. User-Agent와 Accept-Language 헤더를 설정해야 정상적인 응답을 받을 수 있다.

헤더	값
User-Agent	`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36`
Accept-Language	`ko-KR,ko;q=0.9`

헤더 누락 시

헤더 없이 요청하면 네이버가 봇으로 인식해서 정상적인 HTML 대신 에러 페이지를 반환할 수 있다.

Wait - 1초 대기

Wait 노드 — 1초 대기 설정 화면

차단 위험

기사를 연속으로 요청하면 서버에서 차단당할 수 있다. 1초 간격을 두어 네이버 서버에 부담을 주지 않도록 했다.

HTML - 본문 데이터 추출

HTML 노드 — 본문/제목/URL CSS 셀렉터 설정 화면

각 기사 페이지에서 필요한 정보를 CSS 셀렉터로 추출한다.

추출 대상	CSS Selector	설명
본문	`#newsct_article`	기사 전문 텍스트
제목	`h2#title_area span`	기사 제목
URL	`meta[property="og:url"]` (content 속성)	기사 원문 링크

추출이 끝나면 다시 Loop 노드로 돌아가서 다음 기사를 처리한다.

3. LLM 요약

Aggregate

Aggregate 노드 설정 화면 — 10개 아이템을 배열로 합치기

10개 기사 크롤링이 모두 끝나면 Loop의 Done 출력으로 넘어온다. Aggregate 노드는 개별 아이템 10개를 하나의 배열로 합쳐준다. GPT에 한 번에 넘기기 위한 전처리다.

OpenAI - GPT로 요약

OpenAI 노드 설정 화면 — 프롬프트 및 모델 설정

합쳐진 10개 기사 데이터를 GPT에 전달한다. 프롬프트는 다음과 같이 구성했다.

당신은 전문 경제 뉴스 분석가입니다.
아래는 오늘의 네이버 경제 헤드라인 뉴스 10개의 전문(본문)입니다.

각 기사를 자세히 읽고 다음 형식으로 심층 요약해주세요:

##   [기사 번호] 기사 제목
-   핵심 내용: 기사의 핵심 사실 2-3줄로 요약
-   시사점: 이 뉴스가 경제/시장에 미치는 영향
-   관련 키워드: 핵심 키워드 2-3개
-   원문 링크: 기사 원문 URL

---

마지막에   오늘의 경제 트렌드 종합 섹션을 추가하여
10개 기사를 종합한 오늘의 경제 동향을 3-4줄로 분석해주세요.

기사 데이터는 n8n의 Expression 문법으로 동적 주입한다.

{{ $json.data.map((item, i) => 
  `[기사 ${i+1}]\n${item.body}\n  원문: ${item.link}`
).join('\n\n---\n\n') }}

gpt-5-nano 모델 선택

모델 선택

사용한 모델은 gpt-5-nano다. 높은 성능이 필요하지 않은 간단한 요약 작업이면서 매일 실행되는 워크플로우인 만큼 비용을 고려해서 가벼운 모델을 선택했다.

4. 슬랙 전송

Slack 노드 설정 화면 — 채널 및 메시지 내용 설정

GPT의 응답을 슬랙 채널로 전송한다.

설정	값
채널	`news`
메시지 내용	`{{ $json.output[0].content[0].text }}`

슬랙 채널에 도착한 뉴스 요약 메시지 캡처

이제 매일 아침 9시에 슬랙을 열면 경제 뉴스 10개의 요약이 정리되어 있다.

API 설정

OpenAI API 키 설정

ChatGPT를 이용하기 위해서는 API 키를 설정해 주어야 한다.

우선 여기에서 API key를 설정한 후 n8n에서 아래 사진과 같이 credential을 설정해주면 된다.

n8n OpenAI credential 등록 화면

Slack API 설정

참고 영상

Slack API 연결은 생각 외로 복잡하고 시간이 꽤 걸리는 작업이었다. 여기에서 설명하기보다는 내가 참고했던 영상 링크를 남긴다.

개선 아이디어

지금은 기본적인 뉴스 요약만 하고 있지만, 확장할 수 있는 방향이 몇 가지 있다.

경제(101) 외에 정치(100), IT/과학(105) 등 다른 섹션 추가
특정 키워드가 포함된 기사만 별도 알림
요약 결과를 Notion이나 Google Sheets에 저장해서 트렌드 추적
긍정/부정 감성 분석 추가

마치며

n8n으로 첫 번째 워크플로우를 만들었다. 정리하면:

HTTP Request + HTML 노드로 네이버 뉴스 크롤링
Split In Batches + Wait으로 개별 기사 안정적으로 수집
OpenAI 노드로 GPT 요약 생성
Slack 노드로 매일 아침 자동 전송

라즈베리파이에 n8n 셀프 호스팅하기

onebrotravel — Wed, 20 May 2026 20:18:39 +0900

들어가며

이전 글에서 라즈베리파이 5 초기 설정을 마쳤다. 이번 글에서는 Docker를 설치하고 n8n을 셀프 호스팅하는 과정을 정리한다.

n8n은 노코드 워크플로우 자동화 도구다. Zapier나 Make와 비슷하지만, 셀프 호스팅이 가능해서 비용 부담 없이 사용할 수 있다.

Docker 설치

1. 시스템 업데이트

sudo apt update && sudo apt upgrade -y

2. Docker 설치

공식 설치 스크립트를 사용하면 간단하게 설치할 수 있다.

curl -fsSL https://get.docker.com | sh

3. 현재 사용자를 docker 그룹에 추가

기본적으로 docker 명령어는 root 권한이 필요하다. 매번 sudo를 입력하지 않으려면 현재 사용자를 docker 그룹에 추가한다.

sudo usermod -aG docker $USER

4. 재로그인

그룹 변경 사항을 적용하려면 SSH 연결을 끊고 다시 접속해야 한다.

exit

다시 SSH로 접속한 후 현재 사용자가 docker 그룹에 추가되었는지, Docker가 정상 작동하는지 확인한다.

groups

docker --version

버전 정보가 출력되면 설치 완료다.

n8n 설치

1. 프로젝트 폴더 생성

docker-compose.yml 파일을 저장할 폴더를 만든다.

mkdir -p ~/_projects/n8n
cd ~/_projects/n8n

2. docker-compose.yml 작성

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - GENERIC_TIMEZONE=Asia/Seoul
      - TZ=Asia/Seoul
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

주요 설정:

127.0.0.1:5678:5678: localhost에서만 접속 가능 (외부 직접 접속 차단)
GENERIC_TIMEZONE, TZ: 타임존을 서울로 설정
n8n_data: 워크플로우 데이터를 Docker 볼륨에 저장

3. n8n 실행

docker compose up -d

-d 옵션은 백그라운드 실행이다. 컨테이너 상태를 확인하려면:

docker ps

n8n 컨테이너가 실행 중이면 성공이다.

n8n 접속

문제: Secure Cookie 에러

처음에 http://라즈베리파이IP:5678로 접속하니 다음 에러가 나왔다.

Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari.

n8n은 기본적으로 HTTPS 접속을 요구한다. HTTP로 접속하면 보안 쿠키 문제로 로그인이 안 된다.

해결 방법들

Secure Cookie 에러를 해결하는 방법은 크게 세 가지로 나눌 수 있다.

1. HTTPS 설정

실제로 HTTPS를 적용하는 방법이다. 외부에서 n8n에 접속하거나, GitHub/Stripe 같은 외부 서비스의 웹훅을 받아야 한다면 이 방법을 사용해야 한다.

방법	난이도	요구사항
Cloudflare Tunnel	⭐ 쉬움	도메인 필요 (무료 도메인 가능)
Tailscale	⭐ 쉬움	계정만 있으면 됨
Nginx + Let's Encrypt	⭐⭐ 보통	도메인 + 포트포워딩
Traefik	⭐⭐⭐ 복잡	도메인 + 포트포워딩

2. 보안 기능 비활성화

n8n의 Secure Cookie 기능 자체를 끄는 방법이다.

방법	난이도	요구사항
N8N_SECURE_COOKIE=false	⭐ 쉬움	없음

docker-compose.yml의 environment에 추가하면 된다. 간단하지만 보안 기능을 끄는 것이므로 권장하지 않는다.

3. SSH 터널링

localhost로 접속해서 Secure Cookie 검사를 우회하는 방법이다.

방법	난이도	요구사항
SSH 터널링	⭐ 쉬움	SSH 접속 가능

보안 기능을 유지하면서 추가 설정 없이 사용할 수 있다.

내 상황

나는 집 안 로컬 네트워크에서만 n8n에 접속한다. 외부에서 접속할 일이 없으니 HTTPS 설정까지는 필요 없었다.

왜 SSH 터널링인가?

N8N_SECURE_COOKIE=false로 설정하면 가장 간단하지만, 보안 기능을 끄는 것이라 찝찝했다. SSH 터널링은 보안 기능을 유지하면서도 추가 설정 없이 바로 사용할 수 있어서 선택했다.

SSH 터널링으로 접속하기

데스크탑에서 다음 명령어를 실행한다. (Git Bash 또는 터미널)

ssh -L 5678:localhost:5678 사용자이름@라즈베리파이IP

이 명령어는:

데스크탑의 localhost:5678을
라즈베리파이의 localhost:5678로 연결한다

SSH 연결이 유지된 상태에서 브라우저로 접속한다.

http://localhost:5678

localhost로 접속하면 n8n이 HTTPS로 인식해서 Secure Cookie 에러가 발생하지 않는다.

왜 127.0.0.1로 바인딩했나?

docker-compose.yml에서 포트를 127.0.0.1:5678:5678로 설정한 이유는 보안 때문이다.

설정	접속 범위
`5678:5678`	같은 네트워크의 모든 기기에서 접속 가능
`127.0.0.1:5678:5678`	라즈베리파이 자체에서만 접속 가능

SSH 터널링을 통해서만 접속할 수 있게 하면, 같은 네트워크에 있는 다른 기기에서 임의로 접속하는 것을 막을 수 있다.

마치며

라즈베리파이에 n8n 셀프 호스팅을 완료했다. 정리하면:

Docker 공식 스크립트로 설치
docker-compose.yml로 n8n 컨테이너 실행
SSH 터널링으로 Secure Cookie 문제 해결
127.0.0.1 바인딩으로 외부 직접 접속 차단

셀프 호스팅의 장점

n8n은 클라우드 버전도 있지만, 셀프 호스팅하면 몇 가지 장점이 있다.

항목	클라우드	셀프 호스팅
비용	월 $24~ (Starter 기준)	무료
실행 횟수	플랜별 제한	무제한
데이터 저장	n8n 서버	내 라즈베리파이
커스터마이징	제한적	자유로움

라즈베리파이는 저전력으로 24시간 구동이 가능하니, 개인용 자동화 서버로 딱 맞는 조합이다.

다음 글에서는 이렇게 구축한 n8n으로 실제 자동화 워크플로우를 만들어본다.

라즈베리파이 5 초기 설정 가이드

onebrotravel — Wed, 20 May 2026 17:36:26 +0900

들어가며

1년 전 C언어 공부를 하면서 native Linux 환경을 경험해보고 싶어서 라즈베리파이를 구매했다. 당시에는 잠깐 사용하다가 서랍 속에 넣어뒀는데, 최근 n8n으로 자동화 워크플로우를 구성하면서 다시 꺼내게 됐다.

n8n 워크플로우는 24시간 돌아가야 하는데, 데스크탑을 하루 종일 켜놓을 수는 없었다. 클라우드 서버를 사용하면 비용이 발생하기 때문에, 전기세 빼면 추가 비용 없이 사용할 수 있는 라즈베리파이가 생각났다. 저전력으로 24시간 구동이 가능하니 딱 맞는 용도였다.

이 글에서는 라즈베리파이 5 초기 설정 과정을 정리한다.

준비물

항목	사용 제품
본체	Raspberry Pi 5 8GB
저장장치	microSD 카드 256GB
기타	모니터, 키보드, 유선 랜 케이블 (초기 설정용)

OS 설치

1. Raspberry Pi Imager 다운로드

공식 사이트에서 Raspberry Pi Imager를 다운로드한다.

2. OS 선택

Raspberry Pi Imager를 실행하고 다음을 선택한다.

Device: Raspberry Pi 5
OS: Raspberry Pi OS (64-bit) - Debian Trixie with Desktop
Storage: microSD 카드

Device 선택 화면 - Raspberry Pi 5 선택/ OS 선택 화면 - Raspberry Pi OS (64-bit) 선택/ Storage 선택 화면 - SD 카드 선택

3. 설정 커스터마이징

OS 설치 전 설정을 미리 지정할 수 있다.

설정 커스터마이징 화면

호스트 이름
사용자 이름 / 비밀번호
로케일 (Asia/Seoul)
SSH 활성화 옵션(선택)

4. 쓰기

Write 완료 화면

"Write" 버튼을 누르면 OS가 SD 카드에 설치된다.

초기 부팅 및 설정

1. 첫 부팅

SD 카드를 라즈베리파이에 삽입하고 전원을 연결한다. 모니터와 키보드를 연결한 상태로 부팅한다.

라즈베리파이 데스크탑 첫 화면

2. 네트워크 연결

처음에 와이파이로 연결하려 했는데 잘 잡히지 않았다. 유선 랜 케이블을 연결하니 바로 인터넷에 연결됐다.

팁

와이파이 연결이 불안정하다면 초기 설정은 유선 랜으로 진행하는 걸 추천한다.

3. IP 주소 확인

터미널에서 IP 주소를 확인한다.

hostname -I

터미널에서 hostname -I 실행 결과

이 IP 주소로 SSH 접속할 예정이다.

SSH 설정

1. SSH 활성화

라즈베리파이에서 SSH를 활성화한다.

sudo raspi-config

Interface Options → SSH → Enable

2. RSA 키 생성 (데스크탑에서)

데스크탑에서 SSH 키를 생성한다.

ssh-keygen -t rsa -b 4096

3. 공개 키 복사

생성된 공개 키를 라즈베리파이에 복사한다.

ssh-copy-id 사용자이름@라즈베리파이IP

4. 접속 확인

비밀번호 없이 SSH 접속이 되는지 확인한다.

ssh 사용자이름@라즈베리파이IP

SSH 접속 성공 화면 - 비밀번호 입력 없이 접속됨

주의

IP 주소와 게이트웨이는 자신의 네트워크 환경에 맞게 수정한다.

VS Code로 원격 개발 환경 구성

SSH 연결 후에는 VS Code의 Remote - SSH 확장을 사용하면 편하게 작업할 수 있다.

VS Code에서 Remote - SSH 확장 설치

VS Code Extensions에서 Remote - SSH 검색/설치 화면

F1 → "Remote-SSH: Connect to Host"

Command Palette에서 Remote-SSH: Connect to Host 선택

사용자이름@라즈베리파이IP 입력

호스트 입력 화면

연결 완료

VS Code 좌측 하단에 SSH: 라즈베리파이 연결됨 표시

이제 데스크탑에서 라즈베리파이 파일을 직접 편집할 수 있다.

마치며

라즈베리파이 5 초기 설정을 마쳤다. 정리하면:

Raspberry Pi Imager로 OS 설치
유선 랜으로 네트워크 연결
RSA 키로 SSH 설정
고정 IP 설정
VS Code Remote로 원격 개발 환경 구성

다음 글에서는 이렇게 세팅한 라즈베리파이에 Docker를 설치하고 n8n을 셀프 호스팅하는 과정을 다룬다.

[크래프톤 정글 10기] 나만무 프로젝트 회고 (4)

onebrotravel — Tue, 19 May 2026 22:47:05 +0900

들어가며

3편에서는 워크플로우 빌더의 포트 시스템이 어떻게 만들어졌다가 사라졌는지, 그리고 재설계를 분석한 경험을 다뤘다.

4편에서는 5주간의 프로젝트를 돌아보며 시리즈를 마무리하려 한다.

5주간의 회고
팀 협업 이야기
기술적 회고
이후 계획

5주간의 회고

잘한 점: 공통의 목표

5주간 우리 팀이 잘했던 건 "출시할 수 있는 프로덕트 완성"이라는 목표를 끝까지 놓지 않은 것이다.

나만무 프로젝트 특성상 개인의 성장이나 취업을 위한 기술 스택에 집중하기 쉽다. 물론 중요한 부분이지만, 그것에만 매몰되면 작은 기능에 복잡한 기술을 적용하는 오버엔지니어링으로 이어질 수 있다. 잘못하면 결과물 없이 프로젝트가 끝나는 상황도 생길 수 있다. 실제로 이전 기수에는 일정 내에 프로덕트가 완성되지 않아 발표를 하지 못하고 부트캠프를 마무리 했던 팀도 있었다고 들었다. 우리 팀은 방향이 흔들릴 때마다 "일단 출시할 수 있는 상태로 만들자"를 상기시켰다.

이게 나만무 프로젝트를 완주할 수 있었던 이유였다고 생각한다.

아쉬운 점: 구현하지 못한 기능들

시간이 더 있었다면 추가하고 싶었던 기능들이 있다.

워크플로우를 코드로 변환해서 배포: 사용자가 만든 워크플로우를 Python 코드로 export하는 기능
셀프 호스트 배포: n8n처럼 Docker image로 배포해서 사용자가 직접 호스팅할 수 있는 방식

둘 다 기획 단계에서 논의됐지만, 5주라는 시간 안에 핵심 기능을 완성하는 것만으로도 빠듯했다. 다음에 비슷한 프로젝트를 한다면 초기 기획 단계에서 스코프를 더 명확하게 잡아야겠다는 생각이 들었다.

팀 협업 이야기

5주차의 갈등

프로젝트를 진행하면서 있었던 갈등에 대해서 이야기 해 보자면, 5주차 최종 발표 전, 마지막 리허설 이틀 전에 한 팀원이 기능 추가를 제안했다.

그러나 나는 현재 구현된 내용만으로도 충분히 최종 발표가 가능하다고 판단했다. 게다가 발표 PPT 제작, 포스터 세션용 포스터 제작 등 구현 외적인 일도 남아있는 상태라서 이 부분을 마무리하는 게 더 중요하다고 생각했다. 혹시라도 일정을 맞추지 못하는 상황이 생길까 봐 걱정됐기 때문이다.

반면 팀원은 프로덕트의 퀄리티와 발표의 퍼포먼스를 위해 추가 기능 구현이 필요하다고 주장했다.

해결 방식

결국 팀장이 두 일을 병렬로 처리하자고 결정했다.

기능 구현을 주장한 팀원은 추가 기능 개발을 진행
나머지는 그 기능이 없다고 가정하고 발표 시나리오, PPT, 포스터를 준비

기능 구현이 완료되지 않아도 발표를 마무리할 수 있는 구조를 만든 것이다. 결과적으로 기능도 완성됐고 발표 준비도 잘 마무리됐다.

배운 점

돌아보면 둘 다 맞는 말이었다. 나는 리스크 관리를 중요하게 생각했고, 팀원은 결과물의 퀄리티를 중요하게 생각했다. 팀장의 "병렬 처리" 결정이 두 관점을 모두 살릴 수 있는 방법이었다.

팀 프로젝트에서 의견 충돌이 생겼을 때, 꼭 하나를 선택해야 하는 건 아니라는 걸 배웠다.

기술적 회고

다시 만든다면 다르게 할 것들이 있다.

진행 중 상태를 처음부터 고려하기

3편에서 다뤘듯이 처음에 만든 포트 시스템은 완성된 워크플로우를 기준으로 검증을 짰다. 그런데 워크플로우 빌더는 사용자가 점진적으로 만들어가는 도구다. 필수 입력이 잠시 비어 있을 수도 있고, ports 정의가 없는 노드가 있을 수도 있다.

다음에는 디자인 단계에서 완성된 상태만이 아니라 만들어가는 중인 상태도 머릿속에 두고 검증의 시점을 결정하려 한다.

MVP 노드만 보고 디자인하지 않기

포트 시스템을 만들 때 머릿속에 있던 노드는 MVP의 4개 노드뿐이었다. 그래서 고정된 ports를 가진 노드만 가정한 시스템이 나왔고, IF/ELSE 같이 동적 ports를 가진 노드를 만나자마자 깨졌다.

다음에는 디자인 단계에서 가장 복잡한 노드도 미리 고려하려고 한다. 일단 단순한 케이스로 만들고 나중에 확장하면 된다고 생각했지만, 시스템의 구조 자체가 단순한 케이스에 묶이면 확장이 어려워진다는 걸 배웠다.

이후 계획

일단 취업 준비를 진행하면서, SnapAgent를 만들며 알게 된 것들을 활용해보려 한다.

프로젝트를 진행하면서 Dify, n8n, ComfyUI 같은 AI 워크플로우 비주얼 빌더가 있다는 걸 알게 됐다. 직접 써보니 꽤 유용했다. 앞으로는 내가 매일 하는 일들을 이런 서비스로 자동화하는 과정을 공부하고, 그 과정을 블로그로 기록할 예정이다.

마치며

4편에 걸쳐 SnapAgent 프로젝트를 회고했다.

1편: 기획 배경, 매주 피드백을 받으며 방향을 찾아간 과정
2편: 팀 협업을 위한 base 컴포넌트 설계와 노드 생성 가이드 문서화
3편: 워크플로우 빌더의 포트 시스템을 만들고 사라진 과정과 재설계 분석
4편: 5주간의 회고와 이후 계획

5주라는 짧은 시간 동안 기획부터 개발, 배포까지 경험할 수 있었다. 부족한 점도 많았지만, "출시할 수 있는 프로덕트"를 완성했다는 게 가장 큰 성과였다.

이 경험을 바탕으로 다음 프로젝트에서는 더 나은 구조와 협업 방식을 적용해보고 싶다.

최종 발표

[크래프톤 정글 뉴스 카드 — Snap Agent 소개]

[최종 발표회 YouTube 영상]

[크래프톤 정글 10기] 나만무 프로젝트 회고 (3)

onebrotravel — Tue, 19 May 2026 22:46:34 +0900

들어가며

1편에서 SnapAgent의 기획 배경을, 2편에서 팀 협업을 위한 base 컴포넌트 설계와 노드 생성 가이드 문서화 과정을 다뤘다.

3편에서는 내가 담당한 워크플로우 빌더 프론트엔드의 핵심 구현 이야기를 풀어보려 한다.

워크플로우 빌더 구현하기

5주 프로젝트에서 워크플로우 빌더 프론트엔드를 맡았다. ReactFlow 기반의 노드-엣지 에디터를 만드는 일이었다.

ReactFlow를 사용해본 적도, 노드-엣지 구조를 만들어본 적도 없었다. 1편에서 다뤘듯이 코치님이 n8n, Dify, Botpress를 레퍼런스로 추천해줬고, 분석 끝에 Dify를 메인 레퍼런스로 잡았다. 오픈소스라 GitHub 코드를 참고하기 편했다.

2주차에 들어가기 전에 ReactFlow docs와 Dify 코드를 보면서 베이스를 만들었다. 노드 타입 정의나 컴포넌트 구조 같은 패턴은 Dify를 참고했다. 2주차 초에 Start → Knowledge Retrieval → LLM → End로 이어지는 RAG 샘플이 처음 화면에 떴다.

초기 RAG 샘플 워크플로우 — 노드를 클릭하면 오른쪽에 설정 패널이 뜬다

포트 시스템

3주차에 포트 시스템을 만들었다. 노드에 포트를 시각적으로 표시하고, 사용자가 두 노드를 연결할 때 포트 타입이 호환되는지 검증하는 기능이었다.

백엔드는 이미 PortType 8가지(STRING, NUMBER, BOOLEAN, ARRAY, OBJECT, FILE, ANY 등)를 정의해두고 있었고, Dify도 같은 개념을 쓰고 있었다. 프론트엔드도 거기에 맞춰서 백엔드와 일치시키려고 했다.

최초에는 연결되는 노드끼리의 타입이 맞지 않는다는 것을 시각적으로 사용자에게 표현하기 위해 노드를 연결할 때 검증하도록 만들었다. 노드마다 input/output type이 정해져 있으니 type이 다른 노드끼리는 연결할 수 없어야 한다고 판단했다.

이때 만든 코드는 대략 이런 구조였다.

PortIndicator, PortHandle, PortTooltip, NodePort — 노드에 포트를 시각적으로 표시하는 컴포넌트
usePortConnection — onConnect 시점에 포트끼리 연결을 검증하는 훅
portValidation — 검증 로직 모음
typeCompatibility — 포트 타입 호환성 매트릭스

검증은 세 단계로 짰다.

타입 호환성 — 연결하려는 두 포트의 타입이 호환되는지
필수 입력 누락 — 노드에 필수 입력 포트가 비어 있는지
다중 연결 — 같은 입력 포트에 이미 연결된 게 있는지

이 셋을 다 통과해야 실제 엣지가 만들어졌다. 그렇지 않으면 연결 자체가 막히도록 설계했다.

사라진 포트 시스템

며칠 뒤, 새벽에 팀원의 commit이 들어왔다.

fix: 버그 해결

뭘 해결했는지 차차 알아 갈 예정

이 commit에서 시각화 컴포넌트 4개(PortIndicator, PortHandle, PortTooltip, NodePort)와 연결 검증 훅(usePortConnection)이 삭제됐다. 자리에 InputMappingSection이라는 다른 컴포넌트가 들어왔다.

portValidation과 typeCompatibility는 파일로는 남았지만 어디서도 호출되지 않는 상태가 됐다.

왜 사라졌나

이 commit이 들어오고 팀원에게 물어봤다. 내 코드가 삭제되었는데, 이 commit 메시지만으로는 왜 사라졌는지 알 수가 없었기 때문이다.

팀원 말로는, 자기 파트를 구현하다 보니 자꾸 에러가 나는데 어떤 코드인지 이해하는 건 나중에 하고, 일단 돌아가게 하려고 에러 나는 부분을 들어냈다는 거였다. "뭘 해결했는지 차차 알아 갈 예정"이라는 commit 메시지가 그래서 나온 거였다.

수정된 코드는 내 코드였으니 내가 가장 잘 알고 있었고, 내가 분석해서 설명해주기로 했다. 사실 처음에는 내 코드가 맞다는 걸 증명하고 싶다는 마음으로 분석했는데, 분석결과 결국 내 검증 시스템이 너무 빡빡해서 생기는 문제였다는 걸 알게 되었다.

내가 포트 시스템을 만들 때 머릿속에 있던 노드는 처음에 만든 MVP용 RAG 샘플의 노드들 — Start, Knowledge Retrieval, LLM, End — 였다. 이 노드들은 input/output port가 처음부터 정해져 있고 모두 단순한 구조였다. 노드별 ports 메타데이터를 미리 정의해두고, 그걸로 검증하는 방식이 자연스러워 보였다.

문제는 3주차 후반에 추가될 노드들이었다. IF/ELSE 노드는 사용자가 조건을 추가하면 output port가 늘어났다. 처음엔 두 개였다가, 조건을 추가하면 세 개, 네 개로 늘어났다. 노드별 ports를 미리 정의해두는 내 방식으로는 표현할 수 없는 구조였다.

ports 정의 자체가 없는 노드들도 있었다. 새로 추가된 노드 타입이거나, 다른 사람이 ports 메타데이터까지 신경 쓰지 않고 작업한 노드들. 내 시스템에서는 이런 노드는 연결 자체가 막혔다.

필수 입력 검증도 문제였다. 사용자가 워크플로우를 만드는 도중에는 필수 입력 포트가 비어 있는 게 정상이다. 노드를 먼저 놓고 나중에 연결할 수도 있고, 임시로 연결을 끊었다가 다시 붙일 수도 있다. 그런데 내 시스템은 그런 진행 중 상태를 허용하지 않았다.

내가 검증 시스템을 만든 시점에는 이 문제들이 잘 안 보였다. 그때 캔버스에 띄워서 테스트한 건 MVP 단계의 RAG 샘플뿐이었다. RAG 샘플은 ports가 미리 정의된 정적인 노드들이고, 한 번 연결하면 그 상태로 끝이라 검증이 막을 일이 없었다. 사용자가 만들어가는 중인 워크플로우가 어떤 모양일지는 그때 잘 떠오르지 않았다.

이러다 보니 팀원이 새로 추가하는 노드를 바탕으로 워크플로우를 만들고 검증할 수 없어서 통째로 들어낸 거였다.

재설계: Variable Mapping

들어내진 시스템 대신 들어온 코드는 두 가지였다. 노드 베이스 컴포넌트(node.tsx)에서 input/output handle을 표시하는 로직이 단순해졌고, 새로 추가된 InputMappingSection이라는 컴포넌트가 노드 패널에 들어갔다.

먼저 단순해진 부분. 내 시스템에서는 노드별 ports 메타데이터를 미리 정의해두고, 그걸 보고 input handle을 표시할지 결정했다. 새 시스템에서는 이렇게 바뀌었다.

const hasInputHandle = nodeType !== BlockEnum.Start;
const hasOutputHandle = nodeType !== BlockEnum.End;

Start 노드는 input이 없고, End 노드는 output이 없고, 나머지는 다 있다. 끝. 동적 output port 같은 건 핸들 자체에서는 신경 쓰지 않는다.

그러면 IF/ELSE 노드처럼 output이 여러 개 필요한 경우는 어떻게 풀까? 여기서 InputMappingSection이 등장한다.

InputMappingSection은 노드 패널 안에 들어가는 컴포넌트다. 사용자가 노드를 클릭해서 설정 패널을 열면, 그 안에 이 노드의 입력으로 어떤 변수를 쓸지 선택하는 picker가 뜬다. picker에서 변수를 선택하면 그 정보가 노드의 variable_mappings라는 속성에 저장된다.

variable_mappings: {
  "prompt": {
    target_port: "prompt",
    source: ["start_node_id", "user_query"]  // 어디서 가져올지
  },
  "context": {
    target_port: "context",
    source: ["knowledge_node_id", "results"]
  },
}

이 구조의 핵심은 데이터 흐름이 엣지가 아니라 노드의 속성으로 옮겨졌다는 점이다.

내 시스템에서는 엣지 자체가 데이터 흐름이었다. 노드 A의 output port에서 노드 B의 input port로 엣지가 연결되면, 그 엣지를 통해 데이터가 흐르는 모델. 그래서 연결 시점에 두 포트가 호환되는지를 엄격하게 검증해야 했다.

새 시스템에서는 엣지는 시각적 표시다. 실제 데이터 흐름은 각 노드가 자기 variable_mappings에 어떤 변수에서 어떤 값을 가져올지 적어두는 방식. 엣지를 그리는 건 두 노드가 연결돼 있다는 걸 보여주는 정도다.

Port 모델과 Variable Mapping 모델 비교

분석해보니 이 차이가 내 시스템의 문제들을 풀어주고 있었다.

IF/ELSE의 동적 output: variable_mappings는 그냥 dict라서 ports 메타데이터에 의존하지 않는다. output이 두 개든 네 개든 상관없다.
ports 정의 없는 노드: picker는 현재 그래프에서 가져올 수 있는 변수들을 보여주는 방식이라, 노드별 ports 메타데이터가 없어도 작동한다.
진행 중 상태: variable_mappings가 비어 있어도 노드는 살아있을 수 있다. 사용자가 천천히 채우면 된다.
검증의 시점: 변수를 선택할 때 picker가 type compatibility를 확인한다. 연결 시점에는 아무것도 검증하지 않는다.

물론 팀원이 처음부터 이런 모델을 의도해서 들어낸 건 아니었다. 어떤 코드인지 이해는 나중에 하고 일단 돌아가게 하려고 빡빡한 검증 부분을 들어낸 게 이렇게 된 거였다. 하지만 분석해보니 들어내고 남은 부분이 더 적합한 모델이었다.

마치며

이번 글에서는 워크플로우 빌더의 포트 시스템을 만들고, 그게 며칠 뒤에 들어내지고, 재설계를 분석한 경험을 정리했다.

두 시스템의 차이는 검증을 어디에서 할 것인가에 있었다. 내 시스템은 연결 시점에서 그래프 단위로 검증했고, 재설계된 시스템은 변수 선택 시점에서 컴포넌트 단위로 검증한다. 워크플로우를 만들어가는 중인 상태를 허용하려면 후자가 더 적합했다.

지금 돌아보면 내가 처음에 그렸던 타입이 다르면 아예 연결 자체를 막는 방식을 채택하는 서비스도 있다. 노드-엣지 구조로 이미지를 생성하는 ComfyUI 같은 도구가 그렇다. 써본 기억으로는 거기서도 타입이 안 맞으면 엣지가 연결되지 않는다.

왼 - Dify의 노드 / 우 - ComfyUI의 노드

하지만 우리가 만드는 서비스는 ComfyUI보다 Dify 쪽에 가까웠다. 이미지 생성처럼 완성된 그래프를 실행하는 도구가 아니라, 사용자가 AI 에이전트의 워크플로우를 점진적으로 빌드하는 도구. IF/ELSE 노드의 동적 output처럼 그래프가 만들어지는 도중에 모양이 바뀌는 상황이 자연스럽게 일어났다. 우리 서비스에 맞는 방향은 ComfyUI 쪽이 아니라 Dify 쪽이었다.

팀원이 내 코드를 들어낸 commit은 결국 내 시스템의 문제를 가장 빠르게 알려준 피드백이었다. 분석을 마친 뒤에는 내가 만든 시스템에 너무 집착하지 않고 들어낸 것을 받아들였다.

다음 편에서는 5주차 발표 직전과 발표 이후의 회고를 다룰 예정이다.

[크래프톤 정글 10기] 나만무 프로젝트 회고 (2)

onebrotravel — Tue, 19 May 2026 22:46:23 +0900

들어가며

1편에서는 SnapAgent의 기획 배경과 기술 스택 선정 과정을 다뤘다. 비개발자에서 개발자로 타겟을 전환한 이유, 5주간의 타임라인, 그리고 팀의 기술적 배경을 고려한 스택 선정 과정을 정리했다.

2편에서는 팀 협업 이야기를 해보려 한다. 5명이서 워크플로우 에디터를 개발하면서, 어떻게 하면 서로의 작업이 충돌하지 않고 효율적으로 진행될 수 있을지 고민한 과정을 다룬다.

SnapAgent가 어떻게 동작하는가
팀 협업을 위한 base 컴포넌트 설계
노드 생성 가이드 문서화

SnapAgent가 어떻게 동작하는가

본격적인 구현 이야기에 앞서, SnapAgent가 어떻게 동작하는지 간단히 소개한다.

전체 흐름

"시작 - 지식 검색 - LLM - 종료" 노드로 구성된 워크플로우 기준으로, 사용자가 채팅창에 메시지를 입력하면 백엔드에서 워크플로우가 실행된다. 이때 SSE(Server-Sent Events) 를 통해 각 노드의 실행 상태와 LLM 응답이 실시간으로 프론트엔드에 전달된다.

노드 실행 상태 시각화

워크플로우가 실행되면 각 노드의 테두리 색상이 변한다.

성공: 초록색 테두리
실패: 빨간색 테두리

노드_실행상태

사용자는 현재 어떤 노드가 실행 중인지, 어디서 에러가 발생했는지 한눈에 파악할 수 있다.

LLM 응답 스트리밍

LLM 노드가 실행되면 응답이 한 번에 표시되지 않고, 타이핑하듯 한 글자씩 나타난다. 백엔드에서 토큰 단위로 스트리밍되는 응답을 받아서 프론트엔드에서 렌더링하는 방식이다.

이제 이 워크플로우 에디터를 어떻게 구현했는지 이야기해보자.

팀 협업을 위한 base 컴포넌트 설계

하드코딩의 한계

1편에서 언급했듯이, 초반에는 "시작 → 지식 검색 → LLM → 종료" 4개 노드가 하드코딩된 상태였다. MVP를 빠르게 만들어서 발표에서 서비스에 대한 피드백을 받는 게 우선이었기 때문에, 확장성보다는 속도를 택했다.

하지만 타겟을 개발자로 전환하면서 상황이 달라졌다. 빈 워크플로우에서 시작해 사용자가 직접 노드를 추가하는 방식으로 바뀌니, IF-ELSE, Question Classifier 등 다양한 노드가 필요해졌다.

기존 하드코딩 구조로는 노드 하나 추가할 때마다 중복 코드가 쌓일 게 뻔했다. 게다가 분업을 위해서는 5명이서 각자 다른 노드를 개발해야 하는데, 두 가지 문제가 예상됐다.

UX 일관성: 노드마다 스타일이 달라지면 사용자 경험이 깨진다
개발 병목: 매번 "이거 어떻게 구현해요?" 질문이 오면 내가 병목이 된다

결국 기존 하드코딩 구조를 걷어내고, 공통 컴포넌트 기반으로 리팩토링하기로 했다.

해결책: base 공통 컴포넌트

모든 노드가 공유하는 공통 요소를 _base 폴더에 분리했다. 이때 팀에서 이미 합의된 Feature 기반 디렉토리 구조에 따라, _base 폴더는 features/workflow/components/nodes/_base 위치에 자리잡았다.

BaseNode — 노드 래퍼 컴포넌트

모든 노드의 공통 래퍼로서 다음을 자동 처리한다.

240px 고정 폭으로 일관된 크기
실행 상태에 따른 테두리 색상 변화 (성공: 초록, 실패: 빨강)
Validation 에러 시 빨간 "오류" 뱃지 표시
입출력 핸들(Handle) 자동 배치

// _base/node.tsx (핵심 부분)
type BaseNodeProps = {
  id: string;
  data: NodeProps['data'];
  children: ReactElement;
  selected?: boolean;
};

const BaseNode = ({ id, data, children, selected }: BaseNodeProps) => {
  const hasValidationError = useWorkflowStore((state) =>
    state.validationErrorNodeIds.includes(id)
  );

  const { showRunningBorder, showSuccessBorder, showFailedBorder } =
    useMemo(() => ({
      showRunningBorder: data._runningStatus === NodeRunningStatus.Running,
      showSuccessBorder: data._runningStatus === NodeRunningStatus.Succeeded,
      showFailedBorder: data._runningStatus === NodeRunningStatus.Failed,
    }), [data._runningStatus]);

  return (
    <div
      className={clsx(
        'w-[240px] rounded-[15px] border-2',
        selected && 'border-blue-500',
        hasValidationError && 'border-red-400',
        showSuccessBorder && 'border-green-500',
        showFailedBorder && 'border-red-500',
      )}
    >
      {hasValidationError && (
        <div className="absolute -top-2 right-3 rounded-full bg-red-500 px-2 text-xs text-white">
          오류
        </div>
      )}
      <NodeTargetHandle />
      <NodeSourceHandle />
      {children}
    </div>
  );
};

export default memo(BaseNode);

팀원은 BaseNode 안에 들어갈 내부 컨텐츠만 구현하면 된다.

const MyNewNode = ({ data }: NodeProps) => (
  <div className="px-3 py-2">
    {/* BaseNode가 래핑해주므로 내부만 신경쓰면 됨 */}
  </div>
);

BasePanel — 설정 패널 컴포넌트

노드를 클릭하면 오른쪽에 설정 패널이 나타난다. 이 패널의 공통 UI도 분리했다.

헤더 (노드 아이콘 + 제목 + 닫기 버튼)
설명 입력 필드
탭 UI

(TODO_BasePanel_스크린샷)

// _base/panel.tsx (핵심 부분)
interface BasePanelProps {
  children: React.ReactNode;
}

export const BasePanel = ({ children }: BasePanelProps) => {
  const { selectedNodeId, nodes, updateNode, selectNode } = useWorkflowStore();
  const node = nodes.find((n) => n.id === selectedNodeId);

  if (!node) return null;

  return (
    <div className="flex flex-col h-full">
      {/* 헤더: 아이콘 + 제목 + 닫기 버튼 */}
      <div className="flex items-center justify-between px-4 py-3 border-b">
        <div className="flex items-center gap-2">
          <BlockIcon type={node.data.type} size="sm" />
          <h3 className="font-semibold">{node.data.title}</h3>
        </div>
        <button onClick={() => selectNode(null)}>
          <X className="w-4 h-4" />
        </button>
      </div>

      {/* 설명 입력 필드 */}
      <div className="px-4 py-2 border-b">
        <Input
          value={node.data.desc || ''}
          onChange={(e) => updateNode(selectedNodeId!, { desc: e.target.value })}
          placeholder="설명 추가..."
        />
      </div>

      {/* 탭 UI */}
      <div className="border-b">
        <button className="px-4 py-2 text-sm font-medium border-b-2 border-blue-600">
          설정
        </button>
      </div>

      {/* 노드별 설정 내용 */}
      <div className="flex-1 overflow-y-auto p-4">
        {children}
      </div>
    </div>
  );
};

레이아웃 컴포넌트 — Box, Group, Field

패널 내부 UI를 일관되게 구성하기 위한 레이아웃 컴포넌트도 만들었다.

<Box>
  <Group title="모델 설정" description="사용할 AI 모델을 선택하세요">
    <Field label="Provider" required>
      <Select />
    </Field>
    <Field label="Model" required>
      <Select />
    </Field>
  </Group>
</Box>

Box > Group > Field 계층으로 조합하면, 어떤 노드의 패널이든 일관된 레이아웃이 나온다.

보이지 않는 작업의 교훈

base 컴포넌트로 리팩토링한 주의 발표 피드백은 뼈아팠다.

발표 피드백

저번 주 발표랑 차이가 없다. 여전히 4개 노드밖에 없는데 1주일 동안 뭐했냐?

사실 그 주에는 base 컴포넌트 리팩토링만 한 게 아니었다. 타겟을 비개발자에서 개발자로 전환하고, IF-ELSE / Question Classifier / Variable Assigner / Answer 등 새 노드들도 같이 작업하고 있었다. 다만 그 작업들이 내부 구조에 묶여 있어서 발표 시점에 눈에 보이는 결과물로는 드러나지 않았다. 리팩토링의 가치는 당장 눈에 보이지 않는다는 걸 체감한 순간이었다.

결과: 다음 주의 폭발적 개발

하지만 base 컴포넌트의 진가는 그 다음 주에 드러났다. 공통 구조가 잡혀 있으니 위에서 말한 새 노드들에 더해 Tavily, 마켓플레이스 템플릿 노드 등 다양한 노드를 빠르게 추가할 수 있었다. 팀원들도 각자 노드를 개발할 때 공통 스타일과 기능이 자동 적용되니, 노드별 고유 로직에만 집중할 수 있었다.

4주차 발표에서야 "발표 시나리오는 다듬어야겠지만 서비스는 잘 만든 것 같다"는 피드백을 받을 수 있었다.

노드 생성 가이드 문서화

계기: 폴더 위치가 달랐다

base 컴포넌트를 만들고 나서, 팀원이 Variable Assigner 노드를 구현했다. 그런데 코드를 보니 다른 노드들이 있는 폴더가 아니라 엉뚱한 위치에 파일이 있었다. 엉뚱한 위치에 있는 노드의 위치를 옮기면서 생각했다. 내가 처음부터 안내를 잘 했으면 일을 두 번 할 필요가 없었을 텐데.

공통 컴포넌트가 있어도, 새 노드를 추가하려면 여전히 여러 파일을 수정해야 했다.

BlockEnum에 타입 추가
노드 타입 정의 생성
노드 컴포넌트 작성
패널 컴포넌트 작성
컴포넌트 맵에 등록
컨텍스트 메뉴에 추가
아이콘 추가
기본값 정의 (선택)

이 과정을 모르면 "다음에 뭘 해야 하지?"에서 막히거나, 폴더 위치처럼 사소하지만 중요한 부분을 놓치게 된다.

"나 없이도 돌아가는 구조"

노드를 대폭 추가해야 하는 상황에서, 매번 질문에 답하다 보면 내가 병목이 될 게 뻔했다. 그래서 노드 생성 가이드 문서를 작성하기로 했다.

가이드 문서의 목표

내가 없을 때도 팀원이 막힘없이 노드를 추가할 수 있어야 한다.

목표는 단순했다. 내가 없을 때도 팀원이 막힘없이 노드를 추가할 수 있어야 한다.

문서 구성

문서는 다음과 같이 구성했다.

8단계 체크리스트 — 순서대로 따라하면 완성
각 단계별 상세 설명 — 파일 경로, 코드 예시 포함
주의사항 — TypeScript strict 모드, 상태 관리 규칙 등
검증 체크리스트 — 노드 추가 후 확인할 항목
참고 자료 — 난이도별 기존 노드 예시 (간단/설정있음/복잡)

특히 난이도별 예시를 넣은 이유는, 새 노드를 만들 때 비슷한 복잡도의 기존 노드를 참고하면 훨씬 빠르기 때문이다.

결과

문서를 공유한 후 변화가 있었다.

팀원이 새 노드 추가 시 질문 없이 진행 가능해짐
코드 리뷰 시 "가이드 몇 단계 빠뜨렸네요"로 피드백 간소화
내가 다른 작업에 집중할 시간 확보

처음 문서를 작성하는 데 1~2시간 정도 걸렸지만, 이후 절약된 시간을 생각하면 충분히 가치 있는 투자였다.

마치며

3편에서는 워크플로우 빌더의 포트 시스템을 만들고 사라진 과정, 그리고 재설계를 분석한 경험을 다룰 예정이다.

[크래프톤 정글 10기] 나만무 프로젝트 회고 (1)

onebrotravel — Thu, 14 May 2026 17:28:18 +0900

들어가며

5개월간의 크래프톤 정글 여정의 마지막 관문, "나만의 무기 만들기(나만무)" 프로젝트. 5주라는 시간 동안 팀원들과 함께 실제 서비스를 기획하고 개발해야 했다. 우리 팀이 선택한 주제는 AI 에이전트 워크플로우 빌더, 프로젝트명은 SnapAgent였다.

GitHub (Frontend): https://github.com/Krafton-Jungle10-Team4/Frontend
GitHub (Backend): https://github.com/Krafton-Jungle10-Team4/Backend

SnapAgent 인트로/메인 이미지

기획 배경: 아이디어가 나오기까지

첫 번째 아이디어

처음 우리 팀이 가져간 아이디어는 GitHub 레포지토리 시각화 도구였다. 사용자가 GitHub URL을 입력하면 해당 레포지토리의 아키텍처를 시각적으로 재구성해주는 서비스를 구상했다. 이 아이디어는 deepwiki를 레퍼런스로 삼았다.

하지만 코치님의 피드백은 냉정했다.

코치님의 피드백

어떤 기준으로 시각적으로 정렬할 것인지 모르겠지만, 단순히 폴더 구조를 시각적으로 재구성하는 것은 이미 옛날부터 존재하는 구식 아이디어예요.

프로젝트를 모듈 기준으로 분석할 건지, 클래스 기준으로 분석할 건지, 함수 기준으로 분석할 건지에 대한 아이디어가 구체적이지 않다는 피드백이었다. 만약 함수를 기준으로 호출 플로우를 분석한다면 비동기 함수를 포함하는 복잡한 플로우는 분석하기 어려울 것이고, 폴더만을 기준으로 시각화한다면 그건 너무 단순한 프로젝트가 될 것이라는 지적도 있었다.

새로운 방향

코치님이 대안으로 제시한 방향은 이랬다.

코치님의 제안

요즘 langchain으로 AI agent를 구축하려는 시도가 굉장히 늘고 있는데, 그걸 시각적으로 표현하는 툴이 너무 약해요. 이 주제가 더 트렌디하다고 생각하는데 어때요?

이 힌트를 바탕으로 우리는 Dify, n8n 같은 시각적 AI 워크플로우 빌더를 조사하기 시작했다.

우리 팀원들은 모두 AI 관련 프레임워크를 처음 접하는 사람들뿐이었다. 이때부터 코치님께 RAG 파이프라인의 플로우에 대해 질문하거나 관련 도서를 추천받아서, 팀원들끼리 LLM과 AI 워크플로우 구축 방법을 따로 학습하기도 했다.

이런 과정을 거치면서 최종적으로 우리의 방향이 정해졌다.

노코드/로우코드로 AI 워크플로우를 시각적으로 구축하고, 원클릭으로 배포할 수 있는 서비스를 만들자.

방향을 찾기까지

사실 최종 방향이 바로 정해진 건 아니었다. 매주 발표와 피드백을 거치며 서비스의 형태가 계속 바뀌었다.

처음에는 비개발자를 타겟으로 잡았다. 그런데 노드-엣지 구조는 비개발자가 다루기엔 어려울 것이라는 의견이 팀 내에서 지배적이었다. 그래서 1주차에는 노드-엣지 구조 대신 폼 형식으로 데이터를 입력받아 RAG 파이프라인을 자동 생성하고, 프롬프트 테스트로 빠르게 프로토타이핑할 수 있는 서비스를 기획했다.

하지만 피드백은 "이 서비스를 누가 사용할지에 대한 고민이 없는 것 같다.", "타겟 유저가 애매하다"였다. 추가로 "도메인만 AI로 바뀌었지, 기획 단계에서 얘기했던 시각화 아이디어는 사라졌다"는 피드백도 받았다.

1주차 폼 형식 RAG 서비스 프로토타입

2주차에는 시각화 피드백을 수용해 Dify를 참고한 노드-엣지 구조를 도입했다. 하지만 비개발자 타겟은 쉽게 포기할 수 없었다. 결국 폼으로 입력받으면 "시작 → Knowledge → LLM → 종료" 워크플로우가 자동 생성되는 절충안을 선택했다. MVP를 빠르게 검증하기 위해 이 4개 노드는 하드코딩된 상태였다.

2주차 노드-엣지 도입

이번에도 이전과 같은 피드백을 받았다. "여전히 이 서비스의 타겟층을 잘 모르겠다"는 것이었다. 또한 비개발자를 위해 선택한 "폼을 입력하면 자동으로 생성되는 워크플로우"에 대해서는 "노드를 사용자가 직접 만들어야 하는데 왜 자동 생성되냐", "서비스의 사용 플로우가 어색하다"는 피드백을 받았다. 결국 우리팀은 시각화를 위한 노드-엣지 구조와 비개발자 타겟은 양립하기 어렵다는 결론을 내렸다. 3주차에 타겟을 개발자로 완전히 전환하고, 빈 워크플로우에서 시작해 사용자가 직접 노드를 추가하는 방식으로 확정했다.

이때부터 프로젝트명도 SnapAgent로 정해졌다.

최종 발표

[크래프톤 정글 뉴스 카드 — Snap Agent 소개]

[최종 발표회 YouTube 영상]

팀 협업 방식

5명이 5주간 협업하면서 Notion을 적극 활용했다.

칸반 보드 — 태스크 관리 및 진행 상황 공유
공유 문서 — 기술 조사 내용, 회의록, API 명세 등 정리

Notion 공유 문서 — API 명세/회의록, Notion 칸반 보드 — 태스크 관리

기술 스택

나는 이번 프로젝트에서 React Flow 기반 워크플로우 에디터 프론트엔드를 담당했다.

우리 팀은 전반적으로 비전공자로 구성되었고, 특히 프론트엔드 경험자가 없었다. 그래서 문서화가 잘 되어 있고 초기 러닝커브가 적은 스택을 우선적으로 선택했다.

Frontend

React + TypeScript
- 나만무를 시작하기 전에 JavaScript가 TypeScript보다 러닝커브가 낮다는 말을 많이 들었다. 그런데 나만무 직전까지 C 언어를 사용하다 보니 타입이 명시되는 TypeScript가 오히려 더 익숙해서 함께 채택했다.
React Flow
- 노드 기반 워크플로우 에디터의 핵심. 레퍼런스 프로젝트인 Dify도 이 기술 스택을 차용하고 있어서 채택했다.
Zustand
- 가벼운 전역 상태 관리. 이것도 Redux 대비 학습 난이도가 낮아서 빠르게 우리 프로젝트에 도입하기 위해 채택했다.

Backend

Python + FastAPI — 비동기 처리와 자동 API 문서화
SQLAlchemy + PostgreSQL — ORM과 관계형 데이터베이스
pgvector — PostgreSQL 확장으로 벡터 검색 지원
Redis — 응답 캐싱으로 비용·속도 최적화
Alembic — DB 마이그레이션 관리

AI

OpenAI API — GPT 모델 활용
AWS Bedrock — Titan Embeddings로 문서 임베딩

Infrastructure

Vercel — 프론트엔드 배포
AWS ECS — 백엔드 배포
Docker Compose — 로컬 개발 환경 구성

프로젝트 타임라인

주차	계획	실제 진행
1주차	주제 선정 & 기획	주제 선정 & 기획 (폼 형식 RAG)
2주차	MVP 개발	노드-엣지 도입, 하드코딩된 워크플로우
3주차	MVP 추가 개발	타겟 전환, `_base` 컴포넌트 리팩토링, 노드 4종(IF-ELSE / Question Classifier / Variable Assigner / Answer) 신규 구현
4주차	개발	마켓플레이스 / 템플릿 시스템(ImportedWorkflowNode) 구축, Dify 스타일 NodeSelector
5주차	폴리싱	UI 통일, 발표 준비

앞서 말했듯이 2~3주차는 기획 방향이 계속 바뀌면서 개발 속도가 나지 않았다. 특히 3주차에는 타겟을 개발자로 전환하면서 기존 하드코딩된 노드를 _base 컴포넌트 기반으로 리팩토링하는 작업을 진행했는데, 발표 피드백은 "겉으로 보기엔 저번 주와 차이가 없다, 1주일 동안 뭐 했냐"였다. 내부 구조는 완전히 바뀌었지만 눈에 보이는 결과물은 여전히 4개 노드뿐이었기 때문이다.

결국 3주차 후반에 IF-ELSE, Question Classifier, Variable Assigner, Answer 등 4개 노드 타입을 한꺼번에 만들고, 4주차에는 마켓플레이스와 템플릿 시스템(ImportedWorkflowNode)까지 구축하며 MVP의 대부분을 완성했다. 4주차 발표에서야 "서비스는 잘 만든 것 같다"는 피드백을 받을 수 있었다.

마치며

이번 글에서는 나만무 프로젝트의 기획 배경과 매주 피드백을 받으며 방향을 찾아가는 과정을 이야기했다. 비개발자에서 개발자로 타겟을 전환하고, 폼 형식에서 노드-엣지 구조로 바꾸기까지 2주가 걸렸다. 그 과정에서 개발 일정이 밀렸고, 3주차 후반부터 4주차에 걸쳐 MVP 대부분을 몰아서 구현하는 상황이 벌어지기도 했다.

5주차에 팀 내부적으로 작은 트러블이 있기도 했지만, 결과적으로 5주간의 프로젝트는 무사히 마무리되었다. 이 이야기는 4편 회고에서 다룰 예정이다.

다음 편에서는 팀 협업을 위한 컴포넌트 설계와 노드 생성 가이드 문서화 과정을 다룰 예정이다

[오제이 튜브 임베디드 강의] 외전. 최신 DS18B20 라이브러리로 고추건조기 리팩토링하기

onebrotravel — Wed, 6 May 2026 22:02:04 +0900

동기 — 왜 리팩토링을 시도하는가

이 강의 시리즈에서 가장 고생했던 문제 중 하나가 FND와 온도 센서의 통신 충돌이었다. "쓰레드 흉내내기"부터 "드디어 해결된 크리티컬 문제"까지 세 글에 걸쳐 다뤘던 이 문제를 요약하면:

TIM3 인터럽트(100μs 주기)에서 FND를 갱신하고, main 루프에서 DS18B20 온도 센서를 읽는 구조
main에서 1-Wire 통신 중에 TIM3 인터럽트가 발생하면, FND의 SPI GPIO가 끼어들어 1-Wire 타이밍이 깨짐
FND에 온도가 0으로만 표시되거나, 깜빡이는 현상 발생

강의에서는 이전 버전 라이브러리의 소스를 직접 수정하여 해결했다. is_busy 플래그를 수동으로 추가하고, write_bit 단위까지 내려가서 실제 통신 구간에만 락을 걸었다. 동작은 했지만, 라이브러리 내부를 뜯어야 하는 부담이 있었다.

diagram_01_fnd_collision

이전 글("드디어 해결된 크리티컬 문제")의 마지막 섹션에서 현재 버전 DS18B20 라이브러리가 Non-Blocking으로 설계되어 있고, ds18b20_is_busy(), ds18b20_is_cnv_done() 등의 API가 내장되어 있다는 것을 확인했다. 그때 "강의에서 마주한 FND-온도센서 충돌 문제를, 현재 버전 라이브러리를 사용하면 라이브러리 수정 없이 더 간단하게 해결할 수 있지 않을까?"라는 생각을 했다. 이번 글에서 실제로 최신 버전의 라이브러리를 포팅하여 리팩토링을 시도한다.

현재 버전 라이브러리 분석

이전 버전 (블로킹)

이전 버전의 Ds18b20_ManualConvert는 함수 내부에서 변환 시작 → 완료 대기 → 데이터 읽기를 한 번에 수행했다. 함수가 리턴될 때까지 수백 ms 동안 CPU를 점유하므로, 그 사이에 TIM3가 끼어들면 충돌이 발생한다.

DS18B20 데이터시트 Figure 13 — Initialization Timing / Figure 14 — Read/Write Time Slot

왜 수백 ms나 걸릴까? 1-Wire 통신 자체가 μs 단위의 정밀한 타이밍으로 동작하기 때문이다. 이전 글("어디서도 안 알려주는 프로토콜의 원리")에서 다뤘듯이, 통신 시작만 해도 Master가 480μs 이상 Low를 유지(리셋 펄스) → Slave가 Presence Pulse로 응답하는 과정이 필요하고, 이후 ROM 커맨드 + Function 커맨드 + 데이터 송수신이 비트 단위로 이어진다. 여기에 12비트 해상도 기준 온도 변환 자체에 최대 750ms가 소요된다. 이 전체 과정을 하나의 함수 안에서 블로킹으로 처리하면, CPU가 그동안 다른 일을 할 수 없다.

diagram_02_ds18b20_process

현재 버전 (Non-Blocking)

현재 버전(nimaltd/ds18b20)은 Non-Blocking 방식으로 설계되어 있다. 각 동작을 호출하면 즉시 리턴하고, 완료 여부는 별도 함수로 체크한다.

API	역할	특징
`ds18b20_cnv()`	온도 변환 시작(0xCC + 0x44 전송)	호출 후 즉시 리턴
`ds18b20_is_cnv_done()`	변환 완료 여부 확인	HAL_GetTick 기반, 블로킹 없음
`ds18b20_req_read()`	온도 데이터 읽기 요청(0xBE 전송)	호출 후 즉시 리턴
`ds18b20_is_busy()`	1-Wire 버스가 통신 중인지 확인	ow 내부 상태 확인
`ds18b20_read_c()`	수신된 데이터에서 온도 계산	버퍼에서 읽기만, 통신 없음

1-Wire의 실제 비트 단위 통신은 TIM2 타이머 콜백(ow_callback)에서 처리된다. main에서는 명령만 내리고, 타이밍 처리는 타이머가 알아서 한다.

라이브러리 교체

기존 프로젝트에서 이전 버전 라이브러리 파일을 삭제하고, 현재 버전 파일로 교체한다.

삭제:

ds18b20.c / ds18b20.h (이전 버전)
onewire.c / onewire.h (이전 버전)

추가:

ds18b20.c / ds18b20.h (현재 버전)
ow.c / ow.h / ow_config.h — 현재 버전에서는 1-Wire 통신 부분이 별도의 독립 라이브러리(nimaltd/ow)로 분리되었다. 이전 버전에서 onewire.c/h로 ds18b20 라이브러리에 포함되어 있던 것과 달리, 이제는 ds18b20과 ow를 각각 가져와야 한다.

프로젝트 탐색기 — 교체 전/후 파일 구조

ow_config.h에서 OW_MAX_DEVICE를 1로 설정한다 (온도 센서가 1개이므로).

온도 센서 데이터 핀(PA3)은 .ioc에서 Output Open Drain + Pull-up으로 설정해야 한다. 1-Wire 통신은 풀업 저항으로 평상시 High를 유지하고, Master와 Slave가 Low로 당기는 것으로 신호를 만든다(Figure 14 참고). Push-Pull로 설정하면 Master가 직접 High를 구동하게 되어, Slave가 Low로 당기려 할 때 충돌이 발생한다.

PA3 Output Open Drain + Pull-up 설정

교체 후 빌드하면 API 이름이 전부 바뀌었으므로 대량의 에러가 발생한다. 이전 버전의 호출 코드를 모두 제거하고, 현재 버전 API로 새로 작성해야 한다.

리팩토링 시작

현재 버전 라이브러리의 README에서 제공하는 example code를 보자.

// 라이브러리 README의 example code
int16_t temp_c[2];

while(1) {
    ds18b20_cnv(&ds18);
    while(ds18b20_is_busy(&ds18));
    while(!ds18b20_is_cnv_done(&ds18));

    ds18b20_req_read(&ds18, 0);
    while(ds18b20_is_busy(&ds18));
    temp_c[0] = ds18b20_read_c(&ds18);

    ds18b20_req_read(&ds18, 1);
    while(ds18b20_is_busy(&ds18));
    temp_c[1] = ds18b20_read_c(&ds18);
}

API 자체는 Non-Blocking으로 설계되어 있지만, 사용법이 Busy Waiting(바쁜 대기)이다. while(ds18b20_is_busy(&ds18));로 완료될 때까지 빈 루프를 돌면서 CPU를 점유한다. 특히 while(!ds18b20_is_cnv_done(&ds18));는 12비트 해상도에서 약 800ms 동안 CPU가 아무것도 하지 못하고 대기한다는 의미다.

이대로 사용하면 이전 버전의 블로킹 방식과 본질적으로 같은 문제가 발생한다. 800ms 동안 FND 갱신이 멈추고, 다른 작업도 할 수 없다. Non-Blocking API를 제공하는데 busy waiting으로 사용하면 API의 장점을 전혀 살리지 못하는 것이다.

따라서 busy waiting 대신 상태머신을 도입한다. 각 단계에서 조건만 체크하고 즉시 빠져나와서, 대기 시간 동안 main 루프가 다른 작업(버튼 체크, FND 갱신 등)을 수행할 수 있게 한다.

비동기 상태머신 설계

위의 example code에서 busy waiting을 제거하고, 각 단계를 상태로 분리한다. 핵심 원칙은 모든 상태에서 "호출하고 즉시 빠져나옴"이다.

상태 정의

// defines.h
typedef enum {
    TEMPER_SENSOR_STATE_IDLE,
    TEMPER_SENSOR_STATE_WAIT_CONVERT,
    TEMPER_SENSOR_STATE_WAIT_READ,
} TEMPER_SENSOR_STATE;

diagram_03_state_machine

상태 전이

// main.c
volatile TEMPER_SENSOR_STATE temper_sensor_state;
volatile int16_t g_temper;

// while 루프 내
switch (temper_sensor_state) {
case TEMPER_SENSOR_STATE_IDLE:
    if (ds18b20_cnv(&ds18) == OW_ERR_NONE) {
        temper_sensor_state = TEMPER_SENSOR_STATE_WAIT_CONVERT;
    }
    break;

case TEMPER_SENSOR_STATE_WAIT_CONVERT:
    if (ds18b20_is_cnv_done(&ds18)) {
        if (ds18b20_req_read(&ds18) == OW_ERR_NONE) {
            temper_sensor_state = TEMPER_SENSOR_STATE_WAIT_READ;
        }
    }
    break;

case TEMPER_SENSOR_STATE_WAIT_READ:
    if (!ds18b20_is_busy(&ds18)) {
        g_temper = ds18b20_read_c(&ds18);
        temper_sensor_state = TEMPER_SENSOR_STATE_IDLE;
    }
    break;
}

각 상태에서 하는 일:

IDLE: ds18b20_cnv() 호출(변환 시작 명령 전송) → 즉시 WAIT_CONVERT로 전이
WAIT_CONVERT: ds18b20_is_cnv_done() 체크만 하고 리턴. 12비트 해상도에서 약 800ms 소요. 완료되면 ds18b20_req_read() 호출 → WAIT_READ로 전이
WAIT_READ: ds18b20_is_busy() 체크만 하고 리턴. 읽기 완료되면 ds18b20_read_c()로 온도 계산 → IDLE로 복귀

어떤 상태에서도 while로 대기하지 않는다. main 루프가 블로킹 없이 계속 돌면서, 버튼 체크나 다른 작업을 동시에 수행할 수 있다.

g_temper와 temper_sensor_state는 main과 TIM3 인터럽트 양쪽에서 접근하므로 volatile을 붙여야 한다. 컴파일러 최적화로 인터럽트에서 변경된 값을 main이 인식하지 못하는 문제를 방지한다.

FND와의 공존

TIM3에서 ds18b20_is_busy 체크

// stm32f1xx_it.c — TIM3_IRQHandler 내
if (!ds18b20_is_busy(&ds18)) {
    digit_temper((int)(g_temper / 10));
}

ds18b20_is_busy()가 true인 구간은 1-Wire 라이브러리가 실제로 GPIO를 제어하며 비트를 보내고 받는 구간이다. 이때만 FND 갱신을 스킵하고, 나머지 시간(변환 대기 800ms 등)에는 자유롭게 FND를 갱신한다.

강의에서 write_bit 단위까지 내려가서 수동으로 구현했던 것을, 라이브러리 API 한 줄로 대체한 것이다. 라이브러리 소스를 수정할 필요가 전혀 없다.

FND 깜빡임 없는 온도 표시

리팩토링 과정에서 만난 문제들

1. HardFault — done_cb 미초기화

// 수정 전 — 쓰레기 값
ow_init_t ow_init_struct;
ow_init_struct.tim_handle = &htim2;
// done_cb을 설정하지 않음 → 쓰레기 주소

// 수정 후 — 0으로 초기화
ow_init_t ow_init_struct = {0};
ow_init_struct.tim_handle = &htim2;

스택 변수를 초기화하지 않으면 done_cb에 쓰레기 주소가 들어간다. 1-Wire 전송 완료 시 라이브러리가 이 콜백을 호출하면서 존재하지 않는 메모리로 점프 → HardFault가 발생했다. = {0}으로 초기화하면 done_cb이 NULL이 되어 호출을 건너뛴다.

실제로 디버그 모드에서 Memory 뷰(Window → Show View → Memory)를 열어 ow_init_struct의 메모리를 확인하면, 초기화하지 않았을 때 done_cb 위치에 쓰레기 값이 들어있는 것을 확인할 수 있다.

Memory 뷰 — done_cb 쓰레기 값

C 언어에서 구조체를 스택에 선언할 때는 항상 = {0}으로 초기화하는 습관을 들이자. 특히 함수 포인터가 포함된 구조체는 쓰레기 값이 치명적이다.

2. ds18b20_read_c()의 리턴값 단위

ds18b20_read_c()는 온도 × 100 값을 리턴한다 (예: 25.06°C → 2506). 릴레이 제어에서 m_fixed_temper(정수, 예: 25)와 비교할 때 단위를 맞춰야 한다.

// heater_controller.c
void heaterControl(int16_t temper) {
    // temper는 x100 단위
    if (m_state) {
        if ((int)temper >= (m_fixed_temper - PRE_OFF_GAP) * 100) {
            heaterOnOff(OFF_t);
        }
    } else {
        if ((int)temper < (m_fixed_temper - RE_ON_GAP) * 100) {
            heaterOnOff(ON_t);
        }
    }
}

리팩토링된 고추건조기 완성

상태머신에서 온도 읽기가 완료되는 시점(WAIT_READ → IDLE 전이)에 히터 제어 로직을 연동했다.

case TEMPER_SENSOR_STATE_WAIT_READ:
    if (!ds18b20_is_busy(&ds18)) {
        g_temper = ds18b20_read_c(&ds18);
        if (getSwState() == ON_t) {
            heaterControl(g_temper);
        } else {
            if (getHeaterState() == ON_t) {
                heaterOnOff(OFF_t);
            }
        }
        temper_sensor_state = TEMPER_SENSOR_STATE_IDLE;
    }
    break;

전원 스위치 ON 상태에서만 온도 기반 릴레이 제어가 동작하고, 스위치 OFF 시에는 히터가 강제 정지된다. 이전 코드의 로직 그대로이지만, 블로킹 없는 상태머신 안에 자연스럽게 통합되었다.

[VIDEO: 리팩토링된 고추건조기 전체 동작]

오프닝

UP/DOWN/FIX 스위치 조작

Start 스위치 ON

OFF 전환

다시 ON 전환

ON 상태에서 Start 스위치 DOWN

결과 및 비교

항목	이전 버전 (강의)	현재 버전 (리팩토링)
라이브러리 수정	필요 (ds18b20.c, onewire.c 직접 수정)	불필요 (API 호출만)
is_busy 구현	수동 플래그 추가, write_bit 단위 락	`ds18b20_is_busy()` 내장
크리티컬 섹션	수동 관리 (락 범위 시행착오)	라이브러리가 내부 처리
main 루프	블로킹 대기 (`while (!AllDone)`)	Non-Blocking 상태머신
FND 충돌	락 범위에 따라 깜빡임 발생 가능	`is_busy` 한 줄로 해결
코드 구조	ManualConvert를 3~6개 함수로 수동 분해	switch 상태머신으로 깔끔하게 분리

느낀 점

강의에서 이전 버전 라이브러리를 직접 뜯어서 write_bit 단위까지 내려가본 경험이 있었기 때문에, 현재 버전의 ds18b20_is_busy()가 내부적으로 무엇을 보호하는지 이해할 수 있었다. 단순히 API를 호출하는 것과, 그 API가 왜 그렇게 설계되었는지 이해하는 것은 다르다.

Non-Blocking 설계는 임베디드에서 매우 중요하다. OS 없는 베어메탈 환경에서 여러 장치를 동시에 제어하려면, "호출하고 즉시 빠져나와서 다른 일을 하고, 나중에 완료를 확인한다"는 패턴이 필수적이다. 이번 리팩토링이 그 패턴을 직접 경험하는 좋은 기회였다.

[오제이 튜브 임베디드 강의] 40. 클라스가 다른 ADC 강의

onebrotravel — Wed, 6 May 2026 21:39:16 +0900

가변 저항 회로 연결

가변저항 데이터시트

이전 글("너무나도 중요한 ADC")에서 ADC의 이론을 다뤘다. 이번에는 가변 저항을 이용하여 실제로 ADC를 사용한다.

가변 저항은 돌리면 저항값이 변하고, 이에 따라 출력 전압이 변하는 부품이다. 3개의 핀이 있다.

핀	연결	역할
1번	3.3V	입력 전압
2번	PA2 (ADC 입력)	가변 저항에 따라 0~3.3V 변화
3번	GND	접지

테스터기로 확인하면, 1번-3번 사이에 약 3.29V가 측정되고, 2번 핀의 전압은 가변 저항을 조절함에 따라 0V ~ 3.29V까지 변화한다. 이 가변 저항 대신 온도 센서, 습도 센서 등 다른 아날로그 센서를 연결하면 다양한 측정이 가능하다.

가변 저항 회로 빵판 배선

ADC 설정

.ioc 설정

ADC 설정 화면

STM32CubeIDE에서 PA2를 ADC1 채널 2로 설정하고, 다음과 같이 옵션을 구성한다.

설정 항목	값	의미
Mode	Independent	ADC1, ADC2 독립 동작
Data Alignment	Right	12비트 값을 오른쪽 정렬로 저장
Continuous Conversion	Enable	변환 완료 후 자동으로 다음 변환 시작
External Trigger	Software	소프트웨어로 변환 시작
Channel	2 (PA2)	입력 채널

ADC 클럭 제한

데이터시트에 따르면 ADC 클럭은 최대 14MHz로 제한된다. 72MHz 시스템 클럭에서 적절히 분주하여 12MHz로 설정해야 한다. 이 값을 초과하면 .ioc에서 경고가 발생한다.

기본 코드 구현 (폴링 방식)

// main.c
uint32_t adc_value = 0;
float voltage = 0.0f;

HAL_ADC_Start(&hadc1);

while (1) {
    if (HAL_ADC_PollForConversion(&hadc1, 100) == HAL_OK) {
        adc_value = HAL_ADC_GetValue(&hadc1);
        voltage = (float)adc_value / 4096.0f * 3.3f;
    }
    printf("ADC: %lu, Voltage: %.2fV\r\n", adc_value, voltage);
    HAL_Delay(500);
}

HAL_ADC_Start — ADC 변환 시작
HAL_ADC_PollForConversion — 변환 완료 대기 (폴링)
HAL_ADC_GetValue — 변환된 디지털 값 획득 (0~4095)
전압 계산: 값 ÷ 4096 × 3.3V

가변 저항을 돌리면 ADC 값과 전압이 실시간으로 변하는 것을 확인할 수 있다.

데이터시트 분석

12비트 = 4096단계

이전 글("너무나도 중요한 ADC")에서 다뤘던 분해능(Resolution) 개념이 여기서 적용된다. 12비트 ADC는 0~3.3V를 2¹² = 4096단계로 나눈다. 1단계(1 LSB)는 3.3V ÷ 4096 ≒ 0.8mV다.

VREF — 기준 전압

핀	연결	의미
VREF+	VDDA (3.3V)	ADC가 측정할 수 있는 최대 전압
VREF-	VSSA (GND)	측정 시작점 (0V)

데이터시트에 따르면 VREF의 허용 범위는 2.4V ~ 3.6V다.

VDD / VCC / VSS / VSSA 용어 정리

용어	의미	유래
VDD	+ 전원 (디지털)	MOSFET의 Drain
VCC	+ 전원	BJT의 Collector
VSS	GND (디지털)	MOSFET의 Source
VSSA	GND (아날로그)	아날로그 회로용 GND
VDDA	+ 전원 (아날로그)	아날로그 회로용 전원

현대 회로에서는 VDD/VCC, VSS/GND를 거의 같은 의미로 사용한다. 핵심은 VDD/VCC = 플러스 전압, VSS/VSSA = 그라운드라는 것이다.

ADC 동작 모드 정리

스캔 / 연속 / 불연속

모드	동작	용도
Scan Conversion	여러 채널을 순차적으로 자동 변환	다채널 센서 읽기
Continuous Conversion	변환 완료 후 자동으로 다음 변환 시작	실시간 연속 측정
Discontinuous Conversion	수동 제어로 필요할 때만 변환	전력 절약

Regular vs Injected

모드	레지스터	최대 채널	특징
Regular	1개 공유	16개	폴링이 아니면 데이터 혼동 가능
Injected	채널별 개별	4개	정확하지만 채널 수 제한

Regular 모드는 하나의 데이터 레지스터를 여러 채널이 공유하므로, 폴링으로 즉시 읽지 않으면 다음 채널의 값으로 덮어써질 수 있다. Injected 모드는 각 채널마다 별도 레지스터가 있어 안전하지만 최대 4개까지만 지원한다.

기타 기능

External Trigger: 소프트웨어 또는 타이머로 변환 시작 시점 제어
Watchdog: 특정 전압 범위를 벗어나면 인터럽트 발생. 이전 글("온도센서 검증하기")에서 다뤘던 Threshold 개념과 유사

DMA를 이용한 고속 처리

DMA란

DMA(Direct Memory Access)는 CPU의 개입 없이 ADC 변환 결과를 자동으로 메모리에 기록하는 방식이다. 폴링처럼 CPU가 매번 값을 읽어올 필요 없이, 하드웨어가 알아서 메모리에 써준다.

DMA 설정

설정 항목	값	의미
Mode	Circular	지속적으로 기록 (Normal은 한 번만)
Data Width	Half Word (16비트)	12비트 ADC 값 저장에 적합
Memory Address Increment	다채널 시 Enable	채널별로 다른 메모리 주소에 기록

DMA 코드

// main.c
uint16_t adc_dma_value = 0;

HAL_ADC_Start_DMA(&hadc1, (uint32_t*)&adc_dma_value, 1);

while (1) {
    float voltage = (float)adc_dma_value / 4096.0f * 3.3f;
    printf("ADC: %u, Voltage: %.2fV\r\n", adc_dma_value, voltage);
    HAL_Delay(500);
}

HAL_ADC_Start_DMA를 한 번 호출하면, 이후 adc_dma_value에 자동으로 최신 값이 업데이트된다. while 루프에서는 변수를 읽기만 하면 된다.

DMA 오류 및 해결

문제 발생

DMA를 적용한 후 ADC 값이 정상적으로 읽히지 않는 문제가 발생했다. 코드를 변경한 적이 없는데도 오류가 발생했다.

원인 — 인터럽트 충돌

원인은 기존 프로젝트에서 사용 중이던 다른 인터럽트들(타이머, EXTI 등)과의 충돌이었다. PA2 설정이나 샘플링 사이클 등 ADC 자체의 문제는 아니었다.

해결

불필요한 타이머 인터럽트 등을 모두 비활성화하고, ADC + DMA만 동작하도록 설정을 정리하자 정상 동작했다. 가변 저항을 조절하면 3.29V까지 값이 변하며, 실측값과도 일치한다.

ADC를 학습할 때는 기존 프로젝트(여러 인터럽트가 활성화된 상태)보다 새 프로젝트를 생성하여 ADC만 단독으로 테스트하는 것이 좋다. 인터럽트 간 충돌은 원인 추적이 어렵고, 학습 목표에서 벗어나기 쉽다.

DMA 정상 동작

전체 강의 시리즈 마무리

이 글로 임베디드 입문 강의 시리즈 전체가 완료되었다. 약 40시간에 걸쳐 다음을 학습했다.

전기 기본 상식부터 GPIO, 비트 연산, 데이터시트 읽기
SPI, 1-Wire, I2C, UART 4가지 통신 방식
온도 센서, FND, OLED, 릴레이, 스위치, LED 제어
타이머 인터럽트, 크리티컬 섹션, 외부 인터럽트
최종 고추 건조기 프로젝트 완성
ADC 이론과 실습

[오제이 튜브 임베디드 강의] 39. 너무나도 중요한 ADC

onebrotravel — Wed, 6 May 2026 21:21:03 +0900

아날로그와 디지털

ADC를 이해하려면 먼저 아날로그와 디지털의 차이를 알아야 한다.

아날로그(Analog)는 물질이나 시스템의 상태를 연속적으로 변하는 물리량으로 나타낸 것이다. 예를 들어 온도를 그래프로 표현하면, 아무리 확대해도 그 사이에 모든 값이 연속적으로 존재하며 끊어지지 않는다.

디지털(Digital)은 연속적인 값을 0과 1로 표현하고 처리하는 방법이다. 아날로그처럼 모든 값을 저장하는 것은 불가능하므로, 중간 값들을 생략하여 저장한다. 이미지를 확대했을 때 픽셀이 깨지는 것이 대표적인 예다. 사람 눈에는 연결된 것처럼 보이지만, 사실은 빈 공간을 생략하고 촘촘하게 연결하여 아날로그를 흉내 내는 것이다. MP3, AVI, JPG 같은 파일들이 모두 아날로그 신호를 디지털로 변환한 결과물이다.

아날로그 vs 디지털 비교 다이어그램

ADC란

ADC(Analog to Digital Converter)는 아날로그 신호를 디지털 신호로 변환하여 컴퓨터가 처리할 수 있게 만드는 기술이다. 컴퓨터(MCU 포함)는 0과 1의 디지털만 처리할 수 있으므로, 현실 세계의 연속적인 물리량(온도, 압력, 빛, 소리 등)을 다루려면 ADC가 반드시 필요하다.

이전 글("데이터시트 읽어주는 남자")에서 STM32의 Features 중 "2x 12-bit ADC"를 다뤘는데, 이것이 바로 칩에 내장된 ADC 기능이다. 또한 이전 글("온도센서를 붙여보자")에서 "순수 센서 vs 모듈"을 비교할 때, 순수 센서는 ADC로 전압 변화를 직접 측정해야 하는 고난도 방식이라고 언급했다. 이번 강의에서 그 ADC 개념을 본격적으로 다룬다.

ADC 활용 사례

디지털 온도계

특정 쇠막대기(프로브)가 온도 변화에 따라 저항값이 변하는 특성을 발견
저항값 변화는 회로를 통해 전압값 변화로 이어짐
MCU에 내장된 ADC로 이 전압값을 디지털 숫자로 변환
변환된 숫자를 온도 변환 테이블과 대조하여 현재 온도를 계산
화면에 온도 표시

이전 글("온도센서를 붙여보자")에서 우리가 사용한 DS18B20 모듈은 이 과정을 모듈 내부에서 처리해줬지만, 순수 센서를 사용한다면 이 전체 과정을 직접 구현해야 한다.

스트레인 게이지

스트레인 게이지는 누르는 힘에 따라 저항값이 변하는 소자다. 활용 예시:

파이프 모니터링: 파이프에 부착하여 변형을 감지. ADC로 전압 변화를 측정하여 파손 위험을 경고
로드셀(체중계): 무게에 따른 저항 변화를 ADC로 측정하여 몸무게 계산
IoT 센서: 습도 센서, 조도 센서 등 대부분의 아날로그 센서가 같은 원리

결국 저항 변화 → 전압 변화 → ADC → 디지털 값이라는 원리는 모두 동일하다.

ADC 변환 3단계

아날로그 신호를 디지털로 변환하는 과정은 크게 세 단계로 나뉜다.

1단계: 필터링

신호에서 노이즈를 제거하는 전처리 작업이다. 실제 신호에는 원하지 않는 잡음이 섞여 있으므로, 변환 전에 걸러낸다.

2단계: 샘플링 (X축 — 시간)

아날로그 신호를 얼마나 자주 측정할 것인지 결정한다.

샘플링 간격이 좁을수록: 원본 신호에 가까움 → 음질/화질 좋음 → 용량 큼
샘플링 간격이 넓을수록: 원본과 차이 발생 → 음질/화질 낮음 → 용량 작음

음악으로 비유하면, CD 품질(44.1kHz)은 1초에 44,100번 샘플링하고, 전화 품질(8kHz)은 1초에 8,000번만 샘플링한다.

3단계: 양자화 (Y축 — 값의 단위)

측정된 값을 얼마나 세밀하게 나눌 것인지 결정한다.

나누는 단위가 촘촘할수록: 원본에 가까움 → 용량 큼
나누는 단위가 거칠수록: 원본과 차이 발생 → 용량 작음

양자화 이후에는 부호화(인코딩)를 통해 측정된 좌표 값을 0과 1의 이진수로 변환하여 저장하거나 전송한다.

샘플링(X축) vs 양자화(Y축) 비교 다이어그램

분해능 (Resolution)

분해능은 ADC가 얼마나 세밀하게 값을 표현할 수 있는지를 나타내며, 비트 수로 표현한다.

비트 수	경우의 수	설명
8비트	2⁸ = 256	256단계로 구분
10비트	2¹⁰ = 1,024	1,024단계로 구분
12비트	2¹² = 4,096	4,096단계로 구분 (STM32)
16비트	2¹⁶ = 65,536	65,536단계로 구분

STM32의 ADC는 12비트이므로, 0~3.3V 전압을 4,096단계로 나눌 수 있다. 1단계(1 LSB)의 전압 분해능은 3.3V ÷ 4096 ≒ 0.0008V(약 0.8mV)다.

비트 수가 높을수록 원본에 가까운 디지털 값을 얻을 수 있지만, 데이터 용량과 처리 시간이 늘어나는 트레이드오프가 있다.

이전 글("SPI통신 제대로 배워보자")에서 다뤘던 "타임베이스 vs 클럭"처럼, 샘플링은 X축(시간)을, 양자화는 Y축(값)을 얼마나 촘촘하게 나누느냐의 문제다. 결국 얼마나 촘촘하게 측정하느냐에 따라 용량과 정확도가 달라진다는 원리는 통신이든 ADC든 동일하다.

[오제이 튜브 임베디드 강의] 38. 고추건조기 보드완성

onebrotravel — Wed, 6 May 2026 21:08:13 +0900

버튼 더블클릭 해결

이전 글("보드 완성까지 두번 남았다")에서 버튼으로 온도를 설정하고 릴레이를 제어하는 기본 골격을 완성했다. 이번에는 디테일을 다듬어 실제 사용 가능한 수준으로 마무리한다.

첫 번째 문제는 버튼을 한 번 눌렀는데 여러 번 입력되는 현상(더블클릭/채터링)이다. 스위치 접점이 물리적으로 튀면서 인터럽트가 여러 번 발생하기 때문이다.

소프트웨어적 해결

HAL_GetTick()으로 이전 버튼 입력 시간을 저장하고, 현재 시간과의 차이가 200ms 미만이면 무시하도록 구현한다.

// stm32f1xx_it.c
static uint32_t m_button_before_time = 0;

void EXTI0_IRQHandler(void) {
    HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);

    uint32_t now = HAL_GetTick();
    if (now - m_button_before_time < 200) return;  // 200ms 이내면 무시
    m_button_before_time = now;

    g_f_sw_up = 1;
}

모든 버튼(Up/Down/Fix)에 동일하게 적용한다. 200이라는 값은 #define BUTTON_GAP 200으로 정의하여 개발자가 쉽게 조절할 수 있게 한다.

하드웨어적으로는 스위치 출력에 캐패시터를 달아 LPF(Low Pass Filter) 필터링을 하면 해결되지만, 부품이 없으므로 소프트웨어로 처리했다. 실제 제품 설계 시에는 HW/SW 양쪽을 모두 고려하는 것이 좋다.

전원 스위치 기능

PB12에 연결된 Start 스위치는 장비 전체의 on/off를 제어한다. 이 스위치는 토글 방식(왔다 갔다)이라 인터럽트보다 폴링으로 현재 상태를 읽는 것이 적합하다.

// buttonController.c
uint8_t getSwState(void) {
    if (HAL_GPIO_ReadPin(PB12_START_SW_GPIO_Port, PB12_START_SW_Pin) == GPIO_PIN_RESET) {
        return 1;  // LOW = 켜짐
    }
    return 0;  // HIGH = 꺼짐
}

이 함수를 TIM3 인터럽트에서 주기적으로 호출하여 스위치 상태에 따라 LED1을 제어한다. 스위치를 ON으로 밀면 LED가 켜지고, OFF로 밀면 꺼진다.

전원 스위치 ON/OFF에 따른 LED 동작

화면 깜빡임 피드백

Fix 버튼을 누르면 OLED 화면이 4번 깜빡이도록 하여, 사용자에게 "온도가 저장되었다"는 피드백을 제공한다.

// oledController.c
static uint8_t m_toggle = 0;
static uint8_t m_toggle_count = 0;
static uint32_t m_toggle_timer = 0;

void startToggle(void) {
    m_toggle_count = 8;  // 켜짐/꺼짐 각 1번 = 2, 4번 깜빡임 = 8
}

void toggleScreen(void) {
    if (m_toggle_count == 0) return;

    uint32_t now = HAL_GetTick();
    if (now - m_toggle_timer < TOGGLE_TIME) return;
    m_toggle_timer = now;

    m_toggle = !m_toggle;
    if (m_toggle) {
        SSD1306_Fill(SSD1306_COLOR_BLACK);
    } else {
        printBackground();
    }
    SSD1306_UpdateScreen();

    if (m_toggle_count > 0) m_toggle_count--;
}

버그 수정

구현 과정에서 두 가지 버그가 발생했다.

m_toggle_count overflow: 0보다 클 때만 감소시키도록 조건 추가
깜빡이는 도중 온도 업데이트: 화면이 꺼진 상태에서 온도 표시 함수가 호출되어 잘못된 화면이 나타남 → m_toggle_count == 0일 때만 온도 업데이트가 실행되도록 수정

OLED 상태 표시 개선

히터 상태 출력

히터의 ON/OFF 상태를 OLED에 표시하고, LED2도 연동한다.

// oledController.c
void printHeaterState(uint8_t state) {
    SSD1306_GotoXY(0, 40);
    if (state) {
        SSD1306_Puts("Heater: ON ", &Font_7x10, 1);
        HAL_GPIO_WritePin(LED2_GPIO_Port, LED2_Pin, GPIO_PIN_RESET);  // LED ON
    } else {
        SSD1306_Puts("Heater: OFF", &Font_7x10, 1);
        HAL_GPIO_WritePin(LED2_GPIO_Port, LED2_Pin, GPIO_PIN_SET);    // LED OFF
    }
    SSD1306_UpdateScreen();
}

디폴트 온도 표시

초기 화면에 0도가 아닌 디폴트 설정 온도(25도)가 표시되도록 printBackground 함수에서 getFixedTemper()를 호출하여 온도를 출력한다.

OLED 종합 화면 — 설정/현재 온도/히터 상태

전원 스위치-히터 연동

전원 스위치가 OFF일 때는 히터가 무조건 꺼지도록 안전 로직을 추가한다. 설정 온도에 도달하지 않았더라도 사용자가 스위치를 끄면 히터가 즉시 정지해야 한다.

// heaterController.c
void heaterOnOff(void) {
    if (!getSwState()) {
        // 스위치 OFF → 히터 강제 OFF
        if (heater_state == 1) {
            HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, GPIO_PIN_RESET);
            heater_state = 0;
            printHeaterState(0);
        }
        return;
    }

    // 스위치 ON일 때만 온도 기반 제어
    float current_temp = get_current_temp();
    int fixed_temp = getFixedTemper();
    // ... 온도 비교 로직
}

미리 끄기 (Pre-off)

이전 글("난방실 만들기")에서 언급했던 오버슈트 문제를 해결한다. 설정 온도에 정확히 도달한 시점에 히터를 끄면, 잔열로 온도가 더 올라간다. 따라서 설정 온도에 도달하기 전에 미리 끈다.

#define PRE_OFF_GAP  5   // 설정 온도와의 차이가 5도 이하면 OFF
#define RE_ON_GAP    3   // 설정 온도와의 차이가 3도 이상이면 다시 ON

void heaterOnOff(void) {
    // ... 스위치 체크 로직 ...

    float current_temp = get_current_temp();
    int fixed_temp = getFixedTemper();

    if (heater_state == 1 && (fixed_temp - current_temp) <= PRE_OFF_GAP) {
        // 히터 ON 상태에서 목표와의 차이가 5도 이하 → OFF
        HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, GPIO_PIN_RESET);
        heater_state = 0;
        printHeaterState(0);
    }
    else if (heater_state == 0 && (fixed_temp - current_temp) >= RE_ON_GAP) {
        // 히터 OFF 상태에서 목표와의 차이가 3도 이상 → ON
        HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, GPIO_PIN_SET);
        heater_state = 1;
        printHeaterState(1);
    }
}

PRE_OFF_GAP과 RE_ON_GAP 값은 #define으로 정의하여 쉽게 조절할 수 있다. 이 값을 환경에 맞게 반복적으로 조정하는 작업이 실제 개발에서 가장 많은 시간이 소요되는 부분이다.

미리 끄기 동작 — 도달 전 OFF, 차이 벌어지면 ON

시리즈 마무리

37강에 걸친 고추 건조기 프로젝트가 완성되었다. 전체 시리즈에서 다룬 내용을 정리하면:

영역	학습 내용
기초	전기 상식, GPIO, 비트 연산, Startup Code, 데이터시트, 회로도
디버깅	멀티미터, 오실로스코프, UART printf, Live Expression
통신	SPI(FND), 1-Wire(온도센서), I2C(OLED), UART(디버깅)
주변장치	FND, 온도센서(DS18B20), 릴레이, LED, 스위치, OLED(SSD1306)
소프트웨어	타이머 인터럽트, 크리티컬 섹션, 외부 인터럽트, 파일 구조 분리
프로젝트	온도 측정 → FND/OLED 표시 → 버튼 설정 → 릴레이 제어 → 완전체 통합

이 정도 수준의 회로도를 혼자서 구성하고, 코드를 작성하고, 문제를 해결할 수 있다면 신입 임베디드 개발자로서 충분히 경쟁력 있다고 강사도 강조한다. 바닥부터 직접 만들어보는 경험이 가장 중요하다.

시운전 영상

완성된 고추 건조기 보드의 전체 동작을 단계별로 확인한다.

1. 오프닝 — 전원 인가 및 OLED 로고

전원을 인가하면 OLED에 커스텀 로고가 표시된 뒤, 디폴트 설정 온도(25°C)가 표시되는 기본 화면으로 전환된다.

[VIDEO: 전원 인가 → OLED 로고 → 기본 화면 전환]

2. Start 스위치 ON

Start 스위치를 ON으로 밀면 LED1이 켜지며 장비가 동작 대기 상태에 들어간다.

Start 스위치 ON → LED1 점등

3. Up/Down/Fix 스위치로 온도 설정

Up/Down 버튼으로 목표 온도를 조절하고, Fix 버튼을 누르면 OLED가 4번 깜빡이며 온도가 확정된다. 확정된 온도가 OLED에 표시된다.

Up/Down 온도 조절 → Fix → 화면 깜빡임 → 온도 확정

4. 드라이기 작동 및 온도 상승

설정 온도보다 현재 온도가 낮으므로 릴레이가 동작하여 드라이기가 켜진다. OLED에 "Heater: ON"이 표시되고, LED2가 켜진다. FND에 실시간 온도가 올라가는 모습이 보인다.

릴레이 ON → 드라이기 작동 → OLED ON + LED2 점등 → FND 온도 상승

5. 설정 온도 근접 — 드라이기 자동 정지

현재 온도가 m_fixed_temper - PRE_OFF_GAP에 도달하면, 오버슈트를 방지하기 위해 드라이기가 자동으로 꺼진다. OLED에 "Heater: OFF"로 전환되고, LED2가 꺼진다.

설정 온도 근접 → 릴레이 OFF → OLED OFF + LED2 소등

6. 온도 하강

드라이기가 꺼진 후 자연 냉각으로 온도가 서서히 내려간다. FND에 온도가 내려가는 모습이 보인다.

FND 온도 자연 하강

7. 온도 차이 벌어짐 — 드라이기 자동 재작동

현재 온도가 m_fixed_temper - RE_ON_GAP 이상으로 떨어지면, 드라이기가 다시 켜진다. OLED에 "Heater: ON"으로 전환되고, LED2가 다시 켜진다. 이 on/off 반복으로 목표 온도 부근이 유지된다.

충분히 하강 → 릴레이 ON → OLED O N + LED2 점등 → 재상승

8. Start 스위치 OFF — 강제 정지

드라이기가 작동 중인 상태에서 Start 스위치를 OFF로 밀면, 릴레이가 즉시 해제되어 드라이기가 멈춘다. LED1과 LED2가 모두 꺼지고, OLED에 "Heater: OFF"가 표시된다.

동작 중 → 스위치 OFF → 릴레이 해제 → LED 소등 → 드라이기 정지

[오제이 튜브 임베디드 강의] 37. 보드 완성까지 두번 남았다

onebrotravel — Wed, 6 May 2026 20:51:56 +0900

GPIO SPI → HW SPI 전환

이전 글("드디어 완성되는 완전체 보드")에서 모든 모듈의 하드웨어 점검을 마쳤다. 이번에는 본격적인 코딩에 들어간다.

첫 번째로 해결할 문제는 FND가 올바로 켜지지 않는 현상이다. 장치가 늘어나면서 MCU의 작업량이 증가했고, GPIO로 직접 SPI 신호를 만드는 방식으로는 FND 갱신에 필요한 타이밍을 안정적으로 유지하기 어려워졌다.

이전 글("STM32에서는 SPI 기능을 제공한다구")에서 다뤘듯이, GPIO SPI를 칩에서 제공하는 HW SPI(HAL_SPI_Transmit)로 전환하면 MCU의 부담이 줄어든다. FND 제어 코드의 send 함수를 HAL_SPI_Transmit 한 줄로 교체하고, init_fnd에 SPI 핸들러를 인자로 넘기도록 수정한다.

// fnd_controller.c
void init_fnd(SPI_HandleTypeDef *hspi) {
    _hspi = hspi;
    // 매핑 테이블 초기화
}

void send(uint8_t X) {
    HAL_SPI_Transmit(_hspi, &X, 1, 100);
}

핀 배치도 HW SPI에 맞게 변경한다. 이 과정은 이전 글에서 상세히 다뤘으므로 참고한다.

코드 구조 정리

main.c에 모든 코드가 몰려 있으면 관리가 어렵다. 기능별로 파일을 분리하여 구조를 정리한다.

파일	역할
`oledController.c/h`	OLED 초기화, 로고 출력, 온도 표시
`buttonController.c/h`	버튼 인터럽트 처리, 온도 설정
`heaterController.c/h`	온도 센서 읽기, 릴레이 제어
`fnd_controller.c/h`	FND 제어 (기존)
`g_var.h`	전역 변수 선언
`ex_var.h`	extern 선언

main.c에서는 각 컨트롤러의 초기화 함수를 호출하고, while 루프에서 버튼 체크와 온도 제어만 수행하는 깔끔한 구조가 된다.

OLED에 온도 표시

Print_Temp 함수

OLED에 온도를 표시하는 함수를 oledController.c에 구현한다.

// oledController.c
#include <stdio.h>

void printTemper(int temper) {
    char buf[16];
    sprintf(buf, "Temp: %02d", temper);
    SSD1306_GotoXY(0, 0);
    SSD1306_Puts(buf, &Font_11x18, 1);
    SSD1306_UpdateScreen();
}

sprintf로 숫자를 문자열로 변환하고, SSD1306_Puts로 버퍼에 쓴 뒤, SSD1306_UpdateScreen으로 화면을 갱신한다. 이전 글("내 로고는 내가 만든다")에서 다뤘던 "버퍼에 그리고 → UpdateScreen으로 전송" 패턴 그대로다.

Opening 함수

시작 시 로고를 표시한 후 기본 화면으로 전환하는 흐름을 함수로 묶는다.

void oled_opening(void) {
    SSD1306_Init();
    SSD1306_InvertDisplay(1);
    // 로고 애니메이션 출력
    SSD1306_DrawBitmap(0, 0, my_logo_1, 128, 64, 1);
    SSD1306_UpdateScreen();
    HAL_Delay(1000);
    // 기본 화면으로 전환
    printDefault();
}

버튼으로 온도 설정

두 가지 온도 변수

변수	역할
`m_desired_temper`	Up/Down 버튼으로 조절 중인 온도
`m_fixed_temper`	Fix 버튼으로 확정한 목표 온도

디폴트 온도는 헤더 파일에 DEFAULT_TEMP = 25로 정의한다.

buttonController

// buttonController.c
static int m_desired_temper = DEFAULT_TEMP;
static int m_fixed_temper = DEFAULT_TEMP;

void checkButton(void) {
    if (g_f_sw_up) {
        g_f_sw_up = 0;
        if (m_desired_temper < 99) m_desired_temper++;
        printTemper(m_desired_temper);
    }
    if (g_f_sw_down) {
        g_f_sw_down = 0;
        if (m_desired_temper > 0) m_desired_temper--;
        printTemper(m_desired_temper);
    }
    if (g_f_sw_fix) {
        g_f_sw_fix = 0;
        m_fixed_temper = m_desired_temper;
    }
}

int getFixedTemper(void) {
    return m_fixed_temper;
}

Up 버튼을 누르면 온도가 1도 올라가고, Down 버튼으로 1도 내려간다. 0~99도 범위를 벗어나지 않도록 제한한다. Fix 버튼을 누르면 현재 조절 중인 온도가 목표 온도로 확정된다.

OLED Up/Down 온도 조절

설정 온도 기반 릴레이 제어

제어 로직

이전 글("난방실 만들기")에서는 하드코딩된 45~50도 범위로 제어했다. 이번에는 버튼으로 설정한 목표 온도와 현재 온도를 비교하여 릴레이를 제어한다.

// heaterController.c
void heaterOnOff(void) {
    float current_temp = get_current_temp();
    int fixed_temp = getFixedTemper();

    if (current_temp < (float)fixed_temp) {
        // 현재 온도 < 설정 온도 → 드라이기 ON
        HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, GPIO_PIN_SET);
    } else {
        // 현재 온도 ≥ 설정 온도 → 드라이기 OFF
        HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, GPIO_PIN_RESET);
    }
}

main 루프

// main.c
oled_opening();
Ds18b20_Init_Simple();
init_fnd(&hspi2);
HAL_TIM_Base_Start_IT(&htim3);

int m_count = 0;

while (1) {
    checkButton();

    m_count++;
    if (m_count >= 10) {  // 약 1초마다
        m_count = 0;
        heaterOnOff();
    }

    HAL_Delay(100);
}

온도를 1초마다 확인하여 릴레이를 제어한다. 100ms마다 버튼을 체크하고, 10번째 루프(≒1초)마다 온도를 읽어 릴레이를 on/off한다.

임베디드 개발의 특징

이번 강의로 고추 건조기의 핵심 골격이 완성되었다. 강사는 임베디드 개발에서 "길 뚫기" — 하드웨어 장치를 코드로 제어할 수 있는 환경을 만드는 과정 — 가 전체 시간의 80% 이상을 차지한다고 강조한다. 지금까지 35강에 걸쳐 해온 것이 바로 이 "길 뚫기"였고, 응용 소프트웨어(버튼으로 온도 설정, 릴레이 제어 로직 등)는 상대적으로 빠르게 구현할 수 있다.

다음 글에서는 이 기본 골격을 더 다듬어 실제 사용 가능한 수준으로 마무리한다.

[오제이 튜브 임베디드 강의] 36. 드디어 완성되는 완전체 보드

onebrotravel — Wed, 6 May 2026 20:39:56 +0900

완전체 보드의 목표

지금까지 각 모듈을 개별적으로 다뤄왔다. 이번 강의에서는 모든 모듈을 하나의 보드에 통합하고, 각각이 정상 동작하는지 점검한다. 회로도 v4 기준으로 진행하며, 이전 버전과 핀 배치가 일부 변경되었으므로 주의가 필요하다.

전체 핀 배치 요약

모듈	핀	이전 글
스위치 (Up/Fix/Down)	PB0 / PB1 / PB2	"내 힘으로 LED 회로 만들어서 제어하기"
스위치 (Start)	PB12	-
UART TX	PA9	"printf도 쉽지 않다구"
LED × 2	PB6 / PB7	"내 힘으로 LED 회로 만들어서 제어하기"
OLED (I2C)	PB10(SCL) / PB11(SDA)	"배운 I2C로 OLED를 제어해보자"
온도 센서 (1-Wire)	PA2 (v4에서 변경)	"1-Wire 통신"
FND (SPI)	PB15(SCLK) / PB13(RCLK) / PB14(DIO)	"STM32에서는 SPI기능을 제공한다구"
릴레이	PB5	"드라이기를 내 맘대로 껐다, 켰다 해보자"

완성된 회로도 v4 전체

스위치 점검 및 인터럽트 전환

스위치 배선

회로도에 따라 PB0(Up), PB1(Fix), PB2(Down) 세 개의 스위치를 빵판에 구성한다. 이 스위치들은 최종적으로 목표 온도를 올리고 내리며, 설정을 저장하는 기능을 수행한다.

스위치 3개 빵판 구성

폴링 → 인터럽트 전환

처음에는 HAL_GPIO_ReadPin으로 스위치 상태를 확인(폴링)했지만, 더 효율적인 동작을 위해 인터럽트 방식으로 전환한다.

설정 항목	값	이유
GPIO Mode	GPIO_EXTI	외부 인터럽트 사용
GPIO Trigger	Falling Edge	평상시 High → 버튼 누르면 Low. 하강 순간에 감지
NVIC 우선순위	3	다른 인터럽트와 우선순위 분리

글로벌 플래그 패턴

인터럽트 핸들러 안에서 printf 같은 긴 작업을 하면 문제가 발생할 수 있다. 대신 전역 변수(플래그)를 설정하고, main 루프에서 플래그를 확인하는 패턴을 사용한다.

// g_var.h — 전역 변수 선언
char g_f_sw_up = 0;
char g_f_sw_down = 0;
char g_f_sw_fix = 0;

// ex_var.h — extern 선언
extern char g_f_sw_up;
extern char g_f_sw_down;
extern char g_f_sw_fix;

// stm32f1xx_it.c — 인터럽트 핸들러
void EXTI0_IRQHandler(void) {
    HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);
    g_f_sw_up = 1;  // 플래그만 설정
}

// main.c — 메인 루프에서 처리
if (g_f_sw_up) {
    g_f_sw_up = 0;
    printf("UP 버튼 눌림\r\n");
}

PB1(Fix), PB2(Down)도 동일한 방식으로 설정한다.

PB12 (Start 스위치) 트러블슈팅

PB12에 연결한 Start 스위치가 처음에 동작하지 않았다. 원인은 택타일 스위치의 핀 배열을 잘못 연결한 것이었다. 이전 글("내 힘으로 스위치 회로 만들기")에서 다뤘듯이 택타일 스위치는 핀 1/3, 2/4가 내부적으로 연결된 쌍이다. 2번 핀이 GND에 연결되어야 하는데 1번 핀을 연결했던 것이 문제였다. 수정 후 정상 동작을 확인했다.

UART 통신 점검

PA9(USART TX)을 FTDI 모듈의 RX에 연결하고, GND를 공유한다. 시리얼 모니터에서 "Hello World"가 정상 출력되어 UART 통신에 문제가 없음을 확인했다.

LED 점검

PB6과 PB7에 LED를 연결한다. 이전 글("내 힘으로 LED 회로 만들어서 제어하기")에서 다뤘듯이 이 회로에서 LED는 GPIO가 Low일 때 켜지는 구조다.

HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_6);
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_7);
HAL_Delay(100);

0.1초 간격으로 LED가 빠르게 점멸하는 것을 확인했다.

OLED 점검

PB10(SCL)과 PB11(SDA)에 OLED 모듈을 연결한다. 이전 글("내 로고는 내가 만든다")에서 제작한 로고 출력 코드를 활성화하면, OLED에 로고가 정상 출력되는 것을 확인했다.

[IMG: OLED 로고 출력]

온도 센서 점검

회로도 v4에서 온도 센서의 DAT 핀이 PA3 → PA2로 변경되었다. 모듈의 DAT을 PA2에 연결한다.

초기 테스트에서 온도가 출력되지 않는 문제가 발생했다. 원인은 .ioc에서 PA2의 GPIO 설정이 변경되지 않았기 때문이었다. PA2를 GPIO Output으로 설정하고, ds18b20Config.h의 GPIO/PIN 정의도 PA2로 수정하면 해결된다.

수정 후 현재 온도(24.6°C)가 정상 출력되고, 프로브를 손으로 잡으면 온도가 올라가는 것을 확인했다.

[IMG: 온도 센서 정상 동작]

FND 점검

PB15(SCLK), PB13(RCLK), PB14(DIO)에 FND 모듈을 연결한다. 이전 글("쓰레드 흉내내기")에서 구현한 TIM3 타이머 인터럽트 기반 FND 코드를 활성화한다.

// main.c
init_fnd(&hspi2);
HAL_TIM_Base_Start_IT(&htim3);

FND에 현재 온도가 실시간으로 표시되는 것을 확인했다.

[IMG: FND 온도 표시]

릴레이 점검

PB5에 릴레이를 연결한다. Start 스위치(PB12) 인터럽트와 연동하여, 스위치를 누르면 릴레이가 토글되도록 한다.

// main.c
if (g_f_sw_on) {
    g_f_sw_on = 0;
    HAL_GPIO_TogglePin(PB5_RELAY_ON_OFF_CTRL_GPIO_Port,
                        PB5_RELAY_ON_OFF_CTRL_Pin);
}

초기에는 릴레이가 반응하지 않았으나, 전원을 뺐다 다시 꽂으니 딸깍 소리와 함께 정상 동작했다. 드라이기를 릴레이에 연결하여 스위치 조작으로 드라이기가 켜지고 꺼지는 최종 테스트를 성공적으로 마쳤다.

릴레이 + 드라이기 최종 동작

정리

이번 강의로 고추 건조기에 필요한 모든 하드웨어 구성과 검증이 완료되었다.

모듈	상태	핵심 학습 내용
스위치 × 4	✅	GPIO Input → EXTI 인터럽트, Falling Edge, 글로벌 플래그
UART	✅	printf 디버깅
LED × 2	✅	GPIO Output, Toggle
OLED	✅	I2C 통신, SSD1306 라이브러리
온도 센서	✅	1-Wire 통신, DS18B20 라이브러리
FND	✅	SPI 통신, 타이머 인터럽트로 잔상 효과
릴레이	✅	트랜지스터 구동, Low Level Trigger

이 정도 수준의 회로도를 혼자서 구성하고 이해할 수 있다면 신입으로서 충분히 경쟁력 있다고 강사도 강조한다. 다음 글에서는 이 하드웨어를 바탕으로 본격적인 시스템 코딩에 들어간다.

[오제이 튜브 임베디드 강의] 35. 내 로고는 내가 만든다

onebrotravel — Wed, 6 May 2026 20:26:15 +0900

OLED 로고 출력의 목표

이전 글("배운 I2C로 OLED를 제어해보자")에서 SSD1306 라이브러리를 포팅하고, Fast Mode(400kHz)로 변경하여 OLED를 성공적으로 제어했다. 샘플 코드에 포함된 말 애니메이션과 Hello World가 출력되는 것을 확인했는데, 이번에는 샘플 이미지를 자신만의 로고로 교체한다.

로고 이미지 제작

OLED의 해상도가 128×64이므로, 로고 이미지도 128×64 픽셀로 만들어야 한다.

그림판 등 이미지 편집 도구를 열고, 캔버스 크기를 128×64로 설정
텍스트, 도형 등을 추가하여 원하는 로고를 디자인
흑백(모노크롬)으로 저장 — OLED가 흑백이므로 색상은 의미 없음

애니메이션 효과를 원한다면 여러 버전의 로고 이미지를 만들어둔다.

비트맵 변환 — image2cpp

만든 이미지를 코드에서 사용하려면 C 배열 형태로 변환해야 한다. image2cpp 사이트를 사용한다.

사이트에 이미지 업로드
Canvas size를 128×64로 설정
Generate code 클릭 → C 배열 코드가 생성됨

생성된 코드는 이전 글에서 다뤘던 OLED 메모리 구조(128바이트 × 8 page = 1024바이트)에 대응하는 배열이다. 각 바이트가 세로 8픽셀을 ON/OFF하는 구조 그대로다.

image2cpp — 이미지 업로드 및 코드 생성

코드 적용

헤더 파일 생성

기존 샘플의 horse_anim.h를 복사하여 새 헤더 파일(예: my_logo.h)을 만든다. 내부의 배열 데이터를 image2cpp에서 생성한 코드로 교체한다.

// my_logo.h
#ifndef MY_LOGO_H
#define MY_LOGO_H

const unsigned char my_logo_1[] = {
    // image2cpp에서 생성된 1024바이트 데이터
    0x00, 0x00, 0x00, ...
};

const unsigned char my_logo_2[] = {
    // 애니메이션용 두 번째 프레임
    0x00, 0x00, 0x00, ...
};

#endif

여러 버전의 로고가 있다면 배열을 my_logo_1, my_logo_2 등으로 나눈다.

main에서 출력

// main.c
#include "ssd1306.h"
#include "my_logo.h"

// main 함수 내
SSD1306_Init();
SSD1306_InvertDisplay(1);  // 색 반전: 검은 바탕에 흰색 그림

while (1) {
    SSD1306_DrawBitmap(0, 0, my_logo_1, 128, 64, 1);
    SSD1306_UpdateScreen();
    HAL_Delay(500);

    SSD1306_DrawBitmap(0, 0, my_logo_2, 128, 64, 1);
    SSD1306_UpdateScreen();
    HAL_Delay(500);
}

SSD1306_InvertDisplay(1)을 사용하면 검은 바탕에 흰색 그림으로 표시되어 더 선명하다. HAL_Delay로 프레임 간 딜레이를 주면 간단한 애니메이션이 된다.

OLED에 커스텀 로고 출력

OLED 내부 동작 분석

이전 글에서 OLED의 메모리 구조(page, 1024바이트)를 다뤘다. 이번에는 코드가 내부적으로 어떤 흐름으로 동작하는지 분석한다.

전체 흐름

핵심은 STM32 내부 버퍼에 먼저 그리고, UpdateScreen으로 한 번에 전송하는 구조다.

SSD1306_DrawBitmap / SSD1306_Puts 등 → 내부 버퍼(SSD1306_Buffer)에 데이터를 쓰기만 함
SSD1306_UpdateScreen → 버퍼의 1024바이트를 I2C로 한꺼번에 OLED 칩에 전송 → 화면 갱신

UpdateScreen 이전에 호출하는 함수들은 모두 화면에 쓸 데이터를 버퍼에 준비하는 과정이다.

DrawBitmap → DrawPixel → SSD1306_Buffer

SSD1306_DrawBitmap 함수는 비트맵 배열(image2cpp로 생성한 데이터)을 읽으면서, 각 픽셀에 대해 SSD1306_DrawPixel을 호출한다. DrawPixel은 x, y 좌표를 받아 SSD1306_Buffer의 해당 위치에 비트를 설정한다.

최종적으로 SSD1306_Buffer에 완성된 이미지가 담기고, UpdateScreen 내부의 WriteMulti 함수가 이 버퍼를 I2C로 전송한다.

PutChar — 텍스트 출력

SSD1306_Puts는 문자열을 한 글자씩 PutChar로 처리한다. PutChar는 아스키 코드 32번(스페이스)을 기준으로 폰트 데이터에서 해당 글자의 픽셀 정보를 가져와 DrawPixel로 버퍼에 점을 찍는다. 폰트 크기(Font_7x10, Font_11x18 등)에 따라 사용하는 픽셀 수가 달라진다.

스크롤링

스크롤링은 SSD1306 칩 자체에서 지원하는 하드웨어 명령어(0x26, 0x27 등)로 구현된다. 버퍼의 픽셀을 하나씩 옮기는 소프트웨어 방식보다 훨씬 효율적이다.

정리

이 글까지 해서 OLED 시리즈가 완결된다.

이제는 쉬워진 I2C 통신 — 클럭 기반 동기 방식, 7비트 주소, SCL/SDA 두 선
배운 I2C로 OLED를 제어해보자 — SSD1306 라이브러리 포팅, Fast Mode 필수, 128×64 = 1024바이트
이번 글 — image2cpp로 커스텀 로고 제작, 내부 동작 분석(버퍼 → UpdateScreen → I2C 전송)

다음 글에서는 지금까지 다룬 모든 모듈(온도 센서, FND, OLED, 스위치, LED, 릴레이)을 하나의 보드에 통합한다.

[오제이 튜브 임베디드 강의] 34. 배운 I2C로 OLED를 제어해보자!

onebrotravel — Wed, 6 May 2026 20:19:26 +0900

I2C 옵션 보충

이전 글("이제는 쉬워진 I2C 통신")에서 I2C의 기본 개념을 다뤘다. 이번에는 실제 설정에서 만나는 옵션들을 보충한다.

Fast Mode Duty Cycle

diagram_01_duty_cycle

이전 글에서 I2C는 Standard Mode(100kHz)와 Fast Mode(400kHz)가 있다고 다뤘다. Fast Mode에서는 Duty Cycle이 1:1이 아닌 1:2 또는 1:1.77로 설정된다.

400kHz는 1사이클이 2.5μs다. 이를 상승(High)과 하강(Low)으로 나누면 각각 1.25μs가 되어야 한다. 그런데 I2C를 정의한 NXP(구 필립스)의 사양에 따르면 Low 구간의 최소 유지 시간이 1.3μs 이상이어야 한다. 1.25μs로는 이 스펙을 충족하지 못하므로, Low 구간을 더 길게 잡아 1:2(High 0.83μs, Low 1.67μs) 또는 1:1.77 비율이 된다.

Clock No Stretch Mode

diagram_02_clock_stretch

Clock Stretch(클럭 스트레칭)는 Slave나 Master가 바쁠 때 클럭을 Low로 유지하여 통신을 일시 정지시키는 기능이다.

Slave가 스트레칭: 온도 센서처럼 데이터를 준비하는 데 시간이 필요한 경우, Slave가 클럭을 Low로 잡아두어 "잠깐 기다려"라고 알림
Master가 스트레칭: Master의 버퍼에 아직 처리하지 못한 데이터가 있는데 Slave가 새 데이터를 보내려 할 때, Master가 클럭을 멈춰 버퍼 덮어쓰기를 방지

STM32의 "Clock No Stretch Mode: Disabled"는 Stretch Mode를 사용하겠다(= 필요 시 클럭을 멈출 수 있다)는 의미다.

OLED 모듈 소개

이번 강의에서 사용하는 OLED 모듈의 사양:

항목	내용
크기	0.96인치
해상도	128 × 64 픽셀
드라이버 칩	SSD1306
통신	I2C (SCL, SDA)
동작 전압	3.3V ~ 5V
동작 전류	최대 20mA
시야각	160도

OLED는 FND와 달리 자체 메모리가 있어, 한 번 데이터를 보내면 화면이 계속 유지된다. FND처럼 잔상 효과를 위해 타이머 인터럽트로 계속 갱신할 필요가 없으므로, 이전 글들("쓰레드 흉내내기", "흉내낸 쓰레드 크리티컬 섹션 문제 해결")에서 겪었던 통신 충돌 문제가 발생하지 않는다. 온도 표시용으로는 OLED가 훨씬 적합하다.

라이브러리 포팅

파일 구성

강의에서 제공하는 SSD1306 라이브러리 파일을 프로젝트에 추가한다.

Lib/Inc 폴더:

ssd1306.h — OLED 제어 함수 선언
fonts.h — 폰트 데이터
test.h — 테스트 함수 선언
bitmap.h — 비트맵 이미지 데이터
horse_anim.h — 말 애니메이션 프레임 데이터

Lib/Src 폴더:

ssd1306.c — OLED 제어 함수 구현
fonts.c — 폰트 데이터
test.c — 테스트 함수 구현

Lib/Inc, Src 폴더 구조

I2C 핸들러 매크로 변경

샘플 코드에서는 hi2c1을 직접 사용하지만, 우리 프로젝트에서는 I2C2를 사용할 수 있다. 유연하게 대응하기 위해 ssd1306.h에 매크로를 정의한다.

// ssd1306.h
#include "main.h"

extern I2C_HandleTypeDef hi2c2;
#define H_I2C hi2c2

ssd1306.c 내의 모든 hi2c1을 H_I2C로 변경한다. 이렇게 하면 나중에 I2C 포트를 바꿀 때 매크로 한 줄만 수정하면 된다.

ssd1306.h — H_I2C 매크로 정의

OLED 메모리 구조

OLED의 128×64 해상도는 내부적으로 8개의 가로 띠(page)로 나뉜다. 각 page는 가로 128픽셀 × 세로 8픽셀의 영역이다. 화면 전체를 위에서 아래로 8개의 가로 띠로 잘라놓은 구조라고 생각하면 된다.

각 page 안에서 한 열(column)의 세로 8픽셀을 1바이트로 제어한다. 예를 들어 0b10110001을 보내면, 해당 열의 세로 8픽셀이 위에서부터 켜짐-꺼짐-켜짐-켜짐-꺼짐-꺼짐-꺼짐-켜짐으로 표시된다.

1 page = 가로 128열 × 세로 8픽셀 = 128바이트
화면 전체 = 세로 64픽셀 ÷ 8 = 8 page
총 데이터 = 128바이트 × 8 page = 1024바이트

SSD1306_UpdateScreen을 호출하면 이 1024바이트가 I2C로 한꺼번에 전송된다. Standard Mode(100kHz)에서 이 데이터 양이 문제를 일으킨 원인이기도 하다.

하드웨어 연결

OLED 핀	연결	보드 핀
GND	빵판 - 레일	GND
VCC	빵판 + 레일	3.3V
SCL	점퍼선	PB10
SDA	점퍼선	PB11

OLED 모듈 빵판·보드 배선

실패와 해결 — Standard → Fast Mode

문제 발생

라이브러리 포팅과 하드웨어 연결을 마치고, main에서 테스트 코드를 실행했다.

// main.c
#include "ssd1306.h"
#include "test.h"

// main 함수 내
SSD1306_Init();
SSD1306_GotoXY(0, 0);
SSD1306_Puts("Hello World", &Font_11x18, 1);
SSD1306_UpdateScreen();

결과: OLED 화면에 불은 들어왔지만 글자가 출력되지 않았다. 화면이 켜졌다는 것은 I2C 통신 자체는 이루어지고 있다는 의미다.

OLED 불 들어옴 + 글자 미출력

원인 및 해결

원인은 I2C 전송 속도였다. OLED는 화면 전체를 갱신할 때 1024바이트를 전송해야 하는데, Standard Mode(100kHz)에서는 데이터 양이 많아 제대로 처리되지 않았다. .ioc에서 I2C Speed Mode를 Fast Mode(400kHz)로 변경하자 모든 기능이 정상 동작했다.

I2C 설정 — Fast Mode 400kHz

동작 확인

Fast Mode로 변경 후 테스트 코드를 실행하면:

"Hello World" 문구가 OLED에 출력
말이 뛰어다니는 애니메이션 재생
지구본 등 다양한 비트맵 이미지 표시

OLED 동작 — Hello World

OLED는 한 번 데이터를 보내면 화면이 유지되므로, FND와 달리 while 루프를 점유하지 않는다. 온도 센서에서 값을 읽어 OLED에 표시하는 것도 SSD1306_Puts와 SSD1306_UpdateScreen만 호출하면 된다.

[오제이 튜브 임베디드 강의] 33. 이제는 쉬워진 I2C 통신

onebrotravel — Wed, 29 Apr 2026 00:23:38 +0900

통신 방식 분류 복습

이 강의 시리즈에서 지금까지 다양한 통신 방식을 다뤘다. 크게 두 가지로 분류할 수 있다.

분류	방식	예시	이전 글
시간 기반 (비동기)	보드 레이트로 시간 단위를 맞춤	UART, 1-Wire	"printf도 쉽지 않다구", "어디서도 안 알려주는 프로토콜의 원리"
클럭 기반 (동기)	클럭 신호로 데이터를 동기화	SPI, I2C	"SPI통신 제대로 배워보자"

I2C는 SPI와 마찬가지로 클럭 기반의 동기 방식이다. 클럭 신호(SCL)와 데이터 신호(SDA) 두 선을 사용하여 데이터를 주고받는다.

I2C 통신의 특징

항목	내용
데이터 단위	8비트(1바이트)씩 주고받음
주소 공간	7비트 → 최대 128개(0~127) 장치 연결 가능
최대 속도	Fast 모드에서 400kHz
통신 방향	반이중 — 송수신 동시에 불가
동기화	클럭 기반 (동기 방식)
필요 선 수	2가닥 — SCL(클럭), SDA(데이터)
기본 상태	SCL, SDA 모두 High
기타	Sleep 모드 장치를 주소 인식으로 깨울 수 있음

SPI와 I2C 비교 — 장치 선택 방식

여러 장치가 하나의 버스에 연결되어 있을 때, 특정 장치를 어떻게 선택하느냐가 통신 프로토콜의 핵심 차이 중 하나다.

항목	SPI	I2C
장치 선택	CS 선 (하드웨어적)	주소 호명 (소프트웨어적)
추가 선	장치마다 CS 선 1개씩 필요	추가 선 불필요
최대 장치	CS 선 수에 따라 제한	128개 (7비트 주소)
통신 방향	전이중 (MOSI + MISO)	반이중 (SDA 1개)

이전 글("SPI통신 제대로 배워보자")에서 SPI는 CS 선으로 물리적으로 장치를 선택한다고 다뤘다. I2C는 별도의 CS 선 없이 주소를 호명하여 특정 장치를 선택한다. 이 방식은 Master-Slave 관계를 필수적으로 요구한다. Slave가 먼저 통신을 시작하면 신호 충돌이 발생하므로, 항상 Master가 먼저 주소를 호명하고 Slave가 응답하는 구조다.

이전 글("어디서도 안 알려주는 프로토콜의 원리")에서 1-Wire도 ROM 코드(주소)로 장치를 선택한다고 다뤘는데, I2C의 주소 방식과 같은 개념이다. 다만 1-Wire는 64비트 주소인 반면, I2C는 7비트로 훨씬 짧다.

데이터 송신 시퀀스

I2C의 데이터 송수신은 SCL(클럭)과 SDA(데이터)의 조합으로 이루어진다. 클럭을 발생하는 주체는 항상 Master다.

START 조건

SCL이 High인 상태에서 SDA가 High → Low로 떨어지면 통신 시작을 의미한다. 이것이 START 조건이다.

데이터 전송 (8비트 반복)

데이터 세팅: Master가 SCL을 Low로 내린다. 이 구간에서 SDA에 보낼 데이터(0 또는 1)를 세팅한다
데이터 읽기: Master가 SCL을 High로 올린다. 이 구간에서 Slave가 SDA의 값을 읽는다
이 과정을 8번 반복하여 1바이트를 전송한다

이전 글("SPI통신 제대로 배워보자")에서 SPI도 클럭의 Rising/Falling Edge에서 데이터를 읽는다고 다뤘는데, I2C도 SCL이 High인 구간에서 SDA를 읽는다는 점에서 유사하다.

STOP 조건

데이터 전송이 끝나면, SDA를 Low로 내린 상태에서 SCL을 High로 유지하고, 이후 SDA도 High로 올리면 통신 종료를 의미한다. 둘 다 High로 돌아와 기본 상태로 복귀한다.

쓰기 / 읽기 전체 흐름

쓰기 (Master → Slave)

START — SDA↓ (SCL High 상태에서)
주소 전송 — Slave의 7비트 주소를 클럭에 맞춰 전송
R/W 비트 — 1비트를 Low(= Write)로 보냄. 주소 7비트 + R/W 1비트 = 총 8비트
ACK — Slave가 SDA를 Low로 내려 "잘 받았다"고 응답
데이터 전송 — 8비트 단위로 데이터를 보내고, 매 8비트 후 Slave가 ACK 응답
STOP — 통신 종료

읽기 (Slave → Master)

START → 주소 전송 → R/W 비트를 High(= Read)로 설정
ACK — Slave 응답
데이터 수신 — Slave가 클럭에 맞춰 8비트 데이터를 보냄
ACK/NACK — Master가 더 읽을 데이터가 있으면 ACK(Low), 마지막이면 NACK(High)
STOP — 통신 종료

STM32에서 I2C 설정

I2C1 설정 화면

I2C를 사용하는 방법은 두 가지다: GPIO를 직접 제어하여 신호를 만들거나, 칩에서 제공하는 I2C 기능을 사용하는 것. 이전 글("STM32에서는 SPI기능을 제공한다구")에서 SPI도 GPIO → HW SPI로 전환했듯이, I2C도 하드웨어 기능을 사용한다.

.ioc 설정

STM32CubeIDE에서 I2C1을 활성화하면 자동으로 PB8(SCL), PB9(SDA) 핀이 설정된다.

설정 항목	값	의미
I2C Speed Mode	Standard Mode	100kHz (Fast Mode는 400kHz)
Clock Speed	100000	통신 속도

주소 충돌 문제

같은 I2C 버스에 동일한 주소를 가진 장치가 2개 이상 연결되면 통신이 불가능하다. 이 문제를 방지하기 위해 대부분의 I2C 장치는 핀 설정으로 주소를 변경할 수 있는 기능을 제공한다. 특정 핀을 High 또는 Low로 묶어 주소 비트를 바꾸는 방식이다.

General Call Address

General Call Address(0x00)는 모든 연결된 장치에 동시에 명령을 보낼 때 사용한다. 예를 들어 전체 장치 리셋 등에 활용된다. 이전 글("어디서도 안 알려주는 프로토콜의 원리")에서 다뤘던 1-Wire의 Skip ROM(0xCC)과 같은 개념이다.

HAL 라이브러리 함수

설정이 완료되면 HAL 라이브러리 함수로 간단하게 통신할 수 있다.

// 데이터 쓰기
HAL_I2C_Master_Transmit(&hi2c1, slave_addr << 1, data, size, timeout);

// 데이터 읽기
HAL_I2C_Master_Receive(&hi2c1, slave_addr << 1, data, size, timeout);

slave_addr << 1로 주소를 1비트 왼쪽 시프트하는 이유는, HAL 함수가 내부적으로 7비트 주소 + R/W 비트를 합쳐서 8비트로 전송하기 때문이다. I2C 통신 개념을 이해하면 이러한 파라미터의 의미가 명확해진다.

[오제이 튜브 임베디드 강의] 32. 드디어 해결된 크리티컬 문제

onebrotravel — Wed, 29 Apr 2026 00:12:51 +0900

이전 글에서의 상태

이전 글("흉내낸 쓰레드 크리티컬 섹션 문제 해결")에서 ManualConvert를 start_converting / check_converting / get_temper 세 함수로 분해하고, is_busy 플래그로 통신 중 FND 제어를 막는 구조를 만들었다. 온도 정보는 정상적으로 가져올 수 있었지만, 강의에서는 FND에 숫자가 제대로 표현되지 않는 문제가 남아 있었다. 통신 구간이 여전히 길어서 is_busy 상태가 오래 유지되고, 그동안 FND가 꺼져 있었기 때문이다.

문제의 원인 — 락 범위가 너무 넓다

이전 글에서 start_converting, get_temper 등 함수 단위로 is_busy를 설정했다. 하지만 이 함수들 내부에는 실제로 GPIO 신호를 주고받는 통신 구간과, 단순히 시간을 기다리는 딜레이 구간이 섞여 있다.

통신 구간: GPIO를 Output/Input으로 전환하며 비트를 보내고 받는 구간. 이 구간에서 TIM3 인터럽트가 끼어들면 타이밍이 깨짐 → 반드시 락 필요
딜레이 구간: delayMicroseconds 등으로 단순 대기하는 구간. 이 구간에서는 GPIO를 건드리지 않으므로 → 락이 불필요

함수 전체에 락을 걸면 딜레이 구간에서도 FND가 멈추므로, FND가 꺼져 있는 시간이 길어지는 것이다.

해결 — write_bit 단위까지 내려가서 락 걸기

1-Wire 라이브러리의 가장 하위 단위인 OneWire_WriteBit / OneWire_ReadBit까지 내려간다. 이 함수들이 실제로 GPIO 신호를 생성하는 최소 단위다.

락 범위 세분화

// onewire.c — WriteBit 내부 (개념)
void OneWire_WriteBit(OneWire_t* OneWireStruct, uint8_t bit) {
    m_is_busy = 1;          // 락 시작
    // GPIO Output → Low → 딜레이 → High (실제 통신)
    m_is_busy = 0;          // 락 해제
    delayMicroseconds(60);  // 슬롯 완료 대기 (여기서는 FND 제어 가능)
}

실제 통신하는 짧은 구간에서만 is_busy = 1, 딜레이 구간에서는 is_busy = 0으로 풀어준다. 이렇게 하면 딜레이 구간에 TIM3 인터럽트가 발생해도 FND 제어가 가능하고, 실제 GPIO 신호 구간에서는 안전하게 보호된다.

WriteBit/ReadBit에 is_busy 적용한 코드

적용 후 결과

이 방식을 적용하면 FND에 온도가 실시간으로 정확하게 표시되고, 깜빡임 없이 안정적으로 동작한다. 프로브를 손으로 잡으면 온도가 올라가고, 놓으면 내려가는 것이 FND에 즉시 반영된다.

깜빡임 없이 FND에 온도 실시간 표시

data valid 문제

락 범위를 세분화한 후, data valid 값이 True/False를 왔다갔다하는 문제가 발생했다. 온도값 자체는 정상이지만 data valid가 불안정하면 신뢰성이 떨어진다.

원인은 아주 짧은 딜레이 구간에서도 락을 풀었기 때문이다. 1~3μs 정도의 매우 짧은 딜레이 구간에서 TIM3가 끼어들면, 다음 통신 동작의 시작 타이밍이 미세하게 밀려 CRC 검사에서 간헐적으로 실패하는 것이다.

해결 — 짧은 딜레이는 통신 구간과 묶기

아주 짧은 딜레이(수 μs 이하)는 굳이 락을 풀지 않고 통신 구간과 함께 묶어서 is_busy를 유지한다. 충분히 긴 딜레이(수십 μs 이상)에서만 락을 풀어 FND 제어를 허용한다.

// 개념 예시
m_is_busy = 1;
GPIO_Low();           // 실제 통신
delayMicroseconds(3); // 짧은 딜레이 → 묶어서 락 유지
GPIO_Input();         // 실제 통신
m_is_busy = 0;        // 여기서 락 해제
delayMicroseconds(53); // 긴 딜레이 → FND 제어 가능

이 수정을 적용하면 data valid가 항상 True로 유지되고, 전체적인 데이터 신뢰성이 높아진다.

문제 해결에서 얻는 교훈

이번 문제 해결 과정에서 가장 중요한 것은 사용하는 재료(하드웨어와 라이브러리)에 대한 깊이 있는 이해다. 1-Wire 라이브러리의 가장 하위 함수(write_bit)까지 내려가서 "어디가 실제 통신이고 어디가 딜레이인지"를 파악했기 때문에, 락 범위를 정확하게 설정할 수 있었다.

임베디드 개발에서는 이처럼 답이 없는 상황에서 스스로 해결책을 찾아내는 능력이 핵심이다. 재료에 대한 온전한 이해가 있을 때 비로소 복잡한 문제도 풀어낼 수 있다.

정리

크리티컬 섹션 문제의 해결 과정을 정리하면:

쓰레드 흉내내기 — FND를 타이머 인터럽트로 갱신하는 구조 구현, 통신 충돌 발견
흉내낸 쓰레드 크리티컬 섹션 문제 해결 — is_busy 플래그 도입, ManualConvert를 3개 함수로 분해 (함수 단위 락)
이번 글 — write_bit 단위까지 내려가서 실제 통신 구간에만 락, 짧은 딜레이는 묶어서 data valid 안정화

핵심 원리는 "실제 GPIO 통신 구간에서만 최소한으로 락을 걸고, 딜레이 구간에서는 풀어서 다른 작업이 가능하게 한다"는 것이다.

현재 버전 라이브러리라면?

강의에서는 이전 버전 라이브러리의 소스(ds18b20.c, onewire.c)를 직접 수정하여 is_busy를 수동으로 추가하고, write_bit까지 내려가 락 범위를 조절했다. 하지만 이전 글("1-Wire 통신")에서 다뤘던 현재 버전(nimaltd/ds18b20)은 이 문제를 라이브러리 차원에서 이미 해결하고 있다.

현재 버전은 Non-Blocking 방식으로 설계되어, 타이머 콜백으로 1-Wire 통신을 처리한다. 다음 함수들이 내장되어 있다.

함수	역할
`ds18b20_is_busy()`	현재 통신 중인지 확인
`ds18b20_is_cnv_done()`	온도 변환이 완료되었는지 확인
`ds18b20_cnv()`	온도 변환 시작 (Non-Blocking)
`ds18b20_req_read()`	온도 데이터 읽기 요청 (Non-Blocking)

따라서 TIM3 인터럽트에서 ds18b20_is_busy()만 체크하면 라이브러리 소스를 수정하지 않고도 크리티컬 섹션 문제를 해결할 수 있다.

// stm32f1xx_it.c — 현재 버전 사용 시
void TIM3_IRQHandler(void) {
    HAL_TIM_IRQHandler(&htim3);
    if (!ds18b20_is_busy(&ds18)) {
        digit4_temper(m_display_temp);
    }
}

강의의 이전 버전으로는 "라이브러리를 직접 뜯어서 해결하는 과정"을 배울 수 있고, 현재 버전으로는 "잘 설계된 라이브러리가 이런 문제를 어떻게 구조적으로 방지하는지"를 이해할 수 있다. 두 가지 모두 경험해보면 크리티컬 섹션에 대한 이해가 깊어진다.

[오제이 튜브 임베디드 강의] 31. 흉내낸 쓰레드 크리티컬 문제 해결

onebrotravel — Tue, 28 Apr 2026 23:55:47 +0900

문제 복습

이전 글("쓰레드 흉내내기")에서 TIM3 타이머 인터럽트로 FND를 갱신하고, main 루프에서 온도 센서를 읽는 구조를 만들었다. 강의에서는 이 구조에서 FND에 온도가 0으로만 표시되는 문제가 발생했다. 원인은 main에서 1-Wire 통신(PA3) 중에 TIM3 인터럽트가 발생하여 SPI 통신(PB13/14/15)으로 FND를 제어하면서 1-Wire의 μs 단위 타이밍이 깨진 것이었다.

본인 환경에서는 이 문제가 재현되지 않았지만, 강의에서 다루는 해결 과정은 임베디드에서 매우 중요한 개념(크리티컬 섹션)이므로 함께 정리한다.

왜 하드웨어로 해결할 수 없는가

"소프트웨어적으로 복잡하게 하지 말고 하드웨어적으로 해결할 수 없을까?"라는 의문이 들 수 있다. 결론부터 말하면 현재 모듈 구조에서는 불가능하다.

7세그먼트 내부 구조

7세그먼트 내부구조

7세그먼트의 회로도를 보면, A~G 세그먼트가 4자리 모두에 공통으로 연결되어 있다. A 세그먼트에 전압을 가하면 4개의 자릿수 모두에서 A가 켜진다. DIG1~DIG4 신호로 몇 번째 자릿수를 켤지 선택할 수 있지만, 한 번에 하나의 숫자 패턴만 보낼 수 있는 구조다.

따라서 "8888"처럼 같은 숫자는 동시에 표시 가능하지만, "1234"처럼 다른 숫자를 동시에 표시하는 것은 하드웨어적으로 불가능하다.

시프트 레지스터

7세그먼트 모듈에 포함된 시프트 레지스터는 프로그래밍이 가능한 MCU 칩이 아니다. 직렬 신호를 병렬 신호로 바꿔주는 단순한 회로일 뿐이다. 이전 글("FND 제어 소스 분석")에서 다뤘던 send 함수가 8비트를 직렬로 보내면, 시프트 레지스터가 이를 병렬로 변환하여 7세그먼트에 출력하고, send_port에서 래치 클럭(RCLK)을 올리면 숫자가 표시된다.

결국 소프트웨어적으로 빠르게 전환하여 잔상 효과를 만드는 것이 유일한 방법이고, 이를 위해 타이머 인터럽트를 사용하되 통신 충돌을 해결해야 한다.

해결 전략

해결 전략은 다음과 같다.

온도 정보를 가져오는 통신 구간을 최우선 순위로 설정
온도 통신 중에는 FND 제어를 하지 않는다 (is_busy 플래그)
온도 통신 구간을 최대한 분해하여 짧게 만든다
분해된 구간 사이사이에 FND 제어가 동작할 수 있도록 한다

핵심은 is_busy 플래그다. 온도 센서와 통신 중일 때 is_busy = 1로 설정하고, TIM3 인터럽트에서는 is_busy를 확인하여 바쁘면 FND 제어를 건너뛴다.

Init 간소화

ROM 주소 하드코딩

기존 Ds18b20_Init은 OneWire_First → OneWire_Search(0xF0) → OneWire_Next를 호출하여 연결된 장치의 ROM 주소를 탐색했다. 하지만 우리는 온도 센서가 하나뿐이고 항상 같은 주소를 가지므로, 탐색 과정을 생략하고 ROM 주소를 직접 입력한다.

디버그 모드에서 Ds18b20_Init 호출 후 ds18b20[0].Address의 값을 확인하여 그대로 하드코딩한다.

// heaterController.c
static uint8_t m_init = 0;

void init_simple(void) {
    OneWire_Init(&OneWire, _DS18B20_GPIO, _DS18B20_PIN);

    // ROM 주소 직접 입력 (디버그에서 확인한 값)
    OneWire.ROM_NO[0] = 0x28;
    OneWire.ROM_NO[1] = 0xFF;
    // ... (실제 센서의 주소값으로 채움)
    OneWire.ROM_NO[7] = 0x00;

    ds18b20[0].Address[0] = OneWire.ROM_NO[0];
    // ... 나머지도 동일하게 복사

    DS18B20_SetResolution(&OneWire, ds18b20[0].Address, DS18B20_Resolution_12bits);
    DS18B20_DisableAlarmTemperature(&OneWire, ds18b20[0].Address);

    m_init = 1;
}

uint8_t is_init(void) {
    return m_init;
}

디버그 워치 — Address 초기값

이렇게 하면 Init 과정에서 ROM Search 통신이 사라지므로 초기화 시간이 크게 단축된다.

ManualConvert 분해

기존 구조의 문제

기존 Ds18b20_ManualConvert는 온도 변환 시작 → 완료 대기 → 데이터 읽기를 한 번에 수행한다. 이 전체 과정이 수백 ms 이상 걸리므로, 그동안 TIM3가 끼어들면 충돌이 발생한다.

3단계로 분해

기존 ManualConvert를 세 개의 함수로 나눈다.

① start_converting — 온도 변환 시작

static uint8_t m_is_busy = 0;

void start_converting(void) {
    m_is_busy = 1;  // 바쁨 상태 설정
    DS18B20_StartAll(&OneWire);  // 0xCC + 0x44 전송
}

② check_converting — 변환 완료 확인

uint8_t check_converting(void) {
    if (DS18B20_AllDone(&OneWire)) {
        m_is_busy = 0;  // 바쁨 해제
        return 1;  // 완료
    }
    return 0;  // 아직 진행 중
}

③ get_temper — 온도 데이터 읽기

float get_temper(void) {
    m_is_busy = 1;
    float temp = 0.0f;
    DS18B20_Read(&OneWire, ds18b20[0].Address, &temp);
    m_is_busy = 0;
    return temp;
}

is_busy 확인 함수:

uint8_t is_busy(void) {
    return m_is_busy;
}

분해된 함수들

TIM3에서 is_busy 체크

// stm32f1xx_it.c
void TIM3_IRQHandler(void) {
    HAL_TIM_IRQHandler(&htim3);
    if (!is_busy()) {
        digit4_temper(m_display_temp);
    }
}

is_busy()가 1이면 FND 제어를 건너뛴다. 온도 센서 통신이 끝나면 is_busy가 0이 되어 다시 FND가 갱신된다.

main 루프

// main.c
init_simple();

float temper = 0.0f;

while (1) {
    start_converting();

    while (!check_converting()) {
        HAL_Delay(10);
    }

    temper = get_temper();
    m_display_temp = (int)(temper * 10);
}

현재 상태 및 다음 글 예고

이 방식으로 온도 정보는 정상적으로 가져올 수 있게 되었다. 그러나 강의에서는 FND 표시가 여전히 불완전한 문제가 남아 있었다. 온도 통신 구간이 아직 충분히 짧게 분해되지 않아, is_busy로 FND가 멈추는 시간이 길었기 때문이다.

다음 글에서는 1-Wire 통신의 가장 하위 단위인 write_bit까지 내려가서, 실제 통신하는 짧은 구간에서만 is_busy를 걸고 딜레이 구간에서는 풀어주는 방식으로 최종 해결한다. 또한 data valid 값이 불안정한 문제도 함께 다룬다.

[오제이 튜브 임베디드 강의] 30. 쓰레드 흉내내기 (모든 장치 통합시키기)

onebrotravel — Tue, 28 Apr 2026 23:42:13 +0900

문제 인식 — FND는 동시에 표시하지 않는다

이전 글들에서 FND에 숫자를 표시할 때 digit4_replay 함수를 사용했다. 이 함수는 4자리 숫자를 "동시에" 보여주는 것처럼 보이지만, 실제로는 한 자릿수씩 순서대로 매우 빠르게 전환하면서 잔상 효과로 동시에 켜져 있는 것처럼 보이는 것이다.

딜레이 테스트로 증명

이를 증명하기 위해 각 자릿수 출력 사이에 1초의 딜레이를 넣어본다. 결과적으로 숫자가 하나씩 순차적으로 깜빡이다가 마지막 자릿수만 남는 현상이 발생한다. 4개의 숫자가 동시에 표시되는 것이 아님을 눈으로 확인할 수 있다.

딜레이 테스트 — 자릿수 순차 깜빡임

이것이 왜 문제인가

FND를 잔상 효과로 표시하려면 while 루프에서 FND를 계속 갱신해야 한다. 그런데 while 루프에서는 온도 센서 읽기, 릴레이 제어 등 다른 작업도 수행해야 한다. FND 갱신이 while 루프를 점유하면 다른 작업과 충돌하거나, 다른 작업 수행 중 FND가 깜빡이는 문제가 발생한다.

운영체제가 있다면 쓰레드로 FND 갱신을 별도로 돌리면 되지만, 우리는 OS 없는 베어메탈 환경이다. 이 문제를 타이머 인터럽트로 해결한다.

해결 방법 — 타이머 인터럽트로 쓰레드 흉내내기

현재 인터럽트 상황

현재 시스템에는 이미 두 개의 인터럽트가 동작 중이다.

SysTick: HAL_Delay 등 시스템 타이밍 담당
TIM2: 1-Wire 통신의 1μs 타이밍 담당 (이전 글("1-Wire 통신")에서 설정)

여기에 TIM3를 새로 추가하여, FND 갱신을 인터럽트에서 처리한다. while 루프와 독립적으로 FND가 계속 갱신되므로, 마치 별도의 쓰레드처럼 동작한다.

Timer3 설정

STM32CubeIDE에서 TIM3를 활성화하고 다음과 같이 설정한다.

설정 항목	값	의미
Clock Source	Internal Clock	내부 클럭 사용
Prescaler	(72 - 1)	72MHz → 1MHz (1틱 = 1μs)
Counter Period	99	100μs마다 인터럽트 발생
NVIC 우선순위	10	TIM2(1-Wire용)보다 낮은 우선순위

TIM3 설정 화면

인터럽트 시작

main 함수에서 Timer3를 시작한다.

// main 함수 내, while 루프 전
HAL_TIM_Base_Start_IT(&htim3);

이제 100μs마다 TIM3_IRQHandler가 호출된다. 이 핸들러 안에서 FND를 갱신하면 while 루프와 독립적으로 FND가 표시된다.

digit4_temper 함수 구현

인터럽트에서 한 자릿수씩 표시

기존 digit4_show는 한 번에 4자리를 모두 보냈지만, 인터럽트 방식에서는 호출될 때마다 한 자릿수만 표시하고, 다음 호출 때 다음 자릿수를 표시한다.

// fnd_controller.c
static uint8_t m_temp_count = 0;

void digit4_temper(int temper) {
    int n1 = temper % 10;
    int n2 = (temper / 10) % 10;
    int n3 = (temper / 100) % 10;
    int n4 = (temper / 1000) % 10;

    switch (m_temp_count) {
        case 0:
            send_port(_LED_0F[n1], 0b0001);
            break;
        case 1:
            send_port(_LED_0F[n2] & 0x7F, 0b0010);  // 소수점 포함
            break;
        case 2:
            send_port(_LED_0F[n3], 0b0100);
            break;
        case 3:
            send_port(_LED_0F[n4], 0b1000);
            break;
        default:
            m_temp_count = 0;
            return;
    }
    m_temp_count++;
    if (m_temp_count > 3) m_temp_count = 0;
}

100μs마다 호출되므로 4자리를 한 바퀴 도는 데 400μs(0.4ms)가 걸린다. 사람 눈에는 깜빡임 없이 동시에 표시되는 것처럼 보인다.

인터럽트 핸들러에서 호출

// stm32f1xx_it.c
#include "fnd_controller.h"

void TIM3_IRQHandler(void) {
    HAL_TIM_IRQHandler(&htim3);
    digit4_temper(500);  // 테스트: 50.0으로 표시
}

밝기 불균일 문제

해결 전 / 해결 후

테스트 시 마지막 자릿수(1의 자리)가 유독 밝게 보이는 문제가 발생할 수 있다. 원인은 case 3 이후 default에서 아무 것도 표시하지 않고 돌아가면서, 1의 자리가 상대적으로 오래 켜져 있기 때문이다. m_temp_count가 3을 넘으면 즉시 0으로 리셋하여 모든 자릿수가 균일한 시간 동안 켜지도록 수정하면 해결된다.

온도 표시 시도

실제 온도 연결

테스트 값(50.0) 대신 실제 온도를 표시하도록 수정한다.

// main.c
while (1) {
    float temp = get_current_temp();
    int temp_int = (int)(temp * 10);
    digit4_temper(temp_int);  // 전역 변수를 통해 인터럽트에 전달
    HAL_Delay(1000);
}

실행하면 FND에 현재 온도가 정상적으로 표시된다.

FND에 현재 온도 표시

강의에서 발생한 통신 충돌 문제

강의에서는 이 단계에서 FND에 온도가 0으로만 표시되는 문제가 발생했다. 원인은 TIM3 인터럽트와 main의 온도 센서 통신이 동시에 GPIO를 사용하면서 1-Wire 통신의 타이밍이 깨진 것이었다.

main 루프: Ds18b20_ManualConvert → 1-Wire 통신으로 GPIO(PA3)를 통해 온도 데이터 수신
TIM3 인터럽트: digit4_temper → SPI 통신으로 GPIO(PB13/14/15)를 통해 FND 데이터 전송

1-Wire는 μs 단위의 정밀한 타이밍이 필요한데, main에서 1-Wire 통신 중에 TIM3 인터럽트가 발생하면 인터럽트 핸들러에서 SPI GPIO 신호를 보내면서 타이밍이 깨질 수 있다.

본인 환경에서는 이 문제가 재현되지 않았지만, 환경에 따라 충분히 발생할 수 있는 문제다. 다음 글에서는 이 문제의 근본적인 해결 방법인 크리티컬 섹션(Critical Section) — 온도 센서 통신 중에는 TIM3 인터럽트를 잠시 멈추고, 완료 후 다시 활성화하는 방식 — 을 다룬다.

[오제이 튜브 임베디드 강의] 29. 난방실 만들기

onebrotravel — Sun, 26 Apr 2026 20:58:55 +0900

전기 작업 — 소켓과 릴레이 연결

이전 글("드라이기를 내 맘대로 껐다, 켰다 해보자")에서 트랜지스터를 이용한 릴레이 구동 회로를 구성하고, 수동으로 릴레이 동작을 확인했다. 이번에는 실제로 220V 드라이기를 릴레이에 연결한다.

소켓 제작

돼지코(플러그 소켓), 전선, 전기 테이프를 준비한다. 드라이기 사용 시 흐르는 전류량을 고려하여 두껍고 용량이 큰 전선을 사용해야 한다. 전선 피복을 벗기고 소켓 내부에 나사로 고정한 뒤, 전기 테이프로 노출 부분을 감싼다. 전기 테이프는 당겨서 탄력을 받게끔 감는 것이 요령이다.

매 연결 단계마다 멀티미터 쇼트 테스트로 합선 여부를 확인한다.

릴레이에 드라이기 연결

드라이기 전원선의 한 가닥을 끊어서, 한쪽을 릴레이의 COM, 다른 쪽을 NO 단자에 연결한다. 이전 글에서 다뤘듯이 평상시 COM-NC(OFF) → 릴레이 동작 시 COM-NO(ON)로 드라이기 전원이 연결된다.

전선이 두꺼워 단자에 잘 들어가지 않으면, 피복을 벗긴 부분을 넓게 펴서 넣은 후 나사를 단단히 조인다.

릴레이 COM/NO에 드라이기 전선 연결

안전 주의사항

AC 220V를 다루므로 반드시 전원을 분리한 상태에서 작업해야 한다. 양쪽 전선을 동시에 잡으면 감전 위험이 있다. 모든 연결이 완료되면 쇼트 테스트로 합선 여부를 최종 확인한다.

GPIO로 릴레이 제어

PB5 설정

STM32CubeIDE에서 PB5를 GPIO_Output으로 설정한다. 초기 출력 레벨은 Low(릴레이 미동작)로 설정하고, 유저 라벨은 PB5_RELAY_ON_OFF_CTRL로 지정한다.

PB5 GPIO Output 설정

릴레이 동작 테스트

먼저 간단한 토글 코드로 릴레이가 정상 동작하는지 확인한다.

while (1) {
    HAL_GPIO_TogglePin(PB5_RELAY_ON_OFF_CTRL_GPIO_Port, PB5_RELAY_ON_OFF_CTRL_Pin);
    HAL_Delay(2000);
}

코드를 실행하면 2초마다 '딸깍딸깍' 소리가 나며 릴레이가 on/off된다. AC 전원을 연결하면 드라이기가 2초 간격으로 켜졌다 꺼졌다 하는 것을 확인할 수 있다.

간이 난방실 제작

온도에 따라 드라이기를 제어하려면 밀폐된 공간이 필요하다. 택배 상자를 활용하여 간이 난방실을 만든다.

윗면에 온도 센서 프로브가 들어갈 구멍
옆면에 드라이기가 들어갈 구멍

구멍을 일부러 작게 뚫어 센서와 드라이기가 강제로 들어가게 하면 열이 새는 것을 줄일 수 있다.

택배 상자 간이 난방실 — 드라이기와 온도 센서 배치

온도 센서 재연결

이전 글들에서 사용했던 온도 센서를 회로도에 따라 다시 연결한다.

모듈 핀	연결
VCC	빵판 + 레일 (3.3V)
GND	빵판 - 레일
DAT	PA3

STM 보드의 3.3V와 GND도 빵판의 +/- 레일에 연결하여, 모든 부품이 동일한 기준 전압에서 동작하도록 한다.

온도 기반 드라이기 제어 코드

파일 구조

온도 제어 로직을 별도 파일로 분리한다.

heaterController.h:

#ifndef SRC_HEATERCONTROLLER_H_
#define SRC_HEATERCONTROLLER_H_

#include "main.h"
#include "ds18b20.h"

float get_current_temp(void);
void heater_control(void);

#endif

heaterController.c:

#include "heaterController.h"

uint8_t heater_state = 0;  // 0: OFF, 1: ON

float get_current_temp(void) {
    Ds18b20_ManualConvert();
    return ds18b20[0].Temperature;
}

void heater_control(void) {
    float current_temp = get_current_temp();

    if (current_temp > 50.0f && heater_state == 1) {
        // 50도 초과 + 히터 켜져 있으면 → OFF
        HAL_GPIO_WritePin(PB5_RELAY_ON_OFF_CTRL_GPIO_Port,
                          PB5_RELAY_ON_OFF_CTRL_Pin, GPIO_PIN_RESET);
        heater_state = 0;
    }
    else if (current_temp < 45.0f && heater_state == 0) {
        // 45도 미만 + 히터 꺼져 있으면 → ON
        HAL_GPIO_WritePin(PB5_RELAY_ON_OFF_CTRL_GPIO_Port,
                          PB5_RELAY_ON_OFF_CTRL_Pin, GPIO_PIN_SET);
        heater_state = 1;
    }
}

main.c

#include "heaterController.h"

// main 함수 내
Ds18b20_Init();

while (1) {
    heater_control();
    HAL_Delay(1000);
}

제어 로직 정리

조건	동작
현재 온도 > 50°C 그리고 히터 ON	히터 OFF (GPIO Low)
현재 온도 < 45°C 그리고 히터 OFF	히터 ON (GPIO High)
그 외	현재 상태 유지

45°C 미만이면 드라이기가 켜져서 상자 내부에 열을 가하고, 50°C를 넘으면 꺼진다. 이 on/off를 반복하여 45~50°C 사이를 유지한다.

동작 확인 및 한계

코드를 실행하면 드라이기가 켜져서 온도가 올라가고, 50°C를 넘으면 자동으로 꺼진다. 온도가 45°C 아래로 떨어지면 다시 켜지는 것을 확인할 수 있다.

동작 확인 — FND 온도 표시 + 드라이기 자동 제어

동작에는 성공했지만, 정교한 온도 제어는 어려운 과제다. 예를 들어 50°C에서 드라이기를 끄더라도 잔열로 온도가 더 올라갈 수 있다(오버슈트). 목표 온도에 정확히 맞추려면 미리 꺼야 하는 등 세밀한 조정이 필요하다.

이번 강의로 고추 건조기의 핵심 기능인 온도 제어 드라이기 구동이 완성되었다. 다음 글에서는 여러 기능(온도 센서, FND, 릴레이)이 동시에 동작하도록 타이머 인터럽트를 활용한 쓰레드 흉내내기를 다룬다.

[오제이 튜브 임베디드 강의] 28. 드라이기를 내 맘대로 껐다, 켰다 해보자.

onebrotravel — Sun, 26 Apr 2026 20:46:08 +0900

고추 건조기의 큰 그림

고추 건조기의 최종 목표는 특정 온도를 유지하면서 건조하는 것이다. 이를 위해 세 가지 요소가 필요하다.

FND — 현재 온도를 표시 (이전 글들에서 구현 완료)
온도 센서 — 현재 온도를 측정 (이전 글들에서 구현 완료)
릴레이 — 드라이기를 껐다 켰다 제어 (이번 글에서 구현)

동작 원리는 간단하다. 목표 온도가 60°C라면, 온도가 60°C에 도달할 때까지 드라이기를 켜고, 도달하면 끈다. 온도가 55°C로 떨어지면 다시 켜는 방식으로 on/off를 반복하여 목표 온도 부근을 유지한다.

릴레이란

릴레이(Relay)는 GPIO 신호에 따라 전류의 흐름을 제어하는 스위치다. 이전 글("회로도 딱 필요한 만큼만 배우자")에서 릴레이의 회로도 기호와 "GPIO로 AC 전원을 차단하는 개념"을 다뤘는데, 이번에 실물로 구현한다.

전압을 가하면 내부 접점이 붙고(딸깍), 전압을 제거하면 떨어진다. 트랜지스터와 유사한 역할이지만, 릴레이는 물리적으로 접점이 움직이므로 작동 시 '딸깍' 소리가 난다.

릴레이 모듈 실물

Low Level Trigger 설정

이 릴레이 모듈의 딥 스위치를 'L'(Low Level Trigger)로 설정한다. 이는 IN 단자가 평상시 High(5V) 상태에 있다가, Low로 떨어지면 릴레이가 동작하는 방식이다.

릴레이 모듈의 단자 구성:

단자	연결	역할
DC+	5V	릴레이 동작 전원
DC-	GND	접지
IN1	제어 신호	평상시 High, Low가 되면 릴레이 동작

3.3V 보드에서 5V 릴레이 구동

문제는 이 릴레이가 5V에서 동작하는데, 우리 보드는 3.3V로 동작한다는 점이다. 원래 3.3V용 릴레이를 사용하려 했으나 수급 문제로 5V용을 사용하게 되었다. 따라서 트랜지스터를 이용한 추가 회로가 필요하다.

동작 원리

회로도 — PB5 Low vs High 비교

GPIO(PB5)가 Low일 때:

트랜지스터가 OFF 상태이므로, 릴레이의 IN1은 4.7kΩ 풀업 저항을 통해 5V(High)를 유지한다. Low Level Trigger 조건이 아니므로 릴레이 미동작.

GPIO(PB5)가 High일 때:

트랜지스터의 Base에 3.3V가 인가되어 트랜지스터가 ON. Collector-Emitter가 연결되면서 IN1이 GND로 끌려 내려가 Low가 된다. Low Level Trigger 조건이 충족되어 릴레이 동작(딸깍).

저항의 역할

1kΩ 저항 (GPIO → 트랜지스터 Base): 트랜지스터에 과도한 전류가 흐르지 않도록 제한
4.7kΩ 저항 (5V → IN1 풀업): IN1을 평상시 High로 유지. 트랜지스터 ON 시 IN1이 Low로 떨어짐

저항 없이 5V와 GND가 직접 연결되면 쇼트(단락)가 발생하여 회로가 손상된다.

COM / NC / NO — 드라이기 제어 원리

릴레이의 출력 단자는 세 개다.

단자	의미	역할
COM	Common	기준점 (드라이기 전선의 한쪽)
NC	Normally Closed	평상시 COM과 연결됨
NO	Normally Open	평상시 열려 있음, 릴레이 동작 시 COM과 연결

드라이기의 전원선 한 가닥을 끊어서, 한쪽을 COM에, 다른 쪽을 NO에 연결한다.

릴레이 미동작 (평상시): COM-NC 연결 → 드라이기 전원 경로 끊김 → 드라이기 OFF
릴레이 동작 (GPIO High): COM-NO 연결 → 드라이기 전원 경로 연결 → 드라이기 ON

COM/NC/NO와 드라이기 연결 회로도

납땜 작업

보드의 5V 출력 핀에 핀 헤더가 없으므로 납땜으로 핀을 붙여야 한다. 보드 상단의 6구멍이 위에서부터 5V, 3.3V, GND 순서로 배치되어 있다.

납땜은 인두기로 납을 녹여 도체들을 연결하는 작업이다. 다이소에서 5천원에 구입할 수 있는 저렴한 인두기로도 충분히 작업 가능하다.

납땜 시 주의사항

과도한 납 사용: 인접한 패턴끼리 연결되어 쇼트 발생
냉땜: 납이 제대로 녹지 않아 접촉 불량
패턴 손상: 인두기를 너무 오래 대면 기판의 구리 패턴이 벗겨짐

납땜 작업 — 5V 핀에 핀 헤더 납땜

빵판 배선

회로도에 따라 브레드보드에 부품을 조립한다.

부품 목록

트랜지스터 (NPN)
1kΩ 저항 (갈-검-빨)
4.7kΩ 저항 (노-보-빨)
릴레이 모듈 (딥 스위치 L로 설정)

배선 순서

노란 암-수 점퍼선으로 STM 보드의 PB5 → 빵판 j5에 연결
1kΩ 저항을 i5와 i10에 연결
트랜지스터의 B(Base, 가운데)가 h15에 오도록 꽂기 (평평한 면이 -쪽)
주황 수-수 점퍼선으로 j10과 j15 연결 (저항 끝 → 트랜지스터 Base)
검정 수-수 점퍼선으로 g16(트랜지스터 E) → - 레일(GND) 연결
초록 수-수 점퍼선으로 g14(트랜지스터 C) → g20 연결
4.7kΩ 저항을 i20과 i25에 연결
빨간 수-수 점퍼선으로 h25 → + 레일(5V) 연결
릴레이 DC+ → 빵판 j25 (5V 라인)
릴레이 DC- → 빵판 - 레일(GND)
릴레이 IN1 → 빵판 j20 (트랜지스터 C와 풀업 저항의 연결점)

빵판 배선 완성

전원 연결

검정 암-수 점퍼선으로 빵판 - 레일 → STM 보드 GND
빨간 암-수 점퍼선으로 빵판 + 레일 → STM 보드 5V (납땜한 핀)
5V 전원 공급을 위해 USB 어댑터로 외부 전원 연결 필요

코드 없이 릴레이 동작 확인

실제 GPIO 코드를 작성하기 전에, 수동으로 릴레이 동작을 검증한다.

PB5에 연결된 노란 점퍼선을 빼서, 납땜한 3.3V 핀에 꽂는다 → GPIO High를 흉내냄
트랜지스터 ON → IN1 Low → Low Level Trigger → 릴레이 '딸깍' 소리
멀티미터 쇼트 테스트로 COM-NO가 연결되었는지 확인
점퍼선을 빼면 → IN1 High 복귀 → 릴레이 해제 → COM-NC로 복귀

수동 테스트 — 3.3V로 릴레이 동작 확인

이것으로 드라이기 제어의 핵심 회로가 검증되었다. 다음 글에서는 GPIO 코드로 릴레이를 제어하고, 온도 센서와 연동하여 목표 온도를 유지하는 난방실을 구현한다.

[오제이 튜브 임베디드 강의] 27. 온도센서 검증하기

onebrotravel — Sun, 26 Apr 2026 20:26:52 +0900

Init 함수 복습

이전 글("다른 사람 소스 분석하는 방법")에서 Ds18b20_Init 함수의 전체 흐름을 분석했다. 간단히 복습하면:

OneWire_Init — GPIO PA3 초기화, 타이머 시작
OneWire_First → OneWire_Search(0xF0) — 장치 검색, ROM_NO[8]에 주소 저장
OneWire_Next — 다음 장치 검색 (우리는 센서 1개이므로 1번만)
DS18B20_SetResolution — 12비트 정밀도 설정
DS18B20_DisableAlarmTemperature — 알람 비활성화

온도 센서와 통신하는 과정은 항상 리셋 → ROM 주소 선택 → 명령어 전송 → 결과 읽기의 정해진 시퀀스를 따른다. 이 시퀀스는 ManualConvert에서도 동일하게 적용된다.

ManualConvert 분석 — 온도 변환 시작

Ds18b20_ManualConvert는 while문에서 반복 호출되며, 실제로 온도를 읽어오는 핵심 함수다.

bool	Ds18b20_ManualConvert(void)
{
	Ds18b20Timeout=_DS18B20_CONVERT_TIMEOUT_MS/10;
	DS18B20_StartAll(&OneWire);
	Ds18b20Delay(100);
	while (!DS18B20_AllDone(&OneWire))
	{
		Ds18b20Delay(10);  
		Ds18b20Timeout-=1;
		if(Ds18b20Timeout==0)
			break;
	}	
	if(Ds18b20Timeout>0)
	{
		for (uint8_t i = 0; i < TempSensorCount; i++)
		{
			Ds18b20Delay(100);
			ds18b20[i].DataIsValid = DS18B20_Read(&OneWire, ds18b20[i].Address, &ds18b20[i].Temperature);
		}
	}
	else
	{
		for (uint8_t i = 0; i < TempSensorCount; i++)
			ds18b20[i].DataIsValid = false;
	}
	if(Ds18b20Timeout==0)
		return false;
	else
		return true;
	#endif
}

StartAll — 모든 장치에 온도 변환 명령

DS18B20_StartAll(&OneWire);

내부적으로 두 가지 명령어를 순서대로 전송한다.

OneWire_Reset — 리셋 펄스 전송
OneWire_WriteByte(0xCC) — Skip ROM (ROM 커맨드). 이전 글("어디서도 안 알려주는 프로토콜의 원리")에서 다뤘듯이, 모든 Slave 장치에 동시에 명령을 보낼 때 사용
OneWire_WriteByte(0x44) — Convert T (Function 커맨드). 센서에게 "온도를 측정하라"고 명령

이전 글에서 ROM 커맨드(모든 장치 공통)와 Function 커맨드(칩마다 다름)를 구분했는데, 여기서 실제로 적용되는 것이다. 0xCC로 모든 장치를 선택한 뒤 0x44로 온도 변환을 시작한다.

변환 완료 대기 — AllDone

온도 변환이 시작되면, 센서가 완료할 때까지 기다려야 한다.

while (!DS18B20_AllDone(&OneWire)) {
    Ds18b20Delay(10);
    if (Ds18b20Timeout-- <= 0) break;
}

DS18B20_AllDone은 내부적으로 1비트를 읽어 변환 상태를 확인한다. 1-Wire는 pull-up 상태이므로, 한 장치라도 변환 중이면 신호선을 Low로 당긴다. 즉 0이 반환되면 아직 진행 중이고, 1이 반환되면 완료된 것이다.

타임아웃은 _DS18B20_CONVERT_TIMEOUT_MS(= 5000ms)로 설정되어 있다. 12비트 해상도의 변환 시간이 최대 750ms이므로 5초면 충분한 여유가 있다. 타임아웃이 발생하면 실패로 처리한다.

ManualConvert 분석 — 온도 데이터 읽기

변환이 완료되면 DS18B20_Read 함수로 온도 데이터를 읽어온다.

bool DS18B20_Read(OneWire_t* OneWire, uint8_t *ROM, float *destination) 
{
	uint16_t temperature;
	uint8_t resolution;
	int8_t digit, minus = 0;
	float decimal;
	uint8_t i = 0;
	uint8_t data[9];
	uint8_t crc;
	
	/* Check if device is DS18B20 */
	if (!DS18B20_Is(ROM)) {
		return false;
	}
	
	/* Check if line is released, if it is, then conversion is complete */
	if (!OneWire_ReadBit(OneWire)) 
	{
		/* Conversion is not finished yet */
		return false; 
	}

	/* Reset line */
	OneWire_Reset(OneWire);
	/* Select ROM number */
	OneWire_SelectWithPointer(OneWire, ROM);
	/* Read scratchpad command by onewire protocol */
	OneWire_WriteByte(OneWire, ONEWIRE_CMD_RSCRATCHPAD);
	
	/* Get data */
	for (i = 0; i < 9; i++) 
	{
		/* Read byte by byte */
		data[i] = OneWire_ReadByte(OneWire);
	}
	
	/* Calculate CRC */
	crc = OneWire_CRC8(data, 8);
	
	/* Check if CRC is ok */
	if (crc != data[8])
		/* CRC invalid */
		return 0;

	
	/* First two bytes of scratchpad are temperature values */
	temperature = data[0] | (data[1] << 8);

	/* Reset line */
	OneWire_Reset(OneWire);
	
	/* Check if temperature is negative */
	if (temperature & 0x8000)
	{
		/* Two's complement, temperature is negative */
		temperature = ~temperature + 1;
		minus = 1;
	}

	
	/* Get sensor resolution */
	resolution = ((data[4] & 0x60) >> 5) + 9;

	
	/* Store temperature integer digits and decimal digits */
	digit = temperature >> 4;
	digit |= ((temperature >> 8) & 0x7) << 4;
	
	/* Store decimal digits */
	switch (resolution) 
	{
		case 9:
			decimal = (temperature >> 3) & 0x01;
			decimal *= (float)DS18B20_DECIMAL_STEPS_9BIT;
		break;
		case 10:
			decimal = (temperature >> 2) & 0x03;
			decimal *= (float)DS18B20_DECIMAL_STEPS_10BIT;
		 break;
		case 11: 
			decimal = (temperature >> 1) & 0x07;
			decimal *= (float)DS18B20_DECIMAL_STEPS_11BIT;
		break;
		case 12: 
			decimal = temperature & 0x0F;
			decimal *= (float)DS18B20_DECIMAL_STEPS_12BIT;
		 break;
		default: 
			decimal = 0xFF;
			digit = 0;
	}
	
	/* Check for negative part */
	decimal = digit + decimal;
	if (minus) 
		decimal = 0 - decimal;
	
	
	/* Set to pointer */
	*destination = decimal;
	
	/* Return 1, temperature valid */
	return true;
}

Family Code 확인

먼저 발견된 장치의 주소 첫 바이트가 0x28(DS18B20의 family code)인지 확인한다. 0x28이 아니면 올바른 센서가 아니므로 false를 반환한다.

Read Scratchpad

OneWire_Reset(OneWire);
OneWire_SelectWithPointer(OneWire, ROM);       // 특정 주소의 센서 선택
OneWire_WriteByte(OneWire, 0xBE);              // Read Scratchpad 명령

이전 글("어디서도 안 알려주는 프로토콜의 원리")에서 다룬 Read Scratchpad(0xBE) 명령이 여기서 사용된다. 이 명령을 보내면 센서의 Scratchpad에서 9바이트의 데이터를 읽어올 수 있다.

for (i = 0; i < 9; i++) {
    data[i] = OneWire_ReadByte(OneWire);
}

9바이트를 모두 읽은 후 CRC 검사를 수행하여 데이터 오류 여부를 확인한다. 오류가 있으면 false를 반환한다.

ManualConvert 분석 — 온도 계산

읽어온 9바이트 중 0번지와 1번지에 온도 정보가 들어있다.

16비트 temperature 값 조합

temperature = (uint16_t)(data[1] << 8 | data[0]);

1번지를 상위 8비트로, 0번지를 하위 8비트로 합쳐 16비트 temperature 값을 만든다.

음수 검사

if (temperature & 0x8000) {
    minus = 1;
    temperature = (temperature ^ 0xFFFF) + 1;  // 2의 보수
}

MSB(최상위 비트)가 1이면 음수다. 0x8000(= 1000000000000000)과 AND 연산하여 MSB만 검사한다. 음수인 경우 2의 보수 연산으로 양수로 변환하고 minus 플래그를 설정한다.

정수부와 소수부 분리

digit = temperature >> 4;                    // 상위 12비트 → 정수부
digit |= ((temperature >> 8) & 0x7) << 4;

16비트 temperature 값에서 상위 12비트가 정수부, 하위 4비트가 소수부에 해당한다.

Resolution에 따른 소수점 계산

resolution = ((data[4] & 0x60) >> 5) + 9;

Scratchpad의 4번지에서 resolution 정보를 읽어온다. 12비트 해상도의 경우:

case 12:
    decimal = (temperature & 0x0F) * 0.0625;
    break;

하위 4비트를 추출하여 0.0625를 곱하면 소수점 값이 된다. 0.0625는 1/16로, 4비트(16단계)로 0~1 사이를 나눈 최소 단위다.

최종 온도값

float decimal = digit + decimal_part;
if (minus) decimal = 0 - decimal;
*destination = decimal;

정수부와 소수부를 더하고, 음수였다면 마이너스를 적용하여 최종 온도값(float)을 destination 포인터에 저장한다. 이 값이 이전 글("1-Wire 통신")에서 ds18b20[0].Temperature로 읽었던 값이다.

ManualConvert 전체 흐름 정리

DS18B20_StartAll — 0xCC(Skip ROM) + 0x44(Convert T)로 온도 변환 시작
DS18B20_AllDone — 1비트 읽기로 변환 완료 대기 (타임아웃 5000ms)
DS18B20_Read — family code 0x28 확인
Read Scratchpad(0xBE) — 9바이트 읽기 + CRC 검사
0번지/1번지 → 16비트 temperature 조합
0x8000으로 음수 검사, 2의 보수 변환
상위 12비트(정수) + 하위 4비트 × 0.0625(소수) → float 온도값

온도 센서 검증

검증 방법

온도 센서의 정확도를 확인하는 방법은 여러 가지가 있다.

비교 테스트: 신뢰할 수 있는 다른 온도 센서와 함께 측정하여 오차 확인. 가장 간단한 방법
전문 기관 검증: 상용화를 목표로 한다면 온도 센서 검증 기관에서 고정밀 장치로 테스트. 고온/저온을 발생시켜 오차를 측정하고 증서를 발행
기전력 표 이용: K 타입 센서 등 특정 센서는 기전력 테이블이 있어, 센서를 제거하고 임의의 전류값을 넣어 해당 온도에 맞는지 확인

실제 검증 결과

이번 강의에서는 차가운 물과 뜨거운 물에 센서를 넣어 시중 센서와 비교하는 방식으로 검증했다.

조건	DS18B20	비교 센서	오차
차가운 물	8.5°C	7.6°C	약 0.9°C
뜨거운 물 (~80°C)	36.6°C	35.5°C	약 1.1°C

약 1°C 내외의 오차는 일반적인 실험용으로 충분히 허용 가능한 범위다. 고추 건조기 프로젝트에서 설정 온도대로 건조기를 제어하는 용도로는 문제없다.

정리

온도 센서 시리즈를 정리하면:

온도센서를 붙여보자 — 센서 소개, 1-Wire 통신 특징, read_bit/read 함수 분석, 하드웨어 배선
1-Wire 통신 — 라이브러리 포팅, 컴파일 에러 해결, 타이머/클럭 설정, 온도 측정 및 FND 표시
어디서도 안 알려주는 프로토콜의 원리 — 1-Wire 통신의 장단점 예측, ROM/Function 커맨드, 데이터 송수신 타이밍
다른 사람 소스 분석하는 방법 — Ds18b20_Init 흐름, ROM Search 알고리즘
이번 글 — Ds18b20_ManualConvert 흐름, 온도 계산 비트 연산, 센서 검증

다음 글에서는 릴레이를 사용하여 드라이기를 제어하는 방법을 다룬다. 릴레이는 GPIO Output 제어와 회로 구성이 주를 이루어 비교적 간단하다.

[오제이 튜브 임베디드 강의] 26. 다른 사람 소스 분석하는 방법

onebrotravel — Sun, 26 Apr 2026 20:21:12 +0900

남의 소스를 분석하는 깊이

다른 사람의 소스 코드를 분석할 때, C언어 문법이 어려운 게 아니라 코드가 표현하려는 "논리"를 파악하는 것이 더 어렵다. 라이브러리처럼 블랙박스로 처리된 코드는 내부를 몰라도 사용할 수 있지만, 코드에 대한 깊은 이해는 개발자로서의 성장에 필수적이다.

소스 코드를 어디까지 파고들지는 필요에 따라 선택하면 된다. 특정 센서를 계속 사용해야 한다면 더 깊이 분석해야 하지만, 단순히 온도 값을 불러오는 것이 목적이라면 Ds18b20_Init과 Ds18b20_ManualConvert 두 함수만 이해하면 충분하다.

이번 글에서는 이전 글들에서 포팅하여 사용한 DS18B20 라이브러리의 내부를 분석한다.

ROM Search — 단일 선에서 여러 장치 주소 찾기

왜 문제인가

이전 글("어디서도 안 알려주는 프로토콜의 원리")에서 1-Wire는 주소 체계(ROM 코드)를 사용한다고 다뤘다. 그런데 여러 장치가 하나의 신호선에 연결되어 있을 때, 각 장치가 동시에 자기 주소를 보내면 전기적 신호가 중첩되어 Master는 올바른 값을 읽을 수 없다. 이 문제를 어떻게 해결할까?

핵심 원리: 0이 1을 덮는다

이전 글에서 다뤘듯이 1-Wire에서 0을 보낼 때는 60~120μs 동안 Low를 유지하고, 1을 보낼 때는 1μs만 Low로 내린다. 여러 장치가 동시에 0과 1을 보내면 0의 긴 Low 신호가 1의 짧은 Low 신호를 덮어써서 Master는 0으로 읽게 된다.

ROM Search 4단계

Master가 Search ROM (0xF0) 커맨드를 전송
Master가 Slave들로부터 1비트를 읽는다 (id_bit)
Master가 Slave들로부터 그 비트의 보수를 읽는다 (cmp_id_bit)
두 값의 경우의 수를 판단하여 0 또는 1을 Write

id_bit	cmp_id_bit	의미
0	0	연결된 장치들의 해당 비트가 0과 1이 섞여 있음
0	1	연결된 장치들의 해당 비트가 모두 0
1	0	연결된 장치들의 해당 비트가 모두 1
1	1	연결된 장치가 없음

예시로 따라가기

4개의 장치가 연결되어 있다고 가정한다.

ROM1: 00110101...
ROM2: 10101010...
ROM3: 11110101...
ROM4: 00010001...

1번째 비트 읽기:

ROM1~4가 각각 첫 번째 비트 0, 1, 1, 0을 동시에 보낸다. 0이 1을 덮으므로 Master는 id_bit = 0으로 읽는다. 보수를 취해 1, 0, 0, 1을 보내면 마찬가지로 cmp_id_bit = 0으로 읽힌다.

결과는 (0, 0) — 비트가 섞여 있다. Master가 0을 Write하면, 첫 번째 비트가 1인 ROM2, ROM3는 탈락하고 ROM1, ROM4만 남는다.

2번째 비트 읽기:

ROM1, ROM4의 두 번째 비트가 모두 0이므로 id_bit = 0, 보수는 모두 1이므로 cmp_id_bit = 1. 결과는 (0, 1) — 모두 0이다. Master는 두 장치의 두 번째 비트가 0임을 알아낸다.

3번째 비트 읽기:

ROM1의 세 번째 비트는 1, ROM4는 0. 다시 (0, 0)으로 섞여 있다. Master가 0을 Write하면 ROM1이 탈락하고 ROM4만 남는다. 이후 64비트까지 계속 읽어서 ROM4의 전체 주소를 확정한다.

다음 장치 검색:

(0, 0)이었던 분기점으로 돌아가서 이번에는 반대 값(1)을 Write하여 다른 장치를 찾아간다. 이 과정을 반복하면 모든 장치의 64비트 주소를 순차적으로 확인할 수 있다.

DS18B20 소스 분석: Ds18b20_Init

소스 코드는 크게 두 부분으로 나뉜다: ds18b20.c(칩 자체 기능)와 onewire.c(1-Wire 통신 방식). Ds18b20_Init 함수가 모든 동작의 시작점이다.

Ds18b20_Init 함수 코드

1단계: OneWire_Init — GPIO 초기화

OneWire_Init(&OneWire, _DS18B20_GPIO, _DS18B20_PIN);

이전 글("1-Wire 통신")에서 ds18b20Config.h에 설정한 GPIO 포트(PA3)와 핀으로 OneWire 구조체를 초기화한다. 내부적으로 GPIO 핀을 설정하고 High-Low-High 신호를 한 번 보내는 초기 동작을 수행한다.

OneWire 구조체(OneWire_t)에는 중요한 멤버들이 있다.

ROM_NO[8]: 발견된 장치의 64비트 주소 저장 (uint8_t × 8 = 64비트)
LastDiscrepancy: ROM Search에서 마지막 분기점 위치

OneWire_t 구조체 정의

2단계: OneWire_First — 첫 번째 장치 검색

OneWireDevices = OneWire_First(&OneWire);

내부적으로 분기점 관련 플래그들을 0으로 초기화한 후, OneWire_Search를 호출한다.

3단계: OneWire_Search — ROM Search 실행

OneWire_Search가 위에서 설명한 ROM Search 4단계를 실제로 구현한 함수다.

OneWire_Reset으로 리셋 펄스 전송 (480μs Low)
Slave의 Presence Pulse 확인 (응답 없으면 0 반환)
OneWire_WriteByte(0xF0) — Search ROM 커맨드 전송
64비트 반복: id_bit와 cmp_id_bit를 읽고 경우의 수 판단
찾은 장치의 주소를 ROM_NO[8]에 저장

uint8_t OneWire_Search(OneWire_t* OneWireStruct, uint8_t command) {
	uint8_t id_bit_number;
	uint8_t last_zero, rom_byte_number, search_result;
	uint8_t id_bit, cmp_id_bit;
	uint8_t rom_byte_mask, search_direction;

	/* Initialize for search */
	id_bit_number = 1;
	last_zero = 0;
	rom_byte_number = 0;
	rom_byte_mask = 1;
	search_result = 0;

	// if the last call was not the last one
	if (!OneWireStruct->LastDeviceFlag)
	{
		// 1-Wire reset
		if (OneWire_Reset(OneWireStruct)) 
		{
			/* Reset the search */
			OneWireStruct->LastDiscrepancy = 0;
			OneWireStruct->LastDeviceFlag = 0;
			OneWireStruct->LastFamilyDiscrepancy = 0;
			return 0;
		}

		// issue the search command 
		OneWire_WriteByte(OneWireStruct, command);  

		// loop to do the search
		do {
			// read a bit and its complement
			id_bit = OneWire_ReadBit(OneWireStruct);
			cmp_id_bit = OneWire_ReadBit(OneWireStruct);

			// check for no devices on 1-wire
			if ((id_bit == 1) && (cmp_id_bit == 1)) {
				break;
			} else {
				// all devices coupled have 0 or 1
				if (id_bit != cmp_id_bit) {
					search_direction = id_bit;  // bit write value for search
				} else {
					// if this discrepancy if before the Last Discrepancy
					// on a previous next then pick the same as last time
					if (id_bit_number < OneWireStruct->LastDiscrepancy) {
						search_direction = ((OneWireStruct->ROM_NO[rom_byte_number] & rom_byte_mask) > 0);
					} else {
						// if equal to last pick 1, if not then pick 0
						search_direction = (id_bit_number == OneWireStruct->LastDiscrepancy);
					}
					
					// if 0 was picked then record its position in LastZero
					if (search_direction == 0) {
						last_zero = id_bit_number;

						// check for Last discrepancy in family
						if (last_zero < 9) {
							OneWireStruct->LastFamilyDiscrepancy = last_zero;
						}
					}
				}

				// set or clear the bit in the ROM byte rom_byte_number
				// with mask rom_byte_mask
				if (search_direction == 1) {
					OneWireStruct->ROM_NO[rom_byte_number] |= rom_byte_mask;
				} else {
					OneWireStruct->ROM_NO[rom_byte_number] &= ~rom_byte_mask;
				}
				
				// serial number search direction write bit
				OneWire_WriteBit(OneWireStruct, search_direction);

				// increment the byte counter id_bit_number
				// and shift the mask rom_byte_mask
				id_bit_number++;
				rom_byte_mask <<= 1;

				// if the mask is 0 then go to new SerialNum byte rom_byte_number and reset mask
				if (rom_byte_mask == 0) {
					//docrc8(ROM_NO[rom_byte_number]);  // accumulate the CRC
					rom_byte_number++;
					rom_byte_mask = 1;
				}
			}
		} while (rom_byte_number < 8);  // loop until through all ROM bytes 0-7

		// if the search was successful then
		if (!(id_bit_number < 65)) {
			// search successful so set LastDiscrepancy,LastDeviceFlag,search_result
			OneWireStruct->LastDiscrepancy = last_zero;

			// check for last device
			if (OneWireStruct->LastDiscrepancy == 0) {
				OneWireStruct->LastDeviceFlag = 1;
			}

			search_result = 1;
		}
	}

	// if no device found then reset counters so next 'search' will be like a first
	if (!search_result || !OneWireStruct->ROM_NO[0]) {
		OneWireStruct->LastDiscrepancy = 0;
		OneWireStruct->LastDeviceFlag = 0;
		OneWireStruct->LastFamilyDiscrepancy = 0;
		search_result = 0;
	}

	return search_result;
}

OneWire_Search가 1을 반환하면 장치를 찾은 것이고, 0을 반환하면 더 이상 장치가 없는 것이다.

4단계: 여러 장치 검색 및 주소 저장

while (OneWireDevices) {
    TempSensorCount++;
    OneWire_GetFullROM(&OneWire, ds18b20[TempSensorCount - 1].Address);
    OneWireDevices = OneWire_Next(&OneWire);
}

장치를 찾을 때마다 TempSensorCount를 증가시키고, OneWire_GetFullROM으로 주소를 ds18b20 배열에 저장한다. OneWire_Next로 다음 장치를 계속 검색하며, 더 이상 장치가 없으면 while문을 빠져나온다.

장치를 하나도 못 찾으면 최대 5번(Ds18b20TryToFind = 5) 재시도한 후 false를 반환한다.

5단계: 정밀도 설정

DS18B20_SetResolution(&OneWire, ds18b20[i].Address, DS18B20_Resolution_12bits);
DS18B20_DisableAlarmTemperature(&OneWire, ds18b20[i].Address);

찾은 장치에 대해 온도 정밀도를 12비트로 설정하고, 알람 Threshold를 비활성화한다. 이전 글("어디서도 안 알려주는 프로토콜의 원리")에서 다뤘듯이 9비트(93.75ms)~12비트(750ms) 중 선택할 수 있으며, 12비트가 가장 정밀하지만 변환 시간이 가장 길다.

Ds18b20_Init 전체 흐름 정리

OneWire_Init — GPIO PA3 초기화, 초기 신호 전송
3초 미만이면 100ms 대기
OneWire_First → OneWire_Search(0xF0) — 첫 번째 장치 검색, ROM_NO[8]에 주소 저장
while문에서 OneWire_GetFullROM으로 주소를 ds18b20 배열에 복사
OneWire_Next — 다음 장치 검색, 없으면 while 종료
장치를 못 찾으면 최대 5번 재시도
DS18B20_SetResolution — 12비트 정밀도 설정
DS18B20_DisableAlarmTemperature — 알람 비활성화

이 흐름을 이해하면 Ds18b20_Init() 한 줄이 내부적으로 어떤 일을 하는지 파악한 것이다.

분석의 깊이에 대한 조언

임베디드 프로그래밍에서 가장 중요한 자세는 "알고 보면 쉽다"는 마음가짐이다. 어려운 문제도 기초로 돌아가 문서와 코드를 분석하고 추리하면 결국 해결할 수 있다. 이번 글에서 ROM Search 알고리즘이 복잡해 보이지만, "0이 1을 덮는다"는 하나의 물리적 원리에서 전체가 설명된다.

코딩이 안 되는 이유는 크게 두 가지다: 언어 문제(C언어 문법)와 논리 이해 문제(프로토콜 원리, 알고리즘). 지금까지의 강의처럼 데이터시트를 읽고 프로토콜 원리를 이해하는 과정은 논리 이해에 해당한다. 부족한 선행 지식이 무엇인지 파악하고 보충하는 것이 학습의 핵심이다.

[오제이 튜브 임베디드 강의] 25. 어디서도 안 알려주는 프로토콜의 원리

onebrotravel — Sun, 26 Apr 2026 20:02:09 +0900

유선 프로토콜의 원리

이번 강의는 코드 작성 없이 프로토콜의 원리를 이해하는 이론 강의다. 강사가 다양한 통신 장비 개발 경험을 통해 내린 결론은, 세상에 존재하는 모든 유선 프로토콜은 특정 틀에서 벗어나지 않는다는 것이다. 이 원리를 이해하면 새로운 프로토콜을 접할 때 훨씬 수월하다.

프로토콜의 분류

프로토콜은 크게 세 가지로 분류할 수 있다.

분류	예시	특징
물리적 통신 방식만 규정	SPI, I2C	전기 신호 수준의 규칙만 정의
물리적 + SW 규칙까지 규정	1-Wire	물리적 방식과 커맨드 체계까지 정의
SW 규칙만 정의	HTTP, Modbus, TCP	물리적 방식은 하위 레이어에 의존

SW 규칙만 정의하는 프로토콜은 대부분 레이어 구조를 가진다. 예를 들어 HTTP는 TCP 위에 올라가므로, TCP의 장단점을 그대로 물려받는다. 마치 클래스 상속처럼, 하위 레이어의 특성이 상위 레이어에 영향을 주는 것이다.

1-Wire 통신의 장점

1-Wire 통신의 최대 장점은 단 두 선만으로 양방향 통신이 가능하다는 것이다. 더 나아가 두 선으로 전원 공급까지 가능하다.

선 가닥수는 비용과 직결된다. 수백 개의 장치가 연결되는 환경에서는 선 하나 줄이는 것이 하드웨어 비용, 선 자체 가격, 인건비 모두에 영향을 미친다. 이는 UTP 선으로 전원과 통신을 동시에 제공하는 PoE(Power over Ethernet) 시스템이 현장에서 크게 선호되는 것과 같은 이유다.

두 가지 모드

Normal Power Mode (우리가 사용하는 모드)

GND(접지) + DQ(신호선) + VDD(전원선) 3선을 사용한다. 5V 전원과 4.7kΩ 풀업 저항을 거쳐 신호선이 MCU의 GPIO에 연결된다. 이전 글("온도센서를 붙여보자")에서 구성한 배선이 이 모드다.

Parasite Power Mode

GND와 VDD를 묶어버리고, 데이터 선 하나로 전원 공급과 신호 송수신을 모두 수행한다. "기생(Parasite)"이라는 이름처럼 데이터 선에서 전원을 빼내는 구조다.

Normal Power Mode vs Parasite Power Mode 회로도

구조에서 예측하는 특징

1-Wire의 물리적 구조를 보면, 이전에 배운 통신 방식들과 비교하여 몇 가지 특징을 예측할 수 있다.

장거리 통신은 힘들다

신호선 하나로 전압의 High/Low를 이용하여 통신하는 방식은 노이즈에 취약하다. 이전 글("printf도 쉽지 않다구")에서 다룬 RS232도 같은 이유로 장거리에 불리하다. 선 길이가 길어질수록 전압 강하도 발생한다.

주소 체계를 사용할 것이다

여러 장치가 하나의 신호선에 연결되어 있으면, 특정 장치와 통신하려면 주소로 구분해야 한다. 그렇지 않으면 모든 장치가 동시에 응답하여 전기적 충돌이 발생한다. 이전 글("SPI통신 제대로 배워보자")에서 SPI는 CS 선(하드웨어적)으로 해결했고, I2C는 주소(소프트웨어적)로 해결한다고 배웠다. 1-Wire도 ROM 코드라는 주소 체계를 사용한다.

빠른 속도는 불가능하다

클럭 선이 없으므로 SPI처럼 클럭 기반 동기화가 불가능하다. 시간을 미리 쪼개서 데이터를 보내는 타임베이스 방식을 사용할 수밖에 없다. 실제로 온도 변환에만 93.75ms~750ms가 소요되어 고속 통신과는 거리가 멀다.

하드웨어 구성이 간단하다

선이 적으므로 회로 구성이 단순하다. 이것이 1-Wire가 온도 센서 같은 단순한 장치에 많이 사용되는 이유다.

통신 시작 시퀀스

1-Wire 통신은 Master가 리셋 펄스를 보내는 것으로 시작된다.

Master: 신호선을 480μs 이상 Low 상태로 유지 (리셋 펄스)
Master: 신호선을 놓아 High로 복귀
Slave: 15~60μs 대기
Slave: 60~240μs 동안 Low 상태 유지 (Presence Pulse — "나 살아있어")
Master: Presence Pulse를 읽고 통신 시작을 인지

이 시퀀스는 시간을 기반으로 신호를 구분하는 방식이다. 480μs 미만으로 Low를 보내면 시작 신호로 인식되지 않는다. 이전 글("1-Wire 통신")에서 설정한 1μs 단위 타이머가 이 타이밍 제어에 사용된다.

실제로 라이브러리의 OneWire_Reset 함수에서 480μs 딜레이 후 인풋을 읽는 코드가 존재하여, 데이터시트와 코드가 일치함을 확인할 수 있다.

ROM 커맨드 — 장치 선택

통신이 시작되면 Master는 ROM 커맨드를 보내 통신 대상을 선택한다. 모든 1-Wire 장치는 ROM 코드(주소)를 가지며, 이 커맨드는 장치 종류에 관계없이 모든 1-Wire 장치가 공통으로 지키는 약속이다.

커맨드	코드	기능
Search ROM	0xF0	버스에 연결된 모든 Slave의 ROM 코드(주소) 읽기
Match ROM	0x55	특정 64비트 ROM 코드에 해당하는 Slave만 선택
Skip ROM	0xCC	모든 Slave에 동시에 커맨드 전송
Alarm Search	0xEC	알람 플래그가 설정된 Slave 확인

Search ROM은 연결된 장치가 뭐가 있는지, 주소가 무엇인지 알아내는 명령이다. Match ROM은 특정 장치를 선택한 뒤 명령을 내리는 것이고, 선택되지 않은 장치들은 리셋 펄스가 올 때까지 대기한다.

이전 글("SPI통신 제대로 배워보자")에서 SPI의 CS 선이 "누구에게 말하는가?"를 해결했듯이, 1-Wire에서는 ROM 커맨드가 같은 역할을 소프트웨어적으로 수행하는 것이다.

Function 커맨드 — 장치별 동작

ROM 커맨드와 달리 Function 커맨드는 제조사와 칩의 종류마다 다르다. 온도 센서는 온도 변환 명령이 있고, 도어락은 문 열기 명령이 있을 것이다. DS18B20의 주요 Function 커맨드:

커맨드	코드	기능
Convert T	0x44	온도 변환 시작. 변환 시간 93.75ms(9비트)~750ms(12비트)
Write Scratchpad	0x4E	3바이트 데이터를 Scratchpad(임시 저장 공간)에 쓰기
Read Scratchpad	0xBE	Scratchpad 데이터 읽기
Copy Scratchpad	0x48	Scratchpad 내용을 EEPROM에 영구 저장
Recall E²	0xB8	EEPROM에서 알람 Threshold 값과 설정 데이터를 Scratchpad로 불러오기

Scratchpad는 전원이 꺼지면 사라지는 임시 저장 공간이다. 영구 보존이 필요하면 Copy Scratchpad로 EEPROM에 저장해야 한다. Threshold(임계값)는 특정 동작을 트리거하는 기준값으로, 이 값을 넘으면 알람이 발생한다.

Parasite Power Mode에서는 Convert T 커맨드를 보낸 후 신호선을 High 상태로 유지하여 온도 변환 동안 전원을 공급해야 한다.

데이터 송수신 — 시간으로 0과 1을 구분

1-Wire의 데이터 송수신은 1 슬롯에 1비트를 보내는 방식이다. 0과 1의 구분 방법이 독특하다.

Master가 데이터를 보낼 때:

0을 보낼 때: GPIO를 60~120μs 동안 Low 유지
1을 보낼 때: GPIO를 1μs 동안만 Low로 내렸다가 바로 High

즉 Low 상태의 시간 길이로 0과 1을 구분한다. Slave는 15~60μs 사이에 샘플링하여 값을 읽는다.

Slave가 데이터를 보낼 때:

Master가 1μs 이상 신호선을 Low로 내리면 Slave가 전송 가능
Slave가 0을 표현할 때 15μs 동안 Low 유지
Master는 15μs 안에 값을 읽어야 함

이전 글("온도센서를 붙여보자")에서 분석한 read_bit 함수가 바로 이 동작을 구현한 것이다. Output으로 Low를 보낸 뒤 Input으로 전환하여 읽는 과정이 데이터시트의 타이밍과 정확히 일치한다.

[오제이 튜브 임베디드 강의] 24. 1-Wire 통신! 나름 유명했다.

onebrotravel — Sun, 26 Apr 2026 19:54:48 +0900

라이브러리 포팅

이전 글("온도센서를 붙여보자")에서 온도 센서의 원리, 1-Wire 통신의 특징, 샘플 코드 분석, 하드웨어 배선까지 완료했다. 이번 글에서는 DS18B20 라이브러리를 STM32 프로젝트에 포팅하여 실제로 온도를 읽고 FND에 표시한다.

강의에서 사용하는 DS18B20 라이브러리(nimaltd/ds18b20)는 현재 최신 버전과 크게 달라졌다. 이 섹션에서는 강의에서 사용하는 이전 버전(GitHub 커밋 링크)을 기준으로 진행한다. 현재 버전 적용은 글 후반부에서 별도로 다룬다.

폴더 구조 및 파일 복사

프로젝트의 Core 폴더 안에 Lib 폴더를 생성하고, 그 안에 Inc(헤더)와 Src(소스) 폴더를 만든다.

Src 폴더: ds18b20.c, onewire.c
Inc 폴더: ds18b20.h, ds18b20Config.h, onewire.h

Core/Lib/Inc, Src 폴더 구조

컴파일 에러 해결

파일을 복사한 후 컴파일하면 여러 에러가 순서대로 발생한다. 하나씩 해결한다.

(1) onewire.h, ds18b20.h — Include 경로 미지정

컴파일러가 헤더 파일을 찾지 못한다. Project → Properties → C/C++ Build → Settings → Include paths에 Lib/Inc 경로를 추가한다.

Include paths 설정

(2) gpio.h — 존재하지 않는 파일

gpio.h를 include하고 있지만 우리 프로젝트에는 이 파일이 없다. gpio.h를 주석 처리하면 GPIO_TypeDef 타입을 찾을 수 없다는 에러가 발생한다. GPIO_TypeDef는 stm32f103xb.h에 정의되어 있고, main.h가 이를 include하고 있으므로 onewire.h에서 main.h를 include하면 해결된다.

(3) cmsis_os.h — FreeRTOS 미사용

ds18b20Config.h에서 _DS18B20_USE_FREERTOS가 1로 설정되어 있으면 FreeRTOS 헤더를 include하려 한다. 우리는 FreeRTOS를 사용하지 않으므로 이 값을 0으로 변경한다.

(4) tim.h — 타이머 미생성

tim.h를 주석 처리하면 타이머 핸들러가 정의되지 않았다는 에러가 발생한다. 이를 해결하려면 STM32CubeIDE에서 TIM2를 활성화하여 타이머를 생성해야 한다.

(5) GPIO, PIN 설정

ds18b20Config.h에서 GPIO 포트와 핀을 설정해야 한다. 이전 글에서 온도 센서 DAT 핀을 PA3에 연결했으므로, main.h에 정의된 TEMP_DATA_GPIO_Port와 TEMP_DATA_Pin을 사용한다. ds18b20Config.h에 main.h를 include하고 GPIO/PIN 값을 설정한다.

[IMG: ds18b20Config.h 설정]

(6) 타이머 핸들러 설정

ds18b20Config.h에서 타이머를 htim2로 설정한다. htim2는 main.c에 전역 변수로 선언되어 있으므로, Config 파일에서 extern TIM_HandleTypeDef htim2;를 작성하여 참조한다.

이 과정을 모두 거치면 에러 없이 컴파일이 완료된다.

타이머와 클럭 설정

Prescaler와 Counter Period

라이브러리에서 "1틱이 1μs가 되도록 타이머를 설정하라"고 요구한다. 타이머의 시간 조절은 Prescaler(분주비)와 Counter Period(카운터 주기) 두 가지로 이루어진다.

현재 클럭이 8MHz(= 8,000,000Hz)일 때:

Prescaler = (10000 - 1): 8MHz를 10000으로 나눠 800Hz로 만든다. 즉 카운터가 1 증가하는 데 10000 클럭이 필요
Counter Period = (800 - 1): 카운터가 0~799까지 올라가고 다시 0으로 돌아오면 인터럽트 발생. 800Hz로 카운터가 증가하므로 800번 세면 1초

하지만 라이브러리가 요구하는 것은 1초가 아니라 1μs이므로, 클럭을 72MHz로 올려야 한다.

RCC로 72MHz 변경

RCC Clock Configuration — 72MHz

STM32CubeIDE의 .ioc에서 RCC → High Speed Clock → Crystal/Ceramic Resonator를 선택하여 외부 크리스탈을 활성화한다. Clock Configuration에서 HCLK를 72MHz로 설정한다.

72MHz에서 1μs 틱을 만들려면:

Prescaler = (72 - 1): 72MHz를 72로 나눠 1MHz로 만든다. 1MHz는 1초에 1,000,000번이므로 1틱 = 1μs
Counter Period = 0xFFFF: 최대값으로 설정

Counter Period를 작게 설정하면 onewire 내부의 while문에서 카운터 값이 기대보다 작아져 무한 루프가 발생한다. 반드시 0xFFFF로 설정해야 한다.

TIM2 설정 — Prescaler 71, Counter Period 65535

클럭 변경에 따른 딜레이 조정

클럭이 8MHz에서 72MHz로 9배 빨라졌으므로, 기존 코드의 HAL_Delay(50)을 HAL_Delay(450)으로 변경해야 이전과 비슷한 속도로 동작한다.

온도 측정 및 FND 표시

초기화 및 온도 읽기

// main.c
#include "ds18b20.h"

// main 함수 내
Ds18b20_Init();

while (1) {
    Ds18b20_ManualConvert();
    // ds18b20[0].Temperature에 온도값이 저장됨
    int temp = (int)(ds18b20[0].Temperature * 10);  // 소수점 1자리까지 정수로 변환
    DG_Temper(temp);
}

Ds18b20_Init()을 호출하면 센서와 1-Wire 통신이 초기화되고, Ds18b20_ManualConvert()를 호출하면 온도 변환이 수행된다. 변환 결과는 ds18b20[0].Temperature에 float으로 저장된다.

디버그 워치 — Temperature 값 확인

FND에 온도 표시

이전 글("FND 제어 소스 분석")에서 구현한 DG_Temper 함수를 활용한다. 온도값에 10을 곱해 정수로 변환한 뒤 DG_Temper에 전달하면, 소수점이 포함된 온도가 FND에 표시된다.

프로브를 손으로 잡으면 온도가 올라가고, 놓으면 내려가는 것을 확인할 수 있다.

FND에 온도 표시 — 프로브 잡았을 때/놓았을 때

트러블슈팅: GND 선 빠짐

강의 중 온도가 변하지 않고 고정값만 출력되는 문제가 발생했다. 원인은 허무하게도 GND 선이 빠져 있었던 것이다.

GND가 빠지면 송수신 신호의 기준점이 사라져 간헐적인 통신 오류가 발생한다. 때로는 값이 읽히는 것처럼 보이지만 실제로는 정확하지 않은 데이터다. 이전 글들("전기 기본상식", "printf도 쉽지 않다구")에서 GND가 신호의 기준점이라고 강조했는데, 이번에 실제로 체감한 사례다.

임베디드에서 동작이 이상할 때는 코드를 의심하기 전에 물리적 연결부터 확인하는 습관이 중요하다.

현재 버전 라이브러리 적용

강의에서 사용한 이전 버전과 달리, DS18B20 라이브러리의 현재 버전(GitHub 링크)은 구조가 크게 바뀌었다. 본인은 두 버전을 모두 적용해보았다.

이전 버전과의 차이

항목	이전 버전 (강의)	현재 버전
방식	블로킹	Non-Blocking (타이머 콜백)
파일 구성	ds18b20.c/h + onewire.c/h 단일	ds18b20.c/h + 별도 ow 라이브러리
1-Wire 의존	내장	nimaltd/ow 별도 추가 필요
초기화	`Ds18b20_Init()`	`ds18b20_init()` + ow_init 구조체 설정
온도 변환	`Ds18b20_ManualConvert()`	`ds18b20_cnv()` + `ds18b20_req_read()`
온도 읽기	`ds18b20[0].Temperature`	`ds18b20_read_c()`

포팅 과정

현재 버전 포팅 — 프로젝트 폴더 구조 / 타이머 콜백 함수 설정

nimaltd/ow 라이브러리를 프로젝트에 추가
nimaltd/ds18b20 최신 버전 파일 추가
타이머 콜백 함수 설정 — ow 라이브러리가 타이머 인터럽트를 통해 Non-Blocking으로 동작

온도 측정 코드

// main.c
#include "ds18b20.h"

ds18b20_t ds18;

// 타이머 콜백
void ds18_tim_cb(TIM_HandleTypeDef *htim) {
    ow_callback(&ds18.ow);
}

// main 함수 내
ow_init_t ow_init_struct;
ow_init_struct.tim_handle = &htim2;
ow_init_struct.gpio = TEMP_DATA_GPIO_Port;
ow_init_struct.pin = TEMP_DATA_Pin;
ow_init_struct.tim_cb = ds18_tim_cb;
ow_init_struct.done_cb = NULL;
ow_init_struct.rom_id_filter = DS18B20_ID;

ds18b20_init(&ds18, &ow_init_struct);
ds18b20_update_rom_id(&ds18);
while (ds18b20_is_busy(&ds18));

while (1) {
    ds18b20_cnv(&ds18);
    while (ds18b20_is_busy(&ds18));
    while (!ds18b20_is_cnv_done(&ds18));

    ds18b20_req_read(&ds18, 0);
    while (ds18b20_is_busy(&ds18));

    int temp = (int)(ds18b20_read_c(&ds18) * 10);
    DG_Temper(temp);
}

이전 버전의 Ds18b20_Init() + Ds18b20_ManualConvert() 두 줄로 끝나던 것이, 현재 버전에서는 초기화 구조체 설정, 타이머 콜백, busy 체크 등 초기 설정이 더 복잡하다. 하지만 Non-Blocking 방식이라 CPU가 온도 변환을 기다리는 동안 다른 작업을 수행할 수 있어 실제 제품에서는 유리하다.

현재 버전 코드 — 온도 읽기 동작 확인

[오제이 튜브 임베디드 강의] 23. 온도센서를 붙여보자

onebrotravel — Sun, 26 Apr 2026 19:37:11 +0900

온도 센서 소개

고추 건조기의 핵심 기능은 온도를 측정하고 제어하는 것이다. 이번 강의부터 온도 센서를 다루며, 난이도가 높아 총 3강에 걸쳐 진행된다. 이번 글에서는 센서 소개, 샘플 코드 분석, 하드웨어 배선까지 다루고, 실제 동작은 다음 글에서 진행한다.

온도 센서는 크게 세 부분으로 구성된다.

프로브: 온도를 감지하는 쇠 막대 부분. 열이 가해지면 내부 저항값이 변하고, 이에 따라 전압값이 변한다
모듈: 프로브에서 받은 전압 변화를 내장 칩이 계산하여 디지털 데이터 신호로 변환
3개 핀: VCC(전원), GND(접지), DAT(데이터)

온도센서 실물 — 프로브·전선·모듈

순수 센서 vs 모듈

순수 센서 (ADC 방식)

프로브만 있는 순수 센서를 사용하려면, 회로를 직접 구성하여 ADC(아날로그→디지털 변환)로 전압 변화를 측정해야 한다. 이전 글("데이터시트 읽어주는 남자")에서 다룬 것처럼 STM32에는 12비트 ADC가 내장되어 있어 0~3.6V를 4096단계로 나눌 수 있다. 측정된 전압값을 온도 변환 테이블과 대조하여 온도를 구하는 방식인데, 회로 구성과 캘리브레이션의 난이도가 매우 높다.

모듈 방식 (이번 강의)

우리가 사용하는 모듈형 센서는 내장 칩이 온도 계산을 대신 해준다. 모듈이 프로브의 전압 변화를 받아 내부적으로 온도를 계산하고, DAT 핀을 통해 디지털 데이터로 STM32에 전달한다. 우리는 이 데이터를 받아서 FND에 표시하면 된다.

1-Wire 통신의 특징

이 온도 센서 모듈은 1-Wire(원 와이어) 통신을 사용한다. 이전에 다룬 SPI(MOSI/MISO/SCLK/CS)나 UART(TX/RX)와 달리, DAT 핀 하나로 읽기와 쓰기를 모두 수행하는 독특한 방식이다.

통신 방식	데이터 선 수	특징
SPI	2개 (MOSI, MISO) + 클럭	전이중, 클럭 기반
UART	2개 (TX, RX)	전이중, 타임베이스
1-Wire	1개 (DAT)	반이중, 같은 핀으로 Read/Write

1-Wire에서는 같은 DAT 핀의 GPIO 모드를 Output↔Input으로 전환하면서 데이터를 주고받는다. Output 모드에서 신호를 보내고, Input 모드로 전환하여 응답을 읽는 방식이다.

샘플 코드 분석: read_bit (1비트 읽기)

강의에서 제공된 Arduino용 OneWire 라이브러리의 read_bit 함수를 분석한다. 데이터시트를 처음부터 구현하는 것보다 샘플 코드를 분석하는 것이 훨씬 효율적이다.

read_bit 함수의 동작 순서:

인터럽트 비활성화 — 타이밍이 중요하므로 다른 인터럽트가 끼어들지 않게
DAT 핀을 Output 모드로 전환 → LOW 출력 — "데이터를 보내달라"는 신호
3μs 대기
DAT 핀을 Input 모드로 전환 — 같은 핀을 이제 읽기용으로 변경
10μs 대기
DAT 핀에서 1비트 읽기 — High면 1, Low면 0
인터럽트 재활성화
53μs 대기 — 다음 비트 읽기 전 슬롯 완료 대기
읽은 값(r) 반환

read_bit 함수 코드

핵심은 같은 DAT 선을 Output→Input으로 모드 전환하면서 사용한다는 점이다. Output으로 LOW 신호를 보내 센서에게 "데이터를 보내라"고 요청하고, Input으로 전환하여 센서가 보낸 응답을 읽는다.

샘플 코드 분석: read (1바이트 읽기)

read 함수는 read_bit을 8번 호출하여 1바이트(8비트)를 조합한다.

동작 과정:

bitMask가 0x01(= 00000001)에서 시작
read_bit()이 1을 반환하면, r |= bitMask로 해당 비트 위치를 1로 설정
bitMask <<= 1로 마스크를 왼쪽으로 시프트 (00000010, 00000100, ...)
8번 반복하면 bitMask가 00000000이 되어 for문 종료
조합된 바이트 r을 반환

이 방식은 LSB(최하위 비트)부터 읽는다. 이전 글("FND 제어")에서 다룬 send 함수가 MSB부터 보냈던 것과 반대 방향이다.

하드웨어 배선

프로브 ↔ 모듈 연결

온도 센서 프로브의 3가닥 전선을 모듈의 해당 핀에 연결한다.

프로브 전선 색상	모듈 핀
빨간색	VCC
노란색	DAT
검정색	GND

모듈 ↔ 보드 연결

모듈 핀	연결	보드 핀
VCC	빨간색 점퍼선 → 빵판 + 레일	3.3V
GND	검정색 점퍼선 → 빵판 - 레일	GND
DAT	노란색 점퍼선	PA3 (11번 핀)

프로브·모듈·빵판·보드 최종 연결

다음 글 예고

하드웨어 배선이 완료되었다. 다음 글에서는 오늘 분석한 OneWire 라이브러리를 STM32 환경에 포팅하여, 실제로 온도를 읽고 FND에 표시하는 과정을 다룬다.

[오제이 튜브 임베디드 강의] 22. STM32에서는 SPI 기능을 제공한다구

onebrotravel — Sun, 26 Apr 2026 19:28:10 +0900

프로젝트 복사 방법

새로운 기능을 추가할 때 기존 프로젝트를 복사하여 별도로 작업하고 싶은 경우가 있다. 단순히 폴더를 복사하면 메타 정보가 함께 복사되어, 복사본을 수정해도 실제로는 원본 프로젝트가 수정되는 문제가 발생할 수 있다.

가장 깔끔한 방법은 Export/Import를 활용하는 것이다. 강의에서는 폴더를 직접 복사한 뒤 IDE에서 삭제/재임포트하는 방식을 사용하지만, 아래 방법이 더 간단하고 메타 정보 충돌 위험도 없다.

Export (기존 프로젝트 내보내기):

Project Explorer에서 프로젝트 우클릭 → Export
General → Archive File 선택
저장 경로 설정 → Finish

Import (새 프로젝트로 가져오기):

새 workspace 생성
File → Import → General → Existing Projects into Workspace
Archive File 옵션에서 내보낸 .zip 파일 선택 → Finish

Export/Import 설정 화면

이 방법을 사용하면 메타 정보 충돌 없이 완전히 독립된 프로젝트가 생성된다.

GPIO SPI에서 하드웨어 SPI로 전환하는 이유

이전 글들("FND 제어", "FND 제어 소스 분석")에서는 GPIO를 직접 HIGH/LOW로 전환하여 SPI 통신을 소프트웨어적으로 구현했다. 이 방식은 동작하지만 두 가지 한계가 있다.

클럭 간격이 불균일 — HAL_GPIO_WritePin 호출 사이에 다른 코드가 실행되면서 미세한 시간 차이가 발생
코드가 복잡 — for문으로 비트를 하나씩 쪼개고, 클럭을 수동으로 생성해야 함

STM32는 SPI 통신을 하드웨어적으로 지원한다. 칩 내부의 SPI 모듈이 클럭 생성과 데이터 전송을 자동으로 처리하므로, 코드는 HAL_SPI_Transmit 한 줄로 줄어들고 클럭도 균일해진다.

핀 재배치

하드웨어 SPI를 사용하려면 STM32가 정해놓은 특정 핀으로 클럭과 데이터를 내보내야 한다. 기존 GPIO 핀 배치를 다음과 같이 변경한다.

기능	기존 (GPIO)	변경 (HW SPI)
FND_SCLK (클럭)	PB15	PB13 (SPI2_SCK)
FND_DIO (데이터)	PB14	PB15 (SPI2_MOSI)
FND_RCLK (래치)	PB13	PB14 (GPIO Output 유지)

SCLK과 DIO는 하드웨어 SPI가 담당하고, RCLK은 래치 신호이므로 여전히 GPIO Output으로 직접 제어한다.

.ioc 핀 재배치 — PB13 SPI2_SCK, PB15 SPI2_MOSI

SPI 설정

STM32CubeIDE에서 SPI2를 활성화하고 다음과 같이 설정한다. 이전 글("SPI통신 제대로 배워보자")에서 다룬 각 옵션의 의미가 여기서 실제로 적용된다.

설정 항목	값	이유
Mode	Transmit Only Master	FND에 데이터를 보내기만 함
NSS Signal	Disable	CS 핀 불필요 (FND 1개)
Data Size	8 bits	기존 send 함수가 8비트 단위 전송
First Bit	MSB First	기존 코드가 MSB부터 전송
Prescaler	500 kbps	적절한 클럭 속도
Clock Polarity (CPOL)	High	기존 코드의 클럭 기본 상태가 High
Clock Phase (CPHA)	1 Edge	기존 코드가 Rising Edge에서 데이터 전송

코드 변경

init_fnd 수정

SPI 핸들러를 매개변수로 받도록 변경한다.

// fnd_controller.h
void init_fnd(SPI_HandleTypeDef *hspi);

// fnd_controller.c
SPI_HandleTypeDef *_hspi;

void init_fnd(SPI_HandleTypeDef *hspi) {
    _hspi = hspi;
    // 기존 매핑 테이블 초기화 코드 동일
    _LED_0F[0] = 0xC0;  // 0
    _LED_0F[1] = 0xF9;  // 1
    // ...
}

send 함수 수정

기존의 for문 + GPIO 제어 코드 전체가 HAL_SPI_Transmit 한 줄로 교체된다.

// 기존 (GPIO 방식)
void send(uint8_t X) {
    for (int i = 8; i >= 1; i--) {
        if (X & 0x80)
            HAL_GPIO_WritePin(FND_DIO_GPIO_Port, FND_DIO_Pin, HIGH);
        else
            HAL_GPIO_WritePin(FND_DIO_GPIO_Port, FND_DIO_Pin, LOW);
        X <<= 1;
        HAL_GPIO_WritePin(FND_SCLK_GPIO_Port, FND_SCLK_Pin, LOW);
        HAL_GPIO_WritePin(FND_SCLK_GPIO_Port, FND_SCLK_Pin, HIGH);
    }
}

// 변경 (HW SPI 방식)
void send(uint8_t X) {
    HAL_SPI_Transmit(_hspi, &X, 1, 100);
}

send_port 함수의 RCLK 래치 부분은 GPIO로 유지하므로 변경하지 않는다.

main 함수

// main.c
#include "fnd_controller.h"

// main 함수 내
init_fnd(&hspi2);  // SPI2 핸들러 전달

int count = 0;
while (1) {
    digit4_replay(count, 10);
    count++;
    if (count > 99) count = 0;
}

주의: 코드를 반드시 USER CODE BEGIN과 USER CODE END 주석 사이에 작성해야 한다. .ioc 설정 변경 후 코드를 재생성하면 이 주석 밖의 코드는 사라진다.

오실로스코프로 파형 비교

오실로스코프로 GPIO SPI와 하드웨어 SPI의 클럭 파형을 비교하면 차이가 명확히 보인다.

GPIO SPI: 클럭 간격이 불균일. 소프트웨어 실행 시간에 따라 미세하게 달라짐
HW SPI: 클럭 간격이 매우 균일. 칩이 하드웨어적으로 정확한 타이밍을 보장

오실로스코프 — GPIO SPI vs HW SPI 클럭 파형 비교

동작 결과는 동일하다. FND에 이전과 똑같이 숫자가 올라가는 것을 확인할 수 있다. 하지만 내부적으로는 코드가 훨씬 간결해지고 클럭이 안정적이다.

정리

FND 제어 시리즈를 정리하면:

FND 제어 — 샘플 코드를 확보하여 GPIO로 SPI를 수동 구현, 일단 동작시킴
FND 제어 소스 분석 — 오실로스코프로 파형 검증, 래치/반전 동작/소수점 비트 연산 분석
이번 글 — GPIO SPI를 HAL_SPI_Transmit 한 줄로 교체, 클럭 균일성 비교

이 과정은 앞으로 다른 SPI 장치를 제어할 때도 동일하게 적용된다. GPIO로 먼저 원리를 이해한 뒤, 하드웨어 SPI로 전환하면 코드가 간결해지고 성능이 개선된다.

[오제이 튜브 임베디드 강의] 21. FND 제어 소스 분석

onebrotravel — Sun, 26 Apr 2026 19:21:29 +0900

send 함수 파형 확인

이전 글("FND 제어")에서 send 함수의 비트 연산을 코드 레벨에서 분석했다. 이번에는 오실로스코프로 실제 파형을 확인하여, 코드가 만들어내는 전기적 신호를 눈으로 검증한다.

send 함수로 0xF8(이진수 11111000)을 보냈을 때, 오실로스코프로 SCLK(클럭)과 DIO(데이터) 핀의 파형을 관찰하면 클럭에 맞춰 1,1,1,1,1,0,0,0 순서로 데이터가 전송되는 것을 확인할 수 있다.

오실로스코프 — 0xF8 전송 시 SCLK과 DIO 파형

이때 눈에 띄는 점은 클럭 간격이 완벽히 일정하지 않다는 것이다. 이는 GPIO를 소프트웨어적으로 HIGH/LOW 전환하여 클럭을 만들기 때문이다. HAL_GPIO_WritePin 함수 호출 사이에 다른 코드가 실행되면서 미세한 시간 차이가 발생한다.

SPI 통신에서는 클럭 간격이 기계적으로 완벽히 일정하지 않아도 동작한다. 클럭의 엣지 시점에 데이터를 읽기 때문에, 간격이 다소 불균일해도 데이터 전송에는 문제가 없다. 다만 STM32가 제공하는 하드웨어 SPI 통신을 사용하면 훨씬 일정한 클럭 파형을 얻을 수 있다. 이 내용은 다음 글에서 다룰 예정이다.

send_port — FND를 켜는 최소 조건

send만으로는 FND가 켜지지 않는다

main 함수에서 send(0xF8);만 호출하면 FND에 아무것도 표시되지 않는다. send 함수는 SCLK과 DIO를 통해 데이터를 시프트 레지스터에 밀어넣기만 할 뿐, FND 출력에 반영하라는 신호를 주지 않기 때문이다.

RCLK 래치 시퀀스

FND를 실제로 켜려면 send_port 함수를 사용해야 한다.

void send_port(uint8_t X, uint8_t port) {
    send(X);      // 세그먼트 데이터 전송
    send(port);   // 자릿수 선택 데이터 전송
    HAL_GPIO_WritePin(FND_RCLK_GPIO_Port, FND_RCLK_Pin, HIGH);
    HAL_GPIO_WritePin(FND_RCLK_GPIO_Port, FND_RCLK_Pin, LOW);
}

send로 8비트 데이터를 두 번 보낸 후(세그먼트 데이터 + 자릿수 선택), RCLK을 HIGH → LOW로 전환한다. 이 RCLK의 하강 엣지가 "시프트 레지스터에 들어있는 데이터를 출력 레지스터로 옮겨라"라는 래치 신호가 된다. 이 시퀀스가 FND를 동작시키는 최소 조건이다.

port 비트로 자릿수 선택

두 번째 send에서 보내는 port 값은 FND의 4자리 중 어느 자릿수에 표시할지를 결정한다.

port 값	켜지는 자릿수
`0b0001`	1번째 (1의 자리)
`0b0010`	2번째 (10의 자리)
`0b0100`	3번째 (100의 자리)
`0b1000`	4번째 (1000의 자리)

FND 반전 동작 — Low일 때 켜진다

FND의 각 세그먼트(a, b, c, d, e, f, g, dp)는 해당 비트가 0(Low)일 때 켜지고, 1(High)일 때 꺼지는 반전 방식으로 동작한다.

0xF8은 이진수로 11111000이다. 하위 3비트(a, b, c)가 0이므로 a, b, c 세그먼트가 켜진다. 이 세 세그먼트의 조합이 숫자 '7'을 표시한다.

이전 글에서 다뤘던 매핑 테이블도 이 원리로 만들어진 것이다. 예를 들어 0xC0(= 11000000)은 하위 6비트가 0이므로 a~f 세그먼트가 켜져 숫자 '0'이 된다.

7세그먼트 비트 대응 — 0xF8이 '7'로

소수점 표현 — 0x7F AND 연산

diagram_01_dp_bitmask

매핑 테이블의 데이터에서 MSB(최상위 비트)가 dp(소수점)에 대응한다. 모든 숫자 데이터의 MSB가 1이므로, 기본 상태에서는 소수점이 항상 꺼져 있다.

소수점을 켜려면 MSB를 0으로 만들면 된다. 다른 세그먼트에는 영향을 주지 않으면서 MSB만 0으로 바꾸려면 0x7F(= 01111111)와 AND 연산을 하면 된다.

// 예: 숫자 '7' 데이터에 소수점 추가
0xF8 & 0x7F
= 11111000 & 01111111
= 01111000   // MSB가 0이 되어 dp가 켜짐, 나머지는 그대로

어떤 숫자 데이터든 0x7F와 AND 연산하면 해당 숫자는 그대로 표시되면서 소수점만 추가된다.

온도 표시 함수 (DG_Temper)

FND를 온도 표시에 활용하기 위해 DG_Temper 함수를 구현한다. 이 함수는 정수 입력을 받아 소수점이 포함된 온도로 표시한다. 예를 들어 300을 넣으면 '30.0', 1234를 넣으면 '123.4'로 표시된다.

핵심은 소수점 위치를 2번째 자릿수에 고정하는 것이다. 2번째 자릿수의 데이터에만 0x7F AND 연산을 적용하면, 다른 자릿수에는 영향 없이 해당 위치에만 소수점이 찍힌다.

void DG_Temper(int n) {
    int n1, n2, n3, n4;
    n1 = n % 10;
    n2 = (n / 10) % 10;
    n3 = (n / 100) % 10;
    n4 = (n / 1000) % 10;

    send_port(_LED_0F[n1], 0b0001);
    send_port(_LED_0F[n2] & 0x7F, 0b0010);  // 2번째 자리에 소수점 추가
    send_port(_LED_0F[n3], 0b0100);
    send_port(_LED_0F[n4], 0b1000);
}

FND 소수점 포함 온도 표시

정리

이전 글("FND 제어")에서는 샘플 코드를 확보하여 일단 동작시킨 후 코드 레벨에서 분석했다. 이번 글에서는 한 단계 더 깊이 들어가서:

오실로스코프로 실제 파형을 확인하여 코드가 만드는 전기 신호를 검증했고
send만으로는 안 되고 RCLK 래치가 필요한 이유를 이해했고
FND의 반전 동작 원리(Low = 켜짐)를 파악했고
소수점 표현을 위한 비트 연산(0x7F AND)을 구현했다

다음 글에서는 GPIO로 직접 만든 SPI 통신을 STM32의 하드웨어 SPI 기능으로 대체하여, 클럭의 균일성과 코드 간결함이 어떻게 달라지는지 비교할 예정이다.

[오제이 튜브 임베디드 강의] 20. SPI통신 제대로 배워보자

onebrotravel — Sun, 26 Apr 2026 19:15:44 +0900

SPI 통신이란

diagram_01_timebase_vs_clock

SPI(Serial Peripheral Interface)는 칩과 칩, 모듈과 모듈 간의 근거리 통신에 사용되는 시리얼 통신 방식이다. I2C와 함께 임베디드 개발에서 가장 많이 사용되며, 플래시 메모리 데이터 기록 등 다양한 분야에서 활용된다.

이전 글("printf도 쉽지 않다구")에서 다룬 UART는 시간을 쪼개는 타임베이스 방식(비동기)이었다. 예를 들어 9600 bps면 1초를 9600개로 나눠서 각 구간의 전압이 High인지 Low인지로 0과 1을 구분했다.

SPI는 타임베이스가 아니라 클럭 선을 이용하는 방식(동기)이다. 클럭 주기에 맞춰 데이터 선의 High/Low를 읽어 0과 1을 구분한다. 클럭에 제약이 없으므로 이론상 속도 제한이 없다는 것이 SPI의 큰 장점이다.

데이터 통신의 기본

통신은 두 개 이상의 장치(A와 B) 사이에서 이루어진다. 데이터를 주고받으려면 전압 차이를 이용한 데이터 선이 필요하며, High = 1, Low = 0으로 데이터를 표현한다.

SPI 통신에는 최소한 데이터 선과 클럭 선이 필요하다. 클럭이 한 주기 동작할 때(LOW → HIGH → LOW) 데이터 선의 전압을 읽어서 해당 비트가 0인지 1인지 판단한다.

1:1 통신 — 반이중 vs 전이중

A와 B 사이에 데이터 선이 1개면 반이중(Half Duplex) 방식이다. A가 데이터를 보내는 동안 B는 아무것도 할 수 없고, 번갈아가며 통신한다.

데이터 선이 2개면 전이중(Full Duplex) 방식이다. A가 말하는 전용선과 B가 말하는 전용선이 각각 있어서 동시에 양방향 통신이 가능하다. SPI는 기본적으로 이 전이중 방식을 사용한다.

1:다 통신의 두 가지 문제

A가 여러 장치(B, C, D)와 통신할 때 두 가지 문제가 생긴다.

문제 1: 누가 말하는가?

A가 데이터를 보내면 B, C, D 모두가 듣게 된다. 반대로 B, C, D가 동시에 데이터를 보내면 누가 보낸 건지 구분할 수 없다.

해결: Master / Slave 관계 정의

SPI는 Master와 Slave라는 명확한 역할을 정한다. Master는 통신을 시작하고 명령을 내리는 주체이고, Slave는 말하는 권한이 없고 Master의 명령에 응답만 한다. Master는 반드시 1개다.

문제 2: 누구에게 말하는가?

Master가 말하는 건 알겠는데, B, C, D 중 누구에게 말하는 건지 Slave들이 알 수 없다.

해결: CS(Chip Select) 선 추가

각 Slave에 독립적으로 CS 선을 연결한다. 평상시에는 CS가 High 상태이고, 특정 Slave와 통신하고 싶으면 해당 CS 선만 Low로 떨어뜨려서 그 칩을 활성화한다. CS가 Low인 Slave만 Master의 데이터를 수신한다.

1:1 통신일 때는 상대가 하나뿐이므로 CS를 아예 Low로 묶어버려서 Slave가 항상 듣는 상태로 만들 수 있다. 이전 글("FND 제어")에서 FND 모듈에 CS 핀이 없었던 이유가 이것이다.

diagram_02_spi_master_slave

SPI의 기본 뼈대 — 4개의 선

선 이름	의미	역할
MOSI	Master Out Slave In	Master가 말하는 전용선
MISO	Master In Slave Out	Slave가 말하는 전용선 (Master가 듣는 선)
SCLK	Serial Clock	클럭 신호
SS (CS)	Slave Select (Chip Select)	통신 대상 선택

Slave 입장에서는 MOSI를 SI(Slave In), MISO를 SO(Slave Out)라고 표기하기도 한다. 이전 글들에서 접했던 SPI 관련 핀 이름들이 이 구조에서 나온 것이다.

이전 글("데이터시트 보는 꼼수")에서 STB/CLK/DIO로 설명했던 것, 이전 글("멀티미터기 사용방법")에서 클럭+데이터 파형을 오실로스코프로 관찰했던 것, 이전 글("FND 제어")에서 SCLK/RCLK/DIO로 GPIO를 직접 제어했던 것이 모두 이 SPI 통신의 구현이었다.

STM32 SPI 설정 옵션

STM32는 SPI 통신을 하드웨어적으로 지원한다. STM32CubeIDE에서 SPI를 활성화하면 다양한 옵션을 설정할 수 있다.

STM32CubeIDE SPI 설정 화면

Mode

Full Duplex: 전이중. 데이터 선 2개 + 클럭 = 3선
Half Duplex: 반이중. 데이터 선 1개 + 클럭 = 2선
Receive Only: 수신 전용. 데이터 선 1개 + 클럭 = 2선
Transmit Only: 송신 전용. 데이터 선 1개 + 클럭 = 2선

칩의 용도에 따라 선택한다. 예를 들어 온도 센서처럼 데이터를 보내기만 하는 장치는 Transmit Only로 충분하다.

Master / Slave

칩의 역할에 따라 선택한다. 메인 MCU는 보통 Master, 주변 모듈은 Slave로 설정한다.

HW NSS Signal

CS를 하드웨어적으로 자동 제어할지 여부다. HW로 설정하면 SPI 통신 시 자동으로 CS를 Low로 떨어뜨리지만, 통신 대상이 1개일 때만 사용 가능하다. 여러 Slave를 제어해야 하면 GPIO로 직접 CS를 제어해야 하므로 보통 Disable(SW 방식)로 설정한다.

Data Size

한 번에 전송하는 데이터 단위. 8비트 또는 16비트를 선택할 수 있다. 데이터시트에 따라 결정한다.

First Bit

데이터를 보낼 때 MSB(최상위 비트)부터 보낼지 LSB(최하위 비트)부터 보낼지 결정한다. 예를 들어 52(= 0011 0100)를 보낼 때, MSB First면 왼쪽부터, LSB First면 오른쪽부터 보낸다. 데이터시트에 따라 결정한다.

Prescaler (for Baud Rate)

MCU의 기본 클럭을 얼마나 나눌지 결정하여 SPI 통신 속도를 설정한다.

Clock Polarity (CPOL)

클럭이 평상시에 Low인지 High인지 결정한다. 데이터시트를 보고 결정한다.

Clock Phase (CPHA)

클럭의 1st Edge에서 데이터를 읽을지, 2nd Edge에서 읽을지 결정한다. 한 클럭 내에서 데이터가 0인지 1인지 판단하는 시점을 정하는 설정이다. 데이터시트를 보고 결정한다.

이 옵션들은 모두 데이터시트를 보고 결정해야 한다. SPI 통신이 지원된다고 해서 모든 칩이 호환되는 것이 아니며, 이 옵션들이 정확히 맞아야 통신이 가능하다.

SPI vs I2C

비교 항목	SPI	I2C
선 개수	4개 (MOSI, MISO, SCLK, CS)	2개 (SDA, SCL)
통신 방식	전이중 가능	반이중만
칩 선택 방식	CS 선 (HW적, 각 Slave마다 별도 선)	주소 (SW적, 데이터에 주소 포함)
속도	이론상 제한 없음	프로토콜에 의한 속도 제한
선 수 증가	Slave 수만큼 CS 선 추가	Slave 수 늘어도 선 2개 유지

SPI는 빠르고 전이중이 가능하지만 선이 많고, I2C는 선이 적지만 느리고 반이중이다. 용도에 따라 선택한다.

[오제이 튜브 임베디드 강의] 19. FND 제어

onebrotravel — Sun, 26 Apr 2026 19:00:34 +0900

정보 없는 모듈을 만났을 때

실무에서는 데이터시트나 정보가 부족한 상태에서 모듈을 제어해야 하는 상황이 자주 발생한다. 이번 강의의 핵심은 FND 모듈에 대한 정보가 거의 없을 때, 어떻게 접근하고 문제를 해결하는지에 대한 실무 노하우다.

실무 접근 순서

하드웨어 담당자에게 자료 요청 — 가장 편한 방법이지만, 자료를 얻기 어려운 경우도 많다
모듈 뒷면의 메인 칩셋 이름 확인 — 모든 분석의 시작점. 육안으로 안 보이면 핸드폰 카메라로 촬영하여 확대
메인 칩의 데이터시트 검색 — 칩 이름(예: TM74HC595)으로 데이터시트를 찾는다
샘플 코드를 구해서 일단 동작시키고, 코드를 분석하며 추리 — 이것이 실무에서 가장 빠르고 효율적인 방법

이전 글("데이터시트 보는 꼼수")에서 다룬 "데이터시트만이 답이 아니다 — 샘플 코드를 구해서 역추적하는 방법이 가장 빠르다"는 원칙이 여기서 그대로 적용된다.

FND 모듈 분석

FND란

FND는 7세그먼트의 다른 이름이다. 7개의 LED와 소수점(dp)까지 총 8개의 LED로 구성되어 있으며, 원하는 LED에 전압을 가하면 해당 부분에 불이 들어와 숫자를 표현한다.

7세그먼트 구조

모듈 구조

FND 모듈은 메인 칩(드라이버 IC) + 7세그먼트를 합친 형태다. 모듈 뒷면을 보면 드라이버 칩이 있다.

FND 모듈 뒷면 — 드라이버 칩

드라이버 IC가 필요한 이유

diagram_01_fnd_driver

이전 글("데이터시트 보는 꼼수")에서 다뤘듯이, 드라이버 IC 없이 7세그먼트를 직접 제어하려면 LED 하나당 GPIO 핀 하나가 필요하여 핀 수가 너무 많아진다. 드라이버 IC를 사용하면 STM32와 드라이버 IC 사이에 3개의 통신선만으로 FND 전체를 제어할 수 있다.

구조를 정리하면: STM32 ↔ (SPI 통신) ↔ 드라이버 IC(TM74HC595) ↔ FND LED들

SPI 통신과 핀 연결

3-wire SPI

데이터시트를 보면 이 모듈은 SPI 통신을 사용한다. 일반적인 SPI는 CLK, DIO, CS 세 가지 선이 필요하지만, 이 모듈은 CS 핀이 없다. CS는 여러 장치 중 하나를 선택하는 역할인데, 장치가 하나뿐이면 생략할 수 있다. 대신 RCLK이라는 래치 핀이 존재한다.

FND 모듈의 핀 구성:

FND 모듈 핀	연결	역할
VCC	3.3V	전원
GND	GND	접지
SCLK	PB15	클럭 신호
RCLK	PB13	래치(데이터 확정)
DIO	PB14	데이터 입출력

FND 모듈과 STM 보드 연결

핀 연결

암-암 점퍼선으로 FND 모듈의 핀을 STM 보드의 해당 GPIO 핀에 직접 연결한다. VCC와 GND는 빵판의 전원 레일을 통해 연결한다.

GPIO 설정 및 코드 구현

GPIO 설정

STM32는 SPI 통신을 하드웨어적으로 지원하지만, 이번에는 GPIO를 직접 제어하여 클럭과 데이터 신호를 소프트웨어적으로 만들어내는 방식을 사용한다. PB13, PB14, PB15를 모두 GPIO Output으로 설정한다.

PB13/14/15 GPIO Output 설정

send 함수 — 8비트 데이터 전송

핵심 함수인 send는 8비트 데이터를 받아 비트 단위로 쪼개어 DIO 핀으로 보낸다.

void send(uint8_t X) {
    for (int i = 8; i >= 1; i--) {
        if (X & 0x80) {
            HAL_GPIO_WritePin(PB14_FND_DIO_GPIO_Port, PB14_FND_DIO_Pin, HIGH);
        } else {
            HAL_GPIO_WritePin(PB14_FND_DIO_GPIO_Port, PB14_FND_DIO_Pin, LOW);
        }
        X <<= 1;

        HAL_GPIO_WritePin(PB15_FND_SCLK_GPIO_Port, PB15_FND_SCLK_Pin, LOW);
        HAL_GPIO_WritePin(PB15_FND_SCLK_GPIO_Port, PB15_FND_SCLK_Pin, HIGH);
    }
}

동작 과정을 풀어보면:

X & 0x80 — 데이터의 최상위 비트(MSB)가 1인지 확인. 0x80은 이진수로 10000000이므로 MSB만 검사한다
MSB가 1이면 DIO를 HIGH로, 0이면 LOW로 설정
X <<= 1 — 데이터를 왼쪽으로 1비트 시프트하여 다음 비트를 MSB 위치로 올린다
SCLK을 LOW → HIGH로 전환하여 클럭 한 주기를 생성. 이 상승 엣지에서 DIO의 값이 전송된다
이 과정을 8번 반복하면 8비트 데이터 전송 완료

예를 들어 0b10100011을 보내면: H, L, H, L, L, L, H, H 순서로 DIO가 설정된다.

for문이 끝나면 SCLK이 HIGH 상태로 남아 있으므로, 데이터를 안 보낼 때는 기본적으로 HIGH 상태다.

send_port 함수 — 데이터 + 자릿수 전송

void send_port(uint8_t X, uint8_t port) {
    send(X);      // 세그먼트 데이터 전송
    send(port);   // 어느 자릿수에 표시할지 전송
    HAL_GPIO_WritePin(PB13_FND_RCLK_GPIO_Port, PB13_FND_RCLK_Pin, HIGH);
    HAL_GPIO_WritePin(PB13_FND_RCLK_GPIO_Port, PB13_FND_RCLK_Pin, LOW);
}

send로 세그먼트 데이터와 자릿수(port)를 연속으로 보낸 뒤, RCLK을 HIGH → LOW로 전환하여 데이터를 확정(래치)한다.

숫자-세그먼트 매핑 테이블

각 숫자/문자를 7세그먼트로 표현하기 위한 데이터가 배열로 정의되어 있다.

uint8_t _LED_0F[29];

void init_fnd() {
    _LED_0F[0] = 0xC0;  // 0
    _LED_0F[1] = 0xF9;  // 1
    _LED_0F[2] = 0xA4;  // 2
    // ...
    _LED_0F[9] = 0x90;  // 9
    _LED_0F[10] = 0x88; // A
    // ...
}

예를 들어 0xC0은 이진수로 11000000이고, 각 비트가 7세그먼트의 a~g, dp에 대응한다. 0인 비트의 LED가 켜지므로 하위 6비트가 0인 `0xC0`은 a~f 세그먼트가 켜져 숫자 '0'이 표시된다.

digit4_show 함수 — 4자리 숫자 표시

void digit4_show(int n, int replay, uint8_t showZero) {
    int n1 = (int)  n % 10;
    int n2 = (int) ((n % 100) - n1) / 10;
    int n3 = (int) ((n % 1000) - n2 - n1) / 100;
    int n4 = (int) ((n % 10000) - n3 - n2 - n1) / 1000;

    for (int i = 0; i <= replay; i++) {
        send_port(_LED_0F[n1], 0b0001);  // 1의 자리
        if (showZero | n > 9)   send_port(_LED_0F[n2], 0b0010);  // 10의 자리
        if (showZero | n > 99)  send_port(_LED_0F[n3], 0b0100);  // 100의 자리
        if (showZero | n > 999) send_port(_LED_0F[n4], 0b1000);  // 1000의 자리
    }
}

숫자 n을 각 자릿수로 분리하고, port 비트(0b0001, 0b0010, 0b0100, 0b1000)로 어느 자릿수에 표시할지 선택한다.

동작 확인

main 함수에서 실행

// main.c
#include "fnd_controller.h"

// main 함수 내
init_fnd();

while (1) {
    for (int i = 0; i < 9999; i++){
        digit4_replay(i, 50);
    }
}

코드를 실행하면 FND에 1부터 9999까지 숫자가 빠르게 증가하며 표시된다. GPIO를 직접 제어하는 방식임에도 성공적으로 FND를 구동한 것이다.

FND에 숫자가 표시되는 모습

추가 테스트

digit4_replay(count, 50)의 count를 9999까지 올리면 4자리 숫자가 모두 표시된다. send_port(0x88, 0b0001)을 보내면 'A'가 표시되는 것도 확인할 수 있다.

FND에 'A' 표시

정리

이번 강의의 핵심은 FND 제어 자체보다 실무에서 정보가 부족할 때의 접근법이다.

모듈 뒷면에서 칩 이름 확인
데이터시트에서 통신 방식 파악 (이 경우 SPI)
샘플 코드를 확보하여 일단 동작시키고
동작하는 코드를 분석하며 원리를 추리

다음 시간에는 이 코드가 어떻게 동작하는지 심층 분석하고, GPIO 방식 대신 STM32의 하드웨어 SPI 통신 기능을 활용하는 방법도 다룰 예정이다.

[오제이 튜브 임베디드 강의] 18. 내 힘으로 스위치회로 만들기

onebrotravel — Sun, 26 Apr 2026 18:49:34 +0900

스위치 회로 구성

이전 글("내 힘으로 LED 회로 만들어서 제어하기")에서는 GPIO 없이 스위치를 물리적으로 눌러 LED를 켜고 껐다. 이번에는 한 단계 더 나아가서, GPIO Input으로 스위치 상태를 코드에서 읽고, 코드로 LED를 제어하는 회로를 구성한다.

회로도는 다음과 같다: 3.3V → 4.7kΩ 풀업 저항 → PB0(GPIO Input) → 스위치 → GND

스위치 회로도

풀업 저항의 역할

PB0 핀과 3.3V 사이에 4.7kΩ 저항이 연결되어 있다. 이 저항은 스위치가 눌리지 않았을 때 PB0 핀을 확실히 High(3.3V) 상태로 유지하는 역할을 한다. 풀업 저항이 없으면 스위치가 열린 상태에서 PB0 핀이 아무 곳에도 연결되지 않아 전압이 불안정해진다(플로팅 상태).

빵판 배선

빨간 수-수 점퍼선으로 + 레일 → 빵판 특정 행(예: a50)에 전원 연결
4.7kΩ 저항(노랑-보라-빨강)을 같은 행(예: b50)과 다른 행(예: b45)에 연결
흰색 수-암 점퍼선으로 STM 보드의 PB0 → 저항 끝과 같은 행(예: a45)에 연결
노란 수-수 점퍼선으로 같은 행(예: c45) → 스위치의 한쪽 핀(예: d32)에 연결
파란 수-수 점퍼선으로 스위치의 다른 쪽 핀(예: d30) → - 레일(GND)에 연결

이전 글에서 다룬 것처럼, 스위치의 1-3/2-4 핀이 내부적으로 연결되어 있으므로, 빵판의 가운데 홈을 사이에 두고 꽂아야 한다.

스위치 회로 완성된 빵판

스위치 동작 원리

스위치를 누르지 않았을 때: 스위치가 열려 있으므로 GND로 가는 경로가 끊겨 있다. PB0 핀은 풀업 저항을 통해 3.3V에 연결되어 있으므로 High(1)로 읽힌다.

스위치를 눌렀을 때: 스위치가 닫혀 PB0 핀이 GND에 직접 연결된다. 전류가 3.3V → 저항 → 스위치 → GND로 흐르면서 PB0 핀의 전압이 GND 쪽으로 끌려 내려간다. PB0은 Low(0)로 읽힌다.

정리하면:

스위치 상태	PB0 전압	GPIO ReadPin 값
누르지 않음	3.3V (High)	1
누름	0V (Low)	0

GPIO Input 설정 및 코드

IDE 설정

STM32CubeIDE에서 PB0 핀을 GPIO_Input으로 설정한다. 풀업/풀다운 설정은 Pull-up으로 한다. 유저 라벨에는 회로도에 표시된 핀 이름을 입력한다.

PB0 GPIO Input 설정 화면

코드 작성

// 전역 변수 선언
uint8_t button_state = 0;

// while(1) 루프 안
while (1) {
    button_state = HAL_GPIO_ReadPin(PB0_SW_START_GPIO_Port, PB0_SW_START_Pin);
    HAL_Delay(100);
}

디버깅으로 확인

HAL_Delay에 브레이크포인트를 걸고 디버깅한다. 스위치를 누르지 않은 상태에서 다음 줄로 넘기면 button_state = 1(High), 스위치를 누른 상태에서 넘기면 button_state = 0(Low)이 되는 것을 확인할 수 있다.

디버깅 화면 — button_state 값 변화

스위치 + LED 통합 제어

이제 스위치 입력에 따라 LED를 제어한다. 이전 글에서 구성한 LED 회로(3.3V → LED → 저항 → PB6)를 그대로 두고, 스위치 회로를 추가한다.

LED 회로 추가 배선

빨간 수-수 점퍼선으로 + 레일 → 빵판 특정 행(예: f60)에 전원 연결
LED의 + 다리(긴 쪽)를 같은 행(예: g60)에, - 다리(짧은 쪽)를 다른 행(예: g57)에 연결
220Ω 저항을 LED - 다리와 같은 행(예: h57)과 다른 행(예: h53)에 연결
주황 수-암 점퍼선으로 저항 끝(예: i53) → STM 보드의 PB6에 연결

스위치 + LED 통합 회로

코드 작성

while (1) {
    button_state = HAL_GPIO_ReadPin(PB0_SW_START_GPIO_Port, PB0_SW_START_Pin);

    if (!button_state) {  // 버튼 눌림 (Low = 0)
        HAL_GPIO_WritePin(PB6_LED1_GPIO_Port, PB6_LED1_Pin, 0);  // Low → LED 켜짐
    } else {              // 버튼 안 눌림 (High = 1)
        HAL_GPIO_WritePin(PB6_LED1_GPIO_Port, PB6_LED1_Pin, 1);  // High → LED 꺼짐
    }

    HAL_Delay(100);
}

이전 글에서 배운 것처럼, GPIO가 Low일 때 3.3V와 전압차가 생겨 LED가 켜지고, High일 때 전압차가 없어 LED가 꺼진다. !button_state로 조건을 쓰는 이유는 버튼이 눌리면 ReadPin이 0을 반환하기 때문이다.

동작 확인

코드를 실행하면 버튼을 누르면 LED가 켜지고, 떼면 꺼진다. 이전 글에서는 물리적 스위치로 직접 전류를 차단/연결했지만, 이번에는 GPIO Input으로 스위치 상태를 읽고 GPIO Output으로 LED를 제어하는 소프트웨어 방식이다.

버튼 눌러 LED 켜진 모습

[오제이 튜브 임베디드 강의] 17. 내 힘으로 LED회로 만들어서 제어하기

onebrotravel — Sun, 26 Apr 2026 18:44:33 +0900

LED 회로 기초

이번 강의에서는 직접 회로를 구성하여 LED를 제어한다. 남이 만든 회로가 아니라, 원리를 이해하고 직접 설계하여 구현하는 과정이다.

기본 LED 회로는 3.3V 전원 → LED → 저항 → GND로 구성된다. 전류는 항상 높은 전압에서 낮은 전압으로 흐르므로, 3.3V에서 GND 방향으로 전류가 흘러 LED가 켜진다. 저항은 LED에 흐르는 전류량을 조절하여 과전류를 방지하는 역할을 한다.

LED 극성

LED는 다이오드의 일종으로 전류가 한 방향으로만 흐른다. 이전 글("회로도 딱 필요한 만큼만 배우자")에서 다이오드의 기호와 특성을 다뤘는데, 실물에서는 다리가 긴 쪽이 +(애노드), 짧은 쪽이 -(캐소드)다. 극성을 반대로 연결하면 전류가 흐르지 않아 LED가 켜지지 않는다.

LED 실물 — 다리 길이로 극성 구분

저항 읽는 법

저항의 띠 색깔로 저항값을 읽을 수 있다. 일반적으로 4개의 띠가 있으며, 첫 번째와 두 번째 띠는 숫자, 세 번째 띠는 승수, 네 번째 띠는 오차율이다.

예: 빨강-빨강-갈색-금색 → 2, 2, ×10, ±5% → 220Ω ±5% (209~231Ω)

실무에서는 띠 색깔을 외우는 것보다 멀티미터로 직접 저항값을 측정하는 것이 정확하고 편리하다.

저항 띠 색깔과 멀티미터 측정 비교

실습 1: LED 직접 켜기 (GPIO 없이)

GPIO 제어 없이, 3.3V 전원과 GND만으로 LED를 켜본다.

빵판 배선

STM 보드의 3.3V에 빨간 점퍼선, GND에 검정 점퍼선을 연결하여 빵판의 +/- 레일에 공급
수-수 점퍼선으로 + 레일 → 빵판 특정 행(예: a40)에 전원 연결
LED의 + 다리(긴 쪽)를 같은 행(예: e40)에, - 다리(짧은 쪽)를 다른 행(예: e37)에 연결
저항(220Ω)의 한쪽을 LED - 다리와 같은 행(예: c37)에, 다른 쪽을 다른 행(예: c33)에 연결
수-수 점퍼선으로 저항 끝(예: a33) → - 레일(GND)에 연결

전원을 공급하면 LED에 불이 들어온다. 3.3V → LED → 저항 → GND로 전류가 흐르는 것이다.

LED가 켜진 모습

실습 2: GPIO로 LED 제어

원리 — GPIO High/Low와 LED 동작

이제 GND에 연결했던 부분을 GPIO 핀으로 대체한다. 회로 구성은 3.3V → LED → 저항 → GPIO가 된다.

직관과 반대로 동작하는 부분이 있다.

GPIO Low (0V): 3.3V와 0V 사이에 전압차가 있으므로 전류가 흐른다 → LED 켜짐
GPIO High (3.3V): 양쪽 모두 3.3V로 전압차가 없으므로 전류가 흐르지 않는다 → LED 꺼짐

핀 확인

개발 보드 회로도에서 PB6_LED1이 보드의 7번 핀에 연결되어 있음을 확인한다.

빵판 배선 변경

실습 1에서 GND로 갔던 점퍼선을 제거하고, 대신 STM 보드의 PB6 핀에서 빵판의 같은 행(예: a33)으로 점퍼선을 연결한다.

GPIO로 변경된 최종 회로

GPIO 설정 및 코드

STM32CubeIDE에서 PB6을 GPIO_Output으로 설정하고, 초기 출력 레벨을 High로 설정하여 시작 시 LED가 꺼지도록 한다.

while (1) {
    HAL_GPIO_WritePin(PB6_LED1_GPIO_Port, PB6_LED1_Pin, 0);  // Low → LED 켜짐
    HAL_Delay(1000);
    HAL_GPIO_WritePin(PB6_LED1_GPIO_Port, PB6_LED1_Pin, 1);  // High → LED 꺼짐
    HAL_Delay(1000);
}

코드를 실행하면 LED가 1초 간격으로 깜빡인다. 이전 글들에서 코드로만 GPIO를 제어했던 것이, 직접 만든 회로에서 실제로 동작하는 것을 확인하는 순간이다.

LED가 깜빡이는 모습

스위치 이해

내부 구조

스위치는 4개의 핀이 있으며, 내부적으로 1-3번 핀끼리, 2-4번 핀끼리 항상 연결되어 있다. 1-3 쌍과 2-4 쌍 사이는 평소에 끊어져 있다가, 버튼을 누르면 연결된다.

스위치 내부 구조

멀티미터로 핀 확인

스위치의 어느 핀이 1-3이고 어느 핀이 2-4인지 멀티미터 쇼트 테스트로 직접 확인한다. 두 핀에 프로브를 대고 삐- 소리가 나면 같은 쌍(1-3 또는 2-4)이다. 버튼을 누른 상태에서 다른 쌍과도 삐- 소리가 나는지 확인하면 스위치 동작을 검증할 수 있다.

스위치를 빵판에 꽂을 때는, 1-3 쌍과 2-4 쌍이 가운데 홈을 사이에 두고 양쪽에 위치하도록 꽂는다. 같은 쪽(a-e)에 꽂으면 이미 연결된 핀끼리 같은 행에 들어가므로 의미가 없다.

실습 3: 스위치로 LED 제어

회로 구성

3.3V → LED → 저항 → 스위치 → GND 순서로 연결한다.

스위치의 한쪽 쌍(예: 1-3)을 저항과 같은 행에 연결
스위치의 다른 쪽 쌍(예: 2-4)을 GND에 연결

스위치가 추가된 최종 회로

동작 확인

스위치를 누르면 LED가 켜지고, 떼면 꺼진다. 버튼을 누르면 스위치 내부에서 1-3과 2-4 사이가 연결되어 3.3V → LED → 저항 → 스위치 → GND 경로로 전류가 흐르고, 버튼을 떼면 경로가 끊어져 전류가 차단된다.

스위치 눌러 LED 켜진 모습

[오제이 튜브 임베디드 강의] 16. printf도 쉽지 않다구

onebrotravel — Sun, 26 Apr 2026 18:30:20 +0900

printf()를 임베디드에서 쓰려면

printf()는 표준 출력(stdout)으로 데이터를 보내는 함수다. PC에서는 콘솔 창이 표준 출력이지만, 임베디드 환경에서는 콘솔 창이 없다. 대신 UART 통신을 통해 PC로 데이터를 보내고, PC의 터미널 프로그램에서 출력을 확인하는 방식으로 printf()를 사용할 수 있다.

표준 출력은 사용자가 원하는 대로 변경할 수 있다. printf() 내부에서 호출되는 _write 함수를 재정의하면, printf()의 출력이 UART를 통해 전송되도록 만들 수 있다. 이번 글에서는 이 과정을 처음부터 끝까지 다룬다.

하드웨어 준비

FTDI 모듈

FTDI 모듈은 UART 신호를 USB 형태로 변환하는 장치다. 이 모듈의 핵심은 FTDI 칩으로, UART 데이터를 USB 프로토콜로 변환하여 PC가 인식할 수 있게 해준다.

USB 케이블로 PC에 연결하면 빨간 불이 들어오며, 장치 관리자에서 USB 직렬 포트 (COMx) 형태로 인식된다. COM 포트 번호는 PC마다 다를 수 있으므로 확인이 필요하다.

FTDI 모듈 실물

FTDI 모듈에서 중요한 핀은 세 개다.

FTDI 모듈 핀	역할
GND	송수신 신호의 기준점. 반드시 연결
RX	모듈이 데이터를 받는 선
TX	모듈이 데이터를 보내는 선

VCC는 USB를 통해 전원이 공급되므로 반드시 연결할 필요는 없다. 모듈의 스위치를 통해 5V/3.3V를 선택할 수 있는데, 우리 보드는 3.3V로 동작하므로 스위치를 3.3V로 설정해야 한다.

TX/RX 교차 연결

UART 통신에서 핵심 규칙: 보드의 TX는 모듈의 RX로, 보드의 RX는 모듈의 TX로 교차 연결해야 한다. 보드가 보내는 데이터(TX)를 모듈이 받아야(RX) 하고, 모듈이 보내는 데이터(TX)를 보드가 받아야(RX) 하기 때문이다.

FTDI 모듈	방향	STM 보드
RX (수신)	←	PA9 (TX, 송신)
TX (송신)	→	PA10 (RX, 수신)
GND	—	GND

펌웨어 설정

STM32CubeIDE에서 USART1을 비동기(Asynchronous) 방식으로 선택하면, PA9(TX)와 PA10(RX) 핀이 자동으로 할당된다. 데이터시트를 일일이 찾을 필요 없이 툴이 핀 할당을 해주는 것이다.

STM32CubeIDE USART1 Async 설정

UART 설정값은 다음과 같다. 이 값들은 송신 측과 수신 측이 동일하게 맞춰야 통신이 가능하다.

Baud Rate: 115,200 bps
Word Length: 8 bit
Parity: None
Stop Bits: 1
Data Direction: Transmit and Receive
Hardware Flow Control: None

각 설정의 의미는 아래 "UART 통신 원리" 섹션에서 자세히 설명한다.

빵판 배선

보드와 FTDI 모듈을 빵판을 이용해 연결한다.

STM 보드 → 빵판:

GND → 빵판의 - 라인 (검정색 선)
PA9(TX) → 빵판 특정 행 (주황색 선)
PA10(RX) → 빵판 다른 행 (흰색 선)

FTDI 모듈 → 빵판 (같은 행에 연결):

GND → 빵판의 - 라인, 보드 GND와 같은 라인 (검정색 선)
RX → PA9(TX)와 같은 행 (주황색 선)
TX → PA10(RX)과 같은 행 (흰색 선)

빵판의 같은 행은 내부적으로 연결되어 있으므로, 같은 행에 꽂으면 전기적으로 연결된다. 이전 글("큰 그림에 저장하기")에서 빵판의 내부 연결 구조를 다뤘다.

STM 보드와 FTDI 모듈 빵판 연결 최종 모습

UART 통신 원리

비동기 vs 동기

이전 글("데이터시트 보는 꼼수")에서 다룬 SPI 통신은 동기(Synchronous) 방식이다. 클럭 선이 있어서 클럭 신호를 기준으로 데이터를 해석한다. 클럭의 패턴이 약간 바뀌어도 기준점이 있으므로 통신이 가능하다.

반면 UART는 비동기(Asynchronous) 방식이다. 클럭 선이 없고, 대신 송수신 측이 시간을 동일하게 쪼개는 약속을 해서 데이터를 주고받는다. 이 약속이 바로 Baud Rate와 Word Length 등의 설정이다.

참고로 C언어에서 배우는 동기/비동기와 혼동하기 쉽다. 소프트웨어에서의 동기/비동기는 "함수 호출 후 결과를 기다리느냐(동기) 기다리지 않느냐(비동기)", 즉 실행 흐름을 맞추느냐의 문제다. 통신에서의 동기/비동기는 "송신 측과 수신 측이 공유하는 클럭 선이 있느냐(동기) 없느냐(비동기)", 즉 클럭(시간 기준)을 맞추느냐의 문제다. 둘 다 "synchronize(맞추다)"라는 어원에서 나왔지만, 맞추는 대상이 다르다.

Baud Rate (보드 레이트)

1초를 얼마나 잘게 쪼개서 비트를 전송할 것인지 결정하는 속도 단위다. 115,200 bps는 1초를 115,200개로 쪼개어 비트를 전송한다는 뜻이다. 9,600 bps는 디버깅에 사용하기엔 너무 느려 병목이 발생할 수 있으므로, 최소 115,200 bps를 사용하는 것이 좋다.

Word Length (워드 랭스)

한 번에 몇 비트 단위로 데이터를 보낼지에 대한 약속이다. 8비트로 설정하면 Start 비트 이후 8비트를 전송하고 Stop 비트가 오는 형식이다. 받는 쪽에서 다른 비트 수로 설정하면 데이터가 깨진다.

Parity (패리티)

시리얼 통신은 노이즈의 영향을 받기 쉬우므로, 데이터 오류를 검출하기 위한 비트다. 현업에서는 None으로 설정하는 경우가 많다.

Stop Bits (스톱 비트)

데이터 전송이 끝났음을 알리는 비트다. 1비트로 설정하면 "끝났다"를 1비트로 보낸다.

기본 UART 송신 테스트

Xshell 설정

시리얼 통신 프로그램(Xshell 등)을 설치하고, 새 세션을 만든다. 프로토콜을 SERIAL로 변경하고, 장치 관리자에서 확인한 COM 포트 번호와 펌웨어에서 설정한 Baud Rate(115200), 데이터 비트(8), 패리티(None), 스톱 비트(1)를 동일하게 설정한다.

Xshell 시리얼 설정 화면

HAL_UART_Transmit으로 Hello World

// main.c — while(1) 루프 안
uint8_t msg[] = "Hello World\r\n";
HAL_UART_Transmit(&huart1, msg, sizeof(msg) - 1, HAL_MAX_DELAY);
HAL_Delay(1000);

이 코드를 빌드하고 보드에 업로드하면, Xshell 터미널에 Hello World가 1초마다 출력되는 것을 확인할 수 있다.

전체 데이터 흐름 정리

지금까지의 구성을 정리하면:

STM 보드의 PA9(TX)에서 "Hello World" 데이터를 UART로 전송
FTDI 모듈이 UART 신호를 받아 USB 형태로 변환
PC는 USB 드라이버를 통해 이 신호를 COM 포트 데이터로 해석
Xshell이 COM 포트를 열어 수신된 데이터를 화면에 출력

FTDI 모듈의 핵심 역할은 UART ↔ USB 변환이고, PC 측의 드라이버가 USB 신호를 해석할 수 있게 해준다. 리눅스 환경에서 FTDI 드라이버를 포팅하여 사용하는 경우도 많으므로 이 키워드를 기억해두면 좋다.

printf() 구현

_write 함수 재정의

printf()를 호출하면 내부적으로 _write 함수가 최종적으로 호출된다. 이 함수를 HAL_UART_Transmit을 호출하도록 재정의하면, printf()의 출력이 UART를 통해 전송된다.

// main.c 또는 별도 파일
int _write(int file, char *ptr, int len)
{
    HAL_UART_Transmit(&huart1, (uint8_t *)ptr, len, HAL_MAX_DELAY);
    return len;
}

이제 printf("Hello %d\r\n", 42); 같은 코드를 쓰면 Xshell에 "Hello 42"가 출력된다.

실수 출력 설정

printf()로 실수(%f)를 출력하려면 컴파일러 옵션을 추가해야 한다. STM32CubeIDE에서 C/C++ Build → Settings → MCU GCC Linker → Miscellaneous로 이동하여 linker flags에 다음을 추가한다.

--specs=nano.specs -u _printf_float

이 설정을 적용하면 printf("temp: %.2f\r\n", 36.5); 같은 실수 출력이 가능해진다.

STM32CubeIDE linker flags 설정

Live Expression — 실시간 변수 모니터링

STM32CubeIDE에는 Live Expression이라는 실시간 변수 모니터링 기능이 있다. 디버깅 중에 변수 값이 실시간으로 변하는 것을 IDE 화면에서 바로 확인할 수 있다.

단, Live Expression으로 모니터링하려면 해당 변수를 전역 변수로 선언해야 한다. 지역 변수는 스택에 할당되어 함수가 끝나면 사라지므로 실시간 모니터링에 제약이 있다. 전역 변수는 컴파일 시점에 메모리 주소가 확정되므로 안정적으로 모니터링할 수 있다.

Live Expression 실시간 모니터링