체셔's blog

주소는 가짜입니다.
매핑과 정책이 경계를 만듭니다.
가상화는 여기서 시작됩니다.

1. “Virtual Memory가 가상화 맞아요?”

이 시리즈를 시작하며 저는 “VM → 컨테이너 → Docker → Kubernetes” 흐름을 잡았습니다. 그런데 첫 번째 주인공으로 Virtual Memory를 꺼내면 보통 이런 질문이 돌아옵니다.

• “메모리 관리는 그냥 OS의 기본 기능 아닌가요?”
• “본격적인 가상화 이야기로 넘어가기 전에 왜 갑자기 메모리 쪽으로 새는 거죠?”

저 역시 처음에는 Virtual Memory를 ‘메모리 부족을 해결하는 기술’ 정도로만 생각했습니다. 하지만 관점을 [경계 + 매핑 + 정책]이라는 프레임으로 옮겨 보면, Virtual Memory는 오히려 가상화의 원형에 가깝다는 사실을 확인하게 됩니다.

결론은 단순합니다.

• 경계: 프로세스마다 나만의 독립된 주소 공간이 존재하는 것처럼 보이게 합니다.
• 매핑: 가상 주소를 실제 물리 메모리 위치에 연결하는 번역층을 둡니다.
• 정책: 서로의 영역을 침범하지 못하도록 보호 규칙을 강제합니다.

이 구조는 이후에 다룰 VM이나 Kubernetes에서도 이름만 바뀐 채 반복됩니다. 차이는 “무엇을 경계로 잡느냐”에 가깝습니다.

2. Virtual Memory가 만든 환상: “각 프로세스는 자기 주소 공간을 가진다”

Virtual Memory가 만든 첫 번째 효과는 단순하면서도 강합니다.

• 프로세스 A는 자신이 0번지부터 끝번지까지의 메모리를 ‘가진 것처럼’ 동작합니다.
• 프로세스 B도 똑같이 0번지를 사용하지만, A의 0번지와는 다른 세계입니다.
• 서로의 메모리가 어디에 있는지 알 수도, 볼 수도 없습니다.

여기서 핵심은 주소(Address)의 의미가 바뀐다는 점입니다. 우리는 흔히 주소를 ‘실제 메모리의 물리적 위치’라고 생각합니다. 하지만 Virtual Memory에서 주소는 그렇게 취급되지 않습니다.

• 주소는 ‘실제 위치’가 아니라, 자원을 식별하기 위한 이름에 가깝습니다.
• 실제 위치는 운영체제가 관리하고, 프로세스에는 이름(주소)만 제공합니다.

이 순간부터 주소 공간(Address Space)은 물리적 현실이 아니라 운영체제가 설계한 인터페이스가 됩니다. 저는 이 지점을 “첫 번째 가상화 레이어라고 봅니다.

3. 그럼 질문이 바뀝니다: “이름이 인터페이스라면, 실체는 누가 관리하죠?”

주소가 인터페이스라면 저는 이런 생각이 들었습니다.

• “그럼 실제 물리 메모리는 누가, 어떻게 나눠주지?”
• “프로세스들이 각자 주소를 쓰는데 충돌이 안 나는 이유가 뭐지?”

이 의문을 해소하면 Virtual Memory의 구조는 세 가지로 정리됩니다.

3-1) 경계: 주소 공간이라는 소유권 경계

운영체제는 각 프로세스가 볼 수 있는 주소의 범위를 논리적으로 확정합니다. 이 범위 밖은 프로세스 입장에서 원칙적으로 접근할 수 없는 영역입니다. 저는 이것을 격리(Isolation)의 시작이라고 봅니다.

3-2) 매핑: 가상 주소 → 물리 메모리

운영체제는 “이 주소는 실제로 여기다”를 연결하는 매핑 정보를 유지합니다. 프로세스는 주소만 사용하고, 실제 물리적 배치는 운영체제가 결정합니다. 저는 이것이 간접화(Indirection)의 핵심이라고 정리했습니다.

3-3) 정책: 보호 규칙(Permission)으로 침범을 막는다

매핑에는 위치 정보만 있는 게 아닙니다. 읽기만 가능, 쓰기 가능, 실행 가능 같은 규칙이 붙습니다. 이것은 구현 디테일을 넘어선 정책(Policy)입니다. 가상화는 환상을 보여주는 것으로 끝나지 않고, 그 환상을 유지하기 위해 정책을 강제해야 합니다.

4. Virtual Memory가 남긴 핵심: “환상은 운영 모델을 바꾼다”

여기까지 오면 질문은 이렇게 바뀝니다.

• “그래서, 주소를 가상으로 만들어서 얻는 진짜 이득이 뭔가요?”

Virtual Memory는 단순한 편의 기능을 넘어 운영 모델을 바꿨습니다.

• 프로세스는 물리 메모리의 구조를 몰라도 됩니다. (추상화)
• 운영체제는 상황에 맞춰 데이터를 배치하거나 이동시킬 수 있습니다. (유연성)
• 잘못된 접근이나 침범은 정책 위반으로 차단됩니다. (안정성)

즉, 현실 자원을 직접 다루던 방식이 [간접화 + 정책] 구조로 넘어간 것입니다. 저는 이 패턴이 뒤에서 다룰 VM / 컨테이너 / Kubernetes로 이어지는 “공통 골격”이라고 봤습니다.

5. 오늘날의 연결: 주소 공간에서 머신으로의 확장

여기까지 정리하고 나서, 저는 가상화를 보는 시각이 바뀌었습니다. 가상화는 단순한 속임수가 아니라, 경계와 매핑, 그리고 정책을 통해 자원을 운영하는 시스템 설계입니다.

그리고 그 첫 번째 성공 모델이 Virtual Memory였습니다. 그렇다면 다음 질문은 자연스럽습니다.

• “주소 공간(메모리)을 가상화할 수 있다면, CPU와 디스크를 포함한 머신 전체도 같은 방식으로 가상화할 수 있지 않을까?”

이 질문에 대한 대답이 다음 편의 주제인 Virtual Machine(VM)입니다.

이전글

다음글

멀티스레드는 더 많은 코어가 아니라
더 적은 공유 write로 빨라집니다.

멀티스레드에서 제일 흔한 착각이 있습니다.

atomic이 느린 이유 = 락(lock) 때문

 

아니요. 많은 경우 atomic이 느린 이유는 락이 아니라,
캐시 라인 소유권(ownership) 경쟁 때문에 생기는 coherency 트래픽입니다.

3편에서 본 규칙을 그대로 가져오면 됩니다.

• read는 공유(S)로 버틸 수 있지만
• write는 독점(M/E)을 요구하고
• 누가 write를 시작하면 다른 코어의 라인은 invalidate 된다

atomic은 여기서 한 단계 더 빡셉니다.
atomic은 보통 RMW(Read-Modify-Write) 이기 때문입니다.

---

1) atomic이 비싼 진짜 이유: RMW는 라인 독점을 강제한다

atomic_fetch_add 같은 연산을 생각해봅시다.

• 값을 읽고
• 수정하고
• 다시 쓴다

이 3단계를 중간에 끼어들지 못하게 보장해야 합니다.
그래서 하드웨어는 대체로 다음을 요구합니다.

해당 캐시 라인을 내가 독점(M/E)해야만 RMW를 수행할 수 있다.

 

문제는 여러 코어가 같은 atomic을 동시에 건드릴 때 터집니다.

• Core0가 라인 독점 → Core1은 invalidate
• Core1이 라인 독점 → Core0는 invalidate
• 결과: 라인이 ping-pong (False Sharing과 구조가 동일)

