Everything in its Right Place

2025년 회고

Tue, 20 Jan 2026 12:00:00 GMT

조금 늦게 남겨 보는 2025년 회고와 2026년.

2024년 회고와 동일하게 오픈소스, 컨퍼런스/세미나/멘토링, 블로그, 회사에 대한 회고를 작성했고, 이번에는 개인 항목까지 추가했다.

오픈소스

2025년 오픈소스 목표는 아래와 같았다.

오픈소스로 개발한 앱 구글 플레이스토어 출시
Chromium Feature 구현 및 배포 3회 이상

앱 개발과 출시는 올해도 실패. Chromium 기여는 OSSCA 멘토링 실습을 위한 확인 용도로 오타 수정 패치만 반영했다. 예전부터 개발해 보려고 노렸던 web feature 는 구글 쪽에서 진행하겠다고 해서 포기했다. 현재 회사 업무와 괴리가 점점 커지고 있어서 시간을 내기가 더 어려워진 것 같다.

연초부터 바이브 코딩이 유행하기 시작했고, 코딩 에이전트들이 빠르게 발전하면서 개발자들의 생산성이 급격하게 올라갔다. 자기계발과 개인 프로젝트에 대한 방향을 잡기가 어려웠다. 예전에는 다른 사람들과 함께 프로젝트를 해봐야겠다는 생각을 많이 했는데 이제는 토이 프로젝트를 남들과 할 생각을 아예 안하게 됐다. 대신 AI 도구를 적극적으로 활용해, 가능한 한 많은 프로덕트를 빠르게 완성하고 출시하는 것을 목표로 삼게 됐다. 옛날부터 프로젝트를 시작만 하고 끝을 못 내는 일이 비일비재했는데 올해는 꼭 프로젝트 완성이라는 목표를 달성하고 싶다. 도구를 잘 쓰기 위한 지속적인 훈련 목적도 있다.

컨퍼런스/세미나/멘토링

참석한 컨퍼런스/세미나

2025-05-29 Browser Night #1 발표 자료
2025-09-11 2025 OSSCA 멘토단 오픈라운지 NIGHT

2024년에 비해서는 컨퍼런스나 세미나를 거의 가지 않았다. 그나마 갔던 두 개는 모두 OSSCA 멘토링과 관련된 것이었다.

5월 말에 Browser Night 이라는 웹브라우저 개발자 밋업이 처음으로 열렸다. 마침 OSSCA 멘토링이 끝나는 시점이었어서 멘토링 후기 주제로 라이트닝톡 신청을 했다. 멘티들도 몇 명 같이 참석했다. 나름 발표 준비를 열심히 해갔는데 분량 조절 실패로 룰에 따라 5분이 되자마자 강판당했다. 우리나라에서 실력있는 웹브라우저 개발자들을 모두 만나 볼 수 있었던 뜻깊은 시간이었다.

9월에는 OSSCA 주최 측에서 멘토단 모임을 열어서 참석했다. 2025년 체험형, 참여형 멘토님들과 네트워킹 시간을 가졌다. 어색할 줄 알았지만 생각보다 많은 대화를 나누고 오픈소스와 AI에 대해 많은 인사이트를 얻을 수 있었다.

멘토링

위에서 여러번 언급했듯이 지난 4월부터 6주 동안 2025 오픈소스 컨트리뷰션 아카데미(OSSCA) 체험형 프로그램 멘토를 했다. 개인적으로 2025년의 가장 큰 이벤트였다. 자세한 후기는 블로그 글로 따로 남겼다.

봄에는 모교에서 교수님 요청으로 재학생 대상으로 오픈소스 기여와 커리어 성장이라는 주제로 간단히 발표를 했다. 재학생 졸업 프로젝트 멘토링도 작년에 이어서 하나 했다. 요즘에는 오픈소스를 통해 내가 성장했다는 말과 오픈소스 기여를 추천하는 것이 학생들에게는 별로 공감이 되지 않겠다는 생각도 든다. AI 시대가 되면서, 무엇을 어떻게 조언해야 할지 이전보다 더 고민이 많아졌다.

블로그

2025-01-04 2024년 회고
2025-12-31 2025 오픈소스 컨트리뷰션 아카데미 체험형 멘토 후기

2024년 회고 글과 멘토링 후기 글 하나를 남겼다. 회고를 제외하면 블로그에 남긴 글은 하나 뿐이었다. OSSCA 멘토 후기는 5월 말에 프로그램이 끝나자마자 썼었는데 이후에 마무리를 못하다가 2025년 마지막 날에서야 올렸다.

조회수는 작년보다 조금 늘었지만 여전히 적다.

조회수 순위

조회수와 검색어 순위는 작년과 큰 차이는 없다. 1년동안 정보성 글을 쓰지 않았다.

회사

10년이 넘게 회사를 다니면서 한 번도 해본 적이 없는 일을 했다. 굳이 따지자면 임베디드 소프트웨어 개발을 했다. 여전히 하드웨어 베이스의 선행 제품의 기획과 검토를 하고 PoC 제품을 만드는 일을 하고 있다. 이번에는 운이 좋게도 내가 메인으로 참여했던 프로젝트를 상품화 팀에 이관하는 걸로 결정됐다. 이 프로젝트를 하는 동안 새로운 경험도 많이 했다. 아주 높은 분들을 대상으로 하는 중요한 보고 자리에도 참석해 봤다. 사실 몇 년 뒤 이 프로젝트가 실제로 제품으로 출시가 될 수 있을지는 의문이다. 내가 한건 컨셉, 경험 PoC 를 한 수준인데, 실제로 상품화를 위해선 해야 될 일이 훨씬 더 많다. 실제 개발을 담당해야 하는 입장에서는 우리가 책임없는 쾌락을 즐겼다고 느낄 수도 있다. 죄송한 마음도 있지만 결국은 위에서 시켜서 했을 뿐이라는 자기 합리화를 하게 된다. 여러가지 한계가 있는 상황에서 나름대로 최선을 다 했다고 생각한다.

올해 역시 비슷한 고민과 어려움이 있을 것 같다. 작년과는 다른 프로젝트를 하고 있는데, 이번에도 임베디드 개발을 할 것 같고 AI 기능도 개발해야 되는 상황이다. 작년에 내가 어떤 걸 좋아하는지, 어떤 걸 힘들어하고 스트레스 받는지 조금 더 명확하게 알 수 있었다고 했었는데 1년 동안 그 생각이 좀 더 굳혀졌다. 올해도 쉽지 않을 것 같다.

개인

2025년의 가장 큰 성취, 풀코스 마라톤 완주. 연초에 신청을 해서 대회까지 10개월 가까운 시간이 있었지만 사실 준비를 제대로 하지 않았다. 풀코스를 1년 동안 준비하기 위해 봄에 10km, 하프 대회도 많이 신청했지만 다 안 갔다. 너무 큰 목표, 길고 긴 10개월의 시간 때문인지 더 게을러졌다. 대회가 다가올수록 풀코스라는 막연함과 두려움 때문에 오히려 더 뛰지 않게 됐다. 풀코스를 준비하는데 필수라는 30km LSD 훈련과 꾸준한 월 100-200km 마일리지 러닝은 하나도 하지 않았다. 2주 전에 하프마라톤 대회 하나 나가고 그 전, 후로 급하게 20km 몇 번 뛰어본 게 다였다.

대회 당일, 어떻게든 되겠지라는 근거없는 자신감으로 출발했다. 어쨌든 나중에 퍼질텐데 처음에는 최대한 오버페이스하고 후반부에는 페이스가 좀 떨어져도 어떻게든 서브4는 되지 않겠나? 라는 오만한 생각. 작전대로 뛰었지만 30km가 되자마자 귀신같이 햄스트링이 올라왔다. 훈련을 제대로 하지 않으면 30km에서 고비가 온다고 했는데 영상이나 글로 봤던 그대로였다. 이렇게나 정직하다고? 파스 뿌리고 에너지젤 먹으며 겨우겨우 버티다가 35km부터는 도저히 안되겠어서 아예 뛰지 못하고 걸었다. 나중에 계산해보니 1시간 넘게 걸었더라. 주변 사람들은 그렇게 걸은 것 치고 4시간 25분이면 엄청 잘 한거 아니냐고 말한다. 그것도 틀린 말은 아니다. 하지만 아쉽다. 처음부터 끝까지 걷지 않고 뛰고 싶어졌다. 걸으면서 다짐했다. 내년에 다시 도전한다.

2026년

2025년은 소프트웨어 업계에 큰 변화가 있었던 해였다. 지금까지 구글링과 스택오버플로우와 삽질로 쌓아온 나의 노하우는 LLM 앞에서 아무 것도 아니게 됐다. 내가 잘한다고 믿어왔던 것들이 더 이상 확실한 무기가 아니라는 생각이 들었다. 단순히 “내가 해봤다”, “내가 안다”는 말은 이전보다 설득력이 약해졌다. 그렇다고 그동안의 경험이 무의미해졌다고 생각하지는 않는다. 일을 할 때 이전과는 다른 방식으로 접근해야 한다.

나는 아직 AI 도구를 충분히 활용하지 못하고 있다. 의식적인 훈련을 해서 나만의 스킬로 만들어야 한다. 현재 회사에서 쓸 수 있는 툴은 한정적이고 사내에서 개발한 AI 서비스 밖에 사용할 수 없다. 하지만 주어진 한계에 머물지 않고, 외부 도구에 대한 학습과 실험을 병행하려 한다. 의미 있는 결과를 만들어보고 싶다.

추가로 AI 에 대한 관심과 공부, 직접적인 활용을 좀 더 적극적으로 하려고 한다. 회사에서 다 막아 놓아서 사용할 수 있는 도구가 거의 없지만 그 핑계로 아무 것도 안 할 수는 없다. 뒤쳐지면 안 된다.

잊고 있었는데 1년 전 회고에서도 비슷한 얘기를 했었다. 1년 사이에 생각한 것보다 훨씬 더 큰 변화가 있었다. 실천하는 것이 중요하다마음을 단단히 먹자.

2025 오픈소스 컨트리뷰션 아카데미 체험형 멘토 후기

Wed, 31 Dec 2025 14:30:00 GMT

올해 봄, 6주 동안 오픈소스 컨트리뷰션 아카데미 체험형 프로그램 git 활용 및 Chromium 프로젝트의 멘토링을 했다. 2025년 마지막 날이 되어서야 멘토링 과정과 후기를 남긴다.

시작

지난 4월 중순부터 5월 말까지 6주 동안 오픈소스 컨트리뷰션 아카데미 체험형 멘토를 했다. 2월 초에 오픈 프런티어 기여형 프로그램으로 연을 맺게 된 오픈업 담당자 분이 내 블로그에서 멘토링도 한 번 해보고 싶다는 내용을 보셨다면서… 멘토를 제안해 주셨다. OSSCA 체험형 프로그램은 총 6주동안 진행하는데, 그 중 2주는 git 과 GitHub, 나머지 4주는 프로젝트 내용으로 멘토링 프로그램을 진행한다고 들었다. Chromium 과 같은 대형 프로젝트로 그 짧은 기간에 멘토링을 하는게 가능한지 의문이 들었지만 크게 고민하지 않고 하기로 결정했다. 어쨌든 13주 이상 진행하고 최종 보고회까지 있는 참여형 프로그램보다는 부담이 덜할 것 같았다.

멘토링을 하게 된 첫번째 이유는 멘토링을 하면 나도 Chromium 을 더 관심있게 보고 다시 기여를 열심히 하지 않을까라는 막연한 기대 때문이었다. 그 다음은 현재 하고 있는 일에 대한 아쉬움을 해소하고 싶은 이유가 컸다. 작년에 옮긴 부서에서는 하드웨어 기반의 PoC 제품의 소프트웨어를 적은 인원이 개발하고 있는데, 그러다 보니 일하는 방식이나 업무의 깊이에 대한 아쉬움이 많았다. 보통은 연차가 쌓일수록 다른 사람들을 리딩하거나 협업할 일이 많이 생기는데 지금까지 그런 기회도 거의 없었어서 관련된 역량도 키우고 싶었다. 나는 오픈소스를 늦게 시작한 것을 아쉽다고 느꼈기 때문에 주변의 주니어 개발자들이 조금이라도 더 빨리 시작할 수 있게 도움을 주고 싶었다. AI 시대에 취업도 어렵고, 예전과는 다른 목표와 방식으로 일을 하는 것이 중요하게 바뀌고 있는 시점에 이 멘토링 프로그램이 얼마나 효용이 있는지 의문이 들긴 했지만 조금이라도 도움이 되길 바라며 준비를 시작했다.

멘티 선발

4월 초부터 멘티들의 지원을 받았다. 주최에서 제공한 템플릿에 맞춰 프로젝트 소개 페이지를 직접 만들었다. 2025년 1차 체험형 프로그램의 프로젝트는 10개였고, 지원자들은 각 프로젝트 소개 페이지를 보고 자기소개, 지원동기, 개발경험 등을 작성해서 2지망까지 지원할 수 있었다.

각 프로젝트의 멘토가 지원서 내용을 토대로 직접 멘티를 선발했다. 25~30명 선발로 가이드를 받았는데 그보다는 적은 인원이 1지망으로 Chromium 프로젝트를 지원했다. 멘토 입장에서는 20명 이상은 좀 많다고 생각이 들었지만 그래도 최대한 기회를 주고 싶어서 많은 인원을 뽑으려고 했다. 지원서 내용이 조금 성의없다고 느낀 분들을 빼고 2지망 분들을 추가해서 뽑았다. 1지망 지원서를 대충 쓴 사람보다는 2지망이라도 열심히 쓴 사람을 뽑고 싶었다. 당연히 2지망에서 뽑은 분들은 1지망 지원서도 열심히 썼을 것이기 때문에 (2지망으로 쓴 분들이 1지망을 어디에, 어떤 내용으로 썼는지는 알 수 없었다.) 대부분 1지망 프로그램으로 뽑혀가고 1명만 우리 쪽으로 배정이 되었다.

최종 선발 된 멘티는 22명이었다. 발대식 전에 1명이 불참 의사를 밝혀서 발대식 기준 21명으로 시작하였고 그 중 1명을 제외한 20명이 1회 이상 모임에 참여했다.

준비와 발대식

지금껏 오픈소스 컨트리뷰션 아카데미나 다른 프로그램으로 멘토링을 해보거나 받아본 경험이 없었다. 어느 정도 커리큘럼과 기본적인 구성안을 만들었지만 실제로 어떻게 진행해야 할지 막막했다. 그래서 미리 모든 걸 준비하긴 어려웠고, 프로그램을 진행하면서 멘티들의 상황이나 목표에 맞추기로 했다. 최대한 많은 인원을 끝까지 끌고 가고 싶었다. 멘티 선발 후 발대식 전에 사전 설문조사를 했다. 이 부분은 정말 잘한 일이라고 생각한다. 지원서를 통해 이미 어느 정도 정보를 알 수 있었지만 프로젝트 관련 설문을 추가로 받아서 멘티들을 조금 더 깊이 이해할 수 있었다. 내용을 여러번 확인하면서 멘티들의 얼굴과 이름도 금방 익힐 수 있었다. 이전에 다른 프로젝트로 오픈소스 컨트리뷰션 아카데미에 참여한 분들에게도 좋았던 점과 아쉬웠던 점 작성을 요청했다. 경험자는 3~4명 정도 있었는데 공통으로 아쉽게 느꼈던 점이 너무 어려워서 포기하는 분들이 많았고 끝가지 남아있던 분들이 소수였다는 점이었다. 나는 이 부분을 고려해서 최대한 많은 인원을 끝까지 끌고 가는 걸로 방향을 잡았다.

4월 중순 평일 저녁에 프로젝트별로 발대식을 진행했다. 선발된 멘티 21명 중 15명이 참석했다. 먼저 주최 측에서 전체 프로그램 소개와 공지를 하고 이후에 각 강의실에서 어색하게 피자를 먹으며 오리엔테이션을 했다. 사전 설문조사 내용과 앞으로 진행할 내용을 공유하고 모임 시간을 정했다. 멘토 포함 16명 중 MBTI E 성향이 한 명 밖에 없어 어색한 자리였다. 그래도 멘토 입장이니 억텐으로 열심히 진행을 했다. 뒤돌아 봤을때 발대식에 참여한 분들은 대부분 수료를 했다. 오리엔테이션이 별 일 아닐 수도 있지만 가볍게 인사하고 목표를 공유하는 자리에 참석하는 것이 프로그램에 참여하는 태도에 꽤 큰 영향을 미친다고 생각한다.

모임 진행 방식

6주 동안 매주 오프라인 1회, 온라인 1회 모임을 진행했다. 오프라인 모임을 기본으로 하고, 멀리 살아 매주 올라오기 힘든 분들과 불참자 대상으로 온라인 보강을 했다. 오프라인 모임은 매주 일요일과 토요일을 번갈아가면서 일-토-일-토-일-토 모임을 가졌다. 그 다음주 목요일 저녁에 온라인 모임 진행을 했다. 매주 오프라인 모임에는 10-12명, 온라인 모임에는 5-7명 정도가 참여했다.

모임 내용

모임은 강의식으로 진행했다. 강의만 하면 이해하기 어렵고 지루하기 때문에 중간에 간단한 실습도 진행했다. 멘티들은 대부분 코로나 시대에 학교를 다녔기 때문에 비대면 강의에 익숙한 세대인데 나 같은 경우는 그게 아니어서 강의하는 입장에서 조금 어색했다. 영상은 나만 켰었고 멘티들은 음성보다는 채팅으로 질문을 했다.

1주차: 오픈소스 프로젝트 기여 / git & GitHub #1 / 오픈소스 프로젝트 둘러보기
2주차: Chromium 개발 프로세스 개요 / git & GitHub #2
3주차: Chromium 문서 수정 기여 실습
4주차: Chromium 문서 수정 기여 실습 보충 / Chromium 이슈 둘러보기 / WebIDL
5주차: Chromium 폴더 및 구조 둘러보기 / Chromium Feature 둘러보기 실습
6주차: Chromium Feature 둘러보기 (개발자 도구, Extensions) / 과정 마무리

1, 2주차

1, 2주차에는 체험형 취지에 따라 git 과 GitHub 와 같은 협업 도구에 대한 멘토링이 필수였다. git 과 GitHub 는 너무 기본적인 내용보다는 내가 일하면서 많이 쓰는 명령어나 개발 프로세스 전략을 공유했다. 회사를 다니는 분들도 있고 부트캠프 등을 통해 프로젝트를 많이 경험해 본 분들도 있었기 때문에 어려웠던 부분이나 나의 경험 위주로 전달했다. 물론 기본적인 내용이 익숙하지 않은 분들도 있었는데 주최 측에서 git 강의를 따로 유튜브에 업로드하여 멘티들에게 제공을 했기 때문에 기본 강의는 유튜브 강의를 참고하게 했다.

협업 도구에 대한 기본적인 내용 외에 오픈소스 프로젝트 기여 활동에 대한 전반적인 내용도 같이 공유했다.

오픈소스 활동의 의미, 기여 동기와 얻을 수 있는 가치 공유
오픈소스 참여 방법과 프로젝트 탐색법 학습
Git 기본 명령어, 브랜치 전략, alias 설정 등 실습
GitHub를 통한 협업 방식, PR 전략, Trunk-based Development 소개
개인 dotfiles 및 alias 활용법 공유
오픈소스 개발 프로세스 전체 흐름 소개 (이슈 → 리뷰 → 머지 → 배포)
Chromium 기여 흐름 및 Google Issue Tracker, Gerrit 리뷰 시스템 소개
Blink, Web Platform, WebIDL 등 주요 기술 요소 및 구조 개요
웹 표준 문서화 과정 및 Web Platform Test 소개
GitHub 프로젝트 관리, CI/CD, 문서 구성 방식 학습

3주차

3주차부터는 Chromium 기여에 대해 본격적인 멘토링을 해야 했다. 발표 자료와 강의, 데모로 아무리 보여줘도 직접 해보지 않으면 이해가 되지 않는 부분이 많기 때문에 직접 해보는 시간이 필요하다고 생각했다. 특히 Chromium 은 gerrit 과 구글의 issue tracker 를 사용하는데 대부분 처음 사용해 보기 때문에 멘토의 일방적인 설명만으로는 이해하기가 더 어렵다.

