Rust, Python, TypeScript: 새로운 프로그래밍 3대장(Trifecta)
(smallcultfollowing.com)- Rust, Python, TypeScript가 앞으로 소프트웨어 개발의 중심 언어로 부상할 것으로 예상됨
- AI 코딩 도구의 보편화로 인해 개발자의 언어 충성도가 약화되고, 실용적이고 생태계가 강한 언어가 선택받게 됨
- 아이디어 중심 프로그래밍(idea-oriented programming) 패러다임이 등장, 개발자는 설계와 검토에 집중하고 구현은 AI에게 맡기는 구조로 변화함
- 이 세 언어는 고급 타입 시스템과 강력한 패키지 매니저 생태계를 모두 갖추고 있어, AI 활용과 협업, 오류 방지에 유리함
- 에러 메시지 품질, 생태계, 플랫폼 연계성 등도 점점 더 중요한 기준이 되고 있음
Rust, Python, TypeScript가 떠오르는 이유
- Rust는 시스템 소프트웨어, 고성능이 필요한 영역, 타입 안전성과 메모리 효율성이 탁월함
- Python은 실험·프로토타이핑·수학/과학 라이브러리 활용에 최적, 빠르게 아이디어를 검증 가능
- TypeScript는 웹, 브라우저, 다양한 플랫폼에 바로 적용 가능하며, 강력한 타입 시스템과 npm 생태계로 확장성 확보
AI가 바꾸는 개발 패러다임: 아이디어 중심 프로그래밍
- AI 코딩 도구(Large Language Model) 보편화로 프로그래밍이 '아이디어 구상→AI가 구현→사람이 설계/검토'로 변화 중
- Vibe coding은 즉흥적·모호한 명령에 가깝지만, Idea-oriented programming은 설계와 구조, 지속 가능한 원칙에 집중
- 개발자는 주요 설계/방향 제시, AI는 반복적/구현적 작업 담당, 아키텍트와 견습생의 관계에 비유
언어 선택 기준의 변화
- 예전에는 자신이 잘 아는 언어(예: Rust)로 빠르게 작업했으나, AI와 함께 일할 땐 필요한 라이브러리, 성능, 플랫폼 연계성이 더 중요해짐
- 프로젝트에 따라 Python(머신러닝), TypeScript(웹·VSCode Extension), Rust(기본 선택) 등 상황별 최적 언어를 선택
타입 시스템의 중요성
- AI 코딩 보조 환경에서는 고급 타입 시스템이 더 중요해짐
- Rust와 TypeScript는 상태와 데이터 유효성, 실수 방지를 코드 레벨에서 강제, AI가 실수할 확률도 줄어듦
- Python 역시 mypy, pydantic 등 설정을 통해 타입 안정성을 확보 가능
생태계와 패키지 매니저의 가치 상승
- AI와 함께 개발할 때는 대형 라이브러리 활용이 쉬워져서, 생태계의 크기와 패키지 매니저의 품질이 더욱 중요해짐
- Rust(cargo), TypeScript(npm), Python(uv 등) 모두 현대적인 패키지 매니저를 갖춤
사소한 문법과 워크어라운드는 덜 중요해지지만, 에러 메시지와 가이드 품질은 여전히 중요
- LLM(AI)은 반복적 문법 실수는 빠르게 고치지만, 에러 메시지/가이드가 명확해야 효과적으로 보정 가능
- Rust 커뮤니티의 언어 친화성(ergonomics) 노력처럼, AI도 좋은 에러 메시지를 활용해 더 나은 코드를 생산
결론: LLM이 강력한 개발 도구를 모두에게 열어줌
- 아이디어 중심 프로그래밍 시대에는 주니어도 Principal Engineer급 설계/지휘 경험 가능
- 코딩 자체의 ‘플로우’가 줄어든다는 우려도 있으나, 설계와 아이디어 중심의 개발 경험이 더 가치 있어질 전망
► AI와 함께하는 시대, Rust, Python, TypeScript가 강력한 타입, 생태계, 플랫폼 지원으로 개발 현장의 표준으로 자리 잡고 있음
아직도 고성능 코드에서 C에서 Rust로 갈 충분한 이유를 못찾겠습니다. Zig 같이 문법이 그나마 단순한 쪽이 e2e 개발에 나은 것 같고, 나머지는 어차피 프로파일링 후 고수준 언어에서 호출하는 부분만 구현하는 구조인데 (python 사용자), Rust 사용하면 GIL 컨트롤같이 다른 언어랑 상호작용 개발 비용이 의외로 꽤 됩니다. C 는 애초에 다른 언어들이 기대하고 있죠.
c에서 rust 로 이유는 사실 생산성이라고 말씀드리고 싶습니다. 메모리 안정성 지원도 좋지만 cargo 만 놓고 생각해봐도 넘어갈 이유가 된다고 봅니다.
python 확장모듈을 만들때는 언어를 떠나 GIL 처리는 항상 까다롭습니다. 이 부분은 C/C++도 마찬가지구요 물론 확장모듈 작성에 도움을 주는 라이브러리, 도구를 사용할 경우는 예외입니다만 RUST 에도 PyO3 라는 훌륭한 크레잇이 있습니다.
또한 c개발자 입장에선 당연히 zig가 다루기 좋습니다. 기본적으로 zig 자체가 c 컴파일러이기도 해서 헤더파일을 그냥 수입해서 사용할 수 있을 정도니까요.
그렇게 생각해볼 수도 있네요. 제 경험에서는 PyO3 보다 python.h (zig 가 좋은 대안인 이유이기도 한) 가 OS나 벡터라이즈 레벨로 내려갔다 오기가 훨씬 쉬웠지만 메모리 관리 걱정이 없다는 측면에서는 일정 규모 이상이면 Rust 쪽이 장기 생산성이 높을 수 있겠습니다.
C가 쉬운 이유는 현대 메이저 언어들 - Python/TS/Go/PHP/Java 모두의 기반이거나 유사한 문법을 가지고 있기 때문에 단순히 문법을 쉬운 걸 넘어서서, 언젠가 만나게 될 언어이거나 언젠가 만났던 언어이기 때문이겠죠. 반면 Rust는 그 반대 입장이라 높은 가치에 비해서 팀에 도입하려면 상당한 노력이 필요합니다. 진화적 언어라기보다 혁신적 언어라서라고 생각합니다.
Rust의 rayon 크레이트 만든 분이 작성한 글인 것 같네요.
Python, TypeScript는 지금도 중심 언어인거같긴한데...
Rust는 아직 그정도 위치는 아니죠. 어렵다는 인식때문인가 싶긴한데
LLM이 진입장벽을 낮춰줘서 Rust도 중심언어로 부상됐으면 하네요.
Niko Matsakis는 rayon을 넘어서 Rust의 아버지에 가까운 포지션입니다. 물론 Graydon Hoare가 창시자이지만 언어의 가장 중요한 부분들에 가장 많이 기여한 건 Niko라 할 수 있습니다.
셋중에 익숙한건 TS, 할줄아는건 Python, 잘 모르지만 하고싶은건 Rust...
뭐가됐든 저 세개중에 Java가 들어가지 않았다는건 다행중 더 다행
코더=>기능 개발 아키텍처를 짜는 개발자 => 더 큰 아키텍처(시스템, 네트워크, 보안) => 기획
으로 경험이 발전해가는 흐름에서 코더가 현장에서 배울 수 있는 기회가 더 적어질 것 같네요
아이디어 중심 프로그래밍이 대세가 된다면,
적어도 혼자서 ai 기반 풀스택은 다룰 줄 아는 코더가 기본이 될 것 같은 느낌 ㄷ