가. 프로덕트 개발환경

서비스 차원 수준의 개발 환경에서 고려해야 할 점 그리고 감안해야 할 점

• 문제는 어디서 발생하는가?

  • 협업을 통해 만든 제품(application)이라는 측면에서 문제는 Scale(트래픽)에서 발생한다.

    대부분 소프트웨어는 서비스의 크기가 커질 때 문제가 발생한다. 개발자로서 내가 운영하는 소프트웨어가 현재는 어떤 상태인지, 어느 시점부터 문제가 될 것인지 혹은 어디가 문제가 될 가능성이 있는지를 미리 예견하고 대응하되 오버 엔지니어링이 되지 않도록 적절한 수준의 유연성을 가진 소프트웨어를 가지는 것이 중요하다.

• 스타트업 vs 일반기업

  • 어떤 기업이던 똑같다

    제한된 리소스(인적자원), 부족한 시간(Release Date)

  • 이런 건 다르다

    시니어 엔지니어의 부재(프로젝트에 참여하지 않지만 코드에 대한 문의, 검토, 피드백을 요청할 수 있는..) 서비스 실패에 대한 비용, 리스크 부담

• 그렇다면 어떻게 해야할까?

  • 역량 한계 인정과 드러내기

    제한된 리소스(인적자원), 부족한 시간 ****등의 문제는 그 문제 자체가 드러나야 해결할 수 있다. 추상적인 문제제기 만으로는 드러나지 않으며 이러한 문제제기를 하더라도, 필요한 리소스나 시간은 쉽게 보완되지 않는다. 그러므로 이러한 개선만 기다리고 있을 수는 없다.

    현재 가진 환경에서 서비스를 만들어내야 한다면, 가장 크게 직면할 수 있는 문제로 1) 나 혹은 동료의 개발 역량에 한계가 있는 점을 들 수 있다. 역량 강화에는 물리적인 시간과 노력이 불가피하게 필요하다. 이러한 점을 개선하게 위해서는 나와 동료의 개발 역량을 객관적으로 드러내고, 이러한 객관적 내용을 조직 내에 공감을 이끌어내는 것이 중요하다.

  • 리스크를 줄이기 위한 노력

    1. 필요없는 기능은 최대한 배제한다. MVP*에 집중하라
    2. 클린 코드에 집착하지 말아라. 동작하는 코드가 가장 가치있는 시기가 있다.
    • MVP란 무엇인가 ?

나. 웹 개발을 설계하는 방식

개발을 시작하는 방식 - 네이티브 웹 서비스

브라우저에서 작동하는 웹/앱을 개발하는 데 있어 고려(고민)해야하는 부분에 대하여

• Mobile First

  • PC 웹은 보조적 수단이 되었다.

• 브라우저에서 작동하는 웹 앱

  • 콘텐츠, SNS, 실시간, 커머스, 교육 등 다양한 서비스 유형이 있다.

