[코드스테이츠 PMB 9기] 웹/앱서비스 & FE/BE

웹 서비스 이해

📌 개발 형식을 정해야 하는 이유
- 네이티브 앱; 기능 좋고 안정적이나, Android/iOS 비해 공수 많이 듦
- 하이브리드 앱; 공수,비용 비교적 낮으나, 높은 퍼포먼스 구현 힘듦

⇒ 초기 MVP형태의 경우, 하이브리드 앱으로 구현 후 이후 네이티브 앱으로 전환하는 것도 방법임

 

http://uxstory.co.kr/blog/2018/08/10/app_list/

 

앱의 종류

• 네이티브 앱
  • 모바일 OS에 최적화된 언어를 사용해 개발한 앱
  • Android, iOS에서 제공하는 SDK를 사용해 개발
• 모바일 웹
  • 모바일 기기에서 사용하기 편한 방식으로 개발된 ‘웹 페이지’기반 서비스 의미
  • 웹 브라우저에서 동작
• 웹 앱
  • 앱 형태이지만, 실제 내용은 웹에서 구현해 보여주는 페이지
  • 네이티브 앱에 비하여 구현 간단함
• 하이브리드 앱
  • 네이티브 앱의 구조 + 일부 기능은 웹으로 구현
  • 웹의 기능 쉽게 연동 가능

 

반응형/적응형 웹

• 반응형 웹
  • 웹 브라우저 크기에 따라 자동으로 웹 구성 요소 크기와 구조가 변경됨
• 적응형 웹
  • 접속한 기기의 종류(PC, 스마트폰 등) 자동으로 인식해, 웹 구성 요소 크기와 구조가 변경됨

---

FE 커뮤니케이션

 

주의사항

• 동작 구현에는 복잡한 알고리즘과 프레임워크에 대한 검토가 동반됨
• 마크업 ≠ 클라이언트 구현
  • JS 활용한 기능구현 업무는 알고리즘을 만들어 구현하는 업무임
  • 외형 개선(HTML, CSS)인지, 기능 개선(JS)인지에 따라 태스크 달라짐
• 모든 UI 구현 의도를 명확하게 전달해야 함

---

 

서버와 BE

 

백엔드 프레임워크

• Java - Spring
• JavaScript - Express Js, Node Js
• Python - Django
• Ruby - Ruby on Rails

---

 

BE 커뮤니케이션

 

주의사항

• 한번 정해지면 변경하기 어려움
  • 서버 입출력 구조와 DB는 한번 설계되면 Data가 누적되기에 중간에 변경하는 것이 매우 어려움
  • 개발 전, 제품 로드맵 / 서비스 확장성 / 유지 보수성 고려하여 기획
• 항상 Admin 페이지 고려할 것
  • admin : BE 취급 정보 관리하는 페이지
  • FE의 경우, 클라이언트의 반응을 보며 상시 개선 가능함
  • BE의 경우, 직접 관리가 어려워 간접적으로 관리할 수 있는 어드민 페이지가 필요함
• 서버 리소스는 비즈니스와 직접적 연관 있음
  • 클라이언트는 고객과 직접적 연관 있음
  • 서버는 아래와 같은 요소들로 비즈니스와 직접적 연관 있음
    • 트래픽 양 및 서버 비용
    • 확장성, 유지 보수
    • 수집 데이터에 대한 관리 및 운영(PM도 서버 리소스 관리할 줄 알아야 함)

---

 

클라우드 서비스와 기술 스택

 

로드 밸런서

• 하나의 인터넷 서비스가 발생하는 트래픽이 많을 때, 여러 대의 서버가 분산처리하여 해결해주는 서비스
  • 서버의 로드율 증가, 부하량, 속도저하 등의 문제
• 트래픽이 상시로 변하거나 일정 시간대에 많은 트래픽이 몰리는 서비스의 경우, 로드 밸러서 설정이 서비스 안정성에 큰 영향 줌

 

기술 스택 정하는 기준

• 높은 생산성
  • 빠른 개발과 테스트 가능한지?
  • MVP 빠르게 만들 수 있는지?
• 신뢰성
  • 신규 언어와 프레임워크는 신뢰성 낮을 수 있음
• 개발자 고용 가능
  • 해당 스택 개발자 풀이 적당한지?
