Welcome to Mate — 아이디어를 서비스로

1. 왜 Mate인가

1.1 배경

이제 코드는 개발자만 쓰지 않습니다. 마케팅 부서와 지원 부서에서도 AI를 이용하여 랜딩페이지·리포트 대시보드·자동화 봇을 직접 만듭니다. 만드는 실력은 상향평준화됐습니다. 문제는 만든 다음입니다.

문제	지금 벌어지는 일
로컬 서버 의존	만든 것을 내 컴퓨터나 임시 서비스에 띄운다. 제대로 올리려면 방법·비용·인증서·관리 모두가 어렵다 — 누군가의 손을 빌리거나 오랜 시간이 걸린다.
관리 부재	코드가 개인 계정과 노트북에 흩어진다. 담당자가 팀을 옮기거나 퇴사하면 누구 것인지, 어느 버전이 살아 있는지 아무도 모른다.
현황 파악 불가	시험 삼아 띄운 것, 캠페인이 끝난 것이 그대로 남는다. 서버가 몇 대 떠 있고 매달 얼마가 나가는지 아무도 모른다.
보안 취약	API 키·비밀번호·고객 데이터가 코드에 적힌 채 올라간다. 찾아내고 막는 일은 매번 사람 몫이다.

만드는 것에만 집중하세요. 나머지는 Mate가 합니다. 서버·주소·배포·보안·관리 — 만든 다음의 일은 전부 Mate가 준비합니다.

1.2 목적

목적	설명
사용 편의성	쉽다. 서버·도메인·배포를 몰라도 쓸 수 있다. 저장소를 만들고 서버에 연결하면 주소가 생기고, 나머지는 Mate가 한다.
보안 강화	고객사 데이터·API 키·비밀번호 같은 중요한 정보가 코드에 노출되지 않게 막고, 배포 전마다 점검한다.
인력 관리	팀 이동·퇴사 때 권한이 자동으로 따라 빠지고, 코드와 데이터는 회사에 남는다. 담당자가 바뀌어도 앱은 그대로.
중앙 관리	전사 저장소·앱·서버를 데이터컨설팅팀이 한 화면에서 보고, 실패·충돌·방치를 찾아 처리한다.
비용 가시성	팀별·앱별 서버 비용을 월 예상액으로 항상 보여 준다.
팀 자율성	팀원 초대, 저장소 인원, 앱 생성·삭제는 팀 내 관리자가 직접 한다. 중앙 관리자의 병목을 최소화한다.

1.3 한 줄 요약

①Mate에서 저장소를 만들고 서버에 연결한다

→

②Claude / Cursor로 만든다

→

③"배포해줘"

→

✓https://내-앱.madup.app 에 떠 있다

2. 용어와 권한

2.1 용어

용어	뜻
저장소	코드가 있는 곳(GitHub 저장소 — 개발자 말로 "레포"). 이름은 `<고객사>-<기능>` (예 `samsungpop-landing`), 내부용은 `internal-…`
서버	앱이 도는 장비. 한 서버에 같은 팀의 앱을 여러 개 올릴 수 있다
연결	저장소와 서버를 붙이는 일. 이 과정에서 주소(`<저장소>.madup.app`)가 만들어지고 앱 하나가 완성된다
앱	저장소·서버·주소가 하나로 연결된 서비스
팀명 / 팀 ID	한글 표시 이름(바꿀 수 있음) / 영문 식별자(예 `dct`, 첫 팀리드가 온보딩에서 정하고 바꾸지 않음)
역할	팀리드 / 팀원 — 조직에서 맡은 자리
권한	관리자 / 일반 — Mate에서 할 수 있는 일의 범위. 팀리드는 항상 관리자, 팀원은 관리자로 승격 가능
GitHub 권한	저장소마다 GitHub의 5단계를 그대로 쓴다(2.3)
팀 알림 채널	팀의 슬랙 채널. 배포·배치 실패, 가입 신청, 이슈 결과가 간다

2.2 역할과 권한

역할은 "누구인가", 권한은 "무엇을 할 수 있나"입니다.

	일반	관리자
누가	팀원 기본값	팀리드(고정) + 팀리드가 승격한 팀원
내 저장소 보기, 접속 정보, 명단 보기	✅	✅
저장소 만들기, 인원 넣고 빼기	—	✅
서버 만들기·연결, 앱 삭제, 서버 해지	—	✅
팀원 초대·제외, 팀명 변경, 이관	—	✅
팀원을 관리자로 승격·강등	—	팀리드만

관리자로 승격된 팀원은 팀리드와 같은 권한을 갖습니다(여러 명 가능). 관리자를 정하는 것만은 팀리드의 일입니다.

플랫폼(데이터컨설팅팀)은 팀 밖의 운영 역할입니다 — 사람이 들어오고 나가는 일, 돈이 드는 자원, 실패한 일의 뒷정리. 무엇을 하는지는 6장에 있습니다.

2.3 GitHub 권한 — GitHub 것을 그대로, 한글로

GitHub	Mate 표시	할 수 있는 것
read	읽기	코드 보기, clone
triage	분류	읽기 + 이슈·PR 정리
write	쓰기	코드 수정, push, PR — 작업자의 기본값
maintain	유지관리	쓰기 + 사람 넣고 빼기
admin	관리	전부 — 팀리드의 기본값

기본 배정: 팀 내 관리자는 보통 관리(admin) 또는 유지관리(maintain), 팀원은 쓰기(write) 입니다. 팀리드는 팀 저장소마다 자동으로 "관리"가 되고(만들 때·이관받을 때·승계할 때), 승격된 관리자는 저장소를 직접 만들면 "유지관리", 넣어 줄 때도 유지관리 이상으로 배정합니다.

화면에서는 권한 이름 옆 툴팁(ⓘ)이 한 줄 설명을 보여 줍니다.
저장소에 사람을 넣고 빼려면 그 저장소에서 유지관리 이상이어야 합니다. 유지관리 이상인 마지막 사람은 뺄 수 없습니다.

3. 프로세스

3.1 시작하기

1초대 링크 또는 가입 신청

→

2Google 계정(madup.com)으로 로그인

→

3온보딩: 정보 입력 → GitHub 연동

→

4앱 개발 원칙 읽고 "읽었습니다"

	초대로	신청으로
누가	관리자가 팀원을 이메일로 초대(팀리드는 플랫폼이)	초대 없이 로그인한 사람
승인	초대가 곧 승인	팀리드 신청은 플랫폼, 팀원 신청은 그 팀 관리자
입력	—	팀리드: 팀명·팀 ID·알림 채널 / 팀원: 팀 선택(팀리드가 있는 팀만)
대기	—	"승인 대기 중" 화면, 반려되면 사유가 보이고 다시 신청

로그인은 MADUP Google 계정(@madup.com)입니다. 이메일로 1회용 로그인 링크를 받는 방법도 있습니다. 초대받은 이메일과 같은 계정을 써야 초대가 연결됩니다.
정보 입력: 이름(팀리드는 팀 ID·알림 채널도). GitHub 연동: 본인이 GitHub에 로그인해 증명하면 Mate가 MADUP GitHub 조직 초대를 보내고, 수락을 확인하면 연동이 끝납니다 — 조직 가입까지가 연동입니다.
앱 개발 원칙: 온보딩 마지막에 5장을 읽고 "읽었습니다"를 누릅니다. 이걸 눌러야 저장소 화면이 열립니다. 원칙이 바뀌면 다음 로그인에 다시 확인합니다.
조직에 없는 사람을 저장소에 넣으면 권한은 "조직 초대 대기"로 예약됐다가 가입 확인 즉시 들어갑니다.
팀리드가 바뀌는 일(교체·퇴사)은 플랫폼이 처리합니다. 팀당 팀리드는 1명입니다.

더 필요한 것 — 이메일 목록으로 한 번에 초대하고, 사람마다 어디까지 왔는지(로그인 → GitHub 연동 → 조직 가입 → 원칙 확인)를 표로 보기(8.1) · 초대 재발송과 만료(7일) · 반려 사유 보기

