2019 OSS 오픈 소스 개발자 이야기

2019 오픈소스 개발자 이야기

OSS에서 주최한 <오픈소스 개발자 이야기>라는 행사에 다녀왔다. 오픈 소스를 즐겨 쓰는 사람으로서, 오픈 소스에 기여하는 방법에 대해 관심이 있기도 했고 지난 날 해커톤에서 오픈 소스를 만들어보자는 이야기가 나왔기 때문에 유의미한 정보를 배울 수 있으리라 여겼다.

세션 내용 정리

오픈 소스 보고 응용하기

연사자분은 학생들과 캠퍼스 핵 데이를 3년 정도 진행하셨는데, 하시면서 느낀 점은 다음과 같았다고 했다.

• 학생들의 실력은 다양하나
• 성능 이슈를 고려하지 않음
• 협업을 어려워 함
• 오픈소스를 사용만 함
  • 참여하고 공부하지 않는 게 다반사

오픈 소스의 장점

대부분의 개발이 10명 이상 참여하기 쉽지 않은 반면, 오픈 소스는 여러 사람이 함께 참여하고 고민하기 때문에 때문에 퀄리티가 높을 가능성이 높다.

오픈 소스의 사용

오픈 소스를 사용하는 방법은 다양하지만, 우리는 올바르게 사용하고 있는가?

우리가 오픈 소스를 사용하는 단계

• 라이센스 확인
• 피쳐 확인
• 지원 버전 확인
• 사용 방법의 편리함 확인
• 설치 편리함 확인

사용만 급급한 것이 아닌가, 에 대한 질문 도출

오픈 소스를 통한 공부

오픈 소스는 영감을 얻을 수 있고, 새로운 공부 과제를 발견하고, 새로운 패러다임과 구조에 대한 발견을 할 수 있다.

오픈 소스에 접근하는 방식

• 도큐먼트 읽기
  • 도큐먼트에서는 해당 오픈 소스의 중요한 개념을 알 수 있다.
  • 제작자가 해당 개념을 착용한 이유와 장점을 알 수 있고, 이를 오픈 소스를 사용하는데 있어 중요한 자료가 된다.
• 소스 읽기
  • 실질적으로 오픈 소스가 어떻게 설계 되었는지 확인한다.
  • 내부 구조와 원리를 파악한다.
  • 도큐먼트의 특정 개념들을 어떻게 구현했는지에 중점적으로 본다.
• 소스 내에서 이해하지 못하는 것을 스터디 / 커뮤니티로 해결하려 노력한다.

연사자 분이 특정 오픈 소스를 예시로 들어 설명을 해주셨다.

오픈 소스를 잘 사용하는 사람들 중에서는 오픈 소스의 구조와 특징을 파악해, 오픈 소스를 가져와 쓰는 게 아니라, 프로젝트에 필요한 부분을 직접 만드는 게 나은지 등을 판단해서 쓴다고도 했다.

오픈 소스는 무조건적인 찬양이나 비판을 지양해야 한다고 강조하면서 해당 발표가 종료되었다.

국제화/번역과 함께하는 오픈소스에 대한 경험 및 노하우

번역 시작 계기

연사자 분께서 우연한 기회에 openstack을 알게 되어 가입했는데, 커뮤니티 내에서 번역 관련 이슈들이 나오는 걸 보게 되었다. 이전에 누군가의 번역글을 통해 도움을 받은 적이 있었기에, 나도 번역을 할 수 있지 않을까라는 생각으로 번역을 시작하게 되었다.

그런데 openstack이 국제화되며, 300 단어 이상을 번역한 사람에게 특정한 권한을 준다는 것을 알게 되었고, 국제 서밋의 티켓을 무료로 받을 수 있었다.

그래서 트레블 서포트를 신청하셨었다고. 서포트 내용은 아래와 같았다.

• 번역에 참여했더니 티켓이 공짜가 되었다
• 행사는 일본에서 열리는데, 나는 한국에 있으니 비행기 값이 싸다. 타 대륙에 있는 사람보다 나를 후원해달라
• 오픈 스택을 더 배우고 싶다

서포트를 신청해 도움을 받았고, 서밋에서 사람들을 많이 만나 즐거웠지만 번역에 참여하는 사람들 모두 다 영어를 못한다는 것을 알게 되었다. 그런데 이야기가 된다는 점이 신기했다. 그 이후 여러 번역에 참여하게 되었다.

