리액트 컴포넌트를 유연하게 만들기

프론트엔드를 리액트로 개발하다보면 '어떻게 재사용 가능하고 유지보수하기 쉬운 컴포넌트를 만들까?'하는 고민을 늘 하게 되는 것 같습니다.

오늘은 관련된 아티클을 몇 가지 소개해드리려고 합니다 ! 이 아티클들이 컴포넌트를 설계하는 데 도움이 되셨으면 좋겠습니다 !

먼저 Jbee님의 아티클을 소개해드립니다.

컴포넌트의 책임과 역할, 도메인 정보와 결합되지 않는 컴포넌트, 응집도 있는 컴포넌트 등 컴포넌트를 만드는 데 고려하면 좋은 여러 개념을 설명해주고 있습니다.

변경에 유연한 컴포넌트

이번 포스트에서는 변경에 유연하게 대응할 수 있는 컴포넌트에 대해 이야기해보려고 한다 TL;DR 컴포넌트는 데이터를 중심으로 추상화한다. 일반적인 인터페이스로 컴포넌트를 디자인한다. 변경에 유연하다는 것 우리가 작성하는 소프트웨어는 지속가능해야 한다. 클린 코드에 입각하여 코드가 잘 읽히도록 작성하는 것 그 자체가 목적이 되어서는 안 된다. 우리가 작성하는 코드는 예상할 수 없는 변경에 그나마 유연하게 대응할 수 있어야 한다. Why…

https://jbee.io/web/components-should-be-flexible/

그 다음으론 Kent C. Dodds의 제어의 역전과 관련된 아티클입니다.

"Make your abstraction do less stuff, and make your users do that instead"라는 말로 IoC를 설명하고 있는 이 글은 우리가 컴포넌트를 개발하면서 빈번하게 마주하는 케이스를 소개하면서 왜 IoC를 해야하는지 소개하고 있습니다.

Inversion of Control

https://kentcdodds.com/blog/inversion-of-control

관련해서 Compound Component라는 개념을 소개하는 아티클도 공유합니다 :)

React Hooks: Compound Components

https://kentcdodds.com/blog/compound-components-with-react-hooks

그리고 유연한 컴포넌트를 만들기 위해 공식 문서에서 소개하는 '컴포넌트를 props로 전달하기'와 관련된 글도 소개합니다.

Passing Props to a Component – React

The library for web and native user interfaces

https://react.dev/learn/passing-props-to-a-component#passing-jsx-as-children

마지막으로 컴포넌트를 언제 분리하면 좋을지와 관련된 글을 소개합니다.

프론트엔드 아키텍처: 컴포넌트를 분리하는 기준과 방법

컴포넌트를 언제 분리해야 하고 어떻게 분리해야 하는지 살펴봅니다.

https://link.medium.com/IZ7KAjth6Ab

테스트코드 문화... 이게 되네?

오늘 개발 책을 읽고 얘기 나누는 모임에 갔는데 어떤 분이 테스트 코드를 실무에서 쓰고 싶고 도입하고 싶은데 귀찮기도 하고 도입할 자신이 없다고 하셨어요. 그래서 제가 테스트 코드 문화를 결국에 도입한 경험을 들려드렸어요.

입사 초반에 gtm(google tag manager) event를 trigger하는 로직들을 테스트 자동화 해놓으면 어떤 event가 trigger되지 않을 때 미리 알아차릴 수 있지 않을까 하는 발상이 테스트 코드에 관심을 가지게 했던 순간이었는데요. 테스트 코드를 막 짜보다가 업무가 바빠서 손을 놓고 있다가 여유가 생기면 다시 짜보는 루틴의 반복이었어요. 그렇게 계속해서 테스트 코드를 짜고, CI도 붙여보고, 좋은 점도 정리해보고 하다보니까 팀원분들도 관심을 가지기 시작하더라구요. 대체 저게 얼마나 좋길래 저 사람은 계속 테스트 코드를 고집하는 걸까 하는 생각이 들게 하지 않았나 싶은데요. 팀원분들도 하나씩 테스트 코드를 작성해서 올려주시니까 테스트 케이스들이 점점 쌓이고 테스트 코드의 든든함을 함께 느끼고, 테스트 코드를 기반으로 리팩토링도 해보면서 문화가 슬그머니 자리잡고 있는 거 같아서 뿌듯했어요.

