
학습목표 / 사전지식: 이 레슨의 목표는 Codex에서 Plugins를 업무 패키지처럼 이해하고, 그 패키지를 기준으로 5개 앱이 이어지는 Make 워크플로 초안을 만들 수 있게 되는 것입니다. 선수지식은 없어도 되지만, “한 앱에서 나온 값을 다음 앱에 넘긴다”는 감각만 있으면 충분합니다.
Plugins는 Skills, 앱 연동, MCP 서버 설정을 한데 묶는 번들이며, 공식 설명의 핵심 문구는 “bundle skills, app integrations, and MCP server configuration”입니다. [OF-17]
Plugins는 2026년 3월 25일 정식 기능으로 제시되었고, plugin.json 매니페스트를 중심으로 구성됩니다. [OF-17]
용어부터 풀어보겠습니다. Skill이 “일을 처리하는 방법서”라면, 앱 연동은 외부 앱과 대화하는 통로이고, MCP 서버 설정은 그 통로를 어떤 방식으로 열지 적어 둔 연결 메모쯤 됩니다. [OF-17]
매니페스트는 여행 가방에 붙은 물품 목록표를 떠올리면 쉽습니다. plugin.json이 바로 그 목록표여서, 이 플러그인 안에 어떤 Skill과 앱 연동과 MCP 서버 설정이 들어 있는지를 한눈에 알려 줍니다. [OF-17]
이번 실습의 비유는 “사무실 컨베이어 벨트”입니다. 첫 앱에서 접수된 일이 다음 앱으로 넘어가고, 그 결과가 다시 다음 앱으로 전달되며, 마지막에는 사람이 바로 처리할 수 있는 실행 단위로 정리됩니다.
Codex에서 새 작업을 열고, 이번 클립의 기능을 Plugins로 잡습니다. Plugins는 Skills, 앱 연동, MCP 서버 설정을 묶는 기능이므로, 화면에서는 “어떤 일을 시킬지”, “어떤 앱을 연결할지”, “어떤 MCP 설정을 쓸지”를 나눠 확인하는 흐름으로 설명합니다. [OF-17]
촬영 화면에서는 왼쪽에 Codex 입력창, 오른쪽에 Make 시나리오 편집 화면을 나란히 둡니다. Codex는 설계서를 만드는 책상, Make는 그 설계서를 실제 순서로 놓는 작업대라고 설명하면 초보자가 덜 헷갈립니다.
그다음 5개 앱이 맡을 역할을 정해 둡니다. App 1이 시작 신호를 받으면 App 2가 자료를 확인하고, App 3이 기록을 남기며, App 4가 알리고, App 5가 후속 실행으로 마무리하는 식입니다.
1단계, Codex에 워크플로 설계를 요청합니다. 입력창에는 “5개 앱 연동”, “Make에서 실행”, “각 단계의 입력값과 출력값”, “실패 처리”를 반드시 넣습니다.
2단계, Codex가 만든 표에서 앱별 역할을 확인합니다. 이때 앱 이름보다 중요한 것은 “이 단계가 무엇을 받아서 무엇을 넘기는가”입니다.
3단계, Make에서 새 시나리오를 열고 첫 모듈을 시작 신호로 둡니다. 시작 신호에는 요청 제목, 요청 본문, 요청자, 접수 시간을 테스트 값으로 넣습니다.
4단계, 두 번째 앱은 자료 확인 역할로 배치합니다. 요청 제목이나 본문에서 찾을 키워드를 뽑아 자료 위치를 찾는 흐름으로 잡습니다.
5단계, 세 번째 앱은 기록 역할로 배치합니다. 기록에는 요청 요약, 자료 위치, 담당자 확인란, 다음 행동을 넣습니다.
6단계, 네 번째 앱은 알림 역할로 배치합니다. 알림 메시지는 요청명, 기록 링크, 자료 위치, 다음 행동 네 줄로 제한합니다.
7단계, 다섯 번째 앱은 후속 실행 역할로 배치합니다. 제목은 요청명을 쓰고, 본문에는 기록 링크와 자료 위치를 넣어 실행자가 다시 찾는 시간을 줄입니다.
8단계, 다시 Codex로 돌아와 운영 검수를 요청합니다. 검수 기준은 중복 실행, 권한 오류, 빈 값, 알림 과다, 제목 충돌로 잡습니다.
아래 프롬프트는 앱 이름만 바꿔 바로 쓸 수 있는 설계 요청문입니다.
너는 업무 자동화 설계자다.
Make에서 실행할 5개 앱 연동 워크플로를 설계해줘.
업무 목표:
- [예: 고객 요청을 접수해 자료를 찾고, 기록하고, 알리고, 후속 실행으로 넘긴다]
연동 앱과 역할:
- App 1: [시작 신호]
- App 2: [자료 확인]
- App 3: [기록]
- App 4: [알림]
- App 5: [후속 실행]
출력 형식:
- 단계별 입력값
- 단계별 출력값
- Make 모듈 배치 순서
- 반드시 매핑할 필드
- 실패했을 때 멈출 조건
- 운영 전 체크리스트
“업무 목표”는 전체 방향을 잡는 문장입니다. “연동 앱과 역할”은 앱 이름이 바뀌어도 구조가 흔들리지 않게 잡아 주는 뼈대입니다.
Skill로 저장할 문구는 더 짧게 만듭니다. Skill은 업무 방식을 담는 요소이고 Plugins는 Skills, 앱 연동, MCP 서버 설정을 묶는 번들이므로, Skill에는 판단 기준과 출력 형식을 넣는 편이 좋습니다. [OF-17]
이 Skill은 5개 앱 업무 자동화 설계를 돕는다.
항상 시작 신호, 자료 확인, 기록, 알림, 후속 실행 순서로 생각한다.
각 단계마다 입력값, 출력값, 실패 조건, 사람이 확인할 지점을 표로 쓴다.
실제 실행 전에 중복 실행, 권한 오류, 빈 값, 알림 과다를 점검한다.
가장 손쉬운 응용은 시작 앱과 마지막 앱만 갈아 끼우는 방식입니다. 접수 채널이 바뀌어도 “시작 신호 → 자료 확인 → 기록 → 알림 → 후속 실행”이라는 뼈대는 그대로 두면 됩니다.
자주 발이 걸리는 곳은 빈 값입니다. 앞 단계가 자료 위치를 못 찾았는데 뒤 단계가 멈추지 않고 굴러가면, 알림도 후속 실행도 죄다 엉뚱한 내용으로 만들어집니다.
다음은 권한입니다. 붙인 앱이 많을수록 어느 단계에서 접근 권한이 걸리는지 미리 적어 둬야 촬영 도중에 흐름이 끊기지 않습니다.
세 번째 함정은 Plugins를 단순한 앱 목록으로만 보는 것입니다. Plugins는 Skills, 앱 연동, MCP 서버 설정을 함께 묶는 번들이므로, “앱을 몇 개 붙였나”보다 “업무 방식과 연결 설정이 함께 묶였나”를 봐야 합니다. [OF-17]
오늘의 핵심은 Plugins를 업무 가방으로 보는 것입니다. 그 가방 안에는 Skills, 앱 연동, MCP 서버 설정이 함께 들어갑니다. [OF-17]
체크리스트는 다섯 줄이면 충분합니다. 시작 신호가 분명한가, 다음 단계로 넘길 값이 정해졌는가, 빈 값이면 멈추는가, 알림이 너무 많지 않은가, 마지막 실행자가 기록 링크와 자료 위치를 바로 볼 수 있는가.
마지막으로 plugin.json을 매니페스트로 기억합니다. plugin.json은 Plugins 구성을 설명하는 중심 파일입니다. [OF-17]
본문의 [...] 표기는 아래 근거에서 확인할 수 있습니다.