Featured Post

Gemini 멀티모달 분석을 개발 업무에 붙여보니, 이미지·PDF·영상 처리 방식이 확 달라졌다

작성자:
Gemini - 멀티모달 분석 관련 이미지

며칠 전, 주말에 짧게 다녀온 여행 사진을 정리하다가 문득 그런 생각이 들었어요. 영수증 사진, 안내판 사진, 메뉴판 사진, 이동 경로 캡처, 짧은 동영상까지 전부 다 “데이터”인데, 나는 이걸 아직도 사람이 눈으로 보고 하나씩 정리하고 있구나 싶더라고요. 개발자로 일하면서 로그와 JSON은 그렇게 열심히 자동화하면서, 정작 이미지나 PDF, 영상은 은근히 수작업으로 넘기는 경우가 많았고요. 그래서 이번에는 조금 작정하고 Gemini - 멀티모달 분석을 실제 업무 흐름에 붙여봤습니다. 그냥 “이미지를 이해합니다” 같은 소개가 아니라, API로 붙였을 때 어디까지 쓸만한지, 어디서 삐끗하는지, 프롬프트는 어떻게 줘야 결과가 안정적인지 제 경험 위주로 풀어볼게요.

사실 LLM을 텍스트 챗봇으로만 쓰면 반쪽짜리라는 생각을 꽤 오래 했습니다. 요즘 개발 업무는 텍스트만 있는 게 아니잖아요. 기획서는 PDF로 오고, 버그는 스크린샷으로 오고, QA는 영상으로 남고, 고객 문의에는 첨부 이미지가 따라옵니다. 이걸 전부 사람이 읽고 요약해서 티켓으로 옮기는 순간, 하루가 은근히 녹습니다. Gemini의 멀티모달 분석은 바로 이 지점에서 꽤 실용적이었습니다.

내가 Gemini 멀티모달 분석을 붙여본 실제 업무 시나리오

이번에 테스트한 건 크게 네 가지였어요. 이미지 분석, PDF 분석, 짧은 영상 분석, 그리고 스크린샷 기반 UI 버그 분석입니다. 저는 주로 Node.js와 TypeScript 기반의 내부 도구에 붙였고, 결과는 Notion이나 Jira에 넣기 전 단계의 JSON으로 뽑는 방식으로 만들었습니다.

분석 대상 실제 사용 예 Gemini에게 맡긴 일 체감 효과
이미지 영수증, 메뉴판, 오류 캡처 항목 추출, 금액 계산, 화면 요소 설명 수기 입력 시간이 크게 줄어듦
PDF 제안서, API 명세서, 계약 초안 핵심 요구사항 요약, 위험 문구 추출 초기 검토 속도가 빨라짐
영상 QA 재현 영상, 화면 녹화 사용자 행동 순서 정리, 오류 발생 지점 추정 버그 티켓 작성 품질이 좋아짐
스크린샷 관리자 페이지, 모바일 UI UI 불일치, 접근성 문제, 텍스트 오타 확인 기획자와 개발자 간 대화가 짧아짐

이전에 Gemini 자체의 활용 방향을 넓게 정리한 글도 있었는데요. 전체적인 흐름을 먼저 보고 싶다면 Gemini - 멀티모달 AI가 여는 실전 활용법: 개발, 콘텐츠, 일본어 공부의 새로운 패러다임 글을 같이 보면 감이 더 빨리 잡힐 거예요. 이번 글은 거기서 한 발 더 들어가서, 개발자가 실제 API로 붙일 때 부딪히는 부분에 초점을 맞췄습니다.

프로젝트 구조는 최대한 단순하게 잡았다

저는 이런 실험을 할 때 처음부터 거창한 서비스 구조로 만들지 않습니다. 괜히 NestJS, Queue, Storage, Admin까지 한 번에 붙이면 어디서 문제가 생겼는지 흐려지거든요. 여행 갈 때도 처음 가는 도시는 동선을 단순하게 잡는 편인데, 개발 실험도 비슷합니다. 일단 작게 움직여보고, 좋으면 확장하는 방식이 오래 갑니다.

