본문으로 건너뛰기
Previous
Next
C++ Stack Overflow | '스택 오버플로우' 가이드

C++ Stack Overflow | '스택 오버플로우' 가이드

C++ Stack Overflow | '스택 오버플로우' 가이드

이 글의 핵심

C++ Stack Overflow: "스택 오버플로우" 가이드. Stack Overflow란?·발생 원인.

Stack Overflow란?

스택 메모리 한계를 초과하여 발생하는 오류

func 함수의 구현 예제입니다.

// ❌ 무한 재귀
void func() {
    func();  // 스택 오버플로우
}

// ❌ 큰 지역 변수
void func() {
    int arr[1000000];  // 스택 부족
}

발생 원인

// 1. 무한 재귀
void infiniteRecursion() {
    infiniteRecursion();
}

// 2. 깊은 재귀
int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);  // n이 크면 위험
}

// 3. 큰 지역 변수
void largeArray() {
    int arr[10000000];  // 스택에 너무 큼
}

// 4. 과도한 함수 호출
void a() { b(); }
void b() { c(); }
void c() { d(); }
// ....계속

실전 예시

예시 1: 재귀 제한

#include <iostream>

// ❌ 무한 재귀
int badFactorial(int n) {
    return n * badFactorial(n - 1);  // 종료 조건 없음
}

// ✅ 종료 조건
int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);
}

// ✅ 반복문 사용
int factorialIterative(int n) {
    int result = 1;
    for (int i = 2; i <= n; i++) {
        result *= i;
    }
    return result;
}

int main() {
    std::cout << factorial(10) << std::endl;
    std::cout << factorialIterative(10) << std::endl;
}

예시 2: 큰 배열 처리

#include <vector>
#include <memory>

// ❌ 스택에 큰 배열
void processLargeData() {
    int data[1000000];  // 4MB (위험)
    // 처리
}

// ✅ 힙 할당
void processLargeData() {
    auto data = std::make_unique<int[]>(1000000);
    // 처리
}

// ✅ 벡터 사용
void processLargeData() {
    std::vector<int> data(1000000);
    // 처리
}

예시 3: 꼬리 재귀 최적화

// ❌ 일반 재귀 (스택 누적)
int sum(int n) {
    if (n <= 0) return 0;
    return n + sum(n - 1);
}

// ✅ 꼬리 재귀 (최적화 가능)
int sumTail(int n, int acc = 0) {
    if (n <= 0) return acc;
    return sumTail(n - 1, acc + n);
}

// ✅ 반복문
int sumIterative(int n) {
    int result = 0;
    for (int i = 1; i <= n; i++) {
        result += i;
    }
    return result;
}

int main() {
    std::cout << sumTail(10000) << std::endl;
    std::cout << sumIterative(10000) << std::endl;
}

예시 4: 깊이 제한

#include <iostream>

// 재귀 깊이 제한
const int MAX_DEPTH = 1000;

int fibonacci(int n, int depth = 0) {
    if (depth > MAX_DEPTH) {
        throw std::runtime_error("재귀 깊이 초과");
    }
    
    if (n <= 1) return n;
    return fibonacci(n - 1, depth + 1) + fibonacci(n - 2, depth + 1);
}

// ✅ 메모이제이션
int fibonacciMemo(int n, std::vector<int>& memo) {
    if (n <= 1) return n;
    if (memo[n] != -1) return memo[n];
    
    memo[n] = fibonacciMemo(n - 1, memo) + fibonacciMemo(n - 2, memo);
    return memo[n];
}

int main() {
    std::vector<int> memo(100, -1);
    std::cout << fibonacciMemo(50, memo) << std::endl;
}

스택 크기 확인

#include <iostream>

void checkStackSize() {
    int dummy;
    static int* stackStart = nullptr;
    
    if (stackStart == nullptr) {
        stackStart = &dummy;
    }
    
    size_t used = std::abs(stackStart - &dummy) * sizeof(int);
    std::cout << "스택 사용: " << used << " bytes" << std::endl;
}

void recursiveCheck(int n) {
    checkStackSize();
    if (n > 0) {
        recursiveCheck(n - 1);
    }
}

자주 발생하는 문제

