[패스트캠퍼스] 김민태의 React와 Redux로 구현하는 아키텍처와 리스크관리 (2-1)

productuidev·2022년 7월 17일
0

FE Study

목록 보기
42/67
post-thumbnail
post-custom-banner

김민태의 React와 Redux로 구현하는 아키텍처와 리스크관리(2)

패스트캠퍼스 The Red

2. 안정적인 프로덕트를 위한 아키텍처 설계와 리스크 관리

스타트업에서의 개발환경

1) 프로덕트 개발환경

서비스를 개발하는 데 있어서 광범위하게 고려해야 할 점 (회사 차원)
전제에 대한 공감

riskm1

여러가지 상황들

  • 어플리케이션을 잘못 개발되었을 때
  • 구조적인 문제가 있을 때
  • 협업과 과정에 문제가 있을 때
riskm2

Scale

  • 서비스의 규모가 성장하면서 발생
  • 한계를 가진 소프트웨어
  • 트래픽이나 사용자가 늘어나거나
  • 오버엔지니어링(비용) <-> 적절한 설계와 비용

Start-up

riskm3
  • 우아한 형제들 : 성공한 회사
  • 스타트업 vs 일반기업의 미묘한 차이
  • 회사마다 다른 프로덕트 개발 환경, 뭐가 다를까? 뭐가 비슷할까?

공통점

여러분이 대표라면?
riskm4
  • 대부분 제한된 리소스
  • 기업의 속성
  • 무제한 주어지는 시간으로 만드는 회사는 없다 (한정적)

차이점

riskm5
  • 인원이 충분하지 않다 (전사 규모 대비 인원)
  • 시니어가 없는 경우에 일어나는 상황과 갈등
  • 두려움, 조급함,
riskm6
  • 프로덕트 실패비용
  • 회사가 문을 닫아버리는 경우
  • 하나의 프로젝트가 실패했다고 할 때 개발자로서 감당하는 리스크

1-1) 제한된 리소스

스타트업에서의 개발...

  • 인적자원 (Human Resources) : 나와 동료
  • 부족한 시간 : 촉박한 개발 일정
  • 충분히 납득이 가는 여러가지 논리적인 이유 속에 받게 되는 미션들
  • 해결법(솔루션)을 찾으려면 문제를 찾아야 한다 (추상적인 문제 제기 x)
  • 항상 회사는 구인을 하지만 구인에만 목맬 수는 없다
  • 개발 역량 한계 : 나와 동료 모두 (물리적인 시간의 한계, 죄 x)

주어진 리소스 내에서 개발할 수 있는 범위와 타협점을 찾아야 한다
객관적으로 문제를 드러내고 현실적인 해결책을 찾아야 함
(그러나 부족한 부분을 드러내야 한다는 점에서 커뮤니케이션, 감정 문제로 번져질 수 있어 조심스러움)

riskm7
한정된 스타트업에 다닌다면..
당장 동작하는 코드가 우선이다.

현재 스케일 상태가 어디인가?
동작이 되야 서비스가 되고
서비스가 되야 회사가 살고
회사가 살아야 제품을 끊임없이 개선할 수 있는 찬스가 있다

1-2) MVP

초반에는 코드 퀄리티에 너무 집착하지 말아라
제품 개발에 포커스를 두는 데 집중

riskm8
정답은 없어 갑론을박하는 문제지만 이를 두가지로 나눠보자
riskm9

김민태 개발자가 생각하는 우선 순위

  • 서비스 관점 = 도메인 전문가 (기획자, 비즈니스맨이 보는 관점)
  • 개발자나 디자이너가 보는 관점과 다르고 비전문적일 수 있지만 그 분야에 대한 직관을 가지고 있을 수 있다
  • 직관에 대한 결정에 대한 빨리 보완하고 재정비하는 것이 개발자의 역할
빠르게 대처할 수 있는 아키텍처는 무엇일까?
  • 개발자의 포지셔닝을 생각하고 개발자로서의 취할 수 있는 스탠스를 따져보기
riskm10
  • 주니어만 있는 스타트업이라면 생각하기 어려운 문제
  • 현재 단계, 규모, 인력에서 가장 적정한 기술은 무엇일까 (객관화)
  • 구현 속도
개발자로서 시장에서 가장 핫한 프레임워크가 있다?
그걸 쓰지 않으면 내가 도태되는 거 같다고 드는 생각
도구의 퀄리티도 중요하지만
적정기술의 관점에서 생각하면
내가 처한 상황과 만들어야 되는 제품을 모두 포괄해서
적정기술을 골라야 할 때
트렌디한 기술과 트렌디하지 않아도 충분히 빠르게 구현할 수 있는 기술인지
초기에는 퀄리티보다는 생존이 중요하다
그 이후에 고려할 수 있는 것 생각하기

2) 웹 개발을 설계하는 방식

네이티브 웹 서비스

riskm11
  • 인적 자원, 시간, 기술적인 이슈들로 PC보다 모바일, 앱보다는 웹이 더 우선시되는 상황
  • 내가 현재 개발해야하는 서비스에 특화된 기술
  • 유형과 무관한 공통 고려 요소
riskm12

웹 서비스에서 고려할 사항...

1. 웹의 철학과 특징을 고려하라
문서, 접근성, 어떤 브라우저에서도 동일하게 보여지도록
2. 기술이 서비스 성공의 촉매 역할을 할 수도 있다
ex) 접근성, SEO, 해상도 고려 등
3. 모든 것이 공유될 수 있는 자원이라는 것을 고려하라
ex) SEO(검색엔진 최적화), 오픈 그래프 최적화(사소하지만 서비스에 대한 호감도 상승), 소스 코드)기본적인 필터링의 중요성)
4. 외부 서비스 연동 정보를 관리하라
ex) API Key, 인증서(갱신 만료) 등

디자인과 디테일한 UX를 추구하라...
1. 신규 서비스의 어설퍼 보이는 UX는 좋은 이미지를 만들 수 없고, 가치가 하락한다
프론트엔드 개발자로서 협업을 통해 고려할 수 있는 구현사항
2. 발빠른 테스트와 릴리즈를 위한 아키텍처를 처음부터 고려하라
ex) A/B 테스트, 부분 업데이트가 가능한 격리된 컴포넌트 구조 설계
3. UX의 견고함과 기능이 경합을 벌이면 견고함을 선택하라
높은 수준의 사용자 경험을 했던 사용자라는 전제 하에

가능하면 최신 기술을 사용하라...
1. 레거시가 없는 서비스라는 장점을 최대한 활용하라.
누구나 안정적인 회사에 가고 싶어하는데 인력을 구해야 하는 걸 생각할 때..
적절한 최신 기술 사용은 매력 요소가 별로 없는 스타트업의 기술인력 확보에 도움을 줄 수 있다.
ex) PWA, WebRTC, AMP, Web Assembly 등
2. 낮은 버전의 브라우저 환경은 과감히 버려라
기술을 선택할 것인가 일반 환경을 선택할 것인가

riskm13

기능 개발과 출시 시 취향이 아닌 논리적인 근거 기준
사용자 로그를 반드시 심어라
현재 단계의 분석이 어렵다면 일단 로그를 모은 후 이후 차근차근 분석하여 서비스를 지속 발전시키기


💬 스타트업을 고려하거나 신사업을 하고 있는 사람들에게 좋은 인사이트가 되는 내용 😀

profile
필요한 내용을 공부하고 저장합니다.
post-custom-banner

0개의 댓글