b-studio 프로젝트 소개: 사내 도구를 만들고 바로 실행해 보는 AI 앱 빌더

b-studio는 사내 도구를 만드는 AI 앱 빌더입니다. “주문 목록에 상태 필터를 추가해 줘”처럼 요청을 말하면 코딩 에이전트가 코드를 씁니다. 그 코드는 격리된 샌드박스에서 실제 개발 서버로 실행됩니다. 검증을 통과한 변경만 남습니다.

한눈에 보기

왜 만들었나

AI 앱 빌더는 이미 많습니다. 그런데 회사 안에서 쓸 도구를 만들려고 하면 조건이 달라집니다.

• 코드가 회사가 허락한 환경(사내망 Docker나 Kubernetes) 안에서만 돌아야 합니다.
• 생성된 코드가 사내 API를 부를 때 허용된 호출만 나가야 하고, 무엇을 불렀는지 기록이 남아야 합니다.
• 개인정보나 비밀 값이 로그와 커밋에 섞이면 안 됩니다.
• 에이전트가 “다 됐습니다”라고 말해도 실제로 서버가 뜨고 API가 약속대로 동작하는지는 따로 확인해야 합니다.
• 이 도구를 그만 쓰더라도 만든 코드는 그대로 가져갈 수 있어야 합니다.

b-studio는 이 조건들을 플랫폼이 자동으로 적용하게 만드는 데서 출발했습니다. 그래서 첫 대상을 사내 도구로 정했고, 백엔드는 회사에서 많이 쓰는 Spring Boot 템플릿부터 만들었습니다.

누구를 위한 도구인가

주요 기능

1. 요청에서 실행까지 한 흐름

에이전트는 계획, 코드 작성, 실행, 검증 순서로 일합니다. 웹 스튜디오에서는 대화, 화면 미리보기, API 탐색기, 코드, 로그, 변경 기록을 탭으로 오가며 진행 상황을 봅니다. 개발 서버는 Docker나 Kubernetes에 실제로 띄웁니다.

2. 검증 게이트: 완료는 플랫폼이 판정합니다

에이전트가 끝났다고 말하면 검증 게이트가 직접 확인합니다.

• 바뀐 파일이 샌드박스에 반영됐는지 봅니다.
• 바뀐 서비스를 재시작하고 준비 상태(HTTP 응답)를 확인합니다.
• OpenAPI 명세를 이전과 비교해 기존 API 계약이 깨졌는지 봅니다. 계약을 일부러 깨는 작업은 요청에 그 의도가 드러나고 별도 옵션도 켜야 통과합니다.
• 설정에 적어 두면 테스트 명령, 헤드리스 브라우저 화면 확인, 리뷰까지 실행합니다.

하나라도 실패하면 결과를 에이전트에게 돌려보내 고치게 합니다. 위 첫 화면이 컴파일 오류로 한 번 실패한 뒤 고쳐서 통과한 모습입니다.

3. 체크포인트: 코드와 DB를 함께 되돌립니다

검증을 통과한 요청은 Git 커밋 하나로 남습니다. 같은 시점의 PostgreSQL 덤프도 함께 저장합니다. 파일만 되돌리면 DB에는 적용됐지만 코드에는 없는 마이그레이션이 남아 서비스가 뜨지 못하기 때문입니다. 검증에 실패하거나 취소한 변경은 자동으로 되돌립니다.

4. 격리와 정책: 샌드박스의 출입구는 하나

• 서비스마다 메모리와 CPU 상한을 겁니다.
• 샌드박스에서 밖으로 나가는 HTTP는 edge 컨테이너의 프록시 한 곳만 통과합니다. 허용 목록과 감사 기록이 전부 여기 있습니다. 사내 API도 이 프록시를 거쳐야 부를 수 있습니다.
• 비밀 값은 로그와 명령 출력에서 가리고, 비밀 값이 들어간 커밋은 거부합니다.
• 신뢰할 수 없는 코드를 돌릴 때를 위해 gVisor와 Kubernetes 제공자도 있습니다.

5. 여러 모델과 여러 후보