문제 1: 종료 조건 누락

// ❌ 종료 조건 없음
void countdown(int n) {
    std::cout << n << std::endl;
    countdown(n - 1);  // 무한 재귀
}

// ✅ 종료 조건
void countdown(int n) {
    if (n <= 0) return;
    std::cout << n << std::endl;
    countdown(n - 1);
}

문제 2: 상호 재귀

// ❌ 상호 재귀 (종료 조건 부족)
void funcA(int n);
void funcB(int n);

void funcA(int n) {
    funcB(n);
}

void funcB(int n) {
    funcA(n);
}

// ✅ 종료 조건 추가
void funcA(int n) {
    if (n <= 0) return;
    funcB(n - 1);
}

void funcB(int n) {
    if (n <= 0) return;
    funcA(n - 1);
}

문제 3: 구조체 배열

struct LargeStruct {
    int data[10000];
};

// ❌ 스택에 큰 구조체 배열
void func() {
    LargeStruct arr[100];  // 4MB
}

// ✅ 동적 할당
void func() {
    auto arr = std::make_unique<LargeStruct[]>(100);
}

문제 4: 가변 길이 배열

func 함수의 구현 예제입니다.

// ❌ VLA (C99, 일부 컴파일러)
void func(int n) {
    int arr[n];  // n이 크면 위험
}

// ✅ 벡터 사용
void func(int n) {
    std::vector<int> arr(n);
}

디버깅 방법

터미널에서 다음 명령어를 실행합니다.

# 1. 스택 크기 늘리기 (임시 해결)
# Linux
ulimit -s unlimited

# Windows (링커 옵션)
# /STACK:reserve[,commit]

# 2. 디버거 사용
gdb ./program
(gdb) run
# 스택 오버플로우 발생 시
(gdb) backtrace

# 3. AddressSanitizer
g++ -fsanitize=address -g program.cpp

방지 방법

// 1. 재귀 -> 반복문
int sum(int n) {
    int result = 0;
    for (int i = 1; i <= n; i++) {
        result += i;
    }
    return result;
}

// 2. 큰 데이터 -> 힙
void process() {
    auto data = std::make_unique<int[]>(1000000);
}

// 3. 깊이 제한
int recursive(int n, int depth = 0) {
    if (depth > MAX_DEPTH) {
        throw std::runtime_error("깊이 초과");
    }
    // ...
}

// 4. 메모이제이션
std::unordered_map<int, int> cache;

int compute(int n) {
    if (cache.count(n)) {
        return cache[n];
    }
    // 계산
    cache[n] = result;
    return result;
}

스택 vs 힙

stackAlloc 함수의 구현 예제입니다.

// 스택: 빠르지만 제한적
void stackAlloc() {
    int arr[100];  // 빠름
}

// 힙: 느리지만 큰 메모리
void heapAlloc() {
    auto arr = std::make_unique<int[]>(1000000);  // 유연
}

// 선택 기준
// - 작은 데이터 (<1KB): 스택
// - 큰 데이터 (>1KB): 힙
// - 수명이 함수 범위: 스택
// - 수명이 긴 경우: 힙

스택 크기 제한을 알아두기

OS·링커 설정에 따라 기본 스택 크기가 크게 달라집니다. 대략적인 감각은 다음과 같습니다.

환경기본 스택(대략)비고
Linux 스레드(main)ulimit -s (종종 8MiB)pthread 생성 시 pthread_attr_setstacksize로 조정
Windows 스레드링커 /STACK (기본 1MiB 등)실행 파일·스레드 생성 옵션 확인
macOSulimit -s필요 시 늘리되, 근본 해결은 알고리즘·할당 방식

중요: 스택을 무제한으로 키우는 것은 임시 방편입니다. 재귀 깊이나 대형 프레임 문제는 설계를 바꿔 스택 사용량을 줄이는 것이 맞습니다.

재귀 깊이 문제

같은 알고리즘이라도 입력 크기에 따라 호출 깊이가 선형·지수로 늘어납니다. 피보나치의 순수 재귀는 깊이도 크고 호출 수도 폭발하므로, 반복문·메모이제이션·행렬 거듭제곱 등으로 바꾸는 편이 낫습니다.