• 서비스 유형과 무관한 공통 고려 사항

  1. 웹의 철학과 특징을 충분히 고려하라

     어떤 환경에서도 동일한 콘텐츠를 전달해야 한다는 웹의 철학을 충분히 고려하고, 특정 브라우저가 소외되지 않도록 개발한다. 어떻게 하면 다양한 브라우저에서 동일한 사용자 경험을 제공해줄 수 있을까 하는 웹의 특성을 항상 고려해야 한다.

  2. 기술이 서비스 성공의 촉매 역할을 할 수도 있다

     어느 순간 누군가는 알아줘서 서비스의 촉매 역할을 할 수 있다.

     1. 접근성: 개발자 만이 고려할 수 있는 부분. 충분히 서비스에 책임감을 가진다면 이런 측면을 개발자가 충분히 고려해야 한다. UI적으로도 접근성에 필수 시 요소가 보이면 이를 디자이너와 상의하여 반드시 부족함 없이 구현될 수 있도록 한다.
     2. SEO(검색 엔진 최적화): 검색 엔진에 잘 드러나려면, 검색 엔진 최적화가 잘 되어 있어야 한다. SEO에 필요한 키워드, description 등을 기획자에게 충분히 요청하고, 필요한 이유에 대해 납득할만한 이유로 설명할 수 있어야 한다.
     3. 위트: 드러나지 않지만 소스에 위트를 녹여낼 수 있는 아이디어를 생각해보고 이를 구현해보자

  3. 모든 것이 공유될 수 있는 자원이라는 것을 고려하라

     • 서비스를 충분히 설명할 수 있는 콘텐츠를 잘 구축해놓지 않는다면, 더 많이 알려질 수 있는 기회들을 날릴 수 있다.
     • 검색 엔진 최적화, 오픈 그래프 최적화, 소스 코드 등 코드 내에 불필요한 요소를 지우고 정리하는 노력을 하라 (덕지덕지한 주석들..)

  4. 외부 서비스 연동 정보를 관리하라 ex. API Key, 인증서 등

     kakao.init('adfda1231adfkzlvkzsd'); // API Key 예시
     

     위와 같이 코드에 키 값이 하드 코딩으로 관리 된다면, 그리고 위와 같은 정보가 서비스에 다양하게 추가된다면 관리가 필요하다. 예를 들어, 1) 연결 정보들을 업데이트 해야 하는 경우 2) 어디에서 연결 정보들을 사용하는지 파악해야 하는 경우 심지어 3) API Key를 바꿔야 하는 경우도 발생하는데, 별도의 보관 혹은 관리없이 코드 수준에서만 관리하게 된다면 이는 유저에게 나쁜 사용자 경험을 일으키는 다양한 사이드 이펙트를 불러온다.

     때문에 외부와 연동되는 정보들은 "언제나 바뀔 수 있는, 관리되어야 하는 정보"라는 인식으로 초기부터 product 바깥에서 별도로 관리하면서 구축하는 것이 좋다.

• 디자인과 디테일한 UI/UX를 추구하라

  1. 신규 서비스는 어설퍼 보이는 UX는 좋은 이미지를 만들 수 없고, 가치가 하락한다.
     • 프론트엔드 엔지니어는 시장이 공통적으로 가지고 있는 최소한의 퀄리티는 보장하는 디테일함을 추구해야 한다.
     • 개발만 잘한다고 되는게 아니다. 디자이너와의 협업을 적극적으로 하자.
  2. 발빠른 테스트와 릴리즈를 위한 아키텍처를 처음부터 고려하라
     • A/B 테스트, 부분 업데이트가 가능한 격리된 컴포넌트 구조 설계
     • 개발과 테스트, 배포 환경을 초기에 구축하여 불필요한 노동을 줄인다.
  3. UX의 견고함과 기능이 경합을 벌이면 견고함을 선택하라
     • 견고함은 사용자 경험에 큰 영향을 미치므로 어설퍼 보이는 것을 지양한다.

• Tech 스텍을 구성할 때 최신 기술을 사용하라

  1. 레거시가 없는 서비스라는 장점을 최대한 활용하라. 적절한 최신 기술 사용은 매력 요소가 별로 없는 스타트업의 기술인력 확보에 도움을 줄 수 있다.

     ex. PWA, WebRTC, AMP, Web Assembly 등

  2. 낮은 버전의 브라우저 환경은 과감히 버려라

     상황에 따라선 생존을 위해 과감하게 포기할 줄도 알아야 한다. 무엇이 더 중요한가?

• 사용자 로그를 수집하라, 그리고 분석하라

  1. 로그는 필수 요소이다. 분석 인프라가 없더라도 초기부터 로그를 수집하라
  2. 로그 분석 인프라를 마련하고 지속적으로 발전시켜라
  3. 개발자의 취향을 반영하지 말고, 사용자의 로그를 기반으로 움직여라

다. 웹뷰 개발을 설계하는 방식

개발을 시작하는 방식 - 웹뷰

현대 서비스는 사실상 앱 서비스 중심으로 개편되고 있다. 어떤 부분들을 고려해야 하는가?