실습을 어떻게 해야할지 고민을 많이 했는데 결국 오픈소스에 가장 쉽고 빠르게 기여 할 수 있는 방법 중 하나인 문서 수정을 하기로 결정했다. docs 마크다운 문서의 깨진 링크를 수정하는 실습을 진행했다. 실습 전에 내가 직접 + ChatGPT 으로 만든 스크립트로 깨진 링크들을 찾아놓았다. 미리 준비한 이슈를 바탕으로 각 멘티들이 모임 시간 안에 패치를 업로드하는 걸 목표로 진행했다. 모임 시간 안에 끝내지 않으면 흐지부지 될 가능성이 높다. 별도의 자체 GitHub 에 각 깨진 링크에 대한 이슈를 만들어 놓고 멘티들이 셀프 할당하여 컨트리뷰션을 진행했다. Chromium 이슈를 직접 사용하는 건 시간이 더 걸리고 복잡해질 수 있기 때문에 별도의 GitHub 프로젝트를 활용하여 코드 반영 과정을 정리하고 GitHub Pages 로 볼 수 있도록 프로세스를 만들었다.

실습 목표

Chromium 프로젝트 코드 히스토리 파악
패치 업로드
리뷰어 찾기
리뷰 받기
자체 GitHub 프로젝트의 프로세스에 따라 반영 내용 정리하기

실제로 17명이 컨트리뷰션 실습 참여를 했고 대부분 반영까지 완료했다. 리뷰 받는 중에 발생한 문제들은 이후에도 중간중간 정리해서 공유했다. 나도 몰랐던 정책을 알게 된 부분도 있었다. Committer 의 권한이 알고 있던 것보다 좀 더 있다는 것도 알게 됐다. 그래서 다행히 멘티들이 패치를 빠르게 반영하는데 도움을 줄 수 있었다.

4주차

3주차 실습을 하면서 생긴 이슈를 공유했다. 일주일 사이 절반은 반영까지 완료했고 나머지는 리뷰 중이거나 수정 요청을 받은 경우가 있었다. 그 다음에는 본격적으로 기술적인 컨트리뷰션을 하고 싶은 분들을 위해 Chromium 에서 기여할만한 이슈를 찾는 방법을 알려주었다.

나머지 시간에는 웹 브라우저 엔진의 기본인 Web IDL(Interface Definition Language) 기반으로 blink 에서 어떻게 코드를 작성하고 테스트를 하는지 샘플 코드와 실제 코드를 사용하여 설명하는 시간을 가졌다.

5주차

5주차에도 간단한 실습을 진행했다. Chromium 프로젝트의 각 폴더와 구조를 먼저 설명하고 이후에 멘티들이 components 의 각 모듈에 대해 빌드 종속성, DEPS 파일 기반으로 구조가 어떤지 찾아보는 실습을 했다. 자체 GitHub 에 각 멘티가 이슈를 만들고 리포트하는 형태로 진행했다.

6주차

마지막 날이었기 때문에 가볍게 진행했다. 더 배우고 싶은 주제에 대해 미리 설문을 받았다. 개발자 도구, Extensions 등 프론트엔드 개발자들에게 조금 더 호기심이 생길만한 주제로 프로젝트를 한번 둘러보는 시간을 가졌다. 마지막 모임이 끝나고 근처에서 뒷풀이 회식을 하면서 마무리했다.

마무리

프로그램 참여도에 따라 수료자를 선정하여 전달했다. 자체적으로 매주 설문조사를 통해 익명으로 피드백을 받았었는데 응답률이 낮았다. 마지막날 뒷풀이 때 물어봤더니 내요이 너무 많아서 안 썼다는 분이 있었다. 어느 정도 납득이 됐다. 그리고 내가 받은 피드백과 주최 측에서 받은 피드백이 다를 수 있기 때문에 담당자 분께 따로 요청드려서 내용을 받았다.

멘티분들의 피드백을 보시면, 전반적으로 멘토님의 친절한 지도와 실무적인 경험 제공에 대해 만족도가 매우 높았고, 덕분에 대형 오픈소스 기여에 대한 자신감을 얻었다는 응답이 많았습니다. 아쉬운 점으로는 체험형-참여형 연계 부족과 프로그램 기간이 주로 언급되었습니다.

5월에 체험형 프로그램이 끝나고 7월부터 참여형 프로그램이 진행될 예정이었어서 참여형까지 이어서 하길 기대한 멘티들이 많았던 것 같다. 나도 체험형을 준비하면서 참여형을 같이 진행하면 좋겠다는 생각을 했었는데 체험형-참여형 프로그램의 리드 멘토를 이어서 할 수 없다는 정책이 있어서 참여형 멘토 지원을 포기했다. 참여형에는 Chromium 프로젝트가 없었고 멘티들에게 이 부분을 미리 밝혀서 그런지 몇몇 분들이 피드백에 연계에 대한 아쉬움을 남긴 것 같다.

프로그램이 끝나자마자 BrowserUs 의 Browser Night #1 행사에서 라이트닝 토크로 후기를 발표할 기회가 생겼다. 라이트닝 토크인만큼 5분 안에 발표를 끝 마쳐야 했는데 시간이 부족해 준비한 내용을 다 말하지 못하고 내려와야 했다.

발표 자료 를 만들면서 정리했던 KPT 회고를 남기며 2025년 오픈소스 컨트리뷰션 아카데미 체험형 멘토 후기 글을 마친다.

KPT 회고

Keep

사전 설문조사와 모임 후 피드백 수집
- 아주 내성적인 멘티 분들을 사전에 이해하고 커뮤니케이션하는데 큰 도움이 되었음
경험 위주 전파
나만의 방식을 고민하고 적용
- Chromium 마크다운 + GitHub 연계 실습
- 어디에서도 볼 수 없는… (positive)

Problem

강의 내용과 설명의 디테일/깊이 부족
- 세이브 원고(?) 소진 후 매주 급급한 준비
- 어디에서도 볼 수 없는… (negative)
피드백을 제대로 반영 못한 느낌 (피드백 시스템의 한계?)
온라인 강의의 어려움을 극복하지 못함
- 이미 오프라인에서 진행한 내용인데 정신이 더 없었다.
체험형이라는 것과 6주라는 기간에 스스로 한계를 두지 않았나…
- 좀 더 빡세게 했어야 했나? (2차 기여 기회, 숙제나 스터디 등)

Try

좋은 멘토/개발자가 되기 위해서는 훈련이 더 필요하다
느슨해진 오픈소스 컨트리뷰션과 자기계발에 다시 긴장감을 가지자
내년 오픈소스 컨트리뷰션 아카데미 참여형 멘토 도전?
- (업무로 웹브라우저 개발을 다시 하게 된다면…)

2024년 회고

Sat, 04 Jan 2025 05:40:00 GMT

오픈소스

2024년의 오픈소스 목표는 세 개였다.

Chromium 기여를 좀 더 해서 Committer 가 되는 것
Chromium 외 다른 오픈소스 프로젝트에 꾸준히 기여하는 것
내 프로젝트를 오픈소스 프로젝트 형식으로 개발하여 구글 플레이스토어에 출시하는 것

3월에 Chromium Committer 로 선정되면서 1번 목표를 달성했다. 자세한 후기는 블로그 글 로 남겼다. 커미터가 된 후에는 컨트리뷰션을 거의 하지 않았다. 내가 앞으로도 열심히 할 것 같다고 리뷰어가 커미터로 추천을 해줬는데 미안하게 됐다. (올해는 제대로 해볼게…) 한 해동안 반영한 패치는 달랑 두 개. 그 중 하나는 1년 전에 작업이 다 끝났는데 스펙이 정리가 안 돼서 반영을 못했던 것이었다. 1년이 지나서야 정리가 돼서 rebase 를 하고 반영했다. 그 사이에 내가 만들어 놓은 WPT 테스트를 파이어폭스 쪽에서 먼저 그대로 반영해버렸다. 괜히 아쉽다.

2, 3번은 역시나 실패했다. 플레이스토어에 앱을 올려보려고 연초에 조금 끄적거리다가 말았다. 10년 넘게 매번 시작만 하고 완성을 못하고 있다. 작게라도 완성하는 습관을 들이는게 목표이다.

2년 째 오픈 프런티어 기여형 프로그램에 참여하면서 어느 정도 강제적으로 오픈소스 활동을 했었다. 2025년에는 기여형 프로그램이 없어지고 멘토형 프로그램만 남는다고 들었다. 멘토링도 관심은 있지만 Chromium 프로젝트로 멘토링을 하기에는 아직 많이 부족하다고 생각한다. 나중에 다시 업무로 웹브라우저를 하게 되면 도전해볼 생각이다.

2025년 오픈소스 목표

오픈소스로 개발한 앱 구글 플레이스토어 출시
Chromium Feature 구현 및 배포 3회 이상

앱 출시는 올해 우선순위가 가장 높은 목표이다. 앱의 퀄리티도 중요하지만 간단한 앱으로 과정과 데이터를 보는 것에 집중해보려고 한다.

올해도 Chromium 프로젝트에 기여 할 생각이다. 커미터 달고 먹튀한 느낌도 있어서 의무감에 하려는 목적도 있다. 언젠가 웹브라우저를 업무로 다시 할 수도 있고… 어쨌든 오픈소스 기여는 꾸준함이 생명이기 때문에 놓지 않는 것이 중요하다. 쉬면 다시 시작하기 어렵다.

항상 연초에만 매일 하다가… 흐지부지

컨퍼런스/세미나/멘토링

참석한 컨퍼런스/세미나

2024-07-20 I/O Extended Android in Korea 2024 후기
2024-07-27 I/O Extended 2024 Incheon 후기
2024-10-12 DEVCON 2024
2024-11-16 Open Source Conference (오쏘콘) 발표 후기
2024-12-11 솔로프리너 컨퍼런스: 1인 개발자, 인디해커의 삶
2024-12-21 au VimEnter * call Bye2024()

코로나 이후로 컨퍼런스를 전혀 가지 않다가 2024년에는 6개에 다녀왔다. 오쏘콘에서 발표도 했다. 재미있었던 건 VimEnter, 인상 깊었던 건 솔로프리너 컨퍼런스였다. 두 개는 후기를 따로 남기지 못했다. 컨퍼런스 후기 쓰는 건 왜 이리 귀찮은지. GDG I/O Extended 나 데브콘은 실제로 적용할 수 있거나 지식적으로 큰 도움이 되는 세션이 많진 않았지만 (보통 나의 업무와 핏되는 내용이 잘 없음) 에너지를 얻고 동기 부여를 받는데 도움이 됐다.

2025년에도 컨퍼런스를 많이 다닐지는 모르겠다. 오쏘콘이 이번에 처음 열렸는데 2025년에 또 열리면 참석할지도.(발표는 안 할 듯..) VimEnter 는 앞으로 매년 가고 싶다.

멘토링

모교 졸업 프로젝트 두 팀을 멘토링했다. A팀 3회, B팀 2회 zoom 으로 진행했으며 B팀은 아직 프로젝트 진행 중이라 1학기에 또 진행할 예정이다. 솔직히 형식적인 목적이 더 크고 멘토와 멘티 간 주제 매칭이 100% 가 되기 어려워서 기술적인 조언을 주기에 한계가 있다. 그렇다면 다른 도움이라도 되면 좋을텐데 세대 차이도 너무 나고 이제는 졸업한지 너무 오래돼서 취업 관련 조언을 주기도 어렵다. 서로에 대한 이해가 없는 것이나 다름 없어서 더 어렵기도 하다. A팀 멘토링을 할 때는 한 번 자료를 만들어서 내 커리어 소개를 하기도 했다. (별 반응은 없었지만…) 이런 형식적인 멘토링에 한계를 느껴서 아예 강연을 하는게 나을 것 같다는 생각도 했다. 어쨌든 멘토링을 하는 건 조심스러운 부분도 있지만 내 입장에서는 나를 돌아보고 정리하는데 도움이 된다. 회사에서도 가끔 중고등학생이나 대학생 대상으로 진행하는 멘토링 프로그램의 멘토 신청을 받는데 나중에 한 번 지원해 볼 생각이다.

블로그

2024-01-02 2023년 회고 그리고 2024년
2024-05-26 Chromium Committer 가 되었다
2024-10-06 2024 GDG Google I/O Extended 간단 후기
2024-11-25 오쏘콘(Open Source Conference) 발표 후기
2024-11-30 Chromium Faster Build 방법

2024년에는 5개의 글을 올렸다. Chromium Committer 가 된 과정과 오쏘콘 발표 후기를 꽤 공을 들여서 썼다. 꽤 오랫동안 오픈소스 활동을 해서 결국 하나의 마일스톤을 찍고, 발표까지 한 건 나름대로 큰 성과였다. 그리고 블로그에 글까지 남기다니… 내 자신 많이 발전했다.

조회수는 여전히 소소하다. 인기가 있는 주제의 글도 딱히 없고 글 수도 적다. 앞으로 양질의 글을 꾸준히 올리고 싶다. 간단히 공부한 내용이나 튜토리얼 성격의 글은 티스토리 같은 별도의 블로그에 올리고 이 쪽에는 좀 더 퀄리티 있는 글을 올려서 보정을 할 생각이다.

조회수 순위

검색어 유입은 여전히 aosp 빌드와 cuttlefish 가 대부분이다. 검색이 잘 될 만한 글을 올려서 테스트해보고 싶은데 어떤 글을 올려야 될지 모르겠다. 검색어나 유입 경로에 대한 데이터는 궁금해서 한 번씩 보게 된다. 한 달 전에 awesome-devlog 에 블로그를 등록해 놓았는데 이를 통한 유입이 어느 정도 있을지도 궁금하다. (등록 후 이 글이 첫 번째) 조회수는 높으면 좋겠는데 지인은 딱히 안 봤으면 좋겠다. ㅎㅎ

회사

새로운 업무를 하면서 앞으로의 커리어에 대한 고민과 의문이 더 커졌다. 개발을 하면서 소프트웨어 엔지니어링을 같이 고려하는 걸 좋아하는데 그런게 전혀 필요없는, 단기적인 결과만 있으면 되는 휘발성 업무, 프로젝트가 많았다. 커리어 측면에서 남는 게 별로 없었다. 다른 방식으로 일을 하면서 배운 것도 당연히 있지만 이 업무를 오래 하는게 과연 장기적으로 도움이 되는 것인지 의문이 생겼다. 대신 내가 어떤 걸 좋아하는지, 어떤 걸 힘들어하고 스트레스 받는지 조금 더 명확하게 알 수 있었다.

2025년

2024년의 목표는 Pay Off 였다. 밀린 부채를 갚는 것. 만족스럽지는 않지만 절반은 성공했다고 생각한다. 예전부터 되고 싶었던 Chromium Committer 가 됐고 회사 컨퍼런스가 아닌 자의로 처음 컨퍼런스 발표를 했다. 못 갚은 부채는 아직도 많다.

요즘 느끼는 건 결국은 꾸준함이 중요하다는 것이다. 이제는 꾸준하게 쌓은 누적 스탯으로 커리어를 이어나가야 할 때이다. 그런데 나는 커리어를 시작한 지 10년이 넘은 지금도 방향을 못 잡고 방황 중인 것만 같다. 그동안 쌓은 누적 스탯을 폭발시키기 위해 방향을 다시 잡고 루틴을 만들고 프로세스를 만들어 시스템화해야 한다. 최근 느낀 나의 문제는 목표가 없고 정리가 되어있지 않으면 아무 것도 안한다는 것이다. 꾸준히 정리하고 개선하기 위한 의식적인 훈련이 필요하다. 목표를 세우고 쳇바퀴를 만들자. 직접 구르면서 목표를 달성하자.

추가로 AI 에 대한 관심과 공부, 직접적인 활용을 좀 더 적극적으로 하려고 한다. 회사에서 다 막아 놓아서 사용할 수 있는 도구가 거의 없지만 그 핑계로 아무 것도 안 할 수는 없다. 뒤쳐지면 안 된다.

Chromium Faster Build 방법

Sat, 30 Nov 2024 12:00:00 GMT

Chromium 의 빠른 빌드를 위한 환경 셋업 방법을 정리해 보았다.

Chromium 빌드는 굉장히 오래 걸린다. 2018년에 맞춘 아래 사양의 데스크톱 PC 기준으로 chrome 빌드와 blink 를 위한 기본적인 유닛테스트 빌드를 하면 4시간이 넘게 걸린다. 2018년에는 1~2시간 정도 걸렸던 것 같은데 지금은 거의 2배 이상 차이가 난다.

AMD 라이젠 7 피나클릿지 2700X (8 core / 16 thread)
32GB RAM

https://commondatastorage.googleapis.com/chromium-browser-clang/build-time.html

Chromium 팀에서 측정 중인 Chromium Build Time 그래프에서 2018년과 2024년을 비교해도 거의 3배 차이가 난다.

Chromium 빌드 가이드에는 빌드를 빨리 할 수 있는 방법을 여러가지 제공하고 있다.

먼저 구글 개발자를 위한 별도의 가이드가 있다. 내부 리모트 서버를 사용하는 방법이 있는 것 같은데 외부 개발자는 가이드조차 볼 수 없어서 실제로 어떻게 사용하는지, 얼마나 빨라지는지 알 수 없다. 대신 외부 개발자를 위한 Faster builds 가이드가 따로 있다. Reclient 권한을 받으면 리모트 캐시 빌드를 할 수 있다. 가이드 상으로 tryjob access 가 있는 개발자라면 별도의 신청으로 권한을 얻을 수 있다. 하지만 내가 권한 요청을 했을 때는 committer 인지 확인을 했다. 구글에서 비용을 쓰는 것이다보니 아무나 해주는 것 같진 않았다. 다행히 committer 가 된 후에 신청을 했기 때문에 받아주었다.

리모트 빌드는 Bazel 의 remote-apis 기반으로 reclient 를 클라이언트로 사용한다. 백엔드는 구글내 클라우드 서버에서 돌고 있는데 가이드에는 RBE 라고만 되어있고 별다른 설명은 없다. 직접 remote-apis 서버를 구축해서 사용할 수도 있다고 한다. 업무로 chromium 프로젝트를 한다면 한 번 깊게 알아볼 것 같다.

빌드 방법

먼저 구글 클라우드 계정 등록이 필요하다.

gcloud CLI 설치
gcloud 로그인 실행

$ gcloud auth login --update-adc

생성된 링크를 웹브라우저로 복사, verification code 복사
Enter authorization code 에 복사한 verification code 붙여넣기
chromium/.gclient 파일 수정 - custom_vars 내 "rbe_instance": "projects/rbe-chromium-untrusted/instances/default_instance", 추가

solutions = [
  {
    "name": "src",
    "url": "https://chromium.googlesource.com/chromium/src.git",
    "managed": False,
    "custom_deps": {},
    "custom_vars": {
      # This is the correct instance name for using Chromium's RBE service.
      # You can only use it if you were granted access to it. If you use your
      # own REAPI-compatible backend, you will need to change this accordingly
      # to its requirements.
      "rbe_instance": "projects/rbe-chromium-untrusted/instances/default_instance",
    },
  },
]

gclient sync 실행

$ gclient sync

out/Debug/args.gn 에 내용 추가

use_remoteexec = true
reclient_cfg_dir = "../../buildtools/reclient_cfgs/linux"

빌드 실행

$ gn gen out/Debug
$ autoninja -C out/Debug chrome blink_tests blink_unittests blink_platform_unittests

빌드는 스크린샷에서는 2시간 정도 걸리고 8번 명령어 기준으로는 1시간 조금 넘게 걸린다. 평소 로컬 빌드를 했을 때 4시간 이상 걸리는 것과 비교하면 꽤 빠르다. 다른 프로젝트에 비하면 1시간도 빠르다고 볼 수는 없지만 요즘 로컬 빌드 속도에 비하면 꽤 만족스러운 속도이다.

빌드를 빠르게 할 수 있는 기타 방법

리모트 캐시 빌드를 사용할 수 없는 경우, 빌드 옵션을 조정하여 빌드 속도를 빠르게 할 수 있다. 리모트 캐시 서버를 사용하는만큼 빨라지지는 않지만 조금은 시간을 줄일 수 있다.

