AI가 싸게 만든 것 세 가지: 공격, 모델, 반복 운영

in AI on Ai, Coding agent, Llm, Security, Platform engineering, Engineering culture

AI가 싸게 만든 것 세 가지: 공격, 모델, 반복 운영


지난 두 글의 다음 줄

첫 번째 글의 결론은 “컨텍스트는 세션에, 컨벤션은 저장소에”였다. 세션은 피처 단위로 수직으로 쓰고, 일관성은 세션의 기억이 아니라 저장소의 아티팩트가 지키게 하자는 얘기였다.

두 번째 글은 그 다음 줄이었다. “규칙은 저장소에, 판단은 시스템에.” 에이전트는 린터로 검사되는 규칙은 잘 지키지만, 어떤 모델을 어떤 키로 어느 리전에서 부를지 같은 판단은 세션마다 제각각 내린다. 그러니 일관돼야 하는 판단은 코드 밖으로 꺼내 시스템이 소유하게 하자고 했다.

두 글 다 출발점은 같았다. 개인 한 명이 에이전트 여러 개를 돌리면서 이미 하나의 작은 팀이 됐다.

한 달쯤 더 지나 보니 이 문장에 빠진 게 있었다. 팀이 된 건 우리만이 아니다. AI가 싸게 만든 것은 내 생산성만이 아니라, 공격자의 생산성이기도 하고, 모델 자체의 가격이기도 하고, 매일 반복되는 운영 작업의 비용이기도 하다.

싸진 것이 바뀌면 기본값도 바뀌어야 한다. 이번 글은 그 세 가지 이야기다.

싸진 것바뀌어야 하는 기본값
공격숨기지 않고 막는다
모델감이 아니라 비교해 보고 고른다
반복 운영알림이 사람 대신 에이전트를 부른다

① 공격이 싸졌다 — 숨기지 않고 막는다

“주소를 모르면 못 온다”는 가정

사내 관리 화면, 어드민 페이지, 대시보드, 배치 콘솔 같은 내부 도구는 오랫동안 이런 가정 위에 있었다. 주소를 모르면 찾아오기 어렵다. 공개 DNS에 이름이 걸려 있어도, 아무도 그 서브도메인을 모르면 사실상 안전하다고 여겼다. 로그인 화면이 하나 있으면 더 그랬다.

이 가정이 성립했던 이유는 공격이 비쌌기 때문이다. 수많은 도메인을 훑고, 열린 포트를 찾고, 거기서 돌아가는 소프트웨어 버전을 알아내고, 알려진 취약점과 맞춰 보는 일은 사람의 시간이 드는 일이었다. 공격자도 우선순위를 정해야 했고, 이름 없는 내부 도구는 그 목록에서 뒤로 밀렸다.

공격자도 팀이 됐다

그 비용이 무너지고 있다. 최근 보안 업계 보고서들의 숫자는 대체로 같은 방향을 가리킨다.

  • AI를 활용한 공격은 전년 대비 89% 늘었고, 침입 후 내부로 퍼지기까지 걸리는 평균 시간은 29분으로 전년보다 65% 빨라졌다. (CrowdStrike 2026 글로벌 위협 보고서)
  • 취약점이 실제로 발견된 뒤 공격 도구로 만들어지기까지의 중앙값은 24시간을 훨씬 밑돈다. (Microsoft 2026 Digital Defense Report)
  • 공격자가 AI 코딩 도구와 에이전트에게 취약점 스캔 파이프라인을 돌리고 실시간으로 고치게 한 사례가 보고됐다. 6시간이 안 되는 캠페인으로 수천 건의 자격증명이 털렸다. (Google 위협 인텔리전스)

공정하게 덧붙이면, 같은 보고서들은 “완전히 자동화된 공격은 아직 흔하지 않다”, “가장 복잡한 침투는 여전히 사람이 주도한다”는 단서도 단다. 하지만 이 글에서 중요한 건 완전 자동화 여부가 아니다. 탐색과 스캔, 알려진 취약점 맞춰 보기 — 정확히 “주소를 모르면 못 온다”는 가정을 지탱하던 비싼 구간 — 이 가장 먼저 싸졌다는 점이다.

