프론트엔드에서 Headless란?

(출처: https://itnext.io/decoupling-ui-and-logic-in-react-a-clean-code-approach-with-headless-components-82e46b5820c)

이런저런 아티클을 읽다보면 자주 마주치는 개념들이 있는데 그 중 하나가 'headless' 입니다. 전 아직도 headless가 무엇인지 헷갈릴 때가 있는데요, 오늘은 headless에 대한 아티클을 공유해보려고 합니다.

Bard의 답변

The word "headless" can have several meanings, depending on the context.

• Without a head. This is the most literal meaning of the word. It can refer to a person or animal that has had its head cut off, or to a device or object that does not have a head. For example, a headless printer is one that does not have a display screen.

• Without a leader or chief. This meaning is more figurative. It can refer to a group or organization that does not have a clear leader or authority figure. For example, a headless company is one that is struggling to find a new CEO after the previous one resigned.

• Foolish or stupid. This meaning is informal and is often used in a humorous way. It can refer to someone who is making a silly mistake or who is not thinking clearly. For example, you might say that someone made a headless argument if they were not making any sense.

In the context of technology, the term "headless" is often used to describe a device or application that does not have a graphical user interface (GUI). This means that it does not have a display screen or any other visual elements. Instead, it is controlled through a command-line interface (CLI) or a web API.

For example, a headless browser is a web browser that does not have a graphical user interface. It is used by developers to test web pages and applications without having to display them on a screen.

I hope this helps! Let me know if you have any other questions.

아래에 소개해드리는 몇몇 아티클을 요약해보면 headless는

"마크업(HTML), 스타일(CSS), 구현 등을 제외한 핵심 로직을 제공하는 라이브러리 또는 유틸리티 입니다."

가장 유명한 Counter 컴포넌트를 예로 들면, 라이브러리에선 숫자를 세는 로직을 분리해서 제공하고 Counter 컴포넌트를 만드는 데 사용하는 HTML, CSS 그리고 갯수를 어떻게 활용할지(구현) 등은 라이브러리 사용자에게 위임하는 것입니다.

반면, Headless Design System은 어떨까요? 프론트엔드 개발을 할 때 '모달'을 가져다 쓴다면 라이브러리나 디자인시스템의 차이를 구분하시나요? 또는 라이브러리를 'headless' 인지 아닌지 구분하시나요? 제가 혼동하던 부분은 이 부분이었던 것 같기도 합니다.

아래 아티클은 Headless Design System에 대해 소개합니다.

On the other hand, the term “headless” refers to an architecture where the front-end and back-end systems operate independently from one another. In this case, a headless design system allows you to use a single design system across multiple applications and platforms while decoupling it from any specific technology, integration, or UI.

"'headless'는 서로 독립적으로 운영하는 프론트엔드 그리고 백엔드 아키텍처를 의미합니다. 이 경우, 'headless' 디자인 시스템은 여러 애플리케이션과 플랫폼 사이에서 특정 기술, 통합 또는 UI로부터 분리해서 디자인시스템을 사용할 수 있도록 합니다."

즉,

"디자인시스템을 사용하려는 환경을 고려하지 않아도 쓸 수 있도록 설계된 디자인시스템을 'headless' 디자인시스템이라고 한다."

입니다.

결국 'headless'란 사용하는 곳의 환경에 의해 쉽게 바뀔 수 있는 부분을 제외한 핵심적인 부분을 의미하는 것 같습니다.

만약 더 구체적인 예제와 이해를 하고 싶다면 위에 소개해드린 아티클들을 참고해주세요 :)

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

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

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

먼저 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

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

좋은 코드 리뷰란?

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

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

가장 먼저 떠오르는 건 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

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

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

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

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

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

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

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

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

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

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