Github 엔지니어처럼 커뮤니케이션하는법 (How GitHub Engineering communicates)

제가 개발자로 취업한 후 1년 동안 가장 크게 배운 것은,
기술보다는 커뮤니케이션의 중요성이었습니다.

하지만 '커뮤니케이션을 잘한다'는게 참 측정하기 어려운 말이더라구요.
이런 역량은 어떻게 길러야하는지 가이드라인이 없어 어려웠습니다.

그러던 중 How GitHub Engineering communicates 라는 개발자 커뮤니케이션 원칙을 보게 되었고, 공감한 내용이 많아 요즘 가슴에 새기며 일하고 있습니다.

같은 고민을 갖고 계신 분들께 도움이 될거 같아,
원문을 조금 더 이해하기 쉽도록 일부 각색하여 포스팅합니다.

---

How GitHub Engineering communicates 에 대하여

Github는 각 팀이 커뮤니케이션 방식을 자율적으로 결정하는 문화를 가지고 있습니다.
이는 새로운 방식을 실험할 수 있게 하지만, 서로 문화가 다른 팀 간 협업을 위해서는 먼저 어떻게 소통할지에 대한 메타-커뮤니케이션이 필요했습니다.

How GitHub Engineering communicates는 2023년 3월, Github 엔지니어링 조직 내에서 실시된 설문 조사에 따라 제작된 커뮤니케이션 가이드라인입니다.
커뮤니케이션에 있어 일관성을 갖게 하기 위함이며, 모든 엔지니어링 팀을 위한 커뮤니케이션 관행의 공통 핵심을 개략적으로 설명합니다.

팀 마다의 상황에 맞게 가이드라인을 적용하고, 다른 팀과의 커뮤니케이션 인터페이스를 위한 공통된 "API"를 유지할 것을 권장합니다.

1. 비동기 커뮤니케이션을 우선합니다.

지식 근로자들은 긴 시간 동안 한 가지에 집중할 때 가장 생산적입니다.
1시간 씩 두번 일하는 것과, 30분씩 네번 일하는 것은 완전히 다릅니다.

위처럼 일할 수 있다면 이상적이겠지만, 일하다 보면 때때로 Context Switch가 필요할 때가 있습니다.
중간에 미팅에 들어가거나, '지금 바빠요? 잠깐 시간 돼요?' 등등의 이유로 말이죠.

잠시 그 일을 처리한 다음, 원래 하던 일로 돌아올 때 스무스하게 되던가요?
보통은 상당한 Context Switch 비용이 듭니다.

그래도 용건이 있다면?
Issue나, 채팅을 우선합니다.
긴급하거나 텍스트로 커뮤니케이션하기 복잡할 경우에는 예외로 합니다.

2. 기록합니다.

비동기 커뮤니케이션을 성공적으로 하려면,
의사 결정의 why와 how를 잘 적어서 소통하는게 필수적입니다.

그리고 이건

• 모두가 정보에 접근할 수 있으며
• 내구성이 좋고
• 검색이 가능한

매체에 기록되는 것이 좋습니다.

이 때 실용적인 방법은 URL을 적극적으로 사용하는 것입니다.

모든 작업, 아이디어, 의사결정에 각각의 URL을 부여합니다.
누군가 질문하면 링크를 대답으로 줄 수 있게끔 말이죠.
해당 URL 로 미래의 자신과, 미래의 동료들에게 정보를 남길 수 있다는 장점도 있습니다.

3. 작업을 공개하고 과하게 소통합니다.

작업을 비축해두지 마세요. 가시성이 핵심입니다.

• URL에 작업을 남기면 작업을 쉽게 공개할 수 있다는 장점이 있습니다.

• 공개적으로 작업하고, 가장 실용적인 범위에서 널리널리 공유하세요.

• 유용한걸 찾았다면 공유해서 모두가 활용할 수 있게 합니다.

• 다른 사람들이 선택적으로 정보를 볼 수 있게 합니다. (opt-in)

• 모든 소통의 시작에 tl;dr 을 붙여 요지를 정확히 전달하도록 합니다.

4. Github 툴과 워크플로우를 우선합니다.

공개적으로 일하는 가장 좋은 방법은 Github 툴을 이용하는 것입니다. (더 나은 대안이 있는 경우가 아니라면)

즉, 프로세스를 자연스럽게 노출하는 시스템을 이용하는 것이 가장 좋습니다.

그러나 채팅이나 구두 등으로 의사결정이 이루어졌다면, 이후 결과를 꼭 기록해야 합니다.

5. 협업을 수용합니다.

• SW 개발은 팀 스포츠입니다. 일찍, 자주 인풋과 피드백을 얻으세요.
• 의사결정을 문서화할 때는 배경, 트레이드오프, 결과를 포함하세요. 이해관계자들이 적극적으로 의사결정에 참여할 수 있게 됩니다.
• PR은 그 자체로는 협업이 아닙니다.

