golang에 대한 단상

1. 회사 업무로 인해 datadog integration이 필요한 부분이 생겼다. 기존 dd(datadog)에서 지원하는 APM integration형태가 아닌 직접 custom metric + log를 보내야하는 서비스가 있었는데 이부분에 있어서 과연 어떤 방법이 좀 더 효율적일까 하는 고민이 개발팀 내부에 있었는데 간단하게 그냥 datadog-agent의 코드를 까보기로 했다. 정말 놀랍게도 saas형태로 제공되고 있는 서비스의 agent임에도 불구하고 오픈소스로 운용되고 있다. https://github.com/DataDog/datadog-agent 이곳이 바로 그 저장소이다.

 

2. 마찬가지로 회사에서 배포스크립트를 짜는데 shell에서 yaml파일을 변경하는 게 가장 깔끔한 해결책이었다. kustomize같은 cli tool에서 yaml을 쉽게 수정해주니 해당부분을 참고하기 위해 저장소를 찾았다. https://github.com/kubernetes-sigs/kustomize 이곳이 바로 그 저장소이다.

 

위 프로젝트들의 특징이 무엇이냐. 다 go로 돼있다는 점이다.

그래서 생각해봤다. 왜 요즘 나오는 cli tool들은 go로 짜여져있을까?

 

일단 첫번째로는 개발자들이 사용하는 도구라는 점이다.

그리고 다양한 환경에서 실행되기 위해 script형태로 제공할 순 없다.

다른 컴파일언어인 Java, C#처럼 실행 파일이 아닌 바이트코드, IL(Intermediate Language, 중간 언어)을 생성해서는 안된다. 바이트코드와 IL은 가상 머신(Virtual Machine) 위에서 실행되는데 이 VM 자체가 무겁기 때문이다.

결국 c나 c++처럼 independent하게 컴파일된 바이너리 형태로 실행파일을 제공해야 한다.

 

 

다 적고보면 생각나는 언어들이 있다. c, cpp등등 os에 기본적으로 컴파일러가 탑재된 언어들 말이다. 하지만 이 언어들은 잘 다루기가 어렵다. 그래서 아마 최고의 대체제인 go로 쓰여지고 있는 것 같다.

 

 

go를 처음 실제로 써본건 모 회사의 코딩테스트였다. 코테는 합격했지만 면접은 광탈했던 그 회사에서 맨 처음 그 문제를 접했을 땐 꼭 go로의 해결을 요구했기 때문에 뭐 이딴 문제를 다 내냐 싶었지만 문제를 다 풀었을 때 쯤엔 난 이미 go의 팬이 돼있었다. 그만큼 매력적인 언어이다.

 내가 메인으로 사용하고 있는 python의 고질적인 문제인 멀티스레드를 goroutine이라는 세련된 방법으로 해결해버린 go는 그야말로 가뭄의 단비같은 느낌이었다. 그때부터 계속 언젠간 해야지 언젠간 해야지 생각만 하고 있었는데 이제 직접 실무에서 마주치게 되니 진짜 할 때가 됐구나 하는 생각이 든다.

 

그래서 기념으로 golang이라는 카테고리를 하나 추가했다. 나도 위 프로젝트들처럼 cli단에서 사용할 수 있는 오픈소스를 하나 만들어볼 계획이다. 아이디어는 업무 중에 동료를 도와주면서 얻었다.

 

 

datadog-agent도, kustomize도  cobra(https://github.com/spf13/cobra)라는 cli 프레임워크를 사용해서 ​제작돼있어서 하나하나 적용해가면서 제작해볼 예정이다. 그 과정 중에서 기록해야겠다 싶은 부분이 있으면 아마 이 카테고리에 적지 않을까 싶다.

 더 찾아보니 kubectl, kubeadm과 nginx-ingress등 kubernetes진영의 프로젝트들은 거의 다 go로 쓰여졌고 docker진영의 cli tool도, compose도, engine도 go로 쓰여졌다. 찾아보면 찾아볼수록 c나 c++이 들어가야할 자리를 go가 빠르게 꿰차고 있는 것 같다는 느낌이 들었다.

 

 

뭐 아무튼 생산성이 소프트웨어 업계 전반에서 큰 화두가 되면서도 c와 c++등의 언어들이 제공했던 고가용성에 대한 문제를 해결하겠다고 나온 Rust와 Go등등이 이제는 진짜 본격적으로 업계 전반에 적용되는 모습처럼 보인다. 평소에 JD보는게 취미인데 눈씻고 찾아봐도 찾기 힘들던 Rust도 슬슬 보이더라. (Go는 꽤 예전부터 보였다)

 굳이 내 느낌대로 분류하자면 Rust는 좀 더 Serverside와 크게 연결돼있는 느낌이 강했고 Go는 Internal product나 혹은 인풋 아웃풋은 간단하면서도 내부에서 복잡한 연산이 수반돼야하는 부분에 적용된다는 느낌이 강했다. 아무래도 Rust에서 에러를 핸들링 하는 부분과 Go에서 Goroutine을 통한 고가용성 어플리케이션을 만드는 데 용이하다는 점이 각각 분야에서의 장점이자 특징으로 발휘된 게 아닌가 싶다.

 

뭐 아무튼, 당분간은 또 즐겁게 코딩할 수 있을 것 같다.