CodingNabi 님의 블로그

[C++] STL vector - size/capacity부터 iterator invalidation까지

CodingNabi — Sun, 2 Aug 2026 22:54:23 +0900

1. STL이란?

STL (Standard Template Library)은 프로그래밍에 필요한 자료구조와 알고리즘을 템플릿 형태로 제공하는 C++ 표준 라이브러리다.

컨테이너 (Container): 데이터를 저장하는 자료구조 (vector, list, map 등)
반복자 (Iterator): 컨테이너의 원소를 순회하기 위한, 포인터와 유사한 개념의 인터페이스
알고리즘 (Algorithm): sort, find 등 컨테이너에 독립적으로 동작하는 함수들

2. 배열의 한계와 vector의 등장

C 스타일 배열은 크기가 고정이라는 한계가 있다.

const int MAX_SIZE = 10;
int arr[MAX_SIZE] = {};

이 한계를 보완한 것이 vector, 즉 동적 배열이다. vector는 크기가 가변적이라는 점만 빼면 배열과 동일하게 동작한다. 원소가 하나의 연속된 메모리 블록에 저장된다는 특징도 배열과 같다.

3. size와 capacity

vector를 이해하는 핵심은 size와 capacity를 구분하는 것이다.

구분 의미

size()	실제로 사용 중인 데이터의 개수
capacity()	재할당 없이 담을 수 있는 최대 개수 (여유분 포함)

vector가 내부적으로 동작하는 원리는 다음과 같다.

여유분을 두고 메모리를 할당한다.
여유분까지 꽉 차면 메모리를 증설(재할당)한다.
기존 데이터보다 큰 새 메모리 블록을 동적 할당하고, 기존 데이터를 복사(또는 이동)한 뒤 기존 메모리를 해제한다.

capacity 관련 함수

reserve(n): capacity만 n으로 확보한다. size는 그대로이며, 원소를 생성하지 않는다. 순수하게 메모리만 미리 확보하는 용도.
resize(n): capacity와 함께 size도 n으로 변경된다. 새로 생기는 원소는 기본값으로 초기화(value-initialize)된다는 점이 reserve와의 결정적 차이.
clear(): 원소를 모두 소멸시켜 size를 0으로 만든다. capacity는 변하지 않는다.

⚠️ resize로 공간을 미리 잡아두면, 이미 size에 포함된 상태이므로 push_back이 아니라 operator[]로 접근해야 한다. (push_back은 항상 size 뒤에 추가하기 때문)

reserve를 미리 해두는 이유

capacity가 변할 때마다(재할당) 기존 원소를 복사 또는 이동하는 비용이 발생한다. 최종적으로 필요한 크기를 미리 안다면 reserve로 재할당 횟수 자체를 줄여 비용을 아낄 수 있다.

증설 배수 (Growth Factor)

메모리가 꽉 찼을 때 얼마나 증설할지는 표준에 정해져 있지 않고 구현체마다 다르다.

MSVC: 보통 1.5배
GCC libstdc++: 보통 2배

실험 코드로 직접 확인해볼 수 있다.

vector<int> s;
for (int i = 0; i < 1001; i++) {
    s.push_back(100);
    cout << s.size() << " | " << s.capacity() << endl;
}

주의사항 정리

재할당(capacity 증가)이 발생하면 기존의 iterator/pointer/reference는 전부 무효화된다.
재할당 시 원소가 복사되느냐 이동되느냐는 원소 타입의 이동 생성자가 noexcept인지에 따라 갈린다. noexcept 이동 생성자가 있으면 move, 없으면 예외 안전성 때문에 copy로 처리될 수 있다.

4. Iterator (반복자)

Iterator는 포인터와 유사한 개념으로, 컨테이너의 원소를 가리키는 역할을 한다.

vector<int> v(10);
for (vector<int>::size_type i = 0; i < v.size(); i++)
    v[i] = i;

vector<int>::iterator itBegin = v.begin(); // v[0]을 가리킴
vector<int>::iterator itEnd = v.end();     // 마지막 원소의 "다음" 주소 (쓰레기값)

순회 방법:

// 정방향
for (vector<int>::iterator it = v.begin(); it != v.end(); ++it) {
    cout << (*it) << endl;
}

// 역방향
for (vector<int>::reverse_iterator it = v.rbegin(); it != v.rend(); ++it) {
    cout << (*it) << endl;
}

포인터처럼 ++, --, += 등의 연산이 가능하지만, 어디까지나 컨테이너 내부 구현에 맞춰 동작이 정의된 별도의 타입이라는 점에서 포인터와 구분된다.

5. 중간 삽입/삭제 vs 처음·끝 삽입/삭제 vs 임의 접근

vector를 실무에서 쓸 때 가장 중요한 성능 특성이다.

연산 성능

임의 접근 (operator[])	O(1) — 좋음
끝에서 삽입/삭제 (push_back/pop_back)	O(1) (amortized) — 좋음
중간/처음 삽입/삭제 (insert/erase)	O(n) — 나쁨

원소가 연속된 메모리에 저장되기 때문에, 중간에 원소를 끼워 넣으려면 뒤의 원소들을 전부 한 칸씩 밀어야 한다.

[0][1][2][3][4][ ][ ]   // 인덱스 2에 5를 삽입하고 싶은 상황
[0][1][ ][2][3][4][ ]   // 2,3,4를 한 칸씩 뒤로 밀고
[0][1][5][2][3][4][ ]   // 빈 공간에 삽입

삭제도 마찬가지로, 삭제한 자리를 뒤 원소들로 당겨와 연속성을 유지해야 하므로 O(n) 비용이 든다.

vector<int>::iterator insertIt = v.insert(v.begin() + 2, 5);
vector<int>::iterator eraseIt1 = v.erase(v.begin() + 2);
vector<int>::iterator eraseIt2 = v.erase(v.begin() + 2, v.begin() + 4); // [2,4) 범위 삭제, 4는 미포함

6. erase 후 iterator 무효화 - 조건부 삭제 패턴

erase는 실행된 순간 해당 iterator를 무효화시킨다. 삭제 후 그 iterator를 그대로 ++ 하면 이미 유효하지 않은 iterator를 참조하게 되어 크래시로 이어진다.

// 잘못된 코드
for (vector<int>::iterator it = v.begin(); it != v.end(); ++it) {
    if (*it == 3) {
        v.erase(it); // erase 후 it은 무효! 다음 루프의 ++it에서 문제 발생
    }
}

올바른 패턴은 erase의 반환값으로 iterator를 갱신하고, for문의 ++it는 제거하여 삭제하지 않은 경우에만 증가시키는 것이다.

for (vector<int>::iterator it = v.begin(); it != v.end(); /* ++it 제거 */) {
    int data = *it;
    if (data == 3) {
        it = v.erase(it); // erase가 반환하는, 삭제된 자리를 가리키는 새 iterator로 갱신
    } else {
        ++it;
    }
}

⚠️ v.clear()를 호출하면 모든 iterator가 무효화되므로, clear 이후에는 반드시 루프를 break해야 한다.

const int* vs int* const 차이

CodingNabi — Sun, 26 Jul 2026 04:42:39 +0900

C/C++ 공부하다 보면 반드시 한 번은 헷갈리는 지점이 const와 포인터의 조합이다. 오늘 정리한 내용을 기록해둔다.

포인터가 들고 있는 두 가지

포인터 변수는 메모리 공간을 하나 차지하면서, 그 안에 주소값을 저장하고 있다. 그래서 포인터에는 "고정할 수 있는 대상"이 두 가지 존재한다.

포인터가 가리키는 데이터 (주소를 따라갔을 때 나오는 값)
포인터 자기 자신이 담고 있는 주소값

const를 어디에 붙이느냐에 따라 이 둘 중 무엇을 고정할지가 갈린다.

int a = 10, b = 20;

const int* p1 = &a;   // (1) 가리키는 데이터가 const
int* const p2 = &a;   // (2) 포인터 자체가 const

(1) const int* p1 — 가리키는 값을 못 바꾼다

이 포인터를 통해서는 가리키는 대상의 값을 변경할 수 없다. 대신 포인터가 다른 곳을 가리키게 하는 것은 자유롭다.

*p1 = 30;   // 에러! 가리키는 값 변경 시도
p1 = &b;    // OK! 포인터가 다른 곳을 가리키는 건 자유

(2) int* const p2 — 포인터 자체를 못 바꾼다

가리키는 값은 자유롭게 바꿀 수 있지만, 포인터 변수 자체(담고 있는 주소값)는 바꿀 수 없다.

*p2 = 30;   // OK! 가리키는 값 변경은 자유
p2 = &b;    // 에러! 포인터 자체(주소값)를 바꾸려 함

