자바스크립트라니 그것도 프로그래밍 언어야?

우물에서 벗어나 성장하는 축지법

자바스크립트라니 그것도 프로그래밍 언어야?

닷컴 버블 시절, 1972년에 데니스 리치(Dennis Ritchie)가 주도해 개발한 C 언어의 위상은 대단했다. 하드웨어를 직접 제어하는 저수준 언어로써 시스템 프로그래밍, 임베디드 시스템, 운영 체제 개발 등에 쓰였다. 그당시 C 언어를 사용하는 프로그래머는 다른 언어를 얕봤다. 특히 웹 프로그래밍에 대한 상대적 우월주의가 있었다.

폴리글랏 프로그래밍 시대에 살고 있는 지금 생각하면 부질 없는 생각이고, 그때 당시 기준으로도 별로 좋은 관점은 아니지만, 실존했던 굴절된 단상이 분명히 존재했다. 더한 표현을 하고 싶지만, 시대가 낳은 희대의 꼰대주의라고 적당히 미화해본다.

20여년이 훌쩍 지난 지금은 프로그래밍 언어가 700개가 넘는다고 한다. 웹 프론트엔드에서는 HCJ(HTML, CSS, JavaScript)가 표준 기술 스택이다. 터보 8(Turbo 8)에서 지원을 제거한다 발표한 타입스크립트도 여전히 강력한 웹 프로그래밍 언어다. 웹 프론트에는 리액트, Vue.js, Next.js 같은 수많은 웹 프레임워크가 있다.

백엔드에서는 자바스크립트, 자바, 파이썬, Golang, C++, C#, 코틀린, 스칼라를 주로 쓴다. Node.js(자바스크립트), 스프링(자바), 장고/FastAPI(파이썬) 등 언어별로 강력한 서버 프로그램이 자신을 낳은 프로그래밍 언어를 든든하게 뒷받침해주고 있다.

데이터 분석에서는 전통적으로 R이 원톱이었지만, 지금은 많은 부분 파이썬에게 물려주었다. 특히나 머신러닝/딥러닝 영역은 파이썬의 독무대라고 해도 과언이 아닐 정도다.

예전에 꼬꼬마 개발자일 때 디바이스 드라이버를 개발했다. 회사에서 디바이스 드라이버를 개발할 줄 아는 사람이 없었다. 첫 기술 도입인데 주니어인 내가 맡았다.

그당시에는 구글링이 아직은 갓글링이 아니었다. 구글은 1998년 9월에 창립한 신생 엔진으로 우리나라에서 쓰기에는 느렸다. 대개는 야후를 쓰고 나는 엠파스를 썼다. 스택오버플로도 없었다. 스택오버플로는 2008년에 개설할 미래의 프로그래밍 Q&A 사이트다. 그나마 풀뿌리 개발자 커뮤니티들이 있어 다행이었다. 윈도우 디바이스 드라이버 정보는 CD로 제공되는 MSDN에서 찾을 수 있었다. 지금은 웹에 무료로 공개되어 있지만 당시는 유료 구독자에게만 제공되었다. 그리고 크리스 칸트의 《Writing Windows WDM Device Drivers》, 찰스 페졸드의 <Programming Windows> 같은 책들이 출간되어 부족한 정보를 채울 수 있었다.

결론적으로 품질과 기한을 맞혀 개발을 완료했다. 깃도 없고, 깃허브도 없고, 코드 리뷰도 없고, 짝 프로그래밍도 없었다. “이렇게 하면 되는 것인가?” 의문이 들었다. 그 일, 그다음 일, 그다음 일도 늘 그랬다.

그러던 어느날  《조엘 온 소프트웨어》(박재호 역, 조엘 스폴스키 저)라는 책을 읽게 되었다. 모든 버그를 고칠 필요가 없으며, 개발자는 스톡옵션으로 붙잡을 수 없으며... 당시로는 충격적인 이야기가 가득했다. 바깥 세상 소프트웨어 개발은 이렇게 돌아가는구나! 머리가 띵했다. 조엘이 주장한 ‘더 나은 코드를 위한 12단계’는 회자되었다.  

1. 소스코드 관리 시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?12. 무작위 사용편의성 테스트(방금 막 작성한 코드를 다른 사람에게 사용해보도록 하는 기법)를 추가하고 있습니까?

드디어 먼저 경험한 선배의 제대로 된 조언을 듣게 된 것이다. 읽는 내내 모든 것에서 행복감이 밀려왔다.  먼저 앞서간 선배의 노하우를 영접할 수 있는 그런 책은 당시로는 흔치 않았다. 지금은 애자일이 큰 축을 담당해 소프트웨어를 개발하는 더 나은 방법을, 강연으로 책으로 블로그로 흔히 만날 수 있는 시대가 되었다.

