UI 프로토타입 제작, 검토

UI 프로토타입 이해

1. 프로토타입(Prototype)의 뜻

프로토타입은 원래의 온전한 형태, 전형적인 예, 기초적인 표준이다. 시제품 전의 제품 원 형으로 개발 검증과 양산 검증의 과정을 거쳐 시제품이 완성된다. 프로토타입은 “새로운 컴퓨터 시스템이나 소프트웨어의 설계 또는 성능, 구현 가능성, 운 용 가능성을 평가하거나 요구 사항을 좀 더 잘 이해하고 결정하기 위하여 전체적인 기능 을 간략한 형태로 구현한 시제품”(한국어사전)이다. 프로토타입은 사용자의 요구사항이 모두 정확하게 반영될 때까지 계속하여 개선, 보완된다. 실제 수많은 애플리케이션들이 프 로토타입의 지속적인 확장, 보강을 통해 최종 설계가 완성된다.

2. 어원에 따른 접근

“프로토타입(prototype)의 사전적 의미는 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품으로, 제작물의 모형이라 할 수 있다. 소프트웨어 개발에서는 정식 절차에 따라 완 전한 소프트웨어를 만들기 전에 사용자의 요구를 받아 일단 모형을 만들고 이 모형을 사 용자와 의사소통하는 도구로 활용한다. ”(김치수, 2015). 이는 원초적이라는 뜻의 ‘프로 토타이포스’의 중간 음에서 온 것으로, 더 들어가면 “최초의”라는 뜻의 ‘프로토스’ 와 “인상”이라는 뜻의 ‘타이포스’에서 비롯된 것이다. UI에 있어 프로토타이핑이란 추후 구현될 시스템의 골격으로서, 사전에 시스템의 일부분 또는 시스템의 기초 모형이 될 것을 수행하는 과정이다.

3. 프로토타입의 의의

프로토타이핑은 설계의 결과물이 아닌 과정으로 요구사항을 반영하고, 1차 검토 후 수정 하고, 2차 요구사항을 반영하여 최종적인 시제품을 완성하기 위해 반복적으로 수행되어야 하는 단계이다. 사전에 프로토타입을 먼저 제작하고 이를 바탕으로 향후 설계될 UI의 적 정성을 평가해 수정 보완함으로써 추후 발생 가능한 오류들을 사전에 방지하여 시스템 설 계 및 개발에 소요되는 총 비용 및 노력을 절감할 수 있다.

4. 프로토타입의 활용

소프트웨어 개발에 있어 프로토타입은 설명에 대한 시간을 줄여 주며, 특히 고객과 개발 스펙을 논의 시 설득과 이해를 돕기 위해 UI 프로토타입을 만든다. 또한 추가적으로 기술 적인 검증을 위해서 프로토타입을 만드는 경우도 있다. 개발 스펙을 작성하다 보면 구현 이 가능한지 불가능한지를 미리 예측할 필요가 생기는데 이때 먼저 제작해서 사전 검증을 하는 것이다. 프로토타입 작성 후 확실하지 않으면 수정 보완 후 다시 검증한다. 이렇게 함으로써 실제 개발에 들어가기 전 최대한의 오류를 줄일 수 있다. 프로토타입은 검증을 위한 것이므로 최대한 간단하게 만든다.

UI 프로토타입 상세

1. UI 프로토타입 전략

확정된 요구사항을 기반으로 UI전략을 실체화하는 과정이며, UI 디자인 작성 이전에 미리 화 면을 설계하는 단계이다. 아날로그적인 방법으로 스케치, 그림, 글 등을 손으로 직접 작성하 는 페이퍼 프로토타입(Paper Prototype)과 컴퓨터 등 도구를 사용하여 작성하는 디지털 프로 토타입(Digital Prototype)이 있다. 환경 및 상황에 따라 적절하게 선택하여 사용하면 된다.

2. UI 프로토타입의 장점과 단점

(1) 장점

(가) 사용자 설득과 이해가 쉽다.

(나) 개발 시간이 감소한다.

(다) 오류를 사전에 발견할 수 있다.

(2) 단점

(가) 너무 많은 수정 과정을 거친다면 오히려 작업 시간이 늘어날 수 있다. 사용자 의 요구사항은 가능한 들어주되 적절한 타협이 필요하다.

