[번역] 프론트엔드 맥시멀리즘

출처: https://www.natemeyvis.com/front-end-maximalism/

항상 나오는 질문은 같습니다:

Q: 지금 프론트엔드가 백엔드에 요청을 보내서 어떤 일을 처리하고 있는데, 앞으로는 해야 할 일이 더 많아질 수도 있습니다. 이런 상황에서 데이터를 프론트엔드로 보내기 전에 백엔드에서 얼마나 필터링이나 전처리를 해두는 게 좋을까요?

여기서 제 대답은 아래와 같습니다.

A: 가능한 한 적게

몇 예제를 들어보겠습니다:

1. 긴 제품 목록이 있는 제품 페이지가 있다고 가정해보겠습니다. 유저는 한 제품의 상세정보를 보기 위해 선택할 수 있습니다. 먼저 목록을 검색한 다음 선택이 이루어지면 특정 제품의 상세정보를 검색하고 싶을 수 있습니다. 하지만 그것은 전체 제품의 상세 정보를 모두 가져오고, 어떤 상세정보를 보여줄지 결정하는 로컬 상태관리를 사용하여 표시하는게 더 나은 경우가 많습니다.
2. 코치가 선수의 통계를 볼 수 있는 대시보드를 만든다고 가정하겠습니다. 코치는 선수들과 필터를 입력하고 정보를 볼 것입니다. 백엔드에 쿼리를 전달하고 필터링된 데이터를 검색하는 대신 코치가 선수와 쿼리를 입력할 때마다 관련 데이터를 모두 가져와서 업데이트하는 것을 고려하세요.
3. 플래시 카드 사이트를 운영하고 사용자가 학습할 카드의 하위 집합을 선택하도록 한다고 가정해보겠습니다. 현재 학습 선호도를 백엔드에 전달하는 대신에, 사용자 지금 공부할 수 있는 모든 카드를 가져오고 다른 사람이 특이한 요청을 할 때만 데이터를 가져오세요.

대부분의 엔지니어들은 이런 방식으로 접근하지 않을 것입니다. 저는 이것이 주로 심리적, 사회학적 이유 때문이라고 의심합니다. 그저 일이 그렇게 처리되지 않기 때문입니다. 쿼리와 필터링 같은 업무는 백엔드느낌이고 프론트엔드느낌이 들지 않습니다. 프론트엔드로 모든 관련된 데이터를 가져오는 것은 조잡하다고 느낍니다. 그러나 만약 당신이 일하는 엔지니어들에게 시험을 치르고, 백엔드와 프론트엔드를 나누는데 사용하는 원칙에 대해 묻는다면, 다음과 같은 무수한 답변을 얻게 될 것이라고 예상합니다.

1. 시스템의 어떤 부분도 처리할 수 있는 것보다 많은 데이터를 보내지 마세요.
2. 코드 복잡도를 낮춰라
3. 유저 흐름을 최소화 해라
4. 가능하다면 캡슐화하를 유지해라
5. 보안 취약점을 만들지 말아라
6. 그리고 등등..

프론트엔드 맥시멀리즘은 현대적 조건과 광범위한 표준 응용 프로그램에서 이러한 고려 사항을 적용하면 현재 프론트엔드에서 수행하는 작업보다 훨씬 더 많은 작업을 수행하고 백엔드에서는 훨씬 적은 작업을 수행해야 한다는 관점입니다.

프론트엔드 맥시멀리즘 방식을 사용하지 않는 경우

물론 이는 일반적인 관찰일 뿐, 보편적인 관찰은 아닙니다. 백엔드에서 많은 데이터를 수행하는 데에는 두 가지 큰 이유가 있습니다.

첫번째, 때로는 프론트엔드로 전달하기에는 너무 많은 데이터가 있는 경우가 있습니다. 여기서는 물론 백엔드가 필터링, 페이지네이션 등이 필수적으로 필요합니다. 그러나 이것들이 필요하다고 결론 짓기 전에 당신의 일을 먼저 살펴보세요. 동료들이 프론트엔드 맥시멀리즘은 데이터 처리가 너무 어렵다고 말했는지 셀 수가 없습니다. 하지만 데이터는 표준 .jpg 파일보다 작았습니다.

