API, MCP, Computer Use 개념 정리
바이브코딩 잡담 — API, MCP, Computer Use를 한 번에 정리하기
포토샵에 마우스를 쥐여줬더니 벌어진 일
얼마 전 재미로 AI에게 Computer Use만으로 포토샵을 조작해서 그림을 그려보게 한 적이 있다. 결과는 한마디로 형편없었다. 그런데 이 실패가 오히려 API, MCP, Computer Use 세 가지 기술의 차이를 아주 선명하게 보여주는 사례였다. 그래서 이번 글에서는 이 셋을 처음 접하는 사람도 감을 잡을 수 있도록 아주 기초부터 정리해보려 한다.
핵심을 한 문장씩 압축하면 이렇다.
· API = 프로그램끼리 정해진 규격으로 직접 대화하는 것
· MCP = AI가 여러 프로그램의 API·도구를 공통 방식으로 찾아 쓰게 해주는 연결 규격
· Computer Use = 그런 연결 통로가 없을 때 AI가 사람처럼 화면을 보고 마우스·키보드를 조작하는 것
흔히 쓰는 비유로 하면 API는 고속도로, Computer Use는 고속도로가 닿지 않는 마지막 골목길이다. 2026년 현재 OpenAI 역시 에이전트를 만들 때 웹 검색, 파일 검색, MCP, 컴퓨터 사용, 코드 실행 같은 도구들을 상황에 맞게 조합하는 방향으로 가고 있다.
1. API란 무엇인가 — 프로그램의 공식 주문 창구
API(Application Programming Interface)는 쉽게 말해 프로그램에 미리 만들어 놓은 공식 주문 창구다.
예를 들어 내가 운영하는 사내 업무 시스템에서 GPT에게 이런 일을 시킨다고 해보자.
“이 상담 내용을 분석해서 상담요약을 만들어.”
API가 없다면 사람이 직접 ChatGPT를 열고 → 내용을 붙여넣고 → 질문하고 → 결과를 복사해서 → 시스템에 다시 붙여넣어야 한다. 하지만 OpenAI API를 연결해두면 시스템 서버가 직접 통신한다.
사내 시스템 → OpenAI 서버 → GPT → 응답 → 사내 시스템화면을 클릭할 필요가 전혀 없다. API의 가장 중요한 특징은 구조화되어 있다는 것이다. 프로그램은 이런 식으로 정확하게 요청한다.
고객번호: 12345
업무: 상담요약
상담내용: "오늘 고객과 통화한 내용..."
출력형식: JSON그러면 결과 역시 이렇게 정리되어 돌아온다.
고객명: 홍길동
상담주제: 부가가치세
후속조치: 신고자료 요청
중요도: 높음그래서 API는 빠르고, 정확하고, 자동화하기 쉽고, 대량처리에 강하다. OpenAI의 Responses API도 모델에게 자체 도구뿐 아니라 개발자가 정의한 함수(function calling)를 제공해서 외부 시스템과 연결하도록 설계되어 있다.
그런데 API에는 큰 문제가 하나 있다
상대방이 API를 제공해줘야만 쓸 수 있다는 점이다. 예를 들어 어떤 사이트에 [로그인] [조회하기] [다운로드] [확인] 버튼만 있다고 해보자. 사람에게는 아무 문제가 없다. 마우스로 누르면 되니까. 그런데 공식 API가 없다면 프로그램은 난감해진다.
사람에게는 문이 있는데, 프로그램에게는 문이 없는 상태다.
그래서 예전 자동화에서는 Selenium, Playwright, RPA 같은 기술로 브라우저를 강제로 조작했다. 하지만 이것도 개발자가 “여기를 클릭 → 이 입력창에 입력 → 버튼 클릭 → 표의 3번째 열 읽기” 같은 절차를 일일이 코딩해야 했고, 화면이 조금만 바뀌어도 쉽게 깨졌다. Computer Use는 바로 여기서 큰 변화를 만든다.
2. MCP는 API와 무엇이 다른가 — AI용 공통 메뉴판
MCP(Model Context Protocol)는 API의 경쟁자가 아니다. 오히려 API 위에 AI용 공통 연결 규격을 하나 더 얹은 것에 가깝다.
예를 들어 GPT가 클라우드 저장소, 협업툴, 메신저, 사내 CRM, 세무자료 DB, Claude 등 여러 서비스와 연결되어 있다고 해보자. 각각 API 사용법이 전부 다르다. 기존 방식에서는 개발자가 이 모든 걸 따로따로 연결해야 했다.
MCP에서는 각 시스템이 AI에게 대략 이런 식으로 자신이 할 수 있는 일을 미리 알려준다.
나는 이런 도구가 있어.
- search_documents
- read_document
- create_document
- search_customer
- get_tax_data
- send_messageAI는 그것을 보고 “아, 지금 고객자료를 찾아야 하니까 search_customer를 써야겠구나”라고 스스로 판단한다. OpenAI Responses API도 현재 원격 MCP 서버와 MCP 도구를 지원하며, 문서에서 MCP 도구를 별도 범주로 다룬다.
API와 MCP의 관계를 비유하면
API는 각 가게의 주문 시스템이다. 중국집은 짜장면 주문 API, 은행은 계좌조회 API, CRM은 고객조회 API, 코드저장소는 코드조회 API — 전부 제각각이다. MCP는 AI에게 “여기 사용할 수 있는 가게들과 메뉴판이 있으니 필요한 메뉴를 네가 골라”라고 제공하는 AI용 통합 메뉴판 규격에 더 가깝다.
그래서 여러 시스템을 오가며 판단해야 하는 프로젝트에서는 MCP가 상당히 중요해질 수 있다. 예를 들면 이런 구조다.
사용자
↓
GPT
↓
MCP
├─ 법령검색
├─ 판례검색
├─ 내부문서
├─ Claude 호출
├─ 워드프레스
└─ 사내 CRM3. Computer Use란 무엇인가 — 눈과 손
여기서 완전히 다른 접근법이 등장한다. “API도 MCP도 없으면 그냥 사람이 하는 것처럼 해버리자”는 것이다. Computer Use에는 기본적으로 두 가지 능력이 결합된다.
눈 + 손
눈은 스크린샷·화면을 이해하는 비전 능력이고, 손은 마우스·키보드 조작이다. 그래서 AI가 화면을 보고 이런 흐름을 반복한다.
검색창 확인
↓
클릭
↓
검색어 입력
↓
Enter
↓
결과 확인
↓
스크롤
↓
다음 항목초기 OpenAI의 Computer Use 설명도 모델이 생성한 마우스·키보드 행동을 실제 환경에서 실행하는 구조였다. 지금은 이 개념이 더 확장되어, 에이전트가 Responses API·shell·실행 환경·파일시스템·네트워크·skills 등을 결합해 훨씬 긴 작업을 수행하는 구조로 설명된다.
4. 그런데 왜 포토샵 그림은 그렇게 형편없었을까
여기가 제일 재미있는 부분이다. 실험에서 AI는 아마 이런 식으로 작업했을 것이다.
화면 확인 → Brush 선택 → 색 선택 → 마우스 드래그 → 선 그림
→ 다시 화면 확인 → 다음 선 그림즉 정말로 마우스를 잡고 그림을 그린 것이다. 문제는 사람 일러스트레이터의 손이 사실 엄청난 정밀 제어 장치라는 데 있다. 사람은 그림을 그리면서 몇 초 안에도 손가락 압력, 손목 각도, 속도, 곡선, 선의 연결, 미세 위치, 명암, 형태까지 수백 번의 미세한 피드백을 한다.
Computer Use는 애초에 이런 작업에 최적화된 기술이 아니다. 대략 “화면 봄 → 판단 → 마우스 이동 → 클릭/드래그 → 새 화면 봄 → 다시 판단”이라는 비교적 굵은 단위의 피드백 루프이기 때문이다. 그러니 “그림은 그렸는데 아주 열악한 일러스트레이터 수준”이라는 결과는 오히려 자연스럽다.
같은 포토샵이라도 이런 작업은 잘한다
포토샵 열어.
image01.jpg 불러와.
이미지 크기를 1200×630으로 바꿔.
오른쪽 300px 잘라내.
제목 넣어. 글자 크기 42pt.
JPG 품질 85로 저장해.이런 작업은 훨씬 잘 해낼 가능성이 높다. 미세한 손재주가 아니라 UI 조작 문제이기 때문이다. 즉 포토샵 자체를 못 다루는 게 아니라, 포토샵에서 무슨 작업을 시키느냐가 관건이다.
Computer Use가 현재 특히 강한 분야
| 작업 | 적합도 |
|---|---|
| 웹사이트 검색 | ★★★★★ |
| 여러 페이지 조사 | ★★★★★ |
| 폼 입력 | ★★★★★ |
| 관리자 페이지 작업 | ★★★★☆ |
| 파일 다운로드/업로드 | ★★★★☆ |
| 엑셀 단순 입력 | ★★★★☆ |
| 반복 복사·붙여넣기 | ★★★★★ |
| 여러 앱 오가며 업무 | ★★★★★ |
| 포토샵 단순 편집 | ★★★☆☆ |
| 정밀 포토샵 디자인 | ★★☆☆☆ |
| 마우스로 일러스트 그리기 | ★☆☆☆☆ |
| 정교한 영상 타임라인 편집 | ★★☆☆☆ |
“AI가 무엇을 아느냐”와 “AI의 손이 얼마나 정교하냐”는 전혀 다른 문제다. AI가 디자인을 이해한다고 해서 마우스로 훌륭한 그림을 그릴 수 있다는 뜻은 아니다.
5. 이미지 생성 + Computer Use를 결합하면 이야기가 달라진다
Computer Use만 쓴다면 “포토샵 → Brush → 마우스로 그림”이 되어 비효율적이다. 반면 이렇게 하면 훨씬 강력해진다.
GPT → 광고 콘셉트 판단 → 이미지 생성 → 고품질 이미지 생성
→ Computer Use → 포토샵에서 열기 → 크기·텍스트·배치 수정 → 저장전문 도구에 일을 맡기고, Computer Use는 그 도구들을 연결하는 역할만 하는 것이다.
6. 우선순위: API → MCP → CLI/Shell → Computer Use
실제 에이전트를 설계한다면 대략 이런 순서로 이해하는 게 가장 현실적이다.
AI
│
┌───────┴───────┐
↓ ↓
API MCP
빠르고 정확 도구 연결
│ │
└───────┬───────┘
│
안 되는 작업
↓
COMPUTER USE
│
화면 직접 조작① API가 있으면 API를 쓴다 — 가장 빠르고 안정적이다.
② AI가 여러 도구를 자율적으로 골라 써야 한다면 MCP가 낫다.
③ 구조화된 연결 방법이 전혀 없을 때 비로소 Computer Use로 넘어간다.
사실 한 단계가 더 있다: CLI / Shell
AI 입장에서는 가능하다면 GUI보다 CLI가 훨씬 좋다. 예를 들어 파일 1,000개의 이름을 바꾼다고 해보자.
Computer Use: 파일 선택 → F2 → 이름 입력 → Enter → 다음 파일... (1,000번 반복)
CLI: 명령 한 번 → 끝OpenAI도 에이전트 환경에서 shell을 중요한 실행 수단으로 두며, 모델이 명령을 제안하고 실행 환경이 이를 수행한 뒤 결과를 다시 모델에 돌려주는 agent loop를 설명한다. 그래서 실제 우선순위는 대체로 API / 직접 도구 → MCP → CLI/Shell → Computer Use 순으로 생각하면 된다. 다만 이건 엄격한 계층이라기보다 “가능하면 구조화된 수단을 먼저 쓴다”는 원칙에 가깝다.
7. 실제 업무에 대입해보면
예를 들어 “이 고객의 이번 부가세 신고 준비해줘”라는 지시를 받았다고 하자. 미래의 에이전트는 하나의 방법만 고집하지 않는다.
고객정보 ↓ API
내부자료 ↓ DB/API
세금계산서 자료 ↓ API/MCP
내부 문서 ↓ File Search
필요한 계산 ↓ Code/Shell
외부 웹 자료 ↓ Web Search
API 없는 사이트 ↓ Computer Use
보고서 작성 ↓ Document tool
완료이것이 지금 말하는 에이전트의 본질에 가깝다. 모델 자체가 모든 일을 하는 게 아니라, 모델은 판단하고 적합한 도구를 골라서 일을 시킨다. OpenAI도 API 플랫폼을 모델에 context와 tools를 주어 실제 시스템에 걸쳐 행동하는 에이전트를 구축하는 플랫폼으로 설명한다.
포토샵에서 그 엉성한 그림만 보면 “별거 아니네?”라고 생각하기 쉽다. 그런데 잘못된 시험 종목을 준 셈이다. Computer Use에게 정말 무서운 시험은 이런 것이다 — “이 사이트에 들어가서 지난 3년간 자료를 찾아. 엑셀로 정리하고, 관련 PDF도 내려받아. 내용을 비교해서 이상한 것을 표시하고, 결과를 보고서로 만들어.” 사람에게는 지루해서 죽을 것 같은 2시간짜리 일이지만, Computer Use는 이런 작업에서 가치가 크다. 반대로 “포토샵에서 마우스로 아름다운 일러스트를 그려”는 사람에게도 고도의 숙련을 요구하는 일이다. AI에게는 이미지 생성이라는 훨씬 좋은 도구가 이미 있다.
8. 실제 사례: 정부 법령 API를 직접 붙여봤던 경험
예전에 세무 의견서 작성을 위한 법령 검색 자동화를 위해 법제처 API를 직접 받아서 연결한 적이 있다. 그 과정은 대략 이랬다.
API 신청 → 인증키 발급 → API 문서 확인 → 요청 URL 확인
→ 검색어·법령명·조문 등 파라미터 확인 → 응답 XML/JSON 처리
→ 필요한 값 추출 → AI가 사용할 수 있도록 함수 작성법제처는 데이터와 API를 제공했지만, 그걸 AI의 ‘손’으로 만들어주는 작업은 내가 직접 한 것이다.
그런데 만약 법제처가 공식 MCP 서버를 제공하면서 search_law, get_law_article, search_precedent, search_administrative_ruling, get_revision_history 같은 도구들을 각 도구의 입출력 규격까지 MCP로 공개했다면 어땠을까. MCP를 지원하는 AI에 그 서버를 연결한 뒤에는 이렇게만 말하면 됐을 것이다.
“창업중소기업 세액감면 관련 조특법 조문을 법제처에서 찾아봐.”
사용자 자연어
↓
AI: "법령 검색이 필요하군"
↓
MCP의 사용 가능한 도구 확인
↓
search_law 호출 → 검색 결과 확인
↓
"정확한 조문도 필요하군" → get_law_article 호출
↓
원문 확보 → 사용자에게 설명API URL이 뭔지, GET인지 POST인지, 파라미터 이름이 뭔지, XML인지 JSON인지 몰라도 된다. 물론 최초에 “이 AI가 해당 MCP 서버를 사용할 수 있도록 연결하고 인증·권한을 부여하는 작업” 정도는 여전히 필요하다.
한 문장으로 정리하면 — API 시대에는 내가 기관의 기계어를 배워 AI에게 그 기관을 사용할 수 있는 기능을 만들어줬다면, MCP 시대에는 그 기관이 AI가 이해할 수 있는 공통 규격으로 자기 기능을 내놓고, 나는 AI에게 그냥 “거기서 찾아봐”라고 지시할 수 있게 된다.
9. MCP도 결국 인증과 권한이 필요하다
MCP가 편해 보이지만, 인증(Authentication)과 권한(Authorization)이 사라지는 건 아니다. 법제처처럼 누구에게나 공개된 조회 기능이라면 인증이 없거나 API 키 정도로 충분할 수 있지만, 회사 내부 시스템을 MCP로 연결한다면 완전히 다른 이야기다.
AI
│
│ "이 고객의 신고자료 가져와"
↓
MCP Server
│
├─ 너는 누구인가? ← 인증(Authentication)
├─ 이 자료를 볼 권한이 있나? ← 권한(Authorization)
↓
내부 시스템
↓
고객 신고자료인증은 “너 누구야?”이고, 권한은 “네가 이걸 해도 돼?”다. 예를 들어 내부 시스템을 MCP로 연다면 대표자는 모든 고객을 조회·수정할 수 있고, 직원은 담당 고객만 조회할 수 있고, 외부 AI는 허용된 자료만 조회할 수 있고, 익명 사용자는 접근이 아예 안 되는 식의 통제가 여전히 필요하다.
MCP가 없애주는 건 보안이 아니라 다음과 같은 반복 작업이다.
❌ “이 서비스 API는 어떻게 호출하지? 파라미터는? 응답 형식은? AI에게 어떻게 Tool로 만들어주지?”
⭕ “이 MCP 서버를 연결한다 → 인증한다 → 이제 AI가 제공되는 Tool들을 이해하고 사용한다.”
비유하면 이렇다.
API는 각 부서의 전화번호와 통화방법까지 내가 직접 알아내서 연결하는 것이고, MCP는 회사가 AI용 종합 안내데스크를 만들어 놓은 것이다. 그 안내데스크에서도 “신분증 보여주세요”(인증)와 “확인됐습니다, 고객조회는 가능하지만 고객삭제는 안 됩니다”(권한)는 여전히 작동한다.
그리고 MCP가 편리해질수록 인증과 권한관리는 오히려 더 중요해진다. AI가 단순히 자료를 읽는 걸 넘어 여러 도구를 스스로 선택해서 실행할 수 있기 때문이다.
정밀도가 중요한 작업에는 여전히 API가 낫다
“MCP를 쓰면 데이터가 덜 정밀해지는 거 아닌가?”라는 생각이 들 수도 있는데, 정확히는 “MCP라서 정밀도가 떨어진다”기보다 “정밀성이 최우선인 작업에서는 AI의 판단 단계를 끼우지 않고 API를 직접 호출하는 편이 더 확정적”이라고 보는 게 맞다.
예를 들어 “이 고객의 2026년 매출 합계와 부가세를 정확히 가져와라”라는 작업이 있다고 하자. API를 직접 호출하면 개발자가 어떤 API를 호출하고 어떤 필드를 쓸지 미리 확정해놓기 때문에 AI가 해석할 여지가 거의 없다. 반면 MCP를 쓰면 AI가 “매출과 부가세를 원하는구나, get_sales_data를 써야겠다”고 스스로 판단해서 도구를 호출한다.
결국 그 도구 뒤에서 실행되는 건 똑같은 API이기 때문에 반환된 숫자 자체의 정밀도는 API든 MCP든 다를 이유가 없다. 차이는 그 앞단, 즉 “어떤 도구를 선택하고 어떤 인수를 넣을지”를 누가 정하느냐에 있다.
API 직접 연결: 개발자가 이 상황 → 이 API → 이 필드를 확정
MCP + AI: AI가 상황을 이해해서 어떤 Tool을 호출할지 판단 → Tool 뒤에서 API 실행그래서 실제 시스템은 둘 중 하나를 고르기보다 역할을 나누는 것이 좋다. AI/MCP에게는 “무엇을 해야 하는지”를 맡기고, API·DB·코드에는 “정확히 실행하고 계산하는 것”을 맡기는 것이다.
사용자
"이 고객의 작년 부가세 신고 검토해줘"
↓
AI — 무엇이 필요한지 판단
↓
MCP — 필요한 도구 발견·호출
↓
┌────────┼────────┐
↓ ↓ ↓
매출 API 매입 API 신고 API
↓ ↓ ↓
정확한 원시 데이터 반환
└────────┼────────┘
↓
AI — 분석·이상징후 판단
↓
검토보고서숫자를 만들어내거나 확정적인 데이터를 가져오는 일은 API/DB/계산 코드가 하고, 그 숫자가 무엇을 의미하는지 판단하고 다음에 무엇을 조회할지 결정하는 일은 AI가 맡는 것이 이상적이다. 세무처럼 금액·세율·신고값을 다루는 시스템이라면 특히 그렇다.
- 금액·세율·신고값·DB 저장 → API/코드 중심
- 자료 탐색·업무 선택·분석·설명 → AI + MCP 중심
“목적지와 운반할 물건이 정확히 정해져 있다면 굳이 수석 비서에게 판단을 맡길 필요 없이 전용 고속도로로 바로 보내는 게 낫다”는 말이 여기서 또 맞아떨어진다. MCP의 진짜 강점은 정밀한 API를 대체하는 데 있는 게 아니라, AI가 수많은 API와 도구 중 무엇을 언제 써야 할지 자연스럽게 연결할 수 있게 해주는 데 있다.
마무리
API는 AI에게 프로그램의 ‘직통전화’를 주는 것이고, MCP는 여러 직통전화를 AI가 알아서 골라 쓰게 만드는 ‘공통 교환망’이며, Computer Use는 전화번호 자체가 없는 곳에 AI가 직접 찾아가 사람처럼 문을 열고 일을 처리하게 만드는 기술이다.
앞으로 중요한 건 Computer Use 하나가 엄청나게 발전하는 것만이 아니다. 추론 + API + MCP + Shell + Web + File + 이미지 생성 + Computer Use가 한 에이전트 안에서 상황에 따라 섞이는 것이다. OpenAI의 최근 Responses API 방향도 바로 이쪽을 향하고 있다.
포토샵에서 직접 해본 그 볼품없는 실험은 꽤 의미가 있었다. “컴퓨터 유즈가 컴퓨터를 쓸 수 있다”는 것과 “컴퓨터에 설치된 모든 전문 프로그램을 전문가 수준으로 쓸 수 있다”는 완전히 다른 이야기라는 걸 직접 확인한 셈이니까. 그리고 여러 시스템을 오가는 자동화 프로젝트라면, Computer Use보다 API/MCP 기반 구조를 본체로 두고 Computer Use는 API로 뚫리지 않는 마지막 구간을 처리하는 보조 수단으로 두는 편이 훨씬 좋은 설계다.