웹 표준으로 되는데, 왜 여전히 프레임워크를 쓸까요?

핵심 요약

• 웹 표준은 앱을 만드는 데 필요한 기능을 제공하지만, 코드 구조와 협업 규칙까지 정해주지는 않습니다.
• 프레임워크는 화면의 상태 변화를 일관된 방식으로 다루도록 돕습니다.
• 의존성을 줄이면 외부 도구를 관리할 부담은 줄지만, 직접 만든 코드는 계속 관리해야 합니다.
• 도구를 고를 때는 첫 화면을 만드는 속도와 이후 수정에 드는 비용을 함께 따져야 합니다.

브라우저가 직접 처리할 수 있는 일이 많아지면서 “이 정도는 프레임워크 없이 만들면 되지 않을까?”라는 생각도 자연스럽게 듭니다. ‘Use the platform’, 즉 웹 플랫폼이 제공하는 기능을 활용하자는 생각입니다. 다만 팀이 오래 운영할 서비스에 쓸 도구를 고를 때는, 만들 수 있는지만큼 나중에 고치기 쉬운지도 중요합니다.

브라우저는 기능을 주지만, 앱의 설계까지 정해주지는 않습니다

웹 표준은 생각보다 많은 일을 해줍니다. HTML 폼으로는 사용자 입력을 모아 제출할 수 있습니다. 브라우저는 필수 항목을 입력했는지, 이메일 형식이 맞는지 같은 기본 검사도 해줍니다. 자바스크립트의 fetch로 서버에 데이터를 요청할 수도 있습니다.

간단한 문의 페이지라면 이런 기능을 조합하는 것만으로 충분할 수 있습니다. 모든 입력과 클릭을 별도의 라이브러리로 처리할 이유는 없습니다.

하지만 요청한 데이터를 어디에 저장할지는 개발자가 정해야 합니다. 같은 데이터를 여러 화면에서 보여준다면, 언제 함께 갱신할지도 정해야 합니다. 오류 처리 코드를 어느 파일에 둘지도 브라우저가 대신 결정해주지 않습니다.

이것이 기능과 구조의 차이입니다. 브라우저는 화면을 바꾸는 수단을 제공하고, 프레임워크는 그 수단을 반복해서 쓸 때 따를 규칙을 제공합니다.

물론 프레임워크 없이도 좋은 구조를 만들 수 있습니다. 다만 팀이 직접 구조를 설계하고 동료들이 이해할 수 있게 설명해야 합니다. 이후에도 그 구조를 일관되게 유지해야 하고요.

개발 경험의 차이는 두 번째 요구사항부터 드러납니다

설정을 저장하는 화면을 만든다고 해보겠습니다. 처음 요구사항은 단순합니다. 입력창에 값을 넣고 저장 버튼을 누르면 됩니다.

그런데 다음 요구사항이 붙습니다.

• 저장 중에는 버튼을 다시 누를 수 없어야 합니다.
• 실패하면 입력한 내용을 유지하고 오류를 보여줘야 합니다.
• 성공하면 페이지 상단의 사용자 정보도 갱신해야 합니다.

하나씩 보면 특별히 어려운 기능은 아닙니다. 그런데 이 동작들은 서로 맞물려 있습니다.

같은 저장 결과에 맞춰 버튼을 누를 수 있는지 정하고, 오류 메시지와 상단의 사용자 정보도 바꿔야 합니다. 화면을 각각 직접 수정한다면 갱신할 곳을 빠뜨리지 않도록 챙겨야 합니다.

많은 UI 프레임워크에서는 상태를 중심으로 이런 관계를 표현합니다. 상태란 ‘저장 중인지’, ‘오류가 있는지’처럼 화면을 결정하는 데이터입니다. 개발자가 상태에 따라 무엇을 보여줄지 정해두면, 프레임워크는 상태가 바뀔 때 화면도 그에 맞게 바뀌도록 돕습니다.

이 방식도 설계를 잘못하면 복잡해집니다. 서버 데이터를 언제 갱신할지, 동시 요청을 어떻게 처리할지까지 자동으로 해결해주지는 않습니다. 그래도 팀원들이 같은 방식으로 화면 코드를 읽고 수정할 수 있다는 장점은 있습니다.

