시리즈: MCP API 본질적 차이 연결표준 (총 7편) | 2회
API 기본 개념 총정리 — 소프트웨어가 소통하는 약속, 비개발자가 놓치는 오해 7가지
API는 서로 다른 소프트웨어가 정해진 규칙으로 기능과 데이터를 주고받는 약속이야. 개발자 전용 개념 같지만, 사실 기획자와 PM도 반드시 알아야 하는 기초 중의 기초지. 이 글에서 API의 본질과 흔한 오해 7가지를 깔끔하게 정리해볼게.
Summary
- API는 “서로 다른 소프트웨어가 정해진 방식으로 기능과 데이터를 주고받는 규칙(명세)”이야
- 비개발자 관점에서 API의 핵심 가치는 기능 재사용, 데이터 연계, 표준화된 협업 이 세 가지야
- API에 대한 흔한 오해 7가지를 바로잡는 게 MCP를 제대로 이해하는 전제 조건이야
- “API = 자동화의 전부” 같은 착각이 MCP 논의에서 혼동을 만드는 출발점이 되거든
이 글의 대상
- “API가 뭔지 대충은 아는데, 정확히 설명하긴 어려운” 비개발 직군
- MCP를 이해하기 전에 API 개념을 탄탄하게 잡고 싶은 기획자/PM
- API와 MCP의 차이를 혼동하지 않기 위한 기초를 쌓으려는 사람
목차
- API란 뭐야? — 한 문장 정의
- 비개발자가 알아야 할 API의 3가지 가치
- 가장 쉬운 비유: 식당의 주문 창구
- 또 다른 비유: 전기 콘센트
- API에 대한 흔한 오해 7가지
- 이 오해들이 MCP 이해에 왜 중요한가
API란 뭐야? — 한 문장 정의
한 줄 요약: API는 소프트웨어끼리 대화하는 규칙이야.
API(Application Programming Interface)를 한 문장으로 정리하면 이래:
“서로 다른 소프트웨어가 정해진 방식으로 기능과 데이터를 주고받는 규칙(명세)”
여기서 핵심 단어는 “정해진 방식”이야. 아무렇게나 소통하는 게 아니라, “어떤 주소로, 어떤 형식으로 요청하면, 어떤 형식으로 응답한다”가 미리 약속돼 있는 거지.
실무에서 API는 보통 이런 것들을 포함해:
| 구성 요소 | 설명 | 예시 |
|---|---|---|
| 엔드포인트 | 요청을 보낼 주소 | https://api.example.com/users |
| 요청 형식 | 어떤 데이터를 어떤 구조로 보낼지 | JSON 형태의 사용자 정보 |
| 응답 형식 | 어떤 데이터를 어떤 구조로 받을지 | JSON 형태의 처리 결과 |
| 인증 방식 | 누가 쓸 수 있는지 확인하는 방법 | API 키, OAuth 토큰 등 |
비개발자가 알아야 할 API의 3가지 가치
한 줄 요약: API가 실무에서 만드는 가치는 기능 재사용, 데이터 연계, 표준화된 협업이야.
1. 기능 재사용
결제, 지도, 로그인처럼 만들기 어렵고 유지보수 비용이 큰 기능이 있잖아. 이걸 처음부터 직접 만들 필요 없이, 외부 서비스가 제공하는 API로 가져다 쓸 수 있어.
예를 들어 우리 서비스에 결제 기능을 넣고 싶으면, 카드사/PG사의 결제 API를 연동하면 돼. 보안, 정산, 카드사 연동 같은 복잡한 걸 직접 구현할 필요가 없어지는 거지.
2. 데이터 연계
주문 정보, 재고 현황, 고객 데이터처럼 한 시스템에 있는 데이터를 다른 시스템이 실시간으로 읽고 쓸 수 있게 해줘.
쇼핑몰에서 주문이 들어오면 물류 시스템에 자동으로 배송 요청이 간다거나, CRM에서 고객 정보가 업데이트되면 마케팅 도구에 바로 반영되는 것도 다 API 연계 덕분이야.
3. 표준화된 협업
“어떤 주소로, 어떤 형식으로 요청하면, 어떤 형식으로 응답한다”가 문서로 고정돼 있으니까, 서로 다른 팀이나 서로 다른 시스템이 예측 가능한 방식으로 연결될 수 있어.
프론트엔드 팀과 백엔드 팀이 API 명세만 합의하면, 서로의 구현을 몰라도 독립적으로 개발을 진행할 수 있는 거지.
가장 쉬운 비유: 식당의 주문 창구
한 줄 요약: API는 식당의 메뉴판 + 주문 창구야.
API를 식당에 비유하면 딱 이해가 돼:
| 식당 | API |
|---|---|
| 메뉴판 | API 문서 (어떤 요청이 가능한지 정리) |
| 주문 창구 | 엔드포인트 (요청을 보내는 곳) |
| 주문서 작성 | 요청 (정해진 형식으로 데이터 전달) |
| 주방 | 서버 (내부에서 처리) |
| 음식 | 응답 (처리 결과) |
여기서 핵심은 주방 내부가 어떻게 돌아가는지 몰라도 된다는 거야. 메뉴판에 적힌 규칙대로 주문하면, 주방은 정해진 형태로 음식을 내줘. 이 “내부 구현을 몰라도 되는” 분리가 바로 API의 본질이야.
커피숍에서 “아메리카노 한 잔 주세요”라고 하면, 바리스타가 어떤 원두를 몇 도에서 추출하는지 우리가 알 필요 없잖아. 결과물(아메리카노)만 받으면 되는 거지. API도 완전히 같은 구조야.
또 다른 비유: 전기 콘센트
한 줄 요약: API는 기능과 데이터를 끌어오는 표준 연결부야.
전기 콘센트도 좋은 비유야. 한국에서는 220V / 60Hz라는 규격이 정해져 있잖아. 이 규격에 맞기만 하면 냉장고든, 노트북이든, 헤어드라이어든 다 꽂아서 쓸 수 있어.
API도 마찬가지야. “정해진 규격(엔드포인트, 인증, 데이터 형식)”에 맞추기만 하면, 어떤 앱이든 해당 서비스의 기능과 데이터를 가져다 쓸 수 있는 거지.
규격이 정해져 있으니까:
- 새 기기(앱)를 만들어도 콘센트(API) 규격에 맞추면 바로 연결돼
- 콘센트 뒤의 발전소 구조(서버 내부)를 몰라도 전기(데이터)를 쓸 수 있어
- 같은 콘센트에 다른 기기를 꽂을 수도 있어 (같은 API를 여러 앱이 사용)
API에 대한 흔한 오해 7가지
한 줄 요약: 이 7가지 오해를 바로잡아야 MCP 논의에서 헤매지 않아.
오해 1: “API = 화면(UI)이다”
사실: UI는 사람을 위한 인터페이스이고, API는 기계(다른 프로그램)를 위한 인터페이스야. 같은 서비스를 UI와 API 두 가지 방식으로 동시에 제공할 수 있어. 웹사이트에서 버튼 눌러서 날씨를 보는 건 UI, 다른 앱이 프로그래밍으로 날씨 데이터를 가져오는 건 API야.
오해 2: “API가 있으면 자동화가 끝난다”
사실: API는 자동화를 가능하게 하는 통로일 뿐이야. 자동화가 되려면 “어떤 조건에서 어떤 순서로 뭘 할지”라는 업무 규칙과 워크플로 설계가 따로 필요해. API가 있다고 자동으로 자동화가 되는 건 아니야.
오해 3: “API가 있으면 보안은 해결된다”
사실: API가 있다는 것과 그 API가 안전하다는 건 전혀 별개의 문제야. 인증(누구인지 확인), 인가(뭘 할 수 있는지 결정), 로깅(누가 뭘 했는지 기록), 레이트리밋(과도한 요청 차단)을 어떻게 설계하고 운영하는지가 보안의 핵심이야.
오해 4: “Function Calling = API다”
사실: 이건 반만 맞아. LLM의 Function Calling(모델이 함수를 호출하는 기능)은 강력하지만, 특정 모델 플랫폼에 종속되는 경우가 많아. 반면 API는 HTTP/JSON 같은 독립 표준으로 어디서든 재사용할 수 있지. 이 차이가 나중에 MCP를 이해할 때 아주 중요해져.
오해 5: “API는 복잡한 통합에만 필요하다”
사실: 단 하나의 엔드포인트만 있어도 큰 효용을 낼 수 있어. 예를 들어 단순한 날씨 조회 API 하나만으로도 여러 서비스에서 날씨 데이터를 활용할 수 있지. 규모가 커질수록 표준화가 더 중요해질 뿐, 작은 프로젝트에서도 API는 충분히 유용해.
오해 6: “API가 있으면 데이터 문제가 해결된다”
사실: API는 데이터에 접근하는 통로일 뿐이야. 데이터의 정합성(값이 맞는지), 버전(어느 시점 데이터인지), 정책(누가 어디까지 접근할 수 있는지) 같은 운영 설계는 완전히 별개의 문제야.
오해 7: “API를 만들면 모든 플랫폼과 바로 연결된다”
사실: API를 공개하면 연결 가능성은 높아지지만, 플랫폼별로 인증 방식, 호출 패턴, 응답 시간, 사용량 제한 등이 다 달라. 각 환경에 맞춘 추가 설계가 필요한 경우가 대부분이야.
이 오해들이 MCP 이해에 왜 중요한가
한 줄 요약: API에 대한 잘못된 기대가 MCP 논의를 엉뚱한 방향으로 끌고 가.
이 7가지 오해를 짚은 이유가 있어. MCP를 처음 접하는 사람들이 자주 하는 반응이 이래:
- “MCP는 더 좋은 API인가요?” → 아니야, 레이어가 달라
- “MCP 쓰면 자동화 다 되나요?” → API와 마찬가지로 통로일 뿐이야
- “MCP가 보안 문제를 해결하나요?” → 프로토콜이 보안을 자동 보장하진 않아
API에 대한 오해가 있는 상태에서 MCP를 보면, “MCP = 더 발전된 API”라는 단순한 프레임에 갇히게 돼. 그러면 MCP가 실제로 해결하려는 문제(표준화, 도구 발견, 운영 통제)를 놓치게 되지.
특히 오해 4번(Function Calling = API)이 중요해. Function Calling은 특정 모델 플랫폼에 종속된 구현이고, API는 플랫폼 독립적인 표준이야. MCP는 이 둘과 또 다른 위치에 있거든. 이 관계를 제대로 이해해야 다음 편(MCP 기본 개념)이 훨씬 쉬워져.
핵심 정리
1. API = 소프트웨어끼리 정해진 규칙으로 기능/데이터를 주고받는 약속.
2. 비개발자 관점 3대 가치: 기능 재사용 / 데이터 연계 / 표준화된 협업.
3. API는 자동화의 "통로"이지 "전부"가 아니야.
4. Function Calling ≠ API. 플랫폼 종속 vs 플랫폼 독립의 차이가 크지.
5. API에 대한 정확한 이해가 MCP를 제대로 이해하는 전제 조건이야.
FAQ
Q. API를 쉽게 한마디로 설명하면?
A. 소프트웨어끼리 대화하는 약속이야. “이렇게 요청하면 이렇게 응답한다”가 미리 정해진 규칙이라고 생각하면 돼.
Q. API는 개발자만 알면 되는 거 아니야?
A. 아니야. 기획자/PM도 API가 “뭘 가능하게 하는지”는 알아야 해. 어떤 기능을 외부 API로 해결할지, 어떤 데이터를 연계할지가 제품 기획의 핵심이거든.
Q. REST API, GraphQL이 뭔데?
A. API를 구현하는 방식(스타일)이 여러 가지 있는 거야. REST는 URL과 HTTP 메서드(GET/POST 등)로 요청하는 방식, GraphQL은 필요한 데이터만 골라 요청하는 방식이야. 핵심 개념은 동일하고 구현 스타일이 다른 거지.
Q. “API가 있으면 연동 끝”이라고 들었는데?
A. 오해 2번이야. API가 있으면 연동이 “가능해지는” 거지, “끝나는” 게 아니야. 인증 처리, 에러 핸들링, 데이터 매핑, 운영 모니터링 등 추가 작업이 항상 필요해.
Q. API와 MCP의 관계를 미리 알려줄 수 있어?
A. 아주 간단히 말하면, API는 “건물의 출입문”이고 MCP는 “AI가 여러 건물을 효율적으로 드나들 수 있게 만든 표준 출입증 시스템”에 가까워. 자세한 건 3편에서 다룰 거야.
Q. Function Calling은 API랑 완전히 다른 거야?
A. 완전히 다르다기보다, 겹치는 부분이 있지만 레벨이 달라. Function Calling은 “특정 AI 모델이 함수를 호출하는 기능”이고, API는 “소프트웨어 전반의 통신 규약”이야. Function Calling이 API를 호출할 수도 있고, 독립적으로 작동할 수도 있어.
참고 자료
| 출처 | 내용 | 링크 |
|---|---|---|
| MDN Web Docs | API 기본 개념 정의 및 설명 | developer.mozilla.org |
| IBM | API의 역할과 비즈니스 가치 해설 | ibm.com |
| Postman | API의 개념과 활용 가이드 | postman.com |
| Descope | Function Calling vs MCP 비교 | descope.com |
“API는 서로 다른 소프트웨어가 기능과 데이터를 정해진 규칙대로 주고받게 하는 약속이다.” — IBM, MDN
다음 편 예고
3편: MCP 기본 개념 — AI가 도구를 쓰는 표준 연결 방식에서는 MCP가 정확히 뭘 표준화하는지, 기존 플러그인/커넥터/Function Calling과 뭐가 다른지 정리할 거야. 이번 편에서 잡은 API 기초 위에 MCP를 올리면 훨씬 선명하게 보일 거야.