즉 p2는 한번 &a로 초기화되면 평생 a만 가리켜야 하는 포인터가 된다. const int x = 10;이라고 선언하면 x에 다른 값을 대입할 수 없는 것과 완전히 같은 원리인데, 다만 p2가 담고 있는 "값"이 다름 아닌 "주소"라는 점이 다르다.

판별하는 팁

const의 위치가 * 기준으로 어디에 있는지를 보면 된다.

const가 *보다 왼쪽에 있으면 → 가리키는 대상이 const
const가 *보다 오른쪽(변수 이름 바로 앞)에 있으면 → 포인터 자체가 const

참고로 int const * p3처럼 const가 int 뒤, * 앞에 오는 표기도 있는데, 이 경우도 const가 *보다 왼쪽에 있으므로 (1)과 동일하게 "가리키는 대상이 const"인 케이스다. const int*와 int const*는 완전히 같은 의미다.

malloc의 정렬(alignment)과 힙 오버플로우

CodingNabi — Sat, 11 Jul 2026 13:27:21 +0900

들어가기에 앞서 malloc에 대해 짧게 설명하자면, malloc은 힙(heap)이라는 메모리 영역에서 동적으로 메모리를 할당받는 C 표준 라이브러리 함수다.

스택 변수와 다르게, 힙 메모리는:

프로그램이 런타임에 크기를 결정할 수 있음 (컴파일 타임에 크기가 고정되는 배열과 다름)
명시적으로 free()를 호출하기 전까지 계속 살아있음 (함수가 끝나도 사라지지 않음)
힙 관리자(heap manager)라는 별도의 소프트웨어가 이 영역을 추적하고 관리함 (OS가 직접 관리하는 게 아니라, CRT/힙 라이브러리가 OS로부터 큰 덩어리를 받아와서 잘게 쪼개 나눠주는 방식)

라느 특징을 가진다.

malloc 내부 구조

malloc(12)를 호출하면 힙 관리자는 단순히 "12바이트를 뚝 떼어서 준다"가 아니라, 그 블록을 관리하기 위한 메타데이터를 함께 만든다. 대략적인 구조는 이렇다 (구현마다 세부는 다름)

[헤더: 블록 크기, 사용중/free 여부, 이전·다음 블록 링크 등 관리정보]
[정렬용 패딩 (필요 시)]
[실제 데이터 영역: 내가 요청한 12바이트]  ← p가 가리키는 지점
[정렬용 패딩 (필요 시, 다음 블록 시작 위치 맞추기 위함)]

헤더: 힙 관리자가 이 블록의 크기, 상태(사용중/free), free list 연결 정보 등을 기록해두는 영역. free(p)를 호출하면 힙 관리자는 p를 기준으로 앞쪽에 있는 이 헤더를 읽어서 "아, 이 블록은 몇 바이트짜리구나" 판단하고 free list에 돌려놓는다.
데이터 영역: 실제로 내가 쓸 수 있는 12바이트. p는 정확히 이 영역의 시작 주소를 가리킨다.
패딩: 정렬 요구사항을 맞추기 위해 붙는 여유 공간 (아래에서 자세히).

정렬은 항상 보장될까?

C 표준은 malloc이 반환하는 주소가 어떤 타입으로 캐스팅해도 안전한 정렬을 만족하도록 요구한다. x64에서는 보통 16바이트 정렬이다. 즉, malloc이 반환하는 주소값 자체가 항상 16의 배수가 되도록 힙 관리자가 보장해준다는 뜻이다. 이건 "요청 크기"까지 항상 정렬 단위로 올리는 건 아니다. 힙 관리자 구현 방식은 크게 두 가지로 나뉜다.

방식 A: Size class(bin) 기반 — glibc malloc, Windows 힙 관리자 등 대부분

작은 요청은 미리 정해진 "크기 등급"에 배정됨: 16, 24, 32, 48, 64, 96, 128, ...

malloc(12) → 가장 작은 등급(예: 16 또는 24)에 배정
malloc(20) → 다음 등급(예: 32)에 배정

정렬을 위해 올린다기보다, 메모리 단편화 방지와 관리 효율을 위해 미리 정해둔 "그릇 크기"에 담는 것. malloc(12)와 malloc(15)가 같은 등급에 들어가 _msize 결과가 동일할 수 있음.

방식 B: 헤더 오버헤드가 정렬 패딩 역할

[헤더 8~16바이트][요청한 데이터 영역][정렬 맞추기용 패딩]

블록마다 개별적으로 전체 크기가 정렬 단위(8/16)의 배수가 되도록 패딩을 끼워넣는 방식.

_msize가 알려주는 건 "물리적 크기"가 아니다

_msize는 Windows CRT가 제공하는 비표준 함수로, "이 포인터가 가리키는 힙 블록이 얼마나 크냐"를 알려주는 용도로 흔히 소개된다.

char* p = (char*)malloc(12);
printf("%d", _msize(p));

이걸 실제로 Release 모드에서 돌려보면 12가 그대로 나온다. (Debug 모드에서도 12가 나온다.)

왜 물리적으로는 더 크게 잡았을 수 있는데 _msize는 12를 돌려주는가?

Windows 힙 관리자는 블록마다 다음 두 가지를 별도로 추적한다:

실제 물리적으로 확보한 블록 크기 (정렬/size class 때문에 12보다 클 수 있음, 예: 16)
UnusedBytes — "이 블록에서 실제로 안 쓰이는 뒷부분이 몇 바이트인지"를 정확히 기록

그리고 _msize(내부적으로 HeapSize API 호출)는 다음과 같이 계산해서 반환한다:

usable_size = 물리적_확보_크기 - UnusedBytes
            = 16 - 4
            = 12   ← 요청한 크기 그대로 나옴

결론

_msize는 물리적 블록 크기가 아니라, 힙 관리자가 별도로 계산해서 알려주는 "사용 가능한(usable) 크기"를 반환한다. 이 값은 대체로 요청한 크기와 동일하게 나오며, 내부 패딩량을 반영하지 않는다. 즉, _msize로는 "실제 물리적으로 몇 바이트가 확보되어 있는지" 알아낼 방법이 없다. 이건 힙 구현이 완전히 캡슐화해서 감춰버린 정보다.

만약 12바이트를 할당받고 13바이트를 쓴다면?

직관적으론 "12바이트는 정리되고 1바이트만 쓰레기값으로 남는다"라고 생각할 수 있겠지만, 앞서 말했듯 malloc(12)를 호출하면 힙 관리자는 단순히 "12바이트를 뚝 떼어서 준다"가 아니라, 그 블록을 관리하기 위한 메타데이터를 함께 만든다.따라서 넘어간 바이트가 어디를 침범했냐에 따라 결과가 달라진다.

넘어간 위치	free(p) 시점	나중 결과
정렬/size-class 여유 공간 내부 (내 블록 소유)	문제없음	우연히 안전 — 재현 안 되는 시한폭탄
옆 블록 헤더 (메타데이터)	문제없이 통과 가능	옆 블록 malloc/free 시 크래시·힙 손상 에러
옆 블록 데이터 (사용 중)	문제없음	그 데이터를 쓰는 코드에서 값 오염 발견 — 조용한 논리 버그

어느 경우든 오버플로우가 발생한 순간에는 아무 에러도 나지 않는다. 버그를 심는 시점과 증상이 터지는 시점이 완전히 분리되어 디버깅이 매우 어렵다. 앞서 본 것처럼 _msize로도 이 여유 공간의 존재 여부를 미리 알 방법이 없으니, "여유 공간이 있으니 조금 넘쳐도 괜찮겠지"라는 가정 자체가 애초에 성립하지 않는다.

strlen, strcpy, strcmp / memcpy, memcmp 구현

CodingNabi — Sat, 11 Jul 2026 04:15:10 +0900

strlen

size_t strlen(const char* str);

인자: str — 길이를 잴 널 종단 문자열의 시작 주소
반환값: size_t — \0 직전까지의 문자 개수 (\0 자체는 카운트 안 함)
설명: str부터 한 칸씩 전진하며 \0을 만날 때까지 카운트. \0을 찾아야 끝나는 구조라 시간복잡도 O(n). 순수 바이너리 데이터에 쓰면 안 됨(중간에 우연히 0바이트가 있으면 거기서 멈춰버림).

strcpy

char* strcpy(char* dest, const char* src);

인자: dest — 복사받을 목적지 버퍼(반드시 src 길이+1 이상 크기여야 함) / src — 복사할 원본 널 종단 문자열
반환값: char* — dest의 시작 주소 (체이닝 목적)
설명: src를 처음부터 \0까지 한 바이트씩 dest에 복사, \0도 포함해서 복사함. dest 크기 체크를 안 해서 버퍼 오버플로우 위험이 있는 대표적 함수(strcpy_s, strncpy가 대안). src와 dest가 겹치면 undefined behavior.

strcmp

int strcmp(const char* s1, const char* s2);

