Article Weekly, Issue 35

Period

2024-08-25 ~ 2024-08-31

Fixing a Bug in Google Chrome as a First-Time Contributor

• Chromium/Google Chrome 웹 브라우저의 버그를 처음으로 수정하며 대규모 오픈 소스 프로젝트에 기여함
• 과거의 오픈 소스 작업과는 매우 다른 독특한 경험이었음
• 이 과정을 통해 비슷한 작업을 시도하려는 개발자들에게 도움을 주기 위해 전체 과정을 기록함
• 버그
  • 수정한 버그는 Chromium Devtools와 메인 스레드 외부에서 실행되는 AudioWorklet과 같은 worklet의 네트워크 요청 간의 통합 문제였음
  • 이 문제는 여러 프로젝트에서 꾸준히 발생했으며, 최소한 세 가지 오류 보고서와 일치했음
  • 최소한의 재현 작업은 간단했고, 캐시 헤더가 설정된 스크립트를 사용하여 AudioWorkletProcessor를 생성하고 페이지를 다시 로드하는 방식으로 문제를 재현할 수 있었음
• Chromium 코드 다운로드 및 빌드
  • 버그를 실제로 수정하기 위한 첫 번째 단계는 Chromium을 처음부터 빌드하는 것
• 버그 찾기 및 수정
  • 빌드 환경이 작동한 후, 코드 탐색을 시작함
  • Chromium 코드베이스는 매우 방대하고, 전체적인 구조를 파악하기 어려웠음
• 테스트 및 코드 리뷰
  • 디버그 로그를 정리하고 diff를 최종 확인한 후, 코드를 리뷰 및 병합하는 과정을 탐색함
  • Chromium Gerrit 코드 리뷰 사이트에 계정을 만들고 CLA를 서명함
  • 리뷰어를 선정하고, 작성한 코드를 검토하여 필요한 테스트를 추가함
  • Devtools 네트워크 검사 기능을 테스트하는 여러 JavaScript 테스트를 참조하여 새로운 테스트를 작성함
  • 최종적으로 코드 리뷰에서 “LGTM” 승인을 받았고, PR이 병합됨
• 결과 및 회고
  • 버그 수정에 시간이 걸리고 많은 노력이 필요했지만, 매우 독특한 경험이었음
  • Chromium의 규모에서 소프트웨어가 어떻게 개발되는지 경험할 수 있었음
  • 개인적으로 코드가 전 세계 수백만(또는 수십억) 대의 장치에 포함된다는 사실이 큰 동기부여가 되었음
  • 이번 경험을 통해 Chromium에 기여하는 방법을 배웠으며, 앞으로도 더 많은 버그 수정을 시도해볼 예정임

Australian employees now have the right to ignore work emails, calls after hours

• 호주 근로자들은 이제 새로운 “연결 해제 권리(Right to Disconnect)” 법 덕분에 근무 시간 외에 업무 이메일과 전화 등의 사생활 침해를 무시할 수 있게 됨
• 이 새로운 규칙은 월요일부터 시행되었으며, 대부분의 경우 직원들이 근무 시간 외에 고용주로부터의 연락을 읽거나 응답하는 것을 거부해도 처벌받지 않음
• 지지자들은 이 법이 근무 시간 외 업무 이메일, 문자, 전화 등으로 인한 사생활 침해에 대해 직원들이 자신있게 대처할 수 있게 해준다고 말함
• 이러한 추세는 COVID-19 대유행 이후 가정과 직장의 경계가 혼란스러워지면서 가속화되었음

Predicting the Future of Distributed Systems

• 이 글은 분산 시스템의 변화하는 환경과 미래의 동향을 논의함
• 오브젝트 스토리지의 역할 확대
  • 오브젝트 스토리지는 그 신뢰성과 유연성 덕분에 점점 더 트랜잭션 및 분석 시스템에 통합되고 있음
  • 오브젝트 스토리지는 시스템 아키텍처의 핵심이 되어 가고 있으며, 이는 기술 채택 시 양방향 문 결정(가역적이고 유연한 결정)을 가능하게 함
• 프로그래밍 모델의 변화
  • 새로운 프로그래밍 모델이 등장하고 있으며, 이 모델들은 더 나은 보안, 이식성, 애플리케이션 상태 관리 등을 약속함
  • 그러나 이러한 모델들은 리스크가 큰 일방향 문 결정(되돌리기 어려운 결정)으로 여겨져, 그 잠재적인 이점에도 불구하고 채택하기 어려움
• 의사 결정 프레임워크
  • 글에서는 제프 베조스가 언급한 일방향 문(되돌릴 수 없는)과 양방향 문(되돌릴 수 있는) 결정을 참고하며, 특히 분산 시스템에서 기술 선택 시 이러한 유형을 구분하는 것이 중요하다고 강조
