이 글의 목적과 얻어갈 것
SAP Fiori 앱을 만들 때 가장 먼저 부딪히는 갈림길은 "Fiori Elements 템플릿을 쓸 것인가, 아니면 Freestyle UI5로 처음부터 만들 것인가"입니다. 두 방식 모두 SAPUI5 프레임워크 위에서 돌아가지만, 개발 속도·커스터마이징 자유도·유지보수 비용의 균형점이 완전히 다릅니다. 이 글에서는 실제 프로젝트 초반 아키텍처 회의에서 자주 나오는 질문들을 중심으로 두 접근을 비교하고, 어떤 상황에서 어떤 선택이 합리적인지 판단 기준을 제시합니다.
- Fiori Elements와 Freestyle UI5의 근본적 차이를 이해한다
- 메타데이터 기반 UI 생성 방식의 장단점을 파악한다
- 실제 요구사항 유형별로 어떤 방식이 적합한지 판단할 수 있다
- 혼합 전략(Extension, Custom Section) 활용 지점을 안다
- 장기 유지보수 관점의 트레이드오프를 이해한다
미리 알고 있으면 좋은 것
SAPUI5의 기본 MVC 패턴(View/Controller/Model), OData v2 또는 v4 서비스의 기본 개념, 그리고 SAP BAS(Business Application Studio) 또는 VSCode에서 앱을 생성해 본 경험이 있으면 이 글의 내용을 훨씬 빠르게 흡수할 수 있습니다. CAP(Cloud Application Programming Model)이나 RAP(RESTful ABAP Programming) 기반 백엔드를 다뤄본 경험이 있다면 어노테이션 기반 UI 생성의 맥락도 자연스럽게 잡힙니다.
대상 환경과 준비물
이 글에서 다루는 내용은 다음 환경을 전제로 합니다.
- SAPUI5 1.108 LTS 이상 (Fiori Elements v4 기준, OData V4 지원 안정화 버전)
- SAP Business Application Studio 또는 로컬 Node.js 18+ 환경
- @sap/generator-fiori 1.13+ (Fiori 앱 스캐폴딩 도구)
- SAP Fiori Tools VSCode 확장 (Application Modeler, Guided Development 포함)
- 테스트용 CAP 프로젝트 또는 Northwind 같은 공개 OData 서비스
Fiori Elements는 SAPUI5 버전과 강하게 결합되어 있어, 사용 중인 UI5 버전이 지원하는 Floorplan(List Report, Object Page 등)의 기능 범위가 달라질 수 있습니다. 특히 v2 어노테이션 기반과 v4 어노테이션 기반의 문법이 다르므로 프로젝트 시작 전 버전 정책을 확정하는 것이 권장됩니다.
두 접근법의 본질 이해하기
Fiori Elements와 Freestyle UI5의 차이를 이해하는 가장 직관적인 비유는 "조립식 가구와 목공 작업"입니다. Fiori Elements는 IKEA 조립식 가구와 같아서, 정해진 부품과 조립 순서를 따르면 표준화된 결과물이 빠르게 나옵니다. 대신 다리 높이를 5cm 늘리고 싶다면 정해진 확장 지점 안에서만 가능합니다. Freestyle UI5는 목공 작업장으로, 원목과 공구가 주어질 뿐이고 무엇을 만들지는 개발자가 결정합니다. 원하는 모든 것을 만들 수 있지만 그만큼 시간과 숙련도가 필요합니다.
기술적으로 표현하면 Fiori Elements는 "메타데이터 기반 UI 생성(Metadata-driven UI)" 접근입니다. OData 서비스의 $metadata와 어노테이션(예: UI.LineItem, UI.HeaderInfo, UI.FieldGroup)을 읽어들여, 미리 정의된 Floorplan 템플릿이 런타임에 화면을 조립합니다. 개발자는 뷰 XML을 직접 작성하지 않고, 어노테이션을 통해 "어떤 필드를, 어떤 순서로, 어떤 라벨로 보여줄지"를 선언적으로 기술합니다.
Floorplan은 정형화된 화면 패턴을 의미하며 대표적으로 다음과 같은 것들이 있습니다.
- List Report: 검색·필터·테이블 기반의 목록 조회 화면
- Object Page: 단일 엔티티의 상세 정보와 하위 관계를 표시
- Overview Page: 카드 기반 대시보드형 화면
- Analytical List Page: 필터·차트·테이블이 결합된 분석형 화면
반면 Freestyle UI5는 XML View, Controller, Model, Fragment를 개발자가 직접 조합합니다. sap.m, sap.ui.table, sap.f 등의 컨트롤 라이브러리에서 필요한 것을 골라 배치하고, 이벤트 핸들러를 코드로 작성합니다. 결과적으로 UI 구조와 동작 모두 100% 제어 가능하지만, "왜 이 화면이 이렇게 생겼는가"를 관리해야 할 코드의 양이 크게 늘어납니다.
결정적 차이는 업그레이드 시점에 드러납니다. Fiori Elements는 UI5 버전이 올라가면 Floorplan 자체가 개선되어(예: 새로운 필터 UX, 성능 최적화) 사용자가 자동으로 혜택을 봅니다. Freestyle 앱은 명시적으로 재작업하지 않는 한 초기 구현에 머물러 있습니다.
세 단계로 보는 실제 코드 비교
1단계: 가장 단순한 목록 화면 만들기
주문(Order) 목록을 보여주는 화면을 만든다고 가정합시다. Fiori Elements List Report 방식에서는 UI 자체를 코드로 작성하지 않습니다. CAP 프로젝트의 서비스 파일에 어노테이션만 붙이면 됩니다.
// srv/order-service.cds
using { my.sales as db } from '../db/schema';
service OrderService {
entity Orders as projection on db.Orders;
}
annotate OrderService.Orders with @(
UI.HeaderInfo: {
TypeName : 'Order',
TypeNamePlural: 'Orders',
Title : { Value: orderNo }
},
UI.LineItem: [
{ Value: orderNo, Label: 'Order No.' },
{ Value: customerName, Label: 'Customer' },
{ Value: totalAmount, Label: 'Amount' },
{ Value: status, Label: 'Status' }
],
UI.SelectionFields: [ status, customerName ]
);이것으로 검색 필터, 정렬, 페이징, 반응형 테이블이 갖춰진 List Report 화면이 완성됩니다. 뷰 XML은 한 줄도 없습니다.
같은 화면을 Freestyle UI5로 만들면 최소 두 개의 파일이 필요합니다.
<!-- webapp/view/OrderList.view.xml -->
<mvc:View controllerName="my.app.controller.OrderList"
xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m">
<Page title="Orders">
<Table id="orderTable" items="{/Orders}" growing="true">
<columns>
<Column><Text text="Order No."/></Column>
<Column><Text text="Customer"/></Column>
<Column><Text text="Amount"/></Column>
<Column><Text text="Status"/></Column>
</columns>
<items>
<ColumnListItem>
<cells>
<Text text="{orderNo}"/>
<Text text="{customerName}"/>
<ObjectNumber number="{totalAmount}"/>
<ObjectStatus text="{status}"/>
</cells>
</ColumnListItem>
</items>
</Table>
</Page>
</mvc:View>여기에 검색·필터를 추가하려면 FilterBar 컨트롤과 Controller의 이벤트 핸들러를 별도로 작성해야 합니다. 개발 시간은 명확히 Freestyle이 더 오래 걸립니다.
2단계: 실무 요구사항 - 커스텀 액션과 상태 표현
실무에서는 "상태에 따라 행 색상을 다르게" "특정 조건에서만 승인 버튼 노출" 같은 요구가 반드시 나옵니다. Fiori Elements에서는 어노테이션 확장으로 처리합니다.
annotate OrderService.Orders with @(
UI.LineItem: [
{ Value: orderNo, Label: 'Order No.',
Criticality: statusCode }, // 상태값에 따른 색상 자동 매핑
{ Value: totalAmount, Label: 'Amount' },
{ $Type: 'UI.DataFieldForAction',
Action: 'OrderService.approveOrder',
Label : 'Approve' }
]
);
service OrderService {
entity Orders as projection on db.Orders actions {
action approveOrder() returns Orders;
};
}서버 측 핸들러(Node.js/Java 또는 ABAP RAP)에서 approveOrder 로직을 구현하면 UI에 승인 버튼이 자동으로 렌더링되고, 클릭 시 액션이 호출됩니다. Controller 코드를 작성하지 않아도 로딩 인디케이터·에러 메시지·성공 토스트가 표준 동작으로 처리됩니다.
Freestyle에서는 동일한 결과를 위해 다음이 필요합니다.
// webapp/controller/OrderList.controller.js
sap.ui.define([
"sap/ui/core/mvc/Controller",
"sap/m/MessageToast",
"sap/m/MessageBox"
], function (Controller, MessageToast, MessageBox) {
"use strict";
return Controller.extend("my.app.controller.OrderList", {
onApprovePressed: function (oEvent) {
const oCtx = oEvent.getSource().getBindingContext();
const oModel = this.getView().getModel();
const sPath = oCtx.getPath() + "/approveOrder";
this.getView().setBusy(true);
oModel.callFunction(sPath, {
method: "POST",
success: () => {
this.getView().setBusy(false);
MessageToast.show("Approved");
oModel.refresh();
},
error: (err) => {
this.getView().setBusy(false);
MessageBox.error("Approval failed: " + err.message);
}
});
}
});
});버튼 노출 조건 처리, 상태별 색상 계산 함수, formatter까지 하나하나 직접 만들어야 합니다. 자유도는 높지만 코드 양이 늘고 버그 가능성도 커집니다.
3단계: 프로덕션 고려 - 확장 지점과 성능
실제 프로덕션에서는 표준 화면만으로 부족한 부분이 반드시 나옵니다. Fiori Elements는 이를 위해 Flexible Programming Model과 Building Blocks를 제공합니다. Object Page 안에 커스텀 섹션을 삽입하는 예를 봅시다.
<!-- webapp/ext/fragment/CreditHistory.fragment.xml -->
<core:FragmentDefinition
xmlns:core="sap.ui.core"
xmlns:macros="sap.fe.macros"
xmlns="sap.m">
<VBox class="sapUiSmallMargin">
<Title text="Credit History"/>
<macros:Chart
id="creditChart"
metaPath="@com.sap.vocabularies.UI.v1.Chart#Credit"/>
</VBox>
</core:FragmentDefinition>// webapp/manifest.json (일부)
"sap.ui5": {
"routing": {
"targets": {
"OrderObjectPage": {
"options": {
"settings": {
"content": {
"body": {
"sections": {
"creditSection": {
"template": "my.app.ext.fragment.CreditHistory",
"title": "Credit"
}
}
}
}
}
}
}
}
}
}이 방식은 표준 Floorplan의 이점(반응형, 접근성, 업그레이드 자동 반영)을 유지하면서 필요한 부분만 자유롭게 확장할 수 있다는 점에서 실무에서 매우 중요합니다. Freestyle 앱은 처음부터 모든 접근성 속성, 반응형 breakpoint, 다국어 처리를 직접 신경 써야 합니다.
성능 관점에서 Fiori Elements v4는 서버 사이드 페이징, 지연 로딩(lazy loading), $expand 자동 최적화가 내장되어 있습니다. Freestyle 앱은 이를 직접 구현하지 않으면 대용량 데이터에서 성능 문제가 발생하기 쉽습니다.
실수하기 쉬운 지점과 자주 나오는 질문
실제 프로젝트에서 반복적으로 나타나는 오판과 대처법입니다.
Q1. "Fiori Elements는 커스터마이징이 안 된다"는 말이 사실인가요?
부분적으로만 맞습니다. UI 구조 자체를 뒤엎는 커스터마이징은 어렵지만, Extension API·Custom Section·Custom Action·Flexible Column Layout 조정 등 확장 지점은 상당히 넓습니다. "요구사항의 80%가 표준 패턴과 유사한가"를 먼저 점검해야 합니다.
Q2. OData V2와 V4 중 어떤 것을 써야 하나요?
신규 프로젝트라면 V4 Fiori Elements가 일반적으로 권장됩니다. V4는 어노테이션 문법이 더 명확하고 CAP·RAP 백엔드와의 궁합이 좋습니다. 다만 기존 Gateway 서비스가 V2인 경우 V2 Floorplan을 계속 쓰는 것이 마이그레이션 비용 측면에서 합리적입니다.
Q3. 완전히 새로운 UX 패턴을 원하는데 Fiori Elements를 억지로 써야 할까요?
그렇지 않습니다. 예를 들어 지도·간트 차트·드로잉 캔버스 등 표준 Floorplan에 없는 인터랙션이 핵심이라면 Freestyle이 더 적합합니다. 억지로 Elements에 끼워 맞추면 오히려 유지보수 비용이 커집니다.
실전에서 흔한 실수로는 (1) Fiori Elements로 시작해 놓고 어노테이션 대신 뷰 XML을 직접 수정해 업그레이드 호환성을 깨는 것, (2) Freestyle에서 sap.m 컨트롤 대신 임의의 HTML을 남발해 접근성·테마 일관성을 잃는 것, (3) 두 방식을 한 프로젝트에서 무분별하게 섞어 팀 내 코드 스타일이 이원화되는 것 등이 있습니다.
이어서 살펴보면 좋은 주제
두 접근법의 차이를 이해했다면 다음 주제들로 확장해 나가는 것을 추천합니다. Fiori Elements 심화 방향으로는 Flexible Programming Model, Building Blocks(sap.fe.macros), Guided Development 활용법이 있습니다. Freestyle 방향으로는 TypeScript로 UI5 앱을 작성하는 최신 관행, sap.ui.core.routing 심화, OPA5 통합 테스트 작성법이 유용합니다. 백엔드까지 아우르는 관점에서는 CAP 프로젝트에서 어노테이션을 관리하는 전략, RAP의 Behavior Definition과 UI 어노테이션 연결 방식을 익히면 풀스택 관점이 완성됩니다.
더 읽어볼 문서와 링크
댓글 0
아직 댓글이 없습니다.