내가 보기에는 너무나 풍요로운 개발 환경인 지금에도, 적지 않은 주니어 개발자들은 “내가 지금 제대로 하고 있는 것인가” 자문하고, 고민한다. 그리고 그러한 고민을 대개 주변인에게 물어본다. 그런데 그거 아는가? ‘나는 내 주변인의 평균이다.’ 모든 면에서 그렇다. 나와 똑같은 사람이 더 나은 조언을 할 수 있는 걸까?

SW정책연구소 '2022년 SW산업 연간보고서'에 따르면 순수 소프트웨어 개발자는 17만 명에 이른다. 20년이 넘는 기간 우리나라 소프트웨어 역량은 그 규모만큼이나 질적인 면에서도 성장했다. 소프트웨어를 핵심 역량으로 하는 유니콘 기업이 그저 비즈니스 모델만으로 탄생하는 건 아니니 이 말은 믿어 의심치 말자. 그런 멋진 유니콘 기업에는 역량있는 CTO부터 시니어, 주니어 개발자가 공존한다. 짝 프로그래밍을 시행하고, 코드 리뷰도 한다. 깃과 깃허브가 버전 관리를 투명하게 해주고, CI/CD를 훌륭하게 제공해주는 젠킨스 같은 프로그램도 사용한다. 기술 기획을 하는 프로덕트 매니저/오너/기획자가 따로 있고, 개발자도 있고, 품질 관리를 하는 QA도 있다. 소프트웨어 개발에서 인적 자원의 역할도 다변화되어왔다. 벽세지감이 느껴질 정도로 모든 게 좋아졌다.

오늘날 주니어는 과거의 주니어보다 더 나은 기술력을 가졌다고 생각한다. 적어도 나와 동기들을 떠올려보면 그렇다. ‘팩트다.' 그럼에도 오늘날 주니어들의 고심은 전혀 달라지지 않은 것 같다.

한 해에 IT 개발서가 몇 백 권이 출간된다. 원하는 기술은 책으로, 강의로, 그리고 오픈소스 매뉴얼에서 얼마든지 접할 수 있다. 물 반 고기 반이다. 그물을 던지면 원하는 기술 관련 정보를 얼마든지 얻을 수 있다. 그런데 이상하게도 더 많은 기술을 습득한다고 고민이 해결되지 않을 것이다. 사람은 밥을 먹고 공기도 마셔야 한다. 소프트웨어 영역에서 기술은 밥이고 경험은 공기다.

“결국 프로그래밍, 프로젝트, 소통, 협업을 해봐야 숙련도가 높아집니다. 얼마나 열심히 하냐에 따라 공부와 숙련에 드는 시간이 짧아질 수 있습니다. 반면 경험을 쌓는 데 드는 시간은 단축하기가 어렵습니다. 경험은 성공과 실패를 해봐야 하고, 이런 사람 저런 사람도 만나봐야 합니다. 다행인 것은 강연이나 책으로 다른 사람 경험을 간접 습득하면 시간을 줄일 수 있습니다. 왜 많은 사람이 책을 강조하는지 이제 알겠죠?” 《개발자로 살아남기》(박종천)

블리자드, 삼성전자를 거쳐 현재 몰로코에서 근무하는 박종천 30년 개발자의 주옥같은 말씀이다. 직접 경험하여 시행착오하는 시간을 줄이는 방법으로 책은 훌륭한 도구다. ‘인간이 만날 수 있는 가장 정제된 그리고 대개 사실인 정보는 책뿐이다.’라고 단언한다.

글이 길었다. 이글의 요지를 이제서야 말하자면

“여러분은 이미 훌륭한 기술을 가지고 있으니 그만큼 경험도 쌓으세요.”

경험을 쌓을 앞서간 선배들의 이야기를 담은 책을 추천한다. 모조리 내가 10번 읽은 책이니 믿고 읽고 나면 “추천해주셔서 감사하다”는 말이 절로 나올 것이다. 그러니 믿고 봐주시길.

《개발자로 살아남기》 
개발자로 은퇴하고 싶다면 필독!
한글과컴퓨터, 블리자드, 넥슨, 삼성전자, 몰로코 출신 개발자의 30년 커리어패스 인사이트

《개발자 원칙》, 《데이터 과학자 원칙》
테크 리더 9인이 말하는 더 나은 개발자로 살아가는 원칙과 철학
크게 되신 분들은 저마다의 원칙이 있는 법! 롤모델을 찾을 수 있는 기회니까 필독!

《리그 오브 레전드 플레이어 중심주의》
미션 임파서블한 과제를 성공적으로 이끈 ‘라이엇 게임즈’의 미션과 인사이드 이야기  
더 나은 조직 문화를 만들고 싶다면 필독!

《요즘 우아한 개발》
‘배달의민족’을 만든 우아한형제들의 개발, 온보딩, 시행착오를 적나라하게 보여주는 책
프로덕트의 성장과 개인의 성장을 이끄는 간접 경험을 원기옥을 시전하고 싶다면 필독!