개발 slecs

에이전트가 TODO를 보면 멈추지 않는다

목차

GitHub Blog의 "Beyond code generation" 포스트를 훑다가, 옆에 띄워둔 Google Developers 포스트를 더 오래 들여다보게 됐다. "Agent Distraction"이라는 제목이 걸렸다. 913,000개가 넘는 코딩 에이전트 세션을 분석했더니, 13%의 세션에서 인라인 TODO 주석이 에이전트에게 노출됐고, 그중 6%에서 에이전트가 그 TODO를 실제로 처리하려 했다는 내용이다. 그리고 그 행동의 83%는 개발자가 명시적으로 요청하지 않은, 에이전트 혼자의 판단이었다.

숫자가 작아 보일 수 있다. 6%면 별거 아닌 것 같다. 근데 뒤에 붙은 오버헤드가 문제다. 그런 세션에서 단계가 70% 늘고, 토큰이 77% 더 소비되고, 대기 시간이 105% 늘어났다. 에이전트가 닫힌 티켓을 쫓아가거나 허락받지 않은 범위를 건드리는 데 그 비용이 쪼개진다.

TODO는 에이전트의 눈에 작업 명세서다

이게 왜 생기는지는 사실 직관적으로 납득이 된다. 코드베이스에 오래된 "나중에 처리" 주석이 있으면, 사람 개발자는 맥락상 지금 건드릴 게 아니라는 걸 안다. 그 주석이 오래됐거나, 이미 외부 이슈로 옮겨진 거라는 걸 경험으로 판단한다. 에이전트는 그 판단을 하기 어렵다. 텍스트로 보면 미완성 작업이고, 에이전트의 목표는 코드베이스를 개선하는 거니까, 그걸 처리하는 게 "좋은 일"처럼 보인다.

AI 코딩 도구를 쓰면서 비슷한 상황을 겪는다. 에이전트한테 특정 기능 하나를 추가해달라고 했는데, 돌아오는 변경 묶음이 예상보다 훨씬 클 때가 있다. 내가 요청한 것과 직접 관련 없는 수정이 섞여 있고, 왜 건드렸나 보면 근처에 있던 오래된 임시 주석 때문인 경우가 있다. 에이전트가 "어차피 여기 왔으니" 하는 태도로 범위를 넓히는 것이다. 나는 그걸 리뷰하고 걸러내는 데 추가 시간을 쓴다.

이 연구가 그 경험에 숫자를 붙여준 셈이다. 단순히 에이전트가 느려지는 게 아니라, 토큰을 쓰고 시간을 쓰면서 엉뚱한 방향으로 갔다가 돌아온다. 그 결과물을 사람이 검토해야 한다.

"에이전트 엔지니어링"이라는 말이 주는 압박

GitHub Blog 포스트는 코딩 도구를 활용해서 계획, 코딩, 리뷰, 프로덕션 이슈 조사를 어떻게 할 수 있는지를 다룬다. 코드 생성은 빨라졌는데 그 주변 작업은 아직 느리다는 문제 인식에서 시작한다. 아젠틱 엔지니어링 시대라는 프레임으로 개발자한테 도구를 더 적극적으로 써야 한다고 말한다.

이 흐름 자체는 맞다. 단순 코드 작성 속도보다, 뭘 만들지 판단하고, 만든 걸 검토하고, 운영 중 문제를 추적하는 과정이 훨씬 더 큰 비용이다. 거기에 에이전트를 엮는 게 가치 있는 방향이라는 건 동의한다.

다만 그 흐름이 "도입하면 된다" 수준의 이야기에 머물 때가 많다. Google의 에이전트 산만함 연구는 그 반대편을 보여준다. 에이전트를 쓰면서 생기는 조용한 비용, 직접 명령하지 않은 행동, 예상보다 넓어진 변경 범위. 이런 것들이 쌓이는 마찰이다.

혼자 또는 작은 팀으로 굴릴 때 이 마찰이 더 두드러진다. 큰 팀은 에이전트 출력물을 검토하는 사람을 따로 둘 수 있다. 나는 그 검토도 내가 한다. 에이전트가 TODO 하나 잡아서 예상의 세 배짜리 변경을 만들어오면, 그 전체를 내가 훑어야 한다. 그 시간은 "에이전트가 빨라진 시간"으로 상쇄되지 않는다.

컨텍스트 범위가 방어선이다

에이전트한테 넘기는 맥락을 더 좁히게 됐다. 파일 전체를 주는 대신 관련 함수 범위로 잘라서 주는 편이고, 코드베이스 안의 오래된 임시 주석을 주기적으로 정리하거나 별도 위치로 옮기는 것도 고려 중이다. 에이전트가 볼 필요 없는 맥락을 줄이는 것이다.

