MCP 클라이언트를 직접 만들 때
왜 에이전트 서버가 핵심인가

도구라는 말은 편하지만 손에 잘 잡히지 않는다. 채팅창 뒤에 무엇이 있어야 MCP 클라이언트가 제대로 작동하는가.

도구라는 표현은 편하지만 초보자에게는 너무 뭉뚱그려져 있어서 손에 잘 안 잡힙니다. 그래서 여기서는 도구라는 말을 가능한 한 기능 단위로 풀어서 설명하겠습니다. MCP를 이해할 때 중요한 것은 추상적인 도구 개념이 아니라, 실제로 어떤 입력이 들어가고 어떤 처리가 일어나며 어떤 결과가 돌아오는지입니다.

예를 들어 사용자가 "김민수 과장 이메일 알려줘"라고 물었다고 하겠습니다. 이때 시스템 안에서 일어나는 일은 막연한 도구 사용이 아닙니다. 실제로는 다음 같은 처리가 일어납니다.

• 직원정보 테이블에서 이름이 김민수인 행을 찾습니다.
• 그 행의 직급이 과장인지 확인합니다.
• 이메일 컬럼 값을 꺼냅니다.
• 찾은 값을 모델에게 다시 넘깁니다.

즉, 여기서 말하는 기능은 "주소록 검색"이라는 추상 단어가 아니라, 더 구체적으로는 employee_name="김민수"를 입력으로 받아 직원 DB를 조회하고, 결과로 email="..." 값을 돌려주는 실행 단위입니다.

사용자가 "지난달 매출 감소 원인을 요약해줘"라고 물으면 마찬가지입니다. 여기서도 실제 내부 동작은 막연한 도구 호출이 아닙니다.

• 매출 테이블에서 지난달 데이터를 조회합니다.
• 전달 데이터와 비교합니다.
• 감소한 항목을 정렬합니다.
• 관련 회의록이나 메모를 찾습니다.
• 그 결과를 바탕으로 요약 문장을 생성합니다.

이처럼 MCP에서 말하는 것은 사실상 작은 기능 API들의 묶음이라고 보는 편이 더 정확합니다. 파일 목록 가져오기, 특정 문서 본문 읽기, 특정 기간의 매출 데이터 조회, 고객 ID로 주문 내역 조회, 노션 페이지 새로 생성하기, 이메일 초안 저장하기 같은 것들이 전부 여기에 들어갑니다.

따라서 MCP 서버를 만든다는 말은 거창한 무언가를 만든다는 뜻이 아니라, 이런 실행 가능한 기능들을 모델이 일정한 방식으로 호출할 수 있게 정리해 놓는다는 뜻입니다.

01  /  기능의 네 가지 유형직접 보이는 형태로 다시 설명하면

직접 만드는 MCP 시스템에서 모델이 사용할 수 있는 것은 대개 아래처럼 생긴 기능들입니다. 뭉뚱그린 "도구"가 아니라, 입력과 처리와 출력이 분명한 네 가지 결의 실행 단위로 나누어 보면 훨씬 또렷하게 보입니다.

1. 조회형 기능

이 종류는 어딘가에 이미 들어 있는 값을 읽어오는 기능입니다. 예를 들면 이런 것들입니다.

• get_employee_email(name)
• find_sales_data(month)
• read_file(path)
• search_notion(keyword)
• get_customer_orders(customer_id)

이 기능들은 입력값이 들어오면 저장소나 외부 시스템에서 값을 읽어서 반환합니다. 예를 들어 read_file(path)는 입력이 파일 경로이고, 출력은 파일 본문입니다. get_customer_orders(customer_id)는 입력이 고객번호이고, 출력은 주문 목록입니다.

2. 생성형 기능

이 종류는 새로운 결과물을 만드는 기능입니다. 예를 들면 이런 것들입니다.

• create_notion_page(title, content)
• draft_email(to, subject, body)
• generate_report(data)
• summarize_meeting_notes(text)

이 기능들은 단순 조회가 아니라 새 문서나 새 텍스트를 만듭니다. 예를 들어 create_notion_page는 제목과 본문을 입력받아 노션에 새 페이지를 생성합니다. draft_email은 받는 사람, 제목, 본문을 받아 이메일 초안을 저장합니다.

3. 실행형 기능

이 종류는 실제로 어떤 행동을 일으키는 기능입니다. 예를 들면 이런 것들입니다.

• send_email(draft_id)
• create_calendar_event(date, title)
• approve_request(id)
• run_python_code(code)
• start_batch_job(job_name)

이 기능들은 결과를 읽어오는 수준이 아니라 시스템 상태를 바꿉니다. 그래서 권한과 승인 통제가 중요합니다.

4. 변환형 기능

이 종류는 입력 데이터를 다른 형태로 바꾸는 기능입니다. 예를 들면 이런 것들입니다.

• extract_text_from_pdf(file)
• convert_excel_to_json(file)
• translate_text(text, lang)
• classify_document(text)
• extract_table_from_image(image)

