서론

Gemini API를 사용한 AI 에이전트 개인 개발 과정에서, 무료 사용량의 통신 횟수 제한 문제에 부딪혔습니다.

제가 만든 것은 공적 서식 입력을 AI로 보조하는 앱입니다. 당초에는 채팅 형식의 대화 입력을 구상했으나, 통신 횟수를 추산하는 단계에서 "이것은 어렵겠다"라는 판단이 들어 설계를 재검토하게 되었습니다. 최종적으로는 폼(Form) 입력과 1회의 전체 교정이라는 구성으로 결정되었습니다.

비슷한 문제에 직면한 분들을 위해 판단 과정을 기록해 둡니다.

당초 구상했던 구성: 채팅 형식의 대화 입력

처음에 그렸던 모습은 채팅 형식으로 항목을 채워 나가는 UX(사용자 경험)였습니다.

공적 서식 입력은 폼에 계속해서 글자를 타이핑해야 하는 작업이 되기 쉬워, 솔직히 그리 즐거운 경험은 아닙니다. 항목 수도 많고, 작성하는 도중에 "이걸 왜 쓰고 있었지?"라고 생각하기 쉽습니다. 그렇다면 AI와 대화하며 한 항목씩 진행하는 형태가 입력 경험 자체를 가볍게 만들어 주지 않을까 생각했습니다.

기술 구성으로는 Flutter + Gemini API를 사용하며, 데이터는 로컬 저장만 수행합니다. 서버를 두지 않고 사용자가 자신의 API 키를 사용하는 것을 전제로 합니다. 채팅 형식이라면 AI가 직전의 주고받은 대화를 바탕으로 다음 질문을 던지거나, 입력 내용에 따라 말투를 조정할 수 있으므로, 대화의 문맥을 활용한 UX를 만들 수 있을 것이라는 이미지였습니다.

"단조로운 입력 작업"을 "대화하며 만들어가는 경험"으로 바꿀 수 있다면, 그것만으로도 앱을 사용하는 동기가 달라질 것이라고 생각했습니다.

직면한 제약: 무료 사용량과 통신 횟수의 미스매치

여기서 현실적인 문제에 부딪힙니다. Gemini API에는 무료 이용 구간이 있으며, 모델마다 RPM(분당 요청 수)과 RPD(일일 요청 수)의 상한이 설정되어 있습니다. 제가 상정했던 Gemini 1.5 Flash의 경우, 무료 구간에서는 RPM과 RPD 모두 비교적 타이트하게 설정되어 있어, 대화 형식으로 많은 항목을 채우다 보면 RPD 제한에 걸릴 리스크가 보였습니다 (구체적인 수치는 Google의 공식 문서가 가장 최신이며 정확하므로, 검토 시에는 반드시 그쪽을 참조해 주세요).

이 앱은 사용자가 자신의 API 키를 가져와 사용하는 설계이므로, 원리적으로 비용은 사용자 측의 부담이 됩니다. 그 자체는 설계상의 선택으로서 성립하지만, 문제는 "얼마나 많은 통신이 발생하는가"를 사용자가 사전에 예측하기 어렵다는 점이었습니다.

채팅 형식의 경우, 1 세션에서 항목 수만큼의 주고받음이 발생합니다. 잡담 같은 변동성까지 포함하면 통신 횟수는 더욱 늘어납니다. 무료 사용량 내에서 해결하는 사람도 있겠지만, 서식 작성 방식이나 대화 길이에 따라 초과하는 사람도 생길 수 있다는 불확실성이 남는 설계입니다.

제가 고민했던 지점은 바로 여기였습니다. 무료 사용량을 초과하는 순간, 사용자는 과금 여부를 결정해야 합니다. "편리한 앱을 사용하기 위해 내 API 키로 예상치 못한 요금이 발생했다"라는 상황이 되는 것은 개발자로서 마음이 무겁습니다. 특히 이 앱의 예상 사용자를 고려했을 때, 금전적인 불확실성을 UX에 섞고 싶지 않다는 마음이 강했습니다.

"대화의 즐거움"과 "비용의 예측 가능성"을 저울질했을 때, 후자를 우선하는 판단으로 기울게 되었습니다.

