에이전트 제어 레이어를 기본 거부로 설계해보자

허용목록을 비워두면 아무것도 통과하지 않는 구조로 시작했다. 설계 문서 첫 절에 적은 건 기능 목록이 아니라 이전 전제의 철회였고, 그러자 할 일이 줄었다

Posted Aug 19, 2026

views 6 min read

에이전트가 외부 대상에 직접 동작을 걸게 하려니 무엇을 막을지부터 정해야 했다. 허용목록을 비워둔 채로 시작해서, 넣은 것만 통과하게 만들었다.

문제/상황 (Problem): 에이전트에 동작 실행 권한을 주면 잘못된 대상에 잘못된 동작을 걸 수 있다. 막을 것을 하나씩 나열하는 방식은 빠뜨린 항목이 곧 구멍이 된다.
목적 (Purpose): 기본값을 거부로 두고, 통과시킬 것만 명시적으로 등록하는 구조를 만든다. 정책은 한 곳에만 적는다.
대상 (Target Audience): 에이전트에 실행 권한을 넘기기 전에 경계를 어떻게 그을지 고민 중인 개발자.

배경 조사 및 데이터 (Data Collection): 제어 레이어가 막아야 할 축을 네 가지로 나눴다. 축마다 실패했을 때의 결과가 다르다.

접근 방법 (Approach Methods):
- [방법 1]: 정책을 상수 한 곳에 모으고, 진입 함수가 큐에 명령을 싣기 전에 검사한다. 거부되면 큐가 비어 있어야 한다 — 이걸 확인하지 않으면 “거부했다고 로그만 찍고 명령은 나가는” 상태를 못 잡는다.
- [방법 2]: connect → action → disconnect 수명주기를 강제한다. 연결 상태를 한 객체에 모으면 동시 연결 수·마지막 동작 시각·연결 시각을 한자리에서 볼 수 있다. 그래서 세 검사를 순서대로 걸 수 있다.
분석 및 해결 프로세스 (Analysis Flow):
- 도구/기술: 표준 라이브러리만 사용. threading.Lock으로 연결 상태를 보호하고, ast로 가드가 코드에 남아 있는지 확인한다.
- 주요 단계: 대상 검사 $\rightarrow$ 동작 종류 검사 $\rightarrow$ 연결·TTL·간격 검사 $\rightarrow$ 통과 시에만 큐에 적재.
- 결과 도출 및 검증: 허용목록이 빈 상태에서 요청을 넣자 거부되고 큐가 0건이었다. 대상을 하나 등록하자 그 대상만 통과하고 다른 대상은 계속 거부됐다. 0.5초 뒤 재시도는 간격 미달로 막혔고 2.0초 뒤는 통과했다. 네 번째 연결은 한도 초과로 거부돼 연결 수가 3에서 멈췄고, TTL을 넘긴 동작은 만료로 끊겼다. script 동작은 종류 검사에서 걸렸다.

분석 결과 요약: 네 축이 각각 독립적으로 동작하는 것을 확인했고, 거부된 요청이 큐에 흔적을 남기지 않는다는 것까지 봤다. 마지막으로 진입 함수가 허용목록을 실제로 참조하는지 정적으로 확인하는 검사를 붙였다. 조건문을 지워도 기능 테스트는 초록불일 수 있어서, “가드가 코드에 남아 있는가”는 따로 봐야 한다.

인사이트 (Insight): 설계 문서 첫 절에 쓴 게 기능 목록이 아니라 이전 전제의 철회였다. 처음에는 탐지를 사실상 다 우회할 수 있다고 봤는데, 그건 과신이었고 그 방향으로 최적화하지 않기로 못박았다. 그러자 지문 위조나 프록시 순환 같은 항목이 통째로 범위 밖으로 빠졌다. 못 하는 것을 먼저 적으면 할 일이 줄어든다.
실행 방안 (Action Plan): 제어 레이어를 만들 때 허용목록을 빈 채로 먼저 커밋한다. 채운 상태로 시작하면 무엇을 왜 넣었는지가 남지 않고, 나중에 빼기 어렵다.
한 줄 결론 (Key Takeaway): 기본값을 거부로 두면 빠뜨린 항목이 구멍이 아니라 거부가 된다. 샘플 코드
다음 스텝 (Next Step): 지금 정책값(동시 3·간격 1.5초·TTL 900초)은 실측이 아니라 짐작으로 정한 값이다. 실제 대상에서 어느 지점부터 차단이 걸리는지를 재서 근거 있는 값으로 바꾸는 것이 남아 있다.

This post is licensed under CC BY 4.0 by the author.

Trending Tags