SAP를 공부하다 보면 Fiori라는 단어가 계속 나옵니다. 그런데 막상 “Fiori가 뭐냐”고 물으면 앱이라는 사람도 있고, 디자인이라는 사람도 있고, 개발 프레임워크라는 사람도 있습니다. 다 맞는 말이라서 더 헷갈립니다. 이 글에서는 Fiori의 개념을 교통정리하고, 개발자로서 Fiori 개발을 시작하는 방법까지 정리합니다. 저처럼 기존에 다른 엔터프라이즈 UI 프레임워크(넥사크로, 마이플랫폼 등)로 업무 화면을 만들어온 개발자 관점의 비유도 곁들이겠습니다.
1. Fiori는 정확히 무엇인가
Fiori는 세 가지 층위로 이해하면 깔끔합니다.
- 디자인 시스템으로서의 Fiori: SAP 화면의 표준 사용자 경험(UX) 가이드라인입니다. 예전 SAP GUI의 회색 화면 대신, 모바일에서도 동작하는 단순하고 역할 중심적인 화면을 만들자는 디자인 철학과 규격입니다.
- 제품으로서의 Fiori 앱: 그 디자인으로 SAP가 만들어 제공하는 수천 개의 표준 웹 앱입니다. 어떤 표준 앱이 있는지는 SAP Fiori Apps Reference Library(fioriappslibrary.hana.ondemand.com)에서 검색할 수 있습니다.
- 기술 스택으로서의 Fiori: 이 앱들을 만드는 기술, 즉 SAPUI5(SAP의 JavaScript UI 프레임워크)와 OData(백엔드 통신 프로토콜), 그리고 앱들이 모이는 Fiori Launchpad(런치패드, 일종의 홈 화면)를 묶어 부르는 말입니다.
용어 관계를 한 줄로 정리하면: SAPUI5는 프레임워크, Fiori는 그 위에서 지켜야 할 디자인 표준과 결과물입니다. 넥사크로 개발에 비유하면 SAPUI5가 넥사크로 플랫폼이고, Fiori는 사내 UI/UX 표준 가이드 + 표준 화면 세트에 해당합니다.
2. 사용자 관점: Fiori는 어떻게 쓰는가
개발 전에 사용부터 보면 감이 잡힙니다.
- 사용자는 브라우저로 Fiori Launchpad(FLP) 에 접속합니다. 스마트폰 홈 화면처럼 타일(Tile) 형태로 앱들이 배치되어 있고, 역할(Role)에 따라 보이는 타일이 다릅니다.
- 타일을 누르면 앱이 열립니다. 예를 들어 “Manage Journal Entries”(전표 관리) 앱은 기존 FB03의 Fiori 버전입니다.
- S/4HANA에서는 신규 기능이 GUI 트랜잭션 없이 Fiori 앱으로만 제공되는 경우가 늘고 있어서, 이제 Fiori는 선택이 아니라 기본 화면입니다.
3. 개발 관점: Fiori 앱을 만드는 두 가지 방식
Fiori 개발은 크게 두 갈래입니다. 이 구분이 가장 중요합니다.
방식 ① Fiori Elements (권장 기본값)
코드를 거의 쓰지 않고, 어노테이션(메타데이터)으로 화면을 생성하는 방식입니다. 백엔드의 CDS 뷰에 “이 필드는 목록에 보여라”, “이 필드는 필터로 써라” 같은 UI 어노테이션을 붙이면, 표준 템플릿(List Report, Object Page 등)이 화면을 자동으로 그려줍니다.
- 장점: 개발 속도가 압도적으로 빠르고, SAP 표준 UX가 자동 보장되며, 유지보수가 쉽습니다.
- 단점: 템플릿을 벗어나는 자유로운 화면은 만들기 어렵습니다.
- 지난 글에서 다룬 CDS → RAP으로 이어지는 흐름의 종착지가 바로 Fiori Elements입니다. RAP으로 비즈니스 오브젝트를 만들고 서비스 바인딩에서 미리보기를 누르면 나오는 그 화면이 Fiori Elements입니다. 실기 시험에서 만나는 화면도 이것입니다.
방식 ② Freestyle SAPUI5
JavaScript/XML로 화면을 직접 코딩하는 방식입니다. MVC 구조로 XML 뷰 + JS 컨트롤러를 작성합니다. 자유도가 높아 커스텀 UI가 필요할 때 쓰지만, 개발 공수가 크고 UX 일관성을 스스로 지켜야 합니다.
선택 기준: 업무 화면(목록-상세 조회, 등록/승인)의 80~90%는 Fiori Elements로 충분합니다. SAP의 공식 권고도 “Fiori Elements 우선, 안 되면 Freestyle”입니다. 새로 배운다면 Fiori Elements + 그 기반인 CDS 어노테이션부터 익히는 것이 효율적입니다.
4. 개발 환경 준비
Fiori 개발 도구는 시대에 따라 바뀌어왔는데, 현재 표준은 두 가지입니다. (구글링하면 나오는 SAP Web IDE는 단종된 구세대 도구이니 그 예제는 거르세요.)
- SAP Business Application Studio (BAS): SAP가 제공하는 클라우드 IDE입니다. BTP 트라이얼/Free Tier에 포함되어 있어 별도 설치 없이 브라우저에서 개발할 수 있습니다. 입문자에게 가장 무난합니다.
- VS Code + SAP Fiori Tools 확장: 로컬 VS Code에 SAP 공식 확장(Fiori Tools)을 설치하는 방식입니다. 익숙한 에디터를 쓸 수 있어 현업 개발자들이 선호합니다.
둘 다 핵심 기능은 같습니다: 템플릿 마법사(Application Generator)로 앱 뼈대 생성, OData 서비스 연결, 미리보기 실행, 배포.
5. 첫 Fiori Elements 앱 만들기 (전체 흐름)
BAS 기준으로 List Report 앱을 만드는 흐름은 다음과 같습니다.
- 백엔드 준비: CDS 뷰를 만들고 OData 서비스로 노출합니다 (RAP의 Service Definition + Service Binding, 또는 SEGW). 지난 CDS 글에서 만든 것 같은 뷰가 재료가 됩니다.
- BAS에서 프로젝트 생성: Dev Space 생성(SAP Fiori 유형) → Create Project from Template → SAP Fiori Application 선택
- 템플릿 선택: List Report Page 선택 → 백엔드 시스템과 OData 서비스 선택 → 메인 엔티티 지정
- 미리보기 실행: 생성 직후 npm start(또는 Preview Application)로 브라우저에서 앱이 뜹니다. 이 시점에 이미 검색/필터/목록/정렬이 동작합니다. 코드 한 줄 안 썼는데도요.
- 화면 다듬기: 컬럼 구성, 필터 필드 같은 것은 백엔드 CDS의 @UI 어노테이션(@UI.lineItem, @UI.selectionField 등)으로 제어합니다. 프론트 쪽에서 조정할 것은 Fiori Tools의 Page Map/Page Editor로 GUI 방식으로 편집할 수 있습니다.
- 배포: 완성된 앱은 ABAP 시스템(BSP 앱 형태) 또는 BTP에 배포하고, 런치패드에 타일로 등록합니다.
핵심을 요약하면, Fiori Elements 개발의 무게중심은 프론트가 아니라 백엔드(CDS 어노테이션)에 있습니다. UI 개발이라기보다 “데이터 모델에 화면 정보를 선언하는 일”에 가깝습니다. 프론트 개발자보다 백엔드/ABAP 개발자가 Fiori에 빨리 적응하는 이유입니다.
6. 자주 헷갈리는 것들 정리
- Fiori = SAPUI5? 아닙니다. SAPUI5는 기술, Fiori는 표준/결과물입니다. “Fiori 앱을 SAPUI5로 만든다”가 정확한 문장입니다.
- OpenUI5와 SAPUI5: OpenUI5는 SAPUI5의 오픈소스 버전입니다. 학습용으로 문서/샘플(ui5.sap.com)을 자유롭게 볼 수 있습니다.
- 표준 앱을 쓸까, 만들까: 요구사항이 생기면 먼저 Fiori Apps Library에서 표준 앱이 있는지 확인하는 것이 순서입니다. 표준 앱 + 확장으로 안 될 때 커스텀 개발로 갑니다.
- GUI는 없어지나?: 당장은 아닙니다. 현업에서는 GUI와 Fiori가 오래 공존할 것이고, 다만 신규 개발과 신규 기능의 무게중심이 Fiori로 이동했다는 것이 현재 상황입니다.
마치며
Fiori를 한 문장으로 정리하면 “SAP 화면의 현재이자 미래 표준”입니다. 개발자 입장에서 진입 순서는 명확합니다: CDS 뷰 작성 → @UI 어노테이션 → RAP 서비스 노출 → Fiori Elements로 화면 확인. 앞선 CDS 글, 그리고 예고했던 RAP 글과 이 글이 하나의 파이프라인으로 이어지는 셈입니다. 다음 글에서는 이 흐름을 실제로 관통하는 RAP 실습(RAP100)을 다루겠습니다. 질문은 댓글로 남겨주세요