symbol_level 조정 : level 을 낮출수록 빌드 속도가 빨라진다.

symbol_level=2 full debug info
symbol_level=1 stack traces, not line-by-line debugging
symbol_level=0 no debug symbol다

blink, v8 symbol_level 조정 : blink, v8 debug 정보가 불필요한 경우 0으로 낮출 수 있다.

blink_symbol_level=0
v8_symbol_level=0

ccache 사용 (reclient 사용하는 경우 큰 효과 없음)

https://chromium.googlesource.com/chromium/src/+/main/docs/linux/build_instructions.md#ccache 참고

지금은 reclient 를 사용하고 있기 때문에 위 방법은 따로 사용하고 있지 않다.

오쏘콘(Open Source Conference) 발표 후기

Sun, 24 Nov 2024 15:00:00 GMT

11월 16일 토요일 Open Source Conference(오픈소스 컨퍼런스, 줄여서 오쏘콘) 에서 ‘오픈소스 웹 브라우저 개발자는 이렇게 일한다’ 라는 주제로 발표를 했다.

오쏘콘은 올해 처음으로 열린 커뮤니티 기반의 오픈소스 개발자 컨퍼런스이다. 주최는 GDG(Google Developers Group) 송도.

발표 제안

섭외는 지난 8월 일본에서 이뤄졌다. 음악 좋아하는 개발자들과 함께 일본 섬머소닉 페스티벌을 다녀왔다. 페스티벌 마지막 날, 뒷풀이까지 하고 숙소로 또 돌아와서 새벽까지 술을 먹다가 GDG Organizer 한 분이 새로운 오픈소스 컨퍼런스를 기획 중이라고 했고, 얘기를 듣자마자 바로 발표를 하겠다고 했다.(새벽 3~4시쯤..) 올해 몇 년 만에 커뮤니티 기반의 개발자 컨퍼런스를 다녀보면서 나도 발표를 한번 해보면 좋을 것 같다고 생각했고, 생각해 놓은 주제도 몇 개 있어서 바로 하겠다고 했다.

귀국하고 정식으로 다시 연락을 주셨다. 막상 하려니 부담이 돼서 시간을 달라고 했다가 그냥 해야겠다는 생각에 10분 만에 다시 한다고 말씀드렸다.

주제 선정

지금까지 개발자 컨퍼런스에서 발표한 경험은 딱 한 번, 회사 컨퍼런스여서 내가 하고 싶은 얘기보다는 부서를 대표하는 내용의 발표를 했다.(나보다는 리더급이 하는게 더 맞는 내용) 발표 자료도 보안이나 저작권을 신경 쓰면서 만들어야 해서 제약이 많았다. 발표 시간도 20~25분이라 보통의 컨퍼런스보다는 짧은 시간이었다. 준비를 열심히 했는데 청중이 생각보다 적어서 살짝 아쉬웠다.

그 아쉬움 때문인지 커뮤니티 기반의 젊고 열정 있는 분위기의 컨퍼런스에서 내가 하고 싶은 발표를 한 번쯤 해보고 싶었다. 내 얘기를 주로 해야 하는 것이 조금 부담이 되지만 그래도 좋은 경험이 될 것 같았다.

발표 제안을 받기 전부터 생각했던 내용은 구글 엔지니어는 이렇게 일한다 라는 책을 구글의 오픈소스 프로젝트인 Chromium 버전으로 푸는 것이었다. Chromium 이나 AOSP 에 기여를 해보면서 경험한 걸 책과 비교해서 설명하면 재밌을 거라 생각했다.

주최 측의 컨퍼런스 발표 주제 방향

오픈소스 기여자들이 세상을 직접 바꿔 가는 이야기
오픈소스, 현대 문명의 바퀴를 만들어가는 기여자들의 이야기

내가 오픈소스로 대단한 일을 하고 있다고 생각하지는 않아서 전달받은 문장이 살짝 부담되긴 했지만, 발표 주제와 함께 나의 고민과 고충과, 좋았던 점, 아쉬웠던 점은 꼭 공유해야겠다고 생각했다.

준비하면서 이루고자 했던 것

‘구글 엔지니어는 이렇게 일한다’ 책 읽기 (나오자마자 샀었는데 그동안 제대로 읽은 적이 없었음)
기능 구현을 하면서 Chromium 개발 프로세스를 처음부터 끝까지 직접 경험해보기

3개월 정도 시간이 있었기 때문에 발표를 준비하면서 그동안 같이 해보고 싶었다.

발표 준비

막상 준비를 해보니 쉽지 않았다. 목표와 계획을 너무 크게 잡았다. 책 읽는 것과 기능 구현 모두 크게 부담이 됐다. 책 한 권을 읽는 것도 귀찮았고, Feature 하나를 처음부터 개발하고 문서까지 쓰고 할 생각을 하니 막막했다. 어떤 기능을 해볼지는 예전부터 생각해 두었는데 시작이 어려웠다.

발표까지 한 달이 조금 넘게 남은 시기에 컨퍼런스 공지와 티켓이 열렸는데 그때도 준비한 게 거의 없었던 걸로 기억한다. 일단 아는 사람이 오면 조금 더 발표 준비를 열심히 할 수 있을 것 같아서 회사 주변 분들께 초대권을 드렸다. 일주일도 안 돼서 120개 정도의 티켓이 매진됐다. 슬슬 부담되기 시작했다.

이번 컨퍼런스의 환경과 조건을 생각해봤다.

하나의 트랙으로만 진행이 된다.
청중은 여러 개의 세션 중에 특별히 내 발표를 선택해서 듣는 것이 아니라 그대로 쭉 앉아 있는 것이다.

발표 대상도 다시 한번 생각해 봤다.

학생이나 주니어 개발자 비율이 높을 것 같았다.
오픈소스에는 관심이 있지만 Chromium 은 모르거나 크게 관심이 없을 것이다.
웹 브라우저 코드나 C++은 아예 모를 수 있다.
웹 브라우저 기술 지식보다는 오픈소스에 대한 경험을 듣고 싶어서 왔을 것이다.

올해 컨퍼런스를 다시 다니면서 느낀 건 가볍게 들으러 오거나 주제를 잘 모르는 경우, 깊게 얘기할수록 집중력이 떨어질 수 있다는 것. 기반 지식이 없는 상태에서 웹 브라우저 기능 설명과 코드 설명이 들어가기 시작하면 더 어려워지고 발표가 산으로 갈 수 있다. 발표를 위해 기능 개발을 하기에는 시간도 얼마 안 남았고 가성비도 너무 떨어지는 전략이었다. 굳이 내가 했던 걸 직접적으로 예시로 들지 않더라도 어떤 방식으로 오픈소스 프로젝트가 진행되고, 어떤 생태계로 이뤄지고 있는지, 다른 오픈소스 프로젝트랑 다른 점, 신기한 점 얘기하는 것으로도 충분하다. 프로세스 얘기는 하면서 기술적인 얘기는 최대한 배제하고 내 얘기를 섞자, 지금은 회사 업무로 하고 있는 것도 아니고 회사 대표로 나오거나 홍보 목적이 있는 것도 아니니 회사 얘기는 최대한 자제하자.

2개의 메인 주제

Chromium, 다른 웹 브라우저, 웹 플랫폼의 오픈소스 생태계와 개발 프로세스
나의 오픈소스 경험

이렇게 방향을 다시 정했어도 할 얘기가 너무 많았다. 그래도 기능 개발을 포기하니 마음이 한결 편해졌다. 그제야 발표 준비를 본격적으로 시작할 수 있었다. 밀려있는 웹 브라우저, 웹 플랫폼 블로그를 최대한 빨리 읽고 10월 초 있었던 BlinkOn 19 영상을 찾아봤다. 준비를 본격적으로 해보니 프로세스 관련된 내용만 해도 분량이 꽤 많았다. 발표 시간은 Q&A 포함 40분이었는데 제안을 받았을 때부터 50분 이상이 필요하다고 생각했었던 터라 40분이 좀 빠듯한 느낌이 있었다.

발표 자료를 만들면서 내 소개 + 서론 10분, 프로세스 내용 20분, 개인적인 이야기 10분 정도로 분량을 조정했다. 발표자 소개 -> 발표 내용 소개 -> Chromium 소개 -> Blink 소개 -> 웹 플랫폼 소개 -> 개발 프로세스 설명 -> 나의 경험으로 최대한 자연스럽게 이어지게 하고 싶었다. 프로세스 주제에 깊게 들어가면 한도 끝도 없고 시간이 무한정으로 늘어나기 때문에 어디까지, 어떻게 설명할지에 대한 고민도 많이 했다. 밸런스와 흐름을 만드는 게 꽤 어려웠다.

발표 직전까지 완성을 제대로 못 했다. 송도까지 지하철을 타고 가면서 발표 자료 후반부와 대본 수정을 했다..

The Speaker’s Commentary

발표 자료 스피커덱 링크

영화 DVD/블루레이에 부록으로 들어있는 감독과 배우의 commentary 처럼 발표에 대한 해설을 붙여봤다.

발표자 소개 (페이지 1 - 9)

먼저 나의 배경을 설명하고 싶었다. 회사에서 했던 프로젝트를 나열하고 관련해서 어떤 오픈소스 프로젝트를 했는지 보여주는 것으로 시작했다.(이 부분은 스피커덱에서는 뺐다.) 오픈소스 컨퍼런스인만큼 GitHub 스크린샷으로 내가 참여했던 프로젝트에 대해 한 번 더 자세히 설명했다. Chromium 컨트리뷰션 트래킹하는 사이트에서 커밋 개수 그래프도 캡쳐해서 추가했다.(원래 내세울 게 없을수록 양으로 때운다.) 솔직히 오픈소스는 어느 정도의 자랑이 들어갈 수밖에 없고 이게 또 동기 부여가 되기도 한다.

서론 (페이지 10 - 16)

‘구글 엔지니어는 이렇게 일한다’ 책을 소개하고 이 책에서 ‘오픈소스 웹 브라우저 개발자는 이렇게 일한다.’ 라는 제목을 가져왔다는 것을 설명했다. 책의 목차와 그 중 내가 직간접적으로 경험한 것을 하이라이트해서 보여줬다. 오픈소스를 하면 이걸 모두 경험할 수 있어요! 의 느낌. 실제로 하나하나 1:1로 비교해서 얘기하고 싶었지만 그렇게 하면 발표가 전체적인 흐름 없이 끊김이 심할 것 같았고 분량 조절도 안 될 것 같아 포기했다. 발표에서도 1:1 비교 대신 책의 내용을 자연스럽게 녹여내겠다고 얘기했다.

빌드업 (페이지 17 - 31)

그다음부터는 Chromium 소개, Chrome 과의 차이, The Chromium Projects 소개를 했다. Chromium 중 Blink 렌더링 엔진에 기여하는게 좋은 이유를 설명했다. 이 부분은 얘기를 길게 할 수도 있었지만 생략을 많이 할 수밖에 없었다. 프로세스는 웹 플랫폼과 웹 브라우저를 모두 포함하여 얘기할 것이었기 때문에 웹 플랫폼에 대한 설명을 다시 하고, 3대 엔진을 가진 4대 웹 브라우저가 웹 플랫폼을 위해서 열심히 하고 있다고 짧게 설명했다.

개발(기여) 프로세스 (페이지 32 - 77)

본격적인 내용인데 어디까지 설명해야 할지 어려웠다. 간단히 넘어가기에는 너무 애매하고 깊게 얘기하면 한도 끝도 없었다. 책의 내용을 녹여내겠다고 했는데 잘 된 건지 잘 모르겠다. 그동안 기여하면서 나도 신경 쓰지 않거나 하지 않았던 부분이 많은데 잠깐 언급은 하더라도 빼먹는 부분은 없게 최대한 다 뒤져가면서 내용을 넣었다. 그러다 보니 풀 사이즈 스크린샷 한 장에 한 문장으로 대충 설명하고 바로바로 넘어가는 슬라이드가 많아졌다. 청중 입장에서는 너무 휙휙 넘어가는 느낌이지 않았을까 싶다.

느낀 점

발표에 대한 피드백은 많이 듣지 못했다. 발표 직후 지인 2명이 흐름과 기승전결이 좋았다고 했다. 고민한 부분이었으니 꽤 기분 좋은 칭찬이었다. 후반부 발표 연습을 거의 못 해서 분량에 대한 걱정이 있었는데 다행히 시간은 딱 지켰다. 문제는 40분 안에 빠듯하게 발표하려다 보니 하나하나 굉장히 빠르게 정신없이 넘어갔던 것 같고, 어느 순간부터 나도 모르게 준비한 스크립트는 거의 안 보고 프리스타일로 대충 설명하면서 빠르게 넘어갔다. 체력이 떨어져서 그랬는지, 시간에 대한 압박 때문이었는지 모르겠다. 원래 하려던 말을 빼먹거나 잘못 말한 것도 있었을 것이다. 이 발표 내용으로 여유 있게 발표를 하려면 한 시간 정도는 필요할 것 같다. Q&A에 대한 아쉬움도 있었는데 1명에게 질문을 받을 수 있었고 그 질문에 대해 만족할만한 답변을 하진 못했던 것 같다. 하고 싶었던 말은 꼭 뒤늦게 떠오른다.

발표장이 크고 넓어서 발표자와 청중 간 거리가 좀 있는 구조, 계단식이었고 조명을 낮춰놔서 그런지 청중의 리액션을 잘 못 느꼈다. 그래도 대부분 열심히 봐주시고 있다는 느낌은 받았다.

생각보다 후기가 많이 안 올라와서 실제 감상은 거의 못 봤다. 지금까지 찾은 오쏘콘 후기는 3건 정도. 그마저도 하나만 내 발표에 대한 내용이 포함되어 있었다. 아쉽지만 막상 또 안 좋은 말이 있으면 그건 또 그것대로 상처가 될 수 있으니 없는 것도 나쁘지 않다.

다 끝내고 나니 기회가 있다면 발표를 한 번 더 하고 싶다는 생각이 들었다. 준비하면서 스트레스를 많이 받았지만 다음에 하면 조금 더 잘할 수 있지 않을지? 조금 더 부드러운 분위기로 발표를 여유 있게 하고 싶은 목표도 있다. 끝나고 나니 후련하기도 하고 생각과 마음이 정리돼서 삶에 의욕이 다시 생긴 느낌이다.

발표자 기념품으로 받은 후드 집업 뒷면. 오픈소스 컨퍼런스인만큼 GitHub Pull Request 디자인으로.

2024 GDG Google I/O Extended 간단 후기

Sun, 06 Oct 2024 05:00:00 GMT

지난 7월 두 개의 GDG Google I/O Extended 에 참석했던 후기를 뒤늦게 올린다.

하나는 7월 20일에 열린 Extended Android, 다른 하나는 7월 27일에 열린 Extended 인천/송도 였다.

GDG 는 Google Developer Group 의 줄임말로 구글과 구글의 기술을 좋아하는 개발자 커뮤니티이다. GDG 운영진은 구글 소속이 아니고, GDG 에서 진행하는 공식 행사는 구글의 후원을 일부 받으면서 운영되는 것으로 알고 있다. 매년 세계 곳곳의 GDG 에서 I/O Extended, DevFest 와 같은 정기 행사를 열고, 때때로 자체적으로 비공식 행사를 개최하기도 한다. 코로나 전에는 GDG 서울과 수원에서 개최했던 DevFest, I/O Extended 행사를 다녀온 적이 있는데 좋은 기억으로 남아있다. (GDG 수원은 코로나 이후로 없어진 것 같다.)

GDG 에서 개최하는 행사는 구글 이름이 걸려 있지만 기업 주도의 컨퍼런스 느낌보다는 보통 개발자 교류를 위한 커뮤니티 성격이 더 강하다. 주니어 때는 이런 개발자 컨퍼런스를 꽤나 다녔는데 어느 순간 회의감이 들어서 코로나 이후로는 거의 가지 않았다. 보통은 내용이 주니어에게 맞춰져 있어서 너무 초보적이고 다 아는 내용이거나, 아니면 한 주제에 너무 집중적으로 들어가서 집중력을 잃고 얻는 것 없이 시간 낭비만 했다는 들었기 때문이다.

그러다 최근에 다시 가고 싶다는 생각이 들었는데,

요즘 너무 놀고만 있다는 생각
젊고 다양한 개발자들의 열기를 느끼고 싶음 (개발자 문화도 트렌드가 있다.)
현장에서 직접 보고 듣는 것이 집중이 잘 됨 (유튜브에 올라온 것은 잘 보지 않게 됨)

와 같이 동기 부여를 받고 싶었기 때문이었다.

특히 GDG 와 같이 커뮤니티 기반의 행사가 기업 주도의 컨퍼런스보다는 상대적으로 조금 더 동기 부여 측면에서 도움이 될 거라는 생각이 들었다. (기업 컨퍼런스는 대부분 추첨이나 선착순이라 경쟁률이 너무 높아 티켓팅이 쉽지 않기도 하다.)

Google I/O Extended

앞서 언급했듯이 매년 Google I/O 가 끝난 뒤에 여러 GDG 에서 Google I/O Exteneded 를 개최한다. 올해는 안드로이드, 인천/송도, 판교 등에서 I/O Extended 행사를 열었다. 지역 별로 전반적인 내용을 다루는 경우도 있고, 안드로이드, 웹, 머신러닝과 같이 특정 주제로 컨퍼런스를 열기도 한다.

안드로이드

안드로이드의 경우 트랙 하나로 모든 세션이 운영 되었고 각 세션이 Google I/O 에 충실한 느낌. 저녁에 다른 일정이 있어 중간에 나왔지만 안드로이드와 관련된 업무를 하는 입장에서 새로 발표한 내용을 다뤄줘서 좋았다. Google I/O 의 경우 이벤트 키노트와 개발자 키노트가 중요한데 I/O Extended 발표를 통해 이해하게 된 부분이 많았고 정리도 많이 됐다. 모든 세션이 끝나고 네트워킹 타임도 있었는데 참여하지 못했다.

수강

키노트
What’s new in Android
What’s new in Android development tools
유연한 Composable 설계(난 RN 개발자인데)
벤치마크 사용설명서(흑마법 아님 주의)

인천/송도

인천/송도는 Google I/O 에 한정짓지 않고 좀 더 개발자 축제 느낌으로 다양한 주제와 발표자를 선정한 느낌이었다. GDG 인천/송도는 코로나 이후로 다른 GDG 에 비해 컨퍼런스를 크게 열고 있는데 이번에도 역시나 발표가 많고 참석 인원도 많아 고민이 많았을 것 같다. 나는 컨퍼런스 참여 목적 첫번째가 동기 부여였기 때문에 General 주제 위주로 많이 들었다. 듣다 보니 피곤해지고 집중력이 너무 떨어져서 나중에는 지인의 발표나 내용이 쉬운 발표 위주로 들었다.

수강

에어프레미아는 왜 재개발을 하는가?
상태관리의 사실과 오해
사수 없는 주니어 개발자과 성장하는 방법
100명의 개발자분들을 도와 100개 넘는 오픈소스 PR을 함께 만들고 세상을 바꾼 이야기
Flutter Golden Test 101
Godot Engine으로 시작하는 1인 게임 개발

소감

오랜만에 컨퍼런스에 갔는데 기대한 것처럼 에너지를 많이 얻고 동기 부여를 받아서 돌아왔다. 기술적인 측면에서는 사실 큰 소득은 없었다. 그래도 다양한 사람들의 발표를 보면서 컨퍼런스 발표에 대한 생각도 조금 하게 됐다. 이 때 했던 작은 생각이 이어져서 실제로 11월에 발표를 하나 하게 됐다. 이전보다는 개발자 커뮤니티나 컨퍼런스 등에 조금 더 참여할 생각이다.

Chromium Committer 가 되었다

Sun, 26 May 2024 14:00:00 GMT

지난 2024년 3월에 Chromium Committer 가 되었다. Chromium Gerrit 에 아이디를 만든 지 8년 10개월, 첫 번째 패치를 반영한 지 5년 10개월 만이다. 그동안 반영한 패치 수는 75개. 짧은 기간에 적은 패치로 Committer 가 되는 사람이 많은데 중간 3년 이상의 공백을 빼더라도 유독 오래 걸렸다.