내가 에이전트로 팀이 된 것처럼, 공격자도 에이전트로 팀이 됐다. 그 팀원들은 지치지 않고, 이름 없는 서브도메인을 우선순위에서 밀어낼 이유도 없다.

숨기는 것은 판단이고, 막는 것은 시스템이다

여기서 지난 글의 표를 다시 꺼내면 구조가 보인다.

방식성질
주소를 알리지 않는다확률적 — 상대가 못 찾기를 바란다
로그인 화면을 둔다반쯤 결정론적 — 화면 자체는 누구에게나 보인다
네트워크 밖에서는 아예 닿지 않게 한다결정론적 — 찾아도 열리지 않는다

“주소를 숨긴다”는 지난 글의 L1(문서로 부탁하기)과 같은 자리에 있다. 상대가 그 부탁을 들어줄 거라고 기대하는 방식이다. 공격이 비쌀 때는 그 기대가 대체로 맞았다. 이제는 아니다.

그래서 기본값을 이렇게 바꾸는 것이 맞다고 본다. 고객이 쓰지 않는 화면은

  1. 인터넷에서 주소조차 보이지 않게 한다. 공개 DNS에서 이름을 지우고, VPN 툴로 연결된 사내망 안에서만 열리게 한다.
  2. 사내망 안에서도 회사 계정 로그인을 거치게 한다. 네트워크 안에 들어왔다는 사실만으로 신뢰하지 않는다. SSO 한 겹이 더 있다.

새로운 아이디어는 아니다. 제로트러스트라는 말이 나온 지 10년이 넘었다. 달라진 건 이걸 미룰 때의 비용이다. 예전에는 “언젠가 정리해야지”가 현실적인 선택이었다면, 지금은 미루는 동안 누군가의 에이전트가 그 주소를 이미 훑고 지나갔을 가능성이 높다.

옮기는 일도 싸졌다

다행인 점은, 공격만 싸진 게 아니라 막는 작업도 같이 싸졌다는 것이다.

내부 도구 하나를 사내망 전용으로 옮기는 작업은 예전에는 팀마다 인프라 담당자에게 티켓을 넣고 차례를 기다려야 하는 일이었다. 지금은 절차를 레시피 문서로 하나 써 두면, 각 팀이 자기 코딩 에이전트에게 “이 레시피대로 우리 도구 옮겨 줘”라고 시킬 수 있다. 플랫폼은 원칙과 레시피를 소유하고, 각 팀은 자기 도구를 직접 옮긴다. 첫 번째 글에서 말한 “플랫폼은 스트림 팀이 셀프서비스로 쓰는 내부 제품”이 이런 모양이다.

② 모델이 싸졌다 — 감이 아니라 비교해 보고 고른다

비싼 모델이 기본값이 되는 이유

LLM을 쓰는 코드에서 모델 이름은 대부분 처음 그 코드를 쓴 사람의 감으로 정해진다. 그때 가장 똑똑하다고 알려진 모델, 아니면 그 사람이 평소 쓰던 모델. 한 번 정해지면 잘 바뀌지 않는다. 바꿨다가 품질이 떨어지면 책임이 생기는데, 그대로 두면 아무 일도 일어나지 않기 때문이다.

그사이 모델 시장은 빠르게 움직였다. 같은 일을 훨씬 싸게 하는 모델과 오픈 웨이트 모델이 계속 나오고 있다. 그런데 “이걸로 바꿔도 되나?”라는 질문에 답할 수단이 없으면, 코드는 계속 처음의 비싼 모델을 부른다.

벤치마크 점수로는 답이 안 나온다

공개 벤치마크로 고르면 되지 않느냐고 할 수 있다. 실제로 해 보면 그걸로는 부족하다.

