AI가 모호한 프롬프트를 프로덕션 준비 아키텍처로 바꾸는 방법

“프롬프트에서 아키텍처까지”가 실제로 의미하는 바

대부분의 아이디어는 스펙이 아니라 의도에서 출발하기 때문에 ‘모호한 프롬프트’가 일반적인 시작점입니다: “고객 포털을 만들자”, “AI 검색을 추가하자”, 또는 “이벤트를 실시간으로 스트리밍하자.” 사람들은 원하는 결과는 알고 있지만, 그것을 가능하게 하는 경계, 리스크, 엔지니어링 선택은 아직 모릅니다.

“프롬프트에서 아키텍처까지”는 그 의도를 일관된 계획으로 바꾸는 워크플로입니다: 무엇을 만들지, 구성 요소들이 어떻게 맞물리는지, 데이터가 어디로 흐르는지, 그리고 프로덕션에서 작동하려면 무엇이 성립되어야 하는지.

“프로덕션 준비 아키텍처”가 의미하는 것

프로덕션 준비는 단순히 ‘다이어그램이 있다’는 뜻이 아닙니다. 설계가 명시적으로 다루어야 할 항목은 다음과 같습니다:

• 신뢰성: 무엇이 고장 나는가, 어떻게 복구하는가, 부하 상황에서는 무슨 일이 일어나는가
• 보안: 접근은 어떻게 통제되는가, 비밀은 어떻게 저장되는가, 위협은 어떻게 완화되는가
• 비용: 지출을 유발하는 요소와 이를 어떻게 모니터링/통제할 것인가
• 운영성: 모니터링, 백업, 배포, 그리고 새벽 2시에 실패를 어떻게 디버그할 것인지

AI가 도움이 되는 부분 — 그리고 오해를 유발하는 부분

AI는 초기 사고를 가속화하는 데 강합니다: 후보 아키텍처 생성, 일반적인 패턴(큐, 캐시, 서비스 경계) 제안, 누락된 비기능 요구사항 표면화, 인터페이스 계약이나 체크리스트 초안 작성 등입니다.

반면 검증할 수 없는 구체사항에 대해 자신감 있게 말할 때 오해를 부를 수 있습니다: 맥락 없이 기술을 선택하거나 운영 복잡도를 과소평가하거나, 조직만 아는 제약(규정 준수, 기존 플랫폼, 팀 역량)을 건너뛸 수 있습니다. AI의 출력을 수용해야 할 답이 아니라 도전할 제안으로 취급하세요.

이 글이 다루는 것과 다루지 않는 것

이 글은 프롬프트 → 요구사항 → 가정 → 옵션 → 결정으로 이어지는 실용적이고 반복 가능한 워크플로를 다루며, 트레이드오프를 추적할 수 있게 합니다.

도메인 전문성, 상세한 사이징, 보안 검토를 대체하지는 않으며 모든 프롬프트에 대한 단일 ‘정답’이 있다고 주장하지도 않습니다.

1단계: 프롬프트를 명확한 문제 진술로 바꾸기

모호한 프롬프트는 보통 목표(“대시보드 만들기”), 솔루션(“마이크로서비스 사용”), 의견(“빠르게 만들자”)을 섞어 놓습니다. 컴포넌트를 스케치하기 전에 테스트하고 논쟁할 수 있을 만큼 구체적인 문제 진술이 필요합니다.

문제 진술(누가 무엇을, 왜 지금 필요한가)

주요 사용자, 그들이 하려는 작업, 그리고 긴급성을 명시하는 한두 문장을 작성하세요.

예: “고객 지원 매니저는 열려 있는 티켓과 SLA 위험을 한눈에 볼 수 있어야 하며, 이를 통해 일별 우선순위를 정하고 이번 분기 놓친 SLA를 줄여야 한다.”

프롬프트가 실제 사용자를 지정하지 않으면 물어보세요. 시급성이 없으면 나중에 트레이드오프를 정렬할 수 없습니다.

성공 지표(어떻게 성공을 알 수 있는가)