시작

어렸을 때부터 오픈소스 프로젝트와 오픈소스 개발자에 대한 환상이 있었다. 오픈소스 프로젝트가 뭔지 잘 모를 때부터 막연히 동경해 왔다. 오픈소스 프로젝트 개발자라는 이름 그 자체로 있어 보였고, 다른 개발자보다 좀 더 대단한 찐 개발자라는 환상이 있었다.

바야흐로 10년 전, 회사에 입사하기 전에 여름방학 동안 인턴으로 먼저 근무를 했었다. 인턴으로 입사할 때 회사 조직에 대해 아는 게 전혀 없었다. 1지망부터 3지망까지 가고 싶은 팀을 겨우 골라 써서 냈고 인사 면담을 했다. 며칠 뒤 알 수 없는 기준으로 2지망 팀에 배치를 받았다. 다행히 그 아래 부서를 선택할 수 있는 기회가 있었다. 말로 간단히 설명을 듣다가 한 부서가 WebKit 을 한다는 말을 듣고 옆에 있던 대학교 동기와 함께 바로 손을 들었다. 단순히 웹킷이 웹브라우저 오픈소스 프로젝트라는 것만 알고 손을 든 것이다.

막상 인턴을 하면서 회사에서 웹킷 코드는 구경도 못 했다. 짧은 인턴 후 신입 사원으로 다시 들어오기 전 6개월 사이 조직 구조와 프로젝트가 바뀌어 있었다. WebKit 은 이제 거의 하지 않고 Chromium 기반의 웹 브라우저를 메인으로 개발하고 있었다. 내가 인턴을 했던 그해에 Chromium 프로젝트에서 웹 엔진으로 사용하던 WebKit 을 Blink 로 fork 했고, 이에 따라 회사도 Chromium 기반의 프로젝트를 진행하기로 방향이 바뀐 것이다.

어쨌든 Chromium 도 오픈소스이고 오픈소스에 대한 로망은 여전했기 때문에 인턴을 했던 부서로 다시 돌아온 것에 만족했다. 신입으로 들어오면서 동경했던 오픈소스 개발자가 될 수 있을 거라는 기대를 했지만 생각처럼 되지는 않았다. 오픈소스 코드와 큰 관계가 없는 파트에 있으면서 4년 동안 Chromium 프로젝트에 직접적인 기여를 하지 못했다. 내가 먼저 적극적으로 어떻게든 움직였다면 기회가 많았을 텐데 그게 잘 안됐다. 시간이 지나 Chromium 프로젝트와 좀 더 밀접한 팀으로 옮기고 나서야 본격적으로 기여를 시작했다. 업무적으로도 이전보다 여유가 있었기 때문에 가능했다. 주변에 활발히 활동하던 Chromium Committer 분들과 Reviewer 가 있었던 것도 직간접적으로 도움이 됐다.

첫 번째 도전

처음 패치를 반영했던 2018년에는 Good First Bug 레이블과 온갖 필터 조합으로 진입 장벽이 낮은 이슈를 찾아 패치를 올렸다. 다른 사람이 이슈를 선점하지 않게 경쟁적으로 최대한 빠르게, 많이 올렸다. 내가 올린 패치가 빌드와 테스트를 성공하고, 리뷰 후 최종 반영될 때마다 도파민이 터졌고 그 도파민으로 다음 패치를 또 작업했다. 동시에 여러 패치를 작업하기도 했다. 깊이는 별로 없었다. 회사에서도 웹 브라우저 개발을 했지만, 오픈소스 기여는 회사 업무와 관련이 없는 부분을 따로 했기 때문에 전문성을 키우는 데 한계가 있었다.

2018년 말 50개 가까이 패치를 반영하고 살짝 번아웃이 온 시점에 Committer 가 되지 않으면 의욕이 꺾일 것 같은 기분이 들었다. 내 패치를 제일 많이 리뷰해 주었던 Blink 리드 개발자에게 이메일로 커미터 추천해 줄 수 있는지 문의했다. 나를 추천할 2명의 다른 리뷰어가 있는지 물어보는 답장이 왔다. 넓고 얕게 패치를 반영하다 보니 non-trivial 한 패치를 많이 리뷰해 준 또 다른 두 명을 콕 집기가 어려웠다. 그동안 한 게 이만큼인데 그냥 추천서 올려주면 아무나 동의를 해주고 커미터 될 수 있는 거 아닌가? 나의 작업물을 인정해 주지 않고 완곡하게 거절한 걸로 느껴져서 괜히 서운했다. 말 그대로 2명 더 있으면 해주겠다는 단순한 말이었을 수도 있지만, 이 개발자가 깐깐하다는 소문도 있었고 나 자신도 부족한 걸 제일 잘 알았기 때문에 쉽게 포기했다. 의욕을 잃고 몇 달 뒤 새로운 서비스를 하는 팀으로 옮겼다. 그렇게 첫 번째 도전을 포기했다.

두 번째 도전

2019년 초 이후로 프로젝트 기여를 다시 시작한 건 2022년. 그사이 부서를 한 번 더 옮겼고 코로나 시기를 겪으면서 커리어에 대한 고민이 많았다. 이직이나 전배에 대한 기회가 있었지만, 뜻대로 진행되지 않았다. 그냥 남아서 끝까지 해볼걸, 좀 더 깊게 할 걸 후회를 하면서. 이직이든 뭐든 간에 오픈소스를 하는 게 도움이 되지 않을까? 도움이 될 정도로 깊이 해야 하지 않을까? 여러 생각을 했다. 3년 만에 다시 시작하면서 이번에는 하나를 깊게 해보는 걸로 전략을 바꿔보았다. 여러 모듈을 조금씩 보다가 Web Authentication 모듈과 관련된 패치를 반영하기 시작했다.

운이 좋게도 리뷰어를 잘 만나 리뷰어에게 도움을 받으면서 순조롭게 패치 반영을 했다. 그 리뷰어가 오래된 웹 표준 스펙과 테스트를 수정해 줬다고 추천까지 해줘서 Google Open Source Peer Bonus 를 받기도 했다. 6개월 동안 중요한 패치 10개만 딱 채우면 Committer 로 추천해달라고 할 수 있을 것 같았다. 그런데 Web Authentication 은 너무 어려운 모듈이었고 7~8개 정도로 애매한 개수의 패치를 반영한 후에 마무리가 잘 안됐다. 반영하던 내용과 관련된 스펙에 미묘한 부분이 정리가 잘 안됐고 뒤에 올리던 패치도 흐지부지됐다. 워낙 크고 엮인 게 많은 모듈이고, 구글에서 소수의 인원이 회사 업무로, 집중적으로 하는 느낌이라 중간에 끼어들기가 쉽지 않았다.

또 한 번 의욕이 꺾이긴 했지만 2023년 오픈 프런티어 기여형 프로그램 에 참여하면서 1년 동안 다시 도전했다. 조금만 더 하면 될 것 같아 여기서 포기하기에는 아까웠다. 이번에는 Blink CSS 모듈에 반영하는 걸 목표로 했다. 아래와 같은 이유로 CSS 모듈을 골랐다.

웹 엔진 자체 기능
브라우저 앱 기능과 종속적이지 않음
웹 표준 스펙과 웹 플랫폼 테스트
웹 플랫폼 로드맵 존재
방대한 세부 기능
등록된 이슈가 많음

반영할 레이어가 적으면서, 스펙과 테스트가 명확하고, 앞으로 수정할 여지가 많은 모듈은 패치를 만들기도 쉽고 리뷰도 순조롭게 진행된다는 걸 경험했고 CSS 모듈이 이런 점을 충족한다고 판단했다.

전략(?)은 성공했고 결국 올해 CSS 모듈 리뷰어에게 추천을 받아 Committer 가 될 수 있었다. 올해 초에 리뷰 진행이 잘 안되고 feature spec 문서 작성 요청을 받으면서 귀찮고, 지치고, 포기하고 싶은 마음이 들었다. 마지막이라는 생각으로 최근에 자주 리뷰해 줬던 리뷰어에게 이메일로 작년에 반영한 패치 와 기존에 반영했던 패치 중에 중요한 것들을 정리하여 추천해 줄 수 있는지 문의했다. 조금 걱정했지만 리뷰어가 쿨하게 Committer 그룹에 노미네이션 이메일을 보내주었고 반대없이 지인 포함(ㅎㅎ) 여러 명이 +1을 해주면서 최종적으로 Committer 가 되었다. 내가 그 추천서 이메일을 직접 볼 수는 없고 아는 커미터 분께서 본인이 받은 메일을 따로 보내주셔서 내용을 볼 수 있었다. 추천서 내용을 보니 리뷰어가 feature spec 문서 작성을 요청했을 때 외부 개발자들은 잠수를 많이 타는데 나는 그렇지 않고 잘 진행해 주어 미래에도 가치 있는 컨트리뷰터가 될 것 같다는 멘트가 있었다. 올해 패치를 반영하면서 힘들게 feature spec 문서를 작성했던 게 크게 작용한 것 같다.

Chromium Committer?

Chromium Committer 가 되기 위한 조건으로 10~20개의 non-trivial 패치 반영, 커미터 한 명의 추천 글과 다른 커미터 두 명 이상의 동의, 반대하는 사람이나 이견이 없어야 한다. 당연히 커미터 후보는 기본적으로 크로미움 프로젝트 개발 프로세스를 이해하는 개발자여야 한다. 협업 능력, 프로젝트 코드, 코딩 스타일, 테스트, 코드 리뷰 프로세스 등을 이해하는 것을 전제로 한다.

Committer 가 되면 좋은 점은 무엇일까?

Committer 라는 명칭은 보통 commit 을 할 수 있는 권한을 가진 사람이다. 하지만 보통의 개발 프로세스에서 큰 의미가 없다. 당연히 빌드와 테스트가 성공해야 하고 리뷰어(Module Owner)에게 정식으로 리뷰를 받고 반영해야 한다. 예전에는 Committer 는 리뷰를 받지 않아도 반영할 수 있었던 것 같은데 현재는 +1 리뷰 한 개가 강제화 되어있다. Non-committer 의 경우 +1 리뷰 2개를 받아야 패치를 반영할 수 있어 조금의 차별점이 있다.
bug edit 권한과 trybot 권한이 생긴다. Committer 가 아니어도 별도로 신청해서 받을 수 있는 권한이라 차별점이라고 보기는 어렵다. 몇 개의 패치를 반영한 뒤에 별도로 신청해서 권한을 받을 수 있다. 나는 2018년에 패치 4~5개 반영 후 다른 분이 신청을 해줘서 권한을 받았다. Committer 가 되고 나서 비교해 보니 Mega CQ Dry Run 권한이 추가로 생겼는데 이 권한은 없어도 기여를 하는 데 큰 지장이 없다.
chromium.org 이메일 계정을 받을 수 있다. 나는 옛날부터 오픈소스 프로젝트의 Committer 나 Maintainer 가 해당 프로젝트의 이메일 계정을 쓰는 게 너무 멋있다고 생각했다. 개인적으로는 이메일 계정이 가장 큰 메리트라고 생각했다. 예전에는 커미터가 되면 계정을 바로 줬다고 들었는데 보안 이슈 등으로 몇 년 전부터는 별도 신청을 해야 계정을 준다. 나는 회사 소속이고 회사 계정으로 기여를 해왔기 때문에 chromium.org 계정을 받아도 실제로 사용할 일이 많지 않지만, Committer 라는 걸 알았을 때부터 계정을 갖고 싶었기 때문에 따로 계정을 요청했다. 회사 보안이나 내부 시스템 때문에 회사 계정에 한계가 있어서 chromium.org 계정이 필요하다고 이유를 작성했다. 겨우 계정을 받아서 second 계정으로 등록을 해놨다. 앞으로 Slack, Google Docs 등의 시스템을 사용하거나 이메일을 주고받을 일이 있으면 사용할 것 같다.

Chromium Contribution 의 한계

Chromium 은 빅테크 기업 구글이 주도하는 큰 규모의 오픈소스 프로젝트이기 때문에 일반적인 오픈소스 커뮤니티 주도로 운영되는 프로젝트와는 조금 다르다. 개발 프로세스에서 볼 수 있는 chromium.org 계정의 대부분이 구글 개발자이고 그 사람들은 회사 업무와 프로젝트를 오픈된 환경에서 하는 것이라고 봐도 무방하다. 많지는 않지만, 외부 개발자에게 읽기 권한이 없는 이슈와 문서도 있다. 어떤 모듈은 구글 팀이 회사 업무로 로드맵을 세우고 매일 회의하면서 진행하고 있어서 외부인이 중간에 끼어들기 쉽지 않다.

프로젝트 규모가 너무 큰 것도 개인 개발자에게 한계로 느껴질 때가 많다. 규모가 너무 크고 코드가 빠르게 바뀌어 지속적인 추적을 하기 어렵다. 한 명의 개발자가 규모가 있는 큰 기능을 구현하는 것도 쉽지 않다. 그 과정에서 수많은 코드, 개발자, 리뷰어 등을 거쳐야 한다. 물론 처음부터 끝까지 프로세스를 거쳐 하나의 기능에 대해 디자인, 구현, 기능 배포까지 끝내면 퀀텀 점프를 한 느낌을 받을 수 있지만 감히 엄두가 나지 않는다. 그렇다 보니 자꾸 작고 쉬운 수정에 익숙해진다. 사실 내가 그렇다. 주도적으로 한 모듈에 큰게 기여 한 경험이 없다. 다음 레벨로 넘어가지 못하는 느낌이 든다. (다 실력이 부족해서 그렇다) 많은 개발자들이 Chromium 오픈소스 활동을 하다가 중간에 비슷한 한계를 느껴 흥미를 잃는다.

Chromium 프로젝트를 웹 브라우저 기반으로 사용하는 기업의 경우, 팀에서 별도의 협업을 통해 feature 를 제안하고 구현하기도 한다. 보통 Chrome 의 로드맵에 맞춰 Chromium 브라우저 기능을 구현하기 때문에 외부에서 새로운 브라우저 기능을 추가하는 건 사실상 불가능하고, 보통은 웹 표준 관련된 모듈에 기여한다. Blink 등 웹 표준과 관련된 웹 엔진 기능은 외부의 W3C Spec 에 맞춰 구현되기 때문에 구글 외의 다른 기업이 W3C Community 의 Working Group, Editor 활동을 하면서 Chromium 에도 같이 기여를 한다. 웹 표준화 일은 웹 플랫폼 생태계에 기여하는 것이지 금전적으로 큰 이익이 되는 건 아니기 때문에 보통은 개발자 생태계에 기여할 여유가 있는 메이저 웹 브라우저 벤더들이 참여하고 있다. 크롬의 구글, 사파리의 애플, 파이어폭스의 모질라 재단은 물론이고 이를 기반으로 웹 브라우저를 개발하는 빅테크 기업들도 웹 표준화 업무도 같이 한다. 마이크로소프트는 2018년부터 Edge 를 Chromium 브라우저 베이스로 개발하면서 코드 컨트리뷰션 뿐만 아니라 웹 표준화에도 깊게 참여하고 있다.

한계를 길게 써놨는데 순수 실력으로 이런 한계를 돌파한 분들도 있다. 이분들은 이미 웹 표준 에디터나 모듈 리뷰어를 하고 계신다. 외부 사람들이 보통 기대하는 커미터, 이상적인 오픈소스 개발자에 가까운 활동을 한다.

앞으로

Committer 가 된 것이 개인적으로는 하나의 마일스톤을 달성했다는 의미가 있지만 대외적으로는 별것이 아니라고 생각한다. 이게 개발 실력을 대변해 주지 않고, 타이틀 하나로 큰 힘이 있는 게 아니라는 걸 많은 분들이 아실 것이다. 우리나라에도 대충 어림잡아도 20~30명 이상의 Chromium Committer 가 있다. 프로젝트에 기여하는 사람 수를 생각하면 적다고 생각할 수도 있지만 그렇다고 완전 소수도 아닌 숫자다.

어쨌든 수년간 오픈소스를 하면서 많이 배우고 성장할 수 있었다. 회사에서 배울 수 없는 개발 프로세스를 경험하고 좋은 코드와 디자인도 볼 수 있었다. 일반화하긴 어렵지만 대개 오픈소스 프로젝트는 보통 회사에서 진행하는 프로젝트보다 좀 더 이상적인 형태로 운영이 된다. 회사에서 업무를 할 때도 스스로나 팀에게 적용하여 많은 도움이 됐다.

지금은 웹 기술과 웹 플랫폼, 웹 브라우저와 관련된 일을 하고 있진 않지만, 언젠가는 다시 하고 싶다는 마음이 있다. 놓지 않고 꾸준히 하다 보니 결국 커미터가 되었다. 다음 단계로 웹 표준 에디터나 리뷰어도 열려 있지만 회사 업무로 웹 브라우저 개발을 본격적으로 해도 달성하기엔 너무 어려운 목표이다. 지금 이 시점에 이걸 더 하는 게 맞나 의구심이 들기도 한다. 어쨌든 2024년 AI 시대에 앞으로 패러다임이 어떻게 바뀔지는 모르겠지만, 일단 플랫폼 쪽에 붙어있으면 좀 더 오랫동안 인간이 주도하는 일을 할 수 있지 않을까 생각하고 있다. 개인적으로 웹 브라우저를 포함한 웹 플랫폼이나 최근에 했던 안드로이드 플랫폼 등 다른 개발자가 사용하는 플랫폼을 만드는 일에 재미를 느꼈다. (물론 내가 했던 일은 구글과 회사에 깊게 엮여 있다는 함정이 있다)

커미터가 된 지 벌써 두 달이 넘었는데 그 사이 별 활동을 하지 않았다. 다음 목표가 없고, 동기가 떨어져서 그런 것 같다. 다시 작은 수정부터 사이클을 만들어야겠다. 오픈소스 활동도 관성이 있어서 멈추면 다시 시작하기 너무 어려운데 한 번 반영하기 시작하면 다시 쉽게 사이클이 생긴다. 다시 쳇바퀴에 들어가 Chromium 에 구현되지 않은 웹 표준 기능을 처음부터 끝까지, 문서화부터 기능 배포까지 해보고 싶다. 이렇게 하나의 기능에 대해 한 사이클을 돌려본 적이 없기도 하고, 퀀텀 점프를 위한 이벤트를 스스로 만들고 싶은 것이 가장 큰 이유이다.

2023년 회고 그리고 2024년

Tue, 02 Jan 2024 14:45:00 GMT

회사

11월에 팀을 옮겼다. 특이한 부서의 인원 모집 공고가 떴는데 마침 예전에 있던 팀에서 알던 분이 계셔서 먼저 연락을 드렸고, 감사하게도 뽑아주셨다. 이전 팀은 우리 회사의 핵심 부서 중 하나이고 아주 큰 조직이었다. 3년 6개월 동안 많이 배우기도 했지만 힘든 점도 많았다. 내외적으로 여러 종류의 스트레스가 있었다. 스스로 해결하기 어려운 어쩔 수 없는 문제가 많았다. 정신적으로 지쳐서 그런지 내적인 문제도 계속 쌓였다. 결국 환경을 바꿔주면 조금이라도 해소가 될 수 있을거라고 믿었다. 이런저런 고민이 많을 때에 좋은 기회가 있어서 옮겼다. 회사가 크다 보니 팀을 옮기는게 이직하는 것과 비슷한 효과를 주는 것 같다.

나오면서 이전 부서에서 경험한 일과 조직에 대한 복기를 해봐야겠다고 생각했는데 아직 정리를 못했다. 더 늦기 전에 정리를 해두려고 한다. 분명 배운 점도 많이 있었다. 그동안 배운 것과 고민했던 것이 새로 온 부서에서 적응하는데 도움이 되고 있다. 이전 부서에 생각보다 길게 있었기 때문에 더 큰 스트레스를 받았던 것 같기도 한데, 이 정도 있었기에 알게 된 것도 많다.

