Gemma 4에게 단순히 요약만 해달라고 요청하지 마세요

이 글은 Gemma 4 챌린지(Gemma 4 Challenge): Gemma 4에 대해 쓰기(Write About Gemma 4)를 위한 제출물입니다. 불확실성을 숨기는 것이 아니라 드러내기 위해 오픈 모델(open models)을 사용하는 작은 테스트입니다.

대부분의 AI 데모는 깔끔한 프롬프트(prompts)로 시작합니다. 하지만 실제 업무는 보통 지저분한 메모(messy notes)에서 시작됩니다. 이해관계자(stakeholder)는 숫자가 틀린 것 같다고 말합니다. 다른 누군가는 필드(field)가 변경되었다고 말합니다. 또 다른 사람은 소스 파일(source file)이 정리되었다고 말합니다. 대시보드(dashboard) 소유자는 부재중입니다. 매니저(manager)는 리더십 회의 전에 업데이트가 필요합니다. 이것이 바로 제가 Gemma 4로 테스트하고 싶었던 상황입니다.

저는 비즈니스 시스템, 보고(reporting), 데이터 품질(data quality), 프로세스 인수인계(process handoffs) 분야에서 일하기 때문에 이 상황이 익숙하게 느껴졌습니다. 실제 보고 업무에서 위험한 순간은 항상 대시보드가 고장 날 때가 아닙니다. 아무도 소스를 확인하기 전에 모두가 정답을 원할 때가 위험한 순간입니다.

그래서 저는 한 가지 실용적인 질문을 테스트했습니다: Gemma 4가 지저분한 메모를 요약하는 것보다 더 유용한 일을 할 수 있을까? 더 구체적으로는: 지저분한 내용을 '알려진 것(known)', '가정된 것(assumed)', '위험한 것(risky)', 그리고 '여전히 확인이 필요한 것(still needs checking)'으로 분리할 수 있을까? 이것이 제가 중요하게 생각한 차이점이었습니다.

요약(summary)은 지저분한 정보를 압축합니다. 검토 패킷(review packet)은 정보를 사실(facts), 가정(assumptions), 리스크(risks), 그리고 다음 확인 사항(next checks)으로 분리합니다.

테스트 설정: 저는 의도적으로 테스트 규모를 작게 유지했습니다. Google AI Studio에서 Gemma 4 26B A4B IT를 사용했습니다. 동일한 모델 설정(temperature 0.25, thinking level을 High로 설정, 도구(tools) 미사용, 시스템 지침(system instructions) 없음)을 사용하여 동일한 지저분한 메모를 두 번 사용했습니다. 시스템 지침을 비워둔 이유는 프롬프트(prompt) 자체가 동작을 수행하기를 원했기 때문입니다. 이것은 모델 비교가 아니라 프롬프트 패턴(prompt-pattern) 비교였습니다. 제가 바꾼 유일한 것은 프롬프트였습니다.

시나리오는 인위적이지만 현실적이었습니다: 주간 운영 보고서(weekly operations report)가 월요일 아침까지 제출되어야 하고, 합계가 예상보다 낮아 보이며, 지난주에 필드 이름이 변경되었고, 중복 행(duplicate rows)이 제거되었을 수 있으며, 대시보드 소유자는 부재중인 상황입니다. 개인 정보는 없습니다. 회사 데이터도 없습니다. 단지 회의 전에 압박감을 조성하는 그런 지저분한 보고 상황일 뿐입니다.

테스트를 위해 축약된 노트 내용은 다음과 같습니다: 주간 운영 보고서가 월요일 아침까지 제출되어야 합니다. 보고서는 보통 일요일 밤에 갱신됩니다. 지난주에 필드 이름(field name) 하나가 변경되었습니다. 이해관계자(stakeholder) 한 명이 합계가 평소보다 낮아 보인다고 말합니다. 소스 파일에서 중복된 행(row)이 제거되었을 수 있습니다. 대시보드 소유자는 부재중입니다. 이 문제가 소스 데이터 때문인지, 필터 로직(filter logic) 때문인지, 아니면 정의(definition) 변경 때문인지는 아직 아무도 모릅니다.

프롬프트 1: 일반적인 요약을 요청하기
먼저 다음과 같이 요청했습니다: "이 노트들을 매니저를 위해 요약하고 무슨 일이 일어나고 있는지 설명해줘." 결과는 나쁘지 않았습니다.

