한빛출판네트워크

프로그래머들은 다른이들을 위해 멋진 도구를 만들어왔다. 이제 자신들을 위해 만들 시간이다.

Alan Kay는 Quora 포스트에서 프로그래머를 위한 도구의 현황에 대해 애도했습니다. 다른 모든 공학 분야는 컴퓨터 지원 설계, 시뮬레이션 및 테스트 그리고 제조를 위한 현대적인 연산 도구를 구축했습니다. 그러나 프로그래밍은 1970년 이래로 크게 발전하지 않았습니다. 우리는 다른 분야를 위해 훌륭한 도구를 만들었지만, 스스로를 위해서 만들지 않았습니다. 구두 수선공의 자녀의 신발에 구멍이 난 상황입니다.

Kay가 전적으로 옳지는 않지만 그가 놓친 것을 찾기 전에, 어떻게 그가 옳은지에 대해 생각해보는 것이 중요합니다. 그것을 이해하지 못하면, 다음에 무엇을 만들어야 하는지, 그리고 어디에서 미래가 우리를 바라보고 있는지 이해할 수 없을 것입니다.

프로그래밍부터 시작해보겠습니다. 우리는 여전히 고해상도 모니터에서 에뮬레이트된 펀치 카드를 사용하고 있습니다. 여전히 알파벳과 숫자를 사용하여 라인 지향 프로그래밍을 하고 있습니다. 여전히 대부분의 경우 C나 LISP와 같이 동작하는 언어를 사용하며, 프로그래밍 커뮤니티의 가장 큰 논쟁은 이러한 옛 패러다임 중 어떤 것이 더 나은지에 대한 것입니다. 가상 펀치 카드들을 쉽게 생성해주는 IDE가 있지만, 기본적으로 본질은 바꾸지 않았습니다. 단위 테스트를 위한 몇 가지 도구들이 있지만, 이 도구들은 더 많은 펀치 카드를 작성하기를 요구합니다. 이러한 펀치 카드의 변경사항을 관리하기 위한 버전 관리 도구도 있습니다. 그리고 심지어 지속적인 통합, 배포 그리고 컨테이너 오케스트레이션을 위한 도구도 있습니다. 이 모든 도구들은 더 많은 가상 펀치 카드를 생성함으로 프로그래밍됩니다.

데이터베이스 개발자는 다소 나은 편입니다. SQL과 같은 비절차 언어는 시각적 프로그래밍 스타일을 보다 손쉽게 지원하며 Tableau와 같은 도구를 제공합니다. 하지만 엔터프라이즈 애플리케이션을 백엔드 데이터베이스에 연결하는 경우에는 큰 도움이 되지 않습니다. 

여기서 어디로 갈 수 있을까요? 저는 차세대 프로그래밍 언어가 LISP, C 또는 스몰토크(Smalltalk) 구문을 다시 변경하지 않을 것이라고 오랫동안 생각했습니다. 이것은 문자 기반이 전혀 아니며 시각 기반입니다. 타이핑하는 대신에 원하는 대상을 그립니다. 저는 아직 이에 알맞는 언어를 보지 못했습니다. Alice와 Scratch와 같은 학습 플랫폼은 흥미로운 시도지만, 충분히 멀리 가지는 못했습니다. 그들은 우리가 이미 알고 있는 프로그래밍 언어를 활용하여 시각적인 은유를 적용합니다. Loop 대신 C-Clamp, keyword 대신 Plug-in block. 아무 것도 변한 것은 없습니다.

우리가 필요로 하는 시각적 프로그래밍 언어는 우리의 모든 프로그래밍 패러다임에서 아이디어를 빌려 올 것이라고 생각합니다. 메시지를 전달하고, 객체를 생성하고, 동시성을 보장할 것입니다. 존재하지 않는 것은 텍스트 표현입니다. C와 같은 기반언어에 시각적이라는 설탕코팅(sugarcoating)이 되지는 않습니다.

이러한 언어의 기원에 대한 아이디어가 있습니다. 프로그래밍의 미래에 대해 생각하는데 도움이 될 두가지 추세를 살펴보고 있습니다.