얼마나 효과가 있는지는 직접 써봐야 안다. 연구가 913,000개 세션 기준이니 통계적으로 의미 있지만, 내 작업 방식과 도구가 같은 패턴을 보인다는 보장은 없다.

반면에 GitHub Blog 포스트가 언급하는 프로덕션 이슈 조사 용도는 써볼 만하다고 본다. 에러 로그나 트레이스를 에이전트한테 던지고 원인 추론을 맡기는 방식은, 열린 코드베이스를 주는 것과 달리 질문이 명확하게 닫혀 있다. 범위 이탈이 덜 생길 가능성이 있다. 이쪽은 실제로 써보면서 조금씩 판단할 생각이다.

에이전트 엔지니어링을 도입하는 게 아니라, 에이전트가 어디서 삐끗하는지 파악하는 게 먼저인 것 같다. 그래야 도입할 때 같은 함정을 피할 수 있다.

참고한 글

오늘 패치한 것, Alpine OpenSSH

에이전트 얘기를 쓰는 동안 옆에 띄워둔 탭이 하나 있었다. Alpine Linux OpenSSH 서버의 패스워드 인증 우회 취약점. 발표일이 11월 5일이고 오늘이 7일이다.

내 환경에서 직접 노출된 케이스는 없었다. 대부분 키 기반 인증으로 운용하고 있고, Alpine 기반 컨테이너에 SSH 데몬을 외부로 열어두는 경우도 많지 않다. 그래도 Alpine 이미지를 쓰는 컨테이너들 버전 확인하고 패치 적용했다. Alpine 보안 권고 원문에 영향 버전과 픽스 버전이 정리돼 있으니 직접 확인하면 된다.

길게 쓸 얘기는 아니다. 나왔으면 패치하면 된다. 다만 발표에서 확인까지 이틀이 걸렸다는 점이 마음에 걸린다. 주말이라 여유 있게 본 셈이지만, 프로덕션 노출이 있었다면 느린 편이다. CVE 알림을 좀 더 빠르게 받아볼 수 있는 체계가 필요하다는 메모.

- Alpine Linux Security Advisory: OpenSSH-server password authentication bypass

MS Paint RCE

CVE 알림 체계 얘기가 나온 김에 하나 더. CVE-2026-83844, MS Paint 원격 코드 실행 취약점.

Paint에서 RCE가 나온다는 게 처음엔 농담처럼 읽힌다. 실제로 보면 그럴 수 있는 게, Paint도 이제 이미지 편집 그 이상의 기능이 붙어 있다. 기능이 많아질수록 공격 표면이 넓어진다. Windows 환경 쓰는 사람은 패치 상태 확인하면 된다.

GrapheneOS: 같은 날, 반대 방향

서로 다른 방향의 소식이 하루에 묶였다.

네덜란드 ASN 은행이 GrapheneOS를 포함한 비구글 Android를 차단하기 시작했다. 뱅킹 앱들이 환경 무결성 체크를 강화하면서 생기는 패턴이다. GrapheneOS 쪽 이슈 트래커에 올라온 케이스다. ASN이 "이상주의적" 은행을 자처하는 곳이라서 아이러니가 있다.

같은 날 Motorola는 Signature 27 모델에 공식 GrapheneOS 지원을 발표했다. Pixel 외 기기에서 공식 지원이 붙는 건 드문 일이다.

한쪽에선 환경을 잠그고, 한쪽에선 하드웨어 선택지가 넓어진다. 프라이버시 강화 OS와 메인스트림 금융 서비스의 갈등은 당분간 계속될 구조다.

짧게

Salon 폐간: 1995년 창간, 31년만에 문을 닫았다. 광고 모델에서 구독으로, 여러 번 피벗을 시도한 곳이다. 평가하기보다 그냥 한 시대가 끝났다는 느낌이다.

Tesla Cybertruck: 생산 종료 수순. 출시 초기부터 실용성 의문이 많았다. 예상된 결말이라는 반응이 대부분이다.

Kagi 검색: 비로그인 무료 접근 범위를 넓혔다. 결과 품질은 좋다는 평이 많다. 접근성을 넓히는 방향이라면 반갑다.

Window Sweaters: 창문 프레임에 스웨터 니팅 패턴을 오버레이하는 UI 프로젝트. 쓸모없이 귀엽다. 이런 것도 있어야 한다.

마치며

에이전트가 삐끗하는 패턴, CVE 두 개, 미디어 하나의 종말. 조각난 주제들이지만 이번 주말에 같이 처리한 것들이다.

다음 주 초에 할 것은 CVE 알림 채널 정비다. 발표에서 확인까지 이틀이 걸린 것이 계속 마음에 걸린다. RSS든 메일링리스트든 하나 세팅해두면 된다. 간단한 일인데 미뤄두고 있었다.

이어보기

댓글 0

첫 댓글 달아줘.