전체 코드를 Gemini에 넣었다가 분류가 빗나간 밤

밤샘 디버깅에서 Gemini를 만난 장면

저는 Python으로 이메일 자동 분류 기능을 만들던 밤, 분류 결과가 계속 엉뚱하게 나와서 1시간 넘게 디버깅했습니다. 처음에는 Gemini API에 전체 프로젝트 코드를 한꺼번에 넣고 완성된 해결책을 요구했지만, Gemini가 제 프로젝트의 함수 이름과 데이터 형식을 정확히 알 수 없어서 수정안이 여러 번 빗나갔습니다. 저는 그때 AI가 코드를 대신 완성해 주면 바로 실행할 수 있다고 생각했지만, 실제 장면에서는 입력 조건을 정리하지 않은 제 쪽의 문제가 더 컸습니다.

이후 Python 코드를 이메일 수신, 제목 추출, 분류 기준 적용, 결과 저장의 4개 단계로 나누고 Gemini API에 한 단계씩 질문했습니다. 먼저 오류가 발생한 함수와 입력 예시 3개만 전달했더니 Gemini가 예외가 발생할 수 있는 지점을 구체적으로 설명했습니다. 저는 제안된 코드를 그대로 붙여 넣지 않고 로컬에서 한 함수씩 실행했으며, 잘못된 변수명을 고친 뒤에야 분류 결과가 안정적으로 나왔습니다. 이 경험을 통해 Gemini는 정답 버튼이라기보다 디버깅 과정을 함께 정리하는 동료에 가깝다는 사실을 배웠습니다.

Python과 Gemini API를 연결할 때 바꾼 작업 순서

처음에는 Python 파일 하나에 API 호출, 프롬프트, 결과 저장을 모두 넣었지만, 오류가 생기면 어느 단계에서 문제가 생겼는지 확인하기 어려웠습니다. 그래서 저는 Gemini API 호출부를 별도 함수로 분리하고, 입력 텍스트와 응답 결과를 각각 로그로 남겼습니다. 같은 질문을 2번 실행했을 때 응답 형식이 달라지는 장면도 있었기 때문에, 결과를 JSON 형식으로 요청하고 필수 필드가 없는 경우에는 재처리하도록 Python 검증 코드를 추가했습니다.

프롬프트도 한 문장으로 끝내지 않았습니다. 저는 Gemini에 역할, 입력 형식, 원하는 출력 형식, 금지할 동작, 테스트 예시를 차례로 적었습니다. 예를 들어 이메일 자동 분류에서는 분류 결과를 업무, 광고, 개인의 3가지 값 중 하나로 반환하도록 지정하고, 판단 근거는 2문장 이내로 제한했습니다. 이렇게 조건을 구체화하자 Gemini API의 응답을 Python 코드에서 다루기 쉬워졌고, 사람이 다시 확인해야 하는 결과도 줄었습니다.

다만 Gemini가 만든 코드는 Python 문법이 맞더라도 제 운영 환경과 맞지 않을 수 있습니다. 저는 한 번은 Gemini가 제안한 라이브러리 버전과 설치된 Python 환경이 달라서 실행 단계에서 멈췄습니다. 그 뒤에는 새 코드를 적용하기 전에 가상 환경, 패키지 버전, 입력 파일 경로를 먼저 확인하고, 10개 안팎의 테스트 데이터로 결과를 비교했습니다.

API 키를 잃어버린 30분과 보안 설정

제가 가장 크게 당황한 장면은 Gemini API 키를 Python 코드에 직접 적은 채 GitHub에 커밋했던 때입니다. 커밋 후 30분 만에 Google에서 비정상적인 사용량이 감지되었다는 메일이 왔고, 저는 즉시 해당 키를 폐기하고 새 키를 발급했습니다. 이미 공개된 키를 파일에서 지우는 것만으로는 충분하지 않다는 사실을 그때 알았기 때문에, 사용 기록과 저장소의 커밋 이력도 함께 확인했습니다.