이제 이 회사에서 일을 시작한지 만으로 10년이 되었다. 그동안 자의로 팀을 세 번 옮겨서 이번이 네번째 팀이다. 그동안 거쳐 온 부서들의 성격이 각각 달랐었는데 이번 팀은 또 완전 다르다. 선행 조직이고 다양한 직군이 있다보니 지금까지 경험해보지 못한 업무 목표, 방향, 관점을 갖고 있다. 팀이 작다보니 개인적인 역할도 더 생겼다. 리더는 아니지만 주니어 양성에도 좀 더 신경을 써야 한다. 예전보다는 나를 좀 더 돌아보고 주변도 함께 돌아볼 수 있는 여유가 생겼기에 많은 걸 시도해보고 배울 수 있기를 기대하고 있다.

오픈소스

작년에 다시 시작했던 Chromium 기여 활동을 잠깐 쉬다가 오픈 프런티어 활동을 하면서 조금씩 패치를 반영했다. 회사에서도 오픈소스에 관심 있는 분들 대상으로 멘토링을 했다. 회사에서 갑자기 멘토링 프로그램을 시작하였고 별 다른 가이드없이 멘토에게 자율적으로 멘토링을 맡겼다. 멘토링이 처음이었기 때문에 준비해둔 자료가 없었다. 이 프로그램을 위해서 새로 무언가를 만드는 건 부담되는 일이었다. 멘티는 두 명이었는데 간단한 세미나 한 번, 식사 몇 차례와 티타임을 가졌다. 한 분은 현업과 관련이 크게 없는 프로젝트였음에도 몇 차례 패치를 반영했다. 좀 더 준비가 되어있었으면 서로 좋았을텐데 아쉽다. 평소에 정리와 문서화를 잘 해두어야겠다는 생각을 했다.

그동안 오픈소스에 관심을 갖고 직접 기여를 하면서 많이 배웠다. 2024년에는 1. Chromium 기여를 좀 더 해서 committer 가 되는 것, 2. 다른 오픈소스 프로젝트를 선택해서 꾸준히 기여하는 것, 3. 내 프로젝트를 오픈소스 프로젝트 형식으로 개발하여 플레이스토어에 출시하는 것을 목표로 세웠다.

스터디

2개의 스터디를 해봤지만 큰 성과는 없었다. 하나는 AOSP 스터디였다. 온라인에서 스터디 인원을 모집하는 글을 보고 신청했다. 스터디 그룹 인원은 4~5명 정도 됐는데 각자 업무가 다르고 목표가 달랐다. 너무 광범위한 주제였고 스터디를 진행하기에 적절한 도서나 레퍼런스가 없었다. 온라인 스터디 8회, 오프라인 모임 1회를 하고 마무리했다. 현재 국내에서 AOSP 에 관심을 갖고 블로그에 자료를 꾸준히 올리는 사람이 거의 없다. 스터디를 하면서 다른 회사에서 AOSP 관련 현업을 하면서 관심을 갖고 있는 개발자들을 만나서 좋았는데 이 기회를 발전시키지 못한게 아쉽다. 다른 스터디 하나는 Chromium contribution 을 하면서 부족한 부분을 채우고자 예전 부서 분들과 C++ 스터디를 해봤는데 이것도 잘 안 됐다. 제대로 된 스터디를 경험해본 적이 없어서 그런지 아직까지는 스터디 그룹으로 공부하는 방식이 잘 안 맞는 것 같다. 이외에 Chromium contribution 을 하는 국내 개발자들을 모아서 했던 ‘오픈소스를 하는 사람들’이라는 모임에도 참여했었다. 매주 일요일 밤 10시에 온라인으로 모여서 인사하고 각자 개발하는 시간을 가졌다. 이것도 어느 순간 흐지부지되면서 하반기부터는 모임 진행이 잘 안 됐던 것 같다. 올해는 스터디보다는 차라리 온라인 강의 수강을 시도해보려고 한다. 집에 있는 책도 많이 읽어야겠다.

블로그

2023년에는 이 블로그에 8개의 글을 올렸다. Chromium 에 반영한 내용을 정리해서 올리기 시작했다. 블로그에 올리면서 좀 더 정리를 하게 되는 효과가 있어 2024년에도 같은 방식으로 글을 올리려고 한다. 2023년 초에 velog, 티스토리를 따로 만들어서 조금씩 올렸는데 흐지부지됐다. velog 에는 간단한 TIL(Today I Learned) 을 올리고 티스토리에는 책, 강의, 레퍼런스 등을 정리하는 글을 올리려고 한다.

중국 개발자가 내 Google Analytics ID 를 삭제하지 않은 채로 내 블로그 repo 를 그대로 갖다 썼다. 이 사실을 알게 되어 내가 해당 repo 에서 ID 를 직접 삭제하기 전까지 며칠동안 그 블로그가 추적되었다. 조회수가 너무 확 튀어버렸다.

다음은 검색어 순위. aosp cuttlefish 관련 검색어가 많다. 검색어 노출 순위도 나름 높은 편이다.

2024년

2024년 한 해의 목표를 Pay Off 로 정했다. 밀린 부채를 갚는 것이다. 아주 예전부터 매년 계획을 세웠지만 달성하지 못한 적이 훨씬 많았다. 잊고 살다가도 다시 또 비슷한 계획을 세우고 시도하려고 한다. 위에 작성한 오픈소스 활동이라던지, 앱 출시, 블로그 관리 같은 일들은 대학생 때부터 생각하고 여러 방식으로 계획을 세웠던 일이지만 지금까지 제대로 마무리한 적이 없다. 10년 동안 일을 하면서 쌓인 기술 부채와 미뤄두었던 여러 목표를 갚을 수 있는 해가 되길 바란다. 부족한 부분을 채우고 다시 나아갈 수 있는 힘을 기르고 싶다.

Chromium Contribution: CSS KeyframesRule length attribute 추가

Thu, 30 Nov 2023 09:30:00 GMT

개요

CSSKeyframesRule 은 CSS 에서 키 프레임 애니메이션을 정의하는데 사용된다. @keyframes 으로 애니메이션 과정의 스타일을 변경할 수 있다.

[Exposed=Window]
interface CSSKeyframesRule : CSSRule {
           attribute CSSOMString name;
  readonly attribute CSSRuleList cssRules;
  readonly attribute unsigned long length;

  getter CSSKeyframeRule (unsigned long index);
  undefined        appendRule(CSSOMString rule);
  undefined        deleteRule(CSSOMString select);
  CSSKeyframeRule? findRule(CSSOMString select);
};

여기서 getter 함수는 indexed property getter로 index 값으로 접근이 가능한 getter 를 나타낸다. keyframes[0], keyframes[1] 과 같이 index 값으로 keyframe property 에 접근이 가능하다. Web IDL 에서 indexed properties 를 속성으로 포함하고 index 를 사용해서 그 값에 접근하려는 경우, length 도 함께 define 되어야 한다. length는 indexed properties 의 길이를 나타낸다.

내용

blink 가 WebKit 이던 시절부터 비표준 함수로 getter 가 존재했다. 현재는 표준 API 로 변경되었기에 // Non-standard APIs 주석을 제거하고 스펙과 동일한 위치로 옮겼다. length attribute 를 추가하였고, 구현 내용은 구현부에 이미 존재해서 별도로 구현할 필요는 없었다.

테스트

CSSKeyramesRule 타입에 length 가 없어서 실패한 테스트가 모두 성공으로 바뀌었다.

third_party/blink/web_tests/external/wpt/css/cssom/CSSKeyframesRule.html

test(function () {
  const keyframes = document.styleSheets[0].cssRules[2];
  assert_equals(
    keyframes[0].cssText,
    "0% { top: 0px; }",
    "CSSKeyframesRule indexed getter [0]",
  );
  assert_equals(
    keyframes[1].cssText,
    "100% { top: 200px; }",
    "CSSKeyframesRule indexed getter [1]",
  );
  assert_equals(keyframes.length, 2, "CSSKeyframesRule.length");
}, "indexed getter, length");

후기

간단한 수정이기 때문에 코드 리뷰는 문제없이 진행되었으나 API 가 추가된 것이기 때문에 리뷰어로부터 feature 등록을 요청 받았다. 이 패치의 경우 버그 수정에 가까워 형식적인 절차나 다름없는 것이었다. 하지만 feature 등록과 feature 리뷰 진행은 처음 진행해봐서 좋은 경험이 되었다.

Chromium Contribution: CSS GroupingRule insertRule 함수의 index 파라미터를 optional 로 변경

Thu, 30 Nov 2023 08:00:00 GMT

개요

CSSGroupingRule 은 CSS에서 다른 CSS 규칙들을 그룹화하는 데 사용되는 추상 기본 인터페이스이다. @media 또는 @supports 규칙과 같은 at-rule 그룹을 형성하는 데 사용된다.

[Exposed=Window]
interface CSSGroupingRule : CSSRule {
  [SameObject] readonly attribute CSSRuleList cssRules;
  unsigned long insertRule(CSSOMString rule, optional unsigned long index = 0);
  undefined deleteRule(unsigned long index);
};

insertRule 함수를 사용하면 새로운 스타일 규칙을 현재 스타일 시트에 추가할 수 있다.

var stylesheet = document.styleSheets[0];
var newRule = "body { background-color: black; }";
stylesheet.insertRule(newRule, stylesheet.cssRules.length);

insertRule 함수의 마지막 인자인 index 값은 스펙 상으로 optional 하며 값을 명시하지 않는 경우, 0 으로 default 값을 사용하게 되어있다. 현재 Chromium 에서는 이 값이 optional 이 아니기 때문에 값을 넣지 않으면 오류가 발생한다.

var stylesheet = document.styleSheets[0];
var newRule = "body { background-color: white; }";
stylesheet.insertRule(newRule);

내용

CSSGroupingRule insertRule 함수의 index 파라미터를 optional 로 변경하고 값이 없는 경우 0 을 사용하도록 변경했다. 추가로 rule 파라미터의 타입도 DOMString 에서 CSSOMString 으로 변경했다.

IDL 인터페이스만 변경하고 별도 구현 부분을 수정할 필요는 없었다.

테스트

WPT 에서 스펙과 맞지 않는 부분과 insertRule 의 index 를 특정하지 않는 케이스에 대한 테스트가 실패하고 있었다.

third_party/blink/web_tests/external/wpt/css/cssom/CSSGroupingRule-insertRule.html

test(function (t) {
  var groupingRule = create(t);
  var first = groupingRule.cssRules[0].cssText;
  var result;

  result = groupingRule.insertRule(".foo {}");

  assert_equals(groupingRule.cssRules.length, 2);
  assert_not_equals(groupingRule.cssRules[0].cssText, first);
  assert_equals(groupingRule.cssRules[1].cssText, first);
  assert_equals(result, 0);
}, "index not specified");

코드 수정과 함께 테스트 결과가 성공으로 바뀌었다.

후기

간단한 수정이었지만 스펙과 다른 부분을 고치는 건 뿌듯한 일이다. WPT 테스트 결과도 수정할 수 있었고 스펙과 일치하지 않는 blink 의 오래된 테스트도 고칠 수 있었다.

Chromium Contribution: webauthn junit 사용하지 않는 코드 및 DEPS 삭제

Wed, 29 Nov 2023 07:00:00 GMT

개요

Chromium 프로젝트의 content 모듈은 사실상 웹 브라우저의 본체와 같다. content 모듈에서 Chrome 의 자체 기능을 구현하거나 UI 를 활용한 부분을 제외한 전반적인 멀티프로세스 브라우저 기능을 담당한다. content 레이어까지만 포함하여 기본적인 브라우저 기능을 제공하는 Content Shell 이라는 앱을 빌드할 수도 있다. chrome 이나 android_webview 등의 content 를 사용하는 모듈은 content/public 폴더에 있는 public API 를 통해 content 모듈에 접근하도록 설계되어있다. Android 를 위한 Java 파일의 경우 content_public 과 같은 package 명으로 구분을 하기도 한다.

이런 각 레이어, 모듈 간의 종속성은 폴더마다 DEPS 파일로 관리한다. 이 파일에 선언한 내용을 위반하면 빌드가 불가능하다. 테스트나 어쩔 수 없는 특별한 경우에는 예외 처리를 하기도 한다.

내용

webauthn 의 안드로이드 테스트 코드에서 content 에 구현되어있는 ClientDataJsonImpl 클래스를 mocking 하여 사용하는 경우가 있다. 원칙적으로 ClientDataJson 클래스는 public 이고 ClientDataJsonImpl 은 그 구현체이기 때문에 chrome 레이어에서는 ClientDataJson 을 사용하고 ClientDataJsonImpl 에는 접근을 하면 안 된다. 하지만 테스트 코드에서는 ClientDataJsonImpl 을 예외처리하여 직접 사용하고 있다.

ClientDataJson 의 위치 : content/public/android/java/src/org/chromium/content_public/browser/ClientDataJson.java
ClinetDataJsonImpl 의 위치 : content/public/android/java/src/org/chromium/content/browser/ClientDataJsonImpl.java

chrome/android/junit/DEPS 파일에는 ClientDataJsonImpl 파일에 대한 예외 처리가 되어있다.

specific_include_rules = {
  # Added to allow tests to mock JNI methods within the implementation. Tests
  # use the public API classes where possible.
  "Fido2CredentialRequestRobolectricTest.java": [
    "+content/public/android/java/src/org/chromium/content/browser/ClientDataJsonImpl.java",
  ]
}

이처럼 DEPS 에 예외처리가 되어있고 Fido2CredentialRequestRobolectricTest 에서 ClientDataJsonImpl 을 import 하고 있지만 실제로는 사용하지 않고 있기 때문에 불필요한 코드를 삭제하고 DEPS 에서도 삭제했다.

후기

Chrome Android instrumentation 테스트를 하는 javatest 모듈에도 예외처리가 되어있다. (위치: chrome/android/javatests/DEPS) 여기서는 실제로 테스트 코드에서 ClientDataJsonImpl 를 사용하고 있어 DEPS 내 예외처리 삭제와 레이어 종속성 규칙을 지키기 위한 코드 수정이 함께 필요하다. 이전에 시도를 해보다가 적절한 답을 못 찾았는데 다음에 다시 한 번 도전해볼 생각이다.

Chromium Contribution: CSS @supports rule 에서 비어있는 () 허용

Thu, 22 Jun 2023 20:30:00 GMT

개요

CSS 에서 @supports 문법을 활용하면 브라우저가 해당 속성을 지원하는지 여부에 따라 속성 값을 선언할 수 있다. @supports 뒤에는 조건이 올 수도 있고, selector 와 같은 함수가 올 수도 있다. and, or, not 등의 연산자도 사용 가능하다.

@supports () {
}

@supports unknown() {
}

위와 같은 경우 @supports 최후의 파싱 규칙인 <general-enclosed> 을 따르게 되는데 이 때 값이 없는 인자를 가진 임의의 함수나 빈 괄호가 선언되어 있는 경우 unsupported 를 리턴하도록 스펙에 명시되어 있다. 하지만 현재 Chromium 에서는 이 경우에 parsing failure error 를 리턴하고 있다.

내용

<general-enclosed> = [ <function-token> <any-value>? ) ]
                 | ( <any-value>? )

<any-value>? 에서 ? 는 optional 을 뜻한다. 값이 있어도 되고, 없어도 된다는 뜻이다. 기존 Chromium 에서는 <any-value> 에 ? 가 없는 규칙에 맞춰 구현되어 있었다. <general-enclosed> 은 1) <function-token> (( 포함) 으로 시작하여 <any-value> 또는 빈 값 후 ) 으로 닫히거나, 2) () 안에 <any-value> 가 있거나 빈 값인 경우 2가지에 대하여 unsupported 를 리턴한다.

auto block = stream.ConsumeUntilPeekedTypeIs<kRightParenthesisToken>();

// 추가한 코드
block.ConsumeWhitespace();
if (block.AtEnd()) {
    return Result::kUnsupported;
}

위에서 ConsumeUntilPeekedTypeIs 함수는 kRightParenthesisToken()) 토큰이 나올 떄까지 stream 을 consume 하여 CSSParserTokenRange 타입의 block 을 리턴한다. 이렇게 하면 ( 다음부터 가장 마지막 ) 전까지의 CSSParserTokenRange 값을 받아올 수 있다. 그 다음 ConsumeWhitespace 함수로 block 의 whitespace 를 제거한다. block 이 끝까지 consume 된 상태라면 block 은 whitespace 로만 이루어져 있다고 볼 수 있다. 이 경우 kUnsupported 를 리턴하여 함수 안에 빈 값이거나 괄호 안에 빈 값이 있는 케이스에 대하여 처리할 수 있다.

테스트

third_party/blink/web_tests/external/wpt/css/css-conditional/js/supports-conditionText.html

FAIL conditionText getter for @supports () assert_equals: expected 1 but got 0
FAIL conditionText getter for @supports func() assert_equals: expected 1 but got 0
FAIL conditionText getter for @supports (()) assert_equals: expected 1 but got 0
FAIL conditionText getter for @supports (func()) assert_equals: expected 1 but got 0

third_party/blink/web_tests/external/wpt/css/css-conditional/css-supports-040.xht
third_party/blink/web_tests/external/wpt/css/css-conditional/css-supports-041.xht

코드를 수정하면서 WPT 에서 빈 ()에 대한 케이스를 많이 수정할 수 있었다. blink unit test 에도 () ( ) asdf() 와 같은 테스트 케이스도 추가하였다.

코드 리뷰

blink unit test 에서 ( 만 선언되어 있는 경우 kParseFailure 를 리턴하도록 되어 있었다. 기존 테스트 코드를 깨지 않기 위해 ) 토큰이 아예 없는 경우에 대한 예외처리 코드를 넣었었다. 리뷰어가 )가 보장되어 있기 때문에 불필요한 예외처리라고 댓글을 남겼다. 기존에 있던 테스트 코드 때문에 넣었다고 리뷰어에게 설명을 하면서 테스트를 고치면 될지 물어보았다. ( 도 <general-enclosed> 로 간주된다고 하여 예외처리를 삭제하고 테스트 케이스를 변경하였다.

후기

최종적으로 반영한 코드는 몇 줄 안 되지만 예외처리를 생각하는 과정에서 CSS Rule Parser 에 대해 조금 더 깊게 볼 수 있었다. 다른 패치를 반영할 때도 도움이 많이 될 것 같다.

Chromium Contribution: 불필요한 register-property-syntax-parsing.html.ini 파일 삭제

Wed, 21 Jun 2023 21:10:00 GMT

개요

JS 에서 CSS 의 @property 를 직접 선언할 수 있는 registerProperty 함수에 대한 WPT(Web Platform Tests) 실패 이슈를 찾았다. 코드를 좀 더 찾아보니 이미 반영이 된 상태였다. WPT 테스트 파일이 GitHub repository 에서 Chromium 으로 merge 될 때 실패 케이스에 대하여 생성된 초기 파일 register-property-syntax-parsing.html.ini 이 아직 남아있어 해당 파일을 삭제하는 패치를 만들어 반영하고 관련된 이슈 2개를 정리했다.

내용

@property --my-color {
  syntax: "<color>";
  inherits: false;
  initial-value: #c0ffee;
}

CSS 에서는 위와 같이 @property 로 custom property 를 직접 선언해서 사용할 수 있다.

window.CSS.registerProperty({
  name: "--my-color",
  syntax: "<color>",
  inherits: false,
  initialValue: "#c0ffee",
});

JS 에서 registerProperty 함수를 사용하여 선언하는 방법도 있다.

function assert_valid(syntax, initialValue) {
  // No actual assertions, this just shouldn't throw
  test(function () {
    var name = "--syntax-test-" + test_count++;
    CSS.registerProperty({
      name: name,
      syntax: syntax,
      initialValue: initialValue,
      inherits: false,
    });
  }, "syntax:'" + syntax + "', initialValue:'" + initialValue + "' is valid");
}

assert_valid("*", "default");

WPT 에서는 assert_valid 함수로 테스트 케이스를 만들어 확인하고 있다. universal syntax * 에 대하여 default 초기값으로 선언이 가능해야 하는데 Chromium 에서는 불가능한 것이 이슈였다. CSS 에서 default 는 initial, inherit 등과 달리 예약어가 아니므로 초기값으로 사용할 수 있다.

후기

Chromium 의 WPT 에 있는 ini 파일은 TestExpectation 파일이나 실패 결과에 따라 생성된 *-expected 파일과는 달리 실제 테스트 결과와 관련이 없다. GitHub 에서 Chromium 으로 merge 될 때 당시의 결과만 보여주는 것이므로 큰 의미가 없다. 그래도 이번 시도를 통해서 이슈와 코드를 트래킹해보고 ini 파일의 역할을 알게 된 것은 의미가 있었다.

Chromium Contribution: CSS FontFace 속성 타입을 DOMString 에서 CSSOMString 으로 변경

Tue, 20 Jun 2023 22:50:00 GMT

개요

다시 Chromium 에 contribution 을 시작했다. 작년 10월에 마지막으로 패치를 반영한 이후로 6개월 넘게 아무것도 하지 않았다. 이제 다시 마음을 잡고 꾸준히 기여해보려고 한다. 오랜만에 버그 트래커를 뒤져서 쉬운 것부터 찾아 시작했다. 올해 웹 플랫폼 생태계에서 집중적으로 신경쓰고 있는 모듈 중 하나이면서 이슈가 많은 CSS 모듈을 선택했다. CSS 모듈 내 Web Spec 과 Chromium Blink 의 Web IDL(Interface Definition Language) 파일의 내용이 일치하지 않는 이슈를 찾아 수정하였다.

내용

이슈의 내용은 FontFace 의 속성들이 현재 선언되어 있는 DOMString 대신 W3C CSS 스펙에 따라 CSSOMString 타입을 리턴해야 된다는 것이었다. 보통 IDL 에서 어떤 속성의 타입이 스펙과 다른 경우, 1) IDL 의 파일만 살짝 바꿔주면 되는 경우, 2) IDL 및 IDL 이 동일한지 검증을 하는 WPT (Web Platform Tests) 를 같이 수정해줘야 하는 경우, 3) IDL 과 관련된 로직, C++ 파일들까지 함께 수정해줘야 하는 경우 등 간단하게는 3가지 경우가 있고 가끔은 그보다 더 복잡한 경우가 있기도 하다. 이번 수정은 1)번과 같은 경우에 속했다.