여기서 중요한 결론:

atomic 경쟁(contended atomic)은 연산 비용이 아니라 라인 이동 비용으로 느려진다.

 

그래서 스레드를 늘리면 오히려 느려지는 현상이 나옵니다.
CPU가 일을 더 하는 게 아니라, 서로 밀어내느라 시간을 씁니다.

---

2) Uncontended atomic vs Contended atomic (진단 기준)

atomic이 항상 나쁜 건 아닙니다. 구분이 필요합니다.

Uncontended atomic (경쟁 없음)

• 한 코어만 해당 atomic을 자주 업데이트
• 또는 업데이트 빈도가 낮아서 충돌이 거의 없음

이 경우는 대체로 괜찮습니다.

Contended atomic (경쟁 있음)

• 여러 스레드가 같은 atomic(같은 캐시 라인)을 고빈도로 RMW
• 대표: 전역 카운터, 전역 큐 인덱스, 글로벌 통계, 글로벌 work counter

이 경우는 거의 확실히 병목입니다.
락이 없어도 느립니다. (락이 아니라 coherency 경쟁이니까)

---

3) 처방의 방향은 단 하나: 공유 write-hot을 없애라

4편의 실전 처방은 여기로 수렴합니다.

1. 공유 write-hot을 스레드 로컬로 분해
2. 필요한 순간에만 합친다(reduction)
3. 합치는 지점도 가능하면 저빈도 / 배치(batch)로 만든다

즉, atomic을 잘 쓰는 법이 아니라

atomic을 ‘뜨거운 루프에서’ 치워버리는 법

이 핵심입니다.

---

4) 처방 1: per-thread counter + reduction (가장 강력하고 가장 흔함)

나쁜 예: 모든 스레드가 전역 atomic++

std::atomic<uint64_t> gCount = 0;
void Worker()
{
	for (...)
    {
    	gCount.fetch_add(1, std::memory_order_relaxed);
    }
}

이 코드는 연산이 아니라 라인 소유권 ping-pong으로 느려집니다.

좋은 예: 스레드 로컬 누적 + 마지막 합산(reduction)

std::atomic<uint64_t> gCount = 0;
void Worker()
{
	uint64_t local = 0;
    for (...)
    {
    	local++;
    }
    gCount.fetch_add(local, std::memory_order_relaxed); // 빈도 1회
}

핵심은 fetch_add 횟수를 줄이는 게 아닙니다.
라인 소유권 경쟁을 루프 밖으로 빼는 것입니다.

전역 atomic은 루프마다가 아니라 배치로 접근하라.

---

5) 처방 2: per-thread data layout (스레드별 write-hot을 구조적으로 분리)

reduction이 항상 가능한 건 아닙니다.
큐 인덱스, 작업 분배, 스레드 상태처럼 실시간으로 공유해야 하는 값이 존재합니다.

이때는 최소한 이렇게 해야 합니다.

서로 다른 스레드가 쓰는 데이터가 같은 캐시 라인에 들어가지 않게 한다.

 

즉, 2편에서 다룬 alignas(64)의 진짜 목적이 여기서 다시 등장합니다.

패턴: thread slot을 캐시 라인 단위로 고정

 

struct alignas(64) ThreadSlot
{
	uint64_t counter; // padding은 컴파일러/플랫폼에 따라 달라질 수 있음
    char pad[64 - sizeof(uint64_t)];
};

ThreadSlot slots[MAX_THREADS];
void Worker(int tid)
{
	for (...)
    {
    	slots[tid].counter++; // 각자 자기 라인만 건드림
    }
}

이 설계는 속도 최적화라기보다
coherency 트래픽 최악 케이스 제거(안정화)입니다.

---

6) 처방 3: 큐/링버퍼는 head/tail(메타데이터)을 분리하라

Lock-free 큐에서 흔한 병목은 알고리즘이 아니라 메타데이터 배치입니다.

• head와 tail이 같은 캐시 라인에 있으면
• producer/consumer가 서로 다른 변수를 업데이트해도
• 같은 라인을 두고 ping-pong이 납니다 (False Sharing)

원칙

• head와 tail을 다른 캐시 라인으로 분리
• size/flags 같은 write-hot 메타데이터도 분리

이건 구조가 복잡해지기 전에 적용할수록 효과가 큽니다.

---

7) atomic을 써야 한다면: 최소한 이 관점으로 사용해라

atomic을 완전히 없앨 수 없는 경우도 있습니다.
그럴 때의 원칙은 단순합니다.

(1) hot loop에서 atomic을 빼라

• 루프 안에서 1회를 루프 밖에서 1회로 바꿔라 (batch)

(2) 공유 write-hot을 줄여라

• write 빈도를 낮추거나, 스레드별로 나누고 합쳐라

(3) 같은 라인을 두 스레드가 건드리지 않게 배치하라

• per-thread slot
• alignas(64) 또는 명시적 padding

여기까지 하면 atomic이 락처럼 느려지는 대부분의 상황은 정리됩니다.

---

8) 체크리스트: 이 조건이면 atomic 병목을 의심해라

• 스레드를 늘렸는데 throughput이 거의 안 오르거나 떨어진다
• 전역 카운터/통계/큐 인덱스가 hot path에 있다
• 프로파일에서 모두가 같은 위치를 건드린다는 냄새가 난다
• 락은 없는데도 CPU가 바쁘고 일이 안 끝난다

이때는 먼저 묻는 게 맞습니다.

“나는 지금 연산을 하고 있나, 아니면 캐시 라인 소유권을 주고받고 있나?”

---

마무리: 멀티스레드 최적화의 본질

시리즈를 4편까지 오면 결론은 선명해집니다.

• 1편: CPU는 연산보다 물류(메모리/캐시)가 문제다
• 2편: 멀티코어는 shared cache line 때문에 무너진다 (False Sharing)
• 3편: Invalidate는 감이 아니라 MESI 규칙으로 발생한다
• 4편(오늘): atomic의 비용은 락이 아니라 라인 소유권 경쟁이다

그래서 실전 처방도 단순합니다.

1. 공유 write-hot을 없애라
2. 스레드별로 누적하고 마지막에 합쳐라(reduction)
3. 어쩔 수 없이 공유하면 라인을 분리하라(alignas(64), layout)

이전글

다른 코어가 같은 캐시 라인을 가진 상태에서,
누군가 그 라인을 write(특히 RMW)로 독점하려는 순간.
Invalidate가 터진다.

우리는 False Sharing을 캐시 라인 ping-pong으로 봤습니다.
그런데 여기서 한 단계 더 정확해져야 해요.

Invalidate는 캐시 미스가 아니라, 쓰기 권한(소유권) 경쟁 때문에 발생한다.

즉, 멀티코어에서 느려지는 이유는 데이터가 멀리 있어서가 아니라
누가 그 캐시 라인을 ‘쓰기 가능한 최신 상태’로 갖고 있느냐를 맞추느라 트래픽이 터지기 때문입니다.

이걸 설명하는 최소 모델이 MESI입니다.

0) MESI를 한 문장으로 정의

캐시 라인(보통 64B)마다 CPU는 “이 라인이 지금 어떤 상태인가”를 관리합니다.

• M (Modified): 내가 수정했고(Dirty), 최신. 다른 코어는 못 가짐
• E (Exclusive): 나만 가지고 있고 최신. 아직 수정은 안 했음
• S (Shared): 여러 코어가 읽기용으로 공유 중
• I (Invalid): 무효(없다고 봐도 됨)

