• 한양대 도경구 교수님 (CS101을 가르치며)
• 전남대 최광훈 교수님 (프로그래밍 언어 이론을 ESOP 교재로 가르치며)
• 코드마인드 신승철 대표님
• 서울대 이광근 교수님 (easyword.kr)

1. PL 분야의 주요 성과: 소프트웨어 보안 (정적 분석)

신승철: 우리가 경험한 것 중 하나는, 교수님들과 함께 공부했던 프로그램 분석을 소프트웨어 시큐리티에 적용해 아주 좋은 성과를 낸 것입니다. 2008년도 정도부터 시작해서, 지금은 소프트웨어를 개발할 때 소스 코드 진단을 의무적으로 행하게 되어 있습니다. 그 진단 도구에 대한 기술들을 우리 교수님들과 같이 만들었고, 지금은 아주 일상적인 기술이 되었습니다.

도경구: 조금 부연 설명을 드리면, 이 작업을 제안하신 분은 고려대 최진영 교수님이셨습니다. 당시 행정안전부에 근무하던 한근희 박사님이 (최진영 교수님이 각잡힌 기법 (formal method)을 하시니까) 시큐리티 분석 도구를 만들면 좋겠다고 제안하셨죠. 춘천에서 프로그램 연구회를 할 때 그 제안을 가지고 오셨는데, 마침 저도 그 분야를 연구하고 있었습니다.

다른 분들은 다 맥주 마시러 갔는데 (웃음) 저와 최진영 교수님 둘이 앉아서 제안서를 썼습니다. 당시 프로그램 연구회 핵심 멤버들이 다 참여하고 기업체 2곳과 KISA가 주관이 되어, 정보보호학회 산하에 ‘소프트웨어 보안 연구회’를 만들어 행정안전부 과제를 수행했습니다. 거기서 나온 도구가 상용 도구가 되었고, 참여했던 2개 회사는 각자 상용 도구를 만들어 판매하고 있습니다. 지금 정부에 발표하는 모든 소프트웨어는 그 시큐리티 애널라이저를 통과해야 합니다. 우리가 다 같이 한 일 중 가장 큰 일인 것 같습니다.

2. PL 초창기 대표 기술: 정적 분석과 그 너머

최광훈: PL 분야가 좋은 컨퍼런스에 막 실리기 시작하던 시점의 연구 주제는 대부분 정적 분석이 아니었나 개인적으로 생각합니다. 이광근 교수님 연구 그룹에서 계속 정적 분석 관련 기술들을 점진적으로 개발하시는 것을 봤습니다. 분석기가 처음에는 이론적인 형태였다가 점점 정교해지고 소프트웨어 적용 규모가 커지는 것을 보며 오학주 교수님 등 많은 분이 교수가 되셨습니다.

이광근: (웃음) 별로 임팩트 없어요. 1년 매출이 100억이 안 되죠. 툴 시장이라는 게 큰돈이 있는 게 아니라서요. 저는 PL 분야에서 대표할 만한 기술은 하나가 아니라 ‘프로그램을 짜면 제대로 됐는지 확인하는 기술’ 그 자체라고 봅니다.

첫째는 문법 체크 (파싱) 기술인데, 이건 완전히 정립되어서 누구도 신경 안 씁니다.

둘째는 ‘타입에 맞냐’를 체크하는 기술인데, 심지어 프로그래머를 귀찮게 안 하면서 자동으로 타입 추론까지 합니다.

그다음이 정적 분석 같은 ‘타입 말고 딴 거’ 스터디이고,

또 다른 기둥이 오토매틱한 건 집어치우고 사람이 수동으로 증명 하는 것 (허 교수님, 강 교수님 담당)입니다.

소프트웨어가 제대로 짜인 건지 확인해 주는 기술들의 ‘군’이 훌륭한 성취를 이룬 것 같습니다.

3. 기술의 파도와 ‘실패’의 의미

사회자: 그럼 학생들은 정적 분석을 해야 한다는…

이광근: (강하게) 아니, 아니, 아니. 위험해요. 모든 기술에는 ‘기술의 파도’가 있습니다. 어떤 기술이 좋아지다가 더 이상 좋아지지 않는 (saturate) 시점이 오죠. 그걸 능가하는 기술은 (리서치의) ‘어두운 그늘’에서, 말도 안 된다고 생각하는 것에서 싹틉니다. 정적 분석도 위험할 수 있습니다.

사회자: PL 역사에서 가장 큰 실패 사례와 교훈은 무엇일까요?

