[2026] C 언어 시리즈 #04 — 함수·스택 프레임·호출 규약(ABI)과 가변 인자

시리즈 안내

#04 | 이전: #03 제어 · 다음: #05 포인터

---

1. 활성화 레코드(스택 프레임)의 개념

함수가 호출되면(개념적으로):

1. 반환 주소가 스택(또는 링크 레지스터)에 기록된다.
2. 프롤로그에서 프레임 포인터·저장할 callee-saved 레지스터를 백업한다.
3. 지역 변수·spill 슬롯(레지스터 부족 시)이 프레임에 할당된다.

정확한 순서·레지스터 선택은 컴파일러·최적화 수준에 따라 다르다. -fomit-frame-pointer면 전통적인 FP 체인이 사라져 스택 언와인드가 어려워지는데, 이는 디버거·샘플러가 “스택 트레이스”를 볼 때 체감된다.

---

2. x64 호출 규약 개요(요약)

System V AMD64 ABI(리눅스·많은 Unix)

• 정수/포인터 인자: rdi, rsi, rdx, rcx, r8, r9 순으로 일부 전달, 나머지 스택.
• 부동: xmm0–xmm7 등(세부는 타입·개수에 따름).
• 호출 전 스택 포인터 rsp는 16바이트 정렬이어야 한다는 요구가 있다(많은 OS에서).

Windows x64

• 다른 레지스터 할당·비휘발성 레지스터 집합이 다르다.
• 32바이트 섀도 스페이스(shadow space) 등 호출자가 스택에 확보하는 규칙이 있다.

포인트: 같은 C 코드라도 OS를 바꾸면 어셈블리가 달라진다. JIT 경계·콜백·어셈블리 루틴을 섞을 때는 문서화된 ABI를 따라야 한다.

---

3. noinline·인라인과 심볼

static inline 함수는 번역 단위에만 존재할 수 있고, 외부 심볼이 안 될 수 있다. 반대로 일반 함수는 하나의 정의 규칙 아래 링커에 노출된다.

프로덕션:

• 공유 라이브러리 경계에서 심볼 가시성(default/hidden)을 제어해 로드 시간과 의존성을 줄인다(플랫폼별).

---

4. 가변 인자 <stdarg.h>

va_start/va_arg/va_end는 컴파일러가 부어 넣은 레지스터 저장 영역·스택 슬롯을 순회한다. 그래서:

• 타입을 잘못 읽으면 그냥 틀린 비트를 읽는다(UB에 가깝다).
• va_copy는 재진입 가능한 순회에 필요하다.

#include <stdarg.h>
#include <stdio.h>

void print_ints(const char *fmt, ...) {
    va_list ap;
    va_start(ap, fmt);
    /* 실제 코드에서는 fmt 파싱과 함께 타입을 일치시켜야 함 */
    (void)fmt;
    int x = va_arg(ap, int);
    printf("%d\n", x);
    va_end(ap);
}

프로덕션: 가변 인자 API는 새 코드에서 피하고, printf류 표준과의 호환만 유지한다. 대체로 구조체 하나나 매크로 생성기로 안전한 API를 만든다.

---

내부 동작과 핵심 메커니즘

이 글의 주제는 「[2026] C 언어 시리즈 #04 — 함수·스택 프레임·호출 규약(ABI)과 가변 인자」입니다. 여기서는 앞선 설명을 구현·런타임 관점에서 한 번 더 압축합니다. 구성 요소 간 책임 분리와 관측 가능한 지점을 기준으로 생각하면, “입력이 어디서 검증되고, 핵심 연산이 어디서 일어나며, 부작용(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) 수정 후 회귀·부하 테스트.

요약

함수는 소스의 블록이 아니라 ABI가 규정한 레지스터·스택 레이아웃이다. 스택 프레임은 디버깅·보안(스택 카나리)·언와인드와 연결되며, 가변 인자는 그 위를 타입 없이 걷는 칼이다.

다음: #05 포인터 연산·엄격 별칭