“개발자가 수학에 투자하는 시간은 절대 낭비가 아닙니다” C++ 창시자 인터뷰

본문은 요즘IT와 번역가 Chase가 함께 만든 해외 번역 콘텐츠입니다. ‘Evrone’이라는 해외 IT 아웃소싱 기업이, C++ 제작자이자 최초 구현자인 비야네 스트롭스트룹(Bjarne Stroustrup)을 인터뷰한 글입니다. 비야네 스트롭스트룹은 1978년부터 C++를 개발하였고, C++의 표준 참고서로 불리는 <C++ 프로그래밍 언어>를 저술했습니다. 인터뷰에는 C++ 프로그래밍에 대한 생각과 오랜 전문적 경험을 토대로 개발자들에게 건네는 조언이 담겨 있습니다.

에브론: 가장 효율적이고 빠른 프로그래밍 언어 중 하나인 C++를 만드셨습니다. 의심할 여지 없이 세상을 변화시키셨는데요, 이 작업을 하면서 개인적으로도 변화가 있었나요?

비야네: 흥미로운 질문이네요! 많이 생각해 본 질문은 아니지만, 답변을 하기 위해 개인적으로 변하지 않은 부분과 크게 변화한 것을 구분해야 할 것 같습니다.

먼저 여러 분야의 문제에 대한 저의 관심은 변하지 않았습니다. 1994년 D&E에서 말했던 것처럼 역사와 철학을 포함한 광범위한 문제에 대한 저의 관심은 아주 어린 시절부터 꾸준히 이어져 왔으며, 이것이 C++의 발전에 큰 도움이 되었다고 생각합니다. 마찬가지로 학문적으로 깊이 탐구하며, 더 많은 것들을 만들고자 하는 저의 열망이 제 작업에서 공학적인 측면에 투영되었다고 생각합니다. 저는 성능, 저렴한 비용, 신뢰성을 중요하게 생각합니다. 여기에 피드백, 진화적 발전, 현실 세계에서 일어나는 문제에 대한 인식과 강조가 더해져 C++의 토대가 되었습니다.

반면 교육에 관련된 관심은 꾸준히 증가했습니다. 제 아이디어를 설명하려고 노력하면 할수록, 무언가를 만드는 행위만큼 사람들이 잘 사용할 수 있게 가르치는 것이 중요하다는 것을 깨달았습니다. 특히 이 문제는 C++에서 항상 고질적이었죠. 제 메시지는 더 단순한 비전과 더 큰 주장을 하는 사람들에 의해 묻혀버렸습니다.

실제로 1980년대와 1990년대에 "교사들이 C++를 빠르게 가르칠 수 없다"라는 불만이 많았기 때문에, C++는 끔찍하다는 생각을 갖고 가르치는 경우도 많았습니다. 그래서 일부 사람들이 C++에 대해 매우 부정적인 시각을 가진 것도 당연하다고 생각합니다.

또한 제가 평생 영어로 말하게 될 줄 알았다면 영어(외국어) 수업에 더 많은 관심을 기울였을 겁니다. 그리고 저는 여행을 통해 다양한 문제와 그것을 해결하기 위해 직면하는 또 다른 문제에 대해 많은 통찰력을 얻었습니다.

제 인생에서 겪은 가장 어려웠던 문제들은 대부분 조직, 관리, 교육과 관련된 것이었습니다. 그런 점에서는 제가 수료한 기술 교육보다 폭넓은 주제에 대해 독서를 많이 한 것이 더 큰 도움이 되었습니다. 더불어 좋은 개발 언어를 설계하기 위해서는 겸손이 필요하다는 것도 배웠습니다. 이 세상은 끊임없이 변하고, 우리가 모르는 것은 너무나도 많고, 문제도 끊임없이 바뀝니다. 우리도 계속 변하죠.

에브론: 비즈니스 환경에서는 새로운 기능을 구현하는 동시에 타이트한 마감 기한을 준수해야 합니다. 개발자들이 코드 품질과 개발 속도 사이에서 균형을 유지할 수 있는 좋은 방법이 있을까요?

비야네: 이는 기업의 관리 구조와 기술 문화에 따라 달라집니다. 개인적인 의견(주로 벨 연구소에서 개발했습니다)으로는 마감일이 촉박한 프로젝트에 모든 인력을 투입해야 하는 상황을 방지하는 게 가장 이상적이라고 봅니다. 이를 위해 최고 수준 인력을 충분히 고용해야겠죠. 

일부 핵심 인력은 미래를 계획하고, 실험하고, 중요한 시스템의 첫 번째 버전과 그다음 버전도 구축해야 합니다. 좋은 조직은 이미 배포하여 유지 보수 또는 업그레이드가 필요한 제품을 꾸준히 발전시키는 곳이라고 생각합니다. 이는 비용을 절감하거나, 매년 혁신적인 시스템을 만들어내야 한다는 일반적인 생각과는 다소 거리가 있습니다.