실험용 폴더 구조

gemini-multimodal-lab/
├─ package.json
├─ .env
├─ tsconfig.json
├─ samples/
│  ├─ receipt.jpg
│  ├─ mobile-bug.png
│  ├─ api-spec.pdf
│  └─ qa-recording.mp4
├─ src/
│  ├─ index.ts
│  ├─ geminiClient.ts
│  ├─ analyzers/
│  │  ├─ analyzeImage.ts
│  │  ├─ analyzePdf.ts
│  │  ├─ analyzeVideo.ts
│  │  └─ analyzeScreenshot.ts
│  ├─ prompts/
│  │  ├─ receiptPrompt.ts
│  │  ├─ bugPrompt.ts
│  │  └─ pdfPrompt.ts
│  └─ utils/
│     ├─ fileToBase64.ts
│     ├─ safeJsonParse.ts
│     └─ retry.ts
└─ outputs/
   ├─ receipt-result.json
   ├─ bug-ticket.json
   └─ pdf-summary.json

포인트는 프롬프트를 코드에서 분리했다는 점입니다. 이거 정말 중요합니다. 바이브 코딩으로 만들다 보면 처음에는 index.ts 안에 프롬프트를 대충 박아 넣게 되는데, 나중에 결과 품질을 조정하려면 지옥이 열립니다. 프롬프트는 거의 비즈니스 로직에 가까워요. 버전 관리해야 하고, 테스트해야 하고, 실패한 케이스와 함께 남겨야 합니다.

기본 Gemini 클라이언트 설정

import { GoogleGenAI } from "@google/genai";

export const ai = new GoogleGenAI({
  apiKey: process.env.GEMINI_API_KEY
});

파일을 base64로 읽는 유틸

import fs from "fs";

export function fileToBase64(path: string): string {
  const buffer = fs.readFileSync(path);
  return buffer.toString("base64");
}

실제 운영에서는 파일 크기, MIME type 검증, 바이러스 스캔, 개인정보 마스킹을 더 넣어야 합니다. 하지만 실험 단계에서는 일단 이렇게 시작해도 충분했어요. 다만 회사 데이터나 고객 데이터로 바로 테스트하는 건 저는 추천하지 않습니다. 샘플 데이터로 먼저 흐름을 검증하고, 보안 검토를 거친 다음 붙이는 게 마음 편합니다.

사례 1: 영수증 이미지에서 지출 내역 뽑기

제일 먼저 해본 건 영수증 분석이었습니다. 여행 다녀오면 카드 내역과 영수증 사진이 뒤섞이잖아요. 회사에서도 출장비 정산이나 비용 증빙 같은 데 비슷한 문제가 있고요. OCR만 쓰면 글자는 뽑히는데, “이게 상호명인지, 합계인지, 부가세인지” 구조화가 애매한 경우가 많습니다. 여기서 Gemini 멀티모달 분석이 꽤 괜찮았습니다.

영수증 분석 프롬프트

export const receiptPrompt = `
너는 한국어 영수증을 분석하는 정산 보조 도구다.

이미지에서 확인 가능한 정보만 추출해라.
추측이 필요한 값은 null로 둔다.
금액은 숫자만 사용한다.
날짜는 YYYY-MM-DD 형식으로 변환한다.
상호명, 결제일, 품목, 합계금액, 부가세, 결제수단을 JSON으로 반환한다.

반드시 아래 형식을 지켜라.

{
  "storeName": string | null,
  "paidAt": string | null,
  "items": [
    {
      "name": string,
      "quantity": number | null,
      "price": number | null
    }
  ],
  "subtotal": number | null,
  "vat": number | null,
  "total": number | null,
  "paymentMethod": string | null,
  "confidence": "high" | "medium" | "low",
  "warnings": string[]
}
`;

이미지 분석 코드

