[2025.10.17 주간 개발 트렌드] Node.js 25 정리 (권한 모델, Web API, Current)

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

# Agent 개발이 애플리케이션 개발로 넓어지고있다

모델에게 질문하고 답변을 받는 기능은 비교적 간단하게 시작할 수 있다. 그런데 실제 서비스에 붙이면 작업 상태와 도구 호출, 인증, 사용자 화면까지 확인할게 늘어난다.

이번주 10월 6일에 OpenAI가 [AgentKit](https://openai.com/index/introducing-agentkit/)과 ChatGPT Apps SDK를 공개했다. 같은날 Codex도 정식 출시됐다.

이번주에는 모델 API 하나를 연결하는것에서 Agent를 하나의 제품으로 만드는 방향으로 개발 범위가 넓어지는 흐름을 정리해보려고 한다.

# 1. AgentKit은 무엇을 묶었나

AgentKit에는 워크플로를 시각적으로 구성하는 Agent Builder, 제품에 대화형 UI를 넣는 ChatKit, 연결을 관리하는 Connector Registry 등이 소개됐다. 평가 기능도 함께 확장됐다.

```text
Agent 서비스
├── 작업 흐름
├── 도구와 데이터 연결
├── 사용자 인터페이스
└── 실행 결과 평가
```

여기서 모든 구성 요소가 같은 출시 상태인것은 아니다. 이번 발표 기준으로 ChatKit과 새 Evals 기능은 GA이고 Agent Builder는 Beta다. Connector Registry도 일부 고객 대상으로 Beta 배포를 시작한다.

도구가 묶였다는 이유로 상태 차이까지 없어지는것은 아니다. 운영에 사용하려면 우리 계정에서 사용할 수 있는 기능과 필요한 조건을 먼저 확인해야한다.

개인적으로는 Agent의 성능을 모델 답변 하나로만 보지 않고 작업 흐름과 UI, 평가까지 묶어서 다루는 부분이 눈에 들어왔다.

# 2. 워크플로를 그리는것과 잘 실행되는것은 다르다

예를 들어 사내 문서를 찾아 답변하는 Agent를 만든다고 해보자. 단순히 검색 도구와 모델을 연결하는것에서 끝나지 않는다.

```text
질문 받기
  ↓
사용자 접근 범위 확인
  ↓
문서 검색
  ↓
답변 구성
  ↓
근거와 결과 표시
```

문서가 없을때와 검색 서비스가 실패했을때는 다른 결과가 필요하다. 접근할 수 없는 문서를 찾은 경우도 별도로 처리해야한다.

흐름을 시각적으로 만들 수 있다면 이런 분기를 이야기하기는 쉬워질 수 있다. 그래도 각 단계의 입력과 출력, 실패 조건은 개발자가 정해야한다.

같은 요청을 다시 실행했을때 어떤 단계부터 이어갈지도 생각해보자. 검색을 다시 하는것과 외부 시스템에 동일한 변경을 다시 보내는것은 결과가 다를 수 있다.

화면에 노드가 연결됐다는 사실보다 실제 사용자의 요청이 성공과 실패 경로를 어떻게 지나가는지 설명할 수 있어야겠다.

# 3. Apps SDK는 어디에 들어가나

[Apps SDK](https://openai.com/index/introducing-apps-in-chatgpt/)는 ChatGPT 안에서 외부 서비스의 도구와 인터페이스를 연결하기 위한 SDK로 Preview 상태로 공개됐다. MCP를 기반으로 서비스의 기능과 UI를 대화 안에 제공하는 구조다.

AgentKit으로 우리 제품의 Agent 흐름을 구성하는것과 ChatGPT 안에 앱을 연결하는것은 사용되는 위치가 다르다. 이름이 같이 발표됐다고 같은 도구로 생각하면 헷갈릴 수 있다.

예를 들어 도서 검색 서비스를 연결한다고 해보자. 자연어로 검색 조건을 받고 결과를 카드로 보여준 다음, 사용자가 특정 도서를 선택하는 흐름을 생각할 수 있다.

```text
사용자의 대화
    ↓
앱의 검색 도구
    ↓
결과 목록 UI
    ↓
선택한 항목으로 다음 작업
```

이때 도구의 반환값은 모델이 이해하기 쉬워야하고 화면도 사용자가 선택하기 쉬워야한다. 텍스트만 길게 반환하는 방식과 직접 누를 수 있는 목록을 제공하는 방식은 사용 경험이 다르다.

기존 서비스의 로그인과 권한도 연결해서 생각해야한다. 대화가 편해졌다고 사용자별 데이터 접근 범위가 달라지는것은 아니다.

# 4. 평가는 답변 점수만으로 충분할까

Agent가 도구를 여러번 호출하면 마지막 문장이 그럴듯한지만 확인하기 어렵다. 답은 맞았는데 불필요한 요청을 반복했거나, 실패를 숨기고 완료한것처럼 말할 수도 있다.

이번 AgentKit 발표에서는 데이터셋과 trace grading 같은 평가 기능도 강조됐다. 실행 경로까지 살펴보는 방향이다.

우리 서비스에서는 어떤 결과를 성공으로 볼지 먼저 정하면 좋겠다.

| 확인할 항목 | 예시 |
| --- | --- |
| 결과의 정확성 | 요청한 문서를 제대로 찾았는가 |
| 도구 사용 | 필요한 도구를 올바른 인자로 호출했는가 |
| 실패 처리 | 검색 실패와 결과 없음을 구분했는가 |
| 비용과 시간 | 불필요한 호출을 반복하지 않았는가 |

테스트 질문에는 성공하기 쉬운 사례뿐 아니라 정보가 부족하거나 요구가 모호한 사례도 넣어보자. 이때 질문을 다시 해야하는지, 가능한 범위의 결과를 보여줘야하는지 기준이 필요하다.

워크플로를 수정했다면 이전 사례를 다시 실행해보는것도 중요하다. 새로운 예시 하나가 좋아졌다고 기존 요청까지 모두 좋아졌다고 보기는 어렵겠다.

# 5. Codex GA도 같은 흐름으로 보인다

같은날 [Codex의 GA](https://openai.com/index/codex-now-generally-available/)와 SDK, 관리 기능 등이 발표됐다. 코딩 Agent도 개인이 명령을 내리는 도구에서 팀의 작업 흐름 안으로 들어오는 방향이다.

개발 환경에서는 저장소를 읽고 코드를 수정하는것 다음에 테스트 결과와 변경 이유를 확인해야한다. Agent 서비스에서도 도구 호출 다음에 결과를 검증해야한다는 점은 비슷하다.

도구를 선택할때는 데모를 얼마나 빨리 만들 수 있는지와 함께 운영 중에 실패 원인을 찾을 수 있는지도 살펴보면 좋겠다.

예를 들어 문제가 생긴 실행을 다시 추적할 수 있는지, 어떤 버전의 워크플로가 사용됐는지, 도구의 오류가 어디서 발생했는지 확인할 수 있어야한다. 이런 정보가 없으면 모델 문제와 애플리케이션 문제를 구분하기가 어렵다.

# 마무리

이번 소식은 Agent 개발이 프롬프트와 모델 선택을 넘어 워크플로, UI, 연결, 평가를 포함하는 애플리케이션 개발로 넓어지고있다는 느낌이다.

개인적으로는 어떤 도구가 코드를 덜 작성하게 해주는지보다 결과를 확인하고 개선하는 흐름을 얼마나 잘 제공하는지가 중요할것 같다.

우선 작은 업무 하나를 골라 성공 조건과 실패 경로부터 적어보면 좋겠다. 도구를 연결하는 속도만큼 완성된 작업을 설명할 수 있는지도 확인해봐야겠다..


[2025.10.10 주간 개발 트렌드] AgentKit과 Apps SDK 정리 (워크플로, UI, 평가)

독자의 메모