번역의 어려움, 서로 다른 번역 환경

도구

일반적으로 상용 온라인 번역 도구들은 오픈 소스임을 인증하면 무료로 제공하기도 한다.

• GNU gettext : 소프트웨어 국제화에 대한 체계를 잘 정리한 소프트웨어 패키지
• POEdit : PO라는 형식을 가진 파일을 쉽게 PC에서 편집 후 저장 가능한 도구
• Transifex : 온라인 번역 도구로, 협업을 위한 기능 제공. 상용 소프트웨어이나 오픈 소스를 번역하는데 있어서는 사용 가능
• Pootle : 온라인 번역도구로, 해당 도구도 오픈 소스로 만들어져있음 (현재 업데이트가 되고 있지 않음)
• Zanata : Java를 기반으로 하는 온라인 협업 오픈 소스 번역 도구 (작년 9월부터 업데이트가 되고 있지 않음)
• Weblate : gethub와의 통합을 강조하는 web 기반 번역 도구로, 오픈소스 설치 버전
• Crowdin

용어집

번역에 있어 용어는 굉장히 중요한데 많은 난제들이 있다.

• 한글로 번역하면 이상할 때
• 외래어 표기의 애매성
• 번역 단어가 상황에 따라 달라질 때
• etc

때문에 번역 용어집 제작은 굉장히 중요하다.

언어

• 언어 코드에 관한고민

  • ko / ko_KR / ko-kr / ko-KR

• 복수형에 대한 고민

나 또한 현재 자바스크립트 튜토리얼을 좋은 기회로 소개 받아 일부 번역 작업에 참여한 경험이 있었다.

30여줄 번역했는데 피드백만 20여개였던 게 함정(…)

제일 많은 지적을 받은 건 용어와 복수형에 대한 것이었는데, 세션을 들으면서 내 과거의 경험도 오버랩되고 그랬다.

회사원에서 오픈 소스 개발자로 거듭나기

세션 1

평소 개발을 좋아하시던 분이었지만, 사측에서 개발을 할 경험이 많지 않았다. 하여 회사 업무와 밀접한 연관이 있는 오픈 소스를 골라 기여를 시작했다.

• 처음 오픈 소스에 기여해보고 싶었는데, 사람들에게 조언을 구해보니 일단 해당 오픈 소스를 많이 사용해볼 것을 추천하더라

  • 그런데 사용해본 오픈 소스에 버그가 없었다

  연사자 분은 크롬(..)으로 시작하셨다고

• 해당 오픈 소스의 코드를 보기 시작했다

  • 코드가 너무 방대하여 다 보는 건 힘들었다
  • 그래서 특정 핫한 기술을 어떻게 구현했는지를 주로 봤는데
  • 우연한 기회로 불필요한 연산을 발견하게 되었고, 이를 삭제하는 게 첫 패치였다

• FIXME, TODO가 붙은 이슈들을 보기 시작

  • 하지만 해당 마크가 붙은 건 어려운 이슈들이 많았다

• 모든 issue를 다 보기 시작(최신순으로)

  • 쉬운 이슈를 발견하게 되면 고치는 식으로 시작
  • 이렇게 하는 건 비효율적이므로, goodfirstbug 마크 중심의 이슈를 볼 것을 추천하셨다

• 상호운용성에 중점

  • 다른 서비스에는 있지만 해당 오픈 소스에는 없는 기능을 구현
  • 웹 표준 스펙을 읽으며 구현

이런 경험을 통해 남의 코드를 읽는 능력이 크게 향상되었다.

세션 2

오픈 소스에 꾸준하게 기여하는 게 쉽지 않아서 방법을 고안했다.

• 벌금 제도
  • 특정 횟수 이상 패치를 하지 않으면 벌금을 물기
  • 횟수에 집중하다보니 깊이가 얕아진다는 단점이 발생했다.
• 컨퍼런스 발표로 깊게 익힐 수 있도록 노력했다.

당신도 할 수 있는 오픈 소스를 이용한 어플리케이션 만들기

• 오픈 소스를 활용해 테스트 케이스 작성
• 오픈 소스를 활용해 성능 테스트
  • 실제 서버와 같은 테스트 서버를 두고 테스트해보기
  • APM
    • pinpoint
      • 어플리케이션 구조를 볼 수 있고
      • 실시간 요청의 응답 속도를 볼 수 있음
      • 특정 요청에 대한 상세한 정보(call stack, metrics) 확인 가능
  • stress test tool 사용
    • nGrinder
    • jmeter
    • ab