모임에서 만났던 분은 내일 출근해서 테스트 코드부터 작성해보겠다고 모임에서 공개적으로 다짐하셨는데 포기하지 않고 꾸준히 하셨음 좋겠고 잘되서 나중에 만났을 때 후기 들려주셨으면 좋겠다는 생각이 드네요. ☺️

문화를 도입하는건 정말 어려운 거 같아요. 문화가 지속되려면 그 가치를 입증해야 되고, 구성원들이 가치에 동의해야 하며, 유지되게 하는 동력을 만들어야 하는 거 같아요. 저는 제 자리에서 꺾이지 않고 묵묵히 시도했던 게 결국에는 성과가 난 거 같아요.

제 경험에 대해서 궁금하신 점이나 비슷한 경험을 하셨던 분들은 댓글로 남겨주시면 더 풍부한 글로 남을 거 같아요. 읽어주셔서 감사합니다 ☺️

CSS 애니메이션 성능 모니터링 - transform vs position

프론트엔드의 UI를 구성하다보면 선택을 해야할 때가 있습니다. 대표적인게 transform을 쓸 것인지 아니면 positon을 사용할 것인지 입니다. 대상을 움직일 때 자주 사용되지만 어떤게 더 나은 선택인지 판단하기 어려울 때가 있는데요, 이 아티클이 도움이 될거 같습니다.

오래된 글이긴하지만 궁금한게 생길때 깊게 파고드는 것의 매력을 잘 보여준 글이라고 생각합니다.

이 글에선 CPU, GPU, Composite Layer, Performance 등의 키워드가 등장합니다. 길지 않은 글이고 이해하기 쉽게 적혀있어서 좋았던거 같아요 :)

Performance monitoring in CSS animations

Animation using JavaScript ? or Animation using CSS?

https://medium.com/chegg/performance-monitoring-in-css-animations-f11a21d0054f

Next.js Docs 한글화 작업의 컨트리뷰터를 모집합니다!

안녕하세요. 그랜터에서 프론트앤드 개발을 맡고있는 윤창현 입니다.

최근 저는 React Docs 한글화 작업에 참여한 적이 있습니다.

한국에서 대부분의 웹 프론트앤드 개발자들이 React를 사용하고 있고 그중 다수가 Next.js를 사용하고 있습니다.

React의 Docs는 이전부터 한글화 작업이 잘 되어 있었으나

Next.js의 경우 영어를 제외한 다른 언어의 문서가 제공되고 있지 않습니다.

현재 Vercel에 공식적으로 한국어 문서 작업에 대해 요청해둔 상태이며 vercel docs팀에 전달 된 상태입니다.

Vercel의 승인을 떠나 한국인들을 위한 Next.js 한국어 문서 작업을 진행하려고 합니다.

Next.js의 경우 최근 13.x에서 app_dir 기능이 생기며 Pages, App 각각 문서가 존재하고 docs의 양이 너무 방대하여 혼자 작업하기엔 매우 무리인 상태입니다.

이대로 혼자 작업하면 하다가 새로운 버전이 나오겠죠...

Docs 번역 작업의 목표는

1. 한국인들을 위한 Next.js Docs 제공
2. 번역 작업을 하며 Next.js Docs 다시 정독해보기

입니다.

작업을 같이 진행하고싶은 분들은

https://github.com/Nextjs-kr/Nextjs.ko/issues/1

에서 댓글 남겨주시면 할당 해드리겠습니다!

많은 관심 및 공유 부탁드립니다 :)

좋은 코드 리뷰란?

좋은 코드 리뷰 또는 문화란 어떤 걸까요? 코드리뷰를 매일 하고 있지만 항상 어려운 것 같습니다. 관련된 문화가 잘 잡혀있다면 다행이지만, 그렇지 않다면 어떻게 코드리뷰를 주고 받아야 할지 정하는 과정이 생각보다 쉽지 않다는 걸 알게 됩니다. 왜냐하면 어떤 방법이 더 좋은지, 어떻게 해야할지, 우리는 어떤 성향을 가진 구성원이고 조직인지 너무 모호한 질문들이 많기 때문입니다. 이럴 땐 시도해보고 돌아보고 개선하는 과정을 필연적으로 경험할 수 밖에 없는 것 같습니다.

