기존 데이터 소스를 활용하여 대시보드나 보고 워크플로우 프로토타입을 어떻게 지원할 수 있을까요? | 크래프톤 데이터·AI 일반 면접 질문

Q: 기존 데이터 소스를 통해 어떤 인사이트를 도출할 수 있었나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

Q: 이 데이터 소스를 선택한 이유는 무엇이었나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

Q: 이 프로토타입을 통해 개선된 사항은 무엇이었나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

크크래프톤데이터·AI 일반직무 역량2026년 출제

답변 미리보기

인턴 때 팀 주간 보고가 매번 수작업으로 엑셀을 합치는 방식이었는데, 저는 이를 Looker Studio로 자동화하는 프로토타입을 만들었습니다. 먼저 기존

예상 답변 시간

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

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

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

데이터 소스를 활용했는가?

기존 데이터 소스를 활용한 경험이 답에 있어야 합니다. 없으면 면접관이 '어떤 데이터 소스를 사용했나요?'를 추가로 묻는 경우가 자주 보입니다.

대시보드 설계 경험이 있는가?

대시보드나 보고서 설계 경험이 답에 포함된 흔적이 있어야 합니다. 없으면 면접관이 '구체적으로 어떤 대시보드를 만들었나요?'를 질문하는 자리가 자주 보입니다.

프로토타입 제작 경험이 있는가?

워크플로우 프로토타입 제작 경험이 답에 있어야 합니다. 없으면 면접관이 '그 프로토타입은 어떻게 만들었나요?' 같은 질문을 던지는 자리가 흔하게 통합니다.

결과를 어떻게 측정했는가?

프로토타입이나 대시보드의 결과를 측정한 흔적이 답에 있어야 합니다. 없으면 면접관이 '결과는 어땠나요?'를 추가로 묻는 경우가 자주 보입니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

크래프톤 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

경험 중심 1인칭 답변약 90초 SQL 뷰로 기존 소스를 자동화하고 데이터 정합성 문제를 발견·해결하는 결약 90초 사용자 인터뷰로 지표를 정의하고 반복 검증으로 줄여가는 결약 95초

약 90초

경험 중심 1인칭 답변

인턴 때 팀 주간 보고가 매번 수작업으로 엑셀을 합치는 방식이었는데, 저는 이를 Looker Studio로 자동화하는 프로토타입을 만들었습니다. 먼저 기존 데이터 소스(Google Sheets, BigQuery)를 연결하고, 팀원들이 매주 묻는 지표 5가지를 화면에 배치했습니다.

조회 조건은 날짜 필터만 바꾸면 자동으로 업데이트되도록 설계했습니다. 초기 프로토타입을 팀에 공유했을 때 '보고 싶은 지표 순서가 다르다'는 피드백이 있었고, 2회 수정 후 현업에서 사용하는 버전이 됐습니다. 대시보드는 데이터보다 보는 사람의 질문 구조에 맞춰 설계해야 한다는 걸 배웠습니다. 기술보다 어떤 결정에 쓰이는 화면인지를 먼저 이해하는 게 중요합니다. 앞으로도 대시보드를 설계할 때 보는 사람의 질문 구조에 맞춰 화면을 구성하는 방식을 유지하겠습니다.

데이터보다 어떤 결정에 쓰이는 화면인지를 먼저 이해하는 것이 대시보드 설계의 출발점입니다. 기술보다 사용자 맥락이 먼저입니다.

이 결의 특징

자신의 설계만으로 마치지 않고 5명의 외부 사용자나 이해관계자로부터 실제 피드백을 받아 반복 개선한 과정이 구체적입니다.

이 결이 통하는 자리

5 → 2처럼 구체적인 수치 변화가 있을 때 통합니다. 주장이 아닌 근거로 뒷받침할 때 면접관의 신뢰가 형성됩니다.

예시 답변 2

약 90초

SQL 뷰로 기존 소스를 자동화하고 데이터 정합성 문제를 발견·해결하는 결

기존 데이터 소스를 활용해 보고 워크플로우를 프로토타입할 때, 저는 수신자가 주간 보고에서 실제로 결정하는 것이 무엇인지를 먼저 확인하는 것부터 시작합니다.

영업팀이 매주 수작업으로 CRM에서 데이터를 뽑아 Excel로 집계하는 과정을 보고, SQL 뷰를 만들어 자동 집계하는 구조로 바꾸는 프로토타입을 제안했습니다. 핵심은 기존 CRM DB 스키마를 그대로 쓰면서 집계 쿼리만 뷰로 감싸는 방식이었습니다. 기술 변경을 최소화해야 팀이 빠르게 받아들일 수 있다고 판단했습니다.

프로토타입을 공유한 뒤 팀장이 저번 주 수치와 다르다는 점을 지적했고, 데이터 정합성 문제가 드러났습니다. CRM 업데이트 타이밍과 집계 시점이 맞지 않아서였는데, 집계 기준 시간을 뷰 정의에 명시하는 것으로 해결했습니다.

결과적으로 보고서 준비 시간이 2시간에서 15분으로 줄었고, 팀은 그 시간을 분석에 쓸 수 있게 됐습니다. 프로토타입은 작동하는 것보다 팀이 신뢰할 수 있는 숫자를 보여주는 것이 먼저라는 걸 배웠습니다.

이 결의 특징

'점을 지적했고, **데이터 정합성 문제**가 드러났습니다. `CRM` 업데이트 타이밍과 집계 시점이 맞지 않' 같은 구체적 문제를 마주친 뒤, 근본 원인을 파악하고 '해결했습니다. 결과적으로 보고서 준비 시간이 *2시간에서 15분*으로 줄었고, 팀은 그 시간을 분석에 쓸 ' 형태로 개선한 실제 과정이 드러납니다.