인자: s1, s2 — 비교할 두 널 종단 문자열
반환값: int — s1 < s2면 음수, 같으면 0, s1 > s2면 양수
설명: 앞에서부터 한 바이트씩 비교하다가 다른 문자를 만나거나 둘 중 하나가 \0에 도달하면 종료. 바이트는 unsigned char로 해석해서 비교(부호 문제 방지). strncmp(s1, s2, n)은 최대 비교 길이 n이 추가된 버전.

memcpy

void* memcpy(void* dest, const void* src, size_t n);

인자: dest — 목적지 버퍼 / src — 원본 버퍼 / n — 복사할 바이트 수
반환값: void* — dest의 시작 주소
설명: \0이나 데이터 의미와 무관하게 무조건 n바이트를 그대로 복사. 구조체, 배열, 임의 바이너리 데이터에 다 사용 가능. dest와 src가 겹치면 undefined behavior — 겹칠 가능성이 있으면 memmove 사용해야 함.

memcmp

int memcmp(const void* s1, const void* s2, size_t n);

인자: s1, s2 — 비교할 두 버퍼 / n — 비교할 바이트 수
반환값: int — 첫 차이 지점에서 (unsigned char)s1[i] - (unsigned char)s2[i] 부호, 끝까지 같으면 0
설명: \0을 특별 취급하지 않고 무조건 n바이트를 끝까지(또는 다른 지점까지) 비교. 구조체 비교, 해시값 비교, 바이너리 패킷 비교 등에 사용.

핵심 구분 기준

계열	str 계열	mem 계열
대상	텍스트(문자열), \0 종단 전제	순수 바이트 블록, 타입/의미 무관
길이 파악	직접 \0 찾아가며 판단	인자로 받은 n 그대로 사용
\0 만나면	거기서 비교/복사 종료	무시하고 계속 진행
대표 용도	문자열 처리	구조체, 바이너리 패킷, 해시값 비교/복사

구현

size_t my_strlen(const char* buf) {
	const char* b_temp = buf;
	while(*b_temp != '\0') {
		b_temp++;
	}
	return b_temp - buf;
}

char* my_Strcpy(char* dest, const char* src) {
	char* d_temp = dest;
	while (*src != '\0') {
		*dest = *src;
		dest++;
		src++;
	}
	*dest = '\0';
	return d_temp;
}


int my_strcmp(const char* buf1,const char* buf2, size_t t) {
	const unsigned char* b1_temp = (const unsigned char*)buf1;
	const unsigned char* b2_temp = (const unsigned char*)buf2;

	for (size_t i = 0; i < t; i++) {
		if (b1_temp[i] != b2_temp[i]) {
			return  b1_temp[i] - b2_temp[i];
		}
		if (b1_temp[i] == '\0') {
			return 0;
		}
	}
	return 0;
}

void* my_memcpy(void* dest, void* src, size_t t) {
	//파라미터가 void*형 변수이기 때문에 캐스팅을 하려 1바이트씩 복사.
	unsigned char* d_temp = (unsigned char*)dest;
	const unsigned char* s_temp = (const unsigned char*)src;
	for (size_t i = 0; i < t; i++) {
		d_temp[i] = s_temp[i];
	}
	return dest;
}

int my_memcmp(void* buf1, void* buf2, size_t t) {
	const unsigned char* b1_temp = (const unsigned char*)buf1;
	const unsigned char* b2_temp = (const unsigned char*)buf2;

	for (size_t i = 0; i < t; i++) {
		if (b1_temp[i] != b2_temp[i]) {
			return  b1_temp[i] - b2_temp[i];
		}
	}
	return 0;
}

스파이럴(달팽이) 배열 구현하기 - 방향배열(dx, dy) 방식

CodingNabi — Thu, 9 Jul 2026 00:00:35 +0900

시리즈 마지막 방식이다. 코드가 짧고, 방향이 더 늘어나도(대각선 8방향 등) 배열 하나만 늘리면 확장되는 방식이다. 해당 방식은 방향이 필요한 모든 알고리즘에 통용적으로 사용이 가능하며, 게임 알고리즘에서도 종종 사용된다 — 예를 들어 캐릭터의 8방향 이동 처리, 타일 기반 맵에서의 인접 칸 탐색(BFS/DFS), 몬스터의 순찰 경로 계산 같은 곳에서 같은 dx[], dy[] 패턴을 그대로 가져다 쓸 수 있다.

방식 설명

핵심 아이디어는 "방향 자체를 데이터로 만든다"는 것이다.

오른쪽·아래·왼쪽·위, 이 4가지 이동을 if-else나 case로 나누는 대신, dx[], dy[]라는 배열에 미리 저장해두고, dir 값 하나로 "지금 배열의 몇 번째 방향을 쓰는 중인지"만 관리한다.

dx[dir], dy[dir]이 "지금 방향으로 한 칸 이동하면 x, y가 각각 얼마나 바뀌는지"를 나타낸다. dir이 0이면 (dx,dy)=(1,0)이라 오른쪽으로, dir이 1이면 (0,1)이라 아래로 이동한다. 막히면(dir+1) % 4로 배열의 다음 칸을 가리키게 해서 방향을 90도 꺾는다.

switch 방식과 결정적으로 다른 점은, switch는 한 방향으로 갈 수 있는 데까지 for문으로 한 번에 쭉 이동하지만, 이 방식은 딱 한 칸씩만 이동하고 매번 "다음 칸이 유효한가"를 검사한다는 것이다.

void fillSpiralByDirectionVector(int arr[SIZE][SIZE]) {
	int x = 0;
	int y = 0;
	int value = 0;
	int dx[] = { 1, 0, -1, 0 };
	int dy[] = { 0, 1, 0, -1 };
	int dir = 0;
	while (value != SIZE * SIZE) {
		arr[y][x] = ++value;

		int nextX = x + dx[dir];
		int nextY = y + dy[dir];

		if (nextX < 0 || nextX >= SIZE || nextY < 0 || nextY >= SIZE || arr[nextY][nextX] != 0) {
			dir = (dir + 1) % 4;
			nextX = x + dx[dir];
			nextY = y + dy[dir];
		}
		x = nextX;
		y = nextY;
	}
}

그림

과정

dir 값이 어떤 이동량을 뜻하는지부터 정리하면 이렇다.

방향이 막힐 때마다 dir이 0→1→2→3→0 순서로 순환하며, 각 값이 dx[], dy[]의 대응 인덱스로 실제 이동량을 결정한다. 이 순환 구조가 아래 그림에 나와 있다.

실제 값이 채워지는 순서(1~25)는 앞선 두 방식과 완전히 동일하다 — 어떤 방식을 쓰든 스파이럴이라는 문제 자체의 답은 하나뿐이기 때문이다. 차이는 오직 "어떻게 다음 칸을 계산하는가"에 있다.

(0,0)에서 시작해 value=25가 될 때까지 매 스텝 다음 칸을 검사하는 흐름을 요약하면:

(0,0)=1 → 다음칸(1,0) 유효 → 이동
(1,0)=2 → 다음칸(2,0) 유효 → 이동
...
(4,0)=5 → 다음칸(5,0) 범위 밖! → dir=0→1(DOWN)로 전환 → 다음칸(4,1) 유효 → 이동
(4,1)=6 → 다음칸(4,2) 유효 → 이동
...
(4,4)=9 → 다음칸(4,5) 범위 밖! → dir=1→2(LEFT)로 전환 → 다음칸(3,4) 유효 → 이동
...
(0,4)=13 → 다음칸(-1,4) 범위 밖! → dir=2→3(UP)로 전환 → 다음칸(0,3) 유효 → 이동
...
(0,1)=16 → 다음칸(0,0) 이미 채워짐(1)! → dir=3→0(RIGHT)로 전환 → 다음칸(1,1) 유효 → 이동

switch 방식이 "이 방향으로 갈 수 있는 만큼 for문으로 몰아서 채우고 case를 넘긴다"였다면, 이 방식은 "한 걸음씩 걷다가 막히면 그 자리에서 바로 꺾는다"는 감각에 가깝다.

특징 분석

장점

코드가 짧다 : 방향 로직 전체가 dx[], dy[], dir 세 줄로 압축된다.
방향이 늘어나도 확장이 쉽다 : 대각선을 포함한 8방향으로 바꾸고 싶으면 dx[], dy[]에 값 4개만 더 추가하면 된다. switch 방식이라면 case를 4개 더 만들어야 한다.
while 하나로 전체 로직이 끝난다 : 별도의 for문 중첩이나 case 분기 없이, 매 스텝 "이동 가능한지 검사 → 이동"만 반복한다.

단점

