코드가 아닌 개발자를 보호하기: 에이전트 기반 개발(Agentic Development)과 보안에 관한 고찰

몇 년 전, 저는 AI와 사랑에 빠졌고 우리가 소프트웨어를 구축하는 방식이 기존의 보안 가설 대부분을 깨뜨리는 방식으로 변화할 것이라고 확신했기에 Snyk에서의 일상적인 업무를 떠나 Tessl을 시작했습니다. 저는 여전히 그렇게 믿고 있습니다. 최근 Snyk의 보안 컨퍼런스에서 했던 강연은 이를 구체적으로 입증하려는 시도였으며, 이 포스트는 현장에 없었던 분들을 위해 해당 강연을 글로 옮긴 버전입니다.

요약(tl;dr) - 에이전트(agents)가 전례 없는 속도로 코드를 생성하고 삭제함에 따라, 우리 인간의 역할은 코드를 보호하는 것이 아니라, 에이전트가 코드를 구축하는 과정에서 스스로 보안을 유지하도록 만드는 것입니다. 이는 새로운 도구, 접근 방식 및 지표를 요구하는 실질적인 변화입니다.

이것이 무엇을 의미하는지, 그리고 우리가 이에 대해 무엇을 해야 하는지에 대한 제 생각은 다음과 같습니다.

AI 증강(AI-augmented)에서 AI 네이티브(AI-native)로

개발 분야에서의 첫 번째 AI 물결은 Copilot과 그 뒤를 이은 Cursor가 개척한 '증강(augmentation)'이었습니다. 즉, 사용자가 코드를 작성하면 AI가 더 빠르게 작성할 수 있도록 도와주는 방식이었습니다. 두 번째 물결은 '위임(delegation)'입니다. 에이전트에게 작업을 요청하면 에이전트가 스스로 작업을 수행하러 떠나는 방식이며, 이는 에이전트가 개발자가 되고 사용자는 검토자(reviewer), 프롬프트 작성자(prompter), 그리고 의도 감사자(auditor of intent)가 된다는 것을 의미합니다.

이것은 더 이상 논쟁의 여지가 있는 주장이 아닙니다. 에이전트 기반 개발(agentic development)은 모든 것이 통합되는 지점이며, 저는 소프트웨어가 '탄광의 카나리아(canary in the coalmine, 위험을 알리는 지표)' 역할을 하기 때문에 소프트웨어에 집중하겠지만, 모든 형태의 지식 노동이 같은 방향으로 향하고 있습니다.

생산성 향상은 분명히 존재하지만, 에이전트 기반 개발은 작업 단위(unit of work), 출력의 결정론(determinism), 그리고 개발 프로세스의 변화율을 동시에 변화시키며, 이러한 각각의 변화는 우리가 보안 관행을 구축해 온 서로 다른 가설들을 깨뜨립니다.

• 비결정론적(non-deterministic)입니다. 한 번 컴파일하고 다시 컴파일했을 때 동일한 결과가 나오는 방식은 더 이상 작동하지 않습니다. 동일한 프롬프트(prompt)가 서로 다른 출력을 생성하기 때문에, 우리는 이에 대해 통계적으로 접근해야 합니다.
• 소프트웨어의 단위가 변하고 있습니다. 과거에 우리가 보호하던 대상은 구현체(implementation)였으나, 이제는 점점 더 지시 사항(instructions), 즉 기술(skills), 프롬프트(prompts), 컨텍스트(context)가 보호 대상이 되고 있습니다. 이는 새로운 단위이자 새로운 공격 표면(attack surface)이며, 새로운 도구(tooling)의 필요성을 의미합니다.
• 그 어느 때보다 빠르게 움직입니다. 개발 주기가 압축됨에 따라 보안도 이를 따라잡아야 하며, 에이전트(agents)의 속도를 맞출 수 있는 유일한 방법은 보안 그 자체도 에이전트화(agentic)되는 것입니다.

도전 과제 1: 비결정론은 측정이 필요함을 의미합니다

DevOps를 통해 성장했다면 다음과 같은 정신을 알고 있을 것입니다: 움직이는 것이라면 측정하고, 움직이지 않는 것이라면 움직일 경우를 대비해 측정하라. 서버는 우리가 프로덕션에 배포했던 것 중 가장 통계적인 존재였으며, 정답은 언제나 동일했습니다. 즉, 측정할 수 없는 것은 최적화할 수 없다는 것입니다.