에브론: 요즘에는 최신 프레임워크를 사용하는 것이 수학 지식을 적용하는 것보다 더 중요하다는 의견이 널리 퍼져 있습니다. 이와 관련하여 프로그래머들에게 조언해 주실 수 있나요?

비야네: 수학에 투자하는 시간은 절대 낭비가 아닙니다. 수학은 두뇌를 훈련하는 가장 좋은 방법 중 하나이며, 특히 컴퓨팅과 결합하면 프로그래밍적 실수를 금방 파악하는 능력을 기르게 해줍니다. 수학은 우리에게 지나치게 단순화되거나, 잘못된 아이디어에 빠지지 않고 정확성을 기르는 능력을 가져다줍니다.

과학적인 컴퓨팅, 금융 소프트웨어, 그리고 일부 형태의 그래픽 등 수학이 필수적인 분야가 있지만, 대부분의 사람들에게 있어 수학의 핵심 영역은 확률과 통계입니다. 여러분이 짠 코드가 충분히 빠른가요? 확장은 가능한가요? 발생할 수 있는 이벤트와 그 의미는 무엇인가요?

물론 수학을 필요로 하지 않는 애플리케이션도 많습니다. 하지만 인프라를 구축하거나 애플리케이션을 대규모로 배포하는 경우 용량과 에너지 비용이 문제가 될 수 있고, 수학을 간과한 점이 피해를 끼칠 수 있습니다.

에브론: 몇몇 개발자들은 기존 작업을 런타임에서 컴파일 타임으로 전환해 최대한 많은 시간을 단축하고자, C++의 강력한 메타프로그래밍 시스템을 남용하기도 합니다. 이 접근 방식에 대해 어떻게 생각하시나요?

비야네: 새롭고 강력한 기능이나 기술은 남용 또는 오용될 수 있습니다. 이를 피할 방법은 없습니다. 이러한 열정은 우리를 항상 따라다니기 때문에, 결국 도구를 더 잘 사용하는 방법을 배우고 좀 더 관용적인 태도를 가져야 합니다.

남용의 긍정적인 효과는 약점에 대해 많은 것을 배울 수 있고, 더 나은 방향으로 개선할 수 있다는 것입니다. 예를 들어, 템플릿 메타프로그래밍은 매우 유용했기 때문에 많은 사람들이 그 추악함과 끔찍한 오류 메시지를 기꺼이 무시하며 사용했습니다. 그래서 이를 기반으로 컴파일러 시간에 평가되는 함수(constexpr 및 consteval)와 여러 개념을 보완할 수 있을 만큼 충분히 학습하여, 사람들이 작성하는 많은 부분을 극적으로 단순화할 수 있었습니다.

에브론: 딥마인드의 알파코드 신경망이 등장하면서 언론에서는 이러한 신경망이 곧 프로그래머를 대체할 것이라는 주장이 점점 더 많아지고 있습니다. 이를 위한 전제 조건이 있다고 생각하시나요?

비야네: 잘 모르겠습니다만, 제가 가장 중요하게 생각하는 프로그래밍 분야에서 AI가 프로그래머를 대체할 수 있을지는 의문입니다. 최적에 가까운 신뢰성과 성능은 표준화하거나 평균화하기가 쉽지 않거든요. 그래도 제 전문 분야가 아닌 AI에 대한 얘기를 들을 때면 텐서플로우와 유사한 라이브러리가 C++라는 점을 떠올리며, 좋은 의미에서든 나쁜 의미에서든 제 몫을 다했다고 생각합니다.

에브론: 때때로 개발자로서 당면한 프로그래밍 작업에 대한 적절한 솔루션을 찾지 못할 때가 있습니다. 이런 상황을 경험해 본 적이 있으신가요? 이러한 상황에 대처하는 방법에 대한 조언이 있다면 공유해 주시겠어요?

비야네: 물론이죠! 새롭거나 중요한 일을 하려고 할 때 몇 시간, 며칠, 혹은 그 이상 막혀서 좌절감을 느껴보지 않은 사람은 없을 것입니다.

저는 문제를 이해하기 위해 항상 논리적으로 문제를 바라보려고 노력합니다. 또한 피드백을 얻기 위해 측정할 수 있는 것이 있다면 측정하세요. 자신이 하고자 하는 일에 대해 깊게 생각해 보세요. 어쩌면 여러분은 해야 할 일을 하고 있지 않거나, 생각해 낸 작업들이 합리적이지 않을 수도 있습니다. 가끔은 잠시 휴식을 취하고 다른 생각을 해보는 것도 좋습니다. 그러면 긴장이 풀리면서 유용한 아이디어가 떠오르는 경우가 종종 있죠. 저 같은 경우는 조깅을 합니다.