매 칸마다 조건 검사가 실행된다 : switch나 경계값 방식은 방향이 안 바뀌는 구간에서는 검사 없이 쭉 진행하지만, 이 방식은 25칸 전부에서 "다음 칸이 유효한가"를 매번 확인한다. (다만 이 정도 크기에서는 성능 차이가 체감될 수준은 아니다.)
배열 값에 의존한다 : switch 방식과 마찬가지로 arr[nextY][nextX] != 0으로 판단하기 때문에, 경계값 방식이 가진 "배열 값과 무관하게 안전하다"는 장점은 없다.
처음 보는 사람은 이해하는 데 시간이 걸린다 : dx[], dy[], dir이 무엇을 의미하는지 알아야 코드가 읽힌다. 코드량은 가장 적지만 압축도가 높아서, 가독성만 놓고 보면 switch 방식보다 낮다.

네 가지 방식 최종 비교

항목	switch	대칭 축소(nLength)	경계값(Boundary)	방향배열(dx,dy)
코드 길이	김	가장 짧음	중간	짧음
배열 값 의존	의존	의존 안 함(인덱스만)	의존 안 함	의존
for문 인덱스 보정	필요	필요 없음	필요 없음	필요 없음
짝수 크기 지원	지원	미지원	지원	지원
직사각형(N×M) 확장	가능	불가능	가능	가능
방향 개수 확장(8방향 등)	어려움(case 추가)	불가능	어려움	쉬움(배열에 값 추가)
가독성	가장 좋음	낮음	좋음	중간
코딩테스트 표준성	낮음	낮음	높음	중간~높음

시리즈 정리

같은 문제라도 "무엇을 기준으로 다음 칸을 판단하는가"에 따라 코드의 모양이 완전히 달라진다는 걸 이 네 방식을 통해 확인할 수 있었다.

처음 배우는 단계라면 switch 방식으로 시작하는 게 맞다. 방향 전환이라는 개념 자체를 코드 구조로 직접 눈에 보이게 익힐 수 있다.
코딩테스트를 준비한다면 경계값 방식을 표준으로 외워두는 게 가장 범용적이다. 크기·모양에 안 흔들리고, 실제로 이 유형 문제의 정석 풀이로 통한다.
방향이 복잡해지거나(8방향, 불규칙 패턴) 코드량을 최소화하고 싶다면 방향배열 방식이 유리하다.
문제가 홀수 정사각형으로 명확히 고정되어 있고 짧은 코드가 최우선이라면 대칭 축소 방식도 나쁘지 않지만, 범용성은 가장 떨어진다.

결국 "더 좋은 코드"는 상황에 따라 다르다. 지금 풀고 있는 문제의 제약(크기가 고정인지, 확장 가능성이 있는지, 누가 이 코드를 다시 읽을지)에 맞춰 방식을 고르는 게 핵심이다.

스파이럴(달팽이) 배열 구현하기 - 경계값(Boundary) 방식

CodingNabi — Wed, 8 Jul 2026 23:50:24 +0900

이번엔 스파이럴 배열 문제의 "정석" 풀이로 통하는 경계값 방식을 정리한다. 코딩테스트에서 스파이럴/나선 행렬 문제가 나오면 가장 먼저 떠올려야 하는 접근이다.

방식 설명

핵심 아이디어는 앞선 두 방식과 또 다르다. 배열 값이 채워졌는지(0인지) 보는 대신, 네 방향의 한계선(top, bottom, left, right)을 숫자로 직접 관리한다. 한 방향을 채우면 그 방향의 경계선을 안쪽으로 한칸 좁힌다.

switch 방식이 "배열 값이 0인지"로 다음 칸을 판단했다면, 이 방식은 배열 값을 전혀 들여다보지 않고 오직 숫자 네 개(top, bottom, left, right)만으로 어디까지 채웠는지 판단한다. 그래서 한 바퀴가 끝날 때마다 ++top, --right, --bottom, ++left로 테두리가 정확히 한 칸씩 안쪽으로 좁혀진다.

if (top <= bottom)과 if (left <= right) 체크가 있는 이유는, 홀수 크기 배열에서 정가운데 행/열을 두 번 채우는 실수를 막기 위해서다. 예를 들어 5x5의 마지막 바퀴는 정중앙 칸 하나뿐인데, 이 체크가 없으면 그 칸을 아래쪽 행 채우기와 왼쪽 열 채우기에서 중복으로 건드리게 된다.

void fillSpiralByBoundary(int arr[SIZE][SIZE]) {
	int value = 0;

	int top = 0;
	int bottom = SIZE - 1;
	int left = 0;
	int right = SIZE - 1;

	while (top <= bottom && left <= right) {
		for (int x = left; x <= right; x++) {
			arr[top][x] = ++value;
		}
		++top;

		for (int y = top; y <= bottom; y++) {
			arr[y][right] = ++value;
		}
		--right;

		if (top <= bottom) {
			for (int x = right; x >= left; x--) {
				arr[bottom][x] = ++value;
			}
			--bottom;
		}

		if (left <= right) {
			for (int y = bottom; y >= top; y--) {
				arr[y][left] = ++value;
			}
			++left;
		}
	}

}

그림

과정

5x5 기준으로 top, bottom, left, right가 어떻게 좁혀지는지 단계별로 추적하면 이렇다.

[1바퀴] top=0, bottom=4, left=0, right=4

위쪽 행 (x: 0→4)   : arr[0][0..4] = 1,2,3,4,5        → ++top (top=1)
오른쪽 열 (y: 1→4) : arr[1..4][4] = 6,7,8,9           → --right (right=3)
아래쪽 행 (x: 3→0) : arr[4][3..0] = 10,11,12,13       → --bottom (bottom=3)
왼쪽 열 (y: 3→1)   : arr[3..1][0] = 14,15,16          → ++left (left=1)

[2바퀴] top=1, bottom=3, left=1, right=3

위쪽 행 (x: 1→3)   : arr[1][1..3] = 17,18,19          → ++top (top=2)
오른쪽 열 (y: 2→3) : arr[2..3][3] = 20,21              → --right (right=2)
아래쪽 행 (x: 2→1) : arr[3][2..1] = 22,23              → --bottom (bottom=2)
왼쪽 열 (y: 2→2)   : arr[2][1] = 24                    → ++left (left=2)

[3바퀴] top=2, bottom=2, left=2, right=2

위쪽 행 (x: 2→2)   : arr[2][2] = 25                    → ++top (top=3)
오른쪽 열           : top(3) > bottom(2)라 for문 자체가 안 돎
--right (right=1)
if (top<=bottom) → 3<=2 거짓 → 아래쪽 행 스킵
if (left<=right) → 2<=1 거짓 → 왼쪽 열 스킵

while (top<=bottom) → 3<=2 거짓 → 종료

결과는 switch 방식, 답지 방식과 완전히 동일한 스파이럴이다. 다만 이번엔 한 바퀴(ring) 단위로 안쪽까지 몇 겹인지를 기준으로 색을 나눠 봤다.

바깥쪽 테두리(1바퀴, 값 1~16)가 가장 넓고, 그 안쪽 테두리(2바퀴, 값 17~24)가 한 겹 좁고, 정중앙(3바퀴, 값 25)이 마지막이다. 5x5는 딱 3겹으로 끝난다.

특징 분석

장점

배열 값에 전혀 의존하지 않는다 : switch 방식이나 방향배열 방식은 "0인지 아닌지"로 다음 칸을 판단하지만, 이 방식은 오직 경계값 숫자만으로 판단한다. 그래서 배열에 어떤 값이 들어가든(심지어 0이 포함된 값이든) 로직이 안전하다.
for문 인덱스 보정이 필요 없다 : switch 방식은 for문이 끝난 뒤 --x, ++y로 되돌리는 보정이 필요했지만, 이 방식은 for (x = left; x <= right; x++)처럼 범위(<=)가 정확히 맞아떨어져서 별도 보정이 없다.
홀수/짝수 크기 모두 자연스럽게 지원한다 : if (top <= bottom), if (left <= right) 체크가 중앙 칸 중복 채움을 막아주기 때문에, SIZE가 짝수든 홀수든 코드 수정 없이 그대로 동작한다.
직사각형(N×M)으로 쉽게 확장된다 : top/bottom과 left/right이 애초에 가로세로를 독립적으로 관리하므로, 초기값만 가로/세로 크기에 맞게 따로 잡으면 정사각형이 아니어도 그대로 동작한다.
코딩테스트의 표준 풀이다 : 스파이럴/나선 행렬 문제가 나왔을 때 면접관이나 채점 기준이 기대하는 방식이 보통 이거다.

단점

경계 변수 4개(top, bottom, left, right)를 동시에 관리해야 해서, 처음 볼 때는 switch 방식보다 변수 흐름 파악에 시간이 좀 더 걸릴 수 있다.
if (top <= bottom), if (left <= right) 체크의 의미(중앙 칸 중복 방지)를 모르면, 이 두 줄이 왜 있는지 이해하기 어렵다.