설계 재검토: 1세션 1통신으로의 전환

최종적으로 선택한 것은 "사용자가 구조화된 폼에 항목을 입력하고, 마지막에 딱 한 번 API를 호출하여 전체를 교정하는" 심플한 구성이었습니다. 1 세션당 통신은 1회. 이렇게 하면 사용자가 API 통신이 몇 번 발생하는지 의식할 필요가 없어집니다.

솔직히 대화 형식을 포기하는 것은 어려운 결정이었습니다. 채팅 형식으로 항목을 채워 나가는 경험 자체가 이 앱의 재미의 핵심이라고 생각했기 때문입니다. 폼 입력으로 되돌린다는 것은 당초 그렸던 "사용 동기가 바뀌는 경험"을 포기하는 것이기도 합니다. 몇 번인가 다른 안도 생각해 보았습니다. 예를 들어, 처음 몇 항목만 대화로 진행하고 나머지는 폼으로 하는 절충안이나, 대화 이력을 클라이언트 측에 축적했다가 마지막에 한꺼번에 1회만 보내는 안 등이었습니다.

하지만 절충안은 UX로서 어중간해지기 쉽고, 이력을 모아서 보내는 안은 프롬프트(Prompt)에 대화 로그를 통째로 실어야 하기 때문에, (1) 토큰 소비량을 예측하기 어려워지고, (2) 교정 대상인 본문과 대화 중의 잡담 부분을 AI가 구분하기 어려워진다는 두 가지 점이 우려되어 구현 전에 제외했습니다. 검토하면 할수록 "대화의 즐거움을 남기려다 구현을 복잡하게 만들면, 결국 어딘가에서 왜곡이 생긴다"라는 감각이 강해졌습니다.

결과적으로, 대화 형식을 미련 없이 포기하고 폼 입력 + 1회 교정 구성으로 완전히 전환하기로 했습니다. 분명 버린 것도 있지만, 얻은 것은 '사용자가 안심하고 사용할 수 있다'는 앱의 기반 그 자체입니다.

구현상의 고안: 프롬프트 설계와 개인정보 처리

설계를 결정한 후 구현 단계에서 특히 신경 쓴 점은 두 가지였습니다. 프롬프트를 어떻게 구성할 것인가와 개인정보를 어떻게 다룰 것인가입니다.

프롬프트의 방향성: '교정'으로 역할을 한정하기

이 앱에서 사용자가 입력하는 것은 자신이 직접 쓴 짧은 문장입니다. 본인의 감각이나 상황을 그대로 적어 내려간, 구어체적이고 짧은 문장입니다. 이를 서식에 어울리는 문체로 다듬는 것이 API의 역할이 됩니다.

여기서 의식한 것은 AI에게 '생각하게 하지 않는 것'입니다. 내용을 부풀리거나 적혀 있지 않은 내용을 보충하면, 사용자의 의도에서 벗어난 문장이 될 수 있습니다. 하고 싶은 일은 '짧고 단적으로 쓰인 내용을 서식의 문체에 맞추는 것'뿐입니다.

따라서 시스템 프롬프트(System Prompt)는 '교정의 역할', '변경해도 되는 부분', '변경해서는 안 되는 부분'을 명시하는 구성으로 했습니다. 실제 프롬프트는 대체로 다음과 같은 구조입니다.

당신은 공적 서식의 교정 어시스턴트입니다.

【역할】

입력된 자유 기술 텍스트를 공적 서식에 적합한 문체 및 경어체로 다듬는다.

【변경해도 좋은 것】

• 구어 표현을 서면용 표현으로 다듬기
• 경어체(입니다·습니다 체)로 통일
• 명백한 오타 및 탈자 수정

【변경해서는 안 되는 것】

• 적혀 있지 않은 사실이나 구체적인 예를 보충하는 것
• 뉘앙스나 강도를 바꾸는 것 (예: '조금 곤란하다'를 '매우 곤란하다'로 바꾸는 등)
• 원래 텍스트에 없는 정보를 추가하는 것

출력은 교정된 텍스트만. 서론이나 설명은 불필요합니다.

특히 효과적이었던 부분은 '변경해서는 안 되는 것'을 구체적인 예시와 함께 나열한 부분입니다. 단순히