https://velog.io/@teo/frontend
위 글을 익으면서 내용을 정리해보자

1. 프론트엔드의 역사와 미래

2005	2009	2013	2020
Ajax	Node.js	React	Serverless(?)
The inception of the front-end	The mature development of front-end engineering	The rise of componentization and VDOM	데이터를 다루는 로직이 프론트로 내려오고 클라우드를 통해 서버없이 작업하는 형태

2. 프론트엔드 개발자의 업무 범위

• 웹 서비스란
  • 사용자가 어떠한 입력을 하고 입력을 통해 더 가치있는 데이터를 만들어 사용자에게 잘 전달하는 것
• 프론트엔드의 역할
  • 사용자와 서비스를 연결해주는 과정의 모든 것을 구현
    • 1. 데이터를 (예쁘게) 잘 보여주기
    • 2. 데이터(화면)을 조작하는 기능
    • 3. 서버로 데이터 보내기
    • 4. 서버에서 받은 데이터 다루기
    • 5. 개발환경 관리하기, 서버로 배포하기
    • 6. 개발자들을 위한 개발
  • 일반적인 회사에서 업무 범위 : 1~4

2.1. 데이터를 (예쁘게) 잘 보여주기

소위 퍼블리셔 영역, 최근 리액트 등 CSS in JS방식으로 스타일링하면서 프론트엔드 영역이 됨

• 1. 디자인을 HTML + CSS 로 만들어내는 작업
• 2. 적절히 재사용이 가능한 형태로 디자인을 컴포넌트화 하는 작업
• 3. 기기, 브라우저, 화면 등에 맞게 디자인이 제대로 보이기 위한 작업
• 4. 시멘틱, 접근성, 검색엔진 최적화 등을 하기 위한 작업
• 5. 초기 로딩 속도를 개선하기 위한 최적화 작업
• 6. 서버의 데이터를 적절히 디자인 컨텐츠에 연결하여 데이터와 함께 출력하는 작업

2.2 데이터(화면)을 조작하는 기능

전통 프론트엔드 영역, 이미 만들어진 데이터에서 사용자의 입력을 받아서 적절히 다른 데이터(화면)로 변경하는 역할

• UI, DOM, WEB API에 대한 이해필요

• View를 이루고 있는 데이터에 대한 깊은 이해를 요구

• Javascript

• 1. 현재의 화면을 데이터로 구성
• 2. 사용자의 이벤트를 감지
• 3. 해당 이벤트를 적절한 행동으로 분류
• 4. 행동에 맞는 적절한 WEB API를 동작
• 5. 해당 API의 결과를 통해 새로운 데이터를 생성
• 6. 이 데이터를 기존의 데이터와 조립해서 원하는 데이터로 변경
• 7. 해당 데이터를 화면에 출력

2.3 서버로 데이터 보내기

• 백엔드에 의존성

  • 인증, 보안, 헤더, CORS 등 백엔드에서 만들어둔 설정에 따라 맞춰서 작업해야 함
  • 코딩이 아닌 학습의 영역 & 협업의 영역
    • 백엔드와 적절히 협업할 수 있을 정도의 CS 능력이 필요
      • HTTP프로토콜 & REST API의 간단한 이해
• 1. API 문서를 잘 읽기
• 2. 서버에서 정의한 scheme에 맞게 내부적으로 type을 설정
• 3. 서버로 보내기 전 데이터를 검증하는 작업
• 4. 화면에 있는 데이터를 API에서 사용하는 구조에 맞게 변경
• 5. 백엔드에 지정한 API의 양식에 맞춰 URL, Method, Header, Params, Body 등을 만들어서 전달
• 6. 이때 중복 전달 방지를 위한 distint, 쓰로틀링, 디바운싱을 사용하기도 함
• 7. 인증 및 보안은 회사 내부 규정을 따름

REST API or GraphQL or gRPC or Web Socket or Web RTC 스트리밍 등 데이터 교환에는 여러분야가 존재하고 개발하는 영역에 따른 추가 공부가 필요

2.4 서버에서 받은 데이터 다루기

• 서버에서 데이터를 전달받아서 화면에 필요한 데이터로 변환하는 과정
  • 백엔드와 협업 필요
  • 서버의 API가 비동기로 이루어짐
  • 서버와의 스키마와 화면의 스키마가 일치하지 않을 수 있음

1. 백엔드에서 만들어둔 스펙과 실제 화면에서 보여줘야 할 스펙이 일치하지 않기 때문에 이를 적절히 만들어 줄 수 있어야 함
2. 데이터의 응답속도가 느리기 때문에 실제 화면과 데이터간의 타이밍이 일치하지 않음