CSSOMString 은 CSSOM(CSS Object Model) 에서 사용하는 String type 이다. CSSOMString 스펙에 따르면 CSSOMString 에 대한 실제 구현은 브라우저에서 USVString 이나 DOMString 중 하나를 선택하면 된다고 한다. Chromium 에서는 third_party/blink/renderer/core/css/cssom_string.idl 파일에 typedef DOMString CSSOMString 으로 선언되어 있어 IDL 에서 DOMString 을 쓰나 CSSOMString 을 쓰나 같은 것이었다. 그래도 스펙을 따르는게 맞으니 FontFace 에 선언되어있는 DOMString 을 CSSOMString 바꿔주었고, 수정 과정에서 발견한 FontFaceDescriptors 에 대해서도 같은 수정을 해주었다.

후기

오랜만의 contribution 이었기 때문에 간단한 수정으로 시작하였다. 앞으로 매주 꾸준히 할 수 있는 동력과 시스템을 만들고 싶다.

cpp-mini-chromium-template 프로젝트 소개

Mon, 29 May 2023 21:00:00 GMT

Chromium base 에는 Chromium 의 전반적인 핵심 기능과 유틸리티를 제공하는 코드가 있다. 공통으로 사용되는 유틸리티 함수, 데이터 구조, 도구, 플랫폼 지원 등과 같은 코드가 있는 일종의 C++ 라이브러리이다. C++ 최신 기능을 앞서 구현해서 사용하기도 하고 대체해서 사용하기도 한다. 상당히 고도화되어 있고 안정화되어있기 때문에 이쪽 코드를 분석하면 C++ 실력을 키우는데 상당히 도움이 될거라 생각한다. 유닛 테스트도 잘 되어있다.

하지만 Chromium 은 너무 큰 프로젝트이기 때문에 코드 다운로드와 빌드에 대한 장벽이 상당히 높다. 개인적인 경험으로는 리눅스가 그나마 편한데 그것도 쉬운 편은 아니다. base 분석 하나 때문에 리눅스를 설치하고 전체 코드를 받아 빌드하는 건 너무 큰 일이다.

이런 문제를 해결하기 위해서 그랬는지는 몰라도 Chromium 팀에서 mini_chromium 이라는 프로젝트를 따로 만들어 놓았다. mini_chromium 은 Chromium 에서 base 코드만 따로 떼어서 구성한 작은 프로젝트이다. 이를 활용하면 base 코드를 어느 정도 사용하고 분석할 수 있다. 빌드 환경이나 스크립트, 명령어 등은 Chromium 프로젝트와 거의 동일하다. 하지만 이 프로젝트를 받아서 코드를 구현할 수 있는 건 아니다.

이를 쉽게 하기 위해서 cpp-mini-chromium-template 이라는 프로젝트를 하나 만들었다. hello.cc, hello_static.cc 에 원하는 코드를 추가해서 테스트해볼 수 있다. 또 hello_test.cc로 googletest 도 돌려볼 수 있다. GitHub 에서 이 프로젝트를 템플릿 프로젝트로 선언해 놓았기 때문에 클릭 한번으로 이 프로젝트 기반의 신규 프로젝트를 만들 수도 있다. 실제로 개인적인 알고리즘 공부를 위한 프로젝트도 이 프로젝트 템플릿으로 만들어서 쓰고 있다.

환경 셋업 및 사용 방법은 아래 가이드를 따르면 된다.

Prerequisites

$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
$ export PATH=$DEPOT_TOOLS:$PATH

Sync

$ git clone git@github.com:amoseui/cpp-mini-chromium-template.git
$ cd cpp-mini-chromium-template
$ gclient sync

Build

$ gn gen out/Debug
$ ninja -C out/Debug hello

Run

$ ./out/Debug/hello

Test

$ gn gen out/Debug
$ ninja -C out/Debug hello_unittest
$ ./out/Debug/hello_unittest

Android 13 AOSP 빌드 및 cuttlefish 실행

Sun, 19 Mar 2023 00:50:00 GMT

개요

Ubuntu 20.04 환경에서 Android 13 버전 기준으로 AOSP 빌드를 하고 Cuttlefish 라는 가상 디바이스에서 실행하는 방법을 정리해보았다.

AOSP?

보통 Android Open Source Project 를 줄여서 AOSP 라고 부른다. 모바일 기기에 탑재되는 Android OS 는 보통 AOSP에 비공개 코드로 빌드된 여러 모듈과 레이어 + 구글 서비스 + 단말 업체의 수정, 앱, 서비스 등이 포함되어있다고 보면 된다.

AOSP는 오픈소스 프로젝트지만 개발 프로세스, 문서, 코드가 투명하게 모두 공개되어있는 커뮤니티 기반의 일반적인 오픈소스 프로젝트라고 보기는 어렵다. 공개된 repository 에 코드 반영이 가능하긴 하지만 대부분 보수적으로 운영되기 때문에 적극적인 contribution 이 쉽지 않다. AOSP gerrit 에 코드를 올릴 때 CI 빌드가 돌기는 하지만 결과 링크는 구글 내부 URL 이라서 접속을 할 수 없다. 구글이 내부적으로 신규 OS 개발을 1년동안 진행하고 정식 릴리즈 때에 AOSP 브랜치로 전체 merge 를 하는 방식으로 코드를 공개한다.

안드로이드 앱 개발자는 developer.android.com 웹사이트가 익숙한데 AOSP는 이 곳이 아닌 별도의 source.android.com 사이트에 플랫폼 개발자를 위한 문서를 제공한다. developer 사이트에 비해 내용이 많이 부족했지만 몇 년 사이에 리뉴얼도 하고 최신 내용도 많이 보충되었다.

Cuttlefish?

Cuttlefish 는 에뮬레이터와 비슷한 가상 환경의 안드로이드 디바이스 이름이다. (Cuttlefish 뜻은 갑오징어이다. 이 때문에 한국어 AOSP 사이트에는 ‘오징어 가상 Android 기기’로 이상하게 번역되어 있다.) 아래 링크에 에뮬레이터와의 차이점이 설명되어있다. 기존 에뮬레이터는 앱 개발을 쉽게 하기 위한 용도로 기능적으로 앱이 잘 실행될 수 있도록 후킹이 되어있는 부분이 있어서 플랫폼/프레임워크에 대한 적합성을 100% 보장하지 않는다고 한다. 반면 Cuttlefish 는 CTS(Compatibility Test Suite) 등을 돌릴 수 있을 정도로 HAL(Hardware Abstraction Layer)을 제외하면 실제 기기와 거의 동일한 순수 AOSP 플랫폼/프레임워크 기반의 디바이스라고 한다. AOSP 의 대표 공식 가상 환경으로 설명되어있다.

https://source.android.com/docs/setup/create/cuttlefish

Cuttlefish 는 기본적으로 웹 환경으로 제공된다. 웹페이지에 접속하여 기기를 실행한다. 로컬 환경에서 AOSP 코드를 빌드해서 직접 구동을 할 수도 있고 빌드된 이미지를 로컬 환경이나 클라우드 환경에서 구동할 수도 있다. 직접 돌려봤을 때는 에뮬레이터 대비 가벼운 느낌도 좀 있었다.

AOSP 빌드 방법

빌드 환경

빌드 환경 셋업은 아래 링크에 나와있는 그대로 따라했다. Ubuntu 20.04 를 사용하고 있는데 아래 링크에서 Ubuntu 18.04 와 동일하게 패키지를 설치하였는데 별 다른 문제는 없었다.

https://source.android.com/docs/setup/start/initializing

소스 다운로드 및 빌드

$ mkdir AOSP
$ cd AOSP
$ repo init --depth=1 -u https://android.googlesource.com/platform/manifest -b android13-gsi
$ repo sync -c --no-clone-bundle --no-tags -j$(nproc --all)
$ . build/envsetup.sh
$ lunch aosp_cf_arm64_phone
$ m

repo 는 빌드 환경을 위한 도구이다. AOSP 는 수십개의 repository 로 구성되어있으며 manifest 로 이를 관리한다. master 브랜치는 개발 중인 브랜치로 빌드나 디바이스 실행 등이 잘 안 될 수 있기 때문에 Android 13 의 안정화 버전이라고 할 수 있는 Generic System Image 를 위한 android13-gsi 태그로 코드를 받았다. 소스 싱크는 1~2시간 가량 걸렸다.

프로젝트가 워낙 크기 때문에 전체 git history 를 포함한 코드를 모두 받으면 디스크 용량이 부족할 수 있다. 다운받을 소스 코드를 최소화하기 위해 repo init, sync 시에 —depth=1, -c, —no-clone-bundle, —no-tags 옵션 등을 추가했다. 코드는 빌드로만 사용하고 히스토리 트래킹은 https://cs.android.com 이나 https://android.googlesource.com/ 를 참고하는 것이 낫다. 만약 contribution 이 필요한 경우 관련 project 만 따로 코드를 받는 것이 좋다.

repo init --help, repo sync --help 를 하면 사용할 수 있는 옵션을 볼 수 있다.

. build/envsetup.sh 으로 PATH 등의 빌드 환경을 잡고 lunch 명령어로 디바이스 타겟을 설정하여 빌드 준비를 한다. Cuttlefish 타겟을 위해 aosp_cf_arm64_phone 디바이스를 타겟으로 했다. lunch 명령어를 실행하면 아래와 같은 결과가 나온다.

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=13
TARGET_PRODUCT=aosp_cf_x86_64_phone
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_ARCH=x86_64
TARGET_ARCH_VARIANT=silvermont
TARGET_2ND_ARCH=x86
TARGET_2ND_ARCH_VARIANT=silvermont
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-5.15.0-67-generic-x86_64-Ubuntu-20.04.4-LTS
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=TP1A.220624.019
OUT_DIR=out
PRODUCT_SOONG_NAMESPACES=device/generic/goldfish-opengl device/generic/goldfish device/generic/goldfish-opengl hardware/google/camera hardware/google/camera/devices/EmulatedCamera device/google/cuttlefish/apex/com.google.cf.wifi_hwsim external/mesa3d vendor/google_devices/common/proprietary/confirmatioui_hal
============================================

마지막으로 m 명령어로 전체 빌드를 한다.

빌드 에러

빌드 에러가 간간히 발생했는데 무시하고 다시 m 명령어로 빌드를 몇 번 재시도했더니 결국 전체 소스 빌드에 성공했다. 빌드는 3~4시간은 걸린 걸로 기억한다.

rust 에서 빌드 중 segmentation fault 발생

[ 87% 161402/183718] //packages/modules/Virtualization/compos:compsvc rustc src/compsvc_main.rs [apex10000]
FAILED: out/soong/.intermediates/packages/modules/Virtualization/compos/compsvc/android_arm64_armv8-a_cortex-a53_apex10000/unstripped/compsvc

R8 에러

Error: java.lang.ClassCastException: class co m.android.tools.r8.graph.i1$g cannot be cast to class co[m.android.tools.r8.graph.o0](http://m.android.tools.r8.graph.o0) (co m.android.tools.r8.graph.i1$g and co[m.android.tools.r8.graph.o0](http://m.android.tools.r8.graph.o0) are in unnamed 
module of loader 'app')
Compilation failed with an internal error.

Cuttlefish 실행

https://source.android.com/docs/setup/create/cuttlefish-use

위 링크를 참고하여 Cuttlefish 를 설치했다.

$ sudo apt install -y git devscripts config-package-dev debhelper-compat golang curl
$ git clone https://github.com/google/android-cuttlefish
$ cd android-cuttlefish
$ for dir in base frontend; do
  cd $dir
  debuild -i -us -uc -b -d
  cd ..
done
$ sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
$ sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
$ sudo usermod -aG kvm,cvdnetwork,render $USER
$ sudo reboot

재부팅을 하면 빌드할 때 실행했던 build/envsetup.sh 로 지정된 PATH가 다 날아가므로 다시 실행을 해줘야 한다. (터미널을 새로 실행하거나 새 탭을 열 때도 마찬가지)

$ cd AOSP
$ . build/envsetup.sh
$ lunch aosp_cf_arm64_phone
# 실행
$ launch_cvd --daemon
# 종료
$ stop_cvd

launch_cvd 를 실행한 뒤 https://localhost:8443 에 접속하여 Devices 밑에 cvd-1 이 뜨는지 확인한다. 토글 버튼을 눌러 cvd-1 을 실행하면 디바이스가 부팅이 된다.

부팅된 Cuttlefish 화면

launch_cvd 를 실행했을 때 정상적인 경우 아래처럼 로그가 나오고

$ launch_cvd --daemon
===================================================================
NOTICE:

We collect usage statistics in accordance with our
Content Licenses (https://source.android.com/setup/start/licenses),
Contributor License Agreement (https://cla.developers.google.com/),
Privacy Policy (https://policies.google.com/privacy) and
Terms of Service (https://policies.google.com/terms).
===================================================================

launch_cvd I 03-19 00:29:01 75269 75269 main.cc:186] Host changed from last run: 0
assemble_cvd D 03-19 00:29:01 75657 75657 fetcher_config.cpp:212] Could not find file ending in kernel
assemble_cvd D 03-19 00:29:01 75657 75657 fetcher_config.cpp:212] Could not find file ending in initramfs.img
assemble_cvd I 03-19 00:29:01 75657 75657 config_flag.cpp:148] Launching CVD using --config='phone'.
assemble_cvd D 03-19 00:29:01 75657 75657 subprocess.cpp:335] Started (pid: 75660): /home/amoseui/Workspace/AOSP/out/host/linux-x86/bin/extract-ikconfig
assemble_cvd D 03-19 00:29:01 75657 75657 subprocess.cpp:337] /home/amoseui/Workspace/AOSP/out/target/product/vsoc_x86_64/boot.img
GPU auto mode: did not detect prerequisites for accelerated rendering support, enabling --gpu_mode=guest_swiftshader.
The following files contain useful debugging information:
  Serial console is disabled; use -console=true to enable it.
  Kernel log: /home/amoseui/cuttlefish/instances/cvd-1/kernel.log
  Logcat output: /home/amoseui/cuttlefish/instances/cvd-1/logs/logcat
  Launcher log: /home/amoseui/cuttlefish/instances/cvd-1/logs/launcher.log
  Instance configuration: /home/amoseui/cuttlefish/instances/cvd-1/cuttlefish_config.json
  Instance environment: /home/amoseui/.cuttlefish.sh

cvd-1 을 켜서 부팅에 성공하면 아래 로그까지 나온다.

Virtual device booted successfully
VIRTUAL_DEVICE_BOOT_COMPLETED

부팅이 안 되는 경우에는 kernel.log 나 launcher.log 의 내용을 확인해야 한다.

The following files contain useful debugging information:
  Serial console is disabled; use -console=true to enable it.
  Kernel log: /home/amoseui/cuttlefish/instances/cvd-1/kernel.log
  Logcat output: /home/amoseui/cuttlefish/instances/cvd-1/logs/logcat
  Launcher log: /home/amoseui/cuttlefish/instances/cvd-1/logs/launcher.log
  Instance configuration: /home/amoseui/cuttlefish/instances/cvd-1/cuttlefish_config.json
  Instance environment: /home/amoseui/.cuttlefish.sh

launcher.log 내용을 확인해보니 아래처럼 kvm (kernel-based virtual machine) 경로가 없다는 에러가 있었다.

run_cvd D 03-14 21:12:36 3458590 3458590 subprocess.cpp:337] /home/amoseui/Workspace/AOSP/out/target/product/vsoc_x86_64/bootloader
openwrt D 03-14 21:12:36 3458613 3458613 log_tee.cpp:75] `--seccomp-policy-dir=/home/amoseui/Workspace/AOSP/out/host/linux-x86/usr/share/cuttlefish/x86_64-linux-gnu/seccomp` is deprecated, please use `--seccomp-policy-dir /home/amoseui/Workspace/AOSP/out/host/linux-x86/usr/share/cuttlefish/x86_64-linux-gnu/seccomp`
openwrt D 03-14 21:12:36 3458613 3458613 log_tee.cpp:75] [2023-03-14T21:12:36.663845565+09:00 ERROR crosvm] kvm path "/dev/kvm" does not exist
run_cvd I 03-14 21:12:36 3458590 3458590 process_monitor.cc:118] Detected unexpected exit of monitored subprocess /home/amoseui/Workspace/AOSP/out/host/linux-x86/bin/crosvm
run_cvd I 03-14 21:12:36 3458590 3458590 process_monitor.cc:120] Subprocess /home/amoseui/Workspace/AOSP/out/host/linux-x86/bin/crosvm (3458640) has exited with exit code 1

sudo kvm-ok 로 kvm 을 확인해보았더니 BIOS 에서 disable 되어있어서 안된다는 메시지를 나왔다.

$ sudo kvm-ok
INFO: /dev/kvm does not exist
HINT:   sudo modprobe kvm_amd
INFO: Your CPU supports KVM extensions
INFO: KVM (svm) is disabled by your BIOS
HINT: Enter your BIOS setup and enable Virtualization Technology (VT),
      and then hard poweroff/poweron your system
KVM acceleration can NOT be used

AMD 라이젠 GIGABYTE 기준, 부팅 화면에서 BIOS 설정으로 들어가서 M.I.T > Advanced Frequency Settings > Advanced CPU Core Settings > SVM Mode 을 enable 한 뒤, 아래 명령어를 실행하다보니 부팅이 됐다. (바로 기록한 것이 아니라 순서나 내용이 정확하지 않을 수 있음)

$ sudo modprobe kvm_amd
$ sudo apt install -y qemu qemu-kvm libvirt-daemon libvirt-clients bridge-utils virt-manager
$ ls -al /dev/kvm
$ sudo usermod -aG kvm,cvdnetwork,render $USER
$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

2022년 회고

Sat, 31 Dec 2022 09:00:00 GMT

오랜만에 한 해 회고를 남긴다.

개인적으로 오픈소스 프로젝트 활동, 컨퍼런스 발표가 엄청 큰 이벤트였고, 성장할 수 있는 기회가 됐다.

오픈소스 프로젝트 활동