OpenClaw로 자동화 — 초대 뒤 3일이 지나도 멈춰 있는 사람에게 슬랙으로 "다음 단계는 GitHub 연동입니다"와 링크를 보내기 · "GitHub 404 떠요" 같은 질문에 소개서·FAQ로 바로 답하기(온보딩 도우미) · 승인 대기 신청을 팀리드 슬랙에 승인/반려 버튼으로

3.2 팀 운영 — 사람이 움직이면 권한도 움직인다

상황	누가 · 어디서	저장소 권한
합류	관리자 → 팀 → 팀원 초대	없음. 팀에 들어왔다고 저장소가 열리지 않는다. 관리자가 저장소마다 넣어야 보인다
제외	관리자 → 팀 → 구성원 → 제외	그 팀 저장소 전부에서 즉시 회수. 계정은 남지만 소속이 없다
팀 이동	다른 팀 관리자가 초대 → 본인 수락	이전 팀 저장소 권한 전부 제거 → 새 팀 관리자가 다시 배치
관리자 승격	팀리드 → 팀 → 구성원 → 관리자로	팀리드와 같은 권한
회사 퇴사	플랫폼 → 퇴사 처리	모든 권한 제거 + GitHub 조직에서 내보냄 + 계정 비활성

1인 1팀이 원칙입니다. 다른 팀의 초대를 받아들이면 이동입니다.
제외·이동으로 어떤 저장소에 유지관리 이상인 사람이 아무도 남지 않으면 팀리드가 자동으로 "관리"를 승계합니다.
팀 알림 채널은 공개 채널을 씁니다. 비공개 채널은 알림이 가지 않을 수 있습니다.

더 필요한 것 — 관리자가 한 명도 없는 팀에 "팀리드 부재를 대비해 관리자를 한 명 두세요" 안내 · 합류·제외·이동 이력(누가 언제) · 다른 팀 사람을 저장소 협업자로 넣는 길(1인 1팀은 유지)

OpenClaw로 자동화 — 회사 계정(Google Workspace)이 비활성된 사람을 매일 대조해 "퇴사 처리할까요?" → 승인하면 실행 · 팀리드·관리자가 없는 팀, 30일 미로그인 계정을 매주 한 줄로 보고

3.3 저장소 — 누가 어디에 들어가나

저장소 하나 = 배포 단위 하나. 이름에 팀명은 넣지 않습니다 — 팀은 바뀌어도 코드는 남기 때문입니다.

관리자(그 저장소에서 유지관리 이상): 저장소 상세 → 인원 → 추가 (GitHub 연동한 팀원 중 선택, 권한 5단계 중 선택 · 기본 쓰기)
   ▼
봇: GitHub 권한 즉시 부여 (조직 밖 계정이면 조직 초대 → 가입 확인되면 자동 부여)
   ▼
팀원: "내 저장소"에 나타남 → clone → 작업

저장소를 만들면 템플릿에서 복제됩니다 — README·Claude 작업 규칙·배포 설정이 처음부터 들어 있고, 만든 직후 시작 페이지 하나가 뜰 준비가 되어 있습니다. 만들 때 적은 "어떤 기능을 만드실 건가요?" 한 줄이 README의 앱 정보(제목 "새로운 앱" · 설명)에 들어가서 첫 배포부터 통과합니다. 제목은 나중에 Claude에게 "앱 이름은 ~로"라고 하면 바뀝니다.
무엇이든 만들 수 있습니다. 폼·API·대시보드·정기 배치 — 원하는 것을 Claude에게 말하면 되고, 한 서버에 여러 앱을 함께 올릴 수 있습니다.
팀리드는 "관리"로, 만든 사람이 승격된 관리자(팀원)면 "유지관리"로 들어갑니다(팀리드가 직접 만들면 관리). 이름과 주소(<저장소>.madup.app)가 비어 있는지 확인하고 주소는 그 자리에서 예약됩니다.
옛 조직에서 가져온 저장소는 GitHub 관리 (기존)으로 보여 주기만 합니다. 포털이 권한을 관리하는 건 포털에서 만든 저장소뿐입니다.

더 필요한 것 — "지난번 그 저장소처럼" — 기존 저장소를 본으로 새 저장소 만들기 · 고객사·캠페인 태그와 검색 · 90일 넘게 커밋·배포가 없는 "잠자는 저장소" 표시 · 상세에 최근 커밋·브랜치 요약

OpenClaw로 자동화 — 새 저장소 첫날 점검 — README 제목·설명, .env.example, 원칙 위반을 보고 Claude에게 넘길 한 줄을 팀 채널로 · 잠자는 저장소를 월 1회 모아 "휴지통으로 옮길까요?" 제안

3.4 앱 — 저장소를 서버에 연결하면 완성

Mate의 중심은 저장소입니다. 저장소를 서버에 연결해 주소로 뜨게 하는 것이 Mate가 하는 일의 전부이고, 그렇게 연결된 한 벌이 앱입니다.

연결 저장소 화면의 연결 버튼 → 새 서버 만들어 연결(서버 이름 = 저장소 이름, 사양은 기본 하나 · 월 $10) 또는 기존 서버에 연결(우리 팀 서버 목록에서 선택). Mate가 주소·인증서·배포 설정을 심고 첫 배포까지 시작합니다.
만들기 Claude / Cursor로 코딩합니다. main에서는 작업하지 않고, Claude가 작업 이름의 브랜치를 만들어 거기서만 코딩합니다.
배포 "배포해줘" → Claude가 보안 점검(비밀값 하드코딩, 비밀 파일, 입력 검증, 열린 관리 기능, 의존성 취약점)을 하고 결과를 알립니다. 이슈가 전부 처리된 뒤에만 main에 합쳐 배포합니다. 몇 분 뒤 https://<저장소>.madup.app 이 응답합니다.

서버는 비용이 발생하므로 관리자만 만듭니다. 사양은 기본 사양으로 시작합니다. 기본 사양에서 업그레이드가 필요하면 플랫폼에 요청합니다.
한 서버에 같은 팀의 앱을 여러 개 올릴 수 있습니다. 자리(포트·폴더)는 Mate가 정하고, 비용은 서버 단위로 한 번만 보입니다.
앱 화면은 서버별로 묶인 앱 표 하나입니다 — 주소 · 상태(정상/문제/배포 중) · 저장소 · 최근 실행 · 삭제. 앱 정보(README 맨 위의 제목·설명)는 배포마다 자동 수집됩니다.
주소가 이미 다른 서버를 가리키는 등 충돌이 나면 연결을 멈추고 이슈로 올립니다. 플랫폼이 확인·승인하면 이어서 진행됩니다.
오래 걸리는 일(서버 생성·해지, 연결, 이관, 권한 회수)은 요청 즉시 화면을 돌려주고 뒤에서 진행합니다. 진행 상태는 표에 보이고, 실패는 이슈로 남습니다.

데이터베이스와 비밀값

데이터베이스는 필요한 앱만 씁니다. 관리자가 저장소 상세에서 "데이터베이스 사용하기"를 누르면 Mate가 공용 PostgreSQL에 고객사 데이터베이스와 전용 계정을 준비합니다(내부용 앱은 저장소 전용). 팀원은 코딩하면서 DATABASE_URL만 쓰고, 로컬용 값은 접속 정보 화면에서 복사합니다. 코드가 데이터베이스를 쓰는데 아직 켜지 않았으면 배포 때 Mate가 알아채 관리자에게 알립니다.
같은 고객사의 저장소는 팀이 달라도 같은 데이터베이스를 씁니다. 데이터는 고객사 것입니다.
앱 전용 비밀값(외부 API 키 등)은 저장소 상세 "환경 변수" 탭에서 관리자가 넣고, 배포 때 앱에만 주입됩니다. 코드에 넣지 않는 이유와 지켜야 할 것은 5.2에 있습니다.