import { ai } from "../geminiClient";
import { fileToBase64 } from "../utils/fileToBase64";
import { receiptPrompt } from "../prompts/receiptPrompt";

export async function analyzeReceiptImage(imagePath: string) {
  const base64 = fileToBase64(imagePath);

  const response = await ai.models.generateContent({
    model: "gemini-2.5-flash",
    contents: [
      {
        inlineData: {
          mimeType: "image/jpeg",
          data: base64
        }
      },
      {
        text: receiptPrompt
      }
    ],
    config: {
      responseMimeType: "application/json"
    }
  });

  return response.text;
}

여기서 제가 처음에 실수한 게 하나 있습니다. “알아서 잘 정리해줘”라고 프롬프트를 넣었더니, 결과는 보기 좋았지만 시스템에 넣기는 별로였습니다. 어떤 건 “약 12,000원”이라고 나오고, 어떤 건 “₩12,000”으로 나오고, 어떤 건 품목명에 설명까지 붙더라고요. 사람 눈에는 친절하지만 코드 입장에서는 피곤한 결과입니다.

그래서 저는 멀티모달 분석을 할 때 반드시 JSON 형식, null 처리 규칙, 추측 금지 규칙을 같이 넣습니다. 이 세 가지가 없으면 결과가 예쁘긴 한데 자동화에는 잘 안 맞아요.

실제로 나온 결과 예시

{
  "storeName": "카페 모리",
  "paidAt": "2026-05-18",
  "items": [
    {
      "name": "아메리카노",
      "quantity": 2,
      "price": 9000
    },
    {
      "name": "치즈케이크",
      "quantity": 1,
      "price": 6500
    }
  ],
  "subtotal": 15500,
  "vat": null,
  "total": 15500,
  "paymentMethod": "카드",
  "confidence": "medium",
  "warnings": [
    "부가세 항목은 이미지에서 명확히 확인되지 않음"
  ]
}

이 정도면 사람이 최종 확인만 해도 됩니다. 제가 체감한 기준으로는 선명한 영수증은 꽤 잘 뽑고, 구겨진 영수증이나 빛 반사가 심한 사진은 confidence를 낮게 주도록 프롬프트를 설계하는 게 좋았습니다.

사례 2: UI 버그 스크린샷을 Jira 티켓 초안으로 바꾸기

개발팀에서 은근히 시간을 많이 잡아먹는 게 “이거 화면 이상해요”로 시작하는 대화입니다. 스크린샷 하나만 던져지고, 어느 페이지인지, 어떤 조건인지, 기대 동작이 뭔지 다시 물어봐야 하죠. 물론 완전히 자동화할 수는 없습니다. 그래도 Gemini에게 스크린샷을 먼저 보게 하고 티켓 초안을 만들게 하면 대화의 출발점이 훨씬 좋아집니다.

버그 분석용 프롬프트

export const bugPrompt = `
너는 프론트엔드 QA 엔지니어다.
첨부된 화면 캡처를 보고 UI 문제를 분석해라.

다음 기준으로만 답해라.
1. 이미지에서 실제로 보이는 문제
2. 사용자가 겪을 수 있는 불편
3. 개발자가 재현을 위해 확인해야 할 정보
4. Jira 티켓에 바로 붙일 수 있는 제목과 설명

모르는 페이지명이나 기능명은 지어내지 말고 "확인 필요"라고 적어라.

JSON 형식:
{
  "title": string,
  "severity": "blocker" | "major" | "minor" | "trivial",
  "visibleSymptoms": string[],
  "possibleCauses": string[],
  "reproductionQuestions": string[],
  "suggestedTicketBody": string
}
`;

스크린샷 분석 결과 예시

