⚡ 3줄 요약
- “말로 앱을 만든다”가 핵심이 아니다 — 진짜는 말을 배포 설명서(manifest)로 바꾸고, 그 설명서를 검증 가능한 클라우드 작업으로 잇는 것이다.
- 월 $5–$15는 20명이 앱 10개를 돌리는 조건의 추정치다. 규모가 달라지면 그대로 적용되지 않는다.
- 비용을 낮춘 건 마법이 아니라 Lambda의 유휴 과금 구조. 안 쓸 때 자원을 접는 서버리스라 가능한 숫자다.
사내에 필요한 작은 도구는 늘 넘친다. 배송비 계산기, 접수 양식, 스프레드시트 하나 띄우는 대시보드. 그런데 이런 건 개발팀 대기열에서 항상 뒤로 밀린다. 수익과 직접 붙은 기능이 먼저기 때문이다. PDI Technologies가 만든 PDI Brew는 이 대기열 자체를 없애려는 시도다. 비개발자가 평범한 말로 도구를 설명하면, 몇 초 안에 SSO로 보호되고 AWS에서 돌아가는 멀티테넌트 웹 앱을 받는다. 저장소도, 명령줄도, 데브옵스 지식도 필요 없다.
여기서 흔히 “말로 앱을 만드는 마법”에 시선이 쏠린다. 하지만 이 시스템의 진짜 설계 포인트는 다른 데 있다. 사용자의 말을 곧바로 실행하지 않는다는 것 — 그게 핵심이다.
작은 계산기 하나에도 개발 절차 전부가 따라붙는다
단순한 계산기 하나를 배포하려 해도 필요한 게 한둘이 아니다. 저장소, 빌드·배포 파이프라인, 로그인 연동, 호스팅, HTTPS 인증서, 도메인, 로그 수집. 그리고 배포 이후엔 유지보수가 끝없이 붙는다. 규모가 작다는 이유로 우선순위에서 밀리지만, 조직 안에서 필요한 개수는 오히려 많다. 이 모순이 사내 도구의 고질병이다.
PDI Brew는 요청자와 개발팀 사이의 이 연결을 끊는 방식으로 설계됐다. 요청자가 도구를 설명하면 플랫폼이 앱과 기본 운영 환경을 한 번에 준비한다. 그리고 항상 켜 둔 서버 대신 필요할 때만 깨어나는 AWS Lambda를 쓴다. 소형 앱 여러 개를 돌려도 유휴 비용이 낮은 이유가 여기 있다.
⚠️ $5–$15의 진짜 조건
AWS 원문은 “20명이 앱 약 10개를 운영하면 월 $5–$15”라고 못박는다. 이건 사용자 수와 앱 수가 고정된 특정 규모의 추정치다. 사용량이 늘거나 앱이 무거워지면 숫자는 얼마든지 달라진다. “월 몇 달러면 사내 앱 다 만든다”로 읽으면 곤란하다.
말을 곧바로 실행하지 않고 ‘설명서’로 먼저 굳힌다
PDI Brew는 작업을 두 담당으로 쪼갠다. 앞단의 요청 설계 담당(Planning Agent)은 사용자와 대화하며 기능·데이터 구조·접근 권한을 구체화하고 화면을 짠다. 그 결과물이 배포 설명서(deploy manifest)다. 앱 이름, 종류, 데이터 구조(schema), 접근 제어 설정을 담은 JSON 문서. 여기서부터가 기준점이 된다.
뒷단의 자원 준비 담당(Provisioning Agent)은 AWS Lambda에서 이 설명서를 검사하고, 작업 종류에 맞는 제작 절차를 고른 뒤 AWS와 Microsoft Graph API로 클라우드 자원과 회사 계정 연결을 만든다. 오래 걸리는 작업은 Lambda가 자기 자신을 백그라운드로 다시 호출해 처리한다. 그래서 사용자는 배포가 끝날 때까지 붙잡혀 있지 않는다. 먼저 응답을 받고, 작업이 끝나면 접속 주소를 받는다.
| 단계 | 담당 | 하는 일 |
|---|---|---|
| 1. 의도 정리 | 요청 설계 담당 | 대화로 기능·데이터·권한 확정, 화면 구성 |
| 2. 설명서 생성 | 요청 설계 담당 | 앱 이름·종류·데이터 구조·권한을 JSON으로 출력 |
| 3. 검증·배포 | 자원 준비 담당 | Lambda에서 설명서 검사 → 자원·SSO 연동 생성 |
| 4. 응답 | 시스템 | 먼저 응답 반환, 완료 후 접속 주소 전달 |
이 분리가 왜 영리한가 — 설명서가 ‘계약’이라서
요청 설계 담당은 하나의 도구에 묶여 있지 않다. 사원이 이미 쓰는 AI 비서 안에서 도는 Vibe Skill 경로를 쓸 수도 있고, Teams·웹 폼·IDE 같은 채널이면 Amazon Bedrock 모델 호출 경로로 갈 수도 있다. 어느 경로를 켤지는 환경 변수 PLANNER_MODE 하나가 정한다.
핵심은 두 경로가 똑같은 형식의 배포 설명서를 뱉는다는 것이다. 그래서 앞단을 뭘로 바꾸든 뒷단(검증·배포)은 손댈 필요가 없다. 요청을 받는 방법과 실제 자원을 만드는 방법이 깔끔하게 분리돼 있다. 새 요청 경로를 추가해도 자원 준비 담당의 검증·배포 절차를 그대로 재사용한다. AI 비서는 사람의 애매한 요구를 다듬는 대화에 강하고, 클라우드 자원 생성은 결정을 기록하고 반복할 수 있어야 하므로 Lambda가 통제한다 — 각자 잘하는 자리에 놓은 셈이다.
AI 기능도 ‘아무 모델이나 직접’ 연결하지 않는다
앱 안에 대화·요약·분류 같은 AI 기능을 넣을 수 있다. 기업용 모델 연결 서비스인 Amazon Bedrock을 정해진 통로로만 쓰기 때문이다. 여기서 중요한 건 각 앱이 모델 주소나 API 키를 직접 만지지 않는다는 점이다. 모든 호출은 권한 검사, 사용량 제한, AI 안전장치(guardrail)를 거친다. 누가·어떤 앱에서·어떤 모델을·토큰 몇 개나 썼고 예상 비용은 얼마인지까지 기록된다. 이런 사용량과 비용을 좌우하는 다이얼을 앱 밖에서 통제한다는 발상이다.
이 구조 덕분에 데이터가 조직 밖으로 나가면 안 되는 규제·민감 업무에도 쓸 수 있다. AWS 원문은 이렇게 정리한다 — “PDI Brew는 전적으로 PDI 자신의 클라우드와 신원 경계 안에서 돌기 때문에, 데이터가 조직의 경계를 벗어날 수 없는 규제·민감 워크로드도 감당할 수 있다.” 회사 계정 로그인은 Microsoft Entra ID와 MSAL.js로 처리하고, Microsoft Graph API로 그룹 소속을 확인한다.
| 항목 | 확인된 값 | 의미 |
|---|---|---|
| PDI 직원 수 | 약 4,000명 | 플랫폼을 만든 기업 규모 |
| 고객 사업장 | 20만 곳 초과 | 200개 넘는 국가·지역에서 지원 |
| 운영 비용 | 월 $5–$15 | 20명이 앱 약 10개 운영 시 추정치 |
| 실행 기반 | AWS Lambda 등 서버리스 | 유휴 시 자원을 접어 소형 앱 비용 절감 |
🎯 FEEDON의 선택 — 우리라면 이렇게 본다
이 사례에서 베낄 만한 건 “자연어 앱 생성기”가 아니다. 그건 화려한 껍데기다. 진짜 배울 점은 말과 실행 사이에 ‘설명서’라는 검증 지점을 끼워 넣은 설계다. AI가 만든 걸 바로 배포하지 않고, 구조화된 문서로 한번 굳힌 뒤 그걸 기계적으로 검증·배포한다. 이래야 기록이 남고 반복이 되고 책임 소재가 분명해진다.
비용도 냉정하게 보자. $5–$15는 서버리스의 유휴 과금 덕이지 PDI Brew 고유의 마법이 아니다. 앱이 무거워지거나 트래픽이 몰리면 그 숫자는 무너진다. 그리고 자동 생성이 권한 검토와 운영 책임까지 없애 주지는 않는다. 접속되는지만 확인하고 끝내면, 자동화가 오히려 새 위험을 만든다.
내 조직에 적용한다면 — 이 순서로 점검하라
- 만들 도구를 기능 단위로 적는다 — 계산·입력·조회·대화를 구분해야 설명서 범위가 잡힌다
- 누가 읽고 쓰는지 정한다 — 회사 계정으로 로그인해도 전원이 같은 데이터를 봐선 안 된다
- AI가 필요하면 모델 이름보다 사용 목적과 허용 범위를 먼저 정한다 (모델부터 고르면 실패하는 이유) — 답변 품질은 결국 모델이 아니라 자료가 가른다
- 배포 후엔 접속 여부만 보지 말고 권한·데이터 보호·호출 기록·예상 비용을 함께 점검한다
적용 순서
🛠️ 사내 도구 하나 올려보기
- 만들 도구를 계산·입력·조회·대화 같은 기능 단위로 쪼개 적는다 — 이 목록이 곧 배포 설명서의 범위가 된다.
- 누가 읽고 누가 쓰는지 권한을 나눈다 — 회사 계정으로 로그인해도 전원이 같은 데이터를 보게 두지 않는다.
- AI 기능을 넣는다면 모델 이름을 고르기 전에 사용 목적과 허용 범위부터 문장으로 정한다.
- 배포가 끝나면 접속되는지만 보지 말고 권한·데이터 보호·호출 기록·예상 비용을 함께 열어 확인한다.
출처: AWS Machine Learning Blog 「Building an agentic app deployer with Amazon Bedrock and AWS Lambda」 · 가격·사양은 변동될 수 있음
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
