brunch

매거진 세컨드스페이스 이야기

라이킷 23 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 세컨드스페이스 Jul 19. 2019

클라이언트가 궁금해하는 IT 서비스 개발 #2

궁금궁금해

안녕하세요. 지난 클라이언트가 궁금해하는 IT 서비스 개발 #1에 이어 2편을 작성해보려 합니다. 1편에 여러 이야기를 담으려고 했는데 하나하나 답변이 길어지는 바람에 2편을 작성하기로 하였습니다. 자고로 글은 길면 읽는 맛이 떨어지는 법이죠! 시작합니다요오오

1. 기획은 어떻게 해주시는 건가요?

많은 분들이 기획에 어려움을 가지고 계시고 기획, UX/UI에 대한 문의를 많이 해주십니다. 뭐 기획이야 간단하게 클라이언트 분들과 많은 시간을 함께하고 대화를 열심히 해서 좋은 기획을 만드려고 노력합니다. 신기술이 있다면 제안드리고 좀 더 좋은 UX를 위해서 기존의 기획을 변경도 해가면서 말이지요. 이런 이야기가 듣고 싶으셨던 건 아니었을 거고 실제 결과물이 어떻게 나오는지 궁금해하실 것 같습니다. ^____^

보통 기획 결과물로는 기능 명세서와 UX flow, 스토리보드가 나옵니다. 이 녀석들이 어떤 것들이 하나씩 봐볼까요

이런 게 기능 명세서

기능 명세서는 대분류부터 세부 항복까지 분류를 나누고 세부항목의 기능의 작동에 대한 정의해놓은 문서입니다. 보통 기획의 가장 첫 번째는 기능 명세서를 작성하는데서 시작합니다. 이 기능 명세서를 가지고 UX Flow와 스토리 보드가 생성됩니다.

UX Flow와 스토리보드는 비슷하지만 스토리보드가 좀 더 상위 개념입니다. UX Flow는 서비스의 흐름을 한눈에 볼 수 있게 만드는 반면, 너무 복잡한 내용을 다 담아내기에는 어려움이 있습니다. 간단한 서비스는 UX Fow로 제작하고, 복잡한 서비스의 경우 한 페이지에 많은 정보를 가지고 있기 때문에 스토리보드로 제작하는 것이 좋습니다.

좌측 스토리 보드, 우측 UX Flow

이미지와 같이 스토리보드는 한 페이지를 기준으로 다양한 정보를 담으며, UX Flow는 여러 페이지와의 관계를 표시해줍니다. (스토리보드는 보안상 간단한 이미지로 대체하였습니다.)

2. 확정된 기획에 따라 견적은 변경될 수 있습니다.

1번의 기획은 어떻게 해주세요 에서 이어지는 질문인데 보통 미팅 시에는 상세 기획이 정해져 있지 않습니다. 머릿속에 있는 아이디어를 설명해주시거나 레퍼런스 사이트와 비슷하게 만들어 달라고 하는 경우가 대부분입니다. 이런 경우 막상 상세 기획이 나와보면 미팅 때 이야기했던 것과 작업 범위가 다른 경우가 많습니다. 하지만 미팅 때 어느 정도의 러프한 견적과 일정을 항상 원하시기 때문에 "예상하건대 이 정도의 견적과 일정이 필요합니다. 하지만 상세 기획이 나오면 견적이 달라질 수 있습니다. :)" 라고 말씀드릴 수밖에 없습니다.

3. 백앤드, 프런트 앤드 프레임워크&라이브러리는 뭘 써야 하나요? (꼭 써야 하나요?)

이 질문은 조금 고급 질문이긴 합니다만, 서버 스펙과 개발 언어 등에 대해서 이야기를 나누다 보면 궁금해하시는 분들이 많습니다. 어떤 언어가 좋은지 프레임워크&라이브러리는 뭐가 좋은지 왜 좋은지에 관한 질문이 많습니다. 어떤 언어가 좋은지는 많은 토의가 되고 있는 부분이고 판도라의 상자 같은 것이니 패스하고 프레임워크&라이브러리를 왜 써야 하는지, 어떤 것을 써야 하는지에 대해서 이야기해 보겠습니다. (클라이언트 수준의 내용이니 전문적 내용은 없습니다.)

