Go의 장단점

그간 Go를 서버환경에 좀 써보면서 느낀 장점과 단점, 특징들을 정리해본다.

장점

1. 꽤 쉬운 난이도와 러닝커브

신택스 자체가 비교적 간결한 편이고, c나 java 정도만 익힌 사람이라도 빠른 시간 내에 숙달할 수 있다.
물론 그게 코드를 잘 짜게 된다는 것은 아니다.

2. 빠른 컴파일속도

바이너리가 아웃풋으로 나오는 대부분의 컴파일언어들과 비교하면 컴파일-실행 속도가 빠른 편이다.
python 같은 인터프리터와 비견할 정도...까지는 아니고, node+typescript 환경보다는 빠른것도 같다. tsc가 너무 느린 것도 있다.

3. 쓸만한 에코시스템

Java님같은 메이저에 비견할 정도는 아니지만, 환경이 꽤 풍성한 편이다.
devops, 인프라, 코인 쪽 환경은 월등한 편.
웹서버 수준 환경은 보통. 그 외에는 딱히 없는거같다.
미디어 처리같은건 폐급이더라.

4. 프로파일링 환경

성능 추적을 위한 프로파일링 환경이 꽤 잘 내장되어있다.
gc를 위한 메모리 런타임이 존재하기 때문에 cpu&메모리 할당 추적이 거의 자동으로 된다.

5. 쓸만한 성능

실행속도나 메모리관리 측면에서는 다 Java에 밀리는 감이 없지않아 있긴 한데, 그래도 그런대로 쓸만한 수준이다. 비빌 수는 있다.

6. 강력한? 동시성

고루틴이라는 경량 스레드 단위, 채널 같은 편리한 동기화 수단을 제공해서 통해 가벼운 동시성 처리가 쉬운 편이다.
복잡한 동시성을 구현하기 좋다는 말은 아니다. 그냥 간단하게 시작하는 것만 쉽다...

단점

1. 끔찍한 오류처리 시스템

try-catch도 아니고 모나드도 아니고 이도저도 아닌 방법을 오류처리 매커니즘으로 사용한다. 퇴행된 모나드라고 봐도 된다.

값과 오류를 튜플로 묶어서 반환하고, 그걸 받아서 핸들링하는 형태를 취한다.

모나드가 지원되는 다른 언어들은 상위스택으로 에러 전파할때는 키워드만 한두개 붙이면 되는데, Go는 항상 저런 노가다를 쳐야한다.
코파일럿 같은 보조도구가 없으면 이게 참 고문이 따로없다.

게다가 저런 형태의 신택스는 오류 처리를 강제하지 못하기 때문에, 처리를 빼먹고 지나치기도 쉽다.

2. 전역변수 사용 권장

전역변수 기능이 잘 지원되고, 전역변수의 편리한 사용을 위한 init 같은 키워드도 있다.
사이드이펙트 범벅의 더러운 코드를 양산하기 좋다.

3. 기본 라이브러리 디자인

처음에는 괜찮아보일 수도 있는데, 막상 쓰다보면 뭔가 이상하거나 빠져있는 것들이 많다.

• 이름부터 이상한 함수들이 종종 보인다. 예를 들어, log.Fatal 같은 기능은 로그를 찍는게 아니라 패닉을 던져서 프로그램을 터뜨린다. Gophper식 로그다.
• crypto의 몇몇 기능은 입력값이 뭔가 맞지 않으면 패닉부터 던지고 본다.
• strconv.Atoi는 문자열을 정수로 반환하는데, 정수의 반환값이 int 고정이라 int64범위는 처리하지 못할 수 있다.
• math.Abs은 절댓값을 반환해주는 함수인데, float 버전만 있고 int 버전은 없다.

당장 떠오르는 것만 해도 이 정도다.

4. 반쪽짜리 제너릭

