오픈소스로 협력 개발

본문

본문

리눅스 운영 체제, 파이썬 언어, 웹 브라우저의 엔진은 전 세계의 개발자 수천 명이 함께 만든 오픈소스 프로그램이다. 그들은 대부분 서로 얼굴도 모른다. 누구나 코드를 보고 고칠 수 있다면 엉망이 될 것 같은데, 오히려 은행과 우주선, 스마트폰이 이 프로그램들을 믿고 쓴다. 어떻게 그럴 수 있을까? 많은 사람이 함께 코드를 고치려면 어떤 도구와 규칙이 필요할까?

검토자 수 한 명이 그 버그를 찾을 확률 (%)

그림 1. 검토자들이 서로 독립적으로 코드를 볼 때, 누군가 그 버그를 찾아낼 확률. 한 명의 실력이 평범해도 검토자가 늘면 빠르게 1에 가까워진다.

먼저 알아야 할 것프로젝트 설계와 인터페이스(프로젝트 설계), 확률과 여사건(수학).

4.3.1버전 관리와 코드 검토

여러 사람이 같은 코드를 고치려면 누가 언제 무엇을 바꾸었는지 기록하고, 서로의 변경을 합칠 수 있어야 한다. 깃(Git) 같은 버전 관리 도구는 코드의 변경을 커밋이라는 단위로 저장하고, 각자 가지(브랜치)를 만들어 따로 작업한 뒤 합치게 해 준다. 오픈소스 프로젝트에서는 누군가 변경을 제안하면(풀 리퀘스트), 다른 개발자들이 그 코드를 읽고 문제를 지적하며 토론한다. 이것이 코드 검토이다. 검토를 통과하고 자동 시험을 모두 통과한 변경만 본래 코드에 합쳐진다.

정리 4.3.1 여러 검토자의 효과

검토자 한 명이 어떤 버그를 찾을 확률이 \(p\)이고, \(k\)명이 서로 독립적으로 검토하면, 누군가 그 버그를 찾을 확률은 \[1 - (1 - p)^k\]이다. 한 명의 \(p\)가 작아도 \(k\)가 늘면 빠르게 1에 가까워진다. 다만 모두 같은 곳을 놓치는 식으로 검토가 독립적이지 않으면 효과가 줄어든다.

그림 1에서 두 값을 바꾸어 보자. 한 명이 30% 확률로 찾는 버그를 3명이 보면 약 66%, 5명이 보면 약 83%, 10명이 보면 97%의 확률로 누군가 찾아낸다. 수천 명이 쓰고 읽는 오픈소스는 이 효과가 아주 크다. 그래서 '보는 눈이 충분히 많으면 모든 버그는 얕다'는 말이 생겼다. 다만 검토자들이 같은 배경과 습관을 가지면 같은 곳을 함께 놓치므로, 서로 다른 사람들이 검토하는 것이 중요하다.¹

4.3.2라이선스와 협업 규칙

오픈소스라고 해서 아무렇게나 써도 되는 것은 아니다. 코드의 저작자는 라이선스로 다른 사람이 그 코드를 어떤 조건으로 쓰고, 고치고, 다시 배포할 수 있는지 밝힌다. MIT 라이선스처럼 저작권 표시만 남기면 거의 자유롭게 쓰게 하는 것이 있고, GPL처럼 그 코드를 고쳐 배포할 때 고친 코드도 같은 조건으로 공개하게 하는 것이 있다. 프로젝트에는 코드 스타일, 커밋 메시지 쓰는 법, 버그를 알리는 방법, 서로를 존중하는 행동 강령 같은 협업 규칙도 있다. 이런 도구와 규칙 덕분에 서로 모르는 사람들도 함께 일할 수 있다.

그림 2. 도구와 규칙이 서로 모르는 개발자들의 협력을 가능하게 한다.

4.3.3예제 풀이

예제 4.3.2

어떤 버그를 검토자 한 명이 찾을 확률이 20%이다. 이 버그를 90% 넘는 확률로 찾으려면 서로 독립적인 검토자가 몇 명 필요한가? 검토자들이 모두 같은 습관을 가져 한 명이 놓치면 다른 사람도 절반의 확률로 함께 놓친다면 어떻게 될지 설명하여라.

\(1 - 0.8^k > 0.9\)이어야 하므로 \(0.8^k < 0.1\)이다. \(0.8^{10} \approx 0.107\), \(0.8^{11} \approx 0.086\)이므로 11명이 필요하다.

검토자들이 독립적이지 않으면, 한 명이 놓친 버그를 다른 사람들도 놓칠 가능성이 커진다. 그러면 \(0.8^k\)보다 놓칠 확률이 훨씬 커서, 11명이 보아도 90%에 이르지 못한다. 극단적으로 모두가 똑같이 생각한다면 몇 명이 보든 한 명이 본 것과 같다. 즉 검토의 힘은 사람의 수만큼 서로 다른 관점에서 나온다. 그래서 큰 오픈소스 프로젝트는 다양한 배경의 기여자를 모으고, 자동 시험처럼 사람과 다른 방식의 검사도 함께 쓴다.