벤치마크는 “정답을 맞혔는가”를 본다. 그런데 서비스에 박힌 프롬프트가 원하는 건 정답만이 아니다. 출력 형식(JSON 스키마, 마크다운 섹션, 필드 수), 말투, 길이, 지켜야 하는 규칙(금지 문구, 언어, 인용 방식)이 함께 맞아야 한다. 정답률이 같아도 형식이 하나 어긋나면 그 출력을 받아 파싱하는 다운스트림 코드가 깨진다. 점수표에는 이게 안 잡힌다.

그래서 기준을 바꿨다. 우리 프롬프트와 우리 입력으로 비교한다.

실제로 해 본 비교

모든 LLM 호출이 한 게이트웨이를 지나게 해 두었더니(지난 글 이야기다), 운영에서 실제로 오간 요청과 응답이 한곳에 쌓였다. 그 위에 평가 화면을 하나 만들었다.

  • 운영에서 실제로 쓰인 프롬프트와 입력, 그리고 그때의 답을 불러온다.
  • 모델과 프롬프트를 바꿔 가며 같은 입력을 돌리고, 답을 나란히 놓고 눈으로 본다.
  • 동시에 LLM이 항목별로 채점한다. 답의 품질뿐 아니라 기존 답과 형식·말투·내용이 얼마나 같은지, 출력 규칙을 지켰는지까지.

운영 프롬프트 12종에 실제 입력 10건씩, 같은 120건을 두 모델에 돌린 결과는 이랬다.

 claude-opus-5-5deepseek-v4.1-flash-1017
평균 점수 (5점 만점)4.094.12
120건 비용$2.99$0.06

점수는 사실상 같고, 비용은 50배 가까이 차이 난다. 실제 운영에서도 일부 호출을 훨씬 저렴한 모델로 바꿨는데, 하루 17만 5천 건을 처리하는 동안 서비스 쪽 실패는 0건이었다.

그렇다고 전부 바꾸면 안 된다

같은 비교에서 반대 결과도 나왔다. 어떤 프롬프트에서는 싼 모델이 “기존 답과의 일치” 점수에서 눈에 띄게 떨어졌다. 정답은 비슷한데 형식과 말투가 달라진 것이다. 이런 곳은 바꾸지 않거나, 프롬프트를 보완해서 기존 모델과 새 모델 둘 다에서 같은 형식이 나오는지 확인한 뒤에만 옮겼다. 되돌려야 할 때 기존 모델에서도 형식이 깨지면 안 되기 때문이다.

이 경험에서 얻은 결론은 두 문장이다.

  • 비싼 모델이 더 좋은 결과를 보장하지 않는다.
  • 비교해 보지 않고 고른 모델은 그냥 습관이다.

모델을 바꾸는 비용이 설정 한 줄로 떨어진 순간, “바꿀 수 없으니 그대로 둔다”는 핑계는 사라진다. 남는 건 “비교해 봤는가”뿐이다. 새 기능의 모델은 이제 감이 아니라 비교 결과로 정하는 게 기본값이어야 한다.

③ 반복 운영이 싸졌다 — 알림이 에이전트를 부른다

사람이 메시지 버스였다

첫 번째 글에서 수평 세션 구조의 문제를 이렇게 적었다. 세션 사이에서 결과를 읽고 요약해서 다음 세션에 붙여넣는 사람이 메시지 버스가 되고, 그 구간이 암달의 법칙에서 말하는 직렬 구간이 된다고.

운영 알림도 똑같은 구조였다. 매일 아침 점검 작업이 돈다. 결과가 Slack에 올라온다. 사람이 읽는다. 판단한다. 고친다. PR을 올린다. 배포한다. 확인한다. 알림과 수정 사이에 사람이 메시지 버스로 끼어 있다. 알림이 하나일 때는 괜찮은데, 점검이 늘어날수록 그 직렬 구간이 하루를 잡아먹는다.

알림이 에이전트를 부르게 했다

