[2026] C 언어 시리즈 #06 — 배열·디케이(decay)·문자열 리터럴·VLA

[2026] C 언어 시리즈 #06 — 배열·디케이(decay)·문자열 리터럴·VLA

이 글의 핵심

배열 이름이 언제 “첫 요소의 포인터”로 떨어지는지, 왜 `char s[] = "hi"`와 `char *p = "hi"`의 수정 가능성이 다른지, VLA가 스택에 어떤 비용을 남기는지 정리합니다.

시리즈 안내

#06 | 이전: #05 포인터 · 다음: #07 구조체·비트필드


1. 배열 타입 vs 포인터 타입

선언 int a[10];에서 a의 타입은 int[10] 이다. 그러나 대부분의 값 문맥에서 “첫 요소에 대한 포인터” 로 변환된다. 이를 흔히 decay라 부른다.

예외적으로 decay하지 않는 대표 경우:

  • sizeof a
  • &a의 타입(전체 배열에 대한 포인터)
  • 문자열 리터럴로 초기화하는 배열 char s[] = "abc";

2. 포인터 연산과 “배열 길이” 정보 소실

함수에 배열을 넘기면 길이 정보가 사라진다. 그래서 API는:

  • pointer + length
  • 구조체로 묶기 (struct { size_t n; int *p; })

중 하나를 요구한다. “널 종료”에만 의존하는 바이너리 데이터 처리는 버퍼 오버런을 낳는다.


3. 문자열 리터럴의 저장 위치

"hello"정적 저장 기간을 가진 배열 객체로 생각할 수 있으며, 내용을 바꾸는 시도는 UB다. 여러 번역 단위에서 같은 리터럴을 합칠지는 구현 정의다.

프로덕션:

  • 국제화·리소스는 리터럴이 아니라 테이블에서 로드한다.
  • 검색·로깅에 쓰는 상수 문자열도 수명을 명확히 문서화한다.

4. 가변 길이 배열(VLA)

블록 스코프에서 int a[n]; 형태는 C99 VLA다(선택적 구현). 스택에 런타임 크기만큼 잡히며, 깊은 재귀·큰 n스택 오버플로 위험이 있다.

임베디드·커널에서는 VLA를 끄는 경우가 많고(-Wvla), 프로덕션에서는 명시적 malloc/alloca(비표준) 대신 고정 버퍼·풀을 택하는 편이 일반적이다.


5. char 배열 vs wchar_t·UTF-8

소스 인코딩과 실행 문자 집합은 구현에 따른다. UTF-8 소스에서 리터럴을 쓰더라도 char는 바이트일 뿐이며, 다국어 처리는 명시적 라이브러리가 필요하다.


내부 동작과 핵심 메커니즘

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

요약

배열은 “값이 연속인 타입”이지만, 대부분의 사용처에서 포인터로 약화되어 길이를 잃는다. 문자열 리터럴은 읽기 전용 이미지에 가깝고, VLA는 스택 예산을 동적으로 흔든다.

다음: #07 구조체·정렬·비트필드