{
  "title": "모바일 화면에서 하단 CTA 버튼이 콘텐츠와 겹쳐 보임",
  "severity": "major",
  "visibleSymptoms": [
    "하단 고정 버튼이 본문 마지막 문장 일부를 가리고 있음",
    "버튼과 콘텐츠 사이 여백이 부족함",
    "오른쪽 하단 아이콘이 버튼 영역과 시각적으로 충돌함"
  ],
  "possibleCauses": [
    "하단 fixed 영역 높이만큼 padding-bottom이 적용되지 않았을 가능성",
    "모바일 safe-area inset 처리가 누락되었을 가능성"
  ],
  "reproductionQuestions": [
    "사용한 기기 모델과 브라우저는 무엇인가?",
    "문제가 발생한 화면의 URL 또는 메뉴 경로는 무엇인가?",
    "로그인 상태 또는 특정 권한에서만 발생하는가?"
  ],
  "suggestedTicketBody": "모바일 화면에서 하단 고정 CTA 버튼이 본문 콘텐츠를 가리는 문제가 보입니다. 콘텐츠 영역에 fixed footer 높이만큼 하단 여백이 적용되어 있는지 확인이 필요합니다."
}

솔직히 이 결과를 처음 봤을 때 좀 놀랐습니다. 단순히 “버튼이 겹침” 정도가 아니라, safe-area inset 같은 프론트엔드 실무 포인트를 같이 짚어줬거든요. 물론 항상 맞지는 않습니다. 그래서 저는 possibleCauses를 “정답”이 아니라 “점검 후보”로만 다룹니다. 이 관점이 중요해요. AI가 말한 원인을 그대로 믿는 순간 사고가 납니다.

방식 장점 아쉬운 점
사람이 직접 티켓 작성 맥락 파악이 정확함 작성자마다 품질 차이가 큼
Gemini로 초안 생성 증상 정리와 질문 목록이 빠름 원인 추정은 검증 필요
템플릿만 사용 형식이 안정적임 이미지 속 구체적 문제를 반영하기 어려움

사례 3: PDF API 명세서를 읽고 변경 영향도 뽑기

개발자 입장에서 PDF는 늘 묘한 존재입니다. 문서이긴 한데, 코드와 바로 연결되지는 않고, 복사하면 줄바꿈이 깨지고, 표는 더 엉망이고요. 외부 업체에서 API 명세서를 PDF로 보내오면 일단 열어보는 순간 살짝 한숨이 나옵니다. Gemini 멀티모달 분석은 PDF에서 “읽고 요약하기”보다 변경 영향도 추출 쪽으로 쓸 때 더 좋았습니다.

PDF 분석 프롬프트

export const pdfPrompt = `
너는 백엔드 개발 리드다.
첨부된 API 명세서 PDF를 읽고 개발 영향도를 분석해라.

다음 항목을 중심으로 정리해라.

  • 신규 endpoint


  • 변경된 request parameter


  • 변경된 response field


  • 인증 또는 권한 관련 변경


  • 하위 호환성 위험


  • 개발자가 확인해야 할 질문


문서에 없는 내용은 추측하지 마라.
위험도가 높은 항목은 이유를 함께 적어라.

JSON 형식:
{
  "newEndpoints": string[],
  "changedRequestParams": string[],
  "changedResponseFields": string[],
  "authChanges": string[],
  "compatibilityRisks": [
    {
      "risk": string,
      "level": "high" | "medium" | "low",
      "reason": string
    }
  ],
  "questions": string[]
}
`;

여기서 재밌었던 건, “요약해줘”라고 했을 때보다 “백엔드 개발 리드 입장에서 영향도를 분석해줘”라고 했을 때 결과가 훨씬 실무적이었다는 점입니다. 같은 문서를 넣어도 역할과 출력 기준을 어떻게 주느냐에 따라 결과가 확 달라집니다. 이게 제가 말하는 바이브 코딩의 핵심이에요. 느낌으로 대충 던지는 게 아니라, AI에게 맡길 직무와 검토 기준을 아주 구체적으로 부여하는 것이죠.