더 필요한 것 — 앱 공개 범위 스위치: 지금 앱은 주소를 아는 누구나 열 수 있다. "사내 전용"(MADUP Google 계정만) · "링크 아는 사람"(고객사 공유) · "공개" 셋 중 하나를 앱마다 고르게 — 내부 리포트·대시보드에는 이게 먼저다 · 고객사 도메인 연결(campaign.고객사.com → 우리 앱, 인증서까지) — 캠페인 랜딩은 고객사 주소로 나가야 할 때가 있다 · 얼마나 쓰이나: 앱별 방문 수 · 폼 제출 수(2.0) · 정기 배치 화면: 언제 도는지 · 마지막 결과 · 지금 실행 · 배포 이력과 로그를 앱 화면에서(GitHub에 가지 않고) · 이전 배포로 되돌리기(롤백) · 시험 주소 <저장소>-dev.madup.app(dev 브랜치) · 서버 사양 업그레이드 요청 버튼

OpenClaw로 자동화 — 배포가 실패하면 로그를 읽어 원인을 한 줄로 팀 채널에 → 빌드 오류면 수정 브랜치를 만들어 "이걸로 다시 배포할까요?" · 배포 뒤 주소를 브라우저로 열어 첫 화면·주요 링크 깨짐 확인 · 헬스체크 실패는 재시작 → 그래도 안 되면 이슈 · 커밋에 비밀값이 들어오면 즉시 알리고 환경 변수로 옮기는 길 안내 · 주 1회 "이번 주 우리 앱" 한 줄(방문 · 제출 · 배포 · 실패)을 팀 채널로

3.5 이관 — 담당 팀이 바뀔 때

규칙	내용
누가 · 누구에게	그 저장소 팀의 관리자가 → 다른 팀의 팀리드에게(목록에서 선택)
수락	받는 팀리드가 수락하면 성립
권한	기존 인원 전원의 저장소 권한이 사라지고, 받은 팀리드가 "관리"로 혼자 시작 → 팀원을 다시 배치
함께 옮겨지는 것	연결된 서버(비용 귀속이 새 팀으로)
그대로인 것	저장소 이름·주소·배포·데이터베이스

더 필요한 것 — 이관 예약(날짜 지정) · 이관 이력과 사유 · 받는 팀리드가 "이전 인원 그대로 붙이기"를 고를 수 있게

OpenClaw로 자동화 — 팀 이동으로 저장소에 관리자만 남으면 "이관하시겠어요?" 제안 · 이관 뒤 일주일 안에 인원 배치가 없으면 새 팀리드에게 리마인드

3.6 정리 — 앱 삭제, 휴지통, 삭제

비용이 붙는 자원은 만든 사람이 지울 수 있어야 청구가 새지 않습니다. 정리는 세 동작이고, 데이터베이스와 비밀값은 어느 단계에서도 지우지 않습니다.

동작	누가	결과
앱 삭제	관리자	주소가 내려가고(저장소 몫으로 예약 유지), 그 서버에 다른 앱이 없으면 서버 해지(남은 기간 환불). 저장소·데이터는 그대로
휴지통으로 이동	관리자	저장소 상세의 휴지통 버튼. 앱이 있으면 함께 내려가고, 코드는 GitHub에 읽기 전용으로 보관된 채 저장소 휴지통으로 옮겨진다. 주소 예약 유지
되살리기	관리자	저장소 휴지통에서 되살려 예약된 주소 그대로 다시 연결
삭제	관리자	저장소 휴지통에서 삭제. 되돌릴 수 없다 — 코드는 GitHub에서 영구 삭제, 주소 예약과 DNS 레코드 정리. 데이터베이스는 남는다

서버 이미지는 만들지 않습니다. 서버에는 상태가 없고(코드는 GitHub, 데이터는 공용 DB, 비밀은 시크릿 매니저) 저장소만 있으면 언제든 똑같이 다시 만들어집니다.
논리 데이터베이스를 지우는 일은 고객사가 다른 대행사로 넘어가는 경우에만 플랫폼이 처리합니다.

더 필요한 것 — 앱 비활성 — 지우지 않고 내려 두기(2.0) · 휴지통 보관 기한(30일)과 자동 삭제 예고 · 데이터 백업이 언제까지 남는지 화면에 적기(공용 DB 자동 백업 보관 기간 · "이 날짜로 되돌려 주세요" 요청 버튼) · 삭제 전 데이터베이스 덤프 내려받기 · 앱 삭제 때 서버를 해지하지 않고 팀 공용으로 남기는 선택

OpenClaw로 자동화 — 2주 넘게 접속·배포가 없는 앱을 찾아 "비활성할까요?" → 승인하면 실행(비용 지킴이) · 앱이 없는 서버가 하루 넘게 남아 있으면 해지 제안

3.7 비용 — 우리 팀이 얼마나 쓰고 있나

Mate가 만드는 모든 자원에는 팀·고객사·저장소·환경·용도 태그가 붙습니다. 비용 화면은 이번 달 예상 비용 하나를 보여 줍니다 — 우리 팀이 쓰는 서버의 월 정액 합계입니다. 서버 하나에 앱을 여러 개 올려도 서버 값 그대로입니다.

화면의 비용은 Mate 내부 배분 단가입니다. 실제 청구와는 차이가 있을 수 있습니다.
실제 청구서를 팀별로 나눠 보는 것은 한 달 이상 운영해 데이터가 쌓인 뒤 넣습니다.

더 필요한 것 — 팀별 월 예산과 80%·100% 알림(2.0) · 실제 청구서를 태그로 나눠 화면 값과 대조 · 서버 하나에 앱이 여럿이면 앱별 배분 보기 · 지난달 비교

OpenClaw로 자동화 — 월말에 팀별 비용 요약을 팀 채널로 · 전월 대비 급증(30% 이상)은 즉시 알림 · 앱 없는 서버, 태그 빠진 서버를 찾아 정리 제안

3.8 이슈 트래킹 — 오류를 놓치지 않기

포털이 하는 일은 대부분 GitHub·클라우드를 대신 조작하는 것이라 중간에 실패하면 사람이 확인해야 합니다. 실패와 확인이 필요한 일은 전부 이슈로 남습니다 — 배포·헬스체크·배치 실패, 주소 충돌, 서버·데이터베이스 준비 실패, GitHub 권한 실패, 포털 밖에서 바뀐 권한, 클라우드 불일치.

내가 보는 것은 하나뿐입니다 — 저장소 화면 배너에 "확인 중 / 처리됨 / 반려 사유". 결과는 팀 알림 채널로도 옵니다. 그동안 무엇을 할 필요는 없습니다.

중앙이 이슈를 어떻게 처리하는지는 6.4에 있습니다.

더 필요한 것 — 이슈 담당자·기한 · 같은 원인이 반복되면 하나로 묶기 · 재시도가 성공하면 자동 닫힘 · 요청자에게 처리 과정을 슬랙으로도 · 팀 화면에 "우리 팀 이슈"

OpenClaw로 자동화 — 이슈 처리 스킬(8.3의 1순위) — 재시도·재시작·재발송처럼 자동 범위인 것은 스스로 처리하고 결과만 남긴다. 승인이 필요한 것은 원인 요약과 권장 조치를 이슈에 붙여 사람은 버튼만 누른다. 같은 유형이 세 번째 오면 스킬이 되어 저가 모델이 처리한다

3.9 화면 밖에서 — 코딩하다 그대로

Mate 화면을 열지 않아도, 코딩하던 Claude Code 안에서 Mate에 물어보고 시킬 수 있습니다. 프로필에서 연결 키를 발급하고 한 줄을 붙여 넣으면 끝 — 무엇이 되는지는 7장에 정리했습니다.

5. 앱 개발 원칙 — 코딩 전에 꼭 읽기

저장소에서 Claude와 함께 앱을 만들 때 지키는 원칙입니다. 대부분은 Claude가 알아서 지키고, 저장소 훅과 배포 파이프라인이 한 번 더 막습니다. 그래도 왜 그런지 알고 있어야 Claude가 "이건 안 돼요"라고 할 때 바로 이해하고 대안으로 갈 수 있습니다.

온보딩 마지막 단계에서 이 장을 읽고 "읽었습니다"를 누른 뒤에 저장소를 쓸 수 있습니다. 원칙이 바뀌면 다음 로그인에 다시 한 번 확인을 받습니다. 저장소 안의 MATE.md(사용 안내서)에도 같은 내용이 들어 있습니다.