여기서 핵심은 딱 하나:

쓰기(write)는 ‘독점(Exclusive)’ 상태를 요구한다.
그래서 누가 쓰려고 하면, 다른 코어의 같은 라인은 Invalidate(I) 된다.

1) 읽기만 하면 보통 큰 싸움이 없다 (Read / Read)

두 코어가 같은 주소 X를 읽기만 한다고 하자.

• Core0: X를 읽음 → E 또는 S (상황에 따라)
• Core1: X를 읽음 → 둘 다 S로 수렴

여기서는 보통 Invalidate 폭발이 없습니다.
왜냐하면 읽기는 최신성만 맞으면 되고, 독점 소유권이 필요 없기 때문입니다.

결론: Read-mostly 공유는 비교적 안전하다.

2) 누군가 쓰기를 하는 순간부터 Invalidate가 시작된다 (Read / Write)

이제 Core1이 X를 write 한다고 하자. (X++ 같은 수정)

이미 Core0이 X를 S 상태로 갖고 있었다면?

• Core1은 쓰기 위해 X를 독점 상태(M / E)로 만들어야 함
• 그래서 Core0의 X는 I(Invalid) 로 바뀜

즉, 규칙은 간단합니다.

다른 코어가 같은 캐시 라인을 가지고 있는데, 누군가 write를 하려는 순간 → Invalidate 발생

이때 Core0는 내 캐시에 분명히 있었는데(I로 바뀌어서) 다시 가져와야 하고,
이게 Coherency Miss로 관측됩니다.

3) 최악은 Write / Write: 소유권이 공처럼 튕긴다 (Ping-Pong)

False Sharing이 터지는 대표 상황이 이거죠.

• Core0: 라인 X의 어떤 필드(변수 A)를 계속 write
• Core1: 같은 라인 X의 다른 필드(변수 B)를 계속 write

둘은 논리적으로 다른 변수지만, 캐시 라인이 같으면 같은 전쟁입니다.

흐름은 이렇게 됩니다.

1. Core0 write → X를 M로 만든다 (Core1 쪽 X는 I)
2. Core1 write → X를 M로 만들려 한다 → Core0 쪽 X는 I
3. Core0 write → 다시 독점 필요 → Core1 쪽 I
   … 무한 반복

여기서 중요한 포인트:

• 값 자체의 충돌이 없어도
• 캐시 라인 소유권 때문에
• Invalidate가 매번 발생한다.

결론: False Sharing은 shared data가 아니라 shared cache line 문제다.

4) 왜 RMW(atomic)이 특히 비싼가: 독점 + 순서를 강제한다

다음 편에서 atomic을 깊게 다루겠지만, 원리만 여기서 박아두면 이렇습니다.

atomic_fetch_add 같은 연산은 단순 write가 아니라 Read-Modify-Write입니다.

• 값을 읽고
• 수정하고
• 다시 쓰는 작업

이건 의미상 중간에 다른 코어가 끼면 안 되기 때문에,
하드웨어는 보통 해당 라인을 더 강하게 독점하려고 합니다.

즉, 경쟁 상황에서 atomic은 이렇게 동작해요.

• 여러 코어가 동일 라인에 대해 RMW를 시도
• 각 코어가 “내가 지금 독점해서 처리해야 함”을 강제
• 결과적으로 invalidate + 소유권 이동이 더 자주, 더 비싸게 발생

그래서 atomic 비용을 락이니까 느리다고만 보면 진단이 반쯤 틀립니다.

atomic의 핵심 비용은 락이 아니라, 캐시 라인 소유권 경쟁(= coherency 트래픽)이다.

이게 4편의 주제가 됩니다.

5) 이 규칙을 코딩 관점으로 번역하면

MESI를 외우는 목적은 상태도를 잘 그리자는 게 아닙니다.
코드를 이렇게 분류하기 위해서예요.

안전한 패턴(대체로)

• read-mostly 공유 (초기화 후 읽기 전용)
• 스레드마다 자기 데이터에 write (서로 다른 라인)

위험한 패턴(거의 확실히 터짐)

• 여러 스레드가 같은 라인에 write
• 서로 다른 변수라도 같은 캐시 라인이면 동일하게 위험
• 경쟁 상황의 atomic RMW (특히 hot counter)

여기서 2편에서 말한 alignas(64)가 다시 의미를 갖습니다.

• alignas(64)는 단순히 빠르게 하는 것이 아니라
• write-hot 데이터가 같은 캐시 라인을 공유하지 않게 하는 장치
• 즉 Invalidate 규칙을 회피하는 설계입니다.

마무리

여기까지 정리하면, 멀티스레드에서 성능이 무너지는 이유는 CPU가 느려서가 아닙니다.

이전글

다음글

실시간 시뮬레이션에서 가장 먼저 흔들리는 축은 물리 현상보다 시간인 경우가 많습니다. 시간이 흔들리면 데이터의 선후 관계가 흐려지고, 이는 시스템 신뢰도 저하로 직결됩니다. 본 글은 화려한 월드 구성보다 오차 발산을 제어하는 시간 모델을 최우선 전제로 두고, 각 레이어를 데이터 생산 관점으로 정렬하는 설계 관점을 정리합니다.

0. 근본 전제: 오차 발산을 제어하는 시간 모델

초기 설계에서는 엔진 기본 Tick에 의존하기 쉽습니다. 그러나 프레임레이트 변동성은 누적 오차를 만드는 주요 요인이며, 재현성을 떨어뜨립니다.

• 프레임 기반(Variable Step): 환경에 따라 불안정하며 재현성이 확보되기 어렵습니다.
• 고정/통제된 시간 모델(Controlled Timestep): 설계 난도는 높지만 수치적 안정성을 확보할 수 있으며, 장기 실행에서도 결과 발산을 억제하는 검증 가능한 기반이 됩니다.

이 전제가 잡혀야 시뮬레이터는 시각 도구를 넘어 데이터 생산 장치로서 의미를 갖습니다.

1. 월드 레이어: 시각적 재현이 아닌 측정 가능한 좌표계

월드는 배경이 아니라 기준 레퍼런스(Reference Frame)입니다.

• 정밀도 우선: 외부 스캔/지도 데이터를 이식할 때 좌표계와 스케일의 일관성이 무너지면 센서 데이터의 물리적 설명력이 약해집니다.
• 표준화: 원점, 축 방향, 단위를 명확히 규정하여 월드의 퀄리티가 아니라 측정의 정밀도에 집중합니다. 이를 통해 센서 레이어가 단순 렌더링이 아닌 계측 단계로 진입할 수 있습니다.

2. 센서 레이어: 화면 출력이 아닌 측정 장치(Measurement Device)

센서는 시각적 결과물이 아니라, 정의된 규칙에 따라 데이터를 추출하는 측정기로 취급해야 합니다.

• 모델링 분리: 카메라, LiDAR 센서를 구현할 때 렌더링 파이프라인과 물리적 측정 규칙(필터, 노이즈, 왜곡 모델)을 분리합니다.
• 인사이트: 그럴듯한 이미지를 생성하는 것보다, 데이터 생성 조건(Time-stamp, Noise Model)이 명확해야 검증 가능성이 확보됩니다. 조건이 불명확하면 재현성과 검증 가능성이 떨어집니다.

3. 에이전트 레이어: 알고리즘과 동역학의 분리

에이전트의 움직임을 구현할 때 경로 계획(Algorithm)과 물리적 거동(Dynamics)을 분리하여 설계합니다.

