이한솔 멘토님 멘토링

신재우님

• 데이트 코스 관련 어플 -> 데이트 코스 추천

데이터 유실 방지에 노력

프레임워크 특성 파악

• vue는 개인프로젝트로 사용하기 쉬움
• react는 기업 프로젝트로 대부분 사용, 한국은 특히 더
• angular는 si 또는 100명 이상의 개발팀인 곳에서 사용

왜 쓰는걸까? 웹 FE vmfpdladnjzm emdwkd wjs dnpq roqkf

• jquery로 떡칠된 웹페이지
• 돔 트리 특유의 느린 엡데이트 api 성능 + 브라우저 엔진으로 인해 스크립트 많이 쓸 시 제대로 구현 안하면 페이지 반응없음 -> 강제 종료됨.
• 웹 개발자의 메인빌런 IE 6, 7 이 현역이었음.

크롬 V8엔진의 등장, 크롬의 점유율 상승으로 더 나은 환경의 FE개발이 가능해짐

FE 개발자 인식이 안좋은 이유

• 옛날 웹 개발자에 대한 인식
• HTML, CSS 만지는 것이 좀 그렇다..

한 번 배운 것은 과감히 버릴 수 있어야 하고 새로 생긴 기술을 빨리 습득해야 하는 포지션이다. 트렌드에 정말 민감하게 반응해야 한다.

웹 FE 3대장

React

• virtual DOM을 기반으로 바뀐 부분만 스왑하여 업데이트 횟수를 줄여 성능 향상
• awesome react 저장소 간간히 확인할 것
• 장점
  • virtual dom을 써서 압도적으로 빠르다.
  • 앵귤러에 비해 라이브러리이기 때문에 상대적으로 가볍다.
  • 압도적인 유저 + 오픈소스 커뮤니티
  • 배우기 쉬움
  • 훅 같은 멋진 기능들이 꽤 빠른 주기로 추가됨
  • TS 지원이 완벽한 수준
• 단점
  • 과도하게 오픈소스 커뮤니티에 의지하도록 설계되어 있음
  • 미리 갖춰진 쓸만한 라이브러리가 공식이 아니고 오픈소스 형태라 저자가 다 다름.
  • 기본 중에 기본인 navigation조차 오픈소스인 react-navigation에 의지함 -> 2022년 현재는 많이 좋아짐, vercel이 나름 표준을 정의해주고 있다.
  • 상태 관리도 리덕스 등을 따로 배워서 써야함. -> recoil, rtk등장으로 어느정도 해소
  • jsx를 적극적으로 활용해야하는데 정통적인 웹 개발에서의 코드 형태와 달라서 거부감 있을 수 있음

Angular

절대 소마에서 쓰지 마라.

• 장점
  • 구글의 전폭적인 지원
  • 구글이 라이브러리 필요한거 다 만들어서 기본 탑재해줌
  • 웹 개발할 때 필요한 대부분의 기능이 다 기본 탑재
  • 문서 잘 읽고 하라는대로만 하면 고급 기능 자연스럽게 많이 쓰게 됨.
  • 상호간 지켜야할 규칙이 많이 필요한(설계가 제대로 잡혀있어야하는) 대규모 조직에 적합
• 단점
  • 배우기가 다른 웹 FE 프레임워크에 비해서 어려움
  • angular.js에 종속되는 코드가 될 확률이 높음
  • 잘 쓰면 좋은데 잘 쓰기가 어려움
  • 하위 버전 호환 고려 잘 안해주는데 업데이트 크게 일년에 두번 해버림 -> 마이그레이션 할때마다 고통

Vue.js