깊이가 고정되어 있어도(예: 트리 DFS) 최악 깊이가 스택 한계에 근접하면 명시적 스택(std::vector로 노드 스택)으로 바꾸는 것이 안전합니다.

큰 지역 변수와 alloca

VLA(가변 길이 배열)는 C++ 표준이 아니며, 일부 확장으로 허용되더라도 n이 크면 한 번에 스택을 크게 씁니다. alloca도 마찬가지로 스택 사용량이 호출마다 달라져 예측이 어렵습니다. 크기가 런타임에 커질 수 있으면 vectorunique_ptr<T[]>에 두세요.

해결 방법 요약

  1. 힙 할당: std::vector, std::unique_ptr<T[]> — 크고 가변적인 버퍼에 적합.
  2. 반복문으로 전환: 꼬리 재귀 형태로 바꿀 수 있으면 스택 깊이를 없앨 수 있습니다.
  3. 꼬리 재귀: C++ 표준은 꼬리 호출 최적화(TCO)를 보장하지 않습니다. TCO에 의존하기보다 반복문으로 바꾼 버전을 유지보수 기준으로 삼는 것이 안전합니다.
  4. 재귀 깊이 상한 + 에러: 신뢰할 수 없는 입력에서는 깊이 카운터로 조기 실패.
  5. 스택 크기 조정: ulimit -s(Linux), MSVC /STACK(링커) 등은 배포 문서에 명시하고, 근본 원인과는 분리해 다룹니다.

디버깅 (스택 오버플로 의심 시)

  • 증상: SIGSEGV가 스택 끝 근처에서 나거나, 재귀 직후 크래시.
  • gdb / lldb: 크래시 시 bt가 매우 깊거나 같은 함수가 반복되면 재귀 의심. frame 이동하며 지역 변수 크기를 추정합니다.
  • AddressSanitizer: 일부 환경에서 스택 오버플로를 보고하기도 하지만, 보장 도구는 아닙니다. 플랫폼별 가드 페이지 동작에 의존합니다.
  • 컴파일러 경고: 큰 지역 배열에 대한 경고(-Wstack-usage= 등, GCC)를 켜 두면 예방에 도움이 됩니다.

터미널에서 다음 명령어를 실행합니다.

# Linux: 현재 스택 한계 확인
ulimit -s

# 깊은 재귀 재현 시 (임시)
ulimit -s unlimited
./repro

FAQ

Q1: Stack Overflow는 언제?

A:

  • 무한 재귀
  • 깊은 재귀
  • 큰 지역 변수

Q2: 탐지 방법은?

A:

  • 디버거 backtrace
  • AddressSanitizer
  • 스택 크기 모니터링

Q3: 방지 방법은?

A:

  • 재귀 -> 반복문
  • 힙 할당
  • 깊이 제한

Q4: 스택 크기는?

A:

  • Linux: 보통 8MB
  • Windows: 보통 1MB
  • 변경 가능 (ulimit, 링커)

Q5: 재귀 vs 반복문?

A:

  • 재귀: 간결, 스택 사용
  • 반복문: 빠름, 안전

Q6: Stack Overflow 학습 리소스는?

A:

  • “C++ Primer”
  • “Effective C++”
  • GDB 문서

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

관련 글

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「C++ Stack Overflow | ‘스택 오버플로우’ 가이드」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]
sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)
  • 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
  • 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
  • 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
  • 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역운영 관점 질문
관측성요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「C++ Stack Overflow | ‘스택 오버플로우’ 가이드」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

  1. 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
  2. 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
  3. 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
  4. 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
  5. 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.
handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상가능 원인조치
간헐적 실패레이스, 타임아웃, 외부 의존성, DNS최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패환경 변수, 권한, 플랫폼 차이, lockfileCI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치프로필·시크릿·기본값, 리전스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치비멱등 재시도, 부분 쓰기, 캐시 무효화 누락멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git addgit commitgit pushnpm run deploy 순서를 권장합니다.


이 글에서 다루는 키워드 (관련 검색어)

C++, stack-overflow, stack, debugging, recursion 등으로 검색하시면 이 글이 도움이 됩니다.