3년 만에 Chromium 프로젝트 컨트리뷰션을 다시 시작했다. 2018년부터 2019년 초까지 committer 를 목표로 달리다가 결국 목표를 달성하지 못하고 부서를 옮기면서 그만 뒀었다. 오픈소스 컨트리뷰션을 그만 뒀다가 다시 시작하는 건 어려우면서 두려운 일인데 봄에 그 어려운 걸 이겨낼 수 있는 동기가 생겨 다시 시작할 수 있었다. 6월부터 5개월 간 주로 Web Authentication W3C 스펙과 관련한 수정을 했다. 11월에는 컨퍼런스 발표 준비, 코로나 감염으로 고생하면서 쉬었고 12월까지 아무런 패치를 하지 못 했다. 올해 반영한 패치 수는 10개. 6월에 다시 시작하면서 올해 목표를 committer 로 잡았었는데 결국 달성하지 못 했다. 개인적인 기준으로는 아주 조금만 더 반영하면 가능할 것 같은데 그게 너무 어렵다. 다시 힘을 내서 2023년 1분기 안에 committer nomination 요청을 해 볼 계획이다.

오픈소스 컨트리뷰션을 하면서 기대하지 않았던 두 개의 보상이 있었다.

하나는 구글에서 구글이 주도하는 오픈소스 프로젝트에 기여한 외부 개발자에게 상과 상금을 주는 Open Source Peer Bonus 프로그램의 Winner 로 선정된 것이었다.

The Google Open Source Peer Bonus program is designed to recognize external open source contributors nominated by Googlers for their open source contributions. This cycle, we are pleased to announce a total of 141 winners across 110+ projects, residing in 36 countries.

Announcing the second group of Open Source Peer Bonus winners in 2022 | Google Open Source Blog

아무도 신경쓰지 않던 오래 된 이슈를 맡아 관련 W3C Spec 과 Web Platform Tests 를 직간접적으로 정리하게 되었는데 구글 리뷰어가 이를 좋게 보고 추천해준 것이었다. 상장 문서와 함께 250 달러를 상금으로 받았다.

다른 하나는 회사에서도 오픈소스 컨트리뷰션에 대한 보상을 받은 일이다. 최근 1~2년 사이에 회사에서 오픈소스 개발자를 대우해주려는 몇 가지 보상 제도가 생겼다. 가을에도 하나가 생겼는데 조건이 딱 맞아 보상을 받을 수 있었다. 이걸 기대하고 시작한 건 아니었는데 운이 좋았다.

컨퍼런스 발표

회사 컨퍼런스에서 발표를 했다. 타의 반, 자의 반으로 하게 됐다. 막상 발표를 준비해보니 고려해야할 것이 너무 많았다. 나 혼자 한 일이 아니라 많은 사람들이 다 같이 한 일을 회사와 부서를 대표해서 발표하는 것이 정말 큰 부담이었다. 특히 내가 잘 모르는 기술에 대한 내용과 저작권, 초상권, 기술 공개 범위를 고려하여 자료를 만드는 것이 가장 큰 스트레스였다.

처음에는 모든 것이 막막해서 발표 준비를 시작하는 데까지도 시간이 많이 걸렸다. 고민을 하다가 발표 자료를 글로 먼저 썼는데 이게 크게 도움이 됐다. 개요를 짜고 설명을 완성된 문장으로 풀면서 흐름을 정리했다. 보통 러프하게 글을 써 놓으면 ppt 슬라이드도 미완성 형태로 옮기게 되는데, 최대한 완성된 형태의 글을 적어놓았더니 슬라이드도 하나하나 금방 완성할 수 있었다. 본격적으로 ppt 를 만들기 전에는 작성한 마크다운 문서를 GitHub PR 로 올리고 관련 부서원들에게 리뷰를 먼저 받았다. ppt 를 만들기 전에 글로 발표 방향과 내용에 대한 피드백을 먼저 받으면, ppt 형태로 처음 피드백을 받았을 때보다 쉽게 피드백을 반영하고 정리할 수 있는 장점이 있다. 물론 이렇게 해도 발표 리허설 등을 하면서 받은 피드백을 반영하기 위해 발표 자료를 수정할 일이 생긴다.

발표를 준비하면서 발표 내용을 컨퍼런스와 관련이 없는 다른 매체에 글 형태로 외부 공개를 하도록 요청을 받았다. 발표 준비를 하면서 작성해놓은 글이 있었기 때문에 조금만 수정하고 바로 외부 페이지에 배포를 할 수 있었다. 조회수는 1,000회 정도 나왔는데 같은 페이지의 다른 주제에 비해서는 높게 나온 편이라 뿌듯하다.

발표는 배정받은 시간이 오후 늦은 시간이기도 했고 개발 컨퍼런스에서 관심도가 높은 주제가 아니었기 때문에 생각한 것보다 청중은 많지 않았다. 그래도 긴장을 해서 모니터를 보고 스크립트를 읽으면서 발표를 했다. 아직은 발표 영상을 다시 보고 분석할 용기가 나지 않는다. 아마 다음에 이런 기회가 또 생기면 준비를 위해 볼 수 있지 않을까.

회사

9년차, 부서를 이 쪽으로 옮긴지는 이제 만으로 3년이 되어 간다. 이 곳의 업무와 업무 프로세스는 아직도 어렵다. 고민을 많이 하고 있다. 여전히 효율적으로 일하는 방법을 찾기 위해 노력하고 있다. 갈수록 문서화에 대한 중요성을 느끼고 있다. 자체적인 프로세스라도 만들어서 문서화와 자동화를 하고 불필요한 업무를 줄여 업무에 집중하고 재미있게 일하기 위해 노력하려고 한다.

Code Coverage Best Practices

Wed, 09 Dec 2020 22:00:00 GMT

지난 8월 Google Testing Blog 에 올라왔던 Code Coverage Best Practices 를 보고 간단히 정리해 보았다.

위 블로그 내용을 100% 이해하지는 못 했지만 대부분 동의한다. 구체적인 예시는 없지만 Code Coverage 에 대한 생각을 정리하기 위한 용도로 재해석했다.

Code Coverage 의 의미

테스트를 통해 Code Coverage 를 측정하는 것은 개발 프로세스에서 도움이 된다. 하지만 이 수치에 집착해서는 안 된다. Code Coverage 는 테스트를 정량화하여 측정할 수 있는 유일한 방법이 아니며 완벽한 방법도 아니다. 높은 수치의 Code Coverage 는 좋은 코드의 퀄리티를 보장하지 않는다. 라인이나 브랜치가 커버되었다고 해서 해당 코드가 제대로 테스트 되었다는 걸 보장하지 않기 때문이다. 단순히 테스트로 실행이 되었다는 것을 전제로 하고 확인을 해야 한다. 반대로 커버되지 않는 부분을 확인하고 개선하는데 힘을 쓰는게 중요하다.

Code Coverage 기준

모든 프로젝트에 통용되는 이상적인 Code Coverage 수치는 없다. 하지만 팀 내에서 기준을 잡고 목표를 만드는 것이 좋다. 구글에서는 60% acceptable, 75% commendable, 90% exemplary 을 기본적인 가이드 라인으로 정하고 있지만 모든 프로젝트에 필수적인 조건으로 적용하고 있지는 않다. Code Coverage 의 수치와 비용의 관계는 로그 함수 그래프와 같아서 수치가 높아질수록 수치를 그 이상으로 올리기 어렵다. 따라서 90% 에서 95% 로 올리는 것에 집착해서는 안된다. 30% 에서 70% 로 올릴 때는 구체적인 프로세스와 기준을 통해 새 코드가 기준을 만족하는지 확인하면서 프로젝트를 진행하는 것이 좋다. 수치가 낮고 개선하기 어려운 레거시 프로젝트라도 보이 스카웃 규칙(캠프장을 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.)을 기억하고 점진적으로 개선하면 좋아질 수 있다.

Code Coverage 의 활용

Code Coverage 를 장기간동안 올리려는 노력은 결함을 줄이는데 도움이 된다. 낮은 Code Coverage 수치는 프로젝트의 많은 부분이 테스트되지 않으면서 진행되고 있다는 걸 알 수 있는 지표가 된다. 코드 리뷰 단계에서 Code Coverage 를 확인하면 리뷰 프로세스를 좀 더 빠르고 쉽게 만들 수 있다. 리뷰어는 수치 뿐만 아니라 어느 라인이 추가로 커버되었는지 확인할 수 있다. 특히 자주 수정되는 코드는 테스트로 커버되도록 해야 한다. 수정할 때마다 수치가 낮아지지 않도록 하면서 코드와 테스트의 품질을 올릴 수 있다. 패치마다 델타를 확인하여 기준에 충족하지 않는 반영과 배포를 차단할 필요가 있다. 통합 테스트에 대해서도 측정을 하는 것이 좋다. 유닛 테스트에서 놓치고 있는 부분을 확인할 수 있다.

Hacktoberfest 2018 후기

Fri, 28 Dec 2018 22:00:00 GMT

2018년 Hacktoberfest 에 참여했다.

Hacktoberfest 는 Digital Ocean 에서 github 과 함께 매년 10월에 주최하는 행사이다. 올해가 다섯번째라는데 여지껏 몰랐다가 10월 중에 알게 되어 등록을 하고 참여하게 되었다.

Hack 과 October 의 합성어인만큼 10월 중에 조건을 충족하면 기념 티셔츠를 보내준다. 올해는 github 오픈소스 프로젝트에 Pull Request 5개를 채우면 되었다. 선착순 제한도 있는 것 같고 PR 의 퀄리티도 따지는데 이 부분은 어떻게 확인하는지 모르겠다. 개인은 등록만 하면 알아서 PR 카운트가 되었던 것 같고, 그 후엔 사용자의 진행 상태를 볼 수 있다. 당시 보여주던 링크는 시간이 지나 지금은 볼 수가 없다. 대신 누군가가 웹페이지를 따로 만들어서 각 개인의 PR 내용을 볼 수 있다.

10월에 개인적으로 몇몇 프로젝트에 참여하면서 생각보다 쉽게 5개를 채웠다. 행사를 알기 전 마침 deno 라는 typescript runtime 플랫폼 프로젝트에 세 차례 PR을 보낸 적이 있어 이게 자연스럽게 카운트가 되었다.

또 conferences 라는 전 세계 안드로이드 개발 행사를 보여주는 작은 프로젝트(무려 Jake Wharton이 운영하고 있다.)에 올해 11월에 우리나라에서 각 지역 채널에서 열리는 gdg devfest 일정 정보를 추가하면서 한 차례 PR을 하게 되었다. 몇 년 전에 기여했던 경험이 있어서 쉽게 반영 할 수 있었다.

나머지 하나는 이 blog 에 대한 PR이었다. 블로그를 CI 를 통해 업데이트를 하기 위해 PR을 만드는데 이게 인정이 된 것이다. 자신의 프로젝트도 인정되는지 몰랐다.

행사가 끝난 후 확인 후 배송 정보를 입력하였고, 약 두 달 만에 티셔츠와 스티커를 받을 수 있었다. 실제 배송은 12월 6일에 되었고 DHL을 통해 배송되어 12월 28일에 받았다.

내년 10월에는 행사와 상관없이 적극적으로 참여하고 있는 오픈소스 프로젝트가 있어서 의식하지 않고 자연스럽게 참여하고 싶다.

Droid Knights 2017 후기

Tue, 03 Oct 2017 13:08:05 GMT

3월 25일 토요일, DROID KNIGHTS 라는 안드로이드 기술 컨퍼런스에 다녀왔다. 근 7개월 만에 후기를 남긴다. 개인 노트에는 어느 정도 정리를 해뒀었는데 블로그에 올리는데 부담을 느껴 미루다보니 이제서야 올리게 되었다.

드로이드 나이츠는 ‘오직 안드로이드 개발자들을 위한 수준있는 독립 컨퍼런스’라는 이름으로 올해 처음으로 열리는 안드로이드 컨퍼런스다. 구글에서 주최하는 GDG Korea Android Conference 가 매년 열리고 있는데 이 외에 회사에서 주최하지 않는 안드로이드 기술 컨퍼런스는 내가 알기로는 처음이다. 앞으로도 매년 개최할 계획이 있는 것 같다. 국내에 안드로이드 개발자가 많은데 규모가 더 커져 세션 수도 늘어나고 트랙도 늘어나서 안드로이드 개발자들의 축제가 되면 좋겠다.

SESSION

등록
- 시작 시간보다 여유있게 가서 금방 등록을 마쳤다. 참가비 3만원으로 온오프믹스를 사전 등록을 해야 한다. 머그컵, 티셔츠, 스티커, 스폰서 기업 홍보 책자, 소품 등을 기념품으로 받았다. 스폰서 기업은 구글, 레진코믹스, 스마트 스터디, 이브레인 등에서 대회의실 앞에 각각 책상 한개 규모로 부스를 열었다. 카페 업체에서 무료 커피 지원도 있었다.
오프닝
- 이 행사를 어떻게 열게 되었는지, 어떻게 진행할 것인지 간략한 소개를 하였다. 일본의 드로이드 카이기와 같은 안드로이드 컨퍼런스를 우리나라에서도 열겠다는 생각으로 시작했다고 한다. 파이콘 운영진이나 GDG Korea Slack 등 온오프라인에서 많이 볼 수 있는 분들이 주를 이루어 준비하고 운영하는 것으로 보였다.
Compose everything with rx & kotlin
- 요즘 많이 사용하고 있는 Rx와 Kotlin을 어떻게 적용하고 사용하고 있는지에 대한 발표였다. Rx와 Kotlin 모두 익숙하지 않아 발표 자료에 있는 샘플 코드들이 Rx의 특성인지 Kotlin의 특성인지 구분하기 어려웠고 이해도 쉽지 않았다. RxJava라고 설명을 하면서 샘플 코드는 Kotlin인 경우가 많아서 그랬던 것 같다. 이해하기 어렵다보니 이런 방향이 도대체 얼마나 좋은 코드인지, 이게 앞으로 나아갈 방향인지 조금 의문이 들었다.
Some OK Practices in Android Development
- 뱅크샐러드를 개발하는 레이니스트 CTO 님의 발표였다. 사전에 공지된 제목과는 다른 제목으로 발표가 진행되었다. 현재 유행하는 안드로이드 기술, 라이브러리 등을 사용하면서 엉클 밥의 클린 아케텍쳐를 어떻게 적용했는지 각 레이어에 대한 발표였다. 큰 그림부터 세세한 부분까지 설명을 했는데 레이어를 저렇게 많이 쪼개야할 필요가 있나 싶기도 했지만 잘만 운영된다면 좋은 방향인 것 같다.
안드로이드 스튜디오 플러그인 만들어보기
- 기대한 내용과는 다른 내용이었다. 안드로이드 OS 개발에는 적절한 IDE가 없기 때문에 직접 플러그인을 만들었다고 하고 InteliJ Plugin 개발을 어떻게 하는지에 대한 설명이었다. 플러그인을 개발하기 위해 제공되는 것들이 생각한 것보다 불친절하다고 하였고 이를 어떻게 해결했는지에 대한 내용이 주였다.
점심시간
- 죠샌드위치, 써브웨이 샌드위치 중 하나를 받아서 먹을 수 있었다. 먹을 곳은 따로 없어서 회의실 앞 공간에서 대부분 서서 먹었다. 음료는 따로 없었고 마약 커피라고 해서 조그만 플라스틱 컵에 아이스 커피를 먹을 수 있었다. 생수 500ml 한병씩 제공되었으면 좋겠다는 생각이 들었다.
Firebase를 실제 모바일 백엔드로 사용 했을때 생기는 일들
- Firebase를 메인 백엔드 솔루션으로 사용할 때 겪었던 문제를 주로 발표하려고 했으나, 발표 하기 몇주전에 새로운 기능들이 소개되면서 어느 정도 해결이 되었다고 한다. 그래도 흥미로웠고 재밌는 발표가 많았다.
Firebase Remote Config로 배포없이 앱 운영하기
- Firebase Remote Config을 어떻게 사용하는지 설명과 실제 예제, 실습을 하는 간단한 발표였다. 마지막 부분에는 명함 관리앱 리멤버에서 실제로 어떻게 사용하고 있는지 간략하게 보여줘서 좀 더 와닿는 발표였다. 잘만 사용하면 활용할 곳이 많아 보였다.
빠르고 지속적으로 전달하기: Continuous Delivery for Android
- 캐시슬라이드를 개발하는 엔비티에서 Android Continuous Delivery에 대한 고민과 역사를 들을 수 있었다. 관심이 많은 부분이라 흥미로웠다. Android를 개발할때 github에 붙여 사용해 본 Travis-CI, Circle-CI가 각각 아쉬운 점이 있었는데 내가 느낀 것과 비슷한 부분도 많았다. 현재는 bitrise를 이용한다고 한다.
UiAutomator와 AWS Device Farm 을 활용한 UI 테스팅 자동화
- 스타트업 ‘숨고’에서 UI 테스트를 하고 있는 방법에 대한 내용이었다. UI 테스트는 결국 얼마나 많고 다양한 디바이스에서 안정적으로 테스트를 할 수 있는지가 관건인데 이를 제공하는 AWS Device Farm이 현재로선 끝판왕으로 보였다. UI 테스트를 위한 UIAutomator 2에 대한 세세한 설명과 시행착오 등이 발표 내용이었다.
Anatomy of Realm (Realm 심층 분석)
- Realm을 잘 모르다보니 내용을 이해하기 너무 어려웠다. 특히 이 발표 때에만 프로젝터 연결에 문제가 많아서 두 차례 정도 중단이 되어 흐름을 잘 이어가질 못 했다.
KeyFrame과 Lottie로 인터렉티브한 애니메이션을 구현해보기
- facebook에서 만든 KeyFrame과 Airbnb에서 만든 Lottie 를 소개하고 결국 많은 기능이 있는 Lottie를 사용해보았다며 어떻게 쓰는지 샘플을 보여주고 설명하였다. Adobe After Effects로 일단 작업을 하고 이를 벡터 방식으로 변환하여 각 모바일 플랫폼마다 사용할 수 있게 해준다. 아직은 초기 단계여서 그런지 리소스, CPU 문제 등이 있어 약간의 한계가 있지만 흥미로운 내용이었다.
경품추첨
- LG G Watch, 레오폴드 키보드, 안드로이드 피규어 등 여러 경품이 걸린 추첨을 진행했다. 경품 추첨 때문인지 많은 사람들이 남아있었고 즐겁게 마무리될 수 있었다.

좋았던 점

안드로이드 독립 컨퍼런스라는 것 자체가 가장 좋은 점이었다. 국내 안드로이드만을 위한 컨퍼런스가 많지 않고 기업이랑 상관없이 독립적으로 열리는 컨퍼런스는 이번이 처음이기 때문이다. 다양한 기업과 다양한 개발자들로부터 많은 영감을 얻을 수 있는 기회였다.

아쉬운 점

Realm 사이트를 통해 동영상과 발표 자료를 같이 올리려다보니 발표 슬라이드와 발표가 공유되는데 시간이 꽤 걸렸다.

행사 중에 진행했던 설문조사

내년에도 열리길 바라고 또 참석하고 싶다.

2016년과 2017년

Sun, 01 Jan 2017 18:20:22 GMT

다사다난했던 2016년이 지나고 2017년이 시작됐다.

항상 연말이 되면 일찌감치 그 해의 아쉬움 때문에 다음 해에 대한 이런저런 생각을 한다. 그리고 구체적인 계획을 짜기 위해서 매해 세웠던 목표와 결산을 찾아본다. 지금은 작년에 썼던 2016년의 목표, 아직 정리 중인 2017년의 목표, 그리고 1년 전 블로그에 남긴 2015년과 2016년이라는 글을 보면서 이 글을 쓰고 있다.

충격적이었다.

최근 3년간 별 차이 없는 목표를 세우고 있다는 사실도 놀라웠지만 더 놀라웠던 것이 있었다. 작년에 썼던 글의 앞 뒤의 두 문단을 다시 이어 붙이면 오늘 쓰려고 했던 글이 되기 때문이다.

2015년, 여러모로 아쉬운 한 해였다.

특별히 남긴 것 없이 일년을 보내지 않았나 싶다. 연말이 되어가면서 머리 속으로 생각했던 다음 해 계획은 대부분 연초에 세웠던 계획과 별 차이가 없었다. 그 사실을 바로 깨닫는 순간 바로 2015년은 망한 해구나라는 걸 느꼈다.

…