현재는 Gemini API 키를 .env 파일에 저장하고, .gitignore에 .env를 등록한 뒤, Python 코드에서는 환경 변수로 읽습니다. .env 파일이 실제로 무시되는지 Git 상태에서 확인하고, GitHub에 올리기 전에는 API 키와 비슷한 문자열을 검색합니다. Google Cloud 콘솔에서는 Gemini API 사용량과 호출 기록을 확인하며, 평소보다 호출량이 빠르게 늘면 Python 반복문이나 재시도 로직부터 점검합니다.

API 키를 주기적으로 재발급하는 것도 보안 관리의 한 방법이지만, 키를 바꾸는 것만으로 모든 문제가 해결되지는 않습니다. 저는 Gemini API를 호출하는 Python 함수에 타임아웃과 재시도 횟수를 제한하고, 오류 응답을 무한 반복하지 않도록 조건을 넣었습니다. 실시간 뉴스 분석처럼 호출이 잦은 작업은 특히 사용량 제한과 로그 보관 범위를 정해 두어야 하며, 이메일 본문처럼 개인정보가 포함된 장면에서는 전송할 내용을 먼저 줄여야 합니다.

작은 자동화에서 코드 리뷰까지 확장한 방법

저는 처음부터 실시간 뉴스 분석이나 코드 리뷰 자동화를 만들지 않았습니다. 먼저 Python으로 이메일 자동 분류라는 작은 기능을 실행하고, 입력 3개와 출력 3개를 직접 비교한 뒤 다음 단계로 넘어갔습니다. 그 과정에서 Gemini API가 만든 결과를 사람이 검토하는 절차를 유지했기 때문에, 잘못된 분류가 시스템 전체에 바로 반영되는 일을 막을 수 있었습니다.

이후에는 뉴스 문장에서 핵심 문장을 추출하고, 코드 리뷰에서는 함수 변경 내용을 요약하도록 Gemini를 사용했습니다. 하지만 Gemini가 제안한 수정 사항을 자동 승인하지는 않았습니다. 코드 리뷰 결과에는 누락이나 잘못된 가정이 있을 수 있으므로, 저는 변경된 Python 파일을 직접 읽고 테스트를 통과한 경우에만 반영했습니다. AI의 생산성은 검토를 없애는 데서 나오는 것이 아니라, 사람이 반복 작업보다 판단이 필요한 장면에 집중하게 하는 데서 나온다고 생각합니다.

이 글의 결론은 Gemini API를 반드시 사용해야 한다는 뜻이 아닙니다. Python 자동화에서 반복되는 작업이 있고 입력과 출력의 기준을 설명할 수 있다면 Gemini를 실험해 볼 수 있다는 뜻입니다. 저는 작은 기능부터 시작하고, API 키를 .env와 .gitignore로 보호하며, Google Cloud 콘솔의 사용량을 확인하고, 생성된 코드를 직접 테스트하는 순서를 지켰습니다. 이 4가지 원칙을 지키면 밤샘 디버깅의 장면을 줄이면서도 Gemini를 안전한 개발 보조 도구로 활용할 수 있습니다.

실전에서 겪은 시행착오

저는 밤샘 디버깅 중 Python 코드의 이메일 자동 분류 기능을 Gemini API에 설명하고, 처음에는 한 번에 완성된 코드를 요구했다가 오류가 이어져 작은 함수부터 나누는 방식으로 고쳤습니다.

저는 GitHub에 Gemini API 키를 실수로 커밋한 뒤 30분 만에 비정상적인 사용량 메일을 받고 키를 폐기했으며, 이후 .env 파일과 .gitignore를 사용해 같은 장면이 반복되지 않도록 바꿨습니다.

적용 전 꼭 확인할 주의사항

• Gemini API를 Python에서 호출하기 전에 API 키를 코드에 하드코딩하면 GitHub에 노출될 수 있으므로 .env 파일과 .gitignore를 먼저 설정해야 합니다.
• Gemini가 생성한 Python 코드를 그대로 실행하기 전에 이메일 자동 분류와 같은 작은 기능으로 테스트하고, API 호출 로그와 Google Cloud 콘솔의 사용량을 확인해야 합니다.
• Gemini API를 사용해 실시간 뉴스 분석이나 코드 리뷰 자동화를 확장할 때는 30분 만에 비정상적인 사용량 메일을 받은 장면처럼 키 유출과 호출량 증가를 함께 점검해야 합니다.