아래 탐구 카드에서 버전 관리 도구로 함께 코드를 고쳐 보고, 여러 라이선스의 조건을 비교해 보자.

이 말은 1999년 레이먼드가 에세이 「성당과 시장」에서 리눅스의 개발 방식을 설명하며 '리누스의 법칙'이라 이름 붙였다. 리눅스를 처음 만든 토르발스의 이름을 딴 것이다.

마무리

오픈소스 협업은 버전 관리로 변경을 기록하고 합치며, 코드 검토로 여러 사람이 변경을 읽고 문제를 찾고, 라이선스와 협업 규칙으로 쓰는 조건과 일하는 방식을 정한다. 서로 독립적인 검토자가 늘면 버그를 놓칠 확률이 \((1-p)^k\)로 빠르게 줄어, 많은 사람의 서로 다른 눈이 품질을 높인다. 그래서 처음 질문의 오픈소스 프로그램은 수천 명이 각자의 관점으로 검토하고 시험한 덕분에 오히려 믿을 만하다.

탐구 1

두 사람이 같은 파일을 고치면 git은 어떻게 합칠까?

오픈소스 협업 · 브랜치, 병합, 충돌

main 브랜치 (민지가 고침)

fix-empty 브랜치 (준호가 고침)

브랜치마다 고칠 줄을 고른 뒤 병합하세요.

stats.py의 처음 내용(공통 조상)에서 두 브랜치가 갈라졌다. 파란 띠는 main의 변경, 노란 띠는 fix-empty의 변경이다. 실제 git처럼 같은 줄이나 바로 붙은 줄을 양쪽이 서로 다르게 고치면 충돌로 처리한다.

질문오픈소스 프로젝트에는 서로 만난 적 없는 수백 명이 코드를 고친다. 두 사람이 같은 파일을 동시에 고치면, 한 사람의 수정이 다른 사람의 수정을 덮어써 버리지 않을까?
복원git은 파일의 변경 이력을 커밋 단위로 저장하는 버전 관리 도구이다. 브랜치는 커밋 이력의 갈래로, 각자 자기 브랜치에서 작업하면 남의 작업과 섞이지 않는다. GitHub, GitLab 같은 서비스는 git 저장소를 인터넷에 두고 함께 쓰게 해 준다.
설명병합(merge)할 때 git은 두 브랜치의 마지막 커밋과 둘이 갈라진 공통 조상, 세 가지를 비교한다(3-way merge). 한쪽만 고친 부분은 고친 쪽을 자동으로 택하고, 양쪽이 같은 곳을 서로 다르게 고쳤으면 어느 것을 택할지 판단하지 못해 충돌(conflict)을 알린다. 충돌한 곳에는 <<<<<<<, =======, >>>>>>> 표시가 들어가며, 사람이 내용을 보고 고친 뒤 커밋해야 병합이 끝난다.
연결오픈소스 협업에서는 보통 저장소를 복제(fork)하거나 브랜치를 만들어 고친 뒤 풀 리퀘스트(pull request)로 병합을 요청한다. 다른 사람이 코드를 검토(code review)하고 자동 테스트가 통과하면 병합한다. 작은 단위로 자주 커밋하고 자주 병합할수록 충돌이 작고 풀기 쉽다.
적용main에서 5줄(반올림), fix-empty에서 7줄(빈 리스트로 시험)만 고르고 병합해 보자. 그다음 양쪽 모두 5줄을 고르고 병합하면 무엇이 달라지는가? 충돌을 세 가지 방법으로 풀어 결과를 비교하고, main의 1줄과 fix-empty의 2줄처럼 붙어 있는 두 줄을 각각 고치면 어떻게 되는지도 확인해 보자.
판단충돌이 없다고 병합 결과가 옳다는 보장은 없다. 두 사람이 서로 다른 줄을 고쳤어도, 합쳐진 코드가 함께 동작하지 않을 수 있다. 예를 들어 5줄 충돌을 ‘main 쪽 선택’으로 풀면, 충돌 없이 들어온 fix-empty의 7줄 print(average([]))는 실행하자마자 ZeroDivisionError를 낸다. 그래서 병합한 뒤에는 반드시 테스트를 다시 돌린다. ‘한쪽 선택’으로 충돌을 지우면 다른 사람의 수정이 조용히 사라질 수 있으니, 두 변경의 의도를 확인하고 합쳐야 한다.

확인조건이 달라지면

