개발자가 고 언어를 좋아하는 8가지 이유, 그리고 싫어하는 8가지 이유
2007년, 구글의 몇몇 프로그래머가 소프트웨어를 만들기 위한 여러 옵션을 살펴봤지만 마음에 드는 것을 찾을 수 없었다. 이들은 월드 와이드 웹을 위한 데이터를 끊임없이 저장하고 전송하는 수백만 라인의 코드를 관리해야 했고 이 코드는 전 세계의 네트워크에서 수백만 개에 이르는 연결을 처리해야 했다. 데이터 경로에는 경합과 동시성에 따른 문제가 가득했다.
기존 프로그래밍 언어는 별로 도움이 되지 않았다. 기존 언어는 게임, 데스크톱 관리, 또는 웹 브라우저가 등장하기 전부터 존재했던 다른 일반적인 작업을 관리하기 위한 용도로 만들어졌다. 이러한 언어의 매끄럽지 못한 부분이 마음에 들지 않았던 구글 코더는 더 나은 방법을 고민하기 시작했다. 구글에 필요한 모든 안전과 보안을 충족하면서 단 몇 줄의 코드로 I/O 작업을 처리할 수 있는 방법이 없을까?
이 질문에 대한 답은 '없다'였다. 그래서 표면적으로 C 또는 자바와 비슷한 간단한 언어인 고랭(Golang)을 만들었다. 첫 공개 버전은 2009년에, 첫 1.0 버전은 2012년에 출시됐다. 구글은 지금도 고 언어에 계속 투자하고 있다. 기사 작성 시점에 최신 안정화 버전은 1.22.5다.
구글 내에서 고 언어는 인프라의 많은 부분을 움직인다. 구글 외부의 많은 프로그래머도 고를 채택했다. 고는 최근 티오베(Tiobe) 인덱스에서 상위 10개 언어에 포함됐으며 현재 8위를 차지하고 있다.
놀라운 성공은 많은 찬사를 받았지만 신랄한 비판도 따랐다. 많은 경우 똑같은 기능을 두고 비난과 칭찬이 동시에 쏟아진다. 어떤 개발자가 좋아하는 고의 특성을 또 다른 개발자는 싫어한다.
고는 배우기 쉽다
고 언어에는 복잡한 기능이나 유별난 부분이 많지 않다. 고 설계자들은 의도적으로 빠르게 배울 수 있는 언어를 만들었다. 이런저런 부가 기능을 더하는 대신 구글에서 맡은 일을 수행하는 데 필요한 최소한의 기능만 갖추도록 했다. 이 말은 좋은 아이디어라고 다 받아들이는 것이 아니라 프로그래머에게 필요한 이상적인 비전에 집중했다는 의미다.좋아하는 이유 : 단순한 언어일수록 새로운 프로그래머와 팀원이 배우기 쉽다. 마스터해야 할 기능이나 구조의 수가 적으므로 숙련된 프로그래머라면 하루만에 어느정도 익힐 수 있다. 기존 방식에 익숙하더라도 고의 새로운 트릭을 빠르게 가르칠 수 있으므로 프로젝트 인력을 꾸리기도 더 쉽다. 뿐만 아니라 이상한 곳에 불쑥 등장하는 낯설거나 알 수 없는 구조가 없으므로 코드를 읽기도 더 쉽다.
싫어하는 이유 : 단순함이 무조건 나쁘지는 않지만 문제는 빠진 부분이다. 마녀가 축소판 주문 서적을 선택할까? 쿼터백이 소수의 플레이만 포함된 플레이북을 선택할까? 일부 프로그래머는 고를 사용한 프로그래밍이 한 손을 뒤로 묶고 코딩을 하는 것과 같다고 느낀다. 다른 언어 설계자가 세상에 내놓은 온갖 좋은 기능이 고에는 없다. 간소함을 위한 큰 대가다.
고는 인기에 영합하지 않는다
고를 처음 개발한 사람들은 작은 언어를 만들기를 원했고, 그 목표를 위해 다른 언어에서 볼 수 있는 많은 인기 있는 기능을 뺐다. 고는 간소화된 언어다. 해야 할 일을 하지만 부가적인 기능은 없다.좋아하는 이유 : 많은 개발자가 고의 간소함을 높게 평가한다. 능숙하게 다루기 위해 수십 가지의 기능에 대한 전문 지식을 습득하거나 유지할 것을 요구하지 않는다. 코드를 읽어 내려가다가 이전에는 본 적 없는 구조를 발견하게 될 일이 없다.
싫어하는 이유 : 사람마다 좋아하는 기능과 트릭이 있지만 고에서는 그 기능을 찾을 수 없을 가능성이 높다. 개발자들은 종종 고를 사용해서 할 수 있는 일을 코볼이나 자바, 또는 선호하는 다른 언어에서 한 줄로 할 수 있다고 불평한다.
C 기반의 구문
고를 만든 사람들은 유닉스에 깊게 뿌리를 둔 사람들이다. 고의 구문은 C, 또는 자바나 C#과 같이 C를 기원으로 하는 언어를 사용해본 사람들에게는 매우 친숙하다. 이들에겐 고의 중괄호와 유형(type) 특성이 익숙하다. 전통적인 C에서 거친 부분을 다듬고 몇 가지 세부 사항을 간소화해서 더 현대적으로 만들었지만 대체로 C에서 시작된 전통을 그대로 계승한다.좋아하는 이유 : C 스타일과 함께 성장한 프로그래머는 고의 대부분을 직관적으로 이해한다. 구문을 매우 빠르게 익힐 수 있고 C 또는 자바에서 불편했던 부분을 고에서 어떻게 정리했는지 알아보며 시간을 보낼 수 있다. 좋아하지 않을 이유가 있을까?
싫어하는 이유 : 많은 면에서 파이썬은 C와 대조되는 특성을 갖도록 설계됐다. 코드 블록을 구분하기 위한 구두점 표시가 없고 유형은 의도적으로 동적이다. 파이선의 접근법을 좋아하는 사람이라면 고에서 마음에 들지 않는 부분을 많이 발견하게 된다. 이 관점에서 보면 고를 사용한 프로그래밍은 몇 단계 후퇴한 것처럼 느껴진다.
고에는 규칙이 (너무) 많다
고를 만든 사람들은 처음부터 구문뿐만 아니라 언어의 스타일과 사용 패턴도 정의하고자 했다. 예를 들어 고 코드의 들여쓰기에 관한 논쟁을 방지하기 위해 표준 서식 라이브러리를 마련했고, 관용구 목록을 선별해서 프로그래머에게 가장 좋은 관용구를 사용하도록 장려했다. 또한 사용되지 않는 변수, 순환 종속성 등 다른 언어에서 조금 못마땅히 여기는 정도인 몇 가지 습관을 아예 명시적으로 금지했다. 고의 빌드 프로세스는 코드베이스에서 이러한 요소를 발견할 때 멈추도록 프로그램되어 있다.좋아하는 이유 : 고의 강력한 관용적 규칙은 코드의 높은 가독성을 보장한다. 또한 각 개인의 스타일을 형성할 옵션이나 이유 자체가 적기 때문에 스타일을 두고 팀에서 논쟁이 생길 일도 적다.
싫어하는 이유 : 이 같은 모든 부가적인 규칙과 규약은 족쇄처럼 느껴진다. 사용되지 않는 변수가 왜 문제인가? 컴파일러가 탐지할 수 있다면 귀찮게 하지 않고 알아서 없애 준다. 프로그래머가 조금의 자유를 얻는 것이 그렇게 나쁜 일인가?
고의 부가적인 오류 처리
현대 프로그래밍에는 대부분 오류 발생 시 코드가 취할 부가적인 경로 구축이 포함된다. 뭔가 잘못될 때까지 코드는 정상적으로 실행된다. 오류가 발생하면 복구해야 하는데, 잠시 멈출 수도 있고 실행을 완전히 중단할 수도 있다. 자동화된 시스템을 구축하기 위해서는 정상 작동 또는 실패하는 경우를 파악하기 위한 성찰이 필요하다.고는 새로운 접근 방식을 취해서 프로그래머에게 동일한 함수에 두 개의 경로를 작성하도록 독려한다. 모범적인 고 코드는 일반적인 접근 방식과 오류 발생 시의 대처 방법을 모두 명시한다. 고 프로그래머는 "오류는 정규값"이라고 말하곤 한다. 같은 코드의 일부이기 때문이다. 고에는 프로그래머가 더 구체적인 형태의 오류를 생성한 다음 처리 방법을 명시할 수 있게 해주는 오류를 위한 별도의 유형 시스템까지 있다.
좋아하는 이유 : 고 접근 방식은 오류의 존재를 인정하고 프로그래머가 오류 처리를 위한 계획을 세우도록 이끈다. 따라서 프로그래머는 미리 계획하고 회복탄력성을 구축해 더 나은 소프트웨어를 만들 수 있다.
싫어하는 이유 : 불필요한 오류 처리는 고 함수를 더 거추장스럽고 이해하기 어렵게 한다. 딥 체인의 모든 함수가 동일한 오류에 대해 대체로 같은 작업을 수행하는 비슷한 코드를 포함해야 하는 경우가 많다. 자바, 파이썬과 같은 다른 언어는 프로그래머에게 오류를 "잡을" 체인 위의 특정 블록으로 오류를 "던지라"고 독려한다. 결과적으로 코드가 더 깔끔해진다.
표준 라이브러리
팀을 결속시켜주는 단순하지만 강력한 표준으로 설계된 것은 고의 구문만이 아니다. 표준 라이브러리에는 웹 기반 마이크로서비스 프로그래밍에서 일반적인 많은 주요 작업을 위한 지원이 포함된다. 입력과 출력 루틴은 저수준 네트워크 패킷 처리부터 시작해서 HTTPS 프로토콜 처리나 JSON 데이터 디코딩과 같이 더 복잡한 모든 작업을 처리한다. 전체 웹 서버를 코드 몇 줄로 설정할 수 있다. 라이브러리의 "net/http" 부문에 모두 포함돼 있기 때문이다.좋아하는 이유 : 많은 표준 기능이 기본 라이브러리로 처리되면 누구도 자기만의 버전으로 코드를 쓰거나 어느 패키지 또는 써드 파티 라이브러리가 더 나은지를 두고 논쟁할 일이 없으므로 대부분의 코드가 더 읽기 쉬워진다.
싫어하는 이유 : 이와 같이 유용한 코드 모음에 대해 불평하긴 어렵지만 까다로운 사람들은 경쟁이 수요와 혁신을 나타내는 좋은 지표임을 지적한다. 일부 언어가 동일한 작업을 처리하는 여러 개의 패키지를 지원한다는 사실은 깊은 관심과 풍성한 문화를 나타낸다.
실행 파일 크기
고 팀의 목표 중 하나는 고 프로그램을 배포하기 쉽도록 하는 것이었는데, 모든 것을 하나의 실행 파일로 묶어 그 목표를 달성했다. 모든 고의 라이브러리 루틴이 표준 빌드에 포함돼 있으므로 모든 것을 즉시 실행할 수 있다.시간이 지나면서 수십 MB에서 크게는 수백 MB에 이르는 실행 파일을 좋아하지 않는 개발자들이 불필요한 부분을 없애는 방법을 찾아냈다. 적절한 플래그를 설정하고 빌드 프로세스에 부가적인 단계를 포함해야 하므로 할 일이 조금 더 많지만 어쨌든 가능하다.
좋아하는 이유 : 디스크 공간은 저렴하다. 다양한 버전의 라이브러리가 설치되어 있는 경우 잘 모르는 여러 위치에 코드를 배포하는 것은 고역일 수 있다. 고 개발자들이 하나의 실행 파일을 빌드한 덕분에 엄청나게 많은 시간을 절약할 수 있다.
싫어하는 이유 : 디스크 안에 고 라이브러리의 복사본이 몇 개일까? 100개의 프로그램이 있다면 라이브러리 복사본도 100개가 있다는 뜻이다. 어느 시점이 되면 효율성이 문제가 된다. 물론 지금 디스크 공간의 비용이 어느 때보다 저렴하지만 메모리 대역폭과 캐싱은 실행 속도에서 여전히 주요 문제다.
든든한 후원자 구글
고랭은 구글에서 개발됐고, 구글은 지금도 여전히 고의 주 후원사 중 하나로 컴파일러와 툴체인의 대부분을 제공하고 있다. 구글 외에 고를 자바스크립트로 바꿔주는 트랜스파일러인 고퍼JS(GopherJS)도 있다. 그러나 고 개발 작업의 대부분은 구글 내부에서 이뤄진다.좋아하는 이유 : 현대의 작업에서는 서버와 클라이언트를 위한 코드 작성이 차지하는 비중이 크다. 이는 구글 워크로드에서도 마찬가지로 큰 부분을 차지한다. 즉, 고가 구글에 유용하다면 같은 방식으로 작업하는 다른 사람들에게도 유용하다. 구글 엔지니어들이 자신의 마음에 들게 무언가를 만들었다면 비슷한 프로젝트를 하는 다른 사람들의 마음에도 들 수밖에 없다.
싫어하는 이유 : 사람들이 구글을 싫어하는 것이 아니다. 프로그래머는 중앙에 집중된 권한을 신뢰하지 않는다. 벤더 종속, 통제력 상실과 같은 문제는 기술 스택을 조율하는 누구에게나 심각한 문제다. 구글의 관대한 정책에도 불구하고, 특히 방대한 오픈소스 커뮤니티가 구축되어 있는 다른 언어를 선택할 수 있는 상황인 만큼 프로그래머는 여전히 구글에 대한 경계심을 늦추지 않고 있다.
출처 : https://www.itworld.co.kr/topnews/343970
문제가 될 시 삭제하겠습니다.