프론트엔드 맥시멀리즘은 확장성을 이유로 거절되기가 쉽습니다:
비록 데이터가 현재는 많지 않더라도, 데이터가 커질 수 있습니다. 이런 주장은 대개 실패합니다. 종종 잠재적으로 관련성 있는 데이터가 많지 않은 경우도 있습니다. 통계 예시에서, 특정 사용자와 관련된 데이터는 미래의 총 플레이어 수와 시스템의 플레이어당 데이터 양을 곱한 값으로 제한됩니다. 때때로 이는 백엔드에서 프런트엔드로 기꺼이 배송할 수 있는 금액보다 훨씬 낮습니다.

더 중요하고, 논란의 여지가 있는 것은, 시스템 맥시멀리즘 접근 방식이 좌절될 것이라고 믿을만한 충분한 이유가 있더라도, 그것은 여전히 프론트엔드 맥시멀리즘이 더 나은 경우가 많습니다. 왜냐하면 Gall's 법칙때문입니다.

제대로 작동하는 복잡한 시스템은 언제나 제대로 작동하는 간단한 시스템에서 진화한 것으로 밝혀졌습니다. 처음부터 설계된 복잡한 시스템은 결코 작동하지 않으며, 작동하도록 패치할 수도 없습니다. 당신은 작동하는 간단한 시스템부터 시작해야합니다.

영원히 작동하지 않을지라도, 지금도 작동하는 경우가 많으며, 지금 바로 작동하게 하는 가장 간단하고 깔끔한 방법입니다. 과소평가된 부분이구요.

프론트엔드 맥시멀리즘이 좌절되는 두 번째 이유는 보안때문입니다. 명백히, 유저에게 필요없는 데이터는 굳이 프론트엔드에 전달할 필요가 없습니다. 전송만 하고 보여주지 않는 것은 나쁜 타협입니다. 데이터는 여전히 전송되고 있고, 공격자 중에는 이를 노릴 수 있다고 생각해야합니다.

상기하세요. 프런트엔드와 백엔드 간의 업무 분할에는 보안상의 균형이 필요합니다. 프론트엔드 맥시멀리즘이 더 안전할 수 있습니다. 백엔드에 점점 더 세분화된 동작을 구축할수록 해당 곳의 공격 표면도 늘어납니다. 예를 들어, 만약 유저가 프론트엔드로부터 데이터를 쿼링한다면, 악의적으로 구성된 필터는 데이터의 다른 하위 집합만 가져올 수 있습니다. 하지만 백엔드에선 그렇지 않습니다. 모든 페이지네이션, 쿼링, 필터링 등이 보안 위험을 가져다줄 수 있습니다.

실제로 당신이 프론트엔드 맥시멀리즘을 구현할 수 있는 다양한 혜택들을 제안하겠습니다:

1. 유저 경험을 향상시킵니다.
2. 페이지네이션, 쿼리, 데이터를 가져오기 위한 기본적은 방법들의 버그를 모두 없앨 수 있습니다.
3. 새로운 기능을 추가하는 비용이 줄어듭니다. 데이터가 이미 프론트엔드에 있다면, 다른 부분을 고려할 필요가 없습니다.
4. API 호출을 제거할 수 있습니다.
5. 개인정보 보호 개선 또는 최소한 사용자 데이터 최소화: 데이터 필터링 및 쿼리가 백엔드에 영향을 미치지 않는 한 백엔드에는 이에 대한 흔적이 없습니다.

몇명의 반대 의견들

1. 당신은 정말 이것에 대해 많은 사람들이 틀렸다고 생각합니까?

제가 들은 대부분의 공통적인 반대의견들입니다: 어떻게 표준 방식이 틀릴 수 있습니까?

첫째, 위에서 암시했듯 기존지 지혜는 일관성이 없습니다. 예를 들어 단순성과 테스트 가능성이 표준 원칙인 경우 프런트엔드와 백엔드 커뮤니케이션의 표준 패턴은 종종 관행을 위반합니다.

둘째, 프런트엔드 맥시멀리즘은 10년 또는 20년 전보다 실행가능했습니다. 저는 기술이 기존의 통념보다 훨씬 빠르게 발전했다고 생각합니다. 불완전하지만 영향력 있는 책을 예시로 보여드리자면 다음과 같습니다.

