프로그램 프로젝트 설계부터 납품(Deploy)까지

안녕하세요. 명월입니다.

저는 개발 경력으로는 10년 약간 넘었고, 현재는 일본에서 근무 중입니다. 순전히 개인적인 경험에 의한 글이기 때문에 이 글이 반드시 옳고 이렇게 해야 한다는 것은 아닙니다.

참고로 이렇게 개발하는 사람도 있구나 하는 정도로 가볍게 읽으시면 좋겠습니다.

제가 생각하는 프로그램 프로젝트 설계는 크게 두 가지로 나누어서 생각해야 하는 것 같습니다.

하나는 어떤 프로그램을 만들 것인가와 프로그램을 만들기 위해서 어떤 공정을 만들어야 할까입니다.

먼저 어떤 프로그램을 만들 것인가는 프로그램을 의뢰를 받아서 만드는 경우도 있고 혹은 직장 내에서 혹인 개인이 필요에 의해서 개발해야 하는 경우가 있습니다.

최근에는 웹 프로그램 기술이 많이 발전해서 게임 프로그램이 아닌 이상 웬만한 건 다 웹으로 구현이 될 듯싶습니다.

그렇다면 웹으로 프로그램을 작성한다고 했을 때, 제일 처음 고민하는 것은 어떤 언어와 어떤 플랫폼에서 작성할 것인지 고민을 해야 하겠네요.

프로그램 언어는 어떤 것을 사용해도 상관은 없다고 생각하지만 그래도 좀 빠른 개발을 해야 한다면 PHP를 사용하고 시간보다는 프로그램 상에 많은 계산식이 있고 복잡하다고 생각되면 Java(jsp)가 좋은 선택일 수 있습니다.

또 나중에 웹 이상으로 CS프로그램등의 확장성을 고려한다면 C#(ASP.NET)을 선택할 수도 있습니다. 그러나 C#의 경우는 생각보다 비용이 많이 드니, 적은 비용으로 작성을 하려고 한다면 Java가 좋을 것 같습니다.

사실 이 PHP와 Java와 C#의 언어 차이는 크게 없기 때문에, 가장 자신 있는 언어나 팀을 이룬다면 팀에서 가장 주력 언어를 선택하는 것이 좋을 것입니다.

그것이 결정되면 자연히 플랫폼은 따로 오겠네요. C#도 이젠 Core가 있어서 Linux상에서 돌릴 수 있지만 그래도 ASP.NET을 선택하면 자연히 Window Server로 갈 것이고 그 외에는 Linux가 기본으로 가게 되겠습니다.

이렇게 결정이 되면 먼저 한쪽에서는 개발 환경과 프레임워크를 구성하기 시작할 것입니다. 개발 환경은 git을 설치해야 할 것이고, 데이터베이스도 설치해야 하고, 업무를 공유할 수 있는 서버 구축등 환경을 만들고 프레임워크를 구성해야 합니다.

그리고 한쪽에서는 프로젝트의 요건 정의를 받아야 합니다.

요건 정의란 프로그램의 요구 사항을 정리한 것이라고 생각하면 됩니다.

거의 모든 프로그램은 Input에 따른 Output를 구성하는 것이기 때문에 Input Output를 구분해서 요건 정의를 만들면 됩니다.

잠시 처음으로 돌아와서 프로그램 공정에 대한 설명입니다.

프로그램의 공정은 대표적으로 워터폴과 애자일이 있습니다. 이 워터폴과 애자일의 대한 설명은 위키 백과에서 잘 설명되어 있습니다.

워터폴 - https://ko.wikipedia.org/wiki/폭포수_모델

애자일 - https://ko.wikipedia.org/wiki/애자일_소프트웨어_개발

공정을 구성한다는 것은 현재 팀이 몇 명인지를 파악해서 그 팀 맴버들이 무슨 일을 해야 하는 지에 대한 업무 분배(?)라고도 할 수 있습니다.

먼저 프로그램을 작성한다고 한다면 크게 "화면 개발"과 "서버 사이드 개발"과 "데이터베이스 관리", "서버 관리", "테스트 관리", "문서 관리"가 있겠네요.

화면 개발은 웹 프로그램을 작성하면서 브라우저에 보이는 화면을 이야기 하는 것입니다. 기본적으로 태그 구성과 CSS 작성, Javascript 작성, 그와 관련된 라이브러리(Jquery, Bootstrap 등등)이 있습니다.

서버 사이드 개발은 웹에서 Request를 받아서 Response를 하는 서버 쪽 프로그램 개발인데, 프로그램 작성과 참조 라이브러리 관리, 환경 설정 관리등이 있습니다.

데이터베이스는 데이터베이스의 쿼리 작성과 관리, 데이터베이스와 관련 된 문서 작성(ER), ORM 작성 및 관리를 합니다.