‘좋다’를 측정 가능한 결과로 바꾸세요. 제품 신호와 운영 신호를 혼합하는 것이 좋습니다.

• 제품: 주요 작업 완료 시간, 채택률, 오류율, 전환율, NPS
• 운영: p95 지연 시간, 가동 시간 목표, 요청당 비용, 온콜 페이지/주

작은 집합(3–5개)을 선택하세요. 너무 많은 지표는 혼란을 만들고, 너무 적으면 리스크를 숨깁니다.

사용자 여정과 핵심 흐름

먼저 ‘해피 패스’를 평이한 언어로 설명하고, 그 다음 아키텍처를 형성할 엣지 케이스를 나열하세요.

해피 패스 예: 사용자가 로그인 → 고객 검색 → 현재 상태 확인 → 필드 업데이트 → 감사 로그 기록.

초기 표면화할 엣지 케이스: 오프라인/불안정한 연결, 부분 권한, 중복 레코드, 대량 임포트, 타임아웃 및 재시도, 의존성이 다운되었을 때의 동작 등.

범위에서 제외할 내용(디자인 확장 방지)

이번 버전에서 만들지 않을 것을 명시하세요: 아직 지원하지 않을 통합, 고급 분석, 멀티 리전, 커스텀 워크플로, 전체 관리자 도구 등. 경계를 명확히 하면 일정 보호와 이후 ‘2단계’ 대화가 쉬워집니다.

이 네 가지가 작성되면 프롬프트는 공유된 계약이 됩니다. AI는 이를 다듬는 데 도움이 될 수 있지만, 발명해서는 안 됩니다.

2단계: 요구사항과 제약 추출

모호한 프롬프트는 종종 목표(“사용하기 쉽게”), 기능(“알림 전송”), 선호(“서버리스 사용”)을 한 문장에 섞어둡니다. 이 단계는 이를 분리하여 설계할 수 있는 요구사항 목록으로 만드는 과정입니다.

기능적 요구사항(무엇을 해야 하는가)

구체적 동작과 그것이 건드리는 이동 부품을 뽑아내세요:

• 기능들: 사용자 가입/로그인, 검색, 체크아웃, 관리자 대시보드, 감사 로그
• 데이터: 무엇을 저장하는가(사용자, 주문, 이벤트), 보존 기간, 접근 권한
• 통합: 결제 제공자, 이메일/SMS, CRM, 분석, 기존 내부 API

좋은 체크: 각 요구사항에 대해 화면, API 엔드포인트, 또는 백그라운드 작업을 가리킬 수 있는가?

비기능적 요구사항(얼마나 잘 해야 하는가)

이것들은 대부분의 사람들이 생각하는 것보다 아키텍처를 더 많이 형성합니다. 모호한 문구를 측정 가능한 목표로 바꾸세요:

• 지연: “페이지가 빠르다” → “요청의 95%가 300ms 이하”
• 가동시간: “항상 사용 가능” → “월별 99.9% 가동시간”
• 개인정보/규정: “EU 고객을 처리” → “GDPR 기본: 삭제 요청, 데이터 내보내기, 최소 보존”

제약(변경할 수 없는 것)

초기에 경계를 캡처하세요. 이상적인 시스템을 설계했다가 출시할 수 없는 상황을 피하기 위함입니다:

• 예산 & 일정: 고정된 출시일, 클라우드 지출 한도
• 팀 역량: Python에 능숙, Kubernetes 경험 제한
• 기존 시스템: 현재 데이터베이스, SSO, 메시지 버스 사용 필수

수용 기준(평이한 언어로)

다음과 같은 “완료 의미” 문장을 몇 개 적으세요:

• “새 사용자는 2분 이내에 등록, 이메일 확인, 로그인할 수 있다.”
• “지원팀은 주문 환불을 처리하면 1분 이내에 고객이 확인을 받는다.”
• “개인 데이터는 요청 시 삭제될 수 있어야 하며 백업 포함 30일 내에 처리된다.”

이 요구사항과 제약은 다음 단계에서 비교할 후보 아키텍처들의 입력이 됩니다.

