FE 개발 엔지니어와 관련된 기술 공부에만 몰두하다보면
나의 공부 방향이 맞는지, 도대체 왜 공부하는지 의문이 들때가 있다.
그럴 때마다 이 포스팅을 본다면 앞선 의구심을 잠재울 수 있다.
! 참고 !
이 포스팅은 버킷플레이스(오늘의 집) 프론트엔드 리드 조은 개발자의
요구사항 분석과 적정 기술 The Red 강의 내용과 저의 견해를 합친 내용입니다.
성장의 지름길을 놓아주는 질문들
혹시 아래 질문들에 대해서 생각해 본적이 있는가?
- 왜 앱을 만들지 않고 웹을 만드는가?
- 비지니스적으로 FE 개발자는 왜 필요한가?
- FE는 어디까지 알아야할까?
- React는 왜 쓰는가?
한번도 생각해 본적 없었던 나는 그저 기술 공부에만 몰두하는 사람이었다.
정확히 말하면 HTML, CSS, JS 기초 공부도 따라가기 벅차하는 신입 개발자이다.
이런 질문들을 던지고 구체적으로 생각해 보기 전까지는
위 질문들이 지금 당장 나에게 필요한 질문이라고는 생각하지 않았다.
하지만 지금은 과거의 저 생각을 후회하고 있다.
위 질문들은 지금 당장 나에게 필요한 질문들이다.
지금은 성장의 지름길을 놓아주는 질문들이라고 생각한다.
FE의 정체성을 알려주는 생각 Flow
위 질문들 왜 해야하며, 이에 대한 답을 조은 개발자는 아래 Flow를 기반으로 차근차근 알려준다.
- 비지니스 파악하기
- Product 파악하기
- User Flow + MSA 파악하기
- 기술 요구 사항 파악하기
- 기술 제안 하기
위 생각 FLow를 천천히 잘 따라가다보면 FE 개발자는 어떤 일을 하는 사람인지 그 정체성이 보인다.
1. 비지니스 파악하기 ↔ 2. Product 파악하기
-
FE 기술을 열심히 배워서 어디에 도움이 될까?
조은 개발자는 비지니스에 도움을 주기 위함이라고 답한다.
비지니스는 사회적 문제를 해결하려는 비전을 이루고 사회적 부가 가치를 창출하는 영역이다.
이 영역에 투입되는 것이 Product이고, Product에 사용되는 도구가 바로 FE 기술들이다.즉, 아래 세 가지 영역은 연결되어 있다.
비지니스 ↔ Product ↔ FE 기술 -
글로만 보면 와닿지 않으니, 테슬라의 미션(비전)중 하나를 살펴보자.
'신뢰 가능하고 효율적이며 지속 가능한 21세기 가장 매력적인 전기 자동차 회사'
위 비전을 통해 얻으려는 부가 가치 창출은 다음과 같다.
'세계가 지속 가능한 에너지로의 전환에 기여'
즉 테슬라의 비지니스는
'신뢰 가능하고 효율적이며 지속 가능 전기 자동차를 통해 세계를 지속 가능한 에너지로 전환시킨다' 이다.
위 비지니스를 성취하기 위해서 필요한 Product는 전기 자동차이다.
그렇다면 FE 관점에서 Product는 어떤 부분이 될 수 있을까?
바로 UX와 직관된 차량 인포테인먼트 시스템이다만약 당신이라면 유튜브 로딩마저 느린 차량의 자율주행 서비스를 신뢰할 수 있을까?
이처럼 FE가 신경 써야할 차량 인포테인먼트 시스템의 렌더링, 로딩 부분에서 문제가 생기면
'신뢰 가능한 전기 자동차' 비전은 물론, Product 자체에 의미가 없어진다.
아래 세 가지 영역은 연결되어 있다.
비지니스 ↔ Product ↔ FE 기술
3. User Flow + MSA 파악하기 ↔ 4. 기술 요구 사항 파악하기 ↔ 5. 기술 제안 하기
-
비지니스와 Product를 이해했다면 구체적으로 뭘 해야할까?
FE의 정체성을 더 구체화 시키기 위해 조은 개발자는
User Flow와 Macro Service Architecture 파악을 권한다.
Product User는 어디서 유입이되고
곳곳에서 유입된 User마다 어느 페이지를 시작 페이지로 보여주는 것이 좋은지
운전자가 화면을 사용중인지 동승자가 화면을 사용중인지에 따라 필요한 기능을 구분하는 등
고려해야할 점이 많다.당연히 FE 개발자 혼자서 이 모든 내용을 파악할 수는 없다.
하지만 CTO, UXD, PM, 디자이너 등 기술 조직에 종사하는 전문가들에게
본인이 생각하지 못한 부분을 최대한 물어보며 모든 User Flow와 MSA를 파악하는 것이 중요하다고 말한다.
이러한 과정이 FE의 진짜 정체성을 결정하는 과정인
기술 요구 사항 파악 및 제안 과정과 바로 연결되기 때문이다. -
User Flow + MSA 파악이 완료되었다면 기술 요구 사항과 제안은 자연스럽게 따라온다.
배포 주기는 어떤 식으로 가져갈까요?
Product 환경은 어떻게 구성할까요?
화면을 분할 기능이 중요한가요?
서비스 전체 아키텍처는 어떻게 할까요?
Dev - Stage- Real 환경을 구성해야할까요?
검색 기능이 필요한가요?
소셜 로그인을 지원해야하나요?
유저 트래킹이 가능해야하나요?
이 기술 요구 사항들에 맞춰 기술 제안이 들어갈 수 있는 것이다.
앞선 flow대로 왔다면, 그냥 '저희도 React 쓰면 안되나요?' 가 아니라,
' 운전 중에 동승자가 화면을 사용하는 경우,
DOM을 사용하면 전체 렌더링을 하는데 React를 사용하면 부분만 렌더링 할 수 있으니,
차량의 소스를 아껴 자율주행 서비스에 큰 영향을 주지 않을 수 있다.' 라는 구체적인 이유가 나오게 된다.어느 프로젝트든 간에, 써보고 싶어서라는 이유는 최악이다.
React를 사용해야한다면, 반대로 Angular, Vue, jQuery는 왜 사용하면 안되는지 고민해봐야한다.
또한 아래 예시만 봐도
기술 선택 및 제안은 개발자 혼자만의 영역이 아니라는 것을 알 수 있다.
예시)
비지니스 (충성고객 만들자) → 프로덕트 (UX, 체류 시간 늘리기) → 기술 (로딩속도 개선, SEO, 전환 속도 향상) → Task (이미지 최적화, SSR, prefetch, cache 등) → Next.js (모든 Task 케어 가능)
