지난 15년 동안 WebKit과 Chromium 같은 웹 브라우저를 다뤄 온 Yeunjoo는 현재 오픈소스 컨설팅 회사 Igalia에서 일하고 있다.
Yeunjoo는 지난 15년 동안 웹 브라우저(WebKit과 Chromium) 작업을 해왔고, 현재는 오픈소스 컨설팅 회사 Igalia에 있다.
By Phil Eaton·2026년 5월 20일
구독자이기 때문에 이 글을 먼저 읽고 계십니다. 여러분의 지원이 이런 글을 가능하게 합니다. 감사합니다.
이 글은 소프트웨어 인프라에서 일하는 개발자들(창업자도, 임원도 아닌)을 인터뷰하는 시리즈의 일부로, 그들의 일, 여기까지 오게 된 과정, 자랑스러워하는 프로젝트, 배운 사건들, 그리고 무엇에 호기심을 느끼는지를 이해하기 위해 기획되었습니다.
Yeunjoo(LinkedIn, Website)는 지난 15년 동안 웹 브라우저(WebKit과 Chromium) 작업을 해왔으며, 처음에는 LG Electronics에서 일했고 현재는 오픈소스 소프트웨어 개발 컨설팅 회사 Igalia에 있다.
저는 Chromium 팀의 일원이고 최근에는 엔터프라이즈 브라우저 작업을 하고 있습니다. 많은 엔터프라이즈 브라우저 벤더가 웹 표준과의 호환성, 강력한 크로스플랫폼 지원, 활발한 업스트림 유지보수, 생태계, 툴링 등의 이유로 Chromium을 채택합니다. 또한 브라우저는 엔터프라이즈 서비스의 주요 제어 지점이 되었기 때문에, Igalia가 엔터프라이즈 벤더와 협업할 기회도 더 많아졌습니다.
여러 엔터프라이즈 벤더와 함께 일하면서 저는 레이아웃, JavaScript 엔진, 미디어 기능 같은 영역보다는 정책 제어와 데이터 보호에 관련된 엔터프라이즈 기능을 구현해 왔습니다. Chromium에는 일반적인 브라우저 제어를 위한 내장 엔터프라이즈 정책이 이미 있지만, 일부 고객은 단순히 JSON 파일에 새 정책 항목을 추가하는 것으로는 부족하고, 새로운 코드 경로와 훅을 추가해야 하는 더 특수한 동작을 원합니다. 거기에 더해, 자체 문법, 프로토콜, 평가 로직을 가진 별도의 정책 엔진도 고려해야 합니다.
엔터프라이즈 브라우저에서 제가 작업한 또 다른 영역은 브랜딩입니다. 브랜딩은 보통 새 프로젝트를 처음부터 시작할 때 가장 먼저 하는 작업입니다. 여기에는 아이콘과 문자열 변경뿐 아니라 설정 화면이나 새 탭 페이지의 레이아웃, 스플래시 화면 등의 커스터마이징도 포함됩니다. 한 프로젝트에서는 UX 디자이너와 직접 협업하며 에셋을 받고 레이아웃에 대해 논의했습니다. UX 디자이너의 관점을 더 잘 이해하는 데 도움이 되었기 때문에 제게는 꽤 흥미로운 경험 중 하나였습니다.
엔터프라이즈 솔루션 벤더가 개발한 제품에 사용되는 Chromium 버전을 뜻합니다. 이런 브라우저는 종종 고객에게 엔터프라이즈 솔루션으로 판매되지만, 많은 경우 해당 회사들도 내부적으로 직원들에게 그 브라우저를 사용하도록 요구합니다. 그래서 그 회사의 직원들이 종종 그 엔터프라이즈 브라우저의 첫 사용자이기도 합니다.
리베이스는 늘 도전 과제입니다. Chromium은 크고 빠르게 변화하는 저장소이고, 매 릴리스마다 만만치 않은 커밋이 들어가기 때문입니다. 제가 알기로 Chromium을 사용하는 잘 알려진 브라우저 벤더들은 각자 포크를 최신 상태로 유지하기 위한 자체 리베이스 전략을 가지고 있습니다.
Igalia 역시 이 영역에서 고객들로부터 도움과 조언을 요청받아 왔습니다. 리베이스 전략을 정의할 때는 몇 가지 중요한 요소가 있습니다. Rebase를 할지 Merge를 할지, 언제 업데이트할지, 다운스트림 델타의 크기와 형태는 어떤지, 자동화는 어느 정도인지, QA를 위한 팀 역량은 충분한지 등입니다. 제 동료 José Dapena Paz는 downstream maintenance에 관한 흥미로운 블로그 글 시리즈를 올렸는데, 읽어보시길 권합니다.
개인적으로 Chromium 포크에서 개발할 때는 리베이스 중 merge conflict를 줄일 수 있는 방식으로 다운스트림 변경을 구조화하려고 합니다. 예를 들어 저는 새로운 다운스트림 기능을 분리된 레이어(//igalia 같은 곳)에 구현하고, //components, //content, //ui 같은 업스트림 컴포넌트를 재사용해서 제 델타를 더 작게 유지하는 편을 선호합니다. 여기서 중요한 점 하나는 기존 레이어의 계층과 경계를 존중하는 것입니다. 대부분의 업스트림 리팩터링은 레이어 간의 명확한 의존성 규칙을 유지하므로, 그 구조를 따르는 다운스트림 변경은 리베이스 시 merge conflict도 적고 회귀도 더 적게 만듭니다.
Igalia는 오픈소스 컨설팅 회사이기 때문에 대부분의 프로젝트가 고객 주도로 진행됩니다. 어떤 프로젝트는 제품별 기능 구현이나 다운스트림 Chromium 포크 유지보수를 포함하고, 다른 프로젝트는 업스트림 기여에 초점을 맞춥니다. 업스트림 쪽에서는 고객을 위해 개발된 기능을 업스트림에 반영하도록 돕기도 하고, CSS 표준화 노력을 가속하는 일을 돕기도 합니다.
우리는 고객 프로젝트뿐 아니라 내부 투자 프로젝트도 진행합니다. Igalia는 의미가 있거나 전략적으로 중요하다고 믿는 오픈소스 프로젝트에 자원의 일부를 투자합니다. 오랫동안 여러 고객과 긴밀하게 일해 왔기 때문에, Igalia는 오픈소스 프로젝트와 생태계에 무엇이 필요한지 잘 이해하고 있습니다.
이런 투자 프로젝트 중 일부는 우리가 반복적으로 봐 온 필요에서 나옵니다. 예를 들어 제 동료 Miyoung Shin은 확장 기능 관련 코드를 //chrome에서 //extensions로 옮기는 작업을 하고 있는데, 이를 통해 컴포넌트화 방식으로 Chromium이 embedder에서 확장 기능을 지원할 수 있도록 하고 있습니다.
Igalia가 프로젝트 제안을 검토할 때는 먼저 사용 가능한 자원이 있는지, 그리고 사람들이 그 프로젝트에 관심이 있는지를 확인합니다. 이는 제가 제 관심사와 맞는 프로젝트에서 일할 기회도 있다는 뜻입니다. 저는 보통 특정 도메인에만 집중하기보다 Chromium의 여러 영역을 넘나들며 일하는 것을 즐기기 때문에 “그 프로젝트를 하고 싶어요!”라고 말하는 편입니다.
프로젝트의 규모와 기간은 목표에 따라 달라집니다. 예를 들어 Chromium 기반 다운스트림 브라우저를 만들고 새로운 기능을 구현하는 것이 목표라면, 초반에는 프로젝트가 크고 목표를 달성해 갈수록 더 작아질 수 있습니다. 반면 어떤 유지보수 프로젝트는 규모는 작지만 수년에 걸쳐 이어지는 장기 프로젝트이기도 합니다.
제가 결국 깨닫게 된 한 가지는, 오픈소스 프로젝트가 제가 상상했던 것보다 훨씬 더 접근하기 쉽다는 점입니다.
Igalia에 합류하기 전까지 저는 거의 10년 동안 여러 브라우저 엔진을 다뤘음에도 오픈소스 프로젝트에 기여한 적이 없었습니다. 조금 게을렀던 면도 있었고, 솔직히 그렇게 큰 오픈소스 프로젝트에 기여한다는 생각 자체에 압도되기도 했습니다. 그렇게 많은 사람이 널리 사용하는 프로젝트를 망가뜨릴까 봐 두려웠습니다. 또 제 다운스트림 작업이 업스트림에 흥미롭거나 유용할지 의심하기도 했습니다. 너무 제품 특화된 일이라고 생각했기 때문입니다.
또 다른 어려움은 제 익숙한 영역을 벗어나는 것이었습니다. 한국은 비교적 동질적인 사회였고, 예전에는 다른 문화적 배경을 가진 사람들과 소통할 일이 거의 없었습니다. 코드 변경을 논의하고 리뷰하는 과정에서 영어로 잘 소통할 수 있을지도 확신이 없었습니다.
하지만 그렇게까지 걱정할 필요는 없었습니다! 오픈소스 커뮤니티는 다양한 배경의 새로운 기여자들을 반갑게 맞이하고, 초보자들을 기꺼이 도와줍니다. 제가 Chromium에 처음으로 업스트림 기여를 한 것은 작은 리팩터링 커밋이었는데, 예상보다 훨씬 쉬워서 놀랐습니다. 작은 커밋들을 기여하며 Chromium 생태계를 익히고 나니, 더 큰 커밋도 더 이상 위협적으로 느껴지지 않았습니다.
저는 전자공학을 전공했지만, 반도체나 회로 설계 같은 전통적인 하드웨어 분야보다는 디지털 신호 처리와 임베디드 시스템에 더 관심이 있었습니다.
커리큘럼의 핵심 과목 중 하나가 C 프로그래밍이었기 때문에 프로그래밍에도 어느 정도 익숙했습니다. 또 하드웨어 프로젝트보다 훨씬 더 빨리 눈에 보이는 결과를 볼 수 있었기 때문에 소프트웨어 개발에 더 매력을 느끼게 되었습니다.
저는 대형 산업 회사에서 커리어를 시작했고, 순수 소프트웨어 개발을 하는 브라우저 팀에 합류했습니다. 프로그래밍에는 관심이 있었지만 정식 컴퓨터 과학 배경이 많지 않았기 때문에, 실제 소프트웨어 프로젝트를 하며 많은 것을 배워야 했습니다. 퇴근 후에는 동료들이 추천해 준 유명한 책들, 예를 들면 "The C++ Programming Language", "Design Patterns", "Refactoring" 같은 책으로 컴퓨터 과학을 공부하는 데 시간을 썼습니다.
결국 저는 소프트웨어로 문제를 해결하는 일을 진심으로 즐긴다는 사실을 깨달았습니다.
커리어를 시작하자마자 브라우저 팀에 배치되었습니다. 당시에는 브라우저 개발이 뭔지 전혀 몰랐습니다. 컴퓨터 과학도 거의 몰랐으니 당연한 일이었죠! 제가 처음 맡은 일은 SmartTV 브라우저에서 WebGL용 하드웨어 가속을 활성화하는 것이었습니다. 제가 기여할 수 있었던 부분은 EGL API를 사용해 CPU와 GPU 사이의 불필요한 복사를 줄이는 아주 작은 최적화뿐이었습니다. 그때는 새로운 지식을 한꺼번에 소화하느라 너무 바빠서 브라우저 개발에 깊이 뛰어들 생각까지는 하지 못했습니다.
저는 WebKit 작업을 했고, 이후 이전 회사가 Chromium을 채택하면서 Chromium으로 옮겨 갔습니다. 브라우저의 여러 부분으로 제 작업 범위가 점차 넓어지면서, 성숙한 오픈소스 브라우저 엔진에서 일하며 소프트웨어 엔지니어링에 대해 아는 것의 상당 부분을 배웠다는 사실을 문득 깨달았습니다. 브라우저 엔진은 다양한 기술이 뒤섞인 용광로 같은 곳이고, 저는 오픈소스 커뮤니티의 뛰어난 엔지니어들이 작성한 깔끔하고 잘 구조화된 코드를 읽으며 많은 것을 배웠습니다.
아마 그래서 지금도 브라우저 개발을 즐기는 것 같습니다. 언제나 새롭게 배울 것이 있고, 브라우저 개발은 제가 소프트웨어 엔지니어로 성장하기에 가장 좋은 장소였습니다.
하나의 큰 리팩터링 프로젝트는 Google이 주도한 Multiple Page Architecture (MPArch) project였습니다. 이 프로젝트는 back/forward cache, prerendering, portals, fenced frames 같은 기능을 완전히 지원하기 위해 중요한 아키텍처 변경을 도입했습니다.
이 프로젝트는 핵심 내비게이션 아키텍처를 수정했고 Chromium의 많은 부분에 영향을 미쳤기 때문에, 변경 사항을 한 번에 모두 배포할 수는 없었습니다. Google은 MPArch를 위한 새로운 내비게이션 경로를 도입했고, 저는 기존 경로를 점진적으로 교체하는 일을 도왔습니다. 이 작업에는 여러 플랫폼에서 아무것도 망가지지 않았는지 확인하는 과정이 포함되었고, 때로는 코드 오너들과 긴 논의가 필요하기도 했습니다.
이런 종류의 대규모 리팩터링은 많은 기여자가 함께 작업해야 한다고 생각합니다. 특히 Chromium의 핵심 부분을 건드리기 때문입니다. Igalia는 이미 Chromium 오픈소스 커뮤니티의 주요 기여자였고, 경험 많은 기여자들이 함께 일한 덕분에 이 리팩터링 프로젝트를 더 빠르게 진행할 수 있었습니다.
이전 회사에서는 디지털 사이니지 장치를 위한 비디오 기능 구현 작업을 했습니다. 한 사용 사례는 장치를 끄지 않고 비디오 광고를 계속 재생하는 것이어서 안정성이 매우 중요했습니다.
기억에 남는 버그 하나는 비디오 재생 중 간헐적으로 검은 화면이 나온다는 보고였는데, 재현이 매우 어려웠습니다. 기억하기로는 원인을 좁혀 가는 데 꽤 오랜 시간을 썼습니다.
우연히 한 번 배경이 완전히 흰색인 비디오를 테스트했는데, 흰색 영역이 검은색으로 렌더링되는 것을 발견했습니다. 그게 비디오 합성 과정에서의 alpha 처리와 관련된 문제라는 단서가 되었고, 아래 레이어가 드러나고 있었던 것입니다. 지금은 정확한 수정 내용을 기억하지 못하지만, 원인을 알아낸 뒤에는 한 줄 수정으로 끝났던 것은 기억합니다.
확실히 C++입니다! 잘 설명하긴 어렵지만, 제 커리어 내내 C++ 코드를 써 왔기 때문에 현대적인 C++를 쓰는 것이 이제는 제게 아주 자연스럽게 느껴집니다.
개인적으로는 모든 언어가 저마다의 강점을 가지고 있다고 생각하고, C++ 템플릿을 사용해 재사용 가능한 코드를 작성하고 보일러플레이트를 줄이는 것처럼, 어떤 언어를 그 언어가 설계된 방식대로 사용할 수 있을 때 정말 만족스럽습니다.
좋은 질문이네요. 예전에 쓰던 노트북에서 Chromium for Android를 클린 빌드하는 데 9시간이 걸렸던 일은 절대 잊지 못할 것 같습니다.
이제는 새로 산 강력한 노트북 덕분에 클린 빌드가 3시간도 채 걸리지 않고, 로컬 빌드를 빠르게 하기 위해 ccache도 사용합니다. ccache는 특히 다운스트림 프로젝트 작업처럼 베이스 코드를 자주 업데이트할 필요가 없을 때 잘 작동합니다. 만약 매일 많은 파일을 건드리는 대규모 업데이트가 있는 다운스트림 프로젝트를 한다면, 아마 nightly로 가져오고 빌드하는 환경을 구성할 것 같습니다.
업스트림에 기여할 때는 Chromium 커미터로서 “try job access”(즉, Google의 공유 인프라에서 머지 전 테스트 빌드를 실행할 수 있는 권한)가 있기 때문에 Google의 원격 빌드 실행 서비스를 사용합니다. 꽤 빠른 편이라 제 노트북에서도 Android 클린 빌드가 보통 10~15분 정도 걸리지만, Google 의존성을 줄이기 위해 다른 RBE 백엔드를 써볼까 생각한 적도 있습니다.
제 생각에 테스트는 Chromium에서 필수적입니다. 수많은 기능을 지원하고 매우 다양한 플랫폼을 대상으로 하는 브라우저 엔진이기 때문입니다.
Chromium에는 수만 개, 아니 그보다 더 많은 단위 테스트, 통합 테스트, 레이아웃 테스트, 플랫폼별 테스트 등이 포함되어 있습니다. 개발자가 모든 테스트를 로컬에서 실행하는 것은 매우 어렵습니다. 그래서 업스트림에는 각 변경마다 테스트를 실행하고 모든 것이 통과하면 커밋을 반영하는 Commit Queue(CQ)가 있습니다. 다운스트림 프로젝트를 할 때도 가능한 한 이른 시점에 CI 환경에서 Chromium 테스트를 활성화하는 것이 좋습니다. 적어도 프로젝트가 수정하는 컴포넌트와 관련된 테스트 스위트는 활성화해야 합니다.
테스트 수가 워낙 많다 보니, 제게는 Chromium 개발이 매우 테스트 주도적으로 느껴집니다. 기여자들은 자신이 만든 변경을 충분히 커버하는 테스트를 작성할 것으로 기대되고, 리뷰어들도 테스트가 없으면 코드 리뷰 중에 보통 테스트를 요구합니다.
저는 이런 강한 테스트 문화가 Chromium이 이렇게 거대한 코드베이스와 많은 플랫폼을 지원하면서도 계속 진화할 수 있는 이유 중 하나라고 생각합니다.
WebKit과 Chromium에서의 일을 비교할 수 있을지는 잘 모르겠습니다. 제가 WebKit에서 일했을 때는 경력 초반이었기 때문입니다. 하지만 WebKit 작업은 현대 브라우저의 멀티프로세스 아키텍처 개념을 이해하는 데 도움이 되었고, 그 덕분에 이후 Chromium을 이해하는 일이 훨씬 쉬워졌습니다.
저는 지금도 Chromium에서 일하는 것을 즐기지만, 기회가 있다면 WebKit에 기여하는 것도 열려 있습니다. :)
저는 제 작업 환경에서 AI Clients를 어떻게 활용할 수 있을지 배우고 싶습니다. 요즘은 Claude Code를 사용하고 있는데, 분명히 생산성이 높아집니다. 하지만 Claude Code를 쓰기 시작한 지는 정말 얼마 되지 않았기 때문에, 그 기능을 효과적으로 사용하는 법을 배우는 것처럼 아직 개선할 여지가 많다고 생각합니다.
또 AI 도구를 사용해 제 생산성 도구나 VIM 플러그인을 직접 만드는 아이디어도 몇 가지 있습니다. 그것만 생각해도 벌써 기대됩니다.
까다로운 질문이네요. 개인적으로는 AI 덕분에 Chromium 개발자로서 훨씬 좋아졌습니다. 이렇게 큰 코드베이스를 조사하는 데 드는 시간을 줄여 주기 때문입니다. 익숙하지 않은 컴포넌트를 이해하거나 복잡한 코드 경로를 추적하려 할 때 특히 유용합니다.
Chromium 커뮤니티에 대해서는, 제가 한동안 업스트림 활동을 아주 활발히 하지는 않았지만, 지금은 커뮤니티가 새로운 기술에 적응하는 과도기라고 생각합니다. 커미터 요구 사항도 AI 생성 코드에 대한 가이드라인을 포함하도록 업데이트되었고, 업스트림 Chromium은 이제 AI 코딩 에이전트 관련 파일을 위해 //agents도 제공합니다.
도구는 도구일 뿐이고, 저는 Chromium 커뮤니티의 이런 흐름에 대해 낙관적으로 보고 있습니다. 하지만 AI 에이전트에 휘둘리지 않도록 조심해야 합니다.
저는 Vim을 종료할 수 있습니다. :) 가끔 NeoVim이나 VSCode 같은 다른 에디터를 기웃거리기도 하지만, 유연성과 단순함 때문에 결국은 늘 Vim으로 돌아옵니다.
기뻤습니다. 제 커리어를 돌아볼 좋은 기회였어요. 초대해 주셔서 감사합니다!
Phil은 The Consensus의 창립자입니다. 그전에는 EnterpriseDB에서 Postgres 제품에 기여했고, TigerBeetle을 공동 창업해 마케팅을 이끌었으며, Oracle에서는 엔지니어링 매니저로 일했습니다. 그는 Software Internals Discord와 Software Internals Email Book Club을 운영하고, NYC Systems도 공동 운영하고 있습니다. @eatonphil
이 글이 마음에 드셨나요? 훌륭한 글을 계속 만들 수 있도록 돕고 무제한으로 읽으려면 Subscribe하세요.
실수를 발견하셨나요? 질문이나 의견이 있으신가요? the editor에게 연락해 주세요.