기준 실행(Baseline run): 동일한 Gemma 4 모델, 동일한 노트, 시스템 지침(system instructions) 없음. Gemma 4는 매니저에게 보고하기 적합한 업데이트 내용과, 팀이 왜 아직 최종 수치를 제공하는 것을 피해야 하는지에 대한 평이한 영어 설명을 제공했습니다. 유용한 문구 중 하나는 다음과 같았습니다: "주간 합계의 불일치에 대해 조사 진행 중."
이런 버전을 Slack에 보내는 모습을 상상할 수 있었습니다. 하지만 이 요약은 요약(summarization)의 약점도 보여주었습니다. 모델은 "적색 경보(red alert)", "눈을 가리고 비행하는(flying blind)", "수치가 잘못되어 보인다(the numbers look wrong)"와 같은 문구를 사용했습니다. 이러한 문구들은 상황을 더 쉽게 이해하게 만들었지만, 원문 노트가 뒷받침하는 것보다 더 많은 확신과 드라마를 더했습니다. 원문 노트는 보고서가 틀렸다는 것을 증명하지 않았습니다. 단지 합계가 평소보다 낮아 보인다고만 말했을 뿐입니다. 이 점이 중요합니다. 요약은 지저분한 정보를 읽기 쉽게 만들 수 있지만, 실제 상황보다 상황이 더 정리된 것처럼 은밀하게 느끼게 만들 수 있습니다.

프롬프트 2: 검토 패킷(review packet)을 요청하기
그래서 저는 한 가지 변화를 주어 동일한 노트를 다시 실행했습니다. 요약을 요청하는 대신, 검토 패킷을 요청했습니다.

"당신은 검토 패킷을 준비하는 분석가입니다. 아래의 노트만을 사용하여 다음을 반환하세요:

1. 한 단락 요약
2. 확인된 사실 (Confirmed facts)
3. 가정 (Assumptions)
4. 검증되지 않은 주장 (Unverified claims)
5. 리스크 (Risks)
6. 인간 검토자를 위한 질문
7. 제안된 다음 조치
8. 아직 결론 내리지 말아야 할 사항
9. 최종 체크리스트

규칙:

• 사실을 지어내지 마세요.
• 사실과 가정을 분리하세요.
• 차분하고, 실용적이며, 간결하게 유지하세요.
• 인간이 다음에 무엇을 검증할지 결정하는 것을 도우세요. 최종 결정을 내리지 마세요."

출력물은 덜 다듬어져 있었지만, 팀 앞에 놓인 의사결정에는 더 유용했습니다. 확인된 사실(confirmed facts)과 가정(assumptions) 및 검증되지 않은 주장(unverified claims)을 분리했기 때문입니다. 예를 들어, "총계가 평소보다 낮아 보임"이라는 문구는 완료된 데이터 확인(data check) 결과가 아니라 이해관계자 보고서에서 나온 것이기에 검증되지 않은 주장으로 취급했습니다. 또한 가장 큰 미지수(unknown)인 "근본 원인은 현재 알 수 없음"을 명확히 드러냈습니다. 그것이 출력물에서 가장 중요한 부분이었습니다. 실제 보고 이슈가 발생하면 사람들은 종종 원인으로 바로 건너뛰고 싶어 합니다. 필드 변경이 문제를 일으켰다거나, 소스 파일이 변경되었다거나, 필터 로직이 잘못되었다는 식으로 말이죠. 하지만 이 시나리오에서는 그 중 어느 것도 아직 검증되지 않았습니다. 가장 강력했던 섹션은 "아직 결론 내리지 말아야 할 것(What not to conclude yet)"이었습니다: 데이터가 잘못되었다고 결론 내리지 마세요. 필드 이름 변경이나 중복 제거가 불일치를 유발했다고 결론 내리지 마세요. 문제가 소스 데이터인지, 필터 로직인지, 아니면 정의 변경인지 결론 내리지 마세요. 이 섹션 덕분에 출력물은 단순한 상태 업데이트(status update)에서 검토 도구(review tool)로 변모했습니다. 검토 패킷(Review-packet) 실행: 유용한 변화는 사실, 가정, 리스크, 그리고 아직 결론 내리지 말아야 할 것을 분리한 것이었습니다.

무엇이 변했는가
더 나은 출력물은 더 똑똑하게 들려서 더 나은 것이 아니었습니다. 팀에게 다음 단계를 위한 더 안전한 형태를 제공했기 때문에 더 나은 것이었습니다. 요약(summary)은 상태 전달(status communication)에 더 좋았습니다. 검토 패킷(review packet)은 무엇을 여전히 검증해야 하는지 결정하는 데 더 좋았습니다.