• 이러한 비동기성 특정으로 인한 로딩, 중복 방지 등 중간 과정을 적절히 처리할 수 있어야 함

3. 서버 응답에 따른 문제 원인 확인 및 문제 해결 능력이 필요 - 상태코드 볼줄 알아야 함

graphQL이나 react-query 등은 이러한 문제를 좀 해결하자고 나온 라이브러리이다

일반적인 회사에서의 프론트 업무 범위 : 1~4

• 프론트 개발자의 영역 : 사용자의 화면 + 데이터를 백엔드로 전달하고 받는 모든 과정의 파이프라인을 담당
  • 스펙트럼이 넓음 => 사용자에 가까운 쪽 vs 백엔드에 가까운 쪽 => 업무 모양이 달라짐
• 데이터를 전문적으로 다루진 않지만 데이터를 시각화하는 과정에서 기본적인 화면을 만들어내는 능력과
• 화면을 데이터로 이해하고 구성하는 2가지 능력을 동시에 요구
• 또한 디자이너, 기획자, UX, QA, 백엔드, 사업까지 다양한 분양의 동료들과 적극적으로 협업을 해야하는 위치이기 때문에 다른 분야에 대한 이해도가 높아야 함
• 일반적으로 웹 개발은 퍼블리셔, 프론트, 백엔드 이런식으로 역할을 나눠져 있으나 명확한 업무 구분이 존재하지 않음
  • 서로의 영역이 겹치는 그레이영역이 존재
• 퍼블리셔는 2.3~2.4영역을 다루지 않는 것을 의미
• 백엔드는 2.1~2.2 영역을 다루지 않는 것을 말함
• 프론트엔드는 1~4영역을 혼자서 다하는 것이 아닌 자신만의 포지션이 있음
  • 기능단위로 쪼개어 넓은 영역을 커버하는 경우
  • 퍼블리셔가 컴포넌트와 화면 구성 데이터 연동까지 하는 경우
  • 프론트엔드가 Serverless 혹은 BFF를 통해서 백엔드의 기능을 구현하기도 함
  • 이 경계선은 회사마다 다르고 역할마다 다름
• 프론트엔드라는 영역은 원래 없던 영역이 아니라 웹이 거대해지면서 점점 영역이 넓어지고 있기 때문에 고정되어 있지 않고 점점 더 확장이 될 것임

2.5 개발환경 관리하기, 서버로 배포하기

• 프로젝트를 담당하게 되면서 초기 모든 사람들이 개발을 할 수 있도록 기술 스택을 정리하고 개발 환경을 설정하는 작업도 필요
• 그리고 결과물을 외부로 배포하기 위한 작업도 필요
• 소스코드를 관리하고 일정을 관리하는 일도 필요
  -> 보통 이런 역할을 PL(Project Leader)라고 부름

1. 프로젝트 개발 환경 설정 및 패키지 관리
2. 프로젝트 컨벤션, 디자이너와의 컨벤션 조율
3. 일정과 이슈관리 및 분배
4. 배포 프로세스 및 릴리즈 관리

2.6 개발자들을 위한 개발

• React와 같은 도구들을 개발하는 업무
• 사내에서 쓰는 공통 모듈이나 공통 라이브러리나 디자인 시스템의 컴포넌트와 같은 것을 만들고 배포할 수 있음
• git, jira, npm과 같은 도구드를 사내 환경에 맞게 설치를 하고 환경을 만들어주는 업무들도 여기에 속함
• SDK나 OPEN API 등 외부로 공개되는 모듈을 만드는 역할도 여기에 포함

3. 잘하는 프론트엔드 개발자란?

• 시간을 잘맞추고 협업을 잘하는 사람
  • 밤새가면서 맞추라는 의미는 절대 아님
• 프로젝트의 규모와 요구사항을 통해서 전체적인 일정을 스스로 컨트롤 할 수 있어야 함
  • 주니어를 벗어났는가를 구분하는 요소 : 일정 컨트롤 할 수 있는지 여부

많이 알고 소통을 잘해야 한다.

• 프론트와 협업 라인 : 기획, 디자인, 벡엔드, QA, UX, 사업, 사용자
• 프론트엔드 기술 뿐만 아니라 다른 분야에 대한 지식이 충분히 있어야 함
• 사용자를 기준으로 하는 사고 방식과 백엔드의 데이터를 기준으로 하는 사고방식의 차이가 존재
• 디자인 사고방식과 구현의 사고방식 역시 다름

소통의 방식중에는 말도 있지만 글도 있다.

• 문서를 잘 작성하는 것도 잘하는 개발자의 능력

일하는 소통만 소통이 아니다.

• 기본적인 인성과 유머, 성실함, 공감능력, 긍정성, 주도성과 같은 인성적인 측면이 무엇보다 중요
  • 함께 일하고 싶은 사람인가?