• Anthropic, OpenAI 호환 API, Gemini를 같은 도구 계약으로 실행합니다. 작업의 난도와 위험도에 따라 모델을 고르고 요청, 세션, 사용자별 토큰 한도를 겁니다.
• Agent Fleet는 필요한 작업만 2~4개 후보로 펼쳐 각자 독립된 Git 브랜치와 샌드박스에서 돌립니다. 사람은 결과를 비교해 하나를 고릅니다.
• 작업 분해는 큰 요청을 작업과 쓰기 범위로 나눕니다. 사람이 계획을 승인하면 서로 겹치지 않는 작업은 동시에 돌립니다. 결과를 합친 뒤 같은 게이트로 다시 검증합니다.

6. 배포

검증 기록이 있는 체크포인트만 운영 이미지로 만들어 고정 주소로 전환합니다. 이전 릴리스로 롤백할 수 있습니다.

구조

1
사용자 -> 웹 스튜디오 / CLI -> 모델 라우터 -> 에이전트 루프 -> 격리된 샌드박스(web, api, db)
2
                                                     |
3
                                                검증 게이트 -> 통과: Git + DB 체크포인트
4
                                                             -> 실패: 에이전트에게 돌려보냄

저장소는 pnpm 워크스페이스이고 역할별 패키지로 나뉩니다.

일정과 작업 방식

저장소 커밋 기록(2026-09-10 ~ 09-17)을 영역별로 묶으면 다음 순서로 쌓였습니다.

이슈와 PR로 남긴 정도는 시기마다 달랐습니다. 09-10부터 09-12까지는 PR 38개가 병합돼 커밋과 PR이 거의 1대1로 붙었습니다. 09-13 이후 멀티 모델 라우터, Agent Fleet, 워크플로 강제, 작업 분해 같은 굵직한 기능은 PR 없이 main에 바로 커밋했습니다. 지금 진행 중인 화면 문법 정리 작업만 이슈 #39와 PR #40으로 다시 남아 있고 아직 병합 전입니다.

설계 판단은 decisions.md에 ADR 51개로 적었습니다. 샌드박스 제공자를 추상화한 이유(ADR-006), 완료를 플랫폼이 판정하게 한 이유(ADR-010), 워크플로 단계를 게이트가 직접 실행해야 통과로 인정한 이유(ADR-049)처럼 판단마다 근거를 남겼습니다. 기존 ADR은 지우지 않고 판단이 바뀌면 새 ADR에서 대체 관계를 밝히는 규칙을 CONTRIBUTING.md에 정해 뒀습니다.

예상 작업 시간이나 마감을 미리 적어 두고 실제와 비교하는 기록은 남기지 않았습니다. 위 단계 구분은 커밋 기록을 나중에 묶어 다시 구성한 것입니다. 진행하면서 미리 세운 계획은 아니었습니다.

검증도 기능마다 결과를 따로 기록해 뒀습니다. 무엇을 확인했는지는 바로 다음 절에서 이어집니다.

실제 환경에서 확인한 것

기능마다 “구현되어 있음”과 “실제 환경에서 확인함”을 나눠 기록했습니다. 몇 가지만 추리면 다음과 같습니다.

아직 못 한 것

• API 키를 쓰는 외부 모델 공급자 경로는 자격 증명이 있는 환경에서 따로 확인해야 합니다.
• Kubernetes는 로컬 kind에서만 확인했고 관리형 클러스터에서는 돌려 보지 않았습니다.
• 배포 롤백은 DB 마이그레이션까지 되돌리지는 않습니다.
• 작업 분해의 계획을 적절하게 나누는지는 모델 품질에 달려 있습니다. 그래서 레인을 돌리기 전에 사람이 계획을 승인하게 했습니다.
• 아직 라이선스를 정하지 않았습니다.

직접 실행해 보기

Node.js 22 이상, pnpm, Docker Desktop이나 Colima가 필요합니다.

1
git clone https://github.com/dj258255/b-studio.git
2
cd b-studio
3
corepack enable
4
pnpm install
5
pnpm studio up examples/orders

터미널에 웹 미리보기와 OpenAPI 주소가 나옵니다. 웹 스튜디오는 다른 터미널에서 띄웁니다.

1
# 모델 호출 없이 화면과 전체 흐름만 확인
2
pnpm studio:demo

기본 주소는 http://127.0.0.1:3000입니다. 에이전트를 실제로 돌리려면 ANTHROPIC_API_KEY나 로그인된 Claude Code CLI가 필요합니다.

더 보기

• 코드와 문서: GitHub 저장소
• 설계 결정 기록: decisions.md
• 검증 기록과 한계: verification.md
• 체크포인트 덤프와 정책 프록시 문제를 고친 기록: 덤프를 문자열로 들고 있었다