이제 당신의 레포지토리 컨텍스트(Repo Context)는 공격 표면(Attack Surface)입니다

AI 코딩 보안의 게으른 버전은 "모델이 보안에 취약한 코드를 작성하지 않도록 보장하는 것"입니다.

그 말이 틀린 것은 아닙니다. 다만 너무 범위가 좁을 뿐입니다.

더 흥미로운 문제는 에이전트(Agent)가 코드를 작성하기 전에 읽는 모든 것과, 무엇을 할지 결정한 후에 실행할 수 있도록 허용된 모든 것입니다. 이제 당신의 레포지토리(Repo)는 단순히 코드가 거주하는 장소가 아닙니다. 에이전트 기반 코딩 도구(Agentic coding tool)에게 레포지토리는 입력 스트림(Input stream)의 일부입니다.

이것은 보안 모델을 변화시킵니다.

오래된 문서, 오래된 예제, 로컬 지침 파일, 숨겨진 프로젝트 컨벤션(Conventions), 의존성 스크립트(Dependency scripts), 셸 훅(Shell hooks), 웹훅(Webhooks), 메모리, 위임된 워커(Delegated workers), 그리고 이전의 디프(Diffs) 등은 모두 스티어링(Steering, 유도) 자료가 될 수 있습니다. 그 컨텍스트(Context) 중 일부는 유용합니다. 일부는 쓰레기입니다. 그리고 일부는 적대적일 수 있습니다.

이 지점에서 에이전트(Agent)에 대한 열풍은 고통스러울 정도로 평범해집니다. 위험은 마법 같은 것이 아닙니다. 개발자들이 이미 알고 있는 것과 동일한 자동화 위험이 에디터(Editor)에 더 가까이 이동하여, 매우 자신감 있게 들리는 모델에 감싸여 있는 것뿐입니다.

컨텍스트는 더 이상 배경이 아닙니다

개발자들은 레포지토리 컨텍스트를 중립적인 것으로 취급하는 경향이 있습니다.

README는 그냥 README일 뿐입니다. 오래된 마이그레이션 노트는 그냥 오래된 마이그레이션 노트입니다. docs/에 있는 예제는 그냥 예제일 뿐입니다. 훅(Hook) 설정은 지난 분기에 누군가가 추가한 편의 기능일 뿐입니다.

에이전트는 반드시 그러한 사회적 맥락(Social context)을 보지는 않습니다. 에이전트는 텍스트, 도구, 경로, 명령 및 패턴을 봅니다. 만약 코딩 어시스턴트(Coding assistant)가 무엇이 "정상"인지 결정하기 위해 프로젝트 컨텍스트를 사용한다면, 그 모든 자료가 출력값에 영향을 미칠 수 있습니다.

이것이 모든 에이전트가 모든 git 객체, 숨겨진 파일, 또는 잊혀진 노트를 읽는다는 뜻은 아닙니다. 이를 과장하는 것은 논의 전체를 악화시킵니다. 진짜 핵심은 더 좁고 유용합니다: 일단 도구가 동작을 형성하기 위해 로컬 컨텍스트를 사용할 수 있게 되면, 로컬 컨텍스트는 신뢰 경계(Trust boundary)의 일부가 됩니다.

이는 문서와 예제를 저위험성 잡동사니로 취급하며 수년을 보낸 팀들에게 매우 큰 변화입니다.

나쁜 컨텍스트는 지루할 수도 있습니다:

오래된 설정 지침 (outdated setup instructions)
지원 중단된 API (deprecated APIs)를 사용하는 예제
더 이상 프로덕션 환경과 일치하지 않는 오래된 아키텍처 노트
안전하지 않은 가정을 인코딩한 테스트 픽스처 (test fixtures)
취약한 보안 기본값을 가진 복사된 코드 스니펫

나쁜 컨텍스트는 적대적 (adversarial)일 수도 있습니다:

에이전트가 읽을 수 있는 파일 내부의 프롬프트 인젝션 (prompt-injection) 스타일의 지침
예상보다 더 많은 것을 실행하는 의존성 스크립트 (dependency scripts)
로컬 명령을 더 큰 실행 경로로 전환하는 훅 (hook) 설정
미래의 변경 사항을 안전하지 않은 패턴으로 유도하는 오염된 예제

어느 쪽이든 실패 모드는 동일합니다. 에이전트는 당신이 승인할 의도가 없었던 전제 위에서 동작을 구축합니다.

훅 (Hooks)은 빌드 스크립트와 동일한 의심을 받아야 합니다

에이전트를 유용하게 만드는 가장 빠른 방법은 에이전트가 무언가를 수행하게 하는 것입니다.

포맷터를 실행하고, 테스트를 수행하고, 파일을 검색하고, 풀 리퀘스트 (pull requests)를 생성하고, 프로젝트 스크립트를 호출하고, 웹훅 (webhooks)을 트리거하고, 다른 에이전트에게 작업을 넘깁니다. 이것이 바로 유용한 기능들입니다. 하지만 동시에 이것이 폭발 반경 (blast radius)이 시작되는 지점이기도 합니다.

