7 min to read
Go 언어를 쓰기전에(시작편)
이전 포스트입니다.
2017년 4월 2일에 작성된 문서를 재 가공한 포스트입니다. 해당 포스트를 작성했었을 때에는 자위용에 불과해서 자위용포스트는 전부 지워버렸습니다.
세상을 재미있게 만들기 위하여!!
주의
이 블로그의 내용은 대단히 주관적인 내용이 가득합니다.
그리고 양질의 글을 읽었지만 똥글이 나오는건 제 미숙함 때문입니다.
그럼에도 불구하고 피드백 많이 주신다면 자세히 조사하여 반영하도록 하겠습니다.
또한.. 가능한 링크로 올려놓은 자료들은 반드시 열어보시기 바랍니다. 분명 도움이 될 것입니다.
(- -)(_ _)
이 언어를 시작하게 된 동기
Retrica 면접을 보는대 Retrica 서버는 Go 언어와 ProtoBuf를 활용한 서버를 사용중이었다. 면접 질문중에서 ..
면접관 질문 : 용진씨가 해본 언어 Java, Javascript, Python 위 셋 중에 어떤언어가 철학적으로 마음에 들며, 어떤 언어를 배우고 싶으신가요?
사실 Retrica에 들어가기 전부터 Go와 Erlang를 배우고 싶어했었다. 하지만, 취업을 해야하는 입장에서 뭐가 하고 싶다 하더라도 쉽게 도전할 깡다구가 생기지 않는다. 영어하랴, 자소서쓰랴 등등.. 여러가지 요인이 날 방해하고있었기 때문이다. 답변은 속 시원하게 말아먹었었다.
내 답변 : “철학으로는 Javascript고 배우고 싶은 언어는 Go와 Erlang입니다. Javascript의 … (나도 정확히 모르는 내용을 예시를 들려고해서 아예 이 답변을 말아먹었다. ) 그리고 Go 와 Erlang 은 배우고 싶은대 그 이유는 분산처리에 탁월하다는 능력을 들었었습니다. 직접 해본적은 없지만 만약 배운다면 Go또는 Erlang을 배우고 싶었습니다. Erlang은 네이버 라인에서 사용하고 있는 언어로 동접자가 기하급수로 불어난 서비스에 어떻게 해서 Erlang으로 구축할 생각을 했었는지 어떤 의사결정을 통해 Erlang을 선택했는지 궁금했습니다..(생략)”
아직 결과는 나오지 않았지만 분명 탈락일것이다. 내가 면접관이라도 모르는 내용으로 답변하려 들면 기분좋게 탈락시켰을 태니 말이다.
즉, 지금은 이 언어를 시작하게 된 동기는 원래 배우고 싶었지만 결정적인 원인은 실제로 해보고 싶었으면서 면접에서 탈탈 털린 내 자신에게 한탄하기위해 시작한다.
Retrica에서 면접보러온사람이 서버개발자 팀장급과 Retrica 를 처음 만든 창업자 장본인(CEO)이 와서 면접을 보았다. 난 이것에 탈락되어도 후회하지않는다. ( 아쉽긴 하지만 ) 심지어 싸인도 받아보고 싶다.
Intro
불순한 동기로 시작한 언어지만 자세히 알아보도록 합니다.
| 항목 | 값 |
|---|---|
| 개발자 | 로버트 그리즈머, 롭 파이크, 켄 톰슨 |
| 공식 홈페이지 | http://golang.org |
| 개발 회사 | Google 갓 구글 차냥해! |
| 라이센스 | BSD |
시작하기전에 Go 뽕 맞고 시작하자.
Write in Go(Lyrics) The schedule’s tight on the cluster tonight 분산환경에서 해야 할 일로 쉴 틈 없을 오늘밤
So I parallelized my code 그래서 저는 병렬화된 코드를 작성했지요
All those threads and continuations 그 모든 스레드와 연속성들로
My head’s going to explode 제 머리는 폭발하기 일보직전이랍니다
And all that boilerplate 심지어 그 모든 의례적인 코드들
That FactoryBuilderAdapterDelegateImpl 그 모든 “괴상야릇한디자인패턴의복잡다단한구현의향연”
Seems unjustified 이건 제가 가야 할 길이 아닌 것만 같아요
Give me something simple 좀 더 간결한 길을 알려주시겠어요?
Don’t write in Scheme 스킴 쓰지 마세요
Don’t write in C C로 짜지 마세요
No more pointers that I forget to free() 해제하길 깜빡한 포인터여 이제 그만 안녕
Java’s verbose, Python’s too slow Java는 번잡하고, 파이썬은 느려터졌단 걸
It’s time you know 이제 깨달을 때가 왔어요
Write in Go! Write in Go! Go로 짜세요, Go로 짜세요!
No inheritance anymore 클래스 상속이여 이제 그만 안녕
Write in Go! Write in Go! Go로 짜세요, Go로 짜세요!
There’s no do or while, just for do도 while도 없어, for뿐
I don’t care what your linters say 당신의 linter가 뭐라 불평하든 상관없어요
I’ve got tools for that 제겐 해결책이 있답니다
The code never bothered me anyway 코드 자체가 신경 쓸 일을 만들지 않을테니 말이죠
Go언어의 활약
- Docker를 만든 언어 go !
- 드롭박스
- 클라우드 플레어
- 사운드클라우드
- 넷플릭스
- 트위치
- 뉴욕타임즈 Gizmo API
- SpaceX 원격측정 프로그램
배경지식
전반적으로 C에서 영향을 많이 받았으며, 철학으로는 단순함을 목표로 한다. 나온 지 5년 동안은 구글에 취직이라도 하지 않는 이상 배워봤자 딱히 쓸 데가 없다는 이유로 새로운 언어에 관심이 많은 덕후얼리어답터 개발자들 사이에서나 알음알음 쓰이던 정도였지만 Go 언어 사용자들을 Gopher라 부르며, Gopher 들을 위해 매년 고퍼콘(Gophercon)이 열리긴한다.(Gophercon Korea 는 가끔 인 것 같은 것…? ) 많은 종류의 프로그램 버그는 프로그래밍 언어 차원에서 원천적으로 차단될 수 있으며, 프로그래밍 언어 연구자들은 쓰기 쉬우면서도 최대한 많은 버그를 컴파일 시점에 잡을 수 있는 타입 시스템을 만드는데 많은 노력을 기울이고 있다.
- 2009년 11월에 처음 나옴,
- 2014년 12월에 1.4 버전
- 2015년 8월에 1.5 버전
- 1.5 버전에서는 드디어 Go 컴파일러가 Go로 작성되었다.
- 그 이전까지는 C언어로 작성.
- 자기 자신으로 구현된 컴파일러가 생겼다는 것은 개발 속도에 상당한 가속이 붙게 되었다는 의미가 될 수 있다.[4]
- 2016년 2월에는 HTTP/2가 기본으로 지원되고 템플릿 문법의 개선 등이 이루어진 1.6 버전이 릴리즈되었다
- 2016년 8월에는 컴파일 속도의 개선, 실행 퍼포먼스 향상, /x/net/context 패키지의 기본 패키지화 등이 이루어진 1.7 버전이 릴리즈되었다.
(릴리즈 특징)
- 여전히 1.4 버전에 비해 컴파일 속도는 느림(Go Compiler 를 사용하고 나서..)
- 2018년 2월에 32비트 MIPS 명령어 지원, 컴파일러 프론트 엔드 추가, 가비지 컬렉션 개선, Cgo의 오버 헤드 개선 등의 변경점이 있는 1.8 버전이 출시
Go 언어의 특징
- Go 언어를 이용해서 안드로이드와 iOS 앱을 제작할 수 있게 적용 중이다.
- 웹 개발에도 쓰이고 있고 특히 서버 사이드 언어로서 좋은 평가를 받고 있다.
- Go가 자체적으로 지원하는 라이브러리만으로도 간결하게 웹사이트를 만들어낼 수 있다.
- Go 언어의 특징은 컴파일 언어이지만 컴파일러의 컴파일 속도가 매우 빨라 인터프리터 언어처럼 쓸 수 있다는 점에 있다. 언어의 문법 구조를 개선함으로써 달성하였다. 컴파일러가 소스 코드를 해석하는 pass 수를 줄여서 달성한 것으로 보인다.
- 접근하기 어렵지 않고, 코드 역시 간결하면서도 컴파일 언어답게 높은 성능을 낼 수 있다는 점이 호평을 받는다.
- 간결하게 코드를 작성할 수 있으면서도 풍부한 라이브러리 등의 덕택에 막강한 기능을 쉽게 구현할 수 있다는 것은 큰 장점이다.
- 그러나 컴파일 언어의 태생적인 한계를 극복한 것은 아니라서 대형 모듈을 이것저것 붙이면 컴파일에 필요한 시간이 있기에 Python 등의 인터프리터 언어보다는 기동할 때에 확실히 반응이 늦다.
- 물론 컴파일 언어 중에서는 매우 빠른 편이지만 아무래도 인터프리터 언어의 즉흥성까지 바라는 건 무리. 물론 컴파일 언어인만큼 실행 시 퍼포먼스는 확실하다.
Go 루틴에 대해
Go는 GoRoutine이라는 비동기 메커니즘을 제공한다. 이 비동기 메커니즘은 Erlang에서 영향을 받은 것으로 각각의 고루틴은 병렬로 동작하며 메시지 채널을 통해 값을 주고받는다. 고루틴을 사용하면 이벤트 처리, 병렬 프로그래밍 등이 간단해진다. 단 병렬화된 고루틴의 동기화 문제는 프로그래머가 챙겨 줘야 하며 동기화를 무시할 경우 프로그램이 비정상 종료할 수도 있다.
예를 들어 부모 루틴이 자식 루틴보다 먼저 끝나버리면 자식 루틴은 OS에 의해 메모리에서 강제로 사출되어 버린다. 단 동기화 방법은 기존 멀티스레드 응용프로그램에 비해 매우 간단한 편. 단순히 고루틴으로부터 반환값을 받는 줄을 메인 스레드에 추가하면 된다. 고루틴은 멀티스레드 메커니즘이지만 자체적인 스케줄러에 의해 관리되는 경량 스레드이며 OS에서 관리하는 경량스레드보다 더 경량이다. 따라서 고루틴은 CPU 코어수와 무관하게 수백 수천만 고루틴을 작성해도 성능에 문제가 생기지 않는다. 이는 Erlang도 마찬가지. Go는 바이너리 컴파일러이므로 서로 다른 머신 플랫폼들을 타겟으로 배포해야 할 경우 환경변수(GOOS와 GOARCH 등)를 그에 맞게 설정한 후 컴파일해서 여러 벌의 배포판을 만들어야 한다.
Go의 비판적 시각
컴파일 언어인 덕분에, 속도가 느린 스크립트 언어에서 연산 퍼포먼스가 필요한 부분을 Go로 대체해 넣을 수도 있다. 예를 들면, Go로 만든 코드를 공유 라이브러리로 컴파일해 Ruby에서 FFI를 이용해 컴파일한 .so 파일을 가져와 사용하는 식. PHP에서도 역시 가능하다. 다만 기본 패키지들 중에서는 성능보다는 편의성에 초점을 맞춘 탓에 극한의 성능을 추구하는 경우라면 사용을 권하기 어려운 것들이 있다. 예를 들면 웹 서버 제작시에 쓰이는 net/http나 html/template 등이 그러한데, 이런 경우엔 기본 패키지를 대체하는 별도의 패키지를 이용하면 (실제 체감효과는 별론으로 하되 벤치마크상으로는 심지어 수십 배나 수치가 좋아지는(…) 경우도 있다.
- Go 언어의 설계 지향점이 시스템 프로그래밍 언어이었으나 가비지 컬렉션의 지원이나 제네릭의 부재로 인해 박싱/언박싱이 불필요하게 많이 일어나는 등(시스템프로그램 CLI환경에서 구동하는 녀석으로 시스템콜이 빈번한 프로그래밍이 되어야 하는대 박싱/언박싱의 불필요한 호출로 시스템프로그래밍언어로 적합한가에 대한 의구심이 생기는 추세)
- C/C++을 대체할 수 있는 언어는 아니라는 것 에 합의가 이루어지고 있는 상황이다.
- 실제로 고성능 연산에 사용하기에는 C/C++에 비해 너무 느리며,
- 저수준 시스템 개발에서는 가비지 컬렉션과 고루틴을 지원하기 위한 무거운 런타임 등으로 인해 사용이 불가능에 가깝다.
- 대체로 개발 속도와 실행 속도, 병행성 사이의 적정 지점이 필요한 서버 애플리케이션 개발 등에 많이 사용되는 편.
- 이전 버젼에서는 저수준 시스템 프로그래밍에서도 C/C++보다 낫다는 식의 서술이 있었으나, 이는 go를 개발하던 당시 개발진의 목표였을 뿐
- 현대 프로그래밍 언어 연구의 성과를 일체 무시한 언어 설계.
- 널 포인터나 안전하지 않은 타입 캐스팅을 장려하는 인터페이스
- 타입 안전한 제네릭의 부재
Comments