Feature/receipt image vision v2 by jinho-yoo-jack · Pull Request #3 · jinho-yoo-jack/Spring-for-ai

jinho-yoo-jack · 2025-11-20T14:06:43Z

Summary by CodeRabbit

릴리스 노트

새로운 기능
- 영수증 이미지 처리 엔드포인트가 추가되었습니다.
- 이미지 분석 결과에 메타데이터(이미지 유형, 크기, 토큰 사용량)가 함께 제공됩니다.
개선 사항
- Vision 서비스의 이미지 분석 처리가 개선되어 더 일관된 응답 구조를 제공합니다.
- 문서 처리 기능의 내부 구조가 재설계되었습니다.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

coderabbitai · 2025-11-20T14:06:51Z

요약

Walkthrough

이 풀 요청은 이미지 분석 기능을 제너릭 응답 구조로 리팩토링합니다. 새로운 ImageAnalysis 레코드와 제너릭 ImageAnalysisResponseV2<T> 응답 타입을 도입하고, 비전 서비스를 통합하며, 영수증 처리 전용 ReceiptAnalysisService를 추가합니다. 기존 문서 처리 메서드를 새 응답 구조로 마이그레이션합니다.

Changes

내용	설명
프로젝트 초기화 `README.md`	프로젝트 설명이 포함된 새 README 파일 추가
공통 DTO 추가 `spring-ai-app/src/main/java/org/sprain/ai/dto/ImageAnalysis.java` `spring-ai-app/src/main/java/org/sprain/ai/dto/ImageAnalysisResponseV2.java`	이미지 분석을 위한 새 레코드 및 제너릭 응답 래퍼 도입. 팩토리 메서드를 통한 유연한 인스턴스 생성 지원
비전 서비스 리팩토링 `spring-ai-app/src/main/java/org/sprain/ai/service/VisionService.java` `spring-ai-app/src/main/java/org/sprain/ai/service/VisionServiceV2.java`	기존 `analyzeImage` 메서드를 제너릭 버전으로 변환. 새로운 `VisionServiceV2` 구현으로 토큰 사용 추적 및 타입 변환 기능 추가
문서 처리 서비스 업데이트 `spring-ai-app/src/main/java/org/sprain/ai/service/DocumentProcessingService.java`	반환 타입을 `ImageAnalysisResponseV2<T>`로 변경. 내부 파싱 로직을 제거하고 비전 서비스로 위임
신규 영수증 분석 서비스 `spring-ai-app/src/main/java/org/sprain/ai/service/ReceiptAnalysisService.java`	영수증 처리 전용 서비스 추가. JSON 정제 및 검증 로직 포함
컨트롤러 통합 `spring-ai-app/src/main/java/org/sprain/ai/controller/VisionController.java`	`ReceiptAnalysisService` 의존성 주입 및 `/receipt` 엔드포인트 추가. 기존 엔드포인트 시그니처 업데이트

Sequence Diagrams

sequenceDiagram
    participant Client
    participant Controller
    participant VisionService
    participant ChatAPI
    participant DocumentService

    Client->>Controller: POST /receipt (image)
    Controller->>VisionService: analyzeImage(ImageAnalysis, ReceiptData.class)
    VisionService->>VisionService: validateImageAnalysis()
    VisionService->>VisionService: createUserMessage(imageBytes, contentType)
    VisionService->>ChatAPI: call chat API with image + prompt
    ChatAPI-->>VisionService: response text + metadata
    VisionService->>VisionService: cleanJsonResponse(text)
    VisionService->>VisionService: convertToTargetType(text, ReceiptData.class)
    VisionService->>VisionService: extractTokenUsage(metadata)
    VisionService-->>Controller: ImageAnalysisResponseV2<ReceiptData>
    Controller-->>Client: HTTP 200 + response

sequenceDiagram
    participant DocumentService
    participant VisionService
    participant ImageAnalysis

    Note over DocumentService,ImageAnalysis: 이전: 직접 파싱 로직
    DocumentService->>DocumentService: extractReceipt(MultipartFile)
    DocumentService->>DocumentService: manual JSON parsing
    DocumentService-->>DocumentService: ReceiptData

    rect rgb(200, 220, 255)
    Note over DocumentService,ImageAnalysis: 이후: 위임 패턴
    DocumentService->>ImageAnalysis: ImageAnalysis.of(prompt, file)
    DocumentService->>VisionService: analyzeImage(imageAnalysis, ReceiptData.class)
    VisionService-->>DocumentService: ImageAnalysisResponseV2<ReceiptData>
    end

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

주의 영역:
- VisionService.java: 기존 analyzeImage 메서드의 완전한 시그니처 변경(String, MultipartFile → ImageAnalysis, Class<T>). 제너릭 디스패치 로직(promptWithResponseFormat, promptByChatResponse)과 타입 캐스팅 안전성 검증 필요
- VisionServiceV2.java: 새로운 구현체로 JSON 정제(cleanJsonResponse), 타입 변환 로직, 예외 처리(RuntimeException 래핑) 검토 필요
- ReceiptAnalysisService.java: 프롬프트 엔지니어링, JSON 검증 로직 및 NoSuchFieldException 스로우 조건 검토
- DocumentProcessingService.java: 반환 타입 변경에 따른 기존 호출처 호환성 영향 범위 파악 필요
- 제너릭 구조(ImageAnalysisResponseV2<T>) 도입에 따른 타입 안전성 및 런타임 타입 정보 손실 검토

Poem

🐰 새로운 구조로 이미지 분석,
제너릭의 우아한 마법,
토큰을 세며 응답을 깎고,
영수증부터 차트까지 모두 담아,
봄 AI의 마음도 한 발 더 나아갔네! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	PR 제목이 주요 변경사항을 명확하게 반영하며, 구체적인 기능 추가를 설명합니다. Receipt 이미지 분석 및 Vision V2 기능 구현이라는 핵심 변경사항을 잘 요약합니다.
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch feature/receipt-image-vision-v2

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

Provide your own instructions using the high_level_summary_instructions setting.
Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

📝 Description — Summarize the main change in 50–60 words, explaining what was done.

📓 References — List relevant issues, discussions, documentation, or related PRs.

📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.

📊 Contributor Summary — Include a Markdown table showing contributions:
| Contributor | Lines Added | Lines Removed | Files Changed |

✔️ Additional Notes — Add any extra reviewer context.
Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

Actionable comments posted: 3

🧹 Nitpick comments (7)

README.md (1)

1-1: README 내용을 조금만 보완하면 온보딩에 도움이 될 것 같습니다.

현재 저장소 목적과 사용 방법 설명이 없어도 동작에는 문제 없지만, 나중에 실행 방법(빌드/실행 커맨드)과 주요 API 엔드포인트 정도를 간단히 정리해 두면 협업·복습 시 훨씬 편할 것 같습니다.

spring-ai-app/src/main/java/org/sprain/ai/controller/VisionController.java (1)

93-97: /receipt 엔드포인트 와이어링은 자연스럽지만 예외 전략을 정리하면 좋겠습니다.

/api/vision/receipt가 ReceiptAnalysisService.processReceipt(image)를 그대로 위임해 ImageAnalysisResponseV2<ReceiptData>를 반환하는 구조는 명확합니다. 다만 현재 throws IOException, NoSuchFieldException를 그대로 노출하는데, 실제 구현에서는 NoSuchFieldException을 던지지 않고 있습니다(ReceiptAnalysisService 내부 JSON 정제 메서드도 아직 사용되지 않음).

