책에 포함된 노트OpenAI Codex 활용법: IDE·CLI·클라우드에서 코딩 에이전트로 일하기

확장성: MCP와 Skills로 팀의 '반복 가능한 능력' 만들기

2026-03-23Views 9약 10분

Codex를 잘 쓰는 개인은 빠르게 늘지만, 팀 전체의 생산성이 같이 오르지는 않습니다. 이유는 간단합니다. 개인의 요령은 문서화되지 않고, 도구 연결은 사람마다 다르고, "이번엔 이렇게 했으니 다음에도 이렇게"라는 표준 절차가 남지 않기 때문입니다. Codex를 '개인 비서'에서 '팀 플랫폼'으로 바꾸는 핵심이 바로 MCP와 Skills입니다.

MCP는 에이전트가 외부 도구와 데이터를 일관된 방식으로 연결하는 표준이고, Skills는 그 도구들을 써서 반복 업무를 끝까지 밀어붙이게 만드는 "절차 패키지"입니다.¹⁶

MCP: 팀의 도구·문서·데이터를 한 번에 연결하는 표준

MCP(Model Context Protocol)는 LLM 애플리케이션이 외부 도구(tools)와 컨텍스트(resources)를 표준 방식으로 제공/호출하도록 정의한 오픈 프로토콜입니다.¹ 여기서 중요한 건 "무엇을 연결하느냐"가 아니라 "연결 방식이 표준화된다"는 점입니다. 팀이 갖고 있는 데이터 소스(문서, 디자인 시스템, 로그, 이슈 트래커, DB, 배포 플랫폼)가 늘어나도, MCP 서버만 있으면 Codex 같은 호스트(클라이언트)는 같은 규약으로 붙습니다.²

MCP의 기본 구조는 다음과 같습니다.

Host(호스트): Codex/IDE/채팅 앱처럼 사용자가 대화하는 애플리케이션
Client(클라이언트): 호스트 내부의 커넥터. 각 MCP 서버와 1:1 연결을 유지
Server(서버): 도구/리소스/프롬프트 등을 노출하는 서비스

이 구조 덕분에 팀은 "도구별 커스텀 통합"을 매번 만들지 않고도, MCP 서버 단위로 기능을 추가/교체할 수 있습니다.²

MCP가 제공하는 4가지 확장 포인트: Tools, Resources, Prompts, Apps

MCP를 도구 호출만으로 이해하면 절반만 보는 것입니다. VS Code 문서가 정리하듯 MCP 서버는 보통 네 가지 능력을 제공합니다.³

첫째, Tools는 부작용(side effect)이 가능한 실행 단위입니다. 예를 들어 GitHub 이슈 생성, 브라우저 자동화, DB 쿼리 실행 같은 작업이 여기에 들어갑니다.¹³

둘째, Resources는 읽기 전용 컨텍스트입니다. "이 문서/테이블/응답을 프롬프트에 첨부한다"에 가깝고, 에이전트가 판단을 더 정확하게 하도록 돕습니다.³

셋째, Prompts는 서버가 제공하는 프롬프트 템플릿입니다. 팀이 자주 하는 질문/작업을 템플릿으로 배포해, 누구나 같은 품질로 시작하게 만듭니다.³

넷째, MCP Apps는 채팅 안에서 폼/시각화 같은 UI를 렌더링해 상호작용을 풍부하게 만드는 방식입니다.³

팀 관점에서 보면, Tools는 '손', Resources/Prompts는 '근거와 시작점', Apps는 '입력 UI'입니다. Skills는 이 위에 '절차'를 얹습니다.

로컬 vs 원격 MCP 서버: 팀 표준을 어디에 둘 것인가

MCP 서버는 로컬 프로세스로 띄울 수도 있고(예: stdio), HTTP/SSE나 WebSocket 같은 원격으로 붙을 수도 있습니다.¹ 무엇을 선택하느냐는 단순히 편의성 문제가 아니라, 팀 표준화의 위치를 결정합니다.

로컬 MCP는 개발자가 직접 설치하고 실행하니 빠르고 통제감이 좋습니다. 반면 팀마다 설정이 달라지기 쉽고, 업데이트가 분산됩니다. 원격 MCP는 구성과 업데이트를 중앙에서 관리하기 쉬워 팀 일관성이 올라가지만, 네트워크/인증/감사 같은 운영 요소가 필수로 따라옵니다. AWS의 MCP 서버 가이드는 이 차이를 "개발/테스트·프라이버시·지연"과 "협업·상시 가용성·자동 업데이트"의 트레이드오프로 설명합니다.⁴