• 디버깅 가시성: 의사결정의 문제인지, 제어 및 물리 모델의 한계인지를 구분할 수 있습니다.
• 확장성: 알고리즘을 교체하더라도 물리적 신뢰성을 유지하며 트래픽 모델로 확장할 수 있습니다.

에이전트가 의도대로 움직이더라도, 실시간 시스템에서는 연산 지연과 통신 지연이 인과율을 흔들 수 있습니다.

4. 시스템 동역학 및 지연(Latency) 관리

실시간 시뮬레이션에서 연산 자원과 정확도는 트레이드오프 관계입니다.

• 최적화 전략: 실시간성을 유지하면서 수치해석적 정확도를 유지할 수 있는 임계점을 정의합니다.
• 지연 모델링: 네트워크 송수신/하드웨어 제어에서 발생하는 지연이 인과율에 미치는 영향을 설계 단계에서 고려합니다. 지연이 반영되지 않으면 실제 환경 적용에서 오차가 확대될 수 있습니다.

5. 데이터 레이어: 재현 가능성과 추적성(Traceability)

데이터의 가치는 양이 아니라 수집 조건의 명확성에서 결정됩니다.

• 메타데이터 고정: 좌표계, 타임스탬프, 노이즈 규칙, 시나리오 ID를 결합합니다.
• 구조화: 생성 데이터가 어떤 조건에서 도출되었는지 역추적 가능해야 데이터로서의 자격을 갖습니다.

6. 송수신 레이어: 시스템 인터페이스의 경계 정의

시뮬레이터는 단독 프로그램이 아니라 시스템의 구성 요소입니다.

• 프로토콜 정리: TCP/UDP, gRPC, MQTT, CAN 등 통신 규격과 유실/동기화 규칙을 정의합니다.
• 경계 정의: 입력과 출력의 경계가 잡혀야 검증 가능한 시스템으로 운영할 수 있습니다.

7. 검증 레이어: 폐쇄 루프(Closed-loop)의 완성

검증이 없는 데이터 생산은 반복될수록 왜곡될 수 있습니다.

• 재현성 테스트: 동일 조건에서 동일 결과가 도출되는지(Determinism)를 모니터링합니다.
• 표준 준수: OpenDRIVE, OpenSCENARIO 등 표준 규격을 고려하고 시나리오 기반 엣지 케이스를 검증합니다.

요약하면, 성공적인 디지털 트윈 시뮬레이션은 엔진 성능이 아니라 오차가 발산하지 않는 시간 모델 위에서 각 레이어를 데이터 생산 관점으로 정렬하는 설계 역량에 달려 있습니다. 발산하지 않는 시스템만이 개선과 확장을 허용합니다.

디지털 트윈은 단순한 구현을 넘어, 시간·센서·데이터·검증이 맞물리는 공학적 설계 문제로 확장됩니다.
본 글의 7단계 레이어 설계(시간 모델→월드→센서→에이전트→지연→데이터→연동/검증)를 실제 프로젝트에 적용하거나, 현재 구조의 발산이나 비재현 이슈를 정리하고 싶다면 연락 주시면 됩니다. 멘토링 및 기술 자문도 열어두었습니다.

• Email: chessire@naver.com
• LinkedIn: DM(프로필 링크)

CPU는 연산보다
데이터를 가져오는 방식에
훨씬 민감하다.

CPU 최적화를 연산을 줄이는 일로만 보면, 체감 성능이 잘 안 나옵니다. 실전 병목은 대개 계산(ALU)이 아니라 메모리 접근(Load/Store)에서 터집니다. CPU는 load => execute => add 같은 일을 파이프라인으로 겹쳐서 처리할 수 있지만, 데이터가 제때 도착하지 않으면 실행 유닛은 그냥 놀게 됩니다.

1) 패러다임 전환: 연산이 아니라 물류(Load/Store)가 문제다

CPU 내부엔 역할 분리가 있습니다.

• LSU(Load/Store Unit): 메모리를 읽고/쓰는 담당
• ALU/FPU/SIMD: 실제 계산 담당

코드가 느릴 때 계산량이 많아서일 수도 있지만, 더 흔한 케이스는 이겁니다.

• 계산은 준비됐는데 로드가 늦어서 실행이 멈춘다.
• 실행 중에 다음 데이터를 추가로 로드하려다가 캐시 미스로 브레이크가 걸린다.

그래서 최적화의 시작점은 연산 줄이기가 아니라 캐시 히트율을 올리는 데이터 배치입니다.

2) 캐시의 작동 원리: CPU는 64B ‘박스’ 단위로 움직인다

캐시는 바이트 단위로 움직이지 않습니다. 보통 캐시 라인(Cache Line) 단위(대부분 64B)를 최소 단위로 가져오고 버립니다.

여기서 지역성이 나옵니다.

• 공간 지역성(Spatial): 다음에 접근할 메모리가 인접해 있다.
• 시간 지역성(Temporal): 방금 접근한 메모리를 곧 다시 쓴다.

즉, 우리가 코드를 예측 가능하게 만든다는 말의 실체는 대부분 이겁니다.

• 인접 데이터를 연속으로 쓰게 만들고(공간)
• 최근에 쓴 데이터를 다시 쓰게 만들면(시간)
• 캐시 히트율이 올라가고, 로드 지연이 줄어듭니다.

3) 예측 실패보다 무서운 설계 실수: 캐시 미스는 4C로 보자

교과서적 분류는 3C(Cold/Capacity/Conflict)지만, 멀티코어까지 다루려면 4C가 더 정합적입니다.

4C Cache Miss

1. Cold (Compulsory) Miss
   처음 접근이라 캐시에 없어서 발생.
2. Capacity Miss
   캐시 용량 자체가 부족해서, 담아두지 못하고 밀려남.
3. Conflict Miss
   캐시에 공간은 있는데 매핑/세트 충돌 때문에 교체가 과하게 발생.
   특히 stride 패턴이 캐시 인덱스와 맞물리면 계속 갈아엎는 현상이 나옵니다.
4. Coherency Miss (일관성 미스)
   다른 코어가 내가 들고 있던 캐시 라인을 수정해서 Invalidate가 걸린 경우.
   이게 나중에 말할 False Sharing의 바로 그 뿌리입니다.

여기서 중요한 건, 미스를 예측 실패 하나로 뭉개면 원인 진단이 틀어진다는 점입니다.
Capacity인지, Conflict인지, Coherency인지에 따라 처방이 완전히 달라집니다.

4) Stride 프리패처: CPU는 일정 보폭을 좋아한다

하드웨어 프리패처는 다음 줄을 무조건 읽어오기만 하지 않습니다. 규칙적인 보폭(Stride)을 학습합니다.

예를 들어:

• [0] -> [4] -> [8] -> [12] 처럼 일정하면
  → 4칸씩 뛴다는 점을 학습하고 미리 끌어옵니다.

반대로,

• stride가 너무 크거나(Large Stride)
• 접근 주소가 불규칙하게 튀면(Random)
  → 프리패처가 포기하거나 정확도가 떨어집니다.

이 지점이 CPU가 좋아하는 데이터 배치의 현실적인 기준입니다.
연속 배열 + 규칙적 루프는 프리패처, 캐시, SIMD까지 한 번에 정렬됩니다.

5) 구조체 설계의 정석: 무조건 alignas가 아니라 데이터 구겨넣기(Packing)가 먼저다

정렬(Alignment)은 분명 도움이 됩니다. 특히 캐시 라인을 걸치지 않게 만들거나, 멀티스레드에서 라인 공유를 피하는 데도 쓰입니다. 하지만 무작정 alignas(64)부터 박으면 이런 문제가 생깁니다.

