이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
CDS View를 사용한 데이터 모델링에서 가장 중요하게 생각한 것은 레이어 구조였습니다. 기본 인터페이스 뷰, 재정의 뷰, 소비 뷰 순으로 계층을 나누면 각 레이어가 명확한 역할을 갖고, 변경이 필요할 때 영향 범위가 좁아집니다.
Association 정의도 재사용성에 영향을 줬습니다. 자주 함께 조회되는 마스터 데이터를 Association으로 연결해두면 소비 뷰에서 필요한 때만 활성화할 수 있고, 불필요한 조인 없이 성능을 유지하면서 유연하게 사용할 수 있었습니다.
Annotation 관리도 중요했습니다. UI 메타데이터, 시맨틱 정보, 권한 검사를 Annotation으로 표현하면 ABAP 코드 없이도 많은 동작을 제어할 수 있었습니다. 선언적 방식이라 유지보수가 수월하고 SAP Fiori와의 연동도 자연스러웠습니다.
CDS View를 처음 도입했을 때 가장 인상적이었던 건 집계 로직이 ABAP 코드가 아닌 선언적 뷰로 표현된다는 점이었습니다. 기존에는 SELECT와 루프로 집계를 처리했는데, 데이터 양이 늘면서 응답 시간이 길어지는 문제가 있었습니다.
CDS View로 집계 로직을 HANA 데이터베이스 레이어로 내리고 필요한 필드만 프로젝션하는 방식으로 바꾸니 처리 속도가 개선됐습니다. @Analytics.dataCategory 어노테이션으로 큐브 구조를 선언하면 리포트 집계가 DB 레이어에서 처리되는 효과가 있었습니다.
이 경험으로 CDS View는 성능 최적화보다 "데이터 모델을 어디에 두는가"라는 설계 관점의 도구라는 걸 배웠습니다.
CDS View를 쓰다 보면 Association을 많이 정의할수록 뷰가 복잡해지는 한계를 경험했습니다. 각 뷰가 독립적으로 설계되어야 재사용이 가능한데, 기능 요구가 늘면서 하나의 뷰에 너무 많은 Association을 넣는 방향으로 흘렀습니다.
이후에 뷰를 다시 쪼개려 했는데, 이미 여러 프로그램이 해당 뷰를 참조하고 있어 수정 범위가 커졌습니다. 이 경험으로 처음부터 단일 목적 뷰를 유지하는 것이 이후에 훨씬 유연하다는 걸 알았습니다.
이 경험으로 CDS View 설계는 처음 잘 나누는 것이 나중에 수정 비용을 낮춘다는 걸 배웠습니다. 초기 설계 단계에서 목적과 재사용 범위를 명확히 잡는 것이 중요합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.