이 결이 통하는 자리

2 → 15처럼 구체적인 수치 변화가 있을 때 통합니다. 주장이 아닌 근거로 뒷받침할 때 면접관의 신뢰가 형성됩니다.

예시 답변 3

약 95초

사용자 인터뷰로 지표를 정의하고 반복 검증으로 줄여가는 결

대시보드 프로토타입을 만들 때 제가 가장 주의하는 것은 어떤 지표를 보여줄지를 혼자 결정하지 않는 것입니다.

운영팀을 위한 보고 화면을 만든 적이 있는데, 데이터 소스는 PostgreSQL에 이미 다 있었습니다. 문제는 팀원마다 "잘 되고 있다"는 기준이 달랐다는 점입니다. 한 명은 처리 건수를, 다른 한 명은 오류율을 봤고, 두 숫자가 같은 날 서로 다른 방향을 가리켜 혼란이 생긴 적도 있었습니다.

저는 화면을 만들기 전에 팀원 3명과 각각 15분씩 인터뷰를 했습니다. 지난주 회의에서 가장 자주 나온 질문이 무엇이었는지를 물었고, 공통된 질문 패턴 4개를 뽑아 화면에 보여줄 지표를 정의했습니다. Metabase로 첫 번째 버전을 만들고, 실제 보고 자리에서 한 번 써보게 한 뒤 두 번 수정했습니다.

최종 버전은 지표 수를 6개에서 4개로 줄인 형태였습니다. 줄일수록 팀이 어디를 봐야 하는지 빠르게 파악했고, 대시보드는 결정에 필요한 것만 남기는 것이 효과적이라는 걸 직접 확인했습니다.

이 결의 특징

'reSQL`에 이미 다 있었습니다. 문제는 팀원마다 **"잘 되고 있다"는 기준**이 달랐다는 점입니다. 한' 같은 구체적 장애물을 인식한 후, 단순한 회피가 아니라 원인 분석을 거친 개선 과정이 구체적으로 담겨 있습니다.

이 결이 통하는 자리

3 → 15처럼 구체적인 수치 변화가 있을 때 통합니다. 주장이 아닌 근거로 뒷받침할 때 면접관의 신뢰가 형성됩니다.

위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.

자주 빠지는 자리

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

떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.

이어질 꼬리질문

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

壹기존 데이터 소스를 통해 어떤 인사이트를 도출할 수 있었나요?

貳이 데이터 소스를 선택한 이유는 무엇이었나요?

參이 프로토타입을 통해 개선된 사항은 무엇이었나요?

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. 크래프톤 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히

개인정보처리방침 이용약관 문의

크크래프톤데이터·AI 일반직무 역량2026년 출제

답변 미리보기

인턴 때 팀 주간 보고가 매번 수작업으로 엑셀을 합치는 방식이었는데, 저는 이를 Looker Studio로 자동화하는 프로토타입을 만들었습니다. 먼저 기존

예상 답변 시간

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

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

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

데이터 소스를 활용했는가?

기존 데이터 소스를 활용한 경험이 답에 있어야 합니다. 없으면 면접관이 '어떤 데이터 소스를 사용했나요?'를 추가로 묻는 경우가 자주 보입니다.

대시보드 설계 경험이 있는가?

프로토타입 제작 경험이 있는가?

결과를 어떻게 측정했는가?

프로토타입이나 대시보드의 결과를 측정한 흔적이 답에 있어야 합니다. 없으면 면접관이 '결과는 어땠나요?'를 추가로 묻는 경우가 자주 보입니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

크래프톤 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

약 90초

경험 중심 1인칭 답변

데이터보다 어떤 결정에 쓰이는 화면인지를 먼저 이해하는 것이 대시보드 설계의 출발점입니다. 기술보다 사용자 맥락이 먼저입니다.

이 결의 특징

자신의 설계만으로 마치지 않고 5명의 외부 사용자나 이해관계자로부터 실제 피드백을 받아 반복 개선한 과정이 구체적입니다.

이 결이 통하는 자리

5 → 2처럼 구체적인 수치 변화가 있을 때 통합니다. 주장이 아닌 근거로 뒷받침할 때 면접관의 신뢰가 형성됩니다.

예시 답변 2

약 90초

SQL 뷰로 기존 소스를 자동화하고 데이터 정합성 문제를 발견·해결하는 결

이 결의 특징

이 결이 통하는 자리

2 → 15처럼 구체적인 수치 변화가 있을 때 통합니다. 주장이 아닌 근거로 뒷받침할 때 면접관의 신뢰가 형성됩니다.

예시 답변 3

약 95초

사용자 인터뷰로 지표를 정의하고 반복 검증으로 줄여가는 결

대시보드 프로토타입을 만들 때 제가 가장 주의하는 것은 어떤 지표를 보여줄지를 혼자 결정하지 않는 것입니다.

이 결의 특징

이 결이 통하는 자리

3 → 15처럼 구체적인 수치 변화가 있을 때 통합니다. 주장이 아닌 근거로 뒷받침할 때 면접관의 신뢰가 형성됩니다.

자주 빠지는 자리

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

떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.

이어질 꼬리질문

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

壹기존 데이터 소스를 통해 어떤 인사이트를 도출할 수 있었나요?

貳이 데이터 소스를 선택한 이유는 무엇이었나요?

參이 프로토타입을 통해 개선된 사항은 무엇이었나요?

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. 크래프톤 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

개인정보처리방침 이용약관 문의