이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 작품으로 소형 스마트홈 센서 모니터링 시스템을 만들면서, 온도·습도 이상을 수동으로 확인하는 구조의 한계를 느꼈습니다. 알람이 울려도 원인이 무엇인지 직접 로그를 봐야 했습니다.
이상 감지 → 원인 추정 → 조치 제안의 3단계로 동작하는 간단한 에이전트 구조를 설계해 봤습니다. 이상 패턴이 감지되면 이전 3시간 센서 로그를 요약해 LLM에 넘기고, 가능한 원인과 점검 체크리스트를 생성하는 방식입니다.
실제로 구현해 보니 LLM 응답이 원인을 과신하게 표현해서 사용자가 실제 점검 없이 결론으로 받아들이는 문제가 있었습니다. '가능한 원인 중 하나입니다'로 표현을 명확히하고 꼭 직접 확인하도록 유도하는 안내를 추가했습니다. 에이전트 설계에서 신뢰도 표현이 기능만큼 중요하다는 걸 그때 배웠습니다.
사이드 프로젝트에서 매일 아침 서비스 상태 요약 리포트를 슬랙에 보내는 작업이 있었습니다. 직접 대시보드를 보고 정리하다 보니 매일 20분이 걸렸고, 바쁜 날엔 빠뜨리는 일도 생겼습니다.
API 호출로 지표를 수집하고 LLM으로 자연어 요약을 생성해 슬랙에 발송하는 에이전트를 만들었습니다. 어제 대비 변화량, 이상 값, 주의할 항목을 포함하는 구조로 프롬프트를 설계했습니다. 처음엔 긍정적인 내용만 강조하는 경향이 있어 '이상이 없으면 없다고, 이상이 있으면 먼저 언급하라'는 지시를 추가했습니다.
그 경험에서 에이전트는 단순 자동화와 달리 출력 품질을 지속적으로 점검해야 한다는 걸 배웠습니다. 처음 동작한다고 끝이 아니라 운영하면서 기대와 다른 출력을 계속 수정하는 것이 에이전트 개발의 특성이라는 것이 지금도 제 인식입니다.
스마트홈 에이전트 설계 경험은 없지만, IoT 센서 데이터 수집 시스템을 졸업 작품으로 만든 경험에서 비슷한 문제를 다룬 적이 있습니다.
설비 이상을 담당자에게 알리는 기능을 만들 때, 단순 임계값 알람은 오탐이 너무 많다는 문제가 있었습니다. 이상 패턴을 구분하기 위해 최근 30분 추이와 설비 점검 스케줄을 함께 고려하는 조건 로직을 만들었고, 알람 오탐이 80% 줄었습니다.
스마트홈 운영 에이전트라면 장치 상태 이력과 사용자 패턴을 함께 고려해 '왜 이상인가'를 추정하는 것이 핵심이라고 생각합니다. 이상 감지 이후 조치 추천까지 연결하는 구조가 단순 알람보다 훨씬 유용할 것이고, 그 설계 경험을 쌓고 싶어 이 포지션에 지원했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 직방 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.