• 장점
  • 가장 쉽다.(템플릿 형태)
  • 가볍다(간단한 어플리케이션의 경우 render성능이 더 빠를 수 있음)
  • 복잡하게 알아야 될 게 없음, 쉬워서 인기 폭발
  • 최근 떠오르고 있기 때문에 도움 받을 수 있는 곳, 좋은 라이브러리 많이 생기는 중
  • 한 파일에 다 몰아놓고(html, css, js) 컴포넌트 개발하기 좋음
  • 레거시 프로젝트에 추가하기 좋음(php+jquery로 된 사이트 일부분 영역에 vue component 추가), 웹컴포넌트를 사용하여 레거시 프로젝트에 추가하기 편하다.
• 단점
  • 정말 쉬운 구조지만 이게 양날의 검, 테스트, 디버깅이 어려울 수 있음
  • 뷰의 정해진 틀 내에서 개발해야되다보니 확장성이 부족함
  • TS지원이 온전치 못함
  • 뷰 만을 위한 문법을 어느정도 익혀야함

Svelte

• 프레임워크지만 컴파일러와 비슷한 포지션
• Virtual DOM 아님, Virtual DOM없이도 Virtual DOM을 상회하는 속도를 내는 것이 목표
• 코드를 만들면 특이하게 컴파일을 해 최종 결과물을 만들고 이 과정을 통해 어떤 부분이 어떻게 변경되는지를 파악하고 있어 성능 향상을 노림
• 장점
  • 코드양이 적다.
  • 빈번한 업데이트가 있는 웹앱에서 성능이 Virtual DOM보다 좋음
  • 구조가 단순해 다른 프레임워크를 몰라서 새로 시작하는거라면 배우기 쉬움
  • cpu성능이 부족한 임베디드 장비 등에서 가장 좋은 성능을 보여줄 수 있음, 예시) 키오스크
• 단점
  • 힙스터, 홍대병 소리 듣기 좋음
  • 아무리 쉽다고 해도 개발할 사람이 없으면 개발 속도가 느려진다. 내가 손을 뗄 수 없다.
  • 문제가 생겼을 때 도움을 받기 어여울 수 있음(결과결과도 적고 관련 서적도 적음)

아예 글로벌한 툴로 만들어서 무료로 배포해서 유저한테 홍보 -> 유저 뺏어와서 투자를 받아온다. 고객없이 몇 달이상 만드는 프로젝트는 쓰레기가 된다. 요구사항이 완벽히 만족해야 한다. B2B솔루션을 글로벌 한정으로 하면 된다. 시장을 잘 정해라. AI 데이터 수집은 계속 수요가 있다. 어떻게 싸고 편하게 줄거냐 그것이 문제다. 완벽하게 기획해서 한 번에 쫙 낸다 -> 오만한 생각이다.

케이스 스터디를 통해

크로스 플랫폼 프레임워크

• 플러터
• RN

플러터

• 장점
  • ios, 안드로이드, 데스크탑, 웹까지 한 프로젝트로 네 개의 플랫폼에 배포가능하다.
  • 기존 하이브리드 앱들과 다르게 성능 저하도 거의 없음
  • 자체 개발한 skia라는 그리기 라이브러리를 사용하기 때문에 중간 브리지가 없고(성능 저하 없음) 추후에 더 다양한 플랫폼에 배포 가능할 듯
  • 구글이 강력하게 drive하고 있음
  • UI는 플러터로 짜고 기기와 관련된 로직은 그냥 네이티브 코드로 짠다고 하면 가장 편하고 개발속도 빠름
• 단점
  • Dart라는 생소한 언어 배워야함, js알면 금방 적응한다.
  • 결국 os종속적인 코드를 짜야할 때는 ios, android코드를 조금씩 짜긴 해야한다.
  • 아직 버전 1.0 조차 달성하지 못한 라이브러리가 많다.
  • 구글이 라이브러리를 가장 많이 만들어서 배포하는데 없으면 못만들거나 직접 만들어야함
  • 업데이트 주기가 굉장히 빠르고 이 업데이트할 때마다 깨져버리는 라이브러리들을 보고 있으면 멘탈 깨질 수 있음
  • 사용하면 업데이트하지 말고 고정해라

