소프트웨어 아키텍트를 위한 35가지 ChatGPT 프롬프트: 더 나은 시스템 설계, 의사결정 전달 및 기술 전략 리드하기

소프트웨어 아키텍트로서 당신은 기술적 깊이와 조직적 넓이 사이에서 끊임없이 균형을 잡아야 합니다. 즉, 확장 가능한 시스템을 설계하고, 지속 가능한 의사결정을 내리며, 엔지니어부터 경영진에 이르는 다양한 청중에게 트레이드오프 (trade-offs)를 전달해야 합니다. 이 35가지 ChatGPT 프롬프트는 시스템 경계 스케치부터 빈틈없는 ADR (Architecture Decision Records) 작성에 이르기까지, 아키텍트가 매일 직면하는 도전 과제들을 위해 특별히 제작되었습니다. 이를 사용하여 더 빠르게 사고하고, 더 명확하게 소통하며, 더 큰 자신감을 가지고 리드하십시오.

시스템 설계 및 아키텍처 패턴 (System Design and Architecture Patterns)

[규모/제약 조건]을 처리해야 하는 [시스템 유형, 예: 실시간 알림 서비스]를 설계하고 있습니다. 이 유스케이스 (use case)에 적합한 2~3가지 아키텍처 패턴 (architectural patterns)을 각 패턴의 트레이드오프 (trade-offs)와 함께 단계별로 설명해 주세요. 그중 하나를 추천하고 그 이유를 설명해 주세요.

[도메인, 예: 멀티 테넌트 SaaS 플랫폼]을 위한 상위 수준 아키텍처 (high-level architecture) 설계를 도와주세요. 주요 구성 요소, 구성 요소 간의 상호작용 방식, 그리고 발생 가능한 병목 지점 (bottlenecks) 또는 장애 지점 (failure points)을 포함해 주세요. 구성 요소별 상세 분석 (component breakdown) 형식과 노트를 포함하여 작성해 주세요.

[프로젝트 설명]을 위해 모놀리식 (monolithic) 아키텍처와 마이크로서비스 (microservices) 아키텍처 중 하나를 선택해야 합니다. 우리 팀 규모가 [X]이고, 예상 트래픽이 [Y]이며, 배포 빈도가 [Z]일 때, 어떤 접근 방식이 더 타당하며 그 이유는 무엇인가요?

회의적인 CTO에게 정당성을 입증해야 하는 상황이라고 가정하고, 이벤트 기반 아키텍처 (event-driven architecture) 패턴을 설명해 주세요. 이것이 적절한 선택인 시점, 해결할 수 있는 문제, 그리고 도입 시 발생하는 복잡성을 다루어 주세요.

우리는 [시스템 유형]을 구축 중이며 CQRS와 이벤트 소싱 (event sourcing)을 사용할지 논의 중입니다. 두 패턴을 모두 설명하고, 두 패턴을 함께 사용하는 것이 의미 있는 시점을 기술하며, 우리가 예상해야 할 운영 오버헤드 (operational overhead)를 개략적으로 설명해 주세요.

기술 평가 및 의사결정 (Technology Evaluation and Decision Making)

[특정 유스케이스]를 위해 [기술 A]와 [기술 B]를 비교 평가해야 합니다. 성능 (performance), 확장성 (scalability), 생태계 성숙도 (ecosystem maturity), 운영 복잡성 (operational complexity), 비용 (cost), 커뮤니티 지원 (community support)을 아우르는 구조화된 비교표를 만들어 주세요. 마지막으로 권장 사항을 결론으로 제시해 주세요.

우리는 스택에 [새로운 기술/프레임워크]를 도입하는 것을 고려하고 있습니다.

