우문현답
愚 問 賢 答
회사별 면접직군별질문 가이드진행 방식
    홈›회사별›CJ올리브영›그래픽·시각디자인›질문 상세
    問
    CCJ올리브영그래픽·시각디자인직무 역량2026년 출제

    디자인 시스템이나 UI 가이드 제작 경험이 있다면, 어떤 과정이었나요?

    답변 미리보기

    디자인 시스템을 처음 만들었을 때 실수한 게 모든 요소를 컴포넌트로 만들려고 한 것입니다. 4인 팀 프로젝트에서 버튼·카드 등을 전부 컴포넌트로 만들다 보니…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    시스템의 목적이 분명한가?
    디자인 일관성·개발 속도·확장성 중 무엇을 우선했는지 본인의 정의가 답에 있는지를 봅니다. '시스템이 필요하다' 수준의 답은 면접관이 '왜요?'를 추가로 묻는 자리가 자주 보입니다.
    骨
    02
    컴포넌트의 경계를 가르는가?
    공통 컴포넌트와 페이지별 변주의 경계를 어떻게 잡았는지가 답에 있는지를 봅니다. 모든 요소를 똑같이 다룬 답은 설계 감도가 약해 보입니다.
    語
    03
    토큰·문서·코드가 맞물리는가?
    토큰·문서·코드 라이브러리가 어떻게 함께 돌아가는지가 답에 있는지를 봅니다. 시각 자료만 말하는 답은 깊이가 부족해 보이는 자리가 흔합니다.
    本
    04
    운영·갱신 흐름을 다루는가?
    시스템이 낡지 않도록 정기 갱신과 소유자 책임을 어떻게 설계했는지가 답에 있는지를 봅니다. 초기 구축만 말하는 답은 운영 감도가 약해 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    CJ올리브영 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    목적과 컴포넌트 경계를 먼저 정의하고 토큰·갱신 흐름까지 설계한 결약 70초토큰·문서 연결로 공통 언어 정착 결변경 공유·이유 기록으로 운영 구조 설계 결
    예시 답변 1
    약 70초

    목적과 컴포넌트 경계를 먼저 정의하고 토큰·갱신 흐름까지 설계한 결

    디자인 시스템을 처음 만들었을 때 실수한 게 모든 요소를 컴포넌트로 만들려고 한 것입니다. 4인 팀 프로젝트에서 버튼·카드 등을 전부 컴포넌트로 만들다 보니 자유도가 너무 낮아진다는 피드백이 나왔습니다. 그때부터 공통 컴포넌트와 페이지별 변주 허용 구간을 나누는 게 설계의 핵심이라는 걸 알았습니다. 컬러·간격·서체는 디자인 토큰으로 먼저 잡으면 코드와 디자인 파일이 같은 값을 공유할 수 있어서 핸드오프 오류가 줄었습니다. 갱신 흐름도 처음부터 설계했는데, 소유자를 정해두지 않으면 시스템이 옛날 자료가 된다는 걸 한 학기 후에 직접 확인했습니다. 디자인 시스템은 구축보다 굴러가는 방식이 더 중요하다는 게 지금 생각입니다.

    이 결의 특징
    모든 요소를 컴포넌트로 만들려다 자유도가 너무 낮아진다는 피드백을 받고 공통 컴포넌트와 페이지별 변주 허용 구간을 나누는 것이 설계의 핵심이라는 인식을 잡은 흔적이 있습니다. 소유자를 정해두지 않으면 시스템이 옛날 자료가 된다는 한 학기 후 직접 확인 결이 서술됩니다.
    이 결이 통하는 자리
    구축보다 굴러가는 방식이 더 중요하다는 인식이 소유자 미지정으로 시스템이 낡은 경험에서 나온 자리가 살아 있을 때 통합니다. 공통과 변주 구간 분리의 이유가 명확히 설명된 경우 면접관의 꼬리질문이 줄어드는 결이 자주 보입니다.
    예시 답변 2

    토큰·문서 연결로 공통 언어 정착 결

    디자인 시스템에서 토큰·문서가 어떻게 묶여 실제로 굴러가는지를 파악하는 결이 있습니다. 학과 프로젝트에서 팀이 함께 쓰는 디자인 파일을 구성할 때, 컬러 토큰을 Figma 안에서 변수로 정의하고 팀원들이 그 변수를 참조하는 방식을 시도했습니다. 처음에는 토큰 이름이 통일되지 않아 primary-blue와 brand-blue가 혼용되는 자리가 생겼습니다.

    토큰 명칭 기준표 한 장을 따로 문서로 만들어 공유하니 혼용 자리가 눈에 띄게 줄었습니다. 시각 자산과 문서가 연결되지 않으면 진짜 시스템이라고 부르기 어려운 자리가 생긴다는 걸 이 경험에서 배웠습니다. 토큰·문서 연결 결은 Figma 파일을 정리하는 자리가 아니라, 팀 전체가 공통 언어로 자산을 부르는 구조를 만드는 자리에서 드러납니다.

    이 결의 특징
    컬러 토큰을 Figma 변수로 정의하고 팀원이 참조하는 방식을 시도했을 때 토큰 이름 혼용 문제가 발생한 흔적이 있습니다. 명칭 기준표 한 장을 따로 문서화해 공유하자 혼용이 눈에 띄게 줄었다는 결과가 시각 자산과 문서가 연결돼야 진짜 시스템이라는 교훈으로 닫힙니다.
    이 결이 통하는 자리
    팀 전체가 공통 언어로 자산을 부르는 구조를 만드는 것이 Figma 파일 정리와 다르다는 인식이 혼용 경험에서 나온 것으로 서술될 때 통합니다. 명칭 기준표 도입 전후 혼용 빈도 변화가 살아 있는 자리에서 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    예시 답변 3

    변경 공유·이유 기록으로 운영 구조 설계 결

    디자인 시스템이 처음 만들어진 뒤에도 굳지 않게 굴러가려면 운영 구조가 함께 설계되어야 한다는 걸 경험으로 배웠습니다. 학과 프로젝트에서 팀 공용 디자인 파일을 구성한 뒤, 한 명이 컴포넌트 수정을 했는데 나머지 팀원들이 그 변경을 모르는 자리가 생겼습니다. 변경이 있을 때 공유 알림 자리가 없으니 각자의 파일이 다른 버전이 되는 문제가 생겼습니다.

    시스템을 만드는 결과 굴리는 결은 다른 자리에서 작동한다는 걸 이 경험에서 확인했습니다. 이 경험이 컴포넌트를 수정할 때 변경 이유와 범위를 짧게 기록해두는 결의 출발이 됐습니다. 운영 결은 초기 구축을 잘 하는 자리가 아니라, 만들어진 시스템이 어떻게 살아있는 상태를 유지하는지를 설계하는 자리에서 드러납니다.

    이 결의 특징
    한 명이 컴포넌트를 수정했는데 나머지 팀원이 변경을 모르는 문제가 발생한 흔적이 있습니다. 변경 이유와 범위를 짧게 기록하는 결을 잡은 경험이 남아 있으며 시스템을 만드는 결과 굴리는 결은 다른 자리에서 작동한다는 인식이 서술됩니다.
    이 결이 통하는 자리
    운영 구조가 초기 구축과 함께 설계돼야 한다는 인식이 변경 공유 실패 경험에서 나온 것으로 서술될 때 통합니다. 만들어진 시스템이 살아있는 상태를 유지하는 방식 설계라는 정의가 또렷한 경우 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕일관성이나 확장성 같은 원론적 키워드만 나열하고 실제 구축 경험을 말하지 않았는가? 구체적 사례가 없으면 개념 설명에 그칩니다.
    • ✕디자이너 관점에서만 말하고 개발자와의 협업(컴포넌트 명세 등)을 언급하지 않았는가? 디자인 시스템은 협업 도구라는 점이 중요합니다.
    • ✕기존 시스템을 바꾸거나 예외 상황을 처리한 경험 없이 이상적인 구조만 말하지 않았는가? 실제 부딪힌 문제가 이해도를 보여줍니다.
    • ✕왜 그 요소를 가장 중요하게 봤는지 근거 없이 단정적으로만 답하지 않았는가? 판단 근거가 있어야 설득력이 생깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹디자이너와 개발자 간의 인식 차이를 어떻게 좁혀나가시나요?
    대응토큰, 컴포넌트, 코드 예시를 함께 제시하는 답이 자주 나옵니다. 작은 합의의 시도가 보이면 실무 감각이 드러납니다.
    貳디자인 시스템이 실제로 안 쓰이게 된 경험이 있나요?
    대응예시 부족, 복잡한 구조, 온보딩 부족 중 어디가 약했는지 인정하는 답이 강합니다. 그 후 어떻게 개선했는지까지 말하면 성장이 보입니다.
    參시스템 외의 새로운 패턴이 생겼을 때 어떻게 대응하셨나요?
    대응정기적으로 패턴을 추출해 시스템에 흡수하는 과정이 나타나는 답이 강합니다. 본인의 흡수 기준이 분명하면 신뢰감이 커집니다.
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. CJ올리브영 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    라인 · 프로덕트 디자이너
    디자인 시스템을 활용한 UI 설계 경험에 대해 설명해 주실 수 있나요?
    이 질문 보기
    마켓컬리 · UX·프로덕트 디자인 일반
    디자인 시스템을 설계하거나 운영한 경험에 대해 구체적으로 설명해줄 수 있나요?
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, CJ올리브영 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기