• 코칭 가능성
  • 코드 리뷰가 가능하고, 커뮤니티의 도움을 받을 수 있는지?

 

---

 

웹/앱 종류와 특장점

종류	특징	장점	단점
모바일 웹	PC용 사이트를 모바일에 맞게 구현하는 방식 브랑저로 URL을 이용하여 들어가게 됨	PC용 사이트를 모바일에 맞게 구현하는 방식 브랑저로 URL을 이용하여 들어가게 됨	PC용 사이트를 모바일에 맞게 구현하는 방식 브랑저로 URL을 이용하여 들어가게 됨
웹 앱	PC가 아닌 모바일 기준으로 모바일에 중점을 두고 개발하는 방식 모바일 웹보다 더욱 모바일에 최적화 되어 있음 PC와 모바일 등의 기기에 관계없이 모든 디바이스에서 같은 콘텐츠를 볼 수 있음	모바일로 사이트를 이용하는 사용자는 조금 더 익숙하게 사용 가능함 앱 설치할 필요 없고, 수정 사항에 따라 스토어 업데이트하지 않아도 됨	사용자가 검색과 URL을 통해 들어와야 함 모바일 운영체제에서 제공하는 기능 활용할 수 없음 플랫폼 API 사용할 수 없고, 오로지 브라우저 API만 사용 가능함 페이지 로딩 속도 상대적으로 느림
하이브리드 앱	네이티브앱과 웹앱의 장점을 합친 앱 개발 방식 HTML 등의 PC로 작업이 가능한 웹문서로 구현 네이티브 앱에 웹뷰를 보여주어 웹앱을 실행시켜야 함	양쪽의 API를 모두 사용할 수 있음	네이티브 앱 개발지식 필요함 웹뷰에서 앱을 실행하기에 브라우저의 성능에 따라 앱 성능 결정됨 네이티브 앱보다 UI를 구성하는 디자인 부분 취약함
네이티브 앱	웹뷰에서 앱을 실행하기에 브라우저의 성능에 따라 앱 성능 결정됨 네이티브 앱보다 UI를 구성하는 디자인 부분 취약함	높은 사양 그래픽 사용 가능 디바이스 전체에 엑세스 권한 가질 수 있음	높은 기술력 필요하여, 공수 많이 듦 PC 접속 불가능해 수정 사항 발생 시, 스토어 통해 지속적으로 업데이트 해야 함 각 모바일 OS별로 앱 개발해야 함

 

제품 기획 과정에서 기술 스택 선정

기술 스택 선정하기

1. 어떤 기술 스택을 사용할지? 외부 서비스는 활용할 것인지 결정
2. 고객에게 어떤 플랫폼에서 서비스를 보여줄지 결정
3. Product Brief 작성 > 개발 범위 산정
4. 예상 클라우드 호수팅 수
5. 아키텍처 수준에서의 확장성 고려
6. 유지 보수 용이성 고려
7. 타 서비스 호환 가능성 검토
8. 기술 자체 신뢰성 검토

 

<Product Biref> 정리하기

• 팀
  • 비전 :
  • 목표 :
• 제품 요약
• 왜 이제품을 만들어야 하나?
  • Background 리서치 | History | 경쟁사 | 트렌드
  • 제품이 팀과 회사의 목표에 기여하는가?
  • 어떻게 기여하는가?
  • 얼마나 기여하는가?
  • 목표 달성을 위해서는 (왜) 이 제품이어야만 하는가?
• 타깃 유저
  • 타깃 유저 정의
  • 니즈 정의
  • 유저에게 이 니즈가 있는 이유는?
  • 이 니즈가 있다고 확신할 수 있는 증거는?
• 제품 의사결정 원칙
• 기능 리스트
  • MVP에 포함된 기능
  • Fast-Follow에 포함할 기능
• "Good Enough to Ship" 의 정의
  • 기획자의 정의 :
  • 개발자의 정의 :
  • 디자이너의 정의 :
• 성공 정의
  • 유저의 니즈를 충족했는가?
  • 질적/양적 지표 정의와 목표치
• 예상되는 핵심 리스크
• 어떻게 런칭할 것인가?
  • 초기 유저 모으기, 마케팅, in-app 프로모션 등
• 어떻게 키울 것인가?
  • Distribution Strategy
  • 장기적으로 유저가 제품을 찾아오게 하는 법
• Timeline & Milestone