에이전트는 완전히 다른 범주의 통계적 특성을 가집니다. 비결정론적 특성이 단순히 요청 계층(request layer)에만 머무는 것이 아니라, 모델 출력(model output), 도구 선택(tool selection), 검색(retrieval), 재시도(retries), 그리고 다단계 계획(multi-step planning) 전반에 걸쳐 복합적으로 작용하기 때문입니다. 이는 서버를 위해 작동했던 측정 방식으로는 이 중 그 어떤 것도 포착할 수 없음을 의미합니다.

AI 세계에서 이를 수행하는 방법은 **평가(evals)**입니다. 여기서 여러분은 작업을 정의하고, 무엇이 '좋은 상태'인지 미리 정의한 다음, 해당 작업에 대해 에이전트를 여러 번 실행하여 각 실행 결과에 점수를 매깁니다.

예시로 ElevenLabs를 대상으로 이를 실행해 보았습니다. ElevenLabs는 최근 음악 생성 API를 출시한 런던 기반의 뛰어난 텍스트 음성 변환(text-to-speech) 연구소입니다. 저는 에이전트에게 게임 스튜디오를 위한 동적 사운드트랙 생성기를 구축하는 작업을 부여했고, 각 실행에 점수를 매겼으며, 5가지 시나리오에 대해 10번씩 실행했습니다.

결과는 전반적으로 노이즈가 심했습니다. 음악 API가 새롭고 모델 가중치(model weights) 내에서 비중이 낮기 때문에 절대적인 점수는 낮게 나왔으며, 더 큰 문제는 변동성(variance)이었습니다. 동일한 작업, 동일한 프롬프트, 10번의 실행 결과가 매번 실질적으로 달랐습니다.

오늘날 가장 흔한 답변은 **컨텍스트 (context)**이며, 컨텍스트의 가장 흔한 단위는 **스킬 (skills)**입니다. 스킬은 에이전트가 작업을 잘 수행하는 데 필요한 지식을 제공하는 (약간의 구조를 갖춘) 마크다운 (Markdown) 파일입니다.

지식은 지능과 같지 않습니다. 모델은 추상적으로는 매우 유능할 수 있지만, 특정 API 표면(API surface), 내부 컨벤션(internal convention), 또는 피해야 할 지원 중단된 임포트 경로(deprecated import path)를 알지 못해 작업을 실패할 수 있습니다. 외부에서 보기에 이러한 실패는 단순히 충분히 똑똑하지 않은 모델의 실패와 동일해 보입니다.

우리는 API를 설명하는 ElevenLabs 음악 스킬을 가져와 동일한 평가(evals)를 수행했습니다. 그 결과, 에이전트는 스킬이 없을 때의 평균 50%에서 스킬이 있을 때 98%로 상승했으며, 변동성은 압축되었고 작업이 실제로 완료되었습니다.

CodeGuard, 그리고 왜 더 많은 컨텍스트가 더 나은 컨텍스트는 아닌가

동일한 아이디어이지만 보안에 적용했습니다. CodeGuard는 Cisco가 구축하여 기부한 프로젝트로, OWASP 보안 규칙을 에이전트가 더 안전한 코드를 작성하도록 돕는 스킬로 패키징합니다. 그래서 저는 특히 권한 부여(authorisation)에 초점을 맞춘 6가지 평가 시나리오를 만들고, CodeGuard가 있을 때와 없을 때의 에이전트 출력을 점수화했습니다.

CodeGuard가 없을 때 에이전트는 권한 부여 점수표에서 48%를 기록했으며, CodeGuard를 사용했을 때 거의 1.78배 개선되었습니다. 이는 의미 있는 상승이지만, 두 번째 실험이 더 흥미로웠습니다.

CodeGuard를 원래 기술의 약 5% 수준인 인증(authentication) 및 인가(authorisation) 콘텐츠로만 축소하여 동일한 평가(evals)를 다시 실행했을 때, 점수는 98%로 급등했습니다. 이는 작업에 엄격하게 제한된(scoped tightly) 적은 양의 컨텍스트(context)가 더 많은 컨텍스트를 가진 경우를 큰 차이로 압도했음을 의미합니다.