• 구조체가 작아도 64B 패딩이 붙어 캐시 오염(cache pollution)이 생김
• 결과적으로 실제 유효 데이터 대비 로드량이 늘어서 히트율이 떨어질 수 있음

그래서 우선순위는 보통 이 순서가 맞습니다.

1. 필드 재배치 / 타입 정리로 패딩을 줄인다.
2. 남는 공간은 자주 쓰는 필드로 메꿔서 64B를 꽉 채운다. (패킹)
3. 그래도 필요할 때만 alignas(64) 같은 강제 정렬을 쓴다.

그리고 여기서 다음 글 떡밥이 자연스럽게 이어집니다.

• 구조체를 64B 정렬하는 이유는 속도만이 아니라
  멀티코어에서 False Sharing(거짓 공유)를 피하기 위한 목적도 큽니다.
  (서로 다른 스레드가 같은 캐시 라인을 건드리면 Coherency Miss가 폭발합니다.)

6) AoS vs SoA: 데이터의 본질이 아닌 접근 패턴으로 결정한다

여기서 정답을 단정하면 항상 사고가 납니다. 결론은 하나입니다.

AoS/SoA는 취향이 아니라,
루프의 형태로 결정한다.

AoS (Array of Structures)

• 개체 하나를 잡고 여러 필드를 같이 만지는 패턴에 유리
• 단점: 특정 필드만 훑을 때 불필요한 데이터까지 같이 로드될 수 있음

struct Agent { float pos, vel, health; };
Agent agents[100];

SoA (Structure of Arrays)

• 같은 필드를 대량으로 훑는 패턴(예: pos만 10만 개 업데이트)에 유리
• 장점: 캐시/프리패처/SIMD와 궁합이 좋은 경우가 많음
• 단점: 개체 단위로 여러 필드를 동시에 만지면 오히려 산개 접근이 될 수 있음

struct AgentGroup { float pos[100], vel[100], health[100]; };

※ 참고로 Epic Games의 Unreal Engine 쪽에서 ECS 계열(예: Mass 같은 접근)을 떠올릴 수 있는데, 엔진 기능 자체보다 중요한 건 “내 루프가 무엇을 연속으로 훑는가”입니다. 기능 이름보다 접근 패턴이 먼저입니다.

7) 현대 하드웨어의 복잡성: L3 포함 정책은 유연해지는 추세

마지막으로, 멀티코어 시대에 L3 정책 이야기를 안 하면 반쪽입니다.

• L1/L2: 코어 전용, 빠르고 작음
• L3: 여러 코어가 공유, 상대적으로 크고 느림

여기서 Inclusive / Non-Inclusive 얘기가 나오는데, 포스팅에서 중요한 태도는 이겁니다.

• 제조사별 경향성은 참고 가치가 있지만
• 최근에는 코어 수 증가와 L3 효율 문제 때문에
  두 진영 모두 정책을 더 유연하게 가져가는 추세라는 점을 같이 적는 게 신뢰도가 높습니다.

즉, 브랜드로 단정하기보단 마이크로아키텍처/제품군 기준으로 확인하는 게 맞습니다.
(특히 서버/워크스테이션 라인업은 정책이 다르게 나타나는 경우가 많습니다.)

여기서 Intel / AMD 비교를 할 때도 단정이 아니라 확인이 핵심입니다.

이 글의 결론, “캐시를 설계하라”

CPU 최적화는 결국 이 두 문장으로 요약됩니다.

1. 연산보다 로드가 먼저 병목이다.
2. 캐시는 라인 단위로 움직이고, 미스는 4C로 구분해야 한다.

다음 글에서 이어설명할 주제는 아래와 같습니다.

• Coherency Miss와 False Sharing
• 왜 alignas(64)가 속도가 아니라 멀티코어 안정성의 문제인지
• 그리고 멀티스레드에서 캐시 라인을 어떻게 분리/배치할지

이전글

다음글

Coherency Miss(일관성 미스)로 보는
캐시 라인 전쟁과 해결 전략,
alignas(64)는 속도가 아니라
멀티코어 안정성이다.

싱글 스레드 최적화는 보통 캐시 히트율로 설명이 끝납니다.
하지만 멀티스레드에 들어가면 캐시 미스의 얼굴이 하나 더 늘어납니다.

Coherency Miss(일관성 미스).

이건 캐시에 없어서가 아니라, 다른 코어가 내 캐시 라인을 건드려서 내 캐시가 무효화(invalidate)되는 미스입니다. 즉, 데이터가 원래 캐시에 있었는데도, 멀티코어 환경 때문에 있었지만 없어진 것이 됩니다.

1) Coherency Miss란 무엇인가

멀티코어 CPU는 각 코어가 L1/L2 같은 빠른 캐시를 따로 들고 있습니다.
그럼 문제가 생겨요.

• 코어 A가 어떤 메모리 주소 X를 캐시에 들고 있음
• 코어 B도 같은 주소 X를 캐시에 들고 있음
• 코어 B가 X를 쓰기(write) 하면?
• 코어 A가 들고 있던 X는 더 이상 최신이 아님

그래서 CPU는 캐시 일관성 프로토콜(MESI 계열)로 누가 최신인지를 맞춥니다.
이때 흔히 일어나는 현상이:

• invalidate(무효화): 다른 코어가 수정한 라인을 내 캐시에서 폐기
• 다음에 내가 읽을 때는 다시 가져와야 함 → coherency miss

이게 Coherency Miss의 정체입니다.
핵심은 데이터가 멀리 있어서 느린 게 아니라, 서로 방해해서 느린 것입니다.

2) False Sharing: 같은 데이터를 공유한 적이 없는데 공유가 발생한다

False Sharing(거짓 공유)은 더 악질입니다.

두 스레드가 서로 다른 변수를 쓰는데도 느려져요.
왜냐하면 캐시는 변수 단위가 아니라 캐시 라인(보통 64B) 단위로 일관성을 맞추기 때문입니다.

예를 들어, 같은 캐시 라인 안에 아래 두 변수가 들어있다고 하자.

• counterA (스레드 A가 계속 증가)
• counterB (스레드 B가 계속 증가)

둘은 다른 변수고, 논리적으로는 공유가 아닙니다.
하지만 캐시 라인 단위로 보면 둘은 같은 64B 박스 안에 들어 있음.

그러면 벌어지는 일:

1. 스레드 A가 counterA++
   → 해당 캐시 라인(64B)을 쓰기 가능한 최신 상태로 만들기 위해 독점화
2. 스레드 B가 counterB++
   → 똑같은 캐시 라인을 독점화하려고 함
   → A 쪽 라인 invalidate
3. A가 또 counterA++
   → 다시 라인 가져오고 invalidate 반복

이게 흔히 말하는 ping-pong입니다.
캐시가 공처럼 튕기면서 coherency 트래픽이 폭발하고, 성능이 급격히 떨어집니다.

즉, False Sharing은 데이터 공유가 아니라
캐시 라인 공유가 문제입니다.

3) 왜 alignas(64)는 속도가 아니라 안정성인가

많은 사람들이 alignas(64)를 빠르게 하려고 붙입니다.
하지만 멀티스레드에서 alignas(64)의 진짜 목적은 다른 쪽입니다.

서로 다른 스레드가 쓰는 데이터가 같은 캐시 라인에 들어가지 않게 보장하는 것.

즉, False Sharing을 구조적으로 차단하는 장치입니다.

여기서 속도라는 표현이 위험한 이유가 있어요.

