리액트 프리랜서 체크리스트

출처(번역) Freelance React Developer Checklist

리액트 프리랜서로서, 저는 요즘 리액트 프로젝트에서 많은 고객들과 함께 일합니다. 이메일로 요청을 받을 때마다, 저는 보통 리액트 프리렌서 개발자 체크리스트 템플릿으로 답장합니다.

 

본질적으로 이 체크리스트는 리액트 프리랜서로서 프로젝트 참여를 더 원활하게 만듭니다. 왜냐하면 회사가 여러분을 고용하기 전에 양측의 요구 사항을 맞추기 위해 이 체크리스트를 통해 대화해야 하기 때문입니다.

이 글에서 체크리스트의 항목을 자세히 공유하겠습니다. 여려분이 직장을 찾는 구직자이든, 고용하려는 회사이든 상관없습니다.

리액트 프리랜서 체크리스트

프리랜서로서 회사와 일하기전에 항상 알고싶은 몇가지 세부사항이 있습니다.

• 이 프로젝트의 규칙이 뭔가요?
• 이 프로젝트의 마감/기한이 언제인가요?
• 회사의 배경이 뭔가요?

그러나 프리랜서에게 가장 중요한 질문이 있습니다.

신규 프로젝트인가요?

많은 프리랜서들은 신규 프로젝트가 프론트엔드의 레거시 코드를 피하면서 아키텍처를 설계하고 라이브러리를 선택하는 것이 더 창의적이기 때문에 이득으로 보고 있습니다. 그러나, 항상 신규 프로젝트에서 일하는 것만은 아닙니다. 제가 경험한 바로는 리액트에 대한 지식이나 개발 실력의 부족으로 문제에 직면하고 도움이 필요한, 이미 진행 중인 프로젝트에 투입되는 경우가 대부분이었습니다.

팀원이 누구인가요?

개인의 성향에 따라, 혼자 또는 팀에서 일하는걸 선호할 수 있습니다. 혼자 일한다는건 두 가지를 의미합니다. 말 그대로 MVP처럼 혼자 모든걸 하거나, 프론트엔드 개발자로 참여하고 백엔드, 디자이너 등과 함께 협업하며 작업할 수 있습니다. 여러분을 고용한 회사에서 해당 프로젝트에 또 다른 프리랜서를 투입하는 경우도 있습니다. 그런 경우, 프론트엔드 담당자를 아는 일이 매우 중요합니다. 프리랜서들끼리 작업하면 제대로 진행되지 않을수도 있습니다.

의사소통 체크리스트

저는 새로운 회사에서 리액트 프로젝트에 참여할 때, 항상 다섯가지 의사소통 채널을 구축하려고 노력합니다.

Real Time (실시간)

Slack같은 도구는 프로젝트 관계자와 함께 실시간으로 주제에 대해 토론하는 것을 도와줍니다. 장기 프로젝트의 경우 팀원들과 스몰 토크를 도와주기도 합니다. 어쨌든, 주제에 대해 토론하기를 원한다면, 이 방법이 최고입니다. 그러나, 특정 작업에 관한 것이라면(급한 일이 아니라면) 작업 관리자 방식이 더 적합합니다.

Task Manager (작업 관리자)

Trello와 같은 작업관리자 의사소통 방식은 실시간 방식에 비해 더 비동기적입니다. 그러나, 이 방식은 특정 작업에 대한 주제를 유지하는 데 도움이 됩니다. 덧붙여서, 작업이 끝나더라도 이해관계자는 토론을 할 때 작업들을 연결하거나 특정 결정이 내려진 이유를 찾을 때 항상 과거를 참조합니다.

Pull Requests

작업이 완료될 때, PR은 코드 리뷰를 하곤 합니다. 코드 리뷰를 항상 하진 않더라도, PR은 작업 관리자의 작업에 다시 연결할 수 있습니다. 반대로 작업은 PR에 연결되어야 합니다.

Email

개인적으로 저는 이메일을 가능한 적게 사용하고 매우 중요한 문제에 대해 상위 이해관계자(ex: CEO, PO)와 논의해야 할 때에만 사용하려고 합니다. 대부분은 실시간 채널이 있기 때문에 이메일은 온보딩 경험과 송장 발행에만 사용합니다.

Meetings

