사용자 인터페이스 설계시 고려사항

아주 거창한 이야기는 아니고.. UI를 설계하고 구현되어진 프로그램들의 리팩토링을 가끔 하면서 느끼는 점이 있어서 간단하게 몇자 글을 끄적거려봅니다.

대규모 업무프로그램을 개발할 경우에 UI설계를 너무 단순하게 생각하거나 너무 복잡하게 생각하는 경우들이 있는데, 저의 경우에는 이러한 부분들을 어떻게 구분하고 처리하는지 몇가지 정리해봤습니다.

도움이 되실지는 잘.. 모르겠네요. ㅎㅎ

일단, UI설계시에 많은 개발자들이 간과하는 것은 클라이언트 시스템과 데이터베이스, 화일시스템과의 빈번한 데이터 엑세스에 대해서 그렇게 심하게 고려하고 있지 않다는 것이지요.

구성방법

저와 같은 경우에는 다음과 같은 규칙을 정하고 UI설계를 하는 편입니다.

기본규칙
1. C/S이건 WebService이건 Session을 Connect하는 방식이 아닌 명령을 수행하고 리턴하는 구조로 설계한다.
2. 최대한 한번에 많은 처리가 가능하도록 한다.
3. SmartClient의 경우에는 최대한 많은 조건을 체크하여 서버로 완벽하지 않은 질의나 대량의 질의를 발생시키는 자료를 호출하지 않도록 한다.
4. 대량의 자료를 다운로드 해야 하는 경우에는 서버에서 생산하여 클라이언트로 전송받는 구조를 사용한다.
   ( 대표적으로 Excel생산물의 경우에는 보통 표준 레포트 출력기능을 이용한다던지 한다 )
5. Touch Point를 잘 설계하여 최소화 한다.
   ( 이 TP라는 개념은 원래 CRM에서 사용하던 개념인데.. 저는 화면설계에 이 개념을 응용해서
     많이 사용합니다.
     필요한 자료를 Accessg하는 경우를 1 TP라고 정의합니다.
     보통 필요한 자료를 계산, 접근, 처리 하기 위해서 여러번의 데이터베이스 질의나
     처리를 하는데 궁극적으로는 이러힌 TP를 최소화하는 것이 주 목적이죠. )

결론적으로 최소한의 규칙은.. 서버의 리소스를 최소한으로 사용하면서 사용자의 UI상에서 최대한 빠르게 필요한 데이터를 작업하는 것이 UI 설계의 기본이라고 생각합니다.

그래서, 저같은 경우에는 UI설계시에.. 다음과 같은 기준으로 화면을 구분합니다.

Detail 0 : UMS, HTP, MTP, UMW
Detail 1 : SDS

이렇게 구분하는 이유는 UI설계시에 비효율적인 분석, 설계 문서를 최소화하고, 꼭 필요한 부분들만 정의하기 위해서 구분합니다.

Detail 1 의 SDS ( Simple Document Screen )
화면상의 UI흐름이 단순한 CRUD성인경우에 해당화면의 UI설계와 UI Control간의 상호처리 관계, 관련 Touch Point를 위한 계산식과 데이터처리(DML)을 기술하는 선에서 분석, 설계를 마무리합니다.
관련 산출물로는 UI 디자인, Control 흐름도, 관련테이블, 관련 SQL문장등과의 연결관계를 주로 서술하죠.

Detail 0 의경우에는 보다 상세하게 분석 설계합니다.

UMS ( User Meet Screen )
사용자들이 고객과 같은 사람을 상대하거나 속도가 요구되는 화면을 의미합니다. 이런 화면들은 은행창구나 공공기관의 민원인 상대화면이므로 해당 화면들은 정말 설계를 잘해야 합니다. 가장 민감한 부분이니까요.

HTP ( Heavy Transaction Point )
화면의 구성상에서 빈번한 데이터의 수정과 중간계산형식등을 통하여 하나의 완성된 데이터를 만들기위하여 복잡한 화면의 구성이 필요한경우.
보통 이러한 화면은 800~1000여개의 UI를 설계하는 경우 20여개의 화면정도가 나오더군요.
정말 어찌할 수 없는..

