SOFT GROUND Blog
블로그 목록
SW 개발 연대기

2025년 개발 연대기: AI가 답변을 넘어 행동하고 연결 표준이 자라다

Responses API와 Agents SDK, MCP 생태계 확산, Java 25 LTS, Kubernetes 1.34와 국가정보자원관리원 화재로 2025년의 개발 흐름을 살펴봅니다.

2026년 7월 24일약 17분
#2025#AI Agent#Responses API#MCP#Java 25#Kubernetes#국가정보자원관리원#개발 연대기

2025년 생성형 AI의 중심 질문은 ‘무엇을 답할 수 있는가’에서 ‘어떤 도구를 사용해 일을 끝낼 수 있는가’로 이동했다. OpenAI는 Responses API와 Agents SDK를 공개해 검색, file 조회, computer use와 여러 agent의 handoff를 application 안에서 구성할 수 있게 했다. Anthropic이 2024년 말 공개한 Model Context Protocol(MCP)은 2025년에 여러 AI product와 개발 도구로 빠르게 확산됐고, 연말에는 Linux Foundation 산하 재단으로 이관됐다.

기존 platform도 멈추지 않았다. Java는 탄생 30주년에 Java 25를 내놓았고, 대부분의 vendor가 장기지원 대상으로 삼는 release에 간결한 입문 문법과 scoped value를 정식 기능으로 담았다. Kubernetes 1.34는 pod 수준 resource 요청과 Dynamic Resource Allocation을 정식 기능으로 올리며 AI accelerator를 포함한 복잡한 자원 운영을 다듬었다.

국내에서는 9월 국가정보자원관리원 대전 본원의 배터리 화재로 정부 service가 중단됐다. software defect가 아니더라도 전력과 storage, 물리적 공간의 사고가 수많은 digital service를 함께 멈출 수 있다는 사실을 드러냈다. AI가 외부 system에 더 많은 행동을 위임받은 해일수록, 권한 통제와 관찰 가능성, 복구 가능한 infrastructure가 함께 중요해졌다.

2025년을 보여주는 장면

분야주요 변화개발자에게 생긴 의미
AI agentResponses API·Agents SDK 공개model, 내장 tool, handoff와 trace를 하나의 실행 흐름으로 구성
AI 연결 규격MCP 생태계 확산·재단 이관AI application과 data·tool 사이의 연결 방식을 공통 protocol로 표현
JavaJava 25 GA·LTS 제공간결한 source file, module import와 scoped value를 정식 기능으로 사용
container 운영Kubernetes 1.34pod 단위 resource 관리와 특수 hardware 할당 기능의 안정화
국내 infrastructure국가정보자원관리원 화재물리 장애를 포함한 격리, backup, 재해 복구와 service dependency 관리의 중요성

Responses API와 Agents SDK, model 호출이 작업 실행 흐름이 되다

OpenAI는 3월 11일 agent application을 위한 Responses API, 내장 web search·file search·computer use tool과 open source Agents SDK를 발표했다. Responses API는 Chat Completions의 비교적 단순한 호출 방식과 Assistants API의 tool 사용 능력을 결합한 새 API primitive였다. 하나의 응답 안에 message와 tool call 같은 item을 담고, 여러 model turn과 tool 사용을 이어 갈 토대를 제공했다.

Agents SDK는 agent의 instruction과 tool을 정의하고, 한 agent가 다른 agent에게 작업을 넘기는 handoff, input·output guardrail과 실행 trace를 구성하도록 했다. 5월에는 Responses API가 remote MCP server, image generation과 Code Interpreter를 tool로 지원했고, 오래 걸리는 작업을 비동기로 처리하는 background mode도 추가했다.

from agents import Agent, Runner, function_tool

@function_tool
def find_chronicle(year: int) -> str:
    return f"{year}년 개발 연대기"

agent = Agent(
    name="연대기 안내",
    instructions="요청한 연도의 글을 찾습니다.",
    tools=[find_chronicle],
)

result = Runner.run_sync(agent, "2025년 글을 찾아줘")

이 변화는 단순한 SDK 유행보다 application 구조의 변화를 뜻했다. 이전의 chatbot은 대체로 질문 하나와 답변 하나를 연결했지만, agent는 목표를 해석하고 검색한 뒤 결과를 읽고 다른 tool을 호출하는 여러 단계를 수행했다. 개발자는 prompt만 작성하는 사람이 아니라 tool contract, 상태 전이, timeout, retry와 승인 지점을 설계해야 했다.

발표 당시의 제공 상태도 구분해야 한다. web search는 preview였고 computer use는 일부 이용 등급에 제공된 research preview였다. 특히 OpenAI가 공개한 OSWorld 성공률은 38.1%였으며, 회사도 실수를 고려한 human oversight를 권고했다. demo에서 동작한 기능을 중요한 업무에 곧바로 무인 배치할 수준으로 해석할 수는 없었다.

