AI에게 아키텍처를 질문할 때 프롬프트를 얼마나 구체적으로 작성해야 하는가
AI에게 시스템 아키텍처를 질문할 때 자주 발생하는 문제가 있다.
처음에는 단순히:
“현재 구조가 비효율적인 것 같다”라는 정도의 정보만 전달한다.
그러면 AI는 대부분 다음 기준으로 답변하게 된다.
- 일반적인 Best Practice
- 평균적인 클라우드 아키텍처
- 범용적인 확장 구조
- 일반적인 SaaS/MSA 패턴
대표적으로 아래와 같은 구조를 추천하게 된다.
CronJob
↓
Queue
↓
Always-On Worker Pool즉:
- Queue 기반 처리
- Worker 재사용
- JVM 재사용
- Pod 수 감소
- Startup 비용 감소
를 중심으로 접근한다.
그리고 대부분의 일반적인 시스템에서는 실제로 이 방향이 맞다.
그런데 실제 운영 환경의 제약 조건이 추가되면 결과가 완전히 달라진다
예를 들어 아래 조건들이 뒤늦게 추가되었다고 가정해보자.
- 외부 연계가 매우 많음
- Job별 dependency 차이가 큼
- Job별 배포 주기가 다름
- 긴급 배포 빈도가 높음
- Job 장애 격리가 중요함
- 최신 Docker Image 자동 반영 필요
- Job 완료 후 JVM 종료 필요
- 오래 살아있는 Worker가 오히려 장애 유발 가능이 조건들이 추가되는 순간 AI의 결론은 완전히 바뀐다.
기존에는:
“Always-On Worker 구조가 정답”이라고 판단했지만,
제약 조건이 추가되면:
“현재 Job per Pod 구조가 오히려 타당”이라는 결론으로 변경된다.
왜 이런 일이 발생하는가
AI는 기본적으로:
“주어진 정보”를 기반으로 최적화를 수행한다.
즉 처음 질문이:
“Spring Batch startup 이 느린데 어떻게 개선할까요?”정도 수준이면 AI는 일반적으로 다음을 우선 고려한다.
- startup 비용 감소
- pod 수 감소
- worker 재사용
- queue 기반 확장
- JVM warm 상태 유지
왜냐하면 대부분의 일반적인 시스템에서는 이것이 맞기 때문이다.
하지만 실제 시스템은 “제약 조건”이 훨씬 중요한 경우가 많다
실제 운영 환경에서는 종종:
“범용적인 베스트 프랙티스”보다
“운영 제약 조건”이 더 중요하다.
예를 들어 어떤 시스템은:
- 성능 최적화
- 리소스 효율
보다도,
- 독립성
- 장애 격리
- 배포 안정성
- 외부 연계 안정성
이 훨씬 중요할 수 있다.
프롬프트가 모호하면 발생하는 현상
예를 들어 아래 질문은 매우 흔하다.
Spring Batch를 EKS CronJob으로 돌리는데 startup이 느립니다.
어떻게 개선할까요?이 질문만 보면 AI는 거의 반드시 다음을 추천하게 된다.
Always-On Worker 구조
Queue 기반 처리왜냐하면:
- 일반적인 클라우드 환경
- 일반적인 Batch 시스템
- 일반적인 Microservice 구조
에서는 그게 맞기 때문이다.
하지만 실제 운영 환경에 이런 조건이 있었다면?
- Job 완료 후 Pod 종료 필요
- 다음 실행 시 최신 Docker Image 자동 반영 필요
- Job별 외부 연계 SDK 충돌 가능
- Job별 dependency 차이 큼
- 오래 살아있는 Worker가 오히려 장애 유발 가능
- 긴급 배포가 매우 빈번
- 특정 Job 장애가 다른 Job에 영향 주면 안 됨이 조건이 추가되는 순간 AI의 판단은 완전히 달라진다.
즉:
“현재 구조를 유지하면서 startup만 최적화”가 더 현실적인 방향이 된다.
결국 AI의 답변 품질은 “프롬프트의 구체성”에 비례한다
즉 AI가 틀린 것이 아니라:
입력된 제약 조건이 부족했던 것이다.
AI는 기본적으로:
“평균적인 시스템”을 가정해서 답변한다.
따라서 실제 시스템이:
- 대규모 외부연계형
- Enterprise SI 구조
- 독립 배포형 Batch Runtime
- 강한 장애 격리 요구
같은 특수성을 가진다면 반드시 그것을 프롬프트에 포함해야 한다.
좋은 프롬프트는 “현재 구조”보다 “제약 조건”을 설명한다
많은 사람들이:
현재 구조 설명만 한다.
하지만 실제로 더 중요한 것은:
왜 그렇게 설계할 수밖에 없는가이다.
아래 두 질문은 비슷해 보이지만 결과는 완전히 달라진다.
모호한 질문
Spring Batch를 EKS CronJob으로 돌리는데 startup이 느립니다.
개선 방안을 알려주세요.→ 일반적인 Worker Pool 구조 추천 가능성 높음.
제약 조건까지 포함한 질문
Spring Batch를 EKS CronJob으로 운영 중입니다.
다만:
- Job별 독립 배포가 필요합니다.
- Job 완료 시 Pod 종료를 유지해야 합니다.
- 다음 실행 시 최신 Docker Image 자동 반영이 중요합니다.
- 외부 연계가 많아 오래 살아있는 Worker가 오히려 장애 원인이 됩니다.
- Job별 dependency 및 SDK 차이가 큽니다.
- 특정 Job 장애가 다른 Job에 영향을 주면 안 됩니다.
이 조건을 유지한 상태에서 startup 최적화 방안을 고민하고 있습니다.→ 이 경우 AI는:
- 구조 변경보다
- Cold Start 최적화
- Spring Boot Startup 최적화
- JVM 최적화
- ClassPath 최소화
방향으로 접근하게 된다.
핵심 정리
AI에게 아키텍처를 질문할 때 중요한 것은:
“현재 구조”보다
“현재 구조를 유지해야 하는 이유”를 설명하는 것이다.
즉:
베스트 프랙티스는 항상 존재하지만,
실제 운영에서는 제약 조건이 베스트 프랙티스를 바꾼다.그리고 AI는 그 제약 조건이 프롬프트에 포함되어야만 올바른 방향으로 추론할 수 있다.