협업 기반으로 의사결정을 내리는 법

• 결정을 내리기 전에 피드백을 구하세요.
• 문서는 작성자와 이해관계자들이 문제가 무엇인지, 제약이 무엇인지, 어떻게 해결할 것인지 합의하는 것이어야 합니다.
• 문서는 찾기 쉬운 곳에 있어야 합니다. (작업을 공개하는 것을 잊지 마세요!)
• 문서는 충분한 세부사항을 갖춰야 합니다. (가용성, rollout 전략, scaling 패턴 및 타임라인 등)
• 더 큰 맥락을 제공하기 위해 문서 링크를 남기세요.

6. 문서 관리를 중시하는 문화를 조성합니다.

좋은 문서를 만드는 것만큼 문서를 관리하는 것도 중요합니다.

팀이 재구성되거나, 코드/프로세스가 바뀌었을 때 관련된 문서를 업데이트하세요.
문서를 업데이트하는 작업을 따로 해야 하지만,
최신 상태를 유지하면 다음 번에 문서를 업데이트하는 시간이 절약됩니다.

문서가 부정확하거나 오래되었다면, 내부 툴에 대한 신뢰가 떨어집니다.
그리고 정확한 정보를 찾기 위해 많은 시간을 들이게 됩니다.

만약 오래된 정보를 발견했다면, PR을 올리거나 담당자에게 이슈를 남기세요.

만약 문서 관리의 부담이 그 이득보다 크다면, 문서를 없애거나 간소화하세요.

7. 공개적이고, 정직하고, 진정성 있게 소통합니다.

정중하게 말하고 서로 경청하세요.
문화마다 커뮤니케이션 패턴이 다를 수 있으니, 의도를 추측하기보다는 한번 더 질문해서 명확하게 하세요.

중요 변경사항 등 더 복잡한 커뮤니케이션을 구상할 때는,
동료가 가질 수 있는 질문을 미리 준비하고 FAQ를 제공하세요.

아는 것과 모르는 것을 공개하세요.
"아직 모른다"고 말하는 것이 질문이 없는 척 하는 것보다 낫습니다.

7-1. 포용적인 언어를 사용하려고 노력합니다.

포용성을 위한 노력

• 날짜 포맷 지정
• 문맥 없이 약어 사용 지양
• 회의나 일정을 잡을 때 타임존을 고려
• 기타 등등

모든 커뮤니케이션에서 포용적인 언어를 사용하려고 노력하세요.
접근성 또한 고려하세요. (이미지의 alt-text, 의미있는 마크다운 제목과 설명이 포함된 링크 등)

7-2. 이모지와 GIF를 활용합니다.

이모지와 GIF는 온라인 글쓰기 상에서 표정과 바디 랭귀지 역할을 합니다.
감정/어조를 전달하거나 축하할 때 사용하기 좋습니다.

커뮤니케이션은 전문적이고, 정중해야 하지만 너무 형식적인 필요는 없습니다.

Github가 이모지와 GIF를 사용하는 이유
단순히 고양이 이모지가 귀여워서가 아닙니다.
:trollface: 가 가장 효과적으로 빈정거릴 수 있는 방법이기 때문입니다.
특히 영어가 모국어가 아닌 사람들, 신경 다양성을 가진 사람들과 더 포용적으로 커뮤니케이션할 수 있습니다.

유머와 창의성은 어조를 전달하고 재미있게 하는데 도움이 되지만, 애니메이션을 선호하지 않을 수도 있으니 적당히 사용하세요. (사이렌, 알람 등)

이모지가 적절한지 너무 신경쓰지 않아도 되지만,
맞는 것을 찾고자 한다면 Emoji Searcher 등을 이용하세요.

접근성을 위해, 커스텀 이모지가 의미있는 이름을 가지도록 하세요.
Github에서 애니메이션 GIF를 사용한다면, alt text를 포함해서 이미지가 모두에게 접근 가능하도록 하세요. (예시: ![a puppy yawning](puppy-yawning.gif)

그리고 비동기적인 리액션으로 활용하는 것도 좋은 방법입니다.
토론, 이슈, 채팅에 대해 이모지로 반응해 무언가를 확인했다는 것을 표현합니다.

8. 실용성이 순수성을 이깁니다.

이건 가이드라인일 뿐, 규칙이 아닙니다.
중요한 것은 규칙을 따르는 것이 아니라, 프로세스를 통해 원하는 결과를 얻어내는 것입니다.

따라서 여기 얽매이기보다는 그 의도를 이해하고,
현실적이고 실용적인 접근을 추구하는 것이 중요합니다.