언제나 이것들이 궁금하지
앱/웹 개발을 진행하며 많은 클라이언트 분들을 만나고 미팅을 진행해보면 거의 물어보시는 게 비슷비슷합니다. 물론 IT 서비스에 이미 많은 경험을 하시어 궁금해 하기보다 먼저 "이 기술로 만들어 주시죠."라고 하시는 분들도 계십니다. 그렇지만 경험상 대체로 "나는 아무것도 모른다. 전부 다 알려줘야 한다"의 경우가 많습니다. 그. 래. 서 준비해보았습니다. 미팅 시에 가장 많이 듣는 질문과 물어보진 않지만 자연스럽게 알려드려야 하는 내용들에 대해서 이야기해보겠습니다. (업계 분들은 이 글 내용이 너무나 쉬운 내용이므로 스킵을 추천드립니다.)
PC/Mobile 웹 사이트는 당연히 함께 의뢰하게 됩니다. 모바일에서 서비스를 하지 않을게 아니라면 말이죠. 태블릿까지 포함하여 3종 디자인이 나오는 경우도 있습니다만, 국롤은 2종입니다. (2종이 맞아요. 맞는 거라고 할 거예요.) 2종 디자인을 만드는 방법은 반응형과 모바일 사이트를 하나 더 만드는 것입니다.
반응형은 브라우저의 크기에 맞춰서 사이트의 디자인이 변경되는 것입니다. 브라우저 우측을 잡고 쭉쭉 늘렸다가 줄이면 짜라란 하고 사이트가 변경됩니다. 여러분의 친구 세컨드스페이스 사이트가 바로 반응형이죠. (방문하셔서 막 쭉쭉 늘려보시라구요)
모바일 사이트가 따로 존재하는 아주 대표적인 예로는 우리의 초록 친구 헐크 네이버가 있습니다. 네이버의 모바일 사이트의 주소는 m.naver.com으로 주소 자체가 분리됩니다. naver.com에서는 브라우저를 줄여봐도 디자인이 변경되지 않습니다.
네 알겠습니다. 중요한 건 뭐가 더 좋냐는 거죠. 사실 뭐가 더 좋냐는 없습니다. 장단점이 다를 뿐이지요. 반응형은 하나의 주소에서 사용하기 때문에 관리하기가 쉽습니다. 내용이 변경되어도 html 소스만 바꾸면 될 뿐이지요. 그러나 별도 모바일 사이트는 사이트 주소가 다르기 때문에 하나의 내용이 변경되어도 최소 2개의 파일을 수정해야 합니다. 관리적인 측면에서는 반응형이 더 좋다는 점을 알 수 있습니다.
그런데 말입니다. 왜 굳이 네이버는 별도 모바일 사이트를 사용했을까요? 우리는 이점을 주목해야 합니다. 그 이유는 반응형의 경우 1. 디자인의 주가 되는 PC 디자인에서 많은 변화를 주기 어렵다는 점입니다. 이미 HTML 구조가 잡혀있기 때문에 모바일에서만 특별한 레이아웃을 보여주기 어려운 것이죠. 2. 트래픽 낭비가 있습니다. 반응형에서 PC/모바일 디자인이 다를 경우 모바일에서만 보이는 요소들이 있을 수 있습니다. 해당 요소는 PC에서는 눈에 보이지 않지만 실제로 HTML/CSS를 불러오기 때문에 그만큼 속도적인 측면에서 느려집니다.
네이버와 같이 규모가 크고 많은 콘텐츠가 있는 사이트의 경우 반응형으로 만들 경우 장점보다 단점이 부각되지만 세컨드스페이스와 같이 콘텐츠가 적은 경우는 반응형으로 만들어도 크게 속도 차이가 나지 않습니다. 대신 별도 모바일 사이트를 만들 경우의 관리적 측면에서의 단점이 부각되게 됩니다.
결론적으론 사이트가 작거나 관리비용을 줄이려면 반응형, 사이트가 크거나 관리자가 충분하다면 별도 모바일 사이트로 만드는 것이 좋습니다. 물론 100% 정답은 아니니 서비스의 유형과 운영 방침에 따라 선택해야 합니다.
요새는 네이티브 앱을 만들기보다 초기에는 하이브리드 앱으로 만드는 것이 트렌드가 되어가고 있습니다. 그 이유로는 빠른 개발 속도, 저렴한 가격, IOS/Android 멀티 플랫폼 지원 등이 있을 수 있겠습니다. 하이브리드 앱의 장점을 이미 써버렸지만 대체 무엇인지부터 알고 넘어가 보겠습니다.
앱의 개발 종류를 저희는 3가지로 구분합니다. 네이티브 앱, 하이브리드 앱, 웹앱
네이티브 앱은 말 그대로 모바일 네이티브 언어로 만드는 것입니다. 빠르고 고급지고 비싸고 관리비용이 많이 듭니다. (네이티브 앱으로 만들었다고 하면 다른 사장님들께 와 그거 대단한데 라고 이야기 들으실 수 있습니다. 아마도)
하이브리드 앱은 네이티브 언어를 사용하지 않고 Javascript 등의 언어를 이용하여 개발을 진행하고 네이티브 언어로 변환해주는 React Native, Flutter 등의 프레임워크를 이용하는 것입니다. 퍼포먼스는 네이티브 앱보다 떨어지지만 모바일 특성에 맞게 개발할 수 있습니다. 개발&관리비용을 절감할 수 있습니다. 다만 하이브리드 프레임워크는 짧은 기간 동안 변화가 빠르게 때문에 같은 소스여도 1년 뒤에 업데이트를 할 경우 개발 환경을 다시 세팅해야 하는 등의 단점이 있습니다.
웹앱은 말 그대로 웹 사이트를 만든 뒤 앱에서는 해당 웹 사이트만 보여주는 방식입니다. 많은 수의 쇼핑몰 앱에서 이와 같이 개발을 진행하고 있습니다. 이 방식의 장점은 개발 비용이 저렴하며, 업데이트가 쉽다는 점입니다. 단점으로는 퍼포먼스가 느리며 사용자들은 모바일 앱을 사용한다는 경험보다 모바일 웹을 사용한다는 경험을 얻게 됩니다.
저희는 초기 개발 당시에는 웹앱, 웹앱 + 하이브리드 앱을 추천합니다. 아직 서비스가 검증되지 않았고 성공할지 미지수인 서비스에 많은 비용을 투자하는 것은 어렵습니다. (물론 네이티브로 개발 맡기시면 저희는 좋습니다. :) 데헷 ) 웹앱을 이용하여 최소의 비용을 투자하거나, 웹앱 + 하이브리드를 통하여 비용을 줄이고 최대한 모바일 앱의 경험을 줄 수 있는 방식을 추천합니다.
가장 어려운 질문입니다. 개발을 해서 넘겼으면 내가 뙇 받았을 때 실행이 뙇 되어가지고 짜자잔하고 보여줘야 하는 것이 아니냐!? 라고 말씀하시면 그저 죄송합니다.(__) 라고 할 수밖에 없습니다만.. 항상 클라이언트 분들께 테스트 컨펌을 부탁드리곤 합니다. 그 이유로는 개발사의 책임소재 문제도 있습니다만(이 부분이 작다고는 할 수 없겠습니다) 결국에 원하는 기능이 요청한 대로 개발이 되었는지, 정상적으로 작동하지 않는 부분이 있는지 마지막에 확인을 해보시는 게 좋습니다.
보통의 개발사는 개발 완료 이후 테스트에서 수많은 버그들을 수정하는 작업을 진행합니다. 개발사에서 말하는 "개발이 완료되었습니다. 이제 테스트를 진행하겠습니다."의 뜻은 "일정에 맞추어 개발을 완료하였지만 얼마나 많은 버그가 있을지 모르니 함께 기도해주십시오" 와 같습니다. 물론 초기 기획을 잘하는 경우 버그의 양도 적지만 언제나 싱크대 밑의 바퀴벌레처럼 항상 존재하는 것이 개발 버그입니다. 테스트 기간 동안 얼마나 많은 버그를 잘 잡느냐는 결국 서비스의 완성도와 귀결됩니다. (버그가 전부는 아니지만요)
테스트 이후 이슈(버그) 관리 문서를 만들어서 클라이언트에게 전달할 경우 종종 "버그가 왜 이렇게 많아요? 제대로 개발 안 하신 거 아니에요?"라는 이야기를 듣습니다. 감히 말씀드릴 수 있는 부분은 버그를 많이 찾아냈다는 건 그만큼 많은 부분을 고칠 수 있다는 것입니다. 약속한 테스트 일정을 넘기지 않는다면 버그가 많은 건 전혀 상관없습니다. (솔직히 개발자로서 버그가 적으면 더 불안합니다. -_-;;) 또한 개발사에서 찾지 못한 버그를 클라이언트 측에서 찾아내면 그만큼 서비스 완성도가 높아질 수 있습니다.
네. 서버는 뭐..어떻게 ...예??
서버 개발이 필요한 경우 많이 들어보신 용어는 웹 호스팅, AWS, 클라우드 일 것입니다. 그중에서 가장 궁금해하시는 내용은 웹 호스팅을 써야 하는지 서버 호스팅을 써야 하는지입니다. 사실 우리가 사용하고 있는 많은 서비스들은 서버 서비스를 1가지만 사용하지 않습니다. 여러 개의 서비스를 복잡하게 연결하여 사용하고 있습니다. 그러나, 예 그렇습니다. 어차피 설명하면 일단 클라이언트들의 머릿속은 복잡해집니다. 복잡해진다는 것은 결국 관리가 어렵다는 것입니다. 서비스 개발을 외주로 맡기는 업체에서 서버 관리를 할 내부 인원이 있기 어렵습니다. 그렇기 때문에 최대 2가지의 서버 서비스를 이용하는 것이 좋으며, 저희는 기능에 따라 다르지만 가능하면 웹 호스팅을 추천하고 있습니다.
웹 호스팅을 추천하는 이유는
1. 관리가 편하다. 관리가 편해야 운영이 용이합니다.
2. 서버 호스팅은 보안을 신경 써야 한다. 보안이란 개발의 영역이 아닌 운영의 영역에 포함됩니다. 보안 모니터링은 많은 비용이 발생하므로 초기 서비스 개발 시에는 고려하기에는 어려움이 많습니다.
3. 초기에는 트래픽이 많지 않다. 서버 호스팅이나 클라우드 서비스만큼의 비용을 지불할 시 웹 호스팅도 꽤 많은 트래픽을 수용할 수 있습니다. 저희에게 찾아오시는 분들은 보통 개발 초기이기 때문에 당장에 몇 천명이 넘는 사용자가 방문할 예정이 아니므로 확장성이 좋지만 관리가 어렵고 비용이 많이 드는 서버 서비스를 이용할 이유가 없습니다. (동접자가 바로 나올 수 있는 마케팅을 할 수 있는 자금력이 있다면 위의 말은 다 무시해주세요 ^_^)
물론 위의 내용은 기본적으로 작은 규모의 서비스에 추천드리는 내용이며 개발 기능, 서비스를 발전시킬 방향, 운영 방향 등에 따라서 추천드리는 내용은 달라집니다.
짧게 짧게 많은 양의 질문을 소개하려 했으나, 질문 하나하나에 꼭 대답해야 하는 내용을 적다 보니 답변이 길어졌네요. 다음 글에 또 몇 가지 궁금해하실 질문을 들고 다시 찾아오도록 하겠습니다.
잡담 / 개발 문화 / 일하는 방식 / 정보 공유 / 채용 문의 / 프로젝트 문의 등 어떠한 소통도 환영합니다 :)
오픈 슬랙 채널에 참여하기⬇️
https://join.slack.com/t/secondspace-open/shared_invite/zt-19q85dgid-6TCjbezQs4TTafBwT4BxAQ
written by. 세컨드스페이스