단기적으로는 실제로 던지지 않는 checked 예외를 시그니처에서 제거하거나,

조만간 cleanJsonResponse 등과 연동해 NoSuchFieldException을 던질 계획이라면, 해당 로직을 서비스에 연결하고 컨트롤러/글로벌 예외 처리기에서 4xx/5xx 응답 전략을 명확히 하는 것을 제안드립니다.

동작 자체에는 문제가 없으나, 예외 시그니처와 실제 구현을 조기에 맞춰 두면 추후 유지보수 시 혼선을 줄일 수 있습니다.

spring-ai-app/src/main/java/org/sprain/ai/service/ReceiptAnalysisService.java (1)

49-88: cleanJsonResponse는 현재 사용되지 않으므로, 전략을 정리하는 편이 좋겠습니다.

cleanJsonResponse는 마크다운 코드 블록/백틱 제거, JSON 범위 추출 등 꽤 공들인 정제 로직인데, 현재 어느 곳에서도 호출되지 않고 있습니다. 설계 의도에 따라 다음 중 하나를 고려해 볼 수 있습니다.

Spring AI 구조화 응답만 사용할 계획이라면:

cleanJsonResponse와 관련 예외(NoSuchFieldException)는 제거하여 코드 베이스를 단순하게 유지하는 것이 좋습니다.

LLM이 반환한 "텍스트 JSON"을 직접 파싱할 계획이라면:

processReceipt에서 먼저 ImageAnalysisResponseV2<String> 형태로 원문 텍스트를 받아 cleanJsonResponse → objectMapper.readValue(..., ReceiptData.class) 순으로 실제 파싱을 수행하도록 연결하는 쪽이 명확합니다.

이 경우 NoSuchFieldException을 던지는 위치와 컨트롤러/글로벌 예외 처리에서의 HTTP 응답 매핑도 함께 정의해 두면 좋습니다.

어느 쪽이든 지금처럼 미사용 상태로 두기보다는, 실제 전략에 맞춰 제거하거나 연결하는 방향으로 정리하는 것을 추천드립니다.

spring-ai-app/src/main/java/org/sprain/ai/service/VisionServiceV2.java (2)

41-90: analyzeImage 파이프라인은 명확하지만, 예외 래핑 범위는 좁히는 것을 고려해 볼 만합니다

입력 검증 → 이미지/컨텐츠타입 추출 → UserMessage 생성 → Chat 호출 → 토큰 사용량/타겟 타입 변환 → 응답 생성까지 단계가 잘 분리되어 있습니다.

다만 analyzeImage 가 catch (Exception e) 로 모든 예외를 RuntimeException("이미지 분석 중 오류 발생", e) 하나로 래핑하고 있어,

입력 검증 실패(IllegalArgumentException),

JSON 파싱 실패,

ChatClient/네트워크 오류
를 상위 레이어에서 구분하기 어렵습니다.

가능하다면,

검증 실패/호출자 잘못 등은 그대로 IllegalArgumentException 을 전파하고,

외부 시스템/모델 오류만 별도 도메인 예외(예: ImageAnalysisException)로 감싸는 식으로 에러 타입을 분리하면 디버깅과 에러 응답 설계가 더 수월해질 것 같습니다.

275-307: cleanJsonResponse 는 {...} 오브젝트 루트만 가정하고 있어 포맷 변화에 취약할 수 있습니다

현재 구현은,

코드블록/백틱 제거 후,

첫 { 와 마지막 } 사이만 잘라 JSON 으로 간주하는 방식입니다.

이 방식은 모델이 항상 단일 객체(JSON object)만 반환한다는 전제를 깔고 있어서,

루트가 배열([...])이거나,

객체 여러 개가 붙어 나오는 경우,

응답 앞뒤에 설명 텍스트가 아닌 JSON이 더 붙는 경우
에 쉽게 실패할 수 있습니다.

모델 프롬프트로 항상 객체 한 개만 반환하도록 강하게 제한하고 있다면 그대로도 충분하지만, 포맷 변경 가능성을 대비한다면:

루트가 배열인 경우도 허용하도록 [/] 처리 분기 추가,

또는 Jackson 의 스트리밍 파서로 첫 유효 JSON 토큰을 파싱하는 방식 등을 고려해 볼 수 있습니다.
spring-ai-app/src/main/java/org/sprain/ai/service/VisionService.java (2)
198-214: promptWithResponseFormat 의 Class 비교는 simpleName 문자열 대신 Class 비교를 사용하는 편이 더 안전합니다

현재 분기 로직이:
String responseTypeClassName = responseType.getSimpleName();
if ("ChatResponse".equals(responseTypeClassName)) ...
와 같이 simpleName 문자열에 의존하고 있어,
동일 simpleName 을 가진 다른 타입이 생기거나 클래스명이 변경될 경우 오동작할 여지가 있습니다.

보다 명확하게:
-    @SuppressWarnings("unchecked")
-    private <T> T promptWithResponseFormat(Message userMessage, Class<T> responseType) {
-        String responseTypeClassName = responseType.getSimpleName();
-        if ("ChatResponse".equals(responseTypeClassName)) return (T) promptByChatResponse(userMessage);
-        else return chatClient.prompt()
-                .messages(userMessage)
-                .call()
-                .entity(responseType);
-    }
+    @SuppressWarnings("unchecked")
+    private <T> T promptWithResponseFormat(Message userMessage, Class<T> responseType) {
+        if (ChatResponse.class.equals(responseType)) {
+            return (T) promptByChatResponse(userMessage);
+        }
+        return chatClient.prompt()
+                .messages(userMessage)
+                .call()
+                .entity(responseType);
+    }
처럼 ChatResponse.class.equals(responseType) 로 비교하면 타입 리팩터링에도 더 견고합니다.

150-168: compareImages 에서 DEFAULT_CONTENT_TYPE 상수를 재사용하면 중복을 줄일 수 있습니다

compareImages 에서 MIME 타입 기본값을 "image/jpeg" 문자열로 두 번 직접 사용하고 있는데, 클래스 상단에 이미 DEFAULT_CONTENT_TYPE = "image/jpeg" 상수가 정의되어 있습니다.

가독성과 유지보수성을 위해 다음처럼 상수를 사용하는 것을 추천합니다:
-            Media media1 = new Media(
-                    MimeTypeUtils.parseMimeType(
-                            image1.getContentType() != null ? image1.getContentType() : "image/jpeg"
-                    ),
-                    new ByteArrayResource(bytes1)
-            );
+            Media media1 = new Media(
+                    MimeTypeUtils.parseMimeType(
+                            image1.getContentType() != null ? image1.getContentType() : DEFAULT_CONTENT_TYPE
+                    ),
+                    new ByteArrayResource(bytes1)
+            );
...
-            Media media2 = new Media(
-                    MimeTypeUtils.parseMimeType(
-                            image2.getContentType() != null ? image2.getContentType() : "image/jpeg"
-                    ),
-                    new ByteArrayResource(bytes2)
-            );
+            Media media2 = new Media(
+                    MimeTypeUtils.parseMimeType(
+                            image2.getContentType() != null ? image2.getContentType() : DEFAULT_CONTENT_TYPE
+                    ),
+                    new ByteArrayResource(bytes2)
+            );
나중에 기본 MIME 타입을 변경해야 할 때 상수 한 곳만 수정하면 되어 관리가 더 쉬워집니다.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4642821 and 2c71c0e.