agent가 사용할 수 있는 tool은 곧 권한이다. 조회와 수정 tool을 나누고 최소 권한 credential을 사용하며, 송금·발송·삭제처럼 되돌리기 어려운 행동은 실행 직전에 사람의 확인을 받아야 한다. 같은 요청이 재시도돼도 중복 처리되지 않는 idempotency, 전체 tool call을 남기는 audit log, 비용과 실행 횟수 제한도 product 요구사항이 됐다.

MCP, AI와 외부 system 사이의 공통 연결 규격

MCP의 최초 공개는 2025년이 아니다. Anthropic은 2024년 11월 25일 AI assistant를 data source와 연결하는 open protocol로 MCP를 공개했다. 2025년에 주목할 변화는 이 규격이 한 회사의 제안을 넘어 여러 model provider와 개발 도구가 채택하는 연결 층으로 성장했다는 점이다.

MCP는 client가 server가 제공하는 tool, resource와 prompt를 발견하고 정해진 message 형식으로 이용하게 한다. database, source repository, document service마다 AI application 전용 adapter를 반복해서 만드는 문제를 줄이고, 하나의 server를 여러 host에서 재사용할 수 있게 했다. OpenAI가 5월 Responses API에 remote MCP server 지원을 넣은 것도 이 확산을 보여줬다.

12월 9일 Anthropic은 MCP를 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 기증한다고 발표했다. Anthropic, Block과 OpenAI가 재단을 공동 설립했고 Google, Microsoft, AWS, Cloudflare와 Bloomberg가 지원에 참여했다. Anthropic은 당시 1만 개가 넘는 공개 MCP server가 활동하고 ChatGPT, Cursor, Gemini, Microsoft Copilot과 Visual Studio Code 등이 MCP를 채택했다고 집계했다. 이는 vendor가 발표한 수치이지만, protocol의 관리 주체를 중립적 재단으로 옮긴 사건 자체는 생태계의 성격이 달라졌음을 보여준다.

공통 protocol이 security를 자동으로 해결하지는 않는다. 사용자가 설치한 MCP server가 어떤 command와 data에 접근하는지, tool description을 신뢰할 수 있는지, server response에 prompt injection이 섞였는지를 검증해야 한다. remote server에는 인증과 전송 보안, tenant 격리와 data 유출 방지가 필요하다. 연결 비용이 낮아진 만큼 신뢰하지 않는 연결을 추가하는 비용도 낮아졌다.

Java 25, 30년 된 platform이 입문과 동시성 모델을 다듬다

OpenJDK의 JDK 25는 9월 16일 general availability에 도달했다. Oracle은 Java 25를 최소 8년 지원하는 LTS offering으로 발표했고, OpenJDK는 대부분의 vendor가 이 version을 장기지원 release로 제공할 것이라고 설명했다. Java 21 이후 2년 만의 LTS 기준점이었다.

Java 25에는 18개의 JEP가 포함됐다. Compact Source Files and Instance Main Methods는 작은 program을 만들 때 class 선언과 복잡한 public static void main 형식을 줄였다. Module Import Declarations는 module이 export하는 package를 한 번에 import할 수 있게 했고, Flexible Constructor Bodies는 constructor에서 super()나 this()를 호출하기 전에 field를 참조하지 않는 검증 code를 실행할 수 있게 했다.

void main() {
    println("Java 25");
}

이 간결한 형태는 기존 class 기반 Java를 없앤 별도 언어가 아니었다. 초보자와 짧은 program은 작은 문법으로 시작하고 필요할 때 일반 class 구조로 확장할 수 있게 한 변화였다.

Scoped Values도 정식 기능이 됐다. 하나의 값을 method parameter로 계속 전달하지 않고도 특정 실행 범위와 그 안에서 생성한 작업에 안전하게 공유하도록 했다. virtual thread 환경에서 mutable한 ThreadLocal을 무분별하게 복제하는 비용과 추론의 어려움을 줄이는 선택지였다. 반면 Structured Concurrency는 Java 25에서도 다섯 번째 preview였고, primitive type pattern matching은 세 번째 preview, Vector API는 열 번째 incubator였다. LTS에 포함됐다는 이유만으로 이 기능들을 모두 영구 확정 API라고 부를 수는 없다.

Java 25에는 post-quantum cryptography를 위한 Key Derivation Function API, JFR profiling 개선, ahead-of-time cache 사용성 개선과 compact object header도 들어갔다. 장기지원 version은 새 문법보다 조직의 migration 기준으로 더 큰 의미가 있었다. library·framework 호환성, garbage collector와 성능, removed API를 시험하고 운영 기준 version을 Java 17이나 21에서 25로 옮길지 결정하는 시점이 됐다.