민지와 준호가 같은 파일에서 각각 10번째 줄과 40번째 줄을 고쳤고, git merge가 충돌 없이 끝났다. 다음 중 옳은 것은?

읽기 2

인터넷에 공개된 코드는 마음대로 가져다 써도 될까?

읽기 · 라이브러리 활용, 협업 흐름, 오픈소스 라이선스

CSV 파일 읽기, 그래프 그리기, 정렬처럼 많은 사람이 필요로 하는 기능은 이미 누군가 만들어 공개해 두었다. 이것을 쓰면 프로젝트의 핵심 문제에 시간을 쓸 수 있다. 그런데 공개되어 있다는 것과 마음대로 써도 된다는 것은 같은 뜻일까?

1라이브러리를 활용해 협력하기

오픈소스는 소스 코드를 공개하고, 정해진 조건(라이선스) 아래에서 누구나 쓰고 고치고 다시 배포할 수 있게 한 소프트웨어이다. 파이썬에는 설치하지 않아도 쓰는 표준 라이브러리(csv, collections, random 등)가 있고, 그 밖의 라이브러리는 PyPI 저장소에서 pip로 설치한다.

# 터미널에서:  pip install pandas
      import pandas as pd
      from collections import Counter

      df = pd.read_csv("lunch.csv")              # 날짜, 메뉴, 잔반kg 열이 있는 표
      top = df.groupby("메뉴")["잔반kg"].mean().sort_values(ascending=False).head(10)
      print(top)
      print(Counter(df["메뉴"]).most_common(3))  # 가장 자주 나온 메뉴 3개

라이브러리를 쓸 때는 공식 문서와 예제를 먼저 읽고, 프로젝트에서 쓴 라이브러리와 버전을 requirements.txt 같은 파일에 적어 둔다. 그래야 다른 모둠원의 컴퓨터에서도 같은 결과가 나온다.

2오픈소스 프로젝트가 함께 일하는 방식

이슈(issue)

버그 신고나 새 기능 제안을 글로 남기고 토론한다.

포크·브랜치

원래 저장소를 복제하거나 브랜치를 만들어 그 안에서 고친다.

풀 리퀘스트

고친 내용을 원래 저장소에 합쳐 달라고 요청한다. 무엇을 왜 고쳤는지 설명을 붙인다.

코드 리뷰와 자동 테스트

관리자와 다른 기여자가 코드를 읽고 의견을 남기며, 테스트가 통과해야 병합된다.

문서

README(무엇을 하는 프로그램이며 어떻게 쓰는가), CONTRIBUTING(기여하는 방법), LICENSE(이용 조건) 파일을 둔다.

3라이선스, 쓰는 조건을 읽는 법

라이선스	갈래	지켜야 할 주요 조건	쓰는 예
MIT	허용형	저작권 표시와 라이선스 전문을 함께 배포. 수정·상업적 이용 가능. 보증 없음	많은 소규모 라이브러리
BSD 3-Clause	허용형	MIT와 비슷하고, 원저작자의 이름을 허락 없이 홍보에 쓰지 않을 것	NumPy, pandas, scikit-learn
Apache 2.0	허용형	라이선스와 NOTICE 파일 포함, 수정한 파일에 변경 사실 표시. 특허 사용 허락 조항 포함	requests
GPL 3.0	카피레프트	이 코드를 포함한 프로그램을 배포하면 전체 소스 코드를 같은 GPL로 공개	GNU 도구들
CC BY, CC BY-SA	콘텐츠용	저작자 표시(BY), 같은 조건으로 공유(SA). 코드보다는 그림·글·자료에 씀	위키백과 글(CC BY-SA)

프로젝트에 다른 사람의 코드나 라이브러리를 썼다면 README에 출처와 라이선스를 적는다. 산출물을 공개할 때는 내 코드에 어떤 라이선스를 붙일지도 정한다. 사용한 라이브러리가 GPL이면 내 프로그램을 배포할 때 GPL 조건을 따라야 하므로, 라이브러리를 고르는 단계에서 라이선스를 확인한다.

판단“GitHub에 공개되어 있으니 자유롭게 써도 된다”, “오픈소스는 상업적으로 쓸 수 없다”는 둘 다 흔한 오해이다. 공개와 이용 허락은 별개이며, 대부분의 오픈소스 라이선스는 조건만 지키면 상업적 이용도 허락한다. 또 GPL의 소스 공개 의무는 프로그램을 다른 사람에게 배포할 때 생기며, 혼자 쓰거나 모둠 안에서 시험하는 것만으로 생기지는 않는다. 정확한 조건은 반드시 라이선스 원문을 확인한다.

확인조건이 달라지면

모둠이 MIT 라이선스 라이브러리의 코드 일부를 고쳐 프로젝트 프로그램에 넣고, 이 프로그램을 학교 누리집에 공개하려 한다. 반드시 해야 할 일은?