훅 시스템이 실제 개발 환경에서 명령을 실행할 수 있게 되는 순간

에이전트 플랫폼 (Agent platforms)은 단발성 채팅 (single-turn chat)에서 벗어나고 있습니다. 이는 올바른 방향입니다.

메모리 (Memory)는 에이전트가 덜 반복적으로 행동하게 만듭니다. 결과 추적 (Outcome tracking)은 에이전트를 조종하기 더 쉽게 만듭니다. 위임 (Delegation)은 작업을 전문화된 작업자 (specialized workers)들에게 분산시킬 수 있게 합니다. 웹훅 (Webhooks)과 가시성 (visibility) 기능은 시스템이 단순한 마법의 텍스트 상자가 아니라 개발자 인프라 (developer infrastructure)처럼 느껴지게 합니다.

좋습니다.

하지만 유용한 상태 (state)는 여전히 상태입니다. 위임 (Delegation)은 여전히 위임입니다. 웹훅 (webhook)은 여전히 통합 지점 (integration point)입니다.

실수는 이러한 기능들을 순수한 기능적 업그레이드 (capability upgrades)로만 취급하는 것입니다. 제품 UI가 이를 명시적으로 말하든 그렇지 않든, 이것들은 거버넌스 (governance)의 업그레이드이기도 합니다.

에이전트가 프로젝트 선호도를 기억하고, 작업을 할당하며, 외부 시스템을 트리거하고, 더 긴 작업 루프 (task loop)에 걸쳐 작동할 수 있게 되면, 당신은 그 루프의 형태에 신경을 써야 합니다:

어떤 메모리가 저장되는가
누가 그것을 변경할 수 있는가
언제 사용되는가
어떤 에이전트가 그것을 상속받을 수 있는가
위임된 작업자가 어떤 도구 (tools)를 호출할 수 있는가
결과가 반영되기 전에 어떻게 검토되는가

이것은 공황에 빠지라는 호출이 아닙니다. 에이전트가 단지 더 똑똑한 자동 완성 (autocomplete)일 뿐이라고 가장하는 것을 멈추라는 호출입니다.

자동 완성은 텍스트를 제안합니다. 에이전트 워크플로 (Agent workflows)는 가정을 축적하고, 도구를 호출하며, 명령을 실행하고, 향후 실행 시 신뢰하게 될 변경 사항을 남길 수 있습니다. 이것은 차원이 다른 시스템입니다.

실질적인 통제 수단은 지루하지만, 그것이 좋습니다

올바른 대응은 "에이전트를 절대 사용하지 마라"가 아닙니다. 그것은 진지하지 못한 태도입니다.

올바른 대응은 워크플로를 덜 모호하게 (less squishy) 만드는 것입니다. 더 적은 주변 권한 (ambient permissions), 더 작은 범위 (smaller scopes), 더 깨끗한 컨텍스트 (cleaner context), 그리고 발생한 일에 대한 더 나은 기록을 원해야 합니다.

범위 (scope)부터 시작하십시오.

에이전트가 단 세 개의 파일만 필요할 때 전 세계를 향해 가리키지 마십시오. 좁은 작업 (narrow tasks)을 사용하십시오. 변경 사항이 위험할 때는 일회성 워크트리 (disposable worktrees)를 사용하십시오. 에이전트가 어떤 혼란이 의도된 것인지 추론할 필요가 없도록, 관련 없는 차이점 (diffs)을 워킹 트리 (working tree)에서 제외하십시오.

그다음 지침 (instructions)을 감사 (audit)하십시오.

에이전트가 가이드 (guidance)로 취급할 가능성이 높은 파일들을 읽으십시오: 루트 문서 (root docs), 에이전트 지침 (instruction) 파일, 코딩 표준 (coding standards), 예시 (examples), 오래된 마이그레이션 노트 (migration notes), 그리고 내부 체크리스트 (internal checklists). 만약 이 파일들이 오래되었다면(stale), 삭제하거나 수정하십시오. 만약 중요하다면, 명시적으로 만드십시오. 만약 명령 (commands)을 포함하고 있다면, 해당 명령들을 시스템의 일부로 취급하십시오.

그다음 실행 (execution)을 강화 (harden)하십시오.

가능하다면 위험한 작업은 샌드박스 (sandbox)에서 실행하십시오. 자격 증명 (credentials)의 범위를 제한 (scoped)하십시오. 셸 (shell) 내의 암묵적인 비밀 정보 (ambient secrets)를 피하십시오. CI를 검토하듯이 훅 (hook) 설정을 검토하십시오. 에이전트가 트리거할 수 있는 워크플로 (workflows)에 대해 의존성 (dependency) 동작을 고정 (pin)하거나 최소한 검사하십시오. "테스트 실행 (run tests)"이 비밀리에 "사용 가능한 모든 토큰을 사용하여 모든 스크립트를 실행"하는 것을 의미하지 않도록 하십시오.

