코드에 매핑되는 다이어그램
Eraser와 Whimsical은 예쁜 박스만 그려줍니다. 엔지니어들은 결국 마감에 맞는 방식으로 만듭니다. Bob의 다이어그램은 Alex가 실제 코드베이스에서 사용하는 파일 구조와 모듈 경계가 됩니다.
Bob·Architect팀이 구축할 시스템을 설계하는 AI 아키텍트 에이전트
Bob이 시스템을 설계하고, 스택을 선택한 뒤, 그 구조를 Alex에게 넘겨주어 아키텍처가 잊힌 문서가 아니라 실제 코드베이스가 되게 합니다.
코드에 대응하는 다이어그램, 보기 좋은 그림이 아닙니다.
아키텍처 문서는 작성되는 순간부터 왜 구식이 되는가
아무도 구현하지 않는 보기 좋은 다이어그램
Eraser와 Whimsical은 아름다운 상자와 화살표를 렌더링합니다. 하지만 엔지니어들은 여전히 마감 일정에 맞는 방식으로만 구현합니다. Bob의 다이어그램은 Alex가 실제로 사용하는 파일 구조와 모듈 경계가 됩니다.
유행만 보고 결정되는 스택 선택
"Mongo가 인기 있어서 골랐어요." Bob은 왜 Mongo보다 Postgres인지, 왜 직접 호출보다 큐인지, 왜 Memcached 대신 Redis인지 설명합니다. 그 근거가 문서로 남기 때문에 검토하고 이의를 제기할 수 있습니다.
아키텍처와 코드가 따로 논다
위키의 다이어그램은 스프린트 1 시점의 것입니다. 코드는 스프린트 14 시점의 것입니다. 둘 다 서로 맞도록 업데이트하는 사람은 없습니다. Bob은 현재 시스템을 검토하고 실제로 배포된 내용을 반영하도록 아키텍처 문서를 업데이트합니다.
비기능 요구사항이 출시 후에야 발견된다
성능, 보안, 관측 가능성은 첫 번째 장애가 발생한 뒤에야 뒤늦게 덧붙여집니다. Bob은 설계 단계에서부터 Emma의 확장성 요구사항과 데이터 모델이 지원해야 하는 액세스 패턴을 바탕으로 이를 계획합니다.
Bob와 함께하는 하루
첫 번째 프롬프트부터 출시된 결과물까지 — Bob가 실제로 어떻게 작동하는지 보여드립니다.
- 01
- 02
이유를 바탕으로 스택 선택
데이터베이스, 프레임워크, 큐, 캐시 — 각 선택에는 이의를 제기할 수 있는 서면 트레이드오프 설명이 함께 제공됩니다.
- 03
데이터 모델과 모듈 경계를 매핑하기
엔티티, 관계, 소유권, 쓰기 경로 — 나중에 리팩터링할 때 가장 아픈 것들입니다.
- 04
코드에 매핑되는 시스템 다이어그램을 그리세요
박스와 화살표는 실제 모듈과 의존성을 반영하며, 코드가 추가되어도 다이어그램은 계속 동기화된 상태를 유지합니다.
- 05
Bob이 견고한 시스템을 설계하는 데 필요한 모든 것
아키텍처 다이어그램
별도의 도구가 아니라 Editor에서 생성되는 서비스, 데이터 흐름 및 통합 다이어그램입니다.
기술 스택 추천
유행이나 익숙함이 아니라, 당신의 제약 조건을 기준으로 근거 있게 선택한 스택입니다.
데이터 모델 설계
제품의 실제 액세스 패턴에 맞춰 설계된 스키마와 관계입니다.
비기능 요구사항 계획
출시 이후가 아니라 설계 단계에서 성능, 보안 및 관측성을 다룹니다.
의사결정 로그
향후 다시 검토할 수 있도록 아키텍처 의사결정을 근거와 함께 문서화합니다.
구조-코드 매핑
다이어그램이 Alex가 구축하는 파일 구조 및 모듈 경계에 매핑됩니다.
아키텍처 검토
Bob이 기존 시스템을 검토하고 명확한 근거와 함께 변경 사항을 권장할 수 있습니다.
Bob가 팀에 합류하면 무엇이 달라지는가
수작업 워크플로는 느리고, 수동적이며, 여러 도구에 크게 의존합니다. 각 카드에 마우스를 올려 각 향상이 왜 중요한지 확인하세요.
빌더들이 다른 옵션이 아닌 Bob을 선택하는 이유
비교
Eraser AI에서 넘어오셨나요? 여기서부터 Bob가 앞서갑니다.
과장이 아닌 근거로 하는 스택 선택
ChatGPT는 학습 데이터에서 가장 자주 본 프레임워크를 추천합니다. Bob은 왜 Mongo보다 Postgres인지, 왜 직접 호출보다 큐인지, 왜 Memcached보다 Redis인지 설명합니다. 그 이유는 얼마든지 검토하고, 결정은 다시 돌아볼 수 있습니다.
최신 상태를 유지하는 아키텍처
위키의 다이어그램은 스프린트 3쯤 되면 금방 낡아집니다. Bob은 실제 코드를 검토하고 배포된 내용에 맞춰 아키텍처를 새로 갱신합니다. 그래서 문서는 허구가 되지 않고, 새 엔지니어의 온보딩도 한 달이 아니라 하루면 됩니다.
Atoms 대 Eraser AI: 기능, 가격 및 성능 비교
| 기능 | Atoms 추천 | Eraser AI |
|---|---|---|
| 출력 | 코드로 매핑되는 아키텍처 | 위키의 다이어그램 |
| 근거 있는 스택 선택 | 문서화된 트레이드오프 | 일반적인 제안 |
| 코드가 배포되어도 계속 동기화 유지 | 코드베이스 기준으로 새로 고침됨 | 스프린트 3쯤 되면 낡아집니다 |
| 엔지니어링에 연결됨 | Alex에게 인계 | 내보내기를 통해 인계 |
| 다이어그램 작성 | 자동 생성 | 자동 생성 |
Bob이(가) AI 팀의 나머지 구성원과 어떻게 협업하는지
Bob은(는) 혼자 일하지 않습니다. 전체 팀과 함께 빌드할 때 핸드오프가 어떻게 이루어지는지 소개합니다.
건설업자를 위해 Bob이 설계하는 것
Bob이 실제 코드에 매핑되는 구체적인 아키텍처 작업을 수행합니다.
- 시스템 설계하기
그린필드 시스템 설계
제약 조건에 맞춰 기술 스택 선택의 근거를 제시하며 시스템을 처음부터 설계합니다.
- 스택 선택하기
스택 선택
프로젝트에 적합한 스택 옵션을 비교하고 팀 규모와 확장성에 맞는 것을 선택합니다.
- 스키마 설계하기
데이터 모델 설계
제품에서 실제로 실행될 쿼리에 맞춰 스키마, 관계, 인덱스를 설계합니다.
- 통합 매핑하기
통합 매핑
통합 작업을 시작하기 전에 서드파티 서비스, 웹훅, 데이터 흐름을 매핑합니다.
- 확장 계획 세우기
성능 및 확장 계획
병목 지점을 파악하고 운영 환경에 영향을 주기 전에 다음 단계의 규모 확장에 대비한 계획을 세웁니다.
- 보안 검토하기
보안 및 규정 준수 검토
인증, 데이터, 개인정보 관련 우려 사항을 식별하고 출시 후가 아니라 설계 단계에서 이를 해결합니다.
Bob과 함께 이 프롬프트를 사용해 보세요
처음부터 시스템 설계하기
@Bob 사용량 기반 과금, 예상 테넌트 10k, 그리고 Stripe Connect 지급을 지원하는 멀티 테넌트 SaaS의 아키텍처를 설계해 주세요. 스택을 선택하고, 서비스 다이어그램을 그리며, 파일 구조를 Alex에게 전달해 주세요.
이유와 함께 스택 선택하기
@Bob 새 제품을 위해 Postgres + Prisma와 PlanetScale + Drizzle 중에서 선택하려고 합니다. 우리의 제약 조건(멀티 리전 읽기, 단일 엔지니어, 100ms p95)을 기준으로 비교하고, 명확한 트레이드오프와 함께 하나를 추천해 주세요.
기존 아키텍처 검토하기
@Bob 현재 API 레이어를 검토해 주세요. 대시보드 엔드포인트에서 800ms p95가 발생하고 있으며 트래픽을 10배까지 확장하고 싶습니다. 병목 지점을 파악하고, 변경 사항을 제안하며, Alex를 위한 마이그레이션 계획을 작성해 주세요.
기능의 데이터 모델 설계하기
@Bob Emma의 PRD에 있는 추천 프로그램을 위한 스키마를 설계해 주세요. 우리가 실제로 실행할 쿼리를 기준으로 엔터티, 관계, 인덱스를 정리해 주세요. 스키마와 마이그레이션 계획을 Alex에게 전달해 주세요.
Bob의 나머지 AI 팀 만나보기
어떤 에이전트도 혼자 일하지 않습니다. 팀원을 탭하면 제품의 각 부분을 어떻게 처리하는지 볼 수 있습니다.
다음 지역의 고객들이 신뢰합니다
자주 묻는 질문
Bob을 활용해 보세요
아무도 구현하지 않는 다이어그램은 그만 그리세요. Bob이 시스템을 설계하면, 당신의 AI Team이 Atoms 안에서 이를 구축하고 동기화를 유지합니다.
