[2026.08.28 주간 개발 트렌드] Slack Code와 지속 실행 Agent, Cloud Run·Sandbox·CI

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

# 이번주는 개발 플랫폼의 확장과 운영 경계를 같이 봐야겠다

이번주에는 Cursor가 코드 호스팅으로 영역을 넓혔고, GitHub에서는 여러 개발 서비스에 영향을 준 긴 장애가 발생했다. Agent와 저장소, CI를 한곳에서 연결하는 편리함과 그 연결이 만드는 의존성을 같이 생각하게 된다.

8월 17일부터 21일까지의 소식을 중심으로 정리해보았다. Next.js는 이번주 나온 적용 가이드를 보고, npm 캠페인과 PostgreSQL 패치는 앞선 발표에서 이어서 챙길 내용으로 구분했다.

| 분야 | 살펴볼 내용 | 실무에서 볼 부분 |
| --- | --- | --- |
| AI·개발 플랫폼 | Cursor Origin 초기 베타 | 저장소 원본·동기화·이전 범위 |
| 프론트엔드 | Next.js 16.3 적용 가이드 | 캐시·탐색·상태 갱신 |
| 백엔드 | Agent가 사용하는 업무 서비스 | 권한·중복 실행·모델 교체 |
| DevOps | GitHub 8월 17일 장애 | 배포와 서비스 실행의 의존성 |
| 보안 | CI 입력 처리와 npm 공급망 | 신뢰 경계·토큰·외부 코드 |
| 데이터베이스 | PostgreSQL 패치 후속 점검 | 적용 상태·확장·운영 검증 |

# 1. AI — Cursor가 저장소를 직접 호스팅하기 시작했다