Gemini 2.5 Pro를 업무에 붙였을 때의 체감 변화는 예전에 별도로 적어둔 적이 있습니다. 모델 선택 기준이 궁금하다면 Gemini 2.5 Pro, 멀티모달 AI가 내 업무를 이렇게 바꿔버렸다 글도 같이 읽어보면 좋습니다. 저는 빠른 반복은 Flash 계열, 복잡한 문서 검토는 Pro 계열로 나누는 쪽이 편했습니다.

사례 4: QA 화면 녹화 영상에서 재현 순서 뽑기

영상 분석은 기대 반, 의심 반이었습니다. QA 담당자가 보내준 30초짜리 화면 녹화 영상을 Gemini에게 넣고, 사용자가 어떤 버튼을 눌렀고 어느 시점에 오류가 났는지 정리하게 해봤습니다. 물론 아주 긴 영상이나 복잡한 상호작용은 아직 사람이 보는 게 낫습니다. 그래도 짧은 재현 영상에서는 꽤 쓸만했어요.

영상 분석 코드 예시

import { ai } from "../geminiClient";
import { fileToBase64 } from "../utils/fileToBase64";

export async function analyzeQaVideo(videoPath: string) {
  const base64 = fileToBase64(videoPath);

  const prompt = `
너는 QA 엔지니어가 보낸 화면 녹화 영상을 분석하는 개발자다.

영상에서 보이는 사용자 행동을 시간 순서대로 정리해라.
오류 메시지가 보이면 정확한 문구를 적어라.
오류 발생 직전 사용자가 한 행동을 별도로 표시해라.
화면에 보이지 않는 원인은 추측하지 마라.

JSON 형식:
{
  "steps": [
    {
      "order": number,
      "action": string,
      "screenState": string
    }
  ],
  "errorMoment": {
    "approxTime": string | null,
    "message": string | null,
    "previousAction": string | null
  },
  "developerNotes": string[]
}
`;

  const response = await ai.models.generateContent({
    model: "gemini-2.5-pro",
    contents: [
      {
        inlineData: {
          mimeType: "video/mp4",
          data: base64
        }
      },
      {
        text: prompt
      }
    ],
    config: {
      responseMimeType: "application/json"
    }
  });

  return response.text;
}

영상 분석에서 조심해야 할 점은 시간 정보가 아주 정밀하지 않을 수 있다는 겁니다. “12초쯤”이라고 했는데 실제로는 14초일 수 있어요. 그래서 저는 approxTime이라고 필드명을 일부러 애매하게 둡니다. 코드나 티켓에서 이 값을 절대적인 타임코드처럼 쓰면 안 됩니다.

    • 짧은 QA 영상은 15초에서 60초 사이가 가장 다루기 편했습니다.
    • 마우스 포인터가 잘 보이면 사용자 행동 분석 품질이 좋아졌습니다.
    • 토스트 메시지처럼 금방 사라지는 텍스트는 놓칠 때가 있어, 가능하면 영상과 스크린샷을 같이 넣는 게 좋았습니다.
    • 모바일 화면 녹화는 해상도가 낮으면 작은 글씨를 잘못 읽는 경우가 있었습니다.

실무에서 바로 부딪힌 문제들: 멀티모달 분석은 만능이 아니었다

좋은 이야기만 하면 좀 광고 같잖아요. 실제로 붙여보면 꽤 많은 삐걱거림이 있습니다. 저는 특히 세 가지에서 시간을 많이 썼습니다. JSON 깨짐, 과한 추측, 비용과 지연시간 관리입니다.

문제 1: JSON이 가끔 깨진다

responseMimeType을 application/json으로 줘도, 프롬프트가 복잡하거나 이미지가 애매하면 결과가 기대한 스키마와 조금 어긋날 때가 있었습니다. 예를 들어 warnings가 배열이어야 하는데 문자열로 나오거나, null이어야 할 값에 “확인 불가”가 들어오는 식입니다. 

{
  "storeName": "확인 불가",
  "paidAt": null,
  "items": "이미지가 흐려 품목 확인이 어렵습니다",
  "total": "약 15000원"
}