더 많은 컨텍스트가 반드시 더 나은 컨텍스트인 것은 아닙니다. 왜냐하면 제가 당신 앞에 앉아 100가지 사항을 말해준다면, 그 내용이 아무리 훌륭하더라도 3가지를 말해줄 때보다 각 사항에 기울이는 주의(attention)가 줄어들 것이기 때문입니다. 주의(Attention)는 인간과 모델 모두에게 희소한 자원이며, 이는 무엇을 말하고 무엇을 제외할지 선택하는 것이 기술(craft)의 일부임을 의미합니다.

기술(skill) 대신 에이전트(agent)를 변경할 때도 동일한 패턴이 나타납니다. 동일한 지침(instructions)을 Opus, Sonnet, Codex, Cursor에 실행했을 때 실질적으로 다른 점수가 도출됩니다. 컨텍스트는 단순히 기술의 속성이 아니라, 기술-에이전트 쌍(skill-agent pair)의 속성입니다. 따라서 여러분의 컨텍스트는 실제로 사용 중인 에이전트에 맞춰 조정(tuned)되어야 합니다.

컨텍스트 개발 라이프사이클 (The Context Development Lifecycle)

기술(skills)을 구축(build), 평가(evaluate), 최적화(optimise), 배포(distribute)하고 프로덕션(production)에서 관찰(observe)하는 대상으로 다루기 시작하면 라이프사이클(lifecycle)이 생기며, 우리는 이를 **컨텍스트 개발 라이프사이클 (Context Development Lifecycle, CDLC)**이라고 불러왔습니다. 저는 이것이 소프트웨어 개발 라이프사이클 (SDLC) 내부에 포함되기보다는 SDLC와 나란히 존재한다고 생각합니다.

CDLC는 인간이 활동하는 영역으로, 에이전트를 안내하는 컨텍스트를 구축하며, 이렇게 구축된 컨텍스트는 에이전트가 실제로 작업을 수행하는 SDLC 전반에 적용됩니다.

관찰(observe) 단계는 중요합니다. 평가(evals)는 테스트와 마찬가지로 유용하지만, 프로덕션에서 실제로 어떤 일이 일어나고 있는지 관찰하지 않으면 현실과 동떨어지게 되기 때문입니다. 루프(loop)를 완성하고 싶다면 구축(build), 평가(evaluate), 배포(distribute), 관찰(observe), 학습(learn), 개선(improve)의 과정을 거쳐야 합니다.

동일한 기술(skill)과 동일한 지침(instruction)이 엔드 투 엔드(end-to-end)로 적용될 수 있습니다. 이는 뛰어난 개발자가 동일한 지식을 사용하여 기능을 설계(spec)하고, 코드를 작성(write)하며, 리뷰(review)하고, 배포(ship)하며, 장애(incident)를 해결(troubleshoot)하는 방식과 같습니다. 기술(skills)이 그러한 지식을 나타낸다면, 보안 관점에서는 동일한 기술이 작성(writing) 단계, 감사(audit) 단계, 그리고 사고 대응(incident response) 단계를 보호할 수 있음을 의미합니다.

도전 과제 2: 기술(skills)은 소프트웨어의 새로운 단위이다

CDLC(Continuous Development Life Cycle) 내에서 활동할수록 두 번째 도전 과제가 더욱 명확해집니다. 그것은 우리가 기술(skills)을 마치 문서(documents)인 것처럼 다루고 있다는 점인데, 실제로는 그렇지 않다는 것입니다. 기술(skills)은 마크다운(Markdown)으로 저장되고, Confluence 페이지와 동일한 도구에서 편집되며, 산문(prose)처럼 검토됩니다. 하지만 런타임(runtime) 시에 에이전트(agent)는 이를 지침(instructions)으로서 실행합니다. 이는 기술(skills)을 문서보다는 코드(code)에 훨씬 더 가깝게 만듭니다. 따라서 보안 모델은 파일 확장명이 아닌 이러한 현실을 따라야 합니다.

이는 기술(skills)이 소프트웨어가 가진 모든 실패 모드(failure modes)를 가질 뿐만 아니라, 몇 가지 새로운 실패 모드도 가질 수 있음을 의미합니다.

