출제기준 세세항목: IDE 도구 · 협업도구 · 형상관리 도구
혼자 작은 프로그램을 만들 때는 내 컴퓨터의 폴더 하나면 충분합니다. 하지만 여러 사람이 각자 모듈을 만들어 하나의 제품으로 합쳐야 하면 문제가 달라집니다. 누가 어떤 파일을 고치고 있는지, 어제 잘 되던 기능이 누구의 변경 때문에 깨졌는지, 지금 고객에게 나간 버전은 정확히 어떤 코드인지를 알 수 있어야 합니다.
통합 구현 관리는 이런 혼란을 도구로 정리하는 일입니다. 각자 코드를 쓰는 작업 공간(IDE 도구), 사람과 사람 사이의 소통 통로(협업도구), 코드와 문서의 변경 이력을 지키는 장치(형상관리 도구)가 세 축입니다.
IDE는 Integrated Development Environment, 우리말로 통합 개발 환경입니다. 예전에는 메모장 같은 편집기로 코드를 쓰고, 따로 컴파일러를 실행하고, 또 다른 프로그램으로 오류를 추적했습니다. IDE는 이 일들을 한 프로그램 안에 모아 둔 것입니다.
IDE가 해 주는 일을 흐름대로 보면 이렇습니다. 코드를 쓰는 동안 문법 오류에 밑줄을 긋고 이름을 자동 완성해 주는 편집 기능, 쓴 코드를 실행 가능한 형태로 바꾸는 컴파일·빌드 기능, 원하는 줄에서 실행을 멈추고 변수 값을 들여다보는 디버깅 기능, 완성된 결과물을 실행하거나 배포하는 기능이 있습니다. 여기에 형상관리 도구나 데이터베이스 같은 외부 도구와 연결하는 기능, 필요한 기능을 덧붙이는 플러그인 확장도 대부분 제공합니다.
대표적인 IDE로는 자바 개발에 오래 쓰여 온 Eclipse, 마이크로소프트의 Visual Studio, JetBrains의 IntelliJ IDEA, 안드로이드 앱 개발용 Android Studio, 애플 플랫폼용 Xcode 등이 있습니다. 어떤 IDE를 고를지는 개발 언어와 대상 플랫폼, 팀이 이미 쓰는 도구와 잘 연결되는지를 기준으로 판단합니다. 팀원끼리 같은 IDE와 같은 설정을 쓰면 '내 컴퓨터에서는 되는데'라는 문제가 줄어듭니다.
협업도구는 함께 일하는 사람들이 같은 정보를 보고 같은 방향으로 움직이게 도와주는 소프트웨어입니다. 꼭 같은 사무실에 있지 않아도 일이 굴러가게 만드는 것이 목적입니다.
쓰임새별로 나눠 보면 이해가 쉽습니다. 할 일을 카드나 이슈로 만들어 담당자와 마감일을 붙이고 진행 상태를 보여 주는 작업·일정 관리 도구(Jira, Trello 등), 회의 없이도 빠르게 묻고 답하는 메신저형 도구(Slack 등), 설계서나 회의록을 함께 쓰고 고치는 문서 공유 도구(Confluence, 구글 문서 등), 코드를 올리고 서로의 변경을 검토하는 코드 공유 플랫폼(GitHub, GitLab 등)이 있습니다.
협업도구의 가치는 기록이 남는다는 데 있습니다. 구두로 정한 일은 잊히지만, 이슈에 적힌 결정과 그 이유는 몇 달 뒤에도 찾아볼 수 있습니다. 그래서 협업도구는 다음에 볼 형상관리 도구와 연결해, 어떤 이슈 때문에 어떤 코드가 바뀌었는지까지 이어 볼 수 있게 쓰는 경우가 많습니다.
형상관리(SCM, Software Configuration Management)는 소프트웨어를 만드는 동안 생기는 산출물의 변경을 체계적으로 추적하고 통제하는 활동입니다. 여기서 관리 대상은 소스 코드만이 아닙니다. 요구사항 명세서, 설계서, 테스트 계획서, 매뉴얼처럼 개발 과정에서 나오는 문서도 모두 포함되며, 이렇게 관리 대상으로 정한 하나하나를 형상 항목이라고 부릅니다.
형상관리에서 자주 나오는 말이 베이스라인(기준선)입니다. 검토와 승인을 마쳐 '이 시점의 이 상태를 공식 기준으로 삼는다'고 정해 둔 것입니다. 베이스라인 이후의 변경은 아무나 마음대로 할 수 없고, 정해진 절차를 거쳐야 합니다.
형상관리를 하는 이유는 세 가지로 정리됩니다. 언제든 과거의 특정 상태로 돌아갈 수 있고, 누가 무엇을 왜 바꿨는지 추적할 수 있으며, 무분별한 변경을 막아 제품의 품질과 일관성을 지킬 수 있습니다. 변경을 통제해 혼란과 재작업을 막으므로, 결과적으로 개발 전체 비용을 줄이는 데에도 기여합니다.
형상관리는 네 단계로 진행됩니다. 첫 번째 형상 식별은 무엇을 관리할지 정하고 이름과 번호를 붙이는 단계입니다. 관리 대상에 들어가지 않은 것은 변경을 추적할 수도 없으니, 모든 일의 출발점입니다.
두 번째 형상 통제는 변경 요청이 들어왔을 때 그 변경을 받아들일지 판단하고, 승인된 변경만 베이스라인에 반영하는 단계입니다. 변경이 다른 부분에 미칠 영향과 비용을 따져 보고 승인 여부를 정하는 역할을 형상 통제 위원회(CCB, Configuration Control Board)가 맡습니다.
세 번째 형상 감사는 변경이 승인된 대로 제대로 반영되었는지, 베이스라인이 온전한지를 검토하는 단계입니다. 마지막 형상 기록(상태 보고)은 지금까지의 변경 내용과 현재 상태를 문서로 남겨 관련된 사람들에게 알리는 단계입니다. 정할 것을 정하고(식별), 바꿀지 판단하고(통제), 잘 바뀌었는지 보고(감사), 남긴다(기록)는 흐름으로 기억하면 됩니다.
형상관리를 실제로 해 주는 도구는 흔히 버전 관리 도구라고도 부르며, 저장소를 어떻게 두느냐에 따라 세 가지 방식으로 나뉩니다. 공유 폴더 방식은 버전 관리 자료를 공용 폴더에 두고, 개발자가 자기 작업 공간에서 고친 파일을 그 폴더로 복사해 반영하는 가장 단순한 방식입니다. RCS, SCCS 같은 초기 도구가 이 계열입니다.
클라이언트-서버 방식은 중앙 서버에 저장소 하나를 두고, 개발자들이 서버에서 파일을 받아 고친 뒤 다시 서버에 올리는 방식입니다. CVS와 그 단점을 보완한 SVN(Subversion)이 대표적입니다. 이력이 한곳에 모여 관리가 쉬운 대신, 서버에 접속할 수 없으면 이력 조회나 반영을 할 수 없고 서버가 망가지면 전체가 위험해집니다.
분산 방식은 원격 저장소가 있되, 개발자마다 저장소 전체를 복제한 로컬 저장소를 가집니다. 먼저 내 로컬 저장소에 변경을 기록하고, 원하는 때에 원격 저장소와 주고받습니다. 네트워크가 없어도 이력을 남길 수 있고, 저장소 사본이 여러 곳에 있어 한 곳이 망가져도 복구가 가능합니다. Git이 가장 널리 쓰이며, Mercurial도 같은 계열입니다.
도구가 달라도 기본 동작의 이름은 비슷합니다. 저장소에서 작업할 사본을 받는 것(체크아웃. Git에서 원격 저장소를 처음 통째로 복제할 때는 clone), 고친 내용을 저장소에 기록하는 것(커밋), 다른 사람의 변경을 받아 내 사본을 최신으로 맞추는 것(업데이트, Git에서는 pull), 원래 흐름에서 갈라져 따로 작업하는 것(브랜치), 갈라진 작업을 다시 합치는 것(병합, merge)이 있습니다. 두 사람이 같은 부분을 서로 다르게 고쳐 자동으로 합칠 수 없는 상태를 충돌(conflict)이라고 하며, 이때는 사람이 직접 어느 쪽을 남길지 정해야 합니다.
출시 하루 전, 새로 넣은 기능 때문에 로그인이 실패하는 문제가 발견되었습니다. 형상관리 도구의 이력에서 그 기능이 들어간 커밋을 찾아 되돌리고, 지난주 베이스라인 상태로 출시한 뒤 문제를 따로 고쳤습니다. 이력이 없었다면 어디까지 되돌려야 할지조차 알기 어려웠을 것입니다.
협업도구에 '검색 결과 정렬 오류'라는 이슈를 만들고, 그 이슈 번호를 커밋 메시지에 적어 코드를 고쳤습니다. 석 달 뒤 같은 코드에서 의문이 생겼을 때, 커밋 메시지의 번호로 이슈를 찾아 당시의 논의와 고친 이유를 바로 확인할 수 있었습니다.
영업 부서가 출시 2주 전에 결제 방식 하나를 더 넣어 달라고 요청했습니다. 형상 통제 위원회는 영향 범위와 테스트 기간을 따져 본 뒤 이번 버전에는 반영하지 않고 다음 버전으로 미루기로 결정했고, 그 결정과 이유를 형상 기록으로 남겼습니다.