그래서 오늘은 코드리뷰와 관련된 아티클을 몇 개 가져와봤습니다. 그리고 제게 도움이 됐던 몇 가지를 요약하려고 합니다. 시간이 되신다면 하나하나 읽어보는 것도 추천드립니다 ! 그리고 여러분의 의견, 봤던 좋은 아티클들을 소개해주시면 좋을거 같아요 :)

가장 먼저 떠오르는 건 Pn 문화 입니다. 반영해야 하는 우선순위에 따라 P1 부터 P5까지 있습니다. 만약 반드시 반영해야 하는 이슈가 있다면 P1을, 단순한 의견을 전달하는 거라면 P5를 리뷰 앞에 달아줍니다.

리뷰를 할 때면 내 피드백의 중요성에 대해 또는 상대 피드백의 중요성에 대해 언급하는 게 큰 비용처럼 느껴질 때가 있는데 이 방법이 그런 비용을 줄여줍니다.

그 밖에도 리뷰 요청 코드의 라인수(LoC), 설명엔 어떤 걸 적어야 하는지, 리뷰 우선순위 등 좋은 정보를 많이 담고 있습니다.

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

안녕하세요, 뱅크샐러드 BanksaladX iOS Engineer…

https://blog.banksalad.com/tech/banksalad-code-review-culture/

아래 글에서도 이상적인 PR의 라인수(250라인 이하)와 '하나의 PR은 한 가지 문제를 해결한다' 등과 같은 원칙들을 소개합니다. 특히 PR 템플릿을 소개하는 점이 좋았습니다. 과한 측면이 없지 않아 있지만 그렇기에 더 좋았습니다. 왜냐하면 구성원과 조직의 상황에 맞게 참고할 수 있기 때문입니다.

그리고 리뷰어를 위한 체크리스트가 있고, 이 리스트는 특정 PR이 아니라 모든 PR에서 지켜야 하는 체크리스트를 담고 있어서 참고할만 했습니다.

Building a scalable PR review process.

Motivation and Background

https://medium.com/@Games24x7Tech/building-a-scalable-pr-review-process-b0c8ef8dbea0

그리고 아래 글은 다양한 통계와 요약을 담고 있어서 좋다고 생각합니다. 종종 참고합니다.

Pull requestの理想的なサイズとその理由

https://zenn.dev/isana/articles/ideal-size-of-pull-request-and-why

마지막으로 소개해드리는 글은 좋은 코드 리뷰 문화를 갖고 있는지 측정하는 방법들을 소개합니다. 이 글이 특히 좋은 이유는 측정 방법을 소개하는 과정에서 많은 인사이트를 얻을 수 있기 때문입니다. 그리고 이 글의 시작 부분이 인상적입니다.

Just as we track bugs & rate complexity in our CI, or produce Wealth Analytics for our clients to help answer questions about risk, scenarios, or cash flows, we can do the same to track several indicators about our PR culture.

목차를 간략하게 소개해드리면

1. PR을 했을 때 첫 응답까지 시간이 얼마나 걸리는지
2. PR 상호작용의 품질이란?
3. 팀원 중 특정 구성원만 피드백을 주고받진 않는지?
4. end-to-end로 PR과 반영이 얼마나 걸리는지

Developer Engagement One Code Review at a Time

Li shares his view on ‘healthy code review culture’. He describes how this is done on his team using metrics.

https://medium.com/blackrock-engineering/developer-engagement-one-code-review-at-a-time-e01fe5cfc36b

CSS의 적절한 사용이란?

이런저런 아티클을 읽다보면 가끔 좋은 글들을 발견하곤 하는데요, 그런 글이 있다면 공유할 수 있도록 하겠습니다 !

이번에 공유하려고 하는 아티클은 'atomic CSS의 깨어진 약속'이라는 아티클입니다. 주요 내용은 atomic CSS에 대한 비판이지만 사실 조금 더 광범위한 내용이 담겨있습니다. 아래에 요약을 적어둘텐데요, HTML과 CSS를 사용하시는 데 있어서 한 번쯤 고민해보시면 좋겠습니다.