에브론: 모든 아키텍처 문제는 새로운 추상화 계층을 도입하면 해결할 수 있다는 유명한 농담이 있습니다. 추상화 계층이 너무 많다는 문제만 빼고요. 저희가 본 많은 C++ 코드에는 지나치게 많은 추상화 계층이 있었습니다. C++의 설계자로서 추상화 수를 줄이는 방법에 대해 해줄 수 있는 조언이 있나요?

비야네: 말씀하신 부분은 데이비드 휠러의 "컴퓨팅의 제1법칙"의 일부입니다. 그렇지만 많은 사람들이 “새로운 계층의 도입은 또 다른 문제를 만든다"라는 그 법칙의 나머지 내용은 잊어버리곤 합니다. 데이비드 휠러는 제 논문 지도교수였습니다. 그는 훌륭한 분이었고 저는 그에게서 많은 것을 배웠습니다.

이 '농담'은 데이비드가 만들었을 당시보다 오늘날의 현실을 더 반영하고 있습니다. 요즘 사람들은 여러 단계의 인터페이스 뒤에 실제 작업을 계속 숨기고 있습니다. 이로 인해 크기나 런타임이 몇 배나 늘어날 수 있죠. 최신 C++의 대부분은 사람들이 컴파일러가 중복된 간접 함수 없이, 간단한 기계어 코드로 축소할 수 있는 적절한 인터페이스를 가질 수 있도록 만들어졌습니다.

에브론: 지난 10년 동안 주류 언어에 많은 문법적 설탕[1]이 추가되었습니다. 숙련된 개발자에게 더 나은 툴을 제공하기 위해 구문을 부풀리는(bloating) 이러한 추세에 대해 어떻게 생각하시나요?

비야네: ‘블로팅 구문’이 프로그래머의 삶을 단순화한다면 아무 문제 없다고 생각합니다. 저는 이를 ‘간단한 작업을 단순하게 만들기’라고 표현하는 편입니다. 프로그래머가 근본적인 아이디어를 코드로 직접 표현할 수 있도록 하는 것이 핵심이라고 생각합니다.

예를 들어, 컨테이너에 단순한 루프를 C 스타일 루프로 표현하는 것은 아무런 장점이나 이점이 없습니다. 차라리 의도를 직접적으로 표현하는 알고리즘이나 “range-based for”를 사용하는 것이 낫습니다. 루프 변수를 세부적으로 조작하는 것은 컨테이너의 모든 요소를 방문하는 것과 같은 특수한 경우에만 진행하세요. 아이디어를 보다 직접적으로 표현할수록 작성하기 쉽고, 읽기 쉽고, 유지 관리하기 쉬우며, 더 빠르게 실행하기 위해 필요한 최적화에 잘 맞습니다.

저는 '말을 하는데 한 가지 방법만 있어야 한다'라고 생각하지 않습니다. 그런 식으로 하면 어떤 것은 표현하기 매우 어려워지고, 어떤 것을 표현하기 위해 너무 많은 말을 해야 할 수도 있습니다. 또한 수년, 수십 년에 걸쳐 변화가 요구되기 때문에, 자연스럽게 언어 자체도 변하게 됩니다. 그런 점에서 프로그래밍 언어는 자연어와 크게 다르지 않습니다.

에브론: 많은 사람들이 당신을 멘토로 생각합니다. 회사나 팀 내에서 좋은 멘토가 갖춰야 할 자질은 어떤 것이 있을까요?

비야네: 우선 기꺼이 경청하고 문제를 진지하게 이해하려는 자세가 필요합니다. 그리고 조언을 해줄 때 어느 정도의 겸손함이 있어야 합니다. 우리의 이해가 불완전한 경우가 많기 때문입니다. 즉, 좋은 멘토는 일반적인 막연한 조언이 아니라 구체적인 조언을 제공해야 합니다. 누군가 여러분에게 진지한 질문을 한다는 것은 존경의 표현이라고 생각합니다. 따라서 질문자가 앞으로 나아가는 데 도움이 될 만한 답변을 해야 하죠. 그래서 조언은 어려운 일입니다. 좋은 질문은 많은 것을 가르쳐 줍니다. 질문은 발전의 주요 원천이 되고, 좋은 멘토는 학생들로부터 많은 것을 배우는 사람입니다.

에브론: 향후 C++ 버전에 추가할 만한 가치가 있다고 생각하는 변경 사항을 미리 말씀해 주실 수 있나요?

비야네: 우선 커뮤니티가 C++20의 새롭고 강력하며 간소화된 기능에 익숙해져야 합니다. C++20은 C++11에 비해 크게 개선된 버전입니다. 표준 라이브러리 컴포넌트 등 더 많은 기능이 있지만 우선 두 가지 기능만 언급하겠습니다.