• 싱글 스레드에서 alignas(64)는 오히려 패딩이 늘어 캐시 효율을 떨어뜨릴 수 있음
• 멀티스레드에서 alignas(64)는 패딩을 감수하더라도 coherency 폭발을 막아 성능을 안정화함

그래서 alignas(64)는 평균 성능 상승이 아니라
최악의 경우를 제거하는 안정성 장치에 가깝습니다.

4) 멀티스레드에서 캐시 라인을 분리/배치하는 실전 전략

아래는 현업에서 바로 적용하는 순서입니다.

(1) 쓰기를 분리하라: write-hot 데이터부터 격리

False Sharing은 거의 항상 write-write 또는 write-read에서 터집니다.
그래서 먼저 찾아야 하는 건:

• 여러 스레드가 자주 쓰는 변수(카운터, 플래그, 상태값, work queue head/tail 등)

이런 변수는 각 스레드 전용 구조체로 분리하거나, 최소한 캐시 라인을 분리해야 합니다.

(2) Thread-local(스레드 로컬)로 바꾸고 마지막에 합쳐라

공유 카운터를 매번 증가시키는 대신:

• 스레드별 로컬 카운터에 누적
• 프레임 끝/작업 끝에 한 번 합산(reduction)

이건 캐시 최적화라기보다 coherency 최적화입니다.

(3) 구조체를 역할로 쪼개라: read-mostly vs write-hot

AoS/SoA와 같은 결로, 멀티스레드에서도 데이터는 성격이 갈립니다.

• read-mostly(거의 안 변함): 공유해도 비교적 안전
• write-hot(자주 변함): 공유하면 폭발

write-hot만 따로 빼서 alignas(64)를 주는 식으로,
전체 구조체에 무작정 패딩을 박지 않는 게 포인트입니다.

(4) 캐시 라인 패딩 패턴(실전 템플릿)

가장 흔한 패턴:

struct alignas(64) ThreadCounter
{
	std::atomic<uint64_t> value;
	char pad[64 - sizeof(std::atomic<uint64_t>)];
};

핵심은 변수 하나를 64B 박스 하나에 고정시키는 것.
이러면 서로 다른 스레드의 카운터가 같은 라인에 섞일 일이 없습니다.

(5) 큐/링버퍼는 헤더와 테일을 분리한다

멀티프로듀서/멀티컨슈머 구조에서 자주 터지는 포인트가:

• head / tail
• size / flags

이런 메타데이터가 같은 캐시 라인에 붙어있으면 False Sharing이 쉽게 납니다.
헤더와 테일을 다른 캐시 라인으로 분리하면 체감이 크게 바뀌는 경우가 많습니다.

5) 체크리스트: 이 증상이면 False Sharing을 의심해라

• 스레드를 늘렸는데 성능이 안 오르거나 오히려 떨어진다
• CPU 사용률은 높은데 처리량이 늘지 않는다
• 특정 공유 카운터/플래그를 제거하면 성능이 갑자기 좋아진다
• 동일 코드를 단일 스레드로 돌리면 안정적이다

이 경우는 연산 최적화가 아니라
coherency/false sharing 최적화를 먼저 의심하는 게 맞습니다.

마무리

Coherency Miss와 False Sharing은 캐시가 부족해서가 아니라
캐시가 서로 싸워서 생기는 성능 붕괴입니다.

그래서 alignas(64)는 “빠르게 만들기”가 아니라
멀티코어에서의 안정성(최악 제거)을 위한 설계 도구입니다.

다음글

누구를 탓할지보다 중요한 건 세 가지다.
감정을 덜고, 재발을 막고, 회복을 보장하는 것.

긴급 대응은 헌신이나 책임감의 문제가 아닙니다.

지속 가능성의 문제입니다.

새벽 호출, 주말 호출 그 자체보다

개발자를 더 소진시키는 것은

긴급 상황 이전과 이후의 태도와 구조입니다.

그리고 긴급 대응에 감정 압박이 더해지는 순간,

그 사람은 다음 호출을 버텨내기 점점 힘들어집니다.

긴급 대응은

헌신이나 책임감의 문제가 아닙니다.

그 상황을 다음에도 다시 감당할 수 있는가의 문제입니다.

존중

긴급 대응에서 가장 먼저 지켜야할 것은

'얼마나 빨리 고치느냐'가 아니라

누가, 어떤 상태로 그 자리에 서 있었는가 입니다.

국경을 지키고 있는 군인,

치안을 지키고 있는 경찰,

안전을 지키고 있는 소방수처럼

긴급 대응 이전에

누가, 어떤 상태로 그 자리에 서 있었는지에 따라

긴급 상황이 발생했을 때,

대응이 크게 갈릴 것입니다.

그리고 긴급 상황에서

휘말리는 감정적인 여파를 어떻게 다루느냐에 따라

다음 긴급 상황에 있어

소명감을 가지고 임하는 개발자가 될지

상황을 회피하고 싶은 개발자가 될지가

판가름나게 됩니다.

존중에 대한 프로세스

단지 긴급 대응을

사람의 책임감으로 버티기 시작하는 순간,

이미 그 조직은 위험합니다.

긴급 대응은 영웅을 만드는 시간이 아닙니다.

한 사람이 반복해서 그 자리에 서게 되는 구조는
단기적으로는 안정처럼 보이지만,

시간이 지날수록
조직이 대응 방식을 점검할 기회를 잃게 만듭니다.

존중은 태도의 문제라고 생각하기 쉽습니다.

하지만 운영에서는 결국 프로세스의 문제로 귀결됩니다.

아무리 존중하는 말을 건네더라도

그 다음 호출이 똑같은 방식으로 반복된다면,

그 존중은 오래 가지 못합니다.

그래서 긴급 대응에서의 존중은

말이 아니라 프로세스로 확인되어야 합니다.

그래서 긴급 대응 이후에

조직이 해야 할 프로세스는 명확합니다.

• 누군가를 탓하지 않는 것
• 감정을 덜어내는 것
• 다음 상황을 대비하는 것

이 세가지가 없으면

긴급 대응 반복될수록 개발자를 갉아먹게 됩니다.

그렇게 다음 상황을 대비할 때에는

• On-Call이 특정 인원에게 고착되지는 않았는지
• 대체 휴무나 회복 시간이 보장되었는지
• 같은 상황이 다시 발생할 여지가 있는지

를 반드시 확인해야 합니다.

당연하게도 확인한 것들을 바로 적용할 수는 없을 것입니다.

다만 확인하는 것 만으로도

고칠 수 없는 상태가

고칠 수 있는 상태로 바뀌게 됩니다.

구성원들이 고칠 수 있는 방향성을 생각하게 됩니다.

맺는말

긴급 대응을 견디는 조직은 많지만,

긴급 대응을 지속 가능하게 다루는 조직은 많지 않습니다.

중요한 것은 다음 호출이 올 때 같은 사람이 같은 방식으로 다시 서게 만드는 것이 아니라,

그 상황을 조직 전체가 어떻게 감당할 수 있을지에 대한 기준을 남기는 일입니다.

이전글

"누구의 잘못인가?"
or
"어떻게 수습할 것인가?"

• 실력 부족으로 생기는 버그
• 실력이 있어도 생기는 버그

실무에서는 둘을 구분하지 않습니다.

왜냐하면 결과는 동일하게 장애로 연결되기 때문입니다.

버그를 책임 소재로 보는 조직

이러한 접근은 다음의 질문으로 시작합니다.

• "왜 이런 버그가 나왔죠?"
• "누가 이 코드 짰어요?"
• "테스트 안해보셨어요?"

이러한 방식의 질문은