빨리 할 줄 알아야 한다.(프로토타입에 능해야 한다.)

• 요구사항을 빨리 이해
• 빠른 결과물을 만들어내는 능력
• 구현에 시간이 오래걸릴 수록 매몰 비용으로 인해 포기하는 비용이 높아짐

프론트엔드는 잘하는 사람이 잘한다.

• 회사에 따라 webRTC 등을 이용한 화상,
  Socket을 이용한 실시간 처리,
  3D를 이용한 처리,
  AI를 다루는 일들은 전문지식이 필요
  • 자식만의 주특기를 잘하면 이런 분야(회사)에서 잘하는 개발자가 된다.
• 비지니스적 가치를 만들어 낼 수 있다면 그것도 잘하는 개발자가 될 수 있다.

프론트엔드의 가치는 기술보다 본인이 만드는 서비스의 가치로 먼저 평가받는다.

• 프론트엔드 기술이 좋아도 결과물이 형편없다면 가치를 인정받을 수 없다.
  • 좋은 디자인과 UX를 가진 서비스를 만들 수 있어야 한다.
  • 개발자가 서포트 해주는 만큼 디자인과 UX는 얼마든지 더 좋아질 수 있다.
• 좋은 서비스가 무엇인지에 대한 철학, 좋은 서비스를 만들기 위해서라면 내가 한 것을 갈아 엎을 수 있는 용기와 끈기도 필요
• 좋은 서비스를 만들기 위해 협업하고 조율하는 과정
• 좋은 서비스를 골라낼 수 있는 시각
• 좋은 서비스를 만들기 위한 문제 인식 과정 등
• 좋은 서비스를 위한 모든 행동들이 잘하는 프론트엔드 개발자로 만들어 줄 수 있다.

같은 프론트엔드 동료의 입장에서는 트렌드 파악을 잘하는 사람이 좋다.

• 트렌드 캐치를 잘 하면서 좋은 소식을 잘 공유해주는 개발자들이 좋은 동료개발자이다.
• 프론트엔드는 특히 성장 속도가 빠르기 때문에 트렌드를 놓치면 낡은 개발자가 되어 버린다.
• 더 나은 Best Practice를 적립해 나갈 수 있는 동료
• 개발에 대한 철학이 뚜렸하고 함께 논의를 할 수 있는 동료
• 프론트엔드 성장이 빠르기 때문에 Best Practice가 적립 되기 전에 새로운 것이 나올 수도 있다.
  • 열린 마음으로 새로운 것을 받아들이고 끊임없는 탐색을 통해 최근의 트렌드를 쫒아가는 감각이 매우 중요
• 무엇보다 이러한 감각을 토대로 현재 프로젝트에 적절한 기술을 선택하는 밸런스를 갖추는 것이 중요

정리

• 정해진 리소스안에서 되게 해주는 것

• 협업과 소통

• 트렌드와 현실의 균형 감각

• 좋은 서비스를 만들고자 하는 노력

• 일정과 인력이라는 정해진 리소스안에서 어떻게든 최대한의 퍼포먼스를 내어 요구하는 것을 구현해주는 것이 개발자의 역할

2인분 이상 하는 법

• 회사라는 집단에서 문화와 힘을 만들어내는 것
• PM & CTO
  • 개인의 일정을 조율 -> 팀의 일정의 조율 -> 회사의 일정을 조율
  • 개인의 기술스택 -> 팀의 기술스택 -> 회사의 기술스택
  • 여러명의 개발자들의 능력을 더 끌어낼 수 있고 회사의 이익이 되는 방향으로 설정
• 좋은 철학을 가지고 회사의 문화를 만들고 그 문화에 어울리는 사람들을 모아서 키워나가는 역할

고찰

• 회사를 옮기면서 다른 업무방식에 적응하는데 시간이 걸렸다.
  기존에 백엔드에서 데이터를 사용하기 좋게 주었다면
  이번엔 리소스를 기준으로 가져와서 프론트에서 가공해서 사용해야한다.
  이런게 view model이란 개념인걸까?

• 이 글에선 테스트, 좋은 코드에 대한 언급이 없다.
  프론트엔드는 코드품질에 대해선 중요하지 않다고 생각하는걸까?
  일정과 소통은 당연하고 코드품질과 테스트도 중요하다고 생각했었는데 약간 혼란스럽다

• https://youtu.be/TTLHd3IyErM
  드림 코딩 유튜브를 보면서 다시한번 생각해봐야겠다.
  하나의 글만 읽고 정답으로 생각하기 보단 이 사람은 이렇게 생각하는 구나하고 참고하는 정도로 생각해야될 것 같다.