원문: https://thenewstack.io/golang-co-creator-rob-pike-what-go-got-right-and-wrong/ (Translated by Google Gemini)

GopherCon AU 참석자들은 Go의 사양이 처음 작성된 도시인 호주 시드니에서 특별한 대접을 받았습니다. Go의 공동 설계자 중 한 명인 Rob Pike는 Go 프로그래밍 언어가 출시된 지 14주년이 되는 날을 기념하며 “무엇을 제대로 했고, 무엇을 잘못했는지” 돌아보는 강연을 했습니다.

Pike는 2009년 11월 10일 웹사이트가 처음 공개되던 순간을 기억하며 “세상이 우리가 무엇을 해왔는지 알게 되었다”고 말했습니다.

“14년이 지난 지금, 돌아볼 것이 많습니다.”라고 Pike는 청중에게 말하며 “더 큰 교훈들”을 탐구하겠다고 약속했습니다.

Pike는 자신이 개인적인 의견을 말하는 것이며 (Go 팀이나 Google을 대표하는 것이 아님을) 강조했습니다. “Go는 헌신적인 팀과 거대한 커뮤니티의 엄청난 노력이었습니다.”

하지만 그는 Go의 초기 역사에 대한 많은 내부자적인 기억과 함께 프로그래밍 언어를 개발할 때 중요한 점에 대한 유용한 통찰력을 공유하는 강연을 계속했습니다.

더 나은 코드 작성 방식#

Go의 다섯 명의 원래 개발자들은 2022년 Communications of the ACM 기사에서 Go를 인기 있게 만든 요인에 대해 논의했습니다. 이 기사에서 Pike는 Ken Thompson, Russ Cox, Robert Griesemer, Ian Lance Taylor와 함께 Go가 동시성 및 병렬성을 위해 특별히 설계되었으며, 새로운 멀티코어 칩의 성능을 활용하면서 대규모 워크로드를 처리하도록 설계되었다는 점을 지적했습니다.

그러나 그들은 또한 Go의 성공 요인으로 지속적인 “개발 중심 철학”과 활발한 커뮤니티 및 기여 (새로운 패키지 포함)를 꼽았습니다.

이는 Pike가 11월 강연에서 다시 언급한 주제입니다. “우리의 원래 목표는 새로운 프로그래밍 언어를 만드는 것이 아니었습니다. 더 나은 소프트웨어 작성 방식을 만드는 것이었습니다…”

“당시 작업하던 바이너리를 빌드하는 데 45분씩 걸리지 않았다면 Go는 탄생하지 않았을 것입니다.”

곧 Pike는 “우리가 제대로 했던 것들… 각각이 Go의 궁극적인 성공에 결정적이었다”는 상세한 목록을 청중에게 공유했습니다. 예를 들어, 그들은 Go가 구문 분석하기 쉽도록 만들었습니다. 이는 IDE와 같은 도구와 Go의 공식 언어 서버인 gopls(IDE 기능도 제공)를 쉽게 만들 수 있게 했습니다.

곧 그들은 자동 테스트 및 코드 검증 도구로 컴파일러를 보강했습니다. (패키지 컴파일 go 명령은 말할 것도 없습니다.)

하지만 Go가 제대로 한 것은 그것만이 아니었습니다…

  • Pike는 또한 gofmt 자동 포맷팅 도구를 칭찬합니다. 부분적으로는 이 도구의 “핵심”이 간소화 도구, 분석기 및 중요한 코드가 테스트 스윗츠 (test suites) 로 커버되는지 확인하는 도구에서 재사용될 수 있는 라이브러리가 되었기 때문입니다. (이러한 도구의 출력은 항상 인간과 기계 모두에게 완벽하게 포맷될 수 있다는 점은 말할 것도 없습니다.) “공백과 개행에 대해 논쟁하지 않아 절약된 시간은 표준 형식을 정의하고 이 다소 어려운 코드를 작성하여 자동화하는 데 들인 모든 시간만큼 가치가 있습니다.”

  • 흥미롭게도 Go의 패키지 라이브러리는 “초기에 Go 코드를 설치할 다른 곳이 없었기 때문에 다소 우연히 성장했습니다.” 하지만 이제 Pike는 이를 Go가 제대로 한 또 다른 점으로 봅니다. “견고하고 잘 만들어진 라이브러리의 존재 — 21세기 서버 코드를 작성하는 데 필요한 대부분의 것을 포함하고 있는 — 는 중요한 자산이었습니다. 우리는 경험이 충분하여 다른 무엇을 제공해야 할지 이해할 때까지 커뮤니티가 모두 동일한 툴킷으로 작업하도록 유지했습니다.”

  • Go가 제대로 한 또 다른 점은 공식 사양을 발표한 것입니다. “이는 컴파일러를 작성할 때 동작을 고정할 뿐만 아니라, 여러 구현이 공존하고 해당 동작에 동의할 수 있도록 합니다.” 이는 결과적으로 언어를 개선하고 사양을 미세 조정하는 데 도움이 되었다고 Pike는 말합니다.

  • 초기에 Go는 호환성 보장을 발표하여 언어 채택에 “극적이고 문서화된 효과”를 가져왔다고 Pike는 말합니다. 너무나도 “나는 다른 많은 프로젝트가 이를 거부한 것이 의아하다”고 말합니다.

