Rob Pike님의 GopherConAU 2023 세션 트랜스크립트를 의역/요약한 글입니다.

첫 번째 글은 아래 링크에서 확인하실 수 있어요

https://careerly.co.kr/comments/97031

---

동시성 (Concurrency)

“Go의 동시성이 논란의 여지가 있다고?” 라고 생각하시겠죠. 제가 2002년에 구글에 합류했을 때는 그랬습니다. 당시 동시성은 개발 언어가 내세우는 주요 기능은 아니었습니다. 전 Go 언어가 동시성이 유용한 도구임을 개발자들에게 알려줬다고 생각합니다. 적어도 pthreads처럼 고통 받지 않고 동시성을 구현할 수 있다는 것을 보여줬습니다. 요즘은 대부분의 개발 언어에서 동시성은 주요 기능으로 자리 잡았습니다.

동시성은 Go 언어가 새롭다는 느낌을 주었습니다. 분명 다른 개발 언어도 동시성을 지원했지만 당시에 주 기능으로 내세우지 않았습니다. 반면, Go 언어는 동시성을 주요 기능으로 내세우면서 많은 개발자들을 유입하는데 도움이 되었습니다. 다만, 이는 곧 우리가 두 가지 실수를 범했음을 깨닫게 해주었습니다

첫 번째로, goroutine의 사용 사례와 가이드를 명확하게 하지 않은 점입니다. 우리가 생각한 동시성의 사례는 대부분 서버 네트워크 처리 관련 기능들이었습니다. 이걸 명확하게 전달하지 않아서 많은 개발자들이 삽질했던 것을 알고 있습니다. 심지어 제대로 된 가이드도 없었을 겁니다. 이 자리를 빌어 죄송하다는 말씀 전하고 싶습니다.

두 번째도 첫 번째랑 연관이 있는데, 저희가 동시성과 병렬성에 대해 명확하게 설명하지 않은 점입니다. 많은 개발자들이 goroutine을 사용해 프로그램을 병렬로 실행해서 성능 향상을 목표했던 것 같습니다. 다만, 프로그램이 병렬 실행으로 성능 향상이 있으려면 실행 시키고자 하는 문제가 근본적으로 병렬로 수행될 수 있어야 합니다. 우린 이 설명을 지독하게 못했고 많은 개발자들이 병렬적으로 풀 수 없는 문제를 goroutine을 사용해 병렬적으로 구현하면서 성능 저하를 경험했던 것 같습니다.

그럼에도 Go 언어는 서버를 구성할 때 동시성은 유용하다는 것을 대중화 시켰다고 생각합니다.

인터페이스

인터페이스는 Go의 주요 기능입니다. 행동 중심 객체 지향 디자인에서 영감을 받아, 미리 타입을 지정하지 않고 동적으로 생성할 수 있습니다. 초기에 우린 다형성을 어떻게 지원할 것 인가 고민을 했고 인터페이스에 여러 메서드를 정의해서 어떤 함수들을 사용할 수 있는지 표현하는 방식을 떠올렸습니다. 이는 곧 Go의 핵심 기능으로 자리 잡았습니다.

우린 초기에 제네릭을 피하고 인터페이스와 간단한 내장 타입 (맵, 슬라이스 등)에 중점을 두었습니다. 이는 제네릭이 가져오는 복잡성을 지양하려고 했기 때문입니다. 다만, 내장 타입만으로는 한계를 느꼈고 제네릭의 지원이 필요하다는 것을 깨달았습니다. 이는 곧 인터페이스가 우리의 발목을 잡고 있음을 깨닫게 해주었습니다. 다형성을 확장해서 제네릭을 지원하려면 인터페이스와 호환이 되어야 했고 이는 아주 복잡했습니다.

결국, “메서드의 집합”에서 “타입의 집합”을 지원하는 것으로 Go 언어에서 제네릭을 지원하기는 했지만 여전히 찝찝함은 남아있습니다.

컴파일러

초기 Go 컴파일러는 C로 구현되어 있었습니다. 이는 커뮤니티가 기대한 방식과는 달랐습니다. 적어도 그들은, LLVM과 같은 툴킷을 사용하거나 컴파일러를 Go 언어로 만들어주기를 원했습니다. 하지만 우리는 둘 다 사용하지 않았습니다.