그것에 대한 기술 레이더 (Technology Radar) 항목 작성을 도와주세요: 어떤 사분면(채택 (Adopt), 시도 (Trial), 평가 (Assess), 보류 (Hold))에 속하는지, 주요 리스크는 무엇인지, 그리고 우리가 추진해야 하는 조건은 무엇인지 포함해 주세요. 우리 팀은 높은 처리량의 이벤트 파이프라인 (Event Pipeline)을 위한 메시지 브로커 (Message Broker)를 평가하고 있습니다. Kafka, RabbitMQ, 그리고 AWS SQS/SNS를 내구성 (Durability), 순서 보장 (Ordering Guarantees), 처리량 (Throughput), 그리고 운영 부담 (Operational Burden) 측면에서 비교해 주세요. [우리의 특정 시나리오]에 가장 적합한 것은 무엇인가요? [구성 요소, 예: 인증 시스템 (Authentication System)]에 대해 직접 구축할 것인지 구매할 것인지(Build-vs-Buy) 결정해야 합니다. 이 결정을 위한 구조화된 프레임워크를 안내하고 이를 우리의 상황([팀 규모, 예산 범위, 타임라인, 기존 스택])에 적용해 주세요. [데이터베이스 / API 게이트웨이 / CI-CD 도구]를 선정하기 위한 기술 평가 매트릭스 (Technology Evaluation Matrix) 작성을 도와주세요. 평가 기준, 점수 산정 방식 (Scoring Rubric), 그리고 우리의 우선순위([우선순위 목록])에 따라 각 기준의 가중치를 어떻게 설정할지를 포함해 주세요.

기술 문서 및 ADR (Architecture Decision Records)
[예: 공개 API를 위해 REST 대신 GraphQL을 채택하기]로 결정한 것에 대한 아키텍처 결정 기록 (ADR)을 작성해 주세요. 제목 (Title), 상태 (Status), 맥락 (Context), 결정 (Decision), 결과 (Consequences)와 같은 표준 ADR 형식을 사용하세요. 구체적으로 작성하고 우리가 고려했던 대안들도 포함해 주세요. 나는 [아키텍처 결정]을 내렸습니다. 2년 후에 팀에 합류할 신입 엔지니어가 읽어도 이해할 수 있도록 근거 (Rationale)를 문서화하는 것을 도와주세요. 당시 우리가 처했던 제약 사항 (Constraints)과 어떤 상황이 발생했을 때 이 결정을 재검토해야 하는지도 포함해 주세요. [시스템 이름]에 대한 시스템 아키텍처 개요 문서를 작성해 주세요. 목적 (Purpose), 주요 구성 요소 (Key Components), 데이터 흐름 (Data Flow), 외부 의존성 (External Dependencies), 배포 모델 (Deployment Model), 그리고 알려진 한계점 (Known Limitations)을 포함해야 합니다. 대상 독자는 팀에 합류하는 중간 레벨 엔지니어입니다. 우리는 [시스템]에 대한 통합 아키텍처 (Integration Architecture)를 문서화해야 합니다. 인증 (Authentication), 주요 엔드포인트 또는 이벤트 (Key Endpoints or Events), 에러 처리 기대치 (Error Handling Expectations), 그리고 SLA 약속 (SLA Commitments)을 다루는 기술 통합 가이드를 작성해 주세요. 어조는 정확하고 실용적이어야 합니다. [시스템 유형]에 대한 살아있는 아키텍처 다이어그램 설명(텍스트 또는 Mermaid 형식)을 만드는 것을 도와주세요.

서비스, 데이터베이스, 메시지 큐(Message Queues), 그리고 외부 API를 포함해 주세요. 데이터 흐름(Data Flow) 방향과 동기(Synchronous) 대 비동기(Asynchronous) 통신 여부에 대한 주석을 추가해 주세요.

팀 간 커뮤니케이션 및 이해관계자 정렬 (Cross-Team Communication and Stakeholder Alignment)

비기술직 이해관계자(Non-technical stakeholders)에게 제안된 아키텍처 변경 사항을 발표해야 합니다. [기술적 결정, 예: 모놀리스(Monolith)에서 마이크로서비스(Microservices)로의 전환]을 리스크 감소, 인도 속도(Speed of delivery), 비용 영향에 초점을 맞추어 비즈니스 용어로 번역하는 것을 도와주세요.

