자기개선형 App: 닫힌 개선 루프

1. 왜 App에 닫힌 개선 루프가 필요한가

어떤 LLM‑App도 변하는 세계 속에 존재합니다. 새로운 사용자와 시나리오가 생기고, OpenAI는 새로운 모델과 방어 메커니즘을 출시하며, 여러분은 MCP 서버, Agents SDK, UI 위젯을 스스로 업데이트합니다… 그리고 코드가 완벽하게 작성됐다고 해도(네, 맞아요. 여러분이 거의 그렇게 한다는 거 압니다) 모델이나 프롬프트를 한 번 바꾸는 것만으로도 케이스의 절반이 모르게 깨질 수 있습니다.

개선 루프가 없으면 삶은 이렇게 보입니다. 사용자가 지원팀에 쓴다: “GiftGenius가 예산보다 비싼 선물을 추천하기 시작했어요” 또는 “15초씩 멍하니 생각만 해요.” 여러분은 로그를 열어 system‑prompt를 조금 고치고, 모델을 바꾸고, 배포합니다. 일주일 뒤 모든 것이 다시 반복되지만, 다른 곳에서요. 결과는 — 만성적인 화재 진압과 아무도 설명할 수 없는 ‘마법 같은’ 변경의 더미뿐입니다.

루프가 있으면 모든 것이 다릅니다. 여러분에겐 다음이 있습니다:

• 기술, 비용, 제품, 품질에 대한 명확한 시그널 세트;
• 정기적인 의식: 시그널을 보고 가설을 선택하기;
• code/config에서의 통제 가능한 변경;
• 자동 검증: 골든 케이스 + LLM‑evals + 실험.

그때 App은 ‘고정된 프롬프트’에서 다음과 같은 살아 있는 시스템으로 변합니다:

• 어디가 아픈지, 왜 아픈지를 보여줍니다;
• 무엇을 어떻게 개선할 수 있는지 알려줍니다;
• ‘사소한’ 프롬프트 변경 이후의 조용한 성능 저하를 막아줍니다.

보너스도 있습니다: 이런 루프는 여러분이 이미 이전 모듈에서 만든 모든 것과 아주 잘 맞닿습니다. M17의 로그와 SLO는 기술적 시그널을, M19의 비용 계측과 AARRR은 경제적·제품적 시그널을, M20.1–2의 골든 케이스와 LLM‑evals는 품질 시그널을 줍니다. 이제 이것을 명확한 운영 루프로만 엮으면 됩니다.

2. 개선을 위한 시그널 맵

App이 스스로 어디를 개선해야 할지 힌트를 주게 하려면, 여러분에게 어떤 시그널이 있는지와 그것이 어디서 오는지를 명확히 알아야 합니다. 네 가지 그룹으로 생각하면 편합니다.

기술 시그널은 observability 스택에서 옵니다: tool_invocation 로그, latency와 error‑rate 메트릭, MCP/ACP 헬스 체크, OAuth 실패. 이들은 “서비스가 살아 있고 얼마나 안정적인지”에 답합니다.

경제 시그널은 비용 계측과 빌링에서 태어납니다: cost_per_tool_call, cost_per_task, cost_per_user, 특정 툴이나 시나리오에서의 예상치 못한 비용 급증 등. 이들은 “우리가 예상보다 토큰과 돈을 더 태우고 있다” 혹은 반대로 “여유가 있으니 품질을 높여도 된다”라고 말합니다.

제품 시그널은 app_opened, workflow_started, workflow_completed, checkout_* 같은 이벤트로 구성됩니다. 즉 activation‑rate, 퍼널 단계 간 전환율, 코호트별 리텐션입니다. 이들은 사람들의 실제 행동에 무슨 일이 일어나는지 보여줍니다.

품질/행동 시그널에는 골든 케이스에 대한 LLM‑evals 결과(correctness/helpfulness/style/safety 점수), 대화의 표본 수동 리뷰, thumbs up/down, Store의 불만과 리뷰가 포함됩니다. 이는 “App이 더 똑똑/멍청해졌다”라는 체감을 가장 잘 반영합니다.