RN

• 장점
  • react 다룰 줄 알면 날로 먹기 가능
  • React와 대부분의 장점, 단점을 공유함
• 단점
  • HTML 컴포넌트를 그대로 쓸 수 있는건 아니고 등 RN만의 컴포넌트를 숙지해야 함.
  • css형태로 화면을 꾸밀 수 있어 금방 배우지만, 미묘하게 웹의 css와 달라서 고통받을 수 있다.
  • 빌드난이도가 플러터보다 더 어렵다.(여러 오픈소스를 조합해서 하다보니 의존성문제가 펑펑터짐)
  • 브리지로 인한 병목 발생, js코드, 네이티브 코드의 브리지가 모든 것을 담당하기 때문에 cpu 성능이 안좋을 경우 병목이 발생할 수 있다.

하이브리드 vs 네이티브

• 카메라, 센서를 많이 사용해야하는 앱의 경우 일반적인 네이티브 추천
• ai 모듈 사용해야하는 경우 네이티브 추천
• Native UI를 많이 활용해야 하는 앱의 경우 네이티브 추천
• 그 외 POC, MVP검증용으로는 flutter추천(배우기 쉽고 구현속도가 훨씬 빠름)
• 하이브리드 앱이 성능, 개발편의성에서 많이 따라와 위협중이며, 가장 치명적인 단점은 유지보수가 굉장히 힘듦
• 플러터 or RN wrapper + 웹앱의 경우에도 하이브리드인지 인지하기 어려울 정도로 성능이 많이 올라간다. 웹앱과 껍데기의 통신을 위한 노하우가 필요함.
• 웹앱의 경우 live update가 가능하며 이 장점 하나만으로 다른 단점을 다 상쇄하고도 남음.
• RN은 code push라는 기능으로 Live update가 가능, 다만 아직 불안정.

전역 상태 관리

• 스토어 기반
  • 리덕스, Mobx, zustand
• atom 기반: 전역 변수 같은 것
  • recoil, jotai

context api 개념은 알고 있어야함. 근데 쓰지 마라. 성능을 고려하면서 설계해야하는데 초보는 무조건 실수해서 상관없는 컴포넌트들이 다 rerender되고 있을거고 점점 느려짐. 라이브러리 쓸 때보다 파일도 많이 만들어야하고 코드도 많이 작성해야 함.

리덕스

• flux 패턴이 너무 좋다. 그래도 zustand를 쓸 것
• 혹시 쓰더라도 rtk를 써라. zustand 추천
• 앱이 정말 커지고 비즈니스 로직이 복잡해지면, 그리고 협업하는 FE개발자가 많아지면 고려해봄직함(그래도 훌륭한 대체제 많음)
• 쓰더라도 순정으로 쓰지말고 redux-thunk, redux-saga, rtk적극 고려
• 디버깅에 큰 장점이 있다.

store기반

• 객체지향, 클래스 사용에 익숙하다면 그렇게 어렵지 않음
• 필요한 변수들끼리 묶여있으므로 유지보수하기 한층 쉬움

atom기반

• 장점
  • 쓰기 쉽다
  • 코드량 적음
  • useState 쓰는 것과 별반 차이가 없음
  • 앱 다합쳐서 글로벌 상태로 쓸만한게 별로 안보인다 싶으면 도입
• 단점
  • 쓰기 쉬운데에는 책임이 따른다.
  • 적절한 규칙, provider로 scope안정해두면 유지보수 hell될 수 있음
  • 개발자 도구 지원 이제야 조금 되는 중
  • 디버깅 어려울 수 있음

전역상태관리 사용하기 좋은 케이스

• 로그인, 회원가입
• 복잡한 create페이지
• 렌더링 이후 그 값들 가지고 임시로 사용자의 행동을 저장해서 해야되는게 많음(예, 피그마 같은 디자인 툴에서 저장 전까지 사용자가 변경한 내역을 브라우저가 들고있어야할 때)