5.1 작업 방식

원칙	왜
main에서는 작업하지 않는다 — 작업은 늘 브랜치에서. "배포해줘" 하면 Claude가 main에 합쳐 배포한다	main은 지금 서비스 중인 코드다. 실수가 곧 장애가 된다. 훅이 main 커밋을 막는다
배포는 "배포해줘" 한마디로 — 직접 push·merge 하지 않는다. Claude가 보안 점검 → 배포까지 이어서 한다	손으로 하면 점검을 건너뛰기 쉽다. 되돌리기도 "이전으로 되돌려줘" 한마디
한 저장소 = 한 앱 = 한 주소 — 목적이 다르면 새 저장소를 만든다	저장소 이름이 곧 주소이고 배포 단위다
작게 자주 배포한다 — 한 번에 조금씩 바꾸고 확인한다	문제가 나면 어디서 났는지 바로 안다. 되돌리기도 한 번에 끝난다
앱 설명서(README)를 최신으로 — 제목·설명(100자)·무엇을 하나·화면·쓰는 법. Claude가 배포 때마다 갱신한다	앱 화면과 대시보드에 그대로 보인다. 다른 사람이 인수받을 때 유일한 문서다

5.2 비밀값과 데이터

원칙	왜
API 키·비밀번호·토큰은 코드에 넣지 않는다 — `.env.example`에 이름만 적고, 값은 저장소 화면 → 환경 변수에 관리자가 넣는다	GitHub에 올라간 키는 유출된 것으로 본다. 훅과 배포 파이프라인이 막는다
실수로 키를 올렸으면 새로 발급받는다 — 지우는 것만으로는 부족하다	커밋 기록에 남는다
고객 원본 데이터(csv·xlsx·DB 덤프)는 저장소에 올리지 않는다	개인정보·계약 데이터다. 저장소에는 코드만
데이터베이스는 Mate의 공용 PostgreSQL만 — 관리자가 저장소 화면에서 "데이터베이스 사용하기"를 켠다. SQLite·파일 DB는 쓰지 않는다	파일 DB는 재배포·서버 해지 때 사라진다. 공용 DB는 앱을 지워도 남는다
로컬용 `.env`는 내 컴퓨터에만 — 커밋되지 않는다(`.gitignore`)	서버의 비밀값은 배포 때 Mate가 앱에만 넘긴다

5.3 배포 전 보안 점검

원칙	왜
이슈 0건일 때만 배포 — Claude가 점검 결과를 항상 알린다. "그냥 배포해"라고 해도 이슈가 남아 있으면 배포하지 않는다	배포 파이프라인이 같은 검사를 한 번 더 한다. 우회하는 길은 없다
점검 항목 — 하드코딩된 비밀값, 데이터 파일, 취약한 의존성, 열린 관리자 경로, 외부로 나가는 요청	마케팅 앱은 외부에 열린다. 한 번 새면 회수가 안 된다
점검에 걸리면 Claude가 알려 준 대안대로 — 환경 변수로 옮기기, 키 재발급, 파일 제거	원칙마다 정해진 대안이 있다

5.4 손대지 않는 것

원칙	왜
배포 파일과 Claude 설정 — `Dockerfile` · `docker-compose.yml` · `deploy/` · `.github/workflows/` · `.claude/` · `CLAUDE.md`	Mate가 관리하고 매일 자동으로 최신화한다. 고치면 다음 갱신에 덮이거나 배포가 막힌다
GitHub 웹에서 권한·설정 바꾸기 — 협업자 추가·public 전환·설정 변경은 포털에서만	포털이 권한의 원천이다. 밖에서 바꾸면 드리프트로 잡히고 되돌려진다
서버·데이터베이스·도메인을 따로 만들기 — 필요하면 관리자가 포털에서	비용과 보안이 Mate 밖으로 나간다
`git push --force` · `git reset --hard`	다른 사람의 작업이 사라진다. Claude도 막혀 있다

5.5 막혔을 때

Claude가 "이건 안 돼요"라고 하면 위 원칙 중 하나다. 우회하지 말고 Claude가 알려 준 대안대로 간다.
배포가 실패하면 저장소 화면 이슈에 이유가 남는다. 고치면 해결 표시.
권한·환경 변수·데이터베이스가 필요하면 팀 관리자에게. 그 외는 저장소 안 MATE.md, 이 문서, 데이터컨설팅팀.

더 필요한 것 — 폼으로 모은 개인정보 규칙: 무엇을 받을 수 있나 · 동의 문구 · 보관 기간과 자동 파기 · 내려받을 수 있는 사람 — 마케팅 앱은 신청 폼이 첫 앱인 경우가 많은데 지금 원칙에는 "고객 원본 데이터는 저장소에 올리지 않는다"만 있다 · 배포 전 점검에서 무엇이 막혔는지 저장소 상세에 표시 · 원칙이 바뀌면 "무엇이 바뀌었나" 요약을 다시 읽기 화면에

OpenClaw로 자동화 — 현장에서 반복되는 "이건 안 돼요" 사례를 모아 원칙·규칙 개정 후보를 플랫폼에 올리기(8.3의 3순위, 역방향 갱신) · 새 취약점 공지가 나면 영향받는 저장소 목록과 수정 브랜치를 만들어 "배포할까요?"

4. 화면별 기능

4.1 로그인 · 온보딩 · 프로필

로그인: "Google 계정으로 로그인"(MADUP, @madup.com) 기본, 아래에 "메일로 로그인 링크 받기"
온보딩: 이름 → GitHub 계정 연결(새 탭에서 본인 로그인) → MADUP GitHub 조직 가입(초대 확인하기 ↗ · "수락했어요") → (팀리드) 팀 ID · 알림 슬랙 채널 → 앱 개발 원칙(5장 본문을 그 자리에서 읽고 "읽었습니다")
프로필: "<이름>님의 정보" 카드(역할 · 권한 · 소속 팀 · 팀 ID · GitHub 연동과 조직 가입), 이름 바꾸기. 에이전트 연결 키(계정당 하나) — 발급 · 새 키로 갱신 · 회수, Claude Code 등록 명령 복사. 하단에 "Mate 소개서 · 앱 개발 원칙" 링크

프로필 (팀리드) — 내 정보 카드(역할 · 권한 · 소속 팀 · GitHub 연동), 에이전트 연결 키

에이전트 연결 키 — 발급 직후 카드(등록 명령 복사 · 3단계), 아래 목록에서 갱신 · 회수

4.2 저장소 — 목록

상단: 내 저장소 / 내가 관리 / 내가 참여. 범위: 내가 속한 저장소 / 우리 팀 / 조직 전체(플랫폼)
표: 저장소(이름 · 앱 제목 · 설명) · 고객사 · 내 권한(ⓘ) · 인원 · 앱(앱으로 가기 / 연결) · 접속 정보
정렬: 연결이 필요한 저장소가 맨 위, 그다음 진행 중, 연결됨
버튼: + 새 저장소 · 저장소 휴지통(되살리기 · 삭제) · ↻ GitHub 동기화(진행 중이면 버튼 자리에 조용히 표시)
행을 클릭하면 상세 페이지로. 새 저장소는 고객사 · 기능 두 칸으로 이름과 주소가 정해지고, 설명 한 줄(필수)이 README 앱 정보로 들어갑니다

저장소 목록 (팀리드) — 이름 · 앱 제목 · 설명, 고객사 · 내 권한 · 인원 · 앱 · 접속 정보

접속 정보 — GitHub 링크, clone 주소, 데이터베이스 접속 정보(구성원만)

새 저장소 — 고객사 · 기능을 적으면 저장소 이름과 주소가 정해지고(주소 사용 가능), 설명 한 줄이 README 앱 정보로 들어간다

4.3 저장소 — 상세

