이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
멀티 에이전트 시스템을 처음 구현해본 것은 사이드 프로젝트에서였습니다. 에이전트 간 협업 프로토콜을 설계할 때 가장 먼저 고민한 것은 에이전트가 서로 어떤 형식으로 정보를 주고받을지였습니다. 구조화되지 않은 자연어 메시지만으로 소통하면 해석 오류가 생기기 쉬워, JSON 스키마로 메시지 형식을 정의하고 각 에이전트가 이를 검증하는 방식을 도입했습니다.
작업 위임 과정에서 에이전트가 서브태스크를 넘길 때 컨텍스트를 얼마나 포함할지가 성능과 비용에 영향을 줬습니다. 에이전트 하나가 실패했을 때 전체 워크플로우가 멈추지 않도록 오류 격리 구조도 필요했는데, 실패한 서브태스크만 재시도하거나 폴백 경로를 준비하는 방식으로 처리했습니다. 에이전트가 늘어날수록 어떤 에이전트가 무엇을 했는지 추적하는 로그가 중요해졌고, 관찰 가능성이 멀티 에이전트 시스템의 결임을 배웠습니다.
멀티 에이전트 시스템에서 에이전트 하나가 실패했을 때 전체가 멈추는 문제를 초기에 겪었습니다. 직렬 파이프라인으로만 구성했기 때문에 중간 에이전트의 오류가 이후 단계 전체를 막았습니다. Supervisor 에이전트가 Worker 에이전트의 상태를 모니터링하고 실패 시 재시도를 조율하는 구조로 바꾸니 개별 에이전트 실패가 전체를 멈추지 않게 됐습니다. 재시도 설계에서는 작업이 멱등(idempotent)하게 구성되어야 같은 작업을 두 번 실행해도 결과가 같다는 것을 확인했고, 이를 위해 중간 결과를 명시적으로 저장하는 구조를 추가했습니다.
처리 완료된 서브태스크를 기록해두니 중단 후 재개해도 이미 처리한 것은 건너뛰었습니다. 이 구조로 에러 복구에 드는 수작업이 줄고 전체 처리 시간도 안정화됐습니다. 멀티 에이전트 설계는 정상 흐름보다 실패 흐름을 먼저 설계해야 안정적이다는 것을 이 경험에서 배웠습니다.
멀티 에이전트 시스템에서 에이전트 간 컨텍스트를 어떻게 공유할지가 예상보다 큰 설계 문제였습니다. 각 에이전트가 독립적인 컨텍스트 창을 갖기 때문에, 한 에이전트가 발견한 정보를 다른 에이전트에게 전달하려면 명시적인 메커니즘이 필요했습니다. 구조화된 상태 저장소를 두고 에이전트가 작업 후 결과를 구조화 포맷으로 기록하는 방식을 도입했습니다. 자연어로 결과를 넘기면 다음 에이전트가 재해석하는 과정에서 정보가 손실되거나 변형됐는데, JSON 스키마로 결과를 정의하니 에이전트 간 정보 전달 정확도가 높아졌습니다. 토큰 예산도 공유 상태 설계에 영향을 줬는데, 모든 이전 에이전트 결과를 다음 에이전트 프롬프트에 넣으면 컨텍스트가 빠르게 가득 찼습니다. 관련 결과만 선택적으로 전달하는 필터 레이어를 추가하니 각 에이전트 호출 비용이 줄었습니다.
멀티 에이전트의 품질은 각 에이전트의 능력보다 에이전트 간 정보 전달 설계에서 결정된다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.