SSR

웹 서비스로 만들 것이고 구글 검색 결과 노출이 중요하다 -> Next.js 적극 고려, 힙한거 좋아하면 remix

구글 검색 노출이 중요하지 않다. seo보다는 최초 렌더링 이후에 좀 빨랐으면 좋겠다 -> cra + vite 사용

CRA로 만든 다음에 SEO대응하는거 정말 어려움, 세부 메뉴등이 구글 검색 노출이 필수인 앱은 (매거진, 커뮤니티 등) 무조건 next.js or remix

Remix 진짜 괜찮긴한데 무료로 오픈된지 얼마 안돼서 정보가 많이 없음. next.js를 쓰다가 아쉬움을 느낀다면 remix로 넘어가보는 것을 추천

css 프레임워크

1. tailwind css
2. emotion: 부가적인 코드가 많이 늘어나지만 꽤 인기 있음(스토리북과 충돌남)
3. Next.js를 쓴다면 styled-jsx(tailwindcss가 더 좋긴함)가 좋긴하다. 간단히 쓰기 좋긴한데 코드가 지저분해지고 inline css를 쓸 일이 많아지면서 성능 병목 가능성 있음

정답이 있는게 아니라 취향에 맞는걸로 하는게 좋음.

테스팅

소마에서는 테스팅에 손도 대지 않는 것을 추천한다. 프로덕션 레벨에서만 하는 것이다.

단위테스트/통합테스트 -> Jest + RTL
e2e테스트 -> cypress or playwright(유저가 실제 브라우저에 띄웠을 때의 테스트)
사용자 확보를 하고 싶으면 초반에 CI/CD 환경을 구축해라!

vercel쓰면 자동으로 CI/CD가 된다. 고려해볼 것.

소마에서 어떤 프로젝트를 할 것인지에 따른 가이드

팀을 잘 꾸려서 창업까지 경험, 끝나고도 프로젝트가 유지되면 좋겠음

• 오버엔지니어링 경계
• 서버비 많이 쓰기X
• 무료 saas, 노코드 툴 적극 활용
• 아낀 돈으로 마케팅(이세진, 오우택 멘토님 추천)
• 코드 품질 고려하지말고 무조건 빨리 출시해서 고객들이 쓰게 할 것
• 6개월 안에 PMF찾기를 목표로 하기(이것만 해도 대박)
• 과정 끝나고도 운영하는 것을 염두

취업에 도움될만한 포트폴리오 프로젝트 + 기술적인 역량 향상

• 대기업, 현업에 있는 멘토님들로 구성해서 기획보단 오버엔지니어링에 집착할 것.
• 대용량 트래픽 대응, lighthouse 100 100 100 100 찍기, TDD를 통한 코드 품질 향상, spring등을 활용한 복잡한 디자인 패턴 숙지, sql 쿼리 최적화 등 현업에서 생길법한, 현업에서 중점적으로 사용하는 내용들, 채용공고에서 우대사항에 있던 바로 그것들을 적극 트레이닝할 것.
• 앱 출시, 고객반응 보기 안해도 된다. 최종 발표까지 demo를 만들기만 할 것. 대신 퀄리티 있게 만드는데에 집중하고 면접하고 잘 대답할 수 있을 정도로 기술적인 내용을 숙지할 것.
• 과정 끝나고 이 프로젝트를 어떻게할지 생각하지 말고 구현

소마프로젝트 대부분 이 두 케이스 중간쯤 어딘가를 택하고 장렬하게 망함.

소마프로젝트 아이디어 찾는법, PMF는 어떻게 찾는게 좋을까요?

Product Market Fit Pain killer를 찾으세요. 많은 사람의 가벼운 문제, 소수만의 심각한 문제로 접근해서 많은 사람의 심각한 문제로 발전시켜나갈 것