이를 표로 모아두면 편리합니다:

핵심 포인트: 모든 시그널은 특정 시나리오와 App 버전에 연결되어 로그로 남아야 합니다. 즉 이벤트에 최소한 scenario, appVersion, experimentId가 있어야 합니다. 그러면 골든 케이스에서 helpfulness가 8.5에서 6.2로 떨어졌을 때, 단순히 “나빠졌다”가 아니라 “릴리스 "1.3.0" 이후 시나리오 "gift_selection"에서, 실험 변형 "B"에서 나빠졌다”라고 말할 수 있습니다.

코드에서 시그널을 설명하는 간단한 구조를 만들어 둘 수도 있습니다:

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // "이전" 값
};

이런 객체는 대시보드에도, 그리고 앞으로 만들 개선 어시스턴트에도 먹이기 좋습니다.

3. 정석 feedback‑loop: 4단계

이제 매번 의지할 수 있는 정석 개선 루프를 조립해 봅시다. 아주 현실적입니다: 네 단계.

flowchart TD
  A[시그널: 문제가 있거나
성장 기회가 보임] --> B[가설:
무엇을 어떻게 바꿀지]
  B --> C[통제 가능한 변경
code/config]
  C --> D[검증:
오프라인 + 온라인]
  D --> A

1단계. 문제 또는 기회를 발견

이 단계에서는 “어디를 볼 것인가”에 답합니다. 예시:

• 예산이 있는 골든 케이스에 대한 LLM‑eval이 helpfulness 하락을 보여준다.
• p95 latency가 "suggest_gifts" 툴에서 1.2초에서 3.8초로 증가했다.
• 시나리오 "gift_selection"의 cost_per_task가 reasoning 모델로 전환 후 40% 상승했다.
• workflow_completed → checkout_success 전환율이 UX 마법사 수정 후 5 퍼센트포인트 하락했다.
• Store에 일주일 동안 “예산보다 비싸다”는 불만이 10건 올라왔다.

중요한 뉘앙스: 시그널이 “나쁘다”가 아니라 “더 좋아질 수 있다”라고 말하는 경우도 있습니다. 예를 들어 cost_per_task가 허용 임계치보다 눈에 띄게 낮고, quality‑score가 이미 9/10이라면 더 비싼 모델이나 더 ‘똑똑한’ 시나리오를 시도해 볼 수 있습니다 — 전환율이 오를지도 모릅니다.

2단계. 가설을 수립

가설은 “프롬프트를 갈아엎겠다”가 아니라 “컴포넌트 Y에서 특정 변경 X가 메트릭 Z를 개선할 것이라 생각한다. 그 이유는…”입니다. “그 이유”가 없으면 가설이 아니라 바람일 뿐입니다.

예시:

• “system‑prompt에 예산 엄수 규칙을 넣고 항상 예산을 어떻게 반영했는지 설명하도록 요청하면, 예산 있는 케이스에서 helpfulness가 최소 2점 오른다.”
• “rerank 단계에서 비싼 모델을 "gpt-mini"로 바꾸면 cost_per_task는 30% 떨어지고, 전환율은 최대 1 퍼센트포인트 이상 떨어지지 않는다.”
• “위저드를 단순화(두 단계를 하나로 합치기)하고 CTA를 고치면 activation‑rate가 5 퍼센트포인트 오른다.”

코드에서 이런 가설을 최소한 객체 형태로 명시해 두면 편합니다:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "무엇을 왜 바꾸는지"
  targetMetric: string;  // 예: "quality.helpfulness" 또는 "conversion.checkout"
  successCriteria: string;
};

네, 거의 Jira 티켓과 비슷하지만 적어도 타입이 있는 형태죠.

3단계. 통제 가능한 변경을 수행

여기서는 두 단어가 중요합니다: 통제 가능한과 분리된.

