webService.Develop.Management
프로젝트 개발 관리
프로젝트 관리는 대부분 오피스 제품을 많이 사용한다. 요구사항 정의와 일정 관리인 WBS는 엑셀 파일로 관리하고, 기획 스토리보드는 파워포인트나 PDF로 관리되며, 테스트 시나리오는 엑셀 파일, 정책서나 문서는 워드 문서로 관리한다. 오피스 제품군만 있으면 대부분의 관리가 가능하다. 하지만, 개발 소스는 오피스 제품으로 관리하기 힘들다. 혼자서 개발하면 소스는 혼자서 가지고 있어서 상관없지만, 여러 명이서 같은 소스로 개발하기 위해서는 소스 관리가 필요하다.
각자의 컴퓨터에서 개발한 후에 통합하는 과정을 거치면 내 소스가 사라질 수도 있고, 상대방 소스가 사라질 수도 있다. 그리고 소스에서 어디가 어떻게 수정이나 추가됐는지도 모호해지고, 누구의 소스 인지도 모른다. 이럴 경우 프로그램 자체가 제대로 돌아가길 바라는 것은 지나친 욕심이다.
같은 소스를 누가 어디를 수정했고, 언제 수정했는지 등을 관리하는 것을 형상관리(Configuration Management)라고 부른다. configuration은 구성, 형상, 지형, 배치 등의 의미를 가지고 있다. 프로그램의 구성, 형태, 배치 등을 관리한다고 보면 이해가 쉬울 듯하다.
같은 소스를 여러 사람이 공동으로 작업하게 되면 누가 어디를 수정하고, 추가했는지 이력이 필요하다. 이력이 없으면 오류가 났을 경우 찾아내기가 여간 쉽지 않다. 이력에는 수정한 사람도 기재되어 있지만, 소스 중에 어디를 수정하고, 새롭게 추가됐는지 등을 알기 쉽게 저정되어 있어야 한다. 이력으로 소스를 전과 후를 비교해서 수정과 추가된 부분을 쉽게 찾아내고 고칠 수 있다. 이런 이력을 형상관리에서는 revision(개정)이라고 부른다. 중요문서나 법에 해당하는 문서 등등 이력을 관리해야 하는 문서에 있는 개정 목록과 같은 의미이다.
이런 형상관리를 한 사람이 소스를 받아서 일일이 살펴보고 수정되거나 추가된 부분을 표시한 후 날짜와 시간별로 관리한다면 그 사람은 아마도 제명에 살지 못할 것 같다. 여러 사람이 참여하는 프로젝트에는 하루에도 몇십 번이나 같은 소스가 수정되기 때문이다. 인간이 하기에는 더디고 하루에 다 할 수도 없는 분량이기 때문에 형상관리를 자동으로 해주는 툴(프로그램)을 사용한다. 대표적으로 SVN, Git이라는 툴이 있다.
프로그램 개발에서 소스는 인간이 알아볼 수 있는 문자로 작성한다. 이를 코딩(Coding)이라고 한다. 코딩된 소스를 그대로 컴퓨터에 실행할 수는 없다. 컴퓨터는 문장을 이해하지 못하기 때문이다. 컴퓨터는 0과 1만 알고 있다. 문자로 작성한 소스를 컴퓨터가 알 수 있도록 변환해줘야 한다. 이런 변환작업을 컴파일(Compile)이라고 한다.
컴파일(Compile)이라는 단어 자체가 편집하다, 번역하다 등의 의미가 있다. 인간이 만든 소스코드를 컴퓨터가 알 수 있게 기계어로 번역한다라고 생각하면 된다. 여러 개의 소스코드 파일을 컴파일한다고 해서 바로 실행이 되는 것은 아니다. 이런 컴파일된 소스들을 연결하고, 설정이나, 이미지 등을 가져와서 실행이 가능한 형태로 만들어야 한다. 이를 빌드(Build)라고 부른다. 단어 뜻대로 제작한다라는 의미이다.
책을 출판하는 과정을 생각해 보자. 작가는 책에 들어갈 콘텐츠를 작성한다. 글을 쓸 때 원고지에 작성할 수도 있고, A4용지에 작성할 수도 있고, 워드로 작성할 수도 있고, 그림을 그릴 수도 있다. -IT 개발에서는 이런 콘텐츠를 코딩이라고 한다.- 작성된 문서를 편집자가 책 틀에 맞춰 작업을 한다. 작성된 원문을 그대로 책으로 만들기는 힘들기 때문에 편집이 필요하다. -이런 작업이 컴파일이다.- 편집된 편집본을 인쇄소가 마지막으로 책으로 만든다. -이 작업이 빌드다.- 책으로 만들면 출판사가 가지고만 있는 것이 아닌 도서관이나 서점 등에 전달을 해야 한다. -IT에서 이를 배포라고 한다.- 서점은 사람들이 볼 수 있겠 끔 테이블에 전시를 해야 한다. -IT에서 이를 전시라고 한다.- 빌드와 배포는 전시가 가능한 형태로 만들고 서버에 배포하여 다른 사람들이 볼 수 있게 하는 작업이다.
이런 컴파일, 빌드를 형상관리처럼 사람이 수정된 소스를 컴파일하고 다시 빌드한 다면 하루 종일 컴파일, 빌드, 컴파일, 빌드.. 만 해야 한다. 머리 좋은 인간의 인력을 낭비하는 것이다. 고맙게도 컴파일과 빌드 작업을 자동으로 해주는 툴이 있다. 이런 툴을 지속적 통합(Continuous Integration) 툴이라고 하며, 대표적으로 Jenkins, Bamboo 등이 있다.
형상관리 툴로 소스를 관리하고 지속적 통합 툴로 컴파일과 빌드, 배포가 자동으로 진행되면서 개발자들은 코딩과 프로그램이 흐르는 로직에만 전념할 수 있게 되었다. 예전보다는 기간도 단축되고, 좀 더 좋은 품질의 프로그램이 가능해졌다. 형상관리 툴로 오류를 만든 개발자를 잡아낼 수 있거나, 개발자들은 다른 개발자가 작성한 소스를 보면서 시야도 넓어졌다. 지속적 통합 툴로 결과를 바로 확인할 수 있어, 오류나 버그를 인식하고 잡는 시간이 줄어서, 개발자들이 편안한 개발을 할 수 있다고 생각하면 오산이다. 오히려 이런 자동화 툴로 인해 소스 관리, 컴파일, 빌드, 배포는 개발 기간에서 삭제되면서 더 많은 기능이 추가되고, 오히려 개발자 능력에 포커스가 이동되었다.
자동화가 더 많아질수록 인간 자체에 더 포커스가 집중된다.
향후에는 소스 코딩까지 자동화가 될 수 있도록 진행 중에 있다. 사람은 그저 어떤 프로그램을 만들고 싶은지와 프로그램 흐름을 도식화한 플로우 차트만 작성하면 자동으로 코딩이 만들어질 수 있다. 이미 이와 유사한 툴로 ios의 스토리보드, 웹디자인 툴인 스케치, 디자인 공유 툴인 제플린 등이 화면 디자인만 하면 코드를 자동으로 만들어 준다. 이런 자동화 추세는 앞으로 더 많이 발전하고 출시될 것이다.
* Background Photo by Alvaro Reyes on Unsplash