이 기능들은 입력을 받아 가공한 뒤 새로운 구조의 결과를 돌려줍니다.

즉, MCP에서 모델이 다루는 것은 추상적인 마법 상자가 아니라, 실제로는 이런 개별 기능들입니다. 입력이 있고, 내부 처리 로직이 있고, 출력이 있는 아주 구체적인 실행 단위들입니다.

02  /  핵심그러면 왜 에이전트 서버가 핵심인가

이제 여기서 핵심이 보입니다. 사용자가 직접 MCP 클라이언트를 만든다고 했을 때, 실제 어려운 부분은 이 기능들을 화면에 예쁘게 보여주는 것이 아닙니다. 더 중요한 것은 사용자의 질문을 보고 어떤 기능을 언제 어떤 순서로 호출할지 결정하고, 그 결과를 다시 모델에게 넣어 최종 답을 완성하는 흐름을 통제하는 것입니다.

예를 들어 사용자가 "지난달 매출 감소 원인 정리해서 노션에 회의자료 초안까지 만들어줘"라고 말하면, 실제 내부 흐름은 대략 이렇게 됩니다.

• find_sales_data("지난달") 실행
• 전달 비교 데이터 조회 실행
• 감소 폭 큰 항목 정리
• 관련 회의록 검색 실행
• 검색 결과와 매출 결과를 합쳐 요약 생성
• create_notion_page(title, content) 실행
• 생성된 페이지 주소를 사용자에게 반환

여기서 중요한 것은 어느 한 기능이 아니라 이 전체 호출 흐름입니다. 이 흐름을 누가 관리하느냐가 핵심인데, 그 역할을 맡는 것이 에이전트 서버입니다.

즉, 직접 만드는 MCP 클라이언트에서 본질은 채팅창이 아니라 다음을 처리하는 서버입니다.

• 어떤 기능 목록을 현재 사용할 수 있는지 알고 있습니다.
• 사용자의 질문을 보고 필요한 기능 후보를 좁힙니다.
• 기능 호출에 필요한 입력값을 정리합니다.
• 여러 기능을 순서대로 실행합니다.
• 실패 시 재시도하거나 다른 경로로 우회합니다.
• 민감한 기능은 차단하거나 승인 절차를 거치게 합니다.
• 최종 결과를 사용자 문장으로 정리합니다.

이것이 없으면 화면은 있어도 제대로 동작하는 MCP 클라이언트가 되지 않습니다.

03  /  착시유명한 MCP 클라이언트가 왜 쉬워 보이는가

Claude Desktop이나 Cursor 같은 이미 완성된 제품은 이 중간 조정 계층이 이미 안에 들어 있습니다. 그래서 사용자는 마치 모델이 바로 MCP 기능을 쓰는 것처럼 느낍니다.

하지만 직접 만들 때는 다릅니다. 브라우저에 채팅창을 하나 띄운다고 끝나지 않습니다. 채팅창 뒤에서 다음을 담당하는 서버가 반드시 있어야 합니다.

• 연결된 MCP 서버 목록 관리
• 각 기능의 이름, 설명, 입력 형식 관리
• 모델 호출과 기능 호출 사이의 왕복 처리
• 대화 세션 저장
• 사용자별 권한 확인
• 호출 로그 저장
• 실패 상황 대응

이 계층이 바로 에이전트 서버입니다. 그래서 직접 만드는 MCP 클라이언트는 정확히 말하면 클라이언트를 만드는 작업이 아니라, MCP 기능들을 안전하고 순서 있게 실행시키는 에이전트 서버를 만들고 그 위에 화면을 얹는 작업에 가깝습니다.

04  /  정리아주 현실적인 기준으로 다시

직접 만드는 MCP 시스템에서 모델이 쓰는 것은 추상적인 도구가 아니라 아래 같은 실행 함수들입니다.

• 직원 이름으로 이메일 찾기
• 특정 월 매출 데이터 가져오기
• 파일 경로로 문서 본문 읽기
• 고객번호로 주문내역 조회하기
• 회의록 본문 요약하기
• 노션 페이지 만들기
• 이메일 초안 저장하기
• 일정 등록하기

그리고 에이전트 서버는 이 함수들을 적절한 순서로 조합해서 하나의 업무 흐름으로 만드는 계층입니다.

즉, 직접 만드는 MCP 클라이언트의 핵심은 채팅창이 아니라 함수 호출 흐름 제어기라고 이해하는 편이 훨씬 손에 잡힙니다.

05  /  한 줄 결론흐름 제어기가 먼저다

유명한 MCP 클라이언트는 이미 내부에 함수 호출 흐름 제어기가 들어 있어서 편해 보이는 것이고, 사용자가 생짜로 직접 만들 MCP 클라이언트는 결국 그 함수 호출 흐름 제어기 — 즉 에이전트 서버를 먼저 만들어야 제대로 작동합니다.

화면은 그다음입니다.