안녕하세요? 이번 글은 Bluemix를 이용하여 간단한 클라우드 애플리케이션을 디자인하고 만들어 가는 과정을 내용으로 연재되고 있습니다. 아래와 같은 순서로 진행되고 있으므로 참고 부탁 드립니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

애플리케이션 구상 및 요건 정의

지난 글에서는 클라우드에 대한 전반적인 시각을 알아보았다면 이번 글에서는 개발자의 입장에서 클라우드 애플리케이션을 어떻게 만들어갈지에 대해서 고민하고 애플리케이션이 가져야 할 기능에 대해 정의하는 내용을 다루도록 하겠습니다.

아이디어의 구체화

당연한 이야기지만 어떤 애플리케이션을 만들지에 대한 아이디어는 있어야 합니다. 뭘 만들어야 하는지도 모르는데 생각을 한다 해도 원하는 답은 아닐 겁니다. :)

일단 머릿속에 떠오르는 아이디어를 구체화 하는 것의 시작은 이 아이디어를 명확하게 정의하는 것일 것입니다. 머릿속 아이디어와 Bluemix와 같은 개발 플랫폼만으로 무언가 척적 만들 수 있다면 참 좋겠지만, 그건 마치 재료와 연장만 가지고 그냥 멋진 작품을 만들겠다는 것과 다르지 않습니다.

최근 S/W 개발 트렌드인 Agile 방식 개발을 오해해서 간단한 아이디어만 있으면 일단 만들고 보자는 식으로 시도하는 경우도 있는데, 적어도 가야 할 방향은 정하고 가야 합니다. Agile 방식 개발은 그리 크지 않은 기능을 짧은 시간에 구현하고 그 결과를 사용자의 피드백을 받아 개선하거나 폐기 할 수 있도록 하여 유연하게 대응할 수 있는 것이지 아무런 계획 없이 진행하는 것이 아닙니다. Agile 개발 방식은 하나의 개발 주기가 짧은 프로젝트로서 그 안에 계획, 설계, 구현, 평가를 통한 개발 방식이니까요. 참고로 IBM Design Thinking을 참고하시면 도움이 될 듯 합니다.

이제 다음과 같은 아이디어를 어떻게 구체화 하는지 알아 보겠습니다.

회사에 출입하는 외부 방문자를 리셉션 데스크에서 확인하고 임시 출입증을 발급 및 관리하기 위한 애플리케이션이 있었으면 좋겠다

보안 구역이나 출입에 제한이 있는 경우 이를 통제하기 위한 절차가 있다면 위와 같은 생각을 할 수 있을 겁니다. 단순히 뭘 어떻게 하고 싶다는 내용만 있는 간단한 내용인데, 이를 좀 더 구체적으로 하기 위해 다음과 같은 질문 리스트를 만들어 봅니다.

  • 이 애플리케이션의 사용자는 누구인가?
  • 이 애플리케이션 사용자의 업무 절차는 무엇인가?
  • 이 애플리케이션 사용자의 업무를 위한 데이터는 무엇인가?

가장 중요한 질문은 `이 애플리케이션의 사용자는 누구인가?'라는 것입니다.

사용자는 애플리케이션의 존재의 이유이며 이 사용자를 중심으로 애플리케이션이 가진 기능과 요소가 결정됩니다. 보통은 실 사용자를 대상으로 인터뷰를 진행하며 그 인터뷰를 통해 해당 사용자가 가진 특징과 업무에 대한 내용 그리고 현재 가지고 있는 불편하거나 개선되었으면 하는 내용을 얻을 수 있습니다. 인터뷰를 통해 개발자 또는 기획자가 사용자에 대해 공감하고 이해하는 시간을 갖게 되며 이를 바탕으로 애플리케이션 개발의 목표 및 해결 과제를 선정하게 됩니다.

그러나, 본 글에서는 실사용자 인터뷰를 진행하기 어렵기 때문에 어느정도 예상이 가능한 가상의 인물 A라고 상상해 보도록 하겠습니다. :) 인터뷰 후 우리는 A에 대해 다음과 같은 인물이라는 결론을 내렸습니다.

A는 회사 리셉셔니스트로 회사 방문 예약자 및 실제 방문자를 직접 확인하고 출입 기록 및 임시 출입증 발급, 회수 업무를 담당하고 있는 사람이다

그리고, 가상의 인터뷰를 통해 A는 리셉션 업무를 수행하는 사람으로서 다음과 같은 불편한 점이 있었음을 알 수 있었습니다.

  • 현재 종이로 된 방문자 및 임시 출입증 발급 목록을 이용하여 업무를 처리하고 있다보니 매일 아침 목록을 수령후 관리해야 함
  • 일과 이후에 방문자 목록 및 임시 출입증 발급 목록을 보안 부서로 전달해야 함
  • 방문자가 과거 방문했고 변동 내용이 없음에도 불구하고 정보를 방문자에게 다시 기입하여 작성하게됨
  • 방문자가 자신의 정보를 직접 기입하여 제출하는 형식으로 대기자가 많은 경우 처리 시간이 오래 걸림

A에 대한 정보를 통해 이 애플리케이션을 통해 개선할 부분이 명확해진 것을 알 수 있습니다.

두 번째 질문은 `이 애플리케이션 사용자의 업무 절차는 무엇인가?'입니다.

