Swift
Apple 플랫폼에서 네이티브로 갈 때의 기본값입니다. 값 의미론과 actor 격리, 그리고 Xcode에서 코드 서명과 심사로 이어지는 도구 사슬이 학습의 절반을 차지합니다.
두 번째 언어는 상황이 정해 주지 않습니다
첫 언어는 대개 스스로 고른 것이 아닙니다. 학교에서 쓰던 것, 첫 회사의 코드베이스, 처음 붙잡은 튜토리얼이 정해 줍니다. 그런데 두 번째부터는 다릅니다. 시간을 어디에 쓸지 직접 결정해야 하고, 잘못 고르면 몇 달을 들여 얻은 것이 이력서 한 줄로만 남습니다.
이때 가장 흔한 실수가 인기 순위를 기준으로 삼는 것입니다. 순위는 이미 그 언어를 쓰고 있는 사람들의 총량을 보여 줄 뿐, 지금의 나에게 무엇이 열리는지는 말해 주지 않습니다. 채용 공고가 많은 언어는 그만큼 경쟁하는 지원자도 많고, 그 시장에서 이미 몇 년째 일하고 있는 사람과 이제 막 문법을 뗀 사람 사이의 거리는 순위표에 드러나지 않습니다.
“이 언어로만 할 수 있는 일”이 더 나은 기준입니다
실용적인 질문은 하나입니다. 이 언어를 배우면, 지금은 손도 못 대는 어떤 일에 접근할 수 있는가. 이 질문으로 걸러 보면 언어는 크게 두 부류로 나뉩니다.
하나는 플랫폼이 강제하는 언어입니다. iOS 앱을 네이티브로 만들려면 Swift 또는 Objective-C를 거치게 되고, 브라우저 안에서 도는 코드는 결국 JavaScript로 내려갑니다. 관계형 데이터베이스에 무엇을 물어볼지 정하는 일은 SQL로 합니다. 이런 언어는 취향의 문제가 아니라 입장권입니다. 문법이 낯설고 도구가 불편해도, 그 분야에서 일할 생각이라면 배우는 값이 확실하게 나옵니다.
다른 하나는 팀이 고르는 언어입니다. HTTP API 서버는 Go로도, Java로도, Python으로도, PHP로도 만들 수 있습니다. 여기서는 언어가 결과물의 가능 여부를 결정하지 않고, 팀의 익숙함과 운영 방식, 채용 사정이 결정합니다. 이미 하나를 잘 다루고 있다면 같은 부류의 언어를 하나 더 배우는 일의 우선순위는 생각보다 낮습니다. 새 언어의 문법을 익히는 데 드는 시간보다, 지금 쓰는 언어로 아직 만들어 보지 않은 것을 만드는 편이 실력을 더 크게 올리는 경우가 많습니다.
물론 두 부류의 경계가 늘 뚜렷하지는 않습니다. 웹 백엔드는 어떤 언어로도 되지만, 특정 라이브러리 생태계가 사실상 한 언어에 몰려 있는 영역은 따로 있습니다. 이런 경우에도 판단 기준은 같습니다. 언어 자체가 아니라 그 언어에 붙어 있는 생태계가 대체 가능한지를 보면 됩니다.
얕은 익숙함을 모으면 아무것도 남지 않습니다
이력서에 언어를 여섯 개 적어 두고 정작 어느 하나로도 장애를 끝까지 추적해 본 적이 없는 경우가 있습니다. 튜토리얼을 완주하는 일과 그 언어로 일하는 일 사이에는 큰 간극이 있습니다. 문법은 며칠이면 읽히지만, 실제 시간이 들어가는 곳은 따로 있습니다. 빌드가 깨졌을 때 로그를 읽는 법, 의존성을 올렸을 때 무엇이 부서지는지 아는 법, 느려졌을 때 어디를 재는지 아는 법, 그리고 그 언어 특유의 실패 방식에 익숙해지는 일입니다.
스스로를 점검하는 질문은 이렇습니다. 그 언어로 만든 것을 테스트하고 배포까지 해 봤는가. 남이 쓴 코드를 읽고 고쳐 봤는가. 에러 메시지를 보고 원인을 짚을 수 있는가. 셋 다 아니라면 그 언어는 아직 도구가 아니라 읽어 본 문서에 가깝습니다. 반대로 하나라도 끝까지 해 본 언어가 있다면, 두 번째 언어는 훨씬 빨리 익습니다. 배워야 할 것이 프로그래밍 전반이 아니라 차이점으로 좁혀지기 때문입니다.
새 언어를 배울 때 가장 빠른 방법은 새 프로젝트가 아니라 이미 만들어 본 것을 다시 만드는 것입니다. 도메인을 이미 알고 있으면 낯선 부분이 언어와 도구로 좁혀지고, 두 언어가 같은 문제를 어떻게 다르게 푸는지가 선명하게 보입니다.
언어를 하나 더 배울 때 확인할 것
- 그 언어가 아니면 접근할 수 없는 플랫폼이나 런타임, 생태계가 명확히 있습니까.
- 몇 달 안에 그 언어로 끝까지 만들어 볼 대상이 정해져 있습니까. 없다면 배운 내용은 대부분 휘발됩니다.
- 주변에 코드를 봐 줄 사람이나 읽을 만한 실제 코드베이스가 있습니까.
- 지금 주력 언어로 아직 해 보지 않은 영역(테스트, 성능 측정, 배포 자동화)이 남아 있다면 그쪽이 먼저입니다. 지금은 아닙니다.
- 이유가 “요즘 많이 쓴다더라” 하나뿐이라면 지금은 아닙니다. 용도를 한 문장으로 설명할 수 있을 때 다시 판단하십시오.
이 목록을 읽는 순서
아래 카드는 각 언어가 어떤 팀과 어떤 문제에 맞는지를 정리한 문서로 이어집니다. 이미 마음에 둔 언어가 있다면 해당 카드부터 열어 어울리지 않는 경우를 다룬 문단을 먼저 읽으시길 권합니다. 장점보다 한계가 결정에 더 도움이 됩니다. 아직 정하지 못했다면 언어 비교에서 같은 개념이 언어별로 어떻게 달라지는지 훑어보는 편이 빠릅니다. 비동기 처리나 에러 처리처럼 언어의 성격이 가장 크게 갈리는 주제를 나란히 놓고 보면, 설명을 읽는 것보다 취향과 필요가 빨리 드러납니다.
Platform-Bound
분야가 정해지면 선택지가 좁아지는 언어들
