https://nimfsoft.art/ko/blog/2025/07/15/understanding-c-cpp-notation/
나르시가 주장하는 똥글에 대해
GPT Pro 20만원짜리 최신 사양 ai한테 질문을 해보았다.
1. 역사적 배경 ≠ 동일 집합
C++가 C에서 파생된 건 맞습니다. 하지만 “역사적으로 유래했다”는 사실과 “표기법으로 묶어도 된다”는 건 다른 차원의 문제입니다.
예를 들어 Java와 Kotlin도 역사적/기술적 연관이 깊지만, 아무도 “Java/Kotlin 개발자”라고 뭉뚱그려 쓰지 않습니다.
언어의 뿌리가 같다는 이유로 한 데 묶는 건 개발자 입장에선 정체성을 흐리는 표현이 될 수 있습니다.
2. 상호운용성은 특수한 케이스일 뿐
extern "C" 같은 상호운용 기술은 특수 상황에서 필요한 트릭이지, 언어의 본질을 설명하는 근거가 되진 않습니다.
대부분의 프로젝트에서 C와 C++가 혼재하는 경우는 점진적 마이그레이션이나 특정 라이브러리 의존 때문입니다.
순수 C++ 기반 프로젝트에서는 extern "C"를 거의 쓰지 않습니다.
즉, 언어 차이가 분명히 존재하고, 표기법으로 묶을 만큼 일상적으로 섞여 쓰이는 건 아닙니다.
3. 업계 표준이라는 주장에 대한 의문
구인 공고에 “C/C++”가 많이 쓰이는 건 사실입니다. 하지만 이는 표준이라기보다 편의적, 혹은 무지한 관행에 가깝습니다.
기업 입장에서는 “C만 할 줄 아는 사람”과 “C++을 잘 아는 사람”을 구분하지 않고, 그냥 넓게 모집하기 위해 묶어버리는 경우가 많습니다.
교육 콘텐츠에서도 “C/C++”를 쓰는 건 편의적 마케팅 용어일 뿐, 전문성 있는 교재일수록 언어를 엄격히 구분합니다.
4. 정체성 갈등은 단순한 자존심 문제가 아님
“C++ 개발자들이 괜히 자존심 부리는 거다”라고 보는 시각은 반쪽짜리 설명입니다.
C와 C++는 철학부터 다른 언어입니다. C는 절차적 프로그래밍 언어이고, C++는 다중 패러다임(절차적, 객체지향, 제네릭 등) 언어입니다.
따라서 “C/C++” 표기는 C++의 철학적·기술적 정체성을 무시하는 표현으로 읽힐 수 있습니다. 단순 감정 문제가 아니라, 실제로 잘못된 개념 전달입니다.
결론
“C/C++”라는 표기는 역사와 상호운용성 때문에 생긴 관행이지만,
언어적·철학적 차이를 무시하고,
학습자에게 잘못된 개념을 심으며,
업계에서도 단순 편의상 굳어진 잘못된 표현일 가능성이 큽니다.
따라서 “C/C++”는 정확한 기술 용어라기보다는 마케팅적·관행적 타협에 불과하며, 학술적·전문적 맥락에서는 지양하는 게 맞습니다.
+ 요약하면:
“C/C++”는 편의적인 표기는 될 수 있어도, 기술적으로나 교육적으로는 오히려 혼란을 키우는 부정확한 표현이다.
틀리거나 과장될 수 있는 부분
“C 코드 대부분은 C++에서 문제없이 컴파일된다”
과거에는 어느 정도 사실이었지만, 지금은 C99, C11, C23 같은 표준의 기능들이 C++에 그대로 없어서 “대부분”이라고 하기엔 무리예요.
예: restrict, VLA(가변 길이 배열), _Generic, designated initializers 등은 C++에서 지원되지 않음.
따라서 C99 이상 코드라면 컴파일이 깨질 수 있어요.
“업계에서 표준적이고 효율적인 표기법”
C/C++ 표기는 구인 공고, 교육 콘텐츠에서 널리 쓰이지만 표준적인 용어는 아닙니다.
ISO, 공식 문서, 컴파일러 레퍼런스 등에서는 “C/C++”이라는 표현을 쓰지 않고 “C and C++” 혹은 “C or C++”처럼 분리합니다.
즉, 현업 관행이지 공식 표준은 아니에요.
“C와 C++는 높은 수준의 코드 호환성을 가진다”
이는 “C89와 C++98”을 기준으로 보면 대체로 맞지만, 최신 표준 간에는 차이가 점점 벌어졌습니다.
그래서 지금 시점(2025년)에 “높은 수준”이라고 일반화하는 건 틀린 말이 될 수도
정확하네
C/C++이라 표기하는 곳은 공고말고 듣도보도 못하긴 함ㅋㅋ
갓피티
주제넘게 개념정립까지 하려고 했었네 나르시 저놈은
ㅊㅊ