43/ 50
＋ 재시작 인계와 폐기 대상을 매우 구체화했다.
－ 잠정적인 큐 방식을 확정 사항으로 단정했다.
맴도는 대화를 정리하고 새로 시작할지 정하는 프롬프트
논의된 것과 정해진 것을 가릅니다. 뭘 버리고 갈지 명시합니다.
| 분류 | AI 사용법 › 대화 관리 |
|---|---|
| 태그 | 요약분석검토 |
This conversation has gone long and is going in circles. **Decide whether to continue or restart.** 1. **State where it actually stands** — ***what is settled, not what was discussed.*** **Those are different and only the first one carries forward** 2. **Find where it started circling.** *Usually one unresolved question that keeps getting worked around instead of answered* 3. **Diagnose:** - **A decision was never made**, so every path leads back to it - **The requirements changed mid-way** and earlier output is still being treated as valid - **The task is bigger than one conversation** and needs splitting - **Accumulated output is now acting as context** and constraining new answers toward more of the same 4. **Verdict: continue or restart.** ***Say which, plainly*** - **Continue** → the one question to answer next, and why that unblocks it - **Restart** → **write the handoff**: settled decisions, what still has to be decided, what to leave behind, and ***what went wrong here that should not repeat*** ⚠️ ***Do not carry everything over. A restart that brings the whole history brings the problem with it.*** **Say explicitly what to drop.**
붙여 넣으면 맨 아래에 채울 칸(대화 내용 · 하려는 것)이 나옵니다
어떤 프롬프트인가
대화가 맴도는 건 대개 결정을 안 한 질문 하나를 계속 우회하기 때문이다. 그리고 새로 시작할 때 이력을 다 가져가면 문제도 같이 온다. 이 프롬프트는 정해진 것만 추리고, 계속할지 새로 시작할지 판정한 뒤, 버리고 갈 것을 명시적으로 적는다.
모델 비교
Gemini가 가장 완전하고 구체적이나 잠정 결론을 확정으로 본 흠이 있다. ChatGPT는 더 간결하지만 진단 일부와 확정 상태가 부정확하며, [C]는 답이 없다.
42/ 50
＋ 결정 조건과 재시작 절차를 간결히 정리했다.
－ 확정 사항이 없다는 첫 문장이 지나치게 강하다.
| 기준 | ChatGPT | Gemini | 앞선 모델 |
|---|---|---|---|
| 지시 준수 | 8 | 9 | Gemini +13% |
| 정확성 | 7 | 8 | Gemini +14% |
| 구체성 | 9 | 9 | 동점 |
| 구성·가독성 | 9 | 9 | 동점 |
| 분량 적정성 | 9 | 8 | ChatGPT +13% |
gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.
답 전문 보기
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
대화 내용: 60턴 넘게 이어진 대화. 처음엔 신규 알림 시스템을 큐 기반으로 할지 웹소켓 기반으로 할지 논의하다가 큐 기반으로 잠정 결론. 이후 Redis Streams와 Kafka 중 뭘 쓸지로 논쟁하다 Redis Streams로 정함. 그런데 트래픽 처리량 얘기가 다시 나오면서 Kafka가 낫다는 의견이 나와 원점으로 되돌아감. 중간에 알림 우선순위 기능 요구사항이 추가되면서 스키마 얘기까지 섞였고, 지금은 Redis냐 Kafka냐를 다시 논의 중인데 이전에 정리했던 스키마 내용이 계속 재언급되고 있음. 하려는 것: 신규 알림 시스템의 메시지 큐 아키텍처를 확정하고 싶다
실제 상태
확정된 것은 없습니다.
- 알림 전달 방식은 웹소켓보다 큐 기반이 적합하다는 방향만 잠정 합의됨.
- Redis Streams 선택은 처리량 논의로 무효화됨.
- 알림 우선순위 요구사항은 새로 추가됨.
- Redis와 Kafka 중 메시지 브로커 선택이 아직 미결정임.
- 기존 스키마는 브로커가 정해지기 전의 논의이므로 확정 사항으로 볼 수 없음.
순환이 시작된 지점
Redis Streams를 정한 뒤, 실제 트래픽 처리량이 선택을 바꿀 수 있는 핵심 조건으로 다시 등장한 시점부터입니다. 그때 “Redis로 확정할 것인가, 처리량을 근거로 Kafka를 선택할 것인가”라는 질문에 답하지 않고, 이전 스키마와 논의를 계속 재사용하면서 원점으로 돌아갔습니다.
진단
주된 원인은 세 가지입니다.
- 브로커 결정에 필요한 처리량·내구성·운영 조건이 정해지지 않았습니다.
- 우선순위 요구사항이 중간에 추가되어 기존 설계의 유효성이 바뀌었습니다.
- 이미 작성된 스키마와 논의 내용이 맥락으로 누적되어, 아직 확정되지 않은 내용을 확정된 전제로 취급하게 됐습니다.
판정: 재시작
이 대화는 재시작하는 것이 낫습니다.
재시작 시 인계할 것
- 목표: 신규 알림 시스템의 메시지 큐 아키텍처 확정
- 전달 방식: 웹소켓 단독 방식이 아니라 큐 기반을 우선 검토
- 필수 요구사항: 알림 우선순위 처리
- 미결정: Redis Streams와 Kafka 중 선택
- 다음 결정에 필요한 입력:
- 예상 평균·최대 처리량
- 메시지 보존 기간
- 유실 허용 여부
- 순서 보장 범위
- 소비자 수와 확장 계획
- 운영 가능한 인프라와 장애 복구 요구
버릴 것
- Redis Streams가 이미 확정됐다는 전제
- Kafka가 처리량 때문에 자동으로 더 적합하다는 전제
- 브로커 선택 전에 작성한 스키마의 확정성
- 60턴 동안 반복된 비교와 잠정 결론
- 우선순위 요구사항을 반영하지 않은 기존 설계안
반복하지 말아야 할 것
브로커를 먼저 확정하지 않은 채 스키마와 세부 구현을 계속 확장하지 말아야 합니다. 새 대화에서는 먼저 위 운영·트래픽 조건을 숫자로 확정하고, Redis와 Kafka를 동일한 기준으로 비교한 뒤 단일 결정을 내려야 합니다.
같은 분류의 프롬프트
| 채팅 내역 내보내기 프롬프트 | |
| 컨텍스트 이전 문서 프롬프트 | |
| 작업 이어가기 요약 프롬프트 | |
| 긴 자료를 나눠 넣는 순서 짜는 프롬프트 | |
| 서로 충돌하는 내 지시를 찾아내는 프롬프트 |