(나) 자원 효율성 관점에서 보면 필요 이상으로 자원을 많이 소모한다.

(다) 정확한 문서 작업이 생략될 수 있다.

UI 프로토타입 작성 도구 및 방법

UI 프로토타입 작성 시 고려할 사항

1. 프로토타입 계획 작성

프로젝트의 상황에 따라 다르지만 일반적으로 프로토타입 작성은 계획을 수립하는 과정과 실행 후 결과를 보고하는 프로세스로 진행된다. 프로토타입 계획을 세울 때 고려할 부분 과 결과서를 작성할 때 고려할 부분을 고려하여야 한다.

2. 프로토타입 범위 확인

프로토타입의 범위는 프로젝트의 범위나 리스크 상황 등의 주변 여건을 감안해서 정해야 한다. 우선 목적을 명확히 하고 그 목적을 수행할 수 있는 환경이 마련되었는지 확인해야 한다. 특히 프로토타입 팀을 별도로 구성할 수 있는지 반드시 확인해야 한다.

3. 프로토타입 목표 확인

프로토타입을 통해서 얻고자 하는 목표를 미리 명확하게 준비해야 한다. 기능과 관련된 것인지, 성능과 관련된 것인지, 개발 환경에 관련된 것인지에 대한 부분을 고객과 협의하 여 명확하게 준비하고 진행해야 한다.

4. 프로토타입 기간 및 비용 확인

가급적 프로토타입에 투입되는 기간 및 비용은 최소화하여 목적을 달성할 수 있도록 계획 하는 것이 좋다. 검증할 범위를 너무 넓게 잡거나 기간을 많이 잡으면 고객이 원하는 목 표가 너무 커져서 오히려 문제가 될 수도 있으므로 주의해야 한다.

5. 프로토타입 산출물 확인

프로토타입에서 나오는 산출물은 실제 개발에 그대로 참조될 수 있는 수준이 되어야 한 다. 하지만 프로토타입을 통해 개발된 UI를 실제 개발 범위에 넣는 것은 좋은 방법이 아 니다. 실제 기능 요구사항을 가지고 개발되었다 하더라도 아키텍처 요소 검증을 위한 것 이므로 실제 개발에서는 참조만 하는 수준으로 활용해야 한다.

6. 프로토타입 유의 사항 확인

프로토타입은 작은 범위와 적은 인원을 가지고 최소 기간 내에 위험 요소를 식별하고 해 결하는 것이 중요하다. 가급적 프로토타입에 투입되는 기간 및 비용을 최소화하여 목적을 달성할 수 있도록 계획하는 것이 좋다. 검증할 범위를 너무 넓게 잡거나 기간을 많이 잡 으면 원하는 목표가 너무 커져서 오히려 문제가 될 수도 있으므로 주의해야 한다.

UI 프로토타입 계획 시 고려할 사항

프로젝트의 상황에 따라 다르지만 일반적으로 프로토타입은 계획을 수립하고 실행한 후에 그 결과를 보고하는 프로세스로 진행된다. 다음과 같이 프로토타입 계획을 세울 때 고려 할 부분과 권고 사항을 확인한다.

1. 프로토타입 목표 확인

가장 큰 목표는 아키텍처 검증(성능, 안정성, 개발 생산성 측면)이다. 이외에 각종 가이드 확정, 개발 환경 세팅 완료, 공통 모듈 확보, 인력 양성 등을 들 수 있다. 분석, 설계 기법이 프로젝트 팀원들에게 익숙하지 않은 경우에는 그 개선을 프로토타입의 목적으로 잡는 것을 권고한다.

2. 프로토타입 환경 확인

프로토타입을 위한 솔루션(소프트웨어 확보), 인프라 환경(하드웨어 확보)을 마련해야 한다. 분석과 설계 및 개발, 테스트 가이드 베타 버전을 확인한다. 프로토타입 개발에 필요한 환 경(개발 툴, 테스트 툴, 빌드 및 배포 툴, 형상 관리 등)을 마련해야 한다. 인프라 아키텍트 (개발자)와 협의하여 가급적 실제와 가까운 프로토타입 인프라 환경을 구축하는 것이 좋다. 대형 프로젝트의 경우 개발용 서버를 미리 도입하여 진행하는 것도 좋은 방법이다

3. 프로토타입 일정 확인

