이 기사에 대하여

Turbo Pascal, Delphi, C#, TypeScript를 만들고 Microsoft에서 30년째를 맞이하고 있는 Anders Hejlsberg의 세션입니다. 40년 동안 계속해서 언어를 설계해 온 사람이 AI에 대해 무엇을 말하는지가 핵심 청취 포인트였습니다.

1. 언어 설계는 90%가 같고, 새로운 것은 10%뿐이다

갑자기 아주 직설적인 이야기부터 시작합니다.

솔직히 말하면, 언어 설계는

90%가 같고, 어떤 언어든 새로운 것은 10% 정도다

40년 동안 해오며 얻은 결론이 이것이라는 점이 흥미로운 부분입니다. 뒤집어 말하면, 그 10%에 무엇을 선택하느냐가 언어의 성격을 결정한다는 뜻이기도 합니다.

2. async/await의 정체는 「컴파일러가 작성하는 스테이트 머신(State Machine)"

개인적으로 가장 와닿았던 부분입니다.

비동기 처리를 「역전된 아키텍처(Inverted Architecture)」로 작성하려고 하면, 스테이트 머신(State Machine)을 직접 만들어야 합니다. 상태를 스택(Stack)에서 객체(Object)로 옮기고, 어디서 멈췄는지를 기억하며, 거대한 case 문으로 로직 전체를 감싸는 방식입니다. Hejlsberg는 이를 「해독하기가 악몽 같은 구조」라고 표현합니다.

하지만, 순차 실행 코드를 스테이트 머신으로 변환하는 것은 기계적으로 가능합니다.

어디서 yield 하고 싶은지를 나타내는

구문을 도입하면, 컴파일러가 스테이트 머신을 작성해 줍니다. 그것이 바로 await 입니다.

await

라고 한 단어만 쓰면, 그 악몽이 컴파일러 측에 숨겨지게 됩니다. 매일 작성하면서도 정체를 모른 채 사용하고 있었던 사람이 많을 것입니다 (저도 그랬습니다).

3. 진정한 크로스 플랫폼 언어는 Java가 아니었다

Web이 확산되는 과정에서의 깨달음으로서, 다음과 같이 회상합니다.

놀랍게도,

진정한 크로스 플랫폼 언어는 Java가 아니었다. JavaScript였다

계기 중 하나는 Outlook.com 팀이 C# 팀에 가져온 「Script Sharp」라는 도구였습니다. **C#을 JavaScript로 크로스 컴파일(Cross-compile)**하여, 브라우저에서 C# 앱을 구동하는 것입니다.

왜 그런 일을 하고 싶은지 묻자 「성숙한 언어와 성숙한 도구를 사용할 수 있기 때문」이라고 답했습니다. Visual Studio를 사용할 수 있고, 프로젝트 관리가 가능하며, JavaScript로는 할 수 없는 것들을 할 수 있다는 것이죠.

이 말을 들은 Hejlsberg 측의 반응이 TypeScript로 이어집니다.

그렇다면,

JavaScript 자체를 고치는 편이 더 나은 접근 방식이 아닌가

4. 타입 시스템(Type System) 없이는 좋은 도구를 만들 수 없다

TypeScript가 탄생한 이유는 타입 그 자체보다 **도구(Tool)**에 있었습니다.

경험을 통해 알고 있었습니다.

타입 시스템 없이는 좋은 도구를 만들 수 없다. 적당한 것은 만들 수 있지만, 결코 스케일(Scale)할 수 없다

왜 스케일할 수 없는가? 코드 안에 의도를 기술할 수 없기 때문이라고 합니다. 형식화할 방법도 없고, 해석할 방법도 없으며, IDE에서 보완(Completion)도 리팩터링(Refactoring)도 정의 이동(Definition Jump)도 참조 검색도 할 수 없기 때문입니다.

그로부터 「

JavaScript의 슈퍼셋(Superset)을 만들어서 타입 시스템을 더하고, 컴파일 시점에 없애버리면 된다

」라는 아이디어가 싹텄습니다.