정리

경계값 방식은 switch 방식의 장점(배열 크기·모양에 안 흔들리는 확장성)과 대칭 축소 방식의 장점(인덱스 보정 없이 깔끔함)을 동시에 가져간 형태에 가깝다. 그래서 코딩테스트나 실무에서 "스파이럴 행렬을 채워라" 같은 문제가 나오면, 이 경계값 방식을 표준 풀이로 익혀두는 게 가장 범용적이다.

스파이럴(달팽이) 배열 구현하기 - 대칭 축소(nLength) 방식

CodingNabi — Wed, 8 Jul 2026 23:29:58 +0900

앞서 설명한 문제의 교재 답지에 있던 방식이다.

문제 정의

5x5 정수 배열을 아래처럼 시계방향 나선형으로 1부터 25까지 채우는 게 목표다.

1   2   3   4    5
16  17  18  19   6
15  24  25  20   7
14  23  22  21   8
13  12  11  10   9

방식 설명

핵심 아이디어는 한 바퀴를 위쪽/오른쪽 + 아래쪽/왼쪽 두 구간으로 쪼개서, 같은 부호(nDirecton)로 x와 y를 순서대로 움직인다. 한라운드가 끝나면 부호를 뒤집고, 다음 루프는 테두리 한 칸 안쪽(nLength -= 2)에서 반복한다.

nLength는5x5배열 기준 9에서 시작해 2씩 줄어들며 9,7,5,3,1, 다섯 라운드를 수행한다.

안쪽 for문은 매 바퀴 nLength를 반복하는데, 앞쪽 절반(위 or 아래)은 i < nLength/2 +1

void fillSpiralBySymmetry(int arr[SIZE][SIZE]) {
	int x = -1;
	int y = 0;
	int nCounter = 0;
	int i = 0;
	int j = 0;
	int nLength = 9;
	int nDirection = 1;

	for (nLength; nLength > 0; nLength -= 2) {
		for (i = 0; i < nLength; ++i) {
			if (i < nLength / 2 + 1)
				x += nDirection;
			else
				y += nDirection;
			arr[y][x] = ++nCounter;
		}

		nDirection = -nDirection;
	}
}

그림

과정

nLength = 9 첫 바퀴부터 손으로 추적하면 이렇다. (half = nLength/2 + 1)

nLength=9, nDirection=+1, half=5, 시작 x=-1, y=0

i=0~4 (x 이동, i<5)   : x=0,1,2,3,4 → arr[0][0..4] = 1,2,3,4,5
i=5~8 (y 이동, i>=5)  : y=1,2,3,4   → arr[1..4][4] = 6,7,8,9

바퀴 종료 후 nDirection = -1

nLength=7, nDirection=-1, half=4, 시작 x=4, y=4

i=0~3 (x 이동)  : x=3,2,1,0     → arr[4][3..0] = 10,11,12,13
i=4~6 (y 이동)  : y=3,2,1       → arr[3..1][0] = 14,15,16

바퀴 종료 후 nDirection = +1

nLength=5, nDirection=+1, half=3, 시작 x=0, y=1

i=0~2 (x 이동)  : x=1,2,3       → arr[1][1..3] = 17,18,19
i=3~4 (y 이동)  : y=2,3         → arr[2..3][3] = 20,21

바퀴 종료 후 nDirection = -1

nLength=3, nDirection=-1, half=2, 시작 x=3, y=3

i=0~1 (x 이동)  : x=2,1         → arr[3][2..1] = 22,23
i=2 (y 이동)    : y=2           → arr[2][1] = 24

바퀴 종료 후 nDirection = +1

nLength=1, nDirection=+1, half=1, 시작 x=1, y=2

i=0 (x 이동)    : x=2           → arr[2][2] = 25

25에서 정확히 끝나고, 결과는 switch 방식과 완전히 동일한 스파이럴이 나온다.

바퀴가 진행되며 nLength가 어떻게 안쪽으로 좁혀지는지는 아래 그림으로 표현했다.

각 사각형 테두리가 한 바퀴(nLength 값 하나)에 해당하고, 바깥쪽부터 안쪽으로 9 → 7 → 5 → 3 → 1 순서로 좁혀 들어간다. 색이 짙어질수록 나중 바퀴, 즉 배열 중심에 가까운 바퀴다.

특징 분석

장점

-코드가 압도적으로 짧다 : switch 방식은 case 4개 + 인덱스 보정이 필요했지만, 이 방식은 이중 for문 하나로 전체 로직이 끝난다.

-바퀴 수만큼만 바깥 루프가 돈다 : switch 방식은 while 하나 안에서 25번(칸 수만큼) 전체 루프를 도는 반면, 이 방식은 바깥 for문이 5번(바퀴 수만큼)만 돈다.

단점

-홀수 정사각형 전용이다 : nLength = 2*SIZE - 1로 시작해서 2씩 줄어드는 구조 자체가 홀수 크기를 전제로 짜여 있다. SIZE가 짝수면 nLength가 0에서 딱 안 떨어지거나 마지막 바퀴 처리가 어긋나서, 이 로직 자체를 다시 설계해야 한다.

-직사각형(N×M)으로 확장이 안 된다 : nLength 하나로 가로/세로를 동시에 표현하는 구조라서, 가로세로 크기가 다른 배열에는 이 방식이 아예 성립하지 않는다.

-가독성이 낮다 : i < nLength/2 + 1이라는 조건만 보고 "아, 절반까지는 x를 움직이고 나머지는 y를 움직이는구나"를 바로 알아채기 어렵다. 처음 보는 사람은 손으로 트레이스를 돌려봐야 이해된다.

-변형이 어렵다 : 예를 들어 반시계방향으로 바꾸거나 사각형이 아닌 패턴으로 확장하려면, 이 압축된 구조 자체를 뜯어고쳐야 한다. switch 방식처럼 case 순서만 바꾸는 식의 손쉬운 변형이 안 된다.

정리

대칭 축소 방식은 "짧고 영리한 코드"의 전형이다. 문제를 홀수 정사각형이라는 좁은 범위로 한정하는 대신, 그 안에서 대칭성을 최대한 활용해 코드량을 확 줄인 것이다.

스파이럴(달팽이) 배열 구현하기 - switch/case 방향 전환 방식

CodingNabi — Wed, 8 Jul 2026 19:39:20 +0900

C로 5x5 스파이럴 배열을 채우는 문제를 여러 방식으로 구현해보면서, 각 방식의 원리와 장단점을 정리해본다. 첫 번째로 다룰 방식은 switch문으로 방향을 관리하는 방식이다.(처음 문제를 보고 내가 푼 방식이라 많이 와일드 하다. 나머지 3개는 교재참고, 다른 자료를 참고한 방식이다.)

문제 정의

5x5 정수 배열을 아래처럼 시계방향 나선형으로 1부터 25까지 채우는 게 목표다.

1   2   3   4    5
16  17  18  19   6
15  24  25  20   7
14  23  22  21   8
13  12  11  10   9

방식 설명

핵심 아이디어는 간단하다. 한 방향으로 갈 수 있는 데까지 가고, 막히면(이미 채워진 칸을 만나면) 다음 방향으로 90도 회전한다.

방향은 4가지뿐이므로 enu으로 정의하고, switch로 지금 어느 방향으로 가는 중인지를 분기한다.

각 방향은 for 문 하나로 표현되고, 방향이 바뀔때마다 changeFlag를 다음 방향으로 갱신한다.

이미 채워진 초깃값이 0이라는 점을 이용해 arr[y][x] == 0으로 값을 채울지, 아니면 루프를 종료하고 다음 분기로 넘어갈지 판단한다.

void fillSpiralBySwitch(int arr[SIZE][SIZE]) {
	enum {
		GORIGHT,
		DOWN,
		GOLEFT,
		UP
	};

	int changeFlag = GORIGHT;
	int value = 0;
	int x = 0;
	int y = 0;
	while (value < SIZE * SIZE) {
		switch (changeFlag) {
		case GORIGHT: {
			for (x; x < SIZE && y >= 0 && y < SIZE; x++) {
				if (arr[y][x] == 0)
					arr[y][x] = ++value;
				else
					break;
			}
			--x;
			++y;
			changeFlag = DOWN;
			break;
		}
		case DOWN: {
			for (y; x >= 0 && x < SIZE && y < SIZE; y++) {
				if (arr[y][x] == 0)
					arr[y][x] = ++value;
				else
					break;
			}
			--y;
			--x;
			changeFlag = GOLEFT;
			break;
		}
		case GOLEFT: {
			for (x; x >= 0 && y >= 0 && y < SIZE; x--) {
				if (arr[y][x] == 0)
					arr[y][x] = ++value;
				else
					break;
			}
			++x;
			--y;
			changeFlag = UP;
			break;
		}
		case UP: {
			for (y; y >= 0 && x >= 0 && x < SIZE; y--) {
				if (arr[y][x] == 0)
					arr[y][x] = ++value;
				else
					break;
			}
			++y;
			++x;
			changeFlag = GORIGHT;
			break;
		}
		}
	}
}