도경구: 제가 공부를 시작할 때 ML이라는 언어가 Theorem Prover (증명기)를 만들기 위해 나왔습니다. 그때는 정말 논리적으로 AI 문제를 해결할 수 있다고 생각했고, 많은 분이 그 길을 갔는데 어느 시점이 되니 다 도망가더라고요. Theorem Prover 자체는 (원래 안 되는 문제여서) 실패했다고 봅니다.

신승철: (반론하며) 실패라고 하시니까… 연구 분야에서 ‘실패’라는 게 과연 있을까요? 트라이 (Try) 하는 것 자체만으로도 의미가 있고, 잠시 정체기는 있을 수 있어도 나중에 다시 살아날 수 있는 것 아닌가 생각합니다.

4. PL의 성공 정의와 교육 방식

최광훈: (국내 PL의 부족한 점 관련) 우리나라에서도 세계적인 개발자들이 쓰는 프로그래밍 언어가 하나 나오면 좋겠습니다. 일본의 루비 (Ruby)는 PL을 시리어스하게 전공한 분이 만든 것 같지 않은데도, 한때 웹 프로그래밍으로 각광받았습니다.

이광근: 프로그래밍 언어의 ‘성공’은 사람마다 잣대가 다릅니다. 많이 쓰는 게 성공일 수도, 잘 디자인된 게 성공일 수도 있죠.

최광훈: 루비 (Ruby)의 성공은 ‘커뮤니티’였습니다. 누가 쓰라고 하지 않았음에도 (트위터, 깃허브 등) 스스로 쓴다는 것 자체가 그 언어의 장점을 보여줍니다.

이광근: (덧붙여) 요즘은 Rust처럼 언어 커뮤니티가 전 지구적으로 탤런트들이 모여 만듭니다. (웃음) 제가 nML이라고 OCaml과 Standard ML을 짬뽕해서 만들었는데, 학생이 졸업하고 나가면 메인테인할 사람이 없어지더군요. (교수가 바빠서 못한다는 건) 핑계입니다.

사회자: 교육적인 측면에서, 초보 친화적인 (비주얼) 언어가 좋을까요, 주류 언어가 좋을까요?

도경구: 비주얼 프로그래밍이 더 쉽게 배울 수 있게 한다고 하지만, 결국 언어는 ‘더 효과를 낼 때’ 의미가 있습니다. 비주얼하게 한다고 더 논리적으로 사고하는 것 같지는 않습니다. 굳이 비주얼 랭귀지를 새로 개발하는 건 넌센스 (nonsense)가 아닐까… 파이썬 (Python) 같이 심플한 언어가 미니멈 (minimum)이라고 봅니다.

최광훈: 비주얼 프로그래밍도 찬성하지만, 그 단계를 넘어서면 맞는 언어가 또 필요합니다. 요새는 언어 자체의 문법/의미도 있지만, VS Code 플러그인이나 자동 코드 완성 같은 ‘프로그래밍 언어 환경’도 무시할 수 없습니다.

사회자: 하스켈로 수업하시는 분?

강지훈: (웃음) 옛날에 하스켈로 했다가 강의 평가에 꼴찌 먹고… 딴 걸로 옮겼습니다. 중요한 건 ‘내가 전달하고 싶은 개념을 커버하느냐’입니다. 저는 (하스켈의 특징인) 미룬계산 (Laziness) 같은 걸 하려다가 망했습니다.

최광훈: 저는 하스켈 발표의 포인트가 하스켈이 아닙니다. 저는 미룬계산이나 타입 클래스는 안 썼습니다. 조립식 자료형 (Algebraic Data Type), 함수, 강력한 타입, 패턴 매칭 정도만 갖춘 언어면 됩니다.

굳이 순수 함수형 언어를 쓴 이유는, ‘수학에 가깝다’고 학생들을 설득했습니다. 수학에는 글로벌 변수가 없잖아요? 예를 들어 타입 유추 알고리즘을 구현할 때 새로운 이름을 생성하는 것은 일종의 사이드 이펙트인데, 순수 함수형 언어는 ‘이 함수들까지는 영향을 미치는데, 저 함수는 영향이 안 미쳐’라는 것을 타입으로 기가 막히게 매김할 수 있습니다.

이광근: (강지훈 교수에게) 강 교수님이 하스켈 때문에 나쁜 점수를 받았다는 게 확실해요? (웃음) 아닐 수도 있어요. 제가 95년도에 카이스트에서 컴파일러 (번역기) 실습 언어로 Standard ML을 썼습니다. 학생들이 “C++로 갈고닦은 전사인데 이상한 총을 준다”, “배워봤자 인더스트리에서 도움도 안 된다"며 엄청나게 불평했거든요.