머리: 상태 · 주소 · 팀 · 고객사, 오른쪽에 이관 · 휴지통 아이콘. 위에 "앱 개발 원칙" 링크
배너: 비어 있는 환경 변수 n개 → 환경 변수 탭으로 · 이슈(확인 중 / 처리됨 / 반려 사유)
개요: 앱 정보(README의 제목·설명, 갱신 시각) · 앱 카드(서버 · 주소 · 최근 배포 · 앱 보기 · 앱 삭제) · 데이터베이스(사용 안 함 → 사용하기 / 사용 중)
인원: 추가(권한 5단계 · 기본 쓰기) · 권한 변경 · 제외. 조직 미가입자는 "조직 초대 대기"
환경 변수(유지관리 이상): 키 · 설정됨/비어 있음 · 값 넣기 · 삭제. .env.example의 키와 대조해 비어 있는 키를 알려 줌
접속 정보: GitHub 링크 · clone 주소 · 데이터베이스 접속 정보(구성원만)
연결(앱이 없을 때): 새 서버 만들기(월 $10 · 약 3분) / 기존 서버 사용(우리 팀 서버) · 환경 선택 → 연결

저장소 상세 — 머리(상태 · 주소 · 이관 · 휴지통), 환경 변수 · 이슈 배너, 개요(앱 정보 · 앱 카드 · 데이터베이스), 인원 · 환경 변수 탭

서버에 연결 — 새 서버 만들기(월 $10 · 약 3분) 또는 기존 서버 사용, 환경을 고르고 연결. 연결되면 main에 푸시할 때마다 배포

4.4 팀

구성원: 이름 · 역할/권한 배지 · GitHub(연동 안 함 / 초대 대기 n일 · 다시 보내기 / 가입됨) · 제외. 관리자로 올리면 팀리드와 같은 권한
팀원 초대(이메일), 보낸 초대, 가입 신청 승인·반려
팀명 변경(팀 ID는 고정), 알림 슬랙 채널

4.5 앱

상단: 앱 / 서버 / 월 예정 비용
앱 표 하나: 앱 주소 · 설명(README 제목·설명) · 상태(↻ 다시 확인) · 저장소 · 환경(🗑 앱 삭제) · 서버 · 월 비용 — 서버 칸은 오른쪽에 묶여 한 서버에 앱이 여럿이면 "서버 공용 · 앱 n개"로 한 번만. 진행 중인 것이 맨 위
행을 클릭하면 앱 상세: 헬스체크 · 마지막 배포 · 서버(사양 · 월 비용) · 저장소(인원 · 환경 변수) · 실행 이력. 새로고침 · 재배포 · 앱 삭제
연결은 이 화면이 아니라 저장소 상세의 "연결"에서 시작

앱 (팀리드) — 앱 표 하나. 서버는 오른쪽에 묶여 비용은 서버 단위로 한 번(서버 공용 · 앱 2개)

앱 상세 — 헬스체크 · 마지막 배포 · 서버(월 비용) · 저장소 · 실행 이력. 새로고침 · 재배포 · 앱 삭제

4.6 비용

이번 달 예상 총비용 / 과금 중인 서버 수
서버별 월 비용 표(사양 · 팀 · 고객사 · 환경 · 용도 · 앱 · 상태 · 월 비용)

4.7 플랫폼 · 이슈 (데이터컨설팅팀 전용)

중앙이 하는 일 전부 — 사람(초대·승인·사용자·퇴사), 자원(서버·데이터베이스·비용), 권한과 규칙(동기화·점검·Claude 규칙), 실패한 일(이슈). 6장에 정리.

6. 중앙 관리 — 데이터컨설팅팀이 하는 일

팀은 자기 팀의 저장소·앱·인원을 스스로 관리합니다(3장). 중앙(데이터컨설팅팀, 플랫폼 계정)은 팀이 할 수 없는 것 — 사람이 들어오고 나가는 일, 돈이 드는 자원, 실패한 일의 뒷정리 — 만 맡습니다. 전부 플랫폼 메뉴와 이슈 메뉴 두 화면에서 합니다.

6.1 사람

하는 일	어디서	내용
팀리드 초대	플랫폼 → 팀리드 초대	이메일로 초대. 팀리드가 로그인·GitHub 연동·팀 ID·알림 채널을 채우면 팀이 생긴다. 팀당 팀리드 1명
가입 신청 승인 · 반려	플랫폼 → 승인 대기	초대 없이 로그인한 사람의 신청. 팀리드 신청은 중앙이, 팀원 신청은 그 팀 관리자가
사용자 관리	플랫폼 → 사용자	역할(팀리드/팀원) · 권한(관리자) · 소속 팀 변경. 팀을 옮기면 이전 팀 저장소 권한은 자동으로 빠진다
퇴사 처리	플랫폼 → 사용자 → 퇴사	모든 저장소에서 제거, 계정 비활성, GitHub 조직에서 제거(기본). 되돌리려면 다시 초대
팀리드 교체	플랫폼	새 팀리드 지정 시 팀 저장소 전부에 관리 권한이 자동으로 붙는다
초대 삭제	플랫폼 · 팀 화면	잘못 보낸 초대(오타 주소·반송)를 목록에서 삭제

더 필요한 것 — 일괄 초대와 진행 현황 표(8.1) · 퇴사 처리 예약(날짜) · 팀리드 교체 때 인수인계 요약(저장소 n개 · 서버 n대 · 인원) · 사용자 검색

OpenClaw로 자동화 — 회사 계정 비활성자 대조 → "퇴사 처리할까요?" · 조직 초대 미수락자에게 리마인드 · 30일 미로그인·팀리드 없는 팀을 매주 한 줄 보고

6.2 자원과 돈

하는 일	어디서	내용
사양 업그레이드 · 특수 서버	요청 → 중앙	보통 서버는 팀 관리자가 직접 만든다(기본 사양). 기본 사양으로 모자랄 때만 중앙이 올려 준다
서버 해지	앱 화면	앱이 하나도 없는 서버만. 앱 삭제로 빈 서버는 자동 해지
고객사 데이터베이스	저장소 → 데이터베이스 사용하기	고객사 단위로 공용 PostgreSQL에 만든다. 지우는 건 중앙만, 고객사 이탈 때
비용 모니터링	비용 화면(전체)	팀별·서버별 예상 비용과 실제 청구. 예산 알림은 2.0
클라우드 동기화	앱 화면 → 클라우드 동기화	포털 밖에서 생기거나 사라진 서버·태그 누락을 찾아 이슈로

더 필요한 것 — 서버 사양 변경 버튼(지금은 요청) · 고객사 데이터베이스 목록·용량 · 실제 청구서 대조 · 팀별 예산

OpenClaw로 자동화 — 비용 지킴이(8.3의 5순위) — 월말 요약 · 급증 감지 · 미사용 앱·빈 서버 정리 제안 · 클라우드 동기화를 매일 돌려 불일치를 이슈 대신 "정리할까요?" 한 줄로

6.3 권한과 규칙

하는 일	어디서	내용
GitHub 동기화	플랫폼 → GitHub 동기화	조직의 저장소 목록·이름·보관 상태를 포털과 맞춘다
권한 점검 · 복구	플랫폼 → 권한 점검·복구	저장소 전부의 GitHub 권한을 포털 명단과 비교. 빠진 권한은 자동으로 채우고, 포털 밖에서 준 권한은 이슈로. 밤마다 자동으로도 돈다
Claude 규칙 최신화	플랫폼 → Claude 규칙 · 저장소 상세	템플릿의 최신 작업 규칙(`.claude/` · `CLAUDE.md`)을 모든 저장소에 덮어쓴다. 매일 04:00 자동, 필요하면 "지금 적용"
저장소 휴지통(전체)	저장소 → 저장소 휴지통	모든 팀의 휴지통. 되살리기·삭제
감사 로그	플랫폼 → 최근 감사 로그	누가 무엇을 했는지 — 연결 키 사용까지

더 필요한 것 — 권한 점검 결과를 저장소별 차이 표로 · 규칙 적용 결과(저장소별 성공/실패) · 감사 로그 검색과 내려받기 · 의도된 차이는 예외로 등록 · 분기 접근 권한 리포트(누가 어느 저장소·데이터베이스에 접근할 수 있나) — 보안 점검·감사 요청이 오면 그대로 제출

