프론트엔드

이번 글부터 많은 분들이 주신 피드백을 반영하여 글의 스타일을 변경해 보았습니다. 앞으로도 더 나은 방식으로 도움이 되는 내용을 전달하기 위해 노력하겠습니다. 감사합니다.안녕하세요. 최근에 헤드리스 컴포넌트를 개발하면서, 비즈니스 도메인과 상관없이 재사용 가능하고 유연하게 확장할 수 있는 UI 컴포넌트에 대해 많은 고민을 하고 있는데요. Polymorphic Components(다형성 구성요소)는 호출하는 쪽에서 해당 컴포넌트의 시맨틱 요소를 결정할 수 있게 하는 React 패턴으로, UI 컴포넌트의 재사용성을 높이는 데 매우 유용한 기술이기 때문에 소개해드리고자 합니다. 특히 타입스크립트와 함께 사용하면 안전하고 쉽게 Polymorphic Components를 구축할 수 있어서, 재사용과 확장성이 용이..

프론트엔드가 점점 복잡해지면서 프론트엔드 코드베이스를 아키텍처 수준에서 구조화하고 관리하는 것의 중요성이 점점 높아지고 있다. 필자도 이 주제에 대해 굉장히 오랫동안 고민해 왔는데, 특히 백엔드와 달리 프론트엔드에는 3-계층 아키텍처나 클린 아키텍처와 같은 정형화된 아키텍처가 없었기 때문이다. 물론 프론트엔드와 백엔드는 소프트웨어의 본질적인 내용을 공유하기 때문에, 여러 아키텍처의 핵심 논리를 프론트엔드에도 충분히 적용할 수 있다. 하지만 프론트엔드의 특수성 때문에 백엔드 아키텍처를 그대로 적용하기는 어려울 뿐더러, 비효율적이다. 따라서 핵심 논리를 기반으로 프론트엔드만의, 그리고 해당 프로젝트의 복잡성을 고려한 아키텍처를 구축하는 것이 가장 현실적이고 효율적인 방법일 것이다. 이번 포스팅에서는 필자가 ..

프론트엔드는 애플리케이션에서 클라이언트 단에 위치하며 비즈니스 로직을 포함한 코드 영역을 말하며, 백엔드는 서버 단에 위치한 코드 영역을 의미한다. 이 두 요소는 각각 독립적으로 변경되고 발전하므로, 대다수의 애플리케이션 개발에서는 물리적으로 분리된 각기 다른 코드베이스를 가지는 경우가 많다. 그러나, 많은 애플리케이션들이 서버에서 데이터를 저장하고 클라이언트에서는 데이터를 캐시 하는 구조를 가지고 있기 때문에, 프론트엔드는 애플리케이션의 목표를 달성하기 위해 필연적으로 서버에 의존적일 수밖에 없다. 그리고 이런 의존성은 프론트엔드 개발과 테스트를 어렵게 하며, 변경에 취약하게 만든다. API 명세는 이러한 의존성을 약하게 만드는 방법이다. 하지만 그 자체로는 충분하지 않다. API 명세를 만드는 데에도..

모든 소프트웨어는 비즈니스를 위해 존재한다. 특히, 프론트엔드는 사용자와 가장 밀접하게 연결되어 있으므로, 비즈니스 로직 외에도 비즈니스 관련 요구사항을 처리해야 하는 경우가 많다. 이 중에서 대표적인 것이 바로 로깅이다. 로깅이 필요한 이유는 간단하다. 더 나은 비즈니스 결정을 내리기 위함이다. 비즈니스를 구체화하면서, 추상적인 개념들이 구체화되어 특정 기준을 정해야 하는 경우가 많다. 초기에는 사람의 감각에 의존할 수밖에 없지만, 비즈니스가 계속되면서 감각에만 의존하는 것은 위험성이 매우 크다. 따라서, 의사결정에 도움이 될 데이터를 수집하기 위해 로깅이 필요한 것이다. 따라서 로깅은 직접적인 비즈니스 로직은 아닐지라도, 비즈니스 성공과 직결된 매우 중요한 요소이다. 로깅에는 다양한 종류가 있지만, ..

"프론트엔드에서도 테스트를 해야 하는가?"라는 짧은 질문에 대한 답은 분명하게 "예"이다. 그러나 내 경험에 따르면, 테스트 코드를 작성하는 프론트엔드 개발자는 아직도 소수이다. 내가 진행하는 프로젝트에서는 테스트가 작성되지 않은 코드를 '순살 코드'라고 부른다. 이는 최근 화제가 되었던 철근이 빠진 '순살 아파트'에 비유하여 부르는 말이다. 순살 아파트와 순살 코드의 공통점은 언제 무너져도 이상하지 않다는 것이다. 오직 잘 짜인 테스트 코드 만이 변경으로부터 소프트웨어가 안전하게 원하는 의도대로 동작할 수 있음을 보장할 수 있다. 부끄럽지만 나도 몇 년 전까지는 테스트 코드의 중요성을 잘 알지 못했다. 특히 프론트엔드와는 무관한 이야기라고 생각했다. 하지만 기능이 안전하게 의도대로 작동함을 보장해야 하..