MTP ( Multiply Transaction Point )
특정조건을 단순 반복하거나 대량의 반복 처리하는 경우입니다.
이 부분은 분석은 단순하지만, 실제 서버의 리소스나 UI의 구성을 무겁게 하는 경우이기 때문에 이 부분들을 잘 체크해야 합니다.

UMW ( User Many Work )
사용자가 빈번하게 사용될 화면이라고 생각되어지는 화면들을 의미합니다.

저 같은 경우에는 이러한 화면들을 별도 리스트업하고 체크해서 실제 작업 공수를 더 많이 투여할 수 있도록 조정합니다. 실제 이러한 화면들이 가장 많은 유지보수를 거치게되고 수정과 에러를 엄청 발생시키니까요.

그리고..
저는.. 화면의 분석 설계시에 다음과 같은 부분들을 더 정의합니다.

작업화면은 Resize를 고려하는지?
데이터조회조건과 작업영역, 컨트롤 영역등을 명확하게 분리하는지?
데이터 Control은 몇개인지?
데이터 표시의 Area의 갯수는 명쾌한지?
작업화면을 시작할때에 몇번의 Touch Point가 발생하는지?
데이터 질의시 Touch Point를 더 줄일 수 있는지 체크.
레이아웃 디자인시에 조회조건, 필수항목, 참조항목등의 컨트롤이 명확한ㅁ지?
상호참조되는 컨트롤들이 존재하면 그 해결책은 없는지?
에러 발생시에 메시지를 업무와 연계하여 어떻게 명쾌하게 에러가 나오는지?

그리고. Touch Point의 설계시에 다음과 같은 부분을 고려합니다.

1. 하나의 컨트롤은 Was이든 DB Server이든 가능한 한번에 1 Touch Point를 발생하도록 합니다.
2. 1 Touch Point는 최장 2초를 넘기지 않게 설계합니다.
   ( 보통 CRUD성의 조건을 전달하고 첫번쨰 자료를 응답받는 순간을 의미한다. )
3. 2초를 넘기는 경우에는 서버가 존재하면 해당 모듈을 서버모듈화 한다.
   하지만, 서버가 없으면... 메시지 처리나 쓰레딩 처리를 한다.
4. 각 클라이언트로부터의 동시 처리 용량은 5개 이상 실행하지 않는다.
   보통 Was의 경우 쓰레드 갯수가 보통 50개 정도이므로 적정한 처리 리소스 갯수는
   그때 그때 다르다...

머.. 주절주절 여러가지 글을 끄적거렸지만.
제가 생각하는 가장 중요한 개념은 TP입니다.

상당히 많은 델파이로 개발되어진 업무 소스를 보았습니다.
어떤 업무 프로그램들인 경우에는..

화면을 로딩하면서..
20 TP가 넘게 발생하기도 하도..

어떤 작업화면에서는.. 버튼 하나가.. 30 TP를 발생하기도 하더군요.
이벤트가 꼬여있기도 하고..

물론.. 당장의 C/S 프로그램에서는 문제가 없는 것 처럼 보일것이지만..
정말 많은 사용자들이 해당 서버에 붙어서..
작업을 취하게 되면.. 큰 문제를 많이 야기합니다.

흔히들.. 이런 경우에..
테스트는 몇대에서 문제없는데.. 실제 업무 몇백대에서는 문제를 일으키는 경우이죠.

아무리.. 서버가 좋아져도.. 이런 부분은 클라이언트나 서버 설계시에 중요한 체크사항입니다.
많은 초보 개발자들이 이러한 부분들을 간과하고 있어서..
조금 걱정되네요.

델파이든, 자바이든... 기본적인 원리는 변하지 않는다고 생각해요.
ㅎㅎ~

일단.. 오늘 간단하게 생각하는 내용들은 대충 이렇습니다.
다음 기회에.. 다음 글을..