실무적으로는 보통 이렇게 출발합니다.

파일 시스템/로컬 테스트/브라우저 자동화처럼 개발자 PC에 붙어야 하는 것은 로컬
문서 검색/사내 API/관측(로그·메트릭)처럼 팀이 공유해야 하는 것은 원격
무거운 작업(대규모 검색/분석)은 원격으로 오프로딩

이때 조직이 커질수록 "누가 어떤 MCP를 쓸 수 있는가"가 문제가 됩니다. Azure API Center 기반의 MCP Center처럼 '사내 MCP 레지스트리'를 두고, 승인된 서버만 카탈로그화하는 방향이 자연스럽습니다.⁵

Codex에서 MCP 서버를 표준 구성으로 묶기

VS Code: mcp.json으로 팀 설정을 공유한다

VS Code는 MCP 서버를 확장 갤러리로 설치하거나, 워크스페이스의 .vscode/mcp.json으로 구성할 수 있습니다.³ 팀 표준화를 하려면 핵심 MCP는 워크스페이스에 두고 버전 관리에 포함시키는 편이 좋습니다.

예를 들어 GitHub(원격) + Playwright(로컬)를 함께 쓰는 최소 구성은 이렇게 생깁니다.³

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    }
  }
}

여기서 중요한 운영 원칙은 두 가지입니다.

첫째, 비밀값(API Key 등)을 파일에 하드코딩하지 말 것입니다. VS Code 문서도 input 변수나 환경 파일 사용을 권장합니다.³

둘째, 서버 신뢰(trust)와 샌드박스를 표준 프로세스로 넣는 것입니다. 로컬 MCP는 임의 코드를 실행할 수 있어 신뢰 확인이 필수이며, macOS/Linux에서는 sandboxEnabled로 파일/네트워크 접근을 제한할 수 있습니다.³

서버 타입을 표준 용어로 맞춘다

MCP 연결 방식은 크게 세 갈래로 정리할 수 있습니다. 로컬 프로세스(stdio), HTTP/SSE, WebSocket입니다.¹ 팀 문서에서 이 용어를 그대로 쓰면, "이 MCP는 로컬이야/원격이야/스트리밍이야"가 한 문장으로 정리됩니다.

보안과 감사: '연결'이 아니라 '노출'을 관리한다

팀이 MCP를 도입할 때 가장 흔한 실패는 "편해서 다 붙였다"입니다. 특히 제3자 MCP를 붙이면 프롬프트 내용 같은 데이터가 외부로 전달될 수 있고, 과금/보관 정책도 서비스 제공자 조건을 따르게 됩니다.¹

따라서 팀 표준에는 다음이 반드시 들어가야 합니다.

어떤 MCP 서버를 추가했는지, 누가 승인했는지 기록
서버별로 전달되는 데이터의 범위(프롬프트, 리소스, 로그)를 정의
인증 헤더/토큰은 가능하면 런(run) 단위로 주입하고 영구 저장을 피함

Microsoft Agent Framework 문서는 헤더를 tool_resources에 포함해 현재 실행에만 적용하고, 서버에 영구 저장되지 않게 하라고 강조합니다.¹

Skills: "프롬프트와 도구 사이"의 반복 절차를 패키징한다

도구를 붙였는데도 팀 성과가 들쭉날쭉하다면, 문제는 도구가 아니라 절차입니다. OpenAI는 Skills를 "프롬프트(상시 동작)와 도구(원자적 능력) 사이의 중간 레이어"로 정의합니다. 즉, Skills는 필요할 때만 마운트되어 실행되는 반복 가능한 절차(지시 + 스크립트 + 자산)입니다.⁶

Skills를 도입하면 다음이 달라집니다.

"무엇을 할지"가 아니라 "어떤 순서로, 어떤 산출물을, 어떤 검증을 거칠지"가 코드/문서로 남습니다.
개인이 잘하는 일을 '복제'가 아니라 '설치'로 팀에 배포할 수 있습니다.
MCP 도구 호출을 절차 안에 넣어, 지식(가이드)과 실행(툴)이 어긋나지 않게 만듭니다.

이 패턴을 잘 보여주는 예가 Azure Skills Plugin입니다. 이 플러그인은 Azure 작업을 위한 Skills(워크플로·가드레일)과 Azure/Foundry MCP 서버(실행 도구)를 한 번에 묶어 배포합니다.⁷⁸