엔지니어링 리더십을 위해 [기술적 이니셔티브, 예: 서비스 메시(Service Mesh) 도입]에 왜 투자해야 하는지 설명하는 원페이저(One-pager)를 작성해 주세요. 우리가 해결하려는 문제, 제안된 솔루션, 타임라인, 예상 비용, 그리고 조치를 취하지 않았을 때의 리스크를 다루어야 합니다.

[예: API 설계 표준]에 대해 서로 상충하는 선호도를 가진 두 엔지니어링 팀의 의견을 조율해야 합니다. 양측의 관점을 모두 인정하고, 실제 트레이드오프(Trade-offs)를 드러내며, 팀이 합의된 결정(Consensus decision)으로 나아갈 수 있도록 안내하는 토론 프레임워크 초안 작성을 도와주세요.

[제안된 변경 사항, 예: 새로운 배포 파이프라인으로의 이동]에 대한 RFC(Request for Comments) 작성을 도와주세요. 배경, 동기, 제안된 솔루션, 고려된 대안, 그리고 미결 질문(Open questions)을 포함해야 합니다. 내부 엔지니어링 청중을 위한 형식으로 작성해 주세요.

[예: 심각한 아키텍처 부채를 유발하는 기능 추가]와 같은 이해관계자의 요청에 대해 반대 의견을 전달해야 합니다. 외교적이고 기술적 근거가 있으며, 대안적인 경로를 제안하는 답변 초안 작성을 도와주세요.

코드 품질 및 엔지니어링 표준 (Code Quality and Engineering Standards)

[시스템 유형]에 대한 아키텍처 피트니스 함수(Architectural fitness functions) 세트를 정의하는 것을 도와주세요. 이는 우리의 아키텍처가 시간이 지나도 원칙에 부합하는지 검증할 수 있는 자동화 가능한 체크 항목이어야 합니다. 결합도(Coupling), 테스트 커버리지(Test coverage), 의존성 규칙(Dependency rules), 그리고 성능 예산(Performance budgets)에 대한 예시를 포함해 주세요.