프레임워크를 안 쓰고 직접 개발하는 개발업체도 있는 것으로 알고 있습니다. 저는 개인적으로는 프레임워크를 사용하여 개발하는 것이 장점이 더 많다고 생각합니다. 프레임워크를 쓸 경우의 장점에 대해서 이야기해보겠습니다.

1. 안정적이다

2. 확장성이 좋다

3. 유지 보수하기 쉽다

아무래도 오랜 기간 많은 사용자가 사용했고 피드백을 받아 업데이트가 많이 되었기 때문에 성능 면에서 안정적입니다. 또한 이미 많은 기능이 들어가 있고 구조가 잘 잡혀있기 때문에 기능 추가 등 확장성이 좋습니다. 많은 사용자들이 사용 중이기 때문에 개발하기 편리한 구조로 되어있기도 하며, 유지보수가 가능한 개발자를 찾기 쉽다는 장점이 있습니다.

프레임워크를 선택하는 기준에는 언제나와 같이 제작하려는 서비스에 따라 다르며, 운영, 경영 방침에 따라서도 다릅니다. 최근에 나오는 많은 프레임워크들은 성능면에서 기능면에서도 다양한 장점이 존재하지만 오래된 프레임워크에 비해서 개발자를 찾기 어렵기 때문에 유지보수에 어려움이 있을 수 있습니다. 꼭 최신 트렌드를 따라가는 것만이 능사는 아니지요. (저희는 내부 프로젝트는 최신 트렌드를, 외부 프로젝트는 오래된 프레임워크를 사용합니다.)

프런트 앤드의 경우 사용할 필요가 있는 서비스만 사용하면 됩니다. 간단한 디자인인데 굳이 라이브러리를 사용할 필요는 없습니다. HTML Interaction을 중심으로 UX를 제공하려면 프레임워크&라이브러리를 사용하는 것이 좋습니다. 개인적으로는 Jquery는 권장하지 않습니다. Jquery소스는 복잡한 서비스의 경우 유지 보수하기 너무 어렵기 때문입니다. 또한 개발 속도도 빠르지 않습니다. 최근에는 많은 서비스들이 프런트 앤드 프레임워크&라이브러리를 사용하고 있습니다.

4. 개발된 어플을 스토어(플레이스토어, 앱 스토어)에 올려주는 거 아닌가요? + 애플 심사

앱 개발을 진행하다 보면 개발 이후 스토어 등록을 요청하시는 분들이 계십니다. 기본적으로 스토어에 앱을 올리는 업무는 꽤나 시간이 소요됩니다. 앱 개발을 맡겼는데 스토어에는 왜 등록 안 해주냐! 하시면 안 됩니다. 계약 시에 꼭 "스토어에 올려주는 작업까지 공수에 포함시켜 주세요."라고 하셔야 됩니다. 스토어에 앱을 올리기 위해서는 인증서 관리, 앱 정보 등록, 버전 관리 등 작업 범위가 적지 않습니다.

안드로이드에 비해 애플은 좀 더 복잡합니다. 앱 등록 심사가 있기 때문이죠. 가장 두려워하시는 부분이 앱 등록 심사에서 거절을 당했을 경우입니다. 과거에 비해 최근은 앱 등록이 조금 쉬워지긴 했습니다만, 거절이 되는 경우가 종종 있습니다. 거절 사유는 다양하며 개발 이슈가 아닌 경우도 많습니다. 심사 거절이 되면 일정에 차질이 있어 좋아하지 않으시고, 한번 거절당했을 때 등록되는 가능성이 줄어드는 것이 아니냐고 물으시는 분들도 있습니다. 전혀 아니라고 말씀드릴 수 있습니다. 애플 앱 심사 시 거절 사유와 수정해야 하는 부분에 대해서 상세하게 알려줍니다. 해당 부분만 수정하면 쉽게 등록이 되는 경우가 많으니 두려워하지 않으셔도 됩니다.

몇 가지 궁금해하실 부분에 대해서 정리해보았습니다. 앞으로 개발사와 이야기하실 때 해당 내용들을 참고하시어 좋은 서비스 준비하셨으면 합니다. :)