그림

과정

1단계 GORIGHT : (0,0) → (1,0) → (2,0) → (3,0) → (4,0)     [1~5 채움]
                                                     for 종료 시 x=5, 보정 --x → x=4
                                                     ++y → y=1
                                                     changeFlag = DOWN

2단계 DOWN    : (4,1) → (4,2) → (4,3) → (4,4)             [6~9 채움]
                                                     for 종료 시 y=5, 보정 --y → y=4
                                                     --x → x=3
                                                     changeFlag = GOLEFT

3단계 GOLEFT  : (3,4) → (2,4) → (1,4) → (0,4)             [10~13 채움]
                                                     for 종료 시 x=-1, 보정 ++x → x=0
                                                     --y → y=3
                                                     changeFlag = UP

4단계 UP      : (0,3) → (0,2) → (0,1)                     [14~16 채움]
                (0,0)은 이미 채워져 있어 break
                                                     for 종료 시 y=0, 보정 ++y → y=1
                                                     ++x → x=1
                                                     changeFlag = GORIGHT

5단계 GORIGHT : (1,1) → (2,1) → (3,1)                     [17~19 채움]
                (4,1)은 이미 채워져 있어 break
                ... (이하 반복, 안쪽으로 계속 좁혀짐)

특징

장점

- 가독성이 나쁘지 않다 : 어느 방향으로 가는지 코드 구조에 드러난다. case만 따라가다 보면 로직 전체를 이해할 수 있다.

- 디버깅 용이 : 방향별로 로직이 분리되어 있어, 특정 방향에서 생기는 문제가 생기면 그 case만 보면 된다.

- 홀수/짝수 크기 지원 : 이미 채워진 칸인지를 값으로 직접 판단하기 때문에, 배열 크기의 홀짝 여부에 로직이 의존하지 않는다.

- 직사각형 확장이 비교적 쉽다 : x, y의 이동 범위가 이미 분리되어 있어서 가로세로 크기를 다르게 둬도 구조 자체는 크게 바뀌지 않는다.

단점

- 코드가 길다 : 방향이 4개면 case도 4개, 로직도 4개가 필요하다.

- for문에 인덱스 보정이 필요하다 : 각 방향의 for문이 조건을 만족하지 못하는 시점(예: x == SIZE)에 끝나기 때문에, case 끝마다 x,y값을 보정하는 보정 코드가 따라붙는다.

- 배열 값에 의존한다 : "0이면 채워지지 않은 칸"이라는 전제로 동작하기 때문에, 채우는 값 자체가 0이거나, 이미 채워진 값을 다시 채우는 경우 동작하지 않는다.

선택정렬

CodingNabi — Tue, 7 Jul 2026 18:05:55 +0900

선택정렬의 특징

1. 최솟값 선택 기반 정렬

인접한 두 원소만 비교하는 버블 정렬과 다르게, 매 라운드마다 남은 범위 전체를 훑어서 최솟값의 위치를 먼저 찾고, 그 다음에 현재 위치와 딱 한 번만 교환하는 방식이다. 비교는 멀리 떨어진 원소끼리도 하지만, 교환은 매 라운드당 최대 한 번 일어난다.

2. 시간 복잡도

바깥 루프가 n번 돌고, 안쪽 루프(최솟값 탐색)는 바깥 루프가 진행될수록 반복 횟수가 점점 줄어들어(n,n-1,n-2,...,1) 총 비교 횟수는 버블 정렬과 똑같이 등차수열의 합 공식에 의해 n(n-1)/2번이 된다. 빅오 표기법으로는 O(n²)이다. 다만 버블정렬과 결정적으로 다른 점은, 배열이 이미 정렬되어 있어도, 안쪽 루프를 끝까지 다 돌아야 최솟값 위치를 확신할 수 있어서 최선의 경우에도 O(n²)로 줄어들지 않는다는 것이다.

3.불안정 정렬이다.

값이 같은 두 원소가 있을 때, 최솟값을 찾아 먼 위치와 통째로 자리를 밥꾸는 과정에서 원래 순서가 뒤바뀔 수 있다.

4.제자리 정렬이다.

추가 배열이나 메모리 공간이 거의 필요없다. temp변수 하나로 교환만 하면 되니까 공간복잡도는 O(1)이다.

5. 실전성

실전성은 버블정렬보단 낫지만, 여전히 낮다. 같은 O(n²) 계열에선 삽입 정렬이 대부분의 경우 더 빠르지만, 선택 정렬은 교환(swap) 횟수가 라운드당 1번, 전체 최대로도 n-1번으로 압도적으로 적다는 장점이 있다. 그러나 큰 데이터셋에는 여전히 O(n log n)인 다른 정렬법을 사용한다.

6. 플래그

앞서 나는 버블정렬에서 플래그를 이용하여 루프 횟수를 줄이는 방식을 사용했다. 그러나 선택정렬에서는 이 방식을 사용할 수 없다. 그 이유는 "정렬이 끝났다는 확신"을 얻는 방식 자체가 다르기 때문이다.

버블정렬은 한 바퀴 돌면서 인접한 칸끼리 비교하며 스왑한다. 따라서 한 바퀴에서 스왑이 한 번도 발생하지 않았다는 것은, 그 자체로 이미 배열이 정렬되어 있다는 것을 증명해준다.

반면 선택정렬은 i번째부터 끝까지 중에서 최솟값의 위치를 찾는 과정이다. 이 최솟값이 진짜 최솟값인지 확신하려면, 남은 원소를 전부 다 비교해봐야만 한다. 배열이 이미 정렬되어 있어도 선택정렬 입장에서는 그 사실을 모르기 때문에, 매 라운드마다 마지막 칸까지 비교를 마쳐야만 "이게 최솟값이 맞다"는 확신을 얻을 수 있다. 그래서 이전 라운드에서 값이 갱신되지 않았다는 사실이, 다음 라운드의 비교를 생략할 근거가 되지 못한다.

정렬 과정

작성한 코드

#include <stdio.h>

int main() {
	int aList[5] = { 30, 40, 10, 50, 20 };
	int aListSize = sizeof(aList) / sizeof(int);
	int rotationCount = 0;

	for (int i = 0; i < aListSize; i++) {
		int temp = 0;
		int nMinIndex = i;
		for (int j = i; j < aListSize; j++) {
			if (aList[nMinIndex] > aList[j]) {
				nMinIndex = j; 
			}
		}
		temp = aList[i];
		aList[i] = aList[nMinIndex];
		aList[nMinIndex] = temp;
		++rotationCount;
	}

	for (int i = 0; i < aListSize; i++) {
		printf("%d\t", aList[i]);
	}
	printf("\nRotation Count : %d", rotationCount);

	return 0;
}

우리는 왜 UTF-8을 써야 하는가

CodingNabi — Tue, 7 Jul 2026 15:20:48 +0900

*아래 글은 Claude AI가 저와 대화하면서 나눈 내용을 정리한 것입니다. 결론은 제가 정리하였고, 최대한 공식 문서만을 반영하려고 하였습니다. 참고 자료는 글의 마지막에 정리하여 두었습니다. 부족한 부분이 있다면 지적해주시면 감사하겠습니다.

Windows에서 C/C++로 콘솔 프로그램을 짜본 사람이라면 한 번쯤 겪어봤을 것이다. 분명 소스 코드에는 멀쩡하게 한글을 입력했는데, 컴파일 시점에 알 수 없는 경고가 뜨거나, 실행했을 때 콘솔 화면에 글자가 물음표나 깨진 문자로 출력되는 현상 말이다. 이 글에서는 이 현상이 왜 발생하는지, 그리고 표준 문서와 실제 업계가 어떤 방향을 가리키고 있는지를 정리한다.

1. 인코딩 방식 정리: UTF-8, BOM, CP949, UTF-16

문자를 컴퓨터에 저장하려면 결국 "이 글자를 몇 바이트로, 어떤 규칙으로 표현할 것인가"를 정해야 한다. 이 규칙을 인코딩(encoding)이라고 부른다.

UTF-8

유니코드 문자를 1바이트에서 4바이트 사이의 가변 길이로 표현하는 인코딩이다. 영문/숫자(ASCII 범위)는 1바이트로 그대로 표현되고, 한글 같은 non-ASCII 문자는 3바이트로 표현된다. 예를 들어 "안"이라는 글자는 UTF-8에서 EC 95 88 세 바이트로 저장된다. 현재 웹, 대부분의 운영체제, 대부분의 프로그래밍 언어에서 사실상 표준으로 자리 잡은 인코딩이다.