우리 엔지니어링 조직을 위한 API 설계 표준을 수립하고 싶습니다. 명명 규칙(Naming conventions), 버전 관리 전략(Versioning strategy), 에러 응답 형식(Error response formats), 페이지네이션(Pagination), 그리고 인증 패턴(Authentication patterns)을 다루는 간결한 API 설계 가이드라인 초안을 작성해 주세요. 각 항목에 대해 권장 사항(Do)과 금지 사항(Don't) 예시를 포함해 주세요.

우리는 코드베이스에서 아키텍처 드리프트 (Architectural Drift) 현상을 목격하고 있습니다. 팀들이 우리가 의도한 설계와 충돌하는 로컬 결정을 내리고 있습니다. 팀의 속도를 늦추지 않으면서도 전체적인 그림(Big Picture)의 일관성을 유지할 수 있는 가벼운 아키텍처 거버넌스 (Architectural Governance) 프로세스를 설계하도록 도와주세요. 특히 아키텍처 수준의 고려 사항을 위한 코드 리뷰 체크리스트를 작성해 주세요. 관심사 분리 (Separation of Concerns), 의존성 방향 (Dependency Direction), 에러 처리 전략 (Error Handling Strategy), 관찰 가능성 훅 (Observability Hooks), 그리고 정의된 패턴 준수와 관련된 항목들을 포함해 주세요. 기술적 의사결정을 가이드할 수 있는 우리 팀의 엔지니어링 원칙 (Engineering Principles)을 작성하도록 도와주세요. 우리는 [예: 단순성, 운영 가능성, 점진적 인도]를 가치 있게 여깁니다. 이러한 가치들을 짧은 설명과 각 항목에 대한 예시를 포함한 6~8개의 실행 가능한 원칙으로 변환해 주세요.

확장성 (Scalability), 성능 (Performance) 및 신뢰성 (Reliability)
우리의 [서비스/시스템]이 부하 상황에서 성능 저하를 겪고 있습니다. 관찰 가능성 신호 (Observability Signals)에서 시작하여 코드 및 인프라 수준의 원인으로 내려가는, 병목 현상 (Bottleneck)을 진단하기 위한 체계적인 접근 방식을 안내해 주세요. [시스템 유형]을 위해 [읽기/쓰기 패턴]을 처리하는 캐싱 전략 (Caching Strategy)을 설계하도록 도와주세요. 캐시 배치 (클라이언트, CDN, 애플리케이션, 데이터베이스), 제거 정책 (Eviction Policy), 캐시 무효화 (Cache Invalidation) 방식, 그리고 캐시 스탬피드 (Cache Stampedes)를 처리하는 방법을 포함해 주세요. 전체적인 재작성 없이 현재 트래픽의 10배를 수용할 수 있도록 설계해야 합니다. 우리의 현재 아키텍처를 검토해 주세요: [간략하게 설명]. 확장성을 개선하기 위해 우리가 수행할 수 있는 가장 영향력이 큰 세 가지 변경 사항을 식별하고, 각 변경 사항으로부터 기대되는 이득을 설명해 주세요. SLA 목표가 [예: 99.9%]인 [서비스 유형]을 위한 신뢰성 전략 (Reliability Strategy)을 설계해 주세요. 결함 허용 패턴 (Fault Tolerance Patterns; 재시도, 서킷 브레이커, 폴백), 폭발 반경 (Blast Radius)을 줄이기 위한 배포 전략, 그리고 가용성 (Availability)을 측정하고 보고하는 방법을 포함해 주세요. [시스템]을 위한 카오스 엔지니어링 (Chaos Engineering) 계획 연습을 수행하도록 도와주세요.

우리가 테스트해야 할 상위 5가지 장애 시나리오를 식별하고, 운영 환경과 유사한 조건에서 각 장애를 어떻게 안전하게 주입할 수 있는지, 그리고 각 실험 동안 어떤 정상 상태 지표 (Steady-state metrics)를 모니터링해야 하는지 알려주세요.

보안 및 컴플라이언스 아키텍처 (Security and Compliance Architecture)
STRIDE 프레임워크를 사용하여 [시스템/기능 설명]에 대한 위협 모델링 (Threat modeling) 연습을 수행하세요. 각 카테고리별 위협을 식별하고, 심각도를 평가하며, 심각도가 높은 각 위협에 대한 완화 방법 (Mitigation)을 제안하세요.

[시스템 유형]을 위한 제로 트러스트 (Zero-trust) 보안 아키텍처 설계를 도와주세요. 신원 확인 (Identity verification), 네트워크 분할 (Network segmentation), 최소 권한 접근 제어 (Least-privilege access controls)를 다루고, 각 원칙이 우리의 스택 [스택 설명] 내 특정 구현 결정에 어떻게 매핑되는지 설명하세요.

우리 플랫폼이 [컴플라이언스 표준, 예: SOC 2 Type II / GDPR / HIPAA] 준수를 달성해야 합니다. 제어 도메인별로 정리된, 우리가 구현해야 할 기술적 통제 항목 (Technical controls)에 대한 아키텍처 체크리스트를 작성하세요.

[클라우드 네이티브 (Cloud-native) / 하이브리드 (Hybrid)] 환경을 위한 비밀 관리 (Secrets management) 전략을 설계하세요. 비밀 저장, 순환 정책 (Rotation policies), 접근 제어, 감사 로깅 (Audit logging), 그리고 코드나 설정 파일에 노출되지 않고 런타임 시 서비스에 비밀이 주입되는 방법을 다루세요.

외부 감사인에게 우리의 보안 아키텍처를 발표해야 합니다. 우리의 심층 방어 (Defense-in-depth) 접근 방식, 데이터 분류 (Data classification), 암호화 전략 (Encryption strategy), 접근 제어 모델 (Access control model), 그리고 사고 대응 태세 (Incident response posture)를 포괄하는 [시스템] 보안 아키텍처 서술문을 작성하는 것을 도와주세요.

35가지 프롬프트 전체를 한곳에서 확인하기
이 프롬프트들이 유용했다면, 보너스 프롬프트와 사용법이 포함된 바로 사용 가능한 툴킷으로 35가지를 모두 정리해 두었습니다.
이 직업군을 위한 전체 AI 프롬프트 툴킷 받기 → ChatGPT, Claude, DeepSeek에서 작동합니다.