목차
1. 프로덕트 개발환경
2. 웹개발을 설계하는 방식
3. 웹뷰 개발을 설계하는 방식
4. 리액트 직접 구현해 보기(코드)

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

• 서비스 관점의 MVP

1. 개발자가 판단한 MVP가 정답인지 의심하라.
2. 직관이 통하는 세계가 존재함을 인정하라. 직관은 과학이 아님을 인정하라.
3. 개발자의 역할은 직관의 실패 리스크를 최소화하며 피봇할 수 있게 지원하는 것이다.

도메인 전문가의 직관을 존중하라.

• 기술 관점의 MVP

1. 어떤 기술이 적정기술인가?
2. 최대한 포기하라. 포기할 것과 포기하지 못하는 것을 분류하고 검토하라.
3. 기술보다 중요한건 속도다. 어제나 서비스의 생존이 최우선이다.

대표적 웹 서비스 종류: 콘텐츠, sns, 실시간, 커머스, 교육

1. 웹의 철학과 특징을 고려하라
   어떤 환경에서도 작동 가능해야.
2. 기술이 서비스 성공의 촉매 역할을 할 수 도 있다. ex) 접근성, SEO
3. 모든 것이 공유될 수 있는 자원이라는 것을 고려하라
   언제 어떤 내용으로 처리했고 주석처리 지저분하게 되어있으면, 입사하고 싶은 개발자들한테 이 회사는 기본이 안되어 있구나.. 라는 생각이 들게함.
   ex) 검색엔진 최적화, 오픈 그래프 최적화, 소스코드
4. 외부 서비스 연동 정보를 관리하라
   api key (소스코드 하드코딩), 인증서 등 동작은 문제 없지만 관리가 어렵다 인증서 갱신 기간 놓쳐서 서비스 전체가 안되는 경우가 있을수도..

1. 신규 서비스의 어설퍼 보이는 UX는 좋은 이미지를 만들 수 없고, 가치가 하락한다.
2. 발빠른 테스트와 릴리즈를 위한 아키텍처를 처음부터 고려하라 EX) A/B 테스트, 부분 업데이트가 가능한 격리된 컴포넌트 구조 설계
3. UX의 견고함과
4. 최신 기술을 활용하라

• 레거시가 없는 서비스라는 장점을 최대한 활용하라. 적절한 최실 기술 사용은 매력 요소가 별로 없는 스타트업의 기술인력 확보에 도움을 줄 수 있다. ex) PWA, WebRTC, AMP, Web Assembly 등
• 낮은 버전의 브라우저 환경은 과감히 버려라

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

1. 로그는 필수 요소이다. 분석 인프라가 없더라도 초기부터 로그를 수집하라
2. 로그 분석 인프라를 마련하고 지속적으로 발전시켜라
   분석은 나중에 하더라도 간단한 로그라도 심어놔라

1. 네이티브 컨테이너 + 단일 웹뷰 앱스토어 규약 위반 가능성, 네이티브 기능을 탑재해야 함 ex) 푸시, 카메라, 네이티브 인증(페이스 타임, 지문인식)

2. 네이티브 + 멀티 웹뷰 웹뷰간 데이터 교환 방법을 초기부터 고안해야함 앱에 저장소를 마들고 웹뷰에게 인터페이스를 제공하라

3. 네이티브 + RN 변화가 많은 지면은 RN으로 개발, 그 외의 지면은 네이티브 개발

웹뷰의 라이프 사이클을 인지할 수 있는 인터페이스를 만들어라

웹 기술의 발전이 개방형 기술이다 보니 새로운 기술들이 계속 제안되고 있음.
웹 UI룰 만드는 가장 손쉬운 방법은 HTML을 만들고 있음.
문제는 DOM을 다루기가 매우 까다로움
스케일은 얼마든지 커질 수 있는데 코드 구성의 복잡는 일정 이상으로 안커지게 유지 하는것이 필요한데 DOM자체로 그러한 것을 유지하기는 어려움.
스케일이 커져도 복잡도가 늘어나지 않는 방법을 찾고자하는 시도의 결과물들이 프레임웍이 나오고 있음.
적정기술이란 현재 나의 조직상태를 잘 고려해서 선택하는것(우아한JS)

리엑트의 장점이자 단점은 자유도이다. 사람마다 스타일이 다르다. 어떤 아키텍쳐가 좋은지에 대한 정답이 많다.

• 이미 리액트 프로젝트 규모가 너무 커져 만만하지가 않음

• 리엑트의 코어한 컨셉을 만들어보는건 어렵지 않다.