1. 페이지를 구성하는 데 HTML과 CSS의 역할 - 의미론적 문서 구조와 표현
2. 이러한 분리를 달성하기 위해 CSS는 HTML의 수정하지 않는 요소와 요소의 집합을 설명하는 풍부한 문법을 제공합니다. 이건 HTML 문서를 변경하지 않고 CSS 파일만 바꿈으로써 완전히 다른 모습의 문서를 보여 줄 수 있다는 걸 의미합니다.
3. 클래스 기반 CSS는 클래스를 요소 선언의 라벨로 사용합니다. 이건 객체지향의 상속처럼 스타일을 재사용하도록 합니다. (조금 어렵게 다가올 수 있지만, HTML과 CSS의 결합을 의미합니다.) 그리고 이건 많은 문제를 일으킵니다.
4. 이 문제들을 해결하기 위해 BEM, atomic CSS 등이 등장합니다. 그리고 컴포넌트 기반 코드에서 CSS 모듈과 CSS-in-JS 등과 같은 scoped CSS가 등장합니다. 모두 클래스 기반 CSS 입니다.
5. 클래스 기반 CSS는 HTML과 CSS의 강한 결합을 유도합니다.

아주 간단한 예시도 나오는데, 한 번 살펴보는 것도 정말 좋을거 같습니다 :)

많은 의견 환영입니다 :)

The broken promise of atomic CSS

The (not so) hidden cost of atomic CSS

https://medium.com/@hayavuk/the-broken-promise-of-atomic-css-4d3de5e25886

지금 조직에서 업무 프로세스가 어떻게 되나요?

얼마전 커뮤니티의 방향성에 대한 내용 중 '회사 규모에 따른 업무 프로세스의 차이점'에 대한 글이 있었습니다. 그리고 이 내용이 이곳에서 활발하게 다루어지면 좋겠다고 생각했습니다.

면접을 보러 이곳저곳을 다니다보면 제목과 같은 질문을 받을 때가 종종 있습니다.

'지금 조직에서 업무 프로세스가 어떻게 되나요?'

기술과 관련된 질문이나 프로젝트 경험에 대한 질문이면 부족했어도 채울만한 방법이 있기마련인데, 이 질문에 대한 준비는 막막하게 다가왔던 기억이 납니다. 지금 몸담고 있는 조직의 업무 프로세스가 어떻다는 건 알지만, 어떤 모습이 되어야 하는지, 그때 내 역할은 어때야 하는지 등등 참고할만한 정보가 많이 없기 때문입니다. 특히 잘 만들기 위해 기술이 중요하다는 건 알지만 '업무 프로세스도 중요한가?'에 대해 의문을 가질 수도 있습니다.

그리고 업무 프로세스가 조직 규모별로 차이가 있을까? 하는 궁금증이 생길 수 있습니다. 전 프론트엔드 개발자가 없는 조직에서 풀스택 개발자로 일해보고, 프론트엔드 개발자가 있는 소규모 조직, 중간규모 조직에서 일을 해봤습니다. 그리고 이런 차이들이 있었습니다.

1. 업무 또는 작업이 전달되는 방식
2. Waterfall과 Agile 등의 작업 진행 방식
3. 포지션별 소통 방법
4. 정규 작업 및 끼어드는 업무 처리 방식
5. 제품 테스트 방법
6. 브랜치 전략
7. 회고

등

이런 방법들 중 조직 규모와 무관하게 항상 필요한 프로세스 또는 방법이 있을까요? 그리고 조직 규모별로 적절한 방법도 있을까요?

요약

• 조직 규모별 좋은 업무 프로세스는 어떤 모습일까요?
• 어떤 프로세스 또는 방법이 지금 조직에 필요하거나 또는 효과적이었나요?
• 조직 규모와 무관하게 중요한 프로세스가 있을까요?
• 업무 프로세스는 좋은 제품을 만들기 위해 얼만큼 중요할까요? 또는 중요성이 체감되지 않을 수 있을까요?

많은 의견 주시면 감사하겠습니다 ! 저도 적극적으로 대화를 나눠볼게요 :)

만들고 싶은 커뮤니티의 모습이 있나요? | Disquiet*

