아키텍처 시스템

WHY · HOW IT CHANGES

1. 01

   5단계 진단 인터뷰

   사업 배경 → 시스템 모델 → 업무 프로세스 → 기술 환경 → 성공 지표 순으로 묻되, 질문은 고정 문항이 아니라 이전 답변 전체를 넣어 매번 새로 만듭니다.

   왜 이 단계가 있나

   성공 지표를 맨 끝에 두는 것이 핵심입니다. 앞의 넷을 모르는 상태에서 목표를 물으면 “매출 증대” 같은 공허한 답만 돌아옵니다. 컨설팅 인터뷰의 실제 순서를 그대로 옮겼습니다.

2. 02

   옆길 질문 분리

   사용자가 되묻는 문장을 감지하면 그 입력을 답변으로 저장하지 않고 설명만 한 뒤 진단 단계를 그대로 둡니다.

   왜 이 단계가 있나

   “이게 무슨 뜻이죠?”가 진단 답변으로 기록되면, 그 위에 세운 설계 전체가 어긋난 전제에서 출발합니다.

3. 03

   결손 정보 역질문

   문서나 회의록으로 시작한 경우 빠진 항목을 중요한 것부터 되묻고, 정해진 횟수를 넘기면 중단합니다.

   왜 이 단계가 있나

   빈칸을 AI가 그럴듯하게 메우면 설계 전체가 허구 위에 섭니다. 다만 무한히 묻는 것도 실무에서는 못 씁니다.

4. 04

   요약 확인과 승인 게이트

   수집한 답변을 되보여 주고 일정 제약을 받은 뒤, 정확히 일치하는 승인어가 들어왔을 때만 생성을 시작합니다.

   왜 이 단계가 있나

   부분 일치를 허용하면 “확인해 보고 알려줄게요” 같은 문장이 승인으로 오인됩니다. 긴 생성이 시작되는 자리라 오인의 비용이 큽니다.

5. 05

   성격별 분할 병렬 생성

   하나의 요청을 성격이 다른 여러 호출로 쪼개 동시에 실행합니다. 웹 검색은 시장·업계 분석에만 붙이고 다이어그램과 제안서에는 붙이지 않습니다.

   왜 이 단계가 있나

   검색으로 라이브러리 버전을 물으면 오래된 블로그 글의 버전을 물고 옵니다. 검색은 시장 데이터에, 기술 버전은 별도로 관리하는 레퍼런스에 맡기도록 역할을 갈랐습니다.

6. 06

   이중 출력

   같은 인터뷰 하나로 제안서와 개발 문서를 동시에 만들되 금칙어를 정반대로 겁니다. 제안서에는 기술 용어와 검증되지 않은 수치를 금지하고, 개발 문서에는 산문을 금지하고 함수 시그니처와 스키마를 요구합니다.

   왜 이 단계가 있나

   “쉽게 쓴 같은 문서 두 개”가 아닙니다. 독자가 다르면 금지 사항이 달라집니다. 영업과 개발이 같은 인터뷰에서 출발해야 시간이 지나도 어긋나지 않습니다.

7. 07

   일정 압축 규칙

   일정이 짧아도 단계나 기능 범위를 줄이지 못하게 하고, 기간만 압축하며 병렬 가능한 작업을 동시 배치하도록 세 곳에 같은 금지를 심었습니다.

   왜 이 단계가 있나

   AI에게 촉박한 일정을 주면 기능을 슬쩍 빼서 맞추려 합니다. 기간은 줄이되 범위는 유지하고 대신 병렬화하는 것이 실제 일정 압축 방식입니다.

8. 08

   설계 선행 강제

   스프린트 계획에 UI 설계와 디자인 시스템 구축을 초기 스프린트에 반드시 넣고, 이를 프론트엔드 개발의 선행 조건으로 묶습니다.

   왜 이 단계가 있나

   AI가 짜는 스프린트는 백엔드부터 시작해 화면을 뒤로 미룹니다. 그 순서로 가면 나중에 화면을 붙이다 구조를 갈아엎게 됩니다.

9. 09

   산출물 복구와 부분 실패 허용

   잘린 응답을 여러 단계로 복구하고, 모델을 3단으로 대체하며, 필수 산출물만 실패로 처리하고 나머지는 빈 값으로 대체해 진행합니다. 어느 모델이 답했는지 화면에 표시합니다.

   왜 이 단계가 있나

   긴 설계 문서 응답은 실제로 잘립니다. 잘렸다고 전체를 버리면 몇 분간의 생성이 통째로 날아갑니다. 그리고 어느 모델이 답했는지는 숨기지 않습니다.