대충 만들어놓고 방치되고 있는 중이다.
제너릭 바운드 설정에도 제한이 있고, 메서드에는 제너릭을 붙일 수 없다.
제너릭으로 뭐 해보려고 하면 다 막힌다.

5. 컴파일타임 처리 매커니즘 부족

go에는 컴파일타임 수준 확장을 처리하는 기능이 제너릭 외에는 없다.

그래서 뭔가 전처리나 생성을 하기 위해서는 진짜로 코드를 수동으로 generation하는 방법을 취한다.

그리고 런타임 리플렉션이 도배될 때가 많다. 컴파일타임에 결정할 수 있는 것이라도 말이다.

6. 어정쩡한 모듈시스템

go는 각 폴더가 하나의 모듈-패키지 영역을 이룬다. 이 패키지들은 서로 동등하며 상하관계를 가지지 않는다.
그냥 만들기 편하고 단순해서 이렇게 만든거같다.

좋다면 좋다고 할 수도 있는데, 계층형 모듈시스템이 존재하지 않기 때문에 circular import에 대처할 수 있는 방법이 전무하고, 문제지점을 찾는 것도 열불나게 해놨다.

그래서 go로 된 모듈들 보면 한 폴더에 소스파일을 잔뜩 밀어넣은걸 흔하게 볼 수 있다. 다 이거 때문이다.

7. 반쪽짜리 튜플타입

이걸 여기서 쓸 수 있으면 저기서도 적용될 수 있어야 한다. 그걸 기본적인 언어의 직교성이라고 말한다.

그런 면에서 튜플 타입은 직교성이 끔찍하다고 할 수 있다. 함수의 반환타입에는 튜플 타입을 쓸 수 있는데, 구조체 필드 같은 곳에는 튜플타입을 넣을 수 없다.

오류처리같은거 하다보면 열받을때가 많다.

8. 패닉과 저가용성

나는 좋은 서버환경을 결정짓는 주요 요소가 가용성과 안정성이라고 생각한다.
그런 면에서 go는 끔찍한 저가용성 수준 문제를 갖고 있다.

가장 역겨운건 concurrent map write다.
여러 고루틴에서 map에 동시 쓰기를 시도하면 패닉이 발생한다. 심지어 이건 recover도 안돼서 무조건 서버가 뻗는다.
게다가 복잡한 시스템에서는 디버그 트레이스로 패닉포인트를 추적하는 것도 매우 어렵다.

그 다음으로 골치아픈건 상위수준에서 recover를 구성하더라도 다른 고루틴에서 패닉이 터지면 시스템이 통째로 터진다는 것이다.
가장 좋은건 고루틴을 띄울때마다 recover 구성을 하도록 강제하는 것이지만, 팀 규모가 크다면 쉽지 않을 수도 있다.

https://m.blog.naver.com/sssang97/223403313214

9. 네임스페이스의 부재

golang에서 코드와 식별자를 다른 영역으로 격리할 수 있는 방법은 패키지밖에 없다.
근데 논리적 개념을 나누겠다고 패키지 단위를 쪼개면 circular import같은 거지같은 문제들이 발생하기 때문에, 쉽사리 사용할 수가 없다.

그래서 웬만하면 단일패키지에 억지로 쑤셔넣는 경우가 대부분이고, 식별자가 길고 더러워지는 것도 순식간이다. 관리가 지저분해진다.

10. 게으른 GC

Go의 GC는 다른 언어들의 GC와 비교해서 그리 좋다고 하긴 어렵다.

낮은 정지시간(latency)과 단순한 구조 유지라는 명목하에 낭비가 심한 메모리 계층구조를 갖게 되었기 때문이다.

쉽게 말하자면, GC 자체를 매우 게으르게 처리하는데, GC로 인해 할당해제가 되더라도 그게 또 실제로 할당해제되는데 딜레이가 존재한다.

아무튼 이런 단점 때문에 메모리의 할당/해제가 많은 메모리 집약적인 경우에는 Go를 권장하지 않는다.
CPU나 I/O 집약적인 경우에만 고려하길 바란다.