첫째, 두 종류의 프로그래머가 존재한다는 증거가 늘어나고 있습니다. 다른 것들을 함께 연결하여 무언가를 만드는 프로그래머와 다른 사람들이 함께 연결하는 것을 만드는 프로그래머입니다. 첫 번째는 ‘블루칼라' 프로그래머 그룹입니다. 두 번째는 인공지능에서 새로운 일을 하는 사람과 같은 ‘학계' 프로그래머 그룹입니다. 어느 그룹도 더 가치있거나 중요하지 않습니다. 건축업이 좋은 비유입니다. 만약 새 주방 싱크대를 설치해야 할 경우, 배관공에게 전화합니다. 그는 싱크대를 나머지 배관에 연결하는 방법을 알고 있습니다. 하지만 싱크대를 디자인하는 법은 모릅니다. 사무실에는 싱크대를 배관에 연결하는 방법을 (기본적으로) 이해는 하지만 싱크대를 설치하지는 않고 싱크대를 설계하는 전문 지식을 가진 싱크대 디자이너가 있습니다. 세상은 비록 디자이너보다 배관공을 더 필요로 하지만, 둘 다 없으면 안됩니다. 소프트웨어 세상에서도 마찬가지입니다. 웹 애플리케이션을 개발하는 사람의 수가 React와 같은 웹 프레임워크나 새로운 알고리즘을 설계하고 기본적인 연구를 수행하는 사람보다 훨씬 많습니다.

