이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
공공기관 또는 대행 프로젝트에서 자주 겪은 어려움은 요구사항이 문서에 명시돼 있어도 실제 기대와 차이가 있는 경우였습니다. 처음에 합의한 방향이 중간에 바뀌거나 추가 요청이 생기는 일이 많아서, 변경 이력과 합의 내용을 문서로 관리하는 것이 핵심 대응 방법이 됐습니다.
이해관계자가 여럿인 환경도 어려운 부분이었습니다. 담당자, 상위 기관, 최종 검토자의 의견이 서로 다른 경우에는 각자의 우선순위를 파악하고 핵심 결정권자가 누구인지를 명확히 하는 것이 방향을 잡는 데 중요했습니다.
기술적 제약도 변수였습니다. 공공 프로젝트에서는 보안 정책이나 레거시 시스템 제약 때문에 원하는 방식대로 구현하기 어려운 경우가 있었고, 제약 안에서 가능한 최선을 찾는 과정이 문제 해결 능력을 키우는 경험이 됐습니다.
공공 프로젝트에서 가장 비싼 실수는 결정권자를 잘못 파악한 것이었습니다. 담당자와 합의한 내용이 상위 기관 검토에서 뒤집히는 경우가 반복됐고, 처음부터 다시 수정하는 사이클이 두 번 발생했습니다. 그 경험 이후 킥오프 미팅에서 누가 최종 결정권을 갖는지를 명확히 확인하는 것을 첫 번째 질문으로 삼게 됐습니다. 이해관계자가 여럿인 환경에서는 모든 사람을 만족시키려는 방향이 오히려 방향을 잃게 한다는 것도 배웠습니다.
최종 결정권자의 우선순위를 기준으로 잡고, 나머지 의견은 그 안에서 반영하는 방식이 더 효율적이었습니다. 공공 프로젝트는 이해관계가 복잡할수록 프로세스를 더 명확히 해야 한다는 것을 그때 배웠습니다.
공공 프로젝트에서 겪은 또 다른 어려움은 레거시 시스템 제약 때문에 원하는 방식대로 구현이 안 됐던 경우였습니다. 사용자 경험을 개선하기 위해 최신 컴포넌트 방식을 제안했는데, 보안 정책상 외부 라이브러리 사용이 제한돼 있었습니다. 처음엔 제약이 설계를 망친다고 생각했는데, 제약 조건을 먼저 파악하고 그 안에서 가능한 범위를 정의하는 것이 오히려 더 명확한 설계 방향을 줬습니다. 네이티브 기능만으로 구현 가능한 인터랙션을 찾아서 팀에 제안했고, 결과적으로 더 가볍고 빠른 화면이 나왔습니다.
제약은 창의성을 막는 게 아니라 설계의 경계를 명확히 해주는 것이라는 것을 그때 이해했습니다. 이후 프로젝트에서도 기술 스펙 확인을 설계 초반에 하는 습관이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.