네, 프리랜서라도 미팅은 있을 겁니다! 고객을 위해서 얼마나 많이 일하냐에 따라, Meetings는 이전, 혹은 향후 계획에 대해 논의하기 위해 더 자주 하게 될 겁니다. 저는 주간, 격주, 월간 회의가 있는 고객도 있었습니다. 일반적으로 프리랜서로서 매일하는 스탠드업 회의에는 참석하지 않습니다.

 

회사에서 일하는 프리랜서라면, 처음에 이 모든 채널에 초대받아야 합니다. 만약 여려분이 대기업에서 일한다면, 초대 폭격을 받게 될 겁니다. VPN 등에 가입하기 싫다면 클라이언트에게 얼마나 많은 채널이 필요한지 미리 문의하세요.

워크플로우 체크리스트

만약 여려분이 이미 설립된 팀에 들어간다면, 팀은 이미 그들만의 워크플로우를 갖고 있으므로 적응해야 합니다. 칸반에서 스크럼까지, 코드 리뷰에서 코드 리뷰 없음까지, main 브랜치에 푸시부터, 기능 브랜치까지 다양합니다. 그러나 여러분이 이걸 결정할 수 있다면, 또는 팀의 첫번째 개발자라면, 여러분을 위한 짧은 워크플로우 팁 목록이 있습니다.

칸반, 스크럼, 파워 요가를 하나요?

소규모의 팀과 함께 작업하는 경우, Lean 접근을 위해 칸반을 제안합니다. Trello는 잘 알려진 프로젝트 관리 도구입니다. 칸반에서 최대 라인 수, 개발자당 항목 수 같은 부분은 공식적인 규칙을 따라야합니다.

코드 리뷰를 하나요?

동료와 함께 일한다면 Yes. 만약 코드리뷰를 할 수 있을 정도의 여건이 된다면 팀을 위해 하세요. 팀 전체가 서로의 코드를 이해하고, 버그를 찾고, 새로운 코드를 작성할 때 원인과 결과를 논의하는데 도움이 될 겁니다.

기능 브랜치(Feature Branch)를 쓰나요?

동료와 함께 일한다면 Yes. 모든 사람이 메인 브랜치에서 작업하면 자동으로 충돌이 발생합니다. 만약 팀이 기능 브랜치에 대해 모른다면, 단계별 튜토리얼을 알려드리겠습니다.

여러분은 리액트 개발자이기 때문에, 회사에서는 프론트엔드 어플리케이션을 위해 여러분을 고용하고 싶어합니다. 그러나 이게 100% 리액트로 작성한다는 의미는 아닙니다.

여러분은 스스로 T자형 인재가 되도록 해야합니다. 보통 디자인, 프론트엔드, 백엔드, 데이터베이스, 비즈니스를 포함한 팀에서 일하기 때문입니다. DB 관리자와 대화할 일은 멀겠지만 여러분은 UI,UX 디자이너, 백엔드 개발자 및 기타 PO, PM, CTO, CEO와 협력해야합니다.

UI/UX 체크리스트

가장 많은 질문: "보기 좋게 할까요? 픽셀을 정확하게 맞출까요?"

이건 여러분을 고용한 회사의 규모에 따라 다릅니다. 회사가 UI/UX 개발부서를 가졌다면 정확하게 픽셀에 맞춰주세요. 디자인 팀에게 목업을 가져와 HTML,CSS(margin, padding, border, height, width 등)에 픽셀을 매칭시켜야 합니다.

작은 회사와 작업하는 경우, UI담당 인원이 없어 보기좋게 작업해달라는 경우가 있습니다. 또, 목업을 제공하지만 코드 변환으로의 완벽한 픽셀을 제공하지 않는 회사도 있습니다. 그러나, 픽셀을 정확하게 맞추는 것이 더 좋은 방법입니다.

어디에서 목업을 가져오나요?

프리랜서 웹 개발자로서 목업 작업을 받는 경우, 보통 디자인 팀은 이미 목업을 제공하기 위해 선택한 도구를 갖고 있습니다. 디자인 도구는 단순히 "이미지를 PDF로 가져오기" 부터 "상호작용할 수 있는 목업" 까지 다양합니다. 제가 즐겨사용했던 도구는 Zeplin, Invision, Figma입니다.