BOM (Byte Order Mark)

BOM은 파일 맨 앞에 붙는 특수한 바이트 시퀀스로, UTF-8의 경우 EF BB BF 세 바이트가 여기에 해당한다. 이 바이트를 유니코드로 디코딩하면 U+FEFF(ZERO WIDTH NO-BREAK SPACE)라는 문자 코드가 되는데, 이 문자를 파일 맨 앞에 실제 텍스트의 일부로 남겨두지 않고 "이 파일이 무슨 인코딩인지 알려주는 신호"로만 쓰겠다는 것이 BOM의 개념이다.

BOM의 원래 목적은 UTF-16처럼 한 글자를 여러 바이트로 표현하면서 바이트 순서(리틀엔디안/빅엔디안)가 모호해질 수 있는 인코딩에서, 그 순서를 알려주는 것이다. UTF-8은 한 바이트씩 순서대로 쌓아나가는 방식이라 바이트 순서 문제 자체가 없다. 그래서 유니코드 표준 원문(Unicode Standard, 2.6절 "Encoding Schemes")은 다음과 같이 명시한다.

"Use of a BOM is neither required nor recommended for UTF-8" (BOM 사용은 UTF-8에서 필수도 아니고 권장되지도 않는다)

다만 이 문장의 해석을 두고는 유니코드 컨소시엄 내부에서도 이견이 있었다. 2021년 유니코드 기술위원회에 제출된 문서(L2/21-038)는, 이 문장이 "BOM 사용에 반대하는 권고"로 읽히기도 하고 "찬성도 반대도 아닌 무입장"으로 읽히기도 한다는 점을 스스로 지적하며 문구의 모호함을 인정한 바 있다. 즉 "BOM을 쓰지 마라"는 강한 금지라기보다는, "굳이 필요하지 않으니 기본값으로 삼지는 말라"는 정도의 방향성으로 이해하는 편이 정확하다.

한편, 이 문제를 실무적으로 다뤄온 한 개발자의 글(Manski's Dev Log, "UTF-8 and BOM")은 다음과 같은 절충안을 제시한다. 평상시 파일은 BOM 없는 UTF-8을 기본으로 하되, 최종 사용자에게 노출되는 텍스트가 포함된 코드 파일이나 리소스 파일에 한해서는 인코딩 오류(이상한 문자 출력)를 막기 위해 BOM이 있는 UTF-8로 저장하라는 것이다. 이 절충안은 뒤에서 다룰 우리의 실제 상황(콘솔에 한글을 직접 출력하는 소스 파일)에 정확히 들어맞는 조언이기도 하다.

CP949 (한국어 Windows 기본 코드페이지)

CP949는 한글을 2바이트로 표현하는 완성형 인코딩으로, EUC-KR을 확장한 한국어 Windows의 기본 코드페이지다. 예를 들어 "안"이라는 글자는 CP949에서 B0 C8 두 바이트로 저장된다. UTF-8과는 완전히 다른 바이트 체계이며, 한국어 Windows에서만 통용되는 지역화된 인코딩이다.

UTF-16

한 글자를 기본적으로 2바이트로 표현하는 인코딩으로, Windows 내부(NT 커널)와 C#의 string, C++의 wchar_t 등에서 사용된다. UTF-8과는 바이트 구조 자체가 다르기 때문에, 두 인코딩 사이를 오갈 때는 반드시 변환 과정을 거쳐야 한다. BOM이 있다고 해서 UTF-8과 UTF-16이 서로 호환되는 것은 아니다. BOM은 그저 "이 파일이 셋 중 무엇인지"를 알려주는 라벨일 뿐, 인코딩 간 변환을 대신해주지 않는다.

2. 어디서, 왜 글자가 깨지는가

한글이 깨지는 현상은 하나의 원인이 아니라, 아래와 같은 파이프라인의 여러 단계에서 발생할 수 있다.

[.cpp 소스 파일]  →  [컴파일러가 소스를 읽음]  →  [실행 파일(.exe) 생성]  →  [콘솔이 출력을 해석]

1단계: 소스 파일을 컴파일러가 잘못 해석하는 경우

MSVC 컴파일러는 소스 파일 맨 앞에 BOM이 있는지를 확인해, BOM이 있으면 해당 인코딩으로 정확히 읽고, 없으면 시스템 코드페이지(한국어 Windows에서는 CP949)로 간주해버린다. 이는 Microsoft 공식 문서에도 명시되어 있다.

"By default, Visual Studio detects a byte-order mark... If no byte-order mark is found, it assumes that the source file is encoded in the current user code page, unless you've specified a code page by using /utf-8 or the /source-charset option." (출처: Microsoft Learn, /utf-8 컴파일러 옵션 문서)

만약 실제 파일이 BOM 없는 UTF-8로 저장되어 있다면, 컴파일러는 이를 CP949로 잘못 해석한다. 이때 한글을 표현하는 UTF-8 멀티바이트 시퀀스가 우연히 개행 문자와 비슷한 바이트 조합으로 해석되면서, 문자열 리터럴이 예상치 못한 곳에서 끊기는 등 실제 컴파일 오류(C2001, C2143 등)로 이어지기도 한다. 이 경고는 C4819("현재 코드 페이지에서 표시할 수 없는 문자")로 나타나는데, 이는 경고일 뿐이라 빌드 자체는 통과하는 경우가 많다. 다만 빌드가 통과했다는 것이 인코딩이 올바르다는 뜻은 아니며, 실제로는 손상된 문자열이 실행 파일에 그대로 저장된다.

2단계: 실행 파일에 문자열이 저장되는 방식

컴파일러가 소스를 정확히 읽었다 하더라도, 그 문자열을 실행 파일 안에 저장할 때 어떤 인코딩으로 저장할지(실행 문자집합, execution charset)는 별개의 문제다. MSVC는 별도 옵션이 없으면 기본적으로 narrow 문자열(char*)을 시스템 코드페이지로 변환해 저장한다. 이는 1990년대 Windows API가 설계될 때부터 이어진 하위 호환성 정책이다.

3단계: 콘솔이 출력을 해석하는 방식

콘솔(cmd.exe)은 자신만의 기본 코드페이지를 갖고 있으며, 한국어 Windows에서는 이 값이 기본적으로 CP949다. 실행 파일 안에 저장된 문자열의 인코딩과 콘솔이 그것을 해석하는 방식이 일치해야만 화면에 정상적으로 출력된다. 즉 다음 네 가지 조합 중 인코딩이 서로 일치하는 경우에만 정상 출력이 가능하다.

실행 파일 안 문자열 콘솔의 해석 방식 결과

CP949	CP949	정상
UTF-8	UTF-8	정상
CP949	UTF-8	깨짐
UTF-8	CP949	깨짐

지금까지 실무에서 쓰여 온 BOM, /utf-8 컴파일러 옵션, SetConsoleOutputCP, 시스템 로캘의 UTF-8 설정은 모두 이 "인코딩"과 "디코딩" 단계를 서로 일치시키기 위한 각기 다른 수단일 뿐이다.

3. 표준 문서와 업계의 실제 관행

유니코드 표준과 C++ 표준위원회

유니코드 표준은 UTF-8을 텍스트 교환의 사실상 표준으로 삼으면서도, BOM에 대해서는 앞서 살펴본 것처럼 다소 모호한 태도("필수도 권장도 아니다")를 취하고 있다.

C++ 표준위원회(WG21)가 제출한 UTF-8 소스 인코딩 지원 제안서(P2295R3)는 이 지점을 조금 더 명확히 한다. 이 문서는 BOM이 파일에 존재하더라도 그것을 실제 텍스트 콘텐츠로 취급해서는 안 되며(무시되어야 하며), 다만 MSVC처럼 BOM을 UTF-8 감지 수단으로 활용하는 구현 방식도 유효하다고 인정한다. 여기서 "무시되어야 한다"는 것은 "BOM을 쓰지 말라"는 뜻이 아니라, "파일을 읽는 도구가 BOM을 감지에는 활용하되, 그 바이트 자체를 실제 콘텐츠의 일부(눈에 보이지 않는 유령 문자)로 남겨서는 안 된다"는, 도구 구현자를 향한 요구사항에 가깝다. 표준위원회는 BOM 사용 자체를 강제하지도 금지하지도 않는 입장을 취하되, 모든 C++ 컴파일러가 UTF-8 소스 파일을 최소한 지원해야 한다는 방향으로 논의를 진행하고 있다.

대형 오픈소스 프로젝트의 실제 관행

구글 C++ 스타일 가이드(공식 문서, google.github.io/styleguide): 소스 코드에 non-ASCII 문자가 필요한 경우 UTF-8 형식을 사용하도록 명시하고 있다.
Clang 컴파일러의 동작 방식: Clang은 소스 파일을 항상 UTF-8로 가정하며, BOM 유무와 무관하게 이 원칙을 고수하는 것으로 알려져 있다. 이 설명은 Clang 공식 문서가 아니라, 이를 분석한 제3자 기술 블로그(Nutrient.io, "String Literals, Character Encodings, and Multiplatform C++")를 참고했다. 실행 문자집합 변환 역시 UTF-8을 기준으로 처리되어, MSVC와 같은 레거시 코드페이지 변환 단계가 없다는 점도 이 글에서 확인할 수 있다.
개별 프로젝트의 실무 절충안: 한 개발자가 자신의 프로젝트에 채택한 정책(Manski's Dev Log, "UTF-8 and BOM")을 보면, 기본은 BOM 없는 UTF-8로 하되, 컴파일러/인터프리터가 BOM 없이도 UTF-8을 기본으로 가정하는 환경에서는 이 원칙이 무리 없이 성립하고, 최종 사용자에게 직접 노출되는 텍스트가 포함된 파일에는 예외적으로 BOM을 허용해 인코딩 오류를 막는 방식을 취하고 있다. 이는 LLVM이나 특정 대형 프로젝트의 공식 정책이 아니라 한 개인 프로젝트의 사례이지만, 실무에서 통용되는 절충 논리를 잘 보여준다.

Microsoft 공식 문서의 입장

Microsoft는 /utf-8 컴파일러 옵션을 공식 문서에서 안내하며, 기본적으로 BOM이 없으면 소스 파일을 현재 사용자 코드 페이지로 가정한다는 점, 그리고 /utf-8 옵션으로 이를 UTF-8로 고정할 수 있다는 점을 명시하고 있다(Microsoft Learn, /utf-8(원본 및 실행 문자 집합을 UTF-8로 설정) 문서). 아울러 Windows 10 버전 1903부터는 애플리케이션 매니페스트에 activeCodePage를 UTF-8로 지정해, 프로세스 전체의 기본 코드페이지 자체를 UTF-8로 고정하는 방법도 공식적으로 제공하고 있다(Microsoft Learn, "Windows 앱에서 UTF-8 코드 페이지 사용" 문서).

정리

표준 문서와 업계 사례를 종합하면 방향은 비교적 뚜렷하다. 인코딩은 UTF-8을 쓰는 것이 사실상 이견 없는 정석이며, BOM에 대해서는 유니코드 표준 자체가 명확히 "쓰지 말라"고 강하게 못박고 있다기보다는 "굳이 필요하지 않다"는 쪽에 무게를 두고 있고, 실무에서는 도구의 특성에 따라 예외적으로 BOM을 허용하는 절충안이 흔히 쓰인다. Windows/MSVC 환경에서 BOM이 여전히 실질적으로 쓰이는 것은, 표준을 어기는 것이라기보다 MSVC라는 특정 도구가 BOM 없이는 UTF-8을 기본으로 가정하지 않는다는 특수한 사정에서 비롯된 실용적 선택에 가깝다.

4. 그래서 우리는 어떻게 설정해야 하는가

결론적으로, 오늘날 권장되는 조합은 다음과 같다.

소스 파일:     BOM 없는 UTF-8로 저장 (또는 BOM 있는 UTF-8도 무방)
프로젝트 설정:  /utf-8 컴파일러 옵션 추가
콘솔 출력이 필요한 경우: SetConsoleOutputCP(CP_UTF8) 추가

Visual Studio 설정 방법

1) 프로젝트에 /utf-8 옵션 추가

프로젝트 우클릭 → 속성 → 구성 속성 → C/C++ → 명령줄 → 추가 옵션
→ /utf-8 입력

이 옵션 하나로 소스 문자집합과 실행 문자집합이 모두 UTF-8로 고정된다. BOM 유무와 무관하게 소스를 정확히 UTF-8로 인식하게 되므로, 파일마다 저장 방식을 신경 쓸 필요가 없어진다. 즉 /utf-8을 걸어두면, MSVC 역시 "BOM 없이도 UTF-8을 기본으로 가정하는" 환경이 되어, 앞서 살펴본 절충안의 전제 조건을 스스로 만족시키게 된다.

2) 콘솔 출력 코드 추가