이런 결과를 운영 코드에서 바로 믿으면 장애가 납니다. 저는 그래서 AI 응답 뒤에 항상 검증 레이어를 둡니다. Zod 같은 라이브러리로 스키마를 검증하고, 실패하면 한 번 더 “스키마에 맞게 고쳐라”는 복구 프롬프트를 태우는 방식입니다. 

import { z } from "zod";

export const ReceiptSchema = z.object({
  storeName: z.string().nullable(),
  paidAt: z.string().nullable(),
  items: z.array(
    z.object({
      name: z.string(),
      quantity: z.number().nullable(),
      price: z.number().nullable()
    })
  ),
  subtotal: z.number().nullable(),
  vat: z.number().nullable(),
  total: z.number().nullable(),
  paymentMethod: z.string().nullable(),
  confidence: z.enum(["high", "medium", "low"]),
  warnings: z.array(z.string())
});

export function validateReceiptResult(raw: unknown) {
  return ReceiptSchema.safeParse(raw);
}

문제 2: AI가 친절하게 추측한다

LLM은 기본적으로 도움이 되고 싶어 합니다. 이게 장점이기도 한데, 분석 업무에서는 독이 될 때가 있어요. 이미지에 안 보이는 상호명을 근처 문맥으로 추정하거나, PDF에 없는 정책을 일반적인 관행으로 채워 넣는 경우가 있습니다. 뭐랄까, 똑똑한 동료가 너무 적극적으로 나서는 느낌입니다.

저는 이 문제를 줄이려고 프롬프트에 아래 문장을 거의 습관처럼 넣습니다. 

이미지나 문서에서 직접 확인할 수 없는 내용은 추측하지 마라.
추측이 필요한 경우 null 또는 "확인 필요"라고 적어라.
가능하면 어떤 근거로 판단했는지 evidence 필드에 짧게 남겨라.

evidence 필드를 넣으면 결과 검토가 훨씬 편해집니다. 예를 들어 “하단 버튼이 겹침”이라고만 나오면 믿어야 할지 애매한데, “본문 마지막 줄 일부가 버튼 뒤에 가려져 있음”처럼 근거가 같이 나오면 사람이 판단하기 좋습니다.

문제 3: 비용과 지연시간은 설계로 잡아야 한다

가격은 사용하는 모델, 입력 토큰, 파일 크기, 지역, API 제공 방식에 따라 바뀝니다. 제가 테스트할 때는 Google AI Studio의 무료 사용량으로 충분히 실험할 수 있었지만, 팀 단위 운영에서는 유료 과금 기준을 꼭 확인해야 합니다. 특히 영상과 PDF는 텍스트 프롬프트보다 입력량이 커질 수 있어서, 아무 생각 없이 모든 첨부 파일을 Pro 모델로 보내면 비용이 생각보다 빨리 올라갈 수 있습니다.

작업 유형 추천 모델 전략 이유
영수증, 단순 이미지 분류 빠른 모델 우선 정형 추출이라 고급 추론이 덜 필요함
복잡한 PDF 명세서 분석 상위 모델 사용 긴 문맥과 영향도 판단이 중요함
QA 영상 분석 짧게 자른 뒤 분석 영상 전체를 보내면 비용과 지연시간이 커짐
대량 첨부 자동 처리 전처리 후 선별 전송 불필요한 파일까지 분석하지 않게 막아야 함

바이브 코딩으로 Gemini 멀티모달 분석을 다룰 때의 프롬프트 꿀팁

저는 요즘 AI 코딩을 할 때 “한 번에 완성해줘”보다 “같이 좁혀가자”에 가깝게 씁니다. 특히 Gemini - 멀티모달 분석은 입력이 이미지, PDF, 영상이라 결과를 눈으로 검증해야 하거든요. 그래서 프롬프트도 처음부터 최종형을 노리기보다, 실패 케이스를 모으면서 조금씩 단단하게 만듭니다.