OpenClaw로 자동화 — 권한 드리프트를 보면 GitHub에서 누가 바꿨는지 찍어 "되돌릴까요 / 예외로 둘까요" 슬랙 버튼 · 현장 사례에서 규칙 개정 후보를 올리기(역방향 갱신)

6.4 실패한 일 — 이슈

포털이 GitHub·클라우드를 대신 조작하다 실패하거나 사람이 확인해야 하는 일은 전부 이슈로 모입니다(3.8). 새 이슈는 슬랙 #mate_solution_alert로, 처리 결과는 그 팀 채널로 갑니다.

이슈	중앙이 하는 일
배포 실패 · 헬스체크 실패 · 배치 실패	원인 확인, 재시도, 담당자 알림
주소 충돌(연결 시 주소가 다른 곳을 가리킴)	승인하면 주소를 옮겨 연결, 반려하면 요청자에게 사유
서버 생성·해지 실패, 데이터베이스 준비 실패	재시도(권한·재고 문제면 조치 후)
GitHub 권한 부여·회수 실패, 조직 초대 미수락	재시도 또는 수동 처리
권한 드리프트(포털 밖에서 바뀐 권한)	되돌리기 또는 예외 기록
클라우드 불일치(사라진 서버 · 태그 누락)	정리 또는 등록

긴 작업(권한 점검 · 동기화 · 규칙 적용)은 화면에서 기다리지 않습니다 — 접수만 하고, 결과는 위 채널에 한 줄로 옵니다.

플랫폼 — 팀리드 초대 · 팀 · 사용자(역할 · 소속 팀 · 퇴사 처리) · 플랫폼 알림 · Claude 규칙 · 가입 신청 · 승인 대기 · 권한 불일치. 아래로 최근 작업 · 감사 로그

이슈 트래킹 — 주소 이관 승인 · 헬스체크 실패(처리 중) · 배포 실패 · 조직 초대 미수락 · 권한 드리프트

더 필요한 것 — 담당자·기한·묶기·자동 닫힘 · 주간 이슈 통계(유형별 건수 · 평균 처리 시간)로 어디가 병목인지 보기 · 방치 알림: 하루 넘게 손대지 않은 이슈, 같은 앱에서 반복되는 실패는 #mate_solution_alert 에 다시 올리기

OpenClaw로 자동화 — 이슈 처리 스킬(8.3의 1순위) — 자동 범위는 즉시 처리, 나머지는 원인 요약과 권장 조치를 붙여 사람은 결정만. 이슈가 열리기 전에 헬스체크·배포·배치·비용을 먼저 살피는 감시(하트비트)까지

7. 에이전트 연결 — Claude Code 안에서 Mate 쓰기

코딩하던 Claude Code 안에서 Mate에 물어보고 시킵니다. 설치할 것은 없습니다 — 서버는 Mate 안에 있고, 키 하나만 등록하면 됩니다.

7.1 이렇게 하면 됩니다

프로필 → 에이전트 연결 키 → 발급 직후. 명령 한 줄과 복사 버튼, 아래에 3단계

1프로필에서 키 발급 → 복사

→

2PowerShell에 붙여넣고 Enter

→

3Claude Code 다시 열고 "나 누구로 연결돼 있어?"

PowerShell = 시작 메뉴에서 검색해 여는 창(Claude Code를 실행하던 그 창). 맥은 "터미널". 어느 폴더에서 해도 됩니다.
복사되는 건 키가 들어간 완성 명령이라 옮겨 적을 게 없습니다. 이름 같은 걸 입력할 것도 없습니다. 이미 열려 있던 Claude Code에는 안 붙으니 닫고 다시 엽니다.

안 될 때	이렇게
"유효하지 않은 연결 키"	프로필에서 새 키로 갱신 → 1부터 다시
Claude가 Mate를 모름	Claude Code를 닫고 다시 열기. 확인은 같은 창에서 `claude mcp list`
권한이 없다고 함	키는 그 사람 권한 그대로 — 관리자 일은 팀 관리자에게

키는 계정당 하나이고 발급 직후 한 번만 보입니다. 다른 PC에도 넣으려면 새 키로 갱신한 뒤 모든 PC에 다시 등록합니다(옛 키는 즉시 무효). 안 쓰면 회수.

7.2 할 수 있는 일

도구 이름은 몰라도 됩니다 — 이렇게 말하면 Claude가 고릅니다.

보기 — 누구나

이렇게 말하면	알려 주는 것
"나 누구로 연결돼 있어?"	이름 · 역할 · 팀 · 할 수 있는 일
"내 저장소 뭐 있어?"	저장소 목록(상태 · 내 권한 · 주소)
"이 저장소 누가 있어?"	인원 · 권한 · 주소 · 앱 상태 · 최근 배포
"우리 앱들 상태 어때?"	앱 목록(주소 · 헬스 · 마지막 배포 · 월 비용)
"우리 앱 왜 안 떠?"	실패 사유 · 빠진 환경 변수 · 데이터베이스 상태 · 열린 이슈 · 다음 할 일 — 한 번에
"최근 배포 몇 번 됐어?"	최근 배포 실행(결과 · 시각 · 누가)
"확인 중인 요청 있어?"	이슈(종류 · 처리 상태 · 반려 사유)
"아까 그 작업 끝났어?"	접수된 작업의 진행 · 결과
"앱 살아 있어?"	지금 헬스체크
"서버 뭐 있어?"	서버(사양 · 상태 · 비용 · 올라간 앱)
"이번 달 서버 비용?"	팀 예상 비용 · 서버별 · 실제 청구
"어제 밤 배치 돌았어?"	배치 실행 이력 · 로그
"환경 변수 뭐 빠졌어?"	키 이름만(값은 절대 안 보여 줌)
"DB 접속 정보 줘 (.env에 쓰게)"	파일에만 씀, 채팅에는 안 남김

바꾸기 — 관리자

이렇게 말하면	하는 것
"새 저장소 만들어 줘 — kurly, 랜딩페이지"	`kurly-landing` 저장소 생성
"이 저장소 저 서버에 올려 줘"	서버 연결 → 주소 → 첫 배포
"환경 변수 바꿨으니 다시 배포해 줘"	재배포(2~3분)
"DB 쓰고 싶어"	공용 PostgreSQL 준비
"앱 제목/설명 바꿔 줘"	대시보드 표시 갱신
"OO를 작업자로 넣어 줘"	인원 추가(GitHub 권한까지)

지우기 — 관리자, Claude가 먼저 되묻고 실행

이렇게 말하면	하는 것
"이 앱 내려 줘"	앱 삭제(주소는 예약, 빈 서버는 해지). 저장소 이름을 말해야 실행
"OO를 이 저장소에서 빼 줘"	인원 제거

MCP에 없는 것: 휴지통으로 이동 · 저장소 삭제 · 서버 해지 · 이관 — 화면에서만.

7.3 원칙


권한은 사람과 같다	화면에서 못 하는 일은 Claude도 못 한다. 기록에 키 이름과 함께 남는다
비밀값은 채팅에 안 흐른다	환경 변수 값은 어떤 도구도 안 돌려준다. DB 접속 정보는 `.env`에 써 달라고 할 때만 파일에
지우는 일은 사람이 확인	앱 삭제 · 인원 제거는 되묻고, 이름을 말한 뒤에만
오래 걸리는 일은 접수 뒤 확인	만들기 · 연결 · 재배포 · 삭제는 접수 → "끝났어?"로 결과

더 필요한 것 — 내 키가 언제 무엇을 했는지 프로필에서 보기 · 지우는 도구(delete_app · remove_repo_member)를 팀별로 끄기 · 오래 안 쓴 키 자동 회수 · Cursor · Claude Desktop 등록 안내 · 마케터가 실제로 하는 말을 모아 도구 설명 다듬기(8.1)

OpenClaw로 자동화 — "MCP에 없는 것"을 시킨 기록(실패한 호출)을 모아 도구 추가 후보를 매주 보고 · 도구 사용량·오류율 주간 리포트 · 3.0에서는 에이전트가 사람을 기다리지 않고 먼저 움직인다(8.3)

7.4 예시