통제 가능하다는 것은 변경 사항이 PR/커밋으로 정리되어 있고, 가설에 연결되며, 변경 로그가 있고, 가능하면 기능 플래그나 버전이 있다는 뜻입니다. 단지 “프로드에서 프롬프트를 살짝 고쳤다”가 아니라 정확히 어떤 릴리스가 그것을 가져왔는지 말할 수 있어야 합니다.

분리된이란 한 릴리스에 서로 다른 세 개의 가설을 한꺼번에 섞지 않는다는 뜻입니다. 예를 들어 동시에:

• 모델을 바꾸고,
• system‑prompt의 절반을 다시 쓰고,
• UX에 새 단계를 추가하면,

설령 메트릭이 좋아졌더라도 무엇이 먹힌 건지 파악하기 어렵습니다. 작은 덩어리로 움직이는 편이 훨씬 정직합니다.

기술적으로 변경은 어디든 있을 수 있습니다:

• 에이전트의 system‑prompt(lib/prompt/systemPrompt.ts);
• MCP tools 설명(description, inputSchema, annotations);
• 에이전트 설정(추론 단계 한도, 특정 툴의 모델 선택);
• 위젯 코드(CTA, 단계 순서, 오류 문구).

4단계. 정말 좋아졌는지 검증

검증은 오프라인과 온라인으로 나뉩니다.

오프라인 검증은 실제 사용자 없이 새 버전 App으로 골든 케이스를 돌리는 것입니다. 여기에는 이미 다음이 있습니다:

• LLM‑evals(모듈 20.1);
• threshold/baseline 로직(모듈 20.2).

대상 시나리오의 quality‑score가 어떻게 변했는지 봅니다: 올랐는지, 떨어졌는지, 그대로인지. 또한 세이프티 케이스를 확인합니다: 프롬프트 수정을 포함한 어떤 변경도 먼저 세이프티 세트를 통과해야 합니다.

온라인 검증은 실제 트래픽에서의 실험입니다. 가장 간단히는 새 버전을 사용자 N%에게 켜고 다음을 비교합니다:

• 목표 행동으로의 전환(결제, 시나리오 재시작);
• cost_per_task;
• 불만/피드백.

그다음 루프는 닫히거나(가설이 입증/반증되고 문서화됨), 새 가설을 낳습니다.

4. 내부 ‘개선 어시스턴트’를 별도 에이전트로

이제 가장 흥미로운 부분: LLM 모델에 또 다른 역할을 줍시다 — 사용자에게 답하는 것뿐 아니라 여러분이 App을 개선하도록 돕는 역할입니다. 이는 사용자용 GiftGenius와 분리된 내부 에이전트입니다.

무엇인가

이 어시스턴트는 내부 환경에서 동작합니다(같은 저장소, Dev Mode, 별도 ChatGPT App). 이 어시스턴트는:

• 로그와 대화 샘플을 읽고;
• 메트릭을 보고;
• system‑prompt와 tools 설명을 분석하고;
• 문제와 변경 제안 정리에 도움을 줍니다.

본질적으로 여러분은 다음과 같은 ‘가상 PM/애널리스트’를 얻게 됩니다:

• 대화를 읽어도 지치지 않고,
• 반복되는 패턴을 빠르게 찾고,
• 프롬프트 초안과 변경 로그를 작성할 줄 압니다.

입력은 무엇을 받는가

에이전트가 쉽게 작업하도록 입력을 형식화해 두면 좋습니다. 예를 들어 이런 타입:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // 앞 절에서 정의한 것
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

로그에서 시나리오 "gift_selection"의 불성공 대화 10–20개를 모아, 현재 system‑prompt와 툴 설명을 함께 붙여 이런 객체를 만들 수 있습니다.

출력은 무엇이어야 하는가

기대하는 응답 형식도 고정해 두면 좋습니다:

export type ImprovementSuggestion = {
  patterns: string[];     // 반복되는 문제
  promptPatches: string[]; // system-prompt용 제안 조각
  toolsPatches: string[];  // tools 설명 개선 아이디어
  uxCopyIdeas: string[];   // UX 텍스트 대안
  changelog: string[];     // "무엇을 바꿀지" 요약 리스트
};

이런 에이전트의 메타 프롬프트는 대략 다음과 같습니다:

• “예시와 시그널을 분석하라”;
• “문제 패턴을 2–3개로 설명하라”;
• “프롬프트, tools 설명, UX 텍스트에 대해 각각 1–2개의 변경을 제안하라”;
• “모두 엄격히 정의된 JSON으로 반환하라”.

그다음 여러분은 이 조각들을 직접 가져와 팀과 논의하고, 코드에 녹여 eval과 실험을 돌립니다. 중요한 원칙: 이 어시스턴트는 프로덕션에서 스스로 아무것도 바꾸지 않습니다. 아이디어와 텍스트를 생성할 뿐, 커밋을 하지는 않습니다.

5. 변경 유형: 무엇을 ‘튜닝’할 수 있나

이런 어시스턴트와 명확한 루프가 생기면 모든 걸 “system‑prompt의 새 버전 좀”으로 축소하기 쉽습니다. 실제로 개선 범위는 훨씬 넓습니다.

프롬프트와 지침

system‑prompt는 역할, 톤, 우선순위, 엄격한 규칙(예: 예산, 세이프티, 단계 순서)을 정의합니다. 할 수 있는 일:

• 상충하거나 중복되는 지침을 제거해 단순화;
• 부족한 규칙 추가(예산 예시처럼 강화);
• 시나리오별로 맞춤화("gift_selection", "post_purchase_help" 등 각자 서브 프롬프트).

tools 설명은 모델이 특정 툴을 언제 호출하고 무엇을 하는지 이해하도록 돕습니다. 여기서의 개선은 대체로 다음으로 귀결됩니다:

• 더 명시적인 “Use this when… / Do not use when…”;
• 표현 정밀화(다른 tools와의 겹침 감소);
• 결과에 대한 정보 추가(destructiveHint, isConsequential).

세이프티 규칙은 복잡한 도메인에서의 행동을 책임지는 프롬프트/설명의 일부입니다. 충분한 세이프티 eval 이후에 손대는 것이 좋습니다.

행동 아키텍처(behavior)

문제를 프롬프트로만 해결할 수 없을 때도 많습니다: 행동 순서를 바꿔야 합니다.

예시:

• 비싼 툴을 호출하기 전에 매개변수 확인 필수 단계를 추가;
• 일부 계산을 별도의 더 저렴한 단계로 분리(예: 백엔드에서의 사전 필터링);
• 하나의 시나리오에서 연속 tool 호출 횟수 제한.

이런 변경은 보통 프롬프트뿐 아니라 에이전트 설정이나 MCP 계층에서 기술됩니다.

UX와 카피라이팅

맞습니다. 버튼과 오류의 텍스트도 품질의 일부입니다. 다음처럼 말하는 GiftGenius는:

“오류 500. 관리자에게 문의하세요.”,

다음과는 완전히 다른 인상을 줍니다:

“상점에서 응답을 받지 못했습니다. 선택하신 아이디어는 사라지지 않았으니, 잠시 후 결제를 다시 시도해 주세요.”.

중간 화면, 힌트, 마법사 구성 — 모두 여러분이 측정하는 그 activation‑rate와 전환율에 영향을 줍니다.

경제

여기서는 익숙한 “품질 ↔ 비용” 게임을 합니다:

• 모델 선택(추론이 뛰어나지만 비싼 모델 vs 빠르고 저렴한 모델);
• 추론/에이전트 단계의 깊이(허용하는 반복 횟수);
• 대화 한도(예: 한 세션에서 추천 재계산 N회 이하);
• 토큰/쿼터 예산이 소진되었을 때의 ‘저렴한’ 폴백 모드.

