C에서 아직도 사고 나는 이유는 문법이 아니다

C는 오래된 언어다.
문법도 단순하고, 참고 자료도 넘쳐난다.
그런데 이상하게도 C로 만든 프로그램에서는
여전히 비슷한 사고가 반복된다.

널 포인터, 메모리 오염, 예기치 않은 크래시.
겉으로 보면 문법 실수 같지만,
조금만 깊이 들어가 보면 원인은 거의 항상 같다.

문제가 되는 건 문법이 아니라
사고방식이다.

---

C로 사고가 나는 순간을 보면
대부분 이런 흐름을 따른다.

“이 정도는 괜찮겠지.”

이 한 문장이
수많은 장애의 출발점이다.

---

1) 메모리를 ‘값’처럼 다루기 시작할 때

C에서 메모리는 값이 아니다.
상태이고, 계약이고, 책임이다.

하지만 사고가 나는 코드를 보면
메모리를 마치 int 변수처럼 다룬다.

• 누가 할당했는지 모르고
• 누가 해제하는지 신경 쓰지 않고
• 언제까지 유효한지도 고려하지 않는다

이 상태에서 프로그램이
정상 동작하는 게 오히려 이상하다.

메모리를 다룰 때는
항상 이 질문이 먼저 와야 한다.

이 메모리는 누가 책임지는가?

---

2) “지금은 안 터지니까”라는 판단

C 코드에서 가장 위험한 말은
“지금은 괜찮다”다.

• 입력이 항상 정상일 거라는 가정
• 배열 크기를 넘지 않을 거라는 기대
• 호출 순서가 바뀌지 않을 거라는 믿음

이 가정들은
언젠가 반드시 깨진다.

C는 그 순간을
아주 잔인하게 알려준다.

---

3) 경계 조건을 마지막에 생각할 때

많은 C 코드가
정상 흐름부터 작성된다.

• 정상 입력
• 정상 호출
• 정상 종료

문제는
현실에서 정상 흐름은
가장 드물다는 점이다.

• 길이가 0인 데이터
• 예상보다 큰 입력
• 중간에 끊긴 처리

이 경계 조건을
나중에 붙이는 순간
코드는 이미 위험해져 있다.

---

4) 책임이 보이지 않는 함수 설계

좋지 않은 C 함수의 공통점은
사용법을 외우지 않으면 쓸 수 없다는 점이다.

• 이 함수 호출 전에 뭐 해야 하지?
• 호출 후에 뭘 해제해야 하지?
• 실패하면 어디까지 처리된 거지?

함수 시그니처만 보고
이 질문에 답할 수 없다면
그 함수는 이미 사고 후보군이다.

C에서는
함수 하나가 작은 계약이다.
이 계약이 불명확할수록
사고 확률은 기하급수적으로 올라간다.

---

5) “C니까 어쩔 수 없다”는 포기

사고가 반복되는 코드에서
자주 나오는 말이 있다.

“C는 원래 위험한 언어잖아.”

이 말이 나오는 순간
개선은 멈춘다.

C가 위험한 건 사실이다.
하지만 그 위험을
어디까지 통제할지는
전적으로 작성자의 선택이다.

• 방어적인 코드
• 명확한 책임
• 보수적인 가정

이 세 가지만 지켜도
사고의 절반 이상은 사라진다.

---

C에서 사고가 나는 이유는
언어가 낡아서가 아니다.

• 가정을 너무 많이 믿고
• 책임을 흐리게 두고
• 경계를 나중에 생각하기 때문이다.

C는 냉정한 언어다.
작성자가 생각한 만큼만
정확하게 동작한다.

그래서 C를 잘 쓰는 사람은
문법보다 먼저
사고방식을 단련한다.

다음 글에서는
이 사고가 실제로 어떤 형태로 터지는지,
현장에서 자주 보는 C 사고 패턴들을
조금 더 구체적으로 정리해보려 한다.