일반적인 프론트엔드 프로젝트에서 오버엔지니어링 하지 않기

오늘 소개해드리는 이 글은 우리가 일상적으로 만드는 프론트엔드 프로젝트가 어떤 걸 갖추면 좋은지 이야기 합니다. 반대로 어떤 요소들이 오버엔지니어링을 발생시키는지 말해줍니다.

이 글이 좋았던 이유는 여기에서 말하는 대부분의 것들은 생각보다 일정 규모 이상의 조직에서 경험하게 된다는 것입니다. 즉, 제가 경험하고 들어본 대부분의 작은 조직에선 이 글에서 말하는 '갖추면 좋은' 구성도 고려 대상이 아닙니다. 그들 역시 회사를 먹여살리는 일상적인 규모의 프론트엔드 프로젝트를 운영함에도 그렇습니다.

그렇기 때문에 이 글이 눈에 들어왔습니다. 프로젝트를 구성할 때 참고하면 도움이 되지 않을까 합니다.

이 글에서 추천한 몇몇 섹션에 대해 제 생각을 공유하는 걸로 마무리 해보겠습니다 :)

상태 관리

상태 관리가 반드시 필요한가? 라고 하면 고개를 갸우뚱하게 됩니다. 그렇다고 해서 원천적으로 '아니다'라고 하는 건 아닙니다. 이 글에서 말하는 것처럼 애플리케이션이 커지고 복잡도가 올라갈 때 상태관리를 고려하는 건 충분하다고 생각합니다. 물론 불필요한 상황에서 미리 도입하고 보는 건 오버엔지니어링이 될 수 있다고 생각합니다.

기능 플래그

기능 플래그는 새로운 기능을 배포할 때 아주 유용한 도구 입니다. 일정 규모 이상의 앱을 개발한다면 적극적으로 고려해볼만 하다고 생각합니다.

테스트

이 글에서 말하는 것처럼 테스트는 필수입니다. 하지만 어떤 테스트냐에 따라 다를 수 있습니다. 우리 앱의 안정성을 높이는 데 맞는 테스트를 고민해보고 적용하는 과정이 있어야 한다고 생각합니다.

모니터링 (Observability)

모니터링은 고객으로부터 문제를 보고받기 전, 그리고 고객이 느끼지 못하는 잠재적인 문제를 해결할 수 있도록 도와줍니다. 그리고 문제가 발생했을 때 원인 파악을 비교적 정확하게 할 수 있도록 도와줍니다.

접근성

접근성은 앱에서 갖춰야할 가장 중요한 요소 중 하나 입니다. 현재 만들고 있는 앱이 사용자의 접근성을 해치진 않는지 한 번 검토해보는 것도 중요하다고 생각합니다.

DDD, 헥사고날 아키텍처, 마이크로 프론트엔드

모두 오버엔지니어링으로 카테고라이징이 되어 있습니다. 저도 그렇게 생각합니다. 대규모 프로젝트가 아니고서는, 심지어 대규모 프로젝트라고 하더라도 도입은 충분한 고민 후에 그리고 필요에따라, 무엇보다 구성원의 동의와 함께 도입되어야 한다고 생각합니다. 왜냐하면 진입장벽이 존재하고 진입장벽이 존재한다는 사실 자체만으로 앱의 안정성을 해칠 가능성이 있기 때문입니다.

디자인시스템

디자인 시스템은 앱 개발의 생산성을 높여주는 중요한 요소 중 하나 입니다. 하지만 이 글에서 언급한 것처럼 처음부터 발명하고 구현하고 유지보수 하는 건 일정 규모의 조직이 아니고선 생각보다 많은 비용을 발생시키는 오버엔지니어링 입니다. 대신 외부 라이브러리를 가져와 그대로 사용하거나 우리 앱에 맞게 커스터마이징 하는 걸 고려해보는 게 좋다고 생각합니다.