여러분, 처음부터 솔직하게 말씀드릴게요.

저는 AI Security 전문가로서 이 글을 쓰는 것이 아닙니다. 제 업무에 대한 질문 자체가 바뀌는 시점에 서 있기 때문에 이 글을 씁니다.

저는 하루 종일 압박감이 있는 시스템 위에서 시간을 보냅니다: 신뢰성(reliability), 관측 가능성(observability), 인시던트(incident), 그리고 제가 방을 나간 후에도 계속해서 의미를 유지해야 하는 결정들 말이죠. 최근에는 LLM, 에이전트(agent), MCP, 그리고 메모리/RAG를 실제로 운용하며 업무를 수행하고 있습니다.

지난 몇 달 동안, 저는 이미 팀들이 에이전트, MCP 및 자동화(automation) 사용을 가속화하도록 돕고 있다는 것을 깨달았습니다. 하지만 권한(permissions), 공격 표면(attack surfaces), 데이터 흐름(data flow)을 검토할 때는 아직 그만큼의 확신이 없었습니다. 아키텍처와 운영을 평가하는 법은 알고 있었지만, 에이전트 기반 시스템(agentic systems)의 보안을 위해 이 관점을 확장할 필요가 있었습니다.

그렇게 제 머릿속의 질문이 바뀌었습니다.

이전에는:

어떻게 하면 이 에이전트가 더 빠르게 결과물을 내놓게 할 수 있을까?

이제는:

만약 이 에이전트가 도구(tool)를 가지고 있다면, 무엇을 망가뜨릴 수 있으며, 그 리스크는 누가 책임지는가?

이것이 제가 공개적으로 공부하고자 하는 내용입니다. 여러분이 내일 당장 사용할 수 있는 실용적인 팁과 함께 말이죠.

Staff의 성가시지만 (유용한) 본능

저에게 Staff란, 모든 곳에 나타나는 것이 아니었습니다.

그것은 팀이 제 기억력에 의존하지 않고도 올바른 결정을 내릴 수 있는 조건을 구축하는 것이었습니다.

이것은 일종의 성가신 본능을 만듭니다. 멋진 데모를 보고 **실패 모드(failure mode)**를 질문하는 것이죠.

• 웹훅(webhook)은 어떻게 실패하는가?
• 재시도(retry)가 무엇을 중복시키는가?
• 이 지표(metric)는 임팩트를 설명하는가, 아니면 단순히 화면에 스택 트레이스(stacktrace)를 던지는가?
• 킬 스위치(kill switch)가 있는가, 아니면 그냥 운에 맡기는가?

이제 이 동일한 본능이 에이전트의 프롬프트(prompt), 도구(tool), 메모리(memory) 및 권한(permission)을 바라봐야 합니다. 제가 하룻밤 사이에 커리어를 바꿨기 때문이 아닙니다. 리스크의 단위가 변했기 때문입니다.

잘못된 텍스트는 하나의 문제일 뿐입니다. 부적절한 행동은 별개의 문제입니다.

모델이 텍스트만 생성할 때, 피해는 대개 제한적입니다. 짜증 나고 때로는 비용이 들기도 하지만, 환각(hallucination), 부주의로 인한 유출, 나쁜 응답 정도로 제한됩니다.

하지만 동일한 모델이 도구를 갖게 되면: 파일 읽기, API 호출, PR 생성, 데이터 수정, 자동화(automation) 실행 등이 가능해지면 게임의 규칙이 바뀝니다.

그때 리스크는 단순히 "헛소리를 하는 것"에서 벗어나 다음과 같이 변합니다:

• 너무 높은 확신을 가지고 돌이킬 수 없는 행동을 수행함;
• 작업에 필요한 수준보다 훨씬 더 큰 권한을 가짐;
• 그곳에서 유출되어서는 안 되는 정보를 컨텍스트(Context)로 끌어옴;
• 제대로 된 감사(Audit) 없이 강력한 MCP/스킬(Skill)을 연결함.

이것은 블로그 수준의 피해망상이 아닙니다. 업계에서 이미 공개적인 로드맵으로 정리하려고 시도 중인 유형의 문제입니다. 저는 다음 항목들을 학습의 닻(Anchor)으로 삼고 있습니다:

• OWASP Top 10 for LLM Applications
• NIST AI Risk Management Framework

제가 견지하는 Staff Engineer로서의 독법은 매우 직설적입니다:

권한을 확인하지 않고 에이전트(Agent)를 가속하는 것은, 안전벨트를 풀고 속도를 최적화하는 것과 같다.

구체적인 이해를 위한 합성 시나리오 (Synthetic Scenario)

다음과 같은 조건을 가진 코딩 에이전트(Coding Agent)를 상상해 보세요:

• 레포지토리(Repo) 내 셸(Shell) 접근 권한 보유;
• "멈추지 않도록" 광범위하게 설정된 API 토큰(Token);
• 내부 메모와 티켓(Ticket) 컨텍스트를 혼합하는 메모리/RAG.

당신은 다음과 같이 요청합니다: "빌드 폴더의 임시 파일들을 정리해줘."

모델은 "임시(Temporaries)"라는 단어를 지나치게 관대하게 해석합니다. 경로 화이트리스트(Allowlist), 드라이 런(Dry-run), rm 명령에 대한 인간의 확인 절차 없이... 모델은 당신이 상상한 것보다 훨씬 더 멀리 나아갈 수 있습니다.

이것은 기업의 실제 사례가 아닙니다. 이는 우리가 유동성(Fluency)을 최적화하느라 제동 장치를 잊었을 때 발생하는 실패 유형을 보여주는 합성 예시입니다.

만약 제가 셸(Shell)과 광범위한 토큰을 부여하기 전에 아래의 체크리스트를 검토했다면, 적어도 세 가지 질문이 설계를 막았을 것입니다: 돌이킬 수 없는 행동, 최소 범위(Scope), 그리고 의도가 환각(Hallucination)일 경우 피해를 막을 수 있는 수단.

아티팩트(Artifact): 에이전트에게 도구를 부여하기 전 던져야 할 7가지 질문

복사해서 자동화 PR(Pull Request)에 붙여넣으세요. 답변 없이 진행하지 마십시오.

## 도구 접근 게이트 (에이전트)

1. 이 도구가 허용하는 가장 비용이 큰 돌이킬 수 없는 행동은 무엇인가?
...

본질적으로, 이 일곱 가지 질문은 오래된 원칙들, 즉 최소 권한(Least Privilege), 폭발 반경(Blast Radius) 감소, 감사 가능성(Auditability), 그리고 심층 방어(Defense in Depth)를 에이전트라는 새로운 인터페이스에 적용하려는 시도입니다. 역량 경계(Capability Boundaries)와 인간 참여(Human-in-the-loop) 개념이 자연스럽게 여기에 포함됩니다.

경험 법칙(Rule of thumb):

만약 어떤 응답이 모호하다면, 그 도구(tool)는 에이전트(agent)에 포함되지 않습니다.

이것은 우리가 생산성(productivity)을 태만(negligence)과 혼동하지 않기 위한 최소한의 제어 장치입니다.

다음 단계

이 글은 저의 AI Security 공개 여정의 첫 번째 글입니다. 앞으로 이어질 글들을 통해 실험실(labs), 에이전트의 위협 모델(threat models), MCP(Model Context Protocol), RAG(Retrieval-Augmented Generation), 권한(permissions), 그리고 그 과정에서 마주하게 될 오류들을 기록하고자 합니다.

제가 사용하고 있는 개인적인 필터는 다음과 같습니다:

이것이 나를 에이전트의 안전한 아키텍처(secure architecture) 분야에서 신뢰할 수 있는 사람으로 만들어 주는가, 아니면 단순히 새로운 도구에 한눈을 팔게 만드는가?

개인정보 보호(Privacy)와 익명화(anonymization)는 빠르게 게시하고 싶은 욕구보다 우선합니다. 만약 당신이 엔지니어링에 강점이 있고, 하이프(hype)에 회의적이며, 에이전트의 리스크(risk)에 호기심을 느끼는 사람이라면, 이 대화는 바로 우리를 위한 것입니다.

커뮤니티를 위한 질문

에이전트가 필요 이상의 권한을 부여받는 것을 본 적이 있나요? 당신이라면 무엇을 첫 번째 제어 장치로 설정하시겠습니까: 허용 목록(allowlist), 샌드박스(sandbox), 인간의 승인(human approval), 아니면 제한된 토큰(restricted token)인가요?

구체적인 사례가 있다면 더욱 좋습니다. 그 도구가 무엇을 할 수 있었는지, 그리고 그 후에 어떤 방어책(guardrail)을 세웠는지 공유해 주세요. 🤝