이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
AI DC용 솔루션 경험은 없지만, 사이드 프로젝트에서 팀원들끼리 좋을 것 같다고 생각한 기능을 만들었다가 실제 사용자에게 외면받은 경험이 있습니다.
알림 기능을 정성껏 만들었지만, 막상 테스트 사용자 5명에게 보여주었더니 3명이 알림을 아예 끄겠다고 했습니다. 알림이 도움이 아니라 방해라고 느끼는 것이었습니다. 우리 가정이 틀렸다는 것을 2주 일하고 나서야 알게 되었습니다.
이후에는 기능을 만들기 전에 페인 포인트부터 묻는 것을 원칙으로 삼았습니다. AI DC 솔루션이라면 먼저 운영팀이 지금 가장 자주 하는 수작업이 무엇인지 물어보는 데서 시작할 것 같습니다. 기술 솔루션보다 실제 문제가 먼저라는 것을 이때 배웠습니다.
인턴 때 비개발자 담당자에게 API 연동 방식을 안내하는 일을 도왔어요. 처음엔 기술 문서를 그대로 전달했는데, '이게 뭔 소린지 모르겠다'는 반응을 받았습니다.
그래서 담당자가 걱정하는 게 뭔지 먼저 물어봤어요. 결국 '연동하다가 기존 시스템이 망가지면 어떡하냐'는 두려움이 핵심이었습니다. 기술적 안전 장치를 쉬운 언어로 설명하고, 테스트 환경에서 먼저 해볼 수 있다는 걸 알려줬어요.
이 경험에서 배운 건, 고객의 니즈는 표면 요청 뒤에 있다는 거예요. AI DC 솔루션에서도 고객이 원하는 게 '더 많은 기능'이 아니라 '운영 불안감 해소'나 '비용 예측 가능성'일 수 있다고 생각합니다.
AI DC용 솔루션을 직접 제안해본 경험은 없지만, 문제를 먼저 이해하고 솔루션을 나중에 제안하는 것이 순서라고 생각해요.
학교에서 디자인 씽킹 워크숍을 들으면서 배운 게, 고객이 '이게 필요하다'고 말하는 것과 실제로 필요한 것이 다를 수 있다는 점이었어요. 유명한 예시처럼 '더 빠른 말'을 원했는데 실제로는 '빠른 이동 수단'이 필요했던 거잖아요.
AI DC 담당자라면 '지금 운영에서 제일 시간이 많이 드는 게 뭔지', '놓쳐서 문제가 됐던 게 뭔지' 먼저 묻고 싶어요. 기술 이야기는 그 다음이라고 생각합니다. 솔루션보다 먼저 문제를 같이 정의하는 게 고객 신뢰를 만드는 방법이라고 느꼈어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK innovation 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.