GC에 대한 자세한 내용은 별도 포스트를 참조한다.
https://blog.naver.com/sssang97/223576600679

애매한 것

1. 낡아빠진 신택스

21세기에 나온 것이 맞나 싶을 정도로 언어에서 쉰내가 많이 난다.
if-else나 switch 같은 제어문에서 표현식 형태가 지원되지 않고, 패턴매칭도 없으며, 모나드도 없다.
있는걸 세는게 더 빠르다.

2. 자유분방하고 느슨한 신택스

go는 정적타입언어이면서도 좀 느슨하거나 암시적인 문법요소를 몇가지 갖고있다.

그 중 대표적인 것이 구조체 필드 초기화다. 구조체를 생성할때 필드를 생략해도 그냥 기본값이 들어가고 잘 실행된다.
별거 아닌거 같지만 꽤 많은 버그의 원천이 되곤 한다.

구조체 태그도 좀 짜증나는 요소 중 하나다. 뭔가 신택스인데 신택스가 아닌것처럼 만들어진 메타데이터 형식이라서, 형태가 안맞아도 컴파일이 잘 된다. 그리고 버그가 된다.

이런 자잘한 문제들은 lint를 쓰면 해결되긴 하는데, 이것저것 붙이다보면 겁나 느려지고 생산성도 떨어져서 go의 빠른 컴파일성능이 퇴색되는 느낌을 많이 받는다.

3. 위험한 동시성

go는 동시성 로직을 가볍게 작성할 때는 쉽지만, 복잡도가 올라가면 올라갈수록 난장판이 되기 쉽다.

async-await 같은 규격화된 인터페이스가 없어서 가독성도 폭발하기 쉽고, Rust처럼 동시성 충돌을 위한 방어적 검증이 없어서 위험한 코드가 나오기도 쉽다.
알아서 잘해야한다.

4. 수많은 유사키워드와 암시적 문법

golang을 추앙할때 자주 나오는 레퍼토리 중 하나가 적은 키워드와 간단한 신택스인 것 같은데, 글쎄. 난 키워드가 적다는 말에는 동의하기가 어렵다.

go에는 진짜 키워드라곤 하지 않지만 사실상의 키워드인 기능들이 제법 많다. init, iota, len, append, make 등등...

go에서 테스트용 파일은 *_test.go의 형태로 강제되어있다. 저 파일명은 아무렇게나 쓸 수 없다.

함수나 변수를 외부 패키지에 공개할지 말지는 키워드가 아니라 이름으로 결정된다.
식별자가 대문자로 시작하면 패키지 외부로 export되고, 아니면 패키지 내에 숨겨진다.

5. 하위호환성?

go에서는 1.* 버전대 지키면서 하위호환성을 잘 지킨다는 것을 장점으로 내세우곤 한다.

하지만 하위호환이 조금씩 깨질 때도 있다.

당장 근래에 for loop 변수 동작도 코드 수준 호환성이 1.22에선가 깨졌다.

그리고 나는 mockery 기반으로 mocking 환경을 좀 썼었는데, 버전 올릴때마다 뭐 신나게 깨지고 동작 안하고 그러더라. 그래서 못올렸다.

내 생각에 진짜 호환성을 지키는 유일한 방법은 버전을 올리지 않는 것이다.
Ansi C와 Java 1.8을 본받으면 된다.

서버 환경에 잘 맞는가?

간단한 시스템이나 경량 서버를 혼자서 만들어서 띄우는 정도로는 괜찮다. 내 보기에 딱 그 정도가 golang이 강점을 발휘하는 부분이다.

근데 복잡한 비즈니스 로직이 포함되는 서비스를 팀 단위 협업으로 들어가면 걷잡을 수 없어진다.
끔찍한 저가용성과 어정쩡한 신택스에서 유도된 수많은 버그들이 속출한다.
이럴때는 자바가 훨씬 낫다. 관리면에서도, 성능에서도.