이 시그널은 cost_per_task, cost_per_user, 마진으로 이어지며 quality‑score와 결합됩니다.

6. Guardrails: LLM에 맡기면 안 되는 것들

‘개선 어시스턴트’와 편리한 루프가 생기면 “자동 최적화” 버튼을 누르고 커피를 마시러 가고 싶어집니다. 그 버튼이 금지된 곳을 미리 합의합시다.

권한 변경(OAuth 스코프, MCP 툴, 데이터 접근)은 항상 human‑in‑the‑loop 영역입니다. 어떤 모델도 App이 주문을 읽거나, 결제를 만지거나, 사용자에게 메일을 보내도 된다고 스스로 결정해선 안 됩니다. 커머스 플로우도 마찬가지입니다: ACP/Stripe, 한도, 결제 유형과 환불에 관한 모든 변경은 사람 검토와 테스트를 거쳐야 합니다.

App의 세이프티 프로필(어떤 도메인에서는 조언할 수 있고 어떤 도메인에서는 반드시 거부해야 하는지)도 LLM에 위임할 게 아닙니다. 모델은 규칙 텍스트를 정리하는 데 도움을 줄 수 있지만, 어떤 주제를 App에 맡길지에 대한 결정은 여러분의 몫입니다.

데이터와 로깅 정책(무엇을 로그로 남기고, 얼마 동안 보관하며, 삭제 요청에 어떻게 대응하는지)도 동일합니다. LLM은 Privacy Policy의 구조를 제안할 수는 있어도 여러분의 참여 없이 코드의 보관 기간을 바꿔서는 안 됩니다.

무엇을 반자동화할 수 있을까요? 프롬프트와 tools 설명, UX 텍스트의 표현과 워딩, 툴 우선순위(합리적 범위에서), 추가 확인 질문 등입니다. 이 모든 것은 어시스턴트에게 아이디어 소스로 맡길 수 있지만, 마지막 결정과 검증은 사람과 eval 스크립트가 담당합니다.

7. 엔드 투 엔드 개선 루프 예시(GiftGenius)

우리의 주인공으로 돌아갑시다.

문제

사용자가 예산을 지정하지만 GiftGenius가 그 한도보다 비싼 선물을 자주 제안합니다. 로그에는 “너무 비싸요”, “더 싸게 해줘요” 같은 대화 연장이 많이 보입니다.

시그널

먼저 품질이 보입니다: “50$ 이하 선물 추천” 같은 골든 케이스에서 LLM‑eval helpfulness가 6/10 정도입니다. 심판은 reason에 “선물이 예산을 초과함” 또는 “예산 반영이 설명되지 않음”을 자주 씁니다.

제품 및 경제 시그널도 병행해서 도착합니다:

• 지정된 한도가 있는 시나리오의 checkout_success 전환율이 한도가 없는 경우보다 낮다;
• 너무 비싼 옵션을 본 뒤 시나리오를 중단하는 사용자가 일부 존재한다;
• 이런 시나리오의 cost_per_task가 더 높다. App이 “더 싸게 해줘” 요청에 따라 추천을 여러 번 재계산하기 때문이다.

개선 어시스턴트로 분석

가격 불만이 있었던 대화 20개를 모아 ImprovementInput을 구성합니다:

• scenario = "gift_selection_with_budget";
• helpfulness와 전환 하락이 담긴 signals;
• 대화가 담긴 examples;
• 현재 system‑prompt와 툴 설명.

이를 내부 개선 어시스턴트에게 먹입니다. 예를 들어 다음과 같은 결과를 냅니다:

• 패턴:
  • “대략 50$”처럼 표현된 예산이 너무 느슨하게 해석된다;
  • system‑prompt에 “예산을 절대 초과하지 말라”는 명시 규칙이 없다;
  • 응답에서 예산을 어떻게 반영했는지 설명하지 않는다.