안녕하세요 준프입니다 :)이러저러한 경로로 이곳에 오셨을 텐데요, 여러분이 기대하는 또는 만들고 싶은 커뮤니티의 모습이 있나요? 의견을 주시면 그런 공간이 되도록 한 구성원으로서 노력해보려고 합니다 !전 프론트엔드와 관련된 지식, 경험이 공유되고 논의되는 곳이면 좋겠다...

https://disquiet.io/@junep/makerlog/9866?utm_source=user_shared

Next.js 13을 쓰고 계신가요?

Next.js 13이 공개된지도 벌써 8개월이라는 시간이 지났는데요, 프론트엔드 개발자들 클럽 멤버분들은 Next.js 13, 그리고 App Directory 컨벤션을 쓰고 계신지 궁금해요.

Next.js 13

Next.js 13 introduces layouts, React Server Components, and streaming in the app directory, as well as Turbopack, an improved image component, and the brand new font component.

https://nextjs.org/blog/next-13

돌이켜보는 Next.js 13의 기능들

1. app/ 디렉토리 (베타): 더 간편하고, 더욱 빠르며, 클라이언트 JS 사용량도 줄여줍니다. 레이아웃 기능 / 리액트 서버 컴포넌트 지원 /스트리밍 기능 등을 포함합니다.
2. Turbopack (알파): 웹팩을 대체할 수 있는 Rust 기반 툴로, 웹팩보다 최대 700배 더 빠릅니다.
3. 새로운 next/image (안정화): 웹 브라우저의 기본 지연 로딩 기능을 통해 이미지 로딩 속도가 개선되었습니다.
4. 새로운 @next/font (베타): 레이아웃 이동 없이, 자체 호스팅 방식으로 구글 폰트를 쉽게 사용할 수 있습니다.
5. 개선된 next/link: API가 단순화되었으며, 자동으로 <a> 태그를 생성합니다.

저희 같은 경우 제품 웹 앱이 클라이언트 사이드 렌더링 기반의 React App이고, 백엔드 서버가 따로 존재해 아직까지 Next.js를 완전히 도입하지는 못했는데요, 마음 한 켠에는 유저가 체감하는 속도 측면에서나 내부적인 개발 편의성이 개선되지 않을까하는 생각이 있어요.

개인적으로 만들었던 여러 제품에서도 Next.js 12, 13을 활용했다보니 개발 편의성이 확실히 좋은 것 같다, 이런 생각도 있고요.

하지만 작업 공수 측면에서 이 Migration이 제품이 제공하게 될 유저 가치 측면에서 충분히 효과적인지는 아직까지 판단이 안됐어요. 아마 그렇게까지는 효과적이지 않을 것이다, 라는 게 현재까지의 결론인데요.

혹시 클라이언트 사이드 렌더링 -> 서버사이드 렌더링으로 이전해본 경험이 있으신지, 만약 있다면 작업 만큼의 효과가 있었는지. 그리고 Next.js을 사용해보셨다면 App Directory로 이전하면서 겪은 어려움은 있으신지 궁금해요.

아니면 아예 Next.js 자체를 사용하고 있지 않은지도 궁금해요!

클럽 운영 방법에 대해 고민중입니다 :)

1. 모든 구성원이 자유롭게 참여할 수 있고
2. 개발자들에겐 성장의 기회를
3. 개발자가 아닌 분들에게는 정보를

제공할 수 있는 방법을 고민중입니다. 그리고 기회가 된다면 종종 직접적인 커뮤니케이션을 할 수 있으면 좋겠다는 생각도 하고 있습니다. 아래에 올려놓은 글에 댓글로 어떤 부분에 관심있는지 적어주시면 큰 도움이 될거 같습니다.

부족한 점이 있더라도 6월 11일 또는 12일에 운영 초안을 공유할 수 있도록 하겠습니다.

그리고 운영 방식에 대해 좋은 아이디어가 있으시다면 댓글 달아주세요 :)

프론트엔드 개발을 처음 배울 때 어떤 방법 / 리소스를 참고하셨나요?

저는 작년 8월에 창업을 하기 위해선 프론트엔드 개발을 배워야 해!라는 생각을 해서 프론트엔드 개발을 본격적으로 배웠었어요.

