함께 개발하기 — 공유와 협업

생각 열기 — 파일 이름이 ‘최종_최종_진짜최종’

모둠 과제로 발표 자료를 만든 적이 있을 것이다. 파일을 주고받다 보면 이런 일이 생긴다.

발표자료.pptx
발표자료_수정.pptx
발표자료_최종.pptx
발표자료_최종_2.pptx
발표자료_최종_진짜최종.pptx
발표자료_최종_진짜최종_민수수정.pptx

왜 나눠 만드는가

혼자 만들 수 있는 프로그램의 크기에는 한계가 있다. 여럿이 나눠 만드는 이유는 셋이다.

• 규모 — 수만 줄짜리 프로그램을 한 사람이 쓰기에는 시간이 모자란다.
• 전문 분야 — 화면을 잘 만드는 사람, 자료를 잘 다루는 사람, 성능을 잘 다루는 사람이 다르다.
• 점검 — 자기 코드의 잘못은 자기 눈에 잘 보이지 않는다. 다른 사람이 읽으면 보인다.

5차시에서 모듈로 나누는 이야기를 했다. 모듈로 잘 나뉜 프로그램은 사람으로도 나눌 수 있다. 한 사람이 한 모듈을 맡으면 서로의 속을 몰라도 각자 만들 수 있다. 설계가 협업의 조건이 되는 것이다.

나눠 만들 때 새로 생기는 문제

나누면 좋은 점만 생기는 것은 아니다. 파일을 주고받는 방식으로 협업하면 네 가지 문제가 반드시 생긴다.

파일을 주고받는 방식의 문제

문제	어떻게 나타나는가	무엇을 잃는가
최신본을 모른다	이름이 비슷한 파일이 여러 개 쌓인다	어느 것을 고쳐야 할지 모른 채 낡은 것을 고친다
고친 내용을 덮어쓴다	둘이 각자 고친 뒤 한쪽 파일만 남긴다	다른 한쪽이 한 일이 통째로 사라진다
되돌릴 수 없다	잘 되던 코드를 고쳐 망가뜨렸다	어제 상태로 돌아갈 방법이 없다
누가 왜 고쳤는지 모른다	코드가 바뀐 이유가 기록되지 않는다	이상해 보이는 코드를 함부로 지우거나, 못 지우고 남겨 둔다

버전 관리 — 고친 내력을 기록한다

이 네 문제를 한꺼번에 해결하는 도구가 버전 관리(version control) — 코드가 바뀐 내력을 기록해 두고, 되돌리거나 여러 사람의 수정을 합쳐 주는 도구다. 버전 관리 도구는 파일을 덮어쓰지 않고 바뀐 내력을 차곡차곡 쌓아 둔다.

• 누가 · 언제 · 무엇을 · 왜 고쳤는지가 한 묶음으로 기록된다.
• 어느 시점으로든 되돌릴 수 있다. 잘 되던 어제 상태로 돌아가는 일이 명령 한 번이다.
• 두 사람이 서로 다른 곳을 고쳤으면 자동으로 합쳐 준다.
• 두 사람이 같은 줄을 고쳤으면 합치지 않고 알려 준다. 이것을 충돌이라 한다.

도구보다 약속이 먼저다

버전 관리 도구를 쓰더라도 약속이 없으면 문제가 그대로 남는다. 함께 개발할 때 지킬 약속은 다음과 같다.

• 약속 1

  고치기 전에 받는다

  작업을 시작할 때 늘 최신 내용을 먼저 받아 온다. 낡은 것을 고치면 합칠 때 충돌만 늘어난다.

• 약속 2

  한 번에 한 가지만

  "점수 계산 오류 수정"처럼 한 가지를 고치고 기록한다. 열 가지를 한꺼번에 올리면 되돌릴 때 필요한 것까지 함께 사라진다.

• 약속 3

  무엇을 왜 고쳤는지 적는다

  기록에 남기는 말이 나중에 읽는 사람의 유일한 단서다. "수정"이라고만 적으면 아무 정보가 없다.

