엔터프라이즈 애플리케이션 개발,
경영진이 정해야 하는 것
기술 선택처럼 보이지만 실제로는 경영 결정입니다. 무엇을 직접 만들고 무엇을 사올지, 그리고 플랫폼은 무엇을 갖춰야 하는지.
엔터프라이즈 애플리케이션 개발은 기술 부서의 일처럼 보입니다. 그런데 실제로 프로젝트가 어긋나는 지점은 기술이 아닌 경우가 많습니다. 무엇을 직접 만들고 무엇을 사올지, 어떤 플랫폼 위에서 갈지, 누가 무엇을 승인하는지 — 이 결정들이 정리되지 않으면 일정은 밀리고 요구사항은 늘어납니다.
이 글은 그 결정들의 목록입니다. 코드를 쓰는 사람이 아니라 승인하는 사람이 짚어야 할 항목을 정리했습니다.
엔터프라이즈 애플리케이션은 무엇이 다른가
사내 업무 시스템이 일반적인 웹 애플리케이션과 다른 점은 여섯 가지로 정리됩니다. 수천 명이 동시에 쓰고 대량의 데이터와 트랜잭션을 다뤄야 하는 규모, 부서마다 요구가 다르고 다른 시스템과 얽히는 복잡성, 잠깐만 멈춰도 업무가 멈추는 기간계 성격, 기존 IT 환경에 맞추기 위한 커스터마이즈, 규정 준수와 품질을 위한 거버넌스, 그리고 여러 해에 걸쳐 바뀌어 갈 긴 수명입니다.
이 여섯 가지는 각각 비용 항목이기도 합니다. 특히 마지막 항목 — 긴 수명 — 이 사업 검토에서 가장 자주 빠집니다. 첫 출시까지의 비용은 꼼꼼히 따지면서, 그 뒤 5년을 어떻게 끌고 갈지는 계산에 넣지 않습니다.
무엇이 가로막는가
실제로 프로젝트를 막는 것들은 대개 예측 가능한 자리에 있습니다. 기존 시스템과의 연동, 사용자가 늘었을 때의 성능, 보안과 규제 대응, 인력과 예산, 그리고 진행 중에 바뀌는 요구사항입니다.
연동은 특히 그렇습니다. 대부분의 기업이 현대적인 애플리케이션과 함께 돌아가도록 설계되지 않은 레거시를 안고 있습니다. 그래서 우회 방법과 맞춤 코드가 필요해지고, 그것이 다시 유지보수 대상이 됩니다. 보안 쪽도 마찬가지입니다. 사고가 나면 금액이 크고, 그 대비 자체가 개발 과정을 무겁게 만듭니다.
인력입니다. 숙련된 개발자를 확보하기 어려운 상황에서 차별화되지 않는 화면 부품을 직접 만드는 데 인력을 쓰면, 정작 사업에 필요한 기능은 뒤로 밀립니다. 이것은 기술 문제가 아니라 자원 배분 문제입니다.
직접 만들 것인가, 사올 것인가
엔터프라이즈 앱을 만드는 방법은 크게 둘입니다.
직접 개발. 요구사항에 맞춰 처음부터 만듭니다. 업무에 정확히 맞출 수 있고 기술 선택과 아키텍처를 완전히 통제합니다. 대신 비용과 기간이 커질 수 있고, 만든 뒤에는 유지보수와 지원이 계속 따라옵니다.
상용 패키지 도입. 이미 만들어진 기능을 골라 씁니다. 도입이 빠르고 초기 비용이 낮으며 유지보수 부담이 작습니다. 대신 우리 업무 흐름에 맞추려면 손을 봐야 하고, 벤더의 로드맵에 어느 정도 매이게 됩니다.
대다수의 큰 조직은 둘 중 하나를 고르지 않습니다. 가능한 곳은 상용 패키지로 덮고 핵심 영역만 직접 만드는 혼합형으로 갑니다. 유연성과 비용, 일정 사이에서 균형을 잡는 방식이고, 이때 가장 큰 변수는 연동입니다.
플랫폼은 무엇을 갖춰야 하는가
어떤 방식으로 가든 그 위에서 일할 플랫폼을 고르게 됩니다. 검토할 항목은 여덟 가지로 정리됩니다.
플랫폼 검토 항목
- 확장성과 성능 — 사용자와 데이터가 늘어도 견디는가
- 보안 — 암호화, 인증·인가, 업계 표준 대응이 들어 있는가
- 연동 — 기존 시스템·데이터 원본과 붙는가
- 크로스 플랫폼 — 다양한 기기와 브라우저에서 같게 동작하는가
- 분석과 리포팅 — 사용 현황과 성능을 볼 수 있는가
- 문서와 지원 — 문서·예제·커뮤니티가 갖춰져 있는가
- 커스터마이즈 — 우리 업무에 맞게 확장할 여지가 있는가
- 규제 대응 — 해당 산업의 요건을 맞출 수 있는가
이 가운데 문서와 지원 항목은 예전보다 무거워졌습니다. AI 어시스턴트가 코드를 쓰는 비중이 늘면서, 공개된 문서의 품질이 곧 생성되는 코드의 품질이 되기 때문입니다. 문서가 부실한 플랫폼에서는 AI가 없는 API를 지어내거나 낡은 방식을 권합니다.
국내 상황에 대입하면
국내에서는 여기에 두 가지가 더 붙습니다.
첫째는 조달 구조입니다. 공공과 금융권에서는 사업 단위로 발주가 나가고 수행사가 바뀝니다. 그러면 "직접 만들 것인가" 의 주체가 우리가 아니라 그때그때의 수행사가 됩니다. 수행사가 직접 만든 컴포넌트는 사업이 끝나면 유지 주체가 사라집니다. 발주처가 플랫폼을 먼저 정해 두면 그 문제가 상당 부분 없어집니다.
둘째는 망분리입니다. 폐쇄망에서 돌아가야 하는 시스템이라면 패키지 관리자로 의존성을 끌어오는 방식 자체가 제약을 받습니다. 컴포넌트가 한 벌로 묶여 들어오고 버전이 벤더 단위로 관리되는 구조가 이 환경에서는 실질적인 이점이 됩니다.
셋째로, 웹 접근성 인증이 요건에 들어가는 사업이라면 그 대응 수준을 플랫폼 검토 항목에 함께 넣으셔야 합니다. 나중에 붙이면 화면 수만큼 반복 작업이 됩니다.
정리하면
- 엔터프라이즈 앱의 여섯 가지 성격은 그대로 여섯 가지 비용 항목입니다.
- 가장 자주 빠지는 계산은 첫 출시 이후의 수명 비용입니다.
- 직접 개발과 상용 도입은 양자택일이 아니라 혼합이 일반적입니다.
- 플랫폼 검토는 여덟 항목으로 나눠 보면 빠뜨리는 것이 줄어듭니다.
- 국내에서는 조달 구조, 망분리, 접근성 인증이 검토 항목에 추가돼야 합니다.
이 글은 Sencha 백서 C-Level Guide for Enterprise Application Development의 내용을 바탕으로 미래웹 주식회사가 국내 독자를 위해 재구성한 것입니다. 본문의 도식과 통계는 Sencha가 발표한 자료이며 저작권은 Sencha / Idera, Inc. 에 있습니다. 「국내 상황에 대입하면」 항목은 원 자료에 없는 미래웹의 해설입니다.