이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 RAG 기반 에이전트를 만들면서 성능 지표를 어떻게 정의할지부터 막혔습니다. 지연 시간은 end-to-end 응답 시간을 기본으로 측정했고, 검색 단계와 생성 단계로 분리해서 어느 쪽이 병목인지 먼저 파악했습니다. 정확도는 사람이 직접 100건을 평가하는 기준을 만들고, 에이전트 응답이 얼마나 닿는지를 비율로 추적했습니다. 비용 측면에서는 API 호출 당 토큰 수를 로그로 남겼는데, 프롬프트 구조를 바꾸면 토큰이 줄면서 응답 품질도 달라지는 케이스를 경험했습니다. 실패율도 별도로 추적해서, 오류 비율이 일정 수준을 넘으면 패턴을 분석해 프롬프트나 컨텍스트 구성을 수정했습니다. 개선할 때는 한 가지씩 바꾸면서 지표 변화를 관찰하는 방식이 효과적이었습니다.
정량 지표 없이는 에이전트가 개선됐는지조차 알기 어렵다는 걸 그때 배웠습니다.
에이전트 성능을 측정하기 시작했을 때 가장 먼저 만든 것은 평가 데이터셋이었습니다. 임의로 테스트하면 같은 입력에도 결과가 달라 보이기 때문에, 반복 가능한 비교를 하려면 고정된 입력 셋이 필요했습니다.
50개의 대표적인 입력 케이스를 모아 각각에 대한 기대 출력을 기록했습니다. 처음에는 모두 사람이 직접 평가했는데 시간이 오래 걸려서, 명확한 판단 기준이 있는 케이스는 자동으로 채점하는 스크립트를 만들었습니다. 도구 호출 여부, 응답 형식 준수 여부처럼 규칙이 명확한 부분은 자동 검증이 가능했습니다.
프롬프트를 수정할 때마다 이 평가 셋으로 회귀 테스트를 했더니 의도치 않은 성능 저하를 사전에 잡을 수 있었습니다. 한 가지 케이스에서 성능이 올라갔는데 다른 케이스에서 떨어지는 상황이 여러 번 있었고, 평가 셋이 없었다면 놓쳤을 회귀였습니다. 에이전트 개선은 전체 케이스를 커버하는 평가 셋 없이는 진전을 측정하기 어렵다는 생각이 자리 잡혔습니다.
에이전트 성능을 개선하면서 가장 효과가 컸던 것은 도구 정의를 정밀하게 다듬는 작업이었습니다. 처음에는 도구 설명을 간단히 작성했는데, 에이전트가 비슷한 두 도구 중 잘못된 것을 선택하는 오류가 반복됐습니다.
도구 설명에 '이 도구를 사용해야 하는 경우'와 '사용하면 안 되는 경우'를 명시적으로 추가했습니다. 검색 도구와 조회 도구를 구분할 때 입력이 키워드면 검색, 고유 식별자면 조회를 사용하도록 조건을 넣었더니 오류 선택 비율이 줄었습니다.
시스템 프롬프트 길이도 줄이는 실험을 했습니다. 초반에 가이드라인을 길게 작성했는데 에이전트가 지침 중 일부를 무시하는 경향이 보였습니다. 핵심 규칙만 남기고 나머지를 제거하니 오히려 지침 준수율이 올라갔습니다. 에이전트가 처리할 수 있는 맥락 양이 한정돼 있고, 짧고 명확한 지침이 긴 설명보다 효과적인 경우가 많다는 것이 이 경험에서 남은 결입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 신세계아이앤씨 AI 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.