• 앱을 만들기 위한 기술은 다양하게 존재한다.

  • iOS, Android - 구글과 애플의 싸움, 두 개의 플랫폼으로 양분화되어 있다. 위 두 플랫폼에서 제공하는 환경으로 개발한 앱이 네이티브 앱이라고 한다.
  • 순수한 네이티브 앱이란 존재하는가?
    • 웹 기술을 활용한 하이브리드 앱이라 불리우는 패키징 기술이 많이 시도되고 있고, 이에 따른 방식의 다양성과 성능이 많이 나아지고 있다.
    • 보통 모든 화면을 네이비브 앱으로 개발하기는 힘드므로, 웹 기술을 적극적으로 활용한다.
    • 대표적인 기술: 웹뷰를 이용한 개발, 웹뷰에서 작동하는 웹 앱 개발 시 뭘 고려해야 할까?

• 네이티브 앱 패키징 아키텍처

  1. 네이티브 컨테이너 + 단일 웹뷰
     • 단순하게 패키징 된 앱은 심사의 결격사유로 작동할 수 있어 앱스토어 규약 위반 가능성이 있다. 이를 hadge하기 위해 네이티브 기능을 탑재해야 한다.
     • ex. 푸시, 카메라, 네이티브 인증(페이스 타임, 지문 인식 등)
  2. 네이티브 + 멀티 웹뷰
     • 현대의 모바일 앱이 주로 사용하는 방식. 앱 자체는 네이티브 앱 + 스토어의 심사를 받지 않고도 업데이트 할 수 있는 화면의 경우 멀티 웹뷰로 개발하는 방식을 말한다.
     • 실제 현대의 모바일 앱은 순수하게 네이티브 앱 기술만으로 패키징 되는 경우는 거의 없고, 실제 다양한 n개의 멀티 웹뷰와 적절히 혼합하는 아키텍처를 가진다. 마켓 플레이스, 주문 상세, 주문 내역 등 변화가 빈번히 일어나는 경우 웹뷰로 개발한다.
     • 웹 뷰간 데이터 교환 방법을 초기부터 고안해야 한다.
     • 앱에 저장소를 만들고 웹 뷰에게 인터페이스를 제공하라
  3. 네이티브 + RN(React Native)
     • 변화가 많은 지면은 RN으로 개발, 그 외의 지면은 네이티브 개발
     • 실제 개발은 Javascript를 이용해서 개발하고, 실행하는 단계에서는 네이티브 컴포넌트를 사용하는 방식이다.
     • 웹을 가지고 UI를 만드는 방식의 가장 대표적인 문제인 사용성 혹은 퍼포먼스와 관련된 이슈가 없고, 사용자에게 민첩한 사용성을 제공할 수 있다.
     • RN으로 개발한다고, 네이티브 개발자가 전혀 필요하지 않은 것은 아니다. 앱이 알 수 없는 이슈로 crash나 error가 나는 경우가 많은데 네이티브 코드에 문제가 있을 경우가 많다. 이러한 코드는 난이도가 있으므로 미래에 생길 리스크에 발빠르게 대응이 가능하다.
     • 프로젝트 구성이 RN의 경우 아키텍처가 전혀 다르므로, 기존에 네이티브 앱 → RN앱으로 변환할 경우 높은 코스트가 발생한다. 때문에 초기부터 리액트 네이티브 구성으로 만드는 것이 좋다. instagram의 경우 RN으로 되어있다.