2016년이 앞으로의 인생을 결정지을 중요한 시점이 될 것이다. 건강을 우선으로 하고, 글 쓰는 능력, 말하는 능력을 향상 시키길 원한다. 소프트웨어 개발의 기본을 키우는 기간이 되길 바란다. 앞서 말했듯이, 정리를 빨리 끝내고 그 위에 내 자신을 쌓아 진화하는 한 해가 되었으면 한다.

올해도 똑같다. 2016년을 인생에서 중요한 해라고 했지만 그렇게 시간을 보내진 못 했다. 개인적인 발전을 위한 목표는 거의 이루지 못했다. 결국 매년 같은 생각을 하면서 지키지 못 하고 발전이 없는 상태로 1년 뒤 똑같은 생각과 말을 반복하고 있는 것이다.

그래도 올해는 조금 더 나은 조건에서 시작한다는 생각이 든다. 생산성에 대한 고민으로 자신만의 체계를 잡아가면서 작년보다 더 정리된 상태로 새해를 맞게 되었기 때문이다. 이 틀 안에서 많이 읽고, 많이 쓰면서 기록을 남기는 것이 2017년 나의 목표이다.

올해 12월 31일에는 2017년에 대한 자세한 회고를 부끄럽지 않게 남길 수 있길 바란다.

DEVIEW 2016 DAY 2 후기

Wed, 26 Oct 2016 00:36:10 GMT

올해 처음으로 네이버에서 주최하는 DEVIEW 를 다녀왔다. 예전부터 가고 싶었지만 수업 또는 출근 때문에 생각조차 안하고 있었다. 올해도 그렇게 지나가나 싶었지만 회사에서 2일차 티켓이 남는다는 소식을 듣고 재빨리 손을 들어 갈 수 있게 되었다.

2008년 처음 외부 공개 컨퍼런스가 된 이후 시간이 제법 흘러 이번이 아홉번째 DEVIEW 라고 한다. 작년 세션을 자세히 살펴보지는 않았지만 파이콘과 마찬가지로 딥러닝 주제가 예년보다 늘어난 것 같다. 국내에서 최대라고 볼 수 있는 데이터를 가지고 있는 네이버이기 때문에 이를 어떻게 활용하고 있는지 공유하는 자리가 많았다.

1일차 세션이 좀 더 업무과 연관된 내용이 많아 아쉬웠다. 유일하게 참석해 본 컨퍼런스인 파이콘에 비교를 해보자면 회사가 주최하는 컨퍼런스이고 규모가 큰 회사에서 실제로 사용하고 있는 서비스에 대한 내용이 주를 이루기 때문에 좀 더 전문적이고 진지한 분위기가 주를 이루었다. 이는 주로 네이버 소속 개발자 분들의 세션을 들어서 그렇게 느낀 것일 수도 있다.

전문 지식이 없는 수준이라 이해를 거의 하지 못 했지만 기록을 위해 간단한 소감을 남긴다.

나는 서버를 썰 터이니 너는 개발만 하여라
- Zinst 를 주제로 한 세션이었다. 조금 늦게 도착하여 앞부분 내용을 놓쳤는데 발표 자료를 다시 보니 예전에 Yahoo Korea 에 다닐 때 잘 썼던 Yinst 의 컨셉을 기반으로 만들었다고 한다. 개발자들이 개발을 편하게 하기 위한 DevOps 도구로 개발 환경에서 서버 구성을 편하게 하고 개발자들이 직접 배포도 할 수 있다. Bash로 제작되었다는 것이 신기한 부분이었다.
딥러닝을 활용한 이미지 검색: 포토요약과 타임라인
- 여기서 말하는 이미지 검색은 이미지로 검색을 하는 것이 아닌 텍스트로 이미지를 검색하는 걸 얘기한다. 네이버에서 검색을 했을 때 딥러닝 기술을 통하여 이미지들이 어떤 방식으로 보여지는지 공유하였다. 포토 요약과 타임라인 두 개의 서비스에 대해 각각 발표가 진행되었다. 특히 이미지 타임라인에 대한 내용이 흥미로웠다. 특정 연예인을 검색했을 때 이 연예인의 사진을 이벤트 별로 정리하고 사용자에게 보여주는 서비스였다. 이벤트 별로 정리되는 것은 당연하고 적당한 양의 사진이 최대한 비슷하지 않은 사진들로 다채롭게 보이게 하는 것이 서비스의 목표였다. 당연한 것이지만 생각없이 보던 사진들에도 내부적으로는 다양한 기술이 쓰이고 있다는 점을 다시 깨닫게 되었다.
Kaleido 비긴스: 세계 최초 데이터타입 기반의 동기화 Back-end as a Service
- 네이버에서 만들고 있는 BaaS 플랫폼인 Kaleido 에 대한 내용이었다. BaaS 인 만큼 멀티플랫폼 상태의 동기화에 대한 고민이 많이 느껴졌다. 데이터 타입을 operation 단위로 동기화하는 것이 특이점이며 Parse, Cognito, Firebase 의 특징과 비교하며 앞으로의 발전 가능성까지 발표하였다. 발표와는 별개로 Firebase 를 제대로 써 봐야겠다는 생각이 들었다.
Backend 개발자의 Neural Machine Translation 개발기
- 기계 번역을 주제로 발표하였다. 자체 기술로 개발한 기계 번역 시스템으로 성능이 많이 좋아졌고 블라인드 테스트에서도 좋은 결과를 얻어 성과를 얻고 있다고 한다. 네이버에서 출시한 번역 앱인 Papago 도 이 엔진을 사용하고 있다. 마지막에는 10년 동안 백엔드 개발자였던 발표자가 딥러닝 분야로 넘어오면서 느낀 점을 공유하였다. 기존 개발자도 노력하면 진입할 수 있는 분야지만 꼼꼼한 성격이 요구되고 인내심이 필요한 분야라고 하였다. 각각의 주특기를 가진 사람들이 모여 팀을 이루어 강력한 팀이 되어 좋았다고 한 점이 부러웠다.
네이버 콘텐츠 통계서비스 소개 및 구현 경험 공유
- 밖의 부스에서 시간을 보내느라 앞부분을 조금 놓쳤다. 네이버 콘텐츠 통계 서비스를 위한 로그와 데이터를 어떤 아키텍쳐로 어떤 방식으로 처리하고 있는지 공유하였다. 온갖 관련 기술을 다 조사하고 삽질하면서 구축한 것 같았고 발표자도 쉽지 않은 과정이었기 때문에 이런 유용한 경험들이 좀 더 공유되었으면 한다는 말로 발표를 마쳤다.
딥러닝 예제로 보는 개발자를 위한 통계
- 왠지 네이버에서 좀 높은 직책에 있는 분 같았는데 머신 러닝을 오래 전부터 공부했다는 것을 강조했다. 2012년 뒤늦게(?) 딥러닝을 처음 시작했을 때 했던 착각과 이해하지 못 했던 블랙박스들을 통계학을 공부하고 접목해보면서 Breakthrough 로 만들 수 있었다고 한다. 자신만의 방식으로 통계학을 다시 정리하고 이를 어떻게 적용할 수 있을지 고민하는 내용이 많이 담겨있었다.

아쉬운 점

관련 기술 기초를 모르니 어려웠다.
알아도 어려웠을 것이다.(?)
조금 의도하긴 했지만 결국 네이버 세션만 들어갔는데 굳이 그럴 필요는 없었다.
다른 회사들 세션은 파이콘과 조금 겹쳐서 안 들어간 점도 있다.
그래도 다양한 주제에 대하여 자극이 될 수 있고 다른 레이어와 사람들, 회사를 통해 자극이 되는 시간이었다.
또 기회가 된다면 내년에도 오고 싶다.

PyCon APAC 2016 후기

Tue, 16 Aug 2016 23:50:02 GMT

작년에 이어 올해에도 PyCon(이하 파이콘)을 다녀왔다. 국내 개최 3회 만에 올해는 아시아-태평양 지역을 대상으로한 PyCon APAC으로 개최하여 1,500명이 넘는 참가자와 함께 최대 규모로 진행되었다. 국제 행사로 열린만큼 ‘Respect, Diversity’라는 주제로 존중과 다양성을 강조하였다.

파이썬을 주 개발 언어로 사용하고 있진 않지만 필요한 툴이 필요할 때 유용하게 쓰고 있어 이 언어에 대한 관심이 항상 많아 작년부터 참석하고 있다. 대규모 개발 컨퍼런스는 파이콘 외에 참석해 본 경험이 없기 때문에 다른 컨퍼런스와 비교하긴 어렵다. 언어 관련 비영리 컨퍼런스답게 좀 더 자유롭고 젊은 분위기가 있다고 생각된다. 스폰서 기업의 지원과 개인 후원금, 참가비 등으로 운영되기 때문에 자원 봉사자들을 포함한 운영진의 컨퍼런스에 대한 열정 또한 느껴졌다.

작년과 가장 큰 차이점은 딥러닝 관련 주제가 눈에 띄게 늘었다는 것이었다. 딥러닝에 대해서는 잘 모르지만 1년 사이에 TensorFlow 등의 기술이 오픈되고 보편화되면서 생긴 변화로 보인다.

메모는 거의 하지 않았고 기억력에 의존한 내용이기 때문에 틀린 내용이 있다면 꼭 지적해주셨으면 좋겠다.

첫째날

Wes McKinney 키노트
- ‘파이썬 라이브러리를 활용한 데이터 분석’ 저자로 pandas를 만든 개발자이다. 수학자 출신인 자신이 어떻게 pandas를 시작하게 되었는지부터 현재 개발에 참여하고 있는 Apache Arrow 등 여러가지 이야기를 하였다. 특별히 메모를 하지 않았고 발표 자료도 올라와있지 않아 자세한 내용이 기억나지 않는다.
Jacob Kaplan-Moss 키노트
- Django의 공동 창시자라고 한다. 갑작스런 일 때문에 우리나라에 오지 못했고 발표라기 보다는 자신이 얘기하는 것을 비디오를 찍어 보내줬다. 밖에 나갔다 와서 앞부분도 놓쳤고 특별히 기억나는 내용도 없었다.
Deep Learning with Python & TensorFlow
- 발표자는 일본 구글 개발자로 작년에도 파이콘에 왔던 걸로 기억한다. 딥러닝과 TensorFlow, 클라우드 머신 러닝에 대한 개괄적인 발표를 하였다.
TOROS: Python Framework for Recommender System
- 카카오에서 파이썬으로 개발한 추천 시스템에 대한 발표였다. 카카오에서는 수 많은 서비스에서 사용자에게 컨텐츠를 추천해주고 있다. 이를 위한 프레임워크를 파이썬으로 개발을 하면서 겪었던 이야기를 하였다. 파이썬의 큰 강점으로 C/C++ 라이브러리와의 호환을 들었고 파이썬 자체의 성능에 대해서는 큰 문제가 없다고 말하며 만약 있다면 개발자도 의심해 봐야한다고 했다. caching에는 서버 리소스를 크게 투입하지 않아도 잘 운영하고 있다고 했으며 RocksDB를 강력히 추천하였다. 실서비스를 하고 있는 카카오의 발표여서 그런지 첫째날 발표 중에서는 가장 인상깊었다.
뉴스를 재미있게 만드는 법; 뉴스잼
- 뉴스잼 서비스를 만들었던 경험을 토대로 데이터 수집, 분석, 전달에 대하여 발표하였다. 각 단계별로 겪었던 시행착오와 사용했던 라이브러리를 일일이 설명해주었다. 정말 기본적인 내용이어서 모르는 사람이 나중에 비슷한 작업을 해야될 때 도움이 될만한 내용이 많았다.
파이썬으로 광고 효과 측정하기
- 하이퍼커넥트에서 사용하는 광고 플랫폼들의 광고 효과를 측정하고 분석, 시각화하는 방법에 대한 발표였다. 광고로 인하여 설치를 할 수는 있지만 환경에 따라 실제로 실행해서 사용하지 않는 경우도 많다고 한다. 자세한 내용은 관련 지식이 없어 조금 어려웠다.
기계학습을 활용한 게임 어뷰징 검출
- 게임 내 어뷰징 유저 검출을 위하여 딥러닝을 사용한 경험에 대한 발표였다. 처음에는 통계적인 방법으로 검출을 하였으나 오탐의 가능성이 있었고 최종적으로 딥러닝을 도입하였다. GM과 상의하면서 데이터와 알고리즘, 피쳐별 중요도를 조절하여 개선했다는 내용이었다.

둘째날

키노트는 듣지 않았고 근처에서 점심을 먹고 오후 세션부터 참석하였다.
RPC 프레임워크 제작 삽질기
- 스포카에서 개발 중인 RPC 프레임워크 ‘니름’에 대해 발표하였다. Thrift, Cap’n Proto 등 현존하는 RPC 프레임워크와 스포카의 서비스가 잘 맞지 않아 직접 개발하고 있다는 내용이었다. RPC 프레임워크를 잘 몰라 약간 어려웠다.
검색 로그 시스템 with Python
- 카카오에서 사용하는 로그 시스템에 대한 발표였다. 검색 로그 등을 정제해서 다시 각 서비스에 리턴해주는 역할을 한다. 1분 이내에 빠르게 처리해야하기 때문에 어떻게 시간을 단축하고 성능 개선을 했는지에 대한 내용이었다. 주로 multiprocessing을 적용하여 해결한 경우가 많았다. 전날 카카오의 발표와는 조금 다른 면도 많았고 사내 분위기를 조금 엿볼 수 있는 유쾌한 발표였다.
Creating AI chat bot with Python 3 and TensorFlow
- 첫째날 발표했던 내용을 영어로 중간 쉬는 시간에 재발표를 하였다. 일본 애니메이션 아이돌마스터 캐릭터를 챗봇으로 모델링하고 학습시켰던 과정을 발표하였다. 딥 러닝을 잘 모르고 발표도 영어로 하여 어려웠지만 흥미로웠다.
Python Profiling and Performance Tuning
- 말그대로 프로파일링과 성능 튜닝에 대한 Pinterest 개발자의 발표였다. 큰 기대를 하고 갔지만 말이 너무 빠르고 내용이 어려워 따라가지 못 했다.
지적 대화를 위한 깊고 넓은 딥러닝 (Feat. TensorFlow)
- 딥러닝 관련 여러 논문 내용과 이를 어떻게 TensorFlow를 사용하여 구현했는지 예제로 보여주었다. 딥러닝 발표의 정점이었다. 그냥 봐도 어려운데 잘 모르니 너무 어렵다.

파이콘에서는 정규 발표 시간이 끝난 후 5분 제한 자유 주제로 한 라이트닝 토크 시간이 있는데 작년에 이 시간을 놓친게 아까울 정도로 인상 깊었던 발표가 많았다.

아쉬운 점

OST(Open Space Talk) 세션이 발표 주제 관련 또는 자율적으로 2층 여러 공간에서 열렸으나 하나도 참석해보지 못 했다. 아예 2층에는 올라가보지 않았는데 내년에는 고려해보고 참석해봐야겠다.
OST도 세션 별로 참석 인원 차이가 컸다고 들었는데 시스템적으로나 시간, 위치적인 환경이 마련되면 더 좋을 것 같다. 라이트닝 토크 시간에 비슷한 지적이 있었다.
APAC 이름을 걸고 ‘Respect, Diversity’라는 주제였지만 한국어를 모르는 외국 참가자들에게도 통역이나 주제 선정, 운영이 잘 된 편인지는 의문이다.
라이트닝 토크 자료도 공식 홈페이지에 올려주시면 좋을 것 같다. 짧고 굵은 세션이 워낙 많아 다시 보고 싶은 발표가 많았다.

아쉬운 점만 많이 쓴 것 같은데 이 외에는 전부 만족스럽고 앞으로도 매번 가고 싶은 파이콘이었다. 정말 많은 분들이 고생하셨고 내년에도 올해만큼 즐거운 컨퍼런스가 되길 바란다.

워낙 많은 발표와 말을 들어서 그런지 2~3일 밖에 지나지 않았는데도 후기를 작성하는게 쉽지 않았다. 더 부지런해져야 한다.

2015년과 2016년

Fri, 01 Jan 2016 18:20:22 GMT

2015년, 여러모로 아쉬운 한 해였다.

특별히 남긴 것 없이 일년을 보내지 않았나 싶다. 연말이 되어가면서 머리 속으로 생각했던 다음 해 계획은 대부분 연초에 세웠던 계획과 별 차이가 없었다. 그 사실을 바로 깨닫는 순간 바로 2015년은 망한 해구나라는 걸 느꼈다.

개인적으로는 짧은 입원과 전신 마취의 수술을 처음으로 경험 했던 것이 가장 큰 사건이었다. 2주 가량의 휴가와 회복 기간으로 인해 의욕이 많이 꺾이고 일하는 방식도 많이 바뀐 것 같다.

업무 난이도가 높아지진 않았지만 스트레스는 점점 늘고 있다. 알아서 살아남아야 한다는 사실을 조금 더 느끼게 되었다. 뒤늦게 깨닫고 새 출발을 위해 다른 회사에 면접까지 보러 갔지만 준비가 늦었고 너무나 부족했다. 2015년의 가장 아쉬운 일이다.

그래도 다행인 것은 이직 준비를 하면서 일일 커밋을 시작했다는 점이다. 그렇다고 딱히 보이는 걸 완성한 건 아니었다. 12시가 되기 전에 커밋을 해야 한다는 압박감 때문에 오히려 아무 일도 못하기도 했다. 그러다가 겨우 거리를 만들어내 억지로 올린 적도 많았다. 그래도 3개월이 넘는 108일동안 실천한 것에 큰 의미가 있다. 2016년에는 하루도 쉬지 않고 하는 것이 목표다.

사실 2015년 내내 계속 시도했던 건 정리였다. 나 자신을 위한 정리. 하지만 쉽지 않았다. 2015년과 그 이전을 모두 잘 정리하고 2016년을 맞이하려고 한다. 정리된 상태에서 꾸준히 쌓아 올려야 완성이 된다.

2016년, 인생에 있어서 매우 중요한 해다.

2016년이 앞으로의 인생을 결정지을 중요한 시점이 될 것이다. 건강을 우선으로 하고, 글 쓰는 능력, 말하는 능력을 향상 시키길 원한다. 소프트웨어 개발의 기본을 키우는 기간이 되길 바란다. 앞서 말했듯이, 정리를 빨리 끝내고 그 위에 내 자신을 쌓아 진화하는 한 해가 되었으면 한다.

Everything in its Right Place

2025년 회고

오픈소스

컨퍼런스/세미나/멘토링

참석한 컨퍼런스/세미나

멘토링

블로그

조회수 순위

회사

개인

2026년

2025 오픈소스 컨트리뷰션 아카데미 체험형 멘토 후기

시작

멘티 선발

준비와 발대식

모임 진행 방식

모임 내용

1, 2주차

3주차

실습 목표

4주차

5주차

6주차

마무리

KPT 회고

Keep

Problem

Try

2024년 회고

오픈소스

2025년 오픈소스 목표

컨퍼런스/세미나/멘토링

참석한 컨퍼런스/세미나

멘토링

블로그

조회수 순위

회사

2025년

Chromium Faster Build 방법

빌드 방법

빌드를 빠르게 할 수 있는 기타 방법

오쏘콘(Open Source Conference) 발표 후기

발표 제안

주제 선정

주최 측의 컨퍼런스 발표 주제 방향

준비하면서 이루고자 했던 것

발표 준비

2개의 메인 주제

The Speaker’s Commentary

발표자 소개 (페이지 1 - 9)

서론 (페이지 10 - 16)

빌드업 (페이지 17 - 31)

개발(기여) 프로세스 (페이지 32 - 77)

더보기(내가 하고 싶은 이야기) (페이지 78 - 93)

느낀 점

2024 GDG Google I/O Extended 간단 후기

Google I/O Extended

안드로이드

수강

인천/송도

수강

소감

Chromium Committer 가 되었다

시작

첫 번째 도전

두 번째 도전

Chromium Committer?

Chromium Contribution 의 한계

앞으로

2023년 회고 그리고 2024년

회사

오픈소스

스터디

블로그

2024년

Chromium Contribution: CSS KeyframesRule length attribute 추가

관련 링크

개요

내용

테스트