4. MCP와 서브에이전트
여러 AI/도구가 연결되는 시스템 구조
🧒
초딩
3장에서 "도구"라는 게 나왔잖아요. 근데 회사마다, 앱마다 도구가 다 다를 텐데 — 텔레그램 보내기, 구글시트 읽기, DB 조회하기... 이런 걸 다 하나하나 새로 만들어줘야 돼요?🧑💻
코딩천재
좋은 질문이야. 실제로 MCP가 나오기 전엔 그랬어 — AI 앱 A를 만드는 회사가 "구글시트 도구"를 직접 코딩하고, AI 앱 B를 만드는 회사도 똑같은 "구글시트 도구"를 또 직접 코딩하고. 도구 하나당 앱 개수만큼 중복 작업이 생기는 거지. 여기서 질문 — 이 중복을 없애려면 뭘 표준화하면 될까?🧒
초딩
도구를 "설명하는 방식"을 다 똑같이 맞추면... 아무 앱이나 그 설명만 보고 쓸 수 있지 않을까요?🧑💻
코딩천재
바로 그게 MCP(Model Context Protocol)야. "이 도구는 이런 이름이고, 이런 입력을 받고, 이런 결과를 준다"를 표준 형식으로 정의해두면, 그 형식을 이해하는 아무 AI 앱이나 그 도구를 가져다 쓸 수 있어. 구글시트 MCP 서버 하나만 잘 만들어두면, Claude Code든 다른 하네스든 다 같이 연결해서 쓸 수 있는 거지. 도구를 만드는 사람과, 그 도구를 쓰는 AI 앱을 만드는 사람이 분리되는 거야.💡 핵심
MCP는 "AI가 외부 도구/데이터에 연결하는 방식"을 표준화한 규격입니다. MCP 서버가 도구 목록과 사용법을 제공하면, MCP 클라이언트(Claude Code 같은 하네스)가 그걸 읽어서 모델에게 "이런 도구들을 쓸 수 있어"라고 알려줍니다. 3장의 "도구 호출"이 어디서 오는 도구인지를 관리하는 계층이라고 보면 됩니다.
🧒
초딩
그럼 "서브에이전트"는 또 뭐예요? 그냥 도구 중 하나예요?🧑💻
코딩천재
여기서 질문을 하나 해볼게 — 만약 메인 세션 컨텍스트 안에서, 파일 500개짜리 프로젝트를 처음부터 끝까지 다 읽어야 하는 조사 작업을 시킨다고 하자. 그 500개 파일 내용을 전부 메인 대화 텍스트에 쌓으면 어떻게 될까? (3장에서 배운 컨텍스트 윈도우 한도 기억나?)🧒
초딩
아 — 컨텍스트 윈도우가 꽉 차버리겠네요. 그럼 진짜 중요한 대화 내용이 밀려서 잘릴 수도 있고.🧑💻
코딩천재
정확해. 그래서 나온 해법이 서브에이전트야 — "이 조사 작업만 전담할 새로운 에이전트 루프를, 완전히 별도의 빈 컨텍스트 윈도우로 하나 띄워." 그 서브에이전트가 500개 파일을 자기 컨텍스트 안에서 다 읽고 조사한 다음, 결론 요약본만 메인 세션으로 돌려줘. 메인 세션은 500개 파일의 원본 내용이 아니라 "조사 결과 3줄 요약"만 받으니까 컨텍스트가 오염되지 않는 거지.🧒
초딩
그럼 서브에이전트를 여러 개 동시에 띄우면요?🧑💻
코딩천재
그게 바로 오케스트레이션이야. 메인 에이전트가 "지휘자" 역할을 하면서, 작업을 쪼개서 서브에이전트 여러 개에 동시에 맡기고(병렬 처리), 각각의 결과가 돌아오면 그걸 종합해서 다음 판단을 내리는 거지. "하네스 엔지니어링"이라고 부르는 게 바로 이 부분이야 — AI 모델 하나를 잘 쓰는 게 아니라, 여러 에이전트/도구/서버가 어떻게 역할을 나누고 통신하는지를 설계하는 일. 책 제목에 있는 "하네스"가 가리키는 게 바로 이 전체 배선(에이전트 루프 + 도구 호출 + MCP + 서브에이전트 오케스트레이션)이야.🧒
초딩
"스킬 시스템"이라는 말도 봤는데, 이것도 같은 맥락이에요?🧑💻
코딩천재
연결돼 있어. 매번 "이 회사 배포 절차는 이렇게 해" 같은 긴 설명을 대화 초반에 다 넣으면 컨텍스트 낭비지? 스킬은 그런 "특정 작업에 필요한 절차/지식 뭉치"를 파일로 미리 저장해두고, 관련 상황이 됐을 때만 그 내용을 컨텍스트에 불러오는 구조야. 필요할 때만 로드하니까 평소엔 컨텍스트를 안 잡아먹고, 필요한 순간엔 전문가 매뉴얼처럼 활용되는 거지.