Gemma 4에게 요약만 시키지 마세요.

Source: Dev.to

이 글은 Gemma 4 챌린지 Write About Gemma 4에 제출한 내용입니다.
오픈 모델을 사용해 불확실성을 드러내는 작은 테스트이며, 숨기지는 않습니다.

대부분의 AI 데모는 깔끔한 프롬프트로 시작합니다.
실제 업무는 보통 엉성한 메모에서 시작하죠.

• 이해관계자는 “숫자가 이상해 보인다”고 말하고,
• 다른 사람은 “필드가 바뀌었다”고 얘기하고,
• 또 다른 사람은 “원본 파일을 정리했다”고 합니다.
  대시보드 담당자는 자리를 비웠고, 매니저는 리더십 회의 전에 업데이트가 필요합니다.

이런 상황을 Gemma 4로 시험해 보고 싶었습니다.
저는 비즈니스 시스템, 보고, 데이터 품질, 프로세스 인계 작업을 다루다 보니 이 상황이 익숙했습니다. 실제 보고 업무에서 가장 위험한 순간은 대시보드가 고장 났을 때가 아니라 누구도 원본을 확인하기 전에 모두가 답을 원할 때입니다.

그래서 실용적인 질문 하나를 테스트했습니다.

Gemma 4가 엉성한 메모를 단순히 요약하는 것보다 더 유용한 일을 할 수 있을까?

특히:

• 알려진 것, 가정된 것, 위험 요소, 아직 확인이 필요한 것을 구분할 수 있을까?

이 차이가 제가 중요하게 생각하는 부분이었습니다.

요약은 엉성한 정보를 압축하지만, 리뷰 패킷은 사실, 가정, 위험, 다음 확인 사항을 구분합니다.

테스트는 의도적으로 작게 잡았습니다.

• Google AI Studio에서 Gemma 4 26B A4B IT 모델을 사용했습니다.
• 같은 엉성한 메모를 두 번 사용했으며, 모델 설정은 동일했습니다: temperature 0.25, thinking level High, 툴 없음, 시스템 지시문 없음.

시스템 지시문을 비워 둔 이유는 프롬프트 자체가 행동을 정의하도록 했기 때문입니다.

이것은 모델 비교가 아니라 프롬프트 패턴 비교였습니다.

변경한 것은 프롬프트 하나뿐이었습니다.

시나리오는 인공적이지만 현실적이었습니다:

• 주간 운영 보고서가 월요일 아침에 제출돼야 함
• 총계가 예상보다 낮아 보임
• 필드명이 지난 주에 변경됨
• 중복 행이 원본 파일에서 제거됐을 가능성
• 대시보드 담당자는 부재 중

개인 데이터나 기업 데이터는 전혀 포함되지 않았습니다. 회의 전 압박을 주는 전형적인 엉성한 보고 상황이었습니다.

테스트용 메모 (요약)

• 주간 운영 보고서는 월요일 아침에 제출돼야 함.
• 보고서는 보통 일요일 밤에 새로 고침됨.
• 필드명이 지난 주에 변경됨.
• 이해관계자는 “총계가 평소보다 낮다”고 보고함.
• 원본 파일에서 중복 행이 제거됐을 가능성이 있음.
• 대시보드 담당자는 부재 중.
• 아직 문제의 원인이 원본 데이터, 필터 로직, 정의 변경 중 어느 것인지 알 수 없음.

1. 먼저 물어본 질문

“이 메모를 매니저에게 요약하고 현재 상황을 설명해 주세요.”

결과는 나쁘지 않았습니다.

베이스라인 실행 (같은 Gemma 4 모델, 같은 메모, 시스템 지시문 없음)
Gemma 4는 매니저용 업데이트와 “아직 최종 숫자를 제공하기엔 조사가 진행 중이다”는 평이한 설명을 제공했습니다.

“주간 총계 차이에 대한 조사가 진행 중입니다.”

슬랙에 보낼 수 있을 정도로 실용적인 한 줄이었습니다.

하지만 요약에는 약점도 있었습니다. “red alert”, “flying blind”, “숫자가 잘못 보인다” 같은 표현이 들어갔습니다. 이런 표현은 상황을 이해하기 쉽게 만들지만, 원본 메모가 지원하지 않는 확신과 드라마를 추가합니다.

원본 메모는 보고서가 틀렸다고 증명하지 않았고, 단지 “총계가 평소보다 낮다”는 사실만 제시했습니다.

요약은 엉성한 정보를 읽기 쉽게 만들면서도, 실제보다 상황을 덜 불확실하게 만들 위험이 있습니다.

2. 리뷰 패킷 요청으로 전환

프롬프트를 바꿔 리뷰 패킷을 요청했습니다.