• 앱 패키징 아키텍처와 무관한 고려사항

  1. 네비게이션 룰을 확립하라.

     [특정 화면의 직접 랜딩을 위한 앱스킨 디자인]

     앱은 웹과 달리 화면마다 고유의 URL을 생성할 수 있다. 경우에 따라 여러가지 화면 중에 특정한 화면으로 다이렉트로 접근해야하는 일이 자주 발생하는데 이렇게 페이지 별로 다이렉트로 접근할 수 있는 경로(deep link)를 정리한 것을 네비게이션 룰이라고 한다.

     만약 1.0에선 없던 기능이 2.0에서 발생한다면? 기존 유저에게 1.0 → 2.0으로 업데이트를 강제하는 것이 어려우므로, 모든 기능이 버전에 상관없이 실행되어야 한다. 실제 초기에 버전과 관련된 feature들은 모든 웹 페이지가 deep link를 가질 수 있도록 초기에 신중하게 고려를 하여 미리 선배포를 해놓으면 이후에 유연한 대처가 가능하다.

     • deep link를 설계하는 방식?

       향후 웹 서비스를 만들 계획이 있다면 universal link 방식을 deep link의 기본 스키마로 가져가는 것이 좋다. 먼 미래의 이슈에 대해 유연하게 대처할 수 있다.

       • universal link란?

  2. 공개용 웹뷰와 내부용 웹뷰를 분리하라 (보안을 고려하라)

     보안을 고려해야 하는 이슈가 발생하므로 외부에 공유되는 화면과 앱 내에서만 접근할 수 있는 화면을 분리할 것 (개인 정보 등이 외부에 공유되어선 안되므로)

     API 연동 토큰, 앱 메타 정보 등 서버가 필요로 하는 정보를 어떻게 관리할지 고려하라.

     • 내부용/외부용 서버를 달리하고 배포를 각각 달리하면 노출되면 안되는 정보가 노출되는 잠재적인 위험요소를 사전에 방지할 수 있다.

  3. 개발환경을 구축하라

     웹뷰와 데스크탑 브라우저는 다르다. 같은 기기 내 웹 뷰, 브라우저 등도 차이점이 존재한다. 때문에 시뮬레이터 환경을 사전에 구축하는 것이 좋다. (물론 시뮬레이터와 실 기기에서 작동하는 것도 차이가 존재하나 그 예외가 상대적으로 미미하다)

     개발자가 경험할 수 있는 환경을 네이티브 개발자의 도움을 얻어 미리 준비하고 개발자 간 쉽게 방법을 공유할 수 있도록 문서화하고 변경사항을 업데이트 한다.

  4. 런타임 오류를 수집하라

     실제 디바이스 환경 이슈가 브라우저 환경 이슈보다 훨씬 더 다양하게 발생한다. 개발팀 입장에서 해당 디바이스를 가지고 있지 않는 이상 오류에 대한 지원이 어려우므로 발빠른 대응을 위해 런타임 오류를 미연에 수집하는 것이 중요하다.

  5. 캐싱을 적극적으로 활용하라

  캐싱된 데이터와 서버 캐치 데이터의 자연스러운 전환을 고려한 UX를 설계하라

  캐싱은 이미 만들어져 있는 데이터(서버로부터 불러온)를 말한다. 사용자가 개개인의 네트워킹 이슈로 인해 앱 이용에 불편을 겪을 수 있으므로 아예 작동하지 않는 앱보다는 캐싱된 데이터를 보여주는 것으로 만족스러운 사용자 경험을 유지할 수 있다.

  캐싱을 하기 위해 앱의 아키텍처는 굉장히 달라질 수 있으므로 여유가 있을 때 고려한다.

  6. 웹뷰의 라이프사이클을 인지할 수 있는 인터페이스를 초기에 설계하라

  네이티브 앱 내에 웹뷰의 라이프사이클을 인지할 수 있도록 설계하는 것이 필요하다. 네이티브앱이 웹뷰를 로드시킬 때 다른 네이티브 화면에 가려져서 안보이는 경우도 있다. (ex. tab bar) 때문에 프리젠테이션 컴포넌트를 독립적으로 운영하는 것을 선배포해놓으면, 이후 앱이 실제로 웹뷰를 개발할 때 그 인터페이스를 이용해 훨씬 더 좋은 UX를 제공할 수 있다.

  7. 접근성을 언제나 고려하라

  모두가 만족할 수 있는 사용자 경험 제공을 위해 접근성과 관련된 스펙은 반드시 고려한다.

라. 신규 개발 관점에서의 리스크 관리