이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
AEM 플랫폼 기반 사이트 구축에서 가장 먼저 한 것은 플랫폼이 지원하는 컴포넌트 구조와 제약을 파악하는 것이었습니다. 일반적인 디자인 도구와 달리 AEM은 템플릿과 컴포넌트 체계 안에서 설계가 이루어지기 때문에, 플랫폼 제약을 이해하지 않으면 개발 단계에서 재작업이 발생합니다.
콘텐츠 관리 흐름도 설계에 영향을 줬습니다. 편집자가 실제로 어떤 방식으로 콘텐츠를 업데이트하는지를 파악하면, 관리가 수월한 컴포넌트 구조와 레이아웃을 설계하는 데 기준이 생겼습니다.
플랫폼 특성에 맞게 디자인을 조정하는 것도 경험했습니다. 원하는 디자인을 그대로 구현하기 어려운 경우, 플랫폼 안에서 가장 가까운 대안을 찾는 판단이 협업 속도를 유지하는 방법이었습니다. 제약을 이해하면 불필요한 충돌이 줄어들었습니다.
AEM 플랫폼 사이트 구축에서 가장 크게 배운 것은 재사용성과 커스터마이징 유연성 사이의 트레이드오프를 초반에 결정해야 한다는 것이었습니다. 코어 컴포넌트를 그대로 쓰면 유지보수가 쉽지만, 브랜드 요구사항을 맞추기 위해 커스텀 컴포넌트를 많이 만들수록 이후 AEM 버전 업그레이드 시 호환성 유지 비용이 커진다는 것을 경험했습니다.
콘텐츠 작성자가 개발자 없이 편집할 수 있는 구조를 처음부터 고려하지 않으면, 마케터가 실제로 쓸 때 개발 요청이 빈번하게 들어오는 구조가 됐습니다. In-Place Editing — 화면에서 직접 텍스트와 이미지를 편집하는 구조를 작성자 경험 기준으로 먼저 설계하는 것이 운영 효율을 만든다는 걸 뒤늦게 배웠습니다. 다음에 또 같은 플랫폼 프로젝트를 한다면 컴포넌트 설계 전에 운영 주체가 누구이고 어떻게 수정하는지를 먼저 파악할 것입니다. 플랫폼은 운영하면서 진짜 비용이 드러납니다.
AEM 플랫폼 구축에서 가장 구체적인 도전은 다국어·멀티사이트 콘텐츠를 일관되게 관리하는 것이었습니다. 한국어 기준으로 만든 페이지를 다른 언어 시장에 배포할 때, 텍스트 길이 차이로 레이아웃이 깨지는 경우와 날짜·숫자 포맷이 달리 표시되는 문제가 예상보다 많이 나왔습니다.
멀티사이트 관리자(MSM)를 통해 글로벌 공통 구조를 상속하면서 지역별 배리에이션을 관리하는 방식이 있지만, 어디까지 공통으로 쓰고 어디서 분기할지를 초반에 정의하지 않으면 이후 관리가 복잡해졌습니다. 콘텐츠 작성자가 어느 필드를 지역별로 수정할 수 있는지를 컴포넌트 설계에서 먼저 정의하는 것이 운영 혼란을 줄였습니다.
헤드리스 모드와 기존 CMS 방식의 트레이드오프를 팀이 함께 이해하는 것이 설계 방향을 정하는 첫 단계였습니다. 플랫폼 도전은 운영 방식을 미리 그려보는 것에서 반이 풀립니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 PTKOREA UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.