서버 관리는 소스 관리 프로그램(git)이나 프로젝트 워크 플로우 툴 관리(jira, redmine), jenkins등 CI툴 관리, 서버 스크립트, 그리고 ftp나 samba등을 관리하는 것입니다.

테스트 관리는 프로그램의 부품 테스트부터 결합 테스트, 시나리오 테스트까지 테스트 사양서를 작성하고 실시해서 프로젝트 품질을 관리하는 것입니다.

문서 관리는 프로젝트의 브런치 관리, 설계서, 테스트 사양서, 프로그램 매뉴얼, 기타 매뉴얼 등을 관리하는 것입니다.

프로젝트 매니져는 이 6개 분야의 스케줄 관리와 업무 협조 관리, 외부적으로 프레젠 테이션 등을 합니다.

이렇게 각자 담당이 배정이 되면 실질적인 공정을 만들어야 합니다.

여기서 공정이란 서로 간에 업무가 공유되면서 리스크의 영향이 적게 만들어야 하는 것입니다.

예를 들면 화면 개발이 되기 전에 서버 단의 프로그램을 작성할 수 없다고 한다면 화면과 서버 사이드 개발을 나눈 의미가 없습니다. 그냥 하나로 합쳐서 하는 게 더 빠릅니다.

다시 프로그램 작성 쪽으로 돌아갑니다.

요건 정의를 작성하면 순서대로 기본 설계, 상세 설계 그리고 코딩, 테스트까지 이루어집니다.

기본 설계와 상세 설계는 따로 나누지 않고 프로젝트 크기에 따라 한 번에 진행되어도 됩니다.

기본 설계는 화면 설계와 데이터베이스 ER 설계, 공통 부품 설계가 있고 상세설계는 그것에 따른 화면과 데이터베이스, 공통 부품을 연결하는 시퀀스 설계가 있습니다.

예를 들면, 화면 어느 페이지에서는 데이터베이스의 어떤 테이블의 데이터를 가져 온다라는 설계입니다. 또 고객에게 설계서 납품도 해야 한다고 하면, 프로그램을 위한 설계가 아닌 프로그램을 모르는 사람이 봐도 이해할 수 있는 매뉴얼도 작성이 됩니다.

설계가 완료되면 코딩을 위한 준비 단계가 들어갑니다. 특히 서버 사이드의 경우는 화면과 데이터베이스가 만들어지지 않으면 코딩하기가 어려운 면이 많은데, 제일 먼저 팀 간의 표준 코딩을 정하고 프로젝트 내에 pdf 출력이던가 excel 출력이 있으면 미리 공통 부품을 만들고, 또 오픈 프레임 워크를 설치하는 건 금방 하겠으나 프로젝트에 맞게 추상 클래스나 인터페이스를 미리 만드는 작업을 하는 게 나중에 일정이 밀리지 않는 방법이기도 합니다.

사실 여기서는 표준 코딩을 정하는 게 제일 중요합니다.

코딩 표준을 정하지 않으면 나중에 소스가 엉망진창이 됩니다. 기본적으로 소스 스타일, 함수 명명법과 클래스 구성 규약, 또 클래스 파일의 폴더 배치등 고민할 게 많습니다.

이렇게 서로 완료가 되는 시점에서 부분 부분 프로그램 작성을 맞추어서 나가면 동시에 작성이 됩니다.

이때는 테스터는 설계서를 보고 테스트 사양서를 작성해야 합니다. 예를 들면, 로그인할 때, 체크해야하는 것은 대,소문자 특수문자 포함에서 로그인이 되는지 등등의 예상되는 에러들을 생각해서 사양서를 미리 작성합니다. 코딩이 완료되면 바로 실시할 수 있게 말입니다.

이때, 서버 관리자는 테스트 서버와 Production 서버를 만들고 Deploy 절차와 스크럼 작성, 스크립트 설계서 등을 만듭니다.

그리고 최종적으로 고객의 요건이 Production에 전부 개시가 된다면 프로젝트는 완료가 될 것입니다.

프로젝트가 완료되더라도 프로젝트가 완전히 끝난 것은 아닙니다. 상황에 따라 고객의 추가 요청이나 유지 관리가 필요합니다.

이때는 프로젝트 브런치를 만들어서 위의 공정으로 설계 개발 테스트 순으로 추가 개발하면 됩니다.

물론 프로젝트가 작거나 팀 인원이 적으면 위 역할을 한사람이 두 개이상 업무를 할 수도 있습니다. 데이터베이스 관리와 서버 사이드를 같이 하던가 등등입니다.

혼자 하더라도 업무는 구별해서 진행해야 어려움이 없습니다.

위 내용은 개인적인 경험에 의해 작성된 것이고 현재 팀 내에서도 이렇게 관리되고 돌아가고 있습니다.

스타일이 다르니 제 방법은 꼭 맞는 건 아니니 참고하시면 좋을 것 같네요.

개선할 부분이 있다고 생각하면 댓글 주세요.. 참고하겠습니다.