#include <stdio.h>
#include <Windows.h>

int main() {
    SetConsoleOutputCP(CP_UTF8);
    printf("안녕하세요.");
    return 0;
}

/utf-8을 적용하면 실행 파일 안 문자열이 UTF-8로 유지되는데, 콘솔의 기본 코드페이지는 여전히 CP949이므로 이 한 줄이 없으면 콘솔에서 다시 깨진다. SetConsoleOutputCP는 해당 콘솔 창 전체의 설정을 바꾸는 것이므로, 필요하다면 프로그램 종료 전에 GetConsoleOutputCP()로 저장해둔 원래 값으로 복구해주는 것이 매너 있는 방식이다.

그럼에도 BOM이 여전히 유효한 경우

/utf-8 옵션을 걸 수 없거나, 프로젝트 전역 설정을 건드리기 어려운 상황(예: 파일 하나만 급하게 고쳐야 하는 경우)이라면, 앞서 소개한 절충안처럼 최종 사용자에게 직접 보이는 텍스트가 담긴 파일에 한해 BOM을 붙이는 것도 실무적으로 유효한 선택이다. 다만 이 경우 실행 파일 안 문자열이 시스템 코드페이지(CP949)로 변환되어 저장된다는 점을 유의해야 한다. 콘솔 출력만 놓고 보면 문제가 없지만, 네트워크로 들어오는 UTF-8 데이터(예: 채팅 메시지)와 소스에 적어놓은 한글 리터럴을 비교하는 로직에서는 두 값이 서로 다른 바이트가 되어 비교 자체가 실패한다. 콘솔에 보기 좋게 출력되는 것과 실제 데이터 처리 로직이 올바르게 동작하는 것은 별개의 문제이며, 후자를 보장하려면 BOM만으로는 부족하고 반드시 /utf-8이 필요하다.

결론

결국 이 모든 논의를 한 문장으로 요약하자면 글자가 깨지는 것은 "인코딩"과 "디코딩"이라는 두 단계가 서로 어긋났기 때문이며, 이를 막는 가장 확실한 방법은 소스 파일부터 콘솔 출력까지 모든 계층을 UTF-8 하나로 통일하는 것이다.

다만 이런 상황이 "BOM을 절대 쓰지 말라"는 의미는 아니다. 표준이 가리키는 방향은 "새 파일을 만들 때는 BOM 없는 UTF-8을 기본으로 하되, BOM이 붙은 파일을 만나더라도 도구가 오작동 없이 처리할 수 있어야 한다"는 것이고, 개인 학습이나 콘솔 출력 정도의 목적이라면 BOM을 쓰는 것도 여전히 실용적인 선택이다. 다만 네트워크로 들어오는 UTF-8 데이터와 소스 코드의 문자열을 직접 비교해야 하는 순간부터는, BOM만으로는 부족하고 반드시 /utf-8처럼 실행 문자집합까지 UTF-8로 고정하는 설정이 필요해진다.

참고 자료

Google C++ Style Guide — https://google.github.io/styleguide/cppguide.html
- 해당 자료의 Non-ASCII부분에서 참고하였습니다.
ISO/IEC JTC1/SC22/WG21, P2295R3 "Support for UTF-8 as a portable source file encoding" — https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2295r3.pdf
- PDF 안에서 "BOM" 검색 -> 해당 부분 참고
Unicode Technical Committee, L2/21-038 "Clarify guidance for use of a BOM as a UTF-8 encoding signature" — https://www.unicode.org/L2/L2021/21038-bom-guidance.pdf
- - PDF 첫 페이지 도입부, "Unicode 13, in the 'Byte Order' subsection of section 원문 인
Wikipedia, "Byte order mark" — https://en.wikipedia.org/wiki/Byte_order_mark
- 문서 내 "UTF-8" 소제목에서 참
Microsoft Learn, /utf-8(원본 및 실행 문자 집합을 UTF-8로 설정) — https://learn.microsoft.com/ko-kr/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8
- 페이지 상단, "설명(Remarks)" 또는 본문 도입부에서 참고
Microsoft Learn, "Windows 앱에서 UTF-8 코드 페이지 사용" — https://learn.microsoft.com/ko-kr/windows/apps/design/globalizing/use-utf8-code-page
- UTF-8 코드 페이지" 관련 첫 단락 부분 참
Manski's Dev Log, "UTF-8 and BOM" (개인 프로젝트 사례) — https://manski.net/articles/utf8-bom
Nutrient.io, "String Literals, Character Encodings, and Multiplatform C++" (제3자 기술 블로그) — https://www.nutrient.io/blog/string-literals-character-encodings-and-multiplatform-cpp/

msvc 인코딩 옵션 이해 (GitHub Gist) — https://gist.github.com/a9746b9ff99a76582c29ca6f956b219b