주의 사항: 이것이 여전히 아무것도 검증하지는 않습니다
이것은 제가 넘지 않을 경계선입니다. Gemma 4는 보고서를 조사하지 않았습니다. 소스 파일을 열지도 않았습니다. 대시보드 로직을 확인하지도 않았습니다. 중복 제거가 올바른지, 혹은 필드 이름 변경이 계산에 영향을 미쳤는지 알지 못했습니다. 모델은 검토 경로를 정리했을 뿐입니다. 그것은 유용하지만, 검증(verification)과 동일한 것은 아닙니다. 실제 보고 이슈가 발생한다면, 저는 최종적인 발언을 하기 전에 여전히 소스 행(source rows), 필드 매핑(field mapping), 보고서 필터(report filters), 새로고침 타이밍(refresh timing), 그리고 지표 정의(metric definition)를 확인할 것입니다. 검토 패킷이 그 작업을 대신해주지는 않습니다.

이는 제가 그 과정을 건너뛰지 않도록 보장해 줍니다. 복잡한 시스템 작업의 경우, 저는 조사를 마친 후가 아니라 조사하기 전에 이러한 종류의 출력을 사용할 것입니다. 이는 인간 검토자(human reviewer)를 대체하는 것이 아니라, 검토자를 준비시키는 방법입니다. 모델은 흩어진 메모를 조사 수행자를 위한 체크리스트(checklist)로 변환할 수 있습니다. 하지만 모델이 실제 시스템, 데이터, 정의 및 비즈니스 컨텍스트(business context)에 접근할 수 없다면 조사를 수행할 수는 없습니다.

Review Packet Framework (검토 패킷 프레임워크)
만약 누군가 이 게시물에서 단 한 가지만 복사한다면, 저는 이것이 바로 이 프롬프트(prompt) 형태이기를 바랍니다. 입력값이 무질서하거나, 불확실하거나, 시간에 민감한 경우, 모델에게 다음을 요청하십시오:

• 요약 (Summary)
• 확인된 사실 (Confirmed facts)
• 가정 (Assumptions)
• 확인되지 않은 주장 (Unverified claims)
• 리스크 (Risks)
• 인간 검토자를 위한 질문 (Questions for a human reviewer)
• 제안된 다음 조치 (Suggested next actions)
• 아직 결론 내리지 말아야 할 것 (What not to conclude yet)
• 최종 체크리스트 (Final checklist)

가장 유용한 부분이 항상 요약이나 체크리스트인 것은 아닙니다. 저에게 중요한 섹션은 다음과 같습니다:

• 가정 (assumptions)
• 확인되지 않은 주장 (unverified claims)
• 리스크 (risks)
• 아직 결론 내리지 말아야 할 것 (what not to conclude yet)

이 섹션들은 모델이 불확실성을 깔끔한 문단 속에 숨기는 대신, 가시적으로 유지하도록 강제합니다. 이것이 검토 패킷(review packet)을 요약보다 더 유용하게 만드는 핵심입니다.

왜 제가 Gemma 4를 이런 방식으로 사용했는가
제가 Gemma 4를 이런 방식으로 사용한 이유는 무질서한 메모가 실제 업무량(workload)이기 때문입니다. 보고서, 지원 인수인계(support handoffs), 장애 업데이트, 프로젝트 메모 등은 완벽한 형태로 전달되는 경우가 거의 없습니다. 유용한 질문은 모델이 그것들에 대해 쓸 수 있는지 여부만이 아닙니다. 그 안에 담긴 불확실성을 보존할 수 있는지 여부입니다. 이는 제가 가장 중요하게 생각하는 Gemma 4의 측면과 일치합니다. 즉, 단순한 텍스트 생성(text generation)이 아니라, 무질서한 컨텍스트(context)를 바탕으로 추론(reasoning)하고 인간이 사용할 수 있을 만큼 충분히 구조화된 결과물을 만들어내는 능력입니다.

이번 테스트를 위해 저는 26B A4B 인스트럭션(instruction) 모델을 사용했습니다. 가장 작은 모델을 실행하는 것보다 추론 구조(reasoning structure)를 더 중요하게 생각했기 때문입니다. 만약 가벼운 오프라인 도우미를 구축한다면, 다음에는 더 작은 Gemma 4 모델을 테스트할 것입니다.

최종 결론
저는 여전히 Gemma 4에게 요약을 요청할 것입니다. 하지만 이번 테스트 이후, 저는 요약만으로 충분한 상황이 언제인지에 대해 더 신중해질 것입니다.

상황이 복잡하거나, 시간이 촉박하거나, 혹은 검증되지 않은 주장들로 가득 차 있다면, 저는 차라리 검토 패킷 (review packet)을 요청하겠습니다. 유용한 결과물이 항상 가장 깔끔한 문단인 것은 아닙니다. 때로는 다음과 같이 말하는 결과물이 더 유용합니다: '우리가 알고 있는 것, 우리가 가정하고 있는 것, 잘못될 수 있는 것, 아직 결론을 내리지 말아야 할 것'. 이것이 제가 재사용할 패턴입니다. Gemma 4는 혼란을 제거한 것이 아닙니다. 그 혼란을 검토 가능한 상태로 만든 것입니다.