그래서 Claude Code를 컨테이너 이미지로 만들어 Slack에 붙였다. 오픈소스 에이전트 Hermes의 Slack 상호작용 방식을 참고해, 동료에게 말하듯 일을 맡길 수 있게 했다.

  • 멘션이나 DM으로 일을 시키고, 스레드 하나가 세션 하나가 된다. 같은 스레드에서 이어서 말하면 앞의 맥락을 기억한다.
  • 진행 상황은 계속 갱신되는 한 줄로 보여 준다. 작업 중에 질문하면 메인 작업을 끊지 않고 바로 답한다.
  • 실행 시간 상한에 걸리면 실패로 끝내지 않고, 어디까지 했고 무엇이 남았는지 인계 메모를 남긴 뒤 같은 스레드에서 “계속해”로 이어받는다.

그리고 핵심 하나. 허용한 봇의 알림 멘션으로도 작업을 시작할 수 있게 했다. 이제 흐름은 이렇다.

매일 아침 점검 → 결과 알림이 에이전트를 멘션
   → 에이전트가 처리 (단종된 모델 정리, 신규 모델·가격 정보 추가)
   → 개발 환경까지 PR·머지·배포·확인
   → 운영 반영 PR 링크를 스레드에 남김
   → 사람은 검토하고 반영만

알림을 처음 읽는 주체가 사람에서 에이전트로 바뀌었다. 사람은 마지막에 운영 반영 버튼만 누른다.

경계는 사람이 쥔다

이 구조에서 가장 신경 쓴 건 어디까지 에이전트가 하고 어디서 사람이 받느냐다.

  • 개발 환경은 에이전트가 끝까지 간다. PR, 머지, 배포, 확인까지.
  • 운영 환경은 PR까지만 간다. 운영 머지는 사람이 한다.
  • 에이전트가 쓰는 운영 자격증명은 기본으로 꺼져 있다. 알림 안에 든 값(모델 이름 같은 것)은 지시가 아니라 데이터로 다루게 지침을 둔다. 자기 자신이 보낸 메시지로는 절대 작업을 시작하지 않는다(무한 루프 방지).

이게 지난 글의 “판단은 시스템에”와 충돌하지 않느냐고 물을 수 있다. 오히려 그 연장선이다. 매일 같은 방식으로 내려져야 하는 판단(이 단종 모델을 지울까, 이 가격표를 갱신할까)은 시스템과 에이전트에게 넘기고, 운영에 내보낼지 말지라는 마지막 판단 하나만 사람이 쥔다. 사람이 하는 일이 줄어든 게 아니라, 사람이 해야만 하는 일만 남은 것이다.

다음 후보는 이미 받은편지함에 있다

이 패턴은 특정 작업에 묶여 있지 않다. 질문 하나로 다음 후보를 찾을 수 있다.

매일 읽고, 손으로 처리하는 알림이 있는가?

있다면 그게 다음 후보다. 알림이 이미 “무엇이 이상한지”를 구조화해서 말해 주고 있다면, 그걸 읽고 고치는 일은 에이전트가 할 수 있다. 사람은 그 결과를 검토하는 자리로 옮겨 가면 된다.

정리 — 싸진 만큼, 기본값이 바뀐다

세 이야기를 한 줄씩으로 줄이면 이렇다.

  • 공격이 싸졌다 → 숨기는 건 기본값이 될 수 없다. 문은 닫는다.
  • 모델이 싸졌다 → 처음 고른 모델은 기본값이 될 수 없다. 비교해 보고 고른다.
  • 반복 운영이 싸졌다 → 사람이 알림을 먼저 읽는 건 기본값이 될 수 없다. 사람은 마지막 판단에 집중한다.

세 편을 이어 보면 이렇게 된다.

  1. 컨텍스트는 세션에, 컨벤션은 저장소에.
  2. 규칙은 저장소에, 판단은 시스템에.
  3. 반복은 에이전트에게, 마지막 판단은 사람에게.

개인이 팀이 된 시대에는 상대도 팀이고, 도구도 팀이다. 무엇이 싸졌는지를 먼저 보고, 그만큼 기본값을 옮기는 것. 지난 몇 달 동안 한 일을 돌아보면 결국 그 작업의 반복이었다.

참고 자료