소프트웨어 개발 2강. 통합 구현과 형상 관리

"제 컴퓨터에서는 되는데요"라는 문장을 없애기 위해 만들어진 기술들이 있습니다. 형상 관리는 그 문장에 대한 공학의 답입니다.

풀고 시작

형상 관리는 변경을 막는 게 아니라 추적하는 것입니다

형상 관리(Software Configuration Management)를 "함부로 못 바꾸게 하는 제도"로 오해하는 경우가 많습니다. 목적은 정반대입니다. 소프트웨어는 반드시 바뀌기 때문에, 바뀐 것을 추적할 수 있게 만드는 활동이죠. 무엇이 언제 왜 누구에 의해 바뀌었는지 답할 수 있으면 변경은 위험이 아니라 자산이 됩니다.

절차는 넷입니다. 형상 식별에서 관리할 대상, 즉 형상 항목을 정하고 이름을 붙입니다. 소스 코드뿐 아니라 요구사항 명세서, 설계서, 테스트 계획서, 매뉴얼이 모두 형상 항목입니다. 형상 통제에서 변경 요청을 받아 심의하고 승인 여부를 정합니다. 이 일을 하는 조직이 형상통제위원회(CCB)입니다. 형상 감사에서 승인된 변경이 제대로 반영됐는지 확인하고, 형상 기록에서 그 결과를 문서로 남깁니다.

여기서 베이스라인(baseline)이라는 개념이 나옵니다. 특정 시점에 검토를 거쳐 확정된 형상으로, 이후의 변경은 반드시 공식 절차를 거쳐야 하는 기준선입니다. 기준선이 없으면 무엇으로부터 바뀌었는지 말할 수 없으니, 사실상 형상 관리의 출발점입니다.

버전 관리 도구는 세 세대를 거쳤습니다

분산 방식의 장점은 서버가 죽어도 각자의 사본에 전체 이력이 남아 있다는 점입니다. 네트워크 없이도 커밋할 수 있고요.

버전 관리 용어도 자주 나옵니다. 저장소에서 파일을 받아 오는 것이 체크아웃, 수정한 내용을 저장소에 반영하는 것이 체크인 또는 커밋입니다. 커밋 전에 최신 내용을 받아 합치는 것이 업데이트이고, 서로 다른 사람이 같은 곳을 고쳐 부딪히는 상황이 충돌(conflict)입니다.

통합은 미루면 이자가 붙습니다

모듈을 각자 만들고 마지막에 한꺼번에 붙이는 방식을 빅뱅 통합이라고 합니다. 이름이 불길한 이유가 있습니다. 문제가 터졌을 때 어느 모듈 때문인지 찾을 수가 없거든요. 그래서 조금씩 자주 합치는 점진적 통합을 씁니다.

여기서 두 낱말이 중요합니다. 통합 방향에 따라 필요한 가짜 모듈이 다르기 때문입니다. 하향식 통합은 상위 모듈부터 붙이므로 아직 없는 하위 모듈 자리에 스텁(stub)을 놓습니다. 상향식 통합은 하위 모듈부터 붙이므로 아직 없는 상위 모듈 대신 드라이버(driver)를 씁니다. 위에서 아래로 갈 때 스텁, 아래에서 위로 갈 때 드라이버라고 방향과 함께 외우시면 헷갈리지 않습니다.

지속적 통합(Continuous Integration)은 이 발상을 자동화한 것입니다. 개발자가 코드를 올릴 때마다 빌드와 테스트를 자동으로 돌려, 깨진 상태로 오래 방치되지 않게 합니다. 여기에 배포까지 자동화하면 지속적 배포(CD)가 되고요. "제 컴퓨터에서는 됩니다"라는 말이 사라지는 지점이 바로 이 자동 빌드입니다. 내 컴퓨터가 아니라 공용 서버가 매번 처음부터 빌드하니까요.

모듈 사이를 잇는 방식으로는 함수를 직접 호출하는 방법 외에, 메시지 형식을 정해 주고받는 방법이 있습니다. 데이터 형식으로 XML과 JSON이 자주 나오는데, XML은 태그로 구조를 나타내고 스키마로 검증할 수 있으며, JSON은 이름과 값의 쌍으로 가볍게 표현해 자바스크립트 환경에서 널리 쓰입니다.

다음 강은 이렇게 완성한 소프트웨어를 사용자에게 넘기는 단계, 패키징입니다.

인출 문제

생각해볼 질문 (정답 없음)

변경 이력을 남긴다는 것은 실수의 기록도 함께 남긴다는 뜻입니다. 팀이 이 기록을 학습에 쓰게 하려면 어떤 문화가 필요할까요.

이전: 1강 자료구조와 정렬·탐색 · 다음: 3강 제품 소프트웨어 패키징