[2025.09.19 주간 개발 트렌드] Java 25 정리 (LTS, Scoped Values, Preview)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# Gemini CLI가 코드 작성 다음 단계로 넓어지고있다

AI에게 코드를 작성해달라고 하는건 이제 꽤 익숙해졌다. 그런데 코드가 만들어졌다고 개발이 끝나는것은 아니다. 변경 내용을 확인하고 테스트한 다음 배포까지 해야 실제로 사용할 수 있다.

이번주 9월 10일 Google이 [Gemini CLI의 보안 분석과 Cloud Run 배포 확장](https://cloud.google.com/blog/products/ai-machine-learning/automate-app-deployment-and-security-analysis-with-new-gemini-cli-extensions/)을 소개했다. 확장 프레임워크가 어떤 방향으로 갈지 보여주는 초기 사례다.

이번주 개발트렌드로 AI가 코드를 작성하는것에서 보안 분석과 배포까지 작업 범위를 넓히는 흐름을 살펴보려고 한다.

# 1. 우선 어떤 기능이 추가됐는지 보자

이번에 소개된 기능은 크게 두가지다. 로컬 코드 변경을 분석하는 보안 확장과 Cloud Run 배포를 돕는 확장이다.

```text
Gemini CLI
├── 코드 탐색과 수정
├── 보안 분석: /security:analyze
└── Cloud Run 배포: /deploy
```

별도의 도구로 하던 작업을 같은 대화 흐름에서 이어갈 수 있는 구조다. 코드를 수정한 맥락을 유지하면서 변경 부분을 분석하고 배포 단계까지 연결하려는것으로 보인다.

여기서 CLI 본체와 확장은 구분해야한다. 명령어 이름만 입력하면 아무 환경에서나 모든 기능이 준비되는것은 아니다. 필요한 확장을 설치하고 해당 서비스에 접근할 수 있는 환경을 구성해야한다.

발표에서는 Gemini CLI 0.4 이상을 안내하고있다. 사용하는 버전과 확장 구성이 맞는지부터 확인하면 좋겠다.

# 2. 보안 분석은 무엇을 보나

보안 확장은 로컬 변경 사항을 git diff 기준으로 살펴보고 문제와 수정 방향을 제안한다. 하드코딩된 비밀값이나 인젝션, 접근 제어 문제 같은 항목을 다룬다.

```text
코드 변경
    ↓
/security:analyze
    ↓
문제가 의심되는 위치와 이유 확인
    ↓
수정 필요 여부 판단
    ↓
코드 수정과 테스트
```

예를 들어 API에서 입력값을 그대로 쿼리에 넣는 변경이 있다고 해보자. AI가 위험한 부분을 찾아주면 리뷰 전에 다시 살펴볼 계기가 된다.

다만 분석 결과가 없다는것과 안전하다는것은 같은 말이 아니다. diff만으로는 운영 환경의 권한이나 다른 서비스와의 연결을 충분히 알기 어려운 경우도 있다.

반대로 문제가 있다고 나온 항목도 실제 흐름을 확인해야한다. 앞단에서 검증하고있는 값을 다시 지적할 수도 있고, 서비스의 의도를 잘못 이해할 수도 있다.

그래서 보고서의 개수보다 어떤 경로로 문제가 발생하는지 설명할 수 있는지가 중요하다. 입력이 어디에서 들어오고 어떤 검증을 거쳐 어디에 사용되는지 따라가보면 좋겠다.

# 3. 분석 결과를 바로 수정해도 될까

AI가 수정 방향까지 알려주면 그대로 적용하고싶어진다. 그런데 보안 문제를 막으려다가 정상적인 사용 흐름을 바꾸는 경우도 생각해봐야한다.

예를 들어 관리자 전용 API에 권한 확인을 추가한다고 해보자. 로그인 여부를 확인하는것과 관리자 권한을 확인하는것은 다른 작업이다.

```text
확인하고싶은 동작
├── 로그인하지 않은 요청은 거절되는가
├── 일반 사용자의 요청도 거절되는가
├── 관리자는 필요한 작업을 할 수 있는가
└── 다른 사용자의 데이터에 접근할 수 없는가
```

수정된 코드가 컴파일되는지만 확인하면 이런 차이를 놓칠 수 있다. 정상 요청과 거절해야하는 요청을 같이 테스트해보는게 좋겠다.

또한 분석과 수정은 나눠서 확인할 수 있는 작업이다. 우선 어떤 문제가 발견됐는지 읽고, 수정하도록 요청했다면 실제 diff를 다시 살펴보자. 보고서가 그럴듯한것과 변경된 코드가 요구사항을 만족하는것은 별도로 확인해야한다.

이번주 발표 기준으로 로컬 분석을 먼저 사용할 수 있고, GitHub PR이나 Actions를 통한 연동은 앞으로 제공할 내용으로 소개됐다. 지금 바로 모든 PR에 자동 적용되는 기능처럼 받아들이면 안되겠다.

# 4. Cloud Run 배포는 어떻게 연결되나

Cloud Run 확장은 MCP 도구를 통해 애플리케이션을 빌드하고 배포하는 작업을 연결한다. /deploy 명령으로 작업을 시작하고 배포된 주소를 받는 흐름이 소개됐다.

개발자가 터미널에서 명령어를 순서대로 조합하던 부분을 Agent가 도구를 호출하면서 진행하는 방식이다.

```text
애플리케이션 코드
    ↓
배포 요청
    ↓
빌드와 컨테이너 준비
    ↓
Cloud Run 배포
    ↓
서비스 주소와 동작 확인
```

이 과정에서도 배포 대상을 정하는건 중요하다. 같은 프로젝트 안에서도 테스트용 서비스와 운영 서비스는 다를 수 있고, 리전이나 환경 변수에 따라 결과가 달라질 수 있다.

배포하기 전에 어떤 프로젝트와 서비스에 올리는지 확인하고, 외부 공개가 필요한 서비스인지도 정해야한다. 데이터베이스 연결이나 애플리케이션 설정이 빠졌다면 주소가 만들어져도 기능은 정상적으로 동작하지 않을 수 있다.

배포 완료 메시지를 받는것 다음에 실제 API를 호출하고 로그를 확인하는 과정까지 이어가면 좋겠다. 화면이 열린다는 사실과 핵심 기능이 잘 동작한다는것도 다르다.

# 5. CI/CD와는 어떻게 같이 사용할까

이런 기능을 보면 기존 배포 파이프라인이 바로 필요없어질것처럼 느껴질 수 있다. 개인적으로는 먼저 용도를 나눠서 보는게 좋을것 같다.

새로운 서비스를 시험하거나 테스트 환경을 빠르게 준비할때는 대화형 배포가 편할 수 있다. 어떤 설정을 바꿔야할지 설명을 들으면서 진행할 수 있기 때문이다.

반면 팀의 반복 배포에서는 같은 입력으로 같은 절차를 실행하고 결과를 기록하는것이 중요하다. 누가 어떤 코드를 어떤 설정으로 배포했는지 다시 확인할 수 있어야한다.

Agent로 진행한 작업에서도 필요한 설정과 명령을 프로젝트에 남겨두면 좋겠다. 다음 배포가 이전 대화 내용에만 의존한다면 담당자가 바뀌거나 세션이 끊겼을때 다시 설명해야한다.

보안 분석도 마찬가지다. 대화 중에 한번 확인한 결과와 모든 변경에 반복해서 적용하는 검증은 역할이 다르다. 기존 테스트와 리뷰에 AI 분석을 추가하는 방식부터 시작하면 적용 범위를 판단하기가 수월하겠다.

# 마무리

이번 Gemini CLI 소식에서 눈에 들어온건 코드 생성 이후의 작업까지 같은 흐름으로 연결하려는 부분이다. 개발자가 사용하는 도구를 Agent가 호출하면서 DevSecOps 영역으로 넓어지고있다.

개인적으로는 명령어를 몇개 줄이는것보다 수정부터 검증과 배포까지 맥락을 이어갈 수 있다는 점이 흥미롭다. 그만큼 개발자는 결과를 읽고 실제 동작을 판단하는 능력이 더 중요해질것 같다.

우선 작은 테스트 프로젝트에서 보안 분석 결과와 배포 과정을 확인해보면 좋겠다. AI가 완료했다고 말한 작업을 내가 설명하고 다시 실행할 수 있는지까지 살펴봐야겠다..


[2025.09.12 주간 개발 트렌드] Gemini CLI 확장 정리 (보안 분석, Cloud Run 배포, DevSecOps)

독자의 메모