• 악의적인 기술 (Malicious skills). Snyk과 다른 기업들은 공격자가 에이전트가 해서는 안 될 행동을 하도록 설계된 지침을 기술 (skills)에 심어두는 사례를 기록해 왔습니다. 저희 자체 레지스트리에서도 표준 블록체인 API 헬퍼처럼 보이지만, 주의 깊게 살펴보면 비밀번호로 보호된 zip 파일을 조용히 다운로드하는 단계가 포함된 기술 사례를 확인한 바 있습니다.
• 취약한 기술 (Vulnerable skills). 사용자에게 프롬프트(prompt) 내에 API 키를 직접 입력하도록 요청하거나, 일반적인 토큰 (plain vanilla tokens)으로 MCP 호출을 수행하는 기술은 작성자의 의도가 악의적이지 않더라도 설계 단계부터 보안에 취약합니다.
• 태만한 기술 (Negligent skills). 업계 표준 용어는 아니지만, 반드시 용어화되어야 합니다. 왜냐하면 이러한 기술들은 "이것을 프라이빗 저장소 (private repo)에 커밋하세요. 만약 커밋할 수 없다면, 다른 방식으로 작업물을 유출하지 말고 실패 처리하세요."와 같은 기본적인 안전 지침이 결여되어 있기 때문입니다. 우리는 모두 보상 추구 모드 (reward-seeking mode)에 빠져, 사용자를 기쁘게 하기 위해 파일을 삭제하거나 샌드박스 (sandbox)를 탈출하는 등 작업을 완수하기 위해 수단과 방법을 가리지 않는 에이전트들을 목격해 왔습니다. 태만한 기술이란 에이전트에게 가드레일 (guardrails)이 어디에 있는지 알려주지 않는 기술을 말합니다.
• 공급망 (Supply chain). 오늘날 사람들이 기술을 소비하는 방식은 무작위 GitHub 저장소에서 마크다운 (Markdown) 파일을 다운로드하여 자신의 저장소에 커밋하는 방식입니다. 종종 7개의 서로 다른 에이전트를 지원하기 위해 7개의 서로 다른 폴더에 나누어 저장하기도 하는데, 지금은 괜찮을지 몰라도 결국 팀들에게 큰 문제를 일으킬 것입니다.

기술을 단순한 문서가 아닌 소프트웨어 산출물 (software artifact)로 취급하기 시작하면, 프레이밍 문제 (framing problem)의 대부분은 스스로 해결됩니다. 버전 관리 (versioning), 의존성 해결 (dependency resolution), 출처 (provenance), 스캐닝 (scanning), 서명 (signing), 그리고 라이프사이클 관리 (lifecycle management)는 패키지 생태계가 지난 20년 동안 해결해 온 문제들이며, 많은 해답이 약간의 적응만 거치면 그대로 적용될 수 있기 때문입니다.

엔터프라이즈급 기술 거버넌스의 모습

대략적으로 필요한 순서에 따른 세 가지 요소입니다.

**거버넌스 및 보안 (Governance and security)**은 무슨 일이 일어나고 있는지 파악하는 것에 관한 것입니다. 즉, 누가 게시하고 누가 설치하는지 감사(auditing)하고, npm을 제한하는 것과 동일한 방식으로 공급망(supply chain)을 중앙 집중식 경로로 제한하며, 스킬(skills)이 레지스트리(registry)에 도달하기 전에 악성 콘텐츠를 스캔하는 것을 의미합니다. 제가 대화하는 대부분의 팀은 아직 이 작업을 시작하지 않았으며, 바로 이 부분이 배포를 가로막는 요소입니다.

**표준화 및 재사용 (Standardisation and reuse)**은 스킬이 흐르기 시작할 때 발생하는 다음 문제입니다. 팀 내 세 명이 "코드 리뷰" 스킬을 구축한 상태에서 네 번째 사람이 합류하면, 중복(duplication)과 드리프트(drift)가 실제적인 문제가 되기 때문입니다. 팀에는 비교하고, 표준화하며, 선택할 수 있는 방법이 필요합니다.

**지속적 최적화 (Continuous optimisation)**는 궁극적인 목표(holy grail)이며, 에이전트가 무엇을 했는지, 성공했는지, 사용자가 이를 수정해야 했는지를 관찰함으로써 CDLC가 루프를 닫는 단계입니다. 개발자는 해당 시그널을 평가(evals)에 다시 피드백하여 스킬을 진화시키고 새 버전을 출시해야 하며, 이것이 바로 최첨단에 있는 팀들이 하고 있는 일입니다.