• 약속 4

  남의 코드를 지우지 않는다

  이상해 보여도 이유가 있을 수 있다. 지우기 전에 왜 그렇게 했는지 묻는다.

여기에 하나를 더한다. 서로의 코드를 읽는다. 합치기 전에 상대의 수정을 읽고 의견을 주는 일을 코드 리뷰라 한다. 잘못을 찾는 것이 첫 목적이지만, 실제로 더 큰 효과는 모듈을 맡지 않은 사람도 그 부분을 알게 된다는 점이다. 그러면 맡은 사람이 없을 때도 프로그램이 멈추지 않는다.

공유할 때 지킬 것

코드를 남과 나눌 때는 코드 말고도 확인할 것이 있다.

• 개인정보를 넣지 않는다. 시험 삼아 넣어 둔 실제 학생 이름, 전화번호, 학번이 코드나 자료 파일에 남은 채 공유되는 일이 자주 생긴다. 시험용 자료는 홍길동, 학생1 처럼 지어낸 값으로 만든다.
• 비밀값을 코드에 적지 않는다. 비밀번호나 접속 열쇠를 코드에 적어 두면 코드를 공유하는 순간 함께 넘어간다.
• 남의 코드를 가져올 때 조건을 확인한다. 인터넷에 공개된 코드에는 대체로 쓸 수 있는 조건이 붙어 있다. 출처를 밝혀야 하는 조건, 고친 것도 함께 공개해야 하는 조건, 상업적으로는 쓸 수 없는 조건이 있다. 이 조건을 라이선스라 한다. 공개돼 있다는 것이 마음대로 써도 된다는 뜻은 아니다.
• 가져온 부분은 표시한다. 어디서 가져왔는지 주석으로 남긴다. 나중에 그 코드에 문제가 발견됐을 때 찾아갈 수 있다.

활동

프로젝트

짝을 이뤄 하나의 코드를 나눠 고치고 합치기

약 30분

두 사람이 한 코드를 나눠 고친 뒤 합치는 과정을 직접 겪어 본다. 버전 관리 도구를 쓰지 않고 손으로 해 본다. 도구가 무엇을 대신해 주는지 알기 위해서다.

1단계 — 출발 코드를 정한다 (함께)

2차시 번역 방식으로 나눠 보는 언어 — 컴파일러와 인터프리터 의 합 구하기 코드를 종이에 옮겨 적는다. 두 사람이 각자 한 장씩 갖는다. 이 종이가 “함께 쓰던 코드”다.

2단계 — 역할을 나눈다 (각자)

• 학생 A — 합이 아니라 평균도 함께 내도록 고친다.
• 학생 B — 출력 문구를 바꾸고, 1부터 10이 아니라 1부터 n까지 더하도록 고친다.

상대의 종이를 보지 않고 각자 고친다. 고친 뒤 무엇을 왜 고쳤는지 종이 아래에 한 문장으로 적는다.

3단계 — 합친다 (함께)

두 종이를 나란히 놓고 하나의 코드로 합쳐 새 종이에 적는다. 다음을 기록한다.

항목	기록
서로 다른 줄을 고친 부분 (자동으로 합쳐질 곳)
같은 줄을 서로 다르게 고친 부분 (충돌)
충돌을 어떻게 정했는가
합치는 데 걸린 시간

4단계 — 되돌려 본다

합친 코드에서 학생 B의 수정만 되돌려 원래대로 만들어 본다. 2단계에서 적어 둔 “무엇을 왜 고쳤는지”가 있으면 쉽고, 없으면 어렵다는 것을 확인한다.

5단계 — 정리한다

버전 관리 도구가 3단계와 4단계에서 무엇을 대신해 주는지 세 가지 적는다. 그리고 이 활동에서 앞의 네 가지 약속 중 지키지 않아 힘들었던 것이 있는지 이야기한다.

개념 확인 문제

보기를 누르면 바로 채점된다. 틀려도 해설을 읽으면 된다.

여러 사람이 파일을 주고받는 방식으로 코드를 함께 고칠 때 생기는 문제가 아닌 것은?프그01-04