사용자 A의 업무 흐름을 파악해야 애플리케이션의 기능 및 화면을 디자인 할 수 있게 됩니다. 우선 사용자 A는 방문자확인 업무와 임시 출입증 관리 두 가지 업무가 있습니다. 따라서, 이 두 가지 업무에 대한 절차를 확인해야 합니다.

  • 방문 예정자 확인 및 출입 등록 절차 (사전 출입 등록 )

    1. 직원이 방문 예정자 정보를 1일전에 리셉셔니스트에게 전달한다.
    2. 방문자가 본인 확인을 위한 정보와 보안 요청 서류를 작성 하여 리셉셔니스트에게 전달한다.
    3. 리셉셔니스트가 방문자 예정자 리스트에서 방문자 정보를 확인한다.
    4. 에스코트 담당 직원의 방문자 현장 확인 후 출입 등록 리스트에 방문자 정보를 등록한다.
  • 방문자 확인 및 출입 등록 절차 (현장 출입 등록 )

    1. 방문자가 본인 확인을 위한 정보와 보안 요청 서류 작성과 함께 에스코트 담당 직원 정보를 작성하여 리셉셔니스트에게 전달한다.
    2. 에스코트 담당 직원에게 연락하여 직원 여부 및 방문자를 확인한다
    3. 에스코트 담당 직원의 방문자 현장 확인 후 출입 등록 리스트에 방문자 정보를 등록한다.
  • 임시 출입증 발급 절차

    1. 방문자가 리셉셔니스트에게 방문자임을 확인 할 수 있는 정보를 전달한다.
    2. 리셉셔니스트는 해당 정보 중 성명 및 연락처를 방문자 리스트에 기록하고 발급할 임시 출입증의 정보를 같이 기록한다
    3. 임시 출입증을 발급한다.
  • 임시 출입증 회수 절차

    1. 임시 출입증을 회수하고 발급된 출입증 여부를 확인한다.
    2. 일과 시간이 지난 후 보안팀에게 미회수된 임시 출입증 정보를 제공한다.

마지막 질문은 `이 애플리케이션 사용자의 업무를 위한 데이터는 무엇인가?'입니다.

이 부분은 앞서 사용자와 업무 흐름에 대한 내용이 파악되고 나면 자연스럽게 어떤 데이터가 필요한지 알 수 있습니다. 다음은 이 내용을 바탕으로 정리한 데이터입니다.

  • 방문자 예정자 확인을 위한 데이터

    1. 방문 예정자 정보 (이름, 직위, 회사, 연락처)
    2. 담당 직원 정보 (이름, 사번, 이메일, 연락처)
    3. 방문 예정 일시
  • 방문자 확인을 위한 데이터

    1. 방문자 정보 (이름, 직위, 회사, 연락처)
    2. 담당 직원 정보 (이름, 사번, 이메일, 연락처)
    3. 방문 일시
    4. 방문자 보안 사항 동의 서명 정보
    5. 발급된 임시 출입증 정보
  • 임시 출입증 관리를 위한 데이터

    1. 임시 출입증 정보 (종류 및 일련번호)
    2. 임시 출입증 발급 일시
    3. 임시 출입증 회수 일시
    4. 임시 출입증 발급자
    5. 임시 출입증 수령자
    6. 임시 출입증 회수자

이 데이터 목록은 이후 애플리케이션 자료 구조 설계에 사용됩니다.

요건 정리

이제 A의 업무 절차와 데이터를 확인 했다면 이제 다음과 같은 내용으로 요건을 작성해 볼 수 있습니다.

  • 방문자 정보에 대해 수기가 아닌 전산으로 입력/관리해야 한다
  • 방문자의 보안 동의 및 정보 확인도 전산으로 입력 받을 수 있어야 한다
  • 방문자에 대한 정보 입력 시 방문자가 아닌 리셉셔니스트가 입력하고 이를 방문자에게 확인하는 형태가 되어야 한다
  • 보안 동의 서식이나 내용은 관리자에 의해 수정 가능해야 한다
  • 입력한 데이터는 쉽게 수정 할 수 있어야 한다
  • 과거 방문 내역이나 정보에 대해 손쉽게 확인 할 수 있어야 한다
  • 에스코트 직원 확인을 위해 정보(성명, 연락처 등)를 조회 할 수 있는 기능이 있어야 한다
  • 방문 예정자에 대한 사전 정보 등록은 에스코트 직원이 직접 할 수 있어야 한다
  • 에스코트 직원은 자신이 신청/등록한 정보를 바로 확인 할 수 있어야 한다
  • 사용자에게 부여된 권한에 따라 기능이 제한되어야 한다
  • 보관되는 데이터는 암호화된 형태로 보관되어야 한다

두서가 없이 정리되었지만 앞서 업무에 필요한 내용과 함께 전산화 되었을 때 발생 할 수 있는 몇 가지 내용도 추가되어 있습니다. 이 요건을 시작으로 해서 애플리케이션으로 구현 시 필요한 기술적인 부분과 사용자 화면을 정의하게 되며 본격적으로 됩니다. 이후 요건이 변경될 수도 있으나 큰 틀을 흔드는 경우가 아니라면 이후 개발 주기에 포함 시키는 형태가 될 것입니다.

다음 포스팅에서는 이 애플리케이션에 대한 Usecase 및 화면에 대한 Wireframe을 작성하는 내용을 진행하겠습니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

참고

토론 참가

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다