3단계: 가정과 미지수를 조기에 표면화

모호한 프롬프트가 실패하는 이유는 기술이 어렵기 때문이 아니라, 모두가 누락된 세부사항을 서로 다르게 가정하기 때문인 경우가 많습니다. 어떤 아키텍처를 제안하기 전에 AI를 사용해 그 암묵적 가정들을 드러내고 사실과 추측을 분리하세요.

자주 숨겨지는 가정들

사람들이 보통 암묵적으로 전제하는 ‘기본값’을 적어보세요:

• 트래픽과 성장: 하루 50명 사용자인가, 동시 5만 명을 감당해야 하는가? 사용량이 급증하는가(출시) 아니면 안정적인가?
• 데이터 품질: 들어오는 데이터가 정돈되어 있나, 중복/누락/비정형이 많은가?
• 사용자 행동: 사용자는 지연을 참는가? 적극적으로 재시도하는가? 실시간 업데이트를 기대하는가?
• 운영: 누가 운영을 지원하는가? 온콜이 있는가? 주말 장애가 허용되는가?

이런 가정들이 캐싱, 큐, 저장소, 모니터링, 비용 등에 큰 영향을 미칩니다.

“알고 있는 것” vs “모르는 것” vs “조사 필요”로 분리

AI에게 간단한 표(또는 세 개의 짧은 목록)를 만들어 달라고 하세요:

• 알고 있는 것(knowns): 프롬프트나 이해관계자가 확인한 항목
• 모르는 것(unknowns): 자신감 있는 결정을 가로막는 누락된 세부사항
• 조사 필요(needs research): 스파이크, 벤더 확인, 벤치마크, 법적 검토, 사용자 테스트가 필요한 질문

이렇게 하면 AI(와 팀)가 추측을 사실로 취급하는 일을 방지할 수 있습니다.

설계에 앞서 AI가 물어야 할 질문들

유용한 질문 예시:

• 상위 3개 사용자 여정은 무엇이며, 각 여정에서 ‘충분히 빠름’의 의미는 무엇인가?
• 어떤 데이터를 얼마 동안 저장해야 하고 누가 접근할 수 있는가?
• 어떤 실패 모드가 허용되는가(부분 장애, 지연 처리, 읽기 전용 모드)?
• 어떤 통합이 존재하며 그들의 레이트 리밋과 신뢰성은 어떤가?
• 고정된 제약은 무엇인가: 예산, 마감, 클라우드/호스트, 규정?

가정을 문서화하여 나중에 도전할 수 있게 하기

가정을 명시적으로 적으세요(예: “최대 피크 2,000 req/min 가정”, “PII 존재 가정”). 각 가정에 누가 언제 확인했는지 연결해두면 나중에 트레이드오프와 아키텍처 변경을 설명하고 방어하며 되돌리기 쉬워집니다.

4단계: 하나의 답이 아닌 후보 아키텍처 제시

모호한 프롬프트는 거의 단일 ‘정답’을 암시하지 않습니다. 프로덕션 준비 계획에 가장 빨리 도달하는 방법은 몇 가지 실행 가능한 옵션을 스케치한 다음 기본값을 선택하고 무엇이 바뀌면 전환할지 분명히 설명하는 것입니다.

옵션 A(기본): 단순 모놀리식 + 관리형 서비스

초기 단계 제품의 대부분은 하나의 배포 가능한 백엔드(API + 비즈니스 로직), 단일 데이터베이스, 소수의 관리형 서비스(인증, 이메일, 오브젝트 스토리지)로 시작하세요. 이렇게 하면 배포, 디버깅, 변경이 간단합니다.

다음과 같은 경우 이 옵션을 선택하세요: 팀이 작고 요구사항이 변동하며 트래픽이 불확실할 때.

옵션 B: 표준 모듈형 모놀리식 + 비동기 작업

동일한 단일 배포이지만 내부 모듈(결제, 사용자, 리포팅)을 명시하고 느린 작업(임포트, 알림, AI 호출)을 위한 백그라운드 워커를 둡니다. 큐와 재시도 정책을 추가하세요.