5. Microsoft 내부에서 오픈 소스로 만들기 위해서는 「세금」이 필요했다

이 부분은 조직 운영 측면에서 흥미로웠습니다.

Microsoft의 독점적(Proprietary) 라이선스 언어로는 JavaScript 생태계에 받아들여질 가능성이 제로였습니다. 오픈 소스로 만들 수밖에 없었습니다.

다만, 사내에서 이를 통과시키기 위해서는 매우 힘들었다고 합니다.

실현하기 위해서는 어느 정도 끌어와야 했고,

우리는 어느 정도 「세금」을 지불했다

「세금」의 내용은 Microsoft 자체 리포지토리인 CodePlex에 두는 것이었습니다. 「그곳에는 아무도 없었다」. 처음 2년 동안은 그곳에 머물렀고, 정적만이 감돌았습니다. 2014년에 GitHub로 옮겨서야 비로소 채택이 움직이기 시작했다고 합니다.

나아가, 이행은 워크플로우(Workflow) 자체를 바꾸었다고 이어집니다.

오픈 소스(Open Source)와 「오픈 개발(Open Development)」은 다릅니다. 처음에는 기술적으로는 오픈 소스였지만, 오픈 개발은 아니었습니다.

리포지토리에 소스를 던져놓고, issue를 긁어모아 사내 트래커(Tracker)에 넣는 방식의 운영이었다고 합니다. GitHub로 옮기면서 워크플로우 전체가 오픈이 되었다고 합니다.

6. IDE는 「계속 망가지고 있는 코드」를 200밀리초 만에 해석하고 있다

컴파일러를 서비스로서 만든다는 이야기입니다.

IDE 내에서는 코드가 항상 깨져 있습니다. 타이핑하는 도중이기 때문입니다. 그럼에도 구문적·의미적으로 분석해야 합니다. 마침표(.)를 누른 순간에 '다음으로 올 것은 무엇인가'에 답하려면, 마침표를 찍은 대상의 타입을 알아야 하기 때문입니다.

그리고

이 모든 것이 200밀리초 이내에 일어나야 합니다. 그렇지 않으면 사람들은 IDE가 느리다고 느낍니다.

그렇다면 50만 줄이 있다면 어떻게 할까요? 전체를 컴파일할 수는 없습니다. 그래서 철저하게 지연시키고 필요한 부분만 해결하는 설계로 되어 있다고 합니다. 500개 파일 중 499개 파일 분량의 AST는 미리 만들어서 재워두고, 편집 중인 1개 파일만 업데이트합니다.

그래서

전부 다시 하는 것보다 500배 빠릅니다.

'교과서가 전통적으로 가르치는 컴파일러 작성 방식과는 완전히 다른 방식이다'라는 마무리가 좋았습니다.

7. AI는 '코드 작성의 즐거움'을 조금 빼앗는다

AI 이야기가 나옵니다. 먼저 역할의 변화부터입니다.

어떤 의미에서, 우리는

프로젝트 매니저가 되어가고 있습니다. 에이전트라는 이름의 주니어 프로그래머 군단을 거느리고, 대량의 코드를 뿜어내게 합니다. 하지만 전체 그림을 파악하고 리뷰하는 인간이 필요합니다.

그 위에 솔직한 감상을 덧붙입니다.

저는 계속 코드 짜는 것을 좋아했습니다. 작동했을 때의 성취감이 최고였습니다.

어떤 의미에서, AI는 그 즐거움을 조금 빼앗습니다.

하지만 거기서 끝나지 않습니다.

하지만 리뷰 프로세스 자체를

지금보다 훨씬 재미있게 만들 수 있을 것입니다.

지금은 diff가 나열되어 있을 뿐이라, 무엇이 무엇인지 스스로 해독해야 합니다. 더 이해하기 쉬운 보여주는 방식이 있어야 하고, AI가 변경점을 설명해주고 가이드하면서 진행해 주면 좋을 겁니다. 그 공생 관계를 더 만들어낼 필요가 있다고 말입니다.

8. 책임은 AI가 아니라 프로그래머에게 있다

소위 '바이브 코딩(vibecoding)'에 대해입니다.