Skills의 기본 구성: 문서, 스크립트, 테스트, 그리고 연결 정보

Skills는 형식이 한 가지로 고정된 '제품'이 아니라, 팀이 재사용 가능한 절차를 담는 '패키지'입니다. 다만 팀 운영을 위해서는 최소한의 구성 규칙이 필요합니다.

Microsoft의 microsoft/skills 저장소는 실전 운영에 가까운 힌트를 줍니다. 스킬을 선택적으로 설치하고(과도한 로딩은 컨텍스트를 희석시키므로), 에이전트 디렉터리에 배치하며, 여러 에이전트 호스트를 쓴다면 심볼릭 링크로 공유하는 방식도 권장합니다.⁹

예를 들어, 팀 규약을 다음처럼 잡을 수 있습니다.

.github/skills/
  plan-generator/
    SKILL.md
    prompts/
    scripts/
    tests/
    assets/
  pr-reviewer/
    SKILL.md
    prompts/
    scripts/
    tests/
    assets/

핵심은 "스킬이 늘어나도 팀이 관리할 수 있게" 만드는 것입니다. 스킬 하나에는 적어도 다음이 있어야 합니다.

입력: 어디까지 읽고(레포/문서/이슈), 어떤 제약으로(시간/범위/권한) 실행하는지
절차: 단계(Plan → Do → Check 같은)와 각 단계의 완료 조건
산출물: PR 템플릿, 계획서, 리뷰 코멘트, 체크리스트 등 파일/형식
검증: 최소한의 테스트(예: golden file 비교) 또는 휴먼 승인 지점

팀 표준 작업을 Skills로 패키징하는 3가지 설계 예시

이제부터는 "우리 팀이 반복하는 일"을 스킬로 쪼개는 방법을 설계합니다. 목표는 거창한 자동화가 아니라, 항상 같은 순서로 같은 결과물을 내는 것입니다.

1) 계획 생성(Plan 생성) 스킬

이 스킬의 목적은 '할 일 목록'이 아니라 합의 가능한 계획 문서를 만드는 것입니다. 즉, Codex가 혼자 결정하지 못하게 하고, 사람이 판단해야 할 지점을 명확히 표시합니다.

구성은 보통 이렇습니다.

입력: 변경 요청(이슈 링크/요구사항), 레포 구조, 관련 문서 리소스(MCP Resources)
절차: 영향 범위 탐색 → 작업 분해 → 위험/롤백 → 테스트 전략 → 실행 순서
산출물: PLAN.md(스코프, 단계별 체크박스, 예상 커밋 단위)

이때 MCP가 필요한 지점이 분명합니다. 예컨대 GitHub MCP로 이슈/PR/최근 커밋을 읽고, 문서 MCP로 사내 규약을 근거로 붙입니다.¹³

2) PR 리뷰 스킬

PR 리뷰는 '코드를 읽는 능력'보다 '어떻게 리뷰할지의 기준'이 더 중요합니다. 스킬로 만들면 기준이 팀 자산이 됩니다.

입력: PR diff, 관련 이슈, 팀 코딩 규약 문서
절차: 목적 일치 확인 → 위험 변경 탐지(권한/보안/데이터) → 테스트 적합성 → 롤백 가능성
산출물: 리뷰 코멘트 + "승인/보류/차단" 결론(근거 포함)

여기서 스킬은 "리뷰 프롬프트"를 길게 만드는 게 아니라, 검사 순서와 필수 질문을 고정하는 역할을 합니다. 실제 정보 수집은 MCP 도구가 담당하고, 결론 작성은 에이전트가 담당합니다.

3) 배포 전 검증(Preflight) 스킬

배포 전 검증은 자동화가 가장 큰 효과를 내는 영역이지만, 동시에 사고가 가장 위험한 영역입니다. 따라서 스킬은 보통 "자동 실행 + 승인 지점"을 함께 설계합니다.

입력: 배포 대상, 환경(dev/stage/prod), 변경 로그
절차: 빌드/테스트 실행 → 설정 차이 확인 → 마이그레이션 점검 → 관측 지표 준비
산출물: PRECHECK.md + 실행 로그 링크

Azure Skills Plugin이 "validate"를 별도 스킬로 제공하는 것도 같은 이유입니다. 배포는 결국 의사결정 문제이고, 검증은 그 의사결정을 안전하게 만드는 절차이기 때문입니다.⁷⁸