하지만 저는 학교에서는 ‘프로그래밍의 미래’를 겪어보는 게 더 중요하다고 생각하고, 그냥 귀 닫고 밀어붙였습니다. 몇 년 뒤 월스트리트에서 일하던 학생이 “그때 배웠던 함수형 접근 (functional approach)이 이렇게 도움이 될 줄 몰랐습니다"라고 이메일을 보냈더군요. 방향이 맞다 싶으면 (교수님들이) 눈치 보지 마시고 계속해도 될 것 같습니다.

5. AI 시대의 프로그래밍 교육

사회자: AI 시대, 기초 프로그래밍 교육은 어때야 할까요? 계산기처럼 못 쓰게 해야 할까요?

신승철: 기초 프로그래밍 개념을 배울 때는 프로그래밍 자체에 집중해야 하므로 LLM의 도움을 받게 하는 건 곤란하지 않을까 합니다. 하지만 더 복잡한 프로젝트를 할 때는 LLM도 중요한 툴이니까 활용하는, 나눠서 생각하는 게 어떨까 합니다.

도경구: 어려운 문제입니다. 요즘 제 박사급 연구원들은 LLM 도움을 엄청 받습니다. 과거 3달 걸릴 일이 일주일이면 끝납니다. 하지만 처음 배우는 사람에게 도움을 받게 하는 건 비관적입니다. 어떤 방법으로든 제어를 해서 스스로 사고해서 풀 수 있도록 해야 합니다.

이광근: 좋은 학교라면, LLM이 아직 모르는 새로운 언어, 즉 학계의 ‘새로운 아이디어’를 가진 언어를 가르쳐야 합니다. 저는 박사 받을 때까지 완벽한 c 프로그래머… c 해커였습니다. 타입이론 논문 나오면 쳐다도 안 보고 ‘이론을 위한 이론을 하는 놈들’이라고 했죠.

그러다 졸업 후 Standard ML 컴파일러 만드는 그룹에 가서 타입 추론 (Type inference) 기술의 도움을 겪고 ‘감동’ 받았습니다. 학교는 학생들에게 그런 ‘미래’를 겪게 해야 합니다.

설령 LLM이 다 아는 언어라도, LLM이 코드를 만들면 그게 맞는지 틀린지 확인하는 건 결국 사람입니다. 그걸 할 줄 알려면 프로그램에 대해 알아야죠.

최광훈: 코딩은 ‘논리적인 사고’를 키우는 것입니다. GPT가 짜준 걸 그냥 복사하면 아무것도 배운 게 없죠. 최소한 (학생이) 방향을 제시하고 교정하는 인터랙션 (interaction) 과정이 있어야 합니다.

강지훈: 저는 카이스트 2학년 수업에서 GPT를 전면 허용하고, 대신 숙제를 예년보다 3배 늘렸습니다. 제 의도는, 말을 배울 때 문법부터 배우는 게 아니듯, 많은 양질의 데이터를 (실습을 통해) 때려 넣는 것이 중요하다고 봤습니다. 이게 현대 AI 사회의 정신과도 맞지 않나 생각합니다.

6. AI 시대의 연구: 이론의 종말인가, 융합인가?

사회자: AI가 우격다짐으로 성과를 내는 분위기인데, 이론 기반의 PL 분야는 어떻게 나아가야 할까요?

신승철: PL 연구자들이 당황하거나 조급해할 수 있습니다. “우리는 의미망 (semantics) 다 알아야 하는 어려운 걸로 이만큼 했는데, 쟤네는 아무것도 모르면서 유사하게 결과를 낸다"고요. 하지만 어느 쪽도 완벽한 기술이 아닙니다. 핵심은 ‘두 개를 어떻게 잘 융합해서 문제를 해결하는가’ 입니다.

어쩌면 프로그래밍이 프롬프팅 (prompting)이 될 수도 있습니다. (사람: “이런 프로그램 원한다”) → (LLM: “이건 어떻게 할 건데?”) → (사람: 스펙 확정) → (LLM: 프로그래밍)

이광근: (신 박사 의견에 덧붙여) 허기홍 교수 아이디어는 이렇습니다. (사람: 자연어) → (LLM: 포멀 스펙 (Formal Spec) 생성) → (LLM: 코드 생성) → (LLM: 그 코드가 스펙을 만족한다는 증명 (Proof)까지 생성).