보통은 있으면 좋은 정도, 비타민 같은 프로젝트로 시작하기 쉽다. 개인 프로젝트로 하기엔 나쁘지 않지만 창업까지 고려한다면 유저 한명 획득하는데에 정말 좋은 앱 퀄리티가 있어야 하거나 돈이 많이 든다. 써보고 바로 이탈하거나 피드백도 안준다. 그만큼 쓸 동기부여가 부족하다는 뜻

UI가 안좋고 기능이 부실해도 pain killer 역할을 조금이라도 해준다면 참고 써준다. 유저확보도 큰 비용이 들지 않습니다. 바이럴되기도 좋다. 주변에서 이 문제 때문에 모니터/키보드 부숴버리고 싶다는 사람을 타겟팅해서 그 문제를 풀어주세요. 무조건 반응이 온다. 피드백도 많이 준다. 대신 말이 쉽지 찾기 엄청 힘들다.

진통제를 구하기 쉬운 나라에서 FDA허가받지 않은 prototype진통제를 팔면 바로 망하겠지만 전쟁중인 나라이고 진통제를 구하기 힘들다면 엄청나게 팔기 쉽다. 허가받고말고는 중요하지 않다. 당장 너무 아프니까.

Market의 중요성

나쁜 팀이 나쁜 시장을 만나면 시장이 압살합니다.(크게망함)
나쁜 팀이 좋은 시장을 만나면 시장이 이깁니다.(적당한 성공)
좋은 팀이 나쁜 시장을 만나도 시장이 이깁니다.(망함)
좋은 팀이 좋은 시장을 만나면 로켓이 됩니다.(대성공)

많은 사람들이 관심을 갖고 매년 성장할 수 있는 시장이 뻔하게 느껴지더라도 거기에 탑승하면 거저먹는게 많다. 서비스 자체가 성장을 못해도 시장이 크면서 성장을 하게 된다. 서비스도 성장하는데 시장도 커지면 시너지가 어마어마함.

반면에 감소하는 시장에선 정말 열심히해도 제자리 걸음일 수 있습니다.

그럼 지금은 어떤 시장이 좋은 시장일까요?

PMF 검증은 최대한 싸고 빠르게

Airbnb mvp, facebook, twitch, tinder

기획 & MVP 출시

1. www.first1000.co 유명한 기업이 첫 유저 1000명을 어떻게 모았는지 케이스 스터디
2. Disquiet.io 메이커로그나 매거진 참고

기획 단계에서 제일 중요하고 모두가 필요성을 공감하지만 이악물고 안하는 것 Top1

1. 해당 painpoint를 겪고 있는 타겟 유저와의 1:1 심층 인터뷰
   • 매년 모두에게 강조하지만 이것 빼고 다른것들만 다함
   • 설문 등은 큰 도움 안됨(발표자료에 쓰긴 좋음)
   • 솔루션을 듣지말고 문제점을 듣는데에 집중(솔루션은 우리의 몫이고 더 잘 만들 수 있다.)

그 프로젝트와 관련된 커뮤니티에 가입해서 질문도 하고 나중에 출시를 하면서 홍보를 해봐라.

출시 준비

• 기본적인 analytics 필수(최소한 구글, 앱은 파베), mixpanel or amplitude 추천
• 지인, 가족, 친구들은 동작테스트 외에 별 도움 안됨. 지표 오염시킴. analytics 빼고 apk전달할 것.
• 채널톡 등으로 의견 수집 준비

질문

1. 웹뷰에 집착: 웹뷰인게 티가 나면 reject하기도 한다. 난이도가 높다. 구현 상으로도 브리지 설계, 애니메이션, SEO의 장점 극대화. 초기 심사를 미리 해두는게 좋다. 배포해놓고 제대로 된 기능을 추가하는 것이 좋다.
2. RTK 고려
3. FE멘토 추천