연사자 분께서 자바 관련해서 많이 설명해주셨고, 예시로 든 것 또한 자바에서 쓸 수 있는 오픈 소스였다. 안타깝게도 내가 자바를… 안본지 좀 오래 되어서… 그런 게 있구나, 하는 식으로 발표를 이해했다.

나는 어쩌다 오픈소스 프로젝트 멤버가 되었나

• 오픈 소스에 참여하기 전에 도큐먼트를 잘 읽어보고 (어떤 방식으로 기여가 이루어지는지) 기여에 진행해야 한다.
  프로젝트 별 규칙 및 방법론 준수가 핵심

• 코드를 쉽게 짜려고 노력할 것

• 테스트의 중요성을 강조

오픈 소스 스프린트 : 기획부터 실행까지

스프린트

라인에서 만든 오픈 소스에 기여할, 스프린트를 만들게 된 과정 발표

스프린트 멘토가 준비해야 할 것

• CONTRIBUTLING.md
  • Build requirements
  • 개발 환경 설정
  • 코딩 스타일 가이드
  • Code of Conduct
  • CLA
• 예전과 달라졌을 가능성도 있기 때문에 처음부터 한 번 해본다
• good-first-issue 만들기
  • 적당히 작게 쪼갤 것
  • 피상적인 이슈를 피할 것
  • 충분한 정보 제공
    • 왜 해결해야 하나
    • 어디가 문제인가
    • 어떻게 해결해야 하나
• 멘티가 준비해야할 것들을 잘 공지할 것

멘티의 준비 요소

• 배경 지식
  • 언어
  • 유사 프로젝트 사용 경험 / 해당 프로젝트 사용 경험
• md 파일 읽기
• 오리지널 리포 클론
• 빌드
• good-first-issue 마크 확인

느낀점

연사자 분들 대부분이 오픈 소스에 어떻게 기여하기 시작했는지, 어떻게 그 꾸준함을 유지했는지를 논하신 터라 후반부에 진행된 세션의 경우 앞 세션과 겹치는 내용이 많았다. 연사자 분들 대부분이 말씀 자체를 재밌게 하셔서 듣는데 지루하진 않았지만… 주최 측에서 세션 내용의 다양성에 대해 신경 써주셨으면 좋았을 것 같다.

그리고 운영 측에서 시간 운용을 조금 더 효율적으로 하셨으면 좋았을 것 같다. 쉬는 시간은 단 한 번, 10분 남짓이었던 터라 후반에 집중하기 너무 힘들었다. 시간 배분을 널널하게 해서 쉬는 시간도 보다 길었으면 좋았을 것 같고(다과 줄이 얼마나 긴데 쉬는 시간 10분…) 세션이 이어지는 중간 중간에도 홍보라던가, 공지라던가 진짜… 귀에 휴식 시간이 없었다. 정보가 끊임없이 이어졌고 전달되는 정보를 다 얻지도 못해서(연사자 분들께 질문하고자 하는 내용을 따로 받는다고 하셨는데 어떻게 질문을 드리면 되는지 알 수가 없었고, 갑자기 질문 마감하겠다는 공지가 나왔다) 청취자 입장에서는 당황스럽고 그랬다.

시간을 배분한다는 게 어렵다는 것, 이해하지만.. 그렇기 때문에 세션이 여러 개인 행사일 수록 여윳 시간을 좀 많이 넣는 게 좋다고 생각하는데, 해당 행사의 여윳 시간은 어느 정도였을까. 시간에 쫓기는 느낌도 많이 받았고, 발표 중간 중간 우겨넣다시피 공지되는 정보에서 듣기로는 “어떻게든 발표된 시간에 마치도록 하겠습니다”라고 하셨는데, 그 마치는 시간 조율을 세션 중간을 빨리 끝내도록 유도하는 방식이여서… 과연 효율적이었는가… 누구를 위한 시간 맞추기였는가… 좀 많이 의문이 들었다.

여타 개발 행사와 매한가지로 인터넷 친구들과 실제 지인들을 우연치 않게 만난 자리여서, 행사 외적으로 피곤하긴 했지만 즐거웠다. 어제 해커톤 다녀와서… 이것도 후기 써야 하는데 언제 쓰냐