1인 개발자 뉴스 #26 - 2026년 2월 3주차

TL;DR

1. Chrome 144 Temporal API, 드디어 JavaScript 날짜 처리가 바뀌어요

무슨 일이야?

JavaScript 개발하시는 분들이라면 Date 객체 때문에 한 번쯤은 고통받으셨을 거예요. 타임존 변환하다 하루가 사라진다든지, month가 0부터 시작해서 버그를 만든다든지요. 그런데 Chrome 144에서 Temporal API가 정식으로 들어갔어요.

Temporal은 PlainDate, ZonedDateTime, Instant, Duration 같은 명확한 타입을 제공하고, 모든 연산이 불변(immutable)이에요. 기존 Date처럼 .setMonth() 호출했더니 원본이 바뀌어버리는 일이 없는 거죠. Firefox 139에서는 이미 지원하고 있었고, TC39에서 Stage 3까지 올라와서 3월 회의에서 Stage 4(정식 표준) 승격을 목표로 하고 있어요.

1인 개발자에게 왜 중요해?

날짜 처리 라이브러리 의존도를 확 줄일 수 있어요. moment.js(이미 deprecated), date-fns, dayjs 같은 라이브러리를 쓰시는 분들이 많으실 텐데, Temporal이 표준으로 자리잡으면 별도 라이브러리 없이도 타임존, 기간 계산, 캘린더 처리가 가능해져요. 번들 사이즈 줄이는 건 1인 개발자한테 직접적인 이점이거든요.

특히 SaaS를 만드시는 분들이라면 다국가 사용자의 타임존 처리가 훨씬 깔끔해지니까, 새 프로젝트부터는 Temporal 도입을 고려해보세요.

주의할 점

아직 Safari에서는 지원하지 않고, TC39 Stage 3이라 미세한 스펙 변경 가능성은 있어요. 프로덕션 코드에 바로 적용하시기보다는 새 사이드 프로젝트부터 시작해보시는 걸 추천드려요. 폴리필(@js-temporal/polyfill)도 있으니 브라우저 호환이 필요하시면 함께 사용하시면 돼요.

참고: InfoQ - Chrome 144 Ships Temporal API

2. Next.js에 드디어 경쟁자가 나타났어요

무슨 일이야?

React 풀스택 프레임워크 하면 거의 자동으로 Next.js를 떠올리셨을 거예요. 그런데 2026년 들어서 경쟁 구도가 확실히 달라지고 있어요.

SvelteKit은 빌드 타임에 JavaScript를 컴파일해서 번들 크기를 50%까지 줄이고, 별다른 튜닝 없이 Lighthouse 90점대를 찍고 있어요. Remix는 엣지 네트워크(Cloudflare, Deno)에서 TTFB를 30% 정도 빠르게 뽑아내는 데 강점이 있고요. Qwik은 아예 접근이 다른데, JavaScript를 스크롤할 때만 로드해서 100ms 이하의 인터랙티브 시간을 보여줘요. 대시보드 같은 복잡한 앱에서 특히 효과적이에요.

1인 개발자에게 왜 중요해?

선택지가 늘어났다는 건 좋은 소식이에요. Next.js가 여전히 생태계와 레퍼런스에서 압도적이지만, 프로젝트 특성에 맞는 프레임워크를 골라서 시간을 아낄 수 있거든요. 콘텐츠 중심 사이트를 만드시는 분들은 SvelteKit이 빌드 성능에서 유리하고, API 중심의 풀스택 앱이라면 Remix가 데이터 로딩 패턴이 직관적이에요.

“Next.js밖에 모른다"는 상태에서 벗어나면 기술 선택의 폭이 넓어지니까, 사이드 프로젝트 하나 정도는 다른 프레임워크로 시도해보시는 것도 추천드려요.

주의할 점

새 프레임워크로 갈아타는 건 학습 비용이 생겨요. 특히 1인 개발자한테는 이미 익숙한 도구의 생산성이 가장 중요하니까, 기존 프로젝트를 무리하게 마이그레이션하는 건 비추천이에요. 새 프로젝트에서 실험하시고, 생산성이 확실히 나아진다고 느끼면 그때 전환해도 늦지 않아요.

참고: DEV Community - Next.js Finally Has Competition

3. Agoda API Agent - REST/GraphQL을 MCP로 즉시 변환해주는 도구

무슨 일이야?

Agoda 엔지니어링 팀이 API Agent라는 오픈소스 도구를 공개했어요. 핵심은 간단해요 - 기존에 만들어둔 REST API나 GraphQL API를 코드 한 줄 안 쓰고 MCP(Model Context Protocol) 서버로 변환해주는 거예요.

동작 방식이 꽤 영리해요. OpenAPI 스펙(REST)이나 스키마(GraphQL)를 넣어주면, API Agent가 자동으로 스키마를 분석하고 필요한 쿼리를 생성해서 실행해요. 거기에 DuckDB를 내장해서 API 응답 데이터를 SQL로 정렬, 필터링, 조인까지 해준 다음 AI에게 전달하는 구조예요.

1인 개발자에게 왜 중요해?

MCP 서버를 직접 만드시는 분들이라면 아시겠지만, API마다 별도 MCP 서버를 구현하는 게 꽤 번거로운 작업이거든요. API Agent를 쓰면 OpenAPI 스펙만 있으면 즉시 MCP 서버가 생기니까, Claude Desktop이나 다른 AI 도구에서 바로 내 API를 호출할 수 있어요.

