이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
X++ 커스터마이징 경험은 D365 FO 교육 과정에서 실습 프로젝트를 통해 처음 쌓았습니다. 기존 표준 보고서에 커스텀 필드를 추가하는 작업을 했는데, X++는 C#과 유사한 구조라 문법 자체는 빠르게 익혔지만 프레임워크 특유의 레이어 구조를 이해하는 데 시간이 걸렸습니다. 성능 최적화에서 가장 먼저 한 것은 루프 내 쿼리 실행을 줄이는 것이었습니다. 레코드를 하나씩 조회하던 로직을 조인으로 묶어 한 번에 가져오도록 바꾸자 처리 속도가 눈에 띄게 줄었습니다.
캐싱 어노테이션을 활용해 반복 조회가 많은 조회 메서드에 CacheSearch 속성을 적용했고, 동일한 키로 반복 호출될 때 DB 조회가 줄어드는 것을 확인했습니다. 한계는 실제 운영 데이터 규모에서 테스트하지 못했다는 점입니다. X++ 최적화는 DB 접근 횟수를 줄이는 것이 먼저라는 결을 얻었습니다.
X++ 성능 최적화에서 개선이 됐는지 실제로 확인하는 방법도 배웠습니다. 처음에는 빨라진 것 같다는 느낌으로 끝냈는데, 최적화 전후를 비교하려면 시간을 측정해야 한다는 것을 알게 됐습니다. D365 FO에서 SQL 추적 로그를 켜면 어느 쿼리가 몇 번 실행됐는지, 각 쿼리 실행 시간이 얼마인지 확인할 수 있었습니다. 루프 내 쿼리를 조인으로 묶기 전과 후의 실행 횟수를 비교하니, 100건 처리 시 DB 호출이 100번에서 1번으로 줄어든 것이 수치로 확인됐습니다. 처리 시간도 직접 측정했는데, 유사한 데이터 셋으로 최적화 전후를 비교하니 처리 시간이 줄어든 것이 명확했습니다. 한계는 실제 운영 규모의 데이터로 테스트하지 못했다는 점인데, 소규모 데이터에서 효과적인 최적화가 대규모 데이터에서도 동일하게 작동하는지는 별도로 검증이 필요하다는 것을 알게 됐습니다. 성능 개선은 체감이 아니라 측정으로 확인해야 한다는 것을 이 경험에서 배웠습니다.
X++ 커스터마이징에서 가장 시간이 걸린 것은 D365 FO의 레이어 구조를 이해하는 것이었습니다. 표준 기능을 바로 수정하면 나중에 업데이트 시 충돌이 생기는 구조라, 이벤트 핸들러나 확장 클래스로 표준 코드에 영향 없이 기능을 추가하는 방식을 배웠습니다. 처음에는 표준 메서드를 직접 수정해서 구현했는데, 같은 기능을 오버라이드 방식으로 다시 구현하라는 피드백을 받았습니다. 이유를 이해하고 나니 표준 코드를 그대로 두고 확장 포인트에서만 로직을 추가하는 방식이 유지보수에 더 안전하다는 것을 알게 됐습니다. 보고서 커스터마이징에서도 표준 클래스를 상속받아 필요한 메서드만 재정의하는 방식을 적용했습니다. 성능 측면에서는 루프 내 쿼리를 줄이는 것이 중요하지만, 레이어 구조를 이해하지 않으면 올바른 위치에 최적화 로직을 넣기 어렵다는 것을 경험했습니다. ERP 커스터마이징은 언어 문법보다 프레임워크 설계 원칙을 먼저 이해해야 한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.