구축의 기본 절차 (4) 구현과 테스트, 그리고 구현 이후
구현 단계의 정의
구현 단계란, 설계가 확정된 이후 실제 산출물을 만들어 내는 과정입니다. 워터폴 기반 SI 프로젝트에서는 화면 설계서가 확정되는 시점이 구현의 출발점이 되며, 이 단계에서 디자인, 퍼블리싱, 프로그래밍이 순차적으로 진행됩니다. 각 단계는 독립된 작업처럼 보이지만, 실제로는 앞 단계의 결과물을 기반으로 다음 단계가 이어지는 구조를 가지고 있습니다.
따라서 구현은 단순 제작 과정이 아니라, 설계 의도를 현실의 작동 가능한 결과물로 전환하는 절차라고 정의할 수 있습니다.
구현 단계의 흐름과 맥락
구현 단계는 디자인으로 시작됩니다. 디자인 단계에서는 화면 설계서를 기반으로 그래픽 작업이 진행되며, 이 과정은 단순한 시각화가 아니라 ‘재해석’의 성격을 가집니다. 트렌드에 맞추어 표현 방식을 다듬고, 기존에 정의된 요소는 유지하되 조합을 새롭게 구성하며, 브랜드 가치를 높이는 방향으로 미적인 완성도를 더합니다.
그러나 이 재해석은 어디까지나 설계 범위 안에서 이루어져야 합니다. 기획의 관점에서는 화면 설계서에 정의된 요소와 구조, 순서가 유지되어야 하며, 디자인 과정에서 요소가 삭제되거나 구조가 변경되는 경우에는 적절한 피드백이 필요합니다. 디자인은 재료를 활용해 맛을 내는 단계이지만, 재료 자체를 바꾸는 단계는 아닙니다. 그래픽적 완성도를 통해 사용자 몰입을 높이는 것이 목적이기 때문에, 해석 과정에서 구조적 일탈이 발생하지 않도록 기획자가 기준을 점검해야 합니다.
디자인이 완료되면 퍼블리싱 단계로 넘어갑니다. 퍼블리싱은 디자인된 결과물을 HTML, CSS, JavaScript로 구현하여 웹 브라우저에서 실제로 보이도록 만드는 작업입니다. 이는 일종의 디지털화 과정입니다. 화면을 코드로 재구성하고, 필요한 인터랙션을 삽입하여 사용자가 클릭하고 움직일 수 있는 상태로 만듭니다. 다만 이 단계에서는 회원 가입이나 결제와 같은 기능 구현은 이루어지지 않습니다.
이후 프로그래밍 단계에서는 퍼블리싱된 화면에 실제 기능을 연결합니다. 회원 가입, 결제, 데이터 처리와 같은 로직을 구현하고 API를 연동하여 화면과 서버가 연결됩니다. 이 단계까지 완료되면, 비로소 하나의 움직이는 상품이 완성됩니다. 다시 말해 구현의 시작은 화면 설계서 확정이지만, 구현의 끝은 테스트 가능한 상태의 상품이 만들어지는 시점입니다.
구현 완료 이후의 전환
구현이 완료되면 작업 관리서상 전체 일정의 약 90% 이상이 완료로 표시됩니다. 이 시점부터는 테스트가 가능한 환경이 마련되며, 본격적인 검수 단계로 전환됩니다. 검수를 진행하기 위해서는 ‘검수 계획서’를 먼저 작성해야 합니다. 이 계획서는 기획자가 작성하며, 단위 테스트와 통합 테스트로 구분됩니다. 구현 단계가 제작 중심이었다면, 검수 단계는 기준 충족 여부를 확인하는 과정이라고 볼 수 있습니다.
실무에서는 각 단계가 완료될 때마다 기획자가 기준에 부합하는지 확인합니다. 디자이너가 작업을 완료하면 기획팀에 검수 요청을 하고, 통과되면 퍼블리싱으로 넘어갑니다. 퍼블리싱 완료 후에도 동일한 방식으로 확인이 이루어지며, 이후 프로그래밍 단계로 진행됩니다. 이처럼 단계별로 확인을 거치면서 진행되는 구조가 워터폴 방식의 특징입니다. 특히 크로스 브라우징과 같은 이슈는 기획자가 반드시 확인해야 할 사항입니다. 특정 브라우저에서는 정상적으로 보이지만, 다른 브라우저에서는 화면이 깨질 수 있기 때문입니다. 이러한 문제는 퍼블리싱 단계에서 발생하지만, 최종 책임은 기준을 검수하는 기획자의 확인 과정에 있습니다.
테스트와 작업 관리서
구현이 끝나면 테스트 단계로 진입합니다. 이 과정은 ‘작업 관리서’를 통해 관리됩니다. 작업 관리서는 정보 구조도와 유사한 형식을 가지며, 각 페이지별로 기획, 디자인, 퍼블리싱, 프로그래밍의 완료 여부와 담당자, 상태값을 기록하는 문서입니다. 이를 통해 각 페이지가 어느 단계까지 완료되었는지를 한눈에 확인할 수 있습니다. 구현이 모두 완료되어 90% 이상이 표시되는 시점이 바로 검수를 본격적으로 시작할 수 있는 기준점입니다.
단위 테스트와 통합 테스트의 차이
검수 계획서에서 단위 테스트는 페이지 단위로 이루어집니다. 예를 들어 장바구니 페이지라면, 해당 페이지에서 발생할 수 있는 모든 케이스를 점검하여 정상 작동 여부를 확인합니다. 화면 설계서에 기재된 항목을 기준으로 테스트가 진행되며, 모든 항목이 정상적으로 동작하면 해당 페이지는 통과로 처리됩니다.
단위 테스트는 보통 기획자가 작성하고, QA 팀이 있는 경우에는 QA가 이를 보완하여 진행합니다. QA 조직이 없는 프로젝트에서는 기획자가 직접 테스트를 수행하기도 합니다. 각 테스트 케이스에는 별도의 테스트 아이디가 부여되며, 오류가 발생하면 그 원인을 기록하고 수정 후 재검수를 반복합니다. 전체 페이지가 정상으로 확인될 때까지 이 과정은 지속됩니다. 단위 테스트는 보통 2주에서 한 달가량 진행됩니다.
단위 테스트가 페이지 내부 기능을 검증하는 과정이라면, 통합 테스트는 사용자의 흐름을 기준으로 시스템 전체를 검증하는 과정입니다. 예를 들어 비회원 사용자가 사이트를 방문해 상품을 탐색하고, 주문 과정에서 회원 가입을 진행하고, 쿠폰을 적용하여 결제하는 일련의 과정을 하나의 시나리오로 테스트합니다. 이 과정에서는 단위 테스트에서는 발견되지 않았던 로직 오류가 드러날 수 있습니다. 특히 커머스 사이트의 경우 결제와 관련된 오류는 치명적이기 때문에, 결제 유형별로 테스트 케이스를 세분화하여 점검해야 합니다. 통합 테스트의 목적은 실제 사용 흐름 속에서 발생할 수 있는 논리적 결함을 발견하는 데 있습니다.
오픈과 프로젝트 종료
테스트가 완료되면 오픈 시기를 확정합니다. 오픈 일정이 정해지면 개발 서버에서 작업한 내용을 라이브 서버로 이관하고, 도메인을 연결하여 서비스를 실제 환경에 공개합니다. 라이브 전환 이후에는 에이전시 측에서 1~2주 정도 대응 기간을 둡니다. 이 기간 동안 발생하는 오류나 이슈에 대응하며 안정화를 진행합니다. 이 대응 기간이 종료되면 프로젝트는 공식적으로 마무리되고, 에이전시는 철수하게 됩니다.
정리
구현 단계는 화면 설계서를 기준으로 디자인, 퍼블리싱, 프로그래밍이 순차적으로 진행되는 과정입니다. 구현의 출발은 설계 확정이며, 구현의 완성은 테스트 가능한 상품의 완성입니다.
이후 단위 테스트와 통합 테스트를 통해 기준 충족 여부와 로직 오류를 검증하고, 모든 검수를 통과한 뒤 오픈이 이루어집니다. 그리고 안정화 기간을 거쳐 프로젝트는 종료됩니다. 이러한 흐름이 워터폴 기반 SI 프로젝트에서 구현과 검수, 오픈까지 이어지는 전형적인 구조입니다.