예를 들어 개인 SaaS의 관리 API를 MCP로 연결하면, “이번 달 가입자 수 알려줘"라고 AI한테 물어보는 것만으로 데이터를 뽑을 수 있는 거죠. DuckDB 통합 덕분에 API 응답이 복잡하더라도 AI가 깔끔하게 가공해서 보여줘요.

주의할 점

외부에 노출된 프로덕션 API를 바로 연결하시기보다는, 내부 관리용 API부터 시작해보세요. 인증/인가 처리가 어떻게 되는지 먼저 확인하시는 게 안전해요. GitHub에서 스타가 빠르게 올라가고 있으니 커뮤니티 지원은 기대할 수 있어요.

참고: Agoda Engineering - How To Convert Any API to MCP

4. Claude Code 풀스택 개발, 결국 3가지만 있으면 돼요

무슨 일이야?

Wasp 팀에서 Claude Code로 풀스택 앱을 만들 때 실제로 필요한 3가지 요소를 정리한 글을 공개했어요. 서브에이전트, 훅, 플러그인 같은 고급 기능은 대부분 필요 없고, 핵심은 딱 3가지래요.

1. 풀스택 디버깅 가시성 - Claude가 프론트엔드와 백엔드 양쪽 에러를 모두 볼 수 있어야 해요
2. 버전 맞춤 문서 - Claude에게 최신 라이브러리 문서를 제공해야 정확한 코드가 나와요
3. 오피니언이 있는 프레임워크 - 아키텍처 결정을 프레임워크가 해줘야 Claude가 보일러플레이트 고민 없이 바로 구현에 집중할 수 있어요

이 3가지만 갖추면 Claude Code의 기본 도구(탐색, 계획, 읽기, 쓰기, 명령 실행)만으로도 복잡한 풀스택 앱을 만들 수 있다는 결론이에요.

1인 개발자에게 왜 중요해?

AI 코딩 도구를 쓰시는 분들이 “설정을 어떻게 해야 하지?” “어떤 플러그인을 깔아야 하지?“에 시간을 많이 쓰시거든요. 이 글이 말하는 건 결국 환경 구축에 너무 에너지 쓰지 말고, 핵심 3가지에 집중하라는 거예요.

실제로 Next.js, Wasp, Rails 같은 오피니언이 강한 프레임워크를 쓰면 Claude의 코드 품질이 확 올라가요. 프레임워크가 “이렇게 해라"고 정해주니까 AI도 혼란 없이 따라가는 거죠. 1인 개발자한테는 이 시간 절약이 정말 크거든요.

주의할 점

“3가지만 있으면 된다"가 “3가지면 완벽하다"는 뜻은 아니에요. 복잡한 비즈니스 로직이나 외부 API 연동이 많아지면 추가 설정이 필요한 시점이 오거든요. 기본기를 먼저 다지고, 필요할 때 고급 기능을 하나씩 추가하는 접근이 좋아요.

참고: Wasp Blog - Claude Code for Fullstack Development: The 3 Things You Actually Need

5. OpenAI Codex 앱 서버 아키텍처가 공개됐어요

무슨 일이야?

OpenAI가 Codex의 내부 아키텍처를 공개했어요. Codex는 웹 앱, CLI, IDE 확장, macOS 앱 등 여러 곳에서 돌아가는데, 밑바닥에는 전부 같은 “Codex 하네스"라는 에이전트 루프가 돌고 있었거든요.

이걸 어떤 클라이언트에서든 접근할 수 있게 만든 게 “앱 서버"예요. JSON-RPC over stdio(JSONL) 프로토콜을 쓰고, Go, Python, TypeScript, Swift, Kotlin 등 다양한 언어로 클라이언트를 구현할 수 있어요. 에이전트 로직과 UI를 완전히 분리한 거죠. 덕분에 새로운 표면(surface)을 추가할 때마다 에이전트를 다시 만들 필요가 없어요.

1인 개발자에게 왜 중요해?

AI 코딩 에이전트 시장이 “하나의 앱에서만 쓰는 도구"에서 “어디서든 불러쓰는 프로토콜"로 바뀌고 있다는 신호예요. MCP가 도구 호출의 표준이 되고 있다면, OpenAI의 앱 서버는 에이전트 자체를 어디서든 실행할 수 있게 하는 표준을 만들려는 시도예요.

1인 개발자 입장에서는 이런 흐름을 알아두시면 좋아요. CLI에서 쓰던 에이전트를 IDE에서도 같은 컨텍스트로 이어서 작업할 수 있다는 뜻이고, 나중에 직접 AI 도구를 만들 때도 이 패턴을 참고할 수 있거든요.

주의할 점

현재 공개된 건 아키텍처 설계이지, 모든 기능이 오픈소스로 나온 건 아니에요. 실제로 커스텀 클라이언트를 만들어 연동하려면 아직 제약이 있을 수 있으니, 공식 문서가 업데이트되는지 지켜보시는 게 좋아요.

참고: OpenAI - Unlocking the Codex Harness: How We Built the App Server

관련 이전 글

• 1인 개발자 뉴스 #25 - Clawdbot AI 비서, 2026년 CSS 배우기
• 1인 개발자 뉴스 #21 - 시스템 사고 위기, Copilot CLI 비하인드
• 1인 개발자 뉴스 #20 - AI를 개발자로서 실제로 활용하는 법

이번 주 스킵한 소식

엔터프라이즈 전용 솔루션, 소비자 전자제품, 비개발 뉴스 등은 1인 개발자에게 직접적인 도움이 되지 않아 제외했습니다.

1인 개발자 관점에서 기술 소식을 정리하고 있습니다.