MCP + Skills를 합치는 운영 모델: '능력 레이어'를 버전으로 배포한다

개념을 한 문장으로 정리하면 이렇습니다.

MCP는 "무엇을 할 수 있는가(도구/컨텍스트)"를 확장한다.¹³
Skills는 "그걸 어떤 순서로, 어떤 기준으로 할 것인가(절차)"를 고정한다.⁶

이 둘을 결합하면, 팀은 Codex 사용법을 사람마다 교육하는 대신 능력 레이어를 배포하게 됩니다. Azure Skills Plugin이 "이건 프롬프트 팩이 아니라, 스킬(브레인)과 MCP(핸즈)를 정렬한 패키지"라고 강조하는 이유도 여기에 있습니다.⁷⁸

배포 전략: 레지스트리, 저장소, 그리고 실행 환경

사내 MCP 서버를 '제품'처럼 운영하기

사내 API나 도메인 지식을 MCP 서버로 만들면, Codex뿐 아니라 MCP를 지원하는 다른 클라이언트에서도 재사용됩니다. 그리고 이 서버는 내부 시스템의 일부가 되므로, 앱 플랫폼에 올려 운영하는 선택지가 필요합니다.

Azure App Service는 애플리케이션을 MCP 서버로 호스팅하는 시나리오를 명시적으로 지원하며, AI 도구/에이전트가 비즈니스 로직에 접근하도록 확장하는 방법으로 MCP를 언급합니다.¹⁰

즉, 팀이 "사내 결제 API를 도구로 쓰고 싶다"를 넘어서 "사내 결제 정책/권한/감사를 포함한 MCP 서버"로 만들기 시작하면, Codex는 도구 호출의 인터페이스가 아니라 업무 플랫폼의 클라이언트가 됩니다.

스킬 배포는 '선택 설치'와 '버전 고정'이 기본

스킬을 잔뜩 설치해두면 좋아 보이지만, 실제로는 컨텍스트가 오염되고(스킬 간 규칙 충돌), 에이전트가 집중할 기준이 흐려집니다. microsoft/skills도 모든 스킬을 로드하지 말고, 프로젝트에 필요한 것만 선택하라고 경고합니다.⁹

팀 표준은 다음처럼 잡으면 안정적입니다.

기본 스킬(Plan/Review/Preflight)만 전사 공통으로 제공
도메인 스킬(AWS 운영, Azure 배포, 모바일 릴리즈 등)은 팀/레포 단위로 선택 설치
스킬 업데이트는 릴리즈 노트와 함께 PR로 반영(사람이 리뷰)

팀 플랫폼으로 확장하기 위한 체크리스트

MCP와 Skills를 "설치"에서 "운영"으로 끌어올리려면, 아래 질문에 답이 있어야 합니다.

MCP 서버는 어떤 분류로 관리할 것인가. 로컬/원격, 1급(전사) / 2급(팀) / 실험용 같은 티어가 필요한가.⁴⁵
인증 정보는 어디서 주입하고, 어떤 로그를 남길 것인가. 런 단위 헤더 주입과 감사 로그 정책이 있는가.¹
스킬은 어떤 산출물을 강제할 것인가. Plan/Review/Preflight가 남기는 파일 형식과 저장 위치가 합의됐는가.
스킬 변경은 어떻게 검증할 것인가. 최소 테스트(골든 파일 등)와 PR 리뷰 규칙이 있는가.
도구 호출은 어디까지 자동 승인할 것인가. 샌드박스/승인 모드를 어떤 기준으로 나눌 것인가.³

이 체크리스트가 준비되면, Codex는 더 이상 "잘 쓰는 사람이 잘 쓰는 도구"가 아니라, 팀의 표준 능력을 설치하고 업데이트하는 플랫폼 엔드포인트가 됩니다.

참고

¹Using MCP tools with Agents

²microsoft/mcp: Catalog of official Microsoft MCP server implementations

³Add and manage MCP servers in VS Code

⁴Welcome to Open Source MCP Servers for AWS

⁵MCP Center - Build Your Own Enterprise MCP Registry

⁶Skills in OpenAI API

⁷microsoft/azure-skills: Azure Skills Plugin

⁸Announcing the Azure Skills Plugin

⁹microsoft/skills: Skills, MCP servers, Custom Agents

¹⁰Integrate AI into your Azure App Service applications

책 목록

OpenAI Codex 활용법: IDE·CLI·클라우드에서 코딩 에이전트로 일하기

전체 목차 보기