📌 Gemini 2.5 flash-lite model with structured output, Thinking mode off

• 다른 ai모델들에 비해 gemini 2.5 flash-lite를 쓰고 Reasoning 기능을 끄기로 한 이유

  

  • 성능과 속도에 비해 압도적으로 저렴한 가격.

    • 위의 그래프로 봐서 알 수 있듯이, gemini 모델은 기본적으로 정말 빠르고 똑똑하면서 저렴합니다. 따라서 다른 모델에 비해 이 모델을 선택하지 않을 이유가 없었습니다.
    • 추론기능을 끄기로 한 이유(Thinking mode off) Gemini 모델들은 모두 기본적으로 추론 모델입니다. 단순히 답변을 생성하는 데에서 멈추지 않고, 여러 생각의 층을 거쳐 답변을 정제한 후 돌려줍니다. ****저희 서비스의 경우 ai를 이용해 사용자의 직업과 페르소나와 같은 기본적인 정보와, 기존에 작성했던 목표들을 바탕으로 새로운 목표를 추천해주는데, 이는 고도의 추론능력을 필요로 하지는 않는다고 생각했습니다. 또, 실제로 Reasoning 기능을 켜고 테스트했을 때와 끄고 했을 때, 소모된 토큰의 수는 큰 차이를 보였지만, 응답의 퀄리티는 큰 차이를 보이지 않았습니다.

  • Structured output 기능

    • 자유로운 줄글 형식의 답변을 출력하는 다른 모델들과는 다르게, gemini는 structured output이라는 기능을 지원합니다.
    • 저희 서비스 특성상, 항상 정형화된 형태로 응답을 받아야했습니다. 만다라트의 중심목표를 제외한 주변 목표 8칸에 넣을 응답을 프론트에게 json형태로 넘겨야했기 때문에, structured output 기능을 이용해 항상 정형화된 json형태로 ai 응답을 받기로 했습니다.

  • Spring ai를 활용하지 않은 이유1(성능 지표 문제)

    • Spring ai의 경우 gemini-2.0‑flash, gemini-2.0‑flash‑lite, gemini‑2.5‑flash 초기 모델(gemini-2.5-pro-preview-03-25), gemini‑2.5‑pro(gemini-2.5-flash-preview-04-17) 초기 모델만 활용할 수 있습니다.
    • 성능과 속도, 비용 측면에서 최신 gemini 2.5 모델들이 압도적인 지표를 보였고, 이런 모델들을 활용하기 위해 spring ai를 쓰는 대신 직접 gemini api를 연결했습니다.

  • Spring ai를 활용하지 않은 이유2 (Json schema 준수)

    • google ai studio에 들어가면, 원하는 json 형태로 고정해서 응답을 받는 structured output 기능이 있습니다.
    • 앞서 설명했듯 저희 서비스는 structured output을 필수적으로 써야했습니다.
    • 기존 spring ai에서는 json 구조의 정형화된 응답을 받기 위해서는 프롬프트에서 구구절절 설명하는 식으로 해야했는데, 이렇게 되면 일관되고 정형화된 답변을 받기 어렵다는 큰 단점이 있습니다. (spring ai에서 gemini가 아닌 다른 모델(open ai)을 쓰면 json structured output 기능을 활용할 수 있기는 합니다.)
    • 따라서 spring ai를 활용하지 않고 gemini api를 직접 연결하는 방식을 선택할 수밖에 없었습니다.

  • Response Schema의 변경 가능성 고려(확장성)

    

    위 구조에서 text 부분에 prompt가 들어가고,

    responseSchema 부분에 저희가 원하는 structured output이 들어갑니다.

    추후 확장성을 고려했을 때 이 responseSchema를 String 값으로 따로 관리해주는 것이 합리적인 선택이었습니다. responseSchema를 Dto로 처리했을 때, 추후 이 부분에 변경이 있을 때 정말 복잡한 수정사항이 생길 수 있지만, 이 부분을 string으로 관리했을 때는 정말 간단하게 수정이 됩니다.

    따라서 이 responseSchema를 string 값으로 env파일에 넣어놓고, 꺼내와서 json으로 변형한 후 요청을 보내는 방식으로 기능을 구현했습니다.

📌 만다라트 이력 관리

위의 수정하기 뷰에서는 만다라트 생성 완료 후, 하나의 상위 목표에 대해 해당 상위 목표와 하위 목표를 한번에 수정할 수 있습니다.

만다라트를 수정하면, 다음 두 가지 상황을 고려해야 합니다.

1. (왼쪽 사진) 나의 할 일 뷰에서 수정 전 날짜를 클릭한 경우, 해당 날짜에 맞는 수정 전 만다라트를 보여주어야 합니다.
2. (오른쪽 사진) 스트릭 트래커에서 수정 전 날짜를 호버한 경우, 해당 날짜에 맞는 수정 전 하위 목표(할 일)을 보여주어야 합니다.

이러한 경우, 상위 목표나 하위 목표의 수정을 단순히 기존 테이블에 저장된 값을 수정해버리면, 이전 기록을 보여주는 뷰에서 잘못된 값이 나올 수 있다고 생각했습니다.

예를 들면, 사용자가 만다라트 수정 전 “밥 먹기” 라는 하위 목표를 완료한 후, 만다라트 수정 후 해당 목표를 “운동하기”로 바꾸면, 스트릭 트래커에서 보여줄 때 “밥 먹기”를 완료한 날에는 “운동하기”가 아닌 “밥 먹기”를 보여주어야 합니다. 즉, 만다라트가 한번 생성된 이후에 목표를 수정, 삭제 할 때에는 모두 POST하여 이력을 쌓아두고, 완료 여부를 체크할 때에도 각 이력에 대한 완료 여부를 체크해야 합니다. 따라서, 수정 전 날짜의 기록을 조회했을 때에도 사용자가 완료한 목표가 온전히 보여질 수 있도록 합니다.

따라서, 기존 Mandalart ← CoreGoal ← SubGoal ← History로 설계했던 테이블 구조를 위 ERD 그림과 같이 바꾸었습니다. 기존의 CoreGoal과 SubGoal은 해당 데이터의 위치만 저장하고, 해당 위치에 대한 이력은 각각의 스냅샷 테이블에 저장합니다. 할 일 완료 여부를 저장하는 할 일 히스토리 또한 하위 목표 스냅샷에 연결하여 어떤 이력에 대한 할 일인지 알 수 있도록 하였습니다.