• 도전과 기회
  • 오브젝트 스토리지가 널리 채택되고 있는 반면, 새로운 프로그래밍 모델로의 전환은 잠재적인 리스크와 명확한 마이그레이션 경로의 필요성 때문에 더 어려움
  • 글에서는 성공적인 새로운 모델이 가역적인 채택 경로를 제공하여 이러한 리스크를 줄여야 한다고 제안
• 분산 시스템의 미래
  • 이 글은 분산 시스템이 계속 진화할 것이며, 오브젝트 스토리지가 핵심 역할을 하고, 새로운 프로그래밍 모델이 결국 주류가 될 것이라고 예측함
  • 그러나 어떤 기술이 성공할지를 예측하는 것은 어렵고 불확실하다는 점도 인정하고 있음
• 전체적으로 이 글은 분산 시스템에서 새로운 기술을 채택할 때 신중한 의사 결정을 내리는 것이 중요하며, 되돌리기 어려운 선택의 리스크와 잠재적 이점을 균형 있게 고려해야 한다고 강조

Erasure Coding for Distributed Systems

• 삭제 코딩은 저장 효율성과 장애 허용성 사이의 상충 관계를 설명하는 방법
• 애플리케이션은 분산 시스템의 공간 및 테일 레이턴시 개선을 위해 사용됨
  • 테일 레이턴시는 시스템 또는 서비스의 응답 시간 중에서 가장 긴 지연 시간을 가리키는 용어
  • 즉, 대부분의 요청은 일반적인 응답 시간 내에 처리되지만 일부 요청은 예기치 못하게 더 오래 걸릴 수 있는 경우를 나타냄
  • 이 경우, 테일 레이턴시가 발생하면 사용자 경험이 저하되는 결과를 초래할 수 있음
  • 따라서 테일 레이턴시를 최소화하고 시스템이 일관된 성능을 유지할 수 있도록 관리하는 것이 중요
• 정족수 체계과 사용법 등의 구현에 대한 내용 포함
• 데이터 청크 수에 따른 디코딩 성능 변화 및 메타 데이터 추가로 구성 설정 가능
• 다양한 종류의 삭제 코딩 방법이 소개됨
• 구현을 위한 다양한 에러 코딩 패밀리 중 하나로 추정됨
• 암호화 성능을 실험 할 수 있는 새로운 방법론 제시함
• 데이터 저장 시스템의 저장 비용을 절감하고 데이터 내구성을 높이는데 도움이 됨

Code review antipatterns

• 코드 리뷰로 두 명의 개발자가 코드를 보면서 문제를 발견하고, 프로젝트의 발전 과정에 대한 이해를 공유하는 기회가 생김
• 리뷰어는 작성자의 코드를 자세히 보면서 유용한 트릭을 배우거나, 작성자에게 유용한 트릭을 알려줄 기회를 발견할 수 있음
• 그러나 이는 ‘라이트 사이드’ 코드 리뷰어들이 사용하는 방식
  • 코드 리뷰를 코드 개선과 개발자들의 집단적 기술 향상을 위해 사용하는 것임
• 코드 리뷰는 완전히 다른 목적을 위한 강력한 도구가 될 수도 있음
  • 리뷰어가 ‘다크 사이드’로 전환한다면, 코드 개선을 방해하거나 지연시킬 수 있는 다양한 방법을 사용할 수 있음
  • 패치 작성자를 괴롭히거나 완전히 좌절시키는 등 다른 개인적인 목적을 추구할 수도 있음
• 이 글에서는 다크 사이드 코드 리뷰어들을 위한 안티패턴 리스트를 제시함
• The Death of a Thousand Round Trips
  • 코드를 읽으면서 사소한 것을 발견하자마자 리뷰 댓글로 지적하고, 그 즉시 읽기를 중단함
  • 개발자는 성실하게 그 사소한 것을 고치고 수정된 패치를 제출함
  • 리뷰어는 그 버전을 읽기 시작하고, 또 다른 사소한 것을 발견함. 첫 번째 리뷰에서 언급할 수 있었지만 그러지 않았음. 그 사소한 것을 지적하고 다시 읽기를 중단함
  • 이를 개발자가 희망을 잃을 때까지 반복함
• The Ransom Note
  • 이 패치가 개발자에게 특별히 중요한 것 같음
  • 그러나 리뷰어에게는 그렇게 중요하지 않음. 따라서 리뷰어는 권력 위치에 있음
  • 개발자가 원하는 변경 사항을 리뷰어에게 중요한 추가 작업들이 완료될 때까지 인질로 잡아둘 수 있음