제가 실제로 자주 쓰는 프롬프트 패턴

나는 Node.js와 TypeScript로 Gemini 멀티모달 분석 파이프라인을 만들고 있다.
입력은 사용자가 업로드한 이미지이고, 출력은 백엔드에서 검증 가능한 JSON이어야 한다.

너는 지금부터 시니어 백엔드 개발자이자 QA 자동화 설계자다.
아래 요구사항을 만족하는 코드를 제안해라.

요구사항:

  • Gemini API 호출 코드는 별도 모듈로 분리


  • 프롬프트는 prompts 폴더에서 관리


  • 응답은 Zod 스키마로 검증


  • JSON 파싱 실패 시 재시도 로직 포함


  • 이미지에서 확인되지 않는 내용은 추측하지 않도록 프롬프트 작성


  • 운영 환경에서 문제가 될 개인정보 처리 주의점도 함께 설명


먼저 폴더 구조를 제안하고, 그 다음 핵심 코드만 보여줘.

이 프롬프트의 핵심은 “코드 짜줘”가 아니라 내가 원하는 설계 기준을 먼저 박아두는 것입니다. AI에게 역할을 주고, 제약을 주고, 출력 순서를 정해주면 결과가 훨씬 덜 흔들립니다. 특히 “핵심 코드만”이라는 말도 중요합니다. 안 그러면 필요 없는 UI 코드나 장황한 설명까지 한꺼번에 튀어나와서 오히려 피곤해집니다.

멀티모달 프롬프트를 만들 때 체크하는 항목

    • 입력 대상이 이미지인지, PDF인지, 영상인지 명확히 적었는가?
    • AI의 역할을 OCR 도구, QA 엔지니어, 백엔드 리드처럼 구체적으로 지정했는가?
    • 출력 형식을 JSON으로 고정했는가?
    • 추측 금지와 null 처리 규칙을 넣었는가?
    • confidence 또는 warnings 필드를 넣어 불확실성을 표현하게 했는가?
    • 운영 코드 검증을 위해 스키마를 따로 두었는가?
    • 실패 샘플을 모아서 프롬프트 개선에 반영하고 있는가?

저는 프롬프트를 잘 쓰는 사람이 앞으로 개발 생산성에서 꽤 큰 차이를 만들 거라고 봅니다. 단, 프롬프트만 잘 쓰면 된다는 뜻은 아니에요. 오히려 개발자의 기본기가 더 중요해졌습니다. 왜냐하면 AI 결과를 시스템에 안전하게 넣으려면 검증, 예외 처리, 보안, 비용 관리, 관측 가능성 같은 것들이 반드시 필요하거든요.

운영에 붙이기 전에 꼭 넣어야 하는 방어 코드

실험용 코드와 운영용 코드는 다릅니다. 로컬에서 샘플 이미지 10장 돌릴 때는 몰랐던 문제가, 실제 사용자 파일 1,000개가 들어오면 바로 드러납니다. 파일명이 이상하거나, MIME type이 틀리거나, 이미지가 너무 크거나, PDF에 개인정보가 잔뜩 들어 있는 경우도 있고요.

간단한 재시도 로직

export async function retry<T>(
  task: () => Promise<T>,
  maxAttempts = 3,
  delayMs = 800
): Promise<T> {
  let lastError: unknown;

  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await task();
    } catch (error) {
      lastError = error;

      if (attempt < maxAttempts) {
        await new Promise((resolve) => setTimeout(resolve, delayMs * attempt));
      }
    }
  }

  throw lastError;
}

운영 적용 전 체크리스트

    • 업로드 가능한 파일 확장자와 MIME type을 제한한다.
    • 파일 크기 제한을 둔다. 특히 영상은 별도 제한이 필요하다.
    • 개인정보가 포함될 가능성이 있는 이미지는 저장 기간을 짧게 잡는다.
    • AI 응답 원문과 파싱 결과를 분리해서 로그로 남긴다.
    • 로그에는 민감 정보가 남지 않도록 마스킹한다.
    • 모델 호출 실패 시 사용자가 다시 시도할 수 있는 UX를 준비한다.
    • 자동 반영이 아니라 사람 검토 단계를 먼저 둔다.