나: madup-bidding 배포 상태 어때? 빠진 환경 변수 있어? Claude: 정상 — 마지막 배포 성공, 헬스 ok. 빠진 환경 변수 4개: BIDHUB_ADMINS, … → 저장소 화면 → 환경 변수에 넣고 "지금 적용".

나: DB 접속 정보 알려줘. Claude: 비밀번호가 있어 채팅엔 남기지 않겠습니다. .env에 저장해 드릴까요?

8. 로드맵

1.0인프라 관리 + 에이전트 연결(MCP)
2026년 10월 배포

→

2.0앱 대시보드
2026년 11월 배포

→

3.0AI 고도화
2026년 12월 말 배포 (제품은 OpenClaw · Hermes 중 결정)

8.1 1.0 — 인프라 관리 + 에이전트 연결 (2026년 10월 배포)

기본적인 인프라 관리 기능을 마무리하고, 에이전트(Claude Code · Cursor)에서 Mate를 직접 다루는 길(MCP)을 엽니다. 3·4·6·7장에 적힌 것은 운영 중이고, 남은 것은 아래입니다.

항목	내용
에이전트 연결 다듬기	도구 22개는 되어 있다(7장). 파일럿에서 마케터가 실제로 하는 말을 모아 설명과 빠진 도구를 채운다
일괄 온보딩	이메일 목록으로 초대를 한꺼번에 보내고 진행 현황(로그인·연동·조직 가입·원칙 확인)을 표로
기존 저장소의 배포 파일 갱신	템플릿의 배포 설정이 개선되면 이미 만들어진 저장소에도 반영
파일럿	마케팅팀 한 곳이 실제 앱 하나를 끝까지(저장소 → 앱 → 배포) 만들어 보고 소개서·원칙을 다듬는다

8.2 2.0 — 앱 대시보드 (2026년 11월 배포)

여러 마케팅팀이 앱을 만들기 시작하면 "지금 회사에 어떤 앱이 몇 개 돌고 있나"가 가장 먼저 필요한 질문이 됩니다. Mate로 올라간 모든 앱을 한 화면에서 봅니다.

보이는 것	내용
어떤 앱인가	이름 · 한 줄 설명(앱 설명서 README에서) · 팀 · 고객사 · 유형(웹 · 배치)
주소	`https://<저장소>.madup.app` — 누르면 바로 열림
상태	운영 중 (헬스체크 정상) · 문제 (배포·배치·헬스체크 실패) · 비활성 (내려 둔 앱)
비용	앱별 이번 달 예상 비용, 전체·팀별 합계, 지난달과 비교
최근 배포	언제 · 누가 · 무엇을 · 결과(성공 · 실패 · 보안 점검 차단)
얼마나 쓰이나	앱별 방문 수 · 폼 제출 수(간단 집계). 마케터가 가장 먼저 묻는 숫자이고, 안 쓰이는 앱을 찾는 근거가 된다
걸러 보기	팀 · 고객사 · 상태 · 검색. 앱을 누르면 오른쪽에 상세(설명 · 비용 내역 · 서버 · 인원 · 배포 이력)

앱 대시보드 — 예시 화면(2.0 기획 목업). 실제 화면은 다를 수 있습니다

비활성은 새로 생기는 상태입니다 — 앱을 지우지 않고 잠시 내려 두는 것. 주소·저장소·데이터는 그대로 두고 서버에서만 내립니다(서버에 남은 앱이 없으면 비용 0). 캠페인이 끝난 앱, 시험용 앱에 씁니다.
재료(앱 정보 · 상태 · 서버 비용 · 배포 이력)는 1.0에서 이미 모이고 있어서, 2.0은 보여 주는 화면과 "비활성"을 만드는 일입니다.
함께: 실제 청구서를 팀별로 나눠 보기 · 팀별 월 예산 80%/100% 알림 · 고객사 이탈 시 저장소·앱·서버 한 번에 정리(플랫폼).

8.3 3.0 — AI 고도화 (2026년 12월 말 배포)

1.0의 MCP가 "사람이 에이전트를 열어 Mate를 시키는 것"이라면, 3.0은 Mate 쪽에 에이전트를 두어 먼저 움직이게 하고, 한 번 해결한 일을 스킬로 남겨 다음에는 스스로(더 싼 모델로) 처리하게 하는 것입니다. 이 문서의 "OpenClaw로 자동화" 제안(3 · 5 · 6 · 7장의 상자)은 OpenClaw를 기준으로 썼습니다. Hermes는 스킬을 스스로 남기는 방식의 참고 후보로 두고, 제품은 2.0 뒤에 확정합니다. 배포는 2026년 12월 말까지입니다.

후보 제품	성격
OpenClaw	항상 켜져 있는 오픈소스 에이전트. 슬랙 같은 메신저로 대화하고, 정해진 시간에 스스로 일하고(크론 · 하트비트), 브라우저를 다룬다
Hermes (Nous Research)	일을 하면서 그 과정을 스스로 스킬로 남기고 기억을 쌓는 에이전트. 같은 일이 반복될수록 빨라지고 싸진다

후보 기능 — 우선순위 순. 어디까지 넣을지는 논의 중입니다. 각 장의 상자에 흩어진 자동화 제안은 대부분 아래 다섯 가지 중 하나에 들어갑니다(모음은 8.4).

순위	후보	내용
1	이슈 처리 스킬	3.8의 이슈 6종은 "원인 확인 → 재시도 → 담당자 알림"이라는 고정 절차가 있다. 처음 만나는 실패는 상위 모델이 로그를 읽고 판단하고, 같은 유형이 반복되면 스킬이 생겨 이후엔 저가 모델이 처리한다. 이슈가 열리기 전에 헬스체크 · 배포 · 배치 · 비용을 먼저 살피는 감시(하트비트)도 여기. 플랫폼(데이터컨설팅팀) 병목을 푸는 첫 번째 일
2	팀별 앱 제작 스킬	지금은 템플릿 하나에서 복제한다. 앱을 만들고 나면 그 과정이 스킬로 남아, 세 번째 이벤트 신청 폼부터는 "지난번 그 폼처럼"이 실제로 동작한다. 팀마다 다른 요구(고객사 브랜드 톤 · 개인정보 동의 문구 · 추적 태그 세팅)는 팀별 스킬로 갈라 담는다. 사람이 템플릿을 늘리는 것보다 빠르다
3	규칙 문서의 역방향 갱신	지금 Claude 규칙(`CLAUDE.md` · `MATE.md`)은 위에서 아래로만 내려간다(플랫폼 "지금 적용"). 현장에서 막힌 사례로 스킬이 생기면 그 스킬이 곧 규칙 개정 후보가 되어 플랫폼이 검토 · 적용한다. 규칙을 사람이 쓰는 게 아니라 현장에서 올라오는 구조 — 8.1의 파일럿이 한 번으로 끝나지 않고 계속 돈다
4	온보딩 도우미	소개서 · FAQ · `MATE.md`를 에이전트 기억에 넣어 "GitHub 404 떠요" 같은 질문이 데이터컨설팅팀까지 오지 않게. 근거 문서가 이미 있어 투입 대비 효과가 좋다. 관리자의 "OO 님 팀에 넣어줘" 실행은 그다음
5	비용 지킴이	2.0 대시보드 위에 얹는다 — 팀별 월 예산 알림, 2주 넘게 쓰이지 않은 앱을 찾아 "비활성할까요?", 월말 팀별 비용 요약. 조회와 제안뿐이라 권한 표면이 좁다
후순위	자동 유지보수	취약한 의존성 · 앱 설명서를 스스로 갱신해 브랜치 → 점검 → "배포할까요?" — 앱 코드에 손대므로 승인 절차가 먼저 자리 잡은 뒤
후순위	배포 후 브라우저 확인 · 앱에게 묻기	브라우저로 폼 제출 · 링크 확인, "어제 신청 몇 건?" "배치 왜 실패했어?"를 로그 · 데이터베이스로 답하기. 매력적이지만 권한 표면이 넓어져 앞의 것들이 자리 잡은 뒤에 본다
후순위	슬랙에서 앱 만들기	"이벤트 신청 폼 만들어줘" 한 줄로 저장소 생성 → 코딩 → 점검 → 배포 → 주소 회신. 터미널을 안 열어도 된다 — 제품이 메신저형(OpenClaw)이면 자연스럽게 따라온다