1. 1어느 파일이 최신본인지 알 수 없다
2. 2한쪽의 수정이 통째로 덮어써져 사라진다
3. 3잘 되던 시점으로 되돌릴 방법이 없다
4. 4프로그래밍 언어의 문법이 저절로 바뀐다

버전 관리 도구에서 '충돌'이 났다는 것은 무슨 뜻인가?프그01-04

1. 1도구가 고장 나 코드를 잃어버렸다
2. 2두 사람이 같은 줄을 서로 다르게 고쳐 도구가 어느 쪽을 남길지 판단할 수 없다
3. 3코드에 문법 오류가 있다
4. 4인터넷 연결이 끊겼다

협업에서 '한 번에 한 가지만 고치고 기록한다'는 약속을 지키면 얻는 이점은?프그01-04

1. 1코드가 짧아진다
2. 2문제가 생겼을 때 그 한 가지만 골라 되돌릴 수 있다
3. 3실행 속도가 빨라진다
4. 4충돌이 아예 생기지 않는다

시험용 자료를 만들 때 실제 학생 이름과 학번 대신 지어낸 값을 쓰는 이유는?프그01-04

1. 1지어낸 이름이 코드를 빠르게 만든다
2. 2코드를 공유할 때 개인정보가 함께 넘어가는 것을 막기 위해서다
3. 3한글 이름은 프로그램이 처리할 수 없기 때문이다
4. 4실제 이름을 쓰면 컴파일이 되지 않기 때문이다

[OX] 인터넷에 공개된 코드는 공개돼 있으므로 조건 없이 가져다 쓸 수 있다.프그01-04

1. 1⭕ 그렇다
2. 2❌ 아니다

합치기 전에 서로의 코드를 읽는 코드 리뷰의 효과로 알맞지 않은 것은?프그01-04

1. 1자기 눈에 안 보이던 잘못을 찾는다
2. 2맡지 않은 부분도 알게 되어 그 사람이 없을 때 대응할 수 있다
3. 3더 나은 방법을 서로 배운다
4. 4읽는 사람이 코드를 대신 다 만들어 준다

더 알아보기

심화'브랜치'는 갈라진 가지를 뜻한다

버전 관리 도구에서 본문 그림처럼 갈라져 나간 갈래를 브랜치(branch), 즉 가지라 부른다. 가지를 따로 두는 까닭은 만드는 중인 코드가 잘 되던 코드를 망가뜨리지 않게 하려는 것이다. 새 기능을 가지에서 만들어 확인이 끝난 뒤에 본 줄기에 합친다. 그래서 본 줄기는 언제나 돌아가는 상태로 유지된다. 학교 과제에서도 “지금 되는 것”을 한 벌 남겨 두고 새 시도를 따로 하는 습관은 그대로 쓸 만하다.

실무기록에 적는 한 줄의 무게

코드를 고치고 남기는 기록에 무엇을 적어야 하는지에는 관례가 있다. 무엇을 바꿨는지는 코드가 이미 말해 주므로, 왜 바꿨는지를 적는다. “조건문 수정”보다 “0점을 받은 학생이 걸러지던 문제를 고침 — 부등호에 등호를 붙였다”가 훨씬 쓸모 있다. 몇 달 뒤에 그 줄을 읽는 사람은 코드를 보고도 이유를 모르기 때문이다. 5차시에서 주석에 ’왜’를 적으라고 한 것과 같은 이야기다.

진로협업 기록이 곧 경력이 된다

공개된 곳에서 코드를 만들고 고친 내력은 그대로 남는다. 무엇을 만들었는지, 남의 지적에 어떻게 답했는지, 문제를 어떻게 좁혀 갔는지가 기록으로 보인다. 그래서 개발 분야에서는 이력서보다 그 기록을 먼저 보는 경우가 많다. 지금 수업에서 만드는 작은 프로그램도 기록을 남기며 만들어 두면 나중에 자기 자료가 된다. 다만 공유 전에 개인정보와 비밀값을 확인하는 일은 늘 먼저 한다.