컴퓨터의 배관공은 알고리즘 설계자와 같은 도구를 사용해야만 할까요? 저는 그렇게 생각하지 않습니다. 빌드 전 작업을 연결하기 위해 고도로 최적화 된 언어를 상상할 수 있지만, 작업 자체를 빌드하기에는 적합하지 않습니다. list의 모든 element에 함수를 적용하는 언어로 이러한 것을 엿볼 수 있습니다. 여러분들은 더이상 loop가 필요하지 않습니다(Python의 map()은 list의 모든 element에 함수를 적용합니다. 자동으로 함수가 적용되는 언어가 있습니다). PHP는 웹 페이지를 데이터베이스에 연결하는데 좋지만, 암호화 알고리즘을 구현하는데는 좋지 않은 언어로 볼 수 있습니다. 그리고 아마 이 결합 언어는 시각적일 것입니다. 만약 우리가 많은 부분을 연결하고 있다면, 코드의 라인 대신 선을 사용하지 않을까요?(Mel Conway는 고객이 상호 작용 시나리오를 묘사함으로써 응용 프로그램을 개발할 수 있는 “배선 다이어그램"을 개발하고 있습니다.”

둘째, 인공지능에서 가장 흥미로운 연구 분야 중 하나는 코드를 생성하는 능력에 대한 것입니다. 몇 년 전, AI가 데이터베이스 쿼리를 최적화할 수 있다는 것을 알았습니다. Andrej Karpathy는 이 능력이 우리가 원하는 알고리즘을 AI가 생성하게 되는 Software 2.0의 가장자리에 우리를 데려다 놓았다고 주장했습니다. 미래에 AI 시스템에게 우리의 코드를 작성할 수 있는 능력이 있다면 우리가 원하는 코드를 묘사하기 위해 어떤 언어가 필요할까요? 그 언어는 분명히 loop와 조건문이 있는 언어는 아닐겁니다. 또한 함수에 의해 주어진 수학적 추상화에 기초한 언어라고도 생각하지 않습니다. Karpathy는 AI 모델 훈련을 위한 데이터 셋으로 태그되는 것을 이 언어의 핵심으로 제안합니다. 명령을 단계 단계 작성하는 대신, 우리가 무엇을 원하는지 컴퓨터에서 보여줄 것입니다. 이러한 프로그래밍 패러다임이 너무 급진적이라고 생각한다면, 여러분이 입찰한 기계를 만드는 일과 너무 멀리 떨어져 있다면, 1950년대의 기계 언어 프로그래머가 현대의 최적화된 컴파일러에 대해 어떻게 생각할 지에 대해 생각해보세요.

새로운 시각적 언어가 어떻게 생겼는지 상상할 수는 없지만, 그것을 만들 수 있는 가장자리에 우리가 있다는 것은 느낄 수 있습니다. 사실, 우리는 이미 그것을 만들고 있습니다. platform.ai의 Jeremy Howard의 프로젝트 중 하나는 특정 분야의 전문가가 기존의 프로그래밍없이 기계 학습 응용 프로그램을 개발할 수 있도록 하는 시스템입니다. 그리고 Microsoft는 어떤 전통적인 프로그래밍없이 학습 데이터를 모으고, 정리하고, 모델을 빌드하기 위해 사용하기 위한 그래픽 도구를 제공하는 드래그 앤 드롭 기계 학습 도구를 출시했습니다. 누군가 “이건 실제 프로그래밍이 아니야"라고 주장할 수도 있다고 생각하지만, 구식 도구에 의존하여 프로그래밍을 정의하는 것과 매우 유사합니다.

나머지는 어떻습니까? 소프트웨어 빌드, 테스트, 배포 및 관리 도구는 어떻습니까? 이 부분이 Kay가 우리가 가진 것들을 과소평가하는 부분입니다. 이것이 별로 없다는 것은 동의합니다. 이것은 우리가 위로 쌓아 올릴 수 있는 토대입니다. 우리는 빌드 도구에 대한 40년 이상의 경험(1976년부터 make로 시작), 그리고 자동화된 설정에 대한 비슷한 경험(CFengine, Chef와 Puppet의 선구자, 90대로 거슬러 올라간다.), 네트워크 모니터링(Nagios, 2002년으로 거슬러 올라간다.), 그리고 지속적인 통합(Hudson, Jeeves의 전신, 2005년으로 거슬러 올라간다.) 컨테이너 오케스트레이션을 처리하는 Kubernetes는 “new kid on the block"입니다. Kubernetes는 분산 시스템을 위한 로봇 자동화 공장입니다. 많은 노드에서 실행되는 대규모 소프트웨어를 관리하고 운영하기 위한 도구입니다. 자동화된 어셈블리부터 자동화된 테스트, 완전 자동화된 생산까지 실행되는 완벽한 툴 제품입니다. 소등; 컴퓨터가 작업을 수행하도록 합니다.

안타깝게도, 여전히 이러한 도구는 가상 펀치 카드(일반적으로 XML, YAML, JSON 또는 이러한 불편한 텍스트 파일)로 구성되어 있으며 극복해야할 문제입니다. 내 생각에 이건 어려운 문제가 아닙니다. - 이러한 도구 중 하나에 대한 시각적 언어를 만드는 것이 프로그래밍을 위한 시각적 언어를 만드는 것보다 훨씬 쉬운 문제라고  생각합니다. - 이것은 전통입니다.

소프트웨어 종사자는 나쁜 도구에 익숙합니다. 그리고 실제 물리적인 펀치 카드를 사용하는 것은 싫지만 (이것을 해봤습니다, 재미없습니다.), 이 펀치 카드를 가상화하면 낫습니다. 아마도 이것은 통과 의례, 일종의 산업적 관문일 것입니다. “우리는 이 흡수에 살아 남았습니다, 진정한 프로그래머가 되려면 여러분도 그래야 합니다.” 우리는 기뻐합니다.

우리가 이 상황에 만족해서는 안된다고 한 Kay가 옳았습니다. 1960년대 개발자가 즉시 이해할 수 있는 도구를 사용하여 소프트웨어를 구축해야하는 어려움으로 인하여 bit의 의미보다는 bit 자체에 대해 계속 생각하게 됩니다. 

산업적으로 그것을 넘어서야 합니다. 필요한 몇 가지 도구에 대한 프로토 타입이 있습니다. 우리는 단지 일을 끝내기만 하면 됩니다.

소프트웨어 개발을 위한 다른 미래를 상상해야 합니다. 

*****

원문 : Toward the next generation of programming tools

번역 : 김다운