오라클 공짜 서버 쓴다면…

당신이 매달 공짜로 굴리던 그 서버, 오늘 아침에도 어제와 같은 사양일까. 늘 쓰던 IDE의 창과 탭은 정말 최선의 작업 공간일까. 그리고 AI가 당신의 받은편지함을 대신 읽기 시작하면, ‘진짜 발신자’는 누가 보증해 줄까. 오늘 GeekNews 상위권에 오른 세 글은 공교롭게도 개발자가 매일 기대고 있는 인프라 — 무료 클라우드, 코드 에디터, 이메일 — 가 조용히, 그러나 거의 동시에 재편되고 있음을 보여준다. 하나는 비용의 문제이고, 하나는 작업 공간의 패러다임이며, 마지막은 신뢰의 토대다. 셋을 이어 읽으면 2026년 개발 환경이 어디로 향하는지 윤곽이 잡힌다.

TOP1. 오라클 ‘Always Free’ 서버, 오늘부터 반토막

4 OCPU·24GB에서 2 OCPU·12GB로, 6월 15일부터 적용

오라클 클라우드가 ‘Always Free’로 제공하던 Ampere A1(Arm) 인스턴스의 무료 한도를 기존 최대 4 OCPU + 24GB 메모리에서 최대 2 OCPU + 12GB 메모리로 축소한다. 적용 시점은 6월 15일 — 바로 오늘이다. 새 기준을 초과한 사용량에 대해서는 표준 요금이 부과되거나 사용이 강제로 중지된다. 다만 AMD EPYC 기반 인스턴스(최대 1 OCPU + 1GB 메모리)는 이번 축소 대상에서 제외됐다. 변경 사실은 오라클 지원팀을 통해 확인됐고, 관련 레딧 스레드에서 사용자들이 같은 통지를 공유하며 빠르게 퍼졌다.

기존 사양을 유지하려면 월 27달러 — ‘공짜 홈랩’의 끝

GeekNews 댓글에서 한 사용자는 축소 이후에도 기존 사양(코어 2개 + 메모리 12GB 추가분)을 그대로 유지하려면 유료 계정 기준 한 달 약 27달러(코어 2개 15달러, 메모리 12GB 12달러)가 더 든다고 계산했다. 오라클의 넉넉한 무료 티어는 수년간 취미 서버, 개인 홈랩, 소형 봇, 사이드 프로젝트를 무료로 굴리려는 개발자들에게 사실상의 표준 선택지였다. 4코어·24GB Arm 서버를 평생 공짜로 쓸 수 있다는 점이 그 매력의 핵심이었던 만큼, 이번 조정은 한 시대의 분기점처럼 받아들여지고 있다.

TOP2. 창과 탭을 버린 IDE ‘Cate’ — 무한 캔버스 위의 개발 환경

에디터·터미널·브라우저·AI 에이전트를 한 캔버스에

Cate는 무한 캔버스 위에 에디터, 터미널, 브라우저, 문서, AI 에이전트를 자유롭게 펼쳐 배치하는 데스크톱 IDE다. 창과 탭이라는 익숙한 구조 대신 자유로운 공간형(freeform space) 작업 영역을 제공하는 것이 핵심이다. 무한 줌과 팬, 네 방향 도킹, 패널을 별도 OS 창으로 분리하기, 저장된 레이아웃, 다중 프로젝트 세션 복원을 지원하고, 폴더를 다시 열면 이전 레이아웃을 통째로 복원한다. 폴더를 여는 순간 곧바로 워크스페이스가 되며, 우클릭으로 패널을 추가하고 Cmd+K 명령 팔레트와 도킹 드래그로 화면을 구성하는 ‘설정 파일 없는(No config)’ 방식이다. 에디터는 Monaco(구문 강조·멀티 커서·diff·마크다운 미리보기), 터미널은 네이티브 xterm.js를 쓰고 PDF·DOCX·이미지용 문서 패널도 갖췄다.

인앱 에이전트 ‘Pi’와 워크스페이스로 제한된 보안 경계

Cate에는 채팅 스레드와 채팅별 모델 메모리를 갖춘 인앱 코딩 에이전트 ‘Pi’가 탑재돼 있다. Anthropic, OpenAI Codex, OpenRouter, Groq 등을 OAuth나 API 키로 연결해 쓸 수 있다. 보안 측면에서는 모든 IPC를 컨텍스트 격리 preload 브리지로 처리하고, 파일시스템 접근을 워크스페이스 루트로 제한하며, 브라우저 패널의 node 통합을 끄고 터미널이 승인된 디렉터리 밖에서 프로세스를 생성하지 못하도록 막는 보안 경계를 적용했다. git 파일 트리는 실시간 감시를 지원하고, 소스 컨트롤 사이드바에서 스테이징·브랜치·worktree·히스토리·인라인 diff를 다룬다. 라이선스는 MIT다.

TOP3. AI가 받은편지함을 대신 읽는 시대, 이메일 인증이 인프라가 된다

SPF·DKIM·DMARC, 그리고 발신자 검증의 부상

Fastmail은 AI가 받은편지함을 읽고 요약하며 작업까지 수행하는 환경에서는 ‘발신자 검증’이 이메일 신뢰의 핵심 조건이 된다고 진단한다. 이메일 인증은 세 가지 맞물린 표준으로 이뤄진다. SPF는 메시지를 보낸 서버가 해당 도메인을 대신해 발송할 권한이 있는지 확인하고, DKIM은 각 메시지에 암호화 서명을 붙여 전송 중 변경 여부를 검증하며, DMARC는 둘을 묶어 검사에 실패한 메시지를 거부할지·격리할지·통과시킬지 수신 서버에 지시한다. Google과 Yahoo가 2024년 초 대량 발송자에게 DMARC 구성을 요구하면서, 인증은 ‘하면 좋은 것’에서 받은편지함에 도달하기 위한 기본 전제로 바뀌었다. 글은 이 흐름을 웹의 HTTPS에 빗댄다. 모범 사례에서 기대사항으로, 다시 인프라로 자리 잡은 경로다. 검증된 발신자가 받은편지함에 로고를 직접 표시하는 BIMI 같은 표준도 그 위에서 만들어지고 있다.

인증이 신원은 확인해도 ‘의도’는 막지 못한다

Fastmail은 자사 받은편지함에 AI를 통합하지 않았고 사용자 메일을 백그라운드에서 모델로 처리하지 않으며, MCP 서버는 사용자가 명시적으로 승인해야만 연결되는 선택적 엔드포인트라고 강조한다. 그러면서도 인증이 도메인 신원은 확인하지만 ‘의도’까지 보장하지는 못한다고 인정한다. 그럴듯한 유사 도메인에 DMARC 레코드를 제대로 갖춘 사기꾼은 발신자 인증을 통과할 수 있기 때문이다. Hacker News 토론에서는 더 날카로운 반론이 나왔다. 가장 큰 위협은 위조 도메인이 아니라 정상 플랫폼의 악용이라는 것이다. 공격자가 PayPal·Stripe 같은 결제 서비스가 실제로 보내는 메일에 “문제가 있으니 이 번호로 전화하라”는 회사명을 끼워 넣으면, 모든 인증을 통과한 진짜 메일이 피싱 도구가 된다. 인증은 사칭의 비용과 복잡성을 크게 높이지만 완전한 해법은 아니라는 점을 글도, 댓글도 분명히 한다.

관련 글

• 100% 일하는 사람 지금 멈춰 — 80% 활용률과 Institutional AI
• 벡터DB 쓰는 사람 지금 멈춰 — Supermemory·루프 엔지니어링
• jq 쓰는 사람 지금 멈춰 — 개발자 큐레이션 TOP3
• 코드 잘 짜도 안 되는 이유 — 개발자 생산성의 진짜 변수
• 한국 커뮤니티 운영자 지금 멈춰 — 오늘의 기술 트렌드

출처

1. Oracle Cloud — Always Free Resources (docs.oracle.com)
2. GeekNews — 오라클, Ampere A1 인스턴스 무료 사용 한도 축소
3. Cate — 무한 줌 코딩용 캔버스 IDE (github.com/0-AI-UG)
4. GeekNews — Cate, 무한 줌이 가능한 코딩용 캔버스 IDE
5. Fastmail — The Future of Email (fastmail.com)
6. GeekNews — 이메일의 미래 (토론)