제가 생각하는 개발 경험도 이쪽에 가깝습니다. 코드 몇 줄을 덜 쓰는 것보다 요구사항이 바뀌었을 때 고칠 곳을 쉽게 찾을 수 있는지가 중요합니다. 동료도 그 수정이 어디에 영향을 주는지 이해할 수 있어야 합니다.

의존성을 없애면, 유지보수 비용은 어디로 갈까요?

프레임워크를 쓰는 데는 분명 비용이 듭니다. 사용법을 배워야 하고, 버전을 올릴 때는 무엇이 바뀌었는지 확인해야 합니다. 함께 쓰는 도구와 잘 맞는지도 살펴야 합니다. 구성에 따라 브라우저가 내려받고 실행하는 자바스크립트의 양도 늘어납니다.

그래서 의존성을 줄이는 것은 충분히 합리적인 선택입니다. 특히 기능이 작고 자주 바뀌지 않는 페이지에서는 도구를 관리하는 일이 더 부담스러울 수 있습니다.

다만 의존성을 줄여도 유지보수할 일은 남습니다.

직접 만든 화면 갱신 코드에도 버그는 생깁니다. 페이지마다 오류 처리 방식이 달라졌다면 언젠가는 정리해야 합니다. 여러 화면에서 재사용하는 코드가 늘어나면, 어떻게 써야 하고 어떤 예외가 있는지 문서로 남길 필요도 생깁니다.

공통 코드가 있다는 이유만으로 “결국 프레임워크를 다시 만들었다”고 단정할 필요는 없습니다. 작은 함수 몇 개로 해결하는 편이 가장 적절할 때도 많습니다. 다만 공통 코드가 앱 전체의 실행 순서와 상태 변경 규칙까지 결정하기 시작한다면, 그 설계를 유지하는 데 드는 비용도 계산해야 합니다.

비용이 드는 시점도 다릅니다. 외부 도구를 관리하는 부담은 버전을 업데이트할 때 눈에 띕니다. 직접 만든 구조를 유지하는 부담은 새로운 동료가 합류하거나 요구사항이 크게 바뀔 때 드러날 수 있습니다.

처음 구현하는 데 걸린 시간만 비교하면 이 차이를 놓치기 쉽습니다.

선택 기준은 팀이 반복해서 해야 할 일입니다

실제로 도구를 고를 때는 ‘웹 표준인가, 프레임워크인가’라는 질문을 조금 더 구체적으로 바꿔볼 필요가 있습니다.

이 조건을 따져본다고 쓸 도구가 저절로 정해지지는 않습니다. 단순해 보이는 화면에도 복잡한 업무 규칙이 숨어 있을 수 있습니다. 반대로 페이지가 많아도 대부분 읽기 전용이라면 복잡한 상태 관리가 필요하지 않을 수 있습니다.

페이지 전체에 프레임워크를 적용해야 하는 것도 아닙니다. 상호작용이 복잡한 일부 영역에만 도입할 수도 있습니다. 이때는 각 영역이 어디까지 맡고 데이터를 어떻게 주고받을지 분명히 정해야 합니다.

프레임워크를 쓰면서도 웹 표준의 기능을 충분히 활용할 수 있습니다. 이동할 때는 링크를 쓰고, 동작을 실행할 때는 버튼을 씁니다. 입력은 폼으로 처리하는 식입니다. 브라우저의 기본 동작을 활용하면 직접 구현하고 검증할 일이 줄어듭니다.

웹 표준이 어떤 기능을 제공하는지 알면 직접 만들어야 할 부분도 더 정확히 고를 수 있습니다. 프레임워크는 그렇게 남은 복잡한 부분을 팀이 일관되게 다루는 데 얼마나 도움이 되는지 따져보면 됩니다. 지금 만드는 서비스에 요구사항이 하나 더 붙었을 때, 다음 담당자가 어디를 고쳐야 할지 쉽게 찾을 수 있는지도 도구를 고르는 기준이 됩니다.