예전에 저는 주로 Python 언어로 데이터 분석이나 머신러닝 코드를 짜는 일에 익숙했는데, 프론트엔드는 처음부터 모르는 것 투성이더라구요.

벨로퍼트와 함께하는 모던 리액트 · GitBook

https://react.vlpt.us/

'벨로퍼트와 함께하는 모던 리액트'라는 강의 문서를 참고해서 TodoApp을 만들고, 그 다음부터는 원하는 것들을 조금씩 조금씩 만들어보면서 저만의 코딩 방식을 터득했던 것 같아요.

TIL - 낙관적인 UI | Disquiet*

로컬 데이터를 먼저 변조하고 서버에 요청을 보내는 방식프론트엔드 개발을 하다보면 언제나, 서버 데이터와 로컬 데이터의 상태가 일치해야 하는 상황 속에서 문제를 겪게 된다.낙관적 UI란, 서버에 로컬 데이터를 동기화하기 전에 먼저 로컬의 변경사항을 UI 상에 렌더링하고,...

https://disquiet.io/@luckydaun/makerlog/2359

이런 식으로 학습한 내용을 정리해보기도 했던 것 같아요.

프론트엔드 개발자 클럽 멤버분들은 프론트엔드를 어떻게 처음 배우셨나요?

만들고 싶은 커뮤니티의 모습이 있나요?

안녕하세요 준프입니다 :)

이러저러한 경로로 이곳에 오셨을 텐데요, 여러분이 기대하는 또는 만들고 싶은 커뮤니티의 모습이 있나요? 의견을 주시면 그런 공간이 되도록 한 구성원으로서 노력해보려고 합니다 !

전 프론트엔드와 관련된 지식, 경험이 공유되고 논의되는 곳이면 좋겠다는 생각을 했어요. 프론트엔드 개발자이기에 경험하는 업무 프로세스 그리고 개발 문화, 프론트엔드 개발을 하며 경험하는 기술과 좋은 코드의 기준, 좋은 프론트엔드 개발자가 되기위한 시도 등을 너무 쉽지 않게 그리고 너무 어렵지 않게 나누는 곳이 되면 좋겠습니다.

이건 제 의견입니다 ! 여러분의 아이디어, 의견이 있다면 공유해주세요 :)

프론트엔드 엔지니어링의 예술: The art of Frontend Engineering 읽기

프론트엔드 개발을 함께 배우고 얘기 나눠보고 싶어서 프론트엔드 개발자 클럽을 만들어보았어요 :) 같이 프론트엔드 개발 공부하고 이야기 나눠보아요.

프론트엔드 개발이나, 좋은 코드를 작성하는 방법, 좋은 사용자 경험을 제공하는 방법, 개발자로서 일을 잘하는 방법 등등에 대해서 이야기 나누고 학습하면 좋을 것 같아요.

프론트엔드 엔지니어링의 예술: The art of Frontend Engineering 같이 읽기

The art of Frontend Engineering

As the web continues to expand how does Frontend Engineering fit into this landscape and what makes a Frontend Engineer great?

https://www.narative.co/articles/the-art-of-frontend-engineering/

By Dennis Brotzky, Engineer

"웹이 계속 확장되면서 우리가 업무와 여가를 위해 사용하는 도구는 브라우저의 URL과 동의어가 되었습니다. 최고의 디자인과 개발이 결합된 애플리케이션에 대한 요구가 그 어느 때보다 높습니다."

: 정말 맞는 말 같다. 

"프론트엔드 엔지니어는 이러한 요소들을 한데 모아 모든 상호 작용에 만족감을 주는 인터페이스를 만듭니다. 그렇다면 훌륭한 프론트엔드 엔지니어는 무엇이며 왜 그렇게 특별한 것일까요?" 

"프론트엔드는 HTML, CSS, 자바스크립트의 아름다운 조합으로 디자인에 생명을 불어넣는 곳입니다. 어떤 사람들에게는 뒷전일 수도 있습니다. 다른 사람에게는 쉬운 일로 보일 수도 있습니다. " 

"하지만 프론트엔드 엔지니어가 된다는 것은 사용자가 웹을 탐색할 때마다 느끼는 결과물을 책임져야 하는 막중한 책임을 지는 것을 의미합니다." 