다음과 같은 경우 선택하세요: 장시간 실행 작업이 있거나 주기적 스파이크가 있거나 책임 경계가 더 명확해야 할 때—서비스로 분리하지 않고도.

옵션 C: 확장 가능한 서비스(요구사항이 명확할 때만)

격리(규정 준수), 특정 핫스팟의 독립적 스케일링(예: 미디어 처리), 또는 별도 릴리스 주기가 강력한 동인일 때 일부 컴포넌트를 분리하세요.

다음과 같은 경우 선택하세요: 특정 부하 패턴, 조직 경계, 또는 위험 제약이 추가 운영 부담을 정당화할 때.

옵션 간 차이점

옵션들 전반에서 차이점을 명확히 하세요:

• 컴포넌트: 단일 API vs API+워커 vs 다중 배포물
• 비용: 적은 구성요소 vs 추가 큐/모니터링/서비스 간 트래픽
• 복잡성: 로컬 개발이 단순 vs 더 많은 배포, 버전 관리, 실패 모드

좋은 AI 보조 출력은 작은 결정 표입니다: “기본 = A, 백그라운드 작업이 있으면 B로 전환, X 메트릭/제약이면 C로 전환.” 이렇게 하면 조기 마이크로서비스화가 방지되고 아키텍처가 실제 요구사항에 묶입니다.

5단계: 데이터와 경계 모델링

놀랍도록 많은 ‘아키텍처’는 사실 시스템의 데이터가 무엇인지, 어디에 저장되는지, 누가 변경할 수 있는지에 동의하는 것입니다. 이를 조기에 모델링하면 이후 단계(컴포넌트, 인터페이스, 스케일링, 보안)가 훨씬 덜 추측성 있게 됩니다.

핵심 도메인 객체 정의(그리고 누가 소유하는지)

시스템이 중심으로 다루는 몇 가지 객체(보통 프롬프트의 명사)를 이름으로 정하세요: User, Organization, Subscription, Order, Ticket, Document, Event 등. 각 객체에 대해 소유권을 캡처하세요:

• 진실의 출처: 어떤 시스템/서비스가 업데이트를 쓸 수 있는가?
• 읽는 주체: 누가 소비하는가(다른 서비스, 분석, 고객지원)?
• 수명주기: 생성/수정/삭제, 그리고 ‘소프트 삭제’ 규칙

AI는 프롬프트로부터 초기 도메인 모델을 제안하는 데 유용합니다. 그런 다음 실제와 암시된 것을 확인하세요.

접근 패턴에 맞는 저장소 패턴 선택

각 객체가 주로 트랜잭션(OLTP)—작은 읽기/쓰기 다수 및 일관성이 필요한지—아니면 분석(집계, 트렌드, 리포팅)에 더 적합한지 결정하세요. 두 가지 요구를 한 DB에 섞으면 긴장이 발생하기 쉽습니다.

일반 패턴: 앱은 OLTP DB, 분석은 이벤트나 익스포트로 채워지는 별도 분석 저장소. 핵심은 저장소를 ‘개념적 느낌’이 아니라 데이터 사용 방식에 맞추는 것입니다.

엔드 투 엔드 데이터 흐름 계획

데이터가 시스템을 통과하는 경로를 스케치하세요:

• 수집: API, 업로드, 웹훅, 배치 임포트
• 변환: 검증, 보강, 중복 제거
• 보존과 삭제: 데이터 보존 기간과 삭제 방식

데이터 리스크 조기 표면화

리스크를 명시적으로 호출하세요: PII 취급, 중복 레코드, 충돌하는 소스(두 시스템이 진실을 주장), 불명확한 삭제 의미 등. 이런 리스크는 경계를 정의합니다: 무엇을 내부에만 두고 무엇을 공유할 수 있는지, 감사 로그나 접근 제어가 필요한지를 결정합니다.

6단계: 컴포넌트와 인터페이스 매핑

