GET·POST 시대 끝났다…

RFC 10008. 다섯 자리 숫자 하나가, 25년 넘게 굳어 있던 웹 개발의 기본 습관에 슬그머니 균열을 냈다. 오늘 GeekNews 상위권을 관통하는 키워드는 결국 하나다 — ‘당연하게 써온 기본값을 다시 묻기’. 검색은 꼭 GET이어야 할까, 코딩 에이전트는 터미널 하나에 하나씩이어야 할까, 그리고 낡은 노트북은 정말 버려야만 할까. 오늘은 그 세 가지 질문을 차례로 따라가 본다.

GET도 POST도 아닌, 새 HTTP 메소드 ‘QUERY’

왜 지금 표준이 필요했나

복잡한 검색을 REST API로 처리할 때 우리는 늘 둘 중 하나를 골라야 했다. GET은 필터가 조금만 복잡해져도 URL이 길어져 브라우저·서버의 길이 제한에 걸리고, 비ASCII 문자는 인코딩으로 요청이 부풀며, 배열·중첩 구조를 표현하는 표준조차 없다(예: roles[]=admin 대 roles=admin). 게다가 URL 파라미터는 프록시와 서버 로그에 그대로 남아 민감한 검색 조건을 흘린다. 그렇다고 GET 본문에 조건을 담는 것은 스펙상 금지는 아니지만 프록시·방화벽·브라우저마다 처리가 달라 사실상 못 쓴다.

대안인 POST는 본문을 보낼 수 있지만 비멱등(non-idempotent)으로 정의돼 실패 시 자동 재시도가 안전하지 않고, 중간 장비가 ‘읽기 전용’임을 알 수 없어 캐싱 같은 최적화도 불가능하다. 의미상 리소스를 생성·처리하는 메소드를 검색에 쓰는 것 자체가 RESTful 설계와 어긋난다. RFC 10008로 표준화된 QUERY는 바로 이 틈을 메운다. GET처럼 안전(safe)하고 멱등하면서, 동시에 요청 본문을 담을 수 있는 메소드다. 캐싱도 가능하되 본문을 캐시 키에 포함해야 하므로 구현은 GET보다 까다롭다. 한 줄로 줄이면 ‘읽기 전용 요청에서 POST를 대체한다’가 핵심이다.

다만 현실은 차분하게 봐야 한다. 클라이언트·프록시·서버의 QUERY 지원은 아직 제한적이라 완전한 정착에는 시간이 걸린다. 단순 파라미터로 충분한 검색은 굳이 바꿀 필요가 없고, 필터 결과 URL을 그대로 공유하거나 북마크해야 한다면 여전히 GET이 낫다. GeekNews에서도 “프록시·방화벽까지 적용되려면 10년은 걸릴 것”이라는 댓글과 “GET의 모호함을 표준이 정리해준 것”이라는 평가가 동시에 달렸다.

AI 코딩 에이전트 여러 명을 한 창에서 지휘하다 — Orch term

‘터미널 하나에 에이전트 하나’라는 답답함에서 출발

개발자 zendy가 GeekNews에 공개한 Orch term은 터미널·코드 에디터·브라우저·Git을 한 창에 모으고, 그 위에서 Claude Code·Codex·Gemini CLI 같은 여러 AI 코딩 에이전트를 동시에 돌려 조율하는 데스크톱 앱이다(Windows·macOS 지원). 화면은 이진 분할 트리로 자유롭게 쪼개 각 칸에 터미널·에디터·브라우저 탭을 섞어 배치하고, ‘Space’ 단위로 작업 묶음을 전환한다. 내장 에디터, ripgrep 기반 전체 검색(Ctrl+Shift+F), 커밋 로그·그래프·blame·diff·push/pull을 갖춘 Source Control 패널, iframe이 아닌 네이티브 자식 웹뷰 기반 인앱 브라우저까지 한 창에 들어 있다.

핵심은 두 가지다. 첫째, 각 Space의 칸반식 할 일 보드를 앱 안의 AI 에이전트가 MCP로 직접 읽고 쓴다. 에이전트가 자기 진행 상태를 todo로 갱신하고 사람은 그대로 보며 조율하니, 할 일 목록이 사람과 에이전트의 공통 작업판이 된다. 둘째, 워커 에이전트들을 각각 격리된 git worktree에 띄워 병렬로 돌리고, 한 워커가 막히면 다른 워커에 위임해 결과를 되돌린다. 여기에 앱 내부 에이전트를 OpenAI 호환 로컬 HTTP API로 노출하는 ‘AI 게이트웨이’가 더해져, 외부 스크립트가 에이전트를 그대로 호출하고 모든 요청·응답은 날짜별 감사 로그로 남는다.

기술 스택은 Tauri 2(Rust 백엔드)에 TypeScript·Vite, 터미널은 xterm.js(WebGL 렌더러), 저장소는 SQLite, 자동 업데이트 내장이다. 제작자는 네이티브 자식 웹뷰가 메인 스레드를 데드락시키는 함정과 창 복귀 후 키 입력이 끊기는 포커스 버그(결국 wry를 직접 패치), conpty 환경의 한글 IME·이모지 입력 문제를 어려움으로 꼽았다. 아직 코드 서명 전이라 Windows SmartScreen·macOS Gatekeeper 경고가 뜬다는 점은 감안해야 한다.

버리려던 2014년 노트북, Linux로 되살리는 법

느려진 건 하드웨어가 아니라 OS의 요구였다

전 세계가 매년 약 6,200만 톤의 전자폐기물을 쏟아내는데, 그중 상당수는 멀쩡히 작동하는 하드웨어다. Windows 11은 TPM 2.0·Secure Boot·비교적 최신 CPU를 요구해 2014~2019년대의 정상 PC를 대거 지원 대상에서 밀어냈다. 그런데 체감 속도 저하의 진짜 원인은 하드웨어가 아니라 OS의 요구다. 우분투 Xfce 신규 설치는 유휴 상태에서 약 650MB RAM을 쓰지만, Windows 11은 브라우저를 열기도 전에 3~4GB를 쓴다. 경량 Linux 생태계는 2026년에도 활발해, BunsenLabs Carbon(2월, Debian 13 기반·i386 지원 중단), Xubuntu 26.04 LTS(4월, Xfce 4.20·3년 지원), Linux Lite 8.0(6월, 커스텀 성능 커널·내장 게이밍 스택)이 줄줄이 나왔다.

선택의 1차 기준은 RAM이다. 2GB 미만이라면 systemd 없는 antiX(유휴 약 256MB)나 RAM에서 통째로 도는 Puppy Linux가, 2~4GB라면 LXQt 기반 Lubuntu 26.04 LTS(유휴 약 480MB·2029년까지 지원)나 Linux Lite 8.0(유휴 약 650MB·BORE 스케줄러로 반응성 우위)이, 4GB 이상이라면 Xubuntu 26.04나 Linux Mint Xfce가 무난하다. 2014년 ThinkPad T440s 테스트에서 부팅·유휴 메모리는 Lubuntu가, 사용 중 반응성은 Linux Lite가 앞섰다. 데스크톱 환경도 LXQt(약 480MB)·MATE(약 580MB)·Xfce(약 650MB)로 메모리 요구가 갈린다.

하지만 체감 성능은 배포판만으로 결정되지 않는다. RAM 안에 압축 swap을 만드는 zram, HDD라면 swappiness를 60에서 10~20으로 낮추기, 안 쓰는 bluetooth·cups·avahi 서비스 끄기가 누적 효과를 낸다. 가장 큰 한 방은 SSD다. 같은 PC에서 우분투 부팅이 HDD 45~60초에서 SATA SSD 12~18초로, 앱 실행은 5~8초에서 2초 미만으로 줄고, 256GB SATA SSD는 보통 30달러 미만이다. 가장 무거운 앱인 브라우저는 Firefox에서 탭 10개가 2~3GB까지 먹으므로 about:config 손질과 uBlock Origin(광고 많은 페이지 메모리 30~50% 절감)이 사실상 필수다. 일상용으로 너무 느리다면 Pi-hole·Jellyfin 같은 홈 서버로 돌리는 길도 있다. 반대로 32비트 전용 CPU에 1GB 미만 RAM, SMART 불량 섹터, memtest86+ 오류, 가벼운 부하에 90°C 발열이라면 미련 없이 재활용이 답이다.

관련 글

• RFC 10008: 새로운 HTTP QUERY 메서드
• 새로운 HTTP SEARCH 메소드
• agf — AI 코딩 에이전트 세션을 한 곳에서 관리하는 TUI
• Herdr — AI Agent 시대를 위한 tmux 스타일 터미널 워크스페이스
• 이제 Ubuntu가 Windows 11보다 더 많은 기본 RAM을 요구하게 됐다

출처

1. GeekNews — 새로운 HTTP QUERY 메소드 (TOP1)
2. kreya.app — The new HTTP QUERY method, explained
3. IETF Datatracker — RFC 10008
4. GeekNews — Orch term (Show GN, TOP2) · zendy00.github.io
5. FOSS Linux — Reviving old hardware with Linux: 2026 guide (TOP3)