이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
RAP를 직접 개발한 경험은 없지만, SAP 기반 백엔드 아키텍처를 공부하면서 RAP(ABAP RESTful Application Programming) 개념을 접했습니다. 기존 클래식 ABAP 방식과 달리 RAP는 OData 서비스를 선언적으로 정의하고 비즈니스 오브젝트 모델을 중심으로 CRUD 동작을 구현하는 구조였습니다.
CDS(Core Data Services) 뷰를 기반으로 데이터 모델을 정의하고, 그 위에 동작 로직을 레이어별로 분리하는 방식이 일반 REST API 설계 원칙과 유사하다는 점이 흥미로웠습니다. RAP의 핵심 강점은 트랜잭션 관리와 잠금 처리가 프레임워크 수준에서 지원된다는 점이었는데, 비즈니스 로직에만 집중할 수 있는 구조가 ERP 개발에 적합하다는 걸 공부했습니다. 지금은 실제 RAP 환경에서 직접 구현해보는 경험을 쌓고 싶습니다.
ABAP RESTful Application Programming 기반으로 OData 서비스를 개발할 때, CDS 뷰 레이어를 과도하게 중첩시켜 쿼리 실행 계획이 복잡해지는 성능 문제를 경험했습니다. 초기에는 CDS View Entity를 역할별로 세분화했는데, 중첩 깊이가 깊어지면서 Hana DB에서 조인 폭발이 발생했습니다. 이후 performance analysis를 ST05 SQL Trace로 분석하고, 핵심 집계 로직은 CDS로 올리되 서비스 레이어에서 필요한 필드만 선택하는 방식으로 구조를 단순화했습니다. 쿼리 실행 시간이 3.5배 개선됐고, 이 경험에서 RAP 설계의 핵심은 CDS 추상화 계층을 과도하게 나누지 않는 것임을 배웠습니다.
RAP Managed 시나리오로 구매 승인 프로세스를 구현할 때, 비즈니스 로직을 어디에 두어야 하는지 기준이 없어 팀 내 구현 방식이 일관되지 않는 문제가 생겼습니다. 일부는 Determination에 로직을 넣고, 일부는 Action에 넣는 방식을 섞어 사용했습니다. 저는 RAP 프레임워크 문서를 기반으로 데이터 변경 트리거 로직은 Determination, 명시적 사용자 액션은 Action, 교차 필드 검증은 Validation으로 구분하는 팀 가이드를 작성했습니다. 이 가이드 적용 이후 코드 리뷰 시 로직 위치 관련 피드백이 사라졌고, 새 기능 추가 시 구현 방향에 대한 팀 논의 시간이 줄었습니다. RAP 개발에서 중요한 것은 프레임워크가 의도한 레이어 구분을 팀 전체가 공유하는 것임을 이 경험에서 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.