경계와 데이터가 정해지면 이를 구체적인 컴포넌트 맵으로 변환하세요: 무엇이 존재하고, 무엇을 소유하며, 어떻게 나머지와 통신하는지. 여기서 AI는 ‘단어로 다이어그램을 생성하는 도구’로 가장 유용합니다—명확한 분리를 제안하고 누락된 인터페이스를 찾아낼 수 있습니다.

모듈과 책임 정의

작고 명확한 소유권을 가진 컴포넌트 집합을 목표로 하세요. 좋은 체크는: “이게 고장 나면 누가 고치고 무엇을 바꾸는가?” 예:

• API Gateway / BFF: 요청 라우팅, 인증 시행, 레이트 리밋
• 핵심 서비스들: 비즈니스 규칙과 워크플로
• 데이터 저장소들: 지속성 및 쿼리 패턴(단순히 ‘데이터베이스’라고 하지 않음)
• 비동기 워커: 장기간 작업, 재시도, 스케줄 작업
• 관측 가능성: 로깅, 메트릭, 트레이싱(우선순위 컴포넌트로 다룸)

컴포넌트 간 통신 방식 선택(및 이유)

기본 통신 스타일을 선택하고 예외를 정당화하세요:

• REST/HTTP: 단순한 요청/응답과 사람이 디버그하기 쉬운 흐름
• 이벤트/퍼브섭: 여러 소비자가 동일 변경에 반응할 때
• 큐: 백그라운드 작업, 버스트 흡수, 신뢰 가능한 재시도를 위해

AI는 각 사용 사례를 지연 시간과 신뢰성 요구사항을 만족시키는 가장 단순한 인터페이스에 매핑해줄 수 있습니다.

외부 의존성 및 실패 동작

서드파티 서비스들을 나열하고, 그들이 실패할 때 무엇이 발생할지 결정하세요:

• 타임아웃, 백오프 재시도, 회로 차단기
• 열화 모드(캐시된 데이터 제공? 읽기 전용 허용?)
• 명확한 오류 계약(클라이언트가 기대할 수 있는 것)

통합 맵(시스템, API, 인증)

간결한 “통합 테이블”을 작성하세요:

• Payments → 제공자 API (REST), OAuth2 client credentials, 멱등 키
• Email/SMS → 메시징 API (REST), API key, 5xx 시 재시도 큐
• Analytics → 이벤트 스트림, 서비스 토큰, 과부하 시 드롭 정책

이 맵은 구현 티켓과 리뷰 토론의 중추가 됩니다.

7단계: 코딩 전에 프로덕션 고려사항 설계

화이트보드에서는 완벽해 보이던 설계가 실제 프로덕션에서 첫날에 실패할 수 있습니다. 코드 작성 전에 ‘프로덕션 계약’을 명시하세요: 부하, 실패, 공격 시 어떻게 동작하고, 어떻게 이를 감지할 것인지.

신뢰성: 실패 경로 계획

의존성이 느리거나 다운되었을 때 시스템이 어떻게 동작하는지 정의하세요. 타임아웃, 지터 있는 재시도, 명확한 회로 차단기 규칙을 추가하세요. 요청 ID나 멱등 키를 이용해 작업을 멱등으로 만드세요(재시도 안전).

서드파티 API를 호출하면 레이트 리밋을 가정하고 백프레셔를 구축하세요: 큐, 유계 동시성, 우아한 열화(예: ‘나중에 시도’ 응답) 등.

보안: 누가 무엇을 할 수 있는지 결정

인증(신분 증명 방식)과 인가(무엇에 접근 가능한지)를 명시하세요. 상위 위협 시나리오를 적으세요: 토큰 탈취, 공개 엔드포인트 남용, 입력을 통한 인젝션, 권한 상승 등.

또한 비밀 관리를 어떻게 할지: 어디에 저장하고 누가 읽는지, 로테이션 주기, 감사 로그를 정의하세요.

성능: 감이 아닌 목표

용량과 지연 목표(대략이라도)를 설정하세요. 그런 다음 전술을 고르세요: 캐싱(무엇을, 어디에, TTL), 잦은 호출을 줄이기 위한 배칭, 긴 작업을 위한 비동기 처리, 공유 자원 보호를 위한 제한 등.

