이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대화 품질 개선을 위한 성능 테스트는 챗봇 프로젝트에서 응답 적절성을 측정하는 평가 루틴을 만들면서 처음 체계화했습니다. 초반에는 사람이 직접 응답을 보고 좋다/나쁘다를 판단했는데, 이 방식은 시간이 많이 들고 기준이 주관적이었습니다. 응답 관련성, 답변 완결성, 금지 표현 포함 여부를 항목으로 나눠 각각 별도로 측정하는 구조로 바꿨습니다.
LLM-as-judge 방식으로 별도 모델이 응답을 채점하게 했는데, 사람 평가와 비교했을 때 상관관계가 높아 반복 테스트에 활용할 수 있었습니다. 회귀 테스트 역할도 겸하도록 설계했는데, 프롬프트를 수정한 뒤 동일 질문 세트를 돌려 이전보다 나빠진 항목이 없는지를 먼저 확인했습니다. 대화 품질 테스트는 측정할 수 없는 것은 개선할 수 없다는 것을 직접 경험한 결임을 배웠습니다.
챗봇 서비스를 사용자에게 공개하기 전에 동시 사용자가 몰렸을 때의 응답 지연이 어떻게 변하는지를 측정해야 했습니다. 기능은 단일 사용자 기준으로 잘 동작했지만, 동시 요청이 늘어날수록 응답이 느려지는 패턴이 부하 테스트에서 드러났습니다. 특히 스트리밍 응답 방식을 사용했기 때문에 첫 토큰이 도착하기까지의 시간(TTFT)과 전체 응답 완료 시간을 분리해서 측정했습니다.
TTFT가 길어지면 사용자가 응답이 시작됐다는 체감이 없어지므로, 이 수치를 별도 임계값으로 관리했습니다. 동시 사용자 50명 이상에서 TTFT가 목표치를 넘었고, LLM 호출 앞단에 큐를 추가해 순차 처리하는 방식으로 안정화했습니다. 대화 품질 테스트는 정확성뿐 아니라 응답 시작 속도라는 체감 지표를 측정 대상에 포함시켜야 실제 사용자 경험을 반영할 수 있다는 것을 이 경험에서 배웠습니다.
대화 품질 측정에서 자동 지표와 인간 평가의 불일치를 처음 마주쳤을 때 당황했습니다. BLEU 점수가 높아진 응답이 사람이 읽기에는 오히려 어색하거나 불필요하게 장황한 경우가 있었습니다. 자동 지표는 참조 답변과의 표면적 유사도를 보는 반면, 인간 평가는 맥락과 자연스러움을 함께 본다는 차이가 있었습니다. 이 불일치를 확인하고 나서 LLM-as-judge 방식으로 보조 평가를 추가했는데, 평가 모델도 특정 유형의 응답에 편향을 보이는 경우가 있었습니다.
측정 방법이 다르면 개선 방향도 달라진다는 것을 실감하면서, 자동 지표와 인간 평가를 교차 확인하는 루틴을 정했습니다. 자동 지표만 믿으면 점수를 올리는 방향으로 모델이나 프롬프트가 최적화되지만 실제 품질이 올라가지 않는 현상이 나타날 수 있다는 것을 배운 경험이었습니다.
무엇을 측정하는가가 무엇을 개선하는가를 결정한다는 원칙이 이때 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.