말했듯이, 이것들은 당신을 프리랜서로 고용한 회사에 따라 다릅니다. 때때로, 회의에서 CEO와 함께 목업을 만드는 경우도 있고, 회사의 레거시 어플리케이션에서 이미지를 가져와야하는 경우도 있습니다.(좋지는 않지만, 안내를 받으면 해결할 수 있습니다) 그리고 때로는 모든 화면과 상호작용에 대해 준비된 솔루션을 가지고 작업할 수도 있습니다.

어떤 색, 폰트를 사용해야 할까요?

여러분이 디자인 팀과 함께 일하고 있다면 디자인 팀이 보조해 줄겁니다. 보통 디자인 가이드라인을 링크 혹은 PDF로 제공하고 여러분은 가이드라인에 따라 색상과 폰트를 사용하면 됩니다. 덧붙여서, 클라우드 저장소같은 링크는 모든 정보(ex: 로고, 아이콘)에 대한 접근권한을 제공할 수도 있습니다. 그러나, 디자인 팀이나 디자이너 없이 일한다면 프로젝트에 참여할 때 질문해야합니다.

회사 아이콘을 사용하나요?

처음은 아니더라도, 이건 확실하게 물어봐야합니다. 다시 말하지만, 디자인 팀과 작업할 때(인기 있는 라이브러리를 사용하거나) 아이콘은 이미 있습니다.

그러나, 소규모 회사와 작업중이고 그들이 커스텀 아이콘을 사용해야한다고 한다면(잡일 때문에 추천하지 않지만, 특별한 사이트를 만들수는 있습니다) 누군가는 아이콘을 만들어야 합니다. 누가 아이콘을 만들든, 아이콘의 필수 요구사항(크기, 색 구성, 여백 등)을 충족해야합니다.

모바일 페이지도 만드나요?

디자인 팀이 있는 회사에서 작업하는 경우, 프로젝트가 데스크탑만 원하는지, 데스크탑 우선인지 혹은 모바일만 원하는지, 모바일 우선인지 이미 정해두었을겁니다.

소규모 회사에서 일한다면, 이 주제를 전달하는 방법이 중요합니다. 고객사에게 모바일/태블릿/데스크탑에 반응형으로 구현해야하는지 묻는다면 막대한 작업량(추가 목업, 추가 구현)을 고려하지 않고 "예" 라고 말하기 때문입니다.

API 체크리스트

프론트엔드 개발자로 채용될 때, 사용할 백엔드의 종류는 호환을 생각하는 레거시 REST API, 신규 REST API, GraphQL까지 다양합니다. 대부분 백엔드는 미완성일 가능성이 높습니다. 프론트엔드의 요구사항에 따라 기능이 확장되는 경우가 많기 때문입니다.(API 수정, 신규 API, API 분리, 성능, 페이지네이션 등)

리액트 개발자에게 가장 중요한 것은 API입니다. 따라서 여러분은 반드시 질문해야합니다.

어떤 종류의 API를 제공하나요?

개인적으로 GraphQL API를 좋아합니다. 그러나 REST API로 작업할 가능성이 매우 높습니다. 어쨋든, Roy Fielding이 제안한 것처럼 REST API는 진짜 REST가 아닙니다. 그렇기 때문에 백엔드 팀이 REST원칙과 RESTful, RESTish에 대해 알고있는지 아는 것이 중요합니다. 저는 불필요한 자원 중첩, 모호한 이름, GET/POST만 사용하는 REST API로 작업해왔습니다. 프론트엔드 개발자로서 프로젝트에 참여하기 전에 이에 대해 아는 것은 백엔드를 연결하는데 불필요한 어려움을 피할 수 있는 좋은 지표입니다.

API 문서는 어디에 있나요?

GraphQL로 작업하면 자동으로 생성된 스키마가 필요한 모든걸 제공해 줄겁니다. REST로 작업할 때는 API 문서를 위해 백엔드 엔지니어와 조율해야합니다. 저는 이 모든걸 경험해봤고, 그중 좋았던 경우에 대해 알려드리겠습니다.

• Slack을 통해 백엔드에게 요청한 API
• 깃허브 레포지토리에 문서가 있는 경우
• Swagger같은 도구로 생성된 문서

대부분의 작업은 REST로 구현하겠지만 프로젝트에 따라 GraphQL, Firebase, ABI 처럼 다른 데이터 소스가 있을 수도 있습니다.

프론트엔드 체크리스트