관측 가능성: 보이지 않으면 고칠 수 없다

구조화된 로그, 핵심 메트릭(지연, 오류율, 큐 깊이), 분산 트레이싱 경계, 기본 알림을 결정하세요. 각 알림은 행동으로 연결하세요: 누가 응답하는가, 무엇을 확인하는가, ‘안전 모드’는 어떤 모습인가.

이 선택들을 1급 아키텍처 요소로 취급하세요—엔드포인트나 데이터베이스만큼 시스템을 형성합니다.

8단계: 트레이드오프를 명시적이고 추적 가능하게 만들기

아키텍처는 ‘최고’의 답이 아니라 제약 하의 선택 집합입니다. AI는 빠르게 옵션을 나열할 수 있지만, 여전히 왜 그 경로를 택했는지, 무엇을 포기했는지, 무엇이 바뀌면 전환할지를 명확히 기록해야 합니다.

단순한 트레이드오프 표 사용

어디에 리스크를 수용하고 어디에 안전장치를 투자할지 결정

“허용 가능한 실패”(예: 가끔 지연되는 이메일)와 “절대 실패하면 안 되는 영역”(예: 결제, 데이터 손실)을 적으세요. 실패 비용이 큰 곳에 안전장치(백업, 멱등성, 레이트 리밋, 명확한 롤백 경로)를 배치하세요.

팀에 영향을 미치는 운영적 트레이드오프

일부 설계는 온콜 부담과 디버깅 난이도를 증가시킵니다(구성요소 증가, 재시도, 분산 로그 증가). 팀의 지원 현실에 맞는 선택을 하세요: 서비스 수를 줄이고, 관측성을 명확히 하며, 예측 가능한 실패 모드를 선호하세요.

기술적 트레이드오프: 관리형 vs 자체 호스팅

판단 기준을 명시하세요: 규정 준수 필요, 커스터마이제이션, 지연, 인력. 비용 때문에 자체 호스팅을 선택하면 숨은 비용(패치, 업그레이드, 용량 계획, 인시던트 대응)을 기록하세요.

9단계: 결정, 대안, 되돌릴 수 있는 계획 캡처

훌륭한 아키텍처는 ‘발생하는’ 것이 아니라 많은 작은 선택의 결과입니다. 그 선택들이 채팅 로그나 누군가의 기억에만 남아 있으면, 팀은 토론을 반복하고 일관성 없이 배포하며 요구사항 변화에 고생합니다.

ADR로 결정을 검색 가능하게 만들기

각 핵심 선택(데이터베이스, 메시징 패턴, 인증 모델, 배포 방식)에 대해 Architecture Decision Record(ADR) 를 만드세요. 짧고 일관된 형식:

• Context: 해결하려는 문제와 제약
• Decision: 선택한 것
• Alternatives considered: 2–3가지 실현 가능한 옵션
• Why: 이유와 트레이드오프
• Consequences: 무엇을 가능하게 하고 무엇을 제한하는가

AI는 토론에서 옵션을 요약하고 트레이드오프를 추출하여 ADR 초안을 작성하는 데 특히 유용합니다. 그런 다음 사람이 정확성을 검토하고 편집하세요.

설계에 ‘출구 경로’ 추가

가정은 변합니다: 트래픽이 예상보다 빨리 증가하거나, 규정이 더 엄격해지거나, 외부 API가 불안정해질 수 있습니다. 각 주요 가정에 대해 출구 경로를 추가하세요:

• “X 요청/초를 넘으면 단일 DB에서 읽기 복제 도입”
• “벤더 API SLA가 Y 이하로 떨어지면 큐+재시도 워커 도입”

이렇게 하면 미래의 변경이 화재 진압이 아니라 계획된 이동이 됩니다.

위험한 선택에 대한 증거 포인트와 버전 관리

위험한 선택에는 스파이크, 벤치마크, 프로토타입, 부하 테스트 같은 검증 가능한 마일스톤을 붙이세요. 기대 결과와 성공 기준을 기록하세요.