문제해결보다는 책임 규명이 먼저일 때 튀어나옵니다.

그리고 이러한 질문이 반복되면

개발자는 문제 해결 모드가 아니라

상황 설명을 최소화하는 모드로 전환됩니다.

이 전환은 감정의 문제가 아니라,

정보가 흐르는 방식을 바꿉니다.

무엇이 문제였는지보다

어디까지 말해도 되는지가 먼저 계산되기 시작합니다.

개발자 개인의 책임으로 돌리는 것은

단기적으로 감정이 해소될지 몰라도

구조적 안정성을 확보할 수는 없습니다.

버그를 시스템 이벤트로 보는 조직

버그를 시스템 이벤트로 보는 접근법은

다음의 질문으로 이어집니다.

• "사용자 영향 범위는 어떻게 돼요?"
• "롤백이 빠를까요, 핫픽스가 빠를까요?"
• "재발 조건에는 뭐가 더 있을까요?"

이 질문들은

수습 > 원인 > 구조 개선 순서를 만듭니다.

그리고 이 순서가 유지되는 조직에서는
버그 하나가 조직의 판단 기준을 갱신하는 계기로 작동합니다.

해당 구조에서는

"다음엔 더 빨리 잡자"라는 학습이 일어납니다.

"이거 왜 이렇게 했어요?"

"지금 빠르게 수습하려면 어떻게 해야하죠?"

이 한 문장의 차이가

• 팀 신뢰
• 장애 대응 속도
• 개발자의 성장 방향

을 전부 바꿉니다.

운영에서 가장 중요한 관점은

조직이 무엇을 학습하느냐 입니다.

맺는말

이 글은 개발자를 위로하기 위한 글이 아닙니다.

조직이 손해를 보지 않게 하기 위해 작성한 글입니다.

버그를 잘못 다루는 조직은 결국

• 개발자를 잃고
• 품질을 잃고
• 고객을 잃습니다.

버그는 피할 수 없습니다.

다만 그 버그가
한 번의 사고로 끝나는지,
아니면 조직의 판단을 갱신하는 계기가 되는지는
전적으로 조직이 버그를 다루는 방식에 달려 있습니다.

버그를 사람의 문제로 처리하는 조직은
같은 문제를 다른 형태로 반복하게 되고,

버그를 흐름의 문제로 다루는 조직은
점점 같은 문제를 더 빨리, 더 작게 만납니다.

다음 편에서는

개발자를 대하는 태도 - 긴급 대응편에서

더 극단적인 상황을 다뤄볼 수 있도록 하겠습니다.

안정적인 조직은
문제 앞에서 프로세스를 먼저 만든다.
사람부터 찾지 않는다.

초기 조직에서 개발 프로세스를 먼저 갖추는 경우는 거의 없습니다.

사람이 우선시되고, 그중에서도 가장 잘하는 개발자에게 의존하는 구조로 시작하는 것이 대부분입니다.

초기에는 선택지가 없기 때문에 이건 잘못이 아닙니다.

문제를 정의할 사람도, 설계할 사람도, 구현할 사람도 결국 한두명뿐이기 때문입니다.

문제는 이 다음입니다.

조직이 성장하면서도 여전히 "그 사람이라서 되는 개발"에 머무를 때,

조직은 개발자를 믿는 구조에서 벗어나지 못하기 때문입니다.

반대로 안정적인 조직은 능력이 뛰어난 개발자를 중심으로 프로세스를 끌어내는 선택합니다.

사람의 판단과 경험을 문서와 흐름으로 옮기고, 그 사람이 없어도 돌아갈 수 있는 구조를 만듭니다.

이 글은 "특정 개발자를 믿는 조직"과 "프로세스를 믿는 조직"이

어디에서 갈라지기 시작하는지에 대한 이야기입니다.

개발자 의존 구조가 강화되는 순간들

"이 문제는 누구님이 해결해주실거에요."

신규 조직이 처음 문제를 맞닥뜨리는 순간은 대부분 비슷합니다.

예상하지 못한 이슈가 발생하고, 일정은 촉박하고, 정리된 기준이 없습니다.

이때 조직은 가장 쉬운 선택을 합니다.

능력 있는 개발자에게 문제를 맡깁니다.

그 개발자는 경험과 감각으로 문제를 잘 처리해냅니다.

서비스는 멈추지 않고, 일정을 가까스로 지켜냈습니다.

조직 입장에서는 성공적인 대응처럼 보입니다.

하지만 이 지점에서 중요한 단계가 하나 빠집니다.

[회고가 없습니다.]

왜 문제가 발생했는지, 어떤 판단으로 해결했는지,

다음에는 어떻게 대응해야 하는지에 대한 정리가 이루어지지 않습니다.

시간이 지나 또 다른 문제가 발생합니다.

이번에도 기준은 없고, 초반 정리도 생략됩니다.

조직은 다시 같은 선택을 합니다.

"이 문제는 누구님이 보시면 금방 해결할 거에요."

문제는 또 해결됩니다.

그리고 또 기록은 남지 않습니다.

이 과정을 몇 번 반복하면 구조는 고정됩니다.

문제가 생기면 정리부터 하지 않고, 사람부터 찾는 조직이 됩니다.

이때부터 개발자는 문제 해결자가 아니라 조직의 완충제가 됩니다.

하지만 반복될 수록 조직은 '문제를 해결하는 방식'을 잃고,

'특정 사람을 호출하는 방식'만 남기게 됩니다.

그 구조가 낳는 실제 비용

이 구조가 유지될수록 조직은 눈에 보이지 않는 비용을 지불하게 됩니다.

대부분은 당장 드러나지 않고, 시간이 지나서 한꺼번에 터집니다.

1. 개발자 개인의 판단 구조에 회사가 존속됨

프로세스가 없는 조직에서는

의사결정의 기준이 문서나 합의가 아니라 개인의 머릿속에 존재합니다.

무엇을 우선할지, 어디까지를 리스크로 볼지,
언제 타협할지에 대한 판단이 특정 개발자의 경험과 감각에 의존하게 됩니다.

이 시점부터 회사는 시스템 위에 서 있는 것이 아니라,

특정 개인의 컨디션과 기억력이라는 가장 변동성이 큰 리스크 위에 서 있게 됩니다.

이는 단순한 위험이 아니라,

매 의사결정마다 '확인 비용'과 '대기 비용'을 지불하는 구조적 비효율로 굳어집니다.

2. 개발팀(혹은 개발자)와 나머지 조직 간의 마찰이 시작됨

문제가 반복되면 조직 내부에서는 자연스럽게 역할 인식이 갈라집니다.

• 개발자는 "설명할 시간에 내가 하는 것이 빠르다."고 느끼고,
• 다른 구성원들은 "왜 항상 개발자만 알고 있는지"를 의문으로 갖습니다.

기준이 공유되지 않기에 의사소통은 점점 감정 소모로 변하고,

마찰은 개인 간의 문제가 아니라 구조적 갈등으로 누적됩니다.

3. 개발자 번아웃, 그리고 마찰의 가속화

문제를 해결할수록 일이 줄어들지 않는 구조에서는

유능한 개발자가 가장 먼저 지칩니다.

문제해결 > 다음 문제 투입 > 기준 정리 생략

이 루프가 반복되면 개발자는 점점 완충재 역할을 수행하게 됩니다.

이때부터 번아웃은 개인의 체력 문제가 아니라

구조가 만든 결과가 됩니다.

4. 개발자 이탈 이후, 조직의 급격한 붕괴

결정적인 순간은 그 개발자가 떠난 이후입니다.

