이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
에이전트 기반 프로그래밍에 대한 이해는 LLM 기반 자동화 프로젝트를 직접 만들면서 쌓았습니다. 초반에는 단순 프롬프트 호출 수준이었는데, 에이전트가 상태를 가지고 환경과 상호작용하는 구조가 일반 LLM 호출과 어떻게 다른지를 ReAct 논문과 실습으로 이해했습니다.
도구 등록과 선택 로직이 에이전트의 핵심인데, 모델이 어떤 도구를 언제 쓸지 결정하는 과정에서 프롬프트 설계가 전체 성능을 좌우한다는 것을 직접 경험했습니다. 오류 복구 흐름이 가장 어려운 부분이었는데, 도구 호출이 실패했을 때 에이전트가 재시도할지 포기할지를 결정하는 로직을 만드는 것이 생각보다 복잡했습니다. 한계는 프로덕션 수준의 에이전트 운영 경험이 없고, 비용과 지연 시간을 관리하는 실전 감각이 아직 부족하다는 점입니다. 에이전트는 코드가 아니라 행동 흐름을 설계하는 것이 먼저라는 결을 배웠습니다.
에이전트 시스템을 만들다 보니 무엇이 잘못됐는지 디버깅하기 어려운 상황이 반복됐습니다. 단순 코드 버그와 달리 에이전트 실패는 어느 추론 단계에서 잘못된 도구를 선택했는지, 어느 시점에서 루프가 생겼는지를 추적해야 했습니다. 추론 경로를 로그로 남기는 구조를 추가하니 에이전트가 각 단계에서 무엇을 결정했는지 확인할 수 있었습니다. 도구 호출마다 입력과 출력을 기록해두니 어느 단계에서 잘못된 인수가 생성됐는지 역추적이 가능했습니다. 무한 루프 방지도 실제로 경험한 문제였는데, 에이전트가 같은 도구를 계속 호출하면서 빠져나오지 못하는 경우가 생겼습니다.
최대 반복 횟수를 설정하고 도구 호출 이력을 체크해 이미 시도한 것은 건너뛰는 로직을 추가했습니다. 허용 도구 화이트리스트도 중요한데, 에이전트가 설계 의도를 벗어난 도구를 호출하는 것을 방지하는 역할을 했습니다. 에이전트 시스템은 기능보다 관측 가능성을 먼저 설계해야 디버깅이 가능하다는 것을 배웠습니다.
에이전트 루프를 길게 돌릴수록 컨텍스트 창이 가득 차는 문제를 경험했습니다. 이전 도구 호출 결과를 전부 컨텍스트에 쌓으면 토큰이 빠르게 한도에 닿았고, 이후 추론 품질도 떨어졌습니다. 필요한 정보만 추출해서 요약된 형태로 상태를 유지하는 방식으로 바꾸니 긴 루프에서도 컨텍스트가 일정하게 유지됐습니다. 어떤 정보를 유지하고 어떤 정보를 버릴지 결정하는 것이 생각보다 어려웠는데, 현재 단계에서 필요한 정보와 이후 단계를 위해 보존해야 할 정보를 구분하는 기준을 만들었습니다. 비용 관리도 실제로 의식한 부분인데, 에이전트 루프가 예상보다 길어지면 API 비용이 선형으로 늘었습니다. 최대 반복 횟수와 함께 토큰 예산을 설정해두니 비용 범위 내에서 에이전트가 동작했습니다. 한계는 프로덕션 수준에서 비용과 지연 시간을 동시에 최적화하는 실전 경험이 아직 부족하다는 점입니다.
에이전트 상태 관리는 무엇을 기억하고 무엇을 버릴지가 전체 품질을 결정한다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.