바이브 코딩은

작동하는 동안은 최고입니다. 하지만 주제에서 벗어나는 순간, 무슨 일이 일어나고 있는지 전혀 알 수 없게 됩니다. AI에게 고치라고 해도 설득할 수가 없습니다.

그 위에 선을 긋습니다.

여기서 무슨 일이 벌어지고 있는지를 이해할 책임으로부터 도망칠 수는 없습니다. 그것은 프로그래밍이 아닙니다. 그리고 결국,

프로그램의 책임은 AI에게 있는 것이 아니라, 프로그래머에게 있습니다.

AI에게 '부끄러움을 알라, 해고다'라고 할 수 없을 것입니다.

AI는 어디까지나 생산성을 높이기 위한 도구라는 것이 결론입니다. 다만 '프로그램 작성 방식은 확실히 변할 것이다. AI가 100배 빠르게 칠 수 있는 것을 굳이 스스로 타이핑할 의미는 없다'고도 말합니다. 부정하는 것은 아닙니다.

9. AI에게 맡기려면 TypeScript가 유리한 이유

여기는 실무에 직결되는 이야기였습니다.

타입 정보가 AI를 올바른 방향으로 이끌어줍니다. 더 좋은 프로그램을 생성하게 합니다.

다만 '타입을 많이 적으면 된다'는 것이 핵심이 아닙니다.

모든 것에 타입 어노테이션(type annotation)을 강제하면, AI는 오히려 실수를 늘립니다. 모든 타입을 추적해야 하고, 여러 번 반복할 필요가 생기기 때문입니다.

타입은

문맥이 없는 상황에서 중요하고, 추론은 DRY 원칙(Don't Repeat Yourself)에서 중요합니다. 그리고 토큰 수가 적을수록 AI의 효율이 높아집니다.

'문맥이 없을 때 타입을 명시할 수 있고, 문맥이 있을 때는 추론할 수 있다. 이 조합이 딱 좋다'라는 설계 판단이 결과적으로 AI 시대에 효과를 보고 있다는 이야기입니다.

한편 다른 부분에서는 'AI에게 가장 적합한 언어는 AI가 학습 데이터에서 가장 많이 본 언어다'라고도 말합니다. 새로운 언어를 만들어서 AI 시대를 대비하자는 발상에는 찬물을 끼얹고 있습니다.

10. 왜 언어 논쟁은 끝나지 않는가

마지막으로, 프로그래머가 언어에 집착하는 이야기입니다. 문화나 종교와 가깝다는 맥락에서 이야기됩니다. 기술적인 우열의 논쟁처럼 보이지만, 실제로는 다른 것이 움직이고 있다는 지적이었습니다.

감상

'AI는 코드 작성의 즐거움을 조금 빼앗는다'고 솔직하게 말한 뒤, '그래서 리뷰를 재미있게 만들자'로 마무리하는 것이 이 사람답다고 생각했습니다. 빼앗긴 쪽에서 멈추지 않습니다.

그리고 async/await 이야기가 상징적이었습니다. 악몽 같은 정형 작업을 컴파일러에 떠넘기는 발명을 40년 동안 해온 사람이, AI를 보고 같은 구조를 발견합니다. '본질은 변하지 않았다'라는 주장의 설득력이 여기에 있습니다.

타입과 추론 이야기 역시 단순한 TypeScript 홍보가 아니라 '토큰이 적을수록 효율이 높아진다'는 구체적인 이유까지 내려오기 때문에, 내일부터 사용할 수 있는 판단 자료가 되었습니다.

원본 영상

TypeScript, C# 그리고 Turbo Pascal과 Anders Hejlsberg

The Pragmatic Engineer

일본어 자막이 포함된 다이제스트 버전(약 10분)도 공개되어 있습니다.

• 게시 전 예측: 같은 날 2개를 제작하여 동시에 게시
• 지난 해설: 「AI는 x10, 컴파일러는 x1000」 Linus Torvalds가 AI에 대해 이야기한 회차
• 영상: TikTok @talks.tldr.jp

Discussion