"도전과제가 없는 것은 아닙니다. 사용자 인터페이스는 상태, 성능, 디바이스 호환성, 브라우저 호환성 및 API를 관리해야 하는 피할 수 없는 고충을 의미합니다. 지금 작동하는 것이 나중에 고장날 가능성이 높다는 것을 알기 때문에" 

"다른 브라우저를 열거나 새 기기를 가져와 테스트하는 것을 두려워하는 경우가 종종 있습니다."

: 오... 다들 하는 생각이구나. 

"하지만 이 모든 고통에 보상이 따릅니다. UI가 처음으로 렌더링되고 정적인 디자인이 모든 사람이 상호 작용할 수 있는 실체적인 것으로 바뀔 때 - 마법 같은 순간이 항상 있습니다. 아이디어가 실현되고 데이터의 일관성이 확보되는 순간입니다." 

"프론트엔드 엔지니어링이 특별한 이유는 디자인과 엔지니어링이 겹쳐서 인터페이스를 만드는 곳이기 때문입니다. 우리가 만드는 인터랙션이 사용자에게 어떤 느낌을 줄 수 있는지," 

"모든 것이 매끄럽게 느껴지도록 하기 위해 땀을 흘리는 세부 사항, 심지어 이러한 것들이 어떻게 결합되어 방어 가능한 브랜드를 구축할 수 있는지에는 마법이 있습니다."

방어 가능한 브랜드를 만드는 프론트엔드. 

잘하는 프론트 엔지니어들은 디테일에 땀을 흘리고, 한계를 뛰어넘으며, 끊임없이 배웁니다.

이들은 매일 사용하는 도구에 대한 깊은 이해가 있습니다. 프레임워크를 기본으로 사용하지만, 기본 작업을 만드는 자바스크립트도 잘 이해하고 있습니다. 

"유창한 언어처럼 CSS를 활용하고 DOM 요소를 마음대로 조작합니다. 이들은 Stackoverflow 답변에서 가져온 수수께끼 같은 개념이 아니라 브라우저 API를 프로세스의 기초로 간주합니다.

이러한 기본 사항은 클라이언트에서 작업하는 모든 사람의 기준이 됩니다." 

"하지만 저는 눈에 보이는 것 너머의 모든 것, 모든 것을 특별하게 느끼게 하는 사소한 것, 심지어 마법 같은 것까지 더 많은 것이 있다고 믿습니다." 

클라이언트 그 너머

곧 알게 되겠지만, 클라이언트는 그 클라이언트를 구동하는 API만큼만 우수하다는 것을 알게 될 것입니다. 백엔드는 인터페이스 성공의 큰 부분을 차지합니다. 클라이언트는 많은 것을 달성할 수 있는 데 한계가 있으므로  API를 정의하고 데이터베이스에서 데이터가 어떻게 흐르는지 이해하는 것이 중요하며, 이를 통해 엔지니어링의 세계를 열 수 있습니다.

필요한 API를 설계하고 구현까지 할 수 있다면 주변 엔지니어의 프로세스를 간소화할 수 있습니다. 

클라이언트를 넘어선 부분까지 파악할 수 있으면 자연스럽게 모든 업무가 개선됩니다.

디자인은 모든 것입니다. 인터페이스를 구축하려면 디자인이 무엇이고 왜 중요한지 이해해야 합니다. 엔지니어링과 마찬가지로 디자인과 그 원리에는 실제 구조가 있습니다. 

훌륭한 프론트엔드 엔지니어는 이러한 매개변수를 이해하고 이를 작업에 적용합니다.

목표는 디자이너가 자신의 비전을 존중하고 디자인 논리에 기반한 피드백을 제공한다는 것을 알기 때문에 함께 일하고 싶어하는 것이어야 합니다. 

이러한 원칙을 이해한다면 자신의 아이디어를 존중받는 방식으로 전달할 수 있습니다.

저는 세계 최고의 디자이너는 모든 프로젝트에서 병행 작업을 하는 사람, 즉 각 측면을 깊이 존중하고 이해하는 사람이라고 생각합니다. 결국 프론트엔드 엔지니어링은 디자인의 연장선상에 있습니다.