Pike는 또한 “Go가 빠른 빌드라는 명성을 얻는 데 해가 되지 않았다”고 덧붙였습니다.

Go가 놓친 것#

파이크는 강연에서 구현되지 않았지만 그가 원했던 기능 하나를 살짝 보여주었습니다. 바로 임의 정밀도 정수 허용인데, 이는 모든 종류의 보안 문제를 제거했을 것이라고 그는 말했습니다.

긴 정수가 할당된 메모리를 초과할 수 있는 세상에서, “정수 오버플로를 어떻게 처리할지에 대한 논쟁은 여전히 진행 중입니다. 음, 만약 오버플로되지 않는다면요? 전혀 신경 쓸 필요가 없습니다!” 런타임 비용은 낮을 것이며, “제때 생각하고 구현했더라면 좋았을 텐데 하고 아쉬워합니다. 사람들이 반대했을 수도 있습니다 – 너무 비싸 보인다고 – 하지만 그것이 해방시켜주는 것은 놀랍습니다. 더 이상 정수 오버플로에 대해 생각할 필요가 없습니다.”

나중에 그는 컴파일러가 Go의 동적 인터페이스에 대해 더 많은 자동 검사를 수행하고, 자원 공유로 인해 발생할 수 있는 진행 정체 교착 상태 가능성을 검사하기를 원한다고 말했습니다.

“컴파일 시점에 프로그램을 더 안전하게 만드는 모든 것이 좋습니다” — 비록 그는 참을 수 없을 정도로 긴 컴파일 시간은 원하지 않을 것이지만요.

Go 컴파일러의 특이점#

파이크에 따르면 Go가 잘한 또 다른 중요한 점은 이식성입니다. 즉, 다른 플랫폼용으로 코드를 컴파일하기 쉽게 만든 것입니다. 이는 부분적으로 Ken Thompson의 컴파일러 덕분에 가능했는데, 이 컴파일러는 다른 사람들이 컴파일러 자체가 Go로 작성되었어야 했다고 (또는 LLVM 도구를 사용했어야 했다고) 주장했음에도 불구하고 C 프로그래밍 언어로 작성되었습니다.

파이크는 Thompson의 컴파일러가 “이상한 오리였다… 컴파일러 작성의 오래된 아이디어를 사용했다”고 인정합니다 (비록 크기가 적당하고 “실용적이고 효율적”이었지만요). 하지만 무엇보다도 “우리에게 익숙했기 때문에 새로운 아이디어를 시도할 때 빠르게 변경하기 쉬웠습니다… 아무리 비정통적이라 할지라도 우리 방식으로 하는 것이 우리가 빠르게 움직이는 데 도움이 되었습니다. 어떤 사람들은 이 선택에 불쾌해했지만, 당시 우리에게는 올바른 선택이었습니다.”

2015년 Russ Cox는 컴파일러를 C에서 Go로 반자동으로 번역하는 도구를 작성했습니다.

“그리고 물론, 오늘날에는 Go를 위한 LLVM 호스팅 컴파일러와 다른 많은 컴파일러가 있습니다. 그래야 합니다.”

고퍼들을 위한 고퍼#

파이크가 Go가 잘한 점들을 나열한 목록은 놀랍게도 Go의 마스코트인 이름 없는 만화 고퍼에서 시작되었는데, 그는 이를 “Go 성공의 초기 요인 중 하나”라고 불렀습니다.

파이크는 Go의 성장에 “중요했다”고 진정으로 믿습니다. 커뮤니티가 결집할 수 있는 “알아볼 수 있고 재미있는 생물”을 갖는 것이었습니다. “그의 엉뚱하지만 영리한 태도 — 무엇이든 만들 수 있습니다! — 는 커뮤니티가 프로젝트에 참여하는 분위기를 조성합니다. 기술적 우수성과 진정한 재미가 결합된 분위기입니다.”