Kubernetes 1.34, workload가 요청하는 자원을 더 정확히 표현하다

Kubernetes 1.34 ‘Of Wind & Will’은 8월 27일 공개됐다. 이 release에는 58개 enhancement가 포함됐고 그중 23개가 stable에 도달했다. container orchestration이 새로운 개념을 증명하던 단계를 지나, 운영자가 복잡한 workload의 자원과 장애를 더 정확히 다루는 방향으로 진화한 모습이었다.

Pod Level Resources는 CPU와 memory 요청·제한을 container별로만 합산하지 않고 pod 전체에 선언할 수 있게 했다. sidecar와 main container가 시간대별로 서로 다른 자원을 쓰는 경우 pod 안에서 여유 자원을 공유할 수 있어, scheduling 의도를 더 직접적으로 표현했다.

Dynamic Resource Allocation도 stable이 됐다. GPU, accelerator와 network device처럼 단순한 정수 개수만으로 표현하기 어려운 hardware를 claim과 device attribute에 따라 할당하는 framework다. AI workload가 늘며 model code뿐 아니라 어떤 accelerator를 어떻게 배정하고 회수할지가 platform engineering의 핵심 문제가 됐음을 보여줬다.

기능의 stable 승격이 cluster upgrade의 무위험을 뜻하지는 않는다. API deprecation, admission policy, CNI·CSI와 observability component 호환성을 확인하고 control plane과 worker를 단계적으로 올려야 한다. workload별 canary와 rollback 경로, resource quota도 여전히 운영팀의 책임이었다.

국내: 국가정보자원관리원 화재가 드러낸 물리적 단일 장애점

행정안전부 발표에 따르면 9월 26일 오후 8시 15분경 국가정보자원관리원 대전 본원의 배터리에서 화재가 발생했고, 본원에 입주한 정부 service가 중단됐다. 이 사건은 cyberattack이나 application 배포 실패가 아니라 data center의 물리적 사고가 digital government의 가용성 문제로 번진 사례였다.

cloud와 container를 사용하더라도 실제 system은 전력, battery, cooling, network와 storage 위에서 실행된다. 논리적으로 여러 service를 나눴어도 같은 건물, 전력 계통이나 storage에 의존하면 하나의 사고가 공통 원인이 될 수 있다. architecture diagram에는 server와 API뿐 아니라 availability zone, backup의 물리 위치와 복구 순서를 함께 표시해야 한다.

재해 복구는 backup file의 존재만으로 완성되지 않는다. 목표 복구 시점인 RPO와 목표 복구 시간인 RTO를 service별로 정하고, 별도 장애 영역에 보관한 backup에서 실제로 복원되는지 정기적으로 시험해야 한다. 다른 center로 전환할 때 필요한 identity, DNS, certificate와 dependency service까지 함께 준비해야 한다. 국민이 이용하는 service가 많을수록 중요도와 의존 관계에 따른 복구 순서를 미리 합의하는 일도 필요하다.

2023년 지방행정전산서비스 장애가 network component의 부분 고장과 원인 규명의 문제를 보여줬다면, 2025년 화재는 물리 infrastructure와 재해 복구 범위를 물었다. 원인이 달라도 사용자에게 보이는 결과는 service 중단이다. 개발 조직과 운영 조직이 각각의 경계를 넘어 하나의 service continuity를 설계해야 했다.

2025년의 의미

2025년에는 language model을 기존 software 밖의 특별한 대화창으로 다루기 어려워졌다. Responses API와 Agents SDK는 model의 추론을 검색, code 실행과 외부 업무 흐름에 연결했고 MCP는 그 연결을 provider 사이에서 재사용할 수 있는 protocol로 확장했다. 개발의 중심에는 prompt와 model 선택뿐 아니라 권한, tool schema, trace, 평가와 실패 복구가 놓였다.

Java 25와 Kubernetes 1.34는 이런 급격한 변화 옆에서 기존 platform의 역할도 선명하게 했다. 안정적인 release cadence와 preview 절차, resource contract와 단계적 승격은 새 기능을 운영 가능한 기반으로 바꾸는 방식이었다. 빠른 AI 생태계에도 같은 규율이 필요했다.

국가정보자원관리원 화재는 digital service가 물리 세계와 분리돼 있지 않음을 확인시켰다. 2025년의 개발자는 AI agent가 무엇을 할 수 있는지뿐 아니라, 연결한 tool이 실패하거나 기반 시설이 사라졌을 때 어떤 상태로 멈추고 어떻게 되돌아올지도 설계해야 했다.

참고 자료

블로그 목록으로 돌아가기