8월 17일 [Cursor Origin](https://cursor.com/changelog/origin-code-hosting)이 초기 베타로 공개됐다. 유료 플랜에 순차적으로 제공하며 저장소와 Pull Request, 코드 탐색, GitHub 동기화 등을 지원한다.

코드를 편집하고 Agent를 실행하는 도구에서 코드가 저장되는 공간까지 넓어진 변화다. 다만 초기 베타라는 상태와 앞으로 추가할 기능을 현재 완성된 기능처럼 섞어보지는 않아야겠다.

## Origin 저장소와 GitHub 동기화는 다르다

Origin에서 직접 호스팅하는 저장소는 Origin이 원본이고 Push도 그쪽으로 간다. 반면 GitHub에서 동기화한 저장소는 GitHub가 원본이며, Push는 GitHub로 보내고 Origin이 결과를 반영한다.

이 차이는 장애를 생각할때 중요하다. 다른 화면에서 코드를 볼 수 있다는 사실만으로 원본 저장소에 대한 의존성이 없어졌다고 판단할 수는 없다.

```text
직접 호스팅: 개발자·Agent → Origin 저장소
동기화 사용: 개발자·Agent → GitHub 원본 → Origin 복사본
```

## 저장소 이전은 Git Remote만의 문제가 아니다

팀에서 저장소를 옮긴다고 생각하면 코드 외에도 확인할것이 많겠다. 브랜치 보호와 리뷰 규칙, 배포 연동, 패키지 배포 권한과 비밀값 등이 함께 연결돼있기 때문이다.

모델을 교체할때도 업무 규칙은 유지할 수 있어야겠다. 주문 상태 같은 최종 판단은 모델 응답을 검증한 뒤 업무 서비스에서 결정하는 구조를 생각할 수 있다.

# 2. 프론트엔드 — 새 버전보다 적용할 화면을 구체적으로 보자

Next.js 16.3의 정식 출시는 이달 3일 소식이다. 이번주인 8월 18일에는 [앱과 같은 사용 경험을 만드는 가이드](https://nextjs.org/blog/building-app-like-experiences-with-nextjs-16-3)가 공개됐다.

Cache Components와 Partial Prefetching, Server Components를 연결해 빠른 탐색과 동적인 화면을 구성하는 예시를 설명한다. 새 메이저 버전 발표와 기존 기능을 적용하는 가이드는 구분해서 보면 좋겠다.

## 화면이 즉시 보이는것과 데이터가 준비되는것을 나누자

가이드에서는 먼저 보여줄 화면 구조와 로딩 UI를 준비하고, 동적인 내용은 Suspense를 통해 이어서 전달하는 흐름을 설명한다. Partial Prefetching은 클릭 전에 필요한 화면 구조를 브라우저로 가져오는 역할이다.

```text
상세 화면으로 이동
  → 준비된 레이아웃·로딩 UI 표시
  → 필요한 데이터 도착
  → 실제 내용과 사용자 상태 반영
```

빠르게 표시할 수 있다고 모든 데이터를 오래 보관해야하는것은 아니다. 공용 정보와 사용자별 정보, 자주 바뀌는 상태에 같은 캐시 정책을 적용하지 않도록 봐야겠다.

## 수정 직후와 다시 방문했을때도 확인하자

설정 화면에서 이름을 바꾼 뒤 다른 화면으로 갔다가 돌아오면 어떤 값이 보여야할까. 목록과 상세가 같은 데이터를 보여준다면 두 화면의 갱신 기준도 맞아야겠다.

## Agent에게도 프로젝트 버전에 맞는 문맥이 필요하다

[16.3 발표](https://nextjs.org/blog/next-16-3)에는 개발 중 `AGENTS.md`의 안내를 통해 프로젝트 버전과 맞는 문서를 Agent가 읽게 하는 기능이 포함됐다. 최신 문서의 예제가 현재 프로젝트와 항상 맞는것은 아니기 때문이다.

Agent에게 화면 개선을 맡긴다면 어떤 경로를 바꿀지와 유지할 동작, 확인할 테스트를 같이 주면 좋겠다. 기능 이름만 나열하는것보다 성공한 화면의 기준을 설명하는것이다.

# 3. 백엔드 — Agent도 권한을 확인해야하는 클라이언트다

Agent가 MCP Tool을 통해 기능을 호출해도 주문과 결제, 사용자 권한의 규칙은 그대로다. HTTP Controller 옆에 다른 진입점이 생겼다고 생각하면 기존 설계와 연결하기 쉽겠다.

```text
Web·Mobile → REST Controller ─┐
                             ├─ 업무 Service → DB·외부 API
Agent → MCP Tool ────────────┘
```

Tool Handler는 입력과 결과를 변환하고, 실제 업무 판단은 Service에서 공유하는 구성을 생각할 수 있다. 같은 고객을 조회하는데 인터페이스에 따라 접근 범위가 달라지면 곤란하다.

## 모델이 선택한 ID를 인증 정보로 믿지 말자

입력 스키마에 맞는 고객 ID가 들어와도 현재 사용자가 그 고객을 조회할 수 있는지는 별도 문제다. 모델이 적은 사용자나 조직 ID만으로 요청 주체를 결정해서는 안되겠다.

인증한 신원을 서버에서 전달하고 자원 소유권과 수행 가능한 작업을 Service에서 확인하면 좋겠다. 조회 결과의 필드도 업무에 필요한 범위로 제한할 수 있다.

## 타임아웃 뒤에 같은 도구를 다시 호출할 수 있다

Agent는 외부 응답을 받지 못하면 작업을 다시 시도할 수 있다. 이때 실제 처리는 성공했지만 응답만 유실된 경우를 생각해야한다.

환불이나 메시지 발송처럼 상태가 바뀌는 작업이라면 요청 식별자와 처리 결과를 보관할 수 있다. 다시 들어온 요청이 새 업무인지 기존 업무의 확인인지 구분하는것이다.

```text
쓰기 요청 → 요청 ID 확인 → 기존 처리 결과 조회
                         → 미처리라면 업무 수행·결과 저장
```

이 구조에서도 동시 실행과 트랜잭션 범위를 검토해야한다. 조회 후 실행 사이에 같은 요청이 또 들어오는 문제를 단순한 조건문 하나로 해결했다고 생각하지 않아야겠다.

# 4. Cloud·DevOps — GitHub 장애에서 배포 의존성을 생각해보자

8월 17일 GitHub에서는 7시간 47분 동안 장애가 발생했다. 인증과 Actions, API, Issue와 PR, Copilot 등 여러 서비스가 영향을 받았고, [8월 20일 공식 보고서](https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/)가 공개됐다.

GitHub은 트래픽 증가에 핵심 인프라가 확장하지 못한 용량 문제와 복구 중 일부 클라이언트의 재시도 반복을 설명했다. 모든 서비스가 동일한 시간 동안 완전히 중단됐다는 의미로 읽지는 않아야겠다.

## 개발·배포·실행의 의존성을 따로 그려보자

보고서를 읽고 우리 서비스를 점검한다면 먼저 GitHub가 안될때 무엇이 멈추는지 나눠보고 싶다. 코드를 Push하지 못하는것과 새 배포를 못하는것, 이미 실행 중인 서비스가 멈추는것은 다르다.

```text
개발: Repository → PR → Review
배포: CI → Build → Artifact → Deployment
실행: 배포된 애플리케이션 → 업무 DB·필수 외부 서비스
```

새 코드를 가져오지 못해도 이미 검증된 Artifact로 이전 버전을 배포할 수 있는지 확인할 수 있다. Rollback할때 소스 저장소와 빌드 서버가 반드시 필요한지도 궁금하다.

운영 애플리케이션이 요청마다 GitHub API에서 설정을 가져온다면 그 경로는 실행 의존성이다. 필요한 경우 검증된 설정을 별도 저장하고 갱신 실패시의 동작을 정할 수 있겠다.

GitHub OAuth처럼 서비스 기능상 필요한 연동도 있다. 이런 경우에는 의존성을 숨기기보다 장애시 로그인과 기존 세션이 어떻게 동작할지 명확히 정하는 편이 좋겠다.

## 복사본과 실제 복구 경로는 다를 수 있다

저장소를 미러링해도 Actions와 비밀값, 배포 권한까지 바로 복구되지는 않는다. 다른 CI로 옮길 수 있는 코드가 있다는것과 실제로 옮겨 실행할 수 있다는것을 구분해야겠다.

그렇다고 모든 팀이 CI를 두 벌 운영해야한다는 결론은 아니다. 어떤 서비스가 어느 정도의 배포 지연을 감당할 수 있는지에 따라 필요한 준비가 달라진다.

## 재시도는 복구를 돕기도 하고 방해하기도 한다

특히 Agent의 재시도와 애플리케이션 SDK의 재시도, Queue의 재전달이 겹치면 실제 호출 횟수를 놓치기 쉽다. 작업 전체의 시간과 비용 한도를 어디서 통제하는지도 같이 봐야겠다.

# 5. 보안 — CI도 외부 입력을 받는 프로그램이다

8월 17일 [Wiz의 Snowflake 보안 연구](https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug)가 공개됐다. Snowflake의 공개 저장소에 있는 Actions Workflow가 Issue 제목을 Shell 스크립트에 직접 삽입해 명령 주입이 가능한 사례다.

허가된 연구 과정에서 내부 Jira 자격 증명의 접근 범위를 확인했고, 6월 제보 뒤 수정과 자격 증명 교체가 진행됐다. Snowflake는 조사에서 무단 접근의 증거를 찾지 못했다고 밝혔다. 이번주 새로 침해가 시작됐다는 소식과는 구분해야한다.

발표는 Copilot이 참여한 PR이라는 점과 취약한 특정 코드의 작성 주체를 구분하도록 정정됐다. 따라서 AI가 해당 취약 코드를 만들었다고 단정하기보다, 자동 검사도 놓칠 수 있는 입력 처리 문제에 집중하면 좋겠다.

## 제목과 댓글은 코드가 아니라 데이터다

Shell 스크립트를 만드는 단계에 외부 문자열을 직접 끼워 넣으면 나중에 문자열을 정리하는것만으로 충분하지 않을 수 있다. 문법으로 해석되는 시점과 데이터로 전달되는 시점이 다르기 때문이다.

[GitHub의 보안 안내](https://docs.github.com/en/actions/reference/security/secure-use)는 인라인 스크립트에서 중간 환경 변수를 사용하는 방법 등을 설명한다. 아래는 Issue 제목을 JSON 데이터로 전달하는 Step의 예시다.

```yaml
- name: Prepare issue data
  env:
    ISSUE_TITLE: ${{ github.event.issue.title }}
  run: |
    jq -n --arg title "$ISSUE_TITLE" '{title: $title}'
```

환경 변수로 받았어도 다시 `eval`에 넣거나 명령 문자열로 조합하면 문제가 돌아올 수 있다. 인용과 인자 전달까지 포함해서 입력이 실행 코드로 바뀌지 않는지 봐야겠다.

## 읽기 권한도 필요한 범위로 지정하자

`permissions: read-all`은 모든 읽기 권한을 허용하는 설정이므로 항상 최소 권한이라고 부르기는 어렵다. 코드 조회만 필요하다면 필요한 항목을 구체적으로 선언하는 방식부터 검토하면 좋겠다.

```yaml
permissions:
  contents: read
```

실제 Job에 필요한 권한은 기능별로 다르다. 위 예시를 모든 Workflow에 그대로 복사하기보다 Issue 작성이나 PR 갱신, 배포 Job의 요구를 각각 확인해야겠다.

외부 PR 코드를 권한이 높은 `pull_request_target` 같은 실행 문맥에서 Checkout해 실행하는 구성도 점검할 부분이다. 읽기 전용 토큰을 사용해도 별도로 주입한 Secret과 외부 서비스 권한까지 사라지는것은 아니다.

Third-party Action은 검토한 전체 Commit SHA로 고정하고, 버전 변경도 리뷰 대상으로 삼을 수 있다. 고정한 코드 자체가 안전한지는 별도 확인이 필요하다.

## npm 캠페인은 이번주 처음 나온 소식과 구분하자

이달 초 [OpenSourceMalware가 공개한 npm 캠페인](https://opensourcemalware.com/blog/russian-ai-slopsquatting-npm-campaign)은 수백 개의 악성 패키지를 통해 여러 운영체제에 악성코드를 전달하는 사례다. 약 800개 규모로 알려진 소식은 이번주 최초 발표가 아니다.

여기서는 설치 전후 Script 없이 `require()`로 모듈을 불러오는것만으로 실행이 시작될 수 있었다. 설치 Script를 막았다고 패키지를 테스트하거나 실행하는 단계까지 보호되는것은 아니라는 점을 봐야겠다.

AI가 패키지를 제안했다는 이유만으로 존재와 정당성을 신뢰하지 않고, 공식 문서의 이름과 유지관리 주체를 확인하고 싶다. Lockfile의 새 의존성과 내려받는 출처도 변경 검토에 포함할 수 있다.

# 6. 데이터베이스 — 지난주 패치가 실제로 반영됐는지 보자

DB 쪽에서는 지난주인 [8월 13일 PostgreSQL 업데이트](https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/)의 적용 상태를 챙기면 좋겠다. 대상은 18.6, 17.11, 16.15, 15.19, 14.24이며 19 Beta 3도 함께 공개됐다.

이번주에는 버전 번호를 확인하는것에서 한 걸음 더 가고 싶다. 패치 대상 인스턴스와 복제본, 사용하는 확장과 후속 작업을 정리했는지 보는것이다.

병렬 GIN 인덱스 생성의 통계 문제와 특정 `btree_gist`·`ltree` 인덱스는 추가 조치가 필요할 수 있다. 해당 기능을 사용하는 환경이라면 공식 안내의 영향 조건을 확인해야겠다.

고객 ID와 상태로 찾는 조회라면 관계형 쿼리로 충분할 수 있다. 의미 기반 검색이 실제 요구사항일때 벡터 검색을 검토하고, 새 저장소의 동기화와 삭제 책임까지 확인하는 편이 현실적이겠다.

# 7. 이번주는 자동화의 경계를 한 번 그려보고 싶다

이번주 하나를 고른다면 우리 저장소에서 배포된 서비스까지의 의존성을 그려보고 싶다. Repository와 Agent, CI와 Artifact, 운영 환경이 어떤 인증과 데이터로 연결되는지 확인하는것이다.

GitHub가 안될때 할 수 있는 일과 못하는 일, Agent가 호출할 수 있는 도구와 실제 권한을 구분해보자. Workflow의 외부 입력과 Secret 접근 경로도 함께 표시하면 점검할 부분이 구체적으로 보일것같다.

개발 플랫폼이 많은 일을 대신해줄수록 내가 직접 이해해야하는 경계도 더 분명해지는것같다. 이번주는 도구를 얼마나 많이 연결했는지보다 그 연결이 실패하거나 잘못된 입력을 받았을때 어떻게 동작하는지 살펴볼 주다..


[2026.08.21 주간 개발 트렌드] Cursor Origin과 GitHub 장애, Agent·CI의 신뢰 경계

독자의 메모