Go를 사용하는 이유
편의성
동시성, ‘고루틴(goroutines)’ 등 고의 기능 중 일부는 언어 자체에 내장돼 있으며, 추가적인 기능은 고의 ‘http 패키지’와 같은 고 표준 라이브러리 패키지로 제공된다. 고는 파이썬과 마찬가지로 가비지 수집을 포함한 자동 메모리 관리 기능을 지원한다.
파이썬 등의 스크립팅 언어와 달리 고 코드는 빠르게 실행되는 네이티브 바이너리로 컴파일된다. 또한 C나 C++과 달리 고의 컴파일 속도는 매우 빨라서 고로 작업하다 보면 컴파일 언어보다는 스크립팅 언어를 쓰는 느낌이 들 정도다. 아울러 고 빌드 시스템은 다른 컴파일 언어보다 덜 복잡하다.
속도
고 바이너리의 실행 속도는 C보단 느리지만 속도 차이는 대부분의 애플리케이션에서 무시할 만한 수준이다. 대부분의 작업에서 고의 성능은 C와 대등하며, 일반적으로 개발 속도로 유명한 다른 언어(예: 자바스크립트(JavaScript), 파이썬, 루비(Ruby) 등)보다 훨씬 빠르다.
이식성
고 툴체인으로 생성된 실행 파일은 기본적인 외부 종속성 없이 단독으로 실행할 수 있다. 고 툴체인은 다양한 운영체제 및 하드웨어 플랫폼에서 사용할 수 있으며, 여러 플랫폼에서 바이너리를 컴파일하는 데 쓸 수 있다.
상호운용성
고는 기반 시스템 액세스를 희생하지 않고 이 모든 장점을 제공한다. 고 프로그램은 외부 C 라이브러리와 통신하거나 네이티브 시스템 호출을 수행할 수 있다. 예를 들어 도커에서 고는 저수준 리눅스 함수, 컨트롤 그룹, 네임스페이스와 연결하여 컨테이너를 활용할 수 있다.
지원
고 툴체인은 리눅스, 맥OS, 윈도우 바이너리 또는 도커 컨테이너로 무료 제공된다.
고는 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux)와 페도라(Fedora) 등 여러 인기 리눅스 배포판에 기본으로 포함돼 있어 고 소스를 이런 플랫폼에 배치하기 비교적 용이하다.
마이크로소프트 비주얼 스튜디오 코드(Microsoft Visual Studio Code)부터 액티브스테이트(ActiveState)의 코모도 IDE(Komodo IDE)까지 많은 서드파티 개발 환경에서도 고 지원은 탄탄하다.
사용하기 적합한 곳
클라우드-네이티브 개발
고의 동시성 및 네트워킹 기능, 높은 수준의 이식성은 클라우드 네이티브 앱을 개발에 적합하다. 실제로 고는 도커, 쿠버네티스, 이스티오 등 여러 클라우드 네이티브 컴퓨팅의 기반을 구축하는 데 사용됐다.
분산형 네트워크 서비스
네트워크 애플리케이션의 핵심은 동시성이며, 고의 네이티브 동시성 기능(예: 고루틴 및 채널)은 이런 작업에 적합하다. 많은 고 프로젝트가 API, 웹 서버, 웹 애플리케이션을 위한 최소 프레임워크 등 네트워킹, 분산형 기능, 클라우드 서비스에 쓰이는 이유다.
유틸리티 및 독립형 도구
고 프로그램은 외부 종속성이 최소화된 상태에서 바이너리로 컴파일된다. 그래서 유틸리티 및 기타 도구 제작에 이상적이다. 빠르게 실행되고 재배포를 위해 신속하게 패키지화할 수 있어서다. 텔레포트(Teleport, SSH용)라는 액세스 서버를 한 예로 들 수 있다. 텔레포트는 소스부터 컴파일하거나 사전 구축 바이너리를 다운로드하여 쉽고 빠르게 서버에 배치할 수 있다.
단점
제네릭의 부재
수년 동안 고 개발팀은 제네릭 추가를 반대했다. 하지만 2022년 초에 공개된 고 1.18부터 제네릭 구문이 도입됐다. 고는 상당한 고심 끝에 주요 기능을 드물게 추가하지만 여러 버전에서 광범위한 호환성을 유지한다.
생성되는 바이너리의 크기
고 바이너리는 정적으로 컴파일되기 때문에 런타임에 필요한 모든 요소가 바이너리 이미지에 포함돼 있다. 이 접근 방식은 빌드 및 배포 프로세스를 간소화하지만, 그 대신 64비트 윈도우에서 간단한 ‘Hello, world!’를 출력하는 바이너리의 크기도 약 1.5MB에 육박한다는 단점이 있다.
고 개발팀은 후속 릴리즈마다 이런 바이너리의 규모를 줄이고 있다. 또 압축이나 고의 디버그 정보를 삭제하여 고 바이너리를 줄일 수 있다.
이 마지막 옵션은 서비스 실행 실패 시 디버그 정보를 유용하게 쓸 수 있는 클라우드 또는 네트워크 서비스보다는 독립형 분산형 앱에 적합하다.
오버헤드를 필요로 하는 가비지 수집
고는 수동 메모리 관리를 제공하지 않으며, 고의 가비지 수집은 엔터프라이즈 애플리케이션에서 나타나는 종류의 메모리 부하를 효과적으로 처리하지 못한다는 비판을 받고 있다.
하지만 고의 새로운 버전은 메모리 관리 기능을 개선하는 것으로 보인다. 예를 들면 고 1.8은 가비지 수집 지연 시간이 크게 짧아졌다. 고 개발자들은 C 확장 기능 또는 서드파티 수동 메모리 관리 라이브러리를 통해 수동 메모리 할당을 사용할 수 있다. 물론 대부분의 고 개발자는 네이티브 솔루션을 선호한다.
사용 keyword
Reference
