[2025.08.01 주간 개발 트렌드] npm Trusted Publishing 정리 (OIDC, 배포 토큰, provenance)

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

# 말로 앱을 만들고나면 그다음은 뭘까

AI로 화면을 만드는 도구를 보면 처음에는 정말 신기하다. 만들고싶은걸 적었는데 버튼과 목록이 생기고 데이터도 들어간다.

그런데 조금만 더 생각해보면 궁금해진다. 이 결과물을 계속 수정하려면 어떻게 해야할까? 문제가 생겼을때 코드를 볼 수 있을까? 기존 개발 방식과도 연결할 수 있을까?

이번주 7월 23일에 [GitHub Spark가 Public Preview로 공개됐다](https://github.blog/changelog/2025-07-23-github-spark-in-public-preview-for-copilot-pro-subscribers/). 이번주 개발트렌드로 앱을 만드는 과정이 어떻게 달라지는지 정리해보려고 한다.

Spark는 자연어로 앱을 만들고 수정하며 배포까지 이어가는 기능을 제공한다. 지금은 Copilot Pro+ 구독자를 대상으로 공개되어있다. 우선 어떤 기능이 있는지 살펴보자.

# 1. 우선 어떤걸 해주는 도구인가

제공하는 범위는 화면 생성만이 아니다. frontend와 backend 기능에 데이터 저장, GitHub 인증, LLM 추론과 호스팅을 묶어서 제공하는 형태다.

수정할때도 자연어만 사용하는것은 아니다. 시각적인 편집과 코드 편집을 같이 사용할 수 있다.

예를 들어 독서 기록 앱을 만든다고 해보자. 다음처럼 시작할 수 있을것 같다.

```text
독서 기록 앱을 만들어줘.

책 제목, 저자, 읽은 날짜, 한줄 메모를 저장하고싶어.
목록에서 제목으로 검색하고 기록을 수정하거나 삭제할 수 있게 해줘.
사용자마다 본인이 작성한 기록만 볼 수 있어야해.
```

이건 기능을 설명하기 위한 프롬프트 예시다. 실제로 이 요청을 Spark에서 실행했다는 의미는 아니다.

여기서도 요청을 어떻게 쓰는지가 중요하다. “독서 앱 만들어줘”라고만하면 책 정보는 어떤게 필요한지, 누구의 데이터를 보여줘야하는지 도구가 추측해야한다.

화면을 빨리 만드는것과 요구사항이 정확한것은 별개의 문제다. AI가 작업할 범위가 커질수록 처음에 설명해야할 기준도 구체적이어야할것 같다.

# 2. Repository로 이어진다는게 왜 중요한가

이번 발표에서 눈에 들어온건 앱을 GitHub Repository로 만들 수 있다는 점이다. 생성한 코드와 저장소를 동기화하고 GitHub Actions, Dependabot과 연결하는 흐름도 소개됐다.

```text
아이디어와 요구사항
        ↓
Spark에서 앱 생성·수정
        ↓
GitHub Repository로 연결
        ↓
코드 확인 · 테스트 구성 · 변경 검토
        ↓
계속 수정하고 운영
```

이렇게되면 처음에 AI가 만든 결과물도 코드 리뷰와 버전 관리 대상으로 가져올 수 있다. 누가 어떤 내용을 바꿨는지 확인하고 잘못된 변경을 되돌릴 기준도 마련할 수 있다.

다만 저장소가 생겼다고 테스트와 운영 구성이 전부 완성됐다고 보면 안된다. 어떤 동작을 검사할지, 배포 전에 무엇을 통과해야하는지는 프로젝트에 맞게 정해야한다.

Dependabot도 의존성의 취약점 수정 등을 도와주는 도구다. 애플리케이션의 권한 검사나 잘못된 업무 로직까지 전부 찾아주는것은 아니다. [Dependabot 보안 업데이트 설명](https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-security-updates)

또한 소스 코드를 확보하는것과 다른 플랫폼에서 바로 실행하는것은 다르다. 내장 인증이나 데이터 저장 기능에 의존한다면 외부 환경으로 옮길때 그 부분을 어떻게 연결할지 확인해야한다.

# 3. 앱이 동작하는것과 제대로 동작하는것

독서 기록 앱으로 다시 생각해보자. 책을 저장하고 목록에 표시하면 처음에는 잘 만들어진것처럼 보인다.

그런데 다음 상황도 확인해야한다.

1. 로그아웃했다가 다시 로그인해도 기록이 남는가?
2. 다른 사용자로 들어갔을때 내 기록이 보이지 않는가?
3. 제목을 비우거나 아주 긴 메모를 넣으면 어떻게 되는가?
4. 저장 버튼을 연속으로 눌러도 기록이 중복되지 않는가?
5. 저장에 실패했는데 성공했다고 표시하지는 않는가?

여기서 두번째가 특히 중요하다. 로그인 기능이 있다는것과 사용자별 데이터 접근을 제한하는것은 다르다.

화면에서 다른 사람의 기록을 숨겨놓더라도 데이터 접근 경로에서 소유자를 확인하지 않으면 문제가 될 수 있다. **보여주지 않는것과 접근할 수 없는것은 구분해야한다.**

AI가 작성한 코드에서도 같은 기준으로 확인하면 된다. 버튼이 눌리는지만 보는것보다 데이터가 어디에 저장되고 어떤 조건으로 읽히는지 살펴보는게 중요하다.

결국 생성 속도가 빨라졌다면 남는 시간을 이런 검증에 써야할것 같다. 화면이 빨리 나온다는 이유로 검증까지 건너뛰면 나중에 더 크게 고생할 수 있다.

# 4. AI 기능을 추가할때도 확인할게 있다

발표에서는 앱에 LLM 기반 기능을 붙이는 흐름도 소개했다. 독서 기록 앱이라면 메모를 요약하거나 기록에서 자주 등장하는 주제를 정리하는 기능을 생각해볼 수 있다.

이때는 AI 기능이 실패해도 원래 기록을 저장하고 읽는 기능은 사용할 수 있게 나누는게 좋겠다.

```text
독서 기록 저장 → 저장 결과 표시
                     ↓
                 요약 요청
                     ↓
        성공하면 표시 / 실패하면 다시 시도
```

요약 응답을 기다리느라 기록 저장까지 실패한것처럼 보이면 사용자는 무엇이 저장됐는지 알기 어렵다.

또한 메모에 없는 내용을 만들어내거나 지나치게 긴 응답을 반환하는 경우도 생각해야한다. 결과를 그대로 확정하기보다 원문과 함께 보여주거나 사용자가 수정할 수 있게 만드는 방법이 있다.

호출 횟수와 실패 처리도 확인 대상이다. AI 추론이 내장되어있다고 사용량과 비용을 신경쓰지 않아도 되는것은 아니다. 구체적인 제한은 이용 시점의 조건을 봐야한다.

# 5. 개발자가 신경쓸 부분은 어떻게 바뀔까

이런 도구를 보면 이제 개발자는 필요없는건가 싶은 생각이 들 수도 있다. 그런데 앱을 계속 운영할거라면 판단해야할 문제는 여전히 남는다.

독서 기록 앱만 해도 사용자별 데이터 분리, 중복 저장, 삭제 범위, AI 요약 실패 같은 기준을 누군가는 정해야한다. 요구사항이 모호하면 코드도 그만큼 모호해질 수 있다.

개인적으로는 반복적인 화면을 처음 만드는 시간은 줄이고, 무엇을 만들어야하는지와 제대로 만들어졌는지 확인하는 비중이 커지는 흐름으로 보인다.

Spark가 제시한 Repository 연결도 같은 맥락으로 볼 수 있다. 처음 만드는 단계에서 끝내지 않고 수정과 검증을 이어갈 수 있어야 실제 프로젝트가 된다.

# 마무리

이번 발표에서 중요하게 보이는건 자연어로 앱이 만들어진다는 사실만은 아니다. 만든 결과물을 코드와 저장소로 이어서 다룰 수 있다는 점도 같이 봐야할것 같다.

그렇다고 자동 생성한 앱을 바로 완성품으로 보면 안된다. 요구사항을 정하고 데이터를 확인하고 실패 상황을 검증하는 일은 그대로 남는다.

앱의 첫 화면은 금방 만들 수 있어도 그걸 계속 믿고 사용하게 만드는건 또 다른 일인것 같다.. 개발 도구가 바뀌어도 결국 내가 만든 기능이 어떤 상황에서 어떻게 동작하는지는 설명할 수 있어야겠다.


[2025.07.25 주간 개발 트렌드] GitHub Spark 정리 (앱 생성, Repository 연결, 검증할것)

독자의 메모