개발 전과 후에 이루어지는 것

January 21, 2025

개발 전에 이루어지는 것

  • 웹 애플리케이션이 어떤 목적으로 누구를 위해 설계되고 향후 어떻게 발전해 나갈 것인지에 대해 알고 있는 개발자와 그렇지 못한 개발자 사이에는 큰 격차가 생길 수 밖에 없습니다.

아이템 선정

  • 아이템 선정은 어떤 제품을 만들어서 어떤 서비스를 제공할 것인지를 결정하는 일입니다.
  • 처음 아이템을 선정할 때는 다양한 아이디어를 취합합니다.
  • 그중에서 곧바로 최종 아이템 하나를 결정하기보다는 몇 가지 괜찮은 아이디어를 선별하는 것이 좋습니다. 아무리 좋은 아이디어가 담긴 아이템이,라도 시장조사와 벤치마킹을 하다 보니 고객 수요가 없다거나 시장 상황과 맞지 않다는 것을 발견할 수도 있습니다.

시장조사

  • 선정된 아이템이 시장에서 필요한지, 수요가 있는지 점검하기 위해 시장조사를 합니다.
  • 시장조사 단계에서는 아이템과 관련 있는 현재 정보뿐만 아니라 미래의 잠재 고객에 대해서도 조사해야 합니다.

벤치마킹

  • 벤치마킹은 우리 서비스와 유사한 경쟁 제품이 있는지 조사하는 행위입니다.
  • 비교 분석을 통해 장점은 흡수하고 단점은 보완하기 위해 실시합니다.
  • 벤치마킹할 때는 최소 3개 이상의 제품을 선정하는 것이 좋고, 벤치마킹할 제품을 반드시 직접 사용해봐야 합니다. (제품을 사용해보지 않고 경쟁 제품의 웹사이트 혹은 뉴스 기사, 리뷰만을 보고 제품을 조사했다고 착각하면 안 됩니다.)

아이템 구체화

  • 최초에 아이템을 선정할 당시는 시장조사나 벤치마킹을 하지 않은 상태이기 때문에 시장조사 및 벤치마킹 단계를 거치면서 처음 기획했던 아이템이 변경되기도 합니다.

사용자 분석

  • 웹 애플리케이션의 사용자가 누구인지 정확히 알아야 합니다. 이는 개발하는 데 있어 가장 중요한 부분입니다.
  • 가장 먼저 서비스를 이용할 주 사용자와 부 사용자를 정의하고 이를 바탕으로 사용자 모델링을 합니다.
  • 사용자 모델을 만드는 이유는 서비스 기획 과정에 참여한 여러 사람이 서로 다른 사용자를 생각하면서 말하지 않도록, 모두가 명확하게 인지할 수 있는 하나의 사용자 모델을 통해 공감하게 하는 데 있습니다.
  • 사용자 모델링을 하기 위해 주로 인지적 모형과 역할 모형을 사용합니다.
    • 인지적 모형 : 사용자가 시스템을 어떻게 이해하는지, 사용 과정을 어떻게 배우는지, 실제로 어떻게 사용하는지 나타내는 모형
    • 역할 모형 : 사용자와 시스템 간 상호 역할 관계와 관련된 모형

정보 구조 설계

  • 앞에서 도출한 정보를 바탕으로 정보 구조(IA)를 설계합니다.
  • 정보 구조 설계란 웹에서 제공하는 콘텐츠를 체계화하고 이용자가 빠르고 정확하게 원하는 콘텐츠에 접근할 수 있는 구조를 만드는 기술입니다.
  • 정보 구조 설계는 구조, 네비게이션, 레이블링, 검색, 콘텐츠 디자인으로 구성되어 있습니다.

사이트맵

  • 사이트맵은 책의 목차와 같이 제공되는 서비스, 즉 웹사이트의 콘텐츠를 분류하고 사이트에서 제공하는 모든 메뉴를 구조화하는 것입니다.

와이어프레임

  • 와이어프레임은 화면 단위로 레이아웃을 설계하고 서비스 흐름을 정의하는 것입니다.

스토리보드

  • 스토리보드에는 와이어프레임을 통해 만들어진 화면 레이아웃에 실질적인 콘텐츠를 배치하고 콘텐츠 사용법도 상세히 기록합니다.
  • 또한 정책, 프로세스, 기능 정의, 데이터베이스 연동 등 서비스 구축을 위한 모든 정보가 담깁니다.
  • 스토리보드는 개발을 위한 최종 산출물에 해당합니다.

프로토타입

  • 프로토타입은 실제 구현할 서비스와 흡사한 모형을 만드는 작업입니다.
  • 정적인 화면으로 설계된 와이어프레임 또는 스토리보드에 인터랙션을 적용함으로써 실제 서비스가 동작하는 것처럼 시뮬레이션할 수 있기 때문에 간접적인 사용자 테스트가 가능합니다.
  • 이해관계자는 프로토타입을 통해 서비스에 대한 이해를 높일 수 있고, 개발 전 정밀한 요구사항을 도출해낼 수 있습니다.

개발 후에 이루어지는 것

  • 개발을 완료하면 웹 애플리케이션이 사용자의 요구를 충분히 만족시키는지, 기능에 결함이 없는지 등을 테스트합니다.
  • 일반적인 테스트 절차
    1. 테스트 계획서를 작성합니다.
    2. 테스트 케이스를 작성합니다.
    3. 단위 테스트를 진행합니다.
    4. 테스트 시나리오를 작성합니다.
    5. 통합 테스트를 진행합니다.
    6. 테스트 결과를 바탕으로 요구사항을 만족하지 못한 프로그램을 보완합니다.
    7. 모든 테스트 결과로 기대 값이 나올 때까지 반복적으로 진행합니다.

테스트 케이스 작성

  • 테스트 케이스는 애플리케이션이 사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 명세서입니다.

단위 테스트

  • 단위 테스트는 테스트가 가능한 가장 작은 단위 기능을 실행해서 예상대로 작동하는지 테스트하는 것입니다.

테스트 시나리오 작성

  • 테스트 시나리오는 여러 개의 테스트 케이스를 묶은 집합에 테스트 케이스를 적용하는 구체적인 절차를 정의한 문서입니다.

통합 테스트

  • 대규모 프로젝트에서는 일반적으로 최소 3번의 통합 테스트를 진행합니다.
  • 모든 화면을 개발 완료할 때까지 기다렸다가 진행하는 것이 아니라, 우선순위가 높은 화면의 개발이 끝나면 1차 통합 테스트를 진행하고 1차 통합 테스트를 진행하는 동안 추가로 개발한 화면과 1차 통합 테스트에서 결함이 드러난 화면을 모아서 2차 통합 테스트를 합니다.
  • 마지막으로 1, 2차 통합 테스트에서 결함이 드러난 화면과 나머지 모든 화면을 모아서 3차 통합 테스트를 합니다.

빌드와 배포

  • 개발한 모든 프로그램을 운영 서버에 반영하는 것을 배포라고 합니다. 그리고 배포를 위한 파일 생성 과정을 빌드라고 합니다.