[2026] C 언어 시리즈 #03 — 제어 흐름: 분기·스위치 테이블·setjmp와 스택

시리즈 안내

#03 | 이전: #02 타입 · 다음: #04 함수·호출 규약

---

1. 조건과 예측 가능성

현대 CPU는 분기 예측기가 있지만, 핫 루프 안의 랜덤 분기는 여전히 비용이 큽다. C 수준에서 할 수 있는 일은:

• 데이터를 정렬·전처리해 불필요한 분기를 줄인다.
• 분기 없는 산술(조건을 0/1로 만든 뒤 곱·cmov 성격)을 쓰되, 가독성과 UB를 동시에 만족하는지 검토한다.

---

2. switch와 점프 테이블

밀집된 정수 case는 컴파일러가 점프 테이블(주소 배열을 통한 간접 점프)을 만들 수 있다. 희소한 값은 이진 탐색이나 if 체인이 낫다.

내부 관점: switch는 단순 문법이 아니라 다중 분기 최적화의 입구다. default가 없고 범위 밖 값이 들어오면 UB가 될 수 있는 패턴(열거형 스위치에서 default 누락 등)은 정적 분석으로 잡는다.

---

3. Duff’s device와 루프 언롤

역사적으로 I/O 레지스터에 연속 쓰기를 할 때 루프 언롤 + switch로 분기 비용을 줄인 패턴이 알려져 있다. 오늘날에는:

• 컴파일러가 자동 언롤을 잘 수행한다.
• 가독성·검증 비용이 크다.

즉 프로덕션에서는 거의 쓰이지 않는다고 보는 편이 안전하다.

---

4. goto와 오류 처리

커널·드라이버 코드에서는 단일 정리 지점(cleanup) 으로 점프하는 goto fail 패턴이 흔하다. 다중 return과 비교해 락 해제·close 호출 순서를 한눈에 보게 만든다.

int setup(void) {
    int fd = -1;
    void *buf = NULL;
    if (open_resource(&fd) != 0) goto out;
    if (alloc_buffer(&buf) != 0) goto out_fd;
    /* 성공 경로 */
    /* ... */
    free(buf);
    close(fd);
    return 0;
out_fd:
    close(fd);
out:
    return -1;
}

---

5. setjmp/longjmp와 스택 프레임

setjmp는 호출 환경을 버퍼에 저장하고, longjmp는 그 지점으로 비국소적으로 돌아간다.

호출 규약 관점:

• 일반적인 return은 프레임 포인터·저장 레지스터를 정리하는 경로다.
• longjmp는 그걸 건너뛰므로, 가변 길이 배열(VLA)이나 플랫폼별 예외 데이터와 상호작용할 때 미정의 동작이 나올 수 있다(C 표준의 제약 참조).

프로덕션: 파서·코루틴 시뮬레이션 등 제한된 영역 외에는 사용을 피하고, 대신 명시적 상태 기계나 setjmp 대체 설계를 택한다.

---

내부 동작과 핵심 메커니즘

이 글의 주제는 「[2026] C 언어 시리즈 #03 — 제어 흐름: 분기·스위치 테이블·setjmp와 스택」입니다. 여기서는 앞선 설명을 구현·런타임 관점에서 한 번 더 압축합니다. 구성 요소 간 책임 분리와 관측 가능한 지점을 기준으로 생각하면, “입력이 어디서 검증되고, 핵심 연산이 어디서 일어나며, 부작용(I/O·네트워크·디스크)이 어디서 터지는가”가 한눈에 드러납니다.

처리 파이프라인(개념도)

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

알고리즘·프로토콜 관점에서의 체크포인트

• 불변 조건(Invariant): 각 단계가 만족해야 하는 조건(예: 버퍼 경계, 프로토콜 상태, 트랜잭션 격리)을 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
• 결정성: 동일 입력에 동일 출력이 보장되는 순수한 층과, 시간·네트워크에 의해 달라질 수 있는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
• 경계 비용: 직렬화/역직렬화, 문자 인코딩, syscall 횟수, 락 경합처럼 “한 번의 호출이 아니라 누적되는 비용”을 의심 목록에 넣습니다.

---

프로덕션 운영 패턴

실서비스에서는 기능 구현과 함께 관측·배포·보안·비용이 동시에 요구됩니다. 아래는 팀에서 자주 쓰는 최소 체크리스트입니다.

영역	운영 관점에서의 질문
관측성	요청 단위 상관 ID, 에러율/지연 분위수, 주요 의존성 타임아웃이 보이는가
안전성	입력 검증·권한·비밀 관리가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등한 연산에만 적용되는가, 서킷 브레이커·백오프가 있는가
성능	캐시 계층·배치 크기·풀링·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리, 마이그레이션 호환성이 문서화되어 있는가

운영 환경에서는 “개발자 PC에서는 재현되지 않던 문제”가 시간·부하·데이터 크기 때문에 드러납니다. 따라서 스테이징의 데이터 양·네트워크 지연을 가능한 한 현실에 가깝게 맞추는 것이 중요합니다.

---

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스 컨디션, 타임아웃, 외부 의존성 불안정	최소 재현 스크립트 작성, 분산 트레이스·로그 상관관계 확인
성능 저하	N+1 쿼리, 동기 I/O, 잠금 경합, 과도한 직렬화	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 클로저/이벤트 구독 누수, 대용량 객체의 불필요한 복사	상한·TTL·스냅샷 비교(힙 덤프/트레이스)
빌드·배포만 실패	환경 변수·권한·플랫폼 차이	CI 로그와 로컬 diff, 컨테이너/런타임 버전 핀(pin)

권장 디버깅 순서: (1) 최소 재현 만들기 (2) 최근 변경 범위 좁히기 (3) 의존성·환경 변수 차이 확인 (4) 관측 데이터로 가설 검증 (5) 수정 후 회귀·부하 테스트.

요약

제어 흐름은 CPU 분기 예측·점프 테이블·프레임 복원과 직결된다. longjmp는 “스택을 되감는 것”처럼 보이지만 C 추상 기계의 수명 규칙을 깨뜨리기 쉽다.

다음: #04 함수·스택 프레임·호출 규약