• The Double Team
  • 하나의 패치, 두 명의 리뷰어
  • 한 리뷰어가 변경을 요구할 때마다 개발자는 순순히 변경함. 그러면 다른 리뷰어가 불평할 차례가 됨
  • 리뷰어들은 번갈아가며 서로 상충되는 요구사항을 제시함
    • 하지만 항상 개발자를 향해 코멘트를 함. 리뷰 스레드에서 서로 직접 논쟁하는 것은 피함
  • 개발자가 포기할 때까지 리뷰어들이 개발자를 앞뒤로 몇 번이나 튕겨낼 수 있는지 보는 것임
• The Guessing Game
  • 문제가 있고, 그 문제를 해결할 수 있는 다양한 방법이 있음
  • 개발자는 한 가지 해결책을 선택하고 패치를 제출함
  • 리뷰어는 그 특정 솔루션을 문제 해결 여부와 무관한 이유로 비판함
• The Priority Inversion
  • 첫 번째 코드 리뷰에서는 사소하고 간단한 것들을 지적함
  • 개발자가 그것들을 수정하기를 기다렸다가 중대한 문제를 제기함
    • 패치의 상당 부분을 완전히 재작성해야 하는 근본적인 문제가 있음. 이는 이미 수행한 사소한 수정 작업의 많은 부분을 버려야 함을 의미함
    • 누군가에게 많은 작업을 시키고 그것을 버리게 만드는 것만큼 “당신의 작업은 원하지 않으며, 당신의 시간은 소중하지 않다"는 메시지를 잘 전달하는 것은 없음
  • 이것만으로도 개발자가 포기하기에 충분할 수 있음
• The Late-Breaking Design Review
  • 몇 주 또는 몇 달 동안 많은 별도 패치로 엄청나게 복잡한 작업이 진행되어 왔음
  • 리뷰어는 그 전체 작업의 설계에 동의하지 않지만, 원래 논의에는 참여하지 않았거나 토론에서 패배한 측이었음
  • 그런데 이제 리뷰어에게 그 작업의 중간에 있는 사소하지만 중요한 부분(예: 많은 개발자를 막고 있는 버그에 대한 쉬운 수정)을 검토해달라는 요청이 들어옴. 이것이 리뷰어에게는 기회임
  • 리뷰어는 지금까지 수행된 작업의 전체 설계에 대한 정당성을 요구함
  • 개발자가 전체 작업의 일부만 담당하고 있어서 답변을 모른다면, 그것은 리뷰어의 문제가 아님. 리뷰어가 만족할 때까지 “승인” 버튼을 누르지 않을 것임
• The Catch-22
  • 하나의 큰 패치라면 읽기가 너무 어려움. Self-Contained된 하위 조각으로 분할할 것을 요구함
  • 반대로 작은 패치가 많다면 그 중 일부는 그 자체로는 의미가 없음. 다시 붙여넣을 것을 요구함
  • 어떤 종류의 트레이드오프가 특정 경우에 관련이 있는 것처럼 보인다면 이를 활용해 불평할 이유를 찾을 수 있음
    • 예를 들어 코드가 알아보기 쉽게 작성되었다면 성능이 좋지 않을 것이고, 잘 최적화되었다면 읽기 어렵고 유지 관리하기 어려울 것임
• The Flip Flop
  • 코드의 동일한 부분에 사람들이 일반적으로 수행하는 유형의 변경 사항이 있음
  • 리뷰어는 이전에 이러한 변경 사항을 여러 번 검토한 적이 있음
  • 또 다른 변경 사항이 들어옴. 작성자는 이전 변경 사항을 자세히 살펴보고 기존 패턴을 주의 깊게 따랐으며, 이 영역에 익숙해 보이는 리뷰어를 선택함
  • 리뷰어는 이전에는 전혀 문제 삼지 않았던 변경 사항의 한 측면에 갑자기 이의를 제기함. 기존 패턴을 따르는 것만으로는 충분하지 않음
  • 작성자가 이전에 동일한 변경 사항을 보여주면서 리뷰어의 비일관성을 지적하면 어떻게 될까?
    • 리뷰어는 “맞다. 그것도 변경되어야 한다"라고 말함
    • 리뷰어는 기존 사례를 모두 변경하겠다고 자원하지 않도록 주의해야 함. 운이 좋다면 개발자가 이를 기존 사례를 직접 변경하라는 지시로 해석하여 리뷰어가 많은 노력을 아낄 수 있음

References

• https://cprimozic.net/blog/fixing-a-bug-in-google-chrome/
• https://www.reuters.com/world/asia-pacific/australian-employees-now-have-right-ignore-work-emails-calls-after-hours-2024-08-25/
• https://blog.colinbreck.com/predicting-the-future-of-distributed-systems/
• https://transactional.blog/blog/2024-erasure-coding
• https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/