새로운 개발 언어는 컴파일링 할 때 기존 개발 언어를 활용해야 합니다. 우리에게는 Ken (C언어의 모체인 B언어 개발자)이 있었고 C 컴파일러를 이미 개발한 경험이 있는 그의 노하우가 초기 Go 컴파일러를 구성하는데 도움이 될 거라고 생각했습니다. 그리고 새로운 개발 언어를 만들면서 동시에 해당 언어로 컴파일러를 구현하려고 하면, Go 언어를 컴파일러를 위한 개발 언어로 만들게 될 것 같았습니다.

초기 컴파일러는 옛날 방식으로 구현되었지만 준수했습니다. 엄청 효율적이라고 말할 수는 없었지만 필요한 기능은 착실하게 수행했고 무엇보다 우리에게 익숙한 코드 베이스여서 원하는 기능을 쉽게 구현해서 테스트해 볼 수 있었습니다. 만약 LLVM 같은 툴킷을 사용했으면 기능을 구현하는데 정말 어려웠을 겁니다. 그리고, cross-compilation이 잘 되었습니다. 비록 정석은 아니었지만, 당시 구현한 컴파일러는 우리가 Go 개발 언어를 더 빠르게 개발 할 수 있게 도와주었습니다.

이후, Go 1.5에서 Russ는 C 컴파일러를 Go로 변환해주는 translator를 만들었습니다. 이 때는 이미 Go 언어의 개발이 어느 정도 끝난 상태여서 C 기반인 컴파일러를 완전히 Go로 대체할 수 있었습니다.

프로젝트 관리

우린 시작부터 성공하려면 프로젝트를 오픈소스로 만들어야 한다는 것을 알았습니다. 반대로, 프로젝트의 기본 개념을 잡고 기본적인 뼈대를 구현하는 것은 비공개로 우리끼리 만들어야 더 효율적이라는 것도 알고 있었습니다. 그런 면에서 개발 초기의 2년은 정말 중요했습니다.

이후 오픈 소스로의 전환은 정말 큰 변화였고 배움이었습니다. 우선 커뮤니티의 기여가 정말 압도적이었습니다. 커뮤니티가 참여하도록 유도하고 기대에 부응하는데 상당한 노력과 시간이 필요했습니다. 아직도 커뮤니티에 의해 윈도우 용 포트가 그렇게 빨리 만들어진 게 놀랍기만 합니다.

프로젝트를 오픈 소스로 전환 후, 어떻게 관리하고 의사 소통하는지 알아내는데 정말 오랜 시간이 걸렸습니다. 솔직히, 우린 커뮤니티와 소통하는 최적의 방법을 찾는데 정말 오래 걸렸습니다. 다시 한 번 커뮤니케이션에 능숙하지 못한 저희 문제입니다. 우린 잘 소통하고 있다고 생각했지만 항상 커뮤니티가 기대한 것과 우리가 만들어내는 것에는 차이가 있었습니다. 더 잘할 수 있는 부분이 분명히 있었다고 생각합니다.

다행히 오랜 시간을 들여서 우리의 사상이 커뮤니티에 전달되었던 것 같습니다. 비록 많은 오픈 소스 프로젝트들이 빠른 코드 수용 후 코드 퀄리티를 추구하지만, Go 프로젝트는 정반대였습니다. 우린 코드 퀄리티를 더 중요하게 생각했습니다. 이 방식이 프로젝트를 관리하는데 있어 더 효율적이라는 것은 지금도 변함이 없습니다. 다만, 이는 커뮤니티 기여자들에게 허들을 높이고 더 많은 것을 요구합니다.

참고로 Go 프로젝트는 4개의 CMS을 사용했습니다. SVN, Preforce, Mercurial, Git. Git 레포에는 아직도 SVN 시절 변경한 사항들이 남아있습니다.

추가적으로 많은 분들이 Go 팀이 구글의 영향을 많이 받는다고 생각하는데, 전혀 그렇지 않습니다. Go 개발팀은 거의 독립적으로 움직입니다. 구글보다 커뮤니티에서 요구하는 것들이 더 많습니다. 구글 내에서 Go를 개발해서 세상에 공개하는 것이 아니라 공개된 Go 언어를 구글에서 가져가서 쓰고 있습니다. 즉, Go 개발 팀의 연봉을 구글에서 제공하고 사실상 Go 개발 팀은 독자적입니다.

(TBC)

---

분량 조절 실패로 3개로 나뉘었습니다 😏

원글: https://commandcenter.blogspot.com/2024/01/what-we-got-right-what-we-got-wrong.html