“당신은 분석가입니다. 아래 메모만 사용해 다음을 반환하세요:
1️⃣ 한 문단 요약
2️⃣ 확인된 사실
3️⃣ 가정
4️⃣ 검증되지 않은 주장
5️⃣ 위험 요소
6️⃣ 인간 검토자를 위한 질문
7️⃣ 제안된 다음 행동
8️⃣ 아직 결론 내리지 말아야 할 점
9️⃣ 최종 체크리스트

규칙:

• 사실을 창조하지 마세요.
• 사실과 가정을 구분하세요.
• 차분하고 실용적으로, 간결하게 유지하세요.
• 최종 결정을 내리지 말고 검증할 항목을 제시하세요.”

출력은 다소 다듬어지지 않았지만, 팀이 현재 상황을 결정하는 데 훨씬 유용했습니다.

• “총계가 낮다”는 이해관계자의 보고는 검증되지 않은 주장으로 분류되었습니다.
• 가장 큰 미지수인 “근본 원인은 아직 알 수 없음”이 눈에 띄게 유지되었습니다.

실제 보고 이슈에서는 사람들은 바로 원인을 찾으려 합니다: 필드 변경, 원본 파일 변경, 필터 로직 오류 등. 하지만 이 시점에서는 아직 검증되지 않은 상태였습니다.

가장 강력했던 부분은 **“아직 결론 내리지 말아야 할 점”**이었습니다:

• 데이터가 틀렸다고 결론 내리지 말 것
• 필드명 변경이나 중복 제거가 차이의 원인이라고 결론 내리지 말 것
• 문제가 원본 데이터, 필터 로직, 정의 변경 중 어느 것인지 아직 모른다고 결론 내리지 말 것

이 섹션은 상태 업데이트를 리뷰 도구로 바꾸어 주었습니다.

리뷰 패킷 실행 결과, 사실, 가정, 위험, 아직 결론 내리지 말아야 할 점을 구분하는 것이 가장 큰 전환점이었습니다.

출력이 더 똑똑하게 들려서가 아니라, 다음 단계에 대한 안전한 틀을 제공했기 때문에 더 좋았습니다.

• 요약은 상태 전달에 유용하고,
• 리뷰 패킷은 아직 검증이 필요한 부분을 결정하는 데 유용합니다.

이 경계는 제가 넘지 않을 선입니다.

Gemma 4는 보고서를 직접 검사하지 않았고, 원본 파일을 열지도 않았으며, 대시보드 로직을 확인하지도 않았습니다. 중복 제거가 정확했는지, 필드명 변경이 계산에 영향을 주었는지도 알지 못합니다.

그럼에도 검증 경로를 정리해 주었습니다. 이는 검증 자체가 아니라 검증을 위한 준비입니다.

실제 보고 이슈에서는 원본 행, 필드 매핑, 보고서 필터, 새로 고침 시점, 메트릭 정의 등을 모두 확인해야 합니다. 리뷰 패킷은 그 작업을 대체하지 않으며, 오히려 그 작업을 놓치지 않게 해 줍니다.

복잡한 시스템 작업에서는 조사 전에 이런 형태의 출력을 사용합니다. 인간 검토자를 준비시키는 용도이지, 인간을 대체하는 것이 아닙니다.

모델은 흩어진 메모를 조사 담당자를 위한 체크리스트로 바꿀 수 있지만, 실제 시스템, 데이터, 정의, 비즈니스 컨텍스트에 접근하지 않으면 조사를 수행할 수 없습니다.

누군가 이 글에서 한 가지만 가져간다면, 다음 프롬프트 형태가 핵심입니다.

입력이 엉성하고, 불확실하거나, 시간에 민감할 때 모델에 요청할 항목

• 요약
• 확인된 사실
• 가정
• 검증되지 않은 주장
• 위험 요소
• 인간 검토자를 위한 질문
• 제안된 다음 행동
• 아직 결론 내리지 말아야 할 점
• 최종 체크리스트

가장 유용한 부분은 항상 요약이나 체크리스트가 아니라,

• 가정
• 검증되지 않은 주장
• 위험
• 아직 결론 내리지 말아야 할 점

이 섹션들은 모델이 불확실성을 가시화하도록 강제합니다. 이것이 리뷰 패킷을 요약보다 더 유용하게 만든 핵심입니다.

엉성한 메모는 실제 업무에서 흔히 마주치는 상황입니다. 보고서, 지원 인계, 사고 업데이트, 프로젝트 노트 등은 거의 완벽한 형태로 오지 않죠. 중요한 질문은 모델이 이를 처리할 수 있느냐가 아니라, 불확실성을 그대로 유지하면서 구조화된 형태로 제공할 수 있느냐입니다.

Gemma 4를 이렇게 활용한 이유는, **