Upgrade to Pro — share decks privately, control downloads, hide ads and more …

오픈소스 웹 브라우저 개발자는 이렇게 일한다

Amos Lim
November 16, 2024

오픈소스 웹 브라우저 개발자는 이렇게 일한다

2024-11-16 Open Source Conference (오쏘콘)
https://festa.io/events/6160

Amos Lim

November 16, 2024
Tweet

More Decks by Amos Lim

Other Decks in Programming

Transcript

  1. 구글 엔지니어는 이렇게 일한다 목차 •문화 •팀워크, 지식 공유, 공정

    사회, 팀 리딩, 조직 문화, 생산성 •프로세스 •규칙, 리뷰, 문서, 테스트, 폐기 •도구 •버전, 브랜치, 빌드 시스템, 리뷰 도구, 정적 분석, 의존성 관리, CI/CD
  2. 오픈소스 웹 브라우저 개발자는 이렇게 일한다 •문화 •팀워크, 지식 공유,

    공정 사회, 팀 리딩, 조직 문화, 생산성 •프로세스 •규칙, 리뷰, 문서, 테스트, 폐기 •도구 •버전, 브랜치, 빌드 시스템, 리뷰 도구, 정적 분석, 의존성 관리, CI/CD
  3. Chromium vs. Chrome •Crash Reports •User Metrics •Video/Audio Codec •배포

    형태 •QA 방식 •Google API Key 포함 여부 https://chromium.googlesource.com/chromium/src/ /main/docs/chromium browser vs google chrome.md
  4. 내 안의 작은 아이가 fork를... •2013년 Chromium 렌더링 엔진 WebKit

    fork -> Blink https://blog.chromium.org/2013/04/blink rendering engine for chromium.html
  5. Chromium 에 비교적 쉽게 접근하는 방법 •렌더링 엔진 수정 •명확한

    ? 웹 표준 문서와 웹 플랫폼 테스트 존재 •웹 브라우저 앱 기능 개발이 어려운 이유? •구글 개발자는 출근 시간에 하는 회사 업무 •로드맵? OKR? 디자이너? PM? 팀 내부에서 뭐하고 있는지 모름 •외부에서 접근이 불가능한 문서 등이 존재할 수 있음 •데일리 미팅을 하고 있을지도 모를 일
  6. 웹 브라우저와 웹 생태계 •웹 브라우저는 웹 엔진 이상의 웹

    플랫폼 역할 •웹 기술과 웹 브라우저 엔진의 파편화를 줄이기 위한 각자의 노력 •웹 표준 에디터 •웹 브라우저 개발자 •웹 개발자 •WHATWG, W3C 등의 오픈 커뮤니티 기반의 웹 표준 문서화 프로세스 •메이저 웹 브라우저의 웹 플랫폼 테스트 공통화
  7. 이길 수 없다면 합류하라 •Microsoft Edge 2018년 말 Chromium 기반으로

    전환 발표 •Chromium 오픈소스와 웹 플랫폼에 기여하겠다 https://blogs.windows.com/windowsexperience/2018/12/06/microsoft edge making the web better through more open source collaboration/ https://github.com/MicrosoftEdge/MSEdge
  8. 마이크로소프트의 변화 •오픈소스 친화 회사로 탈바꿈하던 시기 •구글 제외 Chromium

    반영 1위 •웹 플랫폼, 웹 표준에도 적극적으로 기여 중 https://youtu.be/cSRAz9Itw84?si 31PVuVnzKgA3URVz
  9. 대규모 오픈소스 프로젝트 •소스 클론 약 90GB .git 폴더 제외

    약 50GB •빌드 산출물 out 폴더 20 ~ 40GB 빌드 옵션에 따라 •일부 테스트 포함 빌드 4시간 Remote Build Cache 1시간 •8 core / 16 thread CPU + 32GB RAM 2018년 조립 PC...
  10. 웹 표준 Web Standards •WHATWG Web Hypertext Application Technology Working

    Group •W3C World Wide Web Consortium •IETF Internet Engineering Task Force •...
  11. 웹 표준 Web Standards •기능/목적 별로 Working Group 운영 •온라인

    정기 미팅 주간, 월간, ... •IRC •W3C TPAC 연례 전체 회의 •GitHub 에서 이슈 리포트 후 Pull Request 를 통한 수정 •GitHub Pages 로 문서 배포
  12. 문서 •docs 폴더, 각 모듈 폴더에 문서 존재 • https://chromium.googlesource.com/chromium/src/

    / main/docs • https://www.chromium.org/ 위 링크로 이관 중 •마크다운 •각종 가이드와 모듈 설명
  13. •Issue Tracker •Hotlist GoodFirstBug 으로 검색 •여러 조합으로 검색 •예

    componentid:1456329 assignee:none status:open •CSS 모듈 이슈 중 / assignee 없고 / open 되어 있는 이슈 •즐겨찾기 후 지속적인 확인 어떤 것을 구현할 것인가?
  14. Feature 문서 Blink Intents •Intent to Prototype Implement •Intent to

    Experiment Origin Trial •Intent to Ship •Intent to Deprecate •Intent to Remove
  15. Design Doc •테크 스펙, 개발 계획서, 명세서 •필수 X •작성하는

    경우 •전체에 큰 영향을 미칠 경우 핵심 기능 •대규모 변경과 히스토리가 필요한 경우 https://docs.google.com/document/d/14YBYKgk uSfjfwpKFlp omgUq5hwMVazy M965s 1KA/edit?tab t.0#heading h.7nki9mck5t64
  16. 개발 준비 •C + + , Java, Python, Javascript, 기타

    자체 protocol 언어 등, ... •성능 좋은 컴퓨터 •IDE •구글에서 만든 각종 라이브러리와 툴, 프로세스 적응 •...
  17. 스타일 가이드 / 정적 분석 •거의 모든 건 프로세스 상에서

    자동화 되어 있음 •아키텍쳐 구조 include, import rule 등 •구글 스타일 가이드와 자체 가이드 적용 •C + + 버전별 가이드 •이슈 트래커, 구글 그룹 포럼, 슬랙 등에서 활발히 논의가 이루어짐
  18. 테스트 •Unit Tests •Browser Tests e2e •Web Tests / web

    platform tests wpt •Instrumentation Tests Android only •EarlGrey Tests iOS only •Telemetry performance •Fuzzer Tests testing user facing APIs
  19. 테스트 •Unit Tests •Browser Tests e2e •Web Tests / web

    platform tests wpt •Instrumentation Tests Android only •EarlGrey Tests iOS only •Telemetry performance •Fuzzer Tests testing user facing APIs
  20. •web platform tests 실패 이슈 확인 •표준화도 했고 테스트까지 다

    만든 상태, 동작만 X •다른 웹 브라우저는? • 힌트를 얻을 수도... 어떤 것을 구현할 것인가? 2
  21. 리뷰 •폴더 별로 OWNERS 파일이 있음 •리뷰어는 보통 리뷰 권한

    별로 1명만 지정 •같은 리뷰어한테 꾸준히 리뷰를 받는게 중요 •수월한 리뷰, 다른 기회, committer 추천 등
  22. 업무와 관련된 오픈소스 프로젝트를 하면? •익숙한 빌드 환경 •익숙한 코드

    구조 •익숙한 개발 프로세스 •회사 소속이라는 이점
  23. 회사 / 팀에게 좋은 점 •수월한 프로젝트 downstream / rebase

    •공통 코드 수정 / 리팩토링 / 코드 개선 •결국 우리 프로젝트에서 사용할 코드 •오픈소스 프로젝트 영향력
  24. 나에게 좋은 점 •최신 트렌드, 기술 공부 •사내/사외 경쟁력 •자연스럽게

    풍부해지는 GitHub mirror repo / 관련 프로젝트 기여 •대규모 프로젝트의 개발 프로세스 경험 •자동화 끝판왕 체험 •해외 빅테크 개발자들과 함께… •인정 받는 기분
  25. Google Open Source Peer Bonus winner https://opensource.googleblog.com/2022/09/announcing the second group

    of open source peer bonus winners in 2022.html https://github.com/w3c/webauthn/issues/1738#issuecomment 1152696529 https://chromium review.googlesource.com/c/chromium/src/ /3678741
  26. Committer •Committer Commit 권한을 가진 사람 •조건 •10 ~ 20개의

    non trivial 패치 반영, 커미터 1명 추천, 2명 이상 동의 •Contributor -> Committer -> OWNER Reviewer •bug edit / trybot 권한 Committer가 아니더라도 받을 수 있음 • chromium.org 계정 •회사 계정을 써서 막상 쓸 일이 없음
  27. 후회? 아쉬움? •빨리 할 걸 기회가 없다고 생각했음 •타이밍이 있다.

    •꾸준히 할 걸 게을러서, 번아웃 이슈 •오래 하면 뭐라도 된다. •깊게 할 걸 실력 부족 •제대로 해야 남는다.
  28. 한계와 고민 •프로젝트의 규모가 너무 큼 •변화가 빠르다 •큰 그림을

    그리기 어려움 핑계… •하고 싶은 것, 쉬운 것만 하는 함정에 빠진다 어느 순간부터 발전이 없음 •Next Level? 웹 표준 에디터? 리뷰어? •본업은? •따로 공부도 해야 하고, 기여도 해야 하고, 언제 다 함?
  29. 오업일치 •오픈소스와 업이 같으면 좋겠는데... •이길 수 없다면 합류하라? •다른

    오픈소스 프로젝트를 찾든지 •오픈소스 프로젝트와 관련된 부서/회사를 찾든지
  30. 마무리 •오픈소스의 정의? 변질? •기업 입장에서 이유 없는 오픈소스는 없다

    •나도 나를 위해서 하는 것 •오픈소스 문화, 오픈소스 정신 •배우고 얻은 것이 있으니 환원하자 •개인의 환경과 관심에 맞는 프로젝트를 직접 찾아보세요.