이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
에이전트 개발에서 주로 활용한 플랫폼은 LangChain이었습니다. LLM 호출, 도구 연결, 메모리 관리를 추상화된 컴포넌트로 조합할 수 있어 복잡한 에이전트 흐름을 빠르게 프로토타이핑하는 데 유용했습니다.
벡터 DB와 연결해 RAG(검색 증강 생성) 구조를 구현했습니다. 사용자 질문과 관련된 문서를 먼저 검색하고 그 내용을 컨텍스트로 제공하면, LLM이 학습 데이터에만 의존하지 않고 최신 정보를 활용해 답변할 수 있었습니다.
배포 단계에서는 에이전트 응답의 일관성 유지가 어려웠습니다. 같은 입력에도 응답이 달라지는 경우가 있어 프롬프트 템플릿을 표준화하고 출력 파서를 추가해 응답 형식을 안정화했습니다. 덕분에 동일 입력에서 일관된 결과를 기대할 수 있었습니다.
AI 에이전트 설계 시 LangChain과 LlamaIndex를 비교 실험한 경험이 있습니다. 두 플랫폼 모두 도구 연결과 메모리 관리를 지원했지만, 복잡한 멀티스텝 에이전트 설계에서는 LangChain의 LCEL(LangChain Expression Language)이 파이프라인 가시성 측면에서 더 유리했습니다. 반면 문서 검색 중심의 단순 에이전트는 LlamaIndex의 인덱스 추상화가 개발 속도가 빨랐습니다. 저는 이 실험 결과를 기반으로 에이전트 복잡도와 검색 중심도를 기준으로 플랫폼을 선택하는 기준을 팀과 공유했습니다. 플랫폼 선택에서 가장 중요한 것은 기술 명성이 아니라 해결하려는 에이전트 패턴에 맞는 추상화 수준임을 이 경험에서 확인했습니다.
프로덕션에 배포한 AI 에이전트가 동일한 도구를 무한 반복 호출하는 루프에 빠지는 문제가 발생했습니다. 에이전트가 목표를 달성하지 못하면 같은 도구를 계속 재시도하는 패턴이었습니다. 저는 도구 호출에 최대 반복 횟수 제한을 추가하고, 동일 도구가 N회 이상 연속 호출되면 실패 상태를 반환하고 에이전트를 종료하는 가드레일을 설계했습니다. 추가로 각 도구 호출 결과를 실행 로그에 남겨, 루프 패턴이 발생하면 알림을 발송하도록 연결했습니다. 이 가드레일 도입 이후 루프로 인한 비정상 비용 발생이 0건으로 감소했습니다. 에이전트 배포에서 가장 중요한 것은 정상 경로 설계만큼 비정상 종료 조건을 명확히 정의하는 것임을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 MLOps 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.