저는 특히 “자동 반영”을 조심합니다. 예를 들어 영수증 금액을 Gemini가 읽었다고 해서 바로 정산 승인에 반영하면 위험합니다. UI 버그 원인을 추정했다고 해서 바로 담당자에게 할당하는 것도 애매하고요. 처음에는 초안 생성, 검토 보조, 후보 추출 정도로 쓰는 게 좋습니다. 그다음 정확도와 실패 패턴이 충분히 쌓이면 자동화 범위를 넓히는 게 안전합니다.

Gemini 멀티모달 분석을 써보며 정리한 내 기준

한동안 써보니 제 안에서 기준이 좀 생겼습니다. Gemini 멀티모달 분석은 “사람을 대체하는 도구”라기보다는 사람이 보기 전에 초벌 정리를 해주는 도구에 가깝습니다. 이 관점으로 쓰면 만족도가 높고, 반대로 완전 자동 판정을 기대하면 실망할 수 있습니다.

잘 맞는 일 아직 조심해야 할 일
이미지 속 텍스트와 구조를 초안으로 추출 법적 효력이 있는 문서의 최종 판단
스크린샷 기반 UI 증상 정리 코드 원인을 단정하는 분석
PDF의 변경 포인트 후보 추출 보안 정책이나 계약 조건의 최종 승인
QA 영상의 재현 순서 초안 작성 정밀한 초 단위 이벤트 판정

비용 면에서는 처음부터 큰 파이프라인을 만들기보다, 가장 반복적이고 귀찮은 작업 하나를 고르는 걸 추천합니다. 제 기준으로는 “영수증 정리”, “QA 티켓 초안”, “PDF 명세서 변경점 추출” 셋 중 하나가 시작점으로 좋았습니다. 성공 여부를 판단하기도 쉽고, 팀원들이 체감하기도 좋거든요.

이런 개발자에게 특히 추천하고 싶다

이 글은 단순히 “Gemini가 이미지도 봅니다” 정도의 소개를 찾는 분보다는, 실제로 Gemini - 멀티모달 분석을 자기 서비스나 내부 도구에 붙여보고 싶은 개발자에게 더 잘 맞을 것 같습니다. 특히 첨부 파일이 많은 업무를 다루는 팀, QA와 개발 사이의 커뮤니케이션 비용이 큰 팀, PDF 문서를 자주 검토하는 백엔드 개발자라면 꽤 재미있게 써볼 만합니다.

제 총평은 이렇습니다. Gemini 멀티모달 분석은 아직 모든 걸 믿고 맡길 단계는 아니지만, 개발자가 적당한 가드레일을 세워주면 반복 업무를 줄이는 데 확실히 도움이 됩니다. 프롬프트를 잘게 나누고, JSON 스키마를 강제하고, 추측을 막고, 사람이 검토하는 흐름을 남겨두면 실무에서 꽤 단단하게 굴러갑니다.

뭐랄까, 좋은 여행 도구와 비슷합니다. 지도 앱이 길을 알려줘도 마지막 골목은 내가 보고 판단해야 하잖아요. Gemini도 그렇습니다. 방향을 빨리 잡아주고, 놓친 포인트를 알려주고, 초안을 만들어줍니다. 하지만 최종 판단은 개발자의 몫입니다. 저는 그 균형이 꽤 마음에 들었습니다.

👨‍💻

작성자: 20년 경력 IT 전문 아키텍트

실무 개발과 아키텍처 설계를 거쳐 현재는 AI 바이브 코딩과 개발 자동화를 연구하고 있습니다. 직접 삽질하며 깨달은 실전 꿀팁과 에러 극복 사례만 투명하게 공유합니다.

댓글

댓글 쓰기