MCP·에이전트·오케스트레이터는 각각 무엇인가 — 세 층위 구분하기

“MCP로 에이전트를 만들었다”, “오케스트레이터가 에이전트를 부른다” 같은 문장에서 세 단어는 자주 뒤섞인다. 하지만 이들은 경쟁 관계가 아니라 서로 다른 층에 있다. 층을 나눠 보면 관계가 선명해진다.

MCP — 도구를 공급하는 규격

MCP는 행위자가 아니다. LLM에게 도구·리소스·프롬프트를 넘겨주는 표준 규격이다. “이런 도구가 있고, 인자는 이렇게 생겼다”를 서버가 선언하면, 그걸 읽어들이는 쪽이 목록에 얹어 쓴다.

MCP 자체는 아무것도 스스로 결정하지 않는다. 도구를 제공할 뿐, 언제 어떤 도구를 부를지는 정하지 않는다. 콘센트 규격에 비유할 수 있다. 규격은 전기를 흐르게 할 통로를 표준화하지만, 무슨 가전을 언제 켤지는 결정하지 않는다.

에이전트 — 스스로 도구를 고르는 행위자

에이전트는 모델 + 루프다. 목표를 받아, 스스로 “지금은 이 도구를 불러야겠다”고 판단하고, 결과를 관찰해 다음 수를 두는 것을 목표에 도달할 때까지 반복한다.

목표 → 모델이 도구 선택 → 실행 → 결과 관찰 → 다시 판단 → ... → 완료

여기서 에이전트가 고를 수 있는 도구 목록을 채워주는 통로 중 하나가 MCP다. 즉 MCP는 에이전트가 쓰는 재료이지, 에이전트와 같은 층이 아니다. 도구가 코드에 직접 박혀 있든 MCP 서버로 붙든, 에이전트 입장에서는 “부를 수 있는 능력”이라는 점에서 같다.

오케스트레이터 — 여러 단계·행위자를 지휘

일이 커지면 에이전트 하나로는 벅차다. 코드베이스 전체를 감사하거나, 여러 관점에서 교차 검증하려면 작업을 쪼개서 여러 에이전트에 나눠주고, 결과를 다시 모아야 한다. 이 지휘 역할이 오케스트레이터다.

• 큰 작업을 하위 작업으로 분해한다
• 각 조각을 워커 에이전트에 배분한다(병렬 가능)
• 나온 결과를 취합·검증해 최종 산출물로 합친다

오케스트레이터는 보통 그 자체도 LLM으로 판단하거나, 정해진 스크립트로 흐름을 고정한다. 핵심은 개별 에이전트보다 한 층 위에서 흐름을 관리한다는 점이다.

한 문장으로

세 층은 이렇게 겹쳐 있다.

오케스트레이터가 에이전트들을 지휘하고, 각 에이전트는 MCP로 받은 도구를 골라 쓴다.

MCP는 재료를 대는 규격, 에이전트는 그 재료로 스스로 일하는 행위자, 오케스트레이터는 여러 행위자를 조율하는 지휘자다. 뒤섞이던 세 단어가 각자 다른 높이에 있다는 것만 잡아도 설계 대화가 한결 또렷해진다.