📒 Files selected for processing (8)

README.md (1 hunks)
spring-ai-app/src/main/java/org/sprain/ai/controller/VisionController.java (5 hunks)
spring-ai-app/src/main/java/org/sprain/ai/dto/ImageAnalysis.java (1 hunks)
spring-ai-app/src/main/java/org/sprain/ai/dto/ImageAnalysisResponseV2.java (1 hunks)
spring-ai-app/src/main/java/org/sprain/ai/service/DocumentProcessingService.java (5 hunks)
spring-ai-app/src/main/java/org/sprain/ai/service/ReceiptAnalysisService.java (1 hunks)
spring-ai-app/src/main/java/org/sprain/ai/service/VisionService.java (4 hunks)
spring-ai-app/src/main/java/org/sprain/ai/service/VisionServiceV2.java (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

spring-ai-app/src/main/java/org/sprain/ai/service/ReceiptAnalysisService.java (2)

spring-ai-app/src/main/java/org/sprain/ai/service/DocumentProcessingService.java (1)

Service (13-69)

spring-ai-app/src/main/java/org/sprain/ai/service/VisionService.java (1)

Service (23-215)

spring-ai-app/src/main/java/org/sprain/ai/controller/VisionController.java (1)

spring-ai-app/src/main/java/org/sprain/ai/controller/ChatController.java (1)

RestController (15-101)

🔇 Additional comments (4)

spring-ai-app/src/main/java/org/sprain/ai/dto/ImageAnalysisResponseV2.java (1)

1-24: 제네릭 응답 DTO 설계가 단순하고 재사용하기 좋아 보입니다.

필드 구성과 of(...) 정적 팩토리 메서드로 호출부 가독성이 좋아졌고, 토큰 사용량까지 한 번에 묶어 반환하는 패턴도 일관성 있게 보입니다. 현재 형태 그대로 사용해도 충분히 괜찮아 보입니다.

spring-ai-app/src/main/java/org/sprain/ai/service/ReceiptAnalysisService.java (1)

22-47: 영수증 처리 플로우 자체는 단순·명확합니다.

processReceipt에서 프롬프트를 구성한 뒤 VisionService.analyzeImage(ImageAnalysis.of(prompt, imageFile), ReceiptData.class)로 바로 위임하는 구조는 일관되고 이해하기 쉽습니다. Spring AI의 entity(ReceiptData.class) 구조화 응답을 그대로 활용하겠다는 방향이면 현재 구현만으로도 충분히 동작 가능해 보입니다.

spring-ai-app/src/main/java/org/sprain/ai/dto/ImageAnalysis.java (1)

1-29: 이미지 입력을 DTO로 캡슐화한 설계가 깔끔합니다.

MultipartFile → (prompt, imageBytes, contentType)로 정규화하는 정적 팩토리 메서드들을 통해 VisionService·각종 분석 서비스가 동일한 DTO를 다루도록 한 점이 좋습니다. getBytes() 사용 특성상 상위 레이어(컨트롤러나 필터)에서 업로드 파일 크기 제한만 걸어두면, 현재 구현으로도 충분히 실용적인 구조라고 판단됩니다.

spring-ai-app/src/main/java/org/sprain/ai/service/DocumentProcessingService.java (1)

22-68: 제네릭 응답 구조로의 전환은 적절하며, 예외/DTO 계약만 확인해 두면 좋겠습니다

extractReceipt/extractBusinessCard/inspectProduct 모두 ImageAnalysis.of(prompt, MultipartFile) + visionService.analyzeImage(..., DTO.class) 패턴으로 잘 통일되어 있어 재사용성과 가독성이 좋아 보입니다.

다만,

이 서비스 메서드들이 throws IOException 을 노출하므로, 상위 컨트롤러/호출부에서 이를 그대로 전파할지(예: 500 매핑) 아니면 도메인 예외로 감쌀지 정책을 한 번 정리해 두면 좋겠습니다.

ReceiptData/BusinessCard/DefectReport 구조가 실제 LLM JSON 응답 스키마와 완전히 일치하는지, 파싱 실패 시 어떤 HTTP 응답을 기대하는지(예: 4xx vs 5xx)도 테스트나 계약 문서로 맞춰 두면 이후 장애 분석에 도움이 됩니다.

coderabbitai · 2025-11-20T14:15:11Z

+    public ResponseEntity<ImageAnalysisResponseV2<ChatResponse>> analyzeImage(
+            @RequestParam String prompt,
+            @RequestParam MultipartFile image) throws IOException {
+

-        ImageAnalysisResponse response = visionService.analyzeImage(prompt, image);
-        return ResponseEntity.ok(response);
+        return ResponseEntity.status(HttpStatus.OK)
+                .body(visionService.analyzeImage(ImageAnalysis.of(prompt, image), DEFAULT_CHAT_RESPONSE_CLASS));


⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

analyzeImage 제네릭 타입과 실제 analysis 값 타입이 어긋날 수 있습니다.

현재 VisionService.analyzeImage(ImageAnalysis, Class<T>)에서 referenceType이 ChatResponse.class인 경우, 내부 구현은 ChatResponse를 받아 텍스트(String)로 변환한 뒤:

return ImageAnalysisResponseV2.of( (T) analysis, // 실제로는 String contentType, imageBytes.length, tokenUsage );

처럼 analysis에 String을 넣고 있습니다. 그런데 컨트롤러 시그니처는:

ResponseEntity<ImageAnalysisResponseV2<ChatResponse>>

로 선언되어 있어, 호출 측에서 response.analysis()를 ChatResponse로 가정하고 접근하면 런타임 ClassCastException이 발생할 소지가 있습니다.

정리 방안 중 하나는 다음 둘 중에서 선택하는 것입니다.

분석 결과를 진짜 ChatResponse로 유지

VisionService.analyzeImage의 ChatResponse 분기에서 analysis 필드에 ChatResponse 자체를 넣고, 토큰 사용량만 별도 추출:
if (response instanceof ChatResponse chatResponse) { // tokenUsage 계산 return ImageAnalysisResponseV2.of( (T) response, // ChatResponse 그대로 contentType, imageBytes.length, tokenUsage ); }

이때 컨트롤러 시그니처(ImageAnalysisResponseV2<ChatResponse>)는 그대로 두고, 실제로도 ChatResponse를 받도록 맞출 수 있습니다.

컨트롤러 반환 타입을 ImageAnalysisResponseV2<String>으로 변경

VisionService에서 ChatResponse를 항상 String으로 변환해 쓰겠다는 방향이라면, 컨트롤러 메서드 시그니처와 제네릭 타입 파라미터를 <String>으로 바꾸고, 호출부에서도 그 전제를 명확히 하는 쪽이 타입 안정성 측면에서 더 안전합니다.

현재 설계 의도(프론트에서 ChatResponse 구조까지 활용할지, 텍스트만 쓸지)에 맞춰 1 또는 2 중 하나로 타입을 통일해 주시는 걸 권장합니다.

--- 🏁 Script executed: ```shell #!/bin/bash # Find and examine VisionController.java fd -e java -e kt | xargs rg -l "class VisionController" 2>/dev/null

Length of output: 74

🏁 Script executed:

#!/bin/bash # Find VisionService.java fd -e java -e kt | xargs rg -l "class VisionService" 2>/dev/null

Length of output: 139

🏁 Script executed:

#!/bin/bash # Find ImageAnalysisResponseV2.java fd -e java -e kt | xargs rg -l "class ImageAnalysisResponseV2" 2>/dev/null

Length of output: 0

🏁 Script executed:

#!/bin/bash # Search for analyzeImage method in VisionService with context rg -n -A 20 "def analyzeImage|analyzeImage\s*\(" --type java --type kt | head -100

Length of output: 26

🏁 Script executed:

#!/bin/bash # Search for ImageAnalysisResponseV2.of calls with context rg -n -B 3 -A 3 "ImageAnalysisResponseV2\.of" --type java --type kt

Length of output: 26

--- 🏁 Script executed: ```shell #!/bin/bash # Examine VisionController.java - read the entire file to find analyzeImage cat spring-ai-app/src/main/java/org/sprain/ai/controller/VisionController.java

Length of output: 3582

🏁 Script executed:

#!/bin/bash # Examine VisionService.java - read the entire file cat spring-ai-app/src/main/java/org/sprain/ai/service/VisionService.java

Length of output: 7099

🏁 Script executed:

#!/bin/bash # Search for ImageAnalysisResponseV2 more broadly rg -n "ImageAnalysisResponseV2" --type java | head -50

Length of output: 3761

🏁 Script executed:

#!/bin/bash # Search for ImageAnalysisResponseV2 class definition rg -n "class ImageAnalysisResponseV2" --type java

Length of output: 0

🏁 Script executed:

#!/bin/bash # Find all files containing ImageAnalysisResponseV2 find . -name "*.java" -exec grep -l "ImageAnalysisResponseV2" {} \;

Length of output: 460

🏁 Script executed:

#!/bin/bash # Examine ImageAnalysisResponseV2 to confirm generic type parameter usage cat spring-ai-app/src/main/java/org/sprain/ai/dto/ImageAnalysisResponseV2.java

Length of output: 754

analyzeImage 제네릭 타입과 실제 analysis 값 타입 불일치 문제가 확인되었습니다.

검증 결과, 리뷰 코멘트의 지적이 정확합니다:

VisionController.analyzeImage는 ImageAnalysisResponseV2<ChatResponse> 반환을 선언합니다.

VisionService.analyzeImage에서 ChatResponse 처리 시, 실제로는 String 값을 analysis 필드에 저장합니다:
String analysis = chatResponse.getResult().getOutput().getText(); return ImageAnalysisResponseV2.of( (T) analysis, // String을 ChatResponse로 캐스팅 contentType, imageBytes.length, tokenUsage );

같은 서비스의 analyzeChart 메서드에서 (String) response.analysis() 로 명시적 캐스팅하는 것이 이 문제를 증명합니다.

이는 Java 제네릭 계약 위반이며 클라이언트가 API를 사용할 때 런타임 ClassCastException 위험이 있습니다. 제시된 두 가지 해결 방안(① ChatResponse 그대로 유지, ② 반환 타입을 <String>으로 변경) 중 하나로 타입을 통일하시기 바랍니다.

🤖 Prompt for AI Agents

spring-ai-app/src/main/java/org/sprain/ai/controller/VisionController.java around lines 35-41: the controller declares ResponseEntity<ImageAnalysisResponseV2<ChatResponse>> but the service actually places a String into the analysis field, causing unsafe casts and possible ClassCastException; fix by unifying the generic types — either (A) change the controller method signature and any default class constant to return ImageAnalysisResponseV2<String> (and pass String.class to visionService.analyzeImage), or (B) change VisionService.analyzeImage to return a real ChatResponse object (wrap the String into a ChatResponse) so the declared ChatResponse generic is accurate; pick one approach and update method signature, constants, and any callers accordingly to keep compile-time type safety.

coderabbitai · 2025-11-20T14:15:11Z

+    @SuppressWarnings("unchecked")
+    public <T> ImageAnalysisResponseV2<T> analyzeImage(ImageAnalysis imageAnalysis, Class<T> referenceType) {
+        String prompt = imageAnalysis.prompt();

-            // 2. MIME 타입 결정
-            String contentType = imageFile.getContentType();
-            if (contentType == null) {
-                contentType = "image/jpeg"; // 기본값
-            }
+        // 1. 이미지 바이트 배열 가져오기
+        byte[] imageBytes = imageAnalysis.imageBytes();

-            // 3. Media 객체 생성
-            Media media = new Media(
+        // 2. MIME 타입 결정
+        String contentType = imageAnalysis.contentType();
+        if (contentType == null) {
+            contentType = DEFAULT_CONTENT_TYPE;
+        }
+
+        // 3. Media 객체 생성
+        Media media = new Media(
                MimeTypeUtils.parseMimeType(contentType),
                new ByteArrayResource(imageBytes)
-            );
+        );

-            // 4. UserMessage 생성 (정적 팩토리 메서드 사용)
-            UserMessage userMessage = UserMessage.builder()
+        // 4. UserMessage 생성 (정적 팩토리 메서드 사용)
+        UserMessage userMessage = UserMessage.builder()
                .media(List.of(media))
                .text(prompt)
                .build();

-            // 5. Claude Vision API 호출
-            ChatResponse response = chatClient.prompt()
-                .messages(userMessage)
-                .call()
-                .chatResponse();
+        // 5. Claude Vision API 호출
+        T response = promptWithResponseFormat(userMessage, referenceType);
+        TokenUsage tokenUsage = null;

-            // 6. 응답 추출
-            String analysis = response.getResult().getOutput().getText();
+        // 6. 응답 타입에 따라 처리
+        if (response instanceof ChatResponse chatResponse) {
+            // ChatResponse 타입인 경우
+            String analysis = chatResponse.getResult().getOutput().getText();

-            // 7. 토큰 사용량 추출
-            TokenUsage tokenUsage = null;
-            var metadata = response.getMetadata();
+            // 토큰 사용량 추출
+            var metadata = chatResponse.getMetadata();
            if (metadata != null && metadata.getUsage() != null) {
                var usage = metadata.getUsage();
                tokenUsage = new TokenUsage(
-                    usage.getPromptTokens(),
-                    usage.getCompletionTokens(),
-                    usage.getTotalTokens()
+                        usage.getPromptTokens(),
+                        usage.getCompletionTokens(),
+                        usage.getTotalTokens()
                );
            }

-            return ImageAnalysisResponse.of(
-                analysis,
-                contentType,
-                imageBytes.length,
-                tokenUsage
+            return ImageAnalysisResponseV2.of(
+                    (T) analysis,
+                    contentType,
+                    imageBytes.length,
+                    tokenUsage
            );

-        } catch (IOException e) {
-            log.error("이미지 처리 실패: {}", e.getMessage());
-            throw new RuntimeException("이미지 처리 중 오류 발생", e);
+        } else {
+            // String 타입인 경우
+            return ImageAnalysisResponseV2.of(
+                    response,
+                    contentType,
+                    imageBytes.length,
+                    tokenUsage
+            );
        }
    }


⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

ChatResponse 분기에서 제네릭 타입과 실제 payload 타입이 어긋나 타입 안전성이 깨집니다

현재 analyzeImage 는 referenceType == ChatResponse.class 인 경우에도:

promptWithResponseFormat 에서 ChatResponse 를 받아온 뒤,

String analysis = chatResponse.getResult().getOutput().getText(); 로 텍스트를 뽑고,

이 analysis(String)를 (T) analysis 로 캐스팅해 ImageAnalysisResponseV2<T> 에 넣습니다.

즉 호출부에서 ImageAnalysisResponseV2<ChatResponse> response = analyzeImage(..., DEFAULT_CHAT_RESPONSE_CLASS); 와 같이 사용하면,

제네릭 타입 인자는 ChatResponse 이지만,

내부 analysis() 실제 런타임 타입은 String 이라,

이후 ChatResponse 로 캐스팅하거나 메서드를 호출하는 시점에 ClassCastException 이 발생할 수 있습니다.

analyzeChart 도 DEFAULT_CHAT_RESPONSE_CLASS 를 넘겨 놓고, ImageAnalysisResponseV2 raw 타입 + (String) response.analysis() 로 캐스팅하는 등 현재 설계가 ChatResponse/문자열 두 개념을 뒤섞고 있습니다.

보다 타입 안전하게 하려면 두 가지 중 하나로 정리하는 것을 권장합니다:

referenceType == ChatResponse.class 인 경우 실제로 ChatResponse 를 그대로 반환하도록 변경

- T response = promptWithResponseFormat(userMessage, referenceType); - TokenUsage tokenUsage = null; - - // 6. 응답 타입에 따라 처리 - if (response instanceof ChatResponse chatResponse) { - // ChatResponse 타입인 경우 - String analysis = chatResponse.getResult().getOutput().getText(); - - // 토큰 사용량 추출 - var metadata = chatResponse.getMetadata(); - if (metadata != null && metadata.getUsage() != null) { - var usage = metadata.getUsage(); - tokenUsage = new TokenUsage( - usage.getPromptTokens(), - usage.getCompletionTokens(), - usage.getTotalTokens() - ); - } - - return ImageAnalysisResponseV2.of( - (T) analysis, - contentType, - imageBytes.length, - tokenUsage - ); - - } else { - // String 타입인 경우 - return ImageAnalysisResponseV2.of( - response, - contentType, - imageBytes.length, - tokenUsage - ); - } + T response = promptWithResponseFormat(userMessage, referenceType); + TokenUsage tokenUsage = null; + + // 6. ChatResponse 인 경우에만 토큰 사용량 추출 + if (response instanceof ChatResponse chatResponse) { + var metadata = chatResponse.getMetadata(); + if (metadata != null && metadata.getUsage() != null) { + var usage = metadata.getUsage(); + tokenUsage = new TokenUsage( + usage.getPromptTokens(), + usage.getCompletionTokens(), + usage.getTotalTokens() + ); + } + } + + // referenceType 과 일치하는 실제 타입 그대로 래핑 + return ImageAnalysisResponseV2.of( + response, + contentType, + imageBytes.length, + tokenUsage + );

그리고 analyzeChart 는 텍스트만 필요하므로 String.class 를 사용하도록 정리할 수 있습니다:

- ImageAnalysisResponseV2 response = analyzeImage(ImageAnalysis.of(prompt, imageFile), DEFAULT_CHAT_RESPONSE_CLASS); - return (String) response.analysis(); + ImageAnalysisResponseV2<String> response = + analyzeImage(ImageAnalysis.of(prompt, imageFile), String.class); + return response.analysis();

이렇게 하면:

ImageAnalysisResponseV2<ChatResponse> 인 경우 analysis() 가 진짜 ChatResponse 가 되고,

문자열 응답이 필요한 곳은 일관되게 String.class 를 사용해 제네릭 타입과 payload 가 맞아 떨어집니다.

혹은 ChatResponse 를 전혀 노출하지 않고 “항상 String” 을 반환하는 API 로 단순화

이미 VisionServiceV2 가 ChatResponse 기반 파이프라인을 명확하게 제공하고 있으므로, 이 서비스는 단순히 String/DTO 를 반환하는 쪽으로 한정하는 것도 고려 여지가 있습니다. 다만 이 경우 기존 호출부 영향 범위를 따로 검토해야 합니다.

현재 PR 에서 VisionController/다른 서비스들이 ImageAnalysisResponseV2<ChatResponse> 로 사용하고 있다면, 위 1번 방식대로 정리하고 호출부 제네릭 타입/캐스팅을 함께 맞추는 것이 안전해 보입니다.

Also applies to: 133-145

필요한 정보를 수집하기 위해 코드베이스를 검사하겠습니다.

🏁 Script executed:

#!/bin/bash # VisionService.java 전체 파일 내용 확인 find . -type f -name "VisionService.java" | head -5

Length of output: 70

🏁 Script executed:

#!/bin/bash # VisionService 클래스 구조와 메서드 목록 ast-grep --pattern 'class VisionService { $$$ }'

Length of output: 0

🏁 Script executed:

#!/bin/bash # analyzeImage, analyzeChart, promptWithResponseFormat 메서드 구현 확인 rg -nA 30 'public.*analyzeImage\s*\(' --type java

Length of output: 10296

🏁 Script executed:

#!/bin/bash # analyzeChart 메서드 확인 rg -nA 20 'public.*analyzeChart\s*\(' --type java

Length of output: 6798

🏁 Script executed:

#!/bin/bash # promptWithResponseFormat 메서드 확인 rg -nA 20 'private.*promptWithResponseFormat\s*\(' --type java

Length of output: 1068

🏁 Script executed:

#!/bin/bash # ImageAnalysisResponseV2 클래스 구조 find . -type f -name "ImageAnalysisResponseV2.java" -exec cat {} \;

Length of output: 754

🏁 Script executed:

#!/bin/bash # VisionController에서 VisionService 사용 패턴 확인 rg -nA 5 -B 5 'analyzeImage|analyzeChart' --type java | grep -E '(VisionController|ImageAnalysisResponseV2|ChatResponse)' | head -20

Length of output: 2754

🏁 Script executed:

#!/bin/bash # DEFAULT_CHAT_RESPONSE_CLASS 정의 확인 rg -n 'DEFAULT_CHAT_RESPONSE_CLASS' --type java

Length of output: 709

🏁 Script executed:

#!/bin/bash # compareImages 메서드 구현 확인 rg -nA 25 'public.*compareImages\s*\(' --type java

Length of output: 7632

🏁 Script executed:

#!/bin/bash # 전체 VisionService 파일 내용 확인 fd VisionService.java -x cat {}

Length of output: 7099

🏁 Script executed:

#!/bin/bash # 호출부에서 ImageAnalysisResponseV2<ChatResponse> 사용 여부 확인 rg 'ImageAnalysisResponseV2<ChatResponse>' --type java

Length of output: 153

🏁 Script executed:

#!/bin/bash # ChatResponse instanceof 체크 후 String 캐스팅 패턴 rg -nA 5 'instanceof ChatResponse' --type java

Length of output: 686

🏁 Script executed:

#!/bin/bash # SimpleClassName 문자열 비교 패턴 (promptWithResponseFormat에서) rg -n 'getSimpleName|ChatResponse.*string' --type java

Length of output: 432

🏁 Script executed:

#!/bin/bash # VisionServiceV2와의 비교를 위해 compareImages 호출 패턴 rg -nB 5 -A 15 'compareImages' --type java | head -50

Length of output: 5219

🏁 Script executed:

#!/bin/bash # String.class와 ChatResponse.class 사용 패턴 비교 rg -n '\.(class|String\.class|ChatResponse\.class)' --type java | grep -E '(analyzeImage|analyzeChart|promptWithResponseFormat)' | head -20

Length of output: 934

🏁 Script executed:

#!/bin/bash # analyzeImage 메서드 서명 확인 rg -n 'analyzeImage\s*$' --type java | head -10

Length of output: 1670

🏁 Script executed:

#!/bin/bash # 전체 VisionService 메서드 목록 ast-grep --pattern 'public $_ $_($$$) { $$$ }'

Length of output: 66822

🏁 Script executed:

#!/bin/bash # TokenUsage 클래스 정보 확인 find . -type f -name "*TokenUsage*" -o -name "*Usage*" | grep -i token

Length of output: 63

🏁 Script executed:

#!/bin/bash # ImageAnalysis 클래스 확인 fd ImageAnalysis.java -x cat {}

Length of output: 860

🏁 Script executed:

#!/bin/bash # DEFAULT_CONTENT_TYPE 상수 확인 rg -n 'DEFAULT_CONTENT_TYPE|DEFAULT_CHAT_RESPONSE_CLASS' --type java

Length of output: 1520

🏁 Script executed:

#!/bin/bash # 캐스팅 패턴 상세 검사 rg -nA 3 -B 3 '\(T$\s*' --type java | grep -A 5 -B 5 'analysis\|response'

Length of output: 1716

🏁 Script executed:

#!/bin/bash # 모든 VisionService 관련 파일 목록 find . -type f -name "*Vision*" | grep -E '\.(java|kt)$'

Length of output: 220

🏁 Script executed:

#!/bin/bash # 전체 파일 경로 확인 pwd && ls -la | head -20

Length of output: 1213

🏁 Script executed:

#!/bin/bash # VisionService.java 위치 파악 find . -path '*/spring-ai-app/src/main/java/org/sprain/ai/service/VisionService.java'

Length of output: 70

🏁 Script executed:

#!/bin/bash # 해당 경로에서 VisionService 내용 확인 cat spring-ai-app/src/main/java/org/sprain/ai/service/VisionService.java 2>/dev/null || cat ./src/main/java/org/sprain/ai/service/VisionService.java 2>/dev/null || find . -name VisionService.java -type f -exec cat {} \;

Length of output: 7099

🏁 Script executed:

#!/bin/bash # 타입 안전성 관련 주요 클래스들 확인 find . -type f $ -name "ImageAnalysisResponseV2.java" -o -name "ImageAnalysis.java" -o -name "VisionService.java" $ -exec echo "=== {} ===" \; -exec cat {} \;

Length of output: 8954

🏁 Script executed:

#!/bin/bash # ImageAnalysisResponseV2의 of 메서드와 analysis() 메서드 확인 rg -nA 10 'public.*analysis|public static.*of$' spring-ai-app/src --type java 2>/dev/null | head -50

Length of output: 5320

🏁 Script executed:

#!/bin/bash # analyzeChart 라인 133-145 확인 find . -name VisionService.java -exec sed -n '133,145p' {} \;

Length of output: 475

🏁 Script executed:

#!/bin/bash # 재귀 검색: VisionService에서 raw 타입 ImageAnalysisResponseV2 사용 rg 'ImageAnalysisResponseV2\s*[a-zA-Z_]' --type java

Length of output: 191

🏁 Script executed:

#!/bin/bash # ChatResponse 메타데이터 구조 확인 rg -nA 5 'getMetadata|getUsage' --type java | head -40

Length of output: 3801

🏁 Script executed:

#!/bin/bash # 호출부에서 분석 응답 사용 방식 확인 rg -nB 3 -A 3 '\.analysis\($' --type java | head -50

Length of output: 4023

🏁 Script executed:

#!/bin/bash # 전체 구조를 파악하기 위해 주요 파일들 나열 find . -type f -name "*.java" | grep -i vision | head -20

Length of output: 220

🏁 Script executed:

#!/bin/bash # Spring AI 관련 ChatResponse import 확인 rg -n 'import.*ChatResponse' --type java

Length of output: 864

🏁 Script executed:

#!/bin/bash # UserMessage 빌더 패턴 확인 rg -nA 8 'UserMessage\.builder' --type java

Length of output: 3820

🏁 Script executed:

#!/bin/bash # 타입 안전 문제 있을 수 있는 캐스팅 패턴 rg -n '$T$.*analysis|$String$.*response\.analysis' --type java

Length of output: 223

🏁 Script executed:

#!/bin/bash # compareImages에서 "image/jpeg" 하드코딩 확인 rg -n 'image/jpeg|JPEG' --type java

Length of output: 631

🏁 Script executed:

#!/bin/bash # 전체 줄 수 확인 및 라인 범위 검증 find . -name VisionService.java -exec wc -l {} \; -exec sed -n '38,99p' {} \; -exec echo "---" \; -exec sed -n '133,145p' {} \;

Length of output: 2620

🏁 Script executed:

#!/bin/bash # 마지막으로 VisionService.java 경로 재확인 find . -name VisionService.java -type f

Length of output: 70

🏁 Script executed:

#!/bin/bash # 경로가 있으면 직접 내용 확인 paths=$(find . -name VisionService.java -type f) if [ -n "$paths" ]; then for path in $paths; do echo "=== File: $path ===" wc -l "$path" echo "--- Lines 38-99 ---" sed -n '38,99p' "$path" echo "--- Lines 133-145 ---" sed -n '133,145p' "$path" done else echo "VisionService.java not found" find . -name "*.java" -path "*/service/*" -type f | head -20 fi

Length of output: 2743

🏁 Script executed:

#!/bin/bash # 구조 파악: spring-ai-app 디렉토리 구조 find spring-ai-app -type d -name "service" 2>/dev/null || find . -type d -name "service" 2>/dev/null

Length of output: 49

🏁 Script executed:

#!/bin/bash # 모든 java 파일에서 analyzeImage 검색 rg 'def analyzeImage|public.*analyzeImage' --type java -A 25

Length of output: 8363

🏁 Script executed:

#!/bin/bash # 최종: VisionService 발견 및 전체 내용 출력 find . -type f -name "VisionService.java" 2>/dev/null | while read f; do echo "Found: $f"; cat "$f"; done

Length of output: 7177

🏁 Script executed:

#!/bin/bash # 대안: 전체 디렉토리 구조 확인 ls -la && echo "---" && find . -maxdepth 3 -type f -name "*Vision*" 2>/dev/null

Length of output: 1198

ChatResponse 분기에서 제네릭 타입과 실제 payload 타입 불일치로 인한 타입 안전성 문제 확인

검증 결과 리뷰 코멘트의 지적이 정확합니다. 코드베이스에서 다음 두 가지 critical issue를 확인했습니다:

analyzeImage 메서드 (라인 84): referenceType == ChatResponse.class일 때 String analysis를 (T) analysis로 캐스팅하여 반환합니다. 호출부(VisionController)에서 ImageAnalysisResponseV2<ChatResponse>를 기대하지만, 실제 내부 타입은 String이 되어 런타임에 ClassCastException이 발생할 수 있습니다.

analyzeChart 메서드 (라인 143-144): raw 타입 ImageAnalysisResponseV2 사용하면서 DEFAULT_CHAT_RESPONSE_CLASS를 넘기고, (String) response.analysis()로 강제 캐스팅합니다.

제안된 수정 방식이 적절합니다. 실제 타입과 제네릭 파라미터를 일치시키려면:

analyzeImage에서 ChatResponse 분기 시 String을 추출한 후 실제로는 String 타입으로 반환하고

analyzeChart는 String.class를 명시적으로 사용하여 타입 안전성을 보장해야 합니다

추가로 promptWithResponseFormat의 getSimpleName() 문자열 비교(라인 208)도 Class.equals() 비교로 개선하면 더욱 견고해집니다.

coderabbitai · 2025-11-20T14:15:11Z

+            String rawText = chatResponse.getResult().getOutput().getText();
+            log.debug("Vision API 원본 응답: {}", rawText);
+


⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

LLM 응답 전문 로깅은 영수증·명함 등 PII 유출 리스크가 있어 보입니다

rawText, 정제 전/후 응답, JSON 파싱 실패 시 전체 텍스트를 DEBUG 로 남기고 있는데, 이 서비스가 영수증/명함/제품 이미지 등을 다루는 만큼,

고객 이름, 연락처, 주소, 결제 금액 등 민감한 정보가 그대로 로그에 남을 수 있고,

운영 환경에서 DEBUG 레벨이 활성화되면 장기 보관/전송되면서 개인정보/보안 리스크가 될 수 있습니다.

운영 환경 기준으로는,

전문이 아닌 일부만 마스킹/절단해 로깅하거나(예: 앞 N자 + 길이),

에러 상황에서도 식별 불가능한 식별자나 요약 정보만 남기고 원문은 저장하지 않는 쪽을 권장합니다.

Also applies to: 267-268, 280-305

--- 🏁 Script executed: ```shell #!/bin/bash # Retrieve the VisionServiceV2.java file to examine logging patterns fd -t f "VisionServiceV2.java" --exec cat {} \;

Length of output: 9807

🏁 Script executed:

#!/bin/bash # Search for logging patterns and DEBUG statements in the codebase rg -n "log\.(debug|info|warn|error)" spring-ai-app/src/main/java/org/sprain/ai/service/ -C 3 --type java

Length of output: 10931

🏁 Script executed:

#!/bin/bash # Search for any PII masking/redaction utilities rg -n "(mask|redact|hide|sanitize|PII)" spring-ai-app/src --type java

Length of output: 0

🏁 Script executed:

#!/bin/bash # Check for logging configuration files fd -t f "(logback|log4j|logging)" --extension xml --extension properties --extension yml --extension yaml

Length of output: 0

민감 정보 로깅 제거 및 마스킹 구현 필수

LLM 응답 전문을 DEBUG 및 ERROR 레벨에서 로깅하고 있어 PII 유출 리스크가 실제로 존재합니다. 이 서비스가 영수증/명함 등 민감 정보를 포함한 이미지를 처리하므로, 다음 위치의 로그에서 고객 이름, 연락처, 주소, 결제 금액 등이 노출될 수 있습니다:

Line 66: 원본 응답 전문 로깅

Line 267: JSON 파싱 실패 시 전체 텍스트

Line 280, 304: 정제 전/후 응답 전문

Line 297: ERROR 로그에 실패한 응답 전문

운영 환경 기준으로 다음 중 하나를 적용하시기 바랍니다:

응답 길이만 로깅 (예: 응답 길이: {}bytes)

식별 불가능한 요약 정보만 기록 (예: JSON 키 목록, 추출 성공 여부)

에러 상황에서는 원문 제외 후 에러 타입과 식별자만 기록

🤖 Prompt for AI Agents

spring-ai-app/src/main/java/org/sprain/ai/service/VisionServiceV2.java lines ~65-67, 267, 280, 297, 304: The code currently logs full LLM responses (raw and pre/post-clean) which may contain PII; replace these full-text logs with redacted/summary logs. Specifically, remove or change debug/error calls that print rawText or full responses to instead log only safe metadata (e.g., response length in bytes, a list of top-level JSON keys, and boolean flags like "parseSuccess" or "extractionSuccess"), and on errors log only the error type/message and a non-sensitive identifier; implement a reusable redact utility that strips/obfuscates common PII patterns (names, phone numbers, addresses, payment amounts) and call it before any remaining debug logs, and ensure full-text logging is gated behind an explicit non-production flag so production never emits unredacted responses.

jinho-yoo-jack · 2026-01-21T06:52:03Z

/gemini review

gemini-code-assist

Code Review

이 PR은 Vision 서비스를 리팩토링하여 일관된 응답 구조를 도입하고 새로운 영수증 처리 기능을 추가하는 중요한 변경 사항을 포함하고 있습니다. ImageAnalysisResponseV2 DTO를 도입하여 API 응답을 표준화한 점은 매우 좋은 개선입니다.

하지만 리팩토링된 VisionService의 analyzeImage 메서드에 심각한 버그가 있습니다. 특정 조건에서 ClassCastException이 발생할 수 있으며, 구조화된 응답을 받을 때 토큰 사용량 메타데이터가 손실되는 설계 결함도 존재합니다.

PR에 함께 추가된 VisionServiceV2.java 파일은 이러한 문제들을 해결한 더 나은 구현으로 보입니다. 현재 이 서비스는 사용되고 있지 않지만, 기존 VisionService의 불안정한 로직을 VisionServiceV2의 견고한 로직으로 대체하여 사용하는 것을 강력히 권장합니다.

그 외에도 컨트롤러의 예외 처리 방식과 일부 서비스의 미사용 코드 등 개선이 필요한 부분이 있습니다. 아래의 개별 코멘트에서 자세한 내용을 확인해주세요.

gemini-code-assist · 2026-01-21T06:55:33Z

+    public static ImageAnalysis of(ImageAnalysisRequest request) throws IOException {
+        return ImageAnalysis.of(request.prompt(), request.image());
+    }


ImageAnalysisRequest 타입이 이 파일에 정의되어 있거나 import되지 않아 컴파일 오류가 발생합니다. 이 클래스의 정의를 추가하거나, 사용되지 않는 팩토리 메서드라면 삭제해주세요.

gemini-code-assist · 2026-01-21T06:55:33Z

+        if (response instanceof ChatResponse chatResponse) {
+            // ChatResponse 타입인 경우
+            String analysis = chatResponse.getResult().getOutput().getText();

-            // 7. 토큰 사용량 추출
-            TokenUsage tokenUsage = null;
-            var metadata = response.getMetadata();
+            // 토큰 사용량 추출
+            var metadata = chatResponse.getMetadata();
            if (metadata != null && metadata.getUsage() != null) {
                var usage = metadata.getUsage();
                tokenUsage = new TokenUsage(
-                    usage.getPromptTokens(),
-                    usage.getCompletionTokens(),
-                    usage.getTotalTokens()
+                        usage.getPromptTokens(),
+                        usage.getCompletionTokens(),
+                        usage.getTotalTokens()
                );
            }

-            return ImageAnalysisResponse.of(
-                analysis,
-                contentType,
-                imageBytes.length,
-                tokenUsage
+            return ImageAnalysisResponseV2.of(
+                    (T) analysis,
+                    contentType,
+                    imageBytes.length,
+                    tokenUsage
            );


여기에 심각한 버그가 있습니다. 이 메서드가 ChatResponse.class를 referenceType으로 하여 호출되면, 제네릭 타입 T는 ChatResponse가 됩니다. 하지만 84번째 줄에서 String 타입인 analysis 변수를 T로 캐스팅하고 있어, 런타임에 String을 ChatResponse로 변환할 수 없다는 ClassCastException이 발생합니다.

gemini-code-assist · 2026-01-21T06:55:33Z

    }
+
+    @PostMapping(value = "/receipt", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
+    public ResponseEntity<ImageAnalysisResponseV2<ReceiptData>> processReceipt(@RequestParam("image") MultipartFile image) throws IOException, NoSuchFieldException {


컨트롤러 메서드 시그니처에 NoSuchFieldException과 같은 특정 구현 예외를 노출하는 것은 좋은 방법이 아닙니다. 이 예외는 내부적으로 처리하고, @ControllerAdvice 등을 사용하여 400 Bad Request 또는 500 Internal Server Error와 같은 적절한 HTTP 상태 코드로 매핑하는 것이 좋습니다. API 계약이 내부 서비스 구현에 종속되지 않도록 해야 합니다.

gemini-code-assist · 2026-01-21T06:55:33Z

+        } else {
+            // String 타입인 경우
+            return ImageAnalysisResponseV2.of(
+                    response,
+                    contentType,
+                    imageBytes.length,
+                    tokenUsage
+            );
        }


이 else 블록에서는 응답이 entity로 직접 변환될 때(ReceiptData 등) tokenUsage가 항상 null이 됩니다. ChatClient에서 .entity(responseType)를 호출하면 토큰 사용량 정보가 포함된 ChatResponse 메타데이터에 접근할 수 없기 때문입니다. 이는 중요한 정보 손실로 이어집니다. 함께 추가된 VisionServiceV2.java 파일의 구현은 ChatResponse를 먼저 받은 후 내용을 파싱함으로써 이 문제를 올바르게 해결하고 있습니다.

gemini-code-assist · 2026-01-21T06:55:33Z

    public ResponseEntity<Map<String, String>> compareImages(
-        @RequestParam("image1") MultipartFile image1,
-        @RequestParam("image2") MultipartFile image2) {
+            @RequestParam("image1") MultipartFile image1,
+            @RequestParam("image2") MultipartFile image2) {


이 compareImages 메서드는 컨트롤러 내 다른 이미지 처리 메서드(analyzeImage, extractText 등)와 달리 throws IOException을 선언하지 않습니다. 이는 일관성 없는 오류 처리 방식입니다. visionService.compareImages가 IOException을 RuntimeException으로 래핑하고 있는데, 일관성을 위해 visionService.compareImages가 IOException을 직접 던지도록 수정하고 여기서도 선언하는 것을 고려해보세요.

gemini-code-assist · 2026-01-21T06:55:33Z

+@Slf4j
+public class ReceiptAnalysisService {
+    private final VisionService visionService;
+    private final ObjectMapper objectMapper;


주입된 ObjectMapper 필드가 클래스 내에서 사용되지 않고 있습니다. 혼동을 피하기 위해 이 미사용 코드를 제거하는 것이 좋습니다.

gemini-code-assist · 2026-01-21T06:55:33Z

+    private final ObjectMapper objectMapper;
+
+
+    public ImageAnalysisResponseV2<ReceiptData> processReceipt(MultipartFile imageFile) throws IOException, NoSuchFieldException {


이 메서드는 시그니처에 throws NoSuchFieldException을 선언하고 있지만, 실제 메서드 본문에서는 이 예외가 발생하지 않습니다. (이 예외를 던지는 cleanJsonResponse가 호출되지 않음). 이는 오해의 소지가 있으므로 throws 절에서 NoSuchFieldException을 제거해야 합니다.

gemini-code-assist · 2026-01-21T06:55:33Z

+    private String cleanJsonResponse(String response) throws NoSuchFieldException {
+        if (response == null || response.isEmpty()) {
+            throw new NoSuchFieldException("Vision API 응답이 비어있습니다");
+        }
+
+        log.debug("정제 전 응답: {}", response);
+
+        // 1. 마크다운 코드 블록 제거
+        response = response.replaceAll("```json\\s*", "");
+        response = response.replaceAll("```\\s*", "");
+
+        // 2. 모든 백틱 제거
+        response = response.replace("`", "");
+
+        // 3. 앞뒤 공백 제거
+        response = response.trim();
+
+        // 4. JSON 시작 위치 찾기
+        int jsonStart = response.indexOf("{");
+        int jsonEnd = response.lastIndexOf("}");
+
+        if (jsonStart == -1 || jsonEnd == -1 || jsonStart >= jsonEnd) {
+            log.error("유효한 JSON을 찾을 수 없습니다. 응답: {}", response);
+            throw new NoSuchFieldException("Vision API 응답에서 JSON을 찾을 수 없습니다");
+        }
+
+        // 5. JSON 부분만 추출
+        response = response.substring(jsonStart, jsonEnd + 1);
+
+        log.debug("정제 후 응답: {}", response);
+
+        return response;
+    }


cleanJsonResponse 메서드가 이 서비스 내에서 호출되지 않는 미사용 코드(dead code)입니다. 필요한 로직이라면 사용해야 하고, 그렇지 않다면 코드베이스를 깔끔하게 유지하기 위해 제거해야 합니다. 유사하고 실제로 사용되는 구현이 VisionServiceV2에 존재합니다.

gemini-code-assist · 2026-01-21T06:55:33Z

+    @SuppressWarnings("unchecked")
+    private <T> T promptWithResponseFormat(Message userMessage, Class<T> responseType) {
+        String responseTypeClassName = responseType.getSimpleName();
+        if ("ChatResponse".equals(responseTypeClassName)) return (T) promptByChatResponse(userMessage);


클래스 타입을 단순 이름 문자열("ChatResponse")로 비교하는 것은 불안정합니다. 클래스 이름이 변경되거나 다른 패키지에 동일한 이름의 클래스가 생기면 코드가 깨질 수 있습니다. 직접 클래스를 비교하는 것이 더 안전하고 명확합니다.

Suggested change

if ("ChatResponse".equals(responseTypeClassName)) return (T) promptByChatResponse(userMessage);

if (responseType == ChatResponse.class) return (T) promptByChatResponse(userMessage);

jinho-yoo-jack added 2 commits November 20, 2025 09:54

ADD: New Type

c584610

ADD: New ReceiptAnalysisService

2c71c0e

coderabbitai Bot reviewed Nov 20, 2025

View reviewed changes

gemini-code-assist Bot reviewed Jan 21, 2026

View reviewed changes

		String rawText = chatResponse.getResult().getOutput().getText();
		log.debug("Vision API 원본 응답: {}", rawText);

		private final ObjectMapper objectMapper;


		public ImageAnalysisResponseV2<ReceiptData> processReceipt(MultipartFile imageFile) throws IOException, NoSuchFieldException {

	if ("ChatResponse".equals(responseTypeClassName)) return (T) promptByChatResponse(userMessage);
	if (responseType == ChatResponse.class) return (T) promptByChatResponse(userMessage);

Conversation

jinho-yoo-jack commented Nov 20, 2025 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

릴리스 노트

Uh oh!

coderabbitai Bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

요약

Walkthrough

Changes

Sequence Diagrams

Estimated code review effort

Poem

Pre-merge checks and finishing touches

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

jinho-yoo-jack commented Jan 21, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

jinho-yoo-jack commented Nov 20, 2025 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Nov 20, 2025 •

edited

Loading