승인 경계 — 에이전트가 무엇을 스스로 해도 되는지는 아래 원칙으로 고정합니다. 에이전트는 시킨 사람의 권한(MCP 연결 키)으로만 움직이고, 기록은 키 이름으로 남습니다.

구분	내용
자동	배포 실패 재시도 · 헬스체크 실패 재시작 · 서버 생성 · 해지 실패 재시도 · 조직 초대 재발송
승인 필요	주소 충돌 이관 · 권한 드리프트 되돌리기 · 클라우드 불일치 정리 · 앱 코드 · 규칙 문서를 바꾸는 배포
절대 금지	비밀값 접근 · 데이터베이스 삭제

8.4 제안 모음 — 어디에 무엇을

3 · 5 · 6 · 7장의 상자를 한 표로 모았습니다. 판은 제안하는 시점이고, 확정은 아닙니다. 판단 기준은 셋 — 마케터가 막히는 곳(1.0), 앱이 여럿 되면 필요한 것(2.0), 사람이 반복하는 일(3.0 자동화).

영역	기능 추가 제안 → 판	OpenClaw 자동화 → 8.3 후보
시작하기 · 사람	일괄 초대 + 진행 현황 표 · 초대 재발송·만료 → 1.0 / 퇴사 예약 · 팀리드 인수인계 요약 → 2.0	멈춘 온보딩 리마인드 · 온보딩 질문 응답 → 4 온보딩 도우미 / 회사 계정 비활성자 → 퇴사 처리 제안 → 1 이슈 처리 스킬(사람 편)
저장소	잠자는 저장소 표시 · 검색·태그 → 2.0 / 기존 저장소를 본으로 만들기 → 3.0(2 팀별 앱 제작 스킬의 전 단계)	새 저장소 첫날 점검 · 잠자는 저장소 정리 제안 → 5 비용 지킴이
앱 · 배포	배포 이력·로그 화면 · 롤백 · 사양 업그레이드 요청 → 2.0 / 시험 주소(dev) · DB 덤프 → 2.0 뒤	배포 실패 원인 요약 + 수정 브랜치 → 1 이슈 처리 스킬 / 배포 후 브라우저 확인 → 후순위 / 커밋 속 비밀값 감지 → 후순위(자동 유지보수)
이관 · 정리	앱 비활성 → 2.0(확정) / 휴지통 기한 · 이관 예약 → 2.0	미사용 앱 비활성 제안 · 빈 서버 해지 제안 → 5 비용 지킴이 / 관리자만 남은 저장소 이관 제안 → 4
비용	팀별 예산 알림 · 실제 청구 대조 → 2.0(확정) / 앱별 배분 → 2.0	월말 요약 · 급증 감지 → 5 비용 지킴이
이슈	담당자·기한 · 묶기 · 자동 닫힘 → 1.0(플랫폼 병목) / 주간 통계 · 우리 팀 이슈 → 2.0	자동 범위 즉시 처리 · 나머지는 요약 + 권장 조치 · 하트비트 감시 → 1 이슈 처리 스킬
원칙 · 규칙	점검 결과 표시 · 개정 요약 다시 읽기 → 2.0	현장 사례 → 규칙 개정 후보 → 3 역방향 갱신 / 취약점 공지 → 수정 브랜치 → 후순위(자동 유지보수)
권한(중앙)	점검 결과 표 · 예외 등록 · 감사 로그 검색 → 1.0	드리프트 "되돌릴까요 / 예외로" 슬랙 버튼 → 1 이슈 처리 스킬
에이전트 연결	키 사용 기록 · 위험 도구 팀별 끄기 · 미사용 키 회수 → 1.0 / Cursor · Desktop 안내 → 1.0	실패한 호출 → 도구 추가 후보 보고 · 사용량 리포트 → 1.0 마무리 재료(8.1 다듬기)
앱 공개 범위 · 주소	사내 전용 / 링크 아는 사람 / 공개 스위치 → 1.0(내부용 앱이 늘기 전에) / 고객사 도메인 연결 → 2.0	공개로 열린 앱에 로그인·관리 경로가 있으면 경고 → 1 이슈 처리 스킬
쓰임새 · 개인정보	앱별 방문 · 폼 제출 수 → 2.0 / 폼 개인정보 보관·파기 규칙 → 1.0(원칙 문서) / 배치 스케줄 화면 → 2.0	주 1회 "이번 주 우리 앱" 요약 · 안 쓰이는 앱 찾기 → 5 비용 지킴이

읽는 법 — 1.0에 넣자는 것은 대부분 플랫폼(데이터컨설팅팀)의 손을 줄이는 것이고, 2.0은 앱이 여럿 될 때 보이는 것, 3.0은 사람이 반복하는 일을 에이전트가 먼저 하는 것입니다.

8.5 무엇으로 성공을 재나 · 무엇이 걱정인가

로드맵은 "무엇을 만드나"이고, 이 절은 "잘되고 있는지 어떻게 아나"입니다. 아래 숫자는 지금도 포털에 쌓이고 있어 따로 만들 것이 거의 없습니다 — 매월 플랫폼이 한 번 봅니다.

무엇을 본다	왜	어디서
살아 있는 앱 수 · 쓰는 팀 수	퍼지고 있나	앱 화면(전체)
아이디어 → 라이브 시간 (저장소 생성 → 첫 배포 성공까지)	Mate가 주는 것이 이 시간의 단축이다. 파일럿에서 기준값을 잡는다	저장소 생성 시각 · 첫 배포 성공 시각
배포 횟수 · 성공률	만들고 끝이 아니라 계속 고치고 있나	실행 이력
플랫폼 손이 간 건수 (이슈 · 수동 처리)	병목이 줄고 있나. 3.0의 목표는 이 숫자를 줄이는 것	이슈 · 감사 로그
온보딩에서 멈춘 사람 수	시작이 어려운가	사용자 목록(로그인 · 연동 · 원칙 확인)
앱 하나당 월 비용	싸게 유지되고 있나	비용 화면
배포 전 점검에서 막힌 건수	사고를 몇 번 미리 막았나	배포 실행 기록

무엇이 걱정인가 — 그리고 대비

걱정	대비
비용이 조용히 는다	서버 단위 정액 + 월 예상 비용을 항상 표시. 다음은 팀별 예산 알림(2.0) · 안 쓰는 앱 비활성 제안(3.0)
마케팅 앱이 외부에 열려 사고가 난다	배포 전 보안 점검(5.3) + 비밀값은 시크릿 매니저 + 고객 데이터는 공용 DB에만. 다음은 공개 범위 스위치(3.4 제안)
플랫폼(데이터컨설팅팀)이 병목이 된다	팀 자율(관리자 승격·팀 내 처리) + 이슈 자동 처리(8.3의 1순위). 위 표의 "플랫폼 손이 간 건수"로 매월 확인
만든 사람이 떠나 앱이 방치된다	코드는 조직 GitHub, 데이터는 공용 DB, 권한은 포털이 회수. 다음은 잠자는 저장소·앱 찾기(3.3 · 3.6 제안)
아무도 안 쓴다	파일럿 한 팀이 실제 앱 하나를 끝까지(8.1) → 막힌 곳을 소개서·원칙·도구에 반영. 안 되면 범위를 줄이고 다시
AI가 잘못 움직인다(3.0)	승인 경계 표(8.3) — 에이전트는 시킨 사람의 권한으로만, 비밀값 접근·데이터베이스 삭제는 절대 금지, 지우는 일은 사람 확인

그 외 백로그: 다크 테마 · 마케팅 앱의 외부 메일 발송(발신 도메인 · 평판 관리) · 앱 삭제 시 서버 해지 대신 플랫폼 소유로 재사용 · 로컬 개발 DB 분리 · 다른 팀 사람을 저장소 협업자로 넣는 방식.

Mate — 데이터컨설팅팀. 화면은 운영 포털의 실제 스크린샷입니다("예시 화면"으로 표시한 목업 제외).