React로 ERP를 만들 때의 장점과 한계 — 화면 단위 전환부터 그리드까지

ERP를 새로 만들거나 오래된 화면을 바꿀 때 프런트엔드로 React를 검토하는 경우가 많습니다. 결론부터 말하면 ERP에 React는 잘 맞습니다. 다만 장점은 “요즘 많이 쓰니까”가 아니라 ERP라는 시스템의 특성에서 나옵니다. 반대로 React를 쓴다고 저절로 해결되지 않는 영역도 분명히 있습니다. 노라가 ERP와 업무 시스템을 구축·운영하며 확인한 내용을 정리합니다.

ERP 화면은 일반 웹 화면과 다르다

장점을 이야기하기 전에 ERP 화면의 성격을 짚어야 합니다. 쇼핑몰이나 홈페이지와 달리 ERP 화면은 이렇습니다.

• 한 화면에 행이 많다. 연간 전표, 거래처 원장, 재고 목록은 수천에서 수만 행입니다. 페이지를 나누면 오히려 업무가 불편해집니다.
• 읽는 화면이 아니라 입력하는 화면이다. 담당자는 셀을 옮겨 다니며 직접 값을 넣습니다. 엑셀에서 쓰던 방식 그대로를 기대합니다.
• 비슷한 화면이 수백 개다. 조회 조건, 목록, 상세, 저장, 권한 체크라는 같은 구조가 모듈마다 반복됩니다.
• 오래 쓴다. 한 번 만들면 5년, 10년 유지보수합니다.

이 네 가지가 기술 선택의 기준이 됩니다.

React의 장점

1. 반복되는 화면을 컴포넌트로 줄인다

ERP에서 가장 큰 비용은 화면 수입니다. 조회 조건 영역, 목록 그리드, 상세 폼, 저장 버튼이라는 구조가 모듈마다 반복되는데, React에서는 이 패턴을 컴포넌트로 만들어 재사용합니다. 화면 하나를 만드는 시간이 줄어드는 것보다, 수백 개 화면의 동작이 같아진다는 점이 더 중요합니다. 저장 확인 메시지나 권한 없는 버튼 처리 방식이 화면마다 다르면 사용자 교육 비용과 버그가 함께 늘어납니다.

2. 화면 단위로 점진적으로 바꿀 수 있다

레거시 ERP를 한 번에 전부 재구축하는 것은 위험이 큽니다. React는 특정 화면만 먼저 교체하고 나머지는 기존 시스템에 두는 방식이 가능합니다. 사용량이 많고 불만이 큰 화면부터 바꾸면서 효과를 확인하고 범위를 넓힐 수 있습니다. 전면 재구축과 단계적 전환 중 무엇을 택할지는 ERP 업그레이드 vs 재구축, 판단 기준 5가지에서 따로 다뤘습니다.

3. 설치 없이 쓰고, 배포가 한 번에 끝난다

설치형 클라이언트는 버전이 다른 PC가 생기는 순간 지원이 어려워집니다. 웹이면 서버에 한 번 배포하면 모두가 같은 버전을 씁니다. 사무실 밖에서, 태블릿에서 결재만 처리하는 식의 사용도 자연스럽게 가능합니다.

4. 사람을 구하기 쉽다

10년 쓸 시스템에서는 개발자를 구할 수 있는지가 기술적 완성도만큼 중요합니다. 특정 벤더의 전용 프레임워크로 만들면 유지보수 인력을 그 생태계 안에서만 찾아야 합니다. React는 인력 풀이 넓어 담당자가 바뀌어도 이어가기 쉽습니다.

5. 복잡한 입력 폼의 상태를 다루기 좋다

ERP 폼은 단순한 입력이 아닙니다. 거래처를 고르면 결제 조건이 바뀌고, 품목을 고르면 단가가 따라오고, 수량을 바꾸면 합계와 세액이 다시 계산됩니다. 값이 바뀔 때 화면이 따라 바뀌는 구조를 다루는 데 React의 방식이 잘 맞습니다.

React만으로는 해결되지 않는 것

여기부터가 실제 구축에서 시간을 가장 많이 쓰는 부분입니다.

과제	왜 어려운가
대량 행 처리	1만 행을 한 화면에 그리면 브라우저가 느려집니다. 화면에 보이는 부분만 그리는 처리가 필요합니다
셀 직접 입력	엑셀처럼 셀을 이동하며 연속 입력하는 동작은 직접 만들면 예외 처리가 끝없이 나옵니다
엑셀 붙여넣기	기존 자료를 옮길 때 가장 많이 요구되지만, 직접 구현하면 서식·줄바꿈 처리에서 막힙니다
계층 구조	계정과목 체계나 품목 구성처럼 펼치고 접는 데이터는 평면 목록과 다루는 방식이 다릅니다
권한과 감사	화면이 아니라 데이터 단위로 보이는 범위를 제어해야 합니다

정리하면 ERP 프런트엔드 작업의 상당 부분은 그리드에 들어갑니다. React를 고른 뒤에도 이 문제는 그대로 남습니다.

ERP에서 React 도입을 검토할 때 실제로 결정해야 할 것은 프레임워크가 아니라 “업무 화면의 그리드를 무엇으로 할 것인가”인 경우가 많습니다.

그리드를 직접 만들지, 가져다 쓸지

직접 만들면 요구사항에 정확히 맞출 수 있지만, 위 표의 과제를 전부 떠안게 되고 그 코드를 10년간 유지보수해야 합니다. 상용 그리드를 쓰면 시간을 아끼는 대신 라이선스 비용과 제품 종속을 감수합니다. 판단 기준은 단순합니다. 그리드가 우리 제품의 차별점인가, 아니면 업무 화면을 만들기 위한 도구인가. 대부분의 ERP에서는 후자입니다.

노라는 이 문제를 직접 겪고 NORA Grid라는 React 데이터 그리드를 만들어 쓰고 있습니다. 1만 행 이상의 데이터 처리, 트리 구조, 드래그 앤 드롭, 셀 직접 입력, 엑셀 붙여넣기를 지원하며, 회계 SaaS 전부(JOUNBOO)와 원온(ONEON) ERP의 실제 업무 화면에서 매일 쓰입니다. 데모용으로 만든 것이 아니라 전표·원장 화면을 만들다가 필요해서 만든 그리드입니다.

정리

• ERP에 React가 맞는 이유는 유행이 아니라 반복되는 화면, 점진적 전환, 배포와 인력 확보 때문입니다.
• 대신 대량 행, 셀 입력, 엑셀 붙여넣기, 계층 구조는 React가 해결해 주지 않습니다. 여기에 들어갈 공수를 처음부터 계획에 넣어야 합니다.
• 그리드를 직접 만들지 가져다 쓸지는 구축 기간과 유지보수 비용을 좌우하는 결정입니다. 기술 검토 단계에서 함께 정하는 것이 좋습니다.

노라는 ERP 구축과 운영을 함께 해온 팀으로, 화면 설계부터 그리드 선택, 기존 시스템 연동까지 같이 검토해 드립니다. ERP 구축·컨설팅에서 제공 범위를 확인하시거나 편하게 문의해 주세요.