• 제안:
  • system‑prompt에 한도 엄수 지침을 추가;
  • 항상 “모든 옵션 ≤ X”라고 명시하도록 요청;
  • 예산이 모호하게 들리면(“대략”, “얼추”) 확인 질문 추가.

가설과 변경

가설을 수립합니다:

“한도 엄수를 명시하고 예산 사용 설명을 요구하면, 예산이 있는 케이스의 helpfulness가 최소 8/10까지 올라가고, 결제 전환율은 3 퍼센트포인트 오른다.”

system‑prompt에 다음 조각을 추가합니다:

export const budgetRule = `
사용자가 예산을 지정했다면(예: "최대 50$" 또는 "대략 30€"),
그 금액을 엄격한 상한선으로 간주하라.

절대 해당 한도를 초과하는 옵션을 제안하지 말라.
각 답변에서 모든 옵션이 예산 내에 있음을
그리고 어떻게 충족되는지(예: "모든 선물은 45$ 이하입니다")를 명시하라.
`.trim();

그리고 GiftGenius의 전체 system‑prompt에 budgetRule을 포함시킵니다.

오프라인 검증

“예산이 있는 선물” 골든 케이스 세트를 새 버전으로 돌립니다:

• LLM‑eval helpfulness가 6.0에서 8.5로 상승;
• correctness도 상승: 예산이 지켜진다;
• 세이프티는(적어도) 악화되지 않는다.

반대로 helpfulness가 오르지 않거나 세이프티가 떨어지면 변경은 통과하지 못하고 가설을 재검토합니다.

온라인 테스트

그다음 실험을 시작합니다:

• 사용자 10%에게 새 프롬프트 버전(variant B)을 적용;
• 나머지 90%은 기존 버전(variant A).

일주일 뒤 확인합니다:

• B의 workflow_completed → checkout_success 전환율이 A의 10%에서 13%로 상승;
• cost_per_task는 거의 변동 없음;
• “너무 비싸다”는 대화 비율이 감소.

실험은 성공으로 판단됩니다.

정착

이후 다음을 수행합니다:

• 새 프롬프트를 트래픽 100%로 롤아웃;
• 회귀 세트에 “느슨한 예산 50$까지” 골든 케이스 추가;
• 변경 로그와(가능하면) 기술 노트에 결과를 기록: 반년 뒤에도 왜 프롬프트에 예산에 관한 강한 문구가 있는지 이해할 수 있도록.

루프가 닫혔습니다. 다음 반복은 예컨대 매우 희귀한 취향을 가진 사람들을 위한 추천이나, 추천 비용 최적화를 다룰 수 있습니다.

8. 자기개선형 App 미니 로드맵

이것이 “할 일 100500개 추가”처럼 보이지 않게 하려면, App이 이미 자기개선형으로 간주되려면 필요한 최소한이 무엇이고, 이후에 무엇을 추가할 수 있는지 보는 것이 도움이 됩니다.

버전 1.0: 최소한의 improvement‑loop

첫 단계에는 세 가지면 충분합니다.

첫째, 구조화 로그와 기본 SLO. 이미 tool_invocation, workflow_completed, checkout_*를 requestId, userId, scenario, appVersion, costEstimateUsd와 함께 로깅할 줄 압니다. 그 위에 SLO가 세워집니다: latency, error‑rate, checkout 성공.

둘째, 10–20개의 골든 케이스와 LLM‑eval 스크립트. 핵심 시나리오에 대한 작지만 잘 고른 예시 세트 + 세이프티 케이스. App과 심판을 통해 이를 실행하고 JSON 점수를 내는 하나의 CLI 스크립트.

셋째, 2주에 한 번의 간단한 의식. 혼자 또는 팀과 함께 앉아 다음을 엽니다:

• SLO, 비용, 제품 메트릭용 대시보드 2–3개;
• 골든 케이스에 대한 LLM‑eval 리포트;

그리고 다음 루프를 위한 1–2개의 가설을 선택합니다. 수립하고, 문서화하고, 작은 릴리스를 만들고, 검증합니다.