• 먼저 모듈 기능입니다. 이제 import module을 선언하면 export module 처리된 인터페이스에 접근할 수 있습니다. 이를 통해 세부 구현 사항과 매크로를 유출하는 #include 헤더를 사용하는 것보다 훨씬 더 깔끔한 코드를 작성할 수 있습니다. 또한 모듈을 컴파일하는 속도 측면에서도 월등합니다. 예를 들어, import std를 사용하면 #import<iostream> 대비 10배 빨리 컴파일 할 수 있습니다. <iostream>에는 전체 스탠다드 라이브러리 중 10%만 담겨있고, std에는 전체가 담겨있는데도 말이죠. 모듈 std는 현재 실험 중인 상태인데, 투표를 통해 C++23에 포함할 기능으로 선정되었습니다.
   
• 다음은 컨셉(concept)입니다. C++20 이전에는 모든 템플릿이 제약 없이 작성되었습니다. 즉, 템플릿의 인수에 대한 요구 사항을 확인할 수 있는 인터페이스를 정의하지 않았습니다. 예를 들어, 반복자 타입(iterator type)이 필요한 템플릿의 경우 template<typename Iter>와 같이 작성되었습니다.

이번 버전부터는 template<random_access_iterator Iter과 같이 컨셉이라는 제약 조건으로 요구사항을 정의하고 사용할 수 있습니다. 저도 이와 같은 제약된 템플릿 인수가 이상적이라고 생각해왔습니다. 다만 유연성을 제한하거나 런타임 오버헤드를 부과하지 않고 이 아이디어를 구현하는 방법을 몰랐을 뿐입니다. 이제 우리는 템플릿 사용을 즉시 확인할 수 있고, 훨씬 더 개선된 오류 메시지를 받아볼 수 있으며, 함수 템플릿을 오버로드하고 성능을 향상시킬 수도 있습니다.

이외에도 웹에서 코루틴(coroutines), 범위, 캘린더, 시간대(time zones), 서식, 스팬, 컴파일러 시간 벡터 및 문자열 등 훨씬 더 자세한 정보를 찾을 수 있습니다. C++20 기능은 주요 컴파일러에서 제공되고 있습니다.

이제 다시 질문으로 돌아가겠습니다. 다음 버전의 경우, 아시다시피 팬데믹으로 인해 많은 프로젝트가 지연됐습니다. 많은 분들이 C++23의 중요한 프로젝트가 완료되길 바랐지만, 제가 가장 기대하는 프로젝트는 아직 진행되지 않고 있습니다. 여기서는 세 가지만 언급하겠습니다.

• 정적 반영(Static reflection): 프로그램의 유형에 따라 컴파일 타임에 코드를 생성하는 메커니즘이 필요합니다. 이렇게 하면 실행 시간 반영의 유연성을 소요 시간이나 공간에 대한 비용 없이 얻을 수 있습니다. 예를 들어, 고정된 유형들의 세트에 대해 최고로 최적화된 JSON 리더를 생성하는 것은 매우 간단해야 합니다. 이와 관련된 작업은 이미 상당 부분 진행되었습니다.
• 패턴 매칭(Pattern matching): 표현식이 일련의 타입 또는 값 대안과 일치하는 방식에 따라 동작을 선택하는 기능은 이미 많은 함수형 프로그래밍 언어에서 대체 동작을 표현하는 가장 편리한 방법 중 하나입니다. 앞으로 C++에서도 동일한 기능이 제공될 예정이며, 더이상 구식인 스위치문을 사용할 필요가 없습니다. 현재 실험적인 구현을 통해 꽤 완성도 높은 설계를 완성했기 때문에, C++26에서 만나볼 수 있을 것입니다.
• 동시성 모델(Concurrency model): 우리는 지난 수년간 동시성을 위한 일반 모델에 대해 연구해왔지만, 부적합한 사용 사례들이 계속 발견하여 개발이 지연되고 있습니다. C++26에서 구현을 목표로 하고 있습니다.

마지막으로 프로그래밍을 편리하고 안전하면서도 효율적으로 만드는 것은 개별적인 기능이 아니라는 것을 말하고 싶습니다. 이를 위해서는 자료형 체계(Type system)[2]에서 함께 작동하는 기능들의 촘촘한 네트워크가 필요합니다. 또한 우리는 수십억 줄의 기존 C++ 라인을 깰 수 없습니다. 지난 수십 년에 걸쳐 만든 호환성과 안전성은 매우 중요한 부분이기 때문입니다.

[1] 동일한 기능의 코드를 더 쉽게 읽거나 표현하도록 설계된 프로그래밍 언어 내의 구문

[2] 값, 표현식, 함수, 모듈 등을 분류하는 규칙의 집합

<원문>

C++ Creator Bjarne Stroustrup Interview

위 번역글의 원 저작권은 Evrone에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.