• 1994: Design Patterns
• 1999: The Pragmatic Programmer
• 2003: Domain-Driven Design
• 2006: Joel on Software (approximate peak influence)
• 2008: Clean Code
• 2018: A Philosophy of Software Design

프런트엔드 맥시멀리즘 접근 방식을 가능하게 하는 중요한 기술의 불완전하지만 가능하게 하는 세트는 다음과 같습니다.

• 2000: Python 2.0
• 2009: py 1.0.0 (now "Pytest")
• 2011: React (first deployment)
• 2012: TypeScript (initial release)
• 2014: Jest (open-sourced)
• 2014: Swift 1.0
• 2024: DuckDB 1.0.0

프런트엔드 맥시멀리즘을 실현할 수 있는 툴이 생기기 오래전 부터 많은 시스템 설계 지침이 문화에 녹아들어 있었습니다.

연결 상태가 좋지 않는 사람들은 어떻게 하나요? 그냥 데이터를 그들에게 던질 것인가요?
다시 말하자면, 프런트엔드 맥시멀리즘 접근 방식으로 유저들에게 너무 많은 데이터를 제공하게 된다면 사용하지 마세요. 그럼에도 불구하고 프런트엔드 극대주의적 접근 방식은 연결 상태가 좋지 않은 사용자에게 더 친화적인 경우가 많습니다. 이러한 연결은 일반적으로 속도가 느릴 뿐만 아니라 안전성도 떨어지며, API 호출을 줄이는 이점은 애초에 적은 양의 데이터를 보내는 것에서 얻을 수 있는 이점보다 더 큰 경우가 많습니다.

대부분의 애플리케이션에서, 프론트엔드 맥시멀리즘은 유저에게 2배에서 10배 정도의 데이터를 던집니다. 이것이 사용자에게 사소하다면, 다른 수단을 통해 페이로드를 줄이는 것이 가능한 경우가 많습니다.

그 외에 아무것도 기억나지 않는다면...

1. 프론트엔드와 백엔드를 그저 관습처럼 책임을 분리하지마세요.
2. 프론트엔드에서 할 수 있는 부분이 과소 평가 되고 있지만, 점점 더 많은 영역이 가능해지고 있습니다.
3. 프론트엔드 맥시멀리즘 접근 방식을 고려하더라도, 결국 어떤 디자인이 되든 더 나은 디자인을 만들어낼 수 있습니다.
4. 모든 코드가 프런트엔드에 있는 경우에도 코드를 적절하게 구조화하면 필요한 모든 모듈성을 얻을 수 있습니다.
5. Gall's 법칙을 잊지마세요.

번역 소감

이 글이 전달하려는 내용을 한 번 고민해봤습니다. 아마 글쓴이는 "최대한 모든 작업을 간단하게 생각하고, 프론트엔드에서 할 수 있다면 프론트에서 해라. 그리고 정말로 프로젝트의 규모가 프론트엔드만으로 감당할 수 없을 때, 백엔드를 활용해라" 라는 의미로 글을 작성한게 아닌가 싶습니다. 위 내용에 대해선 얼핏 이해가 가면서도 어느 부분은 선뜻 동의하기 어려웠습니다. 이런게 어쩌면 트레이드 오프가 아닌가 싶습니다. 이 글을 읽어가면서 이 상황에선 아닌 것 같은데.. 싶으면서도 이 상황에선 어쩌면 맞을지도 라는 생각이 계속해서 드는 글이였습니다. 결국에는 전에 번역한 글에서 처럼 취향으로 갈릴 수 있지 않을까 라는 생각도 듭니다.

가장 제 마음에 와닿았던 부분은 "단순하게 생각해라. Gall's 법칙을 잊지말아라" 였습니다. 2년넘게 개발자로 일하면서 답답했던 부분을 공감해준 글귀였습니다. 초기에 너무나도 복잡하고 어려운 시스템은 시작하기 조차도 힘들었던 경우가 있었거든요. 정작 힘들게 구현해도 대부분의 기능은 사용하지 않곤 했습니다. 아무래도 글쓴이도 이런 경험을 삼아 글을 쓴게 아닐까 싶습니다.

번역글을 읽어주셔서 감사드리며, 앞으로 더 좋은 번역글로 찾아뵙겠습니다. 감사합니다.