그러나 “최선의 선택이 아니었을 수도 있는” 한 가지 결정은 고퍼의 디자인을 크리에이티브 커먼즈 저작자표시 라이선스 아래에 공개한 것이었습니다. 파이크는 “한편으로는 사람들이 재미있는 방식으로 리믹스하도록 장려했다”고 인정했으며, “이는 다시 커뮤니티 정신을 함양하는 데 도움이 되었다”고 말했습니다.

그러나 파이크는 저작자표시 (또는 잘못된 저작자표시)를 수정하기 위한 답답한 논쟁도 있었다고 말했습니다. “솔직히 저작자표시는 마지못해 지켜지거나 전혀 지켜지지 않는 경우가 많았습니다…”

“따라서 다시 한다면 마스코트가 그의 이상에 충실하도록 하는 가장 좋은 방법에 대해 신중하게 생각할 것입니다.”

동시성 전쟁#

파이크의 강연은 Go의 가장 영향력 있는 결정으로 절정에 달했지만, 그는 먼저 2002년에 그가 구글에 처음 합류했을 때의 세상이 어땠는지 설명했습니다. 구글은 프로세스 스레드의 동시 실행을 피하는 것처럼 보였고, 심지어 “아예 금지하는” 것처럼 보였다고 파이크는 기억합니다. 이는 그를 괴롭혔습니다. “저는 1970년대부터 동시성과 같은 일들을 해왔습니다 — 심지어 깨닫지 못하고 해왔던 일들도 있습니다.” 2002년에는 스레드가 나쁜 아이디어라고 믿는 사람들이 많았습니다. 그러나 파이크는 스레드가 잘 될 수 있다고 주장하는 논문, 책, 심지어 다른 언어들을 보았습니다.

“주류 아이디어로 아직 자리 잡지 못했을 뿐이었습니다… Go는 부분적으로 이를 해결하기 위해 탄생했습니다.”

결국 Go가 가장 잘한 일 중 하나가 됩니다. “오늘날 대부분의 주류 언어는 동시성을 잘 지원합니다.”라고 파이크는 언급했습니다. 그러나 당시에는 Go가 “새로운 것처럼 보이게” 만들었습니다… Go의 동시성 지원은 초기 채택을 증가시키는 주요 매력 요인이었고, 이전에 동시성을 사용해 본 적은 없지만 그 가능성에 흥미를 느낀 프로그래머들을 끌어들였습니다. 파이크는 그들이 완전히 성공했다고 믿습니다. Go는 “서버 소프트웨어를 구조화하는 방법으로 동시성을 대중화하는 데 도움을 주었습니다.” (비록 그가 HTTP 요청을 처리하는 것과 같이 “본질적으로 병렬적인” 문제를 다루지 않는 프로그래머들에게는 덜 인상적이었을 수도 있다고 인정했지만요.)

곧 파이크의 강연은 그의 위대한 결론에 도달했습니다. “출시 14년이 지난 지금 우리는 여기에 있습니다. 그리고 전반적으로 아주 좋은 곳이라고 말할 수 있습니다.” 파이크는 그의 강연을 요약한 블로그 게시물에서 성공의 다른 요인들을 간결하게 요약했습니다…

저희가 여기까지 오게 된 이유는 부분적으로 다음 때문입니다:

  • 서버 코드에 필요한 대부분의 기본 기능을 구현하는 강력한 표준 라이브러리
  • 언어의 일등석 구성 요소로서의 동시성
  • 상속보다는 조합 기반의 접근 방식
  • 의존성 관리를 명확히 하는 패키징 모델
  • 통합된 빠른 빌드 및 테스트 도구
  • 엄격하고 일관된 형식 지정
  • 기발함보다는 가독성에 대한 집중
  • 호환성 보장

“그리고 무엇보다도 믿을 수 없을 정도로 도움이 되고 다양한 고퍼 커뮤니티의 지원 덕분입니다.”

“이러한 문제의 가장 흥미로운 결과는 Go 코드가 누가 작성하든 동일하게 보이고 작동하며, 다른 언어의 하위 집합을 사용하는 파벌이 거의 없고, 시간이 지나도 계속 컴파일되고 실행될 것이라는 점입니다. 이는 주요 프로그래밍 언어에서는 처음일 수 있습니다.

“우리는 분명히 그것을 제대로 해냈습니다.”

전체 강연 영상: