들어가며

요새는 기술적인 내용이나 회고보다는, 그냥 생각 정리에 대한 회고가 많은 것 같다는 생각이 든다. 위 이전글도 그렇고, 대부분의 내 블로그 포맷이 회고 형태로 변한 것 같다. 그정도로 급변하는 시기에 많은 생각들을 하고 고민들이 많아지고 있다.

3년차 주니어인 나에게, 우연한 기회로 사내 기술 면접관으로 들어갈 기회들이 생겼다. 7~8월즘 백엔드 엔지니어 채용과, 10~11월에 Product Engineer 채용을 진행하고 있다. 채용 시장이 어려운만큼 채용 공고를 올리면 정말 많은 이력서들이 온다. 내가 모든 이력서를 검토하지는 않지만, 1차로 걸러져서 오는 이력서들도 100장 남짓 되었던 것 같다.

구직을 위해 거쳐온 면접들이 정말 감사하게도 너무 좋은 경험들이었다. 그렇기 때문에 나도 지원자들에게 좋은 경험으로 남겨드리고 싶었다. 면접 환경부터 시작해서, 간단한 식음료나 자리 세팅, 내가 궁금한 질문들이 잘못되지는 않았을까 다시 검토하며 이력 한 줄에 대한 질문을 하기 위해 서너시간씩 준비했다. 기술적으로 정말 기대되는 이력서는 밤을 새서 준비하기도 했다. 덕분에, 딥다이브 하면서 잊고 지냈던 CS 지식이나 몰랐던 부분들도 채울 수 있었고, 다양한 인사이트를 얻을 수 있었다.

이번 글에서는 그 중에서도 다양한 이력서와 면접자들과의 면접을 통해 이력서에서 나의 PR을, 면접을 어떻게 대비할 수 있을까?

특히 개발자 종말이라는 대 AI 시대에, 어떻게 살아남고 자기PR을 해야할까? 에 대한 생각들을 정리해보려고 한다.

일반적으로 어떻게 하면 좋은 이력서일까? 잘 쓴 이력서이고 가독성이 있을까? 에 대한 부분이나 이렇게 하면 서합률이 높아진다는 다루지 않는다.

이력서의 링크들

이력서에는 다양한 링크들이 있다. 본인의 Github부터 시작해서, Linkedin, 블로그, 포트폴리오 등 정말 다양하다. 아래 사진은 내가 지금 회사에 지원했을 때의 이력서 최상단 내용인데, 나 또한 이력서에 링크를 첨부했다.

이력서는 자기 PR을 하는 일련의 문서라고 생각한다. 그렇기 때문에 이력서에 블로그 주소, 깃허브 주소, 링크드인 주소 등을 게시했다면 내세울만한게 있는가를 돌아봐야한다고 생각한다. 적어도 본인이 피력하는게 꾸준함이라면, 꾸준한가? 를 증명할 수 있는 링크가 되어야하지 않을까? 이번 채용 과정에서 95% 이상의 링크들은 감점요소였다. 2022년에 마지막으로 포스팅한 블로그 링크, 활동 내역이 전혀 없어 관리되지 않은 링크드인, 잔디가 드문드문 있는 1년 100커밋 미만인 깃허브까지.

나도 어디서 내세울만큼의 기술적 깊이나 전문성이 있다고 생각하지는 않는다. 그냥 노력을 남들보다 더 많이하는 부분을 이력서에서 어필했다. 물론 우리 조직의 채용 과정에서 위 사진과 같이 샤라웃해주는 분들이 있을 때는 정말 기분이 좋다. (맞다, 사실 자랑하려고...)

내가 너무 이런 부분에 엄격한 것 일수도 있다. 같은 면접관분들께서는 중요도를 낮게 보시기도 하고, 우스갯소리로 내가 있는 조직에 지원할 때는 링크를 안넣겠다고도 하셨으니까. 뭐가됐든 나는, 본인이 어필하려고 하는 강점을 뒷받침해줄 수 있는 수단으로서 링크를 제공해야한다고 생각했다. 

일관성

본인이 작성한 이력서의 내용과 실제 면접 내용이 다른 경우가 부지기수였다.

나는 문제 정의에 강점이 있다. 그런데 이력서 내용은 그냥 기술적인 내용이 주를 이루고 어떻게 문제를 정의했는지는 적혀있지 않다.

궁금해서 면접에 들어가면, 문제 정의는 정말 두루뭉술하다. 그들의 얘기를 들어보면 대체 이게 뭐가 문제인지 상이 맺히지 않는다. 물론 그들의 환경에서 접해보지 않아 단편적일 수 있으나, 문제를 정의하고 해결하는 과정의 이터레이션에서 발생하는 다른 구성원들과의 Alignment는 정말 중요하다고 생각한다. 설득하거나, 설득당하거나의 과정을 거쳐본게 맞나? 라는 생각이 들었다.

반대로, 기술적인 강점이 있고 정말 다양한 기술들로 사용자의, 혹은 조직의 문제를 해결한 흥미로운 지원자분들도 많이 계셨다.

최근 공부를 시작한 언어를 정말 화려하게 사용한 이력이 있으셔서, 내 질문이 누가 되지 않을까 밤새 준비했다.

막상 면접장에 가보면, 본인이 작업해서 이력서에 자랑스레 적어놓은 내용들의 기본적인 이해도 없는 경우가 더러 있다.
혹은 더 나아가서(?) AI가 이렇게 하라던데요. 라는 얘기도 듣는다. 그래서 개발을 어떻게 하시냐 라고 여쭤보면 어떻게를 AI에게 일임한다는 내용이 대부분이다. 엔지니어로서 어떻게를 계속 AI에게 구체화하지 않고 자율 주행 시켰을 때 쌓이는 부채는 지수적으로 증가하고, 기술적으로 엔지니어가 현재 상황에 맞게 가드레일을 치지 않았을 때 발생하는 상황들을 너무 명확히 경험해왔다. 단순히는 바로 뒤이어 나가는 핫픽스부터, 정말 결함이 되어 문제가 발생할 수도 있다. 성장하고자하는 개발자가 아니더라도, 나는 이 부분은 책임감이라고 생각한다. 오너쉽이 없는 사람들을 채용해서 같이 일을 할 수 있을까..? 의문이다.

마치며

사실 위 두 가지가 해결이 되어야 시작인 것 같다.

자기 PR을 정말 이력서로 잘 해야하고 내가 어떤 사람인지, 그 뒷받침할 증거들이 이력으로, 보조 수단들로 드러나있는가?

그리고 면접장에 방문해서 일관적이게 내 가치관을 기술 면접에 적용할 수 있는가? 하다 못해 정말 그 회사에 들어가고 싶으면, JD나 문화가 맞지 않더라도 일관성 있게 연기라도 할 수 있는가?

사실 이런 부분들은 대 AI 시대가 아니더라도 똑같이 적용될 문제인 것 같다.
JD에 맞춰 매력적인 이력과 이력서를 준비했다면, 가서 증명한다. 이게 전부이고, 채용 시장이 어렵다면 내가 남들보다 매력적이면 된다.

단지 그 뿐인데 AI 시대가 가져다주는 무언가에 사로잡혀 본질을 잊고 있는게 아닌가라는 생각이 든다.

들어가며

8월에 600억 토큰을 사용했다는 회고 글을 남겼던것 같은데 어느새 1100억 토큰을 사용했네요.

특정 사용 방식에 정착해서 사용하다가 때로는 전체 하네스 세팅을 초기화 해보기도하고, 외부에 좋은 레퍼런스들이 있으면 내가 사용하는 방식에 들여올 수 있는지도 검토해보고 직접 사용해보기도 하면서 지냈어요.

오늘 쓰고자하는 글은 더 AI를 잘 다루기 위해서 어떻게 프롬프팅을 하는지, 하네스 세팅이 어떤지, 토큰 최적화를 어떻게 하는지 등을 얘기하지는 않아요. 세션을 많이 다루면서 저는 계속 발산만 하고 있었는데 그러느라 놓친 게 무엇인지, 발산하면서도 수렴하며 성장하려면 저에게 어떤 가드레일을 세워야 할지를 정리하는 글이 될 것 같아요.

낭만이 사라진 시대

10을 하고 10을 이해하던 시절

개발자라면 코드를 짜는 시간보다 설계에 시간을 더 들여야 한다는 말을 많이들 들어 보셨을 거예요. 직접 문제를 정의해서 가설을 세우든 R&R이 명확해서 요구사항이 내려오든, 아키텍트처럼 생각하고 견고하게 설계하려고 했죠.

내 설계에 문제가 없는지 구글링하고 스택오버플로우를 뒤졌고, 설계한 대로 짠 코드가 잘 도는지 검증하다 보면 그 코드가 구조째로 머리에 쏙 들어왔어요. 그 과정에서 자연스럽게 공부가 됐고 엔지니어로서 한 단계 올라선 것 같은 기분도 들었어요.

저는 2022년에 개발을 시작해서 그 시절이 길지는 않아요. 그래도 이렇게 반복하면 계속 성장할 줄 알았고, 개발자는 변화에 빨리 적응하고 새 도구를 언제든 받아들여야 한다는 말도 그때는 그냥 그런 줄 알았어요.

100, 어쩌면 200을 하는 시대

AI 시대에 적응을 못 했냐, 도태됐냐고 묻는다면 아니라고 답하겠습니다. 개인으로도 조직으로도 프론티어는 아니어도 LTS 정도는 되려고 늘 노력해 왔고 지금도 그래요.

달라보이는건 양인 것 같습니다. 예전에는 10을 하면 그 10을 전부 이해하려고 따로 시간을 내서 깊게 공부했는데 지금은 AI 덕분에 더 많이 많이, 200을 하는 시대인지라 하나를 깊게 파야하는데 더 많이 더 빨리 하다보면 놓칠 때가 간혹 있더라구요.

예전에는 누군가 물으면 바로 튀어나오던 것을 이제는 저도 AI에게 컨텍스트를 물어봐야 할 때가 있으니까요. 그래서인지 뭔가 공허한 요즘입니다.

채용

채용에도 변화가

종종 보는 판뚜님의 최근 유튜브 영상에서 이런 주제를 다루더라구요?

문제 정의부터 설계, 관련 지식까지 완벽하게 알고 있는데 코드 자체를 읽는 능력은 없는 사람을 기술 면접에서 합격시킬거냐?

(저는 안 뽑을 것 같아요....)

저희 조직도 성장에 속도를 붙이려고 채용을 하고 있고, 저는 20건 가까운 면접에 면접관으로 들어가고 있어요.

JD와 인재상도 Software Engineer에서 Product Engineer로 바뀌어 가는 게 느껴지고, 엔지니어링 역량 자체보다 고객의 문제를 푸는 데 집착하는 사람을 찾고 있어요.

이 변화를 보고 있으면 또 공허해지더군요... 제가 성장이라고 믿고 갈고닦아 온 기술의 깊이가 채용 기준에서 한 칸 뒤로 밀려나는 것처럼 보였거든요... 이런..

이력서와 면접 사이의 간극

채용때문에 최근에 이력서들을 많이 보게 되는데요, 여전히 기술 내용이 대부분이에요. 본인이 정의한 문제도, 성과도 기술 이슈에서 시작해서 기술 지표로 끝나는 경우가 많습니다. 기술적인 부분이 흥미로운 이력서라 면접에 모셔 오면 막상 어떻게를 AI에게 맡기고 검토하지 않은 분들이 종종 보여요. 기술 질문을 하기 위해 화두를 던지면 AI가 이렇게 하라던데요? 로 말문을 막아버리시는 분들도 종종 계시구요.

기억에 남는 분은, 정말 화려한 기술을 많이 다뤄오셨고 이력서 상에서 너무 멋져보였어요. 비슷한 연차인데 정말 많이 다양하게 하셨구나. 과정에서 어떤 과실을 얻으셨을까? 정말 엄청난 엔지니어겠구나! 하는 기대를 갖고, 도리어 제 질문에 실망하지 않게 하기 위해 정말 준비를 많이 했어요. 새벽 3시까지 준비했던 것 같아요.  하지만 면접장에 들어선 제 이상향 같은 분은 막상 여쭤보니 본인이 했다기보다 AI가 한 일을 옮겨 적은 느낌이라 더 깊이 물어볼 수도 없었어요. 그럼 문제를 풀려고 무엇을 정의했는지라도 보자고 질문을 바꿔 봐도 거기서도 답이 나오지 않는 분이 생각보다 많았어요.

그럼에도 성장해야하지 않을까요

나는 이 시대에 어떻게 맞설 것인가

물론 저도 아직 주니어고, 제가 들어간 면접이 다 좋은 결과로 이어진 것도 아니에요. 그래도 개발자는 꾸준히 성장해야 한다는, 어쩌면 가스라이팅 같던 그 말의 기준이 기술의 깊이에서 고객의 문제를 푸는 쪽으로 옮겨간 걸까 하는 생각이 들어요.

그치만 이 문제 정의는 소프트웨어 공학이 오래 다뤄온 원초적인 주제이자 어쩌면 엔지니어링의 핵심이지 않을까 싶어요. 예시로 프레드 브룩스가 1986년에 쓴 No Silver Bullet 논문의 내용을 가져와봤습니다.

The hardest single part of building a software system is deciding precisely what to build.

결국 무엇을 만들지 정하는 일은 항상 소프트웨어 공학 관점에서도 중요하게, 어쩌면 어려운 일로 다뤄져왔고 지금은 거기에 내 제품이, 조직이 성장하기 위한 임팩트 한 스푼이 가미됐을 뿐인거죠. 저도 어쩌면 이 거대한 AI 파동에 넘실거리며 파도를 타는 한 마리의 생선에 지나지 않았을지도...(?)

마치며

엔지니어의 역량 안에 고객의 문제를 정의하고 해결하는 일이 들어 있고, 그걸 기술로 푸는 사람이 결국 엔지니어입니다. 어떻게의 영역(수단)이 엔지니어링이라면 그 깊이는 계속 채워 나가는 게 맞지 않을까요?  AI가 코드 영역은 이미 대체했다고들 하지만 적어도 내가 설계하고 AI를 시켜 짠 코드는 필요하면 직접 읽고 이해하고 고칠 수 있어야 해요. 직접 코드를 짜던 때처럼 관련 지식도 깊이 알고 있어야 하고요.

AI로 워크플로우가 바뀌기 전에도 지금도 여전히 유효한 얘기이고 강력히 주장합니다. 어쩌면 이건 엔지니어로서의 성장이나 소양보다 책임감의 영역일 수도 있어요. 운영 중인 서비스에 장애가 났을 때 Claude도 Codex도 같이 장애일 수 있다는 경각심은 늘 품고 있어야 하니까요. 설계할 때 트레이드오프와 사이드 이펙트를 늘 따지듯이 말이에요. 

떠들썩했던 PHP2Shell

PHP2Shell은 10월 21일 공개된 PHP 보안 취약점 두 건을 RCE 취약점(CVE-2026-109618 및 CVE-2026-109619) 입니다.

메모리 부족으로 초기화가 중단된 상태를 정리 과정에서 사용하는 문제와 이전 요청에서 해제한 메모리를 이후 요청에서 다시 사용하는 문제에요. PHP2Shell로 최근 세상이 시끌시끌했는데요. 개발자 커뮤니티에서뿐만 아니라 미국이나 일본 정부 등에서 국가 단위의 공식 보도나 SNS로도 즉각 대응이 필요하고 불가능하다면 관련 시스템들을 중단까지 해야한다며 난리가 났었습니다.

이 글에서는 주니어 개발자가 학습을 위한 용도로 이번 PHP2Shell 사례에서 볼 수 있는 PHP의 요청 처리 구조와 메모리 관리와 실패 처리까지 내려가보면서 원인을 분석해보기 위한 글입니다.

PHP2Shell의 영향과 발생 조건

PHP2Shell은 2026년 10월 21일 공개된 PHP 원격 코드 실행 취약점 두 건을 가리킵니다. 원격 코드 실행(RCE)은 외부에서 보낸 요청으로 서버에서 공격자가 원하는 코드를 실행할 수 있다는 뜻이에요.

하나는 메모리 부족으로 중단된 작업의 미완성 데이터를 사용하는 문제이고, 다른 하나는 이전 요청에서 해제한 메모리를 다음 요청에서 다시 사용하는 문제입니다.

공식 공지는 PHP-FPM, Apache의 mod_php 등을 포함해 웹 요청을 처리하는 PHP 환경 전반을 영향 범위로 안내합니다. 다만 환경마다 공격이 가능한 경로와 조건은 다릅니다.

저는 PHP로 서비스를 운영해본 적이 없어, 애플리케이션 코드가 실행되기 전에도 공격이 가능하다는 설명이 먼저 눈에 들어왔습니다. 서버는 이미 실행 중일 텐데, 여기서 말하는 앱 실행 전은 어느 시점일까요?

PHP의 request lifecycle

/profile로 name=Kim이라는 폼 데이터가 들어왔다고 해보겠습니다. 이 요청을 처리할 파일이 profile.php라면, PHP는 그 파일을 실행하기 전에 입력을 해석하고 $_POST['name']으로 Kim을 읽을 수 있도록 배열과 문자열을 준비합니다.

그림의 앱 실행 전이 이 구간입니다. 서버와 PHP 실행 환경은 이미 동작하지만 우리가 작성한 로그인 검사나 입력 검증 코드는 아직 실행되지 않았어요. 이때 실행되는 것은 PHP 자체를 구현한 코드입니다. PHP 소스를 실행하는 Zend Engine과 입력 처리 코드도 프로그램이므로, 요청을 읽고 내부 데이터를 만드는 동안 메모리를 사용합니다.

요청을 처리한 뒤에는 요청에 사용한 자원을 정리합니다. 하지만 PHP-FPM처럼 처리 프로세스인 워커를 재사용하는 구성에서는 프로세스가 종료되지 않고 다음 요청을 받아요. 그래서 같은 워커 안에 요청이 끝나면 없어져야 하는 데이터와 다음 요청에도 남는 상태가 함께 있습니다. 이 두 가지를 기억하고 실제 문제가 생긴 지점으로 들어가보겠습니다.

메모리 부족으로 중단된 초기화 (CVE-2026-109618)

첫 번째 취약점은 CVE-2026-109618입니다. 잘 아시다시피 OOM(Out Of Memory)은 필요한 메모리를 더 확보하지 못한 상태를 말해요. 이 OOM은 서버의 RAM이 전부 소진돼야만 발생하는 것은 아닙니다. PHP가 설정된 memory_limit에 도달해도 OOM을 처리합니다. 수정 전 소스에서는 이 오류 처리 중 zend_bailout()을 호출하고, 그 안에서 LONGJMP를 실행하는 경로를 볼 수 있습니다.

// PHP 8.4.26
// Zend/zend_alloc.c
zend_bailout();

// Zend/zend.c: _zend_bailout() 내부
LONGJMP(*EG(bailout), FAILURE);

longjmp는 미리 저장해둔 실행 지점으로 돌아가는 C의 기능입니다. 함수가 하나씩 return하는 대신 중간 실행 과정을 건너뛰므로, 그 뒤에 예정되어 있던 초기화 코드도 실행되지 않을 수 있어요.

중단 이후에 남은 데이터

공식 보고서에 따르면, 일부 경로에서는 아직 초기화가 끝나지 않은 데이터에 다른 코드가 접근할 수 있었습니다. 그 사이 할당이 실패해 실행을 건너뛰면, 요청 정리 코드가 이 미완성 데이터를 읽거나 조건 판단에 사용하게 됩니다.

문제는 OOM이 발생했다는 사실만으로 끝나지 않습니다. 중단된 시점에는 아직 사용할 수 없던 데이터를, 정리 코드가 사용 가능한 데이터로 다뤘다는 데 있어요. 보고서는 multipart 입력을 처리하면서 내부 자료구조의 메모리 사용량이 커지는 경로를 설명합니다. 애플리케이션 실행 중 할당 실패도 원인이 될 수 있고, 실패한 할당이 미완성 데이터 자체를 위한 할당일 필요도 없습니다.

mod_php는 요청 시작에 실패해도 정리 절차를 호출합니다. 이 경로에서 인증 없이 앱 코드 실행 전에 웹 워커 계정 권한으로 코드를 실행하는 공격이 확인됐습니다.

PHP-FPM은 요청 시작에 실패하면 해당 워커를 종료해 이 경로를 막습니다. 다만 시작 이후의 OOM 경로는 별개이며, 보고서는 첫 번째 취약점의 완전한 FPM 공격까지 입증한 것은 아니라고 밝힙니다.

해제한 메모리를 다음 요청에서 사용 (CVE-2026-109619)

요청 A에서 남긴 참조

두 번째 취약점인 CVE-2026-109619는 실제로 어떤 데이터가 남는지 확인할 수 있습니다. PHP 8.5의 fatal error backtrace, 치명적인 오류가 발생했을 때 남기는 함수 호출 기록이 그 사례입니다. 호출 기록 기능이 켜져 있으면 PHP는 오류가 발생했을 때 EG(last_fatal_error_backtrace)에 기록을 저장합니다. 이름이 길지만 여기서는 엔진이 보관하는 마지막 치명적 오류의 호출 기록이라고 읽으면 됩니다. 이 기록을 담은 메모리는 요청에 속해 있습니다. 요청 A가 끝나면 그 메모리를 해제해야 하고, 엔진에 남은 참조도 더 이상 사용되지 않도록 초기화해야 합니다.

8.5.11에서 이 값을 지우는 코드는 if (!fast_shutdown) 블록 안에 있습니다. 빠른 종료 경로에서는 이 블록을 거치지 않아 호출 기록을 가리키는 값이 남을 수 있었어요. 이후 요청 메모리를 해제해도 남은 참조가 자동으로 지워지지는 않습니다.

요청 B에서 다시 읽는 코드

같은 워커가 요청 B를 받았을 때, 정상적인 초기화보다 먼저 설정 관련 경고를 처리하는 경우가 있습니다. 이때 오류 처리 코드가 이전 호출 기록을 다시 사용합니다.

// PHP 8.5.11, main/main.c: 1389L
if (!Z_ISUNDEF(EG(last_fatal_error_backtrace))) {
    backtrace = zend_trace_to_string(
        Z_ARRVAL(EG(last_fatal_error_backtrace)),
        /* include_main */ true);
}

이 조건문은 기록이 없음 상태인지 확인합니다. 남아 있는 값이 가리키는 메모리가 이미 해제됐는지까지 검사하는 코드는 아니에요. 그 결과, 이미 해제한 메모리를 다시 사용하는 Use-after-free가 발생합니다. 다음 요청에서 초기화하는 코드가 있더라도 그보다 먼저 읽는 코드가 있다면 늦습니다. 메모리를 해제했다고 해서 모든 참조가 자동으로 지워지거나, 그 주소를 읽는 즉시 프로세스가 종료되는 것은 아닙니다. 해당 공간이 다른 데이터에 재사용될 수도 있어요. 공격자가 메모리 배치를 조절해 이 접근을 악용하면 코드 실행으로 이어질 수 있습니다.

호출 기록은 확인된 사례 중 하나입니다. 보고서는 세션 처리 상태 등 다른 경로도 다루며, 두 번째 취약점은 OOM 없이 다른 치명적 오류나 종료 중 경고로도 발생할 수 있다고 설명합니다.

PHP의 정리와 프로세스 종료

두 문제의 수정 방향도 원인과 연결됩니다. 첫 번째 패치는 OOM을 감지하자마자 초기화 중간을 빠져나가는 대신, 여유가 있으면 엔진의 안전 지점까지 중단을 미룹니다. 그 여유까지 소진해 하드 한도에 도달하면 _exit()로 프로세스를 즉시 종료합니다. 이 경로에서는 PHP의 정상적인 요청 정리 절차를 실행하지 않습니다. 두 번째 패치에서는 다음 요청 전에 남은 상태를 지우는 처리를 보강했습니다. 앞에서 본 호출 기록도 종료 과정에서 ZVAL_UNDEF로 없음 상태를 설정하는 코드를 확인할 수 있습니다. 여기서 Linux가 등장하는 이유도 분명해집니다. PHP 안에서 요청 하나를 정리하는 것과, OS가 프로세스 자체를 종료하는 것은 다른 동작이기 때문입니다. Linux의 cgroup은 프로세스들이 쓸 수 있는 메모리를 제한합니다. 한도에 도달한 뒤 회수로 해결하지 못하면 OOM killer가 프로세스를 종료할 수 있지만 이것이 PHP의 내부 참조 오류를 고쳐주는 것은 아닙니다.

다른 언어에서의 메모리 관리

다른 언어였다면 괜찮았을까요? 이번 결함은 PHP 구현에서 발견됐지만 OOM 처리와 데이터 수명 관리는 다른 런타임에서도 필요합니다. Node.js의 V8 OOM 처리 경로는 오류를 기록한 뒤 프로세스를 중단합니다. 이 경로에 들어간 프로세스가 다음 요청을 받지는 않지만 서비스가 중단되는 문제는 남아요. JVM은 힙 메모리가 부족하면 OutOfMemoryError를 발생시킵니다. Java 객체의 메모리는 GC가 관리하므로, 일반적인 Java 코드에서 객체를 직접 해제하고 남은 포인터로 다시 읽는 방식과는 차이가 있습니다. Rust는 소유권과 빌림 규칙으로 해제된 값을 사용하는 코드를 컴파일 단계에서 막습니다. 하지만 unsafe나 외부 C 코드가 잘못 구현됐다면 그 안전성도 깨질 수 있습니다. PHP 개발자도 보통 메모리를 직접 해제하지 않습니다. 이번에 살펴본 곳은 애플리케이션을 실행하고 메모리를 관리하는 PHP 내부의 C 코드였어요.

실패한 뒤에도 실행되는 코드

처음에는 메모리가 부족하면 요청이 실패하고 끝날 거라고 생각했습니다. 그런데 요청을 끝내기 위한 코드도 데이터를 읽고, 남은 상태는 다음 요청의 코드에서 다시 사용될 수 있었습니다. 제가 이번 사례에서 가져가고 싶은 질문은 두 가지입니다. 작업이 중간에 실패해도 정리 코드가 다룰 수 있는 상태인가? 그리고 데이터를 해제한 뒤에도 그것을 가리키는 참조가 남는가?입니다. 앞으로 초기화나 정리 코드를 볼 때도 정상적으로 끝나는 순서만 따라가지는 않으려고 합니다. 중간 단계에서 실패했을 때 무엇이 남고, 누가 그것을 다음에 읽는지까지 확인해봐야겠어요.

마치며

PHP 사건이 터지고 거의 10일 뒤에 글을 쓰는 것 같은데요... AI가 발전함에 따라 더 많은 보안 결함들이 발견되고 있습니다.
Node, JDK를 비롯해서 세계가 시끌시끌해지고 있습니다. 기존에 다들 모르고 지나갔던 것들이 정말 많았겠구나 싶네요. 적어도 한 조직의 개발자로서 제가 만들어나가고 있는 제품은 더 관심을 가지고 보안적인 부분들도 처리하며 공부하는게 필수 요소로 자리잡지 않을까? 라는 생각입니다.

References.

https://www.php.net/archive/2026.php#2026-10-21-5

https://www.php.net/manual/en/reserved.variables.post.php

https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files

https://github.com/nodejs/node/blob/v24.0.0/src/node_errors.cc#L596

https://docs.oracle.com/javase/specs/jvms/se25/html/jvms-2.html#jvms-2.5.3

https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

https://doc.rust-lang.org/nomicon/working-with-unsafe.html

https://www.php.net/archive/2026.php#2026-10-21-5

올 한 해 600억 가까이 되는 토큰을 사용하면서, (많이 사용한 편은 아닌 것 같지만 ㅋㅋ) 내 사용 경험과 여러 레퍼런스들을 참고하여 작업 세션을 최적화 한 방법에 대해 조금 남겨놓으려고 한다. 핵심은 예나 지금이나 세션 단위의 PRD를 정확히 물려주고, 발산하는 영역들을 휴먼 루프를 최대한 덜 태우면서 어떻게 검증할지를 항상 고민했던 것 같다.

가장 좋은 모델을 오래 붙잡는 것보다, 작업을 나누고 필요한 컨텍스트만 남기고 마지막에 다시 검증하는 편이 더 빨랐다.

처음에는 가장 좋은 모델에게 최대한 많은 맥락을 주면 가장 좋은 결과가 나올 거라고 생각했다. 실제로도 초반에는 꽤 잘 통했다. 프로젝트 전체를 읽히고, 내가 알고 있는 제약을 길게 적고, 한 세션에서 구현부터 테스트와 리뷰까지 계속 이어갔다.

그런데 오래 사용할수록 이상한 장면이 반복됐다. 세션은 이미 앞선 실패와 긴 명령 출력으로 무거워졌고, 새 작업과 관계없는 판단까지 계속 따라왔다. 간단한 구현에도 가장 비싼 모델과 높은 추론 강도를 사용했다. 테스트가 통과했다는 답을 받았지만 실제 화면이나 배포 환경에서는 다른 문제가 남기도 했다.

결국 내가 최적화해야 했던 것은 토큰 하나만이 아니었다. 같은 시간과 사용량으로 얼마나 정확한 결정을 내리고, 실제로 검증된 결과까지 도달하느냐가 더 중요했다.

컨텍스트를 무조건 늘리거나 줄이는 게 아니라, 한 세션이 한 책임을 갖도록 작업 경계를 먼저 나눴다.

1. 최적화의 대상부터 다시 정의했다

예전에는 컨텍스트 사용량이 낮으면 잘 최적화한 것이라고 생각했다. 지금은 네 가지를 같이 본다.

• 결과가 실제 요구사항을 충족했는가
• 내가 기다린 시간은 얼마나 되는가
• 세션과 주간 사용량을 얼마나 소모했는가
• 마지막 결과를 사람이 검증할 수 있는가

토큰을 적게 썼는데 잘못된 코드를 만들면 다시 고쳐야 한다. 반대로 최고 성능 모델이 한 번에 정답을 내더라도, 기계적인 수정마다 같은 비용과 대기 시간을 쓰면 전체 작업량이 줄어든다. 그래서 모든 단계를 같은 모델과 같은 추론 강도로 처리하지 않게 됐다.

이 글에서 말하는 최적화는 모델을 덜 쓰는 방법이 아니다. 어려운 판단에는 충분히 쓰고, 반복 작업에는 과하게 쓰지 않고, 검증이 필요한 곳에는 다시 집중하는 방식에 가깝다.

2. 새 작업에는 새 컨텍스트를 쓴다

Claude Code를 처음 오래 사용했을 때 가장 먼저 체감한 문제는 긴 세션이었다. 대화뿐 아니라 읽은 파일, 도구 호출, 테스트와 빌드 출력도 다음 요청의 컨텍스트가 된다. 이전 작업에서 유효했던 정보가 다음 작업에서는 잡음이 될 수 있다.

지금도 기준은 단순하다.

• 완전히 다른 작업을 시작하면 새 세션 또는 /clear
• 같은 작업의 한 단계가 끝났고 핵심 맥락은 이어가야 하면 /compact
• 잘못된 접근 이후의 대화를 통째로 끌고 가기보다 분기 전으로 돌아갈 수 있으면 /rewind
• 별도 탐색이 주 작업의 맥락을 오염시킬 때만 서브에이전트

예전 글에서는 commit 단위로 compact하고 branch 단위로 clear한다고 표현했다. 지금도 꽤 쓸 만한 비유다. 다만 무조건 정해진 주기로 압축하지는 않는다. 현재 작업에 필요한 정보가 무엇인지, 압축 과정에서 잃어버리면 안 되는 결정이 무엇인지 먼저 본다.

컨텍스트가 크다는 사실 자체보다 관련 없는 정보가 섞여 있는 것이 더 문제였다. 새 작업이 시작됐는데 이전 장애 조사 로그와 실패한 테스트 출력이 계속 남아 있다면, 긴 기억이 장점이 아니라 편향이 된다.

3. AGENTS.md와 CLAUDE.md에는 매번 필요한 것만 남긴다

한때는 에이전트가 실수할 때마다 금지 규칙을 한 줄씩 추가했다. 당장은 안전해 보였지만, 어느 순간 모든 세션이 거대한 규칙집을 매번 읽고 시작했다. 서로 비슷한 규칙이 반복되고, 중요한 제약과 문체 선호가 같은 무게로 섞였다.

현재는 정보를 세 층으로 나눈다.

상시 규칙, 레포 규칙, 현재 작업 문서를 나눠 필요한 시점에 필요한 정보만 읽게 한다.

• 상시 규칙: 모든 작업에 필요한 짧고 안정적인 원칙
• 레포 규칙: 저장소 구조, 명령, 배포와 검증 계약
• 작업 문서: 현재 PLAN, skill, 증거와 판단

핵심은 자주 쓰는 정보를 모두 한 파일에 모으는 것이 아니라, 필요한 시점에 정확한 문서를 읽게 만드는 것이다. 코딩 스타일 한 줄 때문에 배포 절차 전체를 매 요청마다 넣을 필요는 없다. 반대로 데이터 마이그레이션처럼 실패 비용이 큰 작업에서는 짧은 프롬프트보다 명시적인 게이트와 검증 절차가 더 중요하다.

지시문도 코드와 비슷했다. 중복을 줄이고 책임을 나누고, 바뀌는 정보와 안정적인 정보를 분리해야 오래 유지할 수 있었다.

언제 규칙을 상시 파일에서 빼는가?

모든 작업에서 읽을 이유가 없거나, 특정 도구·배포·업무 단계에서만 필요한 절차라면 별도 문서나 skill로 옮긴다. 반대로 권한 경계나 파괴적 작업 금지처럼 매번 적용되는 규칙은 상시 파일에 남긴다.

4. 모델보다 먼저 작업 단계를 나눈다

Claude Code와 Codex를 번갈아 사용하면서 가장 크게 바뀐 부분은 모델 선택보다 phase를 먼저 구분한다는 점이다.

일상 구현은 균형형 설정에서 처리하고, 애매한 결정과 고위험 최종 게이트에 추론 예산을 집중한다.

지금 사용하는 GPT-5.6 계열에서는 복잡한 판단에는 sol, 일상적인 구현에는 terra, 기계적인 대량 작업에는 luna를 후보로 둔다. 하지만 이름 자체가 핵심은 아니다. 같은 모델이라도 추론 강도를 낮추는 것만으로 사용량과 지연이 크게 달라질 수 있다.

clarify   → sol / high
implement → terra / medium
review    → terra / medium 또는 sol / high

구현이 복잡한 멀티 파일 변경이거나 데이터·권한·배포 계약을 건드리면 implement도 강한 모델을 쓴다. 반대로 파일명 변경, 반복적인 테스트 보강, 명확한 UI 카피 수정에 최고 추론 강도를 사용하지 않는다.

중요한 점은 중간에 즉흥적으로 바꾸기보다 phase가 끝났을 때 다음 세션의 설정을 결정하는 것이다. 한 세션이 하나의 책임을 가지면 모델 선택의 이유도 분명해지고, 결과를 비교하기도 쉬워진다.

5. 출력이 많은 일은 본문 컨텍스트에서 격리한다

테스트, 빌드, 로그 검색은 필요하지만 출력이 많다. 성공 로그 수천 줄을 메인 세션에 그대로 남기면 이후 모든 판단에 그 무게가 따라온다.

• 테스트는 필요한 범위부터 실행한다.
• 가능하면 quiet 옵션이나 요약 출력을 사용한다.
• 실패했을 때만 필요한 앞뒤 로그를 넓힌다.
• 서로 독립적인 조사만 별도 컨텍스트로 보낸다.
• 서브에이전트의 최종 결과에는 결론과 근거 위치를 요구한다.

대량 출력을 없애는 것이 아니라, 필요할 때 실행하고 다음 판단에 필요한 증거만 메인 컨텍스트로 되돌린다.

여기서 병렬화는 무조건 빠르게 만드는 버튼이 아니었다. 같은 파일을 여러 에이전트가 만지거나, 앞선 결정이 다음 작업의 입력인 경우에는 오히려 합치는 비용이 커졌다. 독립적으로 끝낼 수 있고 결과 형태가 명확할 때만 병렬화가 이득이었다.

6. 조사, 구현, 검증, 리뷰를 섞지 않는다

AI가 코드를 빨리 만드는 것과 그 코드가 실제로 동작하는 것은 다른 문제다. 이 차이는 사용할수록 더 크게 느꼈다.

조사는 원인을 찾는 단계다. 구현은 변경을 만드는 단계다. 검증은 테스트와 빌드, 실제 화면, 런타임 증거로 요구사항을 확인하는 단계다. 리뷰는 구현자가 놓친 결함을 다시 찾는 단계다.

리뷰에서 가정이 깨지면 구현을 덧대기 전에 조사로 돌아간다. 완료는 답변의 자신감이 아니라 검증 증거로 결정한다.

이 네 단계를 한 프롬프트에서 모두 시키면 마지막 답변은 대체로 낙관적으로 수렴했다. 자신이 방금 만든 변경을 자신이 바로 리뷰하면 맥락을 잘 아는 대신 같은 가정을 공유한다. 그래서 중요한 변경에서는 새 컨텍스트로 diff와 요구사항만 주고 다시 보게 한다.

테스트가 초록색이어도 완료라고 말하지 않는 것도 같은 이유다. 테스트하지 않은 것은 통과가 아니라 미검증이다. 브라우저를 열지 못했으면 시각 검증은 하지 않은 것이고, 배포하지 않았으면 운영 반영은 되지 않은 것이다.

속도를 위해 AI를 쓰면서도 마지막 책임은 줄어들지 않았다. 오히려 구현의 허들이 낮아진 만큼 무엇을 확인하지 않았는지를 정확히 말하는 일이 더 중요해졌다.

7. 느낌 대신 사용량과 결과를 같이 본다

Claude Code를 많이 쓰기 시작하면서 JSONL 파일이 수 GB까지 쌓였고, 기존 사용량 도구가 느려져 직접 toktrack을 만들었다. 처음에는 비용과 토큰을 보기 위한 도구였지만, 지금은 작업 방식을 비교하는 계기이기도 하다.

단순히 토큰이 적은 세션을 좋은 세션이라고 보지는 않는다. 비슷한 난이도의 작업에서 다음을 같이 본다.

• 완료까지 걸린 시간
• 구현과 수정에 사용한 턴 수
• 다시 열린 결함 수
• 검증 단계에서 발견한 누락
• 최종 입력과 출력 사용량

모델과 추론 강도도 대표 작업으로 비교해야 했다. 공식 문서의 추천값은 출발점이고, 실제 레포의 테스트 구조와 요구사항 밀도에 따라 결과가 달랐다. 가장 높은 설정을 기본값으로 두고 참는 것보다, 평소에는 중간값을 쓰고 품질 차이가 측정되는 단계에서만 올리는 편이 지속 가능했다.

8. 지금 사용하는 기본 흐름

현재의 기본 흐름을 짧게 적으면 다음과 같다.

작업 크기와 실패 비용에 맞춰 단계를 합치거나 깊이를 조절하되, 검증 경계만은 흐리지 않는다.

1. 범위 고정: 요구사항, 성공 조건, 비범위를 먼저 적는다.
2. 설정 선택: 다음 phase의 모델과 추론 강도를 고른다.
3. 구현: 계획과 필요한 파일만 전달한다.
4. 출력 축약: 테스트와 빌드는 필요한 범위부터 실행한다.
5. 실제 검증: 확인한 것과 확인하지 못한 것을 나눈다.
6. 독립 리뷰: 위험한 변경은 새 컨텍스트에서 다시 본다.
7. 컨텍스트 종료: 다음 작업에 불필요한 맥락을 넘기지 않는다.

이 흐름이 항상 가장 빠른 것은 아니다. 한 줄 수정에 phase를 세 개 만들면 오히려 낭비다. 반대로 데이터 마이그레이션이나 권한 로직을 한 세션에서 바로 구현하고 스스로 승인하는 것은 빠른 것처럼 보여도 실패 비용이 크다.

결국 작업 크기와 실패 비용에 맞게 깊이를 조절하는 것이 핵심이었다.

실패했던 방식들

• 하나의 긴 세션에서 관련 없는 작업까지 계속 이어가기
• 실수할 때마다 AGENTS.md와 CLAUDE.md에 금지 규칙 추가하기
• 모든 구현을 최고 모델과 최고 추론 강도로 실행하기
• 독립적이지 않은 작업까지 병렬 에이전트에 맡기기
• 테스트 성공을 실제 기능과 배포 성공으로 확대 해석하기
• 에이전트가 만든 요약만 보고 원본 diff와 런타임 증거를 생략하기

완전히 버린 방식도 있고, 특정 상황에서는 여전히 쓰는 방식도 있다. 긴 세션이 항상 나쁜 것도 아니고, 강한 모델이 아까워서 쓰지 말아야 하는 것도 아니다. 문제는 선택의 이유가 없는 기본값이었다.

모델 이름보다 오래 남는 것

처음 Claude Code를 사용할 때는 컨텍스트를 얼마나 많이 넣을 수 있는지가 중요해 보였다. 이후에는 어떻게 줄일지가 중요해졌다. 지금은 무엇을 남기고, 어떤 단계에 어떤 모델을 쓰고, 어디서 다시 검증할지를 더 많이 고민한다.

AI 코딩 도구가 좋아질수록 프롬프트 요령은 금방 낡을 수 있다. 모델 이름과 명령어도 계속 바뀐다. 그래도 작업을 작게 정의하고, 관련 있는 컨텍스트만 전달하고, 결과를 독립적으로 검증하는 원칙은 비교적 오래 남을 것 같다.

정답이라고 생각하지는 않는다. 다만 Claude Code와 Codex를 꽤 많이 사용하면서, 지금까지는 이 방식이 가장 덜 지치고 가장 많은 결과를 실제 완료 상태까지 가져다줬다.

참고 자료

• Claude Code, OOM과 할루시네이션 없이 똑똑하게 사용하는 메모리 최적화 전략
• ccusage보다 1000배 빠른 AI 토큰 트래커 오픈소스를 만들기까지
• AI 시대에 개발자로 살아남으려면
• Claude Code 세션의 가치를 극대화하는 방법
• Using Claude Code: session management and 1M context
• Lessons from building Claude Code: Prompt caching is everything
• Claude Code Docs: Manage sessions
• Claude Code Docs: Checkpointing
• OpenAI model guidance

요즘 시대에 이정도 요구사항은 AI와 함께라면 전혀 두렵지 않지만, 개발을 접하고 지금까지 파일을 다루는 일을 크게 해오지 않았던 터라, 기록 형태로 남겨보려고 한다.

정의

사용자는 여러 명이 올린 영상들을 하나하나 클릭해서 다운로드 받아야 했다. 이에 불편함을 느껴 일괄 다운로드를 받고싶어 한다.

추가적인 정보는 다음과 같다.

• 숏폼 형태의 영상으로, 영상 하나당 최대 300MB 제한이다.
• 영상의 개수는 최대 100개, 약 30GB이다.
• 앞으로 개수는 더 늘어날 수 있다.
• 기존 단건 다운로드 방식은 public URL로 S3에서 직접 다운로드 받는 방식이다.

생각 정리

얼마 안되는 개발 짬빱으로 1차로 생각을 정리했다.

• 압축
• 스트리밍
• 멱등한 비동기 처리

여튼 효율적으로, 빠르게 다운로드가 가능하게 구현하고 요청과 분리해서 202를 떨어뜨리자.
그럼 effectively-once 하게 다운로드가 가능하지 않을까? (이탈·중복·실패에도 정확히 한 번 완료되도록)

영상도 파일이다

알다시피 파일 다운로드라고 딱히 특별하지는 않다. HTTP GET 요청의 응답 body로 온 바이트를 화면에 렌더링할지 디스크에 저장할지를 결정할 뿐이다. 응답 헤더를 통해서 말이다.

Content-Type을 통해 video/mp4 등의 inline 실행인지, application/octet-stream 등의 저장 방식을 결정하거나

Content-Disposition을 통해 다운로드를 강제할 수 있다. Content-Length 헤더가 있다면, 진행률 바를 그릴 수도 있고 말이다.

이 기본적인 매커니즘은 S3 저장, 다운로드 방식 위에 있는 기본적인 네트워크 개념이다.

촬영되는 영상의 성질

촬영 기기의 카메라 센서는 raw 단위의 프레임을 만들지만 촬영 기기는 raw 단위 프레임을 이어서 저장하기에 버겁다. 그렇기 때문에 하드웨어 인코더 칩 등으로 실시간 압축하여 파일로 쓴다. 글을 작성하는 2026년 기준 HEVC라는 비디오 코딩 기술이 안드로이드와 아이폰 기기에 탑재되어 있다. 

HEVC(High Efficiency Video Coding/H.265)는 고효율 비디오 코딩 기술이다. 기존 대비 40~50% 수준의 파일 크기로 고품질 영상을 유지할 수 으며, 4K 및 8K와 같은 초고화질(UHD) 영상의 용량을 획기적으로 줄여 스트리밍과 저장에 널리 사용된다.

아하? 영상이라 파일 크기가 클 수 밖에 없겠지만, 이미 1차로 최대한 품질을 보존한 압축 기법을 통해 저장이 되는구나?

그렇다면 내가 이걸 더 압축한다면 별도 비디오 코딩 기술을 사용해야하고 그것을 유지보수하기 위한 러닝커브가 존재하겠다.

그리고 애초에 고품질 압축을 추가 압축했을 때 광고 집행이나 2차 활용을 보장할 수 있는 품질인가?

그래서 어떻게 개선?

S3도 사실 큰 틀에서 다르지 않다. 어떻게 저장소 따위(?)가 더 상위 개념인 네트워크의 본질을 벗어날 수 있을까.

S3의 코어는 분산 오브젝트 스토어에 있다. 인증, 멀티파트 등등..

다운로드 요청과 처리를 분리해서, 완료된 파일을 사용자가 이탈할 때에도 다운로드 할 수 있도록 지원하고

중복 요청 방지를 위해서 멱등키로 dedup, 같은 키의 zip이 있으면 S3에서 재생성 없이 presigned URL만 새로 서명했다.

백그라운드 워커가 S3 GET을 통해 영상을 읽는다. 다행히 같은 리전이라 트래픽이 무료이며

영상 파일을 묶어서 멀티파트 업로드를 통해 zip 파일로 업로드해서 presigned URL로 다운로드 시킨게 전부..

되게 별게 없다

글을 쓰다보니까 문득 되게 기술적으로는 별 것 안했구나? 라는 생각이 든다.

광고주의 문제 정의를 하고, 기존 지표를 통해 광고주들이 크리에이터의 소재들을 일일이 번거롭게 다운로드 하는 것을 확인했다.

KPI의 가장 큰 축이 광고주의 리텐션인데, 리텐션 지표 상승의 엄청난 임팩트가 있는 개선이라고 보기는 어렵다만...

임팩트가 높은 시도와 병렬적으로 유저의 행동을 데이터로 보고 부정적인 행동들을 빠르게 끊을 수 있는 시도를 계속 하다보면 목표 달성에 더 빠르게 가까워지지 않을까..? 

뭔가 기술적인 내용을 쓰려고 시작했는데 제품적인 글로 마무리 되는 것 같아 찜찜하게 마무리되는 글..

서론

개발자라면 한 번쯤은 특정 필터, 검색 요건을 충족하는 검색 API를 만들어 본 적이 있을 것이다.

조건이 단순하면 간단하지만, 조금만 필터가 복잡해져도 URL은 금방 지저분해진다. 중첩 조건, 범위 검색, 정렬, 페이지네이션, OR 조건 등 여러 가지 조건들이 붙으면 쿼리 스트링은 읽기도 어렵고 지저분해진다.

그래서 조건을 body나 operation payload에 싣는 POST나 GraphQL을 통해 이런 문제를 풀기도 한다. POST 메서드나 GraphQL의 query operation과 variables를 POST body에 담아 보내기도 한다.

POST /contacts/search HTTP/1.1
Content-Type: application/json
Accept: application/json

{
  "filter": {
    "status": "active",
    "tags": ["a", "b"],
    "createdAt": { "gte": "2026-01-01" }
  },
  "sort": "-createdAt"
}

POST /graphql HTTP/1.1
Content-Type: application/json
Accept: application/json

{
  "query": "query Contacts($status: String!) { contacts(status: $status) { id username } }",
  "variables": { "status": "active" }
}

두 방식 모두 복잡한 검색 조건을 표현하기에는 훨씬 편하다. 하지만 HTTP 의미론 관점에서는 찜찜한 지점이 남는다.

우리가 원하는 것은 서버 리소스를 생성하거나 변경하는 것이 아니다. 조건이 복잡해서 URL query string만으로 표현하기 어렵기 때문에 request body가 필요할 뿐이다. 그런데 HTTP method는 POST다.

POST가 항상 리소스 생성을 뜻하는 것은 아니지만, RFC 9110 기준으로 POST는 safe하지도, idempotent하지도 않은 메서드로 취급된다. 즉 애플리케이션 레이어에서는 읽기 요청이라고 알고 있어도, HTTP 레이어와 중간 인프라 입장에서는 이 요청이 읽기인지 쓰기인지 method만 보고 판단하기 어렵다.

HTTP Method의 safe와 idempotent에 대해 다룬 글이 있으니 필요하다면 참고하길 바란다.

POST, GraphQL의 문제

POST /search와 GraphQL POST는 실무적으로 좋은 해법이다. 복잡한 조건을 JSON으로 표현할 수 있고, typed client나 schema validation을 얹기도 쉽다. GraphQL은 한 걸음 더 나아가 클라이언트가 필요한 field shape까지 operation으로 표현할 수 있다.

하지만 HTTP 관점에서는 어떨까?

요청한 애플리케이션의 의미는 읽기이고, 조건 표현을 위해 request body가 필요하다. HTTP method는 POST라서 safe, idempotent의 의미가 method에 드러나지 않는다. 문제는 조건을 어디에 담을 것인가 만이 아니라, 그 요청이 HTTP 레이어에서 어떤 의미로 보이는가를 같이 생각해보아야 한다.

GraphQL도 마찬가지로 애플리케이션 레이어에서는 읽기라고 말하지만 HTTP method만 보면 그냥 POST로 보인다. 그래서 GraphQL 생태계에서는 persisted query 같은 패턴도 생겼다. 긴 query document를 매번 보내는 대신 hash를 URL에 싣거나 CDN cache key를 직접 조정하거나 POST body를 해석하는 애플리케이션 레벨 캐시를 둔다. 하지만 이런 방법들이 HTTP method의 의미 자체를 바꿔주지는 않는다.

그럼 GET에 body는?

그럼 의미론적으로 읽기 요청인 GET에 body를 실어 보내는 방법은 왜 안됐을까?

GET에서도 당연히 실어 보낼 수는 있다. 하지만 RFC 9110에서 요청 content에 대해 일반적으로 정의된 의미가 없다고 설명한다. 서버가 GET body를 검색 조건으로서 해석하고 사용해야 하는지, 무시하고 거부해야 하는지 표준으로 정해주지 않는다.

클라이언트, 서버, 프록시, CDN, 브라우저, 캐시는 모두 method를 보고 이 요청을 어떻게 다룰지 판단하는데, GET body에 자체 규칙을 얹으면 내가 관리하는 서버에서는 동작할 수 있지만, 중간 경로 전체가 같은 의미를 공유한다고 기대하기 어렵다.

HTTP QUERY Method

이런 간극을 다루기 위해 IETF에서는 2026년 6월 RFC 10008을 발행했다.

QUERY method는 IANA HTTP Method Registry에 등록됐고, 이제 HTTP 안에서 body를 가진 safe하고 idempotent한 요청을 표현할 공식적인 메서드가 생겼다.

QUERY /contacts HTTP/1.1
Content-Type: application/json
Accept: application/json

{
  "filter": {
    "status": "active",
    "tags": ["a", "b"],
    "createdAt": { "gte": "2026-01-01" }
  },
  "sort": "-createdAt"
}

QUERY는 POST처럼 body를 실을 수 있지만, GET처럼 safe하고 idempotent한 query 요청을 표현할 수 있다.

이런 특성을 가진 QUERY라는 method의 의미는 단순 GET 요청에 body를 실을 수 있는 것보다는 더 많은 가치가 있을 것으로 보인다.

• 연결이 끊겼을 때 재시도를 고려할 수 있다.
• 캐시가 safe한 query response로 판단될 수 있다.
• gateway나 WAF 읽기 요청과 쓰기 요청을 더 명확하게 구분할 수 있다.
• observability 관점에서 method 기준으로 요청의 성격을 해석하기 쉬워진다. (기존 POST의 오용 감소)

QUERY, 사용해 볼 수 있을까?

QUERY가 표준화됐다고 해서 내일부터 모든 API에 바로 적용하기는 어렵다.

우선 중간 경로가 method를 알아야 한다. 오래된 proxy, WAF, CDN, gateway는 알 수 없는 method를 거부하거나 별도 allowlist로 관리할 수 있다. 서버 framework가 QUERY 라우팅을 지원하더라도 실제 인터넷 경로에서는 막힐 수 있다.

또한 브라우저의 CORS에서 QUERY는 safelisted method가 아니다. RFC 10008도 CORS를 구현하는 user agent에서 QUERY 요청은 preflight가 필요하다고 언급한다. 브라우저 클라이언트에서 쓸 때는 OPTIONS 처리와 Access-Control-Allow-Methods 설정까지 같이 봐야 한다.

그리고 캐시가 request content를 cache key에 포함해야 한다. 이걸 모르는 캐시는 QUERY response를 아예 저장하지 않거나, 저장하더라도 잘못 재사용할 위험이 있다. QUERY의 장점을 제대로 얻으려면 cache layer가 RFC 10008의 규칙을 구현해야 한다. RFC 10008은 QUERY request의 cache key가 request content와 관련 metadata를 포함해야 한다고 명시한다.

마지막으로 지원 여부를 발견하는 절차가 필요하다. RFC 10008은 Accept-Query response header를 정의한다. 서버는 어떤 media type의 query content를 받을 수 있는지 알릴 수 있다.

Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"

또는 OPTIONS 응답의 Allow header로 QUERY 지원 여부를 드러낼 수 있다.

Allow: GET, QUERY, OPTIONS, HEAD

현실적인 도입 순서는 공용 브라우저 API보다 내부 API나 gateway-controlled API 쪽일 가능성이 높다. 클라이언트, 서버, proxy, cache 설정을 한 팀이 함께 통제할 수 있어야 QUERY의 의미와 이점을 끝까지 보존할 수 있기 때문이다.

마치며

QUERY는 POST이지만 GET으로 사용했던 기존의 레거시 API들을 대체할 수 있는 것처럼 보인다. 그렇다고 당장 기존 API를 바꿀 필요는 없다. POST는 여전히 실용적이며 모든 인프라가 POST를 알고 있고, framework와 client 지원도 안정적이다. 캐시가 꼭 필요하지 않거나, 애플리케이션 레벨에서 캐시/재시도/중복 방지를 이미 잘 처리하고 있다면 POST 검색 API를 유지하는 편이 더 현실적일 수 있다.

다만 RFC 10008이 의미 있는 이유는, 우리가 그동안 관습으로 처리하던 요구사항에 HTTP 차원의 이름을 붙였다는 데 있다. GET은 복잡한 request body를 표준 의미로 다룰 수 없으며, POST는 safe, idempotent하지 않다. 그 문제 정의를 표준으로 정의했다는 것에 의미가 있다고 본다.

그래서, POST지만 GET으로 사용되던 레거시를 완전 대체하기보다는 아직은 생태계 지원을 확인하면서 조심스럽게 봐야 하지만, 검색 API와 GraphQL, 분석 API를 설계할 때 앞으로 꽤 자주 언급되고, 고려할 대상으로 보이지 않을까? 싶다.

티빙, 패스트캠퍼스, 모두의 창업 등 최근 연달아 대규모 개인정보 유출이 발생하고 있다.
개인의, 조직의 실수로 데이터가 유출되는건 생각보다 빈번하겠으나, 어느정도 대규모 조직이나 개발 조직이 두터운 곳들에서도 정말 기본적인 것들을 지키지 않은데에서 오는 파장이 엄청나다고 느끼는 요즘이다. 

오늘도 AI를 신뢰하지 않고 언제나 불매를 할 준비가 되어있다 라는 마인드를 가지고 약간의 원인 해부와 나도 개선할 점을 조금 느끼는 것 같아 회고를 남긴다.

시크릿 키 유출

티빙은 DB에 직접 침입해서 탈취당했다고 한다. 그에 따른 사후 조치로는 AWS 액세스 키를 폐기하고, 깃허브 자격증명을 교체했다고 했다. 정확한 원인을 밝히지 않았으니, 티빙은 감히 추측하지 않도록 하겠다.

패스트캠퍼스는 소위 인강 플랫폼이다. IT/테크 쪽의 플랫폼인줄 알았으나 최근 인프런의 행보와 유사하게 다양한 분야로 확장한 모습이었다.

패스트캠퍼스의 유출 경로는 깃허브 레포의 PAT인지, 깃허브 마스터 계정의 키가 탈취된 채로 한 달 가량 노출되어 있었다고 한다.

BOLA/BFLA

모두의 창업을 잘은 모르지만, 사용자의 창업 아이디어를 PMF로 삼는 플랫폼이다. 지인 분께서 창업 아이디어를 올렸으니 좋아요를 눌러달라고 했던 경험이 있다. 그 경험으로 미루어보아, 무언가 아이디어 경쟁을 할 수도 있겠다는 생각이다.

5,000개 가량의 아이디어 요약, 심사평 등이 유출되었다고 하는데, 원인은 명확하나 왜 그랬는지는 정말 모르겠다.

개발을 하다보면 기본적인 인증/인가 처리는 고려하지 않으려고해도 안할 수가 없는 기본적인 문제이기 때문에, 정말 빠르게 개발을 해야 했거나 소위 빌더라 불리우는 바이브 코딩의 영향이 아닌가 싶다.

헤더에도 써놨지만 Broken Object Level Authorization, Broken Function Level Authorization이라 불리는 API 보안 취약점이 원인이다. 요새 기술 스택이 python이니, python 웹 프레임워크를 예시로 간단하게 코드를 작성했다.

@app.get("/api/applicants/{id}")
def get_applicant(id: int):
    a = db.get(Applicant, id)
    return a.__dict__

<span>{maskEmail(applicant.email)}</span>

API를 위와 같이 구성하고, UI에서만 미노출하는 형태로 개발이 되었다고 한다.

직접 HTTP Request를 보이면 그대로 드러나게 구성을 해두었던 정말 말도 안되는 문제로 소중한 아이디어들이 유출되었다.

AI Slop

GPT5.5, Opus4.8 Fable4.8 시대에 무슨 AI Slop인가 싶겠지만, 모델의 성능에서 오는 조잡한 결과물에 대한 얘기가 아니다.

LLM이 컨텍스트를 충분하게 얻지 못한 이유로 여러 인과관계들을 고려하지 못한 단순 구현 코드를 싸질렀다고 해서 책임을 LLM이 지는 것은 아니다. 실제 업무에서 사람들과 협업 했을 때, 서로 상대방의 책임으로 떠넘긴 결과물이 과연 좋을까.

마찬가지로, LLM을 오케스트레이션 한 결과물을 내가 100% 검수할 수 있는 능력이 없다면, 과연 이 LLM을 가지고 기술적인 요구사항을 구현하는게 맞을까. 구현의 허들은 점점 낮아지지만 책임의 영역은 그대로 보존된다.

이 사고들이 모두 AI 때문에 벌어졌다고 말할 수는 없다. 다만 요즘 개발 환경에서는 구현의 허들이 낮아진 만큼, 검증하지 않은 결과물을 운영 환경에 올리는 속도도 같이 빨라졌다. LLM이 만든 코드든 사람이 급히 짠 코드든, 인증·인가·시크릿 관리의 책임은 결국 배포한 사람과 조직에 남는다. 일련의 사례들을 보고 주니어 개발자인 내가 내린 결론은, 본인이 책임질 수 있는 역량을 키우는 것이 요즘의 개발에서 개발자로 살아남는 가장 중요한 첫 단추이지 않을까 라는 생각이 들었다.

서론

링크드인이나 다른 레퍼런스들에 너무 많은 노이즈가 끼어 있다.

AI로 뭘 자동화했다. 생산성이 몇 배 향상 됐다.

시도하면서 배우는 것들이 있기 때문에, 시도 자체에는 부정의 여지가 단 1%도 존재하지 않는다.
하지만, 나는 이런 레퍼런스들이 성공 사례라고 생각하지 않는다. 개인 혹은 본인이 속한 조직에서 여러 연관 관계에 따른 사이드 이펙트가 있음에도 이를 선택한 설명이나 도입 전후의 공개 가능한 지표들을 충분히 제공하지 않은 채로 무지성 AX를 외치고 있다고 생각한다. 이게 무지성 뇌동매매 후 화성 갈끄니께~~ 를 외치는 것과 뭐가 다를까?

나도 이런 부분에서 자유롭지 않다. 한 조직의 개발자로서 AI로 뭔가 빨라지긴 한 것 같은데, 정말 나아진 게 맞나? 라는 생각이 끊임 없이 든다.

정말 생산성이 향상 됐나? 조직에 어떤 영향을 어떻게 끼쳤나? 그래서 조직의 매출이나 기타 지표들은 상승 곡선을 그리고 있나?

그 무엇도 명쾌하게 설명할 수 없는 것 같은 답답한 상황인 것 같다. 과도기를 어느 정도 넘어가고 있다고 생각하는데, 이 시점에서 어느정도 정리할 수 있는 생각들은 정리할 필요가 있다고 판단이 섰다.

개인은 빨라진 것 같다. 그렇다면 조직은?

개인의 생산성이 올라간 건 부정하기 어렵다. 예전 같으면 누군가에게 부탁하거나 미뤄뒀을 일을, 각자가 필요한 걸 직접 만들기 너무 쉬워졌다. 거기까진 분명한 이득이다.

문제는 그 다음이다. 조직의 경우 직접 만든 그 무언가가 이미 운영되고 있는 제품에 닿는 순간, 결국 관련 담당자의 리뷰가 반드시 필요한 상황에 놓인다. 물론 이 부분들까지 관련 담당자들의 컨텍스트들을 잘 정리해서 자동화 할 수 있다. 리뷰, QA, 배포 등 모든 영역에서 가능하다. 하지만 그게 항상 옳지만은 않다는 것을 모두가 알고 있기 때문에 Human-Loof, Human-in-the-Loof 라는 용어도 생겨났다고 생각한다. 결국 필요 시에는 담당자가 들여다보고 검증하고 책임질 수 있는 형태로 다듬어야 한다는 말이다.  그럼 이건 생산성이 향상되었다고 할 수 있을까? 누군가는 생산성이 향상되었다고 할 수 있겠지만, 이걸 검증 해야하는 사람의 입장에서는 일이 더 늘어났다고도 볼 수 있다. 그렇다면 이게 조직 관점에서 더 이득일까? 라고 물으면 모두가 그렇다. 라고 할 수 있을까?  전체의 관점에서는 비슷한 자리에서 일의 모양만 바뀐 것 같기도 하다.

조직 내 개발자의 생산성은 정말 올랐나?

그럼 우리 조직으로 문제를 가져와서, 개발자 본인의 생산성은 정말 올랐을까?

우리와 비슷한 유사 스타트업들도 스프린트 단위의 업무를 진행하는데, 예나 지금이나 마찬가지로 스프린트의 일정을 준수하며 개발하는 건 똑같다. 달라진건 직접 코드를 작성하는 것에서, 코드를 LLM이 더 잘 작성할 수 있게 PRD를 다듬고, 산출물을 리뷰하는 역할의 차이가 전부이다.

도대체 어떤 부분이 진짜로 향상된 것일까? 개인이 LLM을 다루는 스킬이 향상된 것을 가지고 개인의 자산으로 남았으니 잘했다고 칭찬을 해야할까? 그것도 잘 모르겠다. 어쨋든 시대의 변화에 따라 LLM을 다루는 스킬도 역량이라고 했을 때, 그것을 다시 조직의 무언가로 환원할 수 있는 구조를 만들어가고 있는지에 대해 되돌아 볼 필요가 있다.

나 또한 마찬가지다. 결국 큰 컨텍스트에서 작은 단위로 쪼개어 개발을 할텐데, 그게 LLM Driven Development에서는 자연스럽게 작은 단위에서 발생하는 반복적인 무언가를 스킬 단위로 분리하고, 반복적인 작업에 필요한 것들을 컨텍스트화하고, Do-Not 행위들을 가드레일로 삼고 하는 등의 행위들을 자연스럽게 하고 있는데, 이게 조직 단위로 쌓일 수 있는 것들을 같이 만들어 나가고 있는가? 에 대해서는 세모이다. 전사적인 AX를 시도하고 있지만, 제품의 스프린트에서는 별개로 보았던 것 같다. 나의 개발 행위와 AX 행위에서 교집합을 찾지 않았던 것이 문제였던 것 같다.

그럼 조직으로 관점을 넓혀볼까? 어떻게?

스프린트 밖의 조직 AX로 넘어가서, 비개발자들의 업무 효율을 개선해보려고 이런저런 시도들을 했고, 하고 있다. 결과적으로 개선되는 부분이 생기다보니 생산성이 오르는 것 같고 조직의 형용할 수 없는 무언가(?)도 올라가는 것처럼 보이더라. 서론에서 언급했던 지표나 뒷받침 할 수 있는 근거는 아직 부족해서, 개인 블로그 회고 형태로 밖에 쓸 수 없지만 언젠간 기술 블로그 형태로 정리해서 공유해보고 싶다.

여튼 AX의 시행착오를 겪으면서 여태 가장 크게 문제점이라고 생각했던 부분은, 초기에 무언가 구축할 수 있는 환경을 전달했을 때,

"이런 것도 AI로 할 수 있구나. 나도 해보고 싶다. "

가 아니라

"오 편하네, 근데 이런건 더 있으면 좋겠네, 이것도 해달라고 해야지"

로 나에게 되돌아오는 것이 가장 큰 문제라고 생각한다. 본인이 직접 개선해보거나 만들어보는 경험을 통해 무한히 확장될 수 있는 사고, 경험들을 의존성 체인에 갇혀 우물 안 개구리가 되는게 아닐까 안타까운 심정이 든다.

조직말고 개인으로 돌아와서, 가장 큰 문제는 내가 LLM을 통해 병렬로 싸지르고 다닌 모든 것들에 대해 나는 완벽하게 알고 있나? 에 대한 의문이다. 분명 제품적으로, 조직 내부적으로 개선이 되었는데 내가 구현에 대해 모든 것들을 이해하고 있지는 않은 상태가 더러 발생했다. 이게 조직에 쌓이면, 나중에 어떤 모양으로 돌아올지 잘 모르겠다만 부정적인건 분명하다. 나부터 이 악습을 끊을 필요가 있다.

공부하자 공부

AX? 숫자로 증명이 가능한가?

이력서를 쓸 때도, 기업 소개를 쓸 때도 PR의 수단은 결국 숫자. 지표라고 생각한다. 그래서 도달하는 결론은 숫자다.

물론 지금 당장 AI를 통해 어떤 지표가 개선이 되었고는 잘 모른다. 미지수이다. 하지만 모든 시도들이 조직적인 자산으로 남기만 해도 언젠가 가속화의 수단이 될 것이라는 생각이 든다. 다만 지금 그게 어떻게 남고 있는지, 남겨야 하는지에 대해 시도해보면서 시행 착오를 겪는 과정에 있는 것 같다. 조직의 컨텍스트를 SSoT로 한 군데에 모은지는 벌써 꽤 되었지만, 이건 단순 시발점에 불과하니까.

결국 AI에 돈을 더 쓰는 만큼 다른 부분에서 향상된 것이 있나? 그걸 숫자로 표현할 수 있나? 에 대해 생각해보게 된다.

이 질문에 답하지 못한다면, 결국 기분의 영역으로 AI로 뭔가 잘 되고 있어!!! 라는 환각 상태에 계속 머무르지 않을까?

마치며 (완전 다른얘기)

Opus 4.7이 나온 시점부터, 뭔가 겹겹이 쌓였던 하네스를 걷어내고 있다.

모델 버전이 올라갈수록 LLM 자체의 내부 하네스가 견고해질 것이라고 생각한다. 그래서 내가 덧대둔 로컬 세팅을 조금씩 덜어내고 있었는데, Opus 4.7, GPT-5.5가 나온 시점부터는 아예 모델의 업데이트마다 로컬 세팅을 모두 제거하고 퓨어한 상태에서 시작해보고 있다. 그래야 그 모델을 있는 그대로 이해하고 그 위에 현재에 필요한 새 하네스를 깔아볼 수 있기 떄문이다.

도구는 점점 알아서 잘해지기 때문에, 그럴수록 나는 내가 뭘 알고 모르는지를 더 또렷이 보는 눈을 길러야겠다. 빨라진 만큼 남는 게 있는지, 그 남는 것들을 내가 이해하고 내 것으로 만들어 성장할 수 있는지.