이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
AI Agent 프로젝트에서 Function Calling과 Tool Use를 활용해 에이전트가 자율적으로 행동하는 워크플로우를 구현한 경험이 있습니다. 처음에는 도구 설명을 모호하게 작성했더니 모델이 엉뚱한 도구를 선택하거나 아예 도구를 쓰지 않는 경우가 잦았습니다.
도구 설명에 언제 써야 하는지와 언제 쓰면 안 되는지를 명시하자 선택 정확도가 높아졌습니다. 파라미터 타입 정의를 명확히 하는 것도 중요했는데, 모델이 잘못된 타입의 값을 전달하면 런타임 오류가 발생했습니다. 도구 호출 결과를 다음 단계에 어떻게 전달하느냐도 최적화 지점이었는데, 전체 결과를 컨텍스트에 넣으면 비용이 늘어나서 핵심 정보만 추출해 전달하는 방식으로 개선했습니다. Tool Use 기반 에이전트는 도구를 잘 만드는 것보다 모델이 도구를 잘 이해하도록 설명하는 것이 성능을 결정한다는 결을 얻었습니다.
에이전트 최적화에서 병렬 도구 호출이 가능한 상황을 구조적으로 파악하는 것이 응답 시간에 가장 큰 영향을 줬습니다. 두 도구가 서로 다른 외부 API를 독립적으로 호출하는 경우 순차 실행하면 각 호출 지연이 더해지는데, 병렬 호출을 활성화하니 응답 시간이 기존의 60% 수준으로 줄었습니다. 이를 위해 도구 스키마 설계 시 의존성이 없는 도구끼리는 동시에 호출 가능하다는 힌트를 프롬프트에 명시했습니다. 토큰 예산도 측정 기준이 됐는데, 에이전트 루프에 최대 반복 횟수를 설정하지 않으면 모델이 도구를 불필요하게 반복 호출하는 경우가 생겼습니다.
최대 5회로 제한하니 비용이 줄고 응답도 빨라졌습니다. 도구 결과를 그대로 다음 프롬프트에 넣지 않고 핵심 필드만 추출해 넣으니 컨텍스트가 짧아져 다음 추론 품질도 유지됐습니다. 에이전트 최적화는 도구 호출 구조를 먼저 설계하고 측정하는 순서로 해야 한다는 것을 이 경험에서 얻었습니다.
에이전트가 존재하지 않는 인수를 만들어내는 문제를 처음 만났을 때 원인을 찾는 데 시간이 걸렸습니다. 모델이 Tool Use 호출 시 스키마에 없는 필드를 추가하거나 문자열이어야 할 값에 숫자를 넣는 환각(hallucinate)이 발생했는데, 도구 스키마의 description 필드를 상세하게 쓸수록 오류가 줄었습니다. "언제 이 도구를 써야 하는지"와 "어떤 값을 넣으면 안 되는지"를 description에 명시하니 잘못된 호출이 줄었습니다. 결과 검증 로직도 에이전트 루프에 추가했는데, 도구가 반환한 값이 예상 타입과 다르면 모델에게 재시도를 요청하는 방식이었습니다.
재시도는 최대 2회로 제한하고 그래도 실패하면 폴백 경로로 전환했습니다. 이 구조로 도구 호출 성공률이 눈에 띄게 높아졌습니다. 도구 스키마는 코드 구현보다 description 작성에 더 많은 시간을 써야 에이전트 품질이 올라간다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.