앞서 언급한 바와 같이 T자형 프론트엔드 개발자가 되는 것이 좋습니다. 프론트엔드보다 더 많은 일을 할 수 있기 때문입니다. 예를 들어, 고객이 풀스택 + 디자인을 원한다면 프론트엔드보다 더 많은 책임을 져야 할 겁니다. 제 경우에는, 고객이 인증 서비스 설정과, CI/CD, 데이터베이스와 GraphQL연결을 요구하기도 했습니다. 따라서 새로운 프로젝트에서 항상 여러분의 책임 정도를 측정하세요.

사용할 라이브러리에 대한 계획이 있나요?

이 질문은 프로젝트가 새로 출발하는 것인지, 이미 진행중인 프로젝트인지에 따라 달렸습니다. 일반적으로 이 질문은 프로젝트 성격의 범위를 좁히는 데 도움이 됩니다.

또한, 저에게 최고 책임자 역할을 기대하고 채용하는 회사는 이미 프로젝트에 무엇을 사용할 지 질문하므로, 여러분은 리액트 생태계를 얼마나 잘 아는지 보여줄 수 있는 기회를 제공합니다. 반대로 이미 프로젝트가 진행중인 경우 기술 스택을 파악하는 데 도움이 됩니다.

얼마나 커스터마이징이 필요하나요?

저에게 있어 가장 중요한 질문중에 하나입니다. 새로운 프로젝트의 견적을 요청할 때, UI 라이브러리를 사용할 지, 자체적으로 만들지 물어볼 수 있습니다. 대부분의 회사는 월간 프로젝트인 경우가 많아 특별한 UI 구성에 대한 예산을 사용하고 싶어하지 않습니다. 그러나 이게 실제 요구사항인 경우도 있었습니다.

개인적인 추천으로, 예산과 요구사항이 있는 고객사를 위해 UI 라이브러리를 만들어 보세요. 리액트 개발자로서 훌륭한 학습 경험이 됩니다. 한 번 수행한 후에는 성과로 어필할 수 있습니다.

UI 라이브러리의 경우, Material UI를 많이 사용합니다. 고객사는 일반적인 라이브러리를 사용하지의 여부를 결정해야합니다. 또한 고객사 개발자가 대부분 주니어라면 Material UI를 사용해봤을 가능성이 높으며, 처음부터 생산성을 발휘할 겁니다. 대조적으로 Chakra UI와 같이 인기없는 라이브러리를 선택한다면 특별한 UI를 만들 수 있지만, 프리랜서로서 새롭게 배워야할 무언가가 생기기도 합니다.

하지만 여기서 커스터마이징으로 끝나지 않습니다. 또 다른 인기있는 주제는 리액트의 차트와 시각화입니다. 고객사가 이러한 차트를 사용하는 경우, 처음부터 커스터마이징을 피하거나, D3같은 저수준의 차트 라이브러리를 사용하거나, 다른 차트 라이브러리를 사용하여 워크로드를 최소화해야합니다.

UI 및 차트 라이브러리이상의 주제로 토론할 수 있는 가능성은 언제나 존재합니다. 일반적으로 "상태관리 라이브러리를 사용하나요?", "데이터(fetch)를 어떻게 가져오나요?", "Typescript를 사용할까요?"와 같은 질문들입니다.

제가 함께 일하고 있는 몇몇 회사들이 비공개 리액트 라이브러리를 가지고 저에게 접근하는 경우도 있습니다. 저는 그들을 이 길에서 벗어나게 하려고 최선을 다합니다. 왜냐하면 폐쇄적인 소스 라이브러리에서 일한 경험이 별로였기 때문입니다. 프리랜서로서 저는 일반적으로 사용되는 오픈 소스 라이브러리에서 일하면서 제 지식을 확장하고 싶었습니다.

 

마지막으로, 모든 개발자들이 중요함을 알고있음에도 불구하고 질문합니다.

얼마나 검사해야 합니까?

테스트를 얼마나 중요하게 생각하는지에 대해 물어봅니다. 하지만, 여러 회사들이 테스트보다 기한 내에 완료하기를 원하고 테스트를 나중으로 생각하는 것을 많이 봐왔습니다. 그래서 이건 여러분이 함께 일하고 있는 고객에게 달려있습니다.

마치며...

프리랜서를 고용하거나, 활동하고자 하는 이들에게 채용/참여를 개선하는데 도움이 되기를 바랍니다.