왜 Ember는 백엔드 엔지니어에게 자연스럽게 느껴지는가

Source: Dev.to

Background

프론트엔드 프레임워크를 배우는 데 큰 어려움을 겪은 적은 없습니다.
하지만 그것들로 안정적인 무언가를 만든다는 느낌을 갖는 데는 어려움이 있었습니다.

대부분은 백엔드 작업을 합니다. 프론트엔드 작업을 할 때면 보통 짧은 기간에—무언가를 만들거나 아이디어를 검증하거나 시스템을 실제로 사용할 수 있게 연결하는—작업합니다. 대부분 혼자서 하는 경우가 많죠. 프론트엔드 작업으로 다시 돌아올 때마다 같은 문제가 반복됩니다:

• 모든 것이 바뀌었다.
• 패턴이 달라졌다.

구현을 시작하기도 전에 다시 환경을 세팅해야 합니다. 그럴 시간은 없습니다.

The Problem with Reinventing Patterns

내가 직접 패턴을 만들거나 빠른 개발 환경을 구축할 수는 있겠지만, 그게 효과가 있는 건 다음에 다시 필요할 때까지뿐입니다—그때쯤이면 기반이 또 바뀌어 있습니다. 이런 끊임없는 재발명 사이클은 생산성을 떨어뜨립니다.

Why Ember Works for Me

Ember를 여러 번 접하고, 내려놓았다가 다시 꺼냈습니다. 매번 약 한 시간 정도면 다시 생산성을 회복합니다. 아무것도 바뀌지 않아서가 아니라 Ember의 진화가 대체가 아니라 논리적인 연속처럼 느껴지기 때문입니다.

• 마지막으로 Ember를 사용했을 때, Ember Data가 사라지고 Warp Drive가 도입될 예정이라는 것을 알았습니다. 대부분의 프론트엔드 생태계라면 이는 빨간불, 즉 근본적인 재학습이 필요하다는 신호가 됩니다. 하지만 Ember에서는 Warp Drive가 다음 논리적인 단계처럼 느껴졌고, 전체 구조를 다시 생각할 필요가 없었습니다.

Ember는 끊임없는 재발명을 최적화하지 않고 연속성을 최적화합니다. 구조가 중요한 시스템에 익숙한 저는 Ember가 처음부터 그 구조를 제공한다는 점이 마음에 듭니다:

• Routing 은 직관적이다
• Services 는 예측 가능하게 동작한다
• 명확한 위치에 파일과 로직을 배치한다

어플리케이션을 어떻게 조직할지 묻지 않으니 큰 안도감을 줍니다. 어디에 무엇을 둘지 고민할 시간이 아니라, 무언가를 만들고 싶습니다.

Consistency Over Flexibility

대부분의 프론트엔드 프레임워크는 유연성을 제공합니다—원하는 대로 구조를 잡을 수 있습니다. 처음엔 좋게 들리지만, 몇 달 뒤에 유지보수하거나, 다시 돌아오거나, 다른 사람에게 넘겨줄 때 문제가 됩니다. 유연성은 현재의 문제를 해결해 주지만, Ember는 일관성을 선택합니다.

완벽하지는 않습니다—Ember Data에도 특이점이 있지만, 그 트레이드오프는 의도된 것입니다. Ember는 모든 것을 다 하려는 것이 아니라, 예측 가능성을 복합적으로 제공합니다. 저는 무엇이든 할 수 있는 프레임워크가 아니라, 올바른 일을 일관되게 할 수 있게 도와주는 프레임워크가 필요합니다. 프로젝트를 시작할 때마다 프론트엔드 아키텍처를 다시 짜고 싶지는 않으며, 기능 구현을 바로 시작하고 싶습니다.

Conclusion

그래서 Ember가 저에게 자연스럽게 느껴지는 것입니다—쉽기 때문이 아니라, 도구와 싸우는 대신 바로 구현에 집중할 수 있게 해 주기 때문입니다.