마지막으로 ADR을 요구사항이 진화할 때마다 버전 관리하세요. 히스토리를 덮어쓰지 말고 업데이트를 덧붙여 무엇이 언제 왜 바뀌었는지 추적하세요. 가벼운 구조가 필요하면 내부 템플릿(예: /blog/adr-template)과 연결하세요.

10단계: 리뷰와 증거로 아키텍처 검증

초안 아키텍처는 다이어그램이 깔끔하다고 ‘완료’되는 것이 아닙니다. 설계가 작동한다고 합의할 때, 그리고 까다로운 부분에 대한 증거가 있을 때 완성입니다.

집중된 아키텍처 리뷰 실행

짧은 체크리스트로 중요한 질문을 조기에 표면화하세요:

• 보안: 인증/인가 모델, 비밀 관리, 최소 권한, 감사 로그
• 개인정보: 데이터 분류, 보존, 접근 통제, PII 흐름 매핑, 삭제 요청
• 실패 모드: 열화 동작, 재시도와 백오프, 멱등성, 데드레터 큐, 레이트 리밋
• 운영 준비: 모니터링, 알림, 런북, 온콜 소유권, 백업/복구

출력은 구체적이어야 합니다: “우리는 무엇을 할 것인가?” 그리고 “누가 담당인가?” 같은 형태로.

숫자로 검증(희망사항이 아닌 범위)

단일 처리량 추정 대신 불확실성을 반영한 부하 및 비용 범위를 제시하세요:

• 트래픽: P50 / P95 요청/초(예: 일반 50–200 RPS, 피크 500–1,000 RPS)
• 스토리지 증가: 월별 범위와 보존 가정
• 비용 드라이버: API 사용량, 컴퓨트 오토스케일링, 데이터 이그레스, 관리형 DB

AI에게 자신의 수학과 가정을 보여달라고 요청하고, 현재 분석치나 유사 시스템과 함께 상식적 검증을 하세요.

의존성 및 벤더 리스크 평가

중요 의존성(LLM 제공자, 벡터 DB, 큐, 인증 서비스)을 나열하고 각 항목에 대해:

• 이것이 불가용이면 무엇이 깨지는가?
• 제공자 전환은 얼마나 어려운가?
• 계약적, 지역적, 규정적 제약이 있는가?

사람의 승인 시점 정의

리뷰를 명시적으로 만드세요:

• 제품: 사용자 흐름, SLA, 범위 경계
• 보안/프라이버시: 위협 모델 결과, 데이터 취급 승인
• 운영/SRE: 관측 계획, 인시던트 대응, 용량 가정
• 엔지니어링: 인터페이스, 마일스톤, 마이그레이션 계획

이견이 남으면 담당자와 기한을 정해 ‘결정해야 할 항목’으로 기록하고 명확히 진행하세요.

설계 중 AI와 효과적으로 협업하는 방법

AI를 주니어 아키텍트처럼 대하세요: 빠르게 옵션을 생성할 수 있지만 명확한 맥락, 검증, 지시가 필요합니다.

가정과 제약을 드러내는 프롬프트 작성법

AI에게 ‘상자’를 먼저 주세요: 비즈니스 목표, 사용자, 규모, 예산, 마감, 그리고 비협상 항목(기술 스택, 규정, 호스팅, 지연, 데이터 레지던시). 그런 다음 가정과 열린 질문을 먼저 나열하라고 요구하세요.

규정이 중요하면 명시하세요—모델이 자동으로 유추한다고 기대하지 마세요.

구현으로 이어지는 플랫폼의 유용성

‘아키텍처 계획’에서 ‘작동하는 시스템’으로 넘어갈 때 결정 사항이 손실되지 않도록 워크플로 도구가 중요합니다. 예: Koder.ai 같은 플랫폼은 프롬프트 단계의 제약을 구현으로 옮기고, 반복 가능성을 제공하며 준비가 되면 코드 내보내기를 지원합니다.

이는 아키텍처 리뷰의 필요를 없애지 않지만(오히려 가정과 비기능 요구사항 문서화를 강화함), 제안에서 실행으로 빠르게 이동할 수 있게 합니다.