버전 2.0: ‘똑똑한’ improvement‑loop

다음 단계에서 등장합니다:

내부 개선 어시스턴트. ImprovementInput을 받아 ImprovementSuggestion을 반환하는 별도 에이전트(또는 ChatGPT App)입니다. 수작업으로 대화를 몇 시간씩 뒤적이지 않게 도와줍니다.

자동화된 리포트. 로그와 eval을 기반으로 다음을 생성할 수 있습니다:

• 문제 케이스의 클러스터(예: 사용자가 예산을 재지정한 모든 사례);
• 프롬프트와 tools 설명 변경의 바로 쓰는 초안;
• 짧은 변경 로그.

CI 훅. 프롬프트, 에이전트 설정, 툴 설명 변경은 자동으로 다음을 실행합니다:

• 기능 골든 스위트;
• 세이프티 스위트.

세이프티 케이스가 떨어지거나 핵심 시나리오 품질이 임계치를 통과하지 못하면 — 빌드는 실패, 릴리스는 없습니다.

9. 실습

연습 1. 내 App을 위한 미니 feedback‑loop

여러분 App의 핵심 시나리오 하나를 잡으세요. GiftGenius에서는 이미 “선물 추천 및 구매”를 선택했습니다. 비슷한 시나리오 또는 여러분만의 시나리오를 택하면 됩니다.

자유 형식으로(또는 작은 improvement-plan.md를 만들어) 다음을 적어 보세요:

어떤 시그널을 추적할지. 각 항목당 하나씩:

• 기술: 예를 들어 주요 작업을 수행하는 툴의 p95 latency;
• 경제: 해당 시나리오의 cost_per_task;
• 제품: workflow_started → workflow_completed 또는 목표 행동까지의 전환율;
• 품질: 해당 시나리오의 여러 골든 케이스에 대한 평균 quality_score.

그다음 무엇을 성능 저하로 볼지 임계치를 고정하세요. “언젠가 보자”가 아니라 아주 구체적으로:

• p95 > 5초 — 좋지 않음;
• 매출 증가 없이 cost_per_task가 30% 넘게 상승 — 경보;
• quality_score가 7 미만 — 분석 필요.

그리고 첫 번째 가설을 수립하세요. 예를 들어:

“우리가 확인 질문을 너무 많이 던지는 것 같다. 위저드를 한 단계 줄이고 질문을 조금 더 일반화하면 activation‑rate는 오르고 helpfulness는 거의 손상되지 않을 것이다. 작은 UX 변경과 A/B 실험으로 확인해 보겠다.”

이는 “UX를 개선하자”가 아니라 루프에서 아주 구체적인 한 걸음입니다.

연습 2. 개선 어시스턴트를 위한 메타 프롬프트

여러분 App에 맞춘 내부 개선 에이전트의 프롬프트 텍스트를 초안으로 적어 보세요. 간단히 시작해도 좋습니다:

• 그가 누구인지 설명: “너는 App N의 품질 애널리스트로서…”
• 받는 입력을 나열: 대화, 시그널, system‑prompt, descriptions.
• 과제를 정리:
  • 문제 패턴 2–3개 찾기;
  • 프롬프트, tools, UX 텍스트에 각각 1–2개의 변경 제안하기;
  • 짧은 변경 로그 모으기.
• 응답 형식을 설명: patterns, suggestions, changelog 필드를 가진 구조적 JSON.

아직 코드에서 이 에이전트를 호출하지 않더라도, 이런 프롬프트 하나만으로도 App을 어떻게 개선하는지에 대한 여러분의 사고를 훨씬 잘 구조화하는 데 도움이 됩니다.

10. 개선 루프 구축 시 흔한 실수