마지막으로, 가시성 (visibility)을 요구하십시오.

당신은 다음 질문에 답할 수 있어야 합니다:

에이전트가 무엇을 읽었는가?
어떤 도구 (tools)를 호출했는가?
어떤 파일을 변경했는가?
어떤 명령 (commands)이 실행되었는가?
어떤 가정 (assumptions)을 했는가?
무엇이 여전히 인간의 검토 (human review)를 필요로 하는가?

만약 답변이 "괜찮았던 것 같습니다"라면, 해당 워크플로는 폭발 반경 (blast-radius)이 큰 작업을 수행할 만큼 충분히 성숙하지 않은 것입니다.

프로덕션 사용에는 여전히 인간의 소유권 (ownership)이 필요합니다

프로덕션 AI 코딩에 관한 개발자들의 논의는 계속해서 동일한 지점으로 돌아옵니다: 사람들이 이러한 도구들을 진지한 작업에 사용하고 있지만, 판단 (judgment)을 외주 줄 수는 없다는 점입니다.

그것은 타당하게 느껴집니다.

에이전트는 알려진 지형을 빠르게 이동할 수 있습니다. 스캐폴딩 (scaffold), 리팩터링 (refactor), 검사 (inspect), 요약 (summarize), 그리고 요소들을 서로 연결 (wire together)할 수 있습니다. 하지만 에이전트는 잘못된 컨텍스트 (context)를 완벽한 자신감으로 따를 수도 있습니다. 시스템을 운영하는 사람은 여전히 아키텍처 (architecture), 자격 증명 (credentials), 검토 (review), 테스트 품질 (test quality), 그리고 릴리스 결정 (release decisions)에 대한 소유권을 가집니다.

이것이 팀이 명시적으로 만들어야 할 부분입니다.

만약 에이전트가 풀 리퀘스트 (pull request)를 생성한다면, 작성자가 인간이 아니라는 이유로 검토 표준 (review standard)이 낮아져서는 안 됩니다. 만약 에이전트가 인증 (auth) 코드를 변경한다면, 보안 검토 (security review)는 완화되는 것이 아니라 더 엄격해져야 합니다. 만약 에이전트가 스크립트나 훅 (hooks)을 편집한다면, 이를 인프라 작업 (infrastructure work)으로 취급하십시오. 만약 에이전트가 테스트를 통과했다고 주장한다면, 어떤 테스트가 실행되었고 그것이 무엇을 증명하는지 확인하십시오.

최고의 팀은 에이전트 기반 코딩 (Agentic Coding)을 금지하는 팀이 아닐 것입니다. 또한 모든 에이전트에게 영구적인 토큰과 강력한 프롬프트 (Heroic Prompt)를 부여하는 팀도 아닐 것입니다.

그들은 에이전트의 작업을 지루하고 검사 가능한 개발 프로세스로 전환하는 팀이 될 것입니다.

유용한 멘탈 모델 (Mental Model)

AI 코딩 에이전트를 쉘 (Shell) 접근 권한이 있고, 타이핑 속도는 매우 빠르며, 독특한 독해 습관을 가졌고, 당신의 레포지토리 (Repo)가 왜 현재와 같은 모습인지에 대한 사회적 기억이 없는 주니어 개발자로 생각하십시오.

당신은 그 사람에게 첫날부터 운영 환경 자격 증명 (Production Credentials)을 넘겨주지는 않을 것입니다. 검토 없이 배포 파이프라인 (Deployment Pipeline)을 다시 작성하라고 요청하지도 않을 것입니다. 레포지토리의 모든 오래된 노트를 현재의 정책으로 취급하도록 내버려 두지도 않을 것입니다. 대신 그들에게 작은 작업, 깨끗한 컨텍스트 (Context), 제한된 권한, 그리고 검토 경로를 제공할 것입니다.

이 모델이 완벽하지는 않지만, 올바른 태도 (Posture)를 갖추게 해줍니다.

에이전트가 악한 것이 아닙니다. 레포지토리에 저주가 내린 것도 아닙니다. 문제는 신뢰 (Trust)입니다.

레포지토리 컨텍스트 (Repo Context)가 모델 입력값이 되고 로컬 자동화가 에이전트의 행동이 되면, 경계가 이동합니다. 보안도 그와 함께 이동해야 합니다.

실질적인 교훈은 간단합니다: 컨텍스트를 정돈하고, 범위를 좁히며, 실행을 샌드박스 (Sandbox)화하고, 행동을 기록하며, 변경 사항 (Diff)을 매우 중요한 것처럼 검토하십시오.

왜냐하면 그것은 정말 중요하기 때문입니다.

출처 노트 (Source notes)