재사용 가능한 프롬프트 템플릿

구조화된 출력을 내는 짧은 템플릿을 사용하세요:

You are helping design a system.
Context: <1–3 paragraphs>
Constraints: <bullets>
Non-functional requirements: <latency, availability, security, cost>
Deliverables:
1) Assumptions + open questions
2) 2–3 candidate architectures with pros/cons
3) Key tradeoffs (what we gain/lose)
4) Draft ADRs (decision, alternatives, rationale, risks)

(위 코드 블록은 변경하지 마세요.)

“비판하고 다듬기” 루프와 반복

첫 번째 초안 요청 후 즉시 비판을 요구하세요:

• “이 설계의 무엇이 취약하거나 리스크가 높은가?”
• “어떤 요구사항이 아직 충족되지 않았는가?”
• “시간이 절반이라면 무엇을 단순화하겠는가?”

모델이 조기에 한 경로에 고정되는 것을 막습니다.

흔한 실패 모드 주시

AI는 자신감 있게 잘못될 수 있습니다. 흔한 문제:

• 사실이 아닌 서비스/기능을 만들어내는 것(출처나 불확실성을 요구하세요)
• 제약(비용, 데이터 레지던시, 팀 역량)을 무시하는 것(각 설계 선택을 요구사항에 연결하도록 요구)
• 과잉 설계(가능한 최소 아키텍처 옵션을 강제하세요)

원하면 출력물을 가벼운 ADR로 캡처해 저장소에 두고 참조하세요(예: /blog/architecture-decision-records).

미니 워크스루: 모호한 프롬프트에서 빌드 준비 플랜으로

모호한 프롬프트 예: “배송이 늦을 때 고객에게 알리는 시스템을 만들어라.”

1) 요구사항으로 바꾸기

AI가 이를 구체적 필요로 번역하도록 도울 수 있습니다:

• 사용자: 운영팀, 최종 고객
• 핵심 흐름: 배송 상태 수집 → 지연 위험 탐지 → 알림 전송 → 결과 추적
• 비기능: 상태 변경 후 2분 이내 알림, 99.9% 가용성, 분쟁을 위한 감사 로그

2) 아키텍처를 바꿀 수 있는 가정들

초기에 두 가지 질문이 설계를 뒤바꿀 수 있습니다:

• 가정 A: 상태 업데이트가 운송사로부터 실시간(웹훅)으로 들어온다면 이벤트 기반 처리 적합
• 가정 B: 업데이트를 15분마다 폴링한다면 스케줄링, 레이트 리밋 처리, 그리고 ‘2분’ SLA는 불가능할 수 있음

이 가정을 적어두면 잘못된 것을 빠르게 만드는 일을 방지합니다.

3) 옵션 → 트레이드오프 결정

AI가 제안하는 후보 아키텍처:

• 옵션 1: 동기 API: 운송사 웹훅 → 지연 점수 서비스 → 알림 서비스

  • 장점: 단순, 구성요소 적음
  • 단점: 웹훅 타임아웃으로 업데이트 손실 가능; 버스트가 점수 서비스 과부하를 초래할 수 있음

• 옵션 2: 큐 기반: 웹훅 → 이벤트 큐에 적재 → 워커가 지연 점수 계산 → 알림

  • 장점: 버스트 흡수, 안전한 재시도, 관측성 개선
  • 단점: 구성요소 증가, 결국 일관성(지연성)

결정 예: 운송사 신뢰성이나 트래픽 스파이크가 리스크라면 큐 기반을 선택하고, 볼륨이 낮고 운송사 SLA가 강하면 동기식 선택을 고려.

4) 빌드 가능하게 만들기 위한 산출물

구현 가능하게 하기 위한 산출물:

• 컨텍스트 및 시퀀스 다이어그램
• 데이터 모델 및 이벤트 스키마
• 큐 vs 동기 선택을 문서화한 ADR
• 런북(실패 모드, 재시도, 온콜 체크)
• 백로그 에픽(운송사 통합, 점수 규칙, 알림 템플릿, 모니터링)