오류 №1: 한 가지 메트릭만 최적화.
한 가지에만 집중하는 것은 매우 유혹적입니다. cost만 쫓아 OpenAI 청구서가 줄어드는 것을 기뻐하다가, quality score, 전환율, 리텐션이 내려가는 것을 놓칠 수 있습니다. 반대로 reasoning 모델로 품질을 10/10까지 끌어올리고, 각 시나리오가 1달러씩 들게 만들 수도 있습니다. 개선 루프는 메트릭 묶음을 봐야 합니다: 품질 ↔ 돈 ↔ 사용자 행동.

오류 №2: 측정 없는 ‘마법의’ 프롬프트 변경.
골든 케이스와 eval 없이 “system‑prompt를 다시 썼으니 이제 더 좋아질 거야”라는 말은 몇 주 뒤 자신에게 깜짝 선물을 주는 방법입니다. 프롬프트 변경 — 특히 프로덕션에서의 변경 — 은 명확한 파이프라인을 거쳐야 합니다: 케이스 세트, 변경 전후 LLM‑eval, 필요 시 온라인 실험. 그렇지 않으면 App을 개선하는 게 아니라 품질을 임의의 방향으로 흩뿌리는 것입니다.

오류 №3: LLM 개선 어시스턴트의 변경을 자동 배포.
개선 어시스턴트가 믿을 수 없을 만큼 멋진 프롬프트 조각과 그럴듯한 툴 설명을 쓴다 해도, 그것은 프로드에 리뷰 없이 푸시할 이유가 되지 않습니다. 모델은 모든 비즈니스 제약, 세이프티 위험, 여러분 메트릭의 맥락을 보지 못할 수 있습니다. 그 역할은 컨설턴트이지, 릴리스 권한을 가진 DevOps가 아닙니다.

오류 №4: 변경과 가설/시그널의 연결 부재.
때로 팀은 ‘감’으로 수정하고, 어떤 시그널이 변경을 이끌었는지, 어떤 가설을 검증 중인지 기록하지 않습니다. 그 결과 한 달 뒤 프롬프트의 이상한 문단이 왜 생겼는지, 도대체 누구에게 필요했는지 아무도 기억하지 못합니다. 품질 관련 좋은 PR은 최소 세 가지 질문에 답해야 합니다: “어디가 아팠나?”, “무엇을 바꾸나?”, “무슨 메트릭으로 더 나아졌음을 판단하나?”

오류 №5: 개선 중 세이프티를 잊음.
유용성을 쫓다 보면 세이프티 제약을 느슨하게 하거나, 프롬프트에서 ‘불필요한 거부’를 제거하거나, 세이프티 케이스 실행을 잊기 쉽습니다. system‑prompt, 툴 설명, 에이전트 행동의 모든 변경은 먼저 세이프티 eval 세트를 통과해야 합니다. 이전에 통과하던 케이스 중 하나라도 이제 실패한다면 — 이는 정지 신호입니다. 다른 메트릭이 아무리 예뻐 보여도요.

오류 №6: ‘모두 한꺼번에’ 최적화하고 싶은 욕구.
프롬프트의 절반을 다시 쓰고, 모델을 바꾸고, MCP 툴을 하나 더 추가하고, 새 위저드를 넣고 — 이 모든 것을 한 릴리스에 담는 것은 생산적으로 들리지만, 어떤 변경이 효과를 냈는지 이해할 가능성을 완전히 없앱니다. 개선 루프는 반복적이고 집중적일 때만 효과적입니다: 한두 개의 가설, 작은 변경 묶음, 명확한 롤백 계획.

오류 №7: 개선 루프를 드문 ‘대청소의 날’로 만들어 버림.
반년에 한 번 ‘품질의 날’을 호화롭게 치르고 나머지 달에는 eval과 메트릭 분석 없이 산다면, App은 대부분의 시간을 ‘물살을 따라’ 떠내려가게 됩니다. 훨씬 유익한 것은 작지만 규칙적인 의식입니다: 매주/격주로 시그널을 보고, 가설을 업데이트하고, 작은 걸음을 떼는 것. 바로 그렇게 여러분의 ChatGPT App이 정적 상태에서 벗어나 정말로 자기개선을 시작합니다.