우리가 할 일은 “이 각 잡힌 스펙이 내가 얘기한 거랑 맞는지 확인하는 것"입니다. 결국 프로그래밍이 아니고 ‘하이레벨 스펙을 정확하게 쓸 줄 아는 게’ 프로그래밍이 되는 것일 수 있습니다.

‘이론의 종말’은 너무 성급합니다. 우리 분야 100년도 안 됐습니다. AI가 뭔지 결국 우리는 이해할 것이고, 모델을 만들어 예측할 겁니다.

도경구: 우리가 할 일은 요구 사항 (스펙)을 정확하게 설계하고, 결과물이 나오면 그 요구 사항대로 구현됐는지 ‘검증’만 하면 되는 것입니다.

이광근: 허 교수 아이디어로는 그 검증마저도 LLM이 증명 (Proof)을 만들어내고, 우리는 그 ‘증명’이 맞는지 ‘프로프 체커 (Proof Checker)‘로 체크만 하면 됩니다.

최광훈: 우리는 AI를 하는 사람이 아니지만, AI에 반감을 가진 건 아닙니다. ‘프로그래밍 언어 분야의 종말’은 LLM이 프로그램을 거치지 않고 바로 그 일을 해버릴 때 오는 것입니다. LLM이 (Rust든 Python이든) 프로그램을 생성했다는 것 자체가 우리 분야를 거치는 겁니다. (C3PO와 R2D2가 삐리삐리 대화하듯)

나아갈 방향은 ‘하이브리드’입니다. AI는 데이터 기반 (통계적) 접근이고, 우리 PL은 룰 기반 (분석적) 접근입니다.

예를 들어, 제가 코드 에디터에서 코드를 치다가 LLM에게 다음 코드를 생성해달라고 할 때, LLM이 그냥 통계로 생성하는 것이 아니라, 우리가 ‘전통적인 파싱 기술’로 현재까지의 파스 스택 (Parse stack)을 분석해서 “앞으로 나올 구문은 10가지밖에 안 돼"라고 알려주며 조화를 이루는 식입니다.

7. 향후 50년의 과제와 한국의 프로그래밍 언어 개발

사회자: 앞으로 50년간 풀어야 할 가장 중요한 문제는?

이광근: “이론이 종말했다"며 AI로 다 해결하자는 생각은 끔찍합니다. 만약 파싱이나 타입 추론 기술이 완성되기 전에 LLM이 나와서 “얼추” 신택스 체크 (syntax check)를 해줬다면, 지금처럼 믿을 만한 타입 시스템은 구경도 못 했을 겁니다. 문명이 위태로워져요.

최근 한 석사 논문 심사를 보니, 학생이 A, B, C를 하는데 A도 LLM, B도 LLM, C도 LLM을 썼더군요. “B에 대해서는 이미 제대로 된 알고리즘이 있어, 이놈아!” (웃음) 너무 현혹되지 말고 정신 똑바로 차려야 합니다.

도경구: 우리가 지금까지 해왔던 것들은 하나도 사라질 게 없습니다. 새로운 방법이 우리를 도와주는 것이니, 서로 공생 관계가 형성될 것입니다.

신승철: 인간은 알파고처럼 두 가지를 다 가지고 있습니다. 경험/직관으로 추측하는 능력과, 꼼꼼히 따지는 능력. 지금까지 바퀴 하나로 왔는데, AI라는 바퀴가 하나 더 생겼으니, ‘두 바퀴로 같이 가는 방향’으로 연구가 이루어져야 합니다.

청중: (DB나 OS 분야와 달리) PL 분야에서 한국 교수님들이 개발한 프로그래밍 언어가 있는지 궁금합니다.

도경구: (교육용 외에) 저희 커뮤니티에서 디자인한 언어는 없습니다. nML처럼 변형을 시도했지만, 학계에서 연구 업적으로만 인정을 해준다면 누군가 시도했겠지만… (웃음) 새로운 프로그래밍 개발은 시간적으로나 여러 면에서 시도해보지 못했습니다. 파이썬도 한 사람이 만들었잖아요. (청중을 향해) 여러분들 중에 누가 하나 만들어보면 어떨까 싶습니다.

최광훈: 그런 게 나오면 우리 커뮤니티가 업그레이드될 것입니다. 뛰어난 학생 해커가 만들 수도 있고, 혹은 마이크로소프트가 Javascript의 한계 (대규모 프로그램) 때문에 TypeScript를 만든 것처럼, 네이버 같은 좋은 소프트웨어 회사들이 “프로그래밍 언어로 문제를 해결한다"는 마인드를 가져야 할 것 같습니다.