문서가 없고, 판단 기준이 남아 있지 않으며,

누구도 왜 그렇게 설계되었는지 설명하지 못합니다.

조직은 이때서야 그동안 유지되고 있던 것이

프로세스가 아니라 사람이었음을 인식하게 됩니다.

그리고 대부분의 경우, 이 인식은 너무 늦게 찾아옵니다.

언제, 어떻게 전환해야 하는가?

많은 조직은 이렇게 생각합니다.

프로젝트 마일스톤마다 기록을 어느 정도는 남기고,

그 기록을 바탕으로 사람에게 의존하던 구조를

조금씩 프로세스로 전환해 가면 된다고 말입니다.

지금이라도 늦지 않았고,

필요하다면 대표가 직접 PM 역할을 맡아서라도

그렇게 해야 한다고 판단합니다.

이 생각 자체가 틀렸다고 보기는 어렵습니다.

실제로 많은 조직이 이 방식을 선택합니다.

다만 문제는,

이 판단이 현실에서는 거의 실행되지 않는다는 점입니다.

기록은 늘 '시간이 나면' 남겨야 할 일이 되고,

대표의 PM 역할은 기존 의사결정에 또 하나의 부담으로 추가됩니다.

결국 구조를 바꾸기 위한 시도는 항상 다음 일정 뒤로 밀립니다.

이것은 구성원들의 의지가 부족해서가 아닙니다.

이미 '사람 의존적 방식'이 가장 저렴하게 동작하도록

조직의 모든 근육이 적응해버렸기 때문입니다.

내부 구성원끼리는 서로의 합의를 깨고 프로세스를 강제하는 데 드는 '설득 비용'이,

당장 급한 불을 끄는 '수행 비용'보다 훨씬 높게 느껴질 수밖에 없습니다.

그래서 내부에서의 개혁은 대부분 "좋은 이야기지만, 지금은 아닌 이야기"로 끝납니다.

사람이 해결하고,

문제는 넘어가고,

기록은 남지 않습니다.

맺는말

혹자는 말합니다.

"기술이 세상을 지배한다."고요.

하지만 실제로 조직을 움직이는 것은

기술 그 자체가 아니라,

그 기술을 어디까지, 어떻게 사용할 것인지에 대한 프로세스 입니다.

프로세스 없이 사용되는 기술은

속도를 높이기도 하지만

동시에 리스크를 높이는 선택이 되기도 합니다.

기술과 프로세스 사이의 긴장은 불편하지만,

그 불편함을 피하는 대가는 '속도'가 아니라 '부채'로 돌아옵니다.

지금 조직이 겪고 있는 문제가 단순히 일이 많아서 발생하는 '물리적 과부하'인지,

아니면 누구에게 물어봐야 할지 몰라 발생하는 '구조적 병목'인지 구분해 볼 시점입니다.

만약 후자라면,

그 균형을 잡는 데 필요한 것은 더 많은 개발자가 아니라

그 흐름을 끊고 정리해 줄 제 3의 관점일지도 모릅니다.

현재 문제를 과대평가하면,
미래의 부채가 폭발한다.
구조 대신 사람으로 버티는 순간,
사일로가 고정된다.

프로젝트가 망하는 이유는 기술이 아니라 ‘수주 시점의 판단’에서 이미 결정됩니다.

프로젝트별 사일로 생성

 속도를 위해 분리한 결정이 시간이 지날수록 조직을 분리한다.

대부분의 조직은 사일로가 문제라는 사실을 이미 알고 있습니다.

하지만 프로젝트 수주가 일정과 무관하게 늘어나기 시작하면 이 전제는 쉽게 무너집니다.

빠른 대응을 위해 특정 인력들이 반복적으로 같은 프로젝트에 배치되기 시작하면서,

공식적인 협업 구조보다 비공식적인 커뮤니케이션을 우선하게 됩니다.

그렇게 이 인력 묶음은 '검증된 조합'이라는 이유로 그대로 이동하기 시작합니다.

결국 회사는 프로젝트 단위로 돌아가는 것이 아니라 사람 단위의 묶음이 조직의 기본 단위가 됩니다.

이 상태를 우리는 사일로 라고 부릅니다.

현재의 부채 > 미래의 부채

수주 시점의 판단은 항상 [지금 당장의 문제]를 과대평가한다.

많은 조직들은 당면한 일정과 요구사항을 해결하는 것이

곧 고객의 문제를 해소하는 것이라고 생각하곤 합니다.

이 믿음은 자연스럽게 다음 프로젝트 수주로 이어집니다.

사업팀은 이미 한번 해소한 일처럼 보이기 때문입니다.

하지만 프로젝트가 진행될수록 해결되고 있는 것은 과제일 뿐,

개발팀의 입장에서 고객의 근본적인 문제는 그대로 남아있는 경우가 많습니다.

이 때 해결되지 않은 문제들은 눈에 보이지 않는 형태로 누적되고,

미래의 부채로 연결됩니다.

문제는 이 부채가 즉시 비용으로 드러나지 않는다는 점입니다.

그래서 대부분의 조직은 이를 나중에 정리해도 되는 문제로 과소평가합니다.

시간이 지나고 나서야 그 부채가 이미 단순히 정리할 수 없는 수준으로

커져있음을 발견합니다.

뒤늦게 이를 해소하려 하지만,

여전히 반복되는 당면 과제들이 발목을 잡습니다.

결국 조직은 현재의 문제도, 미래의 부채도,

모두 제대로 해결하지 못한 채 이도 저도 아닌 상태에 머무르게 됩니다.

코드 단일화 난이도 상승

프로젝트 수가 늘어날수록 코드 단일화의 난이도는 기술적인 문제가 아니라 의사결정 문제로 변한다.

수주가 연속적으로 진행되는 상황에서는 어떤 기능을 공통으로 가져가고,

어디까지를 각 프로젝트의 책임으로 둘 것인지에 대한 정리가 선행되기 어렵습니다.

이 상태에서 개발은 가장 빠른 선택을 반복하게 됩니다.

이미 존재하는 코드가 있음에도, 프로젝트별 요구사항에 맞춰 유사한 구현이 다시 만들어지는 것이죠.

시간이 지나면서 중복 코드는 자연스럽게 누적됩니다.

하지만 이 중복은 즉시 문제로 드러나지 않습니다.

이후 유사한 요구가 다시 등장하면

사업팀의 입장에서는 이미 한 번 작업했던 내용처럼 보입니다.

반면 개발팀의 입장에서는 다른 프로젝트에 종속된 구현일 뿐입니다.

이 시점부터 대화는 어긋나기 시작합니다.

사업팀은 속도를 묻고, 개발팀은 코드 구현의 비용을 설명합니다.

문제는 이 간극이 개인의 역량이나 협업 태도의 문제가 아니라,

초기 수주 단계에서 단일화에 대한 판단이 이루어지지 않았던 구조의 결과라는 점입니다.

결국 코드는 합칠 수 없고, 논의는 반복되며,

조직은 같은 문제를 두고 계속 다른 언어로 말하게 됩니다.

맺는말

많은 개발자분들이 이 지점에서 스스로를 자책을 하곤 합니다.

'내가 코드를 막 짜서 이렇게 된건가.'

'그 때, CI/CD 좀 손 봐둘껄...'

'이제 다음 코드는 어떻게 하지'

하지만 이것은 프로젝트 중간에 해결할 수 있는 성질이 아닙니다.

이 지점부터는 기술의 문제가 아니라, 수주 시점에 어떤 판단이 내려졌는가에 대한 문제입니다.