일반적으로 아키텍처가 확정된 이후 프로젝트의 실제 분석 작업이 완료되기 이전에 진행 한다. 프로토타입의 목표를 아키텍처 검증만으로 한다면 프로젝트 개발 이전에 완료해도 무방하다. 대형 프로젝트를 기준으로 프로토타입은 대략 1개월 정도로 잡는 것이 좋다. 분 석, 설계 가이드에 대한 검증을 목적으로 기간을 잡을 경우 2개월을 추가할 수도 있다.

4. 프로토타입 범위 확인

아키텍처의 핵심이 되는 요소(UI)를 프로토타입의 범위로 잡는다. 아키텍처 요소 중에 위 험이 많은 요소(검증되지 않은 요소와의 연동 등)를 범위로 잡을 수 있다. 핵심이 되는 요 소를 판단할 때에는 많은 개발자들이 참여하여 개발하는 부분인가 하는 점을 기준으로 삼 는다.

5. 프로토타입 인원 확인

프로토타입 역할은 리더, 솔루션 담당자, 인프라 담당자, 개발 환경 리더, 공통 모듈 개발 자, 프로토타입 개발자가 있다. 대형 프로젝트를 기준으로 리더 1인, 솔루션 담당자 파트 타임 2인 이상, 인프라 담당자 파트타임 1인, 개발 환경 리더 겸 공통 모듈 개발자 1인, 프로토타입 개발자 3~4인으로 구성된다.

6. 프로토타입 아키텍처 검증 확인

기 수립된 아키텍처로 주어진 비즈니스 요구사항을 모두 만족할 수 있는지 검증한다. 인 프라 환경이 가능하다면 아키텍처 요소 간의 성능을 측정하여 결과 보고한다. 아키텍처에 대한 검증 요소는 품질속성별로 존재할 수 있으나 프로토타입을 통해서 모든 품질속성을 보여줄 수는 없다. 일반적으로 기능 요구사항을 만족시킬 수 있는지 여부와 일부 구간의 성능 측정을 하는 것을 권고한다.

7. 프로토타입 이슈 및 해결

프로토타입을 통해서 발생하는 이슈를 모두 취합하여 보고한다. 프로토타입에서 나오는 이슈의 대부분은 아키텍처 요소 검증 중에 발생하며 분석, 설계 이슈와 개발 환경 등의 이슈가 추가될 수 있다. 프로토타입은 이슈가 많이 발생할수록 좋은 것이다. 따라서 프로 토타입을 통해서 발생한 이슈와 해결한 이슈의 종류별 개수를 취합하여 결과 보고하는 것 이 좋다. 프로토타입 리더가 날마다 이슈를 취합하고 해결 방법을 제시한다. 이것을 모두 정리하여 결과 보고에 반영한다.

8. 프로토타입 가이드 확정

프로토타입에서 검증하려고 한 표준 가이드(분석, 설계, 개발, 테스트 가이드)를 프로토타 입을 하면서 수정하여 최종 확정한다. 프로토타입은 실제 개발과 유사하여 각종 가이드를 실전에 가장 가깝게 만들 수 있으므로 가능한 모든 가이드를 적용하는 것이 좋다.

9. 프로토타입 개발 생산성 확인

프로토타입을 진행하면서 가장 많은 시간이 소요되는 구간(분석, 설계, 개발, 테스트 등)을 찾아 그 원인을 찾고 시정할 수 있는 방법을 찾아 실제 프로젝트에 적용하면 많은 시간을 절약할 수 있다. 프로토타입을 진행하면서 프로토타입 개발자들이 분석, 설계, 개발, 테스 트하는 시간을 분 단위로 적게 하여 매일 취합한다. 가장 많은 시간이 소요되는 부분을 찾고 그 원인을 분석하여 해결 방법을 제시한다.

10. 프로토타입 결과 시연

프로토타입의 결과(화면 위주)를 고객, PM, PL 개발자에게 시연한다. 프로토타입의 목적을 구체적으로 설명한다. 개발이 완료된 화면 위주로만 시연하지 말고 분석, 설계, 개발, 테 스트 과정을 모두 설명하면서 시연하는 것이 중요